From nobody Thu Dec 2 23:43:50 2021 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 343E818C057B for ; Thu, 2 Dec 2021 23:43:53 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4swm6xFFz4nQT; Thu, 2 Dec 2021 23:43:52 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 1B2NhoSC066666 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Dec 2021 15:43:50 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 1B2Nhoel066665; Thu, 2 Dec 2021 15:43:50 -0800 (PST) (envelope-from jmg) Date: Thu, 2 Dec 2021 15:43:50 -0800 From: John-Mark Gurney To: David Chisnall Cc: freebsd-current@freebsd.org Subject: Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined) Message-ID: <20211202234350.GV35602@funkthat.com> Mail-Followup-To: David Chisnall , freebsd-current@freebsd.org References: <20211202020326.GU35602@funkthat.com> <75CCC6A8-F777-48F9-9AC7-5A08FA9CCD25@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-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 02 Dec 2021 15:43:51 -0800 (PST) X-Rspamd-Queue-Id: 4J4swm6xFFz4nQT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N David Chisnall wrote this message on Thu, Dec 02, 2021 at 10:34 +0000: > On 02/12/2021 09:51, Dimitry Andric wrote: > > Apparently the "block runtime" is supposed to provide the actual object, > > so I guess you have to explicitly link to that runtime? > > The block runtime provides this symbol. You use this libc API, you must > be compiling with a toolchain that supports blocks and must be providing > the blocks symbols. If you don't use `atexit_b` or any of the other > `_b` APIs then you don't need to link the blocks runtime. > > I am not sure why this is causing linker failures - if it's a weak > symbol and it's not defined then that's entirely expected: the point of > a weak symbol is that it might not be defined. This avoids the need to > link libc to the blocks runtime for code that doesn't use blocks (i.e. > most code that doesn't come from macOS). > > This code is not using `atexit_b`, but because it is using `atexit` the > linker is complaining that the compilation unit containing `atexit` is > referring to a symbol that isn't defined. I assume that this failure was due to a recent llvm change, because I haven't received any failures about pructl until Nov 16th, 2021, despite the port and code being untouched since 2020-09-22. Digging in a bit more, it looks like libpru is compiled w/ -fblocks, and so depending upon the _Block_copy symbol, the atexit is just the "closest" symbol that's defined". pructl is not, but even compiling pructl w/ -fblocks, doesn't fix the link error, as it looks like the block runtime isn't linked. If I manually include /usr/lib/libBlocksRuntime.so, then pructl is able to link. I can't seem to find any docs on clang about how to properly compile code that uses blocks, so, unless someone points me to docs on how to compile blocks enable programs, I'll just patch libpru to not use blocks since it seems like blocks is well supported. I don't want to fix this code every few years when things change. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Fri Dec 3 10:03:54 2021 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 13957188DD8C for ; Fri, 3 Dec 2021 10:04:00 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J57hH5FWjz4YvM; Fri, 3 Dec 2021 10:03:59 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f26:bf00:2002:64d8:36ae:6cc] (p200300cd5f26bf00200264d836ae06cc.dip0.t-ipconnect.de [IPv6:2003:cd:5f26:bf00:2002:64d8:36ae:6cc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 214D7721C; Fri, 3 Dec 2021 10:03:59 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: <77845d03-6351-8a8b-2eae-1db98f8a192c@freebsd.org> Date: Fri, 3 Dec 2021 11:03:54 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [REVIEW] Hide BIT_* macros from userland code Content-Language: en-US To: Shawn Webb Cc: FreeBSD CURRENT References: <7d97e129-4aa7-aa98-dc91-e332a3da620f@freebsd.org> <20211202164648.276kuh3blin6b2wp@mutt-hbsd> From: Stefan Esser In-Reply-To: <20211202164648.276kuh3blin6b2wp@mutt-hbsd> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------7fJerW2eTavEse5JA9lhZC5g" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638525839; 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=Zj/+2WsQ8v6E/0iqroTTPXOv+hYyST/Uf2YMMR3OSOc=; b=odf1CHrpsNchF5ugn9RgBrc+91441kYq1A8krwHPkcll1ltdDgSZGJQY8V9uI17IA1htzZ 31w6VqA2ZlSX78aHHQGnaECYMFPHY8IHj9XKaB8ZoFnOvT69HMtPko6TWs/1h3XNCqPtDq /nDe7CtGkXeGWp9KX8ZgGdHPnabhthZVwIiZlyQ7go4sKV2klrbak4+O7MieSbsSz65dZE llTVsqkA+tZNRSEPrPTLp2MdujCszvIHYpkHn0q/RFRzmZCE6xDZm7Gb05q1lutgePTwCn V0pDg9ouxZqzYckJjOBWe4lwmcsJodHtzb8ogzhQViEG3Z+JJm6sN8Fb7YrvzA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638525839; a=rsa-sha256; cv=none; b=MNtrnI3BGfl0yJ3UzyExKuAgJLXPuODgAqTCLQo+EZnqXIocSDoTV2pmIKgpU8T/5HDhxg J6d1c9CiN0SsyFYpWQ3aQ/upOFSctZb4C1WNOP/G43frHuvCMckR1MkvPwvw1GHKloiAm2 tD61VIjsZDyJy1MTczrTu3SEGeNzFV1fSs2ulG/dd9lZCvu/jzLz2Xr2+jijVIekKLCVFN mn2cVRlOspljmvZdGaYgSQM0FAC9i3fuN9Ouwio3ynSC7QllgMq3HwYYSHnxTyhkx1ypZu TXa/OE8s1AOQ6QWUwOFPNB0RiRi19Zu20/PeZq1RjDfCDDo9AC0DzxjQv1SR6Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------7fJerW2eTavEse5JA9lhZC5g Content-Type: multipart/mixed; boundary="------------StiE8KZpu6BOYfw0r6NJz1bR"; protected-headers="v1" From: Stefan Esser To: Shawn Webb Cc: FreeBSD CURRENT Message-ID: <77845d03-6351-8a8b-2eae-1db98f8a192c@freebsd.org> Subject: Re: [REVIEW] Hide BIT_* macros from userland code References: <7d97e129-4aa7-aa98-dc91-e332a3da620f@freebsd.org> <20211202164648.276kuh3blin6b2wp@mutt-hbsd> In-Reply-To: <20211202164648.276kuh3blin6b2wp@mutt-hbsd> --------------StiE8KZpu6BOYfw0r6NJz1bR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 02.12.21 um 17:46 schrieb Shawn Webb: > Hey Stefan, >=20 > On Thu, Dec 02, 2021 at 05:26:55PM +0100, Stefan Esser wrote: >> I have created >> >> https://reviews.freebsd.org/D33235 >> >> to remove the BIT_* macros used in the kernel from the userland API. >> >> They conflict with differing definitions in some 3rd party code and >> lead to compile issues in a number of ports (via CPU_* macros based >> on the BIT_* macros). >> >> See PR259787 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D25978= 7 >> for an example of such a problem. >=20 > I recently was in a position to evaluate BIT_* macros for userland > use. It was around the time when the conversation regarding hiding > BIT_* from userland, which conversation caused me to find another > solution. >=20 > I think such an API is incredibly useful, so I wonder if there's a way > to satisfy both. For example, maybe prefix the userland side with a > USERLAND_ or something similar? Kernel would use BIT_* and userland > would use USERLAND_BIT_* (just spitballing, not actually advocating > for "USERLAND_BIT_*" but rather just the idea of it.) Hi Shawn, I have updated the patch set in review D33235 and have added you to the reviewer list. IMHO the approach proposed by Konstantin Belousov is better than the introduction of prefixed macro names for the userland. A simple #define _WANT_FREEBSD_BITSET makes the __BIT* macros available by their traditional names, no other changes are required in the code. This does not solve the potential case of a program that wants to use both the BSD and GLIBC variants of the macros in a single source file. But I think that such a case is constructed and does not occur in actual code. And in any case, the IMHO __BIT* names are as good as the USERLAND_BIT* names you suggest (and I understand that you did not want that specific name - therefore a prefix of __ might be considered to match what you proposed ;-) ). And you are of course free to map __BIT* to any other prefixed name in a header file in your code ... An update of the bitset(9) man page might be a good idea, explaining the visibility rules and _WANT_FREEBSD_BITSET for system utilities that need to work with kernel style bitsets. Regards, STefan --------------StiE8KZpu6BOYfw0r6NJz1bR-- --------------7fJerW2eTavEse5JA9lhZC5g Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmGp64sFAwAAAAAACgkQR+u171r99URv wQgApvC3nHQqyAI7klB15zMEcgRyhqc334UCgBcFBg1uJhO5r/7Iw1n+dCaTGtfedhbAzmjNnULy 8MMaDJw96+Ze023dYJy9CcM8n3aBWfV43VlhWXzysJJQl9vz4thNCRajN1n1e6iyFHQhLdi4Yres FY0JwvLCfgye6YrAJYB0zz1M42VCaM1CFFFycR081YvUykFjJnJfG49BWYnBfuHkWdlUNcinNzCV 2XHA8t/4NNjRf6xImvy9LllG6L2GDv9pXI9U8a2nmHnS/6WS/yEtDvhvE6Wxq1GO5iomOlhqc8VP BvxtbgGTuR5lJbYTBC+/ws9I9+SW5WRmLE0Bh8DEFw== =gfdj -----END PGP SIGNATURE----- --------------7fJerW2eTavEse5JA9lhZC5g-- From nobody Fri Dec 3 11:52:13 2021 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 AD70E18B207A; Fri, 3 Dec 2021 11:52:26 +0000 (UTC) (envelope-from yetoohappy@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5B5P3LfRz3MDG; Fri, 3 Dec 2021 11:52:25 +0000 (UTC) (envelope-from yetoohappy@gmail.com) Received: by mail-ed1-x52c.google.com with SMTP id e3so10506934edu.4; Fri, 03 Dec 2021 03:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=N1RrxuZI5oJwbw7RhQ5EepFQiFAbG5HPvWd/NFxMOF8=; b=QcG5ojayOGC8E9U6HEgBVCaHH+Prj/No9nru4mC+05UBb3CJqymgj+gVDGattj8Txa iW+EHYtfE07368s7+wZwRdm7VN5eJCd405fnENZl/l7goOgXC/fmdbtTJ9Ux6nQ2VEIB 7aUHjAsQVOpgPVbwFkotjdklfNjp5sSEapCk3Ofhh92Q8LkVLw8585CV36Apra5GNVnh eP+dva9wVWXSamxPrl8aMaIUDTrFxDMhZ0k7Jwb1hDAOnq/yiDW0wz+mgmrqSp9px7e0 4LVQDQ9CHZLqG5FoToFVvwGWkUzSVtz6FHTUp8NU0jjDIwuf0Tkp5QsfYsoJk8nePQP4 3aPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=N1RrxuZI5oJwbw7RhQ5EepFQiFAbG5HPvWd/NFxMOF8=; b=WG+9JQ8oAhVSsGff7kOy4ln+ZFN+7VOHeDCgEpYF+ZBzI76pm0rRzUBRSek8I6AsEg qKo3fUL/WhlRBZIfdots9iUaB+2usDAy/Rm656nu7Xa1UdfkTar80qpiEq5yTFhf8Jn6 r2/TDbycNThJLogH9TP8bjNpw/2X5qLs09oG1S8+jNNUcp3aGaK8U7L8j9LV5zbWxRyj L2x8mdCads4QFXlegKWCkNTlzpK3PIHqOPzZnQQpLJdax++YQt7mlcBc8wL8GYuxGuMG Xu32rVvgu1bK2pugs+/0XJhbpb7Me596h42zHPyf/02cdIoPWXO+pM1vs1/tmAF0jrC7 pgYA== X-Gm-Message-State: AOAM532CbyYWik8h99YCKs3bIwRnqnrVUpNjEK8qUFOVqKXyLi1HXaSW nutqYOfa48Iq8ZsUw/H8BMwRGO7lwAqDeGMTRoXcrKlx2ZqpiA== X-Google-Smtp-Source: ABdhPJyP3FalcvXCu32AfwiPlGZw05uPHNh9DgveuEnzqv0a7vs5Zv0I/00TOcjbDuZmbwou3OVeki/uRjOWzkiSCNk= X-Received: by 2002:a05:6402:50c6:: with SMTP id h6mr25202900edb.228.1638532344546; Fri, 03 Dec 2021 03:52:24 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Yetoo Happy Date: Fri, 3 Dec 2021 03:52:13 -0800 Message-ID: Subject: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook To: freebsd-doc@freebsd.org Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000005988d505d23c8a1c" X-Rspamd-Queue-Id: 4J5B5P3LfRz3MDG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=QcG5ojay; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yetoohappy@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=yetoohappy@gmail.com X-Spamd-Result: default: False [0.05 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.949]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --0000000000005988d505d23c8a1c Content-Type: text/plain; charset="UTF-8" In https://docs.freebsd.org/en/books/handbook/cutting-edge/ I can see that at* 24.5.6.1 Merging Configuration Files* are instructions to bootstrap etcupdate if switching from mergemaster. This is really convenient and really useful, *EXCEPT* for that fact that it is placed in a part of the handbook a little ways after installation would complete. The critical issue here being that, due to this information not being higher up, a user who is looking at the handbook to update from source and are trusting the handbook because they have faith that it won't play any dirty tricks on them, because all the documentation and all the user groups speak so highly of the handbook being complete and thorough and authoritative, are just going to* 24.5.1. Quick Start* and follow the instructions and get to step 7 and may think that even though etcupdate is different from mergemaster from the last time they used the handbook they have faith that following the instructions won't brick their system. This user will instead find that faith in general is just a very complex facade for the pain and suffering of not following *24.5.6.1 Merging Configuration Files* because the user doesn't know that step exists or relevant to the current step and ends up unknowingly having etcupdate append "<<<< yours ... >>>>> new" to the top of the user's very important configuration files that they didn't expect the program to actually modify that way when they resolved differences nor could they predict easily because the diff format is so unintuitive and different from mergemaster. Now unable to login or boot into single user mode because redirections instead of the actual configuration is parsed the user goes to the handbook to find out what might have happened and scrolls down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. Completing the Update*. What a mocking section? Completing the update? How could I have completed the update if I was on Step 7 of Quick Steps? The user now may feel cheated, jaded, or insulted and wonder what the fuss is all about with this hyped documentation. Here's a solution: Make a red warning notice at the very top of *24.5.1. Quick Start* and refer to *24.5.6.1 Merging Configuration Files *and make clear this is for step 7. Another solution is, if possible, put that red warning notice next to step 7 or step 7 in the grey section or red/pink section of the quick start box area, I personally would prefer a warning with text right next to step 7 in the red/pink part of the quick start box, but I'm not sure if that's possible or respecting the documentation design paradigm. The next best option is a warning at the top because it reduces the chance of a user following instructions and missing that step because they haven't scrolled to that point yet. I'm sorry if this comes across as an angry potentially combative message, but I just wanted to make clear where and what the problem is and my frustration with this problem. --0000000000005988d505d23c8a1c-- From nobody Fri Dec 3 12:58:39 2021 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 7FF5018B0E59; Fri, 3 Dec 2021 12:58:50 +0000 (UTC) (envelope-from SRS0=W9n4=QU=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4J5CZ22P9Gz3vfy; Fri, 3 Dec 2021 12:58:50 +0000 (UTC) (envelope-from SRS0=W9n4=QU=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B3B8F28416; Fri, 3 Dec 2021 13:58:41 +0100 (CET) Received: from illbsd.quip.test (ip-78-45-215-131.net.upcbroadband.cz [78.45.215.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 8E0ED28411; Fri, 3 Dec 2021 13:58:40 +0100 (CET) Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook To: Yetoo Happy , freebsd-doc@freebsd.org Cc: freebsd-current@freebsd.org References: From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> Date: Fri, 3 Dec 2021 13:58:39 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J5CZ22P9Gz3vfy X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 03/12/2021 12:52, Yetoo Happy wrote: [...] > Quick Start* and follow the instructions and get to step > 7 and may think that even though etcupdate is different from mergemaster > from the last time they used the handbook they have faith that following > the instructions won't brick their system. This user will instead find that > faith in general is just a very complex facade for the pain and suffering > of not following *24.5.6.1 Merging Configuration Files* because the user > doesn't know that step exists or relevant to the current step and ends up > unknowingly having etcupdate append "<<<< yours ... >>>>> new" to the top > of the user's very important configuration files that they didn't expect > the program to actually modify that way when they resolved differences nor > could they predict easily because the diff format is so unintuitive and > different from mergemaster. Now unable to login or boot into single user > mode because redirections instead of the actual configuration is parsed the > user goes to the handbook to find out what might have happened and scrolls > down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. [...] That's why I think etcupdate is not so intuitive as tool like this should be and etcupdate is extremely dangerous because it intentionally breaks syntax of files vital to have system up and running. If anything goes wrong with mergemaster automatic process then your have configuration not updated which is almost always fine to boot the system and fix it. But after etcupdate? Much worse... I maintain about 30 machines for 2 decades and had problems with etcupdate many times. I had ti use mergemaster as fall back many times. Mainly because of etcupdate said "Reference tree to diff against unavailable" or "No previous tree to compare against, a sane comparison is not possible.". And sometimes because etcupdate cannot automatically update many files in /etc/rc.d and manual merging of a lot of files with "<<<< ==== >>>>" is realy painful while with mergemaster only simple keyboard shortcuts will solve it. All of this must be very stressful for beginners. So beside the update of documentation I really would like to see some changes to etcupdate workflow where files are modified in temporary location and moved to destination only if they do not contain any syntax breaking changes like <<<<, ====, >>>>. Kind regards Miroslav Lachman From nobody Fri Dec 3 13:30:01 2021 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 6961118C0D77 for ; Fri, 3 Dec 2021 13:30:03 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5DG32B4Sz4ZKc for ; Fri, 3 Dec 2021 13:30:03 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x72e.google.com with SMTP id g28so3315800qkk.9 for ; Fri, 03 Dec 2021 05:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UXnNtonbFkc78oPg5dPDRrqYFKoMq+gzkjEXdMC0f3c=; b=BDeJYCrEom4WWIzO20OboAE9+EFbUhvx5rvyxTyejLk0wOq0epDEfyNRUF39RLyTBv ZC+S6RJMoo/CfnfIibZa7uNwaVUH8HNfMHK7LsHsr/V3PaLJAWFCiPHsqCp3lMB6ZhF3 UvQEoYzZoCFDg+ooObPk66ReoR/zPYWBVShcA7qtuvJ/WYWp/cbTO6Lhi9Wc2Ov0e14C 1/L+ZsxlF5+i3B6CssMmrB7BCsoqi82EbGT/RprX77IQuG+TxdMOSrpZeVb3DdbH7dWz z83AnZZxivypGUiYEe2m9naJfoo6KSWQ/DLJS5nE04o1EVvmeIeSsu/KioEPBrNyn3JO FuDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UXnNtonbFkc78oPg5dPDRrqYFKoMq+gzkjEXdMC0f3c=; b=qxHD6/eDDgsSDr4zRjINK5+ayYLvX9B8COrMsvJikz0UoxtQKgp91oxMf36JXfci3Y zhERwgoKPN4qgnqsfAjLAbLpa5O9lUMLlu1J+fUoG5kn//lQQ6H+OhLvC4zmlpxFfn1B IQjf4h9Qg0gpMoyE2ymhzwpDGA8Nh0BMeWVuaxku4X8YouL8tOQqaUA+glVuFQyk+z39 m7Zd9T0kJn772eVkWujMNew1GXgZlXIYl0YLExkLaSSLVl/9wpubN/RI28phF5K6mFZW lG/oxR5YcknWvovBVHtY+A9xgZedTqIhcCbpmgYAmHeDXgCtPFZqcLWu+sh263zQdxyX 5GRQ== X-Gm-Message-State: AOAM5304V+9ZIhGgCKQVnSdruAdaT66ZSv8A0aU2q6+jKzcJFnfiN/J8 aFEqUu0hpZL6G6zWFhqp6Smj3Ag/9fBrDSOO X-Google-Smtp-Source: ABdhPJwG9thu5vEuHQLp2uvMKRMAe+NeS5CM5HTda96fMwRDNUPrkNz3Bygu8rt7iinKGL6k9qLpVA== X-Received: by 2002:a05:620a:248a:: with SMTP id i10mr17252350qkn.554.1638538202756; Fri, 03 Dec 2021 05:30:02 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id t11sm1935997qkm.96.2021.12.03.05.30.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Dec 2021 05:30:02 -0800 (PST) Date: Fri, 3 Dec 2021 08:30:01 -0500 From: Shawn Webb To: Stefan Esser Cc: FreeBSD CURRENT Subject: Re: [REVIEW] Hide BIT_* macros from userland code Message-ID: <20211203133001.scaxfsnjy7voast6@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <7d97e129-4aa7-aa98-dc91-e332a3da620f@freebsd.org> <20211202164648.276kuh3blin6b2wp@mutt-hbsd> <77845d03-6351-8a8b-2eae-1db98f8a192c@freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qymcuzu56lw4m24j" Content-Disposition: inline In-Reply-To: <77845d03-6351-8a8b-2eae-1db98f8a192c@freebsd.org> X-Rspamd-Queue-Id: 4J5DG32B4Sz4ZKc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --qymcuzu56lw4m24j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 03, 2021 at 11:03:54AM +0100, Stefan Esser wrote: > Am 02.12.21 um 17:46 schrieb Shawn Webb: > > Hey Stefan, > >=20 > > On Thu, Dec 02, 2021 at 05:26:55PM +0100, Stefan Esser wrote: > >> I have created > >> > >> https://reviews.freebsd.org/D33235 > >> > >> to remove the BIT_* macros used in the kernel from the userland API. > >> > >> They conflict with differing definitions in some 3rd party code and > >> lead to compile issues in a number of ports (via CPU_* macros based > >> on the BIT_* macros). > >> > >> See PR259787 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259787 > >> for an example of such a problem. > >=20 > > I recently was in a position to evaluate BIT_* macros for userland > > use. It was around the time when the conversation regarding hiding > > BIT_* from userland, which conversation caused me to find another > > solution. > >=20 > > I think such an API is incredibly useful, so I wonder if there's a way > > to satisfy both. For example, maybe prefix the userland side with a > > USERLAND_ or something similar? Kernel would use BIT_* and userland > > would use USERLAND_BIT_* (just spitballing, not actually advocating > > for "USERLAND_BIT_*" but rather just the idea of it.) >=20 > Hi Shawn, >=20 > I have updated the patch set in review D33235 and have added you to > the reviewer list. >=20 > IMHO the approach proposed by Konstantin Belousov is better than the > introduction of prefixed macro names for the userland. >=20 > A simple #define _WANT_FREEBSD_BITSET makes the __BIT* macros available > by their traditional names, no other changes are required in the code. >=20 > This does not solve the potential case of a program that wants to use > both the BSD and GLIBC variants of the macros in a single source file. > But I think that such a case is constructed and does not occur in > actual code. >=20 > And in any case, the IMHO __BIT* names are as good as the USERLAND_BIT* > names you suggest (and I understand that you did not want that specific > name - therefore a prefix of __ might be considered to match what you > proposed ;-) ). >=20 > And you are of course free to map __BIT* to any other prefixed name in > a header file in your code ... >=20 > An update of the bitset(9) man page might be a good idea, explaining > the visibility rules and _WANT_FREEBSD_BITSET for system utilities that > need to work with kernel style bitsets. Awesome. kib's suggestion makes sense here. And thanks for adding me to the review. I'll make sure to pay attention as it progresses. :-) Thanks again, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --qymcuzu56lw4m24j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmGqG9kACgkQ/y5nonf4 4fo+vA/7B48h4Dk5YDfATIpbnQEb7yDPSpLDjJxRwKijpsE+QfLQXHzXpXybMfxB 6xlHdCC+O1XnoQwMy8A/ZCulvNtRT+0l70cElhuXNiay/KHF7Q1XGYpFvOd01FRK qP9QC8s+lFehyn30kzdDChqegN9OPLwz9u6miQmX5qLyb0KSzJjFSA31mNPF8Fqy aMUmAiSWuR52AMgkpuR2lNTIzxDf7VrE+wFutoVXVG0OYxfzh4tst6zuzG/Tc4fh HbcS8gjuVq8jv5nCbYXa4umdXfLCzvt4kHLh7GUpTpx/ZuBUF6ClIQfiZE6llS/4 zVRAEasWuAOwIc6C/BT2/ZuEpfXohP1bqwrVnCexexYIVySh7I2y6+udMFnLwt73 vxHrtTwhbZeTGRHYvvglO3Jj7cRY1Q7bdM6Uih/Rc1HTKFIG/7p7ARdMY1nkr+VH lxBSLPdATOCSS1NYlTXzvRwk8oQACorBqQmqoB2p9+YclJoIEtb+JiZPYTQvXBQL ujWjT0ebc4ZRZoGLAp92rgGuPGGmsi4mHx13yXSlew7K8hXhJjeCC71/JWMnGM5h moDuetLnjJ8uwM5/oRVyigyA641gJb3lwMjYezfCiBKTwTBUKvJwD1kRjZY6r7Uv eWZoeRLKvGb0w+EppNXCmZEzJxOZtCLfuAyCthwSyMlVvUPTDic= =KuU3 -----END PGP SIGNATURE----- --qymcuzu56lw4m24j-- From nobody Fri Dec 3 13:54:37 2021 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 DD56518CD09B; Fri, 3 Dec 2021 13:54:47 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from transit01.runbox.com (transit01.runbox.com [91.220.196.211]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5Dpb5V5vz4kHr; Fri, 3 Dec 2021 13:54:47 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by transit01.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1mt91L-00386M-Pi; Fri, 03 Dec 2021 14:54:39 +0100 Received: from [10.9.9.129] (helo=rmmprod07.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1mt91J-0006nd-UD; Fri, 03 Dec 2021 14:54:38 +0100 Received: from mail by rmmprod07.runbox with local (Exim 4.86_2) (envelope-from ) id 1mt91J-0002Cl-Sx; Fri, 03 Dec 2021 14:54:37 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline 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 Received: from [Authenticated alias (650894)] by runbox.com with http (RMM6); Fri, 03 Dec 2021 13:54:37 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "Miroslav Lachman" <000.fbsd@quip.cz> CC: "Yetoo Happy" , "freebsd-doc" , "freebsd-current" Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook Date: Fri, 03 Dec 2021 05:54:37 -0800 (PST) X-RMM-Aliasid: 650894 X-Mailer: RMM6 In-Reply-To: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> Message-Id: X-Rspamd-Queue-Id: 4J5Dpb5V5vz4kHr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.fbsd@quip.cz> wrot= e: > On 03/12/2021 12:52, Yetoo Happy wrote: >=20 > [...] >=20 > > Quick Start* and follow the instructions and get to step > > 7 and may think that even though etcupdate is different from mergemaster > > from the last time they used the handbook they have faith that following > > the instructions won't brick their system. This user will instead find = that > > faith in general is just a very complex facade for the pain and sufferi= ng > > of not following *24.5.6.1 Merging Configuration Files* because the user > > doesn't know that step exists or relevant to the current step and ends = up > > unknowingly having etcupdate append "<<<< yours ... >>>>> new" to the t= op > > of the user's very important configuration files that they didn't expect > > the program to actually modify that way when they resolved differences = nor > > could they predict easily because the diff format is so unintuitive and > > different from mergemaster. Now unable to login or boot into single user > > mode because redirections instead of the actual configuration is parsed= the > > user goes to the handbook to find out what might have happened and scro= lls > > down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. >=20 > [...] >=20 > That's why I think etcupdate is not so intuitive as tool like this=20 > should be and etcupdate is extremely dangerous because it intentionally=20 > breaks syntax of files vital to have system up and running. > If anything goes wrong with mergemaster automatic process then your have= =20 > configuration not updated which is almost always fine to boot the system= =20 > and fix it. But after etcupdate? Much worse... >=20 > I maintain about 30 machines for 2 decades and had problems with=20 > etcupdate many times. I had ti use mergemaster as fall back many times.=20 > Mainly because of etcupdate said "Reference tree to diff against=20 > unavailable" or "No previous tree to compare against, a sane comparison=20 > is not possible.". And sometimes because etcupdate cannot automatically=20 > update many files in /etc/rc.d and manual merging of a lot of files with= =20 > "<<<< =3D=3D=3D=3D >>>>" is realy painful while with mergemaster only sim= ple=20 > keyboard shortcuts will solve it. > All of this must be very stressful for beginners. >=20 > So beside the update of documentation I really would like to see some=20 > changes to etcupdate workflow where files are modified in temporary=20 > location and moved to destination only if they do not contain any syntax= =20 > breaking changes like <<<<, =3D=3D=3D=3D, >>>>. >=20 > Kind regards > Miroslav Lachman Agree. I fell back to mergemaster this Nov on 13-stable when the /var files pertaining to etcupdate were all missing current /etc data, and no study of man etcupdate was clear enough to rectify such a scenario, and suspect my initial use of etcupdate will or may require a planned reinstall, not havi= ng had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and=20 I am just hoping mergemaster stays in /usr/src and updated=20 for system changes, even if moved to 'tools' or something, since its use seems intuitive and much less of a black box.=20 Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still.= =20= From nobody Fri Dec 3 15:58:47 2021 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 6F06218BB6D9; Fri, 3 Dec 2021 15:58:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5HYl1S23z3hw2; Fri, 3 Dec 2021 15:58:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd2f.google.com with SMTP id p65so4311079iof.3; Fri, 03 Dec 2021 07:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=JtnYamK5EINneJgn39csNR5ivJjfVMEFy2DyjPAeaQo=; b=ZiJN/RsUwdBWNB8RgfYadbHAT/BUWritGh+nV8bDIoxnz101rjQ/LRf8M0WTZxy0Yh tVhrbqUoP4g3Y58IdRw2EPEzzCdlJkr7REMLm46v96Hvd8lvn61bA7+h8CIwAjR9ipSZ XfKMPhAJUYVDt3mJZFZbp51Zt09ByISwWifob2BJPtCmS49tvQPo40P9dEq9pf6DaYyS GVURKAAuUTQYjLrN1sMALqlulnS0rkos6zy7dhghZhdOp7SPmhRXMKoiceGmLzN/ubeK N5yZbaje5MC7LjElqV2iuILdV85vzTMUkELJN6srsl+fMcWQjxjujUSgm77jmHU7TgfR GgKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=JtnYamK5EINneJgn39csNR5ivJjfVMEFy2DyjPAeaQo=; b=ImSIF+EZs4NgvjYdzVL2aE5i9aMjdFhD1ygThYyk4qXdVMlEWVHjG4OGP+Zt858Akh zhS0BVtNBztQWq92WhlAJi5QkYkScdfvrYxUT9JzvV9Sox4NznHh3CYZb3eSol6hB59d cSpTkFH1gubM0ppiEzbBp8OVxLAD3Rl5KVAbgBbHL8Oj7PX1umMysGIgR0a6OvxVnkhB 5r4EW5rk6p4zHXZtVRjE5jPx2ypzTXyPb/egrUdUCaok31dsyQaMPTWHbMv79eELd0pz a4gnzRqgwtK40PmSbHp3bK495YKXsvWnzywNsnsharCshIPJmHJUH6IWYh1mF1vKYMMZ FTag== X-Gm-Message-State: AOAM532wEu6tLO2nN1f4gH9sjk7ohaJ6o97xeBAspHCS6meSKintxre2 UWxmpQGWG6rg+ErylyxKmhN1+HTb4e13YQ== X-Google-Smtp-Source: ABdhPJzyFLGjLe1FxGaW5uvRrf4v7qO6U7vYUnjF7dCuWUhp8VyHfnwK9btiLFktxLkaE3DSmzCEoA== X-Received: by 2002:a05:6602:26d3:: with SMTP id g19mr19125009ioo.100.1638547130342; Fri, 03 Dec 2021 07:58:50 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id r18sm1753041ilh.59.2021.12.03.07.58.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Dec 2021 07:58:49 -0800 (PST) Date: Fri, 3 Dec 2021 10:58:47 -0500 From: Mark Johnston To: marklmi@yahoo.com Cc: Free BSD , freebsd-current Subject: Re: FYI: aarch64 main [so: 14] buildkernel (debug): ctfconvert: failed to get mapping for tid ????? Message-ID: References: <47D56092-308F-42DD-94A7-5CA9F3ED6997.ref@yahoo.com> <47D56092-308F-42DD-94A7-5CA9F3ED6997@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47D56092-308F-42DD-94A7-5CA9F3ED6997@yahoo.com> X-Rspamd-Queue-Id: 4J5HYl1S23z3hw2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="ZiJN/RsU"; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d2f as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-1.12 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; SUBJECT_HAS_QUESTION(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.57)[0.572]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2f:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Nov 29, 2021 at 06:45:19PM -0800, Mark Millard via freebsd-arm wrote: > For: > > uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 > > building a variant of itself (producing a debug build instead of a > non-debug), it generated a bunch of messages of the form: > > ctfconvert: failed to get mapping for tid ????? > > in the buildkernel part of the build. Can you share the kernel configuration GENERIC-NODBG-CA72? From nobody Fri Dec 3 17:19:00 2021 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 1E89D18C4CB5 for ; Fri, 3 Dec 2021 17:19:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5KLX60Y1z4kWY for ; Fri, 3 Dec 2021 17:19:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638551949; bh=XY9CV9tXosZPKcG9dPY8pz80mYluSLT2amSBP26KTnE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=p5fpkfyCiL3KU4Mjh/cIEOIXwdTnBiglEcZKQKrJbY9Mz3iTm4wN+uZQTk5AMiYqqDvYCDxtvoqP9LlWyOo94/DzDhOgBZF4hr6HWg4PgmzWbiOzlu1tfZt1Bnkk1e66A0kamRBEzxslikqX0K2Pg+n0dBvmexQNR4RUa6EQamRIztFaCD5Klhy4gfvivSaLgRfZoZ3znR90Rgjf92peCmWMEeMQvhxnOOaNoZ1m8MCRjxwp7uIxTtoitmB8CKaT7PL9aXX4oblQKfDvuLBwiC3XkOrrzuz+mh/7cxepkN8U76ocCwrVwwvI2ZiDVPe4TDOt+B3/LgGJY3tmpppbjw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638551949; bh=8csRG4VMsrJ0Zc5c4iPjTPATRB82180NKiMZ63mEti4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=L31NV7NjVRk9+tzxCbeqGmvCErvKemb8QIZQ56Nb0m/yRGWnoYVLHPs6YLMnqBEzsmXx0lZ9aRGRwbGyelb/MNGu4mSF90rkO5kCeJy36V7PSAYJk7PFzxfxVTOe9faSdar1eJhgpNysm6B2gbr7tZ/qSlOPKVhG0e2J1pjishk6sse9v1YMFtn0oy54ATifhUzT2w7Pups6ec70+c20j5EGDrlDKNPpvuTEQhvDNNf8oAvMbo2M3uXzVpKq3gOiqh101APcLis0E6PriJ3/4Tzd20uW1dJblBe0c4ve7DQHx4Q33ns93WmLrTj+1aYjlzgVZACOKHGilwkmDyAF0g== X-YMail-OSG: Eyg0lwEVM1mzdoKYSXwJyn9zZszsBKtRqJcmW8BGYPl1CX71Bj28wpDEfYfkamv dV.bkI5CX76L5yr06sNWxqPnBu3WEGKchB.uRnCP.6Yg_HCzcqrSF.4Z.su23QR7zapz_atq9.Th I3U7Dhvlr7O8RoKh8rR6owmyksye4Vr08mX3SZUUmlIFSaNh7FVrc1T0.vRJaQ8_CDX_Fes6dg4S prGBFd.Ywvw3jLOQHyAoEfXOnsln01JlmqELFUKfFQGYbzcmvnfL3YTb2Tmdjbm_SnqtEY5y8ATC v5khNfpxo5rObD79jW7u_c8coJC8yCJJdmIhv24Lj0Z6Q5csh.3nK2FKAwfsykLF6EHx1m7JKqSY wkO1faSd5WEsDnLB5syja6gcKatXZmtuFGhUuPRIsrOoTJirNWhiY6ARblvOaIjH2dnMW5C0qa_o Z6DXl1I0Ax7RPkAmXkNgJZL05xIStlZZuSpMND4AIbfZij9d_jm30J5uR4w.2jd91P1EshGD7rTN uLOyIKBS41QxFJ4xkWnbb1KNS86RR3GEOPVmkQXWuMCzGfBmSn9UcBNp.M.xGEnRyRtdebXBlDrk g5hGZvrkNkykOFnr1QnZcCpKUoginxfgj.liYZGy7eRDPSRrzy2W7itCkYw7WXg1myLXCAgXDQDI TtgxKAjohoxBPirLpWX_qMrQGHY6SIwGyI5pNlZFRbGHSrS6jdEAiR1pbSpt_Um0oWrtiomwxkpa Z1rV4aE1tXQDHMYJOQrnxXYg2w54lWOGbH25dh7rkYo01ncyN6rXpPHIqsNTwQG3lZQ137UB8dbQ SbHI1e9_Fs6q0yH.2UCzWO_OPydmTWjF8wZGuazaA14xm.rLJlkXof1HQNMZTl1dbhFumBCUHlCa YcqNT2YBfqXlahnwvFAYzrsvM9DYwEl9ebHLuUJqB.bckxlijr_vkTrCExaSkt_bGKhG2yRW7jAk d_qTuiY6heVtv_rMRAMkUPEcPS6FHlVkZUOXveRhn3SHL5YwvxUv3cxIGC0vzUijK4NlVMtGW_pq ZNewMk_aD49jEWMIFORWzzT31rSPgL56JE3cRgKGPCUz8gEf2I_C4dsNZ4f87M3xN5CwO.x02EjL A7I9Fm0fG7alJCq47QOmItbBOS3udS1wBpiCI1mx_E1f6ZfFg7xa6c9MBaygUcIb2sQamtVIFSKI GVQY9MrygCSFg2ZtQY9hz8Pn759dxpq9yPyQAH1WXezv59rwS7MUsVAGw.HMlelFymSyVheCF1YT 3VwqavL1ZPuHZk9vyMovQvc4cZfVaZBgDfYhMTS3f5bM7i81I9h7Ccyt1SPUltQwYtwaaEBo3HQk HCHo11Dle_BzTq52.55zAg8SKx5jMWWsuBwomkXrW_crzOgQ3C2wvdf2bnH49INaR0N.qZ98eO89 5Lr1K.qLtsB9xLeD4MbgHwn6Lu230wX06BDSsP0EjxnJmNmanGBFuX.fBISyWS2299dyDfW3eNeL vBHhRrdWBI.kCfKLGIp3ZuICsGCta3b3V0QyTYP44LKPKqrF.xs9U4hjiot35PLmGebXMUXK67Lr bDbqsJfVxWOP.qSU9kF3YmwjwQx8jI0hMS.LO_ksPvXZWCyw2Z0YE7vntn9_SVqExD9dR1ZVAlL0 T_QRP9RpDAqM7QkI5zYGUYEyvbhCBYfzn8G.zYODlv28MegLZxMxJBT_FfPOW.MDSzJB1oRM8u_i 9v_Is6kRFe3uAHAPLx0f2dpgplIqJnzyhCxl4tYKR9YLTA5MdXr4sAsydFEzeyhkHFWw6Lbsbu_v J3OcR0.VCL2OVbsVooHNhzXlK15nkjkTSTKuMz2SsuQFEmYRNXgxY5LMg7zNTUSTi9eUo7T_gdR2 SorNhZBsnl7y27f5hYI7sQF87Lr1cKSV4vzWFllYh37sBqBh.WKI.HUKB1w1h8MpXYc63EzqX.6k aANSq2bJi9RtEy7HIc9RuhwxSDwDtUOmwO8j400tzfpZAAuTmDf5ddjL1ZIp7VGwkKtZ39Ecqrxv 8O6BRgSHP3ss9Oi6RIkEvSlw4oSFL0nY3cj32BPUlD9FZmUPHZWebAKDYeaXNW1XHPTjC2tj3l4A k29Z1uhBeDuvfCUj2bH3Uz5JLHF5IE2HKxwIy_tpJMz1EbiPz2LkLuRRSWjzugiPMs6I7C0hfaDl PjuneuxW0GyxjDtZYgOyHF.84utbO.pbUewGpBNCIoi_a1AO5OrEaPHexE.Y5DWaaRyC9caaliuq IMhkiLlb7m7o0U9JQcRO523vJq.4GM104jQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 3 Dec 2021 17:19:09 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4fc935d7ace6d512ba6713a0b6bc5976; Fri, 03 Dec 2021 17:19:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: FYI: aarch64 main [so: 14] buildkernel (debug): ctfconvert: failed to get mapping for tid ????? In-Reply-To: Date: Fri, 3 Dec 2021 09:19:00 -0800 Cc: Free BSD , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <4F851A07-46F6-40E3-B1F2-D18BD873E4E3@yahoo.com> References: <47D56092-308F-42DD-94A7-5CA9F3ED6997.ref@yahoo.com> <47D56092-308F-42DD-94A7-5CA9F3ED6997@yahoo.com> To: Mark Johnston X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J5KLX60Y1z4kWY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-3, at 07:58, Mark Johnston wrote: > On Mon, Nov 29, 2021 at 06:45:19PM -0800, Mark Millard via freebsd-arm = wrote: >> For: >>=20 >> uname -apKU >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>=20 >> building a variant of itself (producing a debug build instead of a >> non-debug), it generated a bunch of messages of the form: >>=20 >> ctfconvert: failed to get mapping for tid ????? >>=20 >> in the buildkernel part of the build. >=20 > Can you share the kernel configuration GENERIC-NODBG-CA72? >=20 Sure. The environment doing the building was built using: # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG-CA72 include "GENERIC-NODBG" ident GENERIC-NODBG-CA72 makeoptions CONF_CFLAGS=3D"-mcpu=3Dcortex-a72" and . . . # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT=3D0 # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING As for the variant being built: # more /usr/main-src/sys/arm64/conf/GENERIC-DBG-CA72 include "GENERIC-DBG" ident GENERIC-DBG-CA72 makeoptions CONF_CFLAGS=3D"-mcpu=3Dcortex-a72" # more /usr/main-src/sys/arm64/conf/GENERIC-DBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-DBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT=3D0 # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP|KTR_PROC ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Enable any extra checking for. . . options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity = checking options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS options WITNESS # Enable checks to detect = deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC options MALLOC_DEBUG_MAXZONES=3D8 # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Dec 3 18:35:01 2021 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 242FA18C1550 for ; Fri, 3 Dec 2021 18:35:23 +0000 (UTC) (envelope-from evgeniy@khramtsov.org) Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f]) (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 4J5M2L0gvYz3Ngd; Fri, 3 Dec 2021 18:35:19 +0000 (UTC) (envelope-from evgeniy@khramtsov.org) Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f]) by mxa.khramtsov.org (Postfix) with ESMTP id 852761260CD; Fri, 3 Dec 2021 18:33:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khramtsov.org; s=rsa; t=1638556416; 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; bh=kZ8yAYI2+oOfhAzabLh9MKvGm2N+3xrgI6Voqpy7Jrw=; b=La8+mCYBfGvuXzNDOJ3BqOzhi/5l4bAwAZjfJ2Ha21pRS3R1MQ7Vo7Vgfo52lJf9F1EnDO yChaYntW1WoVF9W6dP76bypbv2j2GRmaAuwAS241x13w36ghtSkNJYPOSmGToeOfZHFcGH Mw6gJ8KPQeNoM0n0H7j5RWrTIRv/4ZDgldy0GYpAm3LuoMiIlZFODLpWFISEFG2JOirqkC scU9aHwHVGpdI76L2McTaVLaK0DX2kUCoU7Z59nLrwu9dwB6X9QzQyozT5FLRrbdFJB+Kj dJpNyTpJ2V+bEIGJS+rUAiFh5HAYe95xq6oyiODUVGrUy43vLzx1zydrHM9KjQ== Date: Fri, 3 Dec 2021 21:35:01 +0300 To: FreeBSD-CURRENT@FreeBSD.org Cc: Kirk McKusick Subject: lib/libufs: build regressed after b366ee486 Message-ID: <20211203183501.zyroidvh3t4kk2g7@vax.khramtsov.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 X-Rspamd-Queue-Id: 4J5M2L0gvYz3Ngd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=khramtsov.org header.s=rsa header.b=La8+mCYB; dmarc=pass (policy=reject) header.from=khramtsov.org; spf=pass (mx1.freebsd.org: domain of evgeniy@khramtsov.org designates 2a0a:e5c0:2:10f::f as permitted sender) smtp.mailfrom=evgeniy@khramtsov.org X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[khramtsov.org:s=rsa]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a0a:e5c0:2:10f::f]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[khramtsov.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[khramtsov.org,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:207996, ipnet:2a0a:e5c0:2::/48, country:CH]; ONCE_RECEIVED(0.10)[] Reply-To: evgeniy@khramtsov.org From: Evgeniy Khramtsov via FreeBSD-CURRENT X-Original-From: Evgeniy Khramtsov X-ThisMailContainsUnwantedMimeParts: N I was updating from commit 20aa359773befc8182f6b5dcb5aad7390cab6c26 Author: Dimitry Andric Date: Sat Nov 13 21:02:29 2021 +0100 Bump __FreeBSD_version for llvm-project 13.0.0 merge PR: 258209 MFC after: 2 weeks to commit b366ee4868bca2b3ebe4bb29c9590a29b6cecc29 (main) Author: Kirk McKusick Date: Sun Nov 14 22:09:06 2021 -0800 Consolodate four copies of the STDSB define into a single place. The STDSB macro is passed to the ffs_sbget() routine to fetch a UFS/FFS superblock "from the stadard place". It was identically defined in lib/libufs/libufs.h, stand/libsa/ufs.c, sys/ufs/ffs/ffs_extern.h, and sys/ufs/ffs/ffs_subr.c. Delete it from these four files and define it instead in sys/ufs/ffs/fs.h. All existing uses of this macro already include sys/ufs/ffs/fs.h so no include changes need to be made. No functional change intended. Sponsored by: Netflix $ cd lib/libufs $ make [...] /usr/local/llvm13/bin/clang -O2 -pipe -fno-common -D_LIBUFS -I/usr/src/lib/libufs -g -gz=zlib -MD -MF.depend.sblock.o -MTsblock.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c sblock.c -o sblock.o sblock.c:59:38: error: use of undeclared identifier 'STDSB' if ((errno = sbget(disk->d_fd, &fs, STDSB)) != 0) { ^ 1 error generated. *** Error code 1 Stop. make: stopped in /usr/src/lib/libufs [...] My environment is custom (hard to bisect at the moment), but the most major local modification to base that I have is devel/llvm13 as toolchain. make.conf: LLVM=/usr/local/llvm13/bin ADDR2LINE=${LLVM}/llvm-addr2line AR=${LLVM}/llvm-ar AS=${LLVM}/llvm-as CC=${LLVM}/clang CPP=${LLVM}/clang-cpp CPPFILT=${LLVM}/llvm-cxxfilt CXX=${LLVM}/clang++ DTRACEFLAGS+=-x cpppath=${CPP} -x ldpath=${LD} LD=${LLVM}/ld LLVM_LINK=${LLVM}/llvm-link NM=${LLVM}/llvm-nm OBJC=${LLVM}/clang OBJCOPY=${LLVM}/llvm-objcopy OBJDUMP=${LLVM}/llvm-objdump RANLIB=${LLVM}/llvm-ranlib READELF=${LLVM}/llvm-readelf SIZE=${LLVM}/llvm-size STRINGS=${LLVM}/llvm-strings STRIPBIN=${LLVM}/llvm-strip STRIP_CMD=${STRIPBIN} src.conf: WITHOUT_CLANG=yes WITHOUT_CLANG_BOOTSTRAP=yes # elftoolchain utils manually deleted, todo: have a knob to turn off build WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=yes WITHOUT_LLD=yes WITHOUT_LLDB=yes WITHOUT_LLD_BOOTSTRAP=yes WITHOUT_LLVM_COV=yes From nobody Sat Dec 4 02:09:42 2021 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 AF54A18B98C5 for ; Sat, 4 Dec 2021 02:09:54 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5Y6p2GJ4z3slm for ; Sat, 4 Dec 2021 02:09:53 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 1B429hZt096960; Sat, 4 Dec 2021 11:09:44 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 4 Dec 2021 11:09:42 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: jbtakk@iherebuywisely.com Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook Message-Id: <20211204110942.11553b693b165364f3ab31c0@dec.sakura.ne.jp> In-Reply-To: References: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J5Y6p2GJ4z3slm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 03 Dec 2021 05:54:37 -0800 (PST) "Jeffrey Bouquet" wrote: > > > On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.fbsd@quip.cz> wrote: > > > On 03/12/2021 12:52, Yetoo Happy wrote: > > > > [...] > > > > > Quick Start* and follow the instructions and get to step > > > 7 and may think that even though etcupdate is different from mergemaster > > > from the last time they used the handbook they have faith that following > > > the instructions won't brick their system. This user will instead find that > > > faith in general is just a very complex facade for the pain and suffering > > > of not following *24.5.6.1 Merging Configuration Files* because the user > > > doesn't know that step exists or relevant to the current step and ends up > > > unknowingly having etcupdate append "<<<< yours ... >>>>> new" to the top > > > of the user's very important configuration files that they didn't expect > > > the program to actually modify that way when they resolved differences nor > > > could they predict easily because the diff format is so unintuitive and > > > different from mergemaster. Now unable to login or boot into single user > > > mode because redirections instead of the actual configuration is parsed the > > > user goes to the handbook to find out what might have happened and scrolls > > > down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. > > > > [...] > > > > That's why I think etcupdate is not so intuitive as tool like this > > should be and etcupdate is extremely dangerous because it intentionally > > breaks syntax of files vital to have system up and running. > > If anything goes wrong with mergemaster automatic process then your have > > configuration not updated which is almost always fine to boot the system > > and fix it. But after etcupdate? Much worse... > > > > I maintain about 30 machines for 2 decades and had problems with > > etcupdate many times. I had ti use mergemaster as fall back many times. > > Mainly because of etcupdate said "Reference tree to diff against > > unavailable" or "No previous tree to compare against, a sane comparison > > is not possible.". And sometimes because etcupdate cannot automatically > > update many files in /etc/rc.d and manual merging of a lot of files with > > "<<<< ==== >>>>" is realy painful while with mergemaster only simple > > keyboard shortcuts will solve it. > > All of this must be very stressful for beginners. > > > > So beside the update of documentation I really would like to see some > > changes to etcupdate workflow where files are modified in temporary > > location and moved to destination only if they do not contain any syntax > > breaking changes like <<<<, ====, >>>>. > > > > Kind regards > > Miroslav Lachman > > > Agree. I fell back to mergemaster this Nov on 13-stable when the /var files > pertaining to etcupdate were all missing current /etc data, and no study of > man etcupdate was clear enough to rectify such a scenario, and suspect my > initial use of etcupdate will or may require a planned reinstall, not having > had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and > I am just hoping mergemaster stays in /usr/src and updated > for system changes, even if moved to 'tools' or > something, since its use seems intuitive and much less of a black box. > Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still. > Not sure it's fixed or not (tooo dangerous to try...), -n (dry-run) option of etcupdate is now quite harmful. Maybe by any commit done in this april on main (MFC'ed to stable/13 in june). *I got busy manually checking and applying changes to /etc, and forgot to file PR. Doing `etcupdate -n` itself runs OK, but following `etcupdate -B` does NOT do anything, hence nothing is actually updated. The only workaround I have is NOT to try dry-run. It would be because the same trees are used for dry-run and actual run. (Not looked into the code. Just a thought.) Maybe using dedicated trees (older one is copied from actual current one, building current tree on dedicated place and delete them every time the dry-run finishes) for dry-run would fix. And copying /etc to some temporary place and applying changes to it, copy back to /etc may be help for your issue, I think. -- Tomoaki AOKI From nobody Sat Dec 4 07:20:41 2021 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 C19A618CA1DB for ; Sat, 4 Dec 2021 07:20:58 +0000 (UTC) (envelope-from evgeniy@khramtsov.org) Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f]) (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 4J5h1j4fm6z4pJs for ; Sat, 4 Dec 2021 07:20:57 +0000 (UTC) (envelope-from evgeniy@khramtsov.org) Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f]) by mxa.khramtsov.org (Postfix) with ESMTP id 308871260CD; Sat, 4 Dec 2021 07:19:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khramtsov.org; s=rsa; t=1638602358; 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=P95Vka3RBZNNs/I1jfRlWfzQ/28fI3hMfYwUHb8ZUu0=; b=QeetUMWgJqD1TcJ/PFJZ5TmpIh9UDE/iX3X5Ra4k0RjkejF3h0/GSg6ivRimArZ24n5cmM 2BIH7n0d0db8ouGsVTUUDKN2c0KDNZHNniaEtRBzwkxEhCXJb+jMEWBMjrrOdDihB2IPzp PvQLmibmSEpvGyVMGfr6YGQzRFdVnvZp88qBe2SKYOXx/x155MFEiKJuXfT6LV3ODLwNLf 9DLwTtGCh4ZRK1FWG7n5yCBW6macQHrHxH6XaMCHwhWSCsxGsQVtiyk4Q3KyGnabHpQ99V fkVckPCmynTmEW8A0Qk0aa3VAbQEuhncDTlb61WZaCQ1MPt1SdXzi60BeludgQ== Date: Sat, 4 Dec 2021 10:20:41 +0300 To: Kirk McKusick Cc: FreeBSD-CURRENT Subject: Re: lib/libufs: build regressed after b366ee486 Message-ID: <20211204072041.2z6hnht3up6azagx@vax.khramtsov.org> References: <20211203183501.zyroidvh3t4kk2g7@vax.khramtsov.org> <20211204064318.BC12B12A3F@freefall.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: <20211204064318.BC12B12A3F@freefall.freebsd.org> X-Rspamd-Queue-Id: 4J5h1j4fm6z4pJs X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=khramtsov.org header.s=rsa header.b=QeetUMWg; dmarc=pass (policy=reject) header.from=khramtsov.org; spf=pass (mx1.freebsd.org: domain of evgeniy@khramtsov.org designates 2a0a:e5c0:2:10f::f as permitted sender) smtp.mailfrom=evgeniy@khramtsov.org X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[khramtsov.org:s=rsa]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a0a:e5c0:2:10f::f]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[khramtsov.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[khramtsov.org,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:207996, ipnet:2a0a:e5c0:2::/48, country:CH]; ONCE_RECEIVED(0.10)[] Reply-To: evgeniy@khramtsov.org From: Evgeniy Khramtsov via FreeBSD-CURRENT X-Original-From: Evgeniy Khramtsov X-ThisMailContainsUnwantedMimeParts: N > It appears that your build environment does not have the b366ee486 version > of /usr/src/sys/ufs/ffs/fs.h installed in /usr/include/ufs/ffs/fs.h. > > That would normally happen after your did a buildworld and installworld. > You should be able to fix your current compile failure by doing: > > cp /usr/src/sys/ufs/ffs/fs.h /usr/include/ufs/ffs/fs.h. > > Let me know if this fails to correct your problem. > > Kirk McKusick Thanks, Kirk. I was bisecting local enironment, and my issue was related due to dropping https://github.com/DankBSD/ports/commit/56cb9dc72 and overriding sys.mk variables in make.conf instead, which led to include bootstrap being skipped for some reason. From nobody Sat Dec 4 07:25:42 2021 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 BA61D18CC1FD for ; Sat, 4 Dec 2021 07:25:53 +0000 (UTC) (envelope-from evgeniy@khramtsov.org) Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f]) (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 4J5h7P0xPlz4rMS for ; Sat, 4 Dec 2021 07:25:53 +0000 (UTC) (envelope-from evgeniy@khramtsov.org) Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f]) by mxa.khramtsov.org (Postfix) with ESMTP id 211561260CF; Sat, 4 Dec 2021 07:24:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khramtsov.org; s=rsa; t=1638602656; 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=+cRlDOPq491FYZFkaHe5YsWgJFbs3ZdITQBTgQ2AzAE=; b=B7697wnziKkEzs75t3/1iFeXFrbMM6tBL8vBo3sic/QQv7UDjx000mSeGoa+SXyftNKU9Q 0hIfAvl7f2+lTzpz/z1uk+necm1pmD26m56fp7pg/CFv7xpkoT6BMkSr/ytMbDz8kAAf2U xCtId3ehjyUEwirQKhrbJj1zQuEQPgr317zn1tIs+3FcNebzBOAyC0pmcHAflnnx71BJo8 2YaSyO+0kw9vISr57tkSm57NPzuiXOKzUMEahNNI4TxgePWbISzWnwYH77yMQjt7OIPW9a rVj8c5km28P9pY8Nz7mdKM9f+6n9fIqmfZuaN5tVjZsIgPk+9vX7eVlWov4knQ== Date: Sat, 4 Dec 2021 10:25:42 +0300 To: Kirk McKusick Cc: FreeBSD-CURRENT Subject: Re: lib/libufs: build regressed after b366ee486 Message-ID: <20211204072542.h62fhlvgggrqwufz@vax.khramtsov.org> References: <20211203183501.zyroidvh3t4kk2g7@vax.khramtsov.org> <20211204064318.BC12B12A3F@freefall.freebsd.org> <20211204072041.2z6hnht3up6azagx@vax.khramtsov.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: <20211204072041.2z6hnht3up6azagx@vax.khramtsov.org> X-Rspamd-Queue-Id: 4J5h7P0xPlz4rMS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=khramtsov.org header.s=rsa header.b=B7697wnz; dmarc=pass (policy=reject) header.from=khramtsov.org; spf=pass (mx1.freebsd.org: domain of evgeniy@khramtsov.org designates 2a0a:e5c0:2:10f::f as permitted sender) smtp.mailfrom=evgeniy@khramtsov.org X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[khramtsov.org:s=rsa]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a0a:e5c0:2:10f::f:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[khramtsov.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[khramtsov.org,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:207996, ipnet:2a0a:e5c0:2::/48, country:CH]; ONCE_RECEIVED(0.10)[] Reply-To: evgeniy@khramtsov.org From: Evgeniy Khramtsov via FreeBSD-CURRENT X-Original-From: Evgeniy Khramtsov X-ThisMailContainsUnwantedMimeParts: N > dropping https://github.com/DankBSD/ports/commit/56cb9dc72 and Err, the right commit: https://github.com/DankBSD/base/commit/52ff26f21 From nobody Sat Dec 4 18:07:30 2021 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 AE47518C7271 for ; Sat, 4 Dec 2021 18:07:44 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5yMz1tbhz4vZ3; Sat, 4 Dec 2021 18:07:43 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 717AA8D4A129; Sat, 4 Dec 2021 18:07:34 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 7196EE707AE; Sat, 4 Dec 2021 18:07:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id tehDbt8ku93S; Sat, 4 Dec 2021 18:07:32 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id BE50CE707AD; Sat, 4 Dec 2021 18:07:31 +0000 (UTC) Date: Sat, 4 Dec 2021 18:07:30 +0000 (UTC) From: "Bjoern A. Zeeb" To: Warner Losh cc: FreeBSD Current , Jessica Clarke Subject: Re: make cleandiry tries to access /lib/geom In-Reply-To: Message-ID: References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4J5yMz1tbhz4vZ3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zabbadoz.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 24 Nov 2021, Warner Losh wrote: > On Wed, Nov 24, 2021 at 9:52 AM John Baldwin wrote: > >> On 11/24/21 3:30 AM, Bjoern A. Zeeb wrote: >>> Hi, >>> >>> 673 ===> usr.bin/diff/tests (cleandir) >>> 674 ===> lib/geom (cleandir) >>> 675 ===> sbin/mount_udf (cleandir) >>> 676 make[6] warning: /lib/geom: Permission denied. >>> >>> ^^^^ not sure what is going on here? >>> >>> 677 ===> share/i18n/esdb/ISO-8859 (cleandir) >>> 678 ===> tests/sys/cddl/zfs/tests/cli_root/zfs_clone (cleandir) >> >> I think Jess has a possible fix. This is some regression added in the >> build system several months ago. > > > https://reviews.freebsd.org/D30990 I should definitively add it to a tree and try it; Also just saw this which also seems wrong given it is during install/distribution times losing ${DESTDIR} ===> etc (installconfig) make[3] warning: /etc: Permission denied. ===> etc/sendmail (installconfig) -- Bjoern A. Zeeb r15:7 From nobody Sat Dec 4 18:10:45 2021 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 BEBFC18C8BE3 for ; Sat, 4 Dec 2021 18:10:55 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5yRd42R5z4x1S; Sat, 4 Dec 2021 18:10:53 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 1B4IAjRh041368 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Dec 2021 10:10:45 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 1B4IAjPU041367; Sat, 4 Dec 2021 10:10:45 -0800 (PST) (envelope-from jmg) Date: Sat, 4 Dec 2021 10:10:45 -0800 From: John-Mark Gurney To: David Chisnall , freebsd-current@freebsd.org Subject: Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined) Message-ID: <20211204181045.GW35602@funkthat.com> Mail-Followup-To: David Chisnall , freebsd-current@freebsd.org References: <20211202020326.GU35602@funkthat.com> <75CCC6A8-F777-48F9-9AC7-5A08FA9CCD25@FreeBSD.org> <20211202234350.GV35602@funkthat.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: <20211202234350.GV35602@funkthat.com> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 04 Dec 2021 10:10:45 -0800 (PST) X-Rspamd-Queue-Id: 4J5yRd42R5z4x1S X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [0.22 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N John-Mark Gurney wrote this message on Thu, Dec 02, 2021 at 15:43 -0800: > David Chisnall wrote this message on Thu, Dec 02, 2021 at 10:34 +0000: > > On 02/12/2021 09:51, Dimitry Andric wrote: > > > Apparently the "block runtime" is supposed to provide the actual object, > > > so I guess you have to explicitly link to that runtime? > > > > The block runtime provides this symbol. You use this libc API, you must > > be compiling with a toolchain that supports blocks and must be providing > > the blocks symbols. If you don't use `atexit_b` or any of the other > > `_b` APIs then you don't need to link the blocks runtime. > > > > I am not sure why this is causing linker failures - if it's a weak > > symbol and it's not defined then that's entirely expected: the point of > > a weak symbol is that it might not be defined. This avoids the need to > > link libc to the blocks runtime for code that doesn't use blocks (i.e. > > most code that doesn't come from macOS). > > > > This code is not using `atexit_b`, but because it is using `atexit` the > > linker is complaining that the compilation unit containing `atexit` is > > referring to a symbol that isn't defined. > > I assume that this failure was due to a recent llvm change, because I > haven't received any failures about pructl until Nov 16th, 2021, > despite the port and code being untouched since 2020-09-22. > > Digging in a bit more, it looks like libpru is compiled w/ -fblocks, > and so depending upon the _Block_copy symbol, the atexit is just the > "closest" symbol that's defined". pructl is not, but even compiling > pructl w/ -fblocks, doesn't fix the link error, as it looks like the > block runtime isn't linked. If I manually include > /usr/lib/libBlocksRuntime.so, then pructl is able to link. > > I can't seem to find any docs on clang about how to properly compile > code that uses blocks, so, unless someone points me to docs on how to > compile blocks enable programs, I'll just patch libpru to not use > blocks since it seems like blocks is well supported. I don't want > to fix this code every few years when things change. Thanks to some off-list comms, it appears that this was a regression in lld 13, and will be fixed by: https://reviews.llvm.org/D115041 Thanks to jrtc27 for [helping] tracking this down! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Sat Dec 4 18:53:52 2021 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 BF79F18D1BF1; Sat, 4 Dec 2021 18:54:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5zPN6tq1z565j; Sat, 4 Dec 2021 18:54:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1B4Irq6M020460 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 4 Dec 2021 10:53:53 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1B4IrqGQ020459; Sat, 4 Dec 2021 10:53:52 -0800 (PST) (envelope-from sgk) Date: Sat, 4 Dec 2021 10:53:52 -0800 From: Steve Kargl To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: What to do about tgammal? Message-ID: <20211204185352.GA20452@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4J5zPN6tq1z565j X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [1.04 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.04)[0.042]; NEURAL_SPAM_SHORT(0.99)[0.990]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N What to do about tgammal? A long time ago (2013-09-06), theraven@ committed a kludge that mapped several missing long double math functions to double math functions (e.g., tanhl(x) was mapped to tanh(x)). Over the next few years, I (along with bde and das reviews) provided Intel 80-bit (ld80) and IEEE 128-bit (ld128) implementations for some of these functions; namely, coshl(x), sinhl(x), tanhl(x), erfl(x), erfcl(x), and lgamma(x). The last remaining function is tgammal(x). If one links a program that uses tgammal(x) with libm, one sees /usr/local/bin/ld: fcn_list.o: in function `build_fcn_list': fcn_list.c:(.text+0x7c4): warning: tgammal has lower than advertised precision The warning is actually misleading. Not only does tgammal(x) have a *MUCH* lower precision, it has a reduced domain. That is, tgammal(x) produces +inf for x > 172 whereas tgammal(x) should produce a finite result for values of x up to 1755 (or so). On amd64-*-freebsd, testing 1000000 in the below intervals demonstrates pathetic accuracy. Current implmentation via imprecise.c Interval | Max ULP -------------------+------------ [6,171] | 1340542.2 [1.0662,6] | 14293.3 [1.01e-17,1.0661] | 3116.1 [-1.9999,-1.0001] | 15330369.3 -------------------+------------ Well, I finally have gotten around to removing theraven@'s last kludge for FreeBSD on systems that support ld80. This is done with a straight forward modification of the msun/bsdsrc code. The limitation on domain is removed and the accuracy substantially improved. Interval | Max ULP -------------------+---------- [6,1755] | 8.457 [1.0662,6] | 11.710 [1.01e-17,1.0661] | 11.689 [-1.9999,-1.0001] | 11.871 -------------------+---------- My modifications leverage the fact that tgamma(x) (ie., double function) uses extend arithmetic to do the computations (approximately 85 bits of precision). To get the Max ULP below 1 (the desired upper limit), a few minimax polynomials need to be determined and the mystery around a few magic numbers need to be unraveled. Extending what I have done to an ld128 implementation requires much more effort than I have time and energy to pursue. Someone with interest in floating point math on ld128 system can provide an implementation. So, is anyone interested in seeing a massive patch? -- Steve From nobody Sat Dec 4 19:40:56 2021 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 2895A8D4384; Sat, 4 Dec 2021 19:41:11 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J60Rq09wtz3Gtl; Sat, 4 Dec 2021 19:41:10 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A502D2601B4; Sat, 4 Dec 2021 20:41:02 +0100 (CET) Message-ID: <46162af1-b63f-be10-ebdf-cd328dcfb6e2@selasky.org> Date: Sat, 4 Dec 2021 20:40:56 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: What to do about tgammal? Content-Language: en-US To: Steve Kargl , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <20211204185352.GA20452@troutmask.apl.washington.edu> From: Hans Petter Selasky In-Reply-To: <20211204185352.GA20452@troutmask.apl.washington.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J60Rq09wtz3Gtl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 12/4/21 19:53, Steve Kargl wrote: > What to do about tgammal? > > A long time ago (2013-09-06), theraven@ committed a kludge that mapped > several missing long double math functions to double math functions > (e.g., tanhl(x) was mapped to tanh(x)). Over the next few years, I > (along with bde and das reviews) provided Intel 80-bit (ld80) and IEEE > 128-bit (ld128) implementations for some of these functions; namely, > coshl(x), sinhl(x), tanhl(x), erfl(x), erfcl(x), and lgamma(x). The > last remaining function is tgammal(x). If one links a program that uses > tgammal(x) with libm, one sees > > /usr/local/bin/ld: fcn_list.o: in function `build_fcn_list': > fcn_list.c:(.text+0x7c4): warning: tgammal has lower than advertised > precision > > The warning is actually misleading. Not only does tgammal(x) have a > *MUCH* lower precision, it has a reduced domain. That is, tgammal(x) > produces +inf for x > 172 whereas tgammal(x) should produce a finite > result for values of x up to 1755 (or so). On amd64-*-freebsd, > testing 1000000 in the below intervals demonstrates pathetic accuracy. > > Current implmentation via imprecise.c > > Interval | Max ULP > -------------------+------------ > [6,171] | 1340542.2 > [1.0662,6] | 14293.3 > [1.01e-17,1.0661] | 3116.1 > [-1.9999,-1.0001] | 15330369.3 > -------------------+------------ > > Well, I finally have gotten around to removing theraven@'s last kludge > for FreeBSD on systems that support ld80. This is done with a straight > forward modification of the msun/bsdsrc code. The limitation on > domain is removed and the accuracy substantially improved. > > Interval | Max ULP > -------------------+---------- > [6,1755] | 8.457 > [1.0662,6] | 11.710 > [1.01e-17,1.0661] | 11.689 > [-1.9999,-1.0001] | 11.871 > -------------------+---------- > > My modifications leverage the fact that tgamma(x) (ie., double function) > uses extend arithmetic to do the computations (approximately 85 bits of > precision). To get the Max ULP below 1 (the desired upper limit), a few > minimax polynomials need to be determined and the mystery around a few > magic numbers need to be unraveled. > > Extending what I have done to an ld128 implementation requires much > more effort than I have time and energy to pursue. Someone with > interest in floating point math on ld128 system can provide an > implementation. > > So, is anyone interested in seeing a massive patch? > Hi, Do you need a implementation of tgamma() which is 100% correct, or a so-called speed-hack version of tgamma() which is almost correct? I've looked a bit into libm in FreeBSD and I see some functions are implemented so that they execute quickly, instead of producing exact results. Is this true? --HPS From nobody Sat Dec 4 21:20:23 2021 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 23D851837833; Sat, 4 Dec 2021 21:20:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J62fK6xnNz3jdQ; Sat, 4 Dec 2021 21:20:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1B4LKOEl020812 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 4 Dec 2021 13:20:24 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1B4LKNAk020811; Sat, 4 Dec 2021 13:20:23 -0800 (PST) (envelope-from sgk) Date: Sat, 4 Dec 2021 13:20:23 -0800 From: Steve Kargl To: Hans Petter Selasky Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211204212023.GA20729@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <46162af1-b63f-be10-ebdf-cd328dcfb6e2@selasky.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: <46162af1-b63f-be10-ebdf-cd328dcfb6e2@selasky.org> X-Rspamd-Queue-Id: 4J62fK6xnNz3jdQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 04, 2021 at 08:40:56PM +0100, Hans Petter Selasky wrote: > On 12/4/21 19:53, Steve Kargl wrote: > > What to do about tgammal? (trim some history) > > > > Interval | Max ULP > > -------------------+------------ > > [6,171] | 1340542.2 > > [1.0662,6] | 14293.3 > > [1.01e-17,1.0661] | 3116.1 > > [-1.9999,-1.0001] | 15330369.3 > > -------------------+------------ > > > > Well, I finally have gotten around to removing theraven@'s last kludge > > for FreeBSD on systems that support ld80. This is done with a straight > > forward modification of the msun/bsdsrc code. The limitation on > > domain is removed and the accuracy substantially improved. > > > > Interval | Max ULP > > -------------------+---------- > > [6,1755] | 8.457 > > [1.0662,6] | 11.710 > > [1.01e-17,1.0661] | 11.689 > > [-1.9999,-1.0001] | 11.871 > > -------------------+---------- > > > > My modifications leverage the fact that tgamma(x) (ie., double function) > > uses extend arithmetic to do the computations (approximately 85 bits of > > precision). To get the Max ULP below 1 (the desired upper limit), a few > > minimax polynomials need to be determined and the mystery around a few > > magic numbers need to be unraveled. > > > > Extending what I have done to an ld128 implementation requires much > > more effort than I have time and energy to pursue. Someone with > > interest in floating point math on ld128 system can provide an > > implementation. > > > > So, is anyone interested in seeing a massive patch? > > > > Hi, > > Do you need a implementation of tgamma() which is 100% correct, or a > so-called speed-hack version of tgamma() which is almost correct? > > I've looked a bit into libm in FreeBSD and I see some functions are > implemented so that they execute quickly, instead of producing exact > results. Is this true? > I'm afraid that I don't fully understand your questions. The ULP, listed above, were computed by comparing the libm tgammal(x) against a tgammal(x) computed with MPFR. The MPFR result was configured to have 256 bits of precision. In other words, MPFR is assumed to be exact for the comparison between a 64-bit tgammal(x) and a 256-bit mpfr_gamma() function. There is no speed hack with mpfr_gamma(). % time ./tlibm_lmath -l -s 0 -x 6 -X 1755 -n 100000 tgamma Interval tested for tgammal: [6,1755] 100000 calls, 0.042575 secs, 0.42575 usecs/call count: 100000 xmu = LD80C(0xae3587b6f275c42c, 4, 2.17761377613776137760e+01L), libmu = LD80C(0xb296591784078768, 64, 2.57371418855839536160e+19L), mpfru = LD80C(0xb296591784078760, 64, 2.57371418855839536000e+19L), ULP = 8.28349 6.04 real 6.02 user 0.01 sys My test program shows 100000 libm tgammal(x) calls took about 0.04 seconds while the program takes 6 seconds to finish. Most of that time is dominated by MPFR. In general, floating point arithmetic, where a finite number is the result, is inexact. The basic binary operators, +x-/*, are specified by IEEE 754 to have an error no larger that 0.5 ULP. The mantra that I follow (and know bde followed) is to try to optimize libm functions to give the most accurate result as fast as possible. -- Steve From nobody Sat Dec 4 23:48:13 2021 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 6F8F018376BB; Sat, 4 Dec 2021 23:48:16 +0000 (UTC) (envelope-from markm@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J65ww1s86z4bpG; Sat, 4 Dec 2021 23:48:16 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:71c3:4809:ece6:78d6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id 99C4429C51; Sat, 4 Dec 2021 23:48:15 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_3C2A57F7-D97B-4F72-96C1-F0679D5B40A2"; protocol="application/pgp-signature"; micalg=pgp-sha512 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 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211204185352.GA20452@troutmask.apl.washington.edu> Date: Sat, 4 Dec 2021 23:48:13 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211204185352.GA20452@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638661696; 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=EOJnd4kaEMSBsY6MMdVcF6V6+pboRU59PQWAeaASS1E=; b=lkk3tSkrLy9SApY8HZMoYDzx+RS0RVw23KZkfsaEG/FazxdJu02OPgOiIDU01LCiBQaq0f ErYPc6F2bBT8echHKa3/xe+9ibs1sJN3Jj9VaBcy17POW1lf1huBM3jW3cxW+ftZVz7j4d R0Q9QfrMoGaPKVtXv3eay+60/QJwy78wuL1CJZGr9ZIkTymJRJ/Rb6Cc2F96TMPm3KzXyG zrFeCEtJF2KVx+9eIfu0BfFTVrBTJBNHsEJF8csUznhEO/uQx5q0tqcTfrGmEEwuop37pO LGvwKe63aJd8Auwliu6ohaTe359bDboiN1Sx3AdGTLM5/DFJNMgY5SFX6rkhUw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638661696; a=rsa-sha256; cv=none; b=Xx4u81CQpiGFfFiRoPomk3sEqgig8UHKtLTURK/+APVZpksy4//DzVUkjSUmuaP7PgXrP6 XJ5WCLwWfF/qXbz/mUdTIGlGXMWUg0NEwQB+YMjHluyjQuJ0E5TFEBWxAOs9KOdwuH+xzg lU/P3B6BK+94FAHUMJDfAuZ+8zo7hrVtljPrqP4i4x+au8YuqR24YNr1ivtIIgxxLCcc+f PkZ2lO1tRQ7SfIJKF+n6mLjavqm4U835svTt2PkPRQTP2dN0VSmDulqxSRzgNO3rkYuJ3E Wv/dJtd6tE26oWsXTPWyfMZYcX/hcbMmW/y7kGofMWyoU8JTM8eUEPuRw+3Cqg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_3C2A57F7-D97B-4F72-96C1-F0679D5B40A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 4 Dec 2021, at 18:53, Steve Kargl = wrote: >=20 >=20 > So, is anyone interested in seeing a massive patch? Me, please! M -- Mark R V Murray --Apple-Mail=_3C2A57F7-D97B-4F72-96C1-F0679D5B40A2 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 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmGr/j0ACgkQQlsJDh9C UqCCbwf+K6NfE5MfnaD8qPJFdF+w8jIYs+/CqPn0R+2np8KE7uEYAx09MJJ7K6/G iWtVqKw0XfspMF7uBXjpkR1xdSSHzqggqVvhjnkgFEaoynOMkpsIExFCJMFwQpyZ GMKYrBBnz0NwWRuCnWfZ/Xxn2iLsfkA04ut1J4E2qenNzVmDsbTpiHhvpgQ8ztWZ pvlXq1n+ndCEZh5lrhZj320RpCGYBKXuHqYDfb3UNNBGQYElnVGjpGkUR+Slbryk XJfyfU7vb33Ppg5FlnnxuB0XTzi8uWj611Ve3SrYxeZBYHnvmzdx+A8cAdEZ+mJo +t+HC/+mGDxC4itEZ4lMlgP0Ph9gCg== =j6yb -----END PGP SIGNATURE----- --Apple-Mail=_3C2A57F7-D97B-4F72-96C1-F0679D5B40A2-- From nobody Sun Dec 5 00:25:59 2021 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 A8E8C1897537; Sun, 5 Dec 2021 00:26:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J66mT3Rr8z4hRv; Sun, 5 Dec 2021 00:26:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1B50PxLL021884 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 4 Dec 2021 16:25:59 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1B50Px8x021883; Sat, 4 Dec 2021 16:25:59 -0800 (PST) (envelope-from sgk) Date: Sat, 4 Dec 2021 16:25:59 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211205002559.GA21850@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J66mT3Rr8z4hRv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 04, 2021 at 11:48:13PM +0000, Mark Murray wrote: > > > > On 4 Dec 2021, at 18:53, Steve Kargl wrote: > > > > > > So, is anyone interested in seeing a massive patch? > > Me, please! > It is ld80 only. ld128 is still broken. I'll clean things up and create a diff over the next few days. The patch will disconnect imprecise.c from the build. So, if you like what you see and pursue committing the patch(es), one pre-requisite will be to copy src/imprecise.c to ld128/b_tgammal.c. In the good old day, one would use % svn copy src/imprecise.c ld128/b_tgammal.c % svn delete src/imprecise.c or % svn move src/imprecise.c ld128/b_tgammal.c Don't know (or care) how to do this in a git world. -- Steve From nobody Mon Dec 6 22:19:08 2021 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 5EEBD18BC218 for ; Mon, 6 Dec 2021 22:19:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J7HsR1zJ7z3PZ4 for ; Mon, 6 Dec 2021 22:19:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638829164; bh=zibDftujcQ35nzCCSxMnxJJ9B2AZMAb2s40FYFkeUR0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=nLLECC8aZu5BsB6tLGboNeC23sApOwd7ogFr+G0bAFnd01Vid6oABabv+EtteBLSLk8KWeuMkK9/cMcuhRRmQSf9U5dqRfdwInkHuIFMxbkf8TkAGPbLglzKd9cmaXdyC/3wvnh5B8KQ/BKukyEu0ovz+jwmAHns3ReGcXD0Whlyr96yLAz290Fb+UsNecReRPU0XxfnabHaMI5LP16Rl9G395TQcZ042CxrcQn0rHkCmj2qsWi4qh83NhN+J0LurKhdAQOSK3iqX2DXPwW71/h3HjMbE0sgzt58mNNSIbty+Rz87J1OjxtcfnUNQsTtknFzXImT7H1zeogKtLQNzQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638829164; bh=7/w1n4DenlY4vRYlIaYdpxI7nH7FziBfaCvDtsJv2fS=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=R7cRJVMvUIk+dT4Joe32+d7fvLeXn/xT2TGN3MCwvJpdwDqcajx6gPGn0L9eypvo+CA/9qDXe4pDpkUcsom4urHu9IWkK6IrLecsHBgNWmpH8ta8wKBYDxMdaODDZPJwPecb2ekDWOTrTD/MKdLuj4NHre4ixl1S202L39sGE+GRMhhR6uPDzOX2kxx6/w21Ie4K8Yw9QuexogpUgY04GT1sMFNQCsi/iHp/zwwm+vHCZcVDNCohtiWFhNObqXmV1uHEALMqHRkTbiOLw2S1rDd4xksv0qzg5CZegU+0uY0Gca13WxZGPIR22SiKP/PCdCn8QB/sD/oVtlw3LDwTog== X-YMail-OSG: ekNrwiYVM1kWJ9ZytxVvW8wVN1bfA8eqKuwDuWmo4jaUNHyF8cKSlSffWQWitLR vnRH2CqsQLAhY6OMewBcD.oMpH4GodDCr1YjMGBflHlb8OMGb.FWPieL3ZTtyIlxWnlI7YMb1xL3 oZ0u18.Mkq6OC4ZtsazoRevfWf1USrMVZg234wcJ5bNrMjGdTzKzr5P67kep40uLCh4mzSicZ4N5 LvU1ktVZ2fa0dpUSTEkuO50kvO6yQecmwmqL3x0sztLJMTMRISrWxeoavoG7BUx0agjxh8NSXdl0 _H0k7pe_yrc7ywXFB_6UiMQv7qBPzXpk0r8ELSOmw0xHjcDpA8IY5fzqNSTIy6cjenkIPzk9DaLa l7TURtu11PegOr6z9H4vzNXkmJGLb_dxA6k.DQPONQKwjQJ9j6xOxBv38eXCvl3b342dzb8EuHVb f_955zKsLCLj2QkftOGeS2o9De6WBryYqeX4LdR0AGRX8cQ7rkdCQUbZ0NWrN77u8yBWEm7eNACR c2_GmmTcrlqYVePWABqoJPXQkCiEA71ppZRFhehhIQgxNdCw5YP_fHX6eEsFb0c6vfNeK7idPa77 pgvZQLVpnD9HFYu2rilPDvZ8j54t9K8JUhRDHi4vKUsyQU4A5Yj42BLiXrgKd2M88HUcbjdknVkJ 716BnfewuBCYt6lOdaJLq.Ao4HOhW8qOowC4DVpDIXEi.KChbUcaMTyr9ZWyqiXGTw6MhebiAqEA g4v3.gYXTQQTtu0GnTLkeq8xkiaKjkE.zkoLnde6.wuSdWZIFb9f5khExjdVpdnS895SQYI3dc6o f82a13cxsDN1XYWyg1BP7jIRSOH.i8DruLqNeTOPsZcRUIRZBNO2WQWaIiKCjgJDImetBDVsffB8 Pl9Je1h28e_mCZVIvVMmn.XeziIjCIbXJ0S6tim_JJZLM_uYKd6ImmPw.Cg0VOvlerz.fOACB4kv D2fJf78oZtx4BBrg1mxhHND2r8dFSwKm1nJ5AjkG6i0yGUz4Nt4jRbWQKovU96y7jtTJHMONWA.m r7mQYUk8qPX7YApsCsToFAt6gIOPlylsC7iB4tTxv455cAeXrHYArCZCgLaK5ZnsCX7PtDt.VXMG 8POx1fk7GUD15QP29AoE.YoFuN191fstKuE6mRm_5pMrKvmbRn2oMU.y6RH480GYGGb064q4qOeL x8LuyNWmXFBTz97sn2rfAf0qxA6vcfLuLPqDfY7lHO53XnNfZHdXeYbGYZoIVoA41ozlz_OAsMxb uOiiGykrcy5XLvpJQSKnJtm_._ZbahMxIagGLLHw.c0trXcmQbanV80CqNGJBvl5K8NCzd2ZV7uM hlHgQxisIkAOHxNqeLkbd8EoY5A.cw4nAUlaCFpPtchlbS104mlmWjB8KsUXCgDVqa7zKx8GtglC lkEWoHbqWoFwjrgKcySJ3K91wRSamx9_0wfypjB1zlsEMVZpr3h6dmi42JvZylFoOz.ZOkEUH_8d PHYqa8PhrB6s6NvHl_rpJf2JisCSUdkGRi.oR5FApEmJwKjgkp6TkQjYsd.c8AtTBy6OxMxJT8YW okoy1asDaKITZzIVvBeAA.iXSemrnJFPZGmPHmomaknuCmCugJXCHmDcrEIXB0Hlw3dBZXHCb0X1 Z05H17J2dIy232oVntxXqGO6QXHkIZ1MnzFpkfoJJnaePS43SfANZlwhEnUx6bLAH4Ona64pLbl_ 9piMJhyOxVBCoDwRUmbz96UGGnAKBneS2tDoPeHnmu8i1NZYJKSl6ut7_MEA8hS10UqAzimQfY.q XxqlKSWEAAmhtDlHfKrXzDdhCFkmpoduvxNyWJoFxPZOvrWMSAjRuLqBF5KQZnn6fPCZx6pG4E6L IIl3FsjNMM8kXNpGMT83Jol3U2Yoh2Rffp5AWXpiijVOG6DzrPMmY8TKMgs_dKOpeTLvLed6yAF8 rKp1EbjZIoI6FpCv1rWi148LKJ1H.wEqNNO2a_oQiNctJJCCSPSsGw88cv4Ze19rOxibnt5u0RKu JKHLNWFi4blkT8IBlvxZUbWvjiHpKU.CUE0o6XeamIbdghSLkJ9tNEuQ0Dv5nZvNJ6oeEOl_zxWp 5OSmuZzqVdMr02OvlE6ssEkM.GHT_zKMlorj2ZpC5IyN1Qfn2j9MCi23ggJrPCuF26SbiHaV7Un2 SaaqhrqMdw1aMIR54HvDKm8ICxXJngr02r_JHk5rvNr_.kWQuuBTUYrB_cfeik_sklGTrAnRt2qy hmgGflwDrTBpo1T3HixmHDsY1UxaF4jXVzdr2rg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 6 Dec 2021 22:19:24 +0000 Received: by kubenode504.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 414eb7ba8c96ad05b168ca8ad82f569e; Mon, 06 Dec 2021 22:19:10 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e04571cf3cf - main - sys/bitset.h: reduce visibility of BIT_* macros Message-Id: Date: Mon, 6 Dec 2021 14:19:08 -0800 To: Stefan Esser , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4J7HsR1zJ7z3PZ4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nLLECC8a; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.28 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.99)[-0.992]; NEURAL_SPAM_MEDIUM(0.21)[0.207]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N This broke building lang/gcc11 so may be a exp run is appropriate: In file included from /usr/include/sys/cpuset.h:39, from /usr/include/sched.h:36, from /usr/include/pthread.h:48, from = /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc/jit/libgccjit.c:27: /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned = "malloc" 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), = mt, (mf)) | ^ . . . In file included from /usr/include/sys/cpuset.h:39, from /usr/include/sched.h:36, from /usr/include/pthread.h:48, from = /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc/jit/jit-recording.c:28: /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned = "malloc" 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), = mt, (mf)) | ^ . . . gmake[4]: *** [Makefile:1142: jit/libgccjit.o] Error 1 gmake[4]: *** Waiting for unfinished jobs.... In file included from /usr/include/sys/cpuset.h:39, from /usr/include/sched.h:36, from /usr/include/pthread.h:48, from = /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc/jit/jit-playback.c:44: /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned = "malloc" 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), = mt, (mf)) | ^ gmake[4]: *** [Makefile:1142: jit/jit-recording.o] Error 1 gmake[4]: *** [Makefile:1142: jit/jit-playback.o] Error 1 rm gcc.pod gfortran.pod gmake[4]: Leaving directory = '/wrkdirs/usr/ports/lang/gcc11/work/.build/gcc' gmake[3]: *** [Makefile:4817: all-stage2-gcc] Error 2 For reference: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #24 = main-n251362-9f32cb5b1c81-dirty: Sun Dec 5 21:16:30 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400043 1400043 ~/fbsd-based-on-what-commit.sh=20 branch: main merge-base: 9bed79e869721b4ca8a15c527db8d40969867c2c merge-base: CommitDate: 2021-12-06 03:45:47 +0000 9bed79e86972 (HEAD -> main, freebsd/main, freebsd/HEAD) www/drupal9: = update to 9.2.10 n567671 (--first-parent --count for merge-base) My test of building on amd64 is still in progress. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Dec 6 22:48:48 2021 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 DAF1D18C1622 for ; Mon, 6 Dec 2021 22:49:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J7JWg6HMXz3jVj for ; Mon, 6 Dec 2021 22:49:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638830935; bh=oL4jlzbYYDYmpT/n0sjHJByjpdt/Qk7dmoSRjpMO/LA=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=WjujuwFm7X9pffGFslKpJMRmZcG3HpCOuiovSRwxroIq/G6/mbYjruPPtLjrlFKOahTyiL78UBKzf6d9UJLPM/xLw4eWEImtYuhGSFqvLcQL15MFkC7+snoId+m7ivEx+GZnpZU1B8cfKHjJU77LR+8yBqrsmPAW2g9Op8sVkSxb7Q2ZxfHbYiWjLZxHt4txfb14NQDs+8XpTdTSmibjafOCsR4ajCPuNJIQPeoMoDFbrF6e3l4Eq64oC8K3pGWyM5/pwJE+xmK/6lN7Bbv/yHg+MATkHDwnD78c0Xe3r5NZsydcZp2FLWffERkdORry+r4aJ5lgdMY78C+UGj4/pA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638830935; bh=WyjZMCFNmxhZMyal2F3it3omkoEV7RfR8gSo+BUaJdl=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NbtzWCWVnlmR2a+GOTxDJe8DHLlmimy9dJMJxjyYXU5Pb5V5dyfwT7WmV02jSNLVpAR1pBkqS5dC+WLEo1SWJe1a0h037rBkBmcsngsqaNbWf4iIP/P+3EHhXhqmk0+PuCkMNI4i3BIdxiugqf7BupfL+rRxAT+/X6WvaRQOgtETlg6BhTer2Ss1FlrSUkBRHhPFrEsp5yWb0blgLouXxfztV7vTSTpg6EUO+ghpKBVGJ4GZE6UG6w9uEuxQeTofQ0ldXKvtrvJtFLqs2rCFCRCTiUbtLkexjgOKq/RuPBl37edkT5OzxL8utqc8Ez2lVQKYS4xGFWJxwsSbo1uJyw== X-YMail-OSG: 7yhpFZkVM1k_la5w9ztJcdGdZVuMe4lgYiwA4HKr74CcMsILRpoOah_uTAyZDfK 3RhxpEieDUcoMV9IdWAgJIKhD4Q43LA_V0EZTpOF80TW4KKxlNzUJOn84Bk9Q.Bi9BHX68siXNLY iLEc.JTGO_EX8l8q7.LZT0uXXYhySZiHB417MxG3AmDSsAdY6qgp8h4lICj_SGJkNYLpq_vN5vlS TWHmhLKo3FB_7sZsvPM63ulIeEY_kAIkGh0cZEEDcREj3uN1cerra9nueZUIOtbiJt5YLU_6kmz6 LFI3HX9CYJ2GFrMTXo6m8UnIjK41nJmz48VF_yWnM6P9k4LfGMh2oAkQlU6ha1ZVceMkHH8KD6m8 fP4SbLpSLxDF4hKbVkQd_IyioFJO8MoZc0Ls.ml_dhHsfFbSMtD_Of.U5WC2iDjGaQdUUQJmNg6S yEo3xsnlQ22Iui1acMLOL7OxIKq83bKZ4lwxsBHtSs1FQp.S9T03okEpa1PGf4yAUAdcjKWf1xC3 uvdf4tYjnPzBWYyj4F4mSdEOHAem221JE4XV21qF25FRhgnfcLBGh3zFjoDadwZ492VwGX2nO2d5 iqcL5431Maa8hqmZEy5lSgu2FSXuWk3ACUBIl_NfH.oG0dPVoiebCYTkmw13Agv5i_DWmJ8GFOQu yGsGPDR7hQEZHtodFW7Oj0jTN8bWmExW.LJnDS97kCgKKCD8ZjIvj0oFYXNynA23VJpoQ26z.EK0 COw8sBp0RNguexJeW2T2FuFjQvHudId_zwcFgnSDiKMpkfoom34hbrBKm7T0jJFUM95JFu3UAvDV iJjySCSlgxm8FQGZVax3Awl0A6VftUB4vdIdqDE8Wny2rHMIJJ0NHtmf6yFKV7VUks2kFS7n_yV3 ecVbPWEJpKnLc3fUt35EwNVDhV2JCHv94po2UfIJRLIzBPN1JhLWrWw1b2GeQgfs2vpjP3mPpg4A rI1GgZDIj.GpTtJHwEkbRMzZIdzlnwGEIm6subdqC17J_HEeKuU4olW7NbLJ34s6O4CY0ElSN7ir rgFfy5CCkG5QJd.rbMGfzMtpv.GVx1mBO_kQQWFru5mu2V39M1Szn2rjOcMgUhXC8P8x014p2s8N WtSuggNU8dtzl4QLHWeIh_JMRae.syCyiqkeKzHO2PeEvLuD40hOJXzyFquTHZLnT..bM4AylWd6 Y74kRX6AMx0QsrtdZMeC0ibaBghSfZujY0cjxP9WhXWT_8lQPYVmz7oT.QQCjWcSpLbkdtsnxEK. z59tjjKsensnOxnTJOqfhYk.a4GBlWniNfuxTksIyeyrMr1.wV.0A.TEQtIi7I1c7jcp45Nu67_Y fWVLS.Cs1idqPrfQb06NWLXkFkT3jIwkFzNQrXS6hpBKty815w82JJHOpkIBrChGIvpeyeozBQat x96MlPf87MYa6dwcRj9YSJm5NKR4v7Rlng3RQwIdy9bReQpcAGT4GLPUGXE7iOe8hKrJ1cVJ5W1a VEPHzoNfhJR0.2ZzTHy3qzuz29ANazaWNpfcsEhhV8_AU9qx1ZBrQJaKxFvwFmmEGiszCef8W4F3 dqFeUNsGxhV_7eGlShtytGy1YGXEA_8yBC7V7AOp4q6G6EFQM0owcF5.7kaGMLRYPQVHeOntL3RE Tv45sj6Aqwz0JY05tn0VmW_JMlNpk2qLo86vnqVieRb.5wvsDKIJ2QHRJRaftBFqxb_5f0gErHRH STVVOawifmy89.RY6OJph.70o4hh.qHArDv5XaHs1wGxDJw6TfCjyx0_CMU2FEfpqwN9Cnf_.Iza jye1oXK6GjKb21cSckCWEggKGBsJRbUiLI77.eUzOQphMhLfiqISQlfDChZoC2k__ynqFL81pEXr xtsIHhrscXCiiHhMwe.pUIrbpbJ_ih3J5axrwIEm2ba9Ob_VvAZprCX3t4h5KMSMrEwBTW.jpgM3 uDji.BHt1zWNisH9HtP_E6HGur7T3_VvK3RGec5k6YxLMIXKdS1QzTfb2FZsFI7wmXWNX5pBdgKb 0Mx3yTKdmRvn9kDlyemjTSXJCh6QZCr.BA67Da_pabZ4RJ6gLQc7rUgcjk0tvWBMk7QhwSKeoG2L RBNRuek45s39sKxcAhD49Zl1Qha4NWFunFD252i1nx24bBFW6U5YsU30gj7fPDpZW0PJvKooIzHm yUAs4AtAt0JzpL.fojYKsO1Jq2mWWJrI1ib1hLvLtqEABuP9u2QUT5JyhCrz9b_A2Q8LA2z13oRD ifRnlUMXS96BvGfC6H4QjICiVZSP9sU2WBZ9ozlA1JdMjjLKNGV9D4z53X2B6ydzDlYq8rqlNyvK rQOK0iYan1HhByFVBckKu X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 6 Dec 2021 22:48:55 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9d9922e40ac563830ad2874bbcb93f38; Mon, 06 Dec 2021 22:48:50 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e04571cf3cf - main - sys/bitset.h: reduce visibility of BIT_* macros Date: Mon, 6 Dec 2021 14:48:48 -0800 References: To: Stefan Esser , freebsd-current In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J7JWg6HMXz3jVj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WjujuwFm; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.28 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.99)[-0.994]; NEURAL_SPAM_MEDIUM(0.21)[0.214]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-6, at 14:19, Mark Millard wrote: > This broke building lang/gcc11 so may be a exp run is appropriate: >=20 > In file included from /usr/include/sys/cpuset.h:39, > from /usr/include/sched.h:36, > from /usr/include/pthread.h:48, > from = /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc/jit/libgccjit.c:27: > /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned = "malloc" > 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), = mt, (mf)) > | ^ > . . . >=20 > In file included from /usr/include/sys/cpuset.h:39, > from /usr/include/sched.h:36, > from /usr/include/pthread.h:48, > from = /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc/jit/jit-recording.c:28: > /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned = "malloc" > 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), = mt, (mf)) > | ^ > . . . > gmake[4]: *** [Makefile:1142: jit/libgccjit.o] Error 1 > gmake[4]: *** Waiting for unfinished jobs.... > In file included from /usr/include/sys/cpuset.h:39, > from /usr/include/sched.h:36, > from /usr/include/pthread.h:48, > from = /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc/jit/jit-playback.c:44: > /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned = "malloc" > 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), = mt, (mf)) > | ^ > gmake[4]: *** [Makefile:1142: jit/jit-recording.o] Error 1 > gmake[4]: *** [Makefile:1142: jit/jit-playback.o] Error 1 > rm gcc.pod gfortran.pod > gmake[4]: Leaving directory = '/wrkdirs/usr/ports/lang/gcc11/work/.build/gcc' > gmake[3]: *** [Makefile:4817: all-stage2-gcc] Error 2 >=20 >=20 > For reference: >=20 > # uname -apKU > FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #24 = main-n251362-9f32cb5b1c81-dirty: Sun Dec 5 21:16:30 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400043 1400043 >=20 > ~/fbsd-based-on-what-commit.sh=20 > branch: main > merge-base: 9bed79e869721b4ca8a15c527db8d40969867c2c > merge-base: CommitDate: 2021-12-06 03:45:47 +0000 > 9bed79e86972 (HEAD -> main, freebsd/main, freebsd/HEAD) www/drupal9: = update to 9.2.10 > n567671 (--first-parent --count for merge-base) >=20 > My test of building on amd64 is still in progress. Just like the poudriere-devel based build on aarch64, amd64's poudriere-devel based build got: In file included from /usr/include/sys/cpuset.h:39, from /usr/include/sched.h:36, from /usr/include/pthread.h:48, from = /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc/jit/libgccjit.c:27: /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned = "malloc" 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), = mt, (mf)) | ^ . . . In file included from /usr/include/sys/cpuset.h:39, from /usr/include/sched.h:36, from /usr/include/pthread.h:48, from = /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc/jit/jit-recording.c:28: /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned = "malloc" 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), = mt, (mf)) | ^ . . . gmake[4]: *** [Makefile:1142: jit/libgccjit.o] Error 1 gmake[4]: *** Waiting for unfinished jobs.... In file included from /usr/include/sys/cpuset.h:39, from /usr/include/sched.h:36, from /usr/include/pthread.h:48, from = /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc/jit/jit-playback.c:44: /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned = "malloc" 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), = mt, (mf)) | ^ gmake[4]: *** [Makefile:1142: jit/jit-recording.o] Error 1 gmake[4]: *** [Makefile:1142: jit/jit-playback.o] Error 1 rm gcc.pod gfortran.pod gmake[4]: Leaving directory = '/wrkdirs/usr/ports/lang/gcc11/work/.build/gcc' gmake[3]: *** [Makefile:4819: all-stage2-gcc] Error 2 . . . For reference (same sources as used to build for aarch64): # uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #15 = main-n251362-9f32cb5b1c81-dirty: Sun Dec 5 18:17:51 PST 2021 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400043 1400043 # ~/fbsd-based-on-what-commit.sh branch: main merge-base: 9bed79e869721b4ca8a15c527db8d40969867c2c merge-base: CommitDate: 2021-12-06 03:45:47 +0000 9bed79e86972 (HEAD -> main, freebsd/main, freebsd/HEAD) www/drupal9: = update to 9.2.10 n567671 (--first-parent --count for merge-base) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Dec 7 17:49:53 2021 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 4C94D18B1066 for ; Tue, 7 Dec 2021 17:49:58 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J7nr60vhWz4T0B; Tue, 7 Dec 2021 17:49:58 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f1d:f700:f420:16b:af2:5eb4] (p200300cd5f1df700f420016b0af25eb4.dip0.t-ipconnect.de [IPv6:2003:cd:5f1d:f700:f420:16b:af2:5eb4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4F2DF2A141; Tue, 7 Dec 2021 17:49:57 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: <4808c5fb-4d54-ecec-9796-e68cbc07e06d@freebsd.org> Date: Tue, 7 Dec 2021 18:49:53 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: git: 5e04571cf3cf - main - sys/bitset.h: reduce visibility of BIT_* macros Content-Language: de-DE To: Mark Millard Cc: Konstantin Belousov , Mark Johnston , freebsd-current References: From: Stefan Esser In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------UmoqKbeewJtpGFTMvVwxXdNV" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638899398; 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=4lV/8iqoeZwjFOhZn6TeG7xCv3G3JKCedeW1AHK+L10=; b=fxfMosTI+Q862oGE6619lAAz8nm5zXtr2zdbd0xeomQp/n/O4PFgGoAntVppCFcowpid4X m0pLS8az6gpKQnFJXYKQhl422WnNl8ZOezK+tkUj16T9RAaRLHArmFoy5fzN6Gg8/ouVBL 7/cKT2lIlJrhgs8K7/ZrtvyCEk/n1JANj436LlzIjtJs6i3v8GAx0I0IPR/65N/Ac2SaYf rtLYQp/JDEXhaxgZqWn0AGEkHarQaVhCqq21I/aMdavLSlDdqaiBiGCuq3Ylaf4p7XaTZy wUvPj2uWXEiCj1e2vXzwbFVZPCOlkE2Vg/dWPyy0RKkoXQGjilkC62YhktBdFg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638899398; a=rsa-sha256; cv=none; b=TWdZZXCURD2CZg4GwwtJjDOxLip2gR2TVSjhGgawHEjyPC+VB3ZRkzxsOTc9K95jCPcftX aHe6d12Suy2UM/xkNRE1FlgszUM2E2XhvS+Yh0MJAxF835orRFfJ0zmVxlNgXLisUAMwjv YK2R7GiZy+RmY25uD7akHDwOOr9e0Kbn9QsSqCjlvlGt+ZLf9SSox/6J9mXJcNqfHpdXFF T8DN3UYyjsNNSulWJxATgXavkc9Cw1nD/1N91PSk3u5E/xXlWJDYW3i0GVYZEwGA0yNdaI acKXeWX+/2+8spNkxxo27QlFcEDgOxd9stNOXvvyXX5w76XXjO916Lh/FZkVjA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------UmoqKbeewJtpGFTMvVwxXdNV Content-Type: multipart/mixed; boundary="------------KlzVuNV6daWUG0kuODVQRwaZ"; protected-headers="v1" From: Stefan Esser To: Mark Millard Cc: Konstantin Belousov , Mark Johnston , freebsd-current Message-ID: <4808c5fb-4d54-ecec-9796-e68cbc07e06d@freebsd.org> Subject: Re: git: 5e04571cf3cf - main - sys/bitset.h: reduce visibility of BIT_* macros References: In-Reply-To: --------------KlzVuNV6daWUG0kuODVQRwaZ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 07.12.21 um 01:50 schrieb Mark Millard: >=20 >=20 > On 2021-Dec-6, at 14:48, Mark Millard wrote: >=20 >> On 2021-Dec-6, at 14:19, Mark Millard wrote: >> >>> This broke building lang/gcc11 so may be a exp run is appropriate: >>> >>> In file included from /usr/include/sys/cpuset.h:39, >>> from /usr/include/sched.h:36, >>> from /usr/include/pthread.h:48, >>> from /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc= /jit/libgccjit.c:27: >>> /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned "mal= loc" >>> 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), = mt, (mf)) >>> | ^ [...] >> Just like the poudriere-devel based build on aarch64, >> amd64's poudriere-devel based build got: >> >> In file included from /usr/include/sys/cpuset.h:39, >> from /usr/include/sched.h:36, >> from /usr/include/pthread.h:48, >> from /wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc= /jit/libgccjit.c:27: >> /usr/include/sys/bitset.h:314:36: error: attempt to use poisoned "mall= oc" >> 314 | #define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), = mt, (mf)) >> | ^ [...] > This happens from the sequence below, where system.h use in > the: >=20 > work/gcc-11.2.0/gcc/jit/{libgccjit,jit-recording,jit-playback}.c >=20 > builds is what poisons malloc in each case (and poisons more): >=20 > #include "config.h" > #include "system.h" > #include "coretypes.h" > #include "timevar.h" > #include "typed-splay-tree.h" > #include "cppbuiltin.h" > #include >=20 > After the poison-point, new macro definitions can not > reference malloc (and such) --nor can normal code. But > macros defined prior to the poison-point can contain > malloc (and such) and the use of such macros after > the poison point is okay. >=20 > So, if pthread.h is to define a macro referencing > malloc (say), then it needs to be included before > system.h is included in the way that things are set up > in this code. Hi Mark, sorry for (indirectly) causing the breakage ... The problem seems to be the inclusion of extra functionality in sched.h, that is required by a number of programs that use autoconfigure. They probe for one detail of sched.h and then try to use functionality that up to the commit you are referencing had to be hidden (made conditional on _WITH_CPUT_SET_T). The line that contains the malloc() is in a macro definition and AFAIU the situation there is no actual use of __BITSET_ALLOC in the gcc code. In fact, I could not find a single use of BITSEC_ALLOC in userland code. Therefore, the line that contains the malloc could be made conditional on _KERNEL being defined. > I've only tried to build lang/gcc11 (only as supplied > by the port). There could be more failure points for > the lang/gcc11 build that were skipped. At least the other gcc ports. I do not think that there are many other ports that do not accept the definition of a macro using malloc() in the way the poisoning in gcc does. > It seems likely that multiple lang/gcc* would have > such issues but I normally only build the lang/gcc11 > one at this point. I have not tested the other ports, but I do assume the same. I'll try to build the world with BITSET_ALLOC conditional on some macro that is not defined in the gcc build. Regards, STefan --------------KlzVuNV6daWUG0kuODVQRwaZ-- --------------UmoqKbeewJtpGFTMvVwxXdNV Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmGvnsEFAwAAAAAACgkQR+u171r99UQU zwgAyCsgFR4/L4qQzhwbNwUsXG0ALz1ht5NGMDpLP7w8VN6VKq9JXdiOtBFLF7ZZybZP2H0bUcMf KD8FkohxeWPASsYos4PLKjGFBSufmD71SsYfcUfXXdbnIyhza/WVbjKknnu8c3I5gpsQ1VUnkTxQ C8w7NlEsJLHL5EbWoVSYegduSJKgJjMIzQ+VMIwX510Wfht2IKsXADemhUN99nhy+MM1UvSYsgmB ZoZZ1se1SzjrP7mjP7CINAPe23ZUlYiV8i02ga/SEqeF6niYnlUSyS2QuDDIiiwCM+H/8jLkf9gR Z7LA0QePsrntnFeWSclxvhO9IOjWIliNWmoj2F72cQ== =tSZj -----END PGP SIGNATURE----- --------------UmoqKbeewJtpGFTMvVwxXdNV-- From nobody Tue Dec 7 21:26:21 2021 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 2324118553FF for ; Tue, 7 Dec 2021 21:26:35 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J7tf15Lf1z3MsY for ; Tue, 7 Dec 2021 21:26:33 +0000 (UTC) (envelope-from ler@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Type:Message-ID:Subject:To:From:Date:MIME-Version:Sender :Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=o9IrHGTy6/T4yRAxfIWcAw87bzD0a5tO6Uwu6qnNu1c=; b=PIhDDYZT6yj5dm8t1m4Fj85IQ2 MUTPx2vonvstyeJJkkm3hBMs/zsilFK28jNbUIE8mQPmqXD5TVbiQcOy/cGfCLFYKL9pdCpBicxSi LMRIiQMlNYQoI07tdd7l7DpV29TZiOv/RGUiXkvnAVoPUiEg7BscK2wV3CvXWb9iOcGNd06CsXTsO UXbyg44FtDVHrMQ5/7NVkG01ubl8VcYfk0gthbNnjLn+dTml0qeNG8yphQLLYqLeSEJz/FnPR4STG QRxp5YpT9N0nBp59PsMFbEZk/FrWOAjbJcNWvk+XRqL07vFrQZFcx9SRpbzPqPTjknfrnyLA1bqpC TnPmdzkg==; Received-SPF: softfail (thebighonker.lerctr.org: transitioning domain of FreeBSD.org does not designate 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@FreeBSD.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:29677 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1muhyk-000KW1-Jb for freebsd-current@freebsd.org; Tue, 07 Dec 2021 15:26:26 -0600 Received: from 76-250-255-117.lightspeed.austtx.sbcglobal.net ([76.250.255.117]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Tue, 07 Dec 2021 15:26:21 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Tue, 07 Dec 2021 15:26:21 -0600 From: Larry Rosenman To: Freebsd current Subject: installworld: Certificate Error? Message-ID: X-Sender: ler@FreeBSD.org Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_d3baa5a4fc7d740e6251e338a89cc66b"; micalg=pgp-sha256 X-Rspamd-Queue-Id: 4J7tf15Lf1z3MsY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=PIhDDYZT; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4 is neither permitted nor denied by domain of ler@FreeBSD.org) smtp.mailfrom=ler@FreeBSD.org X-Spamd-Result: default: False [-3.13 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; HAS_ATTACHMENT(0.00)[]; DMARC_NA(0.00)[FreeBSD.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.27)[0.270]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_d3baa5a4fc7d740e6251e338a89cc66b Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed -------------------------------------------------------------- >>> Installing everything completed on Tue Dec 7 15:23:33 CST 2021 -------------------------------------------------------------- 68.45 real 262.43 user 95.61 sys Scanning /mnt/usr/share/certs/untrusted for certificates... Scanning /mnt/usr/share/certs/trusted for certificates... Scanning /mnt/usr/local/share/certs for certificates... Scanning /mnt/usr/local/etc/ssl/certs for certificates... unable to load certificate 67912877395968:error:0909006C:PEM routines:get_name:no start line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE Error: /mnt/usr/local/etc/ssl/certs/ecpubkey.pem *** [installworld] Error code 1 [I] âžœ cat /mnt/usr/local/etc/ssl/certs/ecpubkey.pem -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE/ZGaXNnGRqI4vEFFlrs3HNfyWjeL 5HcODD2mLHyvI+948pNZ9ngZl/afkZZZOHwcnlChxcBwNsgPFBXf1ZqKIA== -----END PUBLIC KEY----- ler in src î‚¢ at ler-r610 on î‚  main [?] [I] âžœ Can someone fix this? -- Larry Rosenman http://people.freebsd.org/~ler Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 --=_d3baa5a4fc7d740e6251e338a89cc66b Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=488 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEHjgknedhWzvJgwVzaXyZsatIp30FAmGv0YIACgkQaXyZsatI p32HcggAqjBZoAnqA8ECVHHMd1TX9bUqApUjJO2j7wlUGetIeIDD/k0tfNq9XudZ hDuFShvwIk3Wm8cKpeJV3iSCKVwl9K1UpwDZrSxvAwQc3Oz2rExWPxIEyxwKNtZg iWluwFERRTjZyOHpAD3y2QW4KSaQzOZQ2Gw6Pe3uRlnqHDatSdChsmIolLxRtKNx V3BHunr19Ulm1uw4lR7f4oQUZo7ihfxz+mAccFKhsNBl/NYk8IW/b6kU2FgluS4w kXQ4TjAoqxssCUa8ziojQt+8Nx5kr5Qge9qnvflyj036bSsizuxkXZ4ZOGuOvhs3 cFmmF+sKIbvk7xgXhR7p76BBtOFizw== =/gRh -----END PGP SIGNATURE----- --=_d3baa5a4fc7d740e6251e338a89cc66b-- From nobody Tue Dec 7 23:04:20 2021 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 826DA18CBAAC for ; Tue, 7 Dec 2021 23:04:34 +0000 (UTC) (envelope-from kevans@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J7wq60mHHz3rGl; Tue, 7 Dec 2021 23:04:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id E9A132CFD0; Tue, 7 Dec 2021 23:04:33 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f171.google.com with SMTP id j17so730306qtx.2; Tue, 07 Dec 2021 15:04:33 -0800 (PST) X-Gm-Message-State: AOAM532YxJpNVs0OLhpya41drhkujEgDDv8bWXa+jsYU3ejQVNy/nA56 xI7tLBt0pRaRwpvaEv8/XzuzcKvhNO+jN/dczOw= X-Google-Smtp-Source: ABdhPJw8jfV1VRTScJ3WEOTrkJ8mqvkduiG9xO1mrbB6PTO7IamjcJUbd70YyiDhHOuU5QhBq6XFq1shkxbI7epX10E= X-Received: by 2002:ac8:58ca:: with SMTP id u10mr3122765qta.44.1638918272917; Tue, 07 Dec 2021 15:04:32 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Tue, 7 Dec 2021 17:04:20 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: installworld: Certificate Error? To: Larry Rosenman Cc: Freebsd current Content-Type: multipart/alternative; boundary="00000000000079263c05d29665b0" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638918274; 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=bPot7zRElhA5u2pFLrpkyxKGKL38PMZgoXM/FnteNXU=; b=CbedOzjzlboj6t4lxuEjFkUDQQvV/9U3XFkBaJjn/qsNPFeEnp6v9ZIq5ZvRoKXDbKTzaT ZBgR/14ab5NL8dRt4f55iB4CvYLvduaKJIQjQfMYj4DJ6b7vU16CeavbcgemvzuGf6ED1E vMYw4VrdibGF0OC0kopDnnUm5B9kYtNeS6extgIzrD4YbNkL2StlS24nYaY48pQOWXYvzd v5h94H4q9T3P4U3hXPHR6PzBbaWGeVg+PEf9BtKBsE+aUn6GRvhYXu3Mz519is7ERBmIKA eLXlNYosNgoOHAIB1SThzbSrkq9Bszq0WuGrAdDKq+i1nFDhkrmhGFex+ZyuYA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638918274; a=rsa-sha256; cv=none; b=T5ziOJO49KxJSulD0ecx/j8GsgJtlVHMYJ/gnc0ChW7ehXc3RX5mPXxjtaxjsJQBNQEk90 sjzpLTvD+kgbSNcjLDlZx7LHESm0FA+5t4zPDLh6cZHVNw04oEnN0/s/nY1Yiv+QUvknat t9Iz8JpGsO3bC6aikWS9BuySA7EO5oqaMM36H911CpazgcqWDmSjgu5kcYCxVhmEdwzNL1 1sC3ymKPOXbLKm3w67DrkkpWJE2QPaVm7axtamJ2Hv92aS/HzXknzHCb8Ze4PxE9j5GsrP 3m564qLDVhVyvWr6pH9xNfaZwSQArf7P/vK7BHD38TDeyBS9be+hA1NcIdSuNg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: Y --00000000000079263c05d29665b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Where did this ecpubkey.pem come from? On Tue, Dec 7, 2021, 15:28 Larry Rosenman wrote: > > -------------------------------------------------------------- > >>> Installing everything completed on Tue Dec 7 15:23:33 CST 2021 > -------------------------------------------------------------- > 68.45 real 262.43 user 95.61 sys > Scanning /mnt/usr/share/certs/untrusted for certificates... > Scanning /mnt/usr/share/certs/trusted for certificates... > Scanning /mnt/usr/local/share/certs for certificates... > Scanning /mnt/usr/local/etc/ssl/certs for certificates... > unable to load certificate > 67912877395968:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: TRUSTED > CERTIFICATE > Error: /mnt/usr/local/etc/ssl/certs/ecpubkey.pem > *** [installworld] Error code 1 > > [I] =E2=9E=9C cat /mnt/usr/local/etc/ssl/certs/ecpubkey.pem > -----BEGIN PUBLIC KEY----- > MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE/ZGaXNnGRqI4vEFFlrs3HNfyWjeL > 5HcODD2mLHyvI+948pNZ9ngZl/afkZZZOHwcnlChxcBwNsgPFBXf1ZqKIA=3D=3D > -----END PUBLIC KEY----- > > ler in src =EE=82=A2 at ler-r610 on =EE=82=A0 main [?] > [I] =E2=9E=9C > > Can someone fix this? > > > -- > Larry Rosenman http://people.freebsd.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 > > --00000000000079263c05d29665b0-- From nobody Tue Dec 7 23:05:22 2021 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 4D76818CC019 for ; Tue, 7 Dec 2021 23:05:23 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J7wr30FMTz3s4D; Tue, 7 Dec 2021 23:05:23 +0000 (UTC) (envelope-from ler@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To: From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=atXKkNOonCpmyqRCs3wlwUpwT7kR1i0c7lYrmIkVNyQ=; b=m+PXY34KFW9qEemDIOzleftYwI Xo1r20hZEQcT8fFdU+BWg+9macYA9J/SjZXEHH3yOIHhx2ToyKWTqzkgQj+TL3KTJqCSAU4Vc2gOC NHfpuA4JNHFziZpc3LAZP2tBlBpBIQCRYFjb7+r2Q+DxNKRQTslhONnmDg3ogD3k4L5qR6giN+iec wpwS5QgV/nEP1/qDNXOrCmgcKrTIIfswqRmwBbVdiKFW46kb+WmM/Rz3MnIY0zH9QkPaGnsrX8eNM P7Br8qBXuBKeyLe/W56rq4n9zulJGgoZfmVWtV5ARMIWHn5WG2NqyVkvGoY9qXevUMv27uXqZe3X6 X+Worxwg==; Received-SPF: softfail (thebighonker.lerctr.org: transitioning domain of FreeBSD.org does not designate 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@FreeBSD.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:22492 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mujWU-000M4h-4T; Tue, 07 Dec 2021 17:05:22 -0600 Received: from 76-250-255-117.lightspeed.austtx.sbcglobal.net ([76.250.255.117]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Tue, 07 Dec 2021 17:05:22 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Tue, 07 Dec 2021 17:05:22 -0600 From: Larry Rosenman To: Kyle Evans Cc: Freebsd current Subject: Re: installworld: Certificate Error? In-Reply-To: References: Message-ID: <0f1d268d393a4f42e737b92222f6aff9@FreeBSD.org> X-Sender: ler@FreeBSD.org Content-Type: multipart/alternative; boundary="=_6044998734ed57864d39b1ed493f67a7" X-Rspamd-Queue-Id: 4J7wr30FMTz3s4D X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --=_6044998734ed57864d39b1ed493f67a7 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed I have no clue. On 12/07/2021 5:04 pm, Kyle Evans wrote: > Where did this ecpubkey.pem come from? > > On Tue, Dec 7, 2021, 15:28 Larry Rosenman wrote: > >> -------------------------------------------------------------- >>>>> Installing everything completed on Tue Dec 7 15:23:33 CST 2021 >> -------------------------------------------------------------- >> 68.45 real 262.43 user 95.61 sys >> Scanning /mnt/usr/share/certs/untrusted for certificates... >> Scanning /mnt/usr/share/certs/trusted for certificates... >> Scanning /mnt/usr/local/share/certs for certificates... >> Scanning /mnt/usr/local/etc/ssl/certs for certificates... >> unable to load certificate >> 67912877395968:error:0909006C:PEM routines:get_name:no start >> line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: >> TRUSTED >> CERTIFICATE >> Error: /mnt/usr/local/etc/ssl/certs/ecpubkey.pem >> *** [installworld] Error code 1 >> >> [I] âžœ cat /mnt/usr/local/etc/ssl/certs/ecpubkey.pem >> -----BEGIN PUBLIC KEY----- >> MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE/ZGaXNnGRqI4vEFFlrs3HNfyWjeL >> 5HcODD2mLHyvI+948pNZ9ngZl/afkZZZOHwcnlChxcBwNsgPFBXf1ZqKIA== >> -----END PUBLIC KEY----- >> >> ler in src î‚¢ at ler-r610 on î‚  main [?] >> [I] âžœ >> >> Can someone fix this? >> >> -- >> Larry Rosenman http://people.freebsd.org/~ler >> Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org >> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 -- Larry Rosenman http://people.freebsd.org/~ler Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 --=_6044998734ed57864d39b1ed493f67a7-- From nobody Tue Dec 7 23:10:19 2021 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 54A3918CE23B for ; Tue, 7 Dec 2021 23:10:20 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J7wxm1LzZz3v11; Tue, 7 Dec 2021 23:10:20 +0000 (UTC) (envelope-from ler@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To: From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=BbJ/dEuQBsvC4vTJBhkx2FYktyJI7Cc4TB9M+GxR85o=; b=HzFIFeecSHq+4LnUed5rUGT0F8 U1VDuZgRDmASW95XT/esg7+aTI451VxGeFT/F+Mw1KDY7H7xbEUu0jXcRrq+ZpEt2gMFdEwEq5WDa o8CekqEbENPL0MbDZPfLnDkJ8uQOhjEzOB/7+RKQjRt/5gckYoPw4sYxsuSSzqdQu89a/OUkYKjRo 2okZtpQBxN+bY8JrlDO3eK9CLBjYdGZYms/5eOIYDTjNxM613Hi2dBLNAn9EErfGlqMV11puGJ2zT Qlmz9aGvczDLjnQPUQXD6g2qRDX4AU7HPd7InXpG6YqhbQ81Yg8BoQVYEERXPj0bgDO9Wpc4xTdW9 nQJjLuTw==; Received-SPF: softfail (thebighonker.lerctr.org: transitioning domain of FreeBSD.org does not designate 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@FreeBSD.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:43289 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mujbH-000M8P-FM; Tue, 07 Dec 2021 17:10:19 -0600 Received: from 76-250-255-117.lightspeed.austtx.sbcglobal.net ([76.250.255.117]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Tue, 07 Dec 2021 17:10:19 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Tue, 07 Dec 2021 17:10:19 -0600 From: Larry Rosenman To: Larry Rosenman Cc: Kyle Evans , Freebsd current Subject: Re: installworld: Certificate Error? In-Reply-To: <0f1d268d393a4f42e737b92222f6aff9@FreeBSD.org> References: <0f1d268d393a4f42e737b92222f6aff9@FreeBSD.org> Message-ID: <361eb5c4be4c6a357d668a8ee15c08a6@FreeBSD.org> X-Sender: ler@FreeBSD.org Content-Type: multipart/alternative; boundary="=_c1704de994d3afde77f89b9c1f8669bd" X-Rspamd-Queue-Id: 4J7wxm1LzZz3v11 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --=_c1704de994d3afde77f89b9c1f8669bd Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Looks like I picked it up when I installed this box. Removed. Sorry for the noise. :( On 12/07/2021 5:05 pm, Larry Rosenman wrote: > I have no clue. > > On 12/07/2021 5:04 pm, Kyle Evans wrote: > > Where did this ecpubkey.pem come from? > > On Tue, Dec 7, 2021, 15:28 Larry Rosenman wrote: > -------------------------------------------------------------- >>>> Installing everything completed on Tue Dec 7 15:23:33 CST 2021 > -------------------------------------------------------------- > 68.45 real 262.43 user 95.61 sys > Scanning /mnt/usr/share/certs/untrusted for certificates... > Scanning /mnt/usr/share/certs/trusted for certificates... > Scanning /mnt/usr/local/share/certs for certificates... > Scanning /mnt/usr/local/etc/ssl/certs for certificates... > unable to load certificate > 67912877395968:error:0909006C:PEM routines:get_name:no start > line:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:745:Expecting: > TRUSTED > CERTIFICATE > Error: /mnt/usr/local/etc/ssl/certs/ecpubkey.pem > *** [installworld] Error code 1 > > [I] âžœ cat /mnt/usr/local/etc/ssl/certs/ecpubkey.pem > -----BEGIN PUBLIC KEY----- > MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE/ZGaXNnGRqI4vEFFlrs3HNfyWjeL > 5HcODD2mLHyvI+948pNZ9ngZl/afkZZZOHwcnlChxcBwNsgPFBXf1ZqKIA== > -----END PUBLIC KEY----- > > ler in src î‚¢ at ler-r610 on î‚  main [?] > [I] âžœ > > Can someone fix this? > > -- > Larry Rosenman http://people.freebsd.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 -- Larry Rosenman http://people.freebsd.org/~ler Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 -- Larry Rosenman http://people.freebsd.org/~ler Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 --=_c1704de994d3afde77f89b9c1f8669bd-- From nobody Wed Dec 8 15:05:16 2021 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 9523518E41B9 for ; Wed, 8 Dec 2021 15:05:34 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8L7x4lg2z4SWy for ; Wed, 8 Dec 2021 15:05:33 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 2C18A10A32F6 for ; Wed, 8 Dec 2021 16:05:25 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 3C55110A3310 for ; Wed, 8 Dec 2021 16:05:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1638975923; 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=zQ0DgrSrs/4geCIprw6obG3E/9WlvpHHzzRNCBL9690=; b=rt9taPYNxfenMc/Q4cAPb5n6ZtvUOYmSfTlYVE//XIS9F1aZrs+qDgNcbseB9y2tqtAb88 p7d36MGPKSnY4FODdxhuN5zsISSYT4O5CMhwFMO6avBYlJbHYr5OovmoV1Rq6jSweZFcmh FLqPx9LHkofssgl+pirj+hPKt/dMl/6DV1G9sn1pa9UsD5bBwrboIOm+Bib8r8aNqRE2dq pD5/AADfhFeGGdAGHZ3wFp+WQlQVKkhnyMq3PzqJ14x9MIjISXho/yO9Qf5uU3sCMbwFy1 K+8UktDAsf8cb3OdAIeO9IeEKk9PSiByRm5bVM8lDbG1RCuaeRvK1JerJCG7uw== Received: from freyja (p5de88214.dip0.t-ipconnect.de [93.232.130.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 06D1010A330E for ; Wed, 8 Dec 2021 16:05:22 +0100 (CET) Date: Wed, 8 Dec 2021 16:05:16 +0100 From: FreeBSD User To: freebsd-current Subject: CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress Message-ID: <20211208160516.665649dd@freyja> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 7c9e44 X-Rspamd-UID: dcd5f2 X-Rspamd-Queue-Id: 4J8L7x4lg2z4SWy X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=rt9taPYN; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-0.79 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt-de.de]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_HAM_SHORT(-0.99)[-0.994]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[93.232.130.20:received] X-ThisMailContainsUnwantedMimeParts: N Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD 14.0-CURRENT #7 main-n251463-935dc0de881: Wed Dec 8 06:49:25 CET 2021 amd64) fails with the linker error shown below. Due to this error, no FreeBSD pkg base nor NanoBSD Image can be build. [...] cc -O2 -pipe -O3 -fno-common -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelftc -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common -DNDEBUG -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments -I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/include -static -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib -o nm nm.o -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf -ldwarf -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc -lelftc_pie -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -legacy ld: error: undefined symbol: uncompress >>> referenced by libdwarf_elf_init.c >>> libdwarf_elf_init.o:(_dwarf_elf_init) in archive >>> /usr/lib/libdwarf.a cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [nm] Error code 1 From nobody Wed Dec 8 15:43:41 2021 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 0E4B218C305E for ; Wed, 8 Dec 2021 15:43:45 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8M006kdFz4Xht for ; Wed, 8 Dec 2021 15:43:44 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-il1-x130.google.com with SMTP id j21so2544413ila.5 for ; Wed, 08 Dec 2021 07:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mUoH8BINObSqohQUh4C2odd9MQAgTb3tVIQ3cVqHdT0=; b=P1wmRjCDnpxjKQoko/FXCobmFSxVmL0MnAcm9gyO7DqOLNOV8d9rV3xe7iDB1F8HP3 4RsImmufBAigDotvUqijJ22u1I9ju7nGnxtcYpBk1HxFk3mfWp9Mtome5ienJbKbRQ5X ezZW+kaQspEcTm96nzGiDitK6oNFAm8VK4lAtyjP/oftvArSvpG4+F1QE2raKE/dIgql W5aQXHp/ZEBpD0R8wv3MZwta+hE5UqElotikK2YGs4AgDada04XFQl2SjqWCzj5vKGQU FHaiDxbKeZJPgdfNl6RqwlDxm2J7s4YiKKA/R4SxsXOxjo0g2talKICfCptpkuDRjd0V ioxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=mUoH8BINObSqohQUh4C2odd9MQAgTb3tVIQ3cVqHdT0=; b=7Lakxh9E8nc7TSQYpjzXk8EowvV48fMSwN28J4KSZldlFFGIlPWUVxGu7nPfkf5NM0 X0HeytXcAIMDeWhwlSm0TrHvAyvyTNWTNi0CttPnvs/YfbMr5bSURzAxcfzhx12Q78IL Gt+0dkDv4apKkGhZp03Z/R1zotRw1mH8Sx/2p36tE09SgMGkpLNGCcsr0saerxnZ11vi pbvaSEak5/Py2t1QmGe9PnBR2OJsc47FDK3gTcuCzkfigicsuuvPKwsJP0DxZxlkC9hU QnvdTEQQQrigQXNpl9gIxDEavHd1E/ivqjG/GF5cll49RrTEZG9bD0gDizXXt3nvLCRY g+MA== X-Gm-Message-State: AOAM533pmyWPCTNtBsNX3sf9AKBi5A2idfhL66Oq0NuQN0mwNpA2PXMF yEgZqClJpeYRsu7J91swGw/OwqIhJKmPYw== X-Google-Smtp-Source: ABdhPJzzjlyLQOxjOmU08/nqVJK686NuAqOTNqXbHA0Q33boYffCRx5pi+cmC591mBSkxVI4f2k3vw== X-Received: by 2002:a05:6e02:160c:: with SMTP id t12mr7623994ilu.250.1638978224220; Wed, 08 Dec 2021 07:43:44 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id s18sm1969796ilq.25.2021.12.08.07.43.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Dec 2021 07:43:43 -0800 (PST) Date: Wed, 8 Dec 2021 10:43:41 -0500 From: Mark Johnston To: FreeBSD User Cc: freebsd-current Subject: Re: CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress Message-ID: References: <20211208160516.665649dd@freyja> 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: <20211208160516.665649dd@freyja> X-Rspamd-Queue-Id: 4J8M006kdFz4Xht X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Dec 08, 2021 at 04:05:16PM +0100, FreeBSD User wrote: > Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD 14.0-CURRENT > #7 main-n251463-935dc0de881: Wed Dec 8 06:49:25 CET 2021 amd64) fails with the > linker error shown below. > > Due to this error, no FreeBSD pkg base nor NanoBSD Image can be build. > > > [...] > cc -O2 -pipe -O3 -fno-common > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelftc > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common -DNDEBUG > -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align -Wchar-subscripts -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations > -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > -Wno-error=unused-but-set-variable -Qunused-arguments > -I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/include > -static > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib > -o nm nm.o > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf > -ldwarf > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf > -lelf > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc > -lelftc_pie > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf > -lelf -legacy ld: error: undefined symbol: uncompress > >>> referenced by libdwarf_elf_init.c > >>> libdwarf_elf_init.o:(_dwarf_elf_init) in archive > >>> /usr/lib/libdwarf.a > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** [nm] Error code 1 Is this build using WITHOUT_CLEAN? If so I think you'll need to try a clean build if you had previous built world between dbf05458e3bd and 8d5d329553b3. From nobody Wed Dec 8 17:05:17 2021 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 17DAA18D2EC9; Wed, 8 Dec 2021 17:05:20 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8Np76jJLz4jW6; Wed, 8 Dec 2021 17:05:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 2EA3435B85; Wed, 8 Dec 2021 17:05:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <2e894793-f860-3415-1f5d-26fd5e85a69d@FreeBSD.org> Date: Wed, 8 Dec 2021 09:05:17 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook Content-Language: en-US To: Miroslav Lachman <000.fbsd@quip.cz>, Yetoo Happy , freebsd-doc@freebsd.org Cc: freebsd-current@freebsd.org References: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> From: John Baldwin In-Reply-To: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638983119; 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=evVsH5Nf24EYoYTE5prKH4P856yHlXYFDxcv9rCdnPo=; b=Z2UAfGHo5sK7xhmQsCrgtMHYuqkKEhodGnWqJbYRe92vgO4yzHJarNg49s58sU/Y2b0YAQ Mx/FPxeAKU9R3f2IkH2R03yz8qDP1dZhtEJmLeNMnl4RXEQ12GeAInKESpLm0fV3D43A3B /9tOrSWyHMD6LvjF/15L6/uiY8LxrPFYPwtEe7Ch+MkmL6C3ju/Ft9kPfNwNqw/j30NPh2 wC3nQ4fh21/lD5nre0vJb6XlXaedkQe9GBcrRaTvxx8IZr/mQzNVoSlHqkjw/rVEhbrmsD eGstgNTHJGG3reReHT+vMf5ClgbtrZ7jQcH02A7VAF5rIA043UP5NqRELHExAQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638983119; a=rsa-sha256; cv=none; b=yobUelE01q8CWXleAxj8GExjS9NWNI5gmogAOgAmrNfmNvpf8x9sko81dcHW/f5+FieT8O sc5BXrrLsBeDk7m7SNcSYzu3hyz2ARtr8ucQ32Qz9Ia3o+cHc6iwQcBfc3A8XTVAq9lvX+ am6OO/9rEuWceP/ehf1S+Qt3+0FiQQg3OBhoaTasxbzjaXCV1jbgH4R2cjSkuk+8xOSM6z 8nPoq0rlvuEnD7yMX8/aS0BLja8Ne1jdYRBz6LcpeT1M57jCQIUkZ6cN1FBPvulWZmqnVN k58+QxF8+Clx6KlUjU71c7ygVbHOWGZ4suqSWgQS0RKpISXzh1X5bagGNk3kKA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/3/21 4:58 AM, Miroslav Lachman wrote: > So beside the update of documentation I really would like to see some > changes to etcupdate workflow where files are modified in temporary > location and moved to destination only if they do not contain any syntax > breaking changes like <<<<, ====, >>>>. This is what etcupdate does, so I'm a bit confused why you are getting merge markers in /etc. When an automated 3-way merge doesn't work due to conflicts, the file with the conflicts is saved in /var/db/etcupdate/conflicts/. It is only copied to /etc when you mark it as fully resolved when running 'etcupdate resolve'. Perhaps you had multiple conflicts in a modified file and when editing the file you only fixed the first one and then marked it as resolved at the prompt? Even in that case etcupdate explicitly prompts you a second time after you say "r" with "File still has conflicts, are you sure?", so it will only install a file to /etc with those changes if you have explicitly confirmed you want it. -- John Baldwin From nobody Wed Dec 8 17:11:05 2021 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 2A2A518D45DF for ; Wed, 8 Dec 2021 17:11:07 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8Nwp6KLDz4kts; Wed, 8 Dec 2021 17:11:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4E112356A9; Wed, 8 Dec 2021 17:11:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <98af77aa-628d-5fce-7618-36b1edaa405b@FreeBSD.org> Date: Wed, 8 Dec 2021 09:11:05 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook Content-Language: en-US To: Tomoaki AOKI , freebsd-current@freebsd.org Cc: jbtakk@iherebuywisely.com References: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> <20211204110942.11553b693b165364f3ab31c0@dec.sakura.ne.jp> From: John Baldwin In-Reply-To: <20211204110942.11553b693b165364f3ab31c0@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638983466; 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=ePy6/FJqGb+pByS2AZLAiR3onRZCN8fc9onVy4kipyE=; b=pW4mYATTLddG5cIVQ2HzTq6i7kgVhTX7YiXD1oYFER3kPWx/tZ7+IqWS6hOnxW72hMjWas 4BYU8wnnVyxyDQjeurQX92FdKHk4b+1WRMWsdWzY6xwBwkGAfSJkmKnGE68Kk+DrPgOEjx zJ1swj42LCPxptKZ3E5D+saOjeFP+ZWZgDVckaCx5RhJgl4EkOSvIjN1p5NjBu/E70WRIU iwBOpvKSJOn6dfHC4toAk3kLhANYZzeqlbwxG8tarvos2/LI268cecl9JaLMMvXC1gNEyl 0rOiWaZuOWQLNU90VszTmBqmzZZsQqJ1i7ZLASk5rgxQXLyssdAgVptcgLuKMw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638983466; a=rsa-sha256; cv=none; b=c9tex3uzk949KpR+6/x2Z5lTw0wsXL0EUBjVJfSpzbharu+ohwm8uWskHlXGuFkL3NfDW+ dBI4W2FMIpKXo85gKlNBcGxGeRf0uG5zwpwYn5jnT8uT9lIW0QakJ+vpUjqZIPswamJ5d2 Q9QVpOrcl42ovPwFDwhSjDCj9yUkBJfI1TeTSUVd465XDyhNI759B++gTZaflTczSp/bkM dN1pVUw0QXn/ArcTrpBH3koRDchAA6o5D/osGHTABiql+w2ZkmQ1mOdG/GO47gDNGdVULq wo1FCUVIB/vqFb3g0JUDv5LxvxuuPROcthxI7ws/o5AhM9rA+tR9zW6e5jtyXA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/3/21 6:09 PM, Tomoaki AOKI wrote: > On Fri, 03 Dec 2021 05:54:37 -0800 (PST) > "Jeffrey Bouquet" wrote: > >> >> >> On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.fbsd@quip.cz> wrote: >> >>> On 03/12/2021 12:52, Yetoo Happy wrote: >>> >>> [...] >>> >>>> Quick Start* and follow the instructions and get to step >>>> 7 and may think that even though etcupdate is different from mergemaster >>>> from the last time they used the handbook they have faith that following >>>> the instructions won't brick their system. This user will instead find that >>>> faith in general is just a very complex facade for the pain and suffering >>>> of not following *24.5.6.1 Merging Configuration Files* because the user >>>> doesn't know that step exists or relevant to the current step and ends up >>>> unknowingly having etcupdate append "<<<< yours ... >>>>> new" to the top >>>> of the user's very important configuration files that they didn't expect >>>> the program to actually modify that way when they resolved differences nor >>>> could they predict easily because the diff format is so unintuitive and >>>> different from mergemaster. Now unable to login or boot into single user >>>> mode because redirections instead of the actual configuration is parsed the >>>> user goes to the handbook to find out what might have happened and scrolls >>>> down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. >>> >>> [...] >>> >>> That's why I think etcupdate is not so intuitive as tool like this >>> should be and etcupdate is extremely dangerous because it intentionally >>> breaks syntax of files vital to have system up and running. >>> If anything goes wrong with mergemaster automatic process then your have >>> configuration not updated which is almost always fine to boot the system >>> and fix it. But after etcupdate? Much worse... >>> >>> I maintain about 30 machines for 2 decades and had problems with >>> etcupdate many times. I had ti use mergemaster as fall back many times. >>> Mainly because of etcupdate said "Reference tree to diff against >>> unavailable" or "No previous tree to compare against, a sane comparison >>> is not possible.". And sometimes because etcupdate cannot automatically >>> update many files in /etc/rc.d and manual merging of a lot of files with >>> "<<<< ==== >>>>" is realy painful while with mergemaster only simple >>> keyboard shortcuts will solve it. >>> All of this must be very stressful for beginners. >>> >>> So beside the update of documentation I really would like to see some >>> changes to etcupdate workflow where files are modified in temporary >>> location and moved to destination only if they do not contain any syntax >>> breaking changes like <<<<, ====, >>>>. >>> >>> Kind regards >>> Miroslav Lachman >> >> >> Agree. I fell back to mergemaster this Nov on 13-stable when the /var files >> pertaining to etcupdate were all missing current /etc data, and no study of >> man etcupdate was clear enough to rectify such a scenario, and suspect my >> initial use of etcupdate will or may require a planned reinstall, not having >> had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and >> I am just hoping mergemaster stays in /usr/src and updated >> for system changes, even if moved to 'tools' or >> something, since its use seems intuitive and much less of a black box. >> Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still. >> > > Not sure it's fixed or not (tooo dangerous to try...), -n (dry-run) > option of etcupdate is now quite harmful. Maybe by any commit done in > this april on main (MFC'ed to stable/13 in june). > > *I got busy manually checking and applying changes to /etc, and > forgot to file PR. > > Doing `etcupdate -n` itself runs OK, but following `etcupdate -B` does > NOT do anything, hence nothing is actually updated. > The only workaround I have is NOT to try dry-run. Humm. > It would be because the same trees are used for dry-run and actual run. > (Not looked into the code. Just a thought.) So the new changes always build a temporary tree (vs trying to build /var/db/etupdate/current in place). For -n it should be that it just doesn't change /var/db/etcupdate/current at the end, but if it did the move anyway that would explain the bug you are seeing. That does indeed look broken. Please file a PR as a reminder for me to fix it. -- John Baldwin From nobody Wed Dec 8 17:48:42 2021 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 A67F518DBBBA for ; Wed, 8 Dec 2021 17:48:44 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8PmD2hJJz4qK0; Wed, 8 Dec 2021 17:48:44 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f1d:f700:552c:777b:d2b8:dac9] (p200300cd5f1df700552c777bd2b8dac9.dip0.t-ipconnect.de [IPv6:2003:cd:5f1d:f700:552c:777b:d2b8:dac9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 95B9035B49; Wed, 8 Dec 2021 17:48:43 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: <3acc005b-12c2-b847-0f35-b95ee9b7e98a@freebsd.org> Date: Wed, 8 Dec 2021 18:48:42 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook Content-Language: en-US To: John Baldwin Cc: jbtakk@iherebuywisely.com, Tomoaki AOKI , freebsd-current@freebsd.org References: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> <20211204110942.11553b693b165364f3ab31c0@dec.sakura.ne.jp> <98af77aa-628d-5fce-7618-36b1edaa405b@FreeBSD.org> From: Stefan Esser In-Reply-To: <98af77aa-628d-5fce-7618-36b1edaa405b@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------0WHj4RgK0ykHdptbyV7JH0O0" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638985724; 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=fvCcNIMqz6G2re7KrlxwLWhooUf0dmPXgnIexMfVWl8=; b=pgtXw1CyQphzwR5wQ0/tu4neqaDwyWj/BpkxNz3y4s7wrx5Br+p+cRZv4EEDxqpnJftQAN sTi3ifj84eNAOV/3iUtGjGjSzWZZUpoS699XynZOX2hSxmi2fGWhdE06QJTAwmAmnabTbb tkssa6Shl1x1C4lUA4DeFYahfs84OX0XuQUYcqMvvwZqz1XDYKI/j9xIv1AiyastDhEtH+ ZbHcnjyJuz9VH8s8DX9Yf0SjhKkTkrqiu/ZYxLlQTJvRPn1+K6LwPxp6MJtAFK8MxLFgv2 f9Q9LhsbUyCeqb/iULPuVLT3ABNx8YgZGPjDr+SG4wpSMyAvyshsZaifovdk9A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638985724; a=rsa-sha256; cv=none; b=j9jE3HvSS464TTLkaswswOOUBGteVnML39xLj19VAAZgw13NdGt/eCLUl73HrmdYHyivc+ 9FtusI0tpEoVXMWh2hDlyqxuzSUE58yCnDkA+ElOHYA+n4AI9FTrpxiXWTrMnxoa6iXpZv I0Bqg5OCYeeRr8Wm4E5NPg95b3bP0w5KOK8FguBU7uDVsdOg5UeN4/7xhdl1wCYxxjMXGg 0myDwcMRXPfTpZiHFYeJmUlNT1swtIVUm/l/E6B9UK6goftm7NehInKIppKYs3TLSb1LZH n7VV+ZjVotWexyAhVZ+B07cJVLze6sPTEH4ERVnzKCndEOv9398wemS/8337Eg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0WHj4RgK0ykHdptbyV7JH0O0 Content-Type: multipart/mixed; boundary="------------uTJVBp0DbvLjAv026g8xP7Oy"; protected-headers="v1" From: Stefan Esser To: John Baldwin Cc: jbtakk@iherebuywisely.com, Tomoaki AOKI , freebsd-current@freebsd.org Message-ID: <3acc005b-12c2-b847-0f35-b95ee9b7e98a@freebsd.org> Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook References: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> <20211204110942.11553b693b165364f3ab31c0@dec.sakura.ne.jp> <98af77aa-628d-5fce-7618-36b1edaa405b@FreeBSD.org> In-Reply-To: <98af77aa-628d-5fce-7618-36b1edaa405b@FreeBSD.org> --------------uTJVBp0DbvLjAv026g8xP7Oy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 08.12.21 um 18:11 schrieb John Baldwin: > So the new changes always build a temporary tree (vs trying to build > /var/db/etupdate/current in place).=C2=A0 For -n it should be that it j= ust > doesn't change /var/db/etcupdate/current at the end, but if it did the > move anyway that would explain the bug you are seeing.=C2=A0 That does = indeed > look broken.=C2=A0 Please file a PR as a reminder for me to fix it. If you work on this then please have a look at PR 247519, too: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247519 This problem lead to my complete customized /etc getting lost when I invoked etcupdate with WITH_DIRDEPS_BUILD defined in /etc/src-env.conf. But I can imagine other reasons that let the make commands in build_tree(= ) fail without error exit, leading to an empty etcupdate/current tree and subsequent deletion of files in /etc. Regards, STefan --------------uTJVBp0DbvLjAv026g8xP7Oy-- --------------0WHj4RgK0ykHdptbyV7JH0O0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmGw7/oFAwAAAAAACgkQR+u171r99UQA 9wf/U/ZcnQ+apX6zJXiaqLfOVjiAgNf/R1oYngXILar609q1F/N1Ps/tShQnK1lwNyGjZgPd2pCQ bkUrbeyv1/CPWQTfaiCBzoIo4FWyuVqADrgH7+OX2PjXlctzsoH4sFylwXtDirU2LVPD8YQuXefL 64I14rMM4OxZ38G0S50L2kk4UOcwdqrfIve7KCYGZKbOAb/JAUpUHPGAnStT2kScUXnsXiu9T3bV WEv1eA7tds0koeqfMDujK1RFzMPQQtwtoxPgIfqcsKlyowWnKaw21N8MMXV+If4MXv9E0dWT3ksF 0I5RhnGK1Va53t7LrF77TuOBzutY+wKRdBkf6FVb3w== =cdEP -----END PGP SIGNATURE----- --------------0WHj4RgK0ykHdptbyV7JH0O0-- From nobody Wed Dec 8 21:33:31 2021 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 317FA18E5863; Wed, 8 Dec 2021 21:33:48 +0000 (UTC) (envelope-from yetoohappy@gmail.com) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8Vlw0dNkz3rVC; Wed, 8 Dec 2021 21:33:48 +0000 (UTC) (envelope-from yetoohappy@gmail.com) Received: by mail-lf1-x130.google.com with SMTP id n12so8266886lfe.1; Wed, 08 Dec 2021 13:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WDlQl/AYUQzhE3zaHYFhiZZcChwEiQTpo55VP40eQ8c=; b=F5oHWW2Ka3i5UK8Jww78x1vV3fDHqKpVCAeys6DdG4fxr5elPMaW0k2b5Z2jyUOVMQ DgKCry+OCwdUkFQv/5bAeVtCyxIT3o/8t3hWIOXM+P18FrvD/A0lRxRAa9Ws6dSZMPS8 SOP7B3CMrnrMACnuOhnWbxe4dFGQxbJ2uh82r9oh45km63hEpdEbdqSeY/QmjEvuM5sm V5jV/9xOBICoF/ZBXXrZbBY+bf4MgZwZ35C+3hsReNBxLnBssotZj/d0hpojVHmspuw9 wMLk7w3URYI/u/VGVa/HciU5WPmsh05OosgyWltURrEDtVhyyX5qWNXCfqq0QRykoOlC NCEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WDlQl/AYUQzhE3zaHYFhiZZcChwEiQTpo55VP40eQ8c=; b=4y5HirWeMWY0Ug2DmeEGuPvdM8lq4XrlKdQ14L1Q9Au92Hhgn+RQ1smq93nZ/sWgMj K/75nQCOXNFAXIoTI1lkTIOhbWFKhzap+WhbS47YQPqtLi3l9Gkvmv28keg2s5VH3yyC JBkryopQuCA8iCCBxULqOHoUPMRkL0HbdJYpM5iGZOW4s0CRE3f/BDeD5jmT1gdCoitE vkCJJZSFoXu5EX4nUxA6IKu3jug1Fo/gdhfbPwnpmYWCVrr1d6PU88Rf/Ck7fDO9vVXo jgDjM5/6+VhlgrkpugrzvzHL+bpDSfqU0GvwFKx9E92Zgko9FnNioWHmx4Hse9BcLFz4 Oauw== X-Gm-Message-State: AOAM532V5OBP5hIGkP5eyv9pMWwpO9sVuoZb4brEirK1nSg3i8mWegFP u2qxuzdl/WDL/yab4eX47BLv5HnmpGqJwr2tZaBwwDvLMbQ= X-Google-Smtp-Source: ABdhPJzU9Xnh+OfAs9hdY5+/G0GHnHPTd4zXiswEA4+nmWNuirt/hWV8l9C+dWtLQVmdiN01jxPcQCyWB/FJJX3lEmg= X-Received: by 2002:a05:6512:1304:: with SMTP id x4mr1951779lfu.484.1638999226855; Wed, 08 Dec 2021 13:33:46 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> <2e894793-f860-3415-1f5d-26fd5e85a69d@FreeBSD.org> In-Reply-To: <2e894793-f860-3415-1f5d-26fd5e85a69d@FreeBSD.org> From: Yetoo Happy Date: Wed, 8 Dec 2021 13:33:31 -0800 Message-ID: Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook To: John Baldwin Cc: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-doc@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b4361105d2a93e92" X-Rspamd-Queue-Id: 4J8Vlw0dNkz3rVC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000b4361105d2a93e92 Content-Type: text/plain; charset="UTF-8" If it was in a temporary directory, even if I manaually resolved the file and merge, I was expecting that file marked as resolve to stay in that temporary directory until I was done with all my files. Maybe I'm confusing mergemaster -Ui behavior with something else, but it seems like only merging after the user has reviewed all manual changes in a final verification sweep is common sense or at least explicitly display the tree directory that would be written to and say this is final change. I didn't know that each file etcupdate went over was going to be the final review. I think my system broke by the time I got to the rest of the postponed items due to this. On Wed, Dec 8, 2021, 9:05 AM John Baldwin wrote: > On 12/3/21 4:58 AM, Miroslav Lachman wrote: > > So beside the update of documentation I really would like to see some > > changes to etcupdate workflow where files are modified in temporary > > location and moved to destination only if they do not contain any syntax > > breaking changes like <<<<, ====, >>>>. > > This is what etcupdate does, so I'm a bit confused why you are getting > merge markers in /etc. When an automated 3-way merge doesn't work due > to conflicts, the file with the conflicts is saved in > /var/db/etcupdate/conflicts/. It is only copied to /etc when you > mark it as fully resolved when running 'etcupdate resolve'. Perhaps > you had multiple conflicts in a modified file and when editing the file > you only fixed the first one and then marked it as resolved at the > prompt? Even in that case etcupdate explicitly prompts you a second time > after you say "r" with "File still has conflicts, are you sure?", > so it will only install a file to /etc with those changes if you have > explicitly confirmed you want it. > > -- > John Baldwin > --000000000000b4361105d2a93e92-- From nobody Wed Dec 8 21:55:54 2021 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 8D16518C28D5 for ; Wed, 8 Dec 2021 21:56:05 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8WFd1D3Dz3w1r; Wed, 8 Dec 2021 21:56:04 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 1B8Ltsvo023423; Thu, 9 Dec 2021 06:55:55 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 9 Dec 2021 06:55:54 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: John Baldwin , jbtakk@iherebuywisely.com, Stefan Esser Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook Message-Id: <20211209065554.7fd8a79b48f97608b07d8343@dec.sakura.ne.jp> In-Reply-To: <98af77aa-628d-5fce-7618-36b1edaa405b@FreeBSD.org> References: <56a60a9b-3d7f-b29e-6074-71078f4b0fe6@quip.cz> <20211204110942.11553b693b165364f3ab31c0@dec.sakura.ne.jp> <98af77aa-628d-5fce-7618-36b1edaa405b@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J8WFd1D3Dz3w1r X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 8 Dec 2021 09:11:05 -0800 John Baldwin wrote: > On 12/3/21 6:09 PM, Tomoaki AOKI wrote: > > On Fri, 03 Dec 2021 05:54:37 -0800 (PST) > > "Jeffrey Bouquet" wrote: > > > >> > >> > >> On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.fbsd@quip.cz> wrote: > >> > >>> On 03/12/2021 12:52, Yetoo Happy wrote: > >>> > >>> [...] > >>> > >>>> Quick Start* and follow the instructions and get to step > >>>> 7 and may think that even though etcupdate is different from mergemaster > >>>> from the last time they used the handbook they have faith that following > >>>> the instructions won't brick their system. This user will instead find that > >>>> faith in general is just a very complex facade for the pain and suffering > >>>> of not following *24.5.6.1 Merging Configuration Files* because the user > >>>> doesn't know that step exists or relevant to the current step and ends up > >>>> unknowingly having etcupdate append "<<<< yours ... >>>>> new" to the top > >>>> of the user's very important configuration files that they didn't expect > >>>> the program to actually modify that way when they resolved differences nor > >>>> could they predict easily because the diff format is so unintuitive and > >>>> different from mergemaster. Now unable to login or boot into single user > >>>> mode because redirections instead of the actual configuration is parsed the > >>>> user goes to the handbook to find out what might have happened and scrolls > >>>> down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. > >>> > >>> [...] > >>> > >>> That's why I think etcupdate is not so intuitive as tool like this > >>> should be and etcupdate is extremely dangerous because it intentionally > >>> breaks syntax of files vital to have system up and running. > >>> If anything goes wrong with mergemaster automatic process then your have > >>> configuration not updated which is almost always fine to boot the system > >>> and fix it. But after etcupdate? Much worse... > >>> > >>> I maintain about 30 machines for 2 decades and had problems with > >>> etcupdate many times. I had ti use mergemaster as fall back many times. > >>> Mainly because of etcupdate said "Reference tree to diff against > >>> unavailable" or "No previous tree to compare against, a sane comparison > >>> is not possible.". And sometimes because etcupdate cannot automatically > >>> update many files in /etc/rc.d and manual merging of a lot of files with > >>> "<<<< ==== >>>>" is realy painful while with mergemaster only simple > >>> keyboard shortcuts will solve it. > >>> All of this must be very stressful for beginners. > >>> > >>> So beside the update of documentation I really would like to see some > >>> changes to etcupdate workflow where files are modified in temporary > >>> location and moved to destination only if they do not contain any syntax > >>> breaking changes like <<<<, ====, >>>>. > >>> > >>> Kind regards > >>> Miroslav Lachman > >> > >> > >> Agree. I fell back to mergemaster this Nov on 13-stable when the /var files > >> pertaining to etcupdate were all missing current /etc data, and no study of > >> man etcupdate was clear enough to rectify such a scenario, and suspect my > >> initial use of etcupdate will or may require a planned reinstall, not having > >> had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and > >> I am just hoping mergemaster stays in /usr/src and updated > >> for system changes, even if moved to 'tools' or > >> something, since its use seems intuitive and much less of a black box. > >> Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still. > >> > > > > Not sure it's fixed or not (tooo dangerous to try...), -n (dry-run) > > option of etcupdate is now quite harmful. Maybe by any commit done in > > this april on main (MFC'ed to stable/13 in june). > > > > *I got busy manually checking and applying changes to /etc, and > > forgot to file PR. > > > > Doing `etcupdate -n` itself runs OK, but following `etcupdate -B` does > > NOT do anything, hence nothing is actually updated. > > The only workaround I have is NOT to try dry-run. > > Humm. > > > It would be because the same trees are used for dry-run and actual run. > > (Not looked into the code. Just a thought.) > > So the new changes always build a temporary tree (vs trying to build > /var/db/etupdate/current in place). For -n it should be that it just > doesn't change /var/db/etcupdate/current at the end, but if it did the > move anyway that would explain the bug you are seeing. That does indeed > look broken. Please file a PR as a reminder for me to fix it. > > -- > John Baldwin > Done. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260281 -- Tomoaki AOKI From nobody Wed Dec 8 23:10:27 2021 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 5478618D269B for ; Wed, 8 Dec 2021 23:10:39 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8Xvf1yPsz4crP for ; Wed, 8 Dec 2021 23:10:37 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [IPV6:2001:470:71:d47:a54b:e899:3781:d58f] ([IPv6:2001:470:71:d47:a54b:e899:3781:d58f]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 1B8NASsi037459 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 9 Dec 2021 00:10:29 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1639005029; bh=K6ce3ZI0ytFO/amCDrPKZiBvX6Q/m255f12WXF2q6/w=; h=Date:To:References:From:Subject:In-Reply-To; b=nceMkeoV+3R5S+op1XcANciwKRGdAYCcHNbv99BoH+OgmXCQe8eTffJHv/4483d9T h1VmAIhshmi/IkjN+dMyAwjVmeKxylB7yVAwGFX5MfTBFtx2Nv+ac/NvNi0RUZE9GZ /i7XUxVTBwAMiG1Wxx3PD6lF1U69/0EvAPaOA+B/L0mLjbDlBNyip2rmcygR5RsYMb NxewrMPYmWr0iM1lKn8R0E5epPOhUZodPcqe3mh973yaKUiI6sFPwHhVBP/n34SIgJ 9Pr9xsEHaN/KZalLJ38/1ER8Slp1yWoTSgzMjSZ0fqvRnwxFGVumW6gbfhd/ATFR6d TRPVlwjXTPJFg== Message-ID: <46de5858-277c-2751-a831-224972afcd34@plan-b.pwste.edu.pl> Date: Thu, 9 Dec 2021 00:10:27 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: freebsd-current@freebsd.org References: From: Marek Zarychta Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------SklFJiyYSAiwTRvsDm7gh5zb" X-Rspamd-Queue-Id: 4J8Xvf1yPsz4crP X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=nceMkeoV; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-5.77 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.97)[-0.972]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------SklFJiyYSAiwTRvsDm7gh5zb Content-Type: multipart/mixed; boundary="------------9cyTYRTYxO7p19sDIhJr9YxQ"; protected-headers="v1" From: Marek Zarychta To: freebsd-current@freebsd.org Message-ID: <46de5858-277c-2751-a831-224972afcd34@plan-b.pwste.edu.pl> Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook References: In-Reply-To: --------------9cyTYRTYxO7p19sDIhJr9YxQ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VyBkbml1IDMuMTIuMjAyMSBvwqAxNDo1NCwgSmVmZnJleSBCb3VxdWV0IHBpc3plOg0KPiAN Cj4gDQo+IE9uIEZyaSwgMyBEZWMgMjAyMSAxMzo1ODozOSArMDEwMCwgTWlyb3NsYXYgTGFj aG1hbiA8MDAwLmZic2RAcXVpcC5jej4gd3JvdGU6DQo+IA0KPj4gT24gMDMvMTIvMjAyMSAx Mjo1MiwgWWV0b28gSGFwcHkgd3JvdGU6DQo+Pg0KPj4gWy4uLl0NCg0KVGhhbmsgeW91IFll dG9vIGZvciBkZXNjcmliaW5nIHlvdXIgZXhwZXJpZW5jZSwgYnJpbmdpbmcgdGhlIHRvcGlj IGFnYWluIA0KYW5kIHByb3Zva2luZyB0aGlzIGRpc2N1c3Npb24uDQoNCj4+DQo+Pj4gICBR dWljayBTdGFydCogYW5kIGZvbGxvdyB0aGUgaW5zdHJ1Y3Rpb25zIGFuZCBnZXQgdG8gc3Rl cA0KPj4+IDcgYW5kIG1heSB0aGluayB0aGF0IGV2ZW4gdGhvdWdoIGV0Y3VwZGF0ZSBpcyBk aWZmZXJlbnQgZnJvbSBtZXJnZW1hc3Rlcg0KPj4+IGZyb20gdGhlIGxhc3QgdGltZSB0aGV5 IHVzZWQgdGhlIGhhbmRib29rIHRoZXkgaGF2ZSBmYWl0aCB0aGF0IGZvbGxvd2luZw0KPj4+ IHRoZSBpbnN0cnVjdGlvbnMgd29uJ3QgYnJpY2sgdGhlaXIgc3lzdGVtLiBUaGlzIHVzZXIg d2lsbCBpbnN0ZWFkIGZpbmQgdGhhdA0KPj4+IGZhaXRoIGluIGdlbmVyYWwgaXMganVzdCBh IHZlcnkgY29tcGxleCBmYWNhZGUgZm9yIHRoZSBwYWluIGFuZCBzdWZmZXJpbmcNCj4+PiBv ZiBub3QgZm9sbG93aW5nICoyNC41LjYuMSBNZXJnaW5nIENvbmZpZ3VyYXRpb24gRmlsZXMq IGJlY2F1c2UgdGhlIHVzZXINCj4+PiBkb2Vzbid0IGtub3cgdGhhdCBzdGVwIGV4aXN0cyBv ciByZWxldmFudCB0byB0aGUgY3VycmVudCBzdGVwIGFuZCBlbmRzIHVwDQo+Pj4gdW5rbm93 aW5nbHkgaGF2aW5nIGV0Y3VwZGF0ZSBhcHBlbmQgIjw8PDwgeW91cnMgLi4uID4+Pj4+IG5l dyIgdG8gdGhlIHRvcA0KPj4+IG9mIHRoZSB1c2VyJ3MgdmVyeSBpbXBvcnRhbnQgY29uZmln dXJhdGlvbiBmaWxlcyB0aGF0IHRoZXkgZGlkbid0IGV4cGVjdA0KPj4+IHRoZSBwcm9ncmFt IHRvIGFjdHVhbGx5IG1vZGlmeSB0aGF0IHdheSB3aGVuIHRoZXkgcmVzb2x2ZWQgZGlmZmVy ZW5jZXMgbm9yDQo+Pj4gY291bGQgdGhleSBwcmVkaWN0IGVhc2lseSBiZWNhdXNlIHRoZSBk aWZmIGZvcm1hdCBpcyBzbyB1bmludHVpdGl2ZSBhbmQNCj4+PiBkaWZmZXJlbnQgZnJvbSBt ZXJnZW1hc3Rlci4gTm93IHVuYWJsZSB0byBsb2dpbiBvciBib290IGludG8gc2luZ2xlIHVz ZXINCj4+PiBtb2RlIGJlY2F1c2UgcmVkaXJlY3Rpb25zIGluc3RlYWQgb2YgdGhlIGFjdHVh bCBjb25maWd1cmF0aW9uIGlzIHBhcnNlZCB0aGUNCj4+PiB1c2VyIGdvZXMgdG8gdGhlIGhh bmRib29rIHRvIGZpbmQgb3V0IHdoYXQgbWlnaHQgaGF2ZSBoYXBwZW5lZCBhbmQgc2Nyb2xs cw0KPj4+IGRvd24gdG8gZmluZCAqMjQuNS42LjEgTWVyZ2luZyBDb25maWd1cmF0aW9uIEZp bGVzKiBpcyB1bmRlciAqMjQuNS42Lg0KPj4NCj4+IFsuLi5dDQo+Pg0KPj4gVGhhdCdzIHdo eSBJIHRoaW5rIGV0Y3VwZGF0ZSBpcyBub3Qgc28gaW50dWl0aXZlIGFzIHRvb2wgbGlrZSB0 aGlzDQo+PiBzaG91bGQgYmUgYW5kIGV0Y3VwZGF0ZSBpcyBleHRyZW1lbHkgZGFuZ2Vyb3Vz IGJlY2F1c2UgaXQgaW50ZW50aW9uYWxseQ0KPj4gYnJlYWtzIHN5bnRheCBvZiBmaWxlcyB2 aXRhbCB0byBoYXZlIHN5c3RlbSB1cCBhbmQgcnVubmluZy4NCj4+IElmIGFueXRoaW5nIGdv ZXMgd3Jvbmcgd2l0aCBtZXJnZW1hc3RlciBhdXRvbWF0aWMgcHJvY2VzcyB0aGVuIHlvdXIg aGF2ZQ0KPj4gY29uZmlndXJhdGlvbiBub3QgdXBkYXRlZCB3aGljaCBpcyBhbG1vc3QgYWx3 YXlzIGZpbmUgdG8gYm9vdCB0aGUgc3lzdGVtDQo+PiBhbmQgZml4IGl0LiBCdXQgYWZ0ZXIg ZXRjdXBkYXRlPyBNdWNoIHdvcnNlLi4uDQo+Pg0KPj4gSSBtYWludGFpbiBhYm91dCAzMCBt YWNoaW5lcyBmb3IgMiBkZWNhZGVzIGFuZCBoYWQgcHJvYmxlbXMgd2l0aA0KPj4gZXRjdXBk YXRlIG1hbnkgdGltZXMuIEkgaGFkIHRpIHVzZSBtZXJnZW1hc3RlciBhcyBmYWxsIGJhY2sg bWFueSB0aW1lcy4NCj4+IE1haW5seSBiZWNhdXNlIG9mIGV0Y3VwZGF0ZSBzYWlkICJSZWZl cmVuY2UgdHJlZSB0byBkaWZmIGFnYWluc3QNCj4+IHVuYXZhaWxhYmxlIiBvciAiTm8gcHJl dmlvdXMgdHJlZSB0byBjb21wYXJlIGFnYWluc3QsIGEgc2FuZSBjb21wYXJpc29uDQo+PiBp cyBub3QgcG9zc2libGUuIi4gQW5kIHNvbWV0aW1lcyBiZWNhdXNlIGV0Y3VwZGF0ZSBjYW5u b3QgYXV0b21hdGljYWxseQ0KPj4gdXBkYXRlIG1hbnkgZmlsZXMgaW4gL2V0Yy9yYy5kIGFu ZCBtYW51YWwgbWVyZ2luZyBvZiBhIGxvdCBvZiBmaWxlcyB3aXRoDQo+PiAiPDw8PCA9PT09 ID4+Pj4iIGlzIHJlYWx5IHBhaW5mdWwgd2hpbGUgd2l0aCBtZXJnZW1hc3RlciBvbmx5IHNp bXBsZQ0KPj4ga2V5Ym9hcmQgc2hvcnRjdXRzIHdpbGwgc29sdmUgaXQuDQo+PiBBbGwgb2Yg dGhpcyBtdXN0IGJlIHZlcnkgc3RyZXNzZnVsIGZvciBiZWdpbm5lcnMuDQo+Pg0KPj4gU28g YmVzaWRlIHRoZSB1cGRhdGUgb2YgZG9jdW1lbnRhdGlvbiBJIHJlYWxseSB3b3VsZCBsaWtl IHRvIHNlZSBzb21lDQo+PiBjaGFuZ2VzIHRvIGV0Y3VwZGF0ZSB3b3JrZmxvdyB3aGVyZSBm aWxlcyBhcmUgbW9kaWZpZWQgaW4gdGVtcG9yYXJ5DQo+PiBsb2NhdGlvbiBhbmQgbW92ZWQg dG8gZGVzdGluYXRpb24gb25seSBpZiB0aGV5IGRvIG5vdCBjb250YWluIGFueSBzeW50YXgN Cj4+IGJyZWFraW5nIGNoYW5nZXMgbGlrZSA8PDw8LCA9PT09LCA+Pj4+Lg0KPj4NCj4+IEtp bmQgcmVnYXJkcw0KPj4gTWlyb3NsYXYgTGFjaG1hbg0KPiANCj4gDQo+IEFncmVlLiBJIGZl bGwgYmFjayB0byBtZXJnZW1hc3RlciB0aGlzIE5vdiBvbiAxMy1zdGFibGUgd2hlbiB0aGUg L3ZhciBmaWxlcw0KPiBwZXJ0YWluaW5nIHRvIGV0Y3VwZGF0ZSB3ZXJlIGFsbCBtaXNzaW5n IGN1cnJlbnQgL2V0YyBkYXRhLCBhbmQgbm8gc3R1ZHkgb2YNCj4gbWFuIGV0Y3VwZGF0ZSB3 YXMgY2xlYXIgZW5vdWdoIHRvIHJlY3RpZnkgc3VjaCBhIHNjZW5hcmlvLCBhbmQgc3VzcGVj dCBteQ0KPiBpbml0aWFsIHVzZSBvZiBldGN1cGRhdGUgd2lsbCBvciBtYXkgcmVxdWlyZSBh IHBsYW5uZWQgcmVpbnN0YWxsLCAgbm90IGhhdmluZw0KPiBoYWQgdG8gZG8gc28gc2luY2Ug SmFuIDIwMDQgaWlyYywgIFsgdnMgZmFpbGVkIGhhcmQgZGlzayBtaWdyYXRpb25zIF0gYW5k DQo+IEkgYW0ganVzdCBob3BpbmcgbWVyZ2VtYXN0ZXIgc3RheXMgaW4gL3Vzci9zcmMgYW5k IHVwZGF0ZWQNClNvIGRvIEkuDQoNCj4gZm9yIHN5c3RlbSBjaGFuZ2VzLCBldmVuIGlmIG1v dmVkIHRvICd0b29scycgb3INCj4gc29tZXRoaW5nLCBzaW5jZSBpdHMgdXNlIHNlZW1zIGlu dHVpdGl2ZSBhbmQgbXVjaCBsZXNzIG9mIGEgYmxhY2sgYm94Lg0KPiBBbHNvLCAvdXNyL3Ny Yy9VUERBVElORyBzdGlsbCBhdCB0aGUgYm90dG9tIGVtcGhhc2l6ZXMgbWVyZ2VtYXN0ZXIg c3RpbGwuDQo+IA0KU29tZSBwZW9wbGUgYXJlIHB1c2hpbmcgdG93YXJkIGV0Y3VwZGF0ZSg4 KSBmb3IgdGhlIGF1dG9tYXRpb24gYW5kIDMtd2F5IA0KbWVyZ2Ugc3VwcG9ydCwgYnV0IHVw ZGF0aW5nIG9sZCBTVEFCTEUgd2l0aCB0aGlzIHRvb2wgY291bGQgYmUgcmVhbGx5IA0Kc3Ry ZXNzZnVsIGFuZCB0aW1lLWNvbnN1bWluZyBjaGFsbGVuZ2UuIEhvdyB3b3VsZCBvbmUgZm9y IGV4YW1wbGUgZmluZCANCm9sZCBzb3VyY2VzIHRvIHBlcmZvcm0gImV0Y3VwZGF0ZSBleHRy YWN0IiA/DQoNCiBGcm9tIG15IGV4cGVyaWVuY2UgZXRjdXBkYXRlKDgpIGlzIG9ubHkgdXNl ZnVsIGZvciB1cGRhdGluZyBSRUxFQVNFcyBvciANCmZyZXF1ZW50bHkgdXBkYXRlZCBDVVJS RU5ULiBUaGUgcG93ZXIgb2Ygc2RpZmYoMSkgd2F5IG1lcmdlIGdpdmluZyBmdWxsIA0KY29u dHJvbCBvdmVyIHRoZSB1cGRhdGUgcHJvY2VzcyBpcyB0aGUgcmVhbCBzdHJlbmd0aCBvZiBj dXJzZWQgDQptZXJnZW1hc3Rlcig4KS4gTWF5YmUgaXQncyBhIGJhcnJpZXIgZm9yIHBlb3Bs ZSBub3QgZmFtaWxpYXIgd2l0aCB2aSgxKSANCmFuZCByZXF1aXJlcyBtb3JlIHRpbWUgcGVy IHVwZGF0ZSwgYnV0IHNvIGZhciBuZXZlciBmYWlsZWQgbWUuIFRoZSANCm1pc3NpbmcgJEZy ZWVCU0QgLi4uJCBJRHMgY2FuIGJlIHJlZ2VuZXJhdGVkIGluIGxvY2FsIGdpdCByZXBvIHdp dGggDQpzbXVkZ2UgZmlsdGVycy4gR2VuZXJhdGluZyBsb2NhbGx5IHRoZXNlIElEcyBmb3Ig dGhlIHNwZWNpZmljIHNldCBvZiANCmZpbGVzIHdoaWNoIG1lcmdlbWFzdGVyKDgpIG9wZXJh dGVzIG9uIGRvZXNuJ3Qgc2xvdyBkb3duIHRoZSByZXBvc2l0b3J5IA0KYW5kIHNob3VsZG4n dCBiZSBjb25zaWRlcmVkIGFzIGFyZ3VtZW50IGZvciBkZXByZWNhdGlvbiBhbmQgcmVtb3Zh bCBvZiANCm1lcmdlbWFzdGVyKDgpLg0KDQpJIHRyaWVkIHRvIHVzZSBldGN1cGRhdGUoOCkg Zm9yIFNUQUJMRSBhIGZldyB0aW1lcywgYnV0IHRoZSByaWNvY2hldCANCnNob3QgbXkgZm9v dCBvbmNlIG9yIHR3aWNlLCBzbyBzdGVwcGVkIGJhY2suIEkgc3RpbGwgbWFpbnRhaW4gd2hh dCBJIA0KaGF2ZSB3cml0dGVuIGVhcmxpZXIsIHRoYXQgYSB3ZWxsLXdvcm4gaGFtbWVyIGNv dWxkIGJlIGluIHNvbWUgY2FzZXMgDQpiZXR0ZXIgdGhhbiBhIG5haWxndW4uDQoNCkJpYXNl ZCwgMjArIHllYXJzIEZyZWVCU0QgYW5kIG1lcmdlbWFzdGVyKDgpIHVzZXIsDQoNCi0tIA0K TWFyZWsgWmFyeWNodGENCg== --------------9cyTYRTYxO7p19sDIhJr9YxQ-- --------------SklFJiyYSAiwTRvsDm7gh5zb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmGxO2MFAwAAAAAACgkQHZW8vIFppoIB awgAg5aaFCYH0TI2W5WF3pi6bCRs4z1A1LtsGxZF0IPqB6KrEm5Se0wUuu8ayVYgpkBMDag/Z3HA 1qr3sJqB5Q8NRfg1yMJF8XwZWCmzGbM3pljU5MtlPHSxudI303NwLNPWYf3Jia1LP03Y9raOtSpY k9DnaSj4MahdzaifvXRoXgn+Reqc6Z73mUnudGILE5DZAp6UBrmVi4lbe0dLVCDXp6R3+YXscdCf NS++kqNSh7TBQioBd6isneTkyHIOqWtJPiU11NHVflujP+SCjQzy0PtsY+oq2MEIAMYG9p2UVqZx C3ghleQ+Q82/cSuRcNeZD0vgWGPxlsv3j/b+gNRKVg== =LYH3 -----END PGP SIGNATURE----- --------------SklFJiyYSAiwTRvsDm7gh5zb-- From nobody Thu Dec 9 02:28:59 2021 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 6327B18DCAAE for ; Thu, 9 Dec 2021 02:29:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8dJk2DpVz3jGY for ; Thu, 9 Dec 2021 02:29:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639016943; bh=razuytElnrU+i8lJKtoslWraKob6QqKXuwc+BaY5dfU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=sJjMxft3HZrH+W47lKJedQjzDqj76jFRxoNUptIV2AOM1uE6mX55WIfCOAbIinzPSWzg4uNv6LB5I/3lTiDP8sfgzSfqeeGBralfy7fv/OyGAMfkNA0yiBmhKCe76Qvh9UZ/7zSAQJa2Si5lRAoQ4kVjyAeArHLZhk6PlxTiVTnK4mSHWZixKF2b0f0BWSc5jLMY8iHtwO5lw4UpMOLalWJNOZBza4ciehDUyne18Fy8KbSyj2dgbIPCyru9WQbN3kzXHiw2Vl3JRQKiwvkqGtBK1lG1gCAbrdqROy2gjqL2HsZ8y/EqSnJy0hrMmgIRC0JGbynqLTw6R0QRNRmy0w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639016943; bh=7sh+n3WGAMjrZCBiOqe4ORW32+dZWgr/5gSF6SbPQw8=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=qSc8UE8mBOm5w99mrPPahrDF+JDApJWg41S6sY3AVs8QtImESSZNaxjB5M0AJV8PsG9ICqNRj0mekHTVBocXmOuhOE560G+/6duESCkpiloxpOulpqQ1JeM29drSSEp67+awgYCn0ieswstapdJxj4Wwq2A+3321wIvMjJkmW9UP89C+JYUGNTCHipyMX2hIQL0XPPYXrQGZysAqqr6g34xw22yYOHLmBxRtIvLSCV7JtrR4T1jt+okmgKssw5omdKQqXA9vSar2nfHq5ggqGRPC8CGxaTa1H42NtsaLuEMe19+LruEycLS5NgkHgP1Z8/nq9n6GBi0RQs292BdzPQ== X-YMail-OSG: LMtL3jwVM1kHnn1IoN0G.rtYldqrq5LnbUM2JSxk.G3eAq5PUe39OfRtc.TyzsA SK.qjqouPs0cbvLz.qhU5ZXG5vSqWPtE2_O.l2xcZovWUksWaeY5qlrnrW6xW3Vl06EK66WrOPIj jI6pzY.Gwpc2B6xCGP0BAFpAkW86UpgBN6Rdd3pbsIGaJc3dH2hRZi6PoT_sXqtZJA0KDh7YJEPH ZtZ.dWA1NzzQ7_IvNu43XfpXVAxYdY8VVRdAnCqzZAo9viquI27iz4ryBzI9DeSdca1GLnGM8Mec IuZDdH8h_RgBhuC75ngizQg9sr9seOYpt9WQ0C2JFisV3veXZw29ToMESC3T3EE9xSODcghuyd09 mcYZNHJ5B.12lA4hebzgLmiO0LSHVij.NDxh7AQuSwnaKGq_o35F0ixaD5lkK3QZ2TNOpYsd8ekx wLbpdoCgl4j6.kdIMxf3UFgDCNLfAdRuQ__sqDwFzZKHKdcLk9eJIOJ0u1yuS8wKt0KWPkoGOhn6 aQdbo46iJJ5KgCToUQ7jWrTsDXqKeQQ6L5cmVONqba1Riwb7_o2VW.VaVD5Si6Aw64wENQtPk1HH WH8dymZakHwN5P_t83ExlFu7M3_RCjL.4MwN3ioibnGMTA_yj5itVQMUmjkTxPptAJqjdYy4yHYu _MwCjYXBG.BHgX9vfyHqpkRUOUO3r14578BunqD0xd9ibwGld2yMeZBBYmMFn9h26lKiiZOQ5987 csCGwxPQjZjlF_mXzZhNHY63_tsOB_F7_YP5aoDDueBpbz5H7Hp29i14NQxDp6GL1Bw2SoxGgSG6 TTomEnXrWMwkFs2HPJxFNwpgK51.ucdMphZjpofA3dGlBxulxYnGD3be5XRZOdkGdu8Qypq9iyvj wNIWP2qE_v1.fl2PpKfDtn9YGnJYTQuJVGWmYw9s9f2s6HgcEySdrEll7TuN6WxXI7B2SXxGH00c rJ8hBO0WkIxVw_436nLzixrdj0pkKWGbQppTIZMhHBVT35xbiHBMnOyj5_ZvHTHd1fX6YBTkwb0m 0cnop0J6JXVywF9OE4HUK.buy7k8i8FZ.u1qt0AfCHDPO5cNIy3VDBQDbk2IHKSvF5An9z8HWFwU SU6hitkVbZC35JlA2XToRXl8hTRlA2awf99QWjbONjjd6jGRc1aPqWDYnOCferxJrYS0qsHLz.bq wywAO_h1gbj8H0baeBmqpRe7634B9l2daXRnIEnj3mmnSQx17IUZb00VU.G1CCl0x3fE7q_pGZ06 JTn3Kmlfw5l3wt.YiMMDJsRlTem72HsQygvZcYsc9PK2qm8yduSKOPd7XI3IDmOkMjgkp5QpOLmi gHCPmU4aNQSu.ZzIzqn8pmNH0L1RVntSkxr64vpevqn6bzh6f8nBSkNius.FMvnnmPKXYRavLuqL Kr22mc5TFCJu1M_MbWRXvDw3eVzQ4NmS0l4eKNeLQx4MxcNCnPVut1X4dabyJeZI0eVzH1dG6ATG gb7s01W8vYzEzIVgzPEDHjOYy2ZBQmClutwswW0Au8a9mZHA9E.N0708ssCUCkBfZ7iUBowvKTyr w7eRES4e50in6i_X5fc1Wi1FQoKEouVZ7OmFmxCj_u7Puqdos4N0Is3Hr4_OLwEA3sO_JgtJlsTc 0XjWi.X.FpANa.oR_qZbPBMUZmHNBaHJR3yCyC0CZf31X0ZhuVcRDj.gV46P.dz6QvIL4sKQJdAc XC9cJgsg.L_tSz26ik9OR4kD5DQmlbsURCgHIeNWRDKT9VasUxIqv67rObrqkLcLn0axdXP3Bv3D TbA1pLLxUvrXixQwyVVhRQCR0oEprXYgCSJIR_6oo4_NvEJUt5ZlzhbBXBmjIp1sitbKjnIsM3SO KL3UXQf_lbcq_jvocabgLWHgekw3L9nQOSSlzGTUdw2o1jcgNjCErTx5CRrmQss0DESCIOrkHFbH wLklcXO0Zdt.kzkhmH2FzSk9y0t35bNxs4zCshOPpqwcPlEcmb_nfz7SAgdkmZWJysS8ginsT.pR oCtx2ceyt_2ba8QjFECn35C3I64DmeU0QCLXbLmzUtaDduvgILkOnflJZfEZFscD7IU.JHMZTnJA guXa3Zk2Qe0NKwAO.UmDzeo_kR6UfPYtqQA2KirStlo_kaz54R2qoDkaWaycnMWjP6uaPqc7OyHY oZLN1HH6wMH.VB4fbEW9PsTK73yAFV9ftQBdXJUxn7PI1UpDnu1kcCISFEuOmloUUUTeJJE6GNNq jScGaFCw9rs7wsRqqTnqYwP8jZQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Dec 2021 02:29:03 +0000 Received: by kubenode516.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 71e591157e143e9a1acfa553f3cf7df4; Thu, 09 Dec 2021 02:29:00 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: new boot message: "/etc/rc: WARNING: $zfskeys_enable is not set properly - see rc.conf(5)."? Message-Id: <509685D3-1112-4DFB-86FF-F5E0EA934D15@yahoo.com> Date: Wed, 8 Dec 2021 18:28:59 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <509685D3-1112-4DFB-86FF-F5E0EA934D15.ref@yahoo.com> X-Rspamd-Queue-Id: 4J8dJk2DpVz3jGY X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=sJjMxft3; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.13 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; SUBJECT_HAS_CURRENCY(1.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.89)[-0.890]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.26)[0.258]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N As of my update to (some line splitting applied): # uname -apKU FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25 = main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400043 1400043 my boot sequences are getting a report of: # dmesg -a | grep zfsk /etc/rc: WARNING: $zfskeys_enable is not set properly - see rc.conf(5). for the likes of a system (aarch64 example) based on: # gpart show =3D> 40 2000409184 ada0 GPT (954G) 40 409600 1 efi (200M) 409640 1740636160 2 freebsd-ufs (830G) 1741045800 117440512 3 freebsd-swap (56G) 1858486312 134217728 4 freebsd-swap (64G) 1992704040 7705184 - free - (3.7G) But I also get the notice for a system (aarch64 again) based on: # gpart show =3D> 40 1875384928 nda1 GPT (894G) 40 532480 1 efi (260M) 532520 2008 - free - (1.0M) 534528 515899392 2 freebsd-swap (246G) 516433920 20971520 - free - (10G) 537405440 1337979528 3 freebsd-zfs (638G) The amd64 system gets the same message. The note to see rc.conf(5) is misleading for main 22c4ab6cb015 : # man 5 rc.conf | grep zfsk # =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Dec 9 04:36:20 2021 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 F0DDE18CAB95 for ; Thu, 9 Dec 2021 04:36:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8h7g4bGLz4RdP for ; Thu, 9 Dec 2021 04:36:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639024584; bh=2M2qdLcclsuuDgi+/dDvi8J4HkaTIU4PoEKDicTg4uc=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=KRsN5Q0FaKHrUGxdtxnM0fVJq5G2357GKAvPNrBlLfdU+opTpwktP3xihZZ16+M1jW7PMizC1cmKp8eArx10b8THlzYlly/L36h0eMGa6OX5msZfDIwmlLoRuEeVvoo7qZh8z3wsFEusLhkz8grz/H8fzVrUH53ZQwkyb+cxbbYPOXpqN8+7fqUWTFikqf1TnCBIr2q6xT8hiFg1Z+1XG97I+SVKlc8BqUzveBZzSEC9pFnriR2BRza4YDNuD57gBZL49olsCQgD9ywlrFkn9hAcZB+rUAzc8TiUpU4NXRBjo2RwJwMVw/vV3KA3ZYwCVe9UoXSiSICKyFJMC1SfCw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639024584; bh=Nocr4LHPYnnbsCeXB2UwVE/xI4d+A0ARSd++4lDTzNP=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Ej5kzXsh1QUB03p0i4M9Lgaznje5kixvVYPAhuOPyNItpeYLlsQ7h3/I5QMcZ95gemeXJSXhsP9iB4QEcuHYuJ06IYEw6DfGVbQXwVzVyPZARm/7Dn0gUb3SsK7TJoQMcP9DXNMQSeJb6JhXQLI1hBzwEE4oSg6Qp8JcE8LacCofFvQHerlKvuetjU56fDxftcu5FpOkY669bJOOdygymsK7GeZz65zJum1oORG9eV+s5UKcVIquaEEPmNcm/idjhPCvHHFXAFMRKFKrtlCMtqBe2BIMbIy46melNpLNJEM+ryldNWclr2GID5XZg8/hLS0eEO/ZhhiZa+vKXyGdDg== X-YMail-OSG: 4sbKzEEVM1novzWYNMeTgoegMESay40lRGfFVUQFBu7wUJfVtlrppOXrNA3pYjn R_ofSWRIC0uNJ_Pj.fVOHF2A4ICG3Q5Kl160S8BPbVJnOinC9jemBYTwl1cN_8Om0dF52c2Ac0Di UBh_7Q1m_UPTsesGUfqHBJa69p6b85hl31Xtlp8ZSU1RPOgv1dVPoFXMwet_OwjkHkW_qvpQ1l45 hxiR70gV_kIm2kZc_G6dZs0.VPW2lH8fA5vhP3.45Rhel6n3Se1w8yH3KSG0CHbt6YkdglLCquhA REhARtu.jydnTyPEuhTH8LoJNXHaBc1BtNyxL9kEvstuBgSRdGfMCJVxaqDJlWIFgRW0YewIRUSd QvDZU.dI9QM_16cKxAZBP2ysqNfeEl8ihY1O2XLZLZgfGKoNTRFws.bi8Ure7Ocxwv3VLy64VbRf T9mHRVP7IjX8gXwPxAlcQ6dLxgrPdD7Tu8kqIKTQ9hsHPqXqB6wfYCVa1aO3W2S5sOFmPwyWOx2G CX09gG0Yy_6dBlRgeVMxhkD4RKqm8jSHsxQADUZ._NbsNqnAjvLwc4NaYc8._CpI9u2YtNYzgfLD fCXBIE7x2Kqxur1CpkH2DvSnuZww9WM.5knuHX6tXsq3xlSKDT2SqnlKsifLkQBHQrHhsCpiZ.CK 3AdQlKNjcYn1HhJCZl.XFkhAn3kETFBD6C0CJy5HOHElkjL5cR.nJqNf1SGfLPg17dHNiTILZQNB FPAeZVQZei0phZKzfMrXpy9rb85_LFxGlwVuZszetGeL2g9Pd8QBBZach_dykKyJ3iNRrChy61f7 j_uUc9jnae39fZIv01r0SvmdVfK0rPa7KCGK3D7x8pqTeY8kpIlI2aI3VQz0CNWp9NgicVvWtLN. QgIJpfgBDku7.C593XUAk1Q9DDP_uxmtIN0D2Y7wLC7YWzHh5yhu33Y77sKx0hEaIGPLKoXstz6M PYH8qH3jSyUDBXSyCpFD3rokJUWC1Tz6m3cm3VBHYrNJQAbObjYhSJlrjOxTWVqE.EHpUKh.zudM Bq0W9.pRz2aYogxVQrVWEXSHJgHWWrQ6lRkWW1F.4lYRgO00.NSpjlZHWBKNsgyuAOjRtLdZPVFR NubRnYBd0D0dOVgE4iU5rgc6RQWltzasL4s47DsN6NM67yK9IB8rMhyilknbUZ39b_nGCa._8ay. dC0aCqHdcU3Pa7he0oifeddd6A1910neXM9lBhNrHo5I7Y1QsdCT4P0AJOzfHZJ59WsIJ4nZauU6 niS6uzxOMpZBt6wjNg7shCRwLaxKufLytDAp_np5_wqQMexEyzVeGMDJDZiATHkn6wL0IC4bb4is wU5kHvVq.mu_D3nVIfo4oJlHgeu9Hbbvwrz_WgWkDiFb8IuvO0Zw83N6gPGlX0cLflTBnOJ8rotu uXvHHmNmzK7MCyc._88tX8XCN0SA2OvHcNOZ4mrYCENXwC.ohX7mSrFzjMz0lKDHyXiBldrEDDpW _TNGA9A1FBVMIRY.GMa0cayZfCRUpquXzTJGBOdCpTcVgwzW27Gr0LaF1Fc46o6ekXSYYyjUHFXN _v0siAhOiI0qwU937QjppXdyKLQMH3GJofcVtt3cFkbXTLwwmC63RAB3RHwVCu6g_7Yqb.jImI5I rH6iCLs1rbFO5Y.jgJBMetzFr0qnIOsv9vq_SNU6M8Knam7UUUDcGiBZh7hmjzj0cXM8JWpA52z5 JPvo3ufVo4DQlIBe5iV3MRnPPzaAgAQGkpcV83i7OQOholMfoBs6RxGVtiXxIw1qCduIcMIswAlq rJ94Pw01YXbnTmyRwag3w0Un5Gs1UOj1SJ1zbAtBY81FRgUkV2cCuxqY46rurHHPPRf0_xDi8ZYl iF6BkEtc6dWF5Q4VADUY_CiVdDryZccd5kNvVBR0GjZ7hRgc1CGAqHWPB64ZO06EAe6nKDBwWOxx vdP4hj89zX7Au7bWtImXd1XuzYrONpddtjTtNiO_SpjROnTfGXRFaKNokbi0aVwO_mtO_bgZtnmA UWsHzWngIgtpdnL5RYBKsGMz_hjk2EUe0SKmKwPZXPzQpfcuh.nw3C0QuUXbHxFCDTyCSJw4i7iB G2gajIgdZG2cgmbzep8ko0L0Qptttq3MYpwfn_Viz3QxNjGS8Gq7mciVBv4b5PhA.PkBGjNcIis3 s46Ckl_Y19tRm_vCXOGZXI6zkeq303v1zE2fdF3H2TymZX51DsgoqpP.6AGONEuml7EFq9ZMbbJw KJHdTA6YhIJGNCEf_v9QavAd1U5FKnS5cSvOLQzpSlCStTmap2yIaeZdz_89QQ66CjEAIK4Q6.kV eXqrevdRpv0NP099n_0QuYt8aKD5QvQJ6TeyDNxK607LiSvG_Reu7RSc- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Dec 2021 04:36:24 +0000 Received: by kubenode511.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 89169ce0427b25631466466fdb204c8d; Thu, 09 Dec 2021 04:36:21 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? Message-Id: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> Date: Wed, 8 Dec 2021 20:36:20 -0800 Cc: "wma@freebsd.org" To: freebsd-current , Free BSD X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> X-Rspamd-Queue-Id: 4J8h7g4bGLz4RdP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KRsN5Q0F; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N [ Note: wma@FreeBSD.org is only a guess, based on: = https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/0019= 31.html ] Attempting to update to: main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 resulted in boot failure (showing some boot -v output): . . . mmc0: Probing bus . . . mmc0: SD probe: failed mmc0: MMC probe: OK (OCR: 0x40ff8080) mmc0: Current OCR: 0x00ff8080 mmc0: Probing cards mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) mmc0: Card at relative address 0x0002 added: mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 mmc0: quirks: 0 mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) mmc0: memory: 244277248 blocks, erase sector 1024 blocks mmc0: setting transfer rate to 150.000MHz (HS200 timing) mmcsd0: taking advantage of TRIM mmcsd0: cache size 65536KB mmcsd0: 125GB at = mmc0 150.0MHz/8bit/1016-block mmcsd0boot0: 4MB partition 1 at mmcsd0 mmcsd0boot1: 4MB partition 2 at mmcsd0 mmcsd0rpmb: 4MB partition 3 at mmcsd0 . . . Release APs...done regulator: shutting down unused regulators GEOM: new disk mmcsd0 regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0 busy GEOM: new disk mmcsd0boot1 Trying to mount root from ufs:/dev/gpt/Rock64root []... Unresolved linked clock found: hdmi_phy Unresolved linked clock found: usb480m_phy mmcsd0: Error indicated: 4 Failed Note the the above line. It seems to be unique to the failure. Continuing the output . . . uhub2: 1 port with 1 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub0: 1 port with 1 removable, self powered uhub3: 1 port with 1 removable, self powered ugen4.2: at usbus4 umass0 on uhub1 umass0: = on usbus4 umass0: SCSI over Bulk-Only; quirks =3D 0x0000 umass0:0:0: Attached to scbus0 pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SPC-4 SCSI device pass0: Serial Number REPLACED pass0: 400.000MB/s transfers da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number REPLACED da0: 400.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors) da0: quirks=3D0x2 da0: Delete methods: Nothing more after that. An older kernel (1400042) that happened to be available boots the same configuration when used instead (same world) . . . main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: mmc0: Probing bus . . . mmc0: SD probe: failed mmc0: MMC probe: OK (OCR: 0x40ff8080) mmc0: Current OCR: 0x00ff8080 mmc0: Probing cards mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) mmc0: Card at relative address 0x0002 added: mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 mmc0: quirks: 0 mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) mmc0: memory: 244277248 blocks, erase sector 1024 blocks mmc0: setting transfer rate to 52.000MHz (high speed timing) Note the lack of trying "150.000MHz (HS200 timing)". Continuing the output . . . mmc0: setting bus width to 8 bits high speed timing mmcsd0: taking advantage of TRIM mmcsd0: cache size 65536KB mmcsd0: 125GB at = mmc0 52.0MHz/8bit/1016-block mmcsd0boot0: 4MB partition 1 at mmcsd0 mmcsd0boot1: 4MB partition 2 at mmcsd0 mmcsd0rpmb: 4MB partition 3 at mmcsd0 Note: The media is actually an e.MMC . Continuing the output . . . . . . Release APs...done regulator: shutting down unused regulators GEOM: new disk mmcsd0 regulator: shutting down vcc_sd... Trying to mount root from = ufs:/dev/gpt/Rock64root []... GEOM: new disk mmcsd0boot0 busy GEOM: new disk mmcsd0boot1 Unresolved linked clock found: hdmi_phy Unresolved linked clock found: usb480m_phy Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM uhub1: 1 port with 1 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub3: 1 port with 1 removable, self powered uhub2: 1 port with 1 removable, self powered ugen4.2: at usbus4 umass0 on uhub0 umass0: = on usbus4 umass0: SCSI over Bulk-Only; quirks =3D 0x0000 umass0:0:0: Attached to scbus0 Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM GEOM: new disk da0 pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SPC-4 SCSI device pass0: Serial Number REPLACED pass0: 400.000MB/s transfers da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number REPLACED da0: 400.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors) da0: quirks=3D0x2 da0: Delete methods: random: unblocking device. Warning: bad time from time-of-day clock, system time will not be set = accurately Dual Console: Serial Primary, Video Secondary start_init: trying /sbin/init . . . (I'll stop with that.) So I end up with a 1400042 kernel and a 1400043 world in order to boot. The e.MMC has only: # ls -FTld * -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT drwxr-xr-x 23 root wheel 1536 Dec 8 20:18:34 2021 boot/ drwxr-xr-x 2 root wheel 512 Apr 26 14:39:22 2020 etc/ drwx------ 2 root wheel 33280 Nov 27 09:46:08 2019 lost+found/ where the etc/ has only: # find etc/ -print etc/ etc/hostid World comes from the USB3 SSD that is attached but the kernel comes from the e.MMC instead. (The kernel can deal with the USB3 SSD just fine, unlike the U-Boot that is involved.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Dec 9 07:19:30 2021 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 CA21618CA872; Thu, 9 Dec 2021 07:19:37 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8lls2f6Xz4pj9; Thu, 9 Dec 2021 07:19:37 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639034375; 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=dYIm2IvNtGD8uFElzq79bEp/+XXQs/acxNGY94xfjRU=; b=Bwie8Ujg7TXZmBkI7FV1tDPKXRQNzr/FuEuKF0q4wUoegSXMeKJ8eNiTrvKZ7j4M9Jps/Q ldnpgBHidfnmvXOIfcVULQu5zxJucQbdpkluJD18WsBZWpqRHz2qY4+v5LTvEMiAQQ9mBb GNWQirljogjwvFJAU2NkqHeyIndjOys= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id bd1b18cb (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 9 Dec 2021 07:19:35 +0000 (UTC) Date: Thu, 9 Dec 2021 08:19:30 +0100 From: Emmanuel Vadot To: marklmi@yahoo.com Cc: Mark Millard via freebsd-current , Free BSD , "wma@freebsd.org" Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? Message-Id: <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> In-Reply-To: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J8lls2f6Xz4pj9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Mark, On Wed, 8 Dec 2021 20:36:20 -0800 Mark Millard via freebsd-current wrote: > [ Note: wma@FreeBSD.org is only a guess, based on: > https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/001931.html ] > > Attempting to update to: > > main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 > > resulted in boot failure (showing some boot -v output): > > . . . > mmc0: Probing bus > . . . > mmc0: SD probe: failed > mmc0: MMC probe: OK (OCR: 0x40ff8080) > mmc0: Current OCR: 0x00ff8080 > mmc0: Probing cards > mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) > mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) > mmc0: Card at relative address 0x0002 added: > mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 > mmc0: quirks: 0 > mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) > mmc0: memory: 244277248 blocks, erase sector 1024 blocks > mmc0: setting transfer rate to 150.000MHz (HS200 timing) > mmcsd0: taking advantage of TRIM > mmcsd0: cache size 65536KB > mmcsd0: 125GB at mmc0 150.0MHz/8bit/1016-block > mmcsd0boot0: 4MB partition 1 at mmcsd0 > mmcsd0boot1: 4MB partition 2 at mmcsd0 > mmcsd0rpmb: 4MB partition 3 at mmcsd0 > . . . > Release APs...done > regulator: shutting down unused regulators > GEOM: new disk mmcsd0 > regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0 > busy > GEOM: new disk mmcsd0boot1 > Trying to mount root from ufs:/dev/gpt/Rock64root []... > Unresolved linked clock found: hdmi_phy > Unresolved linked clock found: usb480m_phy > mmcsd0: Error indicated: 4 Failed > > Note the the above line. It seems to be unique to > the failure. Continuing the output . . . > > uhub2: 1 port with 1 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub0: 1 port with 1 removable, self powered > uhub3: 1 port with 1 removable, self powered > ugen4.2: at usbus4 > umass0 on uhub1 > umass0: on usbus4 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0: Attached to scbus0 > pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Direct Access SPC-4 SCSI device > pass0: Serial Number REPLACED > pass0: 400.000MB/s transfers > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number REPLACED > da0: 400.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=0x2 > da0: Delete methods: > > Nothing more after that. > > An older kernel (1400042) that happened to be available boots > the same configuration when used instead (same world) . . . > > main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: > > mmc0: Probing bus > . . . > mmc0: SD probe: failed > mmc0: MMC probe: OK (OCR: 0x40ff8080) > mmc0: Current OCR: 0x00ff8080 > mmc0: Probing cards > mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) > mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) > mmc0: Card at relative address 0x0002 added: > mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x0000 > mmc0: quirks: 0 > mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) > mmc0: memory: 244277248 blocks, erase sector 1024 blocks > mmc0: setting transfer rate to 52.000MHz (high speed timing) > > Note the lack of trying "150.000MHz (HS200 timing)". Continuing > the output . . . > > mmc0: setting bus width to 8 bits high speed timing > mmcsd0: taking advantage of TRIM > mmcsd0: cache size 65536KB > mmcsd0: 125GB at mmc0 52.0MHz/8bit/1016-block > mmcsd0boot0: 4MB partition 1 at mmcsd0 > mmcsd0boot1: 4MB partition 2 at mmcsd0 > mmcsd0rpmb: 4MB partition 3 at mmcsd0 > > Note: The media is actually an e.MMC . Continuing the output . . . > > . . . > Release APs...done > regulator: shutting down unused regulators > GEOM: new disk mmcsd0 > regulator: shutting down vcc_sd... Trying to mount root from ufs:/dev/gpt/Rock64root []... > GEOM: new disk mmcsd0boot0 > busy > GEOM: new disk mmcsd0boot1 > Unresolved linked clock found: hdmi_phy > Unresolved linked clock found: usb480m_phy > Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM > uhub1: 1 port with 1 removable, self powered > uhub0: 2 ports with 2 removable, self powered > uhub3: 1 port with 1 removable, self powered > uhub2: 1 port with 1 removable, self powered > ugen4.2: at usbus4 > umass0 on uhub0 > umass0: on usbus4 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0: Attached to scbus0 > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > GEOM: new disk da0 > pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Direct Access SPC-4 SCSI device > pass0: Serial Number REPLACED > pass0: 400.000MB/s transfers > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number REPLACED > da0: 400.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=0x2 > da0: Delete methods: > random: unblocking device. > Warning: bad time from time-of-day clock, system time will not be set accurately > Dual Console: Serial Primary, Video Secondary > start_init: trying /sbin/init > . . . > > (I'll stop with that.) > > So I end up with a 1400042 kernel and a 1400043 world in order to > boot. > > The e.MMC has only: > > # ls -FTld * > -r--r--r-- 1 root wheel 6170 Feb 1 04:48:34 2020 COPYRIGHT > drwxr-xr-x 23 root wheel 1536 Dec 8 20:18:34 2021 boot/ > drwxr-xr-x 2 root wheel 512 Apr 26 14:39:22 2020 etc/ > drwx------ 2 root wheel 33280 Nov 27 09:46:08 2019 lost+found/ > > where the etc/ has only: > > # find etc/ -print > etc/ > etc/hostid > > World comes from the USB3 SSD that is attached but the kernel > comes from the e.MMC instead. (The kernel can deal with the > USB3 SSD just fine, unlike the U-Boot that is involved.) > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > Could you try reverting 8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 capability check" and let me know ? Thanks, -- Emmanuel Vadot From nobody Thu Dec 9 07:56:04 2021 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 2D2CE18D2FFB; Thu, 9 Dec 2021 07:56:12 +0000 (UTC) (envelope-from peterj@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8mZ36W6Nz3Bv6; Thu, 9 Dec 2021 07:56:11 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id 38EB54CEF; Thu, 9 Dec 2021 07:56:10 +0000 (UTC) (envelope-from peterj@freebsd.org) Date: Thu, 9 Dec 2021 18:56:04 +1100 From: Peter Jeremy To: Emmanuel Vadot Cc: marklmi@yahoo.com, Mark Millard via freebsd-current , Free BSD , "wma@freebsd.org" Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? Message-ID: References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J6+/LmI2UsdAzFcT" Content-Disposition: inline In-Reply-To: <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639036571; 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=4pbVLCEhWLw5S1+g0maESBGGdmeJJlcWjzblgNS6L3g=; b=mWzyOtaaNEfwfjY6r/lJfjK8L8NP6YaabcKBbvQnkEuozhEebBMdVld1hARyMXA2EkHyc1 S+Gw3QEZiyMccR6QMEEzl5j5sxwHV7rFHIlqLc9cgNc13WQ60kRhEc+Bfv7B4sUPc2CCgo 3EuEun1iGiJg7ptt+WAc1xzhhlX0h21Wd21gfQZHZrGiDly+SBeawRgnzOFQQF7pJLZ6/Q T9XPWIVK/wtfCiGBF3R9d0NunzxCLe/lKt8K7TSm6eshJ6ik2/Ts7vDFfz7wiZ4zBiZI3V RLCmUKX97/5NdCI6ihgMaggtWnoYthFS7otniMva29Swn4gbKNd2dOZ0FpMNaA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639036571; a=rsa-sha256; cv=none; b=V7jHe5MD6XsfMNsiNYsVX1vr8vkZIG2k9NdqpPG/Qbi6F6dX3BEMrlAak6hrvqWhtm5Fou I76pFQonjkHGOuMf5zV1J01AXZaenbGFocWbvs4DyzOFI60dImflVTkJN4Xwh+IXcs+RvB MAwVA2S4uxYX1SrRfnyFK+edKa6MEhFAw2o6fX8hpyq6IvA/DVFN4dJU83gWHMELwbbU4O unzkBiL1ml6+LiwJ5A1eyOBXa1ZbAjbj7vKwyeZ3Yb+qjjeQOveuXdkJKityZQf4i/l+Z5 CeuRx04rm0kSCM1x2f9YOHtmNxeC3HNfwlbWaDN8/Y8CIpNkE8I88AK6cOmK5g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --J6+/LmI2UsdAzFcT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-Dec-09 08:19:30 +0100, Emmanuel Vadot wrote: > > Hi Mark, > >On Wed, 8 Dec 2021 20:36:20 -0800 >Mark Millard via freebsd-current wrote: > >> [ Note: wma@FreeBSD.org is only a guess, based on: >> https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/00= 1931.html ] >>=20 >> Attempting to update to: >>=20 >> main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 >>=20 >> resulted in boot failure (showing some boot -v output): [hang just before root is mounted] > Could you try reverting=20 >8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 >capability check" and let me know ? I had exactly the same boot failure but was still working backwards through the root mount code trying to isolate the issue. Reverting 8661e085fb953855dbc7059f21a64a05ae61b22c solves the problem for me. I'd noticed the mmc1 difference and mmcsd1 error: mmc1: bus: 8bit, 200MHz (HS200 timing) mmc1: memory: 30310400 blocks, erase sector 1024 blocks mmc1: setting transfer rate to 150.000MHz (HS200 timing) bud I didn't think it was the cause. I had tracked down that the hang was somewhere between https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c#n779 and https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c#n1008 which led me to suspect that the problem might be in the geom layer (eg g_waitidle()) but was still considering where to add my next tranche of printf's when I saw Mark's mail. --=20 Peter Jeremy --J6+/LmI2UsdAzFcT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmGxtotfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzRyaw/+O2tvQyhKuY1h8uEf9bI1ovNWl8g6tLm4cIMotRcsvcsfmi4HgCAxZqTJ 0FYhYvU/kIe+8zWnjHEaHhPnbUYKiy52NB+VAGI2hyGSrA/TGNaxQytrrw/2jIQ8 /IfyCeYjBZHEPlncl59PzjZe3EPyy4ALd8ucQbChCTbpB1CSXIXMKtshWKsdvSen a+vNsUP/W74LTQ7tA3mbP6KnpVJS1aTUSULC2CrpvBugCL+UBziY4bUqFEi1gSAX yZ2DfeUI2aYHJ2ax/HqHIeFjAMEP5RC29v6oKqfpA013TnKFQgSxwZxPet/cpmpu Xq+qwMnfOsq4J8wVmP79uIfgEWOCZWiORZcYhac/0zHwbJoZo39BWMqqNr8YB9ma 4b84QV+wPMyCsTFIjWG5St5d0TYD31/eaHxNv614FNSbZKY+Cycg+xTkIPZI0caB XIfDjDKggeApufKQ2kpzNMH0RmqXWnXaoVfIt7fByR33E4J2za0MDDWBqXS5OGHl CXXtvKGG5cHCDnITC8ljb4Ao8x/Rut3utktQVqtARNu9AwGRpej8VoUi+AbaL6FR xtYGfrAY5VPZ9fCfprc9U/9WeFQ7tA5EHqmj5EBFWzjECHzE8EPHGGutwexIsNPo fT1TQi426eFX+TNjylh8w3/oKuWw6NSrjw2UGfEXBdOX5qlBCfc= =8yfU -----END PGP SIGNATURE----- --J6+/LmI2UsdAzFcT-- From nobody Thu Dec 9 13:36:10 2021 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 B74AC18CF402 for ; Thu, 9 Dec 2021 13:33:42 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8w3T3TYBz4fs0 for ; Thu, 9 Dec 2021 13:33:41 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-ed1-x531.google.com with SMTP id z5so19747510edd.3 for ; Thu, 09 Dec 2021 05:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=VTX23ETeVJlDm/+m26e+4CLimbsJJH1AH4Bs9CcbZNk=; b=QpfTFNHWV/uwFFK8PYZ02HdRhAtn9pXgy0aIzRMs1DTBKzhrqTHc8mbdxf1P6Fy6IZ HnHLUQPQuhEnUQjJagVznSE7ST4VfIrNAg71TL/aNBqDhOyk7TrCQzJ+BdaMlLlIhmMI ItHF11SQ/vpcbjz+SFx35tBj7WyTHbj1af2MHly5LUMMd5OVZGE0VbBBiaSi4nwV6DOY oGGmD8Sl09Clru8OAHncoFibCJGpu8eqxjZsOJRFh4rc1IVB3DFwvO0lI0f33CKWeJwZ AXbKGF+A/m/Ntbw8WsGHD2xwNIUHyHkAxBodcby+C/TiX/YxGDH+sQYvmrSuieDQ9lQS eX+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=VTX23ETeVJlDm/+m26e+4CLimbsJJH1AH4Bs9CcbZNk=; b=fBG/DSXbqK3DaugUeQ5T30FlUaQ3li8DqrFcuz96SJXLINAPoSUu8PqxJVxGE+r1vI 9Y7PuFaD/eLZ33pkSj6o3jLBrNVC4yq5C3D6VzVJzepRUDT+yJyla2uUBnyb3M9SJ+e0 OUoEvdYdIBfauxLfLCHekfYufm/jCCYVbNOLBZg6K0/FDJXoklab08nVxWvTO/V0m2tu XqU0PeKTnavfcNsFEO3Uku4Ijov2StLT/ugQH9rmXBGAu5LA5mQ8CB6XsGMVcUNrwTMK 8hdWE1Nq+59Rj6K3Wsno9y6BB3T63Y3sEqDZRO3gIjveJHqyKqIHouRWfILg4iPBD+cO 4M1A== X-Gm-Message-State: AOAM531ABZNH5puHutXekomJIo8vEpVa4TO3Ct4Xqe1t7BhQVrUxAIt3 K/kjSP4EfAsvIFPXlaT7lRYIK/jb3sU= X-Google-Smtp-Source: ABdhPJy+faxgtpVUr4gFDnUWXXoeW0YMXk7ynB10U/detobe6nYODtifD5JxchO16GQu9qMZ1Px1dw== X-Received: by 2002:a05:6402:1a42:: with SMTP id bf2mr27708821edb.64.1639056816762; Thu, 09 Dec 2021 05:33:36 -0800 (PST) Received: from localhost ([86.57.155.118]) by smtp.gmail.com with ESMTPSA id r11sm3765784edd.70.2021.12.09.05.33.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 05:33:36 -0800 (PST) Date: Thu, 9 Dec 2021 13:36:10 +0000 From: "Sergey V. Dyatko" To: Subject: 14-current: unable to boot after upgrade (installworld) Message-ID: <20211209163610.0cc4f7c6@gmail.com> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J8w3T3TYBz4fs0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=QpfTFNHW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sergeydyatko@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=sergeydyatko@gmail.com X-Spamd-Result: default: False [-3.38 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.38)[-0.382]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::531:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh 14-current from git,it looked like this: 1) git pull https://git.freebsd.org/src.git /usr/src 2) cd /usr/src ; make buildworld; make kernel 3) shutdown -r now after that I _successfully_ booted into 14-current and continued with etcupdate -p make installworld etcupdate -B shutdown -r now but after that server doesn't come back. After I conneted to this server via IPMI ip-kvm I saw following (sorry for external link): https://i.imgur.com/jH6MHd2.png Well. There was a migration to zol between r368473 and current 'main' branch so I decided to install fresh 14-current from snapshot FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid possible problems and again, after make kernel and reboot OS runs, but after installworld I ended up in the same situation thoughts ? -- wbr, Sergey From nobody Thu Dec 9 14:56:43 2021 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 5F3BD18DE0E6 for ; Thu, 9 Dec 2021 14:56:47 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8xvM0s2wz4qP7; Thu, 9 Dec 2021 14:56:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 98DD7785E; Thu, 9 Dec 2021 14:56:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <4212fb5b-7f60-2b7a-3d83-12903b63f0f8@FreeBSD.org> Date: Thu, 9 Dec 2021 16:56:43 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.0 Subject: Re: 14-current: unable to boot after upgrade (installworld) Content-Language: en-US To: "Sergey V. Dyatko" , freebsd-current@freebsd.org References: <20211209163610.0cc4f7c6@gmail.com> From: Andriy Gapon In-Reply-To: <20211209163610.0cc4f7c6@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639061807; 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=M8tizCXeYwNOF1vilrFyxisxLklVlhDhsYz3v5ft65E=; b=pKHk3jGip3yo5dBYedqtRhYilcrRllLRebkn/I9nAUjArRdhRz8uCpgXtNhQLQE8EJ20HG DTAb9gFPm4/CrIyBdCEZINpJAg9YpZxtfnhPj+3BI0dxZ1OXWR4PyvfLBG6v44v3Lkn8wS Vyf8u6FlNZ9Ff9OVR/+vjnaN4hf1OEXqScAQlz1PEZ6TvBYPQ7bwwjA8sXuXxb5wFc+vaV /AziwgxYq2DIj/cYnSAsKB2HBkUJRaP5k3nWOtEfwxBvaWTvPyiWkqx+yUWw0jyl10kDqU In7mlfRBwmaDChWW4+OMoP9cHeVaCzxj7965MqCiUYrpUeVuCcrOya37GTaM6g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639061807; a=rsa-sha256; cv=none; b=iOK/0Ywbm9Zz3PA20essLfvCrOCi8REDOdlbGpSkbXDoJ147+/a1BxjXCecJZwkhBrNcku To3UC8359soeBg5UWHaSSvvcg96jWIgaTOz62Vx8ITUBOcfQmKWO6i8QUA+rj3v+w8bnNC KypFdV2UaNyauO6XYlSq7B8wpmeDhA78Ln7qUfyFEtrTf175TClMt+Z2B2ihGCJjx4QMKS PpwUVf/Oiqav/U06k2wX2OOy242OKv45wibLH+j9i+7DtuRRx/1QW6Y0TC+RQZ2q58NA9o OEMVmKUyv/+eUgEKtlnUP0UqRrfclqbysxfJZ8uvO7IeZcPCy5Xf2WeWPot31w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 09/12/2021 15:36, Sergey V. Dyatko wrote: > Hi, > > Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh > 14-current from git,it looked like this: > 1) git pull https://git.freebsd.org/src.git /usr/src > 2) cd /usr/src ; make buildworld; make kernel > 3) shutdown -r now > after that I _successfully_ booted into 14-current and continued with > etcupdate -p > make installworld > etcupdate -B > shutdown -r now > > but after that server doesn't come back. After I conneted to this server via > IPMI ip-kvm I saw following (sorry for external link): > https://i.imgur.com/jH6MHd2.png > > Well. There was a migration to zol between r368473 and current 'main' branch so > I decided to install fresh 14-current from snapshot > FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid > possible problems > > and again, after make kernel and reboot OS runs, but after installworld I ended up in the same situation > > thoughts ? Try to update boot blocks. Not sure what you use, like gptzfsboot, etc. -- Andriy Gapon From nobody Thu Dec 9 14:58:07 2021 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 1111618DEBB6 for ; Thu, 9 Dec 2021 14:58:12 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8xwz4k6bz4r3D for ; Thu, 9 Dec 2021 14:58:11 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 1B9Ew7LN074370 for ; Thu, 9 Dec 2021 23:58:07 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 9 Dec 2021 23:58:07 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: 14-current: unable to boot after upgrade (installworld) Message-Id: <20211209235807.31ee2ecea5bc08e243870da3@dec.sakura.ne.jp> In-Reply-To: <20211209163610.0cc4f7c6@gmail.com> References: <20211209163610.0cc4f7c6@gmail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J8xwz4k6bz4r3D X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 9 Dec 2021 13:36:10 +0000 "Sergey V. Dyatko" wrote: > Hi, > > Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh > 14-current from git,it looked like this: > 1) git pull https://git.freebsd.org/src.git /usr/src > 2) cd /usr/src ; make buildworld; make kernel > 3) shutdown -r now > after that I _successfully_ booted into 14-current and continued with > etcupdate -p > make installworld > etcupdate -B > shutdown -r now > > but after that server doesn't come back. After I conneted to this server via > IPMI ip-kvm I saw following (sorry for external link): > https://i.imgur.com/jH6MHd2.png > > Well. There was a migration to zol between r368473 and current 'main' branch so > I decided to install fresh 14-current from snapshot > FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid > possible problems > > and again, after make kernel and reboot OS runs, but after installworld I ended up in the same situation > > thoughts ? > > -- > wbr, Sergey > > Bootcode should be updated. The procedure you wrote doesn't seem to update it. -- Tomoaki AOKI From nobody Thu Dec 9 15:20:10 2021 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 0901E18E2D88 for ; Thu, 9 Dec 2021 15:20:13 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8yQN1hffz4v7Z for ; Thu, 9 Dec 2021 15:20:12 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x733.google.com with SMTP id t6so5161677qkg.1 for ; Thu, 09 Dec 2021 07:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition; bh=1VM8UexHrFwDOdXtvDfnAMthtu99lYSEeTWpJhQuZzA=; b=E/yh+m2Y4HkPuRrFtjOVwF+FRO44avg49NaIcbOcYHTUsXCgd25m2klbXOZPTxRU8l IKiBOg7VdTPmrEksjKUcJ/wAW6pSvT2fAVlBKHb3Nz0Xpcb50eUzy9E/f3Z6a4Tda+lC JQ5Cv/fqe4+tenlE3q9VJLei6llM9Ou0AfL5oorH7vIpAUBCNb6oalQ7D0ELUAstqt9J 2zEBxI4dB7Zbg8YgHH34mx6yyK7QcGsw/PHrMDBd73wFsgod/H81DSfoAfj50BVYDoC/ SIzTBXpZjxeR5itt3eY7VkR3Zx44hBh7/u2J5NMUH50wdGvf77NpZC5/BNNy8+iDj3nz fs4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=1VM8UexHrFwDOdXtvDfnAMthtu99lYSEeTWpJhQuZzA=; b=XBXLwx7lcgcgrvI37RiPB5kUgOexez1yz8qCrMCo34QgDKOGnJtUqH29F2zzvNJ7BU B+yZtncTJ8fsZumzqLGxsC2g/1IOBEq2C4+IgpUarxsPdokWtThrCywvWGkafBODI+fy uNDQkPk+WbzIomBA8CmKckbtxs2CQoX/DEukpMblNppGX3u9rvAaLVcEDtp0agrzAG7S /4H5PtHHBXvUC2vxf3FGq/N7co+9Ym05J1OUqvmsR7N4gKHerawEIDUQu83Uge2YVbRe Vigcfeyj6XJ7qXJ5behLH7VYpCpkbFWMvqS6/jIE6ZDvJMgajuE2i0E0r1+qiiW2S47N YuuA== X-Gm-Message-State: AOAM5306KwkZlKjrAL1i0qjFgJfryzu90Copua214WJmCQ2FaDynrGIb /ufB7wjJEsoUPl3HDvNuoELV4/xgcYl2iuXXp4kOwOIYenbgav0Z5ifBfIAdvDlClQl+DDzIafc eZ4LDCzVfZgBy/PV48swLXN02/n1ie/wXFbUwwdlp5z2TiserqLnHe5VMCKAJZ1pyX7e3gJr7AZ 5Fppr03tWcGkMP X-Google-Smtp-Source: ABdhPJxWV56aVEcu1rlt5imlzEqmCFkiQUsqKEu7Vm77L8qoTrHJNTA9sWVd1Nj64bLf0wVgGQPavQ== X-Received: by 2002:a05:620a:2093:: with SMTP id e19mr14025146qka.516.1639063211520; Thu, 09 Dec 2021 07:20:11 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id c8sm35256qkp.8.2021.12.09.07.20.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 07:20:11 -0800 (PST) Date: Thu, 9 Dec 2021 10:20:10 -0500 From: Shawn Webb To: freebsd-current@freebsd.org Subject: Kernel panic in networking code Message-ID: <20211209152010.z6ofqf3ucpxkijqf@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc 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="gv4zn2hvd2gk4pez" Content-Disposition: inline X-Rspamd-Queue-Id: 4J8yQN1hffz4v7Z X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b="E/yh+m2Y"; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::733 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-3.71 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.24)[0.245]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.86)[-0.858]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[hardenedbsd.org]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::733:from]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.224.136:received] X-ThisMailContainsUnwantedMimeParts: N --gv4zn2hvd2gk4pez Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey all, It looks like there's a potential deadlock in some networking code, specifically with ipv4 jails. I can reproduce by running Poudriere on 14-CURRENT. I am using HardenedBSD 14-CURRENT, but we don't have any changes to any point in the code paths that would trigger/cause this kind of kernel panic. I've uploaded the crash.txt file here: https://hardenedbsd.org/~shawn/2021-12-09_crash-01.txt `uname -a`: FreeBSD ci-08 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD #0 h= ardened/current/master-n191216-7474f245a83: Wed Dec 8 22:44:04 EST 2021 = shawn@ci-08:/usr/obj/usr/src/amd64.amd64/sys/HARDENEDBSD amd64 Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --gv4zn2hvd2gk4pez Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmGyHqcACgkQ/y5nonf4 4fp6Lw/+OghEgXfpQ14+Cyst2LvmXIkK2lLmN1Tx6+SHOwn0MWarP6SAX4v//Aez I6A7iGDjaQwc6UrXtGMv20fIqVA94p1x6afEwgPE1LZvFKxt9bQTz9rhFTSX1Ikd BPUepnLw7YRbPizfC9omu/IHGfAfx3lGGdsilLxlZixiksaRi8zwb+v5BWN3px7a 4ChMkXiUDBI/GVOvcvzcbnUdk++54rsT+7nbpT3VNBJVRQfi8TxH7B/Fuebc6n4k 7kPvwImBY5Vk0R5Nks2WEOLwDv1TmqW5SozDb21wCSJo8Nb0LCirkciudoYJEwqY JG3vVo7CPa46oxJ4JgLITbuEC6jcr/LjCUJpBIUHRJrPyzapKk1LIE+5S0JtMx3G z8/rIrqSE/Qd6HbK7mfA03oeilcQMPeoYlX/CrcuADNPGnRaOfSs+9OrS5p96iDq 6TI35qjjxyoGo4eUW0Ln2kN0L7bDzkBUPstRogb3kC0kXpel5zAotqqStAyRcz0n PQfvzPQwM9Dxd+7tA7+Zlm743s6zcpFMXGT1suNiXLYlarGYrUKU12w/O0NC/JGJ eJ6wmSVgq2tVLsgR53mRfr2PyQcZXfpVAhEPnGuNVJPCe2sqNizde/Ttzks3bVwO RZ9tU+5SUMe72+fJjpb6JwdoSrcUF1tLVM25PNvl9eAElm+26I0= =lujs -----END PGP SIGNATURE----- --gv4zn2hvd2gk4pez-- From nobody Thu Dec 9 15:55:42 2021 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 7D86018C9F9E for ; Thu, 9 Dec 2021 15:56:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8zCh300nz50qd for ; Thu, 9 Dec 2021 15:56:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa35.google.com with SMTP id q21so4096998vkn.2 for ; Thu, 09 Dec 2021 07:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gXhWzZ54kHtMkjWZE/6WIp763pvK+pKi4NwhhteO3Js=; b=R4kHexKVOpqT4BgixZ8fJ9MKsEJopC1Bf4d7IxmP9kknnopaJ2XnUhm29jrrzgnLuk yHAPW/MfWggEMLrKeP+gpr2kY1Q2vmtIUszXrlErYFyypxr5FJkhFb5Z1IWI9N8DRwVm 7lf51dDz6XItNpX8QEQdXbdR1hivCFqag64PE+DB7Zh45fcTpIelXaRN0TgCuINxeLu9 Ghj5RInRAOpzv8jg+r2BWFZZgyXyyVVSqe8dJzptqAt8fPn9XiRFpWr/hmGm0O+iq3Vg XVjngSHlJ6iLYcPU4faKCuDATnN1p4+aeTmhApIqVLU7BsF3e+UOop1hdH4IOyDHd1pS mm/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gXhWzZ54kHtMkjWZE/6WIp763pvK+pKi4NwhhteO3Js=; b=akEhJLi2akUt1jOwQai0xI8fVURNQrJl7OTZeRKTbtMg2tsvYkZ0Qce5SZv+6+SGmk fyL8o5e9JdaN6D4mPgULcnoZDL654SiuEr6aUfggZPWv6iRQii/WGZvDkEx4zaBwghe/ ds2VMScM9jufRDCNXVoQYIrqzzbQX62YN2wj0FfdDYW1jnASq5LF83jvW1hRz57vzHe4 0MITwnjmnmKovDiBH4h+qDizsImdmqwByJWMAKqhMHNpeWi6/gtFWnWRrzWsKpcvp+5M ZB0LgxhJs2t9lqmw+I0a4d+SVULUFGvpb2ls+pVultqrG2d5vyX0enIbGsTkQeGKix3f VRjw== X-Gm-Message-State: AOAM533GHO99WTthHy2z3ExLImBmGbqdaSkzzdy0RaAoGU++7iFY0kVT iqXNHj6upB7ZQEsViiFB9Oht1M5qnTPSq6+uHxfQ2OaOelRyhQ== X-Google-Smtp-Source: ABdhPJwZCz9sV6hEzQfI3HKdHIOjVFLx7L04lNPLee6BeIMLvva32vzDeGytdZiW1QYHAdicEkURV0TbQbLvxcZwbMU= X-Received: by 2002:a05:6122:988:: with SMTP id g8mr10479010vkd.2.1639065354495; Thu, 09 Dec 2021 07:55:54 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211209163610.0cc4f7c6@gmail.com> <20211209235807.31ee2ecea5bc08e243870da3@dec.sakura.ne.jp> In-Reply-To: <20211209235807.31ee2ecea5bc08e243870da3@dec.sakura.ne.jp> From: Warner Losh Date: Thu, 9 Dec 2021 08:55:42 -0700 Message-ID: Subject: Re: 14-current: unable to boot after upgrade (installworld) To: Tomoaki AOKI Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000038115d05d2b8a46f" X-Rspamd-Queue-Id: 4J8zCh300nz50qd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000038115d05d2b8a46f Content-Type: text/plain; charset="UTF-8" On Thu, Dec 9, 2021 at 7:58 AM Tomoaki AOKI wrote: > On Thu, 9 Dec 2021 13:36:10 +0000 > "Sergey V. Dyatko" wrote: > > > Hi, > > > > Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh > > 14-current from git,it looked like this: > > 1) git pull https://git.freebsd.org/src.git /usr/src > > 2) cd /usr/src ; make buildworld; make kernel > > 3) shutdown -r now > > after that I _successfully_ booted into 14-current and continued with > > etcupdate -p > > make installworld > > etcupdate -B > > shutdown -r now > > > > but after that server doesn't come back. After I conneted to this server > via > > IPMI ip-kvm I saw following (sorry for external link): > > https://i.imgur.com/jH6MHd2.png > > > > Well. There was a migration to zol between r368473 and current 'main' > branch so > > I decided to install fresh 14-current from snapshot > > FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid > > possible problems > > > > and again, after make kernel and reboot OS runs, but after installworld > I ended up in the same situation > > > > thoughts ? > > > > -- > > wbr, Sergey > > > > > > Bootcode should be updated. > The procedure you wrote doesn't seem to update it. > The posted error is one you get when you can't read the filesystem, which is why you need to update boot blocks across the OpenZFS change. Warner --00000000000038115d05d2b8a46f-- From nobody Thu Dec 9 17:05:30 2021 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 36BB318D9051 for ; Thu, 9 Dec 2021 17:05:34 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J90ly0p2sz3DsW for ; Thu, 9 Dec 2021 17:05:34 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-il1-x12f.google.com with SMTP id t8so5932225ilu.8 for ; Thu, 09 Dec 2021 09:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=w1A8jt2FYF5hL1AfKnoVF0WEpUgEIQBmYA6TcdEnY44=; b=SqSL8mNqnIVsYEkmr7Bryi717wvz8rSA46L8WtQZF0y1w51qi1/ECioMhX60TyJzI3 HodLExT5dNfMz/syozVxaEDLbOQykKT301A0+huIkTevEqaRhnsvNxuRDEE7YeP/JwtH Ucf6hPlV/vWxiqlYy/Jbgo7PfD2EDNx8VXJmgU9JsmZHX0nGmyR62FMtvb2iuzYMTEMX 2Op1nnVQglrfjPqxEzIOUwF5vGEyI3kfFjqQj/ykqkcvu4p2DbM7nIZka03dA5sAWVPF osgHKDc1fAfciDQoTkTewupTWe8vtCZpSeZCryoPKRuqj1Mx5E3vuMNdHpLGTlwqjpeG if+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=w1A8jt2FYF5hL1AfKnoVF0WEpUgEIQBmYA6TcdEnY44=; b=zinvXYGUe4NX/LicFgzt5plj3AfOYBIfSMUcoCOXjSPPvT8yzKXSeOIIXk0pELYA9d jSF3zcxQoNI/sLA//UKnnnFSUX+KdqnhYJ9GmF1rfFMrSRb+6kbpk09Ib7DlrpLGkeiV cW3f+tSBrm7AJ02Pz2LxrTqKqkAcRAEXKg0Mtro0d/t1PHfwJ5h6aMN/+2rP7pOzC48j 9izylKu4sPRrir8zz63A3XyRgG+fHj6FVJKfQhzzTUfCOjBr6S7qWFIvYGpTvKJSFt/O NZlOogO3qyCCrzWZw1UDMTCTiCHX/ahnQJQew29tWyosU0xguSiQK16OBM1udUfBK2kF 0luQ== X-Gm-Message-State: AOAM531BUzTwdKqgojiOvy5Sr+1v6hOeAtW4W8x6Bud1GIlCFgrv5yD7 gQsuCNjjTxVe85RmWc1BawM= X-Google-Smtp-Source: ABdhPJxvXo/DulPvgkMZCoQ8fb2FjuHI8yiUEN7X4oh9bdwfoyDeH3364K/MoO53HxPZeU7WRn3/ag== X-Received: by 2002:a05:6e02:5c4:: with SMTP id l4mr16844766ils.317.1639069533399; Thu, 09 Dec 2021 09:05:33 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id n11sm217389ili.33.2021.12.09.09.05.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 09:05:32 -0800 (PST) Date: Thu, 9 Dec 2021 12:05:30 -0500 From: Mark Johnston To: Shawn Webb Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic in networking code Message-ID: References: <20211209152010.z6ofqf3ucpxkijqf@mutt-hbsd> 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: <20211209152010.z6ofqf3ucpxkijqf@mutt-hbsd> X-Rspamd-Queue-Id: 4J90ly0p2sz3DsW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Dec 09, 2021 at 10:20:10AM -0500, Shawn Webb wrote: > Hey all, > > It looks like there's a potential deadlock in some networking code, > specifically with ipv4 jails. I can reproduce by running Poudriere on > 14-CURRENT. > > I am using HardenedBSD 14-CURRENT, but we don't have any changes to > any point in the code paths that would trigger/cause this kind of > kernel panic. > > I've uploaded the crash.txt file here: > https://hardenedbsd.org/~shawn/2021-12-09_crash-01.txt There is some WIP to address this in https://reviews.freebsd.org/D33339 and its followup revision. From nobody Thu Dec 9 17:46:30 2021 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 3678318E1F35 for ; Thu, 9 Dec 2021 17:46:33 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4J91gD5XRhz3N2n for ; Thu, 9 Dec 2021 17:46:32 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 1B9HkU1a023850; Thu, 9 Dec 2021 17:46:30 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 1B9HkUf4023849; Thu, 9 Dec 2021 17:46:30 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202112091746.1B9HkUf4023849@donotpassgo.dyslexicfish.net> Date: Thu, 09 Dec 2021 17:46:30 +0000 Organization: Dyslexic Fish To: freebsd-current@FreeBSD.org, dclarke@blastwave.org Subject: Re: pkg sqlite database borked ( again ). How to restore? References: <4d9d5406-c257-e5cb-d237-d26889468f62@blastwave.org> <202111291122.1ATBM1vp034286@donotpassgo.dyslexicfish.net> <3b4d90c7-cacf-8b9d-60cd-694e68e76ed1@blastwave.org> In-Reply-To: <3b4d90c7-cacf-8b9d-60cd-694e68e76ed1@blastwave.org> User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Thu, 09 Dec 2021 17:46:30 +0000 (GMT) X-Rspamd-Queue-Id: 4J91gD5XRhz3N2n X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-2.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Dennis Clarke via freebsd-current wrote: > Ah well ... that seems to toss a ton of errors and yet works ? Ooops. Sorry for the delay, I originally missed your post. I forgot to mention, this is for rebuilding the db from scratch, as such, you needed to delete the old db file first - hence the warnings about tables already existing, and presumably the other "UNIQUE" errors. I'd personally be uncomfortable keeping it like this, but I don't know enought about pkg, but if as you said it works, it seems the merge went ok! Cheers, Jamie From nobody Thu Dec 9 18:06:21 2021 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 B6A2918E5B55 for ; Thu, 9 Dec 2021 18:03:57 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J923K4Rj9z3hDk for ; Thu, 9 Dec 2021 18:03:57 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-yb1-xb31.google.com with SMTP id y68so15680206ybe.1 for ; Thu, 09 Dec 2021 10:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sUWup+5OmjiD3i6jTiDM31eLgvwRJSC6NmPzG2tNlWI=; b=ceB+R63Xnatva00VvmijD83cF6rYUXi98UsreUlHbESM5p7adJmClYI6O5PhJUehx6 soqirCkxB/QVPtxPuSqTzoU3Ez2LuBnM5X0awLouehxwTz43pAyUK7wOqvaXliquWq1O xpyPCq830zEWiD6GZ76xh5ka2eeqHmbG4zeTdBPv8RXqixtLQzrylgejElsBLo51GNow OwZ1k7HS6PPSjJUWZqShRvik3SV8u0A1GRhRKY4VCqRKqYjiF9sY9LMYVsTPFiSSbh9e sAMf/ShEmX1ElqvJQTxr0USwGNRj9td5hdRF4oBJwN9aurr92EKGfavIGHkDyVymLuHJ n66A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sUWup+5OmjiD3i6jTiDM31eLgvwRJSC6NmPzG2tNlWI=; b=qil445BS+dgPZGCw3L4+i/G7B9HSsALlvdGpZapEfZN+XKhCzMtdbhrXCR6vVkGARo GDX47BRkPPYp6ERVso4g3RHjb6EvGnZuclUmuaIJQsxGahnewZelm4eFxXm6OxiA9F0i TsMRXPnr03pgLZy/9N+F88DAhN14NPEj1Nbgsl1KI/EZqDKm+iB6omkIsQ8HSf19AyEf 6s2hy+Kqlophi5UaMWE9jxmXYz2vGa0p30jgYCFNteiTe8NVJQZNgv92a+s9jHWlmT2G MGnfwwwl19sA5qseDkmLwJ9C+TSZ0dYWPYw30yabtyY6K6WWlHQwPPxyJGVm2YbSoRz4 2Rbg== X-Gm-Message-State: AOAM531YJve4uYYKktG86XUb1q/QJjbOiaHA21s5BpgUq+Yj6i7gnjhK bqYzJrXMy4sU+FKCj7N3K8nzTip2Nenc8R3JidIalZqCRJs= X-Google-Smtp-Source: ABdhPJw/qy5Fbu32KlnoBEDuhGRwdnqc9/cjVz0kbuanKfuVumewLBMHW5F2qt6RoDjqIGllN8d00y3c5NuomU4nlNA= X-Received: by 2002:a5b:8c4:: with SMTP id w4mr8232066ybq.333.1639073036869; Thu, 09 Dec 2021 10:03:56 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211209163610.0cc4f7c6@gmail.com> <20211209235807.31ee2ecea5bc08e243870da3@dec.sakura.ne.jp> In-Reply-To: From: Sergey Dyatko Date: Thu, 9 Dec 2021 18:06:21 +0000 Message-ID: Subject: Re: 14-current: unable to boot after upgrade (installworld) To: Warner Losh Cc: Tomoaki AOKI , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000001fa3ba05d2ba6e76" X-Rspamd-Queue-Id: 4J923K4Rj9z3hDk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000001fa3ba05d2ba6e76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was sure the installer did it when I reinstalled the system from scratch.= I can load 14-current successfully after boot via PXE and installworld with 13-current now I did the following: 1) boot from HDDs FreeBSD 14.0-CURRENT #0 main-n251494-f953785b3df (with 'old' world) 2)run installworld (f953785b3df) 3) run `gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da${D}` command , where D=3D4..7 root@dl:/usr/src # zpool status pool: zroot state: ONLINE config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da4p2 ONLINE 0 0 0 da5p2 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 da6p2 ONLINE 0 0 0 da7p2 ONLINE 0 0 0 errors: No known data errors after `shutdown -r now` system still doesn't boot with the same error. As far I can see, there is /boot/lua/config.lua present, but when I try to run command more /boot/lua/config.lua system hangs with following error: https://imgur.com/5p0xu6W.png =D1=87=D1=82, 9 =D0=B4=D0=B5=D0=BA. 2021 =D0=B3. =D0=B2 15:56, Warner Losh = : > On Thu, Dec 9, 2021 at 7:58 AM Tomoaki AOKI > wrote: > > > On Thu, 9 Dec 2021 13:36:10 +0000 > > "Sergey V. Dyatko" wrote: > > > > > Hi, > > > > > > Yesterday I tried to upgrade old 13-current (svn rev r368473) to fres= h > > > 14-current from git,it looked like this: > > > 1) git pull https://git.freebsd.org/src.git /usr/src > > > 2) cd /usr/src ; make buildworld; make kernel > > > 3) shutdown -r now > > > after that I _successfully_ booted into 14-current and continued with > > > etcupdate -p > > > make installworld > > > etcupdate -B > > > shutdown -r now > > > > > > but after that server doesn't come back. After I conneted to this > server > > via > > > IPMI ip-kvm I saw following (sorry for external link): > > > https://i.imgur.com/jH6MHd2.png > > > > > > Well. There was a migration to zol between r368473 and current 'main' > > branch so > > > I decided to install fresh 14-current from snapshot > > > FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to > avoid > > > possible problems > > > > > > and again, after make kernel and reboot OS runs, but after installwor= ld > > I ended up in the same situation > > > > > > thoughts ? > > > > > > -- > > > wbr, Sergey > > > > > > > > > > Bootcode should be updated. > > The procedure you wrote doesn't seem to update it. > > > > The posted error is one you get when you can't read the filesystem, which > is why you need to update > boot blocks across the OpenZFS change. > > Warner > --0000000000001fa3ba05d2ba6e76-- From nobody Thu Dec 9 18:19:11 2021 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 6081018E9F06 for ; Thu, 9 Dec 2021 18:19:26 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st43p00im-ztbu10063601.me.com (st43p00im-ztbu10063601.me.com [17.58.63.174]) (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 4J92PB23kgz3lrL for ; Thu, 9 Dec 2021 18:19:26 +0000 (UTC) (envelope-from tsoome@me.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1639073960; bh=8cO+AlvD8h6+I26bDVMFkLbT9Gnra8TUdwAUzWjgj2M=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=mQujAK897dYZH38RjnVrdRgSLRHfnzVyFj0hZX/8Iw0ByIAgac7/JfxeEYqw03aPN bMnu5oNJKFV+s/MEvnElIEh8UtoyH8xiEjatO+V0SCC5xVpmvxqKGfxSGAntfjyz69 auSog6V7c4M+EdfEdFKUxmc6Vl9WBplyKtNq6Acd6FxXulzbm1SFg1dS2kr8elJ4II 5gyEfa/m7kElmobFzAzEDv8o1Aog6W8ZGnnJR+UN/pYlKPuuHdryXF210rbZZNXju3 8adZez+Bi2aEBAPURiR5GS+C+xSnMTXaqwpTOovszL4kAREYIl+JkzwFLGl6XOpRE9 gBxX21yItXORw== Received: from smtpclient.apple (148-52-235-80.sta.estpak.ee [80.235.52.148]) by st43p00im-ztbu10063601.me.com (Postfix) with ESMTPSA id 38D23700241; Thu, 9 Dec 2021 18:19:18 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: 14-current: unable to boot after upgrade (installworld) In-Reply-To: Date: Thu, 9 Dec 2021 20:19:11 +0200 Cc: Warner Losh , Tomoaki AOKI , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <13846D48-70DF-47FD-B2DA-187A33F0F5C0@me.com> References: <20211209163610.0cc4f7c6@gmail.com> <20211209235807.31ee2ecea5bc08e243870da3@dec.sakura.ne.jp> To: Sergey Dyatko X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.425,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-12-09=5F07:2021-12-08=5F01,2021-12-09=5F07,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 mlxscore=0 malwarescore=0 clxscore=1011 mlxlogscore=960 bulkscore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2112090096 X-Rspamd-Queue-Id: 4J92PB23kgz3lrL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] Reply-To: tsoome@me.com From: Toomas Soome via freebsd-current X-Original-From: Toomas Soome X-ThisMailContainsUnwantedMimeParts: N > On 9. Dec 2021, at 20:06, Sergey Dyatko = wrote: >=20 > I was sure the installer did it when I reinstalled the system from = scratch. I > can load 14-current successfully after boot via PXE and installworld = with > 13-current > now I did the following: > 1) boot from HDDs FreeBSD 14.0-CURRENT #0 main-n251494-f953785b3df = (with > 'old' world) > 2)run installworld (f953785b3df) > 3) run `gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da${D}` > command , where D=3D4..7 > root@dl:/usr/src # zpool status > pool: zroot > state: ONLINE > config: >=20 > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > da4p2 ONLINE 0 0 0 > da5p2 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > da6p2 ONLINE 0 0 0 > da7p2 ONLINE 0 0 0 > errors: No known data errors >=20 > after `shutdown -r now` system still doesn't boot with the same = error. As > far I can see, there is /boot/lua/config.lua present, but when I try = to run > command more /boot/lua/config.lua system hangs with following error: > https://imgur.com/5p0xu6W.png >=20 You seem to get 2x BTX panic, could you try to create video from = console, so we could get register dumps? can this system do UEFI boot and if so, can you test it? Could you post = partition tables? rgds, toomas >=20 > =D1=87=D1=82, 9 =D0=B4=D0=B5=D0=BA. 2021 =D0=B3. =D0=B2 15:56, Warner = Losh : >=20 >> On Thu, Dec 9, 2021 at 7:58 AM Tomoaki AOKI = >> wrote: >>=20 >>> On Thu, 9 Dec 2021 13:36:10 +0000 >>> "Sergey V. Dyatko" wrote: >>>=20 >>>> Hi, >>>>=20 >>>> Yesterday I tried to upgrade old 13-current (svn rev r368473) to = fresh >>>> 14-current from git,it looked like this: >>>> 1) git pull https://git.freebsd.org/src.git /usr/src >>>> 2) cd /usr/src ; make buildworld; make kernel >>>> 3) shutdown -r now >>>> after that I _successfully_ booted into 14-current and continued = with >>>> etcupdate -p >>>> make installworld >>>> etcupdate -B >>>> shutdown -r now >>>>=20 >>>> but after that server doesn't come back. After I conneted to this >> server >>> via >>>> IPMI ip-kvm I saw following (sorry for external link): >>>> https://i.imgur.com/jH6MHd2.png >>>>=20 >>>> Well. There was a migration to zol between r368473 and current = 'main' >>> branch so >>>> I decided to install fresh 14-current from snapshot >>>> FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to >> avoid >>>> possible problems >>>>=20 >>>> and again, after make kernel and reboot OS runs, but after = installworld >>> I ended up in the same situation >>>>=20 >>>> thoughts ? >>>>=20 >>>> -- >>>> wbr, Sergey >>>>=20 >>>>=20 >>>=20 >>> Bootcode should be updated. >>> The procedure you wrote doesn't seem to update it. >>>=20 >>=20 >> The posted error is one you get when you can't read the filesystem, = which >> is why you need to update >> boot blocks across the OpenZFS change. >>=20 >> Warner >>=20 From nobody Thu Dec 9 18:34:09 2021 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 7366E18EE884 for ; Thu, 9 Dec 2021 18:34:11 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J92kC233jz3rGm for ; Thu, 9 Dec 2021 18:34:11 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt1-x835.google.com with SMTP id n15so6234216qta.0 for ; Thu, 09 Dec 2021 10:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=iR5+mDrB94zcSimABsMuUuBrCQjuvw+DJuMNWPOktGY=; b=jreMvA1nKmB2mXbMw64b7BTT7V94xoPEbz2MHsBId5LSU2KBFNR47eN0AwXrwaU9Rr fM4gP6rcxlG0b2VJ/sGGQwaV3iww/aH2uHwDjT9VokF+lkJQmRTMG5GExCbA68B+YBk2 xvUqVKz/D/6mgBc8jRICCPtgM2u1kccmqTKUcdDx05a4p3ZjYzmUcYZtH+XORHPRZEPv WEI+OwvuhEJvVbp9rB5QK0VBaXBOE7Ml4JYgdrfJuliVnQQDRDaty3A/S87vo/UZJQTn 2rTp3RcVUQs37Zji0eEoggO9Dp0NkDmfeTT8xr/jLWzxyR5Ygiuux6dZN7z0jZO8ujZX hMlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=iR5+mDrB94zcSimABsMuUuBrCQjuvw+DJuMNWPOktGY=; b=AJ3WYW9SuSA+I23gQNAWSKymY/gUCfSyHF79bijRktCxurTvrYo/TlAwnP69/RASE9 y6nr6zoPo0zfpZyT/VMtsE0vATcrQuV9H7uEwAuZ5ILb3fqTPUwujB0mpkeAlO2j+qzK 5n6gCOx0w7n4PTgtbI/vgM3MRAKOvEMr4PpDcHDXxWLDSy/5WAbLd9b8ggnZhj3MD3yO W7sV8+xEqp1Tz10CZNu2dhBzQWt+8uYC4smh92uamhDaV8SQB2XOJnUaocsQOPkmJNIn 6x/0A99l0eGZ2X2lqBQh4y3sAaNevXiYeARlFUY/H3CAdsyIjb3AhmKhwn+bDFwqhkXW 097Q== X-Gm-Message-State: AOAM532npI+SfdXfUatNjUCSKkcQ7Lg2dd31eXIrWJBmMhAcN5Of6ESz YAvdRkFe2zv7k1VJ9l8R43pmT9OPV3iCK25h X-Google-Smtp-Source: ABdhPJzl0UDURrcLjD0J++3EQt8/DEFDfDocVPB9TUiRkrrd7MWzM/zkI6f2o+rupyze+gsRune3Iw== X-Received: by 2002:ac8:5710:: with SMTP id 16mr19882780qtw.140.1639074850839; Thu, 09 Dec 2021 10:34:10 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id bk25sm243184qkb.13.2021.12.09.10.34.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 10:34:10 -0800 (PST) Date: Thu, 9 Dec 2021 13:34:09 -0500 From: Shawn Webb To: Mark Johnston Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic in networking code Message-ID: <20211209183409.2xbfgszx7miw3rhv@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <20211209152010.z6ofqf3ucpxkijqf@mutt-hbsd> 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="e7xa75o3jdlqaggr" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J92kC233jz3rGm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --e7xa75o3jdlqaggr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 09, 2021 at 12:05:30PM -0500, Mark Johnston wrote: > On Thu, Dec 09, 2021 at 10:20:10AM -0500, Shawn Webb wrote: > > Hey all, > >=20 > > It looks like there's a potential deadlock in some networking code, > > specifically with ipv4 jails. I can reproduce by running Poudriere on > > 14-CURRENT. > >=20 > > I am using HardenedBSD 14-CURRENT, but we don't have any changes to > > any point in the code paths that would trigger/cause this kind of > > kernel panic. > >=20 > > I've uploaded the crash.txt file here: > > https://hardenedbsd.org/~shawn/2021-12-09_crash-01.txt >=20 > There is some WIP to address this in https://reviews.freebsd.org/D33339 > and its followup revision. Awesome. Thanks for the response! I'll follow along. I'm happy to test out the patch before it lands if needed/wanted. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --e7xa75o3jdlqaggr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmGyTB4ACgkQ/y5nonf4 4fqV8A//VGIhZOvieOAV4cF/m2DnryeZTyROubZlrM5JgJAKuUlENhv+bOjHwVzB V8DEvDNZxUdScT9zwYxQ6FUGYgaA3Wes9HXqYfVIWQCUAC+Fmnw9UGAyo88H3Y8W 0qByFHS7jC/K2euEe/ZshiNFZ88y7aeSNI4jKmEaVuLmppRMhyZCvAi1ff8kfN7M SkL6L9TTQRf6j7GBW9hBQUq4BSponBe2Um5DOoZvHdLXQdg6i4J8cECX4aIGYrh8 GLkPfUAwd31H8i41crALyR0/cMzt4RGD9mgZti18k+J8O628idBElKFOxOscZSKi GysQeR9HMjt/oPupMtvIVrT6HTehpU7R5Y1vosSnk0vNsvwap4mHFRhRc1rkLYm6 +U9IMLH8l1cr+4q3RQDiCViYYObhFQvdPCPEsH8gvA7R0wkjz6vajsPODANCvnfX ZCfc82cBAAnMg1nL+8+do3dYZ8dfkWu3iQcdhp6KDM9/N+O9bkuPruZNPw1SH3TS XM93earOHZTkeqR9cbSnG6Lz973hc85EcVoHPY9m+dWnPTcvSjmolUBEHd1WgOUD ZNz/7U1urHp4tuwUHwe0N+NAqq3BJpIrXC055UIF0ZJgfT/C+E1F5OHkfnZ/AY0B dpZ89BZSuWwnHMsbNaZl5ChEx2hiQtEkQvbDfJa4Jn2cPnGoA2w= =/6S4 -----END PGP SIGNATURE----- --e7xa75o3jdlqaggr-- From nobody Thu Dec 9 18:37:18 2021 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 BD8BE18EEF59 for ; Thu, 9 Dec 2021 18:37:30 +0000 (UTC) (envelope-from kp@krion.cc) Received: from krion.cc (krion.cc [148.251.235.209]) (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 4J92p16YWYz3sc1; Thu, 9 Dec 2021 18:37:29 +0000 (UTC) (envelope-from kp@krion.cc) Date: Thu, 9 Dec 2021 19:37:18 +0100 From: Kirill Ponomarev To: Mark Johnston Cc: FreeBSD User , freebsd-current Subject: Re: CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress Message-ID: References: <20211208160516.665649dd@freyja> 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="DhaQ1cTVJiOfG6/N" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J92p16YWYz3sc1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kp@krion.cc designates 148.251.235.209 as permitted sender) smtp.mailfrom=kp@krion.cc X-Spamd-Result: default: False [-3.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[kp]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[krion.cc]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.87)[0.872]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:148.251.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --DhaQ1cTVJiOfG6/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/08, Mark Johnston wrote: > On Wed, Dec 08, 2021 at 04:05:16PM +0100, FreeBSD User wrote: > > Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD 14.0-= CURRENT > > #7 main-n251463-935dc0de881: Wed Dec 8 06:49:25 CET 2021 amd64) fails = with the > > linker error shown below. > >=20 > > Due to this error, no FreeBSD pkg base nor NanoBSD Image can be build. > >=20 > >=20 > > [...] > > cc -O2 -pipe -O3 -fno-common > > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelftc > > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common -DN= DEBUG > > -std=3Dgnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format= -y2k -W > > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith > > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-pa= rameter > > -Wcast-align -Wchar-subscripts -Wnested-externs -Wredundant-decls > > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations > > -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-= variable > > -Wno-error=3Dunused-but-set-variable -Qunused-arguments > > -I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd= 64.amd64/tmp/legacy/usr/include > > -static > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd= 64.amd64/tmp/legacy/usr/lib > > -o nm nm.o > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd= 64.amd64/tmp/obj-tools/lib/libdwarf > > -ldwarf > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd= 64.amd64/tmp/obj-tools/lib/libelf > > -lelf > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd= 64.amd64/tmp/obj-tools/lib/libelftc > > -lelftc_pie > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd= 64.amd64/tmp/obj-tools/lib/libelf > > -lelf -legacy ld: error: undefined symbol: uncompress > > >>> referenced by libdwarf_elf_init.c > > >>> libdwarf_elf_init.o:(_dwarf_elf_init) in archive > > >>> /usr/lib/libdwarf.a > > cc: error: linker command failed with exit code 1 (use -v to see invoca= tion) > > *** [nm] Error code 1 >=20 > Is this build using WITHOUT_CLEAN? If so I think you'll need to try a > clean build if you had previous built world between dbf05458e3bd and > 8d5d329553b3. I ran 'make clean' before buildworld and got the same issue. --DhaQ1cTVJiOfG6/N Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEJCHRFhEAQujKni1pDyI9/LMCykUFAmGyTN4ACgkQDyI9/LMC ykU2WAf/ROiCf7qdEIHtJOM7uuXXUan6zkWWHRpYJXEo47enu04vFrmh79rP8gWe ONTsXzXRC7NwZh6vGdbUlTIM2m2HdQ1CoDWBdwFnaIgiZZgqOsgoiY4NCCQnzq1J zRH7+uFZ4MEkaH25obixZUFsXKhLoGnLpBd5ME7VtkJgxSZVRZGOpSn2eI33xcFc MiWeqvwaFxydPEedM4TvTGVFfmg+fHgO2apphyBzsyJmoE/R0H3dwBCtoDyG1+Lk bY1S/COTu7yqxGcjLpAXYheu9mwy+LBRl6RV9YgSZwEa73tXWZn6ixMgkyrOyrr0 08oMOPQTq64XR3A2+tquyhx/SbnIzg== =O34B -----END PGP SIGNATURE----- --DhaQ1cTVJiOfG6/N-- From nobody Thu Dec 9 18:54:31 2021 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 0650F18C42D6 for ; Thu, 9 Dec 2021 18:52:13 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J937057Lyz4Rrr for ; Thu, 9 Dec 2021 18:52:12 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-yb1-xb36.google.com with SMTP id f186so15937741ybg.2 for ; Thu, 09 Dec 2021 10:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WMnX2AHGSLE/LI/MHy9hQDPbkiXdbfASMHejzM5Ss/g=; b=fdKQHXDHu3ZcGpfBZonOEEi1ywNu+kOQvAP0G6J0lc5gwHBwmthoH50ITye7p23wfc GI/aP1nzoDe8tsqSF4uR2ooF9Yg2Ls6/KFO7GDaafc2VrQTEGM1rIl3TlHZFHzl7B3t5 mqb3uEGWZyPDtjxXCvgKQsE5fr1ulfi8LcyGRTl8iqNZ0gXUUTBV1QSQnvA2SVp25r7/ RVoz91Wjg509QvQwZxwoDlT/+KusOilnYAfYu4WR2PeIT1oeoXE7HKlPVzYCnaUPSkzZ cejyTmh9VlMJW+tzRlgA8gs+5M7I7LGuBL6DEQ7aUtn7rszmEbZxFr5nHDOuiYiJ8nvK lzNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WMnX2AHGSLE/LI/MHy9hQDPbkiXdbfASMHejzM5Ss/g=; b=HLlfsPzWKWrdbTrKL/yk8/x08evybA+aTzEshqWOaid9TiSy7TQlZ9v6j+iAjgxsar TJNjehRFnWdCUx7u+IOQYAq2Ntlq/w1AvyZdvh9DtnpyNdtywxIeeBWRm0XDlKrE0V1J nbCXgl6yFV2vS90J7blyHzg3lNTSHFxyuHpOAfivKhCiE6SksgI86FgqTBCaXDEoY61h R/aUKqzgegKBKM+8jQIcSL/bPmEKadcwSFILg/cnIFaSsWqa5/yg3GkGPmKbXRfHog4/ uoQQgBrQ7Oa7yCoi5zTfBKrDCXqPfoo1Mm8oasEWFytdKgKPjFmlO1DDdUxi0hMRTqlF rojQ== X-Gm-Message-State: AOAM530SaEEBSklvKQyIBSfwBrwVG+J7D1XfWKAgI2ZsnALTLcbAVMhV mcyWiiKBfVmJ7JSB0JFw8mCro79oG/aWzL9uq7hcLuSOZE8= X-Google-Smtp-Source: ABdhPJxtCv5FjFcXvYyh/rPiaXU7uVNlAqih350lWWTqB3txeQkVQ8N52LpIGbLAeAtRd8CSH90F59Mu4iRag3T+akQ= X-Received: by 2002:a25:b18e:: with SMTP id h14mr8625866ybj.744.1639075925964; Thu, 09 Dec 2021 10:52:05 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211209163610.0cc4f7c6@gmail.com> <20211209235807.31ee2ecea5bc08e243870da3@dec.sakura.ne.jp> <13846D48-70DF-47FD-B2DA-187A33F0F5C0@me.com> In-Reply-To: <13846D48-70DF-47FD-B2DA-187A33F0F5C0@me.com> From: Sergey Dyatko Date: Thu, 9 Dec 2021 18:54:31 +0000 Message-ID: Subject: Re: 14-current: unable to boot after upgrade (installworld) To: Toomas Soome Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000053ba3805d2bb1ad8" X-Rspamd-Queue-Id: 4J937057Lyz4Rrr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000053ba3805d2bb1ad8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable tiger@dl:~ % gpart show | =3D> 40 3907029088 da4 GPT (1.8T) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 3907026944 2 freebsd-zfs (1.8T) 3907028992 136 - free - (68K) =3D> 40 3907029088 da5 GPT (1.8T) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 3907026944 2 freebsd-zfs (1.8T) 3907028992 136 - free - (68K) =3D> 40 3907029088 da6 GPT (1.8T) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 3907026944 2 freebsd-zfs (1.8T) 3907028992 136 - free - (68K) =3D> 40 3907029088 da7 GPT (1.8T) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 3907026944 2 freebsd-zfs (1.8T) 3907028992 136 - free - (68K) i'm not sure about video, everything happens faster than I can see :-) but sometimes the system does not freeze and I can enter commands. Can this help in some way? =D1=87=D1=82, 9 =D0=B4=D0=B5=D0=BA. 2021 =D0=B3. =D0=B2 18:19, Toomas Soome= : > > > > On 9. Dec 2021, at 20:06, Sergey Dyatko wrote= : > > > > I was sure the installer did it when I reinstalled the system from > scratch. I > > can load 14-current successfully after boot via PXE and installworld wi= th > > 13-current > > now I did the following: > > 1) boot from HDDs FreeBSD 14.0-CURRENT #0 main-n251494-f953785b3df (wit= h > > 'old' world) > > 2)run installworld (f953785b3df) > > 3) run `gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da${D}` > > command , where D=3D4..7 > > root@dl:/usr/src # zpool status > > pool: zroot > > state: ONLINE > > config: > > > > NAME STATE READ WRITE CKSUM > > zroot ONLINE 0 0 0 > > mirror-0 ONLINE 0 0 0 > > da4p2 ONLINE 0 0 0 > > da5p2 ONLINE 0 0 0 > > mirror-1 ONLINE 0 0 0 > > da6p2 ONLINE 0 0 0 > > da7p2 ONLINE 0 0 0 > > errors: No known data errors > > > > after `shutdown -r now` system still doesn't boot with the same error. > As > > far I can see, there is /boot/lua/config.lua present, but when I try to > run > > command more /boot/lua/config.lua system hangs with following error: > > https://imgur.com/5p0xu6W.png > > > > You seem to get 2x BTX panic, could you try to create video from console, > so we could get register dumps? > > can this system do UEFI boot and if so, can you test it? Could you post > partition tables? > > rgds, > toomas > > > > > > =D1=87=D1=82, 9 =D0=B4=D0=B5=D0=BA. 2021 =D0=B3. =D0=B2 15:56, Warner L= osh : > > > >> On Thu, Dec 9, 2021 at 7:58 AM Tomoaki AOKI > >> wrote: > >> > >>> On Thu, 9 Dec 2021 13:36:10 +0000 > >>> "Sergey V. Dyatko" wrote: > >>> > >>>> Hi, > >>>> > >>>> Yesterday I tried to upgrade old 13-current (svn rev r368473) to fre= sh > >>>> 14-current from git,it looked like this: > >>>> 1) git pull https://git.freebsd.org/src.git /usr/src > >>>> 2) cd /usr/src ; make buildworld; make kernel > >>>> 3) shutdown -r now > >>>> after that I _successfully_ booted into 14-current and continued wit= h > >>>> etcupdate -p > >>>> make installworld > >>>> etcupdate -B > >>>> shutdown -r now > >>>> > >>>> but after that server doesn't come back. After I conneted to this > >> server > >>> via > >>>> IPMI ip-kvm I saw following (sorry for external link): > >>>> https://i.imgur.com/jH6MHd2.png > >>>> > >>>> Well. There was a migration to zol between r368473 and current 'main= ' > >>> branch so > >>>> I decided to install fresh 14-current from snapshot > >>>> FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to > >> avoid > >>>> possible problems > >>>> > >>>> and again, after make kernel and reboot OS runs, but after > installworld > >>> I ended up in the same situation > >>>> > >>>> thoughts ? > >>>> > >>>> -- > >>>> wbr, Sergey > >>>> > >>>> > >>> > >>> Bootcode should be updated. > >>> The procedure you wrote doesn't seem to update it. > >>> > >> > >> The posted error is one you get when you can't read the filesystem, > which > >> is why you need to update > >> boot blocks across the OpenZFS change. > >> > >> Warner > >> > > --00000000000053ba3805d2bb1ad8-- From nobody Thu Dec 9 19:07:34 2021 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 4369418CC9EE for ; Thu, 9 Dec 2021 19:07:54 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J93T34nn0z4YcL; Thu, 9 Dec 2021 19:07:51 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 13CDB1067547; Thu, 9 Dec 2021 20:07:43 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 0CC2F10A330C; Thu, 9 Dec 2021 20:07:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1639076861; 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=SIOeSNol1jG3SmD8fW07B7VYx7wp5t/fxGPYFhVzZz8=; b=hwoi8Kwsnt+untFP5SgUZ0wdxsJDz+tCT2P1IZ6l8MNXTCmf78yNvwY8OatQH/fiODVPGN TpO+/j3qXOzYEohA5oFCFoed1qOhgjVtvELnY5c8z0uRnA/XqFBS1RnuE083fGAhdpZFhJ C8z6Rt0K810Y/KpPxUn8d5RdmzM04Z6j6VHEWTVcstV8oFfBW+gBZAfEjf2ciNiKrH2UJ0 xfTSBxt04cLuv3q6HKffn4PR1tTgrmjqdZ2TvkxF6jKgKSNefxNdYgsXkL+NchOQm5Okf8 cGTH3RH0ZH7cBad0TO0CeonneXevm/ENnyMoGwSOIQ8Bi95LPscjOUfas9RH2A== Received: from jelly.fritz.box (dynamic-2a01-0c23-64ce-4500-959c-6371-b8f8-b43c.c23.pool.telefonica.de [IPv6:2a01:c23:64ce:4500:959c:6371:b8f8:b43c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id CA81810A330B; Thu, 9 Dec 2021 20:07:40 +0100 (CET) Date: Thu, 9 Dec 2021 20:07:34 +0100 From: FreeBSD User To: Mark Johnston Cc: freebsd-current Subject: Re: CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress Message-ID: <20211209200734.76c0a1b1@jelly.fritz.box> In-Reply-To: References: <20211208160516.665649dd@freyja> Organization: FreeBSD in der Heimstatt List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: a1ab38 X-Rspamd-UID: 75a491 X-Rspamd-Queue-Id: 4J93T34nn0z4YcL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=hwoi8Kws; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:30) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-3.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from] X-ThisMailContainsUnwantedMimeParts: N Am Wed, 8 Dec 2021 10:43:41 -0500 schrieb Mark Johnston : > On Wed, Dec 08, 2021 at 04:05:16PM +0100, FreeBSD User wrote: > > Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD > > 14.0-CURRENT #7 main-n251463-935dc0de881: Wed Dec 8 06:49:25 CET > > 2021 amd64) fails with the linker error shown below. > > > > Due to this error, no FreeBSD pkg base nor NanoBSD Image can be > > build. > > > > > > [...] > > cc -O2 -pipe -O3 -fno-common > > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelftc > > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common > > -DNDEBUG -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall > > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > > -Wchar-subscripts -Wnested-externs -Wredundant-decls > > -Wold-style-definition -Wno-pointer-sign > > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > > -Wno-string-plus-int -Wno-unused-const-variable > > -Wno-error=unused-but-set-variable -Qunused-arguments > > -I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/include > > -static > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib > > -o nm nm.o > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf > > -ldwarf > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf > > -lelf > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc > > -lelftc_pie > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf > > -lelf -legacy ld: error: undefined symbol: uncompress > > >>> referenced by libdwarf_elf_init.c > > >>> libdwarf_elf_init.o:(_dwarf_elf_init) in archive > > >>> /usr/lib/libdwarf.a > > cc: error: linker command failed with exit code 1 (use -v to see > > invocation) *** [nm] Error code 1 > > Is this build using WITHOUT_CLEAN? If so I think you'll need to try a > clean build if you had previous built world between dbf05458e3bd and > 8d5d329553b3. > Hello. Thanks for responding. The issue occured in poudriere and indeed, I set WITHOUT_CLEAN. After deleting the obj folder poudriere and the 14-CURRENT environment compiled the 13-STABLE source as expected. Thanks. oh From nobody Thu Dec 9 19:09:42 2021 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 E100118CD341 for ; Thu, 9 Dec 2021 19:09:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J93WG4F6Hz4Zvq for ; Thu, 9 Dec 2021 19:09:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd2e.google.com with SMTP id e128so7850235iof.1 for ; Thu, 09 Dec 2021 11:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Wsb5GeRCdN/oWFkRkQeqUU03KXBFFXMIs4BlqW2WA/0=; b=RIQ1luZ7vq2cxX0O7lbFg38XGJl/qcFuYzHTIkJ3pkg/nyGl1fqn88uBTKcNtAp2fw qNoSmw7CIMPBp2mQvhE6GjBgZAVMLFwDJ2iXdjldwA5LdgneezDTaqshW1ho4tVLevq2 8Ub7/yqkG2buDCqInD1EzGwawsU8rGBkcC6Yq7d27ZnFjbLNa+MuLw7D/iynaRwAxVb7 GVjNufTySOQmdQNaBIqyKTOopyAY9QOJGwXeRqQUcBMmAU0g+8lx7VEgmCodmjRAVJ7V 7ra70wbaNYvBAbtfXuVCJ2DcK+V7dUgWxQ4y2K4l739Ym8/+3FFTrwxgQ0Frq08MX7JF JWLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=Wsb5GeRCdN/oWFkRkQeqUU03KXBFFXMIs4BlqW2WA/0=; b=1qaMXnGksHZn4PnShmKLq2RnK0Qsk5++jSyNZXzbetcAf8X4X4IVD/QjT1sK2eO+rf 6KH3O8ULt2cpz/mvddfW8KX0SYIIL5ZUpvJXjBmb7Fp9n6AstPr6b7ExI+Kp7U2NJibk asdFA4VBTioDcwTROiJJ3GxEQaz/37lnPy+Dw9zPdu2JMYYMbVtod6WY3HCbdkHe0aLg PqWgDwdnx1uXebTlH4fIDcQltDnZVKW9mztynLN1d+m9Dr3zTvvRHDGqZPIHqeJUXyzh SHrcNdgnvJHeJ3xfDK3QXMXSwOD+d1knwWXnD2KrcNaU1nWbGlVbSlFMkiOer1qvFswU 0V9Q== X-Gm-Message-State: AOAM533HYmm7EYgsj75hcdYhZ+rx0CKrRC7VkkO4rUcvqjAuG77PT3Bu SFWPBAvsGdAT0OdzQG9gEBEW/MWVR9y1Xg== X-Google-Smtp-Source: ABdhPJyvepKnzL7iG5PcJC12gZNic4Cih9ij7Z2QUISnU3pOWfV9ufOZWvS2KzfZkqh3b7i82RNrbw== X-Received: by 2002:a6b:d904:: with SMTP id r4mr16457434ioc.52.1639076985272; Thu, 09 Dec 2021 11:09:45 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id y21sm317757ioj.41.2021.12.09.11.09.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 11:09:44 -0800 (PST) Date: Thu, 9 Dec 2021 14:09:42 -0500 From: Mark Johnston To: Kirill Ponomarev Cc: FreeBSD User , freebsd-current Subject: Re: CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress Message-ID: References: <20211208160516.665649dd@freyja> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J93WG4F6Hz4Zvq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Dec 09, 2021 at 07:37:18PM +0100, Kirill Ponomarev wrote: > On 12/08, Mark Johnston wrote: > > On Wed, Dec 08, 2021 at 04:05:16PM +0100, FreeBSD User wrote: > > > Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD 14.0-CURRENT > > > #7 main-n251463-935dc0de881: Wed Dec 8 06:49:25 CET 2021 amd64) fails with the > > > linker error shown below. > > > > > > Due to this error, no FreeBSD pkg base nor NanoBSD Image can be build. > > > > > > > > > [...] > > > cc -O2 -pipe -O3 -fno-common > > > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelftc > > > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common -DNDEBUG > > > -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W > > > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > > > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > > > -Wcast-align -Wchar-subscripts -Wnested-externs -Wredundant-decls > > > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations > > > -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > > > -Wno-error=unused-but-set-variable -Qunused-arguments > > > -I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/include > > > -static > > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib > > > -o nm nm.o > > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf > > > -ldwarf > > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf > > > -lelf > > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc > > > -lelftc_pie > > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf > > > -lelf -legacy ld: error: undefined symbol: uncompress > > > >>> referenced by libdwarf_elf_init.c > > > >>> libdwarf_elf_init.o:(_dwarf_elf_init) in archive > > > >>> /usr/lib/libdwarf.a > > > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > > *** [nm] Error code 1 > > > > Is this build using WITHOUT_CLEAN? If so I think you'll need to try a > > clean build if you had previous built world between dbf05458e3bd and > > 8d5d329553b3. > > I ran 'make clean' before buildworld and got the same issue. make clean, or make cleanworld? I think the latter is needed. And is your buildworld done with WITHOUT_CLEAN set? From nobody Thu Dec 9 19:49:41 2021 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 401DE18D5483 for ; Thu, 9 Dec 2021 19:49:46 +0000 (UTC) (envelope-from kp@krion.cc) Received: from krion.cc (krion.cc [148.251.235.209]) (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 4J94PQ0qVpz4my2; Thu, 9 Dec 2021 19:49:46 +0000 (UTC) (envelope-from kp@krion.cc) Date: Thu, 9 Dec 2021 20:49:41 +0100 From: Kirill Ponomarev To: Mark Johnston Cc: FreeBSD User , freebsd-current Subject: Re: CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress Message-ID: References: <20211208160516.665649dd@freyja> 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="XkjSvkAzSyfJg8+T" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J94PQ0qVpz4my2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --XkjSvkAzSyfJg8+T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/09, Mark Johnston wrote: > On Thu, Dec 09, 2021 at 07:37:18PM +0100, Kirill Ponomarev wrote: > > On 12/08, Mark Johnston wrote: > > > On Wed, Dec 08, 2021 at 04:05:16PM +0100, FreeBSD User wrote: > > > > Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD 1= 4.0-CURRENT > > > > #7 main-n251463-935dc0de881: Wed Dec 8 06:49:25 CET 2021 amd64) fa= ils with the > > > > linker error shown below. > > > >=20 > > > > Due to this error, no FreeBSD pkg base nor NanoBSD Image can be bui= ld. > > > >=20 > > > >=20 > > > > [...] > > > > cc -O2 -pipe -O3 -fno-common > > > > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelf= tc > > > > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common= -DNDEBUG > > > > -std=3Dgnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-fo= rmat-y2k -W > > > > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpo= inter-arith > > > > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunuse= d-parameter > > > > -Wcast-align -Wchar-subscripts -Wnested-externs -Wredundant-decls > > > > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declara= tions > > > > -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-co= nst-variable > > > > -Wno-error=3Dunused-but-set-variable -Qunused-arguments > > > > -I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src= /amd64.amd64/tmp/legacy/usr/include > > > > -static > > > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src= /amd64.amd64/tmp/legacy/usr/lib > > > > -o nm nm.o > > > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src= /amd64.amd64/tmp/obj-tools/lib/libdwarf > > > > -ldwarf > > > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src= /amd64.amd64/tmp/obj-tools/lib/libelf > > > > -lelf > > > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src= /amd64.amd64/tmp/obj-tools/lib/libelftc > > > > -lelftc_pie > > > > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src= /amd64.amd64/tmp/obj-tools/lib/libelf > > > > -lelf -legacy ld: error: undefined symbol: uncompress > > > > >>> referenced by libdwarf_elf_init.c > > > > >>> libdwarf_elf_init.o:(_dwarf_elf_init) in archive > > > > >>> /usr/lib/libdwarf.a > > > > cc: error: linker command failed with exit code 1 (use -v to see in= vocation) > > > > *** [nm] Error code 1 > > >=20 > > > Is this build using WITHOUT_CLEAN? If so I think you'll need to try a > > > clean build if you had previous built world between dbf05458e3bd and > > > 8d5d329553b3. > >=20 > > I ran 'make clean' before buildworld and got the same issue. >=20 > make clean, or make cleanworld? I think the latter is needed. And is > your buildworld done with WITHOUT_CLEAN set? I'm running it in /usr/src not in poudriere, so I ran with and without NO_CLEAN and ran "make cleanworld" as well, it's still failing. --XkjSvkAzSyfJg8+T Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEJCHRFhEAQujKni1pDyI9/LMCykUFAmGyXdUACgkQDyI9/LMC ykUGiAgAoYhoYbgrzvWyS/jmvkiBL7CXOXUEO0yw2pGgrwHDsAgjZk8L9maTb4vb zxJv6yTBfA5DwN1uxLJPJvP9nQ9cqzwRBfZbjVFx1LtSvSjxPG//Y/lA3lfqxbjS sT1rEPBg65z6xOoj7kwQ0/TORhwc3unqoDuzKIII9zAlOH5uZ0ZSUvt8x0mML8pB utALxXvyU3GcMpGZL3cXndwuduaOGm9eTEamP7Ts+oH5scmVe1fyBdeOObawGm26 2HcyCmol34Qh8yAa9KfuUDxX+bHWiG26/xDpEwgNoJ02BE4+3vkHfq28Q6Dh3EH7 DfBlTO/ldRxb/dFDUcOYEtIlNso5tQ== =hxP1 -----END PGP SIGNATURE----- --XkjSvkAzSyfJg8+T-- From nobody Fri Dec 10 08:29:38 2021 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 40E7718E37E8; Fri, 10 Dec 2021 08:29:57 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9PGX3b2zz4XdR; Fri, 10 Dec 2021 08:29:56 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lj1-x22f.google.com with SMTP id i63so12680912lji.3; Fri, 10 Dec 2021 00:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:cc:subject:message-id:mime-version; bh=ELm2y6dbPZGlarzo9PgVfq5ub4AS3vQ4PdnjPoV7hjk=; b=KiUMwissu+BAl0VtHc+FEvD3Exi32DA3UdcLtoUFbKoHRXelwjEpaIMDd8L/kzPwWC +GodOJfXsdMME6usdNypUq3+Mz8/kcwzHcE+BGp1Xj+LIdFrwLw++PNpBsbUxxJwsVJO n3jTvCZGMMRIO2uFe3AU+MrFO31iMOx9/uwr53NR+YYJVcFZ98qjGCiTLjSweelG4pTS t2IllvcQDfjA4sey+YM5tU8lgF1/aRipAu5p2VilevkJvKCC2Xfcqnld6i9gDf/CDny5 drG7Jx3GPW4dse7xijYUb35BKvfYYl1X1+jcuxAhrbjyKnYkMtpT/asD46YYz30wzvC+ N9zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:message-id:mime-version; bh=ELm2y6dbPZGlarzo9PgVfq5ub4AS3vQ4PdnjPoV7hjk=; b=V+A2P/ReHSsvJhALSXoLuS5FMCjh4N55V3pI0Z+6CtHr3cCTGYNHJkBUPcJn3qprlI SP7AfXy+aBYb9+7IjVs1xgrdQxvxcF3G4F3Lhhu+O4GlptQ9Iwlrk9L+vvTkBwW2qiSc WuMtNaQYnlv03GtViC3pxbAEnOSKJrqmyin1Hj1Qvh0yfIuA3cr6gJO89wmsjDmZj4E/ Jy5gln6q18HTG8N7ld/+uRvAmB4dg+Ql8hxRYEcOLS9OT0g00ZRTm/+AP1l+JigmLNr2 JCpNWvltrVIKNz9aCGPBsrlOO8H7mvLk5hJohbruEhCohCXC7anVo6wPFNAnjVqTHiO3 3JPg== X-Gm-Message-State: AOAM532I1rG+9Ng241isHorSnoFQ6HMCh2Mf6oH00X+3Xd/gWKJ920Wy BhdS0xY1/6pKW+e2eX8WdKxSeYQnptc= X-Google-Smtp-Source: ABdhPJyWs/V/OtZLNL1OaQlOoJLOheZz4pYEO8Dvk/eJWjjWRWpz8TMlyDLmFvL19UHe2nNJr2xAzg== X-Received: by 2002:a2e:1644:: with SMTP id 4mr10940548ljw.312.1639124995277; Fri, 10 Dec 2021 00:29:55 -0800 (PST) Received: from rimwks.local ([176.99.182.246]) by smtp.gmail.com with ESMTPSA id m29sm240049lfj.187.2021.12.10.00.29.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Dec 2021 00:29:54 -0800 (PST) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Fri, 10 Dec 2021 11:29:38 +0300 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Cc: Rozhuk Ivan Subject: Too many warnings for world and kernel for 13 stable Message-ID: <20211210112938.21747d4d@rimwks.local> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/wQ+F2DVnjFSjsXA5CnSTh.G" X-Rspamd-Queue-Id: 4J9PGX3b2zz4XdR X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=KiUMwiss; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::22f as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-0.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[176.99.182.246:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.95)[0.950]; NEURAL_HAM_LONG(-0.97)[-0.968]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22f:from]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --MP_/wQ+F2DVnjFSjsXA5CnSTh.G Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi! There was a lot warning during build wold and kernel in past with clang 13, but with clang 14 to many warnings. Probably commiters will find some time to fix it? I spent some time to fix/supress warnings for world, exept contrib and stand parts. This patch is not to merge, it is to show that something goes wrong. --MP_/wQ+F2DVnjFSjsXA5CnSTh.G Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=616ca2b8b6.patch >From 616ca2b8b63b225be0305d34f36dd3d0050a6a4f Mon Sep 17 00:00:00 2001 From: Rozhuk Ivan Date: Fri, 10 Sep 2021 18:50:20 +0300 Subject: [PATCH] Fix build warnings --- lib/geom/eli/geom_eli.c | 4 +- lib/libc/stdlib/rand.c | 4 +- lib/libfetch/http.c | 7 +--- lib/libkvm/kvm_minidump_powerpc64_hpt.c | 3 -- lib/libmd/rmd160c.c | 1 + lib/libmd/sha1c.c | 2 + lib/libpfctl/libpfctl.c | 16 +++---- lib/libpjdlog/pjdlog.c | 5 ++- lib/libprocstat/libprocstat.c | 1 + lib/libvgl/mouse.c | 5 +-- lib/libvmmapi/vmmapi.c | 3 +- lib/ncurses/ncurses/termcap.c | 2 - sbin/bsdlabel/bsdlabel.c | 8 +--- sbin/camcontrol/zone.c | 7 +--- sbin/ggate/ggated/ggated.c | 42 +++++++------------ sbin/growfs/growfs.c | 5 +-- sbin/ipfw/ipfw2.c | 5 +-- sbin/ipfw/nat.c | 3 +- sbin/ipfw/nat64clat.c | 3 +- sbin/ipfw/nat64lsn.c | 3 +- sbin/ipfw/nat64stl.c | 3 +- sbin/ipfw/nptv6.c | 3 +- sbin/ipfw/tables.c | 6 +-- sbin/nvmecontrol/modules/wdc/wdc.c | 3 +- sbin/pfctl/pfctl_optimize.c | 3 -- sbin/recoverdisk/recoverdisk.c | 14 +------ sys/amd64/vmm/vmm_instruction_emul.c | 18 ++------ sys/netinet/libalias/alias.c | 11 +++-- usr.bin/backlight/backlight.c | 3 -- usr.bin/ipcs/ipc.c | 3 +- usr.bin/mkuzip/mkuzip.c | 8 ++-- usr.bin/mt/mt.c | 5 +-- usr.bin/procstat/procstat.c | 3 +- usr.bin/truss/syscalls.c | 7 +--- usr.bin/unifdef/unifdef.c | 5 +-- usr.bin/units/units.c | 5 --- usr.bin/vmstat/vmstat.c | 4 +- usr.bin/vtfontcvt/vtfontcvt.c | 8 ---- usr.sbin/acpi/acpidump/acpi.c | 5 --- usr.sbin/bhyve/atkbdc.c | 12 ++---- usr.sbin/bhyve/bhyverun.c | 12 ++---- usr.sbin/bhyve/gdb.c | 14 ++----- usr.sbin/bhyve/hda_codec.c | 22 +++------- usr.sbin/bhyve/mem.c | 26 ++++-------- usr.sbin/bhyve/mevent.c | 4 +- usr.sbin/bhyve/pci_ahci.c | 20 ++++----- usr.sbin/bhyve/pci_e82545.c | 8 +--- usr.sbin/bhyve/pci_emul.c | 26 ++++-------- usr.sbin/bhyve/pci_hda.c | 31 ++++---------- usr.sbin/bhyve/pci_virtio_block.c | 10 ++--- usr.sbin/bhyve/pci_virtio_console.c | 8 +--- usr.sbin/bhyve/pci_virtio_net.c | 7 +--- usr.sbin/bhyve/pci_virtio_rnd.c | 5 +-- usr.sbin/bhyve/pci_virtio_scsi.c | 4 +- usr.sbin/bhyve/pm.c | 10 +---- usr.sbin/bhyve/rtc.c | 21 ++++------ usr.sbin/bhyve/spinup_ap.c | 22 ++++------ usr.sbin/bhyve/task_switch.c | 22 +++------- usr.sbin/bhyve/uart_emul.c | 13 ++---- usr.sbin/bhyve/vga.c | 8 ++-- usr.sbin/bsdinstall/partedit/scripted.c | 7 ++-- usr.sbin/camdd/camdd.c | 19 +-------- usr.sbin/efibootmgr/efibootmgr.c | 3 +- usr.sbin/efidp/efidp.c | 3 +- .../fifolog/fifolog_reader/fifolog_reader.c | 4 +- usr.sbin/fifolog/lib/fifolog_int.c | 2 +- usr.sbin/fifolog/lib/fifolog_reader.c | 4 +- usr.sbin/fifolog/lib/fifolog_write_poll.c | 2 +- usr.sbin/fifolog/lib/getdate.y | 13 +----- usr.sbin/fwcontrol/fwdv.c | 4 +- usr.sbin/makefs/msdos.c | 2 - usr.sbin/makefs/msdos/msdosfs_vfsops.c | 2 - usr.sbin/mpsutil/mps_debug.c | 2 - usr.sbin/mptable/mptable.c | 3 -- usr.sbin/pmc/cmd_pmc_filter.cc | 3 +- usr.sbin/pw/pw_user.c | 4 +- usr.sbin/rpc.lockd/kern.c | 5 --- usr.sbin/rpc.tlsservd/rpc.tlsservd.c | 3 +- usr.sbin/rrenumd/parser.y | 2 - 79 files changed, 179 insertions(+), 459 deletions(-) diff --git a/lib/geom/eli/geom_eli.c b/lib/geom/eli/geom_eli.c index 4c04a9256b5..5d3cf504e17 100644 --- a/lib/geom/eli/geom_eli.c +++ b/lib/geom/eli/geom_eli.c @@ -1285,7 +1285,6 @@ eli_setkey_attached(struct gctl_req *req, struct g_eli_metadata *md) { unsigned char key[G_ELI_USERKEYLEN]; intmax_t val, old = 0; - int error; val = gctl_get_intmax(req, "iterations"); /* Check if iterations number should be changed. */ @@ -1304,9 +1303,8 @@ eli_setkey_attached(struct gctl_req *req, struct g_eli_metadata *md) * command-line argument, update the request. */ if (val == -1 && md->md_iterations != old) { - error = gctl_change_param(req, "iterations", sizeof(intmax_t), + gctl_change_param(req, "iterations", sizeof(intmax_t), &md->md_iterations); - assert(error == 0); } gctl_ro_param(req, "key", sizeof(key), key); diff --git a/lib/libc/stdlib/rand.c b/lib/libc/stdlib/rand.c index e448d1b1fd1..45ae924dd7a 100644 --- a/lib/libc/stdlib/rand.c +++ b/lib/libc/stdlib/rand.c @@ -71,11 +71,9 @@ static pthread_once_t rand3_state_once = PTHREAD_ONCE_INIT; static void initialize_rand3(void) { - int error; rand3_state = allocatestate(TYPE_3); - error = initstate_r(rand3_state, 1, rand3_state->rst_randtbl, BREAK_3); - assert(error == 0); + initstate_r(rand3_state, 1, rand3_state->rst_randtbl, BREAK_3); } int diff --git a/lib/libfetch/http.c b/lib/libfetch/http.c index bcb089dc0fc..c1d92d08b31 100644 --- a/lib/libfetch/http.c +++ b/lib/libfetch/http.c @@ -976,13 +976,12 @@ http_base64(const char *src) "0123456789+/"; char *str, *dst; size_t l; - int t, r; + int t; l = strlen(src); if ((str = malloc(((l + 2) / 3) * 4 + 1)) == NULL) return (NULL); dst = str; - r = 0; while (l >= 3) { t = (src[0] << 16) | (src[1] << 8) | src[2]; @@ -991,7 +990,7 @@ http_base64(const char *src) dst[2] = base64[(t >> 6) & 0x3f]; dst[3] = base64[(t >> 0) & 0x3f]; src += 3; l -= 3; - dst += 4; r += 4; + dst += 4; } switch (l) { @@ -1002,7 +1001,6 @@ http_base64(const char *src) dst[2] = base64[(t >> 6) & 0x3f]; dst[3] = '='; dst += 4; - r += 4; break; case 1: t = src[0] << 16; @@ -1010,7 +1008,6 @@ http_base64(const char *src) dst[1] = base64[(t >> 12) & 0x3f]; dst[2] = dst[3] = '='; dst += 4; - r += 4; break; case 0: break; diff --git a/lib/libkvm/kvm_minidump_powerpc64_hpt.c b/lib/libkvm/kvm_minidump_powerpc64_hpt.c index baa2fd1ebc0..d13f8021a73 100644 --- a/lib/libkvm/kvm_minidump_powerpc64_hpt.c +++ b/lib/libkvm/kvm_minidump_powerpc64_hpt.c @@ -253,9 +253,6 @@ static int ppc64mmu_hpt_init(kvm_t *kd) { struct hpt_data *data; - struct minidumphdr *hdr; - - hdr = &kd->vmst->hdr; /* Alloc MMU data */ data = _kvm_malloc(kd, sizeof(*data)); diff --git a/lib/libmd/rmd160c.c b/lib/libmd/rmd160c.c index a8a4ced70b0..95f56dc6b9a 100644 --- a/lib/libmd/rmd160c.c +++ b/lib/libmd/rmd160c.c @@ -83,6 +83,7 @@ char *RMD160_version="RIPEMD160 part of SSLeay 0.9.0b 11-Oct-1998"; #ifdef RMD160_ASM void ripemd160_block_x86(RIPEMD160_CTX *c, const u_int32_t *p,int num); +#undef ripemd160_block #define ripemd160_block ripemd160_block_x86 #else void ripemd160_block(RIPEMD160_CTX *c, const u_int32_t *p,int num); diff --git a/lib/libmd/sha1c.c b/lib/libmd/sha1c.c index d0bcc35f93d..05223204518 100644 --- a/lib/libmd/sha1c.c +++ b/lib/libmd/sha1c.c @@ -101,6 +101,7 @@ char *SHA1_version="SHA1 part of SSLeay 0.9.0b 11-Oct-1998"; #ifndef NOPROTO # ifdef SHA1_ASM void sha1_block_x86(SHA_CTX *c, const u_int32_t *p, int num); +# undef sha1_block # define sha1_block sha1_block_x86 # else void sha1_block(SHA_CTX *c, const u_int32_t *p, int num); @@ -108,6 +109,7 @@ char *SHA1_version="SHA1 part of SSLeay 0.9.0b 11-Oct-1998"; #else # ifdef SHA1_ASM void sha1_block_x86(); +# undef sha1_block # define sha1_block sha1_block_x86 # else void sha1_block(); diff --git a/lib/libpfctl/libpfctl.c b/lib/libpfctl/libpfctl.c index 9252f64969b..09c4aba9c94 100644 --- a/lib/libpfctl/libpfctl.c +++ b/lib/libpfctl/libpfctl.c @@ -60,8 +60,8 @@ static int _pfctl_clear_states(int , const struct pfctl_kill *, unsigned int *, uint64_t); static void -pf_nvuint_8_array(const nvlist_t *nvl, const char *name, size_t maxelems, - uint8_t *numbers, size_t *nelems) +pf_nvuint_8_array(const nvlist_t *nvl, const char *name, + size_t maxelems __unused, uint8_t *numbers, size_t *nelems) { const uint64_t *tmp; size_t elems; @@ -77,8 +77,8 @@ pf_nvuint_8_array(const nvlist_t *nvl, const char *name, size_t maxelems, } static void -pf_nvuint_16_array(const nvlist_t *nvl, const char *name, size_t maxelems, - uint16_t *numbers, size_t *nelems) +pf_nvuint_16_array(const nvlist_t *nvl, const char *name, + size_t maxelems __unused, uint16_t *numbers, size_t *nelems) { const uint64_t *tmp; size_t elems; @@ -94,8 +94,8 @@ pf_nvuint_16_array(const nvlist_t *nvl, const char *name, size_t maxelems, } static void -pf_nvuint_32_array(const nvlist_t *nvl, const char *name, size_t maxelems, - uint32_t *numbers, size_t *nelems) +pf_nvuint_32_array(const nvlist_t *nvl, const char *name, + size_t maxelems __unused, uint32_t *numbers, size_t *nelems) { const uint64_t *tmp; size_t elems; @@ -111,8 +111,8 @@ pf_nvuint_32_array(const nvlist_t *nvl, const char *name, size_t maxelems, } static void -pf_nvuint_64_array(const nvlist_t *nvl, const char *name, size_t maxelems, - uint64_t *numbers, size_t *nelems) +pf_nvuint_64_array(const nvlist_t *nvl, const char *name, + size_t maxelems __unused, uint64_t *numbers, size_t *nelems) { const uint64_t *tmp; size_t elems; diff --git a/lib/libpjdlog/pjdlog.c b/lib/libpjdlog/pjdlog.c index eb7ddb2b7a8..46d31761f41 100644 --- a/lib/libpjdlog/pjdlog.c +++ b/lib/libpjdlog/pjdlog.c @@ -78,7 +78,7 @@ static char pjdlog_prefix[PJDLOG_PREFIX_STACK][PJDLOG_PREFIX_MAXSIZE]; static int pjdlog_printf_arginfo_humanized_number(const struct printf_info *pi __unused, - size_t n, int *argt) + size_t n __unused, int *argt) { assert(n >= 1); @@ -104,7 +104,7 @@ pjdlog_printf_render_humanized_number(struct __printf_io *io, static int pjdlog_printf_arginfo_sockaddr(const struct printf_info *pi __unused, - size_t n, int *argt) + size_t n __unused, int *argt) { assert(n >= 1); @@ -570,6 +570,7 @@ pjdlogv_common_single_line(const char *func, const char *file, int line, break; default: assert(!"Invalid mode."); + return; } *logp = '\0'; diff --git a/lib/libprocstat/libprocstat.c b/lib/libprocstat/libprocstat.c index 89896a81388..3c2e5222a4c 100644 --- a/lib/libprocstat/libprocstat.c +++ b/lib/libprocstat/libprocstat.c @@ -877,6 +877,7 @@ procstat_getfiles_sysctl(struct procstat *procstat, struct kinfo_proc *kp, break; default: assert(!"invalid type"); + return (NULL); } if (files == NULL && errno != EPERM) { warn("kinfo_getfile()"); diff --git a/lib/libvgl/mouse.c b/lib/libvgl/mouse.c index 010a1b7b9c5..fc7ba239938 100644 --- a/lib/libvgl/mouse.c +++ b/lib/libvgl/mouse.c @@ -284,22 +284,19 @@ VGLMouseInit(int mode) { struct mouse_info mouseinfo; VGLBitmap *ormask; - int andmask, border, error, i, interior; + int border, error, i, interior; switch (VGLModeInfo.vi_mem_model) { case V_INFO_MM_PACKED: case V_INFO_MM_PLANAR: - andmask = 0x0f; border = 0x0f; interior = 0x04; break; case V_INFO_MM_VGAX: - andmask = 0x3f; border = 0x3f; interior = 0x24; break; default: - andmask = 0xff; border = BORDER; interior = INTERIOR; break; diff --git a/lib/libvmmapi/vmmapi.c b/lib/libvmmapi/vmmapi.c index 0543c92f430..0d3444a24f9 100644 --- a/lib/libvmmapi/vmmapi.c +++ b/lib/libvmmapi/vmmapi.c @@ -391,7 +391,8 @@ setup_memory_segment(struct vmctx *ctx, vm_paddr_t gpa, size_t len, char *base) } int -vm_setup_memory(struct vmctx *ctx, size_t memsize, enum vm_mmap_style vms) +vm_setup_memory(struct vmctx *ctx, size_t memsize, + enum vm_mmap_style vms __unused) { size_t objsize, len; vm_paddr_t gpa; diff --git a/lib/ncurses/ncurses/termcap.c b/lib/ncurses/ncurses/termcap.c index 535301a1b47..9a609537d80 100644 --- a/lib/ncurses/ncurses/termcap.c +++ b/lib/ncurses/ncurses/termcap.c @@ -111,13 +111,11 @@ _nc_read_termcap_entry(const char *const name, TERMTYPE2 *const tp) int i; char pathbuf[PBUFSIZ]; /* holds raw path of filenames */ char *pathvec[PVECSIZ]; /* to point to names in pathbuf */ - char **pvec; /* holds usable tail of path vector */ char *termpath; _nc_termcap[0] = '\0'; /* in case */ dummy = NULL; fname = pathvec; - pvec = pathvec; p = pathbuf; cp = getenv("TERMCAP"); /* diff --git a/sbin/bsdlabel/bsdlabel.c b/sbin/bsdlabel/bsdlabel.c index 943f37207fc..efe7eebf23c 100644 --- a/sbin/bsdlabel/bsdlabel.c +++ b/sbin/bsdlabel/bsdlabel.c @@ -1094,7 +1094,7 @@ checklabel(struct disklabel *lp) struct partition *pp; int i, errors = 0; char part; - u_long base_offset, needed, total_size, total_percent, current_offset; + u_long base_offset, needed, total_percent, current_offset; long free_space; int seen_default_offset; int hog_part; @@ -1173,7 +1173,6 @@ checklabel(struct disklabel *lp) /* first allocate space to the partitions, then offsets */ - total_size = 0; /* in sectors */ total_percent = 0; /* in percent */ hog_part = -1; /* find all fixed partitions */ @@ -1234,9 +1233,6 @@ checklabel(struct disklabel *lp) size /= lp->d_secsize; pp->p_size = size; } - /* else already in sectors */ - if (i != RAW_PART) - total_size += size; } } } @@ -1272,7 +1268,6 @@ checklabel(struct disklabel *lp) if (part_set[i] && part_size_type[i] == '%') { /* careful of overflows! and integer roundoff */ pp->p_size = ((double)pp->p_size/100) * free_space; - total_size += pp->p_size; /* FIX we can lose a sector or so due to roundoff per partition. A more complex algorithm could avoid that */ @@ -1328,7 +1323,6 @@ checklabel(struct disklabel *lp) } else { lp->d_partitions[hog_part].p_size = current_offset - base_offset - needed; - total_size += lp->d_partitions[hog_part].p_size; } } diff --git a/sbin/camcontrol/zone.c b/sbin/camcontrol/zone.c index 130f53226f5..e6ca6295450 100644 --- a/sbin/camcontrol/zone.c +++ b/sbin/camcontrol/zone.c @@ -138,7 +138,6 @@ zone_rz_print(uint8_t *data_ptr, uint32_t valid_len, int ata_format, struct scsi_report_zones_desc *desc = NULL; uint32_t hdr_len, len; uint64_t max_lba, next_lba = 0; - int more_data = 0; zone_print_status status = ZONE_PRINT_OK; char tmpstr[80]; int field_widths[ZONE_NUM_FIELDS]; @@ -168,7 +167,6 @@ zone_rz_print(uint8_t *data_ptr, uint32_t valid_len, int ata_format, } if (hdr_len > (valid_len + sizeof(*hdr))) { - more_data = 1; status = ZONE_PRINT_MORE_DATA; } @@ -560,7 +558,6 @@ restart_report: case CC_DT_ATA: case CC_DT_SATL: { uint8_t command = 0; - uint8_t protocol = 0; uint16_t features = 0, sector_count = 0; uint32_t auxiliary = 0; @@ -571,7 +568,6 @@ restart_report: */ if (use_ncq == 0) { - protocol = AP_PROTO_NON_DATA; command = ATA_ZAC_MANAGEMENT_OUT; features = action & 0xf; if (all_zones != 0) @@ -581,7 +577,6 @@ restart_report: if (cdb_storage == NULL) err(1, "couldn't allocate memory"); - protocol = AP_PROTO_FPDMA; command = ATA_NCQ_NON_DATA; features = ATA_NCQ_ZAC_MGMT_OUT; auxiliary = action & 0xf; @@ -594,7 +589,7 @@ restart_report: /*retry_count*/ retry_count, /*flags*/ CAM_DIR_NONE | CAM_DEV_QFRZDIS, /*tag_action*/ task_attr, - /*protocol*/ AP_PROTO_NON_DATA, + /*protocol???? AP_PROTO_FPDMA*/ AP_PROTO_NON_DATA, /*ata_flags*/ AP_FLAG_BYT_BLOK_BYTES | AP_FLAG_TLEN_NO_DATA, /*features*/ features, diff --git a/sbin/ggate/ggated/ggated.c b/sbin/ggate/ggated/ggated.c index 226ba1ce72d..03aabd271da 100644 --- a/sbin/ggate/ggated/ggated.c +++ b/sbin/ggate/ggated/ggated.c @@ -639,7 +639,7 @@ recv_thread(void *arg) struct ggd_connection *conn; struct ggd_request *req; ssize_t data; - int error, fd; + int fd; conn = arg; g_gate_log(LOG_NOTICE, "%s: started [%s]!", __func__, conn->c_path); @@ -688,13 +688,10 @@ recv_thread(void *arg) /* * Put the request onto the incoming queue. */ - error = pthread_mutex_lock(&inqueue_mtx); - assert(error == 0); + pthread_mutex_lock(&inqueue_mtx); TAILQ_INSERT_TAIL(&inqueue, req, r_next); - error = pthread_cond_signal(&inqueue_cond); - assert(error == 0); - error = pthread_mutex_unlock(&inqueue_mtx); - assert(error == 0); + pthread_cond_signal(&inqueue_cond); + pthread_mutex_unlock(&inqueue_mtx); } } @@ -704,7 +701,7 @@ disk_thread(void *arg) struct ggd_connection *conn; struct ggd_request *req; ssize_t data; - int error, fd; + int fd; conn = arg; g_gate_log(LOG_NOTICE, "%s: started [%s]!", __func__, conn->c_path); @@ -713,15 +710,12 @@ disk_thread(void *arg) /* * Get a request from the incoming queue. */ - error = pthread_mutex_lock(&inqueue_mtx); - assert(error == 0); + pthread_mutex_lock(&inqueue_mtx); while ((req = TAILQ_FIRST(&inqueue)) == NULL) { - error = pthread_cond_wait(&inqueue_cond, &inqueue_mtx); - assert(error == 0); + pthread_cond_wait(&inqueue_cond, &inqueue_mtx); } TAILQ_REMOVE(&inqueue, req, r_next); - error = pthread_mutex_unlock(&inqueue_mtx); - assert(error == 0); + pthread_mutex_unlock(&inqueue_mtx); /* * Check the request. @@ -766,13 +760,10 @@ disk_thread(void *arg) /* * Put the request onto the outgoing queue. */ - error = pthread_mutex_lock(&outqueue_mtx); - assert(error == 0); + pthread_mutex_lock(&outqueue_mtx); TAILQ_INSERT_TAIL(&outqueue, req, r_next); - error = pthread_cond_signal(&outqueue_cond); - assert(error == 0); - error = pthread_mutex_unlock(&outqueue_mtx); - assert(error == 0); + pthread_cond_signal(&outqueue_cond); + pthread_mutex_unlock(&outqueue_mtx); } /* NOTREACHED */ @@ -785,7 +776,7 @@ send_thread(void *arg) struct ggd_connection *conn; struct ggd_request *req; ssize_t data; - int error, fd; + int fd; conn = arg; g_gate_log(LOG_NOTICE, "%s: started [%s]!", __func__, conn->c_path); @@ -794,16 +785,13 @@ send_thread(void *arg) /* * Get a request from the outgoing queue. */ - error = pthread_mutex_lock(&outqueue_mtx); - assert(error == 0); + pthread_mutex_lock(&outqueue_mtx); while ((req = TAILQ_FIRST(&outqueue)) == NULL) { - error = pthread_cond_wait(&outqueue_cond, + pthread_cond_wait(&outqueue_cond, &outqueue_mtx); - assert(error == 0); } TAILQ_REMOVE(&outqueue, req, r_next); - error = pthread_mutex_unlock(&outqueue_mtx); - assert(error == 0); + pthread_mutex_unlock(&outqueue_mtx); g_gate_log(LOG_DEBUG, "%s: offset=%" PRIu64 " length=%" PRIu32, __func__, req->r_offset, req->r_length); diff --git a/sbin/growfs/growfs.c b/sbin/growfs/growfs.c index 1f1bcf82c96..6a57924fb7b 100644 --- a/sbin/growfs/growfs.c +++ b/sbin/growfs/growfs.c @@ -560,7 +560,7 @@ static void updjcg(int cylno, time_t modtime, int fsi, int fso, unsigned int Nflag) { DBG_FUNC("updjcg") - ufs2_daddr_t cbase, dmax, dupper; + ufs2_daddr_t cbase, dmax; struct csum *cs; int i, k; int j = 0; @@ -607,9 +607,6 @@ updjcg(int cylno, time_t modtime, int fsi, int fso, unsigned int Nflag) dmax = cbase + sblock.fs_fpg; if (dmax > sblock.fs_size) dmax = sblock.fs_size; - dupper = cgdmin(&sblock, cylno) - cbase; - if (cylno == 0) /* XXX fscs may be relocated */ - dupper += howmany(sblock.fs_cssize, sblock.fs_fsize); /* * Set pointer to the cylinder summary for our cylinder group. diff --git a/sbin/ipfw/ipfw2.c b/sbin/ipfw/ipfw2.c index e210cbfd02e..35f7ef2e4c4 100644 --- a/sbin/ipfw/ipfw2.c +++ b/sbin/ipfw/ipfw2.c @@ -2650,7 +2650,6 @@ list_static_range(struct cmdline_opts *co, struct format_opts *fo, int n, seen; struct ip_fw_rule *r; struct ip_fw_bcounter *cntr; - int c = 0; for (n = seen = 0; n < rcnt; n++, rtlv = (ipfw_obj_tlv *)((caddr_t)rtlv + rtlv->length)) { @@ -2669,7 +2668,6 @@ list_static_range(struct cmdline_opts *co, struct format_opts *fo, if (r->rulenum >= fo->first && r->rulenum <= fo->last) { show_static_rule(co, fo, bp, r, cntr); printf("%s", bp->buf); - c += rtlv->length; bp_flush(bp); seen++; } @@ -2788,13 +2786,12 @@ ipfw_show_config(struct cmdline_opts *co, struct format_opts *fo, char *endptr; size_t readsz; struct buf_pr bp; - ipfw_obj_ctlv *ctlv, *tstate; + ipfw_obj_ctlv *ctlv; ipfw_obj_tlv *rbase; /* * Handle tablenames TLV first, if any */ - tstate = NULL; rbase = NULL; dynbase = NULL; dynsz = 0; diff --git a/sbin/ipfw/nat.c b/sbin/ipfw/nat.c index 1076e1038b8..bb2a63e21e9 100644 --- a/sbin/ipfw/nat.c +++ b/sbin/ipfw/nat.c @@ -1074,7 +1074,6 @@ nat_foreach(nat_cb_t *f, void *arg, int sort) struct nat44_cfg_nat *cfg; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(struct nat44_cfg_nat); @@ -1097,7 +1096,7 @@ nat_foreach(nat_cb_t *f, void *arg, int sort) cfg = (struct nat44_cfg_nat*)(olh + 1); for (i = 0; i < olh->count; i++) { - error = f(cfg, arg); /* Ignore errors for now */ + f(cfg, arg); /* Ignore errors for now */ cfg = (struct nat44_cfg_nat *)((caddr_t)cfg + olh->objsize); } diff --git a/sbin/ipfw/nat64clat.c b/sbin/ipfw/nat64clat.c index 962fe7064f8..25d0689ca5f 100644 --- a/sbin/ipfw/nat64clat.c +++ b/sbin/ipfw/nat64clat.c @@ -505,7 +505,6 @@ nat64clat_foreach(nat64clat_cb_t *f, const char *name, uint8_t set, int sort) ipfw_nat64clat_cfg *cfg; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(*cfg); @@ -528,7 +527,7 @@ nat64clat_foreach(nat64clat_cb_t *f, const char *name, uint8_t set, int sort) cfg = (ipfw_nat64clat_cfg *)(olh + 1); for (i = 0; i < olh->count; i++) { - error = f(cfg, name, set); /* Ignore errors for now */ + f(cfg, name, set); /* Ignore errors for now */ cfg = (ipfw_nat64clat_cfg *)((caddr_t)cfg + olh->objsize); } diff --git a/sbin/ipfw/nat64lsn.c b/sbin/ipfw/nat64lsn.c index ff36181815d..b9b58042e94 100644 --- a/sbin/ipfw/nat64lsn.c +++ b/sbin/ipfw/nat64lsn.c @@ -853,7 +853,6 @@ nat64lsn_foreach(nat64lsn_cb_t *f, const char *name, uint8_t set, int sort) ipfw_nat64lsn_cfg *cfg; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(ipfw_nat64lsn_cfg); @@ -877,7 +876,7 @@ nat64lsn_foreach(nat64lsn_cb_t *f, const char *name, uint8_t set, int sort) cfg = (ipfw_nat64lsn_cfg *)(olh + 1); for (i = 0; i < olh->count; i++) { - error = f(cfg, name, set); /* Ignore errors for now */ + f(cfg, name, set); /* Ignore errors for now */ cfg = (ipfw_nat64lsn_cfg *)((caddr_t)cfg + olh->objsize); } diff --git a/sbin/ipfw/nat64stl.c b/sbin/ipfw/nat64stl.c index e82ec202b5c..ec1d11aaad4 100644 --- a/sbin/ipfw/nat64stl.c +++ b/sbin/ipfw/nat64stl.c @@ -521,7 +521,6 @@ nat64stl_foreach(nat64stl_cb_t *f, const char *name, uint8_t set, int sort) ipfw_nat64stl_cfg *cfg; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(*cfg); @@ -544,7 +543,7 @@ nat64stl_foreach(nat64stl_cb_t *f, const char *name, uint8_t set, int sort) cfg = (ipfw_nat64stl_cfg *)(olh + 1); for (i = 0; i < olh->count; i++) { - error = f(cfg, name, set); /* Ignore errors for now */ + f(cfg, name, set); /* Ignore errors for now */ cfg = (ipfw_nat64stl_cfg *)((caddr_t)cfg + olh->objsize); } diff --git a/sbin/ipfw/nptv6.c b/sbin/ipfw/nptv6.c index f2ebbdb6518..a158299eb37 100644 --- a/sbin/ipfw/nptv6.c +++ b/sbin/ipfw/nptv6.c @@ -420,7 +420,6 @@ nptv6_foreach(nptv6_cb_t *f, const char *name, uint8_t set, int sort) ipfw_nptv6_cfg *cfg; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(*cfg); @@ -442,7 +441,7 @@ nptv6_foreach(nptv6_cb_t *f, const char *name, uint8_t set, int sort) cfg = (ipfw_nptv6_cfg *)(olh + 1); for (i = 0; i < olh->count; i++) { - error = f(cfg, name, set); + f(cfg, name, set); cfg = (ipfw_nptv6_cfg *)((caddr_t)cfg + olh->objsize); } free(olh); diff --git a/sbin/ipfw/tables.c b/sbin/ipfw/tables.c index 81cf7e39258..c3c2173f48e 100644 --- a/sbin/ipfw/tables.c +++ b/sbin/ipfw/tables.c @@ -1386,7 +1386,6 @@ guess_key_type(char *key, uint8_t *ptype) { char *p; struct in6_addr addr; - uint32_t kv; if (ishexnumber(*key) != 0 || *key == ':') { /* Remove / if exists */ @@ -1402,7 +1401,7 @@ guess_key_type(char *key, uint8_t *ptype) } else { /* Port or any other key */ /* Skip non-base 10 entries like 'fa1' */ - kv = strtol(key, &p, 10); + strtol(key, &p, 10); if (*p == '\0') { *ptype = IPFW_TABLE_NUMBER; return (0); @@ -1685,7 +1684,6 @@ tables_foreach(table_cb_t *f, void *arg, int sort) ipfw_xtable_info *info; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(ipfw_xtable_info); @@ -1710,7 +1708,7 @@ tables_foreach(table_cb_t *f, void *arg, int sort) info = (ipfw_xtable_info *)(olh + 1); for (i = 0; i < olh->count; i++) { if (g_co.use_set == 0 || info->set == g_co.use_set - 1) - error = f(info, arg); + f(info, arg); info = (ipfw_xtable_info *)((caddr_t)info + olh->objsize); } diff --git a/sbin/nvmecontrol/modules/wdc/wdc.c b/sbin/nvmecontrol/modules/wdc/wdc.c index 050458a8812..cfef69d8b69 100644 --- a/sbin/nvmecontrol/modules/wdc/wdc.c +++ b/sbin/nvmecontrol/modules/wdc/wdc.c @@ -783,7 +783,6 @@ static void print_hgst_info_log(const struct nvme_controller_data *cdata __unused, void *buf, uint32_t size __unused) { uint8_t *walker, *end, *subpage; - int pages; uint16_t len; uint8_t subtype, res; @@ -791,7 +790,7 @@ print_hgst_info_log(const struct nvme_controller_data *cdata __unused, void *buf printf("===================\n"); walker = buf; - pages = *walker++; + walker++; /* Pages */ walker++; len = le16dec(walker); walker += 2; diff --git a/sbin/pfctl/pfctl_optimize.c b/sbin/pfctl/pfctl_optimize.c index cb557884067..d999734a906 100644 --- a/sbin/pfctl/pfctl_optimize.c +++ b/sbin/pfctl/pfctl_optimize.c @@ -817,7 +817,6 @@ block_feedback(struct pfctl *pf, struct superblock *block) { TAILQ_HEAD( , pf_opt_rule) queue; struct pf_opt_rule *por1, *por2; - u_int64_t total_count = 0; struct pfctl_rule a, b; @@ -827,8 +826,6 @@ block_feedback(struct pfctl *pf, struct superblock *block) */ TAILQ_FOREACH(por1, &block->sb_profiled_block->sb_rules, por_entry) { comparable_rule(&a, &por1->por_rule, DC); - total_count += por1->por_rule.packets[0] + - por1->por_rule.packets[1]; TAILQ_FOREACH(por2, &block->sb_rules, por_entry) { if (por2->por_profile_count) continue; diff --git a/sbin/recoverdisk/recoverdisk.c b/sbin/recoverdisk/recoverdisk.c index 8c4aabebc76..0f3388f9933 100644 --- a/sbin/recoverdisk/recoverdisk.c +++ b/sbin/recoverdisk/recoverdisk.c @@ -32,9 +32,7 @@ /* Safe printf into a fixed-size buffer */ #define bprintf(buf, fmt, ...) \ do { \ - int ibprintf; \ - ibprintf = snprintf(buf, sizeof buf, fmt, __VA_ARGS__); \ - assert(ibprintf >= 0 && ibprintf < (int)sizeof buf); \ + snprintf(buf, sizeof buf, fmt, __VA_ARGS__); \ } while (0) struct lump { @@ -79,8 +77,7 @@ static void report_good_read2(time_t now, size_t bytes, struct period_head *ph, time_t dt) { struct period *pp; - const char *fmt; - struct tm tm1; + struct tm tm1 __unused; pp = TAILQ_FIRST(ph); if (pp == NULL || pp->t1 < now) { @@ -89,11 +86,6 @@ report_good_read2(time_t now, size_t bytes, struct period_head *ph, time_t dt) pp->t0 = (now / dt) * dt; pp->t1 = (now / dt + 1) * dt; assert(localtime_r(&pp->t0, &tm1) != NULL); - if (dt < 86400) - fmt = "%H:%M"; - else - fmt = "%d%b"; - assert(strftime(pp->str, sizeof pp->str, fmt, &tm1) != 0); TAILQ_INSERT_HEAD(ph, pp, list); } pp->bytes_read += bytes; @@ -149,12 +141,10 @@ static void set_verbose(void) { struct winsize wsz; - time_t t0; if (!isatty(STDIN_FILENO) || ioctl(STDIN_FILENO, TIOCGWINSZ, &wsz)) return; verbose = 1; - t0 = time(NULL); } static void diff --git a/sys/amd64/vmm/vmm_instruction_emul.c b/sys/amd64/vmm/vmm_instruction_emul.c index ae022210893..a2ee81761c7 100644 --- a/sys/amd64/vmm/vmm_instruction_emul.c +++ b/sys/amd64/vmm/vmm_instruction_emul.c @@ -717,21 +717,11 @@ get_gla(void *vm, int vcpuid, struct vie *vie, struct vm_guest_paging *paging, { struct seg_desc desc; uint64_t cr0, val, rflags; - int error; - - error = vie_read_register(vm, vcpuid, VM_REG_GUEST_CR0, &cr0); - KASSERT(error == 0, ("%s: error %d getting cr0", __func__, error)); - - error = vie_read_register(vm, vcpuid, VM_REG_GUEST_RFLAGS, &rflags); - KASSERT(error == 0, ("%s: error %d getting rflags", __func__, error)); - - error = vm_get_seg_desc(vm, vcpuid, seg, &desc); - KASSERT(error == 0, ("%s: error %d getting segment descriptor %d", - __func__, error, seg)); - error = vie_read_register(vm, vcpuid, gpr, &val); - KASSERT(error == 0, ("%s: error %d getting register %d", __func__, - error, gpr)); + vie_read_register(vm, vcpuid, VM_REG_GUEST_CR0, &cr0); + vie_read_register(vm, vcpuid, VM_REG_GUEST_RFLAGS, &rflags); + vm_get_seg_desc(vm, vcpuid, seg, &desc); + vie_read_register(vm, vcpuid, gpr, &val); if (vie_calculate_gla(paging->cpu_mode, seg, &desc, val, opsize, addrsize, prot, gla)) { diff --git a/sys/netinet/libalias/alias.c b/sys/netinet/libalias/alias.c index 39e9b060623..b70c6458c80 100644 --- a/sys/netinet/libalias/alias.c +++ b/sys/netinet/libalias/alias.c @@ -827,7 +827,6 @@ UdpAliasOut(struct libalias *la, struct ip *pip, int maxpacketsize, int create) u_short dest_port; u_short proxy_server_port; int proxy_type; - int error; size_t dlen; LIBALIAS_LOCK_ASSERT(la); @@ -899,7 +898,7 @@ UdpAliasOut(struct libalias *la, struct ip *pip, int maxpacketsize, int create) alias_port = GetAliasPort(lnk); /* Walk out chain. */ - error = find_handler(OUT, UDP, la, pip, &ad); + find_handler(OUT, UDP, la, pip, &ad); /* If UDP checksum is not zero, adjust since source port is */ /* being aliased and source address is being altered */ @@ -949,7 +948,7 @@ TcpAliasIn(struct libalias *la, struct ip *pip) struct in_addr proxy_address; u_short alias_port; u_short proxy_port; - int accumulate, error; + int accumulate; /* * The init of MANY vars is a bit below, but aliashandlepptpin @@ -968,7 +967,7 @@ TcpAliasIn(struct libalias *la, struct ip *pip) }; /* Walk out chain. */ - error = find_handler(IN, TCP, la, pip, &ad); + find_handler(IN, TCP, la, pip, &ad); alias_address = GetAliasAddress(lnk); original_address = GetOriginalAddress(lnk); @@ -1055,7 +1054,7 @@ TcpAliasIn(struct libalias *la, struct ip *pip) static int TcpAliasOut(struct libalias *la, struct ip *pip, int maxpacketsize, int create) { - int proxy_type, error; + int proxy_type; u_short dest_port; u_short proxy_server_port; size_t dlen; @@ -1137,7 +1136,7 @@ TcpAliasOut(struct libalias *la, struct ip *pip, int maxpacketsize, int create) TcpMonitorOut(tc->th_flags, lnk); /* Walk out chain. */ - error = find_handler(OUT, TCP, la, pip, &ad); + find_handler(OUT, TCP, la, pip, &ad); /* Adjust TCP checksum since source port is being aliased * and source address is being altered */ diff --git a/usr.bin/backlight/backlight.c b/usr.bin/backlight/backlight.c index 9cf7a0912e9..7c3f295223f 100644 --- a/usr.bin/backlight/backlight.c +++ b/usr.bin/backlight/backlight.c @@ -101,11 +101,9 @@ main(int argc, char *argv[]) long percent = -1; const char *percent_error; uint32_t i; - bool setname; bool quiet = false; action = BACKLIGHT_QUERY; - setname = false; fd = -1; while ((ch = getopt(argc, argv, "f:qhi")) != -1) { @@ -114,7 +112,6 @@ main(int argc, char *argv[]) quiet = true; break; case 'f': - setname = true; set_device_name(optarg); break; case 'i': diff --git a/usr.bin/ipcs/ipc.c b/usr.bin/ipcs/ipc.c index d48389dd54b..6a128ba58b1 100644 --- a/usr.bin/ipcs/ipc.c +++ b/usr.bin/ipcs/ipc.c @@ -106,7 +106,8 @@ static struct scgs_vector msginfo_scgsv[] = { MSGINFO_XVEC { .sysctl=NULL } }; kvm_t *kd; void -sysctlgatherstruct(void *addr, size_t size, struct scgs_vector *vecarr) +sysctlgatherstruct(void *addr, size_t size __unused, + struct scgs_vector *vecarr) { struct scgs_vector *xp; size_t tsiz; diff --git a/usr.bin/mkuzip/mkuzip.c b/usr.bin/mkuzip/mkuzip.c index a2763e06440..43fb4f49d73 100644 --- a/usr.bin/mkuzip/mkuzip.c +++ b/usr.bin/mkuzip/mkuzip.c @@ -128,9 +128,8 @@ int main(int argc, char **argv) uint64_t offset, last_offset; struct cloop_header hdr; struct mkuz_conveyor *cvp; - void *c_ctx; struct mkuz_blk_info *chit; - size_t ncpusz, ncpu, magiclen; + size_t ncpusz, ncpu; double st, et; enum UZ_ALGORITHM comp_alg; int comp_level; @@ -233,8 +232,7 @@ int main(int argc, char **argv) cfs.handler = &uzip_fmts[comp_alg]; - magiclen = strlcpy(hdr.magic, cfs.handler->magic, sizeof(hdr.magic)); - assert(magiclen < sizeof(hdr.magic)); + strlcpy(hdr.magic, cfs.handler->magic, sizeof(hdr.magic)); if (cfs.en_dedup != 0) { /* @@ -255,7 +253,7 @@ int main(int argc, char **argv) errx(1, "maximal compressed cluster size %zu greater than MAXPHYS %zu", cfs.cbound_blksz, (size_t)MAXPHYS); - c_ctx = cfs.handler->f_init(&comp_level); + cfs.handler->f_init(&comp_level); cfs.comp_level = comp_level; cfs.iname = argv[0]; diff --git a/usr.bin/mt/mt.c b/usr.bin/mt/mt.c index a053cdd9213..73b54e24217 100644 --- a/usr.bin/mt/mt.c +++ b/usr.bin/mt/mt.c @@ -1555,15 +1555,12 @@ mt_getdensity(int argc, char **argv, char *xml_str, struct mt_status_data *status_data) { int retval = 0; - int verbose = 0, xml_dump = 0; + int xml_dump = 0; struct mt_status_entry *density_root = NULL; int c; while ((c = getopt(argc, argv, "vx")) != -1) { switch (c) { - case 'v': - verbose = 1; - break; case 'x': xml_dump = 1; break; diff --git a/usr.bin/procstat/procstat.c b/usr.bin/procstat/procstat.c index a1cd082ecb5..bb3b9e9de5a 100644 --- a/usr.bin/procstat/procstat.c +++ b/usr.bin/procstat/procstat.c @@ -236,11 +236,10 @@ static const struct procstat_cmd * getcmdbyprogname(const char *pprogname) { const char *ca; - size_t i, len; + size_t i; if (pprogname == NULL) return (NULL); - len = strlen(pprogname); for (i = 0; i < nitems(pacmd_table); i++) { ca = pacmd_table[i].command; diff --git a/usr.bin/truss/syscalls.c b/usr.bin/truss/syscalls.c index 6740ab21ff2..bdad78e66a2 100644 --- a/usr.bin/truss/syscalls.c +++ b/usr.bin/truss/syscalls.c @@ -977,18 +977,15 @@ print_mask_arg32(bool (*decoder)(FILE *, uint32_t, uint32_t *), FILE *fp, static void quad_fixup(struct syscall_decode *sc) { - int offset, prev; + int offset; u_int i; offset = 0; - prev = -1; for (i = 0; i < sc->nargs; i++) { /* This arg type is a dummy that doesn't use offset. */ if ((sc->args[i].type & ARG_MASK) == PipeFds) continue; - assert(prev < sc->args[i].offset); - prev = sc->args[i].offset; sc->args[i].offset += offset; switch (sc->args[i].type & ARG_MASK) { case Quad: @@ -2128,11 +2125,9 @@ print_arg(struct syscall_arg *sc, unsigned long *args, register_t *retval, fputs(strsig2(args[sc->offset]), fp); break; case Sigset: { - long sig; sigset_t ss; int i, first; - sig = args[sc->offset]; if (get_struct(pid, args[sc->offset], (void *)&ss, sizeof(ss)) == -1) { print_pointer(fp, args[sc->offset]); diff --git a/usr.bin/unifdef/unifdef.c b/usr.bin/unifdef/unifdef.c index 50331d5ad9b..b7381a0b46b 100644 --- a/usr.bin/unifdef/unifdef.c +++ b/usr.bin/unifdef/unifdef.c @@ -1556,7 +1556,7 @@ static void addsym2(bool ignorethis, const char *symname, const char *val) { const char *cp = symname; - struct macro *sym, *r; + struct macro *sym; sym = findsym(&cp); if (sym == NULL) { @@ -1564,8 +1564,7 @@ addsym2(bool ignorethis, const char *symname, const char *val) sym->ignore = ignorethis; sym->name = symname; sym->value = val; - r = RB_INSERT(MACROMAP, ¯o_tree, sym); - assert(r == NULL); + RB_INSERT(MACROMAP, ¯o_tree, sym); } debugsym("addsym", sym); } diff --git a/usr.bin/units/units.c b/usr.bin/units/units.c index 02aeb60606f..f547ab66acc 100644 --- a/usr.bin/units/units.c +++ b/usr.bin/units/units.c @@ -763,11 +763,9 @@ main(int argc, char **argv) EditLine *el; HistEvent ev; int inputsz; - char const * history_file; quiet = false; readfile = false; - history_file = NULL; outputformat = numfmt; quit = false; while ((optchar = getopt_long(argc, argv, "+ehf:o:qtvH:UV", longopts, NULL)) != -1) { @@ -782,9 +780,6 @@ main(int argc, char **argv) else readunits(optarg); break; - case 'H': - history_file = optarg; - break; case 'q': quiet = true; break; diff --git a/usr.bin/vmstat/vmstat.c b/usr.bin/vmstat/vmstat.c index 403dc6e2a05..7318d0ed6f1 100644 --- a/usr.bin/vmstat/vmstat.c +++ b/usr.bin/vmstat/vmstat.c @@ -670,12 +670,11 @@ dovmstat(unsigned int interval, int reps) u_long cpumask; size_t size; time_t uptime, halfuptime; - int ncpus, maxid, rate_adj, retval; + int maxid, rate_adj, retval; uptime = getuptime() / 1000000000LL; halfuptime = uptime / 2; rate_adj = 1; - ncpus = 1; maxid = 0; cpumask = 0; @@ -714,7 +713,6 @@ dovmstat(unsigned int interval, int reps) } if (Pflag) { - ncpus = getcpuinfo(&cpumask, &maxid); size_cp_times = sizeof(long) * (maxid + 1) * CPUSTATES; cur_cp_times = calloc(1, size_cp_times); last_cp_times = calloc(1, size_cp_times); diff --git a/usr.bin/vtfontcvt/vtfontcvt.c b/usr.bin/vtfontcvt/vtfontcvt.c index fbfc0539b4d..86b06a9a6f2 100644 --- a/usr.bin/vtfontcvt/vtfontcvt.c +++ b/usr.bin/vtfontcvt/vtfontcvt.c @@ -721,12 +721,9 @@ write_mappings(FILE *fp, unsigned int map_idx) struct mapping_list *ml = &maps[map_idx]; struct mapping *mp; vfnt_map_t fm; - unsigned int i = 0, j = 0; TAILQ_FOREACH(mp, ml, m_list) { - j++; if (mp->m_length > 0) { - i += mp->m_length; fm.vfm_src = htobe32(mp->m_char); fm.vfm_dst = htobe16(mp->m_glyph->g_index); fm.vfm_len = htobe16(mp->m_length - 1); @@ -734,7 +731,6 @@ write_mappings(FILE *fp, unsigned int map_idx) return (1); } } - assert(i == j); return (0); } @@ -743,19 +739,15 @@ write_source_mappings(FILE *fp, unsigned int map_idx) { struct mapping_list *ml = &maps[map_idx]; struct mapping *mp; - unsigned int i = 0, j = 0; TAILQ_FOREACH(mp, ml, m_list) { - j++; if (mp->m_length > 0) { - i += mp->m_length; if (fprintf(fp, "\t{ 0x%08x, 0x%04x, 0x%04x },\n", mp->m_char, mp->m_glyph->g_index, mp->m_length - 1) < 0) return (1); } } - assert(i == j); return (0); } diff --git a/usr.sbin/acpi/acpidump/acpi.c b/usr.sbin/acpi/acpidump/acpi.c index adb5b968f44..25a0f577b20 100644 --- a/usr.sbin/acpi/acpidump/acpi.c +++ b/usr.sbin/acpi/acpidump/acpi.c @@ -1576,7 +1576,6 @@ acpi_print_nfit(ACPI_NFIT_HEADER *nfit) ACPI_NFIT_SYSTEM_ADDRESS *sysaddr; ACPI_NFIT_MEMORY_MAP *mmap; ACPI_NFIT_INTERLEAVE *ileave; - ACPI_NFIT_SMBIOS *smbios; ACPI_NFIT_CONTROL_REGION *ctlreg; ACPI_NFIT_DATA_REGION *datareg; ACPI_NFIT_FLUSH_ADDRESS *fladdr; @@ -1650,10 +1649,6 @@ acpi_print_nfit(ACPI_NFIT_HEADER *nfit) printf("\tLineSize=%u\n", (u_int)ileave->LineSize); /* XXX ileave->LineOffset[i] output is not supported */ break; - case ACPI_NFIT_TYPE_SMBIOS: - smbios = (ACPI_NFIT_SMBIOS *)nfit; - /* XXX smbios->Data[x] output is not supported */ - break; case ACPI_NFIT_TYPE_CONTROL_REGION: ctlreg = (ACPI_NFIT_CONTROL_REGION *)nfit; printf("\tRegionIndex=%u\n", (u_int)ctlreg->RegionIndex); diff --git a/usr.sbin/bhyve/atkbdc.c b/usr.sbin/bhyve/atkbdc.c index a08f58f84b2..df0f2661c8a 100644 --- a/usr.sbin/bhyve/atkbdc.c +++ b/usr.sbin/bhyve/atkbdc.c @@ -397,7 +397,7 @@ atkbdc_sts_ctl_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, uint32_t *eax, void *arg) { struct atkbdc_softc *sc; - int error, retval; + int retval; if (bytes != 1) return (-1); @@ -467,8 +467,7 @@ atkbdc_sts_ctl_handler(struct vmctx *ctx, int vcpu, int in, int port, sc->status |= KBDS_AUX_BUFFER_FULL | KBDS_KBD_BUFFER_FULL; break; case KBDC_RESET: /* Pulse "reset" line */ - error = vm_suspend(ctx, VM_SUSPEND_RESET); - assert(error == 0 || errno == EALREADY); + vm_suspend(ctx, VM_SUSPEND_RESET); break; default: if (*eax >= 0x21 && *eax <= 0x3f) { @@ -516,7 +515,6 @@ atkbdc_init(struct vmctx *ctx) { struct inout_port iop; struct atkbdc_softc *sc; - int error; sc = calloc(1, sizeof(struct atkbdc_softc)); sc->ctx = ctx; @@ -531,8 +529,7 @@ atkbdc_init(struct vmctx *ctx) iop.handler = atkbdc_sts_ctl_handler; iop.arg = sc; - error = register_inout(&iop); - assert(error == 0); + register_inout(&iop); bzero(&iop, sizeof(struct inout_port)); iop.name = "atkdbc"; @@ -542,8 +539,7 @@ atkbdc_init(struct vmctx *ctx) iop.handler = atkbdc_data_handler; iop.arg = sc; - error = register_inout(&iop); - assert(error == 0); + register_inout(&iop); pci_irq_reserve(KBD_DEV_IRQ); sc->kbd.irq = KBD_DEV_IRQ; diff --git a/usr.sbin/bhyve/bhyverun.c b/usr.sbin/bhyve/bhyverun.c index e4d96d2293f..d5bfc00f35d 100644 --- a/usr.sbin/bhyve/bhyverun.c +++ b/usr.sbin/bhyve/bhyverun.c @@ -488,14 +488,13 @@ vm_inject_fault(void *arg, int vcpu, int vector, int errcode_valid, int errcode) { struct vmctx *ctx; - int error, restart_instruction; + int restart_instruction; ctx = arg; restart_instruction = 1; - error = vm_inject_exception(ctx, vcpu, vector, errcode_valid, errcode, + vm_inject_exception(ctx, vcpu, vector, errcode_valid, errcode, restart_instruction); - assert(error == 0); } void * @@ -1136,15 +1135,12 @@ do_open(const char *vmname) void spinup_vcpu(struct vmctx *ctx, int vcpu) { - int error; uint64_t rip; - error = vm_get_register(ctx, vcpu, VM_REG_GUEST_RIP, &rip); - assert(error == 0); + vm_get_register(ctx, vcpu, VM_REG_GUEST_RIP, &rip); fbsdrun_set_capabilities(ctx, vcpu); - error = vm_set_capability(ctx, vcpu, VM_CAP_UNRESTRICTED_GUEST, 1); - assert(error == 0); + vm_set_capability(ctx, vcpu, VM_CAP_UNRESTRICTED_GUEST, 1); fbsdrun_addcpu(ctx, BSP, vcpu, rip); } diff --git a/usr.sbin/bhyve/gdb.c b/usr.sbin/bhyve/gdb.c index 219d192b7c9..0ff15bdef5b 100644 --- a/usr.sbin/bhyve/gdb.c +++ b/usr.sbin/bhyve/gdb.c @@ -780,7 +780,6 @@ static void gdb_cpu_resume(int vcpu) { struct vcpu_state *vs; - int error; vs = &vcpu_state[vcpu]; @@ -791,8 +790,7 @@ gdb_cpu_resume(int vcpu) assert(vs->hit_swbreak == false); assert(vs->stepped == false); if (vs->stepping) { - error = vm_set_capability(ctx, vcpu, VM_CAP_MTRAP_EXIT, 1); - assert(error == 0); + vm_set_capability(ctx, vcpu, VM_CAP_MTRAP_EXIT, 1); } } @@ -874,15 +872,13 @@ gdb_cpu_breakpoint(int vcpu, struct vm_exit *vmexit) struct breakpoint *bp; struct vcpu_state *vs; uint64_t gpa; - int error; if (!gdb_active) { fprintf(stderr, "vm_loop: unexpected VMEXIT_DEBUG\n"); exit(4); } pthread_mutex_lock(&gdb_lock); - error = guest_vaddr2paddr(vcpu, vmexit->rip, &gpa); - assert(error == 1); + guest_vaddr2paddr(vcpu, vmexit->rip, &gpa); bp = find_breakpoint(gpa); if (bp != NULL) { vs = &vcpu_state[vcpu]; @@ -914,11 +910,9 @@ gdb_cpu_breakpoint(int vcpu, struct vm_exit *vmexit) } else { debug("$vCPU %d injecting breakpoint at rip %#lx\n", vcpu, vmexit->rip); - error = vm_set_register(ctx, vcpu, + vm_set_register(ctx, vcpu, VM_REG_GUEST_ENTRY_INST_LENGTH, vmexit->u.bpt.inst_length); - assert(error == 0); - error = vm_inject_exception(ctx, vcpu, IDT_BP, 0, 0, 0); - assert(error == 0); + vm_inject_exception(ctx, vcpu, IDT_BP, 0, 0, 0); } pthread_mutex_unlock(&gdb_lock); } diff --git a/usr.sbin/bhyve/hda_codec.c b/usr.sbin/bhyve/hda_codec.c index 7a6ba345d8e..45dfdc898e7 100644 --- a/usr.sbin/bhyve/hda_codec.c +++ b/usr.sbin/bhyve/hda_codec.c @@ -395,7 +395,6 @@ hda_codec_init(struct hda_codec_inst *hci, const char *play, { struct hda_codec_softc *sc = NULL; struct hda_codec_stream *st = NULL; - int err; if (!(play || rec)) return (-1); @@ -426,10 +425,9 @@ hda_codec_init(struct hda_codec_inst *hci, const char *play, if (play) { st = &sc->streams[HDA_CODEC_STREAM_OUTPUT]; - err = hda_audio_ctxt_init(&st->actx, "hda-audio-output", + hda_audio_ctxt_init(&st->actx, "hda-audio-output", hda_codec_audio_output_do_transfer, hda_codec_audio_output_do_setup, sc); - assert(!err); st->aud = audio_init(play, 1); if (!st->aud) { @@ -444,10 +442,9 @@ hda_codec_init(struct hda_codec_inst *hci, const char *play, if (rec) { st = &sc->streams[HDA_CODEC_STREAM_INPUT]; - err = hda_audio_ctxt_init(&st->actx, "hda-audio-input", + hda_audio_ctxt_init(&st->actx, "hda-audio-input", hda_codec_audio_input_do_transfer, hda_codec_audio_input_do_setup, sc); - assert(!err); st->aud = audio_init(rec, 0); if (!st->aud) { @@ -743,7 +740,6 @@ hda_codec_audio_input_do_transfer(void *arg) struct hda_ops *hops = NULL; struct hda_codec_stream *st = NULL; struct audio *aud = NULL; - int err; hci = sc->hci; assert(hci); @@ -754,8 +750,7 @@ hda_codec_audio_input_do_transfer(void *arg) st = &sc->streams[HDA_CODEC_STREAM_INPUT]; aud = st->aud; - err = audio_record(aud, st->buf, sizeof(st->buf)); - assert(!err); + audio_record(aud, st->buf, sizeof(st->buf)); hops->transfer(hci, st->stream, 0, st->buf, sizeof(st->buf)); } @@ -884,8 +879,6 @@ static int hda_audio_ctxt_init(struct hda_audio_ctxt *actx, const char *tname, transfer_func_t do_transfer, setup_func_t do_setup, void *priv) { - int err; - assert(actx); assert(tname); assert(do_transfer); @@ -903,14 +896,11 @@ hda_audio_ctxt_init(struct hda_audio_ctxt *actx, const char *tname, else strcpy(actx->name, "unknown"); - err = pthread_mutex_init(&actx->mtx, NULL); - assert(!err); + pthread_mutex_init(&actx->mtx, NULL); - err = pthread_cond_init(&actx->cond, NULL); - assert(!err); + pthread_cond_init(&actx->cond, NULL); - err = pthread_create(&actx->tid, NULL, hda_audio_ctxt_thr, actx); - assert(!err); + pthread_create(&actx->tid, NULL, hda_audio_ctxt_thr, actx); pthread_set_name_np(actx->tid, tname); diff --git a/usr.sbin/bhyve/mem.c b/usr.sbin/bhyve/mem.c index 90aefe45c85..588e116c3b1 100644 --- a/usr.sbin/bhyve/mem.c +++ b/usr.sbin/bhyve/mem.c @@ -169,7 +169,7 @@ access_memory(struct vmctx *ctx, int vcpu, uint64_t paddr, mem_cb_t *cb, void *arg) { struct mmio_rb_range *entry; - int err, perror, immutable; + int err, immutable; pthread_rwlock_rdlock(&mmio_rwlock); /* @@ -187,8 +187,7 @@ access_memory(struct vmctx *ctx, int vcpu, uint64_t paddr, mem_cb_t *cb, /* Update the per-vCPU cache */ mmio_hint[vcpu] = entry; } else if (mmio_rb_lookup(&mmio_rb_fallback, paddr, &entry)) { - perror = pthread_rwlock_unlock(&mmio_rwlock); - assert(perror == 0); + pthread_rwlock_unlock(&mmio_rwlock); return (ESRCH); } } @@ -208,15 +207,13 @@ access_memory(struct vmctx *ctx, int vcpu, uint64_t paddr, mem_cb_t *cb, */ immutable = (entry->mr_param.flags & MEM_F_IMMUTABLE); if (immutable) { - perror = pthread_rwlock_unlock(&mmio_rwlock); - assert(perror == 0); + pthread_rwlock_unlock(&mmio_rwlock); } err = cb(ctx, vcpu, paddr, &entry->mr_param, arg); if (!immutable) { - perror = pthread_rwlock_unlock(&mmio_rwlock); - assert(perror == 0); + pthread_rwlock_unlock(&mmio_rwlock); } @@ -294,7 +291,7 @@ static int register_mem_int(struct mmio_rb_tree *rbt, struct mem_range *memp) { struct mmio_rb_range *entry, *mrp; - int err, perror; + int err; err = 0; @@ -310,8 +307,7 @@ register_mem_int(struct mmio_rb_tree *rbt, struct mem_range *memp) pthread_rwlock_wrlock(&mmio_rwlock); if (mmio_rb_lookup(rbt, memp->base, &entry) != 0) err = mmio_rb_add(rbt, mrp); - perror = pthread_rwlock_unlock(&mmio_rwlock); - assert(perror == 0); + pthread_rwlock_unlock(&mmio_rwlock); if (err) free(mrp); } @@ -336,17 +332,12 @@ register_mem_fallback(struct mem_range *memp) int unregister_mem(struct mem_range *memp) { - struct mem_range *mr; struct mmio_rb_range *entry = NULL; - int err, perror, i; + int err, i; pthread_rwlock_wrlock(&mmio_rwlock); err = mmio_rb_lookup(&mmio_rb_root, memp->base, &entry); if (err == 0) { - mr = &entry->mr_param; - assert(mr->name == memp->name); - assert(mr->base == memp->base && mr->size == memp->size); - assert((mr->flags & MEM_F_IMMUTABLE) == 0); RB_REMOVE(mmio_rb_tree, &mmio_rb_root, entry); /* flush Per-vCPU cache */ @@ -355,8 +346,7 @@ unregister_mem(struct mem_range *memp) mmio_hint[i] = NULL; } } - perror = pthread_rwlock_unlock(&mmio_rwlock); - assert(perror == 0); + pthread_rwlock_unlock(&mmio_rwlock); if (entry) free(entry); diff --git a/usr.sbin/bhyve/mevent.c b/usr.sbin/bhyve/mevent.c index 0c5351cd31a..2ce2f655ba6 100644 --- a/usr.sbin/bhyve/mevent.c +++ b/usr.sbin/bhyve/mevent.c @@ -475,7 +475,6 @@ mevent_dispatch(void) { struct kevent changelist[MEVENT_MAX]; struct kevent eventlist[MEVENT_MAX]; - struct mevent *pipev; int numev; int ret; #ifndef WITHOUT_CAPSICUM @@ -509,8 +508,7 @@ mevent_dispatch(void) /* * Add internal event handler for the pipe write fd */ - pipev = mevent_add(mevent_pipefd[0], EVF_READ, mevent_pipe_read, NULL); - assert(pipev != NULL); + mevent_add(mevent_pipefd[0], EVF_READ, mevent_pipe_read, NULL); for (;;) { /* diff --git a/usr.sbin/bhyve/pci_ahci.c b/usr.sbin/bhyve/pci_ahci.c index 38ec87c34ee..d6c301492d4 100644 --- a/usr.sbin/bhyve/pci_ahci.c +++ b/usr.sbin/bhyve/pci_ahci.c @@ -672,7 +672,7 @@ ahci_handle_rw(struct ahci_port *p, int slot, uint8_t *cfis, uint32_t done) struct ahci_cmd_hdr *hdr; uint64_t lba; uint32_t len; - int err, first, ncq, readop; + int first, ncq, readop; prdt = (struct ahci_prdt_entry *)(cfis + 0x80); hdr = (struct ahci_cmd_hdr *)(p->cmd_lst + slot * AHCI_CL_SIZE); @@ -744,10 +744,9 @@ ahci_handle_rw(struct ahci_port *p, int slot, uint8_t *cfis, uint32_t done) ahci_write_fis_d2h_ncq(p, slot); if (readop) - err = blockif_read(p->bctx, breq); + blockif_read(p->bctx, breq); else - err = blockif_write(p->bctx, breq); - assert(err == 0); + blockif_write(p->bctx, breq); } static void @@ -755,7 +754,6 @@ ahci_handle_flush(struct ahci_port *p, int slot, uint8_t *cfis) { struct ahci_ioreq *aior; struct blockif_req *breq; - int err; /* * Pull request off free list @@ -780,8 +778,7 @@ ahci_handle_flush(struct ahci_port *p, int slot, uint8_t *cfis) */ TAILQ_INSERT_HEAD(&p->iobhd, aior, io_blist); - err = blockif_flush(p->bctx, breq); - assert(err == 0); + blockif_flush(p->bctx, breq); } static inline void @@ -820,7 +817,7 @@ ahci_handle_dsm_trim(struct ahci_port *p, int slot, uint8_t *cfis, uint32_t done uint8_t *entry; uint64_t elba; uint32_t len, elen; - int err, first, ncq; + int first, ncq; uint8_t buf[512]; first = (done == 0); @@ -894,8 +891,7 @@ next: if (ncq && first) ahci_write_fis_d2h_ncq(p, slot); - err = blockif_delete(p->bctx, breq); - assert(err == 0); + blockif_delete(p->bctx, breq); } static inline void @@ -1402,7 +1398,6 @@ atapi_read(struct ahci_port *p, int slot, uint8_t *cfis, uint32_t done) uint8_t *acmd; uint64_t lba; uint32_t len; - int err; acmd = cfis + 0x40; hdr = (struct ahci_cmd_hdr *)(p->cmd_lst + slot * AHCI_CL_SIZE); @@ -1441,8 +1436,7 @@ atapi_read(struct ahci_port *p, int slot, uint8_t *cfis, uint32_t done) /* Stuff request onto busy list. */ TAILQ_INSERT_HEAD(&p->iobhd, aior, io_blist); - err = blockif_read(p->bctx, breq); - assert(err == 0); + blockif_read(p->bctx, breq); } static void diff --git a/usr.sbin/bhyve/pci_e82545.c b/usr.sbin/bhyve/pci_e82545.c index d0b4fb9e466..7688cbc205b 100644 --- a/usr.sbin/bhyve/pci_e82545.c +++ b/usr.sbin/bhyve/pci_e82545.c @@ -1084,7 +1084,7 @@ e82545_transmit(struct e82545_softc *sc, uint16_t head, uint16_t tail, struct ck_info ckinfo[2]; struct iovec *iov; union e1000_tx_udesc *dsc; - int desc, dtype, len, ntype, iovcnt, tlen, tcp, tso; + int desc, dtype, len, iovcnt, tcp, tso; int mss, paylen, seg, tiovcnt, left, now, nleft, nnow, pv, pvoff; unsigned hdrlen, vlen; uint32_t tcpsum, tcpseq; @@ -1092,8 +1092,6 @@ e82545_transmit(struct e82545_softc *sc, uint16_t head, uint16_t tail, ckinfo[0].ck_valid = ckinfo[1].ck_valid = 0; iovcnt = 0; - tlen = 0; - ntype = 0; tso = 0; ohead = head; @@ -1124,20 +1122,17 @@ e82545_transmit(struct e82545_softc *sc, uint16_t head, uint16_t tail, /* * legacy cksum start valid in first descriptor */ - ntype = dtype; ckinfo[0].ck_start = dsc->td.upper.fields.css; break; case E1000_TXD_TYP_D: DPRINTF("tx data desc idx %d: %08x%08x", head, dsc->td.upper.data, dsc->td.lower.data); - ntype = dtype; break; default: break; } } else { /* Descriptor type must be consistent */ - assert(dtype == ntype); DPRINTF("tx next desc idx %d: %08x%08x", head, dsc->td.upper.data, dsc->td.lower.data); } @@ -1150,7 +1145,6 @@ e82545_transmit(struct e82545_softc *sc, uint16_t head, uint16_t tail, if ((dsc->td.lower.data & E1000_TXD_CMD_EOP) != 0 && (dsc->td.lower.data & E1000_TXD_CMD_IFCS) == 0) len -= 2; - tlen += len; if (iovcnt < I82545_MAX_TXSEGS) { iov[iovcnt].iov_base = paddr_guest2host( sc->esc_ctx, dsc->td.buffer_addr, len); diff --git a/usr.sbin/bhyve/pci_emul.c b/usr.sbin/bhyve/pci_emul.c index d155029d269..aca69cbf88f 100644 --- a/usr.sbin/bhyve/pci_emul.c +++ b/usr.sbin/bhyve/pci_emul.c @@ -507,7 +507,6 @@ static void modify_bar_registration(struct pci_devinst *pi, int idx, int registration) { struct pci_devemu *pe; - int error; struct inout_port iop; struct mem_range mr; @@ -522,9 +521,9 @@ modify_bar_registration(struct pci_devinst *pi, int idx, int registration) iop.flags = IOPORT_F_INOUT; iop.handler = pci_emul_io_handler; iop.arg = pi; - error = register_inout(&iop); + register_inout(&iop); } else - error = unregister_inout(&iop); + unregister_inout(&iop); if (pe->pe_baraddr != NULL) (*pe->pe_baraddr)(pi->pi_vmctx, pi, idx, registration, pi->pi_bar[idx].addr); @@ -540,18 +539,14 @@ modify_bar_registration(struct pci_devinst *pi, int idx, int registration) mr.handler = pci_emul_mem_handler; mr.arg1 = pi; mr.arg2 = idx; - error = register_mem(&mr); + register_mem(&mr); } else - error = unregister_mem(&mr); + unregister_mem(&mr); if (pe->pe_baraddr != NULL) (*pe->pe_baraddr)(pi->pi_vmctx, pi, idx, registration, pi->pi_bar[idx].addr); break; - default: - error = EINVAL; - break; } - assert(error == 0); } static void @@ -2253,7 +2248,6 @@ struct pci_emul_dsoftc { static int pci_emul_dinit(struct vmctx *ctx, struct pci_devinst *pi, nvlist_t *nvl) { - int error; struct pci_emul_dsoftc *sc; sc = calloc(1, sizeof(struct pci_emul_dsoftc)); @@ -2264,17 +2258,13 @@ pci_emul_dinit(struct vmctx *ctx, struct pci_devinst *pi, nvlist_t *nvl) pci_set_cfgdata16(pi, PCIR_VENDOR, 0x10DD); pci_set_cfgdata8(pi, PCIR_CLASS, 0x02); - error = pci_emul_add_msicap(pi, PCI_EMUL_MSI_MSGS); - assert(error == 0); + pci_emul_add_msicap(pi, PCI_EMUL_MSI_MSGS); - error = pci_emul_alloc_bar(pi, 0, PCIBAR_IO, DIOSZ); - assert(error == 0); + pci_emul_alloc_bar(pi, 0, PCIBAR_IO, DIOSZ); - error = pci_emul_alloc_bar(pi, 1, PCIBAR_MEM32, DMEMSZ); - assert(error == 0); + pci_emul_alloc_bar(pi, 1, PCIBAR_MEM32, DMEMSZ); - error = pci_emul_alloc_bar(pi, 2, PCIBAR_MEM32, DMEMSZ); - assert(error == 0); + pci_emul_alloc_bar(pi, 2, PCIBAR_MEM32, DMEMSZ); return (0); } diff --git a/usr.sbin/bhyve/pci_hda.c b/usr.sbin/bhyve/pci_hda.c index 7491944fedd..d8677088301 100644 --- a/usr.sbin/bhyve/pci_hda.c +++ b/usr.sbin/bhyve/pci_hda.c @@ -325,7 +325,6 @@ hda_init(nvlist_t *nvl) const char *value; char *play; char *rec; - int err; #if DEBUG_HDA == 1 dbg = fopen("/tmp/bhyve_hda.log", "w+"); @@ -355,8 +354,7 @@ hda_init(nvlist_t *nvl) rec = strdup(value); DPRINTF("play: %s rec: %s", play, rec); if (play != NULL || rec != NULL) { - err = hda_codec_constructor(sc, codec, play, rec); - assert(!err); + hda_codec_constructor(sc, codec, play, rec); } free(play); free(rec); @@ -786,7 +784,6 @@ hda_corb_run(struct hda_softc *sc) { struct hda_codec_cmd_ctl *corb = &sc->corb; uint32_t verb = 0; - int err; corb->wp = hda_get_reg_by_offset(sc, HDAC_CORBWP); @@ -797,8 +794,7 @@ hda_corb_run(struct hda_softc *sc) verb = hda_dma_ld_dword(corb->dma_vaddr + \ HDA_CORB_ENTRY_LEN * corb->rp); - err = hda_send_command(sc, verb); - assert(!err); + hda_send_command(sc, verb); } hda_set_reg_by_offset(sc, HDAC_CORBRP, corb->rp); @@ -923,13 +919,11 @@ static void hda_set_corbctl(struct hda_softc *sc, uint32_t offset, uint32_t old) { uint32_t value = hda_get_reg_by_offset(sc, offset); - int err; struct hda_codec_cmd_ctl *corb = NULL; if (value & HDAC_CORBCTL_CORBRUN) { if (!(old & HDAC_CORBCTL_CORBRUN)) { - err = hda_corb_start(sc); - assert(!err); + hda_corb_start(sc); } } else { corb = &sc->corb; @@ -943,12 +937,10 @@ static void hda_set_rirbctl(struct hda_softc *sc, uint32_t offset, uint32_t old) { uint32_t value = hda_get_reg_by_offset(sc, offset); - int err; struct hda_codec_cmd_ctl *rirb = NULL; if (value & HDAC_RIRBCTL_RIRBDMAEN) { - err = hda_rirb_start(sc); - assert(!err); + hda_rirb_start(sc); } else { rirb = &sc->rirb; memset(rirb, 0, sizeof(*rirb)); @@ -1005,7 +997,6 @@ hda_set_sdctl(struct hda_softc *sc, uint32_t offset, uint32_t old) { uint8_t stream_ind = hda_get_stream_by_offsets(offset, HDAC_SDCTL0); uint32_t value = hda_get_reg_by_offset(sc, offset); - int err; DPRINTF("stream_ind: 0x%x old: 0x%x value: 0x%x", stream_ind, old, value); @@ -1016,11 +1007,9 @@ hda_set_sdctl(struct hda_softc *sc, uint32_t offset, uint32_t old) if ((value & HDAC_SDCTL_RUN) != (old & HDAC_SDCTL_RUN)) { if (value & HDAC_SDCTL_RUN) { - err = hda_stream_start(sc, stream_ind); - assert(!err); + hda_stream_start(sc, stream_ind); } else { - err = hda_stream_stop(sc, stream_ind); - assert(!err); + hda_stream_stop(sc, stream_ind); } } } @@ -1212,10 +1201,8 @@ hda_set_pib(struct hda_softc *sc, uint8_t stream_ind, uint32_t pib) static uint64_t hda_get_clock_ns(void) { struct timespec ts; - int err; - err = clock_gettime(CLOCK_MONOTONIC, &ts); - assert(!err); + clock_gettime(CLOCK_MONOTONIC, &ts); return (ts.tv_sec * 1000000000LL + ts.tv_nsec); } @@ -1261,7 +1248,6 @@ pci_hda_write(struct vmctx *ctx, int vcpu, struct pci_devinst *pi, int baridx, uint64_t offset, int size, uint64_t value) { struct hda_softc *sc = pi->pi_arg; - int err; assert(sc); assert(baridx == 0); @@ -1269,8 +1255,7 @@ pci_hda_write(struct vmctx *ctx, int vcpu, struct pci_devinst *pi, DPRINTF("offset: 0x%lx value: 0x%lx", offset, value); - err = hda_write(sc, offset, size, value); - assert(!err); + hda_write(sc, offset, size, value); } static uint64_t diff --git a/usr.sbin/bhyve/pci_virtio_block.c b/usr.sbin/bhyve/pci_virtio_block.c index 385b812be84..946fa4d3a67 100644 --- a/usr.sbin/bhyve/pci_virtio_block.c +++ b/usr.sbin/bhyve/pci_virtio_block.c @@ -305,7 +305,6 @@ pci_vtblk_proc(struct pci_vtblk_softc *sc, struct vqueue_info *vq) struct virtio_blk_hdr *vbh; struct pci_vtblk_ioreq *io; int i, n; - int err; ssize_t iolen; int writeop, type; struct vi_req req; @@ -363,10 +362,10 @@ pci_vtblk_proc(struct pci_vtblk_softc *sc, struct vqueue_info *vq) switch (type) { case VBH_OP_READ: - err = blockif_read(sc->bc, &io->io_req); + blockif_read(sc->bc, &io->io_req); break; case VBH_OP_WRITE: - err = blockif_write(sc->bc, &io->io_req); + blockif_write(sc->bc, &io->io_req); break; case VBH_OP_DISCARD: /* @@ -406,11 +405,11 @@ pci_vtblk_proc(struct pci_vtblk_softc *sc, struct vqueue_info *vq) io->io_req.br_offset = discard->sector * VTBLK_BSIZE; io->io_req.br_resid = discard->num_sectors * VTBLK_BSIZE; - err = blockif_delete(sc->bc, &io->io_req); + blockif_delete(sc->bc, &io->io_req); break; case VBH_OP_FLUSH: case VBH_OP_FLUSH_OUT: - err = blockif_flush(sc->bc, &io->io_req); + blockif_flush(sc->bc, &io->io_req); break; case VBH_OP_IDENT: /* Assume a single buffer */ @@ -424,7 +423,6 @@ pci_vtblk_proc(struct pci_vtblk_softc *sc, struct vqueue_info *vq) pci_vtblk_done_locked(io, EOPNOTSUPP); return; } - assert(err == 0); } static void diff --git a/usr.sbin/bhyve/pci_virtio_console.c b/usr.sbin/bhyve/pci_virtio_console.c index 71c3375a57a..e22da0357cf 100644 --- a/usr.sbin/bhyve/pci_virtio_console.c +++ b/usr.sbin/bhyve/pci_virtio_console.c @@ -575,15 +575,13 @@ pci_vtcon_control_send(struct pci_vtcon_softc *sc, struct vqueue_info *vq; struct vi_req req; struct iovec iov; - int n; vq = pci_vtcon_port_to_vq(&sc->vsc_control_port, true); if (!vq_has_descs(vq)) return; - n = vq_getchain(vq, &iov, 1, &req); - assert(n == 1); + vq_getchain(vq, &iov, 1, &req); memcpy(iov.iov_base, ctrl, sizeof(struct pci_vtcon_control)); if (payload != NULL && len > 0) @@ -602,14 +600,12 @@ pci_vtcon_notify_tx(void *vsc, struct vqueue_info *vq) struct pci_vtcon_port *port; struct iovec iov[1]; struct vi_req req; - int n; sc = vsc; port = pci_vtcon_vq_to_port(sc, vq); while (vq_has_descs(vq)) { - n = vq_getchain(vq, iov, 1, &req); - assert(n == 1); + vq_getchain(vq, iov, 1, &req); if (port != NULL) port->vsp_cb(port, port->vsp_arg, iov, 1); diff --git a/usr.sbin/bhyve/pci_virtio_net.c b/usr.sbin/bhyve/pci_virtio_net.c index d253b081d13..aad2e133b03 100644 --- a/usr.sbin/bhyve/pci_virtio_net.c +++ b/usr.sbin/bhyve/pci_virtio_net.c @@ -506,7 +506,6 @@ pci_vtnet_tx_thread(void *param) { struct pci_vtnet_softc *sc = param; struct vqueue_info *vq; - int error; vq = &sc->vsc_queues[VTNET_TXQ]; @@ -515,8 +514,7 @@ pci_vtnet_tx_thread(void *param) * first tx signaled */ pthread_mutex_lock(&sc->tx_mtx); - error = pthread_cond_wait(&sc->tx_cond, &sc->tx_mtx); - assert(error == 0); + pthread_cond_wait(&sc->tx_cond, &sc->tx_mtx); for (;;) { /* note - tx mutex is locked here */ @@ -526,8 +524,7 @@ pci_vtnet_tx_thread(void *param) break; sc->tx_in_progress = 0; - error = pthread_cond_wait(&sc->tx_cond, &sc->tx_mtx); - assert(error == 0); + pthread_cond_wait(&sc->tx_cond, &sc->tx_mtx); } vq_kick_disable(vq); sc->tx_in_progress = 1; diff --git a/usr.sbin/bhyve/pci_virtio_rnd.c b/usr.sbin/bhyve/pci_virtio_rnd.c index 7274d0b0591..1d2d6144f94 100644 --- a/usr.sbin/bhyve/pci_virtio_rnd.c +++ b/usr.sbin/bhyve/pci_virtio_rnd.c @@ -114,7 +114,7 @@ pci_vtrnd_notify(void *vsc, struct vqueue_info *vq) struct iovec iov; struct pci_vtrnd_softc *sc; struct vi_req req; - int len, n; + int len; sc = vsc; @@ -124,8 +124,7 @@ pci_vtrnd_notify(void *vsc, struct vqueue_info *vq) } while (vq_has_descs(vq)) { - n = vq_getchain(vq, &iov, 1, &req); - assert(n == 1); + vq_getchain(vq, &iov, 1, &req); len = read(sc->vrsc_fd, iov.iov_base, iov.iov_len); diff --git a/usr.sbin/bhyve/pci_virtio_scsi.c b/usr.sbin/bhyve/pci_virtio_scsi.c index f4a701c0e25..0554fcecb81 100644 --- a/usr.sbin/bhyve/pci_virtio_scsi.c +++ b/usr.sbin/bhyve/pci_virtio_scsi.c @@ -598,14 +598,12 @@ pci_vtscsi_requestq_notify(void *vsc, struct vqueue_info *vq) struct pci_vtscsi_request *req; struct iovec iov[VTSCSI_MAXSEG]; struct vi_req vireq; - int n; sc = vsc; q = &sc->vss_queues[vq->vq_num - 2]; while (vq_has_descs(vq)) { - n = vq_getchain(vq, iov, VTSCSI_MAXSEG, &vireq); - assert(n >= 1 && n <= VTSCSI_MAXSEG); + vq_getchain(vq, iov, VTSCSI_MAXSEG, &vireq); req = calloc(1, sizeof(struct pci_vtscsi_request)); req->vsr_idx = vireq.idx; diff --git a/usr.sbin/bhyve/pm.c b/usr.sbin/bhyve/pm.c index 9f467cb591e..30357679ffd 100644 --- a/usr.sbin/bhyve/pm.c +++ b/usr.sbin/bhyve/pm.c @@ -63,8 +63,6 @@ static int reset_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, uint32_t *eax, void *arg) { - int error; - static uint8_t reset_control; if (bytes != 1) @@ -76,8 +74,7 @@ reset_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, /* Treat hard and soft resets the same. */ if (reset_control & 0x4) { - error = vm_suspend(ctx, VM_SUSPEND_RESET); - assert(error == 0 || errno == EALREADY); + vm_suspend(ctx, VM_SUSPEND_RESET); } } return (0); @@ -238,8 +235,6 @@ static int pm1_control_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, uint32_t *eax, void *arg) { - int error; - if (bytes != 2) return (-1); if (in) @@ -259,8 +254,7 @@ pm1_control_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, */ if (*eax & PM1_SLP_EN) { if ((pm1_control & PM1_SLP_TYP) >> 10 == 5) { - error = vm_suspend(ctx, VM_SUSPEND_POWEROFF); - assert(error == 0 || errno == EALREADY); + vm_suspend(ctx, VM_SUSPEND_POWEROFF); } } } diff --git a/usr.sbin/bhyve/rtc.c b/usr.sbin/bhyve/rtc.c index 0f63156adb9..777c8316492 100644 --- a/usr.sbin/bhyve/rtc.c +++ b/usr.sbin/bhyve/rtc.c @@ -78,7 +78,6 @@ rtc_init(struct vmctx *ctx) { size_t himem; size_t lomem; - int err; /* XXX init diag/reset code/equipment/checksum ? */ @@ -89,21 +88,15 @@ rtc_init(struct vmctx *ctx) * 0x5b/0x5c/0x5d - 64KB chunks above 4GB */ lomem = (vm_get_lowmem_size(ctx) - m_16MB) / m_64KB; - err = vm_rtc_write(ctx, RTC_LMEM_LSB, lomem); - assert(err == 0); - err = vm_rtc_write(ctx, RTC_LMEM_MSB, lomem >> 8); - assert(err == 0); + vm_rtc_write(ctx, RTC_LMEM_LSB, lomem); + vm_rtc_write(ctx, RTC_LMEM_MSB, lomem >> 8); himem = vm_get_highmem_size(ctx) / m_64KB; - err = vm_rtc_write(ctx, RTC_HMEM_LSB, himem); - assert(err == 0); - err = vm_rtc_write(ctx, RTC_HMEM_SB, himem >> 8); - assert(err == 0); - err = vm_rtc_write(ctx, RTC_HMEM_MSB, himem >> 16); - assert(err == 0); - - err = vm_rtc_settime(ctx, rtc_time(ctx)); - assert(err == 0); + vm_rtc_write(ctx, RTC_HMEM_LSB, himem); + vm_rtc_write(ctx, RTC_HMEM_SB, himem >> 8); + vm_rtc_write(ctx, RTC_HMEM_MSB, himem >> 16); + + vm_rtc_settime(ctx, rtc_time(ctx)); } static void diff --git a/usr.sbin/bhyve/spinup_ap.c b/usr.sbin/bhyve/spinup_ap.c index 7c4186f5ed1..7f254f79c53 100644 --- a/usr.sbin/bhyve/spinup_ap.c +++ b/usr.sbin/bhyve/spinup_ap.c @@ -47,7 +47,7 @@ __FBSDID("$FreeBSD$"); static void spinup_ap_realmode(struct vmctx *ctx, int newcpu, uint64_t *rip) { - int vector, error; + int vector; uint16_t cs; uint64_t desc_base; uint32_t desc_limit, desc_access; @@ -59,33 +59,26 @@ spinup_ap_realmode(struct vmctx *ctx, int newcpu, uint64_t *rip) * Update the %cs and %rip of the guest so that it starts * executing real mode code at at 'vector << 12'. */ - error = vm_set_register(ctx, newcpu, VM_REG_GUEST_RIP, *rip); - assert(error == 0); + vm_set_register(ctx, newcpu, VM_REG_GUEST_RIP, *rip); - error = vm_get_desc(ctx, newcpu, VM_REG_GUEST_CS, &desc_base, + vm_get_desc(ctx, newcpu, VM_REG_GUEST_CS, &desc_base, &desc_limit, &desc_access); - assert(error == 0); desc_base = vector << PAGE_SHIFT; - error = vm_set_desc(ctx, newcpu, VM_REG_GUEST_CS, + vm_set_desc(ctx, newcpu, VM_REG_GUEST_CS, desc_base, desc_limit, desc_access); - assert(error == 0); cs = (vector << PAGE_SHIFT) >> 4; - error = vm_set_register(ctx, newcpu, VM_REG_GUEST_CS, cs); - assert(error == 0); + vm_set_register(ctx, newcpu, VM_REG_GUEST_CS, cs); } int spinup_ap(struct vmctx *ctx, int vcpu, int newcpu, uint64_t rip) { - int error; - assert(newcpu != 0); assert(newcpu < guest_ncpus); - error = vcpu_reset(ctx, newcpu); - assert(error == 0); + vcpu_reset(ctx, newcpu); fbsdrun_set_capabilities(ctx, newcpu); @@ -95,8 +88,7 @@ spinup_ap(struct vmctx *ctx, int vcpu, int newcpu, uint64_t rip) * Set up the processor state in power-on 16-bit mode, with the CS:IP * init'd to the specified low-mem 4K page. */ - error = vm_set_capability(ctx, newcpu, VM_CAP_UNRESTRICTED_GUEST, 1); - assert(error == 0); + vm_set_capability(ctx, newcpu, VM_CAP_UNRESTRICTED_GUEST, 1); spinup_ap_realmode(ctx, newcpu, &rip); diff --git a/usr.sbin/bhyve/task_switch.c b/usr.sbin/bhyve/task_switch.c index f1b564d560c..94ade46a18e 100644 --- a/usr.sbin/bhyve/task_switch.c +++ b/usr.sbin/bhyve/task_switch.c @@ -104,20 +104,16 @@ static uint64_t GETREG(struct vmctx *ctx, int vcpu, int reg) { uint64_t val; - int error; - error = vm_get_register(ctx, vcpu, reg, &val); - assert(error == 0); + vm_get_register(ctx, vcpu, reg, &val); return (val); } static void SETREG(struct vmctx *ctx, int vcpu, int reg, uint64_t val) { - int error; - error = vm_set_register(ctx, vcpu, reg, val); - assert(error == 0); + vm_set_register(ctx, vcpu, reg, val); } static struct seg_desc @@ -178,11 +174,10 @@ desc_table_limit_check(struct vmctx *ctx, int vcpu, uint16_t sel) { uint64_t base; uint32_t limit, access; - int error, reg; + int reg; reg = ISLDT(sel) ? VM_REG_GUEST_LDTR : VM_REG_GUEST_GDTR; - error = vm_get_desc(ctx, vcpu, reg, &base, &limit, &access); - assert(error == 0); + vm_get_desc(ctx, vcpu, reg, &base, &limit, &access); if (reg == VM_REG_GUEST_LDTR) { if (SEG_DESC_UNUSABLE(access) || !SEG_DESC_PRESENT(access)) @@ -470,10 +465,7 @@ tss32_save(struct vmctx *ctx, int vcpu, struct vm_task_switch *task_switch, static void update_seg_desc(struct vmctx *ctx, int vcpu, int reg, struct seg_desc *sd) { - int error; - - error = vm_set_desc(ctx, vcpu, reg, sd->base, sd->limit, sd->access); - assert(error == 0); + vm_set_desc(ctx, vcpu, reg, sd->base, sd->limit, sd->access); } /* @@ -714,7 +706,7 @@ vmexit_task_switch(struct vmctx *ctx, struct vm_exit *vmexit, int *pvcpu) struct iovec nt_iov[2], ot_iov[2]; uint64_t cr0, ot_base; uint32_t eip, ot_lim, access; - int error, ext, fault, minlimit, nt_type, ot_type, vcpu; + int error, ext, fault, minlimit, nt_type, vcpu; enum task_switch_reason reason; uint16_t nt_sel, ot_sel; @@ -818,8 +810,6 @@ vmexit_task_switch(struct vmctx *ctx, struct vm_exit *vmexit, int *pvcpu) &access); assert(error == 0); assert(!SEG_DESC_UNUSABLE(access) && SEG_DESC_PRESENT(access)); - ot_type = SEG_DESC_TYPE(access); - assert(ot_type == SDT_SYS386BSY || ot_type == SDT_SYS286BSY); /* Fetch the old TSS descriptor */ error = read_tss_descriptor(ctx, vcpu, task_switch, ot_sel, &ot_desc, diff --git a/usr.sbin/bhyve/uart_emul.c b/usr.sbin/bhyve/uart_emul.c index fd0ad2c846f..3e2f87a16a9 100644 --- a/usr.sbin/bhyve/uart_emul.c +++ b/usr.sbin/bhyve/uart_emul.c @@ -188,7 +188,6 @@ rxfifo_reset(struct uart_softc *sc, int size) char flushbuf[32]; struct fifo *fifo; ssize_t nread; - int error; fifo = &sc->rxfifo; bzero(fifo, sizeof(struct fifo)); @@ -208,8 +207,7 @@ rxfifo_reset(struct uart_softc *sc, int size) * Enable mevent to trigger when new characters are available * on the tty fd. */ - error = mevent_enable(sc->mev); - assert(error == 0); + mevent_enable(sc->mev); } } @@ -226,7 +224,6 @@ static int rxfifo_putchar(struct uart_softc *sc, uint8_t ch) { struct fifo *fifo; - int error; fifo = &sc->rxfifo; @@ -239,8 +236,7 @@ rxfifo_putchar(struct uart_softc *sc, uint8_t ch) /* * Disable mevent callback if the FIFO is full. */ - error = mevent_disable(sc->mev); - assert(error == 0); + mevent_disable(sc->mev); } } return (0); @@ -252,7 +248,7 @@ static int rxfifo_getchar(struct uart_softc *sc) { struct fifo *fifo; - int c, error, wasfull; + int c, wasfull; wasfull = 0; fifo = &sc->rxfifo; @@ -264,8 +260,7 @@ rxfifo_getchar(struct uart_softc *sc) fifo->num--; if (wasfull) { if (sc->tty.opened) { - error = mevent_enable(sc->mev); - assert(error == 0); + mevent_enable(sc->mev); } } return (c); diff --git a/usr.sbin/bhyve/vga.c b/usr.sbin/bhyve/vga.c index 24864f32e8b..1dde97422f9 100644 --- a/usr.sbin/bhyve/vga.c +++ b/usr.sbin/bhyve/vga.c @@ -1270,7 +1270,7 @@ vga_init(int io_only) { struct inout_port iop; struct vga_softc *sc; - int port, error; + int port; sc = calloc(1, sizeof(struct vga_softc)); @@ -1283,8 +1283,7 @@ vga_init(int io_only) iop.handler = vga_port_handler; iop.arg = sc; - error = register_inout(&iop); - assert(error == 0); + register_inout(&iop); } sc->gc_image = console_get_image(); @@ -1299,8 +1298,7 @@ vga_init(int io_only) sc->mr.size = 128 * KB; sc->mr.handler = vga_mem_handler; sc->mr.arg1 = sc; - error = register_mem_fallback(&sc->mr); - assert(error == 0); + register_mem_fallback(&sc->mr); sc->vga_ram = malloc(256 * KB); memset(sc->vga_ram, 0, 256 * KB); diff --git a/usr.sbin/bsdinstall/partedit/scripted.c b/usr.sbin/bsdinstall/partedit/scripted.c index 37ac6de131b..ae275663917 100644 --- a/usr.sbin/bsdinstall/partedit/scripted.c +++ b/usr.sbin/bsdinstall/partedit/scripted.c @@ -71,12 +71,11 @@ part_config(char *disk, const char *scheme, char *config) struct gclass *classp; struct gmesh mesh; struct ggeom *gpart = NULL; - int error; if (scheme == NULL) scheme = default_scheme(); - error = geom_gettree(&mesh); + geom_gettree(&mesh); if (provider_for_name(&mesh, disk) == NULL) { fprintf(stderr, "GEOM provider %s not found\n", disk); geom_deletetree(&mesh); @@ -107,7 +106,7 @@ part_config(char *disk, const char *scheme, char *config) } geom_deletetree(&mesh); - error = geom_gettree(&mesh); + geom_gettree(&mesh); /* Create partitions */ if (config == NULL) { @@ -133,7 +132,7 @@ part_config(char *disk, const char *scheme, char *config) gpart_create(provider_for_name(&mesh, disk), type, size, mount, NULL, 0); geom_deletetree(&mesh); - error = geom_gettree(&mesh); + geom_gettree(&mesh); size = type = mount = NULL; } diff --git a/usr.sbin/camdd/camdd.c b/usr.sbin/camdd/camdd.c index caf06ba9a59..337c48db6f2 100644 --- a/usr.sbin/camdd/camdd.c +++ b/usr.sbin/camdd/camdd.c @@ -2748,12 +2748,9 @@ bailout: int camdd_get_next_lba_len(struct camdd_dev *dev, uint64_t *lba, ssize_t *len) { - struct camdd_dev_pass *pass_dev; uint32_t num_blocks; int retval = 0; - pass_dev = &dev->dev_spec.pass; - *lba = dev->next_io_pos_bytes / dev->sector_size; *len = dev->blocksize; num_blocks = *len / dev->sector_size; @@ -2810,15 +2807,11 @@ camdd_queue(struct camdd_dev *dev, struct camdd_buf *read_buf) { struct camdd_buf *buf = NULL; struct camdd_buf_data *data; - struct camdd_dev_pass *pass_dev; size_t new_len; struct camdd_buf_data *rb_data; int is_write = dev->write_dev; int eof_flush_needed = 0; int retval = 0; - int error; - - pass_dev = &dev->dev_spec.pass; /* * If we've gotten EOF or our partner has, we should not continue @@ -2838,8 +2831,7 @@ camdd_queue(struct camdd_dev *dev, struct camdd_buf *read_buf) */ if (is_write) { read_buf->status = CAMDD_STATUS_EOF; - - error = camdd_complete_peer_buf(dev, read_buf); + camdd_complete_peer_buf(dev, read_buf); } goto bailout; } @@ -2908,7 +2900,7 @@ camdd_queue(struct camdd_dev *dev, struct camdd_buf *read_buf) if (len == 0) { dev->flags |= CAMDD_DEV_FLAG_EOF; - error = camdd_complete_peer_buf(dev, read_buf); + camdd_complete_peer_buf(dev, read_buf); goto bailout; } } @@ -3560,7 +3552,6 @@ int main(int argc, char **argv) { int c; - camdd_argmask arglist = CAMDD_ARG_NONE; int timeout = 0, retry_count = 1; int error = 0; uint64_t max_io = 0; @@ -3585,10 +3576,8 @@ main(int argc, char **argv) if (retry_count < 0) errx(1, "retry count %d is < 0", retry_count); - arglist |= CAMDD_ARG_RETRIES; break; case 'E': - arglist |= CAMDD_ARG_ERR_RECOVER; break; case 'i': case 'o': @@ -3618,10 +3607,6 @@ main(int argc, char **argv) errx(1, "invalid timeout %d", timeout); /* Convert the timeout from seconds to ms */ timeout *= 1000; - arglist |= CAMDD_ARG_TIMEOUT; - break; - case 'v': - arglist |= CAMDD_ARG_VERBOSE; break; case 'h': default: diff --git a/usr.sbin/efibootmgr/efibootmgr.c b/usr.sbin/efibootmgr/efibootmgr.c index 53bc417c4e0..75c8592eb07 100644 --- a/usr.sbin/efibootmgr/efibootmgr.c +++ b/usr.sbin/efibootmgr/efibootmgr.c @@ -996,7 +996,7 @@ report_esp_device(bool do_dp, bool do_unix) char *name, *dev, *relpath, *abspath; uint8_t *walker, *ep; efi_char *descr; - efidp dp, edp; + efidp dp; char buf[PATH_MAX]; if (do_dp && do_unix) @@ -1026,7 +1026,6 @@ report_esp_device(bool do_dp, bool do_unix) // Now we have fplen bytes worth of file path stuff dp = (efidp)walker; walker += fplen; - edp = (efidp)walker; if (walker > ep) errx(1, "malformed boot variable %s", name); if (do_dp) { diff --git a/usr.sbin/efidp/efidp.c b/usr.sbin/efidp/efidp.c index aef154112d6..96769402438 100644 --- a/usr.sbin/efidp/efidp.c +++ b/usr.sbin/efidp/efidp.c @@ -169,14 +169,13 @@ efi_to_unix(void) char buffer[MAXSIZE]; char dpbuf[MAXSIZE]; efidp dp; - size_t dplen; char *walker, *dev, *relpath, *abspath; int rv; dp = (efidp)dpbuf; while (fgets(buffer, sizeof(buffer), stdin)) { walker= trim(buffer); - dplen = efidp_parse_device_path(walker, dp, sizeof(dpbuf)); + efidp_parse_device_path(walker, dp, sizeof(dpbuf)); rv = efivar_device_path_to_unix_path(dp, &dev, &relpath, &abspath); if (rv == 0) printf("%s:%s %s\n", dev, relpath, abspath); diff --git a/usr.sbin/fifolog/fifolog_reader/fifolog_reader.c b/usr.sbin/fifolog/fifolog_reader/fifolog_reader.c index 7d6fdbff214..c7485ee23d8 100644 --- a/usr.sbin/fifolog/fifolog_reader/fifolog_reader.c +++ b/usr.sbin/fifolog/fifolog_reader/fifolog_reader.c @@ -54,7 +54,6 @@ Render(void *priv __unused, time_t now, unsigned flag __unused, const unsigned c { static struct tm utc; char buf[128]; - int i; if (now < opt_B || now > opt_E) return; @@ -66,8 +65,7 @@ Render(void *priv __unused, time_t now, unsigned flag __unused, const unsigned c fprintf(fo, "%s\n", p); } else if (opt_T != NULL) { (void)gmtime_r(&now, &utc); - i = strftime(buf, sizeof buf, opt_T, &utc); - assert(i > 0); + strftime(buf, sizeof buf, opt_T, &utc); fprintf(fo, "%s %s\n", buf, p); } else { fprintf(fo, "%12ld %s\n", (long)now, p); diff --git a/usr.sbin/fifolog/lib/fifolog_int.c b/usr.sbin/fifolog/lib/fifolog_int.c index d22bd4745e4..19d61c8b7c5 100644 --- a/usr.sbin/fifolog/lib/fifolog_int.c +++ b/usr.sbin/fifolog/lib/fifolog_int.c @@ -178,7 +178,7 @@ fifolog_int_close(struct fifolog_file **ff) } static void -fifolog_int_file_assert(const struct fifolog_file *ff) +fifolog_int_file_assert(const struct fifolog_file *ff __unused) { CHECK_OBJ_NOTNULL(ff, FIFOLOG_FILE_MAGIC); diff --git a/usr.sbin/fifolog/lib/fifolog_reader.c b/usr.sbin/fifolog/lib/fifolog_reader.c index 1ef6a4e2048..7627dad117d 100644 --- a/usr.sbin/fifolog/lib/fifolog_reader.c +++ b/usr.sbin/fifolog/lib/fifolog_reader.c @@ -59,7 +59,6 @@ fifolog_reader_open(const char *fname) { const char *retval; struct fifolog_reader *fr; - int i; fr = calloc(1, sizeof(*fr)); if (fr == NULL) @@ -74,8 +73,7 @@ fifolog_reader_open(const char *fname) err(1, "Cannot malloc"); fr->olen = fr->ff->recsize * 16; - i = inflateInit(fr->ff->zs); - assert(i == Z_OK); + inflateInit(fr->ff->zs); fr->magic = FIFOLOG_READER_MAGIC; return (fr); diff --git a/usr.sbin/fifolog/lib/fifolog_write_poll.c b/usr.sbin/fifolog/lib/fifolog_write_poll.c index cffe095d4d7..a581df6fbc6 100644 --- a/usr.sbin/fifolog/lib/fifolog_write_poll.c +++ b/usr.sbin/fifolog/lib/fifolog_write_poll.c @@ -65,7 +65,7 @@ const char *fifolog_write_statnames[] = { * Check that everything is all right */ static void -fifolog_write_assert(const struct fifolog_writer *f) +fifolog_write_assert(const struct fifolog_writer *f __unused) { CHECK_OBJ_NOTNULL(f, FIFOLOG_WRITER_MAGIC); diff --git a/usr.sbin/fifolog/lib/getdate.y b/usr.sbin/fifolog/lib/getdate.y index 53a515c4d17..02357b24c56 100644 --- a/usr.sbin/fifolog/lib/getdate.y +++ b/usr.sbin/fifolog/lib/getdate.y @@ -816,26 +816,15 @@ yylex(void) time_t get_date(char *p) { - struct tm *tm, gmt; + struct tm *tm; time_t Start; time_t tod; time_t nowtime; - struct tm *gmt_ptr; yyInput = p; (void)time (&nowtime); - gmt_ptr = gmtime (&nowtime); - if (gmt_ptr != NULL) - { - /* Make a copy, in case localtime modifies *tm (I think - that comment now applies to *gmt_ptr, but I am too - lazy to dig into how gmtime and locatime allocate the - structures they return pointers to). */ - gmt = *gmt_ptr; - } - if (! (tm = localtime (&nowtime))) return -1; diff --git a/usr.sbin/fwcontrol/fwdv.c b/usr.sbin/fwcontrol/fwdv.c index 2baf1c43c80..cb821891821 100644 --- a/usr.sbin/fwcontrol/fwdv.c +++ b/usr.sbin/fwcontrol/fwdv.c @@ -262,7 +262,7 @@ dvsend(int d, const char *filename, char ich, int count) struct dvdbc *dv; struct fw_pkt *pkt; int len, tlen, header, fd, frames, packets, vec, offset, nhdr, i; - int system=-1, pad_acc, cycle_acc, cycle, f_cycle, f_frac; + int system=-1, pad_acc, cycle_acc, cycle, f_frac; struct iovec wbuf[TNBUF*2 + NEMPTY]; char *pbuf; u_int32_t iso_data, iso_empty, hdr[TNBUF + NEMPTY][3]; @@ -363,10 +363,10 @@ next: if (frames % frame_rate[system] == 0) fprintf(stderr, "\n"); fflush(stderr); - f_cycle = (cycle_acc / frame_cycle[system].d) & 0xf; f_frac = (cycle_acc % frame_cycle[system].d * CYCLE_FRAC) / frame_cycle[system].d; #if 0 + int f_cycle = (cycle_acc / frame_cycle[system].d) & 0xf; ciph->fdf.dv.cyc = htons(f_cycle << 12 | f_frac); #else ciph->fdf.dv.cyc = htons(cycle << 12 | f_frac); diff --git a/usr.sbin/makefs/msdos.c b/usr.sbin/makefs/msdos.c index a0e0f7174f2..23fa200d3e5 100644 --- a/usr.sbin/makefs/msdos.c +++ b/usr.sbin/makefs/msdos.c @@ -149,7 +149,6 @@ msdos_makefs(const char *image, const char *dir, fsnode *root, fsinfo_t *fsopts) struct vnode vp, rootvp; struct timeval start; struct msdosfsmount *pmp; - uint32_t flags; assert(image != NULL); assert(dir != NULL); @@ -183,7 +182,6 @@ msdos_makefs(const char *image, const char *dir, fsnode *root, fsinfo_t *fsopts) fsopts->fd = open(image, O_RDWR); vp.fs = fsopts; - flags = 0; if ((pmp = msdosfs_mount(&vp)) == NULL) err(1, "msdosfs_mount"); diff --git a/usr.sbin/makefs/msdos/msdosfs_vfsops.c b/usr.sbin/makefs/msdos/msdosfs_vfsops.c index 4a5c658b794..fa4855597d7 100644 --- a/usr.sbin/makefs/msdos/msdosfs_vfsops.c +++ b/usr.sbin/makefs/msdos/msdosfs_vfsops.c @@ -87,7 +87,6 @@ msdosfs_mount(struct vnode *devvp) struct byte_bpb710 *b710; uint8_t SecPerClust; int ronly = 0, error; - int bsize; unsigned secsize = 512; MSDOSFS_DPRINTF(("%s(bread 0)\n", __func__)); @@ -107,7 +106,6 @@ msdosfs_mount(struct vnode *devvp) error = EINVAL; goto error_exit; } - bsize = 0; pmp = ecalloc(1, sizeof(*pmp)); /* diff --git a/usr.sbin/mpsutil/mps_debug.c b/usr.sbin/mpsutil/mps_debug.c index 4c462ef65f6..83315090d73 100644 --- a/usr.sbin/mpsutil/mps_debug.c +++ b/usr.sbin/mpsutil/mps_debug.c @@ -136,11 +136,9 @@ print_sgl(char *buf, int offset, int numframes) { MPI2_SGE_SIMPLE64 *sge; MPI2_SGE_CHAIN_UNION *sgc; - MPI2_REQUEST_HEADER *req; u_int i = 0, flags; char *frame, tmpbuf[128]; - req = (MPI2_REQUEST_HEADER *)buf; frame = (char *)buf; sge = (MPI2_SGE_SIMPLE64 *)&frame[offset * 4]; printf("SGL for command\n"); diff --git a/usr.sbin/mptable/mptable.c b/usr.sbin/mptable/mptable.c index 6c5efee766b..e8be110dfb1 100644 --- a/usr.sbin/mptable/mptable.c +++ b/usr.sbin/mptable/mptable.c @@ -530,7 +530,6 @@ MPConfigTableHeader( u_int32_t pap ) { mpcth_t cth; int x; - int totalSize; int c; int oldtype, entrytype; u_int8_t *entry; @@ -574,8 +573,6 @@ MPConfigTableHeader( u_int32_t pap ) printf( " extended table length:\t%d\n", cth->extended_table_length ); printf( " extended table checksum:\t%d\n", cth->extended_table_checksum ); - totalSize = cth->base_table_length - sizeof( struct MPCTH ); - puts( SEP_LINE ); printf( "MP Config Base Table Entries:\n\n" ); diff --git a/usr.sbin/pmc/cmd_pmc_filter.cc b/usr.sbin/pmc/cmd_pmc_filter.cc index 07027cb272f..7f2fae6d208 100644 --- a/usr.sbin/pmc/cmd_pmc_filter.cc +++ b/usr.sbin/pmc/cmd_pmc_filter.cc @@ -208,7 +208,7 @@ pmc_filter_handler(uint32_t *lwplist, int lwpcount, uint32_t *pidlist, int pidco char cpuid[PMC_CPUID_LEN]; char *proclist[LIST_MAX]; char *threadlist[LIST_MAX]; - int i, pmccount, copies, eventcount; + int i, pmccount, eventcount; int proccount, threadcount; uint32_t idx; idmap pidmap, tidmap; @@ -247,7 +247,6 @@ pmc_filter_handler(uint32_t *lwplist, int lwpcount, uint32_t *pidlist, int pidco pmclog_close(ps); if ((ps = static_cast < struct pmclog_parse_state *>(pmclog_open(infd)))== NULL) errx(EX_OSERR, "ERROR: Cannot allocate pmclog parse state: %s\n", strerror(errno)); - copies = 0; while (pmclog_read(ps, &ev) == 0) { if (ev.pl_type == PMCLOG_TYPE_THR_CREATE) tidmap[ev.pl_u.pl_tc.pl_tid] = ev.pl_u.pl_tc.pl_tdname; diff --git a/usr.sbin/pw/pw_user.c b/usr.sbin/pw/pw_user.c index 2eec317b5e5..5041dd74b5c 100644 --- a/usr.sbin/pw/pw_user.c +++ b/usr.sbin/pw/pw_user.c @@ -493,7 +493,6 @@ pw_pwcrypt(char *password) char salt[SALTSIZE + 1]; char *cryptpw; static char buf[256]; - size_t pwlen; /* * Calculate a salt value @@ -505,8 +504,7 @@ pw_pwcrypt(char *password) cryptpw = crypt(password, salt); if (cryptpw == NULL) errx(EX_CONFIG, "crypt(3) failure"); - pwlen = strlcpy(buf, cryptpw, sizeof(buf)); - assert(pwlen < sizeof(buf)); + strlcpy(buf, cryptpw, sizeof(buf)); return (buf); } diff --git a/usr.sbin/rpc.lockd/kern.c b/usr.sbin/rpc.lockd/kern.c index 08566a5b465..b25ca828fa2 100644 --- a/usr.sbin/rpc.lockd/kern.c +++ b/usr.sbin/rpc.lockd/kern.c @@ -572,16 +572,11 @@ void show(LOCKD_MSG *mp) { static char hex[] = "0123456789abcdef"; - struct fid *fidp; - fsid_t *fsidp; size_t len; u_int8_t *p, *t, buf[NFS_SMALLFH*3+1]; syslog(LOG_DEBUG, "process ID: %lu\n", (long)mp->lm_msg_ident.pid); - fsidp = (fsid_t *)&mp->lm_fh; - fidp = (struct fid *)((u_int8_t *)&mp->lm_fh + sizeof(fsid_t)); - for (t = buf, p = (u_int8_t *)mp->lm_fh, len = mp->lm_fh_len; len > 0; ++p, --len) { diff --git a/usr.sbin/rpc.tlsservd/rpc.tlsservd.c b/usr.sbin/rpc.tlsservd/rpc.tlsservd.c index 71787b162ac..db829be6833 100644 --- a/usr.sbin/rpc.tlsservd/rpc.tlsservd.c +++ b/usr.sbin/rpc.tlsservd/rpc.tlsservd.c @@ -142,7 +142,7 @@ main(int argc, char **argv) * TLS handshake. */ struct sockaddr_un sun; - int ch, debug, fd, oldmask; + int ch, fd, oldmask; SVCXPRT *xprt; struct timeval tm; struct timezone tz; @@ -177,7 +177,6 @@ main(int argc, char **argv) rpctls_dnsname = hostname; } - debug = 0; rpctls_verbose = false; while ((ch = getopt_long(argc, argv, "D:dhl:n:mp:r:uvWw", longopts, NULL)) != -1) { diff --git a/usr.sbin/rrenumd/parser.y b/usr.sbin/rrenumd/parser.y index 43d08634d43..c75dde23df3 100644 --- a/usr.sbin/rrenumd/parser.y +++ b/usr.sbin/rrenumd/parser.y @@ -335,10 +335,8 @@ rrenum_statement: match_prefix_definition: rrenum_cmd MATCH_PREFIX_CMD prefixval maxlen minlen { - struct icmp6_router_renum *irr; struct rr_pco_match *rpm; - irr = &ple_cur.pl_irr; rpm = &ple_cur.pl_rpm; memset(rpm, 0, sizeof(*rpm)); --MP_/wQ+F2DVnjFSjsXA5CnSTh.G-- From nobody Fri Dec 10 09:11:07 2021 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 EB61818EB9E0 for ; Fri, 10 Dec 2021 09:11:46 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9QBn2JQ5z4gkn for ; Fri, 10 Dec 2021 09:11:45 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.16.1/8.16.1) with ESMTPS id 1BA9BTxd070568 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 10 Dec 2021 19:41:38 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1639127502; bh=O80sQHf5dx1eBdwdsPwhd3jW0KEzSbI3ymjhQVYTHnk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=KVCgGdAUgoFZM6ML/y0yvJtD4UB4nWX+UkWbzxjCkBocN0YnAEbw7C3zjcfiLGNaA dc8WZSUmkqPuDvX3Cj3P7fUP1aBh3//fIiP67/Fh37j7Qb1zo+TJCHxuX45vAVt3r9 qhCwqPHeDow8z/n2ceqvJOFFX7q88eFTo/0RXFL0= Received: (from mailnull@localhost) by midget.dons.net.au (8.16.1/8.16.1/Submit) id 1BA9B7L3070535 for ; Fri, 10 Dec 2021 19:41:07 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-f0f0b4ff001831caa5b8ac39868c4c7e9b4d12fc: 2403:5800:5200:4700:792f:b02:6699:af48 Received: from smtpclient.apple (2403-5800-5200-4700-792f-b02-6699-af48.ip6.aussiebb.net [2403:5800:5200:4700:792f:b02:6699:af48]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 1BA9B7if070530; Fri, 10 Dec 2021 19:41:07 +1030 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 14.0 \(3654.120.0.1.13\)) Subject: Re: CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23) In-Reply-To: <20211125092054.4696b6f2@hermann> Date: Fri, 10 Dec 2021 19:41:07 +1030 Cc: FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211125092054.4696b6f2@hermann> To: FreeBSD User X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Spam-Score: 0.8 () No, score=0.8 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4J9QBn2JQ5z4gkn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=KVCgGdAU; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[] Reply-To: darius@dons.net.au From: Daniel O'Connor via freebsd-current X-Original-From: Daniel O'Connor X-ThisMailContainsUnwantedMimeParts: N > On 25 Nov 2021, at 18:50, FreeBSD User wrote: >=20 > Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: = Mon Nov 22 18:17:54 > CET 2021 amd64) troubles me with our DNS server/service. > Aproximately the same time we switched on CURRENT to the CURRENT = LLVM13 version and also, > after the compilation of a fresh OS with LLVM13, the upgrade from = bind-9.16.22 to > bind-9.16.23 took place as well as ASLR being the default. >=20 > Since then named is crashing with a mysterious segmentation fault (see = PR 259921, > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259921). >=20 > Disabling ASLR as recommended to check whether ASLR triggers the = SegFault did not solve > the problem, so I suspect a miscompilation due to llvm13. >=20 > On 13-STABLE bind-9.16.23 seem not to have this behaviour. >=20 > I'm floating like a dead man in the water, can someone help? lang/sdcc also seg faults = (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260303), although = there disabling ASLR via proccontrol does fix it. Can you show a stacktrace for your seg fault? -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Fri Dec 10 09:15:33 2021 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 1704918ED108 for ; Fri, 10 Dec 2021 09:16:34 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9QJK0pDyz4hfS for ; Fri, 10 Dec 2021 09:16:32 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.16.1/8.16.1) with ESMTPS id 1BA9FxqW074227 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 10 Dec 2021 19:46:25 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1639127790; bh=rCdDbmzOgsqHWb5Z8Ow1/1fnNEeb46uGotV+zpwGjzE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=d8KJrMOTF1mEFu1Q1epRnH97goTIZtsuWsqPJsK4sjvAC+YcPIUwDUMwPXNfAUU9x K1e4ljdMWNrDJA4NWmUF+w6xTKqPcMakdHPJVPg1Eg+u9LoDCHIWOl7t5vxC5Yl2LW k5oDS1OI/R5NitQbIO5fPpTvRGE4Sle3JM6vpGA0= Received: (from mailnull@localhost) by midget.dons.net.au (8.16.1/8.16.1/Submit) id 1BA9FYrj074196 for ; Fri, 10 Dec 2021 19:45:34 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-f0f0b4ff001831caa5b8ac39868c4c7e9b4d12fc: 2403:5800:5200:4700:792f:b02:6699:af48 Received: from smtpclient.apple (2403-5800-5200-4700-792f-b02-6699-af48.ip6.aussiebb.net [2403:5800:5200:4700:792f:b02:6699:af48]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 1BA9FYOW074187; Fri, 10 Dec 2021 19:45:34 +1030 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 14.0 \(3654.120.0.1.13\)) Subject: Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main In-Reply-To: Date: Fri, 10 Dec 2021 19:45:33 +1030 Cc: freebsd-current@freebsd.org, Fabien Thomas , MARECHAL Boris , Rafal Jaworowski , Damien DEVILLE Content-Transfer-Encoding: quoted-printable Message-Id: <7101CA73-DCAD-4DEF-9861-C62789D22596@dons.net.au> References: To: Marcin Wojtas X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Spam-Score: 0.8 () No, score=0.8 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4J9QJK0pDyz4hfS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=d8KJrMOT; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-2.63 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-0.17)[-0.170]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[] Reply-To: darius@dons.net.au From: Daniel O'Connor via freebsd-current X-Original-From: Daniel O'Connor X-ThisMailContainsUnwantedMimeParts: N > On 17 Nov 2021, at 09:00, Marcin Wojtas wrote: > As of b014e0f15bc7 the ASLR (Address Space Layout > Randomization) feature becomes enabled for the all 64-bit > binaries by default. Firstly, thank your for your efforts here, it is appreciated :) I am finding that the lang/sdcc port is crashing with a seg fault and = the core dump is no help to me at all: [freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo = gdb ../../bin/sdcc sdcc.core GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] Reading symbols from ../../bin/sdcc... [New LWP 100122] Core was generated by `../../bin/sdcc -I../../device/include = -I../../device/include/mcs51 -mds390 --nos'. Program terminated with signal SIGSEGV, Segmentation fault. Invalid permissions for mapped object. #0 0x0000000804e3fbc0 in setrlimit () from /lib/libc.so.7 (gdb) info thread Id Target Id Frame * 1 LWP 100122 0x0000000804e3fbc0 in setrlimit () from = /lib/libc.so.7 (gdb) bt #0 0x0000000804e3fbc0 in setrlimit () from /lib/libc.so.7 Backtrace stopped: Cannot access memory at address 0x7fffff87fd08 If I disable ASLR (via proccontrol) then it does not crash, but I am not = sure how I can debug it further. I've raised a bug = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260303 if you (or = anyone else) has suggestions for what to try. Thanks. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Fri Dec 10 15:50:44 2021 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 DE31718CD84E for ; Fri, 10 Dec 2021 15:50:57 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9b3P3ccCz4qm5 for ; Fri, 10 Dec 2021 15:50:57 +0000 (UTC) (envelope-from 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 1BAFoiCl087612 for ; Fri, 10 Dec 2021 07:50:50 -0800 (PST) (envelope-from bsd-lists@bsdforge.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 Date: Fri, 10 Dec 2021 07:50:44 -0800 From: Chris To: freebsd-current@freebsd.org Subject: Re: 14-current: unable to boot after upgrade (installworld) In-Reply-To: <20211209163610.0cc4f7c6@gmail.com> References: <20211209163610.0cc4f7c6@gmail.com> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J9b3P3ccCz4qm5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N On 2021-12-09 05:36, Sergey V. Dyatko wrote: > Hi, > > Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh > 14-current from git,it looked like this: > 1) git pull https://git.freebsd.org/src.git /usr/src > 2) cd /usr/src ; make buildworld; make kernel Not sure you didn't actually do this. But it appears that you omitted a: make install kernel here. > 3) shutdown -r now > after that I _successfully_ booted into 14-current and continued with > etcupdate -p > make installworld > etcupdate -B > shutdown -r now > > but after that server doesn't come back. After I conneted to this server via > IPMI ip-kvm I saw following (sorry for external link): > https://i.imgur.com/jH6MHd2.png > > Well. There was a migration to zol between r368473 and current 'main' branch > so > I decided to install fresh 14-current from snapshot > FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid > possible problems > > and again, after make kernel and reboot OS runs, but after installworld I > ended up > in the same situation > > thoughts ? > > -- > wbr, Sergey From nobody Fri Dec 10 16:01:48 2021 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 D1E4818D04C0 for ; Fri, 10 Dec 2021 16:02:00 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9bJ83JYDz4sR7; Fri, 10 Dec 2021 16:02:00 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id ccb804d9; Fri, 10 Dec 2021 16:01:51 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 26b412b1 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Fri, 10 Dec 2021 16:01:49 +0000 (UTC) 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 (1.0) Subject: Re: 14-current: unable to boot after upgrade (installworld) From: Michael Gmelin In-Reply-To: Date: Fri, 10 Dec 2021 17:01:48 +0100 Cc: freebsd-current@freebsd.org Message-Id: References: To: Chris X-Mailer: iPhone Mail (18H107) X-Rspamd-Queue-Id: 4J9bJ83JYDz4sR7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 10. Dec 2021, at 16:57, Chris wrote: >=20 > =EF=BB=BFOn 2021-12-09 05:36, Sergey V. Dyatko wrote: >> Hi, >> Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh >> 14-current from git,it looked like this: >> 1) git pull https://git.freebsd.org/src.git /usr/src >> 2) cd /usr/src ; make buildworld; make kernel > Not sure you didn't actually do this. But it appears that you omitted a: > make install kernel > here. `make kernel` does buildkernel and installkernel. -m >> 3) shutdown -r now >> after that I _successfully_ booted into 14-current and continued with >> etcupdate -p >> make installworld >> etcupdate -B >> shutdown -r now >> but after that server doesn't come back. After I conneted to this server v= ia >> IPMI ip-kvm I saw following (sorry for external link): >> https://i.imgur.com/jH6MHd2.png >> Well. There was a migration to zol between r368473 and current 'main' bra= nch so >> I decided to install fresh 14-current from snapshot >> FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid >> possible problems >> and again, after make kernel and reboot OS runs, but after installworld I= ended up >> in the same situation >> thoughts ? >> -- >> wbr, Sergey From nobody Fri Dec 10 16:24:05 2021 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 7189918D596C for ; Fri, 10 Dec 2021 16:24:12 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9bnl5CjYz3Crc for ; Fri, 10 Dec 2021 16:24:11 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To: From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Qt9r3ZmXyIleBwrlZtdkOn699z5fvKDPDWdPnxgk7LU=; b=dOqqLWrZevHGiTQvpPVDlPwe58 feQO6PFAAB56mzpMVpO9VSRTL3bF9wNO8znZZwmiqOjK+fA/Zld5KjmSXsYHu+KYsYKUyHp04KQ1m gr+20J6S9CwtyHwt2a3I+gY3Lxkumgb+SHeNt24xB7U7rQdeerw8jMsn8ySwkgcsN7GQwHJrFZh08 UFi3Eloj7yGdGTY89ZWspCsFfdyd78porsPUylfkkrPBaJLXSqqd0A7VsLK1M89KdVkB9hcnC3qCU xpTuEy7iA83KTgWrS6dPHFx9iEq3beCCikcUAtHDAn+VqpuIiiXenSboKVcCLDjd+KWOKJxDwUrGP lrYEObNw==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:61879 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mvign-00018r-BL for freebsd-current@freebsd.org; Fri, 10 Dec 2021 10:24:05 -0600 Received: from 76-250-255-117.lightspeed.austtx.sbcglobal.net ([76.250.255.117]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 10 Dec 2021 10:24:05 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Fri, 10 Dec 2021 10:24:05 -0600 From: Larry Rosenman To: Freebsd current Subject: Panic: Page Fault in Kernel: Yesterday's CURRENT Message-ID: <3d1b5249a2c51670de496fad9e8b054c@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J9bnl5CjYz3Crc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=dOqqLWrZ; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.01 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.99)[0.989]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15 main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021 root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL amd64 VMCORE *IS* available. Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 20 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff804e0db4 stack pointer = 0x0:0xfffffe0434de4e10 frame pointer = 0x0:0xfffffe0434de4e70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 82990 (c++) trap number = 12 panic: page fault cpuid = 0 time = 1639111198 KDB: stack backtrace: #0 0xffffffff8050fc95 at kdb_backtrace+0x65 #1 0xffffffff804c468f at vpanic+0x17f #2 0xffffffff804c4503 at panic+0x43 #3 0xffffffff807a2195 at trap_fatal+0x385 #4 0xffffffff807a21ef at trap_pfault+0x4f #5 0xffffffff80779c78 at calltrap+0x8 #6 0xffffffff8045ddb8 at handleevents+0x188 #7 0xffffffff8045ea3e at timercb+0x24e #8 0xffffffff807ca9eb at lapic_handle_timer+0x9b #9 0xffffffff8077b9b1 at Xtimerint+0xb1 Uptime: 2h28m57s Dumping 12829 out of 131023 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff804c428c in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:487 #3 0xffffffff804c46fe in vpanic (fmt=0xffffffff807e1276 "%s", ap=) at /usr/src/sys/kern/kern_shutdown.c:920 #4 0xffffffff804c4503 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:844 #5 0xffffffff807a2195 in trap_fatal (frame=0xfffffe0434de4d50, eva=0) at /usr/src/sys/amd64/amd64/trap.c:946 #6 0xffffffff807a21ef in trap_pfault (frame=0xfffffe0434de4d50, usermode=false, signo=, ucode=) at /usr/src/sys/amd64/amd64/trap.c:765 #7 #8 0xffffffff804e0db4 in callout_process (now=now@entry=38385536922300) at /usr/src/sys/kern/kern_timeout.c:488 #9 0xffffffff8045ddb8 in handleevents (now=now@entry=38385536922300, fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 #10 0xffffffff8045ea3e in timercb (et=0xffffffff80d475e0 , arg=) at /usr/src/sys/kern/kern_clocksource.c:357 #11 0xffffffff807ca9eb in lapic_handle_timer (frame=0xfffffe0434de4f40) at /usr/src/sys/x86/x86/local_apic.c:1364 #12 #13 0x000000080df42bb6 in ?? () Backtrace stopped: Cannot access memory at address 0x7ffffdef2c90 (kgdb) ------------------------------------------------------------------------ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Fri Dec 10 16:29:22 2021 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 6068618D7251 for ; Fri, 10 Dec 2021 16:29:33 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st43p00im-zteg10073501.me.com (st43p00im-zteg10073501.me.com [17.58.63.180]) (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 4J9bvw5T1pz3FL6 for ; Fri, 10 Dec 2021 16:29:32 +0000 (UTC) (envelope-from tsoome@me.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1639153766; bh=Eqyt6KfktXxqkQZBG94jE92tFAvaWkXWprXBI/uQOD8=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=d7SFYERwXXhD6P76nBcLtMGY2pBHOwtYbJSPGGBaeq3V24a6CTi/GvO0P9C97caQT j4/22AtzacAwTG11SwAG/3pbNSi65L3HL0GV/xzhLUH+oIcHNU3MwEf1Oa+0HEt0AD 4ViWc3uhdsEENQGhyzTnJwd5ieVBWuegktqkBeWSRrLV7EoIyK6g0x+PlxaOGViqx4 PeOI5m6eX6s1rBZOT0WYtvVRiztyiks2dTitWVQPw7uQSf+jIJVU6FttgzZ2KcLhmp tXcGVV0CV7f32SvtxkiF4oer4AxKR+2quSbz8ZhnNaD4MtxGiW4DdS8fZLemRXesCA jeiqJjOYCSpbQ== Received: from smtpclient.apple (148-52-235-80.sta.estpak.ee [80.235.52.148]) by st43p00im-zteg10073501.me.com (Postfix) with ESMTPSA id D3102AE03BB; Fri, 10 Dec 2021 16:29:25 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: 14-current: unable to boot after upgrade (installworld) In-Reply-To: Date: Fri, 10 Dec 2021 18:29:22 +0200 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <7BA117CA-0FC0-4BC9-BD50-9958C0A62573@me.com> References: <20211209163610.0cc4f7c6@gmail.com> <20211209235807.31ee2ecea5bc08e243870da3@dec.sakura.ne.jp> <13846D48-70DF-47FD-B2DA-187A33F0F5C0@me.com> To: Sergey Dyatko X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.790 definitions=2021-12-10_06:2021-12-09,2021-12-10 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2009150000 definitions=main-2112100094 X-Rspamd-Queue-Id: 4J9bvw5T1pz3FL6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] Reply-To: tsoome@me.com From: Toomas Soome via freebsd-current X-Original-From: Toomas Soome X-ThisMailContainsUnwantedMimeParts: N > On 9. Dec 2021, at 20:54, Sergey Dyatko = wrote: >=20 > tiger@dl:~ % gpart show >=20 > | > =3D> 40 3907029088 da4 GPT (1.8T) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 3907026944 2 freebsd-zfs (1.8T) > 3907028992 136 - free - (68K) >=20 > =3D> 40 3907029088 da5 GPT (1.8T) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 3907026944 2 freebsd-zfs (1.8T) > 3907028992 136 - free - (68K) >=20 > =3D> 40 3907029088 da6 GPT (1.8T) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 3907026944 2 freebsd-zfs (1.8T) > 3907028992 136 - free - (68K) >=20 > =3D> 40 3907029088 da7 GPT (1.8T) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 3907026944 2 freebsd-zfs (1.8T) > 3907028992 136 - free - (68K) >=20 > i'm not sure about video, everything happens faster than I can see :-) = but > sometimes the system does not freeze and I can enter commands. Can = this > help in some way? >=20 maybe, maybe not; from one hand, BTX register dump may help us to = identify possible location or give other clues - eip=3D0000004c from = your screenshot is telling us that some structure with function pointers = must have been corrupted, seems like NULL pointer derefernce caused by = this corruption. So the investigation should try to identify what is = causing such corruption=E2=80=A6.=20 Since it was booting before, does the old loader start? I see the iKVM = windo does have record menu entry, can it be used to record whole = incident? rgds, toomas > =D1=87=D1=82, 9 =D0=B4=D0=B5=D0=BA. 2021 =D0=B3. =D0=B2 18:19, Toomas = Soome : >=20 >>=20 >>=20 >>> On 9. Dec 2021, at 20:06, Sergey Dyatko = wrote: >>>=20 >>> I was sure the installer did it when I reinstalled the system from >> scratch. I >>> can load 14-current successfully after boot via PXE and installworld = with >>> 13-current >>> now I did the following: >>> 1) boot from HDDs FreeBSD 14.0-CURRENT #0 main-n251494-f953785b3df = (with >>> 'old' world) >>> 2)run installworld (f953785b3df) >>> 3) run `gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 = da${D}` >>> command , where D=3D4..7 >>> root@dl:/usr/src # zpool status >>> pool: zroot >>> state: ONLINE >>> config: >>>=20 >>> NAME STATE READ WRITE CKSUM >>> zroot ONLINE 0 0 0 >>> mirror-0 ONLINE 0 0 0 >>> da4p2 ONLINE 0 0 0 >>> da5p2 ONLINE 0 0 0 >>> mirror-1 ONLINE 0 0 0 >>> da6p2 ONLINE 0 0 0 >>> da7p2 ONLINE 0 0 0 >>> errors: No known data errors >>>=20 >>> after `shutdown -r now` system still doesn't boot with the same = error. >> As >>> far I can see, there is /boot/lua/config.lua present, but when I try = to >> run >>> command more /boot/lua/config.lua system hangs with following error: >>> https://imgur.com/5p0xu6W.png >>>=20 >>=20 >> You seem to get 2x BTX panic, could you try to create video from = console, >> so we could get register dumps? >>=20 >> can this system do UEFI boot and if so, can you test it? Could you = post >> partition tables? >>=20 >> rgds, >> toomas >>=20 >>=20 >>>=20 >>> =D1=87=D1=82, 9 =D0=B4=D0=B5=D0=BA. 2021 =D0=B3. =D0=B2 15:56, = Warner Losh : >>>=20 >>>> On Thu, Dec 9, 2021 at 7:58 AM Tomoaki AOKI = >>>> wrote: >>>>=20 >>>>> On Thu, 9 Dec 2021 13:36:10 +0000 >>>>> "Sergey V. Dyatko" wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Yesterday I tried to upgrade old 13-current (svn rev r368473) to = fresh >>>>>> 14-current from git,it looked like this: >>>>>> 1) git pull https://git.freebsd.org/src.git /usr/src >>>>>> 2) cd /usr/src ; make buildworld; make kernel >>>>>> 3) shutdown -r now >>>>>> after that I _successfully_ booted into 14-current and continued = with >>>>>> etcupdate -p >>>>>> make installworld >>>>>> etcupdate -B >>>>>> shutdown -r now >>>>>>=20 >>>>>> but after that server doesn't come back. After I conneted to this >>>> server >>>>> via >>>>>> IPMI ip-kvm I saw following (sorry for external link): >>>>>> https://i.imgur.com/jH6MHd2.png >>>>>>=20 >>>>>> Well. There was a migration to zol between r368473 and current = 'main' >>>>> branch so >>>>>> I decided to install fresh 14-current from snapshot >>>>>> FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order = to >>>> avoid >>>>>> possible problems >>>>>>=20 >>>>>> and again, after make kernel and reboot OS runs, but after >> installworld >>>>> I ended up in the same situation >>>>>>=20 >>>>>> thoughts ? >>>>>>=20 >>>>>> -- >>>>>> wbr, Sergey >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> Bootcode should be updated. >>>>> The procedure you wrote doesn't seem to update it. >>>>>=20 >>>>=20 >>>> The posted error is one you get when you can't read the filesystem, >> which >>>> is why you need to update >>>> boot blocks across the OpenZFS change. >>>>=20 >>>> Warner >>>>=20 >>=20 >>=20 From nobody Fri Dec 10 16:36:49 2021 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 6F96818DA7EA for ; Fri, 10 Dec 2021 16:36:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9c4S2TKvz3Klq for ; Fri, 10 Dec 2021 16:36:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qv1-xf2c.google.com with SMTP id m17so8448326qvx.8 for ; Fri, 10 Dec 2021 08:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UM1Z4lhbxTG5Idy6XMIm7Ty25K85if5+VJZw8iqj0x4=; b=EcZZgAyzPJ/jJJm3RhwzzYsxMmSMyVMQ/6gNo0ePlNmFVbtOpNc6Mj9UvlsVlPOYmq H9ofnp4dPI78M7bnwxh7e4T8mLmOvrPjDDEu34XZFPnBpRFX7SpxgyI1VAnY6RiBNtrY Rb/5N2D80rk/IHU+Rr9ru3t3bq74vyl3ioDNjaztJkEztd9/U2Ih4ra9H2nOoOsqVDkn X8W8TwpfdaiGRAX6+N57MP/IXKNRAh/YsMhBmRnCnX3fa/PHJ1WnRPkc5oQ2UCosfBF4 qIXCsH5jM/nWTG/oKUvAonIWhdZnNxBa72CIXT7hqOG4yZEbItKAQ4QcQHyWf4xfRidm R6GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UM1Z4lhbxTG5Idy6XMIm7Ty25K85if5+VJZw8iqj0x4=; b=OU1pOXnm+W4DxtMLQ4fzZaQHQ9paF6toX8JgICuFQ30ekD1Ld12I3FS+RbhhE/F5y+ cQ/P16ZHOsoBhd+udPOjxczGMFHfKG4jTVFzkkVRR8JMt6s33XCkj+iGpVyHvXZYG1HG Whdr5ZFu8HuK61NhLBEnlXHaIGB0GtCAm++hFISi3FviA2r3PaH83trGr0m8rpxhoJP0 yDcrI9b2FbWEq6f8t0mS6eS2GC2PJLTISosv6t7fBmEVg8D8QKje7GA+UL7mSAZ/Pom1 /5LWxFsd/WnhtREZXff1Ea4IPaw78O7zeZImlyIDUA0ESWmFx0VKPR5uPyH49xYHZWhe cCew== X-Gm-Message-State: AOAM530MtkokYZgCGmRF1OuD7PpICnnIr9HWnHZMhGzktz4z1PDQ6W8m f5G8fOoT4eVQpZQV+1NdlsMeoytxOTQ= X-Google-Smtp-Source: ABdhPJxc2NsKW3T2lQNWrtpgwNjymoHTVBgYmSdiFtnAv9xGYZGPnd9XgoGYXbmbXOPVZcHQudl5rA== X-Received: by 2002:ad4:5046:: with SMTP id m6mr26286786qvq.116.1639154210042; Fri, 10 Dec 2021 08:36:50 -0800 (PST) Received: from mavoffice.ixsystems.com ([38.32.73.2]) by smtp.gmail.com with ESMTPSA id g21sm2338333qtb.62.2021.12.10.08.36.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Dec 2021 08:36:49 -0800 (PST) Subject: Re: Panic: Page Fault in Kernel: Yesterday's CURRENT To: Larry Rosenman , Freebsd current References: <3d1b5249a2c51670de496fad9e8b054c@lerctr.org> From: Alexander Motin Message-ID: <9852ae04-6dd0-1cd4-13fe-e97c68e71b37@FreeBSD.org> Date: Fri, 10 Dec 2021 11:36:49 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.13.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 In-Reply-To: <3d1b5249a2c51670de496fad9e8b054c@lerctr.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J9c4S2TKvz3Klq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Larry, This looks like some use-after-free or otherwise corrupted callout structure. Unfortunately the backtrace does not tell what was the callout. When was the previous update to look what could change? On 10.12.2021 11:24, Larry Rosenman wrote: > FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15 > main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021     > root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL  amd64 > > VMCORE *IS* available. > > > > > Unread portion of the kernel message buffer: > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 20 > fault virtual address   = 0x0 > fault code              = supervisor write data, page not present > instruction pointer     = 0x20:0xffffffff804e0db4 > stack pointer           = 0x0:0xfffffe0434de4e10 > frame pointer           = 0x0:0xfffffe0434de4e70 > code segment            = base 0x0, limit 0xfffff, type 0x1b >                         = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags        = resume, IOPL = 0 > current process         = 82990 (c++) > trap number             = 12 > panic: page fault > cpuid = 0 > time = 1639111198 > KDB: stack backtrace: > #0 0xffffffff8050fc95 at kdb_backtrace+0x65 > #1 0xffffffff804c468f at vpanic+0x17f > #2 0xffffffff804c4503 at panic+0x43 > #3 0xffffffff807a2195 at trap_fatal+0x385 > #4 0xffffffff807a21ef at trap_pfault+0x4f > #5 0xffffffff80779c78 at calltrap+0x8 > #6 0xffffffff8045ddb8 at handleevents+0x188 > #7 0xffffffff8045ea3e at timercb+0x24e > #8 0xffffffff807ca9eb at lapic_handle_timer+0x9b > #9 0xffffffff8077b9b1 at Xtimerint+0xb1 > Uptime: 2h28m57s > Dumping 12829 out of 131023 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > 55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" > (offsetof(struct pcpu, > (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > #1  doadump (textdump=) >     at /usr/src/sys/kern/kern_shutdown.c:399 > #2  0xffffffff804c428c in kern_reboot (howto=260) >     at /usr/src/sys/kern/kern_shutdown.c:487 > #3  0xffffffff804c46fe in vpanic (fmt=0xffffffff807e1276 "%s", >     ap=) at /usr/src/sys/kern/kern_shutdown.c:920 > #4  0xffffffff804c4503 in panic (fmt=) >     at /usr/src/sys/kern/kern_shutdown.c:844 > #5  0xffffffff807a2195 in trap_fatal (frame=0xfffffe0434de4d50, eva=0) >     at /usr/src/sys/amd64/amd64/trap.c:946 > #6  0xffffffff807a21ef in trap_pfault (frame=0xfffffe0434de4d50, >     usermode=false, signo=, ucode=) >     at /usr/src/sys/amd64/amd64/trap.c:765 > #7  > #8  0xffffffff804e0db4 in callout_process (now=now@entry=38385536922300) >     at /usr/src/sys/kern/kern_timeout.c:488 > #9  0xffffffff8045ddb8 in handleevents (now=now@entry=38385536922300, >     fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 > #10 0xffffffff8045ea3e in timercb (et=0xffffffff80d475e0 , >     arg=) at /usr/src/sys/kern/kern_clocksource.c:357 > #11 0xffffffff807ca9eb in lapic_handle_timer (frame=0xfffffe0434de4f40) >     at /usr/src/sys/x86/x86/local_apic.c:1364 > #12 > #13 0x000000080df42bb6 in ?? () > Backtrace stopped: Cannot access memory at address 0x7ffffdef2c90 > (kgdb) > > ------------------------------------------------------------------------ > -- Alexander Motin From nobody Fri Dec 10 16:43:19 2021 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 810F018DC4ED for ; Fri, 10 Dec 2021 16:43:20 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9cCr2kQCz3M92; Fri, 10 Dec 2021 16:43:20 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JasuU++9tu+U/2a7uSBDLI2dqfBQsvO17cABxRIT0Do=; b=p1Xuq8aWoNbwsb0talFRh5zOfT jqZ3hPava2ljCjsYSSMcRBgyHmT48ZbhxfABTCdg9gousaraeEaFGNMClACEOe3zD8jmn1RHIQgjG L1m0yBQ7xCbNrKPiXqfRb4BMvNB512MDtOhqrGn+C8cJczjgluPb0TKAo3p3HJOdup/5Jha2xUIoO ctO7VCCIhc/Fm9sVYmebCrwaZL898jrcbbMPuOi+r+wrE98VXjvqpyBC+XbTaoBQbEmPTLQHF9dzo WqH6rejwnk5sr8v3PzdXJrKGY5MsMWQn+UDNj04JZ5yoS8eTTBXl9uGI/GR6n2PvS+36zIMqQTLLy 1ghbNmTA==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:30369 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mvizP-0001Uk-6n; Fri, 10 Dec 2021 10:43:19 -0600 Received: from 76-250-255-117.lightspeed.austtx.sbcglobal.net ([76.250.255.117]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 10 Dec 2021 10:43:19 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Fri, 10 Dec 2021 10:43:19 -0600 From: Larry Rosenman To: Alexander Motin Cc: Freebsd current Subject: Re: Panic: Page Fault in Kernel: Yesterday's CURRENT In-Reply-To: <9852ae04-6dd0-1cd4-13fe-e97c68e71b37@FreeBSD.org> References: <3d1b5249a2c51670de496fad9e8b054c@lerctr.org> <9852ae04-6dd0-1cd4-13fe-e97c68e71b37@FreeBSD.org> Message-ID: X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J9cCr2kQCz3M92 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 14-2021_12_07-1217 - - 1.87G 2021-12-07 12:17 14-2021_12_09-1957 NR / 121G 2021-12-09 19:57 If that's any help On 12/10/2021 10:36 am, Alexander Motin wrote: > Hi Larry, > > This looks like some use-after-free or otherwise corrupted callout > structure. Unfortunately the backtrace does not tell what was the > callout. When was the previous update to look what could change? > > On 10.12.2021 11:24, Larry Rosenman wrote: >> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15 >> main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021     >> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL  >> amd64 >> >> VMCORE *IS* available. >> >> >> >> >> Unread portion of the kernel message buffer: >> kernel trap 12 with interrupts disabled >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 20 >> fault virtual address   = 0x0 >> fault code              = supervisor write data, page not present >> instruction pointer     = 0x20:0xffffffff804e0db4 >> stack pointer           = 0x0:0xfffffe0434de4e10 >> frame pointer           = 0x0:0xfffffe0434de4e70 >> code segment            = base 0x0, limit 0xfffff, type 0x1b >>                         = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags        = resume, IOPL = 0 >> current process         = 82990 (c++) >> trap number             = 12 >> panic: page fault >> cpuid = 0 >> time = 1639111198 >> KDB: stack backtrace: >> #0 0xffffffff8050fc95 at kdb_backtrace+0x65 >> #1 0xffffffff804c468f at vpanic+0x17f >> #2 0xffffffff804c4503 at panic+0x43 >> #3 0xffffffff807a2195 at trap_fatal+0x385 >> #4 0xffffffff807a21ef at trap_pfault+0x4f >> #5 0xffffffff80779c78 at calltrap+0x8 >> #6 0xffffffff8045ddb8 at handleevents+0x188 >> #7 0xffffffff8045ea3e at timercb+0x24e >> #8 0xffffffff807ca9eb at lapic_handle_timer+0x9b >> #9 0xffffffff8077b9b1 at Xtimerint+0xb1 >> Uptime: 2h28m57s >> Dumping 12829 out of 131023 >> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% >> >> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >> 55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" >> (offsetof(struct pcpu, >> (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >> #1  doadump (textdump=) >>     at /usr/src/sys/kern/kern_shutdown.c:399 >> #2  0xffffffff804c428c in kern_reboot (howto=260) >>     at /usr/src/sys/kern/kern_shutdown.c:487 >> #3  0xffffffff804c46fe in vpanic (fmt=0xffffffff807e1276 "%s", >>     ap=) at /usr/src/sys/kern/kern_shutdown.c:920 >> #4  0xffffffff804c4503 in panic (fmt=) >>     at /usr/src/sys/kern/kern_shutdown.c:844 >> #5  0xffffffff807a2195 in trap_fatal (frame=0xfffffe0434de4d50, eva=0) >>     at /usr/src/sys/amd64/amd64/trap.c:946 >> #6  0xffffffff807a21ef in trap_pfault (frame=0xfffffe0434de4d50, >>     usermode=false, signo=, ucode=) >>     at /usr/src/sys/amd64/amd64/trap.c:765 >> #7  >> #8  0xffffffff804e0db4 in callout_process >> (now=now@entry=38385536922300) >>     at /usr/src/sys/kern/kern_timeout.c:488 >> #9  0xffffffff8045ddb8 in handleevents (now=now@entry=38385536922300, >>     fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 >> #10 0xffffffff8045ea3e in timercb (et=0xffffffff80d475e0 , >>     arg=) at /usr/src/sys/kern/kern_clocksource.c:357 >> #11 0xffffffff807ca9eb in lapic_handle_timer >> (frame=0xfffffe0434de4f40) >>     at /usr/src/sys/x86/x86/local_apic.c:1364 >> #12 >> #13 0x000000080df42bb6 in ?? () >> Backtrace stopped: Cannot access memory at address 0x7ffffdef2c90 >> (kgdb) >> >> ------------------------------------------------------------------------ >> -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Fri Dec 10 17:03:53 2021 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 6501418E15A6 for ; Fri, 10 Dec 2021 17:04:01 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9cgj1XGPz3RKR for ; Fri, 10 Dec 2021 17:04:01 +0000 (UTC) (envelope-from 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 1BAH3sgP005688 for ; Fri, 10 Dec 2021 09:04:00 -0800 (PST) (envelope-from bsd-lists@bsdforge.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 Date: Fri, 10 Dec 2021 09:03:53 -0800 From: Chris To: freebsd-current@freebsd.org Subject: Re: 14-current: unable to boot after upgrade (installworld) In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <3b954b437e07d0250fb3dd69ee535361@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_57ca425b56b473d37931132a1894fcb4" X-Rspamd-Queue-Id: 4J9cgj1XGPz3RKR X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_57ca425b56b473d37931132a1894fcb4 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2021-12-10 08:01, Michael Gmelin wrote: >> On 10. Dec 2021, at 16:57, Chris wrote: >> >> On 2021-12-09 05:36, Sergey V. Dyatko wrote: >>> Hi, >>> Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh >>> 14-current from git,it looked like this: >>> 1) git pull https://git.freebsd.org/src.git /usr/src >>> 2) cd /usr/src ; make buildworld; make kernel >> Not sure you didn't actually do this. But it appears that you omitted a: >> make install kernel >> here. > > `make kernel` does buildkernel and installkernel. Right you are. I read it as make BUILDkernel. Sorry. :-/ > > -m > > >>> 3) shutdown -r now >>> after that I _successfully_ booted into 14-current and continued with >>> etcupdate -p >>> make installworld >>> etcupdate -B >>> shutdown -r now >>> but after that server doesn't come back. After I conneted to this server >>> via >>> IPMI ip-kvm I saw following (sorry for external link): >>> https://i.imgur.com/jH6MHd2.png >>> Well. There was a migration to zol between r368473 and current 'main' >>> branch so >>> I decided to install fresh 14-current from snapshot >>> FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid >>> possible problems >>> and again, after make kernel and reboot OS runs, but after installworld I >>> ended up >>> in the same situation >>> thoughts ? >>> -- >>> wbr, Sergey --=_57ca425b56b473d37931132a1894fcb4 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_57ca425b56b473d37931132a1894fcb4-- From nobody Fri Dec 10 17:35:47 2021 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 817EB18E73CB for ; Fri, 10 Dec 2021 17:36:01 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9dNd2xwwz3lq8 for ; Fri, 10 Dec 2021 17:36:01 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-lf1-x134.google.com with SMTP id l22so19340370lfg.7 for ; Fri, 10 Dec 2021 09:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1KeEhCSqBDaWeKxv3M/ArLBkL7IaBmjdBnYRbfG7LyE=; b=b/dlNJi2LWTSHjUmrw251KOzJLfZoaVLA0wndGt5MJkg/oU2O79+HuMtagOQI2npvn yyuWBA5y0Dt6lNCQ98+xicwtChmrhnEX93pbXXiyyyADdsICVqgvB78yPvMq0Gg8QXmW 9UHf3R+C9LISDG3WFt6HXXG6eMoiXBH08JoXtaoJUXhzrdy6d+cFC/oov2UgCPumkXa8 LKgVYM4wrHK+jJmIdTe0x7+winGchkLaDqGitc0zJ2VXviAIAl/hfHoFN+bAUUjh4IRq qcsO0ufn7cHIRTZsSPTh8S0yZwEW4ivkaJgQxU2aIS4++LlM0HFKWsV3+Gpz3e9ME6tA Okcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1KeEhCSqBDaWeKxv3M/ArLBkL7IaBmjdBnYRbfG7LyE=; b=mdetIJfDqzvIOGB5LJyo+uYY2SHazutAoVduAFqSCjFRCYDlE3zNvidXwr6ewmwYUb UJOmYgfsP3KUKmFd5TXD7BldWmWYudlmmhSk90LOcdHbOe9ZdJfpLg2WhH1m1NzSOq7q /FHE9fIDxdTWqjk8G6x0rmSIVkS2xagKxH3JF1yqBfgTnHvFwG/2egzytvnpzhqUXgiS ylTxGcfJ1Jz6WXJqxCESxqkIbPHpFLBsfCF0tTwdmC2ERA/chrxeLUEk1SXsqmuU5zqJ ErtlSmDwR3T3ZWBJ3PMIEthByqTD2lt9HFiu8lO6XpkDv6c3kTM4bF04xlKya6LrfTTv rkmA== X-Gm-Message-State: AOAM532uaNxH2pUyWw7JHKNE11JbToOceoBy5nHCX+Dkq1YyrjCUs+e/ 7sDfRh5+VNILPaLrxhKBm/3a48ilO6sTEWGtvU1jwQ== X-Google-Smtp-Source: ABdhPJwcMpZAhIH3QkeIfSA1PO0jWOKqp881UT2aYZ2Xa+TV5vjn1uMOnq54avFytNN3uzQS77CTngHSMN+q/E1dIxs= X-Received: by 2002:a05:6512:3d09:: with SMTP id d9mr14127476lfv.481.1639157759899; Fri, 10 Dec 2021 09:35:59 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <7101CA73-DCAD-4DEF-9861-C62789D22596@dons.net.au> In-Reply-To: <7101CA73-DCAD-4DEF-9861-C62789D22596@dons.net.au> From: Marcin Wojtas Date: Fri, 10 Dec 2021 18:35:47 +0100 Message-ID: Subject: Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main To: "Daniel O'Connor" Cc: freebsd-current , Fabien Thomas , MARECHAL Boris , Rafal Jaworowski , Damien DEVILLE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J9dNd2xwwz3lq8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Daniel pt., 10 gru 2021 o 10:16 Daniel O'Connor napisa=C5=82(= a): > > > > > On 17 Nov 2021, at 09:00, Marcin Wojtas wrote: > > As of b014e0f15bc7 the ASLR (Address Space Layout > > Randomization) feature becomes enabled for the all 64-bit > > binaries by default. > > Firstly, thank your for your efforts here, it is appreciated :) > > I am finding that the lang/sdcc port is crashing with a seg fault and the= core dump is no help to me at all: > [freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gd= b ../../bin/sdcc sdcc.core > GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] > > Reading symbols from ../../bin/sdcc... > [New LWP 100122] > Core was generated by `../../bin/sdcc -I../../device/include -I../../devi= ce/include/mcs51 -mds390 --nos'. > Program terminated with signal SIGSEGV, Segmentation fault. > Invalid permissions for mapped object. > #0 0x0000000804e3fbc0 in setrlimit () from /lib/libc.so.7 > (gdb) info thread > Id Target Id Frame > * 1 LWP 100122 0x0000000804e3fbc0 in setrlimit () from /lib/lib= c.so.7 > (gdb) bt > #0 0x0000000804e3fbc0 in setrlimit () from /lib/libc.so.7 > Backtrace stopped: Cannot access memory at address 0x7fffff87fd08 > > If I disable ASLR (via proccontrol) then it does not crash, but I am not = sure how I can debug it further. > > I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260= 303 if you (or anyone else) has suggestions for what to try. > Thanks for filing the ticket. Let's continue the conversation there. Best regards, Marcin From nobody Fri Dec 10 20:48:51 2021 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 BCD1518CCB31 for ; Fri, 10 Dec 2021 20:48:54 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9jgB4gYJz4kKm for ; Fri, 10 Dec 2021 20:48:54 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x72c.google.com with SMTP id de30so8981024qkb.0 for ; Fri, 10 Dec 2021 12:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=cPVtKBTtIajLghdZ/JYWjcW1mOE6UAN7KrIC/2OO0fc=; b=Yc8P1U7p8209PMXaluBWlU+VMoQkzfPgJdcLx6GKy2oh+GKEDS3HOxCZYFNbE8bhKk fIn49vaDZJBIIyBTewC8dGQwBc1ASo/oFjhAFyygW86rpPz/nmCgQCUbqhc5wNwNJGub q6BdeOq/sC8N5ZhRPXj3xbWGvhTVFHNYMD/3+s+6pjOwN68YYa3q8yn44mMRkpEAHLCa g4FBBzH3KGjv/GfSdtksfwSpSsq+YVbsFWlgtZv6Bs//3BihSSVIO2QX6EVnvf1s38yH GuJNwSOr7UhoJYvMmzrreeJrhj5XSjUOpkgF4CF7cscq2IWbOGlScBz9GMdNnDD6qw2x lraw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=cPVtKBTtIajLghdZ/JYWjcW1mOE6UAN7KrIC/2OO0fc=; b=PY8idsK5R3EneA6J2yaE2YHPNmECFQLBUzL3y8Nf4f6Bd7khP0r5+zIqe67Xrj/Kye SP/8pvSEhBEw7rJquYojGtBzrig5EyG8HvSc6HY4Jy4ziEQ7lwTxChu16dqbGIawf4mc 70e6NN5NdteBnbtD9t+ztUEBPCq434sRdEdyLfAX1uA6N2iusl66amapAu9ObxnX0TGG 5/qWzJh/4nVVRYoueE3RqW+Pn6zc4OOsgQXUCnaKqF5PSqMHu+ae9I5CR6Luu0W42Xbu 0f9ERB7Chi/WRVLEeCHvXaykyaQ+IsBbuhpYWNJ35MxSAjfza6RIiwkLSgJLTDBug8bt I0yw== X-Gm-Message-State: AOAM530IPHHETZhG9nnvqFWAokzCb5kVmK79yi/Dw681gf5qPLhGFzVk 7kFGrDd67AWaqbJpX2ekYCp6jzZrowApXg== X-Google-Smtp-Source: ABdhPJwb5GLivCAHHc7wOxDfEyGeofnf596Hd7jKlUqaASU2QJmAJ9yiifvNnnqu/EJviHwRMWnSDQ== X-Received: by 2002:a05:620a:400f:: with SMTP id h15mr23139672qko.226.1639169334048; Fri, 10 Dec 2021 12:48:54 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id l15sm2800301qtx.77.2021.12.10.12.48.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Dec 2021 12:48:53 -0800 (PST) Date: Fri, 10 Dec 2021 15:48:51 -0500 From: Mark Johnston To: Marcin Wojtas Cc: Daniel O'Connor , freebsd-current , Fabien Thomas , MARECHAL Boris , Rafal Jaworowski , Damien DEVILLE Subject: Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main Message-ID: References: <7101CA73-DCAD-4DEF-9861-C62789D22596@dons.net.au> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4J9jgB4gYJz4kKm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Dec 10, 2021 at 06:35:47PM +0100, Marcin Wojtas wrote: > Hi Daniel > > > pt., 10 gru 2021 o 10:16 Daniel O'Connor napisaÅ‚(a): > > > > > > > > > On 17 Nov 2021, at 09:00, Marcin Wojtas wrote: > > > As of b014e0f15bc7 the ASLR (Address Space Layout > > > Randomization) feature becomes enabled for the all 64-bit > > > binaries by default. > > > > Firstly, thank your for your efforts here, it is appreciated :) > > > > I am finding that the lang/sdcc port is crashing with a seg fault and the core dump is no help to me at all: > > [freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gdb ../../bin/sdcc sdcc.core > > GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] > > > > Reading symbols from ../../bin/sdcc... > > [New LWP 100122] > > Core was generated by `../../bin/sdcc -I../../device/include -I../../device/include/mcs51 -mds390 --nos'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > Invalid permissions for mapped object. > > #0 0x0000000804e3fbc0 in setrlimit () from /lib/libc.so.7 > > (gdb) info thread > > Id Target Id Frame > > * 1 LWP 100122 0x0000000804e3fbc0 in setrlimit () from /lib/libc.so.7 > > (gdb) bt > > #0 0x0000000804e3fbc0 in setrlimit () from /lib/libc.so.7 > > Backtrace stopped: Cannot access memory at address 0x7fffff87fd08 > > > > If I disable ASLR (via proccontrol) then it does not crash, but I am not sure how I can debug it further. > > > > I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303 if you (or anyone else) has suggestions for what to try. > > > > Thanks for filing the ticket. Let's continue the conversation there. I left a comment there. The gist of it is that there are several lingering problems with the stack gap implementation, and I think we should re-disable it on main until there's some consensus on how to proceed. From nobody Sat Dec 11 08:28:16 2021 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 82AD318DD497 for ; Sat, 11 Dec 2021 08:28:28 +0000 (UTC) (envelope-from potthua@gmail.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JB1BM6M67z3mX6 for ; Sat, 11 Dec 2021 08:28:27 +0000 (UTC) (envelope-from potthua@gmail.com) Received: by mail-ua1-x934.google.com with SMTP id o1so20755055uap.4 for ; Sat, 11 Dec 2021 00:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=Hs1eZfoVxXL32gKcSOMdpF0stir9GsW475giUC0v6hw=; b=EZIfvOraNlm6uJHKtOVPgmuE4p531/EJdOIWteD0nNMFKtwrX1OwxVox+k2yr+705R glmvDX/ue4uVASY7U8+/LAgl0Q28SmgB+DrWJzr51ldqAt/Q6kAQKdUXjT2KaT7dWD3Y ep5RCE75swXHBIAANwXRaVDKoO9n6MBw0n8okn5XCZL8g3pGt8/ZMQF+T5tjoRecJzhc 0w2A/wRfxzt9kke/qgN4AvlW/7Kt+6dKxhSbW9WJ5HT2sPfNtk2oachYJXiQvsrGWPXW oAQS6BrYl9ewKrt6PbQD/A1unSu5GCXnVZ4SjRiZdYS5Mqdkq6qz2sbZUZnhudJ62p8j 7r6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Hs1eZfoVxXL32gKcSOMdpF0stir9GsW475giUC0v6hw=; b=GUvGxhCOaJ7seUls2jW9O/PQJFrq8jpH22gDSHe2S5vkW3yhAQEqjGjBWNCurRCa5R y/3jduveAocnHmHPLHpPuw9+zyUeWinEb8W1Y6lgKycefiMx4V4EitnsOLp+16ITr7Lj lc2tVU5+e9zvXTqbujNw8Q1GPzt/vN+4cJv9rux/+Nq/b2EPzGjL5bnc6Nqxu2tjDetx JoFOn2tqvPbJx8yqLZ440BpK3g4/CK60zKGa8ZLT+L2cPx4M3idPmCG+kvkLx8ovE7X8 PHr0a1QqM8Y+6Hw/rsVowVqaCXvKh/eJiFvJdqD/JcdoF70anqqrJ2yxbtQVsuzX716f t7lw== X-Gm-Message-State: AOAM533pxLQISIpcqbP8HJ4uTO5cuOeiekDf+wAzzgnubCAb/aoX/q68 fWPRE4oiHcpfXPfLBeN5JtFcJwPboOEbngDJaxSKNoPJfEq8yQ== X-Google-Smtp-Source: ABdhPJyevkVYWzx65MoFydtkcO3RuOylmmRWO0G4hcwqUm0QC1gsL7X7NKiJ5DcZElVGpScKDrAvVIjlUR1fYNBPtSA= X-Received: by 2002:a05:6102:b13:: with SMTP id b19mr20110702vst.1.1639211307337; Sat, 11 Dec 2021 00:28:27 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Piper H Date: Sat, 11 Dec 2021 16:28:16 +0800 Message-ID: Subject: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000af8ad805d2da9fe5" X-Rspamd-Queue-Id: 4JB1BM6M67z3mX6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=EZIfvOra; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of potthua@gmail.com designates 2607:f8b0:4864:20::934 as permitted sender) smtp.mailfrom=potthua@gmail.com X-Spamd-Result: default: False [-3.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::934:from]; NEURAL_HAM_SHORT(-0.98)[-0.981]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: Y --000000000000af8ad805d2da9fe5 Content-Type: text/plain; charset="UTF-8" I read this article from Reddit: https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=1 I am surprised to see that the BSD cluster today has much worse performance than Linux. What do you think of this? Thanks Piper --000000000000af8ad805d2da9fe5-- From nobody Sat Dec 11 09:52:10 2021 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 9368318CB5CD for ; Sat, 11 Dec 2021 09:52:22 +0000 (UTC) (envelope-from xpetrl@beepc.ch) Received: from srv.fastssdserver.com (srv.fastssdserver.com [208.91.104.146]) (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 4JB3392FFxz4R6f for ; Sat, 11 Dec 2021 09:52:21 +0000 (UTC) (envelope-from xpetrl@beepc.ch) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=beepc.ch; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KkucM7RZzadtd1L7SRhBBitfxVDkJEcxPKpO05x+Gi4=; b=Om6jWS2+xqIL97ubmg6ZLXnIyo /RGJ0GiBbkQkgfyT/S6Xe+vu3AVW7JykSBV5nmw++nwV5lKjCNUu1fC/DyPppcpmvM4or2qv5YRgU LAs8wEIKTt1TEz8wCdh9pJbtodat81ME1jahpMQGRASQ8xhBcoTuuoVtDJmpMXFKd+TuPqqNH/YUQ t/QRxjyG5h9+Qnwt2EBewAiQTYB2cAJ4CKfxbN/HK7GZiaVSRiDUD6qilGk30o4KmCKL9KxLRvnXU belnEZHzBruqWSe9Ce3Mj0MPKlN1+/cTXaObcr1mn2/2zMfdgFjseIFz/68HMyw+MAj0M6fInMXbt NTqWCqdQ==; Received: from [185.20.202.205] (port=34314 helo=[192.168.3.177]) by srv.fastssdserver.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1mvz3B-0001ZV-6Y for freebsd-current@freebsd.org; Sat, 11 Dec 2021 14:52:13 +0500 Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux To: freebsd-current@freebsd.org References: From: "beepc.ch" Message-ID: Date: Sat, 11 Dec 2021 10:52:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - srv.fastssdserver.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - beepc.ch X-Get-Message-Sender-Via: srv.fastssdserver.com: authenticated_id: xpetrl@beepc.ch X-Authenticated-Sender: srv.fastssdserver.com: xpetrl@beepc.ch X-Source: X-Source-Args: X-Source-Dir: X-Rspamd-Queue-Id: 4JB3392FFxz4R6f X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=beepc.ch header.s=default header.b=Om6jWS2+; dmarc=none; spf=pass (mx1.freebsd.org: domain of xpetrl@beepc.ch designates 208.91.104.146 as permitted sender) smtp.mailfrom=xpetrl@beepc.ch X-Spamd-Result: default: False [1.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:208.91.104.146]; HAS_X_SOURCE(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[beepc.ch:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; HAS_X_ANTIABUSE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:35913, ipnet:208.91.104.0/23, country:US]; MID_RHS_MATCH_FROM(0.00)[]; HAS_X_AS(0.00)[xpetrl@beepc.ch]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(0.00)[beepc.ch:s=default]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[beepc.ch]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; RBL_VIRUSFREE_BOTNET(2.00)[208.91.104.146:from]; NEURAL_SPAM_LONG(1.00)[1.000]; HAS_X_GMSV(0.00)[xpetrl@beepc.ch]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > I am surprised to see that the BSD cluster today has much worse performance > than Linux. > What do you think of this? "Default" FreeBSD install setting are quite conservative. The Linux common distros are high tuned, those benchmark is in my opinion comparison of apples and oranges. Comparing "default" FreeBSD install with "default" Slackware install would be more interesting, because Slackware builds are at most vanilla. From nobody Sat Dec 11 10:17:19 2021 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 EC2A518D2A4E for ; Sat, 11 Dec 2021 10:17:30 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JB3cB68HQz4WwT for ; Sat, 11 Dec 2021 10:17:30 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: by mail-qt1-x830.google.com with SMTP id q14so10702823qtx.10 for ; Sat, 11 Dec 2021 02:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2grGP/Lmqg1dbGfmm9WsGDUdRFsW/DRy56XueP9JaAw=; b=VaUJFSWKm/CJOsBDnQHtU02MEq6KVlvGEAHJvEUnD4MipeIM1gwk5VVXo++nQP32vI mWIUwFjkNXUbrLm5XKGdnyUWhj69PhtlPj0ghKSnMe3cYaLWhW+LEN4HOqqy4jsAv2Y2 98AvOzr3mVJmdnrFSk6sR/eteAYEB7uxVpMN+MROCuF0ogBznjvU4vbmuthrBYGGXjW7 mTaZL5W6p0YOHw/5ftzyj7zhEgbJ8voyepaTikK3VP6cdowFuPrYniiKkWF4P8RyDCh6 NVt6rRrGOF6iAk0ZYEw+2TMT8JGcm6RUzRSZjBPRkaG0zNb1B1afyJmY7Le0O+YlVRKD Z/8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2grGP/Lmqg1dbGfmm9WsGDUdRFsW/DRy56XueP9JaAw=; b=uNDaRImf7+KmIAmmBKC7EcpQMpL0IqDcUokKn+KF+VhZ38kHvrFUa5SiCUA/bM/tUn cFF1X2iXzkch6ySIDIrLyUi4xhQXkyFc6OEpL8Cy9Fy5z9xol0DtsOf9kAH2RmaI99O/ 2JXITYJD/6qguL4Q6bNX2/kF+N1VwYgBvWC/mFl+eBcWkXwtoJIYAKiZwC1exVfnqs+v lmCDptwKBOk4K/6yTMtpBrxY/isjqX+XxO1dDKAoc8g7VxXsUyeF0xZ0jz/hoy/SHT2L PpgjnVqz3wicrg/gxLgCiHkU2seqhnXB3EKDc1STDXP633/PBtJXQM88eJMj45iUc/pc trcA== X-Gm-Message-State: AOAM53207nT3R5KoirgioQlNlWg4hRCw2UlucPiIrJ5rFy3Adevs8TiE RAewTX+GGwO2rbjBA7486G+h8byTLiU7AjnBdAMiJcHc X-Google-Smtp-Source: ABdhPJxw1RqSeacz6uWx9+7UOJ8pgNsxJ8z8LTZFJRsuzJXnEHl802xZbvlqvhPq1fUhpJ6LqwdgCQ8iZHz6bnuvat4= X-Received: by 2002:a05:622a:494:: with SMTP id p20mr32894241qtx.644.1639217850442; Sat, 11 Dec 2021 02:17:30 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: "dmilith ." Date: Sat, 11 Dec 2021 11:17:19 +0100 Message-ID: Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux To: "beepc.ch" Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000af665105d2dc2552" X-Rspamd-Queue-Id: 4JB3cB68HQz4WwT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000af665105d2dc2552 Content-Type: text/plain; charset="UTF-8" 1. Where are compiler options for BSDs? 2. Why they compare -O2 to -O3 code in some benchmarks? Why they enable fast math in some, and disable it for others? 3. Why they don't mention powerd setup for FreeBSD? By default it may use slowest CPU mode. Did they even load cpufreq kernel module? 4. Did they even care about default FreeBSD mitigations (via sysctl) enabled, or it's only valid for Linuxes? ;) 5. What happened to security and environment details of BSDs? It's kinda known that guys from Phroenix lack basic knowledge of how to do proper performance testing and lack basic knowledge about BSD systems. Nothing new. Would take these results with a grain of salt. On Sat, 11 Dec 2021 at 10:53, beepc.ch wrote: > > I am surprised to see that the BSD cluster today has much worse > performance > > than Linux. > > What do you think of this? > > "Default" FreeBSD install setting are quite conservative. > The Linux common distros are high tuned, those benchmark is in my > opinion comparison of apples and oranges. > > Comparing "default" FreeBSD install with "default" Slackware install > would be more interesting, because Slackware builds are at most vanilla. > > -- Daniel Dettlaff Versatile Knowledge Systems verknowsys.com --000000000000af665105d2dc2552-- From nobody Sat Dec 11 10:38:00 2021 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 0AF7B18D7791 for ; Sat, 11 Dec 2021 10:38:03 +0000 (UTC) (envelope-from theraven@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JB43t6ByKz4bPD; Sat, 11 Dec 2021 10:38:02 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id AEE392DE68; Sat, 11 Dec 2021 10:38:02 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.64] (unknown [81.141.223.100]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 0116F2E214; Sat, 11 Dec 2021 10:38:01 +0000 (GMT) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux From: David Chisnall In-Reply-To: Date: Sat, 11 Dec 2021 10:38:00 +0000 Cc: "beepc.ch" , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "dmilith ." X-Mailer: Apple Mail (2.3608.120.23.2.7) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639219082; 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=GqpEvDuwBoothqJC8b8jOxSJb5unbOooU3RrT0K8HZg=; b=HrWq0N959TAXbNQ+QX31Vh1GBWDeghLMCDgEz+/O0YxYs7KJkakt2Fp54wKzLnOndhcIxb CH9gdKQFrCHO2/JZKRqUBdD0vYjadooMzRs2TbsFNEquenqq/OYMWJ/FveoUlKCSMc8ypF LLpnR4Q8phKidR2GNFTKbAjWEJgQ8EhWXYVmQUTur4lXgPmG1DxdALM7quaOKV8u/zw9q1 u49iQC9zQxJ3kLIKwZ9p+6mjfzabzTLs8e8jfHRmMxE4whLQ52QefR/96cHekw1/kUV23E yparb8z+Iz/rmXACFmvkxbE1d1yHN/JQ39k9XnyvKuge3Ozt3cMJpbVkaysA8g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639219082; a=rsa-sha256; cv=none; b=Yczxmm0ADOONtf+9J38/cHLH3+506IZUOOSkXMNqiBbMSRbJjOqaF9/bPKEMWa0Wdkcsmq MqSCCzmjod/91Vt6KC3nPEHaXhvXRyEfivqUWf2bz6NYY3Y6RsVifNlBsGASAZSYT4CQog SsBDj+95nLf3+XGjsCM+p35rPucejIVZ6YG3t55VwQxCVjibd8oQz+mVAJOiT2jpmWY0J9 GJ5AocnVGqX/aD2a0FPpGItQxIurKPkIZOPUFiwWHn06J/MjUhq2wVG/AktsjCvmujogoD OsNhwtks+aoQPHalzLUsSEX/U+eOyMkb+APU19xS8/FHQrec5yn01ArByBAUEQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N While I agree on most of your points, the value of Phoronix is that it = tests the default install. As an end user, I don=E2=80=99t care that a particular program is twice = as fast on a particular Linux distro as it is on FreeBSD because of = kernel features, compiler options, or dependency choices. I would love to see the base system include the ThinLTO (LLVM IR) .a = files so that I can do inlining from libc into my program. I would love = for ports to default to ThinLTO unless they break with it. Apple = flipped that switch a few years ago, so a lot of things that broke with = ThinLTO are now fixed. The FreeBSD memcpy / memset implementations look like they=E2=80=99re = slower than the latest ones, which can give a 5-10% perf boost on some = workloads. LLVM just landed the automemcpy framework, which is designed = by some Google folks to synthesises efficient memcpy implementations = tailored to different workloads. FreeBSD often wins versus glibc-based distros because jemalloc is faster = than dlmalloc (the default malloc implementations in FreeBSD libc and = glibc, respectively). I=E2=80=99ve been using snmalloc in my libc for a = while and it generally gives me a few percent more perf. Unfortunately, = FreeBSD decided to expose all of the jemalloc non-standard functions = from libc, which means I can=E2=80=99t contribute it to upstream without = implementing all of those on top of snmalloc or it would be an ABI = break. It would be great if someone could pick up the Phronix benchmark suite = and do some profiling: where is FreeBSD spending more time than Linux? = Are there Linux-specific code paths that hit slow paths on FreeBSD and = fast paths on Linux that could have FreeBSD-specific fast paths added = (e.g. futex vs _umtx_op)? David > On 11 Dec 2021, at 10:17, dmilith . wrote: >=20 > 1. Where are compiler options for BSDs? > 2. Why they compare -O2 to -O3 code in some benchmarks? Why they = enable > fast math in some, and disable it for others? > 3. Why they don't mention powerd setup for FreeBSD? By default it may = use > slowest CPU mode. Did they even load cpufreq kernel module? > 4. Did they even care about default FreeBSD mitigations (via sysctl) > enabled, or it's only valid for Linuxes? ;) > 5. What happened to security and environment details of BSDs? >=20 > It's kinda known that guys from Phroenix lack basic knowledge of how = to do > proper performance testing and lack basic knowledge about BSD systems. > Nothing new. Would take these results with a grain of salt. >=20 > On Sat, 11 Dec 2021 at 10:53, beepc.ch wrote: >=20 >>> I am surprised to see that the BSD cluster today has much worse >> performance >>> than Linux. >>> What do you think of this? >>=20 >> "Default" FreeBSD install setting are quite conservative. >> The Linux common distros are high tuned, those benchmark is in my >> opinion comparison of apples and oranges. >>=20 >> Comparing "default" FreeBSD install with "default" Slackware install >> would be more interesting, because Slackware builds are at most = vanilla. >>=20 >>=20 >=20 > --=20 > Daniel Dettlaff > Versatile Knowledge Systems > verknowsys.com From nobody Sat Dec 11 10:39:48 2021 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 AED2318D8077 for ; Sat, 11 Dec 2021 10:40:06 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JB46G4DLcz4cVN for ; Sat, 11 Dec 2021 10:40:06 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-qt1-x831.google.com with SMTP id l8so10767049qtk.6 for ; Sat, 11 Dec 2021 02:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gn7os6vLYEhTFnlbTGAssVDz9zMYtLN4jflRyFnqQV4=; b=Yzj0C3dYUDaloZwSsJR6JWCnEbaf2PC7X8/Bo/8UCUgC1t/BsEWDNGsQIhUE9G4qYC X9q3Zw9D9oGp67b+iFb0JtTO/NIxGmlOY4XrbH0MaNCcSVyUCxdQQ2mOPM8jXCGS5dpS GAUX4adqUw4VjwWf4sWDXEf45A2IeZuA70wTV+nN/l1P4Ae4MW3C+Z6PBQfXB0ipAJLC +wZZSR82pJkHH6C+cfcUkQ4CDt1liv9X/HoJRGpJrQEcu/KrA3nmc6Y8ogS+2fGBUcLH PJHh4ptbnf4Sfx2AbiTayvzfHpA6g4M2dtGsPP/IDmGgKVzAacyDnPJ/+fHEdfF/D6O0 Z20A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gn7os6vLYEhTFnlbTGAssVDz9zMYtLN4jflRyFnqQV4=; b=LYiqiqwb1xrWrDK274QvLl0knHOL1qJqwVM+EjO+aS+b+orsSmaT/y8/RJMCERmTCV 41qPxvzVYyW7C1RZRA695YtLtTLfY1GK37XvTEhsjWNv5wKUHvpPd1Sx8HNMfY/6ReZ4 mNXWmd2soJnJ3/g+pPSKfiJwQi7jFmtrrX/Bm2jRrDNSUfC/TbWFLws54rPOrfoxmObH mgeHuY0mXOV7EuvH+QB5LeJsVRMMpDcOruoFPFFF4I3+flMPQ4u7cfqh1DyB5CbU02n0 gniJT5tdUHym9e+2UeTakQwBnApUaDvMI4KpxZNUBkV8l1Xjz035A0D4WBmAm0U1LlDp Z/Tw== X-Gm-Message-State: AOAM531eZeba3gHgUq3VeUQn0rDC16bQYqfKUw1/wO2mQXBPKOOKBeVk wH2GRTkRLwXrBvTS0qOMN8dVgO4avyouT6nWa+g= X-Google-Smtp-Source: ABdhPJxf3NzsX/tk9yyGwJ5WckqwT9nkcDRW5G+PCStf/0Aeymww+QJSZ6pQDs1gsBVrSBApZlwpFVME0BYTA+PdDEk= X-Received: by 2002:ac8:5745:: with SMTP id 5mr32453733qtx.85.1639219200348; Sat, 11 Dec 2021 02:40:00 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Sami Halabi Date: Sat, 11 Dec 2021 12:39:48 +0200 Message-ID: Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux To: "beepc.ch" Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000002559c805d2dc7699" X-Rspamd-Queue-Id: 4JB46G4DLcz4cVN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000002559c805d2dc7699 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I see these claims over and over. So I must ask. Is there any tunibg guide(s) to make the default not conservative in a regrding to several use cases like using as web server? How to Utilize gpu maybe? I know there are few network (aka routing / forwarding) guides.. but maybe instead of that superior feeling "oh they are linuxish and knoe shit" maybe better supply the tuning needed to get better results? And I'm not talking to get an engineer to analyze the tests case.. Maybe the linux defaults fit better for most use cases rather than being conservative?? Just to be clear I almost not used linux and always freebsd for simplicity usage.. but I must say it makes me wonder Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=A9=D7=91=D7=AA, 11 =D7=91=D7=93=D7= =A6=D7=9E=D7=B3 2021, 11:52, =D7=9E=D7=90=D7=AA beepc.ch =E2=80=8F: > > I am surprised to see that the BSD cluster today has much worse > performance > > than Linux. > > What do you think of this? > > "Default" FreeBSD install setting are quite conservative. > The Linux common distros are high tuned, those benchmark is in my > opinion comparison of apples and oranges. > > Comparing "default" FreeBSD install with "default" Slackware install > would be more interesting, because Slackware builds are at most vanilla. > > --0000000000002559c805d2dc7699-- From nobody Sat Dec 11 10:53:07 2021 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 E713318DB256 for ; Sat, 11 Dec 2021 10:53:15 +0000 (UTC) (envelope-from xpetrl@beepc.ch) Received: from srv.fastssdserver.com (srv.fastssdserver.com [208.91.104.146]) (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 4JB4PR0dffz4gBF for ; Sat, 11 Dec 2021 10:53:15 +0000 (UTC) (envelope-from xpetrl@beepc.ch) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=beepc.ch; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=J/Pa7zcBtmN7uVDqWOKFQn6tx8T9xZQSaTMqNDlzylA=; b=jT+kgzJxYg2JYB9hjTKpkcohyh NLJy0LvkC6pH1aMqdTLNynMLuesUx5F2ago0Grh6P6sR1H+k3lH8Pgk4mFauPWlBa3ZkENtHrhuuV xVJtNjqiVJpEbtowpQQqaOTP+7KhzZtasLpNMi4dM1CN2hMT4t4zr22KoTQJS+gGTGILvQ6kbHZ6n 1zt/YpXssYHrEtIFZH3Chy85UA/SjQfOl/ELWVTfIPjFqKtW8UkwyRW21jbMfv4Co9yG1jG5byHXo 4kY+h/Yke8Te0CnuQbW1XR1Ychycx6KSt/rx+cy0fXQrEaMIIO/sYfOeS/G9upBNVwG/112K6e31N k8B8WPhg==; Received: from [185.20.202.205] (port=34382 helo=[192.168.3.177]) by srv.fastssdserver.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1mw00D-0005Up-R8 for freebsd-current@freebsd.org; Sat, 11 Dec 2021 15:53:14 +0500 Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux To: freebsd-current@freebsd.org References: From: "beepc.ch" Message-ID: <593933b6-de09-f879-6e0f-f895a685555d@beepc.ch> Date: Sat, 11 Dec 2021 11:53:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - srv.fastssdserver.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - beepc.ch X-Get-Message-Sender-Via: srv.fastssdserver.com: authenticated_id: xpetrl@beepc.ch X-Authenticated-Sender: srv.fastssdserver.com: xpetrl@beepc.ch X-Source: X-Source-Args: X-Source-Dir: X-Rspamd-Queue-Id: 4JB4PR0dffz4gBF X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=beepc.ch header.s=default header.b=jT+kgzJx; dmarc=none; spf=pass (mx1.freebsd.org: domain of xpetrl@beepc.ch designates 208.91.104.146 as permitted sender) smtp.mailfrom=xpetrl@beepc.ch X-Spamd-Result: default: False [2.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:208.91.104.146:c]; HAS_X_SOURCE(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[beepc.ch:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; HAS_X_ANTIABUSE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:35913, ipnet:208.91.104.0/23, country:US]; MID_RHS_MATCH_FROM(0.00)[]; HAS_X_AS(0.00)[xpetrl@beepc.ch]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[beepc.ch:s=default]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[beepc.ch]; NEURAL_SPAM_MEDIUM(0.98)[0.976]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; RBL_VIRUSFREE_BOTNET(2.00)[208.91.104.146:from]; NEURAL_SPAM_LONG(1.00)[1.000]; HAS_X_GMSV(0.00)[xpetrl@beepc.ch]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, > Is there any tunibg guide(s) to make the default not conservative in a > regrding to several use cases like using as web server? - FreeBSD Handbook, Chapter 12. Configuration and Tuning - section 12.12. Tuning with sysctl(8) > Just to be clear I almost not used linux and always freebsd for simplicity > usage.. but I must say it makes me wonder > > Sami > > בת×ריך שבת, 11 בדצמ׳ 2021, 11:52, מ×ת beepc.ch â€: > >>> I am surprised to see that the BSD cluster today has much worse >> performance >>> than Linux. >>> What do you think of this? >> >> "Default" FreeBSD install setting are quite conservative. >> The Linux common distros are high tuned, those benchmark is in my >> opinion comparison of apples and oranges. >> >> Comparing "default" FreeBSD install with "default" Slackware install >> would be more interesting, because Slackware builds are at most vanilla. >> >> > From nobody Sat Dec 11 11:01:24 2021 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 535EA18DD5F4 for ; Sat, 11 Dec 2021 11:01:35 +0000 (UTC) (envelope-from SRS0=/SP+=Q4=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4JB4b31GYlz4j7d for ; Sat, 11 Dec 2021 11:01:34 +0000 (UTC) (envelope-from SRS0=/SP+=Q4=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id CC17728411; Sat, 11 Dec 2021 12:01:25 +0100 (CET) Received: from illbsd.quip.test (ip-78-45-215-131.net.upcbroadband.cz [78.45.215.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id C82A828416; Sat, 11 Dec 2021 12:01:24 +0100 (CET) Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux To: "dmilith ." , "beepc.ch" Cc: FreeBSD Current References: From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <47ca4ab6-52cf-8dbe-a1f0-7db13a8f605d@quip.cz> Date: Sat, 11 Dec 2021 12:01:24 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JB4b31GYlz4j7d X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[=Q4=quip.cz=000.fbsd]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/12/2021 11:17, dmilith . wrote: > 1. Where are compiler options for BSDs? > 2. Why they compare -O2 to -O3 code in some benchmarks? Why they enable > fast math in some, and disable it for others? > 3. Why they don't mention powerd setup for FreeBSD? By default it may use > slowest CPU mode. Did they even load cpufreq kernel module? > 4. Did they even care about default FreeBSD mitigations (via sysctl) > enabled, or it's only valid for Linuxes? ;) > 5. What happened to security and environment details of BSDs? > > It's kinda known that guys from Phroenix lack basic knowledge of how to do > proper performance testing and lack basic knowledge about BSD systems. > Nothing new. Would take these results with a grain of salt. It is very simple - they are comparing OSes with setting they are shipped. Average users don't know about tuning so the benchmark is reflecting what many average users get. And to be honest - I don't think FreeBSD will win even with everything best tuned. Kind regards Miroslav Lachman From nobody Sat Dec 11 11:11:56 2021 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 C2B0F18E00CA for ; Sat, 11 Dec 2021 11:12:02 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JB4q62qpLz4kyC for ; Sat, 11 Dec 2021 11:12:02 +0000 (UTC) (envelope-from 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 1BBBBuY6099736 for ; Sat, 11 Dec 2021 03:12:02 -0800 (PST) (envelope-from bsd-lists@bsdforge.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 Date: Sat, 11 Dec 2021 03:11:56 -0800 From: Chris To: freebsd-current@freebsd.org Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JB4q62qpLz4kyC X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N On 2021-12-11 02:38, David Chisnall wrote: > While I agree on most of your points, the value of Phoronix is that it tests > the > default install. > > As an end user, I don’t care that a particular program is twice as fast on a > particular Linux distro as it is on FreeBSD because of kernel features, > compiler > options, or dependency choices. > > I would love to see the base system include the ThinLTO (LLVM IR) .a files > so that > I can do inlining from libc into my program. I would love for ports to > default to > ThinLTO unless they break with it. Apple flipped that switch a few years > ago, so > a lot of things that broke with ThinLTO are now fixed. > > The FreeBSD memcpy / memset implementations look like they’re slower than > the > latest ones, which can give a 5-10% perf boost on some workloads. LLVM just > landed the automemcpy framework, which is designed by some Google folks to > synthesises efficient memcpy implementations tailored to different > workloads. > > FreeBSD often wins versus glibc-based distros because jemalloc is faster > than > dlmalloc (the default malloc implementations in FreeBSD libc and glibc, > respectively). I’ve been using snmalloc in my libc for a while and it > generally > gives me a few percent more perf. Unfortunately, FreeBSD decided to expose > all of > the jemalloc non-standard functions from libc, which means I can’t > contribute it > to upstream without implementing all of those on top of snmalloc or it would > be an > ABI break. > > It would be great if someone could pick up the Phronix benchmark suite and > do some > profiling: where is FreeBSD spending more time than Linux? Are there > Linux-specific code paths that hit slow paths on FreeBSD and fast paths on > Linux > that could have FreeBSD-specific fast paths added (e.g. futex vs _umtx_op)? I think everyones (here) making good points on the comparisons made on/at Phronix. But given that the FreeBSD "default" install adds a fair amount of overhead to elicit good feedback for bugs/failures. It makes it a poor candidate (kernel) for comparing performance. Hell, dmesg(8) even throws a warning saying that performance will be encumbered. If they knew the BSD basics. They might be able to provide a more meaningful comparison. I'm going to add Creating a BSD vs Linux comparison to the Foundation Sponsored Request/poll recently posted on some of the mailing lists. It'd be great for promotion/advertising/evangelism. :-) -- Chris > > David > > >> On 11 Dec 2021, at 10:17, dmilith . wrote: >> >> 1. Where are compiler options for BSDs? >> 2. Why they compare -O2 to -O3 code in some benchmarks? Why they enable >> fast math in some, and disable it for others? >> 3. Why they don't mention powerd setup for FreeBSD? By default it may use >> slowest CPU mode. Did they even load cpufreq kernel module? >> 4. Did they even care about default FreeBSD mitigations (via sysctl) >> enabled, or it's only valid for Linuxes? ;) >> 5. What happened to security and environment details of BSDs? >> >> It's kinda known that guys from Phroenix lack basic knowledge of how to do >> proper performance testing and lack basic knowledge about BSD systems. >> Nothing new. Would take these results with a grain of salt. >> >> On Sat, 11 Dec 2021 at 10:53, beepc.ch wrote: >> >>>> I am surprised to see that the BSD cluster today has much worse >>> performance >>>> than Linux. >>>> What do you think of this? >>> >>> "Default" FreeBSD install setting are quite conservative. >>> The Linux common distros are high tuned, those benchmark is in my >>> opinion comparison of apples and oranges. >>> >>> Comparing "default" FreeBSD install with "default" Slackware install >>> would be more interesting, because Slackware builds are at most vanilla. >>> >>> >> >> -- >> Daniel Dettlaff >> Versatile Knowledge Systems >> verknowsys.com From nobody Sat Dec 11 11:20:19 2021 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 42B4918E1BA9 for ; Sat, 11 Dec 2021 11:20:36 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JB5101CrQz4mPH for ; Sat, 11 Dec 2021 11:20:36 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: by mail-qt1-x833.google.com with SMTP id f20so10830659qtb.4 for ; Sat, 11 Dec 2021 03:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PAEWXVUPGGaf0tlhwostD9ciVBlKM8yHLz2sLKsXLTA=; b=XhTy9lRJ5eibuzAtklDa0uVGsSA9uXgBHaZnOaKu2oL8mwS+MERRKvRfSTkBIrAYMX B0wYCx2y690lLme9gP1R3STcPUwhdApYGatTUg0xPWoEDYYby16U2QqOfyC40QgaVsZg FPIWdvLjca8rwEeTcXG1kEG8WIUi+JACHbJjWklQaF36rZGMwUAOftNKRIYtPjoJIy5z UtQuwIdG1Js/w8qty3BHqDXm0BHC6FsAHnWtIHD2q5Xwvo1esimL++dnrOEIHwrnH4Yg /ld5ZDcehKcmojlTtdkogAGbtGq1ugyzIVxItvwQtczANwFumMGqD/BGUg6rUzr0igSv 0XOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PAEWXVUPGGaf0tlhwostD9ciVBlKM8yHLz2sLKsXLTA=; b=MqQ7+G/uYJV8NH3UXtXkn1yCoiOpKfOzry7rnY7prchkkvLez+Y4FexNKQgN0UEByv /4Cf+LMT6gTlcYMy0wEUBFoTIHRmDEEQbkYR30rR1z23DoUmWVlU2pfUoZOJJ9v1Bt5s VIgl9WV43pSPQKZMqVy4ae5Jso3ST7P6cx1theURSpOdsiBV56u2A8SzsorQHNw+0Ywn 8Y7DYjOI9uScCMtjvKDKrPgyCuAN3Wr1Tsl2zsQ0m6UGespov9Vh8BpYAdmMv8+EqXfl akLJB77ss3nUi8L6UMYhHQ00QJtcROm1D5TGOjoNCYo30R9HTFIWmMMrjWAXwZNrg1Gx w3WQ== X-Gm-Message-State: AOAM530pPz7/Eng7a23h21JpuTZEVbn+mjbjoFghRKySzbrt7UZLlXpi hjDVlJRRrZmnwopeKTjWiLEjiwiwV/gwYhmyKsw= X-Google-Smtp-Source: ABdhPJzOEJZAo/LNGlb0lHw3CeLFm2Xp8wsK28YPNr/xI37bxKEQHw9rE3AiCummddZ6gIZ5PqXAS/oAgBQt5fZwfV8= X-Received: by 2002:a05:622a:494:: with SMTP id p20mr33089480qtx.644.1639221630241; Sat, 11 Dec 2021 03:20:30 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <47ca4ab6-52cf-8dbe-a1f0-7db13a8f605d@quip.cz> In-Reply-To: <47ca4ab6-52cf-8dbe-a1f0-7db13a8f605d@quip.cz> From: "dmilith ." Date: Sat, 11 Dec 2021 12:20:19 +0100 Message-ID: Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux To: Miroslav Lachman <000.fbsd@quip.cz> Cc: "beepc.ch" , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000fa903205d2dd062e" X-Rspamd-Queue-Id: 4JB5101CrQz4mPH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000fa903205d2dd062e Content-Type: text/plain; charset="UTF-8" Maybe FreeBSD wouldn't win but results would be much closer. It's also known that default compiler options for ports aren't best. Default sysctl.conf default settings aren't best. They could at least compile all the benchmarks with the same compiler features. So -ffast-math, -flto and -O3 + code hardening features, for all tested systems. It's also professional to mention the compiler used (I recall that the previous Phroenix "benchmark" was done using GCC on FreeBSD which I'll not even comment). I could go on with all mistakes made in this "benchmark", but well, I know - benchmarking is hard. On Sat, 11 Dec 2021 at 12:01, Miroslav Lachman <000.fbsd@quip.cz> wrote: > On 11/12/2021 11:17, dmilith . wrote: > > 1. Where are compiler options for BSDs? > > 2. Why they compare -O2 to -O3 code in some benchmarks? Why they enable > > fast math in some, and disable it for others? > > 3. Why they don't mention powerd setup for FreeBSD? By default it may use > > slowest CPU mode. Did they even load cpufreq kernel module? > > 4. Did they even care about default FreeBSD mitigations (via sysctl) > > enabled, or it's only valid for Linuxes? ;) > > 5. What happened to security and environment details of BSDs? > > > > It's kinda known that guys from Phroenix lack basic knowledge of how to > do > > proper performance testing and lack basic knowledge about BSD systems. > > Nothing new. Would take these results with a grain of salt. > > It is very simple - they are comparing OSes with setting they are > shipped. Average users don't know about tuning so the benchmark is > reflecting what many average users get. > And to be honest - I don't think FreeBSD will win even with everything > best tuned. > > Kind regards > Miroslav Lachman > -- Daniel Dettlaff Versatile Knowledge Systems verknowsys.com --000000000000fa903205d2dd062e-- From nobody Sat Dec 11 12:21:16 2021 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 D78B318ED5F4 for ; Sat, 11 Dec 2021 12:21:53 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JB6Mj5Xkdz3Bxt for ; Sat, 11 Dec 2021 12:21:53 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wr1-x430.google.com with SMTP id a18so19224899wrn.6 for ; Sat, 11 Dec 2021 04:21:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gI/rgcQZE2Jbbp4xAxN/P24ZmX+BItGcHJTIUKUpOi4=; b=PApacQJ9Uo4nulEZtZGhhVJxR1xFw2AGUAc58dc7sPBjrMT3Mo75yHBsM7od/UyH6M Zj5J0qOK+6wPY5Db9Tb/21E6MGwG2BRLaKwYWcwkbtp2brfNmu35xkyHqoLQPwYYd0e6 6xi2xA19kiNemCkTG6KgwcA391z7eJ+29nzUzdkLzLqM2uCp5Nm2d3UrrkMt0HqigwWM UwPjCBLvjzh7G8uIIJeMciPiwVsC9SpJzFaklbo1Sh6Otth1R0t7NtOMUFieJD6BQiuS 5x4gTXLVBUvSMgqi1KE+Ub2CrKrkM0pe7G0WFOS64ED7CQt9ZAZE94WpFHccUE58q5Ta HcrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gI/rgcQZE2Jbbp4xAxN/P24ZmX+BItGcHJTIUKUpOi4=; b=z9MFZCjMyVD7NB1vkmFRtFY+f1krivQSoG/LAfv7bWN9jvYrQF+tkY6x+WlFy0fc58 9ARxDnN3ohs1ccGUnKtj1Tqy+YMOonKp2SLJaQEmlfUZ1+uPp1DX8H0BT3VkuzKdEyS4 OqLWbkAKwg3i6/86PbUtEse0f1XzE4H5i/jvjoYEuAgoq7KoPCNYPiHX5L7Nyqj/bO0s c4TCCGGiqyN/4jTv1l/b+nSALnA4S08lSn8Li9aJnVAq57cm3F5uMg0t4fIT2ppvpbR5 nbuOZNpr0lCv5k+WSnZIzGCkCeFBCVlR06jagMwlJ7wpBi5+ZOisyfikavrlRBiEX6p5 1RUw== X-Gm-Message-State: AOAM533q1Z55MTUVr43UqGgsHO2BMl3GxoeixklLbKmF26ELiqS62Kd5 Vq2qTr5pqNWrunVqXKzkkEug9LEkVcEoIU50/5s= X-Google-Smtp-Source: ABdhPJzknqbiQhj5NFDyJuDjVN8lwvtrIlBYuwByuqz47I3qa/ZR6XOAS11rYUmcD8kO1nxvVfJ/h+h8mfGHFlyUU68= X-Received: by 2002:a05:6000:381:: with SMTP id u1mr20645809wrf.383.1639225312670; Sat, 11 Dec 2021 04:21:52 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Sat, 11 Dec 2021 15:21:16 +0300 Message-ID: Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux To: Sami Halabi Cc: "beepc.ch" , FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000077f7b105d2dde2bd" X-Rspamd-Queue-Id: 4JB6Mj5Xkdz3Bxt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000077f7b105d2dde2bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I can say that these "micro" benchmarks are not "so much" useful . When such comparisons are made based on "abstract" views , they DO NOT SHOW very much utility . Over previous years I am always stressing that proper comparisons would be based on a "specified" workload : Which distributions is more suitable for that "specified" work load ? Testing / benchmarking should be performed with respect to such criteria , for example , continuously "a day work necessary for a profession" , "a web server for a 'specified' task" , "a NFS server working for a 'specified' application" . Then comparisons of parts causing significant differences may generate useful improvement possibilities . When we see *BSD distributions as a single group , it is obvious that everyone has its own priorities to realize . The same is true also for Linux distributions . Without taking such differences into consideration , reaching some conclusions about them would only be a waste of time . With my best regards , Mehmet Erol Sanliturk On Sat, Dec 11, 2021 at 1:40 PM Sami Halabi wrote: > Hi, > I see these claims over and over. > So I must ask. > Is there any tunibg guide(s) to make the default not conservative in a > regrding to several use cases like using as web server? How to Utilize gp= u > maybe? > I know there are few network (aka routing / forwarding) guides.. but mayb= e > instead of that superior feeling "oh they are linuxish and knoe shit" may= be > better supply the tuning needed to get better results? > And I'm not talking to get an engineer to analyze the tests case.. > Maybe the linux defaults fit better for most use cases rather than being > conservative?? > > Just to be clear I almost not used linux and always freebsd for simplicit= y > usage.. but I must say it makes me wonder > > Sami > > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=A9=D7=91=D7=AA, 11 =D7=91=D7=93= =D7=A6=D7=9E=D7=B3 2021, 11:52, =D7=9E=D7=90=D7=AA beepc.ch =E2=80=8F: > > > > I am surprised to see that the BSD cluster today has much worse > > performance > > > than Linux. > > > What do you think of this? > > > > "Default" FreeBSD install setting are quite conservative. > > The Linux common distros are high tuned, those benchmark is in my > > opinion comparison of apples and oranges. > > > > Comparing "default" FreeBSD install with "default" Slackware install > > would be more interesting, because Slackware builds are at most vanilla= . > > > > > --00000000000077f7b105d2dde2bd-- From nobody Sat Dec 11 16:53:25 2021 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 3B2C218D953E for ; Sat, 11 Dec 2021 16:53:34 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBDPB10jQz4W67 for ; Sat, 11 Dec 2021 16:53:34 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-oi1-x236.google.com with SMTP id bf8so17455582oib.6 for ; Sat, 11 Dec 2021 08:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fklZhNnLOBordd+EvvBbmSo2ti8QWXGoghEaaSzXWhs=; b=ggKzVgNWAtczt2kAAZu1NOb6nN5owmJiTN9Ud8WzqnJFotexiwWypulsm/gdrPOIY4 VpKVomr7CMk5m+u13XPlWRzxLxOXy8vbv2rPBnKWuohYqupKAAZr+QNpe8203SNIKZ9H h+uLqEqb8oyTvckb8QSj5kt8X4fOdlMu9FxSl0IoYWJ7H+RYt/iVJ612yL6LLVG4J+hQ MoA8Xe97t55ZhkvJEgtRXj1LC7WmMHh14lSThiBKoitp5GB5fhIbjTGKn0Mc4R0HcUBI MOFJG5Zm0VM3XsBXco6X32f8jmsQkSAc0zt1YCt4FeCtFs2csoPZqr+79HL0yZd1elEC hoQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fklZhNnLOBordd+EvvBbmSo2ti8QWXGoghEaaSzXWhs=; b=Fv3RcCBzYS1tJhdWKbbrQKU32frz1rr1eqgWsK2B54QaPMv+6WZIRf5opIs9przCMT 30oJw6foYf5dxxykPMVYhY5zwOOxTsbxV9o7lEwsVdeXJmfeZsjLTrEhU0PFtdQu61nq jjuV2WeojlPs88HphdGiK9AtYdxfpdNd+Q6xrH2JlZOqqIz+Knbssbo78gxGh0AI8yjR C18TSuWbYs1ueevx8+ZBi+GQzH/npJm09B3BAC4JjNSL6NlrDWfK32RzxC7p2Y+a5I3c jLzN83H1f8/NjpgGv6lpp33C9neZFlIwSohKfUJYrOkQeE0w6sPdSJfmSZv9jwz4vmqD WLgg== X-Gm-Message-State: AOAM532s6Q7amUK0w95EY+QUrxE/+FRWQp2pqMZP9GFZmaoqvJAvFVhJ 2slCKK+JAUp6MCLOVGD43X3+jrTLQ/g+G1XpIAB3bzmv X-Google-Smtp-Source: ABdhPJya2k16GGinGcRWXDugq0iC4kSxdIcI/jRV5Ua8rKoo6HKpLfaDqASDLn55k6+TteJVyg3vEQO7sZKFkBFuGXk= X-Received: by 2002:aca:3047:: with SMTP id w68mr18414814oiw.75.1639241606931; Sat, 11 Dec 2021 08:53:26 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:ac9:6c8c:0:b0:3e8:92e0:314b with HTTP; Sat, 11 Dec 2021 08:53:25 -0800 (PST) In-Reply-To: References: From: Mateusz Guzik Date: Sat, 11 Dec 2021 17:53:25 +0100 Message-ID: Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux To: Piper H Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JBDPB10jQz4W67 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 12/11/21, Piper H wrote: > I read this article from Reddit: > https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=1 > > I am surprised to see that the BSD cluster today has much worse performance > than Linux. > What do you think of this? > There is a lot to say here. One has to own up to Linux likely being a little bit (or even more so) faster for some of the legitimate tests. One, there are certain multicore scalability issues compared Linux, which should be pretty mild given the scale (16 cores/32 threads). A more important problem is userspace which fails to take advantage of SIMD instructions for core primitives like memset, memcpy et al. However, if the difference is more than few %, the result is likely bogus. Key thing to do when benchmarking is being able to explain the result, most notably if you run into huge discrepancies. I had a look at the most egregious result -- zstd and spoiler, it is a bug in result reporting in zstd. I got FreeBSD and Linux (Ubuntu Focal) vms running on: Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz Their zstd test ultimately ends up spawning: zstd -T24 -S -i15 -b19 FreeBSD-12.2-RELEASE-amd64-memstick.img (yes, they compress a ~1GB FreeBSD image). Side note, it does not matter, but I happen to have CURRENT kernel running on the FreeBSD 13 vm right now. [16:37] freebsd13:~ # time zstd -T24 -S -i15 -b19 FreeBSD-12.2-RELEASE-amd64-memstick.img 19#md64-memstick.img :1055957504 -> 692662162 (1.524), 3.97 MB/s ,2156.8 MB/s zstd -T24 -S -i15 -b19 FreeBSD-12.2-RELEASE-amd64-memstick.img 274.10s user 12.90s system 763% cpu 37.602 total In contrast: [16:37] ubuntu:...tem/compress-zstd-1.5.0 (130) # time zstd -T24 -S -i15 -b19 FreeBSD-12.2-RELEASE-amd64-memstick.img 19#md64-memstick.img :1055957504 -> 692662162 (1.524), 60.1 MB/s ,2030.6 MB/s zstd -T24 -S -i15 -b19 FreeBSD-12.2-RELEASE-amd64-memstick.img 328.65s user 3.48s system 850% cpu 39.070 total This is repeatable. If anything, FreeBSD did it *faster*. Yet zstd reports: FreeBSD: 3.97 MB/s ,2156.8 MB/s [total time real time of 37.602 seconds] Linux: 60.1 MB/s ,2030.6 MB/s [total time real time of 39.070 seconds] I don't know what these numbers are supposed to be, but it is pretty clear Phoronix grabs the first one. I'll look into sorting this out some time later. TL;DR don't drink and benchmark -- Mateusz Guzik From nobody Sat Dec 11 17:59:13 2021 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 5178518E7952 for ; Sat, 11 Dec 2021 17:59:21 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBFs43svjz4jdv for ; Sat, 11 Dec 2021 17:59:20 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-oi1-x234.google.com with SMTP id q25so17721408oiw.0 for ; Sat, 11 Dec 2021 09:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9NBHFUSpJQoPD4GlKo/lZs9Enx5GO3cwH4+RRh/SYqU=; b=ZbK2j8wlm3T357TR5Ey4t9tn0Ulh+olGMHuuvOUHXteAxkuuxRiVIoBZ0LQ/rupXkt LZFQ/nxNVE1zTtCFc3T8nQ0qmBg+qz4p4n9vXGFIpZ2y93Iv0wW7Jxx8fVUyhESGJ67z RLWV732gdUwKBjiA3fPJwaEhBoEOulA9uSrMPnfwaUpWH97jWqVGGU7w9Q3F6E4+kOO0 WFXXuseTowQstA57D7VDqqUl+uNwSYA9wPewHVnEB7PI6D/uKQ6ckOL3NY+bFY8IdsI5 yYTNvJC1cStzLHME7ydCmADi4PMiufc22wHrqOeMbEYnDHJIX0qieY+EjWmSqkg95SHF o1wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9NBHFUSpJQoPD4GlKo/lZs9Enx5GO3cwH4+RRh/SYqU=; b=q7ycbRe8GmUD1v2jutDB8yPzlf/PajySmzrTb1F0WmDdbVTycjLIKC924+QTMgUhWB pKFV4X9dFUhut0LAaupGkSWfocTKSQDp+xP2JptJxHEgNACKBuLbenc373VkQWCVXVB7 c+ODYsI2hspchC+6uboK7bnFo+NCMojP0zGlxfor7OB22gqOL0WJ3CcNMpmXF/k0AQAv 6b+1++H0KEeZ0Vz9gUCEn5YFQFhmAs4Yaz5PV9EBVi01/DSlTMRv/dZdL7TlUwnMHVgV 6sEqUWeRv5cS4fcKnMxfb1xU6dMKylQ25bvo2DLNCk3KzhloxntxrwFoRNzrTIIKZUur XCSA== X-Gm-Message-State: AOAM531bEswQKdj3yNlAUUntco0OOxx+obKP2/JyzFkrXim6NbHE7xFV 9qLCBCbynJrqN8oJhOkQ3i5wcb85nsFnNgVGU7g= X-Google-Smtp-Source: ABdhPJxh6u+PjKQaKIvDSXut6BMyG1TP6qM2xhouQ+ANHk4dpnRZdavLJw6okfb+x6XU0zHR6kLsakzQJSpf3hEg0yc= X-Received: by 2002:a54:4486:: with SMTP id v6mr19102658oiv.90.1639245554402; Sat, 11 Dec 2021 09:59:14 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:ac9:6c8c:0:b0:3e8:92e0:314b with HTTP; Sat, 11 Dec 2021 09:59:13 -0800 (PST) In-Reply-To: References: From: Mateusz Guzik Date: Sat, 11 Dec 2021 18:59:13 +0100 Message-ID: Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux To: Piper H Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JBFs43svjz4jdv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZbK2j8wl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2607:f8b0:4864:20::234 as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-3.71 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.908]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-0.80)[-0.800]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::234:from]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 12/11/21, Mateusz Guzik wrote: > On 12/11/21, Piper H wrote: >> I read this article from Reddit: >> https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=1 >> >> I am surprised to see that the BSD cluster today has much worse >> performance >> than Linux. >> What do you think of this? >> > > There is a lot to say here. > > One has to own up to Linux likely being a little bit (or even more so) > faster for some of the legitimate tests. One, there are certain > multicore scalability issues compared Linux, which should be pretty > mild given the scale (16 cores/32 threads). A more important problem > is userspace which fails to take advantage of SIMD instructions for > core primitives like memset, memcpy et al. However, if the difference > is more than few %, the result is likely bogus. Key thing to do when > benchmarking is being able to explain the result, most notably if you > run into huge discrepancies. > > I had a look at the most egregious result -- zstd and spoiler, it is a > bug in result reporting in zstd. > > I got FreeBSD and Linux (Ubuntu Focal) vms running on: > Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz > > Their zstd test ultimately ends up spawning: zstd -T24 -S -i15 -b19 > FreeBSD-12.2-RELEASE-amd64-memstick.img (yes, they compress a ~1GB > FreeBSD image). > > Side note, it does not matter, but I happen to have CURRENT kernel > running on the FreeBSD 13 vm right now. > > [16:37] freebsd13:~ # time zstd -T24 -S -i15 -b19 > FreeBSD-12.2-RELEASE-amd64-memstick.img > 19#md64-memstick.img :1055957504 -> 692662162 (1.524), 3.97 MB/s ,2156.8 > MB/s > zstd -T24 -S -i15 -b19 FreeBSD-12.2-RELEASE-amd64-memstick.img > 274.10s user 12.90s system 763% cpu 37.602 total > > In contrast: > > [16:37] ubuntu:...tem/compress-zstd-1.5.0 (130) # time zstd -T24 -S > -i15 -b19 FreeBSD-12.2-RELEASE-amd64-memstick.img > 19#md64-memstick.img :1055957504 -> 692662162 (1.524), 60.1 MB/s ,2030.6 > MB/s > zstd -T24 -S -i15 -b19 FreeBSD-12.2-RELEASE-amd64-memstick.img > 328.65s user 3.48s system 850% cpu 39.070 total > > This is repeatable. If anything, FreeBSD did it *faster*. Yet zstd reports: > FreeBSD: 3.97 MB/s ,2156.8 MB/s [total time real time of 37.602 seconds] > Linux: 60.1 MB/s ,2030.6 MB/s [total time real time of 39.070 seconds] > > I don't know what these numbers are supposed to be, but it is pretty > clear Phoronix grabs the first one. > > I'll look into sorting this out some time later. > So I cloned https://github.com/facebook/zstd/ and got the v1.4.8 tag, as currently imported into FreeBSD. The diff is pretty minimal and deals with exposing extra symbols. zstd directly compiled from that source (with mere gmake) correctly shows 2-digit MB speeds, so it has to be something in the FreeBSD build which ends up messing with it. I ran out of curiosity at this point (and more so time) at this point, but I invite someone else to get to the bottom of this. Bottom line though: there is no zstd performance problem on FreeBSD. -- Mateusz Guzik From nobody Sat Dec 11 19:07:18 2021 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 6FB0D18CD93A for ; Sat, 11 Dec 2021 19:07:26 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBHMd346Vz4vM4 for ; Sat, 11 Dec 2021 19:07:25 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-ot1-x32c.google.com with SMTP id h19-20020a9d3e53000000b0056547b797b2so13061228otg.4 for ; Sat, 11 Dec 2021 11:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sCn4vhM0p78vo2UBi7WINeGKH+mHbH6OTvpm37QDteM=; b=p4a/EqrsYm9DxRLfh59gIEL9QAtlpmyfh8/2furHB/mjzOmMtOHA+6Uyx091Plbibx y88SzyLNT76KCyn8oRDF9B6PCH6t9/UGvevoEfMVzL9KPmHaSOYunciG0OEVX0bwR8eo e9+kImOV/vdjP7NYfX6F/667RieDKKg0GFuLzAcDudJgtoOiZ44E/bGDDFcwe0hkLeUS PJJ3s5nZvxeSRyH26YcMbDlgfdYT9sQWj1xwTzhd3S0k3zMp6cJVJfY9p2DtEQxSXJRX yuhY0Ph+hkxr0PWsJ8vsVmqVe2f6oYxeKOdtvte02tNAIFm+UmwckBTzmVHfUZ6axaq9 4w2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sCn4vhM0p78vo2UBi7WINeGKH+mHbH6OTvpm37QDteM=; b=HXm9z/aNymQDnVBVN0UZYIjz1S1QBwt5p+C2x2ukOdnR5lHvmnUH5aoRzQ0YbT7Ogo WGw5fKzvnPpJTuHwHtmUgxuldYwXjPMdZlE/mKy+WM4QoiA3ZcyuQknKxkfDketeBHrC 2mb+a3NUTtYL4kNNxczlNrKEr67iE8DtSdwS49wEtGnmujSZSiIqsupbAR6K49AvJxHr XCfWl4smNAl1aYlKXZ4roZ1dCy6MmXOZbFWGxlT4h+Pjwa7mIgkdnoB3k8ZS8saVDtfg dY1OyElAhvcqhrfKfLipIUo5qc+3lRLC3mmIopA0iA4wEgPHtJ+G4Qk9S8BfdbZAuZTR CThw== X-Gm-Message-State: AOAM530/mNVpXVTFQRi4Y/7vgbi4OZTSFuAx86Dxee+HK+9dppACi1Tw 80fNJBpHaaFFe4978/BnEV2+TiGDHg5NQOX196/sMe7b X-Google-Smtp-Source: ABdhPJymNYePDLpefB2zqvlXvsPRa2YEurOa537z/fXN11JYxThFJdxHQRCFLo8LoZ8RFbbpmWvq1p9xaFlv0di3pc8= X-Received: by 2002:a05:6830:2712:: with SMTP id j18mr16797801otu.302.1639249638817; Sat, 11 Dec 2021 11:07:18 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:ac9:6c8c:0:b0:3e8:92e0:314b with HTTP; Sat, 11 Dec 2021 11:07:18 -0800 (PST) In-Reply-To: References: From: Mateusz Guzik Date: Sat, 11 Dec 2021 20:07:18 +0100 Message-ID: Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux To: Piper H Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JBHMd346Vz4vM4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="p4a/Eqrs"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2607:f8b0:4864:20::32c as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-0.80)[-0.795]; NEURAL_SPAM_MEDIUM(0.74)[0.739]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::32c:from]; NEURAL_HAM_SHORT(-0.94)[-0.940]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 12/11/21, Mateusz Guzik wrote: > On 12/11/21, Mateusz Guzik wrote: >> On 12/11/21, Piper H wrote: >>> I read this article from Reddit: >>> https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=1 >>> >>> I am surprised to see that the BSD cluster today has much worse >>> performance >>> than Linux. >>> What do you think of this? >>> >> >> There is a lot to say here. >> >> One has to own up to Linux likely being a little bit (or even more so) >> faster for some of the legitimate tests. One, there are certain >> multicore scalability issues compared Linux, which should be pretty >> mild given the scale (16 cores/32 threads). A more important problem >> is userspace which fails to take advantage of SIMD instructions for >> core primitives like memset, memcpy et al. However, if the difference >> is more than few %, the result is likely bogus. Key thing to do when >> benchmarking is being able to explain the result, most notably if you >> run into huge discrepancies. >> >> I had a look at the most egregious result -- zstd and spoiler, it is a >> bug in result reporting in zstd. >> >> I got FreeBSD and Linux (Ubuntu Focal) vms running on: >> Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz >> >> Their zstd test ultimately ends up spawning: zstd -T24 -S -i15 -b19 >> FreeBSD-12.2-RELEASE-amd64-memstick.img (yes, they compress a ~1GB >> FreeBSD image). >> >> Side note, it does not matter, but I happen to have CURRENT kernel >> running on the FreeBSD 13 vm right now. >> >> [16:37] freebsd13:~ # time zstd -T24 -S -i15 -b19 >> FreeBSD-12.2-RELEASE-amd64-memstick.img >> 19#md64-memstick.img :1055957504 -> 692662162 (1.524), 3.97 MB/s ,2156.8 >> MB/s >> zstd -T24 -S -i15 -b19 FreeBSD-12.2-RELEASE-amd64-memstick.img >> 274.10s user 12.90s system 763% cpu 37.602 total >> >> In contrast: >> >> [16:37] ubuntu:...tem/compress-zstd-1.5.0 (130) # time zstd -T24 -S >> -i15 -b19 FreeBSD-12.2-RELEASE-amd64-memstick.img >> 19#md64-memstick.img :1055957504 -> 692662162 (1.524), 60.1 MB/s ,2030.6 >> MB/s >> zstd -T24 -S -i15 -b19 FreeBSD-12.2-RELEASE-amd64-memstick.img >> 328.65s user 3.48s system 850% cpu 39.070 total >> >> This is repeatable. If anything, FreeBSD did it *faster*. Yet zstd >> reports: >> FreeBSD: 3.97 MB/s ,2156.8 MB/s [total time real time of 37.602 seconds] >> Linux: 60.1 MB/s ,2030.6 MB/s [total time real time of 39.070 seconds] >> >> I don't know what these numbers are supposed to be, but it is pretty >> clear Phoronix grabs the first one. >> >> I'll look into sorting this out some time later. >> > > So I cloned https://github.com/facebook/zstd/ and got the v1.4.8 tag, > as currently imported into FreeBSD. The diff is pretty minimal and > deals with exposing extra symbols. > > zstd directly compiled from that source (with mere gmake) correctly > shows 2-digit MB speeds, so it has to be something in the FreeBSD > build which ends up messing with it. I ran out of curiosity at this > point (and more so time) at this point, but I invite someone else to > get to the bottom of this. > > Bottom line though: there is no zstd performance problem on FreeBSD. > Well I had another look at found it: the low number is computed from supposed total time spent on CPU. Compiling by hand gives c11 primitives to do it, while using the FreeBSD source tree lands with c90 which end up giving bogus results. A hack which I can't be bothered to productize pasted below. I can't easily repeat the test with patched zstd on the same box, but on another one this goes from supposed ~3.3MB/s to 70.2MB/s, which assume sorts it out. diff --git a/sys/contrib/zstd/programs/timefn.c b/sys/contrib/zstd/programs/timefn.c index 95460d0d971d..f5dcdf84186e 100644 --- a/sys/contrib/zstd/programs/timefn.c +++ b/sys/contrib/zstd/programs/timefn.c @@ -84,8 +84,7 @@ PTime UTIL_getSpanTimeNano(UTIL_time_t clockStart, UTIL_time_t clockEnd) /* C11 requires timespec_get, but FreeBSD 11 lacks it, while still claiming C11 compliance. Android also lacks it but does define TIME_UTC. */ -#elif (defined (__STDC_VERSION__) && (__STDC_VERSION__ >= 201112L) /* C11 */) \ - && defined(TIME_UTC) && !defined(__ANDROID__) +#else #include /* abort */ #include /* perror */ @@ -133,14 +132,6 @@ PTime UTIL_getSpanTimeNano(UTIL_time_t begin, UTIL_time_t end) return nano; } - - -#else /* relies on standard C90 (note : clock_t measurements can be wrong when using multi-threading) */ - -UTIL_time_t UTIL_getTime(void) { return clock(); } -PTime UTIL_getSpanTimeMicro(UTIL_time_t clockStart, UTIL_time_t clockEnd) { return 1000000ULL * (clockEnd - clockStart) / CLOCKS_PER_SEC; } -PTime UTIL_getSpanTimeNano(UTIL_time_t clockStart, UTIL_time_t clockEnd) { return 1000000000ULL * (clockEnd - clockStart) / CLOCKS_PER_SEC; } - #endif diff --git a/sys/contrib/zstd/programs/timefn.h b/sys/contrib/zstd/programs/timefn.h index 5d2818e8a1b7..2f0a3c58528d 100644 --- a/sys/contrib/zstd/programs/timefn.h +++ b/sys/contrib/zstd/programs/timefn.h @@ -57,17 +57,9 @@ extern "C" { /* C11 requires timespec_get, but FreeBSD 11 lacks it, while still claiming C11 compliance. Android also lacks it but does define TIME_UTC. */ -#elif (defined (__STDC_VERSION__) && (__STDC_VERSION__ >= 201112L) /* C11 */) \ - && defined(TIME_UTC) && !defined(__ANDROID__) - +#else typedef struct timespec UTIL_time_t; #define UTIL_TIME_INITIALIZER { 0, 0 } - -#else /* relies on standard C90 (note : clock_t measurements can be wrong when using multi-threading) */ - - typedef clock_t UTIL_time_t; - #define UTIL_TIME_INITIALIZER 0 - #endif -- Mateusz Guzik From nobody Sat Dec 11 19:45:31 2021 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 9C1CE18D6740 for ; Sat, 11 Dec 2021 19:45:39 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [209.51.186.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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBJCk4RPGz50y8 for ; Sat, 11 Dec 2021 19:45:38 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.3] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id C29092F846 for ; Sat, 11 Dec 2021 19:45:32 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net C29092F846 Message-ID: Date: Sat, 11 Dec 2021 14:45:31 -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/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux Content-Language: en-US To: freebsd-current@freebsd.org References: From: Allan Jude In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JBJCk4RPGz50y8 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 209.51.186.6 is neither permitted nor denied by domain of allanjude@freebsd.org) smtp.mailfrom=allanjude@freebsd.org X-Spamd-Result: default: False [-1.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[allanjude]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[0.998]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:6939, ipnet:209.51.160.0/19, country:US]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 12/11/2021 5:38 AM, David Chisnall wrote: > While I agree on most of your points, the value of Phoronix is that it tests the default install. > > As an end user, I don’t care that a particular program is twice as fast on a particular Linux distro as it is on FreeBSD because of kernel features, compiler options, or dependency choices. > > I would love to see the base system include the ThinLTO (LLVM IR) .a files so that I can do inlining from libc into my program. I would love for ports to default to ThinLTO unless they break with it. Apple flipped that switch a few years ago, so a lot of things that broke with ThinLTO are now fixed. > > The FreeBSD memcpy / memset implementations look like they’re slower than the latest ones, which can give a 5-10% perf boost on some workloads. LLVM just landed the automemcpy framework, which is designed by some Google folks to synthesises efficient memcpy implementations tailored to different workloads. > > FreeBSD often wins versus glibc-based distros because jemalloc is faster than dlmalloc (the default malloc implementations in FreeBSD libc and glibc, respectively). I’ve been using snmalloc in my libc for a while and it generally gives me a few percent more perf. Unfortunately, FreeBSD decided to expose all of the jemalloc non-standard functions from libc, which means I can’t contribute it to upstream without implementing all of those on top of snmalloc or it would be an ABI break. > > It would be great if someone could pick up the Phronix benchmark suite and do some profiling: where is FreeBSD spending more time than Linux? Are there Linux-specific code paths that hit slow paths on FreeBSD and fast paths on Linux that could have FreeBSD-specific fast paths added (e.g. futex vs _umtx_op)? > > David > > >> On 11 Dec 2021, at 10:17, dmilith . wrote: >> >> 1. Where are compiler options for BSDs? >> 2. Why they compare -O2 to -O3 code in some benchmarks? Why they enable >> fast math in some, and disable it for others? >> 3. Why they don't mention powerd setup for FreeBSD? By default it may use >> slowest CPU mode. Did they even load cpufreq kernel module? >> 4. Did they even care about default FreeBSD mitigations (via sysctl) >> enabled, or it's only valid for Linuxes? ;) >> 5. What happened to security and environment details of BSDs? >> >> It's kinda known that guys from Phroenix lack basic knowledge of how to do >> proper performance testing and lack basic knowledge about BSD systems. >> Nothing new. Would take these results with a grain of salt. >> >> On Sat, 11 Dec 2021 at 10:53, beepc.ch wrote: >> >>>> I am surprised to see that the BSD cluster today has much worse >>> performance >>>> than Linux. >>>> What do you think of this? >>> >>> "Default" FreeBSD install setting are quite conservative. >>> The Linux common distros are high tuned, those benchmark is in my >>> opinion comparison of apples and oranges. >>> >>> Comparing "default" FreeBSD install with "default" Slackware install >>> would be more interesting, because Slackware builds are at most vanilla. >>> >>> >> >> -- >> Daniel Dettlaff >> Versatile Knowledge Systems >> verknowsys.com > > I tried to investigate this a bit yesterday. Specifically, seeing 'zstd' and 'openssl 3.0 sha256' being significantly worse on FreeBSD, when especially the latter, should basically have 0 difference between OSes. The Phoronix test suite is available as a package for freebsd, but I don't know what kind of magic is required to make it actually work. The compress-zstd-1.5.0 benchmark's install.sh tries to compile zstd with BSD make, when the makefile only works for GNU make. A little hacking around that, and I managed to run the test, but the results I got were in line with Linux, over 2 GB/sec, not the 300 MB/sec their result reported. I've not managed to figure out what they could have done wrong. It really does look like for zstd, it was someone only using 1 core on FreeBSD, and all cores on every other OS. -- Allan Jude From nobody Sun Dec 12 09:20:32 2021 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 7FB1518D3362 for ; Sun, 12 Dec 2021 09:20:48 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBfJH4Zv8z3jZ5 for ; Sun, 12 Dec 2021 09:20:47 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id EE09A10A330D for ; Sun, 12 Dec 2021 10:20:38 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id CC90F10A330B for ; Sun, 12 Dec 2021 10:20:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1639300838; 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=RTe2bekCzSBW0kNVdFoZiadCKg03aKXHZ7dFHiHVLhE=; b=TV9Vuee8Mm+X11bO/uHVOInKYVIVzs7DM0ctyh8aMDp6KMOzWARnceh8+9YvynI00ME3+r NcmbASBsBQZ4RlcLLSgL9HC4dykhApO/g1BSzeKat9mRyoCvjSLGal7g9UYPju8Ibj1Kt2 NtfXmzxox4BsXM7L8K5PmFOMMZZjC0Eb9eSMJbjnEbcWFrsTbo5iNv99bB/leLpfZV/anK VGiBl74r3UmX/3ht1LhEv6zQrLznqsunn1V8nwS8tD73BbVH+CDMMnNsml9IKsjkmnlUX/ BlQnkzRqz/UaUE+cnRc9knQA8WXhocl4JejRN6c7YYEFxhdfPwwat9FkvqBDFg== Received: from jelly.fritz.box (dynamic-2a01-0c22-ad1c-cf00-5585-92d4-c169-1fb9.c22.pool.telefonica.de [IPv6:2a01:c22:ad1c:cf00:5585:92d4:c169:1fb9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 9FFDF10A3309 for ; Sun, 12 Dec 2021 10:20:38 +0100 (CET) Date: Sun, 12 Dec 2021 10:20:32 +0100 From: FreeBSD User To: freebsd-current@freebsd.org Subject: CURRENT: ZFS freezes system beyond reboot Message-ID: <20211212102032.08af9689@jelly.fritz.box> Organization: FreeBSD in der Heimstatt List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: f6ad8b X-Rspamd-UID: 42ff9c X-Rspamd-Queue-Id: 4JBfJH4Zv8z3jZ5 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=TV9Vuee8; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [2.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.988]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(0.90)[0.900]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[walstatt-de.de]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_SPAM_LONG(0.89)[0.891]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Running CURRENT (FreeBSD 14.0-CURRENT #52 main-n251260-156fbc64857: Thu Dec 2 14:45:55 CET 2021 amd64), out of the sudden the ZFS RAIDZ pool suffered from an error: Solaris: WARNING: Pool 'POOL00' has encountered an uncorrectable I/O failure and has been suspended. The system does not repsond anymore on that pool, transactions to and from that pool are frozen, the system is 99.9% idle. The most "not so funny" part is: the box doesn't even recognize a "shutdown -r now" or a brute force "reboot". I still can login via ssh, but any action regarding the ZFS pool freezes the console/terminal. ZFS very often renders the system unresponsible forever. How can this be mitigated? The system in question is on a remote site and it seems not only to be bound to CURRENT, we realised similar problems on 13-STABLE as well. What can I do to "unfreeze" the ZFS? The main OS is, luckily, on an UFS/FFS filesystem and so not affected from that problem. By the way, here some more details, as far as I can pick those up: zpool clear POOL00 cannot clear errors for POOL00: I/O error Whatever took out the ZFS pool (can not see any hardware errors, the pool is part of services and especially a poudriere build system and under heavy load all the time, the box has 16 GB RAM), it also renders the rest of the system unusable in a way which is beyond a "reboot". Kind regrads, oh From nobody Sun Dec 12 16:45:06 2021 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 A165118D95E9 for ; Sun, 12 Dec 2021 16:45:23 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBr9H494qz3JMW for ; Sun, 12 Dec 2021 16:45:23 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oo1-f41.google.com with SMTP id d1-20020a4a3c01000000b002c2612c8e1eso3652674ooa.6 for ; Sun, 12 Dec 2021 08:45:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kuy6EO1jGnlHtgdbKXFtAqtLeCzaN6Zzj6wtST6ziRo=; b=bn32kRZX26VOfKwamZWThQTZEqRmy26RUahtIWTZTqpfDB/HBOz4ZPKGB0Fv2i/v8x KeIAAvwZd9sJR8sCtjg7rE0fmPRqlIX1/BQnA2pwsLrH4xBgVIX4KcZjcxmnVs22AHuf UV9SeEk10310p41+jyDzwDE0mqWoBPtCqm01+moRmClD1b/q8SdqeBJ6Yy81NeQTMayk TB4+UUOUJKUvm4SHPKp1+qhBc2x30q/z1Q037cjyI7ql4NA5BDmPBWCaVEwFPgrtnLiq Cy5t9It0tEhZrNLvlc2fs9+VHwQrijcu2zNY+ubxd50R4nvqUq6QqNvz87b7ZOOqAjm0 ve9w== X-Gm-Message-State: AOAM530hNxnYCbKZ88WMhv+qykXthcxDcCOYAQZMYt8GyMo1y0JcVFH3 kC19ahjhZ1VSepkvcQu3CS2NXE5WEGz3bY/SAbHmx5bB X-Google-Smtp-Source: ABdhPJy/CKSDueKdUHIERZbUU8/VGI4K0WL2pWIevrCTQD3CWzR7nFvuRIi+v/sJMfprxNGK38X30MLmm3d9JOF7B6A= X-Received: by 2002:a4a:e1a9:: with SMTP id 9mr16371440ooy.41.1639327517464; Sun, 12 Dec 2021 08:45:17 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211212102032.08af9689@jelly.fritz.box> In-Reply-To: <20211212102032.08af9689@jelly.fritz.box> From: Alan Somers Date: Sun, 12 Dec 2021 09:45:06 -0700 Message-ID: Subject: Re: CURRENT: ZFS freezes system beyond reboot To: FreeBSD User Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JBr9H494qz3JMW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Dec 12, 2021 at 2:22 AM FreeBSD User wrote: > > Running CURRENT (FreeBSD 14.0-CURRENT #52 main-n251260-156fbc64857: Thu > Dec 2 14:45:55 CET 2021 amd64), out of the sudden the ZFS RAIDZ pool > suffered from an error: > > Solaris: WARNING: Pool 'POOL00' has encountered an uncorrectable I/O > failure and has been suspended. > > The system does not repsond anymore on that pool, transactions to and > from that pool are frozen, the system is 99.9% idle. > The most "not so funny" part is: the box doesn't even recognize a > "shutdown -r now" or a brute force "reboot". I still can login via ssh, > but any action regarding the ZFS pool freezes the console/terminal. > > ZFS very often renders the system unresponsible forever. How can this > be mitigated? The system in question is on a remote site and it seems > not only to be bound to CURRENT, we realised similar problems on > 13-STABLE as well. > > What can I do to "unfreeze" the ZFS? The main OS is, luckily, on an > UFS/FFS filesystem and so not affected from that problem. > > By the way, here some more details, as far as I can pick those up: > > zpool clear POOL00 cannot clear errors for POOL00: I/O error > > Whatever took out the ZFS pool (can not see any hardware errors, the > pool is part of services and especially a poudriere build system and > under heavy load all the time, the box has 16 GB RAM), it also renders > the rest of the system unusable in a way which is beyond a "reboot". > > Kind regrads, > oh You need to look at what's causing those errors. What kind of disks are you using, with what HBA? It's not surprising that any access to ZFS hangs; that's what it's designed to do when a pool is suspended. From nobody Sun Dec 12 19:03:18 2021 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 3267018D4C75 for ; Sun, 12 Dec 2021 19:03:32 +0000 (UTC) (envelope-from SRS0=ytTNz9=Q5=codenetworks.net=sm@eigbox.net) Received: from bosmailout06.eigbox.net (bosmailout06.eigbox.net [66.96.184.6]) (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 4JBvDg3Cxcz3sYv for ; Sun, 12 Dec 2021 19:03:31 +0000 (UTC) (envelope-from SRS0=ytTNz9=Q5=codenetworks.net=sm@eigbox.net) Received: from bosmailscan01.eigbox.net ([10.20.15.1]) by bosmailout06.eigbox.net with esmtp (Exim) id 1mwU84-0004AV-RN for freebsd-current@freebsd.org; Sun, 12 Dec 2021 14:03:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codenetworks.net; s=dkim; h=Sender:Content-Transfer-Encoding:Content-Type: In-Reply-To:Subject:From:References:To:MIME-Version:Date:Message-ID:Reply-To: Cc:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6+d64sIgYn/A8VeLhg4zA74EOlvKVHizwGhlQw17U3I=; b=GS+prJtoofQm3SbkdRarcv1zXV zjv1HZNxl9yL9Y8upqtfUHc/G2k1Rh5JqhdQDN5od9pEXejOpbQatBVwYdaCJl4CbtD0d2TkPt+Iq c9oz+nLYx3O1Rwuze8lcRyyhRj4IOp4FOdUo4aBZaodMjmuFWM1mQpFsHo6Kz1uu9VkWfW7JXCpoL B+4DX/g1j3GDGV4ItFHIOMFi//xRnqltHRNYitcKN9IohcbeEs0ZMo56/AhocTWN35uqGEvvqqWiu 2FsLjDIM7gyfhGZdaLKszHmKDG0XPvjgpYGqgLxj16JXZzKMpWpBx7dYL7nMeiddhwgGyTpgNIn2g qwopht9g==; Received: from [10.115.3.33] (helo=bosimpout13) by bosmailscan01.eigbox.net with esmtp (Exim) id 1mwU84-0005JX-Ew for freebsd-current@freebsd.org; Sun, 12 Dec 2021 14:03:24 -0500 Received: from bosauthsmtp19.yourhostingaccount.com ([10.20.18.19]) by bosimpout13 with id VX3M260040QhFXN01X3Qhk; Sun, 12 Dec 2021 14:03:24 -0500 X-Authority-Analysis: v=2.3 cv=RNUo47q+ c=1 sm=1 tr=0 a=9UqFsMnAB6EOkiq4MrOclQ==:117 a=Ek/qOh1uPkKSHvd30yk7rg==:17 a=IkcTkHD0fZMA:10 a=IOMw9HtfNCkA:10 a=-Yl_685HdVUA:10 a=T_zuiYmE3fyN60bNvLYA:9 a=QEXdDO2ut3YA:10 Received: from cm-81-9-194-73.telecable.es ([81.9.194.73]:26463 helo=[192.168.1.100]) by bosauthsmtp19.eigbox.net with esmtpa (Exim) id 1mwU80-0001ek-TX for freebsd-current@freebsd.org; Sun, 12 Dec 2021 14:03:21 -0500 Message-ID: Date: Sun, 12 Dec 2021 20:03:18 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: freebsd-current@freebsd.org References: <47ca4ab6-52cf-8dbe-a1f0-7db13a8f605d@quip.cz> From: Santiago Martinez Subject: Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-EN-UserInfo: d3bdfab0736480cedf04ed92aaea2ef5:931c98230c6409dcc37fa7e93b490c27 X-EN-AuthUser: sm@codenetworks.net X-EN-OrigIP: 81.9.194.73 X-EN-OrigHost: cm-81-9-194-73.telecable.es X-Rspamd-Queue-Id: 4JBvDg3Cxcz3sYv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=codenetworks.net header.s=dkim header.b=GS+prJto; dmarc=none; spf=pass (mx1.freebsd.org: domain of "SRS0=ytTNz9=Q5=codenetworks.net=sm@eigbox.net" designates 66.96.184.6 as permitted sender) smtp.mailfrom="SRS0=ytTNz9=Q5=codenetworks.net=sm@eigbox.net" X-Spamd-Result: default: False [-0.39 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-0.35)[-0.355]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.96.128.0/18]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[codenetworks.net: no valid DMARC record]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[codenetworks.net:~]; NEURAL_SPAM_LONG(0.96)[0.963]; RCVD_IN_DNSWL_NONE(0.00)[66.96.184.6:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_PERMFAIL(0.00)[codenetworks.net:s=dkim]; FORGED_SENDER(0.30)[sm@codenetworks.net,SRS0=ytTNz9=Q5=codenetworks.net=sm@eigbox.net]; RECEIVED_SPAMHAUS_PBL(0.00)[81.9.194.73:received]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29873, ipnet:66.96.128.0/18, country:US]; FROM_NEQ_ENVFROM(0.00)[sm@codenetworks.net,SRS0=ytTNz9=Q5=codenetworks.net=sm@eigbox.net]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi there, sorry for the ignorance, but which are the best settings for sysctl? I guess, it depends on the workload that one is executing, right? But based on the emails, I understand some basic ones can be applied to help with general applications, am I right? If that's the case, can we attempt to list them? I am happy to create a list, document and categorize them based on workloads, I believe it will be a good starting point for normal users (like me). I do have a small list of sysctls that I usually apply, but they are all mostly related to networking and particular to our client's setup. Best regards. Santi On 12/11/21 12:20, dmilith . wrote: > Maybe FreeBSD wouldn't win but results would be much closer. It's also > known that default compiler options for ports aren't best. Default > sysctl.conf default settings aren't best. They could at least compile all > the benchmarks with the same compiler features. So -ffast-math, -flto and > -O3 + code hardening features, for all tested systems. It's also > professional to mention the compiler used (I recall that the previous > Phroenix "benchmark" was done using GCC on FreeBSD which I'll not even > comment). > > I could go on with all mistakes made in this "benchmark", but well, I know > - benchmarking is hard. > > > On Sat, 11 Dec 2021 at 12:01, Miroslav Lachman <000.fbsd@quip.cz> wrote: > >> On 11/12/2021 11:17, dmilith . wrote: >>> 1. Where are compiler options for BSDs? >>> 2. Why they compare -O2 to -O3 code in some benchmarks? Why they enable >>> fast math in some, and disable it for others? >>> 3. Why they don't mention powerd setup for FreeBSD? By default it may use >>> slowest CPU mode. Did they even load cpufreq kernel module? >>> 4. Did they even care about default FreeBSD mitigations (via sysctl) >>> enabled, or it's only valid for Linuxes? ;) >>> 5. What happened to security and environment details of BSDs? >>> >>> It's kinda known that guys from Phroenix lack basic knowledge of how to >> do >>> proper performance testing and lack basic knowledge about BSD systems. >>> Nothing new. Would take these results with a grain of salt. >> It is very simple - they are comparing OSes with setting they are >> shipped. Average users don't know about tuning so the benchmark is >> reflecting what many average users get. >> And to be honest - I don't think FreeBSD will win even with everything >> best tuned. >> >> Kind regards >> Miroslav Lachman >> > From nobody Mon Dec 13 02:22:23 2021 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 93A2018E49BE; Mon, 13 Dec 2021 02:22:31 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JC4zB3Yk6z4Vst; Mon, 13 Dec 2021 02:22:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BD2MN81041496 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 12 Dec 2021 18:22:23 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BD2MN7g041495; Sun, 12 Dec 2021 18:22:23 -0800 (PST) (envelope-from sgk) Date: Sun, 12 Dec 2021 18:22:23 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211213022223.GA41440@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JC4zB3Yk6z4Vst X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-2.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 04, 2021 at 11:48:13PM +0000, Mark Murray wrote: > > > > On 4 Dec 2021, at 18:53, Steve Kargl wrote: > > > > > > So, is anyone interested in seeing a massive patch? > > Me, please! > So, I have the ld80 case working. I'll open a PR if on does not exist. The pr will contain 1) Diff for nonfunctional changes to code for tgamma(x). This is a re-organization of the code so I could reverse it. Some cleanup of comments and documentations. A move towards style(9) 2) Advice on what to do about tgammal(x) on ld128 hardware. Essentially, need to do the git equivalent of 'svn mv imprecise.c ld128/b_tgammal.c. 3) Diff with the new code for ld80 tgamma. Interval tested for tgammal: [6,1755.1] 5000000 calls, 2.056068 secs, 0.41121 usecs/call ulp <= 0.5: 90.233% 4511666 | 90.233% 4511666 0.5 < ulp < 0.6: 7.061% 353033 | 97.294% 4864699 0.6 < ulp < 0.7: 2.393% 119644 | 99.687% 4984343 0.7 < ulp < 0.8: 0.300% 14981 | 99.986% 4999324 0.8 < ulp < 0.9: 0.014% 676 | 100.000% 5000000 Max ulp: 0.873414 at 1.480588145237629047468e+03 Interval tested for tgammal: [1.0662,6] 5000000 calls, 0.748966 secs, 0.14979 usecs/call ulp <= 0.5: 96.355% 4817737 | 96.355% 4817737 0.5 < ulp < 0.6: 3.291% 164534 | 99.645% 4982271 0.6 < ulp < 0.7: 0.328% 16403 | 99.973% 4998674 0.7 < ulp < 0.8: 0.026% 1297 | 99.999% 4999971 0.8 < ulp < 0.9: 0.001% 29 | 100.000% 5000000 Max ulp: 0.861508 at 1.999467927053585410537e+00 Interval tested for tgammal: [1.01e-17,1.0661] 5000000 calls, 0.904246 secs, 0.18085 usecs/call ulp <= 0.5: 96.201% 4810043 | 96.201% 4810043 0.5 < ulp < 0.6: 3.297% 164875 | 99.498% 4974918 0.6 < ulp < 0.7: 0.412% 20581 | 99.910% 4995499 0.7 < ulp < 0.8: 0.082% 4108 | 99.992% 4999607 0.8 < ulp < 0.9: 0.008% 389 | 100.000% 4999996 0.9 < ulp < 1.0: 0.000% 4 | 100.000% 5000000 Max ulp: 0.938041 at 1.023286481537296307856e+00 Interval tested for tgammal: [-1.9999,-1.0001] 5000000 calls, 1.740820 secs, 0.34816 usecs/call ulp <= 0.5: 56.596% 2829776 | 56.596% 2829776 0.5 < ulp < 0.6: 8.616% 430793 | 65.211% 3260569 0.6 < ulp < 0.7: 7.452% 372621 | 72.664% 3633190 0.7 < ulp < 0.8: 6.250% 312511 | 78.914% 3945701 0.8 < ulp < 0.9: 5.147% 257372 | 84.061% 4203073 0.9 < ulp < 1.0: 4.100% 205010 | 88.162% 4408083 1.0 < ulp < 1.5: 9.846% 492324 | 98.008% 4900407 1.5 < ulp < 2.0: 1.790% 89514 | 99.798% 4989921 2.0 < ulp < 3.0: 0.201% 10074 | 100.000% 4999995 3.0 < ulp < 0.0: 0.000% 5 | 100.000% 5000000 -- Steve From nobody Mon Dec 13 02:31:20 2021 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 966EC18E79D1 for ; Mon, 13 Dec 2021 02:31:35 +0000 (UTC) (envelope-from frank@tomatoservers.com) Received: from mail5.25mail.st (mail5.25mail.st [74.50.62.9]) (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 4JC59f4lHzz4Z1N for ; Mon, 13 Dec 2021 02:31:34 +0000 (UTC) (envelope-from frank@tomatoservers.com) Received: from [10.192.0.14] (unknown [178.128.95.176]) by mail5.25mail.st (Postfix) with ESMTPSA id 2B9D8603C8 for ; Mon, 13 Dec 2021 02:31:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tomatoservers.com; s=25mailst; t=1639362688; bh=RJt/bbZ0y7sonx6i8+vlLQSUquavlfEfnboy1iRAp4A=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Svt6spntEAd2A5VaOeJOivSdP8B45iJm1r+k82Jy/gBhZZ26GzFqbssHNIlf7x/qw DiYlBxmoY/4DjwS0buXGOWpWqS3oHuDqA+UYulYiiWMG2sqaar1q0rMeGiZF0+kQCb Od3t3LYDjBkZ+UcX6uqwXp7zlDKP37v4jQLZJMMI1LmPnc4/ARhiRPnbQTezxCervh xHesB0eN2yBKp6OzJLiohpb22FdyPCzBAybG+N8Tv+UHcwwx7P2mUebGJbZ8bFV6zx uUzVPg9S1p6miseH5Z84bkuaDQkUPYJ/pwHtNdZ/t8s0ZxcB1tyHsNDJ0DyaVPxwwl tvNKVtGLRZoJg== Message-ID: <5f2d681b-e74b-a7bb-eca0-3f2c40533c69@tomatoservers.com> Date: Mon, 13 Dec 2021 10:31:20 +0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: root passwd lost Content-Language: en-US To: freebsd-current@freebsd.org References: <47ca4ab6-52cf-8dbe-a1f0-7db13a8f605d@quip.cz> From: Frank Hwa In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JC59f4lHzz4Z1N X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tomatoservers.com header.s=25mailst header.b=Svt6spnt; dmarc=pass (policy=none) header.from=tomatoservers.com; spf=pass (mx1.freebsd.org: domain of frank@tomatoservers.com designates 74.50.62.9 as permitted sender) smtp.mailfrom=frank@tomatoservers.com X-Spamd-Result: default: False [0.01 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[tomatoservers.com:s=25mailst]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; SEM_URIBL_FRESH15(3.00)[tomatoservers.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(0.00)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; DKIM_TRACE(0.00)[tomatoservers.com:+]; DMARC_POLICY_ALLOW(0.00)[tomatoservers.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36024, ipnet:74.50.48.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Can you help me with the case I lost my root password for the dedicated server which has freebsd installed? Thanks in advance. From nobody Mon Dec 13 02:46:50 2021 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 946F818EB32C for ; Mon, 13 Dec 2021 02:47:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JC5Wb3hmZz4chw for ; Mon, 13 Dec 2021 02:47:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oo1-f49.google.com with SMTP id v19-20020a4a2453000000b002bb88bfb594so3872439oov.4 for ; Sun, 12 Dec 2021 18:47:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4g7dc1clm1X4GlvPBfipiq9g+pYp7dfWhOuA97Tyz/E=; b=QJnUfRM71hGa7QMXdPexeXqZ32z1sxDwkLV94kEqfMPG5NkMByz9U1h4tF1qH5H56v lKBy5fO+BNo+7uV3mubYGtc9GoFGBuD+8NzZHYvX/ppwKKm0zO1Jcx0+5b2GNhaMvMH/ 1I7xOvZh2Me/gc+UIaJUG0olozQMqM5byP92bhnZVYzZdzKZRSr5SApCLER8ZzYFvQXP gtCR0Z7s5HFcF1MUUVxXxTaWrfO9X77hcpS/v+9HgwaEygDP6qEoFcPy/Tw6+Z5amVWs ueui2ndG/DOXvpOrcTjL9lL+49719j+CgDtyN9vnv1F8kpkgR/MRVWKD2H8yx77HncpR 6Mzg== X-Gm-Message-State: AOAM53294OxYb65gzy/r8D+ORtrpv7qF00suosxLRjZ8RZr0e81riCk5 +Ic+FcuFGwpIGNwMuYcB63E4S40cHMDC1MV4SFk= X-Google-Smtp-Source: ABdhPJzzBVZowExEPAroG3tW2l271JLOlb/y/Bbckt558UdD/UzleWhC4iwqEyjwN61Kfq9ooBN7gusfUt4jhFSjGuo= X-Received: by 2002:a4a:e1a9:: with SMTP id 9mr17866776ooy.41.1639363621628; Sun, 12 Dec 2021 18:47:01 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <47ca4ab6-52cf-8dbe-a1f0-7db13a8f605d@quip.cz> <5f2d681b-e74b-a7bb-eca0-3f2c40533c69@tomatoservers.com> In-Reply-To: <5f2d681b-e74b-a7bb-eca0-3f2c40533c69@tomatoservers.com> From: Alan Somers Date: Sun, 12 Dec 2021 19:46:50 -0700 Message-ID: Subject: Re: root passwd lost To: Frank Hwa Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JC5Wb3hmZz4chw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Sun, Dec 12, 2021 at 7:33 PM Frank Hwa wrote: > > Can you help me with the case I lost my root password for the dedicated > server which has freebsd installed? > > Thanks in advance. Easy, you just need console access. First reboot it. At the loader prompt, select "Boot single user". Then after the kernel loads you'll find yourself automatically at a root prompt, without needing to login. Change your password using passwd, then exit the shell to continue normal boot. You may need to remount your / filesystem rw in order to change the password. That can be done with "mount -u -w /" -Alan From nobody Mon Dec 13 07:30:50 2021 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 7B77118D5388 for ; Mon, 13 Dec 2021 07:30:53 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCCq12Nyxz3PV9; Mon, 13 Dec 2021 07:30:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id B65CA24009; Mon, 13 Dec 2021 07:30:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Mon, 13 Dec 2021 09:30:50 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.0 Subject: Re: CURRENT: ZFS freezes system beyond reboot Content-Language: en-US To: Alan Somers , FreeBSD User Cc: FreeBSD CURRENT References: <20211212102032.08af9689@jelly.fritz.box> From: Andriy Gapon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639380653; 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=izlf0xYrKuJcX2O3IUEaXwLWl7yTzGTyP9nlvPo1hLY=; b=gg11E56p+XNLDNhByCgU5QYIQX8qpTKsXpQ18HNPW7hKvwkjr6c4VZWFEZ5lUkQrMs/ZZL SonDq/1UT6BpjOIA2Nmb4FI1b8jXipNZly/O78MfjiZ3QrOBaoDRWUyVK0JDxYR+IF1mtY UgWU/ZUwEK3/5gbDbibLB6TvN4b59HI4pAAMNuJLeC00VoSDfzU1otEBP+NPRTDq34vit2 cpnEu8+HznnRDS8FqnQGCPBoesvqonO4WDu9+7+xTiuz6pb4zJog1H8WCBSbAUGAmbN+hX s37r6bl3Ez1jevrA0NtBmLRneea6e/MFR25bdDc0wi6JgVgH3SOhdV/3nfYVxw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639380653; a=rsa-sha256; cv=none; b=bsgetSiEGm/tG5tv+uJ0Fd+nRPJgIlST8X0rm8rgMbqfuQadMPIcDjjND5nRT4PRXmSnUx stFn7PZEzga9fHdo4LyTMtZFZ5RckR9wrc65MJEzVasz0fNAg3Bb++FNEYoNTyl5/5TNda yB7JqJSBoXEn3jokhgZVgX8dBFX/gexdBRtwUjMBCwyrvqDrrxy/9oKW46OaKMWCuMdski X3kBLao42FnzFfSENo3XcaPGhzghYFS66aJgFL1F3SCKmkB2P4/TEGXnDATLkubzlYLHTP jMHnW9SNPQsM2J+QvGIT5umgCIL+zWq8qiCtvEfqjw5sl8BkJ5J5v33X02b1pA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/12/2021 18:45, Alan Somers wrote: > You need to look at what's causing those errors. What kind of disks > are you using, with what HBA? It's not surprising that any access to > ZFS hangs; that's what it's designed to do when a pool is suspended. However, a pool does not have to be suspended on errors. failmode property provides a couple of alternatives: wait Blocks all I/O access until the device connectivity is recovered and the errors are cleared. This is the default behavior. continue Returns EIO to any new write I/O requests but allows reads to any of the remaining healthy devices. Any write requests that have yet to be committed to disk would be blocked. panic Prints out a message to the console and generates a system crash dump. But neither does any magic. The errors will still be there. -- Andriy Gapon From nobody Mon Dec 13 15:45:07 2021 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 1096518E9CAE; Mon, 13 Dec 2021 15:45:10 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCQnK4tmKz3p5m; Mon, 13 Dec 2021 15:45:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [IPV6:2601:648:8601:8b20:b8bf:4bdc:6c55:cbbe] (unknown [IPv6:2601:648:8601:8b20:b8bf:4bdc:6c55:cbbe]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 199AF27F56; Mon, 13 Dec 2021 15:45:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> Date: Mon, 13 Dec 2021 07:45:07 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Gleb Smirnoff Cc: "freebsd-current@freebsd.org" , x11@FreeBSD.org From: John Baldwin Subject: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639410309; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=YJ22Q5zdjxhfowYtVZIEmNZOSG16cSE2z7m8/oETB8Q=; b=xFd8Y7VGFCQjNSmAPbMHjQEL0LrtZ3uNvK009NwGmGDPsmC3k3nH2HovPAxZNBEBBgDAqb i4ujasSKktGyEXjX/WX/zSscfk83etuoF9UJPaVRRWjT07MwoCQYeKA4DQMErNvQynUDuU kDrrzWXF8RJqE2l6+izbeMX0okj27m38tg8fesW8wEn0N72yzxahzSwGMK4gtObxg8slLq YufCRXoh4S6GgqLuAzFda0ANyo6FoCox/UgQBpliI+IRvl+8Bw57z+lCFsm58PJdnekB1H 0xI+Y69fO5McTfXp+TuRiER0TtxvsBXCx5uP91UDpZkUUXn83AqPeJ0PWpAnCw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639410309; a=rsa-sha256; cv=none; b=QpBCJsJ9qCgAMWsdZMHh95GEhgwT2v4B8VCYgSiSBeQI3yWpIBtE/f9T3MRjUUCC6H8Imw U0n0T05yjrqlOvUqJ7DKOfpaHmUHjSmps85X15LkULsRbmO42mvcDlZyfWhwdcp2NQukZy vEiRZNinevU7q9IRrJslWhG7NzfA0+Z8kh4PtE+fxlPrEZvD9CUw3C7csc76dAKQjcdxvT 88TTOjVvWKmEWwDjrK5mpwK5z4v2UN/7BVitt5bc2fyAqI2DL4iekGtnEkiPf4Lq+L+mQz 9AjiCdGPCnlss1Vk8MypqHDcauli8e+KyoGAc56rkb351cV9P9kSDVpmgJhtzQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This weekend I upgraded my FreeBSD laptop and kicked off a poudriere build of the packages I use. My laptop kept "freezing" during the package builds however. Initially due to messages in /var/log/messages I thought it was running out of swap and killing the display server. After poking it at off and on over the weekend I finally narrowed it down to building the devel/apr1 port, and built it on the console (rather than X) and was greeted with the following panic: panic: malloc(M_WAITOK) with sleeping prohibited cpuid = 7 time = 1639374072 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe001e5b55b0 vpanic() at vpanic+0x17f/frame 0xfffffe001e5b5600 panic() at panic+0x43/frame 0xfffffe001e5b5660 malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe001e5b5680 malloc() at malloc+0x2d/frame 0xfffffe001e5b56c0 intel_atomic_state_alloc() at intel_atomic_state_alloc+0x20/frame 0xfffffe001e5b56e0 drm_client_modeset_commit_atomic() at drm_client_modeset_commit_atomic+0x30/frame 0xfffffe001e5b5750 drm_client_modeset_commit_force() at drm_client_modeset_commit_force+0x6f/frame 0xfffffe001e5b5790 drm_fb_helper_restore_fbdev_mode_unlocked() at drm_fb_helper_restore_fbdev_mode_unlocked+0x82/frame 0xfffffe001e5b57c0 vt_kms_postswitch() at vt_kms_postswitch+0x18b/frame 0xfffffe001e5b57f0 vt_window_switch() at vt_window_switch+0x261/frame 0xfffffe001e5b5830 vtterm_cngrab() at vtterm_cngrab+0x4f/frame 0xfffffe001e5b5850 cngrab() at cngrab+0x26/frame 0xfffffe001e5b5870 vpanic() at vpanic+0xee/frame 0xfffffe001e5b58c0 panic() at panic+0x43/frame 0xfffffe001e5b5920 witness_checkorder() at witness_checkorder+0xd1c/frame 0xfffffe001e5b5ae0 __mtx_lock_flags() at __mtx_lock_flags+0x94/frame 0xfffffe001e5b5b30 prison_check_ip4() at prison_check_ip4+0x51/frame 0xfffffe001e5b5b60 in_pcblookup_hash_locked() at in_pcblookup_hash_locked+0x2b6/frame 0xfffffe001e5b5bc0 in_pcblookup_mbuf() at in_pcblookup_mbuf+0x84/frame 0xfffffe001e5b5c00 tcp_input_with_port() at tcp_input_with_port+0x635/frame 0xfffffe001e5b5d50 tcp_input() at tcp_input+0xb/frame 0xfffffe001e5b5d60 ip_input() at ip_input+0x25e/frame 0xfffffe001e5b5de0 swi_net() at swi_net+0x1a1/frame 0xfffffe001e5b5e60 ithread_loop() at ithread_loop+0x279/frame 0xfffffe001e5b5ef0 fork_exit() at fork_exit+0x80/frame 0xfffffe001e5b5f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe001e5b5f30 --- trap 0x61e8cb8b, rip = 0x8b48000000f890ff, rsp = 0x52ff38244c8d4800, rbp = 0x245c8948ccc35f20 --- So there are two things here. The root issue is that the devel/apr1 port runs a configure test for TCP_NDELAY being inherited by accepted sockets. This test panics because prison_check_ip4() tries to lock a prison mutex to walk the IPs assigned to a jail, but the caller (in_pcblookup_hash()) has done an smr_enter() which is a critical_enter(): (kgdb) p panicstr $1 = 0xffffffff81ea90b0 "acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) jail mutex @ /usr/src/sys/netinet/in_jail.c:418" (kgdb) frame 39 #39 0xffffffff80dbcf71 in prison_check_ip4 (cred=, ia=ia@entry=0xfffffe001e5b5b90) at /usr/src/sys/netinet/in_jail.c:418 418 mtx_lock(&pr->pr_mtx); (kgdb) l 413 KASSERT(ia != NULL, ("%s: ia is NULL", __func__)); 414 415 pr = cred->cr_prison; 416 if (!(pr->pr_flags & PR_IP4)) 417 return (0); 418 mtx_lock(&pr->pr_mtx); 419 if (!(pr->pr_flags & PR_IP4)) { 420 mtx_unlock(&pr->pr_mtx); 421 return (0); 422 } (kgdb) up #41 0xffffffff80dc5cb4 in in_pcblookup_hash (pcbinfo=0xfffffe0022db7748, faddr=..., fport=2166892021, laddr=..., lport=0, lookupflags=, numa_domain=56 '8', ifp=) at /usr/src/sys/netinet/in_pcb.c:2387 2387 inp = in_pcblookup_hash_locked(pcbinfo, faddr, fport, laddr, lport, (kgdb) l 2382 struct ifnet *ifp, uint8_t numa_domain) 2383 { 2384 struct inpcb *inp; 2385 2386 smr_enter(pcbinfo->ipi_smr); 2387 inp = in_pcblookup_hash_locked(pcbinfo, faddr, fport, laddr, lport, 2388 lookupflags & INPLOOKUP_WILDCARD, ifp, numa_domain); 2389 if (inp != NULL) { 2390 if (__predict_false(inp_smr_lock(inp, 2391 (lookupflags & INPLOOKUP_LOCKMASK)) == false)) However, it was a bit harder to see this originally as the 915kms driver tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a bad idea). When it panicked in X the result was that the screen just froze on whatever it had most recently drawn and the machine looked hung. (The fact that that sysbeep is off so I couldn't tell if typing in commands was doing anything vs emitting errors probably didn't improve trying to diagnose the hang as "sitting in ddb" initially, though I don't know if DDB itself emits a beep for invalid commands, etc.) -- John Baldwin From nobody Mon Dec 13 16:26:42 2021 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 533E118D2442 for ; Mon, 13 Dec 2021 16:26:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670055.outbound.protection.outlook.com [40.107.67.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCRjW3Q2mz3vW2 for ; Mon, 13 Dec 2021 16:26:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HxeSV18hVFwJMYVluH5BblDWUkKe7F4t0DU/dlLdN0dOrZWGrSxxJ8y4X7CbqRDXoJEEA8zzjS/2bh+TPtcJGf5RzwsVQeHOIM7+4xJzjG+DcocE+V8UBBE4d/sh9L8Nsha0VER00tj5M5ups2H37waVzy89WgUp284NA5B7qMPUIibe9H8sZruvnp6zTKAEfIn4Q4tcnLqyP1BR7ZxovpiiDBI4YF4GNOsP/LNbilebvNfAWgJI+Kv1sV+xzom6k74YGtpAbEhO1apM4WD/4voypy1zk4sxNU6hcO7YxmIt5Olf5KgY6niFso6FMaf0HdJa6XhJdRMPr0YDU7nFeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HR/R5gsPub0Nmc55KIVX3T5XxeMKVMQTv/RgpmaPZRw=; b=h7iWKlk+9TTLFY7U0JkZCsCNIIK9lTBDUuXhgNukI+Ec6a8rcdGV9YbxD5zEG0p1x5QiUeKTKFPiRkFUCxkj3jU43xEHvzFOqKhFcSNC+juQqpJ/iWKoAbVE5K5YRn9CWD0S/d53Pa+mGwxajdTJs+2KjqF6eTQDH+6yIlX4qNMT4NcGIzoJwuwGcq0gLoO+ypI543kHog1RmRpeq9Nz7x+3wTt/c24jpCSosrO5cQDlEUQ2/0OCQt/YpHuLSIJ7y5D6mD5eApUI8C1Ch8fcW/YAL7mjqEX0jFeVklUQeSBrc8F/zrqW99DQpDkgiSn05cLjiFACKqUOpgbVbekyVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HR/R5gsPub0Nmc55KIVX3T5XxeMKVMQTv/RgpmaPZRw=; b=NKtiaXihBlXu8qrOCoXbhslB4rWxaE/UFXwxdnJvhgmJqOdQG7HVsJ9EWNu3d6XwOFg++Dsa1Kdv01lRMLIEA9IDaN1c/whM1uC/0jc8g4K9o2H0WyjnFhRjqQ1H779/TkqHE4VEvgCBHgZbYgm9JCfwwMitpcRFuIl32CgqsX2klt5fR5R1AS+p4iq3z9FUmWAWdidsAoYirsaPlntnqz3lXnPvwHXmXFF5PIV12o6CG8+prixSCPQjh72EI/dTqB6vOC9Qeyio9MV0zYBdLvgX+uvH3vpP0jdti7cu6GYc4VakhboWwBYzX2JbLP+TAJtUNZhnWl57L828uHNtpw== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB6075.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:28::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.11; Mon, 13 Dec 2021 16:26:48 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::e56f:b7a2:3830:5706]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::e56f:b7a2:3830:5706%3]) with mapi id 15.20.4778.017; Mon, 13 Dec 2021 16:26:42 +0000 From: Rick Macklem To: FreeBSD Current Subject: RFC: What to do about Allocate in the NFS server for FreeBSD13? Thread-Topic: RFC: What to do about Allocate in the NFS server for FreeBSD13? Thread-Index: AQHX8DzJnOLrzTHZ6EiZFqH7GNa45g== Date: Mon, 13 Dec 2021 16:26:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 9369b04c-e59b-aff7-3f30-30ed0597c2b5 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b02922b-a2b1-438e-bdc6-08d9be555904 x-ms-traffictypediagnostic: YQXPR01MB6075:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2+ENsQczeA0l9S+lu2/GvK4wRfTrehDoooGSL0/kM1VxAggDt5F21hijmc9WFaiCJHhrhzguEDMcowXTIktrnBmS+r2NgwGx4mrnPN/FamuyWxu/c4NjdDJUCILA9I4NINvJLFR4BDakOdwq3Ikfn5HhLwk12olNR/P+gBFj45WK3G0CYfKdTacXVZ2hHxH5ITXK51tQedO9Jq897thNZIXuYLfyR/4XPWwB/60aVoLrt/7Vy5xHhBpHfryum/1FTOddzZLf+/G3znkUZL2a6R0SZCsMJvcMgbJq+AcaFJH7Cjtj90wkMI7rrKdD3c5rTvuq9ZC3grmOow5OBS+/yBL24ijs8HcKqDoAXEDth8r1X7V3l+xARK85ULh4af9vDfnukKGT7pDYCLrDenfiZWPZ9Z54GMfzj3msE8yln8N3OGUfbQpJV/8vQh0YdBnEwgoZ7DqovqaqRO5M3i6YZj3HgNLJcTK+jY1AzlvksaCy+iDcNmUXANqdiweLpwC2sNUdJeEtXGjzHbAR0Y+7bwdw/QZmHhxHrv0xnJakB8pUWSRtVFK5Wo9sJfbw9TkiP9ByAxBOrzleWh5YzkJaPG1EoDYXKOQRR50RuooLxvbv00uyI2WR1BdN2GMJwnE71qWHAsPpK07Qq2VB47AE/uV2+b2uMkEPT4YIKz2XSGyKJLN838qb5k6ujXFbsvFR x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(5660300002)(55016003)(83380400001)(71200400001)(33656002)(2906002)(122000001)(38100700002)(786003)(316002)(186003)(38070700005)(8936002)(52536014)(6506007)(6916009)(508600001)(66946007)(9686003)(64756008)(66446008)(86362001)(66556008)(8676002)(7696005)(76116006)(91956017)(66476007);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?A/ha7qUlYak2XMI1w7PDNAFbJqJKIMunb1vOl4RT2Q8n26MtmIJ5KbD4BO?= =?iso-8859-1?Q?nr/OiIvAc+SuAt9eChDbHmAc02s8qpngyV9Z2VgKlzfs11BeTsvbRXgNY4?= =?iso-8859-1?Q?VxHt9K7BhsHsRRRQWtKOOU8KSZxHJG1VturOZt60GKLG8HsS7ULKpz8rfT?= =?iso-8859-1?Q?xHa9lgsmG8M4qzDzucn9/aF0aaOJCBuPAtkNuDAitAA1qWWvNqTDUm6ydd?= =?iso-8859-1?Q?7WP7fwrL+aILcCwkm5lY/edTFCjFjRmYC/ir2FYD0t2qmUe8y9p4ajNg8z?= =?iso-8859-1?Q?LL2MMv6weRReq4KXFG9ngCEBFNaZTz6p1ZMRV8PwUIUUoiv7rDdxHqsNCk?= =?iso-8859-1?Q?G6X5cNJ1QcDs272wy2Ho2ay85wsmieBXJEdbe2232niaZRGWXhHqj9tuEi?= =?iso-8859-1?Q?hk//K+eXdH11Z4RKoWzcZ8lFGDfkYI1VnhkSuXVbYrcSolkm1SCKTIAiYg?= =?iso-8859-1?Q?ghofHWh7Ym4pPKhhSYjPVNdGXwFTRTf6I0t7P60dL1exrXz3+zTXEnhXXn?= =?iso-8859-1?Q?ueAsp32G7GoX0eS+3DBxbCKAVgjtpJ8arOPGXkCXqECqZgXTDqlNkcWd9O?= =?iso-8859-1?Q?fL8i2rQQkdKgmscWsGGaFUa+PmcjB+hjMiZZrEG4YVoK0ACA8xWLQOLDqU?= =?iso-8859-1?Q?qLE63sh/5vNuNxSN3aL5Vh+RfIGK6g4HDmQNXTw8oh8kzS4bZnfsYWqOw1?= =?iso-8859-1?Q?eU0ZTEdO745lvCg0lxytehbGjCHCNvBzPPiVHP/wdhRmxiI7YxSQrVb3wB?= =?iso-8859-1?Q?PIGSvEpbbKdkp9vHBIHk2oI4My0UGTS2aV9ly0O5QOKUjppShIKwPDfV6Y?= =?iso-8859-1?Q?t7uVjX0xG8gG0sBvKkVPUK40J+wsInVdWNjCcoidJtgazEiKmA+VFXyDNc?= =?iso-8859-1?Q?ItaMXynv52PcXGsRYSGj6ShuO2iiCnnCRL+/bcz3acqSofFYzG0kXSfERB?= =?iso-8859-1?Q?nRK5YNmDThHU3l2RnUsD/+x0szU/rFkYjIkdwTwt0rS/EyxX6T89CQ0Fis?= =?iso-8859-1?Q?f8KRdG3dIE1Pyr8+X22BSaOqheFKEKby9v2VLdhi5O8+G7D9vWIlKCjP+Z?= =?iso-8859-1?Q?DboPOMD+JK+PvYsATb1wTJ8ONoXemfdVYoiVs/uQNUVN9CnO91/jmM715d?= =?iso-8859-1?Q?TvNpj9eRvvy6o8cJrIZGS2zcJjGmbOS5P7jHgYCliCvaEHmkG7B18zu/as?= =?iso-8859-1?Q?cm2m1edZnvZa4O1hsZ2RXa5H1JxoSgWThhDj/xGVeFHrUex6we42XIcGzj?= =?iso-8859-1?Q?CO5CDH418qG5h1UtQUrbsWSCmQWzjYF9ELaB8qgExO9wnGmKgj9JPOb0EC?= =?iso-8859-1?Q?wQqEjNRGRKYdCwsvAL/FPzJH6IZ4LKtciU+1MrKDfVhakeGO2ChCKgpEdI?= =?iso-8859-1?Q?A+B4UWAwyVwyFQ8iCP/lBAUdubY0V8z6FeXN9FCxiu1j2//5fvQwfSd4wK?= =?iso-8859-1?Q?J/mCUXu1oNgqNbtMet2284oy5xSk2QgdbDKZXf9g+G3TnWo4xO2hM4g267?= =?iso-8859-1?Q?CJdMsmBLhuAbsHMGz5sXotfJPKaxZZzt/MDOwRTaBV4c9YlCts3F43PbQ2?= =?iso-8859-1?Q?p5Hnb61gH75T1yIIdFXcUIhWU4CRQtrHpQBOMuhVSjbmiXyVerZL9dv41V?= =?iso-8859-1?Q?el/6J6CMqqd+qhsnbREN5afeFZ481AhECC7YAbO2AVzVhOLp/vFMhGDKDL?= =?iso-8859-1?Q?lS01ehBLynsXbhj6rStaQ5WjI0hanZHVDgUEbAg6o9IdA12ROn4mbWB7uF?= =?iso-8859-1?Q?1C1Q=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9b02922b-a2b1-438e-bdc6-08d9be555904 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2021 16:26:42.3736 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6vve/Y3IEn426hYnvoXRPWzTvM0uX2s+7vwuE4T/FWTAt6mW3QmzfiuppZ/ULxBY4nCpgXo6ToCE4idoew4Gtw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB6075 X-Rspamd-Queue-Id: 4JCRjW3Q2mz3vW2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=NKtiaXih; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.55 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.86 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.55:from]; NEURAL_HAM_SHORT(-0.87)[-0.872]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.55:from] X-ThisMailContainsUnwantedMimeParts: N Hi,=0A= =0A= There are two problems with Allocate in the NFSv4.2 server in FreeBSD13:=0A= 1 - It uses the thread credentials instead of the ones for the RPC.=0A= 2 - It does not ensure that file changes are committed to stable storage.= =0A= These problems are fixed by commit f0c9847a6c47 in main, which added=0A= ioflag and cred arguments to VOP_ALLOCATE().=0A= =0A= I can think of 3 ways to fix Allocate in FreeBSD13:=0A= 1 - Apply a *hackish* patch like this:=0A= + savcred =3D p->td_ucred;=0A= + td->td_ucred =3D cred;=0A= do {=0A= olen =3D len;=0A= error =3D VOP_ALLOCATE(vp, &off, &len);=0A= if (error =3D=3D 0 && len > 0 && olen > len)=0A= maybe_yield();=0A= } while (error =3D=3D 0 && len > 0 && olen > len);=0A= + p->td_ucred =3D savcred;=0A= if (error =3D=3D 0 && len > 0)=0A= error =3D NFSERR_IO;=0A= + if (error =3D=3D 0)=0A= + error =3D VOP_FSYNC(vp, MNT_WAIT, p);=0A= The worst part of it is temporarily setting td_ucred to cred.=0A= =0A= 2 - MFC'ng commit f0c9847a6c47. Normally changes to the=0A= VOP/VFS are not MFC'd. However, in this case, it might be=0A= ok to do so, since it is unlikely there is an out of source tree=0A= file system with a custom VOP_ALLOCATE() method?=0A= =0A= 3 - Just disable it. Currently it is disabled by default and it=0A= could just be wired down disabled.=0A= Allocate is not that useful, since ZFS does not support it.=0A= =0A= As an aside to this, the IETF NFSv4 working group seems to=0A= have agreed that NFS4ERR_NOTSUPP can be returned by a=0A= NFSv4.2 server on a 'per file system basis" instead of globally,=0A= since the Linux knfsd already does this.=0A= --> As such, Allocate can be enabled by default in main and=0A= could be enabled by default in FreeBSD13, if #1 or #2 was=0A= done.=0A= --> It still would not work for ZFS exports.=0A= =0A= So, what do you think is the preferred alternative?=0A= =0A= rick=0A= From nobody Mon Dec 13 16:30:44 2021 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 1759318D3F31 for ; Mon, 13 Dec 2021 16:30: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 4JCRp35lYfz4RSG for ; Mon, 13 Dec 2021 16:30:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1BDGUiEG055385 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 13 Dec 2021 18:30:47 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1BDGUiEG055385 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1BDGUiUi055384; Mon, 13 Dec 2021 18:30:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 13 Dec 2021 18:30:44 +0200 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD Current Subject: Re: RFC: What to do about Allocate in the NFS server for FreeBSD13? 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=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4JCRp35lYfz4RSG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 13, 2021 at 04:26:42PM +0000, Rick Macklem wrote: > Hi, > > There are two problems with Allocate in the NFSv4.2 server in FreeBSD13: > 1 - It uses the thread credentials instead of the ones for the RPC. > 2 - It does not ensure that file changes are committed to stable storage. > These problems are fixed by commit f0c9847a6c47 in main, which added > ioflag and cred arguments to VOP_ALLOCATE(). > > I can think of 3 ways to fix Allocate in FreeBSD13: > 1 - Apply a *hackish* patch like this: > + savcred = p->td_ucred; > + td->td_ucred = cred; > do { > olen = len; > error = VOP_ALLOCATE(vp, &off, &len); > if (error == 0 && len > 0 && olen > len) > maybe_yield(); > } while (error == 0 && len > 0 && olen > len); > + p->td_ucred = savcred; > if (error == 0 && len > 0) > error = NFSERR_IO; > + if (error == 0) > + error = VOP_FSYNC(vp, MNT_WAIT, p); > The worst part of it is temporarily setting td_ucred to cred. > > 2 - MFC'ng commit f0c9847a6c47. Normally changes to the > VOP/VFS are not MFC'd. However, in this case, it might be > ok to do so, since it is unlikely there is an out of source tree > file system with a custom VOP_ALLOCATE() method? I do not see much wrong with #2, this is what I would do myself. > > 3 - Just disable it. Currently it is disabled by default and it > could just be wired down disabled. > Allocate is not that useful, since ZFS does not support it. > > As an aside to this, the IETF NFSv4 working group seems to > have agreed that NFS4ERR_NOTSUPP can be returned by a > NFSv4.2 server on a 'per file system basis" instead of globally, > since the Linux knfsd already does this. > --> As such, Allocate can be enabled by default in main and > could be enabled by default in FreeBSD13, if #1 or #2 was > done. > --> It still would not work for ZFS exports. > > So, what do you think is the preferred alternative? > > rick > From nobody Mon Dec 13 17:01:43 2021 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 35C3B18DBF53; Mon, 13 Dec 2021 17:01:44 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCSTh122Rz4Yhb; Mon, 13 Dec 2021 17:01:44 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639414904; 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=e7zXsd8QaIirnRlS8GswGsFCSg6Z13zQFY6CmdlwWus=; b=uWdM3DItRbcTLIm1TITDX5K6XoybHcFw4k6Ti7A1dJYoQjTsW9ixfuBmvyy9hPCMwIeT6a uamnwX3WzIJzG1wHxF76LxAkMxT9BbKjo3IgO6UiPcP8ba8vtrZ22FquzllHFdJcj1OuKd 4i9DhYrct/ZSVvj5KHhBog4agPbr9DIwFccbl8ySibEDLNt/f933oRR0jeGNKlGu+O33Lt 8JyiNB6ZelVKzQJ4DkPg43pR+Z4jSlUACDt3f8Kx1j8ykGXTPJP/oPi/smwsIPjRwoWIgS txA1Sq9kLLRpnKheVOEWgqQyBalc4N17aZ/kShbjcj0nG2yU/eG6X04KXG7r5A== Received: by freefall.freebsd.org (Postfix, from userid 1033) id E4F191B6B0; Mon, 13 Dec 2021 17:01:43 +0000 (UTC) Date: Mon, 13 Dec 2021 17:01:43 +0000 From: Alexey Dokuchaev To: John Baldwin Cc: Gleb Smirnoff , "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-ID: References: <1db0942e-0e66-4337-ce2f-4e1005107435@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: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639414904; 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=e7zXsd8QaIirnRlS8GswGsFCSg6Z13zQFY6CmdlwWus=; b=eUmw//TmdeQQQfEIYvaHrm1xoexmi3Afvm/TMkanbseVcPb5EaN9Wu5tBBkr5C83gQ0Y28 1ajxitwGGoKerA1WI4j2DofG0T39jS8C+9Y+H+fOVIcl0Rw1T35fFkEhYHTYIcALVYjdoy NGwRZxD+bXVZ6ddY7aX/Zj5H08qFOR8o+dp039pBmKB4AsQTn9KTorohsT0Sk68wMt5ugG MDkTk0jIeYijX1BW+LFTOl3urMaHTa54XLeoh4v202ozUH9bb2gAqHnHSSzi/RYeJGOSxD Xwg9kF97dfe1Em6Hd7n4UdtcGiN9tkdp0AoY65Yn5QA+7MG78CKk1Z70nsh6GQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639414904; a=rsa-sha256; cv=none; b=s/VheBQ0XtFc4yURLPQt3kFA5qb3O66Vocv9hWfylMUj7ECwExB+ueSyz0i6jsyFHOgBpA 9pIiZMMOSdEHK6dGBo/PRGoAGOdgDnZKNlcmWIb8S+rF96A08AEGHSl9f1en7qhLUq6/hd EAHXVKfJO+iRz14GwVXnwtFsaxNb0xYnvtYdoUwPxxOaIlwBLsVqe09BFuo+kKUaoke5ER hK1LpLRbmKnmOchCW2oYABDTLRHFJWsxb/4SJjq2rledMZqvSkmJDfY1PqxipD4XZSW7Jr COemGF9DGZkZJWZks5CTLDNQBdiIlweDWelgf7UGtyJvmTFezgV8aX5aio0GjA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote: > ... > However, it was a bit harder to see this originally as the 915kms driver > tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which > recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a > bad idea). Funny how these new Linuxish DRM bits could affect so many things. :( > The fact that that sysbeep is off so I couldn't tell if typing in commands > was doing anything vs emitting errors probably didn't improve trying to > diagnose the hang as "sitting in ddb" initially, though I don't know if > DDB itself emits a beep for invalid commands, etc. Now that Warner had fixed the beeper frequency, why we still didn't enable it back on by default? ./danfe From nobody Mon Dec 13 17:32:22 2021 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 79B3618E28C4; Mon, 13 Dec 2021 17:32:25 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCT945xCPz4fl8; Mon, 13 Dec 2021 17:32:24 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639416743; 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=fU+I89Wjj2X85Kap/m6L5c+PYT8nTsrwsLd1Z1L/NUk=; b=mKtfbKrA/i2qjEpcO8P/fwB+7LeP6fH2Q6mcDgoT/YxrNp0rvmWCF5FtzAXjsN35Oqh9gw Zo6mQ03sGyZZGemWD+S79prMrc3S/f3GSO0O0c6YqOgiLvK3N0SKkZExLOvPwAiEqFE5RA yR7yex6CaME0n2uyj3N7rquH8cIOJGY= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 88fb658f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 13 Dec 2021 17:32:22 +0000 (UTC) Date: Mon, 13 Dec 2021 18:32:22 +0100 From: Emmanuel Vadot To: Alexey Dokuchaev Cc: John Baldwin , Gleb Smirnoff , "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-Id: <20211213183222.f945b2e730f7c22dbe74681c@bidouilliste.com> In-Reply-To: References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JCT945xCPz4fl8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 13 Dec 2021 17:01:43 +0000 Alexey Dokuchaev wrote: > On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote: > > ... > > However, it was a bit harder to see this originally as the 915kms driver > > tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which > > recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a > > bad idea). > > Funny how these new Linuxish DRM bits could affect so many things. :( What is this comment about exactly ? > > The fact that that sysbeep is off so I couldn't tell if typing in commands > > was doing anything vs emitting errors probably didn't improve trying to > > diagnose the hang as "sitting in ddb" initially, though I don't know if > > DDB itself emits a beep for invalid commands, etc. > > Now that Warner had fixed the beeper frequency, why we still didn't enable > it back on by default? > > ./danfe > Because all people who wanted it off wasn't because it wasn't the right vt100 frequency, they just wanted it off. -- Emmanuel Vadot From nobody Mon Dec 13 17:35:42 2021 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 7204F18E442A; Mon, 13 Dec 2021 17:35:50 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCTF21Bgkz4hQ4; Mon, 13 Dec 2021 17:35:50 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BDHZgLI002335 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 13 Dec 2021 09:35:42 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BDHZgdx002334; Mon, 13 Dec 2021 09:35:42 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Mon, 13 Dec 2021 09:35:42 -0800 From: Gleb Smirnoff To: John Baldwin Cc: "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-ID: References: <1db0942e-0e66-4337-ce2f-4e1005107435@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: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> X-Rspamd-Queue-Id: 4JCTF21Bgkz4hQ4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi John, On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote: J> So there are two things here. The root issue is that the devel/apr1 port J> runs a configure test for TCP_NDELAY being inherited by accepted sockets. J> This test panics because prison_check_ip4() tries to lock a prison mutex J> to walk the IPs assigned to a jail, but the caller (in_pcblookup_hash()) has J> done an smr_enter() which is a critical_enter(): The first one is known, and I got a patch to fix it: https://reviews.freebsd.org/D33340 However, a pre-requisite to this simple patch is more complex: https://reviews.freebsd.org/D33339 There is some discussion on how to improve that, and I decided to do that rather than stick to original version. So I takes a few extra days. We could push D33340 into main, if the negative effects (raciness of the prison check) is considered lesser evil then potentially contested mtx_lock in smr section. J> However, it was a bit harder to see this originally as the 915kms driver J> tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which J> recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a J> bad idea). When it panicked in X the result was that the screen just froze J> on whatever it had most recently drawn and the machine looked hung. (The J> fact that that sysbeep is off so I couldn't tell if typing in commands was J> doing anything vs emitting errors probably didn't improve trying to diagnose J> the hang as "sitting in ddb" initially, though I don't know if DDB itself J> emits a beep for invalid commands, etc.) Didn't know about this one. Is this isolated to actually entering DDB or there is some path that in a normal inpcb lookup we would M_WAITOK? -- Gleb Smirnoff From nobody Mon Dec 13 19:56:35 2021 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 CD89418DF56C; Mon, 13 Dec 2021 19:56:36 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCXMS47J2z3Hmj; Mon, 13 Dec 2021 19:56:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 0FC61290BB; Mon, 13 Dec 2021 19:56:35 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <836761df-6eea-462b-9ae7-5d0d00aad38f@FreeBSD.org> Date: Mon, 13 Dec 2021 11:56:35 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Content-Language: en-US To: Gleb Smirnoff Cc: "freebsd-current@freebsd.org" , x11@freebsd.org References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639425396; 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=8bXe+2LnS3T4wPGE74Fsg9BspE9IXjbNMzlFbT6+c7s=; b=Y94gCqIiQN7JiC9Td6qdTO3b2gfV0ZEPe3zsUF+Ys+MqmXB4FSROX1Z5Z9/20qrhpQF5EM wxRUs77fgfQJ40pmvrc1jjQaDORaifrg1OQcI6YWjk6OcgvAcfr4tTU2gCBSoXg8O0aaOV ZmDIIMZQa50/I9sR/jO2mvj/adJGjymFccQL0caffwr6vcAeK3BoLMPkTNiQCyAuSCCa7R NPxwAq2Q/+WOCarmP4kmgvXXfyaobXLnSrqK+h88iuZKDC0m64rI54vUr+QxmcWjRc4161 yed8XFPZO9hV/z40/MHAENYQauynCKi6AaNnyHR5YqV9dAcdXGXsnhrS1olndA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639425396; a=rsa-sha256; cv=none; b=yO93r+GU0MnakHjebxEL048tWEmtuDG7xkKS8ZkSeznhxJ3HUDT0bPB5xQALNbwdOR2AWC MRYUbMOK8Pn4jIQGbJ4c323sDKTKE8POo00hxiPxyfHEldBiDXPpicVfJL2j6HJRAV5O2k +S/Fj9F1P1xPzTNK0WjupAS3LGOJG+eBUU/at6jdPWJd73NgLZcoAD/NwMD/7/heZ9yJmo Iq/rQB2YA7jxjv5oLcXCSgb6TH7d2g7yZmtc8d8tVtzdLIQzqp+E4ALHIaRMGerrJn9z3p FEO5jDf/XFZ+miLWjtpHmgNX2KWBvFQ7zEdl0VKV5PML1MtBaKSsJWtlP94u8A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/13/21 9:35 AM, Gleb Smirnoff wrote: > Hi John, > > On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote: > J> So there are two things here. The root issue is that the devel/apr1 port > J> runs a configure test for TCP_NDELAY being inherited by accepted sockets. > J> This test panics because prison_check_ip4() tries to lock a prison mutex > J> to walk the IPs assigned to a jail, but the caller (in_pcblookup_hash()) has > J> done an smr_enter() which is a critical_enter(): > > The first one is known, and I got a patch to fix it: > > https://reviews.freebsd.org/D33340 > > However, a pre-requisite to this simple patch is more complex: > > https://reviews.freebsd.org/D33339 > > There is some discussion on how to improve that, and I decided to do that > rather than stick to original version. So I takes a few extra days. > > We could push D33340 into main, if the negative effects (raciness of > the prison check) is considered lesser evil then potentially contested > mtx_lock in smr section. I think raciness is probably better than always panicking as it does today. > J> However, it was a bit harder to see this originally as the 915kms driver > J> tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which > J> recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a > J> bad idea). When it panicked in X the result was that the screen just froze > J> on whatever it had most recently drawn and the machine looked hung. (The > J> fact that that sysbeep is off so I couldn't tell if typing in commands was > J> doing anything vs emitting errors probably didn't improve trying to diagnose > J> the hang as "sitting in ddb" initially, though I don't know if DDB itself > J> emits a beep for invalid commands, etc.) > > Didn't know about this one. Is this isolated to actually entering DDB or > there is some path that in a normal inpcb lookup we would M_WAITOK? This is in the drm(4) driver, nothing to do with in_pcb, just made it harder to see the in_pcb issue. -- John Baldwin From nobody Mon Dec 13 20:25:55 2021 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 2B8B218E5604; Mon, 13 Dec 2021 20:25:58 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCY1K6XDzz3Mjj; Mon, 13 Dec 2021 20:25:57 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BDKPtW8003561 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 13 Dec 2021 12:25:55 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BDKPtb3003560; Mon, 13 Dec 2021 12:25:55 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Mon, 13 Dec 2021 12:25:55 -0800 From: Gleb Smirnoff To: John Baldwin Cc: "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-ID: References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <836761df-6eea-462b-9ae7-5d0d00aad38f@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: <836761df-6eea-462b-9ae7-5d0d00aad38f@FreeBSD.org> X-Rspamd-Queue-Id: 4JCY1K6XDzz3Mjj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 13, 2021 at 11:56:35AM -0800, John Baldwin wrote: J> > J> So there are two things here. The root issue is that the devel/apr1 port J> > J> runs a configure test for TCP_NDELAY being inherited by accepted sockets. J> > J> This test panics because prison_check_ip4() tries to lock a prison mutex J> > J> to walk the IPs assigned to a jail, but the caller (in_pcblookup_hash()) has J> > J> done an smr_enter() which is a critical_enter(): J> > J> > The first one is known, and I got a patch to fix it: J> > J> > https://reviews.freebsd.org/D33340 J> > J> > However, a pre-requisite to this simple patch is more complex: J> > J> > https://reviews.freebsd.org/D33339 J> > J> > There is some discussion on how to improve that, and I decided to do that J> > rather than stick to original version. So I takes a few extra days. J> > J> > We could push D33340 into main, if the negative effects (raciness of J> > the prison check) is considered lesser evil then potentially contested J> > mtx_lock in smr section. J> J> I think raciness is probably better than always panicking as it does today. AFAIK, today it will always panic only with WITNESS. Without WITNESS it would pass through mtx_lock as long as the mutex is not locked. So, do you suggest to push D33340 before finalizing D33339? -- Gleb Smirnoff From nobody Tue Dec 14 02:47:34 2021 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 2C89E18EAF1E for ; Tue, 14 Dec 2021 02:47:47 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCjTt2MsQz3P8g for ; Tue, 14 Dec 2021 02:47:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f53.google.com with SMTP id x43-20020a056830246b00b00570d09d34ebso19558159otr.2 for ; Mon, 13 Dec 2021 18:47:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=z23JtZ25VQqGBV1VbKXvLNoM0Norp0hBApQGvNcip6k=; b=sEUxSBqPUpIKU5bbXV7ViTlIUMTvUN5BZJVmFU2WrO7HV0sUkMaGN3SBZ3VVQVwtEQ eicXZTaq0emojFLXJEU3Hl60jEeybPQm0os27MEXCfKJvO3AhpDbQU7aRtZ9bxoBJLmY rwSwsmYDJ+xNBa3VrWzQlWpnI0R7pqrOm1ut8REOWVvSUTmUHqKcXxpeVa+/VWNfQSNB QjrYcbPZnbw6hnC/r4RmwOmHMgom9gAfXguEvf2/iZwXDEi/cRx7hnYCTlLyrcmE5reZ Lp8WCyEXzuesidUu4FlbqBp8+L/wgmMHQKMeyNGBelyJ1lttVQgDk1jSjpP06P6DVsDL /frQ== X-Gm-Message-State: AOAM532bpjNYS14Y20nSzqPU8+iHjruNCtOpbrAQiDBcQXBqLsyZCaR1 QUqZEbcl6nw5ajQmtknb/PQvt/omr5EslDjAPcZLfF9uBJs= X-Google-Smtp-Source: ABdhPJxziMgaYJ40WM8nemTSiZpv0UzoVIOHHO0s15wlax1bdpIl9wmtVNNY/Uu9EPOEPPxZIRYM5kZ/qiBlu9gKNUw= X-Received: by 2002:a9d:7cce:: with SMTP id r14mr2062048otn.114.1639450065190; Mon, 13 Dec 2021 18:47:45 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Alan Somers Date: Mon, 13 Dec 2021 19:47:34 -0700 Message-ID: Subject: Fixing VOP_READDIR for 64-bit directory cookies To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JCjTt2MsQz3P8g X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.53 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-1.65 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.53:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.35)[0.350]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.53:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N tldr; this change allows the NFS server to export file systems that use 64-bit directory cookies https://reviews.freebsd.org/D33404 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260375 Long story: NFSv2 included a 32-bit directory cookie with each readdir entry. NFSv3 widened it to 64-bits, and FreeBSD's SVN r22521 raised VOP_READDIR's cookies argument to a u_long. That's 64-bits on some architectures, but 32-bits on others. But since the NFS server is the only caller that uses cookies, VOP_READDIR really ought to use a 64-bit type on all architectures. For NVSv2-exported file systems, the NFS server will ignore the top 32-bits of the cookie. There are no in-tree file systems that use more than 32 bits for their directory cookies, but it matters for some FUSE file systems. Does anybody have any opinions about this change, or about whether/how to MFC it? -Alan From nobody Tue Dec 14 02:59:17 2021 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 79EA418ED0E8 for ; Tue, 14 Dec 2021 02:59:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCjlK2rJWz3R1g; Tue, 14 Dec 2021 02:59:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qk1-x72c.google.com with SMTP id 193so15684649qkh.10; Mon, 13 Dec 2021 18:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=i7KzN+8vqE2zcbMGsLaGSyVxCjA75urUUw9h7tcYsak=; b=GR9JAkf+ET5Xuu/kuvWnoN40+UYAhRs8dis6nLZcWDY60tDELwf7s7E8S3HYbpfQBg SdAt1/8QlOrR3PgPj7tLwzFpOXDYunwAI+vy4j6RDQ2bV9NufXFEMDYKYdUXSd7ermXT jtilerNeHaPi1/hC9M6M/XX90SoRoPC0JdyR77/+i/jNlUCWTKf8NSaEBJdyhq3kzHjl SSRzcENPsohQQznqYnrgcuNCO09f7I8rgWDMm6FS29AJ2SvWp1TGhwgpuynbkTCq9nHb tocYsHik2ra51RwdfzPiKdU8sWyX530PE+waHl73F2f6Rvud4fglDNtw6gcVmInKoJ82 /LVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=i7KzN+8vqE2zcbMGsLaGSyVxCjA75urUUw9h7tcYsak=; b=8KIgm1oJYv8+5z2TZ8FWDkXXQref3wnJWQaLPkoTOld0znweR+f12C9n6QMnSeo7nh Fx8Xz/iAZZVIxKeS1a8WkOou9BSBbZoXBBOSh4bMqoho+J1CzDF9azCX5BjjiZzsTrTT nEcm+8le+h969QA5QUGKJjpSCej4qQzapMYdmsXzh+11JMEQDlSyeyLnTDFjfN2ybzop qTV+W0kgoRSs7KzSmYa5KBElZtuXO2sc2h/7BSsiRqXzZOVr/fqdRz2Xl3wDb8IjlMPr gKWE7SZ+f/xkF+neZ2h/V49dTmB03NItb9jfUp3X9lpehJTZnWTpxMhFVfjXVYft9azh /SpA== X-Gm-Message-State: AOAM533zMzwYRJ2ER6X537hTV5Q3IQ2DbYj6iu5AYDxqs1suu16rydF/ 7MyWaxBw6T1WIx6ekfRYLrvf2PUQDR8= X-Google-Smtp-Source: ABdhPJwwQnpbB8AnI7/LtObXm24an8U5jwuPfMnLQh2WVUoK6YycLEkb7Q2QgSlHtqNxt71+XanbWw== X-Received: by 2002:a05:620a:4103:: with SMTP id j3mr1922211qko.737.1639450758857; Mon, 13 Dec 2021 18:59:18 -0800 (PST) Received: from spectre.mavhome.dp.ua (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id 196sm6784852qkd.61.2021.12.13.18.59.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Dec 2021 18:59:18 -0800 (PST) Subject: Re: Fixing VOP_READDIR for 64-bit directory cookies To: Alan Somers , FreeBSD CURRENT References: From: Alexander Motin Message-ID: <95f70cff-e02e-7f05-f529-1978667f651e@FreeBSD.org> Date: Mon, 13 Dec 2021 21:59:17 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.13.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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JCjlK2rJWz3R1g X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 13.12.2021 21:47, Alan Somers wrote: > tldr; this change allows the NFS server to export file systems that > use 64-bit directory cookies > https://reviews.freebsd.org/D33404 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260375 > > Long story: > NFSv2 included a 32-bit directory cookie with each readdir entry. > NFSv3 widened it to 64-bits, and FreeBSD's SVN r22521 raised > VOP_READDIR's cookies argument to a u_long. That's 64-bits on some > architectures, but 32-bits on others. But since the NFS server is the > only caller that uses cookies, VOP_READDIR really ought to use a > 64-bit type on all architectures. For NVSv2-exported file systems, > the NFS server will ignore the top 32-bits of the cookie. > > There are no in-tree file systems that use more than 32 bits for their > directory cookies, but it matters for some FUSE file systems. > > Does anybody have any opinions about this change, or about whether/how > to MFC it? Since changing the VOP_READDIR argument type will probably break external file system modules I'd say it is not acceptable for MFC. But merge of the NFS part only should fix the issue for the 64-bit machines, which should be good enough for the most people. -- Alexander Motin From nobody Tue Dec 14 07:11:28 2021 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 4472D18D3F58; Tue, 14 Dec 2021 07:11:29 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCqL91W0fz4jXJ; Tue, 14 Dec 2021 07:11:29 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639465889; 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=v3ET69j5wEbHx0RMBbjjnVyhMMSqZuEUqSgM4G38kcs=; b=cPDRnIBIz7Wxu/nMPw0YJ5xk7jta3WF4Owyf+7ca6TbU5CqUgvKc4ROkUdmOraNU1yHJHX iuW0dONwqbAFSBxfhZXSPDTNxPK/LmUhYvVTpFn4bG5OHsU9MEI++IA1vvDzE7ERC7a7hZ DS/ZnwatQUJjoKl+XHO8We5jmS2bhJntQDcBM3zP/HjVINqzuAyPKKYlnHc+XNeVNxhk66 suiYrPwiA0PXaj+8LrycP4Tc9LUmOp/JIqCOdCQxoPj232uRfLYrD/xmsV6XAJrPIZ3evA ba+kVg24Rl+EcFJSb3t6jfok2iQQ6SVblJhWm/SYFCrw0erZJBKDZLqNdlnJsA== Received: by freefall.freebsd.org (Postfix, from userid 1033) id 1041B1DFA7; Tue, 14 Dec 2021 07:11:29 +0000 (UTC) Date: Tue, 14 Dec 2021 07:11:28 +0000 From: Alexey Dokuchaev To: Emmanuel Vadot Cc: John Baldwin , Gleb Smirnoff , "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-ID: References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <20211213183222.f945b2e730f7c22dbe74681c@bidouilliste.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: <20211213183222.f945b2e730f7c22dbe74681c@bidouilliste.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639465889; 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=v3ET69j5wEbHx0RMBbjjnVyhMMSqZuEUqSgM4G38kcs=; b=Hwd8zO9qEh9ju8b3yf98EFKSqJ4yBAOn6SqhGcmlRMfJdmiUusmwd9oAskuFgDFeKtSVzp eq7+yWJ3t6gaMnZMlI9AzJlWkIKZ8YSARM7Qs7dl36mU80Y+1zjEo0UiXrgc5D3r14mwog nB7RmAHPfaY4ZPOKhJpQakK+BY0XFoYy3ujMODLwxWGKgLnOGroTyjWZxanHOKtR0F8V2A GrGZdz+Lu1MURrYaKoeos58U+v8079haZaREGLuqVP+PKS1Qr48aulg5WOwyBYh/wb7u9a L8OgVuCnKAmvoPMw2/Sveh+JtSh9PgEXvuIGfSBOi+/CFe3vejUosvJJb/c2Kw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639465889; a=rsa-sha256; cv=none; b=nu7MXXDyv2Z0zgsjDhnQJ7Y8bWSa1GWElDUF9rozMA3KqzHHDl+ZJSoSK+YfQORPJJVxrM fr+LRAZjNrmP2Rv1uJ+8kqeyNaAjbAm/897SjV9XJ12CCpd7+nZPC2S+qOVgEVlKR6kGp8 lfUC7A9gZy2seZmeArCthYC0v/j4+OmV58U3Ky9HEJVZ6MPOzcU2OU1ZcOsg/1E3I12yqc 8OhaRsRnneqf/RSnZxA2cAsXG6E7ukoZCH80L0MWtorMxMRDT8kIlBN12j31BEwnbFesGU 9ShemFm5GLNxmuOAkMxBm79X0aJYoJuHAGnZLPPF26WeMpzyORsTl5la6TiQAg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 13, 2021 at 06:32:22PM +0100, Emmanuel Vadot wrote: > On Mon, 13 Dec 2021 17:01:43 +0000 Alexey Dokuchaev wrote: > > On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote: > > > ... > > > However, it was a bit harder to see this originally as the 915kms driver > > > tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which > > > recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a > > > bad idea). > > > > Funny how these new Linuxish DRM bits could affect so many things. :( > > What is this comment about exactly? Oh, you know, it's about steadily deteriorating quality of our gfx stack once we had started pulling things from Linux. > > > The fact that that sysbeep is off so I couldn't tell if typing in commands > > > was doing anything vs emitting errors probably didn't improve trying to > > > diagnose the hang as "sitting in ddb" initially, though I don't know if > > > DDB itself emits a beep for invalid commands, etc. > > > > Now that Warner had fixed the beeper frequency, why we still didn't enable > > it back on by default? > > Because all people who wanted it off wasn't because it wasn't the > right vt100 frequency, they just wanted it off. In FreeBSD chat and with less biased poll than the one Warner had posted on Twitter, most people had actually voted against making it off by default: https://t.me/FreeBSD1/25129. If John's assumption that muting it pessimizes debugging is correct, it really leaves no strong reasons NOT to turn it back on by default. ./danfe From nobody Tue Dec 14 08:14:27 2021 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 BF09918E0DA0; Tue, 14 Dec 2021 08:14:45 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCrl90xNRz4sdJ; Tue, 14 Dec 2021 08:14:44 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639469668; 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=lSmkKcEIKkjTXXAJYyaKDkonvVY6u93s5RgDyzA94PI=; b=dhznHr+X8vg2GklN7TdxgGPr8MwYmYuem3aoKjvJS0smCRW3sseYyN9HnZWhxV0w4dVfZX 3TeIZ6d6b3ZgQLDNqtaBo0v5nE7ECAeqHU+yD9goZeFeb0DGxUV3ZAO3ufTgzujGKG/uD4 Iu/gQllvxz5nUJ4NrICIUfLLqZ4I7Vk= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 11358967 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 14 Dec 2021 08:14:28 +0000 (UTC) Date: Tue, 14 Dec 2021 09:14:27 +0100 From: Emmanuel Vadot To: Alexey Dokuchaev Cc: John Baldwin , Gleb Smirnoff , "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-Id: <20211214091427.c531cf51b0284d8a1165b9bb@bidouilliste.com> In-Reply-To: References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <20211213183222.f945b2e730f7c22dbe74681c@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JCrl90xNRz4sdJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 14 Dec 2021 07:11:28 +0000 Alexey Dokuchaev wrote: > On Mon, Dec 13, 2021 at 06:32:22PM +0100, Emmanuel Vadot wrote: > > On Mon, 13 Dec 2021 17:01:43 +0000 Alexey Dokuchaev wrote: > > > On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote: > > > > ... > > > > However, it was a bit harder to see this originally as the 915kms driver > > > > tries to do a malloc(M_WAITOK) from cn_grab() when entering DDB which > > > > recursively panics (even a malloc(M_NOWAIT) from cn_grab() is probably a > > > > bad idea). > > > > > > Funny how these new Linuxish DRM bits could affect so many things. :( > > > > What is this comment about exactly? > > Oh, you know, it's about steadily deteriorating quality of our gfx stack > once we had started pulling things from Linux. Right. That just proves that you know nothing and will just complain on everything "new". We've *always* pulled drm bits from Linux, always. What changed is that instead of, say, replacing all calls to kmalloc in the drm sources to our malloc we have stubs in linuxkpi. And this helped a lot, not patching the upstream sources helps us updating drm much faster. Now for John's case, this is very edge case. The panic happened in a critical section, which put us in a problematic state. I think that Linux can malloc almost all the time and we can't. Even if we had done drm porting "the old way" we will had the same problem. Getting the framebuffer working on a panic works today, unless this kind of stuff happens and I don't think that we can fix that (at least easily). > > > > The fact that that sysbeep is off so I couldn't tell if typing in commands > > > > was doing anything vs emitting errors probably didn't improve trying to > > > > diagnose the hang as "sitting in ddb" initially, though I don't know if > > > > DDB itself emits a beep for invalid commands, etc. > > > > > > Now that Warner had fixed the beeper frequency, why we still didn't enable > > > it back on by default? > > > > Because all people who wanted it off wasn't because it wasn't the > > right vt100 frequency, they just wanted it off. > > In FreeBSD chat and with less biased poll than the one Warner had posted > on Twitter, most people had actually voted against making it off by > default: https://t.me/FreeBSD1/25129. So nothing changes then ? > If John's assumption that muting > it pessimizes debugging is correct, it really leaves no strong reasons > NOT to turn it back on by default. > > ./danfe I wouldn't be opposed to enable the beep when we drop to ddb. It's already annoying to panic so adding annoying beep that *could* help in some edge cases isn't the end of the world. -- Emmanuel Vadot From nobody Tue Dec 14 08:33:55 2021 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 5281D18E6059; Tue, 14 Dec 2021 08:34:07 +0000 (UTC) (envelope-from kp@krion.cc) Received: from krion.cc (krion.cc [148.251.235.209]) (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 4JCs9W1RJVz4xJg; Tue, 14 Dec 2021 08:34:07 +0000 (UTC) (envelope-from kp@krion.cc) Date: Tue, 14 Dec 2021 09:33:55 +0100 From: Kirill Ponomarev To: Gleb Smirnoff Cc: John Baldwin , "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-ID: References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <836761df-6eea-462b-9ae7-5d0d00aad38f@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VX9rrHFS+3WhNl63" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JCs9W1RJVz4xJg X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --VX9rrHFS+3WhNl63 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/13, Gleb Smirnoff wrote: > On Mon, Dec 13, 2021 at 11:56:35AM -0800, John Baldwin wrote: > J> > J> So there are two things here. The root issue is that the devel/a= pr1 port > J> > J> runs a configure test for TCP_NDELAY being inherited by accepted = sockets. > J> > J> This test panics because prison_check_ip4() tries to lock a priso= n mutex > J> > J> to walk the IPs assigned to a jail, but the caller (in_pcblookup_= hash()) has > J> > J> done an smr_enter() which is a critical_enter(): > J> >=20 > J> > The first one is known, and I got a patch to fix it: > J> >=20 > J> > https://reviews.freebsd.org/D33340 > J> >=20 > J> > However, a pre-requisite to this simple patch is more complex: > J> >=20 > J> > https://reviews.freebsd.org/D33339 > J> >=20 > J> > There is some discussion on how to improve that, and I decided to do= that > J> > rather than stick to original version. So I takes a few extra days. > J> >=20 > J> > We could push D33340 into main, if the negative effects (raciness of > J> > the prison check) is considered lesser evil then potentially contest= ed > J> > mtx_lock in smr section. > J>=20 > J> I think raciness is probably better than always panicking as it does t= oday. >=20 > AFAIK, today it will always panic only with WITNESS. Without WITNESS it w= ould > pass through mtx_lock as long as the mutex is not locked. >=20 > So, do you suggest to push D33340 before finalizing D33339? It panics with GENERIC so I'd suggest to push D33340 or backout it temprorary until D33339 is solved. --VX9rrHFS+3WhNl63 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEJCHRFhEAQujKni1pDyI9/LMCykUFAmG4VvMACgkQDyI9/LMC ykXr0Qf+O05zkTDDyGkCIus5KN+bjiJBZPXS359O3s7VzypB+0Ukjz1TEND+xEe3 aTY/P9Pyg0qa4d4bdHoA0R0rujjORgreLOIJmxlWJKqoxP4dtGq0pOl2jGsSVPTo m0IrS8T9dfXL2F2+Lw3NBPYcD2BuNZeeRQbsLDJDZdxJRuk5JUvH5/pt1IfA+j3S XYSdFUV6a6N2BdPt3Aw8hgWPPBRmmEdbp/IAj6HteP9+xJYP+RrUMgVxFjYxsjiv TQLbFca77VEhBVtwyStkSWrZUjAGvYe5uckT09278ibpPoLovA3U5jgr8pehMwzi 7w3GMC2cnbg1kszvyOvnouGln8mF3Q== =PQha -----END PGP SIGNATURE----- --VX9rrHFS+3WhNl63-- From nobody Tue Dec 14 10:14:24 2021 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 A359B18F7EBF; Tue, 14 Dec 2021 10:14:24 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCvPD4J0Dz58Jw; Tue, 14 Dec 2021 10:14:24 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639476864; 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=utF9pyTXh52e+iOjrLXZKWlkuP/vfvI2nCAOh9hdiy4=; b=Ok7pu4XXfX6YKhnMvuE1DXC7TSvCygDuVsDYpNBAHVkEGx8VYXvGmMOwz6sHjMJ8VuCgmT xhWybfEeYt5mROPmTfDVJDE0TjglLqB9O8vTPtz25kxXklTr+Rd0rbKN+SqVAhcvQfCd6E EQXd3YI4a8mALWh5xgCJPIUO1mvyQhlweg54pd+DxJx/tfZyPIKgcVF6Xcs9b75fTUa9bt 18sbM/TpevZELOJyMVhcHsJ2aRQijUGMuTKh9GVF3SpRFW2/gSI9WaCf5oh92F8rw4/jPW xLcag58b/NICOGBtGXmy2Vvo7lalrz9S8tK2if3A9g9E/IDjYdxbbtVufegBVg== Received: by freefall.freebsd.org (Postfix, from userid 1033) id 7435E1E783; Tue, 14 Dec 2021 10:14:24 +0000 (UTC) Date: Tue, 14 Dec 2021 10:14:24 +0000 From: Alexey Dokuchaev To: Emmanuel Vadot Cc: John Baldwin , Gleb Smirnoff , "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-ID: References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <20211213183222.f945b2e730f7c22dbe74681c@bidouilliste.com> <20211214091427.c531cf51b0284d8a1165b9bb@bidouilliste.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: <20211214091427.c531cf51b0284d8a1165b9bb@bidouilliste.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639476864; 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=utF9pyTXh52e+iOjrLXZKWlkuP/vfvI2nCAOh9hdiy4=; b=SOFXPdWIitH2/MvFLu0ZmpgcoNZe6h056fC0i2tbR2ucDhHfvMqhl9UEEWnMQIjeES92Ha a94qS1WNlVesxPlZHGlxZ040HMmnO/E/kO4dT+2Y6e3WCP50s2+EHbjgMHqCeXQNiET8vN O6uONhdfBcthTbyLcdHxyRgCe2H23r4JvFCqBoj4tHM3rYBymbwO8J1uw+izeqpZYI8r9i wF3HcArCGCGaRjhOUv3rB6bXwD8QvWlm7N5QPed0KB1T57JInmvjTXzXFU30okuZDfH7kk otu8SarHcv5aM97T9q7jB5SFC1uUPruLMZdcgs+WT8qieQGlIFwsjVG2HLv+5A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639476864; a=rsa-sha256; cv=none; b=ddSPLGzBsa5ZXWSD0pEJy8O49uqivq/KmzKZ5/osmyAVO9Ab441PgO5FN65VVtsuaT+uMB xCiDcyBdv2UIMvu9d9cbV+aXsW2VDv5GBwrz514DwSjQX5tsn96AWPJ6AG6E4RoX9GwI6N NQ+gf2ZtvHFRk8+WGAkQARYpyWB8EAkntvDqvSbeiTF+7DCGodfZC7HQy5dhdgVdLS+xJ3 nmvJI3FNF0L/chaiB+CtC0cpR6fC4/luTNhy6V7nUPIh6R580LkFknjKZAXkw3rucZNhb0 +qkMZ2743okzswfSbU/esWLtwaAi0b5pGjMph4dcXP8cXzT6cdWq4dE1cBIicA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 09:14:27AM +0100, Emmanuel Vadot wrote: > On Tue, 14 Dec 2021 07:11:28 +0000 Alexey Dokuchaev wrote: > > ... > > Oh, you know, it's about steadily deteriorating quality of our gfx > > stack once we had started pulling things from Linux. > > Right. > That just proves that you know nothing and will just complain on > everything "new". I know that I had problemless desktop some 10-5 years ago, okayish desktop ~three years ago, tolerable experience with 4.16.x DRM bits and shitty one with current 5.4.x (FWIW, 5.x had been problematic for me since the beginning, but previously it was fairly easy to build drm-fbsd12.0-kmod on -CURRENT to avoid regressions, now the source bases had divered too far enough; it's probably still possible to patch, but would take longer time). > We've *always* pulled drm bits from Linux, always. You know what I've meant. > > In FreeBSD chat and with less biased poll than the one Warner had posted > > on Twitter, most people had actually voted against making it off by > > default: https://t.me/FreeBSD1/25129. > > So nothing changes then? How do you mean? Most FreeBSD people, not some random Twitter crowd, want the bell to be on by default, but it's still off. ./danfe From nobody Tue Dec 14 10:27:07 2021 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 41FD018D2A87; Tue, 14 Dec 2021 10:27:11 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCvgy3rJGz3D7F; Tue, 14 Dec 2021 10:27:10 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639477628; 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=gSol03+9Vgj5nNAaMkmj0bkWDRxOdH7KcggAsJuUQvI=; b=ATgqyIRjp3t4nm5+svKnTXnWv70MkHhHsxU+yePyASehvn4/aN8jh0N1lr7qFgVVvBYlJP qHDizOkK12nN3sR8/N5uamY3xIqgyOAkCR1tTb2QW9gqR0W0A5JZOOqUE3EFM8HEGJMaRZ 5wpAfClUUU2mdH6nFQTe5yjFnyFuRQg= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 134efced (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 14 Dec 2021 10:27:08 +0000 (UTC) Date: Tue, 14 Dec 2021 11:27:07 +0100 From: Emmanuel Vadot To: Alexey Dokuchaev Cc: John Baldwin , Gleb Smirnoff , "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-Id: <20211214112707.9bd528d32d6b8e3f2e3c62fe@bidouilliste.com> In-Reply-To: References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <20211213183222.f945b2e730f7c22dbe74681c@bidouilliste.com> <20211214091427.c531cf51b0284d8a1165b9bb@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JCvgy3rJGz3D7F X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 14 Dec 2021 10:14:24 +0000 Alexey Dokuchaev wrote: > On Tue, Dec 14, 2021 at 09:14:27AM +0100, Emmanuel Vadot wrote: > > On Tue, 14 Dec 2021 07:11:28 +0000 Alexey Dokuchaev wrote: > > > ... > > > Oh, you know, it's about steadily deteriorating quality of our gfx > > > stack once we had started pulling things from Linux. > > > > Right. > > That just proves that you know nothing and will just complain on > > everything "new". > > I know that I had problemless desktop some 10-5 years ago, okayish > desktop ~three years ago, tolerable experience with 4.16.x DRM bits > and shitty one with current 5.4.x (FWIW, 5.x had been problematic > for me since the beginning, but previously it was fairly easy to > build drm-fbsd12.0-kmod on -CURRENT to avoid regressions, now the > source bases had divered too far enough; it's probably still possible > to patch, but would take longer time). Any PR open for your issues ? > > We've *always* pulled drm bits from Linux, always. > > You know what I've meant. I do because I know the history, not everyone does. > > > In FreeBSD chat and with less biased poll than the one Warner had posted > > > on Twitter, most people had actually voted against making it off by > > > default: https://t.me/FreeBSD1/25129. > > > > So nothing changes then? > > How do you mean? Most FreeBSD people, not some random Twitter crowd, want > the bell to be on by default, but it's still off. > > ./danfe > Sorry I didn't see the "against". Well this telegram chat is still a community one, I don't see how it makes a difference. Also I can't see the poll result. -- Emmanuel Vadot From nobody Tue Dec 14 11:05:19 2021 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 042EC18DC89F; Tue, 14 Dec 2021 11:05:20 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCwWz6hs1z3MpQ; Tue, 14 Dec 2021 11:05:19 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639479919; 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=l/J/nw0MVXq3R+CK6a1TvqrmE+vxXgEr7+XAbvxNV1g=; b=MrfK7j11ykzTvCiBNVAd2j4pc0nCPIbMN+m19l/zok+nuiNZk6TYaCiNYOV2FASEWFe8/Z AEg1aQf0Wg5nUg4OF/BQXGYGNZNAFldcL9V3cwFmYUmT40rJB5WRNNkPvVExdjzshOc4RJ SdmBw9+qXOJb9KjjhmoHgFvOtAMSL2wOBrtNVFvcbCnlH2x8ErcSnQD8y4WgurbS+1tnUM Nepsz1R4SRhNpvcLn139s7CDMAs04jcs9KlU15QcPDtPj+ycjua6QLj2W+CIsdR+CvKsBR mXaexvygLrItkcpZLtztsLwszxvmzizrhkZ4GIL8XStFBCMze3I+bu/VnzM7YA== Received: by freefall.freebsd.org (Postfix, from userid 1033) id D70331EB20; Tue, 14 Dec 2021 11:05:19 +0000 (UTC) Date: Tue, 14 Dec 2021 11:05:19 +0000 From: Alexey Dokuchaev To: Emmanuel Vadot Cc: John Baldwin , Gleb Smirnoff , "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-ID: References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <20211213183222.f945b2e730f7c22dbe74681c@bidouilliste.com> <20211214091427.c531cf51b0284d8a1165b9bb@bidouilliste.com> <20211214112707.9bd528d32d6b8e3f2e3c62fe@bidouilliste.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: <20211214112707.9bd528d32d6b8e3f2e3c62fe@bidouilliste.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639479919; 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=l/J/nw0MVXq3R+CK6a1TvqrmE+vxXgEr7+XAbvxNV1g=; b=jsjzHGpuRLtflOq9yAAstBev6ecKj8TP5XoynqkwN0K1/brY5VeSeCu+ymeCK7yVZPcNmA WnrBJ6WnphXcDxRf16dsnmtKa/kVDiNx2r8dolitnkh97pxOBEWupMx+Re12nLyjYrW3nt OTxcJzwXbw5IQqiWoesjLl9ullKPp+dFBAlA7g6AGp+XT+1lu+vZYPbRjRkdKmMKBNjqzm IR5IjUoa6kvL48pnIABrjXPfkc1f3xL0CpJqk2UR6R4lICCz34CwNjc696Q2oDoCgU2R6H AUGfXC0xN2s2CJvuDqWqp/ez3IZkadaHwAtC7C6F7sDpSXYUrDZlqJnjTfrzpw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639479919; a=rsa-sha256; cv=none; b=SHmHkADPpV21NE8LCyJoTTJAml3AD18BWlBRNQLkSH17p9NZtJq1nXVl2eTXAw2VezZmDm J9YlDjqpA/aSCa9f499gvwPad66oqD+lc3fpk+P8sTasaP/V5vH60qt8uUpKEDrqRhuo8J oOIFlU0PxBRL+KVTOHDT2BMnchEkBw7nNusWQ12l1p8QqV8yvb78iiGU54pIdOUA85z/Vq vE0KdttP+ru55D21rd8e2dCNwF3iMR6AwEIj+p1TT1lq5Q9TyuUnnzMVcrEBWwb0kaVdkH jFgbKFXc4eLJhPg5UDw5Awyvbj4aqFJgNNSwOZosbQf51NbWVxe36C+ra7zrQg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 11:27:07AM +0100, Emmanuel Vadot wrote: > On Tue, 14 Dec 2021 10:14:24 +0000 Alexey Dokuchaev wrote: > > ... > > I know that I had problemless desktop some 10-5 years ago, okayish > > desktop ~three years ago, tolerable experience with 4.16.x DRM bits > > and shitty one with current 5.4.x (FWIW, 5.x had been problematic > > for me since the beginning, but previously it was fairly easy to > > build drm-fbsd12.0-kmod on -CURRENT to avoid regressions, now the > > source bases had divered too far enough; it's probably still possible > > to patch, but would take longer time). > > Any PR open for your issues? At first I was going to say something about such PRs would be closed as overcome by events anyways, but I like the change of your tone, so I won't. :) I've just ordered a Full HD IPS screen for my laptop so I could play modern (well, relatively modern) games, thus I expect I'd be sticking my hands into X11 stack deeper. I'll collect my notes and stories in a submittable shape and file them. > Well this telegram chat is still a community one, I don't see how it > makes a difference. Well, it'a a group of actual FreeBSD users vs. Twitter where random people who probably don't even use FreeBSD could see the poll and would gladly click on preloaded correct answer. > Also I can't see the poll result. Hmm, indeed, it does not display results even when viewed via browser, that is, unlogged. OTOH you should really try Telegram, there's nothing better right now on the market. ./danfe From nobody Tue Dec 14 11:12:00 2021 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 8941B18E0B27; Tue, 14 Dec 2021 11:12:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCwgj6l8Wz3j7f; Tue, 14 Dec 2021 11:12:01 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639480320; 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=PhOwkOG9ALoe6JoMe5MRzJMz1R1XMYi5czKD+gKemaQ=; b=tTYonm4fnKsuWPp8kONdNQvEYvnX00lAaWGm+XlJ7cfwvwhmrM4kaLKhkQQwy+mADXyxwD 4lIFIlFyC+oKZZng7izN8uADGx+Y6E+3R4zQJE30xQhF9o+moILAf6JJ0mGNmqLtSZ2ySZ gYqZLK48qzaanvN5sgGYOs3UyRz52fY= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id e82d561e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 14 Dec 2021 11:12:00 +0000 (UTC) Date: Tue, 14 Dec 2021 12:12:00 +0100 From: Emmanuel Vadot To: Alexey Dokuchaev Cc: John Baldwin , Gleb Smirnoff , "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-Id: <20211214121200.b824c6aebbaaa287a21db89c@bidouilliste.com> In-Reply-To: References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <20211213183222.f945b2e730f7c22dbe74681c@bidouilliste.com> <20211214091427.c531cf51b0284d8a1165b9bb@bidouilliste.com> <20211214112707.9bd528d32d6b8e3f2e3c62fe@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JCwgj6l8Wz3j7f X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 14 Dec 2021 11:05:19 +0000 Alexey Dokuchaev wrote: > On Tue, Dec 14, 2021 at 11:27:07AM +0100, Emmanuel Vadot wrote: > > On Tue, 14 Dec 2021 10:14:24 +0000 Alexey Dokuchaev wrote: > > > ... > > > I know that I had problemless desktop some 10-5 years ago, okayish > > > desktop ~three years ago, tolerable experience with 4.16.x DRM bits > > > and shitty one with current 5.4.x (FWIW, 5.x had been problematic > > > for me since the beginning, but previously it was fairly easy to > > > build drm-fbsd12.0-kmod on -CURRENT to avoid regressions, now the > > > source bases had divered too far enough; it's probably still possible > > > to patch, but would take longer time). > > > > Any PR open for your issues? > > At first I was going to say something about such PRs would be closed > as overcome by events anyways, but I like the change of your tone, so > I won't. :) All those PR that I closed were old and mostly unrelevant anymore. > I've just ordered a Full HD IPS screen for my laptop so I could play > modern (well, relatively modern) games, thus I expect I'd be sticking > my hands into X11 stack deeper. I'll collect my notes and stories in > a submittable shape and file them. > > > Well this telegram chat is still a community one, I don't see how it > > makes a difference. > > Well, it'a a group of actual FreeBSD users vs. Twitter where random > people who probably don't even use FreeBSD could see the poll and would > gladly click on preloaded correct answer. Still doesn't change the fact that not a lot of people are there. And we're back to my point back then during the bikesched, we do not have a good and reliable way to do poll for FreeBSD users. > > Also I can't see the poll result. > > Hmm, indeed, it does not display results even when viewed via browser, > that is, unlogged. OTOH you should really try Telegram, there's nothing > better right now on the market. > > ./danfe > I manage to see it (and even vote :P) via my phone, I don't use (nor want to) telegram on my desktops. -- Emmanuel Vadot From nobody Tue Dec 14 17:19:52 2021 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 D8CEA18EB8A7 for ; Tue, 14 Dec 2021 17:19:53 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD4r94v7Nz3pry; Tue, 14 Dec 2021 17:19:53 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 2B7DD4AB5; Tue, 14 Dec 2021 17:19:53 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <5b07d437-a81e-9151-b7a4-82c843ef266a@FreeBSD.org> Date: Tue, 14 Dec 2021 09:19:52 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: RFC: What to do about Allocate in the NFS server for FreeBSD13? Content-Language: en-US To: Konstantin Belousov , Rick Macklem Cc: FreeBSD Current References: From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639502393; 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=EnH1JMJTUaplXBgBkbAh7Njg9AHK5Cbw0BgRk0JK9rk=; b=CIQMgz+Zps3Lia5VrWdWq8iO8rsnC2tLYF8AhFHFHV+rJD0Bit64Id/zb0E+TJmOf2Hw+J oeiL++R8q7p/ShDkHo21CH3Cs35Y1tSFckCPL+1XYFRzSevHApOhNEMtIi3rZI1UJbITVW 3kzjU5usB9Qti+NDsIa6xpLe/pkXr8gZ+igKjDEJXD/7099meus//siJ4oPeE2HAjaZV9k MD5RFq4FM+mp2OxsHzboLYlO8EtEuFVu0qET2BwJ0hBopT0+urjdiIp0k2MmvGaJiF9RS4 1oR9RJ/2mbAaEZWzK+JfvGz9eZJG41sntIstzmisSLb58TQA2jiKOXM8XaFTmw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639502393; a=rsa-sha256; cv=none; b=WZj3IxDZTkJ2oVpdvUduN+VF6ttmGlfPtx2rNltx1rdzVaTOGucp6bOLXgwJU3bunm5eVZ TUu7Xo/9muT1wtDPuKtiZMJ5sS59lCaa2ZuBid6NyXqUmh6ff/cgC9N2yzhmNj7EbE72PO hjGDNjbJYrJLUdGWxQKj41hf+SyLFUl3qQMyqdX9iHlM55IO5WNaP8oLooA60D29jIetXp 7rtRUQHn0T1ocTd8ZbPJnjBsqCl7Ltl7A+knWECdV0jXDgkpJ8Pa+dTgz+R/atkHftvBd/ r1C8wGY/KOQYhKftpykmL0W6wUL//8RLUeQ4hhspFwx+X5j1QjNbL+gp2oyHug== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/13/21 8:30 AM, Konstantin Belousov wrote: > On Mon, Dec 13, 2021 at 04:26:42PM +0000, Rick Macklem wrote: >> Hi, >> >> There are two problems with Allocate in the NFSv4.2 server in FreeBSD13: >> 1 - It uses the thread credentials instead of the ones for the RPC. >> 2 - It does not ensure that file changes are committed to stable storage. >> These problems are fixed by commit f0c9847a6c47 in main, which added >> ioflag and cred arguments to VOP_ALLOCATE(). >> >> I can think of 3 ways to fix Allocate in FreeBSD13: >> 1 - Apply a *hackish* patch like this: >> + savcred = p->td_ucred; >> + td->td_ucred = cred; >> do { >> olen = len; >> error = VOP_ALLOCATE(vp, &off, &len); >> if (error == 0 && len > 0 && olen > len) >> maybe_yield(); >> } while (error == 0 && len > 0 && olen > len); >> + p->td_ucred = savcred; >> if (error == 0 && len > 0) >> error = NFSERR_IO; >> + if (error == 0) >> + error = VOP_FSYNC(vp, MNT_WAIT, p); >> The worst part of it is temporarily setting td_ucred to cred. >> >> 2 - MFC'ng commit f0c9847a6c47. Normally changes to the >> VOP/VFS are not MFC'd. However, in this case, it might be >> ok to do so, since it is unlikely there is an out of source tree >> file system with a custom VOP_ALLOCATE() method? > I do not see much wrong with #2, this is what I would do myself. I also think this is fine. -- John Baldwin From nobody Tue Dec 14 17:27:01 2021 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 DFA9118EE18E; Tue, 14 Dec 2021 17:27:03 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD50R5Pmjz3rsC; Tue, 14 Dec 2021 17:27:03 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 09D07499B; Tue, 14 Dec 2021 17:27:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 14 Dec 2021 09:27:01 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Content-Language: en-US To: Alexey Dokuchaev , Emmanuel Vadot Cc: Gleb Smirnoff , "freebsd-current@freebsd.org" , x11@freebsd.org References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <20211213183222.f945b2e730f7c22dbe74681c@bidouilliste.com> <20211214091427.c531cf51b0284d8a1165b9bb@bidouilliste.com> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639502823; 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=Wa7BL5h5lY9r6VZ6qe0hRxPt8usUQvW5HgxQ2QMkEFM=; b=bcBqYZetbdLiFunkSJ4KVz8mUpzSod2QWcZSJ3ZpYk/4TQ+uZ0f1ny7uDbfRo32qffLR8Q T5kzLWifwj9BxFAEUco5Ar91qewt7t9ebQRThi4Paucoj5b7ts25YKiEmRuxPnquD1fQ9B POQrQH4xangO0+Ow+VbJ/1skivBoo+rnDWpuX95QpGEdVu1yhloP5rCfxPXbqiRtQTW5KS LbekqERYqLZ/D1WDhG7jb4uKiEogmSLloSn4sKmqgzJYbBkfy2aG5KRtkd5aSKePpUqjM0 j61OLMEdJCX+RxOWpaq+/PNrYSIA2qPHLN+S7GjJ8TKX3kVrA1M2IigVVFwRzw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639502823; a=rsa-sha256; cv=none; b=R19Gsyc83Zc7pYTZh/fL2KkxeEwrMrMVI98biCrjTBDXGmHUspzxbIGbbUaCFRHjlhK3cB nCr19+qoXAwXM1tNTrifqw4vohmASkSmLXg8f/2+H4dp/b8XN/cJ6tr5lw/OymfZCUsZ25 JXguqUMD1JYiZHeqLkoLp8B6BQtaYW4mADFGZxTHX44AJVAFFYgf1GTNhWB0FKsU0jPf8A Soxdh8r8d+cd/hM9PbWToUAA7DAFvWlk+KygdKa33Hm3JlmVNJk2t/GRp1wABtL7ksBLVm dOeSBKxyErPlVRzJkkGJ0zgjV74J6V2ndGMMP4x7axCRU6rUzWYVj5dcT6dr0Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/14/21 2:14 AM, Alexey Dokuchaev wrote: > How do you mean? Most FreeBSD people, not some random Twitter crowd, want > the bell to be on by default, but it's still off. I don't know that that's true, and I myself am not sure that I want it back on by default. Previously my laptop had a rather annoying beep whose volume I couldn't control that I actually prefer to have off normally. On further reflection, the beep I was looking for for bad input may actually be an xscreensaver thing for an invalid character to unlock the screen vs a sysbeep anyway. -- John Baldwin From nobody Tue Dec 14 17:28:07 2021 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 DC9AF18EE7AE; Tue, 14 Dec 2021 17:28:08 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD51h4JB4z3shh; Tue, 14 Dec 2021 17:28:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id F3E0F4BCE; Tue, 14 Dec 2021 17:28:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 14 Dec 2021 09:28:07 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Content-Language: en-US To: Gleb Smirnoff Cc: "freebsd-current@freebsd.org" , x11@freebsd.org References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <836761df-6eea-462b-9ae7-5d0d00aad38f@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639502888; 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=g03RXAbnYo7ibXJRgKBCYLeY9KoObszivTRCMskX2d8=; b=BTca/dTfywaK/Jbr/Pa/vL9JLefKPs7Yj31MsjVyYQkMd9/6xl25BUWqaHbzN2sdA2f/j0 Zp2ZRnfB1rNrVZK9kiArYy7BiC6LhqnJFz2b8TVNXYFXvJNTlJ7ENbi7Z0IgFBl0xrO8+I Hu/TUfUCrzk9ZopatmzEgq+q9bprCR4X5L/M8MlypwxsYytBhOWERLaclpqMSG24dgVHKA slwxqYG9Z2GzBRmGZtXkdZOv9KB32onpBYbCYiek9Q3+pMlUDZhki9v2PPUvtwExcHcz/w tkzHf2JwcnJLC6woSNnochh00Z1jWdiroWg3Wf5YeDAY9ir+HbspbwWRllpkGQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639502888; a=rsa-sha256; cv=none; b=UN8mh6l1f4lAMfbF3vhozWJfmzKb8+9aRk5CIYq+jPo2rxsey+egKfzRqOOXSpbGNanFmU hWEUXuwMa9tQRgi0O3vGPQy+YM+5y5hNYTqz+6UW24XjfibfWn5ROzRzNz4GYXpcSGTZEp CY1vfDNvZmDbN+o3tjDgSMRhfVzw422qLSpJKFIi2ZkmgnVhT4K1T7Fnm9NC3KLtC2V2xr JrzhXMfVhfK9axI3GHGHqQX5GsbpEWl8jaKRQ5SP70kW/1rp7yIxUT2CgbfvPQw+eUy+mt qTcX1HucwInaF+EtbZLt/XtKctGjJM8eG2ztB1F3SBhgf5tfM6MwXgtai+cD9w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/13/21 12:25 PM, Gleb Smirnoff wrote: > On Mon, Dec 13, 2021 at 11:56:35AM -0800, John Baldwin wrote: > J> > J> So there are two things here. The root issue is that the devel/apr1 port > J> > J> runs a configure test for TCP_NDELAY being inherited by accepted sockets. > J> > J> This test panics because prison_check_ip4() tries to lock a prison mutex > J> > J> to walk the IPs assigned to a jail, but the caller (in_pcblookup_hash()) has > J> > J> done an smr_enter() which is a critical_enter(): > J> > > J> > The first one is known, and I got a patch to fix it: > J> > > J> > https://reviews.freebsd.org/D33340 > J> > > J> > However, a pre-requisite to this simple patch is more complex: > J> > > J> > https://reviews.freebsd.org/D33339 > J> > > J> > There is some discussion on how to improve that, and I decided to do that > J> > rather than stick to original version. So I takes a few extra days. > J> > > J> > We could push D33340 into main, if the negative effects (raciness of > J> > the prison check) is considered lesser evil then potentially contested > J> > mtx_lock in smr section. > J> > J> I think raciness is probably better than always panicking as it does today. > > AFAIK, today it will always panic only with WITNESS. Without WITNESS it would > pass through mtx_lock as long as the mutex is not locked. Yes, but the default kernel on head is GENERIC which has witness enabled, hence the out of the box kernel panics reliably. :) > So, do you suggest to push D33340 before finalizing D33339? Yes, I think so. -- John Baldwin From nobody Tue Dec 14 17:36:07 2021 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 4511918F0C7E; Tue, 14 Dec 2021 17:36:07 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD5Bv1VWNz3w19; Tue, 14 Dec 2021 17:36:07 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639503367; 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=TM02o+P9HHmOAX+8HA13HeCcn4z0yZNPcdCVjrr1dNI=; b=oFOWpPhnBm/qjFcpq2hjW64fTgZFsFc5UKxY8kCho9ZvEbQBnBirZq71qdQ1oywYUkpZB4 NzuapMLLhaUoUuYVTjJp0LVHmCxpu3nWDsWoUtP+ycrb9BHHekDFWqxD1J6mQR6a93ZvAL rV2o1ag5xEOhEu2TSch2nbLFp3+/1p1aHjg+tkAFGfNXd19vA6ZULbR9TA3Szl0+Cth3wV 5DIirDRvED2KONCKeuFy8aMVh1GTtlZ90CwWWeqP6PogbMrxjetptIwTFyl7hul9PMW96I tNrmZz33C19ixYgEt8d1w+rAZq1BJ/dQ5OTsMToy6Q4OytCHSHR7u6fMiBSzbA== Received: by freefall.freebsd.org (Postfix, from userid 1033) id 1C3422D5; Tue, 14 Dec 2021 17:36:07 +0000 (UTC) Date: Tue, 14 Dec 2021 17:36:07 +0000 From: Alexey Dokuchaev To: John Baldwin Cc: Emmanuel Vadot , Gleb Smirnoff , "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-ID: References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <20211213183222.f945b2e730f7c22dbe74681c@bidouilliste.com> <20211214091427.c531cf51b0284d8a1165b9bb@bidouilliste.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: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639503367; 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=TM02o+P9HHmOAX+8HA13HeCcn4z0yZNPcdCVjrr1dNI=; b=dNZZZVerQuXewzdYCr9UFaaFWQdx4XVNrnGpgAC0Z1WHXzPhKeBPYDUPZzcA/zfqw2x4cT 0R1QnTv2z5wJH16ptuI3AIpb1BEnaXoAeeeyUaVrWqPCI8zsOOZ/mbCSSCjYR0qkCRZMZo 46lJtkY9vihdX/WyPltohOU+hpHcarR4HWJmP44RRCONZVLsd7si81hMIwcnEa9gysb7zk FVWo+Qre+9nvuFqNiNav4USenXEIsVvoSsMWLMWXqz9qRgvXAp5+BPCTu5H1ck1yUEUsRZ +MDtYyFK1aZGBb5QjtNpqL9YeV5jPT4ArGgjA66PZyr/m5OC8i+yH11vq3ie/g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639503367; a=rsa-sha256; cv=none; b=HJyU9ox6Uh/stef0iaAORkuyuEptTjWMcZ+HVAbmsloBxhJDGQvJ9qdYTJAdIii35SCgb6 pNRJJ/o7HP9sP6kgOywn1M5MWkh5630Yx+XoaCrASg8BdQpVq/oi38IpfRxjUq93iixAO2 0ELc7rslAM5eN1QEEYkfqwAZwjLte/Ogzjd9OBBQAmFuJBZVlvj1HXqn7IHmtQ9OThLP23 r/P5OuYyk8m0ylaICbBJ49URAE3nI4Ct/2CCIR2vNxVH5iTwI470VLqsXT1wWgG1kM94tk egZjuhSTW+J7eH7SOTQZbN6jyr/pUYPsF+GSsXkdjBG0MP/bveXswQ2meDKTPg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 09:27:01AM -0800, John Baldwin wrote: > On 12/14/21 2:14 AM, Alexey Dokuchaev wrote: > > How do you mean? Most FreeBSD people, not some random Twitter crowd, > > want the bell to be on by default, but it's still off. > > I don't know that that's true, and I myself am not sure that I want it > back on by default. Previously my laptop had a rather annoying beep > whose volume I couldn't control that I actually prefer to have off > normally. Is it still annoying after Warner had fixed the frequency? In that unfortunate case, you should probably disable it just for yourself. Disabling it for everyone by default mutes an important communication channel which is useful for low-level debugging and troubleshooting. It is often the only way to understand if machine is working or not. ./danfe From nobody Tue Dec 14 17:40:42 2021 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 632AB18F26E5; Tue, 14 Dec 2021 17:40:49 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD5JK0qxTz4SN0; Tue, 14 Dec 2021 17:40:49 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BEHegKN005158 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Dec 2021 09:40:42 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BEHegOp005157; Tue, 14 Dec 2021 09:40:42 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Tue, 14 Dec 2021 09:40:42 -0800 From: Gleb Smirnoff To: John Baldwin Cc: "freebsd-current@freebsd.org" , x11@freebsd.org Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Message-ID: References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <836761df-6eea-462b-9ae7-5d0d00aad38f@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-Rspamd-Queue-Id: 4JD5JK0qxTz4SN0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 09:28:07AM -0800, John Baldwin wrote: J> > AFAIK, today it will always panic only with WITNESS. Without WITNESS it would J> > pass through mtx_lock as long as the mutex is not locked. J> J> Yes, but the default kernel on head is GENERIC which has witness enabled, hence J> the out of the box kernel panics reliably. :) J> J> > So, do you suggest to push D33340 before finalizing D33339? J> J> Yes, I think so. Pushed. And I plan to post new version of D33339 today. -- Gleb Smirnoff From nobody Tue Dec 14 18:21:40 2021 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 9735018D3FB8; Tue, 14 Dec 2021 18:21:42 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD6CV3Ldhz4bhX; Tue, 14 Dec 2021 18:21:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id B5EF75257; Tue, 14 Dec 2021 18:21:41 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 14 Dec 2021 10:21:40 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore Content-Language: en-US To: Gleb Smirnoff Cc: "freebsd-current@freebsd.org" , x11@freebsd.org References: <1db0942e-0e66-4337-ce2f-4e1005107435@FreeBSD.org> <836761df-6eea-462b-9ae7-5d0d00aad38f@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639506102; 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=/6P48lUWLAWwkzDQH0DLIRrJBCF0lhFG1Q1hZdpA6tk=; b=VvQDmsRJIc+QfblDuEONyBA8cXBP1pRPjpyM9nEv8Cy5yMhU1RKHifmqmwdkdOVoqK3G3x mjihKyfqVW1p9T6SZmE0Xv0u1+m5x4v4RxnFoxIYUESqWd2xOOqc0ZpaLG2KpGFM0X02BP FlsPLQRRDRg0d+8UXIMgc8/muYjdDX7r6e3D7od+ERH4G+epNx34sfP+CB5ZGXnFjvgfw6 BijEOBuVayuB9UZXt1ElXFXGORcUZK2cSDBiE8N4+CyF0/8ljrN2FaZazoTjps1WQqCppz f+6JKCd41dgsBR6694Bs6/X7dx/hlElKPVd/sbFbByLDlkX0fVF2cuCspiUGYQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639506102; a=rsa-sha256; cv=none; b=ZfGVmmJ9IvoAMVfzbeVnJFxmdNu0B8mmLJzDvCyWDcvQrLdf/cDyFWcS78hYvXrNb7Nq5M AdCMsBVOT90ex/SD0GroNYdd1SJEJR3iY84MGr+dXkIZe9w1kV83ja8NEIKA5CSPWwr4IZ zVh2OFRtuMZrJOd8YcELRxdRtDnXSMm+0KXfv8NPKfTyjAS6srKPxaFVS4SwYUmYy3Sc0d qLEX5oCiN/bCuqUQV5Q4y10a3rkhelOMLlvWs5pBElaBzTCqqntDP0yf++kEXmo2ShglLx q+xQdeHeoGm2seDjN0x7DKq36kV5qAspmpMSEU3RYnL7Vu6GjdRnyBTTE9fk8w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/14/21 9:40 AM, Gleb Smirnoff wrote: > On Tue, Dec 14, 2021 at 09:28:07AM -0800, John Baldwin wrote: > J> > AFAIK, today it will always panic only with WITNESS. Without WITNESS it would > J> > pass through mtx_lock as long as the mutex is not locked. > J> > J> Yes, but the default kernel on head is GENERIC which has witness enabled, hence > J> the out of the box kernel panics reliably. :) > J> > J> > So, do you suggest to push D33340 before finalizing D33339? > J> > J> Yes, I think so. > > Pushed. And I plan to post new version of D33339 today. Thanks! -- John Baldwin From nobody Tue Dec 14 18:26:13 2021 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 CB6C318D5C45; Tue, 14 Dec 2021 18:26:16 +0000 (UTC) (envelope-from markm@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD6Jm3vvVz4dMt; Tue, 14 Dec 2021 18:26:16 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:7dfe:d4bd:52c0:bafb]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id E05DF528E; Tue, 14 Dec 2021 18:26:15 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_8B49C783-B298-40B7-95EB-EFD0CBF8D0D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 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 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211213022223.GA41440@troutmask.apl.washington.edu> Date: Tue, 14 Dec 2021 18:26:13 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Message-Id: <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639506376; 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=ZJpJSHPkrIi/bzjmiXVfk0CQDpi0DTk3/PtMptbcZxk=; b=OsR/C39SEKiTPaqLy+UnSGs1P/rKfQZq6qHABJW0n74orTV/YZpJySrH4Tz4LZQ7//rXYf IxAIybsIQbAAV6H/Y1GjaSiL2ObqwSR8bfAk+AWbm3rJuLv6RJCawDF5++uJnlb8Q4dCva o6BtJz6wHtxkaydnUjT/xQW1aTdjGpCT+DHjugZccSDCb2uByJ9ZbQnOEeUp2VwujhXaQl 7mm/VKbJVRdUp08MEKsck24OWqd11oNVY5e1PkepFxbFK3jOkFD4swkZb8DQny8Z7hZPS9 JU2zyTAvNPxkUug+XUWoEmAZaXP4p/jXoYl5vaIwJmlhD5uWiZFltAse6+TkTQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639506376; a=rsa-sha256; cv=none; b=Hd1GOj+qzjbOnRt1zHPxR6pwKVt158ZZBUJQ3F09SZY1w7ioowHATPteBQPjVHooAAICXM tbsSJKeh44BVr45JmuRwdo5P78VLCgHjYHnQN7q+r9dwc2mKy71IvvOFYwK80JYL+Z+j9w HcJ3LgQbfw2PxXdZtCVSpm/LR1BgnZAsJAV0LrnxUqf+zSEadldH6UYKPJdJKXRzq8qPk/ c9ap0gLriD4t8Wk6Q//vFjnXMfQiEdJZiDO+MYp5mxQLK2YKgrPHNitF9arAE/w6ubnheM oKpHl2qR+JjF4DWHpFiwnVFi/BW+U4Ia5pyie4zqQCeMGYP1XJ6Z5GF2t/zMOw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_8B49C783-B298-40B7-95EB-EFD0CBF8D0D3 Content-Type: multipart/alternative; boundary="Apple-Mail=_7DF879A0-F428-4C26-BF70-B4BA90ABBD6E" --Apple-Mail=_7DF879A0-F428-4C26-BF70-B4BA90ABBD6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13 Dec 2021, at 02:22, Steve Kargl = wrote: >=20 > On Sat, Dec 04, 2021 at 11:48:13PM +0000, Mark Murray wrote: >>=20 >>=20 >>> On 4 Dec 2021, at 18:53, Steve Kargl = wrote: >>>=20 >>>=20 >>> So, is anyone interested in seeing a massive patch? >>=20 >> Me, please! >>=20 >=20 > So, I have the ld80 case working. I'll open a PR if > on does not exist. The pr will contain This is now visible for review at https://reviews.freebsd.org/D33444 Thanks! M -- Mark R V Murray --Apple-Mail=_7DF879A0-F428-4C26-BF70-B4BA90ABBD6E-- --Apple-Mail=_8B49C783-B298-40B7-95EB-EFD0CBF8D0D3 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 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmG44cUACgkQQlsJDh9C UqD1sQf9FgYaKDAcglmiZRzEfpKQ+nWzxG9SChr7V8o2lykhdu7j19XyTR6B8vt/ wFcZZt2AcmaryjNijeDDLlBX5NfLG0EmdkaL4k92+QqBI15MY2PdIH0dw5zVJ/NG 8k42f4P199vo33tquvq9wy4QyPnxwN0xjGvzgLZJZC8Zf9F/92rEaKjepvl2S0Hk DOBUHLYerxfmvUOqdSaotlPEPINdkBLw62tiAUX7UJ5j9l+HVFUWTLKl4EPzaj7b HyKCnflw1aanjnyeHBVgw77izyPwXycn4+kXuIAsyUXnOFvt1YvWqanWmpFQiEmD wu5Z+QXuR/3seIlVhl6KolQnaiiiuQ== =XXUp -----END PGP SIGNATURE----- --Apple-Mail=_8B49C783-B298-40B7-95EB-EFD0CBF8D0D3-- From nobody Tue Dec 14 20:07:40 2021 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 A04A518EE851; Tue, 14 Dec 2021 20:07:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD8Yn342vz3DwT; Tue, 14 Dec 2021 20:07:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BEK7emU049984 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Dec 2021 12:07:40 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BEK7eCJ049983; Tue, 14 Dec 2021 12:07:40 -0800 (PST) (envelope-from sgk) Date: Tue, 14 Dec 2021 12:07:40 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211214200740.GB49922@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@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: <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> X-Rspamd-Queue-Id: 4JD8Yn342vz3DwT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 06:26:13PM +0000, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > Thanks! I looks okay to me (but, of course, I wrote the patch ;-) BTW, I'll probably take a shot at ld128 tgammal(x) this weekend as I still have my account on your aarch64 system for testing. -- Steve From nobody Tue Dec 14 20:41:32 2021 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 5F6E618D72F5; Tue, 14 Dec 2021 20:41:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD9Js6yRZz3Lhl; Tue, 14 Dec 2021 20:41:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BEKfW49050142 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Dec 2021 12:41:32 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BEKfWXm050141; Tue, 14 Dec 2021 12:41:32 -0800 (PST) (envelope-from sgk) Date: Tue, 14 Dec 2021 12:41:32 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211214204132.GA50132@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@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: <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> X-Rspamd-Queue-Id: 4JD9Js6yRZz3Lhl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 06:26:13PM +0000, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > Just looked at this again. I cannot tell from the diff whether you've 'git mv' src/imprecise.c to ld128/b_tgammal.c. This is need to still get the mapping of tgammal -> tgamma. -- Steve From nobody Tue Dec 14 21:51:06 2021 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 053DC18E9BB1; Tue, 14 Dec 2021 21:51:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDBs847rqz3s5w; Tue, 14 Dec 2021 21:51:08 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BELp6iq050409 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Dec 2021 13:51:06 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BELp69M050408; Tue, 14 Dec 2021 13:51:06 -0800 (PST) (envelope-from sgk) Date: Tue, 14 Dec 2021 13:51:06 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211214215106.GA50381@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@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: <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> X-Rspamd-Queue-Id: 4JDBs847rqz3s5w X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 06:26:13PM +0000, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > I see imp lamented that that fact that he is not sufficiently versed in the numerical methods used (neither am I!). bde use to be my go-to reviewer, but he's no longer with us. To allay fears, I've tested 5 million values distributed in the intervals of the various approximations. Here's the result Interval max ULP x at Max ULP [6,1755.1] 0.873414 at 1.480588145237629047468e+03 [1.0662,6] 0.861508 at 1.999467927053585410537e+00 [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or 1.01e-20. -- Steve From nobody Tue Dec 14 22:20:58 2021 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 1717118F1E60; Tue, 14 Dec 2021 22:21:01 +0000 (UTC) (envelope-from markm@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDCWc6T2Hz4WXb; Tue, 14 Dec 2021 22:21:00 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:7dfe:d4bd:52c0:bafb]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id 476F56561; Tue, 14 Dec 2021 22:21:00 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_05A1EFD2-5DBC-4A0E-8510-39E1615D462B"; protocol="application/pgp-signature"; micalg=pgp-sha512 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 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211214204132.GA50132@troutmask.apl.washington.edu> Date: Tue, 14 Dec 2021 22:20:58 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214204132.GA50132@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639520460; 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=FcQIZpp5Ddv5iJPgA4aqyaO6rJlojnO+LH+H3WhJzGU=; b=wShUTfPPyECILqY6oJu0gadB6ZWruTmAVrOiK09sYQTm0CnOxG9ZVU1X0YAIqlKBSNhPOI f49UTw61zp/JIX6lYpWEbuVilLqT3nWDjw7syP+lKR4SXy36jknvXzKmtLDZfZK2B+0ZZM vLIqguXJZUuzfSdCMF2NopyjtC6WJc/VzanYP1pEZfrTm14D1CiqzvcR+9ixaSEE12gJac NbqxkHMI18I0LMg5CN2A0EgDTOV7uvaItShaw9rnGI3NI9McI0Mw6pd0ApyGm7DQG0M421 Vgc2K/U98twuqAteQqpgS8jnQVG9bhW7y7i1osz5DaNF2kNsZOnIlwe1QJCSsA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639520460; a=rsa-sha256; cv=none; b=l6OfhfO1Jqdc3Nwf2cg1hOKVWlbGt9ct44x0KiV7To1MQR9l/WPaBsII2cFfNoKlKBqyHD itbSGa+B1I5WBNOKdk9pNcnSQaaYJfr9GJfiU4AWIorO5uoop2QZ63ufABnjMN3WasKe0/ KRyIlo5VrlDIWtzjXHQymIX0AZQzrvZ5tUJ2t1Y4Q5qqvDIlHNQBAbO3Ei+UPe9LsX5xL2 eZiMPRRZa1Nrk5Xuadm9qS0701VMdNnzCDG/+UnBZj2WUtN/nV3B/32SWNk8cR105dxHvV gU98OJ5k961Fz2q64a/9hhlwdDiFmZ9grSRrbFzwU/KwMq/TQrz3J6CtDO4/Ag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_05A1EFD2-5DBC-4A0E-8510-39E1615D462B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 14 Dec 2021, at 20:41, Steve Kargl = wrote: >=20 > On Tue, Dec 14, 2021 at 06:26:13PM +0000, Mark Murray wrote: >>=20 >> This is now visible for review at >> https://reviews.freebsd.org/D33444 = >>=20 >=20 > Just looked at this again. I cannot tell from the > diff whether you've 'git mv' src/imprecise.c to > ld128/b_tgammal.c. This is need to still get the > mapping of tgammal -> tgamma. Fixed, thanks! Thats what I get from checking only on an ld80 machine! M -- Mark R V Murray --Apple-Mail=_05A1EFD2-5DBC-4A0E-8510-39E1615D462B 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 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmG5GMoACgkQQlsJDh9C UqBQFQf+JYuW46dzet7+VlsSzBkBR+THl+2mHKiZ4WTFjQ73tl5aWCMX/lf6gXxS Jc8gl9SwV1UAP+PxrPkPOd2vnqx/7ZJP74/KKMedbRmGe/msyjMAXU2c1WbboM9f JI3SPiC+Gw6M9RF6+yXv2OjYxeNdFDqNKkE/4ATbPu8CsiAh4Dg0t1ZDMMGkq2/R F5n5bDOZ+3py9uygp8eKC1G/X34Vdc9Wg5wVYeR/V29tTQBKg9mNI+P7QTJxVesM TfNyIACoySxJ60WOKpri77qMkfi74eytr/d1fZA2i438gt8bWT2+KHaitDUAVD+W 647cc2JR3kmGvPwRg/SHXBU9nOdL6g== =gI/g -----END PGP SIGNATURE----- --Apple-Mail=_05A1EFD2-5DBC-4A0E-8510-39E1615D462B-- From nobody Tue Dec 14 22:21:55 2021 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 8F5F918F2678; Tue, 14 Dec 2021 22:21:56 +0000 (UTC) (envelope-from markm@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDCXh2RsYz4X90; Tue, 14 Dec 2021 22:21:56 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:7dfe:d4bd:52c0:bafb]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id 783145FD6; Tue, 14 Dec 2021 22:21:55 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_7789ED85-99E3-47A4-AD1C-A919E6E23F8D"; protocol="application/pgp-signature"; micalg=pgp-sha512 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 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211214215106.GA50381@troutmask.apl.washington.edu> Date: Tue, 14 Dec 2021 22:21:55 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639520516; 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=/Oeh+rWYxRSnAVL01tiMUmYsav5/TCgFWljJZk9MeA4=; b=M6UwZme6z2uQ38lDSnJkPkMz0w6HTEmAghtsisbWGEpse32auM/gELPQsELdrXpbo4zxJk 5ts/Yqf6ONzfDZgDxpmwZ6F4197pnn2syRajBK+eLj2SS4mVoc9NPSxLVsMVcumRaQKlmv Ni2YfoIobLS/fNNjq59FyajtU28stkHZAX8V+sWk8k1AZd/c26w7fu7gZ8CwjPKh6qYLx5 8g8ldsWxs9dMzKNSerG3lUqfDNznNtefx5jdL1eDWmB7oRCRaJFihX3XQmQW4vLafVtTqk y5GlYxvYNL3ZqzZ0wfjfGoK1RUvMVV7sRYOGjfnonz+tQNyVGeGk+t7O5W/CIQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639520516; a=rsa-sha256; cv=none; b=AAbbb0CgPwB+nsmi+OqcMKamDCf+IX5O9X/7555ZUg+T0SCQVzs64EfkU0c9JwIqPBIEJC bZq3L1ijrzUJS4r+X4OPcLsTMVIXSM6VlszCZaJss/bTapMiQ9SdaqYELf6OX4WYrIooOU B9fPM+GyB1onpmbzgh8LWiTmtL5r60R0bBK7Q3MBoFYL2kTlUZZAstQqplja5n9lqXFoL5 NGyWASLBOXBxLE8k+hOAOY8RKf7s1OSFELNq7mSZVjjkxCUQjlRg8ALEWlYAwtDH3NWanv bnmPsjMn/k1GYd50LRLmghxxYi0ycynkQrhJ7r61Cy3gMEKf5ifhmbxlXWl/TA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_7789ED85-99E3-47A4-AD1C-A919E6E23F8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 Dec 2021, at 21:51, Steve Kargl = wrote: > Interval max ULP x at Max ULP > [6,1755.1] 0.873414 at 1.480588145237629047468e+03 > [1.0662,6] 0.861508 at 1.999467927053585410537e+00 > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 > [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 > [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 >=20 > Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or Extra diffs most welcome! M -- Mark R V Murray --Apple-Mail=_7789ED85-99E3-47A4-AD1C-A919E6E23F8D 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 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmG5GQMACgkQQlsJDh9C UqBoBAf+NsbD7j2sJiYzE0Y+SWknyDuVSKV8LoNb0TT4DzFcSNtaGbEhnMzcnOCf vd/OYnwr+EaII3Hv/W8VwGKcQK6tvUrjSPh4fxiGWJcZFv2MyETRel776NUdFUqF nEcAn/dXDIjQIlTtwALbyIMmY22ThF/IhmHNrutI9PLWfQf6HB98hZ5dOa2V7sQX OEJTSjrPA20gZM+/0hxzjbvXSWxL/jJtIRXseIb3L1WqkMFbuf3u0jLVsMvS2gER xzADf9ArAVdNF0KaideNP1ysb8KShLts6wvHGaboCbd7mQ6E/BxHfBRw8p9bOPyv 1Yoe5ez4fioJHe69Ihm8Vxgi/iEUyg== =t+Ia -----END PGP SIGNATURE----- --Apple-Mail=_7789ED85-99E3-47A4-AD1C-A919E6E23F8D-- From nobody Tue Dec 14 22:47:17 2021 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 7F9EA18D337E for ; Tue, 14 Dec 2021 22:47:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDD6F2l1wz4k43 for ; Tue, 14 Dec 2021 22:47:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2d.google.com with SMTP id e27so13496587vkd.4 for ; Tue, 14 Dec 2021 14:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5+JwcqFe5Y2gLCcWupXXwrdKoIxzVAyW60rDxPMYyzg=; b=aRs2CkykXaio/4tcRr8Apqx68tQb23navWsj3vmJ6RqlhwEKZ+9gn2LFmHiioPhre4 6OcNpbC3EGnp3r7bNqYnNy4AIT0tHl8V070FVVkZzgxH8R1XKcwfaHq80a0mEenrQIU5 NMo233nUe6X5XxuyiPjba9WK/Wk80hjkjy0y7Xu4uFRU/HuRVxI4qAkr5gNCcmkIJRgi lsT097HiGnijWbRI9l7Tby0wau/L8Er4DNTob+T7+pAthvxOQdQ2RdgCZbeOpPio96P9 dwgeNwrOXXieMSqjIIY74SRP6yLylTbdVuRH0NKpEs+qcv4TMIFaKDWr88Ag2tCDsJ7f tNLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5+JwcqFe5Y2gLCcWupXXwrdKoIxzVAyW60rDxPMYyzg=; b=miYk/MD9p/1YoHeVkMNp9yAfMJ6EvKgEZntk48d6qtvQyuBATo3WGUcNDyQdodICVa XeBgyMAabeuqfWRHyT0VpTzbxCwA2CKzVEbOdv5V/eZsUvBQKVyoNOlw4+f6To50bszT gkFoKtjtDXl00dJG0RwUpUNBtnFnrsW/4bdYteDpOQpb7jgq8d/KEW6pZAFzEh0J9gz/ uyNPTkgSQ1wr7yCxFXUnKFPyPLL7uhCPRXxngdLy0SxSbh7ms32RJndq2KYtTGQe4Chf vu+iLNyEl9b06KuSTBD5Ou6ZahllZsBTqTRvPD4vBimLHsBvaqHmZsLopGep38b/ou9T i8sg== X-Gm-Message-State: AOAM530oSAMaWpdp78tz3U7WUEY6xrFgJE4ki+j3JpGII6LKHIFyO72h 2RJDht5+wYvyOA2+TfDUoMTuWm9UBl6FTgBtIkVIS2+Only4bg== X-Google-Smtp-Source: ABdhPJyz/m+YQMvxQO1J+P6J9FXlcxFdaeFCsri5qp76Hj01rOovls6TkWruKz/Kw32B/rdOwG2DuRs1PHGvOaA7r4M= X-Received: by 2002:a1f:c193:: with SMTP id r141mr2052619vkf.27.1639522047610; Tue, 14 Dec 2021 14:47:27 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> In-Reply-To: From: Warner Losh Date: Tue, 14 Dec 2021 15:47:17 -0700 Message-ID: Subject: Re: What to do about tgammal? To: Mark Murray Cc: Steve Kargl , FreeBSD Hackers , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000003fe9cd05d322f945" X-Rspamd-Queue-Id: 4JDD6F2l1wz4k43 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000003fe9cd05d322f945 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 14, 2021 at 3:23 PM Mark Murray wrote: > On 14 Dec 2021, at 21:51, Steve Kargl > wrote: > > Interval max ULP x at Max ULP > > [6,1755.1] 0.873414 at 1.480588145237629047468e+03 > > [1.0662,6] 0.861508 at 1.999467927053585410537e+00 > > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 > > [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 > > [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 > > > > Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or > > Extra diffs most welcome! > Those results have allayed my fears. Is 1e-17 sufficient to commit these changes, or do we need to work to get it down to 1e-19 for it to be acceptable? Warner --0000000000003fe9cd05d322f945-- From nobody Tue Dec 14 23:14:22 2021 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 4FE5718D9BC6; Tue, 14 Dec 2021 23:14:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDDjF0n6Wz4p6B; Tue, 14 Dec 2021 23:14:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BENEMOB051104 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Dec 2021 15:14:23 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BENEMow051103; Tue, 14 Dec 2021 15:14:22 -0800 (PST) (envelope-from sgk) Date: Tue, 14 Dec 2021 15:14:22 -0800 From: Steve Kargl To: Warner Losh Cc: Mark Murray , FreeBSD Hackers , FreeBSD Current Subject: Re: What to do about tgammal? Message-ID: <20211214231422.GA51064@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JDDjF0n6Wz4p6B X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 03:47:17PM -0700, Warner Losh wrote: > On Tue, Dec 14, 2021 at 3:23 PM Mark Murray wrote: > > > On 14 Dec 2021, at 21:51, Steve Kargl > > wrote: > > > Interval max ULP x at Max ULP > > > [6,1755.1] 0.873414 at 1.480588145237629047468e+03 > > > [1.0662,6] 0.861508 at 1.999467927053585410537e+00 > > > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 > > > [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 > > > [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 > > > > > > Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or > > > > Extra diffs most welcome! > > > > Those results have allayed my fears. Is 1e-17 sufficient to commit these > changes, or do > we need to work to get it down to 1e-19 for it to be acceptable? > Well, egg-on-the-face. I updated the sloppy limit to isolate x = 0 from 0x1p-56 to use 0x1p-116 and forgot to update my test scripts. The code in tgammal in the interval [-iota:iota] is if (x > iota) RETURNI(smaller_gam(x)); if (x > -iota) { if (x != 0) u.a = 1 - tiny; /* raise inexact */ RETURNI(1 / x); } so tgammal(x) -> 1/x as x -> 0. -- Steve From nobody Wed Dec 15 00:36:10 2021 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 8FABF18ED94E for ; Wed, 15 Dec 2021 00:36:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDGWm02Slz3LR3 for ; Wed, 15 Dec 2021 00:36:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639528572; bh=QCN3t79U9+rPywGIpE2TUfsI49ZUuh8Aw6oMTeWI9LI=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=IlEi2D8/PBe9BkE4DcoEm1P7BQJ31oGNjwgf65XXKir4zqy2TfF3f/tMjsqjO6HOGo5nt7Ra1JSEpM21rlaxKJLaNJJzQe3XeCn0h3Usn2mycLMsQoNzQ4DaqBz1TqvQUpedhXZOd7bM2HAljE3Ucs/AuVaknDRvlnPfyYV86N3Jsu3HWWdVL94Uj9Vzap6I7M1SV+JwPmog5TZmPy60V1A08P78wgsRThOJQUOBRLy8YEJkEJ3XhWdkouNI+2LxIpy8AdUnkz6xFcksmF9zf6KtcBGKZkTTK4cJJzOYzVEM8FOSUEGPWFhDFKfickXjG6Fo6Stx/kzzZb/KBKhw0w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639528572; bh=46BrlhHNBfcpglm0YQcM32OmgJoQrB5viw5z4JRtRhK=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=YpJHOXbVMVDtO7oY97A13Eb44hCM4EUASXhmftvNyM13QdY0zfUNLrvK9PexT5O1IlCPmG+fYm1mET0UVEycoZjQrVecvaYkpqoF8aoi5fN9R08PSLYk3ob5UFvOW38mgB9gQNqPKmidLBAUL/0zXDbq3beri5p9NnYlJAiV+XrOoyIFUHMy/4JtpIr2Tts9ur8If4R+WDpAPis9EU7cnQTFop/c8vxNtfkAaOA8cjgzO8i2Aq+K8IFotYWbEt6lyojm9NFC8ynk1R284lSNH9ipO9RZ25swrNuEm5uiyQg0zGu/3Nv7fAGS2+8McickA3Tz9liobiDN812IYIOBDQ== X-YMail-OSG: qqxohhAVM1lJ3ooExakUH6yywfTghn17BQJDxp7fLstigGKB7YlQ8uS3eIMFJqr shiltKr80k.XRdXe1c7ujOCTaWLxFg6hJer3FxdnanVQ9XhYMFlFxfGo.dGeKSJZ73jz_5Qx6Uqz M4bWUjvcdR34gQd2ikaw8vNoy3l7tSxOdDv4T7jnvKSYHBUTrjAWza8xAxwFWmg0J.3EX1Kl0pDB gfFNt8zn4NnkwI9KydJox_cVqZ71jsVdk5o.PLQGvsIp0SQqZHAH4NYpirA0AoFSIxymNNWyirMF w9Wop3_2TtPt2V8bTVTzd2Wgk8vmzr86zRifhMMvbMunoKG4_GI8kd__aHgOPT8Jy8UpK_cCPtJ5 RFrsJ5cL1F3JHN1hk5G0k0cX.5qlSWvib0mXeR4yl34b1hb7TdKnc_rFoX4tN0k1ZJhMMByxtxvU OR9rk_0EcOLsHG5NYSDhIAeJrJK24rhuo19.0npG95fAeno7c5h0QeQ5o0mtPpvwi.JR3lzq3mLG rTzLTULYvvc6pFRkeQUMRb729SDF2v0VsNu1ZCCBKjWNbrAhySlq7GI87At9_7Fhqpc8eu3WdKm7 A3zl16xjzc5wB6TI7Cyk4B1qZ9tOtaqsH6XBoMaHV0KQGRdfsTI5UD4OlRQ3ZIeKyRgWVD3KoZP5 1HCF_AZ2quGWfBcCrAyxS7E0LuDT.isa62La_h1mEPEeLhFtYY77rdLm1lcfkEVp0gmnxUgGoTCX gZQQcfRnRb7bO9aavSinU3eYYIo5RjVejKKxABdq_3FzILx8IY2BZYcQNYmCC6BAo5uCkZaBuBhZ yfCsBnsnnvF1UGQNyWXjSwKTNNZL55XbI4wKJ.40FE7opX6JE_EF4CzsmAkVA.aoaC6Fd2yb2thJ zj4fhqUFNm.B0pWS2SItxwWybIOIv3WT23gGDzdvUq8gT.guTJuzJSRKtFHHW9KIEaarecqYMqfN 4F6koXWOs7sgFv.yPtXO_MBn1MfIVvHLqL6yRqwE3thzEMJtQbZ_bBtz1HcoJJJHtvJtaJrrdce1 w9QAMsiNvomCqkkRdrNiQG1GzRgTRYvzwcfTWTNOiIeqw8QC02.hN8mXlRrAx.neR660cl7.Ju4U WqfNPW470UMl196GPViAgKm46IN5jTkKew5_pqEru.TeudJVw6lPjKQVTYAX4iY00pWZAt1LcAQf vvA1737ksKkpRz4w8uiM_H.xMOKNRTYP9b2Y590CPQvTy6atWWdhTncMgg96P6RJd_1PZaSsqK_u d7eVH7tBr_7M.OLw63PxyJl_N9aSQqCUDMsz.5hL0uXOeZ2c1NrUxIqn1AlcadlWGLWOAca9WjWI LT_aLankiBX0n278e4IFIpLCYxJpkRzuuFWO2mmF0pwRR4GJ_vKPGJJ7KW1KzRCEfWVpmQ17WJSm Ji5zEyjWZ2rDCbrcRXliyt8r4TNhVogEe2RDT7eA3sF.gnK69NmRGKof0w2iBJc6j7sn.5xj.mWe 91hthAkDB0oYrMnRybYg6.DZg.NHsAS3qrz2fNuBaqWK5PEfN2B5r4_PKm4YngqFT3Q06u37OHRp _mKOZ7wiFp3ihVQJy13CtALQ9z9svUClRbiEm7EkDF2XenR_wFovP5kL4Zc.boVySxagiHRNMVYz xCOKAIXbEpIHW0OdZEPVvvLLvZnaScA6pbegKgaGpW_Tb8anNbxcviEgrxkCwNxr7f4taMxMxGu0 pzxorSkyKuMo_W3GtjJ519PqwipH5pjwrrnKllBNcdWnIGMblmE.iJlrkVjLGD9g6eAjGrZhVnHL F5yHzx5k5gXijbSbXYW7UYRtjiTiOMxbzuj1bdcRD72ic8aLdSLBai9Y62h6GOEIzZI3RE_DNz7T t2JHUAdxHXMrmQrGHHNYYB_OsYyBiODVcEq.3_8ZrTMmzxeGg43iLV_dfb3k6GfwSpmxyqaBizrz ZQhGiHmpZJjo8g5MSwSq_xsdP6t58k72PLxPV5Kaj51RId9o4AHjL9MsnAkiIavAx6dwi5k191lT gvZpFBgL.C0Fb6VCjNR4Lx492Hqoyzieif0uk7dlLxNuX8bLFSFfVBBwPPOXZVg3e4Aen70goUHk x77U4h2V9qn6QxZuOLQPgHmbAtpS3e3wdZWpzwl79GyGX30G5ya0elEtp9ow2oDuGO0AOIt9kPD. WbaBncXGteHsZZC7nZU6KHh.IE.lTgYXITYyakgGk5c0LDZzCfRsMjv2FJm_eoCyC2zGEk36bug_ kBdY9MEHpYog2Inr_cG7wAXVrCuI8hYG2dyilwQn5Xgb9_DTpv56lI9Z4u5dQXGwFIZUjHqhBd.h nuE3KwJzJL.V9EqKw X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 15 Dec 2021 00:36:12 +0000 Received: by kubenode539.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 03fd060a314e9d60a37daa747c21d2d4; Wed, 15 Dec 2021 00:36:11 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status Message-Id: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> Date: Tue, 14 Dec 2021 16:36:10 -0800 To: freebsd-current , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4.ref@yahoo.com> X-Rspamd-Queue-Id: 4JDGWm02Slz3LR3 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="IlEi2D8/"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.58 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.13)[-0.129]; NEURAL_SPAM_SHORT(0.05)[0.051]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N I just noticed that main reports that my pools were created implicitly matching openzfs-2.1-freebsd (and without an explicit compatibility assignment) but, under main, zpool import and zpool status for those pools report a new, disabled feature. Turns out the issue matches what the diff below shows as present for openzfs-2.1-linux but not for openzfs-2.1-freebsd : # diff -u /usr/share/zfs/compatibility.d/openzfs-2.1-[fl]* --- /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd 2021-12-07 = 21:23:21.573542000 -0800 +++ /usr/share/zfs/compatibility.d/openzfs-2.1-linux 2021-12-07 = 21:23:21.581738000 -0800 @@ -1,4 +1,4 @@ -# Features supported by OpenZFS 2.1 on FreeBSD +# Features supported by OpenZFS 2.1 on Linux allocation_classes async_destroy bookmark_v2 @@ -7,6 +7,7 @@ device_rebuild device_removal draid +edonr embedded_data empty_bpobj enabled_txg So I've taken to updating my existing zpool's via: zpool set compatibility=3Dopenzfs-2.1-freebsd NAME because I use them under releng/13 and stable/13 and main and do not want edonr accidentally enabled. It is not obvious to me if edonr being present for main is deliberate or not. For reference: # grep edonr /usr/share/zfs/compatibility.d/* /usr/share/zfs/compatibility.d/openzfs-2.0-linux:edonr /usr/share/zfs/compatibility.d/openzfs-2.1-linux:edonr /usr/share/zfs/compatibility.d/openzfsonosx-1.7.0:edonr /usr/share/zfs/compatibility.d/openzfsonosx-1.8.1:edonr /usr/share/zfs/compatibility.d/openzfsonosx-1.9.3:edonr /usr/share/zfs/compatibility.d/openzfsonosx-1.9.4:edonr /usr/share/zfs/compatibility.d/ubuntu-18.04:edonr /usr/share/zfs/compatibility.d/ubuntu-20.04:edonr /usr/share/zfs/compatibility.d/zol-0.7:edonr /usr/share/zfs/compatibility.d/zol-0.8:edonr I happened to do this activity in a aarch64 context, in case that matters. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Dec 15 00:54:50 2021 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 C29B718D2740; Wed, 15 Dec 2021 00:54:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDGx84m7Tz3Q9P; Wed, 15 Dec 2021 00:54:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qk1-x72e.google.com with SMTP id l25so9222161qkl.5; Tue, 14 Dec 2021 16:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=iW7Epxo8UhzIyLIivDj1YSoTn8CyjRAHgZfoqJACJFo=; b=ctn3fWx8uGxfkmeU+tPz24TrEJDO/QQwCGQPmm5hxVSR2P/3uaQ5Oz7PUlfIfc41zd YwthiJAl9gq25ShnaBlurO2b9nZ79KomXp8bUdupSh/R9zX3cg9JmPmW8dTWTcq9V27i bl7ApcAhxsUuFUPPn1SdD3DooF9/0AIAu5ecNzJUC6qFE5H/nfoYonMrObJK1bw9qH06 k293RQR83h+2TnfdsFdBda8mR1kj3WUfZDrI2mcyRJHHiaqlDLqXKN9uUrawlQnzaNHV 59B0XKVgv1WyqktP2NiEqb1qSsM2GlXWPaHFMkZHtqbHvrOAwxmWqWdqAxnrfxdFH6NI ySUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iW7Epxo8UhzIyLIivDj1YSoTn8CyjRAHgZfoqJACJFo=; b=EWCRyti+zo8XGlub/7b4AQ14Wf+90s3nh+r4+2cfOK7cVFb/gB9iyswipW079RUIiy sQhz5DHvywOySbFn83+b5LbH0ZKJ7X0j/Po1DVKRKDDnDi6UhzCDRb6RptuoTAoRdEd1 pEhrTYgLVO5+myyMCzTnIa3v/TIwgX11LoJ88bnXwWWHeEAqE08QXl7huT/PSsOC58sv rtJkv0tBgZlfJPyZN04CdUBXqAgBkUtsEZI7V05wrmO5dJbsVDwUWuxmzbp2GsN+6Dd4 saHySssvCsCR9Tyn1e7wDye/dzX4TYAXZcQUV9XjDb3B6QPT405qwe+D08XEs/UbgXI2 qYpw== X-Gm-Message-State: AOAM532h39TfbPMvBLpPQA/UXfz1PomFXy2XPABpxGa5+Nvo3gyaiZN8 E5vM6dDV19kIN3hNvFqYIarBSqHped8= X-Google-Smtp-Source: ABdhPJw1Ga0nGIje42q2ignCiseHaxNYjPoRmrJhQQT/HVG83hPmdozK4se5hSCS2Gym03knJ0/CRA== X-Received: by 2002:a05:620a:4494:: with SMTP id x20mr6829172qkp.530.1639529691620; Tue, 14 Dec 2021 16:54:51 -0800 (PST) Received: from spectre.mavhome.dp.ua (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id br13sm266119qkb.10.2021.12.14.16.54.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Dec 2021 16:54:51 -0800 (PST) Subject: Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status To: marklmi@yahoo.com, freebsd-current , FreeBSD-STABLE Mailing List References: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4.ref@yahoo.com> <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> From: Alexander Motin Message-ID: Date: Tue, 14 Dec 2021 19:54:50 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.13.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 In-Reply-To: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JDGx84m7Tz3Q9P X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Mark, Support for edonr checksums was added to FreeBSD main about a month ago: https://github.com/openzfs/zfs/pull/12735 . In 13 it is indeed still not supported. But you should not worry too much about it, since even enabled but not activated feature should not cause problems with pool import by older versions. And activated it will bcomee only when you explicitly set for some dataset with checksum=edonr. Some other features though activate immediately on enable, but compression and checksuming algorithms generally should not, with exception to lz4, which was optional originally, but become default later. On 14.12.2021 19:36, Mark Millard via freebsd-current wrote: > I just noticed that main reports that my pools were created > implicitly matching openzfs-2.1-freebsd (and without > an explicit compatibility assignment) but, under main, zpool > import and zpool status for those pools report a new, disabled > feature. Turns out the issue matches what the diff below shows > as present for openzfs-2.1-linux but not for > openzfs-2.1-freebsd : > > # diff -u /usr/share/zfs/compatibility.d/openzfs-2.1-[fl]* > --- /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd 2021-12-07 21:23:21.573542000 -0800 > +++ /usr/share/zfs/compatibility.d/openzfs-2.1-linux 2021-12-07 21:23:21.581738000 -0800 > @@ -1,4 +1,4 @@ > -# Features supported by OpenZFS 2.1 on FreeBSD > +# Features supported by OpenZFS 2.1 on Linux > allocation_classes > async_destroy > bookmark_v2 > @@ -7,6 +7,7 @@ > device_rebuild > device_removal > draid > +edonr > embedded_data > empty_bpobj > enabled_txg > > So I've taken to updating my existing zpool's via: > > zpool set compatibility=openzfs-2.1-freebsd NAME > > because I use them under releng/13 and stable/13 and main > and do not want edonr accidentally enabled. > > It is not obvious to me if edonr being present for main > is deliberate or not. > > For reference: > > # grep edonr /usr/share/zfs/compatibility.d/* > /usr/share/zfs/compatibility.d/openzfs-2.0-linux:edonr > /usr/share/zfs/compatibility.d/openzfs-2.1-linux:edonr > /usr/share/zfs/compatibility.d/openzfsonosx-1.7.0:edonr > /usr/share/zfs/compatibility.d/openzfsonosx-1.8.1:edonr > /usr/share/zfs/compatibility.d/openzfsonosx-1.9.3:edonr > /usr/share/zfs/compatibility.d/openzfsonosx-1.9.4:edonr > /usr/share/zfs/compatibility.d/ubuntu-18.04:edonr > /usr/share/zfs/compatibility.d/ubuntu-20.04:edonr > /usr/share/zfs/compatibility.d/zol-0.7:edonr > /usr/share/zfs/compatibility.d/zol-0.8:edonr > > I happened to do this activity in a aarch64 context, in > case that matters. > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > -- Alexander Motin From nobody Wed Dec 15 01:07:56 2021 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 9CC8318D66AC for ; Wed, 15 Dec 2021 01:08:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDHDT3vZwz3k05 for ; Wed, 15 Dec 2021 01:08:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639530482; bh=2bsLQk8WaIixLZ/MW7N3nrDVxs48Z48jM2Wmg5IH82Q=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=eoktLdT17zrrDF6taoN1s2WquCDyYdHrcMU/yzlLeofXfHI62aThr2WHxw8HgjjiHMFuOzXNFZK0fe1ZZ41Z8eJWTxQJ+3XIiRFyjwP5WxgByZ2JYWWWf3gHaZdFSNblOS7LoDTM55YQ1WxG8ecR5YDDazW8gV5ojug4qonmN0gdhRIlBqnnqwRpUKXmoqyw8i3FfTHznSe8Nj/JwEgLS8cYvlnhMZECauoXwEm2zZ3ENcoyiqP9DAwDl4Jx5h2b/d2urL+wUxczUJO9C/RMC8/g7vpGS6ncrUVernh1feqgIlhJDsdU5iZZSDrEBUBcuIcSKSEcg6l+MLAKAVE4VA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639530482; bh=0C60AieANyv8dV7SC1EOqgncP7WYxeiQIv3CqnFWa44=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=WX4NCrBiJBnb6d35msm+jaZu+hv3493HTxIUy6WgdF+TEYWhdiAp/bmu0JEnBgLr9bkf17HBoz+WDv6HCL8y1uAXybJKNEo7pYA17b7EcpajvAqv2TPWMMYVxEIPp82VQPKx2sOlmVGGH34ZOehe3MOqtCj7jv1ZtISuifeNDlokhBZrUrLL7iOihXxot7uXHhDz10nOPidyfo2tzvR1Jnw8iPiJ9MVvxAZ50aoq4HJ7esQofpR6IPcRlVwZ8exBBfoGpBwR/yntH2HQZqeus19s4gg9fSv76Gz1Jm+OPdBJBcMVLQtEFzaEmX2THZ3zDHFkhE8vYMN5EJGYUZ9EUA== X-YMail-OSG: VXl1AgMVM1mv2Jel8yJVPxheO5wIBpL.aBs3mSho6uSGAe7wDl7LNN95q4ejDjc 18WHOVmFBev4zdJS6wULpbDDyarbdrEeUVzhE6QluzHsl.ZybmBZgBrhP4XvWbhRZ5zOXmciJcuT dJZyNC3L4Fewsp9iqNxsTv7ZR7Nsvx3PrunNJNT7NF2hIYkp4Zm8yeyc4FGwuXahCT67m6LAGzRD 5r6LEAw7t_TjoGbm3_5386b528UfgjZ6PwTouMi162CA2WHyDz8Qcwi708pz7vMt93nM_hSyWcB3 xI0c8pEXeD.on_zLvIL.gpK3I7AKYHu.G94Nf3jywG1iSzdHK02uKcU9m.sCe7G5HNSfsJCcc7aH 1AUycLRrLJTAtvV9X6Wkd24vMFnPm8k3MOtVrWigNC9Enbd9smYvne2o5JfEFhG1d1IFJsrfH.4Z 09C6xEL_XJaECNOZ0ctdTgxu7YVxdAlOQZY_SorNlJ6Pqztl41kmLm0YD_o047ZOwyLAfLNB1HdU dQR_ROFQ1uGnMAJ0raWC4ribJLdr72xppw2jVgF2kTi3QRNcy4D1SHUAU271CdvPwP5gzQItuTK3 XkukLNdCr8Cg4wgYaAKNegcnklQJcmnmGxDUULykAcV_s3cP2nrJGfNMv4MFlnrzilxM0CUNTVtj QK_UC78uF499obCqaFL9lKyWm0jo.kb0tVIZCXrqfhP34zQ9vPSl_YMpznoshor_v7C.sIu.d.fh s.oGQ3OiKsg6A6T1HJj2fyLzogDFAVEmCJEJ19Koy9cOMuElt1ZDlcIhPGoeWttroIIDfTSZMwxw rW8V19TjvhmZy9xp.mpKimgZndk7fT7XJLqgq_zlbuwMBX_LsdJ6zS3P.fvN_cyxH8IJmLmLmK_V xTElwtcpjmX_e5rIYr4cZizMofut9pPcXqYr.PJ.EAV2FwKVoc2Q6Cw2Sj2lNUKevYXFisOJZS22 gtDxyss_Q1UvdNauBZpYXnE2IujAwM5QrgXwoumfolgdUwC.DOw7mp0mY125yeJLIlkLLzzTY2M5 XMPqo1OJHgG2Fi_uFzljTczD8cBOZGuPJdvrdQrWooM3Uf3W8sYsarLBSZq4s5vmLY.Ad6j3wnPc XrNDSgxCfucoPRO5jkjqy.hv7tuK1gSMD2UHJOU.zv27MFxr59CTix1ypOm2m8PL1Ga8uT2.irfK P5QpQsOVDb8Bb5BUx8zHbEtPNkS.G2tyCJW6LZv8u5cfV9.XrvtCdlJCVTLpudSh5X7Ri8tA3x3S MQJaJ4i6gZ_l8_ZXG8VHMLmKHpQ2CWZUAWuBhh51jB57Cy7VWZExb5QsKDzYjZ0IiPhT.D2WgV7r Ag2g65nSa88pedlpkASbKO4t9j.KBenyAhUPRWz9tpR4rTsuwniXGRw3ydzLzvZzXk6pVNX1A0gM rfVHD70.q_oV350Wpv9rlgMPdsnVpM1JwbphaLW64gT9Y7k69j8xQHFRKszLu59izqAHPZu8tP_W 3l90tZw4P53KdftQsznQlNZjI9zdwsYgoV37mUf3R0HHhprUL1mnHb0OmccH2oEIuTKhUrMQM8og ETuOiiaIdyz041lwJBxDQR91gt1hpxkkjp2X_P19ghJAWJcfEndN1rK9bbupF0hFIjHVJEL2GkSB xB1AhH6zzDj8EyOl77ABqhAznRY1ItpzQynlM5m7BXcNHLi2gWYWR1kSZ4midZfA9L6Lo25wnvXX 6m4nR20wHwM31DGH1zlT74oYFhsFPX0LLEjNt_6721AzdsH51pqaeopJ5TCGy7sKFDWq9yG3.z9d DQyXm7Yr9yR0iV7OOg3prt07LWQu0JfcGLcoG.Rn.Cb9nJG5DHbW1vsWzJ2EPTTs2wi2.p5fecTT 94nMxQ07AKM6wgIzp6d1nbM3HiFnW2Kbdat0BNnyXX8Id46uobYUPqFlky0tsjS6TqikICrrs_c6 qSeVsEWP2ng0wq_ozFi5xmpetr6uJR1dyxT1.XhG4uhQsL2ua1890Edg8k5uCBd4RiNeZ8FYQoPv 7kxeYns0UrKw1YMBni8DX1ibjKJIosz8eTvOmFBWXmjBm6WK3V_hGbgYmHrBSmSi.PgzH7vvrKT5 s8ZA5nO3pU4ip.gGIUADmZnmCijwCKTU7SwGM0EVCEe_5Jnv49o55VBMPGtrUGpAz8tWZPVqBsQv 4bngTQjw_C6IxA.GAXxSEVdZf4LKSZXJq910iLuBF_gmNyPZ.UDpWngrlj41_efaboOcJSN25bJq 6089QrA3m9mRQGhcURTFtpjRDt3uhD6m4KaxBH8pOD3FZiBUhY8PxTSJ8WFX7XtMh.b3w1D101LG hL6d93JXJ0B5lkhtLQA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 15 Dec 2021 01:08:02 +0000 Received: by kubenode537.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1cbb1e0026a65197ff1b71470d48129c; Wed, 15 Dec 2021 01:07:57 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status Date: Tue, 14 Dec 2021 17:07:56 -0800 References: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> To: freebsd-current , FreeBSD-STABLE Mailing List In-Reply-To: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> Message-Id: <5C8E7635-4EF6-4D07-9250-FA0D108B4F60@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JDHDT3vZwz3k05 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=eoktLdT1; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.97 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.19)[-0.186]; NEURAL_HAM_MEDIUM(-0.40)[-0.397]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; NEURAL_HAM_SHORT(-0.89)[-0.888]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-14, at 16:36, Mark Millard wrote: > I just noticed that main reports that my pools were created > implicitly matching openzfs-2.1-freebsd (and without > an explicit compatibility assignment) but, under main, zpool > import and zpool status for those pools report a new, disabled > feature. Turns out the issue matches what the diff below shows > as present for openzfs-2.1-linux but not for > openzfs-2.1-freebsd : >=20 > # diff -u /usr/share/zfs/compatibility.d/openzfs-2.1-[fl]* > --- /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd 2021-12-07 = 21:23:21.573542000 -0800 > +++ /usr/share/zfs/compatibility.d/openzfs-2.1-linux 2021-12-07 = 21:23:21.581738000 -0800 > @@ -1,4 +1,4 @@ > -# Features supported by OpenZFS 2.1 on FreeBSD > +# Features supported by OpenZFS 2.1 on Linux > allocation_classes > async_destroy > bookmark_v2 > @@ -7,6 +7,7 @@ > device_rebuild > device_removal > draid > +edonr > embedded_data > empty_bpobj > enabled_txg >=20 > So I've taken to updating my existing zpool's via: >=20 > zpool set compatibility=3Dopenzfs-2.1-freebsd NAME >=20 > because I use them under releng/13 and stable/13 and main > and do not want edonr accidentally enabled. >=20 > It is not obvious to me if edonr being present for main > is deliberate or not. >=20 > For reference: >=20 > # grep edonr /usr/share/zfs/compatibility.d/* > /usr/share/zfs/compatibility.d/openzfs-2.0-linux:edonr > /usr/share/zfs/compatibility.d/openzfs-2.1-linux:edonr > /usr/share/zfs/compatibility.d/openzfsonosx-1.7.0:edonr > /usr/share/zfs/compatibility.d/openzfsonosx-1.8.1:edonr > /usr/share/zfs/compatibility.d/openzfsonosx-1.9.3:edonr > /usr/share/zfs/compatibility.d/openzfsonosx-1.9.4:edonr > /usr/share/zfs/compatibility.d/ubuntu-18.04:edonr > /usr/share/zfs/compatibility.d/ubuntu-20.04:edonr > /usr/share/zfs/compatibility.d/zol-0.7:edonr > /usr/share/zfs/compatibility.d/zol-0.8:edonr >=20 > I happened to do this activity in a aarch64 context, in > case that matters. >=20 Hmm. After (re-)import zpool status seems to track the compatibility assignment: no complaint in . . . # zpool import -f -N -R /zamd64-mnt -t zamd64 zpamd64 # zpool status zpamd64 pool: zpamd64 state: ONLINE config: NAME STATE READ WRITE CKSUM zpamd64 ONLINE 0 0 0 gpt/amd64zfs ONLINE 0 0 0 errors: No known data errors However there is the following (done after the above): # zpool export zpamd64 # zpool import . . . pool: zamd64 id: 4513815084006659826 state: ONLINE status: Some supported features are not enabled on the pool. (Note that they may be intentionally disabled if the 'compatibility' property is set.) action: The pool can be imported using its name or numeric identifier, = though some features will not be available without an explicit 'zpool = upgrade'. config: zamd64 ONLINE gpt/amd64zfs ONLINE This may be expected/intentional but was not obvious expectation to me. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Dec 15 01:21:16 2021 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 95BA518DAAC6 for ; Wed, 15 Dec 2021 01:21:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDHWr24Zpz3nKJ for ; Wed, 15 Dec 2021 01:21:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639531281; bh=ZKxO2QUR1VPZT3bIhH6ORbcfWFVz4EYu3Fgmu9RmrjU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BRKMk0T/LXALTwmu55GOf+BdtiQW1B9kqAmw0RCOKdQlemQ4EDcLxGt23zU0zrGIZCczO27I7Pt3ynmi8HNpttZxkG/csRDlFN/Vl+cW4ejzBi0C8FU3f/55/oVaw5D7+qSUXWWtgLyHKUdAOwzaT+QI6da4Z8BZ8IaJfKSOg0b/osu4YbfMIQYmVl6YKTEDjXM9NRz7fM7aIIxkLCy7RDuM085AkcIuvuh/+XRDzGBNPdYV8alV2taeZY97IFn5ZxdQB26ZtGWtENPrQu5lGJSoQl3YrAg6uYqwmrkPBmiaz6PHP0K08TM3jNBGQoe7Cv++TFI9FG588vkgTbszVg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639531281; bh=t3goKJQHGR4qIJGi6K3xnBJE6sA58es1BRGNp6HUG5s=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AsgPUrkHmwy/fSb64U2rW74cyDdbaJ25CSPS4SEvVppTVw7TyRHScc0Vds3HB77Jf9rvDeuQASSZGDM9hOFJee+PVPwD+bhAMpfiNrCnp4gp41qSsFJEyONACF6A/PRkY3yBR+MbpIJKUHFRGThIRclaY4nsuwim8VdATAAhGbzgBGg3hOiasfx7b+eNJwcwcWYq2h8KcT+xW/h2XFZz0wB3WgYRZEPYIi6KDLS8aI4aCyoPewQPlbke/uwaDw+cy1uB8bW0YzvMVW+fzmmE9pOYDMk/mEgsSPeXMHA1xLuxrFAugmZhuSOFRoc/MvihxMslysJt6d6bc+RDYACLaw== X-YMail-OSG: .Dx6VcQVM1kzCV_1Xe.ENQvK0k_yuyHsbhgvSrxY7IvGHP9K1..dDtkOeq6iT4n yFjg4LZxjBVxMZ2xvuHMsO7ML2p4PFXqZj5k4OQf2jPYXZA2TySdOYw9t8jtXcabOnossJKBf8iV Qt27Mg9UVO46ObbBWTnepWZLw5QPfgSpJn5._cDsf11FB70RRoVE8cV7_lMgj8bBh8oPV7dgQaHi 9AVtzAirhwJ_MC8bjMrq9hEjB0YCuJ9ZTbuyL421aDZcmcoCuBIB0Ctxhq7O_im6QgY_3m2TAq_R pw3.6EC_tAvjhiDLEbrtwXfbOAKQh2Ml0gWjeI.mjFEr8q7mlZB5KD3hPM0.5A67qWCRvKp9INWa xSslHPhNH2Mggqv5DSd57GAhId_uXLaN601f3LXsdAXk7ysJQQaX83EC_333CCS2c5f3U6cwvJTD NyXDhlApXaC1UceJT3oUCwewwSJZ_nKT5toacXWvcrijQ3QMqbnbmZphY6D1NN7E6krR0MuakE97 nZCwArJUlKz0GEcEHeqJOIfzPs.m6BcPQNbir69vngq4DWvsw_g36u1655rxOlZrMsDiefQ_QKKG REZlllPPxCL1f7L7J9fPvl.gXS6DiPtX4Nct5hQF6VOD_1N9E2fL8Kx_.fHNsugGAhel_91EsPG2 XxohD753T1Z4zai5SY1_r.fyzq2RLxM7QK9jYxjmyhvu6Rp9sacb51ytQ9m5F4NsZZCvW99BTNbw 7VRkYT5Uk3FWvlWykV9T_t8FrweJEq.hOV5moMbjaAj0ZQAq6L3k7MTNENaVhEsjI1kW.npgfEn0 LGJ6FT7Zt1WFUsyAFU6n0oNW8c0YLyIDh1XXPrGXF7WGe.a6f4IKgI_h5P19BEZO4vTBd4Y.x50Y nM.FZ4MvKBmHwCCLsxSnQBzjaLL5TeWKjOhpxvb4AYrGlNZWRS8A4o2GB64PIHIhK8Ooi_4wlieK gZ4QgMe9b8dfB1oXDUGuyqqM9aSszveMEuDtIvlZnlD1RIC4gZ_aoJI.N6B3uQCFBSRvHJhPm1e_ 9g.BHbQr4QivkwqaC64Dv7r0USXfFtwdFoHVlUlSQ9e5y4ez5.NRecFG8S9HJJlYMzP0gji.CgUE logTdceduDpAQhLOGSXwLPaDEIY_z0tZFvui.ll3ji0V7TQ2mncImaeg8ObE09tWeDm.ljDqCifM 14SeSMVu3r7oaW_VeCY3HgwGNbSvH43k_CTb4UQoe_M1qB21P6ijpQvZ95l85bIYvGweACFzmvHk Ztt_Wql_Rc1HHLm_Dx1Veq5kqNu.c9Hrh_QqWpN_5GH_w5fXglShfqFIgOSADLvKNLLg0zd3vjlH 53LKiuGPfA.FlEYu3sdvV5t7hG8LbnnUjEJW7Rlr.JXEnlZsNAvljT7MxwSghAy2jJdW.La7jm.U 7mFSJxc7bPZLLSZ3QmP.UCiAYdb0ud5ACpfDywy4zppFk8SXVVw21_5B.5F40aDzPGhoaBnj9a6n niVHha1KEE1ylcI9tZ_wbsRM7kmsRxc8w52TKk6nC1i.uDpOSwbGwGAJPYq0wvvfXD_urWBgwD_f Af.HIx8.Ag.EtKGejMzj4iS9SMET3qf7XG6aiHjlfKNsYsoTmGKX7vfIq1D6FQ_Bkb5rRrohk_ed 91WllVwSII32uGFtQ62aKqsVIGeGRbXvdyBa8IyJXN0T6chVvdW7r68CiRmDZJKkr5gmpIJCqHNW n9rY2nQz58yyQvc6NMcxMFwfAgtBFAhdn6rQjDdAyTmYPlbUL0Te8GqtzxEBLwnIL9P.XR0GXiED et_gfFXJND1jzVnZEv9d64zKPS6oKoe48vCxWGXR8h_PIvOV9l6rTxUW25evP8iQW2.PC1gh5Ve_ xgkCZ_jesgUeaYWx1BUXhO_q_oeHKEpcIyP.CGwjfMPD_J8TQv9XR7IRN5rJESdInh3sLNqug4Ca S9wOrp1pN9Io8VIRijpj0_ggg5Vg8vGWTPgKWbGGDBfx8oC0b0rAsZ4TsX50aHAqdoz2tsNGuW5Z LXa2cFqLNFpTnmk3ARwCOG7v6aQDiASbQnV3pAq0wAmk7NNt3YZalCb.skOQm4Ym3kJ4ewJXgwbe tspB3AV_U7IgvMJJ_G_jW94JKkgBG4gxJj.a9GbvVTO4SpFjOKsUn5mEIcWPNMOXtIf6vTjOv3fj .ehM5iCnj14yD7.s9L68bnBE5UUbgeAANZXxx1yPPGpsbwIWhzTGMlylEMp11YFsuh6AiBf3rRnZ OcrDemYQeOzl29qWnfYxpMfM8caGnRaMIwGNaxW7Qu8cFD4MXkCQR102zYzlGEWQkCrvw4Yn2GZB zF2bb.TUvfbVzyu.otw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 15 Dec 2021 01:21:21 +0000 Received: by kubenode515.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3b0fba5a032ab06484759bae9fb4f7a5; Wed, 15 Dec 2021 01:21:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status In-Reply-To: Date: Tue, 14 Dec 2021 17:21:16 -0800 Cc: freebsd-current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4.ref@yahoo.com> <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> To: Alexander Motin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JDHWr24Zpz3nKJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-14, at 16:54, Alexander Motin wrote: > Mark, >=20 > Support for edonr checksums was added to FreeBSD main about a month = ago: > https://github.com/openzfs/zfs/pull/12735 . In 13 it is indeed still > not supported. But you should not worry too much about it, since even > enabled but not activated feature should not cause problems with pool > import by older versions. And activated it will bcomee only when you > explicitly set for some dataset with checksum=3Dedonr. Some other > features though activate immediately on enable, but compression and > checksuming algorithms generally should not, with exception to lz4, > which was optional originally, but become default later. I presume that because of FreeBSD's releng/13.0 and stable/13 (and releng/13.? futures) that: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd will never have edonr added to the file. Sound right? Is there going to be a = /usr/share/zfs/compatibility.d/openzfs-2.*-freebsd* that has edonr as well (instead of using a openzfs-2.1-linux file for such)? If yes, when does the file show up? Does main get drafts of the file over time until there is a releng/14.0 that would have the final version? > On 14.12.2021 19:36, Mark Millard via freebsd-current wrote: >> I just noticed that main reports that my pools were created >> implicitly matching openzfs-2.1-freebsd (and without >> an explicit compatibility assignment) but, under main, zpool >> import and zpool status for those pools report a new, disabled >> feature. Turns out the issue matches what the diff below shows >> as present for openzfs-2.1-linux but not for >> openzfs-2.1-freebsd : >>=20 >> # diff -u /usr/share/zfs/compatibility.d/openzfs-2.1-[fl]* >> --- /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd 2021-12-07 = 21:23:21.573542000 -0800 >> +++ /usr/share/zfs/compatibility.d/openzfs-2.1-linux 2021-12-07 = 21:23:21.581738000 -0800 >> @@ -1,4 +1,4 @@ >> -# Features supported by OpenZFS 2.1 on FreeBSD >> +# Features supported by OpenZFS 2.1 on Linux >> allocation_classes >> async_destroy >> bookmark_v2 >> @@ -7,6 +7,7 @@ >> device_rebuild >> device_removal >> draid >> +edonr >> embedded_data >> empty_bpobj >> enabled_txg >>=20 >> So I've taken to updating my existing zpool's via: >>=20 >> zpool set compatibility=3Dopenzfs-2.1-freebsd NAME >>=20 >> because I use them under releng/13 and stable/13 and main >> and do not want edonr accidentally enabled. >>=20 >> It is not obvious to me if edonr being present for main >> is deliberate or not. >>=20 >> For reference: >>=20 >> # grep edonr /usr/share/zfs/compatibility.d/* >> /usr/share/zfs/compatibility.d/openzfs-2.0-linux:edonr >> /usr/share/zfs/compatibility.d/openzfs-2.1-linux:edonr >> /usr/share/zfs/compatibility.d/openzfsonosx-1.7.0:edonr >> /usr/share/zfs/compatibility.d/openzfsonosx-1.8.1:edonr >> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.3:edonr >> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.4:edonr >> /usr/share/zfs/compatibility.d/ubuntu-18.04:edonr >> /usr/share/zfs/compatibility.d/ubuntu-20.04:edonr >> /usr/share/zfs/compatibility.d/zol-0.7:edonr >> /usr/share/zfs/compatibility.d/zol-0.8:edonr >>=20 >> I happened to do this activity in a aarch64 context, in >> case that matters. >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Dec 15 01:35:49 2021 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 DC6F018DF21B; Wed, 15 Dec 2021 01:35:51 +0000 (UTC) (envelope-from mavbsd@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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDHrR5dZRz3rqs; Wed, 15 Dec 2021 01:35:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qt1-x82b.google.com with SMTP id a2so20247131qtx.11; Tue, 14 Dec 2021 17:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=I3fW6l17aDAte9QIALYZqmTDcZY061EroKnoKtRRKys=; b=ItQkVU9nBr7D81ANzbTUdLXBj2KL32OhlHjvb2KjXEn4Nen+uChms8fdP34vUn3Jnm BavmukxAd8weZ5vvh/if+UN/lISWnr8+6mJQqxfzSCiv5eqY9mkJgw2v3YtkT8c/oZMw ctYuCKsM6grnLlzN6+mt1KZI4SyAXhO7ub6aObCVJnxp/3QFiRvFRczHi0O5K05PhZMl q2pkYXFO7EOgsjva4MX0Zd5jW9b2ZCtBq8ojjoN7ARRSSwu2Qj/wek5UsqtYYEVS6nIz LMEAeb1OKyN++wyp8eAex8HO/Z/UIicWvr5XCQtXYG2gzAhYJwmUhuxH6DHWsKWMeiSK aG2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=I3fW6l17aDAte9QIALYZqmTDcZY061EroKnoKtRRKys=; b=RSatShG8JNV9utlxbMPcS9pa8jvTM8KILs4QcGZG96BGzey1Be3ZhTuFKeAKUDohR4 8jL+IviBhPrwUhQpJUy67sHRfWFKudrc6oUWnRsrc5IJkF7JJMgn3g8FqzYSl06Xejtu muu7neGQ7NnEiLCFbuydowRTiu74eEMSGA3vCQE3/e3OlEyAnHlFfWbF2P6U+av/W+E3 kbez5SZz7QgcGDE6Ctuj+bl9RNFkNUeq9ATMNI8Nn0UQhAovGjKLQS1Esy4E+2FWoFdl CYT4+vNy0nKH+pZK64qT7ddvMruPq617pyFVGvAcaqsriI2caICXnDF84DVICOnG+Ikz 5ACA== X-Gm-Message-State: AOAM532eN4Xqyrsbf34xnoiD/qTUFpKjujp1pydio5ZvgKuHyJfygEPb mgmy0mtIyQ+e61lEjldu88YeNv5tRvs= X-Google-Smtp-Source: ABdhPJyrFtM97aMI5JqfcMGbFO0rcXF6XSxpTImrdNabyGIDJfTwJf7M1Xbc7fYDI+aclTl1+QEuwQ== X-Received: by 2002:ac8:5881:: with SMTP id t1mr10006946qta.414.1639532150701; Tue, 14 Dec 2021 17:35:50 -0800 (PST) Received: from spectre.mavhome.dp.ua (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id d6sm383981qtq.15.2021.12.14.17.35.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Dec 2021 17:35:50 -0800 (PST) Subject: Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status To: Mark Millard Cc: freebsd-current , FreeBSD-STABLE Mailing List References: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4.ref@yahoo.com> <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> From: Alexander Motin Message-ID: Date: Tue, 14 Dec 2021 20:35:49 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.13.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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JDHrR5dZRz3rqs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 14.12.2021 20:21, Mark Millard wrote: > I presume that because of FreeBSD's releng/13.0 and stable/13 (and > releng/13.? futures) that: > > /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd > > will never have edonr added to the file. Sound right? FreeBSD stable/13 is tracking still alive upstream zfs-2.1-release branch. It is still updated periodically, but primarily with bug fixes. > Is there going to be a /usr/share/zfs/compatibility.d/openzfs-2.*-freebsd* > that has edonr as well (instead of using a openzfs-2.1-linux file for > such)? If yes, when does the file show up? Does main get drafts of the > file over time until there is a releng/14.0 that would have the final > version? FreeBSD main though tracks openzfs master branch, and as a moving target it has no compatibility definitions. I'd expect by the time of FreeBSD stable/14 branching there to be some new openzfs branch it could switch to, but so far AFAIK there were no specific announcements yet. And enabled edonr is a step toward not differentiating FreeBSD and Linux compatibility settings any more. >> On 14.12.2021 19:36, Mark Millard via freebsd-current wrote: >>> I just noticed that main reports that my pools were created >>> implicitly matching openzfs-2.1-freebsd (and without >>> an explicit compatibility assignment) but, under main, zpool >>> import and zpool status for those pools report a new, disabled >>> feature. Turns out the issue matches what the diff below shows >>> as present for openzfs-2.1-linux but not for >>> openzfs-2.1-freebsd : >>> >>> # diff -u /usr/share/zfs/compatibility.d/openzfs-2.1-[fl]* >>> --- /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd 2021-12-07 21:23:21.573542000 -0800 >>> +++ /usr/share/zfs/compatibility.d/openzfs-2.1-linux 2021-12-07 21:23:21.581738000 -0800 >>> @@ -1,4 +1,4 @@ >>> -# Features supported by OpenZFS 2.1 on FreeBSD >>> +# Features supported by OpenZFS 2.1 on Linux >>> allocation_classes >>> async_destroy >>> bookmark_v2 >>> @@ -7,6 +7,7 @@ >>> device_rebuild >>> device_removal >>> draid >>> +edonr >>> embedded_data >>> empty_bpobj >>> enabled_txg >>> >>> So I've taken to updating my existing zpool's via: >>> >>> zpool set compatibility=openzfs-2.1-freebsd NAME >>> >>> because I use them under releng/13 and stable/13 and main >>> and do not want edonr accidentally enabled. >>> >>> It is not obvious to me if edonr being present for main >>> is deliberate or not. >>> >>> For reference: >>> >>> # grep edonr /usr/share/zfs/compatibility.d/* >>> /usr/share/zfs/compatibility.d/openzfs-2.0-linux:edonr >>> /usr/share/zfs/compatibility.d/openzfs-2.1-linux:edonr >>> /usr/share/zfs/compatibility.d/openzfsonosx-1.7.0:edonr >>> /usr/share/zfs/compatibility.d/openzfsonosx-1.8.1:edonr >>> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.3:edonr >>> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.4:edonr >>> /usr/share/zfs/compatibility.d/ubuntu-18.04:edonr >>> /usr/share/zfs/compatibility.d/ubuntu-20.04:edonr >>> /usr/share/zfs/compatibility.d/zol-0.7:edonr >>> /usr/share/zfs/compatibility.d/zol-0.8:edonr >>> >>> I happened to do this activity in a aarch64 context, in >>> case that matters. >> >> > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > -- Alexander Motin From nobody Wed Dec 15 03:00:41 2021 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 05A4818F18D2 for ; Wed, 15 Dec 2021 03:00:56 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDKkb40Tgz4dBY for ; Wed, 15 Dec 2021 03:00:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639537248; bh=cRD0vKE32+WNZmuuOzlr3VjRm9hokOcxcHbz6DB3Y+A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fjma/csfCUx+hKQgbzzVYZfrAu91sOqmfDo7xClx2bxb2WILkV3GawPGWxpaIsuEnq+rMV6PLJR1ke8oaeDdT1dF3+m15vn0jnVjNWFMQem1nbw4Evutgf9DHqRoLSarsnVo2238VlzkIMNlfkx0q9ZEqlLwDLR049EeZmHS6TRxyPhWl6gE+5eKCUImsuRiASn1pMpnoyuwiksQQVV83T1GPsgPfb2XCAk6+4vzPY4IbdRsJsSU6utWV3nWYNLpaD8cLrdLa9NOvLRgdm80g7BgSj3muOlbRzuWFeB4GY8siYbH2oXhsY+gF9c/VbpLyK8fyy5X9as1upc9YpWJaA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639537248; bh=ovfDRN1EWxWJDczAm/etTmvkoiIM8sC5fFCtrG/rls2=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bUtuvESLZ/pu9116zpD15nT9i1zGZoy0qFEpUzWL7zRzEXIYOfgmtcMtlhCsgSHFiQStPRgKlNcF0L6r92K6QudY20zuhy8EtgvAIwEQfTHneTcKtxJ53TfCdXwer/72laZT9czyuzR1O65UuvE6R5mY0UybIvH45FRVbdq5iOHRSIVq+JuFhgymb9tRKAi0cxAeJMuSlM3+OxKAJ5Jh0sPLMdryUTOzVp4mBQGQzCdY7M3/M4kI5ua6X5q86qIJeWawIepxwpKpMsno27BMbC7c8CMQmq8q7LqnM5fW/cC8xhGLVhUBFPrHB2Kn4478vKii2OWugTG3x5XiRp/nDw== X-YMail-OSG: 03QqZUgVM1lktEnPRnkwbP3mYR6H0BTcZyYiJ9D6PnD.2RzYPH.wMi.hfB8X7i3 FOE6WNJtGRkGNfkFvChMKD0tiA6C0GrgLEEakLcajn7Pkieb5WvIDVlx3vdlO3wQf9_iASXV3puX 436Dvk42AyTmjEzKTHwbaGP90eQq4AtYy88l5NXI11CfwU7QXI54uNdNGtQw8B8.29KEi1CSQl5q 9p8HncrB0w3pjltp.YrXFodYhbGJSqqW454PvQcjYoYbuD6ldTBfJXL8vIfm.OoyK8Qdpy.qqhLd 1bpD5cw5XhYmGCWtbU7Gijj4GaZDFN2hpuNqXxK.wYXonASEHGM7gAJjR.fFViZrif29vw148Dt0 FMsvhmj8vPpm2pBHELNcXfdeI05OnlJrC6buJGRyywuBSGfK.vFIlZjzMRIFTC9qWS0qVrLRRIoF YkZyKLvzzj.OAMsnN.KxdO4oDfYTYkNNJHME8MeuoTTr5blcjgCyRSr31EEJ39D8zX165dRzLOUy 2n0dSu1tdqwKufvWS9RJTg0jZvoW6kiZR4QgVJhd2tvu45dCZ4HSuiHQIFIkCylqz0zVSw3ZVZZg K6Hv9xKl218gUbKbmlEpTIIbJC2t4ZlhkmGnP9EqfD_zsw5_0HBcUdsC6V5czYc5eUksKIMoF5ja iCvl376ejvC8lmcSNhppLcu9F15O8ZN1rdu67dmkH6Pz85Rjf0B12z1._P7DJagavFlUll17m1cJ g56uAPCcF6bFBh7MefXkaQEZsVRzq6Ahq0GVmu5UVp9nMI9g2CbZJ8wn_X.MO_uE3IGrNDaAoT52 olnrTZf5bodGnDw8ZVg6Ise.AHemfFoLkRcw9404JieSFFWQhicAKBZjGmYZO94wp4V1rrYDaCqx 8fpjav_yC0eF0a6zRlYVEVDDJMAKrNyRXtbT6PML5cuI3kklkWPtJyVgbCGXIRq2R9yGcMoNDdbR roT80GLtqQGG3ozqz2zyh8qE2eQV2y71MplertClenOwtjgK.AVnZA_NyCruLu16ORFQ7UbnC_ZC AK57YUuZ83tWMOuW2cJHDeE3Imib4jPDRHdQ2PBq_eGxzyY6kNsfw_y7_VM_OFZ5wy7TxKkLY9Jq 26q7yVM5EErRtEwOPfEvCQuHg0BIF7tVxyF0FqSEmpYlLCwdzkUtiUL2Zq7vz74e6G7O2NYWtMfO u8.Ii6Q8_p_d1blNJ.EE48DQ4Xqaln9m3UEqqRySOUQ03ZFIJqFJ.5YPBRyxjl_r47TlSN2U2MrJ 9LPhVlK669WdLVVfQkAz8iKN4XUwQ19Nk2xUGT5MaOD.gYERVU7IRPZWlfBpMyv4YOPgJzyp286t zOOyUi4shJQtuhp4Na8Aik0mu2YcDRznH1RKBGeumQBsQ26298JAZPCVJ4ENdJeYXyw3wNKT_JuH L0uIrBP40Px3kfuuZVvNP60DYaUi8bXlCCnp7aE7f6_3l23OWLyx08aN7QqpygJD7ifuKVakd7PS hst2faXLAwf3nGE2FnSN1_x9rqhgB4u4ZMLDzqjPuMIpQM_fBcaaokjzAbw52LV58_KDCqC0MmlJ 0IRhKOleY81o3yXlNJyzXL34b.NccsS7pdFQ3WxzVqbadLSFRY.FaDUz4OH72OMxnI9qm1JAKipN lPjrUruJ2yRbzNwuQMQn2PWYWVPCIlREBaLlR1vjIb9n_cbER89p2tRPHpBG.jm.GJqT41JhDsay MBeinPtj8JY4Wdcj_QySbP7BfP7Ejsv8azf6OngCLid9GilXQ.F69TKJIZdHv1IylTRBfBIqyzP6 Ll1oA4_JzmmppJtIQa2VjE9WNLPYf82huhm_Ghe6WTjMLEJOVmdjQK2QVUcq5NQNVL6AHLNWAMmn kt1hpbLbc41Xi_DIGac4UFhbIeb25NT3cyaXLjg7NRuljsS7Sc6Ri5SRfZZ26kmOtBNbglGSFZbI 4.UWWqNA9ALm5ht_8psxjftiRzJKQyb6uMbjmyiJV_7QtIcMm4lgWWOPT4ugOfffiE46tFYGGqOf QDLwhezpdnQ95zVZpN8oR4SV_ve5q1HaEldnEll5Gi245lOEmcI7xTbVh38urewFl3rLn4rVDgsd Lu4CNVpgtKcI8HNQPrqObSLXZj3JrLZOBw5u5VOwKcxQED3ZPr6T.kAedKTvkLLO17rq_iSjin0A 1cXPhMdVB.tcsOg7hslpm3H89c9Ld212OHNs5PWH0XE7zCzzy5Dloqe0v8N6EV.mTRbsdAxvtk8X nhaMWUupNjwWlm1j.kgLBUebX6D_wLLWS_0hL5MXE X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 15 Dec 2021 03:00:48 +0000 Received: by kubenode502.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d5abe871048774b325a8ffaa4999ad44; Wed, 15 Dec 2021 03:00:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status In-Reply-To: Date: Tue, 14 Dec 2021 19:00:41 -0800 Cc: freebsd-current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <0C484963-D833-4B12-A9C8-8FADC0EF1D9B@yahoo.com> References: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4.ref@yahoo.com> <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> To: Alexander Motin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JDKkb40Tgz4dBY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-14, at 17:35, Alexander Motin wrote: > On 14.12.2021 20:21, Mark Millard wrote: >> I presume that because of FreeBSD's releng/13.0 and stable/13 (and >> releng/13.? futures) that: >>=20 >> /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd >>=20 >> will never have edonr added to the file. Sound right? >=20 > FreeBSD stable/13 is tracking still alive upstream zfs-2.1-release > branch. It is still updated periodically, but primarily with bug = fixes. I infer from the above that: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd is unlikely to be changed to be inaccurate relative to releng/13.0 , at least as long as 13.0 is a supported FreeBSD release, but probably for all the releng/13.? . >> Is there going to be a = /usr/share/zfs/compatibility.d/openzfs-2.*-freebsd* >> that has edonr as well (instead of using a openzfs-2.1-linux file for >> such)? If yes, when does the file show up? Does main get drafts of = the >> file over time until there is a releng/14.0 that would have the final >> version? >=20 > FreeBSD main though tracks openzfs master branch, and as a moving = target > it has no compatibility definitions. I'd expect by the time of = FreeBSD > stable/14 branching there to be some new openzfs branch it could = switch > to, but so far AFAIK there were no specific announcements yet. And > enabled edonr is a step toward not differentiating FreeBSD and Linux > compatibility settings any more. I infer from the above that it will be much closer to releng/14.0 's time frame before there will be an additional: /usr/share/zfs/compatibility.d/openzfs-*-freebsd* ( or a name that does not even mention freebsd or linux but applies to releng/14.0 ). Good to know. I could imagine FreeBSD having links with names making it clear what each FreeBSD release should use for a matching feature-list file when one is desired. For example: # ln -s openzfs-2.1-freebsd openzfs-freebsd-13.0-RELEASE I had to do multiple comparisons to know for sure what file to use to have a match: it was not obvious from my background knowledge. (=46rom what you have reported, I'd not expect stable/* or main to have such links.) Thanks for the information. I know better what to do now. >>> On 14.12.2021 19:36, Mark Millard via freebsd-current wrote: >>>> I just noticed that main reports that my pools were created >>>> implicitly matching openzfs-2.1-freebsd (and without >>>> an explicit compatibility assignment) but, under main, zpool >>>> import and zpool status for those pools report a new, disabled >>>> feature. Turns out the issue matches what the diff below shows >>>> as present for openzfs-2.1-linux but not for >>>> openzfs-2.1-freebsd : >>>>=20 >>>> # diff -u /usr/share/zfs/compatibility.d/openzfs-2.1-[fl]* >>>> --- /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd 2021-12-07 = 21:23:21.573542000 -0800 >>>> +++ /usr/share/zfs/compatibility.d/openzfs-2.1-linux 2021-12-07 = 21:23:21.581738000 -0800 >>>> @@ -1,4 +1,4 @@ >>>> -# Features supported by OpenZFS 2.1 on FreeBSD >>>> +# Features supported by OpenZFS 2.1 on Linux >>>> allocation_classes >>>> async_destroy >>>> bookmark_v2 >>>> @@ -7,6 +7,7 @@ >>>> device_rebuild >>>> device_removal >>>> draid >>>> +edonr >>>> embedded_data >>>> empty_bpobj >>>> enabled_txg >>>>=20 >>>> So I've taken to updating my existing zpool's via: >>>>=20 >>>> zpool set compatibility=3Dopenzfs-2.1-freebsd NAME >>>>=20 >>>> because I use them under releng/13 and stable/13 and main >>>> and do not want edonr accidentally enabled. >>>>=20 >>>> It is not obvious to me if edonr being present for main >>>> is deliberate or not. >>>>=20 >>>> For reference: >>>>=20 >>>> # grep edonr /usr/share/zfs/compatibility.d/* >>>> /usr/share/zfs/compatibility.d/openzfs-2.0-linux:edonr >>>> /usr/share/zfs/compatibility.d/openzfs-2.1-linux:edonr >>>> /usr/share/zfs/compatibility.d/openzfsonosx-1.7.0:edonr >>>> /usr/share/zfs/compatibility.d/openzfsonosx-1.8.1:edonr >>>> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.3:edonr >>>> /usr/share/zfs/compatibility.d/openzfsonosx-1.9.4:edonr >>>> /usr/share/zfs/compatibility.d/ubuntu-18.04:edonr >>>> /usr/share/zfs/compatibility.d/ubuntu-20.04:edonr >>>> /usr/share/zfs/compatibility.d/zol-0.7:edonr >>>> /usr/share/zfs/compatibility.d/zol-0.8:edonr >>>>=20 >>>> I happened to do this activity in a aarch64 context, in >>>> case that matters. >>>=20 >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Dec 15 03:10:18 2021 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 0048418F4CFF; Wed, 15 Dec 2021 03:10:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDKxZ6Bk3z4hMy; Wed, 15 Dec 2021 03:10:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qt1-x82d.google.com with SMTP id o17so20511073qtk.1; Tue, 14 Dec 2021 19:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=53GxFRmVi32R2rqyJTmTPm+ja/p1teL1phSAW9IlCV4=; b=oSlfkEGv346hCR4aWbu9U5IzqcwpRhKfD8telcxBbHBL1dQBpyiB7mRtlNm1PSd1Nx EjJKV98bFdCtnvQqH7sduGB0qnTraiZGayFthgp2UC7BZxns15g9SE94Ez0H/KX7ZSGq nyTlnxUQVydd/3YEB36LvSdASDYKGzMichG8uanNquFZuPM95ctAKPJujknbHwpyWtAg WuLTSDuA2ggQrYQFoKDhXZTmOiSgv66TeDDBK/XvfAyvJSVEvXe87CsPqkLs5m5DOXTd jIaQQJu+eoyshN7A0k7GE6PONDpkH0XIMbgIGUHCNKzirr9xHpdDvZqOTArrb3tO8CM1 0v3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=53GxFRmVi32R2rqyJTmTPm+ja/p1teL1phSAW9IlCV4=; b=BWCtdGxjiUemlpmmDUIeqJM1yTfXA99j39jWEjyztM/sTLfr9UvDE2jpZM0C+YtboW Dmtnl2LG+Qm7aflnPK86mL6EhJhILSoD4CR5XwjVTsuJVyrLLFeMJ/mZYqfCI18Ldcnd i5Vn4emj7bawRKfyv5OPWXW89pc0cpxYm0uB7N8uDkKNbQnLGs/Uu/aEsmiHWURxlwfd lk2w4auDYNIhqODjjE2V7Ff7QnRFzyITwMpFiDsvlEUvBGMjf2lTtZ2vQ1/HezIe2tZr g78tq4ucXZdRFjxvz/pdcS+C1B/7TiWI8VEBrsp1Re8oB6c8FfHMc982VKOZ1pE6ps/d hF5w== X-Gm-Message-State: AOAM533VObFIdyIdVnYyStkUiJVfaUagQWw74+JNOs2yAI9WaT+MJ12i apQAeCfSFPjgRT68eBeussjZaQ533/s= X-Google-Smtp-Source: ABdhPJyf1pnHvBpFbxlgiO9v9+9A23P3JG/dsthk/zuL5azkdoIhits4zHjAIon7Wc5wzQ/y+pJL+A== X-Received: by 2002:ac8:7d11:: with SMTP id g17mr10220712qtb.460.1639537819794; Tue, 14 Dec 2021 19:10:19 -0800 (PST) Received: from spectre.mavhome.dp.ua (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id e17sm563634qtw.18.2021.12.14.19.10.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Dec 2021 19:10:19 -0800 (PST) Subject: Re: /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd vs. openzfs-2.1-linux vs. FreeBSD main [so: 14]: edonr status To: Mark Millard Cc: freebsd-current , FreeBSD-STABLE Mailing List References: <928FE23E-C9DB-4473-B8C2-DB3A32529AF4.ref@yahoo.com> <928FE23E-C9DB-4473-B8C2-DB3A32529AF4@yahoo.com> <0C484963-D833-4B12-A9C8-8FADC0EF1D9B@yahoo.com> From: Alexander Motin Message-ID: Date: Tue, 14 Dec 2021 22:10:18 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.13.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 In-Reply-To: <0C484963-D833-4B12-A9C8-8FADC0EF1D9B@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JDKxZ6Bk3z4hMy X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 14.12.2021 22:00, Mark Millard wrote: > On 2021-Dec-14, at 17:35, Alexander Motin wrote: > >> On 14.12.2021 20:21, Mark Millard wrote: >>> I presume that because of FreeBSD's releng/13.0 and stable/13 (and >>> releng/13.? futures) that: >>> >>> /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd >>> >>> will never have edonr added to the file. Sound right? >> >> FreeBSD stable/13 is tracking still alive upstream zfs-2.1-release >> branch. It is still updated periodically, but primarily with bug fixes. > > I infer from the above that: > > /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd > > is unlikely to be changed to be inaccurate relative to releng/13.0 , at > least as long as 13.0 is a supported FreeBSD release, but probably for > all the releng/13.? . Yes, that would be my personal assumption. >>> Is there going to be a /usr/share/zfs/compatibility.d/openzfs-2.*-freebsd* >>> that has edonr as well (instead of using a openzfs-2.1-linux file for >>> such)? If yes, when does the file show up? Does main get drafts of the >>> file over time until there is a releng/14.0 that would have the final >>> version? >> >> FreeBSD main though tracks openzfs master branch, and as a moving target >> it has no compatibility definitions. I'd expect by the time of FreeBSD >> stable/14 branching there to be some new openzfs branch it could switch >> to, but so far AFAIK there were no specific announcements yet. And >> enabled edonr is a step toward not differentiating FreeBSD and Linux >> compatibility settings any more. > > I infer from the above that it will be much closer to releng/14.0 's > time frame before there will be an additional: > > /usr/share/zfs/compatibility.d/openzfs-*-freebsd* > > ( or a name that does not even mention freebsd or linux but > applies to releng/14.0 ). Good to know. Right. There would be nothing bad to have more openzfs releases before stable/14 branching though, just not after. We'll need to coordinate that with upstream. -- Alexander Motin From nobody Wed Dec 15 06:52:27 2021 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 8367018D4A1B for ; Wed, 15 Dec 2021 06:52:46 +0000 (UTC) (envelope-from potthua@gmail.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDQt53dWlz3n3M for ; Wed, 15 Dec 2021 06:52:45 +0000 (UTC) (envelope-from potthua@gmail.com) Received: by mail-ua1-x92e.google.com with SMTP id 30so39182449uag.13 for ; Tue, 14 Dec 2021 22:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=nsPTYfer/tz7KCzDyvGrwf1s5lWTHS3lS5v+4OPIr+k=; b=AmwudCkWZMjsWS0I5Algb4SrViDmj7dG6dRlPZyY8W3iVabIkTJnFhhkbLyOKhoBkf lOgn8Tegyfxgr2yCHF/2F/vxHP6zDkzhDGxu0QeFU8Fzw3gF4W3CeqVzyG43qQh3xzk+ IVZZogeiKhMBp4XekTw4lhFE7fZkX1rSbphMPJR6bStoSnV3oEvHEQrhbA98cTbO72VF k3mifY/LZxxsGZeUp+TtrOYTUBo5zVQP7OPVfm1bdWpvjDEMsUkYZHhtrdjDMjitrW8F VsqEk0MQcdLk8hDWS6AyhxAjzWS6APmhR+H1JnPqT140bZ1zF7K+uDnMDyZOMXz5ixzg 26Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nsPTYfer/tz7KCzDyvGrwf1s5lWTHS3lS5v+4OPIr+k=; b=L9m1U2W4IM7I4Y5Wv5fE3sFdWNeBqQgg8N/pRgqM3Q7PFWfCj2Qfh55X76pjdASCYk 8Xgek5JscZYANtXmyoDepnPWEf68PS9lU8XtKb7NkiR4/B2jh8eGcGUWcTezElksYXb/ lzM2go7ZFxeagMhMmhd2y5ZJgp0IGfSrwdF6WY6rkvN1O/ysXgubM7qbIhhYnWt4eI4v VTScov6pOhBPj1IhN95W0UPneuKj3hY1WeeNbFrgSCIy+ts4KqV9z5iWXm8dhajBlaed QbAvc6XB9f6vcCvW/0GM1RbZsmxXJiH4+srPHPJx8e/0z/rVCXTUzTgvU44BOT73Mq0J jT6A== X-Gm-Message-State: AOAM5314u3MFurcq2ikp8yL8vrKASiGEWJD8WDEjLViKrBB/4briO1lZ c9RChIT5ySNf0DjRPjrWFnhAXKG/Ye8ezZJ6HUm14aIHzXE= X-Google-Smtp-Source: ABdhPJxa/AeKiKYo3wqttk9dfZCCpfOMpEl3X4kyWw5WmoEl9bioofVtITbNMWZlkyf8EifKDg4qf54Hd2DwZG4MsAM= X-Received: by 2002:a67:e90d:: with SMTP id c13mr2404740vso.12.1639551158630; Tue, 14 Dec 2021 22:52:38 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Piper H Date: Wed, 15 Dec 2021 14:52:27 +0800 Message-ID: Subject: question on socket server To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000066bd2205d329c031" X-Rspamd-Queue-Id: 4JDQt53dWlz3n3M X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=AmwudCkW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of potthua@gmail.com designates 2607:f8b0:4864:20::92e as permitted sender) smtp.mailfrom=potthua@gmail.com X-Spamd-Result: default: False [-0.00 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92e:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: Y --00000000000066bd2205d329c031 Content-Type: text/plain; charset="UTF-8" Hello I have little knowledge about socket programming. I have a question that, if I have made a socket server, listening on a port. The server prints data to the socket, but there is never a client connection to the port, and the data is never consumed. What will happen to the server then? will the OS kernel be flushed by junk bytes? Thanks for your help. Piper --00000000000066bd2205d329c031-- From nobody Wed Dec 15 10:51:42 2021 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 9AA7918E3D1A for ; Wed, 15 Dec 2021 10:51:50 +0000 (UTC) (envelope-from SRS0=wFgk=RA=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 4JDX9y3QPbz4lc8 for ; Wed, 15 Dec 2021 10:51:50 +0000 (UTC) (envelope-from SRS0=wFgk=RA=klop.ws=ronald-lists@realworks.nl) Date: Wed, 15 Dec 2021 11:51:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1639565503; 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=xhVGgXxMMUkPo4RX+1ih0K4bumUxVTIhdzhSrjNl5Gg=; b=tfdp7T7FJw+Q2ikqacGVH8YgSQnjkhT2Gr5levufxdbs9WMZUlu409CWG6CiXfXiNpI+2X yYCB2FRQXC/6QuBgtRgeQogA25E8iL+J4HrBQ2HEnE80m0zUUmG/YHrWZvsVk5ZzSWlRqf IVAUu1IkAAy8B41EvvEI1USVYmBr52+tblBl+Ia2MgQUbsdeTGSGjxwoSQ+FR8yzbP5dvz ngDpLEBsL0ATeal5VJyWuBFJeoV9qnBECPxaDnya0mJ6dfI4pTm9Q2yPOpnhxkbKW8baed 4ZpvRwxfnVAuhDgzWhOKsq/ry4Fr5Gku/mxV1Ji18jUENdTxSoNRu+HIHeO2BA== To: Piper H Cc: freebsd-current@freebsd.org Message-ID: <1412287950.345.1639565502579@localhost> In-Reply-To: References: Subject: Re: question on socket server 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_344_414513860.1639565502522" X-Mailer: Realworks (588.193.3eeb293) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4JDX9y3QPbz4lc8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: ronald-lists@klop.ws From: Ronald Klop via freebsd-current X-Original-From: Ronald Klop X-ThisMailContainsUnwantedMimeParts: Y ------=_Part_344_414513860.1639565502522 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Just try it! I think you will get an error that you are writing to a not-connected socket. >From "man 2 write": " [EPIPE] An attempt is made to write to a socket of type SOCK_STREAM that is not connected to a peer socket." See also "man 2 send" and "man 2 socket" for a lot more information. So it depends a bit on the type of socket you created. Regards and happy hacking, Ronald. Van: Piper H Datum: woensdag, 15 december 2021 07:52 Aan: freebsd-current@freebsd.org Onderwerp: question on socket server > > Hello > > I have little knowledge about socket programming. > I have a question that, if I have made a socket server, listening on a > port. The server prints data to the socket, but there is never a client > connection to the port, and the data is never consumed. What will happen to > the server then? will the OS kernel be flushed by junk bytes? > > Thanks for your help. > Piper > > > ------=_Part_344_414513860.1639565502522-- From nobody Wed Dec 15 10:55:17 2021 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 4999818E4BBB for ; Wed, 15 Dec 2021 10:55:29 +0000 (UTC) (envelope-from potthua@gmail.com) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDXG90GKjz4mw3 for ; Wed, 15 Dec 2021 10:55:29 +0000 (UTC) (envelope-from potthua@gmail.com) Received: by mail-ua1-x933.google.com with SMTP id w23so40187998uao.5 for ; Wed, 15 Dec 2021 02:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9IqojWJtIeYUwdYWRNnZQGtDPU79UqZ90K3IfSvaX78=; b=W+HO4Lb1QeZHUTPfzDCx6yKrEn0BH2rC7ftZKzibn53GhZwJpP4jov5BFst+9kAoOp v/Fc39k4/orfEovr7oWdtDOUYNFPQfifikZ6malkfm3ornp5mI+hsjJnK/h1fBWoQPKb jFfZeAhg2TViaH+tAT5MgXKvr5mEYgpifi2XEJVBp04+YEl3p1w6hOmYqrkp66cEL1k9 a+M1McMfYJLXuGxoF+WdHJ9x2Bn9oGGU0VpPslWFpOG6TCrCt0ynL8Z6xkLRCvSOmH8B 2I+p0JJqxgjuomqd22+QhBPsLg/b+E0b/MHnzgICuaCZb67CLgucd1cno3StNWazDwjY BnXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9IqojWJtIeYUwdYWRNnZQGtDPU79UqZ90K3IfSvaX78=; b=4wcHkYnheUP1s0VA6D36GkEW0SqrBAVFzPAqaU2qh4yJLoEjMa4HiECznuO7DpSM98 uvFhhre2KOr+MVe/jwaKEjczh0PK/U0PzcQ/9uSc60IyDSsy3UzjpuM8PeQ8Hs0/ZxXm VmPWNEFqEcsvVDtrV5awvSaNAnguPVdMvdnE6REW9SfZ3pTPbin4Sws/dZ0b0sxBBgNE nPIAz17MFJ3Wbf/gUsu7uLt6Qq/mQqp464YZDwnPIkcGTWYKGIN4CLRKscZ3WSv6V8be moX7ilq//h+41RDsJFC3o3VxyARgj0JPQLlS0YOOu9uh9JOSDYfrJNRDquadIxFafJw6 pUbQ== X-Gm-Message-State: AOAM530yzvMipz9Vpwg5WMi4PxCtw1MvbvGCTvJQ+5hk+QpEK4uhBiUB j0u54yfm7zsvEzCPochu5Lg26ZhXAK+K3cGXA1CKnfNqnbpidbtU X-Google-Smtp-Source: ABdhPJyE7XYmB8QheLRnq065XouOxxR7LZnyM5EHFsXAtcpJSw3T2tG4G58v6HCSN3+DGTItm7Kjp5g9cmP3QO8wGzI= X-Received: by 2002:ab0:4911:: with SMTP id z17mr8957720uac.91.1639565728448; Wed, 15 Dec 2021 02:55:28 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <1412287950.345.1639565502579@localhost> In-Reply-To: <1412287950.345.1639565502579@localhost> From: Piper H Date: Wed, 15 Dec 2021 18:55:17 +0800 Message-ID: Subject: Re: question on socket server To: Ronald Klop Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000d4878a05d32d2481" X-Rspamd-Queue-Id: 4JDXG90GKjz4mw3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000d4878a05d32d2481 Content-Type: text/plain; charset="UTF-8" But I write this program to listen on port 6666 who sends a random str to the socket every 0.25 second. And there is no client connecting to the port. The server just runs there without problem. :( So I am not sure enough... use strict; package MyPackage; use base qw(Net::Server); my @fruit=qw( ... ); sub process_request { my $self = shift; $| = 1; my $max = scalar @fruit; while (1) { my $id1 = int(rand($max)); my $str = $fruit[$id1]; print "$str\015\012"; select(undef, undef, undef, 0.25); } } MyPackage->run(port => 6666, ipv => '*'); On Wed, Dec 15, 2021 at 6:51 PM Ronald Klop wrote: > Hi, > > Just try it! > > I think you will get an error that you are writing to a not-connected > socket. > From "man 2 write": > " [EPIPE] An attempt is made to write to a socket of type > SOCK_STREAM that is not connected to a peer socket." > > See also "man 2 send" and "man 2 socket" for a lot more information. > > So it depends a bit on the type of socket you created. > > Regards and happy hacking, > Ronald. > > > > *Van:* Piper H > *Datum:* woensdag, 15 december 2021 07:52 > *Aan:* freebsd-current@freebsd.org > *Onderwerp:* question on socket server > > Hello > > I have little knowledge about socket programming. > I have a question that, if I have made a socket server, listening on a > port. The server prints data to the socket, but there is never a client > connection to the port, and the data is never consumed. What will happen to > the server then? will the OS kernel be flushed by junk bytes? > > Thanks for your help. > Piper > ------------------------------ > > --000000000000d4878a05d32d2481-- From nobody Wed Dec 15 11:47:27 2021 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 5960F18F22E2 for ; Wed, 15 Dec 2021 11:47:29 +0000 (UTC) (envelope-from SRS0=wFgk=RA=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 4JDYQ86y6Kz3GQD for ; Wed, 15 Dec 2021 11:47:28 +0000 (UTC) (envelope-from SRS0=wFgk=RA=klop.ws=ronald-lists@realworks.nl) Date: Wed, 15 Dec 2021 12:47:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1639568847; 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=OUDSrgfOLrf9Fu/8tyZGy21gblJrnR4MKPNdyQup0rU=; b=vg8tp/IFKvp4jdBHuVNP4mv+jCRVXkZtjJE12jFUFnhqG9IvbZi4JmM9b47ekDXiU1SISe HE0bSy4WQ6TG4oNHt5ITOvPtANqHsI6nqJiq30jlLzwOcqdy0KrDYO7oEbtSGO7uB5wz+b oIT5s5w7orSerOnfvbhv+HOM9t4f0fM3xDt11b7CJ2N4jwOcuYOZUa8hML31LqeXFnMIZu +1npW5X1RdUDb6PPlwkpf5XC7alBBeqLryB/NDEHuIfLBAajmPdy7qEFVZtfw0NT4pdR07 Xd1wdbp6sWgrWzaFGxD0vLlspXvXYGbyZGxWenRt9I6JG71RLHf0z/blZm049w== To: Piper H Cc: freebsd-current@freebsd.org Message-ID: <1432797344.570.1639568847473@localhost> In-Reply-To: References: <1412287950.345.1639565502579@localhost> Subject: Re: question on socket server 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_569_1908596974.1639568847444" X-Mailer: Realworks (588.193.3eeb293) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4JDYQ86y6Kz3GQD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: ronald-lists@klop.ws From: Ronald Klop via freebsd-current X-Original-From: Ronald Klop X-ThisMailContainsUnwantedMimeParts: Y ------=_Part_569_1908596974.1639568847444 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Your program first waits for the first client to connect. So nothing is written anywhere. You can check by running "nc -v localhost 6666" in another terminal. After the first client disconnects it keeps looping in the while and the print will return 0 which means failure. Something like this will improve things. if (0 == print "test\015\012") { return; } Regards and happy hacking, Ronald. PS: I think this does not have to do a lot with freebsd-current. Might move it to https://lists.freebsd.org/subscription/freebsd-perl or some generic perl forum/ML. Van: Piper H Datum: woensdag, 15 december 2021 11:55 Aan: Ronald Klop CC: freebsd-current@freebsd.org Onderwerp: Re: question on socket server > > But I write this program to listen on port 6666 who sends a random str to the socket every 0.25 second. And there is no client connecting to the port. The server just runs there without problem. :( So I am not sure enough... > > use strict; > > package MyPackage; > use base qw(Net::Server); > > > my @fruit=qw( > ... > ); > > > sub process_request { > my $self = shift; > $| = 1; > my $max = scalar @fruit; > > while (1) { > my $id1 = int(rand($max)); > my $str = $fruit[$id1]; > > print "$str\015\012"; > select(undef, undef, undef, 0.25); > } > } > > MyPackage->run(port => 6666, ipv => '*'); > > On Wed, Dec 15, 2021 at 6:51 PM Ronald Klop wrote: >> >> Hi, >> >> Just try it! >> >> I think you will get an error that you are writing to a not-connected socket. >> From "man 2 write": >> " [EPIPE] An attempt is made to write to a socket of type SOCK_STREAM that is not connected to a peer socket." >> >> See also "man 2 send" and "man 2 socket" for a lot more information. >> >> So it depends a bit on the type of socket you created. >> >> Regards and happy hacking, >> Ronald. >> >> >> Van: Piper H >> Datum: woensdag, 15 december 2021 07:52 >> Aan: freebsd-current@freebsd.org >> Onderwerp: question on socket server >>> >>> Hello >>> >>> I have little knowledge about socket programming. >>> I have a question that, if I have made a socket server, listening on a >>> port. The server prints data to the socket, but there is never a client >>> connection to the port, and the data is never consumed. What will happen to >>> the server then? will the OS kernel be flushed by junk bytes? >>> >>> Thanks for your help. >>> Piper >>> >>> >>> >> > ------=_Part_569_1908596974.1639568847444-- From nobody Wed Dec 15 12:13:46 2021 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 ECF4D18F700C for ; Wed, 15 Dec 2021 12:13:58 +0000 (UTC) (envelope-from potthua@gmail.com) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDZ0k633qz3L8H for ; Wed, 15 Dec 2021 12:13:58 +0000 (UTC) (envelope-from potthua@gmail.com) Received: by mail-ua1-x933.google.com with SMTP id o1so40554338uap.4 for ; Wed, 15 Dec 2021 04:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fOcV4HFq/MGeo8wLmASVHYK8748+uFw67hEi7cFjI/g=; b=CmJgRNRHvZGVLfnuLXykvRzsEBGqUjqZ62ycEiHiCVVzWZTzheSdWx1xCaU4hMYYtA fmAhekL+GAQddpe+S1kHAz2qKnQ7RXFAbh6Ol93WjgFbKvBx8nrWvPZHwkXqf7xUit0O zTwKNAT6cW8Iod2Q0cIekYo80PHLcuO7tflpHPfMCQqYaoafrUly0RfP4zMm0gZfuqPW UHZGq8PPEA1Xn21XbJ58hl/bsjWX2aFNOG5niKIHvWCr9yc5x4TsBFztUg/bSm95S06e lNvTPArgdbJwtspCwh+mQntPTw2q7DNYGwmaWSdFa3qDfy2qvzPsB6AGaS3EniX9upst vk4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fOcV4HFq/MGeo8wLmASVHYK8748+uFw67hEi7cFjI/g=; b=KvAXSskQwTN2ZD1cWeicohqzSWwYe5FjI9djB1esacBdNqap36/SARjVLD3RCciM1W T5nqWoZOdwjbuEY33VkopVRuB/UQcUB4++M0oVI/b5eHFPI531Vowhwh1xMSjIUChQ5x OtEyVam12XPMdAeFCp+RnvKFBjHvDeieVnxB7S8N6tMTTcXT0XuaPbNqGoTly8Frmaw9 nUuCJ+EpD5YP34wOALMvhpfZ8ymyfZFD8W0WCnf4rSqLLs3OOjDdfg/of6A+H6QXXO6n 22f8GdLDWlwjCCPak3q331GFmIxZcu7wl8sPp18xZArsSRmyLmkcDuR9jkaPBdW68q41 yYyQ== X-Gm-Message-State: AOAM532Cwh5sfAUxDqUfPoVTVDItUcPizOH4dNx2SRWHIT4Rc6r+hja7 LHFIhjgliG5kBlqqoxljezkptllCauVs1WftOSfDWqEUSfisnkWt X-Google-Smtp-Source: ABdhPJyx74hM+hXkvVqtaNBRKbbAfa+C6K5eyxj71TE11GDBHg/S4LKrivW63ulF8WwMIkbXH0whlFDZ44dVaHNVjkY= X-Received: by 2002:ab0:55ce:: with SMTP id w14mr9113932uaa.93.1639570438382; Wed, 15 Dec 2021 04:13:58 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <1412287950.345.1639565502579@localhost> <1432797344.570.1639568847473@localhost> In-Reply-To: <1432797344.570.1639568847473@localhost> From: Piper H Date: Wed, 15 Dec 2021 20:13:46 +0800 Message-ID: Subject: Re: question on socket server To: Ronald Klop Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000090670e05d32e3d7b" X-Rspamd-Queue-Id: 4JDZ0k633qz3L8H X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000090670e05d32e3d7b Content-Type: text/plain; charset="UTF-8" Thanks @Ronald Klop I changed it to this and it does work: print "$str\015\012" or return; Regards On Wed, Dec 15, 2021 at 7:47 PM Ronald Klop wrote: > Hi, > > Your program first waits for the first client to connect. So nothing is > written anywhere. > You can check by running "nc -v localhost 6666" in another terminal. > After the first client disconnects it keeps looping in the while and the > print will return 0 which means failure. > > Something like this will improve things. > > if (0 == print "test\015\012") { > return; > } > > > Regards and happy hacking, > Ronald. > > PS: I think this does not have to do a lot with freebsd-current. Might > move it to https://lists.freebsd.org/subscription/freebsd-perl or some > generic perl forum/ML. > > > > *Van:* Piper H > *Datum:* woensdag, 15 december 2021 11:55 > *Aan:* Ronald Klop > *CC:* freebsd-current@freebsd.org > *Onderwerp:* Re: question on socket server > > But I write this program to listen on port 6666 who sends a random str to > the socket every 0.25 second. And there is no client connecting to the > port. The server just runs there without problem. :( So I am not sure > enough... > > use strict; > > package MyPackage; > use base qw(Net::Server); > > > my @fruit=qw( > ... > ); > > > sub process_request { > my $self = shift; > $| = 1; > my $max = scalar @fruit; > > while (1) { > my $id1 = int(rand($max)); > my $str = $fruit[$id1]; > > print "$str\015\012"; > select(undef, undef, undef, 0.25); > } > } > > MyPackage->run(port => 6666, ipv => '*'); > > On Wed, Dec 15, 2021 at 6:51 PM Ronald Klop wrote: > >> Hi, >> >> Just try it! >> >> I think you will get an error that you are writing to a not-connected >> socket. >> From "man 2 write": >> " [EPIPE] An attempt is made to write to a socket of type >> SOCK_STREAM that is not connected to a peer socket." >> >> See also "man 2 send" and "man 2 socket" for a lot more information. >> >> So it depends a bit on the type of socket you created. >> >> Regards and happy hacking, >> Ronald. >> >> >> >> *Van:* Piper H >> *Datum:* woensdag, 15 december 2021 07:52 >> *Aan:* freebsd-current@freebsd.org >> *Onderwerp:* question on socket server >> >> Hello >> >> I have little knowledge about socket programming. >> I have a question that, if I have made a socket server, listening on a >> port. The server prints data to the socket, but there is never a client >> connection to the port, and the data is never consumed. What will happen >> to >> the server then? will the OS kernel be flushed by junk bytes? >> >> Thanks for your help. >> Piper >> ------------------------------ >> >> --00000000000090670e05d32e3d7b-- From nobody Wed Dec 15 15:25:38 2021 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 B2A1018F3875 for ; Wed, 15 Dec 2021 15:25:50 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDfG50LjYz4TSb for ; Wed, 15 Dec 2021 15:25:48 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639581941; 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=ECleocihTPDk9aAtYFUKaIQESj2LsoSur2YW4bd6ITw=; b=ia9UNVKgfURYI/OdvnwSKgxYmp8G5jF/79Gl9etxc6F2PCO0uMl1mpz/hAmPjtnnV+aGjz ir4jpa4/NYHAmm8IwYpILLK+SlyfM+mEv7g5EqQcsUl5L5l4Z4AmZtoPoQWKfODBfJwX/y tGK6lTqOWCCzSAdl5NKZvSMUaD6cb58= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id b000d682 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Wed, 15 Dec 2021 15:25:41 +0000 (UTC) Date: Wed, 15 Dec 2021 16:25:38 +0100 From: Emmanuel Vadot To: freebsd-current@freebsd.org Subject: Any Cronyx Tau* (ce(4) or cp(4)) users ? Message-Id: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JDfG50LjYz4TSb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=ia9UNVKg; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; DKIM_TRACE(0.00)[bidouilliste.com:+]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello all, I've noticed this /sbin/sconfig binary and after looking it's for configuring Cronyx E1 PCI (PCI as in PCI, not PCIe). The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't supported. We currently only build the drivers for i386 (and they contain native compiled code). Anyway, I'd like to remove this from the tree, I really doubt that anyone uses this cards nowadays (or even E1) but just in case I send this mail. Links to the review for the removal : https://reviews.freebsd.org/D33465 https://reviews.freebsd.org/D33466 https://reviews.freebsd.org/D33467 https://reviews.freebsd.org/D33468 https://reviews.freebsd.org/D33469 Cheers, [1]: http://www.cronyx.ru/hardware/tau32.html [2]: http://www.cronyx.ru/hardware/taupci.html -- Emmanuel Vadot From nobody Wed Dec 15 15:42:36 2021 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 D696318F6A66 for ; Wed, 15 Dec 2021 15:42:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDfds5bSyz4Wwp for ; Wed, 15 Dec 2021 15:42:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f174.google.com with SMTP id x15so8235723ilc.5 for ; Wed, 15 Dec 2021 07:42:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vHqPUZTRZxtgjM0MsA4AP9QR9zjmx8UQVG8st7WxbXw=; b=wkW7KlJVItpCSJRVVJfqOrI5qiTTAlUnizNxTmkSGUeOy56OrgnNvyIjoXjDqLzn5t Gg2eYgsKC68hd4jSFSTc7U081Jv2yqzb2/MPYc/b1NOfHd3yfUJR3HpfZi2Vwey1meDK 1tmJfqxKEKZAio812ZuvyQbtehGtDOJ9ku/zM1wZZM2bMCQitL3HpgU2EAHMkf2juPAA tYnlmuMkIW6i8c1h3MEZWoMaJ9uX7zanvmzsNegD5N0vjH97dHpyxLtQA1l/kojrj8Pv BqbKT28jMQCaA64N//eFe+74UDHAj9gcNI4L+yFMjwP5XoUBLMvldcCbFbytteCpz60/ kN8w== X-Gm-Message-State: AOAM5328eTiLCXdoMqq47GGdWh1IWQ8MeQD9qPHkB9GKTScJR6x5M28e yPVRwVN4bD/FPH5BVd2Q3i6EFiMQbZcKuD7w5Szw26AefR8= X-Google-Smtp-Source: ABdhPJwAWId1dYfrNJsWEHIxs4f8iwESXKe4LEBk2EQTH1aCUM1oYhbtaD0vGR/FqcC7SyQl8TOfJ3AIc7NjNIhbaAI= X-Received: by 2002:a05:6e02:1988:: with SMTP id g8mr6658896ilf.260.1639582970987; Wed, 15 Dec 2021 07:42:50 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> In-Reply-To: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> From: Ed Maste Date: Wed, 15 Dec 2021 10:42:36 -0500 Message-ID: Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? To: Emmanuel Vadot Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JDfds5bSyz4Wwp X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 15 Dec 2021 at 10:27, Emmanuel Vadot wrote: > > > Hello all, > > I've noticed this /sbin/sconfig binary and after looking it's for > configuring Cronyx E1 PCI (PCI as in PCI, not PCIe). > The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't > supported. > We currently only build the drivers for i386 (and they contain native > compiled code). > > Anyway, I'd like to remove this from the tree, I really doubt that > anyone uses this cards nowadays (or even E1) but just in case I send > this mail. I posted a similar query to -stable in 2020, at https://lists.freebsd.org/pipermail/freebsd-stable/2020-February/092037.html and did not get any response. I have D23928 for a deprecation notice for ce and cp. Gleb commented there that he'd offer to maintain them (and as part of that, removed sppp in 6aae3517ed25). From nobody Wed Dec 15 16:32:49 2021 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 60E8818DA76A for ; Wed, 15 Dec 2021 16:33:03 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDglf6c5jz4gqs for ; Wed, 15 Dec 2021 16:33:02 +0000 (UTC) (envelope-from 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 1BFGWnnE073244 for ; Wed, 15 Dec 2021 08:32:55 -0800 (PST) (envelope-from bsd-lists@bsdforge.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 Date: Wed, 15 Dec 2021 08:32:49 -0800 From: Chris To: freebsd-current@freebsd.org Subject: Re: question on socket server In-Reply-To: References: <1412287950.345.1639565502579@localhost> User-Agent: UDNSMS/17.0 Message-ID: <21aa241b4b1af03e188cc1654393641d@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JDglf6c5jz4gqs X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N On 2021-12-15 02:55, Piper H wrote: > But I write this program to listen on port 6666 who sends a random str to > the socket every 0.25 second. And there is no client connecting to the > port. The server just runs there without problem. :( So I am not sure > enough... > > use strict; > > package MyPackage; > use base qw(Net::Server); > > > my @fruit=qw( > ... > ); > > > sub process_request { > my $self = shift; > $| = 1; > my $max = scalar @fruit; > > while (1) { > my $id1 = int(rand($max)); > my $str = $fruit[$id1]; > > print "$str\015\012"; > select(undef, undef, undef, 0.25); > } > } > I think it might be easier for you if you have a look at the MILTER interface to Sendmail. There are a myriad milters written for sendmail. The entire milter system is (unix) socket driven. So the examples should prove enlightening? :-) HTH -- Chris > MyPackage->run(port => 6666, ipv => '*'); > > On Wed, Dec 15, 2021 at 6:51 PM Ronald Klop wrote: > >> Hi, >> >> Just try it! >> >> I think you will get an error that you are writing to a not-connected >> socket. >> From "man 2 write": >> " [EPIPE] An attempt is made to write to a socket of type >> SOCK_STREAM that is not connected to a peer socket." >> >> See also "man 2 send" and "man 2 socket" for a lot more information. >> >> So it depends a bit on the type of socket you created. >> >> Regards and happy hacking, >> Ronald. >> >> >> >> *Van:* Piper H >> *Datum:* woensdag, 15 december 2021 07:52 >> *Aan:* freebsd-current@freebsd.org >> *Onderwerp:* question on socket server >> >> Hello >> >> I have little knowledge about socket programming. >> I have a question that, if I have made a socket server, listening on a >> port. The server prints data to the socket, but there is never a client >> connection to the port, and the data is never consumed. What will happen to >> the server then? will the OS kernel be flushed by junk bytes? >> >> Thanks for your help. >> Piper >> ------------------------------ >> >> From nobody Wed Dec 15 16:52:02 2021 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 1562518DF837 for ; Wed, 15 Dec 2021 16:52:05 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDh9c4X3Pz4lGb; Wed, 15 Dec 2021 16:52:04 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639587123; 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=Eyy4uavbvx5xtTIEWHGZC3ytiYj4VDvcEKi8qXJuBps=; b=KNs2r6bmdlNR62xPkICaJeCiPc+nVSxRN6EUloJRpXeNPARgjHzqqie7VApXd05dZeCgGz h/aSjSU0zG1dQpQa4iJAcpEy7BEfuUnIvxrBd2VfIogGwYR8Kz1X1RnHNneX/UhYNUUAes 7qn3t5xlqIvBs3KQGdUWprZ9iiUv25Q= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id a18a351f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 15 Dec 2021 16:52:03 +0000 (UTC) Date: Wed, 15 Dec 2021 17:52:02 +0100 From: Emmanuel Vadot To: Ed Maste Cc: FreeBSD Current Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? Message-Id: <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> In-Reply-To: References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JDh9c4X3Pz4lGb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 15 Dec 2021 10:42:36 -0500 Ed Maste wrote: > On Wed, 15 Dec 2021 at 10:27, Emmanuel Vadot wrote: > > > > > > Hello all, > > > > I've noticed this /sbin/sconfig binary and after looking it's for > > configuring Cronyx E1 PCI (PCI as in PCI, not PCIe). > > The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't > > supported. > > We currently only build the drivers for i386 (and they contain native > > compiled code). > > > > Anyway, I'd like to remove this from the tree, I really doubt that > > anyone uses this cards nowadays (or even E1) but just in case I send > > this mail. > > I posted a similar query to -stable in 2020, at > https://lists.freebsd.org/pipermail/freebsd-stable/2020-February/092037.html > and did not get any response. > > I have D23928 for a deprecation notice for ce and cp. Gleb commented > there that he'd offer to maintain them (and as part of that, removed > sppp in 6aae3517ed25). > I'm not sure I understand the logic here. We're keeping drivers for museum grade hardware that no developer have access to and likely no one uses nowadays just for an hypothetical situation where someone will try to use those cards on FreeBSD 14 i386 in 2021 ? And we're doing that just because the drivers compiles ? -- Emmanuel Vadot From nobody Wed Dec 15 16:55:08 2021 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 C5C2418E1515 for ; Wed, 15 Dec 2021 16:55:10 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDhFB02LCz4mfP for ; Wed, 15 Dec 2021 16:55:09 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639587308; 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=6iZPrNq8nqmHivHevzePcy+Jhy1ZCEG91CpnKZoPddY=; b=L3VuEmBY3J79qC1D8WVIyaySY5YlGoimGVyWhXKqsX+97+Diik5zjPzRDe7zEnm0wPibUv BHGvT7bxcnGxxnmOK3faT7mIZCSPnFqMZhXJRdfgpy6v63EeZS60b4pNy19eU4LFVQTJCf FT+XpNrGu4+bKpXp1uIsYCMoZujL9r0= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 7a115025 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Wed, 15 Dec 2021 16:55:08 +0000 (UTC) Date: Wed, 15 Dec 2021 17:55:08 +0100 From: Emmanuel Vadot To: freebsd-current@freebsd.org Subject: Deprecate and remove publickey(5) stuff Message-Id: <20211215175508.d775a7254546c5be13dcd5a3@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JDhFB02LCz4mfP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=L3VuEmBY; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; DKIM_TRACE(0.00)[bidouilliste.com:+]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, it's me again, I've posted some review some time ago but didn't follow up with some mail so users might see it. I'd like to remove publickey(5) related programs, those are the only DES users iirc and likely unused. https://reviews.freebsd.org/D30682 https://reviews.freebsd.org/D30683 I'll commit this in two weeks unless there is some valid argument to keep this. Cheers, -- Emmanuel Vadot From nobody Wed Dec 15 17:12:25 2021 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 5E01818E4FF5 for ; Wed, 15 Dec 2021 17:12:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDhdJ1zZTz4q4F for ; Wed, 15 Dec 2021 17:12:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-lf1-x12b.google.com with SMTP id bt1so1799035lfb.13 for ; Wed, 15 Dec 2021 09:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8DbaeiKHtUzyE7DzG6zR6tY9jiFV6Q36L3/KFWhNyUU=; b=KhvdpHUuPXbriKP0npmIJYxh4wPHiUU8tM9KQpnDm2WrRJbPRas431EJofIB3XjQ0t JMcIHql+KTYzbKW9OGAU22DbheyOj7IUbzasrmlXEktk86dR/hXeMTPGqB9VkWuKWrPq 1SqTJER84+67ogSeswYlGY1dZPcLLSwpc9891OWrU3LVkWvoZR9LgQQgryxlgK1+ziDV Nm7rb47lCg+FdM5a8wpMqxZOz3yGpeB4UdcjqlYhhOi5GFhC9oKHlpVubxSF1BtjIKti 4fr5Rc3FLcninZBFdSvndcfdPCAMxMjIE84tewc/TwwavPSKe8NLAZFxMATJeL7eC+ic eg5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8DbaeiKHtUzyE7DzG6zR6tY9jiFV6Q36L3/KFWhNyUU=; b=1GEsqazVqNnBz5uwrjHbSOJTkevyVsnMxBcEkJ05dbVLn97MiwmhIrfCzdHABawJGo FL/rP1k+NlbpvhNW/yj+4taNRQmy7cYQ/Ce14/fJJHXOMYtSx64zBZamHzCIAz2JhL32 cusTovrbU8NVkrXBXxdEui3eMivikvbSxoWu3JLiB0PFGNz4CI5c5Jg56zy9JFyW1eej lYWekbbKtCoGsnp6Eb7tgHM5jGnS+94r7YkJsmKYMHuM7ouGhSJvnOBa438lxprgshZu cUzlDCaYFquRCgXkJC+2YWHV19Wu8uf7BZSvR1m6ztLtnD+/iKmhq8GbZd6p0ioztHhQ UV5Q== X-Gm-Message-State: AOAM532gRkiMUNHHG4wXL45kOJEGW1RmGwStL/r7uVaNlPtmDtAVqdjm OaygdEq2HHTdzD7Jwkv8LvG/l8ynffANXux/WxFiHA== X-Google-Smtp-Source: ABdhPJwbx/K4ogzHmSk3E2PBQSCmvpjK1fmupG7K7u5jjK5jXIgrrwtCNspn4kPcgiE/B0LPGia9mCKeGDzy6hjHGko= X-Received: by 2002:a05:6512:2154:: with SMTP id s20mr10858340lfr.136.1639588354738; Wed, 15 Dec 2021 09:12:34 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> In-Reply-To: <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> From: Warner Losh Date: Wed, 15 Dec 2021 10:12:25 -0700 Message-ID: Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? To: Emmanuel Vadot , Gleb Smirnoff Cc: Ed Maste , FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000076663705d3326941" X-Rspamd-Queue-Id: 4JDhdJ1zZTz4q4F X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000076663705d3326941 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 15, 2021 at 9:52 AM Emmanuel Vadot wrote: > On Wed, 15 Dec 2021 10:42:36 -0500 > Ed Maste wrote: > > > On Wed, 15 Dec 2021 at 10:27, Emmanuel Vadot > wrote: > > > > > > > > > Hello all, > > > > > > I've noticed this /sbin/sconfig binary and after looking it's for > > > configuring Cronyx E1 PCI (PCI as in PCI, not PCIe). > > > The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't > > > supported. > > > We currently only build the drivers for i386 (and they contain native > > > compiled code). > > > > > > Anyway, I'd like to remove this from the tree, I really doubt that > > > anyone uses this cards nowadays (or even E1) but just in case I send > > > this mail. > > > > I posted a similar query to -stable in 2020, at > > > https://lists.freebsd.org/pipermail/freebsd-stable/2020-February/092037.html > > and did not get any response. > > > > I have D23928 for a deprecation notice for ce and cp. Gleb commented > > there that he'd offer to maintain them (and as part of that, removed > > sppp in 6aae3517ed25). > > > > I'm not sure I understand the logic here. > We're keeping drivers for museum grade hardware that no developer have > access to and likely no one uses nowadays just for an hypothetical > situation where someone will try to use those cards on FreeBSD 14 i386 > in 2021 ? > And we're doing that just because the drivers compiles ? > I've cc'd Gleb to see if he can shine some light on this. Warner --00000000000076663705d3326941 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 15, 2021 at 9:52 AM Emman= uel Vadot <manu@bidouilliste.co= m> wrote:
On Wed, 15 Dec 2021 10:42:36 -0500
Ed Maste <emaste= @freebsd.org> wrote:

> On Wed, 15 Dec 2021 at 10:27, Emmanuel Vadot <manu@bidouilliste.com> wrote:<= br> > >
> >
> >=C2=A0 Hello all,
> >
> >=C2=A0 I've noticed this /sbin/sconfig binary and after lookin= g it's for
> > configuring Cronyx E1 PCI (PCI as in PCI, not PCIe).
> >=C2=A0 The products pages ([1], [2]) seems to say that FreeBSD >= ;=3D7 isn't
> > supported.
> >=C2=A0 We currently only build the drivers for i386 (and they cont= ain native
> > compiled code).
> >
> >=C2=A0 Anyway, I'd like to remove this from the tree, I really= doubt that
> > anyone uses this cards nowadays (or even E1) but just in case I s= end
> > this mail.
>
> I posted a similar query to -stable in 2020, at
> https://lists.freeb= sd.org/pipermail/freebsd-stable/2020-February/092037.html
> and did not get any response.
>
> I have D23928 for a deprecation notice for ce and cp. Gleb commented > there that he'd offer to maintain them (and as part of that, remov= ed
> sppp in 6aae3517ed25).
>

=C2=A0I'm not sure I understand the logic here.
=C2=A0We're keeping drivers for museum grade hardware that no developer= have
access to and likely no one uses nowadays just for an hypothetical
situation where someone will try to use those cards on FreeBSD 14 i386
in 2021 ?
=C2=A0And we're doing that just because the drivers compiles ?

I've cc'd Gleb to see if he can shine s= ome light on this.

Warner=C2=A0
--00000000000076663705d3326941-- From nobody Wed Dec 15 17:44:52 2021 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 C598218EC1E6 for ; Wed, 15 Dec 2021 17:45:06 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [85.220.129.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDjLn2vJRz3CM4 for ; Wed, 15 Dec 2021 17:45:05 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 24C061067557; Wed, 15 Dec 2021 18:44:57 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 1F74210A330B; Wed, 15 Dec 2021 18:44:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1639590295; 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=km/qMeuFSBII5G6ZvdbLlqyPFOFVm+XmZkZwyLZ4nzU=; b=RDpolSCVWSQ6EECvtdH1iVR8e8DIzGAegVeUrIUxntfPV8N7BSb/djPtHhM1dCA/xr78I/ rQDpC3kTQ2U2hmVHnotIgNT8UaHxrb0mnpMH4ra7YGIW5bRW3lkhgSAhRi7QAfVNu2erdU HuFnyUYtKo/HNDoYu7opBS1ajccbIgt7OkBiuyYYfPx/0PPjZOXEEG4OXpUkAlh2nFqdbQ uRjh9x7RJRX96aXyt1aaaXAQ5l5B8356AtzmT2jr59AYtIHdjfxw5uXkrQ8Y6jueHCcJ9W /ETQlzGn9fkxjZS0r6aJw4W3Bgt4VavsCMINe3sR1iOFszl/1ttQZDXreI6MBg== Received: from hermann (dynamic-2a01-0c22-a812-e800-10cb-84b6-cf83-eaeb.c22.pool.telefonica.de [IPv6:2a01:c22:a812:e800:10cb:84b6:cf83:eaeb]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 1371F10A3309; Wed, 15 Dec 2021 18:44:54 +0100 (CET) Date: Wed, 15 Dec 2021 18:44:52 +0100 From: FreeBSD User To: Daniel O'Connor via freebsd-current Cc: darius@dons.net.au, FreeBSD CURRENT Subject: Re: CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23) Message-ID: <20211215184452.3d6481cb@hermann> In-Reply-To: References: <20211125092054.4696b6f2@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: dd9b0c X-Rspamd-UID: 8a6507 X-Rspamd-Queue-Id: 4JDjLn2vJRz3CM4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=RDpolSCV; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.30) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.30:from] X-ThisMailContainsUnwantedMimeParts: N On Fri, 10 Dec 2021 19:41:07 +1030 Daniel O'Connor via freebsd-current wrote: > > On 25 Nov 2021, at 18:50, FreeBSD User wrote: > > > > Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: Mon Nov 22 > > 18:17:54 CET 2021 amd64) troubles me with our DNS server/service. > > Aproximately the same time we switched on CURRENT to the CURRENT LLVM13 version and > > also, after the compilation of a fresh OS with LLVM13, the upgrade from bind-9.16.22 > > to bind-9.16.23 took place as well as ASLR being the default. > > > > Since then named is crashing with a mysterious segmentation fault (see PR 259921, > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259921). > > > > Disabling ASLR as recommended to check whether ASLR triggers the SegFault did not > > solve the problem, so I suspect a miscompilation due to llvm13. > > > > On 13-STABLE bind-9.16.23 seem not to have this behaviour. > > > > I'm floating like a dead man in the water, can someone help? > > lang/sdcc also seg faults (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303), > although there disabling ASLR via proccontrol does fix it. > > Can you show a stacktrace for your seg fault? Hello. I have to prepare the boxes for debugging first, we switched everything off including core dumping. In the meanwhile, bind-9.16.24_1 has been issued in ports - the same problem occurs with that version, too, when compiled with llvm13. Kind regards, O. Hartmann > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > > From nobody Wed Dec 15 17:55:09 2021 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 76C8918EED0D for ; Wed, 15 Dec 2021 17:55:21 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDjZc2ySPz3Drs; Wed, 15 Dec 2021 17:55:20 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id E3A4610A330B; Wed, 15 Dec 2021 18:55:12 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id BAFBC10A3306; Wed, 15 Dec 2021 18:55:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1639590910; 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=vVXJS17lt1JxvufbXE3HFQwMAhT5tI2metcYQJBms1g=; b=EVqYArolJYI7sXkkpXdNkhs92FQkv+pY2/PmAVtbPvcMaMwEDKvZ4ZzlynalxOqnFlDQE8 q1047lM+SDGXuOKEb9TxOTjqkleWCPw8IskbsnxvSRmQZ3cOL4SOrW7eHIU5RtVmFAKggC FaUybZ3Lrtj95mi5Lq3UzIc2UI4+v+nbw7WphGVKg4nsI8zacdsbn8NINNUvGDI8OG1ilW h7PSbTWLq9gKiL2BbIMc6x/Oej3XbcMKcrVE8sJ38eBgdVakyJUmI30F3G+in/nXPamuQw aB3sDRuQTfPT4Ll0/eVV0leBeZ7KJqg0nO5fHSAWbho+iqZaGdzpvQM7YLa06Q== Received: from hermann (dynamic-2a01-0c22-a812-e800-10cb-84b6-cf83-eaeb.c22.pool.telefonica.de [IPv6:2a01:c22:a812:e800:10cb:84b6:cf83:eaeb]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 85F0110A330C; Wed, 15 Dec 2021 18:55:10 +0100 (CET) Date: Wed, 15 Dec 2021 18:55:09 +0100 From: FreeBSD User To: Andriy Gapon Cc: Alan Somers , FreeBSD CURRENT Subject: Re: CURRENT: ZFS freezes system beyond reboot Message-ID: <20211215185509.310fc873@hermann> In-Reply-To: References: <20211212102032.08af9689@jelly.fritz.box> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: a2fd9e X-Rspamd-UID: 613b50 X-Rspamd-Queue-Id: 4JDjZc2ySPz3Drs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=EVqYArol; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.86 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_HAM_SHORT(-0.96)[-0.964]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from] X-ThisMailContainsUnwantedMimeParts: N On Mon, 13 Dec 2021 09:30:50 +0200 Andriy Gapon wrote: > On 12/12/2021 18:45, Alan Somers wrote: > > You need to look at what's causing those errors. What kind of disks > > are you using, with what HBA? It's not surprising that any access to > > ZFS hangs; that's what it's designed to do when a pool is suspended. > > However, a pool does not have to be suspended on errors. > failmode property provides a couple of alternatives: > wait Blocks all I/O access until the device connectivity is > recovered and the errors are cleared. This is the > default behavior. > > continue Returns EIO to any new write I/O requests but allows > reads to any of the remaining healthy devices. Any > write requests that have yet to be committed to disk > would be blocked. > > panic Prints out a message to the console and generates a > system crash dump. > > But neither does any magic. > The errors will still be there. > Hello. The error's cause was not obvous. I used a SSD, partioned into two halfes, one for ZIL, the other for L2ARC. When showing "zpool status", the RAIDZ's HDDs (Hitachi/Seagate 4 TB NAS HDD) where "online", ZIL was "online" and L2ARC device/vdev showd - nothing. I had to power off/power on the box. For several hours nothing moved on, the box was frozen, any invocation of any ZFS volume related tool/command hanged the terminal/console. Several datasets showed errors at <0x0>, nothing serious. After deleting the ZIL and L2ARC extra SSD from the RAIDZ pool, verything went to normal again. It is spooky, if not to say "buggy", if ZFS is capable of freezing the whole box even if the essential operating system stuff is isolated on a dedicated UFS filesystem. Kind regards, O. Hartmann From nobody Wed Dec 15 18:11:16 2021 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 5E4DE18D281D for ; Wed, 15 Dec 2021 18:11:28 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDjxD0zksz3Hrx; Wed, 15 Dec 2021 18:11:28 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BFIBGsC004477 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 15 Dec 2021 10:11:17 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BFIBGkG004476; Wed, 15 Dec 2021 10:11:16 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Wed, 15 Dec 2021 10:11:16 -0800 From: Gleb Smirnoff To: Emmanuel Vadot Cc: Ed Maste , FreeBSD Current Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? Message-ID: References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.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: <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> X-Rspamd-Queue-Id: 4JDjxD0zksz3Hrx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Wed, Dec 15, 2021 at 05:52:02PM +0100, Emmanuel Vadot wrote: E> > > I've noticed this /sbin/sconfig binary and after looking it's for E> > > configuring Cronyx E1 PCI (PCI as in PCI, not PCIe). E> > > The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't E> > > supported. E> > > We currently only build the drivers for i386 (and they contain native E> > > compiled code). E> > > E> > > Anyway, I'd like to remove this from the tree, I really doubt that E> > > anyone uses this cards nowadays (or even E1) but just in case I send E> > > this mail. E> > E> > I posted a similar query to -stable in 2020, at E> > https://lists.freebsd.org/pipermail/freebsd-stable/2020-February/092037.html E> > and did not get any response. E> > E> > I have D23928 for a deprecation notice for ce and cp. Gleb commented E> > there that he'd offer to maintain them (and as part of that, removed E> > sppp in 6aae3517ed25). E> > E> E> I'm not sure I understand the logic here. E> We're keeping drivers for museum grade hardware that no developer have E> access to and likely no one uses nowadays just for an hypothetical E> situation where someone will try to use those cards on FreeBSD 14 i386 E> in 2021 ? E> And we're doing that just because the drivers compiles ? We are doing that because the hardware is still produced and can be purchased at http://cronyx.ru/price/#taupci And this is not a dead website, I gave a call to tech support last year. Who uses it? No idea. For some obscure reason they are still produced along with conventional PCI industrial mainboards (you can google that). I agree that actual intersection of FreeBSD users and Cronyx users could be zero today. But potentially it can be non-zero. I would appreciate if somebody chooses FreeBSD for their very strange industrial communications equipment. Some corrections on above statements. 1) We build cp(4) on amd64. We don't build ce(4) on amd64 for a reason that some functions are marked with __attribute__ fastcall. I'm 99% sure that attribute can be removed and ce(4) will build on amd64. sconfig(8) is build on amd64. 2) Drivers don't contain native precompiled code. They contain obfuscated code. Does sconfig create any problems for you? I'm fine with removing the drivers and the tool if they do really create a burden for us. That was case with their sppp(4) half, and I removed it in 6aae3517ed25. If there is no maintainance burden, why remove them? Just to save disk space? -- Gleb Smirnoff From nobody Wed Dec 15 19:29:40 2021 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 D5BBE18E61C8 for ; Wed, 15 Dec 2021 19:29:58 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDlgp5TpSz3nWd for ; Wed, 15 Dec 2021 19:29:58 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f49.google.com with SMTP id z18so31833886iof.5 for ; Wed, 15 Dec 2021 11:29:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ttn9GxE+M5g7SunMpzZc8+rjuvoZid8wdfXn9ox9xXo=; b=uKPpr+hO/lzLDVsGlpvp12S++o0tek+zgRTbeBmkFS31z8TTP1fZ2VXnmaXaNIpaak l+MHTBZlJraZUWqHPxsIUARLoCAUMhAS9E4a2p2kACjVvTIrUp/i9bmsz3CcGgquv4d3 rvf94KrCWoSF2XThMX8SFFIjaNZqcRPj2wgScFhdhRQ7lL0VZ++jqZZVIYaHtp+j5dWg tMkYjF9ztH07i0Q15BOXQflGnP0gmzRm70XCXn4K+xzrKjlQZJJRclon5wpsLKLt3nlf SnGk5tT3kPhH00lQ2CWXEBwpGahvWFzwmnQn4oLdxjH5VU957NgEqY3FaBgVPUx3qptj u8hw== X-Gm-Message-State: AOAM530dufDJCzcpWXM5rJ4gulpdX9PGiz9WwrbVXfJAJwxECftSse1U Bg+bnEm8Go1s383fs2/lTXGUAiXaqyPnQcRt0D1sQEB5 X-Google-Smtp-Source: ABdhPJyDPbfGhYwyFXW9fejqMhtaM/bg6A8u8xOvaq0R6sr12CciJlUpbYqwo+R7IwSaAf/6UJuXldsd8//2263A6bI= X-Received: by 2002:a5e:9b0e:: with SMTP id j14mr7436806iok.127.1639596592036; Wed, 15 Dec 2021 11:29:52 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211215175508.d775a7254546c5be13dcd5a3@bidouilliste.com> In-Reply-To: <20211215175508.d775a7254546c5be13dcd5a3@bidouilliste.com> From: Ed Maste Date: Wed, 15 Dec 2021 14:29:40 -0500 Message-ID: Subject: Re: Deprecate and remove publickey(5) stuff To: Emmanuel Vadot Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JDlgp5TpSz3nWd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 15 Dec 2021 at 11:56, Emmanuel Vadot wrote: > > > Hello, it's me again, > > I've posted some review some time ago but didn't follow up with some > mail so users might see it. > I'd like to remove publickey(5) related programs, those are the only > DES users iirc and likely unused. > > https://reviews.freebsd.org/D30682 > https://reviews.freebsd.org/D30683 > > I'll commit this in two weeks unless there is some valid argument to > keep this. There is also DES support in lib/libc/rpc/ related to this functionality - I think we have to consider all of this together. From nobody Wed Dec 15 19:52:58 2021 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 7323618EAB3B for ; Wed, 15 Dec 2021 19:53:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-32.consmr.mail.ne1.yahoo.com (sonic301-32.consmr.mail.ne1.yahoo.com [66.163.184.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDmBY0Jqlz3rrw for ; Wed, 15 Dec 2021 19:53:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639597982; bh=TeVx59wa8Z64Tr5v46vZM5iDmmyGBfDep8fOLpv3Iqg=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=E7sBxZHGlUqwo50pdiV0TUeMNB/ePRplrsG7MiahVKfRSWWjurNiu9HIfJUknoVxN8s7/MNDJTF/a5+OfG4dwNZ/E2L920JzFZ/9wTNZyzvfdLmJWoI9wXLtJ7SrkXgiIaxaNzrqgb4cDwzZ7QI2Hy5yK1vsgpWjD0QakUGt8eJxTQ9il+CfYpt577FpJy9X+Kok7ncLGlO8g9NuCPAqXQRwgJwsR88U8gL/F5fiO4lNdJO7xfUVL1iaRrIIAro1rQhLKIajmGJZFB0m1pC7hBNrxCqa3K/ekyxsO+nXXAp1Q8VgsINIHDfhNTM0AwaWjVNyTupMD0SmpupShMHBJQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639597982; bh=ySZO8tXGFenwZ2cnbv/zRoUde1rz5WlizLA9a+0DiCX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kaILujM39xVHrFRsSSK2CGjb9oZiItMLrt+ugqV/AV8mJj2+sEZBSDK72rEAMTRPhP/da8CvHuj9OKcHqd8Q73YjXa7N/SC47yYFEtrd6nLv/b9oZq2lADaPm/A4i+MjIfQ3ZKRjJXforSptqE/YghveduM8KvuSrIL4CYWM0y1x6bxhCM3t/S9Q71dG+8bvnPnR6ZarM0YAKuAhShP+tXtoyzGiYX56z5oPkjzw+LWPPKasUslEAScn2NgXOtt5bb104EnobVzF1Uw1dqkhS68YdaJvjG3lEhc4lm2l/1uFiRP56/h5P6XES/DRz1Xu2jdoWfyHw4uMTbL/YMf/yg== X-YMail-OSG: qFaKpAYVM1neKfiqwgdW7V9WNv85RTRoGubztBCzVrkltH.r6030LwBVu_2DZxI J7UK5k4Rf9u5aTsPoMFLy.6LYw4..AYzbVEJa36Qj8.3R4hucshOD16ndqeIdXD3BJGkfp6pe9ka K6j4Vsa44ALUOKe6ua3dhbgvicPnXfiHMv.yRvSIoBajnXOrfeUqIuPj5jT.DZgA.FuJ3rt3U7XB ROuSyx0sr096_YWMCvDKGVCBi7tKKGv6Bi_JJcJZsjFXEufGm1MSoy9_8pyNQYjS6AKzntTwUUD0 .3FiA8_rVX8.uirQqD2SWcP14JdNNfivko3abBibv0_YNMzLCkvfT8n5adnvMlbjeXK3fud1mHTf LJGeR9_PoiLEwXdL_H2V45QftA5D2G_B4690u82Cug5V_deKZCp13yh.Xh2SUy3VmE7BBkLTIIa8 nO90W4Jxo_aeRlFy4vd_eD1lDXln4gtT52hvW2HeAVN0jHWj5VF8yid73D4zlVOu34XATyWi5aTV cuQSnxRw6lYFuzwlbalW2OX9BTMjrvk_YS2m4.EOM45dnf0AdTEt.IwBgjzkCamqcv7Aj8haW6l7 LODaSiAqS0Srbo_4nY7Gnu6tUcH0l0ul3HN0g3x083VYL2HnSkGaeYLEO2m0Y4HsbEsPtFx.C_3U 79.AYg3qwSxoUl7eGKi.EUhpknjgCivkApI2aAM61IwdOMnjft5tx3fYFF21X6odu4MymphHmd1i dcXKnx0oRBtUuPFWSXioGj5X4C1pPohUpdpAjV4Q3m__S8kkuswT2NrDY0yDOwyijpNGkGCWdXtq .b.M2vM_.5gRHveHeLk0odtY7uuv1XrXZwlvWGswvJa8t5PDWlaxuo9P9lscE8CHGqOXuV7oMSbs JbV7iuVqKxxijIenFZl7ptwXH9omXElOUsy68EwyQx1pC.7FrguQpgEhsQiCq5w03xYU0dRLkEsN p_g8hdnhRM7efnFbDiqlGT6QfRlQ3W634nXPzMsi0HUNrFZXproqKy7zce0tnbN0LRMzuCBW6emA D2Z8otXv4IrY3DCa5b3ykjc4oIFeHQAPPVqssYTNANJQQePuuLDa9HwPelwCg8dh3PGr1bHD5byW DDm2mEEj3Jwi51w_qGkdhn5C4FpsKDgnyMziaqzOoZjG6MqUm8lu91V1tY06gwy9i7F_lcdu70Fz Jm9MRLDtH0jcUxlgtgtyyzOX5TnmM0Yw_1kxvBa38XoIPTwiFEMKimV3s8YmXWQMyCE5H_W2iehY b7l1_jfoYY_CvDPrdiFj6f6EdnQkHP.3Y6JHST.Cxu.tHn3HuubwfF4soHsywQyc0o23ab5BEGQC Yvg5Bd54iUGzkCdQMhhyGVBy9dsJrA_5aINt18WwOt.dikR6nY1iEsgzX8m0ebhw6iIc8qGUzrzE FfclGSrB7cHTDXKkog7geJXLVNkrdRuyTSO0m9YZi3Zl4Ej2.ZTnUR3RwufW.VkY8V1AMRoIpxJ7 xVpm9n2aCkODVV5O1gH6136KuMrdAaNZZ8kb704Z3DMym0iTjfnEVLjaeooXDC7qqbi1kKmke7MF PXQpmdPZwtyRCimM2H1I3K_h._CaHFy5m8QJ7JcNzbH84jzdEgQQ2CuR8d_NVXkURX.UChDpfxx_ SQ.v_B61fKw5CHHKze00BIIucbdTo7Lwre.Ar9QKYchR587Qicn4J8oTw4t3oJTB2LWW9ftLjArA trgJpl4fF4M1751m8WnuAY6rAeBFfGtD.XZfPvJWZIhbK_8Ru0hY4stv5zmN67wPmXxg2hk_RU8. _R5a.TmMJETjUVyL5KYVj8PYzE.uqk6fby3iQB8cQHYc4dpqisLzZWTKr6SCyH8_03xXYqc656La COjcQCoOB0zEnJQUwmGML5Gt5v99xkEG2K9JaqShXcUHXM6hKv3o1qrOb4crwU.HJwHKmeZRqQeX pkLiLgSxiMMZLVAG7QmbxMUdfvlXwNWE6ejTxBAY6k7H_EocDBy1E45aJDUwSv_Rtj5ciewl2JYb vkbwshQXxzpBZIn3AfJCv9TveaglrO3m9ywTEsdPrz47HLjG_yu0w4m97P6cjSGeL.UnVzJ5_9nw UtV6Q.Uox_HkWvKZXQUfuw_5FminBTJhBWX9P8jmXNnHsLJRpLgM8iqtg006AYatIgz.8h.uk7qW 8eFQAkpjRCJLj07TpxifnIhtOQEazQZrgEP41sELXRJkd7jK05Fwop66QMiu2dmPqud0KJHca4Rw 5zJRVVoyhnkDdfoQ_eFXMtRGHkTFkEmw46q0h3GA- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Wed, 15 Dec 2021 19:53:02 +0000 Received: by kubenode539.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ea266c8b99e073df45b333b70a3fbf00; Wed, 15 Dec 2021 19:52:59 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: CURRENT: ZFS freezes system beyond reboot Message-Id: <62F7A6A7-2AD3-4881-A1C2-8EFC2AB34133@yahoo.com> Date: Wed, 15 Dec 2021 11:52:58 -0800 To: freebsd@walstatt-de.de, freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <62F7A6A7-2AD3-4881-A1C2-8EFC2AB34133.ref@yahoo.com> X-Rspamd-Queue-Id: 4JDmBY0Jqlz3rrw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=E7sBxZHG; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 66.163.184.201 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[66.163.184.201:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.184.201:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N From: FreeBSD User wrote on Date: Wed, 15 Dec 2021 18:55:09 +0100 : > . . . >=20 > It is spooky, if not to say "buggy", if ZFS is capable of freezing the = whole box even if > the essential operating system stuff is isolated on a dedicated UFS = filesystem. I would guess that, for ZFS being in use, everything related to, for example, the ARC is "essential operating system stuff", given its tie to wired memory usage and the like that greatly changes the wired memory usage pattern/sizing compared to ZFS not being involved on the system (UFS only). (I only use ZFS in a simpler context, however.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 15 22:58:35 2021 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 2224118E962A for ; Wed, 15 Dec 2021 22:58:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDrJj6J51z4pwc for ; Wed, 15 Dec 2021 22:58:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639609117; bh=frgDgtIc/bwMsh3MpA7BcoTGme9fKU8HMH6Mpus22vk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=GqijW1c7Q6MXSPAn2qMU2JLO8I8rfq1VVXSW/cOoyvos4YBHPTF5Zs80N6dWt/dIb+igTZn/GcBQNsmNTnSQnlXDUVnwpW3T7QoohimwVLoJvwLi/Aop6Nsb+7/fTkqVazvyp9jUU5ZaysZKByoHHL2P3p3uun7faBdRuWKmbXgMZ/6sbOlit9yKMHqp9q4FsBNafgXB+4/Nj5yM3BQc1YqRl5C14Vb7qZXIai2fhHY9899SJ3BrKHGcA2sr9KymolnRhiP6ydaX2RJ4NfC4c28MzzUNkuc36yXA6q0e7fLevby88rFwoIluKcCKcuS96vgxSApR4riZDG6dHWAJFg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639609117; bh=ebPvHKFt3FfzsbM8NAcRTh80F7DmoK8AVGn5P4mcy7W=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=qI+qKhG2dVQWTi6UrlaT+xMNPTc3vzBPg3W6fb3BD64xc/MrMolpl2mW6tAuHQyhowmb5JXqwRkW+r5FLkUdPMtl6D61MqkphPkidcyeI0VYNeciLJJBsqI5sDQOMiOIKEVA73Pdu+1frWn9bgacJCkXlbemMqc2tXrFyo7q6c6rY+TJH8gkbtRuj81Ind1EPU2PYVtNqn2QTugO97Cc1I35FVa1jnQmB1P4axOloxogrk96fYPb7TGIPx/MXYhPQoKytZhgyfMGKHwYPVP+mATHseQVABub8btk3CAfiGa0zItKpbbnWnoCdAOyEX5bhFbacIUyPlJfwMu3iboCuA== X-YMail-OSG: ub.0UbIVM1lqpYXxxXW5RiKwpcCU9kAhIn6fWnZJuQYEIxR_X4eIIBtxxrP.r6S EYJ0ZDCC1Oe49ch75mb4q5o5h0sB3PEB8dgEFtuiNsOC93HinzKancG1SoETAwR.zTQ7CrtJm5PZ Xa4ZQ_HEWHykk7UHPlWQAjZHO3ii4dKQb6OIo9Fpiuw413rGC3GoJaiM9HmeXVhS94ggoOYjt_gk HMMcIUd9EJ4gLxk.YOryZvX8MN0xhxT5ixp92tuii2mcOfSZyBb.GbpLBhykPrstW1k37IZsOeGG tK4x7ghhmb.hQz5MbmUex33YILF39DbvwsESEiwp_ykEa1iHs0l1JJogdG9KF3R2TU.OwOQp22._ LJDFkuykXWTCjHu5RvpHWsX42gF41W0X.JShvPcRgMuGpt7TIofJo.tGg3yAY5gG0pp8PIJS4I9P PVcZSZw0RqxfSkAQY4RVZSFbqNyLrKjqPDLo8SCc3GPHOGluX1Mz7jdh9EvB_7vaUqk4Glprt6Aj FV.n1b2tPX7idscWuGEH3prKSCcN6MGaSWht23Q3_j_Fuaz7_Jfhkefdk85pnEmn77SW6OsRK3FX cY_9pI9CNZ4WY860q9cGwfa7LiZ2nlixw8liU3lV8Hr2HqvOK7qkBh59eyJ7jAnYFHE0tRU0jx7L 0WW7ZWKYfNjqRzbxc3glhWarmzqWttbs2YxRC1ysTP6vI_MfZMEe6hFkoc0p31yOjCQ8_ZVQySWt zeBnKV7oC9Fere3ggUA7NQWfo.tYzqWYiWkCBIuAZ9AbT8Qw3WYGmIwgvBDQQNWgob0pNd5NgKYz YdBvR0SPSp52vN5m.CdGRhJOegfrxlRLaaIfA4eCOSajCXPViA_xOOCtUqixt7bytxgt7Cogo32. DDy6XH4aWyzv4t_xVq.BIF0jidSSI_KWg0fB2Gq1nhmEiG0Sh5XFgRQxnEmN2glKn2AQG0rZBdUS 1jpaba5lKF8YhV2M_7.bkj1oCsLco5BRlUqy2Hg65SbskX7HNz0yE9Kzay6d5JjN2wSyV8DBT6aM qbQ8CKG0WgPY7g3_X6CZr14fQLroTu8AwEVuOlcIVK8BM1rgH5UY20fp0L5QAORdXtHfc_7OlWu2 Vg7XB.4QR5MK3Ldq54Fe1i4_9RNUPsSmtXoKx78etDNXiGlvthxVDS6LZcx9MBgKvxbFQYpr0oTd B_9dt1JgxLgOyOXFXsPlq.e2iiw32DvcBdEg2ua2OREBRpYfBXSoPAGe0OMs_1XPZfiS4ctcyC2C jm316rG6LP2e6NvSfohUdOQERjDH1oJ7x9g9BUrE8ynMV67FotB7WQMVZ5Tz7fBWS5dQshpLcUlh kg9Zeh8JLCjANgZ1iy7KGTYH4FC9FKGjikUurSwNNfcmoVUUWi9Ydb9LzQJKsoRI317Xmc5kPccO VmC_IwJdn3MtQqUswkTYm.83GkAn2FWHfrySgQ9L5BBnisYA99OdWooewl9GbSOyoAfr5YGXFtiV efJY45jnHl_ayDD8ctPw.Mxrr0dsU.1EmsvolL5.kypvcXn_QnfdQwZo8noYy1bPBi10vRziJK1J n_b_V2m69RrccxTH.KmOySSf0N4AgHFCgeCFyf5axluEiaUPXpJy0IpsaFsUAQ81fxmv1vNiGPZv 6H.DMLSdMtkBwjW9.khsuF.SpVdBF98SS67li4q0nrzW7mLIhPFplp1gnXr60qGOOK9dxO141zFJ FA0CyblZins8yZWIaEJY9yeaA_UAwj7ffksAOVYF.rCQz_75ucQ5RIPiSR.v8Q1y0teOdJ6uFMRe 3qlpAHVwdML40lEV8V9ifg4Bt6FyaJDJr5_L_urAmsRWKztQ15pYxXriAoOkypEMNWwcSX8hZ_4e 7133_cX3xtlNA8iRmKpdomum3SwNXl9KAPdsPKCcdVB88.mYoGcH2gBkpII.OjVSuX1ZlPQVi0bG E9.BInZm9GSm49N6F1q5jiIDDhboYSibxF4Cm2.ax8JReav_MPg99Psu82srDq8r6bNlY0BD2Ws6 inyfkTQJFsSsSfvjDnc3f860UgddOwKPUBkZ5J5JRQUhnfi3B3QEoKgnun1WCUfP_.JoUy9FZ3JA 1q9q1DPR8HPMygCHw3aua_AfYQrVNwEwgYe6EfiABNCnuw548jFy6HbfykiEOhLWJgVZnX2oRfIn E6G4B52CS6Mma3Jxp8nr47mZ7WpoQxn.g02h31BYYFy0YH4of4ZOJnFSEZewk7doUv9nPUyMlFmY 4G8SAXM.YJoxJxgW7tp68z63F X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 15 Dec 2021 22:58:37 +0000 Received: by kubenode506.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 06c9a6e2d2535894f2ed2de5f4ad06de; Wed, 15 Dec 2021 22:58:36 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: On amd64 main-n251456-22c4ab6cb015-dirty (Dec.-7): /boot/kernel/ng_ubt.ko is getting "symbol sysctl___net_bluetooth undefined" Message-Id: Date: Wed, 15 Dec 2021 14:58:35 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4JDrJj6J51z4pwc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=GqijW1c7; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.27 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.78)[-0.778]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Back when I upgraded the ThreadRipper 1950X amd64 system to (line split = for readability): # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25 = main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 =20 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72=20 arm64 aarch64 1400043 1400043 I started getting notices like: Dec 7 18:38:57 amd64_ZFS kernel: link_elf_obj: symbol = sysctl___net_bluetooth undefined Dec 7 18:38:57 amd64_ZFS kernel: linker_load_file: = /boot/kernel/ng_ubt.ko - unsupported file type (Not that I use the bluetooth on the system.) Is this expected for a kernel of that vintage? For reference: # more /usr/main-src/sys/amd64/conf/GENERIC-NODBG # # GENERIC -- Custom configuration for the amd64/amd64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols makeoptions WITH_CTF=3D1 # Run ctfconvert(1) for DTrace = support options NUMA options MAXMEMDOM=3D2 #options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT=3D0 # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE #options ACPI_DEBUG # Disable any extra checking for. . . nooptions DEADLKRES # Would enable the deadlock = resolver nooptions INVARIANTS # Would enable calls of extra = sanity checking nooptions INVARIANT_SUPPORT # Would enable extra sanity = checks of internal structures, required by INVARIANTS nooptions WITNESS # Would enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Would enable running witness = on spinlocks for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Kernel Sanitizers nooptions COVERAGE # Would enable generic kernel = coverage. Used by KCOV nooptions KCOV # Would enable Kernel Coverage = Sanitizer # Warning: KUBSAN can result in a kernel too large for loader to load nooptions KUBSAN # Would enable Kernel Undefined = Behavior Sanitizer device iwm device iwmfw sysctl___net_bluetooth seems to be from one or more of: # grep -r "net_bluetooth[^_]" /usr/main-src/sys/ | more = /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_INT(_net= _bluetooth, OID_AUTO, version, = /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_ne= t_bluetooth, OID_AUTO, hci, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, = /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_ne= t_bluetooth, OID_AUTO, l2cap, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, = /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_ne= t_bluetooth, OID_AUTO, rfcomm, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, = /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_ne= t_bluetooth, OID_AUTO, sco, CTLFLAG_RW | CTLFLAG_MPSAFE, 0,=20 = /usr/main-src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:SYSCTL_INT(_net_= bluetooth, OID_AUTO, usb_isoc_enable, CTLFLAG_RWTUN | CTLFLAG_MPSAFE, = /usr/main-src/sys/netgraph/bluetooth/include/ng_bluetooth.h:SYSCTL_DECL(_n= et_bluetooth); =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 16 00:41:27 2021 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 1DA7818D432C for ; Thu, 16 Dec 2021 00:41:32 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDtbH0Snvz3Hm2 for ; Thu, 16 Dec 2021 00:41:31 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x429.google.com with SMTP id e5so7656198wrc.5 for ; Wed, 15 Dec 2021 16:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=YGBuEKdxfmrXomPu68T+fqHsD6IVmTgf7daOmGizJ0k=; b=euZAsVFVCzTTQYz0TkURmAKv8z8PfHtRgDKRme4MBe8d8CwhIJoC6dj+vdz/OgfNqt rSA8j9RLv9FNSVkaeeeF1QS2QJukT559LJZ2yDvGUQ+WkJFx4BFSCBVtUQXD+oG182A0 Tl8hoJjPsWk+fzpkIJwaglznUJ/MCa0ZT7awMXFPVB6IDIZQXbMR2TgBz21OsCHOCoox xAoMbsuHTQBG/nBQDYeIBS/krahY6PDZBmRUyKH+u+MaF8y5cdZMic9OwTAdaOkiIPE3 KnmbBSxT8JrbU4QUc2eNeHEHfuuix2iC3Kdg0USt1/vu5yL2vw1EaW1307P83uXiB74Z e5+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=YGBuEKdxfmrXomPu68T+fqHsD6IVmTgf7daOmGizJ0k=; b=cTXpLVAnFwHO64c1Exivb2bWFyzkot8p6boCBsOfFTZfvmvfJwx3gTliH/+whWvuyx CanhKQqGzDs3/6v+O+etfDxxeCZBdI7GZtaf1lYsjaXMMclO2iEZ8u0QQfY1RYg9NBBr SuEJ35K3I9W9VFLdPycbQtzeEEEZT8x8Mt8rb0bM0PgHteDHj43RwJJX3NM+2OaNK27z PwGnWpxyx207d5rDVtq7W5eRkm3CcwhtTVxANOoW38LtpTkqlIkjB1u3gbTX6oedmoWW G004BIDhY9enblREYv0S+IAW/m68HeqKEdmtD04rc2IG7ZpqigTxYscHVqA8Fxl6my+v Td+Q== X-Gm-Message-State: AOAM533J85H5lkSJDjrCUvRsloxybuUwZMwgQ1Y3LBWW/IlD3mNKFcUC CWNtwi7YLFnwTywTgeTbu+atx8nwqs2RhQ== X-Google-Smtp-Source: ABdhPJxcZUlFGyboX233RoWPQjBtKaCrbT1wQMEDQmmVOrasT1NJl5/n2s9EpLm3pxQ9JwQAUNw4mg== X-Received: by 2002:a5d:6d8a:: with SMTP id l10mr6748563wrs.490.1639615289470; Wed, 15 Dec 2021 16:41:29 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id g13sm3960317wri.102.2021.12.15.16.41.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Dec 2021 16:41:28 -0800 (PST) Message-ID: <11dc149e-bd4e-bde2-efeb-338149a8c311@gmail.com> Date: Thu, 16 Dec 2021 00:41:27 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: L2ARC: inexplicable disappearance of cache device (was: CURRENT: ZFS freezes system beyond reboot) Content-Language: en-GB To: freebsd-current@freebsd.org References: <20211212102032.08af9689@jelly.fritz.box> <20211215185509.310fc873@hermann> From: Graham Perrin In-Reply-To: <20211215185509.310fc873@hermann> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JDtbH0Snvz3Hm2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=euZAsVFV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::429 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::429:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 15/12/2021 17:55, FreeBSD User wrote: > … SSD, partioned into two halfes, one for ZIL, the other for > L2ARC. When showing "zpool status", the RAIDZ's HDDs (Hitachi/Seagate > 4 TB NAS HDD) where "online", ZIL was "online" and > L2ARC device/vdev showd - nothing. … The 'nothing' aspect reminds me of: L2ARC: inexplicable disappearance, without removal, of cache device From nobody Thu Dec 16 07:45:16 2021 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 256FD18F3E28 for ; Thu, 16 Dec 2021 07:45:25 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JF40N74QYz3jj2; Thu, 16 Dec 2021 07:45:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4A2C326EB8; Thu, 16 Dec 2021 07:45:21 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <7de18fab-ddc3-b17c-c066-4e6b291072af@FreeBSD.org> Date: Thu, 16 Dec 2021 09:45:16 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.0 From: Andriy Gapon Subject: Re: CURRENT: ZFS freezes system beyond reboot Content-Language: en-US To: FreeBSD User Cc: Alan Somers , FreeBSD CURRENT References: <20211212102032.08af9689@jelly.fritz.box> <20211215185509.310fc873@hermann> In-Reply-To: <20211215185509.310fc873@hermann> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639640725; 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=xk8VkEui/oxIsQBHBT6G19C3ljEp80L4MAyd3i2a0L4=; b=RVpyG8LIs18WogWYBGSN9jT7bFplMrguUxGfkPwDB/PclSbrKzM/j6r0AE3EHzZL9zXnTt 2ocvWitp6qRrFPndpMKpGB9EV+q+Jg0IAsNeLOlFT5PcUMxSUYt8JN8jEZA0jw3ofwU9+U PhHiF9goD8D950I538jfhDDPEU2Uh9mOQ6Z4QB/XklbyXMdCGICXMX9Dk/WOgJcfQ/7LKu I5DgTtLc1pYfhpHLCG7jXyhlmRvhUmd6qdws4AEoWWuwf2q3uXpqROYgyKx0xwHkTUXAbu SwdqVvkjSON+Q2/kz/DoanPM+mZh1ry8uxuQkDaEWfb1i6TSjCqV0CoDRtr9Uw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639640725; a=rsa-sha256; cv=none; b=Hni9MukryhIPMOW0YMrBkE7Yb90mC5rxsUYdZzn/T0MwT43UbbmN9tSU2UjRL462PkP9pv 5Z1Ju3uaU915Tvvg4F8ybmg/8vWoAR8kRQPaoQiidppsWVhinkJaQPaGaB5ty/nsD7wOP2 IajGQHWoVf90n7VSSldjTgXDQwm+JtwLIkcJBIs/0lBu2o9Tz3tfHHRTKxG+WJ4Kd0BWl7 CrYS+hrbuIalEX9BWQm53A+USOi1brvR4rG3Bqf590Tx7H1cQneyr5V+5oyNJKt9GCR1R+ ln+yhWmgrZ+mz0mtd07J2BhtrLcKAhl8alL1eKRXUrcwF9P0onKwgoh786Qg0w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 15/12/2021 19:55, FreeBSD User wrote: > It is spooky, if not to say "buggy", if ZFS is capable of freezing the whole box even if > the essential operating system stuff is isolated on a dedicated UFS filesystem. I do not think that this is the case. Commands that do not access anything on ZFS or anything related to ZFS should be unaffected. -- Andriy Gapon From nobody Thu Dec 16 08:56:58 2021 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 9C64318D8350 for ; Thu, 16 Dec 2021 08:57:12 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4JF5bD3M52z3sY1 for ; Thu, 16 Dec 2021 08:57:12 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 381DF2602CC; Thu, 16 Dec 2021 09:57:05 +0100 (CET) Message-ID: <3e5b7816-e54e-644b-7e26-4a374cf6bfb7@selasky.org> Date: Thu, 16 Dec 2021 09:56:58 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: On amd64 main-n251456-22c4ab6cb015-dirty (Dec.-7): /boot/kernel/ng_ubt.ko is getting "symbol sysctl___net_bluetooth undefined" Content-Language: en-US To: marklmi@yahoo.com, freebsd-current References: From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JF5bD3M52z3sY1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 12/15/21 23:58, Mark Millard via freebsd-current wrote: > Back when I upgraded the ThreadRipper 1950X amd64 system to (line split for readability): > > # uname -apKU > FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25 main-n251456-22c4ab6cb015-dirty: > Tue Dec 7 19:38:53 PST 2021 > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400043 1400043 > > I started getting notices like: > > Dec 7 18:38:57 amd64_ZFS kernel: link_elf_obj: symbol sysctl___net_bluetooth undefined > Dec 7 18:38:57 amd64_ZFS kernel: linker_load_file: /boot/kernel/ng_ubt.ko - unsupported file type > > (Not that I use the bluetooth on the system.) > > Is this expected for a kernel of that vintage? > > For reference: > > # more /usr/main-src/sys/amd64/conf/GENERIC-NODBG > # > # GENERIC -- Custom configuration for the amd64/amd64 > # > > include "GENERIC" > > ident GENERIC-NODBG > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support > > options NUMA > options MAXMEMDOM=2 > > #options ALT_BREAK_TO_DEBUGGER > > options KDB # Enable kernel debugger support > > # For minimum debugger support (stable branch) use: > options KDB_TRACE # Print a stack trace for a panic > options DDB # Enable the kernel debugger > > # Extra stuff: > #options VERBOSE_SYSINIT=0 # Enable verbose sysinit messages > #options BOOTVERBOSE=1 > #options BOOTHOWTO=RB_VERBOSE > #options KTR > #options KTR_MASK=KTR_TRAP > ##options KTR_CPUMASK=0xF > #options KTR_VERBOSE > #options ACPI_DEBUG > > # Disable any extra checking for. . . > nooptions DEADLKRES # Would enable the deadlock resolver > nooptions INVARIANTS # Would enable calls of extra sanity checking > nooptions INVARIANT_SUPPORT # Would enable extra sanity checks of internal structures, required by INVARIANTS > nooptions WITNESS # Would enable checks to detect deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Would enable running witness on spinlocks for speed > nooptions DIAGNOSTIC > nooptions MALLOC_DEBUG_MAXZONES > > # Kernel Sanitizers > nooptions COVERAGE # Would enable generic kernel coverage. Used by KCOV > nooptions KCOV # Would enable Kernel Coverage Sanitizer > # Warning: KUBSAN can result in a kernel too large for loader to load > nooptions KUBSAN # Would enable Kernel Undefined Behavior Sanitizer > > device iwm > device iwmfw > > > sysctl___net_bluetooth seems to be from one or more of: > > # grep -r "net_bluetooth[^_]" /usr/main-src/sys/ | more > /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_INT(_net_bluetooth, OID_AUTO, version, > /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth, OID_AUTO, hci, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, > /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth, OID_AUTO, l2cap, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, > /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth, OID_AUTO, rfcomm, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, > /usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth, OID_AUTO, sco, CTLFLAG_RW | CTLFLAG_MPSAFE, 0, > /usr/main-src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:SYSCTL_INT(_net_bluetooth, OID_AUTO, usb_isoc_enable, CTLFLAG_RWTUN | CTLFLAG_MPSAFE, > /usr/main-src/sys/netgraph/bluetooth/include/ng_bluetooth.h:SYSCTL_DECL(_net_bluetooth); > This issue was fixed: https://cgit.freebsd.org/src/commit/?id=8fa952937bbe44a0fdd17348adfbbfd44aef6004 --HPS From nobody Thu Dec 16 09:17:33 2021 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 84EF718DD8AC for ; Thu, 16 Dec 2021 09:17:36 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JF62m0QmGz4R03; Thu, 16 Dec 2021 09:17:35 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639646254; 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=27VFZgSvR1UEiFv/ABM4DdH+PnmjUBuGXR5IMKeh0tQ=; b=Wome6hgiVBcPomGmOEnEb8N1mnWaTC5+yskwQVPgV0ymRwbcRazxCqWfJYWeRsAnBvFvQh CsPba/QVgWHpXGEG4dcu3QXoLUlWIUmaDq3Cbo/gqje8iluhvHZ5y1gunHqYkPM5DdhRT/ N1OhXnJtODeuXlhPlReX7VrkDizS+74= Received: from skull.home.blih.net (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id ed67f7b5 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 16 Dec 2021 09:17:34 +0000 (UTC) Date: Thu, 16 Dec 2021 10:17:33 +0100 From: Emmanuel Vadot To: Gleb Smirnoff Cc: Ed Maste , FreeBSD Current Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? Message-Id: <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.com> In-Reply-To: References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JF62m0QmGz4R03 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 15 Dec 2021 10:11:16 -0800 Gleb Smirnoff wrote: > On Wed, Dec 15, 2021 at 05:52:02PM +0100, Emmanuel Vadot wrote: > E> > > I've noticed this /sbin/sconfig binary and after looking it's for > E> > > configuring Cronyx E1 PCI (PCI as in PCI, not PCIe). > E> > > The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't > E> > > supported. > E> > > We currently only build the drivers for i386 (and they contain native > E> > > compiled code). > E> > > > E> > > Anyway, I'd like to remove this from the tree, I really doubt that > E> > > anyone uses this cards nowadays (or even E1) but just in case I send > E> > > this mail. > E> > > E> > I posted a similar query to -stable in 2020, at > E> > https://lists.freebsd.org/pipermail/freebsd-stable/2020-February/092037.html > E> > and did not get any response. > E> > > E> > I have D23928 for a deprecation notice for ce and cp. Gleb commented > E> > there that he'd offer to maintain them (and as part of that, removed > E> > sppp in 6aae3517ed25). > E> > > E> > E> I'm not sure I understand the logic here. > E> We're keeping drivers for museum grade hardware that no developer have > E> access to and likely no one uses nowadays just for an hypothetical > E> situation where someone will try to use those cards on FreeBSD 14 i386 > E> in 2021 ? > E> And we're doing that just because the drivers compiles ? > > We are doing that because the hardware is still produced and can be > purchased at http://cronyx.ru/price/#taupci And this is not a dead > website, I gave a call to tech support last year. Who uses it? No > idea. For some obscure reason they are still produced along with > conventional PCI industrial mainboards (you can google that). I'm sure that if one looks deep enough, a lot of obsolete hardware that we've removed are still produced by some industrial computer maker. And I don't think that this is a valid reason to keep everything that is old. > I agree that actual intersection of FreeBSD users and Cronyx > users could be zero today. But potentially it can be non-zero. > I would appreciate if somebody chooses FreeBSD for their very > strange industrial communications equipment. > > Some corrections on above statements. > > 1) We build cp(4) on amd64. We don't build ce(4) on amd64 for a > reason that some functions are marked with __attribute__ fastcall. > I'm 99% sure that attribute can be removed and ce(4) will build > on amd64. sconfig(8) is build on amd64. No we don't, see : https://cgit.freebsd.org/src/tree/sys/modules/Makefile#n772 > 2) Drivers don't contain native precompiled code. They contain > obfuscated code. Ok, I actually didn't looked, just noticed that they where listed under MK_SOURCELESS_HOST. > Does sconfig create any problems for you? I'm fine with removing > the drivers and the tool if they do really create a burden for us. > That was case with their sppp(4) half, and I removed it in 6aae3517ed25. > If there is no maintainance burden, why remove them? Just to save > disk space? They don't really create a burden. The reason that made me look at this is that I've noticed that my FreeBSD-runtime package had this sconfig binary that I've never heard of before. After digging I saw that it was for those old cards. I honestly don't care if we keep the drivers as of today we only compile them for i386. I don't think that we should enable them for amd64, we've lived ~20 years on amd64 without them, nobody complained that they weren't present so clearly nobody cares about having them. We shouldn't enable drivers on some arch just "because we can". With a46856c3f9ec in main right now I'm perfectly happy as I don't have some useless tool, if it could stay that way that would be great. But it will be nice to have some kind of official statement on what FreeBSD should deliver in term of drivers, I think we're way too conservative on keeping old stuff that nobody uses just because "it compiles". Cheers, -- Emmanuel Vadot From nobody Thu Dec 16 09:49:25 2021 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 8334D18E44B6 for ; Thu, 16 Dec 2021 09:49:33 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JF6ld1K0Lz4W0w; Thu, 16 Dec 2021 09:49:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id E718927DB0; Thu, 16 Dec 2021 09:49:32 +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 25C545CD04; Thu, 16 Dec 2021 10:49:31 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_CCF77E6E-5561-4F08-9076-9AD67314A121"; 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 15.0 \(3693.40.0.1.81\)) Subject: Re: CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23) From: Dimitry Andric In-Reply-To: <20211215184452.3d6481cb@hermann> Date: Thu, 16 Dec 2021 10:49:25 +0100 Cc: Daniel O'Connor via freebsd-current , darius@dons.net.au Message-Id: <568DB415-E9DD-4CEA-9C36-EDE70495F56B@FreeBSD.org> References: <20211125092054.4696b6f2@hermann> <20211215184452.3d6481cb@hermann> To: FreeBSD User X-Mailer: Apple Mail (2.3693.40.0.1.81) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639648173; 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=OYEpLlzaRd2XUukIk0JUlBJGVawfrHjte4XNfjrRPsE=; b=BVb4uF3WNG+4EiY0+c4bdDvT4Uny2Hk+T8MsAgZL1qfeD/kgt+aub5HfrJcwoWyWtd8OpJ s+qp7tkiD0RHLTlYfB01VkNHOgmRNbidq2Hb8Nbeam6sH05fgQ8j8V4LGcwHHBsRVT2T8d SUoPWIyvhxjI7G5JqiBUgEUtVEIFrDbIvv3hhzQWYsIgxsgCSg0BqhU9Vk37Tyig+3FllV PxBZYKIEUBmaNeCKQtJVk0gVxpbHpWEK3KemzGqVELqouWBh3U2d0QOkbMWT28hBsct837 Lkw2wHj8jXdxX3SRrog6BAFwW9aLlAghMmojaDkCZrJfTth1lhDUvzSRs28SGw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639648173; a=rsa-sha256; cv=none; b=qX9ygsIF7jSMoswmh3B+lGQtG1MW1Ccyd5vNZATg37T1lWx+uZONXrjwVU4F36CLStutLH MOYLaPH/HxjN5k3M/9pSVhplNaYIe1eyaTpAFja2fJWw4q2odgliXkE1CTEO1IyISE4GpK WDBynuEOKT2jNVUM9SJuwAUmkvXGWtOUKFgNFTF69OrNMOmAzSv1jRBtJ3HQiYGAgakfw8 9RGZSj0sGOh8hvpjQAjShdv/LJChF4GAhM1qs69oigvfs6+h8B/ZZw4/ByNRdld9jDi0W3 xau6Fv4MT4KiYePL1OjmcpsVMH6DB6Uz/uDe7+Bdw34ANcR8V2fjB/7rcP2dTg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_CCF77E6E-5561-4F08-9076-9AD67314A121 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Dec 2021, at 18:44, FreeBSD User wrote: >=20 > On Fri, 10 Dec 2021 19:41:07 +1030 > Daniel O'Connor via freebsd-current = wrote: >>> On 25 Nov 2021, at 18:50, FreeBSD User = wrote: ... >=20 >>> Since then named is crashing with a mysterious segmentation fault = (see PR 259921, >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259921). ... > In the meanwhile, bind-9.16.24_1 has been issued in ports - the same = problem occurs with > that version, too, when compiled with llvm13. I committed a fix in: = https://cgit.freebsd.org/src/commit/?id=3D5a925e4644665b9a7a5cdd664764fb0a= 4d1c5797 which I'll MFC after the usual 3 days. Please try this out. :) -Dimitry --Apple-Mail=_CCF77E6E-5561-4F08-9076-9AD67314A121 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYbsLpQAKCRCwXqMKLiCW o9wpAKChCpFj0x/dIzRiu808xts+5eQgfwCg/Bz41hhxnY9FhtMo69dmw/6ON24= =XZOZ -----END PGP SIGNATURE----- --Apple-Mail=_CCF77E6E-5561-4F08-9076-9AD67314A121-- From nobody Thu Dec 16 15:01:30 2021 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 F087718FF97B for ; Thu, 16 Dec 2021 15:01:36 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFFgh5GZDz3DnY; Thu, 16 Dec 2021 15:01:36 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BGF1UTX009463 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 16 Dec 2021 07:01:30 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BGF1USY009462; Thu, 16 Dec 2021 07:01:30 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Thu, 16 Dec 2021 07:01:30 -0800 From: Gleb Smirnoff To: Emmanuel Vadot Cc: Ed Maste , FreeBSD Current Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? Message-ID: References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.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: <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.com> X-Rspamd-Queue-Id: 4JFFgh5GZDz3DnY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Emmanuel, On Thu, Dec 16, 2021 at 10:17:33AM +0100, Emmanuel Vadot wrote: E> > E> I'm not sure I understand the logic here. E> > E> We're keeping drivers for museum grade hardware that no developer have E> > E> access to and likely no one uses nowadays just for an hypothetical E> > E> situation where someone will try to use those cards on FreeBSD 14 i386 E> > E> in 2021 ? E> > E> And we're doing that just because the drivers compiles ? E> > E> > We are doing that because the hardware is still produced and can be E> > purchased at http://cronyx.ru/price/#taupci And this is not a dead E> > website, I gave a call to tech support last year. Who uses it? No E> > idea. For some obscure reason they are still produced along with E> > conventional PCI industrial mainboards (you can google that). E> E> I'm sure that if one looks deep enough, a lot of obsolete hardware E> that we've removed are still produced by some industrial computer maker. E> And I don't think that this is a valid reason to keep everything that E> is old. I'd be interested to see at least one example of removed driver for a hardware that is still produced. Can you demonstrate one please? E> > I agree that actual intersection of FreeBSD users and Cronyx E> > users could be zero today. But potentially it can be non-zero. E> > I would appreciate if somebody chooses FreeBSD for their very E> > strange industrial communications equipment. E> > E> > Some corrections on above statements. E> > E> > 1) We build cp(4) on amd64. We don't build ce(4) on amd64 for a E> > reason that some functions are marked with __attribute__ fastcall. E> > I'm 99% sure that attribute can be removed and ce(4) will build E> > on amd64. sconfig(8) is build on amd64. E> E> No we don't, see : E> https://cgit.freebsd.org/src/tree/sys/modules/Makefile#n772 Well, that was my miss, when I moved it from options.i386 to options.x86. Forgot about modules. The Makefile also has a comment at line 764. With "we build" I meant that we can add it to kernel config and build. E> > Does sconfig create any problems for you? I'm fine with removing E> > the drivers and the tool if they do really create a burden for us. E> > That was case with their sppp(4) half, and I removed it in 6aae3517ed25. E> > If there is no maintainance burden, why remove them? Just to save E> > disk space? E> E> They don't really create a burden. E> The reason that made me look at this is that I've noticed that my E> FreeBSD-runtime package had this sconfig binary that I've never heard E> of before. After digging I saw that it was for those old cards. E> I honestly don't care if we keep the drivers as of today we only E> compile them for i386. I don't think that we should enable them for E> amd64, we've lived ~20 years on amd64 without them, nobody complained E> that they weren't present so clearly nobody cares about having them. We E> shouldn't enable drivers on some arch just "because we can". E> With a46856c3f9ec in main right now I'm perfectly happy as I don't E> have some useless tool, if it could stay that way that would be great. I'm not. Your position is simply: "the utility existence bugs me cause it is useless for me", and "I don't care if it exist on i386, cause I don't use i386". Kind of selfish position. For myself FreeBSD also contains quite a lot of tools I never use and probably never would. E> But it will be nice to have some kind of official statement on what E> FreeBSD should deliver in term of drivers, I think we're way too E> conservative on keeping old stuff that nobody uses just because "it E> compiles". I agree with that. We need such policy. It is being promised, and while it is not there yet, there is this document: https://wiki.freebsd.org/DeprecationPlan As you see, a developer who wants to remove something needs to propose that, communicate that and plan. And as you can see there, Cronyx devices were proposed properly by Ed. The ISA ones were deleted quickly. For the PCI ones I communicated Cronyx and checked their status. Later the drivers were made as minimal as possible, removing sppp(4). This is a proper process. Not do a drive by commit and refuse to revert it. -- Gleb Smirnoff From nobody Thu Dec 16 15:13:37 2021 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 E390418C24CE for ; Thu, 16 Dec 2021 15:13:39 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFFxb3STwz3GWG; Thu, 16 Dec 2021 15:13:39 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639667617; 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=e0DiTY/7ZCVwgCSl3cgPvJsYls5GeHala+Wm54eblHY=; b=Zm8mMUSKgn3LtfEp0yyk7mQ1j81D9i6+QCh2rcEYTlr3A7tfkJIs+52cEXUFROXSU6aeRL aSQ+2OMnnj3+41KBkSZVQk7qb6GcxwoX+PSD/6OLCMTBIG8HfI35mtmLZvUHwKiCNNNDdR 1xldiHVh5RPeMl5M7BLReMV5NHi2y+w= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id cb71995a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 16 Dec 2021 15:13:37 +0000 (UTC) Date: Thu, 16 Dec 2021 16:13:37 +0100 From: Emmanuel Vadot To: Gleb Smirnoff Cc: Ed Maste , FreeBSD Current Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? Message-Id: <20211216161337.1fa53758e61eaeb37b8b24d0@bidouilliste.com> In-Reply-To: References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JFFxb3STwz3GWG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 16 Dec 2021 07:01:30 -0800 Gleb Smirnoff wrote: > Emmanuel, > > On Thu, Dec 16, 2021 at 10:17:33AM +0100, Emmanuel Vadot wrote: > E> > E> I'm not sure I understand the logic here. > E> > E> We're keeping drivers for museum grade hardware that no developer have > E> > E> access to and likely no one uses nowadays just for an hypothetical > E> > E> situation where someone will try to use those cards on FreeBSD 14 i386 > E> > E> in 2021 ? > E> > E> And we're doing that just because the drivers compiles ? > E> > > E> > We are doing that because the hardware is still produced and can be > E> > purchased at http://cronyx.ru/price/#taupci And this is not a dead > E> > website, I gave a call to tech support last year. Who uses it? No > E> > idea. For some obscure reason they are still produced along with > E> > conventional PCI industrial mainboards (you can google that). > E> > E> I'm sure that if one looks deep enough, a lot of obsolete hardware > E> that we've removed are still produced by some industrial computer maker. > E> And I don't think that this is a valid reason to keep everything that > E> is old. > > I'd be interested to see at least one example of removed driver for > a hardware that is still produced. Can you demonstrate one please? This was an hypothetical situation. > E> > I agree that actual intersection of FreeBSD users and Cronyx > E> > users could be zero today. But potentially it can be non-zero. > E> > I would appreciate if somebody chooses FreeBSD for their very > E> > strange industrial communications equipment. > E> > > E> > Some corrections on above statements. > E> > > E> > 1) We build cp(4) on amd64. We don't build ce(4) on amd64 for a > E> > reason that some functions are marked with __attribute__ fastcall. > E> > I'm 99% sure that attribute can be removed and ce(4) will build > E> > on amd64. sconfig(8) is build on amd64. > E> > E> No we don't, see : > E> https://cgit.freebsd.org/src/tree/sys/modules/Makefile#n772 > > Well, that was my miss, when I moved it from options.i386 to options.x86. > Forgot about modules. The Makefile also has a comment at line 764. > > With "we build" I meant that we can add it to kernel config and build. > > E> > Does sconfig create any problems for you? I'm fine with removing > E> > the drivers and the tool if they do really create a burden for us. > E> > That was case with their sppp(4) half, and I removed it in 6aae3517ed25. > E> > If there is no maintainance burden, why remove them? Just to save > E> > disk space? > E> > E> They don't really create a burden. > E> The reason that made me look at this is that I've noticed that my > E> FreeBSD-runtime package had this sconfig binary that I've never heard > E> of before. After digging I saw that it was for those old cards. > E> I honestly don't care if we keep the drivers as of today we only > E> compile them for i386. I don't think that we should enable them for > E> amd64, we've lived ~20 years on amd64 without them, nobody complained > E> that they weren't present so clearly nobody cares about having them. We > E> shouldn't enable drivers on some arch just "because we can". > E> With a46856c3f9ec in main right now I'm perfectly happy as I don't > E> have some useless tool, if it could stay that way that would be great. > > I'm not. Your position is simply: "the utility existence bugs me cause > it is useless for me", and "I don't care if it exist on i386, cause I > don't use i386". Kind of selfish position. What's selfish about removing some binary that 100% of our amd64 users never needed since the creation of FreeBSD/amd64 ? > For myself FreeBSD also contains quite a lot of tools I never use and > probably never would. > > E> But it will be nice to have some kind of official statement on what > E> FreeBSD should deliver in term of drivers, I think we're way too > E> conservative on keeping old stuff that nobody uses just because "it > E> compiles". > > I agree with that. We need such policy. It is being promised, and while > it is not there yet, there is this document: > > https://wiki.freebsd.org/DeprecationPlan > > As you see, a developer who wants to remove something needs to propose > that, communicate that and plan. And as you can see there, Cronyx devices > were proposed properly by Ed. The ISA ones were deleted quickly. For the > PCI ones I communicated Cronyx and checked their status. Later the > drivers were made as minimal as possible, removing sppp(4). This is a > proper process. Not do a drive by commit and refuse to revert it. Where did I refuse to revert ? -- Emmanuel Vadot From nobody Thu Dec 16 15:53:10 2021 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 89E3B18DB961 for ; Thu, 16 Dec 2021 15:53:15 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFGqH00PBz3P09; Thu, 16 Dec 2021 15:53:14 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BGFrAuY009654 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 16 Dec 2021 07:53:10 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BGFrAAG009653; Thu, 16 Dec 2021 07:53:10 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Thu, 16 Dec 2021 07:53:10 -0800 From: Gleb Smirnoff To: Emmanuel Vadot Cc: Ed Maste , FreeBSD Current Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? Message-ID: References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.com> <20211216161337.1fa53758e61eaeb37b8b24d0@bidouilliste.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: <20211216161337.1fa53758e61eaeb37b8b24d0@bidouilliste.com> X-Rspamd-Queue-Id: 4JFGqH00PBz3P09 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Emmanuel, look at this communication: E> And we're doing that just because the drivers compiles ? G> We are doing that because the hardware is still produced ... E> ... a lot of obsolete hardware that we've removed are still produced ... G> I'd be interested to see at least one example ... E> This was an hypothetical situation. I don't know what to reply here. :( Now let's get constructive. E> > I'm not. Your position is simply: "the utility existence bugs me cause E> > it is useless for me", and "I don't care if it exist on i386, cause I E> > don't use i386". Kind of selfish position. E> E> What's selfish about removing some binary that 100% of our amd64 users E> never needed since the creation of FreeBSD/amd64 ? I agree that would be cool not to have stuff in the default install that is very unlikely to be used. On the other hand it would be cool that a device that is still in production doesn't require ancient FreeBSD to work. The latter requires to keep them in the build. The former requires not to have them installed. So what we need here is analog of LINT for the world build. A build that would cover all possible tools that aren't included into install. For example cxgbetool(8). Navdeep humbly put it in tools/tools initially. Later I asked him to move it to usr.sbin to make sure its build isn't broken. So it is installed, albeit 99% installations don't have Chelsio card. I think we can find more examples. So, proposed policy for such kind of devices is to have them in sys/conf/files and sys/conf/options and in LINT and do not have them in sys/modules/Makefile. Similarly for tools, to have them in the tree, enabled under 'lintworld' but not enabled under 'world'. Have WITH_SCONFIG and WITH_OTHERTOOL, but don't have it enabled by default. E> > I agree with that. We need such policy. It is being promised, and while E> > it is not there yet, there is this document: E> > E> > https://wiki.freebsd.org/DeprecationPlan E> > E> > As you see, a developer who wants to remove something needs to propose E> > that, communicate that and plan. And as you can see there, Cronyx devices E> > were proposed properly by Ed. The ISA ones were deleted quickly. For the E> > PCI ones I communicated Cronyx and checked their status. Later the E> > drivers were made as minimal as possible, removing sppp(4). This is a E> > proper process. Not do a drive by commit and refuse to revert it. E> E> Where did I refuse to revert ? May I ask you to revert it then, please? If you have time we can discuss and work on the above described policy of built but not included into default install devices/tools. P.S. If you really wish to deprecate something, I can suggest you to sacrifice sbni(4) :) -- Gleb Smirnoff From nobody Thu Dec 16 16:30:41 2021 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 9EC0918E419B for ; Thu, 16 Dec 2021 16:30:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFHfj3rc9z3ktn for ; Thu, 16 Dec 2021 16:30:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x933.google.com with SMTP id y23so6388808uay.7 for ; Thu, 16 Dec 2021 08:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lK75aiEDTzo5PsirePbFTQ2E0OiLtYZfMRqZiVl69J0=; b=csLZEYgjYdqqOjXGxGR/SDZxAxrTkHMAV4CU9DjEN+HHS6T1IxiZc23Tm0kobUixTe 3GtrfZ2M/+zJIvi9TJ++BAWNeYESG0A8zgHRsGCdhmuRYPbl5E8Dh2bU9wfA5A2iKfhW h7khtwtDeMRZ/xRrA4tz8eHGhJF4DnJW2nYTrspcZ0s0GxrVibDJ5rUeL2CEanBtnHWU TFJxLggen+3c/uD28TpCPPUZO7Zqxrptdm/DCg7EPvKRRkfy8Q3Uq5iLOrfEx9HtjRqD a/zxAyGMNkkRisu7KUG4wRsu15C7nSsUjNwnVSp4roPhwL44XpI4Bn8PZbR5vQX2c2UZ C30w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lK75aiEDTzo5PsirePbFTQ2E0OiLtYZfMRqZiVl69J0=; b=WO24/pHol1z9QgFHVG7v4yM1L7YtAFSjJKbd8tBrxSalrg2HDa8zgZYrKG5i+tIMVz Tf4BIAkmTiLLgy5xNJdkFhDLqki1LhayBmzFXQi8cY3EJCQCXctv2SZzC4ugt8Hed/Nq IbVX1NvCDP+c4qQpoiPOLPASE9UddXufpJ89zxpAxpY6ufzXspH6O0pYsB0kH47p06ii 9efy2TKE5mwdZjPFVS3Uat49BjRZq0sLDk8iu3a52wmry7nsSgSNpFqPKZ6wRin3sIpJ kJkrapAvJfWMk+WOei12yzHb5Oo2+lfKdE+L2muef6R1M184yfoT2jk0u7Y6qD/55bny uGqA== X-Gm-Message-State: AOAM530ct6KphaWzNf5wSRS7+AYuc5j5mJoBGvrOHblzF92ytzPd1+ZZ aO8Qk44PdIcnbj0ApZUFr5j4w9XLuoV+nt/ybGbCDluzjF2rNA== X-Google-Smtp-Source: ABdhPJx4Dw3ad0m9ELcHXxgYOy46k9DsqBvuScKjGBLOtWI8nYoDg75oajLIIQZj7+EVGYIj6BdRyOMnKZPiXh146F4= X-Received: by 2002:a05:6102:ec2:: with SMTP id m2mr292028vst.6.1639672252893; Thu, 16 Dec 2021 08:30:52 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.com> <20211216161337.1fa53758e61eaeb37b8b24d0@bidouilliste.com> In-Reply-To: From: Warner Losh Date: Thu, 16 Dec 2021 09:30:41 -0700 Message-ID: Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? To: Gleb Smirnoff Cc: Emmanuel Vadot , Ed Maste , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000002e9e1705d345f2f2" X-Rspamd-Queue-Id: 4JFHfj3rc9z3ktn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000002e9e1705d345f2f2 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 16, 2021 at 8:54 AM Gleb Smirnoff wrote: > Emmanuel, > > look at this communication: > > E> And we're doing that just because the drivers compiles ? > G> We are doing that because the hardware is still produced ... > E> ... a lot of obsolete hardware that we've removed are still produced ... > G> I'd be interested to see at least one example ... > E> This was an hypothetical situation. > > I don't know what to reply here. :( > The standards that Brooks, Ed and I have been using in retiring drivers has been "Still relevant to FreeBSD". Although whether or not something was still in production is an input into that, it's not the only factor in decisions made. While that standard is a bit vague, I'm struggling understanding the case for these drivers still being relevant to FreeBSD in the absence of documented actual use, let alone a use case that we can do a cost-benefit analysis on. Warner --0000000000002e9e1705d345f2f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 16, 2021 at 8:54 AM Gleb = Smirnoff <glebius@freebsd.org= > wrote:
=C2= =A0 Emmanuel,

look at this communication:

E> And we're doing that just because the drivers compiles ?
G> We are doing that because the hardware is still produced ...
E> ... a lot of obsolete hardware that we've removed are still produ= ced ...
G> I'd be interested to see at least one example ...
E> This was an hypothetical situation.

I don't know what to reply here. :(

The standards that Brooks, Ed and I have been using in retiring drivers ha= s been
"Still relevant to FreeBSD". Although whether or= not something was still in production
is an input into that, it&= #39;s not the only factor in decisions made.

While= that standard is a bit vague, I'm struggling understanding the case fo= r these
drivers still being relevant to FreeBSD in the absence of= documented actual use,
let alone a use case that we can do a cos= t-benefit analysis on.

Warner
--0000000000002e9e1705d345f2f2-- From nobody Thu Dec 16 16:49:37 2021 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 1A89C18E7AA8 for ; Thu, 16 Dec 2021 16:49:46 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFJ4T5nZJz3nxB; Thu, 16 Dec 2021 16:49:45 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BGGnbYw009910 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 16 Dec 2021 08:49:37 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BGGnbpQ009909; Thu, 16 Dec 2021 08:49:37 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Thu, 16 Dec 2021 08:49:37 -0800 From: Gleb Smirnoff To: Warner Losh Cc: Emmanuel Vadot , Ed Maste , FreeBSD Current Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? Message-ID: References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.com> <20211216161337.1fa53758e61eaeb37b8b24d0@bidouilliste.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JFJ4T5nZJz3nxB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Thu, Dec 16, 2021 at 09:30:41AM -0700, Warner Losh wrote: W> > E> And we're doing that just because the drivers compiles ? W> > G> We are doing that because the hardware is still produced ... W> > E> ... a lot of obsolete hardware that we've removed are still produced ... W> > G> I'd be interested to see at least one example ... W> > E> This was an hypothetical situation. W> > W> > I don't know what to reply here. :( W> W> The standards that Brooks, Ed and I have been using in retiring drivers has W> been W> "Still relevant to FreeBSD". Although whether or not something was still in W> production W> is an input into that, it's not the only factor in decisions made. W> W> While that standard is a bit vague, I'm struggling understanding the case W> for these W> drivers still being relevant to FreeBSD in the absence of documented actual W> use, W> let alone a use case that we can do a cost-benefit analysis on. Yes, so what I'm trying to say here is that right now cost of having the drivers in the tree is virtually zero. Emmanuel says that benefit is zero. I can't refute Emmanuel's statement, I can only speculate that benefit could be non-zero, as apparently devices are still produced and E1 lines still exist. So I'm fine with removal if anybody demonstrates me a non-zero cost of leaving the drivers in. -- Gleb Smirnoff From nobody Thu Dec 16 16:54:35 2021 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 EFB5118E92B1 for ; Thu, 16 Dec 2021 16:54:41 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFJB86gh3z3qdL; Thu, 16 Dec 2021 16:54:40 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BGGsZYg009940 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 16 Dec 2021 08:54:35 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BGGsZ8p009939; Thu, 16 Dec 2021 08:54:35 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Thu, 16 Dec 2021 08:54:35 -0800 From: Gleb Smirnoff To: Emmanuel Vadot Cc: Ed Maste , FreeBSD Current Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? Message-ID: References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.com> <20211216161337.1fa53758e61eaeb37b8b24d0@bidouilliste.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JFJB86gh3z3qdL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [-2.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_TLS_ALL(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Thu, Dec 16, 2021 at 07:53:10AM -0800, Gleb Smirnoff wrote: T> P.S. If you really wish to deprecate something, I can suggest you to T> sacrifice sbni(4) :) P.P.S. The driver actually provides a historical example: a driver removed, later appeared not only used by somebody but even having a responding vendor: commit ceee59fa5ac606fe28b18086dd07f526ef717f55 Author: John Baldwin Date: Wed Sep 10 18:42:19 2008 +0000 Disable the inline assembly crc32 routine and use the C version instead. The assembly version is reported to be broken on 5.x+. PR: kern/100425 Submitted by: Rashid N. Achilov shelton www.granch.ru MFC after: 1 week commit 26e46883290bfef867a15fb276b4eb7ee598dce6 Author: John Baldwin Date: Wed Sep 10 18:36:58 2008 +0000 Resurrect the sbni(4) driver. Someone finally tested the MPSAFE patches and the driver worked ok with them. Tested by: friends of yar commit e9a31041c016f6e2042440c9f18627b7708fc334 Author: John Baldwin Date: Fri Jul 4 21:06:57 2008 +0000 Remove the sbni(4) driver. No one responded to calls to test it on current@ and stable@. -- Gleb Smirnoff From nobody Fri Dec 17 02:55:39 2021 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 C817918F43E4 for ; Fri, 17 Dec 2021 02:55:43 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFYWf5mmCz4T2C for ; Fri, 17 Dec 2021 02:55:42 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42d.google.com with SMTP id e5so1401852wrc.5 for ; Thu, 16 Dec 2021 18:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:to:content-language:from :subject:content-transfer-encoding; bh=rehjfCLk/421FgIiOlJQ7i01yfHtU6h3dZ9AkDfzZuI=; b=mg4K7meSs+fpU0jReELKOMvxTmFD0ReqngSxMBq3vQt9yAiD6e1PWq+uk89EpS6QiR lFysgz0/R95dLom/IvcPDPYA1Yr35QP8da6gpkrMA63hpqIw09XXGh5HjmdScqRaofQm aRbd9KKzuK+W8rSUKb5EbgwffH8+B+d4eazBEH3Ht27Pu8bjn5POhjBpakLjs1f1g/BI uKG8mJ/dzrgFztEVdBBwUrR99G+OuTJB172DMOo0W0C7Y+uwTJ8Q/ByAS249vIe5b2xt 81feWZWJAhzYjY2pDURrgGACNVLfS1o0aXqv+RWXXs9spN5JIGkI07uTNiplFMOEZV83 w2lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to :content-language:from:subject:content-transfer-encoding; bh=rehjfCLk/421FgIiOlJQ7i01yfHtU6h3dZ9AkDfzZuI=; b=0PtcXWiD77CosxIj3IaH8nAYfOYpZPo6PVp6RkZPRxa9pR2Priv06WovXWeqbULmSd mLdsGVT3aV/ItUAJtJtQPgnYuUjWgOMsctBmdzrZ+Ek+VdmL46TxjVD2gEwfHDPZOizl bJeXqsYUi16a3LdBnZWwsty1XCnTm7rLCRZ1FhK0Z0JPW1IM80/GWCHPS4AZSYKK88UG M312kkMKRPMpbP15t0PtUmNcIl8GAWVq0LqjSD4JHgX4FOITlpjX4gFAFP+CoqykOg+r nymSSWio6xCYUViFMMgELXUJtwr+P+pCD6d92MNmsiWrWlY8jLAbZerhHx/NFsSS+RXo DZuQ== X-Gm-Message-State: AOAM533wI+ZDEX7EKseiWkmaQzTiGl9CoLoTx0CkWE1MjqutgGqwLKlZ EuxMwwa5y+kVOgbgM17jJ6Gu1iQbRrisPw== X-Google-Smtp-Source: ABdhPJyi669BpOPWTpoi3BAjfoDnSputbahAlc+l061tbRt5JvOeDoca/hAiDt9X9ZVyPdjhNYSiOw== X-Received: by 2002:a5d:59a6:: with SMTP id p6mr663993wrr.616.1639709741152; Thu, 16 Dec 2021 18:55:41 -0800 (PST) Received: from [192.168.1.7] (host-92-22-91-188.as13285.net. [92.22.91.188]) by smtp.gmail.com with ESMTPSA id 5sm3981122wmk.0.2021.12.16.18.55.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 18:55:40 -0800 (PST) Message-ID: <557cb9cf-f87a-fb8e-895f-085ce0767e66@gmail.com> Date: Fri, 17 Dec 2021 02:55:39 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: freebsd-current@freebsd.org Content-Language: en-GB From: Graham Perrin Subject: Vastly improved speeds with iwn(4) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JFYWf5mmCz4T2C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mg4K7meS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42d as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[92.22.91.188:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42d:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N In recent months, what (if anything) changed to improve things for users of iwn(4)? Intel Centrino Advanced-N 6205 [Taylor Peak] here. At home, previously I typically got less than 9 (download), now I get more than 70 Mbps. (I see last month's and for iwlwifi/mvm, If I understand correctly this new driver is not applicable to iwn(4) cards.) From nobody Fri Dec 17 03:03:13 2021 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 2F39218F6676 for ; Fri, 17 Dec 2021 03:03:15 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFYhL27jzz4Wj5; Fri, 17 Dec 2021 03:03:14 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WIHk5HD1THDYGZpQaRCeOK3oVkHTq7hzX4kACeRsXUU=; b=lioyLZ3Jpzbr7rXEgVblFRECKn xeAvupJ//D3uZnL5AHnfIUmMlFnAJnBWABhC3Hai7kdCOP33PLd37iSt+rCTTwUTKJnLMMlpkRZEt tgod8BZXVqxlFkB9zEZZvxH95BwlqG070Ch/J7JaTU6Ss8bLOdBh1kONHV5X+VcUhJoxJcNKwC2hD StfGVkYOVWj4dfcv4qHhl1KpLGJIjQM4Mt4mKIqRII7Tu1qubuOJOgxkYo0LC7nDB74RRQEhVzBtu Qojf+8W37KMV2cjCbnaGOx5AbR8/YVbnALdNbTH3c6D6v1g6w6XdN5pse1Q83Uh5Fj+maWgqI83UE bpj713vA==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:20441 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1my3Wb-000Fzl-7P; Thu, 16 Dec 2021 21:03:13 -0600 Received: from 76-250-255-117.lightspeed.austtx.sbcglobal.net ([76.250.255.117]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 16 Dec 2021 21:03:13 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Thu, 16 Dec 2021 21:03:13 -0600 From: Larry Rosenman To: Alexander Motin Cc: Freebsd current Subject: Re: Panic: Page Fault in Kernel: Yesterday's CURRENT In-Reply-To: References: <3d1b5249a2c51670de496fad9e8b054c@lerctr.org> <9852ae04-6dd0-1cd4-13fe-e97c68e71b37@FreeBSD.org> Message-ID: X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JFYhL27jzz4Wj5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=lioyLZ3J; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 12/10/2021 10:43 am, Larry Rosenman wrote: > 14-2021_12_07-1217 - - 1.87G 2021-12-07 12:17 > 14-2021_12_09-1957 NR / 121G 2021-12-09 19:57 > > If that's any help > > On 12/10/2021 10:36 am, Alexander Motin wrote: >> Hi Larry, >> >> This looks like some use-after-free or otherwise corrupted callout >> structure. Unfortunately the backtrace does not tell what was the >> callout. When was the previous update to look what could change? >> >> On 10.12.2021 11:24, Larry Rosenman wrote: >>> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15 >>> main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021     >>> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL  >>> amd64 >>> >>> VMCORE *IS* available. >>> >>> >>> >>> >>> Unread portion of the kernel message buffer: >>> kernel trap 12 with interrupts disabled >>> >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 20 >>> fault virtual address   = 0x0 >>> fault code              = supervisor write data, page not present >>> instruction pointer     = 0x20:0xffffffff804e0db4 >>> stack pointer           = 0x0:0xfffffe0434de4e10 >>> frame pointer           = 0x0:0xfffffe0434de4e70 >>> code segment            = base 0x0, limit 0xfffff, type 0x1b >>>                         = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags        = resume, IOPL = 0 >>> current process         = 82990 (c++) >>> trap number             = 12 >>> panic: page fault >>> cpuid = 0 >>> time = 1639111198 >>> KDB: stack backtrace: >>> #0 0xffffffff8050fc95 at kdb_backtrace+0x65 >>> #1 0xffffffff804c468f at vpanic+0x17f >>> #2 0xffffffff804c4503 at panic+0x43 >>> #3 0xffffffff807a2195 at trap_fatal+0x385 >>> #4 0xffffffff807a21ef at trap_pfault+0x4f >>> #5 0xffffffff80779c78 at calltrap+0x8 >>> #6 0xffffffff8045ddb8 at handleevents+0x188 >>> #7 0xffffffff8045ea3e at timercb+0x24e >>> #8 0xffffffff807ca9eb at lapic_handle_timer+0x9b >>> #9 0xffffffff8077b9b1 at Xtimerint+0xb1 >>> Uptime: 2h28m57s >>> Dumping 12829 out of 131023 >>> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% >>> >>> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >>> 55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" >>> (offsetof(struct pcpu, >>> (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >>> #1  doadump (textdump=) >>>     at /usr/src/sys/kern/kern_shutdown.c:399 >>> #2  0xffffffff804c428c in kern_reboot (howto=260) >>>     at /usr/src/sys/kern/kern_shutdown.c:487 >>> #3  0xffffffff804c46fe in vpanic (fmt=0xffffffff807e1276 "%s", >>>     ap=) at /usr/src/sys/kern/kern_shutdown.c:920 >>> #4  0xffffffff804c4503 in panic (fmt=) >>>     at /usr/src/sys/kern/kern_shutdown.c:844 >>> #5  0xffffffff807a2195 in trap_fatal (frame=0xfffffe0434de4d50, >>> eva=0) >>>     at /usr/src/sys/amd64/amd64/trap.c:946 >>> #6  0xffffffff807a21ef in trap_pfault (frame=0xfffffe0434de4d50, >>>     usermode=false, signo=, ucode=) >>>     at /usr/src/sys/amd64/amd64/trap.c:765 >>> #7  >>> #8  0xffffffff804e0db4 in callout_process >>> (now=now@entry=38385536922300) >>>     at /usr/src/sys/kern/kern_timeout.c:488 >>> #9  0xffffffff8045ddb8 in handleevents (now=now@entry=38385536922300, >>>     fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 >>> #10 0xffffffff8045ea3e in timercb (et=0xffffffff80d475e0 , >>>     arg=) at /usr/src/sys/kern/kern_clocksource.c:357 >>> #11 0xffffffff807ca9eb in lapic_handle_timer >>> (frame=0xfffffe0434de4f40) >>>     at /usr/src/sys/x86/x86/local_apic.c:1364 >>> #12 >>> #13 0x000000080df42bb6 in ?? () >>> Backtrace stopped: Cannot access memory at address 0x7ffffdef2c90 >>> (kgdb) >>> >>> ------------------------------------------------------------------------ >>> ' I got a new crash on a today's current: ⯠more core.txt.1 borg.lerctr.org dumped core - see /var/crash/vmcore.1 Thu Dec 16 17:01:37 CST 2021 FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-n251748-c610426c4de: Thu Dec 16 09:22:52 CST 2021 root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL amd64 panic: page fault GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel... Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 20 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff804e0a34 stack pointer = 0x0:0xfffffe03441a0e10 frame pointer = 0x0:0xfffffe03441a0e70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 86479 (c++) trap number = 12 panic: page fault cpuid = 0 time = 1639694532 KDB: stack backtrace: #0 0xffffffff8050f9e5 at kdb_backtrace+0x65 #1 0xffffffff804c430f at vpanic+0x17f #2 0xffffffff804c4183 at panic+0x43 #3 0xffffffff807a2195 at trap_fatal+0x385 #4 0xffffffff807a21ef at trap_pfault+0x4f #5 0xffffffff80779728 at calltrap+0x8 #6 0xffffffff8045da08 at handleevents+0x188 #7 0xffffffff8045e68e at timercb+0x24e #8 0xffffffff807ca9eb at lapic_handle_timer+0x9b #9 0xffffffff8077b461 at Xtimerint+0xb1 Uptime: 7h7m44s Dumping 13614 out of 131023 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff804c3f0c in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:487 #3 0xffffffff804c437e in vpanic (fmt=0xffffffff807e1291 "%s", ap=) at /usr/src/sys/kern/kern_shutdown.c:920 #4 0xffffffff804c4183 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:844 #5 0xffffffff807a2195 in trap_fatal (frame=0xfffffe03441a0d50, eva=0) at /usr/src/sys/amd64/amd64/trap.c:946 #6 0xffffffff807a21ef in trap_pfault (frame=0xfffffe03441a0d50, usermode=false, signo=, ucode=) at /usr/src/sys/amd64/amd64/trap.c:765 #7 #8 0xffffffff804e0a34 in callout_process (now=now@entry=110228055503582) at /usr/src/sys/kern/kern_timeout.c:488 #9 0xffffffff8045da08 in handleevents (now=now@entry=110228055503582, fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 #10 0xffffffff8045e68e in timercb (et=0xffffffff80d47660 , arg=) at /usr/src/sys/kern/kern_clocksource.c:357 #11 0xffffffff807ca9eb in lapic_handle_timer (frame=0xfffffe03441a0f40) at /usr/src/sys/x86/x86/local_apic.c:1364 #12 #13 0x0000000003883679 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffff6f20 (kgdb) Core is ALSO available Boot Env: ⯠bectl list BE Active Mountpoint Space Created 14-2021-10-26_1554 - - 1.82G 2021-10-26 15:54 14-2021-11-03-1800 - - 162M 2021-11-03 18:00 14-2021_10_19-1900 - - 1.80G 2021-10-19 18:57 14-2021_10_20-0800 - - 1.94G 2021-10-20 08:01 14-2021_11_18-1241 - - 1.86G 2021-11-18 11:41 14-2021_11_20-1417 - - 1.85G 2021-11-20 13:17 14-2021_11_23-1111 - - 1.87G 2021-11-23 11:11 14-2021_11_25-1312 - - 1.87G 2021-11-25 12:12 14-2021_12_04-2220 - - 13.7M 2021-12-04 22:20 14-2021_12_07-1217 - - 1.87G 2021-12-07 12:17 14-2021_12_09-1957 - - 1.89G 2021-12-09 19:57 14-2021_12_14-0224 - - 1.82G 2021-12-14 02:24 14-2021_12_15-0923 - - 18.6M 2021-12-15 09:23 14-2021_12_15-2133 - - 1.83G 2021-12-15 21:33 14-2021_12_15-2257 - - 1.82G 2021-12-15 22:57 14-2021_12_16-0924 NR / 129G 2021-12-16 09:24 14-main-first - - 2.69G 2021-10-02 20:11 14.0-CURRENT-2021-10-04_1051 - - 16.6M 2021-10-04 10:51 14.0-CURRENT_2021-10-06_184540 - - 12.9M 2021-10-06 18:46 14.0-CURRENT_2021-11-04_091349 - - 17.7M 2021-11-04 09:13 14.0-CURRENT_2021-12-05_204803 - - 10.6M 2021-12-05 20:48 r363086 - - 4.19G 2020-07-10 15:37 what else can I supply? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Fri Dec 17 03:16:21 2021 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 DB16518F92E9 for ; Fri, 17 Dec 2021 03:16:22 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFYzV1RLyz4Z7s; Fri, 17 Dec 2021 03:16:22 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZdVr4c33ku13UDD7gLE/xSnFhkN9pr8nK3cqOpncz+Q=; b=Nju3+cTmrfVFjvgvdO7JTyG+ig FdLcs/QXuqQG31rCVhs6lAR7SByuEtYLaZa1ugr67+lwd+yCrANIZsllcsLSIBeUzOAUEpBonUvBu yhK/xxhos/7+c0/vqyxzdCPFy6P9xajR4gSRdiWjXl60/CZ8uCcGHgENW9Imtqp00yboBzVdt0QRS uw/Pu+oKPRobZDWvp6Hc3q+QQu9q2DmfIfym6evk8LpBSiQkWovPiTwUMDcpxlT+Ra3ETCxZRN6kT XNMmEZP/XId+lOenGLxmKKt3aRiFbrHnJJljD0bqbedRpYsStwkOix2rMZ8NQBPFB+CSL/Kkty38H EJLcw+ew==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:22628 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1my3jJ-000GFA-Fd; Thu, 16 Dec 2021 21:16:21 -0600 Received: from 76-250-255-117.lightspeed.austtx.sbcglobal.net ([76.250.255.117]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 16 Dec 2021 21:16:21 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Thu, 16 Dec 2021 21:16:21 -0600 From: Larry Rosenman To: Alexander Motin Cc: Freebsd current Subject: Re: Panic: Page Fault in Kernel: Yesterday's CURRENT In-Reply-To: References: <3d1b5249a2c51670de496fad9e8b054c@lerctr.org> <9852ae04-6dd0-1cd4-13fe-e97c68e71b37@FreeBSD.org> Message-ID: <35ce3d9ab427375f09b44c2ced1e1704@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JFYzV1RLyz4Z7s X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=Nju3+cTm; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 12/16/2021 9:03 pm, Larry Rosenman wrote: > On 12/10/2021 10:43 am, Larry Rosenman wrote: >> 14-2021_12_07-1217 - - 1.87G 2021-12-07 >> 12:17 >> 14-2021_12_09-1957 NR / 121G 2021-12-09 >> 19:57 >> >> If that's any help >> >> On 12/10/2021 10:36 am, Alexander Motin wrote: >>> Hi Larry, >>> >>> This looks like some use-after-free or otherwise corrupted callout >>> structure. Unfortunately the backtrace does not tell what was the >>> callout. When was the previous update to look what could change? >>> >>> On 10.12.2021 11:24, Larry Rosenman wrote: >>>> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15 >>>> main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021     >>>> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL  >>>> amd64 >>>> >>>> VMCORE *IS* available. >>>> >>>> >>>> >>>> >>>> Unread portion of the kernel message buffer: >>>> kernel trap 12 with interrupts disabled >>>> >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 0; apic id = 20 >>>> fault virtual address   = 0x0 >>>> fault code              = supervisor write data, page not present >>>> instruction pointer     = 0x20:0xffffffff804e0db4 >>>> stack pointer           = 0x0:0xfffffe0434de4e10 >>>> frame pointer           = 0x0:0xfffffe0434de4e70 >>>> code segment            = base 0x0, limit 0xfffff, type 0x1b >>>>                         = DPL 0, pres 1, long 1, def32 0, gran 1 >>>> processor eflags        = resume, IOPL = 0 >>>> current process         = 82990 (c++) >>>> trap number             = 12 >>>> panic: page fault >>>> cpuid = 0 >>>> time = 1639111198 >>>> KDB: stack backtrace: >>>> #0 0xffffffff8050fc95 at kdb_backtrace+0x65 >>>> #1 0xffffffff804c468f at vpanic+0x17f >>>> #2 0xffffffff804c4503 at panic+0x43 >>>> #3 0xffffffff807a2195 at trap_fatal+0x385 >>>> #4 0xffffffff807a21ef at trap_pfault+0x4f >>>> #5 0xffffffff80779c78 at calltrap+0x8 >>>> #6 0xffffffff8045ddb8 at handleevents+0x188 >>>> #7 0xffffffff8045ea3e at timercb+0x24e >>>> #8 0xffffffff807ca9eb at lapic_handle_timer+0x9b >>>> #9 0xffffffff8077b9b1 at Xtimerint+0xb1 >>>> Uptime: 2h28m57s >>>> Dumping 12829 out of 131023 >>>> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% >>>> >>>> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >>>> 55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" >>>> (offsetof(struct pcpu, >>>> (kgdb) #0  __curthread () at >>>> /usr/src/sys/amd64/include/pcpu_aux.h:55 >>>> #1  doadump (textdump=) >>>>     at /usr/src/sys/kern/kern_shutdown.c:399 >>>> #2  0xffffffff804c428c in kern_reboot (howto=260) >>>>     at /usr/src/sys/kern/kern_shutdown.c:487 >>>> #3  0xffffffff804c46fe in vpanic (fmt=0xffffffff807e1276 "%s", >>>>     ap=) at /usr/src/sys/kern/kern_shutdown.c:920 >>>> #4  0xffffffff804c4503 in panic (fmt=) >>>>     at /usr/src/sys/kern/kern_shutdown.c:844 >>>> #5  0xffffffff807a2195 in trap_fatal (frame=0xfffffe0434de4d50, >>>> eva=0) >>>>     at /usr/src/sys/amd64/amd64/trap.c:946 >>>> #6  0xffffffff807a21ef in trap_pfault (frame=0xfffffe0434de4d50, >>>>     usermode=false, signo=, ucode=) >>>>     at /usr/src/sys/amd64/amd64/trap.c:765 >>>> #7  >>>> #8  0xffffffff804e0db4 in callout_process >>>> (now=now@entry=38385536922300) >>>>     at /usr/src/sys/kern/kern_timeout.c:488 >>>> #9  0xffffffff8045ddb8 in handleevents >>>> (now=now@entry=38385536922300, >>>>     fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 >>>> #10 0xffffffff8045ea3e in timercb (et=0xffffffff80d475e0 , >>>>     arg=) at /usr/src/sys/kern/kern_clocksource.c:357 >>>> #11 0xffffffff807ca9eb in lapic_handle_timer >>>> (frame=0xfffffe0434de4f40) >>>>     at /usr/src/sys/x86/x86/local_apic.c:1364 >>>> #12 >>>> #13 0x000000080df42bb6 in ?? () >>>> Backtrace stopped: Cannot access memory at address 0x7ffffdef2c90 >>>> (kgdb) >>>> >>>> ------------------------------------------------------------------------ >>>> > ' > > I got a new crash on a today's current: > ⯠more core.txt.1 > borg.lerctr.org dumped core - see /var/crash/vmcore.1 > > Thu Dec 16 17:01:37 CST 2021 > > FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #22 > main-n251748-c610426c4de: Thu Dec 16 09:22:52 CST 2021 > root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL > amd64 > > panic: page fault > > GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] > Copyright (C) 2021 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-portbld-freebsd14.0". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /boot/kernel/kernel... > Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... > > Unread portion of the kernel message buffer: > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 20 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0xffffffff804e0a34 > stack pointer = 0x0:0xfffffe03441a0e10 > frame pointer = 0x0:0xfffffe03441a0e70 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 86479 (c++) > trap number = 12 > panic: page fault > cpuid = 0 > time = 1639694532 > KDB: stack backtrace: > #0 0xffffffff8050f9e5 at kdb_backtrace+0x65 > #1 0xffffffff804c430f at vpanic+0x17f > #2 0xffffffff804c4183 at panic+0x43 > #3 0xffffffff807a2195 at trap_fatal+0x385 > #4 0xffffffff807a21ef at trap_pfault+0x4f > #5 0xffffffff80779728 at calltrap+0x8 > #6 0xffffffff8045da08 at handleevents+0x188 > #7 0xffffffff8045e68e at timercb+0x24e > #8 0xffffffff807ca9eb at lapic_handle_timer+0x9b > #9 0xffffffff8077b461 at Xtimerint+0xb1 > Uptime: 7h7m44s > Dumping 13614 out of 131023 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" > (offsetof(struct pcpu, > (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > #1 doadump (textdump=) > at /usr/src/sys/kern/kern_shutdown.c:399 > #2 0xffffffff804c3f0c in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:487 > #3 0xffffffff804c437e in vpanic (fmt=0xffffffff807e1291 "%s", > ap=) at /usr/src/sys/kern/kern_shutdown.c:920 > #4 0xffffffff804c4183 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:844 > #5 0xffffffff807a2195 in trap_fatal (frame=0xfffffe03441a0d50, eva=0) > at /usr/src/sys/amd64/amd64/trap.c:946 > #6 0xffffffff807a21ef in trap_pfault (frame=0xfffffe03441a0d50, > usermode=false, signo=, ucode=) > at /usr/src/sys/amd64/amd64/trap.c:765 > #7 > #8 0xffffffff804e0a34 in callout_process > (now=now@entry=110228055503582) > at /usr/src/sys/kern/kern_timeout.c:488 > #9 0xffffffff8045da08 in handleevents (now=now@entry=110228055503582, > fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 > #10 0xffffffff8045e68e in timercb (et=0xffffffff80d47660 , > arg=) at /usr/src/sys/kern/kern_clocksource.c:357 > #11 0xffffffff807ca9eb in lapic_handle_timer (frame=0xfffffe03441a0f40) > at /usr/src/sys/x86/x86/local_apic.c:1364 > #12 > #13 0x0000000003883679 in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffffff6f20 > (kgdb) > > > Core is ALSO available > > Boot Env: > ⯠bectl list > BE Active Mountpoint Space Created > 14-2021-10-26_1554 - - 1.82G 2021-10-26 15:54 > 14-2021-11-03-1800 - - 162M 2021-11-03 18:00 > 14-2021_10_19-1900 - - 1.80G 2021-10-19 18:57 > 14-2021_10_20-0800 - - 1.94G 2021-10-20 08:01 > 14-2021_11_18-1241 - - 1.86G 2021-11-18 11:41 > 14-2021_11_20-1417 - - 1.85G 2021-11-20 13:17 > 14-2021_11_23-1111 - - 1.87G 2021-11-23 11:11 > 14-2021_11_25-1312 - - 1.87G 2021-11-25 12:12 > 14-2021_12_04-2220 - - 13.7M 2021-12-04 22:20 > 14-2021_12_07-1217 - - 1.87G 2021-12-07 12:17 > 14-2021_12_09-1957 - - 1.89G 2021-12-09 19:57 > 14-2021_12_14-0224 - - 1.82G 2021-12-14 02:24 > 14-2021_12_15-0923 - - 18.6M 2021-12-15 09:23 > 14-2021_12_15-2133 - - 1.83G 2021-12-15 21:33 > 14-2021_12_15-2257 - - 1.82G 2021-12-15 22:57 > 14-2021_12_16-0924 NR / 129G 2021-12-16 09:24 > 14-main-first - - 2.69G 2021-10-02 20:11 > 14.0-CURRENT-2021-10-04_1051 - - 16.6M 2021-10-04 10:51 > 14.0-CURRENT_2021-10-06_184540 - - 12.9M 2021-10-06 18:46 > 14.0-CURRENT_2021-11-04_091349 - - 17.7M 2021-11-04 09:13 > 14.0-CURRENT_2021-12-05_204803 - - 10.6M 2021-12-05 20:48 > r363086 - - 4.19G 2020-07-10 15:37 > > what else can I supply? FTR Both crashes were during LONG poudriere runs rebuilding all 800+ ports I use after a FreeBSD_Version bump. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Fri Dec 17 16:09:38 2021 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 5304818F8A5C for ; Fri, 17 Dec 2021 16:09:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFv7z0vFFz4R6M for ; Fri, 17 Dec 2021 16:09:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639757384; bh=Hs7F5FzkWNLEuPOUZdA+z0Jm5k0VEqvArWiiHSI7pxY=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=LIS5mc7u8ZCV2Eu++krmraQeZejkUdFNYS5aQ0aJiL2fpQ/M4xJ+Tcecuv0oiSvuDq38QynTWyx/r7FCiJY4Cdc2JUdeQ3D+ZwHmZsywFJtoJAXlWdtPvQUp2VSi4e2YFJU3nAB3v4nvgM4rFmKl4fdU5vMVNDuduoO6zjYwEkFvY+iWqIsXq95vCUN8DCkUs8msfoMIAPH0ACTrTKVKVywts1nIqgL1HZIQkmRExED4OOjOGZTIgmqo7INnR+l2M/itMwhDd8pOyJE3DqvVy77RftgqnLMFaWwlRbjTHsP+xMtpHoVq2MAh+7+N+jHLVaYnZNWsULwdsphbhhh5XQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639757384; bh=s3T+nwHCJ5sMcNxqIqoCm/sRU18M1FFGHNpM12SQBrV=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=tSHv+GotRjdUcC+cMTrEgMLEkVsX2fSzmE6IzF0PGtW9pwfYxKhs4tNIkS6gLvgxLC443o0RaS1/Pa0+rLqw+vYWqYxQ4q2BgCCO99C7mhA9UJktKuKLFb6GFsPfhIrZMeJFBpf+QSiFWjV73QCFtYbWTKDCN4A6vI8GOEBc3SfMJ2t7GHiv3gRXpuIr8w3xSW/8X84ebJ3YM1XmpWlyI8bd6Yq9c35DM09pFzU+vsDOHAJD2yTX7gObAeHSMHj8ajCrk8kpy3j5wZR3OxmWGDZPlHfA+hMBZI/ctw7Eb+hJZxPvczwyP5liV+lUQe8Ysouv6RVGIL3dKBJyG0VQXw== X-YMail-OSG: eRpoINIVM1k_GIMeSpNI.kE6jJtdWMVVxuLl2g0yRVwOo9.pPwQWueHEs8DQkZJ y5C7vHewBO3IGD2i5rFNOiivO29eZA5C9U5g4.B6zfc_TRepOUbD18VfcxP92AXwryqEgo5s1yRp 0NM_ZsmjXrIYPkKlJLmQ2xOngLtqWqYRCmhRrATz2.N3n4FG3TQa0XFIGWTwJylnt_Ml0QB7rfwP y1ArM83w66Tk4pTF.tIDLBpf6Ix8PqoZlgGKBuNvp5nmizUhljhoCAPywOnk9KgT0E9KJhzOM_ng 3R236w8KLRA8IwsWzGjdTWM.KEaHfFvvhr5Ss_t.UCi24Q7B4tyhuuR1xqTEsYxH9LHG.BuN7nK1 jnDuro_l91B3aQz8knBcZazMEMT0eCk8X6B._5LnipyGBNpPdMa2Kquz2SP2PbvfKHLvuLkB1zUC d1_Mkm3VhBPFdJi0V7IvNcvk5ue9EABvmQPfXxAb6tzBYxj94e1ggp3UReapijiK3Vn5JxySLwcX AdO48kgC0b3kSDJPMbMlv0V8Zv4NDfLA8bFSm4cCFoJbKLkXKN0zry5XmL45ePcilYG.3wkBhuzd jlsdb.egDYpcYr49W3OuEcFQFjMmBMA_0o2K2GWCLgKy8s6jwZgy1ksDsYX42PZR4qqJiy3KucHd yJK.aVFZBt.08wYZr18MiweqXcKdf6gfXKjNOBwDrjEtwkc1Lv5ugFu5NdtmudyIphynHGnbEp6y M10a9PXpg18JbQ59.EoJ7dJ1cUcFsDTQ4gI_v3pHuSe8zcQtQH_ZZC0fXIabcV7h_m8ftTB2XU5k QsTCky0LAhrrlGiCreJAQOjI5aqDJaWc4FgqGoFgpVDTdo1HitkRHKTWAiewUH8KFBDw0oecAN3u EMmM8qqdLJSg4GbRtQw.qTUklkZG8tabRKLhWhcOGzt_iC6teOb02jEDsZIcAU8FGvpzKFoRL81X kIaOrPbwHpLA3YVA1_h_aG8oX_W.gC6QQb5.4rW_RhKbY3IK58Ny7K4eQecnveQ9J_YeQH3JAVBt sgkCqEzdU6Ajzlx7f_iU8ON3_wyq0VknleRL1hajht9EZ9BKbi4JwoU9aEviikAo6V90x8eGq_wY yJjZrtjvlOCUh0tMPrdyT2uFc5Bzusrtio9LIqMo.cgK.lluTFQ.czaJu1GqILDwi3b_P52agYsC qhdTIQ6O79E84OQBE8Tar_WtDc5gl3lvQ_dEppE5xxxqEZVBNr69XjNnAJLdOAq2a5Y1_tYFSfs3 DGC_6364Jr6QKyV2c65kX_edbLO4kpxbQ5AAYWvBjD6JlbaB1qeWzqWpasUaLW7eggKaCoVpWk9P MOcEuJjgkFVAcXYpEHIB98ThVT_GZ0z4k.AmSJuObGR2P.k0CGMS7OHzp1z5Wp8PmmoqWxcWGI3v c5LjBn02HxzOeNP95kHifggCQ1tVxXcbMLjlYtQB38RyQjN.iVsWP5Nwt8pucDAV9ysnwrXG6PBI 38WZ_he.gqKkUQGsoW1OwG1ADXSUQWhcWnsiiEzqqzMLlz_kMlrmVmiOPe3s5QiHHn5sTR7omT6t eEkHQzbp1BgD8wLAGZNqu8kQ5e0KgkvamMwGnYqV5_3uc7ENEGU0H.WyWhNnW.nQqNZ_uL1.PNIi XgtLnu0_ABo07Sh4fO0F0lsmtCDXnPCbYdKq_aVs2nU2D4_Z5b0UkrxbYergu0ohp4YA3aocU.tv 6I54_6DbalMRly7m4Ev85k0abtxdIdIywkp_wdrIWsZEy9ln.YhwA8mxKcKT0b3i2dS.gsp4CEzr djIO8EkJo8D765A8B94FSnfIdWcfI_FnNY.Bwy0NEVmuixm5iH7Va6ZtsW2awhfr_JK7oLW9Yj9z BtNuA6xlvmjxai5j3n9isIxWKBXx_7dA4tlhSOd80VmAdYOpudJ82.nhRYv5IpVVut6uN4LtrToR 8IocxHaAohisG.KmnecouF4B5KI.y5bSgGCmvRPLsCI7ecUoJqERjVbqT6PlxgUmiPtKDutjFKk1 _8NHn8HIFzGEm9Z0kA_UJ_pdkKFpb6Dn7RhadTE7hQVo9bmMpV9VkcUVT9cqPqJobU6EasaaDLHQ F7.Ns4tq5uxdAK6bBUJnT_87vNH8pnd8CBAZ36GifiILf74rLE5OZGsrcdhs.kkYarYBdiRmWi7d 8FPBUCXJP_S_sATHXKOwiikkWbumPsAEdUX21k4BXkdE9G4ZujtvQdTH4cGTmZmWbZNDq2mbyisO 6neEE5jtubVukiJeK2g0FKgso6MKG3qslvRTPoJZzBNQnlpHkrsdavUp.4Wfj2P_F2.2JHn5C1Dl K7nPGPUlMGURNrqrWrEQv X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Dec 2021 16:09:44 +0000 Received: by kubenode502.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bfc8781487c780f5d68af446b1e707c9; Fri, 17 Dec 2021 16:09:39 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 30780c3f584a - stable/13 - README.md: correct GPL expansion Message-Id: Date: Fri, 17 Dec 2021 08:09:38 -0800 To: Ed Maste , Baptiste Daroussin , freebsd-current , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4JFv7z0vFFz4R6M X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=LIS5mc7u; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N From: Ed Maste wrote on Date: Fri, 17 Dec 2021 08:42:49 -0500 : > On Fri, 17 Dec 2021 at 05:12, Baptiste Daroussin = wrote: > > > > > -gnu Various commands and libraries under the GNU Public = License. > > > - Please see gnu/COPYING* for more information. > > > +gnu Various commands and libraries under the GNU General = Public > > > + License. Please see gnu/COPYING* for more = information. > > > > Which is wrong ;) > > > > There no library left under the GNU general public license, only one = under LGPL > > which will be soon gone. > > > > As for the commands, various is now a bit overrated, only diff3 is = under GPL >=20 > Good point, in main right now we have LGPL dialog and libdialog, and > GPL diff3, with additional ones in the stable branches. I'm confused, beyond just LGPL claims in the (fairly current) source code, but GPL more generally: # grep -rl "SPDX.*GPL" /usr/main-src/ /usr/main-src/sys/compat/linuxkpi/common/include/linux/net_dim.h /usr/main-src/sys/ofed/include/rdma/signature.h /usr/main-src/sys/ofed/include/rdma/ib_smi.h /usr/main-src/sys/ofed/include/rdma/rdmavt_qp.h /usr/main-src/sys/ofed/include/rdma/opa_smi.h . . . /usr/main-src/sys/ofed/drivers/infiniband/util/madeye.c /usr/main-src/sys/ofed/drivers/infiniband/core/ib_cq.c /usr/main-src/sys/ofed/drivers/infiniband/core/ib_uverbs_uapi.c /usr/main-src/sys/ofed/drivers/infiniband/core/ib_umem.c . . . /usr/main-src/sys/dev/isci/scil/sati_types.h /usr/main-src/sys/dev/isci/scil/sati_mode_sense_10.c /usr/main-src/sys/dev/isci/scil/sati_unmap.c /usr/main-src/sys/dev/isci/scil/scic_sds_stp_packet_request.c /usr/main-src/sys/dev/isci/scil/scic_sds_smp_request.h /usr/main-src/sys/dev/isci/scil/sati_translator_sequence.h /usr/main-src/sys/dev/isci/scil/scic_sds_stp_request.c /usr/main-src/sys/dev/isci/scil/sati_mode_sense.c . . . = /usr/main-src/sys/contrib/device-tree/Bindings/chrome/google,cros-ec-typec= .yaml /usr/main-src/sys/contrib/device-tree/Bindings/dsp/fsl,dsp.yaml = /usr/main-src/sys/contrib/device-tree/Bindings/reset/allwinner,sun6i-a31-c= lock-reset.yaml = /usr/main-src/sys/contrib/device-tree/Bindings/reset/brcm,bcm7216-pcie-sat= a-rescal.yaml = /usr/main-src/sys/contrib/device-tree/Bindings/reset/brcm,bcm6345-reset.ya= ml = /usr/main-src/sys/contrib/device-tree/Bindings/reset/brcm,bcm4908-misc-pci= e-reset.yaml . . . = /usr/main-src/sys/contrib/device-tree/include/dt-bindings/input/ti-drv260x= .h = /usr/main-src/sys/contrib/device-tree/include/dt-bindings/input/gpio-keys.= h = /usr/main-src/sys/contrib/device-tree/include/dt-bindings/input/cros-ec-ke= yboard.h /usr/main-src/sys/contrib/device-tree/include/dt-bindings/input/input.h = /usr/main-src/sys/contrib/device-tree/include/dt-bindings/input/atmel-maxt= ouch.h = /usr/main-src/sys/contrib/device-tree/include/dt-bindings/input/linux-even= t-codes.h . . . /usr/main-src/sys/contrib/device-tree/COPYING /usr/main-src/sys/contrib/device-tree/src/openrisc/or1klitex.dts /usr/main-src/sys/contrib/device-tree/src/openrisc/or1ksim.dts /usr/main-src/sys/contrib/device-tree/src/xtensa/lx200mx.dts /usr/main-src/sys/contrib/device-tree/src/xtensa/kc705_nommu.dts /usr/main-src/sys/contrib/device-tree/src/xtensa/ml605.dts /usr/main-src/sys/contrib/device-tree/src/xtensa/virt.dts /usr/main-src/sys/contrib/device-tree/src/xtensa/csp.dts . . . /usr/main-src/sys/contrib/dev/iwlwifi/iwl-op-mode.h /usr/main-src/sys/contrib/dev/iwlwifi/iwl-io.h /usr/main-src/sys/contrib/dev/iwlwifi/iwl-fh.h /usr/main-src/sys/contrib/dev/iwlwifi/iwl-eeprom-read.c /usr/main-src/sys/contrib/dev/iwlwifi/fw/dbg.h /usr/main-src/sys/contrib/dev/iwlwifi/fw/pnvm.c . . . /usr/main-src/sys/fs/fuse/fuse_kernel.h /usr/main-src/sys/gnu/gcov/gcc_4_7.c /usr/main-src/sys/gnu/gcov/gcov_fs.c /usr/main-src/sys/dts/arm/qcom-ipq4018-rt-ac58u.dts /usr/main-src/sys/dts/include/dt-bindings/soc/qcom,tcsr.h /usr/main-src/sys/cam/scsi/scsi_ses.h /usr/main-src/sys/cam/scsi/scsi_enc.h /usr/main-src/share/man/man4/pvscsi.4 /usr/main-src/share/man/man4/vmci.4 For reference: # cd /usr/main-src/ # ~/fbsd-based-on-what-commit.sh=20 branch: main merge-base: 22c4ab6cb015dc99eb82504e5fd957662cded3c3 merge-base: CommitDate: 2021-12-07 19:29:26 +0000 22c4ab6cb015 (HEAD -> main, freebsd/main, freebsd/HEAD) sys/_bitset.h: = Fix fall-out from commit 5e04571cf3c n251456 (--first-parent --count for merge-base) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 17 17:44:20 2021 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 222E218EA37B for ; Fri, 17 Dec 2021 17:44:34 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFxFF3gYxz4fFx for ; Fri, 17 Dec 2021 17:44:33 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: by mail-ed1-x535.google.com with SMTP id z9so10731579edb.5 for ; Fri, 17 Dec 2021 09:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=XSiqPvWO0h2jK2+md2//KgIJD2cXNjWvL+5Phrrk3VE=; b=ULdX2aq5tSUtRbyDLO8M5S3q8B0jUYS08xKd3t0qg17ROVlwwwJ6uK2uyb8vgW+zF+ k7wHH6tJhBJOieLmFy5cuGINh8Y1M0S6DpPwUNALh3LVv/jiHbnt5y1jsUqVRRurHyrK YEsgYaQ9wKFWe+HrNFisa6zFly7vyNxT1l4U8rz7WZHZmY7trJnQe6iwUQomOxij1y9p rT4whwZLjdqwqPVCBknbma8kMtmDvbgi0U0kPqbYRrFzpLtTojEU3+4jR93Ex8wCG56+ 2JGRTr1X23i2nTi4lSOtbNYPnPc/jT4kYWNUED8aXIrxoFuIUR3x/SIaOe5ULQTiQn5N j0Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XSiqPvWO0h2jK2+md2//KgIJD2cXNjWvL+5Phrrk3VE=; b=BsOtYYD4poqMk5/e9t1Z2g/X4mUY51byO66QXkXY6zDMSpKhzAKiVq3Y/b7ibedp0Z DRUDFWH6vsIITLxMQ/i6P/OSaPKE+wI2/7oXkpqDBdObu0XDlwIgFhAiRYgbywRWiG35 ZkHX2NFHzk0SdjSJglXYGWdUgYxhWojXSdR0UPAGuMAJkn3rwiutd+9BmRyOEVJzlA+7 pfFNVH3fJChhqQS8x/gH89sC+Lo+81XaWiJg5sXHUSQb7oj0D+doZVd9GvWhgYdbfSkc 4maE9SW6QFF8MkAV1ArjbPYKe8Z+97MzBPGQ+aIAHoM8sykUDVAmTflYnJnY8vqJfK9s KZtA== X-Gm-Message-State: AOAM533INmDKyGBUo7+INI/gn0whk+bgwlt+vRjboc5Nkvm8dMqrnXkN l+4G9kCHYe/3hGMpBJypKMIhNGD6xEn04xpS1+UVzPrp0e8= X-Google-Smtp-Source: ABdhPJzBxPELzK2NLIXRGKabGb3M2bnlHNuPoJ6ycoEcoHatbF5rhXOfcBGjdL6XF8aCM5t9vwReBph925/L4hlZpao= X-Received: by 2002:aa7:c497:: with SMTP id m23mr3913897edq.65.1639763072308; Fri, 17 Dec 2021 09:44:32 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Chuck Tuffli Date: Fri, 17 Dec 2021 09:44:20 -0800 Message-ID: Subject: build failure on -current To: FreeBSD-Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JFxFF3gYxz4fFx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ULdX2aq5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ctuffli@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=ctuffli@gmail.com X-Spamd-Result: default: False [-2.05 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.95)[0.946]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N When building current from git, I keep hitting the error below. This is with meta-mode, but I've also tried deleting the object directory. The system also has a couple of tweaks to src-env.conf that were an attempt to avoid building any (most?) of clang. Relevant system information: $ uname -mrsv FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT main-22c4ab6cb0 GENERIC amd64 $ cat /etc/src-env.conf WITH_META_MODE=YES WITHOUT_CLANG=YES WITHOUT_CLANG_BOOTSTRAP=YES $ env MAKEOBJDIRPREFIX=$(realpath ../obj) make buildworld -j$(sysctl -n hw.ncpu) --- Core/ModuleList.o --- In file included from /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/lldb/source/Core/ModuleList.cpp:34: In file included from /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Driver/Driver.h:12: In file included from /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Basic/Diagnostic.h:17: /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Basic/DiagnosticIDs.h:71:10: fatal error: 'clang/Basic/DiagnosticCommonKinds.inc' file not found #include "clang/Basic/DiagnosticCommonKinds.inc" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. *** [Core/ModuleList.o] Error code 1 Where did I goof? TIA --chuck From nobody Fri Dec 17 18:54:35 2021 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 3149B18F94E9 for ; Fri, 17 Dec 2021 18:54:38 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFyp60L0fz4sYv for ; Fri, 17 Dec 2021 18:54:38 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-ed1-x52e.google.com with SMTP id y12so11323580eda.12 for ; Fri, 17 Dec 2021 10:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=7y06wug8AMlNqTDOsyn0FPDBHntFBZg3TqzRRfQVuDw=; b=kAxU099YfqtGj/hcQE4VJ3sOCeYrAcvcglNEFWOETWSCBTgEgoMnErPc9TEntM8aAS /lwAnt+mCI7za9nzKKiwakjuNGu4LZQsi+o9r9EzF3nevnYeMaBJv+Cl6vVMFv2+lIvH By0wwAWdMFMT16RsHUa6yiFTUqY19/fGlNcsTz0rjOfuWAZBfBs+lPZBf8unlp0T/1xO VSx6dzxQThHiI765QVbrLdVMK/9LVBCZ+s2B+W74VlluYsSKggQ/r5IVUSkfWoxL/wjX gQQfHxjKGhSwkOpHDBGTKsRfUFKRBX5M/2uLI5m6/2Vpt2xWaYE0nNzfkpqnsvLB5uGY ajZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=7y06wug8AMlNqTDOsyn0FPDBHntFBZg3TqzRRfQVuDw=; b=3j1VpPayglZHlqXgVI+E661FJG90kh8Oi9znvD399kQL0iPzRpUUrlp+Zz5BxTMfvD 7+6yJM5CYQF+uR0zyVUmz6tHlr3a9JwpVpU4LBeRUcDp267oSx3WB9d9r52hAwWGdRDX EeGf7Mm69Ph8SgPZ4Z00StApTW2gP3/wxgo6fjWsNRQdyBBpVVQq+/ftFjM/nYz6QWAc B2UKZOqrwXFksIbzkZDPubqTpz8VUuE/xqktte6KDIfLk8DXlTg9KLNHNUCwLxzcWNWD iXsJcSu5sk+BvJxhPCCcnBINzNhY4U4TTChWlaoEvnoVGtQf08NRcE6n2MWoozo1RoA2 8brw== X-Gm-Message-State: AOAM531DXCMxXSgPQO7IomSzcGUjTnBVLPvTBfMfuNxCi8vfDeHlLRmu l3WrvHCQWHKdfhBoJg9qC2A= X-Google-Smtp-Source: ABdhPJzIUOotPPAGoCI85qEE5PQuvEGRL6S6WLlO3y9ew2IMF3vvGGYg9dF7Ki0DjMd72xPN0m8tfw== X-Received: by 2002:a50:8d10:: with SMTP id s16mr4044623eds.305.1639767276218; Fri, 17 Dec 2021 10:54:36 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id gb42sm3095108ejc.49.2021.12.17.10.54.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Dec 2021 10:54:35 -0800 (PST) Date: Fri, 17 Dec 2021 19:54:35 +0100 From: Gary Jennejohn To: Chuck Tuffli Cc: FreeBSD-Current Subject: Re: build failure on -current Message-ID: <20211217195435.69a2fb55@ernst.home> In-Reply-To: References: Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JFyp60L0fz4sYv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 17 Dec 2021 09:44:20 -0800 Chuck Tuffli wrote: > When building current from git, I keep hitting the error below. This > is with meta-mode, but I've also tried deleting the object directory. > The system also has a couple of tweaks to src-env.conf that were an > attempt to avoid building any (most?) of clang. Relevant system > information: > > $ uname -mrsv > FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT main-22c4ab6cb0 GENERIC amd64 > $ cat /etc/src-env.conf > WITH_META_MODE=YES > WITHOUT_CLANG=YES > WITHOUT_CLANG_BOOTSTRAP=YES > $ env MAKEOBJDIRPREFIX=$(realpath ../obj) make buildworld -j$(sysctl -n hw.ncpu) > > --- Core/ModuleList.o --- > In file included from > /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/lldb/source/Core/ModuleList.cpp:34: > In file included from > /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Driver/Driver.h:12: > In file included from > /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Basic/Diagnostic.h:17: > /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Basic/DiagnosticIDs.h:71:10: > fatal error: 'clang/Basic/DiagnosticCommonKinds.inc' file not found > #include "clang/Basic/DiagnosticCommonKinds.inc" > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1 error generated. > *** [Core/ModuleList.o] Error code 1 > > Where did I goof? TIA > Do you need lldb? If not you could try adding WITHOUT_LLDB to src-env.conf and see what happens. -- Gary Jennejohn From nobody Fri Dec 17 19:36:33 2021 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 A46F01900F85 for ; Fri, 17 Dec 2021 19:36:37 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFzkX6gWjz3Ftv; Fri, 17 Dec 2021 19:36:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x736.google.com with SMTP id t83so3194315qke.8; Fri, 17 Dec 2021 11:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Z7nVJyGqdZJC4dn4UHM7SsY2UMzAWxgifJRZ0mUQBuY=; b=kChppqAEvnrLJkCv18YeaOudvmQtV0HWolcVuR5s5ctHougmGq56suu4ySZuw8vMyV 4cYOU7tXFSsI0y2YC4EfwU6LJ5SIKl27OMIx78HFwEFouUIJ9Ggvart5gCDAXytmaiAU 8Icvuz1MzsyvV9CAufJOMghvJKiSFqJpc5pGHsH7nwjqlrfcL4p2JoY3UWE+Zx9BNw7g N8nN/qGah8ppGwScv9lNxAQfp3nUn3UPsbr/0xj6845teyz5pQ2Jsrri0I2lp2Ily2lY vjqcFcgPlcDAOLGXtPqHkicuhUI3kDPL1YV3Q63F/kBwPn0r+Y2NLi3cxSUtiIJEUoZK 1RZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=Z7nVJyGqdZJC4dn4UHM7SsY2UMzAWxgifJRZ0mUQBuY=; b=XNwcyePOtxkLk9RAkOvx97unNgRDjW2Xj6/FS3Cdx6MfcO4t86ra2kSltc+RMffzEj ets2eHw1yjfkN7mpz9R87JqSYaryah0wL7cREheDyhVZ/JBAHNeRmGk8m7L3kNDlNZvf bo4yWr4CMtTQw72AsKN2j9eJNC4/CUlIJ6HiD7Mzo3ty+Dvq6zy7IbQNrucSCuawtmBc Xi+rXyPXIa+z521ViRi++aJ1MuifVqqAr3LoSp6wo7K/ue+efVQ1HAnKoTO79DTTj70m uQmPeyc+v4OlF8cMd667yNLCoKUIUCm9CLtpZihMLYshVRWxnpGIew4jESXiqLW41ih2 6SWw== X-Gm-Message-State: AOAM531lKDOPWysrrCXDuaKd6fQmziEvBNs6Oys7dmxqhR5p6i6921AL sWioFW/eyT4XtfFsvyMs561rlID+rtw= X-Google-Smtp-Source: ABdhPJyAplGpWae/lfTxRAHSppIrWW+871/vfPNUjxVw+B9uFoJjRX7XPjib6vgJiDKw2tKhxrMnyA== X-Received: by 2002:a37:745:: with SMTP id 66mr2796859qkh.11.1639769796407; Fri, 17 Dec 2021 11:36:36 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id x4sm7931807qtw.44.2021.12.17.11.36.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Dec 2021 11:36:35 -0800 (PST) Date: Fri, 17 Dec 2021 14:36:33 -0500 From: Mark Johnston To: Larry Rosenman Cc: Alexander Motin , Freebsd current Subject: Re: Panic: Page Fault in Kernel: Yesterday's CURRENT Message-ID: References: <3d1b5249a2c51670de496fad9e8b054c@lerctr.org> <9852ae04-6dd0-1cd4-13fe-e97c68e71b37@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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4JFzkX6gWjz3Ftv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=kChppqAE; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::736 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-0.08 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.38)[-0.383]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote: > 14-2021_12_07-1217 - - 1.87G 2021-12-07 12:17 > 14-2021_12_09-1957 NR / 121G 2021-12-09 19:57 > > If that's any help I can't tell what this is saying. A kernel built on the 7th does not crash, or...? Which revision did you update from before you started seeing crashes? >From a kgdb session it'd be useful to see output from (kgdb) frame 8 (kgdb) p/x *tmp to start. > On 12/10/2021 10:36 am, Alexander Motin wrote: > > Hi Larry, > > > > This looks like some use-after-free or otherwise corrupted callout > > structure. Unfortunately the backtrace does not tell what was the > > callout. When was the previous update to look what could change? > > > > On 10.12.2021 11:24, Larry Rosenman wrote: > >> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15 > >> main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021     > >> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL  > >> amd64 > >> > >> VMCORE *IS* available. > >> > >> > >> > >> > >> Unread portion of the kernel message buffer: > >> kernel trap 12 with interrupts disabled > >> > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 0; apic id = 20 > >> fault virtual address   = 0x0 > >> fault code              = supervisor write data, page not present > >> instruction pointer     = 0x20:0xffffffff804e0db4 > >> stack pointer           = 0x0:0xfffffe0434de4e10 > >> frame pointer           = 0x0:0xfffffe0434de4e70 > >> code segment            = base 0x0, limit 0xfffff, type 0x1b > >>                         = DPL 0, pres 1, long 1, def32 0, gran 1 > >> processor eflags        = resume, IOPL = 0 > >> current process         = 82990 (c++) > >> trap number             = 12 > >> panic: page fault > >> cpuid = 0 > >> time = 1639111198 > >> KDB: stack backtrace: > >> #0 0xffffffff8050fc95 at kdb_backtrace+0x65 > >> #1 0xffffffff804c468f at vpanic+0x17f > >> #2 0xffffffff804c4503 at panic+0x43 > >> #3 0xffffffff807a2195 at trap_fatal+0x385 > >> #4 0xffffffff807a21ef at trap_pfault+0x4f > >> #5 0xffffffff80779c78 at calltrap+0x8 > >> #6 0xffffffff8045ddb8 at handleevents+0x188 > >> #7 0xffffffff8045ea3e at timercb+0x24e > >> #8 0xffffffff807ca9eb at lapic_handle_timer+0x9b > >> #9 0xffffffff8077b9b1 at Xtimerint+0xb1 > >> Uptime: 2h28m57s > >> Dumping 12829 out of 131023 > >> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > >> > >> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > >> 55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" > >> (offsetof(struct pcpu, > >> (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > >> #1  doadump (textdump=) > >>     at /usr/src/sys/kern/kern_shutdown.c:399 > >> #2  0xffffffff804c428c in kern_reboot (howto=260) > >>     at /usr/src/sys/kern/kern_shutdown.c:487 > >> #3  0xffffffff804c46fe in vpanic (fmt=0xffffffff807e1276 "%s", > >>     ap=) at /usr/src/sys/kern/kern_shutdown.c:920 > >> #4  0xffffffff804c4503 in panic (fmt=) > >>     at /usr/src/sys/kern/kern_shutdown.c:844 > >> #5  0xffffffff807a2195 in trap_fatal (frame=0xfffffe0434de4d50, eva=0) > >>     at /usr/src/sys/amd64/amd64/trap.c:946 > >> #6  0xffffffff807a21ef in trap_pfault (frame=0xfffffe0434de4d50, > >>     usermode=false, signo=, ucode=) > >>     at /usr/src/sys/amd64/amd64/trap.c:765 > >> #7  > >> #8  0xffffffff804e0db4 in callout_process > >> (now=now@entry=38385536922300) > >>     at /usr/src/sys/kern/kern_timeout.c:488 > >> #9  0xffffffff8045ddb8 in handleevents (now=now@entry=38385536922300, > >>     fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 > >> #10 0xffffffff8045ea3e in timercb (et=0xffffffff80d475e0 , > >>     arg=) at /usr/src/sys/kern/kern_clocksource.c:357 > >> #11 0xffffffff807ca9eb in lapic_handle_timer > >> (frame=0xfffffe0434de4f40) > >>     at /usr/src/sys/x86/x86/local_apic.c:1364 > >> #12 > >> #13 0x000000080df42bb6 in ?? () > >> Backtrace stopped: Cannot access memory at address 0x7ffffdef2c90 > >> (kgdb) From nobody Fri Dec 17 20:07:25 2021 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 DB5821907507 for ; Fri, 17 Dec 2021 20:07:26 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JG0Q653Zjz3MVD; Fri, 17 Dec 2021 20:07:26 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=3eWsZdqS1ERFywv0Uw5HQB9uvrU1r7+VrT0nNic8EHM=; b=HMpgRCTPYkeqt1KSxqnCO8MPfF 0qtuLDopGb3jF4ynjVEJ4AU67pu65xiiP/6RYBvME/xBW1sjFhfYdaksvKNp4bPeVUgxJz6ze9qEm Grl60g2i3QFl7QhlOPWcDIijw23b/h6dzbcKFJJ0XoHKhcHq4gqwC3goeOPuWiCMOSzvkkzY4vwjz ulZsp+aO1zhTnLtj78joETqTJZcZCk6bIQxbLpprwh57AV2OnzwNzfGhf3t0F3JEOArF5fJd8LRde /k6YffiyWjNQASDJV9PRMxQnyqLiIyaKP0yW8P2vWEtiXPu+FjbZVRPn3Lj0aGrFvhTmqNeuQkrkK DjidBB8Q==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:36733 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1myJVl-0005eW-R4; Fri, 17 Dec 2021 14:07:25 -0600 Received: from 76-250-255-117.lightspeed.austtx.sbcglobal.net ([76.250.255.117]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 17 Dec 2021 14:07:25 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Fri, 17 Dec 2021 14:07:25 -0600 From: Larry Rosenman To: Mark Johnston Cc: Alexander Motin , Freebsd current Subject: Re: Panic: Page Fault in Kernel: Yesterday's CURRENT In-Reply-To: References: <3d1b5249a2c51670de496fad9e8b054c@lerctr.org> <9852ae04-6dd0-1cd4-13fe-e97c68e71b37@FreeBSD.org> Message-ID: X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JG0Q653Zjz3MVD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 12/17/2021 1:36 pm, Mark Johnston wrote: > On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote: >> 14-2021_12_07-1217 - - 1.87G 2021-12-07 >> 12:17 >> 14-2021_12_09-1957 NR / 121G 2021-12-09 >> 19:57 >> >> If that's any help > > I can't tell what this is saying. A kernel built on the 7th does not > crash, or...? Which revision did you update from before you started > seeing crashes? > > From a kgdb session it'd be useful to see output from > > (kgdb) frame 8 > (kgdb) p/x *tmp > > to start. > Correct, the 7th didn't panic, but the 9th did, and yesterday's too. Grrr ler in borg in /mnt🔒 on â˜ï¸ (us-east-1) ⯠kgdb -c /var/crash/vmcore.0 /mnt/boot/kernel/kernel GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /mnt/boot/kernel/kernel... (No debugging symbols found in /mnt/boot/kernel/kernel) Failed to open vmcore: /var/crash/vmcore.0: Permission denied (kgdb) bt No stack. quitb) ler in borg in /mnt🔒 on â˜ï¸ (us-east-1) took 6s ⯠sudo chmod +r /var/crash/* ler in borg in /mnt🔒 on â˜ï¸ (us-east-1) ⯠kgdb -c /var/crash/vmcore.0 /mnt/boot/kernel/kernel GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /mnt/boot/kernel/kernel... (No debugging symbols found in /mnt/boot/kernel/kernel) /wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: internal-error: void switch_to_thread(thread_info *): Assertion `thr != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n This is a bug, please report it. For instructions, see: . /wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: internal-error: void switch_to_thread(thread_info *): Assertion `thr != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n Command aborted. (kgdb) bt No thread selected. (kgdb) fr 8 No thread selected. (kgdb) >> On 12/10/2021 10:36 am, Alexander Motin wrote: >> > Hi Larry, >> > >> > This looks like some use-after-free or otherwise corrupted callout >> > structure. Unfortunately the backtrace does not tell what was the >> > callout. When was the previous update to look what could change? >> > >> > On 10.12.2021 11:24, Larry Rosenman wrote: >> >> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15 >> >> main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021     >> >> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL  >> >> amd64 >> >> >> >> VMCORE *IS* available. >> >> >> >> >> >> >> >> >> >> Unread portion of the kernel message buffer: >> >> kernel trap 12 with interrupts disabled >> >> >> >> >> >> Fatal trap 12: page fault while in kernel mode >> >> cpuid = 0; apic id = 20 >> >> fault virtual address   = 0x0 >> >> fault code              = supervisor write data, page not present >> >> instruction pointer     = 0x20:0xffffffff804e0db4 >> >> stack pointer           = 0x0:0xfffffe0434de4e10 >> >> frame pointer           = 0x0:0xfffffe0434de4e70 >> >> code segment            = base 0x0, limit 0xfffff, type 0x1b >> >>                         = DPL 0, pres 1, long 1, def32 0, gran 1 >> >> processor eflags        = resume, IOPL = 0 >> >> current process         = 82990 (c++) >> >> trap number             = 12 >> >> panic: page fault >> >> cpuid = 0 >> >> time = 1639111198 >> >> KDB: stack backtrace: >> >> #0 0xffffffff8050fc95 at kdb_backtrace+0x65 >> >> #1 0xffffffff804c468f at vpanic+0x17f >> >> #2 0xffffffff804c4503 at panic+0x43 >> >> #3 0xffffffff807a2195 at trap_fatal+0x385 >> >> #4 0xffffffff807a21ef at trap_pfault+0x4f >> >> #5 0xffffffff80779c78 at calltrap+0x8 >> >> #6 0xffffffff8045ddb8 at handleevents+0x188 >> >> #7 0xffffffff8045ea3e at timercb+0x24e >> >> #8 0xffffffff807ca9eb at lapic_handle_timer+0x9b >> >> #9 0xffffffff8077b9b1 at Xtimerint+0xb1 >> >> Uptime: 2h28m57s >> >> Dumping 12829 out of 131023 >> >> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% >> >> >> >> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >> >> 55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" >> >> (offsetof(struct pcpu, >> >> (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >> >> #1  doadump (textdump=) >> >>     at /usr/src/sys/kern/kern_shutdown.c:399 >> >> #2  0xffffffff804c428c in kern_reboot (howto=260) >> >>     at /usr/src/sys/kern/kern_shutdown.c:487 >> >> #3  0xffffffff804c46fe in vpanic (fmt=0xffffffff807e1276 "%s", >> >>     ap=) at /usr/src/sys/kern/kern_shutdown.c:920 >> >> #4  0xffffffff804c4503 in panic (fmt=) >> >>     at /usr/src/sys/kern/kern_shutdown.c:844 >> >> #5  0xffffffff807a2195 in trap_fatal (frame=0xfffffe0434de4d50, eva=0) >> >>     at /usr/src/sys/amd64/amd64/trap.c:946 >> >> #6  0xffffffff807a21ef in trap_pfault (frame=0xfffffe0434de4d50, >> >>     usermode=false, signo=, ucode=) >> >>     at /usr/src/sys/amd64/amd64/trap.c:765 >> >> #7  >> >> #8  0xffffffff804e0db4 in callout_process >> >> (now=now@entry=38385536922300) >> >>     at /usr/src/sys/kern/kern_timeout.c:488 >> >> #9  0xffffffff8045ddb8 in handleevents (now=now@entry=38385536922300, >> >>     fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 >> >> #10 0xffffffff8045ea3e in timercb (et=0xffffffff80d475e0 , >> >>     arg=) at /usr/src/sys/kern/kern_clocksource.c:357 >> >> #11 0xffffffff807ca9eb in lapic_handle_timer >> >> (frame=0xfffffe0434de4f40) >> >>     at /usr/src/sys/x86/x86/local_apic.c:1364 >> >> #12 >> >> #13 0x000000080df42bb6 in ?? () >> >> Backtrace stopped: Cannot access memory at address 0x7ffffdef2c90 >> >> (kgdb) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Sat Dec 18 01:07:57 2021 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 601AA18F5438 for ; Sat, 18 Dec 2021 01:08:03 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JG74y4Jtcz4jyP for ; Sat, 18 Dec 2021 01:08:02 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pg1-x532.google.com with SMTP id 200so3708121pgg.3 for ; Fri, 17 Dec 2021 17:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:reply-to:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=GdTVXZ9wdyHLrHgTrxCNBFPSOm0Xd/QFHO0IZRFhbR0=; b=FulEtFGcvS9tcnuuv6x/M5qd1v4snPUqsHPnK9y0Q5DYGG6+04sAW64Rn8oUOe5Jgi JXTvtLoOLd/abSpnM4rV1cq07zVejWMkh+7VG7Js90lL7LeFFTcCdJJdmr/4yH5DKiEl rSOBWXzTLQVsC+rEyt64x7UxG22a+75/RtAyQUEPjvImXIIQiVrLpOcLbt47PDwdvpRW LTsNrzRWIjZk+fB4ymCJCG7g652yTTgiWPAQDizYykpzkqdYwfELaqWNxQI+0BJ43UPg 7UuDehF6ArLd8wy/NWdVoGB8eOiXJo7+B+hqO4j0G/660vclZlQkJ492di4L2x29XvsS 2XcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :reply-to:subject:content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=GdTVXZ9wdyHLrHgTrxCNBFPSOm0Xd/QFHO0IZRFhbR0=; b=ZXzv2dUtNxvV4sxxXTX4DmvO5DAbi164sHU56JXRNB2WpCd9UGxxeMqxpTE/xk7L4Z i6VjzPRQtkK7WcrfkePlKgTOLdKwEelIc1AXzrCBY3vs6quwF+iqTdw+Ac8HE2kxKe1+ 6/9K7/gJrf+GIRlf2VVFTAgw448DotO6gnRvNFIFLfyA5rWY54fFwmVeQhR8PrL17Zlm PmGm1oZUZQVcoLPBZhf8oiIrFv6TBGZPlw0h+M0jF6D1AR73YnK04EZYpnXUezRa079j sIGueLUo3YuFzv3+E67dDdTcW1ACbU1uCku/0FjKn+R+J3nlMdZ0v44Jm0AeiTk2J1cC LwDw== X-Gm-Message-State: AOAM5335gvNPi0f/Kfad8mhm8RFP6YwGwkM40gDxYNVE3kamCvi7R95p Dv42kSzG38LoGsU3EXUKVJ0UuKYGcjQ= X-Google-Smtp-Source: ABdhPJxPK2n+3GWY/J+Husgjs8hCoAyiUpItoEMhh6MW3NLLBwJblcblG1hCG8FvI1DmM1lDsfd1vg== X-Received: by 2002:a05:6a00:a94:b0:44c:ecb2:6018 with SMTP id b20-20020a056a000a9400b0044cecb26018mr5631408pfl.57.1639789681661; Fri, 17 Dec 2021 17:08:01 -0800 (PST) Received: from ?IPV6:2403:5807:1b:1:79b8:94ce:e5d2:9f00? ([2403:5807:1b:1:79b8:94ce:e5d2:9f00]) by smtp.gmail.com with ESMTPSA id u9sm10921336pfi.23.2021.12.17.17.08.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Dec 2021 17:08:01 -0800 (PST) Message-ID: <36766038-69b9-bc09-27d8-c2169284ca81@FreeBSD.org> Date: Sat, 18 Dec 2021 12:07:57 +1100 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/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Thunderbird/97.0a1 Reply-To: koobs@FreeBSD.org Subject: Re: Deprecate and remove publickey(5) stuff Content-Language: en-US To: Emmanuel Vadot , freebsd-current@freebsd.org References: <20211215175508.d775a7254546c5be13dcd5a3@bidouilliste.com> From: Kubilay Kocak In-Reply-To: <20211215175508.d775a7254546c5be13dcd5a3@bidouilliste.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JG74y4Jtcz4jyP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=FulEtFGc; dmarc=none; spf=pass (mx1.freebsd.org: domain of koobsfreebsd@gmail.com designates 2607:f8b0:4864:20::532 as permitted sender) smtp.mailfrom=koobsfreebsd@gmail.com X-Spamd-Result: default: False [-3.20 / 15.00]; HAS_REPLYTO(0.00)[koobs@FreeBSD.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[koobs@FreeBSD.org,koobsfreebsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_NEQ_ENVFROM(0.00)[koobs@FreeBSD.org,koobsfreebsd@gmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::532:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 16/12/2021 3:55 am, Emmanuel Vadot wrote: > > Hello, it's me again, > > I've posted some review some time ago but didn't follow up with some > mail so users might see it. > I'd like to remove publickey(5) related programs, those are the only > DES users iirc and likely unused. > > https://reviews.freebsd.org/D30682 > https://reviews.freebsd.org/D30683 > > I'll commit this in two weeks unless there is some valid argument to > keep this. > > Cheers, > We may not want to list every single deprecation, but: https://wiki.freebsd.org/DeprecationPlan From nobody Sat Dec 18 03:52:22 2021 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 E5FE418EA5DA; Sat, 18 Dec 2021 03:52:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGBkj3879z3L0c; Sat, 18 Dec 2021 03:52:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BI3qMI9068936 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 17 Dec 2021 19:52:22 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BI3qMNs068935; Fri, 17 Dec 2021 19:52:22 -0800 (PST) (envelope-from sgk) Date: Fri, 17 Dec 2021 19:52:22 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211218035222.GA68916@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JGBkj3879z3L0c X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-2.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 10:21:55PM +0000, Mark Murray wrote: > On 14 Dec 2021, at 21:51, Steve Kargl wrote: > > Interval max ULP x at Max ULP > > [6,1755.1] 0.873414 at 1.480588145237629047468e+03 > > [1.0662,6] 0.861508 at 1.999467927053585410537e+00 > > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 > > [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 > > [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 > > > > Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or > > Extra diffs most welcome! > Hi Mark, Don't know if you noticed, but I borroewed a few cpu cycles from grimoire. My WIP is already better than the imprecise.c kludge from theraven@. I need to work out the details of computing logl(x) in extra precision or see if I can leverage what Bruce did a few years ago. Anywho, current results: Interval tested for tgammal: [128,1755] count: 1000000 xm = 1.71195767195767195767195767195767183e+03L libm = 7.79438030237108165017007606176403036e+4790L mpfr = 7.79438030237108165017007606175285456e+4790L ULP = 14869.19517 Interval tested for tgammal: [16,128] count: 1000000 xm = 1.27687183687183687183687183687183690e+02L libm = 6.61421998891483212224382625339007663e+212L mpfr = 6.61421998891483212224382625338960267e+212L ULP = 731.00958 Interval tested for tgammal: [10,16] count: 1000000 xm = 1.54261654261654261654261654261654251e+01L libm = 2.74203137295418912508367515208072654e+11L mpfr = 2.74203137295418912508367515208073861e+11L ULP = 45.61161 Interval tested for tgammal: [1.2446e-60,10] count: 1000000 xm = 6.26200626138006138006138006138006065e-02L libm = 1.54507103764516989381203274093299079e+01L mpfr = 1.54507103764516989381203274093299091e+01L ULP = 0.76751 -- Steve From nobody Sat Dec 18 10:41:14 2021 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 9C65218E327C; Sat, 18 Dec 2021 10:41:18 +0000 (UTC) (envelope-from markm@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGMpQ26Hnz4kBs; Sat, 18 Dec 2021 10:41:18 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:6dfc:850d:c1cd:d820]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id A3CC220844; Sat, 18 Dec 2021 10:41:17 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_D858C349-81E9-4783-9A72-6F9F7568A1F2"; protocol="application/pgp-signature"; micalg=pgp-sha512 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 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211218035222.GA68916@troutmask.apl.washington.edu> Date: Sat, 18 Dec 2021 10:41:14 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639824078; 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=/Ad3Lky0eNnvICrh1CZUgIH6Hu4GiGCutuqmFdwq1ow=; b=szq2Z/cwOKBb/3GIcFVjdmlT3Tt6dvTWNRiU/KYR8hRFbWMJ70MMBuGVdTb9bP6ekiozGg sQfmk/47PpDFd7y2TljtnfBW9SlKTemCfsGgcA4c8NDcsbvXpRYMgIkQN1IO+5A6UNo4Wd IporNE203CF2bdihJQmKcVtoXPiEaZlRci8/uT1bhZC0aWkvpJhZyGGt+cGkAvcF6vQ/2V JLcgK2tiIlk5AA09/S1hz1XQsy3gXnP/Qx3kDxc825mM4J7nsUBWNpov1yjenooNutd3vw z89JUbgnRKQnsuza1RPe7w6TJHC3dzECd8RHOaLpWS4oAFYuQoRGha/RhcfgcQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639824078; a=rsa-sha256; cv=none; b=BVUsGMuoDwGcMRGoQL7wZ9UXzFE5uxTN2DzHwscP2uxA22GazGjk6wml3v4gPGBwDxuG92 Vbzmlwo0Pv2ZrcQIBtu1ahHLsPq9LqCdeBNlG1k/gjjNGwhxw7jqYdBRrizIQUcKbVJ+Pd 0ZPn3N7vcDb+BQkmFgOnalPPILIsX/2g+qM63C+4SWv1M3eHXiJoWCSuBL6hAXCk4IyNjh HSodVlseGiHJZC1HJNVjm1hVD1fxDT6cwkn5AIEx/JiBjhRBqmwxEt2Lysp5OUwPv9T2sZ aXiaHCZclcWbzxWvP4TM0rrp2k/SR31hiO23Gv+AHdQ9Mdu7DV6rgST8tJokpw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_D858C349-81E9-4783-9A72-6F9F7568A1F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 18 Dec 2021, at 03:52, Steve Kargl = wrote: >=20 > On Tue, Dec 14, 2021 at 10:21:55PM +0000, Mark Murray wrote: >> On 14 Dec 2021, at 21:51, Steve Kargl = wrote: >>> Interval max ULP x at Max ULP >>> [6,1755.1] 0.873414 at 1.480588145237629047468e+03 >>> [1.0662,6] 0.861508 at 1.999467927053585410537e+00 >>> [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 >>> [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 >>> [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 >>>=20 >>> Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or >>=20 >> Extra diffs most welcome! >>=20 >=20 > Hi Mark, >=20 > Don't know if you noticed, but I borroewed a few cpu cycles > from grimoire. Didn't notice a thing! :-) > My WIP is already better than the imprecise.c > kludge from theraven@. I need to work out the details of > computing logl(x) in extra precision or see if I can leverage > what Bruce did a few years ago. Anywho, current results: >=20 > Interval tested for tgammal: [128,1755] > count: 1000000 > xm =3D 1.71195767195767195767195767195767183e+03L > libm =3D 7.79438030237108165017007606176403036e+4790L > mpfr =3D 7.79438030237108165017007606175285456e+4790L > ULP =3D 14869.19517 >=20 > Interval tested for tgammal: [16,128] > count: 1000000 > xm =3D 1.27687183687183687183687183687183690e+02L > libm =3D 6.61421998891483212224382625339007663e+212L > mpfr =3D 6.61421998891483212224382625338960267e+212L > ULP =3D 731.00958 >=20 > Interval tested for tgammal: [10,16] > count: 1000000 > xm =3D 1.54261654261654261654261654261654251e+01L > libm =3D 2.74203137295418912508367515208072654e+11L > mpfr =3D 2.74203137295418912508367515208073861e+11L > ULP =3D 45.61161 >=20 > Interval tested for tgammal: [1.2446e-60,10] > count: 1000000 > xm =3D 6.26200626138006138006138006138006065e-02L > libm =3D 1.54507103764516989381203274093299079e+01L > mpfr =3D 1.54507103764516989381203274093299091e+01L > ULP =3D 0.76751 Hmm. I think my understanding of ULP is missing something? I thought that ULP could not be greater than the mantissa size in bits? I.e., I thought it represents average rounding error (compared with "perfect rounding"), not truncation error, as the above very large ULPs suggest. M -- Mark R V Murray --Apple-Mail=_D858C349-81E9-4783-9A72-6F9F7568A1F2 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 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmG9usoACgkQQlsJDh9C UqA2bwf/aSpM0ZVX02od/89cMjwD+Hy5U4QemDhs+qHx0hPQn/Ry5SyEEeqjAJrA lde6OSxRhX3wBc5i/eN7vXdTz1WVj8C/QboXx0pkOBvVMOrb/9CpD5und8EIdekf f5QixS6vqXURjgLqRCdmOViCfG58KF+BcLJHZAtwl1EwoVTo28H/o+gx+2iA84oT qknObY4tKpMFqi5I5l7mmv7T/1Kiiwbe56KGAHvAMBY3u2048mOZpTGxJ/4qfSJI D/ZZLu51KAVx6mp8gRqUObxVoUpaUpYY8v1C/1Qbegmc7GGPnzcQPV28SWtB6kSw D3jkwnsxc1+GcIvHkFG2WE9Spaq5+w== =gzh1 -----END PGP SIGNATURE----- --Apple-Mail=_D858C349-81E9-4783-9A72-6F9F7568A1F2-- From nobody Sat Dec 18 17:30:12 2021 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 4A25118E1EED; Sat, 18 Dec 2021 17:30:42 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGXtn4KCRz4X4t; Sat, 18 Dec 2021 17:30:41 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f179.google.com with SMTP id x15so4225630ilc.5; Sat, 18 Dec 2021 09:30:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5MC7Jxw9DgRPMlFrvESEw60SxQwViP1iqn4wPigSjQ4=; b=6budBHsz4pTb0p5gHd2ck0M8fGJEaz865tzwSWzUKXYfRM9Shot1LFHGfjZHCxTprt UkN2r96t6D/pmTmIZRPJ8BEnoFn1m7bvEqq51o/uQMGrvYrjlCwWDfQjKhXjrTUBMTma ExHYDKHcZUmQpJd9GcxkbJaHXJopUHUj6djd06m4qx7vW/H1kuQao7ALBDOGu2+xDWUG 73y0HRqjtuD2LT2a+GWgDmLs/JQQcE7TfRvthc8eB4g+MlARv9c3GqgEprDKI8jPi0DH +CC2JdoP1NS4eBR7eH8JjjdskTzhQQ56k/jVaNCmiw7XFzHruX+3VmNGq1EjbznNY/Qd sN1A== X-Gm-Message-State: AOAM530hjf35juSKRg0BrIWDgFcCNSp6AlCVuhFaf7ls4iLcG1dY3yAc 1gNFaQfRvm6wZVMaY2/3jUzGAEmv5wF8cmoHxXs= X-Google-Smtp-Source: ABdhPJxVxXaxRwhl4adJQAnLgkPIWg4+5OGLv5hu/8FojeoB7BaTF5ucOV7fK5en19SmfOGMU+q0KwznfJh+d4cnidI= X-Received: by 2002:a05:6e02:1528:: with SMTP id i8mr4547376ilu.312.1639848634986; Sat, 18 Dec 2021 09:30:34 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Sat, 18 Dec 2021 12:30:12 -0500 Message-ID: Subject: Re: git: 30780c3f584a - stable/13 - README.md: correct GPL expansion To: Mark Millard Cc: Baptiste Daroussin , freebsd-current , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JGXtn4KCRz4X4t X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.179 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [0.21 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.99)[0.987]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.22)[0.222]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.179:from]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.179:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote: > > I'm confused, beyond just LGPL claims in the (fairly > current) source code, but GPL more generally: > > # grep -rl "SPDX.*GPL" /usr/main-src/ You need to exclude the ones with SPDX tags like: SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0 but also note that this text in README.md is just documenting the top-level gnu/ subdirectory. From nobody Sat Dec 18 17:51:51 2021 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 2796418E7825; Sat, 18 Dec 2021 17:51:53 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGYMF03RXz4cfv; Sat, 18 Dec 2021 17:51:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BIHppYb071383 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 18 Dec 2021 09:51:51 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BIHpp8v071382; Sat, 18 Dec 2021 09:51:51 -0800 (PST) (envelope-from sgk) Date: Sat, 18 Dec 2021 09:51:51 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211218175151.GA71197@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@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: <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> X-Rspamd-Queue-Id: 4JGYMF03RXz4cfv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 18, 2021 at 10:41:14AM +0000, Mark Murray wrote: > > Hmm. I think my understanding of ULP is missing something? > > I thought that ULP could not be greater than the mantissa size > in bits? > > I.e., I thought it represents average rounding error (compared with > "perfect rounding"), not truncation error, as the above very large > ULPs suggest. > The definition of ULP differs according which expert you choose to follow. :-) For me (a non-expert), ULP is measured in the system of the "accurate answer", which is assumed to have many more bits of precision than the "approximate answer". >From a very old das@ email and for long double I have /* From a das email: * * ulps = err * (2**(LDBL_MANT_DIG - e)), where e = ilogb(accurate). * * I use: * * mpfr_sub(err, accurate, approximate, RNDN); * mpfr_abs(err, err, RNDN); * mpfr_mul_2si(ulpx, err, -mpfr_get_exp(accurate) + LDBL_MANT_DIG, RNDN); * ulp = mpfr_get_d(ulpx, RNDN); * if (ulp 0.506 && mpfr_cmpabs(err, ldbl_minx) 0) { * print warning...; * } */ Here, "err = |accurate - approximate|" is done in the precision of the "accurate answer", and RNDN is round-to-nearest. The line 'mpfr_mul_2si(...)' is doing the scaling to manipulate the exponent of the radix 2. This is agreement with Goldberg. IIRC, Jean-Michel Muller et al have much more detailed discussion about error and ULPs in their book "Handbook of Floating-Point Arithmetic". https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html So, on ld80 and tgamma, I have % tlibm -l -x 8 -X 1755 -n 100000 -P tgamma Interval tested for tgammal: [8,1755] ulp <= 0.5: 90.207% 90207 | 90.207% 90207 0.5 < ulp < 0.6: 7.085% 7085 | 97.292% 97292 0.6 < ulp < 0.7: 2.383% 2383 | 99.675% 99675 0.7 < ulp < 0.8: 0.314% 314 | 99.989% 99989 0.8 < ulp < 0.9: 0.011% 11 | 100.000% 100000 Max ulp: 0.853190 at 9.236118561185611856579e+02 The "ulp <= 0.5" line indicates the number of correctly rounded case. If the value of ULP exceeds 1, then you are starting to lose more than 1 bit in the significant. Consider individual points. Here's a correctly rounded case: % tlibm -l -a 9.236118561185000000 tgamma xu = LD80C(0x93c72441a44a57a9, 3, 9.23611856118499999994e+00L), libmu = LD80C(0x82f85b3fe4b36f9b, 16, 6.70567128873706962722e+04L), mpfru = LD80C(0x82f85b3fe4b36f9b, 16, 6.70567128873706962722e+04L), ULP = 0.42318 Notice, ULP < 0.5 and the bits in libm and mpfr answer rounded to long double are all the same as is the decimal representation. Now consider the max ULP case: % tlibm -l -a 9.236118561185611856579e+02 tgamma xu = LD80C(0xe6e728a690c4fa87, 9, 9.23611856118561185658e+02L), libmu = LD80C(0xba6bea661a7eda3c, 7762, 5.72944398777756327202e+2336L), mpfru = LD80C(0xba6bea661a7eda3d, 7762, 5.72944398777756327245e+2336L), ULP = 0.85319 ULP is < 1, which is desireable. The bits agree except for the last place where we're off by 1, ie, 0xc vs 0xd. The decimal representation is of course off. So, now on grimoirei without my patch, I have % ./tlibm_libm -l -a 1.59255925592559255925592559255925594e+01 tgamma x = 1.59255925592559255925592559255925594e+01L libm = 1.06660136733166064453125000000000000e+12L mpfr = 1.06660136733166211967839038834033459e+12L, ULP = 13932370826141802496.00000 You have 16 correct decimal digits out of 36, which is the best you can expect from mapping tgammal to tgamma. ULP is significant larger than 1. The ulp is almost guaranteed to be larger than 2**(113-53). Now with my patch and worse case for 10000 x in [10:16] % ./tlibm_lmath -l -a 1.59255925592559255925592559255925594e+01 tgamma x = 1.59255925592559255925592559255925594e+01L libm = 1.06660136733166211967839038834033897e+12 mpfr = 1.06660136733166211967839038834033459e+12L, ULP = 41.40877 I don't print out the hex representation in ld128, but you see the number of correct decimal digits is 33 digits compared to 36. -- Steve From nobody Sat Dec 18 17:52:16 2021 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 5A58118E7E87 for ; Sat, 18 Dec 2021 17:52:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGYMv0fdzz4dNB for ; Sat, 18 Dec 2021 17:52:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92d.google.com with SMTP id y23so10239500uay.7 for ; Sat, 18 Dec 2021 09:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o2VFPKFLhTGeJp7snuAAgqgW3oSjN8v4jkbul0ZK9xg=; b=owyc9yVgWcfM95kA+ZYNfw5bl9jqfssUfUDYFq/U7Wh44SLBP0cYllwQZCidBe7Jtx PvpeT1T7buPzVP93DtNp98sZeljBJMm6Ldxh2GI+P0n/2MLv6cHLVXLme5pl/Eyraqo8 8lbfaPRNugNbDZfciKiMtvct11LxSqaM1HC8o7f2q4K4Uj9ai/4eEJ3ugG4FVYzAkMWm LDJOo9sDnHUn4QW4YI0sIw14wdXUe7dV3kOXONi0kplMJksZlPRc7/OfikwTxGAqvNTc qFJQf6OpcbRk1mB6ws3CA5qEr+Oi46vP+fa6tG4l36t+rJI1/mcrWOTrGNgCV2FHdg6A 1fsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o2VFPKFLhTGeJp7snuAAgqgW3oSjN8v4jkbul0ZK9xg=; b=Q3W0sr5yF30Zn2MkfNBQe/GhrM4veSClhPknLhjEOgYNqBejD2dz4ICLNE4gFC9Lew ponSfnJjCyIyla2uqGuT9uonutVuXmQ5VeR3rKswC1H+WhRV/bh0nwuqSzv+91yP1+/X ravT9uFlCdI2tQEJr4MXiJgJgAqJ9hi43UGUuGfMAdn0WLJaXUfqlPQW7srScOxKqtEn BlpTCFgmApsi8kRqGACC3pxjtip+K7t2zOYbrk7ABerTy+KDzvjwJm79KEdY9n6hcSSw XYGhXIAPxCB26l3W4i3GoMod2S9EPgEd3nlfi/FFTl+SaqvI0PLvlOZaA8iV7oYWsXso eIIQ== X-Gm-Message-State: AOAM531f1Noaeq2Cy3+ZdX5vOcJDyH+28N933a9AW66T4iC5YbYCs5XS PZlH6RJUHDwhmDJOsmWtTIQq8/TMlbSIv9paE6wfSbx+znl9ZQ== X-Google-Smtp-Source: ABdhPJzEW/hE2M8lWnDDSUAawjWvhinwAG1ukjZBAUhhhdyFXToq4IYbYiK25iw5fiYZ8FydkfvLWzhP21HyPRtBJ14= X-Received: by 2002:a9f:2383:: with SMTP id 3mr2840565uao.77.1639849946500; Sat, 18 Dec 2021 09:52:26 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sat, 18 Dec 2021 10:52:16 -0700 Message-ID: Subject: Re: git: 30780c3f584a - stable/13 - README.md: correct GPL expansion To: Ed Maste Cc: Mark Millard , Baptiste Daroussin , freebsd-current , FreeBSD-STABLE Mailing List Content-Type: multipart/alternative; boundary="0000000000008be76505d36f5181" X-Rspamd-Queue-Id: 4JGYMv0fdzz4dNB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000008be76505d36f5181 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 18, 2021, 10:31 AM Ed Maste wrote: > On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote: > > > > I'm confused, beyond just LGPL claims in the (fairly > > current) source code, but GPL more generally: > > > > # grep -rl "SPDX.*GPL" /usr/main-src/ > > You need to exclude the ones with SPDX tags like: > SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0 > > but also note that this text in README.md is just documenting the > top-level gnu/ subdirectory. > Yes. Readme.md has never been a comprehensive guide to license compliance. I'm working on revamping the project's license policies to be more in line with current industry practices. Warner > --0000000000008be76505d36f5181 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Dec 18, 2021, 10:31 AM Ed Maste <emaste@freebsd.org> wrote:
On Fri, 17 Dec 2021 at 11:09, Mark Millard <<= a href=3D"mailto:marklmi@yahoo.com" target=3D"_blank" rel=3D"noreferrer">ma= rklmi@yahoo.com> wrote:
>
> I'm confused, beyond just LGPL claims in the (fairly
> current) source code, but GPL more generally:
>
> # grep -rl "SPDX.*GPL" /usr/main-src/

You need to exclude the ones with SPDX tags like:
SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0

but also note that this text in README.md is just documenting the
top-level gnu/ subdirectory.
=

Yes. Readme.md has = never been a comprehensive guide to license compliance. I'm working on = revamping the project's license policies to be more in line with curren= t industry practices.

Wa= rner
--0000000000008be76505d36f5181-- From nobody Sat Dec 18 17:59:42 2021 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 4A21B18EB982; Sat, 18 Dec 2021 17:59:46 +0000 (UTC) (envelope-from markm@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGYXL0NZxz4jDd; Sat, 18 Dec 2021 17:59:46 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:6dfc:850d:c1cd:d820]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id 628F823DCE; Sat, 18 Dec 2021 17:59:45 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_39AA88BD-0EEE-4E7D-9F37-3FC17D2DD0EA"; protocol="application/pgp-signature"; micalg=pgp-sha512 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 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211218175151.GA71197@troutmask.apl.washington.edu> Date: Sat, 18 Dec 2021 17:59:42 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639850386; 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=8awRWXdBdNSaG0H+w7qzgxKu0/o7+nYCAv4yo0dDwpo=; b=ksG/miBvnt0mQJJhLKubSCG4v+AWL+29ZZNXjvF2fOvMoCX9UdMYimfV5/6+QItp1whzvp LFHHvOB7YEVLpUxeS5UydZihTRD6r7EzRdZ9kGgZpICMArHCNOe3/2L+qgbdyIy9CjvV8F i+h9TzNR2X7+uils8YHbcdL0PxlFX4wVa6VoOucCqXmtZ9uzE8zmqc6SuY24SgcVIh/5W4 ztVs1gXxrAQHxgNHr6IiWqiFoCOt7dzbZOaSDgN0RKKi9BFglK/tUjs4DeQv4gLC57Nl4C 61QBXzD8G/4wPNBHp2k3KfrdpXqhnxY36XgwT/ZR04qOJ4ZnkiSXcNza9L/EPQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639850386; a=rsa-sha256; cv=none; b=lTHFPtsYdVc9073Talb0h0m5QMcmRXxllHxJWcUEZv7zv7TT/Zup3erbcCRdq+yXSBHAW1 6Hgk34FNFFwR6Ny9IGbpytEYRpvXUySSLoMQ75sFqipSbmUBX16mzdEec/sUqZBOfGmX39 XnnNFmsyAqpQz7nQ+08qKqcgF8wGRC8mb4S4bNvnJYF4Tqw+hHz89cy18l5aY/QQSA6ifZ iUTVe+LNwwQL/hedabTPbB3rcc+4Z+l2UHO/YWMInbO7RmDy8Qpa1zMM1yjSB5hSnm+oaH B1CuARUbZkUibxkepo7nrKqzc+VXa9Y2OC+3+6GqJtf/+WAVxLvMQ/h5iIp6Pg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_39AA88BD-0EEE-4E7D-9F37-3FC17D2DD0EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 18 Dec 2021, at 17:51, Steve Kargl = wrote: >=20 > On Sat, Dec 18, 2021 at 10:41:14AM +0000, Mark Murray wrote: >>=20 >> Hmm. I think my understanding of ULP is missing something? >>=20 >> I thought that ULP could not be greater than the mantissa size >> in bits? >>=20 >> I.e., I thought it represents average rounding error (compared with >> "perfect rounding"), not truncation error, as the above very large >> ULPs suggest. >>=20 >=20 > The definition of ULP differs according which expert you > choose to follow. :-) For me (a non-expert), ULP is measured > in the system of the "accurate answer", which is assumed to > have many more bits of precision than the "approximate answer". > =46rom a very old das@ email and for long double I have Thank you! I checked the definition that I was used to, and it is roughly "how many bits of the mantissa are inaccurate (because of rounding error)". I can see how both work. For utterly massive numbers like from Gamma(), I can see how accounting for a much larger range works. It still feels slightly tricky, as e.g. how many digits after the floating point do you account for? > I don't print out the hex representation in ld128, but you see > the number of correct decimal digits is 33 digits compared to > 36. Looking good! M -- Mark R V Murray --Apple-Mail=_39AA88BD-0EEE-4E7D-9F37-3FC17D2DD0EA 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 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmG+IY4ACgkQQlsJDh9C UqDfZggAnbSAQEULcHYiEtSHmmFl3QopLwmRz2Ut6beEHD8olyv/PuqY/zh1aq99 sBqzlnEuVlPIE0jc5LXinK7h4JEolvdmeHHWAKvVQMfoUBxKBQyKa0muErAi+DoH Oimuf27Ga+xSuoDyb34+Nhh2GySchEflyYMwp9VVy+vkApIGkRYJymba458oyQP3 LhkWSSUdP9d1I+AlJHq1zeukmryrGi39rumBvCQ2XPhn0y/Vt48TXAgoVA/M7q3S LY+oEvwnLrNWZkRQEr80lDDpaemmVAmPigj+viTBwhSR3z/cDmFWD1o7uga4Igv7 cMNxBkU0KfPByRz+c3TUnicJ4ZKBwQ== =8ZW9 -----END PGP SIGNATURE----- --Apple-Mail=_39AA88BD-0EEE-4E7D-9F37-3FC17D2DD0EA-- From nobody Sat Dec 18 18:31:54 2021 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 6A5BA18F2F7D for ; Sat, 18 Dec 2021 18:32:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGZFc10t1z4pNs for ; Sat, 18 Dec 2021 18:32:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639852317; bh=DbuqOzzrG9eDcMy329t/+wYSj28DMn2PTKb4f21lZT4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=rgycS2xuFuZuZX3O06TxPLRQ17nyGSSsTxnJn7MaTkpmZIQdV8SCfpVpxuxv5OWwivNfvdUCnDS4cFA4n4fpt2pUBmIewDSE2AhhTkE7Hmrr3l4V88CcS+q52alEIVNijqK1ha+yZImf4rgiGRHuYNkSML/ynXo/fOQG5WNFT2Kz0XKWZZ5PwC/gFeBY5b+Joyp2q6HV1zCktrFn/jQtgcKKgbSB/Vh9EQXP1ujsMu4Wmk12REr/miv4HcqMCRH0eLAni19dBbhKUpjNoQ4B8PPBlb5WEaneyvH9yAB1S0yZSsdVFlaovKFAnwojdmlVcdOddihMBIX0RM57ebz6KQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639852317; bh=J2JqCSg2IuuGUgpbQrNuIlTW0rS5vMBrePcI+Mxe0F1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pAH5EFSUsOfUhMjXiWTmynIZwr4Pqav25Xma4+jnBFG+1HfHZ9gdTppxz/r0we2+aoTwluiWlYC6RXmKMmcX5V+RcWu/AQgpOJRXr0oyZLIET3AfLxDF6m5FYDQ1b2TC4WBS22pSf/Or36AH7LvtvknWlF9XPIlnQ21fJ0+GiRjdoxlB7fQz2e6/Qj4OD20aDqMpx2L867w5yuXxb513ZZQ5JLx50wSbwv8+dxvbvmlDlZgL7/WazLXMHQu9Gm8/hk82ie/NufQ6EoqEVFENIVv0txAM/EUsaQAXsAlUT3e/Sa1qZXR+yX9owV33a3zqmonOWyK9FO6JefU4dwJwfw== X-YMail-OSG: 35rMt4YVM1lhxXx2eswD776FqeesbqTH26kFhQ91EyJadkKxEgRAuHyqbSnC1bh YXzsG2iUUJl6Mj9.4HUnCB7ThW5KlAH35mCaCg7UV2VliZ5X2qXZDuVs9UG5L6Go9cjEiCgcyuZV H1DiBO3nMfH34GgOK9iKYVDrJ8G4gncvGE4UYm83f.Ax0zJQa2Zo8194tpl7.RPZ3Ih_MG8VIHzH wJ4O9A.x4JrSy5TDZYAMgOLaRfaqfuUd4z8O1YBVpPYVE2kEpxf_48hrp4oxh36RN1wZ.yccz5V9 smNs63_3ZZVQUtHE37Fv.xSLcXCA1pd1WAYGnuP2Xc_VBUJZIC6.0JlPPP7HJ7uWpfIT6ZkauzCb MBl8jsvKOltUTiTcIVlqt1y7jxN8Pk576DI7yyvjxaewvI9TH_4SZxHybHMg_jzj79dfZznCqSEw SPXmGuPpPcDyF_JMSAaXcVYwsSpzZHMS2BuA6kEHh7ZtD9.kjF9WLsGsE9u.zpq2nTFDzdomtNTG AcInyAnfq23hvvdj8CId2zSMZAg7xHinvpPoY8TGXvrUFn3SPF0cayQJH_5H9ct_DWrdTQL41bZK JTC8pMeLmqEHPN_mtTUuG70uh3SqQp0Murv9fufd464T4BZgQynuJwkI626R59rfkWU1PE0sVOVo v0jIvqJ3fcLrbc.neB2q.7RxhO45rz5J5WCQtPkefYNoX6wA1h5L12WHEQP7kiNunM5kQw5tpIg4 UDpuL.XmsDc1UyBpfL2xb9jNionv8MJATAs6tohyuIqH7diWvmQu.bIFpPWjsqngnGQeXjjyAZWC O0fa9SFUoS2Tfs4t64oiptWfyAxLS4dZ79RyvzInEwceUp5G0z5pu0fEyjJaXya7O_5BAYR6qsCf 7B_709pJc2gDFqaXUSqRHBm0Z0WDW2LMTYVuby1RblZqApeTUf.HDoR6oQvEZC3Hu9i4WpvQ7BVU d3UgTdTulvAT_GhMQQjwKUgiYz6zTgZvdsY8P3tXvAfcEG4fkX3SQ1vdpU1Um7wZfU5lXIKl4oUV CEuMK8B7iVSCgoQmha6gqgdeLl8JHZvgwG0AxB_oNI9eYhojJtmTm7csmPMbpzDoy9HLE8weWD18 pnq.qh5Armc3u9ZyswPXWBQb8lAYGSdNz_t3ZTif7T49XFXFC_kvIIre4e5SSQBmjExAMtFDjLBq t5Ikv_gKts9zEbEqkirBND.3n4Oqw4pNJwwWWZeVp01fxxIDARZcZPNvej1lWy3bCPSXEYr__hjv ntpf5l94UIZSlTAhz3sBXK4BVhY841D6QwUx_wEdh7iHoN2N2XgHMBeBUs3MhOS.B3l5ZTYJh_rA 2NBYxeBGDvS.s_l1rwIu8LZ.beYbcXhpS2ITZM4OcqM_BbOXoDAt5tiUTOVQ2pKwoei1Oc1mjrLB _.Lu4VQ20YTaCOYSBt8aaBdga14rMYKUVqp_zByf.DqFbee7D0_cfxzj1sZdDTohHj4UzFEDfJxD TkD_xoHxgvTHSopn.5pjka9e7w9RBZZSqTGIhjRbtQ_gM8eTpCCylQnWpQXDc9TLdT5186Z_MImX U04FkAcPXhdjEHEMGKHUAZ158X.AzC9EDywHfHP6c6ALuRmuKABQICszUrg8ST00scPBicsRt0Mo IzHfvpFJxuZZPeNaA9jAQN5xua3HcKLVF8Q8of14.QgrqZv5.l.Uv45LkYujHPZJab6B8wSQOhoU INs0tomFYvwMXmppXZgtDWINrKo1SM.Ob69MI7FSx_lkqChBL_LmVum4Xt60pNyQ96Ewri0_jZNv VveaHtGHqdEPbmYMSKIC4u5rgYrsokabkJ1GvkGiNnjMwCEF9nLAfteHuiiuOpU29p.9qvWLnBpA asoKRcRZvQ1I7ESN5SZf8DKumk_Xw8tI0vJrh4bhoZaDp3cvbuCP3dvlNLylSLwHvwP4wwFTnVTQ dLO3uXXBarOp92kD7kdrv4Fk9rWrrEffuEn_IOv9aDU2xkf95JaeFqSHdWR5CzshUrK1A9gqMLDa d1yM9LaszRvmaN1Y9XnmRPfktGGnrgZ_AJfIPuWf1yD3MMYQVLtvaPMXFwAk.F3SAskHfMmSv_yU LygrDflSepdBYik36aNkn.i_SeO50tWMOd4k8tQzf7EDeU1cY7xjQ9ZkqZ5KTwOa6aPE8BVo9ddD INyUHO9eICBbP7vIt27VJx_ljjymY8HmilmH.NTPWhDl9PIJdxR8Seqh11LD42ByHt2yxj.hk4eL zsA7x6Ymh5fKeJaJBgqpj2RgTA4QCZTIyhvJR7cQpFDfsjl398dnbqs3eekACxazsaIYVH6lzl2y xL0uwaXkLA6ScfVjb X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 18 Dec 2021 18:31:57 +0000 Received: by kubenode537.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6fc99e18d15e2dcefe12edeac5765b5b; Sat, 18 Dec 2021 18:31:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 30780c3f584a - stable/13 - README.md: correct GPL expansion In-Reply-To: Date: Sat, 18 Dec 2021 10:31:54 -0800 Cc: Baptiste Daroussin , freebsd-current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <4DFA25A9-4C30-4598-A694-4D818C5FAADA@yahoo.com> References: To: Ed Maste X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JGZFc10t1z4pNs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-18, at 09:30, Ed Maste wrote: > On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote: >>=20 >> I'm confused, beyond just LGPL claims in the (fairly >> current) source code, but GPL more generally: >>=20 >> # grep -rl "SPDX.*GPL" /usr/main-src/ >=20 > You need to exclude the ones with SPDX tags like: > SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0 >=20 > but also note that this text in README.md is just documenting the > top-level gnu/ subdirectory. # grep -r "SPDX.*GPL" /usr/main-src/ | egrep -vi = "(mit|bsd|Linux-OpenIB)" | grep -v sys/contrib/device-tree/ | more /usr/main-src/sys/gnu/gcov/gcc_4_7.c:// SPDX-License-Identifier: GPL-2.0 /usr/main-src/sys/gnu/gcov/gcov_fs.c:// SPDX-License-Identifier: GPL-2.0 /usr/main-src/sys/dts/include/dt-bindings/soc/qcom,tcsr.h:/* = SPDX-License-Identifier: GPL-2.0 */ But . . . # grep -r "SPDX.*GPL" /usr/main-src/ | egrep -vi = "(mit|bsd|Linux-OpenIB)" | grep sys/contrib/device-tree/ | wc 3104 9958 345089 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 18 19:10:53 2021 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 BDB4618FA89D for ; Sat, 18 Dec 2021 19:11:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGb6c4L87z4vbj for ; Sat, 18 Dec 2021 19:11:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92d.google.com with SMTP id a14so10594177uak.0 for ; Sat, 18 Dec 2021 11:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S/pd5o7CetoGe1gQArDICFoQ1sVZNKtx/eoKEy+d14o=; b=KeZDVoHGqYes9kUCnwTuGjU8XwmcNZekVA1ilLgYvzfN7+M685RvdV15hnUCSf7oEY 7kRS6VwOHDtlMZnXJnBRvqjRaUoKvOEAty0JdDU6+t+Iipl8/Lhu9HXFposny5ei2DHb zFWEJxrZUmqnOKUmiZU8qVdSonzq441PuWLqfAZG0K7oCjUwBJv38BFsvzBRdCmHRNxZ 4+9FH54VoNZbSO8Y8poNO861SbYgVYsDmhLMQ7AhWcDigzeI74lYlbGfFtPFqElKhyk0 poBYbFoYm3NFcINw76/GONg+220N8/GEd21RF46MWj7EOaJl5hPceEPgx5CnenpiqsVc 9YBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S/pd5o7CetoGe1gQArDICFoQ1sVZNKtx/eoKEy+d14o=; b=sEUNaabUv3nhTsSl5lwRsYrez8NXb62hdjvIDolzHeWoZFYXzUSwhbNkmy1zGXaT+N qblWy5nS1st20bVvuGkOneNmqE32IjDEb3+biTbes9VWoWoaVmjeD6KBYZRPdjGrwC/e dxDF8eZP18IOYPlTvQLdXrU0iNCSNbfm+d0l4z9s7V06yrFooz/WRF3cHOX83kLR0Jb9 0Bj0hB2NLT6c/DJhE9zHN01L88Cbso2D9CNR0QeKEkWmlb4vtaj7gktnlYUyafDFl2GQ +FUFgNTtGjrvEWXV1QP/W2obDK2va+Y7CtxxLVLTHrcVJYAUujMhxvL817azaS7gbmzR LoMA== X-Gm-Message-State: AOAM530pOL3pGF+egmipkVBYwJi6d3exG+J/xho3rRicoWPmTZKN2w35 TzuJv1ioBseST3TLKnm/UxeY/EbY5D9TszKm8+QsKg== X-Google-Smtp-Source: ABdhPJwtTappN5V4JqdquOMhmiUOd6KLDwsvanuKmvy/tddn8RLX0EbZ4SntPW+Qh431D+0DSc316jJmcuce9GeUULw= X-Received: by 2002:a05:6102:ec2:: with SMTP id m2mr3137272vst.6.1639854664011; Sat, 18 Dec 2021 11:11:04 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <4DFA25A9-4C30-4598-A694-4D818C5FAADA@yahoo.com> In-Reply-To: <4DFA25A9-4C30-4598-A694-4D818C5FAADA@yahoo.com> From: Warner Losh Date: Sat, 18 Dec 2021 12:10:53 -0700 Message-ID: Subject: Re: git: 30780c3f584a - stable/13 - README.md: correct GPL expansion To: Mark Millard Cc: Ed Maste , Baptiste Daroussin , freebsd-current , FreeBSD-STABLE Mailing List Content-Type: multipart/alternative; boundary="000000000000bb6a3d05d3706ab7" X-Rspamd-Queue-Id: 4JGb6c4L87z4vbj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000bb6a3d05d3706ab7 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 18, 2021 at 11:33 AM Mark Millard via freebsd-current < freebsd-current@freebsd.org> wrote: > On 2021-Dec-18, at 09:30, Ed Maste wrote: > > > On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote: > >> > >> I'm confused, beyond just LGPL claims in the (fairly > >> current) source code, but GPL more generally: > >> > >> # grep -rl "SPDX.*GPL" /usr/main-src/ > > > > You need to exclude the ones with SPDX tags like: > > SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0 > > > > but also note that this text in README.md is just documenting the > > top-level gnu/ subdirectory. > > # grep -r "SPDX.*GPL" /usr/main-src/ | egrep -vi "(mit|bsd|Linux-OpenIB)" > | grep -v sys/contrib/device-tree/ | more > /usr/main-src/sys/gnu/gcov/gcc_4_7.c:// SPDX-License-Identifier: GPL-2.0 > /usr/main-src/sys/gnu/gcov/gcov_fs.c:// SPDX-License-Identifier: GPL-2.0 > /usr/main-src/sys/dts/include/dt-bindings/soc/qcom,tcsr.h:/* > SPDX-License-Identifier: GPL-2.0 */ > > But . . . > > # grep -r "SPDX.*GPL" /usr/main-src/ | egrep -vi "(mit|bsd|Linux-OpenIB)" > | grep sys/contrib/device-tree/ | wc > 3104 9958 345089 > Yea, that doesn't matter that much... Those are generally not used for tier 1 platforms, except for some arm64 boards. And when they are used, they create a separate work (the .dtb files). And that's even assuming these files are expressive enough to have enough creative content that a copyright could attach... It's not used at all the build kernels, userland, etc (though one does have an option to attach a dtb to a kernel, to be fair). And they are all well marked with SPDX tags, so we're not misrepresenting anything and the project's use of them is in full compliance with whichever GPL they are released under. Downstream users will, as with all license things, need to ensure their uses comply. There have been various statements about these files over the years which one should consult if one ships a system with the .dtb w/o the .dts sources to determine compliance measures necessary (though the standard GPL measures will work, some folks have disclaimed the need to do them for their .dts files, ymmv). Warner --000000000000bb6a3d05d3706ab7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 18, 2021 at 11:33 AM Mark= Millard via freebsd-current <freebsd-current@freebsd.org> wrote:
On 2021-Dec-18, at 09:30, Ed Maste <emaste@freebsd.org= > wrote:

> On Fri, 17 Dec 2021 at 11:09, Mark Millard <marklmi@yahoo.com> wrote:
>>
>> I'm confused, beyond just LGPL claims in the (fairly
>> current) source code, but GPL more generally:
>>
>> # grep -rl "SPDX.*GPL" /usr/main-src/
>
> You need to exclude the ones with SPDX tags like:
> SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0
>
> but also note that this text in README.md is just documenting the
> top-level gnu/ subdirectory.

# grep -r "SPDX.*GPL" /usr/main-src/ | egrep -vi "(mit|bsd|L= inux-OpenIB)" | grep -v sys/contrib/device-tree/ | more
/usr/main-src/sys/gnu/gcov/gcc_4_7.c:// SPDX-License-Identifier: GPL-2.0 /usr/main-src/sys/gnu/gcov/gcov_fs.c:// SPDX-License-Identifier: GPL-2.0 /usr/main-src/sys/dts/include/dt-bindings/soc/qcom,tcsr.h:/* SPDX-License-I= dentifier: GPL-2.0 */

But . . .

# grep -r "SPDX.*GPL" /usr/main-src/ | egrep -vi "(mit|bsd|L= inux-OpenIB)" | grep sys/contrib/device-tree/ | wc
=C2=A0 =C2=A0 3104=C2=A0 =C2=A0 9958=C2=A0 345089

=
Yea, that doesn't matter that much...=C2=A0 Those are genera= lly not used for tier 1 platforms,=C2=A0except
for some arm64 boa= rds.=C2=A0 And when they are used, they create a separate work (the .dtb fi= les).
And that's even assuming these files are expressive eno= ugh to have enough creative content
that a copyright could attach= ... It's not used at all the build kernels, userland, etc (though one
does have an option to attach a dtb to a kernel, to be fair). And = they are all well marked with
SPDX tags, so we're not misrepr= esenting anything and the project's use of them is in full
co= mpliance with whichever GPL they are released under. Downstream users will,= as with
all license things, need to ensure their uses comply. Th= ere have been various statements
about these files over the years= which one should consult if one ships a system with the
.dtb w/o= the .dts sources to determine compliance measures necessary (though the st= andard
GPL measures will work, some folks have disclaimed the nee= d to do them for their
.dts files, ymmv).

Warner
--000000000000bb6a3d05d3706ab7-- From nobody Sun Dec 19 10:47:23 2021 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 9690318E1BC0 for ; Sun, 19 Dec 2021 10:47:38 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGzvF6jwVz3stf for ; Sun, 19 Dec 2021 10:47:37 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id j18so13875560wrd.2 for ; Sun, 19 Dec 2021 02:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:reply-to:mime-version :content-transfer-encoding; bh=vVZWW/QRtZAAk7Pm1crJSQ3WH/tJomkBDVSPf3Y9YcA=; b=MLZ1BCe7IQ3Lj13Fwja+e1KPf45MZ7rYUhzCPqCDvl5Pqe15qUvLM4YyI4KDZJROyX eS1mqHVGKqIWtkbiIWj0aTY6YneUTmDSw7pvagLzvPjllMS2X8+w56f0FI8BBPIk27XN +EFYiodD1XJyecBWVEhTKMVPSDWbHN9K85ryhanbBqBALMmGkKyR5dVHF/vdJ2OXyVXn sykBN+ZGbL9PAwWJg+N06XeJVJbmerBAoZTOBsO1glvPl/aqnxcu0xCVSAgZ745n70WA aDkpl/cBunqANqYxavFeh8sSGFYf6moa1OlkF06+rdmnr0gtuRC/3xvtn62G+6zpYSsu Qk8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mime-version:content-transfer-encoding; bh=vVZWW/QRtZAAk7Pm1crJSQ3WH/tJomkBDVSPf3Y9YcA=; b=rvcOjCqJ/WDisNhDlCFA6ifZZsxv8JoDWfVwSBqgbmnyYyx956nmoLpPCVDWrWSUWp 9yll5QCE6kdku1C8g4j6LQEzMu0AsEb/AbXCUkDSr2GEftJbeRCekyCj0xNU7GyRa7My YujkA0HJ+ybVXl5NSKek+ODuM0ic/GiYVFEKpE7Sr1iCh7HQuvW70cJOGkPKI1wq/ckn EIv0xkLz/x2bQ5Wdo/WpIqrzV3Qw1bt+BP2tN9LGJ16KJFl3K4M6e4ZS8WTr94NEowK9 44jiYcxfX09higuCjznravKUnv4qUG66xGuCB1HpRZgrWvLP4XxPXvCCmYVr855vNmiF u1dA== X-Gm-Message-State: AOAM531AbMdPXWNTCog6u/mLKaAF//XZ6ZGERwHpq+HbkoiFNJ8oi9la SLhXFjANYbt/2IKafVVKIrcYlYveNPE= X-Google-Smtp-Source: ABdhPJwltjXNOtt5Fb60PBdBnrYG5zFCRL0K8EZ/o68c1VHwWPS3GyWU/Nr6pSKTD8xxJ78RhYl1Yw== X-Received: by 2002:a5d:4568:: with SMTP id a8mr9419622wrc.471.1639910850931; Sun, 19 Dec 2021 02:47:30 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id r11sm12545551wrw.5.2021.12.19.02.47.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Dec 2021 02:47:30 -0800 (PST) Date: Sun, 19 Dec 2021 11:47:23 +0100 From: Gary Jennejohn To: freebsd-current@freebsd.org Subject: WITHOUT_PF breaks buildworld Message-ID: <20211219114723.338b235e@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JGzvF6jwVz3stf X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=MLZ1BCe7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [2.00 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Some recent change, probably in a .mk file, breaks builworld on HEAD when WITHOUT_PF is enabled in src.conf. Disabling WITHOUT_PF results in a successful buildworld. The reported error is that netpfil/pf/pf.h can't be found. -- Gary Jennejohn From nobody Sun Dec 19 11:05:35 2021 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 8DA9818E64BC for ; Sun, 19 Dec 2021 11:05:46 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.riseup.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JH0JB33ZCz3wKt for ; Sun, 19 Dec 2021 11:05:46 +0000 (UTC) (envelope-from agh@riseup.net) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (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 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4JH0J3429tzDyP5; Sun, 19 Dec 2021 03:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1639911939; bh=31Biu5+YmIBAiYAH2xViNwEr+9Ez2rYjzNbqotYcwmk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LnJMjFt7TJ5yYkoPFMsOp7OrQzK5N376NZTcDYcehb4n/P9SyAJQh9JZrDMyX5dj+ wFVRUgQZBCL1CPx5mPDK7CL+UEL70oZjKYqTcYt9tnToYrP6hZiZvn9rq3QoJVVDD6 0dZIS//xKDc9rlpJ+wpFJz+VV0P070TiTJEIG5xc= X-Riseup-User-ID: 970DCE77968186ED85F55E3D03846CE653F75D5061566ECB3CA4C7A1796B97E9 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4JH0J25Xh7z1y53; Sun, 19 Dec 2021 03:05:38 -0800 (PST) From: Alastair Hogge To: freebsd-current@freebsd.org Cc: gljennjohn@gmail.com Subject: Re: WITHOUT_PF breaks buildworld Date: Sun, 19 Dec 2021 19:05:35 +0800 Message-ID: <4659548.K9QhDrbJkl@direwolf.home.arpa.> In-Reply-To: <20211219114723.338b235e@ernst.home> References: <20211219114723.338b235e@ernst.home> 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="nextPart1904971.IU2PkffUJM" Content-Transfer-Encoding: 7Bit X-Rspamd-Queue-Id: 4JH0JB33ZCz3wKt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --nextPart1904971.IU2PkffUJM Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote: > Some recent change, probably in a .mk file, breaks builworld on HEAD > when WITHOUT_PF is enabled in src.conf. I have had to disable WITHOUT_PF since 2020-07-27, but probably earlier. > Disabling WITHOUT_PF results in a successful buildworld. > > The reported error is that netpfil/pf/pf.h can't be found. Some ports depend on that too. -- To health and anarchy Alastair --nextPart1904971.IU2PkffUJM Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="us-ascii"

On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote:

> Some recent change, probably in a .mk file, breaks builworld on HEAD

> when WITHOUT_PF is enabled in src.conf.


I have had to disable WITHOUT_PF since 2020-07-27, but probably earlier.


> Disabling WITHOUT_PF results in a successful buildworld.

>

> The reported error is that netpfil/pf/pf.h can't be found.


Some ports depend on that too.


--

To health and anarchy

Alastair

--nextPart1904971.IU2PkffUJM-- From nobody Sun Dec 19 11:09:47 2021 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 2BE9E18E74FD; Sun, 19 Dec 2021 11:09:59 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JH0P16kZwz4RnN; Sun, 19 Dec 2021 11:09:57 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id D098C10A32F1; Sun, 19 Dec 2021 12:09:49 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 435C510A330B; Sun, 19 Dec 2021 12:09:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1639912188; 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=GXae5hsDCllqX2N/6gHfir7GbmPQndlyaUcaao73qEA=; b=m9MKeICoxNcC161S56T8ieiJsAruAsHphFUHPqPnizjY5pJBUHhVJ08NLoTf1yF8hilo// oKJwPPqCT7b9BpJMg5vUcd++uru4z2yIi7tyZk9AoSD6/PLTqbZfgaMyg9Sw1X8I8S2Vrr FZ4COoLKIwENo55tWtN8hw3SGU7mcrBJOzmE4TlJ91nI4RRwPQBfRU0x2VZHpZF5ikgnNE PkdFN5XtdN7txoCaORBqgXVbiRYNE+4X1OJGRcnc6slGjd4l0Cnf468z2JBf3FIF/uRbqD /EHivLEshck/ZrVsOvU6gw2UCTvl4E1geceBf01k0age0D7dXCb75Qeukd2eNw== Received: from hermann (dynamic-2a01-0c22-3575-7c00-4417-7d39-cf16-de23.c22.pool.telefonica.de [IPv6:2a01:c22:3575:7c00:4417:7d39:cf16:de23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 1272F10A3309; Sun, 19 Dec 2021 12:09:48 +0100 (CET) Date: Sun, 19 Dec 2021 12:09:47 +0100 From: FreeBSD User To: freebsd-embedded@freebsd.org, FreeBSD CURRENT Subject: Arduino IDF -> make/automake based environment Message-ID: <20211219120947.75530a82@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 1cf155 X-Rspamd-UID: ce1eae X-Rspamd-Queue-Id: 4JH0P16kZwz4RnN X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=m9MKeICo; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[walstatt-de.de:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from] X-ThisMailContainsUnwantedMimeParts: N Hello out there, I'm using the port devel/arduino18 as the basis for some small projects. I'd like to get rid of that clumsy JAVA based IDF and move towards a more make/automake based environment. Since I'm interested in coding for some smaller AMTEL MCUs and ESP32 and like to digg a bit deeper than simply clicking a host base from a menu, I'm not afraid of doing some larger basic setup if needed. But I have so far almost no experience in cross compiling on FreeBSD and I'd like to ask whether someone out here has already done setting up an environment based on the basic tools FreeBSD provides to develop in an crosscompiling sense. My IDE of choice would be Anjuta, but this is only a notice besides. As fas as I know, the base OS for most MCUs, including my choices ESP32, ESP8266, is a derivative of Amazone's FreeRTOS. Can the OS being compiled (cross compiled) on FreeBSD assuming the correct compiler is at hand (which is the case, I presume since the Arduino IDF is already working on FreeBSD)? Thanks in advance, Oliver From nobody Sun Dec 19 11:24:43 2021 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 AB9C418ECB0E for ; Sun, 19 Dec 2021 11:24:51 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JH0kB6BBCz4XCq for ; Sun, 19 Dec 2021 11:24:50 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x429.google.com with SMTP id j9so14056043wrc.0 for ; Sun, 19 Dec 2021 03:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=nKm8yxPzEZH8HtsKmjtH17l+3dFaNUiZgld4oCc5AQ8=; b=GoEDF03+AwZFqKDXatBy1JgNpiDTE/DwOr4kJMbfEmobkc8OLyJ07HUz1alsA55xDg ZjnuQuftAQ+RB2qT0XwRbzdsMiVjgJMQ8vZHiFY0U54LHDI6VeU84HJUNOL1grmFpQdh xF8rmZ827Ps3ZxjncC+XjMwNtgceiQPwvtf9QNxbTzAktX3nNsHTNCgdp3sQ111BbIvl oeUH9piF/9tjvYtqtPCQiCocRj71W8eQJmTMSyabpLBDxhA48dWPaOTilRqo1z8n32Te jSRwEQxxGmBZvcLJ5cVDvK8ixgVNIry9NoWEcH+8VrGU46+6suszkiosIru8+UBPFyHC e8gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=nKm8yxPzEZH8HtsKmjtH17l+3dFaNUiZgld4oCc5AQ8=; b=arfnem2wczIqCRn2iGvisYYZI53xv3dczvulNSGJh1n7gBVBWtkvyOskaZy0ch3YNX Te+Bca69dwSBTrDVMcXb8T2kxC9YkLUDdofI+A85T8M1sGF1+Ouq454rHt0DBHwxfK9n cH3hpWMZ9JDa3PwkeSlg5wsK/LmbHCIaj1GYIOckfscHBYHoilbqjEulxPlRc/e0EvZ+ Fd+UWvmOrB1PYRSphUO7e7rS+k4H92EdUBTmgI1nR1TYkbK1NpnFlbqjAbFbG06koFsv RXVPdLjO4zp8Gs24FBEZIBBhe3PXz/c6YWVkd8CJkHGDG2YccUjVjtGcs6TcYTjblJe0 RZiA== X-Gm-Message-State: AOAM530mXK1ynk6/ZQvoMrYFCc7bEPRsNw7+wpvpvihSwVt/n4L3p2Ki 8+tEw3a0soIFATERsECW4hEdKy7sV6Y= X-Google-Smtp-Source: ABdhPJy192DuCIjc8Yn7xxd9hzBCHHBHQf5pSfbeZjKaQVzg9BYgbC9kqscZ0CrDGYVtLgfe3qG+Pw== X-Received: by 2002:a5d:6488:: with SMTP id o8mr9563897wri.630.1639913084238; Sun, 19 Dec 2021 03:24:44 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id u9sm11524738wmm.7.2021.12.19.03.24.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Dec 2021 03:24:43 -0800 (PST) Date: Sun, 19 Dec 2021 12:24:43 +0100 From: Gary Jennejohn To: Alastair Hogge Cc: freebsd-current@freebsd.org Subject: Re: WITHOUT_PF breaks buildworld Message-ID: <20211219122443.1c84093f@ernst.home> In-Reply-To: <61bf1204.1c69fb81.2c8fc.3280SMTPIN_ADDED_BROKEN@mx.google.com> References: <20211219114723.338b235e@ernst.home> <61bf1204.1c69fb81.2c8fc.3280SMTPIN_ADDED_BROKEN@mx.google.com> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JH0kB6BBCz4XCq X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=GoEDF03+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::429 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [1.93 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(0.96)[0.955]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.98)[0.978]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::429:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, 19 Dec 2021 19:05:35 +0800 Alastair Hogge wrote: > On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote: > > Some recent change, probably in a .mk file, breaks builworld on HEAD > > when WITHOUT_PF is enabled in src.conf. > > I have had to disable WITHOUT_PF since 2020-07-27, but probably earlier. > Hmm. I did a successful buildworld a few days ago with WITHOUT_PF enabled, so it's new breakge for me at least. I don't enable pf in the kernel and don't need it in userland. > > Disabling WITHOUT_PF results in a successful buildworld. > > > > The reported error is that netpfil/pf/pf.h can't be found. > > Some ports depend on that too. > It may not be a problem for ports. Depends on where they look for it. The file is still there under /sys and /usr/include. -- Gary Jennejohn From nobody Sun Dec 19 11:50:37 2021 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 6A66C18F1D3D for ; Sun, 19 Dec 2021 11:50:49 +0000 (UTC) (envelope-from potthua@gmail.com) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JH1J82sTbz4b4C for ; Sun, 19 Dec 2021 11:50:48 +0000 (UTC) (envelope-from potthua@gmail.com) Received: by mail-ua1-x92b.google.com with SMTP id u40so12801287uad.1 for ; Sun, 19 Dec 2021 03:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=Z9N0jkfAIZqAPdCN0nLhZ4jowJnOnhiStnDl8oZZ328=; b=Ro02J0K1JY0YogXoPISviPyBOWXbcprsOXV8TSh0MpaRVIjWHoxNX4X1JmOUGJGFd+ uZWmn0aD23h2cpSx1zVYwfnRzgPTcRY7EoraX2wbCht8Q4fO/1ZyosLN8eHe0bZnLFSz RuoNpkiFb5yQPqBpyvV+RWCCP1QRT3QuxsoTBm0aCN0qPeZmT9ZNOKycIP9lP/TSmF8+ KuTandNR86d5QeKsW+lhU17a4Yrc8LoWnU2unFEd8wG0f6J+ivjR9SaGtKK6Q2qw1i2h rMpKy1MDt1Sgre3d3ynuChBTLHR4zR8BZAEVhEJZdRfEo1qdL2WoigvwvbXsMy7ei20X 3gTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Z9N0jkfAIZqAPdCN0nLhZ4jowJnOnhiStnDl8oZZ328=; b=SwDUyhCX1xGor3X4QUxZ7GN5bQXeh0pPOZJgaNPZ/Jclm1UCbwCCxephEkNQ7Rg5rG S4Y4TV3uaiFJMI1DyA5oj+43YXExYli1m4G79jadF1GM0ZmK1/4QiXjGLynV0i46FYT4 sC5z0vSS0sak2nEHAnwtf3G2EpzedYm71atAkGlvXJm9Cqm18V2iQjkhBX6YFt9nd4Rr WAWasnQkBjjFp/rPg7/Y6MoXZZR5oksMlFuz5KXy8pGsf8XEi065LNQBy1U1Muo6Bsbl im08FZyJuZVhbLRX+s9rwHbGwQwaUgxcIkio8h4LioaDo5E7iHUqW7PPyVxa+z/wZsd+ e+5g== X-Gm-Message-State: AOAM531EEXv7SaG9j+Hw3Hq26dcSRiDWomU4DgXVhxW0v8/zgH2QqY4f qAi/0l4/n8/w7GgIswX29OSSkzfO71Ks6FIIjHj+4OuVvnoC4W5X X-Google-Smtp-Source: ABdhPJyuarnTXLu8Mcq/nc7M9ahJmhuMOJVLlIiLScOgo5J+qK4i2b4BdZLkZ4hA5ajR9u5ZD3qhC06kwb/JvOLzCxQ= X-Received: by 2002:ab0:324e:: with SMTP id r14mr3663255uan.117.1639914647762; Sun, 19 Dec 2021 03:50:47 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Piper H Date: Sun, 19 Dec 2021 19:50:37 +0800 Message-ID: Subject: mail server on freebsd To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000000abc6405d37e62aa" X-Rspamd-Queue-Id: 4JH1J82sTbz4b4C X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ro02J0K1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of potthua@gmail.com designates 2607:f8b0:4864:20::92b as permitted sender) smtp.mailfrom=potthua@gmail.com X-Spamd-Result: default: False [2.00 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92b:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000000abc6405d37e62aa Content-Type: text/plain; charset="UTF-8" I found this article is quite nice for running an email server on freebsd. I just want to share it here. https://www.c0ffee.net/blog/mail-server-guide/ --0000000000000abc6405d37e62aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I found this article is quite nice for running an ema= il server on freebsd. I just want to share it here.

https://www.c0= ffee.net/blog/mail-server-guide/
--0000000000000abc6405d37e62aa-- From nobody Sun Dec 19 15:07:39 2021 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 DAA9318FBE58; Sun, 19 Dec 2021 15:07:49 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from mcusim.org (mcusim.org [176.58.93.53]) (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 4JH5gT5LQ6z3Dw9; Sun, 19 Dec 2021 15:07:49 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from peasant.tower.home (unknown [83.28.233.208]) (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 mcusim.org (Postfix) with ESMTPSA id D612A8F913; Sun, 19 Dec 2021 16:07:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mcusim.org; s=default; t=1639926462; bh=uZG1cFEUloVcj8MJA3iTkdowyzpsb5QQM0qoGsAwTdc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=iRs1URXS367Ws5pt22Fgh1fpX2C8MrEfIjCB6m9HNeatBPoiNdgwJLnLzQ9T9iMEK LB9pVL+qJHFVZb87H4rkJsXGNlhcVJTmP7HQtXM393WWm1OnS5GxTdQcIYIVfvrJXz 6LqjEJ3LXVYkrOLPa6BhsK2kJQpEcN/q62HZTEdY= Date: Sun, 19 Dec 2021 16:07:39 +0100 To: FreeBSD User Cc: freebsd-embedded@freebsd.org, FreeBSD CURRENT Subject: Re: Arduino IDF -> make/automake based environment Message-ID: References: <20211219120947.75530a82@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211219120947.75530a82@hermann> X-Rspamd-Queue-Id: 4JH5gT5LQ6z3Dw9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: dsl@mcusim.org From: Dmitry Salychev via freebsd-embedded X-Original-From: Dmitry Salychev X-ThisMailContainsUnwantedMimeParts: N Hi Oliver, I'm working on this small [1] project using FreeBSD only. Software part is based on FreeRTOS v10.2.1. You can also find some pieces of the development history on hackaday [2]. Regards, Dmitry [1] https://github.com/mcusim/Xling [2] https://hackaday.io/project/165726-xling > Hello out there, > > I'm using the port devel/arduino18 as the basis for some small projects. I'd like to get > rid of that clumsy JAVA based IDF and move towards a more make/automake based > environment. Since I'm interested in coding for some smaller AMTEL MCUs and ESP32 and > like to digg a bit deeper than simply clicking a host base from a menu, I'm not afraid of > doing some larger basic setup if needed. But I have so far almost no experience in cross > compiling on FreeBSD and I'd like to ask whether someone out here has already done > setting up an environment based on the basic tools FreeBSD provides to develop in an > crosscompiling sense. > My IDE of choice would be Anjuta, but this is only a notice besides. > > As fas as I know, the base OS for most MCUs, including my choices ESP32, ESP8266, is a > derivative of Amazone's FreeRTOS. Can the OS being compiled (cross compiled) on FreeBSD > assuming the correct compiler is at hand (which is the case, I presume since the Arduino > IDF is already working on FreeBSD)? > > Thanks in advance, > > Oliver > From nobody Mon Dec 20 10:15:53 2021 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 108F918F0990; Mon, 20 Dec 2021 10:16:04 +0000 (UTC) (envelope-from marc@blackend.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) (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 4JHb8L4rw7z3tqH; Mon, 20 Dec 2021 10:16:02 +0000 (UTC) (envelope-from marc@blackend.org) Received: from emphyrio.blackend.org (unknown [82.64.86.146]) by smtp1-g21.free.fr (Postfix) with ESMTPS id 33472B0057F; Mon, 20 Dec 2021 11:15:54 +0100 (CET) Received: from emphyrio.blackend.org (localhost [127.0.0.1]) by emphyrio.blackend.org (8.16.1/8.16.1) with ESMTPS id 1BKAFsBY001311 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Dec 2021 11:15:54 +0100 (CET) (envelope-from marc@emphyrio.blackend.org) Received: (from marc@localhost) by emphyrio.blackend.org (8.16.1/8.16.1/Submit) id 1BKAFr4l001310; Mon, 20 Dec 2021 11:15:53 +0100 (CET) (envelope-from marc) Date: Mon, 20 Dec 2021 11:15:53 +0100 From: Marc Fonvieille To: Mark Murray Cc: Steve Kargl , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: Mail-Followup-To: Mark Murray , Steve Kargl , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xCByWbMwccz7wm2s" Content-Disposition: inline In-Reply-To: <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> X-Rspamd-Queue-Id: 4JHb8L4rw7z3tqH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of marc@blackend.org has no SPF policy when checking 2a01:e0c:1:1599::10) smtp.mailfrom=marc@blackend.org X-Spamd-Result: default: False [-2.90 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[marc]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[blackend@freebsd.org,marc@blackend.org]; R_SPF_NA(0.00)[no SPF record]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:12322, ipnet:2a01:e00::/26, country:FR]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[blackend@freebsd.org,marc@blackend.org]; RECEIVED_SPAMHAUS_PBL(0.00)[82.64.86.146:received] X-ThisMailContainsUnwantedMimeParts: N --xCByWbMwccz7wm2s Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le 18.12.2021 17:59, Mark Murray a =E9crit : >=20 >=20 > > On 18 Dec 2021, at 17:51, Steve Kargl wrote: > >=20 > > On Sat, Dec 18, 2021 at 10:41:14AM +0000, Mark Murray wrote: > >>=20 > >> Hmm. I think my understanding of ULP is missing something? > >>=20 > >> I thought that ULP could not be greater than the mantissa size > >> in bits? > >>=20 > >> I.e., I thought it represents average rounding error (compared with > >> "perfect rounding"), not truncation error, as the above very large > >> ULPs suggest. > >>=20 > >=20 > > The definition of ULP differs according which expert you > > choose to follow. :-) For me (a non-expert), ULP is measured > > in the system of the "accurate answer", which is assumed to > > have many more bits of precision than the "approximate answer". > > From a very old das@ email and for long double I have >=20 > >=20 > Thank you! >=20 > I checked the definition that I was used to, and it is roughly > "how many bits of the mantissa are inaccurate (because of > rounding error)". > Hi, ULP (Unit in the last place) is at first the weight of the least significant bit of the mantissa. E.g., in IEEE 754 single precision =3D 2^-23. It can also be seen as the distance between 2 consecutive significands (which is not the distance between 2 consecutive floating numbers). Some people, use ULP (or number of ULP) as Units (plural) in the Last Place to show the number of bits in error in the least significant bits of the significand. I assume what Steve is talking about is the corresponding value in decimal of the number of ULP. This thread is really interesting (even if I'm loosely following it). > I can see how both work. For utterly massive numbers like > from Gamma(), I can see how accounting for a much larger > range works. >=20 > It still feels slightly tricky, as e.g. how many digits after the > floating point do you account for? >=20 > > I don't print out the hex representation in ld128, but you see > > the number of correct decimal digits is 33 digits compared to > > 36. >=20 > Looking good! >=20 > M > -- > Mark R V Murray >=20 --=20 Marc --xCByWbMwccz7wm2s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQRV00iDSgSCiqE5pc/ND1HAT4506AUCYcBX0wAKCRDND1HAT450 6MesAJ9hTi3dMFzFfLKQC7S8/sAwqKeudwCdEKjMYEmLttjWsFBx4mM0/L2y3JE= =Rz1J -----END PGP SIGNATURE----- --xCByWbMwccz7wm2s-- From nobody Mon Dec 20 13:35:10 2021 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 2DAD918F72CC; Mon, 20 Dec 2021 13:35:15 +0000 (UTC) (envelope-from marc@blackend.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) (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 4JHgZC048zz4tkl; Mon, 20 Dec 2021 13:35:14 +0000 (UTC) (envelope-from marc@blackend.org) Received: from emphyrio.blackend.org (unknown [82.64.86.146]) by smtp1-g21.free.fr (Postfix) with ESMTPS id 4F235B005A9; Mon, 20 Dec 2021 14:35:13 +0100 (CET) Received: from emphyrio.blackend.org (localhost [127.0.0.1]) by emphyrio.blackend.org (8.16.1/8.16.1) with ESMTPS id 1BKDZCqd002106 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Dec 2021 14:35:12 +0100 (CET) (envelope-from marc@emphyrio.blackend.org) Received: (from marc@localhost) by emphyrio.blackend.org (8.16.1/8.16.1/Submit) id 1BKDZAWo002105; Mon, 20 Dec 2021 14:35:10 +0100 (CET) (envelope-from marc) Date: Mon, 20 Dec 2021 14:35:10 +0100 From: Marc Fonvieille To: Andrew Stevenson Cc: FreeBSD User , freebsd-embedded@freebsd.org, FreeBSD CURRENT Subject: Re: Arduino IDF -> make/automake based environment Message-ID: Mail-Followup-To: Andrew Stevenson , FreeBSD User , freebsd-embedded@freebsd.org, FreeBSD CURRENT References: <20211219120947.75530a82@hermann> <0024BDB4-ABFE-4DAE-BC99-0AF43F8B3180@ugh.net.au> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0024BDB4-ABFE-4DAE-BC99-0AF43F8B3180@ugh.net.au> X-Rspamd-Queue-Id: 4JHgZC048zz4tkl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Le 19.12.2021 21:03, Andrew Stevenson a écrit : > > > > On 19. Dec 2021, at 12:18, FreeBSD User wrote: > > > > environment. Since I'm interested in coding for some smaller AMTEL MCUs and ESP32 and > > like to digg a bit deeper than simply clicking a host base from a menu, I'm not afraid of > > doing some larger basic setup if needed. > > If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in ports. > For ESP32, you should look at: https://wiki.freebsd.org/electronics/arduino/esp32 and https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/ -- Marc From nobody Tue Dec 21 00:48:19 2021 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 96885190098F; Tue, 21 Dec 2021 00:48:27 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHyVy2zTrz3vcJ; Tue, 21 Dec 2021 00:48:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BL0mJhT079172 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Dec 2021 16:48:19 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BL0mJKb079171; Mon, 20 Dec 2021 16:48:19 -0800 (PST) (envelope-from sgk) Date: Mon, 20 Dec 2021 16:48:19 -0800 From: Steve Kargl To: Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211221004819.GA79153@troutmask.apl.washington.edu> References: <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@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-Rspamd-Queue-Id: 4JHyVy2zTrz3vcJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [0.14 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.77)[-0.767]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.82)[0.824]; NEURAL_HAM_LONG(-0.92)[-0.915]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote: > > I assume what Steve is talking about is the corresponding value in > decimal of the number of ULP. > Bad assumption. Please read Goldberg's paper. I am talking about ULP in the underlying floating point format. -- Steve From nobody Tue Dec 21 10:46:10 2021 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 06CF41902232; Tue, 21 Dec 2021 10:46:29 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJCn05rCcz4gPN; Tue, 21 Dec 2021 10:46:28 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 0490010A3309; Tue, 21 Dec 2021 11:46:20 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 2A9A210A330B; Tue, 21 Dec 2021 11:46:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1640083578; 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=22r000WVr03DBxnG/ntVDO/ZaQDwlrMU2arGF1d/ulg=; b=MPNKfSGiYfVwV2vY8RoPbBn257MhvJO4YQJu5Sx7/bibZjgAvbfC2LPAiM+MfyYnDTZ0kC SvISpdiUvIpJncn1T03uJPHji7ClTp2GIMvVlpDXk9y3YlJKWaXdm0Vm6rQYskPmZyvM4I zZ6+P657t+UvPB7qtSAScgNnru+ZP4wYXquBa14HLeJ+OU1uEHRw2H1Fso3uJiWVYfCK72 t60wZ2KkBjTc9LskRi9aCkD8ZgydT/20THJiJ4t27IXYn9j9ctv5hEqGwGm1HtAo3vL0Fj JaPj+G1wv4zPmgbmF73xXosbL+KtEyJZsgh83ma4V5KUPDxuA6FTuSflWwBIeg== Received: from jelly.fritz.box (dynamic-2a01-0c23-6044-9800-2f60-438d-8116-37fd.c23.pool.telefonica.de [IPv6:2a01:c23:6044:9800:2f60:438d:8116:37fd]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id D9F8A10A3307; Tue, 21 Dec 2021 11:46:17 +0100 (CET) Date: Tue, 21 Dec 2021 11:46:10 +0100 From: FreeBSD User To: Marc Fonvieille Cc: Andrew Stevenson , freebsd-embedded@freebsd.org, FreeBSD CURRENT Subject: Re: Arduino IDF -> make/automake based environment Message-ID: <20211221114610.3bc1f74d@jelly.fritz.box> In-Reply-To: References: <20211219120947.75530a82@hermann> <0024BDB4-ABFE-4DAE-BC99-0AF43F8B3180@ugh.net.au> Organization: FreeBSD in der Heimstatt List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-UID: c06450 X-Rspamd-UID: 5e7e73 X-Rspamd-Queue-Id: 4JJCn05rCcz4gPN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Am Mon, 20 Dec 2021 14:35:10 +0100 schrieb Marc Fonvieille : > Le 19.12.2021 21:03, Andrew Stevenson a =C3=A9crit : > >=20 > > =20 > > > On 19. Dec 2021, at 12:18, FreeBSD User > > > wrote: > > >=20 > > > environment. Since I'm interested in coding for some smaller > > > AMTEL MCUs and ESP32 and like to digg a bit deeper than simply > > > clicking a host base from a menu, I'm not afraid of doing some > > > larger basic setup if needed. =20 > >=20 > > If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are > > in ports.=20 >=20 > For ESP32, you should look at: > https://wiki.freebsd.org/electronics/arduino/esp32 > and > https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for= -arduino-on-freebsd12-update-2021-08-17.78408/ >=20 Great! Thanks a lot. Oliver From nobody Tue Dec 21 14:46:40 2021 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 09C6A19061A6; Tue, 21 Dec 2021 14:46:51 +0000 (UTC) (envelope-from marc@blackend.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) (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 4JJK6L64Yfz3hxs; Tue, 21 Dec 2021 14:46:50 +0000 (UTC) (envelope-from marc@blackend.org) Received: from emphyrio.blackend.org (unknown [82.64.86.146]) by smtp1-g21.free.fr (Postfix) with ESMTPS id CDA1EB0051E; Tue, 21 Dec 2021 15:46:41 +0100 (CET) Received: from emphyrio.blackend.org (localhost [127.0.0.1]) by emphyrio.blackend.org (8.16.1/8.16.1) with ESMTPS id 1BLEkejD002250 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Dec 2021 15:46:40 +0100 (CET) (envelope-from marc@emphyrio.blackend.org) Received: (from marc@localhost) by emphyrio.blackend.org (8.16.1/8.16.1/Submit) id 1BLEke99002249; Tue, 21 Dec 2021 15:46:40 +0100 (CET) (envelope-from marc) Date: Tue, 21 Dec 2021 15:46:40 +0100 From: Marc Fonvieille To: Steve Kargl Cc: Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: Mail-Followup-To: Steve Kargl , Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> <20211221004819.GA79153@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211221004819.GA79153@troutmask.apl.washington.edu> X-Rspamd-Queue-Id: 4JJK6L64Yfz3hxs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Le 20.12.2021 16:48, Steve Kargl a écrit : > On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote: > > > > I assume what Steve is talking about is the corresponding value in > > decimal of the number of ULP. > > > > Bad assumption. Please read Goldberg's paper. I am talking > about ULP in the underlying floating point format. > Thanks, it's more clear now: it's the ULP value. Is your tlibm_libm program available for testing ? If I find time I'd like to do some tests. -- Marc From nobody Tue Dec 21 16:47:49 2021 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 656C518F5A0F; Tue, 21 Dec 2021 16:47:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJMnz1xjsz4TR3; Tue, 21 Dec 2021 16:47:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BLGlnbV081717 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Dec 2021 08:47:49 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BLGlniI081716; Tue, 21 Dec 2021 08:47:49 -0800 (PST) (envelope-from sgk) Date: Tue, 21 Dec 2021 08:47:49 -0800 From: Steve Kargl To: Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211221164749.GA81666@troutmask.apl.washington.edu> References: <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> <20211221004819.GA79153@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4JJMnz1xjsz4TR3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [0.68 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.18)[-0.184]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.86)[0.863]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 21, 2021 at 03:46:40PM +0100, Marc Fonvieille wrote: > Le 20.12.2021 16:48, Steve Kargl a écrit : > > On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote: > > > > > > I assume what Steve is talking about is the corresponding value in > > > decimal of the number of ULP. > > > > > > > Bad assumption. Please read Goldberg's paper. I am talking > > about ULP in the underlying floating point format. > > > > Thanks, it's more clear now: it's the ULP value. > Is your tlibm_libm program available for testing ? If I find time I'd like to > do some tests. > Not at the moment. tlibm only handles math functions with a single real agrument [1]. I've been thinking about adding the 2 argument functions such as atan2 and complex argument function, but lack the time. I also need to improve the man page to decoment the default domain for each function and its complete domain. [1] acos, acosh, asin, asinh, atan, atanh, cbrt, cos, cosh, erf, erfc, exp, exp2, expm1, j0, j1, lgamma, log, log10, log1p, log2, sin, sinh, sqrt, tan, tanh, tgamma, y0, y1. -- Steve From nobody Tue Dec 21 17:01:50 2021 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 AAF3418F9245 for ; Tue, 21 Dec 2021 17:02:01 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJN6J4yTNz4YRh; Tue, 21 Dec 2021 17:02:00 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1640106110; bh=ba5iIFJ+KTboDWHvx1O6mUyzfCJ3MWqCo6qE awP99cM=; b=LYYJ21RGlf8KkKMXGz1c6us313CK9FuEHXZcxCdTvBcx8d6d9chj zt9efeNO6ggl0hJXSC9UYlVub0ky6S26tqT+mnnpMOcNnuDc7TSuLyOPXG5bVH11 +glzeW4Fx0kAijWuEozIVTW31qfpN9b7PzK82+jjlj7GXbdF1w+vFjw= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id BB9DA31CA0; Tue, 21 Dec 2021 12:01:50 -0500 (EST) Message-ID: <311ce6f4-9fa8-0514-193d-6be841af26b2@protected-networks.net> Date: Tue, 21 Dec 2021 12:01:50 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Panic: Page Fault in Kernel: Yesterday's CURRENT Content-Language: en-NZ To: Larry Rosenman , Mark Johnston Cc: Alexander Motin , Freebsd current References: <3d1b5249a2c51670de496fad9e8b054c@lerctr.org> <9852ae04-6dd0-1cd4-13fe-e97c68e71b37@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JJN6J4yTNz4YRh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=LYYJ21RG; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-1.91 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.92)[0.917]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-0.83)[-0.827]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N I have an old pentium-3 that also won't boot kernels built after Dec 6th. I suspect the commits listed below but, with the device being remote and having no DRAC, I'm struggling to test this theory. The relevant commits .. commit 553af8f1ec71d397b5b4fd5876622b9269936e63 Author: Mark Johnston Date: Mon Dec 6 10:42:19 2021 -0500 x86: Perform late TSC calibration before LAPIC timer calibration commit 62d09b46ad7508ae74d462e49234f0a80f91ff69 Author: Mark Johnston Date: Mon Dec 6 10:42:10 2021 -0500 x86: Defer LAPIC calibration until after timecounters are available It's currently running git rev e43d081f352 and I have a kernel at git rev f06f1d1fdb969fa7a0a6eefa030d8536f365eb6e to test later this evening, Michael On 12/17/21 15:07, Larry Rosenman wrote: > On 12/17/2021 1:36 pm, Mark Johnston wrote: >> On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote: >>> 14-2021_12_07-1217             -      -          1.87G 2021-12-07 12:17 >>> 14-2021_12_09-1957             NR     /          121G  2021-12-09 19:57 >>> >>> If that's any help >> >> I can't tell what this is saying.  A kernel built on the 7th does not >> crash, or...?  Which revision did you update from before you started >> seeing crashes? >> >> From a kgdb session it'd be useful to see output from >> >> (kgdb) frame 8 >> (kgdb) p/x *tmp >> >> to start. >> > > Correct, the 7th didn't panic, but the 9th did, and yesterday's too. > > Grrr > ler in borg in /mnt🔒 on â˜ï¸Â  (us-east-1) > ⯠kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel > GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] > Copyright (C) 2021 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-portbld-freebsd14.0". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: >     . > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /mnt/boot/kernel/kernel... > (No debugging symbols found in /mnt/boot/kernel/kernel) > Failed to open vmcore: /var/crash/vmcore.0: Permission denied > (kgdb) bt > No stack. > quitb) > > ler in borg in /mnt🔒 on â˜ï¸Â  (us-east-1) took 6s > ⯠sudo chmod +r /var/crash/* > > ler in borg in /mnt🔒 on â˜ï¸Â  (us-east-1) > ⯠kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel > GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] > Copyright (C) 2021 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-portbld-freebsd14.0". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: >     . > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /mnt/boot/kernel/kernel... > (No debugging symbols found in /mnt/boot/kernel/kernel) > /wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: > internal-error: void switch_to_thread(thread_info *): Assertion `thr != > NULL' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) n > > This is a bug, please report it.  For instructions, see: > . > > /wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: > internal-error: void switch_to_thread(thread_info *): Assertion `thr != > NULL' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Create a core file of GDB? (y or n) n > Command aborted. > (kgdb) bt > No thread selected. > (kgdb) fr 8 > No thread selected. > (kgdb) > >>> On 12/10/2021 10:36 am, Alexander Motin wrote: >>> > Hi Larry, >>> > >>> > This looks like some use-after-free or otherwise corrupted callout >>> > structure.  Unfortunately the backtrace does not tell what was the >>> > callout.  When was the previous update to look what could change? >>> > >>> > On 10.12.2021 11:24, Larry Rosenman wrote: >>> >> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15 >>> >> main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021 >>> >> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL >>> >> amd64 >>> >> >>> >> VMCORE *IS* available. >>> >> >>> >> >>> >> >>> >> >>> >> Unread portion of the kernel message buffer: >>> >> kernel trap 12 with interrupts disabled >>> >> >>> >> >>> >> Fatal trap 12: page fault while in kernel mode >>> >> cpuid = 0; apic id = 20 >>> >> fault virtual address   = 0x0 >>> >> fault code              = supervisor write data, page not present >>> >> instruction pointer     = 0x20:0xffffffff804e0db4 >>> >> stack pointer           = 0x0:0xfffffe0434de4e10 >>> >> frame pointer           = 0x0:0xfffffe0434de4e70 >>> >> code segment            = base 0x0, limit 0xfffff, type 0x1b >>> >>                         = DPL 0, pres 1, long 1, def32 0, gran 1 >>> >> processor eflags        = resume, IOPL = 0 >>> >> current process         = 82990 (c++) >>> >> trap number             = 12 >>> >> panic: page fault >>> >> cpuid = 0 >>> >> time = 1639111198 >>> >> KDB: stack backtrace: >>> >> #0 0xffffffff8050fc95 at kdb_backtrace+0x65 >>> >> #1 0xffffffff804c468f at vpanic+0x17f >>> >> #2 0xffffffff804c4503 at panic+0x43 >>> >> #3 0xffffffff807a2195 at trap_fatal+0x385 >>> >> #4 0xffffffff807a21ef at trap_pfault+0x4f >>> >> #5 0xffffffff80779c78 at calltrap+0x8 >>> >> #6 0xffffffff8045ddb8 at handleevents+0x188 >>> >> #7 0xffffffff8045ea3e at timercb+0x24e >>> >> #8 0xffffffff807ca9eb at lapic_handle_timer+0x9b >>> >> #9 0xffffffff8077b9b1 at Xtimerint+0xb1 >>> >> Uptime: 2h28m57s >>> >> Dumping 12829 out of 131023 >>> >> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% >>> >> >>> >> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >>> >> 55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" >>> >> (offsetof(struct pcpu, >>> >> (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >>> >> #1  doadump (textdump=) >>> >>     at /usr/src/sys/kern/kern_shutdown.c:399 >>> >> #2  0xffffffff804c428c in kern_reboot (howto=260) >>> >>     at /usr/src/sys/kern/kern_shutdown.c:487 >>> >> #3  0xffffffff804c46fe in vpanic (fmt=0xffffffff807e1276 "%s", >>> >>     ap=) at /usr/src/sys/kern/kern_shutdown.c:920 >>> >> #4  0xffffffff804c4503 in panic (fmt=) >>> >>     at /usr/src/sys/kern/kern_shutdown.c:844 >>> >> #5  0xffffffff807a2195 in trap_fatal (frame=0xfffffe0434de4d50, >>> eva=0) >>> >>     at /usr/src/sys/amd64/amd64/trap.c:946 >>> >> #6  0xffffffff807a21ef in trap_pfault (frame=0xfffffe0434de4d50, >>> >>     usermode=false, signo=, ucode=) >>> >>     at /usr/src/sys/amd64/amd64/trap.c:765 >>> >> #7  >>> >> #8  0xffffffff804e0db4 in callout_process >>> >> (now=now@entry=38385536922300) >>> >>     at /usr/src/sys/kern/kern_timeout.c:488 >>> >> #9  0xffffffff8045ddb8 in handleevents (now=now@entry=38385536922300, >>> >>     fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 >>> >> #10 0xffffffff8045ea3e in timercb (et=0xffffffff80d475e0 , >>> >>     arg=) at /usr/src/sys/kern/kern_clocksource.c:357 >>> >> #11 0xffffffff807ca9eb in lapic_handle_timer >>> >> (frame=0xfffffe0434de4f40) >>> >>     at /usr/src/sys/x86/x86/local_apic.c:1364 >>> >> #12 >>> >> #13 0x000000080df42bb6 in ?? () >>> >> Backtrace stopped: Cannot access memory at address 0x7ffffdef2c90 >>> >> (kgdb) > From nobody Tue Dec 21 20:08:25 2021 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 B67B91916147 for ; Tue, 21 Dec 2021 20:08:40 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJSFg1f4jz3JfR; Tue, 21 Dec 2021 20:08:39 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-ed1-x52e.google.com with SMTP id j21so52113687edt.9; Tue, 21 Dec 2021 12:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nqStmxbRroiJPg4MJezFFA+jwZUL1dF8yeynrD32/88=; b=cKOrD6StAXxBLByCkpM5vegnUaNQDrmrR3iIOEWW8Qlv0VcIKip889G5vKrdis8YE0 n6LPyF400zSUhm3d/SnnGWQKizx8r1uqUGXiYnsBhxrXFU4JHpSHPraTAK6b5pzwzk/S mmeDt74y4CkxShBBHu7Cii+C2jTQELJGicYkErWMQ6nj+F6q+tq8oNA4j3L8RY6Xlpje UlPwCi0mw+yEV1hhzWs/SgxQe4d5fTU+r8Y58vHtEUe1+HUXByYTZPyVSfiKkdJUqED1 fGoXoarM+nLdpxz1GU4ZscTyWDlfOBneC2dxllZ7JZkOPO3NHQGPjUB/+cRN7b8UM7Vh 3qEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nqStmxbRroiJPg4MJezFFA+jwZUL1dF8yeynrD32/88=; b=HQb6T6t9m05Kgh37ag1nL2i94ApjswZgZJ1dh+FstKfgTpuiCZdkDN2BawHfcH4UvK nsr9Guz366isFSB1zYtlwMMgC/SgH6jq1eAKTK7QAaJBA0EgfVIkNU9G3q7Xr/gHJfEl Q/dyfkpH8URZkMnNNzLLJy1QVyazUztKecZpnMXK8vv9LlqefTZivjx4FsCtOX+BEKJu aG9K99LXi1vFxtv2v5j1b7foDfmmRjuFzWoQOyXkIjnaZbWo4nKbddbgRG9grCbci2oJ /eR8rZqqnTEgu81vTZhk/8otpxgtOmo4CB0qxJivwY8wz/Pt8QhB+2D9BN3zw8WKKKnO WORA== X-Gm-Message-State: AOAM533tu6TELIu7nmJd7aVsn7j3h53IyfjjSiEaiaf2ovNNm6pWevj+ 9AgOjAjmcdbbO6DvSmNJrA/6i0rIZ2b3lAhCO3jiP9hBL/gJFA== X-Google-Smtp-Source: ABdhPJzO/5Bnxo9PFS9z4jmLL751CoBOBbkhU6XT5r6hwgvTs9GldBUF+QNXq2SeHXHeC2byfCh6c/MCh334Z6HIyd8= X-Received: by 2002:a05:6402:440b:: with SMTP id y11mr4845155eda.226.1640117317027; Tue, 21 Dec 2021 12:08:37 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211209152010.z6ofqf3ucpxkijqf@mutt-hbsd> <20211209183409.2xbfgszx7miw3rhv@mutt-hbsd> In-Reply-To: <20211209183409.2xbfgszx7miw3rhv@mutt-hbsd> From: Dustin Marquess Date: Tue, 21 Dec 2021 14:08:25 -0600 Message-ID: Subject: Re: Kernel panic in networking code To: Shawn Webb Cc: Mark Johnston , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JJSFg1f4jz3JfR X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=cKOrD6St; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dmarquess@gmail.com designates 2a00:1450:4864:20::52e as permitted sender) smtp.mailfrom=dmarquess@gmail.com X-Spamd-Result: default: False [1.61 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.62)[0.617]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52e:from]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_SPAM_LONG(1.00)[0.996]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Thu, Dec 9, 2021 at 12:35 PM Shawn Webb wrote: > > On Thu, Dec 09, 2021 at 12:05:30PM -0500, Mark Johnston wrote: > > On Thu, Dec 09, 2021 at 10:20:10AM -0500, Shawn Webb wrote: > > > Hey all, > > > > > > It looks like there's a potential deadlock in some networking code, > > > specifically with ipv4 jails. I can reproduce by running Poudriere on > > > 14-CURRENT. > > > > > > I am using HardenedBSD 14-CURRENT, but we don't have any changes to > > > any point in the code paths that would trigger/cause this kind of > > > kernel panic. > > > > > > I've uploaded the crash.txt file here: > > > https://hardenedbsd.org/~shawn/2021-12-09_crash-01.txt > > > > There is some WIP to address this in https://reviews.freebsd.org/D33339 > > and its followup revision. > > Awesome. Thanks for the response! I'll follow along. I'm happy to test > out the patch before it lands if needed/wanted. I've been running glebius's revised D33339 patch from Friday on my HardenedBSD -CURRENT box since he posted it, and I haven't had any jail related issues since. Granted I'm not running pourdriere builds either, but I guess I could kick one off... -Dustin From nobody Tue Dec 21 21:04:49 2021 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 C471118F8ACE for ; Tue, 21 Dec 2021 21:04:58 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (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 "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJTVd6xQSz4pqP; Tue, 21 Dec 2021 21:04:57 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1640120689; bh=deGO36jFBujXJ1t0qyukqboKma5hfIHkOBXz gzVvr4A=; b=PHJ3SvshfhBWhtwUuwys8LGi+HAWtPOENH+Z8bw8LZfOQiUdI5zU BfRmPf4jxsCcivuMG5FZR39taCAusHt35xpWgfeFFcwQcnJpXanSN+AvAgXelmju SooN+ke8FVNbFJQCg0+2090Kwv0F5yLgF7X/y5+y4O6s2s/2UfFdCuE= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id E4F0B4CCA7; Tue, 21 Dec 2021 16:04:49 -0500 (EST) Message-ID: <0602f537-88ed-d5d6-1077-84a6d8588f1c@protected-networks.net> Date: Tue, 21 Dec 2021 16:04:49 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Panic: Page Fault in Kernel: Yesterday's CURRENT Content-Language: en-NZ To: Larry Rosenman , Mark Johnston Cc: Alexander Motin , Freebsd current References: <3d1b5249a2c51670de496fad9e8b054c@lerctr.org> <9852ae04-6dd0-1cd4-13fe-e97c68e71b37@FreeBSD.org> <311ce6f4-9fa8-0514-193d-6be841af26b2@protected-networks.net> In-Reply-To: <311ce6f4-9fa8-0514-193d-6be841af26b2@protected-networks.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JJTVd6xQSz4pqP X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=PHJ3Svsh; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 2001:470:8d59:1::8 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-2.01 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.99)[0.986]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N Confirmed. The kernel at .. FreeBSD 14.0-CURRENT #0 f06f1d1fdb9: Mon Dec 20 12:24:51 EST 2021 .. boots successfully. The kernel at .. FreeBSD 14.0-CURRENT #1 553af8f1ec7: Tue Dec 21 15:16:10 EST 2021 .. fails immediately after printing something like .. Timecounters tick every 1.000 msec Timecounter "TSC" frequency 701570048 Hz quality 800 .. but before initializing ipfw as it used to, Michael On 12/21/21 12:01, Michael Butler via freebsd-current wrote: > I have an old pentium-3 that also won't boot kernels built after Dec 6th. > > I suspect the commits listed below but, with the device being remote and > having no DRAC, I'm struggling to test this theory. > > The relevant commits .. > > commit 553af8f1ec71d397b5b4fd5876622b9269936e63 > Author: Mark Johnston > Date:   Mon Dec 6 10:42:19 2021 -0500 > >     x86: Perform late TSC calibration before LAPIC timer calibration > > commit 62d09b46ad7508ae74d462e49234f0a80f91ff69 > Author: Mark Johnston > Date:   Mon Dec 6 10:42:10 2021 -0500 > >     x86: Defer LAPIC calibration until after timecounters are available > > It's currently running git rev e43d081f352 and I have a kernel at git > rev f06f1d1fdb969fa7a0a6eefa030d8536f365eb6e to test later this evening, > >     Michael > > > On 12/17/21 15:07, Larry Rosenman wrote: >> On 12/17/2021 1:36 pm, Mark Johnston wrote: >>> On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote: >>>> 14-2021_12_07-1217             -      -          1.87G 2021-12-07 12:17 >>>> 14-2021_12_09-1957             NR     /          121G  2021-12-09 19:57 >>>> >>>> If that's any help >>> >>> I can't tell what this is saying.  A kernel built on the 7th does not >>> crash, or...?  Which revision did you update from before you started >>> seeing crashes? >>> >>> From a kgdb session it'd be useful to see output from >>> >>> (kgdb) frame 8 >>> (kgdb) p/x *tmp >>> >>> to start. >>> >> >> Correct, the 7th didn't panic, but the 9th did, and yesterday's too. >> >> Grrr >> ler in borg in /mnt🔒 on â˜ï¸Â  (us-east-1) >> ⯠kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel >> GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] >> Copyright (C) 2021 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> Type "show copying" and "show warranty" for details. >> This GDB was configured as "x86_64-portbld-freebsd14.0". >> Type "show configuration" for configuration details. >> For bug reporting instructions, please see: >> . >> Find the GDB manual and other documentation resources online at: >>      . >> >> For help, type "help". >> Type "apropos word" to search for commands related to "word"... >> Reading symbols from /mnt/boot/kernel/kernel... >> (No debugging symbols found in /mnt/boot/kernel/kernel) >> Failed to open vmcore: /var/crash/vmcore.0: Permission denied >> (kgdb) bt >> No stack. >> quitb) >> >> ler in borg in /mnt🔒 on â˜ï¸Â  (us-east-1) took 6s >> ⯠sudo chmod +r /var/crash/* >> >> ler in borg in /mnt🔒 on â˜ï¸Â  (us-east-1) >> ⯠kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel >> GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] >> Copyright (C) 2021 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> Type "show copying" and "show warranty" for details. >> This GDB was configured as "x86_64-portbld-freebsd14.0". >> Type "show configuration" for configuration details. >> For bug reporting instructions, please see: >> . >> Find the GDB manual and other documentation resources online at: >>      . >> >> For help, type "help". >> Type "apropos word" to search for commands related to "word"... >> Reading symbols from /mnt/boot/kernel/kernel... >> (No debugging symbols found in /mnt/boot/kernel/kernel) >> /wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: >> internal-error: void switch_to_thread(thread_info *): Assertion `thr >> != NULL' failed. >> A problem internal to GDB has been detected, >> further debugging may prove unreliable. >> Quit this debugging session? (y or n) n >> >> This is a bug, please report it.  For instructions, see: >> . >> >> /wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: >> internal-error: void switch_to_thread(thread_info *): Assertion `thr >> != NULL' failed. >> A problem internal to GDB has been detected, >> further debugging may prove unreliable. >> Create a core file of GDB? (y or n) n >> Command aborted. >> (kgdb) bt >> No thread selected. >> (kgdb) fr 8 >> No thread selected. >> (kgdb) >> >>>> On 12/10/2021 10:36 am, Alexander Motin wrote: >>>> > Hi Larry, >>>> > >>>> > This looks like some use-after-free or otherwise corrupted callout >>>> > structure.  Unfortunately the backtrace does not tell what was the >>>> > callout.  When was the previous update to look what could change? >>>> > >>>> > On 10.12.2021 11:24, Larry Rosenman wrote: >>>> >> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15 >>>> >> main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021 >>>> >> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL >>>> >> amd64 >>>> >> >>>> >> VMCORE *IS* available. >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> Unread portion of the kernel message buffer: >>>> >> kernel trap 12 with interrupts disabled >>>> >> >>>> >> >>>> >> Fatal trap 12: page fault while in kernel mode >>>> >> cpuid = 0; apic id = 20 >>>> >> fault virtual address   = 0x0 >>>> >> fault code              = supervisor write data, page not present >>>> >> instruction pointer     = 0x20:0xffffffff804e0db4 >>>> >> stack pointer           = 0x0:0xfffffe0434de4e10 >>>> >> frame pointer           = 0x0:0xfffffe0434de4e70 >>>> >> code segment            = base 0x0, limit 0xfffff, type 0x1b >>>> >>                         = DPL 0, pres 1, long 1, def32 0, gran 1 >>>> >> processor eflags        = resume, IOPL = 0 >>>> >> current process         = 82990 (c++) >>>> >> trap number             = 12 >>>> >> panic: page fault >>>> >> cpuid = 0 >>>> >> time = 1639111198 >>>> >> KDB: stack backtrace: >>>> >> #0 0xffffffff8050fc95 at kdb_backtrace+0x65 >>>> >> #1 0xffffffff804c468f at vpanic+0x17f >>>> >> #2 0xffffffff804c4503 at panic+0x43 >>>> >> #3 0xffffffff807a2195 at trap_fatal+0x385 >>>> >> #4 0xffffffff807a21ef at trap_pfault+0x4f >>>> >> #5 0xffffffff80779c78 at calltrap+0x8 >>>> >> #6 0xffffffff8045ddb8 at handleevents+0x188 >>>> >> #7 0xffffffff8045ea3e at timercb+0x24e >>>> >> #8 0xffffffff807ca9eb at lapic_handle_timer+0x9b >>>> >> #9 0xffffffff8077b9b1 at Xtimerint+0xb1 >>>> >> Uptime: 2h28m57s >>>> >> Dumping 12829 out of 131023 >>>> >> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% >>>> >> >>>> >> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 >>>> >> 55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" >>>> >> (offsetof(struct pcpu, >>>> >> (kgdb) #0  __curthread () at >>>> /usr/src/sys/amd64/include/pcpu_aux.h:55 >>>> >> #1  doadump (textdump=) >>>> >>     at /usr/src/sys/kern/kern_shutdown.c:399 >>>> >> #2  0xffffffff804c428c in kern_reboot (howto=260) >>>> >>     at /usr/src/sys/kern/kern_shutdown.c:487 >>>> >> #3  0xffffffff804c46fe in vpanic (fmt=0xffffffff807e1276 "%s", >>>> >>     ap=) at /usr/src/sys/kern/kern_shutdown.c:920 >>>> >> #4  0xffffffff804c4503 in panic (fmt=) >>>> >>     at /usr/src/sys/kern/kern_shutdown.c:844 >>>> >> #5  0xffffffff807a2195 in trap_fatal (frame=0xfffffe0434de4d50, >>>> eva=0) >>>> >>     at /usr/src/sys/amd64/amd64/trap.c:946 >>>> >> #6  0xffffffff807a21ef in trap_pfault (frame=0xfffffe0434de4d50, >>>> >>     usermode=false, signo=, ucode=) >>>> >>     at /usr/src/sys/amd64/amd64/trap.c:765 >>>> >> #7  >>>> >> #8  0xffffffff804e0db4 in callout_process >>>> >> (now=now@entry=38385536922300) >>>> >>     at /usr/src/sys/kern/kern_timeout.c:488 >>>> >> #9  0xffffffff8045ddb8 in handleevents >>>> (now=now@entry=38385536922300, >>>> >>     fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 >>>> >> #10 0xffffffff8045ea3e in timercb (et=0xffffffff80d475e0 , >>>> >>     arg=) at /usr/src/sys/kern/kern_clocksource.c:357 >>>> >> #11 0xffffffff807ca9eb in lapic_handle_timer >>>> >> (frame=0xfffffe0434de4f40) >>>> >>     at /usr/src/sys/x86/x86/local_apic.c:1364 >>>> >> #12 >>>> >> #13 0x000000080df42bb6 in ?? () >>>> >> Backtrace stopped: Cannot access memory at address 0x7ffffdef2c90 >>>> >> (kgdb) >> > > From nobody Tue Dec 21 21:42:29 2021 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 7A3F919016F8 for ; Tue, 21 Dec 2021 21:42:34 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJVL15Gygz3DQQ for ; Tue, 21 Dec 2021 21:42:33 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x336.google.com with SMTP id g191-20020a1c9dc8000000b0032fbf912885so307315wme.4 for ; Tue, 21 Dec 2021 13:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:to:content-language:from :subject:content-transfer-encoding; bh=+sEpVDFVgp6BH+EZWyqsiqXrIqdBF+o2v14OfzvVZqE=; b=YWcDCmE5OsrRvX7b8wKvSe9vZpqvS5hdGFuLlOMhVMbbBDcXzGNBERs7l8wDcPMw6v luNQQP3f7irdRu6uX/tcwq2ItLUcK2ruEqHw0gdlAmJSv6YTnZMmkBPyV3ycnonz5ZZX 1WQqDvtPBViPgOItIOChm5Z7sFMi3GMfbbzgBL/+n5AqV/YIh/015ftPoz8uHcA0S4L+ WyftM5pQkXGNnyfsxON3qeuBd5JOKZr7gTGh7qTA7L47/t5vRkxEZkOXYGHftZCzAYtd jv0mwpeZ/phwQXtW57o+NelsI25c9+CGVQcClWb8m23UxEHIXe1cny+HOF1H3aIOeGlH wYKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to :content-language:from:subject:content-transfer-encoding; bh=+sEpVDFVgp6BH+EZWyqsiqXrIqdBF+o2v14OfzvVZqE=; b=61v5kJh6bEQKQaqwh0jsSglpBQhZNDx5mLdzUBNmRhC1Q0tskBKzCoH/0HoQ4oCLB8 nd0LNJT4tXY5GanJ9ZvKcFcmADrHN/9Kol7R8TPlq0Q03G7I3azhPFPDBK0XC4XxSr90 B+lhtgoHR1eA7q0RfLMkIqGBAbtNaU6AL4VYZw87y3ijNdIhjqxeaXYHTYK/cVGGmSQ5 FIHXKgB6bJ0GhSIb0GWMPUb0VYBejCOpuBKFKF0Fjx+rudjnTmT/2AgiWqmRFiRlLxS8 jb9GpvwyA+g+xKydsrhWyE7Uo8nneBxKvcY/wzfDUZNpEuxu/ZD1Yy+x6GCnTRnSJwKO pREQ== X-Gm-Message-State: AOAM532A/SM6opAXQh6wj9+/7xLDYzqpOK4PnOZYI+4Sa8MpozIlRAHP 3O1128d6CmtRFOf78+Aq6CLErTwMra8xYQ== X-Google-Smtp-Source: ABdhPJxnd9UWmcFLl6aULIx6w2TSQHYKiCVAX1elmhsjj6OSBO8h6zHjVpN6ugbYAMJVtQ/Pxclv+Q== X-Received: by 2002:a05:600c:5025:: with SMTP id n37mr308134wmr.18.1640122952493; Tue, 21 Dec 2021 13:42:32 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id d5sm3226102wms.28.2021.12.21.13.42.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Dec 2021 13:42:29 -0800 (PST) Message-ID: Date: Tue, 21 Dec 2021 21:42:29 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: FreeBSD CURRENT Content-Language: en-GB From: Graham Perrin Subject: =?UTF-8?Q?pkg_upgrade_-n_-f=3a_Child_process_pid=3d=e2=80=a6_termin?= =?UTF-8?Q?ated_abnormally=3a_Segmentation_fault?= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JJVL15Gygz3DQQ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=YWcDCmE5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::336 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-0.03 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::336:from]; NEURAL_SPAM_SHORT(0.97)[0.973]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Is the fault maybe because the OS is outdated (1400043)? Updating FreeBSD repository catalogue... Fetching packagesite.pkg: 100% 6 MiB 1.1MB/s 00:06 pkg: cannot parse fingerprints: error while parsing : line: 1, column: 0 - 'key must begin with a letter', character: '-' Processing entries: 0% pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:14:amd64 Processing entries: 100% Unable to update repository FreeBSD Updating poudriere repository catalogue... poudriere repository is up to date. Error updating repositories! Checking for upgrades (2448 candidates): 89% Child process pid=47594 terminated abnormally: Segmentation fault root@mowa219-gjp4-8570p-freebsd:~# pkg upgrade Updating FreeBSD repository catalogue... Fetching packagesite.pkg: 100% 6 MiB 1.1MB/s 00:06 pkg: cannot parse fingerprints: error while parsing : line: 1, column: 0 - 'key must begin with a letter', character: '-' Processing entries: 0% Newer FreeBSD version for package munge: To ignore this error set IGNORE_OSVERSION=yes - package: 1400045 - running kernel: 1400043 Ignore the mismatch and continue? [y/N]: y Processing entries: 100% Fetching provides database: 100% 15 MiB 1.2MB/s 00:13 Extracting database....success FreeBSD repository update completed. 31167 packages processed. Updating poudriere repository catalogue... poudriere repository is up to date. All repositories are up to date. Checking for upgrades (122 candidates): 100% Processing candidates (122 candidates): 100% The following 105 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: amfora: 1.8.0_1 -> 1.9.1 [FreeBSD] … virtual_oss: 1.2.15 -> 1.2.16 [FreeBSD] Number of packages to be upgraded: 105 283 MiB to be downloaded. Proceed with this action? [y/N]: n root@mowa219-gjp4-8570p-freebsd:~# pkg upgrade -n -f Updating FreeBSD repository catalogue... FreeBSD repository is up to date. Updating poudriere repository catalogue... poudriere repository is up to date. All repositories are up to date. Checking for upgrades (2448 candidates): 89% Child process pid=48795 terminated abnormally: Segmentation fault root@mowa219-gjp4-8570p-freebsd:~# From nobody Wed Dec 22 07:21:35 2021 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 0FB2A1900302 for ; Wed, 22 Dec 2021 07:22:13 +0000 (UTC) (envelope-from kjopek@gmail.com) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJlBr1rRyz3k4J for ; Wed, 22 Dec 2021 07:22:12 +0000 (UTC) (envelope-from kjopek@gmail.com) Received: by mail-il1-x12f.google.com with SMTP id w1so1100109ilh.9 for ; Tue, 21 Dec 2021 23:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tmDqIC7X9hmijttFb7Fu8/l6aQhiNwhYiYzvK/ctk9Q=; b=iRsnkCGUiI+qcYagHXaXLPJLlOkZHMZNgsVJUvg1Weum4k82nGoCJPhQCtXKv9k2cu J3r36sSisXAZlwWJ0cbV2b1eLsXRHtn+ZMrGwgL9tN0ldTXKRakdfuqEVN6zDZRKOzEd pfOXdCVNwywZlD/J8fXFBNqxYYmelykKQZmxm6+rJ4V90HyqH5vVF0eJ6IdniNQhEkAK Qi5+Ove2UoSLZw87JBlI0r9oDsk3xpAfzg3YcpUJSZepBcHXP/462lZl230SbhIXPs/d Ma9lVmPqQSrTxFyZJscql6+dniqYKmBWjghZH1qTaGCVqTU6DygONCbRtRk7+l8v3Yo7 WpkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tmDqIC7X9hmijttFb7Fu8/l6aQhiNwhYiYzvK/ctk9Q=; b=cMFtb28HnkAiDDyzi/hlEGdEsp9qAgZjs2UNsay0tXeXswzvnyeLirwWoOMpnAPo6Y Vrhj7wOlZThPgf4FNmHqi7MKAKqGLduHRaRGmjrg4rcOxW54M1nvWB9H/iRKFlQEgxK2 XuotwcqsEwn5v/fDlq4SjXX4EjXptk4H7rgDzCIypSPM0DO/XHbv3/+4ttCsryWLtrZW 4aLPz4LGQP8/b7OCvg1PbTG8mA3mObwdAJBrBXsskaJHUaGUExSmGZYPD1eY9qT1mfZb XZk8aLJ40sQ0+W+msFMgV0Zqo5aMz9Ympv92/TWDUunxBsr4k/W0syiMrTJzf/XRJBwh eRyg== X-Gm-Message-State: AOAM530CWhvCaMVtRyi+T9cLnQXYuEJuInSzDh5WzkFPtUNU8eUBaHmD 73y9YxZDnqMODi8hgCS6FiCb1uKTLh1PHq3zuQ== X-Google-Smtp-Source: ABdhPJyCQPW4wmPSlsYkAwmrlFGLCCuOs7kAbY9pMOGhCpCcwulll1Kbdvx29Yz3o3uwEvVnumaHXQ3xgvualV0cot4= X-Received: by 2002:a05:6e02:78e:: with SMTP id q14mr750949ils.105.1640157731666; Tue, 21 Dec 2021 23:22:11 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211219114723.338b235e@ernst.home> <61bf1204.1c69fb81.2c8fc.3280SMTPIN_ADDED_BROKEN@mx.google.com> <20211219122443.1c84093f@ernst.home> In-Reply-To: <20211219122443.1c84093f@ernst.home> From: =?UTF-8?B?S29ucmFkIFNld2nFgsWCby1Kb3Blaw==?= Date: Wed, 22 Dec 2021 08:21:35 +0100 Message-ID: Subject: Re: WITHOUT_PF breaks buildworld To: gljennjohn@gmail.com Cc: Alastair Hogge , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000f8bee505d3b6fa5b" X-Rspamd-Queue-Id: 4JJlBr1rRyz3k4J X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=iRsnkCGU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kjopek@gmail.com designates 2607:f8b0:4864:20::12f as permitted sender) smtp.mailfrom=kjopek@gmail.com X-Spamd-Result: default: False [-2.75 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; R_MIXED_CHARSET(1.25)[subject]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12f:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000f8bee505d3b6fa5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think the reason is somewhere in tools/build/test-includes: --- net/if_pfsync.o --- In file included from net/if_pfsync.c:1: In file included from [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56: [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: 'netpfil/pf/pf.h' file not found #include ^~~~~~~~~~~~~~~~~ 1 error generated. *** [net/if_pfsync.o] Error code 1 make[3]: stopped in [...]freebsd/tools/build/test-includes --- net/pfvar.o --- In file included from net/pfvar.c:1: [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: 'netpfil/pf/pf.h' file not found #include ^~~~~~~~~~~~~~~~~ 1 error generated. *** [net/pfvar.o] Error code 1 make[3]: stopped in [...]freebsd/tools/build/test-includes 2 errors make[3]: stopped in [...]freebsd/tools/build/test-includes *** [test-includes] Error code 2 make[2]: stopped in [...]freebsd 1 error Best regards, Konrad Sewi=C5=82=C5=82o-Jopek niedz., 19 gru 2021 o 12:26 Gary Jennejohn napisa=C5=82(a): > On Sun, 19 Dec 2021 19:05:35 +0800 > Alastair Hogge wrote: > > > On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote: > > > Some recent change, probably in a .mk file, breaks builworld on HEAD > > > when WITHOUT_PF is enabled in src.conf. > > > > I have had to disable WITHOUT_PF since 2020-07-27, but probably earlier= . > > > > Hmm. I did a successful buildworld a few days ago with WITHOUT_PF > enabled, so it's new breakge for me at least. > > I don't enable pf in the kernel and don't need it in userland. > > > > Disabling WITHOUT_PF results in a successful buildworld. > > > > > > The reported error is that netpfil/pf/pf.h can't be found. > > > > Some ports depend on that too. > > > > It may not be a problem for ports. Depends on where they look for > it. The file is still there under /sys and /usr/include. > > -- > Gary Jennejohn > > --000000000000f8bee505d3b6fa5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think= the reason is somewhere in tools/build/test-includes:

=
--- net/if_pfsync.o ---
In file included from net/if_pfsync.c:1:In file included from [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pf= sync.h:56:
[...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10:= fatal error: 'netpfil/pf/pf.h' file not found
#include <netp= fil/pf/pf.h>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~~~~~~~~~~~~
1= error generated.
*** [net/if_pfsync.o] Error code 1

make[3]: sto= pped in [...]freebsd/tools/build/test-includes
--- net/pfvar.o ---
In= file included from net/pfvar.c:1:
[...]freebsd/arm64.aarch64/tmp/usr/in= clude/net/pfvar.h:65:10: fatal error: 'netpfil/pf/pf.h' file not fo= und
#include <netpfil/pf/pf.h>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0^~~~~~~~~~~~~~~~~
1 error generated.
*** [net/pfvar.o] Error code = 1

make[3]: stopped in [...]freebsd/tools/build/test-includes
2 er= rors

make[3]: stopped in [...]freebsd/tools/build/test-includes
*= ** [test-includes] Error code 2

make[2]: stopped in [...]freebsd
= 1 error

Best regards,
Konrad Sewi=C5=82=C5= =82o-Jopek


niedz., 19 gru 2021= o 12:26=C2=A0Gary Jennejohn <gl= jennjohn@gmail.com> napisa=C5=82(a):
On Sun, 19 Dec 2021 19:05:35 +0800
Alastair Hogge <agh@= riseup.net> wrote:

> On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote:
> > Some recent change, probably in a .mk file, breaks builworld on H= EAD
> > when WITHOUT_PF is enabled in src.conf.=C2=A0
>
> I have had to disable WITHOUT_PF since 2020-07-27, but probably earlie= r.
>

Hmm.=C2=A0 I did a successful buildworld a few days ago with WITHOUT_PF
enabled, so it's new breakge for me at least.

I don't enable pf in the kernel and don't need it in userland.

> > Disabling WITHOUT_PF results in a successful buildworld.
> >
> > The reported error is that netpfil/pf/pf.h can't be found.=C2= =A0
>
> Some ports depend on that too.
>

It may not be a problem for ports.=C2=A0 Depends on where they look for
it.=C2=A0 The file is still there under /sys and /usr/include.

--
Gary Jennejohn

--000000000000f8bee505d3b6fa5b-- From nobody Wed Dec 22 11:04:01 2021 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 9AB0E18F452E for ; Wed, 22 Dec 2021 11:04:03 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJr6q3h6nz3MNL for ; Wed, 22 Dec 2021 11:04:03 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id e5so4116822wrc.5 for ; Wed, 22 Dec 2021 03:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=uFKQbHz7copjVZ/VUF9hq8lP3S2rAnAiinG0dhHl9jY=; b=KHkZmaIBR4hK9rjZcV6cjyR4eyRfDa9XVhp1barJpVVkQnsWkYg/z0Wdr91a+kp0fZ nW0Rr4Rs7beOznARpt+QPlRLCvR37lk9DWfdY9Cp4r62/g4Y1Chtvg0uQjaydorpa2a4 fghKT+/DeDQ1m6pva1/BCONmAjEj10bZ6y/4APmYNGemNT/evbaF6Klya2bRaxzdEF0q YmWegCpCSV99nd2rVRAcT6p+yukcggzNOK7OQx7CXeoiX0cGEvkpoSD/YvOPWfynyo/v z4/jU4eqNkuy9GdxRIqTm40lQnsOCjkIDpFuWhMwjzzn7quZQIRzNYnwRzYpw2ODPSag V1ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=uFKQbHz7copjVZ/VUF9hq8lP3S2rAnAiinG0dhHl9jY=; b=zTjexxLF11x9jUlxct7OvB2caEhqnvrBLjkGjCqLRzSEXsrWrmT74Y3H8Ol9zapVF2 JlY5Kdyxo3eQ4by7+Kh9DdgfwrCvFxnBSz7nQbm2LfnjC/shY/fE9FprxqTrMe31STUg eJc1DCzYFn0/Q6fT8RncedaUCeOnl3YFivZ9mPc+tpjBXmc22Pc3oJ55ahwd2skxZdiX yqLzrY5578sGCabOcLnXMFQWJw8d8+s70dNG+tal0Stxp3Tq7VTRRM/d7Vh3VQ32eHoz trhL+UnGmkwhXe6hsyUkGUmYW03ASSCpHhw1EzAP0yZawKPrb5b9u4r5cQTTaPlfNJ6D gctg== X-Gm-Message-State: AOAM531Doe5RYZFHYM/gC+UWSScX2B2BSCOUydn2fMihkDN/f0jjW6to jq6k/lUVZZHnWWNDPco0HKg= X-Google-Smtp-Source: ABdhPJxSLu6xjcvlgcTk63FcurBuWrhXPXG8v2RbYv5nSiFD2MwFBt9XCQqh0sVpXBcxgPSAcxH9fg== X-Received: by 2002:a5d:5255:: with SMTP id k21mr1860119wrc.381.1640171042588; Wed, 22 Dec 2021 03:04:02 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id d2sm1396283wmb.31.2021.12.22.03.04.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Dec 2021 03:04:02 -0800 (PST) Date: Wed, 22 Dec 2021 12:04:01 +0100 From: Gary Jennejohn To: Konrad =?ISO-8859-1?B?U2V3aT8/by1Kb3Blaw==?= Cc: Alastair Hogge , freebsd-current@freebsd.org Subject: Re: WITHOUT_PF breaks buildworld Message-ID: <20211222120401.7a9b7817@ernst.home> In-Reply-To: References: <20211219114723.338b235e@ernst.home> <61bf1204.1c69fb81.2c8fc.3280SMTPIN_ADDED_BROKEN@mx.google.com> <20211219122443.1c84093f@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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: 8bit X-Rspamd-Queue-Id: 4JJr6q3h6nz3MNL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 22 Dec 2021 08:21:35 +0100 Konrad Sewi??o-Jopek wrote: > Hi, > > I think the reason is somewhere in tools/build/test-includes: > > --- net/if_pfsync.o --- > In file included from net/if_pfsync.c:1: > In file included from > [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56: > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: > 'netpfil/pf/pf.h' file not found > #include > ^~~~~~~~~~~~~~~~~ > 1 error generated. > *** [net/if_pfsync.o] Error code 1 > > make[3]: stopped in [...]freebsd/tools/build/test-includes > --- net/pfvar.o --- > In file included from net/pfvar.c:1: > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: > 'netpfil/pf/pf.h' file not found > #include > ^~~~~~~~~~~~~~~~~ > 1 error generated. > *** [net/pfvar.o] Error code 1 > > make[3]: stopped in [...]freebsd/tools/build/test-includes > 2 errors > > make[3]: stopped in [...]freebsd/tools/build/test-includes > *** [test-includes] Error code 2 > > make[2]: stopped in [...]freebsd > 1 error > Could be. With WITHOUT_PF include/netpfil/pf/pf.h disappears from obj. But since buildworld still tries to build net/if_pfsync.c and other pf-related binaries the buildworld fails. One would thank the WITHOUT_PF should also block building ALL pf-related binaries, but that's not the case. -- Gary Jennejohn From nobody Wed Dec 22 11:51:45 2021 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 BD02618FEDAB for ; Wed, 22 Dec 2021 11:51:51 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJs9y5VgSz3khZ for ; Wed, 22 Dec 2021 11:51:50 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x430.google.com with SMTP id s1so4357542wra.6 for ; Wed, 22 Dec 2021 03:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=yu+mZ7XWQufe4E1rNWzwAAsQTE4sG1/Bi4iqGg/RzgA=; b=b2s5itMBl3ZBSTPOU8v8ueljgjKHC6TiwQyBNBmZOkXOAdF7ar4xnUZZwili2rzD4L imQBB6SJMFvYddWiyOUZufLjt7lrhRVoOlGZoClx6zHB7ROMkj0yWfyIa4FokjVMnzqN ZyhhTS+zqi8AB9iJ3xLaOlAu16RAPU72qCSeqGJ7ashjV4QaFZgGacVXf8H9fFG4g1xe 3+hzMnHukYUuOxj9iBeAMaeAbZKoXcW/kuF+lR77T3hP1m6ZNM+wbufTswuofNdxf0Bj niaFMnrR5gsRAuqB6M5ieOQAv0CSkmmQZb7a+f5JG1StqxN9NRiAEnCkO5XB1b0U9AeL QDJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=yu+mZ7XWQufe4E1rNWzwAAsQTE4sG1/Bi4iqGg/RzgA=; b=O9WjpId+fj5WAtjZUBI1Hqxd052FLJqaKDNViRn5wadlKNGGVBouqc1gp+5GBG5AqV EXbMtqT6KB+Kc70AQNJEBmQ6udR1BQaQ65xT+C4828NDOt4RjQMAm0mHTozqEzSe+au/ L4RhpnXjDhV/XQiivu7dDqrnmCmsIskdQz9d2BefZ7EBy+YDwLoAbnAYaMZ/GpA8NlU0 M1h+OesTJk/r3vz2R3BTTocNXlwNSNV8Uhl4vGTsP3Lkl37bceMb67WH6aSpezmkvPwC 54GXFzpEtFoeupyUNejr3GlZ8xGILNqWs00TeTARlVIWndwLScNhLvCNp6dNpqduDIuP lYEw== X-Gm-Message-State: AOAM532G+doUdQbYILJGDIywdZT0XAnC1Qb0h13J+Q7rOfjoe8ytAMxO ePK5fCnzgQVj62Bu3EEuSwE= X-Google-Smtp-Source: ABdhPJz13c8TVk+Nft+weEuACDMYtgyN+fvv9YmYuw+wKLFNOKRyVYKB7JbdX44Bh6I15SjqDK40+Q== X-Received: by 2002:a05:6000:104f:: with SMTP id c15mr1851743wrx.665.1640173909733; Wed, 22 Dec 2021 03:51:49 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id r62sm1542852wmr.35.2021.12.22.03.51.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Dec 2021 03:51:49 -0800 (PST) Date: Wed, 22 Dec 2021 12:51:45 +0100 From: Gary Jennejohn To: Konrad Sewi??o-Jopek Cc: Alastair Hogge , freebsd-current@freebsd.org Subject: Re: WITHOUT_PF breaks buildworld Message-ID: <20211222125145.344d3681@ernst.home> In-Reply-To: <20211222120401.7a9b7817@ernst.home> References: <20211219114723.338b235e@ernst.home> <61bf1204.1c69fb81.2c8fc.3280SMTPIN_ADDED_BROKEN@mx.google.com> <20211219122443.1c84093f@ernst.home> <20211222120401.7a9b7817@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JJs9y5VgSz3khZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=b2s5itMB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::430 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::430:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 22 Dec 2021 12:04:01 +0100 Gary Jennejohn wrote: > On Wed, 22 Dec 2021 08:21:35 +0100 > Konrad Sewi??o-Jopek wrote: > > > Hi, > > > > I think the reason is somewhere in tools/build/test-includes: > > > > --- net/if_pfsync.o --- > > In file included from net/if_pfsync.c:1: > > In file included from > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56: > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: > > 'netpfil/pf/pf.h' file not found > > #include > > ^~~~~~~~~~~~~~~~~ > > 1 error generated. > > *** [net/if_pfsync.o] Error code 1 > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > --- net/pfvar.o --- > > In file included from net/pfvar.c:1: > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: > > 'netpfil/pf/pf.h' file not found > > #include > > ^~~~~~~~~~~~~~~~~ > > 1 error generated. > > *** [net/pfvar.o] Error code 1 > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > 2 errors > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > *** [test-includes] Error code 2 > > > > make[2]: stopped in [...]freebsd > > 1 error > > > > Could be. With WITHOUT_PF include/netpfil/pf/pf.h disappears from obj. > But since buildworld still tries to build net/if_pfsync.c and other > pf-related binaries the buildworld fails. > > One would thank the WITHOUT_PF should also block building ALL pf-related > binaries, but that's not the case. > Ah well, pf.h is used in so many places under /usr/src that the best approach might be to simply remove the WITHOUT_PF build option. -- Gary Jennejohn From nobody Wed Dec 22 12:42:48 2021 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 454DF1907701 for ; Wed, 22 Dec 2021 12:42:52 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJtJq4rbHz3rHg for ; Wed, 22 Dec 2021 12:42:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4CC78903 for ; Wed, 22 Dec 2021 12:42:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Wed, 22 Dec 2021 14:42:48 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.1 Content-Language: en-US To: FreeBSD Current From: Andriy Gapon Subject: observations on Ryzen 5xxx (Zen 3) processors Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640176971; 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=mBwlxTZ498Q5wdiQ3+jw/TNwRr0Ewc+MckE9LoALdRc=; b=D34GaINae49uZMtorFWBQ75Q9jtmSDUKaTXC0/iiyyD8cMgq283qr7P8HUKM/PBv0C1sIA gwu6AEiZ1GLd03BBUyko1x//MwD+0o6Mv/wVi39W8yddweKHZZVrhZXVymnZTFUQVNDkjl tSRQ0g6buf0Lkcw1WYzQUNihAIsE4qlF3muqB5FYT3IAjjK4esa8D7GVl3AFIsZYM4qKjA s67s4/S1e4BAAAZAAc+1Pg/h0De+2vyW/nlp0wuDTejPILrAUWveclskXekfq+SEOhDPks 6brZI+hluUa+ceNG8vqWdybcw5d4xK6zDCNfDVO8EY4RuoyaiEZuAL1YFube8Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640176971; a=rsa-sha256; cv=none; b=Rw2Toa9pinGzrCU/y1Fmy/FPdburpF6Fhb/AUxVypUg99IK53dhs1pF2WhhjhhYHBOXtNz OgpZH99c20HSTXPElDGkD29BNyTs1LXAVJ7PlDaU1+Nl1nXzhvBPrL8b8voNqw8mEumBRN 4zZ/hY9YR+I1lUj/JMfOhPGSQYVgaJPf8Yl1TGi9oHkp57HeLMSvj4E0SMlkoOsVnv8bjC aSlcLq4BhAZaIWsrMInY4F2jQerTcaQO0aVarQlCyHR64uvXowFiqpjV/Nh1LbUGOO52Fa LD+46kkHSb3e1KXWxV8SxDpWskSFvAf0c7y+PPA8Z+XCDVMey+nvXLBIoJWnTA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N There have been some reports on strange / unexpected things with Ryzen 5xxx processors. I think I have seen 5950X, 5900X and 5800X mentioned, not sure about others. Since I have 5800X myself I looked into a couple of issues that have straightforward demonstrators. I would like to share my findings and observations on those issues. Issue 1. High wake-up latency for CPU idle states. This seems to be related to the so called CC6 idle state. The official information on it is very sparse. The state is not explicitly exposed to the OS, at least, though ACPI interfaces that FreeBSD currently supports. In my tests I see that if all logical processors enter an idle state then an external interrupt can be delayed by 500+ us. Specifically, I observed this with an MSI-X interrupt from a discrete network chip. Interrupts from internal components seem to be affected as well, but to a lesser degree. The deep state in question can be entered regardless of whether C2 (via I/O) is enabled, C1 (via hlt) is sufficient. In fact, with machdep.idle=hlt it works the same. The state is not entered if at least one logical CPU is not idle. The state is not entered if machdep.idle=mwait is used. Apparently, the processors do not attempt to automatically enter as deep idle modes with mwait as they do with hlt. Finally, the state is not entered if zenstates.py utility is used to disable C6 / CC6 state via an undocumented (publicly) MSR. For me personally that state does not cause any annoyances but anyone who experiences problems related to "stuttering", "jitter", latency might want to look into this. Issue 2. Uneven performance of CPU intensive tasks, especially with SCHED_ULE, when SMT is enabled. I found out that at least on my hardware all even numbered logical CPUs can perform much better than odd numbered logical CPUs. It seems that hardware threads within a core are not equal. Maybe this is related to ability to use boosted frequencies, but maybe something else, I am not sure. From a brief look at the ULE code it looks that the selection of a hw thread within a core is intentionally random when all other things are equal. I suspect that the hardware + firmware may actually describe that performance disparity via ACPI CPPC (_CPC object, etc), but right now we do not support querying that or making use of it. It would interesting to see if other owners of similar processors can confirm or provide counter-examples to my observations. Simple tests for issue 1: - ping a host attached to the same switch (so, with very low expected latency) - ping 127.0.0.1 For issue 2: take some CPU intensive single-threaded task and bind it (with cpuset -l) to different logical CPUs. Multiple such tasks can be run concurrently on different logical CPUs. References: - https://forums.freebsd.org/threads/variable-ping-latency-on-ryzen-setup.82791/ - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594 - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254040 - https://github.com/r4m0n/ZenStates-Linux - https://github.com/meowthink/ZenStates-FreeBSD -- has a bug - https://github.com/avg-I/ZenStates-FreeBSD -- has a fix - https://www.kernel.org/doc/html/latest/admin-guide/acpi/cppc_sysfs.html - https://static.linaro.org/connect/lvc21/presentations/lvc21-219.pdf - https://uefi.org/specs/ACPI/6.4/14_Platform_Communications_Channel/Platform_Comm_Channel.html -- Andriy Gapon From nobody Wed Dec 22 12:49:16 2021 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 7941E1909CDF for ; Wed, 22 Dec 2021 12:49:26 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJtSQ26xXz3tDS; Wed, 22 Dec 2021 12:49:26 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4150D2601E9; Wed, 22 Dec 2021 13:49:24 +0100 (CET) Message-ID: <6dd1ef9f-8f44-a2f1-6377-d2b51fde4d43@selasky.org> Date: Wed, 22 Dec 2021 13:49:16 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: observations on Ryzen 5xxx (Zen 3) processors Content-Language: en-US To: Andriy Gapon , FreeBSD Current References: From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JJtSQ26xXz3tDS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 12/22/21 13:42, Andriy Gapon wrote: > > There have been some reports on strange / unexpected things with Ryzen > 5xxx processors.  I think I have seen 5950X, 5900X and 5800X mentioned, > not sure about others. > > Since I have 5800X myself I looked into a couple of issues that have > straightforward demonstrators.  I would like to share my findings and > observations on those issues. > > Issue 1.  High wake-up latency for CPU idle states. > > This seems to be related to the so called CC6 idle state. > The official information on it is very sparse. > The state is not explicitly exposed to the OS, at least, though ACPI > interfaces that FreeBSD currently supports. > > In my tests I see that if all logical processors enter an idle state > then an external interrupt can be delayed by 500+ us.  Specifically, I > observed this with an MSI-X interrupt from a discrete network chip. > Interrupts from internal components seem to be affected as well, but to > a lesser degree. > > The deep state in question can be entered regardless of whether C2 (via > I/O) is enabled, C1 (via hlt) is sufficient.  In fact, with > machdep.idle=hlt it works the same. > The state is not entered if at least one logical CPU is not idle. > The state is not entered if machdep.idle=mwait is used.  Apparently, the > processors do not attempt to automatically enter as deep idle modes with > mwait as they do with hlt. > Finally, the state is not entered if zenstates.py utility is used to > disable C6 / CC6 state via an undocumented (publicly) MSR. > > For me personally that state does not cause any annoyances but anyone > who experiences problems related to "stuttering", "jitter", latency > might want to look into this. > > Issue 2.  Uneven performance of CPU intensive tasks, especially with > SCHED_ULE, when SMT is enabled. > > I found out that at least on my hardware all even numbered logical CPUs > can perform much better than odd numbered logical CPUs.  It seems that > hardware threads within a core are not equal.  Maybe this is related to > ability to use boosted frequencies, but maybe something else, I am not > sure. > From a brief look at the ULE code it looks that the selection of a hw > thread within a core is intentionally random when all other things are > equal. > I suspect that the hardware + firmware may actually describe that > performance disparity via ACPI CPPC (_CPC object, etc), but right now we > do not support querying that or making use of it. > > > It would interesting to see if other owners of similar processors can > confirm or provide counter-examples to my observations. > > Simple tests for issue 1: > - ping a host attached to the same switch (so, with very low expected > latency) > - ping 127.0.0.1 > > For issue 2: take some CPU intensive single-threaded task and bind it > (with cpuset -l) to different logical CPUs.  Multiple such tasks can be > run concurrently on different logical CPUs. > > References: > - > https://forums.freebsd.org/threads/variable-ping-latency-on-ryzen-setup.82791/ > > - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594 > - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254040 > - https://github.com/r4m0n/ZenStates-Linux > - https://github.com/meowthink/ZenStates-FreeBSD --  has a bug >   - https://github.com/avg-I/ZenStates-FreeBSD -- has a fix > - https://www.kernel.org/doc/html/latest/admin-guide/acpi/cppc_sysfs.html > - https://static.linaro.org/connect/lvc21/presentations/lvc21-219.pdf > - > https://uefi.org/specs/ACPI/6.4/14_Platform_Communications_Channel/Platform_Comm_Channel.html > > Hi, I've seen exactly the same thing. See older FreeBSD-current thread: "AMD Ryzen 5 3400G with Radeon Vega Graphics" I just put: machdep.idle=spin In /boot/loader.conf for now. --HPS From nobody Wed Dec 22 15:27:52 2021 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 4116C1901ED6 for ; Wed, 22 Dec 2021 15:27:56 +0000 (UTC) (envelope-from kp@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJxzH71xXz4ppp; Wed, 22 Dec 2021 15:27:55 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id B88C71A1F; Wed, 22 Dec 2021 15:27:55 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id C33DA41E73; Wed, 22 Dec 2021 16:27:53 +0100 (CET) From: Kristof Provost To: Konrad =?utf-8?b?U2V3acWCxYJvLUpvcGVr?= , Warner Losh Cc: gljennjohn@gmail.com, Alastair Hogge , freebsd-current@freebsd.org Subject: Re: WITHOUT_PF breaks buildworld Date: Wed, 22 Dec 2021 16:27:52 +0100 X-Mailer: MailMate (1.14r5852) Message-ID: <74FC7625-295C-4DEC-BF35-434B5F8D7832@FreeBSD.org> In-Reply-To: References: <20211219114723.338b235e@ernst.home> <61bf1204.1c69fb81.2c8fc.3280SMTPIN_ADDED_BROKEN@mx.google.com> <20211219122443.1c84093f@ernst.home> 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640186876; 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=gbWb6NqjJhgaJDrGhaxhr2iMZ9SP/DHIaVDlMk08w5o=; b=RCcsq1Lg9tc1c7vrXEIVcD9ghHt1U7s5Zt5JdmlsVoRRqiwwTq5AaN0RgiYVAWKsMhF8Wy Mjfa92UtGLMRUwUZREQRBVylex1MdC0vqb2kN05H6AVVHouy8prtY0+FrGnh/7sLQeavev 45nrnehCsLs7AaSdvjHfSvzuV+KUjH640MefQfUg4UQ4JBWF0gDhOInF4kQnfclPDGyN9t 7u9CB9DquLPOxPtv0/Xd66ZvC8TGzuv41z/XKlU8UZy+LjTi6HmDU3rKlkgI+jr4Tlar/t ZUKjlucjzsr+DsAx/3MAwwvpA0aFkcDyL2T+mmJbq6FzzDRpoOtv6k0paADgCA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640186876; a=rsa-sha256; cv=none; b=fFsJyDyJj4NwmdkzbAJTc+KMeg8fOBXSW1wxImHccUMDXdoDVUccaPKH2vMvCaqQLXWnpI SKpP2vPEv+KqYEd4s4V6VfDr8mIT/Ck+8Yzk9tmjVoRcnPBLSldpDXOmrIB1f3C3yWtcs3 GIWJnl2d2myeVlP5OapJdw+bKZyiFN6J8zqae4lhgWdGEIXKOL+8WgYbPVYS5w/0jRalXK BaQMUxgUaWQ8zSpfEpE4OXIXOKznP7eiX6tG/TTV+mTM0q8B8x+DcJRuPcW+1p4WTUiATI qNUfqDRlSenVgRXVHY3PuGVNcC30U1fYyQytrsgTN2y2MPomH7pt60Romjn28g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 22 Dec 2021, at 8:21, Konrad Sewi=C5=82=C5=82o-Jopek wrote: > Hi, > > I think the reason is somewhere in tools/build/test-includes: > > --- net/if_pfsync.o --- > In file included from net/if_pfsync.c:1: > In file included from > [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56: > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal err= or: > 'netpfil/pf/pf.h' file not found > #include > ^~~~~~~~~~~~~~~~~ > 1 error generated. > *** [net/if_pfsync.o] Error code 1 > > make[3]: stopped in [...]freebsd/tools/build/test-includes > --- net/pfvar.o --- > In file included from net/pfvar.c:1: > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal err= or: > 'netpfil/pf/pf.h' file not found > #include > ^~~~~~~~~~~~~~~~~ > 1 error generated. > *** [net/pfvar.o] Error code 1 > > make[3]: stopped in [...]freebsd/tools/build/test-includes > 2 errors > > make[3]: stopped in [...]freebsd/tools/build/test-includes > *** [test-includes] Error code 2 > > make[2]: stopped in [...]freebsd > 1 error > > Best regards, > Konrad Sewi=C5=82=C5=82o-Jopek > > > niedz., 19 gru 2021 o 12:26 Gary Jennejohn > napisa=C5=82(a): > >> On Sun, 19 Dec 2021 19:05:35 +0800 >> Alastair Hogge wrote: >> >>> On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote: >>>> Some recent change, probably in a .mk file, breaks builworld on HEAD= >>>> when WITHOUT_PF is enabled in src.conf. >>> >>> I have had to disable WITHOUT_PF since 2020-07-27, but probably earli= er. >>> >> >> Hmm. I did a successful buildworld a few days ago with WITHOUT_PF >> enabled, so it's new breakge for me at least. >> >> I don't enable pf in the kernel and don't need it in userland. >> >>>> Disabling WITHOUT_PF results in a successful buildworld. >>>> >>>> The reported error is that netpfil/pf/pf.h can't be found. >>> >>> Some ports depend on that too. >>> >> This is the test-includes target, which validates that include files are = self-contained (that is, you can =E2=80=98#include <$file>=E2=80=99 witho= ut prerequisites. The target fails because it looks at all headers in /usr/src/sys and then= tries to build them, but some of those headers (like the pf headers) inc= lude other headers that may not be getting installed because they=E2=80=99= re disabled. I=E2=80=99m not quite sure how to best fix this. Note that it is not happening because some pf tools are still getting bui= lt. This is a validation target that fails. We could potentially add the pf headers to BADHDRS depending on the WITHO= UT_ flag, but that would mean manually maintaining badfiles.inc. Or perhaps we should keep installing the pf headers even when WITHOUT_PF = is set, but I=E2=80=99m not actually sure how we convince the build syste= m to do that. Or if it=E2=80=99s a good idea. Warner might have better ideas on how to fix this. Kristof From nobody Wed Dec 22 16:01:51 2021 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 562831909652 for ; Wed, 22 Dec 2021 16:01:54 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJykT4CNtz3CQ1 for ; Wed, 22 Dec 2021 16:01:53 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm1-x32a.google.com with SMTP id b186-20020a1c1bc3000000b00345734afe78so1788439wmb.0 for ; Wed, 22 Dec 2021 08:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=PnTa5bURcay1PlyHdMOUPLwt2I8Sq/nTyRFDRu1N+e8=; b=ddq61h1mnkWPAxOdwIpFI9BZ9ZQ6+n7n9WfH6kC6wm0ecxvZdYzm7rNsWzPu8HwrHX WDIgIIcYqtbOr48twjmKhjF4nK6jC8jWECgGcF8XlkpnjPBqsAGykaDp4AaOoOCQa6ZV ZTOF4+TwWDF2y7P5Pg4lSdp7vygqmts4jGxLruVdgoi5jxu9vI6umepOpmK7Xicy/1iX W2t2/LkMVvNBNN7ba+cFMV4RDUZePhiYdg1jEKpiD9oVFzHeLphVnpdGU4c/eMJErzN+ LHEmxw+2WQx4dyK/Hg5p90s2MZtkDq8kONkITOR32pMq4Mzi7UxseH7Nm1jaYlviKEt2 dEqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=PnTa5bURcay1PlyHdMOUPLwt2I8Sq/nTyRFDRu1N+e8=; b=cSPMJP38Ti1mk8cvXqj6tmyuvQZUJ5esHD0ubomFpoqF6RsW1COSWzbwnn1ouMUcBe +vpOYsuB7GaE04QnmZfRCt2Hv4sunGWv/RsWHYB0V349FqqwMoMmQeaafv2hvEfWBh5y tIKC1hzIekT7W4lbWnNbn4D20UHOmTel4JlBLfVLf9ptO+NlwDI4LFIAcP7UcbMcCMVh 3rtpHgZmQS8/Q1GBsqgRAtFmOSG2NJarG2SBlA3z9wuZ7yPaQGAlUY1QHmXPbUl0MgK2 PZqbJLZH5rrhEdDscHq5wlVskSqWbVOuoQzDtKWxB8qzcM8QbXPdv5x97ORFs73iSYz0 r4+A== X-Gm-Message-State: AOAM532Gh6P17wOyY7WRE9j+Q9OZheah7ykuVsjjfQ7SaXzDo+HMVHU1 iUMzPTY7l2hr0lpXmhloYsk6e/HvfD4= X-Google-Smtp-Source: ABdhPJwcJc0rMkmAZvNJ5NWBflc/ar+ZQros2HAWWlyIgAtqS5xmb6FTLSNUlkIOCtjtT/npXxh7Dw== X-Received: by 2002:a05:600c:1e05:: with SMTP id ay5mr1367796wmb.131.1640188912580; Wed, 22 Dec 2021 08:01:52 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id f13sm2395480wri.51.2021.12.22.08.01.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Dec 2021 08:01:52 -0800 (PST) Date: Wed, 22 Dec 2021 17:01:51 +0100 From: Gary Jennejohn To: freebsd-current@freebsd.org Subject: Re: WITHOUT_PF breaks buildworld Message-ID: <20211222170151.05a4afe3@ernst.home> In-Reply-To: <20211222165154.33ef54fd@ernst.home> References: <20211219114723.338b235e@ernst.home> <61bf1204.1c69fb81.2c8fc.3280SMTPIN_ADDED_BROKEN@mx.google.com> <20211219122443.1c84093f@ernst.home> <74FC7625-295C-4DEC-BF35-434B5F8D7832@FreeBSD.org> <20211222165154.33ef54fd@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JJykT4CNtz3CQ1 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ddq61h1m; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::32a as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [1.14 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.994]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; NEURAL_SPAM_MEDIUM(0.24)[0.244]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.90)[0.897]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32a:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 22 Dec 2021 16:51:54 +0100 Gary Jennejohn wrote: On Wed, 22 Dec 2021 16:27:52 +0100 Kristof Provost wrote: > On 22 Dec 2021, at 8:21, Konrad Sewi??o-Jopek wrote: > > Hi, > > > > I think the reason is somewhere in tools/build/test-includes: > > > > --- net/if_pfsync.o --- > > In file included from net/if_pfsync.c:1: > > In file included from > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56: > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: > > 'netpfil/pf/pf.h' file not found > > #include > > ^~~~~~~~~~~~~~~~~ > > 1 error generated. > > *** [net/if_pfsync.o] Error code 1 > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > --- net/pfvar.o --- > > > In file included from net/pfvar.c:1: > > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: > > > 'netpfil/pf/pf.h' file not found > > > #include > > > ^~~~~~~~~~~~~~~~~ > > > 1 error generated. > > > *** [net/pfvar.o] Error code 1 > > > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > > 2 errors > > > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > > *** [test-includes] Error code 2 > > > > > > make[2]: stopped in [...]freebsd > > > 1 error > > > > > > Best regards, > > > Konrad Sewi??o-Jopek > > > > > > > > > niedz., 19 gru 2021 o 12:26 Gary Jennejohn > > > napisa?(a): > > > > > >> On Sun, 19 Dec 2021 19:05:35 +0800 > > >> Alastair Hogge wrote: > > >> > > >>> On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote: > > >>>> Some recent change, probably in a .mk file, breaks builworld on HEAD > > >>>> when WITHOUT_PF is enabled in src.conf. > > >>> > > >>> I have had to disable WITHOUT_PF since 2020-07-27, but probably earlier. > > >>> > > >> > > >> Hmm. I did a successful buildworld a few days ago with WITHOUT_PF > > >> enabled, so it's new breakge for me at least. > > >> > > >> I don't enable pf in the kernel and don't need it in userland. > > >> > > >>>> Disabling WITHOUT_PF results in a successful buildworld. > > >>>> > > >>>> The reported error is that netpfil/pf/pf.h can't be found. > > >>> > > >>> Some ports depend on that too. > > >>> > > >> > This is the test-includes target, which validates that include files are self-contained (that is, you can '#include <$file>' without prerequisites. > The target fails because it looks at all headers in /usr/src/sys and then tries to build them, but some of those headers (like the pf headers) include other headers that may not be getting installed because they're disabled. > > I'm not quite sure how to best fix this. > > Note that it is not happening because some pf tools are still getting built. This is a validation target that fails. > > We could potentially add the pf headers to BADHDRS depending on the WITHOUT_ flag, but that would mean manually maintaining badfiles.inc. > Or perhaps we should keep installing the pf headers even when WITHOUT_PF is set, but I'm not actually sure how we convince the build system to do that. Or if it's a good idea. > > Warner might have better ideas on how to fix this. > This simple patch to /usr/src/include/Makefile fixes it for me: --- Makefile.orig 2021-12-22 13:37:02.817745000 +0100 +++ Makefile 2021-12-22 13:37:12.177336000 +0100 @@ -246,9 +246,7 @@ INCSGROUPS+= IPFILTER .endif -.if ${MK_PF} != "no" INCSGROUPS+= PF -.endif .if ${MK_CDDL} != "no" INCSGROUPS+= NVPAIR Since pf.h is used so widely in the tree it's probably the simplest fix. -- Gary Jennejohn From nobody Wed Dec 22 16:58:50 2021 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 965DC18F4ED9 for ; Wed, 22 Dec 2021 16:59:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JK00Q3Zy7z3NHW for ; Wed, 22 Dec 2021 16:59:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x929.google.com with SMTP id a14so5625098uak.0 for ; Wed, 22 Dec 2021 08:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SOJUvREvnmZwiEcWSzJe0UpGgRB6l8bUKEZkwV/VEVc=; b=YTWX/NplwRvMWpXYVsK8+somNnKY+J/hYqDKsGnfNZpa/dko1GsZsaYfqAZ7fmUQHG RXiU18LPHvHpJWuX3yMc6l/iiNYXVocDXAbdWug+fmV/DkFzcDkJuApyatQuN7GMweJG 8wxEShJQONe1ekNyZlGML/RipoXb+BY/+sZRn0/TMpimwg+/PizXpTL1aZwHJJgvJA48 55DKkkZ6FpPSfncbLi1aVDZatAznMh/KyAZVkvwHm+9AcDr1NL/ZiLRPo92+79SKlrSm 0b1KBy/WQp5zYO7dC7wj0R/kFyw4TcOrbH9rHNmqC3V0O3h5Wf/naR1S2FwPeNjcOI+8 9qGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SOJUvREvnmZwiEcWSzJe0UpGgRB6l8bUKEZkwV/VEVc=; b=TyEwbXWZvyMnWTWY0kbxJ0eXAuT2RJB1E/n7c+SFw+ZbGCenN6PXrHIsQg9CaG57ll /gUDK1bCQUxI6OqXoeTfqGRpJt1h1GuZyjRU/I5EIOVYrP5Mynd76rQ3B826+XnKGS0m 6Db8YOh09sCaJHFjnQtbRAYfo7eDklPXCKW/07Sio3P/EcTeN/TT1RDWVAyU1zQ+VNfS 7IjefrvgW9T94wLxDFspVxSDKAABbkva3kv40E0gjGtZ5ndGmKJhiFSDAqPxEGTdvDjm KvHd3pqT/qw9lupJkE3wpnXqPKZ7BUSjo+Kk9jlewe9WWLBXbxA/aKlxqQB2Ti9ZBcfo yq6g== X-Gm-Message-State: AOAM532agvPJbt/Oa0BRA+3GxUwnSnPdq+pqU/vjsyvAuL2Lnf4C4SX5 sgmdzfZvevqimAZrPDLGwmmMexPwsBXtHyWRRz/SM4jp8nY= X-Google-Smtp-Source: ABdhPJzvDFLgCsGYR3m/wyMRBwI9pugfV7D33EN4mXudwnFfsU5p+KllYFfZ/kE9Z5RADSPysM+C3DaLGz93aP9quJk= X-Received: by 2002:a05:6102:3e95:: with SMTP id m21mr1141056vsv.77.1640192341909; Wed, 22 Dec 2021 08:59:01 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211219114723.338b235e@ernst.home> <61bf1204.1c69fb81.2c8fc.3280SMTPIN_ADDED_BROKEN@mx.google.com> <20211219122443.1c84093f@ernst.home> <74FC7625-295C-4DEC-BF35-434B5F8D7832@FreeBSD.org> <20211222165154.33ef54fd@ernst.home> <20211222170151.05a4afe3@ernst.home> In-Reply-To: <20211222170151.05a4afe3@ernst.home> From: Warner Losh Date: Wed, 22 Dec 2021 10:58:50 -0600 Message-ID: Subject: Re: WITHOUT_PF breaks buildworld To: Gary Jennejohn Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000e73f8d05d3bf0941" X-Rspamd-Queue-Id: 4JK00Q3Zy7z3NHW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000e73f8d05d3bf0941 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 22, 2021, 10:02 AM Gary Jennejohn wrote: > On Wed, 22 Dec 2021 16:51:54 +0100 > Gary Jennejohn wrote: > > On Wed, 22 Dec 2021 16:27:52 +0100 > Kristof Provost wrote: > > > On 22 Dec 2021, at 8:21, Konrad Sewi??o-Jopek wrote: > > > Hi, > > > > > > I think the reason is somewhere in tools/build/test-includes: > > > > > > --- net/if_pfsync.o --- > > > In file included from net/if_pfsync.c:1: > > > In file included from > > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56: > > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal > error: > > > 'netpfil/pf/pf.h' file not found > > > #include > > > ^~~~~~~~~~~~~~~~~ > > > 1 error generated. > > > *** [net/if_pfsync.o] Error code 1 > > > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > > --- net/pfvar.o --- > > > > In file included from net/pfvar.c:1: > > > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal > error: > > > > 'netpfil/pf/pf.h' file not found > > > > #include > > > > ^~~~~~~~~~~~~~~~~ > > > > 1 error generated. > > > > *** [net/pfvar.o] Error code 1 > > > > > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > > > 2 errors > > > > > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > > > *** [test-includes] Error code 2 > > > > > > > > make[2]: stopped in [...]freebsd > > > > 1 error > > > > > > > > Best regards, > > > > Konrad Sewi??o-Jopek > > > > > > > > > > > > niedz., 19 gru 2021 o 12:26 Gary Jennejohn > > > > napisa?(a): > > > > > > > >> On Sun, 19 Dec 2021 19:05:35 +0800 > > > >> Alastair Hogge wrote: > > > >> > > > >>> On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote: > > > > >>>> Some recent change, probably in a .mk file, breaks builworld on > HEAD > > > >>>> when WITHOUT_PF is enabled in src.conf. > > > >>> > > > >>> I have had to disable WITHOUT_PF since 2020-07-27, but probably > earlier. > > > >>> > > > >> > > > >> Hmm. I did a successful buildworld a few days ago with WITHOUT_PF > > > >> enabled, so it's new breakge for me at least. > > > >> > > > >> I don't enable pf in the kernel and don't need it in userland. > > > >> > > > >>>> Disabling WITHOUT_PF results in a successful buildworld. > > > >>>> > > > >>>> The reported error is that netpfil/pf/pf.h can't be found. > > > >>> > > > >>> Some ports depend on that too. > > > >>> > > > >> > > This is the test-includes target, which validates that include files are > self-contained (that is, you can '#include <$file>' without prerequisites. > > The target fails because it looks at all headers in /usr/src/sys and > then tries to build them, but some of those headers (like the pf headers) > include other headers that may not be getting installed because they're > disabled. > > > > I'm not quite sure how to best fix this. > > > > Note that it is not happening because some pf tools are still getting > built. This is a validation target that fails. > > > > We could potentially add the pf headers to BADHDRS depending on the > WITHOUT_ flag, but that would mean manually maintaining badfiles.inc. > > Or perhaps we should keep installing the pf headers even when WITHOUT_PF > is set, but I'm not actually sure how we convince the build system to do > that. Or if it's a good idea. > > > > Warner might have better ideas on how to fix this. > > > > This simple patch to /usr/src/include/Makefile fixes it for me: > > --- Makefile.orig 2021-12-22 13:37:02.817745000 +0100 > +++ Makefile 2021-12-22 13:37:12.177336000 +0100 > @@ -246,9 +246,7 @@ > INCSGROUPS+= IPFILTER > .endif > > -.if ${MK_PF} != "no" > INCSGROUPS+= PF > -.endif > > .if ${MK_CDDL} != "no" > INCSGROUPS+= NVPAIR > > Since pf.h is used so widely in the tree it's probably the simplest fix. > I like this. I'd unconditionally remove the test in preference to adding it conditionally. Warner --000000000000e73f8d05d3bf0941 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 22, 2021, 10:02 AM Gary Jennejohn <gl= jennjohn@gmail.com> wrote:
O= n Wed, 22 Dec 2021 16:51:54 +0100
Gary Jennejohn <gljennjohn@gmail.com> wrote:

On Wed, 22 Dec 2021 16:27:52 +0100
Kristof Provost <kp@FreeBSD.org> wrote:

> On 22 Dec 2021, at 8:21, Konrad Sewi??o-Jopek wrote:=C2=A0
> > Hi,
> >
> > I think the reason is somewhere in tools/build/test-includes:
> >
> > --- net/if_pfsync.o ---
> > In file included from net/if_pfsync.c:1:
> > In file included from
> > [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56: > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fat= al error:
> > 'netpfil/pf/pf.h' file not found
> > #include <netpfil/pf/pf.h>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~~~~~~~~~~~~~~
> > 1 error generated.
> > *** [net/if_pfsync.o] Error code 1
> >
> > make[3]: stopped in [...]freebsd/tools/build/test-includes
> > --- net/pfvar.o ---
> > > In file included from net/pfvar.c:1:
> > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10= : fatal error:
> > > 'netpfil/pf/pf.h' file not found
> > > #include <netpfil/pf/pf.h>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~~~~~~~~~~~~~~
> > > 1 error generated.
> > > *** [net/pfvar.o] Error code 1
> > >
> > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > > 2 errors
> > >
> > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > > *** [test-includes] Error code 2
> > >
> > > make[2]: stopped in [...]freebsd
> > > 1 error
> > >
> > > Best regards,
> > > Konrad Sewi??o-Jopek
> > >
> > >
> > > niedz., 19 gru 2021 o 12:26 Gary Jennejohn <= gljennjohn@gmail.com>
> > > napisa?(a):
> > >=C2=A0 =C2=A0
> > >> On Sun, 19 Dec 2021 19:05:35 +0800
> > >> Alastair Hogge <agh@riseup.net> wrote:<= br> > > >>=C2=A0 =C2=A0
> > >>> On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jen= nejohn wrote:=C2=A0 =C2=A0
> > >>>> Some recent change, probably in a .mk file, brea= ks builworld on HEAD
> > >>>> when WITHOUT_PF is enabled in src.conf.=C2=A0 = =C2=A0
> > >>>
> > >>> I have had to disable WITHOUT_PF since 2020-07-27, b= ut probably earlier.
> > >>>=C2=A0 =C2=A0
> > >>
> > >> Hmm.=C2=A0 I did a successful buildworld a few days ago = with WITHOUT_PF
> > >> enabled, so it's new breakge for me at least.
> > >>
> > >> I don't enable pf in the kernel and don't need i= t in userland.
> > >>=C2=A0 =C2=A0
> > >>>> Disabling WITHOUT_PF results in a successful bui= ldworld.
> > >>>>
> > >>>> The reported error is that netpfil/pf/pf.h can&#= 39;t be found.=C2=A0 =C2=A0
> > >>>
> > >>> Some ports depend on that too.
> > >>>=C2=A0 =C2=A0
> > >>=C2=A0 =C2=A0
> This is the test-includes target, which validates that include files a= re self-contained (that is, you can '#include <$file>' withou= t prerequisites.
> The target fails because it looks at all headers in /usr/src/sys and t= hen tries to build them, but some of those headers (like the pf headers) in= clude other headers that may not be getting installed because they're d= isabled.
>
> I'm not quite sure how to best fix this.
>
> Note that it is not happening because some pf tools are still getting = built. This is a validation target that fails.
>
> We could potentially add the pf headers to BADHDRS depending on the WI= THOUT_ flag, but that would mean manually maintaining badfiles.inc.
> Or perhaps we should keep installing the pf headers even when WITHOUT_= PF is set, but I'm not actually sure how we convince the build system t= o do that. Or if it's a good idea.
>
> Warner might have better ideas on how to fix this.
>=C2=A0 =C2=A0

This simple patch to /usr/src/include/Makefile fixes it for me:

--- Makefile.orig=C2=A0 =C2=A0 =C2=A0 =C2=A02021-12-22 13:37:02.817745000 += 0100
+++ Makefile=C2=A0 =C2=A0 2021-12-22 13:37:12.177336000 +0100
@@ -246,9 +246,7 @@
=C2=A0INCSGROUPS+=3D=C2=A0 =C2=A0IPFILTER
=C2=A0.endif

-.if ${MK_PF} !=3D "no"
=C2=A0INCSGROUPS+=3D=C2=A0 =C2=A0PF
-.endif

=C2=A0.if ${MK_CDDL} !=3D "no"
=C2=A0INCSGROUPS+=3D=C2=A0 =C2=A0NVPAIR

Since pf.h is used so widely in the tree it's probably the simplest fix= .

I like this. I'd unconditionally remove the test in preference to addi= ng it conditionally.=C2=A0

Warner
--000000000000e73f8d05d3bf0941-- From nobody Wed Dec 22 18:37:25 2021 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 E1DCD1907C28 for ; Wed, 22 Dec 2021 18:37:27 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JK29z5nfZz3sxy for ; Wed, 22 Dec 2021 18:37:27 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x429.google.com with SMTP id r17so6705075wrc.3 for ; Wed, 22 Dec 2021 10:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=vU3TxG6THDHaGKvgBwjopuufF8HY2JRXwIouBcYoqyg=; b=Z18xkmT/evWksbZo6Ji9YlyWT0/r7dQryStlW0QwEkKtUUIWSF3cSruasNt0e5tWGj AiQ3PZa/auad6KuDEP6VE+dEljroErkPE+zAulPDv9oejHSZ4YTLcRB9MegLLlNT9L02 ojafJDZtKqvpAaILWcqbQxnJVek62U/bea8zgwTWRo4hnTQzABpPUtxfETMywkLlO2xx hRGxBUAwdzCIUrMHVn1P3MYzfZ/vlqW6bEyBiB7SdVqto2gTWsgH6xvzmu05ZwJJcDio 6EeeE66v7xn25CL9rSUdrcPRVdl5X2VjBpfxSTfeBll7jRVCEUXfDDFB9cO3yiqKkFte QLPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=vU3TxG6THDHaGKvgBwjopuufF8HY2JRXwIouBcYoqyg=; b=506QU2AvlH5Od5+gCzRW0WkV2iwVVMlH0AK2bB3FeqihPda2ZecU4px+1dzsst6ACO 6PVeT6TWKCVwx/OgT2yS0lk0j56Lj7Ta7mDvqFPJIeyfcZv2mii2zfKjhPkJdJy5u0Kx 3PgYUF+j5hQPoWj49h44VJ5rxnokvfdDx/RMUoRlhVYxMCdn7mDTYcn9HlRIFCq2Lvax hpKa+e6kXRQGO7lOd9ehc+TZuL3K3d0QrRsrPn/Nh8dmCIW6mGYlNnEO7I57VsQWDyGa brZuRomr0yx0R6z6ocYalU+/HK/pQRat61r4gvy+ZldIoKxcKYQlR9AIIx4w/W2c/RWj kHog== X-Gm-Message-State: AOAM530HFpVdnIoGGV4NrzjqnSX5d00RdyY7nEoEnJGhWFqSVg/kfwCE Cy+mJzhEatJt6zOsV4/mfnQR+kLU3pE= X-Google-Smtp-Source: ABdhPJz1MjhWI1gAuSegLTAZCR3yJPxKxJ3kx/54Z/sH1npfzgfRvazcDo/s64oobj7vBss7ZC46Ug== X-Received: by 2002:a05:6000:2a4:: with SMTP id l4mr3040289wry.460.1640198246919; Wed, 22 Dec 2021 10:37:26 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id u23sm2335560wmc.7.2021.12.22.10.37.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Dec 2021 10:37:26 -0800 (PST) Date: Wed, 22 Dec 2021 19:37:25 +0100 From: Gary Jennejohn To: Warner Losh Cc: FreeBSD Current Subject: Re: WITHOUT_PF breaks buildworld Message-ID: <20211222193725.19f2f03a@ernst.home> In-Reply-To: References: <20211219114723.338b235e@ernst.home> <61bf1204.1c69fb81.2c8fc.3280SMTPIN_ADDED_BROKEN@mx.google.com> <20211219122443.1c84093f@ernst.home> <74FC7625-295C-4DEC-BF35-434B5F8D7832@FreeBSD.org> <20211222165154.33ef54fd@ernst.home> <20211222170151.05a4afe3@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JK29z5nfZz3sxy X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 22 Dec 2021 10:58:50 -0600 Warner Losh wrote: > On Wed, Dec 22, 2021, 10:02 AM Gary Jennejohn wrote: > > > > > This simple patch to /usr/src/include/Makefile fixes it for me: > > > > --- Makefile.orig 2021-12-22 13:37:02.817745000 +0100 > > +++ Makefile 2021-12-22 13:37:12.177336000 +0100 > > @@ -246,9 +246,7 @@ > > INCSGROUPS+= IPFILTER > > .endif > > > > -.if ${MK_PF} != "no" > > INCSGROUPS+= PF > > -.endif > > > > .if ${MK_CDDL} != "no" > > INCSGROUPS+= NVPAIR > > > > Since pf.h is used so widely in the tree it's probably the simplest fix. > > > > I like this. I'd unconditionally remove the test in preference to adding it > conditionally. > If I still had my commit bit I'd do it myself :-) -- Gary Jennejohn From nobody Wed Dec 22 18:52:15 2021 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 A469F190BC59 for ; Wed, 22 Dec 2021 18:52:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JK2WP3x2fz4Rg3 for ; Wed, 22 Dec 2021 18:52:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x930.google.com with SMTP id i6so5833512uae.6 for ; Wed, 22 Dec 2021 10:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D2m19K7ajAKN+5bI5lp7urGRH58gy0qA6FqC8Wnvr5s=; b=5wMCR4Cj+xv+g0DQHv6iwUOZVELpWGT200PUuxv3eZWjJWHuF2x2TLA9jXa9of/mX7 dvSSDeFx+Hfgk6apkNZsqDphGN1swx+/6GowbDFM8wQk9Kbk+Qt4Lrs0rTg2wULMMDsR AEhLUTkqDAZILZizbxmyPhePavrkojcJBo9rT4qIt+iZJh0/5I45LxCXDWWHvvy8HFgw I3Xx/dbq2nmw1afQtt1V4w7tJtUUDjKF/rOCeHjE/kWQpD6ecLaGgSkFt4flEOkUPH+k lHA+4WNBGlXbAXIspdo87bGuRQW5xGRGnKZFskJsQmTfdiQzL0uIGFNP8zy/mqp8XinX QvBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D2m19K7ajAKN+5bI5lp7urGRH58gy0qA6FqC8Wnvr5s=; b=E4Oo+wAznY8gidj7v7KTfPmc6+rAnFpbt3Re70xkZ+nMPW5SZ1/ZhWEAzc8Bq0x1Jc rzHKS8J3/sQyBIFmw6jS8uKkHOHJ8XZ0VoEZxO9MC7arlfFbCi1VxtJCvXP9iY1SHTRw 2aqDVonbd4QPQg/kGRWC1Px8wiOc40PWknx9DsIFFGyhUDtjaapsmRsOsE5TDZ1mAcon nrFzEzo04Vr3du+ObqaqRcBVZ6eaF2MNE/Mi3+kDeonaKLruCLSpX6sdMOhMDQoKSvhz m1+73zYSTiMouOxHD25fcqxzhIfYdaWYQ01Xry2tY73roVElnGIm4D+9hNVJ5GTrUEQ+ QlPQ== X-Gm-Message-State: AOAM533yZwz8yGkWgmnu5ewkOETdE+t8KcliwAx6apPaSAF3Uk5fI2X0 ViIyI/XzH/Y1Qebuzhped35u2PnmCuPBPsehhFj8xsGNWmI= X-Google-Smtp-Source: ABdhPJy7RiVr+GFqy/sAR191KEfSa1mt3iEurpbStiE/dhgHk4vK8JIh06aNG703ETNjiIq24WZRJBz/crrFYHTmDq8= X-Received: by 2002:a05:6102:da:: with SMTP id u26mr1567731vsp.42.1640199147257; Wed, 22 Dec 2021 10:52:27 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211219114723.338b235e@ernst.home> <61bf1204.1c69fb81.2c8fc.3280SMTPIN_ADDED_BROKEN@mx.google.com> <20211219122443.1c84093f@ernst.home> <74FC7625-295C-4DEC-BF35-434B5F8D7832@FreeBSD.org> <20211222165154.33ef54fd@ernst.home> <20211222170151.05a4afe3@ernst.home> <20211222193725.19f2f03a@ernst.home> In-Reply-To: <20211222193725.19f2f03a@ernst.home> From: Warner Losh Date: Wed, 22 Dec 2021 12:52:15 -0600 Message-ID: Subject: Re: WITHOUT_PF breaks buildworld To: Gary Jennejohn Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000088923005d3c09f3e" X-Rspamd-Queue-Id: 4JK2WP3x2fz4Rg3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000088923005d3c09f3e Content-Type: text/plain; charset="UTF-8" On Wed, Dec 22, 2021, 12:37 PM Gary Jennejohn wrote: > On Wed, 22 Dec 2021 10:58:50 -0600 > Warner Losh wrote: > > > On Wed, Dec 22, 2021, 10:02 AM Gary Jennejohn > wrote: > > > > > > > > This simple patch to /usr/src/include/Makefile fixes it for me: > > > > > > --- Makefile.orig 2021-12-22 13:37:02.817745000 +0100 > > > +++ Makefile 2021-12-22 13:37:12.177336000 +0100 > > > @@ -246,9 +246,7 @@ > > > INCSGROUPS+= IPFILTER > > > .endif > > > > > > -.if ${MK_PF} != "no" > > > INCSGROUPS+= PF > > > -.endif > > > > > > .if ${MK_CDDL} != "no" > > > INCSGROUPS+= NVPAIR > > > > > > Since pf.h is used so widely in the tree it's probably the simplest > fix. > > > > > > > I like this. I'd unconditionally remove the test in preference to adding > it > > conditionally. > > > > If I still had my commit bit I'd do it myself :-) > I can do it tonight. I'm on the road today dri ING back from Omaha.. Warner -- > Gary Jennejohn > --00000000000088923005d3c09f3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 22, 2021, 12:37 PM Gary Jennejohn <gljennjohn@gmail.com> wrote:
=
On Wed, 22 Dec 2021 10:58:50 -0600
Warner Losh <imp@bsdimp.com> wrote:

> On Wed, Dec 22, 2021, 10:02 AM Gary Jennejohn <gljennjohn@gmail.c= om> wrote:
>
> >
> > This simple patch to /usr/src/include/Makefile fixes it for me: > >
> > --- Makefile.orig=C2=A0 =C2=A0 =C2=A0 =C2=A02021-12-22 13:37:02.8= 17745000 +0100
> > +++ Makefile=C2=A0 =C2=A0 2021-12-22 13:37:12.177336000 +0100
> > @@ -246,9 +246,7 @@
> >=C2=A0 INCSGROUPS+=3D=C2=A0 =C2=A0IPFILTER
> >=C2=A0 .endif
> >
> > -.if ${MK_PF} !=3D "no"
> >=C2=A0 INCSGROUPS+=3D=C2=A0 =C2=A0PF
> > -.endif
> >
> >=C2=A0 .if ${MK_CDDL} !=3D "no"
> >=C2=A0 INCSGROUPS+=3D=C2=A0 =C2=A0NVPAIR
> >
> > Since pf.h is used so widely in the tree it's probably the si= mplest fix.
> >=C2=A0
>
> I like this. I'd unconditionally remove the test in preference to = adding it
> conditionally.
>

If I still had my commit bit I'd do it myself :-)

I can do it tonight.= =C2=A0 I'm on the road today dri ING back from Omaha..

Warner

=
--
Gary Jennejohn
--00000000000088923005d3c09f3e-- From nobody Wed Dec 22 18:57:05 2021 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 22A6E190CC59 for ; Wed, 22 Dec 2021 18:57:07 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JK2cg0Bl8z4TD5 for ; Wed, 22 Dec 2021 18:57:07 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x42d.google.com with SMTP id s1so6769251wra.6 for ; Wed, 22 Dec 2021 10:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=FX5QWshOCtzkIo1Hck64hm1r22G24uRfwHKGuGfUikQ=; b=QaV74BAPrhJYSNFp8fgGEl67su7dNjW+m/88y7gmsS2k4uJC/SHbV/RPjJL1KXIp2h whEs5P/96NI+7QnuFF3CvmYtQQbN9TL5IsxsT4L3MAZsdiBehP39RLWlXCjVuFLtCoB0 VHIX68up/TeQt3JTQNCizqRGZFsu+uzGY9FxxbPkIERnyjTHubpktbC40wcwG02x1sDB gOGs1Uuy4W4UG9khYeAfrQ9xPBrVcg6o2nk7SurRH/JgUojjHVR5E5QRtoNhrwAb/D61 VDOS0jwoWyAa3leuGP9pUWJZLDsAoiy9tBps0Y9VGTNwaR+MxHxK39yb0TO/+kVUR+W7 cXiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=FX5QWshOCtzkIo1Hck64hm1r22G24uRfwHKGuGfUikQ=; b=eQwlmGjbXjz8cR7P6pfNGgYwnTW5j5KAMGV2ZCr5JILpI74PEUyfXU9Iv+wYLXFDqN MDaPNlxJgPY3q97Q8J/3IWA340hZDGRtq7Rq8Skq/C1XRYB5Zrf7wd2Pwo8sJnuqtw11 d+SIWSXL6ENbbFC806I+mhP18PIOOMJbUTRUqBQ2l3kUSq+K52VOccSx4CYf9u+4I3O8 4qWA6r3juBBVTZPzGwEwtY5oa3qHHW+7jR2hHdC1o6AzZRq8zBiohjgCYi5I3l6S04q5 Qis9a3MRnujYgzYArO1vehTzOFrFpwmEKKWhGUpj6ymUri4rkCfq5tXRQ0bRHEjkDHN/ Kh4g== X-Gm-Message-State: AOAM530/7e24Kpk1QDakPFx6jf1GjQf2dR1WrCUWGtxbTHc/XgzxjtHQ ZyNTKfuaYRAvQPl4uMnobqAGUPl/Q3s= X-Google-Smtp-Source: ABdhPJyg/Bxyo0SkdpFGUApl8FWkRCvhYOya4EB5U146vm+xPKvHcKK9+ODaRXH6DxRjhS/jds/yUg== X-Received: by 2002:adf:facb:: with SMTP id a11mr2854346wrs.18.1640199426093; Wed, 22 Dec 2021 10:57:06 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id n8sm2997553wri.47.2021.12.22.10.57.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Dec 2021 10:57:05 -0800 (PST) Date: Wed, 22 Dec 2021 19:57:05 +0100 From: Gary Jennejohn To: Warner Losh Cc: FreeBSD Current Subject: Re: WITHOUT_PF breaks buildworld Message-ID: <20211222195705.0f8b8541@ernst.home> In-Reply-To: References: <20211219114723.338b235e@ernst.home> <61bf1204.1c69fb81.2c8fc.3280SMTPIN_ADDED_BROKEN@mx.google.com> <20211219122443.1c84093f@ernst.home> <74FC7625-295C-4DEC-BF35-434B5F8D7832@FreeBSD.org> <20211222165154.33ef54fd@ernst.home> <20211222170151.05a4afe3@ernst.home> <20211222193725.19f2f03a@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JK2cg0Bl8z4TD5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 22 Dec 2021 12:52:15 -0600 Warner Losh wrote: > On Wed, Dec 22, 2021, 12:37 PM Gary Jennejohn wrote: > [snip patch] > > > > Since pf.h is used so widely in the tree it's probably the simplest > > fix. > > > > > > > > > > I like this. I'd unconditionally remove the test in preference to adding > > it conditionally. > > > > > > > If I still had my commit bit I'd do it myself :-) > > > > I can do it tonight. I'm on the road today dri ING back from Omaha.. > Thanks. Then I can remove my hack to patch the Makefile. -- Gary Jennejohn From nobody Fri Dec 24 03:08:45 2021 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 2F833191EE9F; Fri, 24 Dec 2021 03:09:00 +0000 (UTC) (envelope-from yetoohappy@gmail.com) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JKsTl3hVBz3Pr4; Fri, 24 Dec 2021 03:08:59 +0000 (UTC) (envelope-from yetoohappy@gmail.com) Received: by mail-lf1-x132.google.com with SMTP id k21so16373023lfu.0; Thu, 23 Dec 2021 19:08:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ff2hmuOMYXFXDvcbIAkeqIKyQ2Fr71DzheewzljoKI4=; b=O7/kX9/ipHYYgNZCrd6triz3cP8/61n/+RsTbZz2sYSwROnGhNFd18l1buukGB4UAk DMsJ4AQrMzwDIZ9TZcVbI39vyqSn162/e99nEeZdO7ZutMdicIqfnlz5hFefhx9Okmjp c/PmeSh7I6GwVtLBmQNpfwSKR8T5MVxLJngOvVQKTFBzea/yumu60iJJPXo904PiGq1t dNamjQKZx9yXw94kst4cmlP4GMLxEnH51BnSr5tdrIF89BumqZX+uZbRg83zTjvjt1fk Q9DD6xrHx0UskKZ2u/S6/RYw8+ygBccgrjSymNMJuMRDkVa1PLMmyeG3RJZ0NVP8gtxK In0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ff2hmuOMYXFXDvcbIAkeqIKyQ2Fr71DzheewzljoKI4=; b=kr1+/qqC/bBZ1F49NIrAF6dQVONFI/CZA4OiEd/pHWOimdXbMjl/cPGkC8wFDXMqz6 z3IFU4M7ZHZYILveKKxYhH9r9WIaGu0RsJ1IZdv6dvqipyHNZx/ldBjUiaKSwHGMYI72 b0IR4Osgq11M8u4K0y2qG5YcfNiFfiWnwRvnqOrhKnb8k2zytX/1RmAEpNcS8jBLFDSL tpJf1e18xuH92ZQnhA6l4rSLSlf+9Yf8YiSvKulcwsUzESBuiTWBvaEkz3cda/uvWu/c PLU6mkdmstkKKXVi9QvRZtFZgqcE4xlwHRG341dSgbcZ5QufWxyxLgJ+mDAlWCgV1Ybu lQHw== X-Gm-Message-State: AOAM532r1EkSucT8uKmoR60Gm1NcnWCe44xN2jojb/GLcQWPaOPKTyWC sw2w7ZclAlGBIhrONKbS3F/X9wAwDYoboid5i3OJNftb X-Google-Smtp-Source: ABdhPJybxWVsPOtCw/p9vtMtPMacNCI5PIH9MCg4scWxU2U9T+DWhyt2p4hyStkFSfsrGOFRmYsbsJZDQecV7ThsRo8= X-Received: by 2002:a05:6512:1304:: with SMTP id x4mr3865146lfu.484.1640315337235; Thu, 23 Dec 2021 19:08:57 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Yetoo Happy Date: Thu, 23 Dec 2021 19:08:45 -0800 Message-ID: Subject: Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook To: freebsd-doc@freebsd.org Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JKsTl3hVBz3Pr4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="O7/kX9/i"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yetoohappy@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) smtp.mailfrom=yetoohappy@gmail.com X-Spamd-Result: default: False [-3.18 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-0.19)[-0.185]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::132:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Fri, Dec 3, 2021 at 3:52 AM Yetoo Happy wrote: > > In https://docs.freebsd.org/en/books/handbook/cutting-edge/ I can see tha= t at 24.5.6.1 Merging Configuration Files are instructions to bootstrap etc= update if switching from mergemaster. This is really convenient and really = useful, EXCEPT for that fact that it is placed in a part of the handbook a = little ways after installation would complete. The critical issue here bein= g that, due to this information not being higher up, a user who is looking = at the handbook to update from source and are trusting the handbook because= they have faith that it won't play any dirty tricks on them, because all t= he documentation and all the user groups speak so highly of the handbook be= ing complete and thorough and authoritative, are just going to 24.5.1. Quic= k Start and follow the instructions and get to step 7 and may think that ev= en though etcupdate is different from mergemaster from the last time they u= sed the handbook they have faith that following the instructions won't bric= k their system. This user will instead find that faith in general is just a= very complex facade for the pain and suffering of not following 24.5.6.1 M= erging Configuration Files because the user doesn't know that step exists o= r relevant to the current step and ends up unknowingly having etcupdate app= end "<<<< yours ... >>>>> new" to the top of the user's very important conf= iguration files that they didn't expect the program to actually modify that= way when they resolved differences nor could they predict easily because t= he diff format is so unintuitive and different from mergemaster. Now unable= to login or boot into single user mode because redirections instead of the= actual configuration is parsed the user goes to the handbook to find out w= hat might have happened and scrolls down to find 24.5.6.1 Merging Configura= tion Files is under 24.5.6. Completing the Update. What a mocking section? = Completing the update? How could I have completed the update if I was on St= ep 7 of Quick Steps? The user now may feel cheated, jaded, or insulted and = wonder what the fuss is all about with this hyped documentation. > > Here's a solution: Make a red warning notice at the very top of 24.5.1. Q= uick Start and refer to 24.5.6.1 Merging Configuration Files and make clear= this is for step 7. Another solution is, if possible, put that red warning= notice next to step 7 or step 7 in the grey section or red/pink section of= the quick start box area, I personally would prefer a warning with text ri= ght next to step 7 in the red/pink part of the quick start box, but I'm not= sure if that's possible or respecting the documentation design paradigm. T= he next best option is a warning at the top because it reduces the chance o= f a user following instructions and missing that step because they haven't = scrolled to that point yet. > > I'm sorry if this comes across as an angry potentially combative message,= but I just wanted to make clear where and what the problem is and my frust= ration with this problem. Around the time I made this post, I created a patch that I believe resolves the issue with the documentation. Here is the PR for posterity: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260253 From nobody Fri Dec 24 13:08:08 2021 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 A08FC1913195; Fri, 24 Dec 2021 13:08:11 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JL6n73d0Mz3kjN; Fri, 24 Dec 2021 13:08:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 0285F27152; Fri, 24 Dec 2021 13:08:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <02d9ca2a-2fd7-942b-f411-be007ef88327@FreeBSD.org> Date: Fri, 24 Dec 2021 15:08:08 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.1 Content-Language: en-US To: FreeBSD Current , FreeBSD Hackers From: Andriy Gapon Subject: schedgraph.d experience, per-CPU buffers, pipes Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640351291; 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=ukPiNy1UwYaPjiemcRS5XSKrwtDEydPuax1eH3ax+E4=; b=n5bKNtGfvCOCPNBZDkntZURk9X9pwCpjTtocm/t9x/2YGoqjTIFTqcIAj6FKflM6X8xwWt gD6pN+66wGCVPW/SM/LeuhB7W6VrK/jYLv0Sv/NkzQGN3FgjYskMxMvtDpfWIdXol1KARt vBAm9FjimV9PgBysNqeHONGY6FcKQRe+jSMcavU3Y90QRxZCfI/1ofc4fKZUZLrko1U6/H 5hQBX09Zyoy3yGz8Ys+86o982rLguA4/lkTaJ0PLZo3Ga/lz47FFvYfXfMJ2wgyXlRssjH PTbX4NoelMiIYw5qfXld0Y7GphMxfxSL7MnSEkhFR2k62mjor7KRVB6GFuDtTA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640351291; a=rsa-sha256; cv=none; b=hk7rDkwr3MrN3Oe59bi4t0eJMuNAQtHj2Eqb97+Lca2OWTqN8jzMkQdXKaZLOLAlcNIqJq TrVhU+pbwzSeNirZ1ygaRaYfB59EpNhc5CRQQ43BazyXZ3Z9iaHVwAoXusEkUr3I8VVXFz 882YEezSdA5Rf2vkiqWSYrBME3uLIHqhuBFaDSbYmkJfoFPL1W2/aQGVokQdYYY4LF1bju uz9ZzgIhoKypPencyHYzu/b4C5rAD1IOkrft+/zHXCHsfJHU41P0kXycwzmIbvE6hEO3Bu F6RTzcBX5r0/3mJKL7l6XbibYdAleHG0djocV/QeLXPob3mbxpvxhSQPCGMMJA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N I would like to share some experience or maybe rather a warning about using DTrace for tracing scheduling events. Unlike KTR which has a global circular buffer, DTrace with bufpolicy=ring uses per-CPU circular buffers. So, if there is an asymmetry in processor load, the buffers will fill and wrap-around at different speeds. In the end, they might have approximately equal numbers of events but those may cover very different time intervals. So, some additional post-processing is required to find the latest event among first ones of each per-CPU buffer. Any traces from before that would have information gaps ("missing" processors) and would be very confusing. Also, I noticed that processes passing a lot of data through pipes produce a lot of scheduling events as they seem to get blocked and unlocked every few microseconds (on a modern performant system with the default pipe sizing configuration). That contributes to a quick wrap-around of circular buffers. -- Andriy Gapon From nobody Fri Dec 24 14:40:52 2021 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 A9BDF1905152; Fri, 24 Dec 2021 14:41:02 +0000 (UTC) (envelope-from marc@blackend.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) (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 4JL8rF6H27z4SR4; Fri, 24 Dec 2021 14:41:01 +0000 (UTC) (envelope-from marc@blackend.org) Received: from emphyrio.blackend.org (unknown [82.64.86.146]) by smtp1-g21.free.fr (Postfix) with ESMTPS id B1D6CB004FF; Fri, 24 Dec 2021 15:40:53 +0100 (CET) Received: from emphyrio.blackend.org (localhost [127.0.0.1]) by emphyrio.blackend.org (8.16.1/8.16.1) with ESMTPS id 1BOEeruS001203 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 24 Dec 2021 15:40:53 +0100 (CET) (envelope-from marc@emphyrio.blackend.org) Received: (from marc@localhost) by emphyrio.blackend.org (8.16.1/8.16.1/Submit) id 1BOEeqfY001202; Fri, 24 Dec 2021 15:40:52 +0100 (CET) (envelope-from marc) Date: Fri, 24 Dec 2021 15:40:52 +0100 From: Marc Fonvieille To: Steve Kargl Cc: Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: Mail-Followup-To: Steve Kargl , Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> <20211221004819.GA79153@troutmask.apl.washington.edu> <20211221164749.GA81666@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211221164749.GA81666@troutmask.apl.washington.edu> X-Rspamd-Queue-Id: 4JL8rF6H27z4SR4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of marc@blackend.org has no SPF policy when checking 2a01:e0c:1:1599::10) smtp.mailfrom=marc@blackend.org X-Spamd-Result: default: False [-0.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[marc]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[blackend@freebsd.org,marc@blackend.org]; RECEIVED_SPAMHAUS_PBL(0.00)[82.64.86.146:received]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:12322, ipnet:2a01:e00::/26, country:FR]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[blackend@freebsd.org,marc@blackend.org] X-ThisMailContainsUnwantedMimeParts: N Le 21.12.2021 08:47, Steve Kargl a écrit : > Not at the moment. tlibm only handles math functions with > a single real agrument [1]. I've been thinking about adding > the 2 argument functions such as atan2 and complex argument > function, but lack the time. I also need to improve the man > page to decoment the default domain for each function and its > complete domain. > > [1] acos, acosh, asin, asinh, atan, atanh, cbrt, cos, cosh, erf, > erfc, exp, exp2, expm1, j0, j1, lgamma, log, log10, log1p, > log2, sin, sinh, sqrt, tan, tanh, tgamma, y0, y1. > No problem. It's a great project. Keep up posting about your progress. -- Marc From nobody Mon Dec 27 17:31:15 2021 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 4F3311912B2A for ; Mon, 27 Dec 2021 17:31:25 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JN4TQ2Wbzz3Lnh for ; Mon, 27 Dec 2021 17:31:22 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BRHVFX3005042 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 27 Dec 2021 09:31:15 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BRHVFXq005041; Mon, 27 Dec 2021 09:31:15 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Mon, 27 Dec 2021 09:31:15 -0800 From: Gleb Smirnoff To: Larry Rosenman Cc: current@freebsd.org Subject: Re: My -CURRENT crashes.... Message-ID: References: <286c830efc0e12e3e7a7e9b2ede31c28@lerctr.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: <286c830efc0e12e3e7a7e9b2ede31c28@lerctr.org> X-Rspamd-Queue-Id: 4JN4TQ2Wbzz3Lnh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [-1.57 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.53)[0.526]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Dec 17, 2021 at 01:27:11PM -0600, Larry Rosenman wrote: L> Can someone look at the messages I posted to -CURRENT, most recent L> today, with random L> Callout(?) crashes after long (>6 hour) poudriere runs? L> L> I have core's available. I asked Larry to obtain a core with INVARIANTS and now we have one. Sharing what I've found to brainstorm. Trap happens in LIST_REMOVE() kern_timeout.c:488 because the entry doesn't have a prev pointer, e.g. doesn't belong to any list. #6 0xffffffff807be075 in trap_pfault (frame=0xfffffe02d3393d50, usermode=false, signo=, ucode=) at /usr/src/sys/amd64/amd64/trap.c:765 #7 #8 0xffffffff804e5609 in callout_process (now=now@entry=100465191785818) at /usr/src/sys/kern/kern_timeout.c:488 #9 0xffffffff80460fc5 in handleevents (now=now@entry=100465191785818, fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 #10 0xffffffff80461a66 in timercb (et=0xffffffff80d47980 , arg=) at /usr/src/sys/kern/kern_clocksource.c:357 #11 0xffffffff807e6beb in lapic_handle_timer (frame=0xfffffe02d3393f40) at /usr/src/sys/x86/x86/local_apic.c:1364 (kgdb) p *tmp $13 = {c_links = {le = {le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_precision = 0, c_arg = 0x0, c_func = 0x0, c_lock = 0xfffff8030521e670, c_flags = 0, c_iflags = 0, c_cpu = 0} Useful here is the c_lock, which points into "process lock" lockobject. This allows us to deduct that the callout belongs to proc subsystem and we can retrieve the proc it points to: c_lock - 0x128 = 0xfffff8030521e548 It is ccache in PRS_NORMAL state. And the "tmp" in our stack frame is its p_itcallout. So there is something that would zero out most of the p_itcallout while it is scheduled? -- Gleb Smirnoff From nobody Mon Dec 27 18:43:01 2021 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 908991921F08 for ; Mon, 27 Dec 2021 18:43:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JN6473Spbz3qt0; Mon, 27 Dec 2021 18:43:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qt1-x82e.google.com with SMTP id p19so14178949qtw.12; Mon, 27 Dec 2021 10:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nA1ECNWTG9BzpJTVNoL7EeuxvmcjeVX9XBpfWWrlZ8Q=; b=qAs7pEqNbJPVBtpP//0kF/ErbPlEXqnB6wQwsUWFfyHvgxDwhqdIZJ1hhx/Gcf2jPW iNK8lecMQiTmo3AxEeI13bWnMRy/HWacn5DRED1kl2SqHey3Zih/WikHF3MmFIx94u3j gKLJJEagnTEOa6k0bOH/IF5XbCkyVgiv2YQV2MlmlikW/OU/kqgCqYGOuAU5UZan8HTD Q3M+FlHCEiGH5VE9mH09hTCaayhJogwj/TV5Sp14/Z//on9SlpqCKNr5dY3BkFFifLk7 Ig7dOkBgudU8UB/wKzUIsRPdp0t0rODm906J8yxBBb4fwvMDl9A5e51jhf33oawmazkv 5psw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nA1ECNWTG9BzpJTVNoL7EeuxvmcjeVX9XBpfWWrlZ8Q=; b=oTHSMfIkT/6cP0DrBaUSXgFacE7dXfW56cFadmagi96ZlBv27mfLAH7Gsjf3W2klzG O1SAJcNkWE37G2V4oSE/RfFYp6HkTI4Xj4+joxv0pehEKSHEXxaTkyUBXYumy/wGHuUk w+85/zU9CZacZ+UUKGH0KQmjCaEEdrMjeaOknej1DVbVAe7fyN/yD1QBcnnSlOk3f9Zl /J9nI5uxE9smJyFY1lfHGxmICYr6YbVCMAp1StY9VQv/m4eOExFo4mLqmZmMeZKVDHH6 okbKdkoEoJVbymYtaZFKhKLGW4Dz+6lF/ozTMb1i+oPjyGi94CpJP8EZlHHizuvbxPcd NI5Q== X-Gm-Message-State: AOAM533TM2fqBy6qbyGzPVroE0WVPq/kkeJQIRtyPLdtM+yqjnUqaxtA wdy8UIn/o1er9vK16yv9tGjyZAPGCWI= X-Google-Smtp-Source: ABdhPJxLfMxzvcB3LVieLojY/5pW/O4MF/V6jGd+IyaAiYlZYAhjiZJGKkLfvD6KAHuiWnjMFqVmIQ== X-Received: by 2002:ac8:5c54:: with SMTP id j20mr15793563qtj.121.1640630582721; Mon, 27 Dec 2021 10:43:02 -0800 (PST) Received: from mavoffice.ixsystems.com ([38.32.73.2]) by smtp.gmail.com with ESMTPSA id d17sm13584675qtx.96.2021.12.27.10.43.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Dec 2021 10:43:02 -0800 (PST) Subject: Re: My -CURRENT crashes.... To: Gleb Smirnoff , Larry Rosenman Cc: current@freebsd.org References: <286c830efc0e12e3e7a7e9b2ede31c28@lerctr.org> From: Alexander Motin Message-ID: <45ee5689-b24c-51b5-d7b7-33fd73ee7dce@FreeBSD.org> Date: Mon, 27 Dec 2021 13:43:01 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.13.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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JN6473Spbz3qt0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 27.12.2021 12:31, Gleb Smirnoff wrote: > On Fri, Dec 17, 2021 at 01:27:11PM -0600, Larry Rosenman wrote: > L> Can someone look at the messages I posted to -CURRENT, most recent > L> today, with random > L> Callout(?) crashes after long (>6 hour) poudriere runs? > L> > L> I have core's available. > > I asked Larry to obtain a core with INVARIANTS and now we have one. > > Sharing what I've found to brainstorm. Trap happens in LIST_REMOVE() > kern_timeout.c:488 because the entry doesn't have a prev pointer, e.g. > doesn't belong to any list. > > #6 0xffffffff807be075 in trap_pfault (frame=0xfffffe02d3393d50, usermode=false, signo=, ucode=) > at /usr/src/sys/amd64/amd64/trap.c:765 > #7 > #8 0xffffffff804e5609 in callout_process (now=now@entry=100465191785818) at /usr/src/sys/kern/kern_timeout.c:488 > #9 0xffffffff80460fc5 in handleevents (now=now@entry=100465191785818, fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213 > #10 0xffffffff80461a66 in timercb (et=0xffffffff80d47980 , arg=) at /usr/src/sys/kern/kern_clocksource.c:357 > #11 0xffffffff807e6beb in lapic_handle_timer (frame=0xfffffe02d3393f40) at /usr/src/sys/x86/x86/local_apic.c:1364 > > (kgdb) p *tmp > $13 = {c_links = {le = {le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, > c_precision = 0, c_arg = 0x0, c_func = 0x0, c_lock = 0xfffff8030521e670, c_flags = 0, c_iflags = 0, c_cpu = 0} > > Useful here is the c_lock, which points into "process lock" lockobject. > > This allows us to deduct that the callout belongs to proc subsystem and > we can retrieve the proc it points to: c_lock - 0x128 = 0xfffff8030521e548 > It is ccache in PRS_NORMAL state. And the "tmp" in our stack frame is its > p_itcallout. > > So there is something that would zero out most of the p_itcallout while > it is scheduled? So carefully zero it, but keep the lock pointer... The only way that comes to mind is callout_init_mtx() in do_fork() if we assume the process has completed and the struct proc was reused. I guess if we could somehow leak scheduled callout in exit1(). May be we could add some more assertions to try catch callout still being active there. -- Alexander Motin From nobody Mon Dec 27 18:58:02 2021 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 92A481924DBE for ; Mon, 27 Dec 2021 18:58:04 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JN6PS2QGzz3t4D; Mon, 27 Dec 2021 18:58:04 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BRIw2JI005261 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 27 Dec 2021 10:58:03 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BRIw2Jc005260; Mon, 27 Dec 2021 10:58:02 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Mon, 27 Dec 2021 10:58:02 -0800 From: Gleb Smirnoff To: Alexander Motin Cc: Larry Rosenman , current@freebsd.org Subject: Re: My -CURRENT crashes.... Message-ID: References: <286c830efc0e12e3e7a7e9b2ede31c28@lerctr.org> <45ee5689-b24c-51b5-d7b7-33fd73ee7dce@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: <45ee5689-b24c-51b5-d7b7-33fd73ee7dce@FreeBSD.org> X-Rspamd-Queue-Id: 4JN6PS2QGzz3t4D X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 27, 2021 at 01:43:01PM -0500, Alexander Motin wrote: A> > This allows us to deduct that the callout belongs to proc subsystem and A> > we can retrieve the proc it points to: c_lock - 0x128 = 0xfffff8030521e548 A> > It is ccache in PRS_NORMAL state. And the "tmp" in our stack frame is its A> > p_itcallout. A> > A> > So there is something that would zero out most of the p_itcallout while A> > it is scheduled? A> A> So carefully zero it, but keep the lock pointer... The only way that A> comes to mind is callout_init_mtx() in do_fork() if we assume the A> process has completed and the struct proc was reused. I guess if we A> could somehow leak scheduled callout in exit1(). May be we could add A> some more assertions to try catch callout still being active there. Note that _callout_stop_safe(p_itcallout) is the only place in kernel where CS_EXECUTING is used. -- Gleb Smirnoff From nobody Mon Dec 27 19:15:53 2021 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 97B151902396 for ; Mon, 27 Dec 2021 19:16:01 +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 4JN6p90YjWz4TJW; Mon, 27 Dec 2021 19:16:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1BRJFr4Z096276 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 27 Dec 2021 21:15:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1BRJFr4Z096276 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1BRJFr6S096275; Mon, 27 Dec 2021 21:15:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 Dec 2021 21:15:53 +0200 From: Konstantin Belousov To: Gleb Smirnoff Cc: Alexander Motin , Larry Rosenman , current@freebsd.org Subject: Re: My -CURRENT crashes.... Message-ID: References: <286c830efc0e12e3e7a7e9b2ede31c28@lerctr.org> <45ee5689-b24c-51b5-d7b7-33fd73ee7dce@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=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4JN6p90YjWz4TJW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 27, 2021 at 10:58:02AM -0800, Gleb Smirnoff wrote: > On Mon, Dec 27, 2021 at 01:43:01PM -0500, Alexander Motin wrote: > A> > This allows us to deduct that the callout belongs to proc subsystem and > A> > we can retrieve the proc it points to: c_lock - 0x128 = 0xfffff8030521e548 > A> > It is ccache in PRS_NORMAL state. And the "tmp" in our stack frame is its > A> > p_itcallout. > A> > > A> > So there is something that would zero out most of the p_itcallout while > A> > it is scheduled? > A> > A> So carefully zero it, but keep the lock pointer... The only way that > A> comes to mind is callout_init_mtx() in do_fork() if we assume the > A> process has completed and the struct proc was reused. I guess if we > A> could somehow leak scheduled callout in exit1(). May be we could add > A> some more assertions to try catch callout still being active there. > > Note that _callout_stop_safe(p_itcallout) is the only place in kernel where > CS_EXECUTING is used. I would start asking are there any third-party modules loaded. From nobody Mon Dec 27 19:17:33 2021 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 24FF51903011 for ; Mon, 27 Dec 2021 19:17:36 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:7ae3:b5ff:fe1b:23b4]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JN6r00HPZz4VlW; Mon, 27 Dec 2021 19:17:36 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=aUCRk54zcwCbB4pmoRZ+mQfpMruJjof491qHqTh26eg=; b=FFZcUHXCngNizQ/O03m9IQ/37i uKIctYJSoGQHkhmuffNzwEP/HpfCjRVlBahiqxxUvukJH8WXqPOD60FgZMGgGe5LHq0Y2SWVl6RW+ qjkOyamsnbDFqG9qb+DKE+8x7cmDK8deja9VupWrI7P0NNpd3et0NZHkVOzf3K/t1QWlf8HpAF1jV sw3USgxcL204IwUhqUYJsZey5JRLEaDqJk3lNQ2NiEXOCZ+ShXsnKt18v6K2KjFRRPdYaoVScFOk5 Jm84r4YSgOMxrMUUS1AfuhvOSfhozIgb6LU476word7A3QSftzJ4Yd4jfgTkFspF8LiR3ygFMDFTN unHohB9A==; Received-SPF: softfail (thebighonker.lerctr.org: transitioning domain of lerctr.org does not designate 76.250.255.117 as permitted sender) client-ip=76.250.255.117; envelope-from=ler@lerctr.org; helo=borg.lerctr.org; Received: from 76-250-255-117.lightspeed.austtx.sbcglobal.net ([76.250.255.117]:26282 helo=borg.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1n1vV0-0009d2-J6; Mon, 27 Dec 2021 13:17:34 -0600 Date: Mon, 27 Dec 2021 13:17:33 -0600 From: Larry Rosenman To: Konstantin Belousov Cc: Gleb Smirnoff , Alexander Motin , current@freebsd.org Subject: Re: My -CURRENT crashes.... Message-ID: <20211227191733.7mo64dvqejfsx4ck@borg.lerctr.org> References: <286c830efc0e12e3e7a7e9b2ede31c28@lerctr.org> <45ee5689-b24c-51b5-d7b7-33fd73ee7dce@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-Rspamd-Queue-Id: 4JN6r00HPZz4VlW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 27, 2021 at 09:15:53PM +0200, Konstantin Belousov wrote: > On Mon, Dec 27, 2021 at 10:58:02AM -0800, Gleb Smirnoff wrote: > > On Mon, Dec 27, 2021 at 01:43:01PM -0500, Alexander Motin wrote: > > A> > This allows us to deduct that the callout belongs to proc subsystem and > > A> > we can retrieve the proc it points to: c_lock - 0x128 = 0xfffff8030521e548 > > A> > It is ccache in PRS_NORMAL state. And the "tmp" in our stack frame is its > > A> > p_itcallout. > > A> > > > A> > So there is something that would zero out most of the p_itcallout while > > A> > it is scheduled? > > A> > > A> So carefully zero it, but keep the lock pointer... The only way that > > A> comes to mind is callout_init_mtx() in do_fork() if we assume the > > A> process has completed and the struct proc was reused. I guess if we > > A> could somehow leak scheduled callout in exit1(). May be we could add > > A> some more assertions to try catch callout still being active there. > > > > Note that _callout_stop_safe(p_itcallout) is the only place in kernel where > > CS_EXECUTING is used. > > I would start asking are there any third-party modules loaded. Nope. Id Refs Address Size Name 1 239 0xffffffff80200000 d94b58 kernel 2 1 0xffffffff81441000 f990 ehci.ko 3 12 0xffffffff81451000 3da98 usb.ko 4 1 0xffffffff8148f000 70ae00 zfs.ko 5 5 0xffffffff81b9a000 5338 xdr.ko 6 1 0xffffffff81ba0000 ccf0 ukbd.ko 7 7 0xffffffff81bad000 5248 hid.ko 8 1 0xffffffff81bb3000 b2c0 uhci.ko 9 1 0xffffffff8203d000 cec8 tmpfs.ko 10 1 0xffffffff8204a000 3538 fdescfs.ko 11 2 0xffffffff8204e000 3240 procfs.ko 12 3 0xffffffff82052000 5778 pseudofs.ko 13 1 0xffffffff82058000 9290 aesni.ko 14 1 0xffffffff82062000 20f0 coretemp.ko 15 1 0xffffffff82065000 3238 filemon.ko 16 1 0xffffffff82069000 2dd58 linux.ko 17 4 0xffffffff82097000 aea8 linux_common.ko 18 1 0xffffffff820a2000 4250 ichsmb.ko 19 2 0xffffffff820a7000 2180 smbus.ko 20 1 0xffffffff820aa000 4c10 ichwd.ko 21 1 0xffffffff820af000 2220 cpuctl.ko 22 1 0xffffffff820b2000 4338 cryptodev.ko 23 1 0xffffffff820b7000 2238 dtraceall.ko 24 8 0xffffffff820ba000 8a60 opensolaris.ko 25 8 0xffffffff82200000 84a300 dtrace.ko 26 1 0xffffffff820c3000 2274 dtmalloc.ko 27 1 0xffffffff820c6000 3331 fbt.ko 28 1 0xffffffff820ca000 56570 fasttrap.ko 29 1 0xffffffff82121000 2258 sdt.ko 30 1 0xffffffff82124000 91b4 systrace.ko 31 1 0xffffffff8212e000 91b4 systrace_freebsd32.ko 32 1 0xffffffff82138000 234c profile.ko 33 1 0xffffffff8213b000 8b38 ipmi.ko 34 3 0xffffffff82144000 45b0 efirt.ko 35 1 0xffffffff82149000 75b0 if_bridge.ko 36 1 0xffffffff82151000 50d8 bridgestp.ko 37 1 0xffffffff82157000 1662c hwpmc.ko 38 1 0xffffffff8216e000 28bb8 tcp_rack.ko 39 1 0xffffffff82197000 21b8 mfip.ko 40 2 0xffffffff82a4b000 84470 cam.ko 41 1 0xffffffff8219a000 7d38 ioat.ko 42 1 0xffffffff821a2000 48888 if_bce.ko 43 1 0xffffffff82ad0000 17a50 miibus.ko 44 1 0xffffffff821eb000 44b0 usb_quirk.ko 45 1 0xffffffff821f0000 b3a8 usb_template.ko 46 1 0xffffffff821fc000 3268 ums.ko 47 1 0xffffffff82ae8000 92d0 xhci.ko 48 1 0xffffffff82af2000 6120 ohci.ko 49 1 0xffffffff82af9000 43ef8 nfscl.ko 50 3 0xffffffff82b3d000 18cf0 nfscommon.ko 51 3 0xffffffff82b56000 2168 nfssvc.ko 52 4 0xffffffff82b59000 138a0 krpc.ko 53 1 0xffffffff82b6d000 4e638 nfsd.ko 54 1 0xffffffff82bbc000 bdc0 nfslockd.ko 55 1 0xffffffff82bc8000 4168 ataintel.ko 56 2 0xffffffff82bcd000 8358 ata.ko 57 1 0xffffffff82bd6000 5388 atapci.ko 58 1 0xffffffff82bdc000 4d40 geom_label.ko 59 1 0xffffffff82be1000 29f58 linux64.ko 60 1 0xffffffff82c0b000 2260 pty.ko 61 1 0xffffffff82c0e000 639c linprocfs.ko 62 1 0xffffffff82c15000 3284 linsysfs.ko 63 1 0xffffffff82c19000 3378 acpi_wmi.ko 64 1 0xffffffff82c1d000 2280 uhid.ko 65 1 0xffffffff82c20000 3320 usbhid.ko 66 1 0xffffffff82c24000 31f8 hidbus.ko 67 1 0xffffffff82c28000 32c0 wmt.ko 68 1 0xffffffff82c2c000 41a38 pf.ko 69 1 0xffffffff82c6e000 2a08 mac_ntpd.ko 70 5 0xffffffff82c71000 fb28 netgraph.ko 71 1 0xffffffff82c81000 63f8 ng_netflow.ko 72 1 0xffffffff82c88000 41e8 ng_ksocket.ko 73 1 0xffffffff82c8d000 3180 ng_ether.ko 74 1 0xffffffff82c91000 3918 ng_socket.ko 75 1 0xffffffff82c95000 4708 nullfs.ko -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Tue Dec 28 23:25:10 2021 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 29EC01922340; Tue, 28 Dec 2021 23:25:24 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [85.220.129.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JNrHR1Ys1z4gkQ; Tue, 28 Dec 2021 23:25:23 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id A686710B4FA8; Wed, 29 Dec 2021 00:25:15 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 899A610A75DE; Wed, 29 Dec 2021 00:25:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1640733911; 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=lVYG6NU3ub7nNvQrreDbgAyWiqDg6eVS0/K1cR9PwB0=; b=CqHkw8MXcCD15SivN++PPAJHxnoWmDLUAn1C+dBSv9rr3xSHo8xBjssoVWF44025qpzwuF B/mNzfKAUlJOwWmeIyRaTWQUjpmcyzqZw6h41rzR76Ms0SuWzA/lk6o7FoQm4ocVe53BBP 0m5eAL4H6W+kuDokle285Nrdmx+78BB9P9L4cxl+pCU+xyFC7uNxFql3CXMtGntPPln6BH /CjfOldl8gUvyb3AgVNbowkB9Nc1uY/MuvY1SZ0wYQAAcWnqL9rSsy47xyFUMKH+B80GBx Z8zF+cDlcf40c3zwcV9goSNshUfmelVgXUT0nRHoP8RtBPDsR8jwcROjkj+0vQ== Received: from hermann (dynamic-2a01-0c23-5c11-aa00-2ad2-44ff-fe79-8732.c23.pool.telefonica.de [IPv6:2a01:c23:5c11:aa00:2ad2:44ff:fe79:8732]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 208CA10A32F5; Wed, 29 Dec 2021 00:25:11 +0100 (CET) Date: Wed, 29 Dec 2021 00:25:10 +0100 From: FreeBSD User To: Marc Fonvieille Cc: Andrew Stevenson , freebsd-embedded@freebsd.org, FreeBSD CURRENT Subject: Re: Arduino IDF -> make/automake based environment Message-ID: <20211229002510.2e2c9cb0@hermann> In-Reply-To: References: <20211219120947.75530a82@hermann> <0024BDB4-ABFE-4DAE-BC99-0AF43F8B3180@ugh.net.au> 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-Rspamd-UID: 54e575 X-Rspamd-UID: e08854 X-Rspamd-Queue-Id: 4JNrHR1Ys1z4gkQ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=CqHkw8MX; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.30) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.89 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.30:from] X-ThisMailContainsUnwantedMimeParts: N On Mon, 20 Dec 2021 14:35:10 +0100 Marc Fonvieille wrote: > Le 19.12.2021 21:03, Andrew Stevenson a =E9crit : > >=20 > > =20 > > > On 19. Dec 2021, at 12:18, FreeBSD User wrot= e: > > >=20 > > > environment. Since I'm interested in coding for some smaller AMTEL MC= Us and ESP32 > > > and like to digg a bit deeper than simply clicking a host base from a= menu, I'm not > > > afraid of doing some larger basic setup if needed. =20 > >=20 > > If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in po= rts. > > =20 >=20 > For ESP32, you should look at: > https://wiki.freebsd.org/electronics/arduino/esp32 Following these instructions with the most recent required ports on the lat= est 13-STABLE, results in an linker error: /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../= ../xtensa-esp32-elf/bin/ld: cannot find crt1-sim.o: No such file or directory /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../= ../xtensa-esp32-elf/bin/ld: cannot find _vectors.o: No such file or directory collect2: error: ld returned 1 exit status > and > https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for= -arduino-on-freebsd12-update-2021-08-17.78408/ >=20 From nobody Wed Dec 29 07:10:02 2021 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 2826E192544D; Wed, 29 Dec 2021 07:10:13 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JP2bm67kvz4Rtq; Wed, 29 Dec 2021 07:10:12 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=7Rs1FW2f+91B7Jcqqoxx7yGPm9JvLvXvTB2HAkkJldc=; b=kbWP5BtVEOJv0Hm8dnFJsCGuGTzG1oEjtj+Rxx+LPYQCkTN0Gdm3PXg0LDZQJuFj+3PQzMLpXJSGIXI4eIkB7++3rdxUbWhzG2Yvy0uDqxA06na20tdTZyW6uLrq7H+acGcVJB+n3Tm5D5KQF3UCRqDLqhQipC9waE+f+W1TO63sc5H0TTjcoRP2WfDJB5HywFHaM3bMmAHdf9xw1lbcnfosBN2yyQSrA3z5bt4fArAqfpx3AUMClcnUNYNVgrPUkKtLs6heW+7LL/3uRHhFVbnOZ7yIAnUdG6odY5xeaavVcBwyTyOdHYjTmtQAEMYYbs33evTW3PAQ0CV8528JDg==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1n2T63-000Nj0-80; Wed, 29 Dec 2021 09:10:03 +0200 From: Daniel Braniss Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6F9A623B-5E83-4BA7-AC47-9CFCD8BAF837" 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 14.0 \(3654.120.0.1.13\)) Subject: Re: Arduino IDF -> make/automake based environment Date: Wed, 29 Dec 2021 09:10:02 +0200 In-Reply-To: <20211229002510.2e2c9cb0@hermann> Cc: Marc Fonvieille , Andrew Stevenson , freebsd-embedded@freebsd.org, FreeBSD CURRENT To: FreeBSD User References: <20211219120947.75530a82@hermann> <0024BDB4-ABFE-4DAE-BC99-0AF43F8B3180@ugh.net.au> <20211229002510.2e2c9cb0@hermann> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JP2bm67kvz4Rtq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_6F9A623B-5E83-4BA7-AC47-9CFCD8BAF837 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Dec 2021, at 01:25, FreeBSD User wrote: >=20 > On Mon, 20 Dec 2021 14:35:10 +0100 > Marc Fonvieille > = wrote: >=20 >> Le 19.12.2021 21:03, Andrew Stevenson a =C3=A9crit : >>>=20 >>>=20 >>>> On 19. Dec 2021, at 12:18, FreeBSD User = wrote: >>>>=20 >>>> environment. Since I'm interested in coding for some smaller AMTEL = MCUs and ESP32 >>>> and like to digg a bit deeper than simply clicking a host base from = a menu, I'm not >>>> afraid of doing some larger basic setup if needed. =20 >>>=20 >>> If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in = ports. >>>=20 >>=20 >> For ESP32, you should look at: >> https://wiki.freebsd.org/electronics/arduino/esp32 >=20 > Following these instructions with the most recent required ports on = the latest 13-STABLE, > results in an linker error: >=20 > = /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../..= /../xtensa-esp32-elf/bin/ld: > cannot find crt1-sim.o: No such file or directory > = /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../..= /../xtensa-esp32-elf/bin/ld: > cannot find _vectors.o: No such file or directory > collect2: error: ld returned 1 exit status >=20 >=20 >> and >> = https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-= arduino-on-freebsd12-update-2021-08-17.78408/ = i gave up compiling the xtensa stuff, specially after espressif came out = with a riscv version. so I downloaded the oficial idf and under FreeBSD-13 it almost worked = out of the box, if you want I can search my notes =E2=80=A6 danny --Apple-Mail=_6F9A623B-5E83-4BA7-AC47-9CFCD8BAF837 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 29 Dec 2021, at 01:25, FreeBSD User <freebsd@walstatt-de.de> wrote:

On Mon, 20 Dec 2021 14:35:10 +0100
Marc Fonvieille <blackend@freebsd.org> wrote:

Le = 19.12.2021 21:03, Andrew Stevenson a =C3=A9crit :


On 19. Dec 2021, at = 12:18, FreeBSD User <freebsd@walstatt-de.de> wrote:

environment. Since I'm interested in coding for some smaller = AMTEL MCUs and ESP32
and like to digg a bit deeper than = simply clicking a host base from a menu, I'm not
afraid of = doing some larger basic setup if needed.  

If by small AMTEL MCUs you mean = AVRs then avr-gcc and avrdude are in ports.


For ESP32, you should look at:
https://wiki.freebsd.org/electronics/arduino/esp32

Following these instructions with the most recent required = ports on the latest 13-STABLE,
results in an linker error:

/usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2= .0/../../../../xtensa-esp32-elf/bin/ld:
cannot find crt1-sim.o: No such file or directory
/usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2= .0/../../../../xtensa-esp32-elf/bin/ld:
cannot find _vectors.o: No such file or directory
collect2: error: ld returned 1 = exit status


and
https://forums.freebsd.org/threads/a-guide-for-installing-esp32= -board-for-arduino-on-freebsd12-update-2021-08-17.78408/
<= /div>

i gave up = compiling the xtensa stuff, specially after espressif came out with a = riscv version.
so I downloaded the oficial idf and = under FreeBSD-13 it almost worked  out of the box,
if you want I can search my notes =E2=80=A6

danny

= --Apple-Mail=_6F9A623B-5E83-4BA7-AC47-9CFCD8BAF837-- From nobody Wed Dec 29 12:06:41 2021 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 B38A719064AE; Wed, 29 Dec 2021 12:06:54 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JP9B63tLLz3G5G; Wed, 29 Dec 2021 12:06:54 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 8B32F1067541; Wed, 29 Dec 2021 13:06:45 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id AD35E10A32E6; Wed, 29 Dec 2021 13:06:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1640779603; 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=mCXS0xYzEk7CexJRxyXyDNxMcu84BEG5VFA60yIENvw=; b=ku9fjI2CA7rP52CrFCo615zH2MjD+4UIP3V/1SjaS4TlGOqh0pOpyAjUbTwFVrw9j9LWD0 M3+Y6JOqr56jiG9RN+oYPzKE5jg9+KJtF9IvAOw3vpBUJ9TEoG3adHSlU00+U2dEYBviSk Bue+si+yi7zwJ4WKwlJFESXu/q2/RkOz1lcxSkvfUUBfIlo68T9OJ1vSFYuc7r9fvA1AXM rEa3yUjFV7Wd5daQs5gczBom3hXzzFRRhOj5ZqlDbfB+hOstpynErWe1Mcn6EdyPlt/pUc zPXrY5/ORYs3wt2GN58L592S8Vn/WYWnWpaNLrv6kxq078nAy/fipTz1dstrEQ== Received: from hermann (dynamic-2a01-0c22-3454-c100-2ad2-44ff-fe79-8732.c22.pool.telefonica.de [IPv6:2a01:c22:3454:c100:2ad2:44ff:fe79:8732]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 9530910A3309; Wed, 29 Dec 2021 13:06:42 +0100 (CET) Date: Wed, 29 Dec 2021 13:06:41 +0100 From: FreeBSD User To: Daniel Braniss Cc: Marc Fonvieille , Andrew Stevenson , freebsd-embedded@freebsd.org, FreeBSD CURRENT Subject: Re: Arduino IDF -> make/automake based environment Message-ID: <20211229130641.26a93b2f@hermann> In-Reply-To: References: <20211219120947.75530a82@hermann> <0024BDB4-ABFE-4DAE-BC99-0AF43F8B3180@ugh.net.au> <20211229002510.2e2c9cb0@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-UID: dd1e16 X-Rspamd-UID: 98ad0f X-Rspamd-Queue-Id: 4JP9B63tLLz3G5G X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 29 Dec 2021 09:10:02 +0200 Daniel Braniss wrote: > > On 29 Dec 2021, at 01:25, FreeBSD User wrote: > >=20 > > On Mon, 20 Dec 2021 14:35:10 +0100 > > Marc Fonvieille > wr= ote: > > =20 > >> Le 19.12.2021 21:03, Andrew Stevenson a =C3=A9crit : =20 > >>>=20 > >>> =20 > >>>> On 19. Dec 2021, at 12:18, FreeBSD User wro= te: > >>>>=20 > >>>> environment. Since I'm interested in coding for some smaller AMTEL M= CUs and ESP32 > >>>> and like to digg a bit deeper than simply clicking a host base from = a menu, I'm not > >>>> afraid of doing some larger basic setup if needed. =20 > >>>=20 > >>> If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in = ports. > >>> =20 > >>=20 > >> For ESP32, you should look at: > >> https://wiki.freebsd.org/electronics/arduino/esp32 =20 > >=20 > > Following these instructions with the most recent required ports on the= latest > > 13-STABLE, results in an linker error: > >=20 > > /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../..= /../../xtensa-esp32-elf/bin/ld: > > cannot find crt1-sim.o: No such file or directory > > /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../..= /../../xtensa-esp32-elf/bin/ld: > > cannot find _vectors.o: No such file or directory > > collect2: error: ld returned 1 exit status > >=20 > > =20 > >> and > >> https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-= for-arduino-on-freebsd12-update-2021-08-17.78408/ > >> > >> =20 > i gave up compiling the xtensa stuff, specially after espressif came out = with a riscv > version. so I downloaded the oficial idf and under FreeBSD-13 it almost w= orked out of > the box, if you want I can search my notes =E2=80=A6 >=20 > danny >=20 Hello. I think, that will be the first step in the right direction (using the offi= cial eps-idf). Since I didn't come along with the salvation of the linker error reported e= arlier, I switched back to an older project from January this year. It is also based = on the official FreeBSD Arduino 1.8.5 port and the xtensa compiler 5.2.0 from port= s, but I used within sketchbook/hardware/esp32 the esp32 git branch release/v1.0 instead = of master on which I faced the crt1-sim.o error. The goal is to compile HyperionLED (as = a side product) with the recommended libraries for this project. It doesn't compile with ESP32 branch release/v1.0, the error is now [...] libraries/FastLED/src/platforms/esp/32/clockless_rmt_esp32.h:149:33: error: 'cpu_hal_get_cycle_count' was not declared ... [...] which lead me to the conclusion that a more recent version is required. Wit= h the recent version of ESP32 stuff in place, I face the mentioned crt1-sim.o error. Searching the web for that error leads to a discrepancy of ESP-IDF and the = compiler stuff. I'll try the original esp-idf as you suggested (it is a pity it is backed b= y cmake, I'm not quite familiar with cmake yet). Any advice is highly appreciated. Kind regards, oh From nobody Wed Dec 29 13:16:38 2021 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 6CE0A19133FC; Wed, 29 Dec 2021 13:16:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPBkd0zrbz3QFf; Wed, 29 Dec 2021 13:16:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=ScEtk7fZ8h8NfTjDAVGkcVtulWvLefee3jq+K/U1elE=; b=G6ZnzBiGUjCh2o+Qi7Lud0N2QfRAjX/YiJ+kpaw+CAxTDVG5v6QaBiWv/1qB6H2yk/7LFx5S2rA0UswwmPrNib0BLL4YjkJsNE21/XDUF3sUEnSjxpu1FpY6rqiEdeWQT0+jpsuY1gDBmm8JjF9fQ7k0CYJRVGbOdO4VldbwGV3qpJptWxcBd153S5nZn4bPUGgQ1FXJq/TbubS1b3MsGsBEIdgb6rEOdsBR0DGk2mUEAdvDfUjwz1lAx1bJnWKxMT3JXLT7qYvGYNWAHHicguix472JSrHvwqlXWl+yOydjVdEUzMhZ+K0SAZ6Kl9WPwG9jnWRgGXQw2N7xI2TlGg==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1n2Yoo-0002ib-Tb; Wed, 29 Dec 2021 15:16:38 +0200 From: Daniel Braniss Message-Id: <23D75BE9-B42C-4403-9569-728E3E94B169@cs.huji.ac.il> Content-Type: multipart/alternative; boundary="Apple-Mail=_B2BB71DB-FA9E-47A5-BC13-B80005EBFC15" 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 15.0 \(3693.40.0.1.81\)) Subject: Re: Arduino IDF -> make/automake based environment Date: Wed, 29 Dec 2021 15:16:38 +0200 In-Reply-To: <20211229130641.26a93b2f@hermann> Cc: Marc Fonvieille , Andrew Stevenson , freebsd-embedded@freebsd.org, FreeBSD CURRENT To: FreeBSD User References: <20211219120947.75530a82@hermann> <0024BDB4-ABFE-4DAE-BC99-0AF43F8B3180@ugh.net.au> <20211229002510.2e2c9cb0@hermann> <20211229130641.26a93b2f@hermann> X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Queue-Id: 4JPBkd0zrbz3QFf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_B2BB71DB-FA9E-47A5-BC13-B80005EBFC15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Dec 2021, at 14:06, FreeBSD User wrote: >=20 > On Wed, 29 Dec 2021 09:10:02 +0200 > Daniel Braniss > = wrote: >=20 >>> On 29 Dec 2021, at 01:25, FreeBSD User > wrote: >>>=20 >>> On Mon, 20 Dec 2021 14:35:10 +0100 >>> Marc Fonvieille = >> wrote: >>>=20 >>>> Le 19.12.2021 21:03, Andrew Stevenson a =C3=A9crit : =20 >>>>>=20 >>>>>=20 >>>>>> On 19. Dec 2021, at 12:18, FreeBSD User = wrote: >>>>>>=20 >>>>>> environment. Since I'm interested in coding for some smaller = AMTEL MCUs and ESP32 >>>>>> and like to digg a bit deeper than simply clicking a host base = from a menu, I'm not >>>>>> afraid of doing some larger basic setup if needed. =20 >>>>>=20 >>>>> If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are = in ports. >>>>>=20 >>>>=20 >>>> For ESP32, you should look at: >>>> https://wiki.freebsd.org/electronics/arduino/esp32 =20 >>>=20 >>> Following these instructions with the most recent required ports on = the latest >>> 13-STABLE, results in an linker error: >>>=20 >>> = /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../..= /../xtensa-esp32-elf/bin/ld: >>> cannot find crt1-sim.o: No such file or directory >>> = /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../..= /../xtensa-esp32-elf/bin/ld: >>> cannot find _vectors.o: No such file or directory >>> collect2: error: ld returned 1 exit status >>>=20 >>>=20 >>>> and >>>> = https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-= arduino-on-freebsd12-update-2021-08-17.78408/ = >>>> = > >>>>=20 >> i gave up compiling the xtensa stuff, specially after espressif came = out with a riscv >> version. so I downloaded the oficial idf and under FreeBSD-13 it = almost worked out of >> the box, if you want I can search my notes =E2=80=A6 >>=20 >> danny >>=20 >=20 > Hello. >=20 > I think, that will be the first step in the right direction (using the = official eps-idf). > Since I didn't come along with the salvation of the linker error = reported earlier, I > switched back to an older project from January this year. It is also = based on the > official FreeBSD Arduino 1.8.5 port and the xtensa compiler 5.2.0 from = ports, but I used > within sketchbook/hardware/esp32 the esp32 git branch release/v1.0 = instead of master on > which I faced the crt1-sim.o error. The goal is to compile HyperionLED = (as a side > product) with the recommended libraries for this project. > It doesn't compile with ESP32 branch release/v1.0, the error is now >=20 > [...] > libraries/FastLED/src/platforms/esp/32/clockless_rmt_esp32.h:149:33: = error: > 'cpu_hal_get_cycle_count' was not declared ... > [...] >=20 > which lead me to the conclusion that a more recent version is = required. With the recent > version of ESP32 stuff in place, I face the mentioned crt1-sim.o = error. same here, apart from the need for a different compiler for the riskv = chips. >=20 > Searching the web for that error leads to a discrepancy of ESP-IDF and = the compiler stuff. >=20 > I'll try the original esp-idf as you suggested (it is a pity it is = backed by cmake, I'm > not quite familiar with cmake yet). >=20 > Any advice is highly appreciated. espidf version i=E2=80=99m using is 5 (master) and it needs linux = emulation and yes, cmake, but it=E2=80=99s not that difficult to master, just check the examples CMakefile=E2=80=99s. if you need more specific help just yell :-) danny >=20 > Kind regards, > oh --Apple-Mail=_B2BB71DB-FA9E-47A5-BC13-B80005EBFC15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 29 Dec 2021, at 14:06, FreeBSD User <freebsd@walstatt-de.de> wrote:

On Wed, 29 Dec 2021 09:10:02 +0200
Daniel = Braniss <danny@cs.huji.ac.il> wrote:

On= 29 Dec 2021, at 01:25, FreeBSD User <freebsd@walstatt-de.de> wrote:

On Mon, 20 Dec 2021 14:35:10 +0100
Marc = Fonvieille <blackend@freebsd.org <mailto:blackend@freebsd.org>> wrote:

Le = 19.12.2021 21:03, Andrew Stevenson a =C3=A9crit :  


On 19. Dec 2021, at = 12:18, FreeBSD User <freebsd@walstatt-de.de> wrote:

environment. Since I'm interested in coding for some smaller = AMTEL MCUs and ESP32
and like to digg a bit deeper than = simply clicking a host base from a menu, I'm not
afraid of = doing some larger basic setup if needed.    

If by small AMTEL MCUs you mean = AVRs then avr-gcc and avrdude are in ports.


For ESP32, you should look at:
https://wiki.freebsd.org/electronics/arduino/esp32 =  

Following these = instructions with the most recent required ports on the latest
13-STABLE, results in an linker error:

/usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2= .0/../../../../xtensa-esp32-elf/bin/ld:
cannot find = crt1-sim.o: No such file or directory
/usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2= .0/../../../../xtensa-esp32-elf/bin/ld:
cannot find = _vectors.o: No such file or directory
collect2: error: ld = returned 1 exit status


and
https://forums.freebsd.org/threads/a-guide-for-installing-esp32= -board-for-arduino-on-freebsd12-update-2021-08-17.78408/
<https://forums.freebsd.org/threads/a-guide-for-installing-esp32= -board-for-arduino-on-freebsd12-update-2021-08-17.78408/>

i gave up compiling = the xtensa stuff, specially after espressif came out with a riscv
version. so I downloaded the oficial idf and under FreeBSD-13 = it almost worked  out of
the box, if you want I can = search my notes =E2=80=A6

danny


Hello.

I think, that will be the first step in the right direction = (using the official eps-idf).
Since I didn't come along with the salvation of the linker = error reported earlier, I
switched back to an older project from January this year. It = is also based on the
official FreeBSD Arduino 1.8.5 port and the xtensa compiler = 5.2.0 from ports, but I used
within sketchbook/hardware/esp32 the esp32 git branch = release/v1.0 instead of master on
which I faced the crt1-sim.o error. The goal is to compile = HyperionLED (as a side
product) with the recommended libraries for this = project.
It doesn't = compile with ESP32 branch release/v1.0, the error is now

[...]libraries/FastLED/src/platforms/esp/32/clockless_rmt_esp32.h:14= 9:33: error:
'cpu_hal_get_cycle_count' was not declared ...
[...]
which lead me = to the conclusion that a more recent version is required. With the = recent
version of = ESP32 stuff in place, I face the mentioned crt1-sim.o error.

same here, apart = from the need for a different compiler for the riskv = chips.


Searching the = web for that error leads to a discrepancy of ESP-IDF and the compiler = stuff.

I'll try the = original esp-idf as you suggested (it is a pity it is backed by cmake, = I'm
not quite = familiar with cmake yet).

Any advice is highly appreciated.

espidf = version i=E2=80=99m using is 5 (master) and it needs linux emulation and = yes, cmake, but it=E2=80=99s not that difficult to = master,
just check the examples CMakefile=E2=80=99s.
<= br class=3D"">
if you need more specific help just yell = :-)

danny




Kind regards,
oh

= --Apple-Mail=_B2BB71DB-FA9E-47A5-BC13-B80005EBFC15-- From nobody Wed Dec 29 15:35:31 2021 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 3506F19147D4; Wed, 29 Dec 2021 15:35:34 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPFpt0MYXz4Rxd; Wed, 29 Dec 2021 15:35:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 41B84245CE; Wed, 29 Dec 2021 15:35:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <4dfbdcce-43d8-3bfc-6858-939ab18d637d@FreeBSD.org> Date: Wed, 29 Dec 2021 17:35:31 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.1 Content-Language: en-US To: current@FreeBSD.org, geom@freebsd.org From: Andriy Gapon Subject: gmirror: read failed when one disk (of two) failed Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640792134; 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=xJlcs2YVdfjPBwkAjZh+cCsgzKEeXiMHfmcp+3d8MSc=; b=mZB+LQNg4Cb6UGnkhyAQ5BtsVCcY1w2GNVCVlfEEGENh9JTXAelhGIRT8ejGrFtBNdn0pn v2HWy//N9iGDENezQsvMYwiMwi7iBGAkIBXVZXkdpLck9RHjNPxuJl2N1E1Kouxo9YrBnG RTtqdBSzD+FvIjDDEvYU+eeahBl8+PKMZO8BQ0PtmrVlx9qnXEXDxZSq3ARaRwBcGRzY1A XZFIFYLi76CML2v3ksaKFpIlhUfD6Q8onvRbv7Amch0yB5A649VwPPUFTMysDyXmM7pSmA eyYc+H0zwQwG7TGPcZNJ0FjztRIoFvh/e9unV3r1ah0xGGlQnHV+6XkwaUV96w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640792134; a=rsa-sha256; cv=none; b=sbaHb2CfAZfzccCS+LtvllUd6VPVvkLq9ZNzRMYDki9WPfGOxUHT/T+STpZoF7sd0V32rQ dNTGu17U2oaeBKtd96FD/n/KCFIvTovJ976LeiLJf052mMXLloyaLbofoYa4fbSmcH8foW dhvfVg193YpXSa1bKKeqxCMdGm5EItTLcw3fS6De6Ph0V2TGb2pBYfS5b7q8HcCh6EAXMg G9qqJty/Oq85p3wVkDkA7E1sYB/d7PbiQdssbpyDOtRqsDc4CFCkniKAa+2lCPDY5Qll0c i3Sfe0UNfg2bCpWgDLctw9JokQ+kKOV1BzO9UGYRMqsfWe0KqfUuyL1v63WVvQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N I have a gmirror-ed swap partition: # swapinfo -h Device Size Used Avail Capacity /dev/mirror/swap 8.0G 2.6G 5.4G 33% # gmirror list Geom name: swap State: COMPLETE Components: 2 Balance: prefer Slice: 4096 Flags: NONE GenID: 4 SyncID: 20 ID: 1722474567 Type: AUTOMATIC Providers: 1. Name: mirror/swap Mediasize: 8589934080 (8.0G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e0 Consumers: 1. Name: ada0p2 Mediasize: 8589934592 (8.0G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: (null) GenID: 4 SyncID: 20 ID: 1654937889 2. Name: ada1p2 Mediasize: 8589934592 (8.0G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 655360 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: (null) GenID: 4 SyncID: 20 ID: 1289215755 Recently I had an accident where one of the disks got lost, with some "struggle". I see two things in the logs that concern me. One is mildly concerning and the other seems to be serious. The disk was known as ada1, it was attached to ahcich5. So, while the failing disk was struggling, I got messages like: ahcich5: AHCI reset: device not ready after 31000ms (tfd = 00000080) swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1175296, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 268223, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1175296, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 268223, size: 4096 ahcich5: Timeout on slot 18 port 0 ahcich5: is 00000000 cs 00040000 ss 00000000 rs 00040000 tfd 80 serr 00000000 cmd 0020f217 (aprobe0:ahcich5:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ahcich5:0:0:0): CAM status: Command timeout (aprobe0:ahcich5:0:0:0): Retrying command, 0 more tries remain swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1175296, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 268223, size: 4096 ahcich5: AHCI reset: device not ready after 31000ms (tfd = 00000080) swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1175296, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 268223, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1175296, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 268223, size: 4096 ahcich5: Timeout on slot 19 port 0 ahcich5: is 00000000 cs 00080000 ss 00000000 rs 00080000 tfd 80 serr 00000000 cmd 0020f317 (aprobe0:ahcich5:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ahcich5:0:0:0): CAM status: Command timeout (aprobe0:ahcich5:0:0:0): Error 5, Retries exhausted swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1175296, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 268223, size: 4096 Ideally, it would be nice if gmirror could instruct a chosen member disk to "fail fast", so that a different disk could be tried ASAP in case of any trouble. Only if all members cannot provide the requested data the mirror should switch to "try hard" mode. The more serious issue happened after the struggle was over: ada1 at ahcich5 bus 0 scbus6 target 0 lun 0 ada1: s/n GY3049963 detached GEOM_MIRROR: Request failed (error=6). ada1p2[READ(offset=1098641408, length=4096)] pass4 at ahcich5 bus 0 scbus6 target 0 lun 0 pass4: s/n GY3049963 detached GEOM_MIRROR: Device swap: provider ada1p2 disconnected. swap_pager: I/O error - pagein failed; blkno 1175296,size 4096, error 6 vm_fault: pager read error, pid 1310 (devd) pid 1310 (devd), jid 0, uid 0: exited on signal 10 (core dumped) It looks that the mirror did not do its job properly? It got ENXIO from one disk and it passed that up to a consumer (swap). I suspect that there wa a race between an I/O request getting ENXIO from a failed disk and an orphan event from the same disk. With only one member left the mirror may not realize that the ENXIO came from the detached disk, so it may think that there is no device left to re-try the request. -- Andriy Gapon From nobody Wed Dec 29 20:28:39 2021 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 841321921F9B for ; Wed, 29 Dec 2021 20:28:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPNKJ3NQTz55pr for ; Wed, 29 Dec 2021 20:28:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640809724; bh=6w2HTSeqmTc+hdlWTWk+KKavQfWLY5ywmgUcOAaJYNM=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Vi1XOXnitmB/Z4nrESNZguJrLELMRZDK3iytvswzArKYLe7xnobLwvnzjlezZWtZ8+/Bk2YxVGYblNp/VBeIM0XmR+g1qb+myipOPhgv7KiM7Yb7gj2tGx+7A21TR/Mc0oB2QARWUTXCMIs68hFD0bX2gTG5eWQhIVB+3yxB8JzFIP4I1sDAWGtMp9nnb4LkJbFEC5fYK/vJBTBnayklNoOD6IArObdL/LGWYYwWsj48jKJtwBZpY/vxj4oSyIrrtqoNIN9z7nvJ+n1sRyJtYyRJW0vhUcHmkT4jMC99zsiPPl0sJEoQmWCtfMKu6qz2Z3zhqJmmx60AmqEfQ24f2Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640809724; bh=SecHk7KlOws2ff/tKme/92wqZvms1STQST/Z3xvRJ3G=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=tsRpGQUMraVvfzd5jYaDucQw7WVvKRCuNr0KigbNJIbWoJB3DmWefuUMqz+alM8IC/AvoLowtOi/CF58hAzmmK0oKdiXbFwihRHG8BlHGmTLfOtsUnzhZNqqF/5Dx7t3nFxblPBrYTtWidX0N4imK1d8+1bM8rqtZponvVGt0OgiSt9GUG7I+yusSrJK4FyPwKLkwG4KL2xqohfyX9h5aHsKGaP7nBMTYWPAPouyXULgu1X7py3X8xfLf3r5c+MZsswzqQLnlnT3VLTRaFqrVzlJXWlX7wfDpsDh6JZhFJIDL8QHW7JbnBGKhk0G8YZkhJE31RuvJdUTWAapbcWwvw== X-YMail-OSG: _ZafQZwVM1k7AefXOGSMvFnpCIxNGJ_UfxevIIlHkQMwz7jOu0VjOwk0CI1ljQ2 6AxCPNvJWym.KbXoTHivfIhtgPw8wTSdhaGyYVM95vOmYQ8HfZ7BArmbR5QOTRv_VQyE7_A_RzN2 amfbkLrLQbatME8O98.U.YfBmq0A7AyzkXR9yKkdRjNK_i9jlcnGJmwt8OCZZxcBI6Bgnctp3kiW 1fxt81XVZfsWqFnAm_MKNJyE3oP.jLhJ.46.krQql432.z0_D5CmsN7uHMwlGNkEnbbDjucwPzKd aIyYy7fqGHHrwEuqYnQBxBPNvk7z09Oayi21BqJ32K3.NK1pl1z93mB3XA5r3dojFwDHZp1SEqun GX7fWtpNp7P0viJCimBjK2k.laPtfKm.d8BusIrIcH5fU5jm.u4H5DCrKnLoxww_RXIqX.FMd7PD Cz7UxILedyRGupX4fQ.kzp.RhrBjjQ9sqYxRvhbuy4IqGAioUhcMZGLwA22DbJF6pisJSrZjI99r fyKmLAIp6TU6m61oo9r9qfegb.ZwhIcPMIxSSdmVeSAaTRuIQXiHBt2TKHr9XxnNVl4mSzrTTzAN eNHVaIib5aAPVw340Vj5kCx1gfgMlV2vMvjVVSDr3CRnSHv50HTKMJzixDZxYEeOUqS6w7twyTJI j9yeyUCK.r3tpM8xeNXfni6_4UGJf0I3GSIbU.YPHkH6qU9KmpEyXErKpm0AV92ATxGFhRgy8fWo s9YN6xlxtmIYm8oGC8_DRv_mRkurI0ktGGiMBZQ0c8RndShNt7adAACXfZvOA6HYZSGbiYLirB9R I4jNDBdPH.yjWDlIZpnU.WwlihAHoYLNHPyUJaVhOYseT6c7qspPdG5S24YPjrQ7yLii_SgTTCxR FAMZhKdfWsYHNKT9K0lX69ARjPc0ea9Uzhh5ISlCd5h2bncF5ezk75B69wONuAf7i85T_5sDa6lD 07yfGzenoFSHX9vZphKtkYZvrCLXAmDD25vJryZPaWMw6g8OXbqPUJaKziHROe7OsPzzY2d7yDv1 5mlfD3qjCPlX06oWBFDAPMRniAp2aBR..OcWW0VHA22hizRs5Xbl9Eoj6fN7nKLp3t7zSR6zx57Q AhM87A26JKFuLtGOhuFN9_rirJMo9746IpwG0W_h1s5yBxjqIdl.49mm3bxQbM2a9fuzsaugaIj4 GMa0ayVDRGDcEXgr6lKIYWQTXECP3mEjQZQBpq8vMb.Ug0pP5LfdL7LTAW8KXcmQT.a57ZXj17br x6uIdnmL6rYlZnBHz94YblIc6brcCEx14K5yN4RHjVbeNr8JmK.zDAbgqc0JyrKz9sQtg08CxbxZ pf7vbxWgxjz6VzILey1WIaTYHw_VTm.1XO1veFLOYUoPB16fJ3uaKcnd_vL5Z8Cq4eGUQO0olE_p ln9UC1fMdMpgXzZHAnq8xKD2ERFiDNgT8nCHmPHu0lFynQnJ7EXJ9UeUpn2q9yTCzXP6rtSSacjU sDWrOaek5UqpJgrqJlmvw3reVOOP26pqYUwAyJHOr4gGx8t7BBofF_T_psi_evYfDoYAlc_NtDpy dDugQ8FRWY2RpJX4X7wZFnTPVS8tJQsEX8BHD1nGwqKHxC24zt82RHL1ySwpj_XG2QqR.ed0NHip PM5mOwXnhdQzL5aWm1XPEiw9zatmutvn6wyaA5h5.AY5RPwNYbiBbIgQRhdc.2GviL9dibc9Tg_G H4zJaDht0uk4DU13hClF9YfUgAU5LRHXYyT.lTFp6c_ZQddwPNSPesp1GPAgpDX6ot1j_weuxSLb wJhg.JUpvP6dSVKa_qz_vIJ0p3pFNgF_gXuscdWB7b64P7WEtK8lxLn0DmN2rSh_ZnEOC8zzTk5r uSBtr3Oxm8giDgAung5w9EQpRBd.J5bBuAuJcER_v7dQcrJdENca_v_04D87nndjaC0utIQ.o3sh 93rioHEg01epFpr4nXs3Y9TxlFogHBK9eVsxeNKWz3D0ANIJpLxphzkn.OrJGSjjX_3VgbJWAU16 fqyUoSxoG5tIhCCO7ohU3y.BZE.Ju2N6551MD5.WHZyLe.C_e19qJyGag4QAyQI3cqsWkpXAN92b EJqg7NOz0VKRiXvwT5Ae3b.KYHetLqfJa9lngq22GnykRUlawD3MwSTD_wWV9l_T.YP49g_TvgoV A9lZQWQgG50X7h7n4MuB9rrFoIUUC19LcyZUW9KsnFi6fburNhflL8IYdFidgpA82jd7yNjRWYGz sp88o6enZ.eUi3tiqdMVY.gud2dmaFJHVw8reFeseDSsff5BnDYVVlmoTVJYMc0tmmF9kyHFWum2 yuPHr8ya7qJFc4uHBtrs- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 29 Dec 2021 20:28:44 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c49216d0c9c7ac8bf6eb36425f3f20d7; Wed, 29 Dec 2021 20:28:42 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Is amd64 buildworld supposed to be working for WITH_ASAN= WITH_UBSAN= (both used)? [It fails to link various things.] Message-Id: <2034FBE8-FD43-499B-B400-16F03BAE3D54@yahoo.com> Date: Wed, 29 Dec 2021 12:28:39 -0800 To: "arichardson@freebsd.org" , "emaste@freebsd.org" , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <2034FBE8-FD43-499B-B400-16F03BAE3D54.ref@yahoo.com> X-Rspamd-Queue-Id: 4JPNKJ3NQTz55pr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Vi1XOXni; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N In order to avoid the following for WITH_ASAN=3D WITH_UBSAN=3D (both = used), so also WITH_LLVM_BINUTILS=3D in use: --- all_subdir_usr.bin/clang --- --- llvm-as.full --- ld: error: undefined symbol: compressBound >>> referenced by Compression.cpp:51 = (/usr/main-src/contrib/llvm-project/llvm/lib/Support/Compression.cpp:51) >>> Compression.o:(llvm::zlib::compress(llvm::StringRef, = llvm::SmallVectorImpl&, int)) in archive = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/lib/cl= ang/libllvm/libllvm.a . . . ld: error: undefined symbol: compress2 . . . ld: error: undefined symbol: uncompress . . . ld: error: undefined symbol: crc32 >>> referenced by Compression.cpp:85 = (/usr/main-src/contrib/llvm-project/llvm/lib/Support/Compression.cpp:85) >>> Compression.o:(llvm::zlib::crc32(llvm::StringRef)) in = archive = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/lib/cl= ang/libllvm/libllvm.a I hacked in: # git -C /usr/main-src/ diff /usr/main-src/usr.bin/clang/ diff --git a/usr.bin/clang/llvm.prog.mk b/usr.bin/clang/llvm.prog.mk index 3a708805d3ea..74bed2ecd314 100644 --- a/usr.bin/clang/llvm.prog.mk +++ b/usr.bin/clang/llvm.prog.mk @@ -25,6 +25,7 @@ PACKAGE=3D clang .if ${.MAKE.OS} =3D=3D "FreeBSD" || !defined(BOOTSTRAPPING) LIBADD+=3D execinfo LIBADD+=3D tinfow +LIBADD+=3D z .endif LIBADD+=3D pthread which avoided the specific problem. But the next build attempt then got for missing Apple ObjC stuff and something involving the name renderscript : --- lldb.full --- ld: error: undefined symbol: = lldb_private::formatters::CMTimeSummaryProvider(lldb_private::ValueObject&= , lldb_private::Stream&, lldb_private::TypeSummaryOptions const&) >>> referenced by compressed_pair.h:61 = (/usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/u= sr/include/c++/v1/__memory/compressed_pair.h:61) >>> ObjCLanguage.o:(void = std::__1::__call_once_proxy >(void*)) in archive = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/lib/cl= ang/liblldb/liblldb.a ld: error: undefined symbol: = lldb_private::AppleObjCRuntimeV2::Initialize() . . . ld: error: undefined symbol: lldb_private::CFBasicHash::IsValid() const >>> referenced by NSDictionary.cpp:715 = (/usr/main-src/contrib/llvm-project/lldb/source/Plugins/Language/ObjC/NSDi= ctionary.cpp:715) >>> = NSDictionary.o:(lldb_private::formatters::NSCFDictionarySyntheticFrontEnd:= :CalculateNumChildren()) in archive = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/lib/cl= ang/liblldb/liblldb.a >>> referenced by NSSet.cpp:564 = (/usr/main-src/contrib/llvm-project/lldb/source/Plugins/Language/ObjC/NSSe= t.cpp:564) >>> = NSSet.o:(lldb_private::formatters::NSCFSetSyntheticFrontEnd::CalculateNumC= hildren()) in archive = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/lib/cl= ang/liblldb/liblldb.a . . . ld: error: undefined symbol: = lldb_private::lldb_renderscript::fixupX86FunctionCalls(llvm::Module&) . . . Is the "ObjC" related material and the "renderscript" related material even supposed to be referenced or linked in? If yes, what is missing to allow the links to complete. I've not tried to get past this. There could be more that fails to build after lldb. I'm not sure if WITH_ASAN=3D WITH_UBSAN=3D is supposed to do anything for buildkernel but I've not managed to get a buildworld to finish everything yet. May be src.conf is just ahead of what the build environment is set up for? For reference, at the time I was having the following build itself with the WITH_ASAN=3D WITH_UBSAN=3D added (manually line-split for readability): # uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #21 main-n252010-254e4e5b77d7-dirty: Tue Dec 28 15:54:08 PST 2021 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400045 1400045 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 29 21:38:41 2021 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 1C592190F1A3 for ; Wed, 29 Dec 2021 21:38:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPPsw0jjBz3H4l for ; Wed, 29 Dec 2021 21:38:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640813922; bh=jrNcJVIu5TFnuFQ1KM6QvmiWVgnNM/lb3HBxv8Q2W2M=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=LxN0eTaPhSmtZtQNudGbBM3Rw/s4lpLkzNyy1vhNBENmAskNQIdyxOSMXz0zs7T530wm+xi9/DbJljoqYiIXUyiThu0gEqmy2Jet/8kGim7ur+g0796ib+pQo8xFKmas3CwWmol9GqwpHP0/pwxxe4DTCCeqPxnoAPuiYMJzQMphYxkuEBE4Z+NyeWxk8K7lwBoOju3TGrhwXBAoLeKSQ5SMh0T2mHb7i3kXLn/NByZw9k/t1g1iumzff2O7PrkGGJ7ti4DrUpQ7Ht3mbUHuqDPZmT73+n1yzktYGWRM6jNFBNMztf4yjbYg0DQuppRHJBl/Bu073NEAAF9vzr0pgA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640813922; bh=zckJiIMXtZC03PvhXazIqNeNoNVc/K9rzpixy23mtq0=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ZY8/IpvwpUEp6cSgFl5LDCGZSxETIPWYlJReexOQjNY/x0pYzMu4u7EbicMy92n+JMojHDnStbn58wn0JoBZ95e3szqPeeSngM+8I8lytuQBsu/GoOhxkKr3e0XLyc33Mi00Aj+BDoaG/BtS17AcK7K4VZbhZiSbwKfJFDiyIccH0LUcxCzJqx5/G/w1W1pDasQzkmJdt7ycpofpL/kZgDDJnpzsmDnWvgOTYwU0IKSIyEyzvscpr0BnyzRjRYTCZvDBLJthoBhDXOpCPMEgG80uf77jK11pt/yqaZWITsLJpQzHQ6ZN5qHIpLSF4jtiOyz/6mi3H2qJ/VP6EC83sA== X-YMail-OSG: 1y7pHJYVM1l9SiWVWFW85GrG9A2W8GXBFylWK3cFvRIuovSKON3D.8FBsHQhtjI l8kAA7T8GI6LrwFja1Ko8ga521jXb1l6kD3dbjUw7t4yycAaSdnKIUM.bU8lSyAhVAzmrxlLLJ_E Tx37cN0jecM3XzMYfc5xqsjYrx.3f_UImSoBBQ2HYb5cXoxhzUv71qg3ex8CxVMUxb2uDWmTFZ_d 6Oofls2Z_jxV9s9ZY.BRX5kQfE3HkTWHoGQ_B6fDFfdsAqL.8vQQ7xskpngroi_kn58nIKL1XGZc ZUq8bAiiFMOePoDY7csqpusiJtS1HVWA1ABBJYYoUohWSwUCGvT2rfOi9yI9FeCSYlzjoWyCrpKw P__aFVVqbA5NDLjTWwduTOUgLK47Pmec8IWiNn9BAFWgZKSNB6TOZ1tz5NqP6FRNpmw9TE03YeG9 eWNdCEpNzR4ZpR8I1xBmmY6R8_8jjWEmrC04Cycwwaiz4KWPtXckqXXehKBfd5TTc9YDqiCxsH52 MfQBDBh4GPqXxQ5AEu7ax4d72GHeZp9Fbmh9GiGwyIPjGlkBCHJ6k6Mw4m9It8xVLtCtC0DjpGy6 zSmT17LpJvjCUc75jKfrMLP2eGQx_s5oURdBprBttqGjwrZWl4n6SN7epQLGtHRD1mM8HJLxA3Eg u4fW1JN_fYlaEut9VAOV_wtPgDAyHZcrxccePcwnP5gB7HUJrzRnC25CqqrctNh6VrHg4byv2fVJ 2tMluf6_NqSd2qC2Y6KLayVz2kMuwQjIDgeZKjXWt2pnp3QMBrUmPAeGE7kK9j5gO0PN5fjuIRoP E4ggV9_WI1XzmpgVqdCkVTxub_aMNFasC4PSTkEN.yKNZIbZYjJ330Z0JnPV.6Gmhyi2PHbxrqcU jTtZdc1dTK6FdJmCNrFWoT9aapZ8xoXCKmVCx0JEHl_2KPmJp0jroBNeuGhi6X2SnIvYOVvFj2Vt kYiyfe1R5cTPTx5FvhYDVxy2pSLWsW.J6rNq.C1f4ied_UDmK84oezU5LatQhb2FzW9rJnOlZrE2 vEnBVFn5UJ1ObeXONG2GJXN_OVDdHnPrpm7D2GtI6iWax7JnuJZx_Ws.8MllBJQvh1sQBf0xIPh. 4o8dsXt8MrOdWIIHD2WxoTWUhhc7DEOr8tC7U6WV7P.3I0LO.s9i7gvkZJtmkzzF33XRLavtPqeM UMghvSOiu6xEqtA7AnOgUS4QwgZBi_Ke.HZkb7rl3bXRCDzf13iKTQeBEiIb1gFYakTegYOe7r8W sgOuwPf7GPxoVqodPMie7Wd2.cOM705GOmG60FGW.m2LeCYzYH_Q4vEC4CfOeKx.nGLT1Ka8Kwvn Qsp7QzcGY.d8pMFvWnhQr8NwjMnwXpdPBr0zduu0UHUcnn1gOVs7G6V7SdV5DCWP.lp7FqCH37r_ .JDcHORatzFBbSfXqfzkmochIX37qWG9v_KK8zkzppR_aX.9qWXyowrvPwjAXPT0AsP63FlxNrpx hYIsc5KClQ2wsCP8sF2G37ijF6kD7dfBbc5trYuYpEzK5GuRYcv77_ZiJscOPvtJU71T0rrqQElo ssu7uKgBQDzGuW2d00Nxd3O8_iFlQTyB2FNxFPuv8cZWU8jDAqzXR0ZGOPKTaj4lb0XLdvOt30lR GACimp2KxnkYPvhTxkN_8hWP.YfNETJgRMf5ccTotCgS.ak.9x2SyY4hIMIew_FxKELfjZNoyxW6 uZnbz599W.cWuyjW1SWti4joqSRsxXe_SQKk_5bYHB9bnzN9PLI6Bblx9xZXZ3DDy0D.4UP7SQVw DX3RXwB1fkeaNMy_4EZz2E0Mi8qxzyJOilAsTxUH_rcaa2GLEQkj.jhmt_klFRjmJw0ilBXmhUET SLRuTiQzr5AKNL_9kcdpUme0_LV4j_B8Bh1eOQn6zhzGpJw8BN9EmnMCdE0YWvDQgmDg508DWVtB 7DGf2_hxnnv.9WVRJ83f7Nbxj3gdfgj9_AjDLwmiiqK1D5Hf0XbNlZKvPaXAS5zhvwFeuHKTO5eo WwkFbuWlZ.RcXWtg5fFpYTWgUmv3Ea7ZsjZKsXItuJXhlpJKIUYedjWw4pnt7naSdsl3AhBEgzT4 93E0yx10z3unYgHwrrFEocBaLhwU0w1abpLMVTwXMXWrijEU.CucC5A3y1GhXQsbdBzPgSd_yv1H ..vr1hgmnYpqJwySQhMtLvEj4EpMX2mDBLNNP6gVzdK5CpsSFWmKhlHjYq5G85Ngq8dfB7RUetGD QQhIOpXVmvS.TiF.fZKBBKsrEk2h8dq5rOo6EVe9q_A-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 29 Dec 2021 21:38:42 +0000 Received: by kubenode551.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1497140487491cf4c52dfe1f1b8dd24e; Wed, 29 Dec 2021 21:38:41 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 6b1c5775d1c2 - main - Move libc++ from /usr/lib to /lib Message-Id: <526C400E-C52D-4E59-9892-91DE002BE1D2@yahoo.com> Date: Wed, 29 Dec 2021 13:38:41 -0800 To: Ed Maste , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <526C400E-C52D-4E59-9892-91DE002BE1D2.ref@yahoo.com> X-Rspamd-Queue-Id: 4JPPsw0jjBz3H4l X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=LxN0eTaP; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.26 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.76)[-0.758]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Building 33812d60b960 ( so after 6b1c5775d1c2 ) and installing and rebooting did not put in place a /lib/libc++.so.1 but delete-old-libs removed the /usr/lib/libc++.so.1 . (Luckily my environment has sufficient recent near-redundancy to recover easily by putting in place a /usr/lib/libc++.so.1 .) === Mark Millard marklmi at yahoo.com From nobody Wed Dec 29 21:40:57 2021 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 B68261910A9E for ; Wed, 29 Dec 2021 21:41:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPPwj4VSVz3JMN for ; Wed, 29 Dec 2021 21:41:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640814062; bh=kzsgNnv6ThGQLo7MhOx6duOrponhednhjxK88iy6L9Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=L7p9fsI7HF0aj2ySfi9lzc+t0EPBI+HhnCHvB/vxIT1Qz1asQg7tR8SePMoNGmnVM9U+79KqsjWuqMFE0tfGEKeeJNGFikm7hPRIAGiGJ1rsfIv1YioTMtlRUC2LW8n7mPIVbyRSWpzyXqA0598AvqkQuCkWQ50xT70k75L2P+GAdQQ17tYI7m0BjXqtpobbfXcqN1njQsA79OKvHBJHvBYLFo6z5GfWexz1bMwXKKBGE7T+SWQ6NWkBokTqF92seRMUY1VWhPFb++jF9DpkKnXaYO/o1adLRWNoFtfT0MaGKmrRqms7GeJUtL3N/uhWsV6bAsdUJ9tu8bEnWrtbMQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640814062; bh=fw86rzZ+Mf0yURqK8TfJuoE5ZN8pnsQ/0ps64j5HIXk=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=M+bCM4gqU3Gch79/TPsrjJGNan9tLU3Rq1hCBIjGHartJxNVqj/P46vBCkHFeLDOr9fZEjq/rCPwc/bpXjmMzsfIlco+VmCMA6QBn2ld99G+0TPWmlJaFvnN22t1CaystQfHSLScpeXBsjT5FGqkS3zCAHIci9UbyuaTOCQ/m7ERsbvcVzlS3AKBFekXGtV9ZM7si+DSDfRJSEL51r3DcSSo7y3Wret6FaH2DkMPKG2cpr9VU8xlS6gyl5L1VVX0zqx9GoN5kNsrvQEL879AZiMFM1CL6T8AFYGFkGtfOqaghLg/v5e3ibaX08zir/VNA+qkz0cUp/y1zAFBDQLROA== X-YMail-OSG: ekXoEogVM1kW6KSPWfzDMJfOJGoxb1R0mY9.ekBfZv2uR0EEkoDG5G8jP5Q2u7b MhqBtw5YvuY1oSnqFUd1xYjyOa2itfoCRA4WEv1pBoOuW_pMrqFVHEijIKEIFutOx5PIybwqRpMQ jYErv1pQXx66xjXGZrXZMXabcZeoZDxwtS2DMOU7S1ck0uQEMQKVhXat3mbCgF8VL.0qLsAnQLX0 BFmbvo9G1m0RLRfgbkgqGKOBCAxs.0oniiJdH1yLPunHfoDskUbFRHSaCbUWaqvea6f8Gt3A8mEn X3xIhcp9iZc94e_shMS0PRoo1mAlw3zN7aYGZ4ntfLmYpsSvtb7ibg5IeOhnhNZZHqB_Zg0JXvK9 G.ZjYcrOtQZHgtKscos7frCVmDfna8NgVKqOUPYT7ALmvnfjj3azKPBNAds67cq9K8NgEn8ETiz7 FdFyEPnTYGyg4Gt405Jpo2Gq_VCj0wpBM6bVVYeAhdMvUN8retvc.mhlcVeB8wHHIeEEmYZcRB1C oGBBOSb8VyO19Zu3fvTI1x18v.VcFTOcyOT7BlKgeBVLuzQdA0QdHLkJvcvybHg5KGCq6nCN7yCF hlMz1LhgOsKH2I7.nGoBZzzDkat1nwT7zbcWY.VsyX98fZXTw2TwFUN8kQMUHtMQYxM5N25kSWkd Z7BKbBSxWc8eAkzkPwdsJMfK9XCoW3tYXKbpUHRPd639NyE3pgM9shuTyJDCx4YLsWw.gNGdKJ1B JYjnTwsvIgksX5CrZYvds9of3R_Ug_BhX1mKHXJBqAQCGjlODEzlW4FQF5oqAgvFLlSpwaKNTS7A EkD7kgZLulnnD1akvKYqT.hK05aQGhx39d_0IXpLT7H_tDiyK8VzPzgKfuSeBCAMsQF01ARxVs5F Pdxh2RQiORx8ZKgnchY6X6IijcvnF6APRStUY6ZiMpK0yl2tkDvcjPlU4a_kTYqLTUgtAPL0hp92 TSs5EXjvm0hUzPCcaKkc9G5C_rQtMWFHqpWC.KVLzG.KCnZFg0sW1elYQvDfYiSeK.OURa9sTzYl .lnGD_zQkz9YIuK8cMboriRvqh97z0jHbXlGGZ0GLsosKQwAGpXNR6NGzkR9K1uQqBS4yZUXFFiC cfxI6YFVDoeAWyVVTTEcsF5Q5Fb9lawKKzjlmLvSavNhou84tZfiVhD8SANWkE_gW_pRTli0Ce7k hYbCmSLuxwQLE8pBTF11lfNQqEoYtbuDuVXSkM5R8OLKHQcdHgUOJC1Mt_kF.r9y0jEbm6mOfaRL 5pVmQ1gG_EKOA.Ip_rVcrdoBwU2uqh.YTtF4D7P73JVGgHKUCc4PYJGe630vcsh5ePNObkb9Grdj YcWy_CXO7Skua.BCgvWu_D_L6VKhH2eBPEEEZp3rvTNredcdsJNVE8osf2gV6qClRFBgTlLAag6O GbQzIMU0D2rMo9GFg9ddmapN5aZZnObwVV4Z31rEmL.AMHC6vcnfkyWJzYAKQIzJ8fJYSSq0R5Q2 wCJ9bKmUK9tvMy1FFBpJRtPrWyMNgxBlRjbDfxjMfiFlRFGLJi_vpHHuVXWIOZofZk_tC2dK6Y.8 4pUeaenID_snO9_coiXoF6J8Yli6o3BSY9t3hz.TiBvLhLYeTwRku.pvm1MeG6rwu4Y8Fe7nGVcu COTtFyQ_5OvEUM1dwhNawzmaghTZtQ9zF23X5CxMvIses3QLmXNSayIcu9b900k4Qc3xht.IoudD pRQ.hNDC78X3k1EZtL1ifKtxFOdPNVhRdIJ8m_CS.d5q6rFAmPkkg6.zcQZxbmOigyaHOcph_TlP lu60MfezXxYV2gogdlRAxE9kDwxGKYNF6fesbZ6Y3kJo53PonfFi5dOH0Lahbjy3pXz1RsPugB9t BH5ZIeP3OVMVHwXZcAOL_z0aXMPUj_MYNjW_kIpEqC83KddQhh6mUmR0uKQAGxiw7RD7ZdRVhKDS bb3DnyUDsqL07rwQI_yUQ1.yPpnL4gjQBgBae1wjikoTlsbIbpL8fD5Be861Ed6WJMar526NTabL nuGzjTHaRX7xPqIKOALmgSQHaLfgtuzsFS_VepvTtiNmocv.FdaJVwO_3Ex7ASgsjkPPeGbcmImY 5Z7DyZHd47ip3_WQjMHo02duKNmEmVSuZWKJ3GNAlTOs3QFWRQ3DcNFJR9MB1VwFIbHjL6nE4hwI sd50SivX.szG31eiCtakFFyAhYU2ArEZM7LSDQBjujLJeev3qSgDN8ofghsA2XQSTv9ITgvgDBcf dgCqrVEmuiLqGB5XizWtgxQa5..vcvhdAM5c2IPaTSSf50llv X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Wed, 29 Dec 2021 21:41:02 +0000 Received: by kubenode536.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 804b23d92fcd2ced4fe500e029800982; Wed, 29 Dec 2021 21:40:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 6b1c5775d1c2 - main - Move libc++ from /usr/lib to /lib In-Reply-To: <526C400E-C52D-4E59-9892-91DE002BE1D2@yahoo.com> Date: Wed, 29 Dec 2021 13:40:57 -0800 Cc: "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: 7bit Message-Id: <53644C74-366B-44EA-892D-54AA2FE94007@yahoo.com> References: <526C400E-C52D-4E59-9892-91DE002BE1D2@yahoo.com> To: Ed Maste , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JPPwj4VSVz3JMN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=L7p9fsI7; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via dev-commits-src-main X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N [Resending with dev-commits-src-main@FreeBSD.org CC'd.] On 2021-Dec-29, at 13:38, Mark Millard wrote: Building 33812d60b960 ( so after 6b1c5775d1c2 ) and installing and rebooting did not put in place a /lib/libc++.so.1 but delete-old-libs removed the /usr/lib/libc++.so.1 . (Luckily my environment has sufficient recent near-redundancy to recover easily by putting in place a /usr/lib/libc++.so.1 .) === Mark Millard marklmi at yahoo.com === Mark Millard marklmi at yahoo.com From nobody Thu Dec 30 07:39:52 2021 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 105D819194CB for ; Thu, 30 Dec 2021 07:39:56 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPgCb09T9z4Vl9; Thu, 30 Dec 2021 07:39:55 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-ed1-x535.google.com with SMTP id j6so94798785edw.12; Wed, 29 Dec 2021 23:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:reply-to:mime-version :content-transfer-encoding; bh=5QNDmEVtdqyvteI0W8QExIKFUFyOUDTp1U7ZELYfwKU=; b=lSfzQln93evxOmK5oYHvj1DrFlXg43MWDRTc9j5BmvFUWKe2Z79wambBYLw69YysFo qs8i/Uwr5iwTIgnwJ0lxWy7Sm3YSHVOYLdCTMcYQhqP8dt1pVuJSj5hGgh99NwWwt4WH SkJTId2oFYTMM7nbjJe1ZXPdM8r3mwBPJ80TKPfw+q7i3ONZ6S+ZkpV52PPv6A9RS22V /0/KGTREhpAxQid5gmt1S8otZ6IVKyjba8K3fSOVejt8RAePU2qv2D4CTnTu5SGIlMyy ehO7rxE3n43X3fxvVPTFAfQLOlelth7/S+ON0DwSXtZTeufvRmTooH/tJPBT9ZI4IbSk sG4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :mime-version:content-transfer-encoding; bh=5QNDmEVtdqyvteI0W8QExIKFUFyOUDTp1U7ZELYfwKU=; b=A6B1K3FOKaetHQI0g3QYODFC5mCuLv8OgV75m2oh93B/fbNEBErKB/9db2sppwDurW XgPANlaV5YJBL+xqw/+KppMDLnj7kSdj89nZ9GKb8/X4xmfvPhyPjz0CUM6DOLWxCupa moxA8dU7BLCoSxd/f1yM44PjOIKXrGXi0yMypj39znwihN/Cvka3HzCSFSUsM7Kn+HFp 0FhXiDdpUFQw41AG44/YWnhOzmZ7kTHMU/XSz5UqNG7CxaJqQLwUjN0dLCCF7jHfLa/2 lkzifq8vPQovcZ0A2QSZdmGTzf6N2cJaZzNOwAQuxGhPNlXwfzrZTW4/ZxtgM2smSXuQ sk6Q== X-Gm-Message-State: AOAM5328aiF08eGEQFuNdvgg6EGTdVgNP7lLOe8iX7TIt1sIepCXt1Ot XkAdp2T3NOyonL8eTEZ2lcHzzIA24PA= X-Google-Smtp-Source: ABdhPJygfytm3Oxq/jj8vNvEUwBrUryq73EZoLFtuoSg6taDUGxBXl3MvfFk041Hnyr/qAKZUYPjPQ== X-Received: by 2002:a17:907:2d24:: with SMTP id gs36mr23486408ejc.248.1640849994047; Wed, 29 Dec 2021 23:39:54 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id h10sm9266579edj.1.2021.12.29.23.39.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Dec 2021 23:39:53 -0800 (PST) Date: Thu, 30 Dec 2021 08:39:52 +0100 From: Gary Jennejohn To: current@freebsd.org Cc: melifaro@FreeBSD.org Subject: recent commit breaks buildkernel Message-ID: <20211230083952.46e3a4ae@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JPgCb09T9z4Vl9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=lSfzQln9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-2.01 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.99)[0.986]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N commit ff3a85d32411cdd7894f932b1d3d7ce01ec7a648 breaks buildkernel if options INET6 is not in the kernel config file. The breakage is in the new lltable_get function. It needs #ifdef INET6 around case AF_INET6. -- Gary Jennejohn From nobody Thu Dec 30 16:12:41 2021 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 8B26919257A2; Thu, 30 Dec 2021 16:12:49 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPtbP2Fssz4T8T; Thu, 30 Dec 2021 16:12:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 1731761A; Thu, 30 Dec 2021 16:12:49 +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 8B20FDCDE; Thu, 30 Dec 2021 17:12:47 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_0FE3D119-394B-4A28-BFF5-BCD1FE23F1DF"; 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 15.0 \(3693.40.0.1.81\)) Subject: Re: git: 6b1c5775d1c2 - main - Move libc++ from /usr/lib to /lib From: Dimitry Andric In-Reply-To: <53644C74-366B-44EA-892D-54AA2FE94007@yahoo.com> Date: Thu, 30 Dec 2021 17:12:41 +0100 Cc: Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" Message-Id: <38C289BA-66B3-4773-9A03-23A0A3407C82@FreeBSD.org> References: <526C400E-C52D-4E59-9892-91DE002BE1D2@yahoo.com> <53644C74-366B-44EA-892D-54AA2FE94007@yahoo.com> To: marklmi@yahoo.com X-Mailer: Apple Mail (2.3693.40.0.1.81) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640880769; 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=PSlEGtT1LkauzpLlcLUNsOXntsD5GsPM9Gge3DXvrRU=; b=FH/bZIdz8KdSPZ96EbWuQLQMW7iaJhF1qcZOQ4V0qMm8BWSdaE0yD1prpyfXqAYXZTV0hA mfbdzW+QcePuk4JgTss7rPIF0LUX6VPow1Q8Rm580QvPPG7hmWyLuwV14nbFUQKXKMJB0n a28/RBsT0DV09j3nz5RwoGUzRd2OrS5rwRuqiJaHGFl5ZiyqGD83HVgme76sKwvTZB/RPE W4PZkEdi2M9BkrObHXMaFxdacV0lYuFuUsz4iYchkQJy9dor7xmzttKMS24nTSmbqFzQPq FeZI9/B0B+jsuG+fOsVywXH9L3LOq17NhWaQxFhtwRgUo2P3U5DdzNxF3oRyFw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640880769; a=rsa-sha256; cv=none; b=DUu6zyRJndNkaZOaTDlSgHVP2WRbdTuS/C/+7ko4yfZUZy3RwD8QHjIkkp4YMV/gg5Sn3K x+6Si5wJG7UBXzXqY1mggEYcLX4+uFnb9ztZzPSgXSkal7kQ88Iw13YMMP3LIdutR3FZwf LkCkn+I46Enwam8s3jHcw+tcVb4UUnobqUPVY4Hd+OfXDi/uJrwL6s1fUV1LgAfc514XTP C6bUat23UVEBKLkSamLE3mOt6xkd3YQhBa1dZXO0+PdQVTyMh/tzzP1sjT7DsugrVX2xBg xeVc98799Otwf/wj0XwPrngGXvOnwqkDp/23UKdPKjV/GBYjBggUlgPc8s/7FQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_0FE3D119-394B-4A28-BFF5-BCD1FE23F1DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Dec 2021, at 22:40, Mark Millard via dev-commits-src-main = wrote: >=20 > [Resending with dev-commits-src-main@FreeBSD.org CC'd.] >=20 > On 2021-Dec-29, at 13:38, Mark Millard wrote: >=20 > Building 33812d60b960 ( so after 6b1c5775d1c2 ) and installing > and rebooting did not put in place a /lib/libc++.so.1 but > delete-old-libs removed the /usr/lib/libc++.so.1 . >=20 > (Luckily my environment has sufficient recent near-redundancy > to recover easily by putting in place a /usr/lib/libc++.so.1 .) This should now be be fixed with: = https://cgit.freebsd.org/src/commit/?id=3D5e6a2d6eb220d780c9128c81b58f1331= 14061415 -Dimitry --Apple-Mail=_0FE3D119-394B-4A28-BFF5-BCD1FE23F1DF 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYc3aeQAKCRCwXqMKLiCW o6jgAKCt7YDeL4lhEQ6Hf48OmkApB7RFkQCfVIR2J92YP1UmtSaiDoAxTM4kksk= =lNfk -----END PGP SIGNATURE----- --Apple-Mail=_0FE3D119-394B-4A28-BFF5-BCD1FE23F1DF-- From nobody Thu Dec 30 19:15:22 2021 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 A01C8191CDA8 for ; Thu, 30 Dec 2021 19:15:32 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPyfC4ryrz4slM for ; Thu, 30 Dec 2021 19:15:31 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:d92a:4fee:3c33:3b12]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id B6A29721E283A for ; Thu, 30 Dec 2021 20:15:22 +0100 (CET) From: tuexen@freebsd.org 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 15.0 \(3693.40.0.1.81\)) Subject: Problems compiling kernel Message-Id: <4E7F3351-4E73-4FB3-AC51-587C9E6EDB51@freebsd.org> Date: Thu, 30 Dec 2021 20:15:22 +0100 To: freebsd-current X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4JPyfC4ryrz4slM X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 193.175.24.27 is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org X-Spamd-Result: default: False [1.52 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[tuexen]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.70)[-0.696]; RCVD_IN_DNSWL_LOW(-0.10)[193.175.24.27:from]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.93)[0.926]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NO_DN(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.993]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Dear all, on a system updated yesterday I get tuexen@head:~/freebsd-src % git branch * main tuexen@head:~/freebsd-src % git pull Already up to date. tuexen@head:~/freebsd-src % uname -a FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 = main-n252035-63f7f3921bd: Thu Dec 30 11:33:16 CET 2021 = root@head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP = amd64 tuexen@head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=3DTCP ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc" make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 201: = warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 205: = Unable to determine compiler type for CC=3Dcc. Consider setting = COMPILER_TYPE. make: stopped in /usr/home/tuexen/freebsd-src tuexen@head:~/freebsd-src %=20 any idea what I did wrong and how to fix it? Thanks for any hints. Best regards Michael= From nobody Thu Dec 30 19:26:40 2021 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 9811519242C8 for ; Thu, 30 Dec 2021 19:26:57 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPyvN3Vdmz3G9H; Thu, 30 Dec 2021 19:26:56 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 06d0c4b4; Thu, 30 Dec 2021 19:26:46 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 33e1db75 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Thu, 30 Dec 2021 19:26:42 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-35F0A5B8-7802-4AEA-9051-BF2CE9625293 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 (1.0) Subject: Re: Problems compiling kernel From: Michael Gmelin In-Reply-To: <4E7F3351-4E73-4FB3-AC51-587C9E6EDB51@freebsd.org> Cc: freebsd-current Date: Thu, 30 Dec 2021 20:26:40 +0100 Message-Id: <22958DB3-C785-4360-A55C-9ED18598DA68@freebsd.org> References: <4E7F3351-4E73-4FB3-AC51-587C9E6EDB51@freebsd.org> To: tuexen@freebsd.org X-Mailer: iPhone Mail (19C56) X-Rspamd-Queue-Id: 4JPyvN3Vdmz3G9H X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail-35F0A5B8-7802-4AEA-9051-BF2CE9625293 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This should have been resolved today in https://cgit.freebsd.org/src/commit/= ?id=3D5e6a2d6eb220d780c9128c81b58f133114061415 -m > On 30. Dec 2021, at 20:17, tuexen@freebsd.org wrote: > =EF=BB=BFDear all, >=20 > on a system updated yesterday I get >=20 > tuexen@head:~/freebsd-src % git branch > * main > tuexen@head:~/freebsd-src % git pull > Already up to date. > tuexen@head:~/freebsd-src % uname -a > FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd= : Thu Dec 30 11:33:16 CET 2021 root@head:/usr/obj/usr/home/tuexen/freebs= d-src/amd64.amd64/sys/TCP amd64 > tuexen@head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=3DTCP > ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc" > make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 201: wa= rning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status > make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 205: Un= able to determine compiler type for CC=3Dcc. Consider setting COMPILER_TYPE= . >=20 > make: stopped in /usr/home/tuexen/freebsd-src > tuexen@head:~/freebsd-src %=20 >=20 > any idea what I did wrong and how to fix it? >=20 > Thanks for any hints. >=20 > Best regards > Michael --Apple-Mail-35F0A5B8-7802-4AEA-9051-BF2CE9625293 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

-m

On 30. Dec 2021, at 20:17, tuexen@freebs= d.org wrote:

=EF=BB=BFDear all,

on a system u= pdated yesterday I get

tuexen@head:~/freebs= d-src % git branch
* main
tuexen@head:~/free= bsd-src % git pull
Already up to date.
tuexe= n@head:~/freebsd-src % uname -a
FreeBSD head 14.0-CURRENT Fre= eBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd: Thu Dec 30 11:33:16 CET 2021 &= nbsp;   root@head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.= amd64/sys/TCP  amd64
tuexen@head:~/freebsd-src % sudo m= ake -j 4 kernel KERNCONF=3DTCP
ld-elf.so.1: Shared object "l= ibc++.so.1" not found, required by "cc"
make: "/usr/home/tue= xen/freebsd-src/share/mk/bsd.compiler.mk" line 201: warning: "cc -v 2>&am= p;1 | grep "gcc version"" returned non-zero status
make: "/u= sr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 205: Unable to det= ermine compiler type for CC=3Dcc.  Consider setting COMPILER_TYPE.

make: stopped in /usr/home/tuexen/freebsd-src
tuexen@head:~/freebsd-src %

any idea what I did wrong and how to fix it?

Thanks for any hints.

Best regards
Michael
= --Apple-Mail-35F0A5B8-7802-4AEA-9051-BF2CE9625293-- From nobody Thu Dec 30 19:33:09 2021 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 F22231925DAC for ; Thu, 30 Dec 2021 19:33:13 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPz2d36M1z3MPf; Thu, 30 Dec 2021 19:33:13 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:d92a:4fee:3c33:3b12]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 881A5721E283A; Thu, 30 Dec 2021 20:33:10 +0100 (CET) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: Problems compiling kernel From: tuexen@freebsd.org In-Reply-To: <22958DB3-C785-4360-A55C-9ED18598DA68@freebsd.org> Date: Thu, 30 Dec 2021 20:33:09 +0100 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <44278863-2C71-4FB2-B848-31E980ADBD82@freebsd.org> References: <4E7F3351-4E73-4FB3-AC51-587C9E6EDB51@freebsd.org> <22958DB3-C785-4360-A55C-9ED18598DA68@freebsd.org> To: Michael Gmelin X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4JPz2d36M1z3MPf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 30. Dec 2021, at 20:26, Michael Gmelin wrote: >=20 > This should have been resolved today in = https://cgit.freebsd.org/src/commit/?id=3D5e6a2d6eb220d780c9128c81b58f1331= 14061415 I do have that commit locally in the tree... But I can't build world or = kernel. Looking for libc++.so.1 I get tuexen@head:~/freebsd-src % ls -l /usr/lib/libc++* -r--r--r-- 1 root wheel 6939492 Dec 30 11:38 /usr/lib/libc++.a -r--r--r-- 1 root wheel 68 Jan 28 2021 /usr/lib/libc++.so -r--r--r-- 1 root wheel 35234 Dec 30 11:38 = /usr/lib/libc++experimental.a tuexen@head:~/freebsd-src % ls -l /lib/libc++* ls: No match. tuexen@head:~/freebsd-src %=20 How can I build a kernel? Best regards Michael >=20 > -m >=20 >> On 30. Dec 2021, at 20:17, tuexen@freebsd.org wrote: >>=20 >> =EF=BB=BFDear all, >>=20 >> on a system updated yesterday I get >>=20 >> tuexen@head:~/freebsd-src % git branch >> * main >> tuexen@head:~/freebsd-src % git pull >> Already up to date. >> tuexen@head:~/freebsd-src % uname -a >> FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 = main-n252035-63f7f3921bd: Thu Dec 30 11:33:16 CET 2021 = root@head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP = amd64 >> tuexen@head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=3DTCP >> ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc" >> make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line = 201: warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status >> make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line = 205: Unable to determine compiler type for CC=3Dcc. Consider setting = COMPILER_TYPE. >>=20 >> make: stopped in /usr/home/tuexen/freebsd-src >> tuexen@head:~/freebsd-src %=20 >>=20 >> any idea what I did wrong and how to fix it? >>=20 >> Thanks for any hints. >>=20 >> Best regards >> Michael From nobody Thu Dec 30 19:42:57 2021 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 4FAF31928324 for ; Thu, 30 Dec 2021 19:43:05 +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 4JPzG10FX2z3PNY; Thu, 30 Dec 2021 19:43:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1BUJgvQr070959 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 30 Dec 2021 21:43:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1BUJgvQr070959 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1BUJgvmk070958; Thu, 30 Dec 2021 21:42:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 30 Dec 2021 21:42:57 +0200 From: Konstantin Belousov To: tuexen@freebsd.org Cc: Michael Gmelin , freebsd-current Subject: Re: Problems compiling kernel Message-ID: References: <4E7F3351-4E73-4FB3-AC51-587C9E6EDB51@freebsd.org> <22958DB3-C785-4360-A55C-9ED18598DA68@freebsd.org> <44278863-2C71-4FB2-B848-31E980ADBD82@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: <44278863-2C71-4FB2-B848-31E980ADBD82@freebsd.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4JPzG10FX2z3PNY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Dec 30, 2021 at 08:33:09PM +0100, tuexen@freebsd.org wrote: > > On 30. Dec 2021, at 20:26, Michael Gmelin wrote: > > > > This should have been resolved today in https://cgit.freebsd.org/src/commit/?id=5e6a2d6eb220d780c9128c81b58f133114061415 > I do have that commit locally in the tree... But I can't build world or kernel. > > Looking for libc++.so.1 I get > > tuexen@head:~/freebsd-src % ls -l /usr/lib/libc++* > -r--r--r-- 1 root wheel 6939492 Dec 30 11:38 /usr/lib/libc++.a > -r--r--r-- 1 root wheel 68 Jan 28 2021 /usr/lib/libc++.so > -r--r--r-- 1 root wheel 35234 Dec 30 11:38 /usr/lib/libc++experimental.a > tuexen@head:~/freebsd-src % ls -l /lib/libc++* > ls: No match. > tuexen@head:~/freebsd-src % > > How can I build a kernel? Take libc++.so.1 somewhere, for instance from https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/base.txz archive, and put the library to /lib. From nobody Thu Dec 30 19:52:53 2021 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 591C11929E9E for ; Thu, 30 Dec 2021 19:53:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPzTW2HQhz3h1q for ; Thu, 30 Dec 2021 19:53:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640893976; bh=lPJfvqhZgDeiIuUIEBSKcfoZkEZFuJ0BWjNaYHLfKx8=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=gYJqR2MO+XYtzl47NvC/WTG+xdM5qP3/Bt5p2GtxbianhwGc3d1MaYE40wqrDPDQdJiV6Oi3rRxCM30e8qK0SqITu/kTX8XvcXZ+7hC/+mVYgNHU7L0Uw9ux8KyipwoV2yNUjt0B53TK/JZJO68+yUup0Q8MRdDLNydTIH9pi7LWlsWmRhbsO475gqpiqAvz36koiDplu8FnuAkaxqXuYdoLdW7KWF2mZplWkho7n00+fip+niHH3a0icaYhSn1depKswhlptOJ67f3mLNnhdSj407s/acZNBHBhQuje+rleO95A5kcRfzb7jgG2OHCH6ehIjdg2H9qiXRQGIh3McQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640893976; bh=UB1XA7ihbpUDxT+nDL7pBAwN2OT7ldR3syvlTI9RJP6=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=FyUoh6Ck/TDwrCPQxh1rOqM0jBF4urMPX78l6LSpsCjHNn72Ty3keljhTzOJ8UKDwf36fEWaDALzYjcm8H2ZwUxPb/QbTwZP/HPevYY+UXqzatPc+Rx9SK/khG4jfP+yEUbdcuYB5HFJAlD9xXYiN9vLqDIUYMybBuQ54FA6yfBshirRAExqR2KJAqQ/Yog8TeWLMNYXQt9qqLbinl4ne7zuuAQGCUoygdWo1TCBPNKc2l4/yl4Uah41jNSlP6/7jz44wCUSwgLGyHSXjNedVQFww3cKgY/nYy5HokyOyxkrIM+uDPzcQVgqZ28tre+YYOLmT5+MnGAH2Y+xemmYtA== X-YMail-OSG: tOpQqgoVM1n8yXzDLyExnglneuR4R51pNLa1oM0HN9JiUAYfMdhiKQ0FUrTnlsc pQB9FGjp2c9v5bUOU3wtKfnloXV5ygjQSjnrkdG2BbrdmPA5e.I6y0mmjGyALhy0G9iDCYgNHNSU q28a1_KMjaMRjiJFCSZK98ZsLL44BPqEkh.T_YEq80zWNWnxn7bccWup_0kj3p9s85odOo9W9hqH A9nLKNcWi42zs1IKVdTsSkTK6KCOjJK_Kl4Cc_0v5AgWiNO2bGC6I5is2CD3fcH9K_SgKi2O4aqF PVKPuqebQUMVH2WggqaUbcYu0EB1IFL7OxNGQPw4QBhCKHDJ27UHkLavDhH3AsNYi_UdQ1OnL2gs oxxBdZ2XLqI4_OVGAKB5HVGo3.CmMu9AfQCouzxS.sc4TEo5t1FMdOvrX9GtzQNGhIBpZLoQYzlD NzHNUQ_IkkSugd8S8F04pBqszWe3xs4Khgz8P3NGxwMifdNmmwjODnbvUkO41l7FcSrzw2Q751_O xxEN9joIL54vPAP0hy8iOdtjH5KtgGHVTX_CEUWUtUkmNY8gyGSmyGJGoudjfmq5Zwy8fRHplv3h 6_Hhg32svMpIxbARqG7PL0nFTtcd_lSeNEKuApB3ApYag_nRnm5n_KlnyVbbsEjKkIVI9g7IZ4pP Pw72agG9bXIe0BvhQwzJT4tfEApO7PLD67dyF5xQMjkkzxEQk8qtIM2SZNr1HlGKzlsQmJHn49G5 zpc9CTUhz0h442gbX.bzI8nv.MDUb.o9RepebuoSUg30m9HSgidkAm96rRu.YL5U4oaQjrzfgO58 JeKNJdmugOxDk0Hlg6_UE93IS._2wVrOPnqP7uFQXs2m09770wl65ufvKQxO7GaGjpOc1BZxp6J5 t8sXSnvAzNQO3W2Qvh7t60XvR.egmzQxxBiq1wNBzbirNtyDoYxaZ19viBPdpoylWBoFUaN3OYri sX.TqA1sd_hw3RACHgIFhhMbcYvNrwLQNsCUuGXCYvL1336Oz_91OwlQvw1b0P2VeFiFiN95T9OG MgYInWLHOZ8RIZhtnKPBWr0taaJqfZ26nLZw01gDdPbFU_84.6J._Q3NaVxCTap8jtkbCHpDnyh2 9SO4Frzj_Dht8VSF.YTBWPZbGuClOagd9kSSXNkyfMLg0njleZF8DbdL3TGXrL9jsw1W.0Mk3rgS AXDU.Sai04JVZ.4ysNTQ.R2D0u.MtR7Oj6CqYDwGQPPcTNTXI7UT3FFbDycHINZWDA3q0t8sZWF3 yZoUNLrjRmiJNbncEDP5NvAN4_TkL13j0wvEpzhhfJuAi.zjLn5KjzXQ6pMxRd8Uxmq6gMXB6Kdq g_lE1IRp4Lu2OUA9jIWB1MAdhoweQEaKqYGEsyz8.Cq6oLkie1zlgm8T3jkbq3ZG5M0wNocLQ7ev IrrAclO2Z88A.Ge3AedEQ4gdjmtiuGVTYjHbws6MeBzUM7vvuGcNxIcs4kIF1PEpJ7Dq4xkCs2yV e5FIVFu0yDAeM94KnuGo0brUTCP93GUC_WVmbgjpU0UJv_5IFKg2PHde9a1MhLogRkXkAQ7LoWlG o6oUfoJSzVHg7._oKVOUjo6IuTN2n5G_l46zWMqXfoyuV.FiPAjZ8scvv6C_6AM7DwDd2m4U2jZD p4M3Fi3piAcHIVhAsX91.x8EsmCeOOl6je_hbgpjtms0XVZUEIlx2e3fT1R7buf.xnBwhv1fVu4U r3ZtttMx1WTqJdwLNzogT4RSV7qIPJD96YVTBmFjIQYyaFc68SVhhzM8Osi.y6M0PCW_n9cDOxI0 0m3Tj5ZhRwHi3sMq2PXuu8Nb6BxTqdG5RhP4ukwDANKDLVTLyZqsv_E1cfRslV3vY.lGcK8Ti2ej u9YCa02GSZqjwtJNhn7u9Cjn3urPMNCWn9MTFBYOQ5wlvJYHheTNEBrjpXJ.LoohoIIngsl_gS8F .tSGnGI7WIvL1ADEpCceki6maXuY8pS34Wr0E9Q5onxQoXdGzzuq9XxCmoMA3R1y9.p4ZD5P5tZO fgGnvwa819Jx.zSNsDkTLrfqQto_fOWjgE7sqbJPQYzQtxHOisy8sQniB0Eh8PIKNA6HlQHGbavI uEmPFZtYxAm6Dga09q6BfDkr9N5GJjJVW62UUk5A1Uox8ge9SxrS8HPMhNUxmYAUdf3yJN_azDm_ 7EVGNDxhWwZxgq6tb9IajunpKk0laNUo5JLOVDQ0rjucV3.sG8END7QXM6GdJBWqasMoGqCzOxEN Q7THiE2w4MCYxziKF9HJ9iY0x9I7yblkDBzcI43Un X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Thu, 30 Dec 2021 19:52:56 +0000 Received: by kubenode534.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e719c63ca41880f52444e45f556d5f21; Thu, 30 Dec 2021 19:52:54 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib Message-Id: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> Date: Thu, 30 Dec 2021 11:52:53 -0800 To: Cy Schubert , Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E.ref@yahoo.com> X-Rspamd-Queue-Id: 4JPzTW2HQhz3h1q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gYJqR2MO; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.46 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.957]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N > This commit results in a different error. >=20 > ld: error: = /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2:=20 > cannot find /usr/lib/libc++.so.1 inside = /export/obj/opt/src/git-src/amd64.am > d64/tmp > >>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so ) > >>> ^ > c++: error: linker command failed with exit code 1 (use -v to see=20 > invocation) > *** [libclang_rt.asan-x86_64.so.full] Error code 1 >=20 > make[6]: stopped in /opt/src/git-src/lib/libclang_rt/asan_dynamic Working in a system that had the file removed and then manually put back after the upgrade, what I see after this new rebuild (not installed) is: # grep -r 'GROUP.*/lib.*/libc++.so' = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/ = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= /libc++.ld:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= tmp/usr/lib32/libc++.so:GROUP ( /usr/lib32/libc++.so.1 = /usr/lib32/libcxxrt.so ) = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= lib/libc++/libc++.ld:GROUP ( /usr/lib32/libc++.so.1 = /usr/lib32/libcxxrt.so ) grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/twa/opt_twa.h: No such file or = directory grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/in= clude/dev/ic/esp.h: No such file or directory = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so That has /lib/libc++.so.1 (outside lib32 materials). But it also has: /tmp/usr/lib/libc++.so and is that a problem? And, checking on when the files were modified: # ls -Tld `grep -rl 'GROUP.*/lib.*/libc++.so' = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/` grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/twa/opt_twa.h: No such file or = directory grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/in= clude/dev/ic/esp.h: No such file or directory -rw-r--r-- 1 root wheel 64 Dec 30 08:30:43 2021 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= /libc++.ld -rw-r--r-- 1 root wheel 72 Dec 30 08:22:11 2021 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= lib/libc++/libc++.ld -r--r--r-- 1 root wheel 72 Aug 19 03:09:03 2021 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= tmp/usr/lib32/libc++.so -r--r--r-- 1 root wheel 64 Dec 30 08:30:43 2021 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so So lib/libc++/libc++.ld and tmp/usr/lib/libc++.so both had been updated. I used META_MODE. So I do not get a full match to what is reported but the use of the tmp/usr/lib/libc++.so path does seem odd. I've not looked at what a system from before the first move of libc++.so.1 does. I may be able to check that in a while. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 30 20:27:15 2021 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 34124191194D for ; Thu, 30 Dec 2021 20:27:18 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQ0F20NZkz3pBg; Thu, 30 Dec 2021 20:27:18 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:d92a:4fee:3c33:3b12]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 9FAF2721E283A; Thu, 30 Dec 2021 21:27:15 +0100 (CET) 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 15.0 \(3693.40.0.1.81\)) Subject: Re: Problems compiling kernel From: tuexen@freebsd.org In-Reply-To: Date: Thu, 30 Dec 2021 21:27:15 +0100 Cc: Michael Gmelin , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <9A51E4FC-A9C3-418F-9675-7AA225E4F1CC@freebsd.org> References: <4E7F3351-4E73-4FB3-AC51-587C9E6EDB51@freebsd.org> <22958DB3-C785-4360-A55C-9ED18598DA68@freebsd.org> <44278863-2C71-4FB2-B848-31E980ADBD82@freebsd.org> To: Konstantin Belousov X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4JQ0F20NZkz3pBg X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 30. Dec 2021, at 20:42, Konstantin Belousov = wrote: >=20 > On Thu, Dec 30, 2021 at 08:33:09PM +0100, tuexen@freebsd.org wrote: >>> On 30. Dec 2021, at 20:26, Michael Gmelin = wrote: >>>=20 >>> This should have been resolved today in = https://cgit.freebsd.org/src/commit/?id=3D5e6a2d6eb220d780c9128c81b58f1331= 14061415 >> I do have that commit locally in the tree... But I can't build world = or kernel. >>=20 >> Looking for libc++.so.1 I get >>=20 >> tuexen@head:~/freebsd-src % ls -l /usr/lib/libc++* >> -r--r--r-- 1 root wheel 6939492 Dec 30 11:38 /usr/lib/libc++.a >> -r--r--r-- 1 root wheel 68 Jan 28 2021 /usr/lib/libc++.so >> -r--r--r-- 1 root wheel 35234 Dec 30 11:38 = /usr/lib/libc++experimental.a >> tuexen@head:~/freebsd-src % ls -l /lib/libc++* >> ls: No match. >> tuexen@head:~/freebsd-src %=20 >>=20 >> How can I build a kernel? >=20 > Take libc++.so.1 somewhere, for instance from > = https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/base.t= xz > archive, and put the library to /lib. Works perfectly! Thank you very mich for the quick help! Best regards Michael From nobody Thu Dec 30 20:47:18 2021 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 F410019158BE for ; Thu, 30 Dec 2021 20:47:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQ0hL07dpz3rSL for ; Thu, 30 Dec 2021 20:47:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640897242; bh=hYCjqD8sOR47QpbzcfF1uS8WGRqh7idK1xETwHA3rXQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=V+ScVWuuWw6HkCp7G+b7xMTwL5Jgb6vrMq/ZviHY8OMaTGPaFwI7J1MUporet39LNJCwipjDGqF5XdZSPItjkZwZpy8/UZq9bDDbRl/VIgQtGlj+v73GZKf3DXD2UaQ9STab1F+qaRPGn4ACA8lCU/U+DUqv3JAc6cApMBKkhUK5ujTyKzuidc1YEhV8w7Rkqt2PIsmRufeSLpLo9YhvyQq4oeDNBNU/jlrKRIRZt5GUA2fVE9oBygX5eMwAYmYRmk6jQk+SExVWPiitlRgcl6jPCDaE2lRm1qRk+dL0LVpg/Mj4X1CuEwPAzmVPhtYyRw8+nmfWr9z+907MoZ14og== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640897242; bh=jHj+UCu4OmCHhU9PsL6PWtZGA5AjUzGZdtOh4fw5s1d=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=oV3ZdvBTmsVfjl0Ebdumf4J8mDY5XFqxAVkKnc7btVMR+g6UayDa0fzCGP40QBxozD5GVLfKo2Am0CYgLQXuDSmMYr/q+f5oZSeGS/z4TfSL/KjqG+aRG3UrAofMlzSA/Cxl8Wyr6Dwf1SRnRN5XLgAi4HYfkfhsfJVJRBGtjs3vaeUKnI86eCN2V06XH9BDAKtzheCnef6nstedUvy0ASUOGdqoa8AyEHVbN0m/lhB6ojoqyMSBONH7EY+ELomRfKvpLV8alRXIxS5MYsIKhHG1RAXO5MvgD6SRSMu7Arm5jPI1j0QgPxRgkntW8I8BqxXoqe/wDHKZBKRoQyFfgQ== X-YMail-OSG: fCFnXQAVM1m_M6wVjV5Wqd1Mg8WkaB_RQe34YoeXhZHEtL0x85Id.Bjeqtn8jif bVMqENa7RpAQ3As0UqjjFq7k8RO0bYLvPhl7S2qAvw_lBiNiWwy8a.DcR4tQEYKqStphsgcgpCiz ftUaQ7wPRoRL3duMMzhLM5ow5WU07quUrHWo4hJP82Pb202xJWULSxJuuEWX7pk1x4ObfOU3DGkr AaTfTLzFy7g1QrBaudZF_VJhbWVChfBYsmzrxdnyZzN7snCcD76PbncXtWDGnqQiyZZTlhnPhBvZ kYOEPXK0Wm8G4yzKL1a5D8Bk3XmbVnHCnLEugP0Tfau_NwDShdd83.3NuEjZf4WMbKlkT4D13aaI eQj49mqJsFNpZvuqNwBWtatyoegzqG6LgqZZ8y2qFNacVXMEDSU8RijX_1KAyN6lR503TOlMHxqZ 5ja0u63u0TnexsKnFYMzX5W905bNbsBJ47WEoQ5rxfekmTtMRa1lKIn1arTI.72j8pHOqcuaC.qb LAEI0_H_r.Jh0bk3PvM7FhmzbLczRz1wV4Mv.Qrm.q22HNuyaAYcOnqpLIit1ZANGDpH2vsj8zJr 0Omq_9d0jwVlXZxacFWtDNHu5xziN.L8lIFlbDuu_xhMdaWG8whRYml4c7voVcVAxmOX9qT3hiua HDVE9Ufa2eHa_FXVPzlY47dOwKzIJpjPm5RRz5_x8xkCFDM1.J9h8yHNyNJCovYoXqAC7JlOpqVe PikdhQdHL_DPVEN0tx_fqRpgb0o16VlAhg1Kr15UmsJHadzRraZDolg6strw026kD84KF6UK.gCR Sk6xonB1m4Sdvxx9jyVjx42GUUrCcWmift8jfMLhZSdKw0EL_2veRmeJGYxMqFujijvQkOQOW21T LEkSV8YF..c8c.Q4rVMJSvRjyj2TeH8heP3vtRDd2qvPY7jrB5fwNCauiyQ9oASjKYHCTNcIIeKT 9MtZwnVTEr6Ma35OutBues45as9FE7ewx3.VUGZTdVcOoCrZT4sFfJJmx6LDtfnZVBxoPA2EP3bV ckFTS2BP9RUhBbqYo7BjTavGqlmkzCLIIBSIQvf1fqr87KssB6SxzRINLEC3Q8iZ4Tl73t5aufjQ KCbiowwU9OtE1Leuq3yuxBnbF1IHtqdLvUff8w6vi_.mfAIX1mhULnGGPq2EZEaPZtlxO1RlElyQ Oi4DbMDd6UnyWNRrlu0AzxT1AVhhS35Gf.ETQlGOz6Vc8bvrVqdvgtB8GIQnLFnWFLXMXVeYbwgz flcDz5QbVubP1Q0IArvN2LhNskVOVhFKJYKDG3aaT3bPXCljeCfk9eL9V09KE03zZchqH3TJsDLo e.BuYA458xntCI9Uyrvh2iuECkl5UkuPS8MCcmxkhwKjqAfIf9Ht4QK5nXbP7ZOYSjooJ0SzQ39h _CfADq6qmrgcAZ5zgb2g6QI7PZ22W59.VQhj3As5PyBweFIc6USgBGzkNlnwxkr4WoqSvrwCk8Km UUUc7Edo_wSuQmp8_JPRpG8uw_n9ija98M8PLzkSSjZHgtW_rLSM_vbEIjkVeT4VR2ZCNpG8iSyJ kEs61_9D8Y8cN8jGWqRTn7Oqc4K3GTY4Uf9kgf4tNXuGwv8p785WCRPlWYXijQvwsQ8KgNH5Fwo_ CPv3zuh.R5kihDZY2SSXqokxg2Io9FAtJB4IAypWKfoNxUpQFaIbajYZ3PGeMs7Zs.BU4Fdf8wIy cHWnYflVOI9D4rY9AX3Db72ypqcDFA6sOWJS3oZeAobEMZYvChycgpw.r_Vl1fXduGR_6NHqOIrK XcJQVJeF3Tiwd7L4jRF_H03VK5x_f0_JnEPoXbqoAsjV4cWsf4laaBi0fKKc2uqRIM3iFXERRliz d5yvpjHD9QXXcfVSySeh6yruNX9n1BxJhsSkMJm_U67SEdrKT3Nr8ytaOs9RGf90Qpn12kTRKKHc fUs9XgDRou2tR5gbs1MMwkq9hzP0Plvr9fCWZTxYeAprsCUPvIe57umEIB1c8Lqr0AK7bJ59wfdY jrsXKAPZHiS4BOYaEPz67FC14Obw9ZhKHGFkEYCEvlby3ElfvpgS7WlEKgKCnFpxUNKvA.7hvNy7 2ITnL9bMf9Z91hIZ6MFu64IQ_c92Q..2c2N1GH0.XiorjIszAqU5WlLHIn4rkTTVc8bMCfXoaHn9 RB5NHBNM2nFDwLmOwNMf9xl7u4Jz7pt1a1kBeza.iD9ei0ROhmmIzgSTl5CQAfUdshDtvK4p7TY4 WFjUqohKW1rYsLcmvA.2oMsc25t.fGLNMYt_K2QKCEqpkUDWZHKh_Ct_YuiUOjZgsQ6EajMQl6Y7 FlJhs7xmJT2eNdYZ47jEH1j3gfQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 30 Dec 2021 20:47:22 +0000 Received: by kubenode542.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fa0438ad4322e1c1e22f7ab465369634; Thu, 30 Dec 2021 20:47:19 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib Date: Thu, 30 Dec 2021 12:47:18 -0800 References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> To: Cy Schubert , Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" In-Reply-To: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> Message-Id: <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQ0hL07dpz3rSL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=V+ScVWuu; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [0.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-30, at 11:52, Mark Millard wrote: >> This commit results in a different error. >>=20 >> ld: error: = /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2:=20 >> cannot find /usr/lib/libc++.so.1 inside = /export/obj/opt/src/git-src/amd64.am >> d64/tmp >>>>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so ) >>>>> ^ >> c++: error: linker command failed with exit code 1 (use -v to see=20 >> invocation) >> *** [libclang_rt.asan-x86_64.so.full] Error code 1 >>=20 >> make[6]: stopped in /opt/src/git-src/lib/libclang_rt/asan_dynamic >=20 > Working in a system that had the file removed and then > manually put back after the upgrade, what I see after this > new rebuild (not installed) is: >=20 > # grep -r 'GROUP.*/lib.*/libc++.so' = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/ > = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= /libc++.ld:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) > = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= tmp/usr/lib32/libc++.so:GROUP ( /usr/lib32/libc++.so.1 = /usr/lib32/libcxxrt.so ) > = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= lib/libc++/libc++.ld:GROUP ( /usr/lib32/libc++.so.1 = /usr/lib32/libcxxrt.so ) > grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/twa/opt_twa.h: No such file or = directory > grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/in= clude/dev/ic/esp.h: No such file or directory > = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so >=20 > That has /lib/libc++.so.1 (outside lib32 materials). >=20 > But it also has: /tmp/usr/lib/libc++.so and is that a problem? >=20 > And, checking on when the files were modified: >=20 > # ls -Tld `grep -rl 'GROUP.*/lib.*/libc++.so' = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/` > grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/twa/opt_twa.h: No such file or = directory > grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/in= clude/dev/ic/esp.h: No such file or directory > -rw-r--r-- 1 root wheel 64 Dec 30 08:30:43 2021 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= /libc++.ld > -rw-r--r-- 1 root wheel 72 Dec 30 08:22:11 2021 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= lib/libc++/libc++.ld > -r--r--r-- 1 root wheel 72 Aug 19 03:09:03 2021 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= tmp/usr/lib32/libc++.so > -r--r--r-- 1 root wheel 64 Dec 30 08:30:43 2021 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so >=20 > So lib/libc++/libc++.ld and tmp/usr/lib/libc++.so both had been > updated. >=20 > I used META_MODE. >=20 > So I do not get a full match to what is reported but the use of > the tmp/usr/lib/libc++.so path does seem odd. >=20 > I've not looked at what a system from before the first move of > libc++.so.1 does. I may be able to check that in a while. So I've now looked at a build (not installed) that was done on: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #29 = main-n252010-254e4e5b77d7-dirty: Tue Dec 28 16:04:12 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400045 1400045 which is before the original attempt to move libc++.so.1 . It shows: # grep -r 'GROUP.*/lib.*/libc++.so' = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/ | more grep: = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr/i= nclude/dev/ic/esp.h: No such file or directory = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/lib/libc+= +/libc++.ld:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr/l= ib/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) Again the tmp/usr/lib/libc++.so path but the content has = /lib/libc++.so.1 . Again it was a META_MODE build. https://ci.freebsd.org and https://ci.freebsd.org show successful builds at this point. It looks like Cy may need to report more about the context for the reported build failure. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 30 21:05:14 2021 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 6152B1919A8C for ; Thu, 30 Dec 2021 21:05:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQ1531VbDz3vTg for ; Thu, 30 Dec 2021 21:05:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640898320; bh=fKDIhb9SH2xFVPcxH166tJd9UqwP6+GLtyO7OSaoR+Q=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=e5cqMWBd/N3wL3aJokksL7e93uASwxd986+94YKPFB2qtKpYfpWms9VSw2wEQJuMAJ3EsDTO15iPSfiPU1Cv37V9Da4OZz2FRfT51DnQMeZXwD55gj7cINpfNZyLM2wIxFeTIVLgyqB5HXIbL7eq1A1i2aF/msm3j8vSQkDSNCt+LDJ8ZmWyNmRmHxROihaT3j/c9nViM7ygQSdsQ8Ncir0lzu8KNMtKCsGT/Qu+ykX/uk4JWeCNQCNKYi83VDgl2ieS8Hz+W1HCGmpPd6e1CrPEgWn1uo8WPDGVorZD/lLHHoLvZAjnLV343YZO2CyPJY+PGqHHfs7um3HzopwdMQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640898320; bh=iZoeLnX9q6Uf7PCcOaV/ogwOr20zFcBEwbSOULW0nvR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=GoJQ5vB4oZKlknODDW5sjxXLm37KF4vA/xThvzZnv9BYeqgwTEDUDGM1bjiURpjnyikn/NKeS4c+SzaZldDWOsyNJamNPDtpaC0/7OQK9E3X9cpEZcs9OO1+6mC8H7vVF9p8JUnj8YBIX3qiJr36uLw15IH/2wKBvkLUL0V8vR8jnV0YEX+ZPYRmRVh5lQ+yteB6plw9AeaCZsafnvhRK0wRGsd3HkBqvsRyGb+dRxmI0GlUSGwsJQ/9vKV8F6XaN9lZHSx8pGM4K3kO6Y9lqmPIHGP1g72I/V4jvojpcT84O/t25iO/oGr3jtNicdX9GZAMVlhykLPmnOzD17qNqA== X-YMail-OSG: 9W2uJyoVM1nUW85Nf.o6NL5P80CgD9rPcxCIBLdKJDkohSJxQPzZcIz0wnMsEYP mekFPjbAh_M7TxN1qTTSOsqG21le.WDwab5CzdjzHYfjtMISR7MdzCyypECvS1WplZnxeA_.LG5p GZTmDxRyhyC3OPJCniYlbX8ah2CoY27e1ViynYxXWKaJoRzv2R0PlvUUnT5buZI.h5i_sgHRkjQ5 FxqV.LPlm7uVUdszovWQE1NhEvn.3EOPGtf0IJAW4_vGg_vqCJonOBDVK9iNizI9nAOt5tNjxaIT mdZOOLdWllurVNwdlSDHuhSoZWI0H7FRfWXRtR.SNuUQzf2UFZ5KMkJ6UVv_E0ZBaTmn4oOfHYJK daRyiJQq9r4DmMOI9V0vm8qWFmIGwBJWfseNu43kZZSPI.bg1hdBosFGehrm6b.j01YI7xIa2jrs tvQfb8cOO8Pb3ojuD0F2wBGqitSCa6Zr3RtD0CyosGhEnKvvxrEgW7utqzb7TX7QoL6R0xr.gUz6 y_AaOwroBP0QLEbc5kE.Rr3nTHazUjSSktQRjMkNfQEfi9Lu9BLPdBaCcxb.nMMSlHsvcNb2cJ3B _2SwDgjh2hdjiVNnThmHhav9MEgGWISzg630LbBrP6il0_rkESGzTEKl2tQDkaXOa5Tonhjqk0Jw 2LyiaCt3A5gxRbBqNmz_cdkm1O66MwasIwqy4IwOxTL5bxjGppfcZ_oOkGu7ATcYZCr02xE4nEI8 YqtEMpX86pPjvy9SoMntWNxcuyoKypWMe8nlaW0EzleaAOH.M65EKIgQsFukTJkXwaV0ff2w3oJ1 eexRAT0gsB9pzCjCsD9.0O_8IylBFJuc2FW9z8Xqv_UwBrm0f7HBFFjUu4Tcw_kou9XvEnwACRrt sL70OZQkoo._T_4_nCbiIHikK69jkSAH1K_yNo8upP9q9QbZxQqjsvz0QSh36IM8W3MCrJ0TFCGY H11i5IVokdt6.RCZei6d3fP_WCQnNPWs1rhipR9hPr_.6en_61nMH3ko4QlF_wlmj95JNjROmjlU jyzIHgCDJSZ_CKYZnpS65MaPCONaxnKZVKZK_Z78iAGq49_0Wn07LZr86i6dElJpIlcqwRmVDtuv OW8.HXGJ3K6Ye_vRp5WKBD4yJHrVGqxHLzc84D4qVa3gxjaGDyN8bZEbDChlNHdgXJiwQSK52d.M 9wGbkAnAzLZiaaRk59pni5FKr79EDqoUTLI4RC3b492pecet5mq2bQhhmlZLYFm_6OCjYZ5kInIH GkgUxdCNi_RACzS7JJnscL2yd_0x..fK57IQnuAzhUh.tU_CNVxU7NbrRJton6LH4bBejrylTyzq kV6M0t85OuYoMExj274hgcf.aosf3wXp12OSLlmyHARsELURPxAXkfVRgVQCI1YB2PjBtdE_TtGJ nkoPxKBK4u67J.SNTcH96so3Ls4r88cUf2sH3g3E0kT1OIXR_UtZN2IkSJT75ABAEtSZwfA2ZJit ALiaiGm0DaqAydYrJ5GNfC8_M2xfd4jHxOTNR3TJPFrGTrBGEvaDdLPon1DMkx7pzKYrGkN__WCk YJw6KZUGs6AaaSQKOijJ94dFXR8_o1HN.OXAHbFYth9UD7sUBDOhh_nHIcQlvPENU6PvC2_SyzNG jbkUs8s2Z4iqyXNRkFH8HvxX4AxsPpvkQ0cYgrind1.ydM.j.9XnPg4PjuiaMGPzwB8PrHihftqg ey8kMYjftOyzNglBluai1K1RxDum3SKRY6wudkSKcB335Ovp95KnMZ0esgiU6DwLv6YFEl1awvgR MZxWkA4lVDr0gPFbmZ70OCdOrsZKwG8cA4d0wwoKcdhSUGUamrjEMiVL3E5q8yCMyNpXMWZVsEKy 3NJM4EF9mfQzPBLmgMyFXQQBGt0IOOhO3x1EFBsD3zaI1bqlpPlDsucH1LfcgFPzQUnJbP5yIJnt OKEOjc6uAeVzq8127id9rTZYtZC2vOjp0ts0Jp1iY4GQZ59KtetVlPza.jvtxq38TocBNzrFIiin GqFKrFWo13wC.bV_k1tVbLwGO6.IssquGFHPkJ.9jtWWLIjmuFbvWhfYNLFbvxFaHDnqih8iz3w1 NpZg3JPNv.XBSGZWqU48gYCdagVTy3B.tmkrvekel9z709ZNvTeBIUfBelJHPIwEN2GrNHTnSO3h kYaMYwtBUHTsYnXaxS4dQRy3uUDK143.T5NoHexTe70ALrBYX_x2FMMrl2ZjORz.jss3c1iMVVoO JP_u76I5B14C1NB0W0dyFQ7K9tS6kUBgozeIludVH0TiZ X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 30 Dec 2021 21:05:20 +0000 Received: by kubenode524.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e0cb90a36c9baf788b7210c7cac37fb4; Thu, 30 Dec 2021 21:05:15 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] Date: Thu, 30 Dec 2021 13:05:14 -0800 References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> To: Dimitry Andric , Ed Maste , John Baldwin , freebsd-current , "dev-commits-src-main@freebsd.org" In-Reply-To: <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> Message-Id: <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQ1531VbDz3vTg X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=e5cqMWBd; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [2.35 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_SPAM_SHORT(0.85)[0.847]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N This asks a question in a different direction that my prior reports about my builds vs. Cy's reported build. Background: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so and: lrwxr-xr-x 1 root wheel 23 Dec 29 13:17:01 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 Why did libc++.so.1 not get a: /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ? Why is it that only libcxxrt.so.1 has such? Seems odd to me that the structure of things would be this different between libcxxrt.so.1 and libc++.so.1 . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 30 21:09:04 2021 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 B35C9191B91E for ; Thu, 30 Dec 2021 21:09:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQ19N5QQcz4R4r for ; Thu, 30 Dec 2021 21:09:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640898546; bh=HLHJvvpAKTU30EGOokc455gZURQOQazUFmeqz5JYDQ0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=rVctCYQldQCWJrMFFNL0uIWnzFxO7+q8nlxYtgnqblKJsgX7BaW8tc2vZTZdpDx4LTMMqfysY9jod4ElQTyDvUwCqAzuNqpGGWFrS/UwghTSXpspOyHeCsZm8KZSU4A8JvMdcPBlpP2jO+k3kXDG2njpAytL1R1Sh/zKtD4a3+VUoxV0hCE+BJJn4CXMJwnohizX3VoOENvPweFBInFixYsZByttV0RSutK3kFRtvb6ZoDuOBGAeT0PVcoa0UnzhyUxwux8qZpxjL9mdjuKODCdOtPqfl4JpImGBfJFttpDiNg/9UWpOcz71to0mzBpUiwzduIGs8E3nI3k18UY4GQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640898546; bh=KkhX5JPDrOUzWlSJ+Oz0MNO0avONfump8qptftxQ3JC=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kxQgnwW1R15IvA8ctXEzkzWuhmQvBvTNAPzuMb8Ka56Qwyu2z4WLXjCD8FnE+RE+O2kfmaBs/ZzFCrr4Gete/tuMNok9oAvD2uJnvvkDZCsNenJCtFBJ+sxNk5YgHqiz4rALMX9WzEmkJrkwVIole1DvckVKVFtXGJNnGSgspo7Y4NlyCCud6EKYDdLam5PMpR57vbg+o0wFWIBXGswzgWzuBxvU1LhVMrce2FVquhvdny5DF9YpZxBLmPJnFSR8e8q7EdroI1r6lwMutXyJkUcTXGoqDKSbD2XPdXo3e0UkO7ms/9BHPdCgsoFZmAizUGgewV+QxeFSHGntHH1OVw== X-YMail-OSG: y6yj8f4VM1kUeVwCnWUeZ.EkI4oQMXLmrkuyk7LclFZ6dwN5pG7w.ndPCHKRGcK g7idYR21QtRCIARaSSMNALS_M0Y6uO0GAJz76o4jC6P4HoBekZIZys0Ehu56rT3cq95ZtZNqZqC. GApEMiTGTrewfkmX0cwaxwXCmFVqDgAI3oqCXbh4tALjh9PC0fssYDtmay8EPvVARJpSd_ARh64R Dr2R6XTY7iiwL9XrgDN7vzuK4FIGP9Kh67WGTQDtboEOIjigqnA_is5yckknyTewYPf29TVF4TU_ 2N7krL9vlD8KXhG6GUBf1aZ_i1b_rdkb5fTM9TZGN2hQDTMNX7dnu9gdm7mJ8zyvpOM92seedt0I oxmOpt8pX2IWsQ831ng9SX7IoUKObSAeBuQZdYJE15Eyy3kl1_yISuOzDpIh1B47VLVJ1WzOIcwQ m1lRjWxLNyHiCWFFzb2Do4WT4D5djwoC8oUAR7LsH7xVT21jalC_ZmZetRBkp2AYuRtPoVF6MmJN oI8UidgbBh6E8S8QxXWsAfq5dIpGPLHD18otbvyBeN_gNSrhaw.omJD8hKqFzDqwuaBpjwkF_3Gi eLCw.gJIsRJw9VCJkKVQ13GrWAW37oDxEHMBEqUK6TN0yZu.Lf2Gh0_xWsyXw0.UwJga7DYINakn MsuVc1UTGoLE3PHAVZjh538jBgBD9uks_kA3ofnTrRhq_UQCisJjaG1fkEAXV_CwnL0yKTNEhMN4 GFJR5sB8WVdVbfM.L7XZlEd5A1zgpI6bCkXCMwWDk0H2XIVVnVihA7Wt1iNqCOf1272FaOV6JQ9D lVrZBm8.bjQUrvFgolF1zSblLqwPDOZTE8tX5gnNgFen3zHeuo7r6oHK7hSOK0SGhOWlQlik0r.U jabApOdAWTouluAJrsIokvD04aqNa8xJ6Vw0bZ2pftoKSWK5LlF2laxWsNukM2xQgiAFIeqlg1rT 2WfjdL0xzGj9FXM8SMVFffe8qauItgEpi0InSvR.uxrYGxDVY9Obx57Ls10NzNeORVDV_s5MOIaA ZCStlYU5PI5Elob3Z60uSN8hurcakIvDL_0XcvkJAvJ1vgOkeIdPt5uCA8PS44m2PsGhlcmFBS0b b0KBXiPYFg6Y965QjiT7jGAP4CGCdcY70iJ5hV1k6FDqj3SBN_0FyKHMqIa2uXJM7qONWmrRqUAA xdKo15gNEy2yw.0rZfl.OqwtL.ZGREo81DqqRQxGFLPEUS0eb5wvrZjxuWC5D5uTywajTBaM1wPe dJ0tmL_I08K7SZkO6OZvZ5rs63RL0UrADMaemv_tPHCacrZI5sWCZgXM0uR_j.MEmD4oGexCpv1C 1A8TcMmThwKFU152PvfM5n6xOBU5uKgGrcEHDZ64YqEQovjcc4s.SvX7MQO.YwaGvL1__CZYFRxt O.JeKxvAcx3z6KbIvphrLfH54B0WuGyswVPAHxrCNLrsqaWlamm2ukMFXmADW27df9GzTj6N4Lps Bf42qw3fIbEHzv5iwLykUvfjbhwS_bmoL6i9I9GPDOCbDUmArIM_vKxn1Nz7wj6WJdxgTeBGGrLS orWa5TGfhivETQfUmJPEZMdLmK..TUdO5h7rZgLFUSTYE8wh.3i3wWHUhZxdykR3rmkfZlp39Hga 5mZAgd5MuMFzLeH60PuTUzJl5OMMK301mXU4qwfdCqhUn0Pw5N61dfAssNoUoBxlPZGL5e4BDpNa d_cRv1rZdZIkDBfdX1q6UZFYkzwzJFIy3.Z8Z5v_zZB0Yhxs6fToGyZuvAJOXNGcqPIW0bAYlarE D8UQoHgN42Xvok9_SIlutxUVsR5jyKxhfylo68pIAs4SyrL6KliS0SXvPhIVoUEewM5QfLCAeiqV X_jl5CgndPsyZXOKrXmo4OOWagU3mwcKXAkBGzHGuaUD84dnpLQZQu2IqRStlsbn6YHQEIihvO2C O81Io8JLOlibYGUF4WCIVB5pGEcOO7x5zTTdD1D2dNqd9zkJAFC55aRBSrh3IU2xVGb4nLZ_XeAr 1A803KouWK9_vgZLqY_iQtUpOxKjQKxOmZxz0P_aTqV7grWdxvH8D3o4yOSt1yBp2uCaHJGFArH1 krNIszZjIsta90khA78_g1gG4EXa67Wl1QC6X3TJFRsB2CQnpySmv.o8Y61YJqAT5.hP1_Bsfcbz q8SDVqMXppTf_PHYXS0gcbNGZgmAX.WRFiQ4a6aAkGG_PgUPFIz0SjNUgQKPzfoIackr7aEApBMa l9c_ug.VRcrGV64Di4iJA8K9MAavQG_cZndFvYnYtEKVjw3zHPLWzQwxe8r_JVPAGE9ky13zO8py Qv_1aFdO9Ngct9aLFmz0C X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 30 Dec 2021 21:09:06 +0000 Received: by kubenode550.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 55644768a1a430e4485c86142af1b91e; Thu, 30 Dec 2021 21:09:05 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] Date: Thu, 30 Dec 2021 13:09:04 -0800 References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> To: Dimitry Andric , Ed Maste , John Baldwin , freebsd-current , "dev-commits-src-main@freebsd.org" In-Reply-To: <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQ19N5QQcz4R4r X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=rVctCYQl; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [2.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-30, at 13:05, Mark Millard wrote: > This asks a question in a different direction that my prior > reports about my builds vs. Cy's reported build. >=20 > Background: >=20 > = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so > and: > lrwxr-xr-x 1 root wheel 23 Dec 29 13:17:01 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >=20 > Why did libc++.so.1 not get a: >=20 > /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 I forgot to remove the .1 on the left hand side: /usr/lib/libc++.so -> ../../lib/libc++.so.1 > ? Why is it that only libcxxrt.so.1 has such? >=20 > Seems odd to me that the structure of things would > be this different between libcxxrt.so.1 and > libc++.so.1 . >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 30 21:27:20 2021 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 1D515191F0B3 for ; Thu, 30 Dec 2021 21:27:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQ1ZX3ScSz4Tc8 for ; Thu, 30 Dec 2021 21:27:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640899645; bh=rVzim6r2MhwXjb7siJMtKvifR0aCXm6+rf+9W0jS/lQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=O9VsgOUq41Z7y1p2n6fPSGVGzT1sQpiNuNNfauQSlCF1VROwvhoT4M+Ztk3p3cNjDfww61NftMR9jrdgOLDJy0oChDeYZd6Tq2pEzLYiSfFmk/AMcer9SMUP46t8xe+VIKqaYHnTmOc0yiJaoLnUXtHlBZfkZ/O64Ee2M5BgZdFSQvRXI88Iu4x0ONxVQ64FkP95w7JeyFXyM3Dske5pJMECVFnGf8XeAn4jYMD20vr6HW1s2MPzqLLDo2z28o/deqC10GS6p8PNVZLBBEgAWB8yx+G4WGgDhKaQez0xgIXUtkt/JPK7viF4ADBySGbGEFEVPvWYeyrLM6MUHGoeCQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640899645; bh=eYK3dwG5GQJwVyuk9KMWv3SrvzfcMoryw9HGoPzXSLa=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=iJY1uNW/f9Pa7CSCU1kYhg0hmPR7K4VqVsScTATNHg6QlcZlHPD6bFHNQyEEywQP8GwjNCKsymmR8e0u/4JAwXVTMWOEGBVs29vBXZEIjl3jQXW0PdbLrzxBAvkFFq8jRKIp/JLp2qfoaGb3jp5qN4aD5AMLKMJ5+EhPs4oy92sI7ghFXqIxhWK6YEnLt92BLba8bq6SVYPbjxFRsjjbyJ/8hXOptWbjnEyQfHqxBZB8bwoa2p4Zy7sFhPLkrZxpoTrILPbegw/RKBp4Gpzp1vVqtukdfjAiNLKb5MQDo35ZRD1Y6QWnmF/4njpSA7r+jcE+ZXxo+8sOY8IrkNbqFg== X-YMail-OSG: EYdK6hEVM1n.8zegDz9sAVvh0O3oPWEZlBabPzYND9TKUOJrQqnUcESqDDRkm7J O82.uBg8ubnGi2MIAufD5EjM2impfF35vfzaZ8Dk_TIWSYuOCOTNTtSjiu9YuNox6J6FN6bkVsRD ZAs9Eklwu4CK_SwXv8XwxfTFo7inM2Q.B0ET7SJWUBSzJUwUUj79cQnIw1xvfWKQ.aRtpIkKU_g1 eGk7GGFFXwV9p8KVTV_l4rSXmVT3ISicexnXfVo8vBowO4fUZ5Tk8FulsB5_jy8vghp5FINXKw2n 9DB7ofFRNeylZv7mT0xMg6RFp78SE2Dc0bnQPyNq85S18s2FFWDqSGbGVZnq2.wC9wQ3q9k5.onk 4DZNw8q3XAdyX2b2690yLl1JTmntiTm0avw2hgwW50dPMfSAdhmXbryvF16Hv8QiNv4u50RZuzPd JPAxBlMMMKgLrEKFndekN73lyDuXXwiHAjHmX02WOpv_NckYBAB6gcKWjlGiZEtDhm9Z91N_.zCX Giy4JHkibzHa3OmEFcDMn_Uzb7fwU.IhJ_.2JMSuZglGZriIwWa0qEunhBKcPvMpmneV7ypZF4Yk SxbIjH8qBeaP5SW7YANiE8q4rYYjHsII3619rbtCYpsPz.iOs0UEsxrqStJwplDY96G8._DCpprX bwE78.OyLDXwbtPT9.CT2bBQX7SGad_xmGY4BmoxDCEVs_6sRqwBfFM9KHJXljUcde6EJcAqHJ1k 7hcPb_fB1zBtJKAgmvHnHsLaHHIu3NS0.qDl70ifwpzaCWJ3JNfgHdJMiK77xsc85IQFOC9vFwA9 WsuYRy0.5Cmtnm6LH9OT9pXVJCk_Ey.hIEtmAUEhbifvUbG4QKLOC4CPv6ZZtiQoVU4J_kU81Sv3 z91WrI32ZF6Ck09LW.sqkNlH2msycY4q9XwMXr5qJ_B6k8VJ2XbO9GAt8SRaVzH2GrVAyVVf.bSO voUGBHfDZNYroAaE8kwgPP0j3wRhR02f5qPGWYCc7BCc_ML_R.waJRcqBLEdnb2dS9gpAys5n60I 3Q8OSz.fvsJGvdaO9.mxQaJtJZm1IUmGhfdt5i5pBpgzseQQ_MlotHijfL15JXuFLMxLqN1QDFZO kIrcVKwWUJVkVK5rqMbt7_8bwhpa7HMMZKHh27EZ8SnN3ZifdyyPfbQpbnUhdfmcBfcGhOgvTQdU KAbVZTXxuxCeRGkazyB045jIeM.jL9hppYYsARgMh4qyLQ0g0SNU8vKpfSwwkcsX90.MhSYaDq.X I22m3g9FSIIsmecGD91NbwPlDXcTda.yGx9PMF4lWz.jmvmplYevLM.DzjksV657PO1tMnDUHd4z fid0MEqbpFHglybdUdK4xpuuKNd_s6DZvQ0h7EdxpUOCmqtiT3mTDgy3w3nW7dkahOT.8qT4NLsp oUdM.h8u9jnPjg5Q_GyHjs633.kSZLB6PK7pMRt7MV592vxE7VpUNApEGu5w8yh_7lUgSMvIUQBW sLG7m7elqhMZwQhJOxxk4PUXlDfSNqWYjL8b6KeJQAg.PIspgSVfpPmqQ59IWB.OfGHH0FTdv7FK 4EKgF4LxPf4Ob1sul68MIfPQ61D4fcSGEg2lyywUDsJgf8p5SFJtBurDdu2IaTaT0TJn4_YSU2j1 wfoZfDkIcz4GcjCjZDaMI9VSfutYBj_T1OVxvH0lCb7OOOh6eO2tLlEUTALo4e3shbPvPrh.dBWY BG3vg1a6wAtLHmNw3l9XfNunrTvXyaVk3KWFvO9isnNSGWF1LPbpHWusYymvKV6bJBtvkbTsdpyh 3EdtYXnzYUYgTSs.IVfbUNbB51NMCf2iQodmlmISEFPTfzB7ArjhXZOZRrgUa2dxYvpT0lnvn4Mr mW0Z0VeqKtZb4647SGnBeVdVgAT8Qg9HPJwLR2JDeWM._TzlFQgsng6ImxkShdGzZo3Qz3EtbGLe efdabeartpchVdoCMCg0ZWQyfbq2F5a2c2UrGpSJ7wdvjA5BHz7W57uVWHBHr3q58W9zWnBTGHZT VwSzJWdYwlXKqGjwOkb7hJMRGO16JlQQzbMy8jpLC2uDrUU_vHIUH9pcam_yk07Glyr0LeA7cZ6n ZCFWSS2pMNJmdxepvPxgLcCTgJ98C8cD6qo.vudlShnLx.HnkngEkbRtYaBz48sUAKO0.JTsv4dh kVkf4zUcVRZ9D6_pPcsb0j6Rlo1zdtnGnPC7AeX1bSwjnpBbsAWlPld.hXEoOskOr72ikeWIil0G rRhOzSD6LYy.khf0xKhKMj4_vcaC7LwvxAA5ZbdL5YOcN2Q-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 30 Dec 2021 21:27:25 +0000 Received: by kubenode531.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b76945d06a94c04ec4c71f237542280c; Thu, 30 Dec 2021 21:27:22 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: Problems compiling kernel Message-Id: <3BE75D4A-2FEA-4958-BCAA-66E194043EF5@yahoo.com> Date: Thu, 30 Dec 2021 13:27:20 -0800 To: Michael Tuexen , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <3BE75D4A-2FEA-4958-BCAA-66E194043EF5.ref@yahoo.com> X-Rspamd-Queue-Id: 4JQ1ZX3ScSz4Tc8 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=O9VsgOUq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [0.49 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_LONG(0.99)[0.991]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N > Dear all, >=20 > on a system updated yesterday I get >=20 > tuexen_at_head:~/freebsd-src % git branch > * main > tuexen_at_head:~/freebsd-src % git pull > Already up to date. > tuexen_at_head:~/freebsd-src % uname -a > FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 = main-n252035-63f7f3921bd: Thu Dec 30 11:33:16 CET 2021 = root_at_head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP = amd64 > tuexen_at_head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=3DTCP > ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc" > make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line = 201: warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status > make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line = 205: Unable to determine compiler type for CC=3Dcc. Consider setting = COMPILER_TYPE. >=20 > make: stopped in /usr/home/tuexen/freebsd-src > tuexen_at_head:~/freebsd-src %=20 >=20 > any idea what I did wrong and how to fix it? The problem is in FreeeBSD itself from: git: 6b1c5775d1c2 - main - Move libc++ from /usr/lib to /lib Ed Maste (2021-Dec-29) until the revert: git: b6f7942cbcbd - main - Revert "Move libc++ from /usr/lib to /lib" Ed = Maste or, the fixed commit, if you want /lib/libc++.so.1 : git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib = Dimitry Andric (2021-Dec-30) 6b1c5775d1c2 did not actually cause /lib/libc++.so.1 to be installed but still put it at /usr/lib/libc++.so.1 . But its delete-old-libs did remove /usr/lib/libc++.so.1 . (I suffered this too.) A solution is to find libc++.so.1 in your build tree and to copy it to one of the two places (old or new). So, for example: .../amd64.amd64/lib/libc++/libc++.so.1 or, may be: .../amd64.amd64/tmp/lib/libc++.so.1 Some old trees used for chroot use or the like can also be a source for doing such a copy. (That is what I did.) There will likely be another commit making it nicer for NO_CLEAN style builds. 5e6a2d6eb220 is okay for META_MODE builds or complete rebuilds. I also wonder if they will create a: /usr/lib/libc++.so -> ../../lib/libc++.so.1 or not, analogous to the existing: /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 30 22:04:27 2021 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 2A99D192522F; Thu, 30 Dec 2021 22:04:30 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQ2P96v9Lz4YLm; Thu, 30 Dec 2021 22:04:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 409DC3A8F; Thu, 30 Dec 2021 22:04:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <5a24eb16-078f-15c5-dcd4-ecef33d15ac7@FreeBSD.org> Date: Thu, 30 Dec 2021 14:04:27 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] Content-Language: en-US To: Mark Millard , Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640901870; 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=S5TFK53b1uRLs5nXyNP2qRfp+3su2wcSWDxr0/jrEqw=; b=pt1tOHT/6xwvP4Lo3NOAM4shMh3wMxXPtCw1YctwV+ITZFOMfqcCcNBW8ApspP3mE7ZL2f kqDcQ2+ANe6Hxx9rpjMPpytLwzsCmM/4j2Bj3YEvt/q/rUyc4bBQP8+gXq7Ik37vMt/LHU A/z6AUkueS9lygjuEIEyH08Fi67bmj0lGPpyfG5Syo8U/XgLW8+6yJYaSOUe/5zcv3UoYS 9FG0cGItE3slwcLTg7NcEIVtTbFDK98MFIutHJrm8L3SOrQxscCzMcKScmG5fKMeXxMLzx Zw3YaANoPfT3auk/0jxGkg4Ypu4qv1+rEmRtxQ+w6rWheEn44g9XvWlncqXoHw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640901870; a=rsa-sha256; cv=none; b=E1Ke9p/LFWa8IoDMY3iUgtiXWEruR276v1dyYVcLrcmjl+CAEbC5KlCEKWFgdJJDcwPRiw QJFdndZnayuFXa/cSlNvvR0IMA4vOir14+tK3rrK9dQUdKd2OsTq/1FmNqid9VK8IKYmLS +0bLEEkC12y39UuSY2qp4JCCGJEyVFS24yNVQTSA2pw4oOZiqvbElFlNUpB+4/2copI0DX nXM+3bcubE6GXX8cNguCzlP+ebvRDaXl/dbhwSkNrVaabagUeUvy9KbqQciIGTE6IdbyIf tu+uUbvvITW8g+L1qMPmuzu/X/zQfhIGoopieRh1eUDAL5kMhFrxWpZVvKS7yw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/30/21 1:09 PM, Mark Millard wrote: > > > On 2021-Dec-30, at 13:05, Mark Millard wrote: > >> This asks a question in a different direction that my prior >> reports about my builds vs. Cy's reported build. >> >> Background: >> >> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so >> and: >> lrwxr-xr-x 1 root wheel 23 Dec 29 13:17:01 2021 /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >> >> Why did libc++.so.1 not get a: >> >> /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 > > I forgot to remove the .1 on the left hand side: > > /usr/lib/libc++.so -> ../../lib/libc++.so.1 Because for libc++.so we don't just symlink to the current version of the library (as we do for most other shared libraries) to tell the compiler what to link against for -lc++, instead we use a linker script that tells the compiler to link against both of those libraries when -lc++ is encountered. I have finally reproduced Cy's build error locally and am testing my fix. If it works I'll commit it. -- John Baldwin From nobody Thu Dec 30 23:14:25 2021 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 1639B1910FDF; Thu, 30 Dec 2021 23:14:30 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQ3xx6Mttz4hVj; Thu, 30 Dec 2021 23:14:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id 2xThnxcpOztEj34cvn3dWI; Thu, 30 Dec 2021 23:14:29 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id 34ctndFaK5liv34cunTNI9; Thu, 30 Dec 2021 23:14:29 +0000 X-Authority-Analysis: v=2.4 cv=IfaU5Ema c=1 sm=1 tr=0 ts=61ce3d55 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=IOMw9HtfNCkA:10 a=CjxXgO3LAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=uhm4iqFLJ7xKFP7NoHwA:9 a=CjuIK1q_8ugA:10 a=UivYFtiqaNAA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 17C228F4; Thu, 30 Dec 2021 15:14:26 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 1BUNEPt5016004; Thu, 30 Dec 2021 15:14:25 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202112302314.1BUNEPt5016004@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Mark Millard cc: Cy Schubert , Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib In-reply-to: <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> Comments: In-reply-to Mark Millard message dated "Thu, 30 Dec 2021 12:47:18 -0800." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Dec 2021 15:14:25 -0800 X-CMAE-Envelope: MS4xfP86YXa7CrtWXvy2GtiqXjXO0sPYCfMP2+jdwYeQ2qqRLEmLnuZ/bke21Fyg9/vGrsv59wuWb4Oc9OgdwsHlnwwMMMR47tUL4aEb5pqsszioR0X+v3g2 G0XVhyvUgC8r/aU17euClz0nZWNuxh48hdd+EfFm3RchvZBdlUAv+zmpsVrzqeazks1PNVRQqYDYBw+J59OGmu8OIWs0VgH6kAUMY54gmrfHbNYry13kUgSc Zdn+LSR2YJOHX/M3a8GM9BfgTPtjIPqlmv1iSO7TeQW5BrZ6/G9l/87Sr8jM4j9ocO1PF+/cuzlNH43rzn9QDUrGqyGsznYr1vYoRicQj5w= X-Rspamd-Queue-Id: 4JQ3xx6Mttz4hVj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N In message <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com>, Mark Millard write s: > On 2021-Dec-30, at 11:52, Mark Millard wrote: > > >> This commit results in a different error. > >> > >> ld: error: /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2 > : > >> cannot find /usr/lib/libc++.so.1 inside /export/obj/opt/src/git-src/amd64. > am > >> d64/tmp > >>>>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so ) > >>>>> ^ > >> c++: error: linker command failed with exit code 1 (use -v to see > >> invocation) > >> *** [libclang_rt.asan-x86_64.so.full] Error code 1 > >> > >> make[6]: stopped in /opt/src/git-src/lib/libclang_rt/asan_dynamic > > > > Working in a system that had the file removed and then > > manually put back after the upgrade, what I see after this > > new rebuild (not installed) is: > > > > # grep -r 'GROUP.*/lib.*/libc++.so' /usr/obj/BUILDs/main-amd64-nodbg-clang/ > usr/main-src/amd64.amd64/ > > /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++/ > libc++.ld:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) > > /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/t > mp/usr/lib32/libc++.so:GROUP ( /usr/lib32/libc++.so.1 /usr/lib32/libcxxrt.so > ) > > /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/l > ib/libc++/libc++.ld:GROUP ( /usr/lib32/libc++.so.1 /usr/lib32/libcxxrt.so ) > > grep: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/G > ENERIC-NODBG/modules/usr/main-src/sys/modules/twa/opt_twa.h: No such file or > directory > > grep: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/u > sr/include/dev/ic/esp.h: No such file or directory > > /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib > /libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so > > > > That has /lib/libc++.so.1 (outside lib32 materials). > > > > But it also has: /tmp/usr/lib/libc++.so and is that a problem? > > > > And, checking on when the files were modified: > > > > # ls -Tld `grep -rl 'GROUP.*/lib.*/libc++.so' /usr/obj/BUILDs/main-amd64-no > dbg-clang/usr/main-src/amd64.amd64/` > > grep: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/G > ENERIC-NODBG/modules/usr/main-src/sys/modules/twa/opt_twa.h: No such file or > directory > > grep: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/u > sr/include/dev/ic/esp.h: No such file or directory > > -rw-r--r-- 1 root wheel 64 Dec 30 08:30:43 2021 /usr/obj/BUILDs/main-amd > 64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++/libc++.ld > > -rw-r--r-- 1 root wheel 72 Dec 30 08:22:11 2021 /usr/obj/BUILDs/main-amd > 64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/lib/libc++/libc++.ld > > -r--r--r-- 1 root wheel 72 Aug 19 03:09:03 2021 /usr/obj/BUILDs/main-amd > 64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/tmp/usr/lib32/libc++.so > > -r--r--r-- 1 root wheel 64 Dec 30 08:30:43 2021 /usr/obj/BUILDs/main-amd > 64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so > > > > So lib/libc++/libc++.ld and tmp/usr/lib/libc++.so both had been > > updated. > > > > I used META_MODE. > > > > So I do not get a full match to what is reported but the use of > > the tmp/usr/lib/libc++.so path does seem odd. > > > > I've not looked at what a system from before the first move of > > libc++.so.1 does. I may be able to check that in a while. > > So I've now looked at a build (not installed) that was done on: > > # uname -apKU > FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #29 main-n252010-254e > 4e5b77d7-dirty: Tue Dec 28 16:04:12 PST 2021 root@CA72_16Gp_ZFS:/usr/obj/ > BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA7 > 2 arm64 aarch64 1400045 1400045 > > which is before the original attempt to move libc++.so.1 . It shows: > > # grep -r 'GROUP.*/lib.*/libc++.so' /usr/obj/BUILDs/main-CA72-nodbg-clang/usr > /main-src/arm64.aarch64/ | more > grep: /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/us > r/include/dev/ic/esp.h: No such file or directory > /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/lib/libc++/l > ibc++.ld:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) > /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr/lib/ > libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) > > Again the tmp/usr/lib/libc++.so path but the content has /lib/libc++.so.1 . > > Again it was a META_MODE build. > > https://ci.freebsd.org and https://ci.freebsd.org show > successful builds at this point. > > > It looks like Cy may need to report more about the context > for the reported build failure. It was a NO_CLEAN build. A CLEAN build resolved it. There were no mods to this, my prod tree, except for some upcoming ipfilter commits intended for the new year. One would think a META_MODE build would also fail if NO_CLEAN fails. Sorry for the late reply. There are other things here that needed some urgent attention. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From nobody Thu Dec 30 23:42:31 2021 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 5D08E19181C3 for ; Thu, 30 Dec 2021 23:43:18 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQ4bB21Yjz4ng2; Thu, 30 Dec 2021 23:43:18 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f46.google.com with SMTP id x6so31044167iol.13; Thu, 30 Dec 2021 15:43:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=waZdXfKcK4BWlYhrAtlICurAuQsAca6OXLx/UQGWKgQ=; b=0l1SgHKhzXkyKiXVL/t4XF0P3n33StbSyeNQavLVK4R1MSGigJQv7JzCV66+EJnA4V 2+mA7sUgdIFWX4YJmC69Y8FyUYaibWXseAjZv1Ig1KnSv6C7U8zfaXMZM9/NRByPsVZA iapSPxYLAFJr8WNwOG7w/S/wLxSb3fCTBbQ0F6jZM20h+5lDcKfOSwz5e2yiquJhwtnF MQunNEEKjlqXh1k7/3F0YGOuFkxMevXcTp15CV9EerDt/edHGmVEJ3/bkPVAHjVOMn8C 8wEp5YVHv3f2MBEFxk85Bn3NrR/ek3EqO2lmVRraAPk85Vks31PyZffiKBVedjNxLYpz tVYQ== X-Gm-Message-State: AOAM532Z2Trm/xO+boFpiURCjBAx+Dt+h89RwL4lDfRTvToXKWxBE9Dd 1NJiO45qUT4wu7uvwoOboCGNykLL9TjHLzLb7spzzCwL+MU= X-Google-Smtp-Source: ABdhPJwMRzGJtET0Rft1MxPTUKkGYvcG+6aQGw4+QJHmZ+1Dfxaqh0RONv/CXBfT0sWQZmgtsaw/HzPaUeWS8XRkkEc= X-Received: by 2002:a05:6602:1592:: with SMTP id e18mr15242661iow.142.1640907790879; Thu, 30 Dec 2021 15:43:10 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211230083952.46e3a4ae@ernst.home> In-Reply-To: <20211230083952.46e3a4ae@ernst.home> From: Ed Maste Date: Thu, 30 Dec 2021 18:42:31 -0500 Message-ID: Subject: Re: recent commit breaks buildkernel To: gljennjohn@gmail.com Cc: current , "Alexander V. Chernikov" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JQ4bB21Yjz4ng2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 30 Dec 2021 at 02:41, Gary Jennejohn wrote: > > commit ff3a85d32411cdd7894f932b1d3d7ce01ec7a648 breaks buildkernel > if options INET6 is not in the kernel config file. Thanks for the report, this should be fixed by 818952c638a7. A build without INET appears to be broken for other reasons at the moment; I'll try to take a look at that. From nobody Fri Dec 31 03:15:51 2021 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 72B6E1910A85 for ; Fri, 31 Dec 2021 03:16:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQ9Jg3nYsz3Pvt for ; Fri, 31 Dec 2021 03:16:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640920555; bh=zVkkqD2K6dI9F3j+Ky155tPM8eGL0zMxe5/iE5kXXmU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LHABI7mDIU6pjhCBfXfb4sLEBqnP8BmyRw56HtMk5gTlaeJd0mgR9DTYqoN9Tkg9B8meBi8Ffuuc7sivbqjDA6hwRvYvA/ooz3zjCFV+vvmb2fsPK0i63jvIzSH+aUxcLdCHinGEO863lphSjsQ2aZ7jrEmUBkwy75PUv0E5SlWivTj4pTjIgRxQemTGJFCxcRQVizhKeAXX1pRKb6vAlu8GJR/LZHTkT4foiTAdav5Mb9iFudXhdNeZ60UZqdbEoyTR2dOKbv+vlmDdVT0RmU6tsdfByYE4jPWE39RcNL9XJ3JXAaau+DIJ8Mkzdq78rIAPI2dPBp2ZGvQ72r73TA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640920555; bh=da+41ZXG4uY2Y8pvkYArEZCEDwWHxEtsNWVerwlGY6w=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kiPQ89Q4tOWJ2w6lr7Po95xIFdErXK+hFikohdQ3fx5wYUurTwvPi138xW+bzJhhEE+E2lIon/uEZMr2v7esapr09NMG+Ip0utLQrwScBEtJkVoiFiIBQr016IFeBuxNsFhfBW7Mbj6FgQnm5h4GBsYBvZw6kD3HmcR9wo967krpFHQjzSh6KKwDE7OIXOQPx3nxX4tsod3ikWJEEO8EGaxlL+tU58RakgToPSb4eCYjnVx15IeoejXjZi3Od7R13KPBLHtUk/o43RWxcU3GOmqTXWE+ALhy5JivM7TAshzChW9kggYLJoKWH9i3WJDNPHYkmfbCVLVY+p1qSDTSyQ== X-YMail-OSG: FMMq9dMVM1k.qIB72YgxR0n1S2wXMZgIge.CubB4dqfi3BZ5akA8D6L45CZlYJm moclCzh7qwPL4S122TEyl2i_KI4hWnod7a2XC9JWXJAvyVcjENTM_wlsU_fkP98o7Imrgy9INqzk Yw6QxSzNG.WvO0ZTRUxcpKIpyIK08zUUOBt5eC4RoD8hGz9Mc1CBR6F9PCPED1k9vllczLOxmMnb rdIAgUckklIjIJQtnkbFy0umHCumo7XbaKizltbKzwQcU0zxaq9Bg6OdRszZWhJaKRMptd9VkNB4 SteMPFVxts8aQYsH8I2beXSRoLBJCYyTcwQIYG3ShH4s_2cuebNMLk2nj.PObdpWBGQynGN.Fgfw nXPR2G0lAqGUbvYdhasITm71vnwgcnVWu6ggeWhOrfdhWGGtfcdnXr5v1ONyJiAs8aDYcU8feufT L67ZmBBsgQT1WwpGE7dyvJ_A5LKrCH8mrvsnn1dQ2j.vWVdyVobfWT24KY_AaO.iAxsNIGO06qrq a2EUi2U1S7Uy64T_uzRMPEXoXtLxayj8QBdZQdlwLNDTg4mvRenHa3ShXmrnT0VpL8rgS1NZ6Hvp pLa9YQf5TQBajqhFlWi9p6VEZuq2yVAzhBPBy7TPoH6gN2MbSPh_obxqddoz.NixoVhSVbx8fxxu gqgGqzajMlgsICaxxQg1WTJYKvTi8gUKnwyarkatl1Vm_E1ipI5uMNbFn7b_sn_I4ytxKkXLhwmu TiN9bSH7J37K.tAkhOAWpBcZZemac0nMf_TI7dR3y2fwPRU_IXRzUihaEIkeAbGSzBR.mS5i6c.U VJDAJ_IL6dpOa2Xdm.Tbo0rlkI_1_w4tTvVZA3rXmwzHUzP5L9gvXIPgmlXQqAKwaxDj7LIb26b9 DrfhDTqSdpxQMAvfLxF.XE4oJrc74xqlcZGKTJQkXmgwHL9QDlAVxpzIzotHhGyM_vQP0ayS9c.A 0moXgAI2WfQ5P2batpzdwTYgI3uJWo9CcQ6giw421uqn6goxZ9bypWMcB8FPZkrwDVkFyixsb8YO 5IbH2BUQPmSAfZsa_W0Oknhmywzul3QcAtGus0lAWQjE2pnBbIkIoyxZ1eFByFenMkNOS5ydMIO_ 92wx0IY.xs3gM.sbpiVk32ZCgfo6qICrt4jQDUTYu0BVdwUPee2cr8SnjUc.kGtiSgORkM_PNctk Nig1lvUUoHaGEeLycHInVLPOfg9sSy9duDGEvwm_cUNVuvQl2sLLi_pfaoa07p8YdIjyuYiaYnMJ MwPtfSKqfaNaITfvHLsso2eA1KNc0DlqFSJ4n3_kCuKV.JgreMfiId_ka2otLYDQXWtNAJUrVHvn p4w93cGlhpf_t4u2mXvOBnSwxeo4jiBb1lrergPmVwfSAJSvqrXDqv871drnUixttgOt7bxZm4ru izllfw1X8SrVcPw6nSjKZOtg9loePLw0dOrU22kw5lreSdIMR4To72JCEkkpf3wWu8kHEw90Z2yu 9GbY1f5U1muhJicIo.90Gf4nbVqDSoo3Qyo65Nq5i1bWV2Iv.iPw5IzD8VbnJdi9sziFkWsFcE_2 vxw3KIPo5trpiA2s9SV5d34zYxO189fQoAbcpIz7DMTPW1PqzLqad3RYGYjrJP2RmPJ.6G86DM5x xmT8xp4NSUdKxcmqxw_spc3Axritsfg6nPrspqO6mkKfgMKwuvCTlQUyHAaH80SXmhxNJjSz3rYh iDtvl0p21_b5gUIicE5BNfFDQx_wZ5XUL5100TjWYHL3yOpHFuxZSdg0ORLVNj2C7KGxA8drVklX J1gKoYW8GtThXoJ_hguol3fr4yalkgOfUJjtvZSHiCeqIXhn6rOQqlrmYkGY642JPRsJTLkmeaEJ OdtZoH8dEdjSrRYhaZ0ZxDe9_UybAA8040.507fvu5Nri0NPNZSfrqPZvtki6A0gHiHm_7rynBve fUwbonwHv7ykFGU5BKlji7tbPRFgKa30i1KnyNUa3D6mZhEpCLJh6TpUmCcgRBgP_0vqi.APyz5N WkEL3tRw6aLg3yVEgmfpO0OlBbzE2bvAdWgZhr62cHNbCa9UFSVA2LbTJXggg4LXAnq2LhbVCEWY uMmWZf94C86bcCPVtHK9GehfQLdbYg74psD1eelGdo_rl8e7ySsTjC0DEUxmOPenky08a9p4sWKq s726Oib6UeT.AIR9jpnRGjXj_UwpRh4paY2JUeU_KTzIxz8mJumT4lnfuDGqzNDlMyjQmb0nsCU8 _ljQM4GqSxCnuw0PyKdAs_ZiaWo0B9SuDuYyEoke_zuAQ0OfWTG0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 31 Dec 2021 03:15:55 +0000 Received: by kubenode523.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bf72c175662442cdcc48ec8ab995c3e5; Fri, 31 Dec 2021 03:15:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib In-Reply-To: <202112302314.1BUNEPt5016004@slippy.cwsent.com> Date: Thu, 30 Dec 2021 19:15:51 -0800 Cc: Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8F2CC835-812C-40F9-9097-B28AD8405737@yahoo.com> References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <202112302314.1BUNEPt5016004@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQ9Jg3nYsz3Pvt X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=LHABI7mD; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.988]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N > On 2021-Dec-30, at 15:14, Cy Schubert = wrote: >=20 > In message <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com>, Mark = Millard=20 > write > s: >> On 2021-Dec-30, at 11:52, Mark Millard wrote: >>=20 >>>> This commit results in a different error. >>>>=20 >>>> ld: error: = /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2 >> :=20 >>>> cannot find /usr/lib/libc++.so.1 inside = /export/obj/opt/src/git-src/amd64. >> am >>>> d64/tmp >>>>>>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so ) >>>>>>> ^ >>>> c++: error: linker command failed with exit code 1 (use -v to see=20= >>>> invocation) >>>> *** [libclang_rt.asan-x86_64.so.full] Error code 1 >>>>=20 >>>> make[6]: stopped in /opt/src/git-src/lib/libclang_rt/asan_dynamic >>>=20 >>> Working in a system that had the file removed and then >>> manually put back after the upgrade, what I see after this >>> new rebuild (not installed) is: >>>=20 >>> # grep -r 'GROUP.*/lib.*/libc++.so' = /usr/obj/BUILDs/main-amd64-nodbg-clang/ >> usr/main-src/amd64.amd64/ >>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= / >> libc++.ld:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) >>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= t >> mp/usr/lib32/libc++.so:GROUP ( /usr/lib32/libc++.so.1 = /usr/lib32/libcxxrt.so=20 >> ) >>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/= l >> ib/libc++/libc++.ld:GROUP ( /usr/lib32/libc++.so.1 = /usr/lib32/libcxxrt.so ) >>> grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/G >> ENERIC-NODBG/modules/usr/main-src/sys/modules/twa/opt_twa.h: No such = file or=20 >> directory >>> grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/u >> sr/include/dev/ic/esp.h: No such file or directory >>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b >> /libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so >>>=20 >>> That has /lib/libc++.so.1 (outside lib32 materials). >>>=20 >>> But it also has: /tmp/usr/lib/libc++.so and is that a problem? >>>=20 >>> And, checking on when the files were modified: >>>=20 >>> # ls -Tld `grep -rl 'GROUP.*/lib.*/libc++.so' = /usr/obj/BUILDs/main-amd64-no >> dbg-clang/usr/main-src/amd64.amd64/` >>> grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/G >> ENERIC-NODBG/modules/usr/main-src/sys/modules/twa/opt_twa.h: No such = file or=20 >> directory >>> grep: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/u >> sr/include/dev/ic/esp.h: No such file or directory >>> -rw-r--r-- 1 root wheel 64 Dec 30 08:30:43 2021 = /usr/obj/BUILDs/main-amd >> 64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++/libc++.ld >>> -rw-r--r-- 1 root wheel 72 Dec 30 08:22:11 2021 = /usr/obj/BUILDs/main-amd >> = 64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/lib/libc++/libc++.ld >>> -r--r--r-- 1 root wheel 72 Aug 19 03:09:03 2021 = /usr/obj/BUILDs/main-amd >> = 64-nodbg-clang/usr/main-src/amd64.amd64/obj-lib32/tmp/usr/lib32/libc++.so >>> -r--r--r-- 1 root wheel 64 Dec 30 08:30:43 2021 = /usr/obj/BUILDs/main-amd >> 64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so >>>=20 >>> So lib/libc++/libc++.ld and tmp/usr/lib/libc++.so both had been >>> updated. >>>=20 >>> I used META_MODE. >>>=20 >>> So I do not get a full match to what is reported but the use of >>> the tmp/usr/lib/libc++.so path does seem odd. >>>=20 >>> I've not looked at what a system from before the first move of >>> libc++.so.1 does. I may be able to check that in a while. >>=20 >> So I've now looked at a build (not installed) that was done on: >>=20 >> # uname -apKU >> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #29 = main-n252010-254e >> 4e5b77d7-dirty: Tue Dec 28 16:04:12 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/ >> = BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-= CA7 >> 2 arm64 aarch64 1400045 1400045 >>=20 >> which is before the original attempt to move libc++.so.1 . It shows: >>=20 >> # grep -r 'GROUP.*/lib.*/libc++.so' = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr >> /main-src/arm64.aarch64/ | more >> grep: = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/us >> r/include/dev/ic/esp.h: No such file or directory >> = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/lib/libc+= +/l >> ibc++.ld:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) >> = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr/l= ib/ >> libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) >>=20 >> Again the tmp/usr/lib/libc++.so path but the content has = /lib/libc++.so.1 . >>=20 >> Again it was a META_MODE build. >>=20 >> https://ci.freebsd.org and https://ci.freebsd.org show >> successful builds at this point. >>=20 >>=20 >> It looks like Cy may need to report more about the context >> for the reported build failure. >=20 > It was a NO_CLEAN build. A CLEAN build resolved it. >=20 > There were no mods to this, my prod tree, except for some upcoming = ipfilter=20 > commits intended for the new year. >=20 > One would think a META_MODE build would also fail if NO_CLEAN fails. In the following, the file path of the text was found in comes after the line(s) with the found text in that file: CMD @rm -f libc++.so.1 libc++.so = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= /libc++.so.1.full.meta CMD install -U -S -C -o root -g wheel -m 444 libc++.ld = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so R 74586 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= /_libinstall.meta I expect those suggest that META_MODE tracks the file's status and the status of related files enough --and so it leads to the update that NO_CLEAN did not do. Overall you basically reported that NO_CLEAN did not do the rm of libc++.so --so it apparently did not do some of the related lib/libc++/libc++.so.1.full.meta activity that involved that remove. Given the removal happened under META_MODE, it also lead to the install happening to re-create the file. Such is what I would expect (or hope) for META_MODE use. > Sorry for the late reply. There are other things here that needed some=20= > urgent attention. >=20 No problem. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 31 22:16:41 2021 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 EBACF192DE0C for ; Fri, 31 Dec 2021 22:16:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQfcs4Mlmz4hk6 for ; Fri, 31 Dec 2021 22:16:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640989003; bh=so7jiqVYFVY/0y6d3tOmXc6C7rnH1bLODbZhqw7OpAw=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=MhONTLVL1bLiyKRohecHXD8hTfkMoudhQwpSqrFSekxdsfMEVlzdgzXJuxY+a3SfX2DGYb5Jcisj+b2vTjzRQp4CNmhtlWohLk3DAdp4++5bZji0mS4ubleBGUlZl3wt73jhuaEDkEzdvgE96LlzsfWMlRZygeFzvQLyYb5ZfMHPLKO+0U4iiR4dHwK9jnLfDTiL1ZoQ2Fwkd59iqpua2rl/YBzQF96tZG/oZyQIiHRxRqEJh/zP1dGRW7aN+X+sjN+aZ/jT7SessVBVqLQEMnwnDnpxCq232j4iMs+wkYHQ8QhP7Mr6RSyp9kFKNqYK0KebjU6iEZdumvNu0IdidA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640989003; bh=bJBKxPLXh9UMPvqeER0ytFx2RTBWl0MugpyRJSNisTv=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Dj8oPbfD4Bm4kFh6BqFcuf5nDi84Ba4Nh1YCspZsfGD0j/frOpOMq/KVB+niGCggZAjy1w0KXiV8rBXKN1sfUKRZzwfIwBnPLe2TXGTLaP/2lMa0rOwktE8XElKWEHoNSP9lXoRWkG38jYtALrqCMJyMnCjcSbIFE/IMMdDu/n5b9LM4jLiz8+fbZyyZrTyQFrnOKpcBEBdOVtSUXsuvL1vm5+8NQKW8QRwzmJMgxOUUl/Bkw9+9AcY6AZ9IFeaChnGSXO0iG527+TBJEeXm2CxDQMHXDhZJFVuAjBad+gKooUFamhq2rekppODKgX0hmUNiAS1/1tp+vH4s00+ssg== X-YMail-OSG: HRmF0wYVM1l8lOHY3aqn58ss.Npn.qzt1G8KbCoazYBBhsT06S24s77riQWASPD EAZn74OyIcdeu2SNasuKzZ7PUykidxLd_FvU2pL.OeoEsmvDYPuE7ABDUHNfQaGGj.oMF0b7QPZd l5llgxWvO59L5n.Med73XDVCYvmJ6zEPhUPC5BGNbXr4iJD4mwtUZJx0_Qyr7APLI.4fIeLfhKCh s5AtePj3bdwWDQbLs2GIUSD5pot3IzCMYY0lTekMtN.KOKdya6gnYiWC.ejluQ3551496gVSGZvK vXLwcyrYabaxxg9.lCN3qHpErH3GeK.fyHkcQ4TPvGKozQ_ahh.9YLGFgT7gKt9mYiBATU1wlwJL R8X7QT7HPTiRBkwTkTH8Ie_5fT7SKVutThc4AFVy5WuBaUYfGk_35h82oL1DVvNbmpslQmrbyn4q TQw_zAxMIqhU1w2YICm3ToGet9IiKOixck.yLz9r4OhcmHXzKlcOcMDDmmGDopT4zwivrJ_uKzh5 DRQNuwtfwWWEbYhCvozIRjpkV3FazOwPoIMv5NMgNTfCimq_6BrwlT82ONOEviEeoKkgi5TcwgAQ UaAVjHEGxXbFMq999nc4IsxusTz1hnra7WN9HTlyxgAnPQ0jQoRPAA6hQNgoBFkA7TB9nvT1Dwox 4urIFZXMBZxNI7xCwgwrH477ZtbSjI6eRY0CpLh2YSDupJr7unmdg_uCaiq318xufNvapuiS3.Ms Awckv4D.XX8_aLDIcoTZ_nWs7v1plGIaUJsNRZGZdJCLZlAZXSUXdrvHkjCzJrjxnKOUAOh.xHUB ddbXwjW3wWg.dgTRgqlINUQhb7mGVl2m_OjK7bc8LRL9HoYiAtIOS1qvqCXVOY2bHmZ0eXNVmtrR uSXsatii2xVkuBMM6bc2MLUs0mxgF4ipWoXg1NFw.WtfUQqJf5nFP59BCHLaH.AqlXGPsf.EdrxA riIiWbmMEyenlGKFeEAvK9qiLIOT_bWLWVugpYa5jh8_M77ZkHbRVhH6fGnTKNPXRR3Zyqz235Rz g1hzHPsvvg08LaaetmqzDdbBauVI5a0exlf1cyIYXjeSu_QOn5pHAGIHqO6CdlrJgMbE7G6ZkM.K S7CPLUw.xjGhE_TgZ4kZcqlTEyThDt9_nKNRv5KnLOdhygXnI.n0s0QqVpRXnoNa4p.GSDjDEtGz qae8KjINC7keNA2xqBBSa3eRzrxuPanXJVM9MBwUk6PHc8Fpc_RJ5n8IVlX8E3uUDLMKC0hcQayq Kwbf4cFZJcSgmelCcvCyOtli2zN7iA5ur6jT1GyPHAkwj1aehv6qJOcv6iJC5P0p1aKzT4lQjcc5 ZHehgpa6bIEAX9F0xTVzVHItOxsyqFzTwIJnTz30ib3kAOtPyhtPVZX1u_0Q5Vt7A7DSs3pbekNu V93tfqIe8KH3P6YTQsgADrWwhMuwEqKzpB42KSB6csQmtJsyY_PQycONMRKUWlVxrd0Sa_6vJyMo DVDy77su.9P2QNEHbhvzJYilyTNttprFUNlqJYldBHDZtNoXOI9_dKXb7aO1r5AkH9feLrVBSDiC FbT7kMpE9TFDAo3u39zD3LA776oFiUNvYCSUtdiE0NeCNYK6JigkLJ02Aw5tqPSgUwuuR50fU205 mLHO_h0bAXC6d7NSiayd6Fpf_Zapaa9WRgDi1LBy6E0hx3CMTH_rLuIpbCQIpiy0tscMBVjjTARp jp7ofF4s.tgPIRTJPFZSFqxxw5TbcmTvuRUPPjl0x9Ls3xyHPxLJVmTUOX91JI5fVQVY1tkj5bgf s0sETESUw3t4uAP1YZFfUX_npe.1L71zQr4gniotYKr.KVsRyIb.4N99aAO9xAql4yQhujzJu3TO o6PE70RuqmSueugLyYzzxVWrAKl6wyjNe.wPz7ksLKUSvce80EOS5Fomk98gyec78hNLIziTmmCC oK0dOl3ApfS2FkcsZha7VWie6cCwIkGCcl8tS8WDGt5YLyeOB95zQ4FKr7DY9qBZ9EMRQwfyakLs J6YuqiwCmRvTQ.l9cIe23GZKPoMDPMEa6a8hy8RZnbL3D._tokvTx.s_0zMS_3yodRuIln3gEbbk BaZ4ykjSHLBtEO8uNOYra7rXyyahef4DfTPyTD2SHwO.yjkGnh3_AAtjvS1vIDEcRnE40XRTQNYX p_QOWJaxmC5W4k.kMJ3c3iBzIkZYsCLLtTE81nwrFIIRYrBy51pBoOcCV92aIdGN8bCDO1FnrP5h 84XzEBECr2z2q.0ZmGlZZCjKK3fi6i4cz1aedS8.styg- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 31 Dec 2021 22:16:43 +0000 Received: by kubenode542.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID add2de6d23ab295be599aacb1b771db6; Fri, 31 Dec 2021 22:16:42 +0000 (UTC) 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 14.0 \(3654.120.0.1.13\)) Subject: Re: Problems compiling kernel Date: Fri, 31 Dec 2021 14:16:41 -0800 References: <3BE75D4A-2FEA-4958-BCAA-66E194043EF5@yahoo.com> To: Michael Tuexen , freebsd-current In-Reply-To: <3BE75D4A-2FEA-4958-BCAA-66E194043EF5@yahoo.com> Message-Id: <3BCFA348-3869-4D69-AC8A-7DC9D3A530B4@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQfcs4Mlmz4hk6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=MhONTLVL; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-30, at 13:27, Mark Millard wrote: >> Dear all, >>=20 >> on a system updated yesterday I get >>=20 >> tuexen_at_head:~/freebsd-src % git branch >> * main >> tuexen_at_head:~/freebsd-src % git pull >> Already up to date. >> tuexen_at_head:~/freebsd-src % uname -a >> FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 = main-n252035-63f7f3921bd: Thu Dec 30 11:33:16 CET 2021 = root_at_head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP = amd64 >> tuexen_at_head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=3DTCP >> ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc" >> make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line = 201: warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status >> make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line = 205: Unable to determine compiler type for CC=3Dcc. Consider setting = COMPILER_TYPE. >>=20 >> make: stopped in /usr/home/tuexen/freebsd-src >> tuexen_at_head:~/freebsd-src %=20 >>=20 >> any idea what I did wrong and how to fix it? >=20 > The problem is in FreeeBSD itself from: >=20 > git: 6b1c5775d1c2 - main - Move libc++ from /usr/lib to /lib Ed Maste > (2021-Dec-29) >=20 > until the revert: >=20 > git: b6f7942cbcbd - main - Revert "Move libc++ from /usr/lib to /lib" = Ed Maste >=20 > or, the fixed commit, if you want /lib/libc++.so.1 : >=20 > git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib = Dimitry Andric > (2021-Dec-30) >=20 > 6b1c5775d1c2 did not actually cause /lib/libc++.so.1 to be installed > but still put it at /usr/lib/libc++.so.1 . But its delete-old-libs > did remove /usr/lib/libc++.so.1 . (I suffered this too.) >=20 > A solution is to find libc++.so.1 in your build tree and to > copy it to one of the two places (old or new). So, for example: Just correcting an error in what I wrote above. The "old or new" part of this was wrong: the system still had . . . # more /usr/lib/libc++.so /* $FreeBSD$ */ GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so ) So only "old" was the fully correct place to copy libc++.so.1 to, presuming that /usr/lib/libc++.so was left as above. > .../amd64.amd64/lib/libc++/libc++.so.1 >=20 > or, may be: >=20 > .../amd64.amd64/tmp/lib/libc++.so.1 >=20 > Some old trees used for chroot use or the like can also > be a source for doing such a copy. (That is what I did.) >=20 > There will likely be another commit making it nicer > for NO_CLEAN style builds. 5e6a2d6eb220 is okay for > META_MODE builds or complete rebuilds. >=20 > I also wonder if they will create a: >=20 > /usr/lib/libc++.so -> ../../lib/libc++.so.1 >=20 > or not, analogous to the existing: >=20 > /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 31 22:17:29 2021 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 D85F6192E0B7 for ; Fri, 31 Dec 2021 22:17:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQfdw6xgbz4hxH for ; Fri, 31 Dec 2021 22:17:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640989052; bh=N4czIij+4nO4YkiurfwxE36YTOBD+r7mh6s09tjSIu8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WxllSM6ktuQgic0zG1LKOgOem6OhtdpyvmFB6OR9YHgJWZOkhidRU+Mqc7RJhoSlSjHzCB4diHfivvxt0bg4lzhA+bEonw5/zNJZLLARxWGGWyilnAvJIMfUA/GEZa0Zok3fGRM3t8X/a8CcEaKECRb320afpoDg+OAEjsrLyk4kdUvxfpNntk3oGXIJsC4B4PnM+oiFgNdkQ2ftj4PRF7v1rOfVpqW05VkiIAoGj/+YwIHTCUx+ClLYIMUjo/6pU8x6H6BGYZh9dSmx0n2jgBdNaP1B9h1Or02Amvtmgy5WHkhiJlQdcYVFxbqi/+T2dLyJeN3u58YtAZejzTeNGQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640989052; bh=UfF8n+z6d+BFC1fWO9mi/cTzOldlQhpXI0C+peM6WrP=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mTDXlKkeWkJMuClaMbgaBWqdhbtg8g9q/MtN/BaCqpSYGkjL2qOMQsoA4KGg9i44KlpajSfDkZbPXm4SjPGMBQ3V9So5NFcAiQsJ+sWQHLrg7RejuYbAKS18FyQNi9ZpncCz8X/1x3lpNeQt32EFagbVZ7Ub4XIXeLf4f1efrnakT5e/WeenGO0m8IWSjocjpxlUAuTu+I0ktCEg2J8q1kTaz4drdIJEVdAz2xJ1y0iXfiORshJw095BCE04a6lSYvUKEWPsLAJRM2eKRYPCCghNjfM1hIbJfFu8RII0cf9mBYtRIxj3YzPVygu+IhqA3iLIT0dbqjBUfQ9iEpaCxQ== X-YMail-OSG: QGwhjIQVM1mk60tXRyZEsNADtXVr5xjI4PpPWk.bFQov5G6Cd77whErYEjPGdH3 85R3xNLD7wkCOsdtcIHhGsDKbZBXQSrzEVyCEJUjjOIXQwAKb7GVRkrSAK9rWg1.tfwSL58S8xEa lfHVQebHlM_gx0XNd532YMue9SW0vkDMorhICE85cvHOOrWMqSLVa9J0GaoOgyJfv1X6ehCSbw4x sFG4a8DuRm.b2ELikTezg8ozKt7ypqgMCf3jpQxcpdmv0xDH20dYV7qtnv3sDxzR9e63LeE5wEfF 0K7nqGiQ.Ga07AQUREI3B8.HG5W37d6rKKYw1yJkumd.yk_qjgZFYkooFWXzd9tG_7XzphyPf0Ez PcVelxy49fv5v9is7JmU6EvBh7mPgANvJ0Z2mIr_YQ2VoNZzqBUwxEGkJwfMeIeqTUubb7rsqNFv iDWuHajPZYHgaiCQTL0RvojFd4mF6ZXRCxJLUAN5P3lCHKmKSNY1Xf4plECs604T2fzbICQbqZvY m2NetZmKX2RWmQbr1phcGbM5xp6N6YGVjH_8RxgRkZ_GGy8b73mC9t0G5w3otQAkG1OBgL1jA3Xj JyjM39oP3x3h0DZHSkUiPT6PDI9tDJU.ozqbQqgAofeqNgGekecxJe5_MYh9NkQHQLlZbwQkzPHJ vjYw6chYYihvzNo0ItjSvqlckVdVAX65t0b9R_iBKd5jTbQqGakgwC_W9uQ.ZNCCsATt1cgYew3m YPIhGveQ9p94CTXSYIzpL0jnRlw4k.LsCoHtAeMF58b.LbkU1SXubDRw9WRYRwOUg764rrFZsToJ 8vntMkEWfxzMtPmmA7mrCuYlezzi5EtZKpTJDHvmmZ1D6jcM8e9atXRw0mppKTroJ9esH1mYex6E XJQvdOi1hon1D_Km_bMsludjVA4pkNDBiJ2FybQIfXuG83p6doLfMpTEwH6O8NJDA2QQllIexBPr eDKJqop8jwGu9u4FCbZo.wAMzd2aQgj9bCgqx0yihjaSEtwtBh2hPthyPrdZ6muwGpTXieNeClr6 XTDQj7oU5J7EFtq8N4EDSQgfHY7JGpEJay9Lm2QcDLyhrZjUGJETU1qb9zYl8MbgYsz52aZ95xLX KmlwJPbh1DxDjTGdqX0piI3n2.BoQZd2d3ApUOz_gYFAZrYrDajuCFUiZs0XQYpoWqByUC3nNELO EDlxFGyViTJKyRkWk4Tr3983hVsgNvKvqBHNyCWy1YuW1tgwcsgw_MtAgubATSoDAz76HbMBNJW9 GvLinTbvWIIFJpVIxerQEJuXSAP5E1k3kf67E40xLYNSi2neHHkPcY1ZQchZZmNHPk3bHbCGUWd0 _Rjyn3lDZrw1PCZIMEjnD8UJ4o_GhZFT6npWdoN6xMjj2vQ2uhV6m6i8iU8DxFc47Z6ovTv0zqhv 74yFQKZH6cMzw1Wh4TF8lwK08aKVWlOqsln_9oLhhU7WNAkHz9ovdikTVlsY4UcKS5_RN5i1v4Fu nXRXiB3qT6VVUOav3WdiAbHafV1okF9d9klSNLy0e4sMFKGiXKMb2F6lSlADa4x3.vE4275qmkk. UPeQxpi00__l8ULQ77lnch4Wn3nK_.W2QBDyElt_kZwNvINdykDuDzGocuSmwDSu9orACk71AI8v 6gubF4U_u0t8w1ao71wMOVzrKBdNgIpfxvY8Y0oBl1WIo9fzN7vzbt19OC17Yj0QaBGhGx0UnrTE zTTjUrlqy4.3G3eS6LzNV8BbJEnvtfiFdJX.rhdPkILuccAJKkxcPhjbZZ6.QxQyqVpcfCFWtDVz 6rsX.SugsYj9d6XGOYdW0ez4uoWpw.6MjPMMcEph92nU98FwA8YJexbV2_7k.l_Zf4P.HUZpMCwP n5cd6pUr9Xsw8qWL2YAoBgAU.gEKsQ1BYENL6uL8rf5bE5ujVsNscIPncFuzFJXmCKsYt4uNbZkr 0_gnH1glWWafJoPGjSfk4.vaDMnZQMZD2PUR5AFFdoeRfwP.EvBQEqxjgZUPdxOe3OF8t18SFrGb eMsXgXD95Ut7QGteIW9n3aJeMQhir0GUDGLgzTMAwsuRzOPcCd8SeDq0tqNVKUVp09st8U.I4XJJ NwvQ9iLMIxvolFTBzGamro3SQ7LrnHA9gQUDbSBCgA9K7qf2yU6nBDI8lAN5QXjbyJUytVcYjyrE Eumwmq8AjJEAvKM3bbKH5qoxMQwTzO7Vb4JBhJf5W3wgVI2.0Mer74plGrIPpr8X0TmLHgBhhaPl lQf3FTtHtmk_fzsMCUTMaUF_Cegoq4VWpTFhw7cz_rg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 31 Dec 2021 22:17:32 +0000 Received: by kubenode523.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c60567ea1683007b0c0c708fff8d3911; Fri, 31 Dec 2021 22:17:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib In-Reply-To: <8F2CC835-812C-40F9-9097-B28AD8405737@yahoo.com> Date: Fri, 31 Dec 2021 14:17:29 -0800 Cc: Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <202112302314.1BUNEPt5016004@slippy.cwsent.com> <8F2CC835-812C-40F9-9097-B28AD8405737@yahoo.com> To: Cy Schubert X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQfdw6xgbz4hxH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WxllSM6k; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-30, at 19:15, Mark Millard wrote: >=20 >> On 2021-Dec-30, at 15:14, Cy Schubert = wrote: >>=20 >> In message <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com>, Mark = Millard=20 >> write >> s: >>> On 2021-Dec-30, at 11:52, Mark Millard wrote: >> . . . >> It was a NO_CLEAN build. A CLEAN build resolved it. >>=20 >> There were no mods to this, my prod tree, except for some upcoming = ipfilter=20 >> commits intended for the new year. >>=20 >> One would think a META_MODE build would also fail if NO_CLEAN fails. >=20 > In the following, the file path of the text was found in comes after > the line(s) with the found text in that file: >=20 > CMD @rm -f libc++.so.1 libc++.so > = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= /libc++.so.1.full.meta >=20 > CMD install -U -S -C -o root -g wheel -m 444 libc++.ld = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so > R 74586 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so > = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/lib/libc++= /_libinstall.meta >=20 > I expect those suggest that META_MODE tracks the file's status and > the status of related files enough --and so it leads to the update > that NO_CLEAN did not do. >=20 > Overall you basically reported that NO_CLEAN did not do the rm > of libc++.so --so it apparently did not do some of the related > lib/libc++/libc++.so.1.full.meta activity that involved that > remove. >=20 > Given the removal happened under META_MODE, it also lead to the > install happening to re-create the file. >=20 > Such is what I would expect (or hope) for META_MODE use. >=20 Dumb mistake on my part above: I paid only attention to the build, and not to what was installed (or left in place) by installworld . Despite the buildworld activity indicated above, installworld had left in place: # more /usr/lib/libc++.so /* $FreeBSD$ */ GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so ) (with a modification date back on 2021-Aug-18). (I'm dealing with updating to more recent commits now. So hopefully an update will happen this time.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 31 22:28:32 2021 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 9238E1930E11 for ; Fri, 31 Dec 2021 22:28:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQftg3MdRz4lSq for ; Fri, 31 Dec 2021 22:28:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640989716; bh=25HIIEvaYw4hX+Q7qXR0mp3jSsNE4TAaaPgCK2hzwP4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=k6sXILTxvETkV7PAUaUPzJCYAG+tzgTywtrQuckK/085FkswU1W8wASCcsnCjgtcAU0sqTV94l90mZXsupZ5z7jMHzsEeuhEdhiUeYzIgq9XG9WU/zmx+re9y01gxUuUAYnAhls73B+5JfNC34smUDf0JGYTiDq6MqHQNKUlJOdPJZjgpLsN2M/FkvOXxsLStDb9FTsoo4VUZUohj1mNgawb2nT7pALTL2VfRJvBYwpN8As0QjtNz+l/O4MBwQbyQKfyq6bscqf5DaGN2lq2NRZVbFck2B+1ozvqSEQUHrmrONQ5VANEivF8Kw3/G9wP8nNjM4h9xs2bqwq8fofYKA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640989716; bh=hjbMA53Wo8FKVwPTX0cGKMwsnde3wOY+jzEoLz9FZlO=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rWEBcR9y2G+qaGY2NbPjgZ2vUFwePMbe20fNhHrNdoCjjkc7KoG0f2US5UMcks18JbNFRdsgrpEbrfqVJyaDQTbW7Gtia79UZgM/qYffNsXTRpUxKiWphoG4zkutwAmw8BdUHowx6I3sFSP69+I9H89U0U/c9lDFOZBxmZbehLqWoLgHPLkOl+fYxPK/SXzA07fxDezr2DWT5Tb2sLaK6mBc/sc0UBfxwsSa6ZCvJVFMjYUYnPycMJY7OsuplmTFMh+w9D8JhDPbi4Hgep0x4YCZNz3RgDPolHxVA69Fw/YM498n6WSzSXELhmulZFV1g8iZSvg+Y7Ahch2s7ZpLYQ== X-YMail-OSG: vYAafH4VM1lkQ7EBZrUJ2b7_zJoUw85IAfYtxyV47qBezyj.5hm221cQePKiBlL YOj2QEdk4cIvQQGpSF5MUD62kIwN8VgmR211OoqXA_9.Tg4Zatz4cI3CwmOCzOHlciHkoPRedVsx O.F2xLPGwUZh7JFqx04JgAz4WHfd1rNbhSzBt3ce7f_e7RxozC9LEc.g9f2Fu6OXfkaAIynaBeTl NDSpHWd7xD0m8.XCWhDjwH6TXslpJSD7JTKdHsw4Vkcxvd2tV1PhSHkt9QUN_8mEgSOqQQ.VmCWk PTa_.e.w1zexA0odgTh2So7rpzOT7dcUrtQNsVOBMwXFOX1WKAUwPYPteb7UvhTLdAhYHnMkvc68 qUQjgphIpMeKmyBY6d.AIepxlfTnSA5p4cPCWO.skTWvC9Rf0r79.ZQ35hNsnfpFAjNF5UWMWN5y fh4dCH6YCHiUGrYbVys6yZYvnhRvVjzq6VV_nOYd9u7vMMsLNLLl9.IZwNLi3frTiMH0AxLosRK. J.2i8hU_maPVeMGnAsU5zCTYyMM449U4pMVaUtLlVm8.mrGtpP530Wo9fm6db9ZcfurgKQOvfyCq EAXF5WvxGCW4O9G3q6yx8ZHKfCmCIci5_U9XukIRYXnFMBAxtQr9P1VSv53vQoURYwKvhfRehONo cgExnzGei4bA6v9Qkl3c0X9YVXDKLlWDTfCEp_qUrB3EQFMvmUuK97mzzZFnlwY31cqFBoTbPAiY 5DJbRKOkuWwzhh722Py12iNX1Dg1F2J4zrqcGi1cEANoJ9qiheeEQK5HKzN8YYNavftr9JW77bgv otgzNrFoZsI8jrodSpqcQ1MhyW9mdQSepdLBO4d1ZqrunFtaz8mTSMIVf0Lb6763JbpUk1.N7RLq Hpk0S5_pu_BzDwbTGAZP9.ieQvCj2HPKxvD4vjj.JaUEmcLSuxQHAqq4icDcdite3_WfksqOW2gY jufmkDRhlCT08dwIiXc_tNwCUDNtD1JPmnLtV0CtAO9gbneONAD0fwl.P_wO962NIiSOKJQjEAh6 AT4hB067M3AG6pcF7ZdsvO65xwwu2Le7I8pGUaBUQrbG9UxuLqimtG1uSMJEgy0Z3DytVUwpGR60 h0EVl0y2tVJqNQ.5_C0J0gI2nk8_OY8.DpcdoWkKwHgukp.FHsi4JHyIdS801X85Qlt1y8vugYny fuD3L6Fz5ClUXo0.9h_GdiTAUjmmxHbU.X_Qu9pz7Ufioj7LZYXvC_bMlYKRrqCb.9IlNiWHX4rG YvAaDEX9KNELGA.9AWNntLdMjtBKJ3t2cmNNNcLeM.RSwSE7qaI_ywXLY83jk.SATsA6oj2nR4zr okI1VmMVXJ.Daj6nJLQMMHG3Yb1uAHi3gIyVzlV0I8HBWM9SgakI62XoMZKfQzcnyJ1H84NLAQPm 83m4okKzTNi.0heFbA3MsUGKrcL1dcl0H3ntx7db7ogsbvV15Ut1ENluiB2qtV2wShkziZFE9ITR Hk3fnLmmuqEjeSq6tXPGNXT1Pl6Jlm1D2Ht5oVwxyN8c03J1FtIGyULfwX8uRiEp_hWYjcd4s8Yb upO_hX0S9k1MVCCx5rR48JoAlLoa352FaqZK5tz_2r_BFhOlMi4.9_G61gAtzJ_VuJmuYatF0F5U QkjbLkD_BZzdadC31tQtlS.qNzhjBbqN94qa5E4B1d0cBOnpTscnLXmfclAFcXHG1a8LG7sx4K1y wdhv.DBkTX9wiFh5ffQqH.2r_uPg6pUZWODJpxcAQi0xCzNGnf_Gyi1nrOZam2kL8Cg4l4uT7Pdg 96YFW0RyJgnD86Kk_CQk87zPI3efdyWjphJ.KcdbbrqU5HhYTfpN_W127XCF5I0z_HW6oeEiNp6X FHOovBOhtDBrXdxi9S81hZ3UTxfVZ9ZQsDDYLgOBfmwJNOqjJig2YgzqhLddOT4FcIi697zXH8QQ hUkxkldL711Wao5CTo04BSRUKRwVkuusapRL6QI31C8CuZUj8L8ZgE.8t0IR.Np2DHvhctkL6X26 WovKz6yFrOAeppG3EteoFJCJOY0rRf7O94zLLUR5j9m51oKfyfaHtPyzXFSok0Vvcj8eMvJK2lh0 eVoMtnTNWD0aBpoS64RdyNvLllFlWjLv4D6k3eIBxFjjiDeGydMnWcqRg8i6PkMyIbKPPxHGTklV nlY49hCZLJZt9Ocd4sksfMdMpeEOM97_Ohq87Oz4IsTWnCGNQOGOtzous9YbkZY4NrRo3LWlcQrL 1w8eF7ktF0eqoZs5QbdRgl7vA6hX8IA7c5ZOwcF9aYylIrXI3o__U_mGWNFUMUY4XyVHFvqXkOzX CBV_uX.54OGjjWstwHbzs X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 31 Dec 2021 22:28:36 +0000 Received: by kubenode534.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID df2d1529c0031c1b33fbe53c9cec1078; Fri, 31 Dec 2021 22:28:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] In-Reply-To: <5a24eb16-078f-15c5-dcd4-ecef33d15ac7@FreeBSD.org> Date: Fri, 31 Dec 2021 14:28:32 -0800 Cc: Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <03AF30DA-A632-4223-908C-9F5250D82079@yahoo.com> References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> <5a24eb16-078f-15c5-dcd4-ecef33d15ac7@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQftg3MdRz4lSq X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=k6sXILTx; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.60 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_SPAM_SHORT(0.90)[0.903]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-30, at 14:04, John Baldwin wrote: > On 12/30/21 1:09 PM, Mark Millard wrote: >> On 2021-Dec-30, at 13:05, Mark Millard wrote: >>> This asks a question in a different direction that my prior >>> reports about my builds vs. Cy's reported build. >>>=20 >>> Background: >>>=20 >>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so >>> and: >>> lrwxr-xr-x 1 root wheel 23 Dec 29 13:17:01 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >>>=20 >>> Why did libc++.so.1 not get a: >>>=20 >>> /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 >> I forgot to remove the .1 on the left hand side: >> /usr/lib/libc++.so -> ../../lib/libc++.so.1 >=20 > Because for libc++.so we don't just symlink to the current version of = the library > (as we do for most other shared libraries) to tell the compiler what = to link against > for -lc++, instead we use a linker script that tells the compiler to = link against > both of those libraries when -lc++ is encountered. A better identification of what looks odd to me is the path variations in: # more /usr/lib/libc++.so /* $FreeBSD$ */ GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) So /usr/lib/ still has to be available (so, possibly, mounted) for C++ because of the /usr/lib/libcxxrt.so reference? If so, why the move of libc++.so.1 to /lib/ ? > I have finally reproduced Cy's build error locally and am testing my = fix. If it > works I'll commit it. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 31 22:59:08 2021 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 BC5E719357FF for ; Fri, 31 Dec 2021 22:59:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQgZ21y0fz4qHW for ; Fri, 31 Dec 2021 22:59:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640991554; bh=q6S8ZBDiYf55j9cTKIH6Lyj80jAhb+KOXnXf0dItfGI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IKTaj9I0g17tj/cRuy9vnp3CYWkbOgJkjuydusyokS8CKRGF5TaIpyLHt5rh3nZUbVzHFC9xoyBOOZn2RZwl3JrO31DT4tfUfQ3o3Izhz1HqhSCFf4rBSVo/kbV79rkxehl5oMR3rfR3ujvcQWSW2G5MjUBikPocZT7lQ+wo1Ww6Z96y0YOk5Mpf0jWX3YHjp4YvbnpcClaPbJq+M0aj0Epd0I3hABj944F83Pqw1JUOTBJnKlxgjcf/ll9rYVJ17QRIpoQh/fTunl8mnCRjrwzFgO0jAAHxgEYYA6JZBbGZKJzmpXPWN/+yZVQGLo08X/rHs1HyaReU/0j8J+w/3A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640991554; bh=uAIRljQGyGrvKYI8FbPU5rJIjMwjCfRMLyjq6VoTH6O=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AsJ7ZP5r9GTWD+gPLmQynbCVMR0Wg/JzmpOY6Whj+3JTDp9GmIrNdeal/9x3+5Bs4RqcYlB1WGdNaLW/5Chpa+e/uRTZZfc/p0UkBDUV6ajM7OZbi78X3mpQ8hdktTeY298wTrWczaBbxObpaFF6RfyqErB42zl0oKTSRF51EnpayCNbh3RHBcpZNc+g7poil7WYC3s100IbgI011XKfIJIooa622149SKbszOxdwWDL9bGd8Ftfjk+mt+KvQr0ozKtV76Z+igfpf7WsxrHn3nEx/BW3UvGR+0NU1JvgEPU2AmyOhstIOENL1HB+lPXo6HW6wUlck1MHbwn7WNyGaw== X-YMail-OSG: H.ra9aMVM1lpaDDG_IidACUXFHmvBPuIET5yJGWrCeygaDklwBafTb2W.2MzUT0 9g2GdBUQb08uzEPYsOZcEVgbwnW0kh6KcG6Auv7Vok5lLk6Dy0qifI.GH7YYDzVNQ6coTBZeW3PH gOAK30hMQQVw5dfczdF1USHcvnNj1kYTeH_ftgmQY6kF2cDwMJCC23hYBmjrq.k8mycm5X7FjYY0 ONY_sQRxweYa0KzYkVGXts.B6xOGNeFBcS1XyT_M7VfP02737fnBkzlPsdme4W5QmwMbchOgoJC1 HeI6EY7T.VnocN2M5nHp_s_1Gh0V2wGZxhvnvWy4h5G1n4EZP1J4wFSz329kcLHHfvxEwWj3EzMo kChidzw.xqBYk84kDNXG_3Hthe.rOj13bO_yJxrHclIPgKVi4B9nV1Mrxhmd26ggRRckri6ux1Yg HSa3vdkhQk5U.qRokrIoBbRnZToKHwRHTg4KXhVN5gz.30N1qon4A6ohvjFaTrxUYWtMl2xY2nfO 84MGaVvhHzyaZjq6ZmYeu3Jqu35eV.FQGhUzaYo1h72kqEBod2.tPHJ4AyPB06S0HR9NDudFgEMo TPG5gX7TJTTUhPsRlrF60WYZ.QQJaKA7hBh2tEd8PNmXfBSor_bxAxXwPtao8nsHWNsc0k2Kt2zX xmTAE_cxngTJy8C.bJTYEm83YA5P__sbLYayBD1LkzDeYB_et4o0lFo95Tk5RYME6xG33ybG2PkM FeVpLRt3vXSbix7KZRy4gSk4EReF57Q3cTkWo1mm88hpuzZW5lNPHaJ9lFXoZsKpTkaLMLZ0frrQ RHDpLg.4dnsR4aAduutV8J5JJUOvPYGlbJTtoPBIzAD_71.H37dPWmnT38lRYMjuOobvqksV2ID8 MUA.T6yQ0LtPK0zwJlXPNRoo_ekEO95JLOF4blOEbz33_0jXHx792CGuLoU4H4_cwxG0lWQruvJf rMc9G.5akPWRa9J.61Qor2cPEQTPbsFxQXkzK2noHZ60TZ.7RjGkWBx5j65c4ksMUdeT164xGQfA DKGn6L04LKhqRbW57YpKXeoItYqONAK9NXVp7qm7nbUUMc2lhhS2mIxYP8YfaA6lS8t11H3TpQR4 2m1XRp9mgUOSNdB9cONEdi6AlOBG5NQlzL7GeIy1tWKYC9MvJsJTPmoZd7XiH20oJ8giL9OnBsab fEEGMi4iTCua3DYrrXUbD0GyiHFeHCnwoxj7Sna4dZ7nsTzUtod1Hu6CD22UQ6TzF4VQlV.88adP mtt36i4mRDa59QsjjgIj4gnhzjIi2TgOjFKB6MPrm33hiecAM27WpoohcKo07ksfszpcNMJHimSJ JkFhl1jo7mYLvaFnfarOYBczgTQpxZZCaGqDWisd8bYOPkqe_SSDcjGPolNo6ozO6CLrkREAqJWA xJoyQ0RqbC6tN3EPhWFZCmSQf4nh0WdbAJZa58zx3.5qHmRTB2r9a3_gggz2wcZUW585BGvKRHwU auaZzc_bLLSlATM1SO4YxYBnNAprrkEkuafmHk5t7yoDnU2n5krgrJ0TCWCnVpbsE40eYqxL4p80 rVh62u0YwSDkTHQE43NRdGiqHj09BDXmUnqnsaggjdIlFWfmU6f7lZCSnCUymToPfsPjuuNZxuq8 QwwafetYzJo.LgL_uA3GBTASVmrmyO_6Kl.ImqTMGPgMP1AscfnIvvcgA5Qh_xwkvuguRwm_ysvx RE3HMQSPvm1bkYmQc6QIurth7vOcAmcrqeCPWZsZVDn7nKwq.SX6nG0nSscBgDqs9YmTLImJKJOJ NFY6XDFHnggxPEvbeIomDqBRQipS73ba6tOEDJ0OMckwe7FcIqJf1RbTQfBVCkvnxJKUaFn0QlHn idzzckJSj86YaAUzDtopzgsd4cW5QSX4JHnCYMkIyrVNroNNaKxdTi5jR76Bp73BJutUreaHlcGx gMNVumH9TRNlGahSBXsJA6gXKTvPK0CLTAitTvyzl7A4sIoMqLG_pkaxZCnBlIpre5w2n1GwlWNR rXFgnDOGH_Ics6L5tFT_xqKYxHvZWd.qb81Gfo1G3ROy_irQmqCMGrOyNGa9Ooydfq1Lp3JNGxev ST_tki8arMrhowYn8rDWcFAvroOPUJyBiqE0U0H2GjYrTaNBPomZx6nELeQIWzia3eR0ekVxBBWK hVuV5tK2Jlbe308UNO8fw7py6qvtcqshQ.herQH6R9smNNxZ3b1PAi8DFcDE1.ce.r.UJXLgjLmN oP26UKg.KjtDJk1670GdUVLcdFNE8QoNzbTsQqQ9RNcQBhRMUXothXMgrzmIULb78sPKmN_qnRJB OdeM0hUZGQN4H2HV7EiHQ8ubJQA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 31 Dec 2021 22:59:14 +0000 Received: by kubenode538.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0744fd71fb52ae79e9a311f9f91f1a0d; Fri, 31 Dec 2021 22:59:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] In-Reply-To: <03AF30DA-A632-4223-908C-9F5250D82079@yahoo.com> Date: Fri, 31 Dec 2021 14:59:08 -0800 Cc: Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <76FC7AFB-DA78-4A44-BC74-4477C9E11413@yahoo.com> References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> <5a24eb16-078f-15c5-dcd4-ecef33d15ac7@FreeBSD.org> <03AF30DA-A632-4223-908C-9F5250D82079@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQgZ21y0fz4qHW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=IKTaj9I0; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.28 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-0.99)[-0.993]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.21)[0.215]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-31, at 14:28, Mark Millard wrote: > On 2021-Dec-30, at 14:04, John Baldwin wrote: >=20 >> On 12/30/21 1:09 PM, Mark Millard wrote: >>> On 2021-Dec-30, at 13:05, Mark Millard wrote: >>>> This asks a question in a different direction that my prior >>>> reports about my builds vs. Cy's reported build. >>>>=20 >>>> Background: >>>>=20 >>>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so >>>> and: >>>> lrwxr-xr-x 1 root wheel 23 Dec 29 13:17:01 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >>>>=20 >>>> Why did libc++.so.1 not get a: >>>>=20 >>>> /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 >>> I forgot to remove the .1 on the left hand side: >>> /usr/lib/libc++.so -> ../../lib/libc++.so.1 >>=20 >> Because for libc++.so we don't just symlink to the current version of = the library >> (as we do for most other shared libraries) to tell the compiler what = to link against >> for -lc++, instead we use a linker script that tells the compiler to = link against >> both of those libraries when -lc++ is encountered. >=20 > A better identification of what looks odd to me is the > path variations in: >=20 > # more /usr/lib/libc++.so Another not great day on my part: That path alone makes the mix of /lib/ and /usr/lib/ use involved, given the reference to /lib/libc++.so.1 . That would still be true if the other path had been /lib/libcxxrt.so . I guess I've just not figured out what specific, detailed issue(s) the move to /lib/libc++.so.1 covers vs. not, given the /usr/lib/libc++.so and /usr/lib/libcxxrt.so paths. I'm not using anything with /usr/lib/ being on a different file system than /lib so I'll definitely not observe any problems. And it might be a waste to try to clear my confusions at this point, given how the day is going. > /* $FreeBSD$ */ > GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) >=20 > So /usr/lib/ still has to be available (so, possibly, mounted) > for C++ because of the /usr/lib/libcxxrt.so reference? If so, > why the move of libc++.so.1 to /lib/ ? >=20 >> I have finally reproduced Cy's build error locally and am testing my = fix. If it >> works I'll commit it. >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 31 23:04:00 2021 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 A9E651937307; Fri, 31 Dec 2021 23:04:02 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQggQ39vGz4rVS; Fri, 31 Dec 2021 23:04:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [IPV6:2601:648:8601:8b20:dc79:bf12:122a:616b] (unknown [IPv6:2601:648:8601:8b20:dc79:bf12:122a:616b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id B722AF9B3; Fri, 31 Dec 2021 23:04:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Fri, 31 Dec 2021 15:04:00 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] Content-Language: en-US To: Mark Millard Cc: Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> <5a24eb16-078f-15c5-dcd4-ecef33d15ac7@FreeBSD.org> <03AF30DA-A632-4223-908C-9F5250D82079@yahoo.com> <76FC7AFB-DA78-4A44-BC74-4477C9E11413@yahoo.com> From: John Baldwin In-Reply-To: <76FC7AFB-DA78-4A44-BC74-4477C9E11413@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640991842; 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=2/1TwgQsLNSLvL+0xhpx/h2/bbRy03NSR0LoHMNKldo=; b=CVfXASH+sVXPL3A7IvWUHKJqA72b5w1mKI4vsgsPpaqmkBR+CeJ5ebHyNGppKifupT17TK KVb0PYAPtwzh0hEiiwBqb6bj+VM2Rd3MbRSmpD/bySJzfynCpAo6XUyXPcXIILZG3oqUBp s2QxPl77+4c6JxNVwuFrz8DOweklY04dBkPu+4mjT0N5Jkw4KlNGy2zj4Gt996TIaY0h/j u9G0rvHd/WSG1+nEkGguekmosktzQPQDOf9UxnDXhawbaPUyba4QrOuBmXb1VnI2AnQyIZ UIi3JWYyWY6piQ3KwW+pPb+OjjhXLi5+aonvlnPi28Xf/FlJJoLRKiozdw0Ctg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640991842; a=rsa-sha256; cv=none; b=vfGlfa2QTMnbuIdo1F08aKZTqFDzmdDKZrTcirpVU/PRkwAeuIGN1A9jyfiENBPnh535jn J6Ysj4ffDkNNclRY4LY7uffspX6W3uB1kZCMnQCDj7b56ec84cxsfXOGZ/to2SPfRZFM/A SLsKsy575ZM5LmpDH0Pd9u8kuu6MeZc+drPbnQ5IGfjGdKSk7qZe6raGuRpkujPqW4KUAx yU7MyaM3+iyofZiR6TPt45OiA2VB7+n/ewgInoTqvDjuDyjDu8Tu6Ry9FKipXLQCknw/Be ih8shuVZ/gtprQf/W4KmUt8Oam/zSn9y1vYMO9992Gx2gN33DFdymfSL2PcwoA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 12/31/21 2:59 PM, Mark Millard wrote: > On 2021-Dec-31, at 14:28, Mark Millard wrote: > >> On 2021-Dec-30, at 14:04, John Baldwin wrote: >> >>> On 12/30/21 1:09 PM, Mark Millard wrote: >>>> On 2021-Dec-30, at 13:05, Mark Millard wrote: >>>>> This asks a question in a different direction that my prior >>>>> reports about my builds vs. Cy's reported build. >>>>> >>>>> Background: >>>>> >>>>> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so >>>>> and: >>>>> lrwxr-xr-x 1 root wheel 23 Dec 29 13:17:01 2021 /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >>>>> >>>>> Why did libc++.so.1 not get a: >>>>> >>>>> /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 >>>> I forgot to remove the .1 on the left hand side: >>>> /usr/lib/libc++.so -> ../../lib/libc++.so.1 >>> >>> Because for libc++.so we don't just symlink to the current version of the library >>> (as we do for most other shared libraries) to tell the compiler what to link against >>> for -lc++, instead we use a linker script that tells the compiler to link against >>> both of those libraries when -lc++ is encountered. >> >> A better identification of what looks odd to me is the >> path variations in: >> >> # more /usr/lib/libc++.so > > Another not great day on my part: That path alone makes > the mix of /lib/ and /usr/lib/ use involved, given the > reference to /lib/libc++.so.1 . That would still be true > if the other path had been /lib/libcxxrt.so . /usr/lib/libc++.so is only used by the compiler/linker when linking a binary. The resulting binary has the associated paths (/lib/libc++.so.1 and /usr/lib/libcxxrt.so.1) in its DT_NEEDED. So it is fine for the .so to be in /usr/lib. This is the same with /usr/lib/libc.so vs /lib/libc.so.7. However, your point about libcxxrt.so.1 is valid. It needs to also be moved to /lib if libc++.so.1 is moved to /lib. Doing so will also require yet another depend-clean.sh fixup (well, probably just adjusting the one I added to check the libcxxrt path instead of libc++ path). -- John Baldwin From nobody Sat Jan 1 01:46:19 2022 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 337B3192B1AC for ; Sat, 1 Jan 2022 01:46:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQlGx6Jgkz3Q8c for ; Sat, 1 Jan 2022 01:46:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641001586; bh=CdzgwUvkuzrBkO752DuJzfHRI4qf8bqADCIt3QVfESY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AIk3VGxEoeYQUm/sXPNn3Zx1eP3pB1dpS+M4ejtkLoOeAs8i/bnQcnx/tdut3PNwiU6N5TO4U5p546ghhJfSwa7f+T+UL0TLM6wEG3iF13k4S1fznnegWwngjJejr844/BKhJse3Ild+bV5Xns4IALdeHHlCG5AsPW8rSWB4CJrOrnb6YpVwXfVphzKuMgXVx6pLBdt6/ANaXtB6ytd61xSwxwbAkMdiFyEBunVEOMMTSrlWch5cntD9Bx5SFkSnxAokYoI0AC1yr5hc4gAX6ZljnlyYwx5rJ7ICicxnAuiq3AeSC/Ja/B2ZdV8R8N7h/ZHFvY88SQgTWn2zD3VkGw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641001586; bh=H+iQyVUvBsOvZZvz3pwB9Uv1fudb7sfg7RAJefhycXc=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lTs5pGg4GjGL/NEtho9TeGP9DMFS5z4dtMLM3tR41931gfbEyxTF+U2wUge0eDqAdiq8QyPuyTSFtWf7b23kmMRYAsLqBhQTlIISFC+axMs0JItmo4DWfZ9Ks6iQutXudZKZxiFOXY2u2tGPEquWLoPphK7vIAT+7D2gZwTZXp6gLoPPzVXLGSlGeOtVMoVXxa3fYFrVPMed6NhGrnfF8jP+vqkQME2NbS+8Jgl+9hr7R/SRzeznyZfaY8bPLVxbY+j57HL/7o9wXNAHQp437v8+8WFgEVkEc0SNxWGElkbt8hjLObaohyFE2lbYgx84mkKfntO+r1SeZJ/GXii9eA== X-YMail-OSG: gmF2Da8VM1n8K0DQ45nr.5FSt8UD.21yEdkEZPowqC9G4og9hYr9lgoakxjaNp1 DkKknV2ImiCzvQS6WweCHOU4VZbUcOQ.mRfKp17B0IlndBKUyD1TOezexsp3XCZjvJ6jvGWYoT8R TeTKQ89qHsbIcQJxR9_WSeJ3lnH7_InDd3m41r2a1m5wxvPIEiricOjJxlKRGLi6yJdOxbkQt639 QANJM2nzp9nMfG9lmp3SMPpyZszbAiRL3ucjinM95pa7SzZaKVWIEHmi_b867q5XcgXJkh6w8Pve kCuVwuH0SA_HjwnohuGgfZAshoVE2zDzbUykZwmMd.ID7PU6jDd1L5R4Yg99SYsoA9DKA1zVeetu Rn4bxSD0gpH5q0nctjKEvSQLlkUNbwRQDdtrVCpZdcJL.spFUF3MwHzPOarGtjp63WW08w9OwB7y YwKvEzp5Glu49GanKXlC0mTxXLLBB5F0VDRkh1PUeQbTkqwzdESV7ASQW.hsW33qCaUgs0.4kwFI 1Xt1CJiBH6XBYGKJd4Gg5VzcYCvk4PalzONlr.Sl3ZubMN3IJ1DOklKTEmNB55LaTFQwFReRYPS1 KNYLTnspjoZPLDBgJTYn.9yEY1fPxfPKT3c7Ye7zAFFPh6Xwo5L.yGYQ1oFbyHB8dSiBCnGe0o.M vbcKgKokFwCXyMD4KJFbPklNgZtKD6Ufgy1RZ6LUPmJbsTknUxyE4wYjAMklaCQMY81dTfHBrYXA GyvRBVem0oGjy6zDzFPMpejyYvrv2sEKsuYBnKmWOR.IMVeEgEBukD0WhVx4M_n5jiITion2h0BO Tis.hnR8Ms0XEkkhmW951M9JuA8VrgaOLUdtYcTMAF80nhoXhau5PTsa4TUGIWktScDiNZueYDoH utvi0Oi2tg.dsXFJtFbKE9sDBywFm3Yf0iUe2cEYzLc.UEAcyzswGmm.2dAMVjjNKyROGij8KPYY ZHRxNt25h5.QOKL5jcZ0H7CJ79SB2M1H3hOiqosF65IKn7QeHoUKarN8A7zW1OZIyTX4P0WQNKYf g9Mfep3HtrDsacLyQNOQY_F0uK2tWsfwmpAr4nwotbUkwrNiRqo_IsRQfL9PE6PGOy7TQrkXYlT5 hu2ExONchpN3_9G1cSi8SEm28xddONe9hpl51PXdk2fiKrSwq9Bubsauvip0hgqVOUmsdSe0DNfL LAdhiLBTUcUAQXxFj_Varnpir6ItSCK5f0yEpihnvCwqIa4YSngyVA.O7gQHSzspLlw_jyJlsSrk 0AQlEPSz2lIXIg3a3hYau9QO78JrpfK3KWT6NZ_5mSXzI_49Wb0n4v1nHS7zYz6EeCe2zdAUuw1c UsP0G19wG0kKL7kXADxsGsOCgWfr3p3YCuvdZlPfePHYXr.CWQ6rjnp.80zpJqtcyGm2Aycvue9E U0fb7z.vYnFUW85W3Fn0Mv3WF.Wn0_c.SVNqDL1BkIVmyAhZiY4u.xL4GVuKsmPDcuC5TwMg_jVX 00mbL9pcepQTQK_cr_ggd0BNlEywHz7h0imOu.MGV.9sBYSiBMF9NBqiorZT1bZ3yibC5_43vE.a LH.4QAa2POyDwE2ulDNnQIEtCSsYQBVh2Vf2NILW36cRUrS2X9YO6h9V487Jyroi04p9XMrBT6S7 GJQeWLYAirE.Of85wuxQg7O9jXJL8WZiAq9ZtdyPuNmqEV.WJaxjO3SpfR7dBBq9JLZUHSsw_npy 9AI5R6EvDAwfnozdMYB_iC9NpW_s3Cd2HOQf_JRqcVWoNWKIiDefFMoE4J3OPLi.j553sXaNXbap RCc_LWfokQbJVJjaIyu.u67CuoSTcOWc9LG2ZqiBkokSPrPFY3O8CwXRuXGLznYUin6cbxtcNi6Y 1X7X9yFamPU32SULC8kBeQOswhxG1sTjWCAfE.8j_TrvTEDRLi8hAwuyIvzjEm6_ocai0RU476bQ bn50bcy9axS_HRLfSFkHd6YmYra8aVCGTS5bDO4ymVE54ssyCjVu_7MPv6kiPacl7wSE.RskmBwX aBJTwYJkLomJtEcg4Qf7pF0Dhiq9B3grl2Pxz05ZLf15EUrLuejKfkONGsyPi6TZXGRTo_9Yrgb8 ozAsnlJDag9R6CTkdcHfNV7WhqTh77KKFnqc7xOWyTYNTkXacyoqRl2OtpKWwip8aPTt5eQHvDmg p8gAe69J.bSWOsmDuL3k.AWUW.hWQKgnd_TUlPcIqWaouFQMDhVZ15DX6lsb8P7eWygOCuH3WfM1 FZ9RtPxdz6twXaKHrRbtlF7P7MdENdtgQv3.L4tFnKL7LPw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Jan 2022 01:46:26 +0000 Received: by kubenode531.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dac7313a8a0ebd4a19ce2f15d579dc6a; Sat, 01 Jan 2022 01:46:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] In-Reply-To: Date: Fri, 31 Dec 2021 17:46:19 -0800 Cc: Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <82BE340A-321C-43F3-AD7B-2E8466ADA17F@yahoo.com> References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> <5a24eb16-078f-15c5-dcd4-ecef33d15ac7@FreeBSD.org> <03AF30DA-A632-4223-908C-9F5250D82079@yahoo.com> <76FC7AFB-DA78-4A44-BC74-4477C9E11413@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQlGx6Jgkz3Q8c X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-31, at 15:04, John Baldwin wrote: > On 12/31/21 2:59 PM, Mark Millard wrote: >> On 2021-Dec-31, at 14:28, Mark Millard wrote: >>> On 2021-Dec-30, at 14:04, John Baldwin wrote: >>>=20 >>>> On 12/30/21 1:09 PM, Mark Millard wrote: >>>>> On 2021-Dec-30, at 13:05, Mark Millard wrote: >>>>>> This asks a question in a different direction that my prior >>>>>> reports about my builds vs. Cy's reported build. >>>>>>=20 >>>>>> Background: >>>>>>=20 >>>>>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so >>>>>> and: >>>>>> lrwxr-xr-x 1 root wheel 23 Dec 29 13:17:01 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >>>>>>=20 >>>>>> Why did libc++.so.1 not get a: >>>>>>=20 >>>>>> /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 >>>>> I forgot to remove the .1 on the left hand side: >>>>> /usr/lib/libc++.so -> ../../lib/libc++.so.1 >>>>=20 >>>> Because for libc++.so we don't just symlink to the current version = of the library >>>> (as we do for most other shared libraries) to tell the compiler = what to link against >>>> for -lc++, instead we use a linker script that tells the compiler = to link against >>>> both of those libraries when -lc++ is encountered. >>>=20 >>> A better identification of what looks odd to me is the >>> path variations in: >>>=20 >>> # more /usr/lib/libc++.so >> Another not great day on my part: That path alone makes >> the mix of /lib/ and /usr/lib/ use involved, given the >> reference to /lib/libc++.so.1 . That would still be true >> if the other path had been /lib/libcxxrt.so . >=20 > /usr/lib/libc++.so is only used by the compiler/linker when linking a = binary. > The resulting binary has the associated paths (/lib/libc++.so.1 and > /usr/lib/libcxxrt.so.1) in its DT_NEEDED. So it is fine for the .so = to be > in /usr/lib. This is the same with /usr/lib/libc.so vs = /lib/libc.so.7. >=20 > However, your point about libcxxrt.so.1 is valid. It needs to also be = moved > to /lib if libc++.so.1 is moved to /lib. Doing so will also require = yet another > depend-clean.sh fixup (well, probably just adjusting the one I added = to > check the libcxxrt path instead of libc++ path). Hmm. Looking (now after having updated so /lib/libc++.so.1 is in use, not that this is any different here): # ls -Tld /lib/libcxx* /usr/lib/libcxx* -r--r--r-- 1 root wheel 131656 Dec 31 14:19:49 2021 = /lib/libcxxrt.so.1 -r--r--r-- 1 root wheel 355764 Dec 24 15:19:42 2021 = /usr/lib/libcxxrt.a lrwxr-xr-x 1 root wheel 23 Dec 31 14:19:49 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 # more /usr/lib/libc++.so=20 /* $FreeBSD$ */ GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) So: no actual reference to /usr/lib/libcxxrt.so.1 but a reference in the DT_NEEDED to /usr/lib/libcxxrt.so ? May be just /usr/lib/libc++.so needs different text in order for DT_NEEDED to have different text related to libcxxrt in future build activities, avoiding /usr/lib/ ? For reference: # uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #27 = main-n252090-5650d340ad66-dirty: Fri Dec 31 06:00:41 PST 2021 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400046 1400046 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 1 02:18:56 2022 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 6B5071910573 for ; Sat, 1 Jan 2022 02:19:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQm0V473cz3k21 for ; Sat, 1 Jan 2022 02:19:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641003538; bh=K9616ueUMG8bLwhVDd+sTkqfJYjVtyvtc7AQAXAeiFE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Wdfg72VZzdp2VhXV8UBOllWl1X3RlgmOKuZ/qtIByzu/T/I6XVPFyAMFMByy0d8xSWjz4SGiQ2ewpIQV/n4GSvModPbrRDzUKnEA4hZMdtJcEBeK8JfYaOoLWiR7Tg6qC/6i6nGigUzSpFLVxPoYDPpKaIBL1gyl68GZe9AbwqbFxqp2ITyl8aOQzrEge1WyOx7hTpBfYJtsdHekCO6RNG0w3NX+ke4HybkRra9iBwjDNoKFGXkzoq/rSNGPDO7/3y00Ucqxk4ea9BrrPtqtF7kSsUOk3Gi60ces944zbO4VRX81wr2SY6NELtfuY19ef0d+jMPrDZQvWedJhL/LLw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641003538; bh=QCnd/Ejeaa4EZ8CyYrLCInYuLgYpB0lrKzrc8EmVvAt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Sr1By5lxRK7x9p9BPu1MPw8Pjr54s0nF+0NbH5XJ24mn/R2ugYZebAvbV3yEArpsbJSnFWEEkVBts/Fpc4xU6zEjMsyiYUnLo3x33Z+OEbo02DoKgrBG6MPQXHtSVNkbzPBe5+n9xRQl64anWQU3+phMfAp5nnxn0jzmBBP3/FRbu6ZgdcxdQ94xlgkJW3SwQa9vbMtOjDsmobh7cSDAwfMW90G1raqHnbtPW1URLNBKyW3uqnsEWJ55qaxJLhXGvsv8rTCpIGeEMERai+AERMUCAYxcGwqQ7t7weFSXYidvVf1C+6BByogiqtO0tyysjUUbVnPD0lB1CdV1OMEAfw== X-YMail-OSG: 8FNWZsUVM1n1tucRwVR.nsxN7rrssGGvxH_fd83M8A8TibB65jWgcOY0fPZEGLF vyGkigJIRz_bGoPZAoz9Di.3fTg.BgQshwv4qTJWRbeWaA6_k3NPTUGSQN3vETuRDhGw8gtH4gWm Wa7blRQYC4nZBNZD7QJkj9VLpqffFtnJ5Jj291UIcf2E7dhYVMng_L3ohkjrlgVTdBqcMaKLe7LH LkYvgLeLxR3HAAfFWiFaCV6bmfCV.ShHBI9MRfgtbLZdJhMRlqybwnWDX42zSR7.dx54fLRZYDI2 CCLn9gbtkRa3zxDTXKCSSQ8Ium2Huv7a1HYIjdgsx9BBUpoXNFSgTDiAcr0R7NKWNTW0.w2YqF.r MierVu7jv_T0neaWd2mB9RgGpp0R1UZJ2iJS1FBAxxq0sW4J9D0TBsoiD3dDkQQISZh1KMXH0gMF 3nKP75qw_EVXtTjIdw66G4.bPY_dimtb8jo7CeqIpdKtViU6chnee1g4iYW2fdJIErhw8Dg4370Z MLs3bZcrwlhzekbZNTCl12XWarPfVNDgg9t8ZPdlxTF2fhcq66pkf98zbD7vLm3.b4gclJY.piCH .9Z3q6urdnK4bhpLkXgOCJAOG6O4KIhxzDJlDgQspF5bU_2d9JryfVhRK7_zBVT4gwLBsB5Tt2Du VfJe9_6zg1R2RjZZydLPCpQQfUYklJUI29RouKn8XzEQgFTtPn4RElKUVsObaDjxKZRGbtun8yjP cTjXZ7bwaGYDR1srjfE5Dnhi1IL_GFc3AhK.bdyRiRZU9aHFqNvP9ARwNzwmd9_aCcZobwaSVvHx 7CRavz2Nub39NOEu3Yu.HoJNE0_1IvKIVx.hrDZ0Zvg8dWb9hoIHTZ_AL.IEzpm6O8yUr67qtkZW 0nkCmhdBciBt_9LtnmG2GAgkGS8HLdCrutV5xhnnEaY6noPlq_8Dr.oh3pRkxxniVbh7G5Ohrgp0 May_klHQbtWuHN3IvetK5PfBNa94T6IFcU.1Mzj_T18ohaU3XpUd_Y7Ua82.YirFQ_lS41brPmCW ObNauIkrdfp205uZgrJo_FoKirUhFmqTPq5G6xUsCACi_b3LOwwf0xD198mPtmo7bXSauavdT6HQ VNGLIDHAOT42QkNNEkpp9j_hL3QqI36ttrx0f074rE5dteuZm15REItEjBP4Kd2GFS1UU5IZ05v1 etmI74wixglJ0ZloDugV.W.Dg2.h1Ec9hWZ2OjRQiD4vc21OJz6yEQWHprVVtkH2eAf3yUbhrO27 dgvs2mjUwpl3W05fk9DORO3v5mMzy_keS8J7Na119MybjJYnaLoQomUC7uDLfRQRhFVLrNP53Iav aJJjWFjGS9PD9aExRgdpO0bapjDAzGVP23hmTmywwy137qa7rUB7VKCQqySSnjv1pbjlspxZwb8f AoaYSHEpfgXww9pHcMjl87zS3IJolf9iRtAxGkUcWmm6vS.e1hXyTE0qXCa9Yb5hQ9qhbo6r4Di2 ki5harEmHSrsmBQAFY0p7kUKkF8Tx8rvOa.cEVusaSEPoV4dRBr6.Vim4qnwh_I6p2yVk_kCZjEH DLiMWwmUmbs3n69VoR57YDXBlXk.wUJfTVo1J3Jg0S1gwJ39Pbpktn.oNQfJSa9h5V08nkLTc7gL XeSMEEaBQkjTtabt7PSqzGFvXgslpF_vk95tFxUUeY7eSW0ErcbVHTJrPliYOlhFJxhoC_sepd0I PBSTGacnoWTf4U10hKo8bIgKMxVZY_JQfdW40bkNDst.SECJ5uS_kMEYP4kX1nAXtdPT8SjW7Vfs LJxd4xNYmxpnN6KhyIj5IBx.v16qkYLjVv_O.rwreJlqZu4e2qvr8CNhCN4hPFaEoqDV._PCaxrJ ahoCxANuY3NnMio9ux0h2X0G2hENnYjG9pb0yFQCzCjrPoQefAFRqUl0kWm_.Lio9LLob5899HMF DX0zBh29L7qdWIAdggBLqvGR4WsowQpxwncHNslCtFpJj9Jvg9vSJZ3k12K5qi2XoncpLer2R3Ca rEf2zRxV4lCPYFrfav6fiaCpi9cGJykiv4tdE2spixXl400YnVPDYpy3g2rpQsZHmUX1TWzSLtE0 86cNMIKVf1uVSebhZS1K6eV9YZdJw.tMwAelNKpv80RVrIWf5UWsvBWzEVlL5R4inr4CsJx8rtK5 ibTe4OaSmukCyLvJIp4Kbj5H8B6evCvt6mOckyEku1fCKQnDnSPdz4vsQr.CtZP.Asw4vl_9Frph WIBzsSpIrzI2ErEvjCYeKWsCSmhTzj6fRZtKlDLX7G5E- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Jan 2022 02:18:58 +0000 Received: by kubenode524.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e29680bae811a39c9f7f9095852e448e; Sat, 01 Jan 2022 02:18:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] In-Reply-To: <82BE340A-321C-43F3-AD7B-2E8466ADA17F@yahoo.com> Date: Fri, 31 Dec 2021 18:18:56 -0800 Cc: Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <595C5A0E-B024-46EE-883E-2FCA6ADFE171@yahoo.com> References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> <5a24eb16-078f-15c5-dcd4-ecef33d15ac7@FreeBSD.org> <03AF30DA-A632-4223-908C-9F5250D82079@yahoo.com> <76FC7AFB-DA78-4A44-BC74-4477C9E11413@yahoo.com> <82BE340A-321C-43F3-AD7B-2E8466ADA17F@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQm0V473cz3k21 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Wdfg72VZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_TLS_LAST(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-0.99)[-0.995]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-31, at 17:46, Mark Millard wrote: > On 2021-Dec-31, at 15:04, John Baldwin wrote: >=20 >> On 12/31/21 2:59 PM, Mark Millard wrote: >>> On 2021-Dec-31, at 14:28, Mark Millard wrote: >>>> On 2021-Dec-30, at 14:04, John Baldwin wrote: >>>>=20 >>>>> On 12/30/21 1:09 PM, Mark Millard wrote: >>>>>> On 2021-Dec-30, at 13:05, Mark Millard wrote: >>>>>>> This asks a question in a different direction that my prior >>>>>>> reports about my builds vs. Cy's reported build. >>>>>>>=20 >>>>>>> Background: >>>>>>>=20 >>>>>>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so >>>>>>> and: >>>>>>> lrwxr-xr-x 1 root wheel 23 Dec 29 13:17:01 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >>>>>>>=20 >>>>>>> Why did libc++.so.1 not get a: >>>>>>>=20 >>>>>>> /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 >>>>>> I forgot to remove the .1 on the left hand side: >>>>>> /usr/lib/libc++.so -> ../../lib/libc++.so.1 >>>>>=20 >>>>> Because for libc++.so we don't just symlink to the current version = of the library >>>>> (as we do for most other shared libraries) to tell the compiler = what to link against >>>>> for -lc++, instead we use a linker script that tells the compiler = to link against >>>>> both of those libraries when -lc++ is encountered. >>>>=20 >>>> A better identification of what looks odd to me is the >>>> path variations in: >>>>=20 >>>> # more /usr/lib/libc++.so >>> Another not great day on my part: That path alone makes >>> the mix of /lib/ and /usr/lib/ use involved, given the >>> reference to /lib/libc++.so.1 . That would still be true >>> if the other path had been /lib/libcxxrt.so . >>=20 >> /usr/lib/libc++.so is only used by the compiler/linker when linking a = binary. >> The resulting binary has the associated paths (/lib/libc++.so.1 and >> /usr/lib/libcxxrt.so.1) in its DT_NEEDED. So it is fine for the .so = to be >> in /usr/lib. This is the same with /usr/lib/libc.so vs = /lib/libc.so.7. >>=20 >> However, your point about libcxxrt.so.1 is valid. It needs to also = be moved >> to /lib if libc++.so.1 is moved to /lib. Doing so will also require = yet another >> depend-clean.sh fixup (well, probably just adjusting the one I added = to >> check the libcxxrt path instead of libc++ path). >=20 > Hmm. Looking (now after having updated so /lib/libc++.so.1 > is in use, not that this is any different here): >=20 > # ls -Tld /lib/libcxx* /usr/lib/libcxx* > -r--r--r-- 1 root wheel 131656 Dec 31 14:19:49 2021 = /lib/libcxxrt.so.1 > -r--r--r-- 1 root wheel 355764 Dec 24 15:19:42 2021 = /usr/lib/libcxxrt.a > lrwxr-xr-x 1 root wheel 23 Dec 31 14:19:49 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >=20 > # more /usr/lib/libc++.so=20 > /* $FreeBSD$ */ > GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) >=20 > So: no actual reference to /usr/lib/libcxxrt.so.1 but > a reference in the DT_NEEDED to /usr/lib/libcxxrt.so ? >=20 > May be just /usr/lib/libc++.so needs different text in order > for DT_NEEDED to have different text related to libcxxrt in > future build activities, avoiding /usr/lib/ ? >=20 >=20 > For reference: >=20 > # uname -apKU > FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #27 = main-n252090-5650d340ad66-dirty: Fri Dec 31 06:00:41 PST 2021 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400046 1400046 >=20 In a aarch64 context I looked at an old executable via ldd -a : # ldd -a bt /usr/home/root/c_tests/bt: libexecinfo.so.1 =3D> /usr/lib/libexecinfo.so.1 (0x41c19000) libc++.so.1 =3D> /lib/libc++.so.1 (0x42484000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x43038000) libm.so.5 =3D> /lib/libm.so.5 (0x44a4c000) libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) /usr/lib/libexecinfo.so.1: libelf.so.2 =3D> /lib/libelf.so.2 (0x4581e000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x46e4f000) libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) /lib/libc++.so.1: libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x43038000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x46e4f000) libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) /lib/libcxxrt.so.1: libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x46e4f000) libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) /lib/libm.so.5: libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) /lib/libelf.so.2: libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) /lib/libgcc_s.so.1: libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) Looks like something already deals with finding /lib/libcxxrt.so.1 . But it is not obvious what path it started with and how much processing was done (or when) to end up with /lib/libc++.so.1 showing. But there is still a /usr/lib/ reference overall: /usr/lib/libexecinfo.so.1 But this is because the old program turned out to be an old experiment: # more bt.c=20 // bt.c // from releng/12 (12.2?) context (pre-llvm12), but not releng/13 : // # cc -o bt bt.c -lexecinfo // # ./bt // Rerun in llvm12 context, such as main after the switch: crash. #include int main() { void *addrlist[100]; backtrace(addrlist, 100); } Although, for some reason, the executable was dated 2021-Jul-15, not that I remember why I'd rebuilt it then. # file bt bt: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), = dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.0 = (1400025), FreeBSD-style, with debug_info, not stripped nm -a bt shows: entry: 0 d_tag: DT_NEEDED d_val: libexecinfo.so.1 None of the DT_NEEDED entries had paths shown. The only /usr/lib/ reference was: entry: 65 st_name: /usr/lib/crti.o st_value: 0 st_size: 0 st_info: STT_FILE STB_LOCAL st_shndx: 65521 Overall: backtrace requires /usr/lib/ accessibility for main-n252090-5650d340ad66 in order to access /usr/lib/libexecinfo.so.1 . For reference: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #34 = main-n252090-5650d340ad66-dirty: Fri Dec 31 06:30:22 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400046 1400046 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 1 02:20:46 2022 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 C84451912147 for ; Sat, 1 Jan 2022 02:20:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQm2b4MB1z3l0f for ; Sat, 1 Jan 2022 02:20:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641003648; bh=3gJLoHOaq1QLszzhsNChJnyeTatTAmgZH4bHDiJ7UE8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=cqQVPzK0/A8JsymyYIQqSB33WwjoYk2dsmXZmkLk3IIQpY15tPmldeJecjCDEmulltJn9MDThpg+ClAx+yjYzoAZduVUWI04NAnTcGnLt9MjjqXkdefKVdMPeIiTgeV9uCa6JJsKR3CzbThk8mizhdSG+ndNm0P7dELaRnbN05uYNnswoggO/1R972wIiC79+w/c0suP4KVSdpvMyQnv978AAPw7VylAJlwr6JcUfUwi9rNfWetFq4WbOWOdXHVJ0LmFlrQ9xmzFtxT4IM1RxbfoaYe+X8naAuOE47oI+z7wAdCIHBlh/N1YmqPnSi0kEhgaNrliE7ZZN659TGvLSw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641003648; bh=IkArqnpoXNLAhxdvzpSTKkrQs6Dfqtd2e4USFkva9xX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jknPxs8C0XSQmTodE8ci4SkAhLn6oYKhlu6BV/mzayBSfUHvzlGOk/RhnOzwaVizJybl7o5RdRCNgo7+jMXmwNBPNpJIRd9lVoqX73P+FczURD/4ACOIH7khfiEjtH6S8eKUuV3Zs9uj3JiBOUUFA6gJNgbb0RD81jiunG6OTHzpJL53oAn5fAHlreWArfAhzIqXe7s0iL0tUm3whEulbXIIJ9cH94a3fS7CY7JIgIX0q6Ywr4CehOuHtp20B9gCpuSSff01I3e1J7zPBc2EXED+W/MbHh2QTAn8nOsJbNrihs0VZUW0bb4juJFKB4w584SKlxgJrxQ0He5dUiGNOw== X-YMail-OSG: TMiE1wgVM1mQfJaya6ynu43km5xP2Kjm.iBXF3zSdkbF9UlsQBihI2twO6oditg T_Z7BBDHJkHja9XB3nxlLgHLj422vlhto.OdW_FjJUtirl4E.7j0yAWQ1DtC1f9i2VEx_5CjYwfD AwPXD6v7lBCySpITuaOnpPS69oVUc3d.FvaBq8mV1IKCBv4va5jGN07a1LdYjdtXZ8MILkQS8KcO ZYvsSPwYrl5pVv3huz887n5uMTraIMefXeu7QU6hzdLnHJJlfzfc7fawIP2p4S.TCgncm5zXA8oi gChtm59Ms_LoJBsgoKxCJ6jyF0DbyZDbG8q_I75H_q6nEQe04w76qpa_2Cwo5FtHLLnfCpLRX8j8 aiayoTAhr1SSH8Nl.FSnBhJk_PMMhfEAnRKsv.VBZy15pDBvCw3CvQhGXmHgZQgLJb0RXfsMPNIe UFXk4icsBLFppNF4wkYnGH.8e1aL0UYPSVBRKaKU15D38gE24ibffFXDtem89Ez_C8kVszDhPP.P DrrOyJiAFoA1sOUzH9NDRKjRE3XX0Q7tZm0TkZEFO5h.t72qG3yW5KP5PIgn2T.Vb8D3BCE0WY9q utvMWMM9TMI6umTVBRfGHq9ikqXbGrOxcpZi_GOR7NMA87yk0_bOKA05hBaad8q_PHlVYWR9JOej CMBnPQ0xgvmjQEatQ0o4K6GaZCL5U.cCf3x8bFMufP_3CXPnXeuZXToGbHSe_Vl4c7FDkyJAIUo9 P4Y5nXsJWXa1j9X6gI8BtlYGAMAJ7BPV99Stf66TmxbMHabqX2EAW5SHvDHvUg.BI1t96r_Url.v _0wiTAJlyuK0mCFZLeLQlYg3QvwYE9IrKtcf_52_3x_p.Cf16RuuwPBkfAItxiXyNipL2GhVJG6p 5wIyRcIGiDslh839BaCKKCu2UAqyrqYce9R6mGKk9zaWG9g3dHPN0quD7Ldv3I.Lz79M49p6ELD7 gnk_2mXlBdBoHapX8vsaJ7f8EgXN4Dpc0mnMXcrj_XPzEWqrGH6BpwwtNDJGNB3NfebUF4_wV2F. ntUEVnD7TvZNCudTT9ba0v7WrXy6sP2BdK845l29_Fu3X6hutee_xShi5zLIJ.2qoq8ioJmfYmGP 7lYowS6YVZ5IytpDVtCXEx0Ac3oCYo1EtzEPsZbmASh8WpJ0z7Pj_hVlFqSm9CR5Mhtb7KOYKLMC McF89vX1HJ.v2uqWy8DhMrjspAgR5tMIIml_npu9otlvv5ZeZkF.XaVAZk.sK3WGFFOWtXg6h8yR hP0jF8dn1bXRGJZOCHMgN2KWydg..IkrpAPAiykwsGlHRVFpxhOE9l5xua19DOJ7eb5TBO3edxNC DIWknlcqk5nkVnLm8SiR6FF.lexyMhuEjsfybjN_rWl2BDYXXcIu7X.PUwwV7oIfc1fYOSYGMr5S 6lVifojPaT2wYeQdg1jVj4BkLqEtAdFKMgoufOSRd3_PW8th2OGNH_36Tr23ecQbokelT1a24LkO YZdCZ947C6cjqT.ResllXo3PxtnTvRYVtiBmXy_0wN74Ryv2AcKZwkoU3SqPZwRSWdvQduhcCtiu i0Lh6m3yb3plQKWzmzcMYCEEhsXG_qLUZIKFEcedAaZmXZipMq7kIOBjRcNchkDY5nxKwWkrz7LJ z95sZiQZR84TrlYW6m6cNsb.Dqacu.fU.DEHazcLqSpF3pdVFOHRFzI9hsLDrNPkeSZznNw5SmPt O3oDXWNSzm8s_DWgot3sdxeRWjBl9YQHEE56tdsE9wt0s6KTJ6544MTT02treou9kXqFrx08gsUS qCYVCiUkEmZpJcLxHrzfAdojvkbsSy2CFpZFuYc3P28j2VDfKe4uGnRtSHwWF09ccNL3H9Y7r84b ZtT2bS3JcvIdJ5GsMWV0z6RbpTxvre.L_M5BAMh7fqkeA5XaFZPb8_ldaxDAkbtoFbLX3DNrKOX7 NMWszRHVpAfYsoGzKo_LjkxcPw7cj5uKhQgeMIN5yGMcDelOjGk5ap8okRUKJxwgBlm1uR9SgbLn Is_g8sHQY0tEKJ1zumQop5JlnpsHej0VGEoTJfRptfS449BvBl6mBm7yWANIpvPYDqtDPxt6ZFnL YceQrvee_lX.ZN2CKWzj7afRDBvQYiqKQ8Fyy1vpvXSYpO.Iq2qCsnpGcIJPve4dM0tJ5uRDvsnw ux_ckQwGjRiNS_f389zZUZctxlLiuxn0Ph0xO89wWVN42RLrum1uPODKsyhHDtMn9D9R3c.F4aXK SONAUW7P8maRu8ntKl3W2rPb9SqclYpZ4knxmG3dpTS1wVsHhgoJe6CzfbYeQmUHmFENRAXg76nn 7IKSp8zzzlnl.br.VyxiRZoye X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 1 Jan 2022 02:20:48 +0000 Received: by kubenode550.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 584fa674c5cff9479f7b1cba09b86d09; Sat, 01 Jan 2022 02:20:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] In-Reply-To: <595C5A0E-B024-46EE-883E-2FCA6ADFE171@yahoo.com> Date: Fri, 31 Dec 2021 18:20:46 -0800 Cc: Dimitry Andric , Ed Maste , freebsd-current , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4FEBC148-25FA-4BDB-BFD3-FDBE8D093B9C@yahoo.com> References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> <5a24eb16-078f-15c5-dcd4-ecef33d15ac7@FreeBSD.org> <03AF30DA-A632-4223-908C-9F5250D82079@yahoo.com> <76FC7AFB-DA78-4A44-BC74-4477C9E11413@yahoo.com> <82BE340A-321C-43F3-AD7B-2E8466ADA17F@yahoo.com> <595C5A0E-B024-46EE-883E-2FCA6ADFE171@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JQm2b4MB1z3l0f X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=cqQVPzK0; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-0.99)[-0.995]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-31, at 18:18, Mark Millard wrote: > On 2021-Dec-31, at 17:46, Mark Millard wrote: >=20 >> On 2021-Dec-31, at 15:04, John Baldwin wrote: >>=20 >>> On 12/31/21 2:59 PM, Mark Millard wrote: >>>> On 2021-Dec-31, at 14:28, Mark Millard wrote: >>>>> On 2021-Dec-30, at 14:04, John Baldwin wrote: >>>>>=20 >>>>>> On 12/30/21 1:09 PM, Mark Millard wrote: >>>>>>> On 2021-Dec-30, at 13:05, Mark Millard = wrote: >>>>>>>> This asks a question in a different direction that my prior >>>>>>>> reports about my builds vs. Cy's reported build. >>>>>>>>=20 >>>>>>>> Background: >>>>>>>>=20 >>>>>>>> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/li= b/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so >>>>>>>> and: >>>>>>>> lrwxr-xr-x 1 root wheel 23 Dec 29 13:17:01 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >>>>>>>>=20 >>>>>>>> Why did libc++.so.1 not get a: >>>>>>>>=20 >>>>>>>> /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 >>>>>>> I forgot to remove the .1 on the left hand side: >>>>>>> /usr/lib/libc++.so -> ../../lib/libc++.so.1 >>>>>>=20 >>>>>> Because for libc++.so we don't just symlink to the current = version of the library >>>>>> (as we do for most other shared libraries) to tell the compiler = what to link against >>>>>> for -lc++, instead we use a linker script that tells the compiler = to link against >>>>>> both of those libraries when -lc++ is encountered. >>>>>=20 >>>>> A better identification of what looks odd to me is the >>>>> path variations in: >>>>>=20 >>>>> # more /usr/lib/libc++.so >>>> Another not great day on my part: That path alone makes >>>> the mix of /lib/ and /usr/lib/ use involved, given the >>>> reference to /lib/libc++.so.1 . That would still be true >>>> if the other path had been /lib/libcxxrt.so . >>>=20 >>> /usr/lib/libc++.so is only used by the compiler/linker when linking = a binary. >>> The resulting binary has the associated paths (/lib/libc++.so.1 and >>> /usr/lib/libcxxrt.so.1) in its DT_NEEDED. So it is fine for the .so = to be >>> in /usr/lib. This is the same with /usr/lib/libc.so vs = /lib/libc.so.7. >>>=20 >>> However, your point about libcxxrt.so.1 is valid. It needs to also = be moved >>> to /lib if libc++.so.1 is moved to /lib. Doing so will also require = yet another >>> depend-clean.sh fixup (well, probably just adjusting the one I added = to >>> check the libcxxrt path instead of libc++ path). >>=20 >> Hmm. Looking (now after having updated so /lib/libc++.so.1 >> is in use, not that this is any different here): >>=20 >> # ls -Tld /lib/libcxx* /usr/lib/libcxx* >> -r--r--r-- 1 root wheel 131656 Dec 31 14:19:49 2021 = /lib/libcxxrt.so.1 >> -r--r--r-- 1 root wheel 355764 Dec 24 15:19:42 2021 = /usr/lib/libcxxrt.a >> lrwxr-xr-x 1 root wheel 23 Dec 31 14:19:49 2021 = /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1 >>=20 >> # more /usr/lib/libc++.so=20 >> /* $FreeBSD$ */ >> GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so ) >>=20 >> So: no actual reference to /usr/lib/libcxxrt.so.1 but >> a reference in the DT_NEEDED to /usr/lib/libcxxrt.so ? >>=20 >> May be just /usr/lib/libc++.so needs different text in order >> for DT_NEEDED to have different text related to libcxxrt in >> future build activities, avoiding /usr/lib/ ? >>=20 >>=20 >> For reference: >>=20 >> # uname -apKU >> FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #27 = main-n252090-5650d340ad66-dirty: Fri Dec 31 06:00:41 PST 2021 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400046 1400046 >>=20 >=20 > In a aarch64 context I looked at an old executable via ldd -a : >=20 > # ldd -a bt > /usr/home/root/c_tests/bt: > libexecinfo.so.1 =3D> /usr/lib/libexecinfo.so.1 (0x41c19000) > libc++.so.1 =3D> /lib/libc++.so.1 (0x42484000) > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x43038000) > libm.so.5 =3D> /lib/libm.so.5 (0x44a4c000) > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /usr/lib/libexecinfo.so.1: > libelf.so.2 =3D> /lib/libelf.so.2 (0x4581e000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x46e4f000) > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /lib/libc++.so.1: > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x43038000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x46e4f000) > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /lib/libcxxrt.so.1: > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x46e4f000) > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /lib/libm.so.5: > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /lib/libelf.so.2: > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) > /lib/libgcc_s.so.1: > libc.so.7 =3D> /lib/libc.so.7 (0x439ce000) >=20 > Looks like something already deals with finding > /lib/libcxxrt.so.1 . But it is not obvious what > path it started with and how much processing was > done (or when) to end up with /lib/libc++.so.1 > showing. >=20 > But there is still a /usr/lib/ reference overall: >=20 > /usr/lib/libexecinfo.so.1 >=20 > But this is because the old program turned out to > be an old experiment: >=20 > # more bt.c=20 > // bt.c > // from releng/12 (12.2?) context (pre-llvm12), but not releng/13 : > // # cc -o bt bt.c -lexecinfo > // # ./bt > // Rerun in llvm12 context, such as main after the switch: crash. >=20 > #include > int main() { > void *addrlist[100]; > backtrace(addrlist, 100); > } >=20 > Although, for some reason, the executable was dated > 2021-Jul-15, not that I remember why I'd rebuilt it > then. >=20 > # file bt > bt: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), = dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.0 = (1400025), FreeBSD-style, with debug_info, not stripped >=20 > nm -a bt shows: That should have referenced: elfdump -a bt | more > entry: 0 > d_tag: DT_NEEDED > d_val: libexecinfo.so.1 >=20 > None of the DT_NEEDED entries had paths shown. >=20 > The only /usr/lib/ reference was: >=20 > entry: 65 > st_name: /usr/lib/crti.o > st_value: 0 > st_size: 0 > st_info: STT_FILE STB_LOCAL > st_shndx: 65521 >=20 > Overall: backtrace requires /usr/lib/ accessibility > for main-n252090-5650d340ad66 in order to access > /usr/lib/libexecinfo.so.1 . >=20 > For reference: >=20 > # uname -apKU > FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #34 = main-n252090-5650d340ad66-dirty: Fri Dec 31 06:30:22 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400046 1400046 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 1 17:00:41 2022 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 1D2DB1937EC2; Sat, 1 Jan 2022 17:01:05 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JR7Z85Xxvz3p8s; Sat, 1 Jan 2022 17:01:04 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f177.google.com with SMTP id 9so6268762ill.9; Sat, 01 Jan 2022 09:01:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tRIqU9tAZy9sHkHmCgmftp3VUs5EGG/qadfgEV8kmGU=; b=ydDCUIdZ42w4DFxFnnXTXZ/s1cdxf8zcQYY7252ZvWtOOgwV53bS1aNqsOnyERFduu iqXt2gJVSuCDoEBNdkCLTTY1bHAqb2aSfszYcq+cbnRgsbo6FA9VPOO5AyJEm3Cpx2BR FHfbDmFqa2jmHopUObWV0Ipsj4ZXtnM2Oug7iPbYE95U6Ky3aQF+3GuNvnEgapvFVMDD GBGfH13O8zO6JX4buIuZyKL11ox5UlU8FYW/DIee6D8l1jhC7PbhA3foQ07Kmx01rNG1 8MrnY21KQ5N7QOrApT/nd7z9mA3d6KN3XoyGjE/2ZPp+BzJRtWvK9ezzGi16FAs2BoAp oHDw== X-Gm-Message-State: AOAM533PImZ6XTSSUeKJGHe7WX+4zyE3Fp2XhgplVwpkII4LG2sLxQWb unxZdPg3EAXgt1v7WOkyEQ0Y8MtL39ajm4DCKQueFMG2 X-Google-Smtp-Source: ABdhPJw8JLPi4cReQt7X6RN5zSrykwE/LYtKfSx8yO2+EVC6/CfZ9x2IbaZLXN3nxkcMMK6rwVLzpDjGHpl47Dof9/U= X-Received: by 2002:a05:6e02:1541:: with SMTP id j1mr19020342ilu.7.1641056457549; Sat, 01 Jan 2022 09:00:57 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> <5a24eb16-078f-15c5-dcd4-ecef33d15ac7@FreeBSD.org> <03AF30DA-A632-4223-908C-9F5250D82079@yahoo.com> <76FC7AFB-DA78-4A44-BC74-4477C9E11413@yahoo.com> In-Reply-To: From: Ed Maste Date: Sat, 1 Jan 2022 12:00:41 -0500 Message-ID: Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] To: John Baldwin Cc: Mark Millard , Dimitry Andric , freebsd-current , "dev-commits-src-main@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JR7Z85Xxvz3p8s X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 31 Dec 2021 at 18:04, John Baldwin wrote: > > However, your point about libcxxrt.so.1 is valid. It needs to also be moved > to /lib if libc++.so.1 is moved to /lib. libcxxrt.so.1 has always been in /lib. From nobody Sat Jan 1 18:44:04 2022 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 3F2A7191BE7B; Sat, 1 Jan 2022 18:44:24 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JR9sM05Twz4X1r; Sat, 1 Jan 2022 18:44:23 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-pf1-x433.google.com with SMTP id u20so26017641pfi.12; Sat, 01 Jan 2022 10:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jr2PDLGqCk4ULqMmc0+XMQFSOsaE48vQGp3vxVsgSzs=; b=mykzB9epAA6hOcCbOZ86gsZ1r/EzN81uYugsyJNTnomT4cveW/9MdtYKqXOn2DqBOu wKpoMTr5fxITww0YWKXvedPdMQtFpvSnc+V6sWEU1bd5T8+zUh4vp36H3Bj8+NINkKUN hv1BxUjz6w6mWVt6Iw6wUkpGaiQ6HLL+RDBNfYywfpvc7JRWBQ9HWs72aUEXfkRfH7qv Ec8l2TROXK01ow39ZJRufRCNrWrSzyO8A6BtoQnM1FcwB6yvEKuAizXOWAmudVqTuqS5 UJTm5dJ/uBvBY0X7Eu0JFRYzg56BB5op7nkQhpLpoRR+M0+ygoMpUe/PGWXCFGXIJNbJ /AQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jr2PDLGqCk4ULqMmc0+XMQFSOsaE48vQGp3vxVsgSzs=; b=ZIfgnpuVO/fTJraaFio+zaG5f0ltcfnTTtJ75ndtjJGhHb6HAXreryWoWY5G4hYp7P CzBPUOQG/8lqI1EliqL2VeVbmld/mfYETGu6k6Mlu8bBHC28a7IDzRSjxDPcnv60qsE0 BUy+Smv1DIyMPMZqxqPSTNyasLm6SGsSb3Tn9qjWp+C8I6tF3pyxVNH+pSTQxiE9HzOL Avlen6QXvxp0qEbaM7obYcKSJ2eaQ4goVEvRC5x6oxcWQcx3Hljq0e4VDr8mvxMR3DYg wK09HV++ZT/QI6I/6YVli2BP+O9zs4ZpeJOyAoBoLi7n9EEx8QId79kH3CF3lH6/25MQ VeJg== X-Gm-Message-State: AOAM531M7HLdhghCe5Q4EZWQxQCkMARTdL+W44efTErbGqssFEd+bId/ XeHrCD7z/rxmuphm2eqFA7Qu0S3ySychOGvL8i/I4hZZ X-Google-Smtp-Source: ABdhPJz28XRsjRMdRBSgzCXnBu6j2tTQnAPrZ7sjcjyJvoBfuPvTUYFwTJ+fNfNW08gJ89mHmudJoG9wwkjvt/q0wbc= X-Received: by 2002:aa7:88ce:0:b0:4ba:efec:39e0 with SMTP id k14-20020aa788ce000000b004baefec39e0mr40355891pff.80.1641062656263; Sat, 01 Jan 2022 10:44:16 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <02d9ca2a-2fd7-942b-f411-be007ef88327@FreeBSD.org> In-Reply-To: <02d9ca2a-2fd7-942b-f411-be007ef88327@FreeBSD.org> From: Ryan Stone Date: Sat, 1 Jan 2022 13:44:04 -0500 Message-ID: Subject: Re: schedgraph.d experience, per-CPU buffers, pipes To: Andriy Gapon Cc: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JR9sM05Twz4X1r X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mykzB9ep; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2607:f8b0:4864:20::433 as permitted sender) smtp.mailfrom=rysto32@gmail.com X-Spamd-Result: default: False [-2.08 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.92)[0.924]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::433:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N I've definitely experienced the issue about different buffers rolling over faster than others and producing confusing schedgraph data. I'm away from home this week, but I believe that I have a script that tries to chop off the schedgraph data at the point where the most recent CPU to roll over has no more data. If I think of it I'll try to pass it along. Another issue that I remember encountering is that there is a limitation on the total amount of space that you can allocate to dtrace buffers and it does not scale to the number of CPUs in the system, so the more CPUs that you have, the less buffer you can allocate per CPU. I seem to recall that the limit being very small compared to the amount of memory on a modern large core count system. On Fri, Dec 24, 2021 at 8:08 AM Andriy Gapon wrote: > > > I would like to share some experience or maybe rather a warning about using > DTrace for tracing scheduling events. Unlike KTR which has a global circular > buffer, DTrace with bufpolicy=ring uses per-CPU circular buffers. So, if there > is an asymmetry in processor load, the buffers will fill and wrap-around at > different speeds. In the end, they might have approximately equal numbers of > events but those may cover very different time intervals. So, some additional > post-processing is required to find the latest event among first ones of each > per-CPU buffer. Any traces from before that would have information gaps > ("missing" processors) and would be very confusing. > > Also, I noticed that processes passing a lot of data through pipes produce a lot > of scheduling events as they seem to get blocked and unlocked every few > microseconds (on a modern performant system with the default pipe sizing > configuration). That contributes to a quick wrap-around of circular buffers. > > -- > Andriy Gapon > From nobody Sun Jan 2 08:46:17 2022 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 2A4441925BA1 for ; Sun, 2 Jan 2022 08:46:28 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JRXXz2Pvkz3k08 for ; Sun, 2 Jan 2022 08:46:27 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id o3so5918827wrh.10 for ; Sun, 02 Jan 2022 00:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:from :subject:content-transfer-encoding; bh=iGlXbzb5vl3A/YkPn9zsVbI+FPPASaxzstjtCYjXdQI=; b=kOn+g9i2898TZEBalbN3U2nI0DkUMkFUmzIQq5N/j8u0KdpRm37jEL2D7wE39css+P PHkFB/cDORJOzxDq9OuBcEgNgvVzRvLx1g469mDuFNSBvjBO/HOrtA/EQqLSuYj1g6ym PcUAQgYP85QbsUrGmjbBMgc3RMkMVH7JGqua2Nm5JHyWfRyj+QW4ByOovWiJTAla44Qh UpoVxhp1AvA5YGjQcWJ3WQlKeAQbNc6D1VWpS3R4JshbTptb+v64j8s8lDjgrfRksyF6 F3v3VkWRu1wC+cUsdZbCnECtiSZuH4BUjhrb0rEpptp8hTQQjIHhN233DNZ5q/9KQKhS vZ5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:content-transfer-encoding; bh=iGlXbzb5vl3A/YkPn9zsVbI+FPPASaxzstjtCYjXdQI=; b=KqSWQ9p5rjenFKKt83SR/BjBdMyKEcwG8GU9pri0QjtRTaryhc2bKE42XhoxQ8jTCW DCB81wb3FD53z5rmdq+5XtKxTfExf/QO5FORhqS3Bq7eJt+b6WU6NE2rFRBMRexksMxw yAzHt1ECrYg323Cv8ySxICIR0JExFNqrvtC2YQU335ziMZAcMLibTxerE7lSiuYRk8lp mfJ9CffPl2HuN7wn3g5oGEDTRB0vQV/ZoBrL+9wVHwtaJCPWrmqT/LQf6kesPz8gwK+Q MeWrypIpFq3yO4Avxbslmdmaenr/ZoSLSi0Ezk6T1Dvv/tOSsz4sr3lLx3dl8+qwYZ/O 9O7w== X-Gm-Message-State: AOAM533BYCx8IM+886UiiIyc20B7Z83g3P01cNI/MJFpQndrIsn4UudE RbMZTrrX7ktLApA3z3XpgeibGcEOXIM= X-Google-Smtp-Source: ABdhPJxKFLPvRYbQ+6zDgHJdb8VikYBPtIo+XVUGF55q0aJXhfTZpzvmQqTZDQzX4FrbahHf/ictWQ== X-Received: by 2002:a5d:4c48:: with SMTP id n8mr34333738wrt.25.1641113179573; Sun, 02 Jan 2022 00:46:19 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id b19sm36294547wmb.38.2022.01.02.00.46.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Jan 2022 00:46:18 -0800 (PST) Message-ID: <45df268e-5308-e983-b4be-81e32dcca598@gmail.com> Date: Sun, 2 Jan 2022 08:46:17 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-GB To: FreeBSD CURRENT From: Graham Perrin Subject: main-c572-g82397d791 from January 2021 X-Priority: 5 (Lowest) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JRXXz2Pvkz3k08 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=kOn+g9i2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.73 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.75)[-0.748]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from]; HAS_X_PRIO_FIVE(0.00)[5]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N The version string at the time: FreeBSD 13.0-CURRENT #75 main-c572-g82397d791: Sun Jan  3 20:00:09 GMT 2021 finds nothing. currently takes me to around 2021-01-03, with the first on the 3rd. Should I assume that it will be impossible, or unreasonably difficult, to identify, in cgit, the exact commit that related to g82397d791? (I know, it was not long after the transition to Git.) TIA From nobody Sun Jan 2 10:03:00 2022 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 9ACC51924F42 for ; Sun, 2 Jan 2022 10:03:10 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (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 "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JRZFT4ZXMz3svQ for ; Sun, 2 Jan 2022 10:03:09 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Sun, 02 Jan 2022 11:03:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1641117788; bh=uFopU3TAvlR3xMLEhJkQkh3XA2wkEz+wytnQfhrqPtY=; h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type; b=XruuuuN3GreRafjxjXH7LEhrlrLdtlittLmc948qbPg+sErkbTGNlS7PwPndfCkaZ 8eSYJ8g0iauqP5PcjuYAq+4IgC5Hot6EDqRkvHvREL9xjK54gR8cIVWM70L/3pJYKQ fd8QBi5HHlcR1hPcYqbXwk4Ai3cv6ArnGokAkjN8J4mRCvegsW1m+j6vNXpgQ5212p R9a8oUSqN4q194HR67TwtcJ594YNkjKhsiStrMMbUuuiUMl59YsRaTV6J4gGKIl9hB dnrgVNHHUT1heic+V0t5VJHr0wY90pvAHBJ3dJ0IWg71mHz2pGXDZRZBpHeJqih0O3 ape9rMh0gfDWw== Message-ID: <87k0fiihez.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: freebsd-current@freebsd.org Subject: Re: main-c572-g82397d791 from January 2021 In-Reply-To: <45df268e-5308-e983-b4be-81e32dcca598@gmail.com> References: <45df268e-5308-e983-b4be-81e32dcca598@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/29.0 Mule/6.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 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JRZFT4ZXMz3svQ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=mail202005 header.b=XruuuuN3; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at X-Spamd-Result: default: False [-2.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gojira.at]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[gojira.at:+]; NEURAL_HAM_SHORT(-0.99)[-0.985]; MID_CONTAINS_FROM(1.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE] X-ThisMailContainsUnwantedMimeParts: N On Sun, 02 Jan 2022 09:46:17 +0100, grahamperrin@gmail.com wrote: > = > The version string at the time: > = > FreeBSD 13.0-CURRENT #75 main-c572-g82397d791: Sun Jan=A0 3 20:00:09 = GMT 2021 > = > finds n= othing. > = > currently takes me to= > around 2021-01-03, with > > the first on the 3rd. > = > Should I assume that it will be impossible, or unreasonably difficult= , > to identify, in cgit, the exact commit that related to g82397d791? > = > (I know, it was not long after the transition to Git.) I think you are loooking for commit 82397d791: commit 82397d791966b09d344251bc709cd9db2b3a1902 Author: Mateusz Guzik Date: Fri Jan 1 04:10:12 2021 +0100 vfs: denote vnode being a mount point with VIRF_MOUNTPOINT = Reviewed by: kib (previous version) Differential Revision: https://reviews.freebsd.org/D27794 The 'g' was removed in 8a51f14a7833fd14e1f125e63a0af9d260dcd287. -- Herbert From nobody Sun Jan 2 14:01:14 2022 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 78B36192869D for ; Sun, 2 Jan 2022 14:01:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JRgXT2r6mz4qR7 for ; Sun, 2 Jan 2022 14:01:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92e.google.com with SMTP id v12so42048313uar.7 for ; Sun, 02 Jan 2022 06:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=isHCjn9Py00vU150vi+zzSmpA4YYmfRXU7mRrLNTIAw=; b=ehjgAX9gEzOrsQ9+X96/5BKGQCShqlExma5IEKvYPCTydphbKsU5Pzupe8EE3S2KC9 DRDLcxkgstpYv7kfviXwrSvY4YriU0EHsSKKdofSiVGxKtls+JJpVh6LEHyKWq1F+3mc q51AFhRYz/Ox+zaJeV8DDvKgaz2vef+T66keOZ0oVcBGUxPoX38p9TdbnOf8gtE9NvAy ccr7Q8YGiJMP7UPrCiiMrgiciSl7UhQiQcPia8JNb3FovWf8oYAe5e6lM+PfrsnI8ZmY lDMWfb+ELHSo4jTeHYcb8RZ7RkuUH9P0V3RpqZz3ZX1l0s3dtPU62c82hny2wMo4Dj16 0ofA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=isHCjn9Py00vU150vi+zzSmpA4YYmfRXU7mRrLNTIAw=; b=IU+wr6X/8A0QCpvpRCpxvSmMsrLC15bdIP2yw8FtTcV8Bi0VjlaIA4HOCkJel66cVE TRfRwGwY+TQ4wIDFs/k++R39q2DUeDDvd7GoyTKLjhLnieSRKQhoreUYkeMoGQCs5z1I ViJDJOq7o2V7wAIBkG3glcf4nh4lH4B04ghh7vy3Q8QFxrMqozdfaug4fRccx+3FNQm8 tosgxFi6Qk7Wl55JR85e4/xY07kKEdaGh2Svx4p8CgANwITlOMFv4jEkBBASxYvfaPS2 fD/69jTkm5y+uv6jS/YcAz7BfaWHEnZcPDwBQZb+m0VcQ8XoZjrs5QaxObDWD1DTCjrT 984Q== X-Gm-Message-State: AOAM531IJjgfOhJmLX3YPaExb+x0KBv3aI9O/fjX2x3ZR37vvPsQ7sZ4 5ENO0xSfr0Z7AouDPJh5dz/plCWc4AS0yRGzz7aWO0NHgbQ= X-Google-Smtp-Source: ABdhPJxk2f4Yrx+wQJKthNorXAIClJPzT/n0amI7k4N1Llz3uBg+ypaaSsBnxiwIAGrNpPT0SQ1vMutVncmYXFCUKMM= X-Received: by 2002:a05:6102:ec2:: with SMTP id m2mr13030593vst.6.1641132083198; Sun, 02 Jan 2022 06:01:23 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <45df268e-5308-e983-b4be-81e32dcca598@gmail.com> <87k0fiihez.wl-herbert@gojira.at> In-Reply-To: <87k0fiihez.wl-herbert@gojira.at> From: Warner Losh Date: Sun, 2 Jan 2022 07:01:14 -0700 Message-ID: Subject: Re: main-c572-g82397d791 from January 2021 To: "Herbert J. Skuhra" Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000d9542605d499d69d" X-Rspamd-Queue-Id: 4JRgXT2r6mz4qR7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000d9542605d499d69d Content-Type: text/plain; charset="UTF-8" On Sun, Jan 2, 2022, 3:03 AM Herbert J. Skuhra wrote: > On Sun, 02 Jan 2022 09:46:17 +0100, grahamperrin@gmail.com wrote: > > > > The version string at the time: > > > > FreeBSD 13.0-CURRENT #75 main-c572-g82397d791: Sun Jan 3 20:00:09 GMT > 2021 > > > > finds nothing. > > > > currently takes me to > > around 2021-01-03, with > > < > https://cgit.freebsd.org/src/commit/?id=c98a764c681f8b70812a9f13a6e61c96aa1a69d2 > > > > the first on the 3rd. > > > > Should I assume that it will be impossible, or unreasonably difficult, > > to identify, in cgit, the exact commit that related to g82397d791? > > > > (I know, it was not long after the transition to Git.) > > I think you are loooking for commit 82397d791: > > commit 82397d791966b09d344251bc709cd9db2b3a1902 > Author: Mateusz Guzik > Date: Fri Jan 1 04:10:12 2021 +0100 > > vfs: denote vnode being a mount point with VIRF_MOUNTPOINT > > Reviewed by: kib (previous version) > Differential Revision: https://reviews.freebsd.org/D27794 > > > The 'g' was removed in 8a51f14a7833fd14e1f125e63a0af9d260dcd287. > Yes. It was too confusing and was only in place a short time. Warner -- > Herbert > > --000000000000d9542605d499d69d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jan 2, 2022, 3:03 AM Herbert J. Skuhra <herbert@gojira.at> wrote:
On Sun, 02 Jan 2022 09:46:17 +0100, gra= hamperrin@gmail.com wrote:
>
> The version string at the time:
>
> FreeBSD 13.0-CURRENT #75 main-c572-g82397d791: Sun Jan=C2=A0 3 20:00:0= 9 GMT 2021
>
> <https://cgit.free= bsd.org/src/log/?qt=3Drange&q=3Dg82397d791> finds nothing.
>
> <https://cgit.freebsd.org/src/log/?o= fs=3D15763> currently takes me to
> around 2021-01-03, with
> <https://cgit.freebsd.org/src/commit/?id=3Dc98a764c681f8b70812a9f13a6e61c9= 6aa1a69d2>
> the first on the 3rd.
>
> Should I assume that it will be impossible, or unreasonably difficult,=
> to identify, in cgit, the exact commit that related to g82397d791?
>
> (I know, it was not long after the transition to Git.)

I think you are loooking for commit 82397d791:

commit 82397d791966b09d344251bc709cd9db2b3a1902
Author: Mateusz Guzik
Date:=C2=A0 =C2=A0Fri Jan 1 04:10:12 2021 +0100

=C2=A0 =C2=A0 vfs: denote vnode being a mount point with VIRF_MOUNTPOINT
=C2=A0 =C2=A0 Reviewed by:=C2=A0 =C2=A0 kib (previous version)
=C2=A0 =C2=A0 Differential Revision:=C2=A0 https://revi= ews.freebsd.org/D27794


The 'g' was removed in 8a51f14a7833fd14e1f125e63a0af9d260dcd287.

Yes= . It was too confusing and was only in place a short time.=C2=A0=C2=A0

Warner=C2=A0

--
Herbert

--000000000000d9542605d499d69d-- From nobody Mon Jan 3 08:25:05 2022 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 339B91934EAC for ; Mon, 3 Jan 2022 08:25:23 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JS82B3zF2z4ZHQ for ; Mon, 3 Jan 2022 08:25:22 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: by mail-oi1-x22b.google.com with SMTP id v6so53948753oib.13 for ; Mon, 03 Jan 2022 00:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=MbFYdyaljAKr4e0MRm3wslbR1gykMAssfNCb3aH4XYc=; b=SpkhTur9pGbr2oqDXIAts3MZxCAh1eBCEw8UKamMo6aSWia7oSLIu4R3/IreWZexkv lxnV0zQ1SjT4pp+gqT7cZdRglj8pU1z0ycdeKcwWdjHNdyC7fK/V7lS3UNmihJi0lyYA W0P23EBH6glxlD27SQ9QR9QTadcW9c6Cg4j4/UJ7MwwW5qfR8lutBDAObLRYWfU3IVSB nyb6yawf8aWWJHkfXK9FK7FDZurlw4t4UiY3LyMI79G7tb1KKLXehlasntdvV1qMjmAf 4EvdskWMGhQP71KYZha+6N+uHyI6aGptMi1M3FF5xPa8uWseBdLqmolcmK2wCMgGajWM YqVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MbFYdyaljAKr4e0MRm3wslbR1gykMAssfNCb3aH4XYc=; b=Yvw5BYJWCMgbgmwYkvRrLOARx5ZQ7oKgUCoooYTlGra3vwzbQKnZYsiu4F0v8T/eG2 kdhQwqd+x1lfn54MA+84OoeFGk+2v8zYF2azb71z+MJlHfErRLtyGqlNFVQ7qBKPhaLB clOQ512KYVG+FAiqEqGxi2jE+0H51lwjhcwvSDSTnkQBap8xdzPMNIm5DcRUwICNLE9F VJvwLps7q83oCLSZq0VNwsL2GKTYUHN7pk/mUQEKJy3taGcWjJDeB4hh/hXDS5tPl9Yk UKgQbwdLM4uHK/43WByr6Hw+ID9u68t7yC6NabeIGPyDdiy+UEqHbAXx7UbLZtZPUSbo VjTA== X-Gm-Message-State: AOAM533Yk5jBKxsAzXeFuv+03T8touo9qyIsUIywFAcJhZcolz2wRo8s E5Eu+6ZmxaHY/c6G8MCR3yXsxXFvmU5n2cP7qeBxouJ15wk= X-Google-Smtp-Source: ABdhPJzBhCMQmWdFvejpFKEZE211kdvNHZi91BM+pM5IxAqk+VocGYgW1zFBuNODKk36q5o7V9LjuO/GQSxpNA5+gpA= X-Received: by 2002:aca:1204:: with SMTP id 4mr33922655ois.136.1641198316702; Mon, 03 Jan 2022 00:25:16 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Maurizio Vairani Date: Mon, 3 Jan 2022 09:25:05 +0100 Message-ID: Subject: Lenovo ThinkPad T450 panic in vm_freelist_rem() To: freebsd-current Content-Type: multipart/alternative; boundary="000000000000ac4de805d4a942d9" X-Rspamd-Queue-Id: 4JS82B3zF2z4ZHQ X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=SpkhTur9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of maurizio1018@gmail.com designates 2607:f8b0:4864:20::22b as permitted sender) smtp.mailfrom=maurizio1018@gmail.com X-Spamd-Result: default: False [1.65 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_SHORT(0.67)[0.675]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22b:from]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_SPAM_LONG(0.98)[0.978]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000ac4de805d4a942d9 Content-Type: text/plain; charset="UTF-8" Hello and happy new year. The laptop is running: > uname -a FreeBSD NomadBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 e9016c0be: Sun Jan 2 04:27:33 CET 2022 root@NomadBSD:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 The backtrace command shows: #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=textdump@entry=0) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff804c590a in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:575 #3 0xffffffff804c57c2 in db_command (last_cmdp=, cmd_table=, dopager=dopager@entry=1) at /usr/src/sys/ddb/db_command.c:482 #4 0xffffffff804c541d in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0xffffffff804c8a56 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:270 #6 0xffffffff80c4e63b in kdb_trap (type=type@entry=3, code=code@entry=0, tf=tf@entry=0xfffffe00fc7ae970) at /usr/src/sys/kern/subr_kdb.c:733 #7 0xffffffff810c695a in trap (frame=0xfffffe00fc7ae970) at /usr/src/sys/amd64/amd64/trap.c:609 #8 #9 kdb_enter (why=0xffffffff812c3774 "panic", msg=) at /usr/src/sys/kern/subr_kdb.c:506 #10 0xffffffff80c00d30 in vpanic (fmt=0xffffffff812b6aa3 "Bad link elm %p next->prev != elm", ap=ap@entry=0xfffffe00fc7aead0) at /usr/src/sys/kern/kern_shutdown.c:908 #11 0xffffffff80c00ac3 in panic (fmt=0xffffffff81e8cea0 "\223\002(\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:844 #12 0xffffffff80f8376a in vm_freelist_rem (fl=0xffffff660cc45778, m=0x80, order=0) at /usr/src/sys/vm/vm_phys.c:390 #13 vm_phys_free_pages (m=0xfffffe0002ad8ac8, order=order@entry=0) at /usr/src/sys/vm/vm_phys.c:1124 #14 0xffffffff80f7b7ac in vm_page_zone_release (arg=, store=0xfffff80001783010, cnt=188) at /usr/src/sys/vm/vm_page.c:2596 #15 0xffffffff80f55a4d in bucket_drain (zone=zone@entry=0xfffffe0019861800, bucket=, bucket@entry=0xfffff80001783000) at /usr/src/sys/vm/uma_core.c:1363 #16 0xffffffff80f50936 in bucket_free (zone=0xfffffe0019861800, bucket=0xfffff80001783000, udata=0x0) at /usr/src/sys/vm/uma_core.c:521 #17 zone_put_bucket (zone=0xfffffe0019861800, zone@entry=0xfffff80001783000, domain=, bucket=0xfffff80001783000, bucket@entry =0xfffffe0105017560, udata=udata@entry=0x0, ws=false) at /usr/src/sys/vm/uma_core.c:904 #18 0xffffffff80f57823 in zone_free_bucket (zone=zone@entry=0xfffffe0019861800, bucket=bucket@entry=0xfffff80001783000, udata=udata@entry=0x0, itemdomain=itemdomain@entry=0, ws=) at /usr/src/sys/vm/uma_core.c:4643 #19 0xffffffff80f51091 in cache_free (zone=zone@entry=0xfffffe0019861800, cache=, udata=udata@entry=0x0, itemdomain=1, itemdomain@entry =0) at /usr/src/sys/vm/uma_core.c:4710 #20 0xffffffff80f4fec8 in uma_zfree_arg (zone=0xfffffe0019861800, item=0xfffffe0007970ca0, item@entry=0xfffffe0007970c38, udata=udata@entry =0x0) at /usr/src/sys/vm/uma_core.c:4514 #21 0xffffffff80f73515 in uma_zfree (zone=0xffffffff81e8cea0 , item=) at /usr/src/sys/vm/uma.h:404 #22 0xffffffff80f7348b in vm_page_free (m=0xffffffff81e8cea0 ) at /usr/src/sys/vm/vm_page.c:1330 #23 0xffffffff80f6d66d in vm_object_terminate_pages (object=0xfffff8012e589108) at /usr/src/sys/vm/vm_object.c:907 #24 vm_object_terminate (object=object@entry=0xfffff8012e589108) at /usr/src/sys/vm/vm_object.c:958 #25 0xffffffff80f6d37d in vm_object_deallocate (object=0xfffff8012e589108) at /usr/src/sys/vm/vm_object.c:693 #26 0xffffffff80f5f309 in vm_map_entry_deallocate (entry=0xfffff8012e5fb420, system_map=0) at /usr/src/sys/vm/vm_map.c:3813 #27 vm_map_process_deferred () at /usr/src/sys/vm/vm_map.c:613 #28 0xffffffff80f66aa9 in _vm_map_unlock (map=, line=4002, file=) at /usr/src/sys/vm/vm_map.c:676 #29 vm_map_remove (map=, map@entry=0xfffffe01056713f0, start=4096, end=) at /usr/src/sys/vm/vm_map.c:4002 #30 0xffffffff80f5edf9 in vmspace_dofree (vm=0xfffffe01056713f0) at /usr/src/sys/vm/vm_map.c:382 #31 vmspace_exit (td=td@entry=0xfffffe0105017560) at /usr/src/sys/vm/vm_map.c:457 #32 0xffffffff80bb2fe8 in exit1 (td=, rval=, signo=signo@entry=0) at /usr/src/sys/kern/kern_exit.c:421 #33 0xffffffff80bb2a8d in sys_exit (td=0xffffffff81e8cea0 , uap=) at /usr/src/sys/kern/kern_exit.c:212 #34 0xffffffff810c771e in syscallenter (td=) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #35 amd64_syscall (td=0xfffffe0105017560, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1191 #36 #37 0x000000080848d1fa in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffe848 I can share the /var/crash directory if needed. Regards -- Maurizio --000000000000ac4de805d4a942d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello and happy new year.

The lapto= p is running:
> uname -a
FreeBSD NomadBSD 14.0-CURRENT Free= BSD 14.0-CURRENT #0 e9016c0be: Sun Jan =C2=A02 04:27:33 CET 2022 =C2=A0 =C2= =A0 root@NomadBSD:/usr/obj/usr/src/amd64.amd64/sys/GENERIC =C2=A0amd64
<= /div>

The backtrace command shows:
#0 =C2=A0__curthre= ad () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 =C2=A0doadump (text= dump=3Dtextdump@entry=3D0) at /usr/src/sys/kern/kern_shutdown.c:399
#2 = =C2=A00xffffffff804c590a in db_dump (dummy=3D<optimized out>, dummy2= =3D<unavailable>, dummy3=3D<unavailable>, dummy4=3D<unavaila= ble>) at /usr/src/sys/ddb/db_command.c:575
#3 =C2=A00xffffffff804c57c= 2 in db_command (last_cmdp=3D<optimized out>, cmd_table=3D<optimiz= ed out>, dopager=3Ddopager@entry=3D1) at /usr/src/sys/ddb/db_command.c:4= 82
#4 =C2=A00xffffffff804c541d in db_command_loop () at /usr/src/sys/ddb= /db_command.c:535
#5 =C2=A00xffffffff804c8a56 in db_trap (type=3D<opt= imized out>, code=3D<optimized out>) at /usr/src/sys/ddb/db_main.c= :270
#6 =C2=A00xffffffff80c4e63b in kdb_trap (type=3Dtype@entry=3D3, cod= e=3Dcode@entry=3D0, tf=3Dtf@entry=3D0xfffffe00fc7ae970) at /usr/src/sys/ker= n/subr_kdb.c:733
#7 =C2=A00xffffffff810c695a in trap (frame=3D0xfffffe00= fc7ae970) at /usr/src/sys/amd64/amd64/trap.c:609
#8 =C2=A0<signal han= dler called>
#9 =C2=A0kdb_enter (why=3D0xffffffff812c3774 "panic= ", msg=3D<optimized out>) at /usr/src/sys/kern/subr_kdb.c:506#10 0xffffffff80c00d30 in vpanic (fmt=3D0xffffffff812b6aa3 "Bad link = elm %p next->prev !=3D elm", ap=3Dap@entry=3D0xfffffe00fc7aead0) at= /usr/src/sys/kern/kern_shutdown.c:908
#11 0xffffffff80c00ac3 in panic (= fmt=3D0xffffffff81e8cea0 <cnputs_mtx> "\223\002(\201\377\377\377= \377") at /usr/src/sys/kern/kern_shutdown.c:844
#12 0xffffffff80f83= 76a in vm_freelist_rem (fl=3D0xffffff660cc45778, m=3D0x80, order=3D0) at /u= sr/src/sys/vm/vm_phys.c:390
#13 vm_phys_free_pages (m=3D0xfffffe0002ad8a= c8, order=3Dorder@entry=3D0) at /usr/src/sys/vm/vm_phys.c:1124
#14 0xfff= fffff80f7b7ac in vm_page_zone_release (arg=3D<optimized out>, store= =3D0xfffff80001783010, cnt=3D188) at /usr/src/sys/vm/vm_page.c:2596
#15 = 0xffffffff80f55a4d in bucket_drain (zone=3Dzone@entry=3D0xfffffe0019861800,= bucket=3D<optimized out>, bucket@entry=3D0xfffff80001783000) at /usr= /src/sys/vm/uma_core.c:1363
#16 0xffffffff80f50936 in bucket_free (zone= =3D0xfffffe0019861800, bucket=3D0xfffff80001783000, udata=3D0x0) at /usr/sr= c/sys/vm/uma_core.c:521
#17 zone_put_bucket (zone=3D0xfffffe0019861800, = zone@entry=3D0xfffff80001783000, domain=3D<optimized out>, bucket=3D0= xfffff80001783000, bucket@entry=3D0xfffffe0105017560,
=C2=A0 =C2=A0 udat= a=3Dudata@entry=3D0x0, ws=3Dfalse) at /usr/src/sys/vm/uma_core.c:904
#18= 0xffffffff80f57823 in zone_free_bucket (zone=3Dzone@entry=3D0xfffffe001986= 1800, bucket=3Dbucket@entry=3D0xfffff80001783000, udata=3Dudata@entry=3D0x0= ,
=C2=A0 =C2=A0 itemdomain=3Ditemdomain@entry=3D0, ws=3D<optimized ou= t>) at /usr/src/sys/vm/uma_core.c:4643
#19 0xffffffff80f51091 in cach= e_free (zone=3Dzone@entry=3D0xfffffe0019861800, cache=3D<optimized out&g= t;, udata=3Dudata@entry=3D0x0, itemdomain=3D1, itemdomain@entry=3D0)
=C2= =A0 =C2=A0 at /usr/src/sys/vm/uma_core.c:4710
#20 0xffffffff80f4fec8 in = uma_zfree_arg (zone=3D0xfffffe0019861800, item=3D0xfffffe0007970ca0, item@e= ntry=3D0xfffffe0007970c38, udata=3Dudata@entry=3D0x0)
=C2=A0 =C2=A0 at /= usr/src/sys/vm/uma_core.c:4514
#21 0xffffffff80f73515 in uma_zfree (zone= =3D0xffffffff81e8cea0 <cnputs_mtx>, item=3D<optimized out>) at = /usr/src/sys/vm/uma.h:404
#22 0xffffffff80f7348b in vm_page_free (m=3D0x= ffffffff81e8cea0 <cnputs_mtx>) at /usr/src/sys/vm/vm_page.c:1330
#= 23 0xffffffff80f6d66d in vm_object_terminate_pages (object=3D0xfffff8012e58= 9108) at /usr/src/sys/vm/vm_object.c:907
#24 vm_object_terminate (object= =3Dobject@entry=3D0xfffff8012e589108) at /usr/src/sys/vm/vm_object.c:958#25 0xffffffff80f6d37d in vm_object_deallocate (object=3D0xfffff8012e58910= 8) at /usr/src/sys/vm/vm_object.c:693
#26 0xffffffff80f5f309 in vm_map_e= ntry_deallocate (entry=3D0xfffff8012e5fb420, system_map=3D0) at /usr/src/sy= s/vm/vm_map.c:3813
#27 vm_map_process_deferred () at /usr/src/sys/vm/vm_= map.c:613
#28 0xffffffff80f66aa9 in _vm_map_unlock (map=3D<optimized = out>, line=3D4002, file=3D<optimized out>) at /usr/src/sys/vm/vm_m= ap.c:676
#29 vm_map_remove (map=3D<optimized out>, map@entry=3D0xf= ffffe01056713f0, start=3D4096, end=3D<optimized out>) at /usr/src/sys= /vm/vm_map.c:4002
#30 0xffffffff80f5edf9 in vmspace_dofree (vm=3D0xfffff= e01056713f0) at /usr/src/sys/vm/vm_map.c:382
#31 vmspace_exit (td=3Dtd@e= ntry=3D0xfffffe0105017560) at /usr/src/sys/vm/vm_map.c:457
#32 0xfffffff= f80bb2fe8 in exit1 (td=3D<optimized out>, rval=3D<optimized out>= ;, signo=3Dsigno@entry=3D0) at /usr/src/sys/kern/kern_exit.c:421
#33 0xf= fffffff80bb2a8d in sys_exit (td=3D0xffffffff81e8cea0 <cnputs_mtx>, ua= p=3D<optimized out>) at /usr/src/sys/kern/kern_exit.c:212
#34 0xff= ffffff810c771e in syscallenter (td=3D<optimized out>) at /usr/src/sys= /amd64/amd64/../../kern/subr_syscall.c:189
#35 amd64_syscall (td=3D0xfff= ffe0105017560, traced=3D0) at /usr/src/sys/amd64/amd64/trap.c:1191
#36 &= lt;signal handler called>
#37 0x000000080848d1fa in ?? ()
Backtrac= e stopped: Cannot access memory at address 0x7fffffffe848

I can shar= e the /var/crash directory if needed.

Regards
--
Maurizio
<= /div>
--000000000000ac4de805d4a942d9-- From nobody Mon Jan 3 16:28:18 2022 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 6E92F192BBF1 for ; Mon, 3 Jan 2022 16:28:31 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSLlf5SDVz4cYG for ; Mon, 3 Jan 2022 16:28:30 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: by mail-oi1-x231.google.com with SMTP id j124so55731374oih.12 for ; Mon, 03 Jan 2022 08:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=B4lFFjFXt2h2OfhSYRqm1jmAjV6ExsImiYexiZ2JlHQ=; b=ZvHXPK/MI7o1uTTmbASP8Dmm+HrjQVJnXSyEI9xRvY2/PRzYK6v3yzUDLWGTL7ZrI2 oBrhigybYfn92J/5vbuyWRnSxBBTj6ORPUF9IrV7QRs1nkDgJyxthJI8cjmcsgrVJNy5 eSwBOoXJBo68lkU6vwf4B8oEDV6NS1AH8jow5e9woa06yjXAvdsbo7QR6wko8TMa6/6K DPc2ftLVP7DJbpEwK/yS3P6xbRSwV2Pv/9FSfhFXslJgNlZlJhmbzF8vjEuo6vSf+1sb ub1uPpbXPH1vTo9WhpDpciJHUQwO6J4AlUiuRBwc8vFMlnK3czFUFHRWRTY9DHpB/YD2 hUdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=B4lFFjFXt2h2OfhSYRqm1jmAjV6ExsImiYexiZ2JlHQ=; b=K2EbhD26pz4YJL6WF1N77cl/UxulxNyswUgxdkkPVtT+C2U6yVrRAvxjQ2KHGXHd6x +TCSn26fR647uTWteaVmXhOlC2Aens0xmG7ge7R1z5HRg/k6Go4IChOIR7VAYBZ8wntJ jDJeRUR2au81e4qrWf2YAi7ia2TdKHuAMTa/81PCWRoCJoJxF2dj4qMhELT7SRG4N7/M iAjDFOzrYz/hQaKJuV48AIbmhWGi/IkWd8LqdQw0KKhx11xZonYizmE/qEfexdhPzBw6 JrUvHftgpFb+73Usk2Q7U6kAQ2cfkJ3shzO6G80Lg3/UAHSLE9iFtKRrlhFWKJyDK3kT gZ8Q== X-Gm-Message-State: AOAM532D5z97/sHQf+aoFJm9UZ2VrJIVGyQqzEIrIuS1IfSf0irjIiho jlquQ5UZZIi7o1P2AtlR/Hj9zIwiTVq49MQQKxilJJGydi8= X-Google-Smtp-Source: ABdhPJx7b0uDrnly91HdGjYlslP0zj0bOlX9JdJqvw5hOiZKsctAxW0yIl4a2+EQmOUoLqEgwBvvCYQW1smQYVzVXqo= X-Received: by 2002:a05:6808:1597:: with SMTP id t23mr35856718oiw.24.1641227310087; Mon, 03 Jan 2022 08:28:30 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Maurizio Vairani Date: Mon, 3 Jan 2022 17:28:18 +0100 Message-ID: Subject: Lenovo ThinkPad T450 panic in vm_page_alloc_check To: freebsd-current Content-Type: multipart/alternative; boundary="000000000000d0445e05d4b00286" X-Rspamd-Queue-Id: 4JSLlf5SDVz4cYG X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="ZvHXPK/M"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of maurizio1018@gmail.com designates 2607:f8b0:4864:20::231 as permitted sender) smtp.mailfrom=maurizio1018@gmail.com X-Spamd-Result: default: False [1.99 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.99)[0.987]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::231:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000d0445e05d4b00286 Content-Type: text/plain; charset="UTF-8" Hello, second panic today. The laptop is running: > uname -a FreeBSD NomadBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 e9016c0be: Sun Jan 2 04:27:33 CET 2022 root@NomadBSD:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 The backtrace command shows: (kgdb) backtrace #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=textdump@entry=0) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff804c590a in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:575 #3 0xffffffff804c57c2 in db_command (last_cmdp=, cmd_table=, dopager=dopager@entry=1) at /usr/src/sys/ddb/db_command.c:482 #4 0xffffffff804c541d in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0xffffffff804c8a56 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:270 #6 0xffffffff80c4e63b in kdb_trap (type=type@entry=3, code=code@entry=0, tf=tf@entry=0xfffffe0107440980) at /usr/src/sys/kern/subr_kdb.c:733 #7 0xffffffff810c695a in trap (frame=0xfffffe0107440980) at /usr/src/sys/amd64/amd64/trap.c:609 #8 #9 kdb_enter (why=0xffffffff812c3774 "panic", msg=) at /usr/src/sys/kern/subr_kdb.c:506 #10 0xffffffff80c00d30 in vpanic (fmt=0xffffffff812a7e39 "page %p has object", ap=ap@entry=0xfffffe0107440ae0) at /usr/src/sys/kern/kern_shutdown.c:908 #11 0xffffffff80c00ac3 in panic (fmt=0xffffffff81e8cea0 "\223\002(\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:844 #12 0xffffffff80f74eb8 in vm_page_alloc_check (m=0x80, m@entry=0xfffffe000e199f90) at /usr/src/sys/vm/vm_page.c:2540 #13 0xffffffff80f74987 in vm_page_alloc_domain_after (object=, object@entry=0xfffff801f7801948, pindex=pindex@entry=27, domain=0, req=, mpred=, mpred@entry=0xfffffe0011ff3a30) at /usr/src/sys/vm/vm_page.c:2075 #14 0xffffffff80f745c4 in vm_page_alloc_after (object=0xfffff801f7801948, pindex=27, req=1, mpred=0xfffffe0011ff3a30) at /usr/src/sys/vm/vm_page.c:1940 #15 vm_page_alloc (object=0xfffff801f7801948, pindex=27, req=) at /usr/src/sys/vm/vm_page.c:1911 #16 0xffffffff80f5a850 in vm_fault_allocate (fs=fs@entry=0xfffffe0107440cb8) at /usr/src/sys/vm/vm_fault.c:1199 #17 0xffffffff80f59396 in vm_fault_object (fs=0xfffffe0107440cb8, behindp=0xfffffe0107440cac, aheadp=0xfffffe0107440cb0) at /usr/src/sys/vm/vm_fault.c:1414 #18 vm_fault (map=, map@entry=0xfffffe0106d96000, vaddr=, vaddr@entry=45983234252800, fault_type=fault_type@entry=2 '\002', fault_flags=, fault_flags@entry=0, m_hold=, m_hold@entry=0x0) at /usr/src/sys/vm/vm_fault.c:1549 #19 0xffffffff80f58ee1 in vm_fault_trap (map=0xfffffe0106d96000, vaddr=vaddr@entry=45983234252800, fault_type=, fault_flags=fault_flags@entry=0, signo=0xfffffe0107440f04, ucode=0xfffffe0107440f00) at /usr/src/sys/vm/vm_fault.c:667 #20 0xffffffff810c6f9d in trap_pfault (frame=frame@entry=0xfffffe0107440f40, usermode=true, signo=, signo@entry=0xfffffe0107440f04, ucode=, ucode@entry=0xfffffe0107440f00) at /usr/src/sys/amd64/amd64/trap.c:850 #21 0xffffffff810c6552 in trap (frame=0xfffffe0107440f40) at /usr/src/sys/amd64/amd64/trap.c:385 #22 #23 0x000029d1a8913b05 in ?? () Backtrace stopped: Cannot access memory at address 0xc91868 I can share the /var/crash directory if needed. Regards -- Maurizio --000000000000d0445e05d4b00286 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, second panic today.
The laptop is running:
&g= t; uname -a
FreeBSD NomadBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 e9016c= 0be: Sun Jan =C2=A02 04:27:33 CET 2022 =C2=A0 =C2=A0 root@NomadBSD:/usr/obj= /usr/src/amd64.amd64/sys/GENERIC =C2=A0amd64
The backtrace command shows= :
(kgdb) backtrace
#0 =C2=A0__curthread () at /usr/src/sys/amd64/incl= ude/pcpu_aux.h:55
#1 =C2=A0doadump (textdump=3Dtextdump@entry=3D0) at /u= sr/src/sys/kern/kern_shutdown.c:399
#2 =C2=A00xffffffff804c590a in db_du= mp (dummy=3D<optimized out>, dummy2=3D<unavailable>, dummy3=3D&= lt;unavailable>, dummy4=3D<unavailable>) at /usr/src/sys/ddb/db_co= mmand.c:575
#3 =C2=A00xffffffff804c57c2 in db_command (last_cmdp=3D<o= ptimized out>, cmd_table=3D<optimized out>, dopager=3Ddopager@entr= y=3D1) at /usr/src/sys/ddb/db_command.c:482
#4 =C2=A00xffffffff804c541d = in db_command_loop () at /usr/src/sys/ddb/db_command.c:535
#5 =C2=A00xff= ffffff804c8a56 in db_trap (type=3D<optimized out>, code=3D<optimiz= ed out>) at /usr/src/sys/ddb/db_main.c:270
#6 =C2=A00xffffffff80c4e63= b in kdb_trap (type=3Dtype@entry=3D3, code=3Dcode@entry=3D0, tf=3Dtf@entry= =3D0xfffffe0107440980) at /usr/src/sys/kern/subr_kdb.c:733
#7 =C2=A00xff= ffffff810c695a in trap (frame=3D0xfffffe0107440980) at /usr/src/sys/amd64/a= md64/trap.c:609
#8 =C2=A0<signal handler called>
#9 =C2=A0kdb_e= nter (why=3D0xffffffff812c3774 "panic", msg=3D<optimized out&g= t;) at /usr/src/sys/kern/subr_kdb.c:506
#10 0xffffffff80c00d30 in vpanic= (fmt=3D0xffffffff812a7e39 "page %p has object", ap=3Dap@entry=3D= 0xfffffe0107440ae0) at /usr/src/sys/kern/kern_shutdown.c:908
#11 0xfffff= fff80c00ac3 in panic (fmt=3D0xffffffff81e8cea0 <cnputs_mtx> "\22= 3\002(\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:844<= br>#12 0xffffffff80f74eb8 in vm_page_alloc_check (m=3D0x80, m@entry=3D0xfff= ffe000e199f90) at /usr/src/sys/vm/vm_page.c:2540
#13 0xffffffff80f74987 = in vm_page_alloc_domain_after (object=3D<optimized out>, object@entry= =3D0xfffff801f7801948, pindex=3Dpindex@entry=3D27, domain=3D0, req=3D<op= timized out>,
=C2=A0 =C2=A0 mpred=3D<optimized out>, mpred@entr= y=3D0xfffffe0011ff3a30) at /usr/src/sys/vm/vm_page.c:2075
#14 0xffffffff= 80f745c4 in vm_page_alloc_after (object=3D0xfffff801f7801948, pindex=3D27, = req=3D1, mpred=3D0xfffffe0011ff3a30) at /usr/src/sys/vm/vm_page.c:1940
#= 15 vm_page_alloc (object=3D0xfffff801f7801948, pindex=3D27, req=3D<optim= ized out>) at /usr/src/sys/vm/vm_page.c:1911
#16 0xffffffff80f5a850 i= n vm_fault_allocate (fs=3Dfs@entry=3D0xfffffe0107440cb8) at /usr/src/sys/vm= /vm_fault.c:1199
#17 0xffffffff80f59396 in vm_fault_object (fs=3D0xfffff= e0107440cb8, behindp=3D0xfffffe0107440cac, aheadp=3D0xfffffe0107440cb0) at = /usr/src/sys/vm/vm_fault.c:1414
#18 vm_fault (map=3D<optimized out>= ;, map@entry=3D0xfffffe0106d96000, vaddr=3D<optimized out>, vaddr@ent= ry=3D45983234252800, fault_type=3Dfault_type@entry=3D2 '\002',
= =C2=A0 =C2=A0 fault_flags=3D<optimized out>, fault_flags@entry=3D0, m= _hold=3D<optimized out>, m_hold@entry=3D0x0) at /usr/src/sys/vm/vm_fa= ult.c:1549
#19 0xffffffff80f58ee1 in vm_fault_trap (map=3D0xfffffe0106d9= 6000, vaddr=3Dvaddr@entry=3D45983234252800, fault_type=3D<optimized out&= gt;, fault_flags=3Dfault_flags@entry=3D0,
=C2=A0 =C2=A0 signo=3D0xfffffe= 0107440f04, ucode=3D0xfffffe0107440f00) at /usr/src/sys/vm/vm_fault.c:667#20 0xffffffff810c6f9d in trap_pfault (frame=3Dframe@entry=3D0xfffffe0107= 440f40, usermode=3Dtrue, signo=3D<optimized out>, signo@entry=3D0xfff= ffe0107440f04,
=C2=A0 =C2=A0 ucode=3D<optimized out>, ucode@entry= =3D0xfffffe0107440f00) at /usr/src/sys/amd64/amd64/trap.c:850
#21 0xffff= ffff810c6552 in trap (frame=3D0xfffffe0107440f40) at /usr/src/sys/amd64/amd= 64/trap.c:385
#22 <signal handler called>
#23 0x000029d1a8913b0= 5 in ?? ()
Backtrace stopped: Cannot access memory at address 0xc91868
I can share the /var/crash directory if needed.

Regards
--<= br>Maurizio
--000000000000d0445e05d4b00286-- From nobody Mon Jan 3 17:27:36 2022 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 BF8271937FCB; Mon, 3 Jan 2022 17:27:38 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSN3t4Mb9z4mVj; Mon, 3 Jan 2022 17:27:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [IPV6:2601:648:8601:8b20:34aa:26b6:b31d:7d5a] (unknown [IPv6:2601:648:8601:8b20:34aa:26b6:b31d:7d5a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id DB596200D8; Mon, 3 Jan 2022 17:27:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Mon, 3 Jan 2022 09:27:36 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?] Content-Language: en-US To: Ed Maste Cc: Mark Millard , Dimitry Andric , freebsd-current , "dev-commits-src-main@freebsd.org" References: <45118DB4-F8C4-4F96-9CAA-5DC5DCFFEB7E@yahoo.com> <3140C5F6-495F-441C-AA6B-542F3BC53B62@yahoo.com> <5F8AF0B2-3AF3-4BE4-B5D1-9030F2605FFD@yahoo.com> <5a24eb16-078f-15c5-dcd4-ecef33d15ac7@FreeBSD.org> <03AF30DA-A632-4223-908C-9F5250D82079@yahoo.com> <76FC7AFB-DA78-4A44-BC74-4477C9E11413@yahoo.com> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641230858; 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=po5HoyMsDz7fZT8LkGf+XHcJBgRX17rVJUK1/tXf7P0=; b=LsHnMIKzEjs22G9w3k20VX8qF8UJkwVyxj/nIB3NoB1PtUmsg3BgARGIax/J1aRVHFIvx0 2E0iRBFv0ZPc7PmohR4cSMq1kZ3FwRyIrTZIWpc3ft1DieroiDVOlBr5SWagOrdQU1yCwP LDEXXh0IBMUKX7eRoLHYehVs0+1HsmJ1I2oso11p4hKzx4ZsFbPVUTUtbaQd1qUNjelENp pU3EHSXWH8RVKsX8UOAEmXECACnXSE0I3k4IgHh72L2Io4jqId+HwRJcTgLBYSU1Vkj5WG U0W7SZPWN0f5kzOLRij9Oq+K507f2oV8IheLJmHzCBvOJyoNObRwhJp+diVTiQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641230858; a=rsa-sha256; cv=none; b=etcFygfE3vJfgXSn/06ylGdTz1a/iuo9e3BcsIEDjIvyNNjTs9W5UT246mI84FKsN3anlY TZ6JPlugfN/DkPJ6mg5s9ladN6nWSzQ74p6uO0jBZ41AK2qRC/M8CbQk7hGhgTAzmir4eA 98mY1BRkKiMiZoKvg5h1o4YAMEqsgrRsS406vaJwUpvD064Kt2hrRpYr6VImpzZHRvjOqW /qCNNB6dcCNejApd12nnvoqHxEXZ9ogWc111gJnX3jHtvIQzwpLLXwYxG9v9O6S3xWt7jz vTsgq/6wNeUEgHJiwR61eSv0hO3UPI1AnjB8Kg0KcWFjpT31qrOAHmZVZ6Uqcg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 1/1/22 9:00 AM, Ed Maste wrote: > On Fri, 31 Dec 2021 at 18:04, John Baldwin wrote: >> >> However, your point about libcxxrt.so.1 is valid. It needs to also be moved >> to /lib if libc++.so.1 is moved to /lib. > > libcxxrt.so.1 has always been in /lib. Oh, I was thrown off by the .so indirection for libcxxrt in the linker script. -- John Baldwin From nobody Mon Jan 3 17:42:48 2022 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 756A0193B772 for ; Mon, 3 Jan 2022 17:43:01 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSNPc4h6pz4qTK for ; Mon, 3 Jan 2022 17:43:00 +0000 (UTC) (envelope-from oleglelchuk@gmail.com) Received: by mail-ua1-x931.google.com with SMTP id o63so58998092uao.5 for ; Mon, 03 Jan 2022 09:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=vbsWIMaOKWwXbc/8o7BkOhBWVVyhKbYmgUf3l9i+L90=; b=QYJTJEXdQauyUYLbw+6NYGbh5nx7o26C0s++11Ewg6L3kTGwOU7W1wqiAvsZEXtNm1 UQRqUhfYwGVDpg2b2qH0HG1LCMTntFZRXIQhMuLGSNGFmwf6CvtIkjmazx5Y4Ca5Y1Ay znq6aDCUfT3vijsPAOG/+ibJo/r15Js1z+81Osrfa4geUj4IK66tb/QaMMa5WTubyZTI 4m6xNsW/sSUpV5cHlZJ42scs7DKPL1paV0UJMOlGgzQiEMX2/bQvwzAiSrmL5uJI21zg 9xRSfRXM7Vltp5JnWSGxvR1YGthbgD6ISko6gG5nmMOMWDOsJqOOVL5GsN+JlEZq1RxP syfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vbsWIMaOKWwXbc/8o7BkOhBWVVyhKbYmgUf3l9i+L90=; b=4bx+hXezW7X2X52cpMvQdVrKIqiAOUToaB2txIOANEMtqiW4zGQR56rq7+Z7XXu2Ni RwkkiAmv+pJHdiPhD6MYEZ6EP9vApNiguak2xgaZkyrxMd7KdbgMNiefaLKZ30qBfXGZ KTLJNHgwOQr71Y2Gpv8L3c+4a+Ko4HDgKDsY17liPrqnCI8+yQdugO98NOKpn6OEmIc8 eaRVnoh+uvi+9qGZ8MfxT2zsfSFd5KCOfQ20GAplRVQAj7Hv2XRC6Te5RGeRVVnpnONC pCX5K06ymyPm1yYcvyo1Xw0b9EceFcdnRH9BfowMG4/3OlKs2fuF1tJhgIyOZ+7VV/iF j7aA== X-Gm-Message-State: AOAM533fwAf20/EijzmG6N14eP3BVSNB/vuBnUk/+E0O2jW8O3LSyFf9 QWeZq6JePnhGwI7SI71HgCZ8wr5HlO7KTwHJcjrA+G1U X-Google-Smtp-Source: ABdhPJxiAZ58ZwPm717o2rW6GVEBDtSKphzvpQfnKdiIERP6pYLaaswb9lUPP6YVEV+xvVIKm1RmADYWqMlpafApliM= X-Received: by 2002:a67:e10c:: with SMTP id d12mr13531520vsl.20.1641231779965; Mon, 03 Jan 2022 09:42:59 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Oleg Lelchuk Date: Mon, 3 Jan 2022 12:42:48 -0500 Message-ID: Subject: 14-CURRENT doesn't like it when kern.vt.splash_cpu is set to 1. To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003d2fcd05d4b10d5e" X-Rspamd-Queue-Id: 4JSNPc4h6pz4qTK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=QYJTJEXd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of oleglelchuk@gmail.com designates 2607:f8b0:4864:20::931 as permitted sender) smtp.mailfrom=oleglelchuk@gmail.com X-Spamd-Result: default: False [0.03 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.972]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::931:from]; NEURAL_HAM_SHORT(-0.95)[-0.946]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000003d2fcd05d4b10d5e Content-Type: text/plain; charset="UTF-8" A 14-CURRENT system completely hangs in both the single and multi-user modes when kern.vt.splash_cpu=1. Did you guys notice it? 13-STABLE doesn't have this problem. --0000000000003d2fcd05d4b10d5e Content-Type: text/html; charset="UTF-8"
A 14-CURRENT system completely hangs in both the single and multi-user modes when kern.vt.splash_cpu=1. Did you guys notice it? 13-STABLE doesn't have this problem.
--0000000000003d2fcd05d4b10d5e-- From nobody Mon Jan 3 18:51:31 2022 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 239FC1924E22 for ; Mon, 3 Jan 2022 18:51:42 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (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 "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSPws2R6Nz3LYm; Mon, 3 Jan 2022 18:51:41 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from [100.64.10.108] (c-141-193-140-252.rev.sailinternet.net [141.193.140.252]) by anubis.delphij.net (Postfix) with ESMTPSA id 00649312A0; Mon, 3 Jan 2022 10:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=m7e2; t=1641235894; x=1641250294; bh=I16Ilhr62pfr4YHpsO/VcdMnqQpWCT0/1/I4EdMjrw8=; h=Date:Reply-To:To:Cc:From:Subject; b=gxSOWU/FTyhnt0Eawhs0/nBlEmlkeHxS0ChMUYP53/JDxgVrW6jG667+h616ZkPLi eJR5ZXkA+wmLfTs5eAI8UdLfTZ5E020jFkQL8hW/gjin/y+PMLLCKCNADcp+6K3vPa Up0Jnjdtr8lOwYBajvMhUixOxcPYKP44KkIkfodrEXRSGRpd62PytkqGqZD0GmXn1R gqZuX3wT+powIFUu3r0a+8BApppvdy+lWakQ+mVhNUxz34BCG6gw/e5hkBvM+gAXxF DFlAqbqyqRedj9lxVCPnn9cm8PY2BNpduAlEA8ghAXIvflhL4t7FqDt7P1m/GCD8YL ZFOQ60re2c2iQ== Content-Type: multipart/mixed; boundary="------------emBi8ePUfEbKBsuUI3TW0MQo" Message-ID: Date: Mon, 3 Jan 2022 10:51:31 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Reply-To: d@delphij.net Content-Language: en-US To: freebsd-current Cc: rmacklem@freebsd.org, "re@FreeBSD.org Engineering Team" Organization: The FreeBSD Project Subject: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2? X-Rspamd-Queue-Id: 4JSPws2R6Nz3LYm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=delphij.net header.s=m7e2 header.b="gxSOWU/F"; dmarc=pass (policy=reject) header.from=delphij.net; spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 64.62.153.212 as permitted sender) smtp.mailfrom=delphij@delphij.net X-Spamd-Result: default: False [-1.43 / 15.00]; HAS_REPLYTO(0.00)[d@delphij.net]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[delphij.net:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; NEURAL_HAM_SHORT(-0.70)[-0.701]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.83)[-0.832]; R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2]; FREEFALL_USER(0.00)[delphij]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Reply-To: delphij@delphij.net From: Xin Li via freebsd-current X-Original-From: Xin Li X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------emBi8ePUfEbKBsuUI3TW0MQo Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Currently, mount_nfs will attempt to use NFSv3 and fallback to NFSv2. The manual page says: nfsv2 Use the NFS Version 2 protocol (the default is to try version 3 first then version 2). Note that NFS version 2 has a file size limit of 2 gigabytes. And the code agrees, too: %%%%%%%% if (trymntmode == V4) { nfsvers = 4; mntvers = 3; /* Workaround for GCC. */ } else if (trymntmode == V2) { nfsvers = 2; mntvers = 1; } else { nfsvers = 3; mntvers = 3; } %%%%%%%% When trymntmode == ANY, which is the default, mount_nfs would attempt NFSv3, and if rpcb_getaddr() returned RPC_PROGVERSMISMATCH, it would try again with trymntmode = V2. Nowadays, it seems that NFSv4 is becoming more and more popular. If a server is providing only NFSv4 service, when mounting without -o nfsv4, the user would receive message like: RPCPROG_MNT: RPC:Timed out A friend of mine who is using TrueNAS core hit this yesterday and his Linux client worked just fine. It took me some time to figure out that the root cause. It seems that modern Linux distributions have been using NFSv4 by default for some time. So I think it makes sense to teach mount_nfs to attempt NFSv4, then NFSv3 and NFSv2. However, this might be a POLA violation and we would like to know if there is any objections. (I've attached a patch but I haven't actually tested it yet). Cheers, --------------emBi8ePUfEbKBsuUI3TW0MQo Content-Type: text/x-patch; charset=UTF-8; name="0001-mount_nfs-Attempt-NFSv4-before-NFSv3-and-NFSv2.patch" Content-Disposition: attachment; filename*0="0001-mount_nfs-Attempt-NFSv4-before-NFSv3-and-NFSv2.patch" Content-Transfer-Encoding: base64 RnJvbSBlYjZlNjAyMzNkODQwZDA3MmQwMjgwMzI1Y2EyY2IzNzQ1NWRjMmYxIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBYaW4gTEkgPGRlbHBoaWpARnJlZUJTRC5vcmc+CkRh dGU6IE1vbiwgMyBKYW4gMjAyMiAxMDo0ODoxNyAtMDgwMApTdWJqZWN0OiBbUEFUQ0hdIG1v dW50X25mczogQXR0ZW1wdCBORlN2NCBiZWZvcmUgTkZTdjMgYW5kIE5GU3YyLgoKLS0tCiBz YmluL21vdW50X25mcy9tb3VudF9uZnMuOCB8ICA2ICsrKy0tLQogc2Jpbi9tb3VudF9uZnMv bW91bnRfbmZzLmMgfCAyOSArKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLQogMiBmaWxl cyBjaGFuZ2VkLCAyMyBpbnNlcnRpb25zKCspLCAxMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1n aXQgYS9zYmluL21vdW50X25mcy9tb3VudF9uZnMuOCBiL3NiaW4vbW91bnRfbmZzL21vdW50 X25mcy44CmluZGV4IDY0OGNiMjEyOGU5MC4uNzQxYjVjMjRhMDgwIDEwMDY0NAotLS0gYS9z YmluL21vdW50X25mcy9tb3VudF9uZnMuOAorKysgYi9zYmluL21vdW50X25mcy9tb3VudF9u ZnMuOApAQCAtMjgsNyArMjgsNyBAQAogLlwiCUAoIyltb3VudF9uZnMuOAk4LjMgKEJlcmtl bGV5KSAzLzI5Lzk1CiAuXCIgJEZyZWVCU0QkCiAuXCIKLS5EZCBKdWx5IDEwLCAyMDIxCisu RGQgSmFudWFyeSAxMCwgMjAyMgogLkR0IE1PVU5UX05GUyA4CiAuT3MKIC5TaCBOQU1FCkBA IC0yMTYsOCArMjE2LDggQEAgVGhpcyBvcHRpb24gcmVxdWlyZXMgdGhlCiAuQ20gbmZzdjQK IG9wdGlvbi4KIC5JdCBDbSBuZnN2MgotVXNlIHRoZSBORlMgVmVyc2lvbiAyIHByb3RvY29s ICh0aGUgZGVmYXVsdCBpcyB0byB0cnkgdmVyc2lvbiAzIGZpcnN0Ci10aGVuIHZlcnNpb24g MikuCitVc2UgdGhlIE5GUyBWZXJzaW9uIDIgcHJvdG9jb2wgKHRoZSBkZWZhdWx0IGlzIHRv IHRyeSB2ZXJzaW9uIDQgZmlyc3QsCit0aGVuIHZlcnNpb24gMywgdGhlbiB2ZXJzaW9uIDIp LgogTm90ZSB0aGF0IE5GUyB2ZXJzaW9uIDIgaGFzIGEgZmlsZSBzaXplIGxpbWl0IG9mIDIg Z2lnYWJ5dGVzLgogLkl0IENtIG5mc3YzCiBVc2UgdGhlIE5GUyBWZXJzaW9uIDMgcHJvdG9j b2wuCmRpZmYgLS1naXQgYS9zYmluL21vdW50X25mcy9tb3VudF9uZnMuYyBiL3NiaW4vbW91 bnRfbmZzL21vdW50X25mcy5jCmluZGV4IGUxZWFmMjA2ZTk4Mi4uZTZkN2UwYWZiZmI3IDEw MDY0NAotLS0gYS9zYmluL21vdW50X25mcy9tb3VudF9uZnMuYworKysgYi9zYmluL21vdW50 X25mcy9tb3VudF9uZnMuYwpAQCAtMTI1LDYgKzEyNSw3IEBAIHN0YXRpYyBlbnVtIG1vdW50 bW9kZSB7CiAJQU5ZLAogCVYyLAogCVYzLAorCVYzb3JWMiwKIAlWNAogfSBtb3VudG1vZGUg PSBBTlk7CiAKQEAgLTc3NywxNSArNzc4LDIxIEBAIG5mc190cnlwcm90byhzdHJ1Y3QgYWRk cmluZm8gKmFpLCBjaGFyICpob3N0cCwgY2hhciAqc3BlYywgY2hhciAqKmVycnN0ciwKIAl9 CiAKIHRyeWFnYWluOgotCWlmICh0cnltbnRtb2RlID09IFY0KSB7CisJc3dpdGNoICh0cnlt bnRtb2RlKSB7CisJY2FzZSBWNDoKKwljYXNlIEFOWToKIAkJbmZzdmVycyA9IDQ7CiAJCW1u dHZlcnMgPSAzOyAvKiBXb3JrYXJvdW5kIGZvciBHQ0MuICovCi0JfSBlbHNlIGlmICh0cnlt bnRtb2RlID09IFYyKSB7Ci0JCW5mc3ZlcnMgPSAyOwotCQltbnR2ZXJzID0gMTsKLQl9IGVs c2UgeworCQlicmVhazsKKwljYXNlIFYzb3JWMjoKKwljYXNlIFYzOgogCQluZnN2ZXJzID0g MzsKIAkJbW50dmVycyA9IDM7CisJCWJyZWFrOworCWNhc2UgVjI6CisJCW5mc3ZlcnMgPSAy OworCQltbnR2ZXJzID0gMTsKKwkJYnJlYWs7CiAJfQogCiAJaWYgKHBvcnRzcGVjICE9IE5V TEwpIHsKQEAgLTc5OSwxMCArODA2LDE0IEBAIG5mc190cnlwcm90byhzdHJ1Y3QgYWRkcmlu Zm8gKmFpLCBjaGFyICpob3N0cCwgY2hhciAqc3BlYywgY2hhciAqKmVycnN0ciwKIAogCQlp ZiAoIXJwY2JfZ2V0YWRkcihORlNfUFJPR1JBTSwgbmZzdmVycywgbmNvbmYsICZuZnNfbmIs CiAJCSAgICBob3N0cCkpIHsKLQkJCWlmIChycGNfY3JlYXRlZXJyLmNmX3N0YXQgPT0gUlBD X1BST0dWRVJTTUlTTUFUQ0ggJiYKLQkJCSAgICB0cnltbnRtb2RlID09IEFOWSkgewotCQkJ CXRyeW1udG1vZGUgPSBWMjsKLQkJCQlnb3RvIHRyeWFnYWluOworCQkJaWYgKHJwY19jcmVh dGVlcnIuY2Zfc3RhdCA9PSBSUENfUFJPR1ZFUlNNSVNNQVRDSCkgeworCQkJCWlmICh0cnlt bnRtb2RlID09IEFOWSkgeworCQkJCQl0cnltbnRtb2RlID0gVjNvclYyOworCQkJCQlnb3Rv IHRyeWFnYWluOworCQkJCX0gZWxzZSBpZiAodHJ5bW50bW9kZSA9PSBWM29yVjIpIHsKKwkJ CQkJdHJ5bW50bW9kZSA9IFYyOworCQkJCQlnb3RvIHRyeWFnYWluOworCQkJCX0KIAkJCX0K IAkJCXNucHJpbnRmKGVycmJ1Ziwgc2l6ZW9mIGVycmJ1ZiwgIlslc10gJXM6JXM6ICVzIiwK IAkJCSAgICBuZXRpZCwgaG9zdHAsIHNwZWMsCi0tIAoyLjM0LjEKCg== --------------emBi8ePUfEbKBsuUI3TW0MQo-- From nobody Tue Jan 4 00:07:47 2022 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 13C43191FC5B for ; Tue, 4 Jan 2022 00:08:10 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSXy14lNKz4qQX; Tue, 4 Jan 2022 00:08:08 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 20407lOq088830; Tue, 4 Jan 2022 09:07:47 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 4 Jan 2022 09:07:47 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: d@delphij.net, rmacklem@freebsd.org, "re@FreeBSD.org Engineering Team" Subject: Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2? Message-Id: <20220104090747.7767144800c564ca2cff43d5@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JSXy14lNKz4qQX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N I myself never used NFS, but I don't think it a POLA violation, because... *Keeping latest-stable (formerly, v3?) to oldest (v2) order. *Usually, once new version is considered stable, security fixes are first done on the latest, then backported to older revs, causing delay. It can cause fatal security incident for servers. So always as newer as possible rev should be always preferred unless no specific rev is specified. But development versions would better not automatically selected. If v4 is already considered as production quality on FreeBSD, it would be best preferred first on automatic selection. On Mon, 3 Jan 2022 10:51:31 -0800 Xin Li via freebsd-current wrote: > Hi, > > Currently, mount_nfs will attempt to use NFSv3 and fallback to NFSv2. > The manual page says: > > nfsv2 Use the NFS Version 2 protocol (the default is to try > version 3 first then version 2). Note that NFS version 2 > has a file size limit of 2 gigabytes. > > And the code agrees, too: > > %%%%%%%% > if (trymntmode == V4) { > nfsvers = 4; > mntvers = 3; /* Workaround for GCC. */ > } else if (trymntmode == V2) { > nfsvers = 2; > mntvers = 1; > } else { > nfsvers = 3; > mntvers = 3; > } > %%%%%%%% > > When trymntmode == ANY, which is the default, mount_nfs would attempt > NFSv3, and if rpcb_getaddr() returned RPC_PROGVERSMISMATCH, it would try > again with trymntmode = V2. > > Nowadays, it seems that NFSv4 is becoming more and more popular. If a > server is providing only NFSv4 service, when mounting without -o nfsv4, > the user would receive message like: > > RPCPROG_MNT: RPC:Timed out > > A friend of mine who is using TrueNAS core hit this yesterday and his > Linux client worked just fine. It took me some time to figure out that > the root cause. It seems that modern Linux distributions have been > using NFSv4 by default for some time. > > So I think it makes sense to teach mount_nfs to attempt NFSv4, then > NFSv3 and NFSv2. However, this might be a POLA violation and we would > like to know if there is any objections. > > (I've attached a patch but I haven't actually tested it yet). > > Cheers, -- Tomoaki AOKI From nobody Tue Jan 4 02:00:12 2022 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 EF9D5191C382 for ; Tue, 4 Jan 2022 02:00:14 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSbRL6RZcz57M9; Tue, 4 Jan 2022 02:00:14 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641261614; 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=8EUCc+i6SmuOqN4LyExhtybnbWcMKHhH69nrLnOCbZ0=; b=jh4+Q1Tf0pr/VDyi9sKy0I6vvGJIVIY40eUzstPitbrFRVjIM/I+UZwqvbDR39BlH5CkRs WN4wYGqStRY3z6jQJW+ISLXDvT8g8vjtoMkKyJSPxoesWAMO9v9IAYl3kfjDWjgO9V6c3n ldKTIU6EirwYC+66kRfASaq7QZg7mXqM53+DRBQ66N1Fg2aJvyXOpLwCRxWH9+F/8dIhSw Q2T7ZoIuwptdpPt1Azgm2DThZuq/7+xkx31EQgKFUx7XWn4JhR2Pq0HhcxwVT+r9DQI6Ba ojpN9x0Iiw7wnKcYb+ZUrfQvZMtznx3Ca4xzeebTsuYgQfCZapaJr2G6w3pmvQ== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 5BAF3179B4; Tue, 4 Jan 2022 02:00:14 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Tue, 4 Jan 2022 02:00:12 +0000 From: Glen Barber To: Colin Percival Cc: d@delphij.net, freebsd-current , rmacklem@freebsd.org, "re@FreeBSD.org Engineering Team" Subject: Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2? Message-ID: <20220104020012.GP14836@FreeBSD.org> References: <0100017e22709d93-0c9ce998-0308-47fc-b4f0-aa4c00d795ea-000000@email.amazonses.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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oNLI4EWr1RPQuPCf" Content-Disposition: inline In-Reply-To: <0100017e22709d93-0c9ce998-0308-47fc-b4f0-aa4c00d795ea-000000@email.amazonses.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641261614; 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=8EUCc+i6SmuOqN4LyExhtybnbWcMKHhH69nrLnOCbZ0=; b=a/B5fYiWu7wllhOTouHE6XFclamskTmpMPtAPhmuLfLRpNdhGySresWrfGAbBeO9Lqbx3r R51hU3TgieQkK+8lc77uerhTqBohL4PMGSGyFJs0FbfuPoKPhAZvNdtYmRWBfOp318kRdR nbjvERUPpQ8dnfWqfMVLaGGrOs8az3WAYkYS7sN77zMor5bnfXet8ZxEiUTCHKaTVyQRvP CdrdQqi48ajT52NOyJ3SoklyWBBNp0jYzivtEi1ZKv0Ti74obo9A430u2v8NodDkr9lNlw Jh3Bz4v/MKzP7CL8X6xGxK+AcSdiX2lwp1kaQxWAu7aDomLdtYmY77AgIQk4Fg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641261614; a=rsa-sha256; cv=none; b=JHaOcjZ0q9awmQCugRrwlYgSXH1wYY0wnI2EWYhwSmIZ0/wrLMMt719JZlO0hHjTkdDLWD +yTQQ6M5Bx6nA/vQ507UIkJVfY9C1McN/gRC7jz3036rdUXLOOJblMFnqTFs39woNh3Icg 7kSXtuAsYpnoqMrV5uRfYDvZSeLWR0AHfCFqF7GVSHXkH+38CQP7StujZUmNyio5ceaCRS 3zrEkKWw4raTCi6Q3DG9PGPq1eC6dSgbcydOptC84e3jlKS/6u7HjouEISXVZ2M6bRv4fJ EQTyvg69UFVVRNtJ82jzww4VRJR8HIW4u7VoyT9Gs3Lbafv/PvLQGot3tf0g0g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --oNLI4EWr1RPQuPCf Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 04, 2022 at 12:15:12AM +0000, Colin Percival wrote: > On 1/3/22 10:51, Xin Li wrote: > > [...] > > So I think it makes sense to teach mount_nfs to attempt NFSv4, then > > NFSv3 and NFSv2.=A0 However, this might be a POLA violation and we would > > like to know if there is any objections. >=20 > This seems like a sensible change of defaults to make in 14-CURRENT; plea= se > add an entry to RELNOTES so that users will be alerted to the change. >=20 > I don't think this should be MFCed. >=20 I am torn on the topic, and would like to hear feedback from others that use NFS (I personally do not, so this change does not affect me). I will agree with whatever is the outcome of the majority. Glen --oNLI4EWr1RPQuPCf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmHTqiwACgkQAxRYpUeP 4pMxeA/+Pk8c6vYA26fcT/6jR7G4Q+hNtZzrMEl4uvBxdh0VWiZmlezKqzsq0BbN PROHNEQRhu3H/eN1T0+VKEEpDAwGhh/TZdbXtxwqRIV9ddwEet06rAB+r4PAexYe JyYSV6fr4sVF/ZZ1fJfGaJFNXocveEcuzX4HLkxjCHwqddkKmsP7V4RwlFjRBKR1 e796YwXtLb6GQwMRTa2pZEagF3Asfg2pwdJWPzYqGtG02/a5ulQlQyQz/BpAQaD5 elzWDqyidheOIeYJcA5NdY0cKNC9kfSIg8iOXkgU1SHLJTuIQKz8Twnf5kc2Mbiz EzsFar8BKibb9pzt9jV3Kc7RmBuHrQ1vmyNcDC+qGCBI5WvqeF/oSRGrHQXdtJJU BBVNU489xeuKdOOSeqiBVxbZF+DFFp3qYo8EEHBtczP3Fz6tbbFC1LckNvB7PQwq nYp+oLhHUlh/4yeQ2OaBCrelJwQQJo6eEzlrhPvCdGNj+xaXMZpHyGxbKht3zLdh zVJRAc8xpBLHjmASzjGl8zuB+qaIC9758zo0YMg0CbQ+p9FhwWuzgCGCk+pLzfVx ysqyMXwA6HvYnuva+u1fFeaH14VsQwNiodwqNIiRmFzXZmn6i1KO/3m2JtkrNv++ fWHGhs4FYYXhH0rb1lp5PSHBfArBLn2aJ24LNRfRIpjsRi04zug= =qC+X -----END PGP SIGNATURE----- --oNLI4EWr1RPQuPCf-- From nobody Tue Jan 4 03:04:46 2022 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 CEC101931AE3 for ; Tue, 4 Jan 2022 03:05:14 +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 4JSctL43Gbz3jjZ; Tue, 4 Jan 2022 03:05:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 20434liE005942 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 4 Jan 2022 05:04:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 20434liE005942 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 20434kGW005939; Tue, 4 Jan 2022 05:04:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 Jan 2022 05:04:46 +0200 From: Konstantin Belousov To: Tomoaki AOKI Cc: freebsd-current@freebsd.org, d@delphij.net, rmacklem@freebsd.org, "re@FreeBSD.org Engineering Team" Subject: Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2? Message-ID: References: <20220104090747.7767144800c564ca2cff43d5@dec.sakura.ne.jp> 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: <20220104090747.7767144800c564ca2cff43d5@dec.sakura.ne.jp> 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=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4JSctL43Gbz3jjZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Tue, Jan 04, 2022 at 09:07:47AM +0900, Tomoaki AOKI wrote: > I myself never used NFS, but I don't think it a POLA violation, > because... > *Keeping latest-stable (formerly, v3?) to oldest (v2) order. > > *Usually, once new version is considered stable, security fixes > are first done on the latest, then backported to older revs, > causing delay. It can cause fatal security incident for servers. > So always as newer as possible rev should be always preferred > unless no specific rev is specified. > > But development versions would better not automatically selected. > If v4 is already considered as production quality on FreeBSD, > it would be best preferred first on automatic selection. > > On Mon, 3 Jan 2022 10:51:31 -0800 > Xin Li via freebsd-current wrote: > > > Hi, > > > > Currently, mount_nfs will attempt to use NFSv3 and fallback to NFSv2. > > The manual page says: > > > > nfsv2 Use the NFS Version 2 protocol (the default is to try > > version 3 first then version 2). Note that NFS version 2 > > has a file size limit of 2 gigabytes. > > > > And the code agrees, too: > > > > %%%%%%%% > > if (trymntmode == V4) { > > nfsvers = 4; > > mntvers = 3; /* Workaround for GCC. */ > > } else if (trymntmode == V2) { > > nfsvers = 2; > > mntvers = 1; > > } else { > > nfsvers = 3; > > mntvers = 3; > > } > > %%%%%%%% > > > > When trymntmode == ANY, which is the default, mount_nfs would attempt > > NFSv3, and if rpcb_getaddr() returned RPC_PROGVERSMISMATCH, it would try > > again with trymntmode = V2. > > > > Nowadays, it seems that NFSv4 is becoming more and more popular. If a > > server is providing only NFSv4 service, when mounting without -o nfsv4, > > the user would receive message like: > > > > RPCPROG_MNT: RPC:Timed out > > > > A friend of mine who is using TrueNAS core hit this yesterday and his > > Linux client worked just fine. It took me some time to figure out that > > the root cause. It seems that modern Linux distributions have been > > using NFSv4 by default for some time. > > > > So I think it makes sense to teach mount_nfs to attempt NFSv4, then > > NFSv3 and NFSv2. However, this might be a POLA violation and we would > > like to know if there is any objections. > > > > (I've attached a patch but I haven't actually tested it yet). The v4 NFS is very different from v3, it is not an upgrade, it is rather a different network filesystem with some (significant) similarities to v3. That said, it should be fine changing the defaults, but you need to ensure that reasonable scenarios, like the changed FreeBSD client mounting from v3-only server, still work correctly. The change should be made in a way that only affects client that connects to the server that has both v4 and v3. From nobody Tue Jan 4 03:18:36 2022 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 844BF19355B8 for ; Tue, 4 Jan 2022 03:18:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670040.outbound.protection.outlook.com [40.107.67.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSd9v247yz3mF5; Tue, 4 Jan 2022 03:18:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GrdeOzXzevKw5ORBA8uENb5W6LYqy0YbveE5a1nRflLwKeVmZHUnJ/EJH5s5ypaWb0M8WjLAXojTbmhQi1eLAlas+S48p43fK47txO/WRDthChl3G5dqUoOFBdwXRWxG6YOOf0lqAWkwezJ/+YBLCZJIUB+xJbmVzt6OvFnz6XEmyg9/igQAiPkKp40pA/Cq2wzYdPb29UPNLnvgLVBfbQ5RtqkMZ7XaQ0wbYp2HMpjF1AFUl2RwTH2UTpbGvJccrWtHXv2pYQU7AUy3bmiyvqo/IfX1ZzZdA3wrt8Uz/GJouO5Fnz/sxEf0GHJumvqfBrb28IKWUdvQH/3zchOYuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A5CqdO/vj/xQl/oZ6rQD+HtcTnA41UzKwCur0DMYrYs=; b=Cw7FzeLhI0IqrIDcjlPvhvEkhmt6V7DsWD3oQp3DO+LbDE0kXklNGQ/R+XUMMtWDCh0UUKnSXf7mCr04ISXoNwuuI07uY4FqW4KwQVf43XjxYHLdzBmU6KrB/gGghZn6mHnKPto+Uj6+ActUP6M+095IavhfXYqZZNH6oPPqmNQ9St01UILMYuzM0p6uVD9Sb7d7bTmQgmW9/s6qgqFyhdUetN9k9f9p/BfAzaWLeLsJQm3KKBRBdVXxChzGtYG9567trm/Z853BYJNj/si3uVdfcYYWVG688nhs7HK4ltukEUROY/dLBZXkJ8IUMlJKSd2BqP/pWwoFdNE2oocaWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A5CqdO/vj/xQl/oZ6rQD+HtcTnA41UzKwCur0DMYrYs=; b=NfEgRt9q6RAlopZ5UeXHSUIFW0HFAYXCNAwF1tmq/sQMX0rOr0mS9chzNIKFyTIjrWu/nngu4IxCu0cnzute2ZSubHw6ZLIrQpsIdSq7pHreZR1nv76r+29fqgKq4MrtfJGINkOgp5A4d9HkUa/h1+MBMcThlZou9w66/nQOliUSNYTsKF8fM6NwdXElGKt4FKN/GzAvTnc7YLedSMTYNs6VMHBfxsBCsSKK0iC+u2ySZe7gTX9qyLfW9x2kMmGgtrtJO5A864Qkw07Hbbug8jIbDETQM8xsTghDtyZuBg5gnbDTvqckM1DxFwtejMh3OwoWDoqcdb5D4g6ljVmxQg== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB8493.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:54::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.14; Tue, 4 Jan 2022 03:18:36 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::50bf:ecf6:9d13:fd03]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::50bf:ecf6:9d13:fd03%4]) with mapi id 15.20.4844.016; Tue, 4 Jan 2022 03:18:36 +0000 From: Rick Macklem To: Konstantin Belousov , Tomoaki AOKI CC: "freebsd-current@freebsd.org" , "d@delphij.net" , "rmacklem@freebsd.org" , "re@FreeBSD.org Engineering Team" Subject: Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2? Thread-Topic: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2? Thread-Index: AQHYANL1J9xN1hLYV0qzjoENtRmZsaxR/I+AgAAxcwCAAAEYZg== Date: Tue, 4 Jan 2022 03:18:36 +0000 Message-ID: References: <20220104090747.7767144800c564ca2cff43d5@dec.sakura.ne.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 3d6ff43d-1866-b10d-4e59-a8c51b6b0069 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 033380ac-091e-455c-628e-08d9cf30e545 x-ms-traffictypediagnostic: YQBPR0101MB8493:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cXR3iTwkIxE28qUB/Va6JA5MmCn6bnVfo+JymMIK/GYQ4ZreT3fQZh3Xl5kvbJFL7CCfqGIBpxl0Nr33QNoG1/qtzagPxbeZJ03ZpJQ2oa4FddYfQUmoWCPKB0y72AoJGAf1uYjL+nY/3FpBpsOUPMQEbl8+xzTorqxxDd4iOEfbioTbXUVrHsTYrWMRzWi4M+GcLjrzALXNR43dnSCUxb6CMIme4xZ8QsWxOMskAE0ytqkglbGdR7hVDwy5v1dcRd3kYu7D3EYv49W6s0iYNJZEht9KXFdzbO0d3f0ZwasMjW0t9D4Og74gIa0HXeTcMwnTbt5rYKNT6bVc1CJVF0jxIniB+SJAHLtpAqF7F4jdpT+VXoLi95Xb73eY0q5Kg45fM6ceiI3FHKUHy7tv7gcXBn4gIGPY0pDYNEabJ4K0844eh0RdjG7ndyxMDNgo/cHlq6rB2yRugOWz1URQKkWyADUCIhO1m6Mc9xMEu/86ZAfqyI2Iw6pPev33Y7ItOfIEDV7u8SCcWdc4raGfCNHN/eavwVsdjHMuKBjy0tsFI58ueKRDWWTQMLqB20QKz8aDXKVfqCNK1AKFTvdTsetcmOeAdfoFYNySKgXgGodFvFWP0jBVayOEEp9LrU3NVd6fF30cIvXXsjDBf1YH1oqbg1MdP0yHskseafpk9rP4bUJiggoF2QlMVTfRkRrNeIyVe2O09Ip7XNui9K+L6w== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(316002)(54906003)(786003)(71200400001)(110136005)(186003)(66446008)(76116006)(91956017)(83380400001)(66556008)(6506007)(2906002)(66476007)(508600001)(5660300002)(64756008)(7696005)(33656002)(86362001)(66946007)(8936002)(8676002)(38100700002)(122000001)(4326008)(9686003)(38070700005)(55016003)(52536014);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Wlnq7OiClng2IFzvGsJWkC2q0nhjY8uPJv5tI+smTULN+kYAl1f/Os33Cq?= =?iso-8859-1?Q?PAK/sFZdyHFTc6iNcWMdDZ3c4HFJCJOeU98j6I6YQ/qqq7LKMHiY2MlVc/?= =?iso-8859-1?Q?81G4+bHibcG6uUKs3nnNQo2fXoZRa5j5la1JoW25Egu+vjYWVOXUGy7Jq9?= =?iso-8859-1?Q?4tTmVCMILxf0vYebkoTV2ycUzwwGQ556yDpKDOltIzSl0XUY11WkBXmxs9?= =?iso-8859-1?Q?S1KqxQ6n1V9BdUMx9j+CSxsqNVNMP4l5eDRoTY3Ho06/4cL/ZsCeuCuyQW?= =?iso-8859-1?Q?CjI8WRNw+EbZPKpZrmz3WQMU1aSWh4LNK+F3nLbbSuGNuusKLjLn90BBV1?= =?iso-8859-1?Q?FlFbUj5vq01WAt7AoIl1dDhGlFOOCImTnr1P6U5RRtwbqTT7hZ8XiEl1GL?= =?iso-8859-1?Q?+efS3m6kTZHU4ThkFgk0AJfUpl3629fbFY+q74gv02VcPNJ/n/CPGNaY1P?= =?iso-8859-1?Q?Dh8oVlzTe6WfEORASEXyS7NPBd0wKK8btYhYER0EnEbp1CBH/1GrQnV2wQ?= =?iso-8859-1?Q?UQ45fhddbzv83Z6X15yfv9QmrLSPZfMG6En6AZHv0kSoVa4khUhvJHPyVy?= =?iso-8859-1?Q?1+88KllRnP7AFLrD0FFv4S+cj58Vbjz0iJ/T/rMK1HO2c4bnPCT5s4S4dC?= =?iso-8859-1?Q?EAaBWKDHe8z1CtA4VLH/G23UrnQO32G8SxydG+KUui/MdOrZmKdoOlLCuL?= =?iso-8859-1?Q?aHSk8etGwYgVsgUO3nK1EkamAndfOMurYOmntv/eLCTRXQLbIgd2AvvxDU?= =?iso-8859-1?Q?v3O3GgLzijCv9jGViacruCUP+k6j9UhIYS7hmdfEVsmaYapKu0TQp3tQAn?= =?iso-8859-1?Q?WneNojF3kFLEPAQ/MOFE4OL/lk4LnBxyTlrUePa1g9mABChZ/LRIkaRXfY?= =?iso-8859-1?Q?VLYM9erNDcWLIVcbbvsojNA4HSjGlOiWLgAz8uHkHYalOaF36LBzlYP/xc?= =?iso-8859-1?Q?AYk9rks1btqzsf3b2fOJBM0x9L0UNQ83uHWrLQhTPG8JogEc9jaMy+G8qj?= =?iso-8859-1?Q?gjGvWKGu9VJTsJaRJE8tEvuAh0RS3GChsF36lkBGmv+I9Gkh2KZ4HRex8E?= =?iso-8859-1?Q?pjDSmpxQs2v117hT7xJDIygviyUe3FZBTp4ft5J0PGp1UqxK+U0sc9Tqxz?= =?iso-8859-1?Q?Ac3zbmfFbAflQrmRga2zJAZwfEwM1ivhUvtxqM0XfJOe738alr5oO1DA4D?= =?iso-8859-1?Q?UoGHHYykTjKdQSOZfliUo2LXRKNYaVvkqU5/r8Po6pTqDZeklEjilHQway?= =?iso-8859-1?Q?JYbvPQyzoSHiyx8sB9K2WbNcOb1Zt6FZJrg4rYcl6pAOM55D7ngpMYEJhh?= =?iso-8859-1?Q?/la88gJcAA9MMcZKbJvrhSvDgEWaUtGT7/Zj9OdvPOaDAXuh9vhUcjQQbn?= =?iso-8859-1?Q?0ORZoG1SMcScjHvY6MEZqCfNojdf6AToHEqdgrnfIoETQNI3Mb/dIevWcG?= =?iso-8859-1?Q?EdffsRvvZcoflWeNu5zSqsVupG0uSkZRNDOYSUpJ1Q11FShbKlIM0rRDKu?= =?iso-8859-1?Q?OdGOpS6CTP5RWNnE0oiWpbWI2Flr4XymjnqE7zrG9dXIa6UAphVtQoRLLI?= =?iso-8859-1?Q?z7YzTRteG30a8QxXGK3aoLivCBTm0QJwVGCS5ZWAhL9/e7vA9YgS3P3/gQ?= =?iso-8859-1?Q?Gc+bor1kFOgJm9sbb3nwYqCzPnPkhsISCYQ8+2+5WcC05vsfCgZ0EtB4FT?= =?iso-8859-1?Q?pv8mcUNmwCLSimsiOf/zIBej2l68l8CXYmVNMNMDCbp70K65K78SibTOZ0?= =?iso-8859-1?Q?1UFA=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 033380ac-091e-455c-628e-08d9cf30e545 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2022 03:18:36.1232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tTMA0YxL9I4F57TCF14RWykqZvVLxeCAPN82v/IgP51c/KyDdms9xXtqdsXmwpDpluEGw1GrE8NfphdAUC2i/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB8493 X-Rspamd-Queue-Id: 4JSd9v247yz3mF5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Konstantin Belousov wrote:=0A= [good stuff snipped]=0A= > The v4 NFS is very different from v3, it is not an upgrade, it is rather= =0A= > a different network filesystem with some (significant) similarities to v3= .=0A= >=0A= > That said, it should be fine changing the defaults, but you need to ensur= e=0A= > that reasonable scenarios, like the changed FreeBSD client mounting=0A= > from v3-only server, still work correctly. The change should be made in = a=0A= > way that only affects client that connects to the server that has both=0A= > v4 and v3.=0A= A particular test case that needs to be done is the diskless NFS root fs.= =0A= This case must use NFSv3 and if it is not the default, it might break?=0A= I am not really set up to test this at this time.=0A= (There are assorted reasons that NFSv4 does not, or at least might not,=0A= work for a diskless root fs, but that is a separate topic.)=0A= =0A= Other than testing diskless NFS root file systems, I do not have a=0A= strong opinion w.r.t. whether the default should change.=0A= =0A= If the default stays as NFSv3, a fallback to NFSv4 could be done, which=0A= would handle the NFSv4 only server case. (No one uses NFSv2 any more,=0A= so the fallback to NFSv2 is almost irrelevant, imho.)=0A= =0A= rick=0A= =0A= From nobody Tue Jan 4 06:42:39 2022 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 8D2721936DFC for ; Tue, 4 Jan 2022 06:42:56 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSjjW3CFGz4m5F for ; Tue, 4 Jan 2022 06:42:55 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165022.dip0.t-ipconnect.de [91.22.80.34]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) client-signature ECDSA (P-256)) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 1C67A296E9 for ; Tue, 4 Jan 2022 07:42:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1641278565; 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=d9MsxELQ/6VV7cLZdMvY10RtcZt8h3PO96DpPu3K5Tk=; b=o5EQNXk7RzyzB/pfhAlZLrqF6ARFepaUYTI2D4hPkf8relZiAvwiAmfDFBnmFUoxKZtluK G6xg0b59fSceNdUVf8hTD2laaDqg8fh2FB3cT5CoeSicHOOIBXnKo8FW5dj1/l6StcpZob A16slW/+PM2g90+q5fOUWhDI0JnUL+BR78PcG7ohNHwMmPTXgBEnYF2d/qGH/MPQizLq6T /Dhkh81ojSqBBkn3InG+iPxsooSavLiJYrUqFOoFTOdP81ua91LjljMPVBBWQMsBopk4sn FbIOzNVv2RQ3Soh49NCsuJ+/VupnoZAKazK5dmm14RIaEKcbYz6ic2IlO30LDQ== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 9AE2865F5 for ; Tue, 4 Jan 2022 07:42:39 +0100 (CET) Date: Tue, 04 Jan 2022 07:42:39 +0100 Message-ID: <20220104074239.Horde.lTehmFlQWMv_N_QIcF1h1Wq@webmail.leidinger.net> To: freebsd-current@freebsd.org Subject: Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2? References: <20220104090747.7767144800c564ca2cff43d5@dec.sakura.ne.jp> In-Reply-To: Accept-Language: de,en Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes 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-Disposition: inline X-Rspamd-Queue-Id: 4JSjjW3CFGz4m5F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=o5EQNXk7; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-2.67 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-0.67)[-0.670]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.80.34:received] Reply-To: Alexander@leidinger.net From: Alexander Leidinger via freebsd-current X-Original-From: Alexander Leidinger X-ThisMailContainsUnwantedMimeParts: N Quoting Rick Macklem (from Tue, 4 Jan 2022 03:18:36 +0000): > Konstantin Belousov wrote: > [good stuff snipped] >> The v4 NFS is very different from v3, it is not an upgrade, it is rather >> a different network filesystem with some (significant) similarities to v3. >> >> That said, it should be fine changing the defaults, but you need to ensure >> that reasonable scenarios, like the changed FreeBSD client mounting >> from v3-only server, still work correctly. The change should be made in a >> way that only affects client that connects to the server that has both >> v4 and v3. > A particular test case that needs to be done is the diskless NFS root fs. > This case must use NFSv3 and if it is not the default, it might break? > I am not really set up to test this at this time. > (There are assorted reasons that NFSv4 does not, or at least might not, > work for a diskless root fs, but that is a separate topic.) > > Other than testing diskless NFS root file systems, I do not have a > strong opinion w.r.t. whether the default should change. > > If the default stays as NFSv3, a fallback to NFSv4 could be done, which > would handle the NFSv4 only server case. (No one uses NFSv2 any more, > so the fallback to NFSv2 is almost irrelevant, imho.) As you particiate in interoperability tests, would it make sense to check how those other implementations handle this case? I naively assume you have some contacts or a mailinglist you could use for that. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Tue Jan 4 14:06:43 2022 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 80F2819216AF for ; Tue, 4 Jan 2022 14:06:49 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSvYh37VMz3JFx for ; Tue, 4 Jan 2022 14:06:48 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 8F3573201591 for ; Tue, 4 Jan 2022 09:06:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 04 Jan 2022 09:06:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=ZMbb6BgP/oG6lDN/U17LPURtOGz K2SZJwfcMjv41XYA=; b=jn8M8xaTrHD3h0Sc4VCkcLUFJXrxPFZhAWr+c3rHbwJ u4fP4HHR3CJn4vzAdoQnZaDBy2kzC9+WF2CN4Ar779NFIc42nTMwLGewZ9WZ/9iD TA3V9oE9SaOQqxduZbR+2Ch0SGpTOEa4CtdphA/4JU3wIdQrD7xV37yJhyk/7Nrw EydS4eOmTJ5TrLsXwiZlmorIBAK/Xd7JGuHjPgWxnTQPgZY9rZxVYYRH3eFNEKGa ULFjdEIYq+V9rd7bfkzr2ARum03fVn5zNbYgM4dg/LDnGcG+QcaIhVTfv6XpyOy2 Iji9z/h8K7p+hdIAkV/4KRrG54u28y65xUoGpvvR3nw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ZMbb6B gP/oG6lDN/U17LPURtOGzK2SZJwfcMjv41XYA=; b=LiWxJwQnxM04Mikn0bjR3u 51AJfQ20GOu1eZpoSjUpVTfEB8IqEMhYrJPCUt1k3XNEPbGPKeRVeW8SqBqFX3kg EMX71/uRZjrqSg4yVqgJdNGkwKLYEyKcKMnnMqSJAEbTgl538Xzkl1yDOKTH28sx 1HCSzfgaY/rinmbfpGCOeH6FZYFxATtusJs+u8O+9W9UlgwmPRkf5gVvZocAFadw GF3kU30fUuCZts76awFqfB4sR1+RX8jwUGYxo4pnSKsrYwWc5Hk1ZBUlMpVhc4/R CH8TcwsthFTxhyKK6jJ7ouuzzvkmPaXq0b0w5LfYxSMHaSarjFjJ+BctNCuour5g == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudeffedgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeellefhvdejleeivddvkeffkeekve fhfeefueelvddttdevudevgefgkeefudefheenucffohhmrghinhepsghsugdqhhgrrhgu figrrhgvrdhinhhfohenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 4 Jan 2022 09:06:45 -0500 (EST) Date: Tue, 4 Jan 2022 14:06:43 +0000 From: tech-lists To: freebsd-current@freebsd.org Subject: Re: observations on Ryzen 5xxx (Zen 3) processors Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7Ba30MTppgRpUurd" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JSvYh37VMz3JFx X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=jn8M8xaT; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=LiWxJwQn; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.21 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.21:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from] X-ThisMailContainsUnwantedMimeParts: N --7Ba30MTppgRpUurd Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Wed, Dec 22, 2021 at 02:42:48PM +0200, Andriy Gapon wrote: > >There have been some reports on strange / unexpected things with Ryzen 5xxx >processors. I think I have seen 5950X, 5900X and 5800X mentioned, not sure >about others. Thanks for this. I'm evaluating a ryzen 5600G. Here's hwinfo: https://bsd-hardware.info/?probe=3De67007df20 I've noticed a couple of oddities: 1. some ports won't build, but world builds and installs just fine (current= /14) 2. sometimes it "lags" a bit, but am not sure if it's the cpu, the board, t= he board+cpu,=20 the connection (it's offsite) or all three. Please let me know if there are tests you'd like me to run. --=20 J. --7Ba30MTppgRpUurd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHUVGoACgkQs8o7QhFz NAUgeA/6As3W5QUe/Yp0+iouu7sjPlTQERIvOT890oGhreqm2rFu/s4Iw1uRwP1r LGh/kK0xwp+OPDXTHUICfxKjWH8AfeajiDA5dgQQ2oOkUjdlnlzTdgCZJ3mT8SFM t0XctYwO3sZ5fvUqbBztk8UsqI+/EM+fPlzntvWGsNGMsmjZd88Bux3xCBB/hoLP 9FaFsS2F/sR8RC+FniRaW/DFXUEct5bxviwLlQdWlfuXgL5MGwP4tEmaOYqdTc7k LTg8SHlAd8uOTxUfPJombrBA1G5ckoHKPxX7QioyXxZlv6KFFzZyrjjQOk1ZJWh+ dWWo/1YmHkRYPgbtdq9unYRIjh+2e4kvHEOlWNWL4n9CWRwCWgMB3hGEy3DdkiYD f3NQCrq5oTK9ejpy4gSK7CgC/K7RU290IoAjLIorQW/tFp//O34pw+5DMgLAOqQf 1J7zuzy7djeAtSM00tA4WxjLZ0MMiCcRHKA8VlxKj2FQUUKZ6bHmmYQKqqrqxTcn noZKTWGopEP4SA79kAUaTdH1By40Sb5GMEeCWQtvrzf/kOFNp27rZPji1J2xA034 bwtA6Jcd20FF44saV5/e7Q34oVUyqYd/ya50q7CCrI/ymY6zRfBhnhW8lSilFUx8 uDUdEom44BH9DoAu6aLEvU2eESuNPQ7jzcrEHQRcf42gVLn8Zwg= =AFYt -----END PGP SIGNATURE----- --7Ba30MTppgRpUurd-- From nobody Tue Jan 4 16:56:07 2022 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 5751E192F02F for ; Tue, 4 Jan 2022 16:56:18 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 4JSzKF2CDJz4bhx for ; Tue, 4 Jan 2022 16:56:17 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 215013200C17 for ; Tue, 4 Jan 2022 11:56:10 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 04 Jan 2022 11:56:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=Wg5qfTw7IJmh2aVjXI/ykPh1OJD qC/OeHLyc5cYaM9k=; b=Q5Wm8VvN/C8mXNUrpflePhcewS0raabuCrbv0bpCwVA 9WEupmb5xlaTIkx5ahonBLW9v5NSPJKiF/Jb10+XBXOrl9eSbWCHu0MLcAcich+x xFfXHJjmDTwjRTkkiqzj/2AXvHKJgNVv5wUt6Lrtn47CvQgmSVNdzwi1ubLC9t+K YGikCZ2f0JeSEuG15i6NZdwo2AFedMTdcpOn3Wzs021PoHgmJY2V68jNj1j+OceB RCBbr9PGFGWxYqn7YsB9QdFfxYDH2sqJhQlmEWf7JhpUBE8WfGucrn7pSpbJs3Ft p5s5D/kEezmsjfaRXKqKqn5bqrZEutYIEm/mFjW7mUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Wg5qfT w7IJmh2aVjXI/ykPh1OJDqC/OeHLyc5cYaM9k=; b=NI+tnDtzd34zrSkyzHq7bm 3f9fkZw4axOzmQ/0oOOSRKxSwScErrhW0LdS559NX32JFHParN3Jt6L2LfTZzfiv 6KvwhIOPveCDAay9Q/MOQAFnXwvGL1L9NcfBW14rUnwe5W3DlBwEjfAfR+Tjzrns jkCcdP6DyEFMC3mouzwmkLpR7nkMR97IqFx1W0nw/eVld9LHUulYKWFrWjRC+M0d HTHO0/DL/X1kdZGKlk9WbXdaY9HgqB/Viu64VhKSx2iJLuutIWmDYSNlU+79CUe9 OCuXZSBUOaadJHy96lSBsiw8+1ZoBPEiCW0y05SMQf/kzaYrveNED/OSxxN+cljQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudeffedgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeellefhvdejleeivddvkeffkeekve fhfeefueelvddttdevudevgefgkeefudefheenucffohhmrghinhepsghsugdqhhgrrhgu figrrhgvrdhinhhfohenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 4 Jan 2022 11:56:08 -0500 (EST) Date: Tue, 4 Jan 2022 16:56:07 +0000 From: tech-lists To: freebsd-current@freebsd.org Subject: Re: observations on Ryzen 5xxx (Zen 3) processors Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VzBtrYXJoTcAuCMi" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JSzKF2CDJz4bhx X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=Q5Wm8VvN; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=NI+tnDtz; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from] X-ThisMailContainsUnwantedMimeParts: N --VzBtrYXJoTcAuCMi Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 04, 2022 at 02:06:43PM +0000, tech-lists wrote: >Hello, > >On Wed, Dec 22, 2021 at 02:42:48PM +0200, Andriy Gapon wrote: >> >>There have been some reports on strange / unexpected things with Ryzen 5x= xx >>processors. I think I have seen 5950X, 5900X and 5800X mentioned, not su= re >>about others. > >Thanks for this. I'm evaluating a ryzen 5600G. Here's hwinfo: > >https://bsd-hardware.info/?probe=3De67007df20 > >I've noticed a couple of oddities: > >1. some ports won't build, but world builds and installs just fine (curren= t/14) Can't build lang/perl5.32. I have many vms running perl5.32 and they're not= seeing any issues. There's nothing in bugs suggesting there's an issue with this port right no= w. The context is 14.0-CURRENT #0 main-n252119-dfa5a74357f amd64 1400046 14000= 46 with a nodebug kernel. The sources were built with these (/etc/src.conf): KERNCONF=3DRYZEN5 WITH_CCACHE_BUILD=3D"TRUE" CCACHE_PREFIX=3D/usr/local/bin CPUTYPE?=3Dznver3=20 TARGET_CPU_ARCH=3Dznver3 WITH_MALLOC_PRODUCTION=3D=20 WITH_LLVM_TARGET_ALL=3D WITH_LLVM_BINUTILS=3D WITH_KERNEL_RETPOLINE=3D # WITH_PIE=3Dyes WITH_BIND_NOW=3Dyes WITH_RETPOLINE=3Dyes WITH_SSP=3Dyes # WITH_OPENSSL_KTLS=3D I'm going to try building a new world next, this time with no /etc/src.conf= , or a minimal one. But for now, I'm seeing unexpected failures with ports that compile fine on= other systems: 1. portstree last updated: Tue Jan 4 17:03:38 2022 +0100 version: 570114 2. no /etc/make.conf 3. in /usr/ports/lang/perl5.32: [i] make clean && make distclean && make rmconfig && make rmconfig-recu= rsive [ii] make MAKE_JOBS_UNSAFE=3Dyes -j1 fails here: =20 98 warnings generated. cc -pthread -Wl,-E -fstack-protector-strong -L/usr/local/lib -o m= iniperl opmini.o perlmini.o gv.o toke.o perly.o pad.o regcomp.o d ump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o p= p_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o num= eric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o tim e64.o miniperlmain.o -lpthread -lm -lcrypt -lutil ld: error: undefined symbol: __dtraceenabled_perl___op__entry >>> referenced by perlmini.c >>> perlmini.o:(perl_destruct) >>> referenced by perlmini.c >>> perlmini.o:(perl_destruct) >>> referenced by perlmini.c >>> perlmini.o:(perl_parse) >>> referenced 8 more times ld: error: undefined symbol: __dtrace_perl___sub__entry >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_call) ld: error: undefined symbol: __dtrace_perl___sub__return >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_call) ld: error: undefined symbol: __dtrace_perl___loading__file >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_load) ld: error: undefined symbol: __dtrace_perl___loaded__file >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_load) ld: error: undefined symbol: __dtrace_perl___op__entry >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_op) >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_op) ld: error: undefined symbol: __dtrace_perl___phase__change >>> referenced by util.c >>> util.o:(Perl_dtrace_probe_phase) ld: error: undefined symbol: __dtraceenabled_perl___sub__entry >>> referenced by pp_hot.c >>> pp_hot.o:(Perl_pp_leavesub) >>> referenced by pp_hot.c >>> pp_hot.o:(Perl_pp_entersub) >>> referenced by pp_ctl.c >>> pp_ctl.o:(Perl_cx_popsub) >>> referenced 6 more times cc: error: linker command failed with exit code 1 (use -v to see = invocation) *** [lib/buildcustomize.pl] Error code 1 make[2]: stopped in /usr/ports/lang/perl5.32/work/perl-5.32.1 1 error make[2]: stopped in /usr/ports/lang/perl5.32/work/perl-5.32.1 *** [do-build] Error code 1 make[1]: stopped in /usr/ports/lang/perl5.32 1 error make[1]: stopped in /usr/ports/lang/perl5.32 *** [stage] Error code 2 make: stopped in /usr/ports/lang/perl5.32 1 error make: stopped in /usr/ports/lang/perl5.32 --=20 J. --VzBtrYXJoTcAuCMi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHUfB8ACgkQs8o7QhFz NAVPww/8DsD6pHlpiE1FkkDhVd5UqhrvuuypVXNQju0tMFAryCjDuLcx9xGEh0fR ImwbectiCULR1PZDDGPnosGAdMXA4J9DgnMS7JLc2tC3U6UCviAvUG+diy+XLiLE 43K/LBYZAA0obnZnAuKyAUupNRPIDRXGeqYYiKH5hufK0LgW/toyIYKq2kdA1Fmi zdG78Zv9nIw5oyj+0mPk52Ut5yO/uFV2gMlMpnqyu8xvg0/1x7ZGDjd5G8HZ73Rh jxuSAN0cfW3mYWsMQ4ZPzVMI+RVGxib8hBBmrXmcc3vDm15hgK1p1S/c+SaPQMYL 6LlyTEN+aHn4NHwoJxHYgv4EHFa4oKENAAij8TSkTnLIhVbB8p/xT9Y8nQnlhNty S++reOXW1vOQaLADaOFgxxPfjEg8gTrAiToMVKDb8reRv/C9/JlpOVNzHMk/ps0i eH8SJOkQa8Ud09YPgi3a/iKE+zmBkCtkhU4rkKbvc7pi5MrCU1vXr1T6uvD9H4nQ cCllb8qgHprlXrWJbujaE2exHwUiYjuv/S9+bzmMiw1unUAy5gu/NBSdTkWY9kDS i943bZ5wgFVo7t82V4/JFpAo0SJXzOuHkB3ZfbR2yLmWyS9JQQSZg7SFBrUvmF4I 14auqMyQsFdKrE40UKRToGqg+39JvlR7A2wyVVtSQMy6r8Elt3g= =xYgJ -----END PGP SIGNATURE----- --VzBtrYXJoTcAuCMi-- From nobody Tue Jan 4 20:56:48 2022 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 4411D1929707 for ; Tue, 4 Jan 2022 20:56:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670071.outbound.protection.outlook.com [40.107.67.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JT4fw0CyLz4T0w for ; Tue, 4 Jan 2022 20:56:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UciGXlkGBKZT5cylzzS48h6a4DqE45tm8EL9qsk5faCuOl+KLwNDwwuAQHGiRP9n95Y2wTf+6YMa4UW4IyOVDKPW5S6GwkQUKJvn1c4PlHk4TADQBJZkYBaP8wuvgm98Jc2jBRwrlOsaOUM8sfEPzc/WZq25gS51QYyRZGcZkZCivOfrbnmxShYavE+R50yhpuHmTRqXnrhQ1l0pG9/qtoZjVa1loJVF+yqUD0WUeOtf2DFvir8dW07iFf3PwJjdGXbPXmD1tjU9Kmt6ZV+h4S8cUvUBWQR0Hv6r/bKhXA1cN6IidZEBj8O1cdW0K29NEoMqHzRXixMcFn/ALsEWWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1RxxCosFtX6N2hD5gWtp85aqHRA+ifnZfWGzqSl0ebw=; b=AtCjcmIzTt7mEC76xL3sKLOo7jSBHmZLgJ8AyOZEdheXBqTnFoFco8d1ZSb9ItcwwSVg2rFY3/EedZf1tzAUtBBUuF6VaThSloTPsalrl/ETXzktd8mKW+tea5P3kLd9MQ5jrW6bQ1V0mkUTw5U6tJrpABOqVpEGzMDN/Typg35nZoEVTcoeXh2oyGvAlz2w4iLVBZ4eCPBEptP2I/j9wglVPhEYtVOfUAMtzKYh0OL6t/4MtiJSaZl8SrQHwjuMZfyQFE0W/X1zchVaQMxU2n48R9xWMhtDMcj3SOyoSUg4e6Mof6wwr5JA35X20y4n8YgVlOJdJRmUObWzKJT/Qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1RxxCosFtX6N2hD5gWtp85aqHRA+ifnZfWGzqSl0ebw=; b=NHjjWXrSi4H9oeV9KfsIcJQDc4hWgJdLc9anzrG7C5iJfPheU5DiLQjJPScrU6EujFe4BKpW8NMoVirh+T7tu2BiaTt8KkzwnncYjVmLKUYS1LRcfCJ63IHt8KcwcG4huzU5dd7zfYrsd3w9so3jHEoWfqxOSbLTyQGDZmDpDA29Si3pk8l9YsLypW/HTQV6D73hBSplWTsadA3wqXdzYDWEH6vGk2RrtAl4B+Pl7uarmNiNYysaY8mopHY+rp90/jVmvXk+qqOSi9eZDwlIp+ijyByw/+ZVAGKTIGRIHMqHYFkNIawnOoMBxXzBgCHATtf4V2kooLq2DdqlEMh5vA== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by QB1PR01MB3985.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:3c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.7; Tue, 4 Jan 2022 20:56:48 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::50bf:ecf6:9d13:fd03]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::50bf:ecf6:9d13:fd03%4]) with mapi id 15.20.4844.016; Tue, 4 Jan 2022 20:56:48 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" , "Alexander@leidinger.net" Subject: Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2? Thread-Topic: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2? Thread-Index: AQHYANL1J9xN1hLYV0qzjoENtRmZsaxR/I+AgAAxcwCAAAEYZoAAO8iAgADs21o= Date: Tue, 4 Jan 2022 20:56:48 +0000 Message-ID: References: <20220104090747.7767144800c564ca2cff43d5@dec.sakura.ne.jp> <20220104074239.Horde.lTehmFlQWMv_N_QIcF1h1Wq@webmail.leidinger.net> In-Reply-To: <20220104074239.Horde.lTehmFlQWMv_N_QIcF1h1Wq@webmail.leidinger.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 34017a12-d2c0-8bd0-fd8c-61a9de25daf1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca2ca96d-a7fe-4015-6e00-08d9cfc4b9e1 x-ms-traffictypediagnostic: QB1PR01MB3985:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: njnoF7bKPC+/9hxf0Fnk5Zs8LSYXA3rLLRhDzjbQGXHayH+KFJO8bcxoKzlxZ/qMYXfByh1jvo9FXYKQ01i6hk/D5vKr+7ppnf+tGd+ZU9+ZlDDaDZ0Fz2lT4fPKo23UoBCFns/bD7/8m3mjnuB9TGASJj+ulb1NOx1hYHzEjsh9pCF2/7CXH1aa7MuDYxxfuDHgZIsqGQbc9BA6ucPppEOP2wgKH8RRVdEbOmvcdsVQCJpn9nI8E320WcCecuUqu2bEmn5435Rj9N/Ssb+E4gZl0iRgYKNd9n8aUbEYUArouGmQUTrAye7T8tdZ1Q55wb385dFtN32Tdpn+SaZ+WXXJSU8EVM/6YWGrR09E1ygo7+FgpXTvXrW7Tuzntur4k7zah2uRn2xQwFpzWD8J6QnK4cVwZyKj+wVDGRiOUAperjseGhB5b0H2KfG5r3aNj67RLouiYGp3kg5ui6ucAx0h0xJ4YqS5+HObZIRlfFPJYXW+WObT20Z8fuUvOH9tl2AcbPUciAwOtCDMPikCVflXMbPYfzXp96N022lTnzNTirphy3NcV1LJ0Xs3dsGmuyNU3XypeoYGt0TBSYvA5uCxAjRI8M3P93hqG4/VPR3n/fzq0CS+ITBme5HcsHKlVOpcRbBwSdvyK8GJVGevfl/pyeO6rM9HSROdZ2MlvMYN8oI71hyhtlUscSWpNWHcrIMMVFpim/ykFJFdzOUQBJwTKH2Z/+khQAgrtCXsnzQW6jK0pC2idjTZw6UWJG3s6EsL/mBWBe4XpN8kCP+igQ== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(91956017)(8936002)(8676002)(71200400001)(6506007)(83380400001)(110136005)(38070700005)(2906002)(316002)(786003)(86362001)(66446008)(64756008)(55016003)(186003)(66556008)(66476007)(122000001)(508600001)(38100700002)(966005)(66946007)(76116006)(33656002)(9686003)(52536014)(5660300002)(7696005);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ZBbRcYQ20pxubfu7/viTuSmXxjNmXNnSJSDiJy95KPZWd6xsSwITqi8TxQ?= =?iso-8859-1?Q?HQojNfghQerKArNNsC2qm/cQYGTr+dMP43fXZWkXZXfRfpfyIBsriH8uba?= =?iso-8859-1?Q?9pbWPTWB+mDYg/7jlfw/AbcuIpaEq+o2tTKqk32feHi1i4wAIgVc0OJnaT?= =?iso-8859-1?Q?7XJN+1fDYfN/dm6tHU7vHCa2Va2vkij6LBxPH2g50yYC3QwPPgE4ftqj0N?= =?iso-8859-1?Q?bP8QLinSFK06eqigwNskt4u8zTZ1aTcDtUTtCwQBN/oC+xhifpetxv4M2h?= =?iso-8859-1?Q?VsTE5i57ED4m7I8liGy4aV9mUsCJ96JSwbdFQS1dRo0T2F8nAMSeY6k9QH?= =?iso-8859-1?Q?9p5tl2AJD0/54pdNJ71ZzJr7Gl7qZonTQeWBNYgLfKwOI0zrmNusN+yKEV?= =?iso-8859-1?Q?LkxvsntgFAjRAUnYaH2odYccDxpkFYIDcKTKlhrTrw2RaRo8SuEzX1zmhZ?= =?iso-8859-1?Q?Hf2ceHHZYtm5tJMgb1Dxx5JMefB/E3O6ALKf9mmPcNjsh6BgJVHGeq6cYO?= =?iso-8859-1?Q?nem7bAj9i6852M88HTR0HrEuOelan8n3WmlLCpZGy6utj5Kd1D5Pn57pCC?= =?iso-8859-1?Q?C0j0CKGikG1sF5nZIQqon0ho+UZqnYOr9m1Z7yUN0zSVPJq4Aa83Hgy4VW?= =?iso-8859-1?Q?Uwi7nadgGXUNdcG+O4K6iceFSV2/T13v8tQIbSDv4H4qw0tZwJ6scaM3cI?= =?iso-8859-1?Q?ZO4efCr0Qp1XVgNjUl9Y3ZXo9F/ewupX69UrihlonnJiT1zxGvAnuLJyAz?= =?iso-8859-1?Q?NDByBvt/bXo2bJfWL/KuQT8Eh00Egjs8kNQWW8eMcLv0nC1D8B3QCMYwrF?= =?iso-8859-1?Q?acmVpe/UMUgyyLqy5650kw40/n0biJcN03lUMSGFJd8gpx1irIyr+K3n/2?= =?iso-8859-1?Q?jO+qtwF0p/Fld8WHmDlvnvt6S9713MkQI2bV3UGjuYcZ0C0EswaZKmSCF1?= =?iso-8859-1?Q?NgL7G+XibRNx2fCT6TIKlp4UWSZhYVG3XYvKkgAgfXXGlM/Xd4AnmsILlw?= =?iso-8859-1?Q?emKik3JbNTR5audSvBupNnaLv6iXxcSQXwkKDuS0tpJNhuC7/fHYUu8e7k?= =?iso-8859-1?Q?zoR6ZgfLIQc6SOP+iatigPh/Pdf0NNaTEMZLHWTO8NLyIZCC4S9UyY19Vv?= =?iso-8859-1?Q?Cs1GT3o2lXFy4/R/pYIUHFK4WtUxWVZ89uA1UnyVywYcc1BDWaCxHLvlUl?= =?iso-8859-1?Q?TyVtEmI4nlbwMe9wCF1QeaSR36489zhwxhvhe0A3hMiNNPXRQZmRJPUN0x?= =?iso-8859-1?Q?p2jZjKCItjSjWmg/Ie+4V7QzXuV+ten444C40GptdCnFmkbCtF3JkYSY5v?= =?iso-8859-1?Q?woQCqD3n/IJDIQ2fVKUq04UoJnsvZ9QNWegYpNRLsXiIm/xrOmK5S7rCZN?= =?iso-8859-1?Q?SVrGwUyAkn0tHVjypP0CmXzp4kSqE+AXpfcsYoRSdVt0fE2o9NMjpu1CRv?= =?iso-8859-1?Q?0FOtB9m1tEue/ghJLbHoD3EGYjyCky+HU7DmvXf8QkZjy6mVN5NPGOtjMs?= =?iso-8859-1?Q?M+xrs49ZxjacuNlY5JyY3GwCt6He0yiWSRgEX116io/UyvVnYtzGTbf55V?= =?iso-8859-1?Q?gCPA6AD92ATsJnDeesHCUi+4LHW+IZyoNgJWdm2jNlIUXx4q8/e7PR6iIS?= =?iso-8859-1?Q?kkFDvw+fzWKVpYKWrhXX8hI4/Jwyfgin9fYyzlrD10Co5VPAniUlSgArCf?= =?iso-8859-1?Q?gQqYRTug8L5u6StuXIrrG/eBFiqXymM9jIyu0Qjc5MalJtCuUgCgVaJIOt?= =?iso-8859-1?Q?KJDQ=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: ca2ca96d-a7fe-4015-6e00-08d9cfc4b9e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2022 20:56:48.8265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5XFJt+YkgSBZ18ijv1SBq1e4TEiLWw1koqPKurtjRKhS91m6+8kwBxHj/B1IWM+oqdFiZhBJCtUvJ7oaTi9VpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3985 X-Rspamd-Queue-Id: 4JT4fw0CyLz4T0w X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Alexander Leidinger wrote:=0A= > Rick Macklem wrote:=0A= [stuff snipped]=0A= > >=0A= > > Other than testing diskless NFS root file systems, I do not have a=0A= > > strong opinion w.r.t. whether the default should change.=0A= > >=0A= > > If the default stays as NFSv3, a fallback to NFSv4 could be done, which= =0A= > > would handle the NFSv4 only server case. (No one uses NFSv2 any more,= =0A= > > so the fallback to NFSv2 is almost irrelevant, imho.)=0A= >=0A= > As you particiate in interoperability tests, would it make sense to=0A= > check how those other implementations handle this case? I naively=0A= > assume you have some contacts or a mailinglist you could use for that.=0A= Not sure what you are asking, but...=0A= The only other client I am familiar with is the Linux one.=0A= It does NFSv4, then NFSv3 (I think they have dropped NFSv2 support).=0A= Linux also does handle NFSv4 root file systems.=0A= =0A= The other clients I know of (VMware and Windows) do not paticipate=0A= in the IETF Working group's interoperability testing, unfortunately.=0A= (And I have no contact with either of these groups.)=0A= =0A= rick=0A= =0A= Bye,=0A= Alexander.=0A= =0A= =0A= --=0A= http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF=0A= http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF=0A= =0A= From nobody Wed Jan 5 00:20:08 2022 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 8AB1519218D5 for ; Wed, 5 Jan 2022 00:20:16 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JT99W3qv7z3h8R for ; Wed, 5 Jan 2022 00:20:15 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 2050K8tZ074977 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 4 Jan 2022 19:20:08 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:8432:1527:9d04:33a0] ([IPv6:2607:f3e0:0:4:8432:1527:9d04:33a0]) by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 2050K8E8056382 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 4 Jan 2022 19:20:08 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <78385fb2-adf1-3385-7ecf-2587befb0abc@sentex.net> Date: Tue, 4 Jan 2022 19:20:08 -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/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: observations on Ryzen 5xxx (Zen 3) processors Content-Language: en-US To: freebsd-current@freebsd.org References: From: mike tancsa In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 X-Rspamd-Queue-Id: 4JT99W3qv7z3h8R X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [0.43 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.970]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[sentex.net]; NEURAL_SPAM_SHORT(0.99)[0.987]; NEURAL_SPAM_LONG(0.72)[0.716]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 1/4/2022 11:56 AM, tech-lists wrote: > On Tue, Jan 04, 2022 at 02:06:43PM +0000, tech-lists wrote: >> Hello, >> >> On Wed, Dec 22, 2021 at 02:42:48PM +0200, Andriy Gapon wrote: >>> >>> There have been some reports on strange / unexpected things with >>> Ryzen 5xxx >>> processors.  I think I have seen 5950X, 5900X and 5800X mentioned, >>> not sure >>> about others. >> >> Thanks for this. I'm evaluating a ryzen 5600G. Here's hwinfo: >> >> https://bsd-hardware.info/?probe=e67007df20 >> >> I've noticed a couple of oddities: >> >> 1. some ports won't build, but world builds and installs just fine >> (current/14) > > Can't build lang/perl5.32. I have many vms running perl5.32 and > they're not seeing any issues. > There's nothing in bugs suggesting there's an issue with this port > right now. > I would for sure try a clean src.conf first and use that as a baseline.  Also, someome mentioned trying machdep.idle=spin In /boot/loader.conf But removing your src.conf optimizations would be the first place to try     ---Mike From nobody Wed Jan 5 02:59:08 2022 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 A85511947A6F for ; Wed, 5 Jan 2022 02:59:19 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 4JTDj24M8Kz4brQ for ; Wed, 5 Jan 2022 02:59:18 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5FF575C0140 for ; Tue, 4 Jan 2022 21:59:11 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 04 Jan 2022 21:59:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=7WIGaE7s1e/9wOc7jVKU5caJ+q1 AJgyWIwh8EOzg+o0=; b=W3Fn9Y4EyycCbV6u3pW8jGm22aENolehG0dy1V6rEMq fBChPvZvfoPJU8ZK1lj4k4usPUYMRr1y5j4VnnR/+xzynfpqNGwJ3b7oDeGQNceB SnijHlc/e0K4oGpDRTL0tzYiUYZmO5OCJazgzbhhmHWfvxqXHhaGLPdL/6nw/Nh0 N20RqQrzyerezzc/1sZ9lxb8H0Xz867L8lYsqTyvrO77s4JTDFJxK299Sn4o6tPo LkTxNnB7YMTzP4OTqLcUT+sA7zAGVMN6QSHUf21ct7H5K3jLxj8npIq1UyY5s2BX pkJ8VcnO75Sbymatv0dHifMX/0gUQxEnA7NtVlZIhzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=7WIGaE 7s1e/9wOc7jVKU5caJ+q1AJgyWIwh8EOzg+o0=; b=QNzozv6Mb9TjEPwKeMZLbL SeAoOUaA71Hfa0n+iByJjPehrvcSXtlkeT1MlIPY2dzteg5LxsNbLuiwi+zOiG0S 2f0Z+vnKx0KV9B3YMithKbSVX4V/NNzHeti7MhBQDGLm34icG/uwK7hp7aGaY72o rGJgbPgPqljXtmJkcpHEtTG9dV3ZBSUx+JhzvSPxUfgqtJp6BeyAy0FP81V2M8Rf +q2RMSrQjRTD6+V3jjP8DimJ5QCHvPHZeKEQ0J05hZnWuHplxrgZ9FN3zLUGEihR 7MGs62sLh5B0Hr1PhaoGNoQq+91XDpde77FfYhsRwO2ikOE56FsjsTztbVH/WAbA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefgedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtudenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeevffeujefggefhfeekudetvdehtd ehudfgffeigeefveefheegvddvtdehffeljeenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 4 Jan 2022 21:59:10 -0500 (EST) Date: Wed, 5 Jan 2022 02:59:08 +0000 From: tech-lists To: freebsd-current@freebsd.org Subject: Re: observations on Ryzen 5xxx (Zen 3) processors Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <78385fb2-adf1-3385-7ecf-2587befb0abc@sentex.net> 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="F7BIj3Uz1lcXgBcW" Content-Disposition: inline In-Reply-To: <78385fb2-adf1-3385-7ecf-2587befb0abc@sentex.net> X-Rspamd-Queue-Id: 4JTDj24M8Kz4brQ X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=W3Fn9Y4E; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=QNzozv6M; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.29 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.29:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from] X-ThisMailContainsUnwantedMimeParts: N --F7BIj3Uz1lcXgBcW Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 04, 2022 at 07:20:08PM -0500, mike tancsa wrote: > I would for sure try a clean src.conf first and use that as a baseline.=A0 > Also, someome mentioned trying > > machdep.idle=3Dspin > > In /boot/loader.conf > > But removing your src.conf optimizations would be the first place to try Yeah, tried this just now but it made no difference. No src.conf or make.conf and GENERIC (so, as -current, debugging kernel) it's as vanilla as I can make it. Some ports will build=20 (ports-mgmt/dialog4ports) but lang/perl5.32 and devel/llvm13 won't. All the dependencies build - there's a lot of python there too, for llvm.= =20 They build and install fine. perl installed as a pkg installs fine. I've not tried it but expect llvm13 to install from pkg fine. They (perl5.32 & llvm13) won't build from ports, though. But they will on a vm of the same version, just a different cpu (xenon) --=20 J. --F7BIj3Uz1lcXgBcW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHVCXIACgkQs8o7QhFz NAU7eg/9F3OP5gi+TIUcnf5JD1jxDjnpgnlYvbeKIocJ9fIxq7/Pjtt/GfEQTyXN ZvvR5Tqyk2x+u4s7WzhAB0VGPRjypiJZvd+1QfYUYHa4s19UllQuTqwbo4Z8EIf4 0rZb+cO3TY3yZm9lkw9JFiOI6PKi0aY0WimSXZN8h4yuIVwPvHMZHaJOI9mrCXSh uZ+y4cqUb14ATuBGEIY8yZo6LbYttIYIsG4asyJDMjogBa4Nq+/2gh3wuXc8+9l7 xqvmBe6zELyBmGqaId6rtZ4cHMc3AQr1J8PY/6/SRKa3PPm7OB/EQpuH91O1xk0Z 4OMlYE5GG6e2Ebl1u6SHA55NiG6+kiPgp2iw5DKwmUtlQmsWu1I18BMN6uqszzPJ LqRPzRIo+vw0CAFfMC7MZ/Xr6FmlOCGmyhCmkMuo5t9Qwcf8DyTyCeDPEI2FwrjM PnxDRSW8zsGP62Bp3Mt18KXdV/Q2eVLgNELW5fgwMu+K9wjdfXKyFSqNquqbuNJ6 XY4eS3/tgBA7Qct/Igl3EZ1nH4y8GkRCpe2F8HqOoU/hEySGWRdkUH8DfHEtYJil aQeAa3CF7H7ghBaIvUIS4RWF4OuhJ3GBe8wE+ScsCoZHvLlgOzEs0ftOn/qNpD7i x3g34GYEwYsav9bwQMSwDdZ5doio/XIoljwEwNjWc6yKYvFmEmM= =CJQo -----END PGP SIGNATURE----- --F7BIj3Uz1lcXgBcW-- From nobody Wed Jan 5 03:06:57 2022 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 82703191B922 for ; Wed, 5 Jan 2022 03:07:00 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTDsv6DRmz4f9G for ; Wed, 5 Jan 2022 03:06:59 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C21115C006A for ; Tue, 4 Jan 2022 22:06:59 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 04 Jan 2022 22:06:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=Y90WOctobAIDUSDGBiR2OcHi0dR rbvqTZwV/DVZjiZA=; b=d6uKYZ3OwwONLX2UUWHLOeNrsJu2eWztbedPR10FZNk vP2PLu14MK9JQOcE7Lx1VuWmdTDY9b/ARtrfYa7MMJuYvB8+FJTfztNNNKgsPAWN nJ5R7AUL14/TRTAf6o66RBWWiwxvMaiFSALGSYEuplbE3hr/n8LH1TX6nGmes4Hn /dp5OuUB6iPVLme7/FzsHacBuKAgBEr8smRmSEBLIilaEvYflKraO2eRmA5sa7SR ug/NbYPhMIZcAzbQpyzzUyloNXz72RV0huV3/+/0wA4egvNzrkk1tGn9A28ciO2q DNgBclvAWRs+1AXqKKcfp+3CC3pQO4Y3udxhBlyjTaA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Y90WOc tobAIDUSDGBiR2OcHi0dRrbvqTZwV/DVZjiZA=; b=hWXDCW0vFCutRVCwJx3ULV l622epZ5ozUUwDoGBJpsb4xfpif+gd6VeXl0XzTLVT/80MtNbgmMcuYJM37sIdU3 j/nLOPbuq1mmiPnVJbjj0M8d61yQId3MoRIRw73C4bZ7jGFT9g14934Gzib+dCi1 Th+mqHNuyr9lkzM1dOZATpMHjXVmyA+Q4EzuX/djsGwu7gOXMkL147PCZaGKmq8r EGLj4DGMpmr1easgJBW5Rh5QAeJsPk8eW5nwkSIpVHUDJUDxZVNdra8wAnhQly84 ROLRCHl8Xqtpr9ls1RFVnaSsgTpShnElSxgActcG//imYaIL2p9adIiRoyeWAEjQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefgedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedtheeigfdvudefkeekvddtfedvte dttdekuddvgeevlefftdekffdujedvhfduteenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 4 Jan 2022 22:06:59 -0500 (EST) Date: Wed, 5 Jan 2022 03:06:57 +0000 From: tech-lists To: freebsd-current@freebsd.org Subject: Re: observations on Ryzen 5xxx (Zen 3) processors Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <78385fb2-adf1-3385-7ecf-2587befb0abc@sentex.net> 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="wYbhioneRsW+854n" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JTDsv6DRmz4f9G X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=d6uKYZ3O; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=hWXDCW0v; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.29 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.29:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from] X-ThisMailContainsUnwantedMimeParts: N --wYbhioneRsW+854n Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Next thing to try is I guess to turn hyperthreading off --=20 J. --wYbhioneRsW+854n Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHVC1EACgkQs8o7QhFz NAWW1w/8DdaAZ5n43GbUnsRH3JzCZTuUs2TBe+a1KIsXHwYG4SKJKEGdkotkDmj9 tnGtLl9goUVhvRNLjG5IKeukGiwoh0sUxCWpVt25aIQYMN2NB3jbfEaYRXp1j8yI ZsFNIk4X8d+B8+19RuqswfWcOXgHfhTkFsgoMHkHb7jgNa5dY7zzaq0hPbH+yNH7 w7mGOL0l015VLnH1gUmnFMl1tocjEONom8HxFH2BpLnwJre5SKlZDe5sUw9HHQRQ TNovMeSSfwX8KcklG6+tO4nIAZMT6v9JUT3jo5Vw5pIKwD56dyEJMEgsJmpF4CAB JboFbvuSx+kLGTBunSt3vsel3icYyK7+9tV0Pg122ywxyKugr2blLJmRe+gj/014 YjtwBxAFBUUlCg9BLPQ4pKS4LHYAD1rEmsmiRlRS/eh0whU8ULqt9LSoIRFBF+5/ sJ3zsVYLVw6JcTLgSvQUwqFj3qzXn/qwRpnMicyClSl/IQm8l0skdQDwkMZl3IaW 4Fqdgg7eXPTfmnatbIJMZ9tnZmD+/yfFPIaZitSvha7g9zM6Qc0jstcvcjxlupTR 4IJ//CJO1027ENtoVjuQXsojqAjhppVRK8+g3vW32EqjxAxg3U94hYqmtTGhO3ER imFJCaO5JW9zBhzvmPBUN+tzpuPeSs9z3sZ3VCHwmuouqQH2JPY= =wIEm -----END PGP SIGNATURE----- --wYbhioneRsW+854n-- From nobody Wed Jan 5 05:41:21 2022 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 4304019205F1 for ; Wed, 5 Jan 2022 05:41:24 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTJJ339qbz3Hy2 for ; Wed, 5 Jan 2022 05:41:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qv1-xf29.google.com with SMTP id fq10so36572319qvb.10 for ; Tue, 04 Jan 2022 21:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=MODE71X0RsrsuBULb9x+g6l3a1BTy53+MhHprHNP+y4=; b=fYNs6Dxg03PGRmpxMoNYl7+B5BMPf1RVRnoYN62pP/h6t4eQP+kKL/ysSzsBFdRyXL HqU+OmtmGtD7txVFfBZpEhXdfSSLLCtkmEfHk9MzZ3sRiOybxRzEjA63/U974WVCZuqb 2MaVc2pW8EyHTnYgIDg11RJ9g3PsMjvo1q+iPS6/1cnrzxyrzd01Y9A53NfXxDF4d8oK BSjvAdrFEuStMC23s3vD1dVnK+q+PIfxIoAG2G0dNk5dGuSN9wC0/v0HpukR8foprLy3 h8NwCD4AvfecfUNyYvWEgSeD/2UMIFHVp7/diylplnjxGw2ojTTHR0cG9yogV/XtggMp Ki2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=MODE71X0RsrsuBULb9x+g6l3a1BTy53+MhHprHNP+y4=; b=m8rPCrjFleujmFRQa4k2VtjzLvrdVf0sCUwXF+caQ3hzviWJZXzv3rP8R8No6oWiKJ 41KOFc+vgSCR2oIIwsl5EVglwNBeQWaPO04TCMC0SBtVagYaaFOdK9s5auxEG7kI2/r4 b+dgFo0EAkg5nhPe6MHPyaPLOgrv10oiSqWbwcrMt3/zlzy7Bv/D9f5SvLtiAtKF6mtx 9YFpBk7ioigQEnN5p5N7CZxhgH9QVt5zLwrG3jIw0cCoAZysyhdgiks3nLGmJFfM501D Ciff+tgZU/jZOX4pTTDQOjrbP7VTnNRYKy/Q6wZeribeplXw6YBvGFwzKz8szyt5cqeW PTZw== X-Gm-Message-State: AOAM533DPq+Suwt1VDvCUW4QStZ4y5fo6NOoXpAXgNA7bkLG8k4S7F9V Af+vBqrqz8hrQPxkqjjCSuBGxbkKfH8= X-Google-Smtp-Source: ABdhPJx3nNaZzno7RR1TGl8Mr6wEuueXy0jpOT9/FWTuI1EXsrShZkgxqc6hsxfqLTgqLwXsvWs55w== X-Received: by 2002:a05:6214:19e1:: with SMTP id q1mr47700900qvc.115.1641361282587; Tue, 04 Jan 2022 21:41:22 -0800 (PST) Received: from spectre.mavhome.dp.ua (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id z8sm35243152qta.50.2022.01.04.21.41.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Jan 2022 21:41:22 -0800 (PST) To: "freebsd-current@freebsd.org" From: Alexander Motin Subject: atkbd_timeout() period? Message-ID: Date: Wed, 5 Jan 2022 00:41:21 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JTJJ339qbz3Hy2 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=fYNs6Dxg; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::f29 as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-0.22 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_SPAM_MEDIUM(0.98)[0.979]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f29:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, As I see, one of the most active threaded callouts on idle VMware VM and some hardware is atkbd_timeout(), called 10 times per second. Plus it is also one of few remaining non-MP-safe callouts. According to the comment it seems to be only a workaround for some lost interrupts. That makes me thing: is it really needed to run so often and so accurate, or may be we could reduce it to 1-2 times per second? Or may be it can be avoided somehow 20 years later? -- Alexander Motin From nobody Wed Jan 5 06:39:01 2022 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 1FAEC192FC3F for ; Wed, 5 Jan 2022 06:39:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTKZn02H6z3hF7 for ; Wed, 5 Jan 2022 06:39:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92f.google.com with SMTP id v12so55487348uar.7 for ; Tue, 04 Jan 2022 22:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/DRo01XLJkRFPG6vauwFaUHGieZtXM/VxYPMkp8EMuM=; b=4P7hGxvsY+MjR0JYy9psojqOqe/C6RT/M/31Ibc/cmXAdyprVBwqja4GOJK981zkOc IezWCAcQFQp4d+cLRCl3RPJsnSj+D4gF8SjPam4jpZ1QlERcBeeCcoaNp/jWERAujrJG dMIw23ikk588OCk5YtTQ3vSqNVYETT8TlL3Tm5nzTADQ2fsoqHBZI4amOFdXMAshpQHF PaSQjuiSpdWK3yUN+qp8FHa3EvRpUrQAq4E7ni45/jVod5MKec3Na7NAIwmkfZSD+wjM JU6vH8SihOTGTouuVII51d8nuPE9zG5OpRDpfIZlx8WlGcpg39jCta/XEtm2RsZ1BlYb mZVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/DRo01XLJkRFPG6vauwFaUHGieZtXM/VxYPMkp8EMuM=; b=e4koJTiJFkxvTghrJGdQsMnax7GraBVkOhWnJfxZg+OZPlREWUgl2r1ZDKRqDKNaLj LuTVg6IL0Ti+bF3ei2juF2QTjKnaJw3/OdF4V7A4/u5DfPbhaRxJqCw865axiyz6Irch aNHSllRZhFh5ijAtlIzZ1FEQIT5q6VU4QAHDTH9yRi4TURrn219uoZ9Rl6sdImbDJSOO 1zu0vip6S/J6OH3s6C39gG96M/w9lQKbseQvA4J6DgEpi3R6a74ZWP0warAiWa9b9+Sx 70kZhiw+7hBYM02YU+CxUL+sUeiULlFA87RlIHjwbAcx/ql7QTnte1vnxrRUreCU1ngN wf6A== X-Gm-Message-State: AOAM533xHmWPemls4MkDuy/04QCXsmrKOHNcTEnCwk95FO9IywOmzk/S vrvL6Qlpvm63haojeCLbWcU3OyEqPRhGx3b5akr4dD3RCWU= X-Google-Smtp-Source: ABdhPJzwaFjb5QX87Zvr3IZCl63SOc2+KwrByarEyMJbHYEnLI6sZy2JiKTGaeqZTBVdkFiyQ7clrKbgDwc12LjhpoQ= X-Received: by 2002:a05:6102:ed3:: with SMTP id m19mr17154074vst.68.1641364752144; Tue, 04 Jan 2022 22:39:12 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 4 Jan 2022 23:39:01 -0700 Message-ID: Subject: Re: atkbd_timeout() period? To: Alexander Motin Cc: "freebsd-current@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000ffafd105d4d002a1" X-Rspamd-Queue-Id: 4JTKZn02H6z3hF7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000ffafd105d4d002a1 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 4, 2022 at 10:42 PM Alexander Motin wrote: > Hi, > > As I see, one of the most active threaded callouts on idle VMware VM and > some hardware is atkbd_timeout(), called 10 times per second. Plus it > is also one of few remaining non-MP-safe callouts. According to the > comment it seems to be only a workaround for some lost interrupts. That > makes me thing: is it really needed to run so often and so accurate, or > may be we could reduce it to 1-2 times per second? Or may be it can be > avoided somehow 20 years later? > Yea, we can likely just trash it and wait for people to complain about the keyboard being hung. I doubt we'll get any complaints because Xaccel 2.1 was quite a long time ago... It is no longer relevant and the original conditions that caused the lost interrupts are likely long gone... And if they aren't, we'll get a reproducible test case to judge what the right workaround should be. Warner --000000000000ffafd105d4d002a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 4, 2022 at 10:42 PM Alexa= nder Motin <mav@freebsd.org> w= rote:
Hi,

As I see, one of the most active threaded callouts on idle VMware VM and some hardware is atkbd_timeout(), called 10 times per second.=C2=A0 Plus it=
is also one of few remaining non-MP-safe callouts.=C2=A0 According to the comment it seems to be only a workaround for some lost interrupts.=C2=A0 Th= at
makes me thing: is it really needed to run so often and so accurate, or
may be we could reduce it to 1-2 times per second?=C2=A0 Or may be it can b= e
avoided somehow 20 years later?

Yea, we= can likely just trash it and wait for people to complain about the
keyboard being hung. I doubt we'll get any complaints because=C2=A0X= accel 2.1
was quite a long time ago... It is no longer relevant a= nd the original conditions
that caused the lost interrupts are li= kely long gone...

And if they aren't, we'l= l get a reproducible test case to judge what the right workaround
should be.

Warner

<= /div> --000000000000ffafd105d4d002a1-- From nobody Wed Jan 5 07:07:17 2022 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 9A6EA1937BBE for ; Wed, 5 Jan 2022 07:08:01 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTLD13lSbz3nvD; Wed, 5 Jan 2022 07:08:01 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wr1-x434.google.com with SMTP id e5so80955035wrc.5; Tue, 04 Jan 2022 23:08:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J789KwAXO9SVrtRSTG+36yX1wbalZBIeKsqrD9Q6ifw=; b=EulWHk0giuXY5yvW2JndKpxwrPF5CsBBCLfi1m+wuWHdIvFSYfqG88a/JN+1nSggU1 HFZE9vAREex2SnRtk7mrBoNZNJL6qAz73S+N55LHFxaJ6e8hwBwohCtJf4C/W8HEUoAT Ua1NuKIcxjPqL/cX566KlOyXH6Ji/mtuegLv3REtjSqzEGisBpvJCpY1DujiVMf4liJs mpkK1+Mwfgri+NYvev0UF0wO+1bjyfuGCFZa7d1GaIKBGi2Wgha6hefkpC27MFKnXJ3V miplnCxwsqpxWx219vQEA7jwmP6G4ZiqDDXrhugMNo228sRQJNdXU5Bfp5HMttskwSZN qK4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J789KwAXO9SVrtRSTG+36yX1wbalZBIeKsqrD9Q6ifw=; b=v6T8hFpPWQSnzLr8DgIQt/igE1BFyKP/N6s9VUYxuPP7dmuQB08+9RmfYorSoVQ5p7 pE2aBzKYLYRwwtkwxTyrNxMdOyKuR716j/YQOyQbd4Hbq5px4n7ZDGbZ83K1XAfUA5Pf +p6LbtWoew5dwZBBa54QLBL5QAfrL+RuXJdCR60jyKoCOzj3a7dJniXfQEOIWOyA7Tnh nJVGxuNFKFzeaxYIRtMfCRdWpqw2n8wUDcTTyyHuBQ+0StvN91NH6oVdL3HlZDW8qN8u 1t3x0e+9Y9cRfStL7hi5nankOIlgkoht97L4yk08AaGO70yeHkZjC3z3PpTsSp9tDRum Hf1Q== X-Gm-Message-State: AOAM5336heAjnRXMRO/yuEmwcw+5yeGvQq166s3t2MMIRfO7npc6DRNd OoJ8bl9HJoU5aITzZ4E8YvXgB3tqq6zZrx222OPzkqFV2lHRDA== X-Google-Smtp-Source: ABdhPJzI84RrIt6h1uPlALOcHy2ij6+KKMvZej7ePfBpTJyX14CRIYAo8BbP08V0kATmpxKaPv6lFhqVcdKKNzFZDDA= X-Received: by 2002:adf:e0c8:: with SMTP id m8mr23653646wri.609.1641366473783; Tue, 04 Jan 2022 23:07:53 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Wed, 5 Jan 2022 10:07:17 +0300 Message-ID: Subject: Re: atkbd_timeout() period? To: Warner Losh Cc: Alexander Motin , "freebsd-current@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000009dbb4505d4d06944" X-Rspamd-Queue-Id: 4JTLD13lSbz3nvD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000009dbb4505d4d06944 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 5, 2022 at 9:39 AM Warner Losh wrote: > > > On Tue, Jan 4, 2022 at 10:42 PM Alexander Motin wrote: > >> Hi, >> >> As I see, one of the most active threaded callouts on idle VMware VM and >> some hardware is atkbd_timeout(), called 10 times per second. Plus it >> is also one of few remaining non-MP-safe callouts. According to the >> comment it seems to be only a workaround for some lost interrupts. That >> makes me thing: is it really needed to run so often and so accurate, or >> may be we could reduce it to 1-2 times per second? Or may be it can be >> avoided somehow 20 years later? >> > > Yea, we can likely just trash it and wait for people to complain about the > keyboard being hung. I doubt we'll get any complaints because Xaccel 2.1 > was quite a long time ago... It is no longer relevant and the original > conditions > that caused the lost interrupts are likely long gone... > > And if they aren't, we'll get a reproducible test case to judge what the > right workaround > should be. > > Warner > If "10" in " atkbd_timeout(), called 10 times per second " can be defined by a control variable , then it may not be necessary to remove its call , and polling rate may be set with respect to the suitable needs . Mehmet Erol Sanliturk --0000000000009dbb4505d4d06944 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 5, 2022 = at 9:39 AM Warner Losh <imp@bsdimp.com= > wrote:
=


=
On Tue, Jan 4, 2022 at 10:42 PM Alexa= nder Motin <mav@fre= ebsd.org> wrote:
Hi,

As I see, one of the most active threaded callouts on idle VMware VM and some hardware is atkbd_timeout(), called 10 times per second.=C2=A0 Plus it=
is also one of few remaining non-MP-safe callouts.=C2=A0 According to the comment it seems to be only a workaround for some lost interrupts.=C2=A0 Th= at
makes me thing: is it really needed to run so often and so accurate, or
may be we could reduce it to 1-2 times per second?=C2=A0 Or may be it can b= e
avoided somehow 20 years later?

Yea, we= can likely just trash it and wait for people to complain about the
keyboard being hung. I doubt we'll get any complaints because=C2=A0X= accel 2.1
was quite a long time ago... It is no longer relevant a= nd the original conditions
that caused the lost interrupts are li= kely long gone...

And if they aren't, we'l= l get a reproducible test case to judge what the right workaround
should be.

Warner



If=C2=A0 &qu= ot;10"=C2=A0 in=C2=A0=C2=A0 " atkbd_timeout(), called 10 times pe= r second "
=C2=A0=C2=A0=C2=A0=C2=A0 can = be defined by a control variable ,
then
=C2= =A0=C2=A0=C2=A0=C2=A0 it may not be necessary to remove its call , and
=C2=A0=C2=A0=C2=A0=C2=A0 polling rate may be set with respect to= the suitable needs .


Mehmet Erol Sanliturk






--0000000000009dbb4505d4d06944-- From nobody Wed Jan 5 20:46:00 2022 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 8B8711940926 for ; Wed, 5 Jan 2022 20:46:04 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JThMv5zvCz4sjB; Wed, 5 Jan 2022 20:46:03 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: by mail-wr1-x432.google.com with SMTP id q8so604842wra.12; Wed, 05 Jan 2022 12:46:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=BOPy9iHeIu25SgZ11pgNp0/ErRsZ5D6TmfD6c79+kMc=; b=HbgpNIWWgb1qaU/lXlAnwDY8lVLkyc0NcKnEax9peCW2YlmAuR2jD29o8BYTm8bk+c yU98hO/d+CKNQ4FK2RBZiwj/E4fvpaLvZPiIAHsYdSELGYrCiu8C41wzWQA1drGNr4r3 N4Dg7yIKPTIt3C+Ja72wXDm6ZEDjg7DT78+cjstCDecdzJ2g9hEEXfPeFtli2dpEbt5e DrnZOxXK1pWevS57psU9vMiTqUxGAxyeZoBHtkrMWkmy7GpU5ZddtSJxKva7nWsaGFe2 rvX3IDszv2XmJSiJ/VlnQW1o6i/Bg48oGKcehuA4xKmN2CjGbyRThTFfLBTaXHSVLy+q hGYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=BOPy9iHeIu25SgZ11pgNp0/ErRsZ5D6TmfD6c79+kMc=; b=5cHMSeSe4U50u2P7NQDm9VO5i2i8kLL2zY6xwaBYJEU7e9mYGgvv+ebedPCo/RyYmz GHEzXHnlGkomCJePTnSxFjJH9FEFe4xc5GgB5/yqT5jjU+QQoErHvlKhye5gt1F5eJqM /li2Tq4SigJdiGmcAemxMoyb0E06ONCSnlWsNFwtGZEc7dc5sK4xz0ccah1QpoW3t+Qz pZ278IdjVTxYy/Uwm39prhnobbU4g3/1FBlFp1t+aue6RYt7+Mf5tz9A4LgMMjOZ7Wup FFIzA1cgg73TA1h6AKVAbJcZL7aFMkxvR+Buh3U1axGMctu4HRCE6KCzQw+tKeBQQ+Qg VBEw== X-Gm-Message-State: AOAM531yJCBp9O9uMNH5knW3Top8wXwpF5e5hfHHt2mjsscnB7Gq1zHe gTpP15zn3x0PgKnhP/W/kffy5SDvXXQ= X-Google-Smtp-Source: ABdhPJwOmnUfhiEpGdFKlkekvqxBpSpUJ7iaDls4tWDnretpNEzzszYrzIcZfGU/l6G4AE1uQJWjfw== X-Received: by 2002:adf:f24e:: with SMTP id b14mr47406925wrp.612.1641415562785; Wed, 05 Jan 2022 12:46:02 -0800 (PST) Received: from ?IPV6:2003:d2:1f18:ed00::1d74? (p200300d21f18ed000000000000001d74.dip0.t-ipconnect.de. [2003:d2:1f18:ed00::1d74]) by smtp.googlemail.com with ESMTPSA id v1sm37935wru.45.2022.01.05.12.46.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Jan 2022 12:46:02 -0800 (PST) Message-ID: Date: Wed, 5 Jan 2022 21:46:00 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: atkbd_timeout() period? Content-Language: en-US To: Alexander Motin , "freebsd-current@freebsd.org" References: From: =?UTF-8?Q?Jan_Kokem=c3=bcller?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JThMv5zvCz4sjB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 05.01.22 06:41, Alexander Motin wrote: > Or may be it can be avoided somehow 20 years later? I'd be super happy if this was removed. On my old laptop I had to disable this code for many years because it lead to hangs in my (non-standard) setup at the time: -Jan From nobody Wed Jan 5 21:04:14 2022 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 D56DA1947943 for ; Wed, 5 Jan 2022 21:04:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660061.outbound.protection.outlook.com [40.107.66.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JThn26NWZz51Xc for ; Wed, 5 Jan 2022 21:04:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jrBt55VrkM/BBu2dv8K2QTepwgdQ9nrEqiH+XZQBjfIjCnDAlHGKsOFsJfuQ2TyI9puPj+aY4mrXHKsKKFN31Fgiu6Gn0t+T72ww/A+d/EuVC0cFV36Z4+ilBkJkFdAwVEcNtc+uJNZkhu0g8gJaEWVXqRzZdcvqAkSsEiYTlX3izYr2ukHiAg6B4ngouvmaetL+GJykbsi52Mk9V8FpNO2/j1fYA9DgWtDBkXL+TjLfmxEn5Y/f3C+RbR77y9301uSrQDnc4xtM5m8vrtDgVv28wAmYaVjw1d+cTzPfrxO2FUgNo//2iaAEFKxgjuI6YgXPjofRHJpMR86dGg8ZoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LuP+hXdAUwpaM3bL/ByNeiFC+8cOIkqj+FNUo0oKDeQ=; b=OeDVGr5FcAg5FzDDi877FnvV2S+AJbaHCOWBlhrMMicYJd+S86Efgov/tQhUp3OK3YZJw5tzer4DPhyd2kjsKult9yHoGH6rfQO4N3pKAxkittCwpuhvZMQav9gBBb3vYmKgpiQx/7we5BGA5/m/xVuutEBp/QTBTOyjBdqKRggxojThvG754zMk44qqDptPCO1isEyCF/IliuPBUpGmZ0q77dItUtNqp+ojgy+7vxAE08JQW8lPH+G7iTGyvl/ETvRYMPFHJTyJzGaBhq2F8dIe5GQPEgvsbCVkSdBPY5M5oQk+q2RfUVe5svteN6LYmtj2hPtJS2JB1Hy+52jvmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LuP+hXdAUwpaM3bL/ByNeiFC+8cOIkqj+FNUo0oKDeQ=; b=kSJvxHKyV2wQMN7uL0WzYVB4AfGvkFGn7LHmt8O9+rwdc3tI53FVkFh3PgFMASiTMFEHnWfk67f7dPQCcxmq0ETf1yrAUlXCK50PcfnBefjNv96iVkJ7Gwk2hNV1RAEicuNtOTND5awr9GT8JKihYySBkfsAnSz3s2JCFosfPg6pDniBmQ5TTK0kF81OtU0Vd0igeaSNORBK2FUuJU5/onQLe3azCN5Ywakhm18MP4/CxdRszmfGjSPkANvQhs91Sch31elvaWgyNQvJZVPFdAczrHPrDJBZFRiensSxRBdI5ABa8x/ZUdkFO636cKdKwQtVtmitnirNqu7YP6vaTg== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB2276.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:5::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.9; Wed, 5 Jan 2022 21:04:14 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::50bf:ecf6:9d13:fd03]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::50bf:ecf6:9d13:fd03%4]) with mapi id 15.20.4844.017; Wed, 5 Jan 2022 21:04:14 +0000 From: Rick Macklem To: Zaphod Beeblebrox , freebsd-current Subject: Re: Writing large build logs to NFS extremely slow? Thread-Topic: Writing large build logs to NFS extremely slow? Thread-Index: AQHXvWMEhXhFzFqRLESM9Us/FueWtqxVcvPx Date: Wed, 5 Jan 2022 21:04:14 +0000 Message-ID: References: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 181dcbc6-2538-d681-6ad9-d57d3898a296 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 660c07aa-d402-41ed-9213-08d9d08eee07 x-ms-traffictypediagnostic: YQBPR0101MB2276:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2958; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GEaSCr5hITVGhTuvS4cUMDwo2yB40U7tJGOFPpHDnZkkGARAwetBAR+7yKIViBaTu/7iVYPAkQ65MIyFG57OC4Q3CzzYNrk9z2awGMyO3E19zQJMs4iqoLKrsZ5Nyr67dbkbBg0VeaC/+H35hAhDTgKzdoH0LKx6Ywc68vrnnuAK5yOUUjzyg8BVYXN6M0hRMLjF89ezTeAX5HSdKw+NM06YLq8sKwYPUu8mD9KAo7WYGX+ikwifyRB20IklEgzf1uBynyk2bfaSKshDfHa3stLPcnfEKzfwGpYfzr6UTx5FtQ9pfOH1M6VqMahciUOmjA7XJzI28rlWCxVmf21FcHcLiyPf/IoowZn+6CpLiLrTkxATS+s0+8Ds7LP16IAeGpnyrtrTqNdPqHIHBXhewLpU4ssmOQ4Cc6Gx6DgwKZ20q7MCW3Y79VICFhFopFWCG68j5JBD+sYyAEOIrFWa9NR/cLdJRbvdGitzYEMfkJ6WZb+NBcfxTvIisomD2S/vH8eaIod+HcXKUCwF4yvlsS6359/of89IlmIKl5p5HOGa7GnYlO39uVeU/5YmEfe6L11ybX31r7N5sejXgm5loiJvqflrf9qnZ6AZW1I/bdRSjitdXvAmE3On6dJ3fOK0D8l4Liy52xVLUPjDBVH0ZtiqGxdyQ8pt+qqPcRZTLqsixcaXl7vfs7QwAi6Qd4tcYzB4qIGbKCHEFLocR9FE9Ze8T3BiypqUscO3zSdAZQ5Nbb6uFZfHFThOw0m7uxxJQ3RmTf1NqNGbYrmE68IDmpbh/LI2tEly2ZM8LXgaEb4= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(508600001)(2906002)(110136005)(83380400001)(966005)(7696005)(38070700005)(8676002)(786003)(6506007)(53546011)(8936002)(52536014)(316002)(38100700002)(9686003)(55016003)(66556008)(186003)(64756008)(66446008)(71200400001)(5660300002)(33656002)(66476007)(122000001)(76116006)(66946007)(91956017)(86362001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?zCXWUXdKioe5ETAaY3AekIA7tmICljSdgeWA5K1+jHXbzWWiytpiZAEZ?= =?Windows-1252?Q?ND0m1R1vdpWfLakeaoA+Vh09CMGIJIW+wVC61O5J79nLzRFNgRDNh3Dj?= =?Windows-1252?Q?aLATn48YbDyV70qZCqqkQu/6VmsXT3pkHAXR5ifJmyDD207+qf2GTCTX?= =?Windows-1252?Q?kjhpBPKK8pYDrMdKA6aibtXn31OLgUtMsmP946E+TD30SwKSFCriiIln?= =?Windows-1252?Q?C6fljN8PwwR0Qszgqm/JNz7oRJzNCCmb+sv5UFfTFHP3TGzK3HZ7klqV?= =?Windows-1252?Q?wlauZAOI9BzpyuckKo3t5qaWD0+C2wbTUqDdjAL+DJ1I5k7LavWi/K6B?= =?Windows-1252?Q?PAUOUk9ejR/jOzy2jj5Eli7ACngs91CBeZe2EUF8Cf838jbByZZgnZNW?= =?Windows-1252?Q?i3Fxi+AGnWxJTuzh0IfeE7qSAkjr+cQumBASCRY11ut4ccpgw0RrLN9+?= =?Windows-1252?Q?Cc2mBIJF4/BNxkNrc9he+qMcw33gq1Amji8MHpk/Vu4ED0e0F3xfkYL7?= =?Windows-1252?Q?Pwlex7qNsV+JU1h9M+znzhO3KVU+he/P0snpDkWR4xMkOL6avS3k1t4Q?= =?Windows-1252?Q?MYDuDx6TM0oaNLIXObmZn6ju3rEeCSOO1QGocbwlQtlQr2aI9+eCck9H?= =?Windows-1252?Q?1UX40lQRORcWl8jxwXl4B+82FHxcYBsf3p12bcIgr8Iv1kmDEAaSrN53?= =?Windows-1252?Q?sTlbjEKhz1WxWp5sdjU6OWPxk+CO0OzGbUjNg5jEQZIVCAjquNxUHpxV?= =?Windows-1252?Q?YWUAai4JlhPSYE7NCdUdSe0e5W419h6VZ7+doY0lsPKyTA64VdyBr6Wp?= =?Windows-1252?Q?ZVkdhiXDUlHsI9yWEp0wahm45RsMbCkZK+KR8W+cDYw3Q3/3ke3doD6u?= =?Windows-1252?Q?A9VoeZ7+u1lwgPviM5S7bSAIR5hfxekLpr8nZfVv8iS6CYCE0jIRsUjZ?= =?Windows-1252?Q?ijdcLvVi72oBJ98i2qSZZZbV4+DcgUYd22j+UturritMKJ3Ie3H+GE4I?= =?Windows-1252?Q?SV70Ui0PqVyR1u86Lo5OtLDbfZsxOxJz8s6zGW7fZwrrIOKOaTHBqHAn?= =?Windows-1252?Q?498NVcpNgjm5c3plEX0/PrG+PQh8//i3+bppWaPkv3tlrrK+PeGN46Pj?= =?Windows-1252?Q?VQwEcP41Bv+OjPs7MFjn0qS1UTsn0NkOUNfDrsBY7W4a4ohdZ3BDUn1i?= =?Windows-1252?Q?Jq182JZml4zX+O/CLeJ4jRtK4vH6UD+9zCJohWnjH4QKt67wINoZ59/c?= =?Windows-1252?Q?UcXDVI5nOa9Kt6FYf7nXlJQ/CLbfnbjg4SzF35hSt+XULqJ43UEG8Ezd?= =?Windows-1252?Q?0Nv3ywmTagoqILJnewequE5MkeAyRm4a2i90gr6ZdXcB+tRdg5xNS5xB?= =?Windows-1252?Q?8FtrOokMfz9d1cUpIoHUHIqCWqjJ6D2tdT9pUSr+QoB4R6AZOfNGkyv1?= =?Windows-1252?Q?giemIB+xcyfL5CBclyx3BNJti8tKm3j408gDk4LJiSdVKuskHKwSzqzu?= =?Windows-1252?Q?fS/XM7RP3zDTGVkIHqR+atJxi3wn55nRwPCVhSuZ6YJJ1qq4cTjApKEm?= =?Windows-1252?Q?MWPnl2TaqoheXPDfyNxSdIud67G4CUgLOiRk+3JC729+aBTn6A87WWzL?= =?Windows-1252?Q?LZ91wLzynty/YdHuQZbP5KAoh+vKy4sq4lbIa8gGQfO/R8lUhDLU0li9?= =?Windows-1252?Q?G7VA6ukYrJUyxcZYBmIw+HyLwXMS97ca669lVS7v0mZpZOeIAatLQA7K?= =?Windows-1252?Q?pcoKHJNe3kqhPW9sXq4u+gQSOeZwvuS35eNP/cEJM5s03cCRceH/p9Dp?= =?Windows-1252?Q?d6WVrA=3D=3D?= Content-Type: text/plain; charset="Windows-1252" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 660c07aa-d402-41ed-9213-08d9d08eee07 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2022 21:04:14.6574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ai+mrrHQkQmQe3qZUvxLR3/ZAo+TYlRVb4TTdliy3bHdJ10E9zGNeoCxVUyYQKoUmC4DhYQp6wjuJPU4inYt6A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB2276 X-Rspamd-Queue-Id: 4JThn26NWZz51Xc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=kSJvxHKy; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.61 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.01 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.99)[0.987]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.61:from]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.61:from] X-ThisMailContainsUnwantedMimeParts: N Zaphod Beeblebrox wrote:=0A= > Is the NFS mounted filesystem NFS?=0A= > I've found NFS mounted ZFS has several=0A= > pathologies like this when there is no SSD cache and/or log vdevs attache= d.=0A= Just fyi, I've recently committed a change to main that changes the NFS=0A= client so that it does append writes directly to the NFS server.=0A= This improved the append write performance by 10x for UFS, but only=0A= improved 30% for ZFS without any ZIL log and sync=3Denabled.=0A= Append writes over NFS is still MUCH slower than a local file system.=0A= (Partially because it has to do every write to the serve FileSync, which me= ans=0A= the server must commit the changes to stable storage before replying to th= e=0A= RPC. It also must do a Getattr RPC against the server before every write,= =0A= to get the up-to-date file size.)=0A= =0A= This change won't by MFC'd for a couple of months and is somewhat broken=0A= in main at this time. I am working with kib@ to fix it.=0A= =0A= rick=0A= =0A= On Wed, Oct 6, 2021 at 10:18 PM Felix Palmen wrote:=0A= =0A= > Hi all,=0A= >=0A= > I use a -CURRENT bhyve vm for testing port builds with poudriere. As=0A= > this vm is only running when needed, but I want to always have access to= =0A= > the build logs, I use NFS to mount /usr/local/poudriere/data/logs from=0A= > the host.=0A= >=0A= > I noticed some few ports take ridiculously long to build while barely=0A= > using any CPU time at all. On a closer look, that's all ports producing= =0A= > a lot of compiler (warning) output, e.g. gcc, gnutls, gtk2, =85=0A= >=0A= > So I assume appending to a large file via NFS gets slower and slower. Is= =0A= > there any mount option I could try to fix this? Right now I only have=0A= > `nolockd`, I also tried `noncontigwr` which didn't change anything.=0A= >=0A= > Thinking about alternatives to NFS, are there any news for client-side=0A= > 9p virtfs? I found which=0A= > still builds with a few minor adaptions, but trying to mount a 9p share= =0A= > freezes the machine.=0A= >=0A= > Would you suggest a different mailing list to ask?=0A= >=0A= > BR, Felix=0A= >=0A= > --=0A= > Dipl.-Inform. Felix Palmen ,.//..........=0A= > {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de=0A= > {pgp public key} http://palmen-it.de/pub.txt // """""""""""=0A= > {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A=0A= >=0A= From nobody Thu Jan 6 14:06:14 2022 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 13F99193BB3C for ; Thu, 6 Jan 2022 14:06:28 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JV7SM00Vfz4pWm for ; Thu, 6 Jan 2022 14:06:26 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id A032710B4FAA for ; Thu, 6 Jan 2022 15:06:19 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 97C0710A3309 for ; Thu, 6 Jan 2022 15:06:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1641477975; 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=wWSDi1mVtLJlcKgM5gAqoohvx95o4m+xvSLUMpuJqBw=; b=T63CBM7gP4lchNzWNvrgbPEeuKJH2LBgFZZwpUljscZwiGeA85I0ZVrTfnJYed59YVs0v2 etVxeNG1bzmEEn4osWaLjmlr1RcjaupCGtRpCheXpvDM4Pu0G/zqjtl7QxGsCwSlyJHOEz GVOczElmxybJn8onpurCm7dYIGOsnJN/lsJ6548aX2ImSgwzF3X/U6sPnqUJJCht4Zx1n2 dLxsVGG8d6uyGguCLJjH5309EhnNUPIDLYXkwmqqaAtxq9hgNutzzU91LF3ryA4QXWpf/o O8kh64XGkoSjC2Qyu2USOOZ1iHPqMwEg871dfbA7CaRfqToYUKfKI7DKm3oq4A== Received: from hermann (dynamic-2a01-0c22-adf3-6a00-9d6d-1157-fd6c-6880.c22.pool.telefonica.de [IPv6:2a01:c22:adf3:6a00:9d6d:1157:fd6c:6880]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 6EB5C10A3308 for ; Thu, 6 Jan 2022 15:06:15 +0100 (CET) Date: Thu, 6 Jan 2022 15:06:14 +0100 From: FreeBSD User To: FreeBSD CURRENT Subject: 13/STABLE: usr/src/sys/x86/x86/tsc.c:718:8: error: use of undeclared label 'calibrated' Message-ID: <20220106150614.1382088b@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 1f758b X-Rspamd-UID: 40917c X-Rspamd-Queue-Id: 4JV7SM00Vfz4pWm X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=T63CBM7g; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:30) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-0.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt-de.de]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_SPAM_SHORT(0.99)[0.987]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from] X-ThisMailContainsUnwantedMimeParts: N With mergin a recent commit today involving /usr/src/sys/x86/x86/tsc.c of FreeBSD 13-STABLE, compiling the kernel results in the error shown below: [...] cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -shared -O3 -pipe -fno-strict-aliasing -march=native -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.hack.pico -MThack.pico -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-error=unused-but-set-variable -Wno-format-zero-length -mno-aes -mno-avx -std=iso9899:1999 -nostdlib hack.c -o hack.pico rm -f hack.c --- modules-all --- --- all_subdir_aac --- ===> aac (all) --- all_subdir_aacraid --- ===> aacraid (all) --- all_subdir_accf_data --- ===> accf_data (all) --- tsc.o --- /usr/src/sys/x86/x86/tsc.c:718:8: error: use of undeclared label 'calibrated' goto calibrated; Kind regards and thanks in advance, oh From nobody Thu Jan 6 14:16:22 2022 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 CB598193EBD5 for ; Thu, 6 Jan 2022 14:16:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JV7gs4hrWz4sj1 for ; Thu, 6 Jan 2022 14:16:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x836.google.com with SMTP id y17so2356217qtx.9 for ; Thu, 06 Jan 2022 06:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=lRZSHH/boL3sxn1PYLym/E4CX9m8f6EH5Md2fzcF0mM=; b=UJjg3XWhzopVXBKmGeLpiprFDgY8zMN2zSUi5pF3rfUVeIEQdUdg38bNeVh//NPpGP Uu0vyxMnBeDsJwYYjluUneFGHurIu8O5Erw3TSkd3A9y7HMhk7iWkr213sLRoBRq8feS sznkVhMHBjN4SN4Mng3eOOcDGj97B6/6KlpK6uxqrzC8OmdLRBE240wju14FJ3QC4lpx 1E+zHARRmJEDZPz4IFmgS0TJ3g+ffvSNpFEO5AfAI/whVlHD0X0940pLZ8kTGTig9XkQ 6KgNZCSjQ8nnmjuSOVHBOGXK4yjWqvGYmEa8EENMHNbvm++3w/XisWNCY2aF0+pN0mpj fomw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=lRZSHH/boL3sxn1PYLym/E4CX9m8f6EH5Md2fzcF0mM=; b=LtmTILnyvgExN7TCxyjOdyh39NgrxVgmF77WJa0qS8ZgkCvL32hvt4ycDD3OJtghAk Hq9ytCiPFs2JsG9JgrFAJyrUzC7D7GBY1JPCGaBESyf5zvbi9yi+jyLQcZ1oG5slQdcH /tGmEh6czwPOR+VWbWWfXCTE9zGLZs6ev7rdR477FZvQaGOxrXxJ3PmNvoK9TS39VSWN XINK43ECQjvTgNUoWlbGgagIwEUmBYvw4gFl3InOoIFQOiKD0XerYukkPwj5Xg5DFXw1 EFEVVZd5JwCA86x0be+0UxprZ63c0xAHvYn5BN2DWkh270kXiXtjfwTsMs1iM4P2ppCN GvkQ== X-Gm-Message-State: AOAM533Vst2xhS7qTmBa+9g0jnE3/PToln6sDMr8LODcvg54xwS9Acq5 40SWabfOxjKIe1lW0MgSIv61CBhEyuo= X-Google-Smtp-Source: ABdhPJzpp1jKHYb1iVqu+Ba89+KKvt8k8IHStHPY6ysu1Bog7Uh5ncKb0G1yAA6ZE8kikHBHFg6pSg== X-Received: by 2002:ac8:5d90:: with SMTP id d16mr5264527qtx.588.1641478585135; Thu, 06 Jan 2022 06:16:25 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id u6sm1602367qko.83.2022.01.06.06.16.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Jan 2022 06:16:24 -0800 (PST) Date: Thu, 6 Jan 2022 09:16:22 -0500 From: Mark Johnston To: FreeBSD User Cc: FreeBSD CURRENT Subject: Re: 13/STABLE: usr/src/sys/x86/x86/tsc.c:718:8: error: use of undeclared label 'calibrated' Message-ID: References: <20220106150614.1382088b@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220106150614.1382088b@hermann> X-Rspamd-Queue-Id: 4JV7gs4hrWz4sj1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jan 06, 2022 at 03:06:14PM +0100, FreeBSD User wrote: > With mergin a recent commit today involving /usr/src/sys/x86/x86/tsc.c of FreeBSD > 13-STABLE, compiling the kernel results in the error shown below: > > [...] > cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -shared -O3 -pipe -fno-strict-aliasing > -march=native -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD > -MF.depend.hack.pico -MThack.pico -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include > -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel -mno-red-zone -mno-mmx > -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv > -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option > -Wno-unknown-pragmas -Wno-error=tautological-compare -Wno-error=empty-body > -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign > -Wno-error=shift-negative-value -Wno-address-of-packed-member > -Wno-error=unused-but-set-variable -Wno-format-zero-length -mno-aes -mno-avx > -std=iso9899:1999 -nostdlib hack.c -o hack.pico rm -f hack.c --- modules-all --- --- > all_subdir_aac --- ===> aac (all) --- all_subdir_aacraid --- ===> aacraid (all) --- > all_subdir_accf_data --- ===> accf_data (all) --- tsc.o --- > /usr/src/sys/x86/x86/tsc.c:718:8: error: use of undeclared label 'calibrated' goto > calibrated; > > > Kind regards and thanks in advance, > > oh > Should be fixed now, thanks. From nobody Fri Jan 7 11:39:03 2022 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 E6D391946EDE for ; Fri, 7 Jan 2022 11:39:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVh853ptmz3myn for ; Fri, 7 Jan 2022 11:39:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641555550; bh=0vU/0VqsB67FDxYZA6iZDdnvJOE8c21LaXU76jXTHD4=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=TsIQXFnmmjtXwfobHkfP0YLGLw46x3yXvcAODbqpbOlyb4pO978nHVXVc1EQv3+X92Es9rxiUoIuiQH9Q6no8VLYmv0EKRJUkErAZQ5PBW8cNlm0Hi2cwdZeBy1pCYtz+01TxVlridtFUuD+gRIyRt52BWs/NsshpuZZ+fKfD0EoHSzF4W3Hb6yO0WEjp0VAk/QQkdETGG73ba5cwF65YllZjD36zaPGKUjN7KpYbiTLANkmO4ELNT1zUQCjV4ot7VlLT3LTYy5peVGV8RUMRHssv1eRUE/Y9YJ6tzVxWAsogv+ueJP5G8nal7GeXcSOUyXc1IssfywdOzrETitP8w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641555550; bh=DH/QyuO6M/C4JaCGL93NR6/ulqbQuE64EuxB5Znw8VZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NMDU/Sv/it1IE+BzxMsh6BIrnceFAUqxsYY9PvyepdqV7QfvyuyMqXlD6jxKfF23MsTm5rSri5xtdavf87CKVwE0A/T9qnmIglvrxzGQ1OKTZYEjd2/STZNFv18ZSfDVNVG6m6aZYED4YlMHXEjfjEjfLNXwJInHrMWOhnAOVkzGYmyC9fOvZlXQ9T5IJ6yeDrxbW5wYUK547Zlwq87E/212Wcd1Y7JzKqYPv2Um/x6ul8zl67qLOA7fCO0Z7MjPj76whXoSu0jwa77k4BzMmkAdE8ceh4+cpEan5zCA5ZtiB9XEEJj4E7AJsSRREXdi3+ch/CQkiw2vB9a8ixwZmQ== X-YMail-OSG: JgcNIB8VM1k5XPqu_86AtCCEUSius6xtF4zvrwzEHSrW.XwGtHpryxfARCykpaF AU._FMa.Z0_m_956KWujpM._xhqB7.c4T1GEVbvHLn4J3J7ETVvxXNQhEc1Zgz0u64fEbZYkKxp4 3vJ1vq5L9LjbKyI6qkMQNgZ5ITKi3GJZm7ghAyXV0MScd5nkJMJZ0_vxxlfRq1I3sg3yYqcQWugC b2wYJa5QYAhCErmqj4FWi2fru64eH3pIooIW6MACQ8YBg4Vuv_.iX0gDokH.aDm8wzzvLB7hjiDW yAJE.Ka3PloEJ3AXszGIMbHs1_va5DqFoTE1Dl37B4sZj24Ea6o79tAmC9gf4PDg.PTJhGawy6zI UJM3SoUN.eIYSO9X3FuD7alrd0EEQsd4OgspYCoH5j2Aa.MsaplRU3ttR.Undu6N82PgRg8Htcjt z2CZgnur8HzLDMHHZ3tm48usmxJX7HG4xabm3AxxOxLDDOZX2hyjqmSKzRjQpFYDm5OgcmWtS9Cp d73ZWVD40jAvqKpOBQ3bX1WforHfgnPLTVuMWbWYHSazYVtB71cITf4un_fU.q7dB2JNtLB2itvR FGf2gJnNFZLk3VuF2_utyoaJym1KhPlEYPIvxVtjNye7kFLfABjl77Pr7AJAy8FJOi2bPRlzrr5K XA3jx4qiHGUGLV5PG.eQGARyt2aXLjclKzAWG8qmQdCNNQblLiPjIHdLAvPEohFjd3ekYOr6sWxe NeJCxOYd9sNBqtxJnPRGN5I12tWG2xRRlAAsIFGIAp9HiyEpjrvCLSiBOfoep4fym.HNV4nHB4Fl _tdDuUbQhsj3VxbESnb79tCGIROLU0wRRpLlNLsC7DxfTDpIkO0xMSzye234Wwq88qrJtkGWpm2W LwletwrqVAXaFBi.oX4dM859LGbYtrG5EhOh.FJP8TX0nwV17Y3Oo8.wTEuMX3cHRVSP0Zx9zCmV gdWa0iJMbfHquws36CTzYYQl6ttHoTpQWwsoeAsL6W.AoW.x8bYQTpmwBmjdMcARM7shUGSt6_Pp 27ll_NdKyo2Hpn2Eu4so8MSQnCvMlo.FUXGAwqxudLYU6VT3bBBEJpxm1r.BmcvCk3Ppuelznsf6 ybszKAjsSyDPEHtxRarrvMb3Q8Z_aPZiJyGHPpSfARR.TPNy6DRYWzwMGI.wDPNri1E.UQrj59bO 1v97Oqw0U7_MzKhY4ZKlbIpBYEo7GtEJ9aE8YkEbKQfEb1E5Wl6L_b4F7xiGZWKgyuFqZpSmJRk9 fZRf8gJ_mKhMwFGsymSjZgPY.lqTvxVqTSxpEhBQZM.yBOs2DAsDjej4pCO6uxGeU5sHYV2JBiPP pJXJ48xKN9RKM4UMk5majQCjgG3FbFAgd_RKZ_i0cEm8Cxt4TI6iFCP8Mz6nrCUZ2dyaZYmYyVRw T8KrKxif42TiLTOFlMCr0jhTH9.FG_20W0MRZGp5fmuxbnurZ3CHnj3Qi7FkqIYnMHSCt29ORwhR y938lGdSEDaPCeIqwINEEzB2n0WgetX68nLGkKZAUCoi7HP0FNlyr0C1D00ianErvtWjgrznZjk6 7Xj2avqzgQqnDB1G6nzZuHxR3pCEwchpp24GBlbaI4wjsuP0sNfwwtj0dfUvecGKcLLXMMVSrMWb QB15ZRV.tl8NJmUDL3Dfyk_GLgJ5e0d.7u0hYwmmq.G.1zdcQ_ht5_gDTYkeHvhw41RKDJ8RizUC bPUq7_0MSynYR3EvsUpsByoosj2A0FGFCUg3mw3tMNATIxnuP8nvErfrvOrxSL7LMgBMxkp3m2cy N1yzBP2OLnyHt4yx31FURXlnlAQP0BqL0GJ_.ky7Y4VAo5ASL3j0j6Jh0OKyCGQVM8687so2qBeX YyxSLzQL1mdlpZKy2Bqodf_laEh_Zrx9lY6jcCTnJ1wt2A9q3OF8JeO1sDvEWKDwobVtzmEl2aFa SSfULaMKZ62NFRlKjO._5NQFZZJ32Hu2DRKpMmUmYjdLnjb8R1tMSQZmzO_U6fM66E82gxv6mR3o bDOzONDMiZbHvKaNW7MIGiP3w_64.nCLA1RCsz389zPEWv8CXOiZJG67NP3BPD0BHcIeSCUSvWCr O4bFyAoDM7DnQwH7XBNP7ynjekJOf_5YrqJsvleMhGEWCgWzny9VCNXE2VnSSVItMceaqPURo_Dx eChZR8qLvcYFbDxIp0GdJKFs.3YiF_cQoVhQyWlSNidrzPWxw3zaIke87mg.ijgEzgN1Wb0s3SZi Lp7lv7sl60rL232N3 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Jan 2022 11:39:10 +0000 Received: by kubenode507.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c3b197f4b72370d170cad1113b1aecea; Fri, 07 Jan 2022 11:39:05 +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 14.0 \(3654.120.0.1.13\)) Subject: FYI: An example ASAN failure report during kyua test -k /usr/tests/Kyuafile Message-Id: Date: Fri, 7 Jan 2022 03:39:03 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4JVh853ptmz3myn X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=TsIQXFnm; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.84 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.147:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_MEDIUM(-0.77)[-0.774]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.147:from]; NEURAL_HAM_SHORT(-0.57)[-0.566]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_LONG(1.00)[0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Having done a buildworld with both WITH_ASAN=3D and WITH_UBSAN=3D after finding what to control to allow the build, I installed it in a directory tree for chroot use and have "kyua test -k /usr/tests/Kyuafile" running. I see evidence of one AddressSanitizer report. (kyua is still running.) The context is: # more = /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stdout.txt=20= Executing command [ mkdir /tmp/kyua.FKD2vh/434/work/mntpt ] mount -t tmpfs -o size=3D10M tmpfs /tmp/kyua.FKD2vh/434/work/mntpt Executing command [ touch a ] Executing command [ rm a ] Executing command [ dd if=3D/dev/zero of=3Da bs=3D1m count=3D15 ] Executing command [ rm a ] # more = /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stderr.txt=20= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D14384=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on = address 0x7fffffffa948 at pc 0x000801f38f5a bp 0x7fffffffa830 sp = 0x7fffffffa828 WRITE of size 8 at 0x7fffffffa948 thread T0 #0 0x801f38f59 in strtoimax_l = /usr/main-src/lib/libc/stdlib/strtoimax.c:148:11 #1 0x10de6c8 in strtoimax = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:3441:18 #2 0x11a4723 in getq /usr/main-src/bin/test/test.c:560:6 #3 0x11a4523 in intcmp /usr/main-src/bin/test/test.c:584:7 #4 0x11a4523 in binop /usr/main-src/bin/test/test.c:351:10 #5 0x11a2f06 in primary /usr/main-src/bin/test/test.c:317:10 #6 0x11a2f06 in nexpr /usr/main-src/bin/test/test.c:275:9 #7 0x11a28cb in aexpr /usr/main-src/bin/test/test.c:261:8 #8 0x11a2a03 in aexpr /usr/main-src/bin/test/test.c:263:10 #9 0x11a228b in oexpr /usr/main-src/bin/test/test.c:247:8 #10 0x11a1fcf in testcmd /usr/main-src/bin/test/test.c:224:10 #11 0x1145289 in evalcommand /usr/main-src/bin/sh/eval.c:1107:16 #12 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #13 0x113fb34 in evaltree /usr/main-src/bin/sh/eval.c:225:4 #14 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 #15 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #16 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #17 0x113fc55 in evaltree /usr/main-src/bin/sh/eval.c:241:4 #18 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #19 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #20 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #21 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #22 0x113eb88 in evalstring /usr/main-src/bin/sh/eval.c #23 0x1179727 in main /usr/main-src/bin/sh/main.c:171:3 Address 0x7fffffffa948 is located in stack of thread T0 at offset 264 in = frame #0 0x801f387ff in strtoimax_l = /usr/main-src/lib/libc/stdlib/strtoimax.c:58 This frame has 1 object(s): [32, 36) '__limit.i.i.i' <=3D=3D Memory access at offset 264 = overflows this variable HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow = /usr/main-src/lib/libc/stdlib/strtoimax.c:148:11 in strtoimax_l Shadow bytes around the buggy address: 0x4ffffffff4d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff500: f1 f1 f1 f1 00 00 00 00 f1 f1 f1 f1 f8 f3 f3 f3 0x4ffffffff510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =3D>0x4ffffffff520: 00 00 00 00 f3 f3 f3 f3 f3[f3]f3 f3 00 00 00 00 0x4ffffffff530: f1 f1 f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00 00 0x4ffffffff540: f1 f1 f1 f1 00 f2 f2 f2 00 f3 f3 f3 00 00 00 00 0x4ffffffff550: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x4ffffffff560: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x4ffffffff570: f2 f2 f2 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D14384=3D=3DABORTING Files left in work directory after failure: mntpt, mounterr =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 7 11:49:51 2022 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 11B481921D2D for ; Fri, 7 Jan 2022 11:50:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVhNR54B2z3pyj for ; Fri, 7 Jan 2022 11:49:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641556192; bh=kHvLWIolONi5VG84RZEDPYNBN8wmNn8RC6CmFkFG8aM=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=UohlHig4joZSvt2MWU7x23ht4V7U/IfehWYlv5esIGezvlC8uk20jtVgdc1/QMT/4vD6y7BN81IWfb/SYd0nCxE8BNqPxFz9JcYyP5xiQ8oweTHfjjnhN2V9Htn87ymIAcWMwh+6GI4tsbtIKUgrBx1mYzn309PQjqj3zQIw9w5fHP4+NKTtQnQDY3rwntxLFOZrmVx2s7zcr1WHIq4f+OCJkSXxxyve6wYk/oAeSjSXW73RVnzibeTk9bEoYEWjxLQLOJTPfir2e6aEirSRZStiSlJLyZNuW7caWLX7ybGkAUfDEiw6YoTIjJKhO8pnaChiGcyqdycwHGuLbbaFnw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641556192; bh=T5laz76ujQpY2BDTKilVIIbyjdr2/ibKth8ati/+Dpx=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=U+m+Xhf163gQt77SFIn2Rqx2FlsjnFL9/bRbUOSkZm78JSSvR+2Kai3vg2O+fv/xz74zFVCiDv0KW15PRZotLbEpk2XheQtrTrt/SCUBc5wdbx2jIi6nE5fXABaLbxEHI9s2uVxdP6sSFVBZP8u+Wq+fEv+wa2R1ajemq7xESG9Y8gPbKC+Hj8nMKIAfh/caZmcgAMsJBWhwaeSsXlpZ2PUKVjHNsW7nqcX7uvHrknfw0fycmjNkvOOIjH6iOuSgmTVeEKVyHQM72TIu8tsSZf/mfUbhF8SV+TIulyuiXWu/z7Qw6Xt+FgUxBUStAcscyes5m/9iCc0WJzHKu6xz8g== X-YMail-OSG: v7QI8G4VM1nq.IEUGCAEoXeWydcKHAZdQrIEpaey3lUYnf3tisdQzuXbxMheVD9 _yedXfrMCteB5P0kiWskXuSoO57NBgHzqyClivvUhntiYdmpP3ldmv8jcnT4v27MIwhVPekILKWB SuaZY8GH7Xg.fQoGIE3c8OsGIVgLAqL_e1HgdqfxAcwl6gtQqXBJpLNLXlth_2h0mCx03kshjOCU XfYfhJSxcnMYzjoujnsTDjKbbajE30BkTQf48FzgwZMWxfCp7fZApGx3BMRLoihC9oLd9h2G4gXZ gr_aHjyvFHSZY86F3Uc.m_EADHOa_zSPvTxTW3uS0PXXwnjkGFMMMd_dxpAH9VFVOf0w4_M2h6mU e6Hmd882SanAeW9OrEaqyq09BPM6UmVSBPErKcaaucP.Oz1_cNj2rxg9XN0BYAhFpWWEmQlm5hfs xy3lKEOwCoKj0wYh.megAovsgm9RJdUwoaO9usMIZedLiOwxVISVRbF0IveleLeXL0wA1jQ_opgT PZDB6wwbumknwgQJgpBMkFgu_xscj1F9aqdP0NojpvNGzjOp6XB8EMJcZH37I4rZ0tglluR11WNQ .BRBISctx6hAOgY5HykxufFpj0VfBbgv36_MU3TS7vTG45np.jl297F9SQgrhCn5uEjpexoGLJv4 vF4u17Osxss9W8IPVfEHju6KBf5mbGH0ZtyTG_FjXI91zdV0fZCiLpk0c95mWcKF8xwNxICp3UtV mVE4HigfvBnPqa8FEnT32Zr0AuN2rBaYH.ZZBeQs1YNEfAmIMsFORW71Qx0buJQIfMHc1KwTmCb_ DCRPzRCjLkyPFbPK.mry2AisVLOyye07UAxK2tTRub6MqsYkUNt67rLwrUWBAFi3LjU87eeNpm3C tTiVkKJSSR6HbnYSZ7gy_UM_K.UOMK8nSdLIgCKXZjrolIf.ZV3zTqSAh5N.q67vOLLkIEZ2RJuV uiSZfVHq1WQRbHDV92pxoC9WyjYKvTPPSh.KL5L72HCRCxZ0Vhyzm.dFfRFW72Uu0Np1r24Yco10 g2u3ecB4MrK7S4n51OZfmxKIBYgf_GxaeGj.kNljB9cAuq3jUOuXVqLwPCDGn2LjUUbok3ZZ4dWQ WKsCHM8QTeSBEmlNVJ3C1lHryg6m4lvYGk5fe7poNxzkPMRgAJipbHZzBbeRSFo0EF3FalhQQyda C1gvTmi7FCnv4CICkxDbbN9c.rhpRoQ4Lhpr_RTMXUO8QDW3LsO2XjL4.9WzGUlp9Z3Vd1LG00bi 2Z0fC6kn70sY10mV19OTdYPt9upD3.PXcuTJp.N0liExpvKQaJbOECBOUF8vFEwUyZWhP9nhndMh 2sFIqjsK.TgEfaIWtQbjNtd9sKANhuG0n6_INSuZpaks3OMzzrjp5P5y1_hqvxjsDv2LTZ2.VRSP M5Z8ySJJrl_FS1LiSj68zq.gYw8naUcYe2lQTZcBgUCjO.TnTofYSUouHchdshxg_XED9RNBX6WV oZ1kupbJ8FoYx1_Fc8MOirhmiYog8ZPHOqIW138lIRugDsDWtmT99LwKqrysiBzFvSR32eBp.zfS fXGWTedf_pgvOcYYG1zgFjUPoTjzJp5DckD_oVtDSFRIoUpbaAkJWuFoApRhq19qOCRPKQEdUz77 sQkt66c1ktPTIBjKDnwFahbeDHrSOCnEo_tAczBaD_Sg8LXBl30iHmKTTuTBOcOv0T07jsaUaDSI qbs4NkgGBll.eneRWKmsQtSnBPwPN_NZKQ4gVfu6nrIgz8MDx0d9stO3ftJCqn7WhYXmmK2yyOHa DErER5G4Q8yCqjbFhjLId2lWFGowI8pkAiFJfF96TgH9E1sRiaAZEOPMJEB.3TpS1Dr.fGuKsxgj xWrYEhLj2VI75jDeEYQLujQ.3yKpjOTeiO9XMBPfDzzgw70XDjd1kdPboYGK8sbVP3fuMmtRiWsB C1xzWH4069by4JRBuxw1uIR1KfC.mwvE_ZvRyEJQwqltqXLHxH7ivm06AN7SmU5FYgnPStqk9fER R89Jc9rwxzUk42LmE6T0NahTL1l_ZDLD3Nu88f85zxzmQ.Ofa2Jpo.Orue_ch8TZPGO.LeewhiiD dmm26lZHg5jj3V4SVr3NC8FYuHt.ICNy_VxrBL8yWo5wd0tnSV93Zco2XM8E5LSkLPQMplh5yLhF vAiU6YrIvSnzVI0LS9Aq4hk8ZpqJVWKhJ0heKMt_9F5usRvoKV4spidC43ZYCgaiu8UAeehFEjmq WKdleZleTAEEctBfldNYZ_ITngtKjUGKP0ypzX_x5D48zqwv.p7jaHmOrmit2pHfkF0TFDqaYBJk - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Jan 2022 11:49:52 +0000 Received: by kubenode527.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5dd90d809851eed317245605d2d4ff04; Fri, 07 Jan 2022 11:49:51 +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 14.0 \(3654.120.0.1.13\)) Subject: FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile Message-Id: Date: Fri, 7 Jan 2022 03:49:51 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4JVhNR54B2z3pyj X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=UohlHig4; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.28 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_MEDIUM(-0.78)[-0.780]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_LONG(1.00)[0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Having done a buildworld with both WITH_ASAN=3D and WITH_UBSAN=3D after finding what to control to allow the build, I installed it in a directory tree for chroot use and have "kyua test -k /usr/tests/Kyuafile" running. I see evidence of various examples of one type of undefined behavior: "applying zero offset to null pointer" # more = /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/356/stderr.txt=20= /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 /usr/main-src/usr.bin/sed/process.c:715:18: runtime error: applying zero = offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/sed/process.c:715:18 in=20 /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 Fail: stderr not empty --- /dev/null 2022-01-07 10:29:57.182903000 +0000 +++ /tmp/kyua.FKD2vh/356/work/check.Mk9llD/stderr 2022-01-07 = 10:29:57.173100000 +0000 @@ -0,0 +1,2 @@ +/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 Files left in work directory after failure: mntpt, mounterr In general the lib/libc/stdio/fread.c:133:10 example seems to be in a place that would make it fairly common. usr.bin/sed/process.c:715:18 is more limited: just sed use. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 7 12:31:10 2022 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 7C342192F70E for ; Fri, 7 Jan 2022 12:31:13 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVjJ1227vz4TBh; Fri, 7 Jan 2022 12:31:13 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from [IPV6:2003:cd:5f26:900:4c29:536a:ab75:1583] (p200300cd5f2609004c29536aab751583.dip0.t-ipconnect.de [IPv6:2003:cd:5f26:900:4c29:536a:ab75:1583]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 9E27C2520F; Fri, 7 Jan 2022 12:31:12 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <1fb8db3d-3d12-68ab-95d6-5f6e01af49f3@FreeBSD.org> Date: Fri, 7 Jan 2022 13:31:10 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile Content-Language: en-US To: Mark Millard References: From: Stefan Esser Cc: freebsd-current In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------0cW6aOMgqYKHje8P4UgSNdhf" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641558673; 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=sgN28PGgwuAMvtuX/iF9RxtBzqKORg87nu4qGCirdZU=; b=Qhhz6jnV/0vc/sFc+Dp+UNVIdhX+ZBXiaW8QEFG1UpO2IJFcCLtaJv4fbQVDYH4U4LwUN9 pWVLJB0Z4xVwnUE7vBUnzMDG/u88HY7L2r6rty0FjH1fexZ5u6ptQ7m3RJV1mpG2Dph4pq b/6tW6ei2OuPXwLyIy/dJBg6d9d1NZya9dLDkZ8peM4AeVRkkT8pkWDZ1ilH8SwoE8tIGM RDTn8LgNqwD2rTQmHiYQ6myVqLIQJsCDbRR60xv/8bhHMeNTn6Apg2JMxYeCD1E3jDbllx YfRO+Dqjp+tJ9KMuE+zd2AV5bsmYonAOQgwQNNJkhW8tfGoYlArVvvZJtQCmqQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641558673; a=rsa-sha256; cv=none; b=kXHli2EENeXMjHGwaMyMqEYsOVre2WBguiQ+bZWYFEG8mvfs16Ng78K3bDuF9oX24lLcMm g1bkTXd8zSoU/rQpnypyxA0h14hlKm6+KBe+ZyNFWZZIo1jUEld7BnspNBVhmecBraaqIV JKBAOxBJZDPmNrcFriN/Xt2Z1jvgYlJMBqAtb7/WcX9hNNwWEfi3VgKx16SDT+Pp5+wrC2 hUlHlxe1qx12r78sq53+81UtiJ0eEkGMChCOb3lzumxRhqTaxXHOZBMmAsUVXmL4rD5cJA afBsyi5YN/2/+eeXgd2PUAsRxKIl2iDPZZahTg3yPP61r2v8+d+OcuIhySEUJw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0cW6aOMgqYKHje8P4UgSNdhf Content-Type: multipart/mixed; boundary="------------dQNcQ4XtuFBT0tqIbytPK76Y"; protected-headers="v1" From: Stefan Esser To: Mark Millard Cc: freebsd-current Message-ID: <1fb8db3d-3d12-68ab-95d6-5f6e01af49f3@FreeBSD.org> Subject: Re: FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile References: In-Reply-To: --------------dQNcQ4XtuFBT0tqIbytPK76Y Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 07.01.22 um 12:49 schrieb Mark Millard: > Having done a buildworld with both WITH_ASAN=3D and WITH_UBSAN=3D > after finding what to control to allow the build, I installed > it in a directory tree for chroot use and have > "kyua test -k /usr/tests/Kyuafile" running. >=20 > I see evidence of various examples of one type of undefined > behavior: "applying zero offset to null pointer" >=20 > # more /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/356/std= err.txt=20 > /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying ze= ro offset to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/main-src/l= ib/libc/stdio/fread.c:133:10 in=20 > /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying ze= ro offset to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/main-src/l= ib/libc/stdio/fread.c:133:10 in=20 > /usr/main-src/usr.bin/sed/process.c:715:18: runtime error: applying zer= o offset to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/main-src/u= sr.bin/sed/process.c:715:18 in=20 > /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying ze= ro offset to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/main-src/l= ib/libc/stdio/fread.c:133:10 in=20 > Fail: stderr not empty > --- /dev/null 2022-01-07 10:29:57.182903000 +0000 > +++ /tmp/kyua.FKD2vh/356/work/check.Mk9llD/stderr 2022-01-07 10:2= 9:57.173100000 +0000 > @@ -0,0 +1,2 @@ > +/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying z= ero offset to null pointer > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/main-src/= lib/libc/stdio/fread.c:133:10 in=20 > Files left in work directory after failure: mntpt, mounterr >=20 >=20 > In general the lib/libc/stdio/fread.c:133:10 example seems to > be in a place that would make it fairly common. Interesting find: while (resid > (r =3D fp->_r)) { (void)memcpy((void *)p, (void *)fp->_p, (size_t)r); fp->_p +=3D r; /* line 133 */ /* fp->_r =3D 0 ... done in __srefill */ p +=3D r; resid -=3D r; If fp->_p =3D=3D NULL in line 133, then NULL has been passed as source ad= dress in memcpy() in the line above, and I'd think that is undefined behavior, even if a length of 0 is passed at the same time. Maybe the code block quoted above (line 132 to 136) should be made wrappe= d into "if (r > 0) {}"? Regards, STefan --------------dQNcQ4XtuFBT0tqIbytPK76Y-- --------------0cW6aOMgqYKHje8P4UgSNdhf Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmHYMo4FAwAAAAAACgkQR+u171r99UT0 HggAzNkq06QUTGT8lFrNwDiRmF2XCdeZyCfoii4u2ai6MHXZjy3dfcln/bAzCuziLWsCYUQbw26h 6fQ2x1IGePcCWR5v4+dk/DQh1wT5XAX5NrbMRjgMfMSvetNkOKPY4/hX72jecBv1+t5dC5bxgxMx fcb34PC5MVQJRXME8HiUmzWzRCZYTA9gPkTjx42cqquZhFhZ3tiCaTbpeN5Efi36EbSYnGyJmg+j 28p3cKn3T7ynMyfGfRkcDm6yK+L6RLJs4VLNJzDtuRZdl+AdcAM0OyIB0QhCwCaoA23CsuZc05Zn RZMZ+ctp70AElReRyIkavZnXTb8E09OecqxG0KUJuA== =7Hb0 -----END PGP SIGNATURE----- --------------0cW6aOMgqYKHje8P4UgSNdhf-- From nobody Fri Jan 7 13:08:04 2022 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 431E31939A6E for ; Fri, 7 Jan 2022 13:08:18 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVk6l2TjXz4c8S for ; Fri, 7 Jan 2022 13:08:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641560887; bh=D6sK1++fWWqlgENOucYmUfooFi8ci1Cb8y/Mr5fQ0AM=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=Q/d+4FaR6cv2AmqsJ/qy7u+/xNHl1S3rGj2CzCRMH0fGIfkcA/X5XiEFgAHh/k1nDb+8xQjaUeyNxLo4P6vfhEv+irrVjtKazGAt+uU7nfqgiRO+X/LUfv9aYWQz7eiIoHJou23xz4rmq5sVxVKhdSIWG642Rl2Mc5Z8gbtrWfseTVf4p6G3NT1Tq6kt9OF0pER/YpzUv1SKxCghyudzDx+bLs39+Y0K65zJsUJ3Cc4P7LT5YlQuMo379QORVmWbzWD8+LQ+74LlubX+JilDS+OYUTGW6r78Mg/MbySO6ozfcBXXARkFsM+9g9bkkKCsUdYAVj/kWIj50f9aeWIYDA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641560887; bh=t/hP6cohwBB6k1VHDuxOPFeiMy4ccJlO9BkR3cLpJ3L=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=bfCs0tLRHDxS8HM7HkvHEJTxIqy8asjeAHa6zWf8eDoeJZmdVJy4TvJyKeaq1jtjcFebdbglLtq9Ourg6sBCYObO9PtD/81ojmcZdNAmZw9it5fHrbPw7LoPleQ340InKTaTCeWbVuHytj1hL/bY/9+Ct8IktAd6eu9pYrD7EUPBcuAkNt5efmrQfPS9IEUcIWwqC3KFTKsM4RoTuQ3OP+oc1MHgiIdSgHueivayzs/LF1hXQZFBimoaSRHD5vGGWjgi0W07wIjDUZkV+OuPYUIxbiOI+ecbPjoVsq6XkfIKt2uxZ2deLkOsxucdJxEYWK6BJ5InvpAWEAIw//ysXA== X-YMail-OSG: 5lHyG3kVM1kPmpuFULQrZ7daUTjmGcAR9Mzy7TMeRgdVFmOFninOkhTcvFXEOKQ gwEUStmaKzsSeQvfpGAPlxKW9R.rdQdUaMcWuE9MDNERv98gPrB1LQXkAxsg3UoDtzj3ztlbSw5H S8JYSo1mHwxajpk6XymZhji.wyQxw58DADekZyhFG6sbwvkPlWAJFfMgLxZJ9KfqC4XaNdmj7dvV iQQVcK58QJRpco6sVHVwgvJ38i9ddagyDNY8_t52H9qEfOQiDhhVLmwBu74SCXqLNH7Wn3RCa5RS mI0UU.yZPso7AJ1Yi2evScLf1WnfiXPX2UqAOWskp2_7X9nYV7K__0iCewU4MHP70krR4iKPzf3P RrQAfLKFj5E6LhPNm5.G0j9uuw7e58v1AV.84JaWyB3vGB9k67yhgrJS0G77Ky_QvH4rv9a3dzux hcXTpWDsDqjn5DofShJ4GtV3ZGOeCGtwb6ObZjwB2Ig_E4n85IgaSYSonuKBGfwji0oN6ZlgRwDZ UQPhKLAJMputWpD1fuVQxB_029rHWeT.KyvNKgfd25HTbQD87A4m1t6TAofJN04b7GRoszg1nWIp pVkvj5QXNi7p.D9ebLZW4CB4nAkvtSVvQUJEhEuCc4gYX1T.bfObUYeEX8FDu3Y8N0BDfWOFW3N7 KJXoIRrIwPKRrOBSL5St1RLvIH.f3rBTvckolj0O5mzFNm3zNRm3NoyKbXnQCnw1VgRmntbD7JN. HieQ.CkNwZsaTTLlm_aRLzMRIAZ_cdUnyDfW_uBNt8GLf1k09KCGZG.gq1CLJeI9W9N22YTdmus_ pAoqLywm4HNtJixIymm8f1LQPgUpq1OW.UC8E0sTclMS385ZwfGew6.7gIkG0Bigzr5HblrX.sZC HJ3YmwFhWsn.qqVLFl_kZoWQ4jL7MLUUxJSHdXmOdNLqVmagQZvdFQVl5EDJfxsMX.fb_UUEenmd Zp9f4pzxPfIZMgmYomFvE93sXLu.9OntfYtKGBYyP2bWErzNGggsYD77N2nmgsXEYc7CsD3wgGwy n49X3M.WShMJ1WSUgR0JyYvVQKpJRQjCbVsGmKvrl9VvykmBoTJPD9fym2LeMXwPDynY_giSMT_k eNhwoWb8i66O.1nd3bdlnaEa_b6cKCD8f2_9F9qp8ccBo0Z69OnN7lCLmSrSqck8CL7KfKkiIh4V 5mzB7bFqsxm0qDDelhGuQ3wM6VD.QqnQPwrS92Nvklokt0zl6XwJ8qDgOxj1x.Wel8JQUXHBSAY9 h_KT.Q5SJpvz7NT5V79VB96Kz2nUnANDMRy4lg3N3XaoB4Yezd1PDbmuAftAuytE8qTwlh_9cvqT IvhNc1BEuRgFiOY6eVlKRO6VEYDP_3wmMi0Yxg_KPVGlLmB33tew3qsZ8ncIsizOMK8xeNqr.8uf QbtgOiTv2rGoA80AJR8m_U8MMsmiLLA8L.1jzXW0Ui9DMgNsLq.mKsIrHhTHcXdU2PE0Q_Syxqmm C9a2hHJ1l_GKgDo3lSxftDpaaG1kVwqZOQcmvw9xawdFG.fLvyt85xPCpIm.C5MD7uVhK2479ShK Sn8YcOLBNNdOI6ogZEbzfBxkhMyHsGZBZ3f.dBv.3QrQKlk6YxHEPfof64ubEp4UB6EETU86qJ9I ryh6PfEtEHiG6v4Sor5VMizKWeZK7TDyuwboLJK2ScCB08hD7EbREjuexdcfh0.K7jZXnyD7iO_H PX9KORtu7yKfd8shHFjEP9fyxsNFvfkWi.EFI83sGZO1VvzMn8SIzUA3L9.zPkW3Z7QOHg4pXJ3S PaV_kOev3MA8.KDSinN7DTmqehQMCtM9r42IcIRA0gLaxPPUsEi_RLj7mOAIti4FjQgL7AtUBROb wiwGORLtbtZX0NQDbbe.Gn3Z9sS6SRdlsb30snpnHzf.KbWFRHIMCHz8w6soUjUUryVOd5bnDpTy 5N_d2sFzvoWLdIPbs_CyZFgBtEesLx9rCO5IssMdw2TYiSplm8r1d_g5evtgn7FHFOXirtj9gjYH bwowfEI4rVMpLjZAln9QItu_JTD26Z.F.yl.n70Vs6BwLZ6tRDLBGKi0q72wJgj9.IP_CqYpnBRH ulqp8k3qjNKYQXhtTb5w2Rkd4XoqqLFFoe9UKjh7pT68gEL3MjQHdheS.2jF_G79dncEYWGZYsCm LZnXlTZbCSJHJpY0G1H0U3XjSjc66bBKQ10xlEA4LzjSKnyFJ3fFrOMsfJotuZGzrwPCITlC8tmr 1mGq9CGMD0QYaqlHRLcFOFKNE X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Jan 2022 13:08:07 +0000 Received: by kubenode542.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID deedd3f149e75d413c0932f78b901c5a; Fri, 07 Jan 2022 13:08:05 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile Date: Fri, 7 Jan 2022 05:08:04 -0800 References: To: freebsd-current In-Reply-To: Message-Id: <91B0824D-C202-40A2-8781-30E6E0502D0B@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JVk6l2TjXz4c8S X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="Q/d+4FaR"; 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 X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.82:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_LONG(1.00)[0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-7, at 03:49, Mark Millard wrote: > Having done a buildworld with both WITH_ASAN=3D and WITH_UBSAN=3D > after finding what to control to allow the build, I installed > it in a directory tree for chroot use and have > "kyua test -k /usr/tests/Kyuafile" running. >=20 > I see evidence of various examples of one type of undefined > behavior: "applying zero offset to null pointer" >=20 > # more = /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/356/stderr.txt=20= > /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 > /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 > /usr/main-src/usr.bin/sed/process.c:715:18: runtime error: applying = zero offset to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/sed/process.c:715:18 in=20 > /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 > Fail: stderr not empty > --- /dev/null 2022-01-07 10:29:57.182903000 +0000 > +++ /tmp/kyua.FKD2vh/356/work/check.Mk9llD/stderr 2022-01-07 = 10:29:57.173100000 +0000 > @@ -0,0 +1,2 @@ > +/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 > Files left in work directory after failure: mntpt, mounterr >=20 >=20 > In general the lib/libc/stdio/fread.c:133:10 example seems to > be in a place that would make it fairly common. >=20 > usr.bin/sed/process.c:715:18 is more limited: just sed use. >=20 kyua ran to completion. This note is focused on UBSAN reports. By far the most common UBSAN report is for the lib/libc/stdio/fread.c:133:10 code. Another somewhat common UBSAN report is: Standard error: /usr/main-src/usr.bin/cut/cut.c:458:7: runtime error: addition of = unsigned offset to 0x62100000010d overflowed to 0x62100000010c SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/cut/cut.c:458:7 in=20 Fail: incorrect exit status: 1, expected: 0 There is at least one example of: Standard error: ld-elf.so.1: /lib/libthr.so.3: Undefined symbol = "__asan_option_detect_stack_use_after_return" Some more zero offsets to null are: +/usr/main-src/bin/sh/jobs.c:590:35: runtime error: applying zero offset = to null pointer +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/bin/sh/jobs.c:590:35 in=20 +/usr/main-src/bin/sh/jobs.c:601:22: runtime error: applying zero offset = to null pointer +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/bin/sh/jobs.c:601:22 in=20 +/usr/main-src/contrib/xz/src/liblzma/common/common.c:292:16: runtime = error: applying zero offset to null pointer +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/xz/src/liblzma/common/common.c:292:16 in=20 +/usr/main-src/usr.sbin/makefs/ffs.c:1053:35: runtime error: applying = zero offset to null pointer +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.sbin/makefs/ffs.c:1053:35 in=20 Files left in work directory after failure: dir, ufs.img contrib/libxo/libxo/xo_buf.h has examples of non-zero offsets: +/usr/main-src/contrib/libxo/libxo/xo_buf.h:116:22: runtime error: = applying non-zero offset 4 to null pointer +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/libxo/libxo/xo_buf.h:116:22 in=20 +/usr/main-src/contrib/libxo/libxo/xo_buf.h:116:44: runtime error: = applying zero offset to null pointer +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/libxo/libxo/xo_buf.h:116:44 in=20 +/usr/main-src/contrib/libxo/libxo/xo_buf.h:120:29: runtime error: = applying non-zero offset 4 to null pointer +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/libxo/libxo/xo_buf.h:120:29 in=20 As does contrib/openzfs/module/nvpair/nvpair.c : /usr/main-src/sys/contrib/openzfs/module/nvpair/nvpair.c:3129:49: = runtime error: applying non-zero offset 4 to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/sys/contrib/openzfs/module/nvpair/nvpair.c:3129:49 in=20 There is a: +/usr/main-src/bin/sh/arith_yacc.c:193:10: runtime error: negation of = -9223372036854775808 cannot be represented in type 'arith_t' (aka = 'long'); cast to an unsigned type to negate this value to itself +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/bin/sh/arith_yacc.c:193:10 in=20 And there are various examples similar to: +/usr/main-src/sys/contrib/zlib/deflate.c:1262:31: runtime error: load = of misaligned address 0x631000014805 for type 'ushf' (aka 'unsigned = short'), which requires 2 byte alignment +0x631000014805: note: pointer points here + 69 6c 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 00 00 00 00 00 00 + ^=20 but at different lines of the code. There are examples of: +/usr/main-src/lib/libc/db/hash/hash_page.c:761:3: runtime error: left = shift of 1 by 31 places cannot be represented in type 'int' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/db/hash/hash_page.c:761:3 in=20 +/usr/main-src/lib/libc/db/hash/hash_page.c:840:2: runtime error: left = shift of 1 by 31 places cannot be represented in type 'int' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/db/hash/hash_page.c:840:2 in=20 +/usr/main-src/lib/libc/db/hash/hash_page.c:774:2: runtime error: left = shift of 1 by 31 places cannot be represented in type 'int' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/db/hash/hash_page.c:774:2 in=20 There are various examples similar to: +/usr/main-src/lib/libc/db/btree/bt_conv.c:168:6: runtime error: load of = misaligned address 0x616000000b91 for type 'uint32_t' (aka 'unsigned = int'), which requires 4 byte alignment +0x616000000b91: note: pointer points here + 00 00 02 02 03 00 00 00 ec 01 00 00 78 0a 00 08 00 00 00 02 00 00 = 00 02 02 00 00 00 ec 01 00 00 + ^=20 but at different lines of the code. There was a: /usr/main-src/contrib/netbsd-tests/lib/libc/gen/t_sleep.c:305:36: = runtime error: signed integer overflow: 105827994173648 * 1000000000 = cannot be represented in type 'long long' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/netbsd-tests/lib/libc/gen/t_sleep.c:305:36 in=20 And a: +/usr/main-src/lib/libc/regex/engine.c:1013:53: runtime error: left = shift of 4611686018427387904 by 1 places cannot be represented in type = 'long' +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/regex/engine.c:1013:53 in=20 (It occured in multiple places.) And: /usr/main-src/lib/libc/gen/_rand48.c:45:55: runtime error: signed = integer overflow: 57068 * 43981 cannot be represented in type 'int' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/gen/_rand48.c:45:55 in=20 /usr/main-src/lib/libc/gen/_rand48.c:45:26: runtime error: signed = integer overflow: 58989 * 55082 cannot be represented in type 'int' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/gen/_rand48.c:45:26 in=20 /usr/main-src/lib/libc/gen/_rand48.c:45:37: runtime error: signed = integer overflow: 1365949284 + 876906888 cannot be represented in type = 'int' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/gen/_rand48.c:45:37 in=20 /usr/main-src/lib/libc/stdlib/getenv.c:169:20: runtime error: load of = value 190, which is not a valid value for type 'bool' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdlib/getenv.c:169:20 in=20 /usr/main-src/lib/libc/stdlib/getenv.c:684:23: runtime error: load of = value 190, which is not a valid value for type 'bool' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdlib/getenv.c:684:23 in=20 And: /usr/main-src/lib/libthr/thread/thr_sig.c:797:7: runtime error: member = access within misaligned address 0xffffffffffffffff for type 'const = ucontext_t' (aka 'const struct __ucontext'), which requires 16 byte = alignment 0xffffffffffffffff: note: pointer points here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libthr/thread/thr_sig.c:797:7 in=20 /usr/main-src/lib/libthr/thread/thr_sig.c:797:7: runtime error: member = access within misaligned address 0xffffffffffffffff for type 'const = __sigset_t' (aka 'const struct __sigset'), which requires 16 byte = alignment 0xffffffffffffffff: note: pointer points here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libthr/thread/thr_sig.c:797:7 in=20 /usr/main-src/lib/libthr/thread/thr_sig.c:797:7: runtime error: load of = misaligned address 0xffffffffffffffff for type 'const __uint32_t' (aka = 'const unsigned int'), which requires 16 byte alignment 0xffffffffffffffff: note: pointer points here SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libthr/thread/thr_sig.c:797:7 in=20 And: +/usr/main-src/sbin/nvmecontrol/nvmecontrol.h:99:9: runtime error: load = of misaligned address 0x7fffffffc978 for type 'uint128_t' (aka 'unsigned = __int128'), which requires 16 byte alignment +0x7fffffffc978: note: pointer points here + 00 00 00 00 00 60 a5 ee dc 01 00 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 00 00 00 00 00 00 00 + ^=20 +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/sbin/nvmecontrol/nvmecontrol.h:99:9 in=20 And: /usr/main-src/sys/netinet/libalias/alias_db.c:430:2: runtime error: = member access within null pointer of type 'struct libalias' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/sys/netinet/libalias/alias_db.c:430:2 in=20 And: /usr/main-src/tests/sys/sys/qmath_test.c:569:3: runtime error: left = shift of 1277217398 by 34 places cannot be represented in type 's64q_t' = (aka 'long') SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:569:3 in=20 /usr/main-src/tests/sys/sys/qmath_test.c:569:3: runtime error: signed = integer overflow: -8928018189856292682 + -9223372036854775808 cannot be = represented in type 'long' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:569:3 in=20 /usr/main-src/tests/sys/sys/qmath_test.c:570:3: runtime error: left = shift of 674540471 by 34 places cannot be represented in type 's64q_t' = (aka 'long') SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:570:3 in=20 /usr/main-src/tests/sys/sys/qmath_test.c:570:3: runtime error: signed = integer overflow: -7034438991598280603 + -9223372036854775808 cannot be = represented in type 'long' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:570:3 in=20 /usr/main-src/tests/sys/sys/qmath_test.c:378:3: runtime error: left = shift of 1099256400 by 34 places cannot be represented in type 's64q_t' = (aka 'long') SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:378:3 in=20 /usr/main-src/tests/sys/sys/qmath_test.c:379:3: runtime error: left = shift of 7397324394137081998 by 3 places cannot be represented in type = 's64q_t' (aka 'long') SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:379:3 in=20 /usr/main-src/tests/sys/sys/qmath_test.c:378:3: runtime error: signed = integer overflow: -5522065151083782997 + -9223372036854775808 cannot be = represented in type 'long' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:378:3 in=20 And: /usr/main-src/usr.bin/mkimg/ebr.c:89:16: runtime error: member access = within misaligned address 0x61500000023e for type 'struct = dos_partition', which requires 4 byte alignment 0x61500000023e: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 00 00 00 00 00 00 ^=20 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/mkimg/ebr.c:89:16 in=20 And: /usr/main-src/usr.bin/mkimg/mbr.c:99:8: runtime error: member access = within misaligned address 0x6150000004be for type 'struct = dos_partition', which requires 4 byte alignment 0x6150000004be: note: pointer points here 42 0a 42 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 00 00 00 00 00 00 ^=20 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/mkimg/mbr.c:99:8 in=20 And: +/usr/main-src/usr.bin/rs/rs.c:387:5: runtime error: applying non-zero = offset 108370614813184 to null pointer +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/rs/rs.c:387:5 in=20 And: +/usr/main-src/usr.bin/unifdef/unifdef.c:836:52: runtime error: applying = non-zero offset 1 to null pointer +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/unifdef/unifdef.c:836:52 in=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 7 13:57:11 2022 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 8D70B1921193 for ; Fri, 7 Jan 2022 13:57:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVlCM38hFz4pw8 for ; Fri, 7 Jan 2022 13:57:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641563838; bh=+krWnSqzxV14W8F0UiTb16dUyW3e3d//+KHyoGvMU7w=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=bPiTX45Jw+36/YSKDh4CPsAHV52DjZKTvkk5zxoGyZeVk8i5B67cIm3F9eVrgSjCildYOvwnubsylQOKhqyOZb/OX7GTL0Ne6n+d0pb3Q+s/hULtSVlPdnwq6kDJOmWo7xnn9bVUhMgYlyJl1dYYV/6CCuxkz/MXTrljdG9gaGqxfKFcqf5VqWxsIbyeq6xDU1I8iXztzId8C/PXseEfzh674097od3yj1rOYl0WvYsuqhaqvc9Xz3emeCUuJnETeqqmYN5vYdz1YaIuNGUWse9iy8iODDu2PMJ7vu/+o+mTmIXTyUTVMrCIx/YT/IN6MW7r3Dbn1JPOYfIgBGWdKA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641563838; bh=bFolhg1MRFN/2SyQ5ApGiJvWcUSI5FksNlFwYQBHQCs=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=bgW2tcrcsSB1pUWVkQj1cy4pSZ76O2BpVBehNeK9jFE53rdOu9px/Z19hGh5ZZzJuPimBi/sqKjWlEfNJhAf5IR731otwfWix0mkhNWrl5/wgUAl3IfZM1ALzlPtsJc7tZCbD8IC/kaNj9PeJdEQ6Pp1YzDonnfpXplCChruBuHuf/NzGEeTmNL6wNlA/DEbtbNiZsiNstyLHCp7winvdLVVDibE70WkaeSE9WZaMbTYr8NH1eQQtgq6WT98yH/j+dIXBsna7eU/WTOc9kRXQuhmjD29xJCks1qHlRcvAKRC8yaIuPL8jb2X2V3ZvXOaYzwXUv+urFfFt7TCj+TcFA== X-YMail-OSG: uVblbEEVM1nHwOHpr1w0oD.NHN6Q.sXrXE6GJJjAmbB6Cg5oHfbUccj0WeIste4 zRew3w.s7KwX6nE3wwop6VEK..rid10sYh3l25l0Cz7GQch3Br57eJS8qZbvTN.0rxxbl3Zmlqrp lh5doegH3u15zHX.AGZZQ9CzrqgyXKnhl1K4RUMJMb2PyBU1YA9vdBbHEdKP_Bx310ZrAk6Am85Z f_xvAO2sxhikSe8gkzqU81vHFLBSgthgQntY5shoohDiI6sDBJzkARWxoWnvwR7YAEUF2afK00tb 4f8ggk18ngFDnCpVFkPBSlP2zzDDFp7AxSaUYHbqAIYUlf.RmORBmc9xKkLZnjAq2a5.FW.MQRc_ _zHmAAaCCURy_ZVD8x86Qz2lE1tCj0oJkVRq0V4y3Ya.txYbKkkNlHS2kYpeC2fnvSyXn15FetDI BQHnJ8yxNXI3zqdyLYmepAxRKa4GY9QsGRJwIT6gR4_Q9HY7KowKOxmxT6UOMpw9rLISybEK9aTI gy_iiQa4wk3LVV2ca.CAxU5wfu5unmHBjZXPVJj7Z2.HtWCFRy.ps5b_afSNmvhW2B3bCmVM2WiR jIcRJu5lfpNlEzUNQYwfjGGugYLSg.VTTzx52CZitZt6_2VtN6D8xlV5d_AvSLvwrJt_gfSCkzHq DAxrHnnhLV8krW31aJ50TkzEuOLtpzLTjp8VDvNW9j.CK0Jk7HfAML5kd.EzBD2nfzhv0vl.x2tW Hh8hYb___q6.RVBHjsg.HEz7u.HGYZHpgyWM4lNopzYTn2o5g52FtypzIsIPjX7jWvilSqx7bYI5 GL1wlz1mgtrcltVk.pZN46NoIGmeLcdfMwc0ty0fmVg7BcvT.csQ6K6VCCS.UzLAmonp958OwM0J oHmjpfCRb6icNKiJST3sNLRJGMqdy3q.lw9cmWW2kP1nqJ9FKLT.pCirkKPsdwbec8XjpiHqe.gv 0euZAtDha3XkCcBwk0UGbksdWT0nY2q4MX9VF24F1vUhBMg5FBOe9M6CoLF3re8JTWTIUyaLp91W SJ8VbGMcd7r90YStXdYLt3AsoAx3FgQoIAH80YiqBmhsYYIR0uAoUijwm5.ZM7GQDf2fQte6mgvg MjFsL2pOKg3lrxMRm3sgfmcfrMDKJapwse5fusf.RnHo6trFU9mSwddcQwu2mddTN1N44pTeCuCW Sc4zIioyn1NUigx1VaXYCEKCOUEpX5gJoEuSaGKR2KsBlTqMBeI6Y9QkHu9iAQNS5DpuYPnubcNU JFR_HzBfWpxohgDILT7k4XZiUN2jaNXhGubUvpQTR4e23xmlmZqNMRZAXv4fCh93KmrwoNzOTsGs gICBDPy4IBaswHS8eafaDxA5x3aRGl1ntscMQgq.C3uCfY7rh6sAxVCNP6KQQqfQ1x5_y6TzR1jd KV5BGDTGcYgpqVIDfPu4eE6cdwmARgAuN9c.dYr18jTbKlDrfM0ejVjgP8..20jbrDinpe1wRrBB nTMGQRLrVvUn4KrzNKlEnJLM2ECigrUkX7HRYKzY_t5uD2dmCpoXrCG43Y7NqaJltAN_yZNSCDd_ xxcVI3LVej3tTSpPfH22KeG1oPfh4LlR3gwESQaaQtSYtyvBXEgfE5dRI0nl0Dkz5OOv63UZ4W1A pyaa8JRJYXkNFh8POEhJFgqM6Cf0R0mR19J0CGEZY90760DBWSRcrVDUGQODsypzU7D6Dv4p.SPf WC0AnoK4vNov3lqr7QiH5xX10ZO.YHt4Bhly.k9ECPXr4IiKrGTL1v7crf2CRKjgxn4r2rSfkUxd UyabxbAj8mr9ZHmETNt0xIz1NsFrdDf6LeKhNTjx7OtLRvnhP1gh4ebF0hqVlGhwSGjevQ.1bku8 Dr4hbhBvovOL_lfOlKVX3aYM9pIoVIdL_UAzX5Y0xeL4XvjL_sD3YEvbc4gkcSDdBCCXt1ePml6d .tZAb9Y7TXiA17GJ4K2ood3dBa3HFBZLxMsmG.GJYIIM4OIoXyiy8uo9EXMDaOdwhQ6hbDoIFCMy MdBOUmQQEBUMNX43a8LSPpy8Y1AN2ClhodsJVVCqGg_pvC._Ml7rt.dejciGiGNugEDldsQSykuS 8D0QxFYduRwdWLym.4Hl5g_CEzs4EGUW0wgHUZZjcd_pssk619C67vlQ0grmXICwgQ4i5EAKajTN BPF71qDSieh_0z5bquD4JePNXaUwgUgYHApTOdFwvPEJnyG4wAphk1ITN2eO1i3srrisRkU.xl3J 4_eHBqyZpozzlGU1faGjy7w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Jan 2022 13:57:18 +0000 Received: by kubenode522.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 67a924cece4c9149ae67566bc09e7ec5; Fri, 07 Jan 2022 13:57:13 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile Date: Fri, 7 Jan 2022 05:57:11 -0800 References: <91B0824D-C202-40A2-8781-30E6E0502D0B@yahoo.com> To: freebsd-current In-Reply-To: <91B0824D-C202-40A2-8781-30E6E0502D0B@yahoo.com> Message-Id: <02A69F9D-FE10-40F3-BEF3-5A54EFC2310A@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JVlCM38hFz4pw8 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=bPiTX45J; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.147:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_LONG(1.00)[0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.147:from] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-7, at 05:08, Mark Millard wrote: > On 2022-Jan-7, at 03:49, Mark Millard wrote: >=20 >> Having done a buildworld with both WITH_ASAN=3D and WITH_UBSAN=3D >> after finding what to control to allow the build, I installed >> it in a directory tree for chroot use and have >> "kyua test -k /usr/tests/Kyuafile" running. >>=20 >> I see evidence of various examples of one type of undefined >> behavior: "applying zero offset to null pointer" >>=20 >> # more = /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/356/stderr.txt=20= >> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> /usr/main-src/usr.bin/sed/process.c:715:18: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/sed/process.c:715:18 in=20 >> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> Fail: stderr not empty >> --- /dev/null 2022-01-07 10:29:57.182903000 +0000 >> +++ /tmp/kyua.FKD2vh/356/work/check.Mk9llD/stderr 2022-01-07 = 10:29:57.173100000 +0000 >> @@ -0,0 +1,2 @@ >> +/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> Files left in work directory after failure: mntpt, mounterr >>=20 >>=20 >> In general the lib/libc/stdio/fread.c:133:10 example seems to >> be in a place that would make it fairly common. >>=20 >> usr.bin/sed/process.c:715:18 is more limited: just sed use. >>=20 >=20 > kyua ran to completion. This note is focused on UBSAN reports. >=20 > By far the most common UBSAN report is for the > lib/libc/stdio/fread.c:133:10 code. >=20 > Another somewhat common UBSAN report is: >=20 > Standard error: > /usr/main-src/usr.bin/cut/cut.c:458:7: runtime error: addition of = unsigned offset to 0x62100000010d overflowed to 0x62100000010c > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/cut/cut.c:458:7 in=20 > Fail: incorrect exit status: 1, expected: 0 >=20 >=20 > There is at least one example of: >=20 > Standard error: > ld-elf.so.1: /lib/libthr.so.3: Undefined symbol = "__asan_option_detect_stack_use_after_return" >=20 >=20 > Some more zero offsets to null are: >=20 > +/usr/main-src/bin/sh/jobs.c:590:35: runtime error: applying zero = offset to null pointer > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/bin/sh/jobs.c:590:35 in=20 > +/usr/main-src/bin/sh/jobs.c:601:22: runtime error: applying zero = offset to null pointer > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/bin/sh/jobs.c:601:22 in=20 > +/usr/main-src/contrib/xz/src/liblzma/common/common.c:292:16: runtime = error: applying zero offset to null pointer > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/xz/src/liblzma/common/common.c:292:16 in=20 >=20 > +/usr/main-src/usr.sbin/makefs/ffs.c:1053:35: runtime error: applying = zero offset to null pointer > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.sbin/makefs/ffs.c:1053:35 in=20 > Files left in work directory after failure: dir, ufs.img >=20 >=20 > contrib/libxo/libxo/xo_buf.h has examples of non-zero offsets: >=20 > +/usr/main-src/contrib/libxo/libxo/xo_buf.h:116:22: runtime error: = applying non-zero offset 4 to null pointer > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/libxo/libxo/xo_buf.h:116:22 in=20 > +/usr/main-src/contrib/libxo/libxo/xo_buf.h:116:44: runtime error: = applying zero offset to null pointer > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/libxo/libxo/xo_buf.h:116:44 in=20 > +/usr/main-src/contrib/libxo/libxo/xo_buf.h:120:29: runtime error: = applying non-zero offset 4 to null pointer > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/libxo/libxo/xo_buf.h:120:29 in=20 >=20 > As does contrib/openzfs/module/nvpair/nvpair.c : >=20 > /usr/main-src/sys/contrib/openzfs/module/nvpair/nvpair.c:3129:49: = runtime error: applying non-zero offset 4 to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/sys/contrib/openzfs/module/nvpair/nvpair.c:3129:49 in=20 >=20 >=20 > There is a: >=20 > +/usr/main-src/bin/sh/arith_yacc.c:193:10: runtime error: negation of = -9223372036854775808 cannot be represented in type 'arith_t' (aka = 'long'); cast to an unsigned type to negate this value to itself > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/bin/sh/arith_yacc.c:193:10 in=20 >=20 > And there are various examples similar to: >=20 > +/usr/main-src/sys/contrib/zlib/deflate.c:1262:31: runtime error: load = of misaligned address 0x631000014805 for type 'ushf' (aka 'unsigned = short'), which requires 2 byte alignment > +0x631000014805: note: pointer points here > + 69 6c 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 00 00 00 00 00 00 00 > + ^=20 >=20 > but at different lines of the code. >=20 > There are examples of: >=20 > +/usr/main-src/lib/libc/db/hash/hash_page.c:761:3: runtime error: left = shift of 1 by 31 places cannot be represented in type 'int' > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/db/hash/hash_page.c:761:3 in=20 > +/usr/main-src/lib/libc/db/hash/hash_page.c:840:2: runtime error: left = shift of 1 by 31 places cannot be represented in type 'int' > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/db/hash/hash_page.c:840:2 in=20 > +/usr/main-src/lib/libc/db/hash/hash_page.c:774:2: runtime error: left = shift of 1 by 31 places cannot be represented in type 'int' > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/db/hash/hash_page.c:774:2 in=20 >=20 > There are various examples similar to: >=20 > +/usr/main-src/lib/libc/db/btree/bt_conv.c:168:6: runtime error: load = of misaligned address 0x616000000b91 for type 'uint32_t' (aka 'unsigned = int'), which requires 4 byte alignment > +0x616000000b91: note: pointer points here > + 00 00 02 02 03 00 00 00 ec 01 00 00 78 0a 00 08 00 00 00 02 00 00 = 00 02 02 00 00 00 ec 01 00 00 > + ^=20 >=20 > but at different lines of the code. >=20 > There was a: >=20 > /usr/main-src/contrib/netbsd-tests/lib/libc/gen/t_sleep.c:305:36: = runtime error: signed integer overflow: 105827994173648 * 1000000000 = cannot be represented in type 'long long' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/netbsd-tests/lib/libc/gen/t_sleep.c:305:36 in=20 >=20 > And a: >=20 > +/usr/main-src/lib/libc/regex/engine.c:1013:53: runtime error: left = shift of 4611686018427387904 by 1 places cannot be represented in type = 'long' > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/regex/engine.c:1013:53 in=20 >=20 > (It occured in multiple places.) >=20 > And: >=20 > /usr/main-src/lib/libc/gen/_rand48.c:45:55: runtime error: signed = integer overflow: 57068 * 43981 cannot be represented in type 'int' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/gen/_rand48.c:45:55 in=20 > /usr/main-src/lib/libc/gen/_rand48.c:45:26: runtime error: signed = integer overflow: 58989 * 55082 cannot be represented in type 'int' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/gen/_rand48.c:45:26 in=20 > /usr/main-src/lib/libc/gen/_rand48.c:45:37: runtime error: signed = integer overflow: 1365949284 + 876906888 cannot be represented in type = 'int' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/gen/_rand48.c:45:37 in=20 >=20 > /usr/main-src/lib/libc/stdlib/getenv.c:169:20: runtime error: load of = value 190, which is not a valid value for type 'bool' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdlib/getenv.c:169:20 in=20 > /usr/main-src/lib/libc/stdlib/getenv.c:684:23: runtime error: load of = value 190, which is not a valid value for type 'bool' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdlib/getenv.c:684:23 in=20 >=20 > And: >=20 > /usr/main-src/lib/libthr/thread/thr_sig.c:797:7: runtime error: member = access within misaligned address 0xffffffffffffffff for type 'const = ucontext_t' (aka 'const struct __ucontext'), which requires 16 byte = alignment > 0xffffffffffffffff: note: pointer points here > > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libthr/thread/thr_sig.c:797:7 in=20 > /usr/main-src/lib/libthr/thread/thr_sig.c:797:7: runtime error: member = access within misaligned address 0xffffffffffffffff for type 'const = __sigset_t' (aka 'const struct __sigset'), which requires 16 byte = alignment > 0xffffffffffffffff: note: pointer points here > > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libthr/thread/thr_sig.c:797:7 in=20 > /usr/main-src/lib/libthr/thread/thr_sig.c:797:7: runtime error: load = of misaligned address 0xffffffffffffffff for type 'const __uint32_t' = (aka 'const unsigned int'), which requires 16 byte alignment > 0xffffffffffffffff: note: pointer points here > > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libthr/thread/thr_sig.c:797:7 in=20 >=20 > And: >=20 > +/usr/main-src/sbin/nvmecontrol/nvmecontrol.h:99:9: runtime error: = load of misaligned address 0x7fffffffc978 for type 'uint128_t' (aka = 'unsigned __int128'), which requires 16 byte alignment > +0x7fffffffc978: note: pointer points here > + 00 00 00 00 00 60 a5 ee dc 01 00 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 00 00 00 00 00 00 00 > + ^=20 > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/sbin/nvmecontrol/nvmecontrol.h:99:9 in=20 >=20 > And: >=20 > /usr/main-src/sys/netinet/libalias/alias_db.c:430:2: runtime error: = member access within null pointer of type 'struct libalias' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/sys/netinet/libalias/alias_db.c:430:2 in=20 >=20 > And: >=20 > /usr/main-src/tests/sys/sys/qmath_test.c:569:3: runtime error: left = shift of 1277217398 by 34 places cannot be represented in type 's64q_t' = (aka 'long') > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:569:3 in=20 > /usr/main-src/tests/sys/sys/qmath_test.c:569:3: runtime error: signed = integer overflow: -8928018189856292682 + -9223372036854775808 cannot be = represented in type 'long' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:569:3 in=20 > /usr/main-src/tests/sys/sys/qmath_test.c:570:3: runtime error: left = shift of 674540471 by 34 places cannot be represented in type 's64q_t' = (aka 'long') > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:570:3 in=20 > /usr/main-src/tests/sys/sys/qmath_test.c:570:3: runtime error: signed = integer overflow: -7034438991598280603 + -9223372036854775808 cannot be = represented in type 'long' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:570:3 in=20 >=20 > /usr/main-src/tests/sys/sys/qmath_test.c:378:3: runtime error: left = shift of 1099256400 by 34 places cannot be represented in type 's64q_t' = (aka 'long') > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:378:3 in=20 > /usr/main-src/tests/sys/sys/qmath_test.c:379:3: runtime error: left = shift of 7397324394137081998 by 3 places cannot be represented in type = 's64q_t' (aka 'long') > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:379:3 in=20 > /usr/main-src/tests/sys/sys/qmath_test.c:378:3: runtime error: signed = integer overflow: -5522065151083782997 + -9223372036854775808 cannot be = represented in type 'long' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/tests/sys/sys/qmath_test.c:378:3 in=20 >=20 > And: >=20 > /usr/main-src/usr.bin/mkimg/ebr.c:89:16: runtime error: member access = within misaligned address 0x61500000023e for type 'struct = dos_partition', which requires 4 byte alignment > 0x61500000023e: note: pointer points here > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 00 00 00 00 00 00 00 > ^=20 > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/mkimg/ebr.c:89:16 in=20 >=20 > And: >=20 > /usr/main-src/usr.bin/mkimg/mbr.c:99:8: runtime error: member access = within misaligned address 0x6150000004be for type 'struct = dos_partition', which requires 4 byte alignment > 0x6150000004be: note: pointer points here > 42 0a 42 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = 00 00 00 00 00 00 00 00 00 00 > ^=20 > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/mkimg/mbr.c:99:8 in=20 >=20 > And: >=20 > +/usr/main-src/usr.bin/rs/rs.c:387:5: runtime error: applying non-zero = offset 108370614813184 to null pointer > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/rs/rs.c:387:5 in=20 >=20 > And: >=20 > +/usr/main-src/usr.bin/unifdef/unifdef.c:836:52: runtime error: = applying non-zero offset 1 to null pointer > +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/unifdef/unifdef.c:836:52 in=20 With all the line number references, I should have noted what my source context for main [so: 14] is based on: # uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #29 = main-n252196-a3522837b021-dirty: Mon Jan 3 22:17:33 PST 2022 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400046 1400046 # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ branch: main merge-base: a3522837b021a46f2de81303247599ea51163d13 merge-base: CommitDate: 2022-01-04 03:39:24 +0000 a3522837b021 (HEAD -> main, freebsd/main, freebsd/HEAD) ipfilter = userland: Fix branch mismerge n252196 (--first-parent --count for merge-base) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 7 22:28:47 2022 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 0C38019465F0 for ; Fri, 7 Jan 2022 22:29:01 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVyYm5N4mz3HyM for ; Fri, 7 Jan 2022 22:29:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641594533; bh=ivwdvp6RRxVYDUoe2+qHMuiQvdWfmHDheioyB26lAxU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UVkQaRRJYdPDnIE2lxBpfK9haWS21iOcyw+6EQAVfG1NV88dPu1oMclxXJ0gJNVYpMpsn1m9Yxm0sNzXcpYyF7HCOXt7tXRO7i4xmojuX3lLU+KleHek2X/ZgeZpxqwyHBY8aX57DZIvCRXhV1p3o7KRkFKt1xEzm7HJyuoavNdDcVyEvkboTej3TYUG/EA3WPBzhK16FhmI7fyCPTNtgfxGvUoGuT55X/X7trK5rbjJv2HofU/Q3aK0olHtTIzSd3awGusVihK3ksWaZ5yLgcBLNGHFEhy1pdqfsa4OKFTC0msnaMeXhHob5nQoxlPFlmmhIWHgPNaLh01xVz8YNg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641594533; bh=YSGd0qXlH1AzkXGJTcycAga/VVatCzG3WvDPsbiJLqw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iHeS2w+6m9UynVQfREZ6lJnicJXNAGnd4Mt12UM5/cDLi6zqJDHkQOKFbFsfviMbTsd/ydc5AFy52NK1LzETNySBeEW0M5WodSM40oD0kxAczi4khulpTzgOI4aSqYuPGhrlf1E5OwI6lS/FsQ1gMXUbyb2DtuCHfUvEcymza0Kk3+pEBs0T8sECOn+OzJSJ+f4LdpBIHdq5RX88fUqhW/kpAg1QfWLo2WEK/e6d+M0MqGbd2qCq+jAP+Gp9zxpXWYgQYQQjNoCuW24l2N+1bz9W/KZeq5fIe5h2cdFkvO8WmAvVVqV1Dp496du3uk1ieQujpUVZKafaY9HKj2O7yA== X-YMail-OSG: gzG2EDwVM1nb6ciiBjNBbMMbr.FKlh3pnXrycauPvNGA0FaTPht1X_ju_azv2e7 HJlvIyNQTb5dU5lwsQercOmOCERtij2DdVxY7.cYXIRlkpwrKnIAAUeNKaNEf6k6E0nhtKCemghk fs45HQ9GYSMFM9M_1OCE6QT9CC0ZJusWcy5fFQY8Kqw6eAS5Fm8dHSqV18lZv.yDs3wPFAcqgFHc VKkEum6RcGew7YJiJTJqnI7wpmEk8ofinPK2GDobRyRbDZxLVy1q5SbD92wKGWLDXs4Sv_2JsQWI 7oyDNyHgfUB2toh1QkTa5O9NQ9Z5qxSHkrqV0kEF4L5kzXfbF0dvGxmy49DyDzwHyYnt9aqyf6PJ 4qu3N2z7tGX7hRdCRkMC9hGvvdBk4e7uowPbFFlNe9deA9zmv9HF7zZPfNMwanCVGuteXtQNAINi AquutmaSd2.KjGUFRjPt8pe9cPhTdIS7YY..BtG1Vd2UMunGO9zXnJIurE6k7_UtAlDL9.ckGyAP 4MccXjy_XpUmDkckq.pJxEXQ_sHesM_lUaJJuCgiWHiwG.nGflqe9ZUfXy5Gfwg0NHExTBkygpfP zDTaICjUyQ8hw7CSw_ynsStNuY.PnZgWqk3.znhKaWPztmOWrgA2CqatvJmg9Pmbt3G9hrRk58Jk cPuRLER3lhIWUP11mgBxWL8V4XmdKgeiGlfLIK4ZaATd4q_UF5UsxmCrHRe_bI0iD1KQbIdB_fW4 0CN7vhtlpjcN8XsY0zOtuD9HVbQpZEgc2vpXU5DsGqD7lSWjcCaM5eT4jeapltTRRPcCsZQgnMBK cUO6tGIM9HhL3NbOOBFxN33dthMrZa8gAX2RAbKLcyxCY0t1ZEUWt00CaRN52CCl7m98F5CVPLOa kldNzCokpNUXR8Q7a47b6uIfuLoWSQi9GtXbO0Tp528yxXbf1LMWimf4ajsl2mNtVXXQn17FPDC5 d9CXa9kr6rURPlM27s4IPjtklhnBzYLz0n8VV8n2M9djCXw6PCAHloXenFEux0ay7OpJar6QRcBh vYn.v8jn8Wrsaz4dRMR58y.UsiaTt2IB.fYrIjpsA_8_tW3nBrd.yi3qS5hyghqU2LeTAxE.tabn S6ii8h7jJuYVLR3yYjM3l5YprPL_2r36nBYpoL6d_ycn4LgbLY572VcgmMysqrVfe.hCG4rGuu0_ 1FwtKYH.xpDNRs3JdPtGWaTwIfRZ8tqCeOFAfBkEj5Ay37IBnPwCdHR1p3mb6n_iNoC3UQTIpnSy C3D2xLr8mx_Uv0ZyxTxjLugw2iZc6C4kj2VUlOnSjel1WNLrD.zhQ4iYHlN8HhLKdLg_gQM83fmG YsB40_CcKRjjQT.pvBbEwITZnnzG9V7hlK6md8xbGSXGNIpPSvvo98RHqKO806Xc28Yvtk_gmChK ifQRTgh9c8mqza5nhd2rGydQn9_GWCISBqotbV.0R91KvMfPUXYkWmNQmTZ1caMJqo0DwIseuBla rY7XNS3R0UEJkiAoGID4THyEwYqA3rRq9SxRw.4aMIyKgW7JQgB_qBw2EkdgurnEwfFwBnVC05on 1qkNLJzYDjFO.B4Me95aqMGBbqBY10TtFiQIpAusEk.VR3UfatyxDc85rIlhyrE3t2ugZk.Ff8Mm OI5UB6.iEGqN9H4nBEW9DFF4LrQ7LdHokrZpo7rl2HrcrgQ8pIa2YKVlHpIhTjinjwYhIRK1ePIE KpzPAfRcf0ZnmPrZfyc6SlT3yFmS8Ya_wUjHo5QaKdVVAuMcEZbFhuasfP8cDB07RXRZ5th_3M2r wjGK5ZO2e3x1CvxOMbVn2nVMukzEt7x1GVZMacK3EDxMDVUGXVzJOYt5XFLgcsTLO0bj5UCWOBtP Shr4IPIj087vRv58J5Ynjp553T2TiBUYZtpdV48qvv.duwNR3b9r5ZaiBu2UVhHFPcNOJdw63zFC K0e4FB7XVnGgRlyJ2p.KOWXYOdzrW24GwXTHlzcBeLb7QxLNOdBl1.WLV6vta_ecRAp9ffNy1h67 Tjw9_vl0jnJW_hMmW1J86D.xB7LVhuzPPTQ.lTiP7oEPgJEQ15yr7UE9GxhDVCtr_EXD7Ttl0AC. bWR6Y8T7CHNH0tg9JwT8ucqFK.xT2iTVKqDYRN8x9SMuSw6yDz9hxentVxV0r0HHjM178h.EhJap D3ekX_VgLhD1CbXBMK1Dj6OiYYZLf_2Wq3u0auF6r.CxVmnXFohg8kpp4enErRtTW7cyf0FbJb9x VKsQjQK4gJ6gW_sMkF2TZpDFWe1zU19_NedVYOqJXLCZkmAtwVdZ0bzl3xkMXLfotbCjsCBFmPrA HC8xWTbA7SAlWykVi X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 7 Jan 2022 22:28:53 +0000 Received: by kubenode507.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 14737cf4c348bad4fbc1d1ad423c217a; Fri, 07 Jan 2022 22:28:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: FYI: An example type of UBSAN failure during kyua test -k /usr/tests/Kyuafile From: Mark Millard In-Reply-To: <1fb8db3d-3d12-68ab-95d6-5f6e01af49f3@FreeBSD.org> Date: Fri, 7 Jan 2022 14:28:47 -0800 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <453B3366-AED7-4F29-BC29-A880FA982E56@yahoo.com> References: <1fb8db3d-3d12-68ab-95d6-5f6e01af49f3@FreeBSD.org> To: Stefan Esser X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JVyYm5N4mz3HyM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-7, at 04:31, Stefan Esser wrote: > Am 07.01.22 um 12:49 schrieb Mark Millard: >> Having done a buildworld with both WITH_ASAN=3D and WITH_UBSAN=3D >> after finding what to control to allow the build, I installed >> it in a directory tree for chroot use and have >> "kyua test -k /usr/tests/Kyuafile" running. >>=20 >> I see evidence of various examples of one type of undefined >> behavior: "applying zero offset to null pointer" >>=20 >> # more = /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/356/stderr.txt=20= >> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> /usr/main-src/usr.bin/sed/process.c:715:18: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/usr.bin/sed/process.c:715:18 in=20 >> /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> Fail: stderr not empty >> --- /dev/null 2022-01-07 10:29:57.182903000 +0000 >> +++ /tmp/kyua.FKD2vh/356/work/check.Mk9llD/stderr 2022-01-07 = 10:29:57.173100000 +0000 >> @@ -0,0 +1,2 @@ >> +/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer >> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 >> Files left in work directory after failure: mntpt, mounterr >>=20 >>=20 >> In general the lib/libc/stdio/fread.c:133:10 example seems to >> be in a place that would make it fairly common. >=20 > Interesting find: >=20 > while (resid > (r =3D fp->_r)) { > (void)memcpy((void *)p, (void *)fp->_p, (size_t)r); > fp->_p +=3D r; /* line 133 */ > /* fp->_r =3D 0 ... done in __srefill */ > p +=3D r; > resid -=3D r; >=20 > If fp->_p =3D=3D NULL in line 133, then NULL has been passed as source = address > in memcpy() in the line above, and I'd think that is undefined = behavior, > even if a length of 0 is passed at the same time. My copy of ISO/IEC 9899:2011 (E) only explicitly mentions such a limitation for the memcpy_s variant. It does say "[t]he memcpy function returns the value of s1". The only mentioned "behavior is undefined" is for copying between objects that overlap. But there is more general wording in 7.24.1 (of 7.24 String handling ): QUOTE Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call still shall have valid values, as described in 7.1.4. On such a call, . . . a function that copies characters copies zero characters. END QUOTE But I've not noticed anything in 7.1.4 is that explicit about NULL arguments with zero sizes or that bans NULL arguments in any generality. In other words, I believe that the lack of a report for memcpy's argument values is consistent with what ISO/IEC 9899:2011 is explicit about for such things. I've not tried going through POSIX material or any other potential standards. > Maybe the code block quoted above (line 132 to 136) should be made = wrapped > into "if (r > 0) {}"? >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 7 23:33:42 2022 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 4EA46192EC89 for ; Fri, 7 Jan 2022 23:33:47 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JW00V4fg8z3jsY; Fri, 7 Jan 2022 23:33:46 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id e9so12363033wra.2; Fri, 07 Jan 2022 15:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:from :subject:content-transfer-encoding; bh=HYkkcZwk/2Mz4FBDtuQP8fayd34lka0kgQgZeu6wexU=; b=QKEAiL7862fr5HwsGH57MysWgyuJQuV1mr01gYXlsE2dTdv8vFdX6JYHmrJlkaq/7M OgPZR2cfYSeoeebstYsF7r9bsEtMjckeWtl4EfWMiijhUbvML6q0f3yWNoPhlfchrvDl C69T3YQFKjHdmcJgOdPVDB+0brGyXypIjNCUz+wSQdspbHKuD4PMYl1opzpTVLdZJKvA wA8HYldLfChTOkAizZJz8HeVTpoh0m0hMkObfofoNbUbWhBqoC8yuIYTcdrKRjJDbGaF eF9WGC1z56kR1HZWRbs15uaniYKBiMmagbwisXaPqM/qRfmjZDiEqjyMeSlAXbMTYYN4 f6uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:content-transfer-encoding; bh=HYkkcZwk/2Mz4FBDtuQP8fayd34lka0kgQgZeu6wexU=; b=7tUlyesN8+sEKvuw2ICWrOOs9r71ClUOeIr7vCdRuZV6pdaQg4VXmhDvde08eg+3dw T80/SUthbDadrWFJuFq+u6pH1sLZB/PKRoNlPYNc9vlmo/o3fGD7bSttzF2MwgJHpO/r c2/P21cmgDTGbK9cDfXNS1Wpnqzfoa3iKxjmij2CAxNmw5thkMPygg4i6dFAdPY7cF0n raC5ve3WWpQnpgJO2Lq/dxKDESnO11UD12CQAWRzYeHNi42nHXdSjgoEJepYieG5Yj0N rsJHSmRL+JpWeXtKqYsI3niFXgd5mmGsWwfv+kqtPPE3kKKKNfTTS/kW9UujEHLpWzuC J7tA== X-Gm-Message-State: AOAM5303i52k1Vf1mXTsL2acdzhpUoae2jGsC4Gfar3asGahWa1Yp6Xn ugAppA/b2MSnpmbKBw8bE1GkAm+a7nzusA== X-Google-Smtp-Source: ABdhPJwVMIO9HanhFOuyX2lstnEWcPvwOrmnRuwNIBxio9QCgVUTvOKzuMy6s6dR2WTa+TU4DGuVKQ== X-Received: by 2002:adf:eb4f:: with SMTP id u15mr7853528wrn.6.1641598423930; Fri, 07 Jan 2022 15:33:43 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id c18sm88834wrn.81.2022.01.07.15.33.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jan 2022 15:33:43 -0800 (PST) Message-ID: <2f5d80c6-b46f-2390-8cc1-e509e552b46c@gmail.com> Date: Fri, 7 Jan 2022 23:33:42 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-GB To: FreeBSD CURRENT From: Graham Perrin Subject: bhyve(8) manual page misrepresentation, option -k in particular X-Priority: 4 (Low) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JW00V4fg8z3jsY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=QKEAiL78; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.85 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.96)[-0.961]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.89)[-0.887]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; HAS_X_PRIO_THREE(0.00)[4]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Before I open a website bug report, someone please check my interpretation: * <621b5090487de9fed1b503769702a9a2a27cc7bb> (Refactor configuration management in bhyve) was committed 2021-03-18, MFC after three months, however (for whatever reason, not my concern) it is _not_ yet in stable/13 * online for stable/13, and the corresponding page for 13.0-RELEASE, _do_ include: -k In other words: * a bug with the site (online representations of manual pages). Agreed? ---- Here, in a test machine in VirtualBox, the manual page that's installed with 13.0-RELEASE-p4 appears to be correct; option -k is not mentioned. At a glance, I can find no cherry-pick relating to 621b5090487de9fed1b503769702a9a2a27cc7bb (or a truncation thereof). From nobody Sat Jan 8 03:12:27 2022 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 DD6AE193EAAC for ; Sat, 8 Jan 2022 03:12:36 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JW4s00jytz4mNM; Sat, 8 Jan 2022 03:12:36 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x432.google.com with SMTP id l10so14570438wrh.7; Fri, 07 Jan 2022 19:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language :from:to:references:in-reply-to:content-transfer-encoding; bh=FgLubKNp1Jm+P1yDgNb8/ZCSdJJOyt7Hq/BvXvgO6UM=; b=D1ccmfy4sXsmIeQ1zSGJ8CQpLOCdcxrhmYUuc005+46FO+ai0F6die0IeSdFyUuTor Z16TSkta8+Jt2fV9R4JNdF+KvubDINRe2MmNR5tTnNRq7Bk/w5MyH1vHivSUo+t/qlDB 5yVnmzGu3hcl546/htCn6nHF2wDq4fT792S1F5wRjGwkdvTBlud7qAuFH9Mfht6UrfBA ijcT2OKspXTU5dqxOiWVa5Tv5Cn9bfZSEc+MoZIdHaSZvlrRrcouBBRm6A0lXYuHlq2A RAuYu6kFyedi9vk+K5HaqiGhDsPExurW3EubMda76j2Ey4fd+xBoIYmdEtrWLogsm9fH X0LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:references:in-reply-to :content-transfer-encoding; bh=FgLubKNp1Jm+P1yDgNb8/ZCSdJJOyt7Hq/BvXvgO6UM=; b=QEahDxfxcMO+48DK3zgWFYLaoGwGacK9wId7VCpQvAYkI6JHzxphIM0xLzoknFJznV c5GCY7jYqLtkbx5BCyitm8p3Q0g7Q8zSk9owcGsVmAFiQom8K7nKjprkF/ibBwGrlQta TY1rqTc9m4bxI7i9bBFqDlAVssGOvu/TfUr57jCIbMjTeA9PXxt0alU6/txpy/sGw30K IC0+PWtLvroOVeRSkL1KsLlA3Pz8X3Ej85J1/6mEci+IzoMnzF4o9u5w3l3mb2Y0Sik7 70G33813A56Km/3x96gE8r7iV7UbxNdDexvoDzp4LDDnDjIFnaFLCHcUI7Zt+v0YDkZV TO1A== X-Gm-Message-State: AOAM533tG6nRzeSzjFUnx7mS0kR3n/xAYePDHWrSjayjoZuv7ZoVxV2y 1DaeUygxS483s6GSGC9h0p1vURmhuIP7dg== X-Google-Smtp-Source: ABdhPJwN44rgxgoyMEDz+j6j0iUPAWhp6AkPyiT7xSpZQb5739UmqNRDO3iD5pJ20gfuyfx/c5aX3g== X-Received: by 2002:a05:6000:1883:: with SMTP id a3mr17709986wri.565.1641611549129; Fri, 07 Jan 2022 19:12:29 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id c7sm421693wri.21.2022.01.07.19.12.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jan 2022 19:12:28 -0800 (PST) Message-ID: <49b241e7-6fea-e5e1-fe6c-b7a8c29dc7c3@gmail.com> Date: Sat, 8 Jan 2022 03:12:27 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: =?UTF-8?Q?=5bBug_261018=5d_An_online_manual_page_for_FreeBSD_13=2e0?= =?UTF-8?Q?-RELEASE_misrepresents_features_that_are_in_stable/13_=e2=80=93_n?= =?UTF-8?Q?ot_released?= Content-Language: en-GB From: Graham Perrin To: FreeBSD CURRENT References: <2f5d80c6-b46f-2390-8cc1-e509e552b46c@gmail.com> X-Priority: 5 (Lowest) In-Reply-To: <2f5d80c6-b46f-2390-8cc1-e509e552b46c@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JW4s00jytz4mNM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=D1ccmfy4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_HAM_LONG(-0.99)[-0.989]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::432:from]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; HAS_X_PRIO_FIVE(0.00)[5]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 07/01/2022 23:33, Graham Perrin wrote: > Before I open a website bug report, someone please check my > interpretation: > > * <621b5090487de9fed1b503769702a9a2a27cc7bb> (Refactor configuration > management in bhyve) was committed 2021-03-18, MFC after three months, > however (for whatever reason, not my concern) it is _not_ yet in > stable/13 … > Here, in a test machine in VirtualBox, the manual page that's > installed with 13.0-RELEASE-p4 appears to be correct; option -k is not > mentioned. > > At a glance, I can find no cherry-pick relating to > 621b5090487de9fed1b503769702a9a2a27cc7bb (or a truncation thereof). Correction: it _is_ in stable/13, . (My bad. I forgot, branch searching limitations.) I opened for the online manual page for bhyve(8) in FreeBSD 13.0-RELEASE. From nobody Sun Jan 9 14:46:52 2022 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 1148419372E6; Sun, 9 Jan 2022 14:47:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660072.outbound.protection.outlook.com [40.107.66.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JX0Cm73krz3pFS; Sun, 9 Jan 2022 14:47:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LxW+2gkd+L52V2PD+G7WnHyXsf694GLZFo5++vK7Zdz0CPrg4Pvn7paN4q0fX/zWRTKrhCbrWul2ISroPuAudG1FdpM3Q8MJF6iN+xgc5gQiJztT3FxQ54GWBHVEdCsryrJsoMyrMpZxhF4AyUoxM2jOUmmM0apUVwGajcO5INwT3p9wROP0N0Ce3HKaAV48bg9p/wEfxMlVdU+TWqcjJa3LF283oolkv/iaZUoR4K8aWEOVhVwa/ePOsrxIGEB0eJFvjCsY6AwaLW5rcFoSR+IgiSkEi0iSnltfrDtewWtZthgYoKebzKQGvcWpRsVADadH2BVGBcexNo33iRksuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uYvhNjkLBbpVVyabLbY/PKaBbE243acD1UAKCGLDaWE=; b=haLPjseGyjB6XICNH7x5bo+pYFg6M+M2P50kE+6ewLPx/+B1j/gMYJAL8qYS2GtysRkewq+KxVY1QBljRvOkRKPdgkICpQIy2N8BLSwQ/RZoqkcV1DGvchVAAcxg73QWeIb/l2YkIfiIyMd+lwp9j5agYnf04MKEI2Rqbx5wSoJ8sBf3Br1d3MUQXqmIf3B7IrjibrWUWW+8NkfospkbstBh9JfH6ZHkPc3dr5DO1p4T87/QYeU2Z/HpLP8NwGLelVfN72j9ASQWFCDVckUGq/+dBxjLM5iQLppK8ZQ8LQTMOMWeXNp6LDlJZ0ZdiFa5e/gQPnRyfK6T++dHU5GY2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uYvhNjkLBbpVVyabLbY/PKaBbE243acD1UAKCGLDaWE=; b=UC4rpMoWch9V6aJqdVGp1prfOVf0JtVV3wnszGHTRVTwD7meT9mXv60zu7kV+vavHIjoFF/747HfSS4vkafVk/+3SG/ksqYndWajvOIelipTcDLsNtVRp3deIz0KFlZLDntz7+i+XdwBX76LvL2ErADp/InTV7WsmEU9xk4rb3b/0l03m/gTGJb1EhSKMhuSDJP0IVSp4BUGiwXWBKn3X0BEyogyB8PVJLzKOJmn2pc0de2GgeZ+fgnJ2xchQkbCM/FtkPKH2SdPomG4mDDcUmLNEunWoh9ChQRToggG7n7jng0gBi3MNBWlrwO09owZwEInoyFPsQ7ja5UE57i/Jw== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB9327.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:62::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.7; Sun, 9 Jan 2022 14:46:53 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::c9d2:bf41:eeca:90aa]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::c9d2:bf41:eeca:90aa%4]) with mapi id 15.20.4867.011; Sun, 9 Jan 2022 14:46:53 +0000 From: Rick Macklem To: Miroslav Lachman <000.fbsd@quip.cz>, "freebsd-current@freebsd.org" , freebsd-stable CC: Yuri Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Topic: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Index: AQHXzvvFA1WWxQSLW0uUJGavCusr2KvuZUQAgABpl4WAAGcwgIBr+tlB Date: Sun, 9 Jan 2022 14:46:52 +0000 Message-ID: References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz> In-Reply-To: <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 0bff1c0c-4c91-73f7-655b-38d0c8fc7db0 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 833edab6-05d6-4750-5a23-08d9d37ee035 x-ms-traffictypediagnostic: YQBPR0101MB9327:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tp90gmxjhqZoLeQlvha8m3PSM0D6z5mJWR6kTi0FiN6hl0qMnn6DsIgw9KPK6Cd1wtyEE+HQBctfSnUH8xsPoXJ+37/1p10At6jIw+PRBSu6hlJb7EPH9mxTJaczWCPdHVBV2P8QFgFm9hULr6KlBMWgSCohvmLS6mX72viIktkW2zYQTv5Q1W4ybEXUJ8fkvI1YmFpDY7XPEvTjwP6M/THEMcIXPEs5tUPN/BLGX9wDHtPNAIJ5+DPVWAYUj6MrIN5kcGx5rEsC09/ERGeh6MjlPZ1Hzsq1kRUUxoxpUhkkmsANB5viaJELnGeJtqz5OMLhNKio4aSw1hzESG3sV+3CThMxkiOJwCpyVwuDppfrEdjwzmo2SM5JOg8FFBBvHbAYLC30bdXQmkv/8lpoL308iihS6ihwcjWqz6KVbkos21l+JbP8s94G35QqBjWsGm6GK9kwCd2rpaUtAqFEHbpcrspDKDGzMOYn385YNOy5QCLdv/ydlKpMueT7l8iZQgvTOXKtoekqg2BooHh1tWFRNBRxWebxPF5vXnRAtzLj1VTWdSVS0idHyvLrwuWLEdodzFhyDoPskMXE8Z6vA53lUE5teSgmnxs+LG6XHkW6+S99XhipK4GGhUEBewhk1rX53nbFW8h+f6ctR6w0SarKl0qA2PTYV+TRL707j+rTKW/+x3JFStCPhCsLyJC+XVUWfm5U5/nrJ/+yOb64RLHmXI8n86schHSQJv2xh4KYMJyvrRrk23T0l6lBAiOu/QcULe3jYG1SWOYHIaqzMtZRxis4NCt09IRSGTHxVOo= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(2906002)(508600001)(71200400001)(4326008)(786003)(316002)(55016003)(186003)(38100700002)(966005)(9686003)(53546011)(6506007)(7696005)(86362001)(83380400001)(66946007)(5660300002)(38070700005)(8936002)(8676002)(33656002)(110136005)(91956017)(64756008)(66446008)(52536014)(66556008)(66476007)(122000001)(76116006);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Pl5J6imZZfgBribnm6fTA20p24YBeKtTTG7fK2GsWdX7veicHXly0Z8lQ2Dk?= =?us-ascii?Q?xvYe5+3+XnhN6bHPmhgmHXzCl3N9XZowtpI9dbvGHqmMENeeeRRbTTMYviwC?= =?us-ascii?Q?JCtQfFCBM0VrJFsL//+ESbvAPyBJ+ByaQ+yqo8vxhd82FqwoN1wLJSTbSzOJ?= =?us-ascii?Q?l9QI7HcH0XguJ5OfzhC/Eapiau66IDvbHvFvr2cNntCm8G3R1tuDwN2oqO7G?= =?us-ascii?Q?ouy88wH/hUvk0PAKI5Rb3pEaHDGhH7ofgpK94Y5RFrhv4wUDfJRqoBErk0l+?= =?us-ascii?Q?VP18ebDHaHrXGuXfCLfqjI/viOd/57Q0CvJ+YLR+iS/AUdctNQGQx/harBK2?= =?us-ascii?Q?aiis1pUYnsAXoiR5fJCZpJlMCDhebBp6fPF9RjwTQj1u4pjBNQVbaL/XmNZl?= =?us-ascii?Q?gyMmhjFCY0I4BsOELVUa+RZ1IT1PA3dBGKeyrnPzbanZaMxE/8ns2JoKaUNo?= =?us-ascii?Q?MsLm8e5VBs4q77/DwgwdeZmJ8J7IxdKJ54pVvJTPmX9WqqlUWDVqFRZYuNNr?= =?us-ascii?Q?fqJABYfvK9vI4RPSqVqygFhNSnB0n7tlVXQflMwPMRpIEbXWz+Dxlu4A4w1p?= =?us-ascii?Q?eyg0uwnAcqm/tsbKOP9pT5rxqLMElGu+fERpvRJujJXbQmXoGHozwVg05O8Y?= =?us-ascii?Q?N07VH1FHaLOVHeyTg25U5ogxIFChDTOdcJ4gaa8RQ4Ro4swpP8LJg/n9ne0j?= =?us-ascii?Q?DBii+KNXUkoHxDxGVS5/MSgPkGtxyDyYMem8pY80XUboi3tANKssLCRPpwYO?= =?us-ascii?Q?sH11oC9632YBw2fRJeLUg0UUS+B/NUsTvVBlWk2AXY7zgs92L0SZJdCHQkf5?= =?us-ascii?Q?x8gryjP2tg6AY47ljE6HmiKlQl554jZTa+B7xQedH7Z0CRgYY0E0uODBoQko?= =?us-ascii?Q?35dcujd7prlCnQDNQyGPxdWfSv5I+soqC1CWKkJAy/5SHDAwChGG6CaYP/AM?= =?us-ascii?Q?545MH7RwUuiogJXMnzqtQdQgKlhAEYfgGdrKwTm4VN/f9A26IQfNrAvT858N?= =?us-ascii?Q?oxiauWmWWec8/Cqc0wBrjzbsvd1uTPNC+Pwuu5NjdIqmAuk3KvmsmML57oiq?= =?us-ascii?Q?gEd2xqkLqaKN27vyX+0jlSvMUU58I+DB6i5CD8FYhx8/ZJb9WLz+ldH+F7jY?= =?us-ascii?Q?eHl9NqAHqklbsoJZ3gsJlBO8Q1RxMFFJ0x+JbiR6xhEXpRlUiIKSUIZnRsqf?= =?us-ascii?Q?dW1pvHcRIgjAY+UtfTK1XFNHATzdJ4rFNvPI5M/qaJMNryI6XzSTWLqr/xQg?= =?us-ascii?Q?8kytcQcOgme2naBAFivlbkxDloOrDwcvrSZ5xlg+McrGXyZzt/I4vjQ/HZd2?= =?us-ascii?Q?9L3rl2z9l1xAGiA4I4sHodhUAaUAFq+1AWQ/qoIRWl5+ieo3BSENvk8fH7Xf?= =?us-ascii?Q?uFee6Q1P9Zyy7uo0RSeVJ5Z4IKrr5gbF8KSmoc3eqtzqLsU8rG6Y0OeZNRav?= =?us-ascii?Q?ndBHkb6I0xJlJy+KGnLJH9YjPlObjXSHxIo6jIODNL1azHyXsjukCul9pgD0?= =?us-ascii?Q?CGHypF2CKA/GQVwAdMNx6VWE2JPjPqIrBPritPpZwHlgCux7GEebdF+5ZtrW?= =?us-ascii?Q?3ZYt3cr5IL5es6MB0Olb1DjybZ0jqUyif9bcgy+cyeNaAKfxdxOU8Wc52nne?= =?us-ascii?Q?nXmYXJK+hf5rH6CmA20ITPaS5Pnht9OyHuliTjgel0mjiXsPbmGEvLLsZUYN?= =?us-ascii?Q?gEXgCQ=3D=3D?= 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 833edab6-05d6-4750-5a23-08d9d37ee035 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2022 14:46:52.9631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: L4jXdLDLOxHwzYAg0ZJHuhxoHpgQvaRAuMkasMiEel33IKkKqz33qQLXHX/4u9bBTRAsPmn3nhA9XIpsB3x7hg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB9327 X-Rspamd-Queue-Id: 4JX0Cm73krz3pFS X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=UC4rpMoW; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.72 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.72:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.72:from] X-ThisMailContainsUnwantedMimeParts: N Well, I took a look at the Apple code and I'm afraid I think porting it into FreeBSD is too big a job for me. I was hoping the code would have a layer that could be used as a "block box" for the VOP calls, but that does not seem to be the case. There is also a *lot* of code in it. I am going to look at the OpenSolaris code, to see if I think it will be an easier port. rick ________________________________________ From: Miroslav Lachman <000.fbsd@quip.cz> Sent: Monday, November 1, 2021 5:47 PM To: Rick Macklem; freebsd-current@freebsd.org; freebsd-stable Cc: Yuri Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 CAUTION: This email originated from outside of the University of Guelph. Do= not click links or open attachments unless you recognize the sender and kn= ow the content is safe. If in doubt, forward suspicious emails to IThelp@uo= guelph.ca On 01/11/2021 16:55, Rick Macklem wrote: > Miroslav Lachman wrote: > [good stuff snipped] >> Apple sources can be found there >> https://opensource.apple.com/source/smb/ with all the history from SMBv1 >> to SMBv3. The files have original copyright header from 2001 Boris Popov >> (same as FreeBSD) but otherwise it is very different code due to >> different kernel interfaces and so on. >> With Apple and Illumos sources it is possible to have smbfs in FreeBSD >> upgraded to v2 or v3 but very skilled programmer is needed for this >> work. And for the past years there is none interested in this work. > > Although I agree that it would be a non-trivial exercise, a lot of the Ap= ple > differences are in the "smoke and mirrors" category. > Around OSX 10.4, they changed their VFS/VOP to typedefs and accessor > functions. For example: > "struct vnode *vp" became "vnode_t vp" > and "vp->v_type" became "vnode_type(vp)" > > Ten years ago, the actual semantics were very close to what FreeBSD used. > If you look at sys/fs/nfs/nfskpiport.h in older sources (around FreeBSD 1= 0), > you'll see a bunch of macros I used to allow the Apple port to also build= /run > on FreeBSD (a couple, such as vnode_t are still left because I've never g= otten > around to doing the edit to replace them). If I see it right even the 10 years old Apple version of smbfs has support for SMBv2 so if this old version is closer to FreeBSD kernel / smbfs it can be a good starting point to merge changes to our smbfs to have SMBv2 support on FreeBSD. > The hard part will be dealing with the actual VFS/VOP semantics changes t= hat > have occurred in the last 10 years. > > Did they stick APSLs on the files? (If so, I think it could still be ok, = since the APSL > is a lot like the CDDL. However, I'm not sure if the APSL has ever been b= lessed > by FreeBSD as of yet?) The old versions of smbfs has original copyright header and no other license. Newer version has some added files with different header with APSL license. For example https://opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_sub= r_2.h.auto.html If license is a problem then I think it can live with APSL in the ports tree as a loadable kernel module. Maybe this will be the easier for development too? > Don't assume anything will happen, but I *might* take a look in the winte= r, > since outstanding NFS changes should be done by the end of 2021. I really appreciate your endless work on NFS on FreeBSD. Without your work the NFS will be lacking behind industry standards similar to what we see with smbfs. And if you will have some spare time to take a look on smbfs and maybe solve the SMBv2 / SMBv3 problem you will be my hero. I am waiting for it for many years and I know I am not alone who needs working SMB / CIFS on FreeBSD. > It does sound like there is some interest in this and that fuse doesn't s= olve > the problem (at least for everyone). Yes, there is an interest. It was discussed few times in the past in the mailing lists and web forums.freebsd.org but without anybody willing to touch the code. FUSE alternatives have so many problems with performance, stability and configuration. https://forums.freebsd.org/threads/getting-smbnetfs-to-work.78413/ Kind regards Miroslav Lachman From nobody Sun Jan 9 21:47:35 2022 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 D666E1944DDE for ; Sun, 9 Jan 2022 21:47:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JX9YJ3qX4z4dMb for ; Sun, 9 Jan 2022 21:47:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641764860; bh=0iIb2Kf3t8HReT4QNOkOsnVQxIb7oAZCN9HAmdP9LL0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=Ka/XwLNH/rT3WLwRuX3JyHM94HgFa8JrniIzckzNuxl7ucOarM3c0a9yL3udByGXBLJ3aAX2YFRFxSJgU2xb0ZlkXR+mhA7ug+Eh9G58lfma/BoIiwJ75lfPgt7OV/IeujCqBMxjPiOf6OMgNBROsRP3ienPhR/WDzHjGdUB5kby5h7dww+oydDlTl8eipS+D9+gJRpCvOud/cBVc5U+3JSMprg2A7+IMe7/9ZWu3x7ECQ2Eie5Q+gUt29NKc98wE686hk0mwXHTF+e+0ePVITAiVw31Fba2x5L5mk3lScPydVyPdRKjMnIqjTPhmU7rtMHbIjTPfTFD89RFjVMvsw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641764860; bh=ktkRKPecyqJuXXjLseh+622e1bBhpDK0c+aFe8xf7md=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=bBtK4yd1KRG9S5LM7Cn5URhB8GPGvXmhPuTJnkF5gSM+BNVZkTSk++tCUIHoT4ZqxOQbFM5Q6BWGD+aIqCaM8dQcFQhI6xM33sk4qF3Z1uBhdFmvx61XAUIl3TBfgdIipMvge5wC02TtfPrYqX+Ds4lGhPri0bv7Mt7p8Svh7YaytILUEcYy+GNyV9dx8ebzmswGBD1VqB+2aMONpI2RiINapeNH8NMyfiGa4S75J2XSuNOU9IFRWd3/Nqp93DDQ5l6Y+rG099aiGe9CuubCH3mwjmCFbXNOAjOqNiFm6G2JRXl1MG5vK5wrbjLUkh8t4O4ddPUGrCFf1/Q5B0GoUw== X-YMail-OSG: SWIsDAUVM1lhqOTP9kK9vD3IwUybDOZIEwl.d942wL3m4rQKpvA2osgBLsDme2Z LEG7O5u8AxiWaolChf7d_6DnkxaPUFIfyFbb8gUJg7_xDsRXwD_qKQM2irlfxOuFkAVFw1vtqkXR ItDU0PkccxGZesi.kVYHaSaDR.C29pFw70Nz0yPdoROSESTFtOHr.8L967sxC0CJM7VkJW0nP.GF nGWXBdibQ7pLPuQpwvkqWAp7UyM.iuMgtE.xiXtRD1581aVUSskMkqolgfh4jF5BfVAZBp7z311F 2kY9beHVUBi6F._STbA.cUu4AXLW0X_Cw4_zo8dHtGJ9PWAm2GxCWe9svNrGo40zO3fX1lMBiPYR sbe9tvKQMJpJYG64ywRrZ1RAjKql24VT5cNn1Nho882KipaFoAwBx2tvVPORuou8wFSLDkM4VzU0 uKopZgSwqUeRnpq_7_dCt21S1bHH8IbEIAb92cUjVpfofgbtGp2oa42i1Zv5TqBZmrqYrlKurAEp dQJ0C3weouvf0vrwsD0QJrOCIGE.9lwQS5l9O7qi_cV8Ck5GalfqAUOdgdyqO._9MCiLkW9L2v5g vde.Jgup5ZqE7bwYaPhq_oIkvkYhibf7yBoBDJTt2pBfou2hGidDeu7BeDz_9R3K0r2rgFjxRBdL d2M8AOb3moRjZGsR8ONwZvpaMYW9mo00TWT3mPS4796Y60XPax2hhSLNeTLbgl8uJRYExeeXlzTD Q6WPUGyki9fHtXDnBe.PycUXsJ_Z9t5PWQZ1Pqvg7G7l0ayC2ICt2.rslNM0zQs78jtGF9.oECAB ELFDE7raZY9ZdwMhIjJ5LC7YfIXkA32WdJBLCmp2k7gXXvnVCHkckFuwWndH4Wu41npnIPJozEtE FX3NbkzL5KOCS_Hg.VQ1vXK_i2RLYu65t6re9N.S5Ac26hsresRmrzJAuPs4TSJSZEX1OOurSnGz Eq.ez5_XtCN4KFSSvyxiWy3fdOFGvhuh4R2yCKrkhw74vNs1wAPsWL5Ie_EeQt5xxl0tIteyfzQQ 6_Z7ZEdkkXdAZtABQ76P2I4xHSyoE03p_jotURMDuB4FC0Mjgqrz6BR5EQlshMtLabpcUtsc6Nx6 MLf_3LU7RfO.2wxmTmHGKkT6.LFJb4LY0I1shcE5Yr61UZZMNeTcEt5RQ5Lwqogcwl2vpu6uCKDG 1U4SHYFoiYN1tcMfzBjC6xlYKmwvnVyqo9c_nagRg6v_VS9DoUEZ0RsXL15wqGcDTs4mEVUV8IeJ 6jLmS_DK126GRDkA7srE9fQpeWDuB1bAizvRsnNoU.P0TtVQLoOjhbusUR__zNMbNXYarFW7N91J wNCFBN1TpwpSOQCco79Xb7Vz2NZ9hu4g3A2AXd1tmE__GuE8Vik2vyhYuRQOp0tvvvAiXwBystfW Jyq1Pn0QWOt73jLsAkd4.lF7cRVpbHWMpgf1Zoeyc2vSEPYlYVV2c5lsq46xhVLTbFv4kYsqlqB_ f_Er3YjWWG8dwjq.DuIewEiUvGclL6pE8pxMfTRIzfyRLN3jpshIYY11npwO0uUSYgZh53vazmlK XX_N9aR3txhDIFmjl0eKWmlokwrnSS2YzP9_ji4RYOpFKuWlpxXYg3x7xk.JBOPio9nJ0bJnEAAv ga5iHWRTKZZqBqGX7zZwcvTszGrGHNDbQ7ib4Nv1xRAMqzAlCWfAJNefpDeCcmFFKfPl6wo8WO8P GKc9WnldafPkQr8vSPKFpPMULiESOLAnhLXmvvZ5KReHL06OjdC1yS43U_blyHb8J2wNONnnzJMr 3KCchmvjiGujuTvgME6.b3BTKLG24kgRtPvC_5gnAd8geCFkBZ49Q3GFFQ6H_MXvT61VpF3AAgZp R9HkL3s_ossTgF5CITJVzEvCUDB4d5Sm1twYBa8QZsi4ja5OKaAx4OxVO2lJV5BIEssTrW5JRe6O n.BiDUncQMecta78dHNIXQcq_areYhGyEtIpaHk7zKm1IOH1AHKDbKLYjy5.gL1YpULteg0Vll7O Q0Jzv3YGTjyU17kKljKH6EhXSUeiNJfw8Pn_jies1YkU5ygXqfhm30Tn1tS0bkIT0bJe7sdsmb5P S4KFGMrjzIwS52Jz5Vu2GFChalea3Z3hMxzqgnDPOxBOzLQIzCADFuOE0EQC.Smj5FkT.rnqVnR1 Bw_syaLsZTAV9iJ0KRP8ZNO0Qfi97n8SKOEsYcOLlpyYPYhI7HkKaL566aJ9tdKcYUSjBDUFbSbi QiCRNc.nCAorS9HtyobalQSs- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 9 Jan 2022 21:47:40 +0000 Received: by kubenode537.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 02b1572cf004d032276ccf0b8503ad44; Sun, 09 Jan 2022 21:47:37 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: FYI: An example ASAN failure report during kyua test -k /usr/tests/Kyuafile (info for some more examples) Date: Sun, 9 Jan 2022 13:47:35 -0800 References: To: freebsd-current In-Reply-To: Message-Id: <4A33AD5F-A930-4E2C-854B-E8498C2928EC@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JX9YJ3qX4z4dMb X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="Ka/XwLNH"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [0.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-7, at 03:39, Mark Millard wrote: > Having done a buildworld with both WITH_ASAN=3D and WITH_UBSAN=3D > after finding what to control to allow the build, I installed > it in a directory tree for chroot use and have > "kyua test -k /usr/tests/Kyuafile" running. >=20 > I see evidence of one AddressSanitizer report. (kyua is still > running.) The context is: >=20 > # more = /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stdout.txt=20= > Executing command [ mkdir /tmp/kyua.FKD2vh/434/work/mntpt ] > mount -t tmpfs -o size=3D10M tmpfs /tmp/kyua.FKD2vh/434/work/mntpt > Executing command [ touch a ] > Executing command [ rm a ] > Executing command [ dd if=3D/dev/zero of=3Da bs=3D1m count=3D15 ] > Executing command [ rm a ] >=20 > # more = /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stderr.txt=20= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D14384=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on = address 0x7fffffffa948 at pc 0x000801f38f5a bp 0x7fffffffa830 sp = 0x7fffffffa828 > WRITE of size 8 at 0x7fffffffa948 thread T0 > #0 0x801f38f59 in strtoimax_l = /usr/main-src/lib/libc/stdlib/strtoimax.c:148:11 > #1 0x10de6c8 in strtoimax = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:3441:18 > #2 0x11a4723 in getq /usr/main-src/bin/test/test.c:560:6 > #3 0x11a4523 in intcmp /usr/main-src/bin/test/test.c:584:7 > #4 0x11a4523 in binop /usr/main-src/bin/test/test.c:351:10 > #5 0x11a2f06 in primary /usr/main-src/bin/test/test.c:317:10 > #6 0x11a2f06 in nexpr /usr/main-src/bin/test/test.c:275:9 > #7 0x11a28cb in aexpr /usr/main-src/bin/test/test.c:261:8 > #8 0x11a2a03 in aexpr /usr/main-src/bin/test/test.c:263:10 > #9 0x11a228b in oexpr /usr/main-src/bin/test/test.c:247:8 > #10 0x11a1fcf in testcmd /usr/main-src/bin/test/test.c:224:10 > #11 0x1145289 in evalcommand /usr/main-src/bin/sh/eval.c:1107:16 > #12 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 > #13 0x113fb34 in evaltree /usr/main-src/bin/sh/eval.c:225:4 > #14 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 > #15 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 > #16 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 > #17 0x113fc55 in evaltree /usr/main-src/bin/sh/eval.c:241:4 > #18 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 > #19 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 > #20 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 > #21 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 > #22 0x113eb88 in evalstring /usr/main-src/bin/sh/eval.c > #23 0x1179727 in main /usr/main-src/bin/sh/main.c:171:3 >=20 > Address 0x7fffffffa948 is located in stack of thread T0 at offset 264 = in frame > #0 0x801f387ff in strtoimax_l = /usr/main-src/lib/libc/stdlib/strtoimax.c:58 >=20 > This frame has 1 object(s): > [32, 36) '__limit.i.i.i' <=3D=3D Memory access at offset 264 = overflows this variable > HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork > (longjmp and C++ exceptions *are* supported) > SUMMARY: AddressSanitizer: stack-buffer-overflow = /usr/main-src/lib/libc/stdlib/strtoimax.c:148:11 in strtoimax_l > Shadow bytes around the buggy address: > 0x4ffffffff4d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff4f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff500: f1 f1 f1 f1 00 00 00 00 f1 f1 f1 f1 f8 f3 f3 f3 > 0x4ffffffff510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > =3D>0x4ffffffff520: 00 00 00 00 f3 f3 f3 f3 f3[f3]f3 f3 00 00 00 00 > 0x4ffffffff530: f1 f1 f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00 00 > 0x4ffffffff540: f1 f1 f1 f1 00 f2 f2 f2 00 f3 f3 f3 00 00 00 00 > 0x4ffffffff550: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > 0x4ffffffff560: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > 0x4ffffffff570: f2 f2 f2 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07=20 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > =3D=3D14384=3D=3DABORTING > Files left in work directory after failure: mntpt, mounterr >=20 I've found some manually reproducible AddressSanitizer reports and have a few other notes on some types of reports: # env SH=3D/bin/sh /bin/sh /usr/tests/bin/sh/builtins/trap1.0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D207414) LLVMSymbolizer: error reading file: No such file or directory #0 0x1112b31 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 #1 0x112e00b in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termination.cpp:86:5 #2 0x11153c1 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp #3 0x10bc5a3 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202:11 #4 0x10bc5a3 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 #5 0x10be09e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_errors.cpp:39= 0:7 #6 0x11104fc in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_report.cpp:47= 5:16 #7 0x10ca344 in memcpy = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:827:5 #8 0x80147c861 in handle_signal = /usr/main-src/lib/libthr/thread/thr_sig.c:313:2 #9 0x80147b1f4 in thr_sighandler = /usr/main-src/lib/libthr/thread/thr_sig.c:246:2 #10 0x7fffffffe8a2 ([vdso]+0x2d2) #11 0x801e1d969 in __sys_wait4 = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/lib/li= bc/_wait4.S:4 #12 0x801488d1b in __thr_wait4 = /usr/main-src/lib/libthr/thread/thr_syscalls.c:581:8 #13 0x10d6953 in wait3 = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:2463:13 #14 0x11716a7 in dowait /usr/main-src/bin/sh/jobs.c:1181:9 #15 0x1167977 in waitforjob /usr/main-src/bin/sh/jobs.c:1092:7 #16 0x1142301 in evalsubshell /usr/main-src/bin/sh/eval.c:442:16 #17 0x113f7e1 in evaltree /usr/main-src/bin/sh/eval.c:234:4 #18 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 #19 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 # /bin/sh /usr/tests/bin/sh/execution/path1.0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D207414) #0 0x1112b31 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 #1 0x112e00b in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termination.cpp:86:5 #2 0x11153c1 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp #3 0x10bc5a3 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202:11 #4 0x10bc5a3 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 #5 0x10be09e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_errors.cpp:39= 0:7 #6 0x11104fc in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_report.cpp:47= 5:16 #7 0x111163a in __asan_report_store8_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:128:1= #8 0x801e0f80c in bintime2timespec = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/us= r/include/sys/time.h:285:14 #9 0x801e0f80c in __vdso_clock_gettime = /usr/main-src/lib/libc/sys/__vdso_gettimeofday.c:195:2 #10 0x801e0e0c0 in clock_gettime = /usr/main-src/lib/libc/sys/clock_gettime.c:48:11 #11 0x10d54da in clock_gettime = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:2189:13 #12 0x11234f5 in __sanitizer::MonotonicNanoTime() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_linux_libcdep.cpp:860:3 #13 0x10ba02c in = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::PopulateFreeArray(__sanitizer::AllocatorStats*, unsigned = long, = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::RegionInfo*, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_primary64.h:790:45 #14 0x10b9c4b in = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::GetFromAllocator(__sanitizer::AllocatorStats*, unsigned = long, unsigned int*, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_primary64.h:220:11 #15 0x10b9955 in = __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocato= r64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::Refill(__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeCla= ssAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::PerClass*, = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >*, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_local_cache.h:103:9 #16 0x10b9615 in = __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocato= r64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::Allocate(__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::Lo= calAddressSpaceView> >*, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_local_cache.h:39:11 #17 0x10b9511 in = __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::A= P64<__sanitizer::LocalAddressSpaceView> >, = __sanitizer::LargeMmapAllocatorPtrArrayDynamic>::Allocate(__sanitizer::Siz= eClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64= <__sanitizer::LocalAddressSpaceView> > >*, unsigned long, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_combined.h:69:20 #18 0x10b6086 in __asan::Allocator::Allocate(unsigned long, unsigned = long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp= :537:29 #19 0x10b4818 in __asan::asan_malloc(unsigned long, = __sanitizer::BufferedStackTrace*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp= :980:34 #20 0x110be9b in malloc = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:130:10 #21 0x117aca3 in ckmalloc /usr/main-src/bin/sh/memalloc.c:71:6 #22 0x119eafc in redirect /usr/main-src/bin/sh/redir.c:126:9 #23 0x11450b3 in evalcommand /usr/main-src/bin/sh/eval.c:1092:3 #24 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #25 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 #26 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 # env SH=3D/bin/sh /bin/sh /usr/tests/bin/sh/expansion/cmdsubst21.0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D126718) LLVMSymbolizer: error reading file: No such file or directory #0 0x1112b31 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 #1 0x112e00b in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termination.cpp:86:5 #2 0x11153c1 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp #3 0x10bc5a3 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202:11 #4 0x10bc5a3 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 #5 0x10be09e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_errors.cpp:39= 0:7 #6 0x11104fc in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_report.cpp:47= 5:16 #7 0x10ca202 in memcpy = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:827:5 #8 0x80147c861 in handle_signal = /usr/main-src/lib/libthr/thread/thr_sig.c:313:2 #9 0x80147b1f4 in thr_sighandler = /usr/main-src/lib/libthr/thread/thr_sig.c:246:2 #10 0x7fffffffe8a2 ([vdso]+0x2d2) #11 0x801e1d8c9 in _sigsuspend = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/lib/li= bc/_sigsuspend.S:4 #12 0x80147b997 in __thr_sigsuspend = /usr/main-src/lib/libthr/thread/thr_sig.c:691:8 #13 0x11716d7 in dowait /usr/main-src/bin/sh/jobs.c:1190:4 #14 0x1167977 in waitforjob /usr/main-src/bin/sh/jobs.c:1092:7 #15 0x115252f in expbackq /usr/main-src/bin/sh/expand.c:527:16 #16 0x115252f in argstr /usr/main-src/bin/sh/expand.c:323:4 #17 0x1151178 in expandarg /usr/main-src/bin/sh/expand.c:241:2 #18 0x1142a0b in evalcommand /usr/main-src/bin/sh/eval.c:862:3 #19 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #20 0x113f9e6 in evaltree /usr/main-src/bin/sh/eval.c:218:4 #21 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 #22 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 By contrast, I'll note that: # env SH=3D/bin/sh /bin/sh /usr/tests/bin/sh/expansion/cmdsubst6.0 did not report anything (but did in the kyua run). I took one of the simpler backtraces that reports "((ptr[0] =3D=3D kCurrentStackFrameMagic)) !=3D (0)" and took a look: AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D326791) #0 0x10cfbd1 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 #1 0x10eb0ab in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termination.cpp:86:5 #2 0x10d2461 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp #3 0x1079643 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202:11 #4 0x1079643 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 #5 0x107b13e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_errors.cpp:39= 0:7 #6 0x10cd59c in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_report.cpp:47= 5:16 #7 0x10ce357 in __asan_report_load8_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:123:1= #8 0x8020ca16d in execl /usr/main-src/lib/libc/gen/exec.c:64:9 #9 0x80253dcf2 in _system = /usr/main-src/lib/libc/stdlib/system.c:89:3 #10 0x801acec72 in __thr_system = /usr/main-src/lib/libthr/thread/thr_syscalls.c:545:8 #11 0x10fe434 in systemf = /usr/main-src/contrib/libarchive/test_utils/test_main.c:3071:6 #12 0x10f42bf in test_help = /usr/main-src/contrib/libarchive/cat/test/test_help.c:52:6 #13 0x1101b2c in test_run = /usr/main-src/contrib/libarchive/test_utils/test_main.c:3561:2 #14 0x1101b2c in main = /usr/main-src/contrib/libarchive/test_utils/test_main.c:4062:9 *** forcing core dump so failure can be debugged *** Files left in work directory after failure: = bsdcat_test.2022-01-07T10.54.27-000 Looking at lib/libc/gen/exec.c:64 showed: while (va_arg(ap, char *) !=3D NULL) It appears to me that the backtrace runs into another problem during __asan_report_load8_noabort (already an error classification?) and ends up reporting that other problem instead. There are a fair number of other tests that also report such for that line of code in execl. While looking, I got (odd whitespace removed from the output and split into more lines): /usr/main-src/contrib/nvi/common/log.c:261:2: runtime error: member = access within null pointer of type 'log_t' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/nvi/common/log.c:261:2 in /usr/main-src/contrib/nvi/common/log.c:266:21: runtime error: member = access within null pointer of type 'log_t' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/nvi/common/log.c:266:21 in /usr/main-src/contrib/nvi/common/log.c:272:37: runtime error: member = access within null pointer of type 'log_t' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/nvi/common/log.c:272:37 in=20 (Some of my activity is outside the chroot that has ASAN/UBSAN but the above happened to be in the chroot.) I also looked at: =3D=3D99317=3D=3DERROR: AddressSanitizer: dynamic-stack-buffer-overflow = on address 0x7fffffffa300 at pc 0x0008020ca271 bp 0x7fffffffa2d0 sp = 0x7fffffffa2c8 WRITE of size 8 at 0x7fffffffa300 thread T0 #0 0x8020ca270 in execl /usr/main-src/lib/libc/gen/exec.c:74:10 #1 0x80253dcf2 in _system = /usr/main-src/lib/libc/stdlib/system.c:89:3 #2 0x801acec72 in __thr_system = /usr/main-src/lib/libthr/thread/thr_syscalls.c:545:8 #3 0x10fe434 in systemf = /usr/main-src/contrib/libarchive/test_utils/test_main.c:3071:6 #4 0x10f45f9 in test_stdin = /usr/main-src/contrib/libarchive/cat/test/test_stdin.c:37:6 #5 0x1101b2c in test_run = /usr/main-src/contrib/libarchive/test_utils/test_main.c:3561:2 #6 0x1101b2c in main = /usr/main-src/contrib/libarchive/test_utils/test_main.c:4062:9 Address 0x7fffffffa300 is located in stack of thread T0 SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow = /usr/main-src/lib/libc/gen/exec.c:74:10 in execl Shadow bytes around the buggy address: 0x4ffffffff410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff450: 00 00 00 00 00 00 00 00 00 00 00 00 ca ca ca ca =3D>0x4ffffffff460:[ca]ca ca ca cb cb cb cb f1 f1 f1 f1 00 00 00 f3 0x4ffffffff470: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 0x4ffffffff480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4a0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x4ffffffff4b0: 04 f2 00 00 00 00 f2 f2 f2 f2 00 00 00 00 f2 f2 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D99317=3D=3DABORTING *** forcing core dump so failure can be debugged *** Files left in work directory after failure: = bsdcat_test.2022-01-07T10.54.28-000 Looking at lib/libc/gen/exec.c:74 showed: argv[0] =3D arg; There are a fair number of other tests that also report such for that line of code in execl. There are also examples of the likes of: =3D=3D=3D> bin/pax/legacy_test:main Result: broken: TAP test program yielded invalid data: Load of = '/tmp/kyua.FKD2vh/2679/stdout.txt' failed: Output did not contain any = TAP plan and the program did not bail out . . . Standard error: ld-elf.so.1: /lib/libthr.so.3: Undefined symbol = "__asan_option_detect_stack_use_after_return" where the test does not seem to have been able to run at all because of the undefined symbol. Overall going through trying to summarize the AddressSanitizer reports looks much messier than doing so for the Undefined Behavior reports. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jan 10 02:58:30 2022 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 25D12194EA30 for ; Mon, 10 Jan 2022 02:58:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXJS60cnTz3lTg for ; Mon, 10 Jan 2022 02:58:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641783517; bh=KGGVwHOvhwoxfkAXHy818JW0YuV7O6faXs5G8dlDS5s=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=l2BE4K1oqrycWeGbd7n/Ezwkj/jaeKNSxrbRDkSaj41oy7EV6gaECBd1M/XJZa5VahhcCT/t2S+HNbTX+YwmspFZW7CzlrHR7iZLAwYOji9QU+XRRXArXHaWYcTjcXQJvx1Gqn2TqXhPrmmQ4IXhXq8x5keGXYZeVi7qcPuRwaC65Lv0X9vNkD17fKUfAbXiSxZsOx5TsDKLWuISqEsZYQMSwSYmgvl5xL9uK9+kkX7Y5a+MlqL1Ik+XC+k/DOhkv9flRs+M74sTA6P/VimdYoJptl96hPehSchAwkEPEmMz0WuZcHZNxpuFvDg4YESbVnwD94pYtCeqVzB0lMFq3w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641783517; bh=BJF8v4xfk/aL0XJTB2X0uSXncksKX5AIewntGLXqF+n=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=sDlC0DjSL+xwqGqsXY1r9sFer7kMfNpaj/3k4Q6xHwXSQVcNTrCXDB3lO3bggRzW17QmXj65+2dR8PiQR7MbiWtr9UgpIhVsPm5O9ohgxZkh6OEABl6EjOP6YNi9V56AwCbsd/9bMnIRdmZXO1TJdkymIvO1sI3NZuj9l6UwbdE1/KBKVmsHaVv5n75oj47Kp9X4KB6MPSzBwQ/cm81St3W20vWowX2pk5RGP2GChaKhdlYv2CY5ov3QpmsPPPVeWPO3NESpQY1Nlthfvo1wzmvj86ULJOEKI1OywIg7qzfWHF6W53G8jigZ88ogAv+oReaRjMOIMcfzF4ZQjdBuaw== X-YMail-OSG: E7KkeJsVM1lhz1ElsjRh8Xl16MWPSPpGe8jstQzRS8eeH_MzNswpHeTxnIeMKBj XNtCu9Q.sIRLwq5g5gRpziaYBI76a0Vntp.Cc0bgpORjSqeMl63sh9MS9S4ZS18zjjJ6sXNnHmot J67c_YFcAC_8GgRbQBb5u_RIjTo7on4cb5cI4Irpye1JND0ZgdIvVa8PQFbeDztjHA0YZ6cW_obb Wi9oTN8B2yA3Y7KvyQVoUb1OYSQU38rEtQaeN2bw0RGy5SjBRMFkQfAY6cKbnCasnxe.tswEIt.x 0LuSPuvoxhkC0.qCcZjSQh2DhrqjfrOJMBP5xYfdb6bIenoltgSQwM8.8_Py36sRw7HOZE.tRwND XbsnhYaZlxs9SX0hnlpm3eqTJbaJFoIotmz8j_iGpN8_SFYrsDCxUW9ZQm7oajrV3OIDkd1h.NYj xys.65hfNyMHGPxEXFznuIT_s4wdRKLN0.iolVMQ.wurnJuscazyz.tp411zm49beX8Sq00mpHno 0PEF5yBMjEssNAHfcImRZOrYOuTEt3yIPtvyzpz6BdiE7qrC7QH.QElSHWU9sVnS1V8Kuen6piLb 9ivJRuaBGp9GSF4ZoWK694FBJKDGtw4Jo5wl4WfPYXf87KpJUR5dnUHre6pvaU.tw14H28omrK1R O3D_v.VmhbRMeWfFuI6xgdxsscFwZd3c.75XoBg7fQZkiEtuOZ91wNja1FF2ZAgw4dnOC9XRzP4H g3a8Uf.rlvzLWnY6g3mBpj_9KgZ8v1OUo2knfFqqCNcwob.7Bc1Wbl6ffNEDYVuyqmmvWIFoR7bK NCZ.KPF4hMpicrEqpTvCDvDeWHZVYydZkskjE3_gcgAYxRPAM7fQppaHVVhn0x426VAib0RbQsx_ q8.puw2_xd9ZLiO99S5SQkr4Rx6Jx0WNvihg1ssWoprzBn1MpzLzwDrjN06RhsgJViPeBmx4bnNR kmifkYMzZwYfmdEMwNnhdjEreILvYC6s9JrkI9oKY4heaS9kXUwMgZuiXyGdGOrkkazUOM0C6tGg QEAeqftKw1A0vHL1ctGdQdEvIQps16s3hp2CIe6Ux8q53RSp1s9UdWexx6DigAz1_7YCNiGlwc5i 9J6bF6.FiRcxurC7W7vyjZ1KOH0GjDhmGAvJpLsIfEiXMQXOPAlZkHoX6SbZLa.aIqtEr6qRpEci _R6g5lD..yj.c2lxE4Ab0iY87aN54aCgw14G0SqtH_hNMMDM01RfkKNKdGOzKW7xkSHio6Jhwjtp OpyWjVj_Ym6.D654DaeIFlLoYuG_zBMCx4DAfjfWjW5mkEXzkJVTMa81dv6EhakrrO9fOHeX8DGa _6tZKHYKeIA.q71qzxg8aFhjCo9Fxw1.TplQlwX_iVujGAuWhOLJRKdA.UG4EuTtZ53FU.gLFXX. x2y_uofrQ1CHNJetzYZdl2ipkbxP_pX8W2AYEUQi3fuVPNTsi8Uwx8BNzTnOL0U1Q_P2KPcL7QcX QZSiy5mnMxVOp6NGYgnJlLK2tozV9agyrfTRnMqPQz7RxQRzEmT3yT9QBC2DFZsJwPCid6NrFpOL m5snUjWLw9Pew6Qdk0Iw9JS2Z963C7qhlh1_4DEUURP_J6FUCHz_KFZWi.ZYBE079SSAKYQ7WdBj ihyJLyGUQ8ZT83YgqfF0RCB9uqom3DVLaqFT1vFAaQh_ipyVBr4ULiDPa4uxaGZ7fntupsWOVFKK Zy9UOSRTkU15D7OmhkD9VG0hykTBLd1e.59bl_qOmLj.pN_oKToH4HQaIy1eBjMEDM6vY3ohmyHI 0T.ElWTfd7bTue7KdUK2_nWMC_9A09jWM5cPxEbu6rGKBC0wO6EIxOp23aIYR9tBch4RF9icRV6T flIuf_jpgvIEkn2qN_s_l9pFeoJXABRZEiczALg4rif2C2lqgoID5CeLARDL5mDlVUS4dnkWSLo5 BetFVarjUuuTuKzi_O9kznmGh4zlN7x8jIomeGf1pqtt4BeJz1JvyyQ6Y8UUexdT7S2ad1EDTggN JLpTOi0reb6kevXTUGbn4z.e.Q7Nj07Lxww1yWBl1UnPkWqoINmV74oClGlZCe1c2gmlt4Hds5LA wnddLBBXiMysxSEvLQqavWmM9Ga7.SLTBOKeHY4e8VOwFk81yMSgCr56Y_PIgHSVCmylgP5d9otq y7Bn6vy__yLaTilGSpUPspCCyI1lMeIvfQk.mLS68gjFU9wgKOMcr7Mmp6xcMdH591Efp6xqAgAk acXYM1CZKlPs6QilIYg947iA- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 10 Jan 2022 02:58:37 +0000 Received: by kubenode500.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 45e8c4b7a4188b24939bb7a3cb028462; Mon, 10 Jan 2022 02:58:32 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: FYI: An example ASAN failure report during kyua test -k /usr/tests/Kyuafile (info for some more examples) Date: Sun, 9 Jan 2022 18:58:30 -0800 References: <4A33AD5F-A930-4E2C-854B-E8498C2928EC@yahoo.com> To: freebsd-current In-Reply-To: <4A33AD5F-A930-4E2C-854B-E8498C2928EC@yahoo.com> Message-Id: <6DB6844A-107A-45CA-9041-E851FACB3E90@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JXJS60cnTz3lTg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=l2BE4K1o; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.35 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_MEDIUM(-0.85)[-0.855]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-9, at 13:47, Mark Millard wrote: > On 2022-Jan-7, at 03:39, Mark Millard wrote: >=20 >> Having done a buildworld with both WITH_ASAN=3D and WITH_UBSAN=3D >> after finding what to control to allow the build, I installed >> it in a directory tree for chroot use and have >> "kyua test -k /usr/tests/Kyuafile" running. >>=20 >> I see evidence of one AddressSanitizer report. (kyua is still >> running.) The context is: >>=20 >> # more = /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stdout.txt=20= >> Executing command [ mkdir /tmp/kyua.FKD2vh/434/work/mntpt ] >> mount -t tmpfs -o size=3D10M tmpfs /tmp/kyua.FKD2vh/434/work/mntpt >> Executing command [ touch a ] >> Executing command [ rm a ] >> Executing command [ dd if=3D/dev/zero of=3Da bs=3D1m count=3D15 ] >> Executing command [ rm a ] >>=20 >> # more = /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stderr.txt=20= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D14384=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on = address 0x7fffffffa948 at pc 0x000801f38f5a bp 0x7fffffffa830 sp = 0x7fffffffa828 >> WRITE of size 8 at 0x7fffffffa948 thread T0 >> #0 0x801f38f59 in strtoimax_l = /usr/main-src/lib/libc/stdlib/strtoimax.c:148:11 >> #1 0x10de6c8 in strtoimax = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:3441:18 >> #2 0x11a4723 in getq /usr/main-src/bin/test/test.c:560:6 >> #3 0x11a4523 in intcmp /usr/main-src/bin/test/test.c:584:7 >> #4 0x11a4523 in binop /usr/main-src/bin/test/test.c:351:10 >> #5 0x11a2f06 in primary /usr/main-src/bin/test/test.c:317:10 >> #6 0x11a2f06 in nexpr /usr/main-src/bin/test/test.c:275:9 >> #7 0x11a28cb in aexpr /usr/main-src/bin/test/test.c:261:8 >> #8 0x11a2a03 in aexpr /usr/main-src/bin/test/test.c:263:10 >> #9 0x11a228b in oexpr /usr/main-src/bin/test/test.c:247:8 >> #10 0x11a1fcf in testcmd /usr/main-src/bin/test/test.c:224:10 >> #11 0x1145289 in evalcommand /usr/main-src/bin/sh/eval.c:1107:16 >> #12 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 >> #13 0x113fb34 in evaltree /usr/main-src/bin/sh/eval.c:225:4 >> #14 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 >> #15 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 >> #16 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 >> #17 0x113fc55 in evaltree /usr/main-src/bin/sh/eval.c:241:4 >> #18 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 >> #19 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 >> #20 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 >> #21 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 >> #22 0x113eb88 in evalstring /usr/main-src/bin/sh/eval.c >> #23 0x1179727 in main /usr/main-src/bin/sh/main.c:171:3 >>=20 >> Address 0x7fffffffa948 is located in stack of thread T0 at offset 264 = in frame >> #0 0x801f387ff in strtoimax_l = /usr/main-src/lib/libc/stdlib/strtoimax.c:58 >>=20 >> This frame has 1 object(s): >> [32, 36) '__limit.i.i.i' <=3D=3D Memory access at offset 264 = overflows this variable >> HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork >> (longjmp and C++ exceptions *are* supported) >> SUMMARY: AddressSanitizer: stack-buffer-overflow = /usr/main-src/lib/libc/stdlib/strtoimax.c:148:11 in strtoimax_l >> Shadow bytes around the buggy address: >> 0x4ffffffff4d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x4ffffffff4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x4ffffffff4f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x4ffffffff500: f1 f1 f1 f1 00 00 00 00 f1 f1 f1 f1 f8 f3 f3 f3 >> 0x4ffffffff510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> =3D>0x4ffffffff520: 00 00 00 00 f3 f3 f3 f3 f3[f3]f3 f3 00 00 00 00 >> 0x4ffffffff530: f1 f1 f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00 00 >> 0x4ffffffff540: f1 f1 f1 f1 00 f2 f2 f2 00 f3 f3 f3 00 00 00 00 >> 0x4ffffffff550: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >> 0x4ffffffff560: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >> 0x4ffffffff570: f2 f2 f2 f2 f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 >> Shadow byte legend (one shadow byte represents 8 application bytes): >> Addressable: 00 >> Partially addressable: 01 02 03 04 05 06 07=20 >> Heap left redzone: fa >> Freed heap region: fd >> Stack left redzone: f1 >> Stack mid redzone: f2 >> Stack right redzone: f3 >> Stack after return: f5 >> Stack use after scope: f8 >> Global redzone: f9 >> Global init order: f6 >> Poisoned by user: f7 >> Container overflow: fc >> Array cookie: ac >> Intra object redzone: bb >> ASan internal: fe >> Left alloca redzone: ca >> Right alloca redzone: cb >> =3D=3D14384=3D=3DABORTING >> Files left in work directory after failure: mntpt, mounterr >>=20 >=20 > I've found some manually reproducible AddressSanitizer reports > and have a few other notes on some types of reports: >=20 > # env SH=3D/bin/sh /bin/sh /usr/tests/bin/sh/builtins/trap1.0 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D207414) > LLVMSymbolizer: error reading file: No such file or directory > #0 0x1112b31 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 > #1 0x112e00b in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termination.cpp:86:5 > #2 0x11153c1 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp > #3 0x10bc5a3 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202:11 > #4 0x10bc5a3 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 > #5 0x10be09e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_errors.cpp:39= 0:7 > #6 0x11104fc in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_report.cpp:47= 5:16 > #7 0x10ca344 in memcpy = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:827:5 > #8 0x80147c861 in handle_signal = /usr/main-src/lib/libthr/thread/thr_sig.c:313:2 > #9 0x80147b1f4 in thr_sighandler = /usr/main-src/lib/libthr/thread/thr_sig.c:246:2 > #10 0x7fffffffe8a2 ([vdso]+0x2d2) > #11 0x801e1d969 in __sys_wait4 = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/lib/li= bc/_wait4.S:4 > #12 0x801488d1b in __thr_wait4 = /usr/main-src/lib/libthr/thread/thr_syscalls.c:581:8 > #13 0x10d6953 in wait3 = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:2463:13 > #14 0x11716a7 in dowait /usr/main-src/bin/sh/jobs.c:1181:9 > #15 0x1167977 in waitforjob /usr/main-src/bin/sh/jobs.c:1092:7 > #16 0x1142301 in evalsubshell /usr/main-src/bin/sh/eval.c:442:16 > #17 0x113f7e1 in evaltree /usr/main-src/bin/sh/eval.c:234:4 > #18 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 > #19 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 >=20 > # /bin/sh /usr/tests/bin/sh/execution/path1.0 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D207414) > #0 0x1112b31 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 > #1 0x112e00b in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termination.cpp:86:5 > #2 0x11153c1 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp > #3 0x10bc5a3 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202:11 > #4 0x10bc5a3 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 > #5 0x10be09e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_errors.cpp:39= 0:7 > #6 0x11104fc in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_report.cpp:47= 5:16 > #7 0x111163a in __asan_report_store8_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:128:1= > #8 0x801e0f80c in bintime2timespec = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/us= r/include/sys/time.h:285:14 > #9 0x801e0f80c in __vdso_clock_gettime = /usr/main-src/lib/libc/sys/__vdso_gettimeofday.c:195:2 > #10 0x801e0e0c0 in clock_gettime = /usr/main-src/lib/libc/sys/clock_gettime.c:48:11 > #11 0x10d54da in clock_gettime = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:2189:13 > #12 0x11234f5 in __sanitizer::MonotonicNanoTime() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_linux_libcdep.cpp:860:3 > #13 0x10ba02c in = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::PopulateFreeArray(__sanitizer::AllocatorStats*, unsigned = long, = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::RegionInfo*, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_primary64.h:790:45 > #14 0x10b9c4b in = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::GetFromAllocator(__sanitizer::AllocatorStats*, unsigned = long, unsigned int*, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_primary64.h:220:11 > #15 0x10b9955 in = __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocato= r64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::Refill(__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeCla= ssAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::PerClass*, = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >*, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_local_cache.h:103:9 > #16 0x10b9615 in = __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocato= r64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::Allocate(__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::Lo= calAddressSpaceView> >*, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_local_cache.h:39:11 > #17 0x10b9511 in = __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::A= P64<__sanitizer::LocalAddressSpaceView> >, = __sanitizer::LargeMmapAllocatorPtrArrayDynamic>::Allocate(__sanitizer::Siz= eClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64= <__sanitizer::LocalAddressSpaceView> > >*, unsigned long, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_combined.h:69:20 > #18 0x10b6086 in __asan::Allocator::Allocate(unsigned long, = unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, = bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp= :537:29 > #19 0x10b4818 in __asan::asan_malloc(unsigned long, = __sanitizer::BufferedStackTrace*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp= :980:34 > #20 0x110be9b in malloc = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:130:10 > #21 0x117aca3 in ckmalloc /usr/main-src/bin/sh/memalloc.c:71:6 > #22 0x119eafc in redirect /usr/main-src/bin/sh/redir.c:126:9 > #23 0x11450b3 in evalcommand /usr/main-src/bin/sh/eval.c:1092:3 > #24 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 > #25 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 > #26 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 >=20 > # env SH=3D/bin/sh /bin/sh /usr/tests/bin/sh/expansion/cmdsubst21.0 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D126718) > LLVMSymbolizer: error reading file: No such file or directory > #0 0x1112b31 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 > #1 0x112e00b in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termination.cpp:86:5 > #2 0x11153c1 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp > #3 0x10bc5a3 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202:11 > #4 0x10bc5a3 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 > #5 0x10be09e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_errors.cpp:39= 0:7 > #6 0x11104fc in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_report.cpp:47= 5:16 > #7 0x10ca202 in memcpy = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:827:5 > #8 0x80147c861 in handle_signal = /usr/main-src/lib/libthr/thread/thr_sig.c:313:2 > #9 0x80147b1f4 in thr_sighandler = /usr/main-src/lib/libthr/thread/thr_sig.c:246:2 > #10 0x7fffffffe8a2 ([vdso]+0x2d2) > #11 0x801e1d8c9 in _sigsuspend = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/lib/li= bc/_sigsuspend.S:4 > #12 0x80147b997 in __thr_sigsuspend = /usr/main-src/lib/libthr/thread/thr_sig.c:691:8 > #13 0x11716d7 in dowait /usr/main-src/bin/sh/jobs.c:1190:4 > #14 0x1167977 in waitforjob /usr/main-src/bin/sh/jobs.c:1092:7 > #15 0x115252f in expbackq /usr/main-src/bin/sh/expand.c:527:16 > #16 0x115252f in argstr /usr/main-src/bin/sh/expand.c:323:4 > #17 0x1151178 in expandarg /usr/main-src/bin/sh/expand.c:241:2 > #18 0x1142a0b in evalcommand /usr/main-src/bin/sh/eval.c:862:3 > #19 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 > #20 0x113f9e6 in evaltree /usr/main-src/bin/sh/eval.c:218:4 > #21 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 > #22 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 >=20 >=20 > By contrast, I'll note that: >=20 > # env SH=3D/bin/sh /bin/sh /usr/tests/bin/sh/expansion/cmdsubst6.0 >=20 > did not report anything (but did in the kyua run). >=20 >=20 > I took one of the simpler backtraces that reports > "((ptr[0] =3D=3D kCurrentStackFrameMagic)) !=3D (0)" and > took a look: >=20 > AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D326791) > #0 0x10cfbd1 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 > #1 0x10eb0ab in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termination.cpp:86:5 > #2 0x10d2461 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp > #3 0x1079643 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202:11 > #4 0x1079643 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 > #5 0x107b13e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_errors.cpp:39= 0:7 > #6 0x10cd59c in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_report.cpp:47= 5:16 > #7 0x10ce357 in __asan_report_load8_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:123:1= > #8 0x8020ca16d in execl /usr/main-src/lib/libc/gen/exec.c:64:9 > #9 0x80253dcf2 in _system = /usr/main-src/lib/libc/stdlib/system.c:89:3 > #10 0x801acec72 in __thr_system = /usr/main-src/lib/libthr/thread/thr_syscalls.c:545:8 > #11 0x10fe434 in systemf = /usr/main-src/contrib/libarchive/test_utils/test_main.c:3071:6 > #12 0x10f42bf in test_help = /usr/main-src/contrib/libarchive/cat/test/test_help.c:52:6 > #13 0x1101b2c in test_run = /usr/main-src/contrib/libarchive/test_utils/test_main.c:3561:2 > #14 0x1101b2c in main = /usr/main-src/contrib/libarchive/test_utils/test_main.c:4062:9 >=20 > *** forcing core dump so failure can be debugged *** >=20 > Files left in work directory after failure: = bsdcat_test.2022-01-07T10.54.27-000 >=20 > Looking at lib/libc/gen/exec.c:64 showed: >=20 > while (va_arg(ap, char *) !=3D NULL) >=20 > It appears to me that the backtrace runs into another problem > during __asan_report_load8_noabort (already an error classification?) > and ends up reporting that other problem instead. >=20 > There are a fair number of other tests that also report such for > that line of code in execl. >=20 >=20 > While looking, I got (odd whitespace removed from the output and > split into more lines): >=20 > /usr/main-src/contrib/nvi/common/log.c:261:2: runtime error: member = access within null pointer of type 'log_t' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/nvi/common/log.c:261:2 in > /usr/main-src/contrib/nvi/common/log.c:266:21: runtime error: member = access within null pointer of type 'log_t' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/nvi/common/log.c:266:21 in > /usr/main-src/contrib/nvi/common/log.c:272:37: runtime error: member = access within null pointer of type 'log_t' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/nvi/common/log.c:272:37 in=20 >=20 > (Some of my activity is outside the chroot that has ASAN/UBSAN > but the above happened to be in the chroot.) >=20 > I also looked at: >=20 > =3D=3D99317=3D=3DERROR: AddressSanitizer: = dynamic-stack-buffer-overflow on address 0x7fffffffa300 at pc = 0x0008020ca271 bp 0x7fffffffa2d0 sp 0x7fffffffa2c8 > WRITE of size 8 at 0x7fffffffa300 thread T0 > #0 0x8020ca270 in execl /usr/main-src/lib/libc/gen/exec.c:74:10 > #1 0x80253dcf2 in _system = /usr/main-src/lib/libc/stdlib/system.c:89:3 > #2 0x801acec72 in __thr_system = /usr/main-src/lib/libthr/thread/thr_syscalls.c:545:8 > #3 0x10fe434 in systemf = /usr/main-src/contrib/libarchive/test_utils/test_main.c:3071:6 > #4 0x10f45f9 in test_stdin = /usr/main-src/contrib/libarchive/cat/test/test_stdin.c:37:6 > #5 0x1101b2c in test_run = /usr/main-src/contrib/libarchive/test_utils/test_main.c:3561:2 > #6 0x1101b2c in main = /usr/main-src/contrib/libarchive/test_utils/test_main.c:4062:9 >=20 > Address 0x7fffffffa300 is located in stack of thread T0 > SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow = /usr/main-src/lib/libc/gen/exec.c:74:10 in execl > Shadow bytes around the buggy address: > 0x4ffffffff410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff450: 00 00 00 00 00 00 00 00 00 00 00 00 ca ca ca ca > =3D>0x4ffffffff460:[ca]ca ca ca cb cb cb cb f1 f1 f1 f1 00 00 00 f3 > 0x4ffffffff470: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 > 0x4ffffffff480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff4a0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 > 0x4ffffffff4b0: 04 f2 00 00 00 00 f2 f2 f2 f2 00 00 00 00 f2 f2 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07=20 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > =3D=3D99317=3D=3DABORTING > *** forcing core dump so failure can be debugged *** >=20 > Files left in work directory after failure: = bsdcat_test.2022-01-07T10.54.28-000 >=20 > Looking at lib/libc/gen/exec.c:74 showed: >=20 > argv[0] =3D arg; >=20 > There are a fair number of other tests that also report such for > that line of code in execl. >=20 >=20 >=20 > There are also examples of the likes of: >=20 > =3D=3D=3D> bin/pax/legacy_test:main > Result: broken: TAP test program yielded invalid data: Load of = '/tmp/kyua.FKD2vh/2679/stdout.txt' failed: Output did not contain any = TAP plan and the program did not bail out > . . . > Standard error: > ld-elf.so.1: /lib/libthr.so.3: Undefined symbol = "__asan_option_detect_stack_use_after_return" >=20 > where the test does not seem to have been able to run at all > because of the undefined symbol. >=20 >=20 > Overall going through trying to summarize the AddressSanitizer reports > looks much messier than doing so for the Undefined Behavior reports. >=20 For: +/usr/main-src/sys/contrib/zlib/deflate.c:1262:31: runtime error: load = of misaligned address 0x6310000148cd for type 'ushf' (aka 'unsigned = short'), which requires 2 byte alignment +0x6310000148cd: note: pointer points here + 19 86 a0 f0 d7 21 54 2f 17 85 a6 45 e3 21 a7 5e a6 24 d5 4a c5 c9 02 = 6f cd b8 04 55 b8 d8 49 a1 + ^=20 and many other examples at that source line, the line looks like: register ush scan_start =3D *(ushf*)scan; in "local uInt longest_match(s, cur_match)". Similarly for various other lines involving *(ushf*) in an expression. There are a lot of examples of the likes of: =3D=3D82301=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on = address 0x7fffffffce58 at pc 0x00000110152e bp 0x7fffffffce30 sp = 0x7fffffffc5f8 WRITE of size 24 at 0x7fffffffce58 thread T0 #0 0x110152d in sigaltstack = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:10044:5 #1 0x110e902 in __asan::PlatformUnpoisonStacks() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_posix.cpp:44:= 3 #2 0x11127f5 in __asan_handle_no_return = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:605:8= #3 0x1146099 in evalcommand /usr/main-src/bin/sh/eval.c:1151:3 #4 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #5 0x113f42b in evaltree /usr/main-src/bin/sh/eval.c:238:4 #6 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 #7 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 Address 0x7fffffffce58 is located in stack of thread T0 SUMMARY: AddressSanitizer: stack-buffer-overflow = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:10044:5 in sigaltstack Shadow bytes around the buggy address: 0x4ffffffff970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff9a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff9b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =3D>0x4ffffffff9c0: 00 00 00 00 00 00 00 00 f3 f3 f3[f3]00 00 00 00 0x4ffffffff9d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff9e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffa10: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f2 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb where bin/sh/eval.c:1151 (and 1152) is a common point and is: shellexec(argv, envp, path, cmdentry.u.index); /*NOTREACHED*/ There is an example of the following: =3D=3D82356=3D=3DABORTING #0 0x80148845d in __thr_fcntl = /usr/main-src/lib/libthr/thread/thr_syscalls.c:207:30 #1 0x801e18a44 in fcntl /usr/main-src/lib/libc/sys/fcntl.c:56:10 #2 0x119ef2b in redirect /usr/main-src/bin/sh/redir.c:146:13 #3 0x11450b3 in evalcommand /usr/main-src/bin/sh/eval.c:1092:3 #4 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #5 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 #6 0x113f672 in evalfor /usr/main-src/bin/sh/eval.c:367:3 #7 0x113f672 in evaltree /usr/main-src/bin/sh/eval.c:257:4 #8 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 #9 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 Address 0x7fffffffc780 is located in stack of thread T0 at offset 128 in = frame #0 0x8014881df in __thr_fcntl = /usr/main-src/lib/libthr/thread/thr_syscalls.c:195 This frame has 1 object(s): [32, 56) 'ap' (line 198) <=3D=3D Memory access at offset 128 = overflows this variable HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow = /usr/main-src/lib/libthr/thread/thr_syscalls.c:207:30 in __thr_fcntl Shadow bytes around the buggy address: 0x4ffffffff8a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff8b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff8c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff8d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff8e0: f1 f1 f1 f1 00 00 00 f3 f3 f3 f3 f3 00 00 00 00 =3D>0x4ffffffff8f0:[f3]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff900: f1 f1 f1 f1 00 00 00 f3 f3 f3 f3 f3 00 00 00 00 0x4ffffffff910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff930: 00 00 00 00 f1 f1 f1 f1 f8 f2 f2 f2 f8 f8 f8 f8 0x4ffffffff940: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb lib/libthr/thread/thr_syscalls.c is the middle line of: } else { ret =3D __sys_fcntl(fd, cmd, va_arg(ap, void *)); } in __thr_fcntl . lib/libc/sys/fcntl.c:56 is: return (((int (*)(int, int, ...)) __libc_interposing[INTERPOS_fcntl])(fd, cmd, arg)); but there seems to be only one report with those listed. So: bin/sh/redir.c:146 is: if ((i =3D fcntl(fd, F_DUPFD_CLOEXEC, 10)) =3D=3D = -1) { in redirect. There are examples like the following that needs a modal setting to enable the original intent of the test: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D14624=3D=3DERROR: AddressSanitizer: requested allocation size = 0xffffffffffffffff (0x800 after adjustments for alignment, red zones = etc.) exceeds maximum supported size of 0x10000000000 (thread T0) #0 0x10bbdfd in malloc = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:129:3 #1 0x8011583c6 in atf_dynstr_init_rep = /usr/main-src/contrib/atf/atf-c/detail/dynstr.c:230:26 #2 0x10e76db in atfu_init_rep_body = /usr/main-src/contrib/atf/atf-c/detail/dynstr_test.c:207:15 #3 0x80116bfb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #4 0x8011725e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #5 0x801171d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #6 0x801171d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 #7 0x106359c in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 #8 0x801112007 () =3D=3D14624=3D=3DHINT: if you don't care about these errors you may set = allocator_may_return_null=3D1 SUMMARY: AddressSanitizer: allocation-size-too-big = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:129:3 in malloc There is: =3D=3D20145=3D=3DERROR: AddressSanitizer: heap-buffer-overflow on = address 0x611000000140 at pc 0x00080197634c bp 0x7fffffffb190 sp = 0x7fffffffb188 WRITE of size 1 at 0x611000000140 thread T0 #0 0x80197634b in strnunvisx = /usr/main-src/contrib/libc-vis/unvis.c:547:7 #1 0x10a4da4 in strnunvisx = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:9250:13 #2 0x10a4a48 in strunvisx = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:9239:13 #3 0x10dc94e in atfu_strvis_basic_body = /usr/main-src/contrib/netbsd-tests/lib/libc/gen/t_vis.c:81:3 #4 0x80115cfb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #5 0x8011635e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #6 0x801162d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #7 0x801162d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 0x611000000140 is located 0 bytes to the right of 256-byte region = [0x611000000040,0x611000000140) allocated by thread T0 here: #0 0x10b276d in malloc = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:129:3 #1 0x10dc7ba in atfu_strvis_basic_body = /usr/main-src/contrib/netbsd-tests/lib/libc/gen/t_vis.c:71:2 #2 0x80115cfb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #3 0x8011635e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #4 0x801162d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #5 0x801162d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 #6 0x1059f0c in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 #7 0x801103007 () SUMMARY: AddressSanitizer: heap-buffer-overflow = /usr/main-src/contrib/libc-vis/unvis.c:547:7 in strnunvisx Shadow bytes around the buggy address: 0x4c21ffffffd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4c21ffffffe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4c21fffffff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4c2200000000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x4c2200000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =3D>0x4c2200000020: 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa fa fa 0x4c2200000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4c2200000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4c2200000050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x4c2200000060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x4c2200000070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D20145=3D=3DABORTING where contrib/libc-vis/unvis.c:547 is: *dst =3D '\0'; in strnunvisx and contrib/netbsd-tests/lib/libc/gen/t_vis.c:81 is: ATF_REQUIRE(strunvisx(dstbuf, visbuf, styles[i] & (VIS_HTTP1808|VIS_MIMESTYLE)) > 0); using strunvisx. So, looking: int strunvisx(char *dst, const char *src, int flag) { return strnunvisx(dst, (size_t)~0, src, flag); } So allowing being out of bounds, by effectively disabling CHECKSPACE() in strnunvisx, is not surprising. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D20511=3D=3DERROR: AddressSanitizer: stack-buffer-underflow on = address 0x7fffffffc220 at pc 0x000801a784c3 bp 0x7fffffffbcb0 sp = 0x7fffffffbca8 READ of size 4 at 0x7fffffffc220 thread T0 #0 0x801a784c2 in compat_setservent = /usr/main-src/lib/libc/net/getservent.c:855:7 #1 0x801a9144d in nsdispatch = /usr/main-src/lib/libc/net/nsdispatch.c:729:14 #2 0x10e2feb in servent_fill_test_data = /usr/main-src/lib/libc/tests/nss/getserv_test.c:290:2 #3 0x10e2feb in run_tests = /usr/main-src/lib/libc/tests/nss/getserv_test.c:443:7 #4 0x10e2dd4 in atfu_build_snapshot_body = /usr/main-src/lib/libc/tests/nss/getserv_test.c:502:2 #5 0x801165fb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #6 0x80116c5e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #7 0x80116bd70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #8 0x80116bd70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 Address 0x7fffffffc220 is located in stack of thread T0 at offset 0 in = frame #0 0x10e2e1f in run_tests = /usr/main-src/lib/libc/tests/nss/getserv_test.c:415 This frame has 4 object(s): [32, 48) 'param.i' (line 74) [64, 96) 'td' (line 416) [128, 160) 'td_snap' (line 416) [192, 224) 'td_2pass' (line 416) HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-underflow = /usr/main-src/lib/libc/net/getservent.c:855:7 in compat_setservent Shadow bytes around the buggy address: 0x4ffffffff7f0: f2 f2 f2 f2 00 f2 f2 f2 00 00 00 f3 f3 f3 f3 f3 0x4ffffffff800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =3D>0x4ffffffff840: 00 00 00 00[f1]f1 f1 f1 f8 f8 f2 f2 00 00 00 00 0x4ffffffff850: f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 00 00 0x4ffffffff860: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff870: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x4ffffffff880: f8 f8 f8 f2 f2 f2 f2 f2 f8 f8 f8 f3 f3 f3 f3 f3 0x4ffffffff890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D20511=3D=3DABORTING Looking around at this I wonder if var_arg handling is a false-positive context fairly generally. There is: =3D=3D=3D> lib/libcrypt/crypt_test:crypt_salts Result: broken: Empty test result or no new line Start time: 2022-01-07T10:55:18.806257Z End time: 2022-01-07T10:55:19.183751Z Duration: 0.377s Metadata: allowed_architectures is empty allowed_platforms is empty description =3D crypt(3) salt consistency checks has_cleanup =3D false is_exclusive =3D false required_configs is empty required_disk_space =3D 0 required_files is empty required_memory =3D 0 required_programs is empty required_user is empty timeout =3D 300 Standard error: *** Expected check failure: Old-style/bad inputs fail on FreeBSD: = /usr/main-src/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:142: Test 22 = ^A^BUZoIyj/Hy/c !=3D ^A^Bwyd0KZo65Jo *** Expected check failure: Old-style/bad inputs fail on FreeBSD: = /usr/main-src/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:142: Test 23 = a_Av8awQ0AsR6 !=3D a_C10Dk/ExaG. *** Check failed: = /usr/main-src/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:142: Test 24 = ~UZoIyj/Hy/c !=3D ~.5OTsRVjwLo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D2331=3D=3DERROR: AddressSanitizer: global-buffer-overflow on = address 0x0000010449c1 at pc 0x0008011c1ccd bp 0x7fffffffb950 sp = 0x7fffffffb948 READ of size 1 at 0x0000010449c1 thread T0 #0 0x8011c1ccc in crypt_des = /usr/main-src/secure/lib/libcrypt/crypt-des.c:651:24 #1 0x80119032f in crypt_r /usr/main-src/lib/libcrypt/crypt.c:130:6 #2 0x10a798d in crypt = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:9881:15 #3 0x10dc8f2 in atfu_crypt_salts_body = /usr/main-src/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:127:16 #4 0x80115bfb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #5 0x8011625e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #6 0x801161d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #7 0x801161d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 0x0000010449c1 is located 63 bytes to the left of global variable = '' defined in = '/usr/main-src/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:91:12' = (0x1044a00) of size 14 '' is ascii string 'CCX.K.MFy4Ois' 0x0000010449c1 is located 31 bytes to the left of global variable = '' defined in = '/usr/main-src/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:90:12' = (0x10449e0) of size 14 '' is ascii string 'CCNf8Sbh3HDfQ' 0x0000010449c1 is located 0 bytes to the right of global variable = '' defined in = '/usr/main-src/contrib/netbsd-tests/lib/libcrypt/t_crypt.c:88:36' = (0x10449c0) of size 1 '' is ascii string '' SUMMARY: AddressSanitizer: global-buffer-overflow = /usr/main-src/secure/lib/libcrypt/crypt-des.c:651:24 in crypt_des Shadow bytes around the buggy address: 0x4000002088e0: 00 00 05 f9 f9 f9 f9 f9 00 00 01 f9 f9 f9 f9 f9 0x4000002088f0: 00 00 05 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9 0x400000208900: 00 00 05 f9 f9 f9 f9 f9 00 02 f9 f9 00 00 05 f9 0x400000208910: f9 f9 f9 f9 00 02 f9 f9 00 00 05 f9 f9 f9 f9 f9 0x400000208920: 00 07 f9 f9 00 00 05 f9 f9 f9 f9 f9 00 01 f9 f9 =3D>0x400000208930: 00 00 05 f9 f9 f9 f9 f9[01]f9 f9 f9 00 06 f9 f9 0x400000208940: 00 06 f9 f9 00 06 f9 f9 00 06 f9 f9 00 06 f9 f9 0x400000208950: 00 06 f9 f9 00 01 f9 f9 00 06 f9 f9 00 06 f9 f9 0x400000208960: 00 06 f9 f9 00 06 f9 f9 00 06 f9 f9 00 06 f9 f9 0x400000208970: 00 06 f9 f9 02 f9 f9 f9 03 f9 f9 f9 03 f9 f9 f9 0x400000208980: 00 01 f9 f9 00 02 f9 f9 00 02 f9 f9 00 02 f9 f9 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D2331=3D=3DABORTING secure/lib/libcrypt/crypt-des.c:651 is: salt =3D (ascii_to_bin(setting[1]) << 6) | ascii_to_bin(setting[0]); There is: =3D=3D14241=3D=3DERROR: AddressSanitizer: attempting double-free on = 0x602000001870 in thread T0: #0 0x10cbd02 in free = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:111:3 #1 0x1108577 in (anonymous = namespace)::atfu_tc_dnvlist_take_binary__default_value::body() const = /usr/main-src/lib/libnv/tests/dnv_tests.cc:542:2 #2 0x8011b4fb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #3 0x801171e42 in atf::tests::tc::run(std::__1::basic_string, std::__1::allocator > const&) const = /usr/main-src/contrib/atf/atf-c++/tests.cpp:296:23 #4 0x801171e42 in (anonymous = namespace)::run_tc(std::__1::vector >&, std::__1::basic_string, std::__1::alloc ator > const&, atf::fs::path const&) = /usr/main-src/contrib/atf/atf-c++/tests.cpp:545:13 #5 0x801171e42 in (anonymous namespace)::safe_main(int, char**, void = (*)(std::__1::vector >&)) = /usr/main-src/contrib/atf/atf-c++/tests.cpp:627 :19 #6 0x801171e42 in atf::tests::run_tp(int, char**, void = (*)(std::__1::vector >&)) = /usr/main-src/contrib/atf/atf-c++/tests.cpp:651:16 0x602000001870 is located 0 bytes inside of 6-byte region = [0x602000001870,0x602000001876) freed by thread T0 here: #0 0x10cbd02 in free = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:111:3 #1 0x110856f in (anonymous = namespace)::atfu_tc_dnvlist_take_binary__default_value::body() const = /usr/main-src/lib/libnv/tests/dnv_tests.cc:541:2 #2 0x8011b4fb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #3 0x801171e42 in atf::tests::tc::run(std::__1::basic_string, std::__1::allocator > const&) const = /usr/main-src/contrib/atf/atf-c++/tests.cpp:296:23 #4 0x801171e42 in (anonymous = namespace)::run_tc(std::__1::vector >&, std::__1::basic_string, std::__1::alloc ator > const&, atf::fs::path const&) = /usr/main-src/contrib/atf/atf-c++/tests.cpp:545:13 #5 0x801171e42 in (anonymous namespace)::safe_main(int, char**, void = (*)(std::__1::vector >&)) = /usr/main-src/contrib/atf/atf-c++/tests.cpp:627 :19 #6 0x801171e42 in atf::tests::run_tp(int, char**, void = (*)(std::__1::vector >&)) = /usr/main-src/contrib/atf/atf-c++/tests.cpp:651:16 #7 0x10735ec in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 #8 0x80113a007 () previously allocated by thread T0 here: #0 0x10c2be4 in strdup = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_interceptors.= cpp:439:3 #1 0x11084e3 in set_binary_value(void*&, unsigned long&, char = const*) /usr/main-src/lib/libnv/tests/dnv_tests.cc:474:10 #2 0x11084e3 in (anonymous = namespace)::atfu_tc_dnvlist_take_binary__default_value::body() const = /usr/main-src/lib/libnv/tests/dnv_tests.cc:534:2 #3 0x8011b4fb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #4 0x801171e42 in atf::tests::tc::run(std::__1::basic_string, std::__1::allocator > const&) const = /usr/main-src/contrib/atf/atf-c++/tests.cpp:296:23 #5 0x801171e42 in (anonymous = namespace)::run_tc(std::__1::vector >&, std::__1::basic_string, std::__1::allocator > const&, = atf::fs::path const&) /usr/main-src/contrib/atf/atf-c++/tests.cpp:545:13 #6 0x801171e42 in (anonymous namespace)::safe_main(int, char**, void = (*)(std::__1::vector >&)) = /usr/main-src/contrib/atf/atf-c++/tests.cpp:627:19 #7 0x801171e42 in atf::tests::run_tp(int, char**, void = (*)(std::__1::vector >&)) = /usr/main-src/contrib/atf/atf-c++/tests.cpp:651:16 #8 0x10735ec in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 #9 0x80113a007 () SUMMARY: AddressSanitizer: double-free = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:111:3 in free =3D=3D14241=3D=3DABORTING Hmm . . . ATF_TEST_CASE_WITHOUT_HEAD(dnvlist_take_binary__empty); ATF_TEST_CASE_BODY(dnvlist_take_binary__empty) { nvlist_t *nvl; void *default_val, *actual_val; size_t default_size, actual_size; nvl =3D nvlist_create(0); set_binary_value(default_val, default_size, = "\xa8\x89\x49\xff\xe2\x08"); actual_val =3D dnvlist_take_binary(nvl, "123", &actual_size, = default_val, default_size); ATF_REQUIRE_EQ(default_size, actual_size); ATF_REQUIRE_EQ(memcmp(actual_val, default_val, actual_size), 0); free(actual_val); free(default_val); nvlist_destroy(nvl); } There are a number of other tests with similar code that also report double-free . =3D=3D=3D> sys/capsicum/functional:test_root . . . AddressSanitizer:DEADLYSIGNAL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D9539=3D=3DERROR: AddressSanitizer: SEGV on unknown address = 0x000000000000 (pc 0x0000011fe40b bp 0x7fffffffc4f0 sp 0x7fffffffbcb0 = T0) =3D=3D9539=3D=3DThe signal is caused by a READ memory access. =3D=3D9539=3D=3DHint: address points to the zero page. AddressSanitizer: CHECK failed: sanitizer_procmaps_bsd.cpp:69 "((Err)) = =3D=3D ((0))" (0xffffffffffffffff, 0x0) (tid=3D101026) AddressSanitizer: CHECK failed: sanitizer_procmaps_bsd.cpp:69 "((Err)) = =3D=3D ((0))" (0xffffffffffffffff, 0x0) (tid=3D101026) =3D=3D=3D> sys/capsicum/functional:test_unprivileged . . . [uid:977] /usr/tests/sys/capsicum/mini-me immediately returning = (geteuid() =3D=3D 0) =3D 0 AddressSanitizer:DEADLYSIGNAL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D9645=3D=3DERROR: AddressSanitizer: SEGV on unknown address = 0x000000000000 (pc 0x0000011fe40b bp 0x7fffffffc4f0 sp 0x7fffffffbcb0 = T0) =3D=3D9645=3D=3DThe signal is caused by a READ memory access. =3D=3D9645=3D=3DHint: address points to the zero page. AddressSanitizer: CHECK failed: sanitizer_procmaps_bsd.cpp:69 "((Err)) = =3D=3D ((0))" (0xffffffffffffffff, 0x0) (tid=3D101076) AddressSanitizer: CHECK failed: sanitizer_procmaps_bsd.cpp:69 "((Err)) = =3D=3D ((0))" (0xffffffffffffffff, 0x0) (tid=3D101076) Below are some reports that are likely for deliberate error handling tests where AddressSanitizer activity messes up the original purpose of the test. There is: Standard output: Executing command [ echo ok |/usr/tests/lib/libc/ssp/h_fgets 10 ] Executing command [ /usr/tests/lib/libc/ssp/h_fgets 10 ] Executing command [ echo 0123456789abc |/usr/tests/lib/libc/ssp/h_fgets = 13 ] Executing command [ /usr/tests/lib/libc/ssp/h_fgets 13 ] Standard error: Fail: program did not receive a signal stdout: /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 stderr: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D22446=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on = address 0x7fffffffd9ca at pc 0x0000010af17a bp 0x7fffffffcfd0 sp = 0x7fffffffc798 WRITE of size 12 at 0x7fffffffd9ca thread T0 #0 0x10af179 in __asan_memcpy = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_interceptors_= memintrinsics.cpp:22:3 #1 0x801b66afe in fgets /usr/main-src/lib/libc/stdio/fgets.c:110:9 #2 0x1070456 in fgets = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:1252:15 #3 0x10d9b37 in main = /usr/main-src/contrib/netbsd-tests/lib/libc/ssp/h_fgets.c:42:8 Address 0x7fffffffd9ca is located in stack of thread T0 at offset 42 in = frame #0 0x10d99ff in main = /usr/main-src/contrib/netbsd-tests/lib/libc/ssp/h_fgets.c:39 This frame has 1 object(s): [32, 42) 'b' (line 40) <=3D=3D Memory access at offset 42 overflows = this variable HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_interceptors_= memintrinsics.cpp:22:3 in __asan_memcpy Shadow bytes around the buggy address: 0x4ffffffffae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffaf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffb10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffb20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =3D>0x4ffffffffb30: 00 00 00 00 f1 f1 f1 f1 00[02]f3 f3 00 00 00 00 0x4ffffffffb40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffb50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffb60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffb70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D22446=3D=3DABORTING This is a very short program [(c) NetBSD]: #include __COPYRIGHT("@(#) Copyright (c) 2008\ The NetBSD Foundation, inc. All rights reserved."); __RCSID("$NetBSD: h_fgets.c,v 1.1 2010/12/27 02:04:19 pgoyette Exp $"); #include #include int main(int argc, char *argv[]) { char b[10]; int len =3D atoi(argv[1]); (void)fgets(b, len, stdin); (void)printf("%s\n", b); return 0; } The report is correct for the len =3D=3D 13 test case but this is another example of needing to avoid AddressSanitizer messing up the purpose of the test relative to normal usage (no ASAN). There are other such examples. Also: =3D=3D21507=3D=3DERROR: AddressSanitizer: invalid alignment requested in = aligned_alloc: 512, alignment must be a power of two and the requested = size 0x1 must be a multiple of alignment (thread T0) #0 0x10b1eb2 in aligned_alloc = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:176:3 #1 0x10dbc69 in atfu_aligned_alloc_basic_body = /usr/main-src/contrib/netbsd-tests/lib/libc/stdlib/t_posix_memalign.c:105:= 7 #2 0x80115afb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #3 0x8011615e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #4 0x801160d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #5 0x801160d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 #6 0x1058f7c in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 #7 0x801101007 () =3D=3D21507=3D=3DHINT: if you don't care about these errors you may set = allocator_may_return_null=3D1 SUMMARY: AddressSanitizer: invalid-aligned-alloc-alignment = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:176:3 in aligned_alloc =3D=3D21507=3D=3DABORTING =3D=3D21509=3D=3DERROR: AddressSanitizer: invalid alignment requested in = posix_memalign: 4, alignment must be a power of two and a multiple of = sizeof(void*) =3D=3D 8 (thread T0) #0 0x10b1ff7 in posix_memalign = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:210:3 #1 0x10db8c7 in atfu_posix_memalign_basic_body = /usr/main-src/contrib/netbsd-tests/lib/libc/stdlib/t_posix_memalign.c:69:9= #2 0x80115afb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #3 0x8011615e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #4 0x801160d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #5 0x801160d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 #6 0x1058f7c in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 #7 0x801101007 () =3D=3D21509=3D=3DHINT: if you don't care about these errors you may set = allocator_may_return_null=3D1 SUMMARY: AddressSanitizer: invalid-posix-memalign-alignment = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:210:3 in posix_memalign =3D=3D21509=3D=3DABORTING =3D=3D21665=3D=3DERROR: AddressSanitizer: SEGV on unknown address = 0xfffffffffffffff8 (pc 0x000801cd5174 bp 0x7fffffffc390 sp = 0x7fffffffbb48 T0) =3D=3D21665=3D=3DThe signal is caused by a READ memory access. #0 0x801cd5174 in strlen = /usr/main-src/lib/libc/amd64/string/strlen.S:47 #1 0x10dcfe9 in atfu_access_fault_body = /usr/main-src/contrib/netbsd-tests/lib/libc/sys/t_access.c:107:3 #2 0x80115dfb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #3 0x8011645e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #4 0x801163d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #5 0x801163d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 #6 0x1059efc in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 #7 0x801104007 () AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV = /usr/main-src/lib/libc/amd64/string/strlen.S:47 in strlen =3D=3D21665=3D=3DABORTING =3D=3D21670=3D=3DERROR: AddressSanitizer: heap-buffer-overflow on = address 0x619000000480 at pc 0x000001097bbb bp 0x7fffffffc390 sp = 0x7fffffffbb50 READ of size 1025 at 0x619000000480 thread T0 #0 0x1097bba in access = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:7185:5 #1 0x10ddcc3 in atfu_access_toolong_body = /usr/main-src/contrib/netbsd-tests/lib/libc/sys/t_access.c:202:3 #2 0x80115dfb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #3 0x8011645e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #4 0x801163d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #5 0x801163d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 0x619000000480 is located 0 bytes to the right of 1024-byte region = [0x619000000080,0x619000000480) allocated by thread T0 here: #0 0x10b275d in malloc = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:129:3 #1 0x10ddc07 in atfu_access_toolong_body = /usr/main-src/contrib/netbsd-tests/lib/libc/sys/t_access.c:190:8 #2 0x80115dfb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #3 0x8011645e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #4 0x801163d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #5 0x801163d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 #6 0x1059efc in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 #7 0x801104007 () SUMMARY: AddressSanitizer: heap-buffer-overflow = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:7185:5 in access Shadow bytes around the buggy address: 0x4c3200000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4c3200000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4c3200000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4c3200000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4c3200000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =3D>0x4c3200000090:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x4c32000000a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x4c32000000b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x4c32000000c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x4c32000000d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x4c32000000e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D21670=3D=3DABORTING =3D=3D21729=3D=3DERROR: AddressSanitizer: SEGV on unknown address = 0xffffffffffffffff (pc 0x000801203dd9 bp 0x7fffffffc3b0 sp = 0x7fffffffc030 T0) =3D=3D21729=3D=3DThe signal is caused by a READ memory access. #0 0x801203dd9 in __thr_setcontext = /usr/main-src/lib/libthr/thread/thr_sig.c:797:7 #1 0x10db6a3 in atfu_setcontext_err_body = /usr/main-src/contrib/netbsd-tests/lib/libc/sys/t_getcontext.c:96:2 #2 0x80115bfb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #3 0x8011625e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #4 0x801161d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #5 0x801161d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 #6 0x1058ddc in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 #7 0x801102007 () AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV = /usr/main-src/lib/libthr/thread/thr_sig.c:797:7 in __thr_setcontext =3D=3D21729=3D=3DABORTING =3D=3D21744=3D=3DERROR: AddressSanitizer: negative-size-param: (size=3D8) #0 0x107bbd0 in setitimer = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:2258:5 #1 0x10dca40 in atfu_setitimer_err_body = /usr/main-src/contrib/netbsd-tests/lib/libc/sys/t_getitimer.c:164:2 #2 0x80115bfb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #3 0x8011625e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #4 0x801161d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #5 0x801161d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 Address 0xffffffffffffffff is a wild pointer inside of access range of = size 0x000000000001. SUMMARY: AddressSanitizer: negative-size-param = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:2258:5 in setitimer =3D=3D21744=3D=3DABORTING =3D=3D21982=3D=3DERROR: AddressSanitizer: negative-size-param: (size=3D4) #0 0x1087b38 in read_pollfd(void*, __sanitizer::__sanitizer_pollfd*, = unsigned int) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:3953:5 #1 0x1087b38 in poll = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:3969:20 #2 0x10dd956 in atfu_poll_err_body = /usr/main-src/contrib/netbsd-tests/lib/libc/sys/t_poll.c:230:2 #3 0x80115cfb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #4 0x8011635e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #5 0x801162d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #6 0x801162d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 Address 0xffffffffffffffff is a wild pointer inside of access range of = size 0x000000000001. SUMMARY: AddressSanitizer: negative-size-param = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:3953:5 in read_pollfd(void*, = __sanitizer::__sanitizer_pollfd*, unsigned int) =3D=3D21982=3D=3DABORTING =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D22204=3D=3DERROR: AddressSanitizer: SEGV on unknown address = 0x000000000008 (pc 0x0000010dec62 bp 0x7fffffffc3d0 sp 0x7fffffffc120 = T0) =3D=3D22204=3D=3DThe signal is caused by a WRITE memory access. =3D=3D22204=3D=3DHint: address points to the zero page. #0 0x10dec62 in atfu_wait6_coredumped_body = /usr/main-src/contrib/netbsd-tests/lib/libc/sys/t_wait.c:165:14 #1 0x80115ffb4 in atf_tc_run = /usr/main-src/contrib/atf/atf-c/tc.c:1054:5 #2 0x8011665e3 in run_tc = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:504:15 #3 0x801165d70 in controlled_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:574:15 #4 0x801165d70 in atf_tp_main = /usr/main-src/contrib/atf/atf-c/detail/tp_main.c:604:11 #5 0x105b1ac in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 #6 0x801106007 () AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV = /usr/main-src/contrib/netbsd-tests/lib/libc/sys/t_wait.c:165:14 in = atfu_wait6_coredumped_body =3D=3D22204=3D=3DABORTING =3D=3D=3D> lib/libexecinfo/backtrace_test:backtrace_fmt_basic Result: failed: 6 checks failed; see output for more details . . . Standard output: got nptrs=3D19 ncalls=3D12 (min_frames: 4, max_frames: 9) backtrace is: #0: __interceptor_backtrace #1: myfunc3 #2: myfunc2 #3: myfunc1 #4: myfunc1 #5: myfunc1 #6: myfunc1 #7: myfunc1 #8: myfunc1 #9: myfunc1 #10: myfunc1 #11: myfunc1 #12: myfunc1 #13: myfunc1 #14: myfunc1 #15: myfunc #16: atfu_backtrace_fmt_basic_body #17: = _ZN6__asan9Allocator10DeallocateEPvmmPN11__sanitizer18BufferedStackTraceEN= S_9AllocTypeE #18: = _ZNK6__asan24GlobalAddressDescription27PointsInsideTheSameVariableERKS0_ Standard error: *** Check failed: = /usr/main-src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:95: = strings[0] !=3D "myfunc3" (__interceptor_backtrace !=3D myfunc3) *** Check failed: = /usr/main-src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:96: = strings[1] !=3D "myfunc2" (myfunc3 !=3D myfunc2) *** Check failed: = /usr/main-src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:99: = strings[j] !=3D "myfunc1" (myfunc2 !=3D myfunc1) *** Check failed: = /usr/main-src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:107: = strings[j] !=3D frames[i].name (myfunc1 !=3D myfunc) *** Check failed: = /usr/main-src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:107: = strings[j] !=3D frames[i].name (myfunc !=3D = atfu_backtrace_fmt_basic_body) *** Check failed: = /usr/main-src/contrib/netbsd-tests/lib/libexecinfo/t_backtrace.c:107: = strings[j] !=3D frames[i].name (atfu_backtrace_fmt_basic_body !=3D = atf_tc_run) The extra levels of calls involved mess up the test. That is all for now. There is lots more that I've not looked at (yet?). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jan 10 15:27:40 2022 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 E32591954BBC; Mon, 10 Jan 2022 15:27:52 +0000 (UTC) (envelope-from SRS0=eFGI=R2=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4JXd4R6B5Qz3p4J; Mon, 10 Jan 2022 15:27:51 +0000 (UTC) (envelope-from SRS0=eFGI=R2=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 59DE82842B; Mon, 10 Jan 2022 16:27:44 +0100 (CET) Received: from illbsd.quip.test (ip-78-45-215-131.net.upcbroadband.cz [78.45.215.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 4B50428416; Mon, 10 Jan 2022 16:27:41 +0100 (CET) Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 To: Rick Macklem , "freebsd-current@freebsd.org" , freebsd-stable Cc: Yuri References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <54704b99-7b89-76a4-0368-79bee391926d@quip.cz> Date: Mon, 10 Jan 2022 16:27:40 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JXd4R6B5Qz3p4J X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=eFGI=R2=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=eFGI=R2=quip.cz=000.fbsd@elsa.codelab.cz" X-Spamd-Result: default: False [-1.80 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=eFGI=R2=quip.cz=000.fbsd@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[78.45.215.131:received]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=eFGI=R2=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello Rick, thank you for the update and your time on smbfs. I hope OpenSolaris version will be portable. (or mayby some older version from Apple?) FreeBSD without possibility to mount smbfs is not an option for some projects. Kind regards Miroslav Lachman On 09/01/2022 15:46, Rick Macklem wrote: > Well, I took a look at the Apple code and I'm afraid I > think porting it into FreeBSD is too big a job for me. > > I was hoping the code would have a layer that could > be used as a "block box" for the VOP calls, but that > does not seem to be the case. > There is also a *lot* of code in it. > > I am going to look at the OpenSolaris code, to see if > I think it will be an easier port. > > rick > > ________________________________________ > From: Miroslav Lachman <000.fbsd@quip.cz> > Sent: Monday, November 1, 2021 5:47 PM > To: Rick Macklem; freebsd-current@freebsd.org; freebsd-stable > Cc: Yuri > Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca > > > On 01/11/2021 16:55, Rick Macklem wrote: >> Miroslav Lachman wrote: >> [good stuff snipped] >>> Apple sources can be found there >>> https://opensource.apple.com/source/smb/ with all the history from SMBv1 >>> to SMBv3. The files have original copyright header from 2001 Boris Popov >>> (same as FreeBSD) but otherwise it is very different code due to >>> different kernel interfaces and so on. >>> With Apple and Illumos sources it is possible to have smbfs in FreeBSD >>> upgraded to v2 or v3 but very skilled programmer is needed for this >>> work. And for the past years there is none interested in this work. >> >> Although I agree that it would be a non-trivial exercise, a lot of the Apple >> differences are in the "smoke and mirrors" category. >> Around OSX 10.4, they changed their VFS/VOP to typedefs and accessor >> functions. For example: >> "struct vnode *vp" became "vnode_t vp" >> and "vp->v_type" became "vnode_type(vp)" >> >> Ten years ago, the actual semantics were very close to what FreeBSD used. >> If you look at sys/fs/nfs/nfskpiport.h in older sources (around FreeBSD 10), >> you'll see a bunch of macros I used to allow the Apple port to also build/run >> on FreeBSD (a couple, such as vnode_t are still left because I've never gotten >> around to doing the edit to replace them). > > If I see it right even the 10 years old Apple version of smbfs has > support for SMBv2 so if this old version is closer to FreeBSD kernel / > smbfs it can be a good starting point to merge changes to our smbfs to > have SMBv2 support on FreeBSD. > >> The hard part will be dealing with the actual VFS/VOP semantics changes that >> have occurred in the last 10 years. >> >> Did they stick APSLs on the files? (If so, I think it could still be ok, since the APSL >> is a lot like the CDDL. However, I'm not sure if the APSL has ever been blessed >> by FreeBSD as of yet?) > > The old versions of smbfs has original copyright header and no other > license. Newer version has some added files with different header with > APSL license. For example > https://opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_subr_2.h.auto.html > > If license is a problem then I think it can live with APSL in the ports > tree as a loadable kernel module. Maybe this will be the easier for > development too? > >> Don't assume anything will happen, but I *might* take a look in the winter, >> since outstanding NFS changes should be done by the end of 2021. > > I really appreciate your endless work on NFS on FreeBSD. Without your > work the NFS will be lacking behind industry standards similar to what > we see with smbfs. > And if you will have some spare time to take a look on smbfs and maybe > solve the SMBv2 / SMBv3 problem you will be my hero. I am waiting for it > for many years and I know I am not alone who needs working SMB / CIFS on > FreeBSD. > >> It does sound like there is some interest in this and that fuse doesn't solve >> the problem (at least for everyone). > > Yes, there is an interest. It was discussed few times in the past in the > mailing lists and web forums.freebsd.org but without anybody willing to > touch the code. > FUSE alternatives have so many problems with performance, stability and > configuration. > https://forums.freebsd.org/threads/getting-smbnetfs-to-work.78413/ > > Kind regards > Miroslav Lachman > From nobody Tue Jan 11 07:33:58 2022 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 1F4F11932BE2 for ; Tue, 11 Jan 2022 07:34:12 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JY2WQ4lfqz3mHG for ; Tue, 11 Jan 2022 07:34:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641886442; bh=4kBysAfLNvmkDYAHwkKX9t55zcKIXdJhTblJPJ/igkI=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=BF/dEgKfEBPpfTB8Wfyri1KnHBh4sIw/+ahjCWdbChJ5LyTt0QKuV1ocbjp30FJDwT0EC1EtO/KId9jf3wWGiTgqs/my2lS2viYOI+pdJHWF1yV/mRZ9gGFYFkDYV3kyAjW7bZ7I/6l2d8mxsZoi3bFGZmtkxDEzHvIOA4ssPtAXM9lFecCdQ5vxCGl4/AwIGm+bx5veZqQYFYm0PM62g+YPxTBFkTO3ko5wFbFwfel1UVXLHgkzfI4aSZXVk0w/3o3nQv+G8x7y/6DCi8gZz+rUtAxG5/y7jdBvdnwAufCtKlfSZNqI+tvVYS1a+kegvJxMHgv/MJG80bGoN2LN4g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641886442; bh=IJgepnJ7bGN1mxoT3lX8O9r1imx3dH4KUiKPISYqAUr=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=brn/5X+PUzA//bUHk1yCXCFGZal5W3gmyTLvAOxAQIVUz2nVEObtFHWxbmivyXuE2w590ZjmF/+diMygwJtN3fQfPmj/HGcWhrraJcY71de1jbSRxt1TLe+HcLFlS3+sz14JY9KvIcCN0zJTiI0CKv7r1WDKdQQMpddRm7EEd7UlXxsvGnqW9da12rgoDlI0wXMRBnhWOXwokjv89XzIwNqwYJwoATg3Wy5DoPwLW0Qpdtt+GXG/9OBAhosIahi7kv652Dcu4DtNquRx6B0HHxCzpchvrSZNY1/ObxL/5821ps0qCzkRTbI+SWxHBe9+2+G6DNL54524jbUnKL5uvw== X-YMail-OSG: KmZNjtkVM1mKvUxhAbq18BAnLV3QjKMEOtEkWAjxWXBjXRnO2H6XnvAl_nzXP4x qM.0PqkywUzfj1a89TJF7ETwCs04Q4Vvu2nYGAYh5buY8.JJhc3yT9ud6YT5WQ8lCy8.NStLMHfA J6RspODBEUJKs_LS.Vz868IPjoyRJFqLc1ymD8BeeO7u_PFWlJvCld5l0ZBqR6ewCfXADKR78wzK U6V4ha1Oql3zC9g5c_AZMud4f08fN7ZnzpkA80bBY4Pj489QAbvnB5TAVOPKsF0rOW7sAJa9ze5l Z8xuhvJkUKwKvBnCEcquwTIGQLrqpjIKXCX16HmQ8CJBTkLC5PcMW5KBfo1.TID3PmqZt09W2NEL kYDn1qg87L4W0v0uKJXaVIV.5Q7Bn0QzAgGkk55EFJ0mYiUWKemFqPezkmhwhGO7sG.JMYrnZHg_ L4CBcVsH7KLIhAtNEKNNX.CH0QLvUkxWgRjKPvGF2VI0BZtX8BLCvUHHK2VS76DQ1wkiDJRLhxND RMmHzTWCYEbm8FDWFI670eUWP5zvaNAFWKpldg7vxwlqflMGvsdOeu_IMpMZlf4oItfO5G__DE7O LOi1zH1tq8JwROoI5pFxm6Ul_AUUI_.RsJ2H92.OCeuHN18x6Q.nJ1z4Gd_gB7xmmckdfR6cpCgZ tsfynQ2FLRM_M2L.UIrGdqSERO8qWCgSVQWn0_xB9HqKLsQVJVMmTn1_rTDyH321fqXU61.g0XFB TSyxj2JiONdd5YdACvoJZp9z7zOv.3sJCh1Be_gRvkleTPmNxdblsfCYQNIo4X_13.LONzw0NiIw ruIFbNjeeiUh4IWdxZWdbFfd6s9fdOz357ucdGrFAVe0HCmDSnL.s0GtYLMih_iIyejcw.q0IJNu _G74IspQezCS8nHdT9cJlCMovzF2vF5JEyynclJm6G.yeYZu87BMh3TmHa0TmF_mO_ucIDt09BSZ 2debtTQK_oLzkiWMTeP7rrzeGHN.YrESzDfWF1kGEvhjov.azRCcJ_t62vP1.LYndx2hATad8hwd _WVxDk2vW5Tuckl2g.srZZiU1bXFso.1_0cGSe4oyouysPkmAdK2UKDv4XOq2nqUO8e0M9JfUujS S1Ou8zWBhqojQUMXRB3pHS3kiLEsZYMXrMC2Hx5dgNLAjMhW52859HNv2XYkqDB7p5kxYn.l6wmH e5lAX0ugPWxfjLCDYnveD84RtxKnk1rCY7pm2aP0UxZFCHVj6jSfRHl2UUOu1Irty5qMNbvGe0s4 woemc_McvMCHhLxH0yTMfLnh4hQ.gsnBVYuWF8YaOwC6W16x0XGNrTaoHGR_OM197xfF_6iqgJDy Hps4jD_HnPp_i4EqPvMHgIfWJKZvZ.d.gGL9gWnn6H9_cxedP_1Vlf9NpqqbDQpd5SFbA1R4PdvU DzriZk9UriioRSUbMW_Mk_3PYwhMSXS2f.LswR3SI3eQ_UN1wQDpoOw_NbbcPGrRW8C123leTnFl tQHqTwIGhk_YocK5pb1GNhP6E3fCVq9.YWUFI6rFsnDYYzy7YDPVdy0FqdLcq.qP56htir90b_Nn wshqdX7_Ba22VVyhIK._xS4Wo4qF8pFVMiUXp.a6BLBy9qnbvpQ9d8zbJBXOENyKHn9PIzTgoiNh UY8ArACuCR4yrJbI.aNhnwMmL3chPx6c7WxXRZF7b1txKqhpHrI1J5Ur2sZKQRsSTIIdJzZr7u_X IptXBM.C1E6J1ml3AsWhWPgIC3GaiHDTehKFl8_uApcnPurwgzCQbn7hiQ7vRs9oMuNd0y4TcebH TUOgF3JvkJtlLWygSawIo_gYLABIhDXeg1Ek8Ouj9ROu9sbzKowhx_Ie6K2Q4dolggnSIGC7wlKn upkFD9zffHAirKEqDk_2gxq_ljSf1LkJeV03sO2DCdA5J8OogVEvIhKM72sA0l19v_qrLu5orcYQ 1MKghWRtrKzgopldUq5lYFuR7lxlOqmdDUOZ.ovZpLRYufVUUmAkd10N7XRrzic2YDfiw64ahDrY K8UMPEHsA6S8FfkL3l44pnUx00KiRrow8Xdr0jPh6RVbXMQJTXLH0w0m7xN4PizGyoqRHkT6eTpu SLUdTEeyZzr3dRMUFcPmH4PFL36U0BaEITt_7TocICMN_45QsoxrxNSSJklYwUHzYKgVi03opo94 3Mc6NQjoEYJTncPx5EKSrVNnsl4aXa4MFtszOJ_v51waxM1Lz.5L.GJbu2LJhh.tR6Pq6HjoDSBW cPUKOOXXiu3FAB0AYh7UrGA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Jan 2022 07:34:02 +0000 Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 21d524bf82ce5b0403344a94092d5ba0; Tue, 11 Jan 2022 07:34: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 14.0 \(3654.120.0.1.13\)) Subject: UBSAN report for main [so: 14] /usr/sbin/traceroute: various misaligned address reports Message-Id: <22B1E944-641D-4BD3-A4B2-384767D966FC@yahoo.com> Date: Mon, 10 Jan 2022 23:33:58 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <22B1E944-641D-4BD3-A4B2-384767D966FC.ref@yahoo.com> X-Rspamd-Queue-Id: 4JY2WQ4lfqz3mHG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="BF/dEgKf"; 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 X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N I tried a /usr/sbin/traceroute from a chroot that had been built using WITH_UBSAN=3D in use. It got the common lib/libc/stdio/fread.c zero = offset to null pointer notice but also reported "member access within = misaligned address" for types: 'struct ifreq', which requires 8 byte alignment 'union (unnamed union at = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/us= r/include/net/if.h:398:2)', which requires 8 byte alignment 'struct sockaddr', which requires 8 byte alignment 'unsigned char', which requires 8 byte alignment The reports are: /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 /usr/main-src/contrib/traceroute/ifaddrlist.c:113:13: runtime error: = member access within misaligned address 0x7fffffff55fc for type 'struct = ifreq', which requires 8 byte alignment 0x7fffffff55fc: note: pointer points here 00 00 00 00 6c 6f 30 00 00 00 00 00 00 00 00 00 00 00 00 00 1c 1c 00 = 00 00 00 00 00 fe 80 00 02 ^=20 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/traceroute/ifaddrlist.c:113:13 in=20 /usr/main-src/contrib/traceroute/ifaddrlist.c:113:13: runtime error: = member access within misaligned address 0x7fffffff560c for type 'union = (unnamed union at = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/us= r/include/net/if.h:398:2)', which requires 8 byte alignment 0x7fffffff560c: note: pointer points here 00 00 00 00 1c 1c 00 00 00 00 00 00 fe 80 00 02 00 00 00 00 00 00 00 = 00 00 00 00 01 00 00 00 00 ^=20 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/traceroute/ifaddrlist.c:113:13 in=20 /usr/main-src/contrib/traceroute/ifaddrlist.c:113:13: runtime error: = member access within misaligned address 0x7fffffff560c for type 'struct = sockaddr', which requires 8 byte alignment 0x7fffffff560c: note: pointer points here 00 00 00 00 1c 1c 00 00 00 00 00 00 fe 80 00 02 00 00 00 00 00 00 00 = 00 00 00 00 01 00 00 00 00 ^=20 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/traceroute/ifaddrlist.c:113:13 in=20 /usr/main-src/contrib/traceroute/ifaddrlist.c:113:22: runtime error: = load of misaligned address 0x7fffffff560c for type 'unsigned char', = which requires 8 byte alignment 0x7fffffff560c: note: pointer points here 00 00 00 00 1c 1c 00 00 00 00 00 00 fe 80 00 02 00 00 00 00 00 00 00 = 00 00 00 00 01 00 00 00 00 ^=20 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/traceroute/ifaddrlist.c:113:22 in=20 /usr/main-src/contrib/traceroute/ifaddrlist.c:118:13: runtime error: = member access within misaligned address 0x7fffffff55fc for type 'struct = ifreq', which requires 8 byte alignment 0x7fffffff55fc: note: pointer points here 00 00 00 00 6c 6f 30 00 00 00 00 00 00 00 00 00 00 00 00 00 1c 1c 00 = 00 00 00 00 00 fe 80 00 02 ^=20 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/traceroute/ifaddrlist.c:118:13 in=20 /usr/main-src/contrib/traceroute/ifaddrlist.c:118:13: runtime error: = member access within misaligned address 0x7fffffff560c for type 'union = (unnamed union at = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/us= r/include/net/if.h:398:2)', which requires 8 byte alignment 0x7fffffff560c: note: pointer points here 00 00 00 00 1c 1c 00 00 00 00 00 00 fe 80 00 02 00 00 00 00 00 00 00 = 00 00 00 00 01 00 00 00 00 ^=20 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/traceroute/ifaddrlist.c:118:13 in=20 /usr/main-src/contrib/traceroute/ifaddrlist.c:118:13: runtime error: = member access within misaligned address 0x7fffffff560c for type 'struct = sockaddr', which requires 8 byte alignment 0x7fffffff560c: note: pointer points here 00 00 00 00 1c 1c 00 00 00 00 00 00 fe 80 00 02 00 00 00 00 00 00 00 = 00 00 00 00 01 00 00 00 00 ^=20 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/traceroute/ifaddrlist.c:118:13 in=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Jan 11 07:40:43 2022 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 983EB19352ED for ; Tue, 11 Jan 2022 07:40:49 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JY2g46QSdz3pQD for ; Tue, 11 Jan 2022 07:40:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641886847; bh=EPmqCINJzxj/gRy0G5UmtBID8NrvdccB6xjJ4KsvpPQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=BOJDFXBD1m+mM1HPbQCCeH6xI3ewQg86bwm1SzKipzuy+DowRMHVH2ViSJP0zvwarNb47TfGSlucVPC2+BZRr4o4/sE6vtmHznhVTrnTC7LeLB9ins8T5KlJ0LH4sG/5CJHUWsvewvBSofmMp7nRwJVd+T4L3qE6iQopnGMHRp2uojVU9zi3LmFUK2+NFLpigRm6pkiI4Ov1nNMSBLkLiLpXDPJUheAS7W41o2ylnlb33SYbxkVM7TOQQKDeq7ymPxDT7CFxK0zq1anJf75Yj702ZGUp3Y00P+OD+J0IJtZD+TG02KxgPR4cq62/CRxk3i+Uz9pWeeQs8hA5vyKp5A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641886847; bh=bIpNAP8CLyRWFnS9SNHeFbzNS/5LAT0HViQHSywpsQu=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=iLmSLvlwyNJD4+JXTZww12Podk2L8J7fHbE6hraiBKG73sKPxPOWhtOd78ROykvVAUmdQ5dTwRwv8ZzoUsDMByhFLshvmM0Rg/rJKQHZNNJOnLBovB9hAOhLK24eWYdxMRqZBkMBmlQijqTnNv/wItDatDv0mLiuBvzcraQNC7Oe2UY6HnxgNlNx8597uXzdcBGRfgbSjyKVDlazmQ51bQMV26mCtXemneIpCSo353VgZ3jMzoHCuvLWV8XdlV4n5TGHnK8F1CM/IdfwJXOkLRp1zgGLWFKZ77cHdoZ+D4ca2NBxIvMAyzS76CfCoJCLMSiG87m2a4nYw9+ZxpSYhA== X-YMail-OSG: .cMCYHsVM1kHcw9LjR.g9t33Win1Y6HwxxVsJC_L9hEJaPxCn5eiDrI0x.0XQFl Eaa6tImmvQbRAXdgdIhIZojzI6YkLsA_HWE_Eww4bngMnsu1Dj2zYZUvib5KaTYWWseTxiLRvPlW K1EyPcFfx.p1_njOVQRnVhj2PX0tJvVQstCGsqeihZld7Q5SLEgRvRkxc8Bo0Nl0M94JMUuo1N17 hWoZgtCApOax3mfyeTOiuoLNK3qiKIY5SF1S56rLa05EaGH7b_TP1Ka978hh4l5UBpXLF8Rl4PmI rfBXLelNjcikL3nV0uB_ZSHTU6FocKJGXTj2yBOcpHw3g8Ul3xUlfeKzoa1M08Qr0XJLrysNww37 tBZror2u8Gzc9VUt2sdLol3LSuw4GSZfZlOTTnsyQbb.J2Ija3Cno.ZamI9CRY6Rf6IM4J8fCtX. IJqSaiJ3P6hisKB6xW4FdezU1bFU4FvKQieRGL1A5XSZhZuhFZOlx8L7omuo3gAA6bYDsGxsp5.t rCEv7ZR1u4F8WzCIizhRk6yV2UNSx5_WbdYmuD5u1gBnpcOZgA69E4FHToDjtopzTdKjSIpQQ8i8 jQUS8UntSn.woUR9KRnEgGXntBsyv64OaJZPCwNvUpLIWudROaRheDKOQtdJBrVlbdOMi80O3CZR ixmbEhApxX4KQJNhtjupeaY2.YwmcVX6Fs0ZIVZZ0gQJXQTyuo.XVaO1zzb23xAk06kaicYJ8TJ_ Q.8e7CNEhmt8aIzyzONkcPZ68T4JUd4JMkwW22EaoDssB3rkd6wc1CyrtOhMHBNqTafyyUXiMGK7 mdHPZIya3Rz0A2W1mfPLcXzlwzR1UH0_zWV6au4VYpmydgKpGkBNXF4DmXinbqEBNORDilG_Jpht x6aINWFNFvHU0FhVxUN96oCmTRh87ikI8D4K3u_LkvUpgYxvKhQMayX.j6ZEtWzmCXGU0mypOjUN p.Xy0i8QGckWsfN__gucPf8ho2u0bmO6ZB6RaS5eo_mTSe1TwIOEq8qcUdTITDdW8j71XeaFsFLJ jg7gKzBsb9MA1OBmFzqLReTZ97ypkVar4FnvKfB__s6jwHRxLELkxVSQt0YY8Nj.RzwMsqC7yEFz ilxr79huCGmGgJ1uuvuWsn0HsyFVclunTorysZJbc.41Ce7xvYKOF1xF4W5vjILLfNk4kudqSRYA U7TQaX.YcZUPNbkFBvvbih3moQriyPypSPr_oDlIMMBrcK91BJiLGuCDnIXNVQY0rZBRRDSy.Kwq S08AMhEvunjnZ046v2ydPvz75MJF6jwp.k3Pk4dzBqlWl1fupEmA..N5fDwAZtRsO5OQapF3PImY d0ZHlmFrKggHKagA1T6Meo8EjwB8mfF8lyU7Mj8s7uJf6YUqIjfsFMVrwd35JqA2tkUxlVQJc.ls 7DpDY5DnBw0Yutjzqw0D2aOqEseXBx9xUpa0BcuSsQLsMH2AOBJd2F4a09D3EBKHRBVGFP6il1M6 flg4vzaeiySeMu9SajCEBkCJyA6jyj3JhmJ7BrGz0ld0Sn13KGrXIR2W6VUEVrwyhFlR9LSmsxIm s16JW6ZpXDaFHsMsZB0jT3gGkc5tQY5I4TbgZLh.ktyDkP8N4aZ6MU5B7Us3SjAofbFVDnywOl4t bOnKjiQkh5DyIPQPmbZhBMIiZcg_eN9xayfyObO7TgIMHv5MUJvNGTpKRvtc8ESeUXUnFLATvfQT 08jQ.p0eh5LY_AHFqjHvaZyH51HXd7g2Md3XFK8Xjto_d3sDz.TE7erOl765eH5xLhakdbHE2BEw mc21nhff64Tm.IoNsi4OrilYvRI0gOcINQ3xLmi.ylIjSG3GCulfZHReT9c5n8b7o5.5bWWeGZvk VksDUyY.g2H4ruz3ytB6NSS0.dwUS_yOSK3vq9AwPcDjReQxf5VjQOHwSGy5sX8BuLW.FjT_ShJl Us94CPzIN5Zy437PP4BpPdLoRxactDeCfpLCkO3rB2omU.KQFPNuadbOdqrteA67Huosl3OZKNyI BoQdAoxRohiaAUcgvAaYUIONoRwRQ2HwHPc80Lru8560_6mhVkHkCL8E90tr7eklEZeX9fmiPEj0 isrtM5ndkc0sUiziCEaBd9hxH1SwuCYJtIPFL3B4BybztIEsAYrT5RcSiqigkTCD5hMBwEfsuwjA d8HZKYmDB09cRP3v5bnL.Y6o6mshJChOyJbTTQmgvrVCcuXTnHB6JqpL1uRCYSiJ_ECHpcLepX.v k7PbzodJknAupesa3PemR X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Jan 2022 07:40:47 +0000 Received: by kubenode513.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ab9ccbe1af594090753fde1c8f14d4d0; Tue, 11 Jan 2022 07:40:45 +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 14.0 \(3654.120.0.1.13\)) Subject: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c Message-Id: Date: Mon, 10 Jan 2022 23:40:43 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4JY2g46QSdz3pQD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=BOJDFXBD; 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 X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N # whatis dog /usr/main-src/lib/libc/stdlib/qsort.c:114:23: runtime error: applying = non-zero offset 48 to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdlib/qsort.c:114:23 in=20 /usr/main-src/lib/libc/stdlib/qsort.c:114:44: runtime error: applying = zero offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdlib/qsort.c:114:44 in=20 whatis: nothing appropriate This seems to be only for the not-found case. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Jan 11 13:19:09 2022 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 9A69F194A94E for ; Tue, 11 Jan 2022 13:19:12 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYB9X3nd5z3wDN; Tue, 11 Jan 2022 13:19:12 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641907152; 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=qo9li16gZabBwsMDAgkgNsy1aXVVJNjLP4S4LM/gm7A=; b=HXzub8uZQF8BN5F12WSYBFVyQSn0gqheA5+b+sI4VeYG+n+5Muq6XNWxnUMA08u59iaWR4 3OWJy9BNqxfu+MlzWHGpDibAbEVJADPcFi6awiX4xptIVts5X8YYEQ4PQ5mIv5MZKYKZeK Aqi4KHr7VUsmtBwY7xuBuLCFoWKiNxp/EOoBBI8GOnkF5rNcdC7EcEt6hpuVsBrIE7z8Lx rRsCpJeEM+eP+6PnD0vyvAUpg1UMqMByns2MpZOoPOpMiHFKKYLZ8x9wvETh7OmnfgoOca P+VOsdjHsu4vZ0tJ8G9jpeEFlBUErPcpV7SgpnZ4S3lx7xk19nLSzPwyzkM6hQ== Received: from [IPV6:2003:cd:5f26:900:c492:67dd:8868:a80d] (p200300cd5f260900c49267dd8868a80d.dip0.t-ipconnect.de [IPv6:2003:cd:5f26:900:c492:67dd:8868:a80d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id BA2F44EB3; Tue, 11 Jan 2022 13:19:11 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <35333abc-9d4a-4b78-586d-1e869df4f9d4@FreeBSD.org> Date: Tue, 11 Jan 2022 14:19:09 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c Content-Language: en-US To: bugs@openbsd.org References: From: Stefan Esser Cc: freebsd-current , Mark Millard , Baptiste Daroussin In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------q5tWnARR1ND0Yep0N8BIbkod" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641907152; 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=qo9li16gZabBwsMDAgkgNsy1aXVVJNjLP4S4LM/gm7A=; b=Ly024t5Jjkst/yXlRlsCM7+Z5bjCJjOfHkxBTAHHqcaa/JZog0u87Ml0xfL2+IGCMmtuuJ HrWKzK0Ww2Wc3R2Xj6+BRaNV1DXTVZaI8y42tu2JE/VtWfizbZq5QJCLRXzhyXPzY57EtP Enx+JJTowO+5IiDoE1ZqBS87elsjsDn0GOlKb8gyJGm3CEi6x8dNBlFs8Dn8B4kTIV1v3K TUryTckHFaLFILTyZFc6j3oPm1tzj8pup4CO8NRcZYCqpqIAyVm6PhxgXGifxLO/qABf0j dPiXX9JTarA/SRy01skq1qEP5dmwd4c8WCIS7/A0Rmv68qAyMVVS19as+LCghg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641907152; a=rsa-sha256; cv=none; b=xBvftAsobP+omiGgC6fxRkUTSQ3EQcS+D2iMCIrCHi/bLo5xxzZdEYD2hVHQqHC08UYBoi 23yd3HXh28kztYn9rRQe29NkxNmhJZubEegH8zxTM4nHJeWx38dm6f2KSLtKgCLSbVpDmT NA+s5rB8/2oMJR/xaqxSOyYRlNR9hNKuywX4OHp67DHgoojGxFORk/eWzlN0qxZv20HEGc auqRj8y2U7LM8Mbwk/RFKzqGdWb11bf5cRIyg+fIlPGBJLRRSCR/uBxuXznBlCKrPgSQUi R5Cge2G17d+u6CRafyUVmbfjfDnwq/SXjd50CdIIL64oGwXTpVOd2o+yTGAxQQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------q5tWnARR1ND0Yep0N8BIbkod Content-Type: multipart/mixed; boundary="------------SqilZx8IPkjIo3mGiQtryTRf"; protected-headers="v1" From: Stefan Esser To: bugs@openbsd.org Cc: freebsd-current , Mark Millard , Baptiste Daroussin Message-ID: <35333abc-9d4a-4b78-586d-1e869df4f9d4@FreeBSD.org> Subject: Re: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c References: In-Reply-To: --------------SqilZx8IPkjIo3mGiQtryTRf Content-Type: multipart/mixed; boundary="------------nLmWBUliSu8bWbhmESyLmdLR" --------------nLmWBUliSu8bWbhmESyLmdLR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 11.01.22 um 08:40 schrieb Mark Millard: > # whatis dog > /usr/main-src/lib/libc/stdlib/qsort.c:114:23: runtime error: applying n= on-zero offset 48 to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/main-src/l= ib/libc/stdlib/qsort.c:114:23 in=20 > /usr/main-src/lib/libc/stdlib/qsort.c:114:44: runtime error: applying z= ero offset to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/main-src/l= ib/libc/stdlib/qsort.c:114:44 in=20 > whatis: nothing appropriate >=20 > This seems to be only for the not-found case. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com The undefined behavior is caused by insufficient checking of parameters in mansearch.c. As part of the initializations performed at the start of mansearch(), the variables cur and *res are initialized to 0 resp. NULL: cur =3D maxres =3D 0;=09 if (res !=3D NULL) *res =3D NULL; If no match is found, these values are unchanged at line 223, where res is checked to be non-NULL, but then *res is passed to qsort() and that is still NULL. Suggested fix (also attached to avoid white-space issues): --- usr.bin/mandoc/mansearch.c +++ usr.bin/mandoc/mansearch.c @@ -220,7 +220,7 @@ if (cur && search->firstmatch) break; } - if (res !=3D NULL) + if (res !=3D NULL && *res !=3D NULL) qsort(*res, cur, sizeof(struct manpage), manpage_compare); if (chdir_status && getcwd_status && chdir(buf) =3D=3D -1) warn("%s", buf); (File name as in OpenBSD, it is contrib/mandoc/mansearch.c in FreeBSD.) Regards, STefan --------------nLmWBUliSu8bWbhmESyLmdLR Content-Type: text/plain; charset=UTF-8; name="mansearch.diff" Content-Disposition: attachment; filename="mansearch.diff" Content-Transfer-Encoding: base64 LS0tIHVzci5iaW4vbWFuZG9jL21hbnNlYXJjaC5jCisrKyB1c3IuYmluL21hbmRvYy9tYW5z ZWFyY2guYwpAQCAtMjIwLDcgKzIyMCw3IEBACiAJCWlmIChjdXIgJiYgc2VhcmNoLT5maXJz dG1hdGNoKQogCQkJYnJlYWs7CiAJfQotCWlmIChyZXMgIT0gTlVMTCkKKwlpZiAocmVzICE9 IE5VTEwgJiYgKnJlcyAhPSBOVUxMKQogCQlxc29ydCgqcmVzLCBjdXIsIHNpemVvZihzdHJ1 Y3QgbWFucGFnZSksIG1hbnBhZ2VfY29tcGFyZSk7CiAJaWYgKGNoZGlyX3N0YXR1cyAmJiBn ZXRjd2Rfc3RhdHVzICYmIGNoZGlyKGJ1ZikgPT0gLTEpCiAJCXdhcm4oIiVzIiwgYnVmKTsK --------------nLmWBUliSu8bWbhmESyLmdLR-- --------------SqilZx8IPkjIo3mGiQtryTRf-- --------------q5tWnARR1ND0Yep0N8BIbkod Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmHdg84FAwAAAAAACgkQR+u171r99UTm zwgAnGjlKp/YzckwmfBXchCt4K4uYbF9hOi12ldT7sQyGHdkjSNpLTkBF7j6Zl3S9Ar4x/nYkIhx petgux+7qOsp+oHfu7WrIIcuy8rF9+8iaF4LTTnC4pHOk7QY8limuf12z66+7mcj2WdqNbJh0inG 4l65wCvHvFLc2nsz772PRE+/dibKN78LnydR8JgRwt/+BAzOw67la6jckw0AQfmuCbjLsJgSSVVy ntTmLVT4f4aB0hVCX6Yqhioypes+PH2nlE93imob5OR9HL3fBSosINtxhZ7xFGzi2ywwxnvbxkE7 XnurIR4GOZ2pN8torsF97NJeMZoatEJMTrdQwOcd1Q== =iGen -----END PGP SIGNATURE----- --------------q5tWnARR1ND0Yep0N8BIbkod-- From nobody Tue Jan 11 20:08:23 2022 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 9357B194971C for ; Tue, 11 Jan 2022 20:08:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYMFt4YTxz4Tf8 for ; Tue, 11 Jan 2022 20:08:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641931706; bh=iefCQIlVpXR3sBVKYHhZgAgwF1Knmp5a77XFEUnKr0M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dr0VK0g2BFfZ9bP3KikMONF2nghOU0tczjWQkyKnp1ex9thFmS4I5hbVBQNTCg4CW20J//4QY9nORhT9ad8mdXlIrBPm0M1BmpEfGUgyp8skOYTG8Ylunef+iHg33L+KvJ1TDRbB7mYLglF422DgEd7TnyFR2VS/TC1CV6kEVIMWSTLJaXTOhOb0eEWgYc74VeiC7B4z0nGo8VFpVUG6qSASYjQtdKIgIXWwrqBr20n2xKCIM5GEjdvEXAQKxcYK9UW/1f4ceIvArt8p/hrRnahxvY5k1WT11pGMwbV/+gViZ80LiV6EM4ljucT6s9Zn4wZ04Px5IDesjo80MRjqkw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641931706; bh=FF1vnFaECHWtB3HrI7W2X9iestSXo3fIHD8H0IM5C+l=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=WM914OFrH3RcXIXGLwZLMDLLtx9i53jwPD1jZMVRHBpQL/1lGHA4sJbha98cX8mdS316Zp6srefUfW0ZtNOQ7N/2HmL1aYS5J/DsS8bvDv1bmnmve0b3EmQf+fF1NOuy7O6Yms6zFqE7rO3L6U4AvA5niL3eh5QakCj/oCj7MMaCvkZaGh9guu1LpRwUeYEoa0WjvkmWGZVf0/GLWeYiu09i8tK9BFBxQXrrRr6nKIx4cOTA/Qmd7GGmH0j8M9A4nc8DOTg+uH1TWQTi1JjZxwOqUw57WCgr6Xf6BYD/Qqmb3lZ2xpY5j1oZeDeOY36yIMESUqk4yfg9P54FrBOf5g== X-YMail-OSG: uM7QWZIVM1kEVaX3rFmjpe0Ij3MWl13dVnBK4A08ozr_xxcYQGxwkUtZeeNIzPH JU9D3GGrJ7totW9vUs.Xuowi7LGvQk7uyr23ClXjX7gtWd1pThE7fYGl5h3oSTh0XjuqZCjot9ho MPtLzGTPK3C3GZHPPC7vj5nKWaPjn28TQynszUSGBv2h02J_XBsz8FxZ.VWJOaNZnPEBtbq0i6rF vzLTrH98Cydd3OEm_24MWBXfWtrnQwRgcJYqUe3W4Mw2g_wSZrDQcrQVQUxAuaLiPg.TKlOBuDe5 TjAt8XadlsNH21rs_UTLGbBZilM10qSUDojDpK1T6SiCFRsUetWL2VO8BTag.Q4DkNWa.zHbPqnt a4rmsz8avcopj9v_LICnTuchBqevxAU01zu_uBusR1DQ.SvEKSV8yC6Qz0i_odsYne51yd3BUn0z 0noGIYgePU0yOseMVzDR.lIcVV_Q0.wk.DsLHQyWlcvBFmNE8dRtM95Fi7hcS7BgI0ndfwUQTjHU tdGg4Fet1PNwS8CzEBcNRTM4lGHiH6mv.VODrQRrhlL_mOMfv42NCZfczz_kNWtLgi7i_QRcULbc x7g6t6tginEf_b_LbmSz3QH5g_DBtUPHKDfHzJs1_PqHHIslNHE2tjE3BaYWVwZ6O8R8aCSi6Af2 D.cXUTW3I2k64nB0HDCOy8w7dU3Bn090F4LITbUwIMNrC6uwlpIcx1gYw7G3Yr8Tl7nMMiiC1Vsz WI.3hovqaMv5Shz8oHX8xcQWHmSL.Xhd2WgSzXE7okxHjdaJnqB7MkZYvDZqTY7btYiH7feSyELC UgnMlwcTWhsTwN048QI3OzxLg7KQhOCdh6M5XWCV1vAd3ZA5hDUolhZHI0aUBIxAp0ocmT1k3fyD jnPWNSmUkoK9fvsdAZSNq3xdPsrVzT1DDYIVdQgAPS2WoMtezryFlnOvV5SjG70zUj5bvX0b9fn5 GcdN4T5F3Pwfrb5DUxHwr3_zui7C8r8VlQFUPokEIz.CV0lcfmS2yAU2NdPznx_XbSBivs88lC6m eVkLxpVGCzzDKkAv2h6F1Z75M1j_lJ9P3CXX7YttOncGVxpJ2kLdPFWmKVcXaERQH.eMeCQgj6B_ 3_Mt0hUDQJP0Rugq1yghYaFE4vN0VScvlsj4dInxhm9gr703rRxAAJSsu6eYTZeimYB7fr2gAPkv 3_5PyGZZs_mt8TsAQX2VU5N9hk4pVatDHhNqAamdD_fQ5czHPKk1UsIrwqCPdiLv614xNGzBV24F 3GlHgyHaxscHRUru2vRvOEHYD0JfmYOhZ3PWpBQC20LUsaxj.UNkjpRQ0g7IwPlvE7AE5l4y50LI 5m5jqFuAHEktll6L1kdE4mufncNQUB1wpLcz.FLJvLSIR1aCBU6pqhsmKLG5ItwZwW52Rvjp9aQo zY7wd028Qooho8XBSR_8B8Qw9Gw8FxvPNn3bResOvjd941EmuHltdXQyfBuoDsXc0h.ePowz.Mlp sFCN3c2pmQzdttkQDxQ6gg7TX7k.2K7wFkcVlyJVt3xUuaTZ_mfSvwZbd1oA1Ux9uBpYQaWZwwy1 F.Yc1XXo4FdkZbQHb2yXeou1HMjKC3QYSlWcfRLN_UaYgi0y550PIvC3a4lmFZM5JV6AoWMWvaZE ZqFuz3o_yxo0XzO0cQCQ77gXe2EpfJ7pm7x7rkh0EhSO4ogPj7eDbId_3rTQrOBLW4F7yMyfQv0a kKbAVV0Ls46qufk_xUqlKKoKKyKUFX06kJYQIuBOUdkCIzdyAedgnQkEWv_Zfwt12OdEKDjgxmmF cOywgnoW8mQ2i3sQ6dTXSlsGl6uNnDWZXD0b..wEAtrrkAdnq4_nwIDU0M5LEU9Sx2gJ2lmhpi9z zqxMsijzgR2ASr9tRnLeNUcVGZV1t6G9C1aZLpmz0VmJpUu7912LTvqyfIthRmLFO8kqTOKXR0fV gc5LEqecJPfdypBhixx_AJFO0P4wau4X7Wj03to3bThlWfwrWNcxfeZrcinYknmclZldSywA2k86 cH_JRgdOwDM5IBJm3zPLfZLUJevIdxyKTPWJ545iyRzzB0AdGKKTzWDzOD9K0ainMgS5jNXnl1Hj .H1kmkA6Y2YiRMqxjO3k0E.7Adsgq4RjQCbjDx13yzeea3TuF97FCJk9_YbtV4a5JMFJb0_lsYEO .vWy7.mz_Qxt8vCng7iNn4cLZw4Vu.tKxBmjy1wp9LiJPiIBYozoIBM9AVW_ziWoytErj.bmQ5V6 eE_o_aUKfn497IGdgHSKO8Po159.4XDIn.ARPxw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Jan 2022 20:08:26 +0000 Received: by kubenode545.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID df06ee0d4ae9d73e04b5f50238e4455c; Tue, 11 Jan 2022 20:08:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c From: Mark Millard In-Reply-To: <35333abc-9d4a-4b78-586d-1e869df4f9d4@FreeBSD.org> Date: Tue, 11 Jan 2022 12:08:23 -0800 Cc: bugs@openbsd.org, freebsd-current , Baptiste Daroussin Content-Transfer-Encoding: quoted-printable Message-Id: References: <35333abc-9d4a-4b78-586d-1e869df4f9d4@FreeBSD.org> To: Stefan Esser X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JYMFt4YTxz4Tf8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-11, at 05:19, Stefan Esser wrote: > Am 11.01.22 um 08:40 schrieb Mark Millard: >> # whatis dog >> /usr/main-src/lib/libc/stdlib/qsort.c:114:23: runtime error: applying = non-zero offset 48 to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdlib/qsort.c:114:23 in=20 >> /usr/main-src/lib/libc/stdlib/qsort.c:114:44: runtime error: applying = zero offset to null pointer >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdlib/qsort.c:114:44 in=20 >> whatis: nothing appropriate >>=20 >> This seems to be only for the not-found case. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >=20 > The undefined behavior is caused by insufficient checking of = parameters > in mansearch.c. >=20 > As part of the initializations performed at the start of mansearch(), > the variables cur and *res are initialized to 0 resp. NULL: >=20 > cur =3D maxres =3D 0;=09 > if (res !=3D NULL) > *res =3D NULL; >=20 > If no match is found, these values are unchanged at line 223, where = res > is checked to be non-NULL, but then *res is passed to qsort() and that > is still NULL. >=20 > Suggested fix (also attached to avoid white-space issues): >=20 > --- usr.bin/mandoc/mansearch.c > +++ usr.bin/mandoc/mansearch.c > @@ -220,7 +220,7 @@ > if (cur && search->firstmatch) > break; > } > - if (res !=3D NULL) > + if (res !=3D NULL && *res !=3D NULL) > qsort(*res, cur, sizeof(struct manpage), = manpage_compare); > if (chdir_status && getcwd_status && chdir(buf) =3D=3D -1) > warn("%s", buf); >=20 > (File name as in OpenBSD, it is contrib/mandoc/mansearch.c in = FreeBSD.) Cool. Thanks. (But I'm not a committer so someone else will have to deal with doing an update to the file in git --and likely MFC'ing it.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Jan 11 21:08:50 2022 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 923731960F8D for ; Tue, 11 Jan 2022 21:08:56 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYNbX0193z3wRm; Tue, 11 Jan 2022 21:08:55 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641935336; 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=f/MTcg3mCWSOVWMubL+bDZTdMGQ5M4bw216FmMArpcY=; b=CpGYJi5MezieeBLuuIDJHq+MCmPEM8Ucy8koT7ZOZ9GJImeV51DzIJ4nudX9N5m1VXPjBo cJrCr/V/XuhOJzspkf4WQnJPAHJiw3bsuXCA35BFtrCPYeLgMg62LTHfkxstiUVqB5HSqW hvKhW8Gy4+Y+DaZ3GSaGWg8svb7uxP4lPOBUdgLhaOeEfQJBr3kNJaQN/jeCZp6bDNBSWo m28CGT8C5LhUyQ8YMF8K6Vrey3KASnnDX8yvTOVG6veJoCiZn5ddtrPVb6B7eHl/yLXCWQ lilb6sPHHkfymcXZD+ZaHjhqyUfu8eiGiUkuWUOSWYLgT7g2P0BpMGGgMf0GLg== Received: from [IPV6:2003:cd:5f26:900:c492:67dd:8868:a80d] (p200300cd5f260900c49267dd8868a80d.dip0.t-ipconnect.de [IPv6:2003:cd:5f26:900:c492:67dd:8868:a80d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id D13658C91; Tue, 11 Jan 2022 21:08:54 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <7babd754-6dab-223a-7bfd-ff06f10c71e2@FreeBSD.org> Date: Tue, 11 Jan 2022 22:08:50 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c Content-Language: en-US To: Mark Millard Cc: bugs@openbsd.org, freebsd-current , Baptiste Daroussin References: <35333abc-9d4a-4b78-586d-1e869df4f9d4@FreeBSD.org> From: Stefan Esser In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------so9aXA5pmnmGs0EZ0xCJDgxM" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641935336; 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=f/MTcg3mCWSOVWMubL+bDZTdMGQ5M4bw216FmMArpcY=; b=TBo4ph10iVIiqyPEb5T5203any3khggnmdwCJlfPajCv6rasCvXJhsksDeRArjQ9mtwlHG svaF5nVrG1qTgopSSeEIepofkrDML/KQvd154satVVEroLGz+FdFT6fFbXy+j4iFPPXAI+ ImYPzRwD1BCMRijyvTILGpHX/FPWaIsXkER6JubKLs8CCb6AiZ2LRyCn5nNtL4Xds01txn sOUehUPXlVZlGKYJFVtXbvOYpLc5+VaBVwns3q/BPdRxqqx0v8juCQuAyK/VHwZGIuljxj lE9PYlS3UVgErEunrKiXxSfJH032fgPrMJz2QKnjqntYhOwWGxDKbjWbZ8EULQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641935336; a=rsa-sha256; cv=none; b=FlgxjRvtS9LpKnps2LTXpxpKMJ+wD544YWPgcY5BqzG93oRdZie2ICnVmxMSMxNqgXcVp6 WYg2tsh2mJjasnQ8Xl/cIitjp+4T4btUYADKN1nM5hsWZhZC+AdSlN8/Et65ZjZR0/cwQv GsoMMqmReby8lsr77So24Al+r7XRxYMviIWqRLsJTpad0qn0S55kfgQTnBW9jltAWr5MOF JPeILe8GEYEO5k+/LRDb68kWefw6PVY1fMEXWhjs4vPNQynfeOLv7/nl2VNdfmPJ+rVW+R chM5uVyCAGseKtHojiP3TlPHosDD4LGf54QG4TeGSigrwCoLk2l0EMsWFvco+Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------so9aXA5pmnmGs0EZ0xCJDgxM Content-Type: multipart/mixed; boundary="------------3PXzrn6hY9M6pIwW3w6IdnxA"; protected-headers="v1" From: Stefan Esser To: Mark Millard Cc: bugs@openbsd.org, freebsd-current , Baptiste Daroussin Message-ID: <7babd754-6dab-223a-7bfd-ff06f10c71e2@FreeBSD.org> Subject: Re: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c References: <35333abc-9d4a-4b78-586d-1e869df4f9d4@FreeBSD.org> In-Reply-To: --------------3PXzrn6hY9M6pIwW3w6IdnxA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 11.01.22 um 21:08 schrieb Mark Millard: > On 2022-Jan-11, at 05:19, Stefan Esser wrote: [...] >> The undefined behavior is caused by insufficient checking of parameter= s >> in mansearch.c. >> >> As part of the initializations performed at the start of mansearch(), >> the variables cur and *res are initialized to 0 resp. NULL: >> >> cur =3D maxres =3D 0;=09 >> if (res !=3D NULL) >> *res =3D NULL; >> >> If no match is found, these values are unchanged at line 223, where re= s >> is checked to be non-NULL, but then *res is passed to qsort() and that= >> is still NULL. >> >> Suggested fix (also attached to avoid white-space issues): >> >> --- usr.bin/mandoc/mansearch.c >> +++ usr.bin/mandoc/mansearch.c >> @@ -220,7 +220,7 @@ >> if (cur && search->firstmatch) >> break; >> } >> - if (res !=3D NULL) >> + if (res !=3D NULL && *res !=3D NULL) >> qsort(*res, cur, sizeof(struct manpage), manpage_compare); >> if (chdir_status && getcwd_status && chdir(buf) =3D=3D -1) >> warn("%s", buf); >> >> (File name as in OpenBSD, it is contrib/mandoc/mansearch.c in FreeBSD.= ) >=20 > Cool. Thanks. >=20 > (But I'm not a committer so someone else > will have to deal with doing an update to > the file in git --and likely MFC'ing it.) >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 I have submitted a bug report to our upstream (OpenBSD), but the issue could also be fixed (or rather undefined behavior prevented) by a simple patch that makes qsort() detect the NULL pointer: diff --git a/lib/libc/stdlib/qsort.c b/lib/libc/stdlib/qsort.c index 5016fff7895f..51c41e802330 100644 --- a/lib/libc/stdlib/qsort.c +++ b/lib/libc/stdlib/qsort.c @@ -108,6 +108,8 @@ local_qsort(void *a, size_t n, size_t es, cmp_t *cmp,= void *thunk) int cmp_result; int swap_cnt; + if (__predict_false(a =3D=3D NULL)) + return; loop: swap_cnt =3D 0; if (n < 7) { This would also work to prevent the NULL pointer arithmetik for ports that might also path a =3D=3D NULL and n =3D=3D 0 in certain cases.= I'll apply this patch tomorrow, if there are no objections. Regards, STefan --------------3PXzrn6hY9M6pIwW3w6IdnxA-- --------------so9aXA5pmnmGs0EZ0xCJDgxM Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmHd8eIFAwAAAAAACgkQR+u171r99UQr ZAf+K0z2y4yiqFHAMP0tV/OBU7De/LL5J+Yjzx941LcPUBNt4T9mclLV9w6aIijP+mUJ7UG5qD+D ULyxRQcQ3qkDND/8oc0prceo0fzi8fmeK1Jq54+jwR4VX+siWzq3+hnKYV8YBmSbmAcrRpnd9YgT ZaCJvkPddKMXzQan/Ke2so2I4NFiOxLKDkm2jHu+idov9EsZOTUYkxvOHyGBPQ55CZ131PrkbMnE qnQjwHUg06S/SIJFxIAWmLOy9ctmsgizFA4hmysqZA+dZ1Zk22I9kxPxgCnM0RCpbFbHW6tD7iwk 6hiwZjCzR6L6ucoztK7+iaaec2AtR9JMZ48fTXg1NA== =P3g4 -----END PGP SIGNATURE----- --------------so9aXA5pmnmGs0EZ0xCJDgxM-- From nobody Wed Jan 12 07:50:19 2022 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 818BB195B9B6 for ; Wed, 12 Jan 2022 07:50:23 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYfqg2v05z4SrQ; Wed, 12 Jan 2022 07:50:23 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: by mail-lf1-x12b.google.com with SMTP id x22so5062334lfd.10; Tue, 11 Jan 2022 23:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=LncRzejS7Nq5niwS38Hs7Jka4BxnJe8bQ7LLOMPC+VU=; b=KZ/cNx71ZK8pZZDrt+RGq+dtQAyUiLtLgH5sE3rraAob17QVCLSOsqwGM0TV1waNvD SrFFA9VDKaRs5brc4phKlEWkVvniUz8xtke7FWKPZO3Lu56XDLH07S63RnG74/ALqnL2 bMNkhqtrhAqEjhFKYtiO/IBIb5C/PqvsUDNC5rVOumZDtVIzyfzZxUDOajTrTrsSsNns T6rwpaIl4HFMcuLC31lud3Ck4dePLNWSk6EvDtkhpyzetzxMdHV/YasJavbQVKmfRB6X IykpCwhpNwkOKE6d2m9bqUm8AEUdqvqBh7BS+/suvrQNOjPATi1VZCFc0hkWqjL4F8P4 SWow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=LncRzejS7Nq5niwS38Hs7Jka4BxnJe8bQ7LLOMPC+VU=; b=iRKw+nNyigFKPc/XYrcjMHdS+LrIEaNBc1coxJFqpocIyYc7TZ3LIGKNGI1i0ShA8i 5f8YVbxr1hNuZO85w1hri4ynYSadXlhAtAXRkl9XOhwZ3VokHSgKvBXTak67ymeeq1Sx Z4mDCjNA580gPmUelgiRp38HuadeKPHi9F5tH9rllLVChmPb0JQJTFajN7IQ/S8p+nAM i+Nz2E0JfIaPLP4QK9UIn1CCaz16IPNlR7VFVcOFszOyK0ZAl7dsH2fRr/K54fJegqiD sAFEWNMGPq4yXBpOh+pHefszmAqUm3HJCLdSxx9qn3q8KOxlEmXKvNYsxm4dBx1cIxhb UFBQ== X-Gm-Message-State: AOAM531jX1PcSdDmb++009ltpXud8b93aA8ipl12FArDchiI1rTAuB19 SsL1Ll68d5aFSHIgxoFfs2dObWaVixut+Q== X-Google-Smtp-Source: ABdhPJybTG2UVhePXgwED1h82z+WeoexYmfzkH9Tch+Oz5zC40vlCnutn+L4YB316W2PyM2SdR8FyQ== X-Received: by 2002:a05:6512:39cc:: with SMTP id k12mr6120773lfu.372.1641973822160; Tue, 11 Jan 2022 23:50:22 -0800 (PST) Received: from ?IPV6:2003:d2:1f18:8600::1d74? (p200300d21f1886000000000000001d74.dip0.t-ipconnect.de. [2003:d2:1f18:8600::1d74]) by smtp.googlemail.com with ESMTPSA id f18sm1563066lfj.56.2022.01.11.23.50.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Jan 2022 23:50:21 -0800 (PST) Message-ID: <80e1f514-c0b3-cf79-ea6f-8c62cb1db386@gmail.com> Date: Wed, 12 Jan 2022 08:50:19 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c Content-Language: en-US To: Stefan Esser , Mark Millard Cc: bugs@openbsd.org, freebsd-current , Baptiste Daroussin References: <35333abc-9d4a-4b78-586d-1e869df4f9d4@FreeBSD.org> <7babd754-6dab-223a-7bfd-ff06f10c71e2@FreeBSD.org> From: =?UTF-8?Q?Jan_Kokem=c3=bcller?= In-Reply-To: <7babd754-6dab-223a-7bfd-ff06f10c71e2@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JYfqg2v05z4SrQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11.01.22 22:08, Stefan Esser wrote: > diff --git a/lib/libc/stdlib/qsort.c b/lib/libc/stdlib/qsort.c > index 5016fff7895f..51c41e802330 100644 > --- a/lib/libc/stdlib/qsort.c > +++ b/lib/libc/stdlib/qsort.c > @@ -108,6 +108,8 @@ local_qsort(void *a, size_t n, size_t es, cmp_t *cmp, void > *thunk) > int cmp_result; > int swap_cnt; > > + if (__predict_false(a == NULL)) > + return; > loop: > swap_cnt = 0; > if (n < 7) { > > This would also work to prevent the NULL pointer arithmetik for > ports that might also path a == NULL and n == 0 in certain cases. The UB happens in this line, when "a == NULL" and "n == 0", right? for (pm = (char *)a + es; pm < (char *)a + n * es; pm += es) This is arithmetic on a pointer (the NULL pointer) which is not part of an array, which is UB. Then, wouldn't "if (__predict_false(n == 0))" be more appropriate than checking for "a == NULL" here? Testing for "a == NULL" might suppress UBSAN warnings of valid bugs, i.e. when "qsort" is called with "a == NULL" and "n != 0". In that case UBSAN _should_ trigger. UBSAN should not trigger when n == 0, though. At least, when "a" does point to a valid array. But what about the case of "a == NULL && n == 0"? Is that deemed UB? It looks like at least FreeBSD's "qsort_s" implementation says it's legal. a != NULL (pointing to valid array), n != 0 -> "normal" case, no UB a != NULL (pointing to valid array), n == 0 -> should not trigger UB, and doesn't in the current implementation a == NULL, n == 0 -> should not trigger UB? (debatable) So if "a == NULL && n == 0" was deemed legal, then there would be no bug in "mansearch.c", right? -Jan From nobody Wed Jan 12 09:54:19 2022 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 BAA50195AFD6 for ; Wed, 12 Jan 2022 09:54:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYjZw1vXjz4pFY for ; Wed, 12 Jan 2022 09:54:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641981265; bh=tlTpg4vDaUagqu8PE1ROjZGPrbauWy9COXfDWVw8f6U=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=HYOvUUHw8panw5M1xEvsILslwmSLzCxvMeBf4uRlzrwxYxtvP8Fht3ylSrxmzwdN9Yn2yt75fa9xriFQqlWSmdN9iw7lFMHNMIqVlGKnMZakz7gRhBQnfhS7UnFddOoRq+/nST9ZQreV/dbYxdKf9I3R4QZ2GCQ0Cjei7llJrXk/mIPwK5vw9gHucsWNs7FLTcu9QjkrSh/LNTsnyUDM0UBqKCvzDcJE4mCywxD67QLl6xSgUnQQZ7Mmv+T2UKIF9Yy0Ywh7RBqBy2aMNAL8gn6qdeYx2hDmz1WEKoAxAOfOWJqI6WsDZl2rtou5F0t+mJcIhVqnKo5TgmqrYeg/fA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641981265; bh=znCjRjN6ef02+E3H8HSdMl2ips+Jp+qcGf+ubzv5T45=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NkCwYxag6O1ppFd1Z12DF4OXsHj/fmhxzlx8oPDA/KqujWCPrl5u+eqDkkuv5HOe6A7rH0yWDy+S2ViYtI4x6t8KLUUD8i9S88yLNWH9+33GrwJY/T9EYxqBXMN6BTozu3n78zNbh1++I/XcUMKZcNhrDx5GhHA1ti9ze7NwZRrNaGO8q3XtsJgdwp5I1zTKEnGmVN5YgJIKs5MZh8yNjTi0cqzOAxdtw+N0f6sGST0cFoDha6Mt0lmXQ2H+Y251/tMSqQWVyBkguMJAJ+vVv0cpmQGBuxm6CEkGbyWGZnP0WDvgcUQxgB9q4xZwrrt4wW1GHhn8OQ6uV+VmDXN66w== X-YMail-OSG: ACXp_PYVM1l_4oKWLM3XhkoQ1UDUpvNQ3H_IoIe8mwLOVBMLiD2uXj8_VdMEtxX FSI7_yzobS2fzxSseLY_N3a05M_d0q4YFWgpDFyj4ny5sSP.FyIVbUksxlrpaJdOPihnopUtYU98 RaAbK5UtijY4tx_gwOq9Cs.b8kVlYewkMMcU3qrhpS8zjSZMZJtXSFWtjUnz0M4R1zY6vuKTibli juV6sqvE.3Y7rHrGgwFjV2fuOAIsEOn8gkLy8Ad_EX4qicaZnbLSAR468egCIBbiqzcculLQU8fC WHWPMBYR1Tly3Jt9zUR2mkjJ7EnDZJ3H_TdoMwVEzlw9AtfbIXifB8GiJKuhbUzyhdr7WqQx5m89 VKCW6I0XJGWzNCi5VpDyVSvJf47OEbNHyLTx.5p6LJpphg71nYKjNVhRLPEjKX.PjsBrNOoZnuf. bSUwZwMB6vML_DGaWF1k75RnH2.5FBGSc7624mNkDAzK4B2Z4EnR7U0YBv89EXkuMHKJ7PZCzcu4 6RRFZ8TsCfKht1MdmX40jvpyAMDkqJrCIF9aja7H4xG25PxqEWC1hMGsjHHf9XfpGDL4dSfbuw0o a0.VQahOy0Fy5pbaov57LW4QHHhsxFmaF1.bCXEsJa3kGDH9hDQKVqQBBQYyCd2eCfIJqjs1qigR WaAWlZExbYslMfKjeTVaj_6MvCbDXwgUMbsvpB0LaTp6pAwn2keYBpxI02bB4Rpau6ShtEdwgY_G 9Y_GUvHhlu7oaskAhzC6Ro6oYpG6yRoKpOPlUgOpiqPsYWhkytvlw_y0qLqAZhF2RzKZREWO8blK 7EfjQWVPMsTVGNq3vhq79I_0B_LvaPBtwPkBeW3gGg7Ab8XyLCOL4MCBpZU3KBgjy2nDw5n2.3rq ix6BhjJiBXpB9XP1tW5Ngc2z_fCG7Y7PKz9SPWSJsdbTrCpS9SHjftBhrcSF7I2y6jz1oE9IRYi1 dW95LjHPO.f6IpPB.A4jdB3ZvMCsWDiVfbq0.0egUrgy5eHmdaUyCvySQw_to56oUgD38S1Aqxit PjjwEakZkRVXgBObS4DdzpGLBCgf.Y88u0MVaL9RcdzfhFdEdKzU2cmmN1gLbjeryv61TAHdSdBW gSWqm6nY9STVZF45VQFRy8a907Akmfrq0KvEOQfnF7q14_LeqplrI92vRrJtML.tMFuL2BFmbg5h dIQx0.Ws4zxDncoa_QPCgK8ftHXpcSDfDA8n2lol25jKjLQfRDvb17YVM5kAx6kkhyjEUu2jffRw qgnHQiXW.X6TE6uDQcFD1v3Fgl4PShoTRnltr2AjK3j.RwDADqZI50vPEiuJiPznYd85gGKsfpJk yRPcECm82_pjBacoNqbWN_oFEq0YcUOOB_AFP3GCs4fntduDiJ23jmJsR3vQArCEkUyFTQJwUm47 1nDpSPNqexvd7KObsHfLZFOYFWGZsVLEnwRFmHXBaE_G5RjMbXr226kOACEvnjGax2pdCI1YFKWz y7bTs4S4jLmD7vBo8b9mpQN3cHYlcW0uwsPYDS7k9oTBVXThlT4.zaUlufsp0nwUV203NpaQoBlg E8KiB4J3r8qKkwYBtk34ErZOasG.3IHZ7_QE77C90fdrirojWIye6YB8u0BH4kYAmFyC.0OdlEWG USB2qevVakXMQR8smr8d7Gg_9rUyzrZYsHwHCQw87aQUjzP5W4cedMBHR.HT9opgdRqzx_2QPS3E hWpy9KSh13ZfyY.Mfstn52SmLBoqrcc8k_NqSthFRk3Gax.RpbZXoSGnZY1RqelLb2rkRmv7v9gi lqVNC7GWfilPMRw43XnmILm4KTBMF1vBW9Lo2BZH8lTQmC9FE9wrDSqKgFaQwzF3qRuQN.NyG049 f9nNzLScZ6YoC2YZj2iBsr_MS5SPx6KX9hKso7X1BZ6k50zrkR7Lsse.F8UyE.rbrJbOhHjsseyd sveF1y2HMTXq.01y.g8luAaIO978ABVfp1a4oe5NZ0eBpCWqyEjVkS_YTBxfzTV88lBhDKoBBWga LcvXB8jxSoQgIVsMf2RlKuZMUjDyyQz2eYoE8IMLV6VXR1aVMYa1DYUpHfLO1gxDYrTTsZ.t1bIV FivDa6ODiN2UeolHi7oA9EElC5HGmjXxcnc7n5OJJ16vLkPmjf6WrTjMgf.9zHe4TkGHHu_Cm4zw GJveRWgYSsE5PjgMlJNxRCsr6kw7zoc2BLyFRLDJ39ZoUEXJxWq9g_IJxnwIMCKLQQYkoTAUKu5f lhHjFN_HnyrYX4UgqfMNuGAC6 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 12 Jan 2022 09:54:25 +0000 Received: by kubenode541.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f87a5c91c0a5c4c862253e642bba6b67; Wed, 12 Jan 2022 09:54:21 +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 14.0 \(3654.120.0.1.13\)) Subject: kyua run under WITH_ASAN= built world reports a global-buffer-overflow during cpio test. Message-Id: <313A3FD8-1E8C-46C2-A400-E0A647F09464@yahoo.com> Date: Wed, 12 Jan 2022 01:54:19 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <313A3FD8-1E8C-46C2-A400-E0A647F09464.ref@yahoo.com> X-Rspamd-Queue-Id: 4JYjZw1vXjz4pFY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=HYOvUUHw; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.18 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.84)[-0.844]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.84)[-0.841]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from] X-ThisMailContainsUnwantedMimeParts: N For the below it appears that the report from UBSAN is accurate. =3D=3D85511=3D=3DERROR: AddressSanitizer: global-buffer-overflow on = address 0x0000010753ca at pc 0x000001139bda bp 0x7fffffffc2b0 sp = 0x7fffffffc2a8 READ of size 1 at 0x0000010753ca thread T0 #0 0x1139bd9 in hexdump = /usr/main-src/contrib/libarchive/test_utils/test_main.c:875:35 #1 0x113b73c in assertion_text_file_contents = /usr/main-src/contrib/libarchive/test_utils/test_main.c:1182:3 #2 0x1125d46 in basic_cpio = /usr/main-src/contrib/libarchive/cpio/test/test_basic.c:84:2 #3 0x11259dc in test_basic = /usr/main-src/contrib/libarchive/cpio/test/test_basic.c:229:2 #4 0x1144943 in test_run = /usr/main-src/contrib/libarchive/test_utils/test_main.c:3561:2 #5 0x1144943 in main = /usr/main-src/contrib/libarchive/test_utils/test_main.c:4062:9 0x0000010753ca is located 54 bytes to the left of global variable = '' defined in = '/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:229:13' = (0x1075400) of size 5 '' is ascii string 'copy' 0x0000010753ca is located 22 bytes to the left of global variable = '' defined in = '/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:228:38' = (0x10753e0) of size 9 '' is ascii string '1 block ' 0x0000010753ca is located 0 bytes to the right of global variable = '' defined in = '/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:220:18' = (0x10753c0) of size 10 '' is ascii string '2 blocks ' SUMMARY: AddressSanitizer: global-buffer-overflow = /usr/main-src/contrib/libarchive/test_utils/test_main.c:875:35 in = hexdump Shadow bytes around the buggy address: 0x40000020ea20: f9 f9 f9 f9 02 f9 f9 f9 00 01 f9 f9 00 02 f9 f9 0x40000020ea30: 00 00 00 00 00 00 02 f9 f9 f9 f9 f9 00 f9 f9 f9 0x40000020ea40: 00 01 f9 f9 00 00 00 00 00 00 01 f9 f9 f9 f9 f9 0x40000020ea50: 06 f9 f9 f9 07 f9 f9 f9 00 00 00 00 00 07 f9 f9 0x40000020ea60: f9 f9 f9 f9 04 f9 f9 f9 05 f9 f9 f9 00 00 00 00 =3D>0x40000020ea70: 00 05 f9 f9 f9 f9 f9 f9 00[02]f9 f9 00 01 f9 f9 0x40000020ea80: 05 f9 f9 f9 01 f9 f9 f9 00 01 f9 f9 00 05 f9 f9 0x40000020ea90: 00 02 f9 f9 00 f9 f9 f9 00 02 f9 f9 07 f9 f9 f9 0x40000020eaa0: 00 01 f9 f9 07 f9 f9 f9 00 02 f9 f9 00 02 f9 f9 0x40000020eab0: 00 03 f9 f9 00 01 f9 f9 00 04 f9 f9 00 00 00 00 0x40000020eac0: 00 00 00 03 f9 f9 f9 f9 00 00 00 f9 f9 f9 f9 f9 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D85511=3D=3DABORTING Well, contrib/libarchive/cpio/test/test_basic.c:84 is doing: assertTextFileContents(se, "pack.err"); which involves, in turn: int assertion_text_file_contents(const char *filename, int line, const char = *buff, const char *fn) { . . . s =3D (int)strlen(buff); contents =3D malloc(s * 2 + 128); n =3D (int)fread(contents, 1, s * 2 + 128 - 1, f); . . . if (n > 0) { hexdump(contents, buff, n, 0); . . . Nothing about the code seems to constrain n to fit the size of the space for "pack.err" (9 bytes of "global" space). The report is for the ref[i + j] in the code: static void hexdump(const char *p, const char *ref, size_t l, size_t offset) { . . . for (j =3D 0; j < 16 && i + j < l; j++) { if (ref !=3D NULL && p[i + j] !=3D ref[i + j]) . . . where ref points to the space for "pack.err" and l was given a copy of the value of n in the previously shown code. The i + j < l constraint need not avoid the code doing ref[i + j] in a way that reaches outside the space for "pack.err" --because of the supplied value of n (a.k.a. l) not being sufficient to respect the space for "pack.err". =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 12 11:00:31 2022 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 B867A19455F6 for ; Wed, 12 Jan 2022 11:00:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYl3H3G56z3JKt for ; Wed, 12 Jan 2022 11:00:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641985236; bh=vwZmtfS6+3f0Mcdr/wJxOqF7LidKpFYzTrK0WHHTgk8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=phWD23+sEp9tF2HRk7F52K66s2Lxd06GzTBHPXQBqX2iF0ULa3akk+mqeHSFcrIMU4ZWn8y0R/0+8DBDB/PjLZE7GMhJhJU3wJN6S28fArull/BpknJUItaETWojuwzWYeTN1ijsP+o9N8nFQ+XVlIG5T27Xvrlg2pS1eSekUtYolmnQUvcW8IofrgNRmrh00gkhFT0ywsw5VqYDAVQg5d0vpcTkiqPLMnHOVQrIu0KZGgrP6tO5MtWCHQH8QphqSc9Oo4w9dasuDCaOrq6ud2eARfVa+WS3DGWPHut5kIli34vlkFfO6M//LdWKvX8q0zSRYWnn0PsJtJxDkBufvA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641985236; bh=OqxVRVssr46gOGEeNxN1o0TcP+I+xoxxdEoYg0rwpMy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EHH9K91D2JQDMsmC3d4OVb6Agno9q+t3jcdszDQnp9R+Uf6ju03TwhjbcW0zzvCwsl4en4xaOgjVG9G9rErMwBRxTM818PQYP15CMJHpTT/hle8c18YDra1T7GtVLXLMc0CJPWXDS3WrpeS3t3vmoh0HSWrkzY+y4TSKwViXQnV9GIJSZ88UXg4bEHxoEYpkw5qxgO63jG8doAYC7hHQMTM0SJKjLao/bWMQ9tCazAjsKNWG1DYoS8qSJh+Xv12llYHHMvam3yFjxqyCmGmxux8wV2LF74lvvRxe7hNXvkhsm139XN8g4E3GX62CqNv75tBQMDZh4CfcdBcvlAvgcg== X-YMail-OSG: cN1v62kVM1nUPccfPPX2L283hH65GeAeRTOE1j9llndFjZmiYn0LbDchs3js6QI 29uUJDYz7azBMYnwtvLtvKbF1BDsoIyPsP33tIR4bL8VV0UDGJ.jne7WKXs.RBDShDb81JRSGBKp Nz1bA2r3cnSUBP3EgsfBmqlv2zWZWoOxhFkNRyBpRrAgDIQ63N0Ac5ZlUGCERHA.a2SpL08V9G33 whebvVK_JlZF4MeH.ps8WW_x5AEcuQ0FVm_XSv_aD5BdQS2817nU1tUJ0fHVCmi6aCfGa2paheJi bRBOpXYVV6c81gqVBgMws0WYEZXrQukdXp73_f1bbGk.oh1y3.VWR4.bhBwuaey1DjHLGvQuI9ru XfiWq2ImfDE7FmF5fxb9f8jm8kqydq8GvpRmDjczLfdRBDrICy6kByOhsqMLUlKoTzlgve1xp0gU bEIjvSjBlsibhCTjWzWxYD16uJIGwN_b6I2PfnlJVMtYBov0pPeyZyOInfskaH.oRjiPOkwlhTO5 kkJnJv66CXZSkBJir_4y5AjHQYAmV1RIbfld7OMZ_FLRiPBr8qYwzVUjh7jW2GkKEs2ZKVHaWmjT 3_ZDvuCxdkiXMmTwFjDwm6c9joB3krqsw2Ceh34AnSrQ5im9TBZlAaZIh51aYA42WHP26hfcOoyK 7VTUynTip1QDQ9Dixy.ODCj.tjfnZolSJHaUhR_lb4rtiIXhkdD0Rdq2_q9RrrWRqK0KmxkvBsWi WV94WZBqiMGUvg8I2zu9maPzo9cvrow6Suon7n.D6kFZ3t1KM0cK_b2M_Fm6GJX6biw3JbkCCKuh 2.vQPBKeA39GfR4UU.y.2wH3VfGBsL24m0BfZPBl6zbKW4wrthPQuQIRMFjYH.ENmtF4exQoTKPf _1LeP5MXVIJkLsZLOEoeUcZ5HaWx30_Jkx_6ihMGiZ2iyVoL89kSwnZOM2a_lAjIdMr2RIqkiui_ 8JvEfNiLkLS3NwpDsFcIhbXV7.LKy0AmGUH53Kl_VVbjFQ1FX4T5VS_GQbDh8MqzC8WoFx49NBQA G3BZfHjqunDfo.HemoBGSUWhg9xFsfpslJgqrL2F0o0mxnUwnWoJ8.qBgSo9QCi85CQ.X30YJr8P bdXCZPH4rIueibzOpyy_4yxHW5lCe1udTzFgrPqYhuIs4XPqMB5.EVHmuxuO3hs52N145tsxcBeN N6VgcZ4DCTox_yqgif8uK3z70xpDl31WnTkbt74wLcFXy_YHKEmwOaloFaVgrDSbhS8htqSdUopb rDQnTtoU8RLybUkb4mzdDbZXD4QpkdgfWwDdT5VKQGZ0hOWsuJO2YvWrPcxX14NPbzM9Tk1peB6Z PwtnWjXskEiOq8mUGhS42G35JzRi2.2hS.8ebFJS9mnak_UA3c0HUf7HVsBBJce0f7o07h5jYrWU 75xIGAgJ5sSzrEVu2hgjABllOW4KmeTj4TNMLdlKXFYzubImTlPrSMT36MX3cJ0UhIC6juPyKsc3 UIiu5fijBScgzRWI7t9lU3jg3WKySdv.eSq2_pf2w9XXqVqtUD0wTQ6aCneP1Nyro3MacWWTNEHk F8SmgLjlzGZ8cfYXpXeEOVFkGfNoQ9Xexceuf4Kziu0NQl1ExsvCTxMJGRdkzylmUmT2V4MVIQLK 7sLjAy1pGnSnpGEIQ7pr3fbuO7SN3.Pdg6PuMA_ya_tH.7Qu3DkGefPAfNXJOXjRvscHLA6WqjHZ 4fHvrY9uX7lNJuVB1woDmKGAlrUQO_gpEC9SxN5tNfDD3Dg69CxFzRW4ZnmVS.MHtUxMp5cywetL V1q6WqKamtpgj0McTkyJyn9Nt_vvFkZWvuLkF0qjgY8ugNjOAtInundW1BTz91iJQR.j6EfOV4EL 9q8f1vfI8vOtiA78Pbs8cI0ZFLoQcjkYrmw8PuKOQNddc7sqrFxoJfK132H5YXhH8M557MiGfYgG 01Y84ktZPM9_dQyj7HGs.qawATr8dlXmAO4q4R3myVPMqH21KMdo4ZpteSIwO8dme1oCXkH1LoF0 tAvJsQNjo6YhCaXgqKMxeI9TC51mTEQHPeM1_kT.x4_N71j5.l1sIMSYeziYLcS9uizRNST_fIDQ 57oZrvX2tdIiu.Zjk6Zfui7lg7pd8ZAjKsMXXfSAlkbe902Ds4I4gm7yil7vmB5runDvSUx8R05J UpGVGQd0Ji8TRRBU7e9RErwkej4mJwHXEgkaF8Ln16EmwGvj3WOZxfz0_zKXVL_ip6uSbjIjt4ln .4xBdbnMFrm4afeQa9tChkjH14CaLFXrNvc5Da4zHVGZrTOzlqEq4YbLDt7cB6ZSyrj1mecDITgd dPy6jOZATVV5n X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 12 Jan 2022 11:00:36 +0000 Received: by kubenode536.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6469636441df0579e5b17c462604880f; Wed, 12 Jan 2022 11:00:32 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c From: Mark Millard In-Reply-To: <80e1f514-c0b3-cf79-ea6f-8c62cb1db386@gmail.com> Date: Wed, 12 Jan 2022 03:00:31 -0800 Cc: Stefan Esser , bugs@openbsd.org, freebsd-current , Baptiste Daroussin Content-Transfer-Encoding: quoted-printable Message-Id: <58A5D64F-1157-410B-90A2-3F5F0D31980D@yahoo.com> References: <35333abc-9d4a-4b78-586d-1e869df4f9d4@FreeBSD.org> <7babd754-6dab-223a-7bfd-ff06f10c71e2@FreeBSD.org> <80e1f514-c0b3-cf79-ea6f-8c62cb1db386@gmail.com> To: =?utf-8?Q?Jan_Kokem=C3=BCller?= X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JYl3H3G56z3JKt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-11, at 23:50, Jan Kokem=C3=BCller = wrote: > On 11.01.22 22:08, Stefan Esser wrote: >> diff --git a/lib/libc/stdlib/qsort.c b/lib/libc/stdlib/qsort.c >> index 5016fff7895f..51c41e802330 100644 >> --- a/lib/libc/stdlib/qsort.c >> +++ b/lib/libc/stdlib/qsort.c >> @@ -108,6 +108,8 @@ local_qsort(void *a, size_t n, size_t es, cmp_t = *cmp, void >> *thunk) >> int cmp_result; >> int swap_cnt; >>=20 >> + if (__predict_false(a =3D=3D NULL)) >> + return; >> loop: >> swap_cnt =3D 0; >> if (n < 7) { >>=20 >> This would also work to prevent the NULL pointer arithmetik for >> ports that might also path a =3D=3D NULL and n =3D=3D 0 in certain = cases. >=20 > The UB happens in this line, when "a =3D=3D NULL" and "n =3D=3D 0", = right? >=20 > for (pm =3D (char *)a + es; pm < (char *)a + n * es; pm +=3D es) >=20 > This is arithmetic on a pointer (the NULL pointer) which is not part = of an > array, which is UB. >=20 > Then, wouldn't "if (__predict_false(n =3D=3D 0))" be more appropriate = than checking > for "a =3D=3D NULL" here? Testing for "a =3D=3D NULL" might suppress = UBSAN warnings of > valid bugs, i.e. when "qsort" is called with "a =3D=3D NULL" and "n !=3D= 0". In that > case UBSAN _should_ trigger. >=20 > UBSAN should not trigger when n =3D=3D 0, though. At least, when "a" = does point to > a valid array. But what about the case of "a =3D=3D NULL && n =3D=3D = 0"? Is that deemed > UB? It looks like at least FreeBSD's "qsort_s" implementation says = it's legal. >=20 > a !=3D NULL (pointing to valid array), n !=3D 0 -> "normal" case, no = UB > a !=3D NULL (pointing to valid array), n =3D=3D 0 -> should not = trigger UB, and > doesn't in the current > implementation > a =3D=3D NULL, n =3D=3D 0 -> should not = trigger UB? > (debatable) >=20 > So if "a =3D=3D NULL && n =3D=3D 0" was deemed legal, then there would = be no bug in > "mansearch.c", right? >=20 ISO/IEC 9899:2011 (E) is not explicit about such things for qsort, nor is POSIX as I remember: POSIX states that in cases of disagreement it defers to a C standard, if I remember right. But ISO/IEC 9899:2011 (E) is somewhat explicit for qsort_s: (parameters: base, nmemb, size, and compar in that order) QUOTE If nmemb is not equal to zero, then nether base nor compar shall be a null pointer. END QUOTE But there are no words about nmemb=3D=3D0 relative to either of: base vs. NULL compar vs. NULL So far as I can tell, the implementation is free to treat nmemb=3D=3D0 && (base=3D=3DNULL||compar=3D=3DNULL) as a = "runtime-constraint violation" for qsort_s and to return a non-zero value --or to not do so and return zero. As qsort does not return a value, any rejection of such a combination for qsort would be in a more drastic form, making such an unlikely choice. (qsort is not documented to assign errno either.) So I would expect qsort to avoid involving undefined behavior when nmemb=3D=3D0 && (base=3D=3DNULL||compar=3D=3DNULL) but to not = reject the condition. I do not take doing a well-defined "no-op" as a rejection for my wording here. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 12 12:44:44 2022 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 D5F831941FAC for ; Wed, 12 Jan 2022 12:44:49 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYnMP20Dfz3tvd; Wed, 12 Jan 2022 12:44:49 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641991489; 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=iAqFWz5ktVQQ2yY0/MEcBgP/KqBt2VokzNtoQNq07Hk=; b=nBUDoRk2Gtg8OL84rDp2IX+1BTOknbXQNSd7aFr1d8bKi+t8CS/tbhVDnMcKx87ClRSnDP crUVeZIsAzg22scsOYodch64RJtU2BRK/xv70NNp/G6QHAV2YOW852MDxLU9578WrcMGNJ w9fItbIqrVGeSU6c5Q52YdANHXVQCmRXlBaduvytEQpqa3u2IyB/gCCpJu5xOfUxGBwQSG dUJ32r0u6nLBe/YR1d8LjlIGuoAhGYRV6oIO5cEFQ9goscL8MpSShEN3EYbIrfedEvSqTQ LtjETh8OH0iBnlSqh6NLAkavzCdIsr1hEA3lDY5aWx7M2jjQ9mU00V45QSgzkA== Received: from [IPV6:2003:cd:5f26:900:d9d2:5b4c:aa73:bc5b] (p200300cd5f260900d9d25b4caa73bc5b.dip0.t-ipconnect.de [IPv6:2003:cd:5f26:900:d9d2:5b4c:aa73:bc5b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 0DEC5200DB; Wed, 12 Jan 2022 12:44:47 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: Date: Wed, 12 Jan 2022 13:44:44 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c Content-Language: en-US To: =?UTF-8?Q?Jan_Kokem=c3=bcller?= , Mark Millard Cc: bugs@openbsd.org, freebsd-current , Baptiste Daroussin References: <35333abc-9d4a-4b78-586d-1e869df4f9d4@FreeBSD.org> <7babd754-6dab-223a-7bfd-ff06f10c71e2@FreeBSD.org> <80e1f514-c0b3-cf79-ea6f-8c62cb1db386@gmail.com> From: Stefan Esser In-Reply-To: <80e1f514-c0b3-cf79-ea6f-8c62cb1db386@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------bRIpNhbcXHLAE6JIYyS9A76J" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641991489; 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=iAqFWz5ktVQQ2yY0/MEcBgP/KqBt2VokzNtoQNq07Hk=; b=ukbhCXUwk9I/m4Lhr8KKGe7wn3DdYhtxKTGJ2l5nERa/YQhC99XoGVbNEyWdNsSyCY2EgZ 7CIqYVInZaDqHiGKR4n2z0d1TGYrr5Dsx0Y/5dqVu+w+bMrgOqN+zQX+v9eQnNK+itFKG4 qFTc5qqN0DpEMAJ0hKSCBl2XPaMGHVf1NVdBmSJRyohakEc/aCtmfKCvgCjys3J5KN6KDt E1pNvVGyw9V3+kAKAeAVA0/sLbIwhfnrUlTbBsisJHgZcJ7poM5eWbXXoeKVewHjuNkpiw 0i5zc/xKTe931RfnAWb0PatmDBOX/udrglrOUIhftY3kYggMGmhwe+rzdQZ5Og== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641991489; a=rsa-sha256; cv=none; b=NLoKPBolOLSSFysHa7pUkpuVq9E1MU5/iP46SDRYYKsPw8iP/QO2oemIk98SsYA6sWlb92 ITO6BeIsnanBo2osm4aR2tRD5jJL3TGtHnMDrISW/i+FUJjnnzO5w8Q28lCmP5eS2uNXu3 83f+nzcxIbg3WiOj3sdCi+Bbf8DujUAu48ttmsTXKrvE0AmPMxjDMoWCwBoWkW21Stc2Wo 6NnPON9vyMPxHn6GoAfSW9IsveQGvuQmqbbCAogbY4Rsd3/VU5TSLIyms8jLInINHzJPPs jtK7jaViUKdFLwZL/LMIbaJUkvrNiRHxTuTak7OZgxD65I9KYwKTGpNSvq7JPw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------bRIpNhbcXHLAE6JIYyS9A76J Content-Type: multipart/mixed; boundary="------------sWzOcjTR2UPOZjVfWKWfqCl2"; protected-headers="v1" From: Stefan Esser To: =?UTF-8?Q?Jan_Kokem=c3=bcller?= , Mark Millard Cc: bugs@openbsd.org, freebsd-current , Baptiste Daroussin Message-ID: Subject: Re: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c References: <35333abc-9d4a-4b78-586d-1e869df4f9d4@FreeBSD.org> <7babd754-6dab-223a-7bfd-ff06f10c71e2@FreeBSD.org> <80e1f514-c0b3-cf79-ea6f-8c62cb1db386@gmail.com> In-Reply-To: <80e1f514-c0b3-cf79-ea6f-8c62cb1db386@gmail.com> --------------sWzOcjTR2UPOZjVfWKWfqCl2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 12.01.22 um 08:50 schrieb Jan Kokem=C3=BCller: > On 11.01.22 22:08, Stefan Esser wrote: >> diff --git a/lib/libc/stdlib/qsort.c b/lib/libc/stdlib/qsort.c >> index 5016fff7895f..51c41e802330 100644 >> --- a/lib/libc/stdlib/qsort.c >> +++ b/lib/libc/stdlib/qsort.c >> @@ -108,6 +108,8 @@ local_qsort(void *a, size_t n, size_t es, cmp_t *c= mp, void >> *thunk) >> int cmp_result; >> int swap_cnt; >> >> + if (__predict_false(a =3D=3D NULL)) >> + return; >> loop: >> swap_cnt =3D 0; >> if (n < 7) { >> >> This would also work to prevent the NULL pointer arithmetik for >> ports that might also path a =3D=3D NULL and n =3D=3D 0 in certain cas= es. >=20 > The UB happens in this line, when "a =3D=3D NULL" and "n =3D=3D 0", rig= ht? >=20 > for (pm =3D (char *)a + es; pm < (char *)a + n * es; pm +=3D es) >=20 > This is arithmetic on a pointer (the NULL pointer) which is not part of= an > array, which is UB. Yes. > Then, wouldn't "if (__predict_false(n =3D=3D 0))" be more appropriate t= han checking > for "a =3D=3D NULL" here? Testing for "a =3D=3D NULL" might suppress UB= SAN warnings of > valid bugs, i.e. when "qsort" is called with "a =3D=3D NULL" and "n !=3D= 0". In that > case UBSAN _should_ trigger. Yes, but not only UBSAN would trigger, the program would probably crash due to an attempt to access an unmapped page. > UBSAN should not trigger when n =3D=3D 0, though. At least, when "a" do= es point to > a valid array. But what about the case of "a =3D=3D NULL && n =3D=3D 0"= ? Is that deemed > UB? It looks like at least FreeBSD's "qsort_s" implementation says it's= legal. This might be legal, but it leads to adding the element size to a NULL pointer, in the current implementation. The addition happens in the initialization part of the for loop, before n =3D=3D 0 leads to no actual iteration being performed (a + es < a + n * es is false for es > 0). There is no functional difference if the case of a =3D=3D NULL and n =3D=3D 0 is silently ignored. But your are correct: just returning early for a =3D=3D NULL and n !=3D 0= will prevent the program abort. > a !=3D NULL (pointing to valid array), n !=3D 0 -> "normal" case, no = UB > a !=3D NULL (pointing to valid array), n =3D=3D 0 -> should not trigg= er UB, and > doesn't in the current= > implementation It does trigger UB in a way that does not cause issues (or else the problem would have been detected before). a =3D=3D NULL makes the calculation of pm =3D (char *)a + es undefined, but the value of pm will never be used if n =3D=3D 0. > a =3D=3D NULL, n =3D=3D 0 -> should not tri= gger UB? > (debatable) >=20 > So if "a =3D=3D NULL && n =3D=3D 0" was deemed legal, then there would = be no bug in > "mansearch.c", right? IMHO it is not the question of "legal" or not, but we should prevent the undefined behavior that results from execution reaching the initialization part of the for loop. Any you are correct, the patch should probably be: diff --git a/lib/libc/stdlib/qsort.c b/lib/libc/stdlib/qsort.c index 5016fff7895f..eef51d2dd3b3 100644 --- a/lib/libc/stdlib/qsort.c +++ b/lib/libc/stdlib/qsort.c @@ -108,6 +108,8 @@ int cmp_result; int swap_cnt; + if (__predict_false(a =3D=3D NULL && n =3D=3D 0)) + return; loop: swap_cnt =3D 0; if (n < 7) { This will be detected by UBSAN if called with a =3D=3D NULL and n !=3D 0,= but it will also cause the program to fail with typical parameters for the elements to sort and the cmp function. Regards, STefan PS: I just saw Mark's reply regarding n =3D=3D 0 and cmp =3D=3D NULL. Tha= t case is already covered, since n =3D=3D 0 will prevent cmp from being dereferenced (since that only happens in the loop body, which will not be entered for n =3D=3D 0). --------------sWzOcjTR2UPOZjVfWKWfqCl2-- --------------bRIpNhbcXHLAE6JIYyS9A76J Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmHezTwFAwAAAAAACgkQR+u171r99USs 0ggAjg4TpVg6CHmFOCQpOHEtDapGG74qMzORO3AEBbCl5oZfXeYwds8c7AnOGbF2pjwGYg1xqFFU sLXZTzUG5E/MtJCPF9x5KqovxwloqeCBwfJqafRRhlWBx4qiKBC3eVAr322zeWJKHDU7oIc5kNQk ocPN5yAtSPu59YB5vxWUuVoM5wyOCwjCIB9HfMV05ziuQF2Z6ih6KBtVfAcgDEMXsk/hIYUyQFMM oOe1ksqvx1MSwrHiU6NH9i7YSjQbgh80K2Dt25Mu5yVkU5yf7nVvxntJsG5vxOFaeM4NVNLKOeMN gwTiVZymYs4jue0HsjnK/FaEJLlye+y8RP+k2KP8sw== =WBax -----END PGP SIGNATURE----- --------------bRIpNhbcXHLAE6JIYyS9A76J-- From nobody Wed Jan 12 18:48:59 2022 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 5EB081958F6D; Wed, 12 Jan 2022 18:49:08 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYxRl2mxPz4WpD; Wed, 12 Jan 2022 18:49:07 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 20CImxfP068241 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 12 Jan 2022 10:48:59 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 20CImxYd068240; Wed, 12 Jan 2022 10:48:59 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Wed, 12 Jan 2022 10:48:59 -0800 From: Gleb Smirnoff To: net@freebsd.org Cc: current@freebsd.org Subject: compressed TIME-WAIT to be decomissioned Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4JYxRl2mxPz4WpD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [-1.37 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.993]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.72)[0.719]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi! [crossposted to current@, but let's keep discussion at net@] I have already touched the topic with rrs@, jtl@, tuexen@, rscheff@ and Igor Sysoev (author of nginx). Now posting for wider discussion. TLDR: struct tcptw shall be decomissioned Longer version covers three topics: why does tcptw exist? why is it no longer necessary? what would we get removing it? Why does struct tcptw exist? When TCP connection goes to TIME-WAIT state, it can only retransmit the very last ACK, thus doesn't need all of the control data in the kernel. However, we are required to keep it in memory for certain amount of time (2*MSL). So, let's save memory: free the socket, free the tcpcb and leave only inpcb that will point at small tcptw (much smaller than tcpcb) that holds enough info to retransmit the last ACK. This was done in early 2003, see 340c35de6a2. What was different in 2003 compared to 2022? * First of all, internet servers were running i386 with only 2 Gb of KVA space. Unlike today, they were memory constrained in the first place, not CPU bound like they are today. * Many of HTTP connections were made by older browsers, which were not able to use persistent HTTP connections. Those browsers that could, would recycle connections more often, then today. Default timeouts in Apache for persistent connections were short. So, the ratio of connections in TIME-WAIT compared to live connections was much bigger than today. Here is sample data from 2008 provided to me by Igor Sysoev: ITEM SIZE LIMIT USED FREE REQUESTS FAILURES tcpcb: 728, 163840, 22938, 72722, 13029632, 0 tcptw: 88, 163842, 10253, 72949, 2447928, 0 We see that TIME-WAITs are ~ 50% of live connections. Today I see that TIME-WAITs are ~ 1% of connections. My data is biased here, since I'm looking at servers that do mostly video streaming. I'd be grateful if anybody replies to this email with some other modern data on ratio between tcpcb and tcptw allocations. * The Internet bandwidth was lower and thus average size of HTTP object much smaller. That made the average send socket buffer size much smaller than today. Note that TCP socket buffers autosizing came in 2009 only. This means that today most significant portion of kernel memory consumed by an average TCP connection is the send socket buffer, and socket+inpcb+tcpcb is just a fraction of that. Thus, swapping tcpcb to tcptw we are saving a fraction of a fraction of memory consumed by average connection. * Who told that 2*MSL (60 seconds) is adequate time to keep TIME-WAIT? In 71d2d5adfe1 I added some stats on usage of tcptw and experimented a bit with lowering net.inet.tcp.msl. It appeared that lowering it down three times doesn't have statistically significant effect on TIME-WAIT use stats. This means that the already miniscule number of TIME-WAIT connection on a modern HTTP server can be lowered 3 times more. Feel free to lower net.inet.tcp.msl and do your own measurements with 'netstat -sp tcp | grep TIME-WAIT'. I'd be glad to see your results. Ok, now what would removal give us? * One less alloc/free during socket lifetime (immediately). * Reduced code complexity. inp->inp_ppcb always can be dereferenced as tcpcb. Lot's of checking for inp->inp_flags & INP_TIMEWAIT goes away (eventually). * Shrink of struct inpcb. Today inpcb has some TCP-only data, e.g. HPTS. Reason for that is obvious - compressed TIME-WAIT. A HPTS-driven connection may transition to TIME-WAIT, so we can't use tcpcb. Now we would be able to. So, for non TCP connections memory footprint shrinks (with following changes). * Embedding inpcb into protocols cb. An inpcb becomes one piece of memory with tcpcb. One more less alloc/free during socket lifetime. Reduced code complexity, since now inpcb == tcpb (following changes). How much memory are we going to lose? (kgdb) p tcpcb_zone->uz_keg->uk_rsize $5 = 1064 (kgdb) p tcptw_zone->uz_keg->uk_rsize $6 = 72 (kgdb) p tcpcbstor->ips_zone->uz_keg->uk_rsize $8 = 424 After change a connection in TIME-WAIT would consume 424+1064 bytes instead of 424+72. Multiply that by expected number of connections in TIME-WAIT on your machine. Comments welcome. -- Gleb Smirnoff From nobody Wed Jan 12 21:57:23 2022 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 7F0AE194BB63 for ; Wed, 12 Jan 2022 21:57:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZ1dH31n2z525w for ; Wed, 12 Jan 2022 21:57:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642024651; bh=64uQu2v9wbIs5aQCs+m1hJzRMXjtCmBnYF/fa7Jrk6M=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=RIfXczfMnZACRGO2yf1+s4grF4Z1oC9QRKXzJlBWRlTUubB5l7D1BNoRjZeeXLZTGxqP38v1RlH1nBpSXRpW9N6h1VDoFlJAIZHbxZdLbMr5W9ChpM8HyWSFk/bSbttZVhyER15udO8qkAbh3TDkbBmVRENt+ih4CIigb4col1yINMHIHEKSWNv8nqnSe0xoB4XPxojagtfPKjxx5/HNyxunBF9l8k11/x1lPFyQHOz12KnB8OP6pTiHeIzPhr/lRwf3AavC7GCd3vrQORGKv6eMI65O0pYZsgWBZboo4YXljt9qtW24rTZo0hixu2Bh7N0R9XAWi+CjClq5TuRSCg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642024651; bh=NCIYDSXJUaz4m8+udwpcfKkxL3aJhGJRFjbntz77yKZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=J9dWE1VzOz3kb8WMpCIQ3Ax4CM4aAN54DHxu2Lbyd1rCAdtIoQ6GBorvvQDTMmQBf5QwHl705E0I2/CGMUlQ0/gmfEmULKIqk7lyGeCBujksWHllrYpQkrpYZpAEcv39gx+oTBV8Fv08cNJ5TTPkSbrFVvDDu1g8WxtaWmPrt2xKfeKI6cwUim7Izn49+g2kb/EFRA883GNPFrWc+w6Ip6oPrlf7K/qE7S6SwRJLy1GBlBVYqFr6GQbWE0/hepjrQeXjoOgeeUzj/GFQo6T9VIL85zbqnLy9IzZypKL9rfWgEPaGe4nm6R7/1bEPyr9C0KH8Dx87N88TrxfRHwc2mg== X-YMail-OSG: UrE2ytQVM1lnorHmLxvEGQuIQSjIjOyCfuX0BLvIrai9HkAu3n2altM.rQ5h2pT hfUSBfbh89x7bNerzA9L_b9epAwpDIiXth_GYRGl5f9Z6omcqiFscxFHObuY.ulOrHTddj6cYRi3 Wwz__gx9SSHuerVJXto3HORQjKKb4wd_p5JoC.De82uw9kJbUz2FM68XbYRadNBgxpKp2dkYfndm 8RxR4nWhUT4RpAM4OHDHnSOaQtMTMj9EzptYoDtEPQJq4oVlU2Mu.tOeNBBW5YgLe1UMc2A8cPjP Ulzvm8Av4yro8LNf9nUCG335eGCufSnl.kt_nTHQB2xfmh6PlnLtD7mXIqypsG2VlaoYJTgAdUXB 9iX8LJilYVek4T04GvDvb_Jsq6g3msivKawQjNxFJqQCNw.H_oBGCd4Mj_IHRRCoEb4syMgA1mAR cvwB_7aJaXx_6aDv0Yicj0WkCIigjthCsOjEYCSp43vZhCMjIxKkZ9wmuuqWLa08_OxzxZKlMNPT 1eqd.zOkXE_Hh4Rq3H5Th4bXrdOFWWxmaYav3G2fj8Po.Os8SL14XkePrMMSqW9N0f4JDVnGO3qQ 4Sp0MHoYHRVK40CDQl3.M__ARpqcFdGQT5oOV4GCgWOpWcKi_PfNCcytKpsL3kmFLWP6l7C82bo0 PMCrKIynrbKfTJG3fe9NkocrGSYZnWZGbURxGUPQwxN8Rotg0vM1Js8sgOB60djDzACtvv4QtQhb LXE8CeSe8W9v3Urnk70pMOhE5NP_Q32354tIxfMd_TOBGV_KWUMLzLWQYnOys9ZeB4GSIJk8vkbs mPmJP0ZcMtk13sgJEqesithmqpUBtghUOoEkyP1RuRwa_zO6zluGsvTEfKphJmhngtUxlpih4.P7 PlBNw6cdRjOsdiBh8liFdAkbu23ev_PWdIuCBOHMoaVmdZ9SKJzQKeKFxMwA_HvSUB0fep4RWmpC 9b9HpnBR66QrdbeWZCMq_raRV3l_6s.QMdEl74epTlP47EEQ5zzcq57YbAYmSvYKzfAHbzeoduEC xXVoLzN2LQdwZtbz8u.F_rG1IQ_sc6Lm66RqijUIPVujuuWejyaZyTwzrJv99HbG3TpRJ83k3EIi C8qF23SinlMLju70IlAgNLaS_fdqZb950a7Bi5nIVy4WOZ7zg6qgwuyGb6VgUr.l5OeAYvoCyYn9 POU5Ud1.g.somub5XyIdxf5dyyUoVJo0rYjN0.yHpXYd55twuIHfGMUZWuj8TMxj55zk7jxWkPfr .5W.L3oxAd5vYqan3jnF2pesIKVR1Xz0_0fvn3bPr940pm08VrvxEfMJKl40yM4LdJXJ90wrVe22 SE.UFYYKw6tNu.OPpe9ZK3FDN.GvCiwyTmtNrqm2h4I.bBicMoPJdLw0AB0HbtstSpJyj3WZyX4r I6FKebPCdfjdhecVtitjx4ykPtKOoJm_7stmjRsPgOdR5bB.TFOPata6kBBtqlLVufp9L2qnzoTK ME4ADulDBWq_V0FU9FO89fbMKTgvWNW2cLoyPozpQ511VDp44FhZ3iueQfQNmn3FLW7WXRT1Vsdc aKZpY0JlHDCPmU_y0_kwK39GhUydFhcGmy1znK_5DTDW8syAyPOk2pWOzNmKeyskc4P0OE2O43tE UfYOPROXuZieZlN7j6qfv6aUoaNTYyUFIErDIKJdtzVkb7WvNB0hEPlDwBNHh7_j2.kJ2.AAS8kN 5lhvtiO2hklkvamfmx2UGlJpexR19PP96U7OCiCTmucljfviRTEuniyzIJJdf8blIckyUSX95o5a PlYiGjCq84yA0WDNCi4wLUKL8q8EQSl296AtpZT.i7gKjcaSM4SJAfHmCYsLOMofzmTGlD9CiHrV Wy4YhJEApeLoABCkGg32i6mZeW0KHfm_BrTV2CgCFjlBJsAqV5uB4G8ALAS_tRVCC_Qw7MU9sAxB 6Z02CgkGiz33B8JccWuTZ_rfFdaUtuviMStkMY_2y2JzSjHm0wyu6SBK7e5hFMdTRHdzjn6zOU3A IBXJZp1Vz6uJTc02MxFXRGYjcHW0d_cLDrGsi.7Y3DC6bQzdijnsuEN4qQuqPRzX456UmvLNkXhf Zyflo4YOfEUKCr6uOlKBbuyfvsxSJtlQz4OQVf0P21T0YVJXRkU8ZD_JcIRW.IwLAgEVhaIx9X4B lqpG3XeQ997UXXvWr8udBRFSTuJsHioaJr.Stj1lVVc009u0CVWwF.qy.rYBdEKXScVqG.EnpEAI Jb9bv2a4Zg1vxJMHM2UuRcsd8RYYpmkYPM6QwA_0PR4Yw_5G67Ee8sMlRCLUgDfmzUA8UmTqUfqU q X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 12 Jan 2022 21:57:31 +0000 Received: by kubenode522.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ad8f3321dcd301b102f51925a5772d9d; Wed, 12 Jan 2022 21:57:25 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: kyua run under WITH_ASAN= built world reports a global-buffer-overflow during cpio test. Date: Wed, 12 Jan 2022 13:57:23 -0800 References: <313A3FD8-1E8C-46C2-A400-E0A647F09464@yahoo.com> To: freebsd-current In-Reply-To: <313A3FD8-1E8C-46C2-A400-E0A647F09464@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JZ1dH31n2z525w X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=RIfXczfM; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-12, at 01:54, Mark Millard wrote: > For the below it appears that the report from UBSAN is accurate. >=20 > =3D=3D85511=3D=3DERROR: AddressSanitizer: global-buffer-overflow on = address 0x0000010753ca at pc 0x000001139bda bp 0x7fffffffc2b0 sp = 0x7fffffffc2a8 > READ of size 1 at 0x0000010753ca thread T0 > #0 0x1139bd9 in hexdump = /usr/main-src/contrib/libarchive/test_utils/test_main.c:875:35 > #1 0x113b73c in assertion_text_file_contents = /usr/main-src/contrib/libarchive/test_utils/test_main.c:1182:3 > #2 0x1125d46 in basic_cpio = /usr/main-src/contrib/libarchive/cpio/test/test_basic.c:84:2 > #3 0x11259dc in test_basic = /usr/main-src/contrib/libarchive/cpio/test/test_basic.c:229:2 > #4 0x1144943 in test_run = /usr/main-src/contrib/libarchive/test_utils/test_main.c:3561:2 > #5 0x1144943 in main = /usr/main-src/contrib/libarchive/test_utils/test_main.c:4062:9 >=20 > 0x0000010753ca is located 54 bytes to the left of global variable = '' defined in = '/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:229:13' = (0x1075400) of size 5 > '' is ascii string 'copy' > 0x0000010753ca is located 22 bytes to the left of global variable = '' defined in = '/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:228:38' = (0x10753e0) of size 9 > '' is ascii string '1 block > ' > 0x0000010753ca is located 0 bytes to the right of global variable = '' defined in = '/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:220:18' = (0x10753c0) of size 10 > '' is ascii string '2 blocks > ' > SUMMARY: AddressSanitizer: global-buffer-overflow = /usr/main-src/contrib/libarchive/test_utils/test_main.c:875:35 in = hexdump > Shadow bytes around the buggy address: > 0x40000020ea20: f9 f9 f9 f9 02 f9 f9 f9 00 01 f9 f9 00 02 f9 f9 > 0x40000020ea30: 00 00 00 00 00 00 02 f9 f9 f9 f9 f9 00 f9 f9 f9 > 0x40000020ea40: 00 01 f9 f9 00 00 00 00 00 00 01 f9 f9 f9 f9 f9 > 0x40000020ea50: 06 f9 f9 f9 07 f9 f9 f9 00 00 00 00 00 07 f9 f9 > 0x40000020ea60: f9 f9 f9 f9 04 f9 f9 f9 05 f9 f9 f9 00 00 00 00 > =3D>0x40000020ea70: 00 05 f9 f9 f9 f9 f9 f9 00[02]f9 f9 00 01 f9 f9 > 0x40000020ea80: 05 f9 f9 f9 01 f9 f9 f9 00 01 f9 f9 00 05 f9 f9 > 0x40000020ea90: 00 02 f9 f9 00 f9 f9 f9 00 02 f9 f9 07 f9 f9 f9 > 0x40000020eaa0: 00 01 f9 f9 07 f9 f9 f9 00 02 f9 f9 00 02 f9 f9 > 0x40000020eab0: 00 03 f9 f9 00 01 f9 f9 00 04 f9 f9 00 00 00 00 > 0x40000020eac0: 00 00 00 03 f9 f9 f9 f9 00 00 00 f9 f9 f9 f9 f9 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07=20 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > =3D=3D85511=3D=3DABORTING >=20 > Well, contrib/libarchive/cpio/test/test_basic.c:84 is doing: >=20 > assertTextFileContents(se, "pack.err"); >=20 > which involves, in turn: >=20 > int > assertion_text_file_contents(const char *filename, int line, const = char *buff, const char *fn) > { > . . . > s =3D (int)strlen(buff); > contents =3D malloc(s * 2 + 128); > n =3D (int)fread(contents, 1, s * 2 + 128 - 1, f); > . . . > if (n > 0) { > hexdump(contents, buff, n, 0); > . . . >=20 > Nothing about the code seems to constrain n to fit the > size of the space for "pack.err" (9 bytes of "global" > space). >=20 > The report is for the ref[i + j] in the code: >=20 > static void > hexdump(const char *p, const char *ref, size_t l, size_t offset) > { > . . . > for (j =3D 0; j < 16 && i + j < l; j++) { > if (ref !=3D NULL && p[i + j] !=3D ref[i + j]) > . . . >=20 > where ref points to the space for "pack.err" and l was > given a copy of the value of n in the previously shown > code. >=20 > The i + j < l constraint need not avoid the code doing > ref[i + j] in a way that reaches outside the space for > "pack.err" --because of the supplied value of n (a.k.a. l) > not being sufficient to respect the space for "pack.err". pair below shows up in 13 reports: #0 0x1139bd9 in hexdump = /usr/main-src/contrib/libarchive/test_utils/test_main.c:875:35 #1 0x113b73c in assertion_text_file_contents = /usr/main-src/contrib/libarchive/test_utils/test_main.c:1182:3 So the above notes are just an illustration of a more general issue with the assertion_text_file_contents use of "hexdump(contents, buff, n, 0)". =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 12 22:59:58 2022 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 B54FE194EB27 for ; Wed, 12 Jan 2022 23:00:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZ31P0yHJz3krp for ; Wed, 12 Jan 2022 23:00:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642028402; bh=x09OgQ7rOHyXMB4YJ6PiFiloEYkKKgYeK/PolYm4Qy8=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=YF4eAglVYtxjVavcLMh8d5KFZUb34pGDBf2UGZjcuOUEYeJtfkCnn87uj2p6KQqS/6A9ds/QaBnK1CmtLoopdooER2rpmJ1QIgJ8XG6qrqsCuFWL+oZ/Do8qe7CKLvQrQSJGzL3oiwSbMjXqfgHc71gJSwNakDE23KTr7DO0BtAcXQ3xs3QxoGR6iEZ2VgmK8vLVl8lu9pV0J67eJnGjINq2CyYDyHyIjj4A8b7FTpeKRuuKEfk8HK5IBlzrAhvE1NS+ApzS1/6Na4yHUnBxlvoqp9uxkqqoLul4Kvv0sK0TUtlBXoWMCE2kppj6LMXHL3577pHbrYtAtZZwvn1qDw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642028402; bh=eyodVFbdNhL9hhRpVIwHOETqoAFuWphvwuRto6tbitG=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=lfRXrmjQB0jb16PrZXe1IJ29SVj/oRS+tYHRDn8CxFtedLpdzZRMHL8RetKM90kdC0rTmhdbJG/rYa2IVCICgp1lHi+iHivSFVIrkc6D2AVe0jd8gX7ZS7YPhEmdpiFhQoFSEOu9khzX3rXXyrOxKYy9u2W+266hgNpPa33dn11Boi0qVVMt1N0SLrn6EU32NVYij8Yg3x7zboKMYT6CpnOzflocQXWq9bNwAqNgSnrUU3vUc9GPvlJQG3bacDoNP/PcVm5u1Duf4YQkyZgNHj+KS5Xx6qRGV5/KZVEDFf+GQmaskChCogfRS1T/CPDPSqWdYcOjsPQlejv9stxd7w== X-YMail-OSG: yQwjwecVM1kJpQ56fxb9Kw5787otBLsA9EzZiL8O0Tyh5cSXGT0zOOIQC6uZC4I OXgaSvl12vGFvRQGhEjkt_OaATHwTON3FaFJWvYFPVAh.PrDIb9T5aN2LjEEyS8f4UwQiWYVjxbP L1srJcmaADi4RIJUO8erR7A5Xd.vFUlt1O5Q9hRcmPdH16cNUjXGg1I.6bZcpKq3YO74eiUizcho jJJix9ZrCqv5o9dM21ZgyonXU1QXSTYq_wX2PMe1xdCkaS1H4UStTm7axymKAbywfTXuP_0Dy.uO SI.PWUq1I6bTxpWJHCi56cPmg7qXSPBHPXsXXp2UaPt45IxoaIUS10OP73ImIphlcmAQTM4fwlo1 ml4mLt_5nDackbSjCH_WtzsotPc8ggmMNdOyHSLAycjNvPvZ0vu5czW4_7po3x.ErmzSzZZy75XQ 1sxIe32gtrPJgCxMS7_eu4pF9xocNKOUPF4DPgX28ekhoh4G2a.HVegYgXur7T.A.MLYpvBGQIMP vF7ld10WzUKgmW5cyffOAM_.4fyFVtXLJv9jbWHKOgpmATcSUxM9xfpgFwtgqlGmQ6IrN2HSfUWE I7n1d7dJdMHNfL_nlOX2FaacTQI9SsGu5SkedJO8i7EfViiP.1S7lf.3DDl1gDBg6Cj6iXRkuJBp AToVCRW.B65mDQx2kpGlrcOxPtbw_gDT.voDNH7oI7WIiX9as25H9rG7jQjKgqV5ea1t9qPbyxnE NScJmheOipZ5dzzky7u94.QN22QRCQrjtY8DLceMzlGl_ej2I6JEW.DTCkKQvpfSeYRAkXJDZoPR kABYm4U2RGN5kq5uNeH49Lg2pKjlc5hbRo_Oee.RdVbxBormMftk8qI9sqlqYZM_IbsVy.LV..RP Q8nNtPK3m28HAU4.GZjSNnLnempgSpHMJFhcTXUFR32IUgEhm3xNKNA83_URKNwwxAKFFFePZP3V OuJ_wVPmu1K6W75iufpC.wyhV9RWM_L7WTfUu5px3kBrzaLTEigGXgGvuSdcAlhr.hiSAR8fXyz_ h7IFG8XgBeJVf2I6SY0TGKM6PhXMgvCuGtP_skrkGkdtp4UdMx4SeCOXItozMyp_nXWcyQ5E73vd _Dx5j8EawTjMr284M1hEzeHtLQAFUwIF7O0CS8n0T4N9URyhSuG1JEYqrQydlS7v0C6S7bX7dPAj RkTN74VEpSRXOdFjbjS_3WT1d5_2GZim1ZUure3LcveNBDTMzuJjSJhEOBe.Iz8FMp89kbKVgRwZ wMpoofYTHzPUPvdDlQz3AYEpsz5uC6R5zs_fZJhHsOiWTpI7..e4AnmX.S0KGFfFt8XSyWQE6TPP x71opoWuUSZqi0EfezGEt6.r33dciAcvnL7cnfOjM5t.KTw9etwag2roDyIYBPfp0rDLxYJdcNN9 BHh77ZVaEkKxF9EQM8PTQKB6DmlJnKEh3w2mWoqJPfcS1F5OkK6BxVq5e8kEv5sNdtbbvVqYX3kF EaEsV3mcPrsn9pEEMQQNktgiRwHKL3iIZHLkbClzicEZezhO297TIRbuVO6bI0vGClgmSclq30Rk RTveDgGOray3MPm.IYovt4wxOQ9gLWn8zAWv2hC1I6BQHqXV1nx8XVntl5BtWVTJ_Yj6t2xp5b8P 20goAKfvAsyomQGNOfu6ylYoavaqgjoFeTzeaLOQiA__zYqLgZbb4Eo.XZvSUW6JkPw0c1mSncmd 12jR6.X8fFzvIenJsVM7bJXF.kiZjQY0kVMMdmlHibcaW6LzG24lBHL06pmlE8eTao_Hs9qFOpLN rDLy9OdpKvyEXY61sAcAYO8Ps5FEz2Qt5k66.LgZ70iv1jDYCJcAVq94F4W0Lmrs5SUNSIp9j58G b9tHOyJIrQUmoRTYnCI3CxDcxkYNXkPxIw_5UWxOIKkoSc_nlQIavINwBGU4xQ5oViYsub8LLq0t U8.ZukZ2Q7.a6Jyc.1WB6rihL.go26Yn2h1iLCXHaLaKMrAaul9NxK7UAYoDF05l639lhnjPbi4q .VbL476Ib1B3oVAYjXWcrs4NB4D849EydsY_vUaoyqiLwNcdY6iNZk0oAZfbek_82HiClJiznLWT nB7tJQJdyGeE_jLzeD4jvOQOeqls_jtBo.TaSJ7xHQ54a6lcuRlz5BdJWwxVmebqXWIqtgY2KBaj cKOnGTSyr7gJsU2EWHkT4hMYNe3Qg3hiwPyILldbc3vkRrSCdFFMeHpzTPaTIrkIFqocc_GFVMRu E09rBl1TwznWMxrjLGNlwZg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 12 Jan 2022 23:00:02 +0000 Received: by kubenode507.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 750f70c3f19754a14b87f2fc77dfc291; Wed, 12 Jan 2022 23:00: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 14.0 \(3654.120.0.1.13\)) Subject: The kyua in ASAN-built-world reports: the 65 __asan_report_{load4|store8|load8}_noabort examples Message-Id: <604B4A79-EF86-49A9-9AF0-13716EE8D7EB@yahoo.com> Date: Wed, 12 Jan 2022 14:59:58 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <604B4A79-EF86-49A9-9AF0-13716EE8D7EB.ref@yahoo.com> X-Rspamd-Queue-Id: 4JZ31P0yHJz3krp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=YF4eAglV; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N # kyua report --verbose | grep _noabort=20 #7 0x1111227 in __asan_report_load4_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:122:1= #7 0x111163a in __asan_report_store8_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:128:1= . . . #7 0x10ce357 in __asan_report_load8_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:123:1= . . . (The others are examples of the same 3 routines. In fact there is only that one _load4_ example in the list. The rest are _load8_ or _store8_ examples.) But when I look, I find that all of these fail to actually report the load* or store* information, instead running into another problem while trying to do that. It is this other problem that ends up being reported. It is the same problem for all of them. Picking an example: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D102427) #0 0x1112b31 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 #1 0x112e00b in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termin ation.cpp:86:5 #2 0x11153c1 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp #3 0x10bc5a3 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202 :11 #4 0x10bc5a3 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 #5 0x10be09e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) /usr/main-src/contrib/llvm-project/compiler-rt/lib /asan/asan_errors.cpp:390:7 #6 0x11104fc in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) /usr/main-src/contrib/llvm-project/compiler-rt/lib/a san/asan_report.cpp:475:16 #7 0x1111227 in __asan_report_load4_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:122:1= . . . In each case, __asan::AsanThread::GetStackFrameAccessByAddr attempts to = CHECK ptr[0] =3D=3D kCurrentStackFrameMagic and the CHECK fails --so that is = what ends up being reported. My first guess would be that the load* and store* reports are for misaligned stack accesses. But it is just a guess from my lack of managing to think of anything else it would be checking where the only context-usage apparently involved is: load or store with a size in Bytes. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 13 00:16:51 2022 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 9EFED19606C8 for ; Thu, 13 Jan 2022 00:17:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZ4k712b8z4l9j for ; Thu, 13 Jan 2022 00:17:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642033016; bh=BLVWUJFJgV36nFs6gesOqsJ+m4Y+R99X+xSytLd1p/E=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=IJy2/SKvfnDVeJgUBahEFkjhzA17MNJJ4XGQ/TqKG6LnA0znpaokKudIR/Vsrcye92ekfRmevvsLc4xw8QRZCd6fN4uyJHtxXYJ6l/sh24drc+AHFVAdiihcNDCXjD64O5+9sxfYqFx+OY3qrC5JuDn7LfqXVl1DxUjyJ6ppzC6sBRhMK5mMsA34ITviZRsBSo7mMJhHTGzTy9dK4LBcFxlrZk1ffQCNsJKiOncyZ6iyoSTD4nWx3WGcK+ANU+ORGv4cpfoirGN3Jv30itNARYMNiRJIdGp9dxLbjfLyTWEveJTkJZG5nN3/TFAWM3i9IFdTsTmXArGXdge3gzGv/w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642033016; bh=z7GTTM2WpHDQb0ZW++/hXAFBkPPD/CzvET8LuJlHCRZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=pdwibfZHdyA6+ZrPzH+y+WqdntZ2yoKRECqGUYJJ+ZvcBb1nOkzi83PPBQpG1/7dik1MPtrk879ecuQxK1maHvl0S6WgHwcgHAd1XDp9oi8Bd8ZY2VCYNwD4bsK82cY/WD3SPDjNSCKDwOfpIqP+7Zp+Qk+AuSQj33huE7v11PWHit4+tenvwhKFBd47RP1C7gYDhJzYffg4+K2KLIBNmvvjAsxCLrIJOic9rQhWLKcQvWnwygwHb3quu5dFrxpP4+WLePmX1lgGy4SaymVRpw5p2s1O1dSTcdor6oXavWB+3ystrNB0jM5zRH6pazoMRofIHiBT5nZJN0qgYxWHkg== X-YMail-OSG: JnduJhkVM1m3udu6TRduwdwqAMoWZEJp6rETxZhVJ5UShso5PbR4iRQYCybMx_T xaHrm6JjctSWW2pecoMBdIifJSaW7LRku0D41kED5Y64cyIWvRARTEFNiWqrEq5kuppAOnusUNYD NrJISCEcrt4qx7s3.uR7J.RPAq3nd64fkFBfRU7roDCd3n31PPQhqTMjptPjTwmW2drSjUaaDWpl bZ6maPi_MueZTw_mWYcEXked1LO_9VGd38GGvgrUajITBrsSLhlrJ3ePd3p_LhocJOYFpOXvNwtd yDIL9miripUe6p99UBBPppSfLPsmu4HFnEORfc5ReqcQBjyqsGChxGW6QLI9J_M5dH89bTbLQwcV 2TMihYYrhCC2En6R8npj37B9p5wfdrAELdXahYzorC39NTahQFajKA5gCR21KQ2T8TdVvW.nYEb8 K6yTcKfMcFsY565HSnLZF6tgqCP2DYJNKUbZRcdaton9GGBEtK.Y_w1R9flZdb6WI42CivHYoQ1G o6SfwYn9JA7PXXZ5G4PzFStoWnxZxjWMR_eei3K_VQrUVgexh9JdVwST8t6lrOKYG263lOlA3YIK APlyIsODST88WpCvm5itcms89AgKtzDRSM4N7gG3A9Y3QBnfLlgcMv.u96gg.HGcIef8pPRTgbfR ibqsKCtHaukTgTLlzGx1C26rnfvfBi7.n3mGv.KGVyHmO.GTbk2e4aLXMEAh0kf6sCOF815qVS_i jew8H.jH8hAAHSCUEn3Jr1ZoGPvW3pMdYjFZQ3bCXNsa00FnPTJZiscKutf6SHF3l8FjzVB_hWfV pqUwYCSV_jco9heHWip1pGJGKWEVO8yTXFex9h99Pm40pQVUjv.ESTlhhmlVruNS2niTFMib2b87 Nvbsk1AeVt4Jbz7f76EKHWAYwgWIFep9LlPzm2FyWJ6kj7S4vZmFGvj724apEjQgOlNz.D92celz BgygwzCyMVCDhR9thtpyP_wGFYk30V6itxvljaQEzMkzhBXrNw_ErtAdBTHOrdGDx3tFXO.IjpTP dcHpy3zTIbuhhZi5aLQc5iLHVHUdNfZgMSATRJ2Q838uRF3hz6j9wup3TICn1fHRzOshRNG2GFno .uo4mH_50naY0rLkIp8uly4kWYfPn.PRJkdgLHA7MGs74e5DRkDunPif35N7RzPthvftKUFFOw4U RtU0Lwz8hbM3xtIbUIoqE_9FmFsSUduY_sKhl.S.JYgpQzb31aZpxisNW3FTJ8uoJpbbk.BFT251 4MABJSwvQzc3J.wDI.BZXZau.JHcAe_x76ERExnttXjdB9f9gf3vg4fKcPKrUYZJn7I.rWtIMLBI lT_zHHd.5tOa5ucqmfpMvlvttiiIjuHrXPEEdtzkw2GVPZSOvIxWrBIkz6RUY1kytjyU36fM4XtB AJVZmGlH7shXuY4fFMsCPPYjwqMEEHElEfPDavxmy6AAlP0ip27clwhP5w3zCEwCah87yAuX2lEt qWaG4ByPrCQqbdqEAIEj5efAdi.KuerofbFfoY2sqEe4gHSfLkq.O954zqiEII6U7kcSpRVCinoH tzlzVJ_eN2ailMXTJixiusaSqfRdwudCf_JHH94QLK2KNL13PsDuiWz5vSkVVRP7dnAFIae9YQcb MabFLUCxwfd.U9p5qDwjaiKtqjwqMh88gk.gYlp9f7MzUr4tNR.AShF2Ew.JuOeOwUG7K0RPdwUz C5wO8PT.Pt3WWHXurH9j7d4IncSe3NLMGbwCPrxSKzSNLYSr_3g99PLw2nx5Zod6h_hNITISw6CX V.Wwiirz4t7VAdCay00jDU_h5bbSQxPnMoF5YLKOl3D8amr.TWc4kPUp3sJbMt52PKNu_a51iBVF E1EmlOacz0Ilo6Z5w95MQOcW4PDfuPFfsjmguKBHfQiKHNME2FsHRjGwmg3lzcJ6ClyF9krAWzG4 6rcXu8HCB8zm9bHFRlYpsW8b.XyQHs18IgUdfIWtLquuPQeDyau2r7nFpYAG8Dvk7x5zttxaqVwQ q4QbI_DcfBimJDwvTGCsZtE2JUWEoYsdfkS5qYDLFUbb.LokvFTH1ThSeu6MIBIH9K_nf1wM2Xvh reZXia9TeDOmyq28IZnKp4berV.KVGr8ghhoBi37t9_rP6CWBWYqwNxIuUkcGO2w9eU1n_BiMrei W6cR4OMgNZvCsNOL6Ksz4x1PqdDBAYLF6TCXSfYhM23js1C5QCvMrDE3VY2SVyrXwZVzSYWpk6VY yUCvqAcT.N4AQJZcFfcwxhh9hrP2m1KbOr.mMP0OYOamPYJMmX.R3Z7o5L2BmtSvdmtdJDjnhhlO TzA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 13 Jan 2022 00:16:56 +0000 Received: by kubenode516.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ba6129f8b57145faa247b526a3f74515; Thu, 13 Jan 2022 00:16:52 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: The kyua in ASAN-built-world reports: the 65 __asan_report_{load4|store8|load8}_noabort examples Date: Wed, 12 Jan 2022 16:16:51 -0800 References: <604B4A79-EF86-49A9-9AF0-13716EE8D7EB@yahoo.com> To: freebsd-current In-Reply-To: <604B4A79-EF86-49A9-9AF0-13716EE8D7EB@yahoo.com> Message-Id: <1A24051A-7259-4A99-8F98-AD03431C6569@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JZ4k712b8z4l9j X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="IJy2/SKv"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-12, at 14:59, Mark Millard wrote: > # kyua report --verbose | grep _noabort=20 > #7 0x1111227 in __asan_report_load4_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:122:1= > #7 0x111163a in __asan_report_store8_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:128:1= > . . . > #7 0x10ce357 in __asan_report_load8_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:123:1= > . . . >=20 > (The others are examples of the same 3 routines. In fact there is > only that one _load4_ example in the list. The rest are _load8_ or > _store8_ examples.) >=20 > But when I look, I find that all of these fail to actually report the > load* or store* information, instead running into another problem = while > trying to do that. It is this other problem that ends up being = reported. > It is the same problem for all of them. >=20 > Picking an example: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D102427) > #0 0x1112b31 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 > #1 0x112e00b in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termin > ation.cpp:86:5 > #2 0x11153c1 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp > #3 0x10bc5a3 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202 > :11 > #4 0x10bc5a3 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 > #5 0x10be09e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) /usr/main-src/contrib/llvm-project/compiler-rt/lib > /asan/asan_errors.cpp:390:7 > #6 0x11104fc in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) /usr/main-src/contrib/llvm-project/compiler-rt/lib/a > san/asan_report.cpp:475:16 > #7 0x1111227 in __asan_report_load4_noabort = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:122:1= > . . . >=20 > In each case, __asan::AsanThread::GetStackFrameAccessByAddr attempts = to CHECK > ptr[0] =3D=3D kCurrentStackFrameMagic and the CHECK fails --so that is = what ends > up being reported. >=20 > My first guess would be that the load* and store* reports are for > misaligned stack accesses. But it is just a guess from my lack of > managing to think of anything else it would be checking where the > only context-usage apparently involved is: load or store with a size > in Bytes. >=20 There are 4 other examples of ptr[0] =3D=3D kCurrentStackFrameMagic = reports, ones that do not involve __asan_report_{load4|store8|load8}_noabort in the backtraces. 3 examples are during memcpy used by handle_signal . An example is: AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D210226) LLVMSymbolizer: error reading file: No such file or directory #0 0x1112b31 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 #1 0x112e00b in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termin ation.cpp:86:5 #2 0x11153c1 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp #3 0x10bc5a3 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202 :11 #4 0x10bc5a3 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 #5 0x10be09e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) /usr/main-src/contrib/llvm-project/compiler-rt/lib /asan/asan_errors.cpp:390:7 #6 0x11104fc in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) /usr/main-src/contrib/llvm-project/compiler-rt/lib/a san/asan_report.cpp:475:16 #7 0x10ca344 in memcpy = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:827:5 #8 0x80147c861 in handle_signal = /usr/main-src/lib/libthr/thread/thr_sig.c:313:2 #9 0x80147b1f4 in thr_sighandler = /usr/main-src/lib/libthr/thread/thr_sig.c:246:2 #10 0x7fffffffe8a2 ([vdso]+0x2d2) #11 0x801e1d969 in __sys_wait4 = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/lib/li= bc/_wait4.S:4 #12 0x801488d1b in __thr_wait4 = /usr/main-src/lib/libthr/thread/thr_syscalls.c:581:8 #13 0x10d6953 in wait3 = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:2463:13 #14 0x11716a7 in dowait /usr/main-src/bin/sh/jobs.c:1181:9 #15 0x1167977 in waitforjob /usr/main-src/bin/sh/jobs.c:1092:7 #16 0x1142301 in evalsubshell /usr/main-src/bin/sh/eval.c:442:16 #17 0x113f7e1 in evaltree /usr/main-src/bin/sh/eval.c:234:4 #18 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 #19 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 The other type of example is the one associated with sigaltstack : AddressSanitizer: CHECK failed: asan_thread.cpp:371 "((ptr[0] =3D=3D = kCurrentStackFrameMagic)) !=3D (0)" (0x0, 0x0) (tid=3D102471) #0 0x1112b31 in __asan::CheckUnwind() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:67:3 #1 0x112e00b in __sanitizer::CheckFailed(char const*, int, char = const*, unsigned long long, unsigned long long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_termin ation.cpp:86:5 #2 0x11153c1 in = __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, = __asan::AsanThread::StackFrameAccess*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_thread.cpp #3 0x10bc5a3 in __asan::GetStackAddressInformation(unsigned long, = unsigned long, __asan::StackAddressDescription*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:202 :11 #4 0x10bc5a3 in = __asan::AddressDescription::AddressDescription(unsigned long, unsigned = long, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_descriptions.= cpp:454:21 #5 0x10be09e in __asan::ErrorGeneric::ErrorGeneric(unsigned int, = unsigned long, unsigned long, unsigned long, unsigned long, bool, = unsigned long) /usr/main-src/contrib/llvm-project/compiler-rt/lib /asan/asan_errors.cpp:390:7 #6 0x11104fc in __asan::ReportGenericError(unsigned long, unsigned = long, unsigned long, unsigned long, bool, unsigned long, unsigned int, = bool) /usr/main-src/contrib/llvm-project/compiler-rt/lib/a san/asan_report.cpp:475:16 #7 0x110154f in sigaltstack = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:10044:5 #8 0x110e902 in __asan::PlatformUnpoisonStacks() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_posix.cpp:44:= 3 #9 0x11127f5 in __asan_handle_no_return = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:605:8= #10 0x1146099 in evalcommand /usr/main-src/bin/sh/eval.c:1151:3 #11 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #12 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 #13 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #14 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #15 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 #16 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #17 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #18 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 #19 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #20 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #21 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 #22 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 This last is interesting in that it is the only example of sigaltstack being involved in this type of failure, despite: # kyua report --verbose | grep " sigaltstack /usr" | wc 665 3325 94430 Many/most of the other 664 seem to look similar to: =3D=3D80233=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on = address 0x7fffffffa458 at pc 0x00000110152e bp 0x7fffffffa430 sp = 0x7fffffff9bf8 WRITE of size 24 at 0x7fffffffa458 thread T0 #0 0x110152d in sigaltstack = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:10044:5 #1 0x110e902 in __asan::PlatformUnpoisonStacks() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_posix.cpp:44:= 3 #2 0x11127f5 in __asan_handle_no_return = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:605:8= #3 0x1146099 in evalcommand /usr/main-src/bin/sh/eval.c:1151:3 #4 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #5 0x1140639 in evalpipe /usr/main-src/bin/sh/eval.c:607:4 #6 0x1140639 in evaltree /usr/main-src/bin/sh/eval.c:285:4 #7 0x1146ef6 in evalbackcmd /usr/main-src/bin/sh/eval.c:699:4 #8 0x1151bfc in expbackq /usr/main-src/bin/sh/expand.c:476:2 #9 0x1151bfc in argstr /usr/main-src/bin/sh/expand.c:323:4 #10 0x1151178 in expandarg /usr/main-src/bin/sh/expand.c:241:2 #11 0x11427c8 in evalcommand /usr/main-src/bin/sh/eval.c:857:4 #12 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #13 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 #14 0x113f672 in evalfor /usr/main-src/bin/sh/eval.c:367:3 #15 0x113f672 in evaltree /usr/main-src/bin/sh/eval.c:257:4 #16 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #17 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #18 0x113fc55 in evaltree /usr/main-src/bin/sh/eval.c:241:4 #19 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #20 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #21 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #22 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #23 0x113eb88 in evalstring /usr/main-src/bin/sh/eval.c #24 0x1179727 in main /usr/main-src/bin/sh/main.c:171:3 There is one example of a READ of size 8 instead of a WRITE of size 24. It looks like: =3D=3D82352=3D=3DERROR: AddressSanitizer: stack-buffer-overflow on = address 0x7fffffffc780 at pc 0x00080148845e bp 0x7fffffffc6d0 sp = 0x7fffffffc6c8 READ of size 8 at 0x7fffffffc780 thread T0 #0 0x110152d in sigaltstack = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:10044:5 #1 0x110e902 in __asan::PlatformUnpoisonStacks() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_posix.cpp:44:= 3 #2 0x11127f5 in __asan_handle_no_return = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:605:8= #3 0x1146099 in evalcommand /usr/main-src/bin/sh/eval.c:1151:3 #4 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #5 0x113f42b in evaltree /usr/main-src/bin/sh/eval.c:238:4 #6 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 #7 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 Address 0x7fffffffce58 is located in stack of thread T0 SUMMARY: AddressSanitizer: stack-buffer-overflow = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:10044:5 in sigaltstack #0 0x110152d in sigaltstack = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:10044:5 #1 0x110e902 in __asan::PlatformUnpoisonStacks() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_posix.cpp:44:= 3 #2 0x11127f5 in __asan_handle_no_return = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:605:8= #3 0x1146099 in evalcommand /usr/main-src/bin/sh/eval.c:1151:3 #4 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #5 0x113f42b in evaltree /usr/main-src/bin/sh/eval.c:238:4 #6 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 #7 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 Shadow bytes around the buggy address: 0x4ffffffff970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff9a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff9b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =3D>0x4ffffffff9c0: 00 00 00 00 00 00 00 00 f3 f3 f3[f3]00 00 00 00 0x4ffffffff9d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff9e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffffa10: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f2 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Address 0x7fffffffce58 is located in stack of thread T0 =3D=3D82357=3D=3DABORTING There are various examples that look similar to: . . . =3D=3D80232=3D=3DABORTING #0 0x110152d in sigaltstack = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:10044:5 #1 0x110e902 in __asan::PlatformUnpoisonStacks() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_posix.cpp:44:= 3 #2 0x11127f5 in __asan_handle_no_return = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:605:8= #3 0x1146099 in evalcommand /usr/main-src/bin/sh/eval.c:1151:3 #4 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #5 0x1140639 in evalpipe /usr/main-src/bin/sh/eval.c:607:4 #6 0x1140639 in evaltree /usr/main-src/bin/sh/eval.c:285:4 #7 0x1146ef6 in evalbackcmd /usr/main-src/bin/sh/eval.c:699:4 #8 0x1151bfc in expbackq /usr/main-src/bin/sh/expand.c:476:2 #9 0x1151bfc in argstr /usr/main-src/bin/sh/expand.c:323:4 #10 0x1151178 in expandarg /usr/main-src/bin/sh/expand.c:241:2 #11 0x11427c8 in evalcommand /usr/main-src/bin/sh/eval.c:857:4 #12 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #13 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 #14 0x113f672 in evalfor /usr/main-src/bin/sh/eval.c:367:3 #15 0x113f672 in evaltree /usr/main-src/bin/sh/eval.c:257:4 #16 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #17 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #18 0x113fc55 in evaltree /usr/main-src/bin/sh/eval.c:241:4 #19 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #20 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #21 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #22 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #23 0x113eb88 in evalstring /usr/main-src/bin/sh/eval.c #24 0x1179727 in main /usr/main-src/bin/sh/main.c:171:3 Address 0x7fffffffa458 is located in stack of thread T0 SUMMARY: AddressSanitizer: stack-buffer-overflow = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:10044:5 in sigaltstack Shadow bytes around the buggy address: 0x4ffffffff430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =3D>0x4ffffffff480: 00 00 00 00 00 00 00 00 f3 f3 f3[f3]00 00 00 00 0x4ffffffff490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4a0: f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4d0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f2 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jan 13 00:53:00 2022 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 577131952B33 for ; Thu, 13 Jan 2022 00:53:08 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4JZ5Wl2Qp7z3J8p for ; Thu, 13 Jan 2022 00:53:07 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 20D0r1eX001048 for ; Thu, 13 Jan 2022 00:53:01 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 20D0r0Xx001047 for freebsd-current@freebsd.org; Thu, 13 Jan 2022 00:53:01 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202201130053.20D0r0Xx001047@donotpassgo.dyslexicfish.net> Date: Thu, 13 Jan 2022 00:53:00 +0000 Organization: Dyslexic Fish To: freebsd-current@freebsd.org Subject: [patch] touch(1) enhancement User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Thu, 13 Jan 2022 00:53:01 +0000 (GMT) X-Rspamd-Queue-Id: 4JZ5Wl2Qp7z3J8p X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-3.59 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_LONG(-0.89)[-0.891]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US] X-ThisMailContainsUnwantedMimeParts: N I've added an option to touch(1) - details here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260871 It adds "-R", which is like "-r", but in the case of a link, refers to the link itself. I'm not sure what the protocol is regarding adding "non-standard" options to standard commands, so please don't flame me if you think it's useless! Cheers, Jamie From nobody Thu Jan 13 07:16:09 2022 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 53B8E1944D8E; Thu, 13 Jan 2022 07:16:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZG21048bz4fxv; Thu, 13 Jan 2022 07:16:24 +0000 (UTC) (envelope-from 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 20D7GANI031495; Wed, 12 Jan 2022 23:16:16 -0800 (PST) (envelope-from bsd-lists@bsdforge.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 Date: Wed, 12 Jan 2022 23:16:09 -0800 From: Chris To: Gleb Smirnoff Cc: net@freebsd.org, current@freebsd.org Subject: Re: compressed TIME-WAIT to be decomissioned In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_4ae67900a837bea3c4e6e4d25307e30b" X-Rspamd-Queue-Id: 4JZG21048bz4fxv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_4ae67900a837bea3c4e6e4d25307e30b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-01-12 10:48, Gleb Smirnoff wrote: > Hi! Thanks for the informative writeup, Gleb! Untrimmed, sorry... > > [crossposted to current@, but let's keep discussion at net@] > > I have already touched the topic with rrs@, jtl@, tuexen@, rscheff@ and > Igor Sysoev (author of nginx). Now posting for wider discussion. > > TLDR: struct tcptw shall be decomissioned > > Longer version covers three topics: why does tcptw exist? why is it no > longer necessary? what would we get removing it? > > Why does struct tcptw exist? > > When TCP connection goes to TIME-WAIT state, it can only retransmit > the very last ACK, thus doesn't need all of the control data in the kernel. > However, we are required to keep it in memory for certain amount of time > (2*MSL). So, let's save memory: free the socket, free the tcpcb and > leave only inpcb that will point at small tcptw (much smaller than tcpcb) > that holds enough info to retransmit the last ACK. This was done in > early 2003, see 340c35de6a2. > > What was different in 2003 compared to 2022? > > * First of all, internet servers were running i386 with only 2 Gb of KVA > space. Unlike today, they were memory constrained in the first place, not > CPU bound like they are today. > > * Many of HTTP connections were made by older browsers, which were not able > to use persistent HTTP connections. Those browsers that could, would > recycle connections more often, then today. Default timeouts in Apache > for persistent connections were short. So, the ratio of connections > in TIME-WAIT compared to live connections was much bigger than today. > Here is sample data from 2008 provided to me by Igor Sysoev: > > ITEM SIZE LIMIT USED FREE REQUESTS FAILURES > tcpcb: 728, 163840, 22938, 72722, 13029632, 0 > tcptw: 88, 163842, 10253, 72949, 2447928, 0 > > We see that TIME-WAITs are ~ 50% of live connections. > > Today I see that TIME-WAITs are ~ 1% of connections. My data is biased > here, since I'm looking at servers that do mostly video streaming. I'd > be grateful if anybody replies to this email with some other modern data > on ratio between tcpcb and tcptw allocations. > > * The Internet bandwidth was lower and thus average size of HTTP object > much smaller. That made the average send socket buffer size much smaller > than today. Note that TCP socket buffers autosizing came in 2009 only. > This means that today most significant portion of kernel memory consumed > by an average TCP connection is the send socket buffer, and > socket+inpcb+tcpcb is just a fraction of that. Thus, swapping tcpcb to > tcptw we are saving a fraction of a fraction of memory consumed by average > connection. > > * Who told that 2*MSL (60 seconds) is adequate time to keep TIME-WAIT? > In 71d2d5adfe1 I added some stats on usage of tcptw and experimented a bit > with lowering net.inet.tcp.msl. It appeared that lowering it down three > times doesn't have statistically significant effect on TIME-WAIT use > stats. > This means that the already miniscule number of TIME-WAIT connection on a > modern HTTP server can be lowered 3 times more. Feel free to lower > net.inet.tcp.msl and do your own measurements with > 'netstat -sp tcp | grep TIME-WAIT'. I'd be glad to see your results. I think that should be: 'netstat -sp tcp | grep TIME_WAIT' fe; on the system I'm writing this from: up 15:19, coffee# netstat -sp tcp | grep TIME_WAIT 5 connections in TIME_WAIT state > > Ok, now what would removal give us? > > * One less alloc/free during socket lifetime (immediately). > * Reduced code complexity. inp->inp_ppcb always can be dereferenced as > tcpcb. > Lot's of checking for inp->inp_flags & INP_TIMEWAIT goes away > (eventually). > * Shrink of struct inpcb. Today inpcb has some TCP-only data, e.g. HPTS. > Reason for that is obvious - compressed TIME-WAIT. A HPTS-driven > connection > may transition to TIME-WAIT, so we can't use tcpcb. Now we would be able > to. > So, for non TCP connections memory footprint shrinks (with following > changes). > * Embedding inpcb into protocols cb. An inpcb becomes one piece of memory > with > tcpcb. One more less alloc/free during socket lifetime. Reduced code > complexity, since now inpcb == tcpb (following changes). > > How much memory are we going to lose? > > (kgdb) p tcpcb_zone->uz_keg->uk_rsize > $5 = 1064 > (kgdb) p tcptw_zone->uz_keg->uk_rsize > $6 = 72 > (kgdb) p tcpcbstor->ips_zone->uz_keg->uk_rsize > $8 = 424 > > After change a connection in TIME-WAIT would consume 424+1064 bytes instead > of 424+72. Multiply that by expected number of connections in TIME-WAIT on > your machine. > > Comments welcome. --=_4ae67900a837bea3c4e6e4d25307e30b Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_4ae67900a837bea3c4e6e4d25307e30b-- From nobody Thu Jan 13 16:37:02 2022 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 BBF87195236A; Thu, 13 Jan 2022 16:37:17 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZVT93MYvz4ZL8; Thu, 13 Jan 2022 16:37:17 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 20DGb2MM072267 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 13 Jan 2022 08:37:02 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 20DGb2p4072266; Thu, 13 Jan 2022 08:37:02 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Thu, 13 Jan 2022 08:37:02 -0800 From: Gleb Smirnoff To: Chris Cc: net@freebsd.org, current@freebsd.org Subject: Re: compressed TIME-WAIT to be decomissioned Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JZVT93MYvz4ZL8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jan 12, 2022 at 11:16:09PM -0800, Chris wrote: C> > * Who told that 2*MSL (60 seconds) is adequate time to keep TIME-WAIT? C> > In 71d2d5adfe1 I added some stats on usage of tcptw and experimented a bit C> > with lowering net.inet.tcp.msl. It appeared that lowering it down three C> > times doesn't have statistically significant effect on TIME-WAIT use C> > stats. C> > This means that the already miniscule number of TIME-WAIT connection on a C> > modern HTTP server can be lowered 3 times more. Feel free to lower C> > net.inet.tcp.msl and do your own measurements with C> > 'netstat -sp tcp | grep TIME-WAIT'. I'd be glad to see your results. C> I think that should be: C> 'netstat -sp tcp | grep TIME_WAIT' C> fe; on the system I'm writing this from: C> C> up 15:19, coffee# C> netstat -sp tcp | grep TIME_WAIT C> 5 connections in TIME_WAIT state I'm talking about statistics that I recently committed to CURRENT only: # netstat -sp tcp | grep TIME-WAIT 3 times connection in TIME-WAIT responded with ACK 0 times connection in TIME-WAIT was actively recycled 0 times connection in TIME-WAIT responded with RST They show were the TIME-WAITs actually used. -- Gleb Smirnoff From nobody Thu Jan 13 20:17:25 2022 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 9D9411954A88; Thu, 13 Jan 2022 20:17:40 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZbMR4t7Gz4qsD; Thu, 13 Jan 2022 20:17:39 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 20DKHPsB072998 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 13 Jan 2022 12:17:25 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 20DKHP64072997; Thu, 13 Jan 2022 12:17:25 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Thu, 13 Jan 2022 12:17:25 -0800 From: Gleb Smirnoff To: Michael Tuexen Cc: Chris , net@freebsd.org, current@freebsd.org Subject: Re: compressed TIME-WAIT to be decomissioned Message-ID: References: <933E3937-5ED9-4483-9C7E-1A2B91C78CD1@lurchi.franken.de> 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: <933E3937-5ED9-4483-9C7E-1A2B91C78CD1@lurchi.franken.de> X-Rspamd-Queue-Id: 4JZbMR4t7Gz4qsD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [-1.01 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[glebius]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.910]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[net,current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jan 13, 2022 at 09:06:50PM +0100, Michael Tuexen wrote: M> > I'm talking about statistics that I recently committed to CURRENT only: M> > M> > # netstat -sp tcp | grep TIME-WAIT M> > 3 times connection in TIME-WAIT responded with ACK M> > 0 times connection in TIME-WAIT was actively recycled M> > 0 times connection in TIME-WAIT responded with RST M> > M> > They show were the TIME-WAITs actually used. M> Aren't they also used on the client side to avoid reusing the same 5-tuple M> with the 2 * MSL period. This is not covered by the above (and possibly not M> relevant on the machine you where looking at). Good point. We are not counting this kind of use. -- Gleb Smirnoff From nobody Fri Jan 14 09:50:13 2022 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 6453019658E6 for ; Fri, 14 Jan 2022 09:50:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZxPL1pp7z3n5N for ; Fri, 14 Jan 2022 09:50:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642153823; bh=e41g773Idg8IHGIHDAVFY0GYle3PUaJMInNkU+APfOE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=a2w8cQK/mj85QmutjEo2B1VsqMzmoeed83DZqPzBYVYydfAhZmPJ06EJJyzYYypo8mwTqooh04o6UNsqufSfapsP/ay4pqdgL1IfNc/KE/DP17ewgWblu2T0OA0GhVbHOgCfwMNc0ScLDIz2WM/RQRqn2n7Vjo9nvE1PY8Pwybb+PPek3dE6eNa+Edwi4XyS2i7Zl3TeB4aSMWEPh1BYzt64aZ1RFQf1gUqJfggQF9buxjpU6q4pbEFerCZb9J6YwODXPuMiSHs1Uu2HVGc+7zbmUstBOQXAm0sdrXa5GF8oYQAx1+ZKQCPKIN7uT4JZf2OcSZJJWsga7tsmzssoyA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642153823; bh=ddREWBmaL9WnkTgYOX6Kj7OwG2pMF4MM37yWRSzChM6=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=tZ74xDorHfw6fa6gHDMTPCL08rOCZBpYui5NEd9OQeDq1AJJ7YbdYaR6iY6Yfbq4w8yGXOrhUlKWweJHaxeLlrqcNv38fFJcI5Hk65hMHhE4KPKj8izd3O/RfjQOf+7JTiaSD8DP3sSvRDRnI3m63Uide/s/HtyMKBYOYsKJ1U3hSn2INJlAHUvCb+dZGKvezVtdobt9uyYPtQt3i2vJovFXdAjNafM5DC5la1nyQhn3ryRdsD701b3zIhjJ10Rt+JQNxmY15gvWWg2uwMDaEjPV3DqaNFwqQNHlcze4jpiFJN1Me4L4qFAESkzK66yAzTc68yHLTAJw90HbCd8Gbw== X-YMail-OSG: fVQTQiEVM1kK9xR.hSTnL.QH7bPmNZSzbGyCdg3Gm3aZjhP5v9Q8FCYcUkyHjOg eVpSYJvvX3rPvmL9b_aL8RjfU3wjz8dVJkoC.8CxWIYjb3.4l3Y3KggWsRF7a0x8xeaQm_qqZrig 8dRWcibDVywHo1R6.tLx4QiYeZ1d3YFLG_zVFAGzfGZan17t8gBlKUqqcpsYPAgIfJD0VMp9WtNX 4I87gIZccrmcx.nzrmx5NZVPeUJPKW.2eoFLhFeZbUnI9mO4E1s_Llo8EJnGiSc8wY2VuWS.8vdF wnJ4cvJ_xZmVz1Y7Z0v2ctiivyAAUrddaxA0VAd_1itSexdScHSx8.ghRSb6qBhUzG8OZEIwSXHc kOby1nmV4rbCSiMXKM6QWFS8ZSih76RfOzNioIrGbkddZ1_EFZ29hyVGv3NzRyO0VFDqv5l3zlnP .vFhukV3G_wVLbuo4._R04RYrYMnmk3tLf7wRaV1qIB265p24qkg9oJR9fOOstgIr_ApNGI9jLB5 LcEJFAIJ4z_T1hFQjnPYoeJ08TnasUbzhQC67.ezGmfkgTKqdFdYANXSbMelAwCXsth8w_sCWjpl tHTqxioisyXDEYpekLW4bXd0Ev_Vfns0BBF92lXWGPMyMEDkDUU21mqCPq2GdG4X2BETNyBAzIBA PHVGlmYzm2dWdZWH0zVRjzytl9deFy7vrIRqzCpZ.VLcWBVemGfLxbguAGPNOh62qi_JaOWJAi_8 CxLJrqvXplK_wBxvqlqPYFUbTr8X4UZQJ3Jwzps3T4cknXyeWQ7hQnnY7Ig3nIatQGe9OXVaG3Np S.cdr3OHx.TJZ_GsC81eQc.7QyKQFJoFkJJZiz3uxVCyHD4thGPj_3SV.bTsZdzHwygbHr4HJIHi kJSM8UHSfrfY7XpRIdK9L151rZdsq3FZrvVj8Gbze0r88Grx_2oMxQukv9prsAYIMbple53_iXmO O0E1OOnptf1EZQy_Dg0ClBTlAdjeUNXWHS6JIURo7rGZ.pfHCj1KBkCDvdqJOVF3AgXaVm9Rz7O2 HwLrbPNIuvBlU6ERCoZ1YpQ8UFrATW7qZp7r1EL_odn74yeQSVLlKbZgfrDLxqHat0rQ8dhsTTLb pQ1QgFWH1oBa7HTXcsPC2mb5UmRbs0eXgOQeG5t0fjzytLvxeEcTYL8_kZhCgcqcqric8APUQUmV aa_QFkQZzie8VBwo56PvLHpGY1dz4oVDWAx8IUgQJglqA7FGPTqCv73zixL9M0Wicfbbq8901FhQ uT61snG3TcMXs6oasUq5uWXS2vQOm1bLBp47S1gQ0GdKPbaao7xSBgMf45g7rRexNpjKmfx3sOTm qKh4bVVQrMP6XSL_NieIqJYhcgoXgfF4DV_iH7tl9Wrjrh9rL.LYjLu2jPXAU_X2ZDdN5euJmUj. Km5Nhb9AsAl869T1QZB55Fn5LWYWCFEKNfnLPLjOiD58eYXu2XGA6buD4k4JhsRWgRc5EI.VPnrP XP89_Kb4tEL9Qe1yFVfjmi2V7MsopAnvJoxt8Zm8ipP1GGDw8wp5RSsvBCYR2jJalnfauSOkkWI. ksBHGK4z4ghOFsRj4RfovkrTYesY47yALiqxZT9uU9MWTHcIN2a9guzmodnTyB9dAulX7le8RXer SG5ciqQZV4kTbzf8ZcP4IqSUJOHnqaE.0U8olljF.bCNmPTpGdgUvb9NDWvxahsI04f0gKhjulio pdmv5FQYlzML6NGlUAWQg9p58OU33UH43q8VOhvU9tU7nJ9cvxRduC_Rs5I2BN9Zr2qrkj.MqJR1 1opt5TR92fWnPbHNlfWqxK_AuWvovE3AOzG74_C5xKYBOm.oZ5hMQC1ORCV8r_xkcAqoAmSnsu_B YiU23azyyloHuQNZnEEXUf8SrMZtyq4bAACPd5.vSIqawNQxsOHsLLriLTBiH5cUr7FXF9U9UiBf aZxZBx3DDzR8DjSEHfEW4po.TNOo.IuYniUf9VuthEsWe0uO9NksZuiTIOhwK9pMeNqKV0iK7r5A EIXlfsf1LSSYN0U5pF9nLwia1gXjvC2Zjg1gpDahpB0vzCb9Fu6wmH6PMgcczBPOB6NQy6WNQhRx cM07icdAoC5N0dncfNDC5QLWCq5EA8vL82gvi9V5LnP_nyR2LqP0HpWkyUTG376wBIAuNhXxg1P. PuipZUfzIR5fA6Qt9I3njSWNLmpaq1Y3MxuCgqf.F28GsfsDnzW7a8oygwMWlCKSiHMWCSCaPQYc iz8CvvKCfmxSghBovayek X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Jan 2022 09:50:23 +0000 Received: by kubenode500.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e97fd41b12a44a2a04d295a565378817; Fri, 14 Jan 2022 09:50:14 +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 14.0 \(3654.120.0.1.13\)) Subject: UBSAN report for main [so: 14] zpool status -x : applying non-zero offset 4 to null pointer Message-Id: <62A093FB-BC32-42F7-B54B-05596A95C4A9@yahoo.com> Date: Fri, 14 Jan 2022 01:50:13 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <62A093FB-BC32-42F7-B54B-05596A95C4A9.ref@yahoo.com> X-Rspamd-Queue-Id: 4JZxPL1pp7z3n5N X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="a2w8cQK/"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.10 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.68)[-0.685]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.917]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.146:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N # zpool status -x all pools are healthy /usr/main-src/sys/contrib/openzfs/module/nvpair/nvpair.c:3129:49: = runtime error: applying non-zero offset 4 to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/sys/contrib/openzfs/module/nvpair/nvpair.c:3129:49 in=20 For reference (some manual line splitting): # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ branch: main merge-base: a3522837b021a46f2de81303247599ea51163d13 merge-base: CommitDate: 2022-01-04 03:39:24 +0000 a3522837b021 (HEAD -> main, freebsd/main, freebsd/HEAD) ipfilter = userland: Fix branch mismerge n252196 (--first-parent --count for merge-base) # uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #29 main-n252196-a3522837b021-dirty: Mon Jan 3 22:17:33 PST 2022 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400046 1400046 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 14 10:32:36 2022 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 CB9F4195A3D1 for ; Fri, 14 Jan 2022 10:32:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZyL8045Fz4ZtT for ; Fri, 14 Jan 2022 10:32:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642156360; bh=9vZAHGTP/a6yTN8ovxvPl4t4jIrni+c4U/yEpT3g9gA=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=qlDDMvqlGY2EI3QjzjmRHXXuhNGaluvnDEvCIcNEYo+VGWL0iEmdun1Pbk1NuOaS+0pDvMD0f0VhDF4eW0502RM5ejZtVL8M9oHWfAPRHg5ysoUQT5/b9pjDX2TvwVByxltzzYNBLUCQyEFpo+ZmzXJOIyDNqvqTxQccHioHjB6EkUa5gFbRS62kX2JaM9gxpK1ZbvQujgeSczplCHItA1hZBz6ebZOxNFpxs33kdCDlIiHAQl5KC96CmRAyk08UiuMfH17WwXInt/jG+BbbyvMPmjwz3Q3x7eiSr2C5CFnjJYEcHaWHLU0x8JrPp8f9SGrhCcjpYDAqj39K1luGkA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642156360; bh=PgGo/uPjAfuq49VbZLRf2wcoNCcUsM1nFRy9+cCHwb5=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=PcxIxug6Mz96J6EbZLyeKJmg0btPJRIA4pmKCL6UVvXuU71Cv30IvE8nd680hEMMnRjOPV/P+j2VJVimVnjdwwiGCIO6JKoM09OwlkYw7l/Hyt82Ukp9aXSO9dQH1aZwsv3Qn2197PpAFMuAEMqaqoDxfEoFqMqR0QeF1pJLwyFSYzp3xNRrhEDALvCYlrcIa8Y3Vu3VPfF2pp6bbXpmYyIP+Cozzw7nUEmGO9/nFvkjvEniDZzJh0BzbtZGCnGtFa1bcB9Vuif+tgEN1/2gSgwkHRG7vEwY+NCFJqkA2FW5ByLi3Mba2cak/uD68zFhivTXOjpQpGqrwhcx7fzk+g== X-YMail-OSG: DFQFPpIVM1m86.qmFVY_mmGot3bqZfDPSXfflgYvr7JHAx5Ut1rLuD.VtnBRQnK kLfpy_1eE.Oys4HJ7lQh20fqdLn6bWJOjQ_unpcIePuQUwpsGECYuJvfN5eLG6a9D0FmTFNmceiM QNMj7b1wxUJRtXOMWGjwLSZ7Kv7bPbnjQQGhGQjvyLVWPiJvTOPwDDVrlRrvrNvVy00h6ILO9Cp8 AvffZAPKFYrKQKPF.y0sKBiwUZbpsfYiMJZwTXx_PGxsjct_PWHmHvXsjqdg7Ve0q4qHgQ.lE3ZO UlpeIFiGlfX4d7qNget_9FJePo.EpcaCLQ6_530jiEU1_AQesP0.KR56Wx_CbEqwVvgfCcme2zBG ClFcsbcTlcpkj4RjJSmJ0h6EcI5klg7Pieop4UzKL8EsD8zg8W.LGVYU._H6cNnC8KfU7RV30CSR hFoy7eD85xdok6OWPnwwRial2HzNv_mbrMEQNUfPFpbne0DO4jSUvb5p5lVNbFXDgTBU9gQTcerS GZu2UEdPPYgSv7GqSKV691hCY2HCDKhYDfMIg4QYNBP.YbFSV6wr90w70EhbjIowEbSoxPIxxWWG 1a.3OXKqy7eUZFTkA.TQTT2mdQO84kVsDM3v3hAc811p72kc0fh5tcg349Iz.UyjPfdTkxm0XuVy bnJsMEy_._61weNzbRAF7HMXhZNZIiqo4AJii6W9cDnFj0RFxBCUW_DD9ejgnkayi7WLfNl7QAJL 6BFC7oF47SzJZCL1ixRgNvSs7pTvhZsRdCwpqx30vaMKbNq0yOdXNoZI8BI7sp7NfuihEp2F2STs btVgWEVRcUDHL9OjVdqj6XxjW49X61.hP1quEQRNWsg5MEO2LwJXC6nf3Cxr0u6pvdo.6HkRZvF6 Zi.igl0bRB5aymqBOjGkmTS0D53yfxjiFXgddwM.o8ORwDatFZBf3lSa50mUelqhjnBEFfNeYNR2 GwIIwaYFQT8f8eROq_Ik.6_lGytFcAQS_JXn0IR.p4k4V2y9kHRrVc4PS4SmTeq_nWxT9SIbJoX0 FEhqGLrtgiVMav6Ad.SpxejKNGqfX3LXkoiIcpDLDvUl6N_26FwWzFC7hjD0Nl_gz.2JUsBU8mIN OcDeTO7HVMpmU1IRmuftsaJNh6pf84eQNYRFlTGdUhZ.ElRILAcQ1a6AlkhzjBb6l0.rzvVMT_Uj 3lvox3ewKSu7sp2tD0MXcfund5pwVQgUhm9lxF9oL5r41_MsikHhBKBEoKV12Qyl2srg_L8ppaIZ YkxxFIoOqqhHOpq9kg9pcqllqT_a01XE3mDA.ZBCtJtLmkXEFswjXPbcApMzDiQxFAce83.kqT1U u8LlAyRcMYDq_QFkt9lTkeKnEH.3IxJcsy0mJffY3PlaJKzDt.30PizSZ7oJZMTqRCZix8QIbXy5 Lpe1EmparPjYMdI0c9TVrc6E.sS7CumQmyEp.nOLN2tr02dqxI3XnfuleFw_oatOy80I_K9edDyV 8cwzJNN7I.PJvh_rx8QhkyVyar.m2SxZ05M20gMj_feZTsEv5yRhWxi70CLBWmrJxTZXw7irwkpG 9DNrgohMejOlrsWb2fEFbO7YifIVoQyiGqa.T.MT4BJGICbs9LMfquhYYaq8mFxiIWw142gnFy4Q Kq8fu039_aZncdUBhmSx1PTwjCWRx_GZQANivQqjb6tvVMyZ60BFCIju34O_I_u.w7JFG7t.msRp uJzovC8Iojyd7FLt9R65Hb8KAiDTD7WNNKYRR9P.Kh4PhTFEEUVJW_3vUF84N0MAh3qr0GfnCm3A NGsJU7Dg6_GGaVxwosAmUZViJuQhh57Cv82aPoKxG4IkDcaSEY6xTBR6YJol76zuKeSriiN5Spp. FQivoqxjcuE3pxEAKN.rlhLfksBjFD7q5JE7hL9shfZSgJX6JkVdouyu4bdjGX8KY.PGGX7PP7BO SsxUPWsTSPRAFBtHghxmY4KeEVqNaMcN8j5.zM7JfaiL3k9dFIcZy1irgbSUecKUH50oo6Mb_J_C Iz3vj1s7hjxOXDD2g5oHV2LQD8kGR2LVdoK4ng4F3ljG3cVPSGSvAxkXPNqR0psxQGY1jqn5JVEg 24zbzQf.V54Hy155yWhjtf98nJpluLOhItqTUQw1iFkx0u59AnPyZg5YrJomrl_YJTZng2aXEZJM bYZ1mwKd.VtcznFfUOZX5lNae1Nb5TM1ctxPiCcwF3_KoEqr5D6wLLOTHD6MroUObEsMU8Sb0ONX 6FuMswed3PmbIuCf1hrXWi0H04wZ1Ai6_N08vPv80W4CGHYlRExDLp_Gcqzb7Frn2baGRHGFPbdQ - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Jan 2022 10:32:40 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dfbeb349e2898331d57fbe153f93d493; Fri, 14 Jan 2022 10:32:38 +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 14.0 \(3654.120.0.1.13\)) Subject: ASAN&UBSAN world in chroot tree, ports built previously, variable results finding /usr/local/lib/*.so* files Message-Id: <92820E0F-7733-463D-9383-EBFD0C285E05@yahoo.com> Date: Fri, 14 Jan 2022 02:32:36 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <92820E0F-7733-463D-9383-EBFD0C285E05.ref@yahoo.com> X-Rspamd-Queue-Id: 4JZyL8045Fz4ZtT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qlDDMvql; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Note: like the /usr/local/lib/*.so* files, the wget and git were built previously to the existence of the ASAN&UBSAN world. chrooted into the world I built with ASAN and UBSAN: # ldd `which wget` /usr/local/bin/wget: libintl.so.8 =3D> /usr/local/lib/libintl.so.8 (0x800edc000) libunistring.so.2 =3D> /usr/local/lib/libunistring.so.2 = (0x80182b000) libidn2.so.0 =3D> /usr/local/lib/libidn2.so.0 (0x801b76000) libssl.so.111 =3D> /usr/lib/libssl.so.111 (0x80229d000) libcrypto.so.111 =3D> /lib/libcrypto.so.111 (0x803a00000) libdl.so.1 =3D> /usr/lib/libdl.so.1 (0x8034ed000) libz.so.6 =3D> /lib/libz.so.6 (0x80585d000) libc.so.7 =3D> /lib/libc.so.7 (0x806e00000) libthr.so.3 =3D> /lib/libthr.so.3 (0x8063fc000) # ldd `which git` /usr/local/bin/git: libpcre2-8.so.0 =3D> not found (0) libz.so.6 =3D> /lib/libz.so.6 (0x801bc5000) libintl.so.8 =3D> not found (0) libthr.so.3 =3D> /lib/libthr.so.3 (0x8009ab000) libc.so.7 =3D> /lib/libc.so.7 (0x804000000) Note the differing results for finding libintl.so.8 . The ldd and which runs get no ASAN reports and no UBSAN reports. SIDE NOTE I will note that attempting to use the wget results in: # wget ld-elf.so.1: /usr/lib/libssl.so.111: Undefined symbol = "__asan_option_detect_stack_use_after_return" END SIDE NOTE Instead chrooted into my normal world built for chrooting into main (no ASAN/UBSAN involvement): % ldd `which wget` /usr/local/bin/wget: libintl.so.8 =3D> /usr/local/lib/libintl.so.8 (0x8022a3000) libunistring.so.2 =3D> /usr/local/lib/libunistring.so.2 = (0x801c69000) libidn2.so.0 =3D> /usr/local/lib/libidn2.so.0 (0x803227000) libssl.so.111 =3D> /usr/lib/libssl.so.111 (0x80372d000) libcrypto.so.111 =3D> /lib/libcrypto.so.111 (0x803a37000) libdl.so.1 =3D> /usr/lib/libdl.so.1 (0x805668000) libz.so.6 =3D> /lib/libz.so.6 (0x804618000) libc.so.7 =3D> /lib/libc.so.7 (0x806aca000) libthr.so.3 =3D> /lib/libthr.so.3 (0x80468a000) % ldd `which git` /usr/local/bin/git: libpcre2-8.so.0 =3D> /usr/local/lib/libpcre2-8.so.0 = (0x801b2d000) libz.so.6 =3D> /lib/libz.so.6 (0x801324000) libintl.so.8 =3D> /usr/local/lib/libintl.so.8 (0x801fe8000) libthr.so.3 =3D> /lib/libthr.so.3 (0x802ed9000) libc.so.7 =3D> /lib/libc.so.7 (0x803d98000) Note that both libintl.so.8 and libintl.so.8 were found, as expected. (wget and git both run just fine as well.) It is the same /usr/local/ file system, used from the two contexts (mounted into the chroot trees). It appears that lots of ports from that /usr/local/ tree get "Shared object not found" messages for one or more /usr/local/lib/*.so* files (matching up with ldd reports of not found). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 14 11:07:32 2022 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 75DCA194AC49 for ; Fri, 14 Jan 2022 11:07:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZz6W3jXKz4rFP for ; Fri, 14 Jan 2022 11:07:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642158460; bh=BgWXOiK+bQ2e6LU3n1xmUfeWPLy0FYP9h12PIdzYRDQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=eyOcI3Sj4KDAmy5kAdfS2w0chM80YQv6CzgmxnqFwapPwGVT5n8yII34zB0zVIcaod+hUifAxM4j2CeFWAk7/Mh2tZxK5F18fY7R6tMrhso+3XWFwGSGUdGPN6AtEyDR91R4Wgt+65FvbDC/IyePcxYJGibcXVgviHz5MYblFquI8+xCJrkf/Mm9B+w6ZrzAhOPT3uR9clG1385WJ82eozJdNhzSaoKXXQ5IB5DjRwJwAytXq5anHxSC4mAqVO/KuRYm2Lg4ztqtEbfkJJGC8nG+d/9ciD05cF8iVasJZAsq92DFfAxhrt8UqnCQmDEjMzH8UFDw55vVsUi81bGVNQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642158460; bh=pwLw5m4u3MFWdXAONxCHX5Us38hQSZhXnjfqH0tHzTu=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=UGcnfuP4ejDg7iZwPn7FC/MCxqsMGde24oh+NkS4qjWr5C7ci+l1xNLzBM/IlKkpnRqj4IqkTz9sDosd8YV7lSd+RjzdtxA4YOVFDDP++NUpioDfJdqmb8oPDE8eWzE54+PS+TMITabFbkkQXQquFip17WO8TL88ulFIOM/KhxinHmxghc5oSZKUqouvl85WpGkDnBG9jbUM599PRwpf/lAQ1bCNsd1RN94BgGkg/TvyVtI8dN1Lp4C5aZyXwZuN4LrZevPmotZI7Nj60jlgUGnGvpZxmdu+dTNsK9jXF1L/neAQZugpH6isqu2ES4i9Wg7ozvodIrOXr2UiI042Ug== X-YMail-OSG: lzqrYUMVM1k5u1a9kl.domh7on.qEwJ7eizr68qRpJz5NetIFNRYvHBlz46Yfi3 JmHkLTCFeWqg7aXbq2dh1RhqObeIvhe_4_5JHPija0uXeXe0V3jKRNoX.grwdnqLlqzNRVOAxXIH r2EbOhlcb9t_wyuMaJSUs9x68gWkuhYAZE2XOPcIfW4OuDSab9NkPH91GXdpx.Wbls.wx_LAOeMv .liwXNPRkfYSOJZRw__69tnbyVDaGF5SWwHFR4uS8vG_a37N._F4KYhml2yERCJxr9l9Z_tdMhc_ dhLMXZ3UnmXJu..XDbkrUZpOuS5E9LQMofErMRTIVQBZeBtwIaiC9eR3LHMqog_aBCzsFt0fPh35 6JtGfA7seetagEm5oO2bwlhZvFCYAB_IUU3hUoAdUYEYk5zvHo6UZKVj6fZ4m.EhmGYFx0_wbS33 EDn9GlzV80.Bx5llKCZNemyIYtb4yuj6wclGF42yVyJhGPFwoPiLDKRP2VwYfpbJPUUnlVKwWkfx XY7MnAhHhwF0vHXPo157TNiLLtx3hUzKAr8KpX8c.oKeQ0U1I54FZ.k7Vx4Gbr26AwYpeC9UuTzS cojccpfXm2fWiY_gM_QYPaY8sL1XPu1pcy8btZrfRaOaH4f.S3DaD4HuhGykA3osCNU6iXH2NQU6 Umj3FuOjwjEC_xXIVHzVN9UWatjtKQzXqSUqf2lHO12hS7QLW5oCyFARHH8XGqdxiTs81FRTub4e jptP_8jOT_i.c1oQMsZQgAxCorjX1xG.ui54fj72U00UBP6am9_bmQi4rRwbQ9a6796WuvaeLuYK fSxAAr0VU36FexW_bNUHc78Gkdj7QL6ZOGUva4UyAqQiOhodDtmcLve0m4BoiUyI04CvcdIxv7Pm Brar6XxG.qFOmzf2UDE9NzaCU8_4NCwZFWEw28PUPAlF_xpH.itib4dmGb6Z32wWwmaBgg95mkFI 5_hEDx9J_pzpWkbINibMHntWfmJxgqRMtXlORtL6Cb6roN7eBSVJRHaXe6ddMuOuGjrH5mGRNkWP 2b62a4rXyChKBLzoljWwSC4qapkHLf5rzFn5oejeDPDuj.PCPl6gOZwYgQ.jFwkt0Bzcmkgrg8sa IeZbScSldLxAx1q7YhbuISJZePa2ZKXyfFaYTPeU3QWsoY_Pwst5l4rAWc._gan_HpETXT0P4heE wWa4U7El3amOSR6GB33n9awt0tcmQ07PHBLRBeyK0ylbn0G3daCFwbE..8FrFSkjOo69v9ZZ8fRp dtGpLjKWJ7tj4u7JalDtuFDenxKo7fkQZYv_Bcsm2wUXBbvImaFfTEpPlAmHxU_J7SLk47SuB6O4 zjgp765IEqhhQ4roA5wCKSXySWno6QQBgwEuw0A2N4Ypduq7TZVf0wxMlm80I8ePqqOySxhNtzka axI2Msd2HgIG34MfZ3TDLXq7Ipkk5GrLErBjtxvearUYJmduf8W33Pnv.TX38f17oBcUNnvw2m5f QngAErY0aewC1APla2w8K5PMG9wLxGj1GcADZS_0voU4bSx854n_H10fMrA15m35hvpHsYwsB2rB IrdNwY1mgoqHny0bM_sKovprnii1uVsXoyJ7MsSWHZ6Of9ItFKPb4IagjybxPy8c5IjAenTrpYkA 1HkDs_FNWU.hBbN19lMxB7oy2GAxckWyx3Rt_R2KwJ3NWRqDhC5B5cVuV3X.C2rigO_wOPnokih6 1vkpg4wzRs3HZiF8U6PfGsrd95BpXx4DGyAyNJZqXMAZ0mQyT7WAzs92Z9NmftIl.uDPxDykVq2r p3QIy.gTX_rkmbHnZ7ENralG8hbiTemXrK5LN2l0K_3HzRnWPw49XRgSByP1ABOGsazqej5db67z 6OACgrn.W6cPGkCLslWT_yvqErm8xIIaL47Pwx6I1mtOdMSEWj8zXlaj_E5Vjm4rscc89fAv5juG alEn3oKLml3CKKm4ixDSW8OnambWwzirFxfhaXhZt4gOjFSvRWT1_pTHmkWaQ6dQyx9TC04ELpvU m0cnfm4c_zuZYNMQ2HQwzu5Qh4rJuwg45dNbV8fEP9K9DA7acHKwhkPpRdg0pxeaTmJMJWXkCE43 59YPrcvY47z8MaiNzMRLmLzymDxlZvPXOvNT6nspwG88dgeAurM3S1a5crHRfibuPEOYCoz0IW6o gk8gIHjqgj65MxsQq7r4z8ZeUKf6nMICTaOnqMVoqcGznmWFLZjBzGeKfxv.Z7aQ5u0AyQS9leBg DVabnciD79qakFwiE2O1Odw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Jan 2022 11:07:40 +0000 Received: by kubenode500.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 17f25a25cfceab68cd9b536210ba3e5a; Fri, 14 Jan 2022 11:07:34 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: UBSAN report for main [so: 14] zpool status -x : applying non-zero offset 4 to null pointer Date: Fri, 14 Jan 2022 03:07:32 -0800 References: <62A093FB-BC32-42F7-B54B-05596A95C4A9@yahoo.com> To: freebsd-current In-Reply-To: <62A093FB-BC32-42F7-B54B-05596A95C4A9@yahoo.com> Message-Id: <077AAF38-04D6-4986-83C8-A401E6A9A57C@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JZz6W3jXKz4rFP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=eyOcI3Sj; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.205:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.205:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-14, at 01:50, Mark Millard wrote: > # zpool status -x > all pools are healthy > /usr/main-src/sys/contrib/openzfs/module/nvpair/nvpair.c:3129:49: = runtime error: applying non-zero offset 4 to null pointer > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/sys/contrib/openzfs/module/nvpair/nvpair.c:3129:49 in=20 >=20 >=20 > For reference (some manual line splitting): >=20 > # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ > branch: main > merge-base: a3522837b021a46f2de81303247599ea51163d13 > merge-base: CommitDate: 2022-01-04 03:39:24 +0000 > a3522837b021 (HEAD -> main, freebsd/main, freebsd/HEAD) ipfilter = userland: Fix branch mismerge > n252196 (--first-parent --count for merge-base) >=20 > # uname -apKU > FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #29 > main-n252196-a3522837b021-dirty: Mon Jan 3 22:17:33 PST 2022 > = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG > amd64 amd64 1400046 1400046 I was able to do the following to give some internal context for the report: # env ASAN_OPTIONS=3Ddetect_container_overflow=3D0 lldb `which zpool` (lldb) target create "/sbin/zpool" Current executable set to '/sbin/zpool' (x86_64). (lldb) run status Process 95471 launched: '/sbin/zpool' (x86_64) pool: zoptb state: ONLINE scan: scrub repaired 0B in 00:00:51 with 0 errors on Sun Oct 31 = 21:48:04 2021 config: NAME STATE READ WRITE CKSUM zoptb ONLINE 0 0 0 nvd2p3 ONLINE 0 0 0 errors: No known data errors Process 95471 stopped * thread #1, name =3D 'zpool', stop reason =3D Nullptr with nonzero = offset frame #0: 0x000000000112fca0 zpool`::__ubsan_on_report() at = ubsan_monitor.cpp:39 36 } 37 =09 38 SANITIZER_WEAK_DEFAULT_IMPL -> 39 void __ubsan::__ubsan_on_report(void) {} 40 =09 41 void __ubsan::__ubsan_get_current_report_data(const char = **OutIssueKind, 42 const char = **OutMessage, (lldb) bt * thread #1, name =3D 'zpool', stop reason =3D Nullptr with nonzero = offset * frame #0: 0x000000000112fca0 zpool`::__ubsan_on_report() at = ubsan_monitor.cpp:39 frame #1: 0x000000000112a461 = zpool`__ubsan::Diag::~Diag(this=3D0x00007fffffffae50) at = ubsan_diag.cpp:354:29 frame #2: 0x000000000112f394 = zpool`handlePointerOverflowImpl(Data=3D, = Base=3D, Result=3D, = Opts=3D(FromUnrecoverableHandler =3D false, pc =3D 34378976794, bp =3D = 140737488335024)) at ubsan_diag.h:0:21 frame #3: 0x000000000112eeca = zpool`::__ubsan_handle_pointer_overflow(Data=3D, = Base=3D, Result=3D) at = ubsan_handlers.cpp:815:3 frame #4: 0x0000000801258e1a libnvpair.so.2`nvlist_common [inlined] = nvs_native(nvs=3D0x00007fffffffb170, nvl=3D0x0000603000000160, = buf=3D0x0000000000000000, buflen=3D0x00007fffffffb2c0) at = nvpair.c:3129:49 frame #5: 0x0000000801258dba = libnvpair.so.2`nvlist_common(nvl=3D, buf=3D, = buflen=3D0x00007fffffffb2c0, encoding=3D, = nvs_op=3D) at nvpair.c:2656:9 frame #6: 0x00000008014135ba = libzfs.so.4`zcmd_write_nvlist_com(hdl=3D, = outnv=3D, outlen=3D, nvl=3D0x0000603000000160) = at libzfs_util.c:1204:2 frame #7: 0x00000008013e0000 = libzfs.so.4`zpool_log_history(hdl=3D0x000061d000000080, message=3D"zpool = status") at libzfs_pool.c:4444:8 frame #8: 0x000000000113770c zpool`main(argc=3D, = argv=3D) at zpool_main.c:10986:10 frame #9: 0x00000000010ada2d zpool`_start(ap=3D, = cleanup=3D) at crt1_c.c:73:7 (lldb) up 4 frame #4: 0x0000000801258e1a libnvpair.so.2`nvlist_common [inlined] = nvs_native(nvs=3D0x00007fffffffb170, nvl=3D0x0000603000000160, = buf=3D0x0000000000000000, buflen=3D0x00007fffffffb2c0) at = nvpair.c:3129:49 3126=09 3127 nvs->nvs_ops =3D &nvs_native_ops; 3128=09 -> 3129 if ((err =3D nvs_native_create(nvs, &native, buf + = sizeof (nvs_header_t), 3130 *buflen - sizeof (nvs_header_t))) !=3D 0) 3131 return (err); 3132=09 (lldb) up 1 frame #5: 0x0000000801258dba = libnvpair.so.2`nvlist_common(nvl=3D, buf=3D, = buflen=3D0x00007fffffffb2c0, encoding=3D, = nvs_op=3D) at nvpair.c:2656:9 2653 */ 2654 if (nvl_endian !=3D host_endian) 2655 return (ENOTSUP); -> 2656 err =3D nvs_native(&nvs, nvl, buf, buflen); 2657 break; 2658 case NV_ENCODE_XDR: 2659 err =3D nvs_xdr(&nvs, nvl, buf, buflen); (lldb) up 1 frame #6: 0x00000008014135ba = libzfs.so.4`zcmd_write_nvlist_com(hdl=3D, = outnv=3D, outlen=3D, nvl=3D0x0000603000000160) = at libzfs_util.c:1204:2 1201 char *packed; 1202 size_t len; 1203=09 -> 1204 verify(nvlist_size(nvl, &len, NV_ENCODE_NATIVE) =3D=3D = 0); 1205=09 1206 if ((packed =3D zfs_alloc(hdl, len)) =3D=3D NULL) 1207 return (-1); (lldb) up 1 frame #7: 0x00000008013e0000 = libzfs.so.4`zpool_log_history(hdl=3D0x000061d000000080, message=3D"zpool = status") at libzfs_pool.c:4444:8 4441=09 4442 args =3D fnvlist_alloc(); 4443 fnvlist_add_string(args, "message", message); -> 4444 err =3D zcmd_write_src_nvlist(hdl, &zc, args); 4445 if (err =3D=3D 0) 4446 err =3D zfs_ioctl(hdl, ZFS_IOC_LOG_HISTORY, = &zc); 4447 nvlist_free(args); (lldb) up 1 frame #8: 0x000000000113770c zpool`main(argc=3D, = argv=3D) at zpool_main.c:10986:10 10983 free(newargv); 10984=09 10985 if (ret =3D=3D 0 && log_history) -> 10986 (void) zpool_log_history(g_zfs, = history_str); 10987=09 10988 libzfs_fini(g_zfs); 10989=09 (lldb) up 1 frame #9: 0x00000000010ada2d zpool`_start(ap=3D, = cleanup=3D) at crt1_c.c:73:7 70 #endif 71 =09 72 handle_static_init(argc, argv, env); -> 73 exit(main(argc, argv, env)); 74 } =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 14 12:44:36 2022 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 9830619418B9 for ; Fri, 14 Jan 2022 12:44:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jb1GS1xygz4WcD for ; Fri, 14 Jan 2022 12:44:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642164280; bh=C2R3zBH7NQ+2EGTt+JIUizDrJxIZCx9sH0z65TVHTDE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=nrWNfZE2SNqaucfhjNxuwcBQVQeiaMBhkcB09eUJgg82hIZSQ7n2aR+eBUfJS6lu52tnZJcw7xQ1vK6gVFRHgst2tfvpHcs3Rhn7q1lKITeEHqKVUjLrakfdd+/GCaFYfIJM549N2N2qT1HeFRs8aC5F8qo322SbcgB5gimIzDl9O2zji42eB43zcAd8lMOUPBRMJu89bVB8h8HZOJfHuGSOdtS8kfkNv2rYxFJZM4PPdYPztmRWbvwOcQOPjQZeF9QGxsRzjxyseirVbotnaggu4KC0g9y6ZvD7VRkvbM44oUD2FCVv4zm//66mgmFiolZO8TYNFcWrliMXrUpOVQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642164280; bh=DI1AydocNfa4ksL8SGLujm21c0VdSsHPgnjcE95Pn1d=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=B6pmPUThQ5rtF5Fs4DzyJqeu7tC2QnhDHfU8XdqmNf2Of4CXdW05qhPU6lN1Gz0sJHYhMqh9V99Idv9lh9iz8GGaxW4RQJeeprgcO/XbOJ+2yXBtZf3Eavqz1dixjxEeEwUcX0r5ZBhG/OGIEKRZIve1L8X91FHthnpNA9D1mVEC9S1JfitcwVT3eMVmnx6hg13apCqREiaTD5lIw7NS/IGKhHfkLDR8K5kGUTAGaAKNc3OkOx+RS27Go6Juiqz4ovIlPLiSTi3ZhTmoyxmWAvoApxHLRngwp1x3hRWRnMWIpb15uflXAeP7iD1FDi8Rbni/c/lsobmANpZtiMPpTQ== X-YMail-OSG: vyZcL8kVM1lO_zDwsp3IJWq0GuZpVUCC7Wxjx0pxxksneqMZjxYbErieGKk4ENR yAXBpTZJ1yMLbZuKpS_diYlVTC5T3zKUtEaRw0wjKGgIqIqXS9KgmaeLpH_J5_0rTvvqhQjz0DwD Ctt8mnSTNbMt_3kKR4.1xQgN_gIsdiPRVYoG2H.6xyxsU.Yf717XmOHYeRi3SBW1xSolDMvVu5cS pg5BO4kob5DnND3SlaiCenjWDZcKlqYXvg87hybNYCicqQ1dNuT8V2JlipUjBhMpR.2XKta4ZcP9 Nk54LBHuzb.ghAjLPU.SVrjlSCBB.txN7inOQJJBkFK6QandYOSyZEGoWB8RYkqM6rYHD.ik5iNy V7_VMitcwB3AQniRbSxXM_SDRYtpnaP_fHL1OWYYEq9eU5NR9xXO0VqO1kA5Rf0T_NDqyY0qTEFn 2AI0d0MjxXP3Dzh6W07FZihUfkClaHgpOfiIMyDj8mOP7fgjR_ZarQh3Yhse__git345_t4f7KjG uecud0dHPI.EmOQf8c3MODPfRdB5bBHsePx49O8iQLSy49U8ACOeETjzclR__AoIfzi2eDCWCnEW vRvWnuzHQVeRYaAMczF9nptd43aXVibQihhQxMAMLArzcLO2V6ORs6CntvtyvoykTcVS6wTAyQKy rnVbmWSOOUotRq7e3wNvoQElBjboqFG.LIPDOtuTdEuMRlnXEaCYjg940NH.jTBypTB0OpekOUSC wYjoaahszxvIVZo4Hb0yIaALS8VYRbfTtAyuwgN2bMb6kF3LKeGnUOglUXSABcOxJIvPCS4c.lMQ s.CFLP14Zg5jcpGm70j1xsVLEHP_hkLj6zTrxUbqreYQsZlaNXexcdW16FnGt_clM3sxYrf9JurT 2jLI4UKxNNllFRD1OkNn8w7Violxc0Le_Ckdg7pQMw459rgXbhymdKZLJVGI_wTYBSqqDMTDdKOa xm8w7Fz5a71_AmC_ZjZw1WEjmYSuY8CQsHAHEarIG.9Pgq0p40wUR9U0mKwc5yGOGCfwHCNsTZC6 U0Vl9W3chO5Pw9gfHY6Z8NSIceH3pbhOvmf.K9XHDikh45K5lAJvEqJ.BJl1Hc7TzA2bM_ntnVSq 0pVUB8i.N35.WH8t9IsCMn5MkxvbJOleybN2O.LUQocXyOcHfgdrMz8PluFlAh9Ch51lXMzwJj7A 9yxGhF3iQDvTrQB3qYXuI4F3ZByblR7WtkKSut4onfWUkiEgBMRAdvCeK_slAo0EKwOKzXWocAxh 2vRkVCAh_gmrugHSgB8DW646WBbN2gVs0C.RcM1EB7nnul0ng9zc9SiDIpz71n.cC0zpgfGYXBGO 2qtauTmMl2jvM2mnkSR_evGnCkycpYQRy0ZkSya3F81ing3WXhI6xDm56FQ3h6A5yR9yhrej9nQl CozierzFe__zLrLi7tu0hFWOXDbD1K5Yf0hoz1VZc0Z.ue3RKBEkgbVgEfEhL8Ir96_o_SZHiZTH 3UVxQlcVAflNMggEa2Vbyvf416k9GRvAGZzFkz4aW2ha6CnJSeZRtKLbX.0RpUWmlL1NdFHXklaM rBnBV5_g7rPnKRXSosyG5EXOrulwEXWAh2wlOz0mgmgm5lgnJm7S6QeDDyMlosfWyK0sM9pJWAf4 TevjX.pUZcHh058U2EZ8MsafpoGSUjD.D3Q02wRpurqW3J96d3OcuI5RMmiCVSIYdnya4ng_KHuS kEhkhljHijppw5bny0TjeP6CXSMvNKnLcV9pT6HzWJYgwnVE10oNZtbsO5wReLfnFgopY4gqmBvP IKDrVGRDx6v.6v20BO6Q5eWjjz7bJJeIsYjUDTDJqqJvj6alnhOq5zpTjwfwIEQGhFgYpPBH9NEy UV5rXYw5th.s5W.5.BRC5aSf2rmUmGNxRf7tZSlBZUkLm4yIK2aHWjEQDvH5Dxd6K.7c3dcjXUDL dEVTJ3_aR5ZYRDaslyQlWQxHiOXNdtWCtDx431IJnt_kTZamJ4N0C5vX.5XvNYoD7VWa9eRHhy_0 zzgIfZQTBKxreVTUPF2I.M1BEHknr1LTQC_QlY11t4AwBlyuYYlWeQ8bi.vG04P8shBcqPF4WwPq Nfz9zQkBlAfrgk71Ut5pj2PssoehveKJzr8ubgzoX1BQWf2C7ettuT72PpAJbU302SVh5CohanC5 C.LNH05bap2tSNsEVLnESO16P3TJnwKOKhQEwAbLL2Jwl6KPC.db2.vNKOPFKl6SjGFls6pIRhnC pxPiUxelxZ4kwC.25DKoGXETgLMBcC8FlnH4oen8HGGXsyDTirD5AREtC7H1aT4JjzKhldCyRXa8 - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Jan 2022 12:44:40 +0000 Received: by kubenode521.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9121485339796eccfdd38e3492301fd9; Fri, 14 Jan 2022 12:44:36 +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 14.0 \(3654.120.0.1.13\)) Subject: An explanation of some "Container overflow" ASAN reports Message-Id: <22B11810-DB3F-4E81-AB40-ED207CD83EEE@yahoo.com> Date: Fri, 14 Jan 2022 04:44:36 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <22B11810-DB3F-4E81-AB40-ED207CD83EEE.ref@yahoo.com> X-Rspamd-Queue-Id: 4Jb1GS1xygz4WcD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nrWNfZE2; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Looks like libc++ does the following sort of thing (from lldb list): . . . 1635=09 1636 template 1637 template 1638 void 1639 #ifndef _LIBCPP_CXX03_LANG (lldb)=20 1640 vector<_Tp, _Allocator>::__push_back_slow_path(_Up&& __x) 1641 #else 1642 vector<_Tp, _Allocator>::__push_back_slow_path(_Up& __x) 1643 #endif 1644 { 1645 allocator_type& __a =3D this->__alloc(); 1646 __split_buffer = __v(__recommend(size() + 1), size(), __a); 1647 // __v.push_back(_VSTD::forward<_Up>(__x)); 1648 __alloc_traits::construct(__a, = _VSTD::__to_address(__v.__end_), _VSTD::forward<_Up>(__x)); 1649 __v.__end_++; (lldb)=20 1650 __swap_out_circular_buffer(__v); 1651 } . . . (the bt points to 1650) . . . 1648 constructs into __v at __v.__end_ and 1649 then corrects __v.__end_ to cause the constructed object to no longer be an example of "Container overflow" but now in the Container. (At least that is my interpretation.) The compiler's code generation may move the detailed place where __v.__end_++ happens relative to some other of the activity but the compiler has been told an order relative to the construction that would lead to writing memory in the capacity of the container __v but outside the size of the __v container at the time. For reference: 970 template 971 void 972 vector<_Tp, = _Allocator>::__swap_out_circular_buffer(__split_buffer& __v) 973 { 974 =09 975 __annotate_delete(); 976 = _VSTD::__construct_backward_with_exception_guarantees(this->__alloc(), = this->__begin_, this->__end_, __v.__begin_); 977 _VSTD::swap(this->__begin_, __v.__begin_); 978 _VSTD::swap(this->__end_, __v.__end_); 979 _VSTD::swap(this->__end_cap(), __v.__end_cap()); (lldb)=20 980 __v.__first_ =3D __v.__begin_; 981 __annotate_new(size()); 982 __invalidate_all_iterators(); 983 } . . . (the bt for this points to 976) . . . This suggests to me that using some equivalent of: env ASAN_OPTIONS=3Ddetect_container_overflow=3D0 my be required fairly generally when libc++ can be involved. Other notes . . . I used ld -v as an example for the above via: env ASAN_OPTIONS=3Ddetect_container_overflow=3D0 lldb ld and used: (lldb) env ASAN_OPTIONS=3D (lldb) run -v in order to have ld itself not have detect_container_overflow disabled. lldb suffers the libc++ Container overflow problems via its libc++ use and fails to operate without the: ASAN_OPTIONS=3Ddetect_container_overflow=3D0 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 14 13:17:52 2022 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 7D8FD19595D2 for ; Fri, 14 Jan 2022 13:18:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jb20w2kpNz4ngp for ; Fri, 14 Jan 2022 13:18:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642166281; bh=Kog/N5JRBZhbfEIWsKfgkyYbBDfMmWdJ1UXGBD1ggIs=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=HD1hesAp1GKeCE8BruN6jTRkLf/ZZrYhgxn5YYkBd7MTJhpFHnZTjmL1x82R2iqVP/NWKReW5T9IBk1kg3qx6SrlcVygYY2ougrRsZovwxCY74EKgYygShkJOInk5WLjUmz9qGyW6f47ziJoyleU7UiZeZOi4NiOpYqcSMbLv/KdupYe66s+ONo+gzLmMK7kYe0bT2z0kY4mFp9V4BVbwDdE0ZmMs/MElif4qNhAiq1gspgAlS3iOmKsDTMHfip+eDsZHXyJk1PaAbhokpXl0ojlGqM4XIzHtZMh8H+qMQHBHb8LRx5LDgMZbq+bzr7DZ4whOYRherBXVjLIBKvzPw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642166281; bh=vAgm7gth+Y6JXAiHtKERRxJ9ivCszyUgn/UYrl+06tJ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Kh8h75TNqi0L8O77eTwO8o857UorcZck3I9goH3SPx1BEswaWX7ydRI6AiYHRb6RpRodwXNRv1mzgHVjRy2NKrfGqyXGQbNjHe7jDJWzaff7hkNNkx+/uxslrT7OiJzGU36hYyduvWC/bA5EH+BLtkbkwGK+rTbTCbPNLIBBJCgdAmeMMBvbLbW2SKKsDyfW+BuINPNm1iHl51jOpnBrks3oo9q3AeIjKQaP0XPyIdBD261hSVnU/5gerYaNFI4DeLi+hJLzoeXp9uGmBuWqJ9dSDRvQwAgH2hdJDFVV0w+kEwOhLhI1+DHkauXl1V1JaXKjJ1b7WsOE5KevbpzRRg== X-YMail-OSG: p4a4y7gVM1kTIhgIwiKdo9u3X1d6eCRyOmYxywpikz0Ywwmf1t3f9ufDprSgUGZ YoQBMqy6lHEcFpkjFwnhKg1yZVlxstGkVZz.CgNHJmTqcqrOHgD9TxSEw5aO_oRJpbhmcRvuwfWz 5.b.ha9ggTAz026GrobqBtGoH6KV7CYvgEvuXVdAXQQZ505pNMetnb6PQgRtZLwjRnN4y4nvERUV okhnGgscEbuGrZQNrHEpc9vMzdqsOo7JWwQkA3GjcOoYyMYz5y4cQnFSOde2LxE_C7Lv6apH4bsd 1NZ9M6RvUteQivaZIRf0sOHyUV2AIfZtMCFX66.aDUnZ1BX.hiIFVEgT.Qm9QoWLGdWBRGdCAOj3 SgM6uFR1psmu9PMTgeViVKkitX.siwi.KHXL5pejTnhz2m_VsbxSq8heLMUyRMWpUNhA500vlJYZ AXeKDN3pve0JQNGsNZvSIKh1Qn4tly5am3qbTkpTlDvwqISgUg2FORWJMKqmazi2LEXCt7dDKLEl UGARwvMhRJAjIITgStW3KXxQXk3iCcisPtEJO1XtdpdirQG_jfEeFu1guS9Rit_y6snv0nbIrzRp 7g5aXuG1sF8e_3xon_eDms0QQaw4ejlljQJ16nSwT6hnrkoq5FvHveps8dZAQsmEp7AbMsCaG4hn gihRu5FptafoEKs_WYv2CoS2Ssf5GFhmKgotsVIxsHCcVvE4YDSjCG.XOYR3gTHMLrP4A6Ku643r I5eRlfc5Q2HtzVu3VQlx1Da4dCx1mm3durvNsKWrC.fzNp3mt6VhBH00xHIOxLeMHer.AEpiNIF5 twsnaDaUrUuZDICEikkvOj9WMpCTfY0zqnv6exF.oYyCeX4WCaMYz41Ay2kFYaC.uOBS63W9.R05 KFFb7KbfGiZ9KowPmtGucbTPkhO9d8cziCrN6TDOMI.8ts2gBG35gpVcMZBi.OrBZXNtJ5c9eScu BE8asb7jv5GqXzL7FRtuhYfmNi.2BwU.9yweQR8YWo5cR1b2L_Zf72afMeZzKDvzR0WeB14Ra8Mg z2bUCN8vtA_IX.BNL2XtkQRpq1CzIMquEsyqwQR0wYBv2KH8l.Dv_UcbwmTdmzwHwbLGT.DMgXrq 1n2Jxglr3IHn.bu4BJg9QfItW.15G0lYCmwF8fPgECpVX3a3UcfoTQbU8wYZ1WCEZW9PtMJDjFhz SjSd4U4Z3uN_cdIKRCSb.BNlQs.KS9WtdQPBC6vMZSzPlxzFxV9YLWaeFjbxPoZXgsWcMrTVBKNK kmsHrZGr7tNS09XD8J6ostiYCPay03kgKbQcLwmsB1OO0dMaZofxce8lVYbqVeRInaeYUe8dI8Qu fGS7ot5bGKhZ2f_GzgCoUSdWluTrXamHca3I5LMf0G2jM1Dsbb6lZ.6mBobZgh4IY6VQAxheTzY3 sU8YBp6z5nY2ggNcAB8qCrAvGDXZmXSkCmnBLFzsHgzNaczjpvVxeg8aj9VDkwMfdK4B4v9AQP5R tFX3U21u4AZdQa8ss4_So_RjDvlXjnDvL62MInmZwl5AVGkGJKxnyHDyX8qgoyOxA5c31wh.pXbb cuZpML.JerdkQK_ZlA0cVUbjWTOyTNDzs6iKQwrAsfJ36ghVz0h5p1rMf0kvOwa8R6M_Sf8lqDlt HqBxB_FzdXGY_1QRKQLY.k6BdrhT8ocBcOJep6SaLZ8x8_LlvmhUctl.97A68UgCb8d4YWf59GrQ BkKRBXtX.oHupoHOQdWcYafoUfoP.p9iyJD_I_1FJeoscYKMk5SPPwnbsi_px8mHnAzZI65kRign H5UAfPEv3Rr.YRvrp9suNJOW3RPRFSzEk6xoPF8dTdeo8b_xW8p_Ujf6usWmBEyROGaSPWOeinYB Wv1ZH.W.TKyVCmg.BmTzD5xKTpD8sKNRZG94YICN1rp3zGdenGbU6JPU0mIiRsy3HPc.YEcOlO.x pmcnAVNTbHHScstMUYQfzPFBxhtTK0WFp5oyFTv6c4mPyjC7tOB_FDAJ.haer2izzIbW18gYPrQz gfqFFefo2ey0L2d1XF9cHmJpDPtU3xU3ywhRrdKuwys7CC1LvtUr3SaDxP1KsyJzCq40dKhtRT2g q.mNinFEzjGlTSWEyZ5RRn.KtLw8VQi5Bqz6OSf.TiWiWIlDtRSxZxq8s5u1Zl9Zaj35gkk_U7TJ vi7.6ad4O0kDFk7FJ11a.q5DlEpIj2CZroWmWo.pVO_lddcGv8.WxfKe0sWK9gnlVjOQlqjFGLtD sHqXWGlOIcVPr50QE8qQZOsS7ub._J5zSiF5ALlbj2_JQ48kLz..2982TzvN.gLOlPY2aoAcrZuE 7 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Jan 2022 13:18:01 +0000 Received: by kubenode537.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 18875033a69c27c0934cda8b0b92335c; Fri, 14 Jan 2022 13:17:55 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: An explanation of some "Container overflow" ASAN reports: libc++ does sometimes temporarily overflow the used range of a container Date: Fri, 14 Jan 2022 05:17:52 -0800 References: <22B11810-DB3F-4E81-AB40-ED207CD83EEE@yahoo.com> To: freebsd-current In-Reply-To: <22B11810-DB3F-4E81-AB40-ED207CD83EEE@yahoo.com> Message-Id: <439BD3A5-68D4-40A7-A4CD-77A05A847B18@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jb20w2kpNz4ngp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=HD1hesAp; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.94 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.56)[0.556]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > On 2022-Jan-14, at 04:44, Mark Millard wrote: >=20 > Looks like libc++ does the following sort of thing > (from lldb list): >=20 > . . . > 1635=09 > 1636 template > 1637 template > 1638 void > 1639 #ifndef _LIBCPP_CXX03_LANG > (lldb)=20 > 1640 vector<_Tp, _Allocator>::__push_back_slow_path(_Up&& = __x) > 1641 #else > 1642 vector<_Tp, _Allocator>::__push_back_slow_path(_Up& __x) > 1643 #endif > 1644 { > 1645 allocator_type& __a =3D this->__alloc(); > 1646 __split_buffer = __v(__recommend(size() + 1), size(), __a); > 1647 // __v.push_back(_VSTD::forward<_Up>(__x)); > 1648 __alloc_traits::construct(__a, = _VSTD::__to_address(__v.__end_), _VSTD::forward<_Up>(__x)); > 1649 __v.__end_++; > (lldb)=20 > 1650 __swap_out_circular_buffer(__v); > 1651 } > . . . (the bt points to 1650) . . . >=20 > 1648 constructs into __v at __v.__end_ and 1649 then corrects > __v.__end_ to cause the constructed object to no longer be > an example of "Container overflow" but now in the Container. > (At least that is my interpretation.) >=20 > The compiler's code generation may move the detailed > place where __v.__end_++ happens relative to some other > of the activity but the compiler has been told an order > relative to the construction that would lead to writing > memory in the capacity of the container __v but outside > the size of the __v container at the time. >=20 > For reference: >=20 > 970 template > 971 void > 972 vector<_Tp, = _Allocator>::__swap_out_circular_buffer(__split_buffer& __v) > 973 { > 974 =09 > 975 __annotate_delete(); > 976 = _VSTD::__construct_backward_with_exception_guarantees(this->__alloc(), = this->__begin_, this->__end_, __v.__begin_); > 977 _VSTD::swap(this->__begin_, __v.__begin_); > 978 _VSTD::swap(this->__end_, __v.__end_); > 979 _VSTD::swap(this->__end_cap(), __v.__end_cap()); > (lldb)=20 > 980 __v.__first_ =3D __v.__begin_; > 981 __annotate_new(size()); > 982 __invalidate_all_iterators(); > 983 } > . . . (the bt for this points to 976) . . . >=20 >=20 > This suggests to me that using some equivalent of: >=20 > env ASAN_OPTIONS=3Ddetect_container_overflow=3D0 >=20 > my be required fairly generally when libc++ can > be involved. >=20 >=20 > Other notes . . . >=20 > I used ld -v as an example for the above via: >=20 > env ASAN_OPTIONS=3Ddetect_container_overflow=3D0 lldb ld >=20 > and used: >=20 > (lldb) env ASAN_OPTIONS=3D > (lldb) run -v >=20 > in order to have ld itself not have detect_container_overflow > disabled. >=20 > lldb suffers the libc++ Container overflow problems via its > libc++ use and fails to operate without the: >=20 > ASAN_OPTIONS=3Ddetect_container_overflow=3D0 >=20 Hmm. The code in: 772 template 773 _LIBCPP_INLINE_VISIBILITY 774 void __construct_backward_with_exception_guarantees(_Alloc& __a, = _Ptr __begin1, _Ptr __end1, _Ptr& __end2) { 775 static_assert(__is_cpp17_move_insertable<_Alloc>::value, 776 "The specified type does not meet the requirements of = Cpp17MoveInsertable"); 777 typedef allocator_traits<_Alloc> _Traits; 778 while (__end1 !=3D __begin1) { 779 _Traits::construct(__a, _VSTD::__to_address(__end2 - 1), (lldb)=20 780 #ifdef _LIBCPP_NO_EXCEPTIONS 781 _VSTD::move(*--__end1) 782 #else 783 _VSTD::move_if_noexcept(*--__end1) 784 #endif 785 ); 786 --__end2; 787 } 788 } has the same sort of problem going in the other direction. __end2 references the __v.__begin_ mentioned earlier for the context at hand. line 779 constructs just before where __v.__begin_ refers to at the time and then 786 updates __v.__begin_ to make the constructed object no longer be an example of "Container overflow" but now in the Container. This is likely the WRITE activity that is actually reported, although I've not analyzed the machine code at all. This also suggests to me that using some equivalent of: env ASAN_OPTIONS=3Ddetect_container_overflow=3D0 my be required fairly generally when libc++ can be involved. Important . . . I'll note that the construct-then-include order is tied to exception safety. I'm not claiming that the libc++ code is wrong. It just that it and ASAN are currently mismatched so ASAN by default reports libc++ as having an addressing issue for which aborting the program is the handling ASAN does by default. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 14 13:37:20 2022 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 BB97B19667C8 for ; Fri, 14 Jan 2022 13:37:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jb2RG4XgJz4wwG for ; Fri, 14 Jan 2022 13:37:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642167446; bh=i60dBOEf/322wwJNhbttlXHiAnprM3yLvhBEHnrWiK4=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=q4wbwZB8EApfnQN2YYZCwL1Gv83MwaJKzmCKx6s1ap/+nSMS5w0e/e6IkqIUtX+1KNavecDXZSRBiC0ReELOftOXT5npz7/TB/1VDDTA2mfnSI3DcSbfoRz/nh4ywrRsLv6AKYyMAN+uDlhjXY86TRhqBrlnT9MxvbecM+7t0d8rJ61I65+B9wOvYQiJ+2DuvWpoJ8gRb4kMLSZEwD2DwLijK4k4GokJjqUl79ph9P5S+IX2o5ANtAgp7qI7+SNQvosWZIHtWxu/WKGgjNmdKErfIE7yHO/AKGzU7hRGgxdTFuAZyMvO2dY+Mtr6hjMrKWsHrkjwFBxG/QjbqPSiBg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642167446; bh=y94ItGyJT8hdGiMHt36KoUsnKnRypQAUzJSUz0K1dl6=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=G775ZFvbB6adivtNkfX5pJsKqMw8Zygexbn7T23zOjm5/viPzVXsaBqoWxgecAbgAz1vX0OhxIpyvFG00XV+2haHFn1f9l/RpMeez7prAKoh8llfzt644ED6WRRLvqbn5gJ4nnrqcGhttjp7FHiOsJTT/WEcv/hSGh81NGFzhRY4Og6sPsEKRPXd84dLjCeScdUuZLXt6AW4Ops/fUE0D+p81XCZMQUuvdWY3hzA9Ice4w2YBEBGMh3p5HBUJjmIXKs493sQnDjJRiW1Hh7hQ5clsVPXRxb5N6iHxnf7JVRTfM0ul6B+7pFVitE+jTbYXJYqDiH/QD+dygzfvael5A== X-YMail-OSG: zi4hcacVM1lJ07CeysJMgCb_iG3zxixsh6hbPsaH0VjcHiAFTYn4z7d0oXmzyYZ whN9dYpn_lBEisARKO740fXHcXN6P4yHQR2G4tqEEfkXLLUKAkSdgNWjAmceBiKtFS6L.DrgBFBJ srSQLo0eLJFJ2LhZ8wn8bkc.hZxVH_C57T90rW2507FYzlTfT3Yy6V9z7OcOwwCrmsUpSiOJU_F0 UOr5rzEL_R0LdHaaw51O1IBsG8PXcdGzr_lduroQLM1BRRYQupEqTkEhjq_mm2GMkC.IahLcap33 0XZGmdWO4h2uiT969cQ1ZYdkONYQq.ulcUBAv5hQK5UPuYL2p.PElFd2a_LtP0qgI0mz6Y7rMOAq FChrYef07xwXdte7G_ws5TsylRZL6mStoeoU7fpaBNe7MutlUSFNYsyrrdIp3_dsbeoX9d8HB88X vHNmi6XVo7S4Q0q.uvQST2iVk6HAI_EbYv7bXvfn127ZoE4CU5uZudzezDKM9bcTH8dgBQtqLTFB wJhFCjgbAiayaRof2qyGWUnW32Rj9XYx8z10_3UQikFsPiE3u5Kqi1zJDNu6rXWYdT2x5.hHtnbT AQ2ZAN148JMvapmCkRFxCPnVdP7fSX2y9R19KRe9PqqsJMsyOyeyiKeFo5ZNgvluL9aSLTrqXNtl ar6_3moWVHR0mpQ7Pf.a7ulPcy2Rbpqac0g.9Bwt9wWaJgYNFDebwx4AHQY7_yUv5reAVwlF7GeU 1THvosF6Fl43FrOWu1tlAQRScyMTpKxD6XJnmRMOWdQFyZ9WK7p4EBhFz10_CVk_nXyxiDmNgn4. QgG.2IgxCXeL_arIPh_K46uxVr9GAc_ULTX3KEFAVIa3kDGkaxScnhgrHabT2JQcsOENgpX0ARTk nbKhKBGgXEqygrgu62AsqAoxczbNQXfNzv.hMHNOza4jGqrLxk.9UbCEv5nuVop9MjxE.OhgY9Gy HYISkkWm_OlFvEe9UUIKn1WnCSQGKCgd5kgnRRZhCTUuysCZwZGM_r9O7.k2p7KwH3s0PmxOEHei EhJ.nUi17MYLT0z76nZEXD48enIp0l4OaVlS3D0KSkL8ozxrFzi_.u_KiV1Z2c._DxFZUh2lvJLu DIlEFabSDC3zILbP.oyARwKwT8cLentnG2ATKp863b7U5M9mHamnguVh.kWmTQIJ6qRFdqwl9nSB 79By8AhmD5gZ0Ikr4O0qxqq3.lvFfu7w_ocRKsMgafGKIOOd_iXy3mJ2ejNA9y1QhxmCg.XQfaWF Id1BjFUFJUc.d4scD6z5BboDFNN.WIfUpLZBA6fPPkCgEhAStx4.R_TN7Ylx3MgjX.8VBp.OhJF9 HZo9FcYvNPUgWEIzbukgDu0s.hf7nDlHd2XYPHF.1EQZHGXz.msD.AvL4Ybqnvkq0u8lbUjuF_u2 2X2Y_2rOjYVOZ7rV3PnUjqdmi5JqjWCBk71iEBwdCJ3kJe_kOk8GqMyS8N5bU4dsUDEhVgL9uGOg WSEyZrZH2yCB51A1wtP9tetyiv2QuIgLoRGS4RPdc3aGWEanOIKVqMWRDX9l8w2OrCGb9qA4yIFJ .yslszWJJfMU64MzLai01JUcHjdCLAmzcguQxxmzTiiTKfhCZQl3PKlL0fadkIppoZ0X2s7AphBj _5qjbF_6scWPcJCctlo5__H6yLrNRDN6FR8cMRAuRdMYaz.oRksqFayIckL_gSKm1Tj6s2wgv2NJ hKcCKljIr7niL0cHjGK7RaHjfOrX22T2sCYNlWRrwfRN20A7ESTJh5v5Sjy_Pr70kGC7imsufri4 MRblxlr6IJaLI6wY1qz5ETKcI6g0d9nBrJy0o407yawvJzTaVXVO1MEJF1WP8kT2gCkpVDfHmvRI fJIDhPnt7li4Ku9EKJOtBfcqUOCU0rlvryzQByBEwLSVXwEU9fGwkb3RteDr6nkDcUx9AIYNAP7z BreadQsdxoh_UEo8t2NrIgiADm34IQX88eS1eFnigWYtr8jncvDTcm_7W_oz0A5Zo2g2YomcM5.7 VXcnhh2TeoNxtN9S627vE_cuJOvuY3vZJIQlLtrx77OP4yEN0KH5CNZsQwJHP7_5LfOEXF8Pr2dW WCCAie.He3U1neVBO_BIhEuKU7N5BFjrehitK7rP9Aol1FUsLxkYyxhDxs81VhgWVPn86wivuZYA md5N_AegLZja7eNsYGVGH2kunu0.NGkUIeno.wDGcgy1NC5pQQpqe6NFAAzdbF82XvkvVf1fTaFY KDQYpP6xvjKse4UW49njSq8eDwCRkfw4dWQ9sqZhvJweTl4vDs92IPrNZmHpzDimvtd50AXQvUFi irmQ- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Jan 2022 13:37:26 +0000 Received: by kubenode511.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3d4adf2284bfff72ff8f85470f223ac7; Fri, 14 Jan 2022 13:37:22 +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 14.0 \(3654.120.0.1.13\)) Subject: UBSAN reported behaviors in view use: Null pointer use oddities in contrib/nvi/... code Message-Id: <99C234B7-AD2F-428F-B697-32A1F89AAC51@yahoo.com> Date: Fri, 14 Jan 2022 05:37:20 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <99C234B7-AD2F-428F-B697-32A1F89AAC51.ref@yahoo.com> X-Rspamd-Queue-Id: 4Jb2RG4XgJz4wwG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=q4wbwZB8; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N # env ASAN_OPTIONS=3Ddetect_container_overflow=3D0 lldb view (lldb) target create "view" Current executable set to 'view' (x86_64). (lldb) run /usr/main-src/contrib/nvi/common/log.c Process 96507 launched: '/usr/bin/view' (x86_64) Process 96507 stopped * thread #1, name =3D 'view', stop reason =3D Nullptr with nonzero = offset frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at = ubsan_monitor.cpp:39 36 } 37 =09 38 SANITIZER_WEAK_DEFAULT_IMPL -> 39 void __ubsan::__ubsan_on_report(void) {} 40 =09 41 void __ubsan::__ubsan_get_current_report_data(const char = **OutIssueKind, 42 const char = **OutMessage, (lldb) bt * thread #1, name =3D 'view', stop reason =3D Nullptr with nonzero = offset * frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at = ubsan_monitor.cpp:39 frame #1: 0x00000000012c36b1 = view`__ubsan::Diag::~Diag(this=3D0x00007fffffffb9b0) at = ubsan_diag.cpp:354:29 frame #2: 0x00000000012c85e4 = view`handlePointerOverflowImpl(Data=3D, Base=3D,= Result=3D, Opts=3D(FromUnrecoverableHandler =3D false, pc = =3D 21543807, bp =3D 140737488337936)) at ubsan_diag.h:0:21 frame #3: 0x00000000012c811a = view`::__ubsan_handle_pointer_overflow(Data=3D, = Base=3D, Result=3D) at = ubsan_handlers.cpp:815:3 frame #4: 0x000000000148bb7f view`vs_crel(sp=3D0x00007fffffffbd20, = count=3D) at v_z.c:138:14 frame #5: 0x0000000001420d78 view`v_optchange(sp=3D, = offset=3D, str=3D, valp=3D) at = v_init.c:117:11 [artificial] frame #6: 0x000000000132d079 view`opts_set(sp=3D0x000061e000000080, = argv=3D0x00007fffffffbf00, usage=3D) at options.c:684:8 frame #7: 0x0000000001328db4 view`opts_init(sp=3D, = oargs=3D) at options.c:412:2 frame #8: 0x00000000013184d3 view`editor(gp=3D0x0000621000000100, = argc=3D, argv=3D0x00007fffffffdb10) at main.c:240:6 frame #9: 0x00000000012d21dd view`main(argc=3D, = argv=3D) at cl_main.c:115:9 frame #10: 0x0000000001246c7d view`_start(ap=3D, = cleanup=3D) at crt1_c.c:73:7 (lldb) up 4 frame #4: 0x000000000148bb7f view`vs_crel(sp=3D0x00007fffffffbd20, = count=3D) at v_z.c:138:14 135 sp->t_minrows =3D sp->t_rows =3D count; 136 if (sp->t_rows > sp->rows - 1) 137 sp->t_minrows =3D sp->t_rows =3D sp->rows - 1; -> 138 TMAP =3D HMAP + (sp->t_rows - 1); 139 F_SET(sp, SC_SCR_REDRAW); 140 return (0); 141 } (lldb) thread info -s thread #1: tid =3D 125915, 0x00000000012c8ef0 view`::__ubsan_on_report() = at ubsan_monitor.cpp:39, name =3D 'view', stop reason =3D Nullptr with = nonzero offset { "col": 14, "description": "nullptr-with-nonzero-offset", "filename": "/usr/main-src/contrib/nvi/vi/v_z.c", "instrumentation_class": "UndefinedBehaviorSanitizer", "line": 138, "memory_address": 0, "summary": "Applying non-zero offset 1056 to null pointer", "tid": 125915, "trace": [] } . . . Later: . . . Process 96507 stopped * thread #1, name =3D 'view', stop reason =3D Null pointer use frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at = ubsan_monitor.cpp:39 36 } 37 =09 38 SANITIZER_WEAK_DEFAULT_IMPL -> 39 void __ubsan::__ubsan_on_report(void) {} 40 =09 41 void __ubsan::__ubsan_get_current_report_data(const char = **OutIssueKind, 42 const char = **OutMessage, (lldb) bt * thread #1, name =3D 'view', stop reason =3D Null pointer use * frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at = ubsan_monitor.cpp:39 frame #1: 0x00000000012c36b1 = view`__ubsan::Diag::~Diag(this=3D0x00007fffffffc3c0) at = ubsan_diag.cpp:354:29 frame #2: 0x00000000012c4aef = view`handleTypeMismatchImpl(Data=3D, Pointer=3D,= Opts=3D(FromUnrecoverableHandler =3D false, pc =3D 19992923, bp =3D = 140737488340592)) at ubsan_handlers.cpp:117:5 frame #3: 0x00000000012c47aa = view`::__ubsan_handle_type_mismatch_v1(Data=3D, = Pointer=3D) at ubsan_handlers.cpp:142:3 frame #4: 0x000000000131115b view`log_line(sp=3D, = lno=3D, action=3D) at log.c:261:2 frame #5: 0x000000000130cd55 view`db_append(sp=3D, = update=3D, lno=3D, p=3D, = len=3D) at line.c:295:2 frame #6: 0x000000000141b582 view`v_ecl_log(sp=3D, = tp=3D) at v_ex.c:605:10 frame #7: 0x0000000001419af2 view`v_ex(sp=3D, = vp=3D) at v_ex.c:372:38 frame #8: 0x000000000148da62 view`vi(spp=3D) at = vi.c:226:18 frame #9: 0x0000000001319704 view`editor(gp=3D0x0000621000000100, = argc=3D, argv=3D) at main.c:402:38 frame #10: 0x00000000012d21dd view`main(argc=3D, = argv=3D) at cl_main.c:115:9 frame #11: 0x0000000001246c7d view`_start(ap=3D, = cleanup=3D) at crt1_c.c:73:7 (lldb) up 4 frame #4: 0x000000000131115b view`log_line(sp=3D, = lno=3D, action=3D) at log.c:261:2 258 } else 259 if (db_get(sp, lno, DBG_FATAL, &lp, &len)) 260 return (1); -> 261 BINC_RETC(sp, 262 ep->l_lp, ep->l_len, 263 len * sizeof(CHAR_T) + CHAR_T_OFFSET); 264 ep->l_lp[0] =3D action; (lldb) thread info -s thread #1: tid =3D 208533, 0x00000000012c8ef0 view`::__ubsan_on_report() = at ubsan_monitor.cpp:39, name =3D 'view', stop reason =3D Null pointer = use { "col": 2, "description": "null-pointer-use", "filename": "/usr/main-src/contrib/nvi/common/log.c", "instrumentation_class": "UndefinedBehaviorSanitizer", "line": 261, "memory_address": 0, "summary": "Member access within null pointer of type 'log_t'", "tid": 208533, "trace": [] } (lldb) c Process 96507 resuming /usr/main-src/contrib/nvi/common/log.c:261:2: runtime error: member = access within null pointer of type 'log_t' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/nvi/common/log.c:261:2 in=20 Process 96507 stopped * thread #1, name =3D 'view', stop reason =3D Null pointer use frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at = ubsan_monitor.cpp:39 36 } 37 =09 38 SANITIZER_WEAK_DEFAULT_IMPL -> 39 void __ubsan::__ubsan_on_report(void) {} 40 =09 41 void __ubsan::__ubsan_get_current_report_data(const char = **OutIssueKind, 42 const char = **OutMessage, (lldb) bt * thread #1, name =3D 'view', stop reason =3D Null pointer use * frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at = ubsan_monitor.cpp:39 frame #1: 0x00000000012c36b1 = view`__ubsan::Diag::~Diag(this=3D0x00007fffffffc3c0) at = ubsan_diag.cpp:354:29 frame #2: 0x00000000012c4aef = view`handleTypeMismatchImpl(Data=3D, Pointer=3D,= Opts=3D(FromUnrecoverableHandler =3D false, pc =3D 19993513, bp =3D = 140737488340592)) at ubsan_handlers.cpp:117:5 frame #3: 0x00000000012c47aa = view`::__ubsan_handle_type_mismatch_v1(Data=3D, = Pointer=3D) at ubsan_handlers.cpp:142:3 frame #4: 0x00000000013113a9 view`log_line(sp=3D, = lno=3D, action=3D) at log.c:266:21 frame #5: 0x000000000130cd55 view`db_append(sp=3D, = update=3D, lno=3D, p=3D, = len=3D) at line.c:295:2 frame #6: 0x000000000141b582 view`v_ecl_log(sp=3D, = tp=3D) at v_ex.c:605:10 frame #7: 0x0000000001419af2 view`v_ex(sp=3D, = vp=3D) at v_ex.c:372:38 frame #8: 0x000000000148da62 view`vi(spp=3D) at = vi.c:226:18 frame #9: 0x0000000001319704 view`editor(gp=3D0x0000621000000100, = argc=3D, argv=3D) at main.c:402:38 frame #10: 0x00000000012d21dd view`main(argc=3D, = argv=3D) at cl_main.c:115:9 frame #11: 0x0000000001246c7d view`_start(ap=3D, = cleanup=3D) at crt1_c.c:73:7 (lldb) up 4 frame #4: 0x00000000013113a9 view`log_line(sp=3D, = lno=3D, action=3D) at log.c:266:21 263 len * sizeof(CHAR_T) + CHAR_T_OFFSET); 264 ep->l_lp[0] =3D action; 265 memmove(ep->l_lp + sizeof(u_char), &lno, = sizeof(recno_t)); -> 266 memmove(ep->l_lp + CHAR_T_OFFSET, lp, len * = sizeof(CHAR_T)); 267 =09 268 lcur =3D ep->l_cur; 269 key.data =3D &lcur; (lldb) thread info -s thread #1: tid =3D 208533, 0x00000000012c8ef0 view`::__ubsan_on_report() = at ubsan_monitor.cpp:39, name =3D 'view', stop reason =3D Null pointer = use { "col": 21, "description": "null-pointer-use", "filename": "/usr/main-src/contrib/nvi/common/log.c", "instrumentation_class": "UndefinedBehaviorSanitizer", "line": 266, "memory_address": 0, "summary": "Member access within null pointer of type 'log_t'", "tid": 208533, "trace": [] } (lldb) c Process 96507 resuming /usr/main-src/contrib/nvi/common/log.c:266:21: runtime error: member = access within null pointer of type 'log_t' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/contrib/nvi/common/log.c:266:21 in=20 Process 96507 stopped * thread #1, name =3D 'view', stop reason =3D Null pointer use frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at = ubsan_monitor.cpp:39 36 } 37 =09 38 SANITIZER_WEAK_DEFAULT_IMPL -> 39 void __ubsan::__ubsan_on_report(void) {} 40 =09 41 void __ubsan::__ubsan_get_current_report_data(const char = **OutIssueKind, 42 const char = **OutMessage, (lldb) bt * thread #1, name =3D 'view', stop reason =3D Null pointer use * frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at = ubsan_monitor.cpp:39 frame #1: 0x00000000012c36b1 = view`__ubsan::Diag::~Diag(this=3D0x00007fffffffc3c0) at = ubsan_diag.cpp:354:29 frame #2: 0x00000000012c4aef = view`handleTypeMismatchImpl(Data=3D, Pointer=3D,= Opts=3D(FromUnrecoverableHandler =3D false, pc =3D 19993957, bp =3D = 140737488340592)) at ubsan_handlers.cpp:117:5 frame #3: 0x00000000012c47aa = view`::__ubsan_handle_type_mismatch_v1(Data=3D, = Pointer=3D) at ubsan_handlers.cpp:142:3 frame #4: 0x0000000001311565 view`log_line(sp=3D, = lno=3D, action=3D) at log.c:272:37 frame #5: 0x000000000130cd55 view`db_append(sp=3D, = update=3D, lno=3D, p=3D, = len=3D) at line.c:295:2 frame #6: 0x000000000141b582 view`v_ecl_log(sp=3D, = tp=3D) at v_ex.c:605:10 frame #7: 0x0000000001419af2 view`v_ex(sp=3D, = vp=3D) at v_ex.c:372:38 frame #8: 0x000000000148da62 view`vi(spp=3D) at = vi.c:226:18 frame #9: 0x0000000001319704 view`editor(gp=3D0x0000621000000100, = argc=3D, argv=3D) at main.c:402:38 frame #10: 0x00000000012d21dd view`main(argc=3D, = argv=3D) at cl_main.c:115:9 frame #11: 0x0000000001246c7d view`_start(ap=3D, = cleanup=3D) at crt1_c.c:73:7 (lldb) up 4 frame #4: 0x0000000001311565 view`log_line(sp=3D, = lno=3D, action=3D) at log.c:272:37 269 key.data =3D &lcur; 270 key.size =3D sizeof(recno_t); 271 data.data =3D ep->l_lp; -> 272 data.size =3D len * sizeof(CHAR_T) + CHAR_T_OFFSET; 273 if (ep->log->put(ep->log, &key, &data, 0) =3D=3D -1) 274 LOG_ERR; 275 =09 (lldb) thread info -s thread #1: tid =3D 208533, 0x00000000012c8ef0 view`::__ubsan_on_report() = at ubsan_monitor.cpp:39, name =3D 'view', stop reason =3D Null pointer = use { "col": 37, "description": "null-pointer-use", "filename": "/usr/main-src/contrib/nvi/common/log.c", "instrumentation_class": "UndefinedBehaviorSanitizer", "line": 272, "memory_address": 0, "summary": "Member access within null pointer of type 'log_t'", "tid": 208533, "trace": [] } =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 14 15:27:57 2022 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 9C36F1942938 for ; Fri, 14 Jan 2022 15:28:01 +0000 (UTC) (envelope-from bapt@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jb4tn4521z4cKM; Fri, 14 Jan 2022 15:28:01 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642174081; 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=2gfOPTFToYjLgur/fvw2r0K/rXRIH2Np7d1LFiGnCWw=; b=wFFIr/VhxferY2KiUFy3H1jiL+NEPy2Cnvl1i0+jc7zQzObyqQMsa5CEYsaR4b+nWFyt7h O8jtn8iefQb7WztGSjyJbqM9dtl0g2FL6GnZvjVFq2GktntiUN/uURpVSc1XTDDgGmCiZh ZGQztxTkp+CohGLc9GgNxK8VNjlE9HVRfOaQuljfY2mF8osdHJtswxbPnyDwnnGlte7R6K a45RZU4oJ/E6DHwh2WTE0tmiVOhVk78+bQx7nizmQPFjwvN7nf0c4Mf7xIMmnnKUI00VYg QhzRP/q2OHQXepIZYeHJHONcevHN3lrJx0PmRxJLa0Wcbie803ueIyeSzrBxpw== Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 0DFD28ED9; Fri, 14 Jan 2022 15:28:01 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 01FDF7CE4F; Fri, 14 Jan 2022 16:27:57 +0100 (CET) Date: Fri, 14 Jan 2022 16:27:57 +0100 From: Baptiste Daroussin To: Mark Millard Cc: freebsd-current , Zhihao Yuan Subject: Re: UBSAN reported behaviors in view use: Null pointer use oddities in contrib/nvi/... code Message-ID: <20220114152757.bissm73v5vwhdogv@aniel.nours.eu> References: <99C234B7-AD2F-428F-B697-32A1F89AAC51.ref@yahoo.com> <99C234B7-AD2F-428F-B697-32A1F89AAC51@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99C234B7-AD2F-428F-B697-32A1F89AAC51@yahoo.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642174081; 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=2gfOPTFToYjLgur/fvw2r0K/rXRIH2Np7d1LFiGnCWw=; b=bMaNT3olnxCGnHpGts2vDevmlbQ9wiFnKqVtKKpAD2b+a/cX5fFMeKqzNF0vf8Jy2D18KU bJzEYpZ7hzlkGmvt8iXISQ5xiBs6YVgz+IyD9lFFGFHYHa19sS3HFU2Hw9LM2egZ6cA2lB npfwI9piQH5PSB7NNbSQLAgg0jxinqM42Jl8hafG+4lCL+Gar1J7+iG1WIblBAbW3vx7IR 9uWIm6zx5QTVEFMUuCVHSZT0jLeyG2Vy7n/nW2jwXpsqznPVFA7C5G/3/V5490MLLQJUXh TJxeO0TTqSMKwFVDJJOW59dFGcwK89ZJa3NhnCEe/q3a0Xg0zS7YiZ+smoNnZQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642174081; a=rsa-sha256; cv=none; b=ctZJXkROGERRpvkcLHF7Mv1w+VNCF2FkeDwRTGehfIaE+M0AUFSpF2d5XObpgYqxo3FHBD ohS2eOSAw5QeDfxUWr2G/da6mFMTyB39CiFTf8hs6aDIwDHO1bxIUh/vZG6wyWJpiGeN+I ImPpG9Pel6ZCPjQw/gT66RNLZ/rI3/s0k3osj6YTeK4X5z1huUznv3h3buzr/rhL5bgTPE 3Z4z0GJqDrmZmgy4eQif15heCIe4n2YFAQcfPwacyVGTJ4zmGpFq5qSrEE3klltdRe+b8W dAWgXXL0jCR+WT7LflbqZsogZYmwwBfTIoWmK7Gqvswg+1g0uuswiZKe67vGNg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N + CC upstream On Fri, Jan 14, 2022 at 05:37:20AM -0800, Mark Millard wrote: > # env ASAN_OPTIONS=detect_container_overflow=0 lldb view > (lldb) target create "view" > Current executable set to 'view' (x86_64). > (lldb) run /usr/main-src/contrib/nvi/common/log.c > Process 96507 launched: '/usr/bin/view' (x86_64) > Process 96507 stopped > * thread #1, name = 'view', stop reason = Nullptr with nonzero offset > frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39 > 36 } > 37 > 38 SANITIZER_WEAK_DEFAULT_IMPL > -> 39 void __ubsan::__ubsan_on_report(void) {} > 40 > 41 void __ubsan::__ubsan_get_current_report_data(const char **OutIssueKind, > 42 const char **OutMessage, > (lldb) bt > * thread #1, name = 'view', stop reason = Nullptr with nonzero offset > * frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39 > frame #1: 0x00000000012c36b1 view`__ubsan::Diag::~Diag(this=0x00007fffffffb9b0) at ubsan_diag.cpp:354:29 > frame #2: 0x00000000012c85e4 view`handlePointerOverflowImpl(Data=, Base=, Result=, Opts=(FromUnrecoverableHandler = false, pc = 21543807, bp = 140737488337936)) at ubsan_diag.h:0:21 > frame #3: 0x00000000012c811a view`::__ubsan_handle_pointer_overflow(Data=, Base=, Result=) at ubsan_handlers.cpp:815:3 > frame #4: 0x000000000148bb7f view`vs_crel(sp=0x00007fffffffbd20, count=) at v_z.c:138:14 > frame #5: 0x0000000001420d78 view`v_optchange(sp=, offset=, str=, valp=) at v_init.c:117:11 [artificial] > frame #6: 0x000000000132d079 view`opts_set(sp=0x000061e000000080, argv=0x00007fffffffbf00, usage=) at options.c:684:8 > frame #7: 0x0000000001328db4 view`opts_init(sp=, oargs=) at options.c:412:2 > frame #8: 0x00000000013184d3 view`editor(gp=0x0000621000000100, argc=, argv=0x00007fffffffdb10) at main.c:240:6 > frame #9: 0x00000000012d21dd view`main(argc=, argv=) at cl_main.c:115:9 > frame #10: 0x0000000001246c7d view`_start(ap=, cleanup=) at crt1_c.c:73:7 > (lldb) up 4 > frame #4: 0x000000000148bb7f view`vs_crel(sp=0x00007fffffffbd20, count=) at v_z.c:138:14 > 135 sp->t_minrows = sp->t_rows = count; > 136 if (sp->t_rows > sp->rows - 1) > 137 sp->t_minrows = sp->t_rows = sp->rows - 1; > -> 138 TMAP = HMAP + (sp->t_rows - 1); > 139 F_SET(sp, SC_SCR_REDRAW); > 140 return (0); > 141 } > (lldb) thread info -s > thread #1: tid = 125915, 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39, name = 'view', stop reason = Nullptr with nonzero offset > > { > "col": 14, > "description": "nullptr-with-nonzero-offset", > "filename": "/usr/main-src/contrib/nvi/vi/v_z.c", > "instrumentation_class": "UndefinedBehaviorSanitizer", > "line": 138, > "memory_address": 0, > "summary": "Applying non-zero offset 1056 to null pointer", > "tid": 125915, > "trace": [] > } > > . . . Later: . . . > > Process 96507 stopped > * thread #1, name = 'view', stop reason = Null pointer use > frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39 > 36 } > 37 > 38 SANITIZER_WEAK_DEFAULT_IMPL > -> 39 void __ubsan::__ubsan_on_report(void) {} > 40 > 41 void __ubsan::__ubsan_get_current_report_data(const char **OutIssueKind, > 42 const char **OutMessage, > (lldb) bt > * thread #1, name = 'view', stop reason = Null pointer use > * frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39 > frame #1: 0x00000000012c36b1 view`__ubsan::Diag::~Diag(this=0x00007fffffffc3c0) at ubsan_diag.cpp:354:29 > frame #2: 0x00000000012c4aef view`handleTypeMismatchImpl(Data=, Pointer=, Opts=(FromUnrecoverableHandler = false, pc = 19992923, bp = 140737488340592)) at ubsan_handlers.cpp:117:5 > frame #3: 0x00000000012c47aa view`::__ubsan_handle_type_mismatch_v1(Data=, Pointer=) at ubsan_handlers.cpp:142:3 > frame #4: 0x000000000131115b view`log_line(sp=, lno=, action=) at log.c:261:2 > frame #5: 0x000000000130cd55 view`db_append(sp=, update=, lno=, p=, len=) at line.c:295:2 > frame #6: 0x000000000141b582 view`v_ecl_log(sp=, tp=) at v_ex.c:605:10 > frame #7: 0x0000000001419af2 view`v_ex(sp=, vp=) at v_ex.c:372:38 > frame #8: 0x000000000148da62 view`vi(spp=) at vi.c:226:18 > frame #9: 0x0000000001319704 view`editor(gp=0x0000621000000100, argc=, argv=) at main.c:402:38 > frame #10: 0x00000000012d21dd view`main(argc=, argv=) at cl_main.c:115:9 > frame #11: 0x0000000001246c7d view`_start(ap=, cleanup=) at crt1_c.c:73:7 > (lldb) up 4 > frame #4: 0x000000000131115b view`log_line(sp=, lno=, action=) at log.c:261:2 > 258 } else > 259 if (db_get(sp, lno, DBG_FATAL, &lp, &len)) > 260 return (1); > -> 261 BINC_RETC(sp, > 262 ep->l_lp, ep->l_len, > 263 len * sizeof(CHAR_T) + CHAR_T_OFFSET); > 264 ep->l_lp[0] = action; > (lldb) thread info -s > thread #1: tid = 208533, 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39, name = 'view', stop reason = Null pointer use > > { > "col": 2, > "description": "null-pointer-use", > "filename": "/usr/main-src/contrib/nvi/common/log.c", > "instrumentation_class": "UndefinedBehaviorSanitizer", > "line": 261, > "memory_address": 0, > "summary": "Member access within null pointer of type 'log_t'", > "tid": 208533, > "trace": [] > } > (lldb) c > Process 96507 resuming > /usr/main-src/contrib/nvi/common/log.c:261:2: runtime error: member access within null pointer of type 'log_t' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/main-src/contrib/nvi/common/log.c:261:2 in > Process 96507 stopped > * thread #1, name = 'view', stop reason = Null pointer use > frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39 > 36 } > 37 > 38 SANITIZER_WEAK_DEFAULT_IMPL > -> 39 void __ubsan::__ubsan_on_report(void) {} > 40 > 41 void __ubsan::__ubsan_get_current_report_data(const char **OutIssueKind, > 42 const char **OutMessage, > (lldb) bt > * thread #1, name = 'view', stop reason = Null pointer use > * frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39 > frame #1: 0x00000000012c36b1 view`__ubsan::Diag::~Diag(this=0x00007fffffffc3c0) at ubsan_diag.cpp:354:29 > frame #2: 0x00000000012c4aef view`handleTypeMismatchImpl(Data=, Pointer=, Opts=(FromUnrecoverableHandler = false, pc = 19993513, bp = 140737488340592)) at ubsan_handlers.cpp:117:5 > frame #3: 0x00000000012c47aa view`::__ubsan_handle_type_mismatch_v1(Data=, Pointer=) at ubsan_handlers.cpp:142:3 > frame #4: 0x00000000013113a9 view`log_line(sp=, lno=, action=) at log.c:266:21 > frame #5: 0x000000000130cd55 view`db_append(sp=, update=, lno=, p=, len=) at line.c:295:2 > frame #6: 0x000000000141b582 view`v_ecl_log(sp=, tp=) at v_ex.c:605:10 > frame #7: 0x0000000001419af2 view`v_ex(sp=, vp=) at v_ex.c:372:38 > frame #8: 0x000000000148da62 view`vi(spp=) at vi.c:226:18 > frame #9: 0x0000000001319704 view`editor(gp=0x0000621000000100, argc=, argv=) at main.c:402:38 > frame #10: 0x00000000012d21dd view`main(argc=, argv=) at cl_main.c:115:9 > frame #11: 0x0000000001246c7d view`_start(ap=, cleanup=) at crt1_c.c:73:7 > (lldb) up 4 > frame #4: 0x00000000013113a9 view`log_line(sp=, lno=, action=) at log.c:266:21 > 263 len * sizeof(CHAR_T) + CHAR_T_OFFSET); > 264 ep->l_lp[0] = action; > 265 memmove(ep->l_lp + sizeof(u_char), &lno, sizeof(recno_t)); > -> 266 memmove(ep->l_lp + CHAR_T_OFFSET, lp, len * sizeof(CHAR_T)); > 267 > 268 lcur = ep->l_cur; > 269 key.data = &lcur; > (lldb) thread info -s > thread #1: tid = 208533, 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39, name = 'view', stop reason = Null pointer use > > { > "col": 21, > "description": "null-pointer-use", > "filename": "/usr/main-src/contrib/nvi/common/log.c", > "instrumentation_class": "UndefinedBehaviorSanitizer", > "line": 266, > "memory_address": 0, > "summary": "Member access within null pointer of type 'log_t'", > "tid": 208533, > "trace": [] > } > (lldb) c > Process 96507 resuming > /usr/main-src/contrib/nvi/common/log.c:266:21: runtime error: member access within null pointer of type 'log_t' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/main-src/contrib/nvi/common/log.c:266:21 in > Process 96507 stopped > * thread #1, name = 'view', stop reason = Null pointer use > frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39 > 36 } > 37 > 38 SANITIZER_WEAK_DEFAULT_IMPL > -> 39 void __ubsan::__ubsan_on_report(void) {} > 40 > 41 void __ubsan::__ubsan_get_current_report_data(const char **OutIssueKind, > 42 const char **OutMessage, > (lldb) bt > * thread #1, name = 'view', stop reason = Null pointer use > * frame #0: 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39 > frame #1: 0x00000000012c36b1 view`__ubsan::Diag::~Diag(this=0x00007fffffffc3c0) at ubsan_diag.cpp:354:29 > frame #2: 0x00000000012c4aef view`handleTypeMismatchImpl(Data=, Pointer=, Opts=(FromUnrecoverableHandler = false, pc = 19993957, bp = 140737488340592)) at ubsan_handlers.cpp:117:5 > frame #3: 0x00000000012c47aa view`::__ubsan_handle_type_mismatch_v1(Data=, Pointer=) at ubsan_handlers.cpp:142:3 > frame #4: 0x0000000001311565 view`log_line(sp=, lno=, action=) at log.c:272:37 > frame #5: 0x000000000130cd55 view`db_append(sp=, update=, lno=, p=, len=) at line.c:295:2 > frame #6: 0x000000000141b582 view`v_ecl_log(sp=, tp=) at v_ex.c:605:10 > frame #7: 0x0000000001419af2 view`v_ex(sp=, vp=) at v_ex.c:372:38 > frame #8: 0x000000000148da62 view`vi(spp=) at vi.c:226:18 > frame #9: 0x0000000001319704 view`editor(gp=0x0000621000000100, argc=, argv=) at main.c:402:38 > frame #10: 0x00000000012d21dd view`main(argc=, argv=) at cl_main.c:115:9 > frame #11: 0x0000000001246c7d view`_start(ap=, cleanup=) at crt1_c.c:73:7 > (lldb) up 4 > frame #4: 0x0000000001311565 view`log_line(sp=, lno=, action=) at log.c:272:37 > 269 key.data = &lcur; > 270 key.size = sizeof(recno_t); > 271 data.data = ep->l_lp; > -> 272 data.size = len * sizeof(CHAR_T) + CHAR_T_OFFSET; > 273 if (ep->log->put(ep->log, &key, &data, 0) == -1) > 274 LOG_ERR; > 275 > (lldb) thread info -s > thread #1: tid = 208533, 0x00000000012c8ef0 view`::__ubsan_on_report() at ubsan_monitor.cpp:39, name = 'view', stop reason = Null pointer use > > { > "col": 37, > "description": "null-pointer-use", > "filename": "/usr/main-src/contrib/nvi/common/log.c", > "instrumentation_class": "UndefinedBehaviorSanitizer", > "line": 272, > "memory_address": 0, > "summary": "Member access within null pointer of type 'log_t'", > "tid": 208533, > "trace": [] > } > > > === > Mark Millard > marklmi at yahoo.com > > From nobody Fri Jan 14 18:53:06 2022 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 958F4195F37F for ; Fri, 14 Jan 2022 18:53:26 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jb9Rn1C5wz3hqb for ; Fri, 14 Jan 2022 18:53:25 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-ed1-x52c.google.com with SMTP id o6so37321208edc.4 for ; Fri, 14 Jan 2022 10:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KmrRiV9BDUYOCQuXyFSmjFanQ39+6gMjU1hKM+Ud/Dw=; b=k2Drael8qG65qs2s0tmLWYaDsMgODf2+RsEdk2//P6pU3l6BI9dfxY8E7d7AXwC7qS fAxXkxuq2k5SrVuF1bsgnpMJrYyMrKHzyQMB3hXD9VcE69owOenc0PBPBiQPv1JV+LQx QNQHSQNYcnWrQ9GWVLtA5dZ01omrOKdnBtKPk31Iy2YB/2i/Y2yr/0nOYRHoq18NieF6 +CZGWfD/wbWl1SP36srUCd9yk6/aMy4sNHA0v3C7Hgm9noGRJculLLeAoazKbN5ZWJtE Pz4VcpXb0iaYqVLcp7CAWBj+JUGi1JCUWcPlbpvKBWHeTIbYWFy5OwroAZzS7dyo6sIK Vziw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KmrRiV9BDUYOCQuXyFSmjFanQ39+6gMjU1hKM+Ud/Dw=; b=O+o7YtMH5JkuT7odn7TbdCv606os7Hp9c9yyDDaHJomBKuaFLUGig2WV9+V2FSgT6T 2AoR7RcXFO9QFC5nLpHJUl8yvOv+RwgaE7LfdtjSTjQUx6h8s91NieEpm5+s3KmB/Ft2 3UVJHgzjSod47EQ47oM+sAALx+Lk9DpQ5smX1sKSDRToE0Un/RQy/SiQpebZ3O9DyXHK MNovrPXHVwBmC0XaPsBE+Gk0XsWqmdi7lu6OjpvcpC2QUEGYrfa9gaP9E2Bx1cDFgm8/ CfpL+5NnJNSe927ZI5SuAeQLKT+WIjTtwDhGz75lg3qbpPTQpHt5MbH9K50f2YqXX7CP hU1Q== X-Gm-Message-State: AOAM533z6SfCEEm8x6UCt0sKrsLU3b69t9VWUmnwjdJko/JxHfIXTRn5 VH/9wlPybuwxeQeLz+kneWRx+xmUG/rp8Qofrrw= X-Google-Smtp-Source: ABdhPJzVGwsl8fAvNTpOFOLy05QfW9lI5ezuqLOn0vSEh0eqbwpFzQY+qk4bKn02d2XryZ8Qvkll8TOkZCFQ7PT5890= X-Received: by 2002:a05:6402:502:: with SMTP id m2mr9061947edv.273.1642186397849; Fri, 14 Jan 2022 10:53:17 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <4fa413f4-f167-ce1d-ce2f-a2a05a34dc32@gmail.com> In-Reply-To: From: Pavel Timofeev Date: Fri, 14 Jan 2022 11:53:06 -0700 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Alexander Motin Cc: Warner Losh , Chuck Tuffli , freebsd-current Content-Type: multipart/alternative; boundary="000000000000e61b6d05d58f507a" X-Rspamd-Queue-Id: 4Jb9Rn1C5wz3hqb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=k2Drael8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of timp87@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=timp87@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[bsdimp.com,gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000e61b6d05d58f507a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=B2=D1=81, 17 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 17:52, Pavel Timof= eev : > > > =D0=B2=D1=81, 17 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 11:19, Alexander= Motin : > >> It may be a noise, but comparing logs I see in reboot case also >> "acpi_ec0: not getting interrupts, switched to polled mode". I am >> thinking whether the problem may be caused not by SSD, but by some >> resource conflict/misconfiguration in the system. Pavel, can you >> compare `devinfo -vr` and `lspci -vvvvv` in both cases. looking for any >> differences? Are you running the latest BIOS? >> >> On 12.10.2021 15:56, Warner Losh wrote: >> > One piece of data that would be good to have: >> > >> > nvmecontrol identify nvme0 >> > >> > There's an optional feature that none of my drives have, but that the >> Linux >> > driver does oddly >> > weird things when enabled. The output of that command will help me >> > understand if that may >> > be in play. Maybe we need to do oddly weird things too :) >> > >> > Warner >> > >> > On Sun, Oct 10, 2021 at 11:00 PM Warner Losh wrote: >> > >> >> >> >> >> >> On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev >> wrote: >> >> >> >>> =D1=81=D0=B1, 9 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:59, Warne= r Losh : >> >>> >> >>>> >> >>>> >> >>>> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev >> wrote: >> >>>> >> >>>>> >> >>>>> >> >>>>> =D0=BF=D1=82, 8 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:49, War= ner Losh : >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev >> >>>>>> wrote: >> >>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, = Warner Losh : >> >>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev > > >> >>>>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Warner Losh : >> >>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev < >> timp87@gmail.com> >> >>>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> Pavel Timofeev : >> >>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Chuck Tuffli : >> >>>>>>>>>>>> >> >>>>>>>>>>>>> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev < >> >>>>>>>>>>> timp87@gmail.com> wrote: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Hello >> >>>>>>>>>>>>>> I've got a Dell Latitude 7400 and tried installing the >> latest >> >>>>>>>>>>>>> 14.0-CURRENT >> >>>>>>>>>>>>>> (main-n248636-d20e9e02db3) on it. >> >>>>>>>>>>>>>> Despite other things the weird one which concerns me is >> >>>>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>>>> message I get sometimes on the console. >> >>>>>>>>>>>>>> It seems like I get it only after the reboot of the lapto= p, >> >>>>>>>>>>> i. e. not >> >>>>>>>>>>>>>> getting that message if I power cycle the laptop, at leas= t >> I >> >>>>>>>>>>> haven't >> >>>>>>>>>>>>> seen >> >>>>>>>>>>>>>> them for now in such cases. >> >>>>>>>>>>>>>> So when the laptop is rebooted I can't even take advantag= e >> of >> >>>>>>>>>>>>>> nvmecontrol(8) quickly. >> >>>>>>>>>>>>>> Well, it still works, but it takes tens of seconds to >> return >> >>>>>>>>>>> the output. >> >>>>>>>>>>>>> ... >> >>>>>>>>>>>>>> dmesg when power cycled - >> >>>>>>>>>>>>>> >> >>>>>>>>>>> >> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ >> >>>>>>>>>>>>>> dmesg when rebooted - >> >>>>>>>>>>>>>> >> >>>>>>>>>>> >> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I'm sort of curious about the time stamps for the log >> messages >> >>>>>>>>>>> in the >> >>>>>>>>>>>>> failing case. Something like: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> --chuck >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Well, I can't see timestamps in the verbose boot log. Am I >> >>>>>>>>>>> missing some >> >>>>>>>>>>>> configuration for that? >> >>>>>>>>>>>> >> >>>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >> >>>>>>>>>>>> nvme0: mem >> >>>>>>>>>>>> >> >>>>>>>>>>> >> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at dev= ice >> >>>>>>>>>>>> 0.0 on pci6 >> >>>>>>>>>>>> nvme0: attempting to allocate 5 MSI-X vectors (17 supported= ) >> >>>>>>>>>>>> nvme0: using IRQs 133-137 for MSI-X >> >>>>>>>>>>>> nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 >> >>>>>>>>>>>> nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, >> >>>>>>>>>>> MPSMAX 0 >> >>>>>>>>>>>> nvme0: Version: 0x00010300: 1.3 >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>>>>> nvd0: NVMe namespace >> >>>>>>>>>>>> GEOM: new disk nvd0 >> >>>>>>>>>>>> nvd0: 488386MB (1000215216 512 byte sectors) >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> Ah, sorry, provided wrong output. >> >>>>>>>>>>> Here is what you requested: >> >>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: >> mem >> >>>>>>>>>>> >> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff >> >>>>>>>>>>> at device >> >>>>>>>>>>> 0.0 on pci6 >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to >> allocate 5 >> >>>>>>>>>>> MSI-X >> >>>>>>>>>>> vectors (17 supported) >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 f= or >> >>>>>>>>>>> MSI-X >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: >> MQES >> >>>>>>>>>>> 1023, CQR, >> >>>>>>>>>>> TO 20 >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: >> DSTRD >> >>>>>>>>>>> 0, NSSRS, >> >>>>>>>>>>> CSS 1, MPSMIN 0, MPSMAX 0 >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: >> 1.3 >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: > >>>>>>>>>>> 512GB> NVMe >> >>>>>>>>>>> namespace >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 >> >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 >> 512 >> >>>>>>>>>>> byte >> >>>>>>>>>>> sectors) >> >>>>>>>>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt >> >>>>>>>>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt >> >>>>>>>>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> What happens if you set hw.nvme.use_nvd=3D0 and >> >>>>>>>>>> hw.cam.nda.nvd_compat=3D1 >> >>>>>>>>>> in the boot loader and reboot? Same thing except nda where nv= d >> >>>>>>>>>> was? Or does >> >>>>>>>>>> it work? >> >>>>>>>>>> >> >>>>>>>>>> Something weird is going on in the interrupt assignment, I >> think, >> >>>>>>>>>> but I >> >>>>>>>>>> wanted to get any nvd vs nda issues out of the way first. >> >>>>>>>>>> >> >>>>>>>>>> Warner >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Do you mean kern.cam.nda.nvd_compat instead >> >>>>>>>>> of hw.cam.nda.nvd_compat? >> >>>>>>>>> kern.cam.nda.nvd_compat is 1 by default now. >> >>>>>>>>> >> >>>>>>>>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I >> still >> >>>>>>>>> see >> >>>>>>>>> nvme0: Missing interrupt >> >>>>>>>>> and now also >> >>>>>>>>> Root mount waiting for: CAM >> >>>>>>>>> messages besides those >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by >> default >> >>>>>>>> these >> >>>>>>>> days. >> >>>>>>>> >> >>>>>>>> I'll take a look on monday starting at the differences in >> interrupt >> >>>>>>>> assignment that >> >>>>>>>> are apparent when you cold boot vs reboot. >> >>>>>>>> >> >>>>>>>> Thanks for checking... I'd hoped this was a cheap fix, but also >> >>>>>>>> didn't really >> >>>>>>>> expect it to be. >> >>>>>>>> >> >>>>>>>> Warner >> >>>>>>>> >> >>>>>>>> >> >>>>>>> I've recently upgraded to main-n249974-17f790f49f5 and it got ev= en >> >>>>>>> worse now. >> >>>>>>> So clean poweron works as before. >> >>>>>>> But if rebooted nvme drive refuses to work, while before the cod= e >> >>>>>>> upgrade it was just complaining about missing interrupts. >> >>>>>>> >> >>>>>>> currently dmesg show this: >> >>>>>>> nvme0: mem >> >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104ff= f >> at device >> >>>>>>> 0.0 on pci6 >> >>>>>>> nvd0: NVMe namespace >> >>>>>>> nvd0: 488386MB (1000215216 512 byte sectors) >> >>>>>>> nvme0: mem >> >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104ff= f >> at device >> >>>>>>> 0.0 on pci6 >> >>>>>>> >> >>>>>> >> >>>>>> Why is this showing up twice? Or is everything above this line le= ft >> >>>>>> over from the first, working boot? >> >>>>>> >> >>>>>> >> >>>>>>> nvme0: RECOVERY_START 9585870784 vs 9367036288 >> >>>>>>> nvme0: timeout with nothing complete, resetting >> >>>>>>> nvme0: Resetting controller due to a timeout. >> >>>>>>> nvme0: RECOVERY_WAITING >> >>>>>>> nvme0: resetting controller >> >>>>>>> nvme0: aborting outstanding admin command >> >>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >> >>>>>>> cdw11:00000000 >> >>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >> >>>>>>> nvme0: nvme_identify_controller failed! >> >>>>>>> nvme0: waiting >> >>>>>>> >> >>>>>> >> >>>>>> Clearly something bad is going on with the drive here... We looke= d >> >>>>>> into the completion queues when we didn't get an interrupt and >> there was >> >>>>>> nothing complete there.... >> >>>>>> >> >>>>>> The only thing I can think of is that this means there's a phase >> error >> >>>>>> between the drive and the system. I recently removed a second >> reset and >> >>>>>> made it an option NVME_2X_RESET. Can you see if adding >> >>>>>> 'options NVME_2X_RESET' to your kernel config fixes this? >> >>>>>> >> >>>>>> Warner >> >>>>>> >> >>>>>> >> >>>>>>> nvme0: mem >> >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104ff= f >> at device >> >>>>>>> 0.0 on pci6 >> >>>>>>> nvme0: RECOVERY_START 9362778467 vs 9361830561 >> >>>>>>> nvme0: timeout with nothing complete, resetting >> >>>>>>> nvme0: Resetting controller due to a timeout. >> >>>>>>> nvme0: RECOVERY_WAITING >> >>>>>>> nvme0: resetting controller >> >>>>>>> nvme0: aborting outstanding admin command >> >>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >> >>>>>>> cdw11:00000000 >> >>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >> >>>>>>> nvme0: nvme_identify_controller failed! >> >>>>>>> nvme0: waiting >> >>>>>>> >> >>>>>>> >> >>>>> >> >>>>> Sorry, it's showing twice due to multiple reboots. For one boot it= 's >> >>>>> like: >> >>>>> nvme0: mem >> >>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff >> at device >> >>>>> 0.0 on pci6 >> >>>>> nvme0: RECOVERY_START 9633303481 vs 9365971423 >> >>>>> nvme0: timeout with nothing complete, resetting >> >>>>> nvme0: Resetting controller due to a timeout. >> >>>>> nvme0: RECOVERY_WAITING >> >>>>> nvme0: resetting controller >> >>>>> nvme0: aborting outstanding admin command >> >>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >> cdw11:00000000 >> >>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >> >>>>> nvme0: nvme_identify_controller failed! >> >>>>> nvme0: waiting >> >>>>> >> >>>>> Well, neither Windows not Linux have any problems with the device.= I >> >>>>> understand they may be hiding it or workaround somehow. >> >>>>> >> >>>> >> >>>> Yea, I'm trying to figure out why your machine is different than >> mine, >> >>>> and what Windows or Linux do that is different. It may be dodgy >> hardware, >> >>>> but others have no trouble... >> >>>> >> >>>> I'll try setting NVME_2X_RESET in the kernel config and report back >> in a >> >>>>> while. >> >>>>> >> >>>> >> >>>> Thanks. If it helps, that tells me something. If it doesn't, that >> tells >> >>>> me something else. >> >>>> >> >>>> I suspect that it is somewhere else in the system, tbh, but I need = to >> >>>> find it systematically. >> >>>> >> >>>> Warner >> >>>> >> >>> >> >>> Surprisingly, setting NVME_2X_RESET in the kernel config hasn't >> changed >> >>> anything. I. e it didn't help. >> >>> >> >> >> >> While it would have been nice to have this be the fix, I'm not that >> >> surprised either. >> >> It was the biggest change of late, apart from the big re-arrangement >> that >> >> I'd done. >> >> >> >> So the other changes have moved from the occasional missing interrupt >> >> message >> >> (which the old code would get when a command wasn't completed in the >> >> timeout >> >> period, but that we found to be done when we scanned the completion >> queue. >> >> Now >> >> the device is detected fine (as before), but then doesn't do I/O at a= ll >> >> (including not >> >> completing the identify command!) and is worse. This is unexpected an= d >> I'm >> >> trying >> >> understand what happens on reboot that 'changes'the working state and >> why >> >> the >> >> new code behaves so differently. >> >> >> >> Warner >> >> >> > >> >> -- >> Alexander Motin >> > > > Thanks for the reply. > It's using the latest firmware. This is the first thing I do in such cas= e. > > > Attaching devinfo and lspci output. > These are diffs showing the difference between clean boot and a reboot: > > $ diff -u devinfo.ok devinfo.nok > --- devinfo.ok 2021-10-17 17:48:07.964346000 -0600 > +++ devinfo.nok 2021-10-17 17:48:07.886881000 -0600 > @@ -214,10 +214,6 @@ > nvme0 pnpinfo vendor=3D0x1c5c device=3D0x1639 subvendor=3D0x= 1c5c > subdevice=3D0x1639 class=3D0x010802 at slot=3D0 function=3D0 dbsf=3Dpci0:= 59:0:0 > handle=3D\_SB_.PCI0.RP13.PXSX > Interrupt request lines: > 0x85 > - 0x86 > - 0x87 > - 0x88 > - 0x89 > pcib7 memory window: > 0xcc100000-0xcc103fff > 0xcc104000-0xcc104fff > > $ diff -u lspci.ok lspci.nok > --- lspci.ok 2021-10-17 17:48:15.894470000 -0600 > +++ lspci.nok 2021-10-17 17:48:15.341379000 -0600 > @@ -132,7 +132,7 @@ > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=3D0mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME- > Capabilities: [d0] MSI: Enable+ Count=3D1/1 Maskable- 64bit+ > - Address: 00000000fee06000 Data: 0033 > + Address: 00000000fee06000 Data: 0034 > Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 0= 0 > DevCap: MaxPayload 128 bytes, PhantFunc 0 > ExtTag- RBE- FLReset+ > > Hi, I hope everyone is doing well. So several BIOS updates passed, now the BIOS version 1.15.1, but it works the same. At least on CURRENT built several days ago (main-n252414-0e8181c0123). What is interesting iwn(4) and iwlwifi(4) work the same way - only full power cycle makes wifi functional, simple reboot brakes it in most cases. Does anybody have any idea? --000000000000e61b6d05d58f507a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
=D0=B2=D1=81, 17 =D0=BE=D0=BA=D1=82. = 2021 =D0=B3. =D0=B2 17:52, Pavel Timofeev <timp87@gmail.com>:


=D0=B2=D1=81, 17 =D0= =BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 11:19, Alexander Motin <mavbsd@gmail.com>:
It may be a noise, but= comparing logs I see in reboot case also
"acpi_ec0: not getting interrupts, switched to polled mode".=C2= =A0 I am
thinking whether the problem may be caused not by SSD, but by some
resource conflict/misconfiguration in the system.=C2=A0 Pavel, can you
compare `devinfo -vr` and `lspci -vvvvv` in both cases. looking for any
differences?=C2=A0 Are you running the latest BIOS?

On 12.10.2021 15:56, Warner Losh wrote:
> One piece of data that would be good to have:
>
> nvmecontrol identify nvme0
>
> There's an optional feature that none of my drives have, but that = the Linux
> driver does oddly
> weird things when enabled. The output of that command will help me
> understand if that may
> be in play. Maybe we need to do oddly weird things too :)
>
> Warner
>
> On Sun, Oct 10, 2021 at 11:00 PM Warner Losh <imp@bsdimp.com> wrote:
>
>>
>>
>> On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev <timp87@gmail.com> wrote:
>>
>>> =D1=81=D0=B1, 9 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:59,= Warner Losh <imp@bs= dimp.com>:
>>>
>>>>
>>>>
>>>> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev <timp87@gmail.com> wrote:=
>>>>
>>>>>
>>>>>
>>>>> =D0=BF=D1=82, 8 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0= =B2 14:49, Warner Losh <imp@bsdimp.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev <= timp87@gmail.com&= gt;
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0= =B3. =D0=B2 15:22, Warner Losh <imp@bsdimp.com>:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timo= feev <timp87@gmail= .com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>=C2=A0 Warner Losh <imp@bsdimp.com>:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM P= avel Timofeev <tim= p87@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>=C2=A0 Pavel Timofeev <timp87@gmail.com>:<= br> >>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Chuck Tuffli <ctuffli@gmail.com>:<= br> >>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Aug 16, 2021 a= t 7:43 PM Pavel Timofeev <
>>>>>>>>>>> timp87@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello
>>>>>>>>>>>>>> I've got a Del= l Latitude 7400 and tried installing the latest
>>>>>>>>>>>>> 14.0-CURRENT
>>>>>>>>>>>>>> (main-n248636-d20e= 9e02db3) on it.
>>>>>>>>>>>>>> Despite other thin= gs the weird one which concerns me is
>>>>>>>>>>>>>>=C2=A0 =C2=A0nvme0:= Missing interrupt
>>>>>>>>>>>>>> message I get some= times on the console.
>>>>>>>>>>>>>> It seems like I ge= t it only after the reboot of the laptop,
>>>>>>>>>>> i. e. not
>>>>>>>>>>>>>> getting that messa= ge if I power cycle the laptop, at least I
>>>>>>>>>>> haven't
>>>>>>>>>>>>> seen
>>>>>>>>>>>>>> them for now in su= ch cases.
>>>>>>>>>>>>>> So when the laptop= is rebooted I can't even take advantage of
>>>>>>>>>>>>>> nvmecontrol(8) qui= ckly.
>>>>>>>>>>>>>> Well, it still wor= ks, but it takes tens of seconds to return
>>>>>>>>>>> the output.
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> dmesg when power c= ycled -
>>>>>>>>>>>>>>
>>>>>>>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8S= wJ
>>>>>>>>>>>>>> dmesg when reboote= d -
>>>>>>>>>>>>>>
>>>>>>>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38B= xh
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm sort of curiou= s about the time stamps for the log messages
>>>>>>>>>>> in the
>>>>>>>>>>>>> failing case. Somethin= g like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> $ grep "nv\(me\|d= \)" /var/log/messages
>>>>>>>>>>>>>
>>>>>>>>>>>>> --chuck
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Well, I can't see time= stamps in the verbose boot log. Am I
>>>>>>>>>>> missing some
>>>>>>>>>>>> configuration for that? >>>>>>>>>>>>
>>>>>>>>>>>> $ grep "nv\(me\|d\)&q= uot; /var/log/messages
>>>>>>>>>>>> nvme0: <Generic NVMe De= vice> mem
>>>>>>>>>>>>
>>>>>>>>>>> 0xcc100000-0xcc103fff,0xcc1050= 00-0xcc105fff,0xcc104000-0xcc104fff at device
>>>>>>>>>>>> 0.0 on pci6
>>>>>>>>>>>> nvme0: attempting to alloc= ate 5 MSI-X vectors (17 supported)
>>>>>>>>>>>> nvme0: using IRQs 133-137 = for MSI-X
>>>>>>>>>>>> nvme0: CapLo: 0x140103ff: = MQES 1023, CQR, TO 20
>>>>>>>>>>>> nvme0: CapHi: 0x00000030: = DSTRD 0, NSSRS, CSS 1, MPSMIN 0,
>>>>>>>>>>> MPSMAX 0
>>>>>>>>>>>> nvme0: Version: 0x00010300= : 1.3
>>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvd0: <PC611 NVMe SK hy= nix 512GB> NVMe namespace
>>>>>>>>>>>> GEOM: new disk nvd0
>>>>>>>>>>>> nvd0: 488386MB (1000215216= 512 byte sectors)
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ah, sorry, provided wrong outp= ut.
>>>>>>>>>>> Here is what you requested: >>>>>>>>>>> $ grep "nv\(me\|d\)"= /var/log/messages
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: nvme0: <Generic NVMe Device> mem
>>>>>>>>>>> 0xcc100000-0xcc103fff,0xcc1050= 00-0xcc105fff,0xcc104000-0xcc104fff
>>>>>>>>>>> at device
>>>>>>>>>>> 0.0 on pci6
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: nvme0: attempting to allocate 5
>>>>>>>>>>> MSI-X
>>>>>>>>>>> vectors (17 supported)
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: nvme0: using IRQs 133-137 for
>>>>>>>>>>> MSI-X
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: nvme0: CapLo: 0x140103ff: MQES
>>>>>>>>>>> 1023, CQR,
>>>>>>>>>>> TO 20
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: nvme0: CapHi: 0x00000030: DSTRD
>>>>>>>>>>> 0, NSSRS,
>>>>>>>>>>> CSS 1, MPSMIN 0, MPSMAX 0
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: nvme0: Version: 0x00010300: 1.3
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: nvme0: Missing interrupt
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: nvme0: Missing interrupt
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: nvme0: Missing interrupt
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: nvd0: <PC611 NVMe SK hynix
>>>>>>>>>>> 512GB> NVMe
>>>>>>>>>>> namespace
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: GEOM: new disk nvd0
>>>>>>>>>>> Aug 21 04:34:36 nostromo kerne= l: nvd0: 488386MB (1000215216 512
>>>>>>>>>>> byte
>>>>>>>>>>> sectors)
>>>>>>>>>>> Aug 21 04:34:42 nostromo kerne= l: nvme0: Missing interrupt
>>>>>>>>>>> Aug 21 04:35:36 nostromo kerne= l: nvme0: Missing interrupt
>>>>>>>>>>> Aug 21 04:35:50 nostromo kerne= l: nvme0: Missing interrupt
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What happens if you set hw.nvme.us= e_nvd=3D0 and
>>>>>>>>>> hw.cam.nda.nvd_compat=3D1
>>>>>>>>>> in the boot loader and reboot? Sam= e thing except nda where nvd
>>>>>>>>>> was? Or does
>>>>>>>>>> it work?
>>>>>>>>>>
>>>>>>>>>> Something weird is going on in the= interrupt assignment, I think,
>>>>>>>>>> but I
>>>>>>>>>> wanted to get any nvd vs nda issue= s out of the way first.
>>>>>>>>>>
>>>>>>>>>> Warner
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Do you mean kern.cam.nda.nvd_compat in= stead
>>>>>>>>> of hw.cam.nda.nvd_compat?
>>>>>>>>> kern.cam.nda.nvd_compat is 1 by defaul= t now.
>>>>>>>>>
>>>>>>>>> So I tried to set=C2=A0 hw.nvme.use_nv= d to 1 as suggested, but I still
>>>>>>>>> see
>>>>>>>>>=C2=A0 =C2=A0nvme0: Missing interrupt >>>>>>>>> and now also
>>>>>>>>>=C2=A0 =C2=A0Root mount waiting for: CA= M
>>>>>>>>> messages besides those
>>>>>>>>>
>>>>>>>>
>>>>>>>> OK. That all makes sense. I'd forgotte= n that nvd_compat=3D1 by default
>>>>>>>> these
>>>>>>>> days.
>>>>>>>>
>>>>>>>> I'll take a look on monday starting at= the differences in interrupt
>>>>>>>> assignment that
>>>>>>>> are apparent when you cold boot vs reboot.=
>>>>>>>>
>>>>>>>> Thanks for checking... I'd hoped this = was a cheap fix, but also
>>>>>>>> didn't really
>>>>>>>> expect it to be.
>>>>>>>>
>>>>>>>> Warner
>>>>>>>>
>>>>>>>>
>>>>>>> I've recently upgraded to main-n249974-17f= 790f49f5 and it got even
>>>>>>> worse now.
>>>>>>> So clean poweron works as before.
>>>>>>> But if rebooted nvme drive refuses to work, wh= ile before the code
>>>>>>> upgrade it was just complaining about missing = interrupts.
>>>>>>>
>>>>>>> currently dmesg show this:
>>>>>>> nvme0: <Generic NVMe Device> mem
>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0x= cc104000-0xcc104fff at device
>>>>>>> 0.0 on pci6
>>>>>>> nvd0: <PC611 NVMe SK hynix 512GB> NVMe n= amespace
>>>>>>> nvd0: 488386MB (1000215216 512 byte sectors) >>>>>>> nvme0: <Generic NVMe Device> mem
>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0x= cc104000-0xcc104fff at device
>>>>>>> 0.0 on pci6
>>>>>>>
>>>>>>
>>>>>> Why is this showing up twice? Or is everything abo= ve this line left
>>>>>> over from the first, working boot?
>>>>>>
>>>>>>
>>>>>>> nvme0: RECOVERY_START 9585870784 vs 9367036288=
>>>>>>> nvme0: timeout with nothing complete, resettin= g
>>>>>>> nvme0: Resetting controller due to a timeout.<= br> >>>>>>> nvme0: RECOVERY_WAITING
>>>>>>> nvme0: resetting controller
>>>>>>> nvme0: aborting outstanding admin command
>>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw1= 0:00000001
>>>>>>> cdw11:00000000
>>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid= :15 cdw0:0
>>>>>>> nvme0: nvme_identify_controller failed!
>>>>>>> nvme0: waiting
>>>>>>>
>>>>>>
>>>>>> Clearly something bad is going on with the drive h= ere... We looked
>>>>>> into the completion queues when we didn't get = an interrupt and there was
>>>>>> nothing complete there....
>>>>>>
>>>>>> The only thing I can think of is that this means t= here's a phase error
>>>>>> between the drive and the system. I recently remov= ed a second reset and
>>>>>> made it an option NVME_2X_RESET. Can you see if ad= ding
>>>>>> 'options NVME_2X_RESET' to your kernel con= fig fixes this?
>>>>>>
>>>>>> Warner
>>>>>>
>>>>>>
>>>>>>> nvme0: <Generic NVMe Device> mem
>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0x= cc104000-0xcc104fff at device
>>>>>>> 0.0 on pci6
>>>>>>> nvme0: RECOVERY_START 9362778467 vs 9361830561=
>>>>>>> nvme0: timeout with nothing complete, resettin= g
>>>>>>> nvme0: Resetting controller due to a timeout.<= br> >>>>>>> nvme0: RECOVERY_WAITING
>>>>>>> nvme0: resetting controller
>>>>>>> nvme0: aborting outstanding admin command
>>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw1= 0:00000001
>>>>>>> cdw11:00000000
>>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid= :15 cdw0:0
>>>>>>> nvme0: nvme_identify_controller failed!
>>>>>>> nvme0: waiting
>>>>>>>
>>>>>>>
>>>>>
>>>>> Sorry, it's showing twice due to multiple reboots.= For one boot it's
>>>>> like:
>>>>> nvme0: <Generic NVMe Device> mem
>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000= -0xcc104fff at device
>>>>> 0.0 on pci6
>>>>> nvme0: RECOVERY_START 9633303481 vs 9365971423
>>>>> nvme0: timeout with nothing complete, resetting
>>>>> nvme0: Resetting controller due to a timeout.
>>>>> nvme0: RECOVERY_WAITING
>>>>> nvme0: resetting controller
>>>>> nvme0: aborting outstanding admin command
>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:000000= 01 cdw11:00000000
>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0= :0
>>>>> nvme0: nvme_identify_controller failed!
>>>>> nvme0: waiting
>>>>>
>>>>> Well, neither Windows not Linux have any problems with= the device. I
>>>>> understand they may be hiding it or workaround somehow= .
>>>>>
>>>>
>>>> Yea, I'm trying to figure out why your machine is diff= erent than mine,
>>>> and what Windows or Linux do that is different. It may be = dodgy hardware,
>>>> but others have no trouble...
>>>>
>>>> I'll try setting NVME_2X_RESET in the kernel config an= d report back in a
>>>>> while.
>>>>>
>>>>
>>>> Thanks. If it helps, that tells me something. If it doesn&= #39;t, that tells
>>>> me something else.
>>>>
>>>> I suspect that it is somewhere else in the system, tbh, bu= t I need to
>>>> find it systematically.
>>>>
>>>> Warner
>>>>
>>>
>>> Surprisingly, setting NVME_2X_RESET in the kernel config hasn&= #39;t changed
>>> anything. I. e it didn't help.
>>>
>>
>> While it would have been nice to have this be the fix, I'm not= that
>> surprised either.
>> It was the biggest change of late, apart from the big re-arrangeme= nt that
>> I'd done.
>>
>> So the other changes have moved from the occasional missing interr= upt
>> message
>> (which the old code would get when a command wasn't completed = in the
>> timeout
>> period, but that we found to be done when we scanned the completio= n queue.
>> Now
>> the device is detected fine (as before), but then doesn't do I= /O at all
>> (including not
>> completing the identify command!) and is worse. This is unexpected= and I'm
>> trying
>> understand what happens on reboot that 'changes'the workin= g state and why
>> the
>> new code behaves so differently.
>>
>> Warner
>>
>

--
Alexander Motin


Thanks f= or the reply.
It's using the latest firmware. This is the=C2= =A0 first thing I do in such case.


= Attaching devinfo and lspci output.
These are diffs showing the d= ifference between clean boot and a reboot:

$ diff -u devi= nfo.ok devinfo.nok
--- devinfo.ok 2021-10-17 17:48:07.964346000 -0600+++ devinfo.nok 2021-10-17 17:48:07.886881000 -0600
@@ -214,10 +214,6 = @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nvme0 pnpinfo vendor= =3D0x1c5c device=3D0x1639 subvendor=3D0x1c5c subdevice=3D0x1639 class=3D0x0= 10802 at slot=3D0 function=3D0 dbsf=3Dpci0:59:0:0 handle=3D\_SB_.PCI0.RP13.= PXSX
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Inter= rupt request lines:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A00x85
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A00x86
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x87
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x88
- =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x89
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pcib7 memory window:
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00xcc100000-0= xcc103fff
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A00xcc104000-0xcc104fff

$ diff -u = lspci.ok lspci.nok
--- lspci.ok 2021-10-17 17:48:15.894470000 -0600
= +++ lspci.nok 2021-10-17 17:48:15.341379000 -0600
@@ -132,7 +132,7 @@=C2=A0 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=3D0mA PME(D0+,D1-,D2-,D3hot= +,D3cold+)
=C2=A0 Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0= PME-
=C2=A0 Capabilities: [d0] MSI: Enable+ Count=3D1/1 Maskable- 64bit= +
- Address: 00000000fee06000 =C2=A0Data: 0033
+ Address: 00000000f= ee06000 =C2=A0Data: 0034
=C2=A0 Capabilities: [40] Express (v2) Root Com= plex Integrated Endpoint, MSI 00
=C2=A0 DevCap: MaxPayload 128 bytes, P= hantFunc 0
=C2=A0 ExtTag- RBE- FLReset+

=

Hi,
I hope everyone is doi= ng well.
So several BIOS updates passed, now the BIOS version 1.1= 5.1, but it works the same. At least on CURRENT built several days ago (mai= n-n252414-0e8181c0123).
What is interesting iwn(4) and iwlwifi(4)= work the same way - only full power cycle makes wifi functional, simple re= boot=C2=A0brakes it in most cases.
Does anybody have any idea?
--000000000000e61b6d05d58f507a-- From nobody Sat Jan 15 01:28:52 2022 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 CFD8619424E1 for ; Sat, 15 Jan 2022 01:29:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JbLDG42Tfz3JnF for ; Sat, 15 Jan 2022 01:29:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642210135; bh=P3OscRwlQk16nIRSxw7FazZUMtW1Aw5QwNFOZ360soc=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=VL8hANgD5xtykmJmWdmH2OCpk2BssMlUrmaeeyDlzFI8Q1ZqRRYDR1xfOLqKx8L21PaHixvH9Uc7lzyLFJRnv0vIGzZNIrCzUryDoSMAme3/CC5mPlfpxDnC4trU5EnvLbVMOc+a+Z0xiFfYSBt8lx9lByNr3QE7OwR/fCL5RMB7DBc4RB2pqpvvYnArgpgHisDmGZpe50NI72vffZ5xmScHJMwaJ8LnOwdvNy7ySq4E2ZpG/9BJpo6e/3dYbAbTj/988vGlXpNaJc1wrWba4AyU6H3UjyA2Wy1bPb39QzBwWFUvjLkCa6/aMz6cWnRPBiuhejdVzyKSw+wHRvF+UA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642210135; bh=2boNG6puzkl61GM7F1QFwUWg3VDYRcMj5m/BP6/vQET=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=afH7rJZGn3zwGKK+x38EWFfMy2ANZPC3wIReaXzr3dm3x0/56fqipjr8Gq/Lqqg22aSnJEPNP2267AWmUKEIIucttEAD61W/aeTT1d/MiQHpryzFT5xftA7/0+40Hm2dR9tBu/u2+8NdcyiYGzpibqPnEz3QOI3uhHCQjfT1bi7h1WPNEP5O4KvJmUbJivZz+TFGV5x0SxLI5VrxvDZ6Xm8/Iubs5esLsBQjCN/ne4TdoU/ayOZNp4DrnYD+bIQsR2PM565lGmFrmu/rZLPXzj1G89Lr8X7ufb2mxj+mypD6iAbEJOXoy4Zioq6XgxoOhOpz7hwWixxUElK91fjmSA== X-YMail-OSG: 9mU04KQVM1nF8dbmkTci0pEHANcvYlNTjFi7BCkKbWQV1hXxUxZwWZlsURougIc qn6uuSl5idtybDBRXCVpMHB9WwZk5t.jV4ChG0gRrPB9UMuEg6P5Su1Sy5lfQJv9HYVkU6NazS8U GRHRd2LVmLJ4HwoqL1DePp_LTD69BUuD8Nf3Sp0Ij5a9vcoHf6z2VTl_WYJbzvKf3guwwPpyw7Bx ybi5PGjjimWPeXqCJ2WevllDQIoCq4sDUBcECbTh1QAU_oD1TL6WebWHeBMLLNsVsNGB3drFmI94 t578yL8QQsPVl4Pc6ltl2izA08ZmtNufDI0Jrb6ZsxnJflnkqBr8uqAbhWHMbrVnQkL7uVsq84cr AUgK8vpyfjHO3zdACZpjJQaTHZYB57u7w8vq8nDIUgJg8O_ygOC7SdSC0ED7XNI.04uApC2IM50G eJK2PxenTkPTzfG47bffq8PcdzoDfkyGGwJBxr7bFermH38oA9wdPIkqqvyBEyC153kKlu.Gf1iT j6sjwXpKHUaU6oD7ZAYzGf0mSpHRiJXwfNTujQSOZyqQ0BZfGS9eg.0XS1S1svtQF1X7Y9RO64tq uY8CIAQ5NzDcve3UZCmICvzru3Cychi6uKT6HSIh6R8eFImwdm1XHCsv3Q3wq_BtLapUc.KqF_pN 9KdmeHcODSKeRAn8ZGuxr6wt1nFxG0rt5R3MpoEJqdsdOYt33q.neVmoPsLjU.0BV33nBmGk2TjD 8fv2f1H6d8PXonTKollf1JGYw1f_9fkP.XQnelMq1ZRwZF08tHcp1QDmUCpeWCSsMeWfTCiJckxu BBrmt_BeO18XVOEdf5WFgGp0HwCKKRpXbYdJqWQfYTlJb.PnuBciPmfrJfuAb2ueaqyt9qhVQ0w2 je.ePc_zkHdYhsxwT_1GKwSqjTpIb16Uz75AX3MmmFjdF10bvHGLPML.ZUtwz7aITJvA4KgcnZ.8 vWSWESH31A8R8ULIUJNmflGZV67p1GTv1MVKaCAvoY0kNX23jMcBb1c9hGuvHii3shmdyle9KP0d LyN0QXD_DLPPrPMht7oUWTFQkV_V1HBnTyuL7i6.4giq0hZCl38c.8kXcLNZBWpMUyaNexBYwiLq x6NTvwcrdxgUZ4q9N85EPUZFKiuk8Sla_oVrKUUly017OXtY4QmLsr8JvIU6vI5uefYLlYdgaYN1 DSV0myBZogcKIaPZSHvN5TUtoU34xoNoR_dleB_GFg02ueEJ6fZXcCF.ImsFhn8Yp4W8veJb9gbZ MNZgNl2c.chh5l.pR71kTRF0y4s7PKhvzFk9KmyP7uvQZfBjrEPY1wbsG6BzkByBY2M6ivn_acjR VAsmyWwa6IwLQ_3bPRyYVX0blVyy76zADF57S6saIqxKRk5mWuClO6IpkPjwDKI21nDh.q1601MG XcPL3KNanb8z2mB9GjDM.2HqTBsPxkFCL4LsVTHKbxJLE3l_kxr7YdMAKZCPCs36UHcmUEqGybg7 72PTPTAVrUEd2.9zFVkB10RJa6XaSWK6.j53aUjQeJsgdnjFZYWvSfW.6yUH7phVKm1YrqBB5PaM DOQfUJhAzFhy5T7Ex8Ye.JgAqiJaE3LiVcFUnaB_S9uKDH2MyzlAvEBT5kt_EVOyoHbQPnD1EhXY FbNL2qE7ARg8jFHtmj8SIN6moO2fw3zpFOyyRxLy3kYbffrpUG5iSLYIJLbjn_xGEvMFiFJ1s7bX Js.fM6eU_T8BKxcsrPxiCx6vLg0djVWEOlwfRj5QH9PfVUZnB0La6TpbH8e9VB6iQianeLf7nw9u 4EYHZv7rAM.Jwjnwat_RI4Ox7rqdSyI3f9OC1gxRTTNfkho0T1jeUnkG3.j4aNcUf4L6GfL1PXed Tt8PzVUxMTDZoMZgUaUlJwA5EkXEsSaLVXmWRiihn.aaqgfh1EOEiQo8qvPxkTUXPZUZoTrC3f8n ENRR_QcK95yLb8JDDhWLb7JLYtZIA0wvj4QDFANJIXs8xsTMGO90yQB77BBBOaOEnd8z27q5I7IX uNUUtc2q9zkg6n6QZjeI_5TBK_cM5YlBwBz8_zLvGgnVIXK.YOUbL7a1vEX8vgRGxJi1hhu7TedH w08OQnoPhQv6MM1J_Wz5bdq_dgIDDZ3WgJvcG7hX3WX_pU_lT4UaPICKsnV_2rBAdoHUEX7KYf8E qT5za.HrrPwc7ht0ntqDSqpyEe.i1Xt88WCuPzcqoNXnKO11bXn7KF520qkBpkoul0RlDYzADnat eVBSwBliywO_AXcd5bFnrUFfJStAAthki7zqtQUUZCJbrejYofsULXph56wOYViP71vn9MlWwr6P X X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Jan 2022 01:28:55 +0000 Received: by kubenode515.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cb7da48feb088e6bae5ed2229f730082; Sat, 15 Jan 2022 01:28:52 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: ASAN: "ls -l, *" AddressSanitizer warning: "unexpected format specifier in printf interceptor: %*j'" Message-Id: Date: Fri, 14 Jan 2022 17:28:52 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4JbLDG42Tfz3JnF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=VL8hANgD; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N # ls -l, * /usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying = zero offset to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/lib/libc/stdio/fread.c:133:10 in=20 =3D=3D47404=3D=3DAddressSanitizer: WARNING: unexpected format specifier = in printf interceptor: %*j' (reported once per process) -rwxr-xr-x 1 root wheel 4287752 Jan 14 14:14 a.out -rw-r--r-- 1 root wheel 281 Jul 2 2021 bt.c -rw-r--r-- 1 root wheel 580662 Jan 15 01:10 kyua-test-run2.txt -rw-r--r-- 1 root wheel 2128 Apr 22 2021 listen_sock_peercred.c -rw-r--r-- 1 root wheel 149 Jan 14 14:14 sigaltstack_get.c -rw-r--r-- 1 root wheel 50 Jul 16 2021 trivial.cpp Unfortunately, running under lldb did not stop for the "unexpected = format specifier in printf interceptor" notice, so I do not have a backtrace = for this. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 15 05:38:56 2022 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 76CE91943FF1 for ; Sat, 15 Jan 2022 05:39:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JbRmk1X3Lz4Zbx for ; Sat, 15 Jan 2022 05:39:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642225140; bh=Ec8QGjQZiIvz0rREJEtb3QoDxVDkNOGgTQ2STP9t/cc=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=GgLASp6pEBfZy7Cy/ZfGzXXEh8Jxiw5ACjEVRBp/dxZKzpxjoOiFoFQ3TsYwuV5oKyJtO9SirFiUbBfB763MKtP/cX5lMhfQyhVoU8V5d8VvK1JcXVYrt+SKKWQXhVBDP/GHgTBMKbbAzgyb+kusupzirv85E5MrMVToZs7CBjac+rcblzZwIFdzWK0QbNgqy9RwczAicrSzZQv/3pFuEcusboupDdvazQk2mkLzQd3kFMhc3k549tM3csDamFPWL9Ry7T4aLhh69cBmB3Ed8QWDg3BxoYmZIESPFl5hsz4uRI2n98lkpG8RkLROxas6r3+n/9qMb8cFxY2QO9Hv1Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642225140; bh=l3xQOP/QeEppkfRaPYq+6TFHSSw7zmPP9hes8nn04b1=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=X1Rwg5PKC+CAqGBTzfqN1vDbH0YnMF5j0AlRUleqZBMk4hQZ6FHYCh6MJtNDLyhj4AHXYkgCwHAc6UgGed3pZSOCGly+H+RlPg+j0y8ri4YhH3+wyiaHR0wnuhgSC0CmaNFQJuHXwLgG41exeNqf9X8o2i6bSvS8tcyT2XRY8vZKKeLT40SKLmOlNe848cI30xB5afGXFOltbneyox7qAAHID0TWXl5CgeusPT92pW0iUmEP7cHi2ocnH5uKJPasJLiZA1/IBYSc9SMA/AbJilXf5+zRi6xJJLp9dhKOOEwuYUq36OXnew0soCnjKdPFuZZu4SvvodlxuSWUmXSU2Q== X-YMail-OSG: gNcrhlsVM1lAt8sCr4GA0f6AjmaP0_5zxiIDILKvrMDwiT1HTTeQ_OtSnQhDYPU TD96Jg8xTUyJMhZKeEqzpZhmCQ9a0QkcjiCNB1He3r7lXY6cGtmX49ZKZc8TqeMf63NogSXgF5FN Oym_Ch_F2fZSYApJ4H0VDjH6mDv2CEoZOSsNp2D1EB4aQmuxFsDxcB.WUfIKKkmMVJJ.SzVpUB7j 5im6FWTfBX6VX35wIGNC5NmtruHKBvmUMeZzu0G7PKztzeAWqlL0Y_CkEUldfzh49yqO1HiAjVy9 6uYVTfV7rVJpt1d5L6YxpmfcRC2aQTUKt08S.96r6b.RttVBex1JI2jt3slWRLDuEx54HGeyWmTA 0n4FX4jE7HqjOYK6szob5mQl9FVJ.WY0IxRx82D6H0Er_uFJ3LKDAoN6vvY7lj1ZAVxis7zsUBNB nms5bcDAnLjH2_ag5.uExyzfsMZmiAoC2FSoKQ1eb5vuMAOrMFhZgc2bvbUrlBrQVQJWhp5lOc8Q GHu19n.l4LfPQhZ11DpW_iiVRTW8Dm_ohwEx1QZSJd.jvAo2JMcQA0ze2cz5LWuXbceSuVkz84lF WnFzHMevjaTw.HYzPwhrz5OlDAtx389M4zp16hCJnaaSC23igckXLWNpwE0W3dc..Le5cqngeIXU 6fOBf_S2cpnrCDuv1ZZvxjhkuRyuMZ3.ADDBLB5SL5g7r4zy.CyPsZrnsMmIIVt1kEbW7Ay3Ppk_ 8F7cNn3GEe7OGEMaGwjoXWB_jfIHN8AwN0NKqzMyO_YaxaeXnAHJ4PnsXTjA8c15XWkxud6xVcQG fN0xyzICi.NBsZl.rT2.D4vsTiR8Lgq9W9n73g.cyq7jegLIg_l_zBsrTaEtLO8XdwmSN3xHCb44 ._fDoqqpEtpscUTV7anbGbpyHvk3lsMIgzx3wIEZylAhXkTKS3tn8os7s0UImQ74zjNQrxRhCI_l 6mGgrmFzBr1k7_I5.JcMPVrbezFv6iqrim8pW9g3NeLL42XghZLVyjFD5Arg1P5c614yMRIMqX8S nu0gdd2i1KdkVVF11nbxtMKtJizMlXDYXoxuBY2BiD3npQg.mbAgqh0DXrlvyujUDOg0dfx6CipK VhJsQ7I5bfeik_ftZol2cs91AxwYGd0kDrlrxZzvbcSKpDJqrTyFQ6JJU5QARvA5NRBhlViGAKKP J34V8tx2iQW3K0N8CTu5hluDnN3KTyQwt7VFRtWaxsnSLdEu3g2V1nIECP9NZ98npdHpJ4PBkt4B bmD5NI9mfB7G2A9A8QO06KmZjQzAvkXVN8J223.JDaLcy_k7ZNAKtsGsHsqDNIwmiHUaarIcWM8i YjTjaK0NgxvMcRsoxLRXV3wBJEFA6zHKC6fuB3ihSiXKgOS3xhaK0_k4Zp.AHXbF.mJoXkeUsyO6 tayMBHVwvRcS1LN7vgL9_HucByJ.T95tGr.jtiK7en67lED1Sj8qBjdiAe5sRQupGcFaYZ2PRg8M Lsny.KbqndSATI2cGGDDjWeijiGqBHdpsQomdhU_gCvf96KYZLtsFDTfzLHF8QSdjCfc3HEUJinm StCDmXfuwWlW1vIUSm.bhiDCru.r71aXDgdH6OqLjBskWiAzB0oYoyhWFndXBV2ZD87pRTOTI30m QQejKUWypReBY4pItcw05HfAwrb6j7Wf.qI3Ql_B.89E5seJMUX06Ba2u_533kdhIXC0r3jWQwek mEhpKFU_3eVlFz8UuER84jbSdtummW7F3.MLgLK23iB2Zc61hl4nyxtmrzjD2tAuBHhcqu.vc9ox bquNmnSN0EJ_RilpassrTpcXGRXf8fqsfumnsYaSl2PDHm4Mq1AQIWl_FWLHyOVISbDFbCo7oTQq Bl.pvDDKftcQYUOpaM_HNNPDKLPEZVuDaAkcZB2EayAnveubkh13wWKVESYkHYcrMwFCOgVMlz0y VBE0xkJqkEhruZWkmv2aGu7bAu5C1E7JGFAJL2b33ddO3Tz6zgcGoO7T310HhXlTME53BI.OHuX1 3nOBUSTy7Q_y73Qw6jsfTIF152ZBALYlzUHGFrSpEbgAmTeJspd6YuFUhQwQXnhRtwJPiMTjZHg9 QMhkDIJ0v1s5XglMOEf.1gkLkM0L5WGBWMMJZmx3Y2WrysnsiNmg52j4f_g7QRatMpU0_gfx8u9k 0B_i8w.Ja1l7UukkayrnpqDDxloa2eh6M3qGv7mYRFJ2X_8dIGzegCzJzNJmWIrqchI6ZzJmulel 61SBE4Sd5yNqF_NEFK21Ik8PhCQ6TaLFA5U71z845hWc5rJZYy0D37hVH.O0atMyOMj0V4QvHLv8 V_r57ewwlJYRm9u5N X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Jan 2022 05:39:00 +0000 Received: by kubenode517.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fef330de30ab6e91d7c9d230deff12e2; Sat, 15 Jan 2022 05:38:57 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 4a864f624a70 - main - vm_pageout: Print a more accurate message to the console before an OOM kill Message-Id: <1EF55D96-F7E3-4AA6-A331-782362A70878@yahoo.com> Date: Fri, 14 Jan 2022 21:38:56 -0800 To: Mark Johnston , freebsd-current , dev-commits-src-main@freebsd.org X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <1EF55D96-F7E3-4AA6-A331-782362A70878.ref@yahoo.com> X-Rspamd-Queue-Id: 4JbRmk1X3Lz4Zbx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=GgLASp6p; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Thanks. This will allow me to remove part of my personal additions in this area --and my having to explain the misnomer when trying to help someone analyze why they end up with OOM activity so they can figure out what to do about it. There seem to be two separate sources of VM_OOM_SWAPZ. Showing my personal additions for them (just making them explicit in the sequence of messages generated): diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c index 01cf9233329f..280621ca51be 100644 --- a/sys/vm/swap_pager.c +++ b/sys/vm/swap_pager.c @@ -2091,6 +2091,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) 0, 1)) printf("swap blk zone exhausted, = " "increase = kern.maxswzone\n"); + printf("swp_pager_meta_build: swap blk = uma zone exhausted\n"); vm_pageout_oom(VM_OOM_SWAPZ); pause("swzonxb", 10); } else @@ -2121,6 +2122,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) 0, 1)) printf("swap pctrie zone = exhausted, " "increase = kern.maxswzone\n"); + printf("swp_pager_meta_build: swap = pctrie uma zone exhausted\n"); vm_pageout_oom(VM_OOM_SWAPZ); pause("swzonxp", 10); } else Care to comment on the distinctions and why there are two contexts classified as "out of swap space"? Would either one show the swap space as (nearly?) all used in, say, top? Or might one of them still end up looking like a misnomer from just a top (or whatever) display? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 15 15:55:18 2022 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 B86081965AE5; Sat, 15 Jan 2022 15:55:27 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JbjRz4f05z3npK; Sat, 15 Jan 2022 15:55:27 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x72a.google.com with SMTP id c190so12500762qkg.9; Sat, 15 Jan 2022 07:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=KwM405kC3ch1HgHSuJTgf7MpXd/UWJ6HyONVOLyEz+0=; b=e15dq1JAaSAe0VD4sbku28877rYcp/Jn9jnOA0EElvVS0WsKp+gJrLMpfyPitYCGw+ waJv0VoqKpQ1sP+BoS44OSPGftZaA7U7WkMR/+hlUG6ImW20WQICHNK5zrnumgn5ZuMP 33btZ29Zg0z8cjIj8fVAOCSHT2+qTcqrV/vfwuoYGdrgv7mB3gQ3mPqa+oiB68WGLuVi 26eP8m8ncCMzCSJ5M+EApKdFQDkqLYRG+cFIIueHrjz93cVNlaSIiN+j55rS+Er9YqXV AAU/kN/UxS/d2aw20Hq6iNyk8HQ0+7vSfgwBAHGWTte1n4xeKYPmpXNhvs3fauKQKoLr 0PzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=KwM405kC3ch1HgHSuJTgf7MpXd/UWJ6HyONVOLyEz+0=; b=EP0xuFKH9Zot8UyzyVcrpfwkqnHf1BlsTajJvmHJCe7gBG2wxTRzZL0PQWQr7pBIw9 Hl4XIlzTju4SU7HsRPRVD5bxFUQxgLNRExJ3recMYwVko7a5urCkMIBsT+iZsG+K0TgI Pv+v3FqXLxLjw8jG9HFPFjI5qGJRm8RXwBx+dFPZVTU+5bjbQCFt59cEX3y+AyNbxybu MQGf/HSfM+laJ/5OUXLhxKkdsvsRSSYZmD6u8kdUO/DC0WXJ9j9N3BBuQAbkcuslhi/z d2tU8Kref5KhPJuRUKqu5kbiJBH1VpuPQuACz4wHKjDZdx4yiXEmS3fOby8m4Gc0Thlk r3aQ== X-Gm-Message-State: AOAM5324rxzytRdB2u/md7I3H1S2v2K5bBI21gL7XJ+zAgMtywcKqE9B /rqu+xz3PvMp0lLOI3JpbzlD8FMfHmI= X-Google-Smtp-Source: ABdhPJy0vFF+yIXJafxYNh2l2YYJhQnPTDnpVjZ8XR8I+DJdaizs0xdKvIk1GsNHQxEmM2/Fa+jyew== X-Received: by 2002:ae9:ef51:: with SMTP id d78mr9832684qkg.198.1642262121481; Sat, 15 Jan 2022 07:55:21 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id j186sm2061354qkf.43.2022.01.15.07.55.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Jan 2022 07:55:20 -0800 (PST) Date: Sat, 15 Jan 2022 10:55:18 -0500 From: Mark Johnston To: Mark Millard Cc: freebsd-current , dev-commits-src-main@freebsd.org Subject: Re: git: 4a864f624a70 - main - vm_pageout: Print a more accurate message to the console before an OOM kill Message-ID: References: <1EF55D96-F7E3-4AA6-A331-782362A70878.ref@yahoo.com> <1EF55D96-F7E3-4AA6-A331-782362A70878@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EF55D96-F7E3-4AA6-A331-782362A70878@yahoo.com> X-Rspamd-Queue-Id: 4JbjRz4f05z3npK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Jan 14, 2022 at 09:38:56PM -0800, Mark Millard wrote: > Thanks. This will allow me to remove part of my personal additions > in this area --and my having to explain the misnomer when trying > to help someone analyze why they end up with OOM activity so they > can figure out what to do about it. > > There seem to be two separate sources of VM_OOM_SWAPZ. Showing > my personal additions for them (just making them explicit in the > sequence of messages generated): > > diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c > index 01cf9233329f..280621ca51be 100644 > --- a/sys/vm/swap_pager.c > +++ b/sys/vm/swap_pager.c > @@ -2091,6 +2091,7 @@ swp_pager_meta_build(vm_object_t object, vm_pindex_t pindex, daddr_t swapblk) > 0, 1)) > printf("swap blk zone exhausted, " > "increase kern.maxswzone\n"); > + printf("swp_pager_meta_build: swap blk uma zone exhausted\n"); > vm_pageout_oom(VM_OOM_SWAPZ); > pause("swzonxb", 10); > } else > @@ -2121,6 +2122,7 @@ swp_pager_meta_build(vm_object_t object, vm_pindex_t pindex, daddr_t swapblk) > 0, 1)) > printf("swap pctrie zone exhausted, " > "increase kern.maxswzone\n"); > + printf("swp_pager_meta_build: swap pctrie uma zone exhausted\n"); > vm_pageout_oom(VM_OOM_SWAPZ); > pause("swzonxp", 10); > } else > > Care to comment on the distinctions and why there are two > contexts classified as "out of swap space"? Would either > one show the swap space as (nearly?) all used in, say, top? > Or might one of them still end up looking like a misnomer > from just a top (or whatever) display? Hmm, those cases should likely be changed from "out of swap space" to "failed to allocate swap metadata" or something like that. Running out of swap space is not itself a reason to trigger an OOM kill; if the page daemon can continue to reclaim clean pages while swap is full, then it'll do so without killing anything. If the swap devices are full and the only way to reclaim memory is by laundering dirty pages, then "failed to reclaim memory" is the message you'd likely see after this commit. The two cases which call vm_pageout_oom(VM_OOM_SWAPSZ) arise when the swap pager fails to allocate structures used to map physical pages to their location on a swap device. swap_pager_swap_init() pre-allocates these structures during boot, and the size of the reserves is based on the amount of physical memory. In particular, each VM object maintains a trie of "swap blocks", each of which maps a run of SWAP_META_PAGES pages contiguous within an object to individual blocks on a swap device. One zone provides internal nodes for the trie, while the other provides these swap blocks. Assuming perfect efficiency, the reserves provide enough memory to allow all of physical memory to be swapped out, I believe. In practice there can be external fragmentation of the page index space which leads to less than perfect utilization of these metadata structures, in which case it's possible to exhaust the reserves. This seems to be a fairly rare scenario though. From nobody Sat Jan 15 20:27:47 2022 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 A50AE195409B for ; Sat, 15 Jan 2022 20:28:00 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JbqVS2Vsdz3Gl0 for ; Sat, 15 Jan 2022 20:28:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642278473; bh=umaCkl+5ZFZ7k+ZFxQULnwV0LT5cso5hqhMBLPRAikc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Gr8rfOakzwA+f9bIZSeVkXiav3NRxSVLw6hlz68iOvQJRn5HZ07jIGFOkrWxMTb9ZKZS9KepfYDIiRdZ3o8crxpvjUor9QgobM1RCq6OlPLVMH73e8SGG7f6NN2u+bKd6m3vgutxonutVMHptnkG8bdtuStJpsC69coUL4FucYY4B8Kcvb2ru6mZtKDa2TCzW3gKoqEL68ForNlI2d3MFdtaM/YQn8r/GBnkwZgGMLvcBuCgTdJWESj1/BaVyUEY70XnqQYtB8Y5yCWzdLeITvFo8YJbQF8PHNR+Agvt9u31drFPxMWbUH9wBYmy3v4GgQr07ske/s4qCQZRXvbxrA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642278473; bh=2+0DF/3UhWH/+CRWCrIioCivRP29udTcIp6lPta6stF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UiQDPGvdndc4yNHwth+XjgOyJZA3Sdn8JlgQntoNMzpck2J/XWgocuTC+buDoh4CHtvl+g3SgO/GVbaNRz/6wn5hJJqYTLS3omNnBFYGs/jQ/A/Qa142+1yHR7kitth+kfezl986TqjRmRhjUd1u3e5hXPqszl+dsl4ffZ60iefjIftEcSFnjBKd1E/IxZffL8Ub0i5JYl/yoDK2Pq6fhY4E2KIhOGcVq1IoGetKLz2JGir6H1Hk+W6q3HsdzaCXnYLlvcrrU+ScoeVYJJ7YHdYNO65Iljfg0+XkoAmKnv3gVhlVshR61E7WDiYeqo+e5ubCY0xMthySpHWWy2njXw== X-YMail-OSG: uhCKjcUVM1mcjLrz2rBSyBNXqNZObehRcxHDKqujNveG0ZtlHxjEufvEXdMpMLi QxSOYGxeSCKy5nU9cQNkJ267Uwl8SUnHMgiH1eLpP2ssGDIfFMxOa2jG32okxeROUpzPj1nlsgix vKMGDzOOIDOzQqhdj61ZIdcatJo_G75Y8cPGJnmwwrDTu1aTiA1amOBN3RWJWthcIRL7vGy_rwQi KSZVsvMEm.UldWMGSeKdZf2hxmJJYBTJJwZX7DM.qF95J7d3NNJFaS5p.zPPqci6wmkZ9r58EJIo MIqS_dLvLeYrtREDgnN_NrazAXc18yqrguenhSpPYDVwKI23PqaRrmWO6DrcLYYienVxWgjBpr.i lIbsdvt.1ORirtNcAEiuNzfj.fHxDumiOEomIqKBSB3vTXfSfG5Bk5ALP.SsLX12CKTG0EU0hbgu nDGJRYbrzQG7SOdNkR5IXlDsO45wqXqGW8WfWzBIe7UBT9D_0ZXk4dBUBNaVfRNy.sdMn_ezd_RU GbZUtn2s2i07Uv1BGbgKFSbPScyQb0QZ0HQV2AknGcoM3ZLEB69VYoAsWkTBPqdHLSjRWi1h3hbQ K50CZ182e39jBqvuCNfQG8Pl795ueGPyAET4up_TW71Zi7nUlCtB9eSM6UVWgjsYJP7tp8wmLxWY BahwmuwYsJVhqbaEbAe3G467BfTl1RsCFqiqYjdmVsjXMfOgqq0S8DAGNxTT6MCjuDzdTPxXh8NQ 96toL6_BLBIK2gkoqmz1apDlVdxgbGZB89BkUI5wjFvSVLMT2sv8tHG1.h0dZhGpvrfHT9Rbvs4L 3fhtEOSyDFjguZlymPhQRVyq.FWE2SE3KbU.lkoXKMszDvILWErkhDWHlZjc4WwBM7GbaKXAUVQB Fw2uUfvsw6x1K.SgoAhLXJ4HisGcQ0JdcRDpf02DMxoP7hyBwXs_pH4HhiLWFpqSkXYH03gKUkzk sYRVRnTTWGMg4a0fw4aTBnG9.KfcyH57PRM18lzGIYwsTHTqF8zh7zFRvXpogBpDrmGJDXvBAbF0 0Nx.QnhH70iKeYhFcAbX6g9CtS4SSHoFaZ7SLfs71.PjWEQ0bfLFm9Q9DwYuD73i2bMnXc9Ky95E iFcnHuVwCG7p9DmXDwzLnBW9EzEqDTbX0iqxE0I5pUf6hUfBpfmEEynrAp59xylZffW_QKR8hdGD BYwyhWGPKSmLr5_seP5gRFz.BJNuMiXcyRuaJMXiPoNUpgE7ApsROZzXCEW3SU14yA1ryTsSWIr8 r_A3ypuQdWtf4TZ5frRbXMwo.yGWeXN6g.aVrVzayz1I4tJCCfQuwM0ecNR1r4tRMBoNn2cw5OWA NhCBag6MFM7nxE7eCTrQfxUlIGHlX4ausLQjUoJtZW1tM18whloFupPOF5YZfbswEz2COSGlH3v5 W_MQRgLJm_NEe32sMGJKoCuEhKhR64lzUEfQoLM23B5tykaMR16JzfuSfUMJFpBzdhg5VGaj5wKp xNDFbr_rvxyu6bXu1yN1XTWThj1rfPdOcHlKz5zos67y0cRZwcVn2AnKAIXCU3m3niMqhAvgswZG vg4dSlO6vT56bU7EIMvBfmgt6w68KFGoSbC8iOv47azPIPLe33aklw_yhSTyvhix8WsrzMaFzNhV RcNiw9q225ve1DMvo3J9h28XrRvo3due05zHskQHIth1fWbiUQ5drFtLQwohfoGzmpwi56H5YYqW 9uHopFznz_Vb2zSJY5iKSqhGoR2.F2N05DxYPoQnL.tcwkHwV4PIaOJehe6oo3yU0vpH.hk3_BRY sFnPYspSlkxst_a34qAzlA45J0y95PXhLSnZu8r7ENWjMCabDnTUfcy573f2vysOPo0f1FIaoJxt TuxwVMS1cD3cydSMaWWpQOQ9.xj0THKTh9iVyEueQppnqs4PdsPvEtzYTuZXEji3JS8mZA2U.Exu 1DYaHVzPiQoN9_CK5uzjchDxwBU2rwjoMJsViE.6hxkBaqt07hF_YgJ63nqgkOYkf1IWWXSm1918 98iDaeHHzYcSeQcmCqHRAex2P_Htp8y1p.gRwkza9Ru.M3Ox50DMQmCKhj9VL.Xdl3hHij4ySUBJ GDYuQLJoRl8WwIh2SyaoDsm5fdaSqTmfbMtihBTXkAPJsB3MgfqP5y3yg_myLJp4_07CJLfE.PXo JzRx38yQvTk9BpBqVa0f8ypOCL1GYPMXP9LsOjzFFqh8QI4nfrCKfzP4Sx_38G.jIYWiyvV6mewi NxNKVAEQAxULhUyqccCpFCk2b12W7_C2I077VbA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Jan 2022 20:27:53 +0000 Received: by kubenode536.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cdb6161b041431185fd21d6d405d5f92; Sat, 15 Jan 2022 20:27:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 4a864f624a70 - main - vm_pageout: Print a more accurate message to the console before an OOM kill From: Mark Millard In-Reply-To: Date: Sat, 15 Jan 2022 12:27:47 -0800 Cc: freebsd-current , dev-commits-src-main@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5171EBFB-EB6B-49F9-AC7B-D3867D40CFA6@yahoo.com> References: <1EF55D96-F7E3-4AA6-A331-782362A70878.ref@yahoo.com> <1EF55D96-F7E3-4AA6-A331-782362A70878@yahoo.com> To: Mark Johnston X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JbqVS2Vsdz3Gl0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-15, at 07:55, Mark Johnston wrote: > On Fri, Jan 14, 2022 at 09:38:56PM -0800, Mark Millard wrote: >> Thanks. This will allow me to remove part of my personal additions >> in this area --and my having to explain the misnomer when trying >> to help someone analyze why they end up with OOM activity so they >> can figure out what to do about it. >>=20 >> There seem to be two separate sources of VM_OOM_SWAPZ. Showing >> my personal additions for them (just making them explicit in the >> sequence of messages generated): >>=20 >> diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c >> index 01cf9233329f..280621ca51be 100644 >> --- a/sys/vm/swap_pager.c >> +++ b/sys/vm/swap_pager.c >> @@ -2091,6 +2091,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) >> 0, 1)) >> printf("swap blk zone = exhausted, " >> "increase = kern.maxswzone\n"); >> + printf("swp_pager_meta_build: swap = blk uma zone exhausted\n"); >> vm_pageout_oom(VM_OOM_SWAPZ); >> pause("swzonxb", 10); >> } else >> @@ -2121,6 +2122,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) >> 0, 1)) >> printf("swap pctrie zone = exhausted, " >> "increase = kern.maxswzone\n"); >> + printf("swp_pager_meta_build: swap = pctrie uma zone exhausted\n"); >> vm_pageout_oom(VM_OOM_SWAPZ); >> pause("swzonxp", 10); >> } else >>=20 >> Care to comment on the distinctions and why there are two >> contexts classified as "out of swap space"? Would either >> one show the swap space as (nearly?) all used in, say, top? >> Or might one of them still end up looking like a misnomer >> from just a top (or whatever) display? >=20 > Hmm, those cases should likely be changed from "out of swap space" to > "failed to allocate swap metadata" or something like that. Based on your description (later below), I agree. > Running out > of swap space is not itself a reason to trigger an OOM kill; if the = page > daemon can continue to reclaim clean pages while swap is full, then > it'll do so without killing anything. If the swap devices are full = and > the only way to reclaim memory is by laundering dirty pages, then > "failed to reclaim memory" is the message you'd likely see after this > commit. >=20 > The two cases which call vm_pageout_oom(VM_OOM_SWAPSZ) arise when the > swap pager fails to allocate structures used to map physical pages to > their location on a swap device. swap_pager_swap_init() pre-allocates > these structures during boot, and the size of the reserves is based on > the amount of physical memory. In particular, each VM object = maintains > a trie of "swap blocks", each of which maps a run of SWAP_META_PAGES > pages contiguous within an object to individual blocks on a swap = device. > One zone provides internal nodes for the trie, while the other = provides > these swap blocks. Assuming perfect efficiency, the reserves provide > enough memory to allow all of physical memory to be swapped out, I > believe. The swap space can be bigger than the RAM space and something approaching more like RAM+SWAP "memory space" can be in use overall. The system complains of mistuning when (approximately) the ratio of SWAPSPACE to RAMSIZE gets too large. Relative to the mistuning notices, as I remember, armv7 (so: 32-bit), for example, has a noticably smaller multiplier of the RAM size for how big a SWAP can be compared to, say, arm64/aarch64 (so: 64-bit). But, using aarch64 as an example, the complaints start at somewhat under 4*RAMSIZE, where the as-if-no-page-index-space-fragmentation figure would be somewhat under 8*RAMSIZE. (8*RAMSIZE matches some documentation but that documentation is appearently incorrect for the likes of armv7.) In other words, I think the wording above is misstated in its detail but fairly accurate wording is probably a much more complicated thing to provide and read. > In practice there can be external fragmentation of the page > index space which leads to less than perfect utilization of these > metadata structures, in which case it's possible to exhaust the > reserves. This seems to be a fairly rare scenario though. Side note on an example context that is possibly related to the "fairly rare scenario": At least one person has had the system consistently hang up for a build activity when avoiding the configuration generating the swap mistuning messages that I reference above. This was when a monitoring top did not show swap as nearly fully used --but definitely in significant use. But all they had to do to avoid the hangup was have an even larger swap space (so the mistuning message ended up being generated). As I remember, the used swap space did not get to the original swap space size in the monitoring via top. May be the fragmentation of the swap space itself contributes so the bigger swap space was easier to handle? (I've no actual clue.) Anyway, it was not a result I had expected. I still avoid causing the swap space mistuning notice by keeping my swap spaces somewhat under the sizes where the messages are generated. (While fairly rare, I sometimes do experiments where such a RAM+SWAP total size is important.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jan 15 23:25:45 2022 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 47908195EC56 for ; Sat, 15 Jan 2022 23:25:59 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JbvRp0Z0yz3h0F for ; Sat, 15 Jan 2022 23:25:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642289149; bh=6GjEcx4peSYXxhtDeDKaAM/YBQL2b85G6mUDmlfzGzE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=oDU1D5Pl2goXFxGRJxXo/elXSiFY+bdRJRxUjQAKIl1WPh5GXOMqAdQn/ph+cYIIWVshZPRKIh3E/JUeA/37VuXvAb3jxELupNds1WhP7hvTNrXJvIxgsoo0Va2BWRZLEMo4pcl79ysgf4bhz0w+0eKVO4ld83nRbT8SvP2RqxJYKwvmH6KKt8pqatZc1/gMcW3wr5AohUKhQTpQmTeLh01qKGLiEfBM24c9pkYZvxYcV6RpeGm3RAdEcOvIgRZTY4TNByVTp6gqIyaLA6ie24qpfZYb5fSRu9NahVXW3wLmG/axhTcB7beuJsaD95rrKJyqKaEqFsXKPxNjUv2O+Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642289149; bh=DeN4umjdMgtKbdHLPn7LbgymKH9sukvq1Oxu8zS0Nx+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ZlouJLmFzMvvMi9xSK7sbsS30KfmbiqbnqwjQKFXyJfxvHSbkE33c+Z2dxEpZcgPm54nKQ5sv4NB0cPLpVtjVRFSNYuPzw00KH+MrHch6DLLev98i8Yy7SAUAqdH9sHKBOTjj2mZH2XaxJentZGxJNLZP2SCWx5duCdOFEHO5Y9iT1aZY3bh5N5+BL5lVXATzRJ8F5beEBAmeTH21qZUd+OXymGWhOaYNk8GAEKLKsYw9FRbBgckhncz4bdIh47LhGdMlES0yDTyYLMNdMCswseShptGI3Cna/s/a0B90dibDIKfRqj5LI54SRv6LAIOn2lhwrlyyB8cj/MZfvI/zw== X-YMail-OSG: .tr48E0VM1mw62EF1R3QUI0pdELnrMzkT8II.LO1znVTDOOKHGjsYoJ5JM_YOUD 0ZXb7NKC0x.s7NupLuuZjtX454JzAON.EcCmhI3jE50hrLU8jzZobD9mSNABxKwYYgatq8BIaAHr wzyHh4D3Lm2Tpq6SuWRvPJgC99aaDBMYlIWjVEh_ErcLy24mReh_E1mbVD8kxGXr8Ob7c8IazrTs LsL4iJYxWGkC8JSQQhtr6t04d0HkcSG2fhAz4h6MO4GxTUQDim2yf5LOJqX9.vMer3Na15B1L1G6 ADbtJ8Ckf3hv6hgsYbteeLkV1ExFnIPOKkrkaXItNvum5IT4wIkLxHwIrjkWXxNJuPM0eVh8sDXT dIciQTRG6Zloke1KTaJx8Ra2vwOUsGIAPuSrBT98MjGptYe.JIQuqtPUcMQZb8VyZFWPVzKIFqiz B0aqwaajhjI_2bQaglBS_lVdBpl3LbMAqQaJldT2S6j3d6iYAdfzR0BvY3kR.9W7C_THVmnEIRYb H8w5qF9dntyn8tAx2qLin8rQSSwK68iaEADNM.n.4n42a.q.KTdenp9yWEQf1EbzjkymR7cCAz7E T4QA3OSde_ATV0rU3cD9yEFS3O0BvOxZ4ai0U2AUy5mYHTv8oGo1Axkpp3tDpBbNNSRGChJwPAgz EWVf1K5ekdT0bvXIo57pmRvHm0GHg6hFYl8lLoTUyPQCtErHUplv0MjTlATs6pCtSpck9fBITE1r LwmJR8ialQPv2XJSVsWZm7qWXjJ5_McPAcpOK.PSAYN4OjquDPpUQdQ0.zbpf2ur.H1xwVXO6qdC gQ.jNzbFplKZF4J1BiHGa8BvxdXAPDshLxwovF6e6j2GiQdYnUhSvOSJb_4wOHUHaybnSbTrMgLc udtL6i6KIlNkdXniIuZzGRgJCFEgrgMNzkG8ZJoOP5VeJmdo7binGQuuLHvAloMgJuyzgXrN96m_ o8sXnLwAj2CTXWL8au3sN4S769zKmLT8ItzEDyW2fdT_I2sNG6Ln0ATZPLMbCcuR.91KVUgsbnHM d0lig7ZaHqsvuqCG3FJkoYKieO39mFtxeuNiblHjpqHFFBuHubazmucymfVWBdHxTGx5FQwXYVdp a_vGrILJuwrArGArPU4yi6wP2eAIKR.Faj6cwNF.f5jPbsbeE.vdwdNB4pg4UlMpZyxgLR7hj3Sp CVlqavP2.14PSes9h6P7dqoLgTq5hSNMDISy6VnGkLoJDzEKN8jwH6eezeuR6rU7Tzu2zzM75dXO PwgUbdzzOVRfr0rGT6EyRD1OSGmagGinoyu75bSO1EXqamybqqK.iX.EwIiEthWjihN5z4Wszi6n O3OjYeVREXiQsSxCgZR37Vh.9Dfud8gsG5.uYtN5zpInT4hNwOtExOQXDdZWiy0T0lxA_3q5laso wBbCPvPpUuRw5OricCI6.1Z_sfZ1lMwMza5eonbL5ofySiPEdPh3Bh1z_M9tKbkb3DjoSi.QtRVm NXXlHtGwy51rJJlFvo8ZoLH28lPkMEplLVIjlFA4Nyn9psVcHy4z.Ud.txled1UosnhmUAJENAFS Mz41MSHXU6Ymx0vUFIzEZ5DPclO8WrwxCKdxCyGD7BjuFIyufkg_RMqOxkkis8xh7S4LJvTZy6al tbkzl8mudg89.aAIHQRHFrSqtWS.z_2QDVuuX5f.VEla2iziO7GDdXY6NZM84fZ9iTYANEYJzz6Z t.3XV99IX.jN.BlfNshH60shrteRFexHyCfJ5YK2gUEvfyya4_ufma_FXyjbrlinhcegG8s_B_Uf pSrkw3j9sGiCx.dgPSPlHDjEIdhW7rE4avjWUZOUhb8RV_ZH8VU_QzOYjtoCOjGdpzEHagGWGvmM a3jBDqMU.uaQsIpaHzMORJGUEj_EexBslVR5unCsvlF04G33U9eTh2xASNmTJaz3oju9C97qxVKg JzRSOYzSUZEaq2haTZGs6ZWyFk5BGEslyGRoIunH6mzO8zqhPgRqgOOj3RIjwNfzYsor9WqOgdz2 OH3.2d_Ao_WNo3u9.nl6ZEDoDjIOQ1_BhIiwB4QpAWji0oqzpzbFQ.FKadHcUjqD0cZQ2JWEzvvY pdAxrvKwiVyjyjXy2duqirTUQ1BqDXf0gY.Kx2l6E4fuZ.bUVVCwUepSN9qoE8xLvuY3fbKMkE9t oPFgyyDjPpJ2pR.GaXCPle86zG2ksX9mknGsxtmVWajLYdfLeHeCFBBHnEdnbKU8a4FFRt_EvKNX GRn5O4QvHFP6la6qDVBu9MnxGGxygHbHCTCmu3.XkKu.j2UAnQ_z6h5eHh7CFOHkeIRwDIWDyCd8 J3Dw- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Jan 2022 23:25:49 +0000 Received: by kubenode522.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c33e7568a87eb9e85c832828c25fea4d; Sat, 15 Jan 2022 23:25:48 +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 14.0 \(3654.120.0.1.13\)) Subject: WITH_ASAN= vs. vfork: ASAN can not deal with vfork in a reliable manor, so what to do to avoid vfork fairly generally, including for kyua? Message-Id: Date: Sat, 15 Jan 2022 15:25:45 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4JbvRp0Z0yz3h0F X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=oDU1D5Pl; 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 X-Spamd-Result: default: False [-0.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N ASAN is documented to not be able to deal reliably with vfork use (inaccurate results, result mixing interpretations of the old and new contexts, and so on). [There may be other routines sufficiently analogous to vfork to have the same sorts of issues. I'll write only of vfork explicitly.] It turns out that using SH_DISABLE_VFORK=3D with kyua runs helps avoid a bunch of junk failure ASAN reports that involve /bin/sh using vfork. So I've been recently using the likes of: env SH_DISABLE_VFORK=3D ASAN_OPTIONS=3Ddetect_container_overflow=3D0 \ kyua test -k /usr/tests/Kyuafile in my kyua runs. But that need not cover all the vfork use in the kyua runs --or in general system operation. There is more that could be done. For example . . . contrib/llvm-project/compiler-rt/lib/asan/asan_interceptors.h currently has: #if SANITIZER_LINUX && \ (defined(__arm__) || defined(__aarch64__) || defined(__i386__) || \ defined(__x86_64__) || SANITIZER_RISCV64) # define ASAN_INTERCEPT_VFORK 1 #else # define ASAN_INTERCEPT_VFORK 0 #endif The "# define ASAN_INTERCEPT_VFORK 1" causes interception to use fork for the vfork implementation, instead of an actual vfork. It looks to me like asan_interceptors.h for FreeBSD should also be using: # define ASAN_INTERCEPT_VFORK 1 but it currently is not. There is even the possibility that a WITH_ASAN=3D buildworld could build a world that uses fork behavior for vfork and never does an actual vfork (by behavior). Basically restricting itself to things that fit with ASAN use. I tracked this issue down via a report in a kyua run that referenced: QUOTE ERROR: AddressSanitizer: stack-buffer-underflow on address = 0x7fffffffa580 at pc 0x000801e0f8ed bp 0x7fffffff9bf0 sp 0x7fffffff9be8 WRITE of size 8 at 0x7fffffffa580 thread T0 . . . Address 0x7fffffffa580 is located in stack of thread T0 at offset 0 in = frame #0 0x7fffffffa5ef () This frame has 1 object(s): [32, 288) 'buf' (line 180) HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) END QUOTE The "'buf' (line 180)" turned out to be from the declaration in bin/sh/exec.c 's tryexec : static void tryexec(char *cmd, char **argv, char **envp) { int e, in; ssize_t n; char buf[256]; execve(cmd, argv, envp); e =3D errno; if (e =3D=3D ENOEXEC) { INTOFF; in =3D open(cmd, O_RDONLY | O_NONBLOCK); if (in !=3D -1) { n =3D pread(in, buf, sizeof buf, 0); close(in); if (n > 0 && isbinary(buf, n)) { errno =3D ENOEXEC; return; } } *argv =3D cmd; *--argv =3D __DECONST(char *, _PATH_BSHELL); execve(_PATH_BSHELL, argv, envp); } errno =3D e; } So I could finally see/validate that an example stack-buffer-* report was tied to vfork handling (analyzing other code related to the tryexec use). The report happens well after tryexec did its execve. The information about buf is just old, no longer accurate information, leading to a false report: =3D=3D87961=3D=3DERROR: AddressSanitizer: stack-buffer-underflow on = address 0x7fffffffa580 at pc 0x000801e0f8ed bp 0x7fffffff9bf0 sp = 0x7fffffff9be8 WRITE of size 8 at 0x7fffffffa580 thread T0 #0 0x801e0f8ec in bintime2timespec = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/us= r/include/sys/time.h:285:14 #1 0x801e0f8ec in __vdso_clock_gettime = /usr/main-src/lib/libc/sys/__vdso_gettimeofday.c:195:2 #2 0x801e0e1a0 in clock_gettime = /usr/main-src/lib/libc/sys/clock_gettime.c:48:11 #3 0x10d54da in clock_gettime = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:2189:13 #4 0x11234f5 in __sanitizer::MonotonicNanoTime() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_linux_libcdep.cpp:860:3 #5 0x10ba02c in = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::PopulateFreeArray(__sanitizer::AllocatorStats*, unsigned = long, __sanitizer::SizeClassAllocator 64<__asan::AP64<__sanitizer::LocalAddressSpaceView> >::RegionInfo*, = unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_primary64.h:790:45 #6 0x10b9c4b in = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::GetFromAllocator(__sanitizer::AllocatorStats*, unsigned = long, unsigned int*, unsigned long) /u = sr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitize= r_allocator_primary64.h:220:11 #7 0x10b9955 in = __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocato= r64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::Refill(__sanitizer::SizeClassAllocator64LocalCac = he<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddres= sSpaceView> > >::PerClass*, = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >*, unsigned lo ng) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_local_cache.h:103:9 #8 0x10b9615 in = __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocato= r64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::Allocate(__sanitizer::SizeClassAllocator64<__asa n::AP64<__sanitizer::LocalAddressSpaceView> >*, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_local_cache.h:39:11 #9 0x10b9511 in = __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::A= P64<__sanitizer::LocalAddressSpaceView> >, = __sanitizer::LargeMmapAllocatorPtrArrayDynamic>::Allocate(__san = itizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<_= _asan::AP64<__sanitizer::LocalAddressSpaceView> > >*, unsigned long, = unsigned long) /usr/main-src/contrib/llvm-project/compile r-rt/lib/sanitizer_common/sanitizer_allocator_combined.h:69:20 #10 0x10b6086 in __asan::Allocator::Allocate(unsigned long, unsigned = long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_a llocator.cpp:537:29 #11 0x10b4818 in __asan::asan_malloc(unsigned long, = __sanitizer::BufferedStackTrace*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp= :980:34 #12 0x110be9b in malloc = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:130:10 #13 0x117aca3 in ckmalloc /usr/main-src/bin/sh/memalloc.c:71:6 #14 0x115b1b1 in reprocess /usr/main-src/bin/sh/expand.c:912:9 #15 0x1155163 in evalvar /usr/main-src/bin/sh/expand.c:784:3 #16 0x1155163 in argstr /usr/main-src/bin/sh/expand.c:319:8 #17 0x1151178 in expandarg /usr/main-src/bin/sh/expand.c:241:2 #18 0x11427c8 in evalcommand /usr/main-src/bin/sh/eval.c:857:4 #19 0x114705b in evalbackcmd /usr/main-src/bin/sh/eval.c:681:4 #20 0x1151bfc in expbackq /usr/main-src/bin/sh/expand.c:476:2 #21 0x1151bfc in argstr /usr/main-src/bin/sh/expand.c:323:4 #22 0x1151178 in expandarg /usr/main-src/bin/sh/expand.c:241:2 #23 0x11427c8 in evalcommand /usr/main-src/bin/sh/eval.c:857:4 #24 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #25 0x113eb88 in evalstring /usr/main-src/bin/sh/eval.c #26 0x113e9f9 in evalcmd /usr/main-src/bin/sh/eval.c:139:17 #27 0x1145289 in evalcommand /usr/main-src/bin/sh/eval.c:1107:16 #28 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #29 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 #30 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #31 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #32 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 #33 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 Address 0x7fffffffa580 is located in stack of thread T0 at offset 0 in = frame #0 0x7fffffffa5ef () This frame has 1 object(s): [32, 288) 'buf' (line 180) HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-underflow = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/us= r/include/sys/time.h:285:14 in bintime2timespec Shadow bytes around the buggy address: 0x4ffffffff460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =3D>0x4ffffffff4b0:[f1]f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4d0: 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 0x4ffffffff4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4f0: f1 f1 f1 f1 00 f2 f2 f2 00 f3 f3 f3 00 00 00 00 0x4ffffffff500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D87961=3D=3DABORTING =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 16 08:19:53 2022 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 10075196AD36 for ; Sun, 16 Jan 2022 08:20:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jc7J30FZnz3t5M for ; Sun, 16 Jan 2022 08:20:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642321195; bh=Ell9GTCSgE+1kEo+4BnVbCk7wVrPJaC47alPs5rdOFs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=gqpPuGkuB/84o+R43aj1AyaMhfWWyNMmaqUyNelI6zsLn1Z5AjBmL1e7FLBvsSJYHMKwVx1oC9XaE+abj1gH4vPZN7ASca5i93cjF474t5U63W/mUFa6G8IPhuZya3+V97rMrWYIHH7N3gl8+AhQ99Z0xqoqnMMkndPRe1yrqQ5GaQ33K3qLjMg/5NfkyVubQNdCcLK49ZkMJCUXnuZziPQ9OzSW2PGvkaUYmVnhpYAOlimol/dEWDR3SSBK/41QZ83v8W5lNtURPxdwfItTbgBuQMcESbbDbEVT3DEE1QMKQrbysF6/gBs3xNV4k2eaXCrzKnvPMRSytPmT+JRbtA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642321195; bh=xfbyg4IxRifEBdNufQlHXBWcZZsZ6JRU46xwsP/aWGN=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=FGj1UuQA86a4U2dwq2BmYZQoafnRFgkYvCMKekYv2yVwIJsoM+dlSuDnNOTuQCsH9pWcsz3B4jkjtVnTsQ5E2yvevzHZ++1WrcNBx+tNnZ7jf0FmunNIHXFL6WuFAZUI/v0qJmeiAR8tEmf7x15X4E9WXFgHp267SsF2TW+ODqeMrwmypL0j/hwE/flxgIpUv9dY05lxWOfNWLerFg4Rncm0yr4aA4WqKQgWudlxYyAaSmJ1Y0t03n5OwMyEv5H63rbOax5A9PTRfJY8CpirqVUZbn0AGKN9ZJJsqD5Q6Qd/KLTZ0KvylWildGhjtwvE4eAlD8Qb9FyG+oCMDrRtvg== X-YMail-OSG: KKaquK8VM1mfvT5bLz4YEu176URJvCzuS2DhFC1Set_EfkM1NHEhU4MavtwAKl7 FInS_ZU5czdx5ZSU7GlR4eA7lMyiGs43VRSVHS8xlzG.xc2n1bCDAmyXHu3wwvAvo224vVjNTyIj fb0YWV0lvs.gftFoiPLvPrHIZzk5aJHnYnJqgj_vqjb9oZCe7v3ZueZEwx154SISIrOGsl2TUYoG KkqebHldlxQHyyqmw8jZkKC7jhV9xU2zjz07S4SN6npQQLFM6o6uBufKDQ4pWEXOz1AosD7nbye. R_FUgwShnwR1.5lsmBemaJhRO2tPlNYSsFBtDamHFdILzsXhMEIFZ0ykOJUeTGizl36yVxmNUiZL LR7WKt3oGfZurjh3ZMjnYMhGL5b.LM7DPnrLzxqQipS1YTRgb6SLtZIR0Wmamc626fu7Gpqa0i6z rKUgH51ntXqqVmffas.Nt3mN.R5FOPCbcH6AEh5l6olHNlRiAqXhEn3T881IBUjGdU1YQoNl1i5v ySqwmzvh_8SXwh4iOdpU8mKt2X6thEkKRh7Igj1..2JtpCzg6Gat.4S.MS03YUrSTRJz89SuIX.A 6T.1IHC1swKGnuIK83w4ucuymiqPGOpm5IXWNRBpT3ALDOQcKum7ZpFR2oAg3hktKH9j7Rb_hP9o .aOd8WG1GERaKbBhpFjEFfv1DUIx.bAQvV5E_FPiOyw0CmqUhLNZBUcuZQ9s1TnKTDV_Zw4BPzYG gU7H8tQcW4hEHpABi_Oec4mKSsJ9TaCvRNhEPgsv_atX0HIisiyOIdmG63sakUvD6S5fm4BBtKvh vpNgdZH14Etd2tMnN_buAZtqHpL79fLabEBsIYqZIEvKUN_nBLAUGeyHT8xFoqhcbqrFiT8787Fo MwCf.9r0_x_VDhpHRObeGJV2X4sreLgRhWYW93iIfr21vyp5usnY._iPvCMD5coLNgMDjqVOwfvA _k1e4Lsap6kKXjQTIROyPXW2r6mFIORnaFBhHCQnGKiDebHdvuedTwLFD9kgUB6o2WRxboKXHWVY 6TC19u7w02EPckMyhjD3CAbJuok4sLbSdLXdMvu.yT4k5m.7SmCRqPruaICQLkirNN.WkEkNfGEp rKdCS3pbR9zbsE1gC289H3yVK2BYXt9bv9crszazDNn0sT9zz4ELZOgl0HABxTRneBc7sXdjvpDI XiuO1ui.OnDS_OREgWgeCvoXQQ0AS2yIKDOtQXpaZQCNd24ljEnigKHBE392eaAQHR7Lu8tDfZob wkmbxvR.oKGAujlpoY0jB_zqdfaXmOkl2CKvW9aI9xmnZcf6pD_2Vi3ATYtPb.Gpaf3lvc339_zh maYujCTQIPiZyg_sSek0mja_4damOZKHLFYUqg59iOqnEeWio30wXa16SjrXYUc2rk6UfixyAA36 .HClxWmn94upKLAZDJsvaCmleYsx1xfqJFcpjI5M.sM5diMcoZ5YFJYoJpq9XM.IG.ZHp9uiLBzq WLYMTHbbVpNuzobzEmkE0OfIDfjHYjiiaBMeC8G5ignU8ltguSD0tKYYzpfCWUxW5IL3NLuorppa lylFwGV8a0lvhAz.JIDG7dc5_m1VfLjY8D6R69VG6592Q1X3g2Et4rRnzXsJCr2JqZV6QTi5ZV3T 1cabFTZtrkoX7D6nlTAgQx4G14iQWAKrWGzfduSN5cyF5DAfMtE7gSxHMWS4yGoS4oWJpkgQDN0g f2olikjqJQrFVw9t1W9NjXtFL3Sr2F1mPNqKAhygN_afdv5KERwHEiyWFg8zteneyfh_RYk4QLBU HrevLQooLYKPTPDjCeZyk4EgfcLVYUJCgtiZ_CGlL3_F4tieDQC2Zpm4dMehQynhLzuKxS4Q5Pfk XIKDUFTf2M6z5tfZMRjhIYyzEgsNFqVA_YwfeXtWK6qKr2YcFR_r3Y4LsLDHwC1fKM3qVQV4womr 2hkf2dQdODutRJB.9Wv30N2HN4JdisRr2_OTXwAmLtlhLlDSpTRek4KxvShy6lyzBMuocyvqOlKO 369TWpijdcKWtOJodZUsiDQfE9UDLHLcfRUNzTbyG9bTAUi9ScXkPOYTF398l5QS5UCvp6wxeBQB 4ITBeweN5tAl8puHcN8j_kFKJdaoR3IRVRm7AQnC2ac0gvxdcUzr.HqIUrB1Wws61QkCT84dlac. _7__WsP567DRI_70DZy.1w3tQnX20jZJi5DqgZCJzYRZ4GlI_XzxFSfhob8DYD9RiMxZ.4NGZIfR wI2utBJtH7An0ogxbW1qSKXNdbQdZFUGtZu_ED1l4gn6C0qda7OcZwMg9dYBU1Xj546n8nWjv9A- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 16 Jan 2022 08:19:55 +0000 Received: by kubenode516.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 23f3c3217e96111754d5496053a97b25; Sun, 16 Jan 2022 08:19:54 +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 14.0 \(3654.120.0.1.13\)) Subject: UBSAN report from kyua run in WITH_UBSAN= based world (via chroot): /bin/sh 's waitcmdloop does NULL+0 undefined behavior Message-Id: <701C64F9-B51D-4DD7-BA74-5BFE580BF562@yahoo.com> Date: Sun, 16 Jan 2022 00:19:53 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <701C64F9-B51D-4DD7-BA74-5BFE580BF562.ref@yahoo.com> X-Rspamd-Queue-Id: 4Jc7J30FZnz3t5M X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gqpPuGku; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.147:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.147:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N # /bin/sh /usr/tests/bin/sh/builtins/wait6.0 /usr/main-src/bin/sh/jobs.c:590:35: runtime error: applying zero offset = to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/bin/sh/jobs.c:590:35 in=20 /usr/main-src/bin/sh/jobs.c:601:22: runtime error: applying zero offset = to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/bin/sh/jobs.c:601:22 in=20 So: # lldb /bin/sh /usr/tests/bin/sh/builtins/wait6.0 (lldb) target create "/bin/sh" Current executable set to '/bin/sh' (x86_64). (lldb) settings set -- target.run-args = "/usr/tests/bin/sh/builtins/wait6.0" (lldb) run Process 66125 launched: '/bin/sh' (x86_64) Process 66125 stopped * thread #1, name =3D 'sh', stop reason =3D Nullptr with offset frame #0: 0x0000000001135850 sh`::__ubsan_on_report() at = ubsan_monitor.cpp:39 36 } 37 =09 38 SANITIZER_WEAK_DEFAULT_IMPL -> 39 void __ubsan::__ubsan_on_report(void) {} 40 =09 41 void __ubsan::__ubsan_get_current_report_data(const char = **OutIssueKind, 42 const char = **OutMessage, (lldb) bt * thread #1, name =3D 'sh', stop reason =3D Nullptr with offset * frame #0: 0x0000000001135850 sh`::__ubsan_on_report() at = ubsan_monitor.cpp:39 frame #1: 0x0000000001130011 = sh`__ubsan::Diag::~Diag(this=3D0x00007fffffffcc60) at = ubsan_diag.cpp:354:29 frame #2: 0x0000000001134f44 = sh`handlePointerOverflowImpl(Data=3D, Base=3D, = Result=3D, Opts=3D(FromUnrecoverableHandler =3D false, pc =3D= 18263566, bp =3D 140737488343328)) at ubsan_diag.h:0:21 frame #3: 0x0000000001134a7a = sh`::__ubsan_handle_pointer_overflow(Data=3D, = Base=3D, Result=3D) at = ubsan_handlers.cpp:815:3 frame #4: 0x000000000116ae0e sh`waitcmdloop(job=3D0x0000000000000000) = at jobs.c:590:35 frame #5: 0x000000000114528a sh`evalcommand(cmd=3D, = flags=3D0, backcmd=3D0x0000000000000000) at eval.c:1107:16 frame #6: 0x000000000113eeb8 sh`evaltree(n=3D0x00006150000000d8, = flags=3D) at eval.c:289:4 frame #7: 0x000000000117a317 sh`cmdloop(top=3D) at = main.c:228:4 frame #8: 0x0000000001179789 sh`main(argc=3D2, argv=3D) = at main.c:175:3 frame #9: 0x00000000010b35dd sh`_start(ap=3D, = cleanup=3D) at crt1_c.c:73:7 (lldb) thread info -s thread #1: tid =3D 101020, 0x0000000001135850 sh`::__ubsan_on_report() = at ubsan_monitor.cpp:39, name =3D 'sh', stop reason =3D Nullptr with = offset { "col": 35, "description": "nullptr-with-offset", "filename": "/usr/main-src/bin/sh/jobs.c", "instrumentation_class": "UndefinedBehaviorSanitizer", "line": 590, "memory_address": 0, "summary": "Applying zero offset to null pointer", "tid": 101020, "trace": [] } (lldb) up 4 frame #4: 0x000000000116ae0e sh`waitcmdloop(job=3D0x0000000000000000) at = jobs.c:590:35 587 return retval; 588 } 589 } else { -> 590 for (jp =3D jobtab ; jp < jobtab + = njobs; jp++) 591 if (jp->used && jp->state =3D=3D = JOBDONE) { 592 if (! iflag || ! = jp->changed) 593 freejob(jp); (lldb) c Process 66125 resuming /usr/main-src/bin/sh/jobs.c:590:35: runtime error: applying zero offset = to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/bin/sh/jobs.c:590:35 in=20 Process 66125 stopped * thread #1, name =3D 'sh', stop reason =3D Nullptr with offset frame #0: 0x0000000001135850 sh`::__ubsan_on_report() at = ubsan_monitor.cpp:39 36 } 37 =09 38 SANITIZER_WEAK_DEFAULT_IMPL -> 39 void __ubsan::__ubsan_on_report(void) {} 40 =09 41 void __ubsan::__ubsan_get_current_report_data(const char = **OutIssueKind, 42 const char = **OutMessage, (lldb) bt * thread #1, name =3D 'sh', stop reason =3D Nullptr with offset * frame #0: 0x0000000001135850 sh`::__ubsan_on_report() at = ubsan_monitor.cpp:39 frame #1: 0x0000000001130011 = sh`__ubsan::Diag::~Diag(this=3D0x00007fffffffcc60) at = ubsan_diag.cpp:354:29 frame #2: 0x0000000001134f44 = sh`handlePointerOverflowImpl(Data=3D, Base=3D, = Result=3D, Opts=3D(FromUnrecoverableHandler =3D false, pc =3D= 18264444, bp =3D 140737488343328)) at ubsan_diag.h:0:21 frame #3: 0x0000000001134a7a = sh`::__ubsan_handle_pointer_overflow(Data=3D, = Base=3D, Result=3D) at = ubsan_handlers.cpp:815:3 frame #4: 0x000000000116b17c sh`waitcmdloop(job=3D0x0000000000000000) = at jobs.c:601:22 frame #5: 0x000000000114528a sh`evalcommand(cmd=3D, = flags=3D0, backcmd=3D0x0000000000000000) at eval.c:1107:16 frame #6: 0x000000000113eeb8 sh`evaltree(n=3D0x00006150000000d8, = flags=3D) at eval.c:289:4 frame #7: 0x000000000117a317 sh`cmdloop(top=3D) at = main.c:228:4 frame #8: 0x0000000001179789 sh`main(argc=3D2, argv=3D) = at main.c:175:3 frame #9: 0x00000000010b35dd sh`_start(ap=3D, = cleanup=3D) at crt1_c.c:73:7 (lldb) thread info -s thread #1: tid =3D 101020, 0x0000000001135850 sh`::__ubsan_on_report() = at ubsan_monitor.cpp:39, name =3D 'sh', stop reason =3D Nullptr with = offset { "col": 22, "description": "nullptr-with-offset", "filename": "/usr/main-src/bin/sh/jobs.c", "instrumentation_class": "UndefinedBehaviorSanitizer", "line": 601, "memory_address": 0, "summary": "Applying zero offset to null pointer", "tid": 101020, "trace": [] } (lldb) up 4 frame #4: 0x000000000116b17c sh`waitcmdloop(job=3D0x0000000000000000) at = jobs.c:601:22 598 } 599 } 600 for (jp =3D jobtab ; ; jp++) { -> 601 if (jp >=3D jobtab + njobs) { = /* no running procs */ 602 return 0; 603 } 604 if (jp->used && jp->state =3D=3D = 0) (lldb) c Process 66125 resuming /usr/main-src/bin/sh/jobs.c:601:22: runtime error: applying zero offset = to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior = /usr/main-src/bin/sh/jobs.c:601:22 in=20 Process 66125 exited with status =3D 0 (0x00000000)=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jan 17 01:20:27 2022 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 53A14196B5B2 for ; Mon, 17 Jan 2022 01:20:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JcYxj49nvz3Pkc for ; Mon, 17 Jan 2022 01:20:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642382434; bh=wLJmiDRFSpmupXhYK+qfk7jaFGCneD76TALnctiQo5c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JrffxhNMIbiUM3fyPzVsC20pK95f/dv4q/v5t3XL/ztWgtSxt9yHYIm6mbuzvOX5pyzQK9aSbiFOBKneg8QmG6KPSdg1ukI9B1m79nAi2In5GCOLxwqYRq8EivvisKUCzK+IR71AAGGM8TXeUr5VwDbGHiId/WSlLkXs3fW497xcpBQEjRIjKWJpfAD2S9LM27MbB7Yr1MWnlZOD0nn9kH0x/4C+7ufJ+gVxgFEB3fBXwIFhuSG067CB408LFMzBoXoDcF3PVaPMHdenzAlyas8fZaDJjTkvpoPs/vXgFCWlEGcnOVTxG63ArUkUrDDXGd5lnSSurkHrpTU++feIqw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642382434; bh=W6Qm/R1T7HuyyLGfLyx8MKyiOg56eclczNa1Io5ZXDE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ph3vfoeZWoR0PjCgrHNFGPcl/0gzsI+GgLZMtbUafd4ZPf27yrOVDiq0aXQ08YK50N7PxeLm1cIUqln7rhsxUhaU1EquztAgaCqv0MZk4LT/O6snm9MdTKfWdMWHqTyCPVA+8DZH95i2ZlFrHHe5x05OZ2URLTupQCcfpnOWA6Th4P3zDHio9JcakNiSa3TCbCmA3mC8tpsZ4St/1zkHXQruT6na0JeXF1Cf62P07eUnBbpzfDsab63Zss/je6yPXeRp2FPTJxgTJm1b9tOS6ZEr7TdFt8FBnIUjDSj4duls8vNaocKzp82CxfDmJLuom61WQP1ZujIzTwDks1OMnA== X-YMail-OSG: PNVYpE4VM1nr43AN7GFDPlu9Fh9ipOsFY4WjgNvJM_NNGsgrf1avcw2T1lMQeYA 4kI0I6Nj9R6UXeg8ibdE.DFcnMhsSxbWZitcE6LIEyP__8qB_jRNbuLEpdKgdsL_xZc3ODz7SgQE 4shIIgjPqssfapkMlUBEtrP7Dz_puKrDMKeWU4lKR4RFqL5J3Y9QS51Xm.IjmaRdH465pgn91bTq J2VwQ4E9spFghRu4ezmW1MfiKbPsXSi09bHDkAcdQuu_UUXhkq3gGdi87LAh21rIEKqSq3RUWk6C FOTk7YlwHoaTM59TCYJSMF4kRAJIiEFKTeeflFfFCZ1ujEN6IzVC7NORDgktdC4IqSAnRr5Kuw8y Wxkk1lAHy4b35zdX4ddmzy6tm3CbeQCczqXmPTLbm9Ukcvef9I5L5dcXHN38dhqLZGzPzFIHWPdX kFBSHxkulM5On5kzZdIxoiOJLIDWy8Co85FJ7WQMlZdPyOqQVTurmu3SkRP6P8DxVlCbEo8ydEbE 2JtMYcppVfMreNh7W7FwhiWdad9uLF8UjjT3SJxh_pfO6TF8d8kJlQhBihhQ3cNQ959wBiE7I44X bTq05v59NMAdlEkOI0bXFYGKewO7Jw4HshWoXbiPAnMEoTYr7NPbZEomtzD78w.sjukd4kuYeXRP WXdoWNS2gvzuEFmxaNTdau97Ljmh8jtmdqTYiGVQaLcbDL7EnMfxgSq7aMbt7zlkbbiMn0JunCKE 7g9wJ8F_0fbRinkHnolE9K5PG9N1Do0dDHkfyWhyWU6AGECHmxtSQ9MKQu_o87k_KIy0V1RtJ.XE a20gSD.H7ER05wXr4g1gmXoC7wYkLO1TNiVsHweLLDz.U0FomnBqa8W1X.bIp9U13AlC3u97mqxM UUV44e.LvxmC2pCV9GTuuGokrjG3hoICGeWIx5oMgTAI9Fc8en1.AqNYSnj2IWpFvAivEhpw4..B 1LBpl1erJ9dtEM5i_WFJQJ6swTasnaFl828t3zvnivnQ_vj.7kVuoyl26oU1Tlv6hXWLPFUYJXzI x29Af.jh7D0l0EtbT3wjbBAFetsZrc_wHfAEs5VZQUgZP2F__E0NNAFgSZ26DjlITIOghPLElaKk LHyBuG9PFZu_8T5v8flW7HBek.uwVjbDrLyVbX0k6ziNztGxIt6gMvJRK_uIscwyKGKmscAnGW2. 4cvwAIsS0HP1QIBTKyz32.7JJa0KJo9xprfsYW5ravBR_oB9J0cunoLQJWyPD36n5W73fXwMEUMk WT.7QLqL061wXAemOwoFNKB8Xn0Wt9MVkLygFUhQrXpL4z8R_GXPgfkijUiV3LySrM3xKatZpx4M V3X_0_gxCe5Uc_e.vmtFy7h85wWCctO5Y.o9AKGrj3RDSPJQ1lK63aez7O4ciMtVDm3a4YdYHgf3 Nc3e4m5a_5nYOKjIN9m1cWmxhvKxzUiPV2waUL..Wtt4tCPc5dA3WDyV6ewZg_GDtT9QnVw22zVi RaZ7o95FFlnF07OolOTS6r6DoUKmtGcOg2wWGdY3duO4OjezF4mDWWx.Ng9z1morX5M_8UMtYdOX TdQOf_5NRALR52eCpO8Toon4nlGJJTg_jkZ6LlrBQnse7pgAbk1Ax685sp4lrRng8IfjgyLQyNcF IRRjpYH_er6qr1yk0DwT2ivoHQe2A1QcknX3eUVjZWBq3PUpr6VH1ZOaLpDdbamu0xpMky8mdztt 8zdKJMSukm68RJlJb8vnygZsYXrrZ0nTxU_y0btjOZoU9VmMIsCgF4EiD1X7x1S2FH3qwfskZIm7 f9CnjaEw5LjoEHprLtqehQTKCCpOKSenIdMrDeTgF4tPsswz5zSOmWIY1RZmWvMCUW_zo454IFhk 1gE23esPQqnVOcGObkjGHJyWvysYEuVByDNBIMWy2Tek0knRHykO_y9O2xS7SmV95TRVgh0Jpd4Z C2ObNT48irfwV9G0TTFsvL0KqkxsSfen_H9nT4Tm44vjSAnAnaIw5cTwauBLfn7389PCT4CO3FJ2 wIn8zGein5xLhIna3_g3_gW4KlmjwLhfrMndeV7XCUBA7Fjmz4lyhNayfQJ_M9Ias_Nff808qOAJ QyJAPxB2DG4wnI3RvPcpC5ByXCttyoWbEuK_Nsx4qYYLp2UPu4CS5YWwlrAd04IQzbcVqmf3qYsO MAXH0QAelFvyQDAj3wUEskfQKoYOewwyel5zx6KiH71hPEC7t7n11Vrik51OlrwgaibWEPCV7hci DFpy2glx0uVhnN3r7gdSZx5ClaAnDozUfEciox8PAiPv6fqDUQ7K0Nj.5tkC4fPSfjeGuE2_hR9O zYVNH1dAu8UJU1Cc- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Jan 2022 01:20:34 +0000 Received: by kubenode517.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d3f01c2ba491c35560569b7f7fe3c767; Mon, 17 Jan 2022 01:20:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: WITH_ASAN= vs. vfork: ASAN can not deal with vfork in a reliable manor, so what to do to avoid vfork fairly generally, including for kyua? From: Mark Millard In-Reply-To: Date: Sun, 16 Jan 2022 17:20:27 -0800 Cc: Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JcYxj49nvz3Pkc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=JrffxhNM; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-15, at 15:25, Mark Millard wrote: > ASAN is documented to not be able to deal reliably with vfork use > (inaccurate results, result mixing interpretations of the old > and new contexts, and so on). [There may be other routines > sufficiently analogous to vfork to have the same sorts of issues. > I'll write only of vfork explicitly.] >=20 > It turns out that using SH_DISABLE_VFORK=3D with kyua runs > helps avoid a bunch of junk failure ASAN reports that involve > /bin/sh using vfork. So I've been recently using the likes of: >=20 > env SH_DISABLE_VFORK=3D ASAN_OPTIONS=3Ddetect_container_overflow=3D0 \ > kyua test -k /usr/tests/Kyuafile >=20 > in my kyua runs. But that need not cover all the vfork use in > the kyua runs --or in general system operation. >=20 >=20 >=20 > There is more that could be done. For example . . . >=20 > contrib/llvm-project/compiler-rt/lib/asan/asan_interceptors.h > currently has: >=20 > #if SANITIZER_LINUX && = \ > (defined(__arm__) || defined(__aarch64__) || defined(__i386__) || \ > defined(__x86_64__) || SANITIZER_RISCV64) > # define ASAN_INTERCEPT_VFORK 1 > #else > # define ASAN_INTERCEPT_VFORK 0 > #endif >=20 > The "# define ASAN_INTERCEPT_VFORK 1" causes interception to > use fork for the vfork implementation, instead of an actual > vfork. >=20 > It looks to me like asan_interceptors.h for FreeBSD should > also be using: >=20 > # define ASAN_INTERCEPT_VFORK 1 >=20 > but it currently is not. Well, looking around there does not seem to be a FreeBSD-supporting implementation to go with use of "# define ASAN_INTERCEPT_VFORK 1". So there would be more to it than just causing the #define to happen. Thus, there does not seem to be a quick way for me to see what would result in the kyua run from more avoiding of vfork use (beyond what use of SH_DISABLE_VFORK=3D did). > There is even the possibility that a WITH_ASAN=3D buildworld could > build a world that uses fork behavior for vfork and never does an > actual vfork (by behavior). Basically restricting itself to things > that fit with ASAN use. >=20 >=20 >=20 > I tracked this issue down via a report in a kyua run that > referenced: >=20 > QUOTE > ERROR: AddressSanitizer: stack-buffer-underflow on address = 0x7fffffffa580 at pc 0x000801e0f8ed bp 0x7fffffff9bf0 sp 0x7fffffff9be8 > WRITE of size 8 at 0x7fffffffa580 thread T0 > . . . > Address 0x7fffffffa580 is located in stack of thread T0 at offset 0 in = frame > #0 0x7fffffffa5ef () >=20 > This frame has 1 object(s): > [32, 288) 'buf' (line 180) > HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork > (longjmp and C++ exceptions *are* supported) > END QUOTE >=20 > The "'buf' (line 180)" turned out to be from the declaration in > bin/sh/exec.c 's tryexec : >=20 > static void > tryexec(char *cmd, char **argv, char **envp) > { > int e, in; > ssize_t n; > char buf[256]; >=20 > execve(cmd, argv, envp); > e =3D errno; > if (e =3D=3D ENOEXEC) { > INTOFF; > in =3D open(cmd, O_RDONLY | O_NONBLOCK); > if (in !=3D -1) { > n =3D pread(in, buf, sizeof buf, 0); > close(in); > if (n > 0 && isbinary(buf, n)) { > errno =3D ENOEXEC; > return; > } > } > *argv =3D cmd; > *--argv =3D __DECONST(char *, _PATH_BSHELL); > execve(_PATH_BSHELL, argv, envp); > } > errno =3D e; > } >=20 > So I could finally see/validate that an example > stack-buffer-* report was tied to vfork handling > (analyzing other code related to the tryexec use). >=20 > The report happens well after tryexec did its > execve. The information about buf is just old, > no longer accurate information, leading to a > false report: >=20 >=20 > =3D=3D87961=3D=3DERROR: AddressSanitizer: stack-buffer-underflow on = address 0x7fffffffa580 at pc 0x000801e0f8ed bp 0x7fffffff9bf0 sp = 0x7fffffff9be8 > WRITE of size 8 at 0x7fffffffa580 thread T0 > #0 0x801e0f8ec in bintime2timespec = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/us= r/include/sys/time.h:285:14 > #1 0x801e0f8ec in __vdso_clock_gettime = /usr/main-src/lib/libc/sys/__vdso_gettimeofday.c:195:2 > #2 0x801e0e1a0 in clock_gettime = /usr/main-src/lib/libc/sys/clock_gettime.c:48:11 > #3 0x10d54da in clock_gettime = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:2189:13 > #4 0x11234f5 in __sanitizer::MonotonicNanoTime() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_linux_libcdep.cpp:860:3 > #5 0x10ba02c in = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::PopulateFreeArray(__sanitizer::AllocatorStats*, unsigned = long, __sanitizer::SizeClassAllocator > 64<__asan::AP64<__sanitizer::LocalAddressSpaceView> >::RegionInfo*, = unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_primary64.h:790:45 > #6 0x10b9c4b in = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::GetFromAllocator(__sanitizer::AllocatorStats*, unsigned = long, unsigned int*, unsigned long) /u > = sr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitize= r_allocator_primary64.h:220:11 > #7 0x10b9955 in = __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocato= r64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::Refill(__sanitizer::SizeClassAllocator64LocalCac > = he<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddres= sSpaceView> > >::PerClass*, = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >*, unsigned lo > ng) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_local_cache.h:103:9 > #8 0x10b9615 in = __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocato= r64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::Allocate(__sanitizer::SizeClassAllocator64<__asa > n::AP64<__sanitizer::LocalAddressSpaceView> >*, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_local_cache.h:39:11 > #9 0x10b9511 in = __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::A= P64<__sanitizer::LocalAddressSpaceView> >, = __sanitizer::LargeMmapAllocatorPtrArrayDynamic>::Allocate(__san > = itizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<_= _asan::AP64<__sanitizer::LocalAddressSpaceView> > >*, unsigned long, = unsigned long) /usr/main-src/contrib/llvm-project/compile > r-rt/lib/sanitizer_common/sanitizer_allocator_combined.h:69:20 > #10 0x10b6086 in __asan::Allocator::Allocate(unsigned long, = unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, = bool) /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_a > llocator.cpp:537:29 > #11 0x10b4818 in __asan::asan_malloc(unsigned long, = __sanitizer::BufferedStackTrace*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp= :980:34 > #12 0x110be9b in malloc = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:130:10 > #13 0x117aca3 in ckmalloc /usr/main-src/bin/sh/memalloc.c:71:6 > #14 0x115b1b1 in reprocess /usr/main-src/bin/sh/expand.c:912:9 > #15 0x1155163 in evalvar /usr/main-src/bin/sh/expand.c:784:3 > #16 0x1155163 in argstr /usr/main-src/bin/sh/expand.c:319:8 > #17 0x1151178 in expandarg /usr/main-src/bin/sh/expand.c:241:2 > #18 0x11427c8 in evalcommand /usr/main-src/bin/sh/eval.c:857:4 > #19 0x114705b in evalbackcmd /usr/main-src/bin/sh/eval.c:681:4 > #20 0x1151bfc in expbackq /usr/main-src/bin/sh/expand.c:476:2 > #21 0x1151bfc in argstr /usr/main-src/bin/sh/expand.c:323:4 > #22 0x1151178 in expandarg /usr/main-src/bin/sh/expand.c:241:2 > #23 0x11427c8 in evalcommand /usr/main-src/bin/sh/eval.c:857:4 > #24 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 > #25 0x113eb88 in evalstring /usr/main-src/bin/sh/eval.c > #26 0x113e9f9 in evalcmd /usr/main-src/bin/sh/eval.c:139:17 > #27 0x1145289 in evalcommand /usr/main-src/bin/sh/eval.c:1107:16 > #28 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 > #29 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 > #30 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 > #31 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 > #32 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 > #33 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 >=20 > Address 0x7fffffffa580 is located in stack of thread T0 at offset 0 in = frame > #0 0x7fffffffa5ef () >=20 > This frame has 1 object(s): > [32, 288) 'buf' (line 180) > HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork > (longjmp and C++ exceptions *are* supported) > SUMMARY: AddressSanitizer: stack-buffer-underflow = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/us= r/include/sys/time.h:285:14 in bintime2timespec > Shadow bytes around the buggy address: > 0x4ffffffff460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > =3D>0x4ffffffff4b0:[f1]f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff4c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff4d0: 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 > 0x4ffffffff4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4ffffffff4f0: f1 f1 f1 f1 00 f2 f2 f2 00 f3 f3 f3 00 00 00 00 > 0x4ffffffff500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07=20 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > =3D=3D87961=3D=3DABORTING =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jan 17 21:33:21 2022 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 4EF27195DECB for ; Mon, 17 Jan 2022 21:33:28 +0000 (UTC) (envelope-from 0100017e69f574c6-e9ca9950-d828-4627-ab59-32b2772c7f1c-000000@amazonses.com) Received: from a48-103.smtp-out.amazonses.com (a48-103.smtp-out.amazonses.com [54.240.48.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jd4s322Mpz3hPT for ; Mon, 17 Jan 2022 21:33:27 +0000 (UTC) (envelope-from 0100017e69f574c6-e9ca9950-d828-4627-ab59-32b2772c7f1c-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1642455201; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=3rahOF6SywzwPdJ4egFMgs9H4BQffnQWMx5KGMdgMSw=; b=IN5WDaCmHVu7By40IvZcOQ4SeEsCZw64W150283GtBSPvk/rbbMPt90tUpl2OkbO Vj9kVHu+i9/TxLp3toiCBJHaOEgEJzRdU1w2Do8b/VYGGHWmxhxyg0/+9TF0JE3EMq7 EPsxMSJtu0xELOz/slKVj+levivPNLwCbVC66S34= Message-ID: <0100017e69f574c6-e9ca9950-d828-4627-ab59-32b2772c7f1c-000000@email.amazonses.com> Date: Mon, 17 Jan 2022 21:33:21 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: Current FreeBSD From: Thomas Laus Subject: Kernel Panic main-n252492-ad15eeeaba3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES X-SES-Outgoing: 2022.01.17-54.240.48.103 X-Rspamd-Queue-Id: 4Jd4s322Mpz3hPT X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b=IN5WDaCm; dmarc=none; spf=pass (mx1.freebsd.org: domain of 0100017e69f574c6-e9ca9950-d828-4627-ab59-32b2772c7f1c-000000@amazonses.com designates 54.240.48.103 as permitted sender) smtp.mailfrom=0100017e69f574c6-e9ca9950-d828-4627-ab59-32b2772c7f1c-000000@amazonses.com X-Spamd-Result: default: False [1.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[54.240.48.103:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[acm.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[amazonses.com:+]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[54.240.48.103:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[lausts@acm.org,0100017e69f574c6-e9ca9950-d828-4627-ab59-32b2772c7f1c-000000@amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,0100017e69f574c6-e9ca9950-d828-4627-ab59-32b2772c7f1c-000000@amazonses.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim] X-ThisMailContainsUnwantedMimeParts: N I just updated today to main-n252492-ad15eeeaba3 from: main-n252313-ae13829ddce on 3 PC's. Two of them had the update go well but my Dell Inspiron 1545 had a panic after booting. This laptop doesn't have a scroll buffer and the entire panic message scrolls off the screen, so can't take a screen photograph. I compared the logged messages, I see this difference: ERROR :intel_cpu_fifo_underrun_irq_handler] CPU pipe B FIFO underrun In the /var/log/message on the laptop startup with the panic. All of the other successful startups on this PC, don't contain this error message. I tried both a GENERIC and GENERIC-DEBUG kernels with the same results. The other computers running main-n252492-ad15eeeaba3 don't have this message and all of them successfully boot after the update. It looks like my project tomorrow will involve an exercise in revert and bisect. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From nobody Tue Jan 18 02:07:43 2022 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 A0643195B56B; Tue, 18 Jan 2022 02:07:52 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdBxg4x03z4nGs; Tue, 18 Jan 2022 02:07:51 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 20I27hca089300 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 17 Jan 2022 18:07:43 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 20I27hcm089299; Mon, 17 Jan 2022 18:07:43 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Mon, 17 Jan 2022 18:07:43 -0800 From: Gleb Smirnoff To: dev-commits-src-main@freebsd.org, current@freebsd.org Cc: bz@freebsd.org, zec@freebsd.org Subject: netinet & netpfil tests failing Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4JdBxg4x03z4nGs X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [2.90 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[dev-commits-src-main,current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, just to remind that I'm responsible for multiple tests failing and to refresh the context, kind of explaining why the hell they aren't fixed yet?! The long old discussion can be found in this thread in December, link to last message: https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/002581.html Summarized refreshed context follows. The reason for failing tests is complex. There a constellation of factors [bugs] that attribute to it: * Jails are reference counted and jail destroy may be delayed. Test suite usually didn't trigger delayed jail destroy and expectation of many tests is that immediately after 'jail -r' all resources are released, especially network interfaces in a jail are if_vmove()'d to vnet0. * My original change to inpcb database protection ignored the fact that inp->inp_cred->cr_prison is dereferenced and read during a fast pcb lookup. The prison doesn't have neither network epoch nor SMR protection. That was a bug and to fix it me & Mark decided that an elegant idea would be to delay crfree() when a pcb is destroyed from immediate call to SMR-delayed destructor. This fixed the race, but created another bug. Since every vnet had its own pcb zone, a dying jail won't ever free its resources, it will stay forever. This was mitigated by making the pcb zone global. Now pcbs are correctly recycled, but there is no guarantee that upon return from 'jail -r' the jail is already fully cleared. * Back to tests. As tests expect 'jail -r' to immediately free resources. Right after 'jail -r' tests do 'ifconfig ${ifname} destroy', where ifname is the interface that was just popped up back to vnet0 from the destroyed jail. Now this 'ifconfig destroy' fails, but test suite ignores this error. A test succeeds. However, some time later, usually after other tests, the jail is indeed destroyed and surprise interfaces out of nowhere pop up at vnet0. Of course this is definite memory&resource leak, but not the reason why tests are failing. * Another factor - scapy. The python scapy library would emit warning to stderr if it sees interface without any IP address. This happens right at 'import scapy'. The test suite considers a test failed if it has something on stderr, even if it returned success. So, result is that some test (absolutely unrelated to pcbs) leaves a jail with interfaces, then jail is released, interfaced pop up at vnet0, and then some other test (absolutely unrelated to pcbs) using scapy writes a warning to stderr and triggers failure. My & Mark are now seeing three approaches to the problem: * Reclaim the memory from pcb zone(s), when jail is destroyed, returning back the old behaviour that with test suites 'jail -r' is always synchronous. Some prerequisites for this approach are here: https://reviews.freebsd.org/D33868 * Protect jails with epoch, bypass the cred pointer in inpcb and in the lookup check inp->inp_prison->pr_foo. After that the crfree() can be moved back to the immediate inpcb free procedure. Mark has a quick & dirty proof of concept for this approach. * In the test suite destroy the interface from the jail: 'jexec jname ifconfig ${ifname} destroy'. I'd like to add a few words on the last option. To me it seems most elegant as we are improving the test suite instead of changing kernel to meet demands of the suite. However, it doesn't work :( Why? Why does 'jexec jname ifconfig epair0b destroy' or 'jexec jname ifconfig lo1 destroy' returns ENXIO? Because the interface was created within vnet0 and is linked on vnet0 cloner's list. To repeat: epair0b ifnet is linked to the jail's list of network interfaces, but it linked on vnet0 list of epair(4) ifcloner. Likewise, some lo4 interface would also be in the jail list of interfaces, but on vnet0 if_loop cloner. This makes it impossible to destroy such interface from inside the jail. Neither it is possible to destroy it from the outside, for obvious reasons. There are more side effects about this. For example the only reason why we can't create an interface with the same name inside a jail using its cloner list is call to ifunit() in the beginning of if_clone_createif(). This definitely is a part of design, since if_clone_create()/if_clone_destroy() would lookup vnet0 cloner list in case if interface is not found on the current vnet list. To put it short, it is yet another problem created by if_vmove :( Not an easy one to fix and makes the third approach to the problem complicated. To sum up: I'm sorry for tests broken, I'm working on it, it isn't easy problem. Suggestions and help are welcome. -- Gleb Smirnoff From nobody Tue Jan 18 04:52:32 2022 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 8BB5B19573E9 for ; Tue, 18 Jan 2022 04:52:50 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdGc15ltMz4tDB for ; Tue, 18 Jan 2022 04:52:49 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f182.google.com with SMTP id t9so26711069oie.12 for ; Mon, 17 Jan 2022 20:52:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wnUCBHEd7cl4YSukP46NyQU64Wzc8l+yNxbB78fPt8s=; b=lbqhOJ6lnOK23M7sunE+RFBgc3SP+l71jTTryatl8Y/5ECq3JEYIis3jpsPj8Z4wm8 IaHhGM+afTKtNroUsAmyzhsz003bokioIqOP7EP5ZucYANwwsCkh/wyUP2AH/KJX4Z/9 8lDyTMQzD2PGHgO8M4yko+FEFCEYlRiisf62IK0S0J8rVGFn09yo/au3zGy6y+rX2Ysq NrVlaLm0H1rpoTcd13ZrXPLTDWwFdfc0a2mhXtcKH9yER0psA4HoE2jWo5+NaPnwZ03h SYrl57ri95qyTGGkGaVxxOOlSfIg5QhjC6f2fm0MJKvOVgcsw+pkuT6PTZcXA9URsc24 D5BQ== X-Gm-Message-State: AOAM530XKxuot3g1CJvQO4Z7IsGzZ/o0Yl4mjCegmPY8/RY+zB0MW+B3 AjW4UMrcGunm1zPjBCwJGSHICoFtVNybYdC64KIke7P6ZHs= X-Google-Smtp-Source: ABdhPJw+plY8pKGCpVIkBt8m4IoGmphO/uHKuKcJJRS5xp7d0UyMWk1UNZiaXhQy1On6Ae5fCRpeakfPLixm03AkmPE= X-Received: by 2002:a05:6808:254:: with SMTP id m20mr25267239oie.55.1642481563183; Mon, 17 Jan 2022 20:52:43 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Alan Somers Date: Mon, 17 Jan 2022 21:52:32 -0700 Message-ID: Subject: fspacectl meets DIOCGDELETEE To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JdGc15ltMz4tDB X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.182 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.182:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.182:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N fspacectl(2) does for regular files the same thing that DIOCGDELETE does for GEOM devices. The only differences are that DIOCGDELETE requires the operation to be block-aligned, and if interrupted DIOCGDELETE doesn't give feedback about partial progress. Can we connect the two? That would allow a user to free space with a single API for both files and devices. It would require: * Adding a d_fspacectl_t member to struct cdevsw * Implementing d_fspacectl_t for g_dev_cdevsw by using DIOCGDELETE * Implementing .fo_fspacectl for devfs * Optionally implementing d_fspacectl on other device types, like zvols. -Alan From nobody Tue Jan 18 09:39:14 2022 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 5B7F11950E2A; Tue, 18 Jan 2022 09:39:18 +0000 (UTC) (envelope-from kp@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdNyZ2Dqdz4lyL; Tue, 18 Jan 2022 09:39:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642498758; 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=ULWS8E7FP1rP1UNR9gJn+9Cnjq9a/TcBX1wqCryygPQ=; b=tHlnuaBAbq0twlyn9XDAPWMUKHwh7gZy+Rm4hQp3kwxlnmc5uVBthu8X01Bx2ewIcdvCJQ /BnqQkB4J11NZE93TdFQ0kHyDDz2x8ZyQlCSUzqZXQRQ7Rj+UZMzdnLC3kedwfWt0Xp2AG 311UTEOZsrnPHDhEFnl6aXfyGj45SnSd30wwL4tdO5CYOHbJVuZfJa8aOW6gdKwMmp48zP aJ7KBXlf0ahPG6AKhSlW5SXwd6DhhSZucxk6CyxePy370lM3Bua1tSI4bCIPto2CBvwGPs lyQ2bKhuxcr1/nklI+bmPukbF63Tgv0V+HIMXGalCuLw5hEtVu6GpKYBcWB45Q== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 13A5525D96; Tue, 18 Jan 2022 09:39:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id E642845794; Tue, 18 Jan 2022 10:39:15 +0100 (CET) From: Kristof Provost To: Gleb Smirnoff Cc: dev-commits-src-main@freebsd.org, current@freebsd.org, bz@freebsd.org, zec@freebsd.org Subject: Re: netinet & netpfil tests failing Date: Tue, 18 Jan 2022 10:39:14 +0100 X-Mailer: MailMate (1.14r5852) Message-ID: In-Reply-To: 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=UTF-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642498758; 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=ULWS8E7FP1rP1UNR9gJn+9Cnjq9a/TcBX1wqCryygPQ=; b=hogPVR4DyHzVsk1A28+3s1nF93vaOZxdaDEpqJ32sijwITd61J4y8vwWlVyrKW8ywhhGab T3C5LrH8QotDs4T0V2wurR3Ru1iR5xbiHMQi7t4KRUnHHwKyZ7EJELoJX2V1+VODxmkwau CU0h0A85H4QJBgnJTQWY/vw4Xcs/89KR4+EtbnkpitTvYdeiIJYh4uoR6eNtw8VwOPT+Da O7rjQLBpS/HLaoVkHwJPcb1NjroMLlQhYNK69Gv+2KIu2R8aotkhxxPt1LxPgxASo5AFYB MgfGRYISJF4LRSRC6xnIrThCSt7dWvLfePhy4YZyL0w7ipgxDyU3kxGPBk0kFw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642498758; a=rsa-sha256; cv=none; b=WUMPjFG1mhpYcAPoQza9Yu42Fekt3qgQI6ff19xq+sTfb081TIwBwODUA9dmtJZ0WTDkrt 28mlhami2ppbqF/yZy5wTd1ARGb71ASj07EsGL9UBIFOyAcTquw57Z8rZYqYw+7B8RvRnq x5JYYeDpAdoMvB/mfRYdM683BzJX4VyBiumsWYM07m7tNtscBKBJ85wc198K4aV/N75gBg qiupZPsPOT64dj3hJPdEW2ZFVDqhqs2ykIHJiRKN91S05XR0bMtzGLZZqcVP2AoE9e3hCL wyvFfh2eTRBSB1XTF+KxcY+ExT6xJP9nGPFb+rvTSi/H/2RjGNqxZU04oKCOLw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 18 Jan 2022, at 3:07, Gleb Smirnoff wrote: > * Another factor - scapy. The python scapy library would emit warning = to stderr > if it sees interface without any IP address. This happens right at '= import scapy'. > The test suite considers a test failed if it has something on stderr,= even if > it returned success. > > So, result is that some test (absolutely unrelated to pcbs) leaves a ja= il with > interfaces, then jail is released, interfaced pop up at vnet0, and then= some > other test (absolutely unrelated to pcbs) using scapy writes a warning = to stderr > and triggers failure. > Several of the pf scapy scripts deal with that issue by setting the scapy= log level: https://cgit.freebsd.org/src/tree/tests/sys/netpfil/pf/CVE-2019-5597.py#n= 30 So that part at least we could probably mitigate easily. (I=E2=80=99m not overly fond of that decision in scapy, but didn=E2=80=99= t want to resort to patching scapy to cope with our fairly specific requi= rements.) Kristof From nobody Tue Jan 18 15:48:23 2022 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 7A513196F41A for ; Tue, 18 Jan 2022 15:48:31 +0000 (UTC) (envelope-from 0100017e6ddffea1-27869488-66ee-4c31-83d9-61428a6d9883-000000@amazonses.com) Received: from a48-98.smtp-out.amazonses.com (a48-98.smtp-out.amazonses.com [54.240.48.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdY8Z4zsNz3mGG for ; Tue, 18 Jan 2022 15:48:30 +0000 (UTC) (envelope-from 0100017e6ddffea1-27869488-66ee-4c31-83d9-61428a6d9883-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1642520904; h=Message-ID:Date:MIME-Version:Subject:From:To:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=T5Eaz/xqtnOTggvpjI3K6POIVSC+ENuTMwgNeO5RWZM=; b=gSYo+CLlfAFPPJifRPYH1MjAuLaOgmJRgKKnHwOCLFtfEcN5eNsMZLVMvnY6c1F7 3uPdNCyHF/q7L9GevpKtiW86+n7bSQyrr1gi1YZDWxdn7tXRFEUAsZavKJlaMAy2VUu 00YQ6bYxBbDafg44I3D1B325wAP5mL/1SSn8XZkE= Message-ID: <0100017e6ddffea1-27869488-66ee-4c31-83d9-61428a6d9883-000000@email.amazonses.com> Date: Tue, 18 Jan 2022 15:48:23 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Kernel Panic main-n252492-ad15eeeaba3 - Solved Content-Language: en-US From: Thomas Laus To: Current FreeBSD References: <0100017e69f574c6-e9ca9950-d828-4627-ab59-32b2772c7f1c-000000@email.amazonses.com> In-Reply-To: <0100017e69f574c6-e9ca9950-d828-4627-ab59-32b2772c7f1c-000000@email.amazonses.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES X-SES-Outgoing: 2022.01.18-54.240.48.98 X-Rspamd-Queue-Id: 4JdY8Z4zsNz3mGG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b=gSYo+CLl; dmarc=none; spf=pass (mx1.freebsd.org: domain of 0100017e6ddffea1-27869488-66ee-4c31-83d9-61428a6d9883-000000@amazonses.com designates 54.240.48.98 as permitted sender) smtp.mailfrom=0100017e6ddffea1-27869488-66ee-4c31-83d9-61428a6d9883-000000@amazonses.com X-Spamd-Result: default: False [-0.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[54.240.48.98:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[acm.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[amazonses.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[54.240.48.98:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[lausts@acm.org,0100017e6ddffea1-27869488-66ee-4c31-83d9-61428a6d9883-000000@amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,0100017e6ddffea1-27869488-66ee-4c31-83d9-61428a6d9883-000000@amazonses.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 1/17/22 16:33, Thomas Laus wrote: > I just updated today to main-n252492-ad15eeeaba3 from: > > main-n252313-ae13829ddce on 3 PC's. > I tried bisecting the 87 changes involved between main-n252508-aac52f94ea5 to main-n252492-ad15eeeaba3 and started at the halfway point and worked forward. After 25 kernel build updates, I was still able to boot on this laptop. I gave up and did a 'git pull' to the latest and everything came up OK. I never isolated my problem but all is good today. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From nobody Tue Jan 18 21:50:18 2022 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 D3271195E9EA; Tue, 18 Jan 2022 21:50:29 +0000 (UTC) (envelope-from zec@fer.hr) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70089.outbound.protection.outlook.com [40.107.7.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdjBF1r8kz4b1m; Tue, 18 Jan 2022 21:50:29 +0000 (UTC) (envelope-from zec@fer.hr) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gEHscngqsLqFYMYb8YxzeApdL8qoPymF+KnxVfcz2mbjbJcDZLpqCxHEtGsYaoJFMgWEavmSpZOtzzFHoypnlZ0N0ycCT6DW06DhYtEor8e3s5w3bBYcjDEUqYgM8gsHR/nqLEgEtb8qaCidtyLqobypFjsPWsPSmk8z6e0J2Fhqu0axazv24/S8Ev17lxO1xq2PLM0MXgt0vy2SQfxirlPPwpN4r8lCu/UJIKsve2Tn0myquZJOMS9F0Y4y2i0xzmPL87Fl4GQH4HQeyVOF3SaOcKKZ/sYIO35R5bmUAj9G+7ILRd0Q15kiu3puVAMag96bhc8IPx4v58h0+b6uUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+WCMSXUT8DiUDjqrBrlhQcico1nZBG6FBrHADyRMkdg=; b=iKC+rrOMQmPHJzTBYsYwhie6dNjCJ8KtFomshhIVl46mRCf+yIr9IodKwyibSn/KzkKT0gFw6szooamebHhXtH+Bxrim4Hvz/nmenK0EWN/4cNpw2lpWeSe1R393q0vKtNAf8OdzTq4HdjoKKd6RHJNXVMaW5YTmJ1JMQeRjL0O1SXaYNaQByWQ/2JNJ3KffkvVEGHXv0+uGbHp/y6oTh8PL0ptf8nEvF/mRR8OL5sZgyrWil9YSbTA43/3DXHvDZExQ1Xo9NRyTwnYM+VHROpiKKK3lNRuRn7XFrVyjA72BZU5LDuch3otg6BKG9NEa0mpZEpXpWUaHZftjXJJiJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fer.hr; dmarc=pass action=none header.from=fer.hr; dkim=pass header.d=fer.hr; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ferhr.onmicrosoft.com; s=selector2-ferhr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+WCMSXUT8DiUDjqrBrlhQcico1nZBG6FBrHADyRMkdg=; b=UgfJR9OcWfxxMv7mJ1L7Q5z3f8r5H7Pqg+/GpoWIggdFYsf6wAOg92gwSMQtHx03QGfgBnw2k863FYuON4n+0deZrxMWabnGSTYKxPg8s27dKvTaN2fx+ug+OWXAh9jgtzT8OH+AZBaWSYng8yKDPmwrv1RAgrKXhNEjRbbM9AU= Received: from VE1PR08MB4783.eurprd08.prod.outlook.com (2603:10a6:802:a9::16) by AM6PR08MB4485.eurprd08.prod.outlook.com (2603:10a6:20b:bd::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.10; Tue, 18 Jan 2022 21:50:21 +0000 Received: from VE1PR08MB4783.eurprd08.prod.outlook.com ([fe80::f077:7274:ad5:303]) by VE1PR08MB4783.eurprd08.prod.outlook.com ([fe80::f077:7274:ad5:303%5]) with mapi id 15.20.4888.014; Tue, 18 Jan 2022 21:50:21 +0000 Date: Tue, 18 Jan 2022 22:50:18 +0100 From: Marko Zec To: Gleb Smirnoff Cc: dev-commits-src-main@freebsd.org, current@freebsd.org, bz@freebsd.org, zec@freebsd.org Subject: Re: netinet & netpfil tests failing Message-ID: <20220118225018.0ea91114@x25> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ClientProxiedBy: VI1PR07CA0289.eurprd07.prod.outlook.com (2603:10a6:800:130::17) To VE1PR08MB4783.eurprd08.prod.outlook.com (2603:10a6:802:a9::16) 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-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b59f635e-44ef-450c-9524-08d9dacc862e X-MS-TrafficTypeDiagnostic: AM6PR08MB4485:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1/mrxDge8VS+dxBYMHT8LjKBYRzNEbxPJp+oMTGaMIDFn+NTMXd+FW5gUQlOAfF3dwO4mDPeN8qFKPt1X/CCdCmidxW++lBDN7qb9kmsZHCn9kU4VB4ObuPZmtbP15D3i7pCLMhRHv3l2U8EhLexaNGLPSxFDW3p8u5zjNOFTtsYXIR53x+0MmQ46RSXfSE23qcUGxwc8w05bMdbk2RY1bN/1aa4dHEWcd7ZeJG+oqACU9+EKLT9c9QoxUimE8e51HA7sM+pBAX17GGA4++bq8R6uJiHgcDvPZk4BbIXdFvdMq1gLCneAj9oRoMwGUgAyT2L3ZZ2dvhFhZ6h1GnsD0MJSG1HSh37ly/j5Weq390Wq9bpYF2W8iKSbSecXnrCSWyWVZouvRmiEyLofJfbfJXmvNZ3GZAuqTJvtkmZ+poD5LyciHbzQoi9gOnWRW3jOMUvct1t6wp4cMgs7+zK3oo7noYgCWziW4gz3uB7h+pZxN3/woROcMJRG+W7hjDm2vAQzQQJ6TviQgbB+CpK0i4w00oiOrhQX9HChctOEEfQ5H/3pUIcD/zyg6Ju5KLan4TrKtNm6O31nkuIF0AhE/sb66JSvqRU57hE3orZfzpbY0Og465HRPOUqVVUkztMyXzEY9kgZWIK3ytY+ABeoN/N+1YmcBb1mRHLYN0MoDYnR0qX743V7lr75aomx5gZeCA2irVIoLG5teTD6w1OBdtTrHzRZ119ck0rpG5ioE/qSnHHCKGySz7Yixe5+YaCjOju5iOGH2RiHtnPqmYNcw== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR08MB4783.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(7916004)(366004)(316002)(66476007)(66556008)(186003)(6916009)(6666004)(86362001)(66946007)(6486002)(84970400001)(450100002)(5660300002)(83380400001)(52116002)(8936002)(508600001)(1076003)(6512007)(38100700002)(966005)(8676002)(786003)(9686003)(4326008)(26005)(6506007)(2906002)(33716001)(38350700002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?SFZheulqhOwEPeKIc32CaQwoV9XOuzLEy7AQmHjfJlssG9JdFqaIwkki6BU6?= =?us-ascii?Q?FLwDZRQ2G5d1reS57BHYg4QEbBeQ+IPCbSuVb+l6Q3bcfhUcZ8e9iSfwiRNZ?= =?us-ascii?Q?qP2fr0vZxF0v2f0dsmsw2swvg80Z3znCPYhS92I5vUYQCej97uTS6l11sxdK?= =?us-ascii?Q?v7yIyCHfNLacDUfGUEPBYoizxs9UU1JtSgYeviDGQKk6TLjmlG2nky/Djzh7?= =?us-ascii?Q?0a83RU4PFlz7p5rQmnl85T7FzE5rVOb6uOLL9iXjEINK9YLP8ErHwzB1KfGv?= =?us-ascii?Q?9cWotiezJsJjyRTy8wgEjC9O4zpy8LUjhqXYVu1gezma2PAddntevFgbkyut?= =?us-ascii?Q?VcIPZcPHd0l9ZqnYZTriHT2tKKm8O1KgWTHwACmBHFX1CwAML8XMpTza2FFF?= =?us-ascii?Q?aYtObuhhy5MbTrSQ6TKGGrKi+/nXWDH4s6j7T4WUFQ3c+8efVl+xPAVR/jXN?= =?us-ascii?Q?aift56ttIskRlC4my3RtDV66UT80cOqX6xx2I2BzhTrFHCxeqd1dZzY3cSrw?= =?us-ascii?Q?1bbUJTC+2xMkQtsj7D7l2tEUklUao8QSSBh1svG31t3JbWcYnrCGBQr3yBSU?= =?us-ascii?Q?sVIMIsFhnXm1Oen6fL4FzrPxTwNidV+QUmj1O891Qq8X7YfVqA/O/o8LOFWP?= =?us-ascii?Q?HE8JsdrvxGZJIGxii0OFEeDx9QRI8DGfJ8zvmYovLcRUT1LNuTl3OhJWlPxH?= =?us-ascii?Q?eWqiT2V2kNx2B6kP/cuIqccWTXauiIfemehNvCHXOJ+qJD+7Uu7X4xSzBnd6?= =?us-ascii?Q?MolmP2bD4Bp9r7q4yAPuQmUeWiXOpMVup8aCwhwpPTnY7L6TMBQNAphXSoR4?= =?us-ascii?Q?aalPgmBXxdY6MUv1nYw6S4tRwVu5vEyEoffb65YFbgrBJTUBSJ55uLyeHBj+?= =?us-ascii?Q?0H5nQsLW4tUoMu6zHAWF0TNjor0bf1vtwH6Weo2JkVKPCzZ+QB1yHB0k8Rnn?= =?us-ascii?Q?BQjU3iyg5Htdc22aVfppANNI+gjGExYKKr3uBUZT/fsnfsFroTJLPbA0yJni?= =?us-ascii?Q?gW1tSmoN8nuVarSRx5UbNJdmei/IpZsdK9Cw8X3VSZ05Jq1fTl0wVpvdQMAA?= =?us-ascii?Q?Y54bFXH28MNwAqs35PS9p9BO2l+9d+4hfk4S4JI03ugBG4s+JoO1i94+Yure?= =?us-ascii?Q?x8g5FnFM8a0Q+rU6xrYHjo1CiXOwLxltMQ+K6IvM2C78jP1w8zE2P93JzAKd?= =?us-ascii?Q?SgtCo1BfywV/Ke0YtrtTAGfj4ujB1APimqSi/GeobFn2vP2RWqLxn36Qm2i6?= =?us-ascii?Q?t81WiMif7eJ9vfCQAaQg2U79wSd7pjT6kpqTjA5b0i/Pf993/on1nsJu+wNK?= =?us-ascii?Q?wezqoevKk6xFXOGTsxJeIlTZF7281Rq78rKuEE+rzYri47CQxr0+9cI4rmya?= =?us-ascii?Q?F2Ib/ZWToDPUsQ3UDNATsUiHVE15pDT4/SN2UKpNtCB6/p61Hasx8uT0QNhy?= =?us-ascii?Q?UBETGssbV+alnjjGLO8ejcfZXeSsizbDZWhjpzx8B+g6zu89tX1gPN2I7EgL?= =?us-ascii?Q?/TaAw9V5KCkzY+aRUBimHG2oPARWOxUraauMR7PXyQIaD3iK+5+GROpr1akH?= =?us-ascii?Q?TSWj+YT5MMoV58pBIlo=3D?= X-OriginatorOrg: fer.hr X-MS-Exchange-CrossTenant-Network-Message-Id: b59f635e-44ef-450c-9524-08d9dacc862e X-MS-Exchange-CrossTenant-AuthSource: VE1PR08MB4783.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2022 21:50:21.1987 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ca71eddc-cc7b-4e5b-95bd-55b658e696be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 8ZudShDuAchHI5iwZDh7ZnyU7lkq6vz33n/QR1Rqez0ajXxP2ynh2qG/W9IuFO0F X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4485 X-Rspamd-Queue-Id: 4JdjBF1r8kz4b1m X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 17 Jan 2022 18:07:43 -0800 Gleb Smirnoff wrote: > Hi, > > just to remind that I'm responsible for multiple tests failing and to > refresh the context, kind of explaining why the hell they aren't fixed > yet?! The long old discussion can be found in this thread in December, > link to last message: > > https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/002581.html > > Summarized refreshed context follows. > > The reason for failing tests is complex. There a constellation of > factors [bugs] that attribute to it: > > * Jails are reference counted and jail destroy may be delayed. Test > suite usually didn't trigger delayed jail destroy and expectation of > many tests is that immediately after 'jail -r' all resources are > released, especially network interfaces in a jail are if_vmove()'d to > vnet0. > * My original change to inpcb database protection ignored the fact > that inp->inp_cred->cr_prison is dereferenced and read during a fast > pcb lookup. The prison doesn't have neither network epoch nor SMR > protection. That was a bug and to fix it me & Mark decided that an > elegant idea would be to delay crfree() when a pcb is destroyed from > immediate call to SMR-delayed destructor. This fixed the race, but > created another bug. Since every vnet had its own pcb zone, a dying > jail won't ever free its resources, it will stay forever. This was > mitigated by making the pcb zone global. Now pcbs are correctly > recycled, but there is no guarantee that upon return from 'jail -r' > the jail is already fully cleared. > * Back to tests. As tests expect 'jail -r' to immediately free > resources. Right after 'jail -r' tests do 'ifconfig ${ifname} > destroy', where ifname is the interface that was just popped up back > to vnet0 from the destroyed jail. Now this 'ifconfig destroy' fails, > but test suite ignores this error. A test succeeds. However, some > time later, usually after other tests, the jail is indeed destroyed > and surprise interfaces out of nowhere pop up at vnet0. Of course > this is definite memory&resource leak, but not the reason why tests > are failing. > * Another factor - scapy. The python scapy library would emit > warning to stderr if it sees interface without any IP address. This > happens right at 'import scapy'. The test suite considers a test > failed if it has something on stderr, even if it returned success. > > So, result is that some test (absolutely unrelated to pcbs) leaves a > jail with interfaces, then jail is released, interfaced pop up at > vnet0, and then some other test (absolutely unrelated to pcbs) using > scapy writes a warning to stderr and triggers failure. > > My & Mark are now seeing three approaches to the problem: > > * Reclaim the memory from pcb zone(s), when jail is destroyed, > returning back the old behaviour that with test suites 'jail -r' is > always synchronous. Some prerequisites for this approach are here: > https://reviews.freebsd.org/D33868 > * Protect jails with epoch, bypass the cred pointer in inpcb and in > the lookup check inp->inp_prison->pr_foo. After that the crfree() can > be moved back to the immediate inpcb free procedure. Mark has a > quick & dirty proof of concept for this approach. > * In the test suite destroy the interface from the jail: > 'jexec jname ifconfig ${ifname} destroy'. > > I'd like to add a few words on the last option. To me it seems most > elegant as we are improving the test suite instead of changing kernel > to meet demands of the suite. However, it doesn't work :( Why? Why > does 'jexec jname ifconfig epair0b destroy' or 'jexec jname ifconfig > lo1 destroy' returns ENXIO? Because the interface was created within > vnet0 and is linked on vnet0 cloner's list. To repeat: epair0b ifnet > is linked to the jail's list of network interfaces, but it linked on > vnet0 list of epair(4) ifcloner. Likewise, some lo4 interface would > also be in the jail list of interfaces, but on vnet0 if_loop cloner. > This makes it impossible to destroy such interface from inside the > jail. Neither it is possible to destroy it from the outside, for > obvious reasons. There are more side effects about this. For > example the only reason why we can't create an interface with the > same name inside a jail using its cloner list is call to ifunit() in > the beginning of if_clone_createif(). This definitely is a part of > design, since if_clone_create()/if_clone_destroy() would lookup vnet0 > cloner list in case if interface is not found on the current vnet > list. > > To put it short, it is yet another problem created by if_vmove :( Not > an easy one to fix and makes the third approach to the problem > complicated. > > To sum up: I'm sorry for tests broken, I'm working on it, it isn't > easy problem. Suggestions and help are welcome. Is there a reason why each test could not be composed in a separate master jail, with the actual test vnet topology below it? The setup routine would create epair interfaces in the master jail / vnet, and then delegate those ifnets to the subourdinated vnets. Once the test terminates, all the epairs would sooner or later end up back in that master jail, but never in vnet0. Problem solved. I've been doing this for almost 20 years with github.com/imunes/imunes, except that it uses netgraph instead of epairs for constructing vnet topologies. From nobody Wed Jan 19 03:18:34 2022 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 955B51952F79 for ; Wed, 19 Jan 2022 03:18:46 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdrT14TMLz4nPn for ; Wed, 19 Jan 2022 03:18:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642562318; bh=RzfwtoTKse2uXFRuXp3ydv7Z+1s/Z2M/sMwFyywUUXw=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=IW3sN6iTmdfOCEDCAgnMzKj4/+hfvynMR2X1xyYW2sp4CGhzzfgj7v8TSVkFewSgSewAvMf4W3nRbT8Z8dCp+v2S7g87H7zEKdoXtZaPr4LNEHsLu5jQ40lv7EoK1bki6EcKTZzebPMn+YKylQ8hfDj/+qKK/wwiTd2LcdMFULLez9YjDKB47obPdMlXDmb9KTUU8bOrJeJuQ1locsXHQbiGzOD0cpJpHI8CAbIjtornnX6BZgzU+l+OdA6Lk7HaZUhLrXgArSRRIib1HhwXpS7wYrW1dujb9XGYbtY0N89ya8GSInBQsm/JLnvktVzYXLlAep9agg1up1d8UQa5Ow== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642562318; bh=V2zevEbNEIx60Nl2cG3lNuf4EXmEEtu309Civ0d1L3s=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=hFmvsdnT5FvQGTLkFTfgJj1Pr3C4QFQWuIus58hV8S21bp/X11HjiNJhDsiNCuqF1wKuULtL2ZgsmLYtia86TJWEPKniK2OTOEQubwg52eXuTO7qq/F6mLIfCPxI91Pm1IuCqLCsbtBBYFBawtmkuPXn+3iIB7/Jxc7jNM0HKStR2/Ib/Ru7zSoF0uV8NJ8jMkx4jhYhepUJ9cA+1Hf7ljI6ejqms0zH7IqcYGzoE+ZD4/uB0p7X4lExjLDIDm9njHAeW0PbIeQIDdQUJKJJM8VyIvRRzC2gIC+zomWpnfcfCq6JAlxKhAPRXc64oxM7KAPR4ASaurnPWoPDSGnMmg== X-YMail-OSG: pBL6piMVM1mdTlAxao6X1NgzRgZQ2X8kb5nmJISrBkIL4chsXM5XGJESzKso.r0 GROVy9BoYYhcitBlXtado3CFytBBnUlHdesnneMqQ7HnUq4aqM4MTDWRkuoDyzyqns4uHOYQD9p0 rnqAfV8dujXqwmkq.jltc9OQ0FlYO7Dd7mZn_u.DVOdQHSeMVCTPBwEZIWAsFR6uG2TIRNON6GVc 7hs._fv2vEvMtRSunkp.aID03Odwql9E3cA1EFdMsOyJ_CmBqGqEJ.i7TDn9G96cTNl4QExp0xRr HPJQ52ImsnTr4QOQNj7JhInJeknUDLI9pBw0zMaJLIyGYYPtvQACJqvzJ64BTRd3j.ItAEeRVgXB w_bf_ZbN2alWxqNfW075R72b8jCmzZKk6FsykulRI5rWC5a1KM.fFRGSAvnLIHz5W8f6KKlFxbpu 0WHdhQP9cLnvOZOZkzYBxoYlXF4Nm.xq4DbxitEBTJ_TcLL25_PxWQPVuBj50EXP59ZMAshJlBEg 6xn2aZ3AioNR0q.5ouQn61.tpspp1FR.F0bMBKHAORuSnbpypo7gf3VR6zcK3uy3_2V4o5mi8suC EOySAZz.rLGjRJp7IZpUTSn_S2YCXyEg2uYu7yIPv.L1Kej6cugTozZarhT95J4CYZR2QrA7vqh0 NfKKYD4fQMUl0.X6HFAdq0jxM.VDpcaIeLD0lonKRNKZWZQLu7dAlLKf5YwnrbipWwJfe9uvNZZ2 1zg4pyj6tgVP9idSFJwAMVm4mlOaTxZoTpuJ53U6l13QYGvWm0pJKxUww_dj5mWpCJq_8BBJ__8g i9QthLy7IJXgwT57zu18JxoZzEyYDHyyrIZBQq4Vs3.mwV8BiQHJLX4R5N5DW4CpLCU1yJ4sau.K e3_CqfzczGPn8hjzBGS4Xqr5URm5xrvbtHSAC0hUpzjbrVhsrWwD08STlRg67ncr3f88KbbIv1KF CjhVgYxmlvWbGWJdDMxJ2WIgSpcaU4gma5xFtyYx6ItZAci12Q2ZXV67.l_I4_p2p.S9wzEuOrT8 _1Xpfi3EKBuEGyP_mMc5dCbov2QyZSxbzhuY5wpCM46kkgE9h_hAxJ7556BRO3_8K5HuEm3nGWIJ Qu5Bw83ihaOffGP9j8TqOa7SUE2n8z5D8nHJf3LZ26I5QAY3VHK2V2GDtItrWkcbP8RokcqU5WBN X_X2lXvm7wm95jIDBgJ11k43GkNu7DDHgo4j8w6i4g6fI3APnhn7t.DC09cbHpa75NMYim5V2LyY NfJo2U6OLoX2wA2twTjC7MB91s1_Q9ajAn2VLInnXoY.zde5wdhRmv6zuWZ3oD6GG5trKcDQWt3x hTC8bGa9AmFdJBsrc3r.SJHWCOMwp87DsPrvcyDk206UwmheX5tVDBgAKy2NCUMggZvrrtkvICD2 JrP_1ow6QvgkZXFGa3.T7bFvfAXFZclx2Bm9qc.co5.RZQnfInIfThLMTNsemk01VZ3mZYN2HQDK AyiJsVgEy5bvpw3xKkKxl_oc92xNzAsO1KjcFoXG4rFLuY24AQ9EEuuOgaz_sn05xp1JoNgh6EK0 2e.ZaYICizZH1LxcIoe1Agxaeov5wy0LjNhPSgwJWEfrEaFhVtCFK3MvAGqFjuD4AH1tEJJkhh.G 6v6ZmTdyoSimUPHT3D_1avmhyQJsTcktprQGiOVIj8bRRn7lNU2jM44zS535Kbc.rWo3GyqLa6eW YJrKfVduZwLcNQQzoMp.ueT_twaLrZJ699eVuaJq74BPe9fjmt0eLVvvKFaQvNfjc95smCI7MHJ2 8zoFbT.1xyhjrKUsXYlDeuVklUinpqvYkO_cgX4jV96dv5c64XfGVQmSh4zqYr71mdzdwvtLFyBd VskdkqOUu462bV2PReVzgjSQJPY3eXZcRWsS21y11qKcOtvIVkhlaNiA56RPRzGS0_.fg2llZybR eCL6dxDiMvKn6h6se3Q3aWLg_1ET.yVDxmTM.6Hd2E9BHtK1BdufkdEWFVczcA_6vFOUbB4gIpoE Gn12eRlby.AqsAXs6BagBcEEsO03ABEi38VWS_YRo2fU7rcB2n.8Fbc9Ouxz9d2KkQ0FtpReqAjV 4.bfDXdy8oTefmKTwBuIoE.0nzH9w6mfzLVpDdPqp7khOoT3W5RoE8FINganiaVVGqnnqespIk3s hagXmD.Nw2SKeTvL.VZWnOQCXXqQM1iSgUiJZfxsLG.MPuv1vMRbLJohjR8_WFiXUcuxhqJ2hD8k kXzuPQ6Lq_qmfOsWhXCDG_TJlnk9qQi4ZbF_nW1TDrq57YfSdgJY1_RaI17pGLJlRPvBt X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Jan 2022 03:18:38 +0000 Received: by kubenode534.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 75fba11257346082072a7065e3e39bc3; Wed, 19 Jan 2022 03:18:35 +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 14.0 \(3654.120.0.1.13\)) Subject: main [so: 14] lld got a: ERROR: AddressSanitizer: use-after-poison on address 0x621002402688 Message-Id: Date: Tue, 18 Jan 2022 19:18:34 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4JdrT14TMLz4nPn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=IW3sN6iT; 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 X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N It will probably be some time before I get to trying to have a simpler context, but here is some information, including related backtraces: . . . "/usr/bin/ld.lld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 = --hash-style=3Dboth --enable-new-dtags -o = ../cpp_clockinfo_main-ThreadRipper1950X-131072MiB-threads_32-LP64-FreeBSD_= main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN = /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = -plugin-opt=3Dmcpu=3Dx86-64 -plugin-opt=3DO3 --whole-archive = /usr/lib/clang/13.0.0/lib/freebsd/libclang_rt.asan-x86_64.a = --no-whole-archive --whole-archive = /usr/lib/clang/13.0.0/lib/freebsd/libclang_rt.asan_cxx-x86_64.a = --no-whole-archive --export-dynamic = ../objs/cpp_thousandslocale-clang++_13_O3lto-libc++-xSAN.o = ../objs/cpp_clockinfo-clang++_13_O3lto-libc++-xSAN.o = /tmp/cpp_clockinfo_main-3fa732.o -lc++ -lm --no-as-needed -lpthread -lrt = -lm -lexecinfo -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc = -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o = /usr/lib/crtn.o =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D48532=3D=3DERROR: AddressSanitizer: use-after-poison on address = 0x621002402688 at pc 0x000002145504 bp 0x7fffffff9880 sp 0x7fffffff9040 READ of size 8 at 0x621002402688 thread T0 #0 0x2145503 in memcpy = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:827:5 #1 0x33e77d9 in uninitialized_copy = /usr/main-src/contrib/llvm-project/llvm/include/llvm/ADT/SmallVector.h:505= :7 #2 0x33e77d9 in append = /usr/main-src/contrib/llvm-project/llvm/include/llvm/ADT/SmallVector.h:652= :5 #3 0x33e77d9 in = llvm::MachineInstr::cloneMergedMemRefs(llvm::MachineFunction&, = llvm::ArrayRef) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/MachineInstr.cpp:448:1= 4 #4 0x34c936c in mergeOperations = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:792:= 19 #5 0x34c936c in llvm::BranchFolder::mergeCommonTails(unsigned int) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:815:= 7 #6 0x34c9d01 in = llvm::BranchFolder::TryTailMergeBlocks(llvm::MachineBasicBlock*, = llvm::MachineBasicBlock*, unsigned int) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:974:= 5 #7 0x34c7869 in = llvm::BranchFolder::TailMergeBlocks(llvm::MachineFunction&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:1132= :21 #8 0x34c6b15 in = llvm::BranchFolder::OptimizeFunction(llvm::MachineFunction&, = llvm::TargetInstrInfo const*, llvm::TargetRegisterInfo const*, = llvm::MachineLoopInfo*, bool) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:204:= 34 #9 0x34cd7ff in (anonymous = namespace)::BranchFolderPass::runOnMachineFunction(llvm::MachineFunction&)= = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:133:= 17 #10 0x33ce97d in = llvm::MachineFunctionPass::runOnFunction(llvm::Function&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cp= p:72:13 #11 0x2ed4382 in llvm::FPPassManager::runOnFunction(llvm::Function&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1439:= 27 #12 0x2eda342 in llvm::FPPassManager::runOnModule(llvm::Module&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1485:= 16 #13 0x2ed4a08 in runOnModule = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1554:= 27 #14 0x2ed4a08 in llvm::legacy::PassManagerImpl::run(llvm::Module&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:542:4= 4 #15 0x2fbb8d8 in codegen(llvm::lto::Config const&, = llvm::TargetMachine*, = std::__1::function > (unsigned = int)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex const&) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTOBackend.cpp:416:17 #16 0x2fbab37 in llvm::lto::backend(llvm::lto::Config const&, = std::__1::function > (unsigned = int)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex&) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTOBackend.cpp:515:5 #17 0x2f2d3db in = llvm::lto::LTO::runRegularLTO(std::__1::function > (unsigned = int)>) /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTO.cpp:1134:13 #18 0x2f2c7a5 in = llvm::lto::LTO::run(std::__1::function = > (unsigned int)>, = std::__1::function = > (unsigned int)> (unsigned int, llvm::StringRef)>) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTO.cpp:1033:18 #19 0x25aa570 in lld::elf::BitcodeCompiler::compile() = /usr/main-src/contrib/llvm-project/lld/ELF/LTO.cpp:316:24 #20 0x2382c4a in void = lld::elf::LinkerDriver::compileBitcodeFiles >() = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:1986:31 #21 0x22fe9c9 in void = lld::elf::LinkerDriver::link >(llvm::opt::InputArgList&) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:2321:3 #22 0x22db283 in = lld::elf::LinkerDriver::linkerMain(llvm::ArrayRef) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:564:7 #23 0x22d9f15 in lld::elf::link(llvm::ArrayRef, bool, = llvm::raw_ostream&, llvm::raw_ostream&) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:122:11 #24 0x2b28651 in lldMain(int, char const**, llvm::raw_ostream&, = llvm::raw_ostream&, bool) = /usr/main-src/contrib/llvm-project/lld/tools/lld/lld.cpp:146:11 #25 0x2b28073 in main = /usr/main-src/contrib/llvm-project/lld/tools/lld/lld.cpp:211:12 0x621002402688 is located 3464 bytes inside of 4096-byte region = [0x621002401900,0x621002402900) allocated by thread T0 here: #0 0x21adead in operator new(unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_new_delete.cp= p:95:3 #1 0x2218a27 in Allocate = /usr/main-src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase= .h:85:12 #2 0x2218a27 in llvm::BumpPtrAllocatorImpl::StartNewSlab() = /usr/main-src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:3= 35:21 #3 0x221873e in llvm::BumpPtrAllocatorImpl::Allocate(unsigned long, llvm::Align) = /usr/main-src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:1= 90:5 #4 0x33e695a in Allocate = /usr/main-src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:2= 04:12 #5 0x33e695a in = allocate > = /usr/main-src/contrib/llvm-project/llvm/include/llvm/Support/ArrayRecycler= .h:130:38 #6 0x33e695a in allocateOperandArray = /usr/main-src/contrib/llvm-project/llvm/include/llvm/CodeGen/MachineFuncti= on.h:960:28 #7 0x33e695a in = llvm::MachineInstr::MachineInstr(llvm::MachineFunction&, = llvm::MCInstrDesc const&, llvm::DebugLoc, bool) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/MachineInstr.cpp:127:1= 9 #8 0x33d4f9e in = llvm::MachineFunction::CreateMachineInstr(llvm::MCInstrDesc const&, = llvm::DebugLoc const&, bool) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunction.cpp:35= 2:7 #9 0x39baa6d in BuildMI = /usr/main-src/contrib/llvm-project/llvm/include/llvm/CodeGen/MachineInstrB= uilder.h:349:25 #10 0x39baa6d in llvm::InstrEmitter::EmitSpecialNode(llvm::SDNode*, = bool, bool, llvm::DenseMap, = llvm::detail::DenseMapPair >&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/InstrEmit= ter.cpp:1165:5 #11 0x39b2e35 in EmitNode = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/InstrEmit= ter.h:145:7 #12 0x39b2e35 in = llvm::ScheduleDAGSDNodes::EmitSchedule(llvm::MachineInstrBundleIterator&)::$_1::operator()(llvm::SDNode*, bool, bool, = llvm::DenseMap, = llvm::detail::DenseMapPair >&) const = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/ScheduleD= AGSDNodes.cpp:872:13 #13 0x39b248f in = llvm::ScheduleDAGSDNodes::EmitSchedule(llvm::MachineInstrBundleIterator&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/ScheduleD= AGSDNodes.cpp:936:22 #14 0x399c06e in llvm::SelectionDAGISel::CodeGenAndEmitDAG() = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/Selection= DAGISel.cpp:1006:42 #15 0x399b447 in = llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/Selection= DAGISel.cpp:1622:7 #16 0x3998efd in = llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/Selection= DAGISel.cpp:509:3 #17 0x41c35a5 in (anonymous = namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) = /usr/main-src/contrib/llvm-project/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp= :193:25 #18 0x33ce97d in = llvm::MachineFunctionPass::runOnFunction(llvm::Function&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cp= p:72:13 #19 0x2ed4382 in llvm::FPPassManager::runOnFunction(llvm::Function&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1439:= 27 #20 0x2eda342 in llvm::FPPassManager::runOnModule(llvm::Module&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1485:= 16 #21 0x2ed4a08 in runOnModule = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1554:= 27 #22 0x2ed4a08 in llvm::legacy::PassManagerImpl::run(llvm::Module&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:542:4= 4 #23 0x2fbb8d8 in codegen(llvm::lto::Config const&, = llvm::TargetMachine*, = std::__1::function > (unsigned = int)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex const&) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTOBackend.cpp:416:17 #24 0x2fbab37 in llvm::lto::backend(llvm::lto::Config const&, = std::__1::function > (unsigned = int)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex&) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTOBackend.cpp:515:5 #25 0x2f2d3db in = llvm::lto::LTO::runRegularLTO(std::__1::function > (unsigned = int)>) /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTO.cpp:1134:13 #26 0x2f2c7a5 in = llvm::lto::LTO::run(std::__1::function = > (unsigned int)>, = std::__1::function = > (unsigned int)> (unsigned int, llvm::StringRef)>) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTO.cpp:1033:18 #27 0x25aa570 in lld::elf::BitcodeCompiler::compile() = /usr/main-src/contrib/llvm-project/lld/ELF/LTO.cpp:316:24 #28 0x2382c4a in void = lld::elf::LinkerDriver::compileBitcodeFiles >() = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:1986:31 #29 0x22fe9c9 in void = lld::elf::LinkerDriver::link >(llvm::opt::InputArgList&) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:2321:3 #30 0x22db283 in = lld::elf::LinkerDriver::linkerMain(llvm::ArrayRef) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:564:7 #31 0x22d9f15 in lld::elf::link(llvm::ArrayRef, bool, = llvm::raw_ostream&, llvm::raw_ostream&) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:122:11 #32 0x2b28651 in lldMain(int, char const**, llvm::raw_ostream&, = llvm::raw_ostream&, bool) = /usr/main-src/contrib/llvm-project/lld/tools/lld/lld.cpp:146:11 #33 0x2b28073 in main = /usr/main-src/contrib/llvm-project/lld/tools/lld/lld.cpp:211:12 #34 0x212ea5f in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 #35 0x805007007 () SUMMARY: AddressSanitizer: use-after-poison = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:827:5 in memcpy Shadow bytes around the buggy address: 0x4c4200480480: f7 f7 f7 f7 f7 f7 00 00 00 00 00 00 00 00 00 00 0x4c4200480490: 00 00 00 00 00 00 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 0x4c42004804a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4c42004804b0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 00 00 00 00 00 00 0x4c42004804c0: 00 00 00 00 00 00 00 00 00 00 f7 f7 f7 f7 f7 f7 =3D>0x4c42004804d0: f7[f7]f7 f7 00 00 00 00 00 00 00 00 00 00 00 00 0x4c42004804e0: 00 00 00 00 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 00 00 0x4c42004804f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f7 f7 0x4c4200480500: f7 f7 f7 f7 f7 f7 f7 f7 00 00 00 00 00 00 00 00 0x4c4200480510: 00 00 00 00 00 00 00 00 f7 f7 f7 f7 f7 f7 f7 f7 0x4c4200480520: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D48532=3D=3DABORTING clang++: error: linker command failed with exit code 1 (use -v to see = invocation) For reference: The context is a used-for-chroot installation of a WITH_ASAN=3D = WITH_UBSAN=3D build world. # uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #30 main-n252475-e76c0108990b-dirty: Sat Jan 15 21:18:14 PST 2022 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400047 1400047 # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ branch: main merge-base: e76c0108990b52a25f548cba4c0f1b8db59c6b8b merge-base: CommitDate: 2022-01-16 00:32:36 +0000 e76c0108990b (HEAD -> main, freebsd/main, freebsd/HEAD) Fix inverse = sleep logic in buf_daemon(). n252475 (--first-parent --count for merge-base) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 19 03:38:43 2022 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 C5F001961B27 for ; Wed, 19 Jan 2022 03:38:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdrwH2xzvz3Bty for ; Wed, 19 Jan 2022 03:38:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642563528; bh=hkJgRtBVOxYDJ/wCeGRQdBWVp9PatR83Gb9SaQflRWs=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=Z7GURc2fR23Grn/30hBvQhUB7TV3YGfVhQOib7EKjZOhlg3j5/wrmdphdvnd1Djth4yRWARIjVDmCOb6x2Jgj40niyxRkvhphm9X0K3ZAKAuUNWuIV2lp8gLl62EBHCMHRnYdGzET+b73u27TJfGGOSG4rywd2Iq4uu3tQTvbPzpSNsWhkCmpexWMv9RNgPFwjvUkkNb7GqPU1gF/k7mzoS46W2NmEqiCcLv0xSqOmLClYz+553oDnc8PG5o+1c4Ao/fwmXABdBSSYk2VtB/Zi+S7i5eq2kNu676vlhd8kNYcUeG0tCt0gSbsQ2aToY+aZWF04J3A8AwE/cmqIAQOQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642563528; bh=Mle8lwkRXmzFkOi4CXcjb5mMN+pQ0ZlEkYwytgxBZHN=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KedTo0xk6XbPWo2Xu7eQ1TqGWQCUQf6blm4M65EFoknuBGN65zwhDH+KGs0NMZ1o7ljGR7w8Ku0TmNUrdlJSaEkOZu4N4/cgiiGdV5ZG5A9BGxy2qm5w8Vhf6F4D4l4kuvL6uUqvG5do/8609xr9oi7RpLCbDY6lOBvHCRR/HzCssZtqDySjjjqMaxv76OIF2E4YyDpWKpQvf54ydtXXZHWrSdFnkqfaj9EATLqdGOyDNf+dTCCetUceIDC5ygw5DADmeIrucmYflyhKgCBt9ErLjaiH7R1Mv4ZtkeX1a+ZJrEEABug76kHz/sSClBvI3ueb3LYjwvixyL2uaO37MQ== X-YMail-OSG: LPzENlcVM1kh9uhHWlsh_wHs6IRQnGmj14_ns_SUk8OTB4wCQ0ebhu1ycwGL4wO 2_7_6qm2Cic2VjXfhcYEzOA5LLdWWei3C8VHAnfUXG4w5fXp9ukYlXzyoHSnrkuo_4Rae8ip2geZ sAH6ra_TvMCl6Fk.6Q5Oagy5NefpNznz7REPjzur1F7CH6R406ocv4pOxea6irltq5GzeofxXfxt 5PYzPMLXrOfiyn4cnduuAClvFwRnxRe5LL1QUmxKHbUGO2XRjMQ1PDa7uaE2zpvXA2vplVZuSr1c u96KGPIFnj801r5udUO1ISkK52YinXv018F9152_xbuZWTRqknNKdBKxkkiE31VK8G_zR5OdYdl2 KLTo5.plQiPgBbN97OSTo1fvaMF3vvduNxN9wZMyZVrAqF46CS5EKyjQeD08U.1DM9.SPEtO8Z0D .bGTAg0RgwNH5Az9DI8U5PJmGULtPULao10P35SFUzqP4wRjWe.cbeamXkUPATkmoTjAztMiQfKX e.TZCSAwedPzxcrlb1eOSXvRWJIBL1LB7fhz_18VSLTgFEoh7G7M_kZNyYfpGp7exSOEhR8z.OHC J6CzsYYPY_d9Wu3H4sygbn5Vv.u.bSRgPvbnWk0eqLXHZzewwKAlIatTbNjFRO1X9HQgjLFtA8m_ f_euVfD3rMD8aUGldL1D6Voiw6JDVlTnRhDcFknw0UzxH9uJbjskH.6WfBjrMYsj08NnQ5WQPZ9L noDT.XWPscIAYZB33N2Tu9eyb90iQAEkQmR4TPavJMh0F7Q5e4A2EhY38j29syRHA3IqQG9jXv8x vGpkD3vyHBVDF4kxFazXszpt9rDpimdRsQ10otpFnf1ydYlqoaEPV_wnVFKKKOuSElkkHq7MxHL8 X2uTWKO3zY8ieHJs1X64uLmSRpZWQyfABTCeTcpKHA46PFlkFKg6a6QvLqT_E6UQrEiinvBzCxpX aC2rF6yIL1.AfhAHxCYzHG2jQzsAjIRwoX8VjOaKJMf04.4PumI3KZWBaoLM7UDHBvtk3noK6j8L da9EDQjRz.NPBha0yCfHSF_rIdLaH_kIgtmndQO_eLmkwJ4Q0wiHUpHmsnK_ATmP6UbhQgQCg.Ji 4h79OlnnqsMgGbeeILvvVhTSzYzIlcuIHlBH1MUrVK3tj4yCEaDk1uU9ZRT0wq9DzBcCefbI_8H6 O9BMPtqWitYp0tOCeds8VhOPJT_agbKrumzvqHHyk92smU55s5JfyHJC9mK7WTbUOHb6z.95P.dB .hKSZX9SEMEmGHB.qEOjkpj5IDH4UlZYTwP11sR2nQ5Y3lDSIUEfWPopI5S1uSJvVIommkZ5E7tu Ij7CvDOjYS.eslzDXJ.XNh_WIK6z06qZ0PzDjNhqymAzxPmIihG4kWtJ05HIi_jFC5D0d7ToRZ32 od9tKOMWV3Uwt1jCkI5r70cIjghAwthwNJyeLSz_1mWfhhgLUrRMio8AqEFbZUSPRRFu7KnU8zSe OdlGbM_oMaFaXsPaq6PZpUQzze5lYuqxFgvb7iozOrtwhUmR2AIZErq5iS5YakzdJFiCdBNBBOuJ .p6Z6BiDb5YGKjfTvQu3H5i1tEYgMqaSKcKW03audxcmuSrVWyO4K9qPl0a5CA4eBEaXG.tni3ow 7_R28E64muXfz9__E.GO5nvdA4FNH51BkeKT75hmgy1VDz3IR5C2n6rP0QhES4LQQ4mINRuqvps1 Si5RHwVWNXGWwdGtNuLj1Osa.3_onhW3UGmpinPrxsDHG.sOX8siELx_u3pdc7CZwkurNWm1e8.Q 94Kac5U2m_8zTomI9.AyPH62xP5rm8h76uuqWL2_SxdDPK1f0ECJI7b7KNtp8CNtebFPa0CewsIS WawVi4paWb7XNlh0OZg0CXQF7AndaO6x62UmeWD4BRVckCqbTBlI0K42fZtqjgTbVwVotZ_5l07g SzpDJrhMKNCCFWRDqTlctiZ3Zsn0EW9IG5ok7mhKKfjkK4ekI1RtiiRWzueKokO4n7CZeyWgB4_t FZzrIyEMLBUixxslE3FFkdeKxzMgykzUu9al5yIuz1NDCUjiUYUQ84E7m0ytz7e40TTX5z57yAd6 PbBXAgsRgpKxldt6Q4hj0a.P_miDxwHnueZjtGjdWrASQQHyIZ9hIXzN2YKi5HnwUzgY6Xyl_ZTa D.QAtWMiIA4SodtKej8dC4vIb5cA8jEmolJ39sEx9xPjY7LU7Al6QEYlzn_Zi.p4Zp0FKRpsWYDw VLzGOWyF8gIlKmQRLNOTbpEST1BL46vVWDLEnz62O9rBlOdoQywqzfXQ9RUsUg.SFSiidnRoy X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Jan 2022 03:38:48 +0000 Received: by kubenode517.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 474b5440592e9e58e3729c33bef5e5fc; Wed, 19 Jan 2022 03:38:44 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: main [so: 14] lld got a: ERROR: AddressSanitizer: use-after-poison on address 0x621002402688 Date: Tue, 18 Jan 2022 19:38:43 -0800 References: To: freebsd-current In-Reply-To: Message-Id: <4934E13F-51CB-4C72-9336-0806168CF9E3@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JdrwH2xzvz3Bty X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Z7GURc2f; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-18, at 19:18, Mark Millard wrote: > It will probably be some time before I get to trying to have a > simpler context, but here is some information, including related > backtraces: >=20 > . . . > "/usr/bin/ld.lld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 = --hash-style=3Dboth --enable-new-dtags -o = ../cpp_clockinfo_main-ThreadRipper1950X-131072MiB-threads_32-LP64-FreeBSD_= main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN = /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = -plugin-opt=3Dmcpu=3Dx86-64 -plugin-opt=3DO3 --whole-archive = /usr/lib/clang/13.0.0/lib/freebsd/libclang_rt.asan-x86_64.a = --no-whole-archive --whole-archive = /usr/lib/clang/13.0.0/lib/freebsd/libclang_rt.asan_cxx-x86_64.a = --no-whole-archive --export-dynamic = ../objs/cpp_thousandslocale-clang++_13_O3lto-libc++-xSAN.o = ../objs/cpp_clockinfo-clang++_13_O3lto-libc++-xSAN.o = /tmp/cpp_clockinfo_main-3fa732.o -lc++ -lm --no-as-needed -lpthread -lrt = -lm -lexecinfo -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc = -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o = /usr/lib/crtn.o > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D48532=3D=3DERROR: AddressSanitizer: use-after-poison on address = 0x621002402688 at pc 0x000002145504 bp 0x7fffffff9880 sp 0x7fffffff9040 > READ of size 8 at 0x621002402688 thread T0 > #0 0x2145503 in memcpy = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:827:5 > #1 0x33e77d9 in uninitialized_copy = /usr/main-src/contrib/llvm-project/llvm/include/llvm/ADT/SmallVector.h:505= :7 > #2 0x33e77d9 in append = /usr/main-src/contrib/llvm-project/llvm/include/llvm/ADT/SmallVector.h:652= :5 > #3 0x33e77d9 in = llvm::MachineInstr::cloneMergedMemRefs(llvm::MachineFunction&, = llvm::ArrayRef) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/MachineInstr.cpp:448:1= 4 > #4 0x34c936c in mergeOperations = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:792:= 19 > #5 0x34c936c in llvm::BranchFolder::mergeCommonTails(unsigned int) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:815:= 7 > #6 0x34c9d01 in = llvm::BranchFolder::TryTailMergeBlocks(llvm::MachineBasicBlock*, = llvm::MachineBasicBlock*, unsigned int) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:974:= 5 > #7 0x34c7869 in = llvm::BranchFolder::TailMergeBlocks(llvm::MachineFunction&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:1132= :21 > #8 0x34c6b15 in = llvm::BranchFolder::OptimizeFunction(llvm::MachineFunction&, = llvm::TargetInstrInfo const*, llvm::TargetRegisterInfo const*, = llvm::MachineLoopInfo*, bool) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:204:= 34 > #9 0x34cd7ff in (anonymous = namespace)::BranchFolderPass::runOnMachineFunction(llvm::MachineFunction&)= = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/BranchFolding.cpp:133:= 17 > #10 0x33ce97d in = llvm::MachineFunctionPass::runOnFunction(llvm::Function&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cp= p:72:13 > #11 0x2ed4382 in = llvm::FPPassManager::runOnFunction(llvm::Function&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1439:= 27 > #12 0x2eda342 in llvm::FPPassManager::runOnModule(llvm::Module&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1485:= 16 > #13 0x2ed4a08 in runOnModule = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1554:= 27 > #14 0x2ed4a08 in llvm::legacy::PassManagerImpl::run(llvm::Module&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:542:4= 4 > #15 0x2fbb8d8 in codegen(llvm::lto::Config const&, = llvm::TargetMachine*, = std::__1::function > (unsigned = int)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex const&) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTOBackend.cpp:416:17 > #16 0x2fbab37 in llvm::lto::backend(llvm::lto::Config const&, = std::__1::function > (unsigned = int)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex&) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTOBackend.cpp:515:5 > #17 0x2f2d3db in = llvm::lto::LTO::runRegularLTO(std::__1::function > (unsigned = int)>) /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTO.cpp:1134:13 > #18 0x2f2c7a5 in = llvm::lto::LTO::run(std::__1::function = > (unsigned int)>, = std::__1::function = > (unsigned int)> (unsigned int, llvm::StringRef)>) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTO.cpp:1033:18 > #19 0x25aa570 in lld::elf::BitcodeCompiler::compile() = /usr/main-src/contrib/llvm-project/lld/ELF/LTO.cpp:316:24 > #20 0x2382c4a in void = lld::elf::LinkerDriver::compileBitcodeFiles >() = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:1986:31 > #21 0x22fe9c9 in void = lld::elf::LinkerDriver::link >(llvm::opt::InputArgList&) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:2321:3 > #22 0x22db283 in = lld::elf::LinkerDriver::linkerMain(llvm::ArrayRef) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:564:7 > #23 0x22d9f15 in lld::elf::link(llvm::ArrayRef, bool, = llvm::raw_ostream&, llvm::raw_ostream&) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:122:11 > #24 0x2b28651 in lldMain(int, char const**, llvm::raw_ostream&, = llvm::raw_ostream&, bool) = /usr/main-src/contrib/llvm-project/lld/tools/lld/lld.cpp:146:11 > #25 0x2b28073 in main = /usr/main-src/contrib/llvm-project/lld/tools/lld/lld.cpp:211:12 >=20 > 0x621002402688 is located 3464 bytes inside of 4096-byte region = [0x621002401900,0x621002402900) > allocated by thread T0 here: > #0 0x21adead in operator new(unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_new_delete.cp= p:95:3 > #1 0x2218a27 in Allocate = /usr/main-src/contrib/llvm-project/llvm/include/llvm/Support/AllocatorBase= .h:85:12 > #2 0x2218a27 in llvm::BumpPtrAllocatorImpl::StartNewSlab() = /usr/main-src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:3= 35:21 > #3 0x221873e in llvm::BumpPtrAllocatorImpl::Allocate(unsigned long, llvm::Align) = /usr/main-src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:1= 90:5 > #4 0x33e695a in Allocate = /usr/main-src/contrib/llvm-project/llvm/include/llvm/Support/Allocator.h:2= 04:12 > #5 0x33e695a in = allocate > = /usr/main-src/contrib/llvm-project/llvm/include/llvm/Support/ArrayRecycler= .h:130:38 > #6 0x33e695a in allocateOperandArray = /usr/main-src/contrib/llvm-project/llvm/include/llvm/CodeGen/MachineFuncti= on.h:960:28 > #7 0x33e695a in = llvm::MachineInstr::MachineInstr(llvm::MachineFunction&, = llvm::MCInstrDesc const&, llvm::DebugLoc, bool) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/MachineInstr.cpp:127:1= 9 > #8 0x33d4f9e in = llvm::MachineFunction::CreateMachineInstr(llvm::MCInstrDesc const&, = llvm::DebugLoc const&, bool) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunction.cpp:35= 2:7 > #9 0x39baa6d in BuildMI = /usr/main-src/contrib/llvm-project/llvm/include/llvm/CodeGen/MachineInstrB= uilder.h:349:25 > #10 0x39baa6d in llvm::InstrEmitter::EmitSpecialNode(llvm::SDNode*, = bool, bool, llvm::DenseMap, = llvm::detail::DenseMapPair >&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/InstrEmit= ter.cpp:1165:5 > #11 0x39b2e35 in EmitNode = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/InstrEmit= ter.h:145:7 > #12 0x39b2e35 in = llvm::ScheduleDAGSDNodes::EmitSchedule(llvm::MachineInstrBundleIterator&)::$_1::operator()(llvm::SDNode*, bool, bool, = llvm::DenseMap, = llvm::detail::DenseMapPair >&) const = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/ScheduleD= AGSDNodes.cpp:872:13 > #13 0x39b248f in = llvm::ScheduleDAGSDNodes::EmitSchedule(llvm::MachineInstrBundleIterator&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/ScheduleD= AGSDNodes.cpp:936:22 > #14 0x399c06e in llvm::SelectionDAGISel::CodeGenAndEmitDAG() = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/Selection= DAGISel.cpp:1006:42 > #15 0x399b447 in = llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/Selection= DAGISel.cpp:1622:7 > #16 0x3998efd in = llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/Selection= DAGISel.cpp:509:3 > #17 0x41c35a5 in (anonymous = namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) = /usr/main-src/contrib/llvm-project/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp= :193:25 > #18 0x33ce97d in = llvm::MachineFunctionPass::runOnFunction(llvm::Function&) = /usr/main-src/contrib/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cp= p:72:13 > #19 0x2ed4382 in = llvm::FPPassManager::runOnFunction(llvm::Function&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1439:= 27 > #20 0x2eda342 in llvm::FPPassManager::runOnModule(llvm::Module&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1485:= 16 > #21 0x2ed4a08 in runOnModule = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1554:= 27 > #22 0x2ed4a08 in llvm::legacy::PassManagerImpl::run(llvm::Module&) = /usr/main-src/contrib/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:542:4= 4 > #23 0x2fbb8d8 in codegen(llvm::lto::Config const&, = llvm::TargetMachine*, = std::__1::function > (unsigned = int)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex const&) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTOBackend.cpp:416:17 > #24 0x2fbab37 in llvm::lto::backend(llvm::lto::Config const&, = std::__1::function > (unsigned = int)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex&) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTOBackend.cpp:515:5 > #25 0x2f2d3db in = llvm::lto::LTO::runRegularLTO(std::__1::function > (unsigned = int)>) /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTO.cpp:1134:13 > #26 0x2f2c7a5 in = llvm::lto::LTO::run(std::__1::function = > (unsigned int)>, = std::__1::function = > (unsigned int)> (unsigned int, llvm::StringRef)>) = /usr/main-src/contrib/llvm-project/llvm/lib/LTO/LTO.cpp:1033:18 > #27 0x25aa570 in lld::elf::BitcodeCompiler::compile() = /usr/main-src/contrib/llvm-project/lld/ELF/LTO.cpp:316:24 > #28 0x2382c4a in void = lld::elf::LinkerDriver::compileBitcodeFiles >() = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:1986:31 > #29 0x22fe9c9 in void = lld::elf::LinkerDriver::link >(llvm::opt::InputArgList&) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:2321:3 > #30 0x22db283 in = lld::elf::LinkerDriver::linkerMain(llvm::ArrayRef) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:564:7 > #31 0x22d9f15 in lld::elf::link(llvm::ArrayRef, bool, = llvm::raw_ostream&, llvm::raw_ostream&) = /usr/main-src/contrib/llvm-project/lld/ELF/Driver.cpp:122:11 > #32 0x2b28651 in lldMain(int, char const**, llvm::raw_ostream&, = llvm::raw_ostream&, bool) = /usr/main-src/contrib/llvm-project/lld/tools/lld/lld.cpp:146:11 > #33 0x2b28073 in main = /usr/main-src/contrib/llvm-project/lld/tools/lld/lld.cpp:211:12 > #34 0x212ea5f in _start /usr/main-src/lib/csu/amd64/crt1_c.c:73:7 > #35 0x805007007 () >=20 > SUMMARY: AddressSanitizer: use-after-poison = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:827:5 in memcpy > Shadow bytes around the buggy address: > 0x4c4200480480: f7 f7 f7 f7 f7 f7 00 00 00 00 00 00 00 00 00 00 > 0x4c4200480490: 00 00 00 00 00 00 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 > 0x4c42004804a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4c42004804b0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 00 00 00 00 00 00 > 0x4c42004804c0: 00 00 00 00 00 00 00 00 00 00 f7 f7 f7 f7 f7 f7 > =3D>0x4c42004804d0: f7[f7]f7 f7 00 00 00 00 00 00 00 00 00 00 00 00 > 0x4c42004804e0: 00 00 00 00 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 00 00 > 0x4c42004804f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f7 f7 > 0x4c4200480500: f7 f7 f7 f7 f7 f7 f7 f7 00 00 00 00 00 00 00 00 > 0x4c4200480510: 00 00 00 00 00 00 00 00 f7 f7 f7 f7 f7 f7 f7 f7 > 0x4c4200480520: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07=20 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > =3D=3D48532=3D=3DABORTING > clang++: error: linker command failed with exit code 1 (use -v to see = invocation) Additional context: use of allow_user_poisoning=3D0 in ASAN_OPTIONS was enough of an addition for lld to finish in my context. > For reference: >=20 > The context is a used-for-chroot installation of a WITH_ASAN=3D = WITH_UBSAN=3D > build world. >=20 > # uname -apKU > FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #30 > main-n252475-e76c0108990b-dirty: Sat Jan 15 21:18:14 PST 2022 > = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG > amd64 amd64 1400047 1400047 >=20 > # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ > branch: main > merge-base: e76c0108990b52a25f548cba4c0f1b8db59c6b8b > merge-base: CommitDate: 2022-01-16 00:32:36 +0000 > e76c0108990b (HEAD -> main, freebsd/main, freebsd/HEAD) Fix inverse = sleep logic in buf_daemon(). > n252475 (--first-parent --count for merge-base) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 19 04:42:43 2022 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 183FD1962648; Wed, 19 Jan 2022 04:42:53 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdtL412fGz3rfV; Wed, 19 Jan 2022 04:42:52 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 20J4giPE093655 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 18 Jan 2022 20:42:44 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 20J4ghhl093654; Tue, 18 Jan 2022 20:42:43 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Tue, 18 Jan 2022 20:42:43 -0800 From: Gleb Smirnoff To: dev-commits-src-main@freebsd.org, current@freebsd.org Cc: bz@freebsd.org, zec@freebsd.org Subject: Re: netinet & netpfil tests failing Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JdtL412fGz3rfV X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [0.87 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_SHORT(0.97)[0.965]; MLMMJ_DEST(0.00)[dev-commits-src-main,current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jan 17, 2022 at 06:07:43PM -0800, Gleb Smirnoff wrote: T> * Reclaim the memory from pcb zone(s), when jail is destroyed, returning back T> the old behaviour that with test suites 'jail -r' is always synchronous. T> Some prerequisites for this approach are here: https://reviews.freebsd.org/D33868 T> * Protect jails with epoch, bypass the cred pointer in inpcb and in the lookup T> check inp->inp_prison->pr_foo. After that the crfree() can be moved back to the T> immediate inpcb free procedure. Mark has a quick & dirty proof of concept for T> this approach. T> * In the test suite destroy the interface from the jail: T> 'jexec jname ifconfig ${ifname} destroy'. T> T> I'd like to add a few words on the last option. To me it seems most elegant as we T> are improving the test suite instead of changing kernel to meet demands of the suite. T> However, it doesn't work :( Why? Why does 'jexec jname ifconfig epair0b destroy' or T> 'jexec jname ifconfig lo1 destroy' returns ENXIO? Because the interface was created T> within vnet0 and is linked on vnet0 cloner's list. To repeat: epair0b ifnet is linked T> to the jail's list of network interfaces, but it linked on vnet0 list of epair(4) T> ifcloner. Likewise, some lo4 interface would also be in the jail list of interfaces, T> but on vnet0 if_loop cloner. This makes it impossible to destroy such interface from T> inside the jail. Neither it is possible to destroy it from the outside, for obvious T> reasons. There are more side effects about this. For example the only reason why we T> can't create an interface with the same name inside a jail using its cloner list is T> call to ifunit() in the beginning of if_clone_createif(). This definitely is a part T> of design, since if_clone_create()/if_clone_destroy() would lookup vnet0 cloner list T> in case if interface is not found on the current vnet list. T> T> To put it short, it is yet another problem created by if_vmove :( Not an easy one T> to fix and makes the third approach to the problem complicated. Looking more into the problem, I've found pieces of code that confirm that the clone behavior of staying at home vnet cloner when vmoved is known and seems to be part of design. I created a patch to better workaround this fact and be able to properly destroy a once vmove'd clone: https://reviews.freebsd.org/D33942 Followed by earlier suggested change to the test suite: https://reviews.freebsd.org/D33943 With these two patches in place I have all of the test suite fixed. Waiting for your reviews to push them in. -- Gleb Smirnoff From nobody Wed Jan 19 04:47:56 2022 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 DD35119669D6 for ; Wed, 19 Jan 2022 04:48:09 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdtS83sGCz3tjH for ; Wed, 19 Jan 2022 04:48:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642567681; bh=0ALcyfHHE8OHzXxjTTaqD5TsqFqANjckk9DYWSsJWIM=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Tr3tjBozFa/68ojFvKhVs5EC3ssD2Eoqq8d0ArTQ6wxPQHGrE8uSmm+lUNwZwT3i/jHRG5gue/r1qYWUBooBAp7dG9rzhbFEoKjln3RWTfE5cnKCvkU12VvYm5WqRs86ctYhGaMfuKE2nys7SRmf7/I8YYR+R70tc1v9Gm4Q6x4N099853kUvnENNO60ZSMKx5RUciXQCATO0seqqJeXVyINHqCeKtRPHU3smXZGij+Wkw4EGK0g7UQzNhqR0rgLMzn8gC3QJUppWYQ0TgYGUZMIVtoKzgnN7NwdN+ezrl3BO2fQE5cH+QcRUbt6wN11XAiZkOO66IzTpTvP/lDX3w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642567681; bh=60b4lvBESP3g4gfb0B4qX9AbqTw2ROT2zGMegrVHj34=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ddP3cYHz4iie57CvTw/i2lZEkqCsGWFPVRG0ytx9+hkDCuTkt+NfmdI7okH6nS9Vou3zfFMtHyb29KSKOw1tELTdqOfslY6QmwfysO7UAREGjPTbqawXot1k4VX1J1Ms8gpcBtRVzRL9HsdjIQa/q8mVI6ish8qMoFMzTi2bSz07xrtHLwGrOdg9mQr+o7eAFTmmC7ffOZO0dIat0Uz7VEchzN5DCM2D+EtV87zcPpWp5tf2cokluvkBl10QbGAksI2Ft1RXznAsn0CELHwpZidrU65HXjDy3m06Q+J7dpSO4xN57pj2F3wNMM2rqCWBcOETVW0zrgYJQw084OdpoQ== X-YMail-OSG: AqyeNzoVM1nFtisJvj5nnc_GIZQEDYGu7f4oQRFDmDQeU4wbTTaspiLDi6btFuv TsrlqLKzadTJPFS0DgpwiiiHKKJG57QxtX266ClVUom4klt8C5c6CJ6t.uB62rnLhdpGbNrgJtoe cOubXiBtDmBqwJ0wKPMrTkenWQ477IaHhDM3NdjQFtcjKTnSfHt9dxoWlu6uWKGS8OICTJrrpoCm aDQUfqD8vy4YQAsxREyqRux9k6_yitxf0q_XgW5l29T2sgnj7puornbghy9ggWl3v8A0PGapBS_2 H8qgAhPBlMgF7frUkD1QZAy4ViPZM9ufbyTlMkgB96HJRJDPBUfywU9ypjke.MLqYkNIDBvdiMgV LnzWG3Y3se0URivBkJMvW4z1lCa7QFFSitMeZ72UuqTlLexUhKRG9Ka4Yghjt7kZ4kbFN8sgPsO_ ec3BAacQQWIdo5TBgfZ9mcp5jJ28_aItKug7ooa75Kgkm7A70jRZvGk7VAPdx__9Ze2Gcosq9.g. _Vz8.y4LfOhWJk8c_R_uwMD9mqVGtIvQpmct9dqC0R1AUSZEziSeVgC84IhfOf61NKGnAiFTlPpI VO4AnbhsrPAa62UvQUjgZAsCQnCkzHQgq9DNO7WIQlqFGNvqQZyzKL8F3Tz9fYbxKO2Sxis73cTd YGiTmF67RvfodjiP89En4ehBxlZptQ74YqDlYyiRQ0OP2BtvvY15XbnfhP5YSud3MAh1xC4kCYQA 8nnB9eJiOSfzuzEsSKmWY2SHmkHwGPtO3OmVMHnNCOlkQvvjIze3_k80VjVNjMsl9S50CEbkwWFR BLO__EV2xAn1l7ma5GhaY0ulZf1YFxTl6INwA_tAu3v7lPLYqn0OgUs3cyH06AKjWMFyPFskzpj9 tChgP6in1TXMtDmxHBlZOfhsJQ3eVMevwuiOFvwXTtuStU8gK3D.A01xyqRwJlVAW34pl4Qsr_JK 4xxHH9HIWzGTQZaa6Gk1jsC6W5FvcvGL33f__cHR1annRWRGhyRqWS_kAX9ICzp6NxjjLLhW2fVx pqVAyMEj_D9Po.JzFC7XKGlZmP9JfUSIeajqzg8p.iZptYBwl.YNawIJEQMxgHWnlv2wASFaAvvZ 1wjm_MQgbEX2MwauZ5AQjA_nG94v2LO0Dty2e_IFXnwuc6yF89_tIeV.Iq9t5y4sgtAJTvy.kCTK cCojQb8GXbrKSj_kPFUD1QIkLBS77Mqz9Y.ENtyjiSzpkGyyGtdTEKF.FJe.lII59Y92lXkaoWTE tI5IPsEXZJ5Uf8txzW5rmr4UgxfSMsTXXr7BxLHK5rLSSf5TfSB78jfBXJG8gyiwQ4L3zg_u2sGu KB77yRTNCpn6hya.DUAgAegqPEVBKGr.xKlT4M3jf3rlNo4Kbb8xkcSLSeM94od9_ogA2QXg8P7u EXSLY_EDflAh42HEJa7VkqbBS8.dQEy87L0q6_oF2PK6BC8ywF9FjMH5WWxNrcRZlVef1Fj6qmt3 5Nt9tx1elKWrLPS0VBREjOVYTDeIL3UJTpffFWu4i9Sbq83_yYZ.x7_l6b72TNBPCZW1k1rCpJQy xyrZHvFeB.RJIVWoI0hIhVAKxTOHphBJJ2F9slErvXgF9DLeXE2v53FX0SH.ii4epPtBwjcbPbwa gUqf_wTJHuahQUkcThISqckZfRrouUHqU.iYwFAA9.QD.Z5v2Sui2hNfICog2fDzeufeeyo6AkcQ PIXp_lFDWlanUfPx1s8pmoZmtqxZmxYApDJT9I9vA3yK1EcBLoUGuvsQb5FajSRuxCD.JG9l9UiB EVtpl71W5okWSjJ3yKQB2rVw9wXX822M3QzbOsrT_o0Gzi9n8QzFJxCTIBYcbU4ryo8PMFSrzzBV 0ggKuehDocgifYfIIcyciT7WFBVaO.1ZEvyxa2dAZW61XXmKlJL0d21DN8G_Yq7yNE7b7JXUS50m jSQClMlQTNK_1MV.tXqNJOA7yKAt7bP8BF_ptPGSfHuboDlVXRZq697.Z.3NSBj9qL.RwjajsuUN 6S9ehCmoSRepGQ0CPu9YAWtjixKHkbaP6wDZukjjVaiBQr_qdvHOVZvbVvXv8_0bDutzZd6lcM2D a29C53XH5rkk1e9Of_cjScdrV5VGzpNXNb31FrUz7bVmjEJnVC12Ydwqyl3.lTV6d1douXZx1KqH QRmNIcHjZANNasqDp_eoWa.0PtjUcS7s7KLVvbCc2N1mPesUH9beMVx7azW8b7RdIWW0_buW7Qjg uGY1lHt_Z4slt5vi_.oROMvoN7id2Ga2RFp2k2AK.n9rYa.LHQYm73KvEcNHKUKQ7GsE1fPhR X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Jan 2022 04:48:01 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7399a027e50863b3d793abc1ec536bb5; Wed, 19 Jan 2022 04:47:58 +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 14.0 \(3654.120.0.1.13\)) Subject: UBSAN report for libc: __ldtoa can set up gdtoa to do a "Left shift of negative value -18" Message-Id: Date: Tue, 18 Jan 2022 20:47:56 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4JdtS83sGCz3tjH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Tr3tjBoz; 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 X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Using lldb to look some at the internals for: gdtoa_gdtoa.c:254:32: runtime error: left shift of negative value -18 . . . Process 48846 stopped * thread #1, name =3D 'acpphint_kernels', stop reason =3D Invalid shift = base frame #0: 0x000000000032b3c0 = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`::__u= bsan_on_report() at ubsan_monitor.cpp:39 36 } 37 =09 38 SANITIZER_WEAK_DEFAULT_IMPL -> 39 void __ubsan::__ubsan_on_report(void) {} 40 =09 41 void __ubsan::__ubsan_get_current_report_data(const char = **OutIssueKind, 42 const char = **OutMessage, (lldb) bt * thread #1, name =3D 'acpphint_kernels', stop reason =3D Invalid shift = base * frame #0: 0x000000000032b3c0 = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`::__u= bsan_on_report() at ubsan_monitor.cpp:39 frame #1: 0x0000000000325b81 = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`__ubs= an::Diag::~Diag(this=3D0x00007fffffffb960) at ubsan_diag.cpp:354:29 frame #2: 0x0000000000328819 = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`handl= eShiftOutOfBoundsImpl(Data=3D0x0000000808eb05a0, LHS=3D, = RHS=3D, Opts=3D(FromUnrecoverableHandler =3D false, pc =3D = 34505352983, bp =3D 140737488337968)) at ubsan_diag.h:0:9 frame #3: 0x000000000032832a = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`::__u= bsan_handle_shift_out_of_bounds(Data=3D, LHS=3D,= RHS=3D) at ubsan_handlers.cpp:370:3 frame #4: 0x0000000808ade717 libc.so.7`__gdtoa(fpi=3D, = be=3D-81, bits=3D, kindp=3D0x00007fffffffbe80, = mode=3D, ndigits=3D, decpt=3D, = rve=3D) at gdtoa_gdtoa.c:254:32 frame #5: 0x0000000808ad6e43 libc.so.7`__ldtoa(ld=3D, = mode=3D, ndigits=3D, decpt=3D, = sign=3D, rve=3D) at _ldtoa.c:106:8 frame #6: 0x000000080899e0f7 libc.so.7`__vfprintf(fp=3D, = locale=3D, fmt0=3D, ap=3D) at = vfprintf.c:718:9 frame #7: 0x00000008089cab43 = libc.so.7`vsnprintf_l(str=3D, n=3D29, locale=3D,= fmt=3D, ap=3D) at vsnprintf.c:80:8 frame #8: 0x00000000002c6e84 = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`::__i= nterceptor_vsnprintf_l(str=3D"\b(j", size=3D30, loc=3D0x0000000000000000, = format=3D"%.*Lg", ap=3D0x00007fffffffd2b0) at = sanitizer_common_interceptors.inc:1676:1 frame #9: 0x00000000002c70c2 = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`::__i= nterceptor_snprintf_l(str=3D"\b(j", size=3D30, loc=3D0x0000000000000000, = format=3D"%.*Lg") at sanitizer_common_interceptors.inc:1680:1 frame #10: 0x000000080171855f libc++.so.1`std::__1::num_put > = >::do_put(this=3D, __s=3Dstd::__1::num_put > = >::iter_type @ 0x00007fffffffd320, __iob=3D0x0000000000db2040, __fl=3D' = ', __v=3D0.000006883) const at locale:1631:16 frame #11: 0x0000000801706129 = libc++.so.1`std::__1::basic_ostream = >::operator<<(long double) [inlined] std::__1::num_put > = >::put(this=3D0x0000000801758990, __s=3Dstd::__1::num_put > = >::iter_type @ r15, __iob=3D0x0000000000db2040, __v=3D) = const at locale:1325:16 frame #12: 0x000000080170610d = libc++.so.1`std::__1::basic_ostream = >::operator<<(this=3D0x0000000000db2040, __n=3D0.000006883) at = ostream:666:21 frame #13: 0x0000000000451ccb = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`void = report_survey(clock_info=3D) at = acpphint_kernelsurveyors_main.cpp:118:17 frame #14: 0x0000000000450ad1 = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`main(= argc=3D, argv=3D) at = acpphint_kernelsurveyors_main.cpp:308:5 frame #15: 0x00000000002a9170 = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`_star= t(ap=3D, cleanup=3D) at crt1_c.c:73:7 (lldb) thread info -s thread #1: tid =3D 101028, 0x000000000032b3c0 = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`::__u= bsan_on_report() at ubsan_monitor.cpp:39, name =3D 'acpphint_kernels', = stop reason =3D Invalid shift base { "col": 32, "description": "invalid-shift-base", "filename": "gdtoa_gdtoa.c", "instrumentation_class": "UndefinedBehaviorSanitizer", "line": 254, "memory_address": 0, "summary": "Left shift of negative value -18", "tid": 101028, "trace": [ 34505352982, 34505322050, 34504040694, 34504223554, 34383955294, 34383880488, 34383880460 ] } (lldb) up 4 frame #4: 0x0000000808ade717 libc.so.7`__gdtoa(fpi=3D, = be=3D-81, bits=3D, kindp=3D0x00007fffffffbe80, = mode=3D, ndigits=3D, decpt=3D, = rve=3D) at gdtoa_gdtoa.c:254:32 251 dval(&d) *=3D 1 << j1; 252 word0(&d) +=3D j << Exp_shift - 2 & Exp_mask; 253 #else -> 254 word0(&d) +=3D (be + bbits - 1) << Exp_shift; 255 #endif 256 if (k >=3D 0 && k <=3D Ten_pmax) { 257 if (dval(&d) < tens[k]) (lldb) up frame #5: 0x0000000808ad6e43 libc.so.7`__ldtoa(ld=3D, = mode=3D, ndigits=3D, decpt=3D, = sign=3D, rve=3D) at _ldtoa.c:106:8 103 abort(); 104 } 105 =09 -> 106 ret =3D gdtoa(&fpi, be, vbits, &kind, mode, ndigits, = decpt, rve); 107 if (*decpt =3D=3D -32768) 108 *decpt =3D INT_MAX; 109 return ret; (lldb) up frame #6: 0x000000080899e0f7 libc.so.7`__vfprintf(fp=3D, = locale=3D, fmt0=3D, ap=3D) at = vfprintf.c:718:9 715 if (flags & LONGDBL) { 716 fparg.ldbl =3D GETARG(long = double); 717 dtoaresult =3D cp =3D -> 718 __ldtoa(&fparg.ldbl, expchar = ? 2 : 3, prec, 719 &expt, &signflag, &dtoaend); 720 } else { 721 fparg.dbl =3D GETARG(double); (lldb) up frame #7: 0x00000008089cab43 libc.so.7`vsnprintf_l(str=3D, = n=3D29, locale=3D, fmt=3D, ap=3D) = at vsnprintf.c:80:8 77 f._flags =3D __SWR | __SSTR; 78 f._bf._base =3D f._p =3D (unsigned char *)str; 79 f._bf._size =3D f._w =3D n; -> 80 ret =3D __vfprintf(&f, locale, fmt, ap); 81 if (on > 0) 82 *f._p =3D '\0'; 83 return (ret); (lldb) up frame #8: 0x00000000002c6e84 = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`::__i= nterceptor_vsnprintf_l(str=3D"\b(j", size=3D30, loc=3D0x0000000000000000, = format=3D"%.*Lg", ap=3D0x00007fffffffd2b0) at = sanitizer_common_interceptors.inc:1676:1 1673 #if SANITIZER_INTERCEPT_PRINTF_L 1674 INTERCEPTOR(int, vsnprintf_l, char *str, SIZE_T size, void *loc, 1675 const char *format, va_list ap) -> 1676 VSNPRINTF_INTERCEPTOR_IMPL(vsnprintf_l, str, size, loc, format, = ap) 1677=09 1678 INTERCEPTOR(int, snprintf_l, char *str, SIZE_T size, void *loc, 1679 const char *format, ...) (lldb) up frame #9: 0x00000000002c70c2 = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`::__i= nterceptor_snprintf_l(str=3D"\b(j", size=3D30, loc=3D0x0000000000000000, = format=3D"%.*Lg") at sanitizer_common_interceptors.inc:1680:1 1677=09 1678 INTERCEPTOR(int, snprintf_l, char *str, SIZE_T size, void *loc, 1679 const char *format, ...) -> 1680 FORMAT_INTERCEPTOR_IMPL(snprintf_l, vsnprintf_l, str, size, loc, = format) 1681 #endif // SANITIZER_INTERCEPT_PRINTF_L 1682=09 1683 INTERCEPTOR(int, vsprintf, char *str, const char *format, = va_list ap) (lldb) up frame #10: 0x000000080171855f libc++.so.1`std::__1::num_put > = >::do_put(this=3D, __s=3Dstd::__1::num_put > = >::iter_type @ 0x00007fffffffd320, __iob=3D0x0000000000db2040, __fl=3D' = ', __v=3D0.000006883) const at locale:1631:16 1628 char* __nb =3D __nar; 1629 int __nc; 1630 if (__specify_precision) -> 1631 __nc =3D __libcpp_snprintf_l(__nb, __nbuf, = _LIBCPP_GET_C_LOCALE, __fmt, 1632 (int)__iob.precision(), __v); 1633 else 1634 __nc =3D __libcpp_snprintf_l(__nb, __nbuf, = _LIBCPP_GET_C_LOCALE, __fmt, __v); (lldb) up frame #11: 0x0000000801706129 libc++.so.1`std::__1::basic_ostream >::operator<<(long double) [inlined] = std::__1::num_put > >::put(this=3D0x0000000801758990, = __s=3Dstd::__1::num_put > >::iter_type @ r15, = __iob=3D0x0000000000db2040, __v=3D) const at locale:1325:16 1322 iter_type put(iter_type __s, ios_base& __iob, char_type = __fl, 1323 long double __v) const 1324 { -> 1325 return do_put(__s, __iob, __fl, __v); 1326 } 1327=09 1328 _LIBCPP_INLINE_VISIBILITY (lldb) up frame #12: 0x000000080170610d libc++.so.1`std::__1::basic_ostream >::operator<<(this=3D0x0000000000db2040, = __n=3D0.000006883) at ostream:666:21 663 { 664 typedef num_put > _Fp; 665 const _Fp& __f =3D use_facet<_Fp>(this->getloc()); -> 666 if (__f.put(*this, *this, this->fill(), = __n).failed()) 667 this->setstate(ios_base::badbit | = ios_base::failbit); 668 } 669 #ifndef _LIBCPP_NO_EXCEPTIONS (lldb) up frame #13: 0x0000000000451ccb = acpphint_kernelsurveyors_main-ThreadRipper1950X-131072MiB-threads_32-LP64-= FreeBSD_main_n247756_348c41d1815d_64bit-clang++_13_O3lto-libc++-xSAN`void = report_survey(clock_info=3D) at = acpphint_kernelsurveyors_main.cpp:118:17 115 << = ks_serial_result.krr.kernel_result.ixes_errs_used_each 116 << "\n" 117 << "krr.total_sec_for_laps_for_median: " -> 118 << = ks_serial_result.krr.total_sec_for_laps_for_median.count() 119 << "\n" 120 << "krr.tscout(): " 121 << ks_serial_result.tscout().count() << "\n" So simply using << style output resulted in the oddity. Turns out that be (which ends up as be=3D-81 according to frame 4's = details, if accurate) is calculated in __ldtoa via: 48 char * 49 __ldtoa(long double *ld, int mode, int ndigits, int *decpt, int = *sign, 50 char **rve) 51 { . . . 65 union IEEEl2bits u; . . . 69 u.e =3D *ld; . . . 79 be =3D u.bits.exp - (LDBL_MAX_EXP - 1) - (LDBL_MANT_DIG = - 1); . . . 106 ret =3D gdtoa(&fpi, be, vbits, &kind, mode, ndigits, = decpt, rve); . . . gdtoa then does (various line numbers & some white space omitted): . . . int bbits, . . . . . . b =3D bitstob(bits, nbits =3D fpi->nbits, &bbits); be0 =3D be; if ( (i =3D trailz(b)) !=3D0) { rshift(b, i); be +=3D i; bbits -=3D i; } . . . -> 254 word0(&d) +=3D (be + bbits - 1) << Exp_shift; So, by the UBSAN report: be + bbits - 1 =3D=3D -18 If be=3D=3D-81, then bbits=3D=3D64 at the time & place. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 19 05:04:59 2022 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 E6C2C1952304 for ; Wed, 19 Jan 2022 05:05:02 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jdtqf1ZLCz4WVq; Wed, 19 Jan 2022 05:05:02 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qk1-x731.google.com with SMTP id c190so1604912qkg.9; Tue, 18 Jan 2022 21:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=ixIGH5vhH18ZjRtfae6PqV/VPZ9L6ASsi1FRvvwQe14=; b=pWZCgnlD796G9Uy5GtOaN1yhED+U5dvna3B4aR+t4+2ijLq5xrCjJ4XQuDiUAAHowD 8bdM/D6dh4wPM8eVfDC5+V1dy6AxQ41Z31ISukXuojwj1cvwdX/rbzasfzkPkVKyFzGz 5rM7n4r0+N3a52/94dvkYm/fnw/2BrECfGB7V2DH4aUYHYAjKCLZtu9oQkl/B9SunV6d 35+I318tzgh1WXnxgd9JTLEX9KpIUusYwefa4yzFcFxw8ccSm1O31mYtG1j6XRg9PRG8 IM0KMTwu5AGViWdvxi5S2dhgjesyz4sfOASd16KMzH8nGEGx7tgfZnRMP3NKBpX7Bmyh hnbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=ixIGH5vhH18ZjRtfae6PqV/VPZ9L6ASsi1FRvvwQe14=; b=lZ+s/7ZaP3ArSGLOUpVUUy6wM3+8PbRT5qVxq2YI1rsg6/49CJWRpUVG7nBXAnIDzI 6usaCkP7ls4Y44xFWQdrfJnZceuG6djEmbhh+IbabYsyOjpWIDgLZfeqAU6u7/I4dgJ8 yQt8Pi0UsvD9mmszEqXxde05XLBDUHns8RvcLLN40VHxQygi6UGS86EjuKvgSRjqIgX6 uJNagV6MpKf3pC4bna/q0RRn3qdyZEEUKsctNyTcINYuW7WkKg/wQsqni5GFLmpIU5NV T0oqKqdgtSPpRYb4ciN7pxTqfL4iHJQOqSq6OnB820kx01mf+eNpG1+nucDTGYbjqe3P 3T7A== X-Gm-Message-State: AOAM530U80tfWB3NBCHrWU5D/rEaWyhRhBT44owpEEIOfgZSQlpxxWtS ecCZuoIPockXIz28h+rHQVqsguXTy20= X-Google-Smtp-Source: ABdhPJwaPQF2N/3GMMz41NslQLjLxcUm9mKiZ19ktJMOGAk6N7GqnB1Bgal7mBndXTLND0iqvaGB5Q== X-Received: by 2002:a05:620a:28d4:: with SMTP id l20mr472309qkp.630.1642568701146; Tue, 18 Jan 2022 21:05:01 -0800 (PST) Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id f14sm1001163qtf.81.2022.01.18.21.05.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jan 2022 21:05:00 -0800 (PST) Message-ID: <9a8bb084-394c-6948-1e57-ff9732b93532@FreeBSD.org> Date: Wed, 19 Jan 2022 00:04:59 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: fspacectl meets DIOCGDELETEE Content-Language: en-US To: Alan Somers , FreeBSD CURRENT References: From: Alexander Motin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Jdtqf1ZLCz4WVq X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=pWZCgnlD; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::731 as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-0.84 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::731:from]; NEURAL_HAM_SHORT(-0.64)[-0.638]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Hi Alan, On 17.01.2022 23:52, Alan Somers wrote: > fspacectl(2) does for regular files the same thing that DIOCGDELETE > does for GEOM devices. The only differences are that DIOCGDELETE > requires the operation to be block-aligned, and if interrupted > DIOCGDELETE doesn't give feedback about partial progress. Can we > connect the two? That would allow a user to free space with a single > API for both files and devices. It would require: > > * Adding a d_fspacectl_t member to struct cdevsw > * Implementing d_fspacectl_t for g_dev_cdevsw by using DIOCGDELETE > * Implementing .fo_fspacectl for devfs > * Optionally implementing d_fspacectl on other device types, like zvols. This reminded me that we also have the same problem with DIOCGFLUSH. Unlike regular files cache flush can be sent through devfs only with ioctl(), not fsync()/fdatasync(). -- Alexander Motin From nobody Wed Jan 19 20:28:56 2022 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 9D903195197D; Wed, 19 Jan 2022 20:29:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660043.outbound.protection.outlook.com [40.107.66.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JfHKq40qDz3lyb; Wed, 19 Jan 2022 20:29:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lrTtoMyD///9HtUPy8HxvPjXm2TSHMJONMo8RdSjjWW7KJr7d2Nhx6pI6qeHsJju6sz4SiQoZkIzHCfSuykumJFvZn0UfI611BnfCC3fFwecHSDF9F6H57S1vz+85/i7kkk87JEf4pyaNS/tIy+BSLajEDboviH/KjqhGW9ZUPMYDfy7wjKvPxrTIA8wXAHWcGVol4zcGmL+Lm4SDsILnmWRfMku2SyWJCyh9YddknXw1CWR9YdRHeRwphLMoR5OlaKB7bbmhwvTh0y0pgQ0TbbHBvBI4ZxnUrF7xJEzZm3IwFgcscccDCsbi6f2zYqswGL0a19/bj3CyLcbqs57+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yw3qhd8KUBkXrwINUyGUKW+XTFLplw4qQ1JSPpNF2Z4=; b=hXDpviwTAli5FIPEFbIxyfHmqCra0Q6iyO5tV9IDP/yXjElfiQAx522oEdzILoyoK/ryVJDKzjGYM9N7fsnHPToNJHYJYBuESQTCkJma70PN4MZEL01zQTCpDTO9mX0YyodizzKniQ6CFuYpG4396uhfv3LVMLIqAL307R/o71oo8MTFu4gFjGBYuePJc7mRJkN5da2y+lROn2Puz0RvECZVxgDTzLnuN955hfQHKJaUSedUAK82xZxkSRWIQC9R6PIKzIAxw1d2e5TObMP1hZbF1bcM3ap+c3HWH1LBCOrANM6BnVj0HDUnpQnLp3diG1tdNm4QiAfODuJJEANV3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yw3qhd8KUBkXrwINUyGUKW+XTFLplw4qQ1JSPpNF2Z4=; b=K628dLH6zrzxywm/Lt9IN3ZgsqRZMA8DMmw72mvlkqkuTVI6kTmOpVJqRJDuhKY7N8IgDu6Holhouol2IT2UZCauarl/U5BCWEviOkJiXn2+Jdl60IjGJ6Ekdox41Nvr4NEW5anDrJqGJaBKaGIaFF2H5x8DsbGk40/VFCZPpTpBlZdqFgK5x5J+8PxAMQZvSHoITxTZ3SON8ylVZs/IZ9Z8rax+tIbKQZohxXf3WWgj0ENDC2EqRLpo6R51JA2YLgVVslq8saiXyDndqFdeC1Mr5VNajLPlcAsFccL0AQEMjk1aG4+ietMeG/U8Pj6uUtIZ0TBUYSpMS8pas6Dz3Q== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB4388.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:9::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.7; Wed, 19 Jan 2022 20:28:56 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::c9d2:bf41:eeca:90aa]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::c9d2:bf41:eeca:90aa%5]) with mapi id 15.20.4888.014; Wed, 19 Jan 2022 20:28:56 +0000 From: Rick Macklem To: Miroslav Lachman <000.fbsd@quip.cz>, "freebsd-current@freebsd.org" , freebsd-stable CC: Yuri Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Topic: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Index: AQHXzvvFA1WWxQSLW0uUJGavCusr2KvuZUQAgABpl4WAAGcwgIBr+tlBgAGeWQCADnip0A== Date: Wed, 19 Jan 2022 20:28:56 +0000 Message-ID: References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz> <54704b99-7b89-76a4-0368-79bee391926d@quip.cz> In-Reply-To: <54704b99-7b89-76a4-0368-79bee391926d@quip.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: a8590312-cc43-dfa6-97f0-73ab8d71f4f8 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3a5395e5-6024-4057-e006-08d9db8a5144 x-ms-traffictypediagnostic: YQBPR0101MB4388:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: owEVrWjqhyI7t4sKdfQrd574fUimEQ2dMgtHk/OfAVhmo9ibnsuNd/dIXKpYAEfBFODDvglpcMJ8sdcmDeftFRwouOWG0S+67YFzy7uEANXHd7Q5LaRKcvqnh/oGc5ZymdanDwW776lI4DGjsyd0ebMoTw/hrpHOnOiz0YOcUBOP4LzL6lcQcPb81EKTLuXmgIuQPZCLf33t2dRXodyeTvs/XCzuAxja1Yq1tyeY87puYhFpXR4SJCg8llzyNE2elOSWb+3uUioyTFteWQOvLHG+oo5RspVcUp1sj4JSENxK9lz6y8RZX2wh3iKax1AuCecy3Xbrx73GeMUK/SgFOCYi1eqTD6O3JZGcFnKLRvEwXzoVt0qxDkaWtlTHu+jvRkeUBWLkr4rI7/UoOPyYWmIfWthQRl7Lb4fHx3QDz5WVysSODJ9g6SOqCGPfTifXPHhy+axPmDIcGV7T03bI2CRT4v/0ONgY+Wz0rii/zKzUhzIwIR4NNxAPWZkZzxjfUYxvWNo3D3yzgBXmOtCrVjVSw6QLlGcmiRVAUeD+zaC3rX0NYKoHyQmYLbwW9K7/Va0qKqkm5KrUqtCQVRGKViH4rH2GfKy+k2k6pBusCgiWX7OkZpLumjzPH89fEWFk5bLdpM2m1aU6UkHhN4gUsp02NQxa+28CeehwP+TpZRt8fGtnfWMidsqGyA3ttQN8+tXy1gdDwDsUsk83lNBy4Y20y6vVSOtVeZamnuSCk2QE+htNxy/g/ONEeSdmo9+mmO7PbSLuPRX/GG3pfcFUXJlRPo1wnDem8ZvkhrmfuHk= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(91956017)(76116006)(66476007)(5660300002)(52536014)(66446008)(64756008)(66946007)(8676002)(66556008)(186003)(38100700002)(122000001)(966005)(38070700005)(33656002)(83380400001)(55016003)(110136005)(53546011)(6506007)(9686003)(508600001)(2906002)(7696005)(8936002)(71200400001)(786003)(4326008)(316002)(86362001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?duRgS7yTs68p3MYRpDLzdhRL3+4kyAA2y6tl0TA2tIP47YN1Nh4Q/ZD9zDE5?= =?us-ascii?Q?PWaHpwN7BPH135h6V73hNtuTCWHFsdaHb48vRtTJ4tH03V6WMGZMveUzycnb?= =?us-ascii?Q?EvmRIrXP90EC6P6vmSL9Wv/qXbAxcLeeGmAuZ4YZ+NWMcREXNQ0UdmSd7qXO?= =?us-ascii?Q?l5G0+16iKLsShjeUL9bjZy6kbHYoBxLo72WTjTOCnqteXEqLvAA1RlCKrIAi?= =?us-ascii?Q?ZV/scrwn0N0j1lND/Fg7hKaSp5yGEtIxOGEM0zRWGA2fQglRozDGyq2odgc8?= =?us-ascii?Q?UtpNQoKQb7j5xNXFrsCfESbZG/J9aXlqw9Lz6jO/Ni1dgMh8nZGAGP0U+pTP?= =?us-ascii?Q?ljkoRLAgw1EQmb11Jm+39z+m9/RbCpaPbcme2mbWB9U9+X02LKTjVKDu/Ca1?= =?us-ascii?Q?hrE43oElH+i3cgahNUK68J5ZihEsGEIRdcC2mXMPRjBzaegAuns8k5JYaFEs?= =?us-ascii?Q?woj2CrJHxl8O256oSfl/6iOBJQPaAOsT6nPfWV9E4ToxHSTUW/IrF5WJ2Oaw?= =?us-ascii?Q?AEfKfgUtk3mjSQvpuwZB6zlLy5TH2ziG4aOtAKzLDuT1tvd+EILEYQ5P3LuK?= =?us-ascii?Q?AJem86+GN4/wGR1Qx2HZnMVFWozxFFf4022gpgX0NInmrs9cNfcHEXjpc+a+?= =?us-ascii?Q?hOasqxhE1y8PyBffEJKOAXUDjTQhHEWY8ppEJR4qz0zoQMwHFkfaWuumG0d9?= =?us-ascii?Q?2jIt9TB0N/e+ANZ2PLhaK8a6tZM1S9uHZJVmHEFkfYnAtx/tDvGTOFw+KIbt?= =?us-ascii?Q?K/ZbfaJDcabs9VBS/U8o35GQCrD5P5sMAGdAxzMPXFej2zKZkoD90Fs2BS+I?= =?us-ascii?Q?QK67zMdaZDDP2ftXwVcwbNXUDZA7ikQDAgYuQ4RdZ/1cLz61nrCWEMg8s5sI?= =?us-ascii?Q?zUgRUU1Ch8Zb9t+wXkzLHTWwcrIpPCtLOCEowh3W0zpPfjiHnT/lVaUwBrD+?= =?us-ascii?Q?wRYk21WQ7okjM6tLabAaZX++NDBGylXQHLZEHAjmYa27706drM3yDA1++kYA?= =?us-ascii?Q?nQKH+wCMC2HsLGUsPIhpJQMIwX92YuD4aJNT4a2uC8JyK9S6mqfLti5RmYGc?= =?us-ascii?Q?lRMIOHS6xcDuL0ppquazlaIgcl5v6ozzgkqgcvhsEFq9tpvuWQxc5E6jAcqs?= =?us-ascii?Q?QoJ4BIXBArXP7wDeCvNqQPBxvRm/AItg3O005j3Xc8TkSVEwbAuP5WVjMKI7?= =?us-ascii?Q?S/HvvK9l8ClgZOmEjXa9hYbkpn2UcfFXbsSFVNlsQH2FqZIi1WUOTMTDLPR4?= =?us-ascii?Q?JxZGzSKBHaHsGBdzjUGXViiJVMubMIQmo7YXy7EH81ikEm7hfrbjKKuF1hLH?= =?us-ascii?Q?4lRowF2NmVanewjiW9MrPlUXKceSU+jhOLfEsLI6NktF5IgYuZc7j0+Wv2Dk?= =?us-ascii?Q?4oXO+1JUR7N3EjPcx/TuO9DAcrh6a+RchoWKL2fpWDplwql3+8xjQ1KtMWHL?= =?us-ascii?Q?CcUFHxkOeqQ+H2Ow0LqDkAOJx6o9b3m7Y14aoJPRPNCKRA2BaYnAQ0XMXbdO?= =?us-ascii?Q?PRL9IrzyiXHeNDsskuKm/0C86nb7R17+jzU6oN3AQ3f8hRdLd3NWjrKoEo/j?= =?us-ascii?Q?b639InnyFW0ffM8arVOMoaX4Yqw5l6sGUMUCXTZ0zRP/4kv8TlH0U65UFqLh?= =?us-ascii?Q?NkwEEyAXByVXrSd7z0ijfa/ZnSKxguwf1zh9Yp3zuJbjOLTThW1NdjgYh/pR?= =?us-ascii?Q?tbsW0g=3D=3D?= 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3a5395e5-6024-4057-e006-08d9db8a5144 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2022 20:28:56.4292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lWZ4cERHtJCTJosuPj8YZsujabCzzWQxK7FNthHkj5t/37aPuHcnJQLlJ9MZSUf93ZsgdFsw8HO80gINKHzZXw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB4388 X-Rspamd-Queue-Id: 4JfHKq40qDz3lyb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=K628dLH6; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.43 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.43:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.43:from] X-ThisMailContainsUnwantedMimeParts: N I have downloaded the final version of the opensolaris smbfs and it looks much more reasonable to port to FreeBSD. I will be starting to work on this (and maybe Mark Saad will be able to help). I have no idea when I'll have code that can be tested by others. rick ________________________________________ From: Miroslav Lachman <000.fbsd@quip.cz> Sent: Monday, January 10, 2022 10:27 AM To: Rick Macklem; freebsd-current@freebsd.org; freebsd-stable Cc: Yuri Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 CAUTION: This email originated from outside of the University of Guelph. Do= not click links or open attachments unless you recognize the sender and kn= ow the content is safe. If in doubt, forward suspicious emails to IThelp@uo= guelph.ca Hello Rick, thank you for the update and your time on smbfs. I hope OpenSolaris version will be portable. (or mayby some older version from Apple?) FreeBSD without possibility to mount smbfs is not an option for some projects. Kind regards Miroslav Lachman On 09/01/2022 15:46, Rick Macklem wrote: > Well, I took a look at the Apple code and I'm afraid I > think porting it into FreeBSD is too big a job for me. > > I was hoping the code would have a layer that could > be used as a "block box" for the VOP calls, but that > does not seem to be the case. > There is also a *lot* of code in it. > > I am going to look at the OpenSolaris code, to see if > I think it will be an easier port. > > rick > > ________________________________________ > From: Miroslav Lachman <000.fbsd@quip.cz> > Sent: Monday, November 1, 2021 5:47 PM > To: Rick Macklem; freebsd-current@freebsd.org; freebsd-stable > Cc: Yuri > Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 > > CAUTION: This email originated from outside of the University of Guelph. = Do not click links or open attachments unless you recognize the sender and = know the content is safe. If in doubt, forward suspicious emails to IThelp@= uoguelph.ca > > > On 01/11/2021 16:55, Rick Macklem wrote: >> Miroslav Lachman wrote: >> [good stuff snipped] >>> Apple sources can be found there >>> https://opensource.apple.com/source/smb/ with all the history from SMBv= 1 >>> to SMBv3. The files have original copyright header from 2001 Boris Popo= v >>> (same as FreeBSD) but otherwise it is very different code due to >>> different kernel interfaces and so on. >>> With Apple and Illumos sources it is possible to have smbfs in FreeBSD >>> upgraded to v2 or v3 but very skilled programmer is needed for this >>> work. And for the past years there is none interested in this work. >> >> Although I agree that it would be a non-trivial exercise, a lot of the A= pple >> differences are in the "smoke and mirrors" category. >> Around OSX 10.4, they changed their VFS/VOP to typedefs and accessor >> functions. For example: >> "struct vnode *vp" became "vnode_t vp" >> and "vp->v_type" became "vnode_type(vp)" >> >> Ten years ago, the actual semantics were very close to what FreeBSD used= . >> If you look at sys/fs/nfs/nfskpiport.h in older sources (around FreeBSD = 10), >> you'll see a bunch of macros I used to allow the Apple port to also buil= d/run >> on FreeBSD (a couple, such as vnode_t are still left because I've never = gotten >> around to doing the edit to replace them). > > If I see it right even the 10 years old Apple version of smbfs has > support for SMBv2 so if this old version is closer to FreeBSD kernel / > smbfs it can be a good starting point to merge changes to our smbfs to > have SMBv2 support on FreeBSD. > >> The hard part will be dealing with the actual VFS/VOP semantics changes = that >> have occurred in the last 10 years. >> >> Did they stick APSLs on the files? (If so, I think it could still be ok,= since the APSL >> is a lot like the CDDL. However, I'm not sure if the APSL has ever been = blessed >> by FreeBSD as of yet?) > > The old versions of smbfs has original copyright header and no other > license. Newer version has some added files with different header with > APSL license. For example > https://opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_s= ubr_2.h.auto.html > > If license is a problem then I think it can live with APSL in the ports > tree as a loadable kernel module. Maybe this will be the easier for > development too? > >> Don't assume anything will happen, but I *might* take a look in the wint= er, >> since outstanding NFS changes should be done by the end of 2021. > > I really appreciate your endless work on NFS on FreeBSD. Without your > work the NFS will be lacking behind industry standards similar to what > we see with smbfs. > And if you will have some spare time to take a look on smbfs and maybe > solve the SMBv2 / SMBv3 problem you will be my hero. I am waiting for it > for many years and I know I am not alone who needs working SMB / CIFS on > FreeBSD. > >> It does sound like there is some interest in this and that fuse doesn't = solve >> the problem (at least for everyone). > > Yes, there is an interest. It was discussed few times in the past in the > mailing lists and web forums.freebsd.org but without anybody willing to > touch the code. > FUSE alternatives have so many problems with performance, stability and > configuration. > https://forums.freebsd.org/threads/getting-smbnetfs-to-work.78413/ > > Kind regards > Miroslav Lachman > From nobody Thu Jan 20 00:01:36 2022 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 1EF431950E1A; Thu, 20 Jan 2022 00:01:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670064.outbound.protection.outlook.com [40.107.67.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JfN3D255Qz4gLW; Thu, 20 Jan 2022 00:01:44 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JgYDfHPmbeMbb9ll5obCHJBK4PTm/VBjzQSnmcEON2ARCmxoK/jnmqW71VxJBQHu5/wJSbm2EkrSSGPZ7Q01ODvpxyzrmLLsVMpz+76ReDZpp2AgD24vF5JIZaeQZtZUp7aAXZTgSBUzqR/5SuRkRYSSGhxAi1wk2Pdk+ljvzUNLqOLj+fwPPO1LVlb2Y8swjWV8+GhL9y8YyYGUWKavFTnjsn1nf+pHl4fXF3xM67uhN/9kAHLIGGKmxe/ogVo1FkDAOyCraw1FTDdfyeFBlFhxhf48VWYVYxUt8toC6qHasR1wsQHOsxlmTJqiqbVCCrRVX7Aq8kbvFHd2HhHS7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4UVnceWNMA4gKYC4za20RmRErqlB6IyzyLszTsLpgOA=; b=KV6n8wnGeRbhlSz18GoNE37c5HV7gf9asiPHwKmbzxbllpZsXCHBEi1k+iMnPHReqrImqpA6sTMRWBseysH9CizMgzcj+2OjXxCqP1b00os8vw0uzb0mR9mOdGYSXwmLivMQ2HZGzGKVcaPWafP6b3v93ew0FD27Wo110oK5aeF48kb2w60DM8aeJO0x5imaWDE+KPR6P2JVosmf5ItOrJp9y35S5qHuPrz5HSpVHY/cPJ/iDlIMPyZE+3dRy10dtjV9TX5oZuqHzDWeAKIT8uFqm2cpCbVf5kaQT9+KwA+EmeibAPDJV1MXZxtfbFSlp9ksVL1BXPr/pDSpb14LcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4UVnceWNMA4gKYC4za20RmRErqlB6IyzyLszTsLpgOA=; b=Gb/cMuZ0DZ0KnRQh9dftoWFGRorbXyAUINUDU5ejPcJnBwU5OwvySePboe5B0X7TsM6x1FRtHESibmRB8nd1BinIRzS4+0vVtLN8s1zQsIMvMQQrLRqYacX8jo6xV/n/eokQM2QZ2zEDpjxDi7keQf+JNhqxzYZiZ6d+CN6SveUeRop181UDvyYxr7rrM9tv6yxL/Q+MszU5IoJl8f8WgrnghBThuXbJJsaK7Ttrg33pwtl4S4ZsOqXjulA669jogkMA8vpswcbVBwwRhJ1WgRFNVZhaBZNiQMHgbRi6LqQuCrlkV2+sf/aMMrk0PrGuTldR7hkBSE/aK5TFQrxq6A== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YT1PR01MB4661.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:40::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.11; Thu, 20 Jan 2022 00:01:36 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::c9d2:bf41:eeca:90aa]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::c9d2:bf41:eeca:90aa%5]) with mapi id 15.20.4888.014; Thu, 20 Jan 2022 00:01:36 +0000 From: Rick Macklem To: Yuri , Miroslav Lachman <000.fbsd@quip.cz>, "freebsd-current@freebsd.org" , freebsd-stable Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Topic: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Index: AQHXzvvFA1WWxQSLW0uUJGavCusr2KvuZUQAgABpl4WAAGcwgIBr+tlBgAGeWQCADnip0IAAAWeAgAA5aNs= Date: Thu, 20 Jan 2022 00:01:36 +0000 Message-ID: References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz> <54704b99-7b89-76a4-0368-79bee391926d@quip.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 5be4f8e9-fe39-508c-aa1d-7fd868bd9625 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5a46c75-1fb1-4ddd-a9f6-08d9dba80698 x-ms-traffictypediagnostic: YT1PR01MB4661:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: g2tRnlyqdy9HRDFisEe5Bpjysbk11k+rDzYK7ASqWgBVsJezZXe6NdJHFop6pI7dY3V6gBs781DHUaqYm3Py842jWos9FTbt9LkZRLQv7YJv7i+plkEHU7QF7VNEtFFQ3M700jR8nBEsOpPexNxRpgPEhY6A9rJGThXISHD2wiUG1SAXdsfFKbG/U6legKJVv4PBuGUJYjiqfLNt/nWZCKzAotNKvpH/lSiAt/OXyHH773F+/ZusBPPINyJeUIsWGZ1TI87Nw9cZq51CjGVktQ/ysPCz8hTVRsRRBEjUyE71UsZCJMACONuupEooovFy1QxvaT71n8gAwp6l1EJRZHf4WjmKWWrjc0jd+DNJPUtPD1SjXxeXdjb3B2J6f6n4zV68pmlydcXCYMk6Jr6ej+fxbj9qsb+LqHt4gcapaPubzMbX9QWUbBx7ANS3h6BZ/dvcowYoW7GB8wqhDkTYWay5VWzTq//EWGFLeITjIRJUYBOotYLgdcyU6NH3nXisZfLS4Y1UlL0bJUeV4nz+afqwi51rhEnU830FAH/oWiXxwr+6rgjMhYIydnor0TQ4DTUtsImkOkB34hsYnFNdX350LEfPgoy2eccJPOsfbtU5C/GSvXPQ006dzn3MaoyZoeZfCs51AUFkqtQ0zbaXmVDyM9WtZZkdZtmEpA6w4Kt1yQR6YRYyPmtRQdLyagErItnGzoQSHKAeajSJKtKMtKEoO/PrvWCRa5MLdF8+ibSpmGQRCRJe0JCLkYcE/0Li2WcAdfGYts8Wtb3YO4vGCkB7eiYi3ThxFp5gOakc1KE= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(33656002)(8936002)(2906002)(66476007)(55016003)(71200400001)(86362001)(186003)(83380400001)(38070700005)(7696005)(786003)(5660300002)(66946007)(66446008)(66556008)(76116006)(64756008)(316002)(966005)(9686003)(91956017)(52536014)(122000001)(110136005)(508600001)(53546011)(38100700002)(6506007)(8676002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?l11eJ95DkvH5mBng8PWVFMf+pF+AAMOLqmlGw/x9G4km7hdNTYYgrsjLhx?= =?iso-8859-1?Q?Fkww4tKx72GmNaHkBw17fN+ex/VnVCVv3e10GAInivr2tS3OPa2ra9qlcu?= =?iso-8859-1?Q?rtQa9asE90ot9HTEEuqcTWyOy+jztSyswdTT40W2xDkUkIooxrcTZtd0no?= =?iso-8859-1?Q?heeyo2J52JAE9lhPvR8sAmd52dCrGNW+jrlDm4Y4+yf5WyWY+OlOqLO0hr?= =?iso-8859-1?Q?JuGWbIYyAqEO3T+lAR+F64uUhfKNqtX1rreGS2Ge2Ep9SFHyLtgWbfWigE?= =?iso-8859-1?Q?47hhnkaVnsuj15AGS5vo4oy6N+Ifi7O+/3yK60tzBbZr0/1s0NrQrSNboS?= =?iso-8859-1?Q?vUpi/qkqpOj7g9DRjrcj3zPHZK61a1UqRysYO0TYiPpFE+VnYu6l1SvLlq?= =?iso-8859-1?Q?dbEzg3hEhNEb7ulZ62Ls9wcdUTPy71ESdpgpPuo64/UaX6h+OvTtf84bGn?= =?iso-8859-1?Q?0PPtFQpHOF0uGYDFEu9X0HaqhJ/BM89YbY4sGLrRwhu8anD9158qjJytsJ?= =?iso-8859-1?Q?I6TClkA6FEdcF/NlmXjZ0+uIr8CLL4HvZO1UBOlj/F/WfanyyhlqZ/9KDl?= =?iso-8859-1?Q?JAwDkJXqiLEmjC0JAnwQCBfF7T+vyoF/fVGbhmMpIGlrNWBipNxgK3nSiq?= =?iso-8859-1?Q?wrxHybcei9Rw06W/GJhZyJl5r6dFRc3yMmzmHvMDRghtTSNM2mPqEzRDXp?= =?iso-8859-1?Q?5XJUIJYIVkZkyUVqGy/Q8r079WhsS+L0mUjo4tiPDilsyJlDjnIWXgTEE0?= =?iso-8859-1?Q?/wb3336leEe/TvPNWSlpjcdcSkUUSBqA/i5+wOjDnL25JxYJtkYUz/vAH/?= =?iso-8859-1?Q?Ff4CPKDCp1jWvNnPHeTXw1lTqgY3OoFvTGInsccX4y5lAWJEDoj31z6hYR?= =?iso-8859-1?Q?OiNwoMGai/Zu7uUoG6vXiXqsiphCIJR6gT3ljbd52juvaEXrML5cJJWBE4?= =?iso-8859-1?Q?P+tpxvWTmxSyMaGKy5dI/X1BSpkYns9kdy2ZI+PXDvheWDib3FCBgVKBcq?= =?iso-8859-1?Q?i2JfX1oyXnWV8JI/mf4NTj3BpHbSYCm4HyTWRxu2QzH45TdUSzqfQnRV6H?= =?iso-8859-1?Q?LsL4o9eqPwaYAU9bMe0BRFpIocuPq9/Zc8bV9hxl/IY+FjrS1K6hZOu3n2?= =?iso-8859-1?Q?Xx4jABptHAhfEepKSKaBe6jZKuYq0YF9qllIRIigKphwfmMpoZGvVeyhNq?= =?iso-8859-1?Q?CzADVJcDppLcp+pikCc934C5x9Ll936/LdrMACE2iCttIwk0Z7XAL81PZ9?= =?iso-8859-1?Q?h0tmifjgWKq2CaqkMWvU3Xz059I/SYJyeyDuOyBtI43xyiAJTjjy4Z2ENC?= =?iso-8859-1?Q?SdXh5jOkxtMG4KRzb1IMs6jBHkzuP52mHeJiGzYiHLY03HJ5y7PCKkDvix?= =?iso-8859-1?Q?Ru6YIyDVrhaFxyB84vPdgAFn+vsw21D/Ai2Zjx9r489jymUq8fQ7PgQk3S?= =?iso-8859-1?Q?oPWIwQKnKZxdd9mMwBNEOFLa+bOf0VJkFY5W5japwcGYtST1G2pSAKKbVk?= =?iso-8859-1?Q?72mA40B9QpYc8IzVG/Yg4gkxgTYBXAhb9E9E3nGdpCnA3kIXtE9NH4h6Ft?= =?iso-8859-1?Q?T3UK6c4ge0+G9xXd2EDQw+J0voMktA8OhNnZ5MgIPOQWv8xO+keFNGw6wM?= =?iso-8859-1?Q?iWk1t40b2jBRUaChMywhIqNaX1Ni/jqLQELZVRxCdb+W+MImFLjg4OWoOz?= =?iso-8859-1?Q?qz3i5/XhCbsvbZY2TWKB4jwGPSzTym/KOVd+aaAMSmhdzRWGYd0HoXebLG?= =?iso-8859-1?Q?PZfQ=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e5a46c75-1fb1-4ddd-a9f6-08d9dba80698 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2022 00:01:36.0824 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3itPzOvtl45SP9b8jjBkpSH6j/RD4yYrIvBeQwBFfIccIoPkhNgDDCQKdgDwMhq8xq6PkgyxEdsxMilTnsFCpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB4661 X-Rspamd-Queue-Id: 4JfN3D255Qz4gLW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b="Gb/cMuZ0"; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.64 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.64:from]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.64:from] X-ThisMailContainsUnwantedMimeParts: N Yuri wrote:=0A= > Rick Macklem wrote:=0A= > > I have downloaded the final version of the opensolaris=0A= > > smbfs and it looks much more reasonable to port to=0A= > > FreeBSD.=0A= >=0A= > What do you mean by "final version of the opensolaris smbfs", the one=0A= > from 2010? Please note that illumos (actively maintained fork of=0A= > opensolaris) has a much more up to date one.=0A= I'm not surprised that illumos will have updates.=0A= I don't think it will affect the exercise at this time, since the current w= ork=0A= is to figure out what pieces of the opensolaris code needs to be pulled=0A= into the current smbfs to make the newer version work.=0A= Solaris uses a very different VFS/VOP locking model, so a direct port=0A= of the opensolaris code would be more work than I will be attempting.=0A= =0A= rick=0A= =0A= > I will be starting to work on this (and maybe Mark Saad will be=0A= > able to help).=0A= >=0A= > I have no idea when I'll have code that can be tested by others.=0A= >=0A= > rick=0A= >=0A= > ________________________________________=0A= > From: Miroslav Lachman <000.fbsd@quip.cz>=0A= > Sent: Monday, January 10, 2022 10:27 AM=0A= > To: Rick Macklem; freebsd-current@freebsd.org; freebsd-stable=0A= > Cc: Yuri=0A= > Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14=0A= >=0A= > CAUTION: This email originated from outside of the University of Guelph. = Do not click links or open attachments unless you recognize the sender and = know the content is safe. If in doubt, forward suspicious emails to IThelp@= uoguelph.ca=0A= >=0A= >=0A= > Hello Rick,=0A= > thank you for the update and your time on smbfs. I hope OpenSolaris=0A= > version will be portable. (or mayby some older version from Apple?)=0A= > FreeBSD without possibility to mount smbfs is not an option for some=0A= > projects.=0A= >=0A= > Kind regards=0A= > Miroslav Lachman=0A= >=0A= >=0A= > On 09/01/2022 15:46, Rick Macklem wrote:=0A= >> Well, I took a look at the Apple code and I'm afraid I=0A= >> think porting it into FreeBSD is too big a job for me.=0A= >>=0A= >> I was hoping the code would have a layer that could=0A= >> be used as a "block box" for the VOP calls, but that=0A= >> does not seem to be the case.=0A= >> There is also a *lot* of code in it.=0A= >>=0A= >> I am going to look at the OpenSolaris code, to see if=0A= >> I think it will be an easier port.=0A= >>=0A= >> rick=0A= >>=0A= >> ________________________________________=0A= >> From: Miroslav Lachman <000.fbsd@quip.cz>=0A= >> Sent: Monday, November 1, 2021 5:47 PM=0A= >> To: Rick Macklem; freebsd-current@freebsd.org; freebsd-stable=0A= >> Cc: Yuri=0A= >> Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14=0A= >>=0A= >> CAUTION: This email originated from outside of the University of Guelph.= Do not click links or open attachments unless you recognize the sender and= know the content is safe. If in doubt, forward suspicious emails to IThelp= @uoguelph.ca=0A= >>=0A= >>=0A= >> On 01/11/2021 16:55, Rick Macklem wrote:=0A= >>> Miroslav Lachman wrote:=0A= >>> [good stuff snipped]=0A= >>>> Apple sources can be found there=0A= >>>> https://opensource.apple.com/source/smb/ with all the history from SMB= v1=0A= >>>> to SMBv3. The files have original copyright header from 2001 Boris Pop= ov=0A= >>>> (same as FreeBSD) but otherwise it is very different code due to=0A= >>>> different kernel interfaces and so on.=0A= >>>> With Apple and Illumos sources it is possible to have smbfs in FreeBSD= =0A= >>>> upgraded to v2 or v3 but very skilled programmer is needed for this=0A= >>>> work. And for the past years there is none interested in this work.=0A= >>>=0A= >>> Although I agree that it would be a non-trivial exercise, a lot of the = Apple=0A= >>> differences are in the "smoke and mirrors" category.=0A= >>> Around OSX 10.4, they changed their VFS/VOP to typedefs and accessor=0A= >>> functions. For example:=0A= >>> "struct vnode *vp" became "vnode_t vp"=0A= >>> and "vp->v_type" became "vnode_type(vp)"=0A= >>>=0A= >>> Ten years ago, the actual semantics were very close to what FreeBSD use= d.=0A= >>> If you look at sys/fs/nfs/nfskpiport.h in older sources (around FreeBSD= 10),=0A= >>> you'll see a bunch of macros I used to allow the Apple port to also bui= ld/run=0A= >>> on FreeBSD (a couple, such as vnode_t are still left because I've never= gotten=0A= >>> around to doing the edit to replace them).=0A= >>=0A= >> If I see it right even the 10 years old Apple version of smbfs has=0A= >> support for SMBv2 so if this old version is closer to FreeBSD kernel /= =0A= >> smbfs it can be a good starting point to merge changes to our smbfs to= =0A= >> have SMBv2 support on FreeBSD.=0A= >>=0A= >>> The hard part will be dealing with the actual VFS/VOP semantics changes= that=0A= >>> have occurred in the last 10 years.=0A= >>>=0A= >>> Did they stick APSLs on the files? (If so, I think it could still be ok= , since the APSL=0A= >>> is a lot like the CDDL. However, I'm not sure if the APSL has ever been= blessed=0A= >>> by FreeBSD as of yet?)=0A= >>=0A= >> The old versions of smbfs has original copyright header and no other=0A= >> license. Newer version has some added files with different header with= =0A= >> APSL license. For example=0A= >> https://opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_= subr_2.h.auto.html=0A= >>=0A= >> If license is a problem then I think it can live with APSL in the ports= =0A= >> tree as a loadable kernel module. Maybe this will be the easier for=0A= >> development too?=0A= >>=0A= >>> Don't assume anything will happen, but I *might* take a look in the win= ter,=0A= >>> since outstanding NFS changes should be done by the end of 2021.=0A= >>=0A= >> I really appreciate your endless work on NFS on FreeBSD. Without your=0A= >> work the NFS will be lacking behind industry standards similar to what= =0A= >> we see with smbfs.=0A= >> And if you will have some spare time to take a look on smbfs and maybe= =0A= >> solve the SMBv2 / SMBv3 problem you will be my hero. I am waiting for it= =0A= >> for many years and I know I am not alone who needs working SMB / CIFS on= =0A= >> FreeBSD.=0A= >>=0A= >>> It does sound like there is some interest in this and that fuse doesn't= solve=0A= >>> the problem (at least for everyone).=0A= >>=0A= >> Yes, there is an interest. It was discussed few times in the past in the= =0A= >> mailing lists and web forums.freebsd.org but without anybody willing to= =0A= >> touch the code.=0A= >> FUSE alternatives have so many problems with performance, stability and= =0A= >> configuration.=0A= >> https://forums.freebsd.org/threads/getting-smbnetfs-to-work.78413/=0A= >>=0A= >> Kind regards=0A= >> Miroslav Lachman=0A= >>=0A= >=0A= =0A= From nobody Thu Jan 20 14:26:02 2022 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 A781919752DD for ; Thu, 20 Jan 2022 14:26:05 +0000 (UTC) (envelope-from bapt@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JflDY4JG2z3Dbx for ; Thu, 20 Jan 2022 14:26:05 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642688765; 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=5UWvlwuIIzuQcwfi6EBmYMTVkvDtClVQBFM5lzwqGOQ=; b=kzJVf2oXHSjg76CMAS6zG3QOIpLUhQ1aCXD+dQGwi7KR0jVL8F6zZ2AE6s4MCTWeaJfpaU PZAW/Y8nd0pKjs4YD0TDGCOWLJmD3MgbkUCg+Kp8EC9uzCF960/c7CuAXc6o7siIXnXz2B mOJphBqYY+GTDn1cnf1m4PZKd+zDXVVqTfZ+H3Qsrw7kMcJfvIdX3sAxMJiSmRaUMVtIZk pwx/lry6DGSHOo+0mFkBeE80oBqRHhxB1yDAbnasEeAH+yMKVI03lOq8P6nEjvXQ8gGlMw 1CWER53zs/alKJwDCOdfqsnxzxvPHGD25LdLtiPfsM/QTgmEMEOCvEE6KPU67w== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 1E164FE14 for ; Thu, 20 Jan 2022 14:26:05 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id E023588F79; Thu, 20 Jan 2022 15:26:02 +0100 (CET) Date: Thu, 20 Jan 2022 15:26:02 +0100 From: Baptiste Daroussin To: current@freebsd.org Subject: [HEADSUP] Deprecation of the ftp support in pkg Message-ID: <20220120142602.64go6fjomdxv5yjd@aniel.nours.eu> 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642688765; 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=5UWvlwuIIzuQcwfi6EBmYMTVkvDtClVQBFM5lzwqGOQ=; b=OIDOwFuBIXV4Cn4tTjNg8GeqqgA/P3EJY8Y4BoXpdEZrDMEjSiOfE7Fx7pCYvkzmdAnDi1 0bNjpTfphkWLtEvRBj1SBeN5+xMh9ZFFvYadPLbY18PYcSDrxhfpZRewa+/NBfhfsLfdyZ h3gc2L74UE/SYAN1YhHjAMsIwCOINJXjJc4fn2YKWpRvJgxIeehD0E/u9CThOHh0Gvo8Ha lN15g8IXmdizugNr1vq1jYfWM2OQCQA2RdHSxchYSyngziDZULpnGXE+03oOU/LKP7iWde oTj9K5uJxtBf12AtlUd3djrnDQjF69dpIvYeQjdfYqLzeFAqVCWK+hqoPgO2TQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642688765; a=rsa-sha256; cv=none; b=hWBQKIU4tbhsp2MApbzquoImRI6AnuH2dERZpsLl9PoQFdCwI+vnvh7rSlE8ddRWpuak2A yfZR/8Jg0ROXXCYSWFUdU3fjE2UttBow6SMZbleWidEoH4/ipvE+D0MSY4SUsxu90cv2+1 IPGSkwxj0kn4nRmithWJV2DJlQbZQo59OvnbJUE0DUHI9fPWIS1YFgnQuWt2MmYl4KHWGf XGI2PxSrasVKl4xW2CUUsqDRSv735gtbALkjWKKygousw4N0CKfy52qP5uaUma+yk8+ExE GtAvHthVyybDNy8NAB4Q+UN8/jdiwVYV+cz/HXc8G8esKiZ4dEqo3PDIT5HO8w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hello everyone, We plan to remove the support for fetching packages over ftp for the next releases of pkg (probably 1.18) if you have a strong reason to use ftp which cannot be fixed by switching to any other supported protocols like ssh or http, please do share. Best regards, Bapt From nobody Thu Jan 20 21:54:04 2022 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 11488196FFF5 for ; Thu, 20 Jan 2022 21:54:07 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jfx9V0nQMz3JZ3 for ; Thu, 20 Jan 2022 21:54:06 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ua1-x932.google.com with SMTP id p1so13409406uap.9 for ; Thu, 20 Jan 2022 13:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nkeLAArdbDtGC0he0H9jl3y8pmVKv8GhRRUzsqrmqwQ=; b=AueQiGWUx0IL9ZIXdFhda59C5AutJQIt9PND2pnMx7Rjm9q5nvLWB0ssB0mA2vFsk8 8xTD7u1ipM16u4N77/nD0QXTGCTNUgMzyXQXFYo0+alR3eIgLsDVDBtqp4YNA1vdadMG YMamdsBzUSqEt3BeoYL30XKxKZ8c9cjl56f/Z//5auHYsjviukBSoudGAnN73eEx8fL1 5pXalkzkTaOFwszp4OQjb21uIbeIglUX8KAd1XjRJUfOVVtGPmLWKtTgJGvvbmcFjLM9 TZ/hVAYJEIvh1pHTWmGVrnkirU7SBcJ3eymIzKe4WtZ50qy7a1Ms8FGNlg8QTgLaKR9r WKVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nkeLAArdbDtGC0he0H9jl3y8pmVKv8GhRRUzsqrmqwQ=; b=LY6hZDRD5O8AwdNtCaxHdpnWeuipXsGPM11imrfLkLilU4/sl33nDv/6231SdWGtZ8 5U9sq3wgePI6ALxEdpfOYA+4LihKQHXEZ7LOHW4AdaR1/QJdpphpek/UL8AZXiiKpZ0P s1jOdeJMhSy2kcPLl/975BPxeD7VvwtBONVYqbhNT2Zg3xfLCYvh3/hX39N6na+iBRpP mwbd7aHdF+0QdnPGSRYm6XSoQ65127y1p+0sXJhJNjbKVKkE6nMYqU7bveJCfWNxsmAn povzvMMUkO9VD/hf13YXj35M4yF+BlvChwwVSlJf6Gt8nQIT6SRtCQfQYtLi1wPQ/PGN h66Q== X-Gm-Message-State: AOAM531TzsPhGSGDAbqZtDuDy9eyiHaWeWqmpZb5J/9bf/KnuihaeAS6 fbon/h1nKj5+fsa6TCmrvBnd7rtapOTasl82jNjZUgO8foJr0NUi X-Google-Smtp-Source: ABdhPJw0VV/R0KRUc5FkYmhgNS7MRaZlfU7Tu6oeuDj2xucX0etICLr1MiBu5HW074/S1nmfp0iGMVAhrhVeS3a8ZTM= X-Received: by 2002:a67:e016:: with SMTP id c22mr588370vsl.51.1642715645226; Thu, 20 Jan 2022 13:54:05 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:a59:cda4:0:b0:278:7001:4412 with HTTP; Thu, 20 Jan 2022 13:54:04 -0800 (PST) In-Reply-To: <20220120142602.64go6fjomdxv5yjd@aniel.nours.eu> References: <20220120142602.64go6fjomdxv5yjd@aniel.nours.eu> From: grarpamp Date: Thu, 20 Jan 2022 16:54:04 -0500 Message-ID: Subject: Re: [HEADSUP] Deprecation of the ftp support in pkg To: current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Jfx9V0nQMz3JZ3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=AueQiGWU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::932 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-2.25 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::932:from]; NEURAL_SPAM_SHORT(0.75)[0.749]; MLMMJ_DEST(0.00)[current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Replace FTP with IPFS. Adopt distributed cryptosystems today :) From nobody Fri Jan 21 12:32:56 2022 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 2448D1838980 for ; Fri, 21 Jan 2022 12:33:06 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgJgh3Pbtz4WS7 for ; Fri, 21 Jan 2022 12:33:04 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 20LCWupI064917 for ; Fri, 21 Jan 2022 12:32:56 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 20LCWuoC064916 for current@freebsd.org; Fri, 21 Jan 2022 04:32:56 -0800 (PST) (envelope-from david) Date: Fri, 21 Jan 2022 04:32:56 -0800 From: David Wolfskill To: current@freebsd.org Subject: panic main-n252563-eb815a741940: Bad tailq NEXT(0xfffffe001d7a3ad8->tqh_last) != NULL Message-ID: Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PwMyvObFURhW2Z1d" Content-Disposition: inline X-Rspamd-Queue-Id: 4JgJgh3Pbtz4WS7 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [1.60 / 15.00]; HAS_REPLYTO(0.00)[current@freebsd.org]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[catwhisker.org]; MLMMJ_DEST(0.00)[current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; REPLYTO_EQ_TO_ADDR(5.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --PwMyvObFURhW2Z1d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This is for main-n252563-eb815a741940, after an update from yesterday's main-n252546-e0282802a6ec: FreeBSD 14.0-CURRENT #401 main-n252546-e0282802a6ec: Thu Jan 20 04:15:42 PS= T 2022 root@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys= /CANARY amd64 1400048 1400048 Screenshots (from each of 2 laptops) are in https://www.catwhisker.org/~david/FreeBSD/head/n252563/ The first mentions dummynet, while the second does not. My build machine did not see this -- but I don't run ipfw on it, either (as it doesn't directly connect to networks I don't control). The first laptop happened to be connected via iwn(4); the second, via em(4). I'm happy to provide more information, once I know what to provide. Peace, david --=20 David H. Wolfskill david@catwhisker.org "We can either be loyal to Donald Trump or we can be loyal to the Constitution, but we cannot be both." - Elizabeth ("Liz") Cheney See https://www.catwhisker.org/~david/publickey.gpg for my public key. --PwMyvObFURhW2Z1d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYeqn+F8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix 1MTZAP9hAJ/M1ur8AfDmlQEAgTx/dv5zI23Kd41/pvuKdRM9XgD/ewCjEzrp9yHp E39TCa6dEoR/053Q7SyePF31JZE86gg= =8/PN -----END PGP SIGNATURE----- --PwMyvObFURhW2Z1d-- From nobody Fri Jan 21 16:09:26 2022 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 774CD196967E for ; Fri, 21 Jan 2022 16:09:29 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgPTN2JLBz3CnV; Fri, 21 Jan 2022 16:09:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 20LG9Q3d067366; Fri, 21 Jan 2022 16:09:26 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 20LG9Qtr067365; Fri, 21 Jan 2022 08:09:26 -0800 (PST) (envelope-from david) Date: Fri, 21 Jan 2022 08:09:26 -0800 From: David Wolfskill To: current@freebsd.org Cc: Wojciech Macek Subject: Re: panic main-n252563-eb815a741940: Bad tailq NEXT(0xfffffe001d7a3ad8->tqh_last) != NULL Message-ID: Mail-Followup-To: David Wolfskill , current@freebsd.org, Wojciech Macek 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-sha512; protocol="application/pgp-signature"; boundary="O0sXNwkbMNI1OW9T" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JgPTN2JLBz3CnV X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-1.48 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[catwhisker.org]; NEURAL_SPAM_SHORT(0.92)[0.916]; MID_RHS_MATCH_FROMTLD(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --O0sXNwkbMNI1OW9T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 21, 2022 at 04:32:56AM -0800, David Wolfskill wrote: > This is for main-n252563-eb815a741940, after an update from yesterday's > main-n252546-e0282802a6ec: >=20 > FreeBSD 14.0-CURRENT #401 main-n252546-e0282802a6ec: Thu Jan 20 04:15:42 = PST 2022 root@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/s= ys/CANARY amd64 1400048 1400048 >=20 > Screenshots (from each of 2 laptops) are in > https://www.catwhisker.org/~david/FreeBSD/head/n252563/ > ...=20 > I'm happy to provide more information, once I know what to provide. > .... Reverting 9ce46cbc95d7a6fccb55af0d42cbb85c29f10639, then rebuilding the kernel, avoids the panic on the 2nd laptop. (I'm using the first one, as usual.) Ref. https://cgit.freebsd.org/src/commit/?id=3D9ce46cbc95d7a6fccb55af0d42cbb85c2= 9f10639 Given that the laptops (which use ipfw) saw the panic and the build machine (which does not) did not, there may be a relationship. I'm happy to test possible fixes (on the 2nd laptop). Peace, david --=20 David H. Wolfskill david@catwhisker.org "We can either be loyal to Donald Trump or we can be loyal to the Constitution, but we cannot be both." - Elizabeth ("Liz") Cheney See https://www.catwhisker.org/~david/publickey.gpg for my public key. --O0sXNwkbMNI1OW9T Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYeratl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix 1HgcAQDmemO0r876AwRBIurYqUyVk20zeY+yU1OwKnAQWZLvuQEArVSaQUxtItsn fDIHGULtn1XJmgZs87TxI0hr9WVkvAM= =q1N7 -----END PGP SIGNATURE----- --O0sXNwkbMNI1OW9T-- From nobody Sat Jan 22 14:02:28 2022 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 09109196CFEF for ; Sat, 22 Jan 2022 14:02:38 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgycY0Lmpz3DTm for ; Sat, 22 Jan 2022 14:02:37 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x32e.google.com with SMTP id f202-20020a1c1fd3000000b0034dd403f4fbso21275209wmf.1 for ; Sat, 22 Jan 2022 06:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=433ljuu/naMRklHK3hzfTf+qp0PATBy+e/HgWJjCwsk=; b=NydZo1SROml905ux5oNSmWrL3LCU1+QYY1hvEzgP/SorZP25sAuN6HHemRwKeXRtUq cQmFfPfFULaBYjMz2dHUhM7oLtnTSX72bq3Caf3ppeevYzGCPUNscOotMaxnKZ4Fznky z7MaLlgnhVEsQ0NI0fkjoK7RQsMKluPASarQlKcqEcJVjIZC4thHhsum1yqKiUM1uAcZ 1UI7vzhR4iGWdrPGtknDJAmLKzpG0anyjmL/w8F7Q7iYNxW+WMlccjVpvI5unVvtPXZR Msrbx70Q9fE4DS4MMBM3qnBKAmwnHrodYryJ+Gmv1IUkxW7HmR/UdDKRDLE8q+7/vOyw /DDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=433ljuu/naMRklHK3hzfTf+qp0PATBy+e/HgWJjCwsk=; b=aOm6HNlMCgZZOQMu5wrhgqywP5mx1YtNThTkm1hV2KC78lEFctqqVHmQeWjm0B4QuT mgrP9pC6KXMBT92nB8sqGgmj4LMSNTteYxFHprqk/w3MUN4h+lpYxlJZKA63ripqYNaz uAlexnk0BDL87+/uJZUhs3ERkDZY8rqomqWHuuIPRAmh/IDROz9ThAraohZGAEHJmR3t 1ly+tcuPgcxTkrBmgJ1q8bmjPssDoCRViayHFMWmmb6QWtKDn1Fs+jX4AWW8fA0E6uGP yBkNi81ksI0jRmSQi1L//KMvh2V7aaw7MFQ1dKrNqoQFx/L2qUIMOb5arrvqnOMBSAsZ B4cw== X-Gm-Message-State: AOAM5322nEc/TBG4V73g+vQHklNaWdO3YgJgZPORgRhBrAcR4txP0Lg+ HQY4YPQQg5/vP+GssMTR5Fq8KhsIsViX/w== X-Google-Smtp-Source: ABdhPJxZD7keSEhmYb7GrdCVMiaiTlumpllmhe1qdV1wSgWt3BQcKSSLoOpurgpAOYdBadG2yKp2hA== X-Received: by 2002:a05:600c:3c9b:: with SMTP id bg27mr4615166wmb.163.1642860149914; Sat, 22 Jan 2022 06:02:29 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id l24sm7791935wme.17.2022.01.22.06.02.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Jan 2022 06:02:28 -0800 (PST) Message-ID: <0a09bad0-4ecb-c45a-085d-b04a43f2c73a@gmail.com> Date: Sat, 22 Jan 2022 14:02:28 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Git: the first eleven (11) and twelve (12) characters of the hash of a commit Content-Language: en-GB To: freebsd-current@freebsd.org References: From: Graham Perrin X-Priority: 5 (Lowest) In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JgycY0Lmpz3DTm X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=NydZo1SR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [1.91 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.91)[0.905]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32e:from]; MLMMJ_DEST(0.00)[freebsd-current]; HAS_X_PRIO_FIVE(0.00)[5]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 24/12/2020 04:06, Warner Losh wrote: > Re: referencing one commit in another for git … >>> For MFCs we are recommending the first 11. I think this >>> will likely suffice and matches the git client behavior. >> Mercurial defaults to 12 digit abbreviation. Git >> abbreviates linux, freebsd-legacy, freebsd-ports repos >> on GitHub to 12 digit. > I've updated to 12. That sounds like a good number of > digits...Thanks. > > Warner I might have asked something this before (sorry): * what, ultimately, was the main reason for going with eleven? For consistency, to match the git client behaviour? From nobody Sat Jan 22 14:34:39 2022 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 D6062197FA20; Sat, 22 Jan 2022 14:34:50 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (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 4JgzKj6gp6z3Qb6; Sat, 22 Jan 2022 14:34:49 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 7867C3200B25; Sat, 22 Jan 2022 09:34:42 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 22 Jan 2022 09:34:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :cc:content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm1; bh=g rMmDGBflDhTkQ1dKNL2Z/iZExxar75xUi+zNrWXuI8=; b=YputTSu8Ungh3AN0Z WYeIlXuw57tFGWKpcy84RncQaqIqCkpRMEaZ8aflri3TcW/IQ8PSff+NgMFOqwB3 YMvS/csAT1nxU0M6wlz4ql5D8O7dil9VMfL4lxoeopLqQO/yKW/I9Qx7Pv+/dBRI ky7uNjrms8N6JMvrDpmAOnjDS/lkBqtfnhirxF6NA3cYax7pK9sZ6yceHftLE2Kg oqs0MJRSruDgWfK1/fO5JUHWiJ9elohijF5kNGGsyxhOnWzpiqrkTVF2iQ/REJX4 Hm8p0wPKK+7LDoslbuDpx8WOLFI35EZzU5gAftr8e6Zd82EgvTKRJMme5P0dBKOO +KqmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=grMmDGBflDhTkQ1dKNL2Z/iZExxar75xUi+zNrWXu I8=; b=H2J6EUtrSLNGC9YbfQMoaJP9/3WtTqOWo+HsBHNf7vwcTGfl5TWedgsUB 3Ho63ycPA0YkeX629gd3KesVgY1aprpbFuWDrnyLXJuY/80sUaqVk3owso67d9mk 99UDNJ5sKOgZpa0z5IVEtTF2a40ynNjEabI2g7Ii1L3FQ3DnlHiDlkieAzMIXoT6 qOebaHWGpEps8SJShRUCuwZsfD7NDd1lWbcJokvG/r08MSMP1TjdYAtGzs+bm6TR DqwkbS4lByRCLX7uhtjAr/YcCdtBgbJDLlkAo7EWJMVS37ocyYNB0ionBDqRpuvt eG5skoMcOc+3FVRGuKnr/adPi8Rgg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvddvgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehgtderredttd dvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiihgihs thdrnhgvtheqnecuggftrfgrthhtvghrnhepvefghffftdefkeelleehtdejledvhfdvge eijeevfffguddvhfetgeejueejueeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 22 Jan 2022 09:34:41 -0500 (EST) Date: Sat, 22 Jan 2022 14:34:39 +0000 From: tech-lists To: freebsd-arm@freebsd.org Cc: freebsd-current@freebsd.org Subject: POLLHUP detected on devd socket Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cN8/Qsv4xgEsS6SG" Content-Disposition: inline X-Rspamd-Queue-Id: 4JgzKj6gp6z3Qb6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=YputTSu8; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=H2J6EUtr; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.20 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zyxst.net]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from] X-ThisMailContainsUnwantedMimeParts: N --cN8/Qsv4xgEsS6SG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, context is a usb3-booting rpi4 running main-n252544-7406ec4ea99 I see this in /var/log/daemon.log: Jan 22 13:24:54 redacted zfsd[886]: POLLHUP detected on devd socket. Jan 22 13:24:54 redacted zfsd[886]: Disconnecting from devd. Jan 22 13:24:54 redacted zfsd[886]: ConnectToDevd: Connecting to devd. Jan 22 13:24:54 redacted zfsd[886]: Unable to connect to devd Jan 22 13:24:54 redacted zfsd[886]: Disconnecting from devd. When this happens, several other things happen: 1. the sshd server dies. Already-established sessions still run, but=20 the server itself stops and no new ssh connections can be made. 2. syslogd dies. so does exim, nginx, smartd, sshguard, pf I don't know where to start looking for reasons for this. Is it a known issue? In the meantime I've turned off zfsd as it's not really needed in this machine's context (headless, zfs on single disk), from what I can tell. --=20 J. --cN8/Qsv4xgEsS6SG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHsFfUACgkQs8o7QhFz NAXSLQ//a6StY92eAnZH9yFn3Daqr0KSf3PhHM7y4LJqv5q8T2HNSVmZUst2EKaS IkFSozB9V5CY5qtV0RfRtcvdR+Pv2aN4zp7CuKYp91LGe+Q+gmNAf4D1UOkVnqvc bbCXHBNj22piXsqfpoCxKWLvNV5rqNbGSEPBkFz0y/z50m5hSPwcu9b8A/xY55WG /Ptd7zL1Lv+wZ91E31oPOe3jNHidwoSHah9otMBMhZuJkQXiaLi8c8vT+ChGPRW5 TO/2QKBnBfnNIxiOY1jYS46kSTH14W8snTHnjRRbrc8TCJ+5GRo5MlS0Y0DeXGoP QAh79vrGu3/NqnEcnE8OxMsbPiSpW+pjiyCKCJwKg4WzxUT2UbX8DRL1Dt+uhPjl UqaJ/mX9fvUFTLcIblPNlD5nEmPp9MOuEmXW0O634unN7HUX4BSH5wgljFgUAoSX o/9xN5SFgDbrz9Irns9vvKgJvpKXuGzJzvpEod/20DKThLV8FcFyDcTCNBKVD5PB 33shA+sR/CJTEPHaVa+bUJiuSU3+arO0T2HpcmtXIeivv/obpwrAI4Hev+Dki16e ml4jklzeCl64qdCrPsoXd3avOCv/FXhiQkMyhELRXtE3TPW+8weG45yKQqmjSftC pNgyDFDsNz+LZR/W8ENEeQmIwp372z31uMTk9lf+BssMgCP0yT0= =C4Fm -----END PGP SIGNATURE----- --cN8/Qsv4xgEsS6SG-- From nobody Sat Jan 22 23:20:43 2022 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 E0F6119590D4; Sat, 22 Jan 2022 23:20:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660053.outbound.protection.outlook.com [40.107.66.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JhC0n5FP5z4gxr; Sat, 22 Jan 2022 23:20:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gyzmZRcu0Jz/HA72l0yMwUYA4nCB6HQgnDElIat/ei8XRLT3ypsmovOoKCdQouXaVIzxe5leSGb7jhcq8bCf13lnp4fcgfP5HZmOd8q1JL7c32hSlF+CCXJ81TCT6l/nPhGZDYAZa64Xj7DlAbxSngvGEX4AqVAvFWfFhIIe/bTsjpWH6lSTSDHA4QQ9gCVz4GIYGhzoM1SCgjpoB64vY4deJjgv0nDjs6bjRD6mqJskErGNGlTmcl3CuDluKzN/RQC88tzGS29CI+HMRIvqOR21n4nC78LOMGsA6UUYsGVSby8dCn2gzsU3uAMlm6kFOczA0eK6PzzuQ+wOEoMIRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pHdNPna+a4BdEQ+mMG8Xuesg9xab8VWaDMXXdTy/MJE=; b=F6gv+KxyvWEpz2swWk+waLy4dd1YDsuOqvyt6usUojt7v7UmuipWfl9qeAMGtCJ0RDB4FqA75z7sUxDdElAdYZk4QiJ3PbDeVf8opFSPbTFZc1WZXtwrizM4Rz+lyFX7HgpZOA/n/prT5MsxBAckHh0IriAwq1FoDWjALknBlFhqhMXo5FKiqvzwLBbwRpF4jcK2lOseZ1NlDjz8WyiPAy0J6PczsSY0WfAaJ/ZqiQTMNorwDvW3yzkxP0wYSmP6oj3Z+8dLyJLv9PllmesVedIk0pFB4u50Qf2V3MQwuhzA65Ps0NVvvoajpzd8fBpf1X/bSN/Mk/ilCx8vOEdK1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pHdNPna+a4BdEQ+mMG8Xuesg9xab8VWaDMXXdTy/MJE=; b=kdXsvFi/5KBDiP8Kpeu7jW0CstojNH5EwVSVYTtfOVPOlSlS6EV3SLV/dxNGnTzcngNZ4ksv56bmFOXwvYFCaKreZZSPGbDFHJyxXWj3MXeufaczpPLK53ZKVHj0alXv6+Xv4NVeyjFSJf44lTpaD2KyJBENthX1mU/nLpILrtnhi69Jx/W/tl+fHn/ySBPAGeIBCvRxDNM++rz5HuGeB2FwsByVikFNNh2N1uxN+hD+GSOo4WN8FSOlkPITwoMhYJzlv67ul9I2EZYg0XSv2Vq3fqJcY8FfNzAzJJKXDvfHwRsWTxcN9sRbJSBSYEjl/vOjEIm5uenVlcc0vTvYqQ== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YTXPR0101MB1806.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.12; Sat, 22 Jan 2022 23:20:50 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7dfe:b92e:1f9f:a196]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7dfe:b92e:1f9f:a196%5]) with mapi id 15.20.4909.014; Sat, 22 Jan 2022 23:20:43 +0000 From: Rick Macklem To: Mark Saad CC: Yuri , Miroslav Lachman <000.fbsd@quip.cz>, "freebsd-current@freebsd.org" , freebsd-stable Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Topic: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Index: AQHXzvvFA1WWxQSLW0uUJGavCusr2KvuZUQAgABpl4WAAGcwgIBr+tlBgAGeWQCADnip0IAAAWeAgAA5aNuABGp2gIAAPwEO Date: Sat, 22 Jan 2022 23:20:43 +0000 Message-ID: References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz> <54704b99-7b89-76a4-0368-79bee391926d@quip.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 48cea741-0bc1-0b2d-b42c-055e46148de6 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d7934dd0-acb2-4ca4-6cab-08d9ddfdd015 x-ms-traffictypediagnostic: YTXPR0101MB1806:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QbH/YohIyhvWici0A2W31Vd3MhmIo5XCs4lCE4vPQH1wHLi+F5Rr1Qpuh0FRuGMF3DiJv0WW5EpwRMXoxNhACn2alUKn/pTIEI9I2gaR4VjlKAYT4JK38hFDhdO0+f6EEJtmJFVSIBlaACiu1b6/pdkNPKE6X5KSlhjGQ80Vweqns4Oz1arXkhJMpzKj9DWZU2EPqAPR2Y/ZTt0fy7dGhkbW/elbqXYMt6q5pJcELIGZ69i1onNRk4y4AykWZzMXPN+S7oULD1w+e9jqlZO6TG519aOu8kFDBz6Rhhbffh3BxfoDetGWlkQZemGJD5Zk32KD5Yot/+IYm863krTAuoVvQ6AO9AlAoPqRqwq9Lwxw4smxEilUKoHM2R6WJjKNgHTDGqxgXb7CHlUqAjmxkaJOszTJ++ba8/PK6KR/OG3Mu8XOQDXUA3yNrm9ynRlRXBIVGKoVpCImANLH1F28hc9sIxRGCLGpdnQMN0AUr1VNTa7HbiUtmozz/SXDh38lgPmssFsfTgaSnSJ+2v/5BdhgUFav5rH9CZMaZ9SqHDF2sMPqJl+KKiQglJibaH6S860L5128Kdjthh4RwLWNvSVRJzjES+egpiXnPlZ4i1NPHteiCuYm8c2TxBhnlq7j+yLxxtNYVnzsGwrv6xju7hfOfja6xG/WSuIOWDtfgi23dk9JXBUamlObLjY11XLXTSTJa/Fq6kHssH0l4EgwNkS6qD0jjJ1g5qnccj3HuGlBLR8gX+oZlRWfjpkq3AXvbWbLv8mO/gOLDZLsjFdek2Ukr1nUtOitB/EcSSixJ01hv9396fmC9e33vTF2ueyAGPqM/rcZNfVdV0xMSnpqjg== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(6916009)(966005)(8936002)(33656002)(52536014)(186003)(86362001)(508600001)(38070700005)(4326008)(55016003)(8676002)(5660300002)(91956017)(76116006)(7696005)(45080400002)(71200400001)(9686003)(66476007)(66946007)(64756008)(66556008)(2906002)(66446008)(6506007)(54906003)(122000001)(786003)(38100700002)(316002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?aHaBfug/rIVvoHLl+znmPWH1UY3jRa66/dvpbfAaIecJLZvi7x1zwNM4zl?= =?iso-8859-1?Q?UZo3+oaF9c1MtMhYQzQbUSEGLvG6ED5yRMscGmYBRkM3ocM0sKztTpb7Au?= =?iso-8859-1?Q?EIuy+7/qIr7WNQMxaij+YB/OpJL5AwdnkvqYTlCZ2xgTz+PyxZWKsq3DdE?= =?iso-8859-1?Q?YIH6PSzzP/xbalgdNYyQM2QP8AvbZNie0nM4RnfA6F7IiG7zYuIl+8k/mQ?= =?iso-8859-1?Q?yIlIwXpCjmEKSthBfyp9ukdateu/Q9gYZbK4N9g+/KTMaKMTuuiEp9+7uK?= =?iso-8859-1?Q?iZr6qV+EU7De+B9bL1CgVNZ9Gpl3rSG4XAmOZNMckszG7Kny6IMGrCZZCJ?= =?iso-8859-1?Q?XrH2H/T6IEccXQAMBiU9Ge6aR6yc6mI90h1Z05Nbc4cPVBJjqm7yNGTBL1?= =?iso-8859-1?Q?iQD24CqHXQheSptRSRoJyl88VVYPqnEvqG6hH4rq+RryH1N8DCkfx994bJ?= =?iso-8859-1?Q?EdJOq/o67W0w5hbEWiXywMUG9q+PShk2ymogRFZSKy+LB7bzodNa4gXgyA?= =?iso-8859-1?Q?55Z8FhvAUEBPV+DhGR+rZn9n4LPGMa2YBH9IQAJDr5w1qY/sfodyevUaEN?= =?iso-8859-1?Q?ELvJtByfm2LDOBCboqSFZrgNtt6u7s77YNvMFu2CEz0GX2u4KAIJd8v2U7?= =?iso-8859-1?Q?GkD7qMz5c3yMADBLyC6yk0TAC3kUU7SGpY2UYSYPe5+JRwzTAgHPtgalto?= =?iso-8859-1?Q?+rhsT7GQpGD2HV9BneYJX1MwmCq3dKrlQqrvBjseazzW47aamWpA54Bt4r?= =?iso-8859-1?Q?c80ZULyd9nSMbQhKFGWJ817cgP7IPJrjjWXBXjvyMx9Eba7hKFp9dLDuAQ?= =?iso-8859-1?Q?dyYJZ3XuIF9wvpA3wv059WsKhuX9JthIXUzSPdYozXg87hqdl5VBMSGQfG?= =?iso-8859-1?Q?rmzMQp/tSaJHUUw3xgklogA0oct4ERWimlIZLqKqdv7X7wRjblsYr7PKoj?= =?iso-8859-1?Q?GzwmzhMXV8Ypo72wfqzAkyPPoQYKrzmb6ebhBjMpCsnmH/whpCU+jODyRX?= =?iso-8859-1?Q?IBqkOQaFvZBwwoeflEWpRVVvSHjo6c4/upaGZEd4VqmPIRUVwyHsu45AdI?= =?iso-8859-1?Q?uCOpJqs1Xm+SRrUqEX/lwp74gScqefkLhhhC3lh+5h5bNJ4+NP+vJ7ugg2?= =?iso-8859-1?Q?KPtljCGmNi9c5hU8Gk48Mcg7lPN3T9JdrsODGFqiNx4VngullfeCmgUqEV?= =?iso-8859-1?Q?q877JnZ7uprX8Ac8luHCMAOD8OX6u8gNp1fIxJ4uLKrMJgDGAuqKwLbTKU?= =?iso-8859-1?Q?7AA2KHIrjpi7Vem4oZo7cul+f0zU1BRrXPPdhYY2h3PfeHmK0XWeAxWjo/?= =?iso-8859-1?Q?SS6mMy0SV+XxmDxq06z+1kB+ItEYz0NdGFU6kLeI0J/KEwcnqNKnDgb9RD?= =?iso-8859-1?Q?8ceNMMZtCcWVjKok+dkSu24mCMSyDf5xPRA4a0qSvoaZ+bt/aUH9AOkyr/?= =?iso-8859-1?Q?IZ069CfqSrJsKhIcvNQE9FRUNJBK+lUqZPbr38pidM7FWw/X5dRFUoKjWY?= =?iso-8859-1?Q?WzmTeOwaKtOxRTuIA3rC4qZ4XuSRSRhITDfXvbTM4KVhZUFkey7SqUTT3d?= =?iso-8859-1?Q?UAs9cC7WztWXoHiIi00LLYJ5FeJdJiX1LPztYEOghI+0EsR/DgYaXiSJvb?= =?iso-8859-1?Q?C8Qh92ABo15o69vCU0dl+EGr5akdJNQC4tlooOGUhwGaBMpF/gBflxeQrA?= =?iso-8859-1?Q?xo88VLoiNkTuxL5WrJIGJptI+EGr7Q4k8u/S63m4S0st1E3f7AjL8bDeoQ?= =?iso-8859-1?Q?yDvg=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d7934dd0-acb2-4ca4-6cab-08d9ddfdd015 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2022 23:20:43.5915 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OxF63Fql4LD2pfI+vuE7oj1Eyfkix9AXIoGNJiJSjCiGKDwE1fU3blTBm4Ob+V/ZXKMNowdkhj+agVr5lDu96A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB1806 X-Rspamd-Queue-Id: 4JhC0n5FP5z4gxr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b="kdXsvFi/"; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.53 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCPT_COUNT_FIVE(0.00)[5]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.53:from]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.53:from] X-ThisMailContainsUnwantedMimeParts: N Mark Saad wrote:=0A= [stuff snipped]=0A= > So I am looking at the Apple and Solaris code, provided by rick. I am not= =0A= > sure if the illumos code provides SMB2 support. They based the solaris=0A= > code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure=0A= > predates smb2 .=0A= >=0A= > https://github.com/apple-oss-distributions/smb/tree/smb-217.19=0A= >=0A= > If I am following this correctly we need to look at Apple's smb client=0A= > from OSX 10.9 which is where I start to see bits about smb2=0A= >=0A= > https://github.com/apple-oss-distributions/smb/tree/smb-697.95.1/kernel/n= etsmb=0A= >=0A= > This is also where this stuff starts to look less and less like FreeBSD .= =0A= > Let me ask some of the illumos people I know to see if there is=0A= > anything they can point to.=0A= Yes. Please do so. I saw the "old" calls fo things like open and the=0A= new ntcreate version, so I assumed that was the newer SMB.=0A= If it is not, there is no reason to port it.=0A= =0A= The new Apple code is a monster. 10x the lines of C and a lot of=0A= weird stuff that looks Apple specific.=0A= =0A= It might actually be easier to write SMBv2 from the spec than port=0A= the Apple stuff.=0A= --> I'll try and look at whatever Microsoft publishes w.r.t. SMBv2/3.=0A= =0A= Thanks for looking at this, rick=0A= =0A= =0A= =0A= --=0A= mark saad | nonesuch@longcount.org=0A= From nobody Sun Jan 23 05:40:40 2022 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 E82E71978A1A for ; Sun, 23 Jan 2022 05:41:31 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JhMRs07Gqz4hsv for ; Sun, 23 Jan 2022 05:41:28 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 20N5f3Ck010409 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 23 Jan 2022 16:11:12 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1642916475; bh=1mswWN42ByTZdoYQKC5IeHvDNSiSGlIcN0qjuoch+wo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Zmgwqm3zBomFdgcMWvVil+lb/RvDjrPJ/RyYWKoKYY2AfkjupM+geXxCM003heXww PJvV5ffnOvaX3QzI6Lg8ORLeVfzkdSKV9rUXIP9OPV3oS5x4w1k//zNorJzpP4h6XR uHcQHyFN4R/bwvp9tS2+TxaUCZNDGB8lbJ+KgTPI= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 20N5eejL010384 for ; Sun, 23 Jan 2022 16:10:40 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:1d21:970e:2d9e:8d3e Received: from smtpclient.apple (2403-5800-5200-4700-1d21-970e-2d9e-8d3e.ip6.aussiebb.net [2403:5800:5200:4700:1d21:970e:2d9e:8d3e]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 20N5ee7P010377; Sun, 23 Jan 2022 16:10:40 +1030 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 15.0 \(3693.40.0.1.81\)) Subject: Re: POLLHUP detected on devd socket From: "Daniel O'Connor" In-Reply-To: Date: Sun, 23 Jan 2022 16:10:40 +1030 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> References: To: tech-lists X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Spam-Score: 0.7 () No, score=0.7 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4JhMRs07Gqz4hsv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=Zmgwqm3z; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-1.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 23 Jan 2022, at 01:04, tech-lists wrote: > context is a usb3-booting rpi4 running main-n252544-7406ec4ea99 >=20 > I see this in /var/log/daemon.log: >=20 > Jan 22 13:24:54 redacted zfsd[886]: POLLHUP detected on devd socket. > Jan 22 13:24:54 redacted zfsd[886]: Disconnecting from devd. > Jan 22 13:24:54 redacted zfsd[886]: ConnectToDevd: Connecting to devd. > Jan 22 13:24:54 redacted zfsd[886]: Unable to connect to devd > Jan 22 13:24:54 redacted zfsd[886]: Disconnecting from devd. >=20 > When this happens, several other things happen: >=20 > 1. the sshd server dies. Already-established sessions still run, but = the server itself stops and no new ssh connections can be made. >=20 > 2. syslogd dies. so does exim, nginx, smartd, sshguard, pf >=20 > I don't know where to start looking for reasons for this. Is it > a known issue? In the meantime I've turned off zfsd as it's not > really needed in this machine's context (headless, zfs on single > disk), from what I can tell. Is it reproducible? ie can you trigger it post boot? It is very strange that devd dying would kill anything else running - I = have stopped and started it a lot while testing devd scripts and I = haven't seen anything else break. One idea would be to hack up devd's rc.d script and run it under ktrace = and try and get some clues. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Sun Jan 23 09:02:40 2022 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 32A24195A540; Sun, 23 Jan 2022 09:02:52 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JhRwC25zvz3D60; Sun, 23 Jan 2022 09:02:51 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id CFC0832007F9; Sun, 23 Jan 2022 04:02:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 23 Jan 2022 04:02:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=gPu/DdcCpUE8Q1T2MguP6EJ3CAsvMHE0hYDW3j DzPCI=; b=JgCo4dTGfLAyuo/UGCSft8iqPlA33eHbzl/yX4X6YbSsJLDAZBQ3j4 8qg+jAAIlrfrwcEsTa9lmaorXacdZENNQ5GoSKT0dER1toRPbl8LAAgsi+DPo7H8 ymoXR8I94bbg8zDQq3FBYdQcuApvkSNlmn5zs0jtU2SgX7s5dO/RIvzRUe3xFVlt WnnFCed9f/NphCB4/C/XMdZ7lu4aG07qBl4rmzSKNMMPxypNp+9SA3YJFSjlTjfh Y7LrDMlXeiJgnK+nSLDU4XbGOWP5lgNbMeUze8z6oyay66B88YDvekIVBd5zKaQw 02VDu898rlM8IXXv7wy3URJ0MFJLX9xA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=gPu/DdcCpUE8Q1T2M guP6EJ3CAsvMHE0hYDW3jDzPCI=; b=FgtAuEwZQQw2dN0wS8lu6OIi686LWXQXG Uio0oVod7CpQJRtIKpSEiDbbD240Nt7SYQj8s50XrpJ2G6/eAvkr0fDCKvS/kAt4 IGQHLXcs1z3q1Nt01JQQ0soOgwdeBy+ueQ+ejDa9niY24ifSNF4gaBf/FQIrJHLD bihLhSxeKgnnfOSyc0SjJupJzJp0oBhepUPXrtSOEbcZmjn7K5lv83xno8x4Gtn3 Fl8+lYcFjxcUNJv0FLPzkXI74JgKm0kTwqJVoK4Ryz/HjJ7AwuOdkpYt3s3bo0TT cY+bQM+HI5811FqQAZbr7hAFQ4uJzLdDjL1yP33jBC7qzvc/8oi6A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvdegucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtreertddtvd enucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseiihiigshht rdhnvghtqeenucggtffrrghtthgvrhhnpedtheeigfdvudefkeekvddtfedvtedttdekud dvgeevlefftdekffdujedvhfduteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 23 Jan 2022 04:02:42 -0500 (EST) Date: Sun, 23 Jan 2022 09:02:40 +0000 From: tech-lists To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: POLLHUP detected on devd socket Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> 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="Otv9avpGPrERzERK" Content-Disposition: inline In-Reply-To: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> X-Rspamd-Queue-Id: 4JhRwC25zvz3D60 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=JgCo4dTG; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=FgtAuEwZ; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.21 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.21:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zyxst.net]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from] X-ThisMailContainsUnwantedMimeParts: N --Otv9avpGPrERzERK Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote: > Is it reproducible? ie can you trigger it post boot? > > It is very strange that devd dying would kill anything else running -=20 > I have stopped and started it a lot while testing devd scripts and=20 > I haven't seen anything else break. > > One idea would be to hack up devd's rc.d script and run it under=20 > ktrace and try and get some clues. I can try that, thanks for the suggestion. Right now I'm thinking it's tied to zfsd, since disabling that service I've not seen the issue. --=20 J. --Otv9avpGPrERzERK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHtGacACgkQs8o7QhFz NAU2Fg/9ELstaa09JFiQRcoaPdpQib+H1JllL+HLpff1lxGrHgP9jU2ClZG5dd19 rdnMOgsNuRrDfz8JaHj5xQyqkvKcrGNAIomO5+MlEqWrrUA64wRgSNuNqJsaaBay 8O6M8BxG5wvRE2+9BR9zuoJGQZJOjHUBwbnX6FD04fH1F5oDolC980LQBZjqGusg 2Yd/7ZcuOCHWd3tcHUbpSeOwy75JOBBeA2gZ7pHY0VBZZRwTd3WDbSAvr4fvHj00 5rI26LdAq/1Wmau2WbCWiMk1XY46kRtgjNVxKBiirjN07u9HJpW+G0UHcuA3EPIX u7DDmgHYasESDZG5wLiYyB0oA1msw4MST5odKnofdFNnGXrtrj/t8bAxblWF3UlY empslyeHZ7TBMU7fnNgqMIqCW5i6akGZT5+fsgluBxBEzjuiFTa9/vLYduiUS1h9 z5LSt9u3NagQrEAigfcxksk5UirCyUgGj1/RnwEgiysJ3B8TW0VJnABivxrs8JBw SfYOJZW3bfXXBoRvrwac3pKj36lXfwDRyDYKrXeYL6TB1O3+iBv9XX5/sHoMeh7g uc5ZE6hNjrqeZhkyrW2Z6Iq3irTpBmDQrgarpGGenKZ/THJCn/whY7MFVb8hic+P HjSy9U3dNrrDa59leAhA7tZpKTwYPKn/D1zk6+h0EpIyWV6lhDs= =3xyV -----END PGP SIGNATURE----- --Otv9avpGPrERzERK-- From nobody Sun Jan 23 10:36:29 2022 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 339C41981444 for ; Sun, 23 Jan 2022 10:36:44 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JhV0W3LTBz4gH0 for ; Sun, 23 Jan 2022 10:36:43 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-lf1-x136.google.com with SMTP id a28so13221951lfl.7 for ; Sun, 23 Jan 2022 02:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=HOnQHSQ+7K62O3Q1wNsrJybIA3AsPYRcy56OpiukEl8=; b=zAEQrWKr/pbMU9UR3sncZ6Zcvv0TYRVpHnqATYKxDevW/8mQsj1kpceqWch6g7EbDE iM/wO4cwRf5tElvOX3eggibEdtMk57mE0jiB+T34qIO3ifPahjIo6khoVOIWlagTPb/L IUJIsukHi5rDKkTWjpZgvIw0FUVIVdx0V02AkiXugvJQFIDm/WKtvXS57FZsLeEirms8 SmQ7ikdTP+7Vr65I1LKpmQc7bbxaKe3eNpu34cmZ79fX5LgUZP7MOx5lUNOV25y1Zsnu eFBmjYBUj0U2xNaZjkcYui1NWsq9nx1Ej40IvVA3HLB6nBSwQ4dx2rwQNhIhQPVUwYi3 OsMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HOnQHSQ+7K62O3Q1wNsrJybIA3AsPYRcy56OpiukEl8=; b=ibipGp8GeQw/6686UqsA/Bfwx/n2OqOYmE48LvykOZFR247Tn1AbyLY5GqKRH2uSt6 IxvQ3x05qvX3c98hPQd2bYtkx6/OM/ArrwM+zMTR8L9DUZPOX9UOXQkC6aBi+UTV+PSc saSY20WKFWD8EVOBQXw4KqLAcStAAm45K3zXs9ZU2klgaVd5X40emHGIgJygs3f/5ISk UEUBG/FCnqUZF8eJae1f/A9UwW4XQLmPEwCwtAIR4q9N435Q+S9GMqYdYs5LqGI6L/nt x8HgCFet7Mro3/TmY67/rFKeI4hBLC8q1BX5J21wlnEnrH7V8OOQSG9KhJIkkSPNta9K loHQ== X-Gm-Message-State: AOAM530/SXFbqNyR2bmfW3uiBdcCjtsppWBnQpPMyrsKFK/wb7zH6/M4 wNAVC+MH1LRyGfBsJlBfjCrMVR4fjB090ItGKUKAubXeGohUJQ== X-Google-Smtp-Source: ABdhPJxRgZsAAOOM1k+FaWFUKAEuhpm8TbuvDALsuoncrDfX5c/Ensi7h9KZ2tE+/G8hlxKt9oCR60u7zVxGB+qpV1s= X-Received: by 2002:a05:6512:108b:: with SMTP id j11mr10041909lfg.428.1642934201460; Sun, 23 Jan 2022 02:36:41 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Marcin Wojtas Date: Sun, 23 Jan 2022 11:36:29 +0100 Message-ID: Subject: HEADS-UP: PIE enabled by default on stable/13 To: freebsd-current Content-Type: multipart/alternative; boundary="00000000000077bb5505d63d6d3d" X-Rspamd-Queue-Id: 4JhV0W3LTBz4gH0 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=zAEQrWKr; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2a00:1450:4864:20::136) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [2.70 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[semihalf-com.20210112.gappssmtp.com:s=20210112]; FREEFALL_USER(0.00)[mw]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.995]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20210112.gappssmtp.com:+]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::136:from]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000077bb5505d63d6d3d Content-Type: text/plain; charset="UTF-8" Hi, As of 396e9f259d962 the base system binaries are now built as position-independent executable (PIE) by default, for 64-bit architectures. Thanks to that enabling ASLR can be done simply by sysctls knobs when booting the kernel. If you track stable/13 and normally build WITHOUT_CLEAN you'll need to do one initial clean build -- either run `make cleanworld` or set WITH_CLEAN=yes. The change is a pure MFC of the changes integrated to -CURRENT early 2021 and no issues are expected, but in case any problems are observed, please issue a PR and/or let me know in this thread. Best regards, Marcin --00000000000077bb5505d63d6d3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

As of=C2=A0396e9f259d962 the base s= ystem binaries are now built as position-independent executable (PIE) by de= fault, for 64-bit architectures. Thanks to that enabling ASLR can be done s= imply
by sysctls knobs when booting the kernel.

If you track stable/13 and normally build WITHOUT_CLEAN you'll ne= ed to do one initial clean build -- either run `make cleanworld` or set WIT= H_CLEAN=3Dyes.

The change is a pure MFC of the= changes integrated to -CURRENT early 2021 and no issues are expected, but = in case any problems are observed, please issue a PR and/or let me know in = this thread.

Best regards,
Marcin<= /div>
--00000000000077bb5505d63d6d3d-- From nobody Sun Jan 23 19:38:09 2022 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 E2A001975F06; Sun, 23 Jan 2022 19:38:16 +0000 (UTC) (envelope-from fluffy@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jhk1N4T9Jz3klf; Sun, 23 Jan 2022 19:38:16 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642966696; 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=RB1RYEYLpNEAoAw0Jo9G1BKqQjAAB6E7u/hL6CR1GQ0=; b=dhsCu/cFbgtLUgb5UdPJxm6dDiQHVo4AKp6buPpQzeWSCX/UhdZDW0Lg51p3w7dnoI2Bzm XxhmzVB3G4zG6LgCNJiJ4/4Q+U22kZ3b/ZSDnq1bjcUwCgIrE7Ho52R7FRfdTTVaXHxFCF TJjzErFFuLjtTOoPJAw1HYgx4PYBZBbvIUUeyClNEmX1JsO4XrBnj4d0cBJDWX7JCkzY4d 7+yUWrcJKZ7g+/zXD5+iNfCGM/tNCDjTk6MOUjnAN3rt6VEzkuze4ZhMRRrwUgkfud8gUq jy6fwnjzrmQZDh6fgVCihOvcC48WZuu9zEN2A1VtwnYQ3tHRTKt5gb6IKoMMsQ== Received: from [10.100.224.144] (unknown [5.101.143.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fluffy) by smtp.freebsd.org (Postfix) with ESMTPSA id BFB9D25C9C; Sun, 23 Jan 2022 19:38:14 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) Date: Sun, 23 Jan 2022 22:38:09 +0300 From: Dima Panov To: freebsd-current@freebsd.org, tech-lists , freebsd-arm@freebsd.org Message-ID: In-Reply-To: References: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> Subject: Re: POLLHUP detected on devd socket List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="61edaea1_12200854_7d7d"; protocol="application/pgp-signature" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642966696; 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=RB1RYEYLpNEAoAw0Jo9G1BKqQjAAB6E7u/hL6CR1GQ0=; b=Fjxopk/iEuMKFWqrjX+QHoODV/SBTXNA/38x6DdOGxcbmFqspuVbaEGWaMS5qEmcvxrXdu hiZKGfiPUOa8daSE540Cs+gdzY8+KjjVNFRedWp6Gsb6GRcjkBTtJlrgwxleQYhZxLoqML Q2YY+AnnUDFzKdYb/QlWpmVKHgZ6noiAIEvcLPtk6mEO1UTdGvaIJoGyUJmSUyPYQwM1/D ZCYTNfjIELDkrhHey6t6RfOwjp4LiEGuakBeJfWAr7/rlmgbcXOGYcN3HYXRv4kEEdYNQf q5RpREltb3Ue4z2nBZtDyGgiB5l3Vg3CpCmHJoRzUBZw9536KocHUmVi23Z3Cw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642966696; a=rsa-sha256; cv=none; b=qTew6g2T733lhmRZdR+8izhWb/RR8uHphAP3R1i8HwUn5Y7E5JRKn0ewRhag7BcKz9fd+F 1T/LwO3ResxMoxCj23cqRAuR9qTbal64Pv/cQur2QrtLdEI1oLxVGF5wnTNBHD1/vLvDHp L/0p7IBzKJxz2WfA8GM1UgWRa/c5hXv1HM+wkOFuMbZfH8WQYaMMlh1lriUR8tWK9OePhO ajuujRDS/Z8zOguRts3cUgcQkzPZEO8Q3ylVovd9rfwNRvaycFJfGYCMdZ4s6LOSEq8mZC 1ivjSamghgjwDPPgRg2fAzV5fk1ouWzzqzy9ZZ+CKa4Y9nQBL8SwysHWzoYlSA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --61edaea1_12200854_7d7d Content-Type: multipart/alternative; boundary="61edaea1_5bd062c2_7d7d" --61edaea1_5bd062c2_7d7d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Moin=21 I saw a such issue on amd64, both 13.0-RELEASE and -CURRENT. Both hosts have zfsd enabled, and after devd die by signal 15 all other d= aemons such as sshd, crond, syslogd (almost all runned daemons) stopeed b= y signal 15 too. At least, as it shows by system logs. Will try to play with zfsd disabled, as suggested. -- Dima. (desktop, kde, x11, office, ports-secteam)=40=46reeBSD team (fluffy=40=46reeBSD.org, https://t.me/dima=5Fpanov) > On Sunday, Jan 23, 2022 at 12:03 PM, tech-lists wrote: > On Sun, Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote: > > > Is it reproducible=3F ie can you trigger it post boot=3F > > > > It is very strange that devd dying would kill anything else running -= > > I have stopped and started it a lot while testing devd scripts and > > I haven't seen anything else break. > > > > One idea would be to hack up devd's rc.d script and run it under > > ktrace and try and get some clues. > > I can try that, thanks for the suggestion. > > Right now I'm thinking it's tied to zfsd, since disabling that > service I've not seen the issue. > -- > J. --61edaea1_5bd062c2_7d7d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <= meta name=3D=22viewport=22 content=3D=22width=3Ddevice-width, initial-sca= le=3D1.0, user-scalable=3Dno=22> 3D=22=22
Moin=21


I saw a s= uch issue on amd64, both 13.0-RELEASE and -CURRENT.=C2=A0
Both = hosts have zfsd enabled, and after devd die by signal 15 all other daemon= s such as sshd, crond, syslogd (almost all runned daemons) stopeed by sig= nal 15 too. At least, as it shows by system logs.

Will try to play with zfsd disabled, as suggested.

--
Dima. (desktop, kde, x11, office, ports-secteam)=40= =46reeBSD team
(fluffy=40=46reeBSD.org, https://t.me/dima=5Fpan= ov)

On Sunday, J= an 23, 2022 at 12:03 PM, tech-lists <tech-lists=40zyxst.net> wrote:
On Sun,= Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote:

Is it reproducible=3F ie can you trigger it post = boot=3F

It is very strange that devd dying would kill anything e= lse running -
I have stopped and started it a lot while testing devd = scripts and
I haven't seen anything else break.

One idea wou= ld be to hack up devd's rc.d script and run it under
ktrace and try a= nd get some clues.

I can try that, thanks for the s= uggestion.

Right now I'm thinking it's tied to zfsd, since disab= ling that
service I've not seen the issue.
--
J.
<= /div> --61edaea1_5bd062c2_7d7d-- --61edaea1_12200854_7d7d Content-Type: application/pgp-signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: Canary PGP V3 iQJVBAABCgA/OBxEaW1hIFBhbm92IChGcmVlQlNELk9SRyBDb21taXR0ZXIpIDxm bHVmZnlARnJlZUJTRC5PUkc+BQJh7a6hAAoJEPuLoJ3VOY8peNgP/R0jq+eWgHaU dqZOuRE98wTHP+oEI+Zb0MhSkOFQ/NTHsCDZcLjt6Gt8S/U6pDFAY5gGtHSFXINP vQjiFjVjh5pOiDisInXEzJxIojgoC/Lws3OwTWFgmjVCyG4dre/MxquJv7r3CxSZ Sk4jfhX1nfg0+WsRaVQyOuet/hcrA/AiIfjiFcBhkk1Y5S9rwUcARJyN5s3vS4lc knuKMZHPAKXVPWLKXfV+8sKuUTr4Lkvsv4omXgV2oi+B1eWPaUzmdr9sLjRXohG4 fJojDT1/Di4Ak8I4pqBM1jUfduCxRrkHYa/D50pd4JIL2BAG1xubTpjBLjkAP//f 7VwONwUMuiJGpJCZDrXXHh4NrnTvwTsueotqLWTOL69Kzsw00HuXFEA7G9ITxNp6 tKQyGToOT0qqp4qRbqfIZnb15PsEBv3w3ZY/RgL56BaZe/QHNvb9erF0RpHd1fKk SQA7I+YlAIbQ9BT0WAaIRFvPma7UeMq7GmvyiBOIJJkovwpKlqReK8XqJxF3ddC7 PYaMPIeQ3Ecb1N3sSE/yIudMFKNQ5hb611o36Wo6nprCt5tnrhoRMtKZ5cJuPiVS PHtrYKnF6ixdL6WLzEsaukmYxoZKPZNXkeYTCmltppBUhTVYb4F5cmig7IVgxokP G30/gY/RYXXs1dY1HI0B1U1FTl6d6OvN =OZ4V -----END PGP SIGNATURE----- --61edaea1_12200854_7d7d-- From nobody Sun Jan 23 20:02:26 2022 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 68FB41984321; Sun, 23 Jan 2022 20:02:30 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JhkYL2Dhpz4cNW; Sun, 23 Jan 2022 20:02:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642968150; 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=JgFRS6huPO4FtmiAp6oABiEwlZduhCaF4Oe5SJQli9s=; b=d7ERgE6HRF95rFRvN7dZj6pto3t3/qmGBZfwKRiXZfCKaDPy5Mq0vdLiRUDUOOdqtGjxIC GNu/kiPK5UF/e81e+KU84rSD5VQOadWmV0rPY9gtyHYpJ5TCNOJTsGYq0lE09fuu8GQkbS Qtqo7OT68Tbp02Po712kDWsjz/RpiztrAfooWZ0XrTyHD5YlZWqsPclaL+pR4xXgeUlzyg Gd8maiMQEIqXGbBW5HITuz6AtqEREzkNG++ZPZj8KfN9ZVDfTXz/PkZqPx7PGQ7JSak+lQ Oy6+QeBPpIYN8v5qcrjGuihS+ZG2DzgBVFOQ9nZGZ3zsjhStVxKiKs2DJATTMw== Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 81FBA25DED; Sun, 23 Jan 2022 20:02:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <5e436448-7ab7-8d10-011c-e4e52cbb53aa@FreeBSD.org> Date: Sun, 23 Jan 2022 22:02:26 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.0 Subject: Re: POLLHUP detected on devd socket Content-Language: en-US To: Daniel O'Connor , tech-lists Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> From: Andriy Gapon In-Reply-To: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642968150; 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=JgFRS6huPO4FtmiAp6oABiEwlZduhCaF4Oe5SJQli9s=; b=HVs56aPo1hYFkWRvDExyMH480DQgQdCy7aZzUz2f2ZJbPlfL+w7t737wqkJe6LsETgpv+N 04RlWIzGmS2VlgJoTB9Bt259uz1MO3fO3nzgjjrIH3x5XZp/slS7JtsnTmpdnPlVHpKNXa izE279mYhoNblrE4vgZ6bqf94zqKxfedHzUUUXizt/S1IU7PZb3IeI7bZ4Y8C9FpqOJPZA 1NmJ6onBztIISMCtJrS/hCmJ5TkGdk+30f/SIfIfdpghsucLxguiZGXsHQbitxl+A7UUPA rxNHyMblBgPRSkMi0ckDpZ0TzVUe+cUPw5tTNIpNwIMjWu/NohBFG509mPWLIQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642968150; a=rsa-sha256; cv=none; b=Nz8J7L1p1Mq4NTXe+YJszrzZFVH7wt1uKYYoPC49Il1ksvNqQu8mCDqdgvj+Mbo8cJ9inb vvtkvTL9hFx4FWbSO65aXfGhS1vvaafiHMjVxuusWNUHkbqpjHeU+GsAX7SWzBbn3yakSL 9a8AO5JXuiiOn2CSMUC9Je/Ps4kqsdnxgU5aA5k4VpSKjcmXFa8TJsCNq2YIpRodQtfHgp gwBLMKTBafuAmmqrMfMpxZ+ytRcoC0FG7WHBE6HOoqZ8E+9ium8SMC9Omf7KM789gLb2tl 6Etx17DNiu53NTy3x9QmkftVoeu8/6N9Q6L3OOZt2Vz8XWfO1t+k/vZ2B5FkBg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 23/01/2022 07:40, Daniel O'Connor wrote: > It is very strange that devd dying would kill anything else running Because most likely it's a correlation, not causation. Many things die and among them devd. -- Andriy Gapon From nobody Sun Jan 23 23:58:27 2022 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 81771196877D for ; Sun, 23 Jan 2022 23:58:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jhqnp5V1lz3lrn for ; Sun, 23 Jan 2022 23:58:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92a.google.com with SMTP id m90so27842920uam.2 for ; Sun, 23 Jan 2022 15:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nFj+MsrS32BMYy5lHIifMDiR1PbQCF1epl53KH6sjXQ=; b=lnNeEInd6WFw8M8FA3KfCDUN33GDQ7rANX8oMmlJmahWo3QZMR+XSl4WNyjWTJib5d QwN4WPrS/3kmHcC2aJZO0GM/X8btE1KDNvKJFo9UuevciTMjwm69GFH0qjfvKSqbGWB8 rRH3AjVuMbes4b81dO/xlrLXupJqh/QLNQP/MIVL4Td3Ku/HKV+oOfCxTkdI0sFucUbf UcWybe8qfGi1QMucu5nFrmvOwejy+OWe9bzejXFGbFSmV6ubAtpCctoX5uFX2Jwp/G6X QJ+hAbtv2k3m9X62SgOUJw2K9+9YjkEOwofP3ZhQWt2b8cvENnmi8+p7+L7H81cMb590 OOeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nFj+MsrS32BMYy5lHIifMDiR1PbQCF1epl53KH6sjXQ=; b=A1g/jrCfB5ibl455qU/i3ExXiMTMWyozwlvbdixobMCWKmsGmdCG16c6qIlp9hIY4B VW4A44seHcM4BhVXxdGgf1HsVSETqs3g5krEHedqQ56dt9AuiVdXzcRTupXehjTeHfh+ jDbBs4s/gRiesByZaVEHDnEbtEPOEip0yTMQufO6DQBhx9a3ZJtSXEn1yHtzG0uM1Ey6 gy3crkoemBIVz+A8V5bLpBe4mmXojI6jgfCXWETcSLuc/MHtayjvcWsa4dEoDac3+0QV QuWi+XSBbHrF3xia8FedFpuYfvpGrdDPGjKX42mV+Ik1z/qp117xfN3z2sBxqFfS2aZw 7toA== X-Gm-Message-State: AOAM531HiqnW1ZJZCw7Ne6UcyvAPmk43i6x79orYu1z5euCw9C58UtVu 4Z5ISSy9FtoHxSHS/Bf0qoWZLtsURJMy0vzMO0yQqfiCE4w= X-Google-Smtp-Source: ABdhPJwj9JmLz4cZYeJmi7VTPB42pVh6iCIf3+Ku9IZd+ymOtngUCKcUMaR47WaKi4+j7pc1eXbEJuR7oHOSQKnXNWM= X-Received: by 2002:ab0:23c1:: with SMTP id c1mr4535539uan.11.1642982317823; Sun, 23 Jan 2022 15:58:37 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> In-Reply-To: From: Warner Losh Date: Sun, 23 Jan 2022 16:58:27 -0700 Message-ID: Subject: Re: POLLHUP detected on devd socket To: Dima Panov Cc: FreeBSD Current , tech-lists , "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000006d2b8105d648a136" X-Rspamd-Queue-Id: 4Jhqnp5V1lz3lrn X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=lnNeEInd; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92a) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.83 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.83)[-0.828]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92a:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000006d2b8105d648a136 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 23, 2022 at 1:07 PM Dima Panov wrote: > Moin! > > > I saw a such issue on amd64, both 13.0-RELEASE and -CURRENT. > Both hosts have zfsd enabled, and after devd die by signal 15 all other > daemons such as sshd, crond, syslogd (almost all runned daemons) stopeed by > signal 15 too. At least, as it shows by system logs. > Signal 15 is SIGTERM, which is the software signal from kill(1).... Warner > Will try to play with zfsd disabled, as suggested. > > -- > Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team > (fluffy@FreeBSD.org, https://t.me/dima_panov) > > On Sunday, Jan 23, 2022 at 12:03 PM, tech-lists > wrote: > On Sun, Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote: > > Is it reproducible? ie can you trigger it post boot? > > It is very strange that devd dying would kill anything else running - > I have stopped and started it a lot while testing devd scripts and > I haven't seen anything else break. > > One idea would be to hack up devd's rc.d script and run it under > ktrace and try and get some clues. > > > I can try that, thanks for the suggestion. > > Right now I'm thinking it's tied to zfsd, since disabling that > service I've not seen the issue. > -- > J. > > --0000000000006d2b8105d648a136 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 23, 2022 at 1:07 PM Dima = Panov <fluffy@freebsd.org> = wrote:
3D""<= div id=3D"gmail-m_5433901728503372578CanaryBody">
Moin!

I saw a such issue on amd64, both 13.0-RELEASE a= nd -CURRENT.=C2=A0
Both hosts have zfsd enabled, and after devd d= ie by signal 15 all other daemons such as sshd, crond, syslogd (almost all = runned daemons) stopeed by signal 15 too. At least, as it shows by system l= ogs.

Signal 15 is SIGTERM= , which is the software signal from kill(1)....

Warner
=C2=A0
=
Will try to play wit= h zfsd disabled, as suggested.

--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team<= /div>
(fluffy@FreeBSD.org, https://t.me/dima_panov)

=
On Sun= day, Jan 23, 2022 at 12:03 PM, tech-lists <tech-lists@zyxst.net> wrote:
=
On Sun, Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote: <= br>
Is it reproducible? ie can you trigger it= post boot?

It is very strange that devd dying would kill anything= else running -
I have stopped and started it a lot while testing devd = scripts and
I haven't seen anything else break.

One idea w= ould be to hack up devd's rc.d script and run it under
ktrace and t= ry and get some clues.

I can try that, thanks for the= suggestion.

Right now I'm thinking it's tied to zfsd, sin= ce disabling that
service I've not seen the issue.
--
J.
--0000000000006d2b8105d648a136-- From nobody Mon Jan 24 06:42:19 2022 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 C7947198798B for ; Mon, 24 Jan 2022 06:42:32 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jj0lq6nsHz4nx3 for ; Mon, 24 Jan 2022 06:42:31 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-lf1-x129.google.com with SMTP id x11so47146368lfa.2 for ; Sun, 23 Jan 2022 22:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ijuWut4geqPKPh/8WkxUN3qXWdscKvBN040o1zbaDQs=; b=1KOjjHbfJmunyepNjQ7J5fruxayYmP9RSq0aDb8IqqR5gBry8UJTRE1vVjuZy+a9tB AaMXi6WCnd+8OWTYSE7pliO44u2Rum5NNUpQ5nHbtavppzEyr0/7pUB9CCmN/IjkfAEW ombiUTzY7EprIhN4HSFO7aGI0GwhYZHBYfYsw4BUXGDQSA7NEYcj9GvrxEP9Kd7gPZFK c/Hb7VvI98o0bENYoJ8Lqj1cWbAtLOWLW/RCuCCgf5G7Mr0vKiKFqctw1z9SApwbfJ+k 7BfxU/c2ZNEfZXWtxKruC8WlQ2eOQX162NPiDKDjLAxeZG4PN3TcyZF2VUy995kAJV7m 3mLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ijuWut4geqPKPh/8WkxUN3qXWdscKvBN040o1zbaDQs=; b=CVMV37S3vQIrvmlqUlZAwwKDs4BoFaLwa2BubD8njbIdCRHVUz/3kt0gwnPvVVNJf+ WnPj0R4RANDH0JEyHt+RRiq0DZpie8sN+K2iaIKR0mDg/yJQsF/aLSd7Z27OdfpTGzgY qeoEhXSLSHCEnae20dTfFr7ZOFFw0zj07K6dCQX0SPnIiHW/cIxI9X4k7CYbZtfS6O5m VOeNrq9zk1Xsbv3LntVyc0olveCBDxVJpQRxJHzMs+L2B+6jNDqz92FBWCnmecVsExW5 TY4QnUNXQaAnzT7bopnnZiq4T46418/Ye+nYGgaI4nOX0ALdfjAE/ORjrakSPTN5Q16Q ZtBQ== X-Gm-Message-State: AOAM5320i8of3IYkjsfSFPh7ycFU8eFkZ95kzFFyresyQ5ez89RIl4f3 I6hTW7hazwl7nSMr0SeIB7H2v3SEgFose0Nex0yNn8yy5LU= X-Google-Smtp-Source: ABdhPJz6PD80glr+e6CJ8BOiUOpjGrH4CYgt821mTmsWOvrViQuqgzwrLCz8Bp6liMjzp9g6kdSSc0nKh8JP7lopahc= X-Received: by 2002:a05:6512:785:: with SMTP id x5mr10580349lfr.614.1643006550363; Sun, 23 Jan 2022 22:42:30 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Marcin Wojtas Date: Mon, 24 Jan 2022 07:42:19 +0100 Message-ID: Subject: Re: HEADS-UP: PIE enabled by default on stable/13 To: freebsd-stable@freebsd.org Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Jj0lq6nsHz4nx3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=1KOjjHbf; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2a00:1450:4864:20::129) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [0.70 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[semihalf-com.20210112.gappssmtp.com:s=20210112]; FREEFALL_USER(0.00)[mw]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::129:from]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N +freebsd-stable@ niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisa=C5=82(a)= : > > Hi, > > As of 396e9f259d962 the base system binaries are now built as position-in= dependent executable (PIE) by default, for 64-bit architectures. Thanks to = that enabling ASLR can be done simply > by sysctls knobs when booting the kernel. > > If you track stable/13 and normally build WITHOUT_CLEAN you'll need to do= one initial clean build -- either run `make cleanworld` or set WITH_CLEAN= =3Dyes. > > The change is a pure MFC of the changes integrated to -CURRENT early 2021= and no issues are expected, but in case any problems are observed, please = issue a PR and/or let me know in this thread. > > Best regards, > Marcin From nobody Mon Jan 24 07:04:04 2022 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 11F0A19752DD for ; Mon, 24 Jan 2022 07:04:17 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jj1Dw2MdSz3DNj for ; Mon, 24 Jan 2022 07:04:16 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-lf1-x12a.google.com with SMTP id n8so6803067lfq.4 for ; Sun, 23 Jan 2022 23:04:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=w1kYVJL+0q84qKHnwq8eTXceqJelsJkQAwHb5Vi5JYc=; b=xOukJNMr2eiooydp9w2lTyztp+xm+1xkpGwzjTkptYD24fQuQrcgoE0Poz7JQNNoh6 xaBA8hCCUeAUtLhCKN7GmNqC+RpakDgHnlY0C9OYNPfhEDUqa/K78F28NuHEzeqjkwsQ 3kvPzIIq8NGRng5b5SA7dsfhMwjiVxcB0QjMT1tIuXkzM9K8LwIeTbXRVrXVlyOkLuHx 0zeeFN2vXCLoklG0cBqs9xzrwZiATV4dPgciReafCub/ZdKovVEFjQ60Pp0V5DkwT/AH IQgh4MkAbQLSo685OIGdA+7Q6E28WoDV/uo8kxA9Rtd8BlQ/Nai7ZSn7F2krviAgV8IM HdHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=w1kYVJL+0q84qKHnwq8eTXceqJelsJkQAwHb5Vi5JYc=; b=InXUjrXqq53KUaBq4WKDABJcJOfH7zxkLJTTxAkzodR4UcyglI1chIcHTfBtjg7Acu EtI87h2jtFsrYtjSo1m8PRtadFwyc2+y0EBv08tPSDzuigBEbYOGrystDALBS1J0QnP0 cSWyMCZt9hiHW0ywEoNfb9O+k/EV+kSVmIgdqGJOzYC2UxKw3P37pUAViTA7qIkZBI9U dX/8dYEGl/DZPThH2gN2OhkdYlvwTS9R3Y/z758EqjgH7pF8f2nKGyBdP8AGNYkH8ZOt 8I7OaUo/sewSuDT9CkhO5J19pkjctoYynTqDJIWCrXf/zXvL3srDcrzSBtRAvoBCGXSS MV3w== X-Gm-Message-State: AOAM532zISINDYMs51GS5t37YQFuOqSQ6DyInRR9uSIsjoQYyu3D4O1h vs9vb5fWMwG3P4fp6uZrms5TxCX5Q9SkhJLbP4ZYjSWQW6I= X-Google-Smtp-Source: ABdhPJzorzoCMO+o6jmeqBa3VdM7EQr2Oc95amTgkrTFamQOn886pnzH8I8SRWW4+lv1f55JzSZ2rkvJst7URVzxU84= X-Received: by 2002:a05:6512:1103:: with SMTP id l3mr2083952lfg.680.1643007854956; Sun, 23 Jan 2022 23:04:14 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Marcin Wojtas Date: Mon, 24 Jan 2022 08:04:04 +0100 Message-ID: Subject: Re: HEADS-UP: PIE enabled by default on stable/13 To: freebsd-current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Jj1Dw2MdSz3DNj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=xOukJNMr; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2a00:1450:4864:20::12a) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [0.69 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[semihalf-com.20210112.gappssmtp.com:s=20210112]; FREEFALL_USER(0.00)[mw]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.994]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12a:from]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N + freebsd-stable@, apologies for the noise. niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisa=C5=82(a)= : > > Hi, > > As of 396e9f259d962 the base system binaries are now built as position-in= dependent executable (PIE) by default, for 64-bit architectures. Thanks to = that enabling ASLR can be done simply > by sysctls knobs when booting the kernel. > > If you track stable/13 and normally build WITHOUT_CLEAN you'll need to do= one initial clean build -- either run `make cleanworld` or set WITH_CLEAN= =3Dyes. > > The change is a pure MFC of the changes integrated to -CURRENT early 2021= and no issues are expected, but in case any problems are observed, please = issue a PR and/or let me know in this thread. > > Best regards, > Marcin From nobody Mon Jan 24 07:16:09 2022 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 A6FC2197DC82 for ; Mon, 24 Jan 2022 07:16:21 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jj1Vr2x5Jz3L70 for ; Mon, 24 Jan 2022 07:16:20 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 20O7GAf0077623 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 24 Jan 2022 08:16:10 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1643008570; bh=St6h8TaoAjW7Gc8nvS77blpmLl8xO27iCVVLytgMiEY=; h=Date:Subject:To:References:From:In-Reply-To; b=elRnDiFxMQZJgqWsRZeMmrZTh+j/lMvDubwaGToi4exRt80JTHdKbhTDxDdWg6Yv+ PTqO+j/4Y60RdPsHLJRadLnXAQhx4rdN8XrFkNkfFXGOY8pZ1ILeSBqc+flIpl6ZYU mNA0jAEwggnEAY0cfSdu68799+h/cZxjUowTEHEMrKcWmqbv0d8Wl+GHjXBxKwBv7S v+rid4VD4QWIoOCKvEDNuEbuVm4v38kHwc8U1bRWTf/6p+So5WJjbNSZLceKKuI/I+ q8ju18uFEpKAzkBgW9YTzUbSRSQ6/EgUxZaNZjcSqAjtlzbsxYKvAZWumsNDrh2PXn WOVv9fZdC7TkA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: <1ec9c802-c8a5-237a-50a3-31885cae917e@plan-b.pwste.edu.pl> Date: Mon, 24 Jan 2022 08:16:09 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: HEADS-UP: PIE enabled by default on stable/13 Content-Language: pl To: freebsd-current@freebsd.org References: From: Marek Zarychta In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------8zp8v0guiBy01wWt2JzLsv1A" X-Rspamd-Queue-Id: 4Jj1Vr2x5Jz3L70 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=elRnDiFx; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ATTACHMENT(0.00)[]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[0.999]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------8zp8v0guiBy01wWt2JzLsv1A Content-Type: multipart/mixed; boundary="------------yjsKc0YnJfGR0j7FkDahecU3"; protected-headers="v1" From: Marek Zarychta To: freebsd-current@freebsd.org Message-ID: <1ec9c802-c8a5-237a-50a3-31885cae917e@plan-b.pwste.edu.pl> Subject: Re: HEADS-UP: PIE enabled by default on stable/13 References: In-Reply-To: --------------yjsKc0YnJfGR0j7FkDahecU3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VyBkbml1IDI0LjAxLjIwMjIgb8KgMDc6NDIsIE1hcmNpbiBXb2p0YXMgcGlzemU6DQo+ICtm cmVlYnNkLXN0YWJsZUANCj4gDQo+IG5pZWR6LiwgMjMgc3R5IDIwMjIgbyAxMTozNiBNYXJj aW4gV29qdGFzIDxtd0BzZW1paGFsZi5jb20+IG5hcGlzYcWCKGEpOg0KPj4NCj4+IEhpLA0K Pj4NCj4+IEFzIG9mIDM5NmU5ZjI1OWQ5NjIgdGhlIGJhc2Ugc3lzdGVtIGJpbmFyaWVzIGFy ZSBub3cgYnVpbHQgYXMgcG9zaXRpb24taW5kZXBlbmRlbnQgZXhlY3V0YWJsZSAoUElFKSBi eSBkZWZhdWx0LCBmb3IgNjQtYml0IGFyY2hpdGVjdHVyZXMuIFRoYW5rcyB0byB0aGF0IGVu YWJsaW5nIEFTTFIgY2FuIGJlIGRvbmUgc2ltcGx5DQo+PiBieSBzeXNjdGxzIGtub2JzIHdo ZW4gYm9vdGluZyB0aGUga2VybmVsLg0KPj4NCj4+IElmIHlvdSB0cmFjayBzdGFibGUvMTMg YW5kIG5vcm1hbGx5IGJ1aWxkIFdJVEhPVVRfQ0xFQU4geW91J2xsIG5lZWQgdG8gZG8gb25l IGluaXRpYWwgY2xlYW4gYnVpbGQgLS0gZWl0aGVyIHJ1biBgbWFrZSBjbGVhbndvcmxkYCBv ciBzZXQgV0lUSF9DTEVBTj15ZXMuDQo+Pg0KPj4gVGhlIGNoYW5nZSBpcyBhIHB1cmUgTUZD IG9mIHRoZSBjaGFuZ2VzIGludGVncmF0ZWQgdG8gLUNVUlJFTlQgZWFybHkgMjAyMSBhbmQg bm8gaXNzdWVzIGFyZSBleHBlY3RlZCwgYnV0IGluIGNhc2UgYW55IHByb2JsZW1zIGFyZSBv YnNlcnZlZCwgcGxlYXNlIGlzc3VlIGEgUFIgYW5kL29yIGxldCBtZSBrbm93IGluIHRoaXMg dGhyZWFkLg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+IE1hcmNpbg0KPiANCg0KVGhhbmtz IGZvciBlbmFibGluZyB0aGlzLiBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5IHdlIGdv dCBzb21lIA0KaW1wcm92ZW1lbnRzIG1lbnRpb25lZCBoZXJlWzFdIGFuZCBpdCBkb2Vzbid0 IGltcGx5IHRoYXQgQVNMUiBoYXMgdG8gYmUgDQplbmFibGVkLCBlc3BlY2lhbGx5IGtlcm4u ZWxmNjQuYXNsci5waWVfZW5hYmxlIGNhbiBiZSBzdGlsbCBzZXQgdG8gMCA/DQoNCg0KWzFd IGh0dHBzOi8vd3d3Lm1haWwtYXJjaGl2ZS5jb20vZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qu b3JnL21zZzE4MzYwNS5odG1sDQoNCi0tIA0KTWFyZWsgWmFyeWNodGENCg== --------------yjsKc0YnJfGR0j7FkDahecU3-- --------------8zp8v0guiBy01wWt2JzLsv1A Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmHuUjkFAwAAAAAACgkQHZW8vIFppoJb BQf+NLz68MGpeDCHmguJN8xE2on8fOwwrvO64gZVnoa/mqb+9XYrT9p8PtT1PtAuj8Nkz054n7MO a85dCgYkTPQwHioMlrArKrO/bZ32drTylt0juXzClW8YXv6tLnjj9y+g+dMKyS8V9DOs+NkXsasZ ihycro5Y5cevPsInBOZ1JCVJxSFYGnr1q7iCOmQtTfFB7FbZUHhx5tQ6N5rIYCDEGQdB3JkuZ8N0 z9J0IrXOREdOgGdhlkHUB+HiJTgt2MCINsRHN1nCkLMq08ef3dEh5jPUJcviaxMCu/lCbkVG059s BeDGY8XnebFWA1zxWrVMBPajv0zJCypkkmBLVivmnA== =9Ry1 -----END PGP SIGNATURE----- --------------8zp8v0guiBy01wWt2JzLsv1A-- From nobody Mon Jan 24 10:16:17 2022 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 87AE31986635 for ; Mon, 24 Jan 2022 10:16:20 +0000 (UTC) (envelope-from theraven@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jj5VX2KdVz3nfK for ; Mon, 24 Jan 2022 10:16:20 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643019380; 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=yITgKmf18YeJsc3r0R24Mm7xpOcIgqmE6GefWedk11c=; b=oHJbwv6NF78Rh8hPqnrC+AZAlXdXdm6U4ueDJJUSuGeAtZvh9lViBJ+M83YkXR2ModLAhC kQJ5f0r24we0RQizahL4MQQOk6rgPy4pTq5sD1hcuekzWYMhIarpO6RCOcSsyB1QV+odro jCVeYX5CnqfabaeIFrinYEFIGrXxdie/Q7J4IxUripW4DZ7YEAwPH3yMqCGPyPQ5isaHU4 kluajNdddozbu9/rVFMsJk33VSdykDDQFTbDAvBGMezCHDUQTGe8jmRX47TGwqcJqztOl3 lHl1p5xYGITgLiZfS5ITR3dWNVF8esnpaptEo93TJ5iPh9LL5cYM533f607KLQ== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 2A3842D1AE for ; Mon, 24 Jan 2022 10:16:20 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 360772EC90 for ; Mon, 24 Jan 2022 10:16:19 +0000 (GMT) Message-ID: <489849ca-a404-fb54-81d1-d62ea18c5832@FreeBSD.org> Date: Mon, 24 Jan 2022 10:16:17 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 Content-Language: en-GB To: freebsd-current@freebsd.org References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz> <54704b99-7b89-76a4-0368-79bee391926d@quip.cz> From: David Chisnall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643019380; 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=yITgKmf18YeJsc3r0R24Mm7xpOcIgqmE6GefWedk11c=; b=xE8iZM8IJZIuBtkheDmqrXqw8BofOf6RS95tlj13b1YaZnpE+tF5HIRVtNl+kS3RAwIxev s5a1IzANYirfF3dhDB8EjarzGMkE0rznLd9vjXLsAJCe9PfPOxRPA7BzQ5YXAdIT2NyTwu JTWiINLezI82T2/ZC9dl9LGwftFR/6hYci1d/zZW2DNAqqc7dv7ZlwnnHX/2HArjhWsxax NvkgBjeFOvxIxYoFbk8NTQhkqlmNfxjqRNTT6IFtKb5hAQAOuH927ybnvL5SzCev4WCKYT ApQibjYH0JN4LKZmlW50jI2jIVP+T1GRvk0XXJoui7QfhuNYFpoS73/RfTvLdA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643019380; a=rsa-sha256; cv=none; b=wWGWOrp3Cc5cSr/DxabMotrxUlPSK53mXZpUBIuRSp0Qo8ySjnIbEbzWmPauz9v0rqeDeR uGRg056j4FN+SbeU9rgenhRJYhsuu8miO5yBMf+dNKfUG1FqAj5v8OJC/Pwd/ZcUV2CaNY Yhh+mcR+vjGr2sSgCpExGJewVhMwFZygTSeI9VtVPMOwCyEVJr/NElz5Kw1O/JNQuRZ9ww bA8Hoyi26yJV+E/zxpKQInCRAnI8fZXhChZ6ft/t6ZlC03TrRM0VDb5rIPa7wyM5ZKaiL1 FgWA8Ju/5YYS+eWmu6lVs2QH7k+kVq8UuuMv9GAjaD41s/rFlIiS9rqjHFpi1A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 22/01/2022 23:20, Rick Macklem wrote: > Mark Saad wrote: > [stuff snipped] >> So I am looking at the Apple and Solaris code, provided by rick. I am not >> sure if the illumos code provides SMB2 support. They based the solaris >> code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure >> predates smb2 . >> >> https://github.com/apple-oss-distributions/smb/tree/smb-217.19 >> >> If I am following this correctly we need to look at Apple's smb client >> from OSX 10.9 which is where I start to see bits about smb2 >> >> https://github.com/apple-oss-distributions/smb/tree/smb-697.95.1/kernel/netsmb >> >> This is also where this stuff starts to look less and less like FreeBSD . >> Let me ask some of the illumos people I know to see if there is >> anything they can point to. > Yes. Please do so. I saw the "old" calls fo things like open and the > new ntcreate version, so I assumed that was the newer SMB. > If it is not, there is no reason to port it. > > The new Apple code is a monster. 10x the lines of C and a lot of > weird stuff that looks Apple specific. > > It might actually be easier to write SMBv2 from the spec than port > the Apple stuff. > --> I'll try and look at whatever Microsoft publishes w.r.t. SMBv2/3. > > Thanks for looking at this, rick The docs are public: https://docs.microsoft.com/en-gb/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962 Note that the spec is 480 pages, it is not a trivial protocol to implement from scratch. David From nobody Mon Jan 24 15:13:32 2022 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 9C7CE196B146 for ; Mon, 24 Jan 2022 15:13:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660059.outbound.protection.outlook.com [40.107.66.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JjD5b3fjhz3vV0; Mon, 24 Jan 2022 15:13:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gf8DvSOqxgSMBEIYMA5NyWU6ImIpKV/MpTNRSp0oHUE0ZpKYoxJQkPW40DgSxW4EQtbc5hcjBC278z5lEUhlpqyyPjMMTPKfG4Uc66ZjVLy528ROaSFW0Nt4NJ/5tg4ERwOwE5/h5mBj0vh814umJQMY1kr6sgLxNI5VtAk1F+oKl7/7UCoNoHCGXBDccrDQiBg9aZwpyipnvfeKujslCtpbxvEkpf/R2TFIZ8SBPWyJ+lf52Nljlmnb7md+71GPEZ1aNcNJ5YMjFrbGTqnvgceoZsAU6l6FYOCRgcDeLDNUn9p6PNp4zFWccHB/ryt3kAYYOeRkUbjEPQEw0PbpEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=33BcEUL94kUyJKGDZfMWCYFy0JMfdiPD6Y53go9lE7Q=; b=T8aoWJ792v76oBxtxNd6trZksKYJyxZFFYjnR5HkOkktwYEKhfr2FC9QRHoxdenEPwG/mMq3MZnDZAnLFIKQZsBUsyIibzxlwLCEz9E38fNvqlw8dx/SweagC2TqgMunQLImygT11H1a4Oz1QPDdrjIDJTaa5sMR7wcLosT/NhWY1mG3gWi8kEU1F7Zn6AAPAjA/nR1XONJ9afiznyWbiKbgHABWtoyTvM2SHbkijlQpTQ6vxh6Uhnh7wwO6EsUnXGMxw+B3wJGkf14+ij5JZm+39GnjYD2fxtngiwjX0XKrFOk6jqX0i/nvs7vXKhrIufssH2FwDfJnyBp9RQWMjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=33BcEUL94kUyJKGDZfMWCYFy0JMfdiPD6Y53go9lE7Q=; b=QEHgXcondQ/aQgc+oJrCh450KTNYA2SFCht29pB0dZZT5lsmVBeSoz7qCZwYvlSQMJPZatqp/+ILNlY1OryuQGhIIvt9ZyG4mOY6rqTmEPSVqS47dPRHbWppnWv1ESL/ogFk7/Yz/RMZZA+Xr6fvJ6ijOVSm2J0IJTZrUiubLxc+3t0lzehTs5+LFj5hnGXsgNFfZ6RZ2cYgpqSmh2Rj0xy1i6eVveae0hcwcKwzdwdvE4oKkxfhiHP9bUDg4kKBWWIf8q6jzqBeoUoK5gDlPIiqq7HpsueszK+ouMPZfymUDdRM8xqq+2c5IdbWygHWTGS4bdMHDh0b1WXsu+zDrQ== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB4484.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:1f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.7; Mon, 24 Jan 2022 15:13:32 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7dfe:b92e:1f9f:a196]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7dfe:b92e:1f9f:a196%5]) with mapi id 15.20.4909.017; Mon, 24 Jan 2022 15:13:32 +0000 From: Rick Macklem To: David Chisnall , "freebsd-current@freebsd.org" Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Topic: Deprecating smbfs(5) and removing it before FreeBSD 14 Thread-Index: AQHXzvvFA1WWxQSLW0uUJGavCusr2KvuZUQAgABpl4WAAGcwgIBr+tlBgAGeWQCADnip0IAAAWeAgAA5aNuABGp2gIAAPwEOgAJMtYCAAFF+6Q== Date: Mon, 24 Jan 2022 15:13:32 +0000 Message-ID: References: <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org> <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz> <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz> <54704b99-7b89-76a4-0368-79bee391926d@quip.cz> <489849ca-a404-fb54-81d1-d62ea18c5832@FreeBSD.org> In-Reply-To: <489849ca-a404-fb54-81d1-d62ea18c5832@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: e25856b5-8a66-af1d-bf61-85079b1b0e22 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1c3c4b05-ac12-4595-4112-08d9df4c15a2 x-ms-traffictypediagnostic: YQXPR01MB4484:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WM0fz0hi4f/l8oRAedFMu4HanmrkGRcmBzLBI7KSV3OEAGE0OgbF8YVJSgzLQMbkKBsfnSfAmSqBF9T+5BUUPzIKbnkyR5rc59YnkswG8wQ+ZANLv1Ro/fUPJ2gkMQag/6ha6EjlDKYJUEy64ZCeLd3Z3pwvli6vW3yipv1/oCjAKslTIqgcNzeIY9q/lfEtbzzUHJTI6b59kJ3eDjwqQa6kdLzWuF19sLA5MjbVHNeIuRVe7D2Yp0WNqdH6C9OThr6v0A6fuCGm5HNw6xwz0yWr1aMvME2f/PHaTauRxaHxUb8pAysj5RFGC1QtpEOcevAdSzmvcL2ayaqg62XbiCd157kLVBJqlHCA/p6/I66hZL4g4b+attwZigNqj9S2BcbvrmPnabQfL/1oo0vKXbSAl7taJU+mFVyQZUUNK4guma6CoJam8NWgjH6bp4IFwC3ZoSGhs49NrMxIPsYNsOshCLO8zBwLfrT07PYIUFLXx8u4nKaXUk3+FWcUXFQRBUmmzndY3bkqUkqZ+Lep9v3mVZzucwY7SNSFPR7UuhfkwCg8qSjkCKWLlSlB8iM01qOYwV5iHJeLmt18fCKjz9Eb06JDIX8k2FM0zoco2Got3KVzz3gN1KdNfOaNgDVojuUm8FuAAHWyW+IKD/bcgnr3csSOHvcW9cDaA94VWDPnmBC9e2itThJadZmNa/8lOMk0NDJpr8fBlw+9QDjz/WoZmpD+fEN9QeBju5l/Hbo471xcwmXFwcGsJIyP3U+awDnbYv7GZEXTh3EXZEDRTnSzDIguL+e/Sjui3Grc2EVWFUB3ARFQiEqNCOUQ/RlrDieeYy3pXTupOLrYO2jyRQ== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(508600001)(86362001)(786003)(91956017)(55016003)(6506007)(9686003)(53546011)(5660300002)(316002)(186003)(8936002)(33656002)(45080400002)(110136005)(76116006)(7696005)(450100002)(38070700005)(83380400001)(8676002)(966005)(66476007)(66446008)(66946007)(52536014)(64756008)(71200400001)(38100700002)(2906002)(122000001)(66556008);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?GJGPNRN6kK85SF5XLP4PflzfnnHtRghdZFUIRnOXvVZCRswudvVG8LJsZQ7k?= =?us-ascii?Q?6JLQAoDpVv5p0xI1uUZHRU50cIU49Z8LNOZlR3dQaeYbrHethltJpGcxxL16?= =?us-ascii?Q?3hwSvcwUrsO5vZHCeCMn4qpmZfw7mOZdHb8ITxOpot8QUgfAEpQarGgltD5u?= =?us-ascii?Q?Hxi5SahIdDWHx2p88O/gfbVyizrvrbhurv8DSXjEWJM1NXSsIYplO3Po1dHN?= =?us-ascii?Q?TNc9Ifvqo0TolrMcJOsk9ayUOsXh+8Rrg9oEz9fMOF+B7A0IQaEd4ENr7f+D?= =?us-ascii?Q?8bjipaEFphgHJ69haV7dYDsZop/Lepo/IoJ8NNJuQTf6mkpYVUB0PmiAEpAJ?= =?us-ascii?Q?wsripaemJkGTO5X9xFY+fCuuin5efzeAfY+IBA73mshXDUOboe3gwvkDNIzS?= =?us-ascii?Q?RJ9MysTalfNr0EpSvBw/QD+fDcAqOlSjCjFl31P9+cCxqkhnPG/f+RWRNNs5?= =?us-ascii?Q?NjIlYAho9G87QOEHQkIkp8zXnTxmpk9tDFtO1ZoTRzGzdhW0a8yIAF0zvJB1?= =?us-ascii?Q?LQkCQr2VN/TnG5JblwI98o86th/mX63HAoOjs2/5lj8fuv34Xqb8Vtgteu37?= =?us-ascii?Q?Murj/Q6oW3vXIA3WQxe38H7KE7UHFWXPBK+uD8KAJuPqzoKiH/QW8HX+7aHQ?= =?us-ascii?Q?9kdLPGysybfGlWJn0RS8jTBloukXNZXIyf8jhI8+r2r7LK4Zoup2bhIT3tkI?= =?us-ascii?Q?gN7ERZt28y91B/33Kza0h98weww1ZLCYmFXzkzGfGBsc1nW/O55IZMM/GOek?= =?us-ascii?Q?MmBU2CGXV26QX8oLRYNCNAhB3VX8eenh/RF0ADU3iaL31mSg5O0Vrje8tam6?= =?us-ascii?Q?9kmK2OkQl34XldoI9l6LqZ88ehg5dpdcXmfpdzda7oQSXoXSF16ArFdW/7g7?= =?us-ascii?Q?CCXF7mNdxSwSi0NHDLvZvHc+h7a4CSZyUL0l/rgVt5tzID9mmcnvdwTqkZkm?= =?us-ascii?Q?JI5dWFA69VJWF3UkPq372Sc3V8IfFaDXShWGJ2j/naSAr+hvgOy77SkrqLX1?= =?us-ascii?Q?B3Sq33Oy5LRT8VnmFvQtgKBDoFHReRv5ZQgbPSQQ0Wtz+aUJAEsQA22Xp27q?= =?us-ascii?Q?XDsBlXFyl4rlX8TLMdQD/x9nKQCnmLVc1hCVafkW0DDGQ4U+Dj29Zd8mUShn?= =?us-ascii?Q?PnfTNEn8XdGvCujbuGME5mM8BpWIURC+90xuU/w1I/5TueJoNYs+n/6aRjg6?= =?us-ascii?Q?sMf/8Wo8I6aRoLIdW2QOwUOk81mrG97PerKmi4O+E0iyMGCFcbEsMXRQWBMu?= =?us-ascii?Q?jIKZyMmKk4fcAqSZrQzwSBMfVEHihxuR7+qMLDjdyqkCYGA2OokVuRKBtSTr?= =?us-ascii?Q?ksLrQo/wkDcbm+qqJW9iESictNFVLpEX5wgnJwLQGrgCZXRp1PwPy7z+vbI9?= =?us-ascii?Q?5Xu1DPS+k0nDqNmxgiCiwf2EJkY6G/eBuRJ3N26ZqIVm30D7THuaFZ+P+SnP?= =?us-ascii?Q?WjFXVugv0r2oqDiNmY9hxNiCk4Cyl1nqelG5gP02vFAHPdcXTV1hC37LX0au?= =?us-ascii?Q?5ulJvea4kUAXpVyLcKdGdLwuQTmlW+n9nOpvA/eAFh+QhJqkHTYrc1IZZf8V?= =?us-ascii?Q?fLUKnTwX2LKzT0KWDzOMRrYv5559+Hc9NBBIF1oZ7vR3nxOFHIKlLU3exMW/?= =?us-ascii?Q?se7sC2fBJniyz/W0A0Eshc7371Treu9HtYKzIifJTqvLbIb4PWSs41uoB5Rz?= =?us-ascii?Q?5qomJQ=3D=3D?= 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 1c3c4b05-ac12-4595-4112-08d9df4c15a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2022 15:13:32.1693 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VSTS6EvMoULZ/4fasxvbCJHUET1N7JdRDapBSsobjNxFXMlqnP8sp85isoLusJVZYboomEXm7pmDVj7pOUuDpA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB4484 X-Rspamd-Queue-Id: 4JjD5b3fjhz3vV0 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=QEHgXcon; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.59 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.59:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.59:from] X-ThisMailContainsUnwantedMimeParts: N Yea, I've been looking at that spec. a little bit. I'll admit that encryption related stuff isn't my favourite work and that appears to be a significant part of the changes to SMB2/3. I did find some entries in Illumos gate related to integration of SMBv2.1 about 3-4years ago. It was not completely obvious whether the entries referred to client or server and it noted a work effort of 500hrs. So, I think Mark and Yuri are correct and looking at up to date Illumos sources is the next step. (As I mentioned, porting the Apple sources is beyond what I am willing to attempt.) rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of David Chisnall Sent: Monday, January 24, 2022 5:16 AM To: freebsd-current@freebsd.org Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 CAUTION: This email originated from outside of the University of Guelph. Do= not click links or open attachments unless you recognize the sender and kn= ow the content is safe. If in doubt, forward suspicious emails to IThelp@uo= guelph.ca On 22/01/2022 23:20, Rick Macklem wrote: > Mark Saad wrote: > [stuff snipped] >> So I am looking at the Apple and Solaris code, provided by rick. I am no= t >> sure if the illumos code provides SMB2 support. They based the solaris >> code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure >> predates smb2 . >> >> https://github.com/apple-oss-distributions/smb/tree/smb-217.19 >> >> If I am following this correctly we need to look at Apple's smb client >> from OSX 10.9 which is where I start to see bits about smb2 >> >> https://github.com/apple-oss-distributions/smb/tree/smb-697.95.1/kernel/= netsmb >> >> This is also where this stuff starts to look less and less like FreeBSD = . >> Let me ask some of the illumos people I know to see if there is >> anything they can point to. > Yes. Please do so. I saw the "old" calls fo things like open and the > new ntcreate version, so I assumed that was the newer SMB. > If it is not, there is no reason to port it. > > The new Apple code is a monster. 10x the lines of C and a lot of > weird stuff that looks Apple specific. > > It might actually be easier to write SMBv2 from the spec than port > the Apple stuff. > --> I'll try and look at whatever Microsoft publishes w.r.t. SMBv2/3. > > Thanks for looking at this, rick The docs are public: https://docs.microsoft.com/en-gb/openspecs/windows_protocols/ms-smb2/5606ad= 47-5ee0-437a-817e-70c366052962 Note that the spec is 480 pages, it is not a trivial protocol to implement from scratch. David From nobody Mon Jan 24 18:43:53 2022 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 0A3A41981C04 for ; Mon, 24 Jan 2022 18:44:07 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JjJmQ2JbRz4wVJ for ; Mon, 24 Jan 2022 18:44:06 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-lj1-x231.google.com with SMTP id t7so5218872ljc.10 for ; Mon, 24 Jan 2022 10:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7/hsuAQvHp5R088d0ePX2xN9n+brTYdSiRuntos1n5Q=; b=HqeIV5MUEsgcWL8Ur5VZ2Btj3kC6EBEsJGr91P5NwO5QgTbCYAIN0CaX8FCCTeYpky rw2jol6DqhcBerlBmm4feLi1O8rZ1YKAKtyJbYLhkEZQn5zwoWcX1epDJ+AH+TH3iBuG 8KvhAzo5bu71OBoDEbrJ3ZhtPxUyTXsuevf2p4uJhVnxMakjljj/S9BktDF+1BSOzf1o m947IpQHc0ESbAI7S0ystG3DiErtqLAXCYKkJc6BN/oRlFV2qCIfvDOQqtjlmG3B3Ul9 WNUbDADNHHWNeMIwZZ7WkeUOYQJRF+n3u1TrQBlKc7WiY77fudOOXq9VZeldncQYibhg ED+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7/hsuAQvHp5R088d0ePX2xN9n+brTYdSiRuntos1n5Q=; b=PuSfjS+OS3H46jy1clEam3wL0G9ei6AZCg3QZe8Jd5MxJDeeJOS+lpUG/GiLtCUvPU XtEy8oiEnaQqs3E5KxUpeAbjClKCaCZuNOtnA0q7eLbomLdDuwJo3zrkzi7vmG80/vv1 t6NMYutEZxh7zuVSGsqnTiJBoA8BFia8bNUF0vmvXMnqwS10lRTfYbVNCoJ7E4Dy4fSx 6NYFVH5H81jIZZzEejTl1VaX+NCUe0bB9t3WBVz3+nRrdDV2nX8iCD1KVU3JO7/qdQR0 6ypZqfacFFn8NzMYVq8SEeMODOu0/1VyjqUJBU56I1n5SjqeP74fl1ROJXojtVKrL46q zcZw== X-Gm-Message-State: AOAM531eEl6tl+x6tyLKZixQwKJUUUwjt7cXz1xFDbpXPDatwzEeUlaU jfeuyaz4ZvMSM/ebyF+Yf8drCXEvn7FvN35texyUjSNuRBU= X-Google-Smtp-Source: ABdhPJzUF6p9clqLeuZnuE3dylICJR4R19xFzvOuNK9/Uf2nlU3IEg70t0IS32Yy1prKjUMpmMe6glf1vvcaOHvKTDQ= X-Received: by 2002:a2e:b889:: with SMTP id r9mr12171917ljp.454.1643049844314; Mon, 24 Jan 2022 10:44:04 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <1ec9c802-c8a5-237a-50a3-31885cae917e@plan-b.pwste.edu.pl> In-Reply-To: <1ec9c802-c8a5-237a-50a3-31885cae917e@plan-b.pwste.edu.pl> From: Marcin Wojtas Date: Mon, 24 Jan 2022 19:43:53 +0100 Message-ID: Subject: Re: HEADS-UP: PIE enabled by default on stable/13 To: Marek Zarychta Cc: freebsd-current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JjJmQ2JbRz4wVJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=HqeIV5MU; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2a00:1450:4864:20::231) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[semihalf-com.20210112.gappssmtp.com:s=20210112]; FREEFALL_USER(0.00)[mw]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::231:from]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Marek, pon., 24 sty 2022 o 08:17 Marek Zarychta napisa=C5=82(a): > > W dniu 24.01.2022 o 07:42, Marcin Wojtas pisze: > > +freebsd-stable@ > > > > niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisa=C5= =82(a): > >> > >> Hi, > >> > >> As of 396e9f259d962 the base system binaries are now built as position= -independent executable (PIE) by default, for 64-bit architectures. Thanks = to that enabling ASLR can be done simply > >> by sysctls knobs when booting the kernel. > >> > >> If you track stable/13 and normally build WITHOUT_CLEAN you'll need to= do one initial clean build -- either run `make cleanworld` or set WITH_CLE= AN=3Dyes. > >> > >> The change is a pure MFC of the changes integrated to -CURRENT early 2= 021 and no issues are expected, but in case any problems are observed, plea= se issue a PR and/or let me know in this thread. > >> > >> Best regards, > >> Marcin > > > > Thanks for enabling this. If I understand it correctly we got some > improvements mentioned here[1] and it doesn't imply that ASLR has to be > enabled, especially kern.elf64.aslr.pie_enable can be still set to 0 ? > Currently it still remains opt-in on stable/13 and is disabled by default. Best regards, Marcin > > [1] https://www.mail-archive.com/freebsd-current@freebsd.org/msg183605.ht= ml > From nobody Mon Jan 24 19:48:50 2022 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 05964198C3B9 for ; Mon, 24 Jan 2022 19:48:56 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JjLCB5Gtcz3h2G for ; Mon, 24 Jan 2022 19:48:54 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 20OJmoZL064219 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 24 Jan 2022 20:48:50 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1643053731; bh=mgeBVBLj3tZAktS0e7CU5DO0v1AF1R3kuB/0VU079Ns=; h=Date:From:Subject:To:References:In-Reply-To; b=Z5g5HL7vPEkNMePZA6CmCdTuOhoiYt4zt++HCF/hLAOVzRXixDel8L2c078Y9jXdt QxXWkoJcUzP9zB96zlvgvvRzhWGo/t3eYAr8z80Gn9/yYOZH7lmXsCFkTPICDeeVqp LclTpTY5kF57w93TRVoZNd/Sa1jf5ilcg4nGYJqcFpgMhEu7qojOm7jpP/qC87F0EG KniXl+J2i8UIMcVEbob+DOIX+M46X7k+GHXscq9upoXuzc4VPndwQXan79lxAE1Iyq GA50vqAsMNPPHSv4rIA78gAZ890Nhyt5+iTmMyPaN+Gifvu6etFCczA09drTZSEy7a QIm/s08rG+45w== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: <77736438-0211-faf8-926d-2805dd9b40da@plan-b.pwste.edu.pl> Date: Mon, 24 Jan 2022 20:48:50 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 From: Marek Zarychta Subject: Re: HEADS-UP: PIE enabled by default on stable/13 To: Marcin Wojtas , FreeBSD Current References: <1ec9c802-c8a5-237a-50a3-31885cae917e@plan-b.pwste.edu.pl> Content-Language: pl In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------s1a07bk1qQ4hlT16d0nu2HnB" X-Rspamd-Queue-Id: 4JjLCB5Gtcz3h2G X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=Z5g5HL7v; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-5.78 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; HAS_XAW(0.00)[]; HAS_ATTACHMENT(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.981]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; MLMMJ_DEST(0.00)[current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------s1a07bk1qQ4hlT16d0nu2HnB Content-Type: multipart/mixed; boundary="------------wp4b00fCGuBopuKE0c2Ge3T8"; protected-headers="v1" From: Marek Zarychta To: Marcin Wojtas , FreeBSD Current Message-ID: <77736438-0211-faf8-926d-2805dd9b40da@plan-b.pwste.edu.pl> Subject: Re: HEADS-UP: PIE enabled by default on stable/13 References: <1ec9c802-c8a5-237a-50a3-31885cae917e@plan-b.pwste.edu.pl> In-Reply-To: --------------wp4b00fCGuBopuKE0c2Ge3T8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGVsbG8gTWFyY2luDQpXIGRuaXUgMjQuMDEuMjAyMiBvwqAxOTo0MywgTWFyY2luIFdvanRh cyBwaXN6ZToNCj4gSGkgTWFyZWssDQo+IA0KPiBwb24uLCAyNCBzdHkgMjAyMiBvIDA4OjE3 IE1hcmVrIFphcnljaHRhDQo+IDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVkdS5wbD4gbmFw aXNhxYIoYSk6DQo+Pg0KPj4gVyBkbml1IDI0LjAxLjIwMjIgbyAwNzo0MiwgTWFyY2luIFdv anRhcyBwaXN6ZToNCj4+PiArZnJlZWJzZC1zdGFibGVADQo+Pj4NCj4+PiBuaWVkei4sIDIz IHN0eSAyMDIyIG8gMTE6MzYgTWFyY2luIFdvanRhcyA8bXdAc2VtaWhhbGYuY29tPiBuYXBp c2HFgihhKToNCj4+Pj4NCj4+Pj4gSGksDQo+Pj4+DQo+Pj4+IEFzIG9mIDM5NmU5ZjI1OWQ5 NjIgdGhlIGJhc2Ugc3lzdGVtIGJpbmFyaWVzIGFyZSBub3cgYnVpbHQgYXMgcG9zaXRpb24t aW5kZXBlbmRlbnQgZXhlY3V0YWJsZSAoUElFKSBieSBkZWZhdWx0LCBmb3IgNjQtYml0IGFy Y2hpdGVjdHVyZXMuIFRoYW5rcyB0byB0aGF0IGVuYWJsaW5nIEFTTFIgY2FuIGJlIGRvbmUg c2ltcGx5DQo+Pj4+IGJ5IHN5c2N0bHMga25vYnMgd2hlbiBib290aW5nIHRoZSBrZXJuZWwu DQo+Pj4+DQo+Pj4+IElmIHlvdSB0cmFjayBzdGFibGUvMTMgYW5kIG5vcm1hbGx5IGJ1aWxk IFdJVEhPVVRfQ0xFQU4geW91J2xsIG5lZWQgdG8gZG8gb25lIGluaXRpYWwgY2xlYW4gYnVp bGQgLS0gZWl0aGVyIHJ1biBgbWFrZSBjbGVhbndvcmxkYCBvciBzZXQgV0lUSF9DTEVBTj15 ZXMuDQo+Pj4+DQo+Pj4+IFRoZSBjaGFuZ2UgaXMgYSBwdXJlIE1GQyBvZiB0aGUgY2hhbmdl cyBpbnRlZ3JhdGVkIHRvIC1DVVJSRU5UIGVhcmx5IDIwMjEgYW5kIG5vIGlzc3VlcyBhcmUg ZXhwZWN0ZWQsIGJ1dCBpbiBjYXNlIGFueSBwcm9ibGVtcyBhcmUgb2JzZXJ2ZWQsIHBsZWFz ZSBpc3N1ZSBhIFBSIGFuZC9vciBsZXQgbWUga25vdyBpbiB0aGlzIHRocmVhZC4NCj4+Pj4N Cj4+Pj4gQmVzdCByZWdhcmRzLA0KPj4+PiBNYXJjaW4NCj4+Pg0KPj4NCj4+IFRoYW5rcyBm b3IgZW5hYmxpbmcgdGhpcy4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSB3ZSBnb3Qg c29tZQ0KPj4gaW1wcm92ZW1lbnRzIG1lbnRpb25lZCBoZXJlWzFdIGFuZCBpdCBkb2Vzbid0 IGltcGx5IHRoYXQgQVNMUiBoYXMgdG8gYmUNCj4+IGVuYWJsZWQsIGVzcGVjaWFsbHkga2Vy bi5lbGY2NC5hc2xyLnBpZV9lbmFibGUgY2FuIGJlIHN0aWxsIHNldCB0byAwID8NCj4+DQo+ IA0KPiBDdXJyZW50bHkgaXQgc3RpbGwgcmVtYWlucyBvcHQtaW4gb24gc3RhYmxlLzEzIGFu ZCBpcyBkaXNhYmxlZCBieSBkZWZhdWx0Lg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBNYXJj aW4NCg0KVGhhbmtzIGZvciB0aGUgYW5zd2VyLiBJIGFtIG5vdCB3aWxsaW5nIHRvIHR1cm4g QVNMUiBvbiBhdCB0aGlzIHBvaW50LCANCmJ1dCByYXRoZXIgYXNraW5nIGlmIG15IHdvcmxk LCBhbHJlYWR5IGJ1aWx0IHdpdGggUElFLCB3aWxsIGJyaW5nIGFueSANCm90aGVyIGVuaGFu Y2VtZW50cyBvciBpbXByb3ZlbWVudHM/DQoNCj4gDQo+Pg0KPj4gWzFdIGh0dHBzOi8vd3d3 Lm1haWwtYXJjaGl2ZS5jb20vZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnL21zZzE4MzYw NS5odG1sDQo+Pg0KPiANCldpdGgga2luZCByZWdhcmRzLA0KDQotLSANCk1hcmVrIFphcnlj aHRhDQo= --------------wp4b00fCGuBopuKE0c2Ge3T8-- --------------s1a07bk1qQ4hlT16d0nu2HnB Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmHvAqIFAwAAAAAACgkQHZW8vIFppoKE 5Qf/cwKT4END8bbU+wMboPO/lB28qA0RrREl1mmcwsgSw7gqQAeHoRsrH9l7hDxtGMGJwc6bA5Y8 1AhraW6dp+enmvhYBNXUXoppuP31aiJ+9d3aN2pWPUU7r5vc8IUWWr+IkVTfurPQGnmgss+UUUly jqyszEvtdn/pCreFcjoK1W50PF9oV0qLa89rquQ+PpdybESRLU//9sJnFI/QQ067N3Wl/oF3Ahlz /BrMP9+KzVtiIWevEaRTGRbDr5fzBWpQz5SwJ/xoPDH2j4bfVP4NmaqouhXmUWvAQMGrFrVu6Mot kr0Et8oQSWkTDYfWLi1Bgtpb8Li/7bZsr3+jqxH/VQ== =VI/O -----END PGP SIGNATURE----- --------------s1a07bk1qQ4hlT16d0nu2HnB-- From nobody Thu Jan 27 21:34:10 2022 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 8C3EB197A768; Thu, 27 Jan 2022 21:34:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlDPc4MM5z4hpZ; Thu, 27 Jan 2022 21:34:28 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f181.google.com with SMTP id z7so3723855ilb.6; Thu, 27 Jan 2022 13:34:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=pCmTekoxF53GYKehsu29xGJx/BnbKO4H/2W+6AfCCCw=; b=oiGtDvnkRbvLD3iePiI7y/ZQf5eDwC+Pcy7DueA7LL3YNaIqdINk9k6QEmr0OX8JFT 1IUMTzr5Jr9e1WFWsbqaiOa/ll3zemE1ezNRq9He/CfcAYrLnGx0l7Ct4COzvlZ0kpnc nNVi4BIqLm0R9EuG1QJH6N6Wb1M5BygwPQ0IuENSl/5E8xEzkJ3Y2660CK0fW6NtVLGW kwbJ0+VX2BtIwx2MoKeo768/kMQifegRuNbXFbPf6A2zdxUGC9PdvYT38y51S4PbxGK0 IOgoa3jdp3U1vJ9P4RiwvXs6EI766azRuE8+vuGd79lJzxqLKJ7ENzJdJsluDnJFaoOd klyQ== X-Gm-Message-State: AOAM531Hx0glhHeP5LN6HFFuNcM64vF+7AQ+VJ5LdQMYM/nqoZKyiUGT ZoSZ8tFwcUb3+GHv8SxDt3tOuXPMjyvWh1EN9crsRqO9 X-Google-Smtp-Source: ABdhPJzUZnk9z//hwccn0HIXaprJZks/fzpoe2QjbnslJUn3zrg5/s+1Rpe2uEZzZMYwoEaQ2Mc+jbB4pOrdI8l7Y4I= X-Received: by 2002:a05:6e02:17c6:: with SMTP id z6mr4092398ilu.75.1643319261673; Thu, 27 Jan 2022 13:34:21 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Ed Maste Date: Thu, 27 Jan 2022 16:34:10 -0500 Message-ID: Subject: Dragonfly Mail Agent (dma) in the base system To: FreeBSD Hackers Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JlDPc4MM5z4hpZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.181 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-0.999]; RCVD_TLS_ALL(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.181:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.181:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) which accepts mail from a local Mail User Agent (MUA) and delivers it locally or to a smarthost for delivery. dma does not accept inbound mail (i.e., it does not listen on port 25) and is not intended to provide the same functionality as a full MTA like postfix or sendmail. It is intended for use cases such as delivering cron(8) mail. Since 2014 we have a copy of dma in the base system available as an optional component, enabled via the WITH_DMAGENT src.conf knob. I am interested in determining whether dma is a viable minimal base system MTA, and if not what gaps remain. If you have enabled DMA on your systems (or are willing to give it a try) and have any feedback or are aware of issues please follow up or submit a PR as appropriate. From nobody Thu Jan 27 22:50:50 2022 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 B0F5F1995CF4; Thu, 27 Jan 2022 22:50:51 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlG5l4MB9z3qpq; Thu, 27 Jan 2022 22:50:51 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643323851; 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=lfmBjeN6PV3N95QxdSk6caN+J9VTUoKkd8zURRcxcOY=; b=ufcrqGEZoVVhDcj+4zkK5D3qToK2KUWzIzog6zGNu34AoQ6CSh0yFXot5U25RGtAYILxwV GdjsNDERNxcscWbElwoyDLLafGHLG/fL31y52bp4n9XQfHlhy23J1AGMOFKm92SubngDzP wAm3EciEy50fLcTgRXCTT7G+z3Muwys3Tuv1/djfFDwzeDwhgd33UZnGHl3kQdkHUAnIzp GFJtDrPCdQvg2tCMo4Oe4M7HsedalLcFiL/gFcfBKMwhW2zsp25Pg/f96jCDR4J6xa+tQr yvqELkD98MOC1OaO0x7Ihgb2L+BkVstzmosyAV8N2E4qVAokXU7gVvYec8WXxA== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 047F46EAD; Thu, 27 Jan 2022 22:50:50 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <642d2921-1011-12fe-69b2-b394282341ae@FreeBSD.org> Date: Thu, 27 Jan 2022 14:50:50 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Dragonfly Mail Agent (dma) in the base system Content-Language: en-US To: Ed Maste , FreeBSD Hackers Cc: FreeBSD Current References: From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643323851; 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=lfmBjeN6PV3N95QxdSk6caN+J9VTUoKkd8zURRcxcOY=; b=Zz74tbe8nFHENLDn+vcKx5NMoF7F77WcWM46yuGttBwKf4twF0t/l0x8ZWbZoRSuiM8qn5 CdkYVcbZ3WQFBYhPxyNyDQ/epL5oJbNLbxr903sDnwXvisac+KzEirl1WUMIao5Z2qkzq9 yJchmaII+iO8YIZco8aWx1XdAe0W2QE+/FmDRqlQ3StkD5gf/3n9aGQunyQ+LfzSCWnHV7 mNWifCKb2ht/KUJiVmqok6ccsQJznuwglPMrDlog3jecnLb891x3fyUEydfz0opfIKsDHB O+KccAfj6qJwV6hF0jIaOaZu7vn6bOjSnIMbjMtOIx55/5W/q0Wc8mfFrPgy8w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643323851; a=rsa-sha256; cv=none; b=BCyqC3CSlWmBXQz+KqH/ZEdlfw2tNKBFAV+HW8NIvV5sWz3l67zQN7aZevLYMFW1ndKVjp PltiV6LAyFyAbslH3d1QGlHSeK2qye9xHr3jA1azQz9zDAHmlPnKZf03kOshRRKDuzXARo xb5zq0hpGH4htK55qlkOOa5EPUA4JtuoLGmgP7seuIGTFsQlSvqyg5TekmJKtax0TSZi+0 cCvNWxWcPZF5X6wUZX+E/cZ6+18j9WUZnH/ZxWKxw+hWgsgQQHcrv5p8jtMptvrNIs0I0s 2cCA3r9orIc8M8AkoMMGcVVgyew0FYT7+8csGeLYFMupAj+11fuelyB4NI1zwg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 1/27/22 1:34 PM, Ed Maste wrote: > The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) > which accepts mail from a local Mail User Agent (MUA) and delivers it > locally or to a smarthost for delivery. dma does not accept inbound > mail (i.e., it does not listen on port 25) and is not intended to > provide the same functionality as a full MTA like postfix or sendmail. > It is intended for use cases such as delivering cron(8) mail. > > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. > > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. I've used DMA on systems without local mail accounts to forward cron periodic e-mails just fine. It even supports STARTTLS and SMTP AUTH. I haven't tried using it for simple local delivery to /var/mail/root. -- John Baldwin From nobody Thu Jan 27 23:28:32 2022 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 E2B661986B57 for ; Thu, 27 Jan 2022 23:28:52 +0000 (UTC) (envelope-from contact@shiori.com.br) Received: from out0.migadu.com (out0.migadu.com [IPv6:2001:41d0:2:267::]) (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 4JlGxb6wPDz4dng for ; Thu, 27 Jan 2022 23:28:51 +0000 (UTC) (envelope-from contact@shiori.com.br) X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shiori.com.br; s=key1; t=1643326123; 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=OiIqBxBxxyrCWen6y2UrWrRP6fpGPiMIZubiJZPNrVw=; b=OqUHwFQtP8CnmiinQJbIhisYVcNKT7Jf6HCKttFOrIa2YNf9cSe/tu8rmxMiCt+/VBvlu0 rcV4uKSu/0QwNhQ4go0kjaO27uGID62K//k65XOWmbo7SLfvOmm26nC11O75b1fNcCnAyW B2w0+DVC01AjL6CdQdGvjyZrVOhkv4Y= From: Filipe da Silva Santos To: Ed Maste , FreeBSD Hackers Cc: FreeBSD Current Subject: Re: Dragonfly Mail Agent (dma) in the base system In-Reply-To: References: Date: Thu, 27 Jan 2022 23:28:32 +0000 Message-ID: <861r0src67.fsf@misaka.lan0> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: shiori.com.br X-Rspamd-Queue-Id: 4JlGxb6wPDz4dng X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=shiori.com.br header.s=key1 header.b=OqUHwFQt; dmarc=pass (policy=quarantine) header.from=shiori.com.br; spf=pass (mx1.freebsd.org: domain of contact@shiori.com.br designates 2001:41d0:2:267:: as permitted sender) smtp.mailfrom=contact@shiori.com.br X-Spamd-Result: default: False [-6.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[shiori.com.br:s=key1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:267::]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[shiori.com.br:+]; DMARC_POLICY_ALLOW(-0.50)[shiori.com.br,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; RCVD_IN_DNSWL_LOW(-0.10)[2001:41d0:2:267:::from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR] X-ThisMailContainsUnwantedMimeParts: N --=-=-= Content-Type: text/plain Ed Maste writes: > The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) > which accepts mail from a local Mail User Agent (MUA) and delivers it > locally or to a smarthost for delivery. dma does not accept inbound > mail (i.e., it does not listen on port 25) and is not intended to > provide the same functionality as a full MTA like postfix or sendmail. > It is intended for use cases such as delivering cron(8) mail. > > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. > > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. I've been using DMA for quite some time (in fact, I'm using it to send this mail) for local delivery and forwarding. It is quite easy to set up, and I have no complaints at all. (forgot to carbon copy, sorry :p) -- Filipe da Silva Santos --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJKBAEBCAA0FiEEEC4ZRCGJMf8G6z95dguuRfezAI4FAmHzKqEWHGNvbnRhY3RA c2hpb3JpLmNvbS5icgAKCRB2C65F97MAjpHwD/90wOR/RAcoV6Qv+1S0HpRIgBpE U7aNkBFTNw+9i1zEFypVf8AnSBxHOjwqb8z+bY4DITzPJCZndbfCe4/ha02tQE5U gOQ40xsysDeh1XuOIIjkAqqso6WadiJxOX9DmsoLDJlDscVi5tdy1ImTa+/arZQQ MB1BlE9FezDY921xWW92Zf3Xd6U59ZU5rB+u6lIxx0Cx+tXySRMP6tmr6qpAPZZz l3QX5Lj+BvbD5TPwFCYiTuCpg6lew3DIl4NYvghhX/XbYJrtDNRNurxL+AkDzjyY Pw1ZVWE7YkTs2n2lMCDhwNH7FDnSNFDdsxNxcZY3ifDkL7YhvTXeSmKjer2nUreR lTcgBlrLi69xNKN42clTGZOBGZ2n21W3R8/cW+mOjmEMT5FWJK5noViEgC1rs6/z lkWh4qLxPF2hgH0hVU2uKRRdsV2YCTaF3CCnKpfWi/aHLPm8gIH4Aq5i4MHLJPqr sgYJmc4oIr+PRk9Osi5+wOJjd67HSWnxx5/saGB/M2GqZC7utY9n1jsfWeTBtfhl i19xDuVqqtWuw+d2CuumxUty3v+pTcqDXyRlXql6rKpKzYXHI+GTK4Y7ow9N9D1D An+yU7o1PGTB0UXPcgpB1U1mm0fdU9xGv3PxeSzrlZnhdO9MSyouF0/tgsZelQh2 Ie+91O4HyDFUpcmC5w== =voFg -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 28 00:05:09 2022 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 1596419700FA for ; Fri, 28 Jan 2022 00:05:50 +0000 (UTC) (envelope-from beldin@worldsmith.org) Received: from mail.worldsmith.org (mail.worldsmith.org [IPv6:2404:9400:2:0:2:5751:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 4JlHm90L31z4xZ3 for ; Fri, 28 Jan 2022 00:05:42 +0000 (UTC) (envelope-from beldin@worldsmith.org) Received: from darrin.worldsmith.org (unknown [1.147.81.221]) by mail.worldsmith.org (Postfix) with ESMTPSA id C60EC583 for ; Fri, 28 Jan 2022 10:35:30 +1030 (ACDT) Date: Fri, 28 Jan 2022 10:35:09 +1030 From: Darrin Smith To: freebsd-current@freebsd.org Subject: Re: Dragonfly Mail Agent (dma) in the base system Message-ID: <20220128103509.6c442fdd@darrin.worldsmith.org> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JlHm90L31z4xZ3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=worldsmith.org; spf=pass (mx1.freebsd.org: domain of beldin@worldsmith.org designates 2404:9400:2:0:2:5751:0:1 as permitted sender) smtp.mailfrom=beldin@worldsmith.org X-Spamd-Result: default: False [-3.66 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.956]; DMARC_POLICY_ALLOW(-0.50)[worldsmith.org,reject]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:133159, ipnet:2404:9400:2::/48, country:AU]; RCVD_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[1.147.81.221:received] X-ThisMailContainsUnwantedMimeParts: N On Thu, 27 Jan 2022 16:34:10 -0500 Ed Maste wrote: > The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) > which accepts mail from a local Mail User Agent (MUA) and delivers it > locally or to a smarthost for delivery. dma does not accept inbound > mail (i.e., it does not listen on port 25) and is not intended to > provide the same functionality as a full MTA like postfix or sendmail. > It is intended for use cases such as delivering cron(8) mail. > > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. > > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. > Another user here who uses it on every machine except my mail server, have been for years and it does the incidental mail handling reliably. -- =b From nobody Fri Jan 28 00:18:50 2022 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 68F2E1978712; Fri, 28 Jan 2022 00:19:00 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 4JlJ3R4Y8Pz54qS; Fri, 28 Jan 2022 00:18:59 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id BA7A016057; Fri, 28 Jan 2022 01:18:51 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 23B7039C1; Fri, 28 Jan 2022 01:18:50 +0100 (CET) Date: Fri, 28 Jan 2022 01:18:50 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Ed Maste Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Dragonfly Mail Agent (dma) in the base system Message-ID: <20220128001850.FBYGI%steffen@sdaoden.eu> In-Reply-To: References: Mail-Followup-To: Ed Maste , FreeBSD Hackers , FreeBSD Current User-Agent: s-nail v14.9.23-224-g6440afd04d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4JlJ3R4Y8Pz54qS X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-0.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_DN_ALL(0.00)[]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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 Ed Maste wrote in : |The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) |which accepts mail from a local Mail User Agent (MUA) and delivers it |locally or to a smarthost for delivery. dma does not accept inbound |mail (i.e., it does not listen on port 25) and is not intended to |provide the same functionality as a full MTA like postfix or sendmail. |It is intended for use cases such as delivering cron(8) mail. | |Since 2014 we have a copy of dma in the base system available as an |optional component, enabled via the WITH_DMAGENT src.conf knob. | |I am interested in determining whether dma is a viable minimal base |system MTA, and if not what gaps remain. If you have enabled DMA on |your systems (or are willing to give it a try) and have any feedback |or are aware of issues please follow up or submit a PR as appropriate. I used it for years and even maintained a package for a Linux distribution (CRUX) until last October, and i think maybe even AlpineLinux before? I know for sure i maintained a package with Author: emaste Date: Fri Oct 27 20:21:09 2017 New Revision: 325047 URL: https://svnweb.freebsd.org/changeset/base/325047 patched on top of it for years. Very basic usage, only local delivery. But i plan to readd the package as part of the postfix-lmdb package i maintain, because, you know, postfix's sendmail(1) and local deliveries need read access to the postfix configuration, and as part of my effort to totally box (unshare + overlay mount) all my daemons which cross ingress/egress (and place their config under /root/hosts/$HOSTNAME), it's need to access /etc/postfix-lmdb is in the way. (The plan is thus to make dma "part of this package" and make it provide /usr/sbin/sendmail, configured to proxy to local SMTP, where postfix then regulary sits.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Fri Jan 28 01:09:54 2022 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 B70DD1986F4F; Fri, 28 Jan 2022 01:10:06 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4JlKBL5bFLz3msZ; Fri, 28 Jan 2022 01:10:02 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 20S19s6Y016665; Fri, 28 Jan 2022 01:09:54 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 20S19sY2016664; Fri, 28 Jan 2022 01:09:54 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202201280109.20S19sY2016664@donotpassgo.dyslexicfish.net> Date: Fri, 28 Jan 2022 01:09:54 +0000 Organization: Dyslexic Fish To: freebsd-hackers@FreeBSD.org, emaste@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Re: Dragonfly Mail Agent (dma) in the base system References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Fri, 28 Jan 2022 01:09:55 +0000 (GMT) X-Rspamd-Queue-Id: 4JlKBL5bFLz3msZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-2.83 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.13)[-0.132]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Ed Maste wrote: > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. I thought it was enabled at default! > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. I use it on my non-mailservers for delivering both local mail and remote mail (from cron etc. to remote users) via my mailservers as smarthost. It works perfectly. I've been using it for many years. It doesn't run as a daemon - if a message can't be delivered (e.g. smarthost temporarily unavailable), it will be requeued, and the process exits. Don't forget to add the cron entry to retry requeued entries! */30 * * * * root /usr/libexec/dma -q Thus was my only minor "gotcha" - it wasn't obvious from the man pages to add the cron entry (or maybe I just missed it) As for the smarthost configuration, I've successfully used ipv4, ipv6, both on port 25, and non-standard ports. I've also used combinations of non-encrypted, TLS, and opportunistic TLS, - all work as expected. I haven't ever used the smtp-login facility. Cheers, Jamie From nobody Fri Jan 28 01:47:25 2022 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 3BEE8197778A; Fri, 28 Jan 2022 01:47:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlL1q3lWnz4ZmL; Fri, 28 Jan 2022 01:47:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f48.google.com with SMTP id z199so5973529iof.10; Thu, 27 Jan 2022 17:47:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Acb3J3GxLVuitfzzX4zvnY/trFxd2cr7/BBmDaGeuu0=; b=2/Dg5vNv3nNK8Q+u86ndD5+E+CXkbmWL4ETG7I5BwIeN36B2Mune2Ogn2wtae8mUyv o2avkEHf+DhkcmEA55jEQmRCRHM40wx7IALkmrZGvE4H7QPt8MzmodhulUcjYSdxNCtn Dz5UPo93VjB2oxOJ1RO7hMd9p0hXbVibfe480O/6PYh8OI333vdLttDeCeI/NqaSPhOP 4+UCtaHGKj7RuPcp0ItOTSiwEWznSVE4qY41mhQcimCAcNua01iNpCDg+rQevN/5Z+Q0 Na2reUgwMITtftuamgX9ATeKEwifJG55E5F1g73TPgzrgfd7YEOxAzWUEqVEDSfSvGl6 +oKQ== X-Gm-Message-State: AOAM531+7ALYLazbejZRUXMaDT0ZisgfkiD1WC/98iB1OE8uSTnjJH4C CLPU0S4ng9U3Q4r7TIErYklbQa9+ALr8vuUJWbX9FBQh X-Google-Smtp-Source: ABdhPJzsLVpr9ZrfT6oee1iLEcRlvwxevGtVguyKOhDrX4139oFYYLrjvtXnS+NCxigKjU2kVCyvvDlaCi9bFkzyqQw= X-Received: by 2002:a5e:a806:: with SMTP id c6mr3904148ioa.112.1643334457346; Thu, 27 Jan 2022 17:47:37 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <202201280109.20S19sY2016664@donotpassgo.dyslexicfish.net> In-Reply-To: <202201280109.20S19sY2016664@donotpassgo.dyslexicfish.net> From: Ed Maste Date: Thu, 27 Jan 2022 20:47:25 -0500 Message-ID: Subject: Re: Dragonfly Mail Agent (dma) in the base system To: Jamie Landeg-Jones Cc: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JlL1q3lWnz4ZmL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.48 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [0.68 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.84)[0.838]; NEURAL_SPAM_SHORT(0.84)[0.842]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.48:from]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.48:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 27 Jan 2022 at 20:10, Jamie Landeg-Jones wrote: > > Ed Maste wrote: > > > Since 2014 we have a copy of dma in the base system available as an > > optional component, enabled via the WITH_DMAGENT src.conf knob. > > I thought it was enabled at default! Yes, my mistake - by default WITH_DMAGENT is enabled, and /usr/libexec/dma is built. What is not done by default is configuring /etc/mailer.conf to use dma for /usr/sbin/sendmail or /usr/sbin/mailq. From nobody Fri Jan 28 02:54:25 2022 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 5840F197AD9D; Fri, 28 Jan 2022 02:54:35 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 4JlMVy1WYrz3L7q; Fri, 28 Jan 2022 02:54:34 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B2C0C5C0036; Thu, 27 Jan 2022 21:54:28 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 27 Jan 2022 21:54:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=ZiJhbCEmuCr2q5GuJAZYNl5cOZdGc+2ZLtmBDt 0jgFs=; b=eOH1WSvPIdhivIdbSH8QsHYLIlFGdnh9WOX58rylC/wJ/b3CIOxeed 53hofi15ivO30O/TtqgHHTucb32gM9fLTi2XGnXNU9n9hdtRD4Jk/wX0raDLbm79 4a4Uo57SJCamCH90GdDSW0swGoEF+GYFYMz7DTDEBo0716ywRbBLMO0XSx7CbxSJ mG5GZRW2BzL8HHzD+5w6kbegkueA3RN9xfuzwK+T1Rm5soTRD43viEjKWrwWMsSo /ICPzLO8jnM4iczbjewz7TsqaQh0Q1tLfo+IDqNFnKVVaOxN+BKMQ6axJlYne2SA sbmQjPcsmX6FCFyRf6e/Q45u2pgOeoqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ZiJhbCEmuCr2q5GuJ AZYNl5cOZdGc+2ZLtmBDt0jgFs=; b=VVKoljsCvop5r8tfgdCWn4MVSqpA9qHw2 9vMLUgl06viKZ93t7p8Iww0boottNFFoWgAVOEC7fTien+wJdFz0VGB1mMN7ThDf NG2hkGiwykxdBXzML7wpte27dBVsGXMiYrEbSdxCZM5grw3htJDHJ8SbyFM5aBRg IZy0gFO/gWEn7UDEoPMx05HoZY2v6mEiTrkcuJfGktlUXxsCcuUP6TfjHvctBToj KYRA4qwz8MUj6GE1s1x+tnD5DnqFLN9mfNkDKH1N6Lk4X1Ylpn781jH2QzJgeMPe r79DlEJmmIbz1h9fh7paVUv85QWxjHHXbid+ZqyvdLPgSy0oekbxg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfeeggdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Jan 2022 21:54:27 -0500 (EST) Date: Fri, 28 Jan 2022 02:54:25 +0000 From: tech-lists To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: POLLHUP detected on devd socket Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> 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="juCUSW30Z3DtYX2A" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JlMVy1WYrz3L7q X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=eOH1WSvP; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=VVKoljsC; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zyxst.net]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from] X-ThisMailContainsUnwantedMimeParts: N --juCUSW30Z3DtYX2A Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 23, 2022 at 10:38:09PM +0300, Dima Panov wrote: > >Will try to play with zfsd disabled, as suggested. since reporting the issue and disabling zfsd, the problem=20 has not re-occurred so far at this time (28th Jan) --=20 J. --juCUSW30Z3DtYX2A Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHzWtQACgkQs8o7QhFz NAXUYBAAlvHToI7h3zLmNZcOYceEYn5Tml8PyPRSDhxcVl+aX6D1wRyZUrIXVyyB Tkk5fM613nHxBBKo08LR6J9dqd1fP4MRV1Et8XPAfM9ytgKZQogd0M0TiBRLVv9K LZG8lmpK204GkDZAVB00u8x6o6oaTIGkzqOXGzbcHbkg6hb1Nb/lVaaS23QwgVZO McQj1kTurHrot/azTJGeucPEsBWgBSM/b7tltQTxQc+WTSEnpQrSIBN0cnBBQgPl OPhST3nsFoi32+o9/y2MxwAdVFtnQm3bAKjeZ3I56T/exiDVZHyJeehfwgTWpAvW TCY3GMXf+D+NjCVlVShkz+qjyY3s3KMJUYjtAKkZrQFMYKGatjLJNjg8jhyekqC1 ZYdMMqdOHFMn4e3R9sMHadMGZjZk6vadoh+XK/NslVuKbUF/w1awT8TyX6EtOjTK OhX377EsxejdaTD+AIRIPNIiHNQNFvVLlnvWNCYg7RwMlxkdOimcI8D9weoTO9b3 KJh5gCWfP+nxT+hszyF8SfpexhWFymiBJ1HChN4uby21rgSn87+LwLyfb3gQR5qx RR6UfR+HR9u71I1DSzRZgunnfBgKFBHZVl7EFmiomxGMHxWjvn3paXxJjx4bjqM5 iDe9+ljK/l6qgUipkFop+Di9uqAKy3LF82H0F9Xsermaaha5W+c= =PIWr -----END PGP SIGNATURE----- --juCUSW30Z3DtYX2A-- From nobody Fri Jan 28 10:16:16 2022 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 7512B198F773; Fri, 28 Jan 2022 10:16:24 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 4JlYJl2sHxz3jVx; Fri, 28 Jan 2022 10:16:23 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [192.168.0.252] (gw.br-thn-01.caladan.net.uk [80.71.4.65] (may be forged)) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 20SAGGDs064663; Fri, 28 Jan 2022 10:16:16 GMT (envelope-from rb@gid.co.uk) 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 13.4 \(3608.120.23.2.7\)) Subject: Re: Dragonfly Mail Agent (dma) in the base system From: Bob Bishop In-Reply-To: Date: Fri, 28 Jan 2022 10:16:16 +0000 Cc: FreeBSD Hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ed Maste X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4JlYJl2sHxz3jVx X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk X-Spamd-Result: default: False [1.29 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; DMARC_NA(0.00)[gid.co.uk]; NEURAL_SPAM_MEDIUM(0.99)[0.990]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, > On 27 Jan 2022, at 21:34, Ed Maste wrote: >=20 > The Dragonfly Mail Agent (dma) [etc] We've used it for years on routers and other small boxes to offload mail = from periodic and cron. -- Bob Bishop rb@gid.co.uk From nobody Fri Jan 28 10:56:15 2022 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 13D80198AAF7 for ; Fri, 28 Jan 2022 10:56:25 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlZBw22Hfz4X0x for ; Fri, 28 Jan 2022 10:56:24 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-ej1-x635.google.com with SMTP id ah7so14708979ejc.4 for ; Fri, 28 Jan 2022 02:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=wfjxy6nHo9NlCS1OaDMrN0MUdYQan/ElOuQd8koHZPo=; b=MEUNy8ez79y64vrcGBsMrRM0DpEJhMN8SOC/mexsOFeol0H6pQRyNgZ5x9csZ4ZXAq FMlRYa+YzlCw1nWeapWVgtAe0ZVh0ruaxJwWm0BBH+TK/li9tpB9VDtTuhWmDk8LxQQ7 uly+Ly3ukd/pfNeTvKDmOeqg8Uhy57apxEjObX07jysLePx0iK8MCwPZNJX6hGvtCKna Z79ZJcNyA3iBrey2ONMLVkRjqycjbskvGA8Ca83qxiMxnPYGE33xV3kFaiS3xl6YaSKC LPKbhui3x3z25iUbd3tFa6VItRR7OUM3qswvlmyZQyjG74NC6v2myisCN9itXGXsLiB8 h/aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=wfjxy6nHo9NlCS1OaDMrN0MUdYQan/ElOuQd8koHZPo=; b=pgcBX7VDeGiY0Z6DKN2ZKiy/kwF3QHXjeXtLfhOeGQyqva54iT6VqPeB2id4+X/0lc mnMS+4HnvA6KPwvks1J4M9cn2hxLcsbOrM9TccaxtMF9ZU2c6phEL3KJgV+HH8jnIe2r UZYGMvFlySSVgmAgnBekXW8FvkHf78DtPjKfP7V0MF9F9urnGzGnecCNuyLTlwhwnm/a cJwMdWM9Kxdoi27bSovFX4+y8WCLXedjQ8oO61cJ3NQviLrv2fhc+HdTT1kiA250wOhC o61F5AxIAaEAURLjp1HZAxzUfKVZQ+aURb4DQ4L/dGeTrRQHDL4jaQuOKbsOquHgmsp9 7v3A== X-Gm-Message-State: AOAM530OkHYMKEkxzoBO7RJjcO+1f259J/qcctG180orhaI1BaDy8T5n quwmy9C+RYIK7MY+VQ8FSs1pKAlP1Lc= X-Google-Smtp-Source: ABdhPJyCMJtty7rMg7hp/xPbORSQ9GS7e04hwsaAhq3ksBmcNiMWWBTX0jVdcwo0mYB+kuuvacndwg== X-Received: by 2002:a17:907:b00d:: with SMTP id fu13mr6461069ejc.459.1643367376459; Fri, 28 Jan 2022 02:56:16 -0800 (PST) Received: from [192.168.1.17] (85-147-130-226.cable.dynamic.v4.ziggo.nl. [85.147.130.226]) by smtp.gmail.com with ESMTPSA id h20sm12416443eds.9.2022.01.28.02.56.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Jan 2022 02:56:16 -0800 (PST) Message-ID: Date: Fri, 28 Jan 2022 11:56:15 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: Dragonfly Mail Agent (dma) in the base system Content-Language: en-US To: freebsd-current@freebsd.org References: From: Johan Hendriks In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JlZBw22Hfz4X0x X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=MEUNy8ez; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of johhendriks@gmail.com designates 2a00:1450:4864:20::635 as permitted sender) smtp.mailfrom=johhendriks@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::635:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 27/01/2022 22:34, Ed Maste wrote: > The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) > which accepts mail from a local Mail User Agent (MUA) and delivers it > locally or to a smarthost for delivery. dma does not accept inbound > mail (i.e., it does not listen on port 25) and is not intended to > provide the same functionality as a full MTA like postfix or sendmail. > It is intended for use cases such as delivering cron(8) mail. > > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. > > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. > > We use it also to get periodic mail and other mail off of the system and it works fine! Gr Johan From nobody Fri Jan 28 16:49:31 2022 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 1197119934A2 for ; Fri, 28 Jan 2022 16:49:41 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from cameronkatri.com (cameronkatri.com [206.189.178.249]) (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 4Jlk2X257Rz3h4Q for ; Fri, 28 Jan 2022 16:49:40 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from FreeBSDY540 (unknown [69.4.234.21]) by cameronkatri.com (Postfix) with ESMTPSA id 7012F40F6B for ; Fri, 28 Jan 2022 11:49:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cameronkatri.com; s=dkim; t=1643388574; 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=h8OxGGue6CO0SIKn9zmSOsATii8re6DEswpZCiZNxOI=; b=I1QJzb4WiIjC/2FLcOrmPqyf3BQx77sytUwDK2ENCYphXTqYl2coWtbYTAQxGXzT+2W8SX mWQv2K0QwJNzAgPq+YQTqIVnNPkYcTTlKY4uLE1teACYskJHhG94MlpamRIRrE00frvy7R N7YKdYT8Xjc9TKUSZ7LHA7hSGVIR1Qw= Date: Fri, 28 Jan 2022 11:49:31 -0500 From: Cameron Katri To: freebsd-current@freebsd.org Subject: delete-old-files Deleting Newly Installed Files Message-ID: <20220128164931.vo43kpuxtogqqqnj@FreeBSDY540> 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="5reexjxc2ccgxihl" Content-Disposition: inline X-Rspamd-Queue-Id: 4Jlk2X257Rz3h4Q X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=cameronkatri.com header.s=dkim header.b=I1QJzb4W; dmarc=pass (policy=reject) header.from=cameronkatri.com; spf=pass (mx1.freebsd.org: domain of me@cameronkatri.com designates 206.189.178.249 as permitted sender) smtp.mailfrom=me@cameronkatri.com X-Spamd-Result: default: False [-5.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[me]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; DKIM_TRACE(0.00)[cameronkatri.com:~]; DMARC_POLICY_ALLOW(-0.50)[cameronkatri.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_PERMFAIL(0.00)[cameronkatri.com:s=dkim]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:14061, ipnet:206.189.176.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --5reexjxc2ccgxihl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I recently enabled WITHOUT_MANCOMPRESS=3D"YES" and WITH_LLVM_BINUTILS=3D"YES" on my 14-Current installation and noticed two issues while running make delete-old. The first issue is that mount_fusefs.8 is being deleted, this seems to be due to b9ec6f2 ("Add a whole bunch of missed obsolete manpages to Obsole= teFiles.inc"). The second issue is that when using llvm binutils, the newly installed llvm= -objdump at /usr/bin/objdump will be deleted, this seems to be due to 80b7615 ("binutils: disconnect objdump from the build") and 021385a ("Add WITH_LLVM_BINUTILS to install LLVM binutils instead of Elftoolchain"). I have CC'd the people responsible for those 3 commits. Thank you. --=20 Cameron Katri Email: me@cameronkatri.com PGP Fingerprint: 7D3B36CEA40FCC2181FB6DCDBAFFD97826540F1C --5reexjxc2ccgxihl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEfTs2zqQPzCGB+23Nuv/ZeCZUDxwFAmH0HpYACgkQuv/ZeCZU Dxzouwf9FbUn87sCFC9zbwgFx1gR8iPlt9/HpmyLncOX49HNgmO8M33cxIoLuRiI Se+a2BP6cxQCfQ3+rEaJ9al8fbefKxgJLC7tA3SmJDG2yb6shrRg6fPr8PaPEntE 1KvBjTDcAUeLliNoe3ArtKS7ldovIX1nEywDucYMdKh2z0Zy8NJ/Vec6Tn9GMmZe hLyNpz+9C88pQzrSRrcojPk8k6UWvSSq3i8Z2QuuQ+LaFM/Y73Ne4ETR14y41kfs n1cL7Xam7y2JHMLpetwwCjMH2FjkQdMxPSDiErRGTbVcWeWqcaiRqV3Ek2vNTR2i ZiUE7+lV2lD6CduKYExUgmkqnrGBew== =U/N4 -----END PGP SIGNATURE----- --5reexjxc2ccgxihl-- From nobody Fri Jan 28 18:04:28 2022 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 98F461975F30; Fri, 28 Jan 2022 18:04:49 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlljD6Zhlz4lcQ; Fri, 28 Jan 2022 18:04:48 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f52.google.com with SMTP id r144so8703804iod.9; Fri, 28 Jan 2022 10:04:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MNFtwXB/xUkBewYoqwIPSW2v4RSb9JgYcP5Y81E0w/8=; b=NRN7vDe6LO31ahfd27R81ORi9gMoEI5oSlfNc1L5IDwygNlTloJHk5LQ01jnyGlGOO bAMk4rUxDIKOUXpeC6a35VJzGmTxgfyDNFrisHH93lvCGHX0pkvapFoLOMi9vmmxLTAE +ETTDsh41EhLmoLu04EH2JWTGvfZmiS9ugV3wgcRSKyvNHa8pR9NFQeH1PlO9tuc5qOl dz1q5YsJCyQccn0JevVbvRiEQmlYC8uDO0+9DuECrT9TD2dsKbC4XDpoogPTGH+ofNAm GTvfeG8BzYkLVH08qvZwCt5lBiibK6zxeJ4FJVenmcqXGXvieuVQMUZIvxkWXKeNZZ7H 8Cew== X-Gm-Message-State: AOAM532n2JfZc9oC/WMObmiQXxXIGmTep0Im/aMBQIzlP2YoasF4qIAW rb4E198nrARZHpxg8Q+K1lsVR3AlTlTAEW27/pxoE83WJ6A= X-Google-Smtp-Source: ABdhPJy5K7gHYa/dIexNcmJc90n3yF8wsM6mDaecI/U79L16UoROYOsZivveKXoQGJwlByiow7sVr49Aaay9dd6CusQ= X-Received: by 2002:a02:1181:: with SMTP id 123mr5252003jaf.93.1643393081329; Fri, 28 Jan 2022 10:04:41 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Fri, 28 Jan 2022 13:04:28 -0500 Message-ID: Subject: Re: Dragonfly Mail Agent (dma) in the base system To: FreeBSD Hackers Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JlljD6Zhlz4lcQ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [0.08 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.52:from]; NEURAL_SPAM_LONG(0.08)[0.077]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.52:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 27 Jan 2022 at 16:34, Ed Maste wrote: > > If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. Thanks everyone for the feedback so far. I think the feedback (including some private mail) can be summarised as: - It works well for the intended use case. - Documentation (FreeBSD handbook) is missing. I have submitted https://bugs.freebsd.org/261536 to track this. - We'd need to address queued mail in some way before it could be the default (e.g. provide a default cron job). From nobody Sat Jan 29 21:25:17 2022 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 4780C197455F for ; Sat, 29 Jan 2022 21:25:22 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmS6B0j7Nz4cBW; Sat, 29 Jan 2022 21:25:22 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643491522; 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=ExGS+VIk6aK6a6NIbtRSs9MnGe3Qe66claapPcYO6PI=; b=WPUfW0LE5KD+f9JjJ1CvMknaR9ES/mKgUZRHy4sIaC/1XCuvHOhVIipKh3wge5ewpNhpu8 y9q5+97FRl8juYXFvg2V0xtOBkfPi2xLV5l2WLocWIX+xcFZzmIEpXksmw5JYr9BwrdeA4 gCs3HceqxYbMalip+y0lOOsCLWuKnYnIlkjjn0pI+HAem98lphHL0WL+iPWL4jNGIm5eH6 2xwru4R7pozTn9/Oyo+XktXg3i+oQqUKnSChk1Dx3Jhorti/C+0Tv/88JTrFFZEeNOnl2s T06XmpAxM3+fhDaXwlJuRs58Zw3R9r5+VsNcEmOyjutgB2WN2JDCLkiocRXO7A== Received: from [IPV6:2003:cd:5f0c:9800:b50a:1ab6:2f63:fb85] (p200300cd5f0c9800b50a1ab62f63fb85.dip0.t-ipconnect.de [IPv6:2003:cd:5f0c:9800:b50a:1ab6:2f63:fb85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id D6C1C2DE74; Sat, 29 Jan 2022 21:25:20 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: Date: Sat, 29 Jan 2022 22:25:17 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US From: Stefan Esser To: FreeBSD CURRENT Subject: Kernel changes causing AMDGPU / DRM to fail? i2c related? Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------FVa8KjCSzfw1wj5MC00K3S4G" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643491522; 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=ExGS+VIk6aK6a6NIbtRSs9MnGe3Qe66claapPcYO6PI=; b=gHml+fGrmUu0bbx/NYDMHHPylk0OHbsxz71QK/ldwS+3yZoHOlxzs9V/rVmEYU1atRpq/a OrOBcwOMBMutBw0hFIq7JLnwbXnTF9kCDZSmAKVkPG04u3DC5ymF+RDewt5lSeYPrI8XVg EDk3k+SaDlwJSuNXUd6dbaJIePI3U11C2H8QZizWWT5KuoCFEcE3vEqkz9skMyUoACCYES ElqzaGDWhtcJs/Jn2iyn9aWJXV5Dsi81348lvUy7YOr3jfJt4cPuEJLeDlZrmfWK0o0Bb3 KneK/mgNU/c6uYqZN5Wdr2tCxU6I4vNotQk0ldeFFAqNZjwNHwGIULgdnnfF8g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643491522; a=rsa-sha256; cv=none; b=ceWQonbfG0KIfQQaIqPHoyssS6PCHuFRpIuYConE5c5FsLw0jsDzl7A+fy/lUw6M7lz/xg P+vXZWCR0a4hI72RNcqVkY4MUh6eFiIBZTT8BPz099hA3wOXB5F3NDV1I9FCRne3SUmS4Q 71BOVGMGYxvLRVw2NkyG63o0aDeeW1z4pmxKKEJfUNYUTUuZ+NJ0wApyUp4XwK5aGw95ep qKECjJIwVIHlJG8wnvCj1cpqZH3yNdDNDTEkYC2myAZrGjfhhgNQhleexxaPRFCmHBlHjh E30wDFx7I+jUA2Dfb1X35qPX4UZBibRAo1bcmvYm9cNXHINHuDi4rSjs21Jh7w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------FVa8KjCSzfw1wj5MC00K3S4G Content-Type: multipart/mixed; boundary="------------p9TPy0mjPlFxg7x05eUIdmJV"; protected-headers="v1" From: Stefan Esser To: FreeBSD CURRENT Message-ID: Subject: Kernel changes causing AMDGPU / DRM to fail? i2c related? --------------p9TPy0mjPlFxg7x05eUIdmJV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable After rebooting with freshly built world, kernel and the amdgpu driver my console stopped working. It goes blank and the display goes into a power save mode, as soon as the amdgpu driver is loaded. The GPU (a Radeon R7 250E) is correctly detected as before, but there is an error message "drmn0: [drm] Cannot find any crtc or sizes". I'm asking here and not on the ports list, since the AMDGPU driver has not been updated for half a year. But to be sure that there is no mismatc= h between kernel and user land, I have rebuilt all X11 server and library ports. There have been changes affecting the i2c driver, IIRC, and the error message seems to point at an issue obtaining information from the LCD display. The output of "grep drm /var/run/dmesg.boot" follows: [drm] amdgpu kernel modesetting enabled. drmn0: on vgapci0 vgapci0: child drmn0 requested pci_enable_io vgapci0: child drmn0 requested pci_enable_io [drm] initializing kernel modesetting (VERDE 0x1002:0x683F 0x174B:0xA001 = 0x00). [drm] register mmio base: 0xFCE00000 [drm] register mmio size: 262144 [drm] add ip block number 0 [drm] add ip block number 1 [drm] add ip block number 2 [drm] add ip block number 3 [drm] add ip block number 4 [drm] add ip block number 5 [drm] add ip block number 6 [drm] BIOS signature incorrect 0 0 [drm] vm size is 512 GB, 2 levels, block size is 10-bit, fragment size is= 9-bit drmn0: successfully loaded firmware image 'amdgpu/verde_mc.bin' drmn0: VRAM: 1024M 0x000000F400000000 - 0x000000F43FFFFFFF (1024M used) drmn0: GART: 1024M 0x000000FF00000000 - 0x000000FF3FFFFFFF [drm] Detected VRAM RAM=3D1024M, BAR=3D256M [drm] RAM width 128bits GDDR5 [drm] amdgpu: 1024M of VRAM memory ready [drm] amdgpu: 3072M of GTT memory ready. [drm] GART: num cpu pages 262144, num gpu pages 262144 drmn0: PCIE GART of 1024M enabled (table at 0x000000F400500000). [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). drmn0: successfully loaded firmware image 'amdgpu/verde_pfp.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_me.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_ce.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_rlc.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_smc.bin' [drm] Internal thermal controller without fan control [drm] amdgpu: dpm initialized [drm] Connector DP-1: get mode from tunables: [drm] - kern.vt.fb.modes.DP-1 [drm] - kern.vt.fb.default_mode [drm] Connector HDMI-A-1: get mode from tunables: [drm] - kern.vt.fb.modes.HDMI-A-1 [drm] - kern.vt.fb.default_mode [drm] Connector DVI-I-1: get mode from tunables: [drm] - kern.vt.fb.modes.DVI-I-1 [drm] - kern.vt.fb.default_mode [drm] AMDGPU Display Connectors [drm] Connector 0: [drm] DP-1 [drm] HPD4 [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY2 [drm] Connector 1: [drm] HDMI-A-1 [drm] HPD1 [drm] DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY2 [drm] Connector 2: [drm] DVI-I-1 [drm] HPD2 [drm] DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b [drm] Encoders: [drm] DFP3: INTERNAL_UNIPHY [drm] CRT1: INTERNAL_KLDSCP_DAC1 drmn0: [drm] Cannot find any crtc or sizes drmn0: [drm] Cannot find any crtc or sizes drmn0: [drm] Cannot find any crtc or sizes [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 A successful driver attach from a reboot a few days ago had ended in: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] fb mappable at 0xE0503000 [drm] vram apper at 0xE0000000 [drm] size 33177600 [drm] fb depth is 24 [drm] pitch is 15360 [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 Regards, STefan --------------p9TPy0mjPlFxg7x05eUIdmJV-- --------------FVa8KjCSzfw1wj5MC00K3S4G Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmH1sL0FAwAAAAAACgkQR+u171r99UQC OQgAzAUuy2P+Uyph5gkj9GAQU9DR2t5VSsLTnAFISOcmRmX4+9g4Z4WmaSS7l8oJvHXTHe8PlpOt oN0mqec5jsWHoZLzbNm+Od3hHVhWKDSFmo20FXxbWrpUxV1Mo9BtHRF3LR+01Y6egvv585W5iEUO 4nqXBreHluZPvK5L2EEbrclRvBl4KzQZGg+YgABqPhataSy0cqAaNfUNGsLinIhUunSvbtb6VWv3 EKOOXkvuBUSN4Q/4jZlQaoIdYdbkZsp31b7+5M01swA9kY+sDMCUJV/xB0nGfAfssNPSCUsWR/D8 H7kSBxKCJr1Azsf3Y42EihLrfbZLKbVeqpH10BuF6Q== =DD/u -----END PGP SIGNATURE----- --------------FVa8KjCSzfw1wj5MC00K3S4G-- From nobody Sat Jan 29 22:25:49 2022 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 ACF7119858FD for ; Sat, 29 Jan 2022 22:25:54 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmTS13Z1Sz3HpJ; Sat, 29 Jan 2022 22:25:52 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 20TMPnxF006524; Sun, 30 Jan 2022 07:25:49 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 30 Jan 2022 07:25:49 +0900 From: Tomoaki AOKI To: Stefan Esser Cc: FreeBSD CURRENT Subject: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related? Message-Id: <20220130072549.85a1365c78a5779238d72183@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JmTS13Z1Sz3HpJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-0.59 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Sat, 29 Jan 2022 22:25:17 +0100 Stefan Esser wrote: > After rebooting with freshly built world, kernel and the amdgpu driver > my console stopped working. It goes blank and the display goes into a > power save mode, as soon as the amdgpu driver is loaded. > > The GPU (a Radeon R7 250E) is correctly detected as before, but there > is an error message "drmn0: [drm] Cannot find any crtc or sizes". > > I'm asking here and not on the ports list, since the AMDGPU driver has > not been updated for half a year. But to be sure that there is no mismatch > between kernel and user land, I have rebuilt all X11 server and library > ports. > > There have been changes affecting the i2c driver, IIRC, and the error > message seems to point at an issue obtaining information from the LCD > display. > > The output of "grep drm /var/run/dmesg.boot" follows: > > [drm] amdgpu kernel modesetting enabled. > drmn0: on vgapci0 > vgapci0: child drmn0 requested pci_enable_io > vgapci0: child drmn0 requested pci_enable_io > [drm] initializing kernel modesetting (VERDE 0x1002:0x683F 0x174B:0xA001 0x00). > [drm] register mmio base: 0xFCE00000 > [drm] register mmio size: 262144 > [drm] add ip block number 0 > [drm] add ip block number 1 > [drm] add ip block number 2 > [drm] add ip block number 3 > [drm] add ip block number 4 > [drm] add ip block number 5 > [drm] add ip block number 6 > [drm] BIOS signature incorrect 0 0 > [drm] vm size is 512 GB, 2 levels, block size is 10-bit, fragment size is 9-bit > drmn0: successfully loaded firmware image 'amdgpu/verde_mc.bin' > drmn0: VRAM: 1024M 0x000000F400000000 - 0x000000F43FFFFFFF (1024M used) > drmn0: GART: 1024M 0x000000FF00000000 - 0x000000FF3FFFFFFF > [drm] Detected VRAM RAM=1024M, BAR=256M > [drm] RAM width 128bits GDDR5 > [drm] amdgpu: 1024M of VRAM memory ready > [drm] amdgpu: 3072M of GTT memory ready. > [drm] GART: num cpu pages 262144, num gpu pages 262144 > drmn0: PCIE GART of 1024M enabled (table at 0x000000F400500000). > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > drmn0: successfully loaded firmware image 'amdgpu/verde_pfp.bin' > drmn0: successfully loaded firmware image 'amdgpu/verde_me.bin' > drmn0: successfully loaded firmware image 'amdgpu/verde_ce.bin' > drmn0: successfully loaded firmware image 'amdgpu/verde_rlc.bin' > drmn0: successfully loaded firmware image 'amdgpu/verde_smc.bin' > [drm] Internal thermal controller without fan control > [drm] amdgpu: dpm initialized > [drm] Connector DP-1: get mode from tunables: > [drm] - kern.vt.fb.modes.DP-1 > [drm] - kern.vt.fb.default_mode > [drm] Connector HDMI-A-1: get mode from tunables: > [drm] - kern.vt.fb.modes.HDMI-A-1 > [drm] - kern.vt.fb.default_mode > [drm] Connector DVI-I-1: get mode from tunables: > [drm] - kern.vt.fb.modes.DVI-I-1 > [drm] - kern.vt.fb.default_mode > [drm] AMDGPU Display Connectors > [drm] Connector 0: > [drm] DP-1 > [drm] HPD4 > [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 > [drm] Encoders: > [drm] DFP1: INTERNAL_UNIPHY2 > [drm] Connector 1: > [drm] HDMI-A-1 > [drm] HPD1 > [drm] DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f > [drm] Encoders: > [drm] DFP2: INTERNAL_UNIPHY2 > [drm] Connector 2: > [drm] DVI-I-1 > [drm] HPD2 > [drm] DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b > [drm] Encoders: > [drm] DFP3: INTERNAL_UNIPHY > [drm] CRT1: INTERNAL_KLDSCP_DAC1 > drmn0: [drm] Cannot find any crtc or sizes > drmn0: [drm] Cannot find any crtc or sizes > drmn0: [drm] Cannot find any crtc or sizes > [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 > > A successful driver attach from a reboot a few days ago had ended in: > > [drm] CRT1: INTERNAL_KLDSCP_DAC1 > [drm] fb mappable at 0xE0503000 > [drm] vram apper at 0xE0000000 > [drm] size 33177600 > [drm] fb depth is 24 > [drm] pitch is 15360 > [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 > > Regards, STefan Are you sure your ports tree is up-to-date and graphics/drm-*-kmod you installed (IIRC, should be needed for -intel and -amdgpu drivers) is also updated? drm-*-kmod could be affected by LinuxKPI updates in base. *There can be some (sometime very wide) timeframe between LinuxKPI update and corresponding linux-*-kmod catches up with it. Looking into cgit.freebsd.org, at least drm-current-kmod is updated 36 hours ago. Not sure it's related or not, though. *I always prefer nvidia dGPU because of these dangerous span. So I've forced to choose ThinkPad P series (without "s") which usually can disable CPU-integrated Intel GPU and run nvidia GPU alone though BIOS setting. -- Tomoaki AOKI From nobody Sat Jan 29 22:59:53 2022 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 78574199AAE1; Sat, 29 Jan 2022 22:59:56 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmVCJ2CNjz3mJq; Sat, 29 Jan 2022 22:59:56 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643497196; 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=OGvSVKYjYzn1C5wS9Jd9xF+Hb+bHnvQR3X50d4fpSug=; b=l9v62YwgIiJmMyoCSgxPC9+sXrEzxgGvrz6bX4x80E59A9p1relmGoA+xdN+GWMuRBn93c HXp8kVmT188ly4u4LiabD+0pHHVOL94dckUVoixVXufZqrZIsMqnErkTWgLl8t5/mFE1S/ cLQ1FU9rvsmhddsJ9s4h0K7U5BaEDDOUA6ilw1PEI2sp+sUYi+WkhC731xSgDpDA21ifsf 3fWCGFIs6xopy8lc7GjWKMmoGkejIC9Xe3dsSdEcvgt5s48ORa3+0qGUanj2kL1p0vRbLp 83QziOVH9gZXm++SEwKl14QoegFSb7syPKZX/LujW27WuMpoMi03YiKw6JI9MQ== Received: from [IPV6:2003:cd:5f0c:9800:b50a:1ab6:2f63:fb85] (p200300cd5f0c9800b50a1ab62f63fb85.dip0.t-ipconnect.de [IPv6:2003:cd:5f0c:9800:b50a:1ab6:2f63:fb85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 9647B2E52F; Sat, 29 Jan 2022 22:59:55 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: Date: Sat, 29 Jan 2022 23:59:53 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Latest drm-devel-kmod port not working? (was: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?) Content-Language: de-DE To: Tomoaki AOKI , x11@freebsd.org Cc: FreeBSD CURRENT References: <20220130072549.85a1365c78a5779238d72183@dec.sakura.ne.jp> From: Stefan Esser In-Reply-To: <20220130072549.85a1365c78a5779238d72183@dec.sakura.ne.jp> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------QLR7m6aktuDOmnFFnvgNa15V" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643497196; 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=OGvSVKYjYzn1C5wS9Jd9xF+Hb+bHnvQR3X50d4fpSug=; b=Ejzfvms8zhQi+hGqmmfS34RIRA6DKqKM9/gfjdSL7CJ97HrpHaSK1nRYnvKulNutg6S9Ok 55SmmFcnJ4aOG5wsGrwNURyBUM73jk4jw7RhK0bR684VeAvNTKjYWVlb6LoKgyZDX0ayKa B8kAVH9STZE6qh8y/R2SV+QE39s5AuHHKV21hHWNQ7b79b+9bBYiH/M9b/+YoiAhBs2HVh FHLYTUXUafunbn+PfNqZ2HXtzWxnoECSQGoeb5NgvlMOsTgg7I/hjOHhfl4dX0zD+eWUNA n3kO6EzNH2M+Jn/xTDFeg0e0KyYjlGV0WUyaOvrhFqAddVHYsc8XnxMce7D8JA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643497196; a=rsa-sha256; cv=none; b=fVBq2YFH5kayEbC4SGem+Ss+sOWItgUdOBbj8JUAC5vgYswqR95ytzIHd/Bp+xGZHEVtdA GEdIvO4bmRn1UtUWr1ZZxuiiwL2JNNt4PCTgi1IwCKoXEZoQizITEGTQy+d5EgvejLDT32 idzWdWZH6fExZ7QkmlQZ7R6wjtzB9E/OrH7OV9dLb0hk+wq2w/ejgM/JuLMB4CJ26FRLGL z6ymVNBtiuM1K7JiMwxpKFdnH09jBiucKD1HktEEYhuVOFHGhaninXQzUwB6kFcvKJxK1g 4m4ASM9joZ+JCvgzuvPQfateVVccTop21eT2VoYQdhfLSdgWQEY8p5IdirPTTQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------QLR7m6aktuDOmnFFnvgNa15V Content-Type: multipart/mixed; boundary="------------jsV0PxIPDTHgxFwXO60CNg0V"; protected-headers="v1" From: Stefan Esser To: Tomoaki AOKI , x11@freebsd.org Cc: FreeBSD CURRENT Message-ID: Subject: Latest drm-devel-kmod port not working? (was: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?) References: <20220130072549.85a1365c78a5779238d72183@dec.sakura.ne.jp> In-Reply-To: <20220130072549.85a1365c78a5779238d72183@dec.sakura.ne.jp> --------------jsV0PxIPDTHgxFwXO60CNg0V Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 29.01.22 um 23:25 schrieb Tomoaki AOKI: > On Sat, 29 Jan 2022 22:25:17 +0100 > Stefan Esser wrote: >=20 >> After rebooting with freshly built world, kernel and the amdgpu driver= >> my console stopped working. It goes blank and the display goes into a >> power save mode, as soon as the amdgpu driver is loaded. >> >> The GPU (a Radeon R7 250E) is correctly detected as before, but there >> is an error message "drmn0: [drm] Cannot find any crtc or sizes". [...] > Are you sure your ports tree is up-to-date and graphics/drm-*-kmod > you installed (IIRC, should be needed for -intel and -amdgpu drivers) > is also updated? drm-*-kmod could be affected by LinuxKPI updates in > base. Yes, I rebuild the system from sources at least once a day, but do only reboot every few days, especially if there has been any change that might cause incompatibilities between kernel and user land. And I always rebuild all KLDs together with the kernel, including all the driver module ports relevant for X11. > *There can be some (sometime very wide) timeframe between LinuxKPI > update and corresponding linux-*-kmod catches up with it. X11 was working just fine on a system built and rebooted a few days ago. > Looking into cgit.freebsd.org, at least drm-current-kmod is updated 36 > hours ago. Not sure it's related or not, though. I had missed that update - and YES you are right. I'm using the devel version and after reverting the update to drm_v5.5.19_7 the driver does attach again. Thanks for the hint! > *I always prefer nvidia dGPU because of these dangerous span. > So I've forced to choose ThinkPad P series (without "s") which > usually can disable CPU-integrated Intel GPU and run nvidia GPU > alone though BIOS setting. I had issues with Nvidia cards (and the closed source driver modules and libraries) before and for that reason bought a passively cooled Radeon card for this development workstation. Best regards, STefan --------------jsV0PxIPDTHgxFwXO60CNg0V-- --------------QLR7m6aktuDOmnFFnvgNa15V Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmH1xukFAwAAAAAACgkQR+u171r99UTZ IAf/eBuIpV5aLt/NMvZE6O6J2PoTxYIZj3199fhKCE/5tFJtICSMK6lrxacJDkJ0KRf5IIto92io f6g4Fmxs+EokcOUXAlb9ZVvlTOKrKDWWxAdqX9uErHjFCHInFT3INUFrSHIncBiCJdndqAb/B7Ut O46fa8POKWKqtwxzmWZyydyU0N3sA8/222dVxvl7tGZRa7ti1fhCQXs50vDYNObte0J1+GjIcDDD M6gFvhok2oexMGK87dvtSA9AD4Q4oMqSGUmpyhHMDdHy/R+Xz0SmNtk6w/mtpeb45wx9JDbQ8YR8 kdaU7fMhR7wC58SWL95NdCZ+4u3aoMVxe8+I0LrttA== =pMRs -----END PGP SIGNATURE----- --------------QLR7m6aktuDOmnFFnvgNa15V-- From nobody Sun Jan 30 00:39:46 2022 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 7D6FD1991D39 for ; Sun, 30 Jan 2022 00:40:28 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JmXRH1tWvz3G4v for ; Sun, 30 Jan 2022 00:40:26 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 20U0dmYx021497; Sun, 30 Jan 2022 09:39:48 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 30 Jan 2022 09:39:46 +0900 From: Tomoaki AOKI To: David Wolfskill Cc: FreeBSD CURRENT Subject: Re: On choice of graphics for laptops [Was: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?] Message-Id: <20220130093946.c1841167b472195630908abf@dec.sakura.ne.jp> In-Reply-To: References: <20220130072549.85a1365c78a5779238d72183@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JmXRH1tWvz3G4v X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.60 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; ARC_NA(0.00)[]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received] X-ThisMailContainsUnwantedMimeParts: N On Sat, 29 Jan 2022 15:33:34 -0800 David Wolfskill wrote: > On Sun, Jan 30, 2022 at 07:25:49AM +0900, Tomoaki AOKI wrote: > > ... > > *I always prefer nvidia dGPU because of these dangerous span. > > So I've forced to choose ThinkPad P series (without "s") which > > usually can disable CPU-integrated Intel GPU and run nvidia GPU > > alone though BIOS setting. > > .... > > But then you lose suspend/resume, yes? > > Peace, > david (who has been using Dell laptops w/ Nvidia for years...) > -- > David H. Wolfskill david@catwhisker.org > Republican Senators had two chances to hold Donald Trump accountable > for his malfeasance in office during his term -- and utterly failed. > > See https://www.catwhisker.org/~david/publickey.gpg for my public key. Unfortunately, yes. Suspend/resume never worked for me after APM is gone... (This means ACPI never allowed me to suspend/resume.) I preferred safety on update rather than convenience of suspend/resume. IIRC, in APM era, ATI (!) dGPU (no internal GPU existed) could sanely suspend/resume. Already cannot confirm, though. I started using nvidia dGPU models when no accelerated drivers were provided for newly shipped notebooks with Intel or ATI (AMD) GPUs (interlal or descrete). ITOH, nvidia "usually" provides their FreeBSD drivers before notebooks are discontinued. *There WAS a crisis, though, WRT FreeBSD kernel functionality. Once Linux kernel functionality that graphics drivers use become fixed (no more KPI changes needed) and FreeBSD LinuxKPI catches up with it, I can choose any notebook with (non-nvidia) internal GPU only or with AMD dGPUs. -- Tomoaki AOKI From nobody Sun Jan 30 14:01:33 2022 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 2DDF5198FE45 for ; Sun, 30 Jan 2022 14:01:45 +0000 (UTC) (envelope-from fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com) Received: from mta-64-227.siemens.flowmailer.net (mta-64-227.siemens.flowmailer.net [185.136.64.227]) (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 4JmtCq5LnLz5377 for ; Sun, 30 Jan 2022 14:01:43 +0000 (UTC) (envelope-from fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com) Received: by mta-64-227.siemens.flowmailer.net with ESMTPSA id 20220130140134635822a728a3855306 for ; Sun, 30 Jan 2022 15:01:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm1; d=siemens.com; i=michael.osipov@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To; bh=lpNDNo0TQpZXW6Of7rZQip1To8S5cs1R2a+iabgsadI=; b=OS1UhWvLdBw/jF4d2CzSLB1DD6tQVPEGB+Da8MsBb5NYhqIyuLijxvtv996FZeH3zumfoU +D1OfP/l2sY3ZFDbji5Cgweo/+5WZjG5X5LsFt8Qwmz4fkYAiHVDYtMLcjvdzlx+NO0K4BET BFOkd0lS8F8Hq6jr3rXrzeAtKANGc=; Message-ID: <835dc887-6491-602c-7d71-d99309871126@siemens.com> Date: Sun, 30 Jan 2022 15:01:33 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: michael.osipov@siemens.com Subject: Re: Dragonfly Mail Agent (dma) in the base system Content-Language: de-DE In-Reply-To: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-7517:519-21489:flowmailer X-Rspamd-Queue-Id: 4JmtCq5LnLz5377 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=siemens.com header.s=fm1 header.b=OS1UhWvL; dmarc=pass (policy=none) header.from=siemens.com; spf=pass (mx1.freebsd.org: domain of fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com designates 185.136.64.227 as permitted sender) smtp.mailfrom=fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[185.136.64.227:from]; R_SPF_ALLOW(-0.20)[+ip4:185.136.64.224/29]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[siemens.com:+]; DMARC_POLICY_ALLOW(-0.50)[siemens.com,none]; FORGED_SENDER(0.30)[michael.osipov@siemens.com,fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50018, ipnet:185.136.64.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[michael.osipov@siemens.com,fm-7517-20220130140134635822a728a3855306-MmR4lo@rts-flowmailer.siemens.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[siemens.com:s=fm1]; DWL_DNSWL_MED(-2.00)[siemens.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[1.000]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[185.136.64.227:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Ed, thanks for raising, this is just on time for us. I'd like to describe what both cover and not cover and I would expect from a minimal MTA. I am on 12-STABLE/12.3-RELEASE. We solely use sendmail with relay via sendmail invocation or SMTP on localhost:25. Minimal configuration for scripts and applications running on hosts and jails. Our current corporate messaging service is being phased out for a new one which requires authentication via LOGIN or PLAIN and mandatory STARTTLS, previous was anonymous and unencrypted. Sendmail: The biggest problem is that authentication strictly requires Cyrus SASL, even for stupid ones like PLAIN/LOGIN, accourding to the handbook you must recompile sendmail from base with Cyrus SASL from ports to make this possible. A showstopper actually, for two reasons: 1. I don't like mixing base and ports, it just creates a messy system. 2. While this may work with hosts, when you have jails running off a RELEASE in Bastille this obviously will not work. Not going to work with sendmail easily. DMA: Disclaimer: I haven't tried, but read documentation and source code. Although it supports TLS, I don't see any of these [1], I fail to see how it verifies the peer. I have never seen something to provide the server's fingerprint to verification. It very much feels like an SSH-like approach. It does not listen, as documented, on localhost, so applications supporting SMTP only will need extra configuration to reach out to the relay host directly. Central config at MTA side not possible anymore. Although, I don't need certificate-based authentication against the relay and DMA supports it, it does not support of using a passphrase for the certificate key file like HTTPd supports through mod_ssl. Should be a no-brainer these days. Requirements for a simplistic MTA with a relay host: * Support TLS or STARTTLS through OpenSSL in base * Verify server's certificate chain against default certstore (/etc/ssl/certs) and log success/failure, e.g, sendmail does this after config * Properly rewrite FROM for local users user@localhost or even <> when delivered with sendmail executable * Accept messages on localhost:25 or a configurable loopback address in general (e.g., multihomed with cloned interface and jails) for those applications which only support SMTP (e.g., Java Mail or other programming libraries) The issues with certificates and OpenSSL in the base system I have already extensively dicussed with kevans@ [2]. I hope this can be put into consideration. Regards, Michael [1] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_default_verify_paths.html [2] https://reviews.freebsd.org/D31487#710650 From nobody Sun Jan 30 14:18:18 2022 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 AA799199B195 for ; Sun, 30 Jan 2022 14:19:02 +0000 (UTC) (envelope-from fm-7517-202201301418591d13caeaac1ae6db19-pTza04@rts-flowmailer.siemens.com) Received: from mta-64-227.siemens.flowmailer.net (mta-64-227.siemens.flowmailer.net [185.136.64.227]) (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 4Jmtbn58c0z59Nr for ; Sun, 30 Jan 2022 14:19:01 +0000 (UTC) (envelope-from fm-7517-202201301418591d13caeaac1ae6db19-pTza04@rts-flowmailer.siemens.com) Received: by mta-64-227.siemens.flowmailer.net with ESMTPSA id 202201301418591d13caeaac1ae6db19 for ; Sun, 30 Jan 2022 15:19:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm1; d=siemens.com; i=michael.osipov@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:References:In-Reply-To; bh=cT0nFf8Ef1/Wdtt1V0xGJ6lG3LBvU0govqxGfeTM47M=; b=YfF153wLSF8Qf2WjC3dNKsOj3z08QX6mPKm/c4kokTPsAlNA2+FrqiXHx1R0fp5vLQz7od xUQtDvMZU8LY2s7oOC/010pdYEdXAGrJTi6mo7ojnZgn5cuQO6qf73ghUwGTyVz/bGOehNPk kCEpAIJTY1mfjusuf68JLMNGPo4Ls=; Message-ID: <5d96363b-3bc1-bfdc-169e-3f6a273a00cd@siemens.com> Date: Sun, 30 Jan 2022 15:18:18 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Subject: Re: Dragonfly Mail Agent (dma) in the base system Content-Language: de-DE To: freebsd-current@freebsd.org References: <835dc887-6491-602c-7d71-d99309871126@siemens.com> From: michael.osipov@siemens.com In-Reply-To: <835dc887-6491-602c-7d71-d99309871126@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-7517:519-21489:flowmailer X-Rspamd-Queue-Id: 4Jmtbn58c0z59Nr X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=siemens.com header.s=fm1 header.b=YfF153wL; dmarc=pass (policy=none) header.from=siemens.com; spf=pass (mx1.freebsd.org: domain of fm-7517-202201301418591d13caeaac1ae6db19-pTza04@rts-flowmailer.siemens.com designates 185.136.64.227 as permitted sender) smtp.mailfrom=fm-7517-202201301418591d13caeaac1ae6db19-pTza04@rts-flowmailer.siemens.com X-Spamd-Result: default: False [-5.69 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[185.136.64.227:from]; R_SPF_ALLOW(-0.20)[+ip4:185.136.64.224/29:c]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[siemens.com:+]; DMARC_POLICY_ALLOW(-0.50)[siemens.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.995]; FORGED_SENDER(0.30)[michael.osipov@siemens.com,fm-7517-202201301418591d13caeaac1ae6db19-pTza04@rts-flowmailer.siemens.com]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50018, ipnet:185.136.64.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[michael.osipov@siemens.com,fm-7517-202201301418591d13caeaac1ae6db19-pTza04@rts-flowmailer.siemens.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[siemens.com:s=fm1]; DWL_DNSWL_MED(-2.00)[siemens.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[185.136.64.227:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Am 2022-01-30 um 15:01 schrieb michael.osipov@siemens.com: > Requirements for a simplistic MTA with a relay host: > * Support TLS or STARTTLS through OpenSSL in base > * Verify server's certificate chain against default certstore > (/etc/ssl/certs) and log success/failure, e.g, sendmail does this after > config > * Properly rewrite FROM for local users user@localhost or even <> when > delivered with sendmail executable > * Accept messages on localhost:25 or a configurable loopback address in > general (e.g., multihomed with cloned interface and jails) for those > applications which only support SMTP (e.g., Java Mail or other > programming libraries) Another feature I have forgot: * .forward support. All mails received on a Unix account shall be redirected to the user's email address. Michael From nobody Sun Jan 30 14:40:06 2022 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 DC053197F1E4 for ; Sun, 30 Jan 2022 14:40:19 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jmv4L5YVYz3KPB for ; Sun, 30 Jan 2022 14:40:18 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-lj1-x232.google.com with SMTP id bx31so4259225ljb.0 for ; Sun, 30 Jan 2022 06:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XfdNyMO2BvRfBUOLgNnsMXO+PKuQfGxzZ//KkNF9Z/A=; b=4fRbbueS08Pk0J3LF45CcHro+T15VUCbW3sMofxEKmvm3AV4ZFCGCYIM77EROCgOJV alEKZYqYJVNc2kU1uNNVPl4cGUEefb8jHwErFcNYgm1/XmGaHTHFMkEgzFTbauKZnUrs bS6utcr3UAE3IDDecpqvRChsJH/jxoAoLFYh83MwnALNGIgMtogI1zL0qKinZR/FeYRX 5rB7DsbQ95DnkXEZ/0HQjrRvGia77UnN9MLYUyM9BrhsId14pD9k+tM9xEg0JNQumruh ZKyG6tfjqwmaTd0oaNnoaxaNxR0d4JrTvoIA/dDhC+jj/shGLcgeJDeTFFDIxyzkR4jI zzjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XfdNyMO2BvRfBUOLgNnsMXO+PKuQfGxzZ//KkNF9Z/A=; b=2tEJHXwr5VrNHkzZ0PsjltDuMnBK60m0bdi23XI0YzBMZqIFi+y/w4XI+sJbyLrPnY caHb5YmANRosbjIFGM5YLOQKi6zYg2IIGKNL1/kYf2HT10sz6hPMVI98f4YYfY98Fw88 My+sgpsVG3A7jw+Av91iNSc69iqGRfsSCvZ/4jDvKfjviR1Ddf3txiNPF5jNq2i2zCZx MoUtiQiYxHFYRtkftRboKVsHBVccaDUqhOqre++ocn2aWKem59sOnTZMJO+DFRAqFELk gklLSEjlfmaBbIZSCA4eY16tfh8/0rH/Z2L3OZCIv73wV9CiBn0LcLXnXtsgTlnIC/6l tuNA== X-Gm-Message-State: AOAM5337bBeiQnNXUSQBF56EFNRKY0BlzoQsg2x3BigKXIgothfIZRum OaA4osTmn8OWJXSqLZAYRlooJ06Za49qYvS7BbZm1fzqcDU= X-Google-Smtp-Source: ABdhPJwy0DSMeMfNRkTebAYwJYr11Nk0xZNOVPYYnoqI05aiwWv/CdFiWbGRdJ5NGypepWyaHLKi/q1KHr4fS3VwGGI= X-Received: by 2002:a2e:80d2:: with SMTP id r18mr6668496ljg.474.1643553611366; Sun, 30 Jan 2022 06:40:11 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <1ec9c802-c8a5-237a-50a3-31885cae917e@plan-b.pwste.edu.pl> <77736438-0211-faf8-926d-2805dd9b40da@plan-b.pwste.edu.pl> In-Reply-To: <77736438-0211-faf8-926d-2805dd9b40da@plan-b.pwste.edu.pl> From: Marcin Wojtas Date: Sun, 30 Jan 2022 15:40:06 +0100 Message-ID: Subject: Re: HEADS-UP: PIE enabled by default on stable/13 To: Marek Zarychta Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Jmv4L5YVYz3KPB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=4fRbbueS; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2a00:1450:4864:20::232) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [-1.49 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[semihalf-com.20210112.gappssmtp.com:s=20210112]; FREEFALL_USER(0.00)[mw]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.989]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; NEURAL_SPAM_MEDIUM(0.80)[0.803]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::232:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, pon., 24 sty 2022 o 20:48 Marek Zarychta napisa=C5=82(a): > > Hello Marcin > W dniu 24.01.2022 o 19:43, Marcin Wojtas pisze: > > Hi Marek, > > > > pon., 24 sty 2022 o 08:17 Marek Zarychta > > napisa=C5=82(a): > >> > >> W dniu 24.01.2022 o 07:42, Marcin Wojtas pisze: > >>> +freebsd-stable@ > >>> > >>> niedz., 23 sty 2022 o 11:36 Marcin Wojtas napisa=C5= =82(a): > >>>> > >>>> Hi, > >>>> > >>>> As of 396e9f259d962 the base system binaries are now built as positi= on-independent executable (PIE) by default, for 64-bit architectures. Thank= s to that enabling ASLR can be done simply > >>>> by sysctls knobs when booting the kernel. > >>>> > >>>> If you track stable/13 and normally build WITHOUT_CLEAN you'll need = to do one initial clean build -- either run `make cleanworld` or set WITH_C= LEAN=3Dyes. > >>>> > >>>> The change is a pure MFC of the changes integrated to -CURRENT early= 2021 and no issues are expected, but in case any problems are observed, pl= ease issue a PR and/or let me know in this thread. > >>>> > >>>> Best regards, > >>>> Marcin > >>> > >> > >> Thanks for enabling this. If I understand it correctly we got some > >> improvements mentioned here[1] and it doesn't imply that ASLR has to b= e > >> enabled, especially kern.elf64.aslr.pie_enable can be still set to 0 ? > >> > > > > Currently it still remains opt-in on stable/13 and is disabled by defau= lt. > > > > Best regards, > > Marcin > > Thanks for the answer. I am not willing to turn ASLR on at this point, > but rather asking if my world, already built with PIE, will bring any > other enhancements or improvements? > If your world is already built with PIE, the MFC'ed patches should make no difference at all. Best regards, Marcin > > > >> > >> [1] https://www.mail-archive.com/freebsd-current@freebsd.org/msg183605= .html > >> > > > With kind regards, > > -- > Marek Zarychta From nobody Sun Jan 30 18:23:49 2022 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 B7F7B1981F20 for ; Sun, 30 Jan 2022 18:23:55 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jn02M33Nbz4b3j for ; Sun, 30 Jan 2022 18:23:55 +0000 (UTC) (envelope-from wulf@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643567035; 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=Pra/yrAM2fg4F6Qe9Lzl/mJUWmGcMY9Fq/MBg3ZEG0Q=; b=p0tsuLVfdn2Eg6e0M8MmRDBuqdugZxK/jlgr103y/ZfV3JMZJbztXDYRUyDdjl5A+3N+rg vmlOHEaNtxWCawf3PkIhI9ba8UyT9GrHYrcRTbC8VF2XeL8bZ8HxEvr+uybnuQAyYDpJAp zwjDfJPrvhzdsEe2xBI/tnA3YdAjwyfikDZ/9hdeN3E2y8HivYd8j05+GlIb7Fy7OAoEUN YSjdTUtLg7lCkURUuoXukO8uBRJSGpJic+Fb/77k9rgNxMLCGEQEHiB9ELYD3+9ilz0CM0 NSYd3JqCQapizifDSUtv4+lzRGG0CNTeszfA27BQcHoFJsgiaqFd8uMG7E8/xw== Received: from [192.168.0.30] (unknown [176.120.228.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: wulf) by smtp.freebsd.org (Postfix) with ESMTPSA id 022B280BA for ; Sun, 30 Jan 2022 18:23:54 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Message-ID: <4611d16a-ef17-d8f3-c2c0-1b1091723646@FreeBSD.org> Date: Sun, 30 Jan 2022 21:23:49 +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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related? Content-Language: en-US To: freebsd-current@freebsd.org References: From: Vladimir Kondratyev In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643567035; 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=Pra/yrAM2fg4F6Qe9Lzl/mJUWmGcMY9Fq/MBg3ZEG0Q=; b=e+L4nq+SQoMQazsGvsO49kx/kDQPxUWR8X7U4q5xZmuksIcHlZfqWgVoe9m94aQ8Tgs7V/ bNBBSEH/FRowNOEH7LCxE0XjRsImkWKXyj4AmwdSCEQ9+bDyOaylTsWAJt3I0eA34QFEJd TnFAPSMTuF52WzLyLftjTbm0Lhp1miQAGIVRDlpJ6H9aYugsNu+xB2Gw6RbN6dAMA+ZcFA KdoN37BdX78RVCL+ycaLHSXaw0OnqRM+0p6SsgcdaE6OWUzgGRqFgX6Hn2RMaLhN0MNDxC +ryl0Oljzc/g7d8WP43BVjclytnAKkoo0OwuMMhBZa3dG8DfkzwxO1N9c3fmyg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643567035; a=rsa-sha256; cv=none; b=duHWVx0+A910hwjRVKgMtb3i9g+9573qDJD362lNzV08nHOwIN7MQIcZ1zLF/2XXmm1vO0 HjPcJd0h3s3XUAUUU54FOxf7jBcWUYMK42QbuMs4nygvwg+MYIvnWSHWDP68gEM/zF/cD+ 0ezP+SlIuwpGM+5pa74fYzmvI5Tg6hd8dojfjbkXmaZiFHQmkFStH2BJHwcL+508ybnopi IfaAyDX3hl9at47Opwe+ae/psnDil1/a76WCXKk5MlVdawv8XwUCsMy/whtU/Hy88pkL4N NqlfL/3w5hC7PKlmkHKNRZp0mfYlrlo3mX0O7ZDF/o9gaU5LyRnlBaZuLtcTwA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 30.01.2022 00:25, Stefan Esser wrote: > After rebooting with freshly built world, kernel and the amdgpu driver > my console stopped working. It goes blank and the display goes into a > power save mode, as soon as the amdgpu driver is loaded. > > The GPU (a Radeon R7 250E) is correctly detected as before, but there > is an error message "drmn0: [drm] Cannot find any crtc or sizes". > > I'm asking here and not on the ports list, since the AMDGPU driver has > not been updated for half a year. But to be sure that there is no mismatch > between kernel and user land, I have rebuilt all X11 server and library > ports. > > There have been changes affecting the i2c driver, IIRC, and the error > message seems to point at an issue obtaining information from the LCD > display. > > The output of "grep drm /var/run/dmesg.boot" follows: > > [drm] amdgpu kernel modesetting enabled. > drmn0: on vgapci0 > vgapci0: child drmn0 requested pci_enable_io > vgapci0: child drmn0 requested pci_enable_io > [drm] initializing kernel modesetting (VERDE 0x1002:0x683F 0x174B:0xA001 0x00). > [drm] register mmio base: 0xFCE00000 > [drm] register mmio size: 262144 > [drm] add ip block number 0 > [drm] add ip block number 1 > [drm] add ip block number 2 > [drm] add ip block number 3 > [drm] add ip block number 4 > [drm] add ip block number 5 > [drm] add ip block number 6 > [drm] BIOS signature incorrect 0 0 > [drm] vm size is 512 GB, 2 levels, block size is 10-bit, fragment size is 9-bit > drmn0: successfully loaded firmware image 'amdgpu/verde_mc.bin' > drmn0: VRAM: 1024M 0x000000F400000000 - 0x000000F43FFFFFFF (1024M used) > drmn0: GART: 1024M 0x000000FF00000000 - 0x000000FF3FFFFFFF > [drm] Detected VRAM RAM=1024M, BAR=256M > [drm] RAM width 128bits GDDR5 > [drm] amdgpu: 1024M of VRAM memory ready > [drm] amdgpu: 3072M of GTT memory ready. > [drm] GART: num cpu pages 262144, num gpu pages 262144 > drmn0: PCIE GART of 1024M enabled (table at 0x000000F400500000). > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > drmn0: successfully loaded firmware image 'amdgpu/verde_pfp.bin' > drmn0: successfully loaded firmware image 'amdgpu/verde_me.bin' > drmn0: successfully loaded firmware image 'amdgpu/verde_ce.bin' > drmn0: successfully loaded firmware image 'amdgpu/verde_rlc.bin' > drmn0: successfully loaded firmware image 'amdgpu/verde_smc.bin' > [drm] Internal thermal controller without fan control > [drm] amdgpu: dpm initialized > [drm] Connector DP-1: get mode from tunables: > [drm] - kern.vt.fb.modes.DP-1 > [drm] - kern.vt.fb.default_mode > [drm] Connector HDMI-A-1: get mode from tunables: > [drm] - kern.vt.fb.modes.HDMI-A-1 > [drm] - kern.vt.fb.default_mode > [drm] Connector DVI-I-1: get mode from tunables: > [drm] - kern.vt.fb.modes.DVI-I-1 > [drm] - kern.vt.fb.default_mode > [drm] AMDGPU Display Connectors > [drm] Connector 0: > [drm] DP-1 > [drm] HPD4 > [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 > [drm] Encoders: > [drm] DFP1: INTERNAL_UNIPHY2 > [drm] Connector 1: > [drm] HDMI-A-1 > [drm] HPD1 > [drm] DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f > [drm] Encoders: > [drm] DFP2: INTERNAL_UNIPHY2 > [drm] Connector 2: > [drm] DVI-I-1 > [drm] HPD2 > [drm] DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b > [drm] Encoders: > [drm] DFP3: INTERNAL_UNIPHY > [drm] CRT1: INTERNAL_KLDSCP_DAC1 > drmn0: [drm] Cannot find any crtc or sizes > drmn0: [drm] Cannot find any crtc or sizes > drmn0: [drm] Cannot find any crtc or sizes > [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 > > A successful driver attach from a reboot a few days ago had ended in: > > [drm] CRT1: INTERNAL_KLDSCP_DAC1 > [drm] fb mappable at 0xE0503000 > [drm] vram apper at 0xE0000000 > [drm] size 33177600 > [drm] fb depth is 24 > [drm] pitch is 15360 > [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 > > Regards, STefan drm-kmod commit 534aa199c10d forced it to use i2c from base. You may try to checkout previous revision (444dc58f0247) to find out if in-base i2c is guilty or not. -- WBR Vladimir Kondratyev From nobody Sun Jan 30 19:43:09 2022 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 A3CF4198B718 for ; Sun, 30 Jan 2022 19:43:13 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jn1ns47jLz3Lwr; Sun, 30 Jan 2022 19:43:13 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643571793; 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=1UBaJt18j6jmFuBZuxCPaj9KJZKeBmHvM8VtGJsX/DE=; b=nzWDtUFLjivcmJO9bxLiWgrCG4ojdZpOzVqAaHQT4Q0B0jvJvugKv5HxsHSiGwk6jjgpKt +s8gkz3UikF9ZfKBGLihJB1TixUO6jQI8lu3DNDX+kJc3Nt21Lyvm/0FCNxDyxi6rMCRCa mrJsIuoJyVmnffTHwEgTJk5lvS7352Y/S6gSFArHQZDiYKcDkUgmACi5RostCEetFoAztY oeyb0RMEhPyZaZ7ZoAqY6WjkBTrMOllHZHXScsITSBt+vbLTtnT0fFDoh4thc1+vJ5QBxd FfAirAduq9qP6K36f9GE+nOIvAl+mkFwVDXK5vpOCZJuJeumxk5gGgU3PZQsng== Received: from [IPV6:2003:cd:5f0c:9800:818c:49c5:f27e:e140] (p200300cd5f0c9800818c49c5f27ee140.dip0.t-ipconnect.de [IPv6:2003:cd:5f0c:9800:818c:49c5:f27e:e140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 0853990EB; Sun, 30 Jan 2022 19:43:12 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: Date: Sun, 30 Jan 2022 20:43:09 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related? Content-Language: en-US To: Vladimir Kondratyev References: <4611d16a-ef17-d8f3-c2c0-1b1091723646@FreeBSD.org> From: Stefan Esser Cc: freebsd-current@freebsd.org In-Reply-To: <4611d16a-ef17-d8f3-c2c0-1b1091723646@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------LSTiDFrbrdXqddmjn0y2I3nT" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643571793; 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=1UBaJt18j6jmFuBZuxCPaj9KJZKeBmHvM8VtGJsX/DE=; b=ogXNMZp291Ua0eT6deR/8M+WPH5+xdQWFbY8N0VkpeGzr0itkt2ziuBU2ovP6CXDNXM4Do 1ngk67xTxK2RyKedb+Acl2tDulwh+dcufxPaqjLaTtkLiLE7dguOo5kk4qWbcWolXaQk3U nWhe6kHu+jGCvwEZmnYGLZiYsyQQzZlPolZ35L/8S6herkh28QjSp4LtChmM2bNAchvYOx d6l0AhPNPXwPnRp/k9MsMpVG1aViiMRxdDXBrPfM2152ghYwuvi6waIGsj5Ocz1vH0tbM+ zUEOW+GXFdU3Kqc91yYszQlQC5k4k0K+088h7T/UMGS9IVr6AHKqgCnAOoWYjw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643571793; a=rsa-sha256; cv=none; b=DFKQ6nUnpBVoA3ldhB1AQDKVxCy4DnufsqueZFbkUGB3Jqx9NUbGkRvxkH1MrdctV1j2ld nTh1/WUi386JW0oLD/BNiU5anr2/GiCDmZgBIjkpNurcthmxbnapr//tZ0K89YShQn9/DQ FQgZm3vYUR+CawXrpozoZO8bpvAdh6RJjj2TEXwrYmIsKqqJciqGlUDnC5EY+V+hkAZ0Em CIwjllHAPhygGUOiiVgjJyLCiyAP2ei+e8sydwZRM9BgkRXhhvO1/ncslWKtHi57G89DOR jF5VO44rp755BNhmvEGZzHYbJTWDC0l8HKAy857+/O8xce1AdQ6HwWPMAPP17A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------LSTiDFrbrdXqddmjn0y2I3nT Content-Type: multipart/mixed; boundary="------------6yDW8Sj3j0b6bNZBv5ak18Jq"; protected-headers="v1" From: Stefan Esser To: Vladimir Kondratyev Cc: freebsd-current@freebsd.org Message-ID: Subject: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related? References: <4611d16a-ef17-d8f3-c2c0-1b1091723646@FreeBSD.org> In-Reply-To: <4611d16a-ef17-d8f3-c2c0-1b1091723646@FreeBSD.org> --------------6yDW8Sj3j0b6bNZBv5ak18Jq Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 30.01.22 um 19:23 schrieb Vladimir Kondratyev: > On 30.01.2022 00:25, Stefan Esser wrote: >> After rebooting with freshly built world, kernel and the amdgpu driver= >> my console stopped working. It goes blank and the display goes into a >> power save mode, as soon as the amdgpu driver is loaded. >> >> The GPU (a Radeon R7 250E) is correctly detected as before, but there >> is an error message "drmn0: [drm] Cannot find any crtc or sizes". >> [...] >> [drm] AMDGPU Display Connectors >> [drm] Connector 0: >> [drm]=C2=A0=C2=A0 DP-1 >> [drm]=C2=A0=C2=A0 HPD4 >> [drm]=C2=A0=C2=A0 DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x195= 3 0x1953 >> [drm]=C2=A0=C2=A0 Encoders: >> [drm]=C2=A0=C2=A0=C2=A0=C2=A0 DFP1: INTERNAL_UNIPHY2 >> [drm] Connector 1: >> [drm]=C2=A0=C2=A0 HDMI-A-1 >> [drm]=C2=A0=C2=A0 HPD1 >> [drm]=C2=A0=C2=A0 DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195= f 0x195f >> [drm]=C2=A0=C2=A0 Encoders: >> [drm]=C2=A0=C2=A0=C2=A0=C2=A0 DFP2: INTERNAL_UNIPHY2 >> [drm] Connector 2: >> [drm]=C2=A0=C2=A0 DVI-I-1 >> [drm]=C2=A0=C2=A0 HPD2 >> [drm]=C2=A0=C2=A0 DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195= b 0x195b >> [drm]=C2=A0=C2=A0 Encoders: >> [drm]=C2=A0=C2=A0=C2=A0=C2=A0 DFP3: INTERNAL_UNIPHY >> [drm]=C2=A0=C2=A0=C2=A0=C2=A0 CRT1: INTERNAL_KLDSCP_DAC1 >> drmn0: [drm] Cannot find any crtc or sizes >> drmn0: [drm] Cannot find any crtc or sizes >> drmn0: [drm] Cannot find any crtc or sizes >> [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 >> >> A successful driver attach from a reboot a few days ago had ended in: >> >> [drm]=C2=A0=C2=A0=C2=A0=C2=A0 CRT1: INTERNAL_KLDSCP_DAC1 >> [drm] fb mappable at 0xE0503000 >> [drm] vram apper at 0xE0000000 >> [drm] size 33177600 >> [drm] fb depth is 24 >> [drm]=C2=A0=C2=A0=C2=A0 pitch is 15360 >> [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 >> >> Regards, STefan >=20 > drm-kmod commit 534aa199c10d forced it to use i2c from base. Hi Vladimir, thank you for the information! I'm using drm-devel-kmod, and in fact foun= d that 5.5.19.g20211230 works, while 5.7.19.g20220126 (committed as 0c38674= b389ad on 2022-01-26) causes the failure. > You may try to checkout previous revision (444dc58f0247) to find out if= in-base > i2c is guilty or not. Assuming that the same change to use the system i2c code has been in the = latest commit to the drm-devel-kmod port, this should be proven, now. ;-) These is the list of in-kernel i2c modules on my system (a Ryzen 9 5950 o= n an ASUS mainboard with B550 chip-set): $ kldstat -v | grep iic 68 iicsmb/smbus 67 iicbus/iicsmb 66 iichb/iicbus 65 iicbb/iicbus 64 iicbus/iic 63 iicbus/ic 213 lkpi_iicbb/iicbb 212 lkpi_iic/lkpi_iicbb 211 lkpi_iic/iicbus 210 drmn/lkpi_iic 56 iichid/hidbus Can I help debug this issue? I could re-install the latest version and boot with hw.dri.drm_debug or dev.drm.drm_debug set? Or are there other settings to get a debug log from the i2c side? Regards, STefan PS: I'm keeping the CC to current@, since this might be an issue in the i= 2c kernel code ... --------------6yDW8Sj3j0b6bNZBv5ak18Jq-- --------------LSTiDFrbrdXqddmjn0y2I3nT Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmH26k0FAwAAAAAACgkQR+u171r99UTi zwf9GnGgrn6d99ZiqXsmMJ/O4q50ahJEh4ZnymcSkrDOQpUk4zIsl1MYazAuBOnJAVd/xTTlmGeu ZVZUnC87ZfnhKEVgo5hpvxwTYOryAZjcdTmCNvPwyhUMuTEzSRYe8nHB0JYDYM1zkp39kJQbcURS 5s0V1J1pTfs4DjHrMkHKHgRVcQxQckPFEmXvhSlIEPTAEvENRkA9Krsy9rG4MghB/+o1CqYkNiAu 3HWjA4v3LwJMASqUMBrGWNMfE00e7WeD5Mliw5oVOaXyQvC12Nx4GQ2JxQleTmfrZyNqirspwS7F NDPwKUBxyGLGVjsT/WDA13RyCGPhqzF5pZtz85S5/Q== =9cNY -----END PGP SIGNATURE----- --------------LSTiDFrbrdXqddmjn0y2I3nT-- From nobody Sun Jan 30 22:25:54 2022 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 D44E7198A911; Sun, 30 Jan 2022 22:25:56 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jn5Pc5Hfnz3qrW; Sun, 30 Jan 2022 22:25:56 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643581556; 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=n2+F2CXeXD0m3NnP4PTuxjPW4YeZk2blas5/CjMj0RU=; b=NRNF2jAztvHHXp/AuSs1lpTwJQE3fibz8YMKhAnc3XgpSNopwGHw6AaWq3jOP0BOLHJIli 5JFpj/VgyoZtQ/qQe6RuAxsGParxGY19jmJqhgmOPqwIIlY6wv6GVKy6RpSo2f7u44uyUb pS5ZEQh6TitwCPRIDd9Bot6xDw37+dsFTJKUyzuFLEwLrEihmBCcNl5qGNTvgnAAYZBQxP wn7QIE1mCNkrk7vqSO91BtPnAvH9fuLe2QTXTJ6ObkJF110GiRtS4VkikExF8du4JKehxt 4RdKQAPHCI27ASG2+orxppTjMDi7cwqvWZTZNsfCXOXR5ezwVB3QA0R/6kniWA== Received: from next.des.no (unknown [84.210.195.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 72D59A6E2; Sun, 30 Jan 2022 22:25:56 +0000 (UTC) (envelope-from des@freebsd.org) Received: by next.des.no (Postfix, from userid 1001) id 41A118C85; Sun, 30 Jan 2022 23:25:54 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ed Maste Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Dragonfly Mail Agent (dma) in the base system In-Reply-To: (Ed Maste's message of "Thu, 27 Jan 2022 16:34:10 -0500") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (berkeley-unix) Date: Sun, 30 Jan 2022 23:25:54 +0100 Message-ID: <86czk8rhcd.fsf@next.des.no> 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643581556; 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=n2+F2CXeXD0m3NnP4PTuxjPW4YeZk2blas5/CjMj0RU=; b=oJBGEl96SMbU7UtT10CV7ilPExA3EV8bSCFqtIf906+WG31O+2JQ5en9mR1vNQcst143Iu inzdXe+0qIOtYVQuHIfiIm8hoxZC0EK2pCGVhfXV78MSh7Yw91hQNQG4+Ng4geQU8rAkAa NxS3p1T8EM84Uwlmy9iW1w/hiJnRoauhzXp6EhHdNZV1kc0FZvoy2zgNEkIrseZDadasLb yFHH96jeLyOTS0pnbPLMicbdpIGgpFnF2E5NKVCPMM0VkUiEcW1/S/NGPkoD/d8p5ijPT3 4HnsaAb60CWStuyAMwvd24/ovL2vKXlf67dbYv+i7s0LEK3qSdC75TsbP7KoOQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643581556; a=rsa-sha256; cv=none; b=NDet+3lhZ8n93gA/M+9a4efoJjxOXLFdK6WbcndYVPSZeFDpxFY9puSnttflQL/2WkrcLZ Di7mJiVMnT0abfLBXxqBtmCjWHeFyDqMtyDHy0PvZ1KGnAt7cV7lYq26r3l4HZbwbFEpJw Z0XbH4I2ZMgcq25KtKszI7+naqLZeO0VpNj5ehFKaz0UN6AuyIEqscyjnu63nLsEFvqy98 mjXauxiWbfB7cFGYmUAOJXGBz5qW0RCmryiQPsVqIAs86SJNwqdbipl06cLtqPmaMteasN xnsLkbQOuij5DpZewX8hhpfJuTzINn1bMBA6hoxge5Sl/xR91gAGXeY8VbFq3w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Ed Maste writes: > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. It cannot. Ask bapt@ who was the one to import it, and later abandon the idea of making it our default MTA. The reason was that it does not have a default domain setting, so it cannot handle email from cron, periodic etc. where the recipient is just a user name (usually =E2=80=9Croo= t=E2=80=9D), and the devs were not willing to add that feature. I have email as far back as 2015 on the subject. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Mon Jan 31 11:19:53 2022 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 B2FD7199FC4E for ; Mon, 31 Jan 2022 11:19:58 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JnQZk4gqjz3FMj for ; Mon, 31 Jan 2022 11:19:58 +0000 (UTC) (envelope-from wulf@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643627998; 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=9EXivVMFKzDNJ6pGbO0gprEFxfndIstYEb+kV8LgF1A=; b=ZINleT9wIGClxmp79UfPdT4TnBKlrFPY0v0w7gjoius55wMaOywDGHoX6fIYCUXIQEbfkR ba//OUixM+f2neOJNtxBTUN9xIlCP38duhJIaASF3kZlP0UmB7EtcqWDdY/4OaIOpIL0GD VE9IKKkOLEsXbGDZyq9l1xqqf5N5Fpr0eFC+3V968UjpWQRmOZDIxicQHxyCDzSHEZaOXS yIFCkeKErqRiZTjB1/+wWk59MymgPllks704iZrNjNH/S6n/uMMYURZi47lMxPm/JW0zw3 GU6gNqB7bUPQVx36h9z7/9wceCCm1o/+5QhVUQl6Jtur6UHP1xI54EEAQk2YtQ== Received: from [192.168.0.30] (unknown [176.120.228.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: wulf) by smtp.freebsd.org (Postfix) with ESMTPSA id 4053020A62 for ; Mon, 31 Jan 2022 11:19:58 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Message-ID: <41f0a849-f2c9-75fe-e0ed-e60356ac4728@FreeBSD.org> Date: Mon, 31 Jan 2022 14:19:53 +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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related? Content-Language: en-US To: freebsd-current@freebsd.org References: <4611d16a-ef17-d8f3-c2c0-1b1091723646@FreeBSD.org> From: Vladimir Kondratyev In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643627998; 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=9EXivVMFKzDNJ6pGbO0gprEFxfndIstYEb+kV8LgF1A=; b=lv3SRXFp5QoNeqbzR/VUjB/AhCDgXrKmfZHqg1pupAAr0a/xbTFA/IhLcAUFFqlC+bvB5V EFawfKfMcHR2qwcGNWId3rwMbGypY8CjPSdVNvtuKw/19YWltg4eZKoZ9nKKnXMFqEd3hB BxLQnLDTKE5f9+fM++txRjEU3ne6WMnBOHAeJKEUZrleUoJmKPxxOSFwlhyg8+y+8YH1Mr QEhpgBdx87/gSkuIeEs5xhYD6WUJqBY82iYsKLhQ/j4Xm3k724gLlNkDbDtEVAD0Y7+yHg 4IdTWVY8hBfyuoDlUl5scOwFfTit46zMEc/D0KGeIiI4hQJAi1Sj8aTggO9nzQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643627998; a=rsa-sha256; cv=none; b=OXgd5T/T9Y0Aai0IPSFMo//Laguw/i1HdbAff6LwEbT9W+7YGbzfehzOvgEmAdWgMdfgyM Zy5CluCdXyByRn71Ee9uQLmngLXc/Wp6iFHl40LQRp6IJPDdQmjMLsuuZsC2rJjCGi+S+4 wU0B+xKiP/89v3/dvhFzg+/i6K/QhN03vYivkxIrQr4wv7A/v4OiumbZ62Zjd88O7z/LtT +q5kBZjyaWbQKvZWbVipAc/qwxSNwdvConswr0tvuCDhZF/mU7tBei3ltT8ygn+Lq2BuP4 x4ks2c4vkqbv9uiGjIwBYPZLZGQOZub7mtg7OTrCA0gVM3weUxX3gV7h7hwhYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 30.01.2022 22:43, Stefan Esser wrote: > Am 30.01.22 um 19:23 schrieb Vladimir Kondratyev: >> On 30.01.2022 00:25, Stefan Esser wrote: >>> After rebooting with freshly built world, kernel and the amdgpu driver >>> my console stopped working. It goes blank and the display goes into a >>> power save mode, as soon as the amdgpu driver is loaded. >>> >>> The GPU (a Radeon R7 250E) is correctly detected as before, but there >>> is an error message "drmn0: [drm] Cannot find any crtc or sizes". >>> > [...] >>> [drm] AMDGPU Display Connectors >>> [drm] Connector 0: >>> [drm]   DP-1 >>> [drm]   HPD4 >>> [drm]   DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 >>> [drm]   Encoders: >>> [drm]     DFP1: INTERNAL_UNIPHY2 >>> [drm] Connector 1: >>> [drm]   HDMI-A-1 >>> [drm]   HPD1 >>> [drm]   DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f >>> [drm]   Encoders: >>> [drm]     DFP2: INTERNAL_UNIPHY2 >>> [drm] Connector 2: >>> [drm]   DVI-I-1 >>> [drm]   HPD2 >>> [drm]   DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b >>> [drm]   Encoders: >>> [drm]     DFP3: INTERNAL_UNIPHY >>> [drm]     CRT1: INTERNAL_KLDSCP_DAC1 >>> drmn0: [drm] Cannot find any crtc or sizes >>> drmn0: [drm] Cannot find any crtc or sizes >>> drmn0: [drm] Cannot find any crtc or sizes >>> [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 >>> >>> A successful driver attach from a reboot a few days ago had ended in: >>> >>> [drm]     CRT1: INTERNAL_KLDSCP_DAC1 >>> [drm] fb mappable at 0xE0503000 >>> [drm] vram apper at 0xE0000000 >>> [drm] size 33177600 >>> [drm] fb depth is 24 >>> [drm]    pitch is 15360 >>> [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 >>> >>> Regards, STefan >> >> drm-kmod commit 534aa199c10d forced it to use i2c from base. > > Hi Vladimir, > > thank you for the information! I'm using drm-devel-kmod, and in fact found > that 5.5.19.g20211230 works, while 5.7.19.g20220126 (committed as 0c38674b389ad > on 2022-01-26) causes the failure. > >> You may try to checkout previous revision (444dc58f0247) to find out if in-base >> i2c is guilty or not. > > Assuming that the same change to use the system i2c code has been in the latest > commit to the drm-devel-kmod port, this should be proven, now. ;-) > > These is the list of in-kernel i2c modules on my system (a Ryzen 9 5950 on an > ASUS mainboard with B550 chip-set): > > $ kldstat -v | grep iic > 68 iicsmb/smbus > 67 iicbus/iicsmb > 66 iichb/iicbus > 65 iicbb/iicbus > 64 iicbus/iic > 63 iicbus/ic > 213 lkpi_iicbb/iicbb > 212 lkpi_iic/lkpi_iicbb > 211 lkpi_iic/iicbus > 210 drmn/lkpi_iic > 56 iichid/hidbus > > Can I help debug this issue? > > I could re-install the latest version and boot with hw.dri.drm_debug or > dev.drm.drm_debug set? > > Or are there other settings to get a debug log from the i2c side? > > Regards, STefan > > PS: I'm keeping the CC to current@, since this might be an issue in the i2c > kernel code ... There are no successful lkpi_iic attachments in your output. They look like: lkpi_iic0: on drmn0 Please share your `devinfo -v` output. Kldload output with verbose boot enabled can be helpful too. -- WBR Vladimir Kondratyev From nobody Mon Jan 31 12:05:12 2022 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 F204C1997459 for ; Mon, 31 Jan 2022 12:05:21 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JnRb46SBHz3qWD; Mon, 31 Jan 2022 12:05:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1643630712; 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=cmgpIRKhzruTPnYYW4mRPUNmf4+FnjHCjdtRsUqmC8c=; b=gvw/YKm5RXnye0xGwPU5b8jHt5Pl5wy8a/dbtn/F9n286Rc8swb3p/nuhiI5rJ7tKqTt9t O7oo4WKZxSdRIPk0j/o6SNl+amSHnRpXj328TAdq27TQHdw1vsWICHnlmr8Cwv8bEcrGCq T0jbTeGFj1N/Yj/+jW7SC46TB5fqD8I= Received: from amy (lfbn-idf2-1-1209-14.w90-92.abo.wanadoo.fr [90.92.34.14]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 60024440 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 31 Jan 2022 12:05:12 +0000 (UTC) Date: Mon, 31 Jan 2022 13:05:12 +0100 From: Emmanuel Vadot To: Vladimir Kondratyev Cc: freebsd-current@freebsd.org Subject: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related? Message-Id: <20220131130512.ebc9efe4877db832e657af01@bidouilliste.com> In-Reply-To: <41f0a849-f2c9-75fe-e0ed-e60356ac4728@FreeBSD.org> References: <4611d16a-ef17-d8f3-c2c0-1b1091723646@FreeBSD.org> <41f0a849-f2c9-75fe-e0ed-e60356ac4728@FreeBSD.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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-Rspamd-Queue-Id: 4JnRb46SBHz3qWD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b="gvw/YKm5"; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-1.58 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.09)[-0.089]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 31 Jan 2022 14:19:53 +0300 Vladimir Kondratyev wrote: > On 30.01.2022 22:43, Stefan Esser wrote: > > Am 30.01.22 um 19:23 schrieb Vladimir Kondratyev: > >> On 30.01.2022 00:25, Stefan Esser wrote: > >>> After rebooting with freshly built world, kernel and the amdgpu driver > >>> my console stopped working. It goes blank and the display goes into a > >>> power save mode, as soon as the amdgpu driver is loaded. > >>> > >>> The GPU (a Radeon R7 250E) is correctly detected as before, but there > >>> is an error message "drmn0: [drm] Cannot find any crtc or sizes". > >>> > > [...] > >>> [drm] AMDGPU Display Connectors > >>> [drm] Connector 0: > >>> [drm]=A0=A0 DP-1 > >>> [drm]=A0=A0 HPD4 > >>> [drm]=A0=A0 DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1= 953 > >>> [drm]=A0=A0 Encoders: > >>> [drm]=A0=A0=A0=A0 DFP1: INTERNAL_UNIPHY2 > >>> [drm] Connector 1: > >>> [drm]=A0=A0 HDMI-A-1 > >>> [drm]=A0=A0 HPD1 > >>> [drm]=A0=A0 DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x1= 95f > >>> [drm]=A0=A0 Encoders: > >>> [drm]=A0=A0=A0=A0 DFP2: INTERNAL_UNIPHY2 > >>> [drm] Connector 2: > >>> [drm]=A0=A0 DVI-I-1 > >>> [drm]=A0=A0 HPD2 > >>> [drm]=A0=A0 DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x1= 95b > >>> [drm]=A0=A0 Encoders: > >>> [drm]=A0=A0=A0=A0 DFP3: INTERNAL_UNIPHY > >>> [drm]=A0=A0=A0=A0 CRT1: INTERNAL_KLDSCP_DAC1 > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 > >>> > >>> A successful driver attach from a reboot a few days ago had ended in: > >>> > >>> [drm]=A0=A0=A0=A0 CRT1: INTERNAL_KLDSCP_DAC1 > >>> [drm] fb mappable at 0xE0503000 > >>> [drm] vram apper at 0xE0000000 > >>> [drm] size 33177600 > >>> [drm] fb depth is 24 > >>> [drm]=A0=A0=A0 pitch is 15360 > >>> [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 > >>> > >>> Regards, STefan > >> > >> drm-kmod commit 534aa199c10d forced it to use i2c from base. > >=20 > > Hi Vladimir, > >=20 > > thank you for the information! I'm using drm-devel-kmod, and in fact fo= und > > that 5.5.19.g20211230 works, while 5.7.19.g20220126 (committed as 0c386= 74b389ad > > on 2022-01-26) causes the failure. > >=20 > >> You may try to checkout previous revision (444dc58f0247) to find out i= f in-base > >> i2c is guilty or not. > >=20 > > Assuming that the same change to use the system i2c code has been in th= e latest > > commit to the drm-devel-kmod port, this should be proven, now. ;-) > >=20 > > These is the list of in-kernel i2c modules on my system (a Ryzen 9 5950= on an > > ASUS mainboard with B550 chip-set): > >=20 > > $ kldstat -v | grep iic > > 68 iicsmb/smbus > > 67 iicbus/iicsmb > > 66 iichb/iicbus > > 65 iicbb/iicbus > > 64 iicbus/iic > > 63 iicbus/ic > > 213 lkpi_iicbb/iicbb > > 212 lkpi_iic/lkpi_iicbb > > 211 lkpi_iic/iicbus > > 210 drmn/lkpi_iic > > 56 iichid/hidbus > >=20 > > Can I help debug this issue? > >=20 > > I could re-install the latest version and boot with hw.dri.drm_debug or > > dev.drm.drm_debug set? > >=20 > > Or are there other settings to get a debug log from the i2c side? > >=20 > > Regards, STefan > >=20 > > PS: I'm keeping the CC to current@, since this might be an issue in the= i2c > > kernel code ... >=20 > There are no successful lkpi_iic attachments in your output. They look li= ke: >=20 > lkpi_iic0: on drmn0 >=20 > Please share your `devinfo -v` output. > Kldload output with verbose boot enabled can be helpful too. That's because this card is probably using the bitbang part. As stated in the commit this wasn't tested as I don't have compatible hardware. It's likely a timing issue in the bitbang part. That's the main reason it's only in master and 5.7 branch of drm-kmod, so people can debug/fix. --=20 Emmanuel Vadot From nobody Mon Jan 31 12:45:31 2022 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 A32B91988FBA; Mon, 31 Jan 2022 12:45:35 +0000 (UTC) (envelope-from bapt@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JnSTW4Gwzz4bYF; Mon, 31 Jan 2022 12:45:35 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643633135; 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=6XvGQgnutzI5n7mkHS4a+5Sr3hcUL/XX/dMe8JpB4ck=; b=Fb0d+90u03uxHaeFWzL/ubkXv4I4gRUU6DAAM3dkNTTwl7f1yZ1AdeLUHfX7TV+jw++WF8 h71HDVchNvVhyzFjZiBZOMR+z+JkrLwJ2gqyTwoHI/1rB+c7MC4ABkU3KVaeV90e5JeV/g xLqeB6uIwT5rUXmtq96Hqt2hMlGR/XQYDDGRqe/0qeITTzG+5mGBM9X8tBezOqekv+TYHt +emgNy5GW1/jGkVetLNJYDhNBdMJyK7356rlJ73cufGMCWdQPRyBix0p6VFgLIkC+abVDi OR8NWAIojaW5+a9y8D2PcKP89arILUEeWIw2uZlV1bwDoHnU0+QBCW98mf5/hA== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 5AB61203FB; Mon, 31 Jan 2022 12:45:35 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 0455EAAD72; Mon, 31 Jan 2022 13:45:32 +0100 (CET) Date: Mon, 31 Jan 2022 13:45:31 +0100 From: Baptiste Daroussin To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= Cc: Ed Maste , FreeBSD Hackers , FreeBSD Current Subject: Re: Dragonfly Mail Agent (dma) in the base system Message-ID: <20220131124531.aoc7lowc3f7vyjaf@aniel.nours.eu> References: <86czk8rhcd.fsf@next.des.no> 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: <86czk8rhcd.fsf@next.des.no> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643633135; 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=6XvGQgnutzI5n7mkHS4a+5Sr3hcUL/XX/dMe8JpB4ck=; b=abqSZPBtBVVbcsOpL8AWYSJdLv5WJDkIhrMzs5wdkzQARJfpr0PZZg95wL5mdOQTE+059/ z2Nrt6bfoA6U+y0BFpfME6ICvUGS4a4+5iWLHt7tHHvW9WSxW0cOpRz8cHcgYed3vGrSis P9dMrV6hucBokkH0Gx5SoeZdrrnH9apk5BcqY/4Di3fNb+cXzsYVlF5wr+cBqV6guIKNgT IhA86dZx4ZAVdZksrctZ/G/b4jCw+PVtGmcN5b9CLlKTp6t/2sv4x/4Oax8MVOI+SM6aHA SN99VT9tYdF/VeQPLXU0nFlk7G3gxpaUtQhNUCAxGW9d4MEOCCntWHSFagcAIw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643633135; a=rsa-sha256; cv=none; b=bVbsNxsvf+HCoFptqV4m0j3eXsVnWVSkviR9p83YWYNyU4NBqjbAzj3/Ox8yKR03d3iGhG KzGZ1ZzsAfzgB6NRZrSEojmj+xNpZixUAJjuTy9bh3X1Z8/X5OFuz+guVbygQ0h405E/VP uFW7dyEnSVADBxibBVS6RBWbBJZvHzPZEz9O1SioDDMkk3vCDReoraAviLLrC8MAZgQVtv cSbhS73KehnuuP2jMr2OTq1JvvP0jF/thsXOj16CJKdKHDbBIS9mcjnFit75PR5eH57q1I 2dXTFBJegczpPZiRzdlwfx+Fxw08fKuX7IV0O6faZBAS0pGVpmFiyb778w/haQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sun, Jan 30, 2022 at 11:25:54PM +0100, Dag-Erling Smørgrav wrote: > Ed Maste writes: > > I am interested in determining whether dma is a viable minimal base > > system MTA, and if not what gaps remain. > > It cannot. Ask bapt@ who was the one to import it, and later abandon > the idea of making it our default MTA. The reason was that it does not > have a default domain setting, so it cannot handle email from cron, > periodic etc. where the recipient is just a user name (usually “rootâ€), > and the devs were not willing to add that feature. I have email as far > back as 2015 on the subject. > This has been fixed since. (not by me) Bapt From nobody Mon Jan 31 13:47:52 2022 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 5FE0319924B4; Mon, 31 Jan 2022 13:47:56 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JnTsS2BFXz3H4Z; Mon, 31 Jan 2022 13:47:56 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643636876; 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=nvySX/DlXtwmCVlrUQ8U74hEemKNMp5vfv1PxLlK0Lo=; b=ardzTiHevKLFxX+smAHyNccm+ai4SQDI+RelTFj/MZ2Mu/r9X/TmzZy2KH6CskL7fsVE1E ecCOURU/IzVxeQA9fuUn0j5vND/s30B75hyXx+ZpayqadTqCawbPfJrQMQtUDEQPi2Y9oH Yc5nTYJ9XU3xjoxPBnWI6XMBEA30Y4k8urQGbgqNGjcFrpsyB8UXZ3+gVqNaePyNmTcFfZ eb1Pu2vDMQgy4bvHuidAZEbYLqYPsimEQ2+n65oSbsD91WXk0OwJphY47fj+GW8wvAheu/ 1g9j9zU6166tNG8DUoMnucaZZ6PXpMXILrypXzzcjrQKus2zsyp2dX6vL0xF/Q== Received: from next.des.no (unknown [84.210.195.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id D557B213F8; Mon, 31 Jan 2022 13:47:55 +0000 (UTC) (envelope-from des@freebsd.org) Received: by next.des.no (Postfix, from userid 1001) id 40E0089CA; Mon, 31 Jan 2022 14:47:52 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Baptiste Daroussin Cc: Ed Maste , FreeBSD Hackers , FreeBSD Current Subject: Re: Dragonfly Mail Agent (dma) in the base system In-Reply-To: <20220131124531.aoc7lowc3f7vyjaf@aniel.nours.eu> (Baptiste Daroussin's message of "Mon, 31 Jan 2022 13:45:31 +0100") References: <86czk8rhcd.fsf@next.des.no> <20220131124531.aoc7lowc3f7vyjaf@aniel.nours.eu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (berkeley-unix) Date: Mon, 31 Jan 2022 14:47:52 +0100 Message-ID: <865yq02f07.fsf@next.des.no> 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643636876; 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=nvySX/DlXtwmCVlrUQ8U74hEemKNMp5vfv1PxLlK0Lo=; b=skC5QNL8QQcVj+MOOd9WqrQVojz6Ym10ua2aM67XvhZHhOzuUDbx8twIpMYfe4WSImVVRD FsvCriila5IDIbDqsa2jfgtV2SKaMFt3rUYh850YsbKPjfy2cIZC1QXYQJC3m0QQFaZBMb Qgzev0+30tIItzPaOx1hL7qFCrbuzTk1S5uggJniGbG5cwaAw7o6xRPlmbdYVKnpAeCu/K LAqrppbQ6WpEKjqiyLI2hRLeAzCrxqy/M/BmxVYTX79kKl/GLgHSDI6TRRCaIrE+4J9guv gC6qThlqZ/c9m58HhF0v4itTiyafhlfb8H1n8fXwxJKg2pc6ED9G/mcnqX8qSQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643636876; a=rsa-sha256; cv=none; b=XhECk9w0bH3dFbuUO/oHYnwLNSGqXNavUQXN/C2MTFldcKfW87x0nvbYSSLKZEfnVJ8qVA HkKs+2I4659TJ9gPN63N455vByU33JM13P5PGqmN6wIEL9ds6O1cSV+Mx0QPIk+oTczqpw BLGN7Ke3M+tGa35WNOGWltuoshhn8sc5rq5LwXDRpdAkI8M8Gyd0638IEZ6LHGEhtJ5/qU BA4BDXnZp632kEmdmyPPUgiLNizyBecGj65vt/cLmCmmBhOfIocAqchPtJoYO4zR1qs61T LzTwfdR+pAPKdqYUfUCXX411gatfGMRUMo+hdMEu56xwe0Yggij12DesKEGYmA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Baptiste Daroussin writes: > Dag-Erling Sm=C3=B8rgrav writes: > > [...] does not have a default domain setting, so it cannot handle > > email from cron, periodic etc. where the recipient is just a user > > name (usually =E2=80=9Croot=E2=80=9D) [...] > This has been fixed since. (not by me) In that case, assuming that it behaves sensibly out of the box, my only objection is the lack of documentation, which I understand is being worked on. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Mon Jan 31 16:02:30 2022 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 107BD199B97F for ; Mon, 31 Jan 2022 16:02:53 +0000 (UTC) (envelope-from tijl@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JnXs870zLz4rx0; Mon, 31 Jan 2022 16:02:52 +0000 (UTC) (envelope-from tijl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643644973; 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=IW0TO2rwaYC6eRcgmDVEN+7Vw3XfIBowOgkdUz87bJ0=; b=eTLPtliuFQY03hxCo84opHxCiOS78xHLG3VbhnkZwzdoHDpPIRIUkNOIGePK/9cmX3Nkuw n8Is4wObh+ciQfXfnbikeXIyKXEDjdeOXVtvtYG++B2m+Kk6RDDEgS7bPSULpt48B6mJSd DJv7sIIjG6tA1Hbq1Snf+I7vaa9bK47mymmSJO9nt1EyY9v2mF+a09jNCXpS22Vyy15jvq r1f9CF+p2t3xvzuh2qaWy+ypSdcDI+KW6LJynet7qkjQAZ4W8dx7/4zyaOSIc+Kg1uz32A wQKf0Y0K95iASusCzPzcAr0aZ0pomMQrVtqDllBk3I5W3rdSzPk7QMHcQhklbw== Received: from localhost (unknown [IPv6:2a02:a03f:894b:4700:6dc8:7b7b:bfc5:33e6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: tijl) by smtp.freebsd.org (Postfix) with ESMTPSA id 6D3CC228D3; Mon, 31 Jan 2022 16:02:52 +0000 (UTC) (envelope-from tijl@FreeBSD.org) Date: Mon, 31 Jan 2022 17:02:30 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Vladimir Kondratyev Cc: freebsd-current@freebsd.org Subject: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related? Message-ID: <20220131170230.3f9155be@FreeBSD.org> In-Reply-To: <4611d16a-ef17-d8f3-c2c0-1b1091723646@FreeBSD.org> References: <4611d16a-ef17-d8f3-c2c0-1b1091723646@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-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643644973; 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=IW0TO2rwaYC6eRcgmDVEN+7Vw3XfIBowOgkdUz87bJ0=; b=k0A0CGjWpjcsTVO3V2h03pirPHlocbYigufylD2Wop2mFsR8+9i8+qq2X/z6S7+0WCI79O 9jGIKAjqtBRgA1bGNuClcS+PsxjsBpLv2rC3YYofY6SOmIaElH2+R0EXMXAlYmGWM65wQq inVgFJ4LkZI4Zvoo/WuxWJ7QsdRqdWbnH2ld0PNPILNEvhI7yx4zMpr5v0t0ZWd5dTrrWf QyJxICCiW46zb7B+5QM9n1vX1Pg4g1b8MwK77zRfovv9XW8kO0ksAg/sPmEigvLxE/XxH6 AKgPdZhNY2jW2gJHawOMh96mOILQX/roKeFfqBpS4yd6Ltk7uKUpzItQ5JBKmw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643644973; a=rsa-sha256; cv=none; b=pHKCNV8klnlYVk+/IS+SvYMN7vxFZCYUcTNxjoPAj3xjcMCLSpGTExElSlxcjzE7EKHoSo Q0mLmi5mKKlJipohW7oRDoLYRFUJ7DxQMnol+/xHmfM4pRQZ4lCX2GqoYL0apBeiAwrtX6 K+0nJvgRwUq/1toyxyx0Vzn/BKEeoLRMw0bvFSpKMSDfqkUvHc5Oj2wz6Z+phXuJue/cIn Z8roRzwW5wqTmIjL1IhoVN9RTwMM5f74IK8xR0BdZUsukgRu/H5/XPmymUNIlMCP/DCZ8X hodUUjpJBQFj5VMsiaei6/3qMuZDte0XOSM5raoL7sjSgD8tXJct3AxaPFtPww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sun, 30 Jan 2022 21:23:49 +0300 Vladimir Kondratyev wrote: > On 30.01.2022 00:25, Stefan Esser wrote: >> After rebooting with freshly built world, kernel and the amdgpu driver >> my console stopped working. It goes blank and the display goes into a >> power save mode, as soon as the amdgpu driver is loaded. >> >> The GPU (a Radeon R7 250E) is correctly detected as before, but there >> is an error message "drmn0: [drm] Cannot find any crtc or sizes". >> >> I'm asking here and not on the ports list, since the AMDGPU driver has >> not been updated for half a year. But to be sure that there is no mismatch >> between kernel and user land, I have rebuilt all X11 server and library >> ports. >> >> There have been changes affecting the i2c driver, IIRC, and the error >> message seems to point at an issue obtaining information from the LCD >> display. > > drm-kmod commit 534aa199c10d forced it to use i2c from base. > > You may try to checkout previous revision (444dc58f0247) to find out if in-base > i2c is guilty or not. I found that since base dbc920bd9a9b (linuxkpi interval_tree) linuxkpi.ko now exports some rb_* functions (from rbtree.h). These are declared static inline but the compiler may decide not to inline them. These functions conflict with the ones in linuxkpi_gplv2.ko from drm-kmod, because both implementations use a different order for the fields in struct rb_node. From nobody Mon Jan 31 18:27:41 2022 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 A1E96198BD3A for ; Mon, 31 Jan 2022 18:27:43 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4Jnc4G3x4bz4rtD for ; Mon, 31 Jan 2022 18:27:42 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 20VIRfLM071294 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 31 Jan 2022 12:27:41 -0600 (CST) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 20VIRfIR071293; Mon, 31 Jan 2022 12:27:41 -0600 (CST) (envelope-from mike) Message-Id: <202201311827.20VIRfIR071293@mail.karels.net> To: freebsd-current@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: randomdev hangs during initial boot of -current on Raspberry Pi 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-ID: <71291.1643653661.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jan 2022 12:27:41 -0600 X-Rspamd-Queue-Id: 4Jnc4G3x4bz4rtD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [-1.28 / 15.00]; HAS_REPLYTO(0.00)[mike@karels.net]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.68)[-0.678]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.91)[-0.906]; DMARC_NA(0.00)[karels.net]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[mike@karels.net,mike@mail.karels.net]; RCVD_NO_TLS_LAST(0.10)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[mike@karels.net,mike@mail.karels.net]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N I hadn't updated my Raspberry Pi 4B running -current for a couple of months, so I booted the latest snapshot (Jan 27). It hangs when it does the "growfs" step, expanding the root partition and fs to fill the SD card. When it hangs, it prints this every 10 seconds or so: random: randomdev_wait_until_seeded unblock wait I waited several minutes the first time, and 20 minutes on another trial. If I hold down the return key on the serial console, the device unblocks and the boot continues. This only happens on the initial boot, when the growfs script runs. The hang happens on a Raspberry Pi 3B+ as well. It also happens with the two-week-old snapshot, but not the Nov 25 snapshot. The program that's running during the hang is awk, doing a read, according to ^T; the script uses awk to parse output from mount, glabel, and sysctl. It sounds like there is no source of entropy at this point, and there was no cache. I don't see any changes to the random device since this was working. Does anyone have a guess what to look for? A bisect would be rather laborious, building a modified SD card each time, even if just testing kernel changes. Any other suggestions? An excerpt from /var/log/messages during this time is appended. Mike Jan 27 10:38:48 generic kernel: umass0 on uhub0 Jan 27 10:38:48 generic kernel: umass0: on usbus0 Jan 27 10:38:48 generic kernel: umass0: SCSI over Bulk-Only; quirks =3D 0= x8100 Jan 27 10:38:48 generic kernel: umass0:0:0: Attached to scbus0 Jan 27 10:38:48 generic kernel: da0 at umass-sim0 bus 0 scbus0 target 0 lu= n 0 Jan 27 10:38:48 generic kernel: da0: Fixed Direct Acce= ss SPC-4 SCSI device Jan 27 10:38:48 generic kernel: da0: Serial Number 40118905201B Jan 27 10:38:48 generic kernel: da0: 400.000MB/s transfers Jan 27 10:38:48 generic kernel: da0: 228936MB (468862128 512 byte sectors) Jan 27 10:38:48 generic kernel: da0: quirks=3D0x2 Jan 27 10:38:48 generic kernel: random: randomdev_wait_until_seeded unbloc= k wait Jan 27 10:38:48 generic syslogd: last message repeated 48 times Jan 27 10:38:48 generic kernel: random: unblocking device. Jan 27 10:38:48 generic kernel: GEOM_PART: mmcsd0s2 was automatically resi= zed. Jan 27 10:38:48 generic kernel: Use `gpart commit mmcsd0s2` to save chan= ges or `gpart undo mmcsd0s2` to revert them. Jan 27 10:38:48 generic kernel: lo0: link state changed to UP From nobody Mon Jan 31 20:13:31 2022 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 DE60A198B50A for ; Mon, 31 Jan 2022 20:13:38 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 4JnfQV1DC1z4jKf for ; Mon, 31 Jan 2022 20:13:38 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 66F0E5C0182 for ; Mon, 31 Jan 2022 15:13:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 31 Jan 2022 15:13:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; bh=oMpakG4Sr+OWlD9ydGCE64WaA4t0h79S1d12PX 5koro=; b=F5J5R5vlOzm6QbP0GhhrLNyEIA38En2Z3IFfG1nDE0DxumF66+nQSj i6TbYmiolZnbM2Fxprz3DAMkPocwF0M0dRkJjlBRn5sj1LBaUNg+MhQYcrW4pdG4 cRDUmoTUH9J1LA1k2cJAYgq0xZvUpoCba73486VQKJHUNDah/JVSEQxEPTPraAws iP6HL9ttjqOPY400Bp6HGIlanhYG5C1iOrJekrXsF/HCcBrVc3LonCoMZetlWk4C 9BDcAsJJn1mOdijyqosusAE/nPLCHZ0kt3ZSbL55EE8YZi56Jgfq4pGs3QR4f5LY tMpiZDqdusn669gKQmO2j6SsorfrRaGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=oMpakG4Sr+OWlD9yd GCE64WaA4t0h79S1d12PX5koro=; b=J2i5NeVFLKtnGTs6BbL41C8roQILnTXFc omMo+/83PFaKQ7eW8of5lXcIZl6DOChKwWQwr8+xOel0WKIqsrm26rQ65VmGBFmb eSVtlVi9AQcVAvvzQMNyQhv0m/zc7TyjGl222m/e5jhwIhryPwjYm44dDsqLKMZo GwcOm6cTpgzseTooyqZmP7fLT4BwewS57QVVdoPRd2RCkyiD7AvOp0kYjpRt4vZu xDeesiiubsliMalu6Hu4KgQ5mp9pOzW47Gs6GwkNdOJjoREg+h8Dk1bJHqH9Hf22 2uigVWZnTVISIaF+1W+7I2vwMWZBqihY7ggIj+UBpB5wA/9lXC/KA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrgedugddufeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfvhffutgfgsehtjeertd dtfeejnecuhfhrohhmpegjuhhrihcuoeihuhhrihesrggvthgvrhhnrdhorhhgqeenucgg tffrrghtthgvrhhnpeffvefffefgteeuudekhfefvdfhjeetgfejffffieetvdfhfeejff ekleegjefftdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpeihuhhrihesrggvthgvrhhnrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 31 Jan 2022 15:13:31 -0500 (EST) Message-ID: <2523cbfa-f44a-da34-7e24-d92e5dcbadc6@aetern.org> Date: Mon, 31 Jan 2022 23:13:31 +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/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US To: current@freebsd.org From: Yuri Subject: smartpqi: panic: malloc(M_WAITOK) with sleeping prohibited Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JnfQV1DC1z4jKf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm2 header.b=F5J5R5vl; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=J2i5NeVF; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 66.111.4.28 as permitted sender) smtp.mailfrom=yuri@aetern.org X-Spamd-Result: default: False [-4.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.28:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28:c]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm2,messagingengine.com:s=fm2]; FREEFALL_USER(0.00)[yuri]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; DMARC_NA(0.00)[aetern.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[current] X-ThisMailContainsUnwantedMimeParts: N Got this panic after booting GENERIC kernel: panic: malloc(M_WAITOK) with sleeping prohibited cpuid = 3 time = 1643658859 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00c7b20ae0 vpanic() at vpanic+0x17f/frame 0xfffffe00c7b20b30 panic() at panic+0x43/frame 0xfffffe00c7b20b90 malloc_dbg() at malloc_dbg+0xd4/frame 0xfffffe00c7b20bb0 malloc_domainset() at malloc_domainset+0x36/frame 0xfffffe00c7b20c20 bounce_bus_dmamem_alloc() at bounce_bus_dmamem_alloc+0x5b/frame 0xfffffe00c7b20c50 os_dma_mem_alloc() at os_dma_mem_alloc+0xe3/frame 0xfffffe00c7b20c90 pqisrc_build_send_raid_request() at pqisrc_build_send_raid_request+0x78/frame 0xfffffe00c7b20d30 pqisrc_write_current_time_to_host_wellness() at pqisrc_write_current_time_to_host_wellness+0xff/frame 0xfffffe00c7b20df0os_wellness_periodic() at os_wellness_periodic+0x1a/frame 0xfffffe00c7b20e10 softclock_call_cc() at softclock_call_cc+0x14d/frame 0xfffffe00c7b20ec0 softclock_thread() at softclock_thread+0xc6/frame 0xfffffe00c7b20ef0 fork_exit() at fork_exit+0x80/frame 0xfffffe00c7b20f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00c7b20f30 The reason seems to be obvious enough, changing BUS_DMA_WAITOK to BUS_DMA_NOWAIT in os_dma_mem_alloc() helps. From nobody Mon Jan 31 21:20:40 2022 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 72F761989F9A for ; Mon, 31 Jan 2022 21:20:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jngw45WLqz3hGC for ; Mon, 31 Jan 2022 21:20:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643664045; bh=9wWGJu+k9wBGEZhrOxVUX3smjbxxYH8qh5cCROLyBIg=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=ZDtQtYznkObYg4ohBUYvQk6LdwziJwv8/O5XMuuRbKNSsFXSG2SRz7ctl+R+nsD8ydkXNuhdyOB/2vZ/cBWt2HuMOlVkNvdaYBwuSudjs3s/iCTAdxwT90uF3rkPpDGFpLFdGN4cD/49JQ+BDS9lnx8qKsieDLrrQyPPjpFyJeziIFGJEUH22eVprObCBT3PSxx4UmKhW7XccCCMFYhCCJVb/ePaM0RbZyU9+Np8TZ5rN5+QJgkGkj/KwMWsg84KytoGeHbe0+I1RBtifllwbUGqH2PpzEgsG+xk4xjphZKSQGTJ3AwF9TZzy4B4kOdN4ijbYQuKQ1SPTQ8afuif3w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643664045; bh=7NmSHQdEC1g83afifyChR7AjJ60fCBJZlypirncmngx=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=B3qrDYZxr4z1wZN9mGwk2KcUF7cb3UnA5fgRCMLHffoZSXqzTHtByr+0boypKcsKQ+Xc8qs+IowT3E/GEbIK2L/BO2KQu9BqXnLcQrcoFUa/AxGbpVzqtUIdKw+IzofLxuQBlC9k0X6a61Xb1FcKMGM5N6sFK0gWWHZq4fTtEFSOvDL54/KWKEtykIo35AIukO20Tzo7nl4nuBkuS5fmIfR0zc8hvAXg6RealaRrSQXZIWlrSroSZze9sLhm0/GQG8Z+wtMVphisRmkH88EPMGhuwNWv2Qv6yxRmTdJs5ulNkSran3aAy6JMElKlGKykjtEd3Pp+dJVawCb8QN5oqw== X-YMail-OSG: GmXolFkVM1mddh6oY1m7O1mdLvdyrkOh1W6kSXJJxu3Iac8i7MyIZRrR1hSWNYu 8qwABeFj3qKg8suJhf3l3N2iscPgdMsa1jgBdA7eKfXjQzMz4fBqWC3rvBCYejf50lSx0sbJb1Nv ylRda2qOkxLmj1Ce_sx4pyFrBWpblpEF2XwTWrP90larUmpaVliYnY1Cv3HvqLp5dFtNVv5SiDF6 c.DyqSjv7EM.5hl70kNFouszCmIe3e2LKqfsGdKridUc1Rsi6.2f4FeQkQdQ213XE0bFefSW0pUs V5lxdFMEYnF557h7QyeTg0WdQ5TtPArmm3st_.R2JJy7HaIjz_aWatNdf8CPHHsIaFJr2kLwsu.P p22fCTTLqa8DPQe_y8T6Z97VSbN_lvPkO3GmXk7weSwhgyVm1LqJQPkL3f2R32eUYeN9JGt2jJN3 1vhZab4ELC7AvYkGoO90k.VXYFnStUIi79uGB5Broj2ZE7xJDI8gVWBsbb04iNPH6iLsd2FHbebt CM9xkH8J5ruVOJYNF5lGDhmn5UWr9cDW4IVoGIqPBMTuX3wiqf6gzPg6NRfD1FjI0lWlOcvON36h A4AKCGv1uDBIkR6PDWQwZtyTtFld__VUjHj0Cwp_yiO1ZzvdAY73TNVp0MRekzHOpmyn48nI83Hc H632iSEIOLi94_4LX2BZ0ZSZlOI1zC0HHHIIWt07PkJNqPSGJEMZdYywe.XXgmIoQnc7dEGjazbY vSLgSLCk90KXtU3ZaNnhQcZww.Begk15X3pInDpwlljhBdQqMUas3Z1mRcGTl9PDIxobiATnEO_8 rp5NZiSkjtiwT0QDEXPpmJq_s9ZTalzhaqOl_jP03VxWFRmAguvSF16Xth6WPsHVZb4bN8XMVRzJ QFDBilJyxDq9K34yGofOIkXks1Co80QqNaezvyjC_xRW0SPhuxCPUSQt91a6P68VJUmxWSyj8iyK QIlVDBVibC_dXsyJHsB4jCn7WXw19wAtqpHoT4yh7Ma.OYYvkbWxaKR1gQ8avoD_0NioYBN5Xlf6 _hgYVjgaZRwK72vn7FVjvOxlESz4lf_y_Pg8G2RGbCWYjBtX799GWNqz_wKZUBKgNRG9FDHTEJhc STffKEi2dPL0JaTNCShfk_Ytof5i91dzK5pYyPF1nq5fThXZPsEt_4AyUjgDrEENlUWscKH2L9qz I2nKjUIVbUF4Gu_aHLiVhXEWlT9.h2TUrfy0GxvFdd6MiTyl9QeM2T7q2eswi1KvGv6Z6CSk9JIy Zgb7C7NoahixZwPWux3pACTTMP5v4suxqNGgOBoU5.Qefj9ZEpgcI7YTRUh1XtVaaDvCLsLxq8BE 60jDXpXQFSNs503cbkX1T7uCxPW5v1pm4rfIzKXWyTnZ_6yp0lJtW0i1POiR32Thy4tvVlpNNkRZ SjWg44TGY2bIoBxQvfkJP8t0gw732SSQMxBzFGSgIwh7HOTCnDHLJxu5KCszy3xf2i6oyjs.nmdv ReeHRA37i3hLbqwbiWmEBPe07Ome4ejkrWdIwH7thCUi2FX9Ni7g4q8bodEsbY67.OWArpfrR84Y .q.arXrFecCGcwK06y8TGSd8ij0E_7WnA058xiH79vjb3I6DFjzh3T4qnxlnoIvSXgKRPXCV061E mt0yV9OusygShB_Kr2EzkcT8fjvkJRShWv4FOWOofeesgYkvc383TGw9k2Xpdze8O4gvfuLuObxW txOyjn_Rt_eAVB9JQ1UZjliaQ3jC6inYdrk_0IMdYpETUy0CHSw7_RM7LMMb2Z65zHPVLGm8qA_U gEamJhecHexKudU2zgiNTAA_f59y26dVkPpd.f94v1R9XlI56k4aUf2Mhgy9vQmwOy5mi8v309OP .R4rVpFqJKiAnFMTcZXzFD3PLjglntbKJOC.m9eFLhcFSwoJoEneQNZR.33bpf5LpmLPHzh3pHug GJzgnP7FItnvFuX94VZmPTo58P.9J9bSed3pxQuAX5MXQeEg_Ngn8Lvm2Ma7OxVgtLzz5kpqy.nA iBFK7LYo21AfYMPJxtGABJPIdkpviat7Tnmyr7gxAhJELwEk2UgDfRLvC1IXqoSIIWCyIbo2ubx9 ZB4o52g1509VZf7AqKnj6Gvu1eGSc_w92jSLkQ6_1vOSgm2drWaoNFucmeXH2GMAt6i13P2yym4P bmLMorzCXlU9mbUH09dtSSFTomYUBM1LaACaWm3lJtNN3fMAMwNTS2gE18wGu7tpnA3rUFZkGrrr jvVOHLCgOw8UHgx8rgDbDg5wxFCZn4PIUHQ_09.bHk9DPWFQ5Qkgcf1woeYAAN7g.JJzsUFgIJYt UzXIudiQREEI_cMQQv9X_RERC2zQ.Ogo1druASblB2ccgrimWLmUFzXwoT2Di X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 31 Jan 2022 21:20:45 +0000 Received: by kubenode538.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 193e185b3877ddd979439ccb6d5c3be8; Mon, 31 Jan 2022 21:20: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 14.0 \(3654.120.0.1.13\)) Subject: Re: randomdev hangs during initial boot of -current on Raspberry Pi Message-Id: Date: Mon, 31 Jan 2022 13:20:40 -0800 Cc: freebsd-current To: Mike Karels X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4Jngw45WLqz3hGC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ZDtQtYzn; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Mike Karels wrote on Date: Mon, 31 Jan 2022 12:27:41 -0600 : > A bisect > would be rather laborious, building a modified SD card each time, > even if just testing kernel changes. Any other suggestions? Historically I've used: https://artifact.ci.freebsd.org/snapshot/main/?C=3DM&O=3DD and the likes of kernel.txz (or more) from, for example: = https://artifact.ci.freebsd.org/snapshot/main/b4cc5d63b6112746598d21413c98= 00a43171da52/arm64/aarch64/?C=3DM&O=3DD to update just the kernel (or whatever) and rebooted. (It can help to have a somewhat older world that is left in place instead of running newer worlds on older kernels. Avoiding needing got update world as well has been helpful when testing for kernel issues.) This avoids building the kernels and allows a somewhat bisect like activity until some subrange has no arm64/aarch64 artifacts available. One can sometimes run into the dates for the sort for: https://artifact.ci.freebsd.org/snapshot/main/?C=3DM&O=3DD not matching up well with the dates on the files of interest in specific sub directoreis. (Some sort of directory update?) This can make the bisect far more difficult, given the choice to not have the directory names prefixed with text that would sort by a date/time estimate when sorted by name. (Only using the commit id/hash completely randomizes the naming.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Feb 1 00:57:37 2022 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 AD3871987B46; Tue, 1 Feb 2022 00:57:47 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 4JnmkL3y14z4fNB; Tue, 1 Feb 2022 00:57:46 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 1F3E55C012A; Mon, 31 Jan 2022 19:57:40 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 31 Jan 2022 19:57:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=pUsD90Ob4/bClRK66ab97l5KpxKwwQfoU7Nxle svA5Q=; b=mvnAx48uOPLjpXFdK7L5ACeGJhrHvg5kbXRcBG9cW0lP9GPgdYYGfT Yjv4MqXCOExD3GPZZYc/0fSamABo5CeM/1D+BP/tRdxOxLuR6wP6hCnXC4iO/bBM ptLVkYQ5iGn0TW6P2Ct4k6Ziu4mQHXRn5sJJijQW1O/U3U/RGKtpg/+O04Pm7KVC D0aknGFLuhjExwL30CU3xCIuAmguu/NSKM75AwJSj/N4U+zF/h8ag7sM+blw3k5H UbcmWN3N7+7lG8e/jpWyVVlhMpA5sAcYLp7zyE9ApS6ikZSADQ6my/tHnHvOAyWu Ukk+Sui/41fK4Sq+6rzEp1Q8gUKUBdXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=pUsD90Ob4/bClRK66 ab97l5KpxKwwQfoU7NxlesvA5Q=; b=Dg0RFg+9RGYQueToQaTUjOqdqngL4NuN8 OnbDldxVSH63sKyElM7Z/sw/3EJsG/Ym9h9YM1+0D1lgca+c7GMi9gRYZ0LGb8Lb +1I9l6+bmgcRs9y/Xq259qnmWBgVXDmktGy4tn1E1rs4VZWXQsVqthB5jAia1vc9 s1/zE/qRa/oR3GoX8W7djOZqv6cqWsR6aYkZsXuDuO2i6AElAeOQeRNSDRvqfb96 dk8kgcweoRAT5usj3RIYPNF119E9YeTHhIQybL2AOjTu2wQXxLMc5auwt94rQ47W Vq0ImkAFqqmjmBLw+XgTw7y19rBn/X8J9tLpoLKm5vCfg+LC/Jsgg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrgedvgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 31 Jan 2022 19:57:39 -0500 (EST) Date: Tue, 1 Feb 2022 00:57:37 +0000 From: tech-lists To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: POLLHUP detected on devd socket Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: <8BA9DE0C-81B4-420E-B326-7B7133EC31BA@dons.net.au> 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="0HnNK0L8r1/DIyKV" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JnmkL3y14z4fNB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=mvnAx48u; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=Dg0RFg+9; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm2]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zyxst.net]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from] X-ThisMailContainsUnwantedMimeParts: N --0HnNK0L8r1/DIyKV Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 28, 2022 at 02:54:25AM +0000, tech-lists wrote: > On Sun, Jan 23, 2022 at 10:38:09PM +0300, Dima Panov wrote: >> >> Will try to play with zfsd disabled, as suggested. > > since reporting the issue and disabling zfsd, the problem > has not re-occurred so far at this time (28th Jan) It's happened again. But with zfsd being disabled, it meant I wasn't detecting the problem except by indirect=20 means. Like "hm why isn't nginx working". The problem is, one of the things that stops first is syslogd.=20 So it's not recorded anywhere. syslogd is loaded with these flags: syslogd_enable=3D"YES" syslogd_flags=3D"-ss" syslogd_oomprotect=3D"YES" context is main-n252544-7406ec4ea99 on a rpi4b/8GB. zfs-on-root. There is no microsd; it boots from usb3. How would I debug this? In the meantime, I'm re-enabling zfsd. thanks, --=20 J. --0HnNK0L8r1/DIyKV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmH4hXYACgkQs8o7QhFz NAWVCQ/+K0IZPz9OduFx6uRM5VAoxDznvhY/5H9e3+vGaiL3Wzc/tlP/+iFyOYTZ xKXcRND9Zckdwc7IeaKgRoBjyO7a4K0DMxVD4BnfZ3Fvh1cOOU0eYQ+a8kDUeCeL LlIsRjAbsRR3qVFN/pifKm2YWbXOgSbSfod3+dDdyf/HWiQfRFIS+BmY2tHy2MiQ pd7kHmZHhvXmk2kOz1Gk2Rk3kAB/Ysf1DrKu1QgiRt87fHoesf/7RyXh1wVVmPFL wUbm2XHJ2E1FbxI2ATAfeol9lB2jDWiU4AAYe+whKTWVaTWOtHXUUiK+arHV4KWu 8cqh2sVZtIQ/voTNrW2G0gjiltpHhZ58+dsKqARRugNA+Ph37ggJ7FAf5rPrRcLd fvUJ8CaJiUtNQyQVnBv+DUJcT2iKJ7tMxek8I7Qw0nw8s92xw7pEFvpuVD5zYPbi 3CNNqvzkOoqv0UfISSuTAASS9A8R+3VcRNKuEqEtbeZC0L/71ANmnEX5O1QS5lk+ wWu0GhExvVfMORyXaIqrd1edoypFL7+PA2oRsEx7XaOnsit0vwL2iuAkVWoXKczn eAJ6vEzNHmCjWRUNEElGHnlFxC5yMMOoO+LPxJW9U5KmMGb9FHRBc6K+D856fMqm YqDv5nYmeDnJ1X1Is2B+3sTgbGrWguS3w4T7y6Y7Gt+b0xCOD+s= =YmK5 -----END PGP SIGNATURE----- --0HnNK0L8r1/DIyKV-- From nobody Tue Feb 1 06:55:51 2022 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 5755819A10E0 for ; Tue, 1 Feb 2022 06:56:04 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201]) by mx1.freebsd.org (Postfix) with ESMTP id 4Jnwgl0wyxz4y3x for ; Tue, 1 Feb 2022 06:56:02 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (Haraka outbound); Tue, 01 Feb 2022 07:53:35 +0100 Received-SPF: SoftFail (connect.ultra-secure.de: domain of ultra-secure.de does not designate 217.71.83.52 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=217.71.83.52; helo=smtpclient.apple; envelope-from= Received-SPF: None (connect.ultra-secure.de: domain of smtpclient.apple does not designate 217.71.83.52 as permitted sender) receiver=connect.ultra-secure.de; identity=helo; client-ip=217.71.83.52; helo=smtpclient.apple; envelope-from= Received: from smtpclient.apple (217-071-083-052.ip-tech.ch [217.71.83.52]) by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id AC9722B5-715A-4BB1-99E1-E9F4248967E6.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 verify=NO); Tue, 01 Feb 2022 07:53:33 +0100 Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Subject: Re: smartpqi: panic: malloc(M_WAITOK) with sleeping prohibited From: Rainer Duffner In-Reply-To: <2523cbfa-f44a-da34-7e24-d92e5dcbadc6@aetern.org> Date: Tue, 1 Feb 2022 07:55:51 +0100 Cc: current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2523cbfa-f44a-da34-7e24-d92e5dcbadc6@aetern.org> To: Yuri X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Haraka-GeoIP: EU, CH, 451km X-Haraka-ASN: 24951 X-Haraka-GeoIP-Received: 217.71.83.52:CH X-Haraka-ASN: 24951 217.71.80.0/20 X-Haraka-ASN-CYMRU: asn=24951 net=217.71.80.0/20 country=CH assignor=ripencc date=2003-08-07 X-Haraka-FCrDNS: 217-071-083-052.ip-tech.ch X-Haraka-p0f: os="Mac OS X " link_type="DSL" distance=16 total_conn=2 shared_ip=N X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,BAYES_00, SPF_HELO_NONE,SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.1 X-Haraka-Karma: score: 6, good: 21064, bad: 624, connections: 23548, history: 20440, asn_score: 872, asn_connections: 909, asn_good: 873, asn_bad: 1, pass:asn, relaying X-Rspamd-Queue-Id: 4Jnwgl0wyxz4y3x X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rainer@ultra-secure.de designates 88.198.71.201 as permitted sender) smtp.mailfrom=rainer@ultra-secure.de X-Spamd-Result: default: False [1.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ultra-secure.de]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.198.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > Am 31.01.2022 um 21:13 schrieb Yuri : >=20 > Got this panic after booting GENERIC kernel: >=20 Probably best to open a PR. It usually gets assigned to the microchip-people - I=E2=80=99m not sure = if they are following the mailing-lists. From nobody Tue Feb 1 09:39:49 2022 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 712D3198D6A6 for ; Tue, 1 Feb 2022 09:39:55 +0000 (UTC) (envelope-from tijl@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jp0Jq2qT8z4m1L; Tue, 1 Feb 2022 09:39:55 +0000 (UTC) (envelope-from tijl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643708395; 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=jaSn8H8U9wZisp1p7mBDyPuPeFCobGzuSn/zG6/a0YA=; b=QIP1j+3u4m0vJkkCvtA43+v6vNjpfg2tO0Y2iph7GrNXhnnjR18u6q6GR2Ica06ztKysa3 Sh7g6mxmAvK2GKOmaqkVEtkss8ewbqI6CEgYXUB/ZiBD+HtTThEFgCGYJG/C+uKNo0YecL JmqBAz+xeXBt0FI7MKfrQHXB8riGj1OcK+kYuL6AFdk8hbX2T02/N3Y8nuKh84JCf5Utiu qBs180TC2V0nxG/lzTwwAuirVREOthsrNeN6zxUXpi3BeGNWx6PW9JmbCxVVhRhLmAWvL1 ZOPHP7pzfa0X9sfWPJsUcq62ITzrJxd835s/gvmb2F/E5sA7LUwQlYtAj+h+YQ== Received: from localhost (unknown [IPv6:2a02:a03f:894b:4700:1063:43e6:117a:7021]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: tijl) by smtp.freebsd.org (Postfix) with ESMTPSA id CDF1E2BB1B; Tue, 1 Feb 2022 09:39:54 +0000 (UTC) (envelope-from tijl@FreeBSD.org) Date: Tue, 1 Feb 2022 10:39:49 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Vladimir Kondratyev Cc: freebsd-current@freebsd.org Subject: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related? Message-ID: <20220201103949.11e09ce8@FreeBSD.org> In-Reply-To: <20220131170230.3f9155be@FreeBSD.org> References: <4611d16a-ef17-d8f3-c2c0-1b1091723646@FreeBSD.org> <20220131170230.3f9155be@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=UTF-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643708395; 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=jaSn8H8U9wZisp1p7mBDyPuPeFCobGzuSn/zG6/a0YA=; b=P96aETby8sELkzPaf5PuurC1EFDYl6Un42D6B4JNTkxpBPyc8nnNTRrUJr6R7t09RrHFHc z1U2d/zP1PHy9WEN1mfIHvpzlYpyuC6vOwIJ0QJq5InhK29khUNIPeMA0I8jIiuafH2gpY i7vEbwnCL9JDXj0zuUDDBCo9DrekM38vAo4eKoIu1QKUgcNLDErQdEUxvJoFySmG4wHlZL z+35mus/EAJ6FC+QMMbGjSQuOSWUfFM/HXPkL3NDOUBAG7/Aca68wCiAsW1THaTz9mVNTr 2vgov29JdbaLTs9ryD7fUX9VWRQL659bsFOPpXb4uNoGh2EJsc/zlRTK0Cny/Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643708395; a=rsa-sha256; cv=none; b=Loks6PRlg0EDMB81G5rD8ZhUhILL3isUPyEn+tK8xSgxChYvkcgUNqlUxYmWTPq+SKuyiV 7b292IsXh9qvirGJh02tLbm3AswVfuB8oi5djjojlv0BCl7p3/8/YrzkVf07kSLJEZ1AyH uHeZ+T7hCGOmjVyvjU6Vknd9G+v12LG2pUwwMrWcN+gdWLbsH9paUbcF/n3uLDPz2cfBKR KtrTQhw1vKaMbmIR5PeW71OUgXKcvaEFbid9TbqfddQNGri5elLw0wfnPVVYiyRwBdALvT IJEPE4tX1YD7DaHFOHg7cx4O1ubEZxm7NbnTmr+f/LxRrrVzqMJNcNhl5R2QeA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, 31 Jan 2022 17:02:30 +0100 T=C4=B3l Coosemans wrote: > On Sun, 30 Jan 2022 21:23:49 +0300 Vladimir Kondratyev > wrote: >> On 30.01.2022 00:25, Stefan Esser wrote: >>> After rebooting with freshly built world, kernel and the amdgpu driver >>> my console stopped working. It goes blank and the display goes into a >>> power save mode, as soon as the amdgpu driver is loaded. >>>=20 >>> The GPU (a Radeon R7 250E) is correctly detected as before, but there >>> is an error message "drmn0: [drm] Cannot find any crtc or sizes". >>>=20 >>> I'm asking here and not on the ports list, since the AMDGPU driver has >>> not been updated for half a year. But to be sure that there is no misma= tch >>> between kernel and user land, I have rebuilt all X11 server and library >>> ports. >>>=20 >>> There have been changes affecting the i2c driver, IIRC, and the error >>> message seems to point at an issue obtaining information from the LCD >>> display. >>=20 >> drm-kmod commit 534aa199c10d forced it to use i2c from base. >>=20 >> You may try to checkout previous revision (444dc58f0247) to find out >> if in-base i2c is guilty or not. >=20 > I found that since base dbc920bd9a9b (linuxkpi interval_tree) > linuxkpi.ko now exports some rb_* functions (from rbtree.h). These are > declared static inline but the compiler may decide not to inline them. > These functions conflict with the ones in linuxkpi_gplv2.ko from > drm-kmod, because both implementations use a different order for the > fields in struct rb_node. Here's a list of functions that linuxkpi.ko and linuxkpi_gplv2.ko have in common in my case. Some are probably ok. device_register i2c_transfer linux_compat_init lkpi_arch_phys_wc_add lkpi_arch_phys_wc_del rb_erase_cached rb_insert_color_cached sysctl_handle_attr From nobody Wed Feb 2 09:40:09 2022 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 5758019A2EBB for ; Wed, 2 Feb 2022 09:40:12 +0000 (UTC) (envelope-from jsm@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JpcGh25QCz3lMn; Wed, 2 Feb 2022 09:40:12 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643794812; 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=aqn8Hov2HT29V0pvLT0VFQe72ITZR61Q2Pqw4pe+1G4=; b=XioSfqQccb5lBs/W7A43auOdT0adOXwPh3pYtZ1AX0VVCXf9uPUet4cEsUbbOksLS3tEQT VADoQG3xfpwY/eeoEjLUoBPjLMBuSDk5rbOcbWedO2NAn1J6pKXgaMa8HWQB2jVQesXCGT nC46oQmjOjo6ijVr/1j+Me0ojl5VlXGdd9AEozf5sYEvga/mw8iq1Lzz4ounVSYAUbS7aG rcneS8/DVY8/fWqd+UHyjSiSWXFTdDDCZj8ooMa3IE4FzpLEp2tdmJUmtyy/Db0fjRM6Yu O38estnwLtg1fmDhj6plgZA3v6a3zPnKBpt7MAx/lkp2109mlWvVspyhuWIfLA== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id AFB1C7BE5; Wed, 2 Feb 2022 09:40:11 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <3f375da9-c2a0-8c9e-33e5-d8273e84590c@FreeBSD.org> Date: Wed, 2 Feb 2022 10:40:09 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: randomdev hangs during initial boot of -current on Raspberry Pi Content-Language: en-US To: Mark Millard , Mike Karels Cc: freebsd-current References: From: Jesper Schmitz Mouridsen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643794812; 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=aqn8Hov2HT29V0pvLT0VFQe72ITZR61Q2Pqw4pe+1G4=; b=RvtnBXKjCFUDmaPJSZiRkDpqmV9sb43V9l45mwz6QJ3Og5hj5QlGPNIN3ByXW6U79qCBIa KuJU6BmBT3G2454BWZIl3laL5TAo2FwLLkcaDffYUZxeWOfKDm+Djize7ypbkCp8sX0NkT x1BjFE5NNdouSPmZ3MueavCdU75amzdnDKrTiGUpyvxTH0OzLOTDwAPLpYPgc75NaFjI8P +iAVggzQSCCqEatMItW3bCU4NTp0fHDvervp6AjoqV1PHdE9PZcft9OPNO/8Ces2vPD3Lx /HpYBYWQtJu6YM28o3YyX5Eb/DMIIp8fQKftYt3jL/L6t9I/4KYINNDWONd3SA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643794812; a=rsa-sha256; cv=none; b=n020xNGQAM6xrcOayqCislBPO0KUgwyAgHSrqFoAZsXMIMo4yTIEivwTI3Ry9+7XNobc5C 3iiatJyQGIpvt6uZI0gffMGENsnlyaSL+51xplB3NunyY52HFXBr+7L0JAKPNJIFwAsF6H rl+UAGiUmvHnWJWSwOIoO+45Iv1rgy94M5t5t7pn0GfO6oTyKwcYm+PhPNsIPw331BnBK+ 28QPNQlV3KMnJ3TDcKItrzYZwxaM/z9x0r1TDrwbl+D+msu8S3x7o2fznTyyRnz7DVMavy YYImDtAp0xP5fBe64j6cDzPMLDDFUMVevbcaE90PkPS5lYKcK+PRnK1HsN1pww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 31.01.2022 22.20, Mark Millard wrote: > Mike Karels wrote on > Date: Mon, 31 Jan 2022 12:27:41 -0600 : > >> A bisect >> would be rather laborious, building a modified SD card each time, >> even if just testing kernel changes. Any other suggestions? > > Historically I've used: > > https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D > > and the likes of kernel.txz (or more) from, for example: > > https://artifact.ci.freebsd.org/snapshot/main/b4cc5d63b6112746598d21413c9800a43171da52/arm64/aarch64/?C=M&O=D > > to update just the kernel (or whatever) and rebooted. > (It can help to have a somewhat older world that is > left in place instead of running newer worlds on older > kernels. Avoiding needing got update world as well has > been helpful when testing for kernel issues.) > > This avoids building the kernels and allows a somewhat > bisect like activity until some subrange has no > arm64/aarch64 artifacts available. > > One can sometimes run into the dates for the sort for: > > https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D > > not matching up well with the dates on the files of > interest in specific sub directoreis. (Some sort of > directory update?) This can make the bisect far more > difficult, given the choice to not have the directory > names prefixed with text that would sort by a > date/time estimate when sorted by name. (Only using > the commit id/hash completely randomizes the naming.) > > > === > Mark Millard > marklmi at yahoo.com > > Hi My bisect gives: The latest working is: dda9847275da79ccbb2f0b7079b250e28b3b3b2a The excact following commit: 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is bad. So 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is where the problem starts for me. Hope that someone can explain why 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 does block entropy/random seeding on first boot around growfs invocation on arm64 /Jsm From nobody Wed Feb 2 10:47:31 2022 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 E80AA17E8271 for ; Wed, 2 Feb 2022 10:47:45 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jpdmc5zN9z4jNc for ; Wed, 2 Feb 2022 10:47:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643798857; bh=a+GX+opwkWfqRh4j62QsoMK39eXzB2UieJKTktyQaZQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=b4u0uOUsISJ5J2rbfMkHcDki1FTB4VtE/Zj8E3v+btb4KuBg1pGnw1F2xFqTooSIhvnZ9tgb+nUa8o+gUKVBcT4SC7C5li9GpolFm8SysHncGTpjw3U1+QWrNJSEEkgeZCQw8q2bvc+cgLFG6zjfCykVuvDq0aRdQjmpYamW0EyocRfeSjtNF0zU44R/jEc5vK9UKVdgXvDKxPypVn9VZ7vfXb7Q/8ryfu1LdJyEhVcRsH0nPZ6FoACvsWA0B2UEvpueEs6ou6Ih6Ma2CGB/a761EVU4NRMrgfd+LMCj1idL7hWPFxEMAK1n52Jz3cOBtXkgwyEDDzOg8QUv1b1LOQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643798857; bh=TYm+mHEDuSouYE2wnZwBFsjqYoi3viJYU5QvI++o5i/=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BOeG/7AXbIZpkLaQnYSHE7lGGYH/86iPB/m/Sth5NKoMPLEUqMEM5nOPlskfsz0lupA38TVyifH8lTE+KwF3xklxZAsuxvDzQfgmJRPD77m/l/vUTbLF/yEtz2+EQiT0HkNMaMYshuW+QFXCN218eFix1n4KF9rGVBfp4chGhRCqD2Jmv66+CSDzX2ipcTEPhlaQ2Zjfyfhg4MZInMWXQd4dE+GYjowQwVzXPKz1P16s1UAo2wudc1rMeSXPqsr8C92YvkHVMxFOtAzhuRxdTYEx+5/ZqTMMqSkWHyMfmn0ZfZVmRiKT+HzgIuvNqELhJvxcnS27P3Yq1zB4SIHgmw== X-YMail-OSG: 5KdOUkkVM1mPKPi73c8aDE_o6BM0EaJcTp5qjAKmnvzDMVqA6XSaDqoUrsBd07C 3Pfq7raA0PS_JOuPMN57_VzbkJ84fIbOtaP28k15Ipw4FuzaIey29UzK9yvgOCGDhY2GPpdF7pE8 KOGK378TTS0HLqu2UiRwqkDMWzNWmUvXruaOFXW7Z96byaf9a3HMYHveDOhIWHTM0kl1V7g8mjPe _fcC8mmxocF6geWTXpq3AXPE8QLvC00kIJ3oiOvkLWYMhH6s.CeXTJ2zmCKwb2pQJPsqwzJO3poU HB2yjHa7R_XfWLxu08iuaM.mffqSanHXv6uH3ZR7vRs1Gyko5s7_HkWC5SqI9PGbDQafYPL2BuJB WH9Q.Cw905vvYi8PeRJkv1k7m26CGBe8ImIm5.S3iJxn7FaTvDDsl281qFCF6Qm9CjYb98j3xdz0 qL5r04hdgB3JGc_XrZuyrnL0PEgwCENvA4aG7tzxXge4WUNfUZLjub11u3WPdRPxRwOnXpjdZ6Iw WE5EeExGdSBa395FDMKOXoxjS5kHqhxRwk_EcccL982To1vy.biLDHb6AHD0BVhv_oQEKIL1JdOC _g44XHvaQQtYgnJ0F19lJ4or2aCKAeRCdqqDZ..dN36qm8rOnlxABKuUgVL99n4CqBMcO6KGKlIH KXiO3piIDsrKfhQWAaFPtUuBU3imGchHwkgFlqopLVS.5kOGaQcyTfeHDoCvPjqwRSbpbhMoz8cl qwamJ1AWQFCLu3e0hEWLI0bZm_P38l8aMRemUCHnuDMTg3x8mAVNDN2QU1DuHGekEZ8AEUF9SCPX HGKhEJ_x0p_5Zy_OLodqC2iLDWsb5mgeW1VGl7d7yUzeFSLNrD3LeNOvcgLVEO1kDLD36mkrPZLi e0rN2yLo5CNJKb8f2fstR6qDMec_9SpcIiPOhIajMkFSUd6JA_I30sjeNyYd14mi06hRJVKfYR3w vJUf14A0YBmtYF2WeCio3mrXezOkbYP75S_o9y_jy8iI1dbdFNgDvLUAzAB.d_sDCsesvMcngwkF wQv0vXJN5y78cwho4rZLpxD70oWUgQmna_mv8bL8_QUiRMzFLuisXFodDvEoTqz2pkfv1BLcXMxm oju7dOvfH5J_4KqT3hqA5ObwUvsrDVFO_RuLgaPyZfkI6Lq1IRxcLDCPCngY479xprAbbTYiPmZV RUgEH_q4bInem8Lwn_jgD9zxYDvMdY7JXbvnEujeYPgPuGbChesqcAs.2FJIWYGTwuF6MaxZ84fH vCstULaAnLZ.QfmN_gFfcVfyzoMDswkphfV0DhG1Kb1zkeUBa9Hy5q8RQlp_bVfKqbw2qhwWtlfb rrLx5I.0KVhbIpxcJLIvFD8xEva4ODmejhFoUdwtmS9d74uU8tXEmf.aGQqjBO.pbf0y416maHX9 uqYxC2XzCaUbIutGJwPxIS8FOPStr5h0zJRbOL8eBSohGiA4MB_I_Kytegxq8ZGMXOgQha5V51Pe Ai64N3AJ0Lp0BQhLjhLvKAyYaBcHTt9Hd6VZpom72PeNgVn1aWKYrxcirCFi7LQeCIdD8uFcgqLR pLj__YqMaIhz0jTLdY4d0eFecdkOo1QvXJqO2DOUPljZqDmWii2w_VBzddqithWYBoMrwbN1OEQb 1Pu3WNcA0sVi.HWcuQaNNehtxonxQ96wfJyWNeCx.bATUCXQ.U2h.iprIXda_eGUEe4dV4WRMHIn lmYcVwjp2VjySP3EdlFPzZ5McA9ZVtUOiNEJDwso1OEJRb2zl_w.oJc9JuNva0_NedEtcH_HSns3 vCNwIQC1oBatyzi4ityHAec318qZVgWuP9bZgWep92Ov3tjEKI3cxAZqhQmZPpWNWnTJrVjQ3QqW 2k_kFXTnSVRJ_Exxc9z.YrqTLIQZbv0ZdRGqfP4bZOyDJPINkiCDv_g7sBFpFLHP7u195BJE6DzV wsSQIuaE4BifVjvuWv3npzMT.ZNiJM6bC.1QxpNCs5XMwu34vXK.zBf6.I9UfOU.6I4w2pLR3Lw4 f7oy9h0m44_42IT9ZU_Uy_6PpRpBJU3mtIvoEZruZxvI1KvXfHXbaA0s0NKqf0DMVoKUtBpBfMYG dm0UdPVf2YdhUDkLnohz4KPH.nnN.C1Y9amWUgOuVqqJkzFh7AGAQU45A3FrV0CH5LF.K3_lfe_G xE3wSXtg5xOOHflP8.vYmJ7782HsctaZO4KnTvmFvwa0mSSKuAWtSBPkmdUhspe8W8enjD60x0mC A9GhTjvU9zamO6l1opAOLa4pJu3QfkA44xunSuONMJbcrfU1cFeNhsKyZBuHZH_FLLXzc.nM9hud fVE6UeKJm4oPFLX_dQ6AaYNNQSmazFn84c6CuYhv5EfxJfvrSivC0NDWt1YI- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Feb 2022 10:47:37 +0000 Received: by kubenode531.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 97edccaf4d0d4383b0342039d6ceecb3; Wed, 02 Feb 2022 10:47:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: randomdev hangs during initial boot of -current on Raspberry Pi [main 74cf7cae4d22 issue] From: Mark Millard In-Reply-To: <3f375da9-c2a0-8c9e-33e5-d8273e84590c@FreeBSD.org> Date: Wed, 2 Feb 2022 02:47:31 -0800 Cc: Jesper Schmitz Mouridsen , Mike Karels , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <7C5570BA-8502-454C-B422-636BC3B416D7@yahoo.com> References: <3f375da9-c2a0-8c9e-33e5-d8273e84590c@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jpdmc5zN9z4jNc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=b4u0uOUs; 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 X-Spamd-Result: default: False [-1.52 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.98)[0.981]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.82:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N [Forwarding to John Baldwin, who authored and comitted: https://cgit.freebsd.org/src/commit/?id=3D74cf7cae4d22 "softclock: Use dedicated ithreads for running callouts." Also including text from the original message: = https://lists.freebsd.org/archives/freebsd-current/2022-January/001474.htm= l "randomdev hangs during initial boot of -current on Raspberry Pi" so there is a description of the problem wihtout having to look elsewhwere. ] Mike Karels wrote on Date: Mon, 31 Jan 2022 12:27:41 -0600 : > I hadn't updated my Raspberry Pi 4B running -current for a couple of > months, so I booted the latest snapshot (Jan 27). It hangs when it > does the "growfs" step, expanding the root partition and fs to fill > the SD card. When it hangs, it prints this every 10 seconds or so: >=20 > random: randomdev_wait_until_seeded unblock wait >=20 > I waited several minutes the first time, and 20 minutes on another = trial. > If I hold down the return key on the serial console, the device = unblocks > and the boot continues. This only happens on the initial boot, when = the > growfs script runs. The hang happens on a Raspberry Pi 3B+ as well. > It also happens with the two-week-old snapshot, but not the Nov 25 > snapshot. The program that's running during the hang is awk, doing > a read, according to ^T; the script uses awk to parse output from > mount, glabel, and sysctl. >=20 > It sounds like there is no source of entropy at this point, and there > was no cache. I don't see any changes to the random device since this > was working. Does anyone have a guess what to look for? A bisect > would be rather laborious, building a modified SD card each time, > even if just testing kernel changes. Any other suggestions? >=20 > An excerpt from /var/log/messages during this time is appended. >=20 > Mike >=20 > Jan 27 10:38:48 generic kernel: umass0 on uhub0 > Jan 27 10:38:48 generic kernel: umass0: on usbus0 > Jan 27 10:38:48 generic kernel: umass0: SCSI over Bulk-Only; quirks =3D= 0x8100 > Jan 27 10:38:48 generic kernel: umass0:0:0: Attached to scbus0 > Jan 27 10:38:48 generic kernel: da0 at umass-sim0 bus 0 scbus0 target = 0 lun 0 > Jan 27 10:38:48 generic kernel: da0: Fixed Direct = Access SPC-4 SCSI device > Jan 27 10:38:48 generic kernel: da0: Serial Number 40118905201B > Jan 27 10:38:48 generic kernel: da0: 400.000MB/s transfers > Jan 27 10:38:48 generic kernel: da0: 228936MB (468862128 512 byte = sectors) > Jan 27 10:38:48 generic kernel: da0: quirks=3D0x2 > Jan 27 10:38:48 generic kernel: random: randomdev_wait_until_seeded = unblock wait > Jan 27 10:38:48 generic syslogd: last message repeated 48 times > Jan 27 10:38:48 generic kernel: random: unblocking device. > Jan 27 10:38:48 generic kernel: GEOM_PART: mmcsd0s2 was automatically = resized. > Jan 27 10:38:48 generic kernel: Use `gpart commit mmcsd0s2` to save = changes or `gpart undo mmcsd0s2` to revert them. > Jan 27 10:38:48 generic kernel: lo0: link state changed to UP Later material . . . On 2022-Feb-2, at 01:40, Jesper Schmitz Mouridsen = wrote: >=20 > On 31.01.2022 22.20, Mark Millard wrote: >> Mike Karels wrote on >> Date: Mon, 31 Jan 2022 12:27:41 -0600 : >>> A bisect >>> would be rather laborious, building a modified SD card each time, >>> even if just testing kernel changes. Any other suggestions? >> Historically I've used: >> https://artifact.ci.freebsd.org/snapshot/main/?C=3DM&O=3DD >> and the likes of kernel.txz (or more) from, for example: >> = https://artifact.ci.freebsd.org/snapshot/main/b4cc5d63b6112746598d21413c98= 00a43171da52/arm64/aarch64/?C=3DM&O=3DD >> to update just the kernel (or whatever) and rebooted. >> (It can help to have a somewhat older world that is >> left in place instead of running newer worlds on older >> kernels. Avoiding needing got update world as well has >> been helpful when testing for kernel issues.) >> This avoids building the kernels and allows a somewhat >> bisect like activity until some subrange has no >> arm64/aarch64 artifacts available. >> One can sometimes run into the dates for the sort for: >> https://artifact.ci.freebsd.org/snapshot/main/?C=3DM&O=3DD >> not matching up well with the dates on the files of >> interest in specific sub directoreis. (Some sort of >> directory update?) This can make the bisect far more >> difficult, given the choice to not have the directory >> names prefixed with text that would sort by a >> date/time estimate when sorted by name. (Only using >> the commit id/hash completely randomizes the naming.) >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com > Hi > My bisect gives: > The latest working is: > dda9847275da79ccbb2f0b7079b250e28b3b3b2a > The excact following commit: > 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is bad. > So 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is where the problem = starts for me. > Hope that someone can explain why = 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 does block entropy/random = seeding on first boot around growfs invocation on arm64 > /Jsm =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Feb 2 16:50:02 2022 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 2D3A219B276B for ; Wed, 2 Feb 2022 16:50:14 +0000 (UTC) (envelope-from kevans@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jpnpt0V82z3FkZ; Wed, 2 Feb 2022 16:50:14 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643820614; 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=9p7TuR82uOOU0Xa5QUozyvizuFYg2wVK+SqfbDRK82U=; b=Lky6ZtF9S63K3aV/rNj6I3EgirbO7L9KqiAJoLbXJwbA4vAPsLdwLBB/RV5R+kFIPmPYUH zgURI1EyFgGkZWe2txOMrNBL8lGH/otTp+6IJu3v3T/9kAe082/od70QDo5OJ35mCB4viO J+SA+BCXg5uh7REC9+/PFFpPAQeg9wmPnKj3ND0zEAlx8N33Qh4ag3c/AIgvIQ7TmLiiSw D+xs1xVrqHGnk9OUqkzvq59NyHNAf+YkdD6fc4PzeYvZnjJT1D7Nhc+fnuOGm8thP6Mr2T deFtevCtdU00Npb6iPSMPKYy7sX4wTRczGcO6KADnP0lqf8AJpqnWddpNLQI4w== Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id CD158B4DF; Wed, 2 Feb 2022 16:50:13 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f46.google.com with SMTP id g13so139116qvw.4; Wed, 02 Feb 2022 08:50:13 -0800 (PST) X-Gm-Message-State: AOAM531mVEt7G9j3zLtScV8OB36x4RbXUaPt+i98pxsPXE8hqDM6ubtZ cel0v05kSU3UqjfmdYfl8ADr5eAD1Xlc/CvfLrw= X-Google-Smtp-Source: ABdhPJz2AaUw69PWO9ApOXZB5QOVrmFM0i+kT1dnWJ9446OoaiiVcdGcQkmjcoNoAlW6FVCfpn3VLoOnafQzbjRsdWk= X-Received: by 2002:ad4:5949:: with SMTP id eo9mr26863390qvb.95.1643820613255; Wed, 02 Feb 2022 08:50:13 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <3f375da9-c2a0-8c9e-33e5-d8273e84590c@FreeBSD.org> In-Reply-To: <3f375da9-c2a0-8c9e-33e5-d8273e84590c@FreeBSD.org> From: Kyle Evans Date: Wed, 2 Feb 2022 10:50:02 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: randomdev hangs during initial boot of -current on Raspberry Pi To: Jesper Schmitz Mouridsen Cc: Mark Millard , Mike Karels , freebsd-current , John Baldwin Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643820614; 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=9p7TuR82uOOU0Xa5QUozyvizuFYg2wVK+SqfbDRK82U=; b=vwQABK2uQvnZ9ie9fOjjAe3mBz+gyrFfql6F3rkBzf8VzLVBAXuFUodgNJ/ivqzUbodMJB YjxgZ8T2wKfKn3OO7YWAzou1zbL4562Xro1O9r4ShN0h1vTw45Bqmc2qpAx9VYC+jdggtW MymyvHx4YPojfYXVWtd3SPg1ND06weCMU4LOIARoTpnT/CLl609nmvh6CrpGD9huOyWxsw HtFf2xGBdjv2/58mDOSwj/l5chWchpCNOr624o78hSSFezKACSfPdNU2CoLXFOCQ6DGqUY nIiNJW/uWa9JdB1+YXCfaB08zjAPeULL0Owhny0xtDchRJjrLE0IfmOAwG+Isw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643820614; a=rsa-sha256; cv=none; b=ikjMUThilVtwzpZhfQ3geWPs47V332kJ+z1K7xG+4cD1dov9LIpLRXoKPgsuCPhqkgDx7z 5XioKEIThVy9tmrM2GkFnaiTCicLFTjVTk7yHKo4bqCa63zlIitjMu6qIwQ420AcPJajGq VeGHxoDwa6jnKaW37NRG2SZrrvvgtmCHG7bceUGCzB6jZxm4fUGgkcIdxhf72+8I2azSj7 qtuimBoHUD095GWqBLxYiTJfi4WslXnF+79yv8oCAc6kAdeOK4HQKU4Xn83QjDZLcSCyl3 q0cFBBMdQUHlofpoZnEV6M+rrwSci7zJWH0kZrtICLdumOOkWfRVqLs4y63IkA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Wed, Feb 2, 2022 at 3:41 AM Jesper Schmitz Mouridsen wrote: > > > > On 31.01.2022 22.20, Mark Millard wrote: > > Mike Karels wrote on > > Date: Mon, 31 Jan 2022 12:27:41 -0600 : > > > >> A bisect > >> would be rather laborious, building a modified SD card each time, > >> even if just testing kernel changes. Any other suggestions? > > > > Historically I've used: > > > > https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D > > > > and the likes of kernel.txz (or more) from, for example: > > > > https://artifact.ci.freebsd.org/snapshot/main/b4cc5d63b6112746598d21413c9800a43171da52/arm64/aarch64/?C=M&O=D > > > > to update just the kernel (or whatever) and rebooted. > > (It can help to have a somewhat older world that is > > left in place instead of running newer worlds on older > > kernels. Avoiding needing got update world as well has > > been helpful when testing for kernel issues.) > > > > This avoids building the kernels and allows a somewhat > > bisect like activity until some subrange has no > > arm64/aarch64 artifacts available. > > > > One can sometimes run into the dates for the sort for: > > > > https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D > > > > not matching up well with the dates on the files of > > interest in specific sub directoreis. (Some sort of > > directory update?) This can make the bisect far more > > difficult, given the choice to not have the directory > > names prefixed with text that would sort by a > > date/time estimate when sorted by name. (Only using > > the commit id/hash completely randomizes the naming.) > > > > > > === > > Mark Millard > > marklmi at yahoo.com > > > > > Hi > My bisect gives: > The latest working is: > dda9847275da79ccbb2f0b7079b250e28b3b3b2a > The excact following commit: > 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is bad. > So 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is where the problem starts > for me. > Hope that someone can explain why > 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 does block entropy/random > seeding on first boot around growfs invocation on arm64 > /Jsm > That seems odd, but CC'ing jhb@ -- maybe there's something hinky going on since this is before AP startup for arm. From nobody Thu Feb 3 01:06:24 2022 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 CDA1D19A260E for ; Thu, 3 Feb 2022 01:06:36 +0000 (UTC) (envelope-from kevans@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jq0qc3xTzz3DLx for ; Thu, 3 Feb 2022 01:06:36 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643850396; h=from:from:reply-to:subject:subject:date:date:message-id:message-id:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1COApmbuskIckDSHQjzO4mOHaDUdyscVQv9x4oOs63M=; b=Ilj4hG7O3lA6vKw+a8yorfRI5Exv0KwKyQfH8OPZAfQEuBWgiP07lrIUzn36DTMqYveRot 731WaIW/vrJGxn26cqhGKpohHO2pGD6a0eVcFvbpUJuwqu2VSpGl4oGPa3yQIJwXepeb+D l3InOzUwL/7FG7s3KQF01NqhlNC1rqZm79uu3H06ttykcfIH5cb7StBIClGxMqb98djt0r UVU++T7nik0SurutHGVclxbd+n74bkhfDPbvLK+vFlS7yHzTmhcJy70aIe2EcxclW2y5gm lMRs3xZycCmCN0IgmLlSipB9J0xv9fZNPr4RIzPsX0Ew1KPqmWMA50Ov584p4A== Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 1097BF17B for ; Thu, 3 Feb 2022 01:06:36 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f45.google.com with SMTP id d8so1271558qvv.2 for ; Wed, 02 Feb 2022 17:06:36 -0800 (PST) X-Gm-Message-State: AOAM530GBfLUbpiHO2d0xw/qYamETUtWg28ZoFybkZA2ldra8gQQjhBf FPFxredIxOb/zA/HDi3AqQCoYq4JXULSBD/eM/A= X-Received: by 2002:ad4:5cc3:: with SMTP id iu3mt30634391qvb.79.1643850395372; Wed, 02 Feb 2022 17:06:35 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <3f375da9-c2a0-8c9e-33e5-d8273e84590c@FreeBSD.org> In-Reply-To: From: Kyle Evans Date: Wed, 2 Feb 2022 19:06:24 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: randomdev hangs during initial boot of -current on Raspberry Pi Cc: Jesper Schmitz Mouridsen , Mark Millard , Mike Karels , freebsd-current Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643850396; h=from:from:reply-to:subject:subject:date:date:message-id:message-id:to: cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1COApmbuskIckDSHQjzO4mOHaDUdyscVQv9x4oOs63M=; b=a0re+tUEwU7e968jKSv23VWaf+8AEPmSqWvOFwpXbyNvHxxj6Cpt3fQwzwlNhCXtrL8FnK tHohHzEePlMzyiP+KB5pYPaUBPLFj9Iu5b+Z2b1YCJ9/ZO1hNH7k1B8eQbVN1AXw3SxwqX nfZpDIOrjxjUE4kU2BSnoK6Z/BEwx/eh/Ts+NG++XGhAy/WrBWIXjjDkNvFRX1Gk6L7S7u vuScNCEvSQ7OKw1ysdiPYQmbWfDQsXkwRxgfYXA6c6V559dR7YilaLhHjIXwB1x1Ke5pEC qTfCzJW2G85dC1RMMrUhct/rm6uvWDOzgVGp3hnrLiCDX8BLseFsz/GbVwagNg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643850396; a=rsa-sha256; cv=none; b=WusWwnkVNGeu7qBeWlUGwDWVoATqH2AprqYglOxICaqlyxQ7oE+8GsG09ynF/kb0JJQsTe dfI+dUuNki6cKxNB0WgZG4NrWKtaMo8B3inq3RTFQjXvF2oOo/xgvZapxe60NTQMiawYxd FecRJ8XylK1GhXVHT/Ey6MBmcvpcOKBth/bHPsPhSTZlHLzqyoEAsnAc6Dhr4NN7RiO2Ix 55107IOiA5gKms5IWZWLm68rcNuCfJaudfG2J4DcEm2FiMH2twrHCudGL6il1nVGmnUo19 XnsNrSUc4eTOsSOResUMCxy1kQ5lgLLdp/G/T9lprLSneu5DupRNrjCYTcxQHg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Wed, Feb 2, 2022 at 10:50 AM Kyle Evans wrote: > > On Wed, Feb 2, 2022 at 3:41 AM Jesper Schmitz Mouridsen wrote: > > > > > > > > On 31.01.2022 22.20, Mark Millard wrote: > > > Mike Karels wrote on > > > Date: Mon, 31 Jan 2022 12:27:41 -0600 : > > > > > >> A bisect > > >> would be rather laborious, building a modified SD card each time, > > >> even if just testing kernel changes. Any other suggestions? > > > > > > Historically I've used: > > > > > > https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D > > > > > > and the likes of kernel.txz (or more) from, for example: > > > > > > https://artifact.ci.freebsd.org/snapshot/main/b4cc5d63b6112746598d21413c9800a43171da52/arm64/aarch64/?C=M&O=D > > > > > > to update just the kernel (or whatever) and rebooted. > > > (It can help to have a somewhat older world that is > > > left in place instead of running newer worlds on older > > > kernels. Avoiding needing got update world as well has > > > been helpful when testing for kernel issues.) > > > > > > This avoids building the kernels and allows a somewhat > > > bisect like activity until some subrange has no > > > arm64/aarch64 artifacts available. > > > > > > One can sometimes run into the dates for the sort for: > > > > > > https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D > > > > > > not matching up well with the dates on the files of > > > interest in specific sub directoreis. (Some sort of > > > directory update?) This can make the bisect far more > > > difficult, given the choice to not have the directory > > > names prefixed with text that would sort by a > > > date/time estimate when sorted by name. (Only using > > > the commit id/hash completely randomizes the naming.) > > > > > > > > > === > > > Mark Millard > > > marklmi at yahoo.com > > > > > > > > Hi > > My bisect gives: > > The latest working is: > > dda9847275da79ccbb2f0b7079b250e28b3b3b2a > > The excact following commit: > > 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is bad. > > So 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is where the problem starts > > for me. > > Hope that someone can explain why > > 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 does block entropy/random > > seeding on first boot around growfs invocation on arm64 > > /Jsm > > > > That seems odd, but CC'ing jhb@ -- maybe there's something hinky going > on since this is before AP startup for arm. I poked jhb out-of-band and we tracked it down to callouts having been a major source of entropy for early boot via SWI; tentative fix pending here: https://reviews.freebsd.org/D34150 Thanks, Kyle Evans From nobody Thu Feb 3 10:52:48 2022 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 74DAE19B0A28; Thu, 3 Feb 2022 10:53:08 +0000 (UTC) (envelope-from jsm@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqFrN2TjXz4cYs; Thu, 3 Feb 2022 10:53:08 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643885588; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Cf+BmybanCN5X1ZvHlYzfpUEtBPjlr+uQyQvoEVPxVw=; b=YgcfC5OkJD++sODrlHaGvRxVK0v7FhMvKO8Eo819FZD262vLMujtR2IMuLb29kMhKUJi94 LtQWIcpF4BKRAbP+faWeqdD0Yf8HSUCxF8hUgYZXFZNUkg/76AirvrEcwebjj4ZHUyjIFX vwXkBgTJIhlInLbdbF5Xsu+vu+qTYlyuElbzFu46tuPCDvdzhBkaeUYd7eE3WCfgynBGLi KqUXms1B8yj4xNpDtpndaxeTMPXTNC3Dd7qC/ENqRsyDjk35FGa8tsqTZJFYhbwZb10qxm ctkjSLquQpQKGQAsbE9sObkzGKa9YIKe/Yt7P/EuCV8+ytwIBrWLZwazXdDpeQ== Received: from [IPV6:2a06:4000:c189:1:1::2] (unknown [IPv6:2a06:4000:c189:1:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id CED3C242A2; Thu, 3 Feb 2022 10:53:07 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <54083e67-8052-575c-aab1-ad1cce2a7a3d@FreeBSD.org> Date: Thu, 3 Feb 2022 11:52:48 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 To: freebsd-current Content-Language: en-US Cc: freebsd-arm From: Jesper Schmitz Mouridsen Subject: d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks sys/arm64/iommu/iommu_pmap.c Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643885588; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Cf+BmybanCN5X1ZvHlYzfpUEtBPjlr+uQyQvoEVPxVw=; b=RWWAw25JGTye8ILWRtt7o4raTLGYPGGQVrQS1KIyVw9noS81hqn2KIBoQKUkN/cdudUWHn /GUPAE1KVf9sRnqsW/02mOho4YcVIRcRRanE5ZM6A2Kt7yeDc368Pd0WcWvRZGHaW1YzvV ya/Z8sQMSRk5q8TLmBzYNTnb+QwflRxA6QNnFWIPPcQFRI0djDN6xW8eG3V7GhCL+OzRGI eTo2yUd/knKwnFnmzZW28N0CxvqIj5PPIiKtafBvoobvX05BerpHYD37v9mYhU+cFHXo5a heVpmM06sAVvUrfACAdKW291G80YkwNjuHZ1NzSaQCcLjVIfsg3iIDystKf0vg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643885588; a=rsa-sha256; cv=none; b=BvP9qIIX60NhaZ7DLyTNmxZt5jDNbRHjH0EIBBGGKP6slPT5vtY7ixH/VentLH34ChXxqp FkvqCl1E83DC5u+I5oB/XOmzJPxqkx9DpRU3uGkgfVSO95OCbaT88PtdUoEXqwLNfQKQi9 K7TQhaivHpr6V2hJIlHEkv3ujRU0tGcXPJnmjwtuJAkST9IDhdm3+46XZ/+DJNeerAFafk gdeRbWddXFx84ORqeyI2K96TN3ig2Dry71RHF/tC9NZBO9QXc5rHU76t+W8ynmmwMHmyvl i3Cq+uBfJOOEZslOdc+6s3oF+vRaiZkILdDA4G8FfazIK/m/+79CgjA6eDo2ug== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hi d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks arm64 with options IOMMU. grep -nir vm_page.h sys/arm64/iommu/iommu_pmap.c sys/arm64/iommu/iommu_pmap.c:50:#include /usr/src/sys/arm64/iommu/iommu_pmap.c:539:52: error: implicit declaration of function 'UINT64_C' is invalid in C99 [-Werror,-Wimplicit-function-declaration] ./machine/pte.h:53:21: note: expanded from macro 'ATTR_MASK' #define ATTR_MASK (ATTR_MASK_H | ATTR_MASK_L) ^ ./machine/pte.h:51:22: note: expanded from macro 'ATTR_MASK_H' #define ATTR_MASK_H UINT64_C(0xfffc000000000000) How best to fix this? #include in iommu_pmap.c? Thanks /jsm From nobody Thu Feb 3 10:59:42 2022 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 8B8C219B296A; Thu, 3 Feb 2022 10:59: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 4JqG071Y0Yz4ffQ; Thu, 3 Feb 2022 10:59:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 213AxgJX016879 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Feb 2022 12:59:46 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 213Axgf0016878; Thu, 3 Feb 2022 12:59:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Feb 2022 12:59:42 +0200 From: Konstantin Belousov To: Jesper Schmitz Mouridsen Cc: freebsd-current , freebsd-arm Subject: Re: d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks sys/arm64/iommu/iommu_pmap.c Message-ID: References: <54083e67-8052-575c-aab1-ad1cce2a7a3d@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: <54083e67-8052-575c-aab1-ad1cce2a7a3d@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4JqG071Y0Yz4ffQ X-Spamd-Bar: ++ 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 X-Spamd-Result: default: False [2.73 / 15.00]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.95)[0.945]; NEURAL_SPAM_SHORT(0.79)[0.787]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-arm]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Thu, Feb 03, 2022 at 11:52:48AM +0100, Jesper Schmitz Mouridsen wrote: > Hi > d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks arm64 with options IOMMU. Which kernel config is it? Or is it your custom config? If the later, please provide it to me. > > grep -nir vm_page.h sys/arm64/iommu/iommu_pmap.c > sys/arm64/iommu/iommu_pmap.c:50:#include > > > /usr/src/sys/arm64/iommu/iommu_pmap.c:539:52: error: implicit declaration of > function 'UINT64_C' is invalid in C99 > [-Werror,-Wimplicit-function-declaration] > ./machine/pte.h:53:21: note: expanded from macro 'ATTR_MASK' > #define ATTR_MASK (ATTR_MASK_H | ATTR_MASK_L) > ^ > ./machine/pte.h:51:22: note: expanded from macro 'ATTR_MASK_H' > #define ATTR_MASK_H UINT64_C(0xfffc000000000000) > > > How best to fix this? #include in iommu_pmap.c? If the issue is with UINT64_C() only, perhaps something like sys/stdint.h inclusion is enough. From nobody Thu Feb 3 11:16:38 2022 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 8CEDF19BD2D7; Thu, 3 Feb 2022 11:16:40 +0000 (UTC) (envelope-from jsm@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqGMX1sX4z4nDt; Thu, 3 Feb 2022 11:16:40 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643887000; 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=fLHhk3UuyXgerRlQwp1wBDR3QYvf4jqYaPqsSKpq9Qk=; b=TFU1szCT0xLTHvXncCu51HCTd4O07znBE+f4/oRclZQKyYudZDIwmbKPlGaIjWBq7LvSq3 /v5umwATUFKvZ1+A7MYtoFa5vCOCM42GJLS0u+IcNZPyVWlYkxo2IjoCITjj3hRe3j0TJL VRJhUelmkOsMi/PXKo+p0HIXE88/s8v05mJ3MQR/aNIScBD4iwHzaZByvu0079iFNF5Dxd agEbnAAfTph+D8DDiTgpJsVQL3OA4aaOY+nSxMAhPzE3tNw1pYtWoGwE+xV10MC9hDKzuh 3dTBHyg4mSFhljcyfr2d7UhqYarq8VZ9jqzKXD1C8OAJAfwJuxrzn3ARuUcrjw== Received: from [IPV6:2a06:4000:c189:1:1::2] (unknown [IPv6:2a06:4000:c189:1:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 92AA0239C4; Thu, 3 Feb 2022 11:16:39 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <42609179-f079-02c9-c57b-263467f70814@FreeBSD.org> Date: Thu, 3 Feb 2022 12:16:38 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks sys/arm64/iommu/iommu_pmap.c Content-Language: en-US To: Konstantin Belousov Cc: freebsd-current , freebsd-arm References: <54083e67-8052-575c-aab1-ad1cce2a7a3d@FreeBSD.org> From: Jesper Schmitz Mouridsen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643887000; 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=fLHhk3UuyXgerRlQwp1wBDR3QYvf4jqYaPqsSKpq9Qk=; b=Mj7DzrR8gUnp/968UzIpxub8yJ/66JDlaBIpnhK3AKMkKIY1v7+wUGEr2k3PoSRIKXPFOR SfaPc1iYUrNJDQgjNsy9Lb9wUF1MbkxpP16XG93VQPmCMpX+CNb3DAl1WP2HPpK7C5Utf/ nFRLUn7OEKL9eh694eDSN50HYnBYbNbhBBQXXSX46v8VEmpsvK+FPY9s6aVBT+4n0oecK4 5wU452s1SBl+2/8jHWzp0MzEBTOIxEbvniL7NG628fTjwoubLw6JwYRKL68anuuVrx7ehH JUTgAwFviZAVkFr8h1gFn6PDLs4jXrUGDeP/6JODqt+JC++zcgfsI9b2jwH0Pw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643887000; a=rsa-sha256; cv=none; b=bu3v+l1hAuY+Ou5vaDhw9tF90JEhYw3W07iWGdALwtHONTZZn7wDbd/JUB/CWsiKcxgAF7 0Mk/Ya3DabXClQSLYD+pZpwbEMsZwTJtgCvyj89EDnQdtBpyDGEr6qel8yjWbmHUsBGvTw tBblA7Jkrq8XSsDVyPbtUOqQ1tp5uQRI8gGbAXwE1gCw0c7qkEhmyqax7C5XmqpHIDUdLk pPU7hDUF1VMAivv1SxI4TWwnfk3Y65YwaYSz6yQuaQnRltxgaPQLP6eZSg853nZy3WWobc 2BJ5h9wieVFCDwNd7JOhIdij8Uo93FWECjtPFiK+Dx1uRbMLefk7ZURw1MxVqA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 03.02.2022 11.59, Konstantin Belousov wrote: > On Thu, Feb 03, 2022 at 11:52:48AM +0100, Jesper Schmitz Mouridsen wrote: >> Hi >> d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks arm64 with options IOMMU. > Which kernel config is it? Or is it your custom config? > If the later, please provide it to me. > >> grep -nir vm_page.h sys/arm64/iommu/iommu_pmap.c >> sys/arm64/iommu/iommu_pmap.c:50:#include >> >> >> /usr/src/sys/arm64/iommu/iommu_pmap.c:539:52: error: implicit declaration of >> function 'UINT64_C' is invalid in C99 >> [-Werror,-Wimplicit-function-declaration] >> ./machine/pte.h:53:21: note: expanded from macro 'ATTR_MASK' >> #define ATTR_MASK (ATTR_MASK_H | ATTR_MASK_L) >> ^ >> ./machine/pte.h:51:22: note: expanded from macro 'ATTR_MASK_H' >> #define ATTR_MASK_H UINT64_C(0xfffc000000000000) >> >> >> How best to fix this? #include in iommu_pmap.c? > If the issue is with UINT64_C() only, perhaps something like sys/stdint.h > inclusion is enough. That was enough. https://reviews.freebsd.org/D34155 Thanks /jsm From nobody Thu Feb 3 16:44:07 2022 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 9BAB41989236 for ; Thu, 3 Feb 2022 16:44:09 +0000 (UTC) (envelope-from jsm@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqPdP3z2Fz4pH7; Thu, 3 Feb 2022 16:44:09 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643906649; 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=Xj493l7DagZjddl1YThELGtjAaa9UVWLav9diLyJSyQ=; b=Ph75pPO32qzGJ2JG/54MLfpMgsuxiT95JyIPlvIQ3mOBHrMBCBdigrFdx1zuKIIIPclOk8 Nl+qdxlY3aqoVh5h4nnaW/jfSV1Q1AYmexz8/dyWGpK886mj8nGQmKmc97Mwvh+6mVCFu2 +XjqMkLDmPuZ2JU7g0ZUAFD4Vdf1AEbycfuC0WNooTl6oJoGwshD9JDmJgOOK4H++UwLqb 9jLolnFsPAa1ZYKbjAqBYQeoswbsV1ZJ4kgnwW9FXTwC6ZAgGinVHA6r1DjYkf6UtrY5ww PZEfUHwa8X3w1V8BlH0rFjBskJEwI14pGVxIWWtYa3SCrL0tQM+KEepFtifrvw== Received: from [IPV6:2a06:4000:c189:1:1::2] (unknown [IPv6:2a06:4000:c189:1:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id D260A26D74; Thu, 3 Feb 2022 16:44:08 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <12b6fcc0-9343-63cb-53a3-bfa40c87017c@FreeBSD.org> Date: Thu, 3 Feb 2022 17:44:07 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: randomdev hangs during initial boot of -current on Raspberry Pi Content-Language: en-US To: Kyle Evans Cc: Mark Millard , Mike Karels , freebsd-current References: <3f375da9-c2a0-8c9e-33e5-d8273e84590c@FreeBSD.org> From: Jesper Schmitz Mouridsen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643906649; 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=Xj493l7DagZjddl1YThELGtjAaa9UVWLav9diLyJSyQ=; b=D+WiF5+nT5VBm/tD+MCpRDMdfdARTSQs1GS7HWr7uAOLSUbArExjYE3ReQ/nvQ2qPJZxjO BVU7plwCyILywGH3bW8s4UKja68PE+Vy00ONHGsmHbxvK082dUVaoROVcE//g9AJPcz0fU IzUJ5cINziuirCpBck9GRRMjmVoYWLTbzN7rGFLrF22wYh17JHpEC0HoP36GKN6veGqp/3 Xuz5jsMDERZxXZ2WlfVnRHjXaJ13+5RUMAezSW1x11uChUysF+7x5ZZwPvPR+4sPV0JB4d J8Qurw0xC53bFlscjXZKb2f6UNcmEYGqbn0joaVdrsTLH60Nrv9e8L79lgp9VQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643906649; a=rsa-sha256; cv=none; b=ePxqwfdn+b2pgv8tujN7kk6SoaBwEkaB40etKHN6H5fxpETJf0+F1br61tdq/B3eElmBKm IQEA/sg055NhhyQ084nfQiKtNyyt31ir/VgLcP/OfMKbHvy7Wz0DtC5cCe1ErOCKFAIM+c HSrNVxQEQ0H0OzFgyH/AqFpX3y3JJgkkV9V21+pUA60oaOPU83Pgddt3qWX3e2FuaLyoR/ jD8QCV3mHtnuQ+ZOZskLcGedPQdcneEoUzy4Hr5i9LlLYdVsfonfQuBylYDfIkeNskeFUK 5VjQ+D82FSr1vuCEoeWeePD0DaZxVvvEHn+VrgJiANl8Igh2xocFwBjxIxZWHQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 03.02.2022 02.06, Kyle Evans wrote: > On Wed, Feb 2, 2022 at 10:50 AM Kyle Evans wrote: >> On Wed, Feb 2, 2022 at 3:41 AM Jesper Schmitz Mouridsen wrote: >>> >>> >>> On 31.01.2022 22.20, Mark Millard wrote: >>>> Mike Karels wrote on >>>> Date: Mon, 31 Jan 2022 12:27:41 -0600 : >>>> >>>>> A bisect >>>>> would be rather laborious, building a modified SD card each time, >>>>> even if just testing kernel changes. Any other suggestions? >>>> Historically I've used: >>>> >>>> https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D >>>> >>>> and the likes of kernel.txz (or more) from, for example: >>>> >>>> https://artifact.ci.freebsd.org/snapshot/main/b4cc5d63b6112746598d21413c9800a43171da52/arm64/aarch64/?C=M&O=D >>>> >>>> to update just the kernel (or whatever) and rebooted. >>>> (It can help to have a somewhat older world that is >>>> left in place instead of running newer worlds on older >>>> kernels. Avoiding needing got update world as well has >>>> been helpful when testing for kernel issues.) >>>> >>>> This avoids building the kernels and allows a somewhat >>>> bisect like activity until some subrange has no >>>> arm64/aarch64 artifacts available. >>>> >>>> One can sometimes run into the dates for the sort for: >>>> >>>> https://artifact.ci.freebsd.org/snapshot/main/?C=M&O=D >>>> >>>> not matching up well with the dates on the files of >>>> interest in specific sub directoreis. (Some sort of >>>> directory update?) This can make the bisect far more >>>> difficult, given the choice to not have the directory >>>> names prefixed with text that would sort by a >>>> date/time estimate when sorted by name. (Only using >>>> the commit id/hash completely randomizes the naming.) >>>> >>>> >>>> === >>>> Mark Millard >>>> marklmi at yahoo.com >>>> >>>> >>> Hi >>> My bisect gives: >>> The latest working is: >>> dda9847275da79ccbb2f0b7079b250e28b3b3b2a >>> The excact following commit: >>> 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is bad. >>> So 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 is where the problem starts >>> for me. >>> Hope that someone can explain why >>> 74cf7cae4d2238ae6d1c949b2bbd077e1ab33634 does block entropy/random >>> seeding on first boot around growfs invocation on arm64 >>> /Jsm >>> >> That seems odd, but CC'ing jhb@ -- maybe there's something hinky going >> on since this is before AP startup for arm. > I poked jhb out-of-band and we tracked it down to callouts having been > a major source of entropy for early boot via SWI; tentative fix > pending here: https://reviews.freebsd.org/D34150 > > Thanks, > > Kyle Evans I can confirm it works on  arm64 (Pinebook Pro) Thanks! From nobody Fri Feb 4 10:07:04 2022 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 6BE2119A1075; Fri, 4 Feb 2022 10:07:07 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jqrmq241tz4n28; Fri, 4 Feb 2022 10:07:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643969227; 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=RvUIV2G4d5RBuL0ufm9EKGobpYo1ErAUk6UXTMl8JV4=; b=TIn9k7abiQY1xVhhtngoliymQ7qOiYZFP0vjBUeIxbNO0cTeCc+lorXnLWkR6GCTy7nBan xTSxegY8s4GouSDcLOUcNYBvMs9ZUTGQ6FKcuQfqlNNyejuanym8p+1jQNatb0BKZk7qwt FRk+Yd5Df6iMpbAVrL3hwLD6mGNlFHNF/dqdfPtQHrlkEPxXgtv84XX4JthA5NQlZumoOC hiCWUWP4qrCgrsISRnplM/mc5zx67CaKQ7VeR93ExUFLSO+AJmkVJ9klqM5cquMhR8I9Jo WAr9x4Ph55dQ/34HApcVgStpSSPnFhJ0jTOqtsirty3tzSKUQ0lzcOJYALkmhw== Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id ADF542F6D5; Fri, 4 Feb 2022 10:07:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <556a2f46-9dac-e0bc-10a7-d81bf7c99f5a@FreeBSD.org> Date: Fri, 4 Feb 2022 12:07:04 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.1 Content-Language: en-US To: freebsd-fs , FreeBSD Current From: Andriy Gapon Subject: rc.d/zpool should require (rw) root? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643969227; 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=RvUIV2G4d5RBuL0ufm9EKGobpYo1ErAUk6UXTMl8JV4=; b=crex5P316EbWtrsoIpcdIUB6JwesJq9Z6cxxYX3RI4YrOL9O9CAEQxbWB5AkD2zImH9BqM hC+j9pHmhawfIxrMKgLQSQIkeIU5PDtwYcfkHRqC8LgbTRwL24fCSRgOXhz5toZoL31/IL gjyux+NnojZBBJi7uD1xiLdf7yik9X5MD4lGpcffm0SCliRltdkkS3eSftd1eEUSsuhvtY qV7088GTiLnyyIbRk/ZAPHRpB/AKlYjLXYswiTOFsNSC5ma+fqqvExcxbQ3oOBXg47ti1Q eEo/bW83VGqWPm+ePR6rUjWkSLvUcOofVwWjJqeJXw0fpQVG433DpR/PAp0XdA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643969227; a=rsa-sha256; cv=none; b=DQTQzgxQtAPpI0s1fB7YGJt8iNRg4BlUGnZPgGNwUW8PG2uzA6x0lYuCuo6XKbmPvASCew ZnP8mpARrbd5qHF+QU+BBMDZU/ltNLI0B8bWZm27rNVY4tTF1sWwrg27qOK44zojLLFLze lAEq5V4eLJT1ob8YjZ7mRLYNS4ZnNXGUA5vEcg0cQXMPPfuKyz54rX7gnlIWPt6R0OmOo3 Oio1VB5TemC2TL0TZLRefqq80737nhgUA9Rkl2OTJiEV0lE/7rnTSdp9Bl9DoAsYY3xt3F 9Hncwh3TyBOd4I9Wp2ce3B3ivBteY7fLLo4NRP3AvueHZvhelvnvhTiXjwWCWw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N It seems that in some cases zpool import -c requires read/write access to the zpool.cache file. So, it probably makes sense to import "other" pools (non-root) after upgrading / to rw. What do you think? -- Andriy Gapon From nobody Fri Feb 4 11:00:39 2022 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 ADE9819A0581; Fri, 4 Feb 2022 11:00:53 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 4Jqsym5Pssz3PBN; Fri, 4 Feb 2022 11:00:48 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800:0:0:0:0:a135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 214B0eLF009183; Fri, 4 Feb 2022 12:00:40 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 27C9D770; Fri, 4 Feb 2022 12:00:40 +0100 (CET) Subject: Re: Dragonfly Mail Agent (dma) in the base system To: Ed Maste , FreeBSD Hackers Cc: FreeBSD Current References: From: Harry Schmalzbauer Organization: OmniLAN Message-ID: Date: Fri, 4 Feb 2022 12:00:39 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4Jqsym5Pssz3PBN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de X-Spamd-Result: default: False [-1.27 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.888]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[omnilan.de]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2a00:e10:2800::a135:server fail,2a00:e10:2800::a130:server fail,217.91.127.234:server fail]; NEURAL_SPAM_LONG(0.92)[0.920]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Am 28.01.2022 um 19:04 schrieb Ed Maste: > On Thu, 27 Jan 2022 at 16:34, Ed Maste wrote: >> If you have enabled DMA on >> your systems (or are willing to give it a try) and have any feedback >> or are aware of issues please follow up or submit a PR as appropriate. > Thanks everyone for the feedback so far. I think the feedback > (including some private mail) can be summarised as: > > - It works well for the intended use case. > - Documentation (FreeBSD handbook) is missing. I have submitted > https://bugs.freebsd.org/261536 to track this. > - We'd need to address queued mail in some way before it could be the > default (e.g. provide a default cron job). Just to add the probably most simple way, in use here for several years, for the same purpose others already reported (nano-monitoring-solution): cat /etc/dma/dma.conf # $FreeBSD: stable/11/libexec/dma/dmagent/dma.conf 289087 2015-10-09 22:09:44Z bapt $ SMARTHOST msa PORT 587 NULLCLIENT Working perfectly fine (forwarding all and everything; mostly ending up for root(@localhost)) and highly appreciated zero-hassle base feature! From nobody Fri Feb 4 11:19:55 2022 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 12D6319ACE74 for ; Fri, 4 Feb 2022 11:19:58 +0000 (UTC) (envelope-from theraven@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqtNs6rNrz3mfg for ; Fri, 4 Feb 2022 11:19:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643973598; 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=APmRuFwVY5IcG30aoBtUdx6SW6S8MkSpZiLBKH2VWGY=; b=AKNpVV+Bne5M7hQEorhxhS7IfB6EPB/xSywWM5819DQox/QK9FrTOYYlbzszIpWnRQHuZm yIh3muax7z5Ow5PPTPTfhCK3wpHsTNQKoRm34sqKAsoJUdMmS5EiujW07+M3if+Br7M/7D 8SHbEQSSkfgeXqYJAS53jBKEHwCsoiZZoGYRwfFr/xWnD5UlXFd5IZbehQePJmTi5kqXWv NybK10nwiA7pKg/RT4PX/DRC93qfyneimd8pRbiLMFDx5mbmZUX4lg8LBV53D3KoFXp0fB KZmhFgl2c9ERb8541EZUbm+dIpABFABTMjD7gGu+uixVKL1T/KHuhknpLeSjWA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id C21C82F966 for ; Fri, 4 Feb 2022 11:19:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id D8AA62EEF3 for ; Fri, 4 Feb 2022 11:19:56 +0000 (GMT) Message-ID: Date: Fri, 4 Feb 2022 11:19:55 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: Dragonfly Mail Agent (dma) in the base system Content-Language: en-GB To: freebsd-current@freebsd.org References: <835dc887-6491-602c-7d71-d99309871126@siemens.com> From: David Chisnall In-Reply-To: <835dc887-6491-602c-7d71-d99309871126@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643973598; 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=APmRuFwVY5IcG30aoBtUdx6SW6S8MkSpZiLBKH2VWGY=; b=kbrCw4u2P2wNETzuVdQiFYuM9OCGmwWgZhtm37iQopBBjrQAJ92UVjTquCsotfYMwZt12J Oju+WJv9iSXCFBJgESKSWn4at+3y+m85yEqKSeYzXQrtCWq2/S1oQZ7tijGOdT1o00698x cOe/1MStQNY0pgg3zo5VFM9Xd1DK2R9qptCgRRMxdgckJBHbbgDO7nERhTA+NNpaGVaAPt /7rEoQAKgOh+BztZoHsnjPePknvG5xDZ/NR12QFU+UM95+Pq1IkBYf/O7PtyOA3mduOzkd hXGftXG3v+XwQS/y+nq9t8yQClLv/PsD9/OYFgSNr+6DYiTaGcldqQE7CWEcjw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643973598; a=rsa-sha256; cv=none; b=uIARswE6LFMk8u0tP7C2FfK+jInON/CWSaf4OIJuG5cvxthDcZS/4slX8Xc8POQYIIG+1S AGIN0XIktYgrC3Oz+USXCxzoAv/sqOTeDKWQlY2PGCbSvI79eZz/CVabOTKlQeu7t71K0V cMxRJjff0X0HuenxZUfjjxYFzJBSg0rI5ZP1r1VLxhpT+Gm7/U5EFgs4OmRDfRScDhNwBf 75suJNsj+GfdVk6g0iqimHgayXqyul+FoWn4H/AZnlR8AvYaXj4/u2+IvFfO8l4xWrT++Q yIpdWwCSe1JyWXgi2HWeLg4rvLfcq8anzkeDxScQvwCXoHRTlm9d2auCaia4WQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 30/01/2022 14:01, michael.osipov@siemens.com wrote: > Sendmail: The biggest problem is that authentication strictly requires > Cyrus SASL, even for stupid ones like PLAIN/LOGIN, accourding to the > handbook you must recompile sendmail from base with Cyrus SASL from > ports to make this possible. A showstopper actually, for two reasons: > 1. I don't like mixing base and ports, it just creates a messy system. > 2. While this may work with hosts, when you have jails running off a > RELEASE in Bastille this obviously will not work. > Not going to work with sendmail easily. I think this is a critical point: at the moment, we're paying the cost of having a full-featured MTA in the base system, without getting most of the benefits. Around 2003, I hit exactly this problem. The instructions after update were slightly terrifying: after each base system or ports update, I potentially had to recompile my own sendmail. There's now a sendmail+sasl configuration in packages and so I was incredibly happy to be able to move away from using sendmail in base. Now I have two copies of sendmail on some machines. The one in ports, for compatibility reasons, looks for config in /etc/mail not under LOCALBASE, which is a layering violation and means that freebsd-update periodically tries to corrupt my config. I have no strong opinions about where we move to, but moving *from* shipping a limited sendmail in base would make me very happy. David From nobody Fri Feb 4 11:23:42 2022 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 F09E919AE72F; Fri, 4 Feb 2022 11:23:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqtTL1ppkz3p2x; Fri, 4 Feb 2022 11:23:50 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=aOo3I5b4Jxf6HQcfzufQ32ECteOFZJEIyr5+H0gjUuc=; b=IvErUPwZRpBDdAVPi/e+Ycvjdb0y5CW+ml69+OQbh1oDqYaVHXB4lRs5OKkCyDN1zOGdm9DAVHpUr9r7CYo4urL43xcmSUiKMWY2MyAqfG+4ZUP0e747X3v8nT950NrE3O6WX9Y0wcrWvAVXp79GcFoV+NBop3NVf9oA2a4kAaEjl1jitPu9DHqttzWUAAFHwGhYqm2FSc54gjTSefhzu78C2072gytB5+Dnwv9kP87TKRk1n2C7eP/Tpxrwaw/vwTiKhw/CUdgZUDKpsCNj0Ev0wgb1b2/e7rJOhCAJOMLCX6smjt0AXD5rMiFSdesV18lA1kiXdXpLII4bwi6QXg==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1nFwgo-000Il2-CO; Fri, 04 Feb 2022 13:23:42 +0200 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 15.0 \(3693.40.0.1.81\)) Subject: Re: rc.d/zpool should require (rw) root? From: Daniel Braniss In-Reply-To: <556a2f46-9dac-e0bc-10a7-d81bf7c99f5a@FreeBSD.org> Date: Fri, 4 Feb 2022 13:23:42 +0200 Cc: freebsd-fs , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <2904FD1B-456C-41A0-B097-52C0EEC711E7@cs.huji.ac.il> References: <556a2f46-9dac-e0bc-10a7-d81bf7c99f5a@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Queue-Id: 4JqtTL1ppkz3p2x X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=IvErUPwZ; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-1.98 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.88)[-0.877]; NEURAL_HAM_MEDIUM(-0.81)[-0.814]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-0.99)[-0.985]; MLMMJ_DEST(0.00)[fs,current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 4 Feb 2022, at 12:07, Andriy Gapon wrote: >=20 >=20 > It seems that in some cases zpool import -c requires read/write access = to the zpool.cache file. So, it probably makes sense to import "other" = pools (non-root) after upgrading / to rw. > What do you think? >=20 what if root is ro? i.e: diskless? danny > --=20 > Andriy Gapon >=20 From nobody Fri Feb 4 11:41:10 2022 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 9D52419B93FD; Fri, 4 Feb 2022 11:41:13 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JqtsP3XV5z3wRs; Fri, 4 Feb 2022 11:41:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643974873; 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=LFW4DI2LNPdUeC7AlQYVg9GrAMGH3IpZfRR4ATyn6PQ=; b=maTOxTTmeEs7q0NUfASeKnZTNck/qxeIiT/ssaNYjWlz0u0Q077EH4wrXuuHzZYbdheIHd Ax//CW79W8k5WJRnzPrVobsGMSGWHQ0k4sRSn6AVrL8Y7dH5Sv8pWR3rB929BkhqTG9L0M mJ3eMP2V5/K0/uSFo18Nt252svlI/6jYU80quc4Y0DrRLdobaktcj8lHIN/NxtAFVDUSkp /uRDZbWoMnpNV3KMjIKmeRdnlLeU0+kuGnjphX7NaGhfb6UdxnNIgcEK+SJcxbTR158HFs 04PMHYBYzcT8WayWh53bwLk7bbbTKoW7Z0TFFq8oJ7OFSrVr0MT/cd9u70Gdbw== Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id D9B9730568; Fri, 4 Feb 2022 11:41:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Fri, 4 Feb 2022 13:41:10 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.1 From: Andriy Gapon Subject: Re: rc.d/zpool should require (rw) root? Content-Language: en-US To: Daniel Braniss Cc: freebsd-fs , FreeBSD Current References: <556a2f46-9dac-e0bc-10a7-d81bf7c99f5a@FreeBSD.org> <2904FD1B-456C-41A0-B097-52C0EEC711E7@cs.huji.ac.il> In-Reply-To: <2904FD1B-456C-41A0-B097-52C0EEC711E7@cs.huji.ac.il> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643974873; 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=LFW4DI2LNPdUeC7AlQYVg9GrAMGH3IpZfRR4ATyn6PQ=; b=SXk75aLowLvJze0uVdzQE0u8Fc7C9lmeEGfQAmg5mP+6xjmMbE/RyIX4ofjJczj8dv/mdv 8w21XujaXeyuQeS/uKa7Slwwm45/5mGZM0w8S1foeYQW112sLKNyn0VZa62wnXAntOQsEx 6iFdw4BLQtve240CDEUVW5NThsaU7Hd+D+OI3AahrbqHTbDMP8QuaZremX9J9OKIXjmh7Z keg+4YDaJLN8ut355mXtB7uEha/mryFka8uz/BjH51CT7fk2U5acbOYbTNYXYu8azXdEiZ Zrhv5dobMvnMwVevczTcCF2cg/h1E9sPXTJecwUm4wMqeUuKbAYxderXhtzORA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643974873; a=rsa-sha256; cv=none; b=RlJ09uGu0IM6HgZWF17QxQSfat6s1rHXkK/isSPlc2+4JzEIcXc/xSelwDGFXNeS9nToGR /L/qIi0xniGlZtr9tktP4stRIngmoHYFWn2m/xzs4Ert/Bs1//1HY0PXB9NyL8zec1A5VY +gETFJGWPXMMCh26TlXtlxMNRfyR7YPDTW5zhjgcTfDOvlb8FtEQ1E1hVFXl6ffT6xAKoE tS1bm7B7ZMa0ndXBGRni+kAJLJwfKfULXAAta8PHxhqZUCOUgRUiKz45b8XtVYyRx/jEgR uVZfQxKN3AG6/6AJMKpdIpQtX7Qr4Ly+l/1BGGP4qP8XgJHpW368zmHHcdJI7A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 04/02/2022 13:23, Daniel Braniss wrote: > > >> On 4 Feb 2022, at 12:07, Andriy Gapon wrote: >> >> >> It seems that in some cases zpool import -c requires read/write access to the zpool.cache file. So, it probably makes sense to import "other" pools (non-root) after upgrading / to rw. >> What do you think? >> > > what if root is ro? i.e: diskless? Then nothing changes. rc.d/root would leave / alone. -- Andriy Gapon From nobody Sat Feb 5 01:22:15 2022 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 4226A19AACF2 for ; Sat, 5 Feb 2022 01:22:27 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JrF4y1d9qz3thp for ; Sat, 5 Feb 2022 01:22:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644024138; bh=ZdG+sOu3qAh0Pp7ZrdN9Ztc+pqJmfvHAU7k8X48oRrQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=SKhEDXmQB8Q5x/iVRy4UVJtdgnvRA2RYWYJ7bbHg3FXzOx6AcoUNikiWbgQpwxHbdA1TQOr1XqpTJex3DbjhQvZa+zhmaw/56lPTEPOWBexj7VJtK9DdHZGVgEegBDXgp+YtCyLvcoAzkl/t5+qR0ELk3feoAw5ojEGo2RwnSsI276ib0DVQ6t1xpBWSwkbTFNW2RPhWfdIe87EU0PDbfu3g+VVI6HdMujuRoS3ZmQ+E8rDEVn85YATcxOemf87XGG8bvyavvOFDHClBmZ3qotVEvNxt2obqnynw1NP9sIr+G+1TY2+mUS0cvHdnXA6d54DIu+KZjWOh/mU1wS4rUg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644024138; bh=a4G0Hk7JF+mhTQ7aMMgXhaKXKAI/MSJSxJBbVQUAUHw=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Eud04CUUPwE8UtfCmVfKs0HYqAPKLd66RKdAyVrTz01fbTA2+lkH3vjq01/pLaHs9EdpB1U+8GbXrFv8scUb7alxlWHn5CBzlascte6WEURNL1VvgH8JjAASSaC06OU0dwApyNUosGNeRkq2MlUlROh3DvsT0UsFERqkstMTpL0y/UdyxKR+1d7y1Hnc/zqKJ3i8RjuMOuqsE0jOlspDaUSSwrnD9p3y5IJkTcwbVitVgDY0SwS16nNyTu7FZIesCCNJB0VGN+nR9kCQRw1fdWB7aKirLsl0tJ+7DhxuG44dcAjaJYOYrnLnnMN7RVcAlJk2/zsZUsNYHyGv7+iN2w== X-YMail-OSG: 9AFww8cVM1lyx9OUIexbST8cPHX5WOzusWAO52TwPOBDsk0jYJutfRgolUvI.kb biDGEJwx7yRtHbHNANUm5pndApAQjQuIM3QCp8mXLB3uGyY89qA_Mad.a6NY8XFM9ZCYLwZvdI_9 lvOGKJSKLgUPjd4dNJC1Rzr5fAW38diwcmwcduy_Cx_uoLgMWhMa.Yq6r7PxaUAq.m1212JSdvpO cuh6b_uBN249DNOsCe1IFpIiqUB1Qe9KTmrP.a2_GpHRolVyREvkyctOcJvjXnc6lTx7P1WymPd4 r8G4piFy9QRF0qaKN7sZjA8IASATbVN6QglPst8h6QV7L0AMjfWKkv.xSu0Hq9DhEm09l47AjX1T U_Nb47a6hIQhZsLEcJZt6yD4m8UWxbED_0sKCpmTEtFZqXZvPNCQVKu87fQUGTmsUyT2pEXbKrYI Byp5xi7tKcU10pz.iTmXqrefuiacpAhxqCn8R5S2oa1WhJoRj8IpQ.sN5wcmGGWoNNQOMb8hGbJQ KdjUtV6na9mjGIkEIKMgxbSE3wk9CNtExOr1bX.VbCc_LRtfMRY9pjXNmmBPahuit.Yg6gBxtn1g vVdI46QHuBxT0f5Pbphc05wT7aQvNY4hiyS6mFaDDXbsDK6nYAUiESN9KJLaAw9CY5ftX8uQQyCk BoDsBQr34pBKpnvrdz_LJHhyVHVFhvVPX7SvWnLgu1Lire8OXj.D8JBHz0qxbZJih.Sj8iRfwdMS XhLBtzgIkDUvdna2MVQe3pA0fIZybcODL2xJDrDd9_0jpqhkMo.bH2GqVJmzfXX95XKloHQ8VUmU C65Q.iDq4gvtppFovMg0ZOOuIQ3MQ4wQSF.wg2pabVQir0Tk58zIQiQVpsnNUsNayiK1n5LjteLJ AiYDF4zJ3kaFgrvlL0jUuIOzfraK69GtoOMYH.u2ngX5OVKzzhY22nueJi5DN_i1QmAfhmtk9c06 QYvvrTyKrts6fuxa2StLYGmMYrAV6ITbGIaA0cL9rVXaPiU6Xbdf4QxOGnfQJ1bHkx7TXFjaseYO _7DZdhzW2yKXc2miOBFMvyB6VOvfqmkYm6WQfCxEpdwKPb_We_xIQop.qbEHF73P0g_8o4znWNlg Nx56aIPQrySmtcgkcJMRaloafJjUyVLGGQqp5sQen1lw6AKNZN93XCHrE5XdRGoaJQ06vJBo39Ir H7ufghkHuP_4JP367kKEjCYfqFolxxdfNm6GDB8wLcVTGm1Fj8DKf7fMNnRu_X74ytG6GhGnd0Wl CMTO30xlQN52SZcCYXN9.JJgD2USqlqH8ng.YjBDseboqrVulSBJHG7JEbR.BNaxDSIh_PK3lj4S 7xCf_R0w081L8JADNC0IKDS6awyU0HqXDCmVLQM4nTMmfjuePrMj1A7r6LSVmZ4yBsD4GBOVsKPu ulfbgMr9U.xrvP6tx2tpeG_PmyMASNMMgXZErIfDteJEMh5O97TLNlyEj7b5FYcG4vbaSWrbjbvJ cOXoZBla6xGUSKDd_vpR2s1AcaEBx78.gv5mgGkhrYegSGzPdXoMbp7T_oWaQtBcgQES9xrURICa WP14Xb_XfF3sgiOBhWHJpaSCEKj8oCqbnMAX_fnzQDxZiizT0wVWV.IGzq6QAhbfyRpAzeR7eM.u eulO5LPmQ0.rqvVLVmIYB2c76_5tLV9fxZnBUAs2ptXRx_rXjKyIqhKwl27uCgunm2Z0dRcoWhp8 GhPROScZRhw47STa18DrRno8EZikx6QhaPVxqF6Xrhbhfg4ym0agnRHhe0ZC.U9xhd8VGtDTUfi2 FR4WGdshcdoAVAk0WF4sklXQfLZBHuGpyb1k9uDN9F17x56bgByoFoL.Jh1hew8aL.uEvABuoEG1 SIVr8BgaTaG9dkGVrbXBVunBI14Bo9o0jiGSfCcJnShg3WCE92SXDm7ufuPQGlzdquC_kSKzEa0h zl0qFk7wlQ8zhUSroGWGXg2w.h4Ck52hp0Q8sGWgUD8Cu.9Pi2Er3ucJDbdJWqW5BCfjTYyUZ1KK SBoDdzW4nmRIywysLZtRIEf2qF5aPRJOWCk7hxGlkWyjITAXP.kptu4xJwQFpN8lyo3fIcjaJXUT iI4DlJzwzKFQl7sGG1yPhcPZDjQIyCsf1YDu0T1_wji5LwFcXtoXpgvrVtZkQwfX19M.AdHH.O47 iGUcrsmB.G4cph9TMLteMEYnN0DiDaucMonC86jTroXEE.8.z54IruS00JZuLy2H_bR55UsU0b50 Tvp8laSD4tXN3ksloMjDcMM_E_GkDfhHWHmYPlYv3nU1ObouO7AsGB.LbA7OlHYYX8xA7FQvf X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Feb 2022 01:22:18 +0000 Received: by kubenode534.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 07542f611f4db448d383bae671554774; Sat, 05 Feb 2022 01:22:16 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: man elfctl vs. elfctl -l : man has +aslr example but elfctl -l lists onlt naslr style for ASLR control Message-Id: Date: Fri, 4 Feb 2022 17:22:15 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4JrF4y1d9qz3thp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=SKhEDXmQ; 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 X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N EXAMPLES The following is an example of a typical usage of the elfctl command: elfctl file elfctl -e +aslr file vs.: # elfctl -l Known features are: noaslr Disable ASLR noprotmax Disable implicit PROT_MAX nostackgap Disable stack gap wxneeded Requires W+X mappings la48 amd64: Limit user VA to 48bit noaslrstkgap Disable ASLR stack gap === Mark Millard marklmi at yahoo.com From nobody Sat Feb 5 02:06:16 2022 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 5B0C1198DD33 for ; Sat, 5 Feb 2022 02:06:35 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JrG3t4m45z4kFL for ; Sat, 5 Feb 2022 02:06:34 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f182.google.com with SMTP id o10so6422269ilh.0 for ; Fri, 04 Feb 2022 18:06:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LnaSBVPd2qI4kfQMqr68s7eKMiTuuu4cV5bVEDugFGY=; b=hNu6JQLzohNm1jBsOC61HIX2vz2HsSTm+ZS5sdIyrE2+vI2WSlI2B1O9h1tRyv6DqS m3m96wTZEpP2+K5DN7aKT8g/GaVUpLSrRMeFr+FrK4/2axHcWNpzekWa5BJpIpBz9+FX 0Yi6EC2XmsRb+RbG3KxH4C6dr2HQWXj063GkxK7sheGju+VFLz/mNBqj5uURWtNCnyfH 4gWFiymvLt4A9iKsEmcdTxQAmoCheLjMie8BEnOJ8w4dBuq6uTRD/wiWEuwfo8kzI3wO lXjNOrOJlvI3Pt2BVy4ZWxYS92m8UBo+dtDDgSjf4C+3YbqEozesxfxbFOurJfayR2eA t3GQ== X-Gm-Message-State: AOAM531qqx7umcSkI5+7jeJJttE0H/q7/FCt5A3LGJbAngek4PGs6CA4 5tPQDuaSBBxwxOEj0laYYJ2ujIABqSqEvDT6xes= X-Google-Smtp-Source: ABdhPJzAV5Fu0B8QJuZZlEp7gpBkwDWGZUWToOfVdNNjXn1LV1XRAeA3Fh4t/qm6pixwLXwTJxkX5lzqzlYXluudlq8= X-Received: by 2002:a05:6e02:160b:: with SMTP id t11mr998796ilu.75.1644026788095; Fri, 04 Feb 2022 18:06:28 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Fri, 4 Feb 2022 21:06:16 -0500 Message-ID: Subject: Re: man elfctl vs. elfctl -l : man has +aslr example but elfctl -l lists onlt naslr style for ASLR control To: Mark Millard Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JrG3t4m45z4kFL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.182 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.89)[-0.886]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.182:from]; NEURAL_SPAM_LONG(0.79)[0.787]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.182:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 4 Feb 2022 at 20:24, Mark Millard wrote: > > EXAMPLES > The following is an example of a typical usage of the elfctl command: > > elfctl file > elfctl -e +aslr file Fixed in dbc7364b1840ef3f36994952d085add5d161775d From nobody Sat Feb 5 12:01:45 2022 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 0205E19B6827 for ; Sat, 5 Feb 2022 12:01:50 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JrWGj6kjbz4RXg; Sat, 5 Feb 2022 12:01:49 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644062509; 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=tJKhCD2/z9GOpAlrIL72te3Mr2gUUgoGoJbiB718Qbw=; b=DjG34CM9/7P5LVD8mm66qzGKRL1YAZsfvhSAG93zIbzNCEo55wXoj2dnkhkXVKnhtRytJG AA9bRTrbkBiE7urz3UYope0OT+SnFuUu2j1WtIaJqTYzG7TvZuUffbJtlCAaXTySbM4SYt +KmbQZ2f8mD/N4c2pu2czMFyFQZT32cEShpwYoFgO7xx2vKYcX/SM/afWRTzthTmwHsFfk 19dLLKSznCUx40QbkRssjZWAfcjPL6dggS4PWg6B8KK2NJNUgWlHf7NPKbxkLJGSRUtg31 Ev/fjIlExR6UQ63Tz/PVFjnxDxT+SHq9DND2ActWmNQeylOgtI7QjOs9tYucwA== Received: from [IPV6:2003:cd:5f0c:9800:ecf1:9d04:7fdb:712d] (p200300cd5f0c9800ecf19d047fdb712d.dip0.t-ipconnect.de [IPv6:2003:cd:5f0c:9800:ecf1:9d04:7fdb:712d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 7AEB3445E; Sat, 5 Feb 2022 12:01:49 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <28a65581-bb25-9f60-5b15-ef4fd4a15ec9@FreeBSD.org> Date: Sat, 5 Feb 2022 13:01:45 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US From: Stefan Esser To: FreeBSD CURRENT Subject: [REVIEW] Fix of sysctlbyname() accesses to user sub-tree variables Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644062509; 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=tJKhCD2/z9GOpAlrIL72te3Mr2gUUgoGoJbiB718Qbw=; b=h1WWoHhUrIL1x85fzHH3BoYHld0TWlaZ7W6ktNGqzlh/i2jfjVD1jumO6YP66By92xCCrW JKulxwJ9/ksOuZggsvEpejq+EDXZ3QwAxjtZpJ8SJpX8xJgV5x0fnXX4mhXAM0KcN4PyUV t3oMzqsFRS+RJNNu3a7e6fvvCr9VwB68qxsMlaeOAddlNzIDAummNjRTHZQptySEy6D9CJ O/px8Ro+FUsnJ+yBhfvweQLCk1mqHToTFaPFAGIrsniWBtA/ePwqe3RudjL09H4FCngROK C1CmaRyKhyF2wpJ28WK2MKTY0mkeSUcNdFhkPHte3PKzCl/4/tZkWjoVg+EjLQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644062509; a=rsa-sha256; cv=none; b=CSWENLOaF7C3K1UnCcdHR8XfeMJucveMNqhMmskOslIW2MZ8Ie5mgKcZehCwrKwpa5zaTb ToF4sL46YKdmXlJTuPDGABODV6Fp3KRPIDR+bsx/2PcjgUqkCZ1b9EsdZVNRhAQ0MDN8Yu gmYExceOtmVNrn3UlhWmpcGDgSvflGq+0lwQYE+EJHV9nvf7oVk7l2HQopKQ3/Idlv/vUE 9H8cPlHYuitdWOzP1FZQaCH+vKq/wzv+JsyGQQzAQ8MgqK3fmn8qGEcXzWOanMkXpYWGyw +gO5NghbyNxhdja8qaep+he7UWS3csuJdJI2tbhwaSyQVTVg23acCrpLNZtHLA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N I have created https://reviews.freebsd.org/D34171 for a patch that restores the lost support for accesses to the user sub-tree in sysctlbyname(). E.g. sysctlbyname("user.cs_path", ...) returns 0 to indicate no error, but only an empty string, since the actual result string is to be provided by the user-land code in the C library. This functionality exists in sysctl(), which used to be called by sysctlbyname(), but after an optimization that reduces the number of system calls required, sysctl() is not longer called and thus the empty result obtained from the kernel is returned. (The system call is only used to check access rights, and a non-zero return value would be returned to the caller, but the actual value of the result string is not known to the kernel.) One user land application affected by this issue is "whereis" (just fixed in -CURRENT, MFC to -STABLE planned). But more out of tree users of sysctlbyname() may exist that try to to access user sub-tree variables, and thus this function should be fixed to return the same results as sysctl() in all cases, as it did before the optimization was implemented. The code in the review special cases accesses to "user.*" and uses sysctl() to fill in the actual value, but keeps the faster direct system call for the variables actually maintained in the kernel. It is simplified relative to the "old" implementation to account for the implicit assumption that user.* names may only have 2 elements in the OID array. (Codified in sysctl() and would cause error returns if that assumption was violated.) I'd appreciate a review and an approval of the change. Regards, STefan From nobody Sat Feb 5 14:13:00 2022 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 8A72E19B57A7 for ; Sat, 5 Feb 2022 14:13:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JrZB86MTRz3ljn; Sat, 5 Feb 2022 14:13:04 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id GJVxntrrC5Rf1GLoGnXh9k; Sat, 05 Feb 2022 14:13:04 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id GLoEnXBcVa4s1GLoFn4Ddf; Sat, 05 Feb 2022 14:13:04 +0000 X-Authority-Analysis: v=2.4 cv=S9vKfagP c=1 sm=1 tr=0 ts=61fe85f0 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=oGFeUVbbRNcA:10 a=6I5d2MoRAAAA:8 a=a_U1oVfrAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=zzDZMH1rJaIYcIVx9r0A:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=ILgoY2Ve9XsnFM_ECIJt:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 0F62E538; Sat, 5 Feb 2022 06:13:01 -0800 (PST) Received: from slippy (localhost [IPv6:::1]) by slippy.cwsent.com (Postfix) with ESMTP id C19D2149; Sat, 5 Feb 2022 06:13:00 -0800 (PST) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: David Chisnall cc: freebsd-current@freebsd.org Subject: Re: Dragonfly Mail Agent (dma) in the base system In-reply-to: References: <835dc887-6491-602c-7d71-d99309871126@siemens.com> Comments: In-reply-to David Chisnall message dated "Fri, 04 Feb 2022 11:19:55 +0000." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Feb 2022 06:13:00 -0800 Message-Id: <20220205141300.C19D2149@slippy.cwsent.com> X-CMAE-Envelope: MS4xfG/9rJE1g5TtNOJGmELpZtLGPO0mgkM/4WMvrErs62gopgruinqqqu4hvN7pIBtA4EkN5s9n13Z4VHuc3baE0EBpX7CEtAfqcH+4jZzylWQm6GADG1I8 hywI4mf40hfjiM6r3M6+Ll81kykka4FdB2OnT6e+nGqzbzWRbapIADiuY9FVOAvjCq9dF2b2H8hsnlw/9o/dNoQGHCSqWtCSR5qneIBMpXnouFkf3dkC+hEP uZpy7voz/NJaF6ptaKMR/A== X-Rspamd-Queue-Id: 4JrZB86MTRz3ljn X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [0.64 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; RWL_MAILSPIKE_GOOD(0.00)[3.97.99.32:from]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[70.66.148.124:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.52)[-0.518]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.981]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.94)[0.936]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record] X-ThisMailContainsUnwantedMimeParts: N In message , David Chisnall w rites: > On 30/01/2022 14:01, michael.osipov@siemens.com wrote: > > Sendmail: The biggest problem is that authentication strictly requires > > Cyrus SASL, even for stupid ones like PLAIN/LOGIN, accourding to the > > handbook you must recompile sendmail from base with Cyrus SASL from > > ports to make this possible. A showstopper actually, for two reasons: > > 1. I don't like mixing base and ports, it just creates a messy system. > > 2. While this may work with hosts, when you have jails running off a > > RELEASE in Bastille this obviously will not work. > > Not going to work with sendmail easily. > > I think this is a critical point: at the moment, we're paying the cost > of having a full-featured MTA in the base system, without getting most > of the benefits. Around 2003, I hit exactly this problem. The > instructions after update were slightly terrifying: after each base > system or ports update, I potentially had to recompile my own sendmail. > > There's now a sendmail+sasl configuration in packages and so I was > incredibly happy to be able to move away from using sendmail in base. > Now I have two copies of sendmail on some machines. The one in ports, > for compatibility reasons, looks for config in /etc/mail not under > LOCALBASE, which is a layering violation and means that freebsd-update > periodically tries to corrupt my config. > > I have no strong opinions about where we move to, but moving *from* > shipping a limited sendmail in base would make me very happy. I'd like to add, proceed cautiously. I've been running postfix on my external gateway for a couple of decades but recently migrated all but one of my internal machines from sendmail to postfix. There were a couple of hiccups along the way. In one case there was a mail loop of at(1) jobs which required the tweak of a procmail rule. In the second case nmh submits mail to localhost:587 requiring altering master.cf. nmh uses only that port though it can pipe directly to the sendmail binary when built that way. If dma doesn't support SMTP submission, we may need to review various port default options or whether ports even support it. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From nobody Sat Feb 5 15:08:17 2022 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 353AC19B4FD2 for ; Sat, 5 Feb 2022 15:08:47 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 4JrbQQ1wymz4bP2 for ; Sat, 5 Feb 2022 15:08:45 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1C12E5C0106 for ; Sat, 5 Feb 2022 10:08:39 -0500 (EST) Received: from imap44 ([10.202.2.94]) by compute4.internal (MEProxy); Sat, 05 Feb 2022 10:08:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=S5NTRTjOaPBwtctos6eSCrR3MFNiyp+3eYgPeS Lrsug=; b=D3ArjYx5QNRma2lWVJ1h4P0iU23n4X0GtjjlkUAi2LBBz51ZSwwUrc ab65oJftGOaCsnaJBrWcoZmbDnE9/50BUfHMZNR5Lbe8NGwCPlpQ/QlJA2pWrRak bqwkAz55oc8OG8eIuEghxsPB8UWUCIgUBjc7EFff5Ixbbdliwfrj3mPqFjg+LPyD tjGkfxHdVVVszqDZeTdQMvhY7rulTHqpKQP1fW9jNjrgh8txvdRynsnNWYh9tmxY EW2gpvCpdc2zxPu3qDiO+NMkRBGm/bPAu4DorDqrZzrRGPzidmoXYxBWzYicXkEM tkJDPfm3plJQV6W5Q5cHVhDznRg2jVuw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=S5NTRTjOaPBwtctos 6eSCrR3MFNiyp+3eYgPeSLrsug=; b=JcNEcR3w4yLiwPKA1inSb1LqSt9D0mDpV 7i5JcvzfmW2fGSs1oQZ/P/oD0Hrvd3FF+rFXkBKoVnwPOe8hJLHBWejtEncoAnqq LIg0Fc68qYlkH9uGMAUhlr+Ogp7ec0RSI+MBieBqVCdSzqBG0hvk9TYoCEVUFgdj HdE/y3X8Dr8BWOnTqglQpN0NbkUXLU/dxsZkfRFoQngNYuQOQDknH8ztW9BQtoyW pDHNYnMdLhbtVyMJW46jEL0w5drgb/wE+TgI5QmZc8tX1or4WSM/Tn4K+Bf5cde3 ytJqW0tauZksBesv0XvQkOFs5A2lTCYMYU/QhryepRriE1EEDYU0g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrhedugdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdffrghvvgcuvehothhtlhgvhhhusggvrhdfuceouggthhes shhkuhhnkhifvghrkhhsrdgrtheqnecuggftrfgrthhtvghrnhepkefffedvfeetkeffge fgffdvfeeugfeuhffhhfdufedvtefgieelueejffehvdejnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepuggthhesshhkuhhnkhifvghrkhhsrd grth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D34D2FA0AA6; Sat, 5 Feb 2022 10:08:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4745-gf9b5b8e72a-fm-cal2020-20220203.002-gf9b5b8e7 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 Message-Id: <9cc08cf1-b175-4f32-9731-42bb7686ce5b@www.fastmail.com> In-Reply-To: References: Date: Sat, 05 Feb 2022 15:08:17 +0000 From: "Dave Cottlehuber" To: freebsd-current Subject: Re: Dragonfly Mail Agent (dma) in the base system Content-Type: text/plain X-Rspamd-Queue-Id: 4JrbQQ1wymz4bP2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm1 header.b=D3ArjYx5; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=JcNEcR3w; dmarc=none; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 66.111.4.25 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-2.36 / 15.00]; XM_UA_NO_VERSION(0.01)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm1,messagingengine.com:s=fm2]; FREEFALL_USER(0.00)[dch]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[skunkwerks.at]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_SPAM_SHORT(0.23)[0.225]; MLMMJ_DEST(0.00)[freebsd-current]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 27 Jan 2022, at 21:34, Ed Maste wrote: > The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) > which accepts mail from a local Mail User Agent (MUA) and delivers it > locally or to a smarthost for delivery. dma does not accept inbound > mail (i.e., it does not listen on port 25) and is not intended to > provide the same functionality as a full MTA like postfix or sendmail. > It is intended for use cases such as delivering cron(8) mail. > > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. Yes please. I've used both the one in base, and also from ports, for many years, on both hobby / home desktops, and also in production. The base one has occasionally gotten wedged, and backed up processes from periodic. I don't recall seeing this with the one from ports, nor do I recall seeing it recently in the last year. If I get a repeat, I'll add a PR rather than this anecdotal info. A+ Dave From nobody Sun Feb 6 00:19:59 2022 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 AD1F1198B51E for ; Sun, 6 Feb 2022 00:20:35 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from us-smtp-delivery-197.mimecast.com (us-smtp-delivery-197.mimecast.com [170.10.129.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mimecast.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jrqg65vMJz3Cyb for ; Sun, 6 Feb 2022 00:20:34 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from MAIL-DR.pai.local (175.158.26.216.gopai.com [216.26.158.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-159-4aofyL_3OmGeJM-8sLyLyw-1; Sat, 05 Feb 2022 19:20:25 -0500 X-MC-Unique: 4aofyL_3OmGeJM-8sLyLyw-1 Received: from MAIL-HUB.pai.local (10.10.0.250) by MAIL-DR.pai.local (10.10.0.251) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Sat, 5 Feb 2022 19:19:59 -0500 Received: from MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8]) by MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8%15]) with mapi id 15.00.1497.026; Sat, 5 Feb 2022 19:20:00 -0500 From: Michael Jung To: freebsd-current Subject: pciconf -lbvV crashes kernel main-8d72c409c Thread-Topic: pciconf -lbvV crashes kernel main-8d72c409c Thread-Index: Adga70Yty6CDct7/TtO0ME3wzl/IcA== Date: Sun, 6 Feb 2022 00:19:59 +0000 Message-ID: <4156999090d9414a90ce4c40aec4bbdb@MAIL-HUB.pai.local> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.0.59] x-c2processedorg: 474f336e-f930-49ec-9717-e3226b5b6e6e 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-Mimecast-Spam-Score: 0 X-Mimecast-Originator: paymentallianceintl.com Content-Type: multipart/alternative; boundary="MCBoundary=_12202051920260821" X-Rspamd-Queue-Id: 4Jrqg65vMJz3Cyb X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=paymentallianceintl.com; spf=pass (mx1.freebsd.org: domain of mikej@paymentallianceintl.com designates 170.10.129.197 as permitted sender) smtp.mailfrom=mikej@paymentallianceintl.com X-Spamd-Result: default: False [1.54 / 15.00]; ARC_NA(0.00)[]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:170.10.129.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.92)[0.916]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[paymentallianceintl.com,none]; NEURAL_HAM_SHORT(-0.42)[-0.420]; RCVD_IN_DNSWL_LOW(-0.10)[170.10.129.197:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_SPAM_LONG(0.85)[0.845]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:30031, ipnet:170.10.128.0/23, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[170.10.129.197:from] X-ThisMailContainsUnwantedMimeParts: N --MCBoundary=_12202051920260821 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 RHVtcCBoZWFkZXIgZnJvbSBkZXZpY2U6IC9kZXYvYWRhMHAyDQogIEFyY2hpdGVjdHVyZTogYW1k NjQNCiAgQXJjaGl0ZWN0dXJlIFZlcnNpb246IDINCiAgRHVtcCBMZW5ndGg6IDkwMDIzMTE2OA0K ICBCbG9ja3NpemU6IDUxMg0KICBDb21wcmVzc2lvbjogbm9uZQ0KICBEdW1wdGltZTogMjAyMi0w Mi0wNCAxNTo0ODowOCAtMDUwMA0KICBIb3N0bmFtZTogZHJhaWQubWlrZWouY29tDQogIE1hZ2lj OiBGcmVlQlNEIEtlcm5lbCBEdW1wDQogIFZlcnNpb24gU3RyaW5nOiBGcmVlQlNEIDE0LjAtQ1VS UkVOVCAjMSBtYWluLThkNzJjNDA5YzogVGh1IEZlYiAzIDE4OjE0OjAxIEVTVCAyMDIyDQptaWtl akBkcmFpZDovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3N5cy9HRU5FUklDDQogIFBhbmlj IFN0cmluZzogbGVuZ3RoIG1pc21hdGNoDQogIER1bXAgUGFyaXR5OiAxNjkyOTgyNTkzDQogIEJv dW5kczogMg0KICBEdW1wIFN0YXR1czogZ29vZA0KDQpodHRwOi8vbWFpbC5taWtlai5jb20vaW5m by4yDQoNCmh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9jb3JlLnR4dC4yDQoNCmh0dHA6Ly9tYWlsLm1p a2VqLmNvbS92bWNvcmUuMg0KDQpUaGlzIGlzIGEgdGVzdCBzeXN0ZW0sIG5vdGhpbmcgb2YgdmFs dWUgaXMgc3RvcmUgaW4gdGhlc2UgZmlsZXMuDQoNCg0KDQpDT05GSURFTlRJQUxJVFkgTk9URTog VGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2UNCm9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5DQpjb250YWluIGlu Zm9ybWF0aW9uIHRoYXQgaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBhbmQNCmV4ZW1wdCBm cm9tIGRpc2Nsb3N1cmUgdW5kZXIgYXBwbGljYWJsZSBsYXcuIElmIHRoZSByZWFkZXINCm9mIHRo aXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkN Cm5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5n DQpvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhh dmUNCnJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVz IGJ5DQp0ZWxlcGhvbmUgYXQgKDUwMikgMjEyLTQwMDAgb3Igbm90aWZ5IHVzIGF0IFBBSSwgRGVw dC4gOTksDQoyMTAxIEhpZ2ggV2lja2hhbSBQbGFjZSwgU3VpdGUgMTAxLCBMb3Vpc3ZpbGxlLCBL WSA0MDI0NQ0KDQpEaXNjbGFpbWVyDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBjb21tdW5pY2F0aW9uIGZyb20gdGhlIHNlbmRlciBpcyBjb25maWRlbnRpYWwuIEl0IGlzIGlu dGVuZGVkIHNvbGVseSBmb3IgdXNlIGJ5IHRoZSByZWNpcGllbnQgYW5kIG90aGVycyBhdXRob3Jp emVkIHRvIHJlY2VpdmUgaXQuIElmIHlvdSBhcmUgbm90IHRoZSByZWNpcGllbnQsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlv biBvciB0YWtpbmcgYWN0aW9uIGluIHJlbGF0aW9uIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGlu Zm9ybWF0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg0K VGhpcyBlbWFpbCBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBtYWx3YXJlLCBhbmQg bWF5IGhhdmUgYmVlbiBhdXRvbWF0aWNhbGx5IGFyY2hpdmVkIGJ5IE1pbWVjYXN0LCBhIGxlYWRl ciBpbiBlbWFpbCBzZWN1cml0eSBhbmQgY3liZXIgcmVzaWxpZW5jZS4gTWltZWNhc3QgaW50ZWdy YXRlcyBlbWFpbCBkZWZlbnNlcyB3aXRoIGJyYW5kIHByb3RlY3Rpb24sIHNlY3VyaXR5IGF3YXJl bmVzcyB0cmFpbmluZywgd2ViIHNlY3VyaXR5LCBjb21wbGlhbmNlIGFuZCBvdGhlciBlc3NlbnRp YWwgY2FwYWJpbGl0aWVzLiBNaW1lY2FzdCBoZWxwcyBwcm90ZWN0IGxhcmdlIGFuZCBzbWFsbCBv cmdhbml6YXRpb25zIGZyb20gbWFsaWNpb3VzIGFjdGl2aXR5LCBodW1hbiBlcnJvciBhbmQgdGVj aG5vbG9neSBmYWlsdXJlOyBhbmQgdG8gbGVhZCB0aGUgbW92ZW1lbnQgdG93YXJkIGJ1aWxkaW5n IGEgbW9yZSByZXNpbGllbnQgd29ybGQuIFRvIGZpbmQgb3V0IG1vcmUsIHZpc2l0IG91ciB3ZWJz aXRlLg0K --MCBoundary=_12202051920260821 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Dump header from device: /dev/ada0p2
Architecture: amd64
Architecture Version: 2
Dump Length: 900231168
Blocksize: 512
Compression: none
Dumptime: 2022-02-04 15:48:08 -0500
Hostname: draid.mikej.com
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 14.0-CURRENT #1 main-8d72c409c: Thu Feb 3 18:14:0= 1 EST 2022
mikej@draid:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
Panic String: length mismatch
Dump Parity: 1692982593
Bounds: 2
Dump Status: good

http://mail.mike= j.com/info.2

http://mail.= mikej.com/core.txt.2

http://mail.mi= kej.com/vmcore.2

This is a test system, nothing of value is store in these files.



CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245


<= b>Disclaimer

The information contained in this communication from the sender i= s confidential. It is intended solely for use by the recipient and others a= uthorized to receive it. If you are not the recipient, you are hereby notif= ied that any disclosure, copying, distribution or taking action in relation= of the contents of this information is strictly prohibited and may be unla= wful.

This email has been scanned for viruses and malware, and may h= ave been automatically archived by Mimecast, a leader in email security and= cyber resilience. Mimecast integrates email defenses with brand protection= , security awareness training, web security, compliance and other essential= capabilities. Mimecast helps protect large and small organizations from ma= licious activity, human error and technology failure; and to lead the movem= ent toward building a more resilient world. To find out more, visit our web= site.

--MCBoundary=_12202051920260821-- From nobody Sun Feb 6 00:50:15 2022 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 553C819AEDBA for ; Sun, 6 Feb 2022 00:50:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JrrKV2lMqz3R6Y for ; Sun, 6 Feb 2022 00:50:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 2160oFI6000148; Sun, 6 Feb 2022 00:50:15 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 2160oF7N000147; Sat, 5 Feb 2022 16:50:15 -0800 (PST) (envelope-from david) Date: Sat, 5 Feb 2022 16:50:15 -0800 From: David Wolfskill To: Michael Jung Cc: freebsd-current Subject: Re: pciconf -lbvV crashes kernel main-8d72c409c Message-ID: Mail-Followup-To: David Wolfskill , Michael Jung , freebsd-current References: <4156999090d9414a90ce4c40aec4bbdb@MAIL-HUB.pai.local> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7gRxq3vRkCcgv0p3" Content-Disposition: inline In-Reply-To: <4156999090d9414a90ce4c40aec4bbdb@MAIL-HUB.pai.local> X-Rspamd-Queue-Id: 4JrrKV2lMqz3R6Y X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-3.03 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; NEURAL_HAM_LONG(-0.63)[-0.629]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[catwhisker.org]; NEURAL_SPAM_MEDIUM(0.97)[0.974]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.972]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --7gRxq3vRkCcgv0p3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 06, 2022 at 12:19:59AM +0000, Michael Jung wrote: > Dump header from device: /dev/ada0p2 > Architecture: amd64 > Architecture Version: 2 > .... As a reality check, I just tried the "pciconf -lbvV" command on my newer laptop, which was running: FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #84 main-n25= 2957-34478b73bf18: Sat Feb 5 05:22:21 PST 2022 root@g1-48.catwhisker.o= rg:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400051 1400051 (thus, a bit more recent than the main-n252894-8d72c409cd85 you tested); it completed without issue. I then fired up a newer build machine and tried the command, again without problems. It was running: FreeBSD freetest.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-= n252957-34478b73bf1: Sat Feb 5 04:04:51 PST 2022 root@freetest.catwhis= ker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1400051 14000= 51 For what it's worth. Peace, david --=20 David H. Wolfskill david@catwhisker.org "No person shall ... hold any office ... who, having previously taken an oath ... to support the Constitution of the United States, shall have engaged in insurrection or rebellion against the same...." [14th amendment] See https://www.catwhisker.org/~david/publickey.gpg for my public key. --7gRxq3vRkCcgv0p3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYf8bR18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix 1G4fAP41R3kZeZgvbFVaOorS7Ubj7RL1fBqgHqrA/0grSIr82AD/WyCW0GX7+hsr LY6d0RgdPKGTsB28XvCBIccnUt0hKwY= =7NjD -----END PGP SIGNATURE----- --7gRxq3vRkCcgv0p3-- From nobody Sun Feb 6 11:03:07 2022 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 326B019A3343 for ; Sun, 6 Feb 2022 11:03:11 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Js5wb0sVwz4dyg; Sun, 6 Feb 2022 11:03:11 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644145391; 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=7OIAH4cgth0VajG8LpeqbiSTHCgL0cyJTlU8OqdEQeM=; b=LLPLf+w92zm3SJIxVouIoveR1w2jjm2aWUn7LEevXjWgs3xFQX+oqRb6feJjsHatr8CvqF Or4IaGBkRQO3h357KNM8HOzsW4YR3fTBgqX2oKit5v5/FEOQGAra0yZH9HkFHXpIGlz22+ uRgGkrAB1IvTiRMrVBxgMZMBOcpTvzsNKNzoe0FaU3HU3IVTl48vxNTFPHhKrZJ9OWpbz9 013ahRhkkwhvXn3qTPMEJDUHd6df1dGNpbOh7pMsSH1zG1Gb8QCGqAEgYhLM9hNNxT/ChS sfoRKFXkOB5EJuNZ4bXXOhvUjKcZOCoG7v9W91PvDX9iFsK/Kw3G7LpyktdW5w== Received: from [IPV6:2003:cd:5f0c:9800:a9af:d58a:b071:caf4] (p200300cd5f0c9800a9afd58ab071caf4.dip0.t-ipconnect.de [IPv6:2003:cd:5f0c:9800:a9af:d58a:b071:caf4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 8FCEBF99D; Sun, 6 Feb 2022 11:03:10 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <016bb393-9f4a-cefa-858f-aef7ce41e640@FreeBSD.org> Date: Sun, 6 Feb 2022 12:03:07 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: pciconf -lbvV crashes kernel main-8d72c409c Content-Language: en-US To: Michael Jung References: <4156999090d9414a90ce4c40aec4bbdb@MAIL-HUB.pai.local> From: Stefan Esser Cc: freebsd-current In-Reply-To: <4156999090d9414a90ce4c40aec4bbdb@MAIL-HUB.pai.local> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ofK5ce99cbe2nKle3Bm9SEq6" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644145391; 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=7OIAH4cgth0VajG8LpeqbiSTHCgL0cyJTlU8OqdEQeM=; b=Ffyy/DgpE/MOH46agA1iXBPrv5y/d8fUFAJt+FGinorwdthZXm1ij/l9h8z8TAqyr+i56W RsRRtwAUgsWG0xzyhBNuRhRNO3DcgyYWedvoy+y0op2tldDmq+1gQxhiWks4yTS6rDothi 3VlKGo8e2RNHQq0+iykR7Q0PlyU7gRoP/McysXEgp8kKihGmdHXMe07+f3/k/eLoj64fjO iLerkD8heoyM/o2wfbGC7nLTOT/2I07u2b5szb4jjbRwyZiTH2QEKsxTX0AzZQYBiYHC+x V3LyVAsdkmPxxMywnqu7r/hpmB2fe2iQf7MTyjGRYBbwqUrez/P5MN1lpiyM0w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644145391; a=rsa-sha256; cv=none; b=a+zBnn2+2SQ8EvB7FwVgEAuB+KmZnO0bGLym7oeOHLXVZAouFG9mNOr/fzE/57R+oSHClH 1vxQtQwAk+f31rs5em37pIhUtfBSZjObYRzud6ARpUvckTHzpImDtramCBUVmYoioVs5pf ou+bn3jBunY50EmZyA+YOevBGqvMCdUtjsiYxIKprC8Kvg01Ioq+t+xeh1TUQ/riBSE7GY AmG3HxnPTkNG9wkemz1s3V7CL334C1KsrdptWIV/eeZIcz+CWzpbOCATQoKITvlnivwKj9 VWgiTc53rKbsF9/D3xW90iEsnPpzYaDcBBkl4X/zb2RNaBf19guZZFdIbcJocg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ofK5ce99cbe2nKle3Bm9SEq6 Content-Type: multipart/mixed; boundary="------------EpAH2XZhPiiWbbYUDyouNveM"; protected-headers="v1" From: Stefan Esser To: Michael Jung Cc: freebsd-current Message-ID: <016bb393-9f4a-cefa-858f-aef7ce41e640@FreeBSD.org> Subject: Re: pciconf -lbvV crashes kernel main-8d72c409c References: <4156999090d9414a90ce4c40aec4bbdb@MAIL-HUB.pai.local> In-Reply-To: <4156999090d9414a90ce4c40aec4bbdb@MAIL-HUB.pai.local> --------------EpAH2XZhPiiWbbYUDyouNveM Content-Type: multipart/mixed; boundary="------------4l5O0uW3zUcOq38cVYbzEyob" --------------4l5O0uW3zUcOq38cVYbzEyob Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 06.02.22 um 01:19 schrieb Michael Jung: > Dump header from device: /dev/ada0p2 > Architecture: amd64 > Architecture Version: 2 > Dump Length: 900231168 > Blocksize: 512 > Compression: none > Dumptime: 2022-02-04 15:48:08 -0500 > Hostname: draid.mikej.com > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 14.0-CURRENT #1 main-8d72c409c: Thu Feb 3 18:14= :01 EST 2022 > mikej@draid:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > Panic String: length mismatch > Dump Parity: 1692982593 > Bounds: 2 > Dump Status: good This is caused by the following code fragments: /* * Calculate the amount of space needed in the data buffer. An * identifier element is always present followed by the read-only= * and read-write keywords. */ len =3D sizeof(struct pci_vpd_element) + strlen(vpd->vpd_ident); for (i =3D 0; i < vpd->vpd_rocnt; i++) len +=3D sizeof(struct pci_vpd_element) + vpd->vpd_ros[i]= =2Elen; for (i =3D 0; i < vpd->vpd_wcnt; i++) len +=3D sizeof(struct pci_vpd_element) + vpd->vpd_w[i].l= en; [...] vpd_user =3D lvio->plvi_data; [...] vpd_user =3D PVE_NEXT_LEN(vpd_user, vpd_element.pve_datalen); vpd_element.pve_flags =3D 0; for (i =3D 0; i < vpd->vpd_rocnt; i++) { vpd_element.pve_keyword[0] =3D vpd->vpd_ros[i].keyword[0]= ; vpd_element.pve_keyword[1] =3D vpd->vpd_ros[i].keyword[1]= ; vpd_element.pve_datalen =3D vpd->vpd_ros[i].len; error =3D copyout(&vpd_element, vpd_user, sizeof(vpd_elem= ent)); if (error) return (error); error =3D copyout(vpd->vpd_ros[i].value, vpd_user->pve_data, vpd->vpd_ros[i].len); if (error) return (error); vpd_user =3D PVE_NEXT_LEN(vpd_user, vpd_element.pve_datal= en); } vpd_element.pve_flags =3D PVE_FLAG_RW; for (i =3D 0; i < vpd->vpd_wcnt; i++) { vpd_element.pve_keyword[0] =3D vpd->vpd_w[i].keyword[0]; vpd_element.pve_keyword[1] =3D vpd->vpd_w[i].keyword[1]; vpd_element.pve_datalen =3D vpd->vpd_w[i].len; error =3D copyout(&vpd_element, vpd_user, sizeof(vpd_elem= ent)); if (error) return (error); error =3D copyout(vpd->vpd_w[i].value, vpd_user->pve_data= , vpd->vpd_w[i].len); if (error) return (error); vpd_user =3D PVE_NEXT_LEN(vpd_user, vpd_element.pve_datal= en); } KASSERT((char *)vpd_user - (char *)lvio->plvi_data =3D=3D len, ("length mismatch")); The KASSERT triggered, indicating that a different amount of data has bee= n fetched than has previously been calculated. It would be interesting to compare the pre-computed "len" and the actual amount of data (i.e. the operands of =3D=3D in the KASSERT). The definition of PVE_NEXT_LEN looks correct, but in order to completely understand what the issue is, a dump of the VPD range should be analyzed (or you could add trace output to both the calculation of "len" and to the fetching of the VPD data that advances vpd_user). Regards, STefan PS: You may want to build a kernel with the attached patch, which prints the calculated lengths after each element that is added to "len". The KASSERT will only trigger if the actual length exceeds the expect= ed value, and the printf() output should go to the console device. My system does not seem to have a single device that provides VPD, therefore the patch has only been compile tested ... --------------4l5O0uW3zUcOq38cVYbzEyob Content-Type: text/plain; charset=UTF-8; name="pci_user.diff" Content-Disposition: attachment; filename="pci_user.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvcGNpL3BjaV91c2VyLmMgYi9zeXMvZGV2L3BjaS9wY2lf dXNlci5jCmluZGV4IGE1Zjg0OWU4NWMyZC4uYzc3MWRiMGI1MDcwIDEwMDY0NAotLS0gYS9z eXMvZGV2L3BjaS9wY2lfdXNlci5jCisrKyBiL3N5cy9kZXYvcGNpL3BjaV91c2VyLmMKQEAg LTU2NSw2ICs1NjUsNyBAQCBwY2lfbGlzdF92cGQoZGV2aWNlX3QgZGV2LCBzdHJ1Y3QgcGNp X2xpc3RfdnBkX2lvICpsdmlvKQogCXNpemVfdCBsZW47CiAJaW50IGVycm9yLCBpOwogCisJ cHJpbnRmKCIlcCAvICVwXG4iLCBsdmlvLT5wbHZpX2RhdGEsIFBWRV9ORVhUX0xFTihsdmlv LT5wbHZpX2RhdGEsIDEpKTsKIAl2cGQgPSBwY2lfZmV0Y2hfdnBkX2xpc3QoZGV2KTsKIAlp ZiAodnBkLT52cGRfcmVnID09IDAgfHwgdnBkLT52cGRfaWRlbnQgPT0gTlVMTCkKIAkJcmV0 dXJuIChFTlhJTyk7CkBAIC01NzUsMTAgKzU3NiwxNSBAQCBwY2lfbGlzdF92cGQoZGV2aWNl X3QgZGV2LCBzdHJ1Y3QgcGNpX2xpc3RfdnBkX2lvICpsdmlvKQogCSAqIGFuZCByZWFkLXdy aXRlIGtleXdvcmRzLgogCSAqLwogCWxlbiA9IHNpemVvZihzdHJ1Y3QgcGNpX3ZwZF9lbGVt ZW50KSArIHN0cmxlbih2cGQtPnZwZF9pZGVudCk7Ci0JZm9yIChpID0gMDsgaSA8IHZwZC0+ dnBkX3JvY250OyBpKyspCisJcHJpbnRmKCJMRU4oJWQpOiAlbHVcbiIsIC0xLCBsZW4pOwor CWZvciAoaSA9IDA7IGkgPCB2cGQtPnZwZF9yb2NudDsgaSsrKSB7CiAJCWxlbiArPSBzaXpl b2Yoc3RydWN0IHBjaV92cGRfZWxlbWVudCkgKyB2cGQtPnZwZF9yb3NbaV0ubGVuOwotCWZv ciAoaSA9IDA7IGkgPCB2cGQtPnZwZF93Y250OyBpKyspCisJCXByaW50ZigiTEVOKCVkKTog JWx1XG4iLCBpLCBsZW4pOworCX0KKwlmb3IgKGkgPSAwOyBpIDwgdnBkLT52cGRfd2NudDsg aSsrKSB7CiAJCWxlbiArPSBzaXplb2Yoc3RydWN0IHBjaV92cGRfZWxlbWVudCkgKyB2cGQt PnZwZF93W2ldLmxlbjsKKwkJcHJpbnRmKCJMRU4oJWQpOiAlbHVcbiIsIGksIGxlbik7CisJ fQogCiAJaWYgKGx2aW8tPnBsdmlfbGVuID09IDApIHsKIAkJbHZpby0+cGx2aV9sZW4gPSBs ZW47CkBAIC02MDYsNiArNjEyLDcgQEAgcGNpX2xpc3RfdnBkKGRldmljZV90IGRldiwgc3Ry dWN0IHBjaV9saXN0X3ZwZF9pbyAqbHZpbykKIAlpZiAoZXJyb3IpCiAJCXJldHVybiAoZXJy b3IpOwogCXZwZF91c2VyID0gUFZFX05FWFRfTEVOKHZwZF91c2VyLCB2cGRfZWxlbWVudC5w dmVfZGF0YWxlbik7CisJcHJpbnRmKCJMRU4oJWQpOiAlbHVcbiIsIC0xLCAoc2l6ZV90KSgo Y2hhciAqKXZwZF91c2VyIC0gKGNoYXIgKilsdmlvLT5wbHZpX2RhdGEpKTsKIAl2cGRfZWxl bWVudC5wdmVfZmxhZ3MgPSAwOwogCWZvciAoaSA9IDA7IGkgPCB2cGQtPnZwZF9yb2NudDsg aSsrKSB7CiAJCXZwZF9lbGVtZW50LnB2ZV9rZXl3b3JkWzBdID0gdnBkLT52cGRfcm9zW2ld LmtleXdvcmRbMF07CkBAIC02MTksNiArNjI2LDcgQEAgcGNpX2xpc3RfdnBkKGRldmljZV90 IGRldiwgc3RydWN0IHBjaV9saXN0X3ZwZF9pbyAqbHZpbykKIAkJaWYgKGVycm9yKQogCQkJ cmV0dXJuIChlcnJvcik7CiAJCXZwZF91c2VyID0gUFZFX05FWFRfTEVOKHZwZF91c2VyLCB2 cGRfZWxlbWVudC5wdmVfZGF0YWxlbik7CisJCXByaW50ZigiTEVOKCVkKTogJWx1XG4iLCBp LCAoc2l6ZV90KSgoY2hhciAqKXZwZF91c2VyIC0gKGNoYXIgKilsdmlvLT5wbHZpX2RhdGEp KTsKIAl9CiAJdnBkX2VsZW1lbnQucHZlX2ZsYWdzID0gUFZFX0ZMQUdfUlc7CiAJZm9yIChp ID0gMDsgaSA8IHZwZC0+dnBkX3djbnQ7IGkrKykgewpAQCAtNjMzLDggKzY0MSw5IEBAIHBj aV9saXN0X3ZwZChkZXZpY2VfdCBkZXYsIHN0cnVjdCBwY2lfbGlzdF92cGRfaW8gKmx2aW8p CiAJCWlmIChlcnJvcikKIAkJCXJldHVybiAoZXJyb3IpOwogCQl2cGRfdXNlciA9IFBWRV9O RVhUX0xFTih2cGRfdXNlciwgdnBkX2VsZW1lbnQucHZlX2RhdGFsZW4pOworCQlwcmludGYo IkxFTiglZCk6ICVsdVxuIiwgaSwgKHNpemVfdCkoKGNoYXIgKil2cGRfdXNlciAtIChjaGFy ICopbHZpby0+cGx2aV9kYXRhKSk7CiAJfQotCUtBU1NFUlQoKGNoYXIgKil2cGRfdXNlciAt IChjaGFyICopbHZpby0+cGx2aV9kYXRhID09IGxlbiwKKwlLQVNTRVJUKChjaGFyICopdnBk X3VzZXIgLSAoY2hhciAqKWx2aW8tPnBsdmlfZGF0YSA8PSBsZW4sCiAJICAgICgibGVuZ3Ro IG1pc21hdGNoIikpOwogCWx2aW8tPnBsdmlfbGVuID0gbGVuOwogCXJldHVybiAoMCk7Cg== --------------4l5O0uW3zUcOq38cVYbzEyob-- --------------EpAH2XZhPiiWbbYUDyouNveM-- --------------ofK5ce99cbe2nKle3Bm9SEq6 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmH/qusFAwAAAAAACgkQR+u171r99USE GggAqqv0fYlvNQqr7hEtKNTxmN5e0IwhnK3RRbXcCcQ0zYmmmV+T7oBlmADtBn/pYCsn3y7cZzO5 QDdkqauSXd65N64vJ+trSrHJn46dakqRbKkyjSuMm8OTyusYBxKXNpaIyUn3UnvlbSOX8nYQn1BW 3RRle1BYSd51r4X46RtjgXY2uy5mtJE8/I3SGZgJY0fRE0azSWJY1hp7jxZLxebfqGfl9ZxhT/6B +zaUTlVcS6Te3On9MNN9r8Bf1HZqYFumewKcwOgnnTJIbUhzrdCM56O5JXpcvQ2qrCm0ZTU7vJys 4ggcnvhPyMe+JqGqVCIo9q05At/Pp8R/NyAPYuJY+g== =2nxb -----END PGP SIGNATURE----- --------------ofK5ce99cbe2nKle3Bm9SEq6-- From nobody Sun Feb 6 15:53:00 2022 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 6AE43198A43D for ; Sun, 6 Feb 2022 15:53:04 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4JsDM35Dvnz4YS4; Sun, 6 Feb 2022 15:53:03 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 216Fr0S0071776; Sun, 6 Feb 2022 15:53:01 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 216Fr0Yt071775; Sun, 6 Feb 2022 15:53:00 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202202061553.216Fr0Yt071775@donotpassgo.dyslexicfish.net> Date: Sun, 06 Feb 2022 15:53:00 +0000 Organization: Dyslexic Fish To: theraven@FreeBSD.org, Cy.Schubert@cschubert.com Cc: freebsd-current@FreeBSD.org Subject: Re: Dragonfly Mail Agent (dma) in the base system References: <835dc887-6491-602c-7d71-d99309871126@siemens.com> <20220205141300.C19D2149@slippy.cwsent.com> In-Reply-To: <20220205141300.C19D2149@slippy.cwsent.com> User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sun, 06 Feb 2022 15:53:01 +0000 (GMT) X-Rspamd-Queue-Id: 4JsDM35Dvnz4YS4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.61)[-0.606]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Cy Schubert wrote: > dma doesn't support SMTP submission, we may need to review various port > default options or whether ports even support it. Good catch. Would a suitable workaround be to parse the dma.conf file for the SMARTHOST address, and then set up a simple tcp proxy on the local submission port to that? From nobody Sun Feb 6 17:14:50 2022 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 580CD19AC4A3 for ; Sun, 6 Feb 2022 17:14:59 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 4JsG9Z10VFz5584 for ; Sun, 6 Feb 2022 17:14:58 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.1.14] (c-98-249-71-218.hsd1.nm.comcast.net [98.249.71.218]) (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) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 285521AF4F8 for ; Sun, 6 Feb 2022 17:14:51 +0000 (UTC) Message-ID: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> Date: Sun, 6 Feb 2022 10:14:50 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Content-Language: en-US To: freebsd-current From: Sean Bruno Subject: USB Disk Stalls on -current Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JsG9Z10VFz5584 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 199.102.79.106 is neither permitted nor denied by domain of sbruno@freebsd.org) smtp.mailfrom=sbruno@freebsd.org X-Spamd-Result: default: False [-2.40 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[sbruno]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.91)[-0.910]; RECEIVED_SPAMHAUS_PBL(0.00)[98.249.71.218:received]; NEURAL_HAM_MEDIUM(-0.98)[-0.975]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.41)[-0.415]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:199.102.76.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I'm doing something "gross" with ZFS & Plex on a little Intel NUC that I have here at the house to provide me with a nice little NAS at home. I'm using 2x USB2 external disks as the mirror. I noted that the two USB2 disks I'm using in a mirror seem to "stall" from time to time and its not clear to me why. I'd like to poke further into the USB system but I'm not sure where I should start to see if there is something amiss with the hardware (e.g. the disks suck) or if FreeBSD is losing track of something during I/O leading to a stall/timeout. I'm not seeing data loss or anything, I just note from time to time during large file transfers that the clanking/grinding sound of the spinning rust on my desk completely stops, the encoding of the video files stops (so its waiting for a read to complete) and its gets much quieter in my office. :-) sean From nobody Sun Feb 6 17:52:04 2022 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 7B81B19A40D1 for ; Sun, 6 Feb 2022 17:52:47 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsH1B3vhCz3NRl; Sun, 6 Feb 2022 17:52:46 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-oi1-x234.google.com with SMTP id y23so14675296oia.13; Sun, 06 Feb 2022 09:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MeIeQOAOLiW/d6/OfCEv5ciHgn+ySpf3+pcTwpKoEgI=; b=mx+DXaWGAY4bNQ+0RmPe9LKg0irkowlnI8sF1onwJheQZ5tOsDRmUk3cRxWZOPApp+ ulOG3WyUJcisgPquM5Uk0Rh1mJ+4bIp2pf3CFLRWt7STkWO5pTu4+tYudhKbLQjveGV+ mTxULGBYjFXZUUyXn9k3cHpMimhaX7uU3j+XCxEYX/l0AyRmdQCuTQSy9xFqpcg9qmXd qdG19MIELrQT7Bnw/wRIYlG7vQ1o9Ks3b1jUU6P2fL7c/UlcLlXU8s5ApOg6PdiKS49X WifepmQq1fD4JySm/ITj8vtEgsRuwJmyrWEUi40Gw9RiHzRr22knjFX8Oh8HovPeq/qK 2aVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MeIeQOAOLiW/d6/OfCEv5ciHgn+ySpf3+pcTwpKoEgI=; b=K6m9l1m4QuU1G3RydXOmIQ8uFUrTLyza4y0XQfV2k1ju3zLbVepH72ibiYgODyhZGn 9GfdSkMegIO3bBvJlA2am4y865xlhBijlgC4UNMgPNr5hnZRrsiCNxIJtr7SRl/DCLZS /FTEaPSI/OGp4RZQ5o9z/cQvnQmoyo9TeO3BatdSpmvvssGbv5l24+8kGqS6kJHaSf3/ oGoOlc35A9QP6bzFPHhfjcIYYt1VhwKX+Buptj+gSGkooydpF+7cVQxIePczFfDv7LzJ zOjOxcvv9VXAl5I3xjn/O8y08wP7MHHSMoTXUFoGAktEK5ULCPQTQ2i8fs26inYX6ZCv t+FQ== X-Gm-Message-State: AOAM531f8ONLcNJrSrqNIinim9wB8ihfrIX2FWBT5L0NFh3top3Dd5+0 XIP4NzUnl0HNJn58eAQGP0Td1RKQ703uOrG2d27Enyb2t+U= X-Google-Smtp-Source: ABdhPJzXt8fqHxv/dlodzyqYK90dlb/7yqpSZ1ZWRmNjgjkEUdR8XN0CvZAmW7xu8k0dgXmAZeVlM0qwRCnP4FGy3rs= X-Received: by 2002:aca:5e55:: with SMTP id s82mr5418290oib.109.1644169960253; Sun, 06 Feb 2022 09:52:40 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> In-Reply-To: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> From: Mehmet Erol Sanliturk Date: Sun, 6 Feb 2022 20:52:04 +0300 Message-ID: Subject: Re: USB Disk Stalls on -current To: Sean Bruno Cc: freebsd-current Content-Type: multipart/alternative; boundary="0000000000006e6c3b05d75d264c" X-Rspamd-Queue-Id: 4JsH1B3vhCz3NRl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mx+DXaWG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mesanliturk@gmail.com designates 2607:f8b0:4864:20::234 as permitted sender) smtp.mailfrom=mesanliturk@gmail.com X-Spamd-Result: default: False [-2.05 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.972]; NEURAL_SPAM_MEDIUM(0.72)[0.720]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::234:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-0.80)[-0.798]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000006e6c3b05d75d264c Content-Type: text/plain; charset="UTF-8" On Sun, Feb 6, 2022 at 8:15 PM Sean Bruno wrote: > I'm doing something "gross" with ZFS & Plex on a little Intel NUC that I > have here at the house to provide me with a nice little NAS at home. > I'm using 2x USB2 external disks as the mirror. > > I noted that the two USB2 disks I'm using in a mirror seem to "stall" > from time to time and its not clear to me why. > > I'd like to poke further into the USB system but I'm not sure where I > should start to see if there is something amiss with the hardware (e.g. > the disks suck) or if FreeBSD is losing track of something during I/O > leading to a stall/timeout. > > I'm not seeing data loss or anything, I just note from time to time > during large file transfers that the clanking/grinding sound of the > spinning rust on my desk completely stops, the encoding of the video > files stops (so its waiting for a read to complete) and its gets much > quieter in my office. :-) > > sean > > I encountered such a case in Fedora Linux with an external 2.0 USB disk . When the external disk was connected to a 1.? USB port , the loading of operating system was terrifically slow or sometimes some parts normal . You may check your USB ports versions to ensure that they are conforming to each other . Board USB port may be 2.0 , but connected chassis USB port may be 1.? like in my chassis . When USB external disk is connected to the chassis USB 2.0 port , everything has become normal . Mehmet Erol Sanliturk --0000000000006e6c3b05d75d264c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 6, 2022 = at 8:15 PM Sean Bruno <sbruno@free= bsd.org> wrote:
I'm doing something "gross" with ZFS & Plex on a l= ittle Intel NUC that I
have here at the house to provide me with a nice little NAS at home.
I'm using 2x USB2 external disks as the mirror.

I noted that the two USB2 disks I'm using in a mirror seem to "sta= ll"
from time to time and its not clear to me why.

I'd like to poke further into the USB system but I'm not sure where= I
should start to see if there is something amiss with the hardware (e.g. the disks suck) or if FreeBSD is losing track of something during I/O
leading to a stall/timeout.

I'm not seeing data loss or anything, I just note from time to time during large file transfers that the clanking/grinding sound of the
spinning rust on my desk completely stops, the encoding of the video
files stops (so its waiting for a read to complete) and its gets much
quieter in my office.=C2=A0 :-)

sean



I encountered= such a case in Fedora Linux with an external 2.0 USB disk .
When the external disk was connected to a 1.? USB port , the loading of op= erating system
was terrifically slow or sometimes some parts= normal .

You may check your USB ports v= ersions to ensure that they are conforming to each other .
= Board USB port may be 2.0 , but connected chassis USB port may be 1.?=C2=A0= like in my chassis .
When USB external disk is connecte= d to the chassis=C2=A0 USB 2.0 port ,
everything has be= come normal .


= Mehmet Erol Sanliturk



=C2=A0
--0000000000006e6c3b05d75d264c-- From nobody Sun Feb 6 18:18:01 2022 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 4A6FD19B505C for ; Sun, 6 Feb 2022 18:18:05 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 4JsHZM3ZYCz3py7 for ; Sun, 6 Feb 2022 18:18:03 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.1.14] (c-98-249-71-218.hsd1.nm.comcast.net [98.249.71.218]) (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) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 6F7EE1AF4F8; Sun, 6 Feb 2022 18:18:02 +0000 (UTC) Message-ID: Date: Sun, 6 Feb 2022 11:18:01 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: USB Disk Stalls on -current Content-Language: en-US To: Mehmet Erol Sanliturk Cc: freebsd-current References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> From: Sean Bruno In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JsHZM3ZYCz3py7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 199.102.79.106 is neither permitted nor denied by domain of sbruno@freebsd.org) smtp.mailfrom=sbruno@freebsd.org X-Spamd-Result: default: False [-1.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[sbruno]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_MEDIUM(0.90)[0.902]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:199.102.76.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[98.249.71.218:received] X-ThisMailContainsUnwantedMimeParts: N On 2/6/22 10:52, Mehmet Erol Sanliturk wrote: > > > On Sun, Feb 6, 2022 at 8:15 PM Sean Bruno > wrote: > > I'm doing something "gross" with ZFS & Plex on a little Intel NUC > that I > have here at the house to provide me with a nice little NAS at home. > I'm using 2x USB2 external disks as the mirror. > > I noted that the two USB2 disks I'm using in a mirror seem to "stall" > from time to time and its not clear to me why. > > I'd like to poke further into the USB system but I'm not sure where I > should start to see if there is something amiss with the hardware (e.g. > the disks suck) or if FreeBSD is losing track of something during I/O > leading to a stall/timeout. > > I'm not seeing data loss or anything, I just note from time to time > during large file transfers that the clanking/grinding sound of the > spinning rust on my desk completely stops, the encoding of the video > files stops (so its waiting for a read to complete) and its gets much > quieter in my office.  :-) > > sean > > > > I encountered such a case in Fedora Linux with an external 2.0 USB disk . > When the external disk was connected to a 1.? USB port , the loading of > operating system > was terrifically slow or sometimes some parts normal . > > You may check your USB ports versions to ensure that they are conforming > to each other . > Board USB port may be 2.0 , but connected chassis USB port may be 1.? > like in my chassis . > When USB external disk is connected to the chassis  USB 2.0 port , > everything has become normal . > > > Mehmet Erol Sanliturk > > > I see them all up as 480mbps / USB 2.0 if usbconfig and the driver attach is anything to go by. Disk read/write perf when running seems to approach 40MB/s, so I think its running pretty close to the correct speed. ... ugen0.7: at usbus0 umass1 on uhub0 umass1: on usbus0 da0 at umass-sim1 bus 1 scbus4 target 0 lun 0 da0: Fixed Direct Access SCSI device da0: 40.000MB/s transfers da0: 1907729MB (3907029168 512 byte sectors) da0: quirks=0x2 Root mount waiting for: usbus0 .... ugen0.8: at usbus0 umass2 on uhub0 umass2: on usbus0 da1 at umass-sim2 bus 2 scbus5 target 0 lun 0 da1: Fixed Direct Access SPC-2 SCSI device da1: Serial Number ABCDEF0123456847 da1: 40.000MB/s transfers da1: 1907729MB (3907029168 512 byte sectors) da1: quirks=0x2 ... ugen0.7: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) ugen0.8: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ... sean From nobody Sun Feb 6 18:20:51 2022 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 69E9219B6026 for ; Sun, 6 Feb 2022 18:21:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsHdw31b8z3rBw for ; Sun, 6 Feb 2022 18:21:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x934.google.com with SMTP id b37so19460880uad.12 for ; Sun, 06 Feb 2022 10:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SWbiW8Pf6WbzdfD+y/MKGyC7rc2QmDYJLHrimBB6+TM=; b=zCEnDM3MERiVPPD3+ngahPhalmRP8+b8LR9GNr0LahN3HaT+EaZrmoj68P1Ccqn4nZ HR/br2/WdZyr1X1f4TWiQ01P8697yINgX+aWYd2OcZxuzKsH7VLIvXMK50KVmX9aM7s0 ltvCvBT/uhyDsJkYGT/PbGV9jhDdTecD6qlC1wYrHFoRar7oeNr8ye3gCF8tU/pMiGID zaoCBrvbsGuRW/0OpYSO6+hBnBevViaUl1PfzbRGHL1nUC4SsfKtlsrsPSsa2LTbuW1J 4gpo87JgJadIHX0hE7qZjTnGRUMW0py2lRfTUI+ghwg0cU2IrlV5sG0Mo1XcJeTBg8Fs ePuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SWbiW8Pf6WbzdfD+y/MKGyC7rc2QmDYJLHrimBB6+TM=; b=gipCItdoCoI5xCLBmOR0eeHdGGHSwXcgpNdRvbKjkAg7eLjmfPjo/gh6pjAmok5/um YAUi2D7RIaQ7riEt4zqIVJrwYwUerZV1whYujiaRBJoGB1ie5idWKDKmchY8Ax/iw5Ts DSWEKmB307UuxuVsNj5LPuyt3uArlN+N+LdzaUfFEzVFGUI8Vt5JCzcVLElu0mxI+urL VecH2gfWS1CzZZLEMwTl5H0cOWO1njJs+UPdyg0U/GD4qszS8WjyGWgshWHfxVPhT09O 6IL9IJvNboZw3QLrMKXx2MN7NKeYvedloDgjDkP+pUHh3p8LAvqT9yzP/L3viWcU6GmR 9nOg== X-Gm-Message-State: AOAM5322l/tLhxMVuogQb99HHx/KbRoGMASkJzQqsLjLUrDmimkaN6gI YZyYrPDu5xOeEbyjlhH04HpW5G0JPJ44yVl9rali0meSR1M= X-Google-Smtp-Source: ABdhPJxk/eFM8614Pa4FLIrTIXGY1lv2QLAyzT3m2nVgmn8EGzZfJOI1k0q180rYOgc6SIp/Ymf4HuLdVJpBBTVGNTE= X-Received: by 2002:a67:fac3:: with SMTP id g3mr3863963vsq.6.1644171662395; Sun, 06 Feb 2022 10:21:02 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> In-Reply-To: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> From: Warner Losh Date: Sun, 6 Feb 2022 11:20:51 -0700 Message-ID: Subject: Re: USB Disk Stalls on -current To: Sean Bruno Cc: freebsd-current Content-Type: multipart/alternative; boundary="000000000000e3225705d75d8b1d" X-Rspamd-Queue-Id: 4JsHdw31b8z3rBw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=zCEnDM3M; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::934) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.99 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::934:from]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000e3225705d75d8b1d Content-Type: text/plain; charset="UTF-8" On Sun, Feb 6, 2022 at 10:15 AM Sean Bruno wrote: > I'm doing something "gross" with ZFS & Plex on a little Intel NUC that I > have here at the house to provide me with a nice little NAS at home. > I'm using 2x USB2 external disks as the mirror. > > I noted that the two USB2 disks I'm using in a mirror seem to "stall" > from time to time and its not clear to me why. > > I'd like to poke further into the USB system but I'm not sure where I > should start to see if there is something amiss with the hardware (e.g. > the disks suck) or if FreeBSD is losing track of something during I/O > leading to a stall/timeout. > > I'm not seeing data loss or anything, I just note from time to time > during large file transfers that the clanking/grinding sound of the > spinning rust on my desk completely stops, the encoding of the video > files stops (so its waiting for a read to complete) and its gets much > quieter in my office. :-) > So there's some tools you can use. For usb, there's usbdump that can get you the USB transactions. I've not used it enough to give more details here. This will let you know what's going on, and when, on the USB endpoint. You can also enable the CAM_IOSCHED stuff. This will allow you to get latency measurements for 'requests in the sim' which basically will tell you what your latency spread is for the drives. This will tell you if things are getting caught up in the USB layer, or after CAM's da driver completes the I/O request (granted, that's almost certainly not happening, but it will help you figure out what's going on and put numbers to the oddities you are seeing). Also, make sure you have good cables. I've had lots of hicups over the years from dodgy USB cables. Also make sure you have good, high quality enclosures. Many from the USB2 time-period are sketchy at best and I went through several at one point trying to find a good one. I'd be tempted to get USB 3 enclosures. I've had better luck with USB3 gear than USB2 gear here, but you need a USB-3 controller to get USB-3 speeds which might not be compatible with the NUC's built-in stuff (though my NUC has one USB3 port, there's lots of different models). Usually, though, I see weirdness associated with dmesg messages from usb, cam, etc when the hardware is on the sketch end. Warner --000000000000e3225705d75d8b1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 6, 2022 at 10:15 AM Sean = Bruno <sbruno@freebsd.org> = wrote:
I'm d= oing something "gross" with ZFS & Plex on a little Intel NUC = that I
have here at the house to provide me with a nice little NAS at home.
I'm using 2x USB2 external disks as the mirror.

I noted that the two USB2 disks I'm using in a mirror seem to "sta= ll"
from time to time and its not clear to me why.

I'd like to poke further into the USB system but I'm not sure where= I
should start to see if there is something amiss with the hardware (e.g. the disks suck) or if FreeBSD is losing track of something during I/O
leading to a stall/timeout.

I'm not seeing data loss or anything, I just note from time to time during large file transfers that the clanking/grinding sound of the
spinning rust on my desk completely stops, the encoding of the video
files stops (so its waiting for a read to complete) and its gets much
quieter in my office.=C2=A0 :-)

So ther= e's some tools you can use. For usb, there's usbdump that can
=
get you the USB transactions. I've not used it enough to give more= details
here. This will let you know what's going on, and wh= en, on the USB endpoint.

You can also enable the C= AM_IOSCHED stuff. This will allow you to get latency
measurements= for 'requests in the sim' which basically will tell you what your<= /div>
latency spread is for the drives. This will tell you if things ar= e getting caught
up in the USB layer, or after CAM's da drive= r completes the I/O request
(granted, that's almost certainly= not happening, but it will help you figure out
what's going = on and put numbers to the oddities you are seeing).

Also, make sure you have good cables. I've had lots of hicups=C2=A0ov= er the
years from dodgy USB cables. Also make sure you have good,= high quality
enclosures. Many from the USB2 time-period are sket= chy at best and I
went through several at one point trying to fin= d a good one. I'd be tempted to
get USB 3 enclosures. I'v= e had better luck with USB3 gear than USB2 gear
here, but you nee= d a USB-3 controller to get USB-3 speeds which might not
be compa= tible with the NUC's built-in stuff (though my NUC has one USB3
port, there's lots of different models).

Us= ually, though, I see weirdness associated with dmesg messages from
usb, cam, etc when the hardware is on the sketch end.

Warner
--000000000000e3225705d75d8b1d-- From nobody Sun Feb 6 19:02:19 2022 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 2DA0919A6E33 for ; Sun, 6 Feb 2022 19:02:22 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 4JsJYT0YlCz4dbb for ; Sun, 6 Feb 2022 19:02:21 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.1.14] (c-98-249-71-218.hsd1.nm.comcast.net [98.249.71.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 410761AF4F8; Sun, 6 Feb 2022 19:02:20 +0000 (UTC) Message-ID: <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> Date: Sun, 6 Feb 2022 12:02:19 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: USB Disk Stalls on -current Content-Language: en-US To: Warner Losh Cc: freebsd-current References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> From: Sean Bruno In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JsJYT0YlCz4dbb X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 199.102.79.106 is neither permitted nor denied by domain of sbruno@freebsd.org) smtp.mailfrom=sbruno@freebsd.org X-Spamd-Result: default: False [-0.78 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[sbruno]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.63)[-0.631]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.99)[-0.992]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_SHORT(0.94)[0.943]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:199.102.76.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[98.249.71.218:received] X-ThisMailContainsUnwantedMimeParts: N > > > So there's some tools you can use. For usb, there's usbdump that can > get you the USB transactions. I've not used it enough to give more details > here. This will let you know what's going on, and when, on the USB endpoint. > > You can also enable the CAM_IOSCHED stuff. This will allow you to get > latency > measurements for 'requests in the sim' which basically will tell you > what your > latency spread is for the drives. This will tell you if things are > getting caught > up in the USB layer, or after CAM's da driver completes the I/O request > (granted, that's almost certainly not happening, but it will help you > figure out > what's going on and put numbers to the oddities you are seeing). > > Also, make sure you have good cables. I've had lots of hicups over the > years from dodgy USB cables. Also make sure you have good, high quality > enclosures. Many from the USB2 time-period are sketchy at best and I > went through several at one point trying to find a good one. I'd be > tempted to > get USB 3 enclosures. I've had better luck with USB3 gear than USB2 gear > here, but you need a USB-3 controller to get USB-3 speeds which might not > be compatible with the NUC's built-in stuff (though my NUC has one USB3 > port, there's lots of different models). > > Usually, though, I see weirdness associated with dmesg messages from > usb, cam, etc when the hardware is on the sketch end. > > Warner I'm assuming that I have a fairly dodgy USB device, as the pauses seem to correspond to this from CAM being emitted: Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: 28 00 36 69 02 6e 00 00 80 00 Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status: CCB request completed with an error Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying command, 2 more tries remain Things resume after this is emitted, but there is a substantial (multiple minutes) pause here. I would assume that timeouts would fire much quicker. sean From nobody Sun Feb 6 19:11:01 2022 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 CA4B119AC911 for ; Sun, 6 Feb 2022 19:11:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsJlS0r4wz4hpx for ; Sun, 6 Feb 2022 19:11:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x933.google.com with SMTP id b37so19574425uad.12 for ; Sun, 06 Feb 2022 11:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OuEhUbD4Qes5muSSVLX+LqPMW3xMQ/NO1vqrO2KQIyo=; b=c/EC8QO5PVQ1ryQiCocEzi5b3BgAhweosIJ0W96dmupt/h8DwZ3AEBfiD7MLYBllCt 4VnYWY5bOyo0lOcIj9CK53D/xnDc0AUaPQNYEO6T1nMnmzj1MwCOGzNJAZysgHDxwk0/ i0/yDv/QlmDfeoCTrxORkqutAHUelb9jxGANCAJ1G3tUSBTFi7LyrAX7ES5bsw/ylNeD OQrHfR99wtKyhJFvV/XjVnay7GYRyCQ0chDlXfQ2bWoeuSzyWbbSdbO8Nd2j2SHWxMqL APPTMBK2bWWw28LBrxKzZx/KtGUL7uoJY8UGYBl+dnwTLJZevJ/Ci/e88xQJWNEzp4Zd VlXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OuEhUbD4Qes5muSSVLX+LqPMW3xMQ/NO1vqrO2KQIyo=; b=stInNFLf25kjqALND7WBZrx5nWMJdxkBmtRzeNM+AYcDhCTFHgP7nD2Ao/TOyYDQlM XFF9KTybB66dwEzri2WKnG1SwIAwx4P2ajfEasOCHaY57QcOJqq1SRW9flquAUJXGRaE QfzTwqNoclHSacnnQ1+CCIiLOctuV7tiKJ8gGb9Iwdcw7XxlF/rblfepq9C9M51kR2ro kaShtDnSmZiEVeUeid14ktgNDEd0das1Ly8UnMbyVQlE7AA8qkWZZQelymJuCGfOjjRX bnr+YOi3T61eJXq+R13M9i7zWv3/xq409iLLSl6BvhhlGiQmY4LVqw1JI8xJFMwq5FxX vRfA== X-Gm-Message-State: AOAM533yhnvXuuvV+LfhJB/yGnkdZpiWhI2PU+oe03zpL1BzeGBpoiyB xgIBrDJnJJGB0e4feXBSne5M8GrAEvu+8GHKGWnWZ2f/s7QUyw== X-Google-Smtp-Source: ABdhPJwSFXuqA8Kbi2t2BDxsqdEDpgAAbiEg9fb4MDm3oPrs/7ezgwYH349qdz8Vya/WviWt9UkfH9cW84G448ycM00= X-Received: by 2002:a67:33c9:: with SMTP id z192mr3597651vsz.42.1644174659557; Sun, 06 Feb 2022 11:10:59 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> In-Reply-To: <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> From: Warner Losh Date: Sun, 6 Feb 2022 12:11:01 -0700 Message-ID: Subject: Re: USB Disk Stalls on -current To: Sean Bruno Cc: freebsd-current Content-Type: multipart/alternative; boundary="00000000000088342d05d75e3e91" X-Rspamd-Queue-Id: 4JsJlS0r4wz4hpx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="c/EC8QO5"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::933) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.76 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::933:from]; NEURAL_HAM_SHORT(-0.77)[-0.767]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000088342d05d75e3e91 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 6, 2022 at 12:02 PM Sean Bruno wrote: > > > > > > > > So there's some tools you can use. For usb, there's usbdump that can > > get you the USB transactions. I've not used it enough to give more > details > > here. This will let you know what's going on, and when, on the USB > endpoint. > > > > You can also enable the CAM_IOSCHED stuff. This will allow you to get > > latency > > measurements for 'requests in the sim' which basically will tell you > > what your > > latency spread is for the drives. This will tell you if things are > > getting caught > > up in the USB layer, or after CAM's da driver completes the I/O request > > (granted, that's almost certainly not happening, but it will help you > > figure out > > what's going on and put numbers to the oddities you are seeing). > > > > Also, make sure you have good cables. I've had lots of hicups over the > > years from dodgy USB cables. Also make sure you have good, high quality > > enclosures. Many from the USB2 time-period are sketchy at best and I > > went through several at one point trying to find a good one. I'd be > > tempted to > > get USB 3 enclosures. I've had better luck with USB3 gear than USB2 gear > > here, but you need a USB-3 controller to get USB-3 speeds which might not > > be compatible with the NUC's built-in stuff (though my NUC has one USB3 > > port, there's lots of different models). > > > > Usually, though, I see weirdness associated with dmesg messages from > > usb, cam, etc when the hardware is on the sketch end. > > > > Warner > > I'm assuming that I have a fairly dodgy USB device, as the pauses seem > to correspond to this from CAM being emitted: > > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: 28 > 00 36 69 02 6e 00 00 80 00 > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status: CCB > request completed with an error > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying command, > 2 more tries remain > > > Things resume after this is emitted, but there is a substantial > (multiple minutes) pause here. I would assume that timeouts would fire > much quicker. > The default timeout is 60s. You can reduce that substantially by setting kern.cam.da.default_timeout to a smaller level. Disk operations completed within 5s these days, except spin ups. Heck, nearly all complete within 500ms. You might try setting this value to maybe 3 or 5 or 10 to see if that helps the hiccups without introducing extra retries when the load is heavy. The smaller values give a faster recovery, but too small a number may result in timeouts and errors under load. I think you need to set this as a tuneable. Warner --00000000000088342d05d75e3e91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 6, 2022 at 12:02 PM Sean = Bruno <sbruno@freebsd.org> = wrote:


>
>
> So there's some tools you can use. For usb, there's usbdump th= at can
> get you the USB transactions. I've not used it enough to give more= details
> here. This will let you know what's going on, and when, on the USB= endpoint.
>
> You can also enable the CAM_IOSCHED stuff. This will allow you to get =
> latency
> measurements for 'requests in the sim' which basically will te= ll you
> what your
> latency spread is for the drives. This will tell you if things are > getting caught
> up in the USB layer, or after CAM's da driver completes the I/O re= quest
> (granted, that's almost certainly not happening, but it will help = you
> figure out
> what's going on and put numbers to the oddities you are seeing). >
> Also, make sure you have good cables. I've had lots of hicups=C2= =A0over the
> years from dodgy USB cables. Also make sure you have good, high qualit= y
> enclosures. Many from the USB2 time-period are sketchy at best and I > went through several at one point trying to find a good one. I'd b= e
> tempted to
> get USB 3 enclosures. I've had better luck with USB3 gear than USB= 2 gear
> here, but you need a USB-3 controller to get USB-3 speeds which might = not
> be compatible with the NUC's built-in stuff (though my NUC has one= USB3
> port, there's lots of different models).
>
> Usually, though, I see weirdness associated with dmesg messages from > usb, cam, etc when the hardware is on the sketch end.
>
> Warner

I'm assuming that I have a fairly dodgy USB device, as the pauses seem =
to correspond to this from CAM being emitted:

Feb=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: 2= 8
00 36 69 02 6e 00 00 80 00
Feb=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status: CCB =
request completed with an error
Feb=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying command= ,
2 more tries remain


Things resume after this is emitted, but there is a substantial
(multiple minutes) pause here.=C2=A0 I would assume that timeouts would fir= e
much quicker.

The default timeout is 60= s.

You can reduce that substantially by setting ke= rn.cam.da.default_timeout
to a smaller level. Disk operations com= pleted within 5s these days,
except spin ups. Heck, nearly all co= mplete within 500ms. You
might try setting this value to maybe 3 = or 5 or 10 to see if that helps the
hiccups without introducing e= xtra retries when the load is heavy. The
smaller values give a fa= ster recovery, but too small a number may result
in timeouts and = errors under load. I think you need to set this as a tuneable.

Warner
--00000000000088342d05d75e3e91-- From nobody Sun Feb 6 20:05:14 2022 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 C290719AB091 for ; Sun, 6 Feb 2022 20:05:57 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsKyr3mjbz3JY7; Sun, 6 Feb 2022 20:05:56 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-oi1-x229.google.com with SMTP id m10so15015852oie.2; Sun, 06 Feb 2022 12:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZS+4VQB1OfpqOWC1g+yH3gCh4jPhOwetxMt3VhWf9Nw=; b=MAqArU/wOew/bYajQZ2ntjgF5fw3VjQIUQw3tN4W6JQCnPkv6H0hLzpx9NMUi9tqHD d7z5tFKAiRpTRxsuDkghKJL9SxCRzOeosOWaHow1ai7AhlSiJj4b7aqDgiQJpi+cxxVp mem7sSi2bS/0/gEJsShEU/3Uii6rmryeJE4WHpyprVeCpO+Zmm+TIfjjyq1fgJCWITN0 9Tzz15qTp4Pk8quSXqIKKycpYfcRTo+wTsKDBJU2fUrt+j+FXB1/vyo7WBjlFCPI+dv8 mWIywLdImPDlPpJgeV1EpmQEOUR4AjwBCKjyxKDzcql/zPgvG1bh4Pt8+s4EgeHmMFmx jcyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZS+4VQB1OfpqOWC1g+yH3gCh4jPhOwetxMt3VhWf9Nw=; b=v4mWhDJRZInbvOL8PsCGFT9OEnQ0isizwho/ddvsF5tE5jSkdPEjhcLu8kR9xRdwUX QI78Iewq6cHUwKiDOqSH1NEIOHnlZgg/4tsGjaST0b8Lmb6Yrg5h9gspjqyyfsjLDOW4 ENkPRowQ0w4Z7PVlO0obMxDtKT0AuhssiIVDs5XZl1jojZn9gvGfARSs1HkeGzLNtyCK SQNFLGLl+M8n6lLC6+C/kGJuBfwaymAClCCCDIsFCqfSjjWlFUrSFgz2Tlm9B5NNS+R/ T7VVChXptZO98U5jhAxmKvtF4qi3W7gbywsX0oSzcf11yeSVHxCDPZ4nHmb+aVmu8ELY cDqQ== X-Gm-Message-State: AOAM533sOM/uE4GrA5lTQAQMAKGIfFpPO00HljUdTrSfvbBu8AJVnBmD zu0PpqvMyBR0gz0G7yTRmv7mXgqd1Yq0R/reydVL3ddmd4I= X-Google-Smtp-Source: ABdhPJwohNq5T6r/GXTO4eee0urfSWOImcspIHMfUtizGxhYiXebmwKeZRyz3gJfyeS0QWp0jUSqYTAWMdn/f5hI56Q= X-Received: by 2002:a05:6808:d4b:: with SMTP id w11mr5911660oik.62.1644177950446; Sun, 06 Feb 2022 12:05:50 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> In-Reply-To: From: Mehmet Erol Sanliturk Date: Sun, 6 Feb 2022 23:05:14 +0300 Message-ID: Subject: Re: USB Disk Stalls on -current To: Warner Losh Cc: Sean Bruno , freebsd-current Content-Type: multipart/alternative; boundary="000000000000af1a4d05d75f0223" X-Rspamd-Queue-Id: 4JsKyr3mjbz3JY7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="MAqArU/w"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mesanliturk@gmail.com designates 2607:f8b0:4864:20::229 as permitted sender) smtp.mailfrom=mesanliturk@gmail.com X-Spamd-Result: default: False [-3.97 / 15.00]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-0.99)[-0.986]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::229:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000af1a4d05d75f0223 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 6, 2022 at 10:11 PM Warner Losh wrote: > > > On Sun, Feb 6, 2022 at 12:02 PM Sean Bruno wrote: > >> >> >> > >> > >> > So there's some tools you can use. For usb, there's usbdump that can >> > get you the USB transactions. I've not used it enough to give more >> details >> > here. This will let you know what's going on, and when, on the USB >> endpoint. >> > >> > You can also enable the CAM_IOSCHED stuff. This will allow you to get >> > latency >> > measurements for 'requests in the sim' which basically will tell you >> > what your >> > latency spread is for the drives. This will tell you if things are >> > getting caught >> > up in the USB layer, or after CAM's da driver completes the I/O request >> > (granted, that's almost certainly not happening, but it will help you >> > figure out >> > what's going on and put numbers to the oddities you are seeing). >> > >> > Also, make sure you have good cables. I've had lots of hicups over the >> > years from dodgy USB cables. Also make sure you have good, high quality >> > enclosures. Many from the USB2 time-period are sketchy at best and I >> > went through several at one point trying to find a good one. I'd be >> > tempted to >> > get USB 3 enclosures. I've had better luck with USB3 gear than USB2 gear >> > here, but you need a USB-3 controller to get USB-3 speeds which might >> not >> > be compatible with the NUC's built-in stuff (though my NUC has one USB3 >> > port, there's lots of different models). >> > >> > Usually, though, I see weirdness associated with dmesg messages from >> > usb, cam, etc when the hardware is on the sketch end. >> > >> > Warner >> >> I'm assuming that I have a fairly dodgy USB device, as the pauses seem >> to correspond to this from CAM being emitted: >> >> Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: 28 >> 00 36 69 02 6e 00 00 80 00 >> Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status: CCB >> request completed with an error >> Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying command, >> 2 more tries remain >> >> >> Things resume after this is emitted, but there is a substantial >> (multiple minutes) pause here. I would assume that timeouts would fire >> much quicker. >> > > The default timeout is 60s. > > You can reduce that substantially by setting kern.cam.da.default_timeout > to a smaller level. Disk operations completed within 5s these days, > except spin ups. Heck, nearly all complete within 500ms. You > might try setting this value to maybe 3 or 5 or 10 to see if that helps the > hiccups without introducing extra retries when the load is heavy. The > smaller values give a faster recovery, but too small a number may result > in timeouts and errors under load. I think you need to set this as a > tuneable. > > Warner > Are your external disks "GREEN" , i.e. , "energy saver" kind . If the external disks are energy saver kind , they will start to sleep when they are not used for a while , and waking them up will take time which causes significant distress , because to use them requires waiting every such wake up . At that point another important trouble is slowness of USB external disks with respect to internal ( non-energy saver ) SATA disks . When response time is important , it is necessary to avoid such "GREEN" disks . Mehmet Erol Sanliturk --000000000000af1a4d05d75f0223 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 6, 2022 = at 10:11 PM Warner Losh <imp@bsdimp.co= m> wrote:


On Sun, Feb 6, 2022 at 12:02 PM Sean= Bruno <sbruno@f= reebsd.org> wrote:


>
>
> So there's some tools you can use. For usb, there's usbdump th= at can
> get you the USB transactions. I've not used it enough to give more= details
> here. This will let you know what's going on, and when, on the USB= endpoint.
>
> You can also enable the CAM_IOSCHED stuff. This will allow you to get =
> latency
> measurements for 'requests in the sim' which basically will te= ll you
> what your
> latency spread is for the drives. This will tell you if things are > getting caught
> up in the USB layer, or after CAM's da driver completes the I/O re= quest
> (granted, that's almost certainly not happening, but it will help = you
> figure out
> what's going on and put numbers to the oddities you are seeing). >
> Also, make sure you have good cables. I've had lots of hicups=C2= =A0over the
> years from dodgy USB cables. Also make sure you have good, high qualit= y
> enclosures. Many from the USB2 time-period are sketchy at best and I > went through several at one point trying to find a good one. I'd b= e
> tempted to
> get USB 3 enclosures. I've had better luck with USB3 gear than USB= 2 gear
> here, but you need a USB-3 controller to get USB-3 speeds which might = not
> be compatible with the NUC's built-in stuff (though my NUC has one= USB3
> port, there's lots of different models).
>
> Usually, though, I see weirdness associated with dmesg messages from > usb, cam, etc when the hardware is on the sketch end.
>
> Warner

I'm assuming that I have a fairly dodgy USB device, as the pauses seem =
to correspond to this from CAM being emitted:

Feb=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: 2= 8
00 36 69 02 6e 00 00 80 00
Feb=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status: CCB =
request completed with an error
Feb=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying command= ,
2 more tries remain


Things resume after this is emitted, but there is a substantial
(multiple minutes) pause here.=C2=A0 I would assume that timeouts would fir= e
much quicker.

The default timeout is 60= s.

You can reduce that substantially by setting ke= rn.cam.da.default_timeout
to a smaller level. Disk operations com= pleted within 5s these days,
except spin ups. Heck, nearly all co= mplete within 500ms. You
might try setting this value to maybe 3 = or 5 or 10 to see if that helps the
hiccups without introducing e= xtra retries when the load is heavy. The
smaller values give a fa= ster recovery, but too small a number may result
in timeouts and = errors under load. I think you need to set this as a tuneable.

Warner



Are your external disks=C2=A0 &q= uot;GREEN" , i.e. ,=C2=A0 "energy saver" kind .

If the external disks are energy saver kind , they w= ill start to sleep when they are not
used for a while , and = waking them up will take time which causes significant distress ,
because to use them requires waiting every such wake up=C2=A0 .
=

At that point another important trouble is sl= owness of USB external disks
with respect to internal (= non-energy saver ) SATA disks .

Whe= n response time is important , it is necessary to avoid such "GREEN&qu= ot; disks .



Mehmet Erol Sanliturk

=


=C2=A0
--000000000000af1a4d05d75f0223-- From nobody Sun Feb 6 22:16:26 2022 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 A5D2C19B23C5 for ; Sun, 6 Feb 2022 22:16:31 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4JsNsT2bpyz3Dgf; Sun, 6 Feb 2022 22:16:29 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 216MGRN3005758; Sun, 6 Feb 2022 22:16:27 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 216MGQgQ005757; Sun, 6 Feb 2022 22:16:26 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202202062216.216MGQgQ005757@donotpassgo.dyslexicfish.net> Date: Sun, 06 Feb 2022 22:16:26 +0000 Organization: Dyslexic Fish To: jamie@catflap.org, Cy.Schubert@cschubert.com Cc: theraven@FreeBSD.org, freebsd-current@FreeBSD.org, Cy.Schubert@cschubert.com Subject: Re: Dragonfly Mail Agent (dma) in the base system References: <835dc887-6491-602c-7d71-d99309871126@siemens.com> <20220205141300.C19D2149@slippy.cwsent.com> <202202061553.216Fr0Yt071775@donotpassgo.dyslexicfish.net> <20220206161102.D8114111@slippy.cwsent.com> In-Reply-To: <20220206161102.D8114111@slippy.cwsent.com> User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sun, 06 Feb 2022 22:16:27 +0000 (GMT) X-Rspamd-Queue-Id: 4JsNsT2bpyz3Dgf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-2.57 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net:c]; NEURAL_HAM_LONG(-0.95)[-0.952]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.08)[0.076]; BLOCKLISTDE_FAIL(0.00)[104.207.135.49:server fail,2001:19f0:300:2185:123::1:server fail]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Cy Schubert wrote: > In message <202202061553.216Fr0Yt071775@donotpassgo.dyslexicfish.net>, > Jamie La > ndeg-Jones writes: > > Cy Schubert wrote: > > > > > dma doesn't support SMTP submission, we may need to review various port > > > default options or whether ports even support it. > > > > Good catch. > > You misquoted me. Read my email again! Sorry, I read it again, but it still looks to me as "some ports only work via SMTP submission, so they will need to be looked at." I suggested an alternative of instead, "emulating" the SMTP submission functionality (but maybe in a better way that my suggested hack, though) After all, it isn't just ports - there could be other third party stuff that only works via submission too. So, to avoid breaking functionality, smtp submission is something to think about continuing supporting, hence my use of the phrase "good catch". Is this not correct? cheers, Jamie > > Would a suitable workaround be to parse the dma.conf file for the SMARTHOST > > address, and then set up a simple tcp proxy on the local submission port to > > that? > > Your comment is based on a false premise. From nobody Mon Feb 7 02:50:40 2022 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 D1EA019BECDD for ; Mon, 7 Feb 2022 02:50:45 +0000 (UTC) (envelope-from qroxana@protonmail.com) Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25]) (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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsVxx013Yz4fJ5 for ; Mon, 7 Feb 2022 02:50:44 +0000 (UTC) (envelope-from qroxana@protonmail.com) Date: Mon, 07 Feb 2022 02:50:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1644202242; bh=MCr9WbTFQuw8gp0x8ftOhvpTxNKNstTQQN5zodTQS0M=; h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc; b=PCXaaRfD241fHGA/S2iMlyFqLkyDPgwtaUx6Crx9tcC5O9aKtUAi3dm3IH6diWoxr /c/B7FHQuGCOlUyjEQ2sOmMtoudGT+DwzIoEJO5sBe1QxmAZPczCGFhn741/LOBDk0 Pbu5cNY1mnSHI2WIXiye70DoEfai88puK1+x+6eOtdnjuFf3xSR0RM3KrkViApkyvj d4euFixVdyYUEguaAghELV7UNEUH7BuDL83Z6lRyjSGMmwXU61Cco/c46BPGV9tBxu N/O5y74LlUuoJxTkJMmHbU/M8C1cStCLNltYP1y68Ulyk/+xVBXTrMHOpQJftIl4va y7WKj0EGGCznw== To: "freebsd-current@freebsd.org" From: qroxana Reply-To: qroxana Subject: buildworld failed Message-ID: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.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: multipart/alternative; boundary="b1_Ze7qUnN9SWbrIdSrtpKjKyDC0Ta39oao9Rj7Xsq1I" X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4JsVxx013Yz4fJ5 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail2 header.b=PCXaaRfD; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of qroxana@protonmail.com designates 185.70.43.25 as permitted sender) smtp.mailfrom=qroxana@protonmail.com X-Spamd-Result: default: False [2.77 / 15.00]; HAS_REPLYTO(0.00)[qroxana@protonmail.com]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail2]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.999]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.67)[0.675]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_Ze7qUnN9SWbrIdSrtpKjKyDC0Ta39oao9Rj7Xsq1I Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBrbm93IHJ1bm5pbmcgbWFrZSBpbnN0YWxsIGZvciAvdXNyL3NyYy90b29scy9idWlsZC90ZXN0 LWluY2x1ZGVzIGNhbiBmaXggdGhpcywKYnV0IHRoaXMgc3RpbGwgZmFpbHMgb24gYSBuZXdseSBp bnN0YWxsZWQgMTQuMC1DVVJSRU5ULgoKLS0tIHRlc3QtaW5jbHVkZXMgLS0tCmNkIC91c3Ivc3Jj L3Rvb2xzL2J1aWxkL3Rlc3QtaW5jbHVkZXM7IE1BQ0hJTkVfQVJDSD1hYXJjaDY0IE1BQ0hJTkU9 YXJtNjQgQ1BVVFlQRT0gQ0M9ImNjIC10YXJnZXQgYWFyY2g2NC11bmtub3duLWZyZWVic2QxNC4w IC0tc3lzcm9vdD0vdXNyL29iai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvdG1wIC1CL3Vzci9vYmov dXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC91c3IvYmluIC10YXJnZXQgYWFyY2g2NC11bmtub3du LWZyZWVic2QxNC4wIC0tc3lzcm9vdD0vdXNyL29iai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvdG1w IC1CL3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC91c3IvYmluIiBDWFg9ImMrKyAt dGFyZ2V0IGFhcmNoNjQtdW5rbm93bi1mcmVlYnNkMTQuMCAtLXN5c3Jvb3Q9L3Vzci9vYmovdXNy L3NyYy9hcm02NC5hYXJjaDY0L3RtcCAtQi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90 bXAvdXNyL2JpbiAtdGFyZ2V0IGFhcmNoNjQtdW5rbm93bi1mcmVlYnNkMTQuMCAtLXN5c3Jvb3Q9 L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcCAtQi91c3Ivb2JqL3Vzci9zcmMvYXJt NjQuYWFyY2g2NC90bXAvdXNyL2JpbiIgQ1BQPSJjcHAgLXRhcmdldCBhYXJjaDY0LXVua25vd24t ZnJlZWJzZDE0LjAgLS1zeXNyb290PS91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAg LUIvdXNyL29iai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvdG1wL3Vzci9iaW4gLXRhcmdldCBhYXJj aDY0LXVua25vd24tZnJlZWJzZDE0LjAgLS1zeXNyb290PS91c3Ivb2JqL3Vzci9zcmMvYXJtNjQu YWFyY2g2NC90bXAgLUIvdXNyL29iai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvdG1wL3Vzci9iaW4i IEFTPSJhcyIgQVI9ImFyIiBFTEZDVEw9ImVsZmN0bCIgTEQ9ImxkIiBMTFZNX0xJTks9IiIgTk09 bm0gT0JKQ09QWT0ib2JqY29weSIgUkFOTElCPXJhbmxpYiBTVFJJTkdTPSBTSVpFPSJzaXplIiBT VFJJUEJJTj0ic3RyaXAiIElOU1RBTEw9Imluc3RhbGwgLVUiIFBBVEg9L3Vzci9vYmovdXNyL3Ny Yy9hcm02NC5hYXJjaDY0L3RtcC9iaW46L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3Rt cC91c3Ivc2JpbjovdXNyL29iai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvdG1wL3Vzci9iaW46L3Vz ci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC9sZWdhY3kvdXNyL3NiaW46L3Vzci9vYmov dXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC9sZWdhY3kvdXNyL2JpbjovdXNyL29iai91c3Ivc3Jj L2FybTY0LmFhcmNoNjQvdG1wL2xlZ2FjeS9iaW46L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJj aDY0L3RtcC9sZWdhY3kvdXNyL2xpYmV4ZWM6Oi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2 NC90bXAvYmluOi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAvdXNyL3NiaW46L3Vz ci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC91c3IvYmluOi91c3Ivb2JqL3Vzci9zcmMv YXJtNjQuYWFyY2g2NC90bXAvbGVnYWN5L3Vzci9zYmluOi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQu YWFyY2g2NC90bXAvbGVnYWN5L3Vzci9iaW46L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0 L3RtcC9sZWdhY3kvYmluOi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAvbGVnYWN5 L3Vzci9saWJleGVjOjovc2JpbjovYmluOi91c3Ivc2JpbjovdXNyL2JpbiBTWVNST09UPS91c3Iv b2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAgbWFrZSBERVNURElSPS91c3Ivb2JqL3Vzci9z cmMvYXJtNjQuYWFyY2g2NC90bXAgdGVzdC1pbmNsdWRlcwotLS0gc3lzL2FiaV9jb21wYXQuYyAt LS0KLS0tIHN5cy9hY2N0LmMgLS0tCi0tLSBzeXMvYWNsLmMgLS0tCi0tLSBzeXMvYWlvLmMgLS0t Ci0tLSBzeXMvYWJpX2NvbXBhdC5jIC0tLQplY2hvICIjaW5jbHVkZSA8c3lzL2FiaV9jb21wYXQu aD4iID4gc3lzL2FiaV9jb21wYXQuYwpzaDogY2Fubm90IGNyZWF0ZSBzeXMvYWJpX2NvbXBhdC5j OiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5CioqKiBbc3lzL2FiaV9jb21wYXQuY10gRXJyb3Ig Y29kZSAyCgptYWtlWzRdOiBzdG9wcGVkIGluIC91c3Ivc3JjL3Rvb2xzL2J1aWxkL3Rlc3QtaW5j bHVkZXMKLS0tIHN5cy9hY2N0LmMgLS0tCmVjaG8gIiNpbmNsdWRlIDxzeXMvYWNjdC5oPiIgPiBz eXMvYWNjdC5jCnNoOiBjYW5ub3QgY3JlYXRlIHN5cy9hY2N0LmM6IE5vIHN1Y2ggZmlsZSBvciBk aXJlY3RvcnkKKioqIFtzeXMvYWNjdC5jXSBFcnJvciBjb2RlIDIKCm1ha2VbNF06IHN0b3BwZWQg aW4gL3Vzci9zcmMvdG9vbHMvYnVpbGQvdGVzdC1pbmNsdWRlcwotLS0gc3lzL2Fpby5jIC0tLQpl Y2hvICIjaW5jbHVkZSA8c3lzL2Fpby5oPiIgPiBzeXMvYWlvLmMKc2g6IGNhbm5vdCBjcmVhdGUg c3lzL2Fpby5jOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5CioqKiBbc3lzL2Fpby5jXSBFcnJv ciBjb2RlIDIKCm1ha2VbNF06IHN0b3BwZWQgaW4gL3Vzci9zcmMvdG9vbHMvYnVpbGQvdGVzdC1p bmNsdWRlcwotLS0gc3lzL2FjbC5jIC0tLQplY2hvICIjaW5jbHVkZSA8c3lzL2FjbC5oPiIgPiBz eXMvYWNsLmMKc2g6IGNhbm5vdCBjcmVhdGUgc3lzL2FjbC5jOiBObyBzdWNoIGZpbGUgb3IgZGly ZWN0b3J5CioqKiBbc3lzL2FjbC5jXSBFcnJvciBjb2RlIDI= --b1_Ze7qUnN9SWbrIdSrtpKjKyDC0Ta39oao9Rj7Xsq1I Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9k aXY+PGRpdiBpZD0icHJvdG9uLXJvb3QiPjxkaXYgaWQ9InByb3Rvbi1wcmludCI+PGJyPjwvZGl2 PjxkaXYgc3R5bGU9ImRpc3BsYXk6IGZsZXggIWltcG9ydGFudDsgd2lkdGg6IDEwMCUgIWltcG9y dGFudDsiPjxkaXYgc3R5bGU9IndpZHRoOiAxMDAlICFpbXBvcnRhbnQiPjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyI+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij5JIGtub3cgcnVubmluZyBtYWtlIGluc3RhbGwg Zm9yIC91c3Ivc3JjL3Rvb2xzL2J1aWxkL3Rlc3QtaW5jbHVkZXMgY2FuIGZpeCB0aGlzLDxicj48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPmJ1 dCB0aGlzIHN0aWxsIGZhaWxzIG9uIGEgbmV3bHkgaW5zdGFsbGVkIDE0LjAtQ1VSUkVOVC48YnI+ PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0 cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6 IDE0cHg7Ij48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsi Pi0tLSB0ZXN0LWluY2x1ZGVzIC0tLTxicj48L2Rpdj48ZGl2PmNkDQogL3Vzci9zcmMvdG9vbHMv YnVpbGQvdGVzdC1pbmNsdWRlczsmbmJzcDsgTUFDSElORV9BUkNIPWFhcmNoNjQmbmJzcDsNCk1B Q0hJTkU9YXJtNjQmbmJzcDsgQ1BVVFlQRT0gQ0M9ImNjIC10YXJnZXQgYWFyY2g2NC11bmtub3du LWZyZWVic2QxNC4wDQotLXN5c3Jvb3Q9L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3Rt cA0KLUIvdXNyL29iai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvdG1wL3Vzci9iaW4gLXRhcmdldA0K YWFyY2g2NC11bmtub3duLWZyZWVic2QxNC4wIC0tc3lzcm9vdD0vdXNyL29iai91c3Ivc3JjL2Fy bTY0LmFhcmNoNjQvdG1wDQogLUIvdXNyL29iai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvdG1wL3Vz ci9iaW4iIENYWD0iYysrJm5ic3A7IC10YXJnZXQNCmFhcmNoNjQtdW5rbm93bi1mcmVlYnNkMTQu MCAtLXN5c3Jvb3Q9L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcA0KIC1CL3Vzci9v YmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC91c3IvYmluJm5ic3A7IC10YXJnZXQNCmFhcmNo NjQtdW5rbm93bi1mcmVlYnNkMTQuMCAtLXN5c3Jvb3Q9L3Vzci9vYmovdXNyL3NyYy9hcm02NC5h YXJjaDY0L3RtcA0KIC1CL3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC91c3IvYmlu IiZuYnNwOyBDUFA9ImNwcCAtdGFyZ2V0DQphYXJjaDY0LXVua25vd24tZnJlZWJzZDE0LjAgLS1z eXNyb290PS91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXANCiAtQi91c3Ivb2JqL3Vz ci9zcmMvYXJtNjQuYWFyY2g2NC90bXAvdXNyL2JpbiAtdGFyZ2V0DQphYXJjaDY0LXVua25vd24t ZnJlZWJzZDE0LjAgLS1zeXNyb290PS91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAN CiAtQi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAvdXNyL2JpbiImbmJzcDsgQVM9 ImFzIiBBUj0iYXIiDQpFTEZDVEw9ImVsZmN0bCIgTEQ9ImxkIiZuYnNwOyBMTFZNX0xJTks9IiIg Tk09bm0gT0JKQ09QWT0ib2JqY29weSImbmJzcDsNClJBTkxJQj1yYW5saWIgU1RSSU5HUz0mbmJz cDsgU0laRT0ic2l6ZSIgU1RSSVBCSU49InN0cmlwIiZuYnNwOyBJTlNUQUxMPSJpbnN0YWxsDQot VSImbmJzcDsNClBBVEg9L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC9iaW46L3Vz ci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC91c3Ivc2JpbjovdXNyL29iai91c3Ivc3Jj L2FybTY0LmFhcmNoNjQvdG1wL3Vzci9iaW46L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0 L3RtcC9sZWdhY3kvdXNyL3NiaW46L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC9s ZWdhY3kvdXNyL2JpbjovdXNyL29iai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvdG1wL2xlZ2FjeS9i aW46L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC9sZWdhY3kvdXNyL2xpYmV4ZWM6 Oi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAvYmluOi91c3Ivb2JqL3Vzci9zcmMv YXJtNjQuYWFyY2g2NC90bXAvdXNyL3NiaW46L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0 L3RtcC91c3IvYmluOi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAvbGVnYWN5L3Vz ci9zYmluOi91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFyY2g2NC90bXAvbGVnYWN5L3Vzci9iaW46 L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3RtcC9sZWdhY3kvYmluOi91c3Ivb2JqL3Vz ci9zcmMvYXJtNjQuYWFyY2g2NC90bXAvbGVnYWN5L3Vzci9saWJleGVjOjovc2JpbjovYmluOi91 c3Ivc2JpbjovdXNyL2JpbiZuYnNwOw0KIFNZU1JPT1Q9L3Vzci9vYmovdXNyL3NyYy9hcm02NC5h YXJjaDY0L3RtcCBtYWtlJm5ic3A7DQpERVNURElSPS91c3Ivb2JqL3Vzci9zcmMvYXJtNjQuYWFy Y2g2NC90bXAgdGVzdC1pbmNsdWRlczxicj48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZh bWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPi0tLSBzeXMvYWJpX2NvbXBhdC5jIC0tLTxi cj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsi Pi0tLSBzeXMvYWNjdC5jIC0tLTxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogYXJp YWw7IGZvbnQtc2l6ZTogMTRweDsiPi0tLSBzeXMvYWNsLmMgLS0tPGJyPjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyI+LS0tIHN5cy9haW8uYyAt LS08YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0 cHg7Ij4tLS0gc3lzL2FiaV9jb21wYXQuYyAtLS08YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij5lY2hvICIjaW5jbHVkZSAmbHQ7c3lzL2Fi aV9jb21wYXQuaCZndDsiICZndDsgc3lzL2FiaV9jb21wYXQuYzxicj48L2Rpdj48ZGl2IHN0eWxl PSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPnNoOiBjYW5ub3QgY3JlYXRl IHN5cy9hYmlfY29tcGF0LmM6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnk8YnI+PC9kaXY+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij4qKiogW3N5cy9h YmlfY29tcGF0LmNdIEVycm9yIGNvZGUgMjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZh bWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPm1ha2VbNF06IHN0b3BwZWQgaW4gL3Vzci9z cmMvdG9vbHMvYnVpbGQvdGVzdC1pbmNsdWRlczxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZh bWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPi0tLSBzeXMvYWNjdC5jIC0tLTxicj48L2Rp dj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPmVjaG8g IiNpbmNsdWRlICZsdDtzeXMvYWNjdC5oJmd0OyIgJmd0OyBzeXMvYWNjdC5jPGJyPjwvZGl2Pjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyI+c2g6IGNhbm5v dCBjcmVhdGUgc3lzL2FjY3QuYzogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeTxicj48L2Rpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPioqKiBbc3lz L2FjY3QuY10gRXJyb3IgY29kZSAyPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBh cmlhbDsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyI+bWFrZVs0XTogc3RvcHBlZCBpbiAvdXNyL3NyYy90 b29scy9idWlsZC90ZXN0LWluY2x1ZGVzPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyI+LS0tIHN5cy9haW8uYyAtLS08YnI+PC9kaXY+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij5lY2hvICIjaW5j bHVkZSAmbHQ7c3lzL2Fpby5oJmd0OyIgJmd0OyBzeXMvYWlvLmM8YnI+PC9kaXY+PGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij5zaDogY2Fubm90IGNyZWF0 ZSBzeXMvYWlvLmM6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnk8YnI+PC9kaXY+PGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij4qKiogW3N5cy9haW8uY10g RXJyb3IgY29kZSAyPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9u dC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsg Zm9udC1zaXplOiAxNHB4OyI+bWFrZVs0XTogc3RvcHBlZCBpbiAvdXNyL3NyYy90b29scy9idWls ZC90ZXN0LWluY2x1ZGVzPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsg Zm9udC1zaXplOiAxNHB4OyI+LS0tIHN5cy9hY2wuYyAtLS08YnI+PC9kaXY+PGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij5lY2hvICIjaW5jbHVkZSAmbHQ7 c3lzL2FjbC5oJmd0OyIgJmd0OyBzeXMvYWNsLmM8YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij5zaDogY2Fubm90IGNyZWF0ZSBzeXMvYWNs LmM6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnk8YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij4qKiogW3N5cy9hY2wuY10gRXJyb3IgY29k ZSAyPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAx NHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXpl OiAxNHB4OyI+PGJyPjwvZGl2PjxkaXYgaWQ9InByb3Rvbi10b2dnbGUiPjxicj48L2Rpdj48ZGl2 IGlkPSJwcm90b24tYmxvY2txdW90ZSI+PGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2Pg== --b1_Ze7qUnN9SWbrIdSrtpKjKyDC0Ta39oao9Rj7Xsq1I-- From nobody Mon Feb 7 04:02:16 2022 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 A9B9519C74D1 for ; Mon, 7 Feb 2022 04:02:20 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsXXW6j3Vz3LMm for ; Mon, 7 Feb 2022 04:02:19 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x32d.google.com with SMTP id j5-20020a05600c1c0500b0034d2e956aadso7678844wms.4 for ; Sun, 06 Feb 2022 20:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=AUpKPg3OON2k6AqJtem+6F59FQzOGXmtswdH67BMJwU=; b=FjmK9SvjWHJQa1GcCaRCYatgD6uo+kDXIRzNM9bxTF06bFkIJkAwdqExK2LJ7ePW7m hTZ9mcp0LHuNM/HddQXQWjW7rBDS2Zxcl9W/Tc0GUblkyznNS1GbNFOK0GXe7Zn3h0YA QE7lAyM70IQFK+UDmI8VSnUxHYZQd34hzHzZQqPQVp7eB0n7UCPA+jSEd84eXL6jD2Gr v240q7oMe72H5W0wNYVMI8t6hqxqOKaBS78RF/oPasZPpMUQALj59DAQxIxiZwLkUN26 IYmtsT4CJylvPqSEiBCsRO/r9utoAQqmSvdfQs95alaJaRrw74rOi2C2XnlzDUa0myUQ E5ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=AUpKPg3OON2k6AqJtem+6F59FQzOGXmtswdH67BMJwU=; b=6k2KROidklm/xOPKnTANZrKudMlIGCKt7HKvVqftSveBpWpSp6LNBhkcIlYh6Ew/df B5zd2onzZCwHGi/LS4EjTZkmNgPX72O/OuB1df1/40QJSeC1TQ78iTssFQapl2jJBOcC Ui2I6wCQxtggFfeok6LpstGJWPB2yjmYphMgzVQPI/zCiEdX5YcGq+ukVtn5lH9MBqQJ YVmRU7UXm99TXxJ/FizWLiwEzaYgkABv5mY1vfn2khE58HmizzN2hsEy5Cq84bUG4sKA eRzmwtQfB6czAlK9pkjHdzD79buyY5Ecm6c4k56+mQTYZRJ02GRv8CBsK0T/ppyr9IxR RHHg== X-Gm-Message-State: AOAM533hGa6EJEQPyWYA4k2alXMCh1aENRg+EsNBKg/wubwbTjEnOTiw ipXbUjkC6Lk2y1K1p1NlhFUlx+6uLWNBcQ== X-Google-Smtp-Source: ABdhPJx6ILjPGjzNp7BquSs/ImHKhhG2aa4uIUY+7ccsoJeUdhkdWY7BZttHac2Bq/r64K6+hmV7vQ== X-Received: by 2002:a05:600c:a0d:: with SMTP id z13mr9396534wmp.20.1644206538344; Sun, 06 Feb 2022 20:02:18 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id f25sm5207702wml.16.2022.02.06.20.02.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Feb 2022 20:02:17 -0800 (PST) Message-ID: <2bc20b06-d2f6-2dd1-2fdc-c4a288515604@gmail.com> Date: Mon, 7 Feb 2022 04:02:16 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: USB Disk Stalls on -current Content-Language: en-GB To: freebsd-current References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> From: Graham Perrin In-Reply-To: <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JsXXW6j3Vz3LMm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=FjmK9Svj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32d as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.96 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32d:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 06/02/2022 17:14, Sean Bruno wrote: > … the clanking/grinding sound of the spinning rust on my desk > completely stops, the encoding of the video files stops (so its > waiting for a read to complete)… On 06/02/2022 19:02, Sean Bruno wrote: > … assuming that I have a fairly dodgy USB device, as the pauses seem > to correspond to this from CAM being emitted: > > Feb  6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: > 28 00 36 69 02 6e 00 00 80 00 > Feb  6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status: CCB > request completed with an error > Feb  6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying > command, 2 more tries remain > > Things resume after this is emitted, but there is a substantial > (multiple minutes) pause here. … Yep, for a pause of that length (without a logged exhaustion) I'd suspect the hard disk drive. Over the years, I've seen 'CCB request completed with an error' often enough, and in various situations, with _good_ media e.g. , to get a sense (for myself) of whether there's a marginal cable, marginal port at the computer, marginal port at the drive, or some combination of those three things. Can you get S.M.A.R.T. data? An extended self-test might not expose an issue that becomes evident with sustained _writes_ (although I note your opening post comment about waiting for a read to complete). HTH Graham From nobody Mon Feb 7 06:31:40 2022 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 A154819B1641 for ; Mon, 7 Feb 2022 06:31:48 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jsbrz6Rc7z3GNr for ; Mon, 7 Feb 2022 06:31:47 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-vk1-xa2f.google.com with SMTP id m131so7210792vkm.7 for ; Sun, 06 Feb 2022 22:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3CJkfF8lw32y8iO3aiAnAEw0c7kSWKjfaXhAPZ0mHqQ=; b=NPG1/9BDPbGKTjDQjZ3CDT6tcWyT4A5NYjIdklg0NXaMitRGDuInG7Q9V2A1EdgsHN 7/fk+ZwtwOTqcui1PllxEbi1hprxcps/Nw9w/iD87T1oFLpD4DkXHcHpTlYWYIFHU5+d 7/QMP5OeDiU/2Rf7oefjKSmmz2uuF86zjDeHN+e4+PmJ9vbL6cUsZMY09jAL7bnS6N51 kk1PZNBovbcP08mxnQp2+zBoRW9UWete2YjRhgnvsZcMWApel0rz1EEaL88KgOa4Dkll TBpja8dRJt/PUv4zzMi/sqvlcW6VuJdRkzemc/OcjrwxskosmJo/NoYL3RpVaIjYFD+T glfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3CJkfF8lw32y8iO3aiAnAEw0c7kSWKjfaXhAPZ0mHqQ=; b=VaZY3/M9IULrD2zp1/F+j8iHEyaCXefDAWDAbEvJKAhz+31egfoGDw3dLAljO3eGlF 3uCf9zLH/72A8pWxT9YWNmkYfY87EB8lPVj9VtH1uVJ+ciN+6HjEkVDmL546iYCEyUvL cXB496TduHbcv2QKJzcGN8koBPt/siJsU6gLmhXdwPsoSdPQoYNBTetC8BpWwOaCTIWx Msg53JUswdhofEczutxA6kPl7dBmEorpL7bGf62jf46pRmCegX+S+098CANEtl8hsIXb +6XXp4JHWp3ZNj8I0pUlXkFPhCsy6qA3FsihdEG2pAyD73zZPhAMI3QTkJRSfeDpbFLd Lp1w== X-Gm-Message-State: AOAM5310ZKl8/VimomlzPBwkv5GLeyfDxTUuSBHFyKUSnraTGezBWcNP LEDnnF6z+8pqLuX54uG86nr+K6nwuJezJZZcGWAqfHT4RDfRt5Hc X-Google-Smtp-Source: ABdhPJz3XKvn7MEl8wSmjNINk/s4lEyP2G28F819bF9XiajFKd3cP4XFc1dJjK1UZynt6zEDAWJgtwaKK9sHQqJQdPo= X-Received: by 2002:a05:6122:7cf:: with SMTP id l15mr4472597vkr.27.1644215501182; Sun, 06 Feb 2022 22:31:41 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:a59:aca4:0:b0:28a:7e2e:6c8c with HTTP; Sun, 6 Feb 2022 22:31:40 -0800 (PST) In-Reply-To: <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> From: grarpamp Date: Mon, 7 Feb 2022 01:31:40 -0500 Message-ID: Subject: Re: USB Disk Stalls on -current To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Jsbrz6Rc7z3GNr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="NPG1/9BD"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::a2f as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-2.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2f:from]; NEURAL_SPAM_SHORT(0.99)[0.990]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: 28 > 00 36 69 02 6e 00 00 80 00 > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status: CCB > request completed with an error > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying command, > 2 more tries remain Isn't there mechanism for kernel/cam/driver to issue a sense request to fetch and print the actual error... assuming, which is fine, that the bus or devices aren't already locked up, in reset, etc such that a sense would go unfulfilled or already be cleared. From nobody Mon Feb 7 06:46:02 2022 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 C348919B931E for ; Mon, 7 Feb 2022 06:46:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jsc9f2gSwz3Mml for ; Mon, 7 Feb 2022 06:46:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92c.google.com with SMTP id v5so10156934uam.3 for ; Sun, 06 Feb 2022 22:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2oV4X0QOefB3dAsmmBua09BzjfIQeCLRiWYGdLvrJ+o=; b=V7ZqSZgZfvnbwNWe5TUfyVYfKka3EKXuSpGEXm5/ROphp03f3ej/AtSLHKl6S93dHF L5lXkAX5cdXt21gx5sFDhGqigAFqCRGulg3ZaMtH5w+80a8Up0RxkSiJ38M+VdbFMbGL 6xpYULwTzhE/GNdc4DZR+7OwfjwxOOfy/UqlqmcQv0BI/AcfDknO8zGIq5HGVWOXw516 ZneyRTrafkIdRw9rG7xW2Zre7oUnNYAjZKkMUvUY5ldxSdupkkeubMpAucsOuXtzPyxw 6EbNqxG+eoXG1ua5V1KxLjXpqiNzntYllL7RsMF06H34e5i/I+aIx8ymhLR5frIMk78O Nx6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2oV4X0QOefB3dAsmmBua09BzjfIQeCLRiWYGdLvrJ+o=; b=7zXPzxcGD/0jFMVxX++j0wiyFq8dA4tZXPkb2ywHwlQrZzbI11Ymgi4uwb/JAVzUB0 NROwx44BXVztE4O9/pzIn9ECgm0FUvZtOLZNQ3TM62XW9H/JP5QYMpWwU27VM9jFYNfb szpo8ezYG8hsGPlNbQrA/SLTiF6fBnq0CZ4U6cDeC6eqIzE/j2B1pG6pUMVYoBWwrjw7 45W6ULyoCYPh8hIs206tJ890GCm/tC/qGfGLBSQYac1seh1IvakvVjyhcSsnyFg/kqp+ ZSRx3Fa5nOK3sKL0kq97GMHtz3BpEBumV9iNUvZliUklk+hlBWazFQf8l42l4yGrkTDW F/Ng== X-Gm-Message-State: AOAM531dCcZXracSaZS8pI0yKrYRqHtStb4z7mdpWvlyT4eYDCOv/RcE HT0ArilCMcCCuBMayvcj/cMcSrBfBWzQIHcqSk8DIw== X-Google-Smtp-Source: ABdhPJx9OC9rBtsqDwlgsA0W7rmYKJpTucfy4DrLX8kjyfSfqDAU8nXdNInIYaLL6NdCO2kx09j2ejMButOXNdKzMWw= X-Received: by 2002:a67:fc97:: with SMTP id x23mr4307415vsp.68.1644216373738; Sun, 06 Feb 2022 22:46:13 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> In-Reply-To: From: Warner Losh Date: Sun, 6 Feb 2022 23:46:02 -0700 Message-ID: Subject: Re: USB Disk Stalls on -current To: grarpamp Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000e4180505d767f4a9" X-Rspamd-Queue-Id: 4Jsc9f2gSwz3Mml X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=V7ZqSZgZ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.48 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.48)[-0.481]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92c:from]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::92c:server fail]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; NEURAL_HAM_SHORT(-1.00)[-0.997]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000e4180505d767f4a9 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 6, 2022 at 11:32 PM grarpamp wrote: > > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: 28 > > 00 36 69 02 6e 00 00 80 00 > > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status: CCB > > request completed with an error > > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying command, > > 2 more tries remain > > Isn't there mechanism for kernel/cam/driver to issue a > sense request to fetch and print the actual error... > We do that, but since this is a timeout, there's no sense to print (otherwise we'd print the sense here). We definitely report those errors for things like media error, etc. > > assuming, which is fine, that the bus or devices aren't > already locked up, in reset, etc such that a sense > would go unfulfilled or already be cleared. > I'm pretty sure the problem here is that the disks are timing out for some reason. Many USB drives are designed for occasional use, and often have aggressive power saving modes, which are known to hiccup like this. And many USB bridge to SATA chips have been known to glitch out under load (sometimes transparently sometimes not). Warner --000000000000e4180505d767f4a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 6, 2022 at 11:32 PM grarp= amp <grarpamp@gmail.com> wr= ote:
> Feb=C2= =A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: 28
> 00 36 69 02 6e 00 00 80 00
> Feb=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status:= CCB
> request completed with an error
> Feb=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying co= mmand,
> 2 more tries remain

Isn't there mechanism for kernel/cam/driver to issue a
sense request to fetch and print the actual error...
<= br>
We do that, but since this is a timeout, there's no sense to
print (otherwise we'd print the sense he= re). We definitely report
those errors for = things like media error, etc.
=C2=A0 assuming, which is fine, that the bus or devices aren't
already locked up, in reset, etc such that a sense
would go unfulfilled or already be cleared.

=
I'm pretty sure the problem here is that the disks are timing out<= /div>
for some reason. Many USB drives are designed for occasional
use, and often have aggressive power saving modes, which are
known to hiccup like this. And many USB bridge to SATA chips
ha= ve been known to glitch out under load (sometimes transparently
s= ometimes not).

Warner

--000000000000e4180505d767f4a9-- From nobody Mon Feb 7 07:10:33 2022 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 C807B19A9214 for ; Mon, 7 Feb 2022 07:11:04 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from us-smtp-delivery-197.mimecast.com (us-smtp-delivery-197.mimecast.com [170.10.133.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mimecast.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsckH485Nz3mnb for ; Mon, 7 Feb 2022 07:11:03 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from MAIL-DR.pai.local (175.158.26.216.gopai.com [216.26.158.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-258-Od2YsZNBMLGBz4NIyxpWmQ-1; Mon, 07 Feb 2022 02:10:53 -0500 X-MC-Unique: Od2YsZNBMLGBz4NIyxpWmQ-1 Received: from MAIL-HUB.pai.local (10.10.0.250) by MAIL-DR.pai.local (10.10.0.251) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Mon, 7 Feb 2022 02:10:33 -0500 Received: from MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8]) by MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8%15]) with mapi id 15.00.1497.028; Mon, 7 Feb 2022 02:10:33 -0500 From: Michael Jung To: freebsd-current Subject: FW: pciconf -lbvV crashes kernel main-8d72c409c - 2022-02-07 Thread-Topic: pciconf -lbvV crashes kernel main-8d72c409c - 2022-02-07 Thread-Index: Adgb4iBT3s4tbgwdQ9iXzufPWGK3DAAAxZog Date: Mon, 7 Feb 2022 07:10:33 +0000 Message-ID: <2ae728c8634e44b391e23764aa2ca5e8@MAIL-HUB.pai.local> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.0.59] x-c2processedorg: 474f336e-f930-49ec-9717-e3226b5b6e6e 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-Mimecast-Spam-Score: 0 X-Mimecast-Originator: paymentallianceintl.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_2ae728c8634e44b391e23764aa2ca5e8MAILHUBpailocal_" X-Rspamd-Queue-Id: 4JsckH485Nz3mnb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=paymentallianceintl.com; spf=pass (mx1.freebsd.org: domain of mikej@paymentallianceintl.com designates 170.10.133.197 as permitted sender) smtp.mailfrom=mikej@paymentallianceintl.com X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:170.10.133.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[paymentallianceintl.com,none]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:30031, ipnet:170.10.132.0/23, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[170.10.133.197:from] X-ThisMailContainsUnwantedMimeParts: N --_000_2ae728c8634e44b391e23764aa2ca5e8MAILHUBpailocal_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi: Here are the kernel.full files some of you asked for. Let me know what els= e may be helpful to test. Thanks! Michael Jung Notes below ***** (UPDATED) ***** Started fresh Installed FreeBSD-14.0-CURRENT-amd64-20220113-0910a41ef3b-252413-disc1.iso with its accompany source tree. Built kernel/world, installed them, reboote= d and http://mail.mikej.com/core.txt.0 http://mail.mikej.com/info.0 http://mail.mikej.com/kernel.full.0 http://mail.mikej.com/vmcore.0 ***** I deleted all contents from /usr/obj built fresh /usr/src via git to = b6724f7004c and 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252997-b6724f7004c http://mail.mikej.com/core.txt.1 http://mail.mikej.com/info.1 http://mail.mikej.com/kernel.full.1 http://mail.mikej.com/vmcore.1 ***** It's the '-V' switch that triggers the panic ***** I did note that pciconf does not identify my CPU correctly (see below= ) ***** The panic always occurs after ix0 output from pciconf -lbvV (see belo= w) ix1 has always followed next with -lbv - it has never been pres= ent with -lbvV ***** Switching the LSI 9208-16E and Intel dual port X520 PCI slots did no= t help ***** ixl1 definitely works using the exact same SPF+ adapter and cable ***** Removing the Intel X520 82599ES allow pciconf -lbvV to run ***** I have a single port version of this intel X520 which works It seem to me, that when pciconf iterates to ix1@pci0:2:0:1 the problem alw= ays occurs. I build like this: nice make -WITH_META_MODE -DFAST_DEPEND -DWITHOUT_CLEAN -sj12 buildworld nice make -WITH_META_MODE -DFAST_DEPEND -DWITHOUT_CLEAN -sj12 buildkernel root@draid:/var/crash # cat /etc/make.conf WITH_CCACHE_BUILD=3Dyes CCACHE_DIR=3D/root/.ccache root@draid:/var/crash There is no src.conf or sysctl.conf and I have only added '"filemon_load=3D= "YES"' to /boot/loader.conf ***** I did Note that pciconf does not identify my CPU correctly It is actually an Intel Core i7-3770K - a sample programs in ports that get= s it right is sysutils/cpufetch. ***** Here is "-vlb" root@draid:/home/mikej # pciconf -vlb pciconf -lvb hostb0@pci0:0:0:0: class=3D0x060000 rev=3D0x09 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x0150 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D 'Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 rev=3D0x09 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x0151 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D 'Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root= Port' class =3D bridge subclass =3D PCI-PCI pcib2@pci0:0:1:1: class=3D0x060400 rev=3D0x09 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x0155 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D 'Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root= Port' class =3D bridge subclass =3D PCI-PCI none0@pci0:0:22:0: class=3D0x078000 rev=3D0x04 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c3a subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family MEI Controller' class =3D simple comms bar [10] =3D type Memory, range 64, base 0xf7f0b000, size 16, enabled ehci0@pci0:0:26:0: class=3D0x0c0320 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c2d subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family USB Enhanced Host C= ontroller' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xf7f08000, size 1024, enabl= ed hdac1@pci0:0:27:0: class=3D0x040300 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c20 subvendor=3D0x1043 subdevice=3D0x8469 vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family High Definition Aud= io Controller' class =3D multimedia subclass =3D HDA bar [10] =3D type Memory, range 64, base 0xf7f00000, size 16384, enab= led pcib3@pci0:0:28:0: class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x1c10 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family PCI Express Root Po= rt 1' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:0:28:4: class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x1c18 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family PCI Express Root Po= rt 5' class =3D bridge subclass =3D PCI-PCI pcib5@pci0:0:28:5: class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x1c1a subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family PCI Express Root Po= rt 6' class =3D bridge subclass =3D PCI-PCI pcib6@pci0:0:28:6: class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x1c1c subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family PCI Express Root Po= rt 7' class =3D bridge subclass =3D PCI-PCI pcib7@pci0:0:28:7: class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x1c1e subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family PCI Express Root Po= rt 8' class =3D bridge subclass =3D PCI-PCI ehci1@pci0:0:29:0: class=3D0x0c0320 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c26 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family USB Enhanced Host C= ontroller' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xf7f07000, size 1024, enabl= ed isab0@pci0:0:31:0: class=3D0x060100 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c46 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D 'P67 Express Chipset LPC Controller' class =3D bridge subclass =3D PCI-ISA ahci1@pci0:0:31:2: class=3D0x010601 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c02 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family 6 port Desktop SATA= AHCI Controller' class =3D mass storage subclass =3D SATA bar [10] =3D type I/O Port, range 32, base 0xf070, size 8, enabled bar [14] =3D type I/O Port, range 32, base 0xf060, size 4, enabled bar [18] =3D type I/O Port, range 32, base 0xf050, size 8, enabled bar [1c] =3D type I/O Port, range 32, base 0xf040, size 4, enabled bar [20] =3D type I/O Port, range 32, base 0xf020, size 32, enabled bar [24] =3D type Memory, range 32, base 0xf7f06000, size 2048, enabl= ed ichsmb0@pci0:0:31:3: class=3D0x0c0500 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c22 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family SMBus Controller' class =3D serial bus subclass =3D SMBus bar [10] =3D type Memory, range 64, base 0xf7f05000, size 256, enable= d bar [20] =3D type I/O Port, range 32, base 0xf000, size 32, enabled vgapci0@pci0:1:0:0: class=3D0x030000 rev=3D0x00 hdr=3D0x00 vendor=3D0x1= 002 device=3D0x68b8 subvendor=3D0x1458 subdevice=3D0x21d7 vendor =3D 'Advanced Micro Devices, Inc. [AMD/ATI]' device =3D 'Juniper XT [Radeon HD 5770]' class =3D display subclass =3D VGA bar [10] =3D type Prefetchable Memory, range 64, base 0xe0000000, siz= e 268435456, enabled bar [18] =3D type Memory, range 64, base 0xf7e20000, size 131072, ena= bled bar [20] =3D type I/O Port, range 32, base 0xe000, size 256, enabled hdac0@pci0:1:0:1: class=3D0x040300 rev=3D0x00 hdr=3D0x00 vendor=3D0x1= 002 device=3D0xaa58 subvendor=3D0x1458 subdevice=3D0xaa58 vendor =3D 'Advanced Micro Devices, Inc. [AMD/ATI]' device =3D 'Juniper HDMI Audio [Radeon HD 5700 Series]' class =3D multimedia subclass =3D HDA bar [10] =3D type Memory, range 64, base 0xf7e40000, size 16384, enab= led ix0@pci0:2:0:0: class=3D0x020000 rev=3D0x01 hdr=3D0x00 vendor=3D0x8086 devi= ce=3D0x10fb subvendor=3D0x8086 subdevice=3D0x000c vendor =3D 'Intel Corporation' device =3D '82599ES 10-Gigabit SFI/SFP+ Network Connection' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 64, base 0xf7880000, size 524288, ena= bled bar [18] =3D type I/O Port, range 32, base 0xd020, size 32, enabled bar [20] =3D type Memory, range 64, base 0xf7904000, size 16384, enab= led ix1@pci0:2:0:1: class=3D0x020000 rev=3D0x01 hdr=3D0x00 vendor=3D0x8086 devi= ce=3D0x10fb subvendor=3D0x8086 subdevice=3D0x000c vendor =3D 'Intel Corporation' device =3D '82599ES 10-Gigabit SFI/SFP+ Network Connection' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 64, base 0xf7780000, size 524288, ena= bled bar [18] =3D type I/O Port, range 32, base 0xd000, size 32, enabled bar [20] =3D type Memory, range 64, base 0xf7900000, size 16384, enab= led mps0@pci0:3:0:0: class=3D0x010700 rev=3D0x02 hdr=3D0x00 vendor=3D0x1= 000 device=3D0x0064 subvendor=3D0x1000 subdevice=3D0x30d0 vendor =3D 'Broadcom / LSI' device =3D 'SAS2116 PCI-Express Fusion-MPT SAS-2 [Meteor]' class =3D mass storage subclass =3D SAS bar [10] =3D type I/O Port, range 32, base 0xc000, size 256, enabled bar [14] =3D type Memory, range 64, base 0xf7dc0000, size 16384, enab= led bar [1c] =3D type Memory, range 64, base 0xf7d80000, size 262144, ena= bled none1@pci0:4:0:0: class=3D0x0c0010 rev=3D0x01 hdr=3D0x00 vendor=3D0x1= 106 device=3D0x3403 subvendor=3D0x1043 subdevice=3D0x8384 vendor =3D 'VIA Technologies, Inc.' device =3D 'VT6315 Series Firewire Controller' class =3D serial bus subclass =3D FireWire bar [10] =3D type Memory, range 64, base 0xf7c00000, size 2048, enabl= ed bar [18] =3D type I/O Port, range 32, base 0xb000, size 256, enabled re0@pci0:5:0:0: class=3D0x020000 rev=3D0x06 hdr=3D0x00 vendor=3D0x10ec devi= ce=3D0x8168 subvendor=3D0x1043 subdevice=3D0x8432 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll= er' class =3D network subclass =3D ethernet bar [10] =3D type I/O Port, range 32, base 0xa000, size 256, enabled bar [18] =3D type Prefetchable Memory, range 64, base 0xf0004000, siz= e 4096, enabled bar [20] =3D type Prefetchable Memory, range 64, base 0xf0000000, siz= e 16384, enabled ahci0@pci0:6:0:0: class=3D0x01018f rev=3D0x12 hdr=3D0x00 vendor=3D0x1= b4b device=3D0x91a0 subvendor=3D0x1043 subdevice=3D0x83ba vendor =3D 'Marvell Technology Group Ltd.' device =3D '88SE912x SATA 6Gb/s Controller [IDE mode]' class =3D mass storage subclass =3D ATA bar [10] =3D type I/O Port, range 32, base 0x9090, size 8, enabled bar [14] =3D type I/O Port, range 32, base 0x9080, size 4, enabled bar [18] =3D type I/O Port, range 32, base 0x9070, size 8, enabled bar [1c] =3D type I/O Port, range 32, base 0x9060, size 4, enabled bar [20] =3D type I/O Port, range 32, base 0x9050, size 16, enabled bar [24] =3D type Memory, range 32, base 0xf7b15000, size 2048, enabl= ed xhci0@pci0:7:0:0: class=3D0x0c0330 rev=3D0x00 hdr=3D0x00 vendor=3D0x1= b21 device=3D0x1042 subvendor=3D0x1043 subdevice=3D0x8488 vendor =3D 'ASMedia Technology Inc.' device =3D 'ASM1042 SuperSpeed USB Host Controller' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 64, base 0xf7a00000, size 32768, enab= led ***** Kernel dumps with -lbvV after ix0 output ***** me/mikej # pciconf -lbvV hostb0@pci0:0:0:0: class=3D0x060000 rev=3D0x09 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x0150 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D 'Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 rev=3D0x09 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x0151 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D 'Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root= Port' class =3D bridge subclass =3D PCI-PCI pcib2@pci0:0:1:1: class=3D0x060400 rev=3D0x09 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x0155 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D 'Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root= Port' class =3D bridge subclass =3D PCI-PCI none0@pci0:0:22:0: class=3D0x078000 rev=3D0x04 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c3a subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family MEI Controller' class =3D simple comms bar [10] =3D type Memory, range 64, base 0xf7f0b000, size 16, enabled ehci0@pci0:0:26:0: class=3D0x0c0320 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c2d subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family USB Enhanced Host C= ontroller' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xf7f08000, size 1024, enabl= ed hdac1@pci0:0:27:0: class=3D0x040300 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c20 subvendor=3D0x1043 subdevice=3D0x8469 vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family High Definition Aud= io Controller' class =3D multimedia subclass =3D HDA bar [10] =3D type Memory, range 64, base 0xf7f00000, size 16384, enab= led pcib3@pci0:0:28:0: class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x1c10 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family PCI Express Root Po= rt 1' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:0:28:4: class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x1c18 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family PCI Express Root Po= rt 5' class =3D bridge subclass =3D PCI-PCI pcib5@pci0:0:28:5: class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x1c1a subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family PCI Express Root Po= rt 6' class =3D bridge subclass =3D PCI-PCI pcib6@pci0:0:28:6: class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x1c1c subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family PCI Express Root Po= rt 7' class =3D bridge subclass =3D PCI-PCI pcib7@pci0:0:28:7: class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8= 086 device=3D0x1c1e subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family PCI Express Root Po= rt 8' class =3D bridge subclass =3D PCI-PCI ehci1@pci0:0:29:0: class=3D0x0c0320 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c26 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family USB Enhanced Host C= ontroller' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xf7f07000, size 1024, enabl= ed isab0@pci0:0:31:0: class=3D0x060100 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c46 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D 'P67 Express Chipset LPC Controller' class =3D bridge subclass =3D PCI-ISA ahci1@pci0:0:31:2: class=3D0x010601 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c02 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family 6 port Desktop SATA= AHCI Controller' class =3D mass storage subclass =3D SATA bar [10] =3D type I/O Port, range 32, base 0xf070, size 8, enabled bar [14] =3D type I/O Port, range 32, base 0xf060, size 4, enabled bar [18] =3D type I/O Port, range 32, base 0xf050, size 8, enabled bar [1c] =3D type I/O Port, range 32, base 0xf040, size 4, enabled bar [20] =3D type I/O Port, range 32, base 0xf020, size 32, enabled bar [24] =3D type Memory, range 32, base 0xf7f06000, size 2048, enabl= ed ichsmb0@pci0:0:31:3: class=3D0x0c0500 rev=3D0x05 hdr=3D0x00 vendor=3D0x8= 086 device=3D0x1c22 subvendor=3D0x1043 subdevice=3D0x844d vendor =3D 'Intel Corporation' device =3D '6 Series/C200 Series Chipset Family SMBus Controller' class =3D serial bus subclass =3D SMBus bar [10] =3D type Memory, range 64, base 0xf7f05000, size 256, enable= d bar [20] =3D type I/O Port, range 32, base 0xf000, size 32, enabled vgapci0@pci0:1:0:0: class=3D0x030000 rev=3D0x00 hdr=3D0x00 vendor=3D0x1= 002 device=3D0x68b8 subvendor=3D0x1458 subdevice=3D0x21d7 vendor =3D 'Advanced Micro Devices, Inc. [AMD/ATI]' device =3D 'Juniper XT [Radeon HD 5770]' class =3D display subclass =3D VGA bar [10] =3D type Prefetchable Memory, range 64, base 0xe0000000, siz= e 268435456, enabled bar [18] =3D type Memory, range 64, base 0xf7e20000, size 131072, ena= bled bar [20] =3D type I/O Port, range 32, base 0xe000, size 256, enabled hdac0@pci0:1:0:1: class=3D0x040300 rev=3D0x00 hdr=3D0x00 vendor=3D0x1= 002 device=3D0xaa58 subvendor=3D0x1458 subdevice=3D0xaa58 vendor =3D 'Advanced Micro Devices, Inc. [AMD/ATI]' device =3D 'Juniper HDMI Audio [Radeon HD 5700 Series]' class =3D multimedia subclass =3D HDA bar [10] =3D type Memory, range 64, base 0xf7e40000, size 16384, enab= led ix0@pci0:2:0:0: class=3D0x020000 rev=3D0x01 hdr=3D0x00 vendor=3D0x8086 devi= ce=3D0x10fb subvendor=3D0x8086 subdevice=3D0x000c vendor =3D 'Intel Corporation' device =3D '82599ES 10-Gigabit SFI/SFP+ Network Connection' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 64, base 0xf7880000, size 524288, ena= bled bar [18] =3D type I/O Port, range 32, base 0xd020, size 32, enabled bar [20] =3D type Memory, range 64, base 0xf7904000, size 16384, enab= led CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4000 or notify us at: PAI, Dept. 99, 2101 High Wickham Place, Suite 101, Louisville, KY 40245 Disclaimer The information contained in this communication from the sender is confiden= tial. It is intended solely for use by the recipient and others authorized = to receive it. If you are not the recipient, you are hereby notified that a= ny disclosure, copying, distribution or taking action in relation of the co= ntents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been auto= matically archived by Mimecast, a leader in email security and cyber resili= ence. Mimecast integrates email defenses with brand protection, security aw= areness training, web security, compliance and other essential capabilities= . Mimecast helps protect large and small organizations from malicious activ= ity, human error and technology failure; and to lead the movement toward bu= ilding a more resilient world. To find out more, visit our website. --_000_2ae728c8634e44b391e23764aa2ca5e8MAILHUBpailocal_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <= /head>

Hi:

 

Here are the kernel.full files some o= f you asked for.  Let me know what else

may be helpful to test.

 

Thanks!

 

Michael Jung

 

Notes below ***** (UPD= ATED)

 

***** Started fresh

 

Installed FreeBSD-14.0= -CURRENT-amd64-20220113-0910a41ef3b-252413-disc1.iso

with its accompany sou= rce tree. Built kernel/world, installed them, rebooted and

 

http://mail.mikej.com/core.txt.0

http://mail.mikej.com/info.0

http://mail.mikej.com/kernel.full.0

http://mail.mikej.com/vmcore.0

 

***** I deleted all co= ntents from /usr/obj built fresh /usr/src via git to b6724f7004c and

 

14.0-CURRENT FreeBSD 1= 4.0-CURRENT #1 main-n252997-b6724f7004c

 

http://mail.mikej.com/core.txt.1

http://mail.mikej.com/info.1

http://mail.mikej.com/kernel.full.1

http://mail.mikej.com/vmcore.1

 

 

***** It's the '-V' sw= itch that triggers the panic

***** I did note that = pciconf does not identify my CPU correctly (see below)

***** The panic always= occurs after ix0 output from pciconf –lbvV (see below)

   &nbs= p;        ix1 has always followed next w= ith –lbv – it has never been present with –lbvV

*****  Switching the LSI 9208-16= E and Intel dual port X520 PCI slots did not help

*****   ixl1 definitely wor= ks using the exact same SPF+ adapter and cable

*****   Removing the Intel = X520 82599ES allow pciconf –lbvV to run

*****   I have a single port ver= sion of this intel X520 which works

 

It seem to me, that when pciconf iter= ates to ix1@pci0:2:0:1 the problem always occurs.<= /span>

 

I build like this:

 

nice make -WITH_META_M= ODE -DFAST_DEPEND -DWITHOUT_CLEAN -sj12 buildworld

nice make -WITH_META_M= ODE -DFAST_DEPEND -DWITHOUT_CLEAN -sj12 buildkernel

 

root@draid:/var/crash = # cat /etc/make.conf

WITH_CCACHE_BUILD=3Dye= s

CCACHE_DIR=3D/root/.cc= ache

root@draid:/var/crash =

 

There is no src.conf o= r sysctl.conf and I have only added '"filemon_load=3D"YES"'<= o:p>

to /boot/loader.conf

 

 

 

***** I did Note that = pciconf does not identify my CPU correctly

 

It is actually an Inte= l Core i7-3770K – a sample programs in ports that gets it<= /span>

right is sysutils/cpuf= etch.

 

 

 

***** Here is “-= vlb”

 

 

root@draid:/home/mikej= # pciconf -vlb

 

pciconf –lvb<= /p>

hostb0@pci0:0:0:0:   &= nbsp;  class=3D0x060000 rev=3D0x09 hdr=3D0x00 vendor=3D0x8086 device= =3D0x0150 subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D 'Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller'

    class  &= nbsp;   =3D bridge

    subclass &nbs= p; =3D HOST-PCI

pcib1@pci0:0:1:0:   &n= bsp;   class=3D0x060400 rev=3D0x09 hdr=3D0x01 vendor=3D0x8086 dev= ice=3D0x0151 subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D 'Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root P= ort'

    class  &= nbsp;   =3D bridge

    subclass &nbs= p; =3D PCI-PCI

pcib2@pci0:0:1:1:   &n= bsp;   class=3D0x060400 rev=3D0x09 hdr=3D0x01 vendor=3D0x8086 dev= ice=3D0x0155 subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D 'Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root P= ort'

    class  &= nbsp;   =3D bridge

    subclass &nbs= p; =3D PCI-PCI

none0@pci0:0:22:0:   &= nbsp;  class=3D0x078000 rev=3D0x04 hdr=3D0x00 vendor=3D0x8086 device= =3D0x1c3a subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '6 Series/C200 Series Chipset Family MEI Controller'<= /o:p>

    class  &= nbsp;   =3D simple comms

    bar   [1= 0] =3D type Memory, range 64, base 0xf7f0b000, size 16, enabled<= /span>

ehci0@pci0:0:26:0:   &= nbsp;  class=3D0x0c0320 rev=3D0x05 hdr=3D0x00 vendor=3D0x8086 device= =3D0x1c2d subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '6 Series/C200 Series Chipset Family USB Enhanced Host Con= troller'

    class  &= nbsp;   =3D serial bus

    subclass &nbs= p; =3D USB

    bar   [1= 0] =3D type Memory, range 32, base 0xf7f08000, size 1024, enabled

hdac1@pci0:0:27:0:   &= nbsp;  class=3D0x040300 rev=3D0x05 hdr=3D0x00 vendor=3D0x8086 device= =3D0x1c20 subvendor=3D0x1043 subdevice=3D0x8469

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '6 Series/C200 Series Chipset Family High Definition Audio= Controller'

    class  &= nbsp;   =3D multimedia

    subclass &nbs= p; =3D HDA

    bar   [1= 0] =3D type Memory, range 64, base 0xf7f00000, size 16384, enabled

pcib3@pci0:0:28:0:   &= nbsp;  class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8086 device= =3D0x1c10 subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '6 Series/C200 Series Chipset Family PCI Express Root Port= 1'

    class  &= nbsp;   =3D bridge

    subclass &nbs= p; =3D PCI-PCI

pcib4@pci0:0:28:4:   &= nbsp;  class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8086 device= =3D0x1c18 subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '6 Series/C200 Series Chipset Family PCI Express Root Port= 5'

    class  &= nbsp;   =3D bridge

    subclass &nbs= p; =3D PCI-PCI

pcib5@pci0:0:28:5:   &= nbsp;  class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8086 device= =3D0x1c1a subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '6 Series/C200 Series Chipset Family PCI Express Root Port= 6'

    class  &= nbsp;   =3D bridge

    subclass &nbs= p; =3D PCI-PCI

pcib6@pci0:0:28:6:   &= nbsp;  class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8086 device= =3D0x1c1c subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '6 Series/C200 Series Chipset Family PCI Express Root Port= 7'

    class  &= nbsp;   =3D bridge

    subclass &nbs= p; =3D PCI-PCI

pcib7@pci0:0:28:7:   &= nbsp;  class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D0x8086 device= =3D0x1c1e subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '6 Series/C200 Series Chipset Family PCI Express Root Port= 8'

    class  &= nbsp;   =3D bridge

    subclass &nbs= p; =3D PCI-PCI

ehci1@pci0:0:29:0:   &= nbsp;  class=3D0x0c0320 rev=3D0x05 hdr=3D0x00 vendor=3D0x8086 device= =3D0x1c26 subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '6 Series/C200 Series Chipset Family USB Enhanced Host Con= troller'

    class  &= nbsp;   =3D serial bus

    subclass &nbs= p; =3D USB

    bar   [1= 0] =3D type Memory, range 32, base 0xf7f07000, size 1024, enabled

isab0@pci0:0:31:0:   &= nbsp;  class=3D0x060100 rev=3D0x05 hdr=3D0x00 vendor=3D0x8086 device= =3D0x1c46 subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D 'P67 Express Chipset LPC Controller'

    class  &= nbsp;   =3D bridge

    subclass  &nb= sp;=3D PCI-ISA

ahci1@pci0:0:31:2:   &= nbsp;  class=3D0x010601 rev=3D0x05 hdr=3D0x00 vendor=3D0x8086 device= =3D0x1c02 subvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '6 Series/C200 Series Chipset Family 6 port Desktop SATA A= HCI Controller'

    class  &= nbsp;   =3D mass storage

    subclass &nbs= p; =3D SATA

    bar   [1= 0] =3D type I/O Port, range 32, base 0xf070, size 8, enabled

    bar   [1= 4] =3D type I/O Port, range 32, base 0xf060, size 4, enabled

    bar   [1= 8] =3D type I/O Port, range 32, base 0xf050, size 8, enabled

    bar   [1= c] =3D type I/O Port, range 32, base 0xf040, size 4, enabled

    bar   [2= 0] =3D type I/O Port, range 32, base 0xf020, size 32, enabled

    bar   [2= 4] =3D type Memory, range 32, base 0xf7f06000, size 2048, enabled

ichsmb0@pci0:0:31:3:   = ; class=3D0x0c0500 rev=3D0x05 hdr=3D0x00 vendor=3D0x8086 device=3D0x1c22 su= bvendor=3D0x1043 subdevice=3D0x844d

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '6 Series/C200 Series Chipset Family SMBus Controller'

    class  &= nbsp;   =3D serial bus

    subclass &nbs= p; =3D SMBus

    bar   [1= 0] =3D type Memory, range 64, base 0xf7f05000, size 256, enabled=

    bar   [2= 0] =3D type I/O Port, range 32, base 0xf000, size 32, enabled

vgapci0@pci0:1:0:0:   =   class=3D0x030000 rev=3D0x00 hdr=3D0x00 vendor=3D0x1002 device=3D0x68= b8 subvendor=3D0x1458 subdevice=3D0x21d7

    vendor  =    =3D 'Advanced Micro Devices, Inc. [AMD/ATI]'=

    device  =    =3D 'Juniper XT [Radeon HD 5770]'

    class  &= nbsp;   =3D display

    subclass &nbs= p; =3D VGA

    bar   [1= 0] =3D type Prefetchable Memory, range 64, base 0xe0000000, size 268435456,= enabled

    bar   [1= 8] =3D type Memory, range 64, base 0xf7e20000, size 131072, enabled

    bar   [2= 0] =3D type I/O Port, range 32, base 0xe000, size 256, enabled

hdac0@pci0:1:0:1:   &n= bsp;   class=3D0x040300 rev=3D0x00 hdr=3D0x00 vendor=3D0x1002 dev= ice=3D0xaa58 subvendor=3D0x1458 subdevice=3D0xaa58

    vendor  =    =3D 'Advanced Micro Devices, Inc. [AMD/ATI]'=

    device  =    =3D 'Juniper HDMI Audio [Radeon HD 5700 Series]'

    class  &= nbsp;   =3D multimedia

    subclass &nbs= p; =3D HDA

    bar   [1= 0] =3D type Memory, range 64, base 0xf7e40000, size 16384, enabled

ix0@pci0:2:0:0: class=3D0x020000 rev= =3D0x01 hdr=3D0x00 vendor=3D0x8086 device=3D0x10fb subvendor=3D0x8086 subde= vice=3D0x000c

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '82599ES 10-Gigabit SFI/SFP+ Network Connection'<= /o:p>

    class  &= nbsp;   =3D network

    subclass &nbs= p; =3D ethernet

    bar   [1= 0] =3D type Memory, range 64, base 0xf7880000, size 524288, enabled

    bar   [1= 8] =3D type I/O Port, range 32, base 0xd020, size 32, enabled

    bar   [2= 0] =3D type Memory, range 64, base 0xf7904000, size 16384, enabled

ix1@pci0:2:0:1: class=3D0x020000 rev= =3D0x01 hdr=3D0x00 vendor=3D0x8086 device=3D0x10fb subvendor=3D0x8086 subde= vice=3D0x000c

    vendor  =    =3D 'Intel Corporation'

    device  =    =3D '82599ES 10-Gigabit SFI/SFP+ Network Connection'<= /o:p>

    class  &= nbsp;   =3D network

    subclass &nbs= p; =3D ethernet

    bar   [1= 0] =3D type Memory, range 64, base 0xf7780000, size 524288, enabled

    bar   [1= 8] =3D type I/O Port, range 32, base 0xd000, size 32, enabled

    bar   [2= 0] =3D type Memory, range 64, base 0xf7900000, size 16384, enabled

mps0@pci0:3:0:0:   &nb= sp;    class=3D0x010700 rev=3D0x02 hdr=3D0x00 vendor=3D0x100= 0 device=3D0x0064 subvendor=3D0x1000 subdevice=3D0x30d0

    vendor  =    =3D 'Broadcom / LSI'

    device  =    =3D 'SAS2116 PCI-Express Fusion-MPT SAS-2 [Meteor]'=

    class  &= nbsp;   =3D mass storage

    subclass &nbs= p; =3D SAS

    bar   [1= 0] =3D type I/O Port, range 32, base 0xc000, size 256, enabled

    bar   [1= 4] =3D type Memory, range 64, base 0xf7dc0000, size 16384, enabled

    bar   [1= c] =3D type Memory, range 64, base 0xf7d80000, size 262144, enabled

none1@pci0:4:0:0:   &n= bsp;   class=3D0x0c0010 rev=3D0x01 hdr=3D0x00 vendor=3D0x1106 dev= ice=3D0x3403 subvendor=3D0x1043 subdevice=3D0x8384

    vendor  =    =3D 'VIA Technologies, Inc.'

    device  =    =3D 'VT6315 Series Firewire Controller'

    class  &= nbsp;   =3D serial bus

    subclass &nbs= p; =3D FireWire

    bar   [1= 0] =3D type Memory, range 64, base 0xf7c00000, size 2048, enabled

    bar   [1= 8] =3D type I/O Port, range 32, base 0xb000, size 256, enabled

re0@pci0:5:0:0: class=3D0x020000 rev= =3D0x06 hdr=3D0x00 vendor=3D0x10ec device=3D0x8168 subvendor=3D0x1043 subde= vice=3D0x8432

    vendor  =    =3D 'Realtek Semiconductor Co., Ltd.'

    device  =    =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller= '

    class  &= nbsp;   =3D network

    subclass &nbs= p; =3D ethernet

    bar   [1= 0] =3D type I/O Port, range 32, base 0xa000, size 256, enabled

    bar   [1= 8] =3D type Prefetchable Memory, range 64, base 0xf0004000, size 4096, enab= led

    bar   [2= 0] =3D type Prefetchable Memory, range 64, base 0xf0000000, size 16384, ena= bled

ahci0@pci0:6:0:0:   &n= bsp;   class=3D0x01018f rev=3D0x12 hdr=3D0x00 vendor=3D0x1b4b dev= ice=3D0x91a0 subvendor=3D0x1043 subdevice=3D0x83ba

    vendor  =    =3D 'Marvell Technology Group Ltd.'

    device  =    =3D '88SE912x SATA 6Gb/s Controller [IDE mode]'

    class  &= nbsp;   =3D mass storage

   subclass  = ; =3D ATA

    bar   [1= 0] =3D type I/O Port, range 32, base 0x9090, size 8, enabled

    bar   [1= 4] =3D type I/O Port, range 32, base 0x9080, size 4, enabled

    bar   [1= 8] =3D type I/O Port, range 32, base 0x9070, size 8, enabled

    bar   [1= c] =3D type I/O Port, range 32, base 0x9060, size 4, enabled

    bar   [2= 0] =3D type I/O Port, range 32, base 0x9050, size 16, enabled

    bar   [2= 4] =3D type Memory, range 32, base 0xf7b15000, size 2048, enabled

xhci0@pci0:7:0:0:   &n= bsp;   class=3D0x0c0330 rev=3D0x00 hdr=3D0x00 vendor=3D0x1b21 dev= ice=3D0x1042 subvendor=3D0x1043 subdevice=3D0x8488

    vendor  =    =3D 'ASMedia Technology Inc.'

    device  =    =3D 'ASM1042 SuperSpeed USB Host Controller'=

    class  &= nbsp;   =3D serial bus

    subclass &nbs= p; =3D USB

    bar   [1= 0] =3D type Memory, range 64, base 0xf7a00000, size 32768, enabled

 

 

 

***** Kernel dumps with –lbvV after ix0 output *****<= /span>

 

me/mikej # pciconf = 211;lbvV

hostb0@pci0:0:0:0:&nbs= p;     class=3D0x060000 rev=3D0x09 hdr=3D0x00 vendor=3D= 0x8086 device=3D0x0150 subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D 'Xeon E3-1200 v2/3rd Gen Core processor DRA= M Controller'

    cla= ss      =3D bridge

    sub= class   =3D HOST-PCI

pcib1@pci0:0:1:0: = ;      class=3D0x060400 rev=3D0x09 hdr=3D0x01 vend= or=3D0x8086 device=3D0x0151 subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D 'Xeon E3-1200 v2/3rd Gen Core processor PCI= Express Root Port'

    cla= ss      =3D bridge

    sub= class   =3D PCI-PCI

pcib2@pci0:0:1:1: = ;      class=3D0x060400 rev=3D0x09 hdr=3D0x01 vend= or=3D0x8086 device=3D0x0155 subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D 'Xeon E3-1200 v2/3rd Gen Core processor PCI= Express Root Port'

    cla= ss      =3D bridge

    sub= class   =3D PCI-PCI

none0@pci0:0:22:0:&nbs= p;     class=3D0x078000 rev=3D0x04 hdr=3D0x00 vendor=3D= 0x8086 device=3D0x1c3a subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '6 Series/C200 Series Chipset Family MEI Co= ntroller'

    cla= ss      =3D simple comms

    bar=    [10] =3D type Memory, range 64, base 0xf7f0b000, size 16, enab= led

ehci0@pci0:0:26:0:&nbs= p;     class=3D0x0c0320 rev=3D0x05 hdr=3D0x00 vendor=3D= 0x8086 device=3D0x1c2d subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '6 Series/C200 Series Chipset Family USB En= hanced Host Controller'

    cla= ss      =3D serial bus

    sub= class   =3D USB

    bar=    [10] =3D type Memory, range 32, base 0xf7f08000, size 1024, en= abled

hdac1@pci0:0:27:0:&nbs= p;     class=3D0x040300 rev=3D0x05 hdr=3D0x00 vendor=3D= 0x8086 device=3D0x1c20 subvendor=3D0x1043 subdevice=3D0x8469

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '6 Series/C200 Series Chipset Family High D= efinition Audio Controller'

    cla= ss      =3D multimedia

    sub= class   =3D HDA

    bar=    [10] =3D type Memory, range 64, base 0xf7f00000, size 16384, e= nabled

pcib3@pci0:0:28:0:&nbs= p;     class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D= 0x8086 device=3D0x1c10 subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '6 Series/C200 Series Chipset Family PCI Ex= press Root Port 1'

    cla= ss      =3D bridge

    sub= class   =3D PCI-PCI

pcib4@pci0:0:28:4:&nbs= p;     class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D= 0x8086 device=3D0x1c18 subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '6 Series/C200 Series Chipset Family PCI Ex= press Root Port 5'

    cla= ss      =3D bridge

    sub= class   =3D PCI-PCI

pcib5@pci0:0:28:5:&nbs= p;     class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D= 0x8086 device=3D0x1c1a subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '6 Series/C200 Series Chipset Family PCI Ex= press Root Port 6'

    cla= ss      =3D bridge

    sub= class   =3D PCI-PCI

pcib6@pci0:0:28:6:&nbs= p;     class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D= 0x8086 device=3D0x1c1c subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '6 Series/C200 Series Chipset Family PCI Ex= press Root Port 7'

    cla= ss      =3D bridge

    sub= class   =3D PCI-PCI

pcib7@pci0:0:28:7:&nbs= p;     class=3D0x060400 rev=3D0xb5 hdr=3D0x01 vendor=3D= 0x8086 device=3D0x1c1e subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '6 Series/C200 Series Chipset Family PCI Ex= press Root Port 8'

    cla= ss      =3D bridge

    sub= class   =3D PCI-PCI

ehci1@pci0:0:29:0:&nbs= p;     class=3D0x0c0320 rev=3D0x05 hdr=3D0x00 vendor=3D= 0x8086 device=3D0x1c26 subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '6 Series/C200 Series Chipset Family USB En= hanced Host Controller'

    cla= ss      =3D serial bus

    sub= class   =3D USB

    bar=    [10] =3D type Memory, range 32, base 0xf7f07000, size 1024, en= abled

isab0@pci0:0:31:0:&nbs= p;     class=3D0x060100 rev=3D0x05 hdr=3D0x00 vendor=3D= 0x8086 device=3D0x1c46 subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D 'P67 Express Chipset LPC Controller'

    cla= ss      =3D bridge

    sub= class   =3D PCI-ISA

ahci1@pci0:0:31:2:&nbs= p;     class=3D0x010601 rev=3D0x05 hdr=3D0x00 vendor=3D= 0x8086 device=3D0x1c02 subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '6 Series/C200 Series Chipset Family 6 port= Desktop SATA AHCI Controller'

    cla= ss      =3D mass storage

    sub= class   =3D SATA

    bar=    [10] =3D type I/O Port, range 32, base 0xf070, size 8, enabled=

    bar=    [14] =3D type I/O Port, range 32, base 0xf060, size 4, enabled=

    bar=    [18] =3D type I/O Port, range 32, base 0xf050, size 8, enabled=

    bar=    [1c] =3D type I/O Port, range 32, base 0xf040, size 4, enabled=

    bar=    [20] =3D type I/O Port, range 32, base 0xf020, size 32, enable= d

    bar=    [24] =3D type Memory, range 32, base 0xf7f06000, size 2048, en= abled

ichsmb0@pci0:0:31:3:&n= bsp;   class=3D0x0c0500 rev=3D0x05 hdr=3D0x00 vendor=3D0x8086 dev= ice=3D0x1c22 subvendor=3D0x1043 subdevice=3D0x844d

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '6 Series/C200 Series Chipset Family SMBus = Controller'

    cla= ss      =3D serial bus

    sub= class   =3D SMBus

    bar=    [10] =3D type Memory, range 64, base 0xf7f05000, size 256, ena= bled

    bar=    [20] =3D type I/O Port, range 32, base 0xf000, size 32, enable= d

vgapci0@pci0:1:0:0:&nb= sp;    class=3D0x030000 rev=3D0x00 hdr=3D0x00 vendor=3D0x100= 2 device=3D0x68b8 subvendor=3D0x1458 subdevice=3D0x21d7

    ven= dor     =3D 'Advanced Micro Devices, Inc. [AMD/ATI]'

    dev= ice     =3D 'Juniper XT [Radeon HD 5770]'

    cla= ss      =3D display

    sub= class   =3D VGA

    bar=    [10] =3D type Prefetchable Memory, range 64, base 0xe0000000, = size 268435456, enabled

    bar=    [18] =3D type Memory, range 64, base 0xf7e20000, size 131072, = enabled

    bar=    [20] =3D type I/O Port, range 32, base 0xe000, size 256, enabl= ed

hdac0@pci0:1:0:1: = ;      class=3D0x040300 rev=3D0x00 hdr=3D0x00 vend= or=3D0x1002 device=3D0xaa58 subvendor=3D0x1458 subdevice=3D0xaa58

    ven= dor     =3D 'Advanced Micro Devices, Inc. [AMD/ATI]'

    dev= ice     =3D 'Juniper HDMI Audio [Radeon HD 5700 Series]= '

    cla= ss      =3D multimedia

    sub= class   =3D HDA

    bar=    [10] =3D type Memory, range 64, base 0xf7e40000, size 16384, e= nabled

ix0@pci0:2:0:0: class= =3D0x020000 rev=3D0x01 hdr=3D0x00 vendor=3D0x8086 device=3D0x10fb subvendor= =3D0x8086 subdevice=3D0x000c

    ven= dor     =3D 'Intel Corporation'

    dev= ice     =3D '82599ES 10-Gigabit SFI/SFP+ Network Co= nnection'

    cla= ss      =3D network

    sub= class   =3D ethernet

    bar=    [10] =3D type Memory, range 64, base 0xf7880000, size 524288, = enabled

    bar=    [18] =3D type I/O Port, range 32, base 0xd020, size 32, enable= d

    bar=    [20] =3D type Memory, range 64, base 0xf7904000, size 16384, e= nabled

 

 

 

 

 

 

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245





<= b>Disclaimer

The information contained in this communication from the sender i= s confidential. It is intended solely for use by the recipient and others a= uthorized to receive it. If you are not the recipient, you are hereby notif= ied that any disclosure, copying, distribution or taking action in relation= of the contents of this information is strictly prohibited and may be unla= wful.

This email has been scanned for viruses and malware, and may h= ave been automatically archived by Mimecast, a leader in email security and= cyber resilience. Mimecast integrates email defenses with brand protection= , security awareness training, web security, compliance and other essential= capabilities. Mimecast helps protect large and small organizations from ma= licious activity, human error and technology failure; and to lead the movem= ent toward building a more resilient world. To find out more, visit our web= site.

--_000_2ae728c8634e44b391e23764aa2ca5e8MAILHUBpailocal_-- From nobody Mon Feb 7 07:50:52 2022 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 1B70919BFF51 for ; Mon, 7 Feb 2022 07:51:00 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsdcM2SrPz4X7g for ; Mon, 7 Feb 2022 07:50:59 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ua1-x932.google.com with SMTP id d22so3103198uaw.2 for ; Sun, 06 Feb 2022 23:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=9+8EwT+TN9baWV9qi98szI4CuFWUlRQoO3rBLZ69kTw=; b=Z9JSVWh/tLEDZAoTqijxxAqQgMTkPOlol7ltQzGRH2vowYgkwCRfhD9HWEdbgbPlK7 sZPTIxoij4nKgZ/NliTi9jT9OxwUAWdBgSDTy1OylLASlAPVKnB1RO3yu4b/cx28dzFW nUhoxWbk6xQrRc1eqG18Hg3HgVHXfRC75nTz0QJaGUKuqHM1fsry5Oo8ZAut7Ca/9mJ7 cLT4cvBS5ioi3YExJ61XlEKCtZ9xXiaxDOZIXB1hM2IIert9NFdGA2HxYEdM1G7wzLbS Azt8st+TQuRAZIzc2AqO5Fw3jP+Mmzz8c2X8PS3d9m5yRljmxXffmZtBw34jEFZEuahz ZnSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=9+8EwT+TN9baWV9qi98szI4CuFWUlRQoO3rBLZ69kTw=; b=P6bWVzYm5wVTirTnye5bzZ8ZVHZEeGJP57bWmhGmv9B7A47Y29iSGRHMbeEFePMK6Q kxdKLBwAnLtyHqMyr6rTQEGNLjLC7nYl+TxBBr2ymSImLfduakXvRhl0yzKTw9JDtLH+ DtbNmNDA+2S8Y7PxZvdR866xT4UA8pRWRHDwaxx8ner4Aj7txaC7aPgGHCCpcSZqnSXT EUoPpCOaDOeSeRHAo3PlZlv4ISiTIufqLiBkKlEuLh3JdlZb3r4kewJGjh6MoH0iZ/Jd HQFAFIb61VoahXvaH59etAD3eBC1Nhe/TAWVyNTYfbRr0hIe4KMJsVnLRq1cdI+/KsjC QC/A== X-Gm-Message-State: AOAM532E94MQb0jWX4NEVe3qVLgZ3raOgnXq4RNIm26p5pULu0wlhJBF f1ZaY0YO9JvxgkHw7zcqmintbouZX3nOlh6s40XK36PEuUZARQCn X-Google-Smtp-Source: ABdhPJzyfF2R2Km07QsVtPOncwaNv7DhDbxh2JGnxLIdNy5XM/EWbRBmZWdQ5BDXmNkcoHQ81D0CXU9UlIuQLPzMGrs= X-Received: by 2002:a67:ee01:: with SMTP id f1mr4167601vsp.0.1644220252725; Sun, 06 Feb 2022 23:50:52 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:a59:aca4:0:b0:28a:7e2e:6c8c with HTTP; Sun, 6 Feb 2022 23:50:52 -0800 (PST) In-Reply-To: References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> From: grarpamp Date: Mon, 7 Feb 2022 02:50:52 -0500 Message-ID: Subject: Re: USB Disk Stalls on -current To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JsdcM2SrPz4X7g X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="Z9JSVWh/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::932 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.992]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::932:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Yes, some USB hw is very flaky, but ZFS can work great on these... https://www.youtube.com/watch?v=7z526m1jvls https://www.youtube.com/watch?v=dougISKs2vQ https://vimeo.com/13758987 https://www.youtube.com/watch?v=1zIoK_9UzHk From nobody Mon Feb 7 07:57:47 2022 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 7FE3D19C4538 for ; Mon, 7 Feb 2022 07:57:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsdmQ2M2gz4bPQ for ; Mon, 7 Feb 2022 07:57:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x930.google.com with SMTP id u77so7622961uau.6 for ; Sun, 06 Feb 2022 23:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EH06ykj08UDiihr5C6xwt8TNV+6F/yceTv5QRHitwQQ=; b=76ELQ1r3RiJDopIaPq6NmXaQhbZLe9aewvVPmQYFAbd/7r1MlRBliJpKiQyw/g2IjE bP82MSPYYDpvCcf2lNeY7V0XWQNR8IYzmOOHr4jsUCphKc+V+S1OqbZZEMHZv3CWJ/cD UrQGGSvAVC7V4nnv683qMab4FfZUWK3tYgMqTcmXyTUMYZfLkDac4wpSdWwf27jRCgeh J4fU6FUJ4TascS0ek30j7B9Oa3Su7UGAVr1gH0CQHmspjIl7DE1J2/AFn1S0CJBHMQKY ACOXDXn4xEyuJQpKKGMLI2LKuFlYS7SMTQoqZ68fe3gBTCNk02OIN5T0Tw/psGBuaoF8 i/QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EH06ykj08UDiihr5C6xwt8TNV+6F/yceTv5QRHitwQQ=; b=F3yR3SYbXr4xeW2QrgEj8+4T+ubaxWhZJEkBCEZmyt3vWWcmRCZPKHjDS+Lw4luIf2 E+5hv3dUmqelHuWEyVXyIi7riCfQ7IrwK48mtAGNzOg8+lCJ9ZaqZYZiBCxULLh9Er62 D0eocEHMcTDASyYr6Hdn5HtwYsTZhuiPKxo0vKucFXAs0SBk2SrYLlAHUBd/Y2goaQiH J1aXi4npWSEbPOUmHE+N3CrqEaR/uz38UMT555cTy2aDolAhyzAzQh0lj+mzpD8CJdb9 cHzwj9NKf942Wn50+DvD9Y+CCXG3KINIKT+kY+79e7WVuLDhSsTC2aqE2jV69JwPFJ5o DOtg== X-Gm-Message-State: AOAM531PYKNp/ne86udwsPywrgbUhilDjhLxl0RgYKoWPg90Y3MqOR3z HctJlpAy64X4fOmsmZKrUl47BtDUTa1x3Pr9pCdnggbNamY= X-Google-Smtp-Source: ABdhPJw6UsNm2algh7jPhDHxM0AWiYIrQqkeLBFMQLyjCR+u4rDNuveuZQPN3yGUSdSCSoGFTjO5/Te+UDuj8j9Gp+g= X-Received: by 2002:a67:dd17:: with SMTP id y23mr3498337vsj.77.1644220677672; Sun, 06 Feb 2022 23:57:57 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> In-Reply-To: From: Warner Losh Date: Mon, 7 Feb 2022 00:57:47 -0700 Message-ID: Subject: Re: USB Disk Stalls on -current To: grarpamp Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000006cef6605d768f570" X-Rspamd-Queue-Id: 4JsdmQ2M2gz4bPQ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=76ELQ1r3; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::930) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.23 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::930:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.77)[0.768]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000006cef6605d768f570 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 7, 2022, 12:51 AM grarpamp wrote: > Yes, some USB hw is very flaky, > but ZFS can work great on these... > > https://www.youtube.com/watch?v=7z526m1jvls > https://www.youtube.com/watch?v=dougISKs2vQ > https://vimeo.com/13758987 > https://www.youtube.com/watch?v=1zIoK_9UzHk Doesn't help the performance hiccups though. If you are waiting for a drive to spin up or come out of power save mode or a USB interface chip to reset, the filesystem isn't going to matter. ZFS does a good job recovering in the face of this, but it's not without a performance hit. Warner --0000000000006cef6605d768f570 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Doesn't help the performance hiccups though. If you are waiting for a = drive to spin up or come out of power save mode or a USB interface chip to = reset, the filesystem isn't going to matter.
ZFS does a good job recovering in the face of this= , but it's not without a performance hit.

Warner
--0000000000006cef6605d768f570-- From nobody Mon Feb 7 09:17:21 2022 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 986EB19ABDE5 for ; Mon, 7 Feb 2022 09:17:33 +0000 (UTC) (envelope-from fm-7517-20220207091721352dbaae5a40447075-P2uVNd@rts-flowmailer.siemens.com) Received: from mta-64-226.siemens.flowmailer.net (mta-64-226.siemens.flowmailer.net [185.136.64.226]) (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 4JsgXC1BYfz3Lml for ; Mon, 7 Feb 2022 09:17:31 +0000 (UTC) (envelope-from fm-7517-20220207091721352dbaae5a40447075-P2uVNd@rts-flowmailer.siemens.com) Received: by mta-64-226.siemens.flowmailer.net with ESMTPSA id 20220207091721352dbaae5a40447075 for ; Mon, 07 Feb 2022 10:17:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm1; d=siemens.com; i=michael.osipov@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:References:In-Reply-To; bh=4RdxwoOb/eT5oqLSnXbNu6Uk9Xbafk4PwTMHppLgXoI=; b=dWlUpBaJS2DbHIlXJPKS6BbIbz7aDAGnxJVzVPNCd2L1jiGcCsYzaD9gDNub/lUOWByeQz lkog8O+vBsqgISETeTb8b2ISyZmLbd9LBsVOWDsI5hW7v1y8AwEPbU+sGjClfDBFPCv5OsOL lds8Iz+w4coagHPGGtC28PeGdRaLI=; Message-ID: Date: Mon, 7 Feb 2022 10:17:21 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Subject: Re: Dragonfly Mail Agent (dma) in the base system Content-Language: de-DE To: freebsd-current@freebsd.org References: <835dc887-6491-602c-7d71-d99309871126@siemens.com> <20220205141300.C19D2149@slippy.cwsent.com> <202202061553.216Fr0Yt071775@donotpassgo.dyslexicfish.net> <20220206161102.D8114111@slippy.cwsent.com> <202202062216.216MGQgQ005757@donotpassgo.dyslexicfish.net> From: michael.osipov@siemens.com In-Reply-To: <202202062216.216MGQgQ005757@donotpassgo.dyslexicfish.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-7517:519-21489:flowmailer X-Rspamd-Queue-Id: 4JsgXC1BYfz3Lml X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=siemens.com header.s=fm1 header.b=dWlUpBaJ; dmarc=pass (policy=none) header.from=siemens.com; spf=pass (mx1.freebsd.org: domain of fm-7517-20220207091721352dbaae5a40447075-P2uVNd@rts-flowmailer.siemens.com designates 185.136.64.226 as permitted sender) smtp.mailfrom=fm-7517-20220207091721352dbaae5a40447075-P2uVNd@rts-flowmailer.siemens.com X-Spamd-Result: default: False [-5.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[siemens.com:s=fm1]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_MED(-2.00)[siemens.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.136.64.224/29]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[siemens.com:+]; DMARC_POLICY_ALLOW(-0.50)[siemens.com,none]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[185.136.64.226:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[michael.osipov@siemens.com,fm-7517-20220207091721352dbaae5a40447075-P2uVNd@rts-flowmailer.siemens.com]; MIME_TRACE(0.00)[0:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; ASN(0.00)[asn:50018, ipnet:185.136.64.0/24, country:NL]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[michael.osipov@siemens.com,fm-7517-20220207091721352dbaae5a40447075-P2uVNd@rts-flowmailer.siemens.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Am 2022-02-06 um 23:16 schrieb Jamie Landeg-Jones: > Cy Schubert wrote: > >> In message <202202061553.216Fr0Yt071775@donotpassgo.dyslexicfish.net>, >> Jamie La >> ndeg-Jones writes: >>> Cy Schubert wrote: >>> >>>> dma doesn't support SMTP submission, we may need to review various port >>>> default options or whether ports even support it. >>> >>> Good catch. >> >> You misquoted me. Read my email again! > > Sorry, I read it again, but it still looks to me as "some ports only work via > SMTP submission, so they will need to be looked at." > > I suggested an alternative of instead, "emulating" the SMTP submission > functionality (but maybe in a better way that my suggested hack, though) > > After all, it isn't just ports - there could be other third party stuff > that only works via submission too. It is not that easy just too look at ports. I give you three examples from work: 1. Zabbix (network monitoring), suppports only SMTP, although PHP supports sendmail(8) 2. JavaMail Transport implementation exists only for SMTP, I was not able to find any transport implementation for sendmail(8). Maybe I will write one for fun. 3. Python mail package supports SMTP only, no other package available, at least AFAIK. Unless ecosystems provide impls for sendmail(8) I see it very hard to live without localhost:25 for many cases. Michael From nobody Mon Feb 7 12:02:11 2022 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 9809F19C6128 for ; Mon, 7 Feb 2022 12:02:27 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4JslBQ4BSjz3khh; Mon, 7 Feb 2022 12:02:22 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 217C2B0V071883; Mon, 7 Feb 2022 12:02:12 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 217C2BLZ071882; Mon, 7 Feb 2022 12:02:11 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202202071202.217C2BLZ071882@donotpassgo.dyslexicfish.net> Date: Mon, 07 Feb 2022 12:02:11 +0000 Organization: Dyslexic Fish To: jamie@catflap.org, Cy.Schubert@cschubert.com Cc: theraven@FreeBSD.org, freebsd-current@FreeBSD.org, Cy.Schubert@cschubert.com Subject: Re: Dragonfly Mail Agent (dma) in the base system References: <835dc887-6491-602c-7d71-d99309871126@siemens.com> <20220205141300.C19D2149@slippy.cwsent.com> <202202061553.216Fr0Yt071775@donotpassgo.dyslexicfish.net> <20220206161102.D8114111@slippy.cwsent.com> <202202062216.216MGQgQ005757@donotpassgo.dyslexicfish.net> <20220206231723.E7EA71D0@slippy.cwsent.com> In-Reply-To: <20220206231723.E7EA71D0@slippy.cwsent.com> User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Mon, 07 Feb 2022 12:02:12 +0000 (GMT) X-Rspamd-Queue-Id: 4JslBQ4BSjz3khh X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-0.16 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net:c]; NEURAL_HAM_LONG(-0.04)[-0.043]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_FIVE(0.00)[5]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2001:19f0:300:2185:123::1:server fail,104.207.135.49:server fail]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; NEURAL_HAM_SHORT(-0.41)[-0.413]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > It was a let's consider all the gotchas before diving in with both feet. *shrug* And all I did was suggest one way to deal with it. I didn't disagree with your analysis. I don't understand the hostility. > For me personally, maintainer of nmh and heirloom-mailx, I will enable the > dma build on my sandbox to give it a little workout. I use heirloom-mailx all the time. It works fine with DMA. Ooops, sorry if that comment was too presumptuous of me ;-) cheers! ... Jamie From nobody Mon Feb 7 12:29:32 2022 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 F3E9619AFDF9 for ; Mon, 7 Feb 2022 12:29:33 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4Jslnn21Mpz4Rmg for ; Mon, 7 Feb 2022 12:29:33 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 217CTX4c072477 for ; Mon, 7 Feb 2022 12:29:33 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 217CTWBe072476 for freebsd-current@FreeBSD.org; Mon, 7 Feb 2022 12:29:32 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202202071229.217CTWBe072476@donotpassgo.dyslexicfish.net> Date: Mon, 07 Feb 2022 12:29:32 +0000 Organization: Dyslexic Fish To: freebsd-current@FreeBSD.org Subject: Re: USB Disk Stalls on -current References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Mon, 07 Feb 2022 12:29:33 +0000 (GMT) X-Rspamd-Queue-Id: 4Jslnn21Mpz4Rmg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [0.28 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_SPAM_SHORT(0.97)[0.973]; NEURAL_HAM_LONG(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N grarpamp wrote: > Yes, some USB hw is very flaky, > but ZFS can work great on these... For what it's worth, I have had for 2.5 years, tracking stable, a NAS hanging off a single NUC usb port, with 14 hard disks, 12 of which are used for 2 ZFS, spools, of two 3X2 mirror spools. Albeit, I'm using USB3 During heavy writes, I often get: [1429164] (da10:umass-sim10:10:0:0): WRITE(16). CDB: 8a 00 00 00 00 02 04 39 b2 80 00 00 01 00 00 00 [1429164] (da10:umass-sim10:10:0:0): CAM status: CCB request completed with an error [1429164] (da10:umass-sim10:10:0:0): Retrying command, 14 more tries remain , but with no errors or timeouts. I scrub regularly etc. It rarely has to attempt a retry more than once (although I did bump "kern.cam.da.retry_count" up to 15 a while back while dealing with another issue, and never changed it back) I only get about 300MB/s maximum on file reads though, but the current USB daisychaining I use isn't ideal. (Each raw disk individually give 150MB/s) The only issue I have is occasionally the main USB hub craps out, and all the disks disappear for a few seconds. When it recovers, and the OS sees the disks again, things remain weird until a reboot. cheers, Jamie From nobody Tue Feb 8 06:38:51 2022 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 A0ACA19AC9FF for ; Tue, 8 Feb 2022 06:38:55 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtCyk3jycz4T6L for ; Tue, 8 Feb 2022 06:38:54 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x435.google.com with SMTP id s18so28831864wrv.7 for ; Mon, 07 Feb 2022 22:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=VS+Up7DSsUT+AW9ZbxiWLTeU68jGept4CVpmp3Dccss=; b=pS3eDuLOBXt+Z4yOsHSt30XWe2TRNQqinSb1EEAw6xmZ8orlQ64MO9nV02WdcUIG2P TTytHZO66Sf315ldWSoj8JKWflMWGc9JuLn2dE4i0rSBC+Y/T4C5Dw3ElzelBkUsZAv2 xeK7EgSFl1gHz9NtnZGzU6pPMXCwztkcqNQRp1paXYcqccvl57QZFiqUoQjyGhMhXMmn Vjlvt/t2PQIsCvyzFaV670GQZRRRkiB7sJK53xm3wE+x470jzvw7ZjZbhIkE6k6V5AIS 8NbeTCM/06sp/eRki6KZIo62q1GLz3BSNGaqKhtmMY/QZBWyhb6zsP5ltlg55wetmFqS 0jEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=VS+Up7DSsUT+AW9ZbxiWLTeU68jGept4CVpmp3Dccss=; b=w+nRSwKWWgYJn4KZkQ7uZhSfA2vuzifrTXGAOl6hOBCXZXXoWV+ci5UOaR/heKJDnD zPplVZc/6Fpw8Cocv20Srm7bK63UV56A3z5Qu60vRQgLHb3usGWST9F6L5d/6vfFofT5 4rt4HWqk/6jRQlFtrf1LPwbPrUMj4L7XHeBdNX08Kzfn2Gb2UwhYaUdCgBAqhVaNQvVO E2a4P1MqVEnI+jADmuy0Qi72lrMn+zUOi8NUI/hCRjGBwbspy5gqYQvaTbuQOtp68F/I n+RfozxyperdXlZaFdJIk42bqec5pq4/OAxM9+xyarJ3DHfuOmhNFiSCTnyw91tTFDwH GWug== X-Gm-Message-State: AOAM531VU9dPrxjUy15/ZQGzr5RtEQvhYnd5IX6gCTRlal791ELF2Qqr WtjXYublOBPnrfChvVBIbGaMMT051iWeTQ== X-Google-Smtp-Source: ABdhPJzMP/Bwivp5AW2OEV4NW/WQMRWVF8aHpldbwgBQAswS7FuWFVbucOPvgsVHgTBxMK1xfwCSGw== X-Received: by 2002:a5d:5850:: with SMTP id i16mr2096847wrf.519.1644302333117; Mon, 07 Feb 2022 22:38:53 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id k6sm1537539wms.14.2022.02.07.22.38.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Feb 2022 22:38:52 -0800 (PST) Message-ID: Date: Tue, 8 Feb 2022 06:38:51 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: FreeBSD guests behaving as if their boot disks have disappeared (was: USB Disk Stalls on -current) Content-Language: en-GB To: freebsd-current References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> From: Graham Perrin In-Reply-To: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JtCyk3jycz4T6L X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=pS3eDuLO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::435 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.39 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.73)[-0.730]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.957]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::435:from]; MIME_HTML_ONLY(0.20)[]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N

On 06/02/2022 18:20, Warner Losh wrote:

… So there's some tools you can use. For usb, there's usbdump that can
get you the USB transactions. I've not used it enough to give more details
here. This will let you know what's going on, and when, on the USB endpoint.

You can also enable the CAM_IOSCHED stuff. This will allow you to get latency
measurements for 'requests in the sim' which basically will tell you what your
latency spread is for the drives. This will tell you if things are getting caught
up in the USB layer, or after CAM's da driver completes the I/O request
(granted, that's almost certainly not happening, but it will help you figure out
what's going on and put numbers to the oddities you are seeing).

Also, make sure you have good cables. I've had lots of hicups over the
years from dodgy USB cables. Also make sure you have good, high quality
enclosures. Many from the USB2 time-period are sketchy at best and I
went through several at one point trying to find a good one. I'd be tempted to
get USB 3 enclosures. I've had better luck with USB3 gear than USB2 gear
here, but you need a USB-3 controller to get USB-3 speeds which might not
be compatible with the NUC's built-in stuff (though my NUC has one USB3
port, there's lots of different models).

Usually, though, I see weirdness associated with dmesg messages from
usb, cam, etc when the hardware is on the sketch end.

Warner


Thanks, I'll arm myself with those tools.

In the meantime (maybe more for freebsd-virtualization@ than here): where a VirtualBox guest running FreeBSD behaves as if its boot disk has disappeared, and no exhaustion at the underlying storage level, is there a sysctl in the guest that might help to avoid the situation?

Underlying storage: OpenZFS pool on an old but reasonably good mobile hard disk drive (the one that features in <https://github.com/openzfs/zfs/issues/13038> with a hardware probe near the head of the opening post).

Whilst I have not yet found time to pay all due attention to VirtualBox logs, I do have a strong sense that these stalls of guests are more likely to bug FreeBSD guests than, for example, my Windows 10 guest with its .vhd in the same underlying pool.

From nobody Tue Feb 8 10:42:43 2022 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 E053719B00BB for ; Tue, 8 Feb 2022 10:42:57 +0000 (UTC) (envelope-from george@fork.id.au) Received: from mail2.uniridge.com.au (mail2.uniridge.com.au [13.237.159.77]) by mx1.freebsd.org (Postfix) with ESMTP id 4JtKNJ12bYz577r for ; Tue, 8 Feb 2022 10:42:55 +0000 (UTC) (envelope-from george@fork.id.au) Received: from mail.hq (unknown [192.168.11.6]) by mail2.uniridge.com.au (Postfix) with ESMTP id 7C348E4C for ; Tue, 8 Feb 2022 10:42:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fork.id.au; s=mail; t=1644316967; bh=zyQKYavcGbQCOW994+FY6uoB0DsX/pHMxVl1O3atie0=; h=Date:Subject:To:References:From:In-Reply-To; b=j2str7aROOJ2ntl/D+q+xZfQzYq5v6vJipq7uXxpP65/Fwqk1REfMcq31gBlwGKP/ r30kDg+GR6EMJiu4U4SK/lgGB76UCrQNcG/JBdH6nzfusM3Tn8LF5uXHyboJDjCNIs Wqd9x43RID8ykuTcV5W1hOxmcWAHIEQAl9uA6wGQ= Received: from [192.168.11.53] (unknown [192.168.11.53]) by mail.hq (Postfix) with ESMTP id 52E27AC475 for ; Tue, 8 Feb 2022 10:42:45 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------3oJ5n3wlY1UvvZb3AlZlVpwh" Message-ID: Date: Tue, 8 Feb 2022 11:42:43 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: buildworld failed Content-Language: en-US To: freebsd-current@freebsd.org References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> From: George Abdelmalik In-Reply-To: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> X-Rspamd-Queue-Id: 4JtKNJ12bYz577r X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fork.id.au header.s=mail header.b=j2str7aR; dmarc=pass (policy=reject) header.from=fork.id.au; spf=pass (mx1.freebsd.org: domain of george@fork.id.au designates 13.237.159.77 as permitted sender) smtp.mailfrom=george@fork.id.au X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[fork.id.au:s=mail]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:13.237.159.77]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[fork.id.au:+]; DMARC_POLICY_ALLOW(-0.50)[fork.id.au,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:16509, ipnet:13.236.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------3oJ5n3wlY1UvvZb3AlZlVpwh Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/2/22 03:50, qroxana wrote: > > > I know running make install for /usr/src/tools/build/test-includes can > fix this, > but this still fails on a newly installed 14.0-CURRENT. > > --- test-includes --- > cd /usr/src/tools/build/test-includes; MACHINE_ARCH=aarch64 > MACHINE=arm64  CPUTYPE= CC="cc -target aarch64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target > aarch64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="c++ -target > aarch64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin  -target > aarch64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  CPP="cpp -target > aarch64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target > aarch64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  AS="as" AR="ar" > ELFCTL="elfctl" LD="ld"  LLVM_LINK="" NM=nm OBJCOPY="objcopy" > RANLIB=ranlib STRINGS=  SIZE="size" STRIPBIN="strip" INSTALL="install > -U" > PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin > SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make > DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp test-includes > --- sys/abi_compat.c --- > --- sys/acct.c --- > --- sys/acl.c --- > --- sys/aio.c --- > --- sys/abi_compat.c --- > echo "#include " > sys/abi_compat.c > sh: cannot create sys/abi_compat.c: No such file or directory > *** [sys/abi_compat.c] Error code 2 > > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/acct.c --- > echo "#include " > sys/acct.c > sh: cannot create sys/acct.c: No such file or directory > *** [sys/acct.c] Error code 2 > > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/aio.c --- > echo "#include " > sys/aio.c > sh: cannot create sys/aio.c: No such file or directory > *** [sys/aio.c] Error code 2 > > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/acl.c --- > echo "#include " > sys/acl.c > sh: cannot create sys/acl.c: No such file or directory > *** [sys/acl.c] Error code 2 > > Same here for me for the past couple of weeks. Haven't been able to identify why it fails. My hunch was that a particular objdir wasn't being created. As a workaround I edited the Makefile.inc1 to remove the test-includes command (line 1128 I think). I'd really like to understand why this error comes about. If someone has any insights, please share them :) Regards, George. --------------3oJ5n3wlY1UvvZb3AlZlVpwh Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 7/2/22 03:50, qroxana wrote:


I know running make install for /usr/src/tools/build/test-includes can fix this,
but this still fails on a newly installed 14.0-CURRENT.

--- test-includes ---
cd /usr/src/tools/build/test-includes;  MACHINE_ARCH=aarch64  MACHINE=arm64  CPUTYPE= CC="cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="c++  -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin  -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  CPP="cpp -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  AS="as" AR="ar" ELFCTL="elfctl" LD="ld"  LLVM_LINK="" NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size" STRIPBIN="strip"  INSTALL="install -U"  PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin  SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make  DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp test-includes
--- sys/abi_compat.c ---
--- sys/acct.c ---
--- sys/acl.c ---
--- sys/aio.c ---
--- sys/abi_compat.c ---
echo "#include <sys/abi_compat.h>" > sys/abi_compat.c
sh: cannot create sys/abi_compat.c: No such file or directory
*** [sys/abi_compat.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/acct.c ---
echo "#include <sys/acct.h>" > sys/acct.c
sh: cannot create sys/acct.c: No such file or directory
*** [sys/acct.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/aio.c ---
echo "#include <sys/aio.h>" > sys/aio.c
sh: cannot create sys/aio.c: No such file or directory
*** [sys/aio.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/acl.c ---
echo "#include <sys/acl.h>" > sys/acl.c
sh: cannot create sys/acl.c: No such file or directory
*** [sys/acl.c] Error code 2


Same here for me for the past couple of weeks. Haven't been able to identify why it fails. My hunch was that a particular objdir wasn't being created. As a workaround I edited the Makefile.inc1 to remove the test-includes command (line 1128 I think).

I'd really like to understand why this error comes about. If someone has any insights, please share them :)

Regards,
George.


--------------3oJ5n3wlY1UvvZb3AlZlVpwh-- From nobody Tue Feb 8 14:45:44 2022 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 5672E19B12AC for ; Tue, 8 Feb 2022 14:46:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtQmh138wz3wWp for ; Tue, 8 Feb 2022 14:45:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x934.google.com with SMTP id e17so25103449uad.9 for ; Tue, 08 Feb 2022 06:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xjAO+NGHD6Zd8ImCXQBe4Vr2QBSEQqNXIzYQLT+1VQA=; b=zaqatSksZayENkyWHnMQqxpPYSH5kEvK1mz1kfEIHqJx3EwPypyNI4ac0o5q1zRnit pZ0uW/t3gSFx6HqSI+TwjgkFs38TXqlXiqmxQc6vvHaKxjnaVLM3/S7Rs9pItifqp8Bd jIn9yhjdTKZpH4z9N3GBI/Yhky+ArExJbYgip0D7/h3ZY7q3CyjhK5wnWVyDFZYviA/G vpeieoBcyOGMvZaNcBx1OTh+Htuc6zitGpD3gA0lJI+wz5VkimTWUwW11ldSGmWD5AkI swODJhrzgwqoRE9/V8OZ28gRb49iReq/mt4lQTGMi8Rm4UKal3fwjwVepqQHBh6lew5Z 5jaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xjAO+NGHD6Zd8ImCXQBe4Vr2QBSEQqNXIzYQLT+1VQA=; b=oGVYDKi04RpWsC+26WP/K/KjAD7ABneKylsh4gridXgOJxFssvPIP7oqqdK+Wklu7D hA8XKZIF8jQCwmDu8aBSEpHhhdi1/4tVuSK4U0/Q/h1pl2P4OrRbwUb8fncQe+Cuc3HP IQrq/Wp5QcPglkW4G+pXrXbrV7wd6C060GKVPFa3LC4VmlwiWzIFir2nWPG+ti80bKi/ YHe6v4tA+DfgZoGsGMIMeHW2rhztfnQxRCj9/Bo9kwTe2CapmJFCmbZc6tIs8pIGVofj MqQU86NuwKD6AMtvYIBZzWEKQG+gd6ksojRxNd2A7Z/2VkQ/uuo8Ef+sOZf13wM93irZ vPTA== X-Gm-Message-State: AOAM530FiuNjzzzEV2ahiiOwRD6CMbAy2vGmXdNM+eSNMGu4A5HVpoAD pG7aC9liQFpHMXaVZTtn1rix7ENZiB677OIVw44bpXjlsWo= X-Google-Smtp-Source: ABdhPJwzRv5Fn17cZ598DOpXcoadWCEZhrO2/opK0YZCWxI8jktkPHPawbkPkNwM86nsGKOUixdallw8RGtIx4lsi6Y= X-Received: by 2002:ab0:ae:: with SMTP id 43mr1476636uaj.85.1644331554785; Tue, 08 Feb 2022 06:45:54 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> In-Reply-To: From: Warner Losh Date: Tue, 8 Feb 2022 07:45:44 -0700 Message-ID: Subject: Re: buildworld failed To: George Abdelmalik Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000003760a005d782c61b" X-Rspamd-Queue-Id: 4JtQmh138wz3wWp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=zaqatSks; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::934) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::934:from]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::934:server fail]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --0000000000003760a005d782c61b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 8, 2022 at 3:43 AM George Abdelmalik wrote: > > On 7/2/22 03:50, qroxana wrote: > > > > I know running make install for /usr/src/tools/build/test-includes can fi= x > this, > but this still fails on a newly installed 14.0-CURRENT. > > --- test-includes --- > cd /usr/src/tools/build/test-includes; MACHINE_ARCH=3Daarch64 > MACHINE=3Darm64 CPUTYPE=3D CC=3D"cc -target aarch64-unknown-freebsd14.0 > --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target > aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tm= p > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX=3D"c++ -target > aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tm= p > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target > aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tm= p > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP=3D"cpp -target > aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tm= p > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target > aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tm= p > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" AS=3D"as" AR=3D"ar" > ELFCTL=3D"elfctl" LD=3D"ld" LLVM_LINK=3D"" NM=3Dnm OBJCOPY=3D"objcopy" > RANLIB=3Dranlib STRINGS=3D SIZE=3D"size" STRIPBIN=3D"strip" INSTALL=3D"= install -U" > PATH=3D/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarc= h64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/sr= c/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/lega= cy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/a= rm64.aarch64/tmp/legacy/usr/libexec::/usr/obj/usr/src/arm64.aarch64/tmp/bin= :/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64= /tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/us= r/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/l= egacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin= :/usr/sbin:/usr/bin > SYSROOT=3D/usr/obj/usr/src/arm64.aarch64/tmp make > DESTDIR=3D/usr/obj/usr/src/arm64.aarch64/tmp test-includes > --- sys/abi_compat.c --- > --- sys/acct.c --- > --- sys/acl.c --- > --- sys/aio.c --- > --- sys/abi_compat.c --- > echo "#include " > sys/abi_compat.c > sh: cannot create sys/abi_compat.c: No such file or directory > *** [sys/abi_compat.c] Error code 2 > > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/acct.c --- > echo "#include " > sys/acct.c > sh: cannot create sys/acct.c: No such file or directory > *** [sys/acct.c] Error code 2 > > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/aio.c --- > echo "#include " > sys/aio.c > sh: cannot create sys/aio.c: No such file or directory > *** [sys/aio.c] Error code 2 > > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/acl.c --- > echo "#include " > sys/acl.c > sh: cannot create sys/acl.c: No such file or directory > *** [sys/acl.c] Error code 2 > > > Same here for me for the past couple of weeks. Haven't been able to > identify why it fails. My hunch was that a particular objdir wasn't being > created. As a workaround I edited the Makefile.inc1 to remove the > test-includes command (line 1128 I think). > > I'd really like to understand why this error comes about. If someone has > any insights, please share them :) > What build options are you using? this is the test to make sure that files can be included on their own. Warner --0000000000003760a005d782c61b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 8, 2022 at 3:43 AM George= Abdelmalik <george@fork.id.au&= gt; wrote:
=20 =20 =20


On 7/2/22 03:50, qroxana wrote:
=20


I know running make install for /usr/src/tools/build/test-includes can fix this,
but this still fails on a newly installed 14.0-CURRENT.

--- test-includes ---
cd /usr/src/tools/build/test-includes;=C2=A0 MACHINE_ARCH=3Daarch64=C2=A0 MACHINE=3Darm64=C2=A0 CPUTYPE=3D CC=3D"cc -target aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX=3D&q= uot;c++=C2=A0 -target aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin=C2=A0 -target aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"=C2=A0 CP= P=3D"cpp -target aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"=C2=A0 AS= =3D"as" AR=3D"ar" ELFCTL=3D"elfctl" LD=3D"ld"=C2=A0 LLVM_= LINK=3D"" NM=3Dnm OBJCOPY=3D"objcopy"=C2=A0 RANLIB=3Dranlib STRINGS=3D=C2=A0 SIZE=3D"size" ST= RIPBIN=3D"strip"=C2=A0 INSTALL=3D"install -U"=C2=A0 PATH=3D/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch6= 4/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/= arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy= /usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm= 64.aarch64/tmp/legacy/usr/libexec::/usr/obj/usr/src/arm64.aarch64/tmp/bin:/= usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/t= mp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/= src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/leg= acy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/= usr/sbin:/usr/bin=C2=A0 SYSROOT=3D/usr/obj/usr/src/arm64.aarch64/tmp make=C2=A0 DESTDIR=3D/usr/obj/usr/src/arm64.aarch64/tmp test-includes<= br>
--- sys/abi_compat.c ---
--- sys/acct.c ---
--- sys/acl.c ---
--- sys/aio.c ---
--- sys/abi_compat.c ---
echo "#include <sys/abi_compat.h>" > sys/abi_co= mpat.c
sh: cannot create sys/abi_compat.c: No such file or directory
*** [sys/abi_compat.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/acct.c ---
echo "#include <sys/acct.h>" > sys/acct.c
sh: cannot create sys/acct.c: No such file or directory
*** [sys/acct.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/aio.c ---
echo "#include <sys/aio.h>" > sys/aio.c
sh: cannot create sys/aio.c: No such file or directory
*** [sys/aio.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/acl.c ---
echo "#include <sys/acl.h>" > sys/acl.c
sh: cannot create sys/acl.c: No such file or directory
*** [sys/acl.c] Error code 2


Same here for me for the past couple of weeks. Haven't been able to identify why it fails. My hunch was that a particular objdir wasn't being created. As a workaround I edited the Makefile.inc1 to remove the test-includes command (line 1128 I think).

I'd really like to understand why this error comes about. If someone has any insights, please share them :)

=
What build options are you using?=C2=A0 this is the test to make sure = that files can be included on their own.

Warner
--0000000000003760a005d782c61b-- From nobody Tue Feb 8 14:54:07 2022 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 E306819B6506 for ; Tue, 8 Feb 2022 14:54:10 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 4JtQy93Qpcz4Tt0 for ; Tue, 8 Feb 2022 14:54:09 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.1.14] (c-98-249-71-218.hsd1.nm.comcast.net [98.249.71.218]) (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) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 7004F1AF4F8 for ; Tue, 8 Feb 2022 14:54:08 +0000 (UTC) Message-ID: Date: Tue, 8 Feb 2022 07:54:07 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: USB Disk Stalls on -current Content-Language: en-US To: freebsd-current@freebsd.org References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> From: Sean Bruno In-Reply-To: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JtQy93Qpcz4Tt0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 199.102.79.106 is neither permitted nor denied by domain of sbruno@freebsd.org) smtp.mailfrom=sbruno@freebsd.org X-Spamd-Result: default: False [-2.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[sbruno]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.77)[-0.768]; RECEIVED_SPAMHAUS_PBL(0.00)[98.249.71.218:received]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:199.102.76.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2/6/22 10:14, Sean Bruno wrote: > I'm doing something "gross" with ZFS & Plex on a little Intel NUC that I > have here at the house to provide me with a nice little NAS at home. I'm > using 2x USB2 external disks as the mirror. > > I noted that the two USB2 disks I'm using in a mirror seem to "stall" > from time to time and its not clear to me why. > > I'd like to poke further into the USB system but I'm not sure where I > should start to see if there is something amiss with the hardware (e.g. > the disks suck) or if FreeBSD is losing track of something during I/O > leading to a stall/timeout. > > I'm not seeing data loss or anything, I just note from time to time > during large file transfers that the clanking/grinding sound of the > spinning rust on my desk completely stops, the encoding of the video > files stops (so its waiting for a read to complete) and its gets much > quieter in my office.  :-) > > sean > I think I'm going to grab one of these fancy 5-disk USB 3 enclosures I see on the Internet. ;-) Most of the consumer grade units seem to have one or more issues (no NCQ depth more than 1, loud/bad fans, hard to get a real JBOD mode, JBOD mode eats serial numbers making ID hard). I think I settled on the TERRAMASTER D5-300 USB3.1 I'll post back results when it arrives and I get done swearing and cursing during the replacement. sean From nobody Tue Feb 8 15:33:17 2022 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 EE2C419AAC52 for ; Tue, 8 Feb 2022 15:33:52 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic308-9.consmr.mail.ne1.yahoo.com (sonic308-9.consmr.mail.ne1.yahoo.com [66.163.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtRqw6PcFz3D5M for ; Tue, 8 Feb 2022 15:33:48 +0000 (UTC) (envelope-from filippomore@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644334421; bh=0+i4x2yEQp6DlPtUyfGuWjCJLXWSifEPIID6oAEOZLQ=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=VTrZVdkJ2yeqGSOIMbEHGPZn9ZDPgjxAZmQ3qKCQZYsXvvjiFPx64Ak7UfxAN1ne8UvPQ8OZKRJx2FiRyy05zS5p+p4m54fagN3yWm4g2ZL6dI3VCqHpMtC5QPUKUb9ifM0YIJKI3QV4BaoXyU1pcV1/fsgni0NpbVZFoA5Au7UuzNQ6mtgXrShgnq0DWjjCbbLt5dR95yI0xxhgthEhJa+wTTccYHiZohhwYIPyKcqrBRCc7KKEKlNhLzbxktFWYKFsMxBMk4k9/JwIDiU9Cr1aWf61QhUp2hK57Dmna51Auk3gW5KI5q37CESGn9w+O7yuwzKsp+ei8cj/0EmitQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1644334421; bh=xV/47tJoWrqo+Mv+46VcK2Z5Z1pJ5nTfrU4JJkBAf2d=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=EX+7i6+8Mm2FCdh3C7AigZ8X3Pq0/2MsnEGpmXYzl7YcMNf03K+otUel8FGoIuFsS/5D/8TFcWkpwVq9vNx9EQ86mVcsSZj4sg8VOwsPGzkbagBLQPGmvb+uoTpmmNE1w5mBIKpUThot1QcB5teilsWJuC3SVZHwC7qrvfiF1DBC/bp+ixihbkG5roMR6evZHO10uaFFbflRJiyn23M3/SUOpzYXc8OnCacYkuhR8WoWQe8rnQEJfBEpGUMWvz641qiafUHbRMSCRSEh2nblGgEvS16xwqtv4DPqo/Q0ZCcrQDJW/419fVsOnHHO0sQdxQodbuYqsszC8W0MQSV4wA== X-YMail-OSG: PBXKCh8VM1mpeTxWXmdhxNAu3pIdewrkQq51fjI..a2_3LAKH7SZHR_YuEIu5xX NFCduvrYnIGNd5DO7m5nPp_Cx41iIBX7XAtqJIirUpW_eozumDgQQHAIT5LATYQDDOor01dkDXX1 0ZA8WVEL0KuPg0h8KiY6wnl9AcqmgnfU7NpJ0jAoyMkK4n3RwVhDDue5YLgjOH_.FHVuDqghn8ZA lw1LT.PxBb99z2ZFyrGCpYbaRHaLCa8ybFeydNGsAEIWCduuU0kTnjS8DUpaQyJRhq8pl513d2qp n75Cxm7qVCkkGJooB75Nlr4JvTbEPRYBgxgCbTyHso1AHf1LYOpM6liTVpRVHSnKEIh3EJ1Bql70 tPOOmW8vGGeb3oiq8l862HxDKHydcjnkG_N.F9RwAEoltQivpptTKHBSC5cRplwqroLgqDlX.7yD WkrKVID3DzAqdyteMwbqBVJwtTj72KrlJVfVJIHPJvceWP98ih7Rjr2aaW0WqeUNUuwMyHRlIs5L vpFHZqT3EbJ8U08PQulrhh2N6raRw17eoO2_lsUY41E01mcYb7Oyo9ACHlT.G8RxDflKh4SvOzu6 gWHGe5PW7pnEUusJd5WlyCFrAWU4_rNkCYGhIL7NCrLjD8Gobm3b1GAOLqpPCuQ.S1WZYJPYWyei wOGyv7o545WEuAh3VdAPzJPd1eq0h.U8PsfudvmR9eu.RjELyIf4V1CMnK3OLCTtIf1bnRWeId0w N4AqrnNMfSSqpxjZpuzGFGw5NrQjGtUru5kSDJ0jOzKVuLr9_RRRBdtEMitXmsbz.kYjxJzRns.d atnKj2pACxZl_Bwh947a1d7.1C1VXfqIhQbdYrsUaq0VT9FhKwV4InxeYsdSHW5MlOwamWKBQiPl IvEq26OzvCRMBSojt6B4DzOIFXpUzL0GGCaB79BP17Uo4ooHp_ep1p0L1bAPjQ2SYPjVy0YeKCUp wXQ45sE8IDBgtHkBGOOiE4fY8tvbGi97udSJF1AGAMBlp8UdWcCcbZvxSY08JK_HuVp8mnoh8vMu TsvgaflUEQXBNL_9UOcODtXjxB3HV0UxU0yepEaNGPL50PXN37wHnmQh91PXE7UX.8x2acOFUo9_ j8i0sUaRUCBdlP4_lquMRX_0c2aizmHNpzneYghTHPgH_a_X0PYP.296brdHGk2TcWjFFLI1gAiv P3WE5ees4Usy9CjHwoPXCYF3bNWYc8oV2cGjDSS6Gl4LTOaz1qpFUu2GLCxVH_kKZLxG94UO7igt ZZtkKGCSZ0McdZqobmDuIVaxgn.RbuNHBtJ8sfiH14UBlsS_IzRKeRO3_UDdRcPePGMaMkWZp1RO e3URhlC1DlR7nhxrtYADRsCwIu11lfwuWvxL5Oa1GrG3ZZuTA2a1LJ43.AkQ60r6CMxPoohskXde phh3IlhVA6r9SQ_0aTwUtpz17jhYK9kdibkavMPfCXLCNhCMSeaHXLOoELJpHtSXQK.zMIY_O_Vx kJINZcBnUX32UpJ9wHbgXPrxHICOkepH2liDWCxa1my2o0PvGxnkrTSTWbkmLzsnQWomL3bWJf5K QnZ6aKQCb_BEkvNFGgf.BnrKCevFl9_J2S5eLEXY1XJhZ98R.VUA2zlzPTlRj.HQ3pjDHBKEafN_ qRVoDjSUSujfxIwJ7IR1u5xEzXgagoPPxkeeOtjQzSNfpbuuixqxsgogOSKs9VsWt9bNdsteEia8 ktN5sAP4YCEyUU8_gL.rJV2XPTvoQarBum3IRjBGwZTyd6IUGSUCsmGSoy3Ca_A2b6HpPTGeno5P l7NWtl9aEeNGrZFn_RXlqTmZoF28p3BwAkkWVysO3X0n7MDf72db3hl53CF_91_ZFBqx4yDFJlRC G_0YoLDIZrP0V1MkDeVY7ebL9ZWo2HPGkm_fKavOO7BIy46W22pw2Y.oXI5QMLb2c22QO3jzNf_o bIL15Byvks64f0MVwS3WXWBUTZ6t1udemV1OpnUED23baqHsuwblVAZY1K3HQmh9xou44C4m0oNS Nbm3gwSWyE77IX.aFRkaeTuxwqvfjfG8x70FFzlCcsoMQ7hgTgMrNg8DKdxJYTu7H5GKVBgHZlyK BdYT398mNyLl0CSDWAGR2sosBqQxnC0sNifgQUNiDgu4xS7bQpgFGvanoWejoNqxtui649popEGa NFvAiGRCGUnnaUxgetlidE9fbX2CVZbTzig-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Tue, 8 Feb 2022 15:33:41 +0000 Date: Tue, 8 Feb 2022 15:33:17 +0000 (UTC) From: Filippo Moretti To: FreeBSD Current Message-ID: <1280673324.1447565.1644334397652@mail.yahoo.com> Subject: Problem compiling firefox 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_1447564_1513386290.1644334397651" References: <1280673324.1447565.1644334397652.ref@mail.yahoo.com> X-Mailer: WebService/1.1.19711 YMailNorrin X-Rspamd-Queue-Id: 4JtRqw6PcFz3D5M X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=VTrZVdkJ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.187.32 as permitted sender) smtp.mailfrom=filippomore@yahoo.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[66.163.187.32:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.187.32:from] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_1447564_1513386290.1644334397651 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable /usr/local/bin/clang++13 -std=3Dgnu++17 --target=3Dwasm32-wasi --sysroot=3D= /usr/local/share/wasi-sysroot -o rlbox.wasm -Wl,--export-all -Wl,--stack-fi= rst -Wl,-z,stack-size=3D262144 -Wl,--no-entry -Wl,--growable-table ogg_allo= c.wasm ogg_bitwise.wasm ogg_framing.wasm xmlparse.wasm xmlrole.wasm xmltok.= wasm wasm2c_sandbox_wrapper.wasm mozHunspellRLBoxSandbox.wasm affentry.wasm= affixmgr.wasm csutil.wasm hashmgr.wasm hunspell.wasm phonet.wasm replist.w= asm suggestmgr.wasm GraphiteExtra.wasm CmapCache.wasm Code.wasm Collider.wa= sm Decompressor.wasm Face.wasm FeatureMap.wasm FileFace.wasm Font.wasm Glyp= hCache.wasm GlyphFace.wasm Intervals.wasm Justifier.wasm NameTable.wasm Pas= s.wasm Position.wasm Segment.wasm Silf.wasm Slot.wasm Sparse.wasm TtfUtil.w= asm UtfCodec.wasm call_machine.wasm gr_char_info.wasm gr_face.wasm gr_featu= res.wasm gr_font.wasm gr_logging.wasm gr_segment.wasm gr_slot.wasm json.was= m RLBoxWOFF2Sandbox.wasm table_tags.wasm variable_length.wasm woff2_common.= wasm woff2_dec.wasm woff2_out.wasm -lwasi-emulated-process-clockswasm-ld: e= rror: cannot open /usr/local/llvm13/lib/clang/13.0.1/lib/wasi/libclang_rt.b= uiltins-wasm32.a: No such file or directoryclang-13: error: linker command = failed with exit code 1 (use -v to see invocation)gmake[5]: *** [/usr/ports= /www/firefox/work/firefox-97.0/config/rules.mk:498: rlbox.wasm] Error 1gmak= e[5]: Leaving directory '/usr/ports/www/firefox/work/.build/security/rlbox'= gmake[4]: *** [/usr/ports/www/firefox/work/firefox-97.0/config/recurse.mk:7= 2: security/rlbox/target-objects] Error 2gmake[4]: Leaving directory '/usr/= ports/www/firefox/work/.build'gmake[3]: *** [/usr/ports/www/firefox/work/fi= refox-97.0/config/recurse.mk:34: compile] Error 2gmake[3]: Leaving director= y '/usr/ports/www/firefox/work/.build'gmake[2]: *** [/usr/ports/www/firefox= /work/firefox-97.0/config/rules.mk:352: all] Error 2gmake[2]: Leaving direc= tory '/usr/ports/www/firefox/work/.build'*** Error code 1 Stop.make[1]: stopped in /usr/ports/www/firefox*** Error code 1 Stop.make: stopped in /usr/ports/www/firefox[root@sting /usr/ports/www/fire= fox]#=C2=A0 This is the error I get while=C2=A0 attempting to update firefox from port [root@sting /usr/ports/www/firefox]# uname -aFreeBSD sting 14.0-CURRENT Fre= eBSD 14.0-CURRENT #67 heads/main-n252631-ccf50c1df9c: Tue Jan 25 22:12:38 C= ET 2022=C2=A0 =C2=A0 =C2=A0filippo@sting:/usr/obj/usr/src/amd64.amd64/sys/S= TING=C2=A0 amd64 sincerelyFilippo ------=_Part_1447564_1513386290.1644334397651 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
/usr/local/bin/clang++13 -std=3Dgn= u++17 --target=3Dwasm32-wasi --sysroot=3D/usr/local/share/wasi-sysroot -o r= lbox.wasm -Wl,--export-all -Wl,--stack-first -Wl,-z,stack-size=3D262144 -Wl= ,--no-entry -Wl,--growable-table ogg_alloc.wasm ogg_bitwise.wasm ogg_framin= g.wasm xmlparse.wasm xmlrole.wasm xmltok.wasm wasm2c_sandbox_wrapper.wasm m= ozHunspellRLBoxSandbox.wasm affentry.wasm affixmgr.wasm csutil.wasm hashmgr= .wasm hunspell.wasm phonet.wasm replist.wasm suggestmgr.wasm GraphiteExtra.= wasm CmapCache.wasm Code.wasm Collider.wasm Decompressor.wasm Face.wasm Fea= tureMap.wasm FileFace.wasm Font.wasm GlyphCache.wasm GlyphFace.wasm Interva= ls.wasm Justifier.wasm NameTable.wasm Pass.wasm Position.wasm Segment.wasm = Silf.wasm Slot.wasm Sparse.wasm TtfUtil.wasm UtfCodec.wasm call_machine.was= m gr_char_info.wasm gr_face.wasm gr_features.wasm gr_font.wasm gr_logging.w= asm gr_segment.wasm gr_slot.wasm json.wasm RLBoxWOFF2Sandbox.wasm table_tag= s.wasm variable_length.wasm woff2_common.wasm woff2_dec.wasm woff2_out.wasm= -lwasi-emulated-process-clocks
wasm-ld: error: cannot open /usr/= local/llvm13/lib/clang/13.0.1/lib/wasi/libclang_rt.builtins-wasm32.a: No su= ch file or directory
clang-13: error: linker command failed with = exit code 1 (use -v to see invocation)
gmake[5]: *** [/usr/ports/= www/firefox/work/firefox-97.0/config/rules.mk:498: rlbox.wasm] Error 1
gmake[5]: Leaving directory '/usr/ports/www/firefox/work/.build/secur= ity/rlbox'
gmake[4]: *** [/usr/ports/www/firefox/work/firefox-97.= 0/config/recurse.mk:72: security/rlbox/target-objects] Error 2
gm= ake[4]: Leaving directory '/usr/ports/www/firefox/work/.build'
gm= ake[3]: *** [/usr/ports/www/firefox/work/firefox-97.0/config/recurse.mk:34:= compile] Error 2
gmake[3]: Leaving directory '/usr/ports/www/fir= efox/work/.build'
gmake[2]: *** [/usr/ports/www/firefox/work/fire= fox-97.0/config/rules.mk:352: all] Error 2
gmake[2]: Leaving dire= ctory '/usr/ports/www/firefox/work/.build'
*** Error code 1
=

Stop.
make[1]: stopped in /usr/ports/www/fire= fox
*** Error code 1

Stop.
mak= e: stopped in /usr/ports/www/firefox
[root@sting /usr/ports/www/f= irefox]# 

= This is the error I get while  attempting to update firefox from port<= /div>

[root@sting /usr/ports/www/firefox]# uname -a
FreeBSD sting 14.0-CURRENT FreeBSD 14.0-CURRENT #67 heads/main-n25= 2631-ccf50c1df9c: Tue Jan 25 22:12:38 CET 2022     filippo@s= ting:/usr/obj/usr/src/amd64.amd64/sys/STING  amd64

sincerely
Filippo
<= /div> ------=_Part_1447564_1513386290.1644334397651-- From nobody Tue Feb 8 16:11:10 2022 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 0C9E919BF1E9; Tue, 8 Feb 2022 16:11:14 +0000 (UTC) (envelope-from vishwin@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtSg56n4Hz3k8v; Tue, 8 Feb 2022 16:11:13 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644336674; 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=fxwak2bg1fK315Hl6cWmZc0jgDITovwN6k3K7tAIVO8=; b=tuQIB70dxTUlDc+SJ4dU6K41FO9QImMnVgETrpKlxvIJ26ayoCjF1jTOY3Y14TxxfmfG4I o4GBmnNRT/GU3mKfiJzgZ/6UGBhfSaAyFKs/QC4eGFE+0QhOVKgw+PeQ40KKyJlxrB9vOp zClK8EKfhsDCAtnsVJ2ilaKFStlOZiH/bbO5KGhZNcnxYjmaJe8TjKxhTWdIZ0pq9tZe4d EIbEEhRVpjCQrXGjn/N5gJbYTrSNeq2EmUo+8+DATiW6lVOovjE3b9LON+GZ7a6Qzg7ba3 DX9MJW11Cb8znZ7O1VYeObaqyfk31xvROkTOlaC4QhqGwwtwLssULlysxZmbww== Received: from [IPV6:2601:98a:600:3c20:56ee:75ff:fe50:69b5] (unknown [IPv6:2601:98a:600:3c20:56ee:75ff:fe50:69b5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id A010AA395; Tue, 8 Feb 2022 16:11:13 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: Date: Tue, 8 Feb 2022 11:11:10 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: Problem compiling firefox Content-Language: en-GB To: FreeBSD Current , gecko@freebsd.org References: <1280673324.1447565.1644334397652.ref@mail.yahoo.com> <1280673324.1447565.1644334397652@mail.yahoo.com> Cc: Filippo Moretti From: Charlie Li Organization: FreeBSD Project In-Reply-To: <1280673324.1447565.1644334397652@mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Vfzn6l9MfH7TwxoCw1py6WKg" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644336674; 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=fxwak2bg1fK315Hl6cWmZc0jgDITovwN6k3K7tAIVO8=; b=yNp/nqBxJa0pLKpB9UT65Az7pCXZ5NPpcyNplJRXJKplYBvqM4HvOd0lYLvK8LMlJwVmM7 q++4hjFLbb7LuDnDA/XB2UuokcTZtZtxp3cHfJCNGQPSru8s1v6g1OlpesDVf6eunLYCFl YsUJFkcrpkzTWYVTTPaj4X/D7hlFLrL11Xb1dQ25UxntS3/bC+lJ/riMIEgQzkHUvU2Yac jDZ61QgroR+hT9hcuE0y0vfsaq3fHYvY++UHKivEVcHWMsiP9euQWrJ4qSZ9i8obG6OB/W 6Vi8RoQF0Wh2sj13s/6GJHK0IW8fNamSANrwZ/9RkvyHf5oftTmLRzM+j+ku5w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644336674; a=rsa-sha256; cv=none; b=YNfkffihaa7+nvRcKMciHdqvP8K2jVS3GvwXmBmjOATlE2JWxWDWaJs17AOGAE/BKvSlD4 t/K7/Fnt+myDQ6D/8CzHudnJpXEaK9aGmQfYAsHRSvf1eaeKxnMX0ghviAuKZvdHF15XN0 NF60U1srM+z+WXW6K00gxm6tObJcD6CAW/9P7n0xY8ZEROBdMlnyTW/FpmN+U5YLiRVIww ubZ6XTfEIBK6+oy2LT9PYU2Yy2awy/e3b0j06FFp1kwtpKVP4ysaK3SjTH0UzJT2iiQBW/ qzXK44lYkbA+kPz4Qh+KL+pWqqcW+xc65r9mirgZvSf6/sg9cUNruEHOX0ZZHA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Vfzn6l9MfH7TwxoCw1py6WKg Content-Type: multipart/mixed; boundary="------------sz10XoXP6bHBAW92D2aTASxx"; protected-headers="v1" From: Charlie Li To: FreeBSD Current , gecko@freebsd.org Cc: Filippo Moretti Message-ID: Subject: Re: Problem compiling firefox References: <1280673324.1447565.1644334397652.ref@mail.yahoo.com> <1280673324.1447565.1644334397652@mail.yahoo.com> In-Reply-To: <1280673324.1447565.1644334397652@mail.yahoo.com> --------------sz10XoXP6bHBAW92D2aTASxx Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RmlsaXBwbyBNb3JldHRpIHdyb3RlOg0KPiAvdXNyL2xvY2FsL2Jpbi9jbGFuZysrMTMgLXN0 ZD1nbnUrKzE3IC0tdGFyZ2V0PXdhc20zMi13YXNpIA0KPiAtLXN5c3Jvb3Q9L3Vzci9sb2Nh bC9zaGFyZS93YXNpLXN5c3Jvb3QgLW8gcmxib3gud2FzbSAtV2wsLS1leHBvcnQtYWxsIA0K PiAtV2wsLS1zdGFjay1maXJzdCAtV2wsLXosc3RhY2stc2l6ZT0yNjIxNDQgLVdsLC0tbm8t ZW50cnkgDQo+IC1XbCwtLWdyb3dhYmxlLXRhYmxlIG9nZ19hbGxvYy53YXNtIG9nZ19iaXR3 aXNlLndhc20gb2dnX2ZyYW1pbmcud2FzbSANCj4geG1scGFyc2Uud2FzbSB4bWxyb2xlLndh c20geG1sdG9rLndhc20gd2FzbTJjX3NhbmRib3hfd3JhcHBlci53YXNtIA0KPiBtb3pIdW5z cGVsbFJMQm94U2FuZGJveC53YXNtIGFmZmVudHJ5Lndhc20gYWZmaXhtZ3Iud2FzbSBjc3V0 aWwud2FzbSANCj4gaGFzaG1nci53YXNtIGh1bnNwZWxsLndhc20gcGhvbmV0Lndhc20gcmVw bGlzdC53YXNtIHN1Z2dlc3RtZ3Iud2FzbSANCj4gR3JhcGhpdGVFeHRyYS53YXNtIENtYXBD YWNoZS53YXNtIENvZGUud2FzbSBDb2xsaWRlci53YXNtIA0KPiBEZWNvbXByZXNzb3Iud2Fz bSBGYWNlLndhc20gRmVhdHVyZU1hcC53YXNtIEZpbGVGYWNlLndhc20gRm9udC53YXNtIA0K PiBHbHlwaENhY2hlLndhc20gR2x5cGhGYWNlLndhc20gSW50ZXJ2YWxzLndhc20gSnVzdGlm aWVyLndhc20gDQo+IE5hbWVUYWJsZS53YXNtIFBhc3Mud2FzbSBQb3NpdGlvbi53YXNtIFNl Z21lbnQud2FzbSBTaWxmLndhc20gU2xvdC53YXNtIA0KPiBTcGFyc2Uud2FzbSBUdGZVdGls Lndhc20gVXRmQ29kZWMud2FzbSBjYWxsX21hY2hpbmUud2FzbSANCj4gZ3JfY2hhcl9pbmZv Lndhc20gZ3JfZmFjZS53YXNtIGdyX2ZlYXR1cmVzLndhc20gZ3JfZm9udC53YXNtIA0KPiBn cl9sb2dnaW5nLndhc20gZ3Jfc2VnbWVudC53YXNtIGdyX3Nsb3Qud2FzbSBqc29uLndhc20g DQo+IFJMQm94V09GRjJTYW5kYm94Lndhc20gdGFibGVfdGFncy53YXNtIHZhcmlhYmxlX2xl bmd0aC53YXNtIA0KPiB3b2ZmMl9jb21tb24ud2FzbSB3b2ZmMl9kZWMud2FzbSB3b2ZmMl9v dXQud2FzbSANCj4gLWx3YXNpLWVtdWxhdGVkLXByb2Nlc3MtY2xvY2tzDQo+IHdhc20tbGQ6 IGVycm9yOiBjYW5ub3Qgb3BlbiANCj4gL3Vzci9sb2NhbC9sbHZtMTMvbGliL2NsYW5nLzEz LjAuMS9saWIvd2FzaS9saWJjbGFuZ19ydC5idWlsdGlucy13YXNtMzIuYTogDQo+IE5vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnkNCj4gY2xhbmctMTM6IGVycm9yOiBsaW5rZXIgY29tbWFu ZCBmYWlsZWQgd2l0aCBleGl0IGNvZGUgMSAodXNlIC12IHRvIHNlZSANCj4gaW52b2NhdGlv bikNCkNhdXNlZCBieSBhIHZlcnNpb24gbWlzbWF0Y2ggYWZ0ZXIgZGV2ZWwvbGx2bTEzIHVw ZGF0ZSwgdHJ5IHRoaXM6DQpodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDM0MjA2DQoN Ci0tIA0KQ2hhcmxpZSBMaQ0K4oCmbm9wZSwgc3RpbGwgZG9uJ3QgaGF2ZSBhbiBleGl0IGxp bmUuDQo= --------------sz10XoXP6bHBAW92D2aTASxx-- --------------Vfzn6l9MfH7TwxoCw1py6WKg Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmIClh4FAwAAAAAACgkQ/reFK+KbPocE uA/+NRSbowH/B3PAGcqvcr0mwLg2HoRi95gXdtrA2J8PtXjjaidwf5m1ZBwkLrP7elM2mbVfE3k/ vYUGOh59HniLHXnMIV3F96Y0yRDhwGjuBoEam2X/6E63wjczwi7a4dxaj6/AJj+Tee23v9XjCFE8 behBYypCT17QXGXtvhRF2M5k1EVM9pHbkAfpXixLLWN7iwftD+OUQWWZrE5na//wOU/qB7qkc62i vahCjIy8ut1JkLZEvIYljMswvsVTUqi3Ik2BHngK+6xIoCXterSgZsTW/nsAVriJHf393w/gE6ec 3cck04VdTqNiO5Z8woRfu5hy7mixMcKthVJXobUTQA8otFp5VtMaeSpbD0Vkz3fTLPkU5L/m/qBM Slq0cpAuYtZV6dXUchseTrXGYTeMfGxV/cK4C3W1ArfNqeE7FtsgMC03BYDyHndOcVTXLMVHgMRn aUTEIHrK7bRRAB1s5syCZSsSBnphnqU32GZ/fzOZp4EzwofN0duBWdYCmM92AgcMzSTh0k3IUtcr oeakkXGLXlZhYT3woInme1cfpkmSHp+M5e33Ej9QglFUyfWw4AlqdAcXskuxinrBcQSn4aKRtUjk l0TM2FDw28Ey1Bwb/mHb6Bgx9mhaRmBTmksOIyd80BpeK0baf521ESiqvXUvuUYp8Mim3ri/HeCj 8yw= =EOov -----END PGP SIGNATURE----- --------------Vfzn6l9MfH7TwxoCw1py6WKg-- From nobody Tue Feb 8 17:56:19 2022 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 B105519B9054 for ; Tue, 8 Feb 2022 17:56:29 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtW0X4YbXz3GXL for ; Tue, 8 Feb 2022 17:56:28 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 218HQsUg014746; Tue, 8 Feb 2022 09:56:24 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=y1+NenYRsJo5T2WX+I1KcHsm6RFYS7vq4MgB8jPgjD8=; b=sX+1YDtqRFPTIR6eUydhMygeoJlal1/qLDOfsgjRl4yL9VkXI+ylSCm3USCR/t1PSZaU /XZXi3q3gcNz9WEKyRzPNui/JaR+m2AD/W5Bh7PYRFMHzXBbxv1x6KnC/c1Gi0Vco23D 72Mwrmkp7h1F9CveT2tdl0T1tXtisLgjrMXKYK6rrdyUcsacCiknDbxXBJHfPZLNWf7b I7SL+RvF9vdSzMBQZ7EnUNYMgQ0q7znurWsemm3MFGqwY824zv2+aPuuryCXPO1oLH5U g/Tcv//hYXwiUhO1K5xHfS7V0w1QZ7Ts3sDLnmD1AYLH8ubAJi9hSrf5bnmZN2LR20vz 0g== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2172.outbound.protection.outlook.com [104.47.56.172]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3e3j9hscpm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Feb 2022 09:56:24 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NPVHeGeuPHpR7ZiftXJjJtmdpJuXvk6KxgGzb8gndl0nBf4UddtTlVwrZX2INvhnd/vNjXrMNE5oRFUnSfh3hh5Ba2xrrJRRkLamNUNyckg2UruDTREaciTrBDj54047hGsglMB99v6Tn+VJSZPa1+PBpuuGrrEZgqTwo/4emvktz1sSe/j1b+zmNnfmldedQ9olPSyqwhmK6wwDeUMpD4VL+/tNzdsCfR4pyNT7HsEWsT+bDFtTPArk2PpTd+CwVjJEo+4MCUrycOJ27KQIYF5AVe1X56zrIZ3om9iX91lQKSq1EhF75lNPOZJyWZFnGBbrRYhDHbeVibyGIA5/vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=y1+NenYRsJo5T2WX+I1KcHsm6RFYS7vq4MgB8jPgjD8=; b=g+3w2uqog1kMyHFL+OCL8l26l3ixDT08/ARZPNdjjWosrm0SJOkoCpurOGs6esI6AXkdZR13MxLgVFDz3JMEcvYOzum3JxzOf7vHJW435oLpMZKLzXlrzKHOQI42g4TV32A0a67xFXvUSaAg6eXESQCGKJSbBPcpOshVn5Wod66G4DB03SItHTVjbK8qfePhiMaJTJfUarJsVnHR2bCmp79nRfd99jFTOLncQC+bTfWWYQpryLkBZxTmOf7M9vEXeFf31gqLVUnkawTNCxxwmQBaf787DZK0f7TiJLzDmDgFdbizXizWOFRtNtBUVkQkvWOIH6xjQbO3xWoWFyF1nQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.242.14) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y1+NenYRsJo5T2WX+I1KcHsm6RFYS7vq4MgB8jPgjD8=; b=LzBfLdd+uWPTy7B3u6Ajo43x624oHxi5GmlNtVnDdZxX+Mt/BuEupcPRtYM3/u6lUblQVO5BKfzJLVRodJYbIDkr/b2dILLUkL2BFLNytUqYjCe3kB7S5g1D9C9fLU+BN0kxGbgh/1jo6F+059iaaxgvBT3DSRtPsPElpzNOBQk= Received: from DM6PR04CA0019.namprd04.prod.outlook.com (2603:10b6:5:334::24) by DM6PR05MB4875.namprd05.prod.outlook.com (2603:10b6:5:13::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11; Tue, 8 Feb 2022 17:56:22 +0000 Received: from DM6NAM12FT060.eop-nam12.prod.protection.outlook.com (2603:10b6:5:334:cafe::f) by DM6PR04CA0019.outlook.office365.com (2603:10b6:5:334::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12 via Frontend Transport; Tue, 8 Feb 2022 17:56:22 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.242.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.242.14) by DM6NAM12FT060.mail.protection.outlook.com (10.13.179.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.5 via Frontend Transport; Tue, 8 Feb 2022 17:56:22 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20; Tue, 8 Feb 2022 11:56:21 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20 via Frontend Transport; Tue, 8 Feb 2022 11:56:21 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 218HuJiv025889; Tue, 8 Feb 2022 09:56:20 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id E968E9F92D; Tue, 8 Feb 2022 09:56:19 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id E7C539F8B7; Tue, 8 Feb 2022 09:56:19 -0800 (PST) To: Warner Losh CC: George Abdelmalik , FreeBSD Current , Subject: Re: buildworld failed In-Reply-To: References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> Comments: In-reply-to: Warner Losh message dated "Tue, 08 Feb 2022 07:45:44 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.2 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7836.1644342979.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Feb 2022 09:56:19 -0800 Message-ID: <9955.1644342979@kaos.jnpr.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5c0bab1f-acc0-4494-60c3-08d9eb2c5153 X-MS-TrafficTypeDiagnostic: DM6PR05MB4875:EE_ X-MS-Exchange-AtpMessageProperties: SA|SL X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: f3O6VBYlcDsXQqbpjnpcZJygNgG01M/+TIUn0uc+BIsYfWQBGamBxA1II7UFlLTHNB5C2v4ks6Kzapw4Oa+qh7b99fHL0Lu9arGFdfw8UJUiuv3ycf3QXWxDE5fIYOZ5DUgwUSjNN9BK9F2o2XISBkhlKM9U6Xqi/ppFBrSeXzs8fMILd67gLefEUhL0EHD+cHqke2hH6oeknbHWYjreZ3YcQPWpQLPu9euBV0qgwStAN2BbPSCMoWFfVey5ODUDTPUwye+2M08AxbKqRYr2jEbz6dDNhIJXepKR4yPsied5UyNCbZHmmVg85IpSFA/uCUwzpqtXhkF7zz+gQCZpFvOh+xaKva9BFVMNt6HXiemZ0jshBM+vXffsBf4HfuQIzvj6dat2xJlcl4i9Blds0q/+Jo1y7vIzQlV6p6ugU7xwC6Kz2tKzhvJ1RsxcsOQ981V3lYi3792mgBVHwomuiANeUPFI7HHYTnFdYavYnc+w7ZglcnXoUpvIEjwaOtj5jNnFXfME9FIFbLjQELx2cIrEseROTLaOcjC3FTHHu9Kjw6ehFRtfRmoRass6z536zEWOKtGXPjK3ZkZJLvMkN1myANtBgnM0umzmgk9FmPA/228PBVCDzjhGoL7GqTkpuVUOKDTy69cyINxzAECdq2YI/sJXYuuep2CsC41hhQgWiTCqBRH3/XezQvhrvx945zWNnlHvJfKFflkHmcQMT5yXpUS7OSPbVOfzKDEb7hWnZAPzlvq8X/3dhwWfE4Ua X-Forefront-Antispam-Report: CIP:66.129.242.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230001)(4636009)(40470700004)(36840700001)(46966006)(36860700001)(3480700007)(81166007)(2906002)(5660300002)(7696005)(508600001)(82310400004)(356005)(9686003)(316002)(40460700003)(54906003)(70586007)(47076005)(4326008)(107886003)(8936002)(7116003)(26005)(186003)(6266002)(7126003)(8676002)(70206006)(336012)(55016003)(6916009)(86362001)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2022 17:56:22.4205 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5c0bab1f-acc0-4494-60c3-08d9eb2c5153 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.242.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM12FT060.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4875 X-Proofpoint-GUID: uNhTWuVx__hsBJOz3t4M8C2DflLSc328 X-Proofpoint-ORIG-GUID: uNhTWuVx__hsBJOz3t4M8C2DflLSc328 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-08_06,2022-02-07_02,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 lowpriorityscore=0 bulkscore=0 impostorscore=0 mlxlogscore=999 spamscore=0 mlxscore=0 priorityscore=1501 suspectscore=0 adultscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202080105 X-Rspamd-Queue-Id: 4JtW0X4YbXz3GXL X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b=sX+1YDtq; dkim=pass header.d=juniper.net header.s=selector1 header.b=LzBfLdd+; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=juniper.net; spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 208.84.65.16 as permitted sender) smtp.mailfrom=sjg@juniper.net X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; FREEFALL_USER(0.00)[sjg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:208.84.65.16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[juniper.net:+]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; RCVD_IN_DNSWL_NONE(0.00)[104.47.56.172:received]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:26211, ipnet:208.84.65.0/24, country:US]; RCVD_COUNT_SEVEN(0.00)[10]; RCVD_IN_DNSWL_LOW(-0.10)[208.84.65.16:from] X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: > --- sys/abi_compat.c --- > echo "#include " > sys/abi_compat.c > sh: cannot create sys/abi_compat.c: No such file or directory > *** [sys/abi_compat.c] Error code 2 > = > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/acct.c --- > echo "#include " > sys/acct.c > sh: cannot create sys/acct.c: No such file or directory > *** [sys/acct.c] Error code 2 > = > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/aio.c --- > echo "#include " > sys/aio.c > sh: cannot create sys/aio.c: No such file or directory > *** [sys/aio.c] Error code 2 > = > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/acl.c --- > echo "#include " > sys/acl.c > sh: cannot create sys/acl.c: No such file or directory > *** [sys/acl.c] Error code 2 > = > = > = > Same here for me for the past couple of weeks. Haven't been able to > identify why it fails. My hunch was that a particular objdir wasn't > being created. As a workaround I edited the Makefile.inc1 to remove > the test-includes command (line 1128 I think). The sys subdir does not exist. Best bet would be to avoid the need: diff --git a/tools/build/test-includes/Makefile b/tools/build/test-include= s/Makefile index 3ae39a2cb61..eb9016ecc03 100644 --- a/tools/build/test-includes/Makefile +++ b/tools/build/test-includes/Makefile @@ -24,11 +24,11 @@ CFLAGS.event.c=3D -D_WANT_KEVENT32 -D_WANT_FREEBSD11_K= EVENT = .include "badfiles.inc" = -.for h in ${HDRS} +.for h c in ${HDRS:@x@$x ${x:S,/,_,g:R}.c@} .if !${BADHDRS:M${h}} -SRCS+=3D ${h:R}.c -CLEANFILES+=3D${h:R}.c -${h:R}.c: +SRCS+=3D $c +CLEANFILES+=3D$c +$c: echo "#include <$h>" > ${.TARGET} .endif .endfor so you get: echo "#include " > sys_abi_compat.c echo "#include " > sys_acct.c echo "#include " > sys_acl.c echo "#include " > sys_aio.c echo "#include " > sys_alq.c echo "#include " > sys_apm.c echo "#include " > sys_arb.c echo "#include " > sys_asan.c echo "#include " > sys_assym.c etc From nobody Tue Feb 8 18:14:57 2022 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 2ED6C19C39A0 for ; Tue, 8 Feb 2022 18:15:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtWQ428t5z3Pch for ; Tue, 8 Feb 2022 18:15:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2f.google.com with SMTP id u82so725527vkb.11 for ; Tue, 08 Feb 2022 10:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X/WxEki6ubqSZP99J8mKjwxAWD28QWXiWfp202qNSgY=; b=OOf2yJlhKqzFWKnppdZ+MhOHYdvvgTw6ovvN3OA50yiotXvVkfb1IF3uvhtZA3LNDo b0XahHP4kwGYe1quXYYNVQjqR9P9dhYG0X9MSKgQ1eYfybhGHnXq/GiM0aZLPEDcGH5M rNbdWh8DVbYkGt8QJ16ZZHSs0zkyXcNMeOT99vP040Pb9wVWlxzwt2Nx9RbLTyXgZrOP /mlAmhB5qY4re1wcGGPDAqkTK6dyKLWK0zGsSETrwX5fcfSHGJdpYenWN3qnM/1+8iZu JXyWaM2PZx8fDjrdD5yWjlBDAIX2vzoqLVTC6wNOnP4DhfzdvP1DGnhbFd/7qYjwsNTo gyPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X/WxEki6ubqSZP99J8mKjwxAWD28QWXiWfp202qNSgY=; b=1CnJI5BQCMrUNlsOBUqZBtWCY7l+7kP8U1ntAQLEUSCa2JaF4JLf0wupvmXUSxfs4n My2PhKZYFjbRHpvQDy7tk3Gs3PX9lQimt6Xc+gcOoDHA3bRgCJH82R5U0YtaVRm//CQ3 vLlg7hcCp14bfvxQY//7VjQBEPxta1ttHyTbCaNSr1Fx2v+JWQ4D9T0x2TUwCL0yL+RU sI6A36VDC8vimlWpoG+b4qF77MT+SpsIgEqvMF72VaBOGTpNql6bavy2A3NZNKaQIaH7 XKMvWSQIqMtEd7mH4OBxS8HLsWJAAdpCNaRY5LLo2r2QESJ1uaTRuOBYgZjdfoyEZRTn YvIA== X-Gm-Message-State: AOAM532fwd82Tk00fROQXJoMlRp27dt45r6m4awYdiwPkg5bnsldB6H/ B8YEp4wcvDhI6TNVqc1hb2ZR1MUpuX0yvRu31+6vWLZQS1g= X-Google-Smtp-Source: ABdhPJzgMF1l16DQ9GtH0zadj4AFPsgOSdcc0nQjAg5YtJnxuL5F8CiUxO59fKX41tyw11AQZ8TMxRLVn9F6daoXfLE= X-Received: by 2002:a05:6122:130e:: with SMTP id e14mr2099665vkp.26.1644344107461; Tue, 08 Feb 2022 10:15:07 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> <9955.1644342979@kaos.jnpr.net> In-Reply-To: <9955.1644342979@kaos.jnpr.net> From: Warner Losh Date: Tue, 8 Feb 2022 11:14:57 -0700 Message-ID: Subject: Re: buildworld failed To: "Simon J. Gerraty" Cc: George Abdelmalik , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000006a118605d785b2a2" X-Rspamd-Queue-Id: 4JtWQ428t5z3Pch X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=OOf2yJlh; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2f:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000006a118605d785b2a2 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 8, 2022 at 10:56 AM Simon J. Gerraty wrote: > Warner Losh wrote: > > --- sys/abi_compat.c --- > > echo "#include " > sys/abi_compat.c > > sh: cannot create sys/abi_compat.c: No such file or directory > > *** [sys/abi_compat.c] Error code 2 > > > > make[4]: stopped in /usr/src/tools/build/test-includes > > --- sys/acct.c --- > > echo "#include " > sys/acct.c > > sh: cannot create sys/acct.c: No such file or directory > > *** [sys/acct.c] Error code 2 > > > > make[4]: stopped in /usr/src/tools/build/test-includes > > --- sys/aio.c --- > > echo "#include " > sys/aio.c > > sh: cannot create sys/aio.c: No such file or directory > > *** [sys/aio.c] Error code 2 > > > > make[4]: stopped in /usr/src/tools/build/test-includes > > --- sys/acl.c --- > > echo "#include " > sys/acl.c > > sh: cannot create sys/acl.c: No such file or directory > > *** [sys/acl.c] Error code 2 > > > > > > > > Same here for me for the past couple of weeks. Haven't been able to > > identify why it fails. My hunch was that a particular objdir wasn't > > being created. As a workaround I edited the Makefile.inc1 to remove > > the test-includes command (line 1128 I think). > > The sys subdir does not exist. > Why does it exist for me, though? What's making it for me and not for the OP? > Best bet would be to avoid the need: > Oh, I like this and I agree. Do you want to commit, or should I do the honors? Warner > diff --git a/tools/build/test-includes/Makefile > b/tools/build/test-includes/Makefile > index 3ae39a2cb61..eb9016ecc03 100644 > --- a/tools/build/test-includes/Makefile > +++ b/tools/build/test-includes/Makefile > @@ -24,11 +24,11 @@ CFLAGS.event.c= -D_WANT_KEVENT32 > -D_WANT_FREEBSD11_KEVENT > > .include "badfiles.inc" > > -.for h in ${HDRS} > +.for h c in ${HDRS:@x@$x ${x:S,/,_,g:R}.c@} > .if !${BADHDRS:M${h}} > -SRCS+= ${h:R}.c > -CLEANFILES+=${h:R}.c > -${h:R}.c: > +SRCS+= $c > +CLEANFILES+=$c > +$c: > echo "#include <$h>" > ${.TARGET} > .endif > .endfor > > so you get: > > echo "#include " > sys_abi_compat.c > echo "#include " > sys_acct.c > echo "#include " > sys_acl.c > echo "#include " > sys_aio.c > echo "#include " > sys_alq.c > echo "#include " > sys_apm.c > echo "#include " > sys_arb.c > echo "#include " > sys_asan.c > echo "#include " > sys_assym.c > > etc > --0000000000006a118605d785b2a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 8, 2022 at 10:56 AM Simon= J. Gerraty <sjg@juniper.net> = wrote:
Warner Lo= sh <imp@bsdimp.com> wrote:
> --- sys/abi_compat.c ---
> echo "#include <sys/abi_compat.h>" > sys/abi_compat= .c
> sh: cannot create sys/abi_compat.c: No such file or directory
> *** [sys/abi_compat.c] Error code 2
>
> make[4]: stopped in /usr/src/tools/build/test-includes
> --- sys/acct.c ---
> echo "#include <sys/acct.h>" > sys/acct.c
> sh: cannot create sys/acct.c: No such file or directory
> *** [sys/acct.c] Error code 2
>
> make[4]: stopped in /usr/src/tools/build/test-includes
> --- sys/aio.c ---
> echo "#include <sys/aio.h>" > sys/aio.c
> sh: cannot create sys/aio.c: No such file or directory
> *** [sys/aio.c] Error code 2
>
> make[4]: stopped in /usr/src/tools/build/test-includes
> --- sys/acl.c ---
> echo "#include <sys/acl.h>" > sys/acl.c
> sh: cannot create sys/acl.c: No such file or directory
> *** [sys/acl.c] Error code 2
>
>
>
> Same here for me for the past couple of weeks. Haven't been able t= o
> identify why it fails. My hunch was that a particular objdir wasn'= t
> being created. As a workaround I edited the Makefile.inc1 to remove > the test-includes command (line 1128 I think).

The sys subdir does not exist.

Why does= it exist for me, though? What's making it for me and not for the OP?
=C2=A0
Best bet would be to avoid the need:

Oh= , I like this and I agree. Do you want to commit, or should I do the honors= ?

Warner
=C2=A0
diff --git a/tools/build/test-includes/Makefile b/tools/build/test-includes= /Makefile
index 3ae39a2cb61..eb9016ecc03 100644
--- a/tools/build/test-includes/Makefile
+++ b/tools/build/test-includes/Makefile
@@ -24,11 +24,11 @@ CFLAGS.event.c=3D=C2=A0 =C2=A0 =C2=A0-D_WANT_KEVENT32 -= D_WANT_FREEBSD11_KEVENT

=C2=A0.include "badfiles.inc"

-.for h in ${HDRS}
+.for h c in ${HDRS:@x@$x ${x:S,/,_,g:R}.c@}
=C2=A0.if !${BADHDRS:M${h}}
-SRCS+=3D ${h:R}.c
-CLEANFILES+=3D${h:R}.c
-${h:R}.c:
+SRCS+=3D $c
+CLEANFILES+=3D$c
+$c:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 echo "#include <$h>" > ${.TA= RGET}
=C2=A0.endif
=C2=A0.endfor

so you get:

echo "#include <sys/abi_compat.h>" > sys_abi_compat.c echo "#include <sys/acct.h>" > sys_acct.c
echo "#include <sys/acl.h>" > sys_acl.c
echo "#include <sys/aio.h>" > sys_aio.c
echo "#include <sys/alq.h>" > sys_alq.c
echo "#include <sys/apm.h>" > sys_apm.c
echo "#include <sys/arb.h>" > sys_arb.c
echo "#include <sys/asan.h>" > sys_asan.c
echo "#include <sys/assym.h>" > sys_assym.c

etc
--0000000000006a118605d785b2a2-- From nobody Tue Feb 8 18:30:31 2022 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 D3A5319A4ED4 for ; Tue, 8 Feb 2022 18:30:39 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 4JtWly4gZzz3lgl for ; Tue, 8 Feb 2022 18:30:38 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id ECB313C0199; Tue, 8 Feb 2022 18:30:31 +0000 (UTC) Date: Tue, 8 Feb 2022 18:30:31 +0000 From: Brooks Davis To: "Simon J. Gerraty" Cc: Warner Losh , George Abdelmalik , FreeBSD Current Subject: Re: buildworld failed Message-ID: <20220208183031.GB31429@spindle.one-eyed-alien.net> References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> <9955.1644342979@kaos.jnpr.net> 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-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <9955.1644342979@kaos.jnpr.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4JtWly4gZzz3lgl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-3.84 / 15.00]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.941]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net] X-ThisMailContainsUnwantedMimeParts: N --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 08, 2022 at 09:56:19AM -0800, Simon J. Gerraty wrote: > Warner Losh wrote: > > --- sys/abi_compat.c --- > > echo "#include " > sys/abi_compat.c > > sh: cannot create sys/abi_compat.c: No such file or directory > > *** [sys/abi_compat.c] Error code 2 > >=20 > > make[4]: stopped in /usr/src/tools/build/test-includes > > --- sys/acct.c --- > > echo "#include " > sys/acct.c > > sh: cannot create sys/acct.c: No such file or directory > > *** [sys/acct.c] Error code 2 > >=20 > > make[4]: stopped in /usr/src/tools/build/test-includes > > --- sys/aio.c --- > > echo "#include " > sys/aio.c > > sh: cannot create sys/aio.c: No such file or directory > > *** [sys/aio.c] Error code 2 > >=20 > > make[4]: stopped in /usr/src/tools/build/test-includes > > --- sys/acl.c --- > > echo "#include " > sys/acl.c > > sh: cannot create sys/acl.c: No such file or directory > > *** [sys/acl.c] Error code 2 > >=20 > >=20 > >=20 > > Same here for me for the past couple of weeks. Haven't been able to > > identify why it fails. My hunch was that a particular objdir wasn't > > being created. As a workaround I edited the Makefile.inc1 to remove > > the test-includes command (line 1128 I think). >=20 > The sys subdir does not exist. > Best bet would be to avoid the need: >=20 > diff --git a/tools/build/test-includes/Makefile b/tools/build/test-includ= es/Makefile > index 3ae39a2cb61..eb9016ecc03 100644 > --- a/tools/build/test-includes/Makefile > +++ b/tools/build/test-includes/Makefile > @@ -24,11 +24,11 @@ CFLAGS.event.c=3D -D_WANT_KEVENT32 -D_WANT_FREEBSD11_= KEVENT > =20 > .include "badfiles.inc" > =20 > -.for h in ${HDRS} > +.for h c in ${HDRS:@x@$x ${x:S,/,_,g:R}.c@} > .if !${BADHDRS:M${h}} > -SRCS+=3D ${h:R}.c > -CLEANFILES+=3D${h:R}.c > -${h:R}.c: > +SRCS+=3D $c > +CLEANFILES+=3D$c > +$c: > echo "#include <$h>" > ${.TARGET} > .endif > .endfor >=20 > so you get: >=20 > echo "#include " > sys_abi_compat.c > echo "#include " > sys_acct.c > echo "#include " > sys_acl.c > echo "#include " > sys_aio.c > echo "#include " > sys_alq.c > echo "#include " > sys_apm.c > echo "#include " > sys_arb.c > echo "#include " > sys_asan.c > echo "#include " > sys_assym.c >=20 > etc >=20 This would be fine, but should not be necessicary. The sys subdir should be created by AUTOOBJ. -- Brooks --AqsLC8rIMeq19msA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJiArbHAAoJEKzQXbSebgfACOkH/0OO08RALO6u58JAV8dphUNY T/5ma3hfRQjrQ+tcDPwZGjIUiN2Vc9ybGqrN6dbvXGY5nw/boGwvbbYZ36ahEjiP gymuv1aDNhk2oA3I8DVpub8G9qXyPTeNAL28CTHYYcUoD4WYwuJi+0ECU+mH7vB5 IDVOIzZoPw+9AhSGJCunQxPaCFUKIyUvqysd2Nzp02m0SZ6ELHTGhQVt4AecIpBj XE3AcjoLepg8u74PNx7rxJeZ5XRJcLhZl/1SnOGbiuTBNirYM6xNqM6vmSzBtQWn nFtgKq28I9ijB8U4WoSOS6C+DYDmn5ro1HxrNWugQfK0ok7a8864aE4o5iG/sC8= =dh4R -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From nobody Tue Feb 8 19:32:30 2022 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 B969519AC23A for ; Tue, 8 Feb 2022 19:32:39 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtY7W05Qlz4hxv for ; Tue, 8 Feb 2022 19:32:38 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 218E8iQB026510; Tue, 8 Feb 2022 11:32:35 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=aiMWMjxOjF418dp16QX3kxO5/4/8775luG1UZsP+j7k=; b=zdtr6t0azOZoRKpfScxBByTbrDP6j1/9dt7TGgPSVvVhE1sVt9x4e3kWDSiNS68v1yIc uNbo0zamPI15uyxqH6P85/COQ9v/gv1DsiEf18h498V80ZtvNdZG2SDm99wSkqcNJKo4 8qeJNO43DPGdwXzUW6ruXePu5jmx9GGjm6npGihqo8Z7gbHTofUArNEzCWiPXZtDM3ej lfaQ4+Fnc+AkZT+wjHps5msfWZivV7JMjYmpz5RmwDba4FV7VgK8oojCQ5kJy3IDiHut v3I46imTJab22RUcU4Fo28h2gcv5Cd/jrwi33Vy43Mn65LW2vYt7HQxVZl9cjyajaAng EQ== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2176.outbound.protection.outlook.com [104.47.59.176]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3e3t170q1h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Feb 2022 11:32:35 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E9h4E0jPku6buy5RJhS8h6qm9n0T4R5EOtaSM/aSAlc7ZAlYIrAANKnnVKL3ZwQHSo426FvguyfmLxhLIE3W6/fwUC4qv8xOVWu21x3tDTR2y5puLPVkWnQsCJ6R5ZT+unt9ZL7oPwmgvYsRmfFtGy1fs9qsm+hyz0hq4VWWNpshikWclyZDNlbCpvaIz6+1CPZ9172i5nzzRqI47kmEcZVuVsHWfAp9C3ja0T6rwUf0qnloxXDo45A/RadYk7vElv4j4x5KZYoCVPItuNuLpZYxgOPaRDWKHsz61ZcdzJi3U2StOrbsbP+V2HkogsaTnWPiKeKAtz1cojxnN6wAdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aiMWMjxOjF418dp16QX3kxO5/4/8775luG1UZsP+j7k=; b=LWiNXhqmWoyAGnRq6c3F7jNq6gtv4Tu3BUk5BnZbOt31kJLrFIEtfmjRaFbT4+DBJGNrxatEy9dQcdBu40pLCrt8NdQsY/tBoKOW4oarR0mJkb7gHB3MHiqu6P4VthDBv4J7WqV+N7szfAFvTN7RqV9nh9MJ36Qv6/J5AOJcEtDGob0LZ9Lh21bTd9uXNuG0Ot0ElmtTjKiaJf80pcEIxr6beHIu3J+qgQU5O5Ld245upun+CO5+pSEQDP2cnTW+nnzb/OOlLVcwV21GE/omLYmt9X5i1GwrWgqKYKKNnxJlkgZetrAMCx25Cy9k65nT4mjUXQt/kFg1O4NpeBDaSg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.242.15) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aiMWMjxOjF418dp16QX3kxO5/4/8775luG1UZsP+j7k=; b=eFP3W0YHZkobwZMc4QBIcNn0Y6V5udghsvrnz1LDNHJtO51Z2CMxxrmh1gHesx1TMNT/d/ox04pJrNOMRVLwm0JasOQwZKq9Hju6Pbnof+T4JWygk4qA5dQa0bJFLtLNqVxQ3vCjAfAMzm+IVV9oCWhjHxeJ8WqR0ZSUnCJCE7I= Received: from MWHPR1701CA0013.namprd17.prod.outlook.com (2603:10b6:301:14::23) by BY5PR05MB6932.namprd05.prod.outlook.com (2603:10b6:a03:1c9::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.9; Tue, 8 Feb 2022 19:32:32 +0000 Received: from MW2NAM12FT059.eop-nam12.prod.protection.outlook.com (2603:10b6:301:14:cafe::17) by MWHPR1701CA0013.outlook.office365.com (2603:10b6:301:14::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.19 via Frontend Transport; Tue, 8 Feb 2022 19:32:32 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.242.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.242.15) by MW2NAM12FT059.mail.protection.outlook.com (10.13.180.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.5 via Frontend Transport; Tue, 8 Feb 2022 19:32:32 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20; Tue, 8 Feb 2022 13:32:31 -0600 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20; Tue, 8 Feb 2022 13:32:31 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20 via Frontend Transport; Tue, 8 Feb 2022 13:32:31 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 218JWUg5008368; Tue, 8 Feb 2022 11:32:30 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 6ABE69F7C6; Tue, 8 Feb 2022 11:32:30 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 692E89F9A4; Tue, 8 Feb 2022 11:32:30 -0800 (PST) To: Warner Losh CC: George Abdelmalik , FreeBSD Current , Subject: Re: buildworld failed In-Reply-To: References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> <9955.1644342979@kaos.jnpr.net> Comments: In-reply-to: Warner Losh message dated "Tue, 08 Feb 2022 11:14:57 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.2 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <93110.1644348750.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Feb 2022 11:32:30 -0800 Message-ID: <93913.1644348750@kaos.jnpr.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e0af7660-841c-48f5-50b9-08d9eb39c048 X-MS-TrafficTypeDiagnostic: BY5PR05MB6932:EE_ X-MS-Exchange-AtpMessageProperties: SA|SL X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oIWcW/xobb/9NzlYnQPeOdRS+3mz33oPwjQFZdbYVcq4BRTpRAMb5m2XDj4JpLris9MIBtx6rVoFaC9Y8iiprb2gQLosQdFL0iSOp0ShL2x44FrFNncP+muT/o4Jk+EKhmXsgp1BA45FQrKqqgVcWU7AAOi7fHRBm++dcHTaIdRWBFdEPBI8MjIaHifDdi8tglvwzsGYbfqk2p9nbz/v/9ofuEXGxcKRpvnVrBTsED2O4qFySGlxS+TwlSQxJ5EpW/sAiHV91+JU9FScCaau7aaMbDLLDbW/hAI6XTfbVBDr5d0msuVcmirm/6l9aymyYThbLpmmMWo+zPnUcPzqPHaUZU+HpUUSz5byg2TMMjo03zCWxwky73r2hiP6j2WhpBBfFt45gMy542MunaKppqBFiX32CJMquWebOz9q1jD9KNFjwmiN1qEEH68O9AAkZoUl4XWt92OMziVSUG4g3YK11tecCHQgBhfCGKBF2kbmykYjz6S2tls0YO3E51hpyx9d1MdMErAreMcVLuulENM7++cWVc51A7yXNkX0JoaHvkn9du46RiJ802yOQWWnWFBSg0H0E2t2pBBXzCCxrt7TteqJCG20E1+2KI6qiZ+qW2mWmQSOmkmSBYsc6JuuJlA4m5jOmzjGGmarGs/thHZpXUYbVxSvJyQNLDcPn1wAj5n38OMIDuSZ27qDkJ4Z0RMTE/vl3wkcoLY+VZCEpw== X-Forefront-Antispam-Report: CIP:66.129.242.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230001)(4636009)(36840700001)(40470700004)(46966006)(7126003)(6266002)(7696005)(107886003)(2906002)(83380400001)(55016003)(8936002)(4744005)(9686003)(508600001)(47076005)(70586007)(26005)(36860700001)(3480700007)(86362001)(7116003)(356005)(186003)(5660300002)(70206006)(54906003)(6916009)(316002)(4326008)(336012)(81166007)(8676002)(40460700003)(82310400004)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2022 19:32:32.0795 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e0af7660-841c-48f5-50b9-08d9eb39c048 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.242.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT059.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR05MB6932 X-Proofpoint-GUID: pajI_DE8U7ejVk6_oX-LrQOc6KZew4fK X-Proofpoint-ORIG-GUID: pajI_DE8U7ejVk6_oX-LrQOc6KZew4fK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-08_06,2022-02-07_02,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=875 adultscore=0 suspectscore=0 priorityscore=1501 spamscore=0 impostorscore=0 clxscore=1015 malwarescore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202080115 X-Rspamd-Queue-Id: 4JtY7W05Qlz4hxv X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b=zdtr6t0a; dkim=pass header.d=juniper.net header.s=selector1 header.b=eFP3W0YH; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=juniper.net; spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 67.231.152.164 as permitted sender) smtp.mailfrom=sjg@juniper.net X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; FREEFALL_USER(0.00)[sjg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:67.231.152.164]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.152.164:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[juniper.net:+]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; RCVD_IN_DNSWL_NONE(0.00)[104.47.59.176:received]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]; RCVD_COUNT_SEVEN(0.00)[11]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: > > Same here for me for the past couple of weeks. Haven't been able to > > identify why it fails. My hunch was that a particular objdir wasn't > > being created. As a workaround I edited the Makefile.inc1 to remove > > the test-includes command (line 1128 I think). > = > The sys subdir does not exist. > = > Why does it exist for me, though? What's making it for me and not for th= e OP? Unless you cleaned your tree recently, that could just be an artifact of an earlier version of the makefile. > = > Best bet would be to avoid the need: > = > Oh, I like this and I agree. Do you want to commit, or should I do the h= onors? Feel free, I've got my hands full at present. From nobody Tue Feb 8 19:51:59 2022 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 4C34819B8A8A for ; Tue, 8 Feb 2022 19:52:14 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtYZ502HVz4rZV for ; Tue, 8 Feb 2022 19:52:13 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To: From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=PKNPiCu3D4aqWr+iJY2YxGhlhepAvkptMKXaYUFPyqA=; b=o87dIVRQHbVj9yunQI45ElJWPl APOkAngs+HW7rOpBFROyogv7th+hffUxGAxvv4RHbvD5hs5p+Rac3rnbryu3V/1s44ptmLMMigBaf DxZCW3Pr1d7hCzO5X6Tx34EGzSy/1HhETa5VxrPYsBXNR4TlmQOS4Ui7gQNZE7OO+Cr9Q2MJvElMc 5cvF85NvqzuONTn+IPDdUwXp1GwW3fACQuYctSWJOCfYgIoEHwyB3r76MhtYbgOiebqT+PK8c8lgZ I2iMUhjXO+5ugxLdbBfzNxSDgwzKBivj5Y0BsgqjmoHMAjfM70Su9jturrKBVCe3F7+5RI32cjRQB 7RwCxrgQ==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:21726 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nHWWt-000199-5u for freebsd-current@freebsd.org; Tue, 08 Feb 2022 13:51:59 -0600 Received: from 2600:1700:210:b18f:d412:350c:9cc4:55b4 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Tue, 08 Feb 2022 13:51:59 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Tue, 08 Feb 2022 13:51:59 -0600 From: Larry Rosenman To: Freebsd current Subject: Panic, CURRENT, yesterday Message-ID: <1ae8c6664f33959f69be4d61a8c545f3@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JtYZ502HVz4rZV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=o87dIVRQ; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I got the following last night while doing a poudriere run as well as a full bacula backup: borg.lerctr.org dumped core - see /var/crash/vmcore.0 Mon Feb 7 23:05:48 CST 2022 FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #54 ler/freebsd-main-changes-n252969-5e5fd0c788c: Sat Feb 5 14:48:30 CST 2022 root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL amd64 panic: ng_snd_item: 42 != 290 GNU gdb (GDB) 11.2 [GDB v11.2 for FreeBSD] Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel... Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... Unread portion of the kernel message buffer: panic: ng_snd_item: 42 != 290 cpuid = 0 time = 1644295724 KDB: stack backtrace: #0 0xffffffff80515fc5 at kdb_backtrace+0x65 #1 0xffffffff804cbaef at vpanic+0x17f #2 0xffffffff804cb8c3 at panic+0x43 #3 0xffffffff82c765b7 at ng_snd_item+0x587 #4 0xffffffff82c8f263 at ng_ether_output+0xb3 #5 0xffffffff805e0c1d at ether_output+0x6cd #6 0xffffffff805f6251 at arpintr+0xd71 #7 0xffffffff805e5587 at netisr_dispatch_src+0x97 #8 0xffffffff805e0f1e at ether_demux+0x14e #9 0xffffffff82c8f89c at ng_ether_rcv_upper+0x12c #10 0xffffffff82c76dab at ng_apply_item+0x7eb #11 0xffffffff82c7638d at ng_snd_item+0x35d #12 0xffffffff82c76dab at ng_apply_item+0x7eb #13 0xffffffff82c7638d at ng_snd_item+0x35d #14 0xffffffff82c8f33f at ng_ether_input+0x9f #15 0xffffffff805e21d7 at ether_nh_input+0x217 #16 0xffffffff805e5587 at netisr_dispatch_src+0x97 #17 0xffffffff805e138d at ether_input+0x5d Uptime: 2d7h20m52s Dumping 28321 out of 131023 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff804cb6ff in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:487 #3 0xffffffff804cbb5e in vpanic (fmt=0xffffffff82c7fd98 "%s: %d != %d", ap=) at /usr/src/sys/kern/kern_shutdown.c:920 #4 0xffffffff804cb8c3 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:844 #5 0xffffffff82c765b7 in ng_snd_item (item=0xfffff8116a9f3900, flags=0) at /usr/src/sys/netgraph/ng_base.c:2256 #6 0xffffffff82c8f263 in ng_ether_output (ifp=, ifp@entry=, mp=0xfffffe025a5b2868, mp@entry=) at /usr/src/sys/netgraph/ng_ether.c:294 #7 0xffffffff805e0c1d in ether_output (ifp=0xfffff8010dc57000, m=0xfffff81736a3f600, dst=, ro=) at /usr/src/sys/net/if_ethersubr.c:427 #8 0xffffffff805f6251 in in_arpinput (m=0xfffff81736a3f600) at /usr/src/sys/netinet/if_ether.c:1129 #9 arpintr (m=0xfffff81736a3f600, m@entry=) at /usr/src/sys/netinet/if_ether.c:739 #10 0xffffffff805e5587 in netisr_dispatch_src (proto=4, source=source@entry=0, m=0xfffff81736a3f600) at /usr/src/sys/net/netisr.c:1153 #11 0xffffffff805e58df in netisr_dispatch (proto=, m=) at /usr/src/sys/net/netisr.c:1244 #12 0xffffffff805e0f1e in ether_demux (ifp=ifp@entry=0xfffff8010dc57000, m=, m@entry=0xfffff81736a3f600) at /usr/src/sys/net/if_ethersubr.c:926 #13 0xffffffff82c8f89c in ng_ether_rcv_upper (hook=, hook@entry=, item=0xfffff8116a9f3900, item@entry=) at /usr/src/sys/netgraph/ng_ether.c:742 #14 0xffffffff82c76dab in ng_apply_item (node=node@entry=0xfffff8018a9b8c00, item=item@entry=0xfffff8116a9f3900, rw=0) at /usr/src/sys/netgraph/ng_base.c:2406 #15 0xffffffff82c7638d in ng_snd_item (item=0xfffff8116a9f3900, item@entry=, flags=0, flags@entry=) at /usr/src/sys/netgraph/ng_base.c:2323 #16 0xffffffff82c76dab in ng_apply_item (node=node@entry=0xfffff8115dd94300, item=item@entry=0xfffff8116a9f3900, rw=0) at /usr/src/sys/netgraph/ng_base.c:2406 #17 0xffffffff82c7638d in ng_snd_item (item=item@entry=0xfffff8116a9f3900, flags=flags@entry=0) at /usr/src/sys/netgraph/ng_base.c:2323 #18 0xffffffff82c8f33f in ng_ether_input (ifp=, ifp@entry=, mp=0xfffffe025a5b2cf8, mp@entry=) at /usr/src/sys/netgraph/ng_ether.c:255 #19 0xffffffff805e21d7 in ether_input_internal (ifp=0xfffff8010dc57000, m=0xfffff81736a3f600) at /usr/src/sys/net/if_ethersubr.c:661 #20 ether_nh_input (m=, m@entry=) at /usr/src/sys/net/if_ethersubr.c:742 #21 0xffffffff805e5587 in netisr_dispatch_src (proto=proto@entry=5, source=source@entry=0, m=m@entry=0xfffff81736a3f600) at /usr/src/sys/net/netisr.c:1153 #22 0xffffffff805e58df in netisr_dispatch (proto=, proto@entry=5, m=, m@entry=0xfffff81736a3f600) at /usr/src/sys/net/netisr.c:1244 #23 0xffffffff805e138d in ether_input (ifp=0xfffff8010dc57000, m=0xfffff81736a3f600) at /usr/src/sys/net/if_ethersubr.c:833 #24 0xffffffff821a934d in bce_rx_intr (sc=0xfffffe02a141c000) at /usr/src/sys/dev/bce/if_bce.c:6721 #25 bce_intr (xsc=) at /usr/src/sys/dev/bce/if_bce.c:7870 #26 0xffffffff80490929 in intr_event_execute_handlers (ie=0xfffff8010dac6900, p=) at /usr/src/sys/kern/kern_intr.c:1205 #27 ithread_execute_handlers (ie=0xfffff8010dac6900, p=) at /usr/src/sys/kern/kern_intr.c:1218 #28 ithread_loop (arg=, arg@entry=0xfffff8015d3683a0) at /usr/src/sys/kern/kern_intr.c:1306 #29 0xffffffff8048d3a0 in fork_exit ( callout=0xffffffff804906d0 , arg=0xfffff8015d3683a0, frame=0xfffffe025a5b2f40) at /usr/src/sys/kern/kern_fork.c:1102 #30 (kgdb) core is available, and I can give access and/or send the core and kernel/debug stuff. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Tue Feb 8 22:52:27 2022 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 DB0F619B59A5 for ; Tue, 8 Feb 2022 22:52:38 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtdZF5cCpz3M7H; Tue, 8 Feb 2022 22:52:37 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 218MitPp004247; Tue, 8 Feb 2022 14:52:34 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=SrwkUmpK2tflCRckeFX7qo+B2ki0e0O35qsFFKqzbgg=; b=ySF+CbljGp4wqsAmBx02NVdq+G2YlMS2J2+8EnJHH1BFk4azjeiBACutozygfk9zXf3b f1CKdKk/56UanDgQDSwK6iO/09bcJW6pJYQlYFR5iKudN2jenTppaZ1EX7K0zbOLRrZF CczR/j6S+lQEzug3fws6oen9oYApRWl+0JtgX+JGq5sogShJ9pOeu+Yy8S8poJ5d6L9L iHOHweSKPhyEGeU9bOE5ox34hU9PdFBiXHKtlWWpdfi0EGusW8bllljj6HfLJTMw17Ks W47Le5qOqzgEq9v6EMzY5cvxXuLHu40gxskYbWgOsdrcOG+B4And05WUaaN7FSlE6Ac6 gA== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2174.outbound.protection.outlook.com [104.47.59.174]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3e3t228x4w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Feb 2022 14:52:34 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c9AkUNb07bGQdF51tg3FDl0PGTV9EJJoE3UlwbvxnKK3w3O/e0r080FmEROEOkK8xvs75XmNTO4f/MBCmPxI7dy2vl7zGWAFkghhxyNGFgOT3NNHlIz7S291HdAXdpLK3Gv8zGfpjiStKj5ND42K1kwtWRxCvJgbiEvx6Uqc6i9b9owiR6xOWC7jzDoZvzxMOP+CO6kl0pU9hHTDZISAEJVeyDfm7Nq0UHX5vxD0hythREIHMAmK2FWH4yc8+FlQz6mw8xiaSJJJXcllQKaHFwROPrXvG26OdzOZLX2CVCjl58v14HzabCVZbHNqZlc0noUNUf/PhRvBH0kIZfYWXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SrwkUmpK2tflCRckeFX7qo+B2ki0e0O35qsFFKqzbgg=; b=RkhW48nyTi5nUOAKk5OUQROI58yb9lfCV+XFOYwQK78qsXgowNOQ7adpXAyuDVrCKxqjgEU4itq90Nv+wYblzjYjEdvoRdhIFz4mmjhF2WveqHGS0LuIm4wedsfNukeLa/4K3mCOdoOmhJGJdQ0MFX+hq5e1lS5wtj1Y2kkXm6DKmEazupVE6YxC9nnGSE8Sn5aVndgbH0HbQiEJ+c5tSb3jIVQjx7Wp/JQOJKQe4CvG/34WcUSZBJ5Z2XbxaTZbqR16LaY9jOfvEhBy0IVHLoGzAyCSQFdILLmKcZ/QxGmpntdK3UohTuVj3rpOYQXQjftTqTcOw6wWci5jVeGTvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.242.14) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SrwkUmpK2tflCRckeFX7qo+B2ki0e0O35qsFFKqzbgg=; b=E/59eoM4w/e/Er0m3h6boODAVjutTyN5y3Zos2CliBnh/xC9wZdSfAxlstMr7xjDrHwQSa0QALUY5o0a24aCBm3A0/ZNLzIoiAeQhEg/otbeiusQZtJbydhuH+gvcR2AVVBVIziU6TBZoknhet6i5LIyr6izvm3YmCf+WDHO3P8= Received: from BN6PR17CA0006.namprd17.prod.outlook.com (2603:10b6:404:65::16) by SN6PR05MB5199.namprd05.prod.outlook.com (2603:10b6:805:e5::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11; Tue, 8 Feb 2022 22:52:30 +0000 Received: from BN8NAM12FT055.eop-nam12.prod.protection.outlook.com (2603:10b6:404:65:cafe::8d) by BN6PR17CA0006.outlook.office365.com (2603:10b6:404:65::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.19 via Frontend Transport; Tue, 8 Feb 2022 22:52:30 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.242.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.242.14) by BN8NAM12FT055.mail.protection.outlook.com (10.13.182.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.5 via Frontend Transport; Tue, 8 Feb 2022 22:52:29 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20; Tue, 8 Feb 2022 16:52:29 -0600 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20; Tue, 8 Feb 2022 16:52:28 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20 via Frontend Transport; Tue, 8 Feb 2022 16:52:28 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 218MqRAt005317; Tue, 8 Feb 2022 14:52:28 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 9E90A9F9AE; Tue, 8 Feb 2022 14:52:27 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 9D0549F93B; Tue, 8 Feb 2022 14:52:27 -0800 (PST) To: Brooks Davis CC: Warner Losh , George Abdelmalik , FreeBSD Current , Subject: Re: buildworld failed In-Reply-To: <20220208183031.GB31429@spindle.one-eyed-alien.net> References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> <9955.1644342979@kaos.jnpr.net> <20220208183031.GB31429@spindle.one-eyed-alien.net> Comments: In-reply-to: Brooks Davis message dated "Tue, 08 Feb 2022 18:30:31 +0000." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.2 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35635.1644360747.1@kaos.jnpr.net> Date: Tue, 8 Feb 2022 14:52:27 -0800 Message-ID: <38435.1644360747@kaos.jnpr.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f7a5b166-c6b6-4723-5cf1-08d9eb55af8e X-MS-TrafficTypeDiagnostic: SN6PR05MB5199:EE_ X-MS-Exchange-AtpMessageProperties: SA|SL X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: idIfkzzG+uZdEKgDS+kZ+bNmS6XbRb++8kkPeV8FzdbWVlqIf+mjIFlz4im2Ir+qEzHnrZ/rMjI1mx4y/Tz02fNnlM06ksuNPTee2jEwCU6jZpEu/cgWl5L8ED9RSc5CyRQPiSVbnsZwqpSHEIkuvjifCaBGxMvCv5aE1V21YGpmUbehkN2KKkNM5m1C0rIKbm2mGuvyD3QM0Mt2jr02OA1vwYkM6NNx0iukUwAks+elgKPM7w6ZYzpLx9wZuBzfc8QiiRNo8J7B4Lc3wH6kmYjAFbyTza3C6geuyoNEzQYxj7uqgR10FNxNq0j3GQLHxxnTljgvmdOP83FTQLi1QmMc/7RYssh7fwLgeyK7zbrAC+CvowQjTHD8m+uZ4oaFukYceC4a+YPnTKsS+axMRbSlD7f6tkVqMxlpsn/smlpzyYaxGGOkqChwbYfIXHY+yfMFB3iS1oUuQgpC6DMW+YsSTu3wJdREZ9Wt/5Wt8L/zr39dIbxewlecG4uTKTFJM7wTCJ3YTXOq8Vi1lwj2FBcFhDn9zt1ojBzGyJ7Iq+Iprj4b5VJ02EV6w1WXYkjJlj1FNrO+v+lnnvQWIdaxfNfX+5ToOizWExNLBNJ2lIVvXWPx1R/j0CJ+8j4HMWsjuVGYdFhR+nI/Brpdu2asfsF3Ea1r37tf5doG1cFik/EkMO1CQ7PglnQ7gbAalRw+lUyHql0Ba73m6RUCAEIkJNUHiE5olwC+xBztG7YJhNssNjL4hb2bIGQWmNMeLph8 X-Forefront-Antispam-Report: CIP:66.129.242.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230001)(4636009)(36840700001)(46966006)(40470700004)(81166007)(47076005)(40460700003)(356005)(508600001)(186003)(26005)(7126003)(6266002)(107886003)(336012)(7696005)(9686003)(316002)(54906003)(8936002)(70586007)(70206006)(8676002)(4326008)(7116003)(5660300002)(36860700001)(3480700007)(82310400004)(55016003)(6916009)(4744005)(2906002)(86362001)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2022 22:52:29.8319 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f7a5b166-c6b6-4723-5cf1-08d9eb55af8e X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.242.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM12FT055.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB5199 X-Proofpoint-ORIG-GUID: oQQEw4KJvuAWgETsIkcExtCybxXmsZok X-Proofpoint-GUID: oQQEw4KJvuAWgETsIkcExtCybxXmsZok X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-08_07,2022-02-07_02,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 adultscore=0 mlxlogscore=665 clxscore=1011 bulkscore=0 malwarescore=0 spamscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 impostorscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202080133 X-Rspamd-Queue-Id: 4JtdZF5cCpz3M7H X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b=ySF+Cblj; dkim=pass header.d=juniper.net header.s=selector1 header.b="E/59eoM4"; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=juniper.net; spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 208.84.65.16 as permitted sender) smtp.mailfrom=sjg@juniper.net X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; FREEFALL_USER(0.00)[sjg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:208.84.65.16]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[juniper.net:+]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; RCVD_IN_DNSWL_NONE(0.00)[104.47.59.174:received]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:26211, ipnet:208.84.65.0/24, country:US]; RCVD_COUNT_SEVEN(0.00)[11]; RCVD_IN_DNSWL_LOW(-0.10)[208.84.65.16:from] X-ThisMailContainsUnwantedMimeParts: N Brooks Davis wrote: > > This would be fine, but should not be necessicary. The sys subdir should > be created by AUTOOBJ. .OBJDIR should be (and is), not .OBJDIR/sys making that subdir is up to the makefile and would also fix the problem, but given the nature of what the makefile is doing just replacing / with _ is simpler. From nobody Wed Feb 9 00:10:41 2022 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 6483E19BCF3B for ; Wed, 9 Feb 2022 00:10:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtgJX2bX5z4Zkb for ; Wed, 9 Feb 2022 00:10:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2e.google.com with SMTP id n14so259156vkk.6 for ; Tue, 08 Feb 2022 16:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VO+Nk8EInPOv5JDVSEAEvD4WkGkRotc9rIcZxBLq3W4=; b=bLs3Z2zFnNVivqqxh/Rr2JalbH9z9+l8IHnhXP4BhnHd0O9HvTMbvK3LT1XLzV+/pP 0F2V7XSyHvMNhRWbw72/xd0pZnwwY2Km2jyWZJYlYqpIGRfRWmF5gtAUVJZp4rl3OH48 HSfNLQ/cvM5J3RX8EAufhvBfgXpEgT+PO6TQ47rEyz2rRIHzbvdTqUyRz4Kmb90HtQX4 Gp+HbZZLDU9nM0ZCn4zhY1xxD1qQ5VpJkMzMNJY+W/ney/GhjokZOIO0LWCjD3flRCB3 5lgL2iqzP2oPcW2UgCYhsl2O34SPsV/pz8baegFxSd1XTNpF0i8jZod0hVhm3hze37Ad UrxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VO+Nk8EInPOv5JDVSEAEvD4WkGkRotc9rIcZxBLq3W4=; b=SOzTjKtZBUPa5RYVSMItoXWKwH7nuj76Au/MXPSZDwF1Hwh15NS6EpxUGXpCXRaifV ukx9Qf6s2HuApdjnmBUC7z72FQgYGXq6mVPKf1Hk9RkjXcYWEEu7OGKQM7UXhwrHe85z eLS62YljxaO4W8slLQ66pJT/EutR3OAFHkBd8fbvrKjAKJUh6za/fZ+oKRLRH2XmyuqI D6Ho7RIe+k2DZmON5wPyqoF1jG+AfjsmeOdkb1Ux0wXj1G93n0P6SVgwEtD0XEY6dYd5 +aPx056FsBd463cxmkbktI+f9J0KhhThgTeirWz6hJsyFEj8yI86Ui9TxYMIAtAg8sVW DpLA== X-Gm-Message-State: AOAM5327Mp7Yq8iT+mSRF4uXM6anKwERfmITHttyXhO0U3gW68iVV/4a T9WG0yBKQN+Kmqv6jsD3nefyJCezt7gcR0FhVxhhRw== X-Google-Smtp-Source: ABdhPJw98CVEWlsDJ6/JrHtFlNm5dHGUbVAkTCs8sHJOrDaPlp+0h5p07VvAnySSLminS5+ZQFa+Lb6BBNM7WounN8E= X-Received: by 2002:a05:6122:181a:: with SMTP id ay26mr2470804vkb.5.1644365451576; Tue, 08 Feb 2022 16:10:51 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> <9955.1644342979@kaos.jnpr.net> <20220208183031.GB31429@spindle.one-eyed-alien.net> <38435.1644360747@kaos.jnpr.net> In-Reply-To: <38435.1644360747@kaos.jnpr.net> From: Warner Losh Date: Tue, 8 Feb 2022 17:10:41 -0700 Message-ID: Subject: Re: buildworld failed To: "Simon J. Gerraty" Cc: Brooks Davis , George Abdelmalik , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000009f8d4005d78aaa1f" X-Rspamd-Queue-Id: 4JtgJX2bX5z4Zkb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=bLs3Z2zF; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2e:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000009f8d4005d78aaa1f Content-Type: text/plain; charset="UTF-8" On Tue, Feb 8, 2022 at 3:52 PM Simon J. Gerraty wrote: > Brooks Davis wrote: > > > > This would be fine, but should not be necessicary. The sys subdir should > > be created by AUTOOBJ. > > .OBJDIR should be (and is), not .OBJDIR/sys > making that subdir is up to the makefile and would also fix the problem, > but given the nature of what the makefile is doing just replacing / with > _ is simpler. > Agreed. Testing this. Warner --0000000000009f8d4005d78aaa1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 8, 2022 at 3:52 PM Simon = J. Gerraty <sjg@juniper.net> w= rote:
Brooks Dav= is <brooks@freeb= sd.org> wrote:
>
> This would be fine, but should not be necessicary. The sys subdir shou= ld
> be created by AUTOOBJ.

.OBJDIR should be (and is), not .OBJDIR/sys
making that subdir is up to the makefile and would also fix the problem, but given the nature of what the makefile is doing just replacing / with _ is simpler.

Agreed. Testing this.

Warner
--0000000000009f8d4005d78aaa1f-- From nobody Wed Feb 9 00:28:01 2022 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 B8B7719A7135 for ; Wed, 9 Feb 2022 00:28:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtghW5x5Dz4hQl for ; Wed, 9 Feb 2022 00:28:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2c.google.com with SMTP id u82so261828vkb.11 for ; Tue, 08 Feb 2022 16:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oJpwM2j596xeWKhcae3tWcXF5gHsXo0bHUTXcn4iIXU=; b=OvsDwXCcu92eHAhH8v9vIREaJ6FU8LJF0h1A8fbB2tIa6HbpEJ9JP6ZlZeonVhut5l IXD2/4s17APE2vKRXvPJL7/gm1+/TCNU4wJEuGYpvLDXOBG5YCKOT4kmiG2KyOCkOE7b I4iNdpHmqpZeXRLZ4kD0yzaoAwsIcZhT8SJlQuT1jWbgF61EKiGWHaVbomifAsEj5NxP rHnQ2VKtOJ2aCubbPI9JYBn9eY1E0Sj0PhzLlvBbUU7H16BFsPUlfVftkeHSzWsllwd6 5YtaMql8vX7+Kv1cJh4312qONtuXfabgx+t56tSO+RJMjY6kv4k7fLoiyeZ7On+oXiGx a3+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oJpwM2j596xeWKhcae3tWcXF5gHsXo0bHUTXcn4iIXU=; b=sdeTYD5ok4x8dGWzZp39JwtukPx7ceWCi1keV3wyU9GH6jQem/4vvw0q6ug3VUlUao pxzU1cuF7ya4B3BQyE4oEyPUip8xu7QmQ8bhmoqxC0Fdd/bTWnLjkBuilStpmsnXApjt yvoGIgP2Im87sKNJkhkXp6yGNd8ilk/Q2ld8lPx49HRJuzqoaAU1eOxQIIPO8gev9lmK V4ddh2Lgz+Fd8impTXNLLEXZsQRnac8wGEsE39hyzhOKLEiVubCty1Y9MW1jOCL0FXpM NAzPRIi0TdzvhRD0auL+CnxH44BAbCBg5nUB14zP3bsHA7WWy6caDWLR56TQPJyVadMk 9QMQ== X-Gm-Message-State: AOAM531AptY5hPEnGwLwMJ09WWiFjYO8p6Y3HlMd6Xmtof25knh8THAV 5ruoPpo+CJoi5Jp+aekWYhxpPIWfTH/6G9X/wWSRlg== X-Google-Smtp-Source: ABdhPJzTyWJa21ddi5wtyBGzOPuBX6V45VEq+J7ZgjzWYwxFW6NXp54RSU8mXKqr0Sgw/+GyzhKy31E6yxvaUMWW/k4= X-Received: by 2002:a05:6122:181a:: with SMTP id ay26mr2487433vkb.5.1644366491167; Tue, 08 Feb 2022 16:28:11 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> <9955.1644342979@kaos.jnpr.net> <20220208183031.GB31429@spindle.one-eyed-alien.net> <38435.1644360747@kaos.jnpr.net> In-Reply-To: From: Warner Losh Date: Tue, 8 Feb 2022 17:28:01 -0700 Message-ID: Subject: Re: buildworld failed To: "Simon J. Gerraty" Cc: Brooks Davis , George Abdelmalik , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000009642c105d78ae823" X-Rspamd-Queue-Id: 4JtghW5x5Dz4hQl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=OvsDwXCc; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2c:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000009642c105d78ae823 Content-Type: text/plain; charset="UTF-8" I went ahead and committed this as 5ae6cc00111c since we chatted about it here. Warner On Tue, Feb 8, 2022 at 5:10 PM Warner Losh wrote: > > > On Tue, Feb 8, 2022 at 3:52 PM Simon J. Gerraty wrote: > >> Brooks Davis wrote: >> > >> > This would be fine, but should not be necessicary. The sys subdir should >> > be created by AUTOOBJ. >> >> .OBJDIR should be (and is), not .OBJDIR/sys >> making that subdir is up to the makefile and would also fix the problem, >> but given the nature of what the makefile is doing just replacing / with >> _ is simpler. >> > > Agreed. Testing this. > > Warner > --0000000000009642c105d78ae823 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I went ahead and committed this as=C2=A05ae6cc00111c since= we chatted about it here.

Warner

On Tue, Feb 8, 20= 22 at 5:10 PM Warner Losh <imp@bsdimp.= com> wrote:


On Tue, Feb 8, 2022 at 3:52 PM Sim= on J. Gerraty <sjg@= juniper.net> wrote:
Brooks Davis <brooks@freebsd.org> wrote:
>
> This would be fine, but should not be necessicary. The sys subdir shou= ld
> be created by AUTOOBJ.

.OBJDIR should be (and is), not .OBJDIR/sys
making that subdir is up to the makefile and would also fix the problem, but given the nature of what the makefile is doing just replacing / with _ is simpler.

Agreed. Testing this.

Warner
--0000000000009642c105d78ae823-- From nobody Wed Feb 9 00:43:18 2022 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 6EAF319B146C for ; Wed, 9 Feb 2022 00:43:20 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 4Jth1z5Pwpz4pX2 for ; Wed, 9 Feb 2022 00:43:19 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id ED41B3C0199; Wed, 9 Feb 2022 00:43:18 +0000 (UTC) Date: Wed, 9 Feb 2022 00:43:18 +0000 From: Brooks Davis To: "Simon J. Gerraty" Cc: Warner Losh , George Abdelmalik , FreeBSD Current Subject: Re: buildworld failed Message-ID: <20220209004318.GC31429@spindle.one-eyed-alien.net> References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> <9955.1644342979@kaos.jnpr.net> <20220208183031.GB31429@spindle.one-eyed-alien.net> <38435.1644360747@kaos.jnpr.net> 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-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <38435.1644360747@kaos.jnpr.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4Jth1z5Pwpz4pX2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-3.90 / 15.00]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net] X-ThisMailContainsUnwantedMimeParts: N --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 08, 2022 at 02:52:27PM -0800, Simon J. Gerraty wrote: > Brooks Davis wrote: > >=20 > > This would be fine, but should not be necessicary. The sys subdir should > > be created by AUTOOBJ. >=20 > .OBJDIR should be (and is), not .OBJDIR/sys We've had support for relative paths in SRCS since 2015 (cee9be4971a56f2a748eb78df97b72e42fe860ab). If this is broken if some supported modes we should fix it or remove it (but I belive clang/llvm depends on it). -- Brooks --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJiAw4mAAoJEKzQXbSebgfA3lkH/A1WRjIw7NPoSFIPLED6Lm+l FFbWSqvMltH4jugZys2xeGq+JFgKTiRktNdKSBxPxd4ShL4Bockzp7TKw0/XTin5 rWKfMeG6nUEr16aQJAUlSQzieV7rk1qiw9vTXCT/cMS6zOCXsWaIOMr0wFK52T8w XouA2kiA+O8j4ro3jbq605Ajp0u90nqAUiL2YR4oXTvLR9mhYN0rANtGY9iIJ4GC pbVq3+Ipdugw91wGy3OVceT2jX4qIdPujID+Fx8A+RmBDXMX/Yhj+CEprRyFGlHB UWpcSIx9MvRNYG338vtB2y+/B+woVe01s6M/HLppav2kf+hIszi0pn/Lsf5R9rU= =FVtY -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From nobody Wed Feb 9 04:21:44 2022 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 DFC9A19C5303 for ; Wed, 9 Feb 2022 04:21:54 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jtmt90wVxz3mLw; Wed, 9 Feb 2022 04:21:53 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 218Mils4019199; Tue, 8 Feb 2022 20:21:50 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=jVvrtooFzD00AvfoOdiaDSeCyOAS809oVQHlUmAT3Wc=; b=pzqJlV3xfpDebRHJcauCbU5oYSRUZj8fCLh0HK3LpO4D9PbP6d6U2llKmsIR9NZ4HQya OfwnGAtAB5Vf2JoKNQboiaNETcnUISRNg7Y7YsHWlOupuxSqJ1SN5zAa6hS/A6guu7bb CVjs8k6V8NhP9xkWoCCypCQf+DzVISRCnWl3bwEZFn0nia3UnastleS4hGHB0aFvM66O 0fRHr3uxaYfPfwtMdJsNQaj4MZYUFwVCEDEUYWtySi7XwQ/0F1KgfA1fGKXcMEmp6lRf ugg4g6C7ZIX5H828J5PL91DB8vu77MohoK4DpeYJt5FehnXDkebt7sFmp62PSNKVys8W Vg== Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2109.outbound.protection.outlook.com [104.47.55.109]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3e3tu1sc94-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Feb 2022 20:21:49 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bQL5V5jcXlkvEFcdbwIectoMrM85prft6xDH1cWnha6FGnQd9gW7g5OVF/S+MWIJLz6wcanufRN6YYscCT/xyRDiU1kX6OumPGKrAO1hBvQUD85PrDD+RU+uMH4LRqxWPo25MmWSAWI0h8AcCGf/t0LWk1HatCOag8DQZov70yWbdFDclBYhpw9oWjHvZpNkM60XFzGgh976ePl0R3Idn4+XstmjQ+6CLkBnimZHqSPHogWJav19yuzZxROj5pGD1vsj48ssB5yPabMLV7oTws7dWQzmJ+zmcmAoUSXHuDFK3cWEJtym40TvY/o6uPyGbwO3BUuKze3mw4ipJO+prw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jVvrtooFzD00AvfoOdiaDSeCyOAS809oVQHlUmAT3Wc=; b=afx87717gqrFarB9ylSYJ9sEIxnnIioZTDfu3UfhLOBCUVA4devDj2L36Mb2mSw9+ptSJ1GA8kle6vkj4FqN7VjHYXZSRrqCa9AZ+orYMEzo+hw2lyca6yZI6NvR9zlVCRGvyRH2fk2hXQXl1O42JQrOwRwKOidvjkIpKrOyqhQp4ZvJ6XkJtpOPlSP6A6kmUx47YRz3XA5xqua1wc0gSiRB0xNbzVrfn/3a8yRAOGFbPmVc/L/0Qmrc4IwH0HOR4ZzztXu2jd4aaGxAIy/RdOUdz6tCvjd9snrtEa/3FLJlDC1T5+8E9Oz7O6Ov59JknrL92Vu3a/1RWIujTE0ywA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.242.15) smtp.rcpttodomain=fork.id.au smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jVvrtooFzD00AvfoOdiaDSeCyOAS809oVQHlUmAT3Wc=; b=L15Lx59Myaz9XG/NWIn72a9zmC4E7UblKLunSl8fl54LRyOgIRb2ThMXv/48KIE6cXhiAyF9bBUSVkZ0pznBLeGIwg1ggL1NoLOLz7xQvRDlwFc+zlMqDlRhkXXQAVbF/eP6rcdq+nvoFcrWSObQPorU9S6R3APcY2DoPY0MSD8= Received: from MW4PR03CA0281.namprd03.prod.outlook.com (2603:10b6:303:b5::16) by DM6PR05MB4683.namprd05.prod.outlook.com (2603:10b6:5:fb::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11; Wed, 9 Feb 2022 04:21:47 +0000 Received: from MW2NAM12FT032.eop-nam12.prod.protection.outlook.com (2603:10b6:303:b5:cafe::c8) by MW4PR03CA0281.outlook.office365.com (2603:10b6:303:b5::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.17 via Frontend Transport; Wed, 9 Feb 2022 04:21:47 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.242.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.242.15) by MW2NAM12FT032.mail.protection.outlook.com (10.13.180.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.5 via Frontend Transport; Wed, 9 Feb 2022 04:21:46 +0000 Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.922.20; Tue, 8 Feb 2022 22:21:46 -0600 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Tue, 8 Feb 2022 20:21:46 -0800 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20 via Frontend Transport; Tue, 8 Feb 2022 22:21:45 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 2194LiLG021874; Tue, 8 Feb 2022 20:21:44 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 3FAFF9F6EA; Tue, 8 Feb 2022 20:21:44 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 3D73B9F9C4; Tue, 8 Feb 2022 20:21:44 -0800 (PST) To: Brooks Davis CC: Warner Losh , George Abdelmalik , FreeBSD Current , Subject: Re: buildworld failed In-Reply-To: <20220209004318.GC31429@spindle.one-eyed-alien.net> References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> <9955.1644342979@kaos.jnpr.net> <20220208183031.GB31429@spindle.one-eyed-alien.net> <38435.1644360747@kaos.jnpr.net> <20220209004318.GC31429@spindle.one-eyed-alien.net> Comments: In-reply-to: Brooks Davis message dated "Wed, 09 Feb 2022 00:43:18 +0000." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.2 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11362.1644380504.1@kaos.jnpr.net> Date: Tue, 8 Feb 2022 20:21:44 -0800 Message-ID: <13362.1644380504@kaos.jnpr.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 49017c57-a8f4-46a1-ffee-08d9eb83af88 X-MS-TrafficTypeDiagnostic: DM6PR05MB4683:EE_ X-MS-Exchange-AtpMessageProperties: SA|SL X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: D5WrVEXo0z7hBgrr2ivy0VY/NDB0sYcIrj9GOfFJzpXvpXGgFn24y+L7gegxg5im7Hh8JlZl12+f2zY7QfwWuBb0X7gHC3dMVUGuW4DpF0iPy+74TtQ2EgXnx3BIJ2qo/CZPW5apfq9D0irEMeHpTVmJGwHfogdeUDB7Dy/OtV4LMTDej03Mo/tvfQIqvtUVPcezc3SelcmDJoUBehLokGlU7Of4wDxW9jCyGcr/h+Nes7QWGz3zBvRMR8GbEwXL451iPYa2rOBjNOx1YZuvjy60kjUi64A9xlbk5eD2SiT0PUHfnqLlSdChgIQDwLX4SiTXuwkcPJOzoJQDco/9fjCUttZGG51zqU1YZeAiskBfZynD1fe+MvLJToUTVs/pU8td1DX2NRXsofG3z8Vw3T+ANNspUwhVyUfp6UUyMcWO2Xg+PFvhBu4GSTRLRB+ghKt0f+MnbTRQq01QC3TIeh/xObf1b127iWetbN2vRHeAw+3RStcIAeLSKASX0d7XAdNoNwYifLPiCsExGGxnkIjz49jEr+1YkKRnYB8U9XnNByJI18xJQ4gWF5JPhQAwhyQ0uICus7yjYUtm+BNY94A2gtW1YDhscNT/DkYodrqTQPUFym+UkDu2jti173KQcjKZHVFFeHqT5ksG1Y8iKKC41F7FLzcX7uPHklHky3awGQ3MmWFrHmsLi5WGYa+hgl1xhpn81PtKmW53JOmiFItzoMELBGmcSnETaD5V29ExQWg8ELk8I5ZM3QcfRN15FrAjyk4vAZBlGNqrz86uNQ== X-Forefront-Antispam-Report: CIP:66.129.242.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230001)(4636009)(40470700004)(36840700001)(46966006)(8936002)(55016003)(6266002)(7696005)(8676002)(356005)(4326008)(82310400004)(336012)(70586007)(70206006)(47076005)(7126003)(86362001)(81166007)(107886003)(36860700001)(3480700007)(40460700003)(7116003)(2906002)(26005)(186003)(316002)(6916009)(9686003)(54906003)(508600001)(5660300002)(4744005)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2022 04:21:46.7401 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 49017c57-a8f4-46a1-ffee-08d9eb83af88 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.242.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT032.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4683 X-Proofpoint-ORIG-GUID: milDHgrj6FRE_Jsr8NoijV13zOq4yjjI X-Proofpoint-GUID: milDHgrj6FRE_Jsr8NoijV13zOq4yjjI X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-09_02,2022-02-07_02,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 malwarescore=0 clxscore=1015 suspectscore=0 mlxlogscore=666 priorityscore=1501 spamscore=0 bulkscore=0 impostorscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202090032 X-Rspamd-Queue-Id: 4Jtmt90wVxz3mLw X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b=pzqJlV3x; dkim=pass header.d=juniper.net header.s=selector1 header.b=L15Lx59M; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=juniper.net; spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 67.231.152.164 as permitted sender) smtp.mailfrom=sjg@juniper.net X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; FREEFALL_USER(0.00)[sjg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:67.231.152.164]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[juniper.net:+]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; RCVD_IN_DNSWL_NONE(0.00)[104.47.55.109:received]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]; RCVD_COUNT_SEVEN(0.00)[11]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.152.164:from] X-ThisMailContainsUnwantedMimeParts: N Brooks Davis wrote: > On Tue, Feb 08, 2022 at 02:52:27PM -0800, Simon J. Gerraty wrote: > > Brooks Davis wrote: > > > > > > This would be fine, but should not be necessicary. The sys subdir should > > > be created by AUTOOBJ. > > > > .OBJDIR should be (and is), not .OBJDIR/sys > > We've had support for relative paths in SRCS since 2015 > (cee9be4971a56f2a748eb78df97b72e42fe860ab). If this is broken if some > supported modes we should fix it or remove it (but I belive clang/llvm > depends on it). That logic appears to be in bsd.obj.mk as part of the obj target it depends on SRCS containing paths with / That target does not get run if one is using auto.obj.mk --sjg From nobody Wed Feb 9 09:57:52 2022 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 E89F119AA5B0 for ; Wed, 9 Feb 2022 09:57:59 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtwKy5hJxz3KNG for ; Wed, 9 Feb 2022 09:57:58 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-ej1-x62f.google.com with SMTP id fy20so5863002ejc.0 for ; Wed, 09 Feb 2022 01:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:reply-to:mime-version :content-transfer-encoding; bh=B7dckOPEoXEEpLhODyX+6EqF25/yYuIWzq9ZKVb0jxo=; b=WdouUc1mKQsV76r0Ew8Z0hNza2D/3jCu7oKAK4cRFRQFtzMXSdhOV6NMISi3obXOkI uyrum3GLYWX5MtJwSGSnI0q36V7H8ECTT8hhzOfi/d8b52LuDgdAwTrt+z/gbPE6PV06 UfyCIat8c3ZRxf7zr8TOJXCfGlmArkN+C+bYU6iIirVy/klN6CjULgnTpQvowC0AeKPh fZWPjuy3KEoachOY+cF9PfAnOfVA+yYiXU4QBFX5KJo3YqoOmb76tVAnn2NVofJAkICq C6vC2+tkKgJLK6sG4KfIeEw8tlmw6OHEZYUT4ILQT2QeACHHkikfU0ewqemLbYQqotT5 4TIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mime-version:content-transfer-encoding; bh=B7dckOPEoXEEpLhODyX+6EqF25/yYuIWzq9ZKVb0jxo=; b=q/rMXZlbto628k2rZTV/HcHwp3QBcnMIkqnZKBu5tx9zhFeW5SKyr/BRS5zfuCGHHK Dckn9Qo0l0BcB//Ut11y/5wVkYxmL3AY7awkbriEm1bZhwqPaaW/UCYShHQ6P0CJT7kJ obfH//4c79VH7syn7yBK7eV8Hq3IP2mjYrrhOmo6xp9N4aRxLj2fvnrviLRgkBrJVvMb q8aixx2maqdWyL9tPVkKE6AhYT/VigDupNduc9AgeU6Wttlv7wtc/HoYzVK23RT8bzl3 DbauyFHLcoi79HvtJ4luMHO2qiZTIIR/vAij8XFlXbfXnGGCGKsDw2MnikimhwYnJCNI RYlQ== X-Gm-Message-State: AOAM530OT2EzTNH14lxM947RnQEhHdynGmA0qU5KlOEyHpf+8W3lPPBu xtHW4+94UwDrrJ0OsqxRfr3CUHvCA6g= X-Google-Smtp-Source: ABdhPJyN8khKqfJhilt+f67dvAXTiTRptwmB/3rC2i5k7A3pgOtXjeDKVeBNZt6G6KkTxulBsE0flg== X-Received: by 2002:a17:907:7241:: with SMTP id ds1mr1231833ejc.491.1644400677437; Wed, 09 Feb 2022 01:57:57 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id e26sm4221356eds.10.2022.02.09.01.57.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 01:57:57 -0800 (PST) Date: Wed, 9 Feb 2022 10:57:52 +0100 From: Gary Jennejohn To: current@freebsd.org Subject: test-includes breaks buildworld when WITHOUT_PF is set in src.conf Message-ID: <20220209105752.2c382ac2@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JtwKy5hJxz3KNG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=WdouUc1m; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-3.91 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.907]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; MLMMJ_DEST(0.00)[current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N test-includes uses pf.h when checking usage of pfvar.h. But, these lines in include/Makefile remove pf.h when WITHOUT_PF is set in src.conf: .if ${MK_PF} != "no" INCSGROUPS+= PF .endif This breaks buildworld. The error message: In file included from net_pfvar.c:1: /usr/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:65:10: fatal error: 'netpfil/pf/pf.h' file not found #include ^~~~~~~~~~~~~~~~~ 1 error generated. --- net_pfvar.o --- *** [net_pfvar.o] Error code 1 make[3]: stopped in /usr/src/tools/build/test-includes .ERROR_TARGET='net_pfvar.o' Removing the .if/.endif fixes it for me, although there may be a better way to avoid the error. -- Gary Jennejohn From nobody Wed Feb 9 10:08:44 2022 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 44C3619AE65A for ; Wed, 9 Feb 2022 10:08:48 +0000 (UTC) (envelope-from kp@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtwZS0xptz3MTW; Wed, 9 Feb 2022 10:08:48 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644401328; 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=Weamu8tG/QKR9m/WOOLvJSs6BPO8tQNObhe5i6eLvOE=; b=LFp6zbV+MHotZsVcIbpcPGHt+qu3uAnqgIoocbuaOXy3NKAwzgF52GcHmTZa76bpCsx4iv zLifGdFymnQ32/4+r6W0H1KyaV7q/AXalitNfwTQpqR+856x2pS/leLYfJh2FpoiezotvZ EDf9MjxTFIy82CgaduakUNEXuQdGNHkJmihpKEBBBYTUNd5/Lhbru5hT7dNrAfsy9k5P/F /oVGjUzZIweziJmnZI93mFbRNDXoDXLhu28njrM3S21sXHQ+weCP1hbS3eNAmiZSLRFee6 vMvq04jh9PEgewGrG4emQ9cZbz8Oi08fjzetgMWE4Y63C2T80KmkbRdwdZ8v7Q== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id C6ABD22DDC; Wed, 9 Feb 2022 10:08:47 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 91608240EF; Wed, 9 Feb 2022 11:08:45 +0100 (CET) From: Kristof Provost To: Gary Jennejohn Cc: current@freebsd.org Subject: Re: test-includes breaks buildworld when WITHOUT_PF is set in src.conf Date: Wed, 09 Feb 2022 11:08:44 +0100 X-Mailer: MailMate (1.14r5852) Message-ID: <7E81E26A-1296-4107-8379-53A9F2C0DCE6@FreeBSD.org> In-Reply-To: <20220209105752.2c382ac2@ernst.home> References: <20220209105752.2c382ac2@ernst.home> 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644401328; 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=Weamu8tG/QKR9m/WOOLvJSs6BPO8tQNObhe5i6eLvOE=; b=P0EG8epvk9xApe6YoESoj7aWdtRdc9uhugjMC0h1tx3/VM6jsBfp4FKzTT/A6jjPYkySX9 XE8dAhBu+MFPmb5L1f7NR46z3SpJDtq9M4rrj6i3d/JqICgPb60m1aSWTnEE1URYEncCpd V8PTp/O7UyAoLeeONAGhS6YfF5+puGyzHz7pXzK4GuV59+2IL4y7zzZkJDwQIXxUgZXlJf 28Hrz2J9E9Sf/xYHXOoowFWjpZo6n+UxDjc7vTLxWl5Rec9NVQJUuuMDnXlOZrqdrHBzaJ aqTYj1nZ//JVh7gro8T/R68qche35V8XKfB38gyVe35QJCWFnRALbzqMhsNdow== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644401328; a=rsa-sha256; cv=none; b=cGWbIhFLUtrBp6CEaSMAbswvSYD3hwRfIaZEUGc9JvmDPNNaDTf4sf8+prTTXs5oSCV65w 7QH+3+G0L5RvYnn000G5D3nyViGp7i9k2RqMQecisq0/oZJqsu3wdnO3xaW5ROuCIFXf26 86vwRFVSIuSHlYvrLcul/iTf46Q9qlY2uGGTD/8RkMS7yfZnBkeRkcbt1jQ5brO0NSQSgk SCSavNZO8op+uvYnH56DwHCalF8BAoZN6jFjygtNXDTGGliVtEO7LAow/dV9Dwhpkq0AKS t7BkZNdK74AdThU4FgRyl2SbYOB0dbvAV8YD5YMvvXCbFZ4UbxS4/9JPBgmOEA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 9 Feb 2022, at 10:57, Gary Jennejohn wrote: > test-includes uses pf.h when checking usage of pfvar.h. > > But, these lines in include/Makefile remove pf.h when WITHOUT_PF is > set in src.conf: > > .if ${MK_PF} !=3D "no" > INCSGROUPS+=3D PF > .endif > > This breaks buildworld. The error message: > > In file included from net_pfvar.c:1: > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:65:10: fatal e= rror: > 'netpfil/pf/pf.h' file not found > #include > ^~~~~~~~~~~~~~~~~ > 1 error generated. > --- net_pfvar.o --- > *** [net_pfvar.o] Error code 1 > > make[3]: stopped in /usr/src/tools/build/test-includes > .ERROR_TARGET=3D'net_pfvar.o' > > Removing the .if/.endif fixes it for me, although there may be a better= > way to avoid the error. > Warner=E2=80=99s working on a better fix. See https://reviews.freebsd.org= /D34009 for the discussion. Kristof From nobody Wed Feb 9 10:43:10 2022 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 9E61619A175D for ; Wed, 9 Feb 2022 10:43:13 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtxL83d24z3rK3 for ; Wed, 9 Feb 2022 10:43:12 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-ej1-x62c.google.com with SMTP id a8so5962732ejc.8 for ; Wed, 09 Feb 2022 02:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:reply-to:mime-version :content-transfer-encoding; bh=T2fvwW6+4A+6fSxaUICLbfRxSYRnO1tVLUNvl06GUWk=; b=LeGzIC0jB7LppkFnXOrpLAQtpC7KqK4/6298yFjpEZklBdTsONaRz4TeT2iT+80DLx T+zsHaLImGziTeGwAIzCpQTkNouuHC9PTBke5hpjSLIGed9fdfxtipf5pjhayMCi3Y4x Omr4yHy01aK3AIpgxN2aqq2Gru03Ce/vAGr71HCq+c/PRFOyekykOkdteG3nEOVwNqoB I58c5sOe/jWGPInaXwxrFIC9qOeTZTIvaqK/Vw0mj9e/erdJ9sLwszrQYOYPERhNbZIE g9Y7TKZT1VQ5TDVB3CuUsq50FZ03tXXAWDIscNQY1dUjoJV4Rh4eDLOm4gqVEr/c6BDq waxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mime-version:content-transfer-encoding; bh=T2fvwW6+4A+6fSxaUICLbfRxSYRnO1tVLUNvl06GUWk=; b=PSuwwSu5C4PtdjCGdL3xRuB0wePkkocTSuUYM6+FQfzIixKpudEI+S7qZv7JIBI1cC hEXgL5k/g9P1EyhKc1B/2L9Qpn8DD5ipzThWmWTdmBdIknO49Wklenjbi6ezRMGf+GNL EVgf6KG4PQIL9uLmtIl2OlsRzoMT3SDwcVWmkUuv2yoBmkYedXdtLF1CWm0G+KK7ulvp RCUarJxie94VrXNR/mXvEdYo5FHTV04E4CU2EMy5xqJbqnLuaSabzt2Zfomk5wdz6+wW nES8HeuIAPmRZz6YIWyiSAoAlRvBets53xzuHmzK64fpUYDICVkcBnPXpZbZfaBCU6ip 3nZQ== X-Gm-Message-State: AOAM531o9Ly+cqkqq2ECQR0LGT/58LcW9jWv/3fpKfwbaluS4GD2RRNc nUqkatwMtuMVeL4RWZpEUZUwHFxeKSo= X-Google-Smtp-Source: ABdhPJwwWBGpxwvZv6Aw4rnTTMNhtA4tJfBpr5p5QjPht/vFT5y4rgKme9qhK0WfG/pGcBcoe22iKA== X-Received: by 2002:a17:907:7292:: with SMTP id dt18mr1368463ejc.649.1644403391384; Wed, 09 Feb 2022 02:43:11 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id p19sm5857701ejc.42.2022.02.09.02.43.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 02:43:10 -0800 (PST) Date: Wed, 9 Feb 2022 11:43:10 +0100 From: Gary Jennejohn To: current@freebsd.org Subject: fd7daa727126 breaks buildkernel when KERN_TLS is not defined Message-ID: <20220209114310.1a93fa85@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JtxL83d24z3rK3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=LeGzIC0j; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-3.92 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.923]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from]; MLMMJ_DEST(0.00)[current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Commit fd7daa727126 to /usr/src/sys/netinet/tcp_usrreq.c breaks buildkernel when KERN_TLS is not defined. This patch fixes it for me: --- tcp_usrreq.c.orig 2022-02-09 10:25:46.851034000 +0000 +++ tcp_usrreq.c 2022-02-09 10:30:27.541058000 +0000 @@ -2119,12 +2119,12 @@ int tcp_default_ctloutput(struct inpcb *inp, struct sockopt *sopt) { - struct socket *so = inp->inp_socket; struct tcpcb *tp = intotcpcb(inp); int error, opt, optval; u_int ui; struct tcp_info ti; #ifdef KERN_TLS + struct socket *so = inp->inp_socket; struct tls_enable tls; #endif char *pbuf, buf[TCP_LOG_ID_LEN]; @@ -2136,7 +2136,9 @@ INP_WLOCK_ASSERT(inp); KASSERT((inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) == 0, ("inp_flags == %x", inp->inp_flags)); +#ifdef KERN_TLS KASSERT(so != NULL, ("inp_socket == NULL")); +#endif switch (sopt->sopt_level) { #ifdef INET6 -- Gary Jennejohn From nobody Wed Feb 9 10:54:55 2022 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 C339119A8836 for ; Wed, 9 Feb 2022 10:55:01 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jtxbm5rDNz3wRf; Wed, 9 Feb 2022 10:55:00 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id s10so3319106wra.5; Wed, 09 Feb 2022 02:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=ijrAfdzwxJQ2Xm5cW5RDOtNZeLuIT1LsCFgnJ8qwvWQ=; b=mNgW0ZNn5jQxpSTaMW+L6oWB44etTHQJXa9AUGUAGVYGFY/RqXeEPx7tfd5ntaQ7Q3 vTwSdTZfKMjibNNB+alH8az0TwnPne19gE3cC6TXyH4Po31MbRm6Gxl+dIWAgxUmOcCJ gZ/Ljh7MTz+TIQ23Is7vmuSYjNw6tKzE65GrdismOscIXYKU3MKQtCubK/e/uUtL+TX3 q3c1gDNXC+3wDcL4toCW/grOs6dvNYAg03TdibHYw+MGVJ6r8pQbDVAo9mVI9gUF2Jml Poc363NyNgmvQGLiqWq6E3mSmlivjlmTD6RYMfNQWhSbk3s6E6MZPhnOuxP4MCd4Aa9n 4/Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=ijrAfdzwxJQ2Xm5cW5RDOtNZeLuIT1LsCFgnJ8qwvWQ=; b=c1ltYVPKSnqY7PUoigvFBP1Yf7c//snGud5NHFKSElkIA97oCtcgkQGpLU6y0ftvZ4 CvHd3bf/iIlhJIcyrQHH/vDn0uYa8hsQqeewt2IyR/rP1SBqJYNN0E/fKMiuHEZsMrg0 PyiWZjSfm6sz7T61FaBHyYZJSERy8fGjQPDHZxY+w5rm/Zji0zQTD3AMTCJOdDSXqihX M1gr4mq+xi3jTYY24RcnNtDHk3eq3NZPIUJbDhQGRQG2YNWovuilRchSM4Y5BhRLklpD 80nZiST4jJuDXcJt2SvMNlU7pSI/e65291kAAfEPfm1yGBkMVMCH3pKPAg4hGsAQYVWp /RiA== X-Gm-Message-State: AOAM533v4wlOhGlGXjgpDB+XAWLPa5JwxHovtq6bwLmRsOL5mTR5fxgg lPyV3JcFa+bcLlVBQA922vfuPMPx1fg= X-Google-Smtp-Source: ABdhPJzkb6DrdryGeZ4DaOMg5NVim3jbUk8DUkuKibEln6RLwJBoIP6I3/jJQPbQXNlIrS1tgcnpxw== X-Received: by 2002:adf:e5c4:: with SMTP id a4mr719897wrn.441.1644404099751; Wed, 09 Feb 2022 02:54:59 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id x7sm15084225wrt.77.2022.02.09.02.54.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 02:54:59 -0800 (PST) Date: Wed, 9 Feb 2022 11:54:55 +0100 From: Gary Jennejohn To: Kristof Provost Cc: current@freebsd.org Subject: Re: test-includes breaks buildworld when WITHOUT_PF is set in src.conf Message-ID: <20220209115455.18d2e064@ernst.home> In-Reply-To: <7E81E26A-1296-4107-8379-53A9F2C0DCE6@FreeBSD.org> References: <20220209105752.2c382ac2@ernst.home> <7E81E26A-1296-4107-8379-53A9F2C0DCE6@FreeBSD.org> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Jtxbm5rDNz3wRf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mNgW0ZNn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-3.78 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.78)[-0.781]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c:from]; MLMMJ_DEST(0.00)[current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 09 Feb 2022 11:08:44 +0100 Kristof Provost wrote: > On 9 Feb 2022, at 10:57, Gary Jennejohn wrote: > > test-includes uses pf.h when checking usage of pfvar.h. > > > > But, these lines in include/Makefile remove pf.h when WITHOUT_PF is > > set in src.conf: > > > > .if ${MK_PF} != "no" > > INCSGROUPS+= PF > > .endif > > > > This breaks buildworld. The error message: > > > > In file included from net_pfvar.c:1: > > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:65:10: fatal error: > > 'netpfil/pf/pf.h' file not found > > #include > > ^~~~~~~~~~~~~~~~~ > > 1 error generated. > > --- net_pfvar.o --- > > *** [net_pfvar.o] Error code 1 > > > > make[3]: stopped in /usr/src/tools/build/test-includes > > .ERROR_TARGET='net_pfvar.o' > > > > Removing the .if/.endif fixes it for me, although there may be a better > > way to avoid the error. > > > Warner's working on a better fix. See https://reviews.freebsd.org/D34009 for the discussion. > Thanks for the info. -- Gary Jennejohn From nobody Wed Feb 9 11:16:18 2022 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 10AE519B75C8 for ; Wed, 9 Feb 2022 11:16:35 +0000 (UTC) (envelope-from george@fork.id.au) Received: from mail2.uniridge.com.au (mail2.uniridge.com.au [13.237.159.77]) by mx1.freebsd.org (Postfix) with ESMTP id 4Jty4Z5gnNz4bbc for ; Wed, 9 Feb 2022 11:16:30 +0000 (UTC) (envelope-from george@fork.id.au) Received: from mail.hq (unknown [192.168.11.6]) by mail2.uniridge.com.au (Postfix) with ESMTP id 6A74FE7C; Wed, 9 Feb 2022 11:16:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fork.id.au; s=mail; t=1644405382; bh=sPD5daqM/R1MPsdHu8i0ORjXShF3iMrMy3eEFH/Nagc=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=rOAqb9ujP2O652B5dMwWBxUeemM77qFXLEHRgnMB2FioxTJhH1rD6Hs9NLHpiLUYY K4mVBQxxFjhWGsQUolbwsuRapFdboN6g9pfyu6YO1Py+yRU/v70XIR6EzPI5hg/2LT dw0Do8z4vitF4x5RLW0P3Q9n7Ah7MUi1h0jfv6Hw= Received: from [192.168.11.53] (unknown [192.168.11.53]) by mail.hq (Postfix) with ESMTP id 06B7DAC883; Wed, 9 Feb 2022 11:16:20 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------0fbvVeC8bmftFUd0CTeJjA0i" Message-ID: Date: Wed, 9 Feb 2022 12:16:18 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: buildworld failed Content-Language: en-US To: Warner Losh Cc: FreeBSD Current References: <0UZyB4mlM9jAgpWD6iLfODtbpKIM4xVsFg11wqD5CvHnEQNQrXX4Dx6ywa0fW2ZNmzk0XC5Os_gCkYm-knr8JmCokn5xI_onhf5A4mUn2mI=@protonmail.com> From: George Abdelmalik In-Reply-To: X-Rspamd-Queue-Id: 4Jty4Z5gnNz4bbc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fork.id.au header.s=mail header.b=rOAqb9uj; dmarc=pass (policy=reject) header.from=fork.id.au; spf=pass (mx1.freebsd.org: domain of george@fork.id.au designates 13.237.159.77 as permitted sender) smtp.mailfrom=george@fork.id.au X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[fork.id.au:s=mail]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:13.237.159.77]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[fork.id.au:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[fork.id.au,reject]; BLOCKLISTDE_FAIL(0.00)[13.237.159.77:server fail]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:16509, ipnet:13.236.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------0fbvVeC8bmftFUd0CTeJjA0i Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/2/22 15:45, Warner Losh wrote: > > > On Tue, Feb 8, 2022 at 3:43 AM George Abdelmalik > wrote: > > > On 7/2/22 03:50, qroxana wrote: >> >> >> I know running make install for >> /usr/src/tools/build/test-includes can fix this, >> but this still fails on a newly installed 14.0-CURRENT. >> >> --- test-includes --- >> cd /usr/src/tools/build/test-includes; MACHINE_ARCH=aarch64  >> MACHINE=arm64  CPUTYPE= CC="cc -target >> aarch64-unknown-freebsd14.0 >> --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp >> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target >> aarch64-unknown-freebsd14.0 >> --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp >> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="c++  -target >> aarch64-unknown-freebsd14.0 >> --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp >> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target >> aarch64-unknown-freebsd14.0 >> --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp >> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP="cpp -target >> aarch64-unknown-freebsd14.0 >> --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp >> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target >> aarch64-unknown-freebsd14.0 >> --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp >> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" AS="as" AR="ar" >> ELFCTL="elfctl" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" >> RANLIB=ranlib STRINGS=  SIZE="size" STRIPBIN="strip"  >> INSTALL="install -U" >> PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin >> SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make >> DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp test-includes >> --- sys/abi_compat.c --- >> --- sys/acct.c --- >> --- sys/acl.c --- >> --- sys/aio.c --- >> --- sys/abi_compat.c --- >> echo "#include " > sys/abi_compat.c >> sh: cannot create sys/abi_compat.c: No such file or directory >> *** [sys/abi_compat.c] Error code 2 >> >> make[4]: stopped in /usr/src/tools/build/test-includes >> --- sys/acct.c --- >> echo "#include " > sys/acct.c >> sh: cannot create sys/acct.c: No such file or directory >> *** [sys/acct.c] Error code 2 >> >> make[4]: stopped in /usr/src/tools/build/test-includes >> --- sys/aio.c --- >> echo "#include " > sys/aio.c >> sh: cannot create sys/aio.c: No such file or directory >> *** [sys/aio.c] Error code 2 >> >> make[4]: stopped in /usr/src/tools/build/test-includes >> --- sys/acl.c --- >> echo "#include " > sys/acl.c >> sh: cannot create sys/acl.c: No such file or directory >> *** [sys/acl.c] Error code 2 >> >> > Same here for me for the past couple of weeks. Haven't been able > to identify why it fails. My hunch was that a particular objdir > wasn't being created. As a workaround I edited the Makefile.inc1 > to remove the test-includes command (line 1128 I think). > > I'd really like to understand why this error comes about. If > someone has any insights, please share them :) > > What build options are you using?  this is the test to make sure that > files can be included on their own. > > Warner Hi Warner, My make.conf contains: # make.conf(5) to use when building world. MALLOC_PRODUCTION= My src.conf contains: ## src.conf(5) to use when building world. WITHOUT_IPFILTER= WITHOUT_PF= WITHOUT_PPP= WITHOUT_LPR= WITHOUT_NIS= WITHOUT_LIB32= WITHOUT_HYPERV= WITHOUT_APM= WITHOUT_ATM= WITHOUT_FINGER= WITHOUT_FLOPPY= WITHOUT_RADIUS_SUPPORT= WITHOUT_DEBUG_FILES= WITHOUT_TESTS= The build command is: env MAKEOBJDIRPREFIX=$HOME/obj \     make -j2 \     -DNO_CLEAN \     __MAKE_CONF=$HOME/make.conf \     SRCCONF=$HOME/src.conf \     TARGET=amd64 \     TARGET_ARCH=amd64 \     CPUTYPE= \     buildworld Perhaps the issue is that I first build the toolchain as a separate step prior to invoking buildworld, that command is:     env MAKEOBJDIRPREFIX=$HOME/obj \     make -j2 \     __MAKE_CONF=$HOME/make.conf \     SRCCONF=$HOME/src.conf \     TARGET=amd64 \     TARGET_ARCH=amd64 \     toolchain Thanks for your interest, George. --------------0fbvVeC8bmftFUd0CTeJjA0i Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 8/2/22 15:45, Warner Losh wrote:


On Tue, Feb 8, 2022 at 3:43 AM George Abdelmalik <george@fork.id.au> wrote:


On 7/2/22 03:50, qroxana wrote:


I know running make install for /usr/src/tools/build/test-includes can fix this,
but this still fails on a newly installed 14.0-CURRENT.

--- test-includes ---
cd /usr/src/tools/build/test-includes;  MACHINE_ARCH=aarch64  MACHINE=arm64  CPUTYPE= CC="cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="c++  -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin  -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  CPP="cpp -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin"  AS="as" AR="ar" ELFCTL="elfctl" LD="ld"  LLVM_LINK="" NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size" STRIPBIN="strip"  INSTALL="install -U"  PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin  SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make  DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp test-includes
--- sys/abi_compat.c ---
--- sys/acct.c ---
--- sys/acl.c ---
--- sys/aio.c ---
--- sys/abi_compat.c ---
echo "#include <sys/abi_compat.h>" > sys/abi_compat.c
sh: cannot create sys/abi_compat.c: No such file or directory
*** [sys/abi_compat.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/acct.c ---
echo "#include <sys/acct.h>" > sys/acct.c
sh: cannot create sys/acct.c: No such file or directory
*** [sys/acct.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/aio.c ---
echo "#include <sys/aio.h>" > sys/aio.c
sh: cannot create sys/aio.c: No such file or directory
*** [sys/aio.c] Error code 2

make[4]: stopped in /usr/src/tools/build/test-includes
--- sys/acl.c ---
echo "#include <sys/acl.h>" > sys/acl.c
sh: cannot create sys/acl.c: No such file or directory
*** [sys/acl.c] Error code 2


Same here for me for the past couple of weeks. Haven't been able to identify why it fails. My hunch was that a particular objdir wasn't being created. As a workaround I edited the Makefile.inc1 to remove the test-includes command (line 1128 I think).

I'd really like to understand why this error comes about. If someone has any insights, please share them :)

What build options are you using?  this is the test to make sure that files can be included on their own.

Warner


Hi Warner,

My make.conf contains:

# make.conf(5) to use when building world.
MALLOC_PRODUCTION=


My src.conf contains:

## src.conf(5) to use when building world.
WITHOUT_IPFILTER=
WITHOUT_PF=
WITHOUT_PPP=
WITHOUT_LPR=
WITHOUT_NIS=
WITHOUT_LIB32=
WITHOUT_HYPERV=
WITHOUT_APM=
WITHOUT_ATM=
WITHOUT_FINGER=
WITHOUT_FLOPPY=
WITHOUT_RADIUS_SUPPORT=
WITHOUT_DEBUG_FILES=
WITHOUT_TESTS=


The build command is:

env MAKEOBJDIRPREFIX=$HOME/obj \
    make -j2 \
    -DNO_CLEAN \
    __MAKE_CONF=$HOME/make.conf \
    SRCCONF=$HOME/src.conf \
    TARGET=amd64 \
    TARGET_ARCH=amd64 \
    CPUTYPE= \
    buildworld


Perhaps the issue is that I first build the toolchain as a separate step prior to invoking buildworld, that command is:

    env MAKEOBJDIRPREFIX=$HOME/obj \
    make -j2 \
    __MAKE_CONF=$HOME/make.conf \
    SRCCONF=$HOME/src.conf \
    TARGET=amd64 \
    TARGET_ARCH=amd64 \
    toolchain

Thanks for your interest,
George.

--------------0fbvVeC8bmftFUd0CTeJjA0i-- From nobody Wed Feb 9 11:21:38 2022 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 56B7F19BB55A for ; Wed, 9 Feb 2022 11:21:43 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtyBZ4hmzz4fgB for ; Wed, 9 Feb 2022 11:21:42 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:e02c:adf0:dce1:9c85]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 8999F721E2807; Wed, 9 Feb 2022 12:21:39 +0100 (CET) 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 15.0 \(3693.60.0.1.1\)) Subject: Re: fd7daa727126 breaks buildkernel when KERN_TLS is not defined From: tuexen@freebsd.org In-Reply-To: <20220209114310.1a93fa85@ernst.home> Date: Wed, 9 Feb 2022 12:21:38 +0100 Cc: current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1531B30A-E253-452F-8AB5-669DD5CCF0AC@freebsd.org> References: <20220209114310.1a93fa85@ernst.home> To: gljennjohn@gmail.com X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4JtyBZ4hmzz4fgB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:638:a02:a001:20e:cff:fe4a:feaa is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org X-Spamd-Result: default: False [-2.60 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[tuexen]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MLMMJ_DEST(0.00)[current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 9. Feb 2022, at 11:43, Gary Jennejohn wrote: >=20 > Commit fd7daa727126 to /usr/src/sys/netinet/tcp_usrreq.c breaks = buildkernel > when KERN_TLS is not defined. Fixed in = https://cgit.FreeBSD.org/src/commit/?id=3D528c76492402d9be8ec83a0a769f0d70= e2a32f61 Thanks for reporting. Best regards Michael > This patch fixes it for me: >=20 > --- tcp_usrreq.c.orig 2022-02-09 10:25:46.851034000 +0000 > +++ tcp_usrreq.c 2022-02-09 10:30:27.541058000 +0000 > @@ -2119,12 +2119,12 @@ > int > tcp_default_ctloutput(struct inpcb *inp, struct sockopt *sopt) > { > - struct socket *so =3D inp->inp_socket; > struct tcpcb *tp =3D intotcpcb(inp); > int error, opt, optval; > u_int ui; > struct tcp_info ti; > #ifdef KERN_TLS > + struct socket *so =3D inp->inp_socket; > struct tls_enable tls; > #endif > char *pbuf, buf[TCP_LOG_ID_LEN]; > @@ -2136,7 +2136,9 @@ > INP_WLOCK_ASSERT(inp); > KASSERT((inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) =3D=3D = 0, > ("inp_flags =3D=3D %x", inp->inp_flags)); > +#ifdef KERN_TLS > KASSERT(so !=3D NULL, ("inp_socket =3D=3D NULL")); > +#endif >=20 > switch (sopt->sopt_level) { > #ifdef INET6 >=20 > --=20 > Gary Jennejohn >=20 From nobody Thu Feb 10 04:08:59 2022 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 24B4E19C3ED3 for ; Thu, 10 Feb 2022 04:09:15 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JvNY56tzpz3F8Y; Thu, 10 Feb 2022 04:09:13 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:To:From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=5zQ3A3RXPbI3HTgqPgpuDOQCUzFi78X+QZdwC32hMjQ=; b=dzde0OlxpyH9ZDMqtlN48nZtgZ 7N/F+d5mZndCuWN8Nsg6M9R5EMMIeVAwt9Q8DLwvd/XYwZxdhF3AeQjNQWkbSCFtm6cLUXqCqUuyG 1BqZe0C4SGCe2qI6eZ8Frpj84bpguKV8MIp483Cq1LUQgFjHkP8eX12a1iDjPhs7wQagxrcfZknV1 V+kZbCYH+nhcTK0SWbsqQqXgKKWf1h172YAseGLwju6Ug/aQauo4ysj263OpWMKl4ElIYcjvVFI56 vTrpkuqEkQYtNf+x/GswP7vBuDNN3+a6g56GJvPL5ETokSUZwHQgvfijOrJ0toWqwX6Zs6af4ZkE+ 0ZlHkmAA==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:43615 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nI0lP-0002g7-AF; Wed, 09 Feb 2022 22:08:59 -0600 Received: from 2600:1700:210:b18f:71b4:229b:495c:69cc by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 09 Feb 2022 22:08:59 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Wed, 09 Feb 2022 22:08:59 -0600 From: Larry Rosenman To: Freebsd current , Mark Johnston Subject: Re: Panic, CURRENT, yesterday In-Reply-To: <1ae8c6664f33959f69be4d61a8c545f3@lerctr.org> References: <1ae8c6664f33959f69be4d61a8c545f3@lerctr.org> Message-ID: <53727be0434c4c58ae66b8e979aee4f3@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JvNY56tzpz3F8Y X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=dzde0Olx; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02/08/2022 1:51 pm, Larry Rosenman wrote: > I got the following last night while doing a poudriere run as well as > a full bacula backup: > > borg.lerctr.org dumped core - see /var/crash/vmcore.0 > > Mon Feb 7 23:05:48 CST 2022 > > FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #54 > ler/freebsd-main-changes-n252969-5e5fd0c788c: Sat Feb 5 14:48:30 CST > 2022 > root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL > amd64 > > panic: ng_snd_item: 42 != 290 > Another one today: ⯠more /var/crash/core.txt.1 borg.lerctr.org dumped core - see /var/crash/vmcore.1 Wed Feb 9 19:30:43 CST 2022 FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #54 ler/freebsd-main-changes-n252969-5e5fd0c788c: Sat Feb 5 14:48:30 CST 2022 root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL amd64 panic: ng_snd_item: 42 != 1414 GNU gdb (GDB) 11.2 [GDB v11.2 for FreeBSD] Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel... Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... Unread portion of the kernel message buffer: panic: ng_snd_item: 42 != 1414 cpuid = 0 time = 1644455454 KDB: stack backtrace: #0 0xffffffff80515fc5 at kdb_backtrace+0x65 #1 0xffffffff804cbaef at vpanic+0x17f #2 0xffffffff804cb8c3 at panic+0x43 #3 0xffffffff82c765b7 at ng_snd_item+0x587 #4 0xffffffff82c8f263 at ng_ether_output+0xb3 #5 0xffffffff805e0c1d at ether_output+0x6cd #6 0xffffffff805f6251 at arpintr+0xd71 #7 0xffffffff805e5587 at netisr_dispatch_src+0x97 #8 0xffffffff805e0f1e at ether_demux+0x14e #9 0xffffffff82c8f89c at ng_ether_rcv_upper+0x12c #10 0xffffffff82c76dab at ng_apply_item+0x7eb #11 0xffffffff82c7638d at ng_snd_item+0x35d #12 0xffffffff82c76dab at ng_apply_item+0x7eb #13 0xffffffff82c7638d at ng_snd_item+0x35d #14 0xffffffff82c8f33f at ng_ether_input+0x9f #15 0xffffffff805e21d7 at ether_nh_input+0x217 #16 0xffffffff805e5587 at netisr_dispatch_src+0x97 #17 0xffffffff805e138d at ether_input+0x5d Uptime: 1d20h10m31s Dumping 28528 out of 131023 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff804cb6ff in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:487 #3 0xffffffff804cbb5e in vpanic (fmt=0xffffffff82c7fd98 "%s: %d != %d", ap=) at /usr/src/sys/kern/kern_shutdown.c:920 #4 0xffffffff804cb8c3 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:844 #5 0xffffffff82c765b7 in ng_snd_item (item=0xfffff8132d74f880, flags=0) at /usr/src/sys/netgraph/ng_base.c:2256 #6 0xffffffff82c8f263 in ng_ether_output (ifp=, ifp@entry=, mp=0xfffffe02ba63f868, mp@entry=) at /usr/src/sys/netgraph/ng_ether.c:294 #7 0xffffffff805e0c1d in ether_output (ifp=0xfffff80114a43000, m=0xfffff81f8203e600, dst=, ro=) at /usr/src/sys/net/if_ethersubr.c:427 #8 0xffffffff805f6251 in in_arpinput (m=0xfffff81f8203e600) at /usr/src/sys/netinet/if_ether.c:1129 #9 arpintr (m=0xfffff81f8203e600, m@entry=) at /usr/src/sys/netinet/if_ether.c:739 #10 0xffffffff805e5587 in netisr_dispatch_src (proto=4, source=source@entry=0, m=0xfffff81f8203e600) at /usr/src/sys/net/netisr.c:1153 #11 0xffffffff805e58df in netisr_dispatch (proto=, m=) at /usr/src/sys/net/netisr.c:1244 #12 0xffffffff805e0f1e in ether_demux (ifp=ifp@entry=0xfffff80114a43000, m=, m@entry=0xfffff81f8203e600) at /usr/src/sys/net/if_ethersubr.c:926 #13 0xffffffff82c8f89c in ng_ether_rcv_upper (hook=, hook@entry=, item=0xfffff8132d74f880, item@entry=) at /usr/src/sys/netgraph/ng_ether.c:742 #14 0xffffffff82c76dab in ng_apply_item (node=node@entry=0xfffff812992fe600, item=item@entry=0xfffff8132d74f880, rw=0) at /usr/src/sys/netgraph/ng_base.c:2406 #15 0xffffffff82c7638d in ng_snd_item (item=0xfffff8132d74f880, item@entry=, flags=0, flags@entry=) at /usr/src/sys/netgraph/ng_base.c:2323 #16 0xffffffff82c76dab in ng_apply_item (node=node@entry=0xfffff8040b1eda00, item=item@entry=0xfffff8132d74f880, rw=0) at /usr/src/sys/netgraph/ng_base.c:2406 #17 0xffffffff82c7638d in ng_snd_item (item=item@entry=0xfffff8132d74f880, flags=flags@entry=0) at /usr/src/sys/netgraph/ng_base.c:2323 #18 0xffffffff82c8f33f in ng_ether_input (ifp=, ifp@entry=, mp=0xfffffe02ba63fcf8, mp@entry=) at /usr/src/sys/netgraph/ng_ether.c:255 #19 0xffffffff805e21d7 in ether_input_internal (ifp=0xfffff80114a43000, m=0xfffff81f8203e600) at /usr/src/sys/net/if_ethersubr.c:661 #20 ether_nh_input (m=, m@entry=) at /usr/src/sys/net/if_ethersubr.c:742 #21 0xffffffff805e5587 in netisr_dispatch_src (proto=proto@entry=5, source=source@entry=0, m=m@entry=0xfffff81f8203e600) at /usr/src/sys/net/netisr.c:1153 #22 0xffffffff805e58df in netisr_dispatch (proto=, proto@entry=5, m=, m@entry=0xfffff81f8203e600) at /usr/src/sys/net/netisr.c:1244 #23 0xffffffff805e138d in ether_input (ifp=0xfffff80114a43000, m=0xfffff81f8203e600) at /usr/src/sys/net/if_ethersubr.c:833 #24 0xffffffff821a934d in bce_rx_intr (sc=0xfffffe02adda0000) at /usr/src/sys/dev/bce/if_bce.c:6721 #25 bce_intr (xsc=) at /usr/src/sys/dev/bce/if_bce.c:7870 #26 0xffffffff80490929 in intr_event_execute_handlers (ie=0xfffff80106acf400, p=) at /usr/src/sys/kern/kern_intr.c:1205 #27 ithread_execute_handlers (ie=0xfffff80106acf400, p=) at /usr/src/sys/kern/kern_intr.c:1218 #28 ithread_loop (arg=, arg@entry=0xfffff801269d4ec0) at /usr/src/sys/kern/kern_intr.c:1306 #29 0xffffffff8048d3a0 in fork_exit ( callout=0xffffffff804906d0 , arg=0xfffff801269d4ec0, frame=0xfffffe02ba63ff40) at /usr/src/sys/kern/kern_fork.c:1102 #30 (kgdb) > > core is available, and I can give access and/or send the core and > kernel/debug stuff. True for this one too. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Fri Feb 11 20:07:56 2022 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 6299C19B882B for ; Fri, 11 Feb 2022 20:10:44 +0000 (UTC) (envelope-from yasu@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JwPr42JWFz4lfL; Fri, 11 Feb 2022 20:10:44 +0000 (UTC) (envelope-from yasu@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644610244; 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=TWKTEXLP7MoBw0AFcU49qadnE/1WfXRE2jmk/mmXHVU=; b=ojrw2E1GhDVX3hLsy1DFRegp4p0laghPKqOwSWJj9rdMovEohp6mhaMvSd71nwv5jWDBcX 20zwrCmliq6ql3La5qnlpTCYZxvmj64PCtcztEZagP1eGK86VTVNnBP0DRAIXfZOtHP4n3 3zr7sfLk0PiDKkE1TRsZOOGmb3Lhd0qIPGpUY6yL9Qaa91uIYfQTseisnMOvZSMlHH2pNH SLhjPdkiVbvsGMOuKv7ISXXkG0jLGHhzcbmVb/gT8i7+qEGM2RD6VCOClhp1RERW002BF4 dLV7tM7gmJ0wBV+sJ8a2Ibm7Y2YnKxAEG2e0MqauOzoiCujrk6J76W9Psa70AA== Received: from localhost (unknown [IPv6:240b:11:220:fe00:fc81:51c0:bbcc:27c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: yasu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 9348AF050; Fri, 11 Feb 2022 20:10:43 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Date: Sat, 12 Feb 2022 05:07:56 +0900 (JST) Message-Id: <20220212.050756.569441849093045289.yasu@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Buildworld fails with external GCC toolchain From: Yasuhiro Kimura X-Mailer: Mew version 6.8 on Emacs 29.0.50 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644610244; 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=TWKTEXLP7MoBw0AFcU49qadnE/1WfXRE2jmk/mmXHVU=; b=cGI7pgCT9ONAKIkn74uv0/Wxp1+m8TGuTruEAgF7GAm2G8AOx2ml2fTdrVRUX17JtnM0tE EuFaGl0Zq01vmYR63Ny3c4xstPwJd2w35oJM/Fg4lRrz0E/Qsp6tAnjswYLjJh7MJoUdQ5 7m3YmNiHcrCI/1OzA3ilSpXqN+xRg63CoGL6mxvn0cHqdglWvd+JQcvnS/urpgj5B7/D/f R83pkn9d3skF/rzJ992gTa9Cb8j5qC30zYW8tNR2lMR41N/3J3vk5eUz2MPbte87FFoBau A54xkVLBiuZK8dVG0CQM2tw/cazBOGsjZT7yDU3jVkWM4akh6dqrIH0ojtw8LA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644610244; a=rsa-sha256; cv=none; b=NPYSEiQ7g8ARKyHqppuL6LWqnYJfc4lrPywsx+nl5gyQMu8vRRgWd3Ni883TSfpRsmP6xO FYFqmtfudpBJyqzrQQ2LUEtWJh5qON6NMsIstvcD6EZmEqfqGqqbUBZFkGq4R+r/AzYEEP /tGBeogGyZuVO9JrCdOsFCLBJQT8g2EZXWVTbXVmaKGCkE5JWDJscyoqghRGSP5oCy7QM7 ex1nsL4UTN+wsRFLNnxwGcx5wSH0aMheZslA9mOjjv420DDJusDICSHp12HJ6evo8as4Gz L7BWcKByMnVgrWBUO+b1WjjEyK83VeEx8ojn7skavl6E1AfjdIBYf1tlPeqJXA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hello, I'm tring to update devel/binutils port to 2.38. When it was updated to 2.37.1, there was a suggestion that it should also be checked if building base system with GCC succeeds as binutils is a part of external GCC toolchain. So I'd like to do it with binutils 2.38 before updating the port. And as a preparation for it, I tried building base system with current external GCC toolchain (that is, with binutils 2.37.1). At first I read following wiki pages. https://wiki.freebsd.org/ExternalToolchain https://wiki.freebsd.org/ExternalGCC Next I took following steps. 1. Make clean install of 14-CURRENT amd64 with the install image of 20220210 snapshot. 2. Checkout latest main of src repository (d4b0fa45dc1 at that time). 3. pkg install amd64-gcc9 4. cd /usr/src 5. make -j 4 CROSS_TOOLCHAIN=amd64-gcc9 buildworld buildkernel Then step 5 failed as following. ---------------------------------------------------------------------- --- all_subdir_rescue --- /usr/local/bin/x86_64-unknown-freebsd14.0-ld: nc.lo: in function `_$$hide$$ nc.lo main': (.text.startup+0xd42): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_set_term.o): in function `_nc_setupscreen_sp': /usr/src/contrib/ncurses/ncurses/base/lib_set_term.c:415: undefined reference to `_nc_set_buffer_sp' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_tstp.o): in function `handle_SIGTSTP': /usr/src/contrib/ncurses/ncurses/tty/lib_tstp.c:222: undefined reference to `flushinp_sp' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getch.o): in function `check_mouse_activity': /usr/src/contrib/ncurses/ncurses/base/lib_getch.c:188: undefined reference to `_nc_timed_wait' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getstr.o): in function `wgetnstr': /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:106: undefined reference to `erasechar_sp' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:107: undefined reference to `killchar_sp' collect2: error: ld returned 1 exit status *** [rescue] Error code 1 make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue --- all_subdir_stand --- make[2]: stopped in /usr/src --- all_subdir_share --- make[2]: stopped in /usr/src --- all_subdir_rescue --- 1 error make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue *** [rescue] Error code 2 make[4]: stopped in /usr/src/rescue/rescue 1 error make[4]: stopped in /usr/src/rescue/rescue make[3]: stopped in /usr/src/rescue make[2]: stopped in /usr/src --- all_subdir_lib --- make[2]: stopped in /usr/src 167.49 real 492.07 user 94.42 sys make[1]: stopped in /usr/src make: stopped in /usr/src ---------------------------------------------------------------------- If I check commit messages of main branch over the last few months, I can find some commits that fix warning message displayed by GCC. So currently external GCC toolchain seems to work fine. Then what is the cause of my build failure? Did I do something wrong? Best Regards. --- Yasuhiro Kimura From nobody Fri Feb 11 21:53:44 2022 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 78FEB19AB5CF for ; Fri, 11 Feb 2022 21:53:54 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JwS7629s9z3r4W; Fri, 11 Feb 2022 21:53:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644616434; 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=R/erRDxcI0T2XcRPY7Pe8OTC2ygXz1eyiI0el93LYG4=; b=c1JBWa43Mjbou2blrPgx/nuuMFhzykp+/vIu+tWhqqARXrMGwc3Tl9CZF08YLuAA9WBTyh lnUkGs9OiTThQcaoYmJThfRmYrc3msCOGHuSGpNMtRd16O9HuwbOx2PJkeOQm/dH3wAUQk 2p9GIufMH7CBv4TiKCZPctjlVt5dZIFqpcQ6+J0XE4CVklEUs9TJQog2gz6SAlUzuYY+TE +ZhwZascwpATgT7+Gag5dR3Ib4DghYdD9sdP6/fGckYy0oAiTR04GdQvYCmDq2ifrOaWyy DoacwFUyzoQ1rzRnnCbFf9oM6Bamxz4Rx7w49du4/X0gN7ag2m5m39fTNQ3klA== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id E1BCE2042F; Fri, 11 Feb 2022 21:53:53 +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 048E6828D; Fri, 11 Feb 2022 22:53:52 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_C838CBAE-215B-4700-85B0-EE5A0434FFAA"; 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 15.0 \(3693.60.0.1.1\)) Subject: Re: Buildworld fails with external GCC toolchain From: Dimitry Andric In-Reply-To: <20220212.050756.569441849093045289.yasu@FreeBSD.org> Date: Fri, 11 Feb 2022 22:53:44 +0100 Cc: freebsd-current@freebsd.org Message-Id: <116A6C73-6A06-4671-9C82-5D58A7F05018@FreeBSD.org> References: <20220212.050756.569441849093045289.yasu@FreeBSD.org> To: Yasuhiro Kimura X-Mailer: Apple Mail (2.3693.60.0.1.1) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644616434; 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=R/erRDxcI0T2XcRPY7Pe8OTC2ygXz1eyiI0el93LYG4=; b=e0lKMwH2VZDd6lMu9/z35tbAss5w4ATtW+m/ePLSbECXzExYO/+7JpFPMDR45emUndqfwt lfQ0onttnuLr3umkjunTVkGqcfdOLJssa1SZSzxdAYJ1XtA6whUP8YDMif+H4Wz6SqDDrT qjXKnEsu+kdy8mE32BgvFpthOtALuZoDTwBdv1k0Y+Qoax2BIQ5zvouC+x0UW0jiuw+FlW 3tnNxNt5kh7JxoBDbXdto1ACXoCrdpem40JY0/WM+FdGl3BN1Svg6Girj45kwy8WXJfLpu Fjljz9H0dx86AEBcStQIbrK0+INajZ6L/U0yjHO5PQvuEYq+sg9u7i2mugsLew== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644616434; a=rsa-sha256; cv=none; b=kMBde6/zkQJvBzhbxsmhsL/fdd8szv82snz5FxWhJNzg4GOHU+ES16Coc24gkAu790E4Jl +EMVxMWrBnU0ArdaE+U7WsWroqJOQtJqv0SN/5a5ISqPKP8J6Yo74vvwG7QSvK2xixqekY t/3/nmrrHPfmio17Li+1u/qmDFd1snfF4N3Hy8BPdleBN9GXq/yUJk48PzFG6qnqRRrsfD xJ8qK9k+bdUOnRPVJR1lQVtLc13lG/AwmsaM/nwTy1EUfPQoJcnvMe/5aNuk6AGUTV5NQC HHZsUxYapFVjkfJ1OC7zFlBNdA+HsxCdubazwAIS8DfCOAdaLPyYLTm/vJ1YHA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_C838CBAE-215B-4700-85B0-EE5A0434FFAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 Feb 2022, at 21:07, Yasuhiro Kimura wrote: >=20 > I'm tring to update devel/binutils port to 2.38. When it was updated > to 2.37.1, there was a suggestion that it should also be checked if > building base system with GCC succeeds as binutils is a part of > external GCC toolchain. So I'd like to do it with binutils 2.38 before > updating the port. And as a preparation for it, I tried building base > system with current external GCC toolchain (that is, with binutils > 2.37.1). >=20 > At first I read following wiki pages. >=20 > https://wiki.freebsd.org/ExternalToolchain > https://wiki.freebsd.org/ExternalGCC >=20 > Next I took following steps. >=20 > 1. Make clean install of 14-CURRENT amd64 with the install image of > 20220210 snapshot. > 2. Checkout latest main of src repository (d4b0fa45dc1 at that time). > 3. pkg install amd64-gcc9 > 4. cd /usr/src > 5. make -j 4 CROSS_TOOLCHAIN=3Damd64-gcc9 buildworld buildkernel >=20 > Then step 5 failed as following. >=20 > ---------------------------------------------------------------------- > --- all_subdir_rescue --- > /usr/local/bin/x86_64-unknown-freebsd14.0-ld: nc.lo: in function = `_$$hide$$ nc.lo main': > (.text.startup+0xd42): warning: warning: mktemp() possibly used = unsafely; consider using mkstemp() > /usr/local/bin/x86_64-unknown-freebsd14.0-ld: = /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_set_term.o= ): in function `_nc_setupscreen_sp': > /usr/src/contrib/ncurses/ncurses/base/lib_set_term.c:415: undefined = reference to `_nc_set_buffer_sp' > /usr/local/bin/x86_64-unknown-freebsd14.0-ld: = /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_tstp.o): = in function `handle_SIGTSTP': > /usr/src/contrib/ncurses/ncurses/tty/lib_tstp.c:222: undefined = reference to `flushinp_sp' > /usr/local/bin/x86_64-unknown-freebsd14.0-ld: = /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getch.o): = in function `check_mouse_activity': > /usr/src/contrib/ncurses/ncurses/base/lib_getch.c:188: undefined = reference to `_nc_timed_wait' > /usr/local/bin/x86_64-unknown-freebsd14.0-ld: = /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getstr.o):= in function `wgetnstr': > /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:106: undefined = reference to `erasechar_sp' > /usr/local/bin/x86_64-unknown-freebsd14.0-ld: = /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:107: undefined = reference to `killchar_sp' > collect2: error: ld returned 1 exit status > *** [rescue] Error code 1 >=20 > make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue > --- all_subdir_stand --- >=20 > make[2]: stopped in /usr/src > --- all_subdir_share --- >=20 > make[2]: stopped in /usr/src > --- all_subdir_rescue --- > 1 error >=20 > make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue > *** [rescue] Error code 2 >=20 > make[4]: stopped in /usr/src/rescue/rescue > 1 error >=20 > make[4]: stopped in /usr/src/rescue/rescue >=20 > make[3]: stopped in /usr/src/rescue >=20 > make[2]: stopped in /usr/src > --- all_subdir_lib --- >=20 > make[2]: stopped in /usr/src > 167.49 real 492.07 user 94.42 sys >=20 > make[1]: stopped in /usr/src >=20 > make: stopped in /usr/src > ---------------------------------------------------------------------- >=20 > If I check commit messages of main branch over the last few months, I > can find some commits that fix warning message displayed by GCC. So > currently external GCC toolchain seems to work fine. Then what is the > cause of my build failure? Did I do something wrong? Not really, the gcc 9 build has been broken for months, as far as I = know. See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/ The last build(s) show a different error from yours, though: /workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp': /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: = converting a packed 'struct ip' pointer (alignment 2) to a 'uint32_t' = {aka 'unsigned int'} pointer (alignment 4) may result in an unaligned = pointer value [-Werror=3Daddress-of-packed-member] 112 | uint32_t *up =3D (void *)p; | ^~~~~~~~ In file included from = /workspace/src/tests/sys/netinet/libalias/util.h:37, from = /workspace/src/tests/sys/netinet/libalias/util.c:39: /workspace/src/sys/netinet/ip.h:51:8: note: defined here 51 | struct ip { | ^~ -Dimitry --Apple-Mail=_C838CBAE-215B-4700-85B0-EE5A0434FFAA 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYgba6AAKCRCwXqMKLiCW o5DyAJwN/mcalzt1BHr2Nv77BQRVGaBXiACgxAXEaAFk1d62Z0ql05GYm8CARdk= =Gk3d -----END PGP SIGNATURE----- --Apple-Mail=_C838CBAE-215B-4700-85B0-EE5A0434FFAA-- From nobody Sat Feb 12 19:34:16 2022 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 16E3219BA16B for ; Sat, 12 Feb 2022 19:35:43 +0000 (UTC) (envelope-from yasu@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jx11C08qWz3NDs; Sat, 12 Feb 2022 19:35:43 +0000 (UTC) (envelope-from yasu@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644694543; 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=gZhBMygzenNUx1M3Ye7PZmLEbhUmY6XnylFwGu5ZnVA=; b=u9z2y90kPhXeCRLIDfpAYLVtqqDT4BTET5DuF+ZcrokPZZsOcQcMKWtIfB6Whmt6whVZ5k fEIznaHquG27/6Anyc4fm5PkS4kipe68sQQI63JHhoIDFGKp18dAUGnCBnifyJ0bnn5Fh8 psQApsmeZTlMFGxrDJIE6sl3cupSbI3lFJztmd4nE4GfATChP+RMbAiRNdYpNKDCe9P5PJ tQlxuU+TbdG1UiNWuCYqiGxaK6Xqi4rnfgtjsPdsof5bQ73G/KuDJCbnXMHJ4Jk7pIpIzG Dl3BU88cmb1qDCoPffGMDjSpY2snwjntKbmjrt1/pS21Prukovt4eTXFXqsAbQ== Received: from localhost (unknown [IPv6:240b:11:220:fe00:a92b:e366:2068:45ac]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: yasu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4E0A92AD72; Sat, 12 Feb 2022 19:35:42 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Date: Sun, 13 Feb 2022 04:34:16 +0900 (JST) Message-Id: <20220213.043416.312036094791123131.yasu@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Re: Buildworld fails with external GCC toolchain From: Yasuhiro Kimura In-Reply-To: <116A6C73-6A06-4671-9C82-5D58A7F05018@FreeBSD.org> References: <20220212.050756.569441849093045289.yasu@FreeBSD.org> <116A6C73-6A06-4671-9C82-5D58A7F05018@FreeBSD.org> X-Mailer: Mew version 6.8 on Emacs 29.0.50 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644694543; 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=gZhBMygzenNUx1M3Ye7PZmLEbhUmY6XnylFwGu5ZnVA=; b=UQnnqd1ES259obZSPHhrh0t6L32OtMeGI71Cv0q/2A6+Zv5OJkQxt2VPahz4KKo4a5xosR yqtFFhsrPPZeyVOgGsVe3wJkm48615pJmHiGGBtRgeqDUpkw9Y/Um/pb16nTEOqp1d+rTf hJp1Cu+t3kyefDoLVtwxN/WHTW7jJUKUn3Tgl5UlEl4EIoMbSp75YGApthktXH8jvZQ5A6 iZuX7frbqBg0DHhW7XmbAdLuJBVET0f0E6gWDHmZSVv0JxgyBMFUqyRDyzb69OL6PZS8EB 80WWwvYPN4/L8jhU1hzqRg555ms0nkL1MktXgRlETFpodL2/7SyrvU7fP9qfmg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644694543; a=rsa-sha256; cv=none; b=qxM/kLC6o7ibKSU/lBONyoqu/r39t5q+Cf/Iaa5K248uOiQpYW5c6fSsvXGtrrONZist33 bylpPMR36X+uv/itDyPafpC0Zw50rH/y70Hc0gW4QC62HY2PxyZR4C0zCEv262ArkM4QQ4 QoFWcksw+8wRu7OHZIMcfpoo5M6r2GvgAXMduFrJdTAiKtgJ+3SSGggwrQCQneKOm5khRO /v4G7JUCBdPStvI9gcmWaztZkHYb3IMeku6tfS1aVOs9OMLHqLwXMeqMr+IhhNMaR2bASh bJpl0LHXOQrnmJdiIIbvlRlbAKTyIaTnvX/PfWI3AbCYtiYeoVl3jlIQn2CEmA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N From: Dimitry Andric Subject: Re: Buildworld fails with external GCC toolchain Date: Fri, 11 Feb 2022 22:53:44 +0100 > Not really, the gcc 9 build has been broken for months, as far as I know. > > See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/ > > The last build(s) show a different error from yours, though: > > /workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp': > /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'} pointer (alignment 4) may result in an unaligned pointer value [-Werror=address-of-packed-member] > 112 | uint32_t *up = (void *)p; > | ^~~~~~~~ > In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37, > from /workspace/src/tests/sys/netinet/libalias/util.c:39: > /workspace/src/sys/netinet/ip.h:51:8: note: defined here > 51 | struct ip { > | ^~ > > -Dimitry > Thanks for information. I went back the commit history of main branch about every month and check if buildworld succeeds with GCC. But it didn't succeed even if I went back about a year. And devel/binutils port was update to 2.37 on last August. So I suspect external GCC toolchain doesn't work well after binutils is updated to current version. --- Yasuhiro Kimura From nobody Sun Feb 13 00:14:35 2022 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 D66241944A2B for ; Sun, 13 Feb 2022 00:14:44 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 4Jx7C75JQpz4bnR for ; Sun, 13 Feb 2022 00:14:43 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.1.14] (c-98-249-71-218.hsd1.nm.comcast.net [98.249.71.218]) (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) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 38B0C1AF4F8 for ; Sun, 13 Feb 2022 00:14:36 +0000 (UTC) Message-ID: <28e2c8f1-0017-ccd4-8e16-1e7625e6ba3c@freebsd.org> Date: Sat, 12 Feb 2022 17:14:35 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: USB Disk Stalls on -current Content-Language: en-US To: freebsd-current@freebsd.org References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> From: Sean Bruno In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Jx7C75JQpz4bnR X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 199.102.79.106 is neither permitted nor denied by domain of sbruno@freebsd.org) smtp.mailfrom=sbruno@freebsd.org X-Spamd-Result: default: False [1.72 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[sbruno]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.18)[-0.176]; RECEIVED_SPAMHAUS_PBL(0.00)[98.249.71.218:received]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(1.00)[0.997]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:199.102.76.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >> > > I think I'm going to grab one of these fancy 5-disk USB 3 enclosures I > see on the Internet.  ;-) > > Most of the consumer grade units seem to have one or more issues (no NCQ > depth more than 1, loud/bad fans, hard to get a real JBOD mode, JBOD > mode eats serial numbers making ID hard). > > I think I settled on the TERRAMASTER D5-300 USB3.1 > > I'll post back results when it arrives and I get done swearing and > cursing during the replacement. > > sean > > Performance, unsurprisingly is way better. Some irritating XHCI initialization was noted on reboots: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261912 I am currently moving stuff around but it is fun to be able to put my old 2 disk USB 2 array into the 5 disk USB 3 array and have ZFS just flat out DO THE RIGHT THING. Its fantastic. Another thing I noticed is the lack of support by this vendor for SATA NCQ. Not surprising, but SUPER irritating. The drives I'm using definitely supported this in the their old USB 2 enclosures, but the only thing I can do is yell at the vendor. sean From nobody Mon Feb 14 18:46:29 2022 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 DC66E19BEA81 for ; Mon, 14 Feb 2022 18:46:31 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyCqW5xs1z3w1W for ; Mon, 14 Feb 2022 18:46:31 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644864391; 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=dtvhZqUVIEd7krT71WCUd1bzFDSvQ5aiMIuFb8r5KdI=; b=x9+OON7V+wmAXxLAn5+wLuzQs0sXncfVMpvWIWRTMZ05G6JwU2/+5AhgUXhsm5hS+YBCEr NP0DCstF6JHM/U9MF9M5CJOKOCE9dWRkwlzx2X4S9ZCPp4WCogAIRoSfnzDTah1wmT9P8n 8kjvR4ANjWe/IGa6jO63OAXbMHV2hpt9mASVxN3PwZZcz4ZpB1jzz0Cq4DJ2ykQShLOLJa 9p5tBcpCe5pMzbQCfTwgPiJ8Dk+E9IeE3V7XUGqjsXmzOFlEDH6Q9CSWomG2PkrCZHH/ch wvbkGPcAnU+Z+GLLSgTP2DWynoSfa6KkabZ1f8w7CL45gda6ncaPNLnNQxNDKA== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 7C41022B4C for ; Mon, 14 Feb 2022 18:46:31 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Mon, 14 Feb 2022 10:46:29 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: Buildworld fails with external GCC toolchain Content-Language: en-US To: freebsd-current@freebsd.org References: <20220212.050756.569441849093045289.yasu@FreeBSD.org> <116A6C73-6A06-4671-9C82-5D58A7F05018@FreeBSD.org> <20220213.043416.312036094791123131.yasu@FreeBSD.org> From: John Baldwin In-Reply-To: <20220213.043416.312036094791123131.yasu@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644864391; 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=dtvhZqUVIEd7krT71WCUd1bzFDSvQ5aiMIuFb8r5KdI=; b=MjsZcAHNnR38eX/OFPHPeOeVTKh22wRa+o2AAuXJSqsZOeQXQ7BT8aiC6jW+4wRZF5mjEs 88asb4w3l9jNw1Xb4Jsrxv6qrC5/ToiGRi96mO4UcADDya9e3q7QvWyJ4Q2/1jKbgKMRkO m2HUHt9iHA5fOcftqRztDsQgm693OuhE7WwXjZTWsKlH81l7uw9lpcl79TzWUonc4hhBIz USTHPPOb1IDKidp/F/bPkFUJc7xuS3HWrUxU6OkQ7Q6RWLKzQ7HGasqVyY8ghNGVNg3Adb ncasjuaW0KUrXOwbaq7E8/ziYaboVJxZB5f5vwCpHd0rs5rzgnvg34zuJjWFfw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644864391; a=rsa-sha256; cv=none; b=CYsixQhLXMOOtMt/pP6dVI7Zbbezs3EHkri8Kv2w6Vv4OT+DHKNbk6aCqYy+ifASpif/7v tNzouzjxT8kKUPU7QRQ2qRDxAGSCWZ0Q2ap7Xrr0ErelobSLsv9GZFEMEJAw92pHuNO99K NJth4BISk//SdKJdIgoea/QfEp5BY26iDtoashikIAYTeID4PlNtEbL7sLNIh/upOdCRYQ l9y/GdzBadswxVYg9SBk2z9/zkVp/Doa7eRSQiY+PZBH5G3caKbdNUhrPzCvieZox3UMIX fPBrbIWVRjVxs4tdgMXoLshOtvbcdDvPcWYAmjA30mO3yE5QcxW80clupFpmwQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 2/12/22 11:34 AM, Yasuhiro Kimura wrote: > From: Dimitry Andric > Subject: Re: Buildworld fails with external GCC toolchain > Date: Fri, 11 Feb 2022 22:53:44 +0100 > >> Not really, the gcc 9 build has been broken for months, as far as I know. >> >> See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/ >> >> The last build(s) show a different error from yours, though: >> >> /workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp': >> /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'} pointer (alignment 4) may result in an unaligned pointer value [-Werror=address-of-packed-member] >> 112 | uint32_t *up = (void *)p; >> | ^~~~~~~~ >> In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37, >> from /workspace/src/tests/sys/netinet/libalias/util.c:39: >> /workspace/src/sys/netinet/ip.h:51:8: note: defined here >> 51 | struct ip { >> | ^~ >> >> -Dimitry >> > > Thanks for information. I went back the commit history of main branch > about every month and check if buildworld succeeds with GCC. But it > didn't succeed even if I went back about a year. And devel/binutils > port was update to 2.37 on last August. So I suspect external GCC > toolchain doesn't work well after binutils is updated to current > version. I have amd64 world + kernel building with GCC 9 and the only remaining open review not merged yet is https://reviews.freebsd.org/D34147. It is work to keep it working though and I hadn't worked on it again until recently. -- John Baldwin From nobody Mon Feb 14 23:26:00 2022 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 4C5C919CD504 for ; Mon, 14 Feb 2022 23:27:17 +0000 (UTC) (envelope-from yasu@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyL3T1mh1z3M7X; Mon, 14 Feb 2022 23:27:17 +0000 (UTC) (envelope-from yasu@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644881237; 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=mJXyGVoOTgrLeEE8K+e1lv/cC6M3nLsAEgxXsdGKP+w=; b=obzvT3S0xL18iQvC8y/L3FXCMpZ8ES5TFRDL2CM6X6XZIAsIBILi7czw/0knKfyGR8wjzT bkYQRyrXtepROTvIXGD6jQeMfscV+aoUP1ooGrI0fNzYgJstHFjAt6FCrBaPHiV8hrUbEg 4p63MnKinEMzuG6xlY7qz5QvvueaeAjmMJwe6Cq57HrmRcv0uldmv2kKccah5H7ajARjS6 xOtrumB3DpqqhliPbZ6rZJz2V/sZTty4ub4CS32zF8CYv3gGpvw5ZYRHsTBWIAktf/5mkg XO4k0aIbPeENCWssG5DkaEbKVm0KGX5HdsV8Xtdux1vygdX8UwPkgggYu6WL2w== Received: from localhost (unknown [IPv6:240b:11:220:fe00:1d2a:3996:f353:7c5d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: yasu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 7F84524D7A; Mon, 14 Feb 2022 23:27:16 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Date: Tue, 15 Feb 2022 08:26:00 +0900 (JST) Message-Id: <20220215.082600.277857195136294442.yasu@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Re: Buildworld fails with external GCC toolchain From: Yasuhiro Kimura In-Reply-To: References: <116A6C73-6A06-4671-9C82-5D58A7F05018@FreeBSD.org> <20220213.043416.312036094791123131.yasu@FreeBSD.org> X-Mailer: Mew version 6.8 on Emacs 29.0.50 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644881237; 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=mJXyGVoOTgrLeEE8K+e1lv/cC6M3nLsAEgxXsdGKP+w=; b=vJOL/QzUt1PkjppilroC9kFBif4QDsTFmm5YpUSgvX76f2WnhxTHBXQJK5Yo58efZ4Nj44 w3g9+CVDYihOd/FbCgdoPwWPZJH+bw+aXWSYi2jiij+IS0ecZ0B+x77IgzlfydCfDOxOyD sLy+fG4hKIOmUfBSBavWJXGyt/yPF7t0Kqj0c9ZHeU75r242wgPSYCrTReR9US93tF6hEE O5IS1S1B6A/bD3KGk/lFxuJ7PaZCGDGyFQLDZMc5Le3TamiZeS/8S9F7G0qz81cmmnJq8k 0yyO0MwDMjLQLE2QYZXfU6NWJbruovvY0fn4EqdgtgxE5ReYZW06AQ5FJLu/aQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644881237; a=rsa-sha256; cv=none; b=C3EdWHMVEbRBCXuS8KoC3ekHHTf+tAFoEFlnmponbFnwiTGXbHa+HQEjgL5ICcRS6YwzeY BxwkEPeDyMcyQYZgH9v+702eMngNir17FLadNjFZT914chg4DFnWk9Y1luEnBq/faFDJFR snVG0/uxpT/iBA0eZOdZ9KenLRy5tcLo07V1yzGwxsjBt+KiBHMDafQAXEKDxItpbR54C8 qDZO5ktGoMcu2e3p/8blP/4/K1pX8AtZotzA3NVIWVSxmwO/AzNHyzMYAR4baGF/oZbLKH /ORdDnk5Oe+5U1a6tIOscDIJwAZEcxThbHtwnNsmfgTO9kgoUo8OPVtpv4d8AQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N From: John Baldwin Subject: Re: Buildworld fails with external GCC toolchain Date: Mon, 14 Feb 2022 10:46:29 -0800 >>> Not really, the gcc 9 build has been broken for months, as far as I >>> know. >>> >>> See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/ >>> >>> The last build(s) show a different error from yours, though: >>> >>> /workspace/src/tests/sys/netinet/libalias/util.c: In function >>> 'set_udp': >>> /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: >>> converting a packed 'struct ip' pointer (alignment 2) to a 'uint32_t' >>> {aka 'unsigned int'} pointer (alignment 4) may result in an unaligned >>> pointer value [-Werror=address-of-packed-member] >>> 112 | uint32_t *up = (void *)p; >>> | ^~~~~~~~ >>> In file included from >>> /workspace/src/tests/sys/netinet/libalias/util.h:37, >>> from /workspace/src/tests/sys/netinet/libalias/util.c:39: >>> /workspace/src/sys/netinet/ip.h:51:8: note: defined here >>> 51 | struct ip { >>> | ^~ >>> >>> -Dimitry >>> >> Thanks for information. I went back the commit history of main branch >> about every month and check if buildworld succeeds with GCC. But it >> didn't succeed even if I went back about a year. And devel/binutils >> port was update to 2.37 on last August. So I suspect external GCC >> toolchain doesn't work well after binutils is updated to current >> version. > > I have amd64 world + kernel building with GCC 9 and the only remaining > open review not merged yet is https://reviews.freebsd.org/D34147. > > It is work to keep it working though and I hadn't worked on it again > until recently. Thanks for letting me know. I tried patch of the review and confirmed both buildworld and buildkernel succeed with GCC 9 and binutils 2.37. So I reached start point now and can test binutils 2.38. --- Yasuhiro Kimura From nobody Tue Feb 15 18:28:13 2022 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 08F7219D56B0 for ; Tue, 15 Feb 2022 18:28:47 +0000 (UTC) (envelope-from yasu@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JyqNZ6txxz4fQK; Tue, 15 Feb 2022 18:28:46 +0000 (UTC) (envelope-from yasu@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644949727; 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=JdO/udndN1hFKVradcizxcqbkcJV43Mas+GFiV+zi9Y=; b=uJD0GAJj1cAWbkzTIn+XzM1b6OD7HOcj4B7+wswsAOEk6zjLIfRLwM2M8rEF3OtLJx7PjU zBGOwVuqe34KdsYKEjy9hkUQp0zuw/4KKW22vh2h5Pbd/lTpotrXdIms+Ao7DiWqcp9MqM 8b0f151x/RlymuEo2RtOTwMLXCJq9KQQZwmdcesYPR+e65dL8hyvcDLyqcjSgalDBDqdGr PMTYS/22UEzxalgB1UqePq8Vi3QJNBg7ITE4EYLgQt5WeJitcO+RDfQ+h4l3flEWNjmFkD Hz+PhzMGO23kHTuUJn561ash2ypt8mzakolyCzEyg6cOMqR4aL5x3D+v8nr6kw== Received: from localhost (unknown [IPv6:240b:11:220:fe00:a00:27ff:fe05:12f4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: yasu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 33B582E9C4; Tue, 15 Feb 2022 18:28:46 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Date: Wed, 16 Feb 2022 03:28:13 +0900 (JST) Message-Id: <20220216.032813.2297496974520620245.yasu@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Re: Buildworld fails with external GCC toolchain From: Yasuhiro Kimura In-Reply-To: <20220215.082600.277857195136294442.yasu@FreeBSD.org> References: <20220213.043416.312036094791123131.yasu@FreeBSD.org> <20220215.082600.277857195136294442.yasu@FreeBSD.org> X-Mailer: Mew version 6.8 on Emacs 29.0.50 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644949727; 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=JdO/udndN1hFKVradcizxcqbkcJV43Mas+GFiV+zi9Y=; b=nYrSq5zlqbpzvb2JVyUkM1macdH7w9Xv9RvL6PqMNykqOKTKGTniFAEQF3scFCTQa4zKki mThF92HKob/G3T+/3ki07cOO561Wldh0KsIETD5zfr4wwIS94pUxSBKNbmqv9gh2iQrgCD Eq7pEP/iJy+f2qn0/cGZBrwP3qftCEQyqGWhqAYftEqsyaTXQ2kaLV3XvhyrIZ4q0ZpBU6 tKALgCDZhwTgd2nxBfBIWc5HJ4a57B6fp/BJ/toEkuWETMPHC1vHbC8mlCVhOR33TR02YT RhZ17i4KAWotzno4Yc9A297doGrycBX8qfVJ1WVnEX8Br9IUsV5h0pomXst5BA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644949727; a=rsa-sha256; cv=none; b=PQQcYQGgeghKZgeZKs7FT7p+30itheOOgABP72SHf5pgx0AjO9qGL3Hlzi/Y4vavRnVtj/ P5OHC8IHgsUxj/HZAS9EFV+SkfF7JGUpVnPHMPM02fXRergztCiaWma2Ur7TIvrX4TJb6H smpgjXbnAuG2ICO857OFt0ctSAixXqmSu5ibsIqxFWJnqy3tITDpkkJwrZxBoLcU+hU8lT xZlJ1LE0pCL5MwKdAcHafM07euk8Kaqscq8eaK4YzGb1mOln0rz050sjru6bHFVe619u3U 8hJJLrBXqtrRkRn0RT9uOccBTrQHIdLdfv6fQo6g8+brg/DDl/Ykslj2Mf5uqQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N From: Yasuhiro Kimura Subject: Re: Buildworld fails with external GCC toolchain Date: Tue, 15 Feb 2022 08:26:00 +0900 (JST) >> I have amd64 world + kernel building with GCC 9 and the only remaining >> open review not merged yet is https://reviews.freebsd.org/D34147. >> >> It is work to keep it working though and I hadn't worked on it again >> until recently. > > Thanks for letting me know. I tried patch of the review and confirmed > both buildworld and buildkernel succeed with GCC 9 and binutils 2.37. > So I reached start point now and can test binutils 2.38. I tried buildworld and buildkernel with binutils 2.38 and they completed successfully. Just FYI. --- Yasuhiro Kimura From nobody Wed Feb 16 03:29:11 2022 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 DB5BE19DE359 for ; Wed, 16 Feb 2022 03:29:15 +0000 (UTC) (envelope-from Weike.Chen@Dell.com) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 4Jz3NB64Fsz3F8N for ; Wed, 16 Feb 2022 03:29:14 +0000 (UTC) (envelope-from Weike.Chen@Dell.com) Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 21FMfKiZ011142 for ; Tue, 15 Feb 2022 22:29:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=aeaguKJatPiNStTPiz4OX7ulmb7n9P/3yfEblSmq1+s=; b=KhEL+MxAguFCD/4IyL3yoi73z3WF6BpJl9AniU7z3dgs9mj7yK9SVsJec29B3x6oj3LG c2yhzyc1AZkGvGa+/p2rvZOy0OnTrDFYkLvJ/Eg3sZnVh6QsI0yYpGEJ8w10ObXbgbA7 h0qVSJSpyFuEdfgsvzIAlUGXRNhNX0R+oFCw3J9JdQPGlOMB0Q2ASNOKr8nR0t8PW0rx +tWzlsIsc4SY+MqFGl1fnQg+KfQg9JFx74uLfa2EsW9QVdPEdJy311iDzctRcwE8viqJ q2+GqwVWZFWE0rbEbgYJBzCPTU7Ao+HyY+xIHbVZxQBTWrn9Tqh1QeA4wABNx8xSi3c3 YQ== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com (PPS) with ESMTPS id 3e8n6krw8m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 15 Feb 2022 22:29:14 -0500 Received: from pps.filterd (m0089483.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 21G3Abbo068437 for ; Tue, 15 Feb 2022 22:29:14 -0500 Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2100.outbound.protection.outlook.com [104.47.55.100]) by mx0b-00154901.pphosted.com with ESMTP id 3e8n4pu6mq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 15 Feb 2022 22:29:13 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H0suLHx+75d5mK6ZI1qbyVvTNRFLdhQNWgAWclGRZXoVAt+/n0LFT5uXXyyDs9t68XmhDYWnMADkR8LmBct7ngeQEZp8tLbafNarqxw7HZGcOSUaKZRTvhvFW+u9GJZkjjd3FiLX0oslF/1XjuNpuMM0r+kEiD3O8zPEczBzV8Pqm4clADinvc67g4YUaQANdGmGcq55xr8/TT52hfgYuuaj2Rr3MwRmZsIGwsgSuebHl+bLvndXR7bmdn8LY3dKhfN2lfIMswRj6DGFAyBKTV9EM3C8P/s9fV6ls3E63zHwidVfeab2q4wiH31KBdOqumMpCMbzCWU+Kg4R34L1aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aeaguKJatPiNStTPiz4OX7ulmb7n9P/3yfEblSmq1+s=; b=lE3r8toRrpywMr/HwsLcEvAFEexwci5qFBCZzAOhvRAjB1sHSPnIy+NzERk/cPtqS8S7GIxMLtGeyHYqufGWxxaFE5Y1M8PButIrJkkOrnrmL8nfbBd3zGxuigUbXJyD8nrV91zuwnAbswqz7gj3MEdt38PQ0gPU2QV8F1S3VcS5frweCfWUZ6WoOXH1nEAwqNCSZM9uYzf5f9X+ySTt8XLUiVuhQyFzSw4hbq1jA1bgG52MQpn3wv8MWD0sIIOod8MDa21edJzxTxzJdN+Tg9Zgh/Hb+H0rk7dDsq8PdL4FytKSendIVNoaEUn2Wps2mAa3sjwShxee1bE1EeX1wg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none Received: from PH0PR19MB4938.namprd19.prod.outlook.com (2603:10b6:510:94::9) by DS7PR19MB4503.namprd19.prod.outlook.com (2603:10b6:5:2c3::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.16; Wed, 16 Feb 2022 03:29:11 +0000 Received: from PH0PR19MB4938.namprd19.prod.outlook.com ([fe80::704f:ebed:4242:35ed]) by PH0PR19MB4938.namprd19.prod.outlook.com ([fe80::704f:ebed:4242:35ed%5]) with mapi id 15.20.4975.019; Wed, 16 Feb 2022 03:29:11 +0000 From: "Chen, Alvin W" To: "freebsd-current@freebsd.org" Subject: [Intel AlderLake]Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Thread-Topic: [Intel AlderLake]Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Thread-Index: AdgiU7LtuqDwFf1bQ0eAzhIfnwoyFwAkPrvwAAAl4WA= Date: Wed, 16 Feb 2022 03:29:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Enabled=true; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SetDate=2022-02-16T03:29:09Z; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Method=Standard; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Name=No Protection (Label Only) - Internal Use; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ActionId=f0b027b1-a48d-4371-ad06-f2b088217420; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ContentBits=2 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 23a59bde-57f5-4915-22b1-08d9f0fc7fec x-ms-traffictypediagnostic: DS7PR19MB4503:EE_ x-microsoft-antispam-prvs: x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4 x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: a+fDy0M1pSOWQCJnKgot7CR12N1Pkl/MPAviT8cVI/zjrTc9xKnqzxJUgIScGWyUvbkxUs4aZfFvS/P/WvaaNHpfnW6yZwTfgn8cEDryrvQviMOUXYXUsXxVr/gll0xCpBLUrLdmcfSU6QgraG5MsV2VE+64pWCQIsjeRyv4nw/uwlmBLo3B+z6LI6n0lRUl4KdzwaCrDv4hJZWEVtSo3fp9pCHaTU/7n0Bh66WhC/vJUBLuvd9QkRi1BBHDXA+9oOHi/OSE+3QEBJmGy/ueDOTKkZOdWlvxr+oc3Z3U8eZV+q5jrVkJVbCYAqCT+nDYmH05StL6JI2zbX8BPMS+Bm+VsaMTIDzTTfW3zmPspU6obbT0xo37gWt2H1pn3rPP9ELeauIHgBSydRSXyAF3NyZpxFzrUQowLJsd6tDHJXa2WWZxCJwpE76BXCFujUfvFZlbC+tQnFQMHZZTgON/q6VxrSDQ4vj7N4IYk/tzAhRnoxbOhEHHYxDXqBxlN6HbQh1wjTi680Fz5vb+tseEYRZKPiDtz4GNzeNZf2mpRnDuNog8CMxlsJAA29rMglyH4XLngjb5bNe9W9pMoUiZVB3Ia0Ayr9rqHJrIeAkC8ChXRwRfjk7UruxUFIYO+cBcjLfgArWemGeOE94N9v/glQzdGZyzDGfrYTQs9bhTVLq5cNAqJ8hnsN8qwAZ4xZdjpzlnZf/4tY4pXjHFj5O/KgX7ffy5moU02pSqzb72xryIYV0TA2eAns7h/RX7Mb3j4ufaYhznuCPgpXX6u9I8fP2XZ/VHHJ8y0eiNzSxnJBg= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR19MB4938.namprd19.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(38070700005)(71200400001)(64756008)(2940100002)(166002)(8676002)(66946007)(9326002)(76116006)(8936002)(52536014)(66446008)(66476007)(66556008)(55016003)(82960400001)(38100700002)(122000001)(6916009)(508600001)(83380400001)(7696005)(6506007)(86362001)(26005)(186003)(2906002)(33656002)(5660300002)(9686003)(316002)(786003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?j8HTuC6hu5u4EqzA341qHKMh879nN4bkfZPlPWltYNhT97QvdESh/N4Xax+j?= =?us-ascii?Q?wddgESGmCi/8WHSljRjEzbO7BDaYJB26MUZ5NRpkfi97MKpLh5KfzQpWdO9g?= =?us-ascii?Q?S3aRNT9nxdSyrw2M7ej3f2VAKKKTE0br7uTqC+s8VSmUsBAGpFNeoyGr6OMT?= =?us-ascii?Q?9fwa0oKTt5XmKAq1aLvFWfzHqXOSa6QkMGwSLYGhvo5jvzygMszAIRA60QIF?= =?us-ascii?Q?PZwCT9UQ8hj9Etr5+ori7eA+I9WwLDgB3suHde2bdRGO1tO/bUm1MoWODfiD?= =?us-ascii?Q?UfuVLwf4zGG+9ToTt0qT0PAVKoQN/gZnRN1yKy6MtwuP3Frg9crNbAIdH9Xl?= =?us-ascii?Q?3mYlUZ1MKncYgewNOuLhcMKM2/j3Y3QjBu1CsMNZui4MXv6ufLzhQx43noEq?= =?us-ascii?Q?j0/404lcoyxHRs2XbzZfXgT+1GspuUOn28AeG6XsSkcTEeSex6WQo21GtMsY?= =?us-ascii?Q?WI1Pw3Nu9JcXHrpFkGyUCDAmjSLEpdgXspr2L0axjFwUV3TmbJ0BmrVyDA4J?= =?us-ascii?Q?jOai0VXJWSOsizLC4D+7pcAtwKT9pOL+Hi0OWTziKVkcxQx1moUCFVs0wV3k?= =?us-ascii?Q?t2+rX1TXEu3rdgDTtG3lGyTEVUky2jv9ohx16U1KWqNVwGaInfiH975hJVnS?= =?us-ascii?Q?mJT5zzZgitD5LrunEynpfYhkezJ8B8xHamWR21Z7zh6Iub0VESGOjYos3OSI?= =?us-ascii?Q?ozs/qqGfabZXvtA0ncMKU9DGjCErius+u4hwxtC6XAB/jxj8zsoPmi/tU9Th?= =?us-ascii?Q?WIoshk7fQFgVC/o6WzQlEpe5gp/rXBAS1SohXYludijE+qX5DAL/SOesIpaT?= =?us-ascii?Q?kI6jz6V2hXUQry9m8pKR8+sha+qKmgzdPM94POu8xLCwOyRYR932RWmVAvEz?= =?us-ascii?Q?eBYQbZ4zT+As/j91he2mGihL5COG6N5lclpqUHQelF7GQKIaFsqoZ0SdoEmA?= =?us-ascii?Q?55imb5BQI2nIR16vXwmqGRBKeWGWb4jEwzYEt5MYM9+epwXMygFfEkM9xl9c?= =?us-ascii?Q?XtJTVqorr7o+42mMSO5ODyhhvNk8Ka1+mpJOGh7xcA2fZClKuu6Q5N6QcJ1z?= =?us-ascii?Q?+BrINrJkSFD5E5jVgp1Pw9Ld3HPUJh47wtdTIuDHCYDER9Xlpv4jcMXghvds?= =?us-ascii?Q?iLVC9ai4+uo/6K86OVnWXZUzze5qInzMta7TRwSni6DwSSBySq4RBtIfGLvv?= =?us-ascii?Q?9b6dNR+MH5m3fXkpDHb3zeq9xIUVSCnWm7QD+lxFhsgiDmZLHhyx5Ace0NpI?= =?us-ascii?Q?q1x4lRM6IMtIlvLQCo8YTeBhgwvnVluuYKuoZxFZvYSZqIJXj3x+wnjJld1t?= =?us-ascii?Q?/jtbthf6ZgYp0o4VABQ0deISznbNOQSoNoRucGgxk13NhC8H16ESqJYHLGSV?= =?us-ascii?Q?WmEJ5YGYX/30nAxM8pSFT4lK77pZO99iBCfx+ScFUiyU8UftofYsCUXTr5bs?= =?us-ascii?Q?4V2ItluQNmS7jV6KymhS8Dgx0h/BEsx6f+Furkrthj862ChN8U7/PvNRVAVf?= =?us-ascii?Q?cyOI4HqB2s/XTqz1x1UrxxaqyDLyJH8MspVCYrvVWYP24Hg9NXhM3R60mIst?= =?us-ascii?Q?Kg130WrizLPGRiNHsImFiQlq8wAbxyHKNa0Y80XWtq6+6oMHdn8zjY9DC0pX?= =?us-ascii?Q?kwP+xamx9tBMBBAOLt8Wfao=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR19MB49388A4BC14B16FCEA5F742D9E359PH0PR19MB4938namp_" 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-OriginatorOrg: Dell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR19MB4938.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23a59bde-57f5-4915-22b1-08d9f0fc7fec X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2022 03:29:11.7159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: q1O3EqSXAAOMdN6ssGSQykC0/pQKFh/5dGtaxzHhO+8JLmnvr45pXTMjj2CbB171mYfYJsB5XLW5NjOlD4yIuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR19MB4503 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.816 definitions=2022-02-16_01:2022-02-14,2022-02-16 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 spamscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 mlxlogscore=928 suspectscore=0 clxscore=1015 adultscore=0 bulkscore=0 lowpriorityscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2202160014 X-Proofpoint-ORIG-GUID: hmtaR6gXg8K8Rr64SjMHFy_v77XU-YO0 X-Proofpoint-GUID: hmtaR6gXg8K8Rr64SjMHFy_v77XU-YO0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 adultscore=0 phishscore=0 mlxlogscore=999 bulkscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202160014 X-Rspamd-Queue-Id: 4Jz3NB64Fsz3F8N X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dell.com header.s=smtpout1 header.b=KhEL+MxA; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); dmarc=pass (policy=none) header.from=Dell.com; spf=pass (mx1.freebsd.org: domain of Weike.Chen@Dell.com designates 148.163.137.20 as permitted sender) smtp.mailfrom=Weike.Chen@Dell.com X-Spamd-Result: default: False [-6.10 / 15.00]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[dell.com:s=smtpout1]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:148.163.137.20:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_REJECT(2.00)[signature check failed: fail, {[1] = sig:microsoft.com:reject}]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[dell.com:dkim]; RWL_MAILSPIKE_EXCELLENT(0.00)[148.163.137.20:from]; DKIM_TRACE(0.00)[dell.com:+]; DMARC_POLICY_ALLOW(-0.50)[Dell.com,none]; RCVD_IN_DNSWL_NONE(0.00)[104.47.55.100:received]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; WHITELIST_SPF_DKIM(-3.00)[dell.com:d:+,Dell.com:s:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:22843, ipnet:148.163.137.0/24, country:US]; RCVD_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.157.37:received] X-ThisMailContainsUnwantedMimeParts: N --_000_PH0PR19MB49388A4BC14B16FCEA5F742D9E359PH0PR19MB4938namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Guys, Any updates to support Intel P-core + E-core? I have filed a bug: PR 261169, but no updates. Does anybody know the progress? For Intel Adler Lake P core + E core processor (i7-12700T), copying files t= o FAT32 partition, the file corrupted (50%), but ZFS is fine. After disabli= ng E core in the code by restrict the max cpu number, this issue is gone. A= nd No E core processor has no such issue, like i7-12400. HW ENV: CPU: Intel AlderLake 12th Gen i7-12700T Disk: NVME SSD There are 3 methods to reproduce this issue: 1. Make FreeBSD 13 USB disk installer, install FreeBSD with UFS, and select= install source and ports, the txz package checking will be failed. 2. Boot to shell by USB disk installer, and mount a FAT32 partition (on SSD= ), and copy a 300MB file to the FAT32, compare the sha256 checksums for the= source file and the dst file, the checksum are different (50%). Or if ther= e is a 300MB file in FAT32 partition, mount the partition, and for the firs= t time check the sha256 value by running 'sha256 file.tgz', the checksum is= wrong, but the second time, the checksum is correct. 3. Install FreeBSD 13 with ZFS, and it can work well. And boot into FreeBSD= , disable swap, and format the SWAP partition to FAT32. Do the testing as a= bove. Regards, Alvin Chen Dell | Comercial Client Group office +86-10-82862506, fax +86-10-82861554, Dell Lync 8672506 weike_chen@d= ell.com Internal Use - Confidential --_000_PH0PR19MB49388A4BC14B16FCEA5F742D9E359PH0PR19MB4938namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Guys,
Any updates to support Intel P-core + E-co= re?
I have filed a bug: PR 261169, but no updates.
Does anybody know the progress?

For Intel Adler Lake P core + E core proce= ssor (i7-12700T), copying files to FAT32 partition, the file corrupted (50%= ), but ZFS is fine. After disabling E core in the code by restrict the max = cpu number, this issue is gone. And No E core processor has no such issue, like i7-12400.

HW ENV:
CPU: Intel AlderLake 12th Gen i7-12700T
Disk: NVME SSD

There are 3 methods to reproduce this issu= e:
1. Make FreeBSD 13 USB disk installer, ins= tall FreeBSD with UFS, and select install source and ports, the txz package= checking will be failed.

2. Boot to shell by USB disk installer, an= d mount a FAT32 partition (on SSD), and copy a 300MB file to the FAT32, com= pare the sha256 checksums for the source file and the dst file, the checksu= m are different (50%). Or if there is a 300MB file in FAT32 partition, mount the partition, and for the first= time check the sha256 value by running 'sha256 file.tgz', the checksum is = wrong, but the second time, the checksum is correct.

3. Install FreeBSD 13 with ZFS, and it can= work well. And boot into FreeBSD, disable swap, and format the SWAP partit= ion to FAT32. Do the testing as above.

 

 

 

Regards,

Alvin Chen

Dell | Comercial Client Group

office +86-10-82862506, fax +86-10-82861554, Dell Ly= nc 8672506 weike_chen@dell.com

 

 

Internal Use - Confidential

--_000_PH0PR19MB49388A4BC14B16FCEA5F742D9E359PH0PR19MB4938namp_-- From nobody Wed Feb 16 10:31:02 2022 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 BA228194B48C for ; Wed, 16 Feb 2022 10:31:15 +0000 (UTC) (envelope-from qroxana@protonmail.com) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JzDl63ttMz4pYj for ; Wed, 16 Feb 2022 10:31:14 +0000 (UTC) (envelope-from qroxana@protonmail.com) Date: Wed, 16 Feb 2022 10:31:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1645007464; bh=cVI5RDXdEwfx4HLZMpS7k78ypP/7g9AocG5VSdE3jdM=; h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc:Date:Subject: Reply-To:Feedback-ID:Message-ID; b=iRSaKffmAps/E8kDs0/yzGLjcU7ziE/LHdNDzBo1rgT2QU1J1Kx2L8LUa0AQ2Lx18 eTLm0sLqu6q8E38zvoTb/QyPdSneFH4cBfgdqC+9jKdYUcutB5TrzTU/B6Xsvb73Mx X5nxZw+R8TJn/sCM8ds0vSOGRq2I93i6qPQy7641KKQr1B9KZHWZe2aNcf9vYwWmD+ rYz6Zm4He2EsCyp0iMqwH9NBEEfH85ycx8FBt1U0Skz1S5oHlsZkB1QmFXrHyloHyJ 0OMkeZmwifX0N+EVqgxp/nhtCdbM7pGo6vczpnjYVP2v4iPRetuZgUb2HjjQ3Ph4lF NobgmhCQsj/9Q== To: "freebsd-current@freebsd.org" , "freebsd-arm@freebsd.org" From: qroxana Reply-To: qroxana Subject: Kernel panic for if_epair 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: multipart/alternative; boundary="b1_vNmHMfWFb6NRKYLFkhix8peAt5pkGQEEyBO3xBMbE" X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4JzDl63ttMz4pYj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=iRSaKffm; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of qroxana@protonmail.com designates 185.70.40.132 as permitted sender) smtp.mailfrom=qroxana@protonmail.com X-Spamd-Result: default: False [-0.80 / 15.00]; HAS_REPLYTO(0.00)[qroxana@protonmail.com]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail3]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.996]; NEURAL_HAM_LONG(-0.89)[-0.894]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.132:from] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_vNmHMfWFb6NRKYLFkhix8peAt5pkGQEEyBO3xBMbE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SXQncyBydW5uaW5nIDE0LjAtQ1VSUkVOVCBhcm12NyBtYWluLW4yNTI5ODMtZDIxZTcxZWZjZTM5 CgpLZXJuZWwgcGFnZSBmYXVsdCB3aXRoIHRoZSBmb2xsb3dpbmcgbm9uLXNsZWVwYWJsZSBsb2Nr cyBoZWxkOgpleGNsdXNpdmUgc2xlZXAgbXV0ZXggZXBhaXJpZHggKGVwYWlyaWR4KSByID0gMCAo MHhlMmZlOTE2MCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL25ldC9pZl9lcGFpci5jOjE2NQpzdGFj ayBiYWNrdHJhY2U6CiMwIDB4YzAzNTU4ZjggYXQgd2l0bmVzc19kZWJ1Z2dlcisweDdjCiMxIDB4 YzAzNTZiM2MgYXQgd2l0bmVzc193YXJuKzB4M2ZjCiMyIDB4YzA1ZWIzYzggYXQgYWJvcnRfaGFu ZGxlcisweDFkOAojMyAweGMwNWNhOGUwIGF0IGV4Y2VwdGlvbl9leGl0KzAKIzQgMHhjMDQ3NTky OCBhdCB1ZHBfaW5wdXQrMHgxYzAKIzUgMHhjMDQ0MTg4NCBhdCBpcF9pbnB1dCsweGExOAojNiAw eGMwNDE0MjZjIGF0IG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDAKIzcgMHhjMDQwYjlhMCBhdCBl dGhlcl9kZW11eCsweDFjOAojOCAweGMwNDBkMjJjIGF0IGV0aGVyX25oX2lucHV0KzB4NTE0CiM5 IDB4YzA0MTQyNmMgYXQgbmV0aXNyX2Rpc3BhdGNoX3NyYysweDEwMAojMTAgMHhjMDQwYmU5NCBh dCBldGhlcl9pbnB1dCsweDhjCiMxMSAweGUyZmQ4MTMwIGF0ICRhLjgrMHgxMjgKIzEyIDB4YzAy YTFlZTAgYXQgaXRocmVhZF9sb29wKzB4MjY4CiMxMyAweGMwMjllMDg4IGF0IGZvcmtfZXhpdCsw eGEwCiMxNCAweGMwNWNhODcwIGF0IHN3aV9leGl0KzAKRmF0YWwga2VybmVsIG1vZGUgZGF0YSBh Ym9ydDogJ0FsaWdubWVudCBGYXVsdCcgb24gcmVhZAp0cmFwZnJhbWU6IDB4ZTJhMGJhZjAKRlNS PTAwMDAwMDAxLCBGQVI9ZTNmMDJhNTYsIHNwc3I9MjAwMDAwMTMKcjAgPTAwMDAwMDAwLCByMSA9 MDAwMDAwMDEsIHIyID0wMDAwMDAwMSwgcjMgPTAwMDAwYTBhCnI0ID0wMDAwMDAwMCwgcjUgPWUz ZjAyYTZhLCByNiA9ZTNmMDJhNTYsIHI3ID0wMDAwMDA0NApyOCA9MDAwMDAwNDQsIHI5ID1jMGFm OTU1YywgcjEwPTAwMDAwMDE0LCByMTE9ZTJhMGJjMTAKcjEyPTAwMDAwMDAwLCBzc3A9ZTJhMGJi ODAsIHNscj1jMDQ0MTg4NCwgcGMgPWMwNDc1OTI4CgpwYW5pYzogRmF0YWwgYWJvcnQKY3B1aWQg PSAwCnRpbWUgPSAxNjQ1MDA0ODg5CktEQjogc3RhY2sgYmFja3RyYWNlOgpkYl90cmFjZV9zZWxm KCkgYXQgZGJfdHJhY2Vfc2VsZgogICAgICAgICBwYyA9IDB4YzA1YzdmMzQgIGxyID0gMHhjMDA3 YWM0OCAoZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MzApCiAgICAgICAgIHNwID0gMHhlMmEwYjhj OCAgZnAgPSAweGUyYTBiOWUwCmRiX3RyYWNlX3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3Nl bGZfd3JhcHBlcisweDMwCiAgICAgICAgIHBjID0gMHhjMDA3YWM0OCAgbHIgPSAweGMwMmUyNTlj ICh2cGFuaWMrMHgxNzApCiAgICAgICAgIHNwID0gMHhlMmEwYjllOCAgZnAgPSAweGUyYTBiYTA4 CiAgICAgICAgIHI0ID0gMHgwMDAwMDEwMCAgcjUgPSAweDAwMDAwMDAwCiAgICAgICAgIHI2ID0g MHhjMDc3ZjY3MCAgcjcgPSAweGMwOTBkOTEwCnZwYW5pYygpIGF0IHZwYW5pYysweDE3MAogICAg ICAgICBwYyA9IDB4YzAyZTI1OWMgIGxyID0gMHhjMDJlMjM0YyAoZG9hZHVtcCkKICAgICAgICAg c3AgPSAweGUyYTBiYTEwICBmcCA9IDB4ZTJhMGJhMTQKICAgICAgICAgcjQgPSAweGUyYTBiYWYw ICByNSA9IDB4MDAwMDAwMTMKICAgICAgICAgcjYgPSAweGUzZjAyYTU2ICByNyA9IDB4MDAwMDAw MDEKICAgICAgICAgcjggPSAweDAwMDAwMDAxICByOSA9IDB4ZTI5NGUwMDAKICAgICAgICByMTAg PSAweGUzZjAyYTU2CmRvYWR1bXAoKSBhdCBkb2FkdW1wCiAgICAgICAgIHBjID0gMHhjMDJlMjM0 YyAgbHIgPSAweGMwNWViYTE4IChhYm9ydF9hbGlnbikKICAgICAgICAgc3AgPSAweGUyYTBiYTFj ICBmcCA9IDB4ZTJhMGJhNDgKICAgICAgICAgcjQgPSAweGUzZjAyYTU2ICByNSA9IDB4ZTJhMGJh MTQKICAgICAgICAgcjYgPSAweGMwMmUyMzRjIHIxMCA9IDB4ZTJhMGJhMWMKYWJvcnRfYWxpZ24o KSBhdCBhYm9ydF9hbGlnbgogICAgICAgICBwYyA9IDB4YzA1ZWJhMTggIGxyID0gMHhjMDVlYjUx OCAoYWJvcnRfaGFuZGxlcisweDMyOCkKICAgICAgICAgc3AgPSAweGUyYTBiYTUwICBmcCA9IDB4 ZTJhMGJhZTgKICAgICAgICAgcjQgPSAweDAwMDAwMDEzICByNSA9IDB4ZTNmMDJhNTYKYWJvcnRf aGFuZGxlcigpIGF0IGFib3J0X2hhbmRsZXIrMHgzMjgKICAgICAgICAgcGMgPSAweGMwNWViNTE4 ICBsciA9IDB4YzA1Y2E4ZTAgKGV4Y2VwdGlvbl9leGl0KQogICAgICAgICBzcCA9IDB4ZTJhMGJh ZjAgIGZwID0gMHhlMmEwYmMxMAogICAgICAgICByNCA9IDB4MDAwMDAwMDAgIHI1ID0gMHhlM2Yw MmE2YQogICAgICAgICByNiA9IDB4ZTNmMDJhNTYgIHI3ID0gMHgwMDAwMDA0NAogICAgICAgICBy OCA9IDB4MDAwMDAwNDQgIHI5ID0gMHhjMGFmOTU1YwogICAgICAgIHIxMCA9IDB4MDAwMDAwMTQK ZXhjZXB0aW9uX2V4aXQoKSBhdCBleGNlcHRpb25fZXhpdAogICAgICAgICBwYyA9IDB4YzA1Y2E4 ZTAgIGxyID0gMHhjMDQ0MTg4NCAoaXBfaW5wdXQrMHhhMTgpCiAgICAgICAgIHNwID0gMHhlMmEw YmI4MCAgZnAgPSAweGUyYTBiYzEwCiAgICAgICAgIHIwID0gMHgwMDAwMDAwMCAgcjEgPSAweDAw MDAwMDAxCiAgICAgICAgIHIyID0gMHgwMDAwMDAwMSAgcjMgPSAweDAwMDAwYTBhCiAgICAgICAg IHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAweGUzZjAyYTZhCiAgICAgICAgIHI2ID0gMHhlM2YwMmE1 NiAgcjcgPSAweDAwMDAwMDQ0CiAgICAgICAgIHI4ID0gMHgwMDAwMDA0NCAgcjkgPSAweGMwYWY5 NTVjCiAgICAgICAgcjEwID0gMHgwMDAwMDAxNCByMTIgPSAweDAwMDAwMDAwCnVkcF9pbnB1dCgp IGF0IHVkcF9pbnB1dCsweDFjMAogICAgICAgICBwYyA9IDB4YzA0NzU5MjggIGxyID0gMHhjMDQ0 MTg4NCAoaXBfaW5wdXQrMHhhMTgpCiAgICAgICAgIHNwID0gMHhlMmEwYmMxOCAgZnAgPSAweGUy YTBiYzUwCiAgICAgICAgIHI0ID0gMHgwMDAyMmU3NSAgcjUgPSAweDAwMDAwMDAwCiAgICAgICAg IHI2ID0gMHgwMDAwMDAxNCAgcjcgPSAweDAwMDAwMGZiCiAgICAgICAgIHI4ID0gMHhjMDkwZDkx MCAgcjkgPSAweGMwOTQ1N2ZjCiAgICAgICAgcjEwID0gMHhlM2YwMmE1NgppcF9pbnB1dCgpIGF0 IGlwX2lucHV0KzB4YTE4CiAgICAgICAgIHBjID0gMHhjMDQ0MTg4NCAgbHIgPSAweGMwNDE0MjZj IChuZXRpc3JfZGlzcGF0Y2hfc3JjKzB4MTAwKQogICAgICAgICBzcCA9IDB4ZTJhMGJjNTggIGZw ID0gMHhlMmEwYmM4MAogICAgICAgICByNCA9IDB4MDAwM2E3M2IgIHI1ID0gMHhlM2YwMmEwMAog ICAgICAgICByNiA9IDB4MDAwMDAwMDAgIHI3ID0gMHhjMGI1YjRiNAogICAgICAgICByOCA9IDB4 ZTQ0MTdhYzAgIHI5ID0gMHg1ZTRhNmYyOAogICAgICAgIHIxMCA9IDB4MDAwMDAwMDgKbmV0aXNy X2Rpc3BhdGNoX3NyYygpIGF0IG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDAKICAgICAgICAgcGMg PSAweGMwNDE0MjZjICBsciA9IDB4YzA0MGI5YTAgKGV0aGVyX2RlbXV4KzB4MWM4KQogICAgICAg ICBzcCA9IDB4ZTJhMGJjODggIGZwID0gMHhlMmEwYmNhMAogICAgICAgICByNCA9IDB4ZTMyNDQ0 MDAgIHI1ID0gMHhlM2YwMmEwMAogICAgICAgICByNiA9IDB4MDAwMDA4MDAgIHI3ID0gMHhlMzI0 NDQwMAogICAgICAgICByOCA9IDB4ZTQ0MTdhYzAgIHI5ID0gMHg1ZTRhNmYyOAogICAgICAgIHIx MCA9IDB4MDAwMDAwMDgKZXRoZXJfZGVtdXgoKSBhdCBldGhlcl9kZW11eCsweDFjOAogICAgICAg ICBwYyA9IDB4YzA0MGI5YTAgIGxyID0gMHhjMDQwZDIyYyAoZXRoZXJfbmhfaW5wdXQrMHg1MTQp CiAgICAgICAgIHNwID0gMHhlMmEwYmNhOCAgZnAgPSAweGUyYTBiZDEwCiAgICAgICAgIHI0ID0g MHhlMzI0NDQwMCAgcjUgPSAweGUzZjAyYTAwCiAgICAgICAgIHI2ID0gMHhlM2YwMmE0OCAgcjcg PSAweDAwMDAwMDAwCmV0aGVyX25oX2lucHV0KCkgYXQgZXRoZXJfbmhfaW5wdXQrMHg1MTQKICAg ICAgICAgcGMgPSAweGMwNDBkMjJjICBsciA9IDB4YzA0MTQyNmMgKG5ldGlzcl9kaXNwYXRjaF9z cmMrMHgxMDApCiAgICAgICAgIHNwID0gMHhlMmEwYmQxOCAgZnAgPSAweGUyYTBiZDQwCiAgICAg ICAgIHI0ID0gMHgwMDA1MGU4OCAgcjUgPSAweGUzZjAyYTAwCiAgICAgICAgIHI2ID0gMHgwMDAw MDAwMCAgcjcgPSAweGMwYjViNTM0CiAgICAgICAgIHI4ID0gMHg1ZTRhNmYyOCAgcjkgPSAweDAw MDAwMDIwCiAgICAgICAgcjEwID0gMHgwMDAwMDAwMApuZXRpc3JfZGlzcGF0Y2hfc3JjKCkgYXQg bmV0aXNyX2Rpc3BhdGNoX3NyYysweDEwMAogICAgICAgICBwYyA9IDB4YzA0MTQyNmMgIGxyID0g MHhjMDQwYmU5NCAoZXRoZXJfaW5wdXQrMHg4YykKICAgICAgICAgc3AgPSAweGUyYTBiZDQ4ICBm cCA9IDB4ZTJhMGJkODAKICAgICAgICAgcjQgPSAweGUzMjQ0NDAwICByNSA9IDB4MDAwMDAwMDAK ICAgICAgICAgcjYgPSAweGUzZjAyYTAwICByNyA9IDB4MDAwMDAwMDAKICAgICAgICAgcjggPSAw eDVlNGE2ZjI4ICByOSA9IDB4MDAwMDAwMjAKICAgICAgICByMTAgPSAweDAwMDAwMDAwCmV0aGVy X2lucHV0KCkgYXQgZXRoZXJfaW5wdXQrMHg4YwogICAgICAgICBwYyA9IDB4YzA0MGJlOTQgIGxy ID0gMHhlMmZkODEzMCAoJGEuOCsweDEyOCkKICAgICAgICAgc3AgPSAweGUyYTBiZDg4ICBmcCA9 IDB4ZTJhMGJkYjgKICAgICAgICAgcjQgPSAweGM1N2Y1YzhjICByNSA9IDB4MDAwMDAwMDAKICAg ICAgICAgcjYgPSAweGUzMjQ0NDAwICByNyA9IDB4YzU3ZjVjODAKICAgICAgICAgcjggPSAweGUy ZmU5MTcwICByOSA9IDB4YzA5MzgzMjgKICAgICAgICByMTAgPSAweGUyYTBiZDg4CiRhLjgoKSBh dCAkYS44KzB4MTI4CiAgICAgICAgIHBjID0gMHhlMmZkODEzMCAgbHIgPSAweGMwMmExZWUwIChp dGhyZWFkX2xvb3ArMHgyNjgpCiAgICAgICAgIHNwID0gMHhlMmEwYmRjMCAgZnAgPSAweGUyYTBi ZTIwCiAgICAgICAgIHI0ID0gMHhkYjc3ZjY0MCAgcjUgPSAweDAwMDAwMDAwCiAgICAgICAgIHI2 ID0gMHhlM2IzZjU0NCAgcjcgPSAweGUzYjNmNTAwCiAgICAgICAgIHI4ID0gMHhjMDc3Y2VjOSAg cjkgPSAweGUzYjNmNTA4CiAgICAgICAgcjEwID0gMHhkYjc3ZjY0MAppdGhyZWFkX2xvb3AoKSBh dCBpdGhyZWFkX2xvb3ArMHgyNjgKICAgICAgICAgcGMgPSAweGMwMmExZWUwICBsciA9IDB4YzAy OWUwODggKGZvcmtfZXhpdCsweGEwKQogICAgICAgICBzcCA9IDB4ZTJhMGJlMjggIGZwID0gMHhl MmEwYmU0MAogICAgICAgICByNCA9IDB4ZTI5NGUwMDAgIHI1ID0gMHhkNzk2NzAwMAogICAgICAg ICByNiA9IDB4YzAyYTFjNzggIHI3ID0gMHhkYjZlODEyMAogICAgICAgICByOCA9IDB4ZTJhMGJl NDggIHI5ID0gMHgwMDAwMDAwMAogICAgICAgIHIxMCA9IDB4MDAwMDAwMDAKZm9ya19leGl0KCkg YXQgZm9ya19leGl0KzB4YTAKICAgICAgICAgcGMgPSAweGMwMjllMDg4ICBsciA9IDB4YzA1Y2E4 NzAgKHN3aV9leGl0KQogICAgICAgICBzcCA9IDB4ZTJhMGJlNDggIGZwID0gMHgwMDAwMDAwMAog ICAgICAgICByNCA9IDB4YzAyYTFjNzggIHI1ID0gMHhkYjZlODEyMAogICAgICAgICByNiA9IDB4 MDAwMDAwMDAgIHI3ID0gMHgwMDAwMDAwMAogICAgICAgICByOCA9IDB4MDAwMDAwMDAgcjEwID0g MHgwMDAwMDAwMApzd2lfZXhpdCgpIGF0IHN3aV9leGl0CiAgICAgICAgIHBjID0gMHhjMDVjYTg3 MCAgbHIgPSAweGMwNWNhODcwIChzd2lfZXhpdCkKICAgICAgICAgc3AgPSAweGUyYTBiZTQ4ICBm cCA9IDB4MDAwMDAwMDAKS0RCOiBlbnRlcjogcGFuaWMKWyB0aHJlYWQgcGlkIDExIHRpZCAxMDAx NzQgXQpTdG9wcGVkIGF0ICAgICAga2RiX2VudGVyKzB4NTg6IGxkcmIgICAgcjE1LCBbcjE1LCBy MTUsIHJvciByMTVdIQpkYj4gYnQKVHJhY2luZyBwaWQgMTEgdGlkIDEwMDE3NCB0ZCAweGUyOTRl MDAwCmRiX3RyYWNlX3NlbGYoKSBhdCBkYl90cmFjZV9zZWxmCiAgICAgICAgIHBjID0gMHhjMDVj N2YzNCAgbHIgPSAweGMwMDc3NmY0IChkYl9zdGFja190cmFjZSsweDE0MCkKICAgICAgICAgc3Ag PSAweGUyYTBiNzE4ICBmcCA9IDB4ZTJhMGI3MzAKZGJfc3RhY2tfdHJhY2UoKSBhdCBkYl9zdGFj a190cmFjZSsweDE0MAogICAgICAgICBwYyA9IDB4YzAwNzc2ZjQgIGxyID0gMHhjMDA3NzQwNCAo ZGJfY29tbWFuZCsweDM5YykKICAgICAgICAgc3AgPSAweGUyYTBiNzM4ICBmcCA9IDB4ZTJhMGI3 ZDgKICAgICAgICAgcjQgPSAweGMwNzI0NjQ2ICByNSA9IDB4MDAwMDAwMDAKICAgICAgICAgcjYg PSAweGMwYWY5NTVjIHIxMCA9IDB4YzA4YThiYTAKZGJfY29tbWFuZCgpIGF0IGRiX2NvbW1hbmQr MHgzOWMKICAgICAgICAgcGMgPSAweGMwMDc3NDA0ICBsciA9IDB4YzAwNzcwNDAgKGRiX2NvbW1h bmRfbG9vcCsweDY0KQogICAgICAgICBzcCA9IDB4ZTJhMGI3ZTAgIGZwID0gMHhlMmEwYjdmMAog ICAgICAgICByNCA9IDB4YzA3ODZkY2QgIHI1ID0gMHhjMDc4NjQ0NQogICAgICAgICByNiA9IDB4 YzA5NWVmNWMgIHI3ID0gMHhjMGFmYjg1OAogICAgICAgICByOCA9IDB4YzBhZmI4MzggIHI5ID0g MHhjMDhhOGYzOAogICAgICAgIHIxMCA9IDB4YzA5Mzg3NzgKZGJfY29tbWFuZF9sb29wKCkgYXQg ZGJfY29tbWFuZF9sb29wKzB4NjQKICAgICAgICAgcGMgPSAweGMwMDc3MDQwICBsciA9IDB4YzAw N2FkY2MgKGRiX3RyYXArMHgxMjgpCiAgICAgICAgIHNwID0gMHhlMmEwYjdmOCAgZnAgPSAweGUy YTBiOTEwCiAgICAgICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAweGMwOTVlZjUwCiAgICAgICAg IHI2ID0gMHhlMmEwYjk0OCByMTAgPSAweGMwOTM4Nzc4CmRiX3RyYXAoKSBhdCBkYl90cmFwKzB4 MTI4CiAgICAgICAgIHBjID0gMHhjMDA3YWRjYyAgbHIgPSAweGMwMzMyNTQ0IChrZGJfdHJhcCsw eDFiOCkKICAgICAgICAgc3AgPSAweGUyYTBiOTE4ICBmcCA9IDB4ZTJhMGI5NDAKICAgICAgICAg cjQgPSAweDAwMDAwMDAwICByNSA9IDB4MDAwMDAwMDEKICAgICAgICAgcjYgPSAweGUyYTBiOTQ4 ICByNyA9IDB4YzBhZmI4NTgKa2RiX3RyYXAoKSBhdCBrZGJfdHJhcCsweDFiOAogICAgICAgICBw YyA9IDB4YzAzMzI1NDQgIGxyID0gMHhjMDVjYThlMCAoZXhjZXB0aW9uX2V4aXQpCiAgICAgICAg IHNwID0gMHhlMmEwYjk0OCAgZnAgPSAweGUyYTBiOWUwCiAgICAgICAgIHI0ID0gMHg2MDAwMDFk MyAgcjUgPSAweDAwMDAwMDAwCiAgICAgICAgIHI2ID0gMHhjMDc3ZjY3MCAgcjcgPSAweGMwOTBk OTEwCiAgICAgICAgIHI4ID0gMHhlMjk0ZTAwMCAgcjkgPSAweGUyYTBiYTFjCiAgICAgICAgcjEw ID0gMHhjMGFlYmIzMApleGNlcHRpb25fZXhpdCgpIGF0IGV4Y2VwdGlvbl9leGl0CiAgICAgICAg IHBjID0gMHhjMDVjYThlMCAgbHIgPSAweGMwMzMxYWJjIChrZGJfZW50ZXIrMHg0OCkKICAgICAg ICAgc3AgPSAweGUyYTBiOWQ4ICBmcCA9IDB4ZTJhMGI5ZTAKICAgICAgICAgcjAgPSAweGMwYWZi ODQ4ICByMSA9IDB4MDAwMDAwMDAKICAgICAgICAgcjIgPSAweDAwMDAwMDEyICByMyA9IDB4MDAw MDAwMDAKICAgICAgICAgcjQgPSAweGMwNzk4NzA0ICByNSA9IDB4MDAwMDAwMDAKICAgICAgICAg cjYgPSAweGMwNzdmNjcwICByNyA9IDB4YzA5MGQ5MTAKICAgICAgICAgcjggPSAweGUyOTRlMDAw ICByOSA9IDB4ZTJhMGJhMWMKICAgICAgICByMTAgPSAweGMwYWViYjMwIHIxMiA9IDB4MjAwMDAw MDAKa2RiX2VudGVyKCkgYXQga2RiX2VudGVyKzB4NWMKICAgICAgICAgcGMgPSAweGMwMzMxYWQw ICBsciA9IDB4YzAyZTI1ZTggKHZwYW5pYysweDFiYykKICAgICAgICAgc3AgPSAweGUyYTBiOWU4 ICBmcCA9IDB4ZTJhMGJhMDgKICAgICAgICAgcjQgPSAweDAwMDAwMTAwIHIxMCA9IDB4YzBhZWJi MzAKdnBhbmljKCkgYXQgdnBhbmljKzB4MWJjCiAgICAgICAgIHBjID0gMHhjMDJlMjVlOCAgbHIg PSAweGMwMmUyMzRjIChkb2FkdW1wKQogICAgICAgICBzcCA9IDB4ZTJhMGJhMTAgIGZwID0gMHhl MmEwYmExNAogICAgICAgICByNCA9IDB4ZTJhMGJhZjAgIHI1ID0gMHgwMDAwMDAxMwogICAgICAg ICByNiA9IDB4ZTNmMDJhNTYgIHI3ID0gMHgwMDAwMDAwMQogICAgICAgICByOCA9IDB4MDAwMDAw MDEgIHI5ID0gMHhlMjk0ZTAwMAogICAgICAgIHIxMCA9IDB4ZTNmMDJhNTYKZG9hZHVtcCgpIGF0 IGRvYWR1bXAKICAgICAgICAgcGMgPSAweGMwMmUyMzRjICBsciA9IDB4YzA1ZWJhMTggKGFib3J0 X2FsaWduKQogICAgICAgICBzcCA9IDB4ZTJhMGJhMWMgIGZwID0gMHhlMmEwYmE0OAogICAgICAg ICByNCA9IDB4ZTNmMDJhNTYgIHI1ID0gMHhlMmEwYmExNAogICAgICAgICByNiA9IDB4YzAyZTIz NGMgcjEwID0gMHhlMmEwYmExYwphYm9ydF9hbGlnbigpIGF0IGFib3J0X2FsaWduCiAgICAgICAg IHBjID0gMHhjMDVlYmExOCAgbHIgPSAweGMwNWViNTE4IChhYm9ydF9oYW5kbGVyKzB4MzI4KQog ICAgICAgICBzcCA9IDB4ZTJhMGJhNTAgIGZwID0gMHhlMmEwYmFlOAogICAgICAgICByNCA9IDB4 MDAwMDAwMTMgIHI1ID0gMHhlM2YwMmE1NgphYm9ydF9oYW5kbGVyKCkgYXQgYWJvcnRfaGFuZGxl cisweDMyOAogICAgICAgICBwYyA9IDB4YzA1ZWI1MTggIGxyID0gMHhjMDVjYThlMCAoZXhjZXB0 aW9uX2V4aXQpCiAgICAgICAgIHNwID0gMHhlMmEwYmFmMCAgZnAgPSAweGUyYTBiYzEwCiAgICAg ICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAweGUzZjAyYTZhCiAgICAgICAgIHI2ID0gMHhlM2Yw MmE1NiAgcjcgPSAweDAwMDAwMDQ0CiAgICAgICAgIHI4ID0gMHgwMDAwMDA0NCAgcjkgPSAweGMw YWY5NTVjCiAgICAgICAgcjEwID0gMHgwMDAwMDAxNApleGNlcHRpb25fZXhpdCgpIGF0IGV4Y2Vw dGlvbl9leGl0CiAgICAgICAgIHBjID0gMHhjMDVjYThlMCAgbHIgPSAweGMwNDQxODg0IChpcF9p bnB1dCsweGExOCkKICAgICAgICAgc3AgPSAweGUyYTBiYjgwICBmcCA9IDB4ZTJhMGJjMTAKICAg ICAgICAgcjAgPSAweDAwMDAwMDAwICByMSA9IDB4MDAwMDAwMDEKICAgICAgICAgcjIgPSAweDAw MDAwMDAxICByMyA9IDB4MDAwMDBhMGEKICAgICAgICAgcjQgPSAweDAwMDAwMDAwICByNSA9IDB4 ZTNmMDJhNmEKICAgICAgICAgcjYgPSAweGUzZjAyYTU2ICByNyA9IDB4MDAwMDAwNDQKICAgICAg ICAgcjggPSAweDAwMDAwMDQ0ICByOSA9IDB4YzBhZjk1NWMKICAgICAgICByMTAgPSAweDAwMDAw MDE0IHIxMiA9IDB4MDAwMDAwMDAKdWRwX2lucHV0KCkgYXQgdWRwX2lucHV0KzB4MWMwCiAgICAg ICAgIHBjID0gMHhjMDQ3NTkyOCAgbHIgPSAweGMwNDQxODg0IChpcF9pbnB1dCsweGExOCkKICAg ICAgICAgc3AgPSAweGUyYTBiYzE4ICBmcCA9IDB4ZTJhMGJjNTAKICAgICAgICAgcjQgPSAweDAw MDIyZTc1ICByNSA9IDB4MDAwMDAwMDAKICAgICAgICAgcjYgPSAweDAwMDAwMDE0ICByNyA9IDB4 MDAwMDAwZmIKICAgICAgICAgcjggPSAweGMwOTBkOTEwICByOSA9IDB4YzA5NDU3ZmMKICAgICAg ICByMTAgPSAweGUzZjAyYTU2CmlwX2lucHV0KCkgYXQgaXBfaW5wdXQrMHhhMTgKICAgICAgICAg cGMgPSAweGMwNDQxODg0ICBsciA9IDB4YzA0MTQyNmMgKG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgx MDApCiAgICAgICAgIHNwID0gMHhlMmEwYmM1OCAgZnAgPSAweGUyYTBiYzgwCiAgICAgICAgIHI0 ID0gMHgwMDAzYTczYiAgcjUgPSAweGUzZjAyYTAwCiAgICAgICAgIHI2ID0gMHgwMDAwMDAwMCAg cjcgPSAweGMwYjViNGI0CiAgICAgICAgIHI4ID0gMHhlNDQxN2FjMCAgcjkgPSAweDVlNGE2ZjI4 CiAgICAgICAgcjEwID0gMHgwMDAwMDAwOApuZXRpc3JfZGlzcGF0Y2hfc3JjKCkgYXQgbmV0aXNy X2Rpc3BhdGNoX3NyYysweDEwMAogICAgICAgICBwYyA9IDB4YzA0MTQyNmMgIGxyID0gMHhjMDQw YjlhMCAoZXRoZXJfZGVtdXgrMHgxYzgpCiAgICAgICAgIHNwID0gMHhlMmEwYmM4OCAgZnAgPSAw eGUyYTBiY2EwCiAgICAgICAgIHI0ID0gMHhlMzI0NDQwMCAgcjUgPSAweGUzZjAyYTAwCiAgICAg ICAgIHI2ID0gMHgwMDAwMDgwMCAgcjcgPSAweGUzMjQ0NDAwCiAgICAgICAgIHI4ID0gMHhlNDQx N2FjMCAgcjkgPSAweDVlNGE2ZjI4CiAgICAgICAgcjEwID0gMHgwMDAwMDAwOApldGhlcl9kZW11 eCgpIGF0IGV0aGVyX2RlbXV4KzB4MWM4CiAgICAgICAgIHBjID0gMHhjMDQwYjlhMCAgbHIgPSAw eGMwNDBkMjJjIChldGhlcl9uaF9pbnB1dCsweDUxNCkKICAgICAgICAgc3AgPSAweGUyYTBiY2E4 ICBmcCA9IDB4ZTJhMGJkMTAKICAgICAgICAgcjQgPSAweGUzMjQ0NDAwICByNSA9IDB4ZTNmMDJh MDAKICAgICAgICAgcjYgPSAweGUzZjAyYTQ4ICByNyA9IDB4MDAwMDAwMDAKZXRoZXJfbmhfaW5w dXQoKSBhdCBldGhlcl9uaF9pbnB1dCsweDUxNAogICAgICAgICBwYyA9IDB4YzA0MGQyMmMgIGxy ID0gMHhjMDQxNDI2YyAobmV0aXNyX2Rpc3BhdGNoX3NyYysweDEwMCkKICAgICAgICAgc3AgPSAw eGUyYTBiZDE4ICBmcCA9IDB4ZTJhMGJkNDAKICAgICAgICAgcjQgPSAweDAwMDUwZTg4ICByNSA9 IDB4ZTNmMDJhMDAKICAgICAgICAgcjYgPSAweDAwMDAwMDAwICByNyA9IDB4YzBiNWI1MzQKICAg ICAgICAgcjggPSAweDVlNGE2ZjI4ICByOSA9IDB4MDAwMDAwMjAKICAgICAgICByMTAgPSAweDAw MDAwMDAwCm5ldGlzcl9kaXNwYXRjaF9zcmMoKSBhdCBuZXRpc3JfZGlzcGF0Y2hfc3JjKzB4MTAw CiAgICAgICAgIHBjID0gMHhjMDQxNDI2YyAgbHIgPSAweGMwNDBiZTk0IChldGhlcl9pbnB1dCsw eDhjKQogICAgICAgICBzcCA9IDB4ZTJhMGJkNDggIGZwID0gMHhlMmEwYmQ4MAogICAgICAgICBy NCA9IDB4ZTMyNDQ0MDAgIHI1ID0gMHgwMDAwMDAwMAogICAgICAgICByNiA9IDB4ZTNmMDJhMDAg IHI3ID0gMHgwMDAwMDAwMAogICAgICAgICByOCA9IDB4NWU0YTZmMjggIHI5ID0gMHgwMDAwMDAy MAogICAgICAgIHIxMCA9IDB4MDAwMDAwMDAKZXRoZXJfaW5wdXQoKSBhdCBldGhlcl9pbnB1dCsw eDhjCiAgICAgICAgIHBjID0gMHhjMDQwYmU5NCAgbHIgPSAweGUyZmQ4MTMwICgkYS44KzB4MTI4 KQogICAgICAgICBzcCA9IDB4ZTJhMGJkODggIGZwID0gMHhlMmEwYmRiOAogICAgICAgICByNCA9 IDB4YzU3ZjVjOGMgIHI1ID0gMHgwMDAwMDAwMAogICAgICAgICByNiA9IDB4ZTMyNDQ0MDAgIHI3 ID0gMHhjNTdmNWM4MAogICAgICAgICByOCA9IDB4ZTJmZTkxNzAgIHI5ID0gMHhjMDkzODMyOAog ICAgICAgIHIxMCA9IDB4ZTJhMGJkODgKJGEuOCgpIGF0ICRhLjgrMHgxMjgKICAgICAgICAgcGMg PSAweGUyZmQ4MTMwICBsciA9IDB4YzAyYTFlZTAgKGl0aHJlYWRfbG9vcCsweDI2OCkKICAgICAg ICAgc3AgPSAweGUyYTBiZGMwICBmcCA9IDB4ZTJhMGJlMjAKICAgICAgICAgcjQgPSAweGRiNzdm NjQwICByNSA9IDB4MDAwMDAwMDAKICAgICAgICAgcjYgPSAweGUzYjNmNTQ0ICByNyA9IDB4ZTNi M2Y1MDAKICAgICAgICAgcjggPSAweGMwNzdjZWM5ICByOSA9IDB4ZTNiM2Y1MDgKICAgICAgICBy MTAgPSAweGRiNzdmNjQwCml0aHJlYWRfbG9vcCgpIGF0IGl0aHJlYWRfbG9vcCsweDI2OAogICAg ICAgICBwYyA9IDB4YzAyYTFlZTAgIGxyID0gMHhjMDI5ZTA4OCAoZm9ya19leGl0KzB4YTApCiAg ICAgICAgIHNwID0gMHhlMmEwYmUyOCAgZnAgPSAweGUyYTBiZTQwCiAgICAgICAgIHI0ID0gMHhl Mjk0ZTAwMCAgcjUgPSAweGQ3OTY3MDAwCiAgICAgICAgIHI2ID0gMHhjMDJhMWM3OCAgcjcgPSAw eGRiNmU4MTIwCiAgICAgICAgIHI4ID0gMHhlMmEwYmU0OCAgcjkgPSAweDAwMDAwMDAwCiAgICAg ICAgcjEwID0gMHgwMDAwMDAwMApmb3JrX2V4aXQoKSBhdCBmb3JrX2V4aXQrMHhhMAogICAgICAg ICBwYyA9IDB4YzAyOWUwODggIGxyID0gMHhjMDVjYTg3MCAoc3dpX2V4aXQpCiAgICAgICAgIHNw ID0gMHhlMmEwYmU0OCAgZnAgPSAweDAwMDAwMDAwCiAgICAgICAgIHI0ID0gMHhjMDJhMWM3OCAg cjUgPSAweGRiNmU4MTIwCiAgICAgICAgIHI2ID0gMHgwMDAwMDAwMCAgcjcgPSAweDAwMDAwMDAw CiAgICAgICAgIHI4ID0gMHgwMDAwMDAwMCByMTAgPSAweDAwMDAwMDAwCnN3aV9leGl0KCkgYXQg c3dpX2V4aXQKICAgICAgICAgcGMgPSAweGMwNWNhODcwICBsciA9IDB4YzA1Y2E4NzAgKHN3aV9l eGl0KQogICAgICAgICBzcCA9IDB4ZTJhMGJlNDggIGZwID0gMHgwMDAwMDAwMA== --b1_vNmHMfWFb6NRKYLFkhix8peAt5pkGQEEyBO3xBMbE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij48ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPkl0J3MgcnVubmluZyAx NC4wLUNVUlJFTlQgYXJtdjcgbWFpbi1uMjUyOTgzLWQyMWU3MWVmY2UzOTxicj48L2Rpdj48ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48 L2Rpdj48cHJlPktlcm5lbCBwYWdlIGZhdWx0IHdpdGggdGhlIGZvbGxvd2luZyBub24tc2xlZXBh YmxlIGxvY2tzIGhlbGQ6DQpleGNsdXNpdmUgc2xlZXAgbXV0ZXggZXBhaXJpZHggKGVwYWlyaWR4 KSByID0gMCAoMHhlMmZlOTE2MCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL25ldC9pZl9lcGFpci5j OjE2NQ0Kc3RhY2sgYmFja3RyYWNlOg0KIzAgMHhjMDM1NThmOCBhdCB3aXRuZXNzX2RlYnVnZ2Vy KzB4N2MNCiMxIDB4YzAzNTZiM2MgYXQgd2l0bmVzc193YXJuKzB4M2ZjDQojMiAweGMwNWViM2M4 IGF0IGFib3J0X2hhbmRsZXIrMHgxZDgNCiMzIDB4YzA1Y2E4ZTAgYXQgZXhjZXB0aW9uX2V4aXQr MA0KIzQgMHhjMDQ3NTkyOCBhdCB1ZHBfaW5wdXQrMHgxYzANCiM1IDB4YzA0NDE4ODQgYXQgaXBf aW5wdXQrMHhhMTgNCiM2IDB4YzA0MTQyNmMgYXQgbmV0aXNyX2Rpc3BhdGNoX3NyYysweDEwMA0K IzcgMHhjMDQwYjlhMCBhdCBldGhlcl9kZW11eCsweDFjOA0KIzggMHhjMDQwZDIyYyBhdCBldGhl cl9uaF9pbnB1dCsweDUxNA0KIzkgMHhjMDQxNDI2YyBhdCBuZXRpc3JfZGlzcGF0Y2hfc3JjKzB4 MTAwDQojMTAgMHhjMDQwYmU5NCBhdCBldGhlcl9pbnB1dCsweDhjDQojMTEgMHhlMmZkODEzMCBh dCAkYS44KzB4MTI4DQojMTIgMHhjMDJhMWVlMCBhdCBpdGhyZWFkX2xvb3ArMHgyNjgNCiMxMyAw eGMwMjllMDg4IGF0IGZvcmtfZXhpdCsweGEwDQojMTQgMHhjMDVjYTg3MCBhdCBzd2lfZXhpdCsw DQpGYXRhbCBrZXJuZWwgbW9kZSBkYXRhIGFib3J0OiAnQWxpZ25tZW50IEZhdWx0JyBvbiByZWFk DQp0cmFwZnJhbWU6IDB4ZTJhMGJhZjANCkZTUj0wMDAwMDAwMSwgRkFSPWUzZjAyYTU2LCBzcHNy PTIwMDAwMDEzDQpyMCA9MDAwMDAwMDAsIHIxID0wMDAwMDAwMSwgcjIgPTAwMDAwMDAxLCByMyA9 MDAwMDBhMGENCnI0ID0wMDAwMDAwMCwgcjUgPWUzZjAyYTZhLCByNiA9ZTNmMDJhNTYsIHI3ID0w MDAwMDA0NA0KcjggPTAwMDAwMDQ0LCByOSA9YzBhZjk1NWMsIHIxMD0wMDAwMDAxNCwgcjExPWUy YTBiYzEwDQpyMTI9MDAwMDAwMDAsIHNzcD1lMmEwYmI4MCwgc2xyPWMwNDQxODg0LCBwYyA9YzA0 NzU5MjgNCg0KcGFuaWM6IEZhdGFsIGFib3J0DQpjcHVpZCA9IDANCnRpbWUgPSAxNjQ1MDA0ODg5 DQpLREI6IHN0YWNrIGJhY2t0cmFjZToNCmRiX3RyYWNlX3NlbGYoKSBhdCBkYl90cmFjZV9zZWxm DQogICAgICAgICBwYyA9IDB4YzA1YzdmMzQgIGxyID0gMHhjMDA3YWM0OCAoZGJfdHJhY2Vfc2Vs Zl93cmFwcGVyKzB4MzApDQogICAgICAgICBzcCA9IDB4ZTJhMGI4YzggIGZwID0gMHhlMmEwYjll MA0KZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJfdHJhY2Vfc2VsZl93cmFwcGVyKzB4MzAN CiAgICAgICAgIHBjID0gMHhjMDA3YWM0OCAgbHIgPSAweGMwMmUyNTljICh2cGFuaWMrMHgxNzAp DQogICAgICAgICBzcCA9IDB4ZTJhMGI5ZTggIGZwID0gMHhlMmEwYmEwOA0KICAgICAgICAgcjQg PSAweDAwMDAwMTAwICByNSA9IDB4MDAwMDAwMDANCiAgICAgICAgIHI2ID0gMHhjMDc3ZjY3MCAg cjcgPSAweGMwOTBkOTEwDQp2cGFuaWMoKSBhdCB2cGFuaWMrMHgxNzANCiAgICAgICAgIHBjID0g MHhjMDJlMjU5YyAgbHIgPSAweGMwMmUyMzRjIChkb2FkdW1wKQ0KICAgICAgICAgc3AgPSAweGUy YTBiYTEwICBmcCA9IDB4ZTJhMGJhMTQNCiAgICAgICAgIHI0ID0gMHhlMmEwYmFmMCAgcjUgPSAw eDAwMDAwMDEzDQogICAgICAgICByNiA9IDB4ZTNmMDJhNTYgIHI3ID0gMHgwMDAwMDAwMQ0KICAg ICAgICAgcjggPSAweDAwMDAwMDAxICByOSA9IDB4ZTI5NGUwMDANCiAgICAgICAgcjEwID0gMHhl M2YwMmE1Ng0KZG9hZHVtcCgpIGF0IGRvYWR1bXANCiAgICAgICAgIHBjID0gMHhjMDJlMjM0YyAg bHIgPSAweGMwNWViYTE4IChhYm9ydF9hbGlnbikNCiAgICAgICAgIHNwID0gMHhlMmEwYmExYyAg ZnAgPSAweGUyYTBiYTQ4DQogICAgICAgICByNCA9IDB4ZTNmMDJhNTYgIHI1ID0gMHhlMmEwYmEx NA0KICAgICAgICAgcjYgPSAweGMwMmUyMzRjIHIxMCA9IDB4ZTJhMGJhMWMNCmFib3J0X2FsaWdu KCkgYXQgYWJvcnRfYWxpZ24NCiAgICAgICAgIHBjID0gMHhjMDVlYmExOCAgbHIgPSAweGMwNWVi NTE4IChhYm9ydF9oYW5kbGVyKzB4MzI4KQ0KICAgICAgICAgc3AgPSAweGUyYTBiYTUwICBmcCA9 IDB4ZTJhMGJhZTgNCiAgICAgICAgIHI0ID0gMHgwMDAwMDAxMyAgcjUgPSAweGUzZjAyYTU2DQph Ym9ydF9oYW5kbGVyKCkgYXQgYWJvcnRfaGFuZGxlcisweDMyOA0KICAgICAgICAgcGMgPSAweGMw NWViNTE4ICBsciA9IDB4YzA1Y2E4ZTAgKGV4Y2VwdGlvbl9leGl0KQ0KICAgICAgICAgc3AgPSAw eGUyYTBiYWYwICBmcCA9IDB4ZTJhMGJjMTANCiAgICAgICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUg PSAweGUzZjAyYTZhDQogICAgICAgICByNiA9IDB4ZTNmMDJhNTYgIHI3ID0gMHgwMDAwMDA0NA0K ICAgICAgICAgcjggPSAweDAwMDAwMDQ0ICByOSA9IDB4YzBhZjk1NWMNCiAgICAgICAgcjEwID0g MHgwMDAwMDAxNA0KZXhjZXB0aW9uX2V4aXQoKSBhdCBleGNlcHRpb25fZXhpdA0KICAgICAgICAg cGMgPSAweGMwNWNhOGUwICBsciA9IDB4YzA0NDE4ODQgKGlwX2lucHV0KzB4YTE4KQ0KICAgICAg ICAgc3AgPSAweGUyYTBiYjgwICBmcCA9IDB4ZTJhMGJjMTANCiAgICAgICAgIHIwID0gMHgwMDAw MDAwMCAgcjEgPSAweDAwMDAwMDAxDQogICAgICAgICByMiA9IDB4MDAwMDAwMDEgIHIzID0gMHgw MDAwMGEwYQ0KICAgICAgICAgcjQgPSAweDAwMDAwMDAwICByNSA9IDB4ZTNmMDJhNmENCiAgICAg ICAgIHI2ID0gMHhlM2YwMmE1NiAgcjcgPSAweDAwMDAwMDQ0DQogICAgICAgICByOCA9IDB4MDAw MDAwNDQgIHI5ID0gMHhjMGFmOTU1Yw0KICAgICAgICByMTAgPSAweDAwMDAwMDE0IHIxMiA9IDB4 MDAwMDAwMDANCnVkcF9pbnB1dCgpIGF0IHVkcF9pbnB1dCsweDFjMA0KICAgICAgICAgcGMgPSAw eGMwNDc1OTI4ICBsciA9IDB4YzA0NDE4ODQgKGlwX2lucHV0KzB4YTE4KQ0KICAgICAgICAgc3Ag PSAweGUyYTBiYzE4ICBmcCA9IDB4ZTJhMGJjNTANCiAgICAgICAgIHI0ID0gMHgwMDAyMmU3NSAg cjUgPSAweDAwMDAwMDAwDQogICAgICAgICByNiA9IDB4MDAwMDAwMTQgIHI3ID0gMHgwMDAwMDBm Yg0KICAgICAgICAgcjggPSAweGMwOTBkOTEwICByOSA9IDB4YzA5NDU3ZmMNCiAgICAgICAgcjEw ID0gMHhlM2YwMmE1Ng0KaXBfaW5wdXQoKSBhdCBpcF9pbnB1dCsweGExOA0KICAgICAgICAgcGMg PSAweGMwNDQxODg0ICBsciA9IDB4YzA0MTQyNmMgKG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDAp DQogICAgICAgICBzcCA9IDB4ZTJhMGJjNTggIGZwID0gMHhlMmEwYmM4MA0KICAgICAgICAgcjQg PSAweDAwMDNhNzNiICByNSA9IDB4ZTNmMDJhMDANCiAgICAgICAgIHI2ID0gMHgwMDAwMDAwMCAg cjcgPSAweGMwYjViNGI0DQogICAgICAgICByOCA9IDB4ZTQ0MTdhYzAgIHI5ID0gMHg1ZTRhNmYy OA0KICAgICAgICByMTAgPSAweDAwMDAwMDA4DQpuZXRpc3JfZGlzcGF0Y2hfc3JjKCkgYXQgbmV0 aXNyX2Rpc3BhdGNoX3NyYysweDEwMA0KICAgICAgICAgcGMgPSAweGMwNDE0MjZjICBsciA9IDB4 YzA0MGI5YTAgKGV0aGVyX2RlbXV4KzB4MWM4KQ0KICAgICAgICAgc3AgPSAweGUyYTBiYzg4ICBm cCA9IDB4ZTJhMGJjYTANCiAgICAgICAgIHI0ID0gMHhlMzI0NDQwMCAgcjUgPSAweGUzZjAyYTAw DQogICAgICAgICByNiA9IDB4MDAwMDA4MDAgIHI3ID0gMHhlMzI0NDQwMA0KICAgICAgICAgcjgg PSAweGU0NDE3YWMwICByOSA9IDB4NWU0YTZmMjgNCiAgICAgICAgcjEwID0gMHgwMDAwMDAwOA0K ZXRoZXJfZGVtdXgoKSBhdCBldGhlcl9kZW11eCsweDFjOA0KICAgICAgICAgcGMgPSAweGMwNDBi OWEwICBsciA9IDB4YzA0MGQyMmMgKGV0aGVyX25oX2lucHV0KzB4NTE0KQ0KICAgICAgICAgc3Ag PSAweGUyYTBiY2E4ICBmcCA9IDB4ZTJhMGJkMTANCiAgICAgICAgIHI0ID0gMHhlMzI0NDQwMCAg cjUgPSAweGUzZjAyYTAwDQogICAgICAgICByNiA9IDB4ZTNmMDJhNDggIHI3ID0gMHgwMDAwMDAw MA0KZXRoZXJfbmhfaW5wdXQoKSBhdCBldGhlcl9uaF9pbnB1dCsweDUxNA0KICAgICAgICAgcGMg PSAweGMwNDBkMjJjICBsciA9IDB4YzA0MTQyNmMgKG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDAp DQogICAgICAgICBzcCA9IDB4ZTJhMGJkMTggIGZwID0gMHhlMmEwYmQ0MA0KICAgICAgICAgcjQg PSAweDAwMDUwZTg4ICByNSA9IDB4ZTNmMDJhMDANCiAgICAgICAgIHI2ID0gMHgwMDAwMDAwMCAg cjcgPSAweGMwYjViNTM0DQogICAgICAgICByOCA9IDB4NWU0YTZmMjggIHI5ID0gMHgwMDAwMDAy MA0KICAgICAgICByMTAgPSAweDAwMDAwMDAwDQpuZXRpc3JfZGlzcGF0Y2hfc3JjKCkgYXQgbmV0 aXNyX2Rpc3BhdGNoX3NyYysweDEwMA0KICAgICAgICAgcGMgPSAweGMwNDE0MjZjICBsciA9IDB4 YzA0MGJlOTQgKGV0aGVyX2lucHV0KzB4OGMpDQogICAgICAgICBzcCA9IDB4ZTJhMGJkNDggIGZw ID0gMHhlMmEwYmQ4MA0KICAgICAgICAgcjQgPSAweGUzMjQ0NDAwICByNSA9IDB4MDAwMDAwMDAN CiAgICAgICAgIHI2ID0gMHhlM2YwMmEwMCAgcjcgPSAweDAwMDAwMDAwDQogICAgICAgICByOCA9 IDB4NWU0YTZmMjggIHI5ID0gMHgwMDAwMDAyMA0KICAgICAgICByMTAgPSAweDAwMDAwMDAwDQpl dGhlcl9pbnB1dCgpIGF0IGV0aGVyX2lucHV0KzB4OGMNCiAgICAgICAgIHBjID0gMHhjMDQwYmU5 NCAgbHIgPSAweGUyZmQ4MTMwICgkYS44KzB4MTI4KQ0KICAgICAgICAgc3AgPSAweGUyYTBiZDg4 ICBmcCA9IDB4ZTJhMGJkYjgNCiAgICAgICAgIHI0ID0gMHhjNTdmNWM4YyAgcjUgPSAweDAwMDAw MDAwDQogICAgICAgICByNiA9IDB4ZTMyNDQ0MDAgIHI3ID0gMHhjNTdmNWM4MA0KICAgICAgICAg cjggPSAweGUyZmU5MTcwICByOSA9IDB4YzA5MzgzMjgNCiAgICAgICAgcjEwID0gMHhlMmEwYmQ4 OA0KJGEuOCgpIGF0ICRhLjgrMHgxMjgNCiAgICAgICAgIHBjID0gMHhlMmZkODEzMCAgbHIgPSAw eGMwMmExZWUwIChpdGhyZWFkX2xvb3ArMHgyNjgpDQogICAgICAgICBzcCA9IDB4ZTJhMGJkYzAg IGZwID0gMHhlMmEwYmUyMA0KICAgICAgICAgcjQgPSAweGRiNzdmNjQwICByNSA9IDB4MDAwMDAw MDANCiAgICAgICAgIHI2ID0gMHhlM2IzZjU0NCAgcjcgPSAweGUzYjNmNTAwDQogICAgICAgICBy OCA9IDB4YzA3N2NlYzkgIHI5ID0gMHhlM2IzZjUwOA0KICAgICAgICByMTAgPSAweGRiNzdmNjQw DQppdGhyZWFkX2xvb3AoKSBhdCBpdGhyZWFkX2xvb3ArMHgyNjgNCiAgICAgICAgIHBjID0gMHhj MDJhMWVlMCAgbHIgPSAweGMwMjllMDg4IChmb3JrX2V4aXQrMHhhMCkNCiAgICAgICAgIHNwID0g MHhlMmEwYmUyOCAgZnAgPSAweGUyYTBiZTQwDQogICAgICAgICByNCA9IDB4ZTI5NGUwMDAgIHI1 ID0gMHhkNzk2NzAwMA0KICAgICAgICAgcjYgPSAweGMwMmExYzc4ICByNyA9IDB4ZGI2ZTgxMjAN CiAgICAgICAgIHI4ID0gMHhlMmEwYmU0OCAgcjkgPSAweDAwMDAwMDAwDQogICAgICAgIHIxMCA9 IDB4MDAwMDAwMDANCmZvcmtfZXhpdCgpIGF0IGZvcmtfZXhpdCsweGEwDQogICAgICAgICBwYyA9 IDB4YzAyOWUwODggIGxyID0gMHhjMDVjYTg3MCAoc3dpX2V4aXQpDQogICAgICAgICBzcCA9IDB4 ZTJhMGJlNDggIGZwID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjQgPSAweGMwMmExYzc4ICByNSA9 IDB4ZGI2ZTgxMjANCiAgICAgICAgIHI2ID0gMHgwMDAwMDAwMCAgcjcgPSAweDAwMDAwMDAwDQog ICAgICAgICByOCA9IDB4MDAwMDAwMDAgcjEwID0gMHgwMDAwMDAwMA0Kc3dpX2V4aXQoKSBhdCBz d2lfZXhpdA0KICAgICAgICAgcGMgPSAweGMwNWNhODcwICBsciA9IDB4YzA1Y2E4NzAgKHN3aV9l eGl0KQ0KICAgICAgICAgc3AgPSAweGUyYTBiZTQ4ICBmcCA9IDB4MDAwMDAwMDANCktEQjogZW50 ZXI6IHBhbmljDQpbIHRocmVhZCBwaWQgMTEgdGlkIDEwMDE3NCBdDQpTdG9wcGVkIGF0ICAgICAg a2RiX2VudGVyKzB4NTg6IGxkcmIgICAgcjE1LCBbcjE1LCByMTUsIHJvciByMTVdIQ0KZGImZ3Q7 IGJ0DQpUcmFjaW5nIHBpZCAxMSB0aWQgMTAwMTc0IHRkIDB4ZTI5NGUwMDANCmRiX3RyYWNlX3Nl bGYoKSBhdCBkYl90cmFjZV9zZWxmDQogICAgICAgICBwYyA9IDB4YzA1YzdmMzQgIGxyID0gMHhj MDA3NzZmNCAoZGJfc3RhY2tfdHJhY2UrMHgxNDApDQogICAgICAgICBzcCA9IDB4ZTJhMGI3MTgg IGZwID0gMHhlMmEwYjczMA0KZGJfc3RhY2tfdHJhY2UoKSBhdCBkYl9zdGFja190cmFjZSsweDE0 MA0KICAgICAgICAgcGMgPSAweGMwMDc3NmY0ICBsciA9IDB4YzAwNzc0MDQgKGRiX2NvbW1hbmQr MHgzOWMpDQogICAgICAgICBzcCA9IDB4ZTJhMGI3MzggIGZwID0gMHhlMmEwYjdkOA0KICAgICAg ICAgcjQgPSAweGMwNzI0NjQ2ICByNSA9IDB4MDAwMDAwMDANCiAgICAgICAgIHI2ID0gMHhjMGFm OTU1YyByMTAgPSAweGMwOGE4YmEwDQpkYl9jb21tYW5kKCkgYXQgZGJfY29tbWFuZCsweDM5Yw0K ICAgICAgICAgcGMgPSAweGMwMDc3NDA0ICBsciA9IDB4YzAwNzcwNDAgKGRiX2NvbW1hbmRfbG9v cCsweDY0KQ0KICAgICAgICAgc3AgPSAweGUyYTBiN2UwICBmcCA9IDB4ZTJhMGI3ZjANCiAgICAg ICAgIHI0ID0gMHhjMDc4NmRjZCAgcjUgPSAweGMwNzg2NDQ1DQogICAgICAgICByNiA9IDB4YzA5 NWVmNWMgIHI3ID0gMHhjMGFmYjg1OA0KICAgICAgICAgcjggPSAweGMwYWZiODM4ICByOSA9IDB4 YzA4YThmMzgNCiAgICAgICAgcjEwID0gMHhjMDkzODc3OA0KZGJfY29tbWFuZF9sb29wKCkgYXQg ZGJfY29tbWFuZF9sb29wKzB4NjQNCiAgICAgICAgIHBjID0gMHhjMDA3NzA0MCAgbHIgPSAweGMw MDdhZGNjIChkYl90cmFwKzB4MTI4KQ0KICAgICAgICAgc3AgPSAweGUyYTBiN2Y4ICBmcCA9IDB4 ZTJhMGI5MTANCiAgICAgICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAweGMwOTVlZjUwDQogICAg ICAgICByNiA9IDB4ZTJhMGI5NDggcjEwID0gMHhjMDkzODc3OA0KZGJfdHJhcCgpIGF0IGRiX3Ry YXArMHgxMjgNCiAgICAgICAgIHBjID0gMHhjMDA3YWRjYyAgbHIgPSAweGMwMzMyNTQ0IChrZGJf dHJhcCsweDFiOCkNCiAgICAgICAgIHNwID0gMHhlMmEwYjkxOCAgZnAgPSAweGUyYTBiOTQwDQog ICAgICAgICByNCA9IDB4MDAwMDAwMDAgIHI1ID0gMHgwMDAwMDAwMQ0KICAgICAgICAgcjYgPSAw eGUyYTBiOTQ4ICByNyA9IDB4YzBhZmI4NTgNCmtkYl90cmFwKCkgYXQga2RiX3RyYXArMHgxYjgN CiAgICAgICAgIHBjID0gMHhjMDMzMjU0NCAgbHIgPSAweGMwNWNhOGUwIChleGNlcHRpb25fZXhp dCkNCiAgICAgICAgIHNwID0gMHhlMmEwYjk0OCAgZnAgPSAweGUyYTBiOWUwDQogICAgICAgICBy NCA9IDB4NjAwMDAxZDMgIHI1ID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjYgPSAweGMwNzdmNjcw ICByNyA9IDB4YzA5MGQ5MTANCiAgICAgICAgIHI4ID0gMHhlMjk0ZTAwMCAgcjkgPSAweGUyYTBi YTFjDQogICAgICAgIHIxMCA9IDB4YzBhZWJiMzANCmV4Y2VwdGlvbl9leGl0KCkgYXQgZXhjZXB0 aW9uX2V4aXQNCiAgICAgICAgIHBjID0gMHhjMDVjYThlMCAgbHIgPSAweGMwMzMxYWJjIChrZGJf ZW50ZXIrMHg0OCkNCiAgICAgICAgIHNwID0gMHhlMmEwYjlkOCAgZnAgPSAweGUyYTBiOWUwDQog ICAgICAgICByMCA9IDB4YzBhZmI4NDggIHIxID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjIgPSAw eDAwMDAwMDEyICByMyA9IDB4MDAwMDAwMDANCiAgICAgICAgIHI0ID0gMHhjMDc5ODcwNCAgcjUg PSAweDAwMDAwMDAwDQogICAgICAgICByNiA9IDB4YzA3N2Y2NzAgIHI3ID0gMHhjMDkwZDkxMA0K ICAgICAgICAgcjggPSAweGUyOTRlMDAwICByOSA9IDB4ZTJhMGJhMWMNCiAgICAgICAgcjEwID0g MHhjMGFlYmIzMCByMTIgPSAweDIwMDAwMDAwDQprZGJfZW50ZXIoKSBhdCBrZGJfZW50ZXIrMHg1 Yw0KICAgICAgICAgcGMgPSAweGMwMzMxYWQwICBsciA9IDB4YzAyZTI1ZTggKHZwYW5pYysweDFi YykNCiAgICAgICAgIHNwID0gMHhlMmEwYjllOCAgZnAgPSAweGUyYTBiYTA4DQogICAgICAgICBy NCA9IDB4MDAwMDAxMDAgcjEwID0gMHhjMGFlYmIzMA0KdnBhbmljKCkgYXQgdnBhbmljKzB4MWJj DQogICAgICAgICBwYyA9IDB4YzAyZTI1ZTggIGxyID0gMHhjMDJlMjM0YyAoZG9hZHVtcCkNCiAg ICAgICAgIHNwID0gMHhlMmEwYmExMCAgZnAgPSAweGUyYTBiYTE0DQogICAgICAgICByNCA9IDB4 ZTJhMGJhZjAgIHI1ID0gMHgwMDAwMDAxMw0KICAgICAgICAgcjYgPSAweGUzZjAyYTU2ICByNyA9 IDB4MDAwMDAwMDENCiAgICAgICAgIHI4ID0gMHgwMDAwMDAwMSAgcjkgPSAweGUyOTRlMDAwDQog ICAgICAgIHIxMCA9IDB4ZTNmMDJhNTYNCmRvYWR1bXAoKSBhdCBkb2FkdW1wDQogICAgICAgICBw YyA9IDB4YzAyZTIzNGMgIGxyID0gMHhjMDVlYmExOCAoYWJvcnRfYWxpZ24pDQogICAgICAgICBz cCA9IDB4ZTJhMGJhMWMgIGZwID0gMHhlMmEwYmE0OA0KICAgICAgICAgcjQgPSAweGUzZjAyYTU2 ICByNSA9IDB4ZTJhMGJhMTQNCiAgICAgICAgIHI2ID0gMHhjMDJlMjM0YyByMTAgPSAweGUyYTBi YTFjDQphYm9ydF9hbGlnbigpIGF0IGFib3J0X2FsaWduDQogICAgICAgICBwYyA9IDB4YzA1ZWJh MTggIGxyID0gMHhjMDVlYjUxOCAoYWJvcnRfaGFuZGxlcisweDMyOCkNCiAgICAgICAgIHNwID0g MHhlMmEwYmE1MCAgZnAgPSAweGUyYTBiYWU4DQogICAgICAgICByNCA9IDB4MDAwMDAwMTMgIHI1 ID0gMHhlM2YwMmE1Ng0KYWJvcnRfaGFuZGxlcigpIGF0IGFib3J0X2hhbmRsZXIrMHgzMjgNCiAg ICAgICAgIHBjID0gMHhjMDVlYjUxOCAgbHIgPSAweGMwNWNhOGUwIChleGNlcHRpb25fZXhpdCkN CiAgICAgICAgIHNwID0gMHhlMmEwYmFmMCAgZnAgPSAweGUyYTBiYzEwDQogICAgICAgICByNCA9 IDB4MDAwMDAwMDAgIHI1ID0gMHhlM2YwMmE2YQ0KICAgICAgICAgcjYgPSAweGUzZjAyYTU2ICBy NyA9IDB4MDAwMDAwNDQNCiAgICAgICAgIHI4ID0gMHgwMDAwMDA0NCAgcjkgPSAweGMwYWY5NTVj DQogICAgICAgIHIxMCA9IDB4MDAwMDAwMTQNCmV4Y2VwdGlvbl9leGl0KCkgYXQgZXhjZXB0aW9u X2V4aXQNCiAgICAgICAgIHBjID0gMHhjMDVjYThlMCAgbHIgPSAweGMwNDQxODg0IChpcF9pbnB1 dCsweGExOCkNCiAgICAgICAgIHNwID0gMHhlMmEwYmI4MCAgZnAgPSAweGUyYTBiYzEwDQogICAg ICAgICByMCA9IDB4MDAwMDAwMDAgIHIxID0gMHgwMDAwMDAwMQ0KICAgICAgICAgcjIgPSAweDAw MDAwMDAxICByMyA9IDB4MDAwMDBhMGENCiAgICAgICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAw eGUzZjAyYTZhDQogICAgICAgICByNiA9IDB4ZTNmMDJhNTYgIHI3ID0gMHgwMDAwMDA0NA0KICAg ICAgICAgcjggPSAweDAwMDAwMDQ0ICByOSA9IDB4YzBhZjk1NWMNCiAgICAgICAgcjEwID0gMHgw MDAwMDAxNCByMTIgPSAweDAwMDAwMDAwDQp1ZHBfaW5wdXQoKSBhdCB1ZHBfaW5wdXQrMHgxYzAN CiAgICAgICAgIHBjID0gMHhjMDQ3NTkyOCAgbHIgPSAweGMwNDQxODg0IChpcF9pbnB1dCsweGEx OCkNCiAgICAgICAgIHNwID0gMHhlMmEwYmMxOCAgZnAgPSAweGUyYTBiYzUwDQogICAgICAgICBy NCA9IDB4MDAwMjJlNzUgIHI1ID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjYgPSAweDAwMDAwMDE0 ICByNyA9IDB4MDAwMDAwZmINCiAgICAgICAgIHI4ID0gMHhjMDkwZDkxMCAgcjkgPSAweGMwOTQ1 N2ZjDQogICAgICAgIHIxMCA9IDB4ZTNmMDJhNTYNCmlwX2lucHV0KCkgYXQgaXBfaW5wdXQrMHhh MTgNCiAgICAgICAgIHBjID0gMHhjMDQ0MTg4NCAgbHIgPSAweGMwNDE0MjZjIChuZXRpc3JfZGlz cGF0Y2hfc3JjKzB4MTAwKQ0KICAgICAgICAgc3AgPSAweGUyYTBiYzU4ICBmcCA9IDB4ZTJhMGJj ODANCiAgICAgICAgIHI0ID0gMHgwMDAzYTczYiAgcjUgPSAweGUzZjAyYTAwDQogICAgICAgICBy NiA9IDB4MDAwMDAwMDAgIHI3ID0gMHhjMGI1YjRiNA0KICAgICAgICAgcjggPSAweGU0NDE3YWMw ICByOSA9IDB4NWU0YTZmMjgNCiAgICAgICAgcjEwID0gMHgwMDAwMDAwOA0KbmV0aXNyX2Rpc3Bh dGNoX3NyYygpIGF0IG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDANCiAgICAgICAgIHBjID0gMHhj MDQxNDI2YyAgbHIgPSAweGMwNDBiOWEwIChldGhlcl9kZW11eCsweDFjOCkNCiAgICAgICAgIHNw ID0gMHhlMmEwYmM4OCAgZnAgPSAweGUyYTBiY2EwDQogICAgICAgICByNCA9IDB4ZTMyNDQ0MDAg IHI1ID0gMHhlM2YwMmEwMA0KICAgICAgICAgcjYgPSAweDAwMDAwODAwICByNyA9IDB4ZTMyNDQ0 MDANCiAgICAgICAgIHI4ID0gMHhlNDQxN2FjMCAgcjkgPSAweDVlNGE2ZjI4DQogICAgICAgIHIx MCA9IDB4MDAwMDAwMDgNCmV0aGVyX2RlbXV4KCkgYXQgZXRoZXJfZGVtdXgrMHgxYzgNCiAgICAg ICAgIHBjID0gMHhjMDQwYjlhMCAgbHIgPSAweGMwNDBkMjJjIChldGhlcl9uaF9pbnB1dCsweDUx NCkNCiAgICAgICAgIHNwID0gMHhlMmEwYmNhOCAgZnAgPSAweGUyYTBiZDEwDQogICAgICAgICBy NCA9IDB4ZTMyNDQ0MDAgIHI1ID0gMHhlM2YwMmEwMA0KICAgICAgICAgcjYgPSAweGUzZjAyYTQ4 ICByNyA9IDB4MDAwMDAwMDANCmV0aGVyX25oX2lucHV0KCkgYXQgZXRoZXJfbmhfaW5wdXQrMHg1 MTQNCiAgICAgICAgIHBjID0gMHhjMDQwZDIyYyAgbHIgPSAweGMwNDE0MjZjIChuZXRpc3JfZGlz cGF0Y2hfc3JjKzB4MTAwKQ0KICAgICAgICAgc3AgPSAweGUyYTBiZDE4ICBmcCA9IDB4ZTJhMGJk NDANCiAgICAgICAgIHI0ID0gMHgwMDA1MGU4OCAgcjUgPSAweGUzZjAyYTAwDQogICAgICAgICBy NiA9IDB4MDAwMDAwMDAgIHI3ID0gMHhjMGI1YjUzNA0KICAgICAgICAgcjggPSAweDVlNGE2ZjI4 ICByOSA9IDB4MDAwMDAwMjANCiAgICAgICAgcjEwID0gMHgwMDAwMDAwMA0KbmV0aXNyX2Rpc3Bh dGNoX3NyYygpIGF0IG5ldGlzcl9kaXNwYXRjaF9zcmMrMHgxMDANCiAgICAgICAgIHBjID0gMHhj MDQxNDI2YyAgbHIgPSAweGMwNDBiZTk0IChldGhlcl9pbnB1dCsweDhjKQ0KICAgICAgICAgc3Ag PSAweGUyYTBiZDQ4ICBmcCA9IDB4ZTJhMGJkODANCiAgICAgICAgIHI0ID0gMHhlMzI0NDQwMCAg cjUgPSAweDAwMDAwMDAwDQogICAgICAgICByNiA9IDB4ZTNmMDJhMDAgIHI3ID0gMHgwMDAwMDAw MA0KICAgICAgICAgcjggPSAweDVlNGE2ZjI4ICByOSA9IDB4MDAwMDAwMjANCiAgICAgICAgcjEw ID0gMHgwMDAwMDAwMA0KZXRoZXJfaW5wdXQoKSBhdCBldGhlcl9pbnB1dCsweDhjDQogICAgICAg ICBwYyA9IDB4YzA0MGJlOTQgIGxyID0gMHhlMmZkODEzMCAoJGEuOCsweDEyOCkNCiAgICAgICAg IHNwID0gMHhlMmEwYmQ4OCAgZnAgPSAweGUyYTBiZGI4DQogICAgICAgICByNCA9IDB4YzU3ZjVj OGMgIHI1ID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjYgPSAweGUzMjQ0NDAwICByNyA9IDB4YzU3 ZjVjODANCiAgICAgICAgIHI4ID0gMHhlMmZlOTE3MCAgcjkgPSAweGMwOTM4MzI4DQogICAgICAg IHIxMCA9IDB4ZTJhMGJkODgNCiRhLjgoKSBhdCAkYS44KzB4MTI4DQogICAgICAgICBwYyA9IDB4 ZTJmZDgxMzAgIGxyID0gMHhjMDJhMWVlMCAoaXRocmVhZF9sb29wKzB4MjY4KQ0KICAgICAgICAg c3AgPSAweGUyYTBiZGMwICBmcCA9IDB4ZTJhMGJlMjANCiAgICAgICAgIHI0ID0gMHhkYjc3ZjY0 MCAgcjUgPSAweDAwMDAwMDAwDQogICAgICAgICByNiA9IDB4ZTNiM2Y1NDQgIHI3ID0gMHhlM2Iz ZjUwMA0KICAgICAgICAgcjggPSAweGMwNzdjZWM5ICByOSA9IDB4ZTNiM2Y1MDgNCiAgICAgICAg cjEwID0gMHhkYjc3ZjY0MA0KaXRocmVhZF9sb29wKCkgYXQgaXRocmVhZF9sb29wKzB4MjY4DQog ICAgICAgICBwYyA9IDB4YzAyYTFlZTAgIGxyID0gMHhjMDI5ZTA4OCAoZm9ya19leGl0KzB4YTAp DQogICAgICAgICBzcCA9IDB4ZTJhMGJlMjggIGZwID0gMHhlMmEwYmU0MA0KICAgICAgICAgcjQg PSAweGUyOTRlMDAwICByNSA9IDB4ZDc5NjcwMDANCiAgICAgICAgIHI2ID0gMHhjMDJhMWM3OCAg cjcgPSAweGRiNmU4MTIwDQogICAgICAgICByOCA9IDB4ZTJhMGJlNDggIHI5ID0gMHgwMDAwMDAw MA0KICAgICAgICByMTAgPSAweDAwMDAwMDAwDQpmb3JrX2V4aXQoKSBhdCBmb3JrX2V4aXQrMHhh MA0KICAgICAgICAgcGMgPSAweGMwMjllMDg4ICBsciA9IDB4YzA1Y2E4NzAgKHN3aV9leGl0KQ0K ICAgICAgICAgc3AgPSAweGUyYTBiZTQ4ICBmcCA9IDB4MDAwMDAwMDANCiAgICAgICAgIHI0ID0g MHhjMDJhMWM3OCAgcjUgPSAweGRiNmU4MTIwDQogICAgICAgICByNiA9IDB4MDAwMDAwMDAgIHI3 ID0gMHgwMDAwMDAwMA0KICAgICAgICAgcjggPSAweDAwMDAwMDAwIHIxMCA9IDB4MDAwMDAwMDAN CnN3aV9leGl0KCkgYXQgc3dpX2V4aXQNCiAgICAgICAgIHBjID0gMHhjMDVjYTg3MCAgbHIgPSAw eGMwNWNhODcwIChzd2lfZXhpdCkNCiAgICAgICAgIHNwID0gMHhlMmEwYmU0OCAgZnAgPSAweDAw MDAwMDAwDQo8YnI+PC9wcmU+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNp emU6IDE0cHg7Ij48YnI+PC9kaXY+ --b1_vNmHMfWFb6NRKYLFkhix8peAt5pkGQEEyBO3xBMbE-- From nobody Wed Feb 16 10:57:56 2022 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 0F32F1951644; Wed, 16 Feb 2022 10:58:01 +0000 (UTC) (envelope-from kp@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JzFL075VYz4t2l; Wed, 16 Feb 2022 10:58:00 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1645009081; 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=v5vAakIgF4myeqYFpyl2xyoA1v/5efj3P4NZvZCVgso=; b=YpCbdJ7UF9BBJPFpbGB6eNNKdn0NhQ2PHUoMHykU1TGc0rYmq5GDQsjR9izhbVGEeVra63 CV3y4RKYm26J9p5FDChQ1HMfCo3B4SLfkcmh5hMWnUtDBmb72JIzWn4K/ZT134p8qnkjvv onui9KIfmijae3Qm3gk+CzR+rDDC1HxaNwOyjK7XvSCT5Eb9AsKYbqfY3Dz+TRv56GWRFm tId9FgVKXK/3+fK/tRgzuQjvdr9mlxYmuRzNS7gd23jzwgxPfcwuAHwXbTETAFidNN3PuX M63OiOjHObZQcwllrGohE86cCc4/ZyQY2Zt85cvr4jOOcXdxbieSZPJZ3nw0kg== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id BA7436B58; Wed, 16 Feb 2022 10:58:00 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 814233E215; Wed, 16 Feb 2022 11:57:57 +0100 (CET) From: Kristof Provost To: qroxana Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Kernel panic for if_epair Date: Wed, 16 Feb 2022 11:57:56 +0100 X-Mailer: MailMate (1.14r5852) Message-ID: In-Reply-To: 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=UTF-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1645009081; 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=v5vAakIgF4myeqYFpyl2xyoA1v/5efj3P4NZvZCVgso=; b=yZUoFJahAm15WUho5MtbuX9JIARxeciHYMlCr3WzrUlXGAuIQnsBuVtX0MynHF8SxPjDTa Hv28SrMtj4Mo9V5huHsBknNY2XuLbqtykzZumHLjnkut5zhV2wWuJvKCYKIKeS1lXTWQkW lemGKt4Wf3zbVQo6/tfFwITc+H9F6Jd4X1q4I/qSZRCSPpyU4OBmkzQIbx+BIZyd3p8FLU 3T+Vk+UDBdtM+dls6BO53Hm78Q4uI8gqODEoHvUrhYUEyLjR+py+zvJ4PrUassvaeveXGj ylX9YuV35/kOQq/jH21h92cSWHWX3W1W3ztiCH4SH8sMkDhlMEkPNRGzUb4KLg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645009081; a=rsa-sha256; cv=none; b=RTko03DgcKrCD4ohKSRTcyhbLlI9HHmiSZOjTUA5t/bwLi0gd+/umDBEVLWzJl8WYWmjM2 jvsTJtEeAxlgn2TM7KzwbUvX8OXE6dASrNpui9nMD6cIFTQ9Tl10FSveTLJX5MrHUp2U5H BxEzXerqNHT4Hh8xUQm4Yo9i/jTzo2n4NQZtODkUDI34Cz0k8geISXoC53o6Aukystc2VO Kjq//6/SRTvHu5SKxp1J594M+2bOc1Udpjao3K6JQSTf2ZS3PCNgRKA2Rq2YxqhBjMsHMz rcxAcenYHHzodkwRhWR/SRd3LoEAi3QXvTiJzD7FEZRzbnH1cwKDZoSUcJ9FAA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 16 Feb 2022, at 11:31, qroxana wrote: > It's running 14.0-CURRENT armv7 main-n252983-d21e71efce39 > > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex epairidx (epairidx) r =3D 0 (0xe2fe9160) locked @= /usr/src/sys/net/if_epair.c:165 > stack backtrace: > #0 0xc03558f8 at witness_debugger+0x7c > #1 0xc0356b3c at witness_warn+0x3fc > #2 0xc05eb3c8 at abort_handler+0x1d8 > #3 0xc05ca8e0 at exception_exit+0 > #4 0xc0475928 at udp_input+0x1c0 > #5 0xc0441884 at ip_input+0xa18 > #6 0xc041426c at netisr_dispatch_src+0x100 > #7 0xc040b9a0 at ether_demux+0x1c8 > #8 0xc040d22c at ether_nh_input+0x514 > #9 0xc041426c at netisr_dispatch_src+0x100 > #10 0xc040be94 at ether_input+0x8c > #11 0xe2fd8130 at $a.8+0x128 > #12 0xc02a1ee0 at ithread_loop+0x268 > #13 0xc029e088 at fork_exit+0xa0 > #14 0xc05ca870 at swi_exit+0 > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xe2a0baf0 > FSR=3D00000001, FAR=3De3f02a56, spsr=3D20000013 > r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3D00000a0a > r4 =3D00000000, r5 =3De3f02a6a, r6 =3De3f02a56, r7 =3D00000044 > r8 =3D00000044, r9 =3Dc0af955c, r10=3D00000014, r11=3De2a0bc10 > r12=3D00000000, ssp=3De2a0bb80, slr=3Dc0441884, pc =3Dc0475928 > > panic: Fatal abort That backtrace suggests an alignment fault in udp_input(), not an issue w= ith if_epair. There=E2=80=99s not even any mention of if_epair in that backtrace, but I= suppose it=E2=80=99s remotely possible that it=E2=80=99s in epair_intr()= , calling epair_sintr() in #11. That would explain why the epair lock is = held, at least. Note that the epair code has been substantially reworked recently so if y= ou retry with a recent (post 24f0bfbad57b9c3cb9b543a60b2ba00e4812c286) bu= ild you won=E2=80=99t see the epair lock mentioned (assuming you can repr= oduce the panic), but again, it doesn=E2=80=99t look to be involved here = anyway. Kristof From nobody Thu Feb 17 02:31:19 2022 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 9351519DEA30 for ; Thu, 17 Feb 2022 02:31:27 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 4Jzf325FM8z4rc3 for ; Thu, 17 Feb 2022 02:31:26 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.1.14] (c-73-26-2-106.hsd1.nm.comcast.net [73.26.2.106]) (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) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 627561AF4F8 for ; Thu, 17 Feb 2022 02:31:20 +0000 (UTC) Message-ID: Date: Wed, 16 Feb 2022 19:31:19 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Content-Language: en-US To: freebsd-current From: Sean Bruno Subject: USB CD Eject Failures Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Jzf325FM8z4rc3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 199.102.79.106 is neither permitted nor denied by domain of sbruno@freebsd.org) smtp.mailfrom=sbruno@freebsd.org X-Spamd-Result: default: False [0.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[sbruno]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; RECEIVED_SPAMHAUS_PBL(0.00)[73.26.2.106:received]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.91)[0.914]; NEURAL_SPAM_LONG(0.20)[0.197]; NEURAL_HAM_SHORT(-0.98)[-0.976]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:199.102.76.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Been playing around with sysutils/eject to automate some media backup stuff. I note that "after a number of ejects" the USB 2 CD drive will cease responding. I don't think its a race to failure, it acts like resource starvation/leak. Seems fairly reproducible, if someone gets to it before I do, let me know. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261961 I suspect that something has changed in the 12 years since sysutils/eject was last looked at and the CDIOCEJECT case in sys/cam/scsi_cd.c probably needs an eyeball. The close tray command also seems nonfunctional, which probably means that a data structure has changed or something else that I haven't started at in quite some time. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261936 sean From nobody Thu Feb 17 09:11:34 2022 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 78B5919DF3D5 for ; Thu, 17 Feb 2022 09:11:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jzpx94gFWz4RF9; Thu, 17 Feb 2022 09:11:57 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2C649260236; Thu, 17 Feb 2022 10:11:48 +0100 (CET) Message-ID: <665582e5-46f3-b2da-9764-59c4c52cdbd3@selasky.org> Date: Thu, 17 Feb 2022 10:11:34 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: USB CD Eject Failures Content-Language: en-US To: Sean Bruno , freebsd-current References: From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Jzpx94gFWz4RF9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-1.44 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.86)[0.856]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2/17/22 03:31, Sean Bruno wrote: > Been playing around with sysutils/eject to automate some media backup > stuff. > > I note that "after a number of ejects" the USB 2 CD drive will cease > responding.  I don't think its a race to failure, it acts like resource > starvation/leak.  Seems fairly reproducible, if someone gets to it > before I do, let me know. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261961 > > I suspect that something has changed in the 12 years since > sysutils/eject was last looked at and the CDIOCEJECT case in > sys/cam/scsi_cd.c probably needs an eyeball. > > The close tray command also seems nonfunctional, which probably means > that a data structure has changed or something else that I haven't > started at in quite some time. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261936 > Hi, You can trace all USB SCSI commands with "usbdump". --HPS From nobody Fri Feb 18 20:36:27 2022 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 796B619CF61B for ; Fri, 18 Feb 2022 20:36:30 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K0k4Y5zbDz4pgs for ; Fri, 18 Feb 2022 20:36:29 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qv1-xf31.google.com with SMTP id h9so17055671qvm.0 for ; Fri, 18 Feb 2022 12:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=dNeUM1gEv1PhsgUBaAOOYEbZ/K4KDJzt4ggnIRD28Oc=; b=YkcpE45IhDsdlNA9gavfA3i8qVEQ1qXK4+sG+a9VAzx6UX7Q7oEQBwqm8mI1iSBy+Y 35n5KPyv3aM59zYV3pOqkdRllE1qgojcL1yPMaxNpJEcTlNH2x9zR82RaoA0x0g/eG6X Y0v9K/cQ9d61c+XazqL3uT8GfdXlXG/FcnJuxLVnyiInGMMLEThtssVFguimwKKReOzE N7qmOP3e3blY0P1k2BfsnOle+YAyRjRxvcOZkN8SRsXm605wX3m1bAbu5+AvlFdXhqGk h6okBtkIeNp8HxZuZ8JTwIRWM/l9Im0OH2unJJ+4ARCAJVn+uE5eF76LLag6SciH6GUG R7Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=dNeUM1gEv1PhsgUBaAOOYEbZ/K4KDJzt4ggnIRD28Oc=; b=CqdbfjZLLuA/UqHIrOPit0ZpHRqZYdqhQhnRKf4VtOzesa84GEdwo8I+SKDhce0jZm sXE9PrYKtSrLQGXJD28rj1mybf6W/ehhaEbuSidAXiof2EMusWSXICv4Zxh2jv4WRIiQ +CAnCAiwYmz1SXMbZ9HsGKsPvFP8BINNzDGUWrpBC347LFZfpETA8SekyW5bTMrEBFGK lGouuYdLcL6L9w4uZMTUVs9chx9mypwxvbn+3LVTw7MB6J3bdpZWp0pRrS6mxbFUTsA2 nBNIdOFeTdRofwnjIcEPhEpdefhPsk4Gupwf6WtnEdgrU0SfmdeRWdywr9pSLw2Pwu6A n28w== X-Gm-Message-State: AOAM532z042JiYBMmM8MOXn93GYxQ1qH3mrkmWkGb+4F6exAEj3TiVOe WBcZTa2uwhah2rJOKa2tsckpwVqyqVM= X-Google-Smtp-Source: ABdhPJximcn3muLiGumFIgYlyYEXGPRrwdGJjPYBC5banRs01gnU6Sb5+DH3B2KwgB7ClUQVcJx7Lw== X-Received: by 2002:a05:6214:c4e:b0:42c:d5f:7e56 with SMTP id r14-20020a0562140c4e00b0042c0d5f7e56mr7293558qvj.46.1645216589314; Fri, 18 Feb 2022 12:36:29 -0800 (PST) Received: from [10.231.1.66] (075-130-069-034.biz.spectrum.com. [75.130.69.34]) by smtp.gmail.com with ESMTPSA id de15sm21543335qkb.107.2022.02.18.12.36.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Feb 2022 12:36:28 -0800 (PST) Message-ID: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> Date: Fri, 18 Feb 2022 15:36:27 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: [Intel AlderLake]Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Content-Language: en-US To: "Chen, Alvin W" , "freebsd-current@freebsd.org" References: From: Alexander Motin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K0k4Y5zbDz4pgs X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=YkcpE45I; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::f31 as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-1.31 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.89)[0.889]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f31:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This looks pretty weird to me, but I don't think it is specific to the FAT32. Just today I've first noticed that booting TrueNAS 12.0-U8 (http://download.freenas.org/12.0/STABLE/U8/x64/TrueNAS-12.0-U8.iso) (based on FreeBSD 12.2 with many backports) from NVMe SSD (I don't insist on NVMe so far) and ZFS almost never completes successfully, ending up in hangs or random stack corruption panics in ZFS threads as soon as at least one E core is enabled of my i7-12700K. Disabling all E cores fixes the problem. Updated to TrueNAS 13.0-BETA1 (based on FreeBSD 13.0-STABLE from few weeks ago) it does not demonstrate the problem any more. The same TrueNAS 12.0-U8 kernel booted from NFS does not seem to demonstrate the problem with ZFS mounting, but I haven't stressed it much so far. There are seem to be dragons somewhere... On 15.02.2022 22:29, Chen, Alvin W wrote: > Hi Guys, > Any updates to support Intel P-core + E-core? > I have filed a bug: PR 261169 > , but no updates. > Does anybody know the progress? > > For Intel Adler Lake P core + E core processor (i7-12700T), copying > files to FAT32 partition, the file corrupted (50%), but ZFS is fine. > After disabling E core in the code by restrict the max cpu number, this > issue is gone. And No E core processor has no such issue, like i7-12400. > > HW ENV: > CPU: Intel AlderLake 12th Gen i7-12700T > Disk: NVME SSD > > There are 3 methods to reproduce this issue: > 1. Make FreeBSD 13 USB disk installer, install FreeBSD with UFS, and > select install source and ports, the txz package checking will be failed. > > 2. Boot to shell by USB disk installer, and mount a FAT32 partition (on > SSD), and copy a 300MB file to the FAT32, compare the sha256 checksums > for the source file and the dst file, the checksum are different (50%). > Or if there is a 300MB file in FAT32 partition, mount the partition, and > for the first time check the sha256 value by running 'sha256 file.tgz', > the checksum is wrong, but the second time, the checksum is correct. > > 3. Install FreeBSD 13 with ZFS, and it can work well. And boot into > FreeBSD, disable swap, and format the SWAP partition to FAT32. Do the > testing as above. > > Regards, > > Alvin Chen > > Dell | Comercial Client Group > > office +86-10-82862506, fax +86-10-82861554, Dell Lync 8672506 > weike_chen@dell.com > > Internal Use - Confidential > -- Alexander Motin From nobody Fri Feb 18 23:19:53 2022 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 8B0A019CDD26 for ; Fri, 18 Feb 2022 23:20:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K0njM6HGdz3hY6 for ; Fri, 18 Feb 2022 23:20:07 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B9AF6260BC9; Sat, 19 Feb 2022 00:20:04 +0100 (CET) Message-ID: Date: Sat, 19 Feb 2022 00:19:53 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: Patch for patch, but not foreach :-) Content-Language: en-US From: Hans Petter Selasky To: Chris , Michael Gmelin Cc: FreeBSD Current , Shawn Webb References: <12082107-B6CE-4EB3-935A-812FC1966CFA@grem.de> <36f77d67cb2673caf8ce72ec45ce8881@bsdforge.com> <1cbe6ac6-c48b-a59e-dc3d-18cf59ed16aa@selasky.org> In-Reply-To: <1cbe6ac6-c48b-a59e-dc3d-18cf59ed16aa@selasky.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K0njM6HGdz3hY6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.99 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-0.69)[-0.693]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/10/21 15:57, Hans Petter Selasky wrote: > On 5/7/21 11:58 PM, Chris wrote: >> On 2021-05-07 14:10, Michael Gmelin wrote: >>> What about using "."? Or "/" (which would match the muscle memory of >>> "search" in >>> less/more/vi/some browsers)? >> +1 >> I really like that idea. > > Hi, > > Thank you for all the good feedback! > > Based on the input I've got, the differential revision has now been > updated: > > https://reviews.freebsd.org/D30160 > Still looking for feedback on this? Anyone tried it? --HPS From nobody Sat Feb 19 02:55:34 2022 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 BC94119CA4BA for ; Sat, 19 Feb 2022 02:55:51 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K0tVG0bpBz4Yd6; Sat, 19 Feb 2022 02:55:49 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 21J2tY4u094090; Sat, 19 Feb 2022 11:55:34 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 19 Feb 2022 11:55:34 +0900 From: Tomoaki AOKI To: Alexander Motin Cc: "Chen, Alvin W" , "freebsd-current@freebsd.org" Subject: Re: [Intel AlderLake]Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-Id: <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> In-Reply-To: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> References: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.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-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K0tVG0bpBz4Yd6 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [2.07 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; AUTH_NA(1.00)[]; NEURAL_SPAM_LONG(0.06)[0.062]; NEURAL_HAM_MEDIUM(-0.39)[-0.387]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received] X-ThisMailContainsUnwantedMimeParts: N Just a thought, but can it be the reason with timing (e.g., rendezvous within (i)threads, hardware controlls without using hardware timer) problem? On FreeBSD, IIUC, multi processor (multi core) implementation assumes SMP (differs only clock speed) and end up with difference of performance at same clock speed within P-core and E-core, possibly. BTW, how aarch64 guys implement big.Little support to avoid such a case? Or are they simply disable all Little cores and use big only? On Fri, 18 Feb 2022 15:36:27 -0500 Alexander Motin wrote: > This looks pretty weird to me, but I don't think it is specific to the > FAT32. Just today I've first noticed that booting TrueNAS 12.0-U8 > (http://download.freenas.org/12.0/STABLE/U8/x64/TrueNAS-12.0-U8.iso) > (based on FreeBSD 12.2 with many backports) from NVMe SSD (I don't > insist on NVMe so far) and ZFS almost never completes successfully, > ending up in hangs or random stack corruption panics in ZFS threads as > soon as at least one E core is enabled of my i7-12700K. Disabling all E > cores fixes the problem. Updated to TrueNAS 13.0-BETA1 (based on > FreeBSD 13.0-STABLE from few weeks ago) it does not demonstrate the > problem any more. The same TrueNAS 12.0-U8 kernel booted from NFS does > not seem to demonstrate the problem with ZFS mounting, but I haven't > stressed it much so far. > > There are seem to be dragons somewhere... > > On 15.02.2022 22:29, Chen, Alvin W wrote: > > Hi Guys, > > Any updates to support Intel P-core + E-core? > > I have filed a bug: PR 261169 > > , but no updates. > > Does anybody know the progress? > > > > For Intel Adler Lake P core + E core processor (i7-12700T), copying > > files to FAT32 partition, the file corrupted (50%), but ZFS is fine. > > After disabling E core in the code by restrict the max cpu number, this > > issue is gone. And No E core processor has no such issue, like i7-12400. > > > > HW ENV: > > CPU: Intel AlderLake 12th Gen i7-12700T > > Disk: NVME SSD > > > > There are 3 methods to reproduce this issue: > > 1. Make FreeBSD 13 USB disk installer, install FreeBSD with UFS, and > > select install source and ports, the txz package checking will be failed. > > > > 2. Boot to shell by USB disk installer, and mount a FAT32 partition (on > > SSD), and copy a 300MB file to the FAT32, compare the sha256 checksums > > for the source file and the dst file, the checksum are different (50%). > > Or if there is a 300MB file in FAT32 partition, mount the partition, and > > for the first time check the sha256 value by running 'sha256 file.tgz', > > the checksum is wrong, but the second time, the checksum is correct. > > > > 3. Install FreeBSD 13 with ZFS, and it can work well. And boot into > > FreeBSD, disable swap, and format the SWAP partition to FAT32. Do the > > testing as above. > > > > Regards, > > > > Alvin Chen > > > > Dell | Comercial Client Group > > > > office +86-10-82862506, fax +86-10-82861554, Dell Lync 8672506 > > weike_chen@dell.com > > > > Internal Use - Confidential > > > > -- > Alexander Motin > -- $B@DLZ(B $BCNL@(B [Tomoaki AOKI] From nobody Sat Feb 19 17:02:40 2022 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 CAAFE19C7EE2 for ; Sat, 19 Feb 2022 17:03:02 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4K1FHn3Bbgz3ChQ; Sat, 19 Feb 2022 17:03:01 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTP id 21JH2eLS077912; Sat, 19 Feb 2022 11:02:41 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([10.0.1.1]) by mail.karels.net with ESMTPSA id fLCfFLAiEWJWMAEA4+wvSQ (envelope-from ); Sat, 19 Feb 2022 11:02:40 -0600 From: Mike Karels To: Tomoaki AOKI Cc: Alexander Motin , "Chen, Alvin W" , freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Date: Sat, 19 Feb 2022 11:02:40 -0600 X-Mailer: MailMate (1.14r5818) Message-ID: <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> In-Reply-To: <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> References: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> 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-Queue-Id: 4K1FHn3Bbgz3ChQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net X-Spamd-Result: default: False [-3.01 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[karels.net]; NEURAL_HAM_LONG(-0.81)[-0.814]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 18 Feb 2022, at 20:55, Tomoaki AOKI wrote: > Just a thought, but can it be the reason with timing (e.g., rendezvous > within (i)threads, hardware controlls without using hardware timer) > problem? > > On FreeBSD, IIUC, multi processor (multi core) implementation assumes > SMP (differs only clock speed) and end up with difference of > performance at same clock speed within P-core and E-core, possibly. Another possibility is that the system is confused by having hyperthreadi= ng on the P cores but not the E cores. > BTW, how aarch64 guys implement big.Little support to avoid such a case= ? > Or are they simply disable all Little cores and use big only? Are there supported arm64 systems with asymmetric processors yet? Mike > On Fri, 18 Feb 2022 15:36:27 -0500 > Alexander Motin wrote: > >> This looks pretty weird to me, but I don't think it is specific to the= >> FAT32. Just today I've first noticed that booting TrueNAS 12.0-U8 >> (http://download.freenas.org/12.0/STABLE/U8/x64/TrueNAS-12.0-U8.iso) >> (based on FreeBSD 12.2 with many backports) from NVMe SSD (I don't >> insist on NVMe so far) and ZFS almost never completes successfully, >> ending up in hangs or random stack corruption panics in ZFS threads as= >> soon as at least one E core is enabled of my i7-12700K. Disabling all= E >> cores fixes the problem. Updated to TrueNAS 13.0-BETA1 (based on >> FreeBSD 13.0-STABLE from few weeks ago) it does not demonstrate the >> problem any more. The same TrueNAS 12.0-U8 kernel booted from NFS doe= s >> not seem to demonstrate the problem with ZFS mounting, but I haven't >> stressed it much so far. >> >> There are seem to be dragons somewhere... >> >> On 15.02.2022 22:29, Chen, Alvin W wrote: >>> Hi Guys, >>> Any updates to support Intel P-core + E-core? >>> I have filed a bug: PR 261169 >>> , but no= updates. >>> Does anybody know the progress? >>> >>> For Intel Adler Lake P core + E core processor (i7-12700T), copying >>> files to FAT32 partition, the file corrupted (50%), but ZFS is fine. >>> After disabling E core in the code by restrict the max cpu number, th= is >>> issue is gone. And No E core processor has no such issue, like i7-124= 00. >>> >>> HW ENV: >>> CPU: Intel AlderLake 12th Gen i7-12700T >>> Disk: NVME SSD >>> >>> There are 3 methods to reproduce this issue: >>> 1. Make FreeBSD 13 USB disk installer, install FreeBSD with UFS, and >>> select install source and ports, the txz package checking will be fai= led. >>> >>> 2. Boot to shell by USB disk installer, and mount a FAT32 partition (= on >>> SSD), and copy a 300MB file to the FAT32, compare the sha256 checksum= s >>> for the source file and the dst file, the checksum are different (50%= ). >>> Or if there is a 300MB file in FAT32 partition, mount the partition, = and >>> for the first time check the sha256 value by running 'sha256 file.tgz= ', >>> the checksum is wrong, but the second time, the checksum is correct. >>> >>> 3. Install FreeBSD 13 with ZFS, and it can work well. And boot into >>> FreeBSD, disable swap, and format the SWAP partition to FAT32. Do the= >>> testing as above. >>> >>> Regards, >>> >>> Alvin Chen >>> >>> Dell | Comercial Client Group >>> >>> office +86-10-82862506, fax +86-10-82861554, Dell Lync 8672506 >>> weike_chen@dell.com >>> >>> Internal Use - Confidential >>> >> >> -- = >> Alexander Motin >> > > > -- = > =E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E [Tomoaki AOKI] From nobody Sat Feb 19 17:14:16 2022 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 CD5F619CB698 for ; Sat, 19 Feb 2022 17:14:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K1FXw5sFQz3Gg3 for ; Sat, 19 Feb 2022 17:14:24 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qv1-xf31.google.com with SMTP id a19so21306832qvm.4 for ; Sat, 19 Feb 2022 09:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=nqlCg3AEkpmkHEA8DOBI4fYovr3txtISyiH+rHoFLG8=; b=c+dCfxWsXKooEgAEuZD1mpjyF8dSt4QdZnPPfGpDeEXO2BpMGTV1l53tFQm1WXojST UQV6/b1wgzhJPgGtawyVFTB5ycXcLpr9yD2L52izYowDgmQaVXPPaxgxlwssD88gl8Zd p1YrVZnHd8fMZDtY+jlfkfesWxfN+CYOmlB5ABPsQ96eIbfZXz84HRO2p/MsaDPvjwrx DE7vvFmE/E16U4J1dFquE8oY2/5xDE+Ly0OZ0UdHJRtgGaTzAhNWw1fFqjqehKYALP7G MIZXy5RsjWiXr6H+lD+P4xYetSQcxsV70XJ+Hc/TEFxoBL1XO1DF7muAv4MmNsLafHt0 yvGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=nqlCg3AEkpmkHEA8DOBI4fYovr3txtISyiH+rHoFLG8=; b=3rFo4GLHkYm4WI8GPW7nlOoYcEAN2tBPPtKAnf4W6vVu+H7Q7eu0DCVkbYbn9AtCOA MHM66DwV9yfcE67AJPD2s/+kFMP3ZeFegYwDq4re+YGIJviwvrhOQh8fBGkMaYf+ZGBc QLIiN2/aw6K3K3NGrOqoiDPx0uyT4HTGfgLtizaGrK9zp20vSkMD9bC1lSVv0hzD/73k MwGkedG/D1AZK2k56EUdHfrPqlelmFeijqQFz7JWgCtQ9X8aO1Jm4VlRL2CocMpgbXvw aTqJO4juFmYxC0NHwUI6yupMdUlwrOU/HBtEa7vp0ovnhuAIw5WJeyhBWjZDXm/sE1zu toAg== X-Gm-Message-State: AOAM532FGSkOOagXKbyUqOz8OkFunAs/Je9T69J5vlu0g4f8qXA8d2se zzwbVSAN3zHqPvpGL9+/mog= X-Google-Smtp-Source: ABdhPJxdi+nIBkmHCJzOMCVxeEaHt+a5Q/Nrsg1AUxQZlR91uqrcRW5c6Dmol+lOsAUYc4ww+HWpVQ== X-Received: by 2002:a05:622a:1349:b0:2d7:fd8c:4263 with SMTP id w9-20020a05622a134900b002d7fd8c4263mr11677289qtk.556.1645290857959; Sat, 19 Feb 2022 09:14:17 -0800 (PST) Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id x3sm22024513qkp.54.2022.02.19.09.14.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Feb 2022 09:14:17 -0800 (PST) Message-ID: Date: Sat, 19 Feb 2022 12:14:16 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Content-Language: en-US To: Mike Karels , Tomoaki AOKI Cc: "Chen, Alvin W" , freebsd-current@freebsd.org References: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> From: Alexander Motin In-Reply-To: <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K1FXw5sFQz3Gg3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=c+dCfxWs; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::f31 as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-3.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.99)[-0.994]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f31:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 19.02.2022 12:02, Mike Karels wrote: > On 18 Feb 2022, at 20:55, Tomoaki AOKI wrote: >> Just a thought, but can it be the reason with timing (e.g., rendezvous >> within (i)threads, hardware controlls without using hardware timer) >> problem? >> >> On FreeBSD, IIUC, multi processor (multi core) implementation assumes >> SMP (differs only clock speed) and end up with difference of >> performance at same clock speed within P-core and E-core, possibly. > > Another possibility is that the system is confused by having hyperthreading > on the P cores but not the E cores. No, I've tried to disable SMT and different number of cores to make it look identical and uniform for the scheduler. The only thing I could not test is disabling all P cores to test only E, the motherboard does not allow that, requiring at least one P core enabled. >> BTW, how aarch64 guys implement big.Little support to avoid such a case? >> Or are they simply disable all Little cores and use big only? > > Are there supported arm64 systems with asymmetric processors yet? > > Mike > >> On Fri, 18 Feb 2022 15:36:27 -0500 >> Alexander Motin wrote: >> >>> This looks pretty weird to me, but I don't think it is specific to the >>> FAT32. Just today I've first noticed that booting TrueNAS 12.0-U8 >>> (http://download.freenas.org/12.0/STABLE/U8/x64/TrueNAS-12.0-U8.iso) >>> (based on FreeBSD 12.2 with many backports) from NVMe SSD (I don't >>> insist on NVMe so far) and ZFS almost never completes successfully, >>> ending up in hangs or random stack corruption panics in ZFS threads as >>> soon as at least one E core is enabled of my i7-12700K. Disabling all E >>> cores fixes the problem. Updated to TrueNAS 13.0-BETA1 (based on >>> FreeBSD 13.0-STABLE from few weeks ago) it does not demonstrate the >>> problem any more. The same TrueNAS 12.0-U8 kernel booted from NFS does >>> not seem to demonstrate the problem with ZFS mounting, but I haven't >>> stressed it much so far. >>> >>> There are seem to be dragons somewhere... >>> >>> On 15.02.2022 22:29, Chen, Alvin W wrote: >>>> Hi Guys, >>>> Any updates to support Intel P-core + E-core? >>>> I have filed a bug: PR 261169 >>>> , but no updates. >>>> Does anybody know the progress? >>>> >>>> For Intel Adler Lake P core + E core processor (i7-12700T), copying >>>> files to FAT32 partition, the file corrupted (50%), but ZFS is fine. >>>> After disabling E core in the code by restrict the max cpu number, this >>>> issue is gone. And No E core processor has no such issue, like i7-12400. >>>> >>>> HW ENV: >>>> CPU: Intel AlderLake 12th Gen i7-12700T >>>> Disk: NVME SSD >>>> >>>> There are 3 methods to reproduce this issue: >>>> 1. Make FreeBSD 13 USB disk installer, install FreeBSD with UFS, and >>>> select install source and ports, the txz package checking will be failed. >>>> >>>> 2. Boot to shell by USB disk installer, and mount a FAT32 partition (on >>>> SSD), and copy a 300MB file to the FAT32, compare the sha256 checksums >>>> for the source file and the dst file, the checksum are different (50%). >>>> Or if there is a 300MB file in FAT32 partition, mount the partition, and >>>> for the first time check the sha256 value by running 'sha256 file.tgz', >>>> the checksum is wrong, but the second time, the checksum is correct. >>>> >>>> 3. Install FreeBSD 13 with ZFS, and it can work well. And boot into >>>> FreeBSD, disable swap, and format the SWAP partition to FAT32. Do the >>>> testing as above. >>>> >>>> Regards, >>>> >>>> Alvin Chen >>>> >>>> Dell | Comercial Client Group >>>> >>>> office +86-10-82862506, fax +86-10-82861554, Dell Lync 8672506 >>>> weike_chen@dell.com >>>> >>>> Internal Use - Confidential >>>> >>> >>> -- >>> Alexander Motin >>> >> >> >> -- >> é’木 知明 [Tomoaki AOKI] -- Alexander Motin From nobody Sat Feb 19 18:23:41 2022 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 5E30119D6FEA for ; Sat, 19 Feb 2022 18:24:26 +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 4K1H5j3r6Hz3Ntw; Sat, 19 Feb 2022 18:24:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 21JINl8t014184 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 19 Feb 2022 20:23:50 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 21JINfTh014182; Sat, 19 Feb 2022 20:23:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Feb 2022 20:23:41 +0200 From: Konstantin Belousov To: Alexander Motin Cc: Mike Karels , Tomoaki AOKI , "Chen, Alvin W" , freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-ID: References: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> 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=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4K1H5j3r6Hz3Ntw X-Spamd-Bar: + 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 X-Spamd-Result: default: False [1.96 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.33)[0.327]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_SPAM_MEDIUM(0.63)[0.634]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 19, 2022 at 12:14:16PM -0500, Alexander Motin wrote: > On 19.02.2022 12:02, Mike Karels wrote: > > On 18 Feb 2022, at 20:55, Tomoaki AOKI wrote: > > > Just a thought, but can it be the reason with timing (e.g., rendezvous > > > within (i)threads, hardware controlls without using hardware timer) > > > problem? > > > > > > On FreeBSD, IIUC, multi processor (multi core) implementation assumes > > > SMP (differs only clock speed) and end up with difference of > > > performance at same clock speed within P-core and E-core, possibly. > > > > Another possibility is that the system is confused by having hyperthreading > > on the P cores but not the E cores. > > No, I've tried to disable SMT and different number of cores to make it look > identical and uniform for the scheduler. The only thing I could not test is > disabling all P cores to test only E, the motherboard does not allow that, > requiring at least one P core enabled. Does the kernel select MWAIT as the idle method? If you set idle to spin, is anything change? From nobody Sat Feb 19 20:20:58 2022 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 6CA4419C0B1F for ; Sat, 19 Feb 2022 20:21:13 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K1KhS0phkz3qDP; Sat, 19 Feb 2022 20:21:12 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:To:From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=kOBKfar3BtaZVrC4OsmVnT6vCBO6qth7itily/iG/yQ=; b=Roxn5tRkk5MJlDo2uR+cdV/z6Z 9mfZ0dD6P1aFsYTupwZVxmmRWbXdZTjW4T8wyz2HcxfWhGQyK9A34q55u5Duosvt1zRl9/dAUAkvL h+DoXpAdCGGeJO37kavFwdsBFFmyz1oRIQXIVg/Y+FVn8TSaNFYwU1naIG+lqZPjLCiRKWT2hzzZE 1y/rL6JKl4HiMyMzeUOxlTHUoe70IV3jQm8JOP8Dl/eKPezvMivRrt9IkUXiC90IMwv6s/s/NTN/J 0qg0j46nPL9BA7FQkrUWNGtK8CfURUXl5i0wuLLXMTjRtx0KkdDf4WUUojw2DxD9ip25iGiddEkNx uoOzoiRw==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:61180 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nLWDy-00056a-Qm; Sat, 19 Feb 2022 14:20:58 -0600 Received: from 2600:1700:210:b18f:c546:ed3:6648:c04e by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sat, 19 Feb 2022 14:20:58 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Sat, 19 Feb 2022 14:20:58 -0600 From: Larry Rosenman To: Freebsd current , Mark Johnston Subject: Re: Panic, CURRENT, yesterday In-Reply-To: <53727be0434c4c58ae66b8e979aee4f3@lerctr.org> References: <1ae8c6664f33959f69be4d61a8c545f3@lerctr.org> <53727be0434c4c58ae66b8e979aee4f3@lerctr.org> Message-ID: <1fb31da3589a7f96e9bdad33b38934c8@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K1KhS0phkz3qDP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=Roxn5tRk; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02/09/2022 10:08 pm, Larry Rosenman wrote: > Another one today: > ⯠more /var/crash/core.txt.1 > borg.lerctr.org dumped core - see /var/crash/vmcore.1 > > Wed Feb 9 19:30:43 CST 2022 > >> >> core is available, and I can give access and/or send the core and >> kernel/debug stuff. > > True for this one too. Yet another one: ⯠more core.txt.3 borg.lerctr.org dumped core - see /var/crash/vmcore.3 Sat Feb 19 00:42:59 CST 2022 FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #56 ler/freebsd-main-changes-n253181-c140933ef40: Tue Feb 15 12:26:23 CST 2022 root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL amd64 panic: ng_snd_item: 42 != 173 GNU gdb (GDB) 11.2 [GDB v11.2 for FreeBSD] Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel... Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... Unread portion of the kernel message buffer: panic: ng_snd_item: 42 != 173 cpuid = 0 time = 1645251876 KDB: stack backtrace: #0 0xffffffff80516005 at kdb_backtrace+0x65 #1 0xffffffff804cba7f at vpanic+0x17f #2 0xffffffff804cb853 at panic+0x43 #3 0xffffffff82c755b7 at ng_snd_item+0x587 #4 0xffffffff82c8e263 at ng_ether_output+0xb3 #5 0xffffffff805e0e2d at ether_output+0x6cd #6 0xffffffff805f6461 at arpintr+0xd71 #7 0xffffffff805e5797 at netisr_dispatch_src+0x97 #8 0xffffffff805e112e at ether_demux+0x14e #9 0xffffffff82c8e89c at ng_ether_rcv_upper+0x12c #10 0xffffffff82c75dab at ng_apply_item+0x7eb #11 0xffffffff82c7538d at ng_snd_item+0x35d #12 0xffffffff82c75dab at ng_apply_item+0x7eb #13 0xffffffff82c7538d at ng_snd_item+0x35d #14 0xffffffff82c8e33f at ng_ether_input+0x9f #15 0xffffffff805e23e7 at ether_nh_input+0x217 #16 0xffffffff805e5797 at netisr_dispatch_src+0x97 #17 0xffffffff805e159d at ether_input+0x5d Uptime: 2d6h42m17s Dumping 29172 out of 131023 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff804cb68f in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:487 #3 0xffffffff804cbaee in vpanic (fmt=0xffffffff82c7ed98 "%s: %d != %d", ap=) at /usr/src/sys/kern/kern_shutdown.c:920 #4 0xffffffff804cb853 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:844 #5 0xffffffff82c755b7 in ng_snd_item (item=0xfffff8131de0bd80, flags=0) at /usr/src/sys/netgraph/ng_base.c:2256 #6 0xffffffff82c8e263 in ng_ether_output (ifp=, ifp@entry=, mp=0xfffffe025a044868, mp@entry=) at /usr/src/sys/netgraph/ng_ether.c:294 #7 0xffffffff805e0e2d in ether_output (ifp=0xfffff8010cfe0800, m=0xfffff81d2e92b000, dst=, ro=) at /usr/src/sys/net/if_ethersubr.c:427 #8 0xffffffff805f6461 in in_arpinput (m=0xfffff81d2e92b000) at /usr/src/sys/netinet/if_ether.c:1129 #9 arpintr (m=0xfffff81d2e92b000, m@entry=) at /usr/src/sys/netinet/if_ether.c:739 #10 0xffffffff805e5797 in netisr_dispatch_src (proto=4, source=source@entry=0, m=0xfffff81d2e92b000) at /usr/src/sys/net/netisr.c:1153 #11 0xffffffff805e5aef in netisr_dispatch (proto=, m=) at /usr/src/sys/net/netisr.c:1244 #12 0xffffffff805e112e in ether_demux (ifp=ifp@entry=0xfffff8010cfe0800, m=, m@entry=0xfffff81d2e92b000) at /usr/src/sys/net/if_ethersubr.c:926 #13 0xffffffff82c8e89c in ng_ether_rcv_upper (hook=, hook@entry=, item=0xfffff8131de0bd80, item@entry=) at /usr/src/sys/netgraph/ng_ether.c:742 #14 0xffffffff82c75dab in ng_apply_item (node=node@entry=0xfffff81365630b00, item=item@entry=0xfffff8131de0bd80, rw=0) at /usr/src/sys/netgraph/ng_base.c:2406 #15 0xffffffff82c7538d in ng_snd_item (item=0xfffff8131de0bd80, item@entry=, flags=0, flags@entry=) at /usr/src/sys/netgraph/ng_base.c:2323 #16 0xffffffff82c75dab in ng_apply_item (node=node@entry=0xfffff813660f8500, item=item@entry=0xfffff8131de0bd80, rw=0) at /usr/src/sys/netgraph/ng_base.c:2406 #17 0xffffffff82c7538d in ng_snd_item (item=item@entry=0xfffff8131de0bd80, flags=flags@entry=0) at /usr/src/sys/netgraph/ng_base.c:2323 #18 0xffffffff82c8e33f in ng_ether_input (ifp=, ifp@entry=, mp=0xfffffe025a044cf8, mp@entry=) at /usr/src/sys/netgraph/ng_ether.c:255 #19 0xffffffff805e23e7 in ether_input_internal (ifp=0xfffff8010cfe0800, m=0xfffff81d2e92b000) at /usr/src/sys/net/if_ethersubr.c:661 #20 ether_nh_input (m=, m@entry=) at /usr/src/sys/net/if_ethersubr.c:742 #21 0xffffffff805e5797 in netisr_dispatch_src (proto=proto@entry=5, source=source@entry=0, m=m@entry=0xfffff81d2e92b000) at /usr/src/sys/net/netisr.c:1153 #22 0xffffffff805e5aef in netisr_dispatch (proto=, proto@entry=5, m=, m@entry=0xfffff81d2e92b000) at /usr/src/sys/net/netisr.c:1244 #23 0xffffffff805e159d in ether_input (ifp=0xfffff8010cfe0800, m=0xfffff81d2e92b000) at /usr/src/sys/net/if_ethersubr.c:833 #24 0xffffffff821a734d in bce_rx_intr (sc=0xfffffe02a3690000) at /usr/src/sys/dev/bce/if_bce.c:6721 #25 bce_intr (xsc=) at /usr/src/sys/dev/bce/if_bce.c:7870 #26 0xffffffff80490729 in intr_event_execute_handlers (ie=0xfffff80101b05900, p=) at /usr/src/sys/kern/kern_intr.c:1205 #27 ithread_execute_handlers (ie=0xfffff80101b05900, p=) at /usr/src/sys/kern/kern_intr.c:1218 #28 ithread_loop (arg=, arg@entry=0xfffff8012e073a80) at /usr/src/sys/kern/kern_intr.c:1306 #29 0xffffffff8048d1a0 in fork_exit ( callout=0xffffffff804904d0 , arg=0xfffff8012e073a80, frame=0xfffffe025a044f40) at /usr/src/sys/kern/kern_fork.c:1102 #30 #31 0x0000284dcd80544a in ?? () Backtrace stopped: Cannot access memory at address 0x284dd4baff48 (kgdb) Core/kernel/debug/access available on request. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Sun Feb 20 00:26:24 2022 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 60B2619CE8C3 for ; Sun, 20 Feb 2022 00:26:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K1R7Q20wcz4rj3 for ; Sun, 20 Feb 2022 00:26:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qv1-xf2f.google.com with SMTP id f19so22675824qvb.6 for ; Sat, 19 Feb 2022 16:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=+y5IEz1wCIwHHYcg6W2qUDQAES+JlSU18ygcraiWno8=; b=ma2x46kqjwbI14J/Ze65EVASAMc0uzPbidt5m3F1iuseCGKw0J3GldLlTyjNBMxidk v6pZvrQkTUnOf5rjvrdtovonrRCDEs8RQ+5Vdc8bjXvkECpwa5LjGq8oMR8k+tBOwHqx rFMX6FUtoCTx+0uA95hc903RLdfkXTRyA4nCMcIwZS38mrd/+GFljS7L3UIMDFCoou/Y epLpTjpF0Ykds/UBvLDNNTEN84mI3QNwYExIRK/CxZGzhjKoLjmtCekw5Jpd/pt/I/r5 ZTD3CjM15EVqGBYAPUBxVnIyom6omUIGmd0xa8gZdQx/FiopB29B98ObKThlhQ49KGUH dYpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=+y5IEz1wCIwHHYcg6W2qUDQAES+JlSU18ygcraiWno8=; b=qVDjTMGQwgdx+sjKgVRgYDK2UzZ7wNoHwJYMGxzvDgmVL13Yjez3KrPnVdGs7elP5a 34Hil2tiZYHNPQLInXguzKh/HFttvIt0jBJkt8QhQq87LJjqzSJWKtw4H0lZvaZG1Pu1 nrPbZ1WfuoYus/FDlsoTSwK0VKVFdVAu90FsjpyMa2uKI7gzp+BPNf+dnYw2h/bUw7FN qPmf5KOdxj2arUqoBQ1MShn9AqpPAy2MI0r0XWh53VkEj0OI9Fq2Rbm0pw7+85yRvuD0 w+UnZSDC+GJnKMlA+aawGms2TbWYwzuzXfjfdMCZ9ExUYoKDLAxWiDEpst0/W9k7cl4m df+g== X-Gm-Message-State: AOAM531MMhRvdHPM98h6ArShssUKbv0UDntALT8RdWyCci8rmSIQccTh JF4kia5yKytE+kZUZOBKQL0= X-Google-Smtp-Source: ABdhPJznaGCRijWgo1fuoiLeOP43lA8VbwrrJjONTdF4BqTRDyl3j24xF+ZJ9rv5gKfIhK5JmT4cGQ== X-Received: by 2002:a05:622a:1a8d:b0:2de:6b8:e8ca with SMTP id s13-20020a05622a1a8d00b002de06b8e8camr840882qtc.373.1645316785694; Sat, 19 Feb 2022 16:26:25 -0800 (PST) Received: from [10.231.1.66] (075-130-069-034.biz.spectrum.com. [75.130.69.34]) by smtp.gmail.com with ESMTPSA id v14sm29008320qtk.5.2022.02.19.16.26.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Feb 2022 16:26:25 -0800 (PST) Message-ID: <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> Date: Sat, 19 Feb 2022 19:26:24 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Content-Language: en-US To: Konstantin Belousov Cc: Mike Karels , Tomoaki AOKI , "Chen, Alvin W" , freebsd-current@freebsd.org References: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> From: Alexander Motin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K1R7Q20wcz4rj3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ma2x46kq; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::f2f as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-3.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2f:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 19.02.2022 13:23, Konstantin Belousov wrote: > On Sat, Feb 19, 2022 at 12:14:16PM -0500, Alexander Motin wrote: >> On 19.02.2022 12:02, Mike Karels wrote: >>> On 18 Feb 2022, at 20:55, Tomoaki AOKI wrote: >>>> Just a thought, but can it be the reason with timing (e.g., rendezvous >>>> within (i)threads, hardware controlls without using hardware timer) >>>> problem? >>>> >>>> On FreeBSD, IIUC, multi processor (multi core) implementation assumes >>>> SMP (differs only clock speed) and end up with difference of >>>> performance at same clock speed within P-core and E-core, possibly. >>> >>> Another possibility is that the system is confused by having hyperthreading >>> on the P cores but not the E cores. >> >> No, I've tried to disable SMT and different number of cores to make it look >> identical and uniform for the scheduler. The only thing I could not test is >> disabling all P cores to test only E, the motherboard does not allow that, >> requiring at least one P core enabled. > > Does the kernel select MWAIT as the idle method? If you set idle to spin, > is anything change? By default kernel selects ACPI, using MWAIT: machdep.idle: acpi dev.cpu.0.cx_method: C1/mwait/hwc C2/mwait/hwc C3/mwait/hwc I've tried to do in loader: set machdep.idle_mwait=0 set machdep.idle="spin" (also tried "hlt") , but without visible positive effects. -- Alexander Motin From nobody Sun Feb 20 14:12:53 2022 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 410AF19CCF86 for ; Sun, 20 Feb 2022 14:13:05 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K1nTD5T78z3J7R for ; Sun, 20 Feb 2022 14:13:04 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x12e.google.com with SMTP id q4so1348465ilt.0 for ; Sun, 20 Feb 2022 06:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=q+VSYKApOUs4dJUaT0VSYWMLjAHwomI8maVED7xALd0=; b=Y3A7zMXjTM85Ut861DYVFhJ3pkEq72SB41d64RD3NxCrh+LyH763kD53v+hOrjXKV2 qINWrtQWxAM4k2047tPshVkFM3vdbxGs2QdnG9t2h4CjBZmT3X+/AXrjUGDrJuzGi/+5 LN0FWrbfytyFGhwTRHm8qqu7ikq8kdTWiELJDU9hZXgByMVzvJmEZiN43bQ0UsZtSRoo e1hZmrN/ra2pG+eYSYWjrX5SaBDNdp/Yi1R/MnzZHBJmta/v9gTrlRd0bCnHy3R4xFY+ fHujxyuu7LsQiCfNQ2mfeNwT9yL7TAqNpkmbm6KiETJRmzX3cK7cImykipvoBJ9CSsVe dbzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=q+VSYKApOUs4dJUaT0VSYWMLjAHwomI8maVED7xALd0=; b=Px0DWmJAXriJlkcYuBvTIjxVAWSXg+5iZyTOAmxr3pfgUgDvgwiAFFrpFLN65k7l48 k0lYjM80cbfW+/bjwzT5pDl0EAu183RToYqCwBlrXaOVPR3iQmdA4SRLM39BcisxmA+B YJ330fTZgXQzRWeMucFeTGpczjRuNQUubmSDTlQ4dt8C4Yy3/hDVW/6jPKviCNZxqJUy KXsVA/k2jKbUyxtTIUTW5EfofxAHiQt7QnF4YO0wsW4Ek1sTYCuFN10NZGNBq+RbSurl 448hoiHgrgFvVcbO6N1LJSW6qbnTjb4+rYeXD6nR34xpbXOBkKbSJLTDQrduD8c/AIXM 7beg== X-Gm-Message-State: AOAM533mQJOujUe7Cq1Te3P/mt0vMPJ9g8Pnj540raRUVtxdrOma/4lB 6Qb0JNu8k53f59/XBr3cv0SvWLAXJg6L2juC609XhYQieOIpn6ri X-Google-Smtp-Source: ABdhPJxDAhiD9rprwkgwS3Xfs61A/h/7oePMS7VLIuA7FjtPCIgsFfLTIdLz5zlV1Y3UndlX3wEmaaTb3Q6/lsnJmlA= X-Received: by 2002:a05:6e02:1beb:b0:2bf:eed2:cd93 with SMTP id y11-20020a056e021beb00b002bfeed2cd93mr11996083ilv.99.1645366383897; Sun, 20 Feb 2022 06:13:03 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Michael Schuster Date: Sun, 20 Feb 2022 15:12:53 +0100 Message-ID: Subject: "linker_load_file ... unsupported file type" after upgrade attempts on -CURRENT To: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000d671f405d873b6b2" X-Rspamd-Queue-Id: 4K1nTD5T78z3J7R X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Y3A7zMXj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::12e as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.94 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12e:from]; NEURAL_HAM_SHORT(-0.94)[-0.937]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000d671f405d873b6b2 Content-Type: text/plain; charset="UTF-8" Hi, I'm currently running on -CURRENT from November, though I think the message for amdgpu.ko ("kernel: linker_load_file: /boot/modules/amdgpu.ko - unsupported file type") started to appear as early as last August. Since this isn't my daily driver (yet!), I didn't notice for quite a while, and scfb is adequate for what little I currently do on FreeBSD. When I initially installed this machine in Aug 2020, my GPU (Vega10 Renoir) wasn't supported by DRM, so over time I made several builds of the graphics/drm-devel-kmod port, which worked for a while last year. In the last weeks, in the time I managed to set aside for this work, I made several attempts to bring this machine up-to-date, using "pkg upgrade", building my own from /usr/src (always up-to-date using 'git pull'), and beinstall.sh. (both separately and in combination). I always work with separate build environments for these attempts. All my upgrade attempts have resulted in a system that boots, but neither starts X nor lets me log in on a console. There are "linker_load_file ... " message for several .ko files, all preceded by a line like this: "KLD hconf.ko: depends on kernel - not available or version mismatchmodule name" here are the paths I get this message about: /boot/kernel/cuse.ko /boot/kernel/hconf.ko /boot/kernel/hms.ko /boot/kernel/hmt.ko /boot/kernel/intpm.ko /boot/kernel/lindebugfs.ko /boot/kernel/linux.ko /boot/kernel/linux64.ko /boot/modules/amdgpu.ko /boot/modules/drm.ko The information I found on the Internet about this error message seem to indicate that I need to re-build the .ko being reported by the message with the current kernel, which is .. hard if I can't even log in ;-). I would also not expect a version mismatch after a pkg upgrade (but no, I didn't go through all the output that generated). Does anyone have an idea what I can do to get past this obstacle? I could of course always re-install, but that feels like giving in :-) TIA Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' --000000000000d671f405d873b6b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">I'm currently running on -CURRENT from November, thou= gh I think the message for amdgpu.ko ("kernel: linker_load_file: /boot= /modules/amdgpu.ko - unsupported file type") started to appear as earl= y as last August. Since this isn't my daily driver (yet!), I didn't= notice for quite a while, and scfb is adequate for what little I currently= do on FreeBSD.
When I initially installed this mac= hine in Aug 2020, my GPU (Vega10 Renoir) wasn't supported by DRM, so ov= er time I made several builds of the graphics/drm-devel-kmod port, which wo= rked for a while last year.

In the last weeks, in the time I managed to set aside for this work, I mad= e several attempts to bring this machine up-to-date, using "pkg upgrad= e", building my own from /usr/src (always up-to-date using 'git pu= ll'), and beinstall.sh. (both separately and in combination). I always = work with separate build environments for these attempts.
All my upgrade attempts have resulted in a system that boots, but = neither starts X nor lets me log in on a console. There are "linker_lo= ad_file ... " message for several .ko files, all preceded by a line li= ke this:

"KLD hco= nf.ko: depends on kernel - not available or version mismatchmodule name&quo= t;

here are the pa= ths I get this message about:

/boot/kernel/cuse.ko
/boot/kernel/hconf.ko
/boot/kernel/hms.= ko
/boot/kernel/hmt.ko
/boot/kernel/intpm.ko
/boot/kernel/lindebug= fs.ko
/boot/kernel/linux.ko
/boot/kernel/linux64.ko
/boot/modules/= amdgpu.ko
/boot/modules/drm.ko

The information I found on the Intern= et about this error message seem to indicate that I need to re-build the .k= o being reported by the message with the current kernel, which is .. hard i= f I can't even log in ;-). I would also not expect a version mismatch a= fter a pkg upgrade (but no, I didn't go through all the output that gen= erated).

Does anyone = have an idea what I can do to get past this obstacle? I could of course alw= ays re-install, but that feels like giving in :-)

TIA
Michael=
--
recursion, n: see 'recu= rsion'
--000000000000d671f405d873b6b2-- From nobody Sun Feb 20 20:53:09 2022 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 5D6C219C75E9 for ; Sun, 20 Feb 2022 20:53:39 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from us-smtp-delivery-197.mimecast.com (us-smtp-delivery-197.mimecast.com [170.10.133.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mimecast.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K1yMQ4wYxz3JJ4 for ; Sun, 20 Feb 2022 20:53:38 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from MAIL-DR.pai.local (175.158.26.216.gopai.com [216.26.158.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-512-mV1GWlHdO-C5SYudX6jOeg-1; Sun, 20 Feb 2022 15:53:29 -0500 X-MC-Unique: mV1GWlHdO-C5SYudX6jOeg-1 Received: from MAIL-HUB.pai.local (10.10.0.250) by MAIL-DR.pai.local (10.10.0.251) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Sun, 20 Feb 2022 15:53:09 -0500 Received: from MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8]) by MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8%15]) with mapi id 15.00.1497.028; Sun, 20 Feb 2022 15:53:09 -0500 From: Michael Jung To: freebsd-current Subject: New panic in main-n253273-a52d8d4a6c6: Thread-Topic: New panic in main-n253273-a52d8d4a6c6: Thread-Index: AdgmmC6h1TNd/HB0TUWCzt+asldIhg== Date: Sun, 20 Feb 2022 20:53:09 +0000 Message-ID: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.0.59] x-c2processedorg: 474f336e-f930-49ec-9717-e3226b5b6e6e 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-Mimecast-Spam-Score: 0 X-Mimecast-Originator: paymentallianceintl.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_b7ca5b5e7a9a4df3951a2cb2f1d63552MAILHUBpailocal_" X-Rspamd-Queue-Id: 4K1yMQ4wYxz3JJ4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=paymentallianceintl.com; spf=pass (mx1.freebsd.org: domain of mikej@paymentallianceintl.com designates 170.10.133.197 as permitted sender) smtp.mailfrom=mikej@paymentallianceintl.com X-Spamd-Result: default: False [-3.85 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:170.10.133.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.951]; DMARC_POLICY_ALLOW(-0.50)[paymentallianceintl.com,none]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:30031, ipnet:170.10.132.0/23, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[170.10.133.197:from] X-ThisMailContainsUnwantedMimeParts: N --_000_b7ca5b5e7a9a4df3951a2cb2f1d63552MAILHUBpailocal_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! The box was quite busy at the time. The only odd thing I am aware of and w= hich I do not think is related is I have not been able to expand one of my zpool's. = ZFS sees my added draid2:2d:10c:0s vdev but I can't seem to force zpool's expansion - m= y bet this is somehow related to the mirrored special device in the pool even though a= utoexpand is set to 'on' for the pool. Not asking anyone to solve this, I plan on putting together a "how to repro= duce" and post to freebsd-fs@ but wanted to note this oddity. --mikej This is a unmodified GENERIC kernel. Unread portion of the kernel message buffer: panic: refcount 0xfffff801cc119284 wraparound cpuid =3D 7 time =3D 1645382575 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0119a83= c80 vpanic() at vpanic+0x17f/frame 0xfffffe0119a83cd0 panic() at panic+0x43/frame 0xfffffe0119a83d30 fdclose() at fdclose/frame 0xfffffe0119a83dc0 closefp_impl() at closefp_impl+0x77/frame 0xfffffe0119a83e00 amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0119a83f30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0119a83f30 --- syscall (6, FreeBSD ELF64, sys_close), rip =3D 0x3309a531b62a, rsp =3D = 0x3309a2802bc8, rbp =3D 0x3309a2803000 --- KDB: enter: panic __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(str= uct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=3Dtextdump@entry=3D0) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff804c86ba in db_dump (dummy=3D, dummy2=3D, dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:575 #3 0xffffffff804c8572 in db_command (last_cmdp=3D, cmd_table=3D, dopager=3Ddopager@entry=3D1) at /usr/src/sys/ddb/db_command.c:482 #4 0xffffffff804c81cd in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0xffffffff804cb806 in db_trap (type=3D, code=3D) at /usr/src/sys/ddb/db_main.c:270 #6 0xffffffff80c566fb in kdb_trap (type=3Dtype@entry=3D3, code=3Dcode@entr= y=3D0, tf=3Dtf@entry=3D0xfffffe0119a83bb0) at /usr/src/sys/kern/subr_kdb.c:733 #7 0xffffffff810e75ca in trap (frame=3D0xfffffe0119a83bb0) at /usr/src/sys/amd64/amd64/trap.c:609 #8 #9 kdb_enter (why=3D0xffffffff812e5eaf "panic", msg=3D) at /usr/src/sys/kern/subr_kdb.c:506 #10 0xffffffff80c08c50 in vpanic ( fmt=3D0xffffffff8122606d "refcount %p wraparound", ap=3Dap@entry=3D0xfffffe0119a83d10) at /usr/src/sys/kern/kern_shutdown.= c:908 #11 0xffffffff80c089e3 in panic ( fmt=3D0xffffffff81e8cf40 "\332#*\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:844 #12 0xffffffff80ba9180 in _refcount_update_saturated (count=3D0xfffff801cc1= 19284) at /usr/src/sys/sys/refcount.h:55 #13 refcount_releasen (count=3D0xfffff801cc119284, n=3D1) at /usr/src/sys/sys/refcount.h:154 #14 refcount_release (count=3D0xfffff801cc119284) at /usr/src/sys/sys/refcount.h:174 #15 closef (fp=3D, td=3D0xfffffe00df8d0560) at /usr/src/sys/kern/kern_descrip.c:2776 #16 0xffffffff80bad587 in closefp_impl (fdp=3D0xfffffe012b7c0430, fd=3D4, fp=3D0xfffff801cc119280, td=3D0xfffffe00df8d0560, audit=3Dtrue) at /usr/src/sys/kern/kern_descrip.c:1300 #17 0xffffffff810e838e in syscallenter (td=3D) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #18 amd64_syscall (td=3D0xfffffe00df8d0560, traced=3D0) at /usr/src/sys/amd64/amd64/trap.c:1191 #19 #20 0x00003309a531b62a in ?? () Backtrace stopped: Cannot access memory at address 0x3309a2802bc8 (kgdb) http://mail.mikej.com/core.txt.0 http://mail.mikej.com/info.0 http://mail.mikej.com/kernel.full.0 http://mail.mikej.com/vmcore.0 CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4000 or notify us at: PAI, Dept. 99, 2101 High Wickham Place, Suite 101, Louisville, KY 40245 Disclaimer The information contained in this communication from the sender is confiden= tial. It is intended solely for use by the recipient and others authorized = to receive it. If you are not the recipient, you are hereby notified that a= ny disclosure, copying, distribution or taking action in relation of the co= ntents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been auto= matically archived by Mimecast, a leader in email security and cyber resili= ence. Mimecast integrates email defenses with brand protection, security aw= areness training, web security, compliance and other essential capabilities= . Mimecast helps protect large and small organizations from malicious activ= ity, human error and technology failure; and to lead the movement toward bu= ilding a more resilient world. To find out more, visit our website. --_000_b7ca5b5e7a9a4df3951a2cb2f1d63552MAILHUBpailocal_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <= /head>

Hi!

 

The box was quite busy at the time.  The only odd thin= g I am aware of and which I do

not think is related is I have not been able to expand one = of my zpool’s.  ZFS sees my

added draid2:2d:10c:0s vdev but I can’t seem to force= zpool’s expansion – my bet this

is somehow related to the mirrored special device in the po= ol even though autoexpand

is set to ‘on’ for the pool.<= /p>

 

Not asking anyone to solve this, I plan on putting together= a “how to reproduce” and

post to freebsd-fs@ but wanted to note this oddity.

 

--mikej

 

This is a unmodified GENERIC kernel.

 

 

Unread portion of the kernel message buffer:

panic: refcount 0xfffff801cc119284 wraparound

cpuid =3D 7

time =3D 1645382575

KDB: stack backtrace:

db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/f= rame 0xfffffe0119a83c80

vpanic() at vpanic+0x17f/frame 0xfffffe0119a83cd0<= /o:p>

panic() at panic+0x43/frame 0xfffffe0119a83d30

fdclose() at fdclose/frame 0xfffffe0119a83dc0

closefp_impl() at closefp_impl+0x77/frame 0xfffffe0119a= 83e00

amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe01= 19a83f30

fast_syscall_common() at fast_syscall_common+0xf8/frame= 0xfffffe0119a83f30

--- syscall (6, FreeBSD ELF64, sys_close), rip =3D 0x3309a5= 31b62a, rsp =3D 0x3309a2802bc8, rbp =3D 0x3309a2803000 ---

KDB: enter: panic

 

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55<= o:p>

55         &nb= sp;     __asm("movq %%gs:%P1,%0" : "=3Dr= " (td) : "n" (offsetof(struct pcpu,

(kgdb) #0  __curthread () at /usr/src/sys/amd64/includ= e/pcpu_aux.h:55

#1  doadump (textdump=3Dtextdump@entry=3D0)=

    at /usr/src/sys/kern/kern_shutdown.c:399=

#2  0xffffffff804c86ba in db_dump (dummy=3D<optimiz= ed out>,

    dummy2=3D<unavailable>, dummy= 3=3D<unavailable>, dummy4=3D<unavailable>)

    at /usr/src/sys/ddb/db_command.c:575

#3  0xffffffff804c8572 in db_command (last_cmdp=3D<= optimized out>,

    cmd_table=3D<optimized out>, = dopager=3Ddopager@entry=3D1)

    at /usr/src/sys/ddb/db_command.c:482

#4  0xffffffff804c81cd in db_command_loop ()

    at /usr/src/sys/ddb/db_command.c:535

#5  0xffffffff804cb806 in db_trap (type=3D<optimize= d out>, code=3D<optimized out>)

    at /usr/src/sys/ddb/db_main.c:270

#6  0xffffffff80c566fb in kdb_trap (type=3Dtype@entry= =3D3, code=3Dcode@entry=3D0,

    tf=3Dtf@entry=3D0xfffffe0119a83bb0)= at /usr/src/sys/kern/subr_kdb.c:733

#7  0xffffffff810e75ca in trap (frame=3D0xfffffe0119a8= 3bb0)

    at /usr/src/sys/amd64/amd64/trap.c:609

#8  <signal handler called>

#9  kdb_enter (why=3D0xffffffff812e5eaf "panic&qu= ot;, msg=3D<optimized out>)

    at /usr/src/sys/kern/subr_kdb.c:506=

#10 0xffffffff80c08c50 in vpanic (

    fmt=3D0xffffffff8122606d "refcount = %p wraparound",

    ap=3Dap@entry=3D0xfffffe0119a83d10)= at /usr/src/sys/kern/kern_shutdown.c:908

#11 0xffffffff80c089e3 in panic (

    fmt=3D0xffffffff81e8cf40 <cnputs_mtx&= gt; "\332#*\201\377\377\377\377")

    at /usr/src/sys/kern/kern_shutdown.c:844=

#12 0xffffffff80ba9180 in _refcount_update_saturated (count= =3D0xfffff801cc119284)

    at /usr/src/sys/sys/refcount.h:55

#13 refcount_releasen (count=3D0xfffff801cc119284, n=3D1)

    at /usr/src/sys/sys/refcount.h:154<= /o:p>

#14 refcount_release (count=3D0xfffff801cc119284)

    at /usr/src/sys/sys/refcount.h:174<= /o:p>

#15 closef (fp=3D<optimized out>, td=3D0xfffffe00df8d= 0560)

    at /usr/src/sys/kern/kern_descrip.c:2776=

#16 0xffffffff80bad587 in closefp_impl (fdp=3D0xfffffe012b7= c0430, fd=3D4,

    fp=3D0xfffff801cc119280, td=3D0xfff= ffe00df8d0560, audit=3Dtrue)

    at /usr/src/sys/kern/kern_descrip.c:1300=

#17 0xffffffff810e838e in syscallenter (td=3D<optimized = out>)

    at /usr/src/sys/amd64/amd64/../../kern/s= ubr_syscall.c:189

#18 amd64_syscall (td=3D0xfffffe00df8d0560, traced=3D0)

    at /usr/src/sys/amd64/amd64/trap.c:1191<= o:p>

#19 <signal handler called>

#20 0x00003309a531b62a in ?? ()

Backtrace stopped: Cannot access memory at address 0x3309a2= 802bc8

(kgdb)

 

 

 

 

http://mail.mi= kej.com/core.txt.0

 

http://mail.mikej.= com/info.0

 

http://mail= .mikej.com/kernel.full.0

 

http://mail.mike= j.com/vmcore.0

 

 

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245





<= b>Disclaimer

The information contained in this communication from the sender i= s confidential. It is intended solely for use by the recipient and others a= uthorized to receive it. If you are not the recipient, you are hereby notif= ied that any disclosure, copying, distribution or taking action in relation= of the contents of this information is strictly prohibited and may be unla= wful.

This email has been scanned for viruses and malware, and may h= ave been automatically archived by Mimecast, a leader in email security and= cyber resilience. Mimecast integrates email defenses with brand protection= , security awareness training, web security, compliance and other essential= capabilities. Mimecast helps protect large and small organizations from ma= licious activity, human error and technology failure; and to lead the movem= ent toward building a more resilient world. To find out more, visit our web= site.

--_000_b7ca5b5e7a9a4df3951a2cb2f1d63552MAILHUBpailocal_-- From nobody Mon Feb 21 07:43:26 2022 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 6B4F919C3116 for ; Mon, 21 Feb 2022 07:43:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4K2DnT3G7Lz3lVd for ; Mon, 21 Feb 2022 07:43:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A049E260347 for ; Mon, 21 Feb 2022 08:43:39 +0100 (CET) Message-ID: <6984fd5d-ae58-11a4-0d21-a8695b0c77f7@selasky.org> Date: Mon, 21 Feb 2022 08:43:26 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US To: FreeBSD Current From: Hans Petter Selasky Subject: pxeboot binary is too big on FreeBSD (>640KBytes) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K2DnT3G7Lz3lVd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.29 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[selasky.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N FYI: After a lot of digging trying everything, I found that the pxeboot and loader.efi was too big simply due to ZFS support. So I did this after buildworld: cd /usr/src/stand make WITHOUT_LOADER_ZFS=YES clean make WITHOUT_LOADER_ZFS=YES all make WITHOUT_LOADER_ZFS=YES install And now it works, with my old GigaByte mainboard! Why should pxeboot have ZFS support? https://forums.freebsd.org/threads/problem-with-isc-dhcpd-and-diskless-booting.82199/ --HPS From nobody Mon Feb 21 07:48:27 2022 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 A259B19C4A32 for ; Mon, 21 Feb 2022 07:48:46 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2DvK5b1Fz3mY1 for ; Mon, 21 Feb 2022 07:48:45 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C838E260347; Mon, 21 Feb 2022 08:48:37 +0100 (CET) Message-ID: Date: Mon, 21 Feb 2022 08:48:27 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: New panic in main-n253273-a52d8d4a6c6: Content-Language: en-US To: Michael Jung , freebsd-current References: From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K2DvK5b1Fz3mY1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.29 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2/20/22 21:53, Michael Jung wrote: > Hi! > > The box was quite busy at the time. The only odd thing I am aware of and which I do > not think is related is I have not been able to expand one of my zpool's. ZFS sees my > added draid2:2d:10c:0s vdev but I can't seem to force zpool's expansion - my bet this > is somehow related to the mirrored special device in the pool even though autoexpand > is set to 'on' for the pool. > > Not asking anyone to solve this, I plan on putting together a "how to reproduce" and > post to freebsd-fs@ but wanted to note this oddity. > > --mikej > > This is a unmodified GENERIC kernel. > > > Unread portion of the kernel message buffer: > panic: refcount 0xfffff801cc119284 wraparound > cpuid = 7 > time = 1645382575 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0119a83c80 > vpanic() at vpanic+0x17f/frame 0xfffffe0119a83cd0 > panic() at panic+0x43/frame 0xfffffe0119a83d30 > fdclose() at fdclose/frame 0xfffffe0119a83dc0 > closefp_impl() at closefp_impl+0x77/frame 0xfffffe0119a83e00 > amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0119a83f30 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0119a83f30 > --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x3309a531b62a, rsp = 0x3309a2802bc8, rbp = 0x3309a2803000 --- > KDB: enter: panic > This may be a refcount leak. Are you able to dump "fdp" at: #16 0xffffffff80bad587 in closefp_impl (fdp=0xfffffe012b7c0430, fd=4, fp=0xfffff801cc119280, td=0xfffffe00df8d0560, audit=true) at /usr/src/sys/kern/kern_descrip.c:1300 frame 16 print /x *fdp --HPS From nobody Mon Feb 21 13:07:44 2022 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 7DEF119E2927 for ; Mon, 21 Feb 2022 13:07:56 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from us-smtp-delivery-197.mimecast.com (us-smtp-delivery-197.mimecast.com [170.10.133.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mimecast.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2MzZ6Zzcz3KMs for ; Mon, 21 Feb 2022 13:07:54 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from MAIL-DR.pai.local (175.158.26.216.gopai.com [216.26.158.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-652-K0O6oSmPMumKHqrCfr493Q-1; Mon, 21 Feb 2022 08:07:52 -0500 X-MC-Unique: K0O6oSmPMumKHqrCfr493Q-1 Received: from MAIL-HUB.pai.local (10.10.0.250) by MAIL-DR.pai.local (10.10.0.251) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Mon, 21 Feb 2022 08:07:44 -0500 Received: from MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8]) by MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8%15]) with mapi id 15.00.1497.028; Mon, 21 Feb 2022 08:07:45 -0500 From: Michael Jung To: Hans Petter Selasky , freebsd-current Subject: RE: New panic in main-n253273-a52d8d4a6c6: Thread-Topic: New panic in main-n253273-a52d8d4a6c6: Thread-Index: AdgmmC6h1TNd/HB0TUWCzt+asldIhgAiSNWAAACbjEA= Date: Mon, 21 Feb 2022 13:07:44 +0000 Message-ID: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.0.59] x-c2processedorg: 474f336e-f930-49ec-9717-e3226b5b6e6e 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-Mimecast-Spam-Score: 0 X-Mimecast-Originator: paymentallianceintl.com Content-Type: multipart/alternative; boundary="MCBoundary=_12202210807532101" X-Rspamd-Queue-Id: 4K2MzZ6Zzcz3KMs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=paymentallianceintl.com; spf=pass (mx1.freebsd.org: domain of mikej@paymentallianceintl.com designates 170.10.133.197 as permitted sender) smtp.mailfrom=mikej@paymentallianceintl.com X-Spamd-Result: default: False [-2.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:170.10.133.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[paymentallianceintl.com,none]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:30031, ipnet:170.10.132.0/23, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[170.10.133.197:from] X-ThisMailContainsUnwantedMimeParts: N --MCBoundary=_12202210807532101 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvd25lci1mcmVlYnNkLWN1cnJl bnRAZnJlZWJzZC5vcmcgW21haWx0bzpvd25lci1mcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmdd IE9uIEJlaGFsZiBPZiBIYW5zIFBldHRlciBTZWxhc2t5DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5 IDIxLCAyMDIyIDI6NDggQU0NClRvOiBNaWNoYWVsIEp1bmcgPG1pa2VqQHBheW1lbnRhbGxpYW5j ZWludGwuY29tPjsgZnJlZWJzZC1jdXJyZW50IDxmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmc+ DQpTdWJqZWN0OiBSZTogTmV3IHBhbmljIGluIG1haW4tbjI1MzI3My1hNTJkOGQ0YTZjNjoNCg0K T24gMi8yMC8yMiAyMTo1MywgTWljaGFlbCBKdW5nIHdyb3RlOg0KPiBIaSENCj4NCj4gVGhlIGJv eCB3YXMgcXVpdGUgYnVzeSBhdCB0aGUgdGltZS4gIFRoZSBvbmx5IG9kZCB0aGluZyBJIGFtIGF3 YXJlIG9mDQo+IGFuZCB3aGljaCBJIGRvIG5vdCB0aGluayBpcyByZWxhdGVkIGlzIEkgaGF2ZSBu b3QgYmVlbiBhYmxlIHRvIGV4cGFuZA0KPiBvbmUgb2YgbXkgenBvb2wncy4gIFpGUyBzZWVzIG15 IGFkZGVkIGRyYWlkMjoyZDoxMGM6MHMgdmRldiBidXQgSQ0KPiBjYW4ndCBzZWVtIHRvIGZvcmNl IHpwb29sJ3MgZXhwYW5zaW9uIC0gbXkgYmV0IHRoaXMgaXMgc29tZWhvdyByZWxhdGVkDQo+IHRv IHRoZSBtaXJyb3JlZCBzcGVjaWFsIGRldmljZSBpbiB0aGUgcG9vbCBldmVuIHRob3VnaCBhdXRv ZXhwYW5kIGlzIHNldCB0byAnb24nIGZvciB0aGUgcG9vbC4NCj4NCj4gTm90IGFza2luZyBhbnlv bmUgdG8gc29sdmUgdGhpcywgSSBwbGFuIG9uIHB1dHRpbmcgdG9nZXRoZXIgYSAiaG93IHRvDQo+ IHJlcHJvZHVjZSIgYW5kIHBvc3QgdG8gZnJlZWJzZC1mc0AgYnV0IHdhbnRlZCB0byBub3RlIHRo aXMgb2RkaXR5Lg0KPg0KPiAtLW1pa2VqDQo+DQo+IFRoaXMgaXMgYSB1bm1vZGlmaWVkIEdFTkVS SUMga2VybmVsLg0KPg0KPg0KPiBVbnJlYWQgcG9ydGlvbiBvZiB0aGUga2VybmVsIG1lc3NhZ2Ug YnVmZmVyOg0KPiBwYW5pYzogcmVmY291bnQgMHhmZmZmZjgwMWNjMTE5Mjg0IHdyYXBhcm91bmQg Y3B1aWQgPSA3IHRpbWUgPQ0KPiAxNjQ1MzgyNTc1DQo+IEtEQjogc3RhY2sgYmFja3RyYWNlOg0K PiBkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYi9m cmFtZQ0KPiAweGZmZmZmZTAxMTlhODNjODANCj4gdnBhbmljKCkgYXQgdnBhbmljKzB4MTdmL2Zy YW1lIDB4ZmZmZmZlMDExOWE4M2NkMA0KPiBwYW5pYygpIGF0IHBhbmljKzB4NDMvZnJhbWUgMHhm ZmZmZmUwMTE5YTgzZDMwDQo+IGZkY2xvc2UoKSBhdCBmZGNsb3NlL2ZyYW1lIDB4ZmZmZmZlMDEx OWE4M2RjMA0KPiBjbG9zZWZwX2ltcGwoKSBhdCBjbG9zZWZwX2ltcGwrMHg3Ny9mcmFtZSAweGZm ZmZmZTAxMTlhODNlMDANCj4gYW1kNjRfc3lzY2FsbCgpIGF0IGFtZDY0X3N5c2NhbGwrMHgxMmUv ZnJhbWUgMHhmZmZmZmUwMTE5YTgzZjMwDQo+IGZhc3Rfc3lzY2FsbF9jb21tb24oKSBhdCBmYXN0 X3N5c2NhbGxfY29tbW9uKzB4ZjgvZnJhbWUNCj4gMHhmZmZmZmUwMTE5YTgzZjMwDQo+IC0tLSBz eXNjYWxsICg2LCBGcmVlQlNEIEVMRjY0LCBzeXNfY2xvc2UpLCByaXAgPSAweDMzMDlhNTMxYjYy YSwgcnNwID0NCj4gMHgzMzA5YTI4MDJiYzgsIHJicCA9IDB4MzMwOWEyODAzMDAwIC0tLQ0KPiBL REI6IGVudGVyOiBwYW5pYw0KPg0KDQpUaGlzIG1heSBiZSBhIHJlZmNvdW50IGxlYWsuIEFyZSB5 b3UgYWJsZSB0byBkdW1wICJmZHAiIGF0Og0KDQojMTYgMHhmZmZmZmZmZjgwYmFkNTg3IGluIGNs b3NlZnBfaW1wbCAoZmRwPTB4ZmZmZmZlMDEyYjdjMDQzMCwgZmQ9NCwNCiAgICAgZnA9MHhmZmZm ZjgwMWNjMTE5MjgwLCB0ZD0weGZmZmZmZTAwZGY4ZDA1NjAsIGF1ZGl0PXRydWUpDQogICAgIGF0 IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jOjEzMDANCg0KZnJhbWUgMTYNCnByaW50 IC94ICpmZHANCg0KLS1IUFMNCg0KDQogW3Jvb3RAZHJhaWQgL3Zhci9jcmFzaF0jIGtnZGIga2Vy bmVsLmZ1bGwuMCB2bWNvcmUuMA0KR05VIGdkYiAoR0RCKSAxMS4yIFtHREIgdjExLjIgZm9yIEZy ZWVCU0RdDQpDb3B5cmlnaHQgKEMpIDIwMjIgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMu DQpMaWNlbnNlIEdQTHYzKzogR05VIEdQTCB2ZXJzaW9uIDMgb3IgbGF0ZXIgPGh0dHA6Ly9nbnUu b3JnL2xpY2Vuc2VzL2dwbC5odG1sPg0KVGhpcyBpcyBmcmVlIHNvZnR3YXJlOiB5b3UgYXJlIGZy ZWUgdG8gY2hhbmdlIGFuZCByZWRpc3RyaWJ1dGUgaXQuDQpUaGVyZSBpcyBOTyBXQVJSQU5UWSwg dG8gdGhlIGV4dGVudCBwZXJtaXR0ZWQgYnkgbGF3Lg0KVHlwZSAic2hvdyBjb3B5aW5nIiBhbmQg InNob3cgd2FycmFudHkiIGZvciBkZXRhaWxzLg0KVGhpcyBHREIgd2FzIGNvbmZpZ3VyZWQgYXMg Ing4Nl82NC1wb3J0YmxkLWZyZWVic2QxNC4wIi4NClR5cGUgInNob3cgY29uZmlndXJhdGlvbiIg Zm9yIGNvbmZpZ3VyYXRpb24gZGV0YWlscy4NCkZvciBidWcgcmVwb3J0aW5nIGluc3RydWN0aW9u cywgcGxlYXNlIHNlZToNCjxodHRwczovL3d3dy5nbnUub3JnL3NvZnR3YXJlL2dkYi9idWdzLz4u DQpGaW5kIHRoZSBHREIgbWFudWFsIGFuZCBvdGhlciBkb2N1bWVudGF0aW9uIHJlc291cmNlcyBv bmxpbmUgYXQ6DQogICAgPGh0dHA6Ly93d3cuZ251Lm9yZy9zb2Z0d2FyZS9nZGIvZG9jdW1lbnRh dGlvbi8+Lg0KDQpGb3IgaGVscCwgdHlwZSAiaGVscCIuDQpUeXBlICJhcHJvcG9zIHdvcmQiIHRv IHNlYXJjaCBmb3IgY29tbWFuZHMgcmVsYXRlZCB0byAid29yZCIuLi4NClJlYWRpbmcgc3ltYm9s cyBmcm9tIGtlcm5lbC5mdWxsLjAuLi4NCg0KVW5yZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5lbCBt ZXNzYWdlIGJ1ZmZlcjoNCnBhbmljOiByZWZjb3VudCAweGZmZmZmODAxY2MxMTkyODQgd3JhcGFy b3VuZA0KY3B1aWQgPSA3DQp0aW1lID0gMTY0NTM4MjU3NQ0KS0RCOiBzdGFjayBiYWNrdHJhY2U6 DQpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYi9m cmFtZSAweGZmZmZmZTAxMTlhODNjODANCnZwYW5pYygpIGF0IHZwYW5pYysweDE3Zi9mcmFtZSAw eGZmZmZmZTAxMTlhODNjZDANCnBhbmljKCkgYXQgcGFuaWMrMHg0My9mcmFtZSAweGZmZmZmZTAx MTlhODNkMzANCmZkY2xvc2UoKSBhdCBmZGNsb3NlL2ZyYW1lIDB4ZmZmZmZlMDExOWE4M2RjMA0K Y2xvc2VmcF9pbXBsKCkgYXQgY2xvc2VmcF9pbXBsKzB4NzcvZnJhbWUgMHhmZmZmZmUwMTE5YTgz ZTAwDQphbWQ2NF9zeXNjYWxsKCkgYXQgYW1kNjRfc3lzY2FsbCsweDEyZS9mcmFtZSAweGZmZmZm ZTAxMTlhODNmMzANCmZhc3Rfc3lzY2FsbF9jb21tb24oKSBhdCBmYXN0X3N5c2NhbGxfY29tbW9u KzB4ZjgvZnJhbWUgMHhmZmZmZmUwMTE5YTgzZjMwDQotLS0gc3lzY2FsbCAoNiwgRnJlZUJTRCBF TEY2NCwgc3lzX2Nsb3NlKSwgcmlwID0gMHgzMzA5YTUzMWI2MmEsIHJzcCA9IDB4MzMwOWEyODAy YmM4LCByYnAgPSAweDMzMDlhMjgwMzAwMCAtLS0NCktEQjogZW50ZXI6IHBhbmljDQoNCl9fY3Vy dGhyZWFkICgpIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9pbmNsdWRlL3BjcHVfYXV4Lmg6NTUNCjU1 ICAgICAgICAgICAgICBfX2FzbSgibW92cSAlJWdzOiVQMSwlMCIgOiAiPXIiICh0ZCkgOiAibiIg KG9mZnNldG9mKHN0cnVjdCBwY3B1LA0KDQooa2dkYikgZnJhbSAxNg0KIzE2IDB4ZmZmZmZmZmY4 MGJhZDU4NyBpbiBjbG9zZWZwX2ltcGwgKGZkcD0weGZmZmZmZTAxMmI3YzA0MzAsIGZkPTQsIGZw PTB4ZmZmZmY4MDFjYzExOTI4MCwgdGQ9MHhmZmZmZmUwMGRmOGQwNTYwLCBhdWRpdD10cnVlKSBh dCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoxMzAwDQoxMzAwICAgICAgICAgICAg ZXJyb3IgPSBjbG9zZWYoZnAsIHRkKTsNCg0KKGtnZGIpIHByaW50IC94ICpmZHANCiQxID0ge2Zk X2ZpbGVzID0gMHhmZmZmZmUwMGRmNmQ5MDAwLCBmZF9tYXAgPSAweGZmZmZmODAwMDFiYjE4MDAs IGZkX2ZyZWVmaWxlID0gMHg0LCBmZF9yZWZjbnQgPSAweDEsIGZkX2hvbGRjbnQgPSAweDEsIGZk X3N4ID0ge2xvY2tfb2JqZWN0ID0ge2xvX25hbWUgPSAweGZmZmZmZmZmODEyNGY2YTksIGxvX2Zs YWdzID0gMHgyMzMwMDAwLCBsb19kYXRhID0gMHgwLA0KICAgICAgbG9fd2l0bmVzcyA9IDB4ZmZm ZmY4MDQxZWI5NDAwMH0sIHN4X2xvY2sgPSAweDF9LCBmZF9rcWxpc3QgPSB7dHFoX2ZpcnN0ID0g MHgwLCB0cWhfbGFzdCA9IDB4MH0sIGZkX2hvbGRsZWFkZXJzY291bnQgPSAweDAsIGZkX2hvbGRs ZWFkZXJzd2FrZXVwID0gMHgwfQ0KKGtnZGIpDQoNCg0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RF OiBUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZQ0Kb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gaXQgaXMgYWRkcmVzc2VkIGFuZCBtYXkNCmNvbnRhaW4g aW5mb3JtYXRpb24gdGhhdCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIGFuZA0KZXhlbXB0 IGZyb20gZGlzY2xvc3VyZSB1bmRlciBhcHBsaWNhYmxlIGxhdy4gSWYgdGhlIHJlYWRlcg0Kb2Yg dGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVi eQ0Kbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlp bmcNCm9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3Ug aGF2ZQ0KcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dXMgYnkNCnRlbGVwaG9uZSBhdCAoNTAyKSAyMTItNDAwMCBvciBub3RpZnkgdXMgYXQgUEFJLCBE ZXB0LiA5OSwNCjIxMDEgSGlnaCBXaWNraGFtIFBsYWNlLCBTdWl0ZSAxMDEsIExvdWlzdmlsbGUs IEtZIDQwMjQ1DQoNCkRpc2NsYWltZXINCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIGNvbW11bmljYXRpb24gZnJvbSB0aGUgc2VuZGVyIGlzIGNvbmZpZGVudGlhbC4gSXQgaXMg aW50ZW5kZWQgc29sZWx5IGZvciB1c2UgYnkgdGhlIHJlY2lwaWVudCBhbmQgb3RoZXJzIGF1dGhv cml6ZWQgdG8gcmVjZWl2ZSBpdC4gSWYgeW91IGFyZSBub3QgdGhlIHJlY2lwaWVudCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0 aW9uIG9yIHRha2luZyBhY3Rpb24gaW4gcmVsYXRpb24gb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMg aW5mb3JtYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0K DQpUaGlzIGVtYWlsIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIG1hbHdhcmUsIGFu ZCBtYXkgaGF2ZSBiZWVuIGF1dG9tYXRpY2FsbHkgYXJjaGl2ZWQgYnkgTWltZWNhc3QsIGEgbGVh ZGVyIGluIGVtYWlsIHNlY3VyaXR5IGFuZCBjeWJlciByZXNpbGllbmNlLiBNaW1lY2FzdCBpbnRl Z3JhdGVzIGVtYWlsIGRlZmVuc2VzIHdpdGggYnJhbmQgcHJvdGVjdGlvbiwgc2VjdXJpdHkgYXdh cmVuZXNzIHRyYWluaW5nLCB3ZWIgc2VjdXJpdHksIGNvbXBsaWFuY2UgYW5kIG90aGVyIGVzc2Vu dGlhbCBjYXBhYmlsaXRpZXMuIE1pbWVjYXN0IGhlbHBzIHByb3RlY3QgbGFyZ2UgYW5kIHNtYWxs IG9yZ2FuaXphdGlvbnMgZnJvbSBtYWxpY2lvdXMgYWN0aXZpdHksIGh1bWFuIGVycm9yIGFuZCB0 ZWNobm9sb2d5IGZhaWx1cmU7IGFuZCB0byBsZWFkIHRoZSBtb3ZlbWVudCB0b3dhcmQgYnVpbGRp bmcgYSBtb3JlIHJlc2lsaWVudCB3b3JsZC4gVG8gZmluZCBvdXQgbW9yZSwgdmlzaXQgb3VyIHdl YnNpdGUuDQo= --MCBoundary=_12202210807532101 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

-----Original Message-----
From: owner-freebsd-cu= rrent@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf = Of Hans Petter Selasky
Sent: Monday, February 21, 2022 2:48 AM
To: Michael Jung <mikej@paymentallianceintl.com>; freebsd-current <= ;freebsd-current@freebsd.org>
Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/20/22 21:53, Michael Jung wrote:
> Hi!
>
> The box was quite busy at the time. The only odd thing I am aware of<= BR> > and which I do not think is related is I have not been able to expand<= BR> > one of my zpool's. ZFS sees my added draid2:2d:10c:0s vdev but I
> can't seem to force zpool's expansion - my bet this is somehow related=
> to the mirrored special device in the pool even though autoexpand is s= et to 'on' for the pool.
>
> Not asking anyone to solve this, I plan on putting together a "ho= w to
> reproduce" and post to freebsd-fs@ but wanted to note this oddity= .
>
> --mikej
>
> This is a unmodified GENERIC kernel.
>
>
> Unread portion of the kernel message buffer:
> panic: refcount 0xfffff801cc119284 wraparound cpuid =3D 7 time =3D
> 1645382575
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe0119a83c80
> vpanic() at vpanic+0x17f/frame 0xfffffe0119a83cd0
> panic() at panic+0x43/frame 0xfffffe0119a83d30
> fdclose() at fdclose/frame 0xfffffe0119a83dc0
> closefp_impl() at closefp_impl+0x77/frame 0xfffffe0119a83e00
> amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0119a83f30
> fast_syscall_common() at fast_syscall_common+0xf8/frame
> 0xfffffe0119a83f30
> --- syscall (6, FreeBSD ELF64, sys_close), rip =3D 0x3309a531b62a, rsp= =3D
> 0x3309a2802bc8, rbp =3D 0x3309a2803000 ---
> KDB: enter: panic
>

This may be a refcount leak. Are you able to dump "fdp" at:

#16 0xffffffff80bad587 in closefp_impl (fdp=3D0xfffffe012b7c0430, fd=3D4, fp=3D0xfffff801cc119280, td=3D0xfffffe00df8d0560, audit=3Dtrue)
at /usr/src/sys/kern/kern_descrip.c:1300

frame 16
print /x *fdp

--HPS


[root@draid /var/crash]# kgdb kernel.full.0 vmcore.0
GNU gdb (GDB) 11.2 [GDB v11.2 for FreeBSD]
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>=
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word&= quot;...
Reading symbols from kernel.full.0...

Unread portion of the kernel message buffer:
panic: refcount 0xfffff801cc119284 wraparound
cpuid =3D 7
time =3D 1645382575
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0119a83= c80
vpanic() at vpanic+0x17f/frame 0xfffffe0119a83cd0
panic() at panic+0x43/frame 0xfffffe0119a83d30
fdclose() at fdclose/frame 0xfffffe0119a83dc0
closefp_impl() at closefp_impl+0x77/frame 0xfffffe0119a83e00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0119a83f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0119a83f30<= BR> --- syscall (6, FreeBSD ELF64, sys_close), rip =3D 0x3309a531b62a, rsp =3D = 0x3309a2802bc8, rbp =3D 0x3309a2803000 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) = : "n" (offsetof(struct pcpu,

(kgdb) fram 16
#16 0xffffffff80bad587 in closefp_impl (fdp=3D0xfffffe012b7c0430, fd=3D4, f= p=3D0xfffff801cc119280, td=3D0xfffffe00df8d0560, audit=3Dtrue) at /usr/src/= sys/kern/kern_descrip.c:1300
1300 error =3D closef(fp, td);

(kgdb) print /x *fdp
$1 =3D {fd_files =3D 0xfffffe00df6d9000, fd_map =3D 0xfffff80001bb1800, fd_= freefile =3D 0x4, fd_refcnt =3D 0x1, fd_holdcnt =3D 0x1, fd_sx =3D {lock_ob= ject =3D {lo_name =3D 0xffffffff8124f6a9, lo_flags =3D 0x2330000, lo_data = =3D 0x0,
lo_witness =3D 0xfffff8041eb94000}, sx_lock =3D 0x1}, fd_kqlist =3D {= tqh_first =3D 0x0, tqh_last =3D 0x0}, fd_holdleaderscount =3D 0x0, fd_holdl= eaderswakeup =3D 0x0}
(kgdb)




CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245


<= b>Disclaimer

The information contained in this communication from the sender i= s confidential. It is intended solely for use by the recipient and others a= uthorized to receive it. If you are not the recipient, you are hereby notif= ied that any disclosure, copying, distribution or taking action in relation= of the contents of this information is strictly prohibited and may be unla= wful.

This email has been scanned for viruses and malware, and may h= ave been automatically archived by Mimecast, a leader in email security and= cyber resilience. Mimecast integrates email defenses with brand protection= , security awareness training, web security, compliance and other essential= capabilities. Mimecast helps protect large and small organizations from ma= licious activity, human error and technology failure; and to lead the movem= ent toward building a more resilient world. To find out more, visit our web= site.

--MCBoundary=_12202210807532101-- From nobody Mon Feb 21 13:52:41 2022 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 EB549183D8D4 for ; Mon, 21 Feb 2022 13:52:56 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4K2NzW6K0wz3jcn for ; Mon, 21 Feb 2022 13:52:55 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 74E64260501; Mon, 21 Feb 2022 14:52:54 +0100 (CET) Message-ID: Date: Mon, 21 Feb 2022 14:52:41 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: New panic in main-n253273-a52d8d4a6c6: Content-Language: en-US To: Michael Jung , freebsd-current References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> From: Hans Petter Selasky In-Reply-To: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K2NzW6K0wz3jcn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.20 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.10)[0.100]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2/21/22 14:07, Michael Jung wrote: > (kgdb) fram 16 > #16 0xffffffff80bad587 in closefp_impl (fdp=0xfffffe012b7c0430, fd=4, fp=0xfffff801cc119280, td=0xfffffe00df8d0560, audit=true) at /usr/src/sys/kern/kern_descrip.c:1300 > 1300 error = closef(fp, td); > > (kgdb) print /x *fdp > $1 = {fd_files = 0xfffffe00df6d9000, fd_map = 0xfffff80001bb1800, fd_freefile = 0x4, fd_refcnt = 0x1, fd_holdcnt = 0x1, fd_sx = {lock_object = {lo_name = 0xffffffff8124f6a9, lo_flags = 0x2330000, lo_data = 0x0, > lo_witness = 0xfffff8041eb94000}, sx_lock = 0x1}, fd_kqlist = {tqh_first = 0x0, tqh_last = 0x0}, fd_holdleaderscount = 0x0, fd_holdleaderswakeup = 0x0} > (kgdb) Can you also: print /x *fp in the same frame? --HPS From nobody Mon Feb 21 15:03:44 2022 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 9BFFE19CDC3B for ; Mon, 21 Feb 2022 15:03:56 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2QYR5Dc3z4S5T for ; Mon, 21 Feb 2022 15:03:55 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 62F3D8D4A156; Mon, 21 Feb 2022 15:03:47 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 50123E707BC; Mon, 21 Feb 2022 15:03:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id N4AV5G-3KMtX; Mon, 21 Feb 2022 15:03:45 +0000 (UTC) Received: from [169.254.226.220] (unknown [IPv6:fde9:577b:c1a9:4902:3ca2:aeae:a4ad:3884]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 1BEECE707B7; Mon, 21 Feb 2022 15:03:44 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Hans Petter Selasky" Cc: "FreeBSD Current" Subject: Re: pxeboot binary is too big on FreeBSD (>640KBytes) Date: Mon, 21 Feb 2022 15:03:44 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: In-Reply-To: <6984fd5d-ae58-11a4-0d21-a8695b0c77f7@selasky.org> References: <6984fd5d-ae58-11a4-0d21-a8695b0c77f7@selasky.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; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4K2QYR5Dc3z4S5T X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-0.46 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; FROM_HAS_DN(0.00)[]; R_MISSING_CHARSET(2.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.68)[-0.679]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 21 Feb 2022, at 7:43, Hans Petter Selasky wrote: > FYI: > > After a lot of digging trying everything, I found that the pxeboot and = > loader.efi was too big simply due to ZFS support. > > So I did this after buildworld: > > cd /usr/src/stand > make WITHOUT_LOADER_ZFS=3DYES clean > make WITHOUT_LOADER_ZFS=3DYES all > make WITHOUT_LOADER_ZFS=3DYES install > > And now it works, with my old GigaByte mainboard! > > Why should pxeboot have ZFS support? > > https://forums.freebsd.org/threads/problem-with-isc-dhcpd-and-diskless-= booting.82199/ Well actually it started with a lua update; pxeboot 4th is not (or was = not) too big and still working. See PR 257018 . From nobody Mon Feb 21 15:19:58 2022 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 BE3B919D0DC9 for ; Mon, 21 Feb 2022 15:20:16 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-ztdg10021901.me.com (pv50p00im-ztdg10021901.me.com [17.58.6.55]) (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 4K2QwJ0Q84z4Vfr for ; Mon, 21 Feb 2022 15:20:16 +0000 (UTC) (envelope-from tsoome@me.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1645456809; bh=uY+pi/R/dR/4hkDwoz4gw+N8nvgz6iU39f/c8KIBhbM=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=uHhvgEzzwUw/vh3/FNsIrus0uWDrEI7BtjbFCctRadZJWPuN87mlxNbemOx1yC5pF oUnQt6nwa+BgOgheFQeNxg/vEgWmu5DG5Xsze5wgdKCx0GxpIbDegJyxJu8u3IMQlA 4VROzVrTKlghCtNpVd0cUu1PlE6UZ8QgReqRbczoZda7ng+x9+FjpXhhNm4Fy53M0d gfBKQNDms07yfSNqLI9xe+es1u3W/Vc65Fi7i7VUA7fserMJP4DVDLtjrKTCjtmXca +AqL5uTZLulwb2Af9tVg1Ryxj20cq7bqGwHq+ojfExP8zbcY34AtW78K7FqoXqXqO3 +WlxTmUpzd8cw== Received: from smtpclient.apple (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-ztdg10021901.me.com (Postfix) with ESMTPSA id C0D9181B49; Mon, 21 Feb 2022 15:20:07 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Subject: Re: pxeboot binary is too big on FreeBSD (>640KBytes) From: Toomas Soome In-Reply-To: <6984fd5d-ae58-11a4-0d21-a8695b0c77f7@selasky.org> Date: Mon, 21 Feb 2022 17:19:58 +0200 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <02586EFB-0BB5-46BF-9EE5-28623D20EFD3@me.com> References: <6984fd5d-ae58-11a4-0d21-a8695b0c77f7@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.816 definitions=2022-02-21_07:2022-02-21,2022-02-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2009150000 definitions=main-2202210090 X-Rspamd-Queue-Id: 4K2QwJ0Q84z4Vfr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=uHhvgEzz; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.55 as permitted sender) smtp.mailfrom=tsoome@me.com X-Spamd-Result: default: False [-3.57 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; RWL_MAILSPIKE_EXCELLENT(0.00)[17.58.6.55:from]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.55:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[me.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.973]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 21. Feb 2022, at 09:43, Hans Petter Selasky = wrote: >=20 > FYI: >=20 > After a lot of digging trying everything, I found that the pxeboot and = loader.efi was too big simply due to ZFS support. >=20 > So I did this after buildworld: >=20 > cd /usr/src/stand > make WITHOUT_LOADER_ZFS=3DYES clean > make WITHOUT_LOADER_ZFS=3DYES all > make WITHOUT_LOADER_ZFS=3DYES install >=20 > And now it works, with my old GigaByte mainboard! >=20 > Why should pxeboot have ZFS support? >=20 > = https://forums.freebsd.org/threads/problem-with-isc-dhcpd-and-diskless-boo= ting.82199/ >=20 > =E2=80=94HPS >=20 Well, the feature X can be helpful for recovery purposes. The root cause = is not the feature X itself, but the size limit. And the unfortunate = fact, the size limit is not fixed, but depends on the system. Therefore = there are two options - either to fix the size limit or drop option X = from default build =E2=80=94 at least till the size limit is fixed (or = support for BIOS will be dropped). rgds, toomas= From nobody Mon Feb 21 17:18:41 2022 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 8889E19CC64D for ; Mon, 21 Feb 2022 17:18:49 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2TY42T2cz3CHd for ; Mon, 21 Feb 2022 17:18:48 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 21L7shCZ014781; Mon, 21 Feb 2022 09:18:47 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-transfer-encoding : date : message-id; s=PPS1017; bh=0kX7vKp2Ln7IpfmZ5SX/4o7J9prxYez4BwpwmDNvomE=; b=RIDFsKC3fQ7xslNj1s5u7IPFKibU6b1AHkeNUHpt4Yga97YANZuPCeBZrblEntGpdfDI g/PWHN/xNbAzb4qjC5VfBKT4z1aaOfgNdCuu7vrZFWLwFnyR94J9TsVa3P1mdx0MxfpI GDKt1IEigLbkvoAdL0VCVDJWhXFllFroR8Nqn1M6DWfPc1gyfF9PRtFhlwsZumvje4Il oVV3No0W5xJsDNh0IVdOQIH93LG57Pp9fLudiAC9qR6xKwqoYAVtNrUTzpnsFj1d72Ug q3bAD5+b2md9VIrQwcVxP2KTRkHleo3LJLBpLSIfqS7zPTGLEb3eIS5UDz77GG+2cxl/ Gw== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2168.outbound.protection.outlook.com [104.47.59.168]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3ec6rn0uem-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Feb 2022 09:18:47 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GV6KmELeaw5ZWIode+O4ieKvSNiDhGQamDsb8ilzWeEleeqILafuEerjeikIujk4fogalvWQhXbe8r+bNOdY+JlHL7D3C+tRmg7jc4ZWzFEQOdVRstfbb3OY0aSbkJDnGIEZWCB1HkEkad+8c2hueuF/ioz0l6bJUD+CXL/S3tyn82ImGK6/3qgT31tZUihzCU3xYaT1Itnq9ACUZ2woXnJ5/UFX3WhHIs0rWMv2UkgLgAQXewuaZn4DdcPno7ECICxIEt7Bp+w5EiFW9HUY7+Bqkw+H3iS8qkXqLF3oIV0DDI4WvCp7lU6LUkaMRrjmQ434vUxP6+AGSwnaY8BoFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0kX7vKp2Ln7IpfmZ5SX/4o7J9prxYez4BwpwmDNvomE=; b=F7xP4JZZ3Smc9pFVGcEgSBs3ZowMtT4+2jzFBJK7eZiAKKp0G09MBbPFfn7ZmCbgrgYrV5gcQp9yimjL4nj4VFdKuIFpBlnYgxtRdPa+2LSEkCk/h6nDETw+3FFrL0itDlz6RuCQGz+kHV2Lx80kHS4My2Dj6KQIHW8TDGr1il+0kytaxZXID9OyNa71qckvFBpQAPDMTbzKqxhdIW+qTUwyKlQ2ChfkjVEqH1fr6shOTb6j4CbJupRWf9BwP4U5LrRFiXtxG0t7pec3xOEMEj5ZNlP5xh0ThIfimTWms5zb2A2AhuummU5S5ugVL5mn4Hx14CurS6l71GnTE3O9bQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.242.14) smtp.rcpttodomain=selasky.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0kX7vKp2Ln7IpfmZ5SX/4o7J9prxYez4BwpwmDNvomE=; b=BpONeCLqwwd6+6QmXZHXNToVbD0NZh6ZoNA6qg+ReClCn8VYXrJSAt2T5ISrrCznPyZ5XQdJ2iin7S6+98z3Ml3VHXfEl0/uavj60V3xq8vF+UxpjiFc3SLeMBm58PBtX0SlwC7Ugl5OfqisB5mtjTAUGgMCda0h9K7nIi8WJPI= Received: from BN9PR03CA0739.namprd03.prod.outlook.com (2603:10b6:408:110::24) by DM6PR05MB6105.namprd05.prod.outlook.com (2603:10b6:5:11c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.21; Mon, 21 Feb 2022 17:18:44 +0000 Received: from BN8NAM12FT062.eop-nam12.prod.protection.outlook.com (2603:10b6:408:110:cafe::1b) by BN9PR03CA0739.outlook.office365.com (2603:10b6:408:110::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.14 via Frontend Transport; Mon, 21 Feb 2022 17:18:44 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.242.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.242.14) by BN8NAM12FT062.mail.protection.outlook.com (10.13.183.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.9 via Frontend Transport; Mon, 21 Feb 2022 17:18:43 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20; Mon, 21 Feb 2022 11:18:42 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20 via Frontend Transport; Mon, 21 Feb 2022 11:18:42 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 21LHIfAH028310; Mon, 21 Feb 2022 09:18:41 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 948C4A23B2; Mon, 21 Feb 2022 09:18:41 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 94160A2254; Mon, 21 Feb 2022 09:18:41 -0800 (PST) To: Toomas Soome CC: Hans Petter Selasky , FreeBSD Current , Subject: Re: pxeboot binary is too big on FreeBSD (>640KBytes) In-Reply-To: <02586EFB-0BB5-46BF-9EE5-28623D20EFD3@me.com> References: <6984fd5d-ae58-11a4-0d21-a8695b0c77f7@selasky.org> <02586EFB-0BB5-46BF-9EE5-28623D20EFD3@me.com> Comments: In-reply-to: Toomas Soome message dated "Mon, 21 Feb 2022 17:19:58 +0200." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.2 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Feb 2022 09:18:41 -0800 Message-ID: <16051.1645463921@kaos.jnpr.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 17418423-6998-41f2-d575-08d9f55e3641 X-MS-TrafficTypeDiagnostic: DM6PR05MB6105:EE_ X-MS-Exchange-AtpMessageProperties: SA|SL X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: M7php6lOMRu3TaD0PtFXpRpy+g0GZALZQ1ipOEOwSjYvCFHcVwwKe658TucJoK34TyxQ9VFkcNRAefj0bhVtCUrP8RQFToiBv4/8qycMRCea+u2BO1DesomUIiWoG5mq5SkjNgb9QbD/7XluN3nIPYaR49PGFC4POM8nRbne2SlEDhRNE/PXewFLhyWWDPFkGb7cSW2UUUaar0xCKbvIp9q2wJxNDE8WSX2eeZcGurHsTgmxwZOWjFr9xh+NxbHI4VrnWr4+Fj3rCskSXmF2pIB56fPfx7bbi4vTOwpwvdBVYqBp2UVje6Lu84ABJoFaxwuI2PMP4s4+edGeWunuBpjWzSc2BLUz0FF3JsO67RvkljYBKQT3gQNGGsDuj0xqzxmMH9fm3/GBi5+YeyTaYMGUEonsAwW/YR4Vg34eOEuajBg1wthZu0dF0QvcT2m7LIYC/RuGPfYmQ0ReU0iVfxK7UAW2lfe3NaEHmV7OmYlQF1g6QufSa31xOoGpo3aaMF0lVC7xO/Le7DpW+mXZHF15SiJFSfwR+QZ86YgniAFrqSVZ1sJSomQDy0V38jcmzH4nwAOiQ+eaTODBNAo8Z16nYjpaVhkEHQ2QBg0v0lsP2xVleQeAvClfwu0JSbuMEpWdh4aKmfbQyfTcGg7SvIACpO3RseDQxRFZ1Px6NWJcqZh7zpLnb9BMKHm98S/zUKZMp5tt07jj/JeeNO18ruPcvWr3cMFeOFNAJuy9199FMJ68JWZ+BDfUJ/3XafrLrgpjuZGzzsw3CaYogO6aaluf9T/8k/4hhw522v2o7A4= X-Forefront-Antispam-Report: CIP:66.129.242.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230001)(4636009)(46966006)(40470700004)(36840700001)(83380400001)(54906003)(186003)(26005)(9686003)(7696005)(316002)(40460700003)(6916009)(47076005)(2906002)(82310400004)(70586007)(4326008)(356005)(4744005)(81166007)(8936002)(86362001)(34070700002)(8676002)(36860700001)(508600001)(6266002)(7126003)(107886003)(55016003)(336012)(5660300002)(70206006)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Feb 2022 17:18:43.4244 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 17418423-6998-41f2-d575-08d9f55e3641 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.242.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM12FT062.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB6105 X-Proofpoint-ORIG-GUID: Y282ZLEOycItgzOm5zMqlK_as-FRpAso X-Proofpoint-GUID: Y282ZLEOycItgzOm5zMqlK_as-FRpAso X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-21_08,2022-02-21_02,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 mlxlogscore=641 phishscore=0 spamscore=0 priorityscore=1501 bulkscore=0 lowpriorityscore=0 suspectscore=0 impostorscore=0 adultscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202210102 X-Rspamd-Queue-Id: 4K2TY42T2cz3CHd X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b=RIDFsKC3; dkim=pass header.d=juniper.net header.s=selector1 header.b=BpONeCLq; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=juniper.net; spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 67.231.152.164 as permitted sender) smtp.mailfrom=sjg@juniper.net X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; FREEFALL_USER(0.00)[sjg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:67.231.152.164]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[juniper.net:+]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; RCVD_IN_DNSWL_NONE(0.00)[104.47.59.168:received]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]; RCVD_COUNT_SEVEN(0.00)[10]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.152.164:from] X-ThisMailContainsUnwantedMimeParts: N Toomas Soome wrote: > > Why should pxeboot have ZFS support? >=20 > Well, the feature X can be helpful for recovery purposes. The root > cause is not the feature X itself, but the size limit. And the > unfortunate fact, the size limit is not fixed, but depends on the > system. Therefore there are two options - either to fix the size limit > or drop option X from default build =E2=80=94 at least till the size limi= t is > fixed (or support for BIOS will be dropped). Or just build separate variants. As Bjoern said Lua is probably the straw breaking the cammel's back but I think it reasonable to assume that a system that has the resources to support ZFS does not have an ancient BIOS ? Thus a non-ZFS version could work for older systems while those without limitation can use the kitchen-sink version. From nobody Mon Feb 21 17:43:06 2022 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 26A9519D1523 for ; Mon, 21 Feb 2022 17:43:25 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st43p00im-zteg10072001.me.com (st43p00im-zteg10072001.me.com [17.58.63.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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2V5S3V3Sz3Gcj for ; Mon, 21 Feb 2022 17:43:24 +0000 (UTC) (envelope-from tsoome@me.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1645465398; bh=pkHvWTuOKyuimlHbAicXVBr+K7KIVI7ouERhoYEXWNA=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=UDtl0N7L1JorN0D+s/A6uiBz9w9zUaAZXA22W10gJ3vhk3GN2MKBdaYb7mB6uDc8x zQy3VxuP2x1k1sMG1lW3FaI0vIWJxmnusS1cWf9g8B+M+lSlLiKd7ya7quX1ITCY+3 6q+8V8clGz6lE+PqdhqBiZj2rmt3kJcbJiRCBzA3ggSmUPL4qtiqLUOe2c1zIC+9he 8E4gYpiHZFp8OqT8K5JKzbFLQhSt5MfPihgtcaB2GuamhHqDqdPVtnfl/P4wmqU5hn k//BgL0D76ozaUgXHXGOqDa0lgoUAS0HFm8nVZaj5ku8V/cXpQYlXwO15TtXjQteyN CRQ/K9QW+8lHQ== Received: from smtpclient.apple (148-52-235-80.sta.estpak.ee [80.235.52.148]) by st43p00im-zteg10072001.me.com (Postfix) with ESMTPSA id 5210EB40AA0; Mon, 21 Feb 2022 17:43:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Subject: Re: pxeboot binary is too big on FreeBSD (>640KBytes) From: Toomas Soome In-Reply-To: <16051.1645463921@kaos.jnpr.net> Date: Mon, 21 Feb 2022 19:43:06 +0200 Cc: Hans Petter Selasky , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <9ADBF2DA-0D00-40C0-A2CA-AFBCA7E5F3A4@me.com> References: <6984fd5d-ae58-11a4-0d21-a8695b0c77f7@selasky.org> <02586EFB-0BB5-46BF-9EE5-28623D20EFD3@me.com> <16051.1645463921@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.572,17.0.605.474.0000000_definitions?= =?UTF-8?Q?=3D2020-02-14=5F11:2020-02-14=5F02,2020-02-14=5F11,2020-01-23?= =?UTF-8?Q?=5F02_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 suspectscore=0 clxscore=1011 spamscore=0 malwarescore=0 adultscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2202210105 X-Rspamd-Queue-Id: 4K2V5S3V3Sz3Gcj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=UDtl0N7L; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.63.167 as permitted sender) smtp.mailfrom=tsoome@me.com X-Spamd-Result: default: False [-3.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; RWL_MAILSPIKE_EXCELLENT(0.00)[17.58.63.167:from]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[me.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.63.0/24, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.63.167:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 21. Feb 2022, at 19:18, Simon J. Gerraty wrote: >=20 > Toomas Soome wrote: >>> Why should pxeboot have ZFS support? >>=20 >> Well, the feature X can be helpful for recovery purposes. The root >> cause is not the feature X itself, but the size limit. And the >> unfortunate fact, the size limit is not fixed, but depends on the >> system. Therefore there are two options - either to fix the size = limit >> or drop option X from default build =E2=80=94 at least till the size = limit is >> fixed (or support for BIOS will be dropped). >=20 > Or just build separate variants. > As Bjoern said Lua is probably the straw breaking the cammel's back > but I think it reasonable to assume that a system that has the = resources > to support ZFS does not have an ancient BIOS ? >=20 > Thus a non-ZFS version could work for older systems > while those without limitation can use the kitchen-sink version. It is not even about =E2=80=9Cancient=E2=80=9D BIOS, the problem is, PXE = stack does also need resources and it is easier to consume low memory = (just as loader does).=20 rgds, toomas= From nobody Mon Feb 21 21:05:21 2022 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 C864319DF365 for ; Mon, 21 Feb 2022 21:00:50 +0000 (UTC) (envelope-from pj@smo.de) Received: from mail.adebahr.de (mail.adebahr.de [185.66.179.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.adebahr.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2ZTF6sY1z4Trp for ; Mon, 21 Feb 2022 21:00:49 +0000 (UTC) (envelope-from pj@smo.de) Received: from localhost (localhost [127.0.0.1]) by mail.adebahr.de (Postfix) with ESMTP id D2DF260327120 for ; Mon, 21 Feb 2022 22:00:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=smo.de; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject :user-agent:mime-version:date:date:message-id; s=mail; t= 1645477241; x=1647291642; bh=++mjs54O6uLXgfj+UVaiXcor880jlh03arQ eDMx7ap8=; b=z9njQ5pfBKPwr9kB9pOpqfEy0RRciFHxZ3oCriL6zGo9+tRBeCl xt3j5w0+Gxc7yTkP65ijspkCw7v2ZPnlUMr4/hi9unsIrDgYpkD+eQEJhLb4h32G cnQpBncCr8JBpgDZPwf4c9ns6Ff0mh57mq3ekYsOGxW7L0PRcFHCC2hw= Received: from mail.adebahr.de ([127.0.0.1]) by localhost (mail.adebahr.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id ZOe3Zqu75A0Q for ; Mon, 21 Feb 2022 22:00:41 +0100 (CET) Received: from [192.168.153.212] (p4fe02b24.dip0.t-ipconnect.de [79.224.43.36]) by mail.adebahr.de (Postfix) with ESMTPSA id 9F8A960327128 for ; Mon, 21 Feb 2022 22:00:41 +0100 (CET) Message-ID: <0c2419e7-925f-7648-865b-86328009cf29@smo.de> Date: Mon, 21 Feb 2022 22:05:21 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: pxeboot binary is too big on FreeBSD (>640KBytes) Content-Language: en-US To: freebsd-current@freebsd.org References: <6984fd5d-ae58-11a4-0d21-a8695b0c77f7@selasky.org> <02586EFB-0BB5-46BF-9EE5-28623D20EFD3@me.com> <16051.1645463921@kaos.jnpr.net> From: Philipp Ost In-Reply-To: <16051.1645463921@kaos.jnpr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K2ZTF6sY1z4Trp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smo.de header.s=mail header.b=z9njQ5pf; dmarc=pass (policy=reject) header.from=smo.de; spf=pass (mx1.freebsd.org: domain of pj@smo.de designates 185.66.179.123 as permitted sender) smtp.mailfrom=pj@smo.de X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[smo.de:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.66.179.96/27]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[smo.de:+]; DMARC_POLICY_ALLOW(-0.50)[smo.de,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:198930, ipnet:185.66.176.0/22, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[79.224.43.36:received] X-ThisMailContainsUnwantedMimeParts: N On 2/21/22 18:18, Simon J. Gerraty wrote: > Toomas Soome wrote: >>> Why should pxeboot have ZFS support? >> >> Well, the feature X can be helpful for recovery purposes. The root >> cause is not the feature X itself, but the size limit. And the >> unfortunate fact, the size limit is not fixed, but depends on the >> system. Therefore there are two options - either to fix the size limit >> or drop option X from default build — at least till the size limit is >> fixed (or support for BIOS will be dropped). > > Or just build separate variants. > As Bjoern said Lua is probably the straw breaking the cammel's back > but I think it reasonable to assume that a system that has the resources > to support ZFS does not have an ancient BIOS ? I have several machines in use which are capable of supporting ZFS just fine and all of these have a BIOS. Just saying. ;-) From nobody Mon Feb 21 21:28:02 2022 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 C756219E558C for ; Mon, 21 Feb 2022 21:28:05 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2b4j0Sslz4bVV for ; Mon, 21 Feb 2022 21:28:05 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qk1-x736.google.com with SMTP id b13so9012551qkj.12 for ; Mon, 21 Feb 2022 13:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=iTx8yELNhcmL3qFyXHDhGgOg3xODCFF3DWVkp7onfVw=; b=eodSAam4/4ZgEDUaBtoQuKQnSTxzVIAlz5wJw6VNF+9w5c8ciENeu84oSmSM7931JU qrCdGp36ksilT3YNgtNx12/z/l/dcPRWlvmOIFX5YGkLtRJR86OauMPVjn+omy+E5N9b J0n/3k+hNwWHWbhuF9wkAJZEt5somlMDiggyX9Xj2tXfwnfG2q5VdAZAcMGklMYmevB+ fWAx4JhyFRMx6r2yig/1VvgljsNoaJD7W64TxwcanHQXcxgny9gUl0wPVg8Gg2A+3wwI UQkXOs/qWF3H04IyPAkS3pL51H9SaduXFrwp4xnie+9PpdQ0iMlS5+fKgEB90tj95ye5 D4yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=iTx8yELNhcmL3qFyXHDhGgOg3xODCFF3DWVkp7onfVw=; b=sC+cO73A01PuqNfWYqwgcPrf2E7obvkL03Mc41Y7P2hE3C/PUFfadJC0w33B42/yqQ l+8Erh8JZGSllN+o0NJRoF0zICuKzzCQ1W4T03DgiguFdBguz8PSbF32jXtTc4aWhEWa hMjYM75A4m26SMVWrbQk2LunCyn/ZPCQUJSjOQgo07zcfPrVOQRBYk1VndPDUIPJ//G4 Pldn1dAJ/QhR2dn/Go+nxkV84N+D/Ac9PHLlqfYfBOkB+I4o9muSi83VTXbTTpKW6v8w mN2yi+39a3hfPXL64dLYa4KdIrtgaq5jFcj0TtK7FWUjvEHnElQlREOn9uYFYbxjWRKm TXcA== X-Gm-Message-State: AOAM533liUKW2QRy7ZPKaq5rv6gkLPSA2UYEvYOcZ0NleWgSB3AVtzGs r49GehgWz3QKFWnspeJdwGnxwaVJ36k= X-Google-Smtp-Source: ABdhPJxKD0pjuzfV5A19hCIKDvlYKgaCOJbAU8//Oh6q6HG4GAeTK/drI7GUw2qFJCT76D8qv8YNfg== X-Received: by 2002:a05:620a:3de:b0:60d:dd0a:4d0c with SMTP id r30-20020a05620a03de00b0060ddd0a4d0cmr12728810qkm.246.1645478884412; Mon, 21 Feb 2022 13:28:04 -0800 (PST) Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id o19sm30659646qta.19.2022.02.21.13.28.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Feb 2022 13:28:03 -0800 (PST) Message-ID: Date: Mon, 21 Feb 2022 16:28:02 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: pxeboot binary is too big on FreeBSD (>640KBytes) Content-Language: en-US To: Toomas Soome , "Simon J. Gerraty" Cc: Hans Petter Selasky , FreeBSD Current References: <6984fd5d-ae58-11a4-0d21-a8695b0c77f7@selasky.org> <02586EFB-0BB5-46BF-9EE5-28623D20EFD3@me.com> <16051.1645463921@kaos.jnpr.net> <9ADBF2DA-0D00-40C0-A2CA-AFBCA7E5F3A4@me.com> From: Alexander Motin In-Reply-To: <9ADBF2DA-0D00-40C0-A2CA-AFBCA7E5F3A4@me.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K2b4j0Sslz4bVV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=eodSAam4; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::736 as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-2.79 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.59)[-0.586]; FREEMAIL_TO(0.00)[me.com,juniper.net]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 21.02.2022 12:43, Toomas Soome wrote: >> On 21. Feb 2022, at 19:18, Simon J. Gerraty wrote: >> Toomas Soome wrote: >>>> Why should pxeboot have ZFS support? >>> >>> Well, the feature X can be helpful for recovery purposes. The root >>> cause is not the feature X itself, but the size limit. And the >>> unfortunate fact, the size limit is not fixed, but depends on the >>> system. Therefore there are two options - either to fix the size limit >>> or drop option X from default build — at least till the size limit is >>> fixed (or support for BIOS will be dropped). >> >> Or just build separate variants. >> As Bjoern said Lua is probably the straw breaking the cammel's back >> but I think it reasonable to assume that a system that has the resources >> to support ZFS does not have an ancient BIOS ? >> >> Thus a non-ZFS version could work for older systems >> while those without limitation can use the kitchen-sink version. > > It is not even about “ancient†BIOS, the problem is, PXE stack does also need resources and it is easier to consume low memory (just as loader does). I've recently switched all my lab systems to UEFI PXE. It "just works" for me using normal loader.efi of 872KB. -- Alexander Motin From nobody Mon Feb 21 23:21:39 2022 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 D918919D46F9 for ; Mon, 21 Feb 2022 23:21:51 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from us-smtp-delivery-197.mimecast.com (us-smtp-delivery-197.mimecast.com [170.10.129.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mimecast.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2dby4Pcjz3CP6 for ; Mon, 21 Feb 2022 23:21:50 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from MAIL-HUB.pai.local (175.158.26.216.gopai.com [216.26.158.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-529-EUIHxVYQOzaPTKdg8lq6Og-1; Mon, 21 Feb 2022 18:21:40 -0500 X-MC-Unique: EUIHxVYQOzaPTKdg8lq6Og-1 Received: from MAIL-HUB.pai.local (10.10.0.250) by MAIL-HUB.pai.local (10.10.0.250) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Mon, 21 Feb 2022 18:21:39 -0500 Received: from MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8]) by MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8%15]) with mapi id 15.00.1497.028; Mon, 21 Feb 2022 18:21:39 -0500 From: Michael Jung To: Hans Petter Selasky , freebsd-current Subject: RE: New panic in main-n253273-a52d8d4a6c6: Thread-Topic: New panic in main-n253273-a52d8d4a6c6: Thread-Index: AdgmmC6h1TNd/HB0TUWCzt+asldIhgAiSNWAAACbjEAADBz0gAAJX15A Date: Mon, 21 Feb 2022 23:21:39 +0000 Message-ID: <8e780c77416b48e7bf79186cc77fe5c5@MAIL-HUB.pai.local> References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.0.59] x-c2processedorg: 474f336e-f930-49ec-9717-e3226b5b6e6e 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-Mimecast-Spam-Score: 0 X-Mimecast-Originator: paymentallianceintl.com Content-Type: multipart/alternative; boundary="MCBoundary=_12202211821420921" X-Rspamd-Queue-Id: 4K2dby4Pcjz3CP6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=paymentallianceintl.com; spf=pass (mx1.freebsd.org: domain of mikej@paymentallianceintl.com designates 170.10.129.197 as permitted sender) smtp.mailfrom=mikej@paymentallianceintl.com X-Spamd-Result: default: False [-1.22 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:170.10.129.0/24]; RCVD_IN_DNSWL_LOW(-0.10)[170.10.129.197:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.57)[0.574]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[paymentallianceintl.com,none]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:30031, ipnet:170.10.128.0/23, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[170.10.129.197:from] X-ThisMailContainsUnwantedMimeParts: N --MCBoundary=_12202211821420921 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIYW5zIFBldHRlciBTZWxhc2t5 IFttYWlsdG86aHBzQHNlbGFza3kub3JnXQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyMSwgMjAy MiA4OjUzIEFNDQpUbzogTWljaGFlbCBKdW5nIDxtaWtlakBwYXltZW50YWxsaWFuY2VpbnRsLmNv bT47IGZyZWVic2QtY3VycmVudCA8ZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnPg0KU3ViamVj dDogUmU6IE5ldyBwYW5pYyBpbiBtYWluLW4yNTMyNzMtYTUyZDhkNGE2YzY6DQoNCk9uIDIvMjEv MjIgMTQ6MDcsIE1pY2hhZWwgSnVuZyB3cm90ZToNCj4gKGtnZGIpIGZyYW0gMTYNCj4gIzE2IDB4 ZmZmZmZmZmY4MGJhZDU4NyBpbiBjbG9zZWZwX2ltcGwgKGZkcD0weGZmZmZmZTAxMmI3YzA0MzAs IGZkPTQsIGZwPTB4ZmZmZmY4MDFjYzExOTI4MCwgdGQ9MHhmZmZmZmUwMGRmOGQwNTYwLCBhdWRp dD10cnVlKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoxMzAwDQo+IDEzMDAg ICAgICAgICAgICBlcnJvciA9IGNsb3NlZihmcCwgdGQpOw0KPg0KPiAoa2dkYikgcHJpbnQgL3gg KmZkcA0KPiAkMSA9IHtmZF9maWxlcyA9IDB4ZmZmZmZlMDBkZjZkOTAwMCwgZmRfbWFwID0gMHhm ZmZmZjgwMDAxYmIxODAwLCBmZF9mcmVlZmlsZSA9IDB4NCwgZmRfcmVmY250ID0gMHgxLCBmZF9o b2xkY250ID0gMHgxLCBmZF9zeCA9IHtsb2NrX29iamVjdCA9IHtsb19uYW1lID0gMHhmZmZmZmZm ZjgxMjRmNmE5LCBsb19mbGFncyA9IDB4MjMzMDAwMCwgbG9fZGF0YSA9IDB4MCwNCj4gICAgICAg IGxvX3dpdG5lc3MgPSAweGZmZmZmODA0MWViOTQwMDB9LCBzeF9sb2NrID0gMHgxfSwgZmRfa3Fs aXN0ID0ge3RxaF9maXJzdCA9IDB4MCwgdHFoX2xhc3QgPSAweDB9LCBmZF9ob2xkbGVhZGVyc2Nv dW50ID0gMHgwLCBmZF9ob2xkbGVhZGVyc3dha2V1cCA9IDB4MH0NCj4gKGtnZGIpDQoNCkNhbiB5 b3UgYWxzbzoNCg0KcHJpbnQgL3ggKmZwDQoNCmluIHRoZSBzYW1lIGZyYW1lPw0KDQotLUhQUw0K DQoNCg0KVW5yZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5lbCBtZXNzYWdlIGJ1ZmZlcjoNCnBhbmlj OiByZWZjb3VudCAweGZmZmZmODAxY2MxMTkyODQgd3JhcGFyb3VuZA0KY3B1aWQgPSA3DQp0aW1l ID0gMTY0NTM4MjU3NQ0KS0RCOiBzdGFjayBiYWNrdHJhY2U6DQpkYl90cmFjZV9zZWxmX3dyYXBw ZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyYi9mcmFtZSAweGZmZmZmZTAxMTlhODNj ODANCnZwYW5pYygpIGF0IHZwYW5pYysweDE3Zi9mcmFtZSAweGZmZmZmZTAxMTlhODNjZDANCnBh bmljKCkgYXQgcGFuaWMrMHg0My9mcmFtZSAweGZmZmZmZTAxMTlhODNkMzANCmZkY2xvc2UoKSBh dCBmZGNsb3NlL2ZyYW1lIDB4ZmZmZmZlMDExOWE4M2RjMA0KY2xvc2VmcF9pbXBsKCkgYXQgY2xv c2VmcF9pbXBsKzB4NzcvZnJhbWUgMHhmZmZmZmUwMTE5YTgzZTAwDQphbWQ2NF9zeXNjYWxsKCkg YXQgYW1kNjRfc3lzY2FsbCsweDEyZS9mcmFtZSAweGZmZmZmZTAxMTlhODNmMzANCmZhc3Rfc3lz Y2FsbF9jb21tb24oKSBhdCBmYXN0X3N5c2NhbGxfY29tbW9uKzB4ZjgvZnJhbWUgMHhmZmZmZmUw MTE5YTgzZjMwDQotLS0gc3lzY2FsbCAoNiwgRnJlZUJTRCBFTEY2NCwgc3lzX2Nsb3NlKSwgcmlw ID0gMHgzMzA5YTUzMWI2MmEsIHJzcCA9IDB4MzMwOWEyODAyYmM4LCByYnAgPSAweDMzMDlhMjgw MzAwMCAtLS0NCktEQjogZW50ZXI6IHBhbmljDQoNCl9fY3VydGhyZWFkICgpIGF0IC91c3Ivc3Jj L3N5cy9hbWQ2NC9pbmNsdWRlL3BjcHVfYXV4Lmg6NTUNCjU1ICAgICAgICAgICAgICBfX2FzbSgi bW92cSAlJWdzOiVQMSwlMCIgOiAiPXIiICh0ZCkgOiAibiIgKG9mZnNldG9mKHN0cnVjdCBwY3B1 LA0KDQoNCihrZ2RiKSBmcmFtZSAxNg0KIzE2IDB4ZmZmZmZmZmY4MGJhZDU4NyBpbiBjbG9zZWZw X2ltcGwgKGZkcD0weGZmZmZmZTAxMmI3YzA0MzAsIGZkPTQsIGZwPTB4ZmZmZmY4MDFjYzExOTI4 MCwgdGQ9MHhmZmZmZmUwMGRmOGQwNTYwLCBhdWRpdD10cnVlKSBhdCAvdXNyL3NyYy9zeXMva2Vy bi9rZXJuX2Rlc2NyaXAuYzoxMzAwDQoxMzAwICAgICAgICAgICAgZXJyb3IgPSBjbG9zZWYoZnAs IHRkKTsNCg0KDQooa2dkYikgcHJpbnQgL3ggKmZwDQokMSA9IHtmX2ZsYWcgPSAweDUsIGZfY291 bnQgPSAweGZmZmZmZmZmLCBmX2RhdGEgPSAweGZmZmZmODAwMTU4YjA0MDAsIGZfb3BzID0gMHhm ZmZmZmZmZjgxYjA1MmQwLCBmX3Zub2RlID0gMHhmZmZmZjgwMGQ5MTU2MDAwLCBmX2NyZWQgPSAw eGZmZmZmODAxZDgxYmU0MDAsIGZfdHlwZSA9IDB4MSwgZl92bnJlYWRfZmxhZ3MgPSAweDAsIHtm X3NlcWNvdW50ID0gezB4MCwNCiAgICAgIDB4MH0sIGZfcGlwZWdlbiA9IDB4MH0sIGZfbmV4dG9m ZiA9IHsweDAsIDB4MH0sIGZfdm51biA9IHtmdm5fY2RldnByaXYgPSAweDAsIGZ2bl9hZHZpY2Ug PSAweDB9LCBmX29mZnNldCA9IDB4MH0NCihrZ2RiKQ0KDQoNCg0KDQpDT05GSURFTlRJQUxJVFkg Tk9URTogVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2UNCm9mIHRoZSBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5DQpjb250 YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBhbmQNCmV4 ZW1wdCBmcm9tIGRpc2Nsb3N1cmUgdW5kZXIgYXBwbGljYWJsZSBsYXcuIElmIHRoZSByZWFkZXIN Cm9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBo ZXJlYnkNCm5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBj b3B5aW5nDQpvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYg eW91IGhhdmUNCnJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHVzIGJ5DQp0ZWxlcGhvbmUgYXQgKDUwMikgMjEyLTQwMDAgb3Igbm90aWZ5IHVzIGF0IFBB SSwgRGVwdC4gOTksDQoyMTAxIEhpZ2ggV2lja2hhbSBQbGFjZSwgU3VpdGUgMTAxLCBMb3Vpc3Zp bGxlLCBLWSA0MDI0NQ0KDQpEaXNjbGFpbWVyDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBjb21tdW5pY2F0aW9uIGZyb20gdGhlIHNlbmRlciBpcyBjb25maWRlbnRpYWwuIEl0 IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdXNlIGJ5IHRoZSByZWNpcGllbnQgYW5kIG90aGVycyBh dXRob3JpemVkIHRvIHJlY2VpdmUgaXQuIElmIHlvdSBhcmUgbm90IHRoZSByZWNpcGllbnQsIHlv dSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3Ry aWJ1dGlvbiBvciB0YWtpbmcgYWN0aW9uIGluIHJlbGF0aW9uIG9mIHRoZSBjb250ZW50cyBvZiB0 aGlzIGluZm9ybWF0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1 bC4NCg0KVGhpcyBlbWFpbCBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBtYWx3YXJl LCBhbmQgbWF5IGhhdmUgYmVlbiBhdXRvbWF0aWNhbGx5IGFyY2hpdmVkIGJ5IE1pbWVjYXN0LCBh IGxlYWRlciBpbiBlbWFpbCBzZWN1cml0eSBhbmQgY3liZXIgcmVzaWxpZW5jZS4gTWltZWNhc3Qg aW50ZWdyYXRlcyBlbWFpbCBkZWZlbnNlcyB3aXRoIGJyYW5kIHByb3RlY3Rpb24sIHNlY3VyaXR5 IGF3YXJlbmVzcyB0cmFpbmluZywgd2ViIHNlY3VyaXR5LCBjb21wbGlhbmNlIGFuZCBvdGhlciBl c3NlbnRpYWwgY2FwYWJpbGl0aWVzLiBNaW1lY2FzdCBoZWxwcyBwcm90ZWN0IGxhcmdlIGFuZCBz bWFsbCBvcmdhbml6YXRpb25zIGZyb20gbWFsaWNpb3VzIGFjdGl2aXR5LCBodW1hbiBlcnJvciBh bmQgdGVjaG5vbG9neSBmYWlsdXJlOyBhbmQgdG8gbGVhZCB0aGUgbW92ZW1lbnQgdG93YXJkIGJ1 aWxkaW5nIGEgbW9yZSByZXNpbGllbnQgd29ybGQuIFRvIGZpbmQgb3V0IG1vcmUsIHZpc2l0IG91 ciB3ZWJzaXRlLg0K --MCBoundary=_12202211821420921 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

-----Original Message-----
From: Hans Petter Selasky [mailto:hps@selasky.org]
Sent: Monday, February 21, 2022 8:53 AM
To: Michael Jung <mikej@paymentallianceintl.com>; freebsd-current <= ;freebsd-current@freebsd.org>
Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/21/22 14:07, Michael Jung wrote:
> (kgdb) fram 16
> #16 0xffffffff80bad587 in closefp_impl (fdp=3D0xfffffe012b7c0430, fd= =3D4, fp=3D0xfffff801cc119280, td=3D0xfffffe00df8d0560, audit=3Dtrue) at /u= sr/src/sys/kern/kern_descrip.c:1300
> 1300 error =3D closef(fp, td);
>
> (kgdb) print /x *fdp
> $1 =3D {fd_files =3D 0xfffffe00df6d9000, fd_map =3D 0xfffff80001bb1800= , fd_freefile =3D 0x4, fd_refcnt =3D 0x1, fd_holdcnt =3D 0x1, fd_sx =3D {lo= ck_object =3D {lo_name =3D 0xffffffff8124f6a9, lo_flags =3D 0x2330000, lo_d= ata =3D 0x0,
> lo_witness =3D 0xfffff8041eb94000}, sx_lock =3D 0x1}, fd_kqlist= =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, fd_holdleaderscount =3D 0x0, fd= _holdleaderswakeup =3D 0x0}
> (kgdb)

Can you also:

print /x *fp

in the same frame?

--HPS



Unread portion of the kernel message buffer:
panic: refcount 0xfffff801cc119284 wraparound
cpuid =3D 7
time =3D 1645382575
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0119a83= c80
vpanic() at vpanic+0x17f/frame 0xfffffe0119a83cd0
panic() at panic+0x43/frame 0xfffffe0119a83d30
fdclose() at fdclose/frame 0xfffffe0119a83dc0
closefp_impl() at closefp_impl+0x77/frame 0xfffffe0119a83e00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0119a83f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0119a83f30<= BR> --- syscall (6, FreeBSD ELF64, sys_close), rip =3D 0x3309a531b62a, rsp =3D = 0x3309a2802bc8, rbp =3D 0x3309a2803000 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) = : "n" (offsetof(struct pcpu,


(kgdb) frame 16
#16 0xffffffff80bad587 in closefp_impl (fdp=3D0xfffffe012b7c0430, fd=3D4, f= p=3D0xfffff801cc119280, td=3D0xfffffe00df8d0560, audit=3Dtrue) at /usr/src/= sys/kern/kern_descrip.c:1300
1300 error =3D closef(fp, td);


(kgdb) print /x *fp
$1 =3D {f_flag =3D 0x5, f_count =3D 0xffffffff, f_data =3D 0xfffff800158b04= 00, f_ops =3D 0xffffffff81b052d0, f_vnode =3D 0xfffff800d9156000, f_cred = =3D 0xfffff801d81be400, f_type =3D 0x1, f_vnread_flags =3D 0x0, {f_seqcount= =3D {0x0,
0x0}, f_pipegen =3D 0x0}, f_nextoff =3D {0x0, 0x0}, f_vnun =3D {fvn_c= devpriv =3D 0x0, fvn_advice =3D 0x0}, f_offset =3D 0x0}
(kgdb)




CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245


<= b>Disclaimer

The information contained in this communication from the sender i= s confidential. It is intended solely for use by the recipient and others a= uthorized to receive it. If you are not the recipient, you are hereby notif= ied that any disclosure, copying, distribution or taking action in relation= of the contents of this information is strictly prohibited and may be unla= wful.

This email has been scanned for viruses and malware, and may h= ave been automatically archived by Mimecast, a leader in email security and= cyber resilience. Mimecast integrates email defenses with brand protection= , security awareness training, web security, compliance and other essential= capabilities. Mimecast helps protect large and small organizations from ma= licious activity, human error and technology failure; and to lead the movem= ent toward building a more resilient world. To find out more, visit our web= site.

--MCBoundary=_12202211821420921-- From nobody Mon Feb 21 23:42:28 2022 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 1501F19D81DC for ; Mon, 21 Feb 2022 23:42:34 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from us-smtp-delivery-197.mimecast.com (us-smtp-delivery-197.mimecast.com [170.10.129.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mimecast.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2f3s1tlHz3Fyh for ; Mon, 21 Feb 2022 23:42:33 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from MAIL-HUB.pai.local (175.158.26.216.gopai.com [216.26.158.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-629-KaB8ndsqO6WkARa8fVgxqw-1; Mon, 21 Feb 2022 18:42:30 -0500 X-MC-Unique: KaB8ndsqO6WkARa8fVgxqw-1 Received: from MAIL-HUB.pai.local (10.10.0.250) by MAIL-HUB.pai.local (10.10.0.250) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Mon, 21 Feb 2022 18:42:29 -0500 Received: from MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8]) by MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8%15]) with mapi id 15.00.1497.028; Mon, 21 Feb 2022 18:42:29 -0500 From: Michael Jung To: Hans Petter Selasky , freebsd-current Subject: RE: New panic in main-n253273-a52d8d4a6c6: Thread-Topic: New panic in main-n253273-a52d8d4a6c6: Thread-Index: AdgmmC6h1TNd/HB0TUWCzt+asldIhgAiSNWAAACbjEAADBz0gAAJX15AAACjCbA= Date: Mon, 21 Feb 2022 23:42:28 +0000 Message-ID: <924c13764ce342cf968ef9a93699be9a@MAIL-HUB.pai.local> References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.0.59] x-c2processedorg: 474f336e-f930-49ec-9717-e3226b5b6e6e 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-Mimecast-Spam-Score: 0 X-Mimecast-Originator: paymentallianceintl.com Content-Type: multipart/alternative; boundary="MCBoundary=_12202211842315431" X-Rspamd-Queue-Id: 4K2f3s1tlHz3Fyh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=paymentallianceintl.com; spf=pass (mx1.freebsd.org: domain of mikej@paymentallianceintl.com designates 170.10.129.197 as permitted sender) smtp.mailfrom=mikej@paymentallianceintl.com X-Spamd-Result: default: False [-1.52 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:170.10.129.0/24]; RWL_MAILSPIKE_POSSIBLE(0.00)[170.10.129.197:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.28)[0.285]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[paymentallianceintl.com,none]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:30031, ipnet:170.10.128.0/23, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[170.10.129.197:from] X-ThisMailContainsUnwantedMimeParts: N --MCBoundary=_12202211842315431 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGk6DQoNCkkgd2FzIHRyeWluZyB0byByZW1lbWJlciB3aGF0IEkgZGlkIHRoYXQgd2FzIG9kZCB3 aGVuIHRoaXMgY3Jhc2ggb2NjdXJyZWQgdGhlbiBpdA0KaGl0IG1lLiAgWW91IGNhbiByZXBlYXQg dGhpcyBwYW5pYyBieSBkb2luZzoNCg0KIyB3YXRjaCAtSSAtVyBwdHMvMA0KDQpIZXJlIGlzIGFu b3RoZXIgcGFuaWMgdGhhdCBoYXBwZW5lZCB3cml0ZSBhZnRlciBpc3N1aW5nICJ3YXRjaCIgZm9y IGNvbXBhcmlzb24uDQoNCmh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9jb3JlLnR4dC4xDQoNCmh0dHA6 Ly9tYWlsLm1pa2VqLmNvbS9pbmZvLjENCg0KaHR0cDovL21haWwubWlrZWouY29tL3ZtY29yZS4x DQoNCi0tbWlrZWoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pY2hhZWwg SnVuZw0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyMSwgMjAyMiA2OjIyIFBNDQpUbzogJ0hhbnMg UGV0dGVyIFNlbGFza3knIDxocHNAc2VsYXNreS5vcmc+OyBmcmVlYnNkLWN1cnJlbnQgPGZyZWVi c2QtY3VycmVudEBmcmVlYnNkLm9yZz4NClN1YmplY3Q6IFJFOiBOZXcgcGFuaWMgaW4gbWFpbi1u MjUzMjczLWE1MmQ4ZDRhNmM2Og0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IEhhbnMgUGV0dGVyIFNlbGFza3kgW21haWx0bzpocHNAc2VsYXNreS5vcmddDQpTZW50OiBN b25kYXksIEZlYnJ1YXJ5IDIxLCAyMDIyIDg6NTMgQU0NClRvOiBNaWNoYWVsIEp1bmcgPG1pa2Vq QHBheW1lbnRhbGxpYW5jZWludGwuY29tPjsgZnJlZWJzZC1jdXJyZW50IDxmcmVlYnNkLWN1cnJl bnRAZnJlZWJzZC5vcmc+DQpTdWJqZWN0OiBSZTogTmV3IHBhbmljIGluIG1haW4tbjI1MzI3My1h NTJkOGQ0YTZjNjoNCg0KT24gMi8yMS8yMiAxNDowNywgTWljaGFlbCBKdW5nIHdyb3RlOg0KPiAo a2dkYikgZnJhbSAxNg0KPiAjMTYgMHhmZmZmZmZmZjgwYmFkNTg3IGluIGNsb3NlZnBfaW1wbCAo ZmRwPTB4ZmZmZmZlMDEyYjdjMDQzMCwgZmQ9NCwgZnA9MHhmZmZmZjgwMWNjMTE5MjgwLCB0ZD0w eGZmZmZmZTAwZGY4ZDA1NjAsIGF1ZGl0PXRydWUpIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5f ZGVzY3JpcC5jOjEzMDANCj4gMTMwMCAgICAgICAgICAgIGVycm9yID0gY2xvc2VmKGZwLCB0ZCk7 DQo+DQo+IChrZ2RiKSBwcmludCAveCAqZmRwDQo+ICQxID0ge2ZkX2ZpbGVzID0gMHhmZmZmZmUw MGRmNmQ5MDAwLCBmZF9tYXAgPSAweGZmZmZmODAwMDFiYjE4MDAsIGZkX2ZyZWVmaWxlID0gMHg0 LCBmZF9yZWZjbnQgPSAweDEsIGZkX2hvbGRjbnQgPSAweDEsIGZkX3N4ID0ge2xvY2tfb2JqZWN0 ID0ge2xvX25hbWUgPSAweGZmZmZmZmZmODEyNGY2YTksIGxvX2ZsYWdzID0gMHgyMzMwMDAwLCBs b19kYXRhID0gMHgwLA0KPiAgICAgICAgbG9fd2l0bmVzcyA9IDB4ZmZmZmY4MDQxZWI5NDAwMH0s IHN4X2xvY2sgPSAweDF9LCBmZF9rcWxpc3QgPQ0KPiB7dHFoX2ZpcnN0ID0gMHgwLCB0cWhfbGFz dCA9IDB4MH0sIGZkX2hvbGRsZWFkZXJzY291bnQgPSAweDAsDQo+IGZkX2hvbGRsZWFkZXJzd2Fr ZXVwID0gMHgwfQ0KPiAoa2dkYikNCg0KQ2FuIHlvdSBhbHNvOg0KDQpwcmludCAveCAqZnANCg0K aW4gdGhlIHNhbWUgZnJhbWU/DQoNCi0tSFBTDQoNCg0KDQpVbnJlYWQgcG9ydGlvbiBvZiB0aGUg a2VybmVsIG1lc3NhZ2UgYnVmZmVyOg0KcGFuaWM6IHJlZmNvdW50IDB4ZmZmZmY4MDFjYzExOTI4 NCB3cmFwYXJvdW5kIGNwdWlkID0gNyB0aW1lID0gMTY0NTM4MjU3NQ0KS0RCOiBzdGFjayBiYWNr dHJhY2U6DQpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIr MHgyYi9mcmFtZSAweGZmZmZmZTAxMTlhODNjODANCnZwYW5pYygpIGF0IHZwYW5pYysweDE3Zi9m cmFtZSAweGZmZmZmZTAxMTlhODNjZDANCnBhbmljKCkgYXQgcGFuaWMrMHg0My9mcmFtZSAweGZm ZmZmZTAxMTlhODNkMzANCmZkY2xvc2UoKSBhdCBmZGNsb3NlL2ZyYW1lIDB4ZmZmZmZlMDExOWE4 M2RjMA0KY2xvc2VmcF9pbXBsKCkgYXQgY2xvc2VmcF9pbXBsKzB4NzcvZnJhbWUgMHhmZmZmZmUw MTE5YTgzZTAwDQphbWQ2NF9zeXNjYWxsKCkgYXQgYW1kNjRfc3lzY2FsbCsweDEyZS9mcmFtZSAw eGZmZmZmZTAxMTlhODNmMzANCmZhc3Rfc3lzY2FsbF9jb21tb24oKSBhdCBmYXN0X3N5c2NhbGxf Y29tbW9uKzB4ZjgvZnJhbWUgMHhmZmZmZmUwMTE5YTgzZjMwDQotLS0gc3lzY2FsbCAoNiwgRnJl ZUJTRCBFTEY2NCwgc3lzX2Nsb3NlKSwgcmlwID0gMHgzMzA5YTUzMWI2MmEsIHJzcCA9IDB4MzMw OWEyODAyYmM4LCByYnAgPSAweDMzMDlhMjgwMzAwMCAtLS0NCktEQjogZW50ZXI6IHBhbmljDQoN Cl9fY3VydGhyZWFkICgpIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9pbmNsdWRlL3BjcHVfYXV4Lmg6 NTUNCjU1ICAgICAgICAgICAgICBfX2FzbSgibW92cSAlJWdzOiVQMSwlMCIgOiAiPXIiICh0ZCkg OiAibiIgKG9mZnNldG9mKHN0cnVjdCBwY3B1LA0KDQoNCihrZ2RiKSBmcmFtZSAxNg0KIzE2IDB4 ZmZmZmZmZmY4MGJhZDU4NyBpbiBjbG9zZWZwX2ltcGwgKGZkcD0weGZmZmZmZTAxMmI3YzA0MzAs IGZkPTQsIGZwPTB4ZmZmZmY4MDFjYzExOTI4MCwgdGQ9MHhmZmZmZmUwMGRmOGQwNTYwLCBhdWRp dD10cnVlKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYzoxMzAwDQoxMzAwICAg ICAgICAgICAgZXJyb3IgPSBjbG9zZWYoZnAsIHRkKTsNCg0KDQooa2dkYikgcHJpbnQgL3ggKmZw DQokMSA9IHtmX2ZsYWcgPSAweDUsIGZfY291bnQgPSAweGZmZmZmZmZmLCBmX2RhdGEgPSAweGZm ZmZmODAwMTU4YjA0MDAsIGZfb3BzID0gMHhmZmZmZmZmZjgxYjA1MmQwLCBmX3Zub2RlID0gMHhm ZmZmZjgwMGQ5MTU2MDAwLCBmX2NyZWQgPSAweGZmZmZmODAxZDgxYmU0MDAsIGZfdHlwZSA9IDB4 MSwgZl92bnJlYWRfZmxhZ3MgPSAweDAsIHtmX3NlcWNvdW50ID0gezB4MCwNCiAgICAgIDB4MH0s IGZfcGlwZWdlbiA9IDB4MH0sIGZfbmV4dG9mZiA9IHsweDAsIDB4MH0sIGZfdm51biA9IHtmdm5f Y2RldnByaXYgPSAweDAsIGZ2bl9hZHZpY2UgPSAweDB9LCBmX29mZnNldCA9IDB4MH0NCihrZ2Ri KQ0KDQoNCg0KDQpDT05GSURFTlRJQUxJVFkgTk9URTogVGhpcyBtZXNzYWdlIGlzIGludGVuZGVk IG9ubHkgZm9yIHRoZSB1c2UNCm9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIGl0 IGlzIGFkZHJlc3NlZCBhbmQgbWF5DQpjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJpdmls ZWdlZCwgY29uZmlkZW50aWFsLCBhbmQNCmV4ZW1wdCBmcm9tIGRpc2Nsb3N1cmUgdW5kZXIgYXBw bGljYWJsZSBsYXcuIElmIHRoZSByZWFkZXINCm9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkNCm5vdGlmaWVkIHRoYXQgYW55IGRpc3Nl bWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nDQpvZiB0aGlzIGNvbW11bmljYXRpb24g aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUNCnJlY2VpdmVkIHRoaXMgdHJhbnNt aXNzaW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGJ5DQp0ZWxlcGhvbmUgYXQgKDUwMikg MjEyLTQwMDAgb3Igbm90aWZ5IHVzIGF0IFBBSSwgRGVwdC4gOTksDQoyMTAxIEhpZ2ggV2lja2hh bSBQbGFjZSwgU3VpdGUgMTAxLCBMb3Vpc3ZpbGxlLCBLWSA0MDI0NQ0KDQpEaXNjbGFpbWVyDQoN ClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uIGZyb20gdGhl IHNlbmRlciBpcyBjb25maWRlbnRpYWwuIEl0IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdXNlIGJ5 IHRoZSByZWNpcGllbnQgYW5kIG90aGVycyBhdXRob3JpemVkIHRvIHJlY2VpdmUgaXQuIElmIHlv dSBhcmUgbm90IHRoZSByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB0YWtpbmcgYWN0aW9uIGluIHJl bGF0aW9uIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg0KVGhpcyBlbWFpbCBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBtYWx3YXJlLCBhbmQgbWF5IGhhdmUgYmVlbiBhdXRvbWF0aWNh bGx5IGFyY2hpdmVkIGJ5IE1pbWVjYXN0LCBhIGxlYWRlciBpbiBlbWFpbCBzZWN1cml0eSBhbmQg Y3liZXIgcmVzaWxpZW5jZS4gTWltZWNhc3QgaW50ZWdyYXRlcyBlbWFpbCBkZWZlbnNlcyB3aXRo IGJyYW5kIHByb3RlY3Rpb24sIHNlY3VyaXR5IGF3YXJlbmVzcyB0cmFpbmluZywgd2ViIHNlY3Vy aXR5LCBjb21wbGlhbmNlIGFuZCBvdGhlciBlc3NlbnRpYWwgY2FwYWJpbGl0aWVzLiBNaW1lY2Fz dCBoZWxwcyBwcm90ZWN0IGxhcmdlIGFuZCBzbWFsbCBvcmdhbml6YXRpb25zIGZyb20gbWFsaWNp b3VzIGFjdGl2aXR5LCBodW1hbiBlcnJvciBhbmQgdGVjaG5vbG9neSBmYWlsdXJlOyBhbmQgdG8g bGVhZCB0aGUgbW92ZW1lbnQgdG93YXJkIGJ1aWxkaW5nIGEgbW9yZSByZXNpbGllbnQgd29ybGQu IFRvIGZpbmQgb3V0IG1vcmUsIHZpc2l0IG91ciB3ZWJzaXRlLg0K --MCBoundary=_12202211842315431 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi:

I was trying to remember what I did that was odd when this crash occurred t= hen it
hit me. You can repeat this panic by doing:

# watch -I -W pts/0

Here is another panic that happened write after issuing "watch" f= or comparison.

http://mail.= mikej.com/core.txt.1

http://mail.mike= j.com/info.1

http://mail.mi= kej.com/vmcore.1

--mikej

-----Original Message-----
From: Michael Jung
Sent: Monday, February 21, 2022 6:22 PM
To: 'Hans Petter Selasky' <hps@selasky.org>; freebsd-current <free= bsd-current@freebsd.org>
Subject: RE: New panic in main-n253273-a52d8d4a6c6:



-----Original Message-----
From: Hans Petter Selasky [mailto:hps@selasky.org]
Sent: Monday, February 21, 2022 8:53 AM
To: Michael Jung <mikej@paymentallianceintl.com>; freebsd-current <= ;freebsd-current@freebsd.org>
Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/21/22 14:07, Michael Jung wrote:
> (kgdb) fram 16
> #16 0xffffffff80bad587 in closefp_impl (fdp=3D0xfffffe012b7c0430, fd= =3D4, fp=3D0xfffff801cc119280, td=3D0xfffffe00df8d0560, audit=3Dtrue) at /u= sr/src/sys/kern/kern_descrip.c:1300
> 1300 error =3D closef(fp, td);
>
> (kgdb) print /x *fdp
> $1 =3D {fd_files =3D 0xfffffe00df6d9000, fd_map =3D 0xfffff80001bb1800= , fd_freefile =3D 0x4, fd_refcnt =3D 0x1, fd_holdcnt =3D 0x1, fd_sx =3D {lo= ck_object =3D {lo_name =3D 0xffffffff8124f6a9, lo_flags =3D 0x2330000, lo_d= ata =3D 0x0,
> lo_witness =3D 0xfffff8041eb94000}, sx_lock =3D 0x1}, fd_kqlist= =3D
> {tqh_first =3D 0x0, tqh_last =3D 0x0}, fd_holdleaderscount =3D 0x0, > fd_holdleaderswakeup =3D 0x0}
> (kgdb)

Can you also:

print /x *fp

in the same frame?

--HPS



Unread portion of the kernel message buffer:
panic: refcount 0xfffff801cc119284 wraparound cpuid =3D 7 time =3D 16453825= 75
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0119a83= c80
vpanic() at vpanic+0x17f/frame 0xfffffe0119a83cd0
panic() at panic+0x43/frame 0xfffffe0119a83d30
fdclose() at fdclose/frame 0xfffffe0119a83dc0
closefp_impl() at closefp_impl+0x77/frame 0xfffffe0119a83e00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0119a83f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0119a83f30<= BR> --- syscall (6, FreeBSD ELF64, sys_close), rip =3D 0x3309a531b62a, rsp =3D = 0x3309a2802bc8, rbp =3D 0x3309a2803000 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) = : "n" (offsetof(struct pcpu,


(kgdb) frame 16
#16 0xffffffff80bad587 in closefp_impl (fdp=3D0xfffffe012b7c0430, fd=3D4, f= p=3D0xfffff801cc119280, td=3D0xfffffe00df8d0560, audit=3Dtrue) at /usr/src/= sys/kern/kern_descrip.c:1300
1300 error =3D closef(fp, td);


(kgdb) print /x *fp
$1 =3D {f_flag =3D 0x5, f_count =3D 0xffffffff, f_data =3D 0xfffff800158b04= 00, f_ops =3D 0xffffffff81b052d0, f_vnode =3D 0xfffff800d9156000, f_cred = =3D 0xfffff801d81be400, f_type =3D 0x1, f_vnread_flags =3D 0x0, {f_seqcount= =3D {0x0,
0x0}, f_pipegen =3D 0x0}, f_nextoff =3D {0x0, 0x0}, f_vnun =3D {fvn_c= devpriv =3D 0x0, fvn_advice =3D 0x0}, f_offset =3D 0x0}
(kgdb)




CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245


<= b>Disclaimer

The information contained in this communication from the sender i= s confidential. It is intended solely for use by the recipient and others a= uthorized to receive it. If you are not the recipient, you are hereby notif= ied that any disclosure, copying, distribution or taking action in relation= of the contents of this information is strictly prohibited and may be unla= wful.

This email has been scanned for viruses and malware, and may h= ave been automatically archived by Mimecast, a leader in email security and= cyber resilience. Mimecast integrates email defenses with brand protection= , security awareness training, web security, compliance and other essential= capabilities. Mimecast helps protect large and small organizations from ma= licious activity, human error and technology failure; and to lead the movem= ent toward building a more resilient world. To find out more, visit our web= site.

--MCBoundary=_12202211842315431-- From nobody Tue Feb 22 01:34:20 2022 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 F0FA119C902C for ; Tue, 22 Feb 2022 01:34:38 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4K2hYB0Swxz3s7L for ; Tue, 22 Feb 2022 01:34:38 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C511F2602E7; Tue, 22 Feb 2022 02:34:30 +0100 (CET) Content-Type: multipart/mixed; boundary="------------ITVZJDlWv0kaRyiy0CQ2n0Fk" Message-ID: <719aa03f-6f34-fdf8-1258-c7e5fcf33043@selasky.org> Date: Tue, 22 Feb 2022 02:34:20 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: New panic in main-n253273-a52d8d4a6c6: Content-Language: en-US To: Michael Jung , freebsd-current References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> <924c13764ce342cf968ef9a93699be9a@MAIL-HUB.pai.local> From: Hans Petter Selasky In-Reply-To: <924c13764ce342cf968ef9a93699be9a@MAIL-HUB.pai.local> X-Rspamd-Queue-Id: 4K2hYB0Swxz3s7L X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-1.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-0.32)[-0.318]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch]; HAS_ATTACHMENT(0.00)[]; DMARC_NA(0.00)[selasky.org]; MIME_BASE64_TEXT_BOGUS(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.78)[-0.783]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------ITVZJDlWv0kaRyiy0CQ2n0Fk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/22/22 00:42, Michael Jung wrote: > Hi: > > I was trying to remember what I did that was odd when this crash occurred then it > hit me. You can repeat this panic by doing: > > # watch -I -W pts/0 > > Here is another panic that happened write after issuing "watch" for comparison. > > http://mail.mikej.com/core.txt.1 > > http://mail.mikej.com/info.1 > > http://mail.mikej.com/vmcore.1 > I also need your kernel and debug kernel to fully debug this. 1) Do ssh to machine. 2) watch -i -W pts/0 (does not panic over here) Can you explain what step 1 is? An scp ? Refcount is -1. f_count = 0xffffffff f_data = 0xfffff800158b0400 In your KGDB, can you enter: info 0xffffffff81b052d0 Does the attached patch make any difference? --HPS --------------ITVZJDlWv0kaRyiy0CQ2n0Fk Content-Type: text/x-patch; charset=UTF-8; name="a.diff" Content-Disposition: attachment; filename="a.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvc25wL3NucC5jIGIvc3lzL2Rldi9zbnAvc25wLmMKaW5k ZXggNjRlMmQwZjY0NTMuLjZlZWM0YTVhNjMyIDEwMDY0NAotLS0gYS9zeXMvZGV2L3NucC9z bnAuYworKysgYi9zeXMvZGV2L3NucC9zbnAuYwpAQCAtODYsNiArODYsNyBAQCBzdGF0aWMg ZF9wb2xsX3QJCXNucF9wb2xsOwogCiBzdGF0aWMgc3RydWN0IGNkZXZzdyBzbnBfY2RldnN3 ID0gewogCS5kX3ZlcnNpb24JPSBEX1ZFUlNJT04sCisJLmRfZmxhZ3MJPSBEX1RSQUNLQ0xP U0UsCiAJLmRfb3BlbgkJPSBzbnBfb3BlbiwKIAkuZF9yZWFkCQk9IHNucF9yZWFkLAogCS5k X3dyaXRlCT0gc25wX3dyaXRlLAo= --------------ITVZJDlWv0kaRyiy0CQ2n0Fk-- From nobody Tue Feb 22 01:47:46 2022 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 D60DA19CB8E3 for ; Tue, 22 Feb 2022 01:47:59 +0000 (UTC) (envelope-from rob.fx907@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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2hrZ6CB5z3v7B for ; Tue, 22 Feb 2022 01:47:58 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: by mail-ed1-x533.google.com with SMTP id c6so30315134edk.12 for ; Mon, 21 Feb 2022 17:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wbkA+9eTwi7CvQopl3wLVnmJdD5MjzUty24QUak3OyI=; b=hv4uAMooFRHC5fWaJvyT+yVBK/pRutl5N+bDO6Vzg99ff4744Ax/HW7LI6JR/4jkie gjsSE8IT0DuWzb4o85lldwfx4rEO5hr6VbRhD3m3L2ETYFU+4hqOuHTb6aAmDe9CeuIL kmHCYBKo2kgWqZ7VoABl+m9bh/B2FAlE+Us1j+GrDxIgtt0/8nhtZHOrD/B438P6u22b ECMSCmoAX6ibR9q1ux0ZlvUWHyErXO0ojMahFA6KpuSbYYHLidTT+DnrX1l+oUQuVM7l Y1Oc7aGE1sJPKCYe1kpIOClQfytL7Cea456g7hzt4a3p+p2827yR+6q0RCN99yg7sbnV 1NsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wbkA+9eTwi7CvQopl3wLVnmJdD5MjzUty24QUak3OyI=; b=3lXU4Vra/fbqRrQuDGXjp2B6nrM+9xRF3PReCVe7WoTPAmO+6mumoZ3t95YypaV1tE vxXhhPNfohOm34YQRFdpLi/PT+MMCX7tPuIcUc4epmDYOW+YzvxZRZCEzEzC3IL4QsAc RhWUKylosAi4TFi9yEhVRhuMtuuAS4136DLiJOYT8/QfZhADVdSIBcx277oXwJQe9ziU uroGAsF5zfeNeaAMJIvEtY40ynIj45JzrI+UEwrCrBzoS/GCr/CFM5fHljXMxT3FD9SE fKRsfbgE4Bl08kETFjJow4IRi7Z4lL65Oim8+sL7dr1eFhd6wu9wjvMoCZlqItj25vc3 NkSQ== X-Gm-Message-State: AOAM531SxEb0KLVc/uFWql/93hUGwdMgP7DGmVoObmWZl/Nvs3J2mzNB T9BCq3x5IKFdyTZ5ijKUjDSC6uLXWQWRZ7PTVRE= X-Google-Smtp-Source: ABdhPJz46/qLOisT0fN1lP8Mh7BkmzTZVbeH4bLGpl0Jv6M1rovOvMyMv6NBAnF6oyOUMwGYzv2IUYjuHyKkEJRVtPI= X-Received: by 2002:a05:6402:27d4:b0:412:b81a:b2dc with SMTP id c20-20020a05640227d400b00412b81ab2dcmr20277867ede.87.1645494472428; Mon, 21 Feb 2022 17:47:52 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> <924c13764ce342cf968ef9a93699be9a@MAIL-HUB.pai.local> <719aa03f-6f34-fdf8-1258-c7e5fcf33043@selasky.org> In-Reply-To: <719aa03f-6f34-fdf8-1258-c7e5fcf33043@selasky.org> From: Rob Wing Date: Mon, 21 Feb 2022 16:47:46 -0900 Message-ID: Subject: Re: New panic in main-n253273-a52d8d4a6c6: To: Hans Petter Selasky Cc: Michael Jung , freebsd-current Content-Type: multipart/alternative; boundary="000000000000824e2605d891891f" X-Rspamd-Queue-Id: 4K2hrZ6CB5z3v7B X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=hv4uAMoo; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of robfx907@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=robfx907@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000824e2605d891891f Content-Type: text/plain; charset="UTF-8" kinda thinking this might be related to commit f40dd6c8034b ("tty: switch ttyhook_register to use fget_cap_locked") fget_unlocked() must have grabbed an extra reference count on the file pointer that fget_cap_locked() doesn't get On Mon, Feb 21, 2022 at 4:35 PM Hans Petter Selasky wrote: > On 2/22/22 00:42, Michael Jung wrote: > > Hi: > > > > I was trying to remember what I did that was odd when this crash > occurred then it > > hit me. You can repeat this panic by doing: > > > > # watch -I -W pts/0 > > > > Here is another panic that happened write after issuing "watch" for > comparison. > > > > http://mail.mikej.com/core.txt.1 > > > > http://mail.mikej.com/info.1 > > > > http://mail.mikej.com/vmcore.1 > > > > I also need your kernel and debug kernel to fully debug this. > > 1) Do ssh to machine. > 2) watch -i -W pts/0 (does not panic over here) > > Can you explain what step 1 is? An scp ? > > Refcount is -1. > f_count = 0xffffffff > > f_data = 0xfffff800158b0400 > > In your KGDB, can you enter: > > info 0xffffffff81b052d0 > > Does the attached patch make any difference? > > --HPS --000000000000824e2605d891891f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
kinda thinking this might be related to commit f40dd6= c8034b ("tty: switch ttyhook_register to use fget_cap_locked")

fget_unlocked() must have grabbed an extra reference= count on the file pointer that fget_cap_locked() doesn't get

On M= on, Feb 21, 2022 at 4:35 PM Hans Petter Selasky <hps@selasky.org> wrote:
On 2/22/22 00:42, Michael Jung wrote:
> Hi:
>
> I was trying to remember what I did that was odd when this crash occur= red then it
> hit me.=C2=A0 You can repeat this panic by doing:
>
> # watch -I -W pts/0
>
> Here is another panic that happened write after issuing "watch&qu= ot; for comparison.
>
> http://mail.mikej.com/core.txt.1
>
> http://mail.mikej.com/info.1
>
> http://mail.mikej.com/vmcore.1
>

I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count =3D 0xffffffff

f_data =3D 0xfffff800158b0400

In your KGDB, can you enter:

info 0xffffffff81b052d0

Does the attached patch make any difference?

--HPS
--000000000000824e2605d891891f-- From nobody Tue Feb 22 02:06:20 2022 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 AD15519CF99F for ; Tue, 22 Feb 2022 02:06:51 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from us-smtp-delivery-197.mimecast.com (us-smtp-delivery-197.mimecast.com [170.10.133.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mimecast.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2jGL3ztJz4RxB for ; Tue, 22 Feb 2022 02:06:50 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from MAIL-DR.pai.local (175.158.26.216.gopai.com [216.26.158.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-436-d9PkNib9NkGUAAd_MWn1yA-1; Mon, 21 Feb 2022 21:06:40 -0500 X-MC-Unique: d9PkNib9NkGUAAd_MWn1yA-1 Received: from MAIL-HUB.pai.local (10.10.0.250) by MAIL-DR.pai.local (10.10.0.251) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Mon, 21 Feb 2022 21:06:21 -0500 Received: from MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8]) by MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8%15]) with mapi id 15.00.1497.028; Mon, 21 Feb 2022 21:06:21 -0500 From: Michael Jung To: Hans Petter Selasky , freebsd-current Subject: RE: New panic in main-n253273-a52d8d4a6c6: Thread-Topic: New panic in main-n253273-a52d8d4a6c6: Thread-Index: AdgmmC6h1TNd/HB0TUWCzt+asldIhgAiSNWAAACbjEAADBz0gAAJX15AAACjCbAADn7WAAAJxDvg Date: Tue, 22 Feb 2022 02:06:20 +0000 Message-ID: References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> <924c13764ce342cf968ef9a93699be9a@MAIL-HUB.pai.local> <719aa03f-6f34-fdf8-1258-c7e5fcf33043@selasky.org> In-Reply-To: <719aa03f-6f34-fdf8-1258-c7e5fcf33043@selasky.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.0.59] x-c2processedorg: 474f336e-f930-49ec-9717-e3226b5b6e6e 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-Mimecast-Spam-Score: 0 X-Mimecast-Originator: paymentallianceintl.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_b793efd3965a491aa2e53c5191287feaMAILHUBpailocal_" X-Rspamd-Queue-Id: 4K2jGL3ztJz4RxB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=paymentallianceintl.com; spf=pass (mx1.freebsd.org: domain of mikej@paymentallianceintl.com designates 170.10.133.197 as permitted sender) smtp.mailfrom=mikej@paymentallianceintl.com X-Spamd-Result: default: False [-2.78 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:170.10.133.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RWL_MAILSPIKE_EXCELLENT(0.00)[170.10.133.197:from]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.980]; DMARC_POLICY_ALLOW(-0.50)[paymentallianceintl.com,none]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:30031, ipnet:170.10.132.0/23, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[170.10.133.197:from] X-ThisMailContainsUnwantedMimeParts: N --_000_b793efd3965a491aa2e53c5191287feaMAILHUBpailocal_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 DQoNCkNPTkZJREVOVElBTElUWSBOT1RFOiBUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgb25seSBm b3IgdGhlIHVzZQ0Kb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gaXQgaXMgYWRk cmVzc2VkIGFuZCBtYXkNCmNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBwcml2aWxlZ2VkLCBj b25maWRlbnRpYWwsIGFuZA0KZXhlbXB0IGZyb20gZGlzY2xvc3VyZSB1bmRlciBhcHBsaWNhYmxl IGxhdy4gSWYgdGhlIHJlYWRlcg0Kb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieQ0Kbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlv biwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcNCm9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZQ0KcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgYnkNCnRlbGVwaG9uZSBhdCAoNTAyKSAyMTItNDAw MCBvciBub3RpZnkgdXMgYXQ6IFBBSSwgRGVwdC4gOTksDQoyMTAxIEhpZ2ggV2lja2hhbSBQbGFj ZSwgU3VpdGUgMTAxLCBMb3Vpc3ZpbGxlLCBLWSA0MDI0NQ0KDQoNCg0KRnJvbTogSGFucyBQZXR0 ZXIgU2VsYXNreSBbbWFpbHRvOmhwc0BzZWxhc2t5Lm9yZ10NClNlbnQ6IE1vbmRheSwgRmVicnVh cnkgMjEsIDIwMjIgODozNCBQTQ0KVG86IE1pY2hhZWwgSnVuZyA8bWlrZWpAcGF5bWVudGFsbGlh bmNlaW50bC5jb20+OyBmcmVlYnNkLWN1cnJlbnQgPGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9y Zz4NClN1YmplY3Q6IFJlOiBOZXcgcGFuaWMgaW4gbWFpbi1uMjUzMjczLWE1MmQ4ZDRhNmM2Og0K DQpPbiAyLzIyLzIyIDAwOjQyLCBNaWNoYWVsIEp1bmcgd3JvdGU6DQo+IEhpOg0KPg0KPiBJIHdh cyB0cnlpbmcgdG8gcmVtZW1iZXIgd2hhdCBJIGRpZCB0aGF0IHdhcyBvZGQgd2hlbiB0aGlzIGNy YXNoIG9jY3VycmVkIHRoZW4gaXQNCj4gaGl0IG1lLiBZb3UgY2FuIHJlcGVhdCB0aGlzIHBhbmlj IGJ5IGRvaW5nOg0KPg0KPiAjIHdhdGNoIC1JIC1XIHB0cy8wDQo+DQo+IEhlcmUgaXMgYW5vdGhl ciBwYW5pYyB0aGF0IGhhcHBlbmVkIHdyaXRlIGFmdGVyIGlzc3VpbmcgIndhdGNoIiBmb3IgY29t cGFyaXNvbi4NCj4NCj4gaHR0cDovL21haWwubWlrZWouY29tL2NvcmUudHh0LjE8aHR0cDovL21h aWwubWlrZWouY29tL2NvcmUudHh0LjE+DQo+DQo+IGh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9pbmZv LjE8aHR0cDovL21haWwubWlrZWouY29tL2luZm8uMT4NCj4NCj4gaHR0cDovL21haWwubWlrZWou Y29tL3ZtY29yZS4xPGh0dHA6Ly9tYWlsLm1pa2VqLmNvbS92bWNvcmUuMT4NCj4NCg0KSSBhbHNv IG5lZWQgeW91ciBrZXJuZWwgYW5kIGRlYnVnIGtlcm5lbCB0byBmdWxseSBkZWJ1ZyB0aGlzLg0K DQoxKSBEbyBzc2ggdG8gbWFjaGluZS4NCjIpIHdhdGNoIC1pIC1XIHB0cy8wIChkb2VzIG5vdCBw YW5pYyBvdmVyIGhlcmUpDQoNCkNhbiB5b3UgZXhwbGFpbiB3aGF0IHN0ZXAgMSBpcz8gQW4gc2Nw ID8NCg0KUmVmY291bnQgaXMgLTEuDQpmX2NvdW50ID0gMHhmZmZmZmZmZg0KDQpmX2RhdGEgPSAw eGZmZmZmODAwMTU4YjA0MDANCg0KSW4geW91ciBLR0RCLCBjYW4geW91IGVudGVyOg0KDQppbmZv IDB4ZmZmZmZmZmY4MWIwNTJkMA0KDQpEb2VzIHRoZSBhdHRhY2hlZCBwYXRjaCBtYWtlIGFueSBk aWZmZXJlbmNlPw0KDQotLUhQUw0KDQoNCg0KUGF0Y2ggbWFkZSBubyBkaWZmZXJlbmNlLCBpbnN0 YW50IHBhbmljLg0KDQpUaGVzZSBhcmUgd2lsbCB0aGUgcGF0Y2ggYXBwbGllZC4NCg0KaHR0cDov L21haWwubWlrZWouY29tL3ZtY29yZS4yDQoNCmh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9jb3JlLnR4 dC4yDQoNCmh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9pbmZvLjINCg0KaHR0cDovL21haWwubWlrZWou Y29tL2tlcm5lbC4yDQoNCmh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9rZXJuZWwuZnVsbC4yDQoNCi0t bWlrZWoNCg0KRGlzY2xhaW1lcg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg Y29tbXVuaWNhdGlvbiBmcm9tIHRoZSBzZW5kZXIgaXMgY29uZmlkZW50aWFsLiBJdCBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHVzZSBieSB0aGUgcmVjaXBpZW50IGFuZCBvdGhlcnMgYXV0aG9yaXpl ZCB0byByZWNlaXZlIGl0LiBJZiB5b3UgYXJlIG5vdCB0aGUgcmVjaXBpZW50LCB5b3UgYXJlIGhl cmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24g b3IgdGFraW5nIGFjdGlvbiBpbiByZWxhdGlvbiBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZv cm1hdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQoNClRo aXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgbWFsd2FyZSwgYW5kIG1h eSBoYXZlIGJlZW4gYXV0b21hdGljYWxseSBhcmNoaXZlZCBieSBNaW1lY2FzdCwgYSBsZWFkZXIg aW4gZW1haWwgc2VjdXJpdHkgYW5kIGN5YmVyIHJlc2lsaWVuY2UuIE1pbWVjYXN0IGludGVncmF0 ZXMgZW1haWwgZGVmZW5zZXMgd2l0aCBicmFuZCBwcm90ZWN0aW9uLCBzZWN1cml0eSBhd2FyZW5l c3MgdHJhaW5pbmcsIHdlYiBzZWN1cml0eSwgY29tcGxpYW5jZSBhbmQgb3RoZXIgZXNzZW50aWFs IGNhcGFiaWxpdGllcy4gTWltZWNhc3QgaGVscHMgcHJvdGVjdCBsYXJnZSBhbmQgc21hbGwgb3Jn YW5pemF0aW9ucyBmcm9tIG1hbGljaW91cyBhY3Rpdml0eSwgaHVtYW4gZXJyb3IgYW5kIHRlY2hu b2xvZ3kgZmFpbHVyZTsgYW5kIHRvIGxlYWQgdGhlIG1vdmVtZW50IHRvd2FyZCBidWlsZGluZyBh IG1vcmUgcmVzaWxpZW50IHdvcmxkLiBUbyBmaW5kIG91dCBtb3JlLCB2aXNpdCBvdXIgd2Vic2l0 ZS4NCg== --_000_b793efd3965a491aa2e53c5191287feaMAILHUBpailocal_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBG b250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiPi5zdHlsZTEge2ZvbnQtZmFtaWx5OiAiVGltZXMgTmV3IFJvbWFuIjt9PC9zdHlsZT48L2hl YWQ+PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogQXJpYWwiPiZuYnNwOzwvcD4NCjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTBw eDsgQk9SREVSLVRPUDogIzY2NjY2NiAxcHggc29saWQ7IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBX SURUSDogNDEwcHg7IEJPUkRFUi1CT1RUT006ICM2NjY2NjYgMXB4IHNvbGlkOyBQQURESU5HLUJP VFRPTTogNXB4OyBQQURESU5HLVRPUDogNXB4OyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1S SUdIVDogNXB4Ij4NCkNPTkZJREVOVElBTElUWSBOT1RFOiBUaGlzIG1lc3NhZ2UgaXMgaW50ZW5k ZWQgb25seSBmb3IgdGhlIHVzZTxicj4NCm9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aG9tIGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5IDxicj4NCmNvbnRhaW4gaW5mb3JtYXRpb24gdGhh dCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIGFuZCA8YnI+DQpleGVtcHQgZnJvbSBkaXNj bG9zdXJlIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBJZiB0aGUgcmVhZGVyIDxicj4NCm9mIHRoaXMg bWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgPGJy Pg0Kbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlp bmcgPGJyPg0Kb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElm IHlvdSBoYXZlIDxicj4NCnJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHVzIGJ5IDxicj4NCnRlbGVwaG9uZSBhdCAoNTAyKSAyMTItNDAwMCBvciBub3Rp ZnkgdXMgYXQ6IFBBSSwgRGVwdC4gOTksIDxicj4NCjIxMDEgSGlnaCBXaWNraGFtIFBsYWNlLCBT dWl0ZSAxMDEsIExvdWlzdmlsbGUsIEtZIDQwMjQ1PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHAg c3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHls ZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9 IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJG T05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9O VC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQt U0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpF OiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTog MTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEw cHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4 OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZP TlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05U LUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1G QU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFN SUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlM WTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6 IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBW ZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVy ZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRh bmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5h Ij48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+ PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwv cD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+ DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0K PHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxw IHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBz dHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5 bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxl PSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZP TlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05U LVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1T SVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0la RTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAx MHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBw eDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7 IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBG T05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9O VC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQt RkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZB TUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1J TFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZ OiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTog VmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZl cmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJk YW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFu YSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEi PjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48 L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9w Pg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4N CjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8 cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAg c3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHls ZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9 IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJG T05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9O VC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQt U0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpF OiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTog MTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEw cHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4 OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZP TlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05U LUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1G QU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFN SUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlM WTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6 IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBW ZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVy ZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRh bmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5h Ij48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+ PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwv cD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+ DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0K PHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxw IHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBz dHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5 bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxl PSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZP TlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05U LVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1T SVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0la RTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAx MHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBw eDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7 IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBG T05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9O VC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQt RkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZB TUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1J TFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZ OiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTog VmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZl cmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJk YW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFu YSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEi PjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48 L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9w Pg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4N CjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8 cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAg c3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHls ZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9 IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJG T05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9O VC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQt U0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpF OiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTog MTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEw cHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4 OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZP TlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05U LUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1G QU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFN SUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlM WTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6 IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBW ZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVy ZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRh bmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5h Ij48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+ PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwv cD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSGFucyBQZXR0ZXIgU2VsYXNreSBb bWFpbHRvOmhwc0BzZWxhc2t5Lm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1 YXJ5IDIxLCAyMDIyIDg6MzQgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pY2hhZWwgSnVuZyAmbHQ7bWlr ZWpAcGF5bWVudGFsbGlhbmNlaW50bC5jb20mZ3Q7OyBmcmVlYnNkLWN1cnJlbnQgJmx0O2ZyZWVi c2QtY3VycmVudEBmcmVlYnNkLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE5ldyBw YW5pYyBpbiBtYWluLW4yNTMyNzMtYTUyZDhkNGE2YzY6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAyLzIyLzIyIDAwOjQyLCBNaWNoYWVsIEp1bmcgd3JvdGU6PGJyPg0KJmd0OyBI aTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB3YXMgdHJ5aW5nIHRvIHJlbWVtYmVyIHdoYXQgSSBk aWQgdGhhdCB3YXMgb2RkIHdoZW4gdGhpcyBjcmFzaCBvY2N1cnJlZCB0aGVuIGl0PGJyPg0KJmd0 OyBoaXQgbWUuIFlvdSBjYW4gcmVwZWF0IHRoaXMgcGFuaWMgYnkgZG9pbmc6PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICMgd2F0Y2ggLUkgLVcgcHRzLzA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGVyZSBp cyBhbm90aGVyIHBhbmljIHRoYXQgaGFwcGVuZWQgd3JpdGUgYWZ0ZXIgaXNzdWluZyAmcXVvdDt3 YXRjaCZxdW90OyBmb3IgY29tcGFyaXNvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGEgaHJlZj0i aHR0cDovL21haWwubWlrZWouY29tL2NvcmUudHh0LjEiPg0KaHR0cDovL21haWwubWlrZWouY29t L2NvcmUudHh0LjE8L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9tYWls Lm1pa2VqLmNvbS9pbmZvLjEiPg0KaHR0cDovL21haWwubWlrZWouY29tL2luZm8uMTwvYT48YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL21haWwubWlrZWouY29tL3ZtY29yZS4x Ij4NCmh0dHA6Ly9tYWlsLm1pa2VqLmNvbS92bWNvcmUuMTwvYT48YnI+DQomZ3Q7IDxicj4NCjxi cj4NCkkgYWxzbyBuZWVkIHlvdXIga2VybmVsIGFuZCBkZWJ1ZyBrZXJuZWwgdG8gZnVsbHkgZGVi dWcgdGhpcy48YnI+DQo8YnI+DQoxKSBEbyBzc2ggdG8gbWFjaGluZS48YnI+DQoyKSB3YXRjaCAt aSAtVyBwdHMvMCAoZG9lcyBub3QgcGFuaWMgb3ZlciBoZXJlKTxicj4NCjxicj4NCkNhbiB5b3Ug ZXhwbGFpbiB3aGF0IHN0ZXAgMSBpcz8gQW4gc2NwID88YnI+DQo8YnI+DQpSZWZjb3VudCBpcyAt MS48YnI+DQpmX2NvdW50ID0gMHhmZmZmZmZmZjxicj4NCjxicj4NCmZfZGF0YSA9IDB4ZmZmZmY4 MDAxNThiMDQwMDxicj4NCjxicj4NCkluIHlvdXIgS0dEQiwgY2FuIHlvdSBlbnRlcjo8YnI+DQo8 YnI+DQppbmZvIDB4ZmZmZmZmZmY4MWIwNTJkMDxicj4NCjxicj4NCkRvZXMgdGhlIGF0dGFjaGVk IHBhdGNoIG1ha2UgYW55IGRpZmZlcmVuY2U/PGJyPg0KPGJyPg0KLS1IUFM8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5QYXRjaCBtYWRlIG5vIGRpZmZlcmVuY2UsIGluc3RhbnQgcGFuaWMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGVzZSBhcmUgd2ls bCB0aGUgcGF0Y2ggYXBwbGllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly9tYWlsLm1pa2VqLmNvbS92bWNvcmUuMiI+aHR0cDovL21h aWwubWlrZWouY29tL3ZtY29yZS4yPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL21haWwubWlrZWouY29tL2NvcmUudHh0LjIiPmh0 dHA6Ly9tYWlsLm1pa2VqLmNvbS9jb3JlLnR4dC4yPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL21haWwubWlrZWouY29tL2luZm8u MiI+aHR0cDovL21haWwubWlrZWouY29tL2luZm8uMjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9rZXJu ZWwuMiI+aHR0cDovL21haWwubWlrZWouY29tL2tlcm5lbC4yPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL21haWwubWlrZWouY29t L2tlcm5lbC5mdWxsLjIiPmh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9rZXJuZWwuZnVsbC4yPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS1taWtlajxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KDQoNCjxicj48YnI+PHAgc3R5bGU9ImZvbnQtZmFtaWx5 OiBWZXJkYW5hOyBmb250LXNpemU6MTBwdDsgY29sb3I6IzY2NjY2NjsiPjxiPkRpc2NsYWltZXI8 L2I+PC9wPjxwIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYTsgZm9udC1zaXplOjhwdDsgY29s b3I6IzY2NjY2NjsiPlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0 aW9uIGZyb20gdGhlIHNlbmRlciBpcyBjb25maWRlbnRpYWwuIEl0IGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdXNlIGJ5IHRoZSByZWNpcGllbnQgYW5kIG90aGVycyBhdXRob3JpemVkIHRvIHJlY2Vp dmUgaXQuIElmIHlvdSBhcmUgbm90IHRoZSByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlm aWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB0YWtpbmcg YWN0aW9uIGluIHJlbGF0aW9uIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uIGlz IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC48YnI+PGJyPlRoaXMgZW1h aWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgbWFsd2FyZSwgYW5kIG1heSBoYXZl IGJlZW4gYXV0b21hdGljYWxseSBhcmNoaXZlZCBieSBNaW1lY2FzdCwgYSBsZWFkZXIgaW4gZW1h aWwgc2VjdXJpdHkgYW5kIGN5YmVyIHJlc2lsaWVuY2UuIE1pbWVjYXN0IGludGVncmF0ZXMgZW1h aWwgZGVmZW5zZXMgd2l0aCBicmFuZCBwcm90ZWN0aW9uLCBzZWN1cml0eSBhd2FyZW5lc3MgdHJh aW5pbmcsIHdlYiBzZWN1cml0eSwgY29tcGxpYW5jZSBhbmQgb3RoZXIgZXNzZW50aWFsIGNhcGFi aWxpdGllcy4gTWltZWNhc3QgaGVscHMgcHJvdGVjdCBsYXJnZSBhbmQgc21hbGwgb3JnYW5pemF0 aW9ucyBmcm9tIG1hbGljaW91cyBhY3Rpdml0eSwgaHVtYW4gZXJyb3IgYW5kIHRlY2hub2xvZ3kg ZmFpbHVyZTsgYW5kIHRvIGxlYWQgdGhlIG1vdmVtZW50IHRvd2FyZCBidWlsZGluZyBhIG1vcmUg cmVzaWxpZW50IHdvcmxkLiBUbyBmaW5kIG91dCBtb3JlLCB2aXNpdCBvdXIgd2Vic2l0ZS48L3A+ PC9ib2R5PjwvaHRtbD4NCg== --_000_b793efd3965a491aa2e53c5191287feaMAILHUBpailocal_-- From nobody Tue Feb 22 02:13:34 2022 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 B94FF19D10A7 for ; Tue, 22 Feb 2022 02:13:39 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from us-smtp-delivery-197.mimecast.com (us-smtp-delivery-197.mimecast.com [170.10.133.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mimecast.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2jQC21ZQz4TJ8 for ; Tue, 22 Feb 2022 02:13:39 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from MAIL-HUB.pai.local (175.158.26.216.gopai.com [216.26.158.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-14-Zw-JubA3MY-YNQ4Magu-KQ-1; Mon, 21 Feb 2022 21:13:36 -0500 X-MC-Unique: Zw-JubA3MY-YNQ4Magu-KQ-1 Received: from MAIL-HUB.pai.local (10.10.0.250) by MAIL-HUB.pai.local (10.10.0.250) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Mon, 21 Feb 2022 21:13:34 -0500 Received: from MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8]) by MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8%15]) with mapi id 15.00.1497.028; Mon, 21 Feb 2022 21:13:34 -0500 From: Michael Jung To: Hans Petter Selasky , freebsd-current Subject: RE: New panic in main-n253273-a52d8d4a6c6: Thread-Topic: New panic in main-n253273-a52d8d4a6c6: Thread-Index: AdgmmC6h1TNd/HB0TUWCzt+asldIhgAiSNWAAACbjEAADBz0gAAJX15AAACjCbAADn7WAAAJxDvgABMYq2A= Date: Tue, 22 Feb 2022 02:13:34 +0000 Message-ID: <794fbec71b714f6ea3931b942f17e1ea@MAIL-HUB.pai.local> References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> <924c13764ce342cf968ef9a93699be9a@MAIL-HUB.pai.local> <719aa03f-6f34-fdf8-1258-c7e5fcf33043@selasky.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.0.59] x-c2processedorg: 474f336e-f930-49ec-9717-e3226b5b6e6e 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-Mimecast-Spam-Score: 0 X-Mimecast-Originator: paymentallianceintl.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_794fbec71b714f6ea3931b942f17e1eaMAILHUBpailocal_" X-Rspamd-Queue-Id: 4K2jQC21ZQz4TJ8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=paymentallianceintl.com; spf=pass (mx1.freebsd.org: domain of mikej@paymentallianceintl.com designates 170.10.133.197 as permitted sender) smtp.mailfrom=mikej@paymentallianceintl.com X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:170.10.133.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RWL_MAILSPIKE_EXCELLENT(0.00)[170.10.133.197:from]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[paymentallianceintl.com,none]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:30031, ipnet:170.10.132.0/23, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[170.10.133.197:from] X-ThisMailContainsUnwantedMimeParts: N --_000_794fbec71b714f6ea3931b942f17e1eaMAILHUBpailocal_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 DQoNCg0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RFOiBUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQg b25seSBmb3IgdGhlIHVzZQ0Kb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gaXQg aXMgYWRkcmVzc2VkIGFuZCBtYXkNCmNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBwcml2aWxl Z2VkLCBjb25maWRlbnRpYWwsIGFuZA0KZXhlbXB0IGZyb20gZGlzY2xvc3VyZSB1bmRlciBhcHBs aWNhYmxlIGxhdy4gSWYgdGhlIHJlYWRlcg0Kb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieQ0Kbm90aWZpZWQgdGhhdCBhbnkgZGlzc2Vt aW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcNCm9mIHRoaXMgY29tbXVuaWNhdGlvbiBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZQ0KcmVjZWl2ZWQgdGhpcyB0cmFuc21p c3Npb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgYnkNCnRlbGVwaG9uZSBhdCAoNTAyKSAy MTItNDAwMCBvciBub3RpZnkgdXMgYXQ6IFBBSSwgRGVwdC4gOTksDQoyMTAxIEhpZ2ggV2lja2hh bSBQbGFjZSwgU3VpdGUgMTAxLCBMb3Vpc3ZpbGxlLCBLWSA0MDI0NQ0KDQoNCg0KRnJvbTogTWlj aGFlbCBKdW5nDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIxLCAyMDIyIDk6MDYgUE0NClRvOiAn SGFucyBQZXR0ZXIgU2VsYXNreScgPGhwc0BzZWxhc2t5Lm9yZz47IGZyZWVic2QtY3VycmVudCA8 ZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnPg0KU3ViamVjdDogUkU6IE5ldyBwYW5pYyBpbiBt YWluLW4yNTMyNzMtYTUyZDhkNGE2YzY6DQoNCkZyb206IEhhbnMgUGV0dGVyIFNlbGFza3kgW21h aWx0bzpocHNAc2VsYXNreS5vcmddDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIxLCAyMDIyIDg6 MzQgUE0NClRvOiBNaWNoYWVsIEp1bmcgPG1pa2VqQHBheW1lbnRhbGxpYW5jZWludGwuY29tPG1h aWx0bzptaWtlakBwYXltZW50YWxsaWFuY2VpbnRsLmNvbT4+OyBmcmVlYnNkLWN1cnJlbnQgPGZy ZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZzxtYWlsdG86ZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qu b3JnPj4NClN1YmplY3Q6IFJlOiBOZXcgcGFuaWMgaW4gbWFpbi1uMjUzMjczLWE1MmQ4ZDRhNmM2 Og0KDQpPbiAyLzIyLzIyIDAwOjQyLCBNaWNoYWVsIEp1bmcgd3JvdGU6DQo+IEhpOg0KPg0KPiBJ IHdhcyB0cnlpbmcgdG8gcmVtZW1iZXIgd2hhdCBJIGRpZCB0aGF0IHdhcyBvZGQgd2hlbiB0aGlz IGNyYXNoIG9jY3VycmVkIHRoZW4gaXQNCj4gaGl0IG1lLiBZb3UgY2FuIHJlcGVhdCB0aGlzIHBh bmljIGJ5IGRvaW5nOg0KPg0KPiAjIHdhdGNoIC1JIC1XIHB0cy8wDQo+DQo+IEhlcmUgaXMgYW5v dGhlciBwYW5pYyB0aGF0IGhhcHBlbmVkIHdyaXRlIGFmdGVyIGlzc3VpbmcgIndhdGNoIiBmb3Ig Y29tcGFyaXNvbi4NCj4NCj4gaHR0cDovL21haWwubWlrZWouY29tL2NvcmUudHh0LjE8aHR0cDov L21haWwubWlrZWouY29tL2NvcmUudHh0LjE+DQo+DQo+IGh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9p bmZvLjE8aHR0cDovL21haWwubWlrZWouY29tL2luZm8uMT4NCj4NCj4gaHR0cDovL21haWwubWlr ZWouY29tL3ZtY29yZS4xPGh0dHA6Ly9tYWlsLm1pa2VqLmNvbS92bWNvcmUuMT4NCj4NCg0KSSBh bHNvIG5lZWQgeW91ciBrZXJuZWwgYW5kIGRlYnVnIGtlcm5lbCB0byBmdWxseSBkZWJ1ZyB0aGlz Lg0KDQoxKSBEbyBzc2ggdG8gbWFjaGluZS4NCjIpIHdhdGNoIC1pIC1XIHB0cy8wIChkb2VzIG5v dCBwYW5pYyBvdmVyIGhlcmUpDQoNCkNhbiB5b3UgZXhwbGFpbiB3aGF0IHN0ZXAgMSBpcz8gQW4g c2NwID8NCg0KUmVmY291bnQgaXMgLTEuDQpmX2NvdW50ID0gMHhmZmZmZmZmZg0KDQpmX2RhdGEg PSAweGZmZmZmODAwMTU4YjA0MDANCg0KSW4geW91ciBLR0RCLCBjYW4geW91IGVudGVyOg0KDQpp bmZvIDB4ZmZmZmZmZmY4MWIwNTJkMA0KDQpEb2VzIHRoZSBhdHRhY2hlZCBwYXRjaCBtYWtlIGFu eSBkaWZmZXJlbmNlPw0KDQotLUhQUw0KDQoNClNvIHNvcnJ5LCB5ZXMgc3RlcCBvbmUsIHNzaCB0 byBtYWNoaW5l4oCmLg0KDQpFdmVuIG9wZW4gYSBzZWNvbmQgY29uc29sZSBvbiB0aGUgY29tcHV0 ZXIsIG5vIFNTSCBhbmQgZG8g4oCcd2F0Y2gg4oCTSSAgLVcgdjDigJ0gaXQgcGFuaWNzLg0KDQpF eGFtcGxlIG9mIOKAnHdhdGNoIOKAk0kg4oCTVyB2MOKAnSBmb3IgY29tcGFyaXNvbiDigJMga2Vy bmVsL2tlcm5lbC5mdWxsIGhhdmUgbm90IGNoYW5nZWQgc2luY2UgLjINCg0KaHR0cDovL21haWwu bWlrZWouY29tL2NvcmUudHh0LjMNCg0KaHR0cDovL21haWwubWlrZWouY29tL2luZm8uMw0KDQpo dHRwOi8vbWFpbC5taWtlai5jb20vdm1jb3JlLjMNCg0KRGlzY2xhaW1lcg0KDQpUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBmcm9tIHRoZSBzZW5kZXIgaXMg Y29uZmlkZW50aWFsLiBJdCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHVzZSBieSB0aGUgcmVjaXBp ZW50IGFuZCBvdGhlcnMgYXV0aG9yaXplZCB0byByZWNlaXZlIGl0LiBJZiB5b3UgYXJlIG5vdCB0 aGUgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJl LCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdGFraW5nIGFjdGlvbiBpbiByZWxhdGlvbiBvZiB0 aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuDQoNClRoaXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcyBhbmQgbWFsd2FyZSwgYW5kIG1heSBoYXZlIGJlZW4gYXV0b21hdGljYWxseSBhcmNoaXZl ZCBieSBNaW1lY2FzdCwgYSBsZWFkZXIgaW4gZW1haWwgc2VjdXJpdHkgYW5kIGN5YmVyIHJlc2ls aWVuY2UuIE1pbWVjYXN0IGludGVncmF0ZXMgZW1haWwgZGVmZW5zZXMgd2l0aCBicmFuZCBwcm90 ZWN0aW9uLCBzZWN1cml0eSBhd2FyZW5lc3MgdHJhaW5pbmcsIHdlYiBzZWN1cml0eSwgY29tcGxp YW5jZSBhbmQgb3RoZXIgZXNzZW50aWFsIGNhcGFiaWxpdGllcy4gTWltZWNhc3QgaGVscHMgcHJv dGVjdCBsYXJnZSBhbmQgc21hbGwgb3JnYW5pemF0aW9ucyBmcm9tIG1hbGljaW91cyBhY3Rpdml0 eSwgaHVtYW4gZXJyb3IgYW5kIHRlY2hub2xvZ3kgZmFpbHVyZTsgYW5kIHRvIGxlYWQgdGhlIG1v dmVtZW50IHRvd2FyZCBidWlsZGluZyBhIG1vcmUgcmVzaWxpZW50IHdvcmxkLiBUbyBmaW5kIG91 dCBtb3JlLCB2aXNpdCBvdXIgd2Vic2l0ZS4NCg== --_000_794fbec71b714f6ea3931b942f17e1eaMAILHUBpailocal_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBG b250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+LnN0eWxlMSB7 Zm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iO308L3N0eWxlPjwvaGVhZD48Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj4m bmJzcDs8L3A+DQo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEJPUkRFUi1UT1A6ICM2NjY2 NjYgMXB4IHNvbGlkOyBGT05ULUZBTUlMWTogVmVyZGFuYTsgV0lEVEg6IDQxMHB4OyBCT1JERVIt Qk9UVE9NOiAjNjY2NjY2IDFweCBzb2xpZDsgUEFERElORy1CT1RUT006IDVweDsgUEFERElORy1U T1A6IDVweDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDVweCI+DQpDT05GSURF TlRJQUxJVFkgTk9URTogVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2U8 YnI+DQpvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQg YW5kIG1heSA8YnI+DQpjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJpdmlsZWdlZCwgY29u ZmlkZW50aWFsLCBhbmQgPGJyPg0KZXhlbXB0IGZyb20gZGlzY2xvc3VyZSB1bmRlciBhcHBsaWNh YmxlIGxhdy4gSWYgdGhlIHJlYWRlciA8YnI+DQpvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IDxicj4NCm5vdGlmaWVkIHRoYXQgYW55 IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIDxicj4NCm9mIHRoaXMgY29t bXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSA8YnI+DQpyZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBieSA8YnI+ DQp0ZWxlcGhvbmUgYXQgKDUwMikgMjEyLTQwMDAgb3Igbm90aWZ5IHVzIGF0OiBQQUksIERlcHQu IDk5LCA8YnI+DQoyMTAxIEhpZ2ggV2lja2hhbSBQbGFjZSwgU3VpdGUgMTAxLCBMb3Vpc3ZpbGxl LCBLWSA0MDI0NTxicj4NCjxicj4NCjxicj4NCjxicj4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEw cHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4 OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZP TlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05U LUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1G QU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFN SUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlM WTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6 IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBW ZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVy ZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRh bmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5h Ij48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+ PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwv cD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+ DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0K PHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxw IHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBz dHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5 bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxl PSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZP TlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05U LVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1T SVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0la RTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAx MHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBw eDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7 IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBG T05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9O VC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQt RkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZB TUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1J TFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZ OiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTog VmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZl cmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJk YW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFu YSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEi PjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48 L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9w Pg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4N CjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8 cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAg c3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHls ZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9 IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJG T05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9O VC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQt U0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpF OiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTog MTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEw cHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4 OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZP TlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05U LUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1G QU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFN SUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlM WTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6 IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBW ZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVy ZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRh bmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5h Ij48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+ PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwv cD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+ DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0K PHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxw IHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBz dHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5 bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxl PSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZP TlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05U LVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1T SVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0la RTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAx MHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBw eDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7 IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBG T05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9O VC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQt RkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZB TUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1J TFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZ OiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTog VmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZl cmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJk YW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFu YSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEi PjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48 L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9w Pg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4N CjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8 cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAg c3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHls ZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9 IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJG T05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9O VC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQt U0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpF OiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTog MTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEw cHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4 OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZP TlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05U LUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1G QU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFN SUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlM WTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6 IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBW ZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVy ZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRh bmEiPjwvcD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5h Ij48L3A+DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+ PC9wPg0KPHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwv cD4NCjxwIHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+ DQo8cCBzdHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0K PHAgc3R5bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxw IHN0eWxlPSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBz dHlsZT0iRk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5 bGU9IkZPTlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxl PSJGT05ULVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPHAgc3R5bGU9IkZP TlQtU0laRTogMTBweDsgRk9OVC1GQU1JTFk6IFZlcmRhbmEiPjwvcD4NCjxwIHN0eWxlPSJGT05U LVNJWkU6IDEwcHg7IEZPTlQtRkFNSUxZOiBWZXJkYW5hIj48L3A+DQo8cCBzdHlsZT0iRk9OVC1T SVpFOiAxMHB4OyBGT05ULUZBTUlMWTogVmVyZGFuYSI+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNaWNoYWVs IEp1bmcNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDIxLCAyMDIyIDk6MDYg UE08YnI+DQo8Yj5Ubzo8L2I+ICdIYW5zIFBldHRlciBTZWxhc2t5JyAmbHQ7aHBzQHNlbGFza3ku b3JnJmd0OzsgZnJlZWJzZC1jdXJyZW50ICZsdDtmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBOZXcgcGFuaWMgaW4gbWFpbi1uMjUzMjczLWE1 MmQ4ZDRhNmM2OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEhh bnMgUGV0dGVyIFNlbGFza3kgWzxhIGhyZWY9Im1haWx0bzpocHNAc2VsYXNreS5vcmciPm1haWx0 bzpocHNAc2VsYXNreS5vcmc8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVh cnkgMjEsIDIwMjIgODozNCBQTTxicj4NCjxiPlRvOjwvYj4gTWljaGFlbCBKdW5nICZsdDs8YSBo cmVmPSJtYWlsdG86bWlrZWpAcGF5bWVudGFsbGlhbmNlaW50bC5jb20iPm1pa2VqQHBheW1lbnRh bGxpYW5jZWludGwuY29tPC9hPiZndDs7IGZyZWVic2QtY3VycmVudCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyI+ZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qu b3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE5ldyBwYW5pYyBpbiBtYWluLW4y NTMyNzMtYTUyZDhkNGE2YzY6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzIy LzIyIDAwOjQyLCBNaWNoYWVsIEp1bmcgd3JvdGU6PGJyPg0KJmd0OyBIaTo8YnI+DQomZ3Q7IDxi cj4NCiZndDsgSSB3YXMgdHJ5aW5nIHRvIHJlbWVtYmVyIHdoYXQgSSBkaWQgdGhhdCB3YXMgb2Rk IHdoZW4gdGhpcyBjcmFzaCBvY2N1cnJlZCB0aGVuIGl0PGJyPg0KJmd0OyBoaXQgbWUuIFlvdSBj YW4gcmVwZWF0IHRoaXMgcGFuaWMgYnkgZG9pbmc6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICMgd2F0 Y2ggLUkgLVcgcHRzLzA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGVyZSBpcyBhbm90aGVyIHBhbmlj IHRoYXQgaGFwcGVuZWQgd3JpdGUgYWZ0ZXIgaXNzdWluZyAmcXVvdDt3YXRjaCZxdW90OyBmb3Ig Y29tcGFyaXNvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL21haWwubWlr ZWouY29tL2NvcmUudHh0LjEiPg0KaHR0cDovL21haWwubWlrZWouY29tL2NvcmUudHh0LjE8L2E+ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9pbmZv LjEiPg0KaHR0cDovL21haWwubWlrZWouY29tL2luZm8uMTwvYT48YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGEgaHJlZj0iaHR0cDovL21haWwubWlrZWouY29tL3ZtY29yZS4xIj4NCmh0dHA6Ly9tYWls Lm1pa2VqLmNvbS92bWNvcmUuMTwvYT48YnI+DQomZ3Q7IDxicj4NCjxicj4NCkkgYWxzbyBuZWVk IHlvdXIga2VybmVsIGFuZCBkZWJ1ZyBrZXJuZWwgdG8gZnVsbHkgZGVidWcgdGhpcy48YnI+DQo8 YnI+DQoxKSBEbyBzc2ggdG8gbWFjaGluZS48YnI+DQoyKSB3YXRjaCAtaSAtVyBwdHMvMCAoZG9l cyBub3QgcGFuaWMgb3ZlciBoZXJlKTxicj4NCjxicj4NCkNhbiB5b3UgZXhwbGFpbiB3aGF0IHN0 ZXAgMSBpcz8gQW4gc2NwID88YnI+DQo8YnI+DQpSZWZjb3VudCBpcyAtMS48YnI+DQpmX2NvdW50 ID0gMHhmZmZmZmZmZjxicj4NCjxicj4NCmZfZGF0YSA9IDB4ZmZmZmY4MDAxNThiMDQwMDxicj4N Cjxicj4NCkluIHlvdXIgS0dEQiwgY2FuIHlvdSBlbnRlcjo8YnI+DQo8YnI+DQppbmZvIDB4ZmZm ZmZmZmY4MWIwNTJkMDxicj4NCjxicj4NCkRvZXMgdGhlIGF0dGFjaGVkIHBhdGNoIG1ha2UgYW55 IGRpZmZlcmVuY2U/PGJyPg0KPGJyPg0KLS1IUFM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvIHNvcnJ5LCB5ZXMgc3RlcCBvbmUs IHNzaCB0byBtYWNoaW5l4oCmLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5FdmVuIG9wZW4gYSBzZWNvbmQgY29uc29sZSBvbiB0aGUgY29tcHV0ZXIsIG5vIFNT SCBhbmQgZG8g4oCcd2F0Y2gg4oCTSSAmbmJzcDstVyB2MOKAnSBpdCBwYW5pY3MuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FeGFtcGxlIG9mIOKAnHdhdGNoIOKA k0kg4oCTVyB2MOKAnSBmb3IgY29tcGFyaXNvbiDigJMga2VybmVsL2tlcm5lbC5mdWxsIGhhdmUg bm90IGNoYW5nZWQgc2luY2UgLjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9jb3JlLnR4dC4zIj5odHRwOi8v bWFpbC5taWtlai5jb20vY29yZS50eHQuMzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9pbmZvLjMiPmh0 dHA6Ly9tYWlsLm1pa2VqLmNvbS9pbmZvLjM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vbWFpbC5taWtlai5jb20vdm1jb3JlLjMi Pmh0dHA6Ly9tYWlsLm1pa2VqLmNvbS92bWNvcmUuMzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCg0KDQo8YnI+PGJyPjxwIHN0eWxlPSJmb250LWZh bWlseTogVmVyZGFuYTsgZm9udC1zaXplOjEwcHQ7IGNvbG9yOiM2NjY2NjY7Ij48Yj5EaXNjbGFp bWVyPC9iPjwvcD48cCBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTo4cHQ7 IGNvbG9yOiM2NjY2NjY7Ij5UaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVu aWNhdGlvbiBmcm9tIHRoZSBzZW5kZXIgaXMgY29uZmlkZW50aWFsLiBJdCBpcyBpbnRlbmRlZCBz b2xlbHkgZm9yIHVzZSBieSB0aGUgcmVjaXBpZW50IGFuZCBvdGhlcnMgYXV0aG9yaXplZCB0byBy ZWNlaXZlIGl0LiBJZiB5b3UgYXJlIG5vdCB0aGUgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBu b3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdGFr aW5nIGFjdGlvbiBpbiByZWxhdGlvbiBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlv biBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuPGJyPjxicj5UaGlz IGVtYWlsIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIG1hbHdhcmUsIGFuZCBtYXkg aGF2ZSBiZWVuIGF1dG9tYXRpY2FsbHkgYXJjaGl2ZWQgYnkgTWltZWNhc3QsIGEgbGVhZGVyIGlu IGVtYWlsIHNlY3VyaXR5IGFuZCBjeWJlciByZXNpbGllbmNlLiBNaW1lY2FzdCBpbnRlZ3JhdGVz IGVtYWlsIGRlZmVuc2VzIHdpdGggYnJhbmQgcHJvdGVjdGlvbiwgc2VjdXJpdHkgYXdhcmVuZXNz IHRyYWluaW5nLCB3ZWIgc2VjdXJpdHksIGNvbXBsaWFuY2UgYW5kIG90aGVyIGVzc2VudGlhbCBj YXBhYmlsaXRpZXMuIE1pbWVjYXN0IGhlbHBzIHByb3RlY3QgbGFyZ2UgYW5kIHNtYWxsIG9yZ2Fu aXphdGlvbnMgZnJvbSBtYWxpY2lvdXMgYWN0aXZpdHksIGh1bWFuIGVycm9yIGFuZCB0ZWNobm9s b2d5IGZhaWx1cmU7IGFuZCB0byBsZWFkIHRoZSBtb3ZlbWVudCB0b3dhcmQgYnVpbGRpbmcgYSBt b3JlIHJlc2lsaWVudCB3b3JsZC4gVG8gZmluZCBvdXQgbW9yZSwgdmlzaXQgb3VyIHdlYnNpdGUu PC9wPjwvYm9keT48L2h0bWw+DQo= --_000_794fbec71b714f6ea3931b942f17e1eaMAILHUBpailocal_-- From nobody Tue Feb 22 02:18:22 2022 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 BDBDE19D2878 for ; Tue, 22 Feb 2022 02:18:36 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2jWv6fFFz4VWq for ; Tue, 22 Feb 2022 02:18:35 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: by mail-ej1-x633.google.com with SMTP id p9so38096611ejd.6 for ; Mon, 21 Feb 2022 18:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PzabeRmQzKXvPR2gCLlvnTaQ080dhYKceBC/P5rWjug=; b=TNDW0aq5RvFB+zhwnyed6H3mKotwDgXyD8JZ+0Ilz7QibwHDh80lrG5dk1MLS/2vXl 0K+2Tw8ivl/uPvIBl/QaEYFzU8QRxYADowIVdcwiNr9nGJtm/kGw7NDB67zS0/Icm0hZ Y6RIUrkx+SD+nDgCpNdXd6/L81UssAZkEQY2oQ1YvAyp+r1hlZtGbGMGbC39zf09udtl cHHXr9T1h/0PNd1D6u2OhtK6DgC8q59k0FGPXPq47HGPzMxXc/UBQlBBlPsBYXERXAd1 gGGIB8LcvSjuVldKM7wofwESizIpYUaABMhmARk2WrvpstKkEX91ey3noRSJV3UX9LA8 pPRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PzabeRmQzKXvPR2gCLlvnTaQ080dhYKceBC/P5rWjug=; b=MJ/w1xe6iO6LQ0JLiQzJjGox2rPP4eB5+aOscsRyuVwHQmvKFPMlWSjK7b6krrG3xW 40nD3r0dSM7HyyGgFEyGRYpX0gYH5POuSb7uNLEkuFf61CAtbFMzhR2Wj6R6bt9X6FwM eIUrT/VJSc4Ou4pbjc+mTsYeHvWt/47s1xuS4wLGypftiowRFXugF5WuJCy0soGFK45d xwAGLq6RqIj2zdwnC34+yx7gII3ZF7cwbKPaOAo7JoKa0BGBcSWXABqGzQOcJuNAjwgt fOS+8cxmSQaROF9Ww2ccNVNABGRbNSQUzaMuFtIh1vIWomd9uAgd53pu0DXfp0ag1jfT Rmow== X-Gm-Message-State: AOAM532tdQUYsQMGZiuLG4t5q4HTdF2v79AOVoHwCzxbkuWg3J4GLcIy 1BdMcqTWVWLUMhxCdQhvGhLRsOkFCyWAzDwj9WoNAz/k X-Google-Smtp-Source: ABdhPJwk4BshzyhMH8qVl2Jna21ZdAPCK3v1A+u3CdLmNzMT74S2PnD/NG1RWYfkBmMEA24wVLNX/9wpJv9EH1+d04s= X-Received: by 2002:a17:906:2a92:b0:6cd:4349:dc1a with SMTP id l18-20020a1709062a9200b006cd4349dc1amr17595632eje.648.1645496308825; Mon, 21 Feb 2022 18:18:28 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> <924c13764ce342cf968ef9a93699be9a@MAIL-HUB.pai.local> <719aa03f-6f34-fdf8-1258-c7e5fcf33043@selasky.org> <794fbec71b714f6ea3931b942f17e1ea@MAIL-HUB.pai.local> In-Reply-To: <794fbec71b714f6ea3931b942f17e1ea@MAIL-HUB.pai.local> From: Rob Wing Date: Mon, 21 Feb 2022 17:18:22 -0900 Message-ID: Subject: Re: New panic in main-n253273-a52d8d4a6c6: To: Michael Jung Cc: Hans Petter Selasky , freebsd-current Content-Type: multipart/mixed; boundary="000000000000f7994b05d891f6e9" X-Rspamd-Queue-Id: 4K2jWv6fFFz4VWq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=TNDW0aq5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of robfx907@gmail.com designates 2a00:1450:4864:20::633 as permitted sender) smtp.mailfrom=robfx907@gmail.com X-Spamd-Result: default: False [-2.90 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain,text/x-patch]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::633:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000f7994b05d891f6e9 Content-Type: multipart/alternative; boundary="000000000000f7994805d891f6e7" --000000000000f7994805d891f6e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable try the attached patch On Mon, Feb 21, 2022 at 5:14 PM Michael Jung wrote: > > > > > > CONFIDENTIALITY NOTE: This message is intended only for the use > of the individual or entity to whom it is addressed and may > contain information that is privileged, confidential, and > exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby > notified that any dissemination, distribution or copying > of this communication is strictly prohibited. If you have > received this transmission in error, please notify us by > telephone at (502) 212-4000 or notify us at: PAI, Dept. 99, > 2101 High Wickham Place, Suite 101, Louisville, KY 40245 > > > > *From:* Michael Jung > *Sent:* Monday, February 21, 2022 9:06 PM > *To:* 'Hans Petter Selasky' ; freebsd-current < > freebsd-current@freebsd.org> > *Subject:* RE: New panic in main-n253273-a52d8d4a6c6: > > > > *From:* Hans Petter Selasky [mailto:hps@selasky.org ] > *Sent:* Monday, February 21, 2022 8:34 PM > *To:* Michael Jung ; freebsd-current < > freebsd-current@freebsd.org> > *Subject:* Re: New panic in main-n253273-a52d8d4a6c6: > > > > On 2/22/22 00:42, Michael Jung wrote: > > Hi: > > > > I was trying to remember what I did that was odd when this crash > occurred then it > > hit me. You can repeat this panic by doing: > > > > # watch -I -W pts/0 > > > > Here is another panic that happened write after issuing "watch" for > comparison. > > > > http://mail.mikej.com/core.txt.1 > > > > http://mail.mikej.com/info.1 > > > > http://mail.mikej.com/vmcore.1 > > > > I also need your kernel and debug kernel to fully debug this. > > 1) Do ssh to machine. > 2) watch -i -W pts/0 (does not panic over here) > > Can you explain what step 1 is? An scp ? > > Refcount is -1. > f_count =3D 0xffffffff > > f_data =3D 0xfffff800158b0400 > > In your KGDB, can you enter: > > info 0xffffffff81b052d0 > > Does the attached patch make any difference? > > --HPS > > > > > > So sorry, yes step one, ssh to machine=E2=80=A6. > > > > Even open a second console on the computer, no SSH and do =E2=80=9Cwatch = =E2=80=93I -W > v0=E2=80=9D it panics. > > > > Example of =E2=80=9Cwatch =E2=80=93I =E2=80=93W v0=E2=80=9D for compariso= n =E2=80=93 kernel/kernel.full have not > changed since .2 > > > > http://mail.mikej.com/core.txt.3 > > > > http://mail.mikej.com/info.3 > > > > http://mail.mikej.com/vmcore.3 > > > > > > > > > *Disclaimer* > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and m= ay > be unlawful. > > This email has been scanned for viruses and malware, and may have been > automatically archived by Mimecast, a leader in email security and cyber > resilience. Mimecast integrates email defenses with brand protection, > security awareness training, web security, compliance and other essential > capabilities. Mimecast helps protect large and small organizations from > malicious activity, human error and technology failure; and to lead the > movement toward building a more resilient world. To find out more, visit > our website. > --000000000000f7994805d891f6e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
try the attached patch

On Mon, Feb 21, 2022 at 5:14 PM = Michael Jung <mikej@pay= mentallianceintl.com> wrote:

=C2=A0

=C2=A0

=C2=A0

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245



From: Michael Jung
Sent: Monday, February 21, 2022 9:06 PM
To: 'Hans Petter Selasky' <hps@selasky.org>; freebsd-current <freebsd-current@f= reebsd.org>
Subject: RE: New panic in main-n253273-a52d8d4a6c6:

=C2=A0

From: Hans Petter Selasky [mailto:hps@selasky.org]
Sent: Monday, February 21, 2022 8:34 PM
To: Michael Jung <mikej@paymentallianceintl.com>; freebsd-current = <freebs= d-current@freebsd.org>
Subject: Re: New panic in main-n253273-a52d8d4a6c6:

=C2=A0

On 2/22/22 00:42, Michael Jung wrote:
> Hi:
>
> I was trying to remember what I did that was odd when this crash occur= red then it
> hit me. You can repeat this panic by doing:
>
> # watch -I -W pts/0
>
> Here is another panic that happened write after issuing "watch&qu= ot; for comparison.
>
> http://mail.mikej.com/core.txt.1
>
> http://mail.mikej.com/info.1
>
> http://mail.mikej.com/vmcore.1
>

I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count =3D 0xffffffff

f_data =3D 0xfffff800158b0400

In your KGDB, can you enter:

info 0xffffffff81b052d0

Does the attached patch make any difference?

--HPS

=C2=A0

=C2=A0

So sorry, yes step one, ssh to m= achine=E2=80=A6.

=C2=A0

Even open a second console on th= e computer, no SSH and do =E2=80=9Cwatch =E2=80=93I =C2=A0-W v0=E2=80=9D it= panics.

=C2=A0

Example of =E2=80=9Cwatch =E2=80= =93I =E2=80=93W v0=E2=80=9D for comparison =E2=80=93 kernel/kernel.full hav= e not changed since .2

=C2=A0

http://mail.mikej.com/core.txt.3<= u>

=C2=A0

http://mail.mikej.com/info.3

=C2=A0

http://mail.mikej.com/vmcore.3

=C2=A0

=C2=A0

=C2=A0



Disclaimer

The information contained in this communication from th= e sender is confidential. It is intended solely for use by the recipient an= d others authorized to receive it. If you are not the recipient, you are he= reby notified that any disclosure, copying, distribution or taking action i= n relation of the contents of this information is strictly prohibited and m= ay be unlawful.

This email has been scanned for viruses and malware,= and may have been automatically archived by Mimecast, a leader in email se= curity and cyber resilience. Mimecast integrates email defenses with brand = protection, security awareness training, web security, compliance and other= essential capabilities. Mimecast helps protect large and small organizatio= ns from malicious activity, human error and technology failure; and to lead= the movement toward building a more resilient world. To find out more, vis= it our website.

--000000000000f7994805d891f6e7-- --000000000000f7994b05d891f6e9 Content-Type: text/x-patch; charset="US-ASCII"; name="tty.patch" Content-Disposition: attachment; filename="tty.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kzxi05x50 ZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3R0eS5jIGIvc3lzL2tlcm4vdHR5LmMKaW5kZXggZWJiMzJm Njk4ZTg4Li5lOThiMmQxMGI4MTAgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3R0eS5jCisrKyBiL3N5 cy9rZXJuL3R0eS5jCkBAIC0yMDgzLDYgKzIwODMsOCBAQCB0dHlob29rX3JlZ2lzdGVyKHN0cnVj dCB0dHkgKipydHAsIHN0cnVjdCBwcm9jICpwLCBpbnQgZmQsIHN0cnVjdCB0dHlob29rICp0aCwK IAlGSUxFREVTQ19TTE9DSyhmZHApOwogCWVycm9yID0gZmdldF9jYXBfbG9ja2VkKGZkcCwgZmQs IGNhcF9yaWdodHNfaW5pdF9vbmUoJnJpZ2h0cywgQ0FQX1RUWUhPT0spLAogCSAgICAmZnAsIE5V TEwpOworCWlmIChlcnJvciA9PSAwICYmICFmaG9sZChmcCkpCisJCXJldHVybiAoRUJBREYpOwog CUZJTEVERVNDX1NVTkxPQ0soZmRwKTsKIAlpZiAoZXJyb3IgIT0gMCkKIAkJcmV0dXJuIChlcnJv cik7Cg== --000000000000f7994b05d891f6e9-- From nobody Tue Feb 22 02:29:34 2022 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 5908819D4F3D for ; Tue, 22 Feb 2022 02:29:42 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2jmj3bbhz4XXm for ; Tue, 22 Feb 2022 02:29:41 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: by mail-ej1-x62a.google.com with SMTP id d10so38117804eje.10 for ; Mon, 21 Feb 2022 18:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fDx5+D+euQs7ZEEm1geemPtvVVLfvVdyG0fGPihB1X0=; b=LMekhwKPl/N7A03f2tDEex3HZBqg5aa07dpA1cqcUbeQYy12gVvP8jLTFkfExbghbD 13C9+epUPktrLrefybwEDWpIusUo7CrL1PlJub50PUVYLgIiqX4FHav858A6usmDjRGO h+zLx+CUjswzzgGYDEwtVjkkonC1hCnlGBRoGWOF0Kq1n4qInGSay1r5gpnXtAW6l7wb CTBoMSbajJ0Ut5ev4v+mu2vkIvPjqLHpmbeklfRKyQkI1DQD6EGSgCzFm8/eZ5MzXY3k HM53IMGdPEbqhmJP1xcNYnK5sHfKThNODKrrFFAsAX6qIw1uDkldIX5caT/9Im9FxwPM TVqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fDx5+D+euQs7ZEEm1geemPtvVVLfvVdyG0fGPihB1X0=; b=gqVeK/9EfrIqSlBODvPC8+FBqoM7z+1cumIHY85vvwtsas3h7XC8ew0OqE9FVL7Cok 1BnLTVnbRe3OoslHQt8dnDEK2v42Aqh1Lnu8HE+N3ydx08pRj388mJIOy2f/q4FnyEOg rGZu6+sub9Hifm/+C2nVOAaRVTBbHd8tmlRHxwfBRuXF+CNNnbA3pFpqPeoJhRSK+nGz XBlL51PVWG9eYLgokGPETmcUoI+np+Proq2AOBxu1K8iiYhoIRFaSsTS/E5fY7eeJavs X4TqpBWVrJX1pgJk7fZsE4cjRg6dLxYRGtcka6YNgwfNFqM/FqIMPiKzTw8ECq95b5G6 Wgcw== X-Gm-Message-State: AOAM533/s5nIcDOB1EbV4TpYigoD93+l7EL1SLbK9Hf/j8yssVaDzfvi dpe1+1IJXGkUidIkuFQ8zahq1KNlkFjtbx9cPWU= X-Google-Smtp-Source: ABdhPJx5VyL3QQ0d+1J6puJFxLApw3mf+whds9zPQSc2BozcuyqcOVoIr1TU+INQxMrNxMYeuMPN6ldFyEHFIaXbc6o= X-Received: by 2002:a17:906:b57:b0:6ce:e31a:524 with SMTP id v23-20020a1709060b5700b006cee31a0524mr17587591ejg.290.1645496980390; Mon, 21 Feb 2022 18:29:40 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> <924c13764ce342cf968ef9a93699be9a@MAIL-HUB.pai.local> <719aa03f-6f34-fdf8-1258-c7e5fcf33043@selasky.org> <794fbec71b714f6ea3931b942f17e1ea@MAIL-HUB.pai.local> In-Reply-To: From: Rob Wing Date: Mon, 21 Feb 2022 17:29:34 -0900 Message-ID: Subject: Re: New panic in main-n253273-a52d8d4a6c6: To: Michael Jung Cc: Hans Petter Selasky , freebsd-current Content-Type: multipart/mixed; boundary="000000000000ff4ffc05d8921e36" X-Rspamd-Queue-Id: 4K2jmj3bbhz4XXm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=LMekhwKP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of robfx907@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=robfx907@gmail.com X-Spamd-Result: default: False [-2.90 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain,text/x-patch]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000ff4ffc05d8921e36 Content-Type: multipart/alternative; boundary="000000000000ff4ffb05d8921e34" --000000000000ff4ffb05d8921e34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The previous attached patch should work for testing purposes, but it's incorrect if an error occurs. The fhold() should be below FILEDESC_SUNLOCK(), this patch addresses that. On Mon, Feb 21, 2022 at 5:18 PM Rob Wing wrote: > try the attached patch > > On Mon, Feb 21, 2022 at 5:14 PM Michael Jung < > mikej@paymentallianceintl.com> wrote: > >> >> >> >> >> >> CONFIDENTIALITY NOTE: This message is intended only for the use >> of the individual or entity to whom it is addressed and may >> contain information that is privileged, confidential, and >> exempt from disclosure under applicable law. If the reader >> of this message is not the intended recipient, you are hereby >> notified that any dissemination, distribution or copying >> of this communication is strictly prohibited. If you have >> received this transmission in error, please notify us by >> telephone at (502) 212-4000 or notify us at: PAI, Dept. 99, >> 2101 High Wickham Place, Suite 101, Louisville, KY 40245 >> >> >> >> *From:* Michael Jung >> *Sent:* Monday, February 21, 2022 9:06 PM >> *To:* 'Hans Petter Selasky' ; freebsd-current < >> freebsd-current@freebsd.org> >> *Subject:* RE: New panic in main-n253273-a52d8d4a6c6: >> >> >> >> *From:* Hans Petter Selasky [mailto:hps@selasky.org ] >> *Sent:* Monday, February 21, 2022 8:34 PM >> *To:* Michael Jung ; freebsd-current < >> freebsd-current@freebsd.org> >> *Subject:* Re: New panic in main-n253273-a52d8d4a6c6: >> >> >> >> On 2/22/22 00:42, Michael Jung wrote: >> > Hi: >> > >> > I was trying to remember what I did that was odd when this crash >> occurred then it >> > hit me. You can repeat this panic by doing: >> > >> > # watch -I -W pts/0 >> > >> > Here is another panic that happened write after issuing "watch" for >> comparison. >> > >> > http://mail.mikej.com/core.txt.1 >> > >> > http://mail.mikej.com/info.1 >> > >> > http://mail.mikej.com/vmcore.1 >> > >> >> I also need your kernel and debug kernel to fully debug this. >> >> 1) Do ssh to machine. >> 2) watch -i -W pts/0 (does not panic over here) >> >> Can you explain what step 1 is? An scp ? >> >> Refcount is -1. >> f_count =3D 0xffffffff >> >> f_data =3D 0xfffff800158b0400 >> >> In your KGDB, can you enter: >> >> info 0xffffffff81b052d0 >> >> Does the attached patch make any difference? >> >> --HPS >> >> >> >> >> >> So sorry, yes step one, ssh to machine=E2=80=A6. >> >> >> >> Even open a second console on the computer, no SSH and do =E2=80=9Cwatch= =E2=80=93I -W >> v0=E2=80=9D it panics. >> >> >> >> Example of =E2=80=9Cwatch =E2=80=93I =E2=80=93W v0=E2=80=9D for comparis= on =E2=80=93 kernel/kernel.full have not >> changed since .2 >> >> >> >> http://mail.mikej.com/core.txt.3 >> >> >> >> http://mail.mikej.com/info.3 >> >> >> >> http://mail.mikej.com/vmcore.3 >> >> >> >> >> >> >> >> >> *Disclaimer* >> >> The information contained in this communication from the sender is >> confidential. It is intended solely for use by the recipient and others >> authorized to receive it. If you are not the recipient, you are hereby >> notified that any disclosure, copying, distribution or taking action in >> relation of the contents of this information is strictly prohibited and = may >> be unlawful. >> >> This email has been scanned for viruses and malware, and may have been >> automatically archived by Mimecast, a leader in email security and cyber >> resilience. Mimecast integrates email defenses with brand protection, >> security awareness training, web security, compliance and other essentia= l >> capabilities. Mimecast helps protect large and small organizations from >> malicious activity, human error and technology failure; and to lead the >> movement toward building a more resilient world. To find out more, visit >> our website. >> > --000000000000ff4ffb05d8921e34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The previous attached patch should work for testing p= urposes, but it's incorrect if an error occurs.

The fhold() should be below FILEDESC_SUNLOCK(), this patch addresses = that.

On Mon, Feb 21, 2022 at 5:18 PM Rob Wing <rob.fx907@gmail.com> wrote:
try the attach= ed patch

On Mon, Feb 21, 2022 at 5:14 PM Michael Jung <mikej@paymentalliancei= ntl.com> wrote:

=C2=A0

=C2=A0

=C2=A0

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245



From: Michael Jung
Sent: Monday, February 21, 2022 9:06 PM
To: 'Hans Petter Selasky' <hps@selasky.org>; freebsd-current <freebsd-current@f= reebsd.org>
Subject: RE: New panic in main-n253273-a52d8d4a6c6:

=C2=A0

From: Hans Petter Selasky [mailto:hps@selasky.org]
Sent: Monday, February 21, 2022 8:34 PM
To: Michael Jung <mikej@paymentallianceintl.com>; freebsd-current = <freebs= d-current@freebsd.org>
Subject: Re: New panic in main-n253273-a52d8d4a6c6:

=C2=A0

On 2/22/22 00:42, Michael Jung wrote:
> Hi:
>
> I was trying to remember what I did that was odd when this crash occur= red then it
> hit me. You can repeat this panic by doing:
>
> # watch -I -W pts/0
>
> Here is another panic that happened write after issuing "watch&qu= ot; for comparison.
>
> http://mail.mikej.com/core.txt.1
>
> http://mail.mikej.com/info.1
>
> http://mail.mikej.com/vmcore.1
>

I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count =3D 0xffffffff

f_data =3D 0xfffff800158b0400

In your KGDB, can you enter:

info 0xffffffff81b052d0

Does the attached patch make any difference?

--HPS

=C2=A0

=C2=A0

So sorry, yes step one, ssh to m= achine=E2=80=A6.

=C2=A0

Even open a second console on th= e computer, no SSH and do =E2=80=9Cwatch =E2=80=93I =C2=A0-W v0=E2=80=9D it= panics.

=C2=A0

Example of =E2=80=9Cwatch =E2=80= =93I =E2=80=93W v0=E2=80=9D for comparison =E2=80=93 kernel/kernel.full hav= e not changed since .2

=C2=A0

http://mail.mikej.com/core.txt.3<= u>

=C2=A0

http://mail.mikej.com/info.3

=C2=A0

http://mail.mikej.com/vmcore.3

=C2=A0

=C2=A0

=C2=A0



Disclaimer

The information contained in this communication from th= e sender is confidential. It is intended solely for use by the recipient an= d others authorized to receive it. If you are not the recipient, you are he= reby notified that any disclosure, copying, distribution or taking action i= n relation of the contents of this information is strictly prohibited and m= ay be unlawful.

This email has been scanned for viruses and malware,= and may have been automatically archived by Mimecast, a leader in email se= curity and cyber resilience. Mimecast integrates email defenses with brand = protection, security awareness training, web security, compliance and other= essential capabilities. Mimecast helps protect large and small organizatio= ns from malicious activity, human error and technology failure; and to lead= the movement toward building a more resilient world. To find out more, vis= it our website.

--000000000000ff4ffb05d8921e34-- --000000000000ff4ffc05d8921e36 Content-Type: text/x-patch; charset="US-ASCII"; name="tty.patch" Content-Disposition: attachment; filename="tty.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kzxiefac0 ZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3R0eS5jIGIvc3lzL2tlcm4vdHR5LmMKaW5kZXggZWJiMzJm Njk4ZTg4Li4yYzYwYTdlNDI1ODAgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3R0eS5jCisrKyBiL3N5 cy9rZXJuL3R0eS5jCkBAIC0yMDg2LDYgKzIwODYsOCBAQCB0dHlob29rX3JlZ2lzdGVyKHN0cnVj dCB0dHkgKipydHAsIHN0cnVjdCBwcm9jICpwLCBpbnQgZmQsIHN0cnVjdCB0dHlob29rICp0aCwK IAlGSUxFREVTQ19TVU5MT0NLKGZkcCk7CiAJaWYgKGVycm9yICE9IDApCiAJCXJldHVybiAoZXJy b3IpOworCWlmICghZmhvbGQoZnApKQorCQlyZXR1cm4gKEVCQURGKTsKIAlpZiAoZnAtPmZfb3Bz ID09ICZiYWRmaWxlb3BzKSB7CiAJCWVycm9yID0gRUJBREY7CiAJCWdvdG8gZG9uZTE7Cg== --000000000000ff4ffc05d8921e36-- From nobody Tue Feb 22 03:04:57 2022 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 5860919DC482 for ; Tue, 22 Feb 2022 03:05:25 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from us-smtp-delivery-197.mimecast.com (us-smtp-delivery-197.mimecast.com [170.10.129.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mimecast.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2kYw1Lhxz4f86 for ; Tue, 22 Feb 2022 03:05:24 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from MAIL-DR.pai.local (175.158.26.216.gopai.com [216.26.158.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-245-klyz3rzcPY-WhG_yl3wfxg-1; Mon, 21 Feb 2022 22:05:21 -0500 X-MC-Unique: klyz3rzcPY-WhG_yl3wfxg-1 Received: from MAIL-HUB.pai.local (10.10.0.250) by MAIL-DR.pai.local (10.10.0.251) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Mon, 21 Feb 2022 22:04:57 -0500 Received: from MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8]) by MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8%15]) with mapi id 15.00.1497.028; Mon, 21 Feb 2022 22:04:57 -0500 From: Michael Jung To: Rob Wing CC: Hans Petter Selasky , freebsd-current Subject: RE: New panic in main-n253273-a52d8d4a6c6: Thread-Topic: New panic in main-n253273-a52d8d4a6c6: Thread-Index: AdgmmC6h1TNd/HB0TUWCzt+asldIhgAiSNWAAACbjEAADBz0gAAJX15AAACjCbAADn7WAAAJxDvgABMYq2D//yVmAIAAAyEAgABL5AA= Date: Tue, 22 Feb 2022 03:04:57 +0000 Message-ID: <903498700a1c4b32acb8fe283e746189@MAIL-HUB.pai.local> References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> <924c13764ce342cf968ef9a93699be9a@MAIL-HUB.pai.local> <719aa03f-6f34-fdf8-1258-c7e5fcf33043@selasky.org> <794fbec71b714f6ea3931b942f17e1ea@MAIL-HUB.pai.local> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.0.59] x-c2processedorg: 474f336e-f930-49ec-9717-e3226b5b6e6e 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-Mimecast-Spam-Score: 0 X-Mimecast-Originator: paymentallianceintl.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_903498700a1c4b32acb8fe283e746189MAILHUBpailocal_" X-Rspamd-Queue-Id: 4K2kYw1Lhxz4f86 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=paymentallianceintl.com; spf=pass (mx1.freebsd.org: domain of mikej@paymentallianceintl.com designates 170.10.129.197 as permitted sender) smtp.mailfrom=mikej@paymentallianceintl.com X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:170.10.129.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[paymentallianceintl.com,none]; RWL_MAILSPIKE_POSSIBLE(0.00)[170.10.129.197:from]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:30031, ipnet:170.10.128.0/23, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[170.10.129.197:from] X-ThisMailContainsUnwantedMimeParts: N --_000_903498700a1c4b32acb8fe283e746189MAILHUBpailocal_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Um9iOg0KDQpJIGRpZCBub3QgcmVtb3ZlIEhhbnMgZWFybGllciBwYXRjaCwgYnV0IHlvdXIg4oCc bGF0ZXN04oCdIHBhdGNoIGFwcGxpZWQgYW5kIGNvbXBpbGVkIHdpdGggbm8gZXJyb3JzLg0KDQpJ IGNhbiBub3cgd2F0Y2ggYW5kIGNvbnRyb2wgYSBUVFkgKHYwKSBvciBhIFNTSCBzZXNzaW9uIChw dHMvMSkgd2l0aG91dCBjcmFzaGluZy4NCg0KQW55dGhpbmcgZWxzZSB5b3Ugd291bGQgbGlrZSBt ZSB0byB0cnk/DQoNCi0tbWlrZWoNCg0KDQpGcm9tOiBSb2IgV2luZyBbbWFpbHRvOnJvYi5meDkw N0BnbWFpbC5jb21dDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIxLCAyMDIyIDk6MzAgUE0NClRv OiBNaWNoYWVsIEp1bmcgPG1pa2VqQHBheW1lbnRhbGxpYW5jZWludGwuY29tPg0KQ2M6IEhhbnMg UGV0dGVyIFNlbGFza3kgPGhwc0BzZWxhc2t5Lm9yZz47IGZyZWVic2QtY3VycmVudCA8ZnJlZWJz ZC1jdXJyZW50QGZyZWVic2Qub3JnPg0KU3ViamVjdDogUmU6IE5ldyBwYW5pYyBpbiBtYWluLW4y NTMyNzMtYTUyZDhkNGE2YzY6DQoNClRoZSBwcmV2aW91cyBhdHRhY2hlZCBwYXRjaCBzaG91bGQg d29yayBmb3IgdGVzdGluZyBwdXJwb3NlcywgYnV0IGl0J3MgaW5jb3JyZWN0IGlmIGFuIGVycm9y IG9jY3Vycy4NCg0KVGhlIGZob2xkKCkgc2hvdWxkIGJlIGJlbG93IEZJTEVERVNDX1NVTkxPQ0so KSwgdGhpcyBwYXRjaCBhZGRyZXNzZXMgdGhhdC4NCg0KT24gTW9uLCBGZWIgMjEsIDIwMjIgYXQg NToxOCBQTSBSb2IgV2luZyA8cm9iLmZ4OTA3QGdtYWlsLmNvbTxtYWlsdG86cm9iLmZ4OTA3QGdt YWlsLmNvbT4+IHdyb3RlOg0KdHJ5IHRoZSBhdHRhY2hlZCBwYXRjaA0KDQpPbiBNb24sIEZlYiAy MSwgMjAyMiBhdCA1OjE0IFBNIE1pY2hhZWwgSnVuZyA8bWlrZWpAcGF5bWVudGFsbGlhbmNlaW50 bC5jb208bWFpbHRvOm1pa2VqQHBheW1lbnRhbGxpYW5jZWludGwuY29tPj4gd3JvdGU6DQoNCg0K DQoNCkNPTkZJREVOVElBTElUWSBOT1RFOiBUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgb25seSBm b3IgdGhlIHVzZQ0Kb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gaXQgaXMgYWRk cmVzc2VkIGFuZCBtYXkNCmNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBwcml2aWxlZ2VkLCBj b25maWRlbnRpYWwsIGFuZA0KZXhlbXB0IGZyb20gZGlzY2xvc3VyZSB1bmRlciBhcHBsaWNhYmxl IGxhdy4gSWYgdGhlIHJlYWRlcg0Kb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieQ0Kbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlv biwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcNCm9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZQ0KcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgYnkNCnRlbGVwaG9uZSBhdCAoNTAyKSAyMTItNDAw MCBvciBub3RpZnkgdXMgYXQ6IFBBSSwgRGVwdC4gOTksDQoyMTAxIEhpZ2ggV2lja2hhbSBQbGFj ZSwgU3VpdGUgMTAxLCBMb3Vpc3ZpbGxlLCBLWSA0MDI0NQ0KDQoNCkZyb206IE1pY2hhZWwgSnVu Zw0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyMSwgMjAyMiA5OjA2IFBNDQpUbzogJ0hhbnMgUGV0 dGVyIFNlbGFza3knIDxocHNAc2VsYXNreS5vcmc8bWFpbHRvOmhwc0BzZWxhc2t5Lm9yZz4+OyBm cmVlYnNkLWN1cnJlbnQgPGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZzxtYWlsdG86ZnJlZWJz ZC1jdXJyZW50QGZyZWVic2Qub3JnPj4NClN1YmplY3Q6IFJFOiBOZXcgcGFuaWMgaW4gbWFpbi1u MjUzMjczLWE1MmQ4ZDRhNmM2Og0KDQpGcm9tOiBIYW5zIFBldHRlciBTZWxhc2t5IFttYWlsdG86 aHBzQHNlbGFza3kub3JnXQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyMSwgMjAyMiA4OjM0IFBN DQpUbzogTWljaGFlbCBKdW5nIDxtaWtlakBwYXltZW50YWxsaWFuY2VpbnRsLmNvbTxtYWlsdG86 bWlrZWpAcGF5bWVudGFsbGlhbmNlaW50bC5jb20+PjsgZnJlZWJzZC1jdXJyZW50IDxmcmVlYnNk LWN1cnJlbnRAZnJlZWJzZC5vcmc8bWFpbHRvOmZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZz4+ DQpTdWJqZWN0OiBSZTogTmV3IHBhbmljIGluIG1haW4tbjI1MzI3My1hNTJkOGQ0YTZjNjoNCg0K T24gMi8yMi8yMiAwMDo0MiwgTWljaGFlbCBKdW5nIHdyb3RlOg0KPiBIaToNCj4NCj4gSSB3YXMg dHJ5aW5nIHRvIHJlbWVtYmVyIHdoYXQgSSBkaWQgdGhhdCB3YXMgb2RkIHdoZW4gdGhpcyBjcmFz aCBvY2N1cnJlZCB0aGVuIGl0DQo+IGhpdCBtZS4gWW91IGNhbiByZXBlYXQgdGhpcyBwYW5pYyBi eSBkb2luZzoNCj4NCj4gIyB3YXRjaCAtSSAtVyBwdHMvMA0KPg0KPiBIZXJlIGlzIGFub3RoZXIg cGFuaWMgdGhhdCBoYXBwZW5lZCB3cml0ZSBhZnRlciBpc3N1aW5nICJ3YXRjaCIgZm9yIGNvbXBh cmlzb24uDQo+DQo+IGh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9jb3JlLnR4dC4xPGh0dHA6Ly9tYWls Lm1pa2VqLmNvbS9jb3JlLnR4dC4xPg0KPg0KPiBodHRwOi8vbWFpbC5taWtlai5jb20vaW5mby4x PGh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9pbmZvLjE+DQo+DQo+IGh0dHA6Ly9tYWlsLm1pa2VqLmNv bS92bWNvcmUuMTxodHRwOi8vbWFpbC5taWtlai5jb20vdm1jb3JlLjE+DQo+DQoNCkkgYWxzbyBu ZWVkIHlvdXIga2VybmVsIGFuZCBkZWJ1ZyBrZXJuZWwgdG8gZnVsbHkgZGVidWcgdGhpcy4NCg0K MSkgRG8gc3NoIHRvIG1hY2hpbmUuDQoyKSB3YXRjaCAtaSAtVyBwdHMvMCAoZG9lcyBub3QgcGFu aWMgb3ZlciBoZXJlKQ0KDQpDYW4geW91IGV4cGxhaW4gd2hhdCBzdGVwIDEgaXM/IEFuIHNjcCA/ DQoNClJlZmNvdW50IGlzIC0xLg0KZl9jb3VudCA9IDB4ZmZmZmZmZmYNCg0KZl9kYXRhID0gMHhm ZmZmZjgwMDE1OGIwNDAwDQoNCkluIHlvdXIgS0dEQiwgY2FuIHlvdSBlbnRlcjoNCg0KaW5mbyAw eGZmZmZmZmZmODFiMDUyZDANCg0KRG9lcyB0aGUgYXR0YWNoZWQgcGF0Y2ggbWFrZSBhbnkgZGlm ZmVyZW5jZT8NCg0KLS1IUFMNCg0KDQpTbyBzb3JyeSwgeWVzIHN0ZXAgb25lLCBzc2ggdG8gbWFj aGluZeKApi4NCg0KRXZlbiBvcGVuIGEgc2Vjb25kIGNvbnNvbGUgb24gdGhlIGNvbXB1dGVyLCBu byBTU0ggYW5kIGRvIOKAnHdhdGNoIOKAk0kgIC1XIHYw4oCdIGl0IHBhbmljcy4NCg0KRXhhbXBs ZSBvZiDigJx3YXRjaCDigJNJIOKAk1cgdjDigJ0gZm9yIGNvbXBhcmlzb24g4oCTIGtlcm5lbC9r ZXJuZWwuZnVsbCBoYXZlIG5vdCBjaGFuZ2VkIHNpbmNlIC4yDQoNCmh0dHA6Ly9tYWlsLm1pa2Vq LmNvbS9jb3JlLnR4dC4zPGh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9jb3JlLnR4dC4zPg0KDQpodHRw Oi8vbWFpbC5taWtlai5jb20vaW5mby4zPGh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9pbmZvLjM+DQoN Cmh0dHA6Ly9tYWlsLm1pa2VqLmNvbS92bWNvcmUuMzxodHRwOi8vbWFpbC5taWtlai5jb20vdm1j b3JlLjM+DQoNCg0KDQoNCg0KRGlzY2xhaW1lcg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgY29tbXVuaWNhdGlvbiBmcm9tIHRoZSBzZW5kZXIgaXMgY29uZmlkZW50aWFsLiBJ dCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHVzZSBieSB0aGUgcmVjaXBpZW50IGFuZCBvdGhlcnMg YXV0aG9yaXplZCB0byByZWNlaXZlIGl0LiBJZiB5b3UgYXJlIG5vdCB0aGUgcmVjaXBpZW50LCB5 b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0 cmlidXRpb24gb3IgdGFraW5nIGFjdGlvbiBpbiByZWxhdGlvbiBvZiB0aGUgY29udGVudHMgb2Yg dGhpcyBpbmZvcm1hdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdm dWwuDQoNClRoaXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgbWFsd2Fy ZSwgYW5kIG1heSBoYXZlIGJlZW4gYXV0b21hdGljYWxseSBhcmNoaXZlZCBieSBNaW1lY2FzdCwg YSBsZWFkZXIgaW4gZW1haWwgc2VjdXJpdHkgYW5kIGN5YmVyIHJlc2lsaWVuY2UuIE1pbWVjYXN0 IGludGVncmF0ZXMgZW1haWwgZGVmZW5zZXMgd2l0aCBicmFuZCBwcm90ZWN0aW9uLCBzZWN1cml0 eSBhd2FyZW5lc3MgdHJhaW5pbmcsIHdlYiBzZWN1cml0eSwgY29tcGxpYW5jZSBhbmQgb3RoZXIg ZXNzZW50aWFsIGNhcGFiaWxpdGllcy4gTWltZWNhc3QgaGVscHMgcHJvdGVjdCBsYXJnZSBhbmQg c21hbGwgb3JnYW5pemF0aW9ucyBmcm9tIG1hbGljaW91cyBhY3Rpdml0eSwgaHVtYW4gZXJyb3Ig YW5kIHRlY2hub2xvZ3kgZmFpbHVyZTsgYW5kIHRvIGxlYWQgdGhlIG1vdmVtZW50IHRvd2FyZCBi dWlsZGluZyBhIG1vcmUgcmVzaWxpZW50IHdvcmxkLiBUbyBmaW5kIG91dCBtb3JlLCB2aXNpdCBv dXIgd2Vic2l0ZS4NCg0KRGlzY2xhaW1lcg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgY29tbXVuaWNhdGlvbiBmcm9tIHRoZSBzZW5kZXIgaXMgY29uZmlkZW50aWFsLiBJdCBp cyBpbnRlbmRlZCBzb2xlbHkgZm9yIHVzZSBieSB0aGUgcmVjaXBpZW50IGFuZCBvdGhlcnMgYXV0 aG9yaXplZCB0byByZWNlaXZlIGl0LiBJZiB5b3UgYXJlIG5vdCB0aGUgcmVjaXBpZW50LCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmli dXRpb24gb3IgdGFraW5nIGFjdGlvbiBpbiByZWxhdGlvbiBvZiB0aGUgY29udGVudHMgb2YgdGhp cyBpbmZvcm1hdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu DQoNClRoaXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgbWFsd2FyZSwg YW5kIG1heSBoYXZlIGJlZW4gYXV0b21hdGljYWxseSBhcmNoaXZlZCBieSBNaW1lY2FzdCwgYSBs ZWFkZXIgaW4gZW1haWwgc2VjdXJpdHkgYW5kIGN5YmVyIHJlc2lsaWVuY2UuIE1pbWVjYXN0IGlu dGVncmF0ZXMgZW1haWwgZGVmZW5zZXMgd2l0aCBicmFuZCBwcm90ZWN0aW9uLCBzZWN1cml0eSBh d2FyZW5lc3MgdHJhaW5pbmcsIHdlYiBzZWN1cml0eSwgY29tcGxpYW5jZSBhbmQgb3RoZXIgZXNz ZW50aWFsIGNhcGFiaWxpdGllcy4gTWltZWNhc3QgaGVscHMgcHJvdGVjdCBsYXJnZSBhbmQgc21h bGwgb3JnYW5pemF0aW9ucyBmcm9tIG1hbGljaW91cyBhY3Rpdml0eSwgaHVtYW4gZXJyb3IgYW5k IHRlY2hub2xvZ3kgZmFpbHVyZTsgYW5kIHRvIGxlYWQgdGhlIG1vdmVtZW50IHRvd2FyZCBidWls ZGluZyBhIG1vcmUgcmVzaWxpZW50IHdvcmxkLiBUbyBmaW5kIG91dCBtb3JlLCB2aXNpdCBvdXIg d2Vic2l0ZS4NCg== --_000_903498700a1c4b32acb8fe283e746189MAILHUBpailocal_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBG b250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0 IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+LnN0eWxlMSB7Zm9udC1mYW1p bHk6ICJUaW1lcyBOZXcgUm9tYW4iO308L3N0eWxlPjwvaGVhZD48Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJvYjo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgZGlkIG5vdCByZW1v dmUgSGFucyBlYXJsaWVyIHBhdGNoLCBidXQgeW91ciDigJxsYXRlc3TigJ0gcGF0Y2ggYXBwbGll ZCBhbmQgY29tcGlsZWQgd2l0aCBubyBlcnJvcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JIGNhbiBub3cgd2F0Y2ggYW5kIGNvbnRyb2wgYSBUVFkgKHYwKSBv ciBhIFNTSCBzZXNzaW9uIChwdHMvMSkgd2l0aG91dCBjcmFzaGluZy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFueXRoaW5nIGVsc2UgeW91IHdvdWxkIGxpa2Ug bWUgdG8gdHJ5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS1t aWtlajxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9iIFdpbmcgW21haWx0bzpy b2IuZng5MDdAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkg MjEsIDIwMjIgOTozMCBQTTxicj4NCjxiPlRvOjwvYj4gTWljaGFlbCBKdW5nICZsdDttaWtlakBw YXltZW50YWxsaWFuY2VpbnRsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEhhbnMgUGV0dGVyIFNl bGFza3kgJmx0O2hwc0BzZWxhc2t5Lm9yZyZndDs7IGZyZWVic2QtY3VycmVudCAmbHQ7ZnJlZWJz ZC1jdXJyZW50QGZyZWVic2Qub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogTmV3IHBh bmljIGluIG1haW4tbjI1MzI3My1hNTJkOGQ0YTZjNjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByZXZpb3VzIGF0dGFjaGVkIHBhdGNoIHNob3VsZCB3 b3JrIGZvciB0ZXN0aW5nIHB1cnBvc2VzLCBidXQgaXQncyBpbmNvcnJlY3QgaWYgYW4gZXJyb3Ig b2NjdXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgZmhvbGQoKSBzaG91bGQgYmUgYmVsb3cgRklMRURFU0NfU1VOTE9DSygpLCB0aGlz IHBhdGNoIGFkZHJlc3NlcyB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEZlYiAyMSwgMjAyMiBhdCA1OjE4IFBNIFJvYiBX aW5nICZsdDs8YSBocmVmPSJtYWlsdG86cm9iLmZ4OTA3QGdtYWlsLmNvbSI+cm9iLmZ4OTA3QGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRyeSB0aGUgYXR0YWNoZWQgcGF0Y2g8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRmViIDIx LCAyMDIyIGF0IDU6MTQgUE0gTWljaGFlbCBKdW5nICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWpA cGF5bWVudGFsbGlhbmNlaW50bC5jb20iIHRhcmdldD0iX2JsYW5rIj5taWtlakBwYXltZW50YWxs aWFuY2VpbnRsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXRvcDpzb2xpZCAjNjY2NjY2IDEu MHB0O2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjNjY2NjY2IDEuMHB0O2Jv cmRlci1yaWdodDpub25lO3BhZGRpbmc6NC4wcHQgMGluIDQuMHB0IDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5D T05GSURFTlRJQUxJVFkgTk9URTogVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkgZm9yIHRo ZSB1c2U8YnI+DQpvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSBpdCBpcyBhZGRy ZXNzZWQgYW5kIG1heSA8YnI+DQpjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJpdmlsZWdl ZCwgY29uZmlkZW50aWFsLCBhbmQgPGJyPg0KZXhlbXB0IGZyb20gZGlzY2xvc3VyZSB1bmRlciBh cHBsaWNhYmxlIGxhdy4gSWYgdGhlIHJlYWRlciA8YnI+DQpvZiB0aGlzIG1lc3NhZ2UgaXMgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IDxicj4NCm5vdGlmaWVkIHRo YXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIDxicj4NCm9mIHRo aXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSA8YnI+ DQpyZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBi eSA8YnI+DQp0ZWxlcGhvbmUgYXQgKDUwMikgMjEyLTQwMDAgb3Igbm90aWZ5IHVzIGF0OiBQQUks IERlcHQuIDk5LCA8YnI+DQoyMTAxIEhpZ2ggV2lja2hhbSBQbGFjZSwgU3VpdGUgMTAxLCBMb3Vp c3ZpbGxlLCBLWSA0MDI0NTxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVy LWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBN aWNoYWVsIEp1bmcNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDIxLCAyMDIy IDk6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+ICdIYW5zIFBldHRlciBTZWxhc2t5JyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmhwc0BzZWxhc2t5Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmhwc0BzZWxhc2t5Lm9y ZzwvYT4mZ3Q7OyBmcmVlYnNkLWN1cnJlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVlYnNkLWN1 cnJlbnRAZnJlZWJzZC5vcmciIHRhcmdldD0iX2JsYW5rIj5mcmVlYnNkLWN1cnJlbnRAZnJlZWJz ZC5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogTmV3IHBhbmljIGluIG1haW4t bjI1MzI3My1hNTJkOGQ0YTZjNjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gSGFucyBQZXR0ZXIgU2VsYXNreSBbPGEgaHJlZj0ibWFpbHRvOmhwc0BzZWxh c2t5Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpocHNAc2VsYXNreS5vcmc8L2E+XQ0KPGJy Pg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMjEsIDIwMjIgODozNCBQTTxicj4NCjxi PlRvOjwvYj4gTWljaGFlbCBKdW5nICZsdDs8YSBocmVmPSJtYWlsdG86bWlrZWpAcGF5bWVudGFs bGlhbmNlaW50bC5jb20iIHRhcmdldD0iX2JsYW5rIj5taWtlakBwYXltZW50YWxsaWFuY2VpbnRs LmNvbTwvYT4mZ3Q7OyBmcmVlYnNkLWN1cnJlbnQgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVlYnNk LWN1cnJlbnRAZnJlZWJzZC5vcmciIHRhcmdldD0iX2JsYW5rIj5mcmVlYnNkLWN1cnJlbnRAZnJl ZWJzZC5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogTmV3IHBhbmljIGluIG1h aW4tbjI1MzI3My1hNTJkOGQ0YTZjNjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiAyLzIyLzIyIDAwOjQyLCBNaWNoYWVsIEp1bmcgd3JvdGU6PGJyPg0KJmd0OyBIaTo8YnI+ DQomZ3Q7IDxicj4NCiZndDsgSSB3YXMgdHJ5aW5nIHRvIHJlbWVtYmVyIHdoYXQgSSBkaWQgdGhh dCB3YXMgb2RkIHdoZW4gdGhpcyBjcmFzaCBvY2N1cnJlZCB0aGVuIGl0PGJyPg0KJmd0OyBoaXQg bWUuIFlvdSBjYW4gcmVwZWF0IHRoaXMgcGFuaWMgYnkgZG9pbmc6PGJyPg0KJmd0OyA8YnI+DQom Z3Q7ICMgd2F0Y2ggLUkgLVcgcHRzLzA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGVyZSBpcyBhbm90 aGVyIHBhbmljIHRoYXQgaGFwcGVuZWQgd3JpdGUgYWZ0ZXIgaXNzdWluZyAmcXVvdDt3YXRjaCZx dW90OyBmb3IgY29tcGFyaXNvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDov L21haWwubWlrZWouY29tL2NvcmUudHh0LjEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9tYWls Lm1pa2VqLmNvbS9jb3JlLnR4dC4xPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YSBocmVmPSJo dHRwOi8vbWFpbC5taWtlai5jb20vaW5mby4xIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vbWFp bC5taWtlai5jb20vaW5mby4xPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YSBocmVmPSJodHRw Oi8vbWFpbC5taWtlai5jb20vdm1jb3JlLjEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly9tYWls Lm1pa2VqLmNvbS92bWNvcmUuMTwvYT48YnI+DQomZ3Q7IDxicj4NCjxicj4NCkkgYWxzbyBuZWVk IHlvdXIga2VybmVsIGFuZCBkZWJ1ZyBrZXJuZWwgdG8gZnVsbHkgZGVidWcgdGhpcy48YnI+DQo8 YnI+DQoxKSBEbyBzc2ggdG8gbWFjaGluZS48YnI+DQoyKSB3YXRjaCAtaSAtVyBwdHMvMCAoZG9l cyBub3QgcGFuaWMgb3ZlciBoZXJlKTxicj4NCjxicj4NCkNhbiB5b3UgZXhwbGFpbiB3aGF0IHN0 ZXAgMSBpcz8gQW4gc2NwID88YnI+DQo8YnI+DQpSZWZjb3VudCBpcyAtMS48YnI+DQpmX2NvdW50 ID0gMHhmZmZmZmZmZjxicj4NCjxicj4NCmZfZGF0YSA9IDB4ZmZmZmY4MDAxNThiMDQwMDxicj4N Cjxicj4NCkluIHlvdXIgS0dEQiwgY2FuIHlvdSBlbnRlcjo8YnI+DQo8YnI+DQppbmZvIDB4ZmZm ZmZmZmY4MWIwNTJkMDxicj4NCjxicj4NCkRvZXMgdGhlIGF0dGFjaGVkIHBhdGNoIG1ha2UgYW55 IGRpZmZlcmVuY2U/PGJyPg0KPGJyPg0KLS1IUFM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvIHNvcnJ5LCB5ZXMgc3Rl cCBvbmUsIHNzaCB0byBtYWNoaW5l4oCmLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+RXZlbiBvcGVuIGEgc2Vjb25kIGNvbnNvbGUgb24gdGhlIGNvbXB1 dGVyLCBubyBTU0ggYW5kIGRvIOKAnHdhdGNoIOKAk0kgJm5ic3A7LVcgdjDigJ0gaXQgcGFuaWNz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkV4YW1wbGUg b2Yg4oCcd2F0Y2gg4oCTSSDigJNXIHYw4oCdIGZvciBjb21wYXJpc29uIOKAkyBrZXJuZWwva2Vy bmVsLmZ1bGwgaGF2ZSBub3QgY2hhbmdlZCBzaW5jZSAuMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly9tYWlsLm1pa2VqLmNvbS9j b3JlLnR4dC4zIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL21haWwubWlrZWouY29tL2NvcmUudHh0 LjM8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEg aHJlZj0iaHR0cDovL21haWwubWlrZWouY29tL2luZm8uMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly9tYWlsLm1pa2VqLmNvbS9pbmZvLjM8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL21haWwubWlrZWouY29tL3ZtY29yZS4z IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL21haWwubWlrZWouY29tL3ZtY29yZS4zPC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5EaXNjbGFpbWVy PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+VGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gZnJvbSB0aGUgc2VuZGVyIGlzIGNvbmZp ZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB1c2UgYnkgdGhlIHJlY2lwaWVudCBh bmQgb3RoZXJzIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBpdC4gSWYgeW91IGFyZSBub3QNCiB0aGUg cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJlLCBj b3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdGFraW5nIGFjdGlvbiBpbiByZWxhdGlvbiBvZiB0aGUg Y29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBt YXkgYmUgdW5sYXdmdWwuPGJyPg0KPGJyPg0KVGhpcyBlbWFpbCBoYXMgYmVlbiBzY2FubmVkIGZv ciB2aXJ1c2VzIGFuZCBtYWx3YXJlLCBhbmQgbWF5IGhhdmUgYmVlbiBhdXRvbWF0aWNhbGx5IGFy Y2hpdmVkIGJ5IE1pbWVjYXN0LCBhIGxlYWRlciBpbiBlbWFpbCBzZWN1cml0eSBhbmQgY3liZXIg cmVzaWxpZW5jZS4gTWltZWNhc3QgaW50ZWdyYXRlcyBlbWFpbCBkZWZlbnNlcyB3aXRoIGJyYW5k IHByb3RlY3Rpb24sIHNlY3VyaXR5IGF3YXJlbmVzcyB0cmFpbmluZywgd2ViIHNlY3VyaXR5LA0K IGNvbXBsaWFuY2UgYW5kIG90aGVyIGVzc2VudGlhbCBjYXBhYmlsaXRpZXMuIE1pbWVjYXN0IGhl bHBzIHByb3RlY3QgbGFyZ2UgYW5kIHNtYWxsIG9yZ2FuaXphdGlvbnMgZnJvbSBtYWxpY2lvdXMg YWN0aXZpdHksIGh1bWFuIGVycm9yIGFuZCB0ZWNobm9sb2d5IGZhaWx1cmU7IGFuZCB0byBsZWFk IHRoZSBtb3ZlbWVudCB0b3dhcmQgYnVpbGRpbmcgYSBtb3JlIHJlc2lsaWVudCB3b3JsZC4gVG8g ZmluZCBvdXQgbW9yZSwgdmlzaXQgb3VyIHdlYnNpdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQoNCg0KPGJyPjxicj48cCBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6 ZToxMHB0OyBjb2xvcjojNjY2NjY2OyI+PGI+RGlzY2xhaW1lcjwvYj48L3A+PHAgc3R5bGU9ImZv bnQtZmFtaWx5OiBWZXJkYW5hOyBmb250LXNpemU6OHB0OyBjb2xvcjojNjY2NjY2OyI+VGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gZnJvbSB0aGUgc2VuZGVy IGlzIGNvbmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB1c2UgYnkgdGhlIHJl Y2lwaWVudCBhbmQgb3RoZXJzIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBpdC4gSWYgeW91IGFyZSBu b3QgdGhlIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xv c3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHRha2luZyBhY3Rpb24gaW4gcmVsYXRpb24g b2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRl ZCBhbmQgbWF5IGJlIHVubGF3ZnVsLjxicj48YnI+VGhpcyBlbWFpbCBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBtYWx3YXJlLCBhbmQgbWF5IGhhdmUgYmVlbiBhdXRvbWF0aWNhbGx5 IGFyY2hpdmVkIGJ5IE1pbWVjYXN0LCBhIGxlYWRlciBpbiBlbWFpbCBzZWN1cml0eSBhbmQgY3li ZXIgcmVzaWxpZW5jZS4gTWltZWNhc3QgaW50ZWdyYXRlcyBlbWFpbCBkZWZlbnNlcyB3aXRoIGJy YW5kIHByb3RlY3Rpb24sIHNlY3VyaXR5IGF3YXJlbmVzcyB0cmFpbmluZywgd2ViIHNlY3VyaXR5 LCBjb21wbGlhbmNlIGFuZCBvdGhlciBlc3NlbnRpYWwgY2FwYWJpbGl0aWVzLiBNaW1lY2FzdCBo ZWxwcyBwcm90ZWN0IGxhcmdlIGFuZCBzbWFsbCBvcmdhbml6YXRpb25zIGZyb20gbWFsaWNpb3Vz IGFjdGl2aXR5LCBodW1hbiBlcnJvciBhbmQgdGVjaG5vbG9neSBmYWlsdXJlOyBhbmQgdG8gbGVh ZCB0aGUgbW92ZW1lbnQgdG93YXJkIGJ1aWxkaW5nIGEgbW9yZSByZXNpbGllbnQgd29ybGQuIFRv IGZpbmQgb3V0IG1vcmUsIHZpc2l0IG91ciB3ZWJzaXRlLjwvcD48L2JvZHk+PC9odG1sPg0K --_000_903498700a1c4b32acb8fe283e746189MAILHUBpailocal_-- From nobody Tue Feb 22 04:48:55 2022 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 568ED19CCFC5 for ; Tue, 22 Feb 2022 04:49:03 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2msV4xTwz4qGV for ; Tue, 22 Feb 2022 04:49:02 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: by mail-ej1-x632.google.com with SMTP id a23so38883932eju.3 for ; Mon, 21 Feb 2022 20:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Go0kaJCv60zUxKgZyZarFSekRRlJqM2WegWiGhHeLTU=; b=dz1WRklxkZAqwoGX3QbGyDD8cFB1Re/OucbPJlZZ2fm/0gDmFNFaeiQDyPXVZqfZxy PiskcWS78pfIPG6w/UIttcwe65DBHVZp+lpJv8cCKMv8fYPHyzwwoEmf7N5P0pUOb8mf /v6lnIV0J+cnWuaoXF6ILnnD2XrVJCl3QufdskL+PVNeHSUPz+DXmOm1O4I/jH0j3tQV fHTbWSNJ4x0qunMxAjrNSVjYm+vtNVqCSWNgV7gxgLLZAO5w363j1e1hp+5gWB/JxIvV a0iZsefOX4evKsGWCelC5EreaEmc3aSsAIjaNNl3pCFwDwHp8OvjRrSs3z9Qe8/qaWs3 5g8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Go0kaJCv60zUxKgZyZarFSekRRlJqM2WegWiGhHeLTU=; b=QsrxOpoK5ugX5UkukFLC3v90aw6OzwaMB7ibKcyaqkHVAOFFwZ069Ri3utBvBxB1f3 d13D8I7QcmR33OeyOg+eqANnzebIh11fFXWKAHleRvQPWEaaZBdqbwUV/bKtm8K3MqlB xXjmoxa969TbKmWBfyjmEP4WVy42T4TNWKR5hxoNYrNrx+cYlwL4LC8wX3fi2o4rhh2C JhzD4U7gOk+zWX/jZCuWs69GBCe0WrizTEU8CkjXi/YM/EAsMpxBADEmrDn8xDUf9hvq etIKJV0z6Aj5i8JhaRPQXec3gVee6sBZSpngLsiffr0bMtT5TfSPXnTbfZfUTYGuGG8r H73A== X-Gm-Message-State: AOAM531YXlrEiRd8QuDbtd1tTf9gUYSlRHE5reaXjgArfqpWOqutGZcX TGFltRoVy4p6oz3vQPmBAC5RKP/0XtWvVIM4xaCuCFblrqk= X-Google-Smtp-Source: ABdhPJzDSqoY+Gbky68hp87STs/KT4FdnCs+2m5pfBB2U77yHeWodoY8UIe4bvibAjA/qnCCzgpcN2XtdwVItf5PtR4= X-Received: by 2002:a17:906:b57:b0:6ce:e31a:524 with SMTP id v23-20020a1709060b5700b006cee31a0524mr17842954ejg.290.1645505341481; Mon, 21 Feb 2022 20:49:01 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> <924c13764ce342cf968ef9a93699be9a@MAIL-HUB.pai.local> <719aa03f-6f34-fdf8-1258-c7e5fcf33043@selasky.org> <794fbec71b714f6ea3931b942f17e1ea@MAIL-HUB.pai.local> <903498700a1c4b32acb8fe283e746189@MAIL-HUB.pai.local> In-Reply-To: <903498700a1c4b32acb8fe283e746189@MAIL-HUB.pai.local> From: Rob Wing Date: Mon, 21 Feb 2022 19:48:55 -0900 Message-ID: Subject: Re: New panic in main-n253273-a52d8d4a6c6: To: Michael Jung Cc: Hans Petter Selasky , freebsd-current Content-Type: multipart/alternative; boundary="0000000000005ae5a605d89411cb" X-Rspamd-Queue-Id: 4K2msV4xTwz4qGV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=dz1WRklx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of robfx907@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=robfx907@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::632:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000005ae5a605d89411cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Think that's it...thanks for testing for the patch. I opened up https://reviews.freebsd.org/D34335 for review. -Rob On Mon, Feb 21, 2022 at 6:05 PM Michael Jung wrote: > Rob: > > > > I did not remove Hans earlier patch, but your =E2=80=9Clatest=E2=80=9D pa= tch applied and > compiled with no errors. > > > > I can now watch and control a TTY (v0) or a SSH session (pts/1) without > crashing. > > > > Anything else you would like me to try? > > > > --mikej > > > > > > *From:* Rob Wing [mailto:rob.fx907@gmail.com] > *Sent:* Monday, February 21, 2022 9:30 PM > *To:* Michael Jung > *Cc:* Hans Petter Selasky ; freebsd-current < > freebsd-current@freebsd.org> > *Subject:* Re: New panic in main-n253273-a52d8d4a6c6: > > > > The previous attached patch should work for testing purposes, but it's > incorrect if an error occurs. > > > > The fhold() should be below FILEDESC_SUNLOCK(), this patch addresses that= . > > > > On Mon, Feb 21, 2022 at 5:18 PM Rob Wing wrote: > > try the attached patch > > > > On Mon, Feb 21, 2022 at 5:14 PM Michael Jung < > mikej@paymentallianceintl.com> wrote: > > > > > > > > CONFIDENTIALITY NOTE: This message is intended only for the use > of the individual or entity to whom it is addressed and may > contain information that is privileged, confidential, and > exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby > notified that any dissemination, distribution or copying > of this communication is strictly prohibited. If you have > received this transmission in error, please notify us by > telephone at (502) 212-4000 or notify us at: PAI, Dept. 99, > 2101 High Wickham Place, Suite 101, Louisville, KY 40245 > > > *From:* Michael Jung > *Sent:* Monday, February 21, 2022 9:06 PM > *To:* 'Hans Petter Selasky' ; freebsd-current < > freebsd-current@freebsd.org> > *Subject:* RE: New panic in main-n253273-a52d8d4a6c6: > > > > *From:* Hans Petter Selasky [mailto:hps@selasky.org ] > *Sent:* Monday, February 21, 2022 8:34 PM > *To:* Michael Jung ; freebsd-current < > freebsd-current@freebsd.org> > *Subject:* Re: New panic in main-n253273-a52d8d4a6c6: > > > > On 2/22/22 00:42, Michael Jung wrote: > > Hi: > > > > I was trying to remember what I did that was odd when this crash > occurred then it > > hit me. You can repeat this panic by doing: > > > > # watch -I -W pts/0 > > > > Here is another panic that happened write after issuing "watch" for > comparison. > > > > http://mail.mikej.com/core.txt.1 > > > > http://mail.mikej.com/info.1 > > > > http://mail.mikej.com/vmcore.1 > > > > I also need your kernel and debug kernel to fully debug this. > > 1) Do ssh to machine. > 2) watch -i -W pts/0 (does not panic over here) > > Can you explain what step 1 is? An scp ? > > Refcount is -1. > f_count =3D 0xffffffff > > f_data =3D 0xfffff800158b0400 > > In your KGDB, can you enter: > > info 0xffffffff81b052d0 > > Does the attached patch make any difference? > > --HPS > > > > > > So sorry, yes step one, ssh to machine=E2=80=A6. > > > > Even open a second console on the computer, no SSH and do =E2=80=9Cwatch = =E2=80=93I -W > v0=E2=80=9D it panics. > > > > Example of =E2=80=9Cwatch =E2=80=93I =E2=80=93W v0=E2=80=9D for compariso= n =E2=80=93 kernel/kernel.full have not > changed since .2 > > > > http://mail.mikej.com/core.txt.3 > > > > http://mail.mikej.com/info.3 > > > > http://mail.mikej.com/vmcore.3 > > > > > > > > > > *Disclaimer* > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and m= ay > be unlawful. > > This email has been scanned for viruses and malware, and may have been > automatically archived by Mimecast, a leader in email security and cyber > resilience. Mimecast integrates email defenses with brand protection, > security awareness training, web security, compliance and other essential > capabilities. Mimecast helps protect large and small organizations from > malicious activity, human error and technology failure; and to lead the > movement toward building a more resilient world. To find out more, visit > our website. > > > > *Disclaimer* > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and m= ay > be unlawful. > > This email has been scanned for viruses and malware, and may have been > automatically archived by Mimecast, a leader in email security and cyber > resilience. Mimecast integrates email defenses with brand protection, > security awareness training, web security, compliance and other essential > capabilities. Mimecast helps protect large and small organizations from > malicious activity, human error and technology failure; and to lead the > movement toward building a more resilient world. To find out more, visit > our website. > --0000000000005ae5a605d89411cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Think that's it...thanks for testing for the patc= h.

I opened up https://reviews.freebsd.org/D34335 for review.

-Rob

On Mon, Feb 21, 2022 at 6:05 PM Michael = Jung <mikej@paymentalli= anceintl.com> wrote:

Rob:

=C2=A0

I did not remove Hans earlier pa= tch, but your =E2=80=9Clatest=E2=80=9D patch applied and compiled with no e= rrors.

=C2=A0

I can now watch and control a TT= Y (v0) or a SSH session (pts/1) without crashing.

=C2=A0

Anything else you would like me = to try?

=C2=A0

--mikej

=C2=A0

=C2=A0

From: Rob Wing [mailto:rob.fx907@gmail.com]
Sent: Monday, February 21, 2022 9:30 PM
To: Michael Jung <mikej@paymentallianceintl.com>
Cc: Hans Petter Selasky <hps@selasky.org>; freebsd-current <freebsd-current@freebsd.org= >
Subject: Re: New panic in main-n253273-a52d8d4a6c6:

=C2=A0

The previous attached patch should work for testing = purposes, but it's incorrect if an error occurs.

=C2=A0

The fhold() should be below FILEDESC_SUNLOCK(), this= patch addresses that.

=C2=A0

On Mon, Feb 21, 2022 at 5:18 PM Rob Wing <rob.fx907@gmail.com&g= t; wrote:

try the attached patch

=C2=A0

On Mon, Feb 21, 2022 at 5:14 PM Michael Jung <mikej@payme= ntallianceintl.com> wrote:

=C2=A0

=C2=A0

= =C2=A0

CONFIDENTIALITY NOTE: T= his message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245


From: Michael Jung
Sent: Monday, February 21, 2022 9:06 PM
To: 'Hans Petter Selasky' <hps@selasky.org>; freebsd-current <freebsd-current@f= reebsd.org>
Subject: RE: New panic in main-n253273-a52d8d4a6c6:=

=C2=A0

From: Hans Petter Selasky [mailto:hps@selasky.org]
Sent: Monday, February 21, 2022 8:34 PM
To: Michael Jung <mikej@paymentallianceintl.com>; freebsd-current = <freebs= d-current@freebsd.org>
Subject: Re: New panic in main-n253273-a52d8d4a6c6:=

=C2=A0

On 2/22/22 00:42, Michael Jung wrote:
> Hi:
>
> I was trying to remember what I did that was odd when this crash occur= red then it
> hit me. You can repeat this panic by doing:
>
> # watch -I -W pts/0
>
> Here is another panic that happened write after issuing "watch&qu= ot; for comparison.
>
> http://mail.mikej.com/core.txt.1
>
> http://mail.mikej.com/info.1
>
> http://mail.mikej.com/vmcore.1
>

I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count =3D 0xffffffff

f_data =3D 0xfffff800158b0400

In your KGDB, can you enter:

info 0xffffffff81b052d0

Does the attached patch make any difference?

--HPS

=C2=A0

=C2=A0

So sorry, yes step one, ssh to m= achine=E2=80=A6.

=C2=A0

Even open a second console on th= e computer, no SSH and do =E2=80=9Cwatch =E2=80=93I =C2=A0-W v0=E2=80=9D it= panics.

=C2=A0

Example of =E2=80=9Cwatch =E2=80= =93I =E2=80=93W v0=E2=80=9D for comparison =E2=80=93 kernel/kernel.full hav= e not changed since .2

=C2=A0

http://mail.mikej.com/core.txt.3<= u>

=C2=A0

http://mail.mikej.com/info.3

=C2=A0

http://mail.mikej.com/vmcore.3

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Disclaimer<= /u>

The information contained in this communication fro= m the sender is confidential. It is intended solely for use by the recipien= t and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distr= ibution or taking action in relation of the contents of this information is= strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been auto= matically archived by Mimecast, a leader in email security and cyber resili= ence. Mimecast integrates email defenses with brand protection, security aw= areness training, web security, compliance and other essential capabilities. Mimecast helps protect large = and small organizations from malicious activity, human error and technology= failure; and to lead the movement toward building a more resilient world. = To find out more, visit our website.



Disclaimer

The information contained in this communication from th= e sender is confidential. It is intended solely for use by the recipient an= d others authorized to receive it. If you are not the recipient, you are he= reby notified that any disclosure, copying, distribution or taking action i= n relation of the contents of this information is strictly prohibited and m= ay be unlawful.

This email has been scanned for viruses and malware,= and may have been automatically archived by Mimecast, a leader in email se= curity and cyber resilience. Mimecast integrates email defenses with brand = protection, security awareness training, web security, compliance and other= essential capabilities. Mimecast helps protect large and small organizatio= ns from malicious activity, human error and technology failure; and to lead= the movement toward building a more resilient world. To find out more, vis= it our website.

--0000000000005ae5a605d89411cb-- From nobody Tue Feb 22 18:43:46 2022 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 B246519D1D87 for ; Tue, 22 Feb 2022 18:43:57 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K37Nr5rY4z3wST for ; Tue, 22 Feb 2022 18:43:56 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: by mail-oi1-x235.google.com with SMTP id ay7so15531870oib.8 for ; Tue, 22 Feb 2022 10:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uqMQhz4pZ/kbOVGf+LOJ4VGrjdKDzYdUGaR8eLUg+lU=; b=VEfxUBAJDjVn/upcfpIOiAIiOlE3dcc3qa2MpsHFX9SxAc2pKrkKlXg2LRAL/MoV+V WIcyM3uB6onDOg7pfwSu8/nhtmh6gFITryb3vOGwVCdlmOfgRY5U4b20asHLHppdT1IF EVlFP6JvaJm4t3+NzlCFCSXVrrdnak+fbglf/tsCxbdjp3A5kgdi4PIcpug6N3+8LaRN rw2Y5VDyhXTBgUfsc3Vzr/yCPYsebQMqj+UC8qf3U2OTxYtQfaPVMhSxQHCwf5l1BetS iNz4IatXP8COKxNEzxF/WJJEY+4n1Jc3VuCEaJDP03yvTTsdpQNbhMnhtEYKKY3lrOGe bPLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uqMQhz4pZ/kbOVGf+LOJ4VGrjdKDzYdUGaR8eLUg+lU=; b=mHYaJa90bk76Nmyzic6iSH26Ssy6Q8NFTF2C3KOthE2SpesUgzNPz+qvaQftiOqmWu cfSCKvaYmoxgDqchRoYEhCgCQ/8yT4QoWykOVnnT/0eF6OQX+O/+Po9W15IGcaVXfvdV rWdkJUGuFXPOrK0pNiBCFST5f63wSBDZ0PEEzdNTtJH4dLPFwFUd6ETpgeH4XzVMfJFJ mgEYuTol3KKu3tZmZL2p4wPMBGDGrUDzhdotaZ3SLVSSfMdon8z8meOPbkOddMmOPmf/ bXsRg/YiuqcQ1t7ijAtDTGi5y/ffL1Ihy5woD45cp4jjE18U0Wx8he6BTGjFabciUZC4 JLUQ== X-Gm-Message-State: AOAM532WzaH/IwQjS8+jtkqF9q4cHC+p5rK/Dv7DJ5O6LYs2pJiK/so3 Nrmkyo5QofQ2A+kin01EWoQo2jIuPDUoqzbXsvJR1WdRs+c= X-Google-Smtp-Source: ABdhPJz5FdYqGJroGQAhEIYz6c5mwAV0T14BGHESbkbVkh1LOCE3aT4thZV2jLSxcbvJQpVHqZXJhVRnwj6loUwWlrY= X-Received: by 2002:a05:6808:1794:b0:2d4:81d7:23f8 with SMTP id bg20-20020a056808179400b002d481d723f8mr2693424oib.9.1645555434569; Tue, 22 Feb 2022 10:43:54 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <6fcc161dd23b4f7ebe7cc789f11c017e@MAIL-HUB.pai.local> <924c13764ce342cf968ef9a93699be9a@MAIL-HUB.pai.local> <719aa03f-6f34-fdf8-1258-c7e5fcf33043@selasky.org> <794fbec71b714f6ea3931b942f17e1ea@MAIL-HUB.pai.local> <903498700a1c4b32acb8fe283e746189@MAIL-HUB.pai.local> In-Reply-To: From: Rob Wing Date: Tue, 22 Feb 2022 09:43:46 -0900 Message-ID: Subject: Re: New panic in main-n253273-a52d8d4a6c6: To: Michael Jung Cc: Hans Petter Selasky , freebsd-current Content-Type: multipart/alternative; boundary="00000000000022c2b205d89fbb2b" X-Rspamd-Queue-Id: 4K37Nr5rY4z3wST X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=VEfxUBAJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of robfx907@gmail.com designates 2607:f8b0:4864:20::235 as permitted sender) smtp.mailfrom=robfx907@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::235:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000022c2b205d89fbb2b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Mike, Should be fixed in commit 0a2f498234023008d9a3b13ad7fc8fd81d384bab Thanks for the report -Rob On Mon, Feb 21, 2022 at 7:48 PM Rob Wing wrote: > Think that's it...thanks for testing for the patch. > > I opened up https://reviews.freebsd.org/D34335 for review. > > -Rob > > On Mon, Feb 21, 2022 at 6:05 PM Michael Jung < > mikej@paymentallianceintl.com> wrote: > >> Rob: >> >> >> >> I did not remove Hans earlier patch, but your =E2=80=9Clatest=E2=80=9D p= atch applied and >> compiled with no errors. >> >> >> >> I can now watch and control a TTY (v0) or a SSH session (pts/1) without >> crashing. >> >> >> >> Anything else you would like me to try? >> >> >> >> --mikej >> >> >> >> >> >> *From:* Rob Wing [mailto:rob.fx907@gmail.com] >> *Sent:* Monday, February 21, 2022 9:30 PM >> *To:* Michael Jung >> *Cc:* Hans Petter Selasky ; freebsd-current < >> freebsd-current@freebsd.org> >> *Subject:* Re: New panic in main-n253273-a52d8d4a6c6: >> >> >> >> The previous attached patch should work for testing purposes, but it's >> incorrect if an error occurs. >> >> >> >> The fhold() should be below FILEDESC_SUNLOCK(), this patch addresses tha= t. >> >> >> >> On Mon, Feb 21, 2022 at 5:18 PM Rob Wing wrote: >> >> try the attached patch >> >> >> >> On Mon, Feb 21, 2022 at 5:14 PM Michael Jung < >> mikej@paymentallianceintl.com> wrote: >> >> >> >> >> >> >> >> CONFIDENTIALITY NOTE: This message is intended only for the use >> of the individual or entity to whom it is addressed and may >> contain information that is privileged, confidential, and >> exempt from disclosure under applicable law. If the reader >> of this message is not the intended recipient, you are hereby >> notified that any dissemination, distribution or copying >> of this communication is strictly prohibited. If you have >> received this transmission in error, please notify us by >> telephone at (502) 212-4000 or notify us at: PAI, Dept. 99, >> 2101 High Wickham Place, Suite 101, Louisville, KY 40245 >> >> >> *From:* Michael Jung >> *Sent:* Monday, February 21, 2022 9:06 PM >> *To:* 'Hans Petter Selasky' ; freebsd-current < >> freebsd-current@freebsd.org> >> *Subject:* RE: New panic in main-n253273-a52d8d4a6c6: >> >> >> >> *From:* Hans Petter Selasky [mailto:hps@selasky.org ] >> *Sent:* Monday, February 21, 2022 8:34 PM >> *To:* Michael Jung ; freebsd-current < >> freebsd-current@freebsd.org> >> *Subject:* Re: New panic in main-n253273-a52d8d4a6c6: >> >> >> >> On 2/22/22 00:42, Michael Jung wrote: >> > Hi: >> > >> > I was trying to remember what I did that was odd when this crash >> occurred then it >> > hit me. You can repeat this panic by doing: >> > >> > # watch -I -W pts/0 >> > >> > Here is another panic that happened write after issuing "watch" for >> comparison. >> > >> > http://mail.mikej.com/core.txt.1 >> > >> > http://mail.mikej.com/info.1 >> > >> > http://mail.mikej.com/vmcore.1 >> > >> >> I also need your kernel and debug kernel to fully debug this. >> >> 1) Do ssh to machine. >> 2) watch -i -W pts/0 (does not panic over here) >> >> Can you explain what step 1 is? An scp ? >> >> Refcount is -1. >> f_count =3D 0xffffffff >> >> f_data =3D 0xfffff800158b0400 >> >> In your KGDB, can you enter: >> >> info 0xffffffff81b052d0 >> >> Does the attached patch make any difference? >> >> --HPS >> >> >> >> >> >> So sorry, yes step one, ssh to machine=E2=80=A6. >> >> >> >> Even open a second console on the computer, no SSH and do =E2=80=9Cwatch= =E2=80=93I -W >> v0=E2=80=9D it panics. >> >> >> >> Example of =E2=80=9Cwatch =E2=80=93I =E2=80=93W v0=E2=80=9D for comparis= on =E2=80=93 kernel/kernel.full have not >> changed since .2 >> >> >> >> http://mail.mikej.com/core.txt.3 >> >> >> >> http://mail.mikej.com/info.3 >> >> >> >> http://mail.mikej.com/vmcore.3 >> >> >> >> >> >> >> >> >> >> *Disclaimer* >> >> The information contained in this communication from the sender is >> confidential. It is intended solely for use by the recipient and others >> authorized to receive it. If you are not the recipient, you are hereby >> notified that any disclosure, copying, distribution or taking action in >> relation of the contents of this information is strictly prohibited and = may >> be unlawful. >> >> This email has been scanned for viruses and malware, and may have been >> automatically archived by Mimecast, a leader in email security and cyber >> resilience. Mimecast integrates email defenses with brand protection, >> security awareness training, web security, compliance and other essentia= l >> capabilities. Mimecast helps protect large and small organizations from >> malicious activity, human error and technology failure; and to lead the >> movement toward building a more resilient world. To find out more, visit >> our website. >> >> >> >> *Disclaimer* >> >> The information contained in this communication from the sender is >> confidential. It is intended solely for use by the recipient and others >> authorized to receive it. If you are not the recipient, you are hereby >> notified that any disclosure, copying, distribution or taking action in >> relation of the contents of this information is strictly prohibited and = may >> be unlawful. >> >> This email has been scanned for viruses and malware, and may have been >> automatically archived by Mimecast, a leader in email security and cyber >> resilience. Mimecast integrates email defenses with brand protection, >> security awareness training, web security, compliance and other essentia= l >> capabilities. Mimecast helps protect large and small organizations from >> malicious activity, human error and technology failure; and to lead the >> movement toward building a more resilient world. To find out more, visit >> our website. >> > --00000000000022c2b205d89fbb2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Mike,

Should be fixed in= commit 0a2f498234023008d9a3b13ad7fc8fd81d384bab

Thanks for the report

-Rob<= br>

On Mon, Feb 21, 2022 at 7:48 PM Rob Wing <rob.fx907@gmail.com> wrote:
Think that's= it...thanks for testing for the patch.

I open= ed up http= s://reviews.freebsd.org/D34335 for review.

-Rob

On Mon, Feb 21, 2022 at 6:05 PM Michael Jung <mikej@paymentallia= nceintl.com> wrote:

Rob:

=C2=A0

I did not remove Hans earlier pa= tch, but your =E2=80=9Clatest=E2=80=9D patch applied and compiled with no e= rrors.

=C2=A0

I can now watch and control a TT= Y (v0) or a SSH session (pts/1) without crashing.

=C2=A0

Anything else you would like me = to try?

=C2=A0

--mikej

=C2=A0

=C2=A0

From: Rob Wing [mailto:rob.fx907@gmail.com]
Sent: Monday, February 21, 2022 9:30 PM
To: Michael Jung <mikej@paymentallianceintl.com>
Cc: Hans Petter Selasky <hps@selasky.org>; freebsd-current <freebsd-current@freebsd.org= >
Subject: Re: New panic in main-n253273-a52d8d4a6c6:

=C2=A0

The previous attached patch should work for testing = purposes, but it's incorrect if an error occurs.

=C2=A0

The fhold() should be below FILEDESC_SUNLOCK(), this= patch addresses that.

=C2=A0

On Mon, Feb 21, 2022 at 5:18 PM Rob Wing <rob.fx907@gmail.com&g= t; wrote:

try the attached patch

=C2=A0

On Mon, Feb 21, 2022 at 5:14 PM Michael Jung <mikej@payme= ntallianceintl.com> wrote:

=C2=A0

=C2=A0

= =C2=A0

CONFIDENTIALITY NOTE: T= his message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245


From: Michael Jung
Sent: Monday, February 21, 2022 9:06 PM
To: 'Hans Petter Selasky' <hps@selasky.org>; freebsd-current <freebsd-current@f= reebsd.org>
Subject: RE: New panic in main-n253273-a52d8d4a6c6:=

=C2=A0

From: Hans Petter Selasky [mailto:hps@selasky.org]
Sent: Monday, February 21, 2022 8:34 PM
To: Michael Jung <mikej@paymentallianceintl.com>; freebsd-current = <freebs= d-current@freebsd.org>
Subject: Re: New panic in main-n253273-a52d8d4a6c6:=

=C2=A0

On 2/22/22 00:42, Michael Jung wrote:
> Hi:
>
> I was trying to remember what I did that was odd when this crash occur= red then it
> hit me. You can repeat this panic by doing:
>
> # watch -I -W pts/0
>
> Here is another panic that happened write after issuing "watch&qu= ot; for comparison.
>
> http://mail.mikej.com/core.txt.1
>
> http://mail.mikej.com/info.1
>
> http://mail.mikej.com/vmcore.1
>

I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count =3D 0xffffffff

f_data =3D 0xfffff800158b0400

In your KGDB, can you enter:

info 0xffffffff81b052d0

Does the attached patch make any difference?

--HPS

=C2=A0

=C2=A0

So sorry, yes step one, ssh to m= achine=E2=80=A6.

=C2=A0

Even open a second console on th= e computer, no SSH and do =E2=80=9Cwatch =E2=80=93I =C2=A0-W v0=E2=80=9D it= panics.

=C2=A0

Example of =E2=80=9Cwatch =E2=80= =93I =E2=80=93W v0=E2=80=9D for comparison =E2=80=93 kernel/kernel.full hav= e not changed since .2

=C2=A0

http://mail.mikej.com/core.txt.3<= u>

=C2=A0

http://mail.mikej.com/info.3

=C2=A0

http://mail.mikej.com/vmcore.3

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Disclaimer<= /u>

The information contained in this communication fro= m the sender is confidential. It is intended solely for use by the recipien= t and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distr= ibution or taking action in relation of the contents of this information is= strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been auto= matically archived by Mimecast, a leader in email security and cyber resili= ence. Mimecast integrates email defenses with brand protection, security aw= areness training, web security, compliance and other essential capabilities. Mimecast helps protect large = and small organizations from malicious activity, human error and technology= failure; and to lead the movement toward building a more resilient world. = To find out more, visit our website.



Disclaimer

The information contained in this communication from th= e sender is confidential. It is intended solely for use by the recipient an= d others authorized to receive it. If you are not the recipient, you are he= reby notified that any disclosure, copying, distribution or taking action i= n relation of the contents of this information is strictly prohibited and m= ay be unlawful.

This email has been scanned for viruses and malware,= and may have been automatically archived by Mimecast, a leader in email se= curity and cyber resilience. Mimecast integrates email defenses with brand = protection, security awareness training, web security, compliance and other= essential capabilities. Mimecast helps protect large and small organizatio= ns from malicious activity, human error and technology failure; and to lead= the movement toward building a more resilient world. To find out more, vis= it our website.

--00000000000022c2b205d89fbb2b-- From nobody Tue Feb 22 21:44:41 2022 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 B1A0E19D5B67 for ; Tue, 22 Feb 2022 21:44:54 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3CPd4PPHz4tsT for ; Tue, 22 Feb 2022 21:44:53 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x135.google.com with SMTP id w4so2677095ilj.5 for ; Tue, 22 Feb 2022 13:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=QrGMtxmyNPlDj2bnXDwv+bwkylrJG7s0RwPjqEBnIK0=; b=e9Qfpcs4wvxcN5ZjtyJ7FI1N4/S/HRIpgjqO1s0RlbaI44Yot+QG5xSStfeLrRP2MH xSq5S225uTGgh6ZxkzKJ5fqjGeup3fJwlRmyw1v+3o8nJJ8hWFOUoMMq5S1rERa42KFE hZ8PEof6JQNa+oDYdAWtBkywegoDiuCRLv8LrxrhjHfBH4+/XKbaVB1nDge46H1DYA0f AZ8OA6w5lzBGyyhPNZAMK3GXMWGCWtQ5QpUF6YAeQlTJVNMJViFvQQ7Ogh7s07ou0VI0 2/QzUz0ssKjckdUq1n3QOZYhcNS3LR7yq4mzUdrvPeOu1r/s2tV7iLqVfhHHpK6LMEWC NXkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=QrGMtxmyNPlDj2bnXDwv+bwkylrJG7s0RwPjqEBnIK0=; b=vuR5rVBa1NnXz85LsfpzPAm8AUq2uA0ws8f/18vtIGQTzo/8UQHNHzHTTEsqyIZh6R bq52qyYu5lROvugl0WhTmffaLj+aiBr3ouNIVdbPABFeXSUhN+s38vaVLlMWQZljT+vs 9OmNL+RdEH8QlBkYkUUv73AWpF8nZggU7XzLX6UFajv1LCj0bD1cycc4GgbXzYJeylv1 WxGcxT1zVGloIYNQh8wOwDkN0WGgqim7OGj3Gj6VFyx9NweGfyLuKjdvB3/oWeS6oMTX qmkvA19QBRAXRE4AlL2Pzn0st8kb5Z06uOg6Wgo0l3KHwAnR8PUWx+Ycwb+pK2vcdnlI JccA== X-Gm-Message-State: AOAM532MvH2nU/Cs+jGTfOe8LSR9m76/Tiz/+zShqh1WsoH0TsevDfNl eHUz/IyrM/EqUvVfu75kNP381OCg7jyp8zLwhFc2st0IVJqHNA== X-Google-Smtp-Source: ABdhPJyj0trCXPZkNDofHue6Fgup5BH67SBviAdvDyymk/YhYJlRn5H+3PSKaGGNt6K2tyE/IdUK116QJnRjGBN2xmE= X-Received: by 2002:a05:6e02:194a:b0:2c2:59e2:d48e with SMTP id x10-20020a056e02194a00b002c259e2d48emr5806260ilu.128.1645566292684; Tue, 22 Feb 2022 13:44:52 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Michael Schuster Date: Tue, 22 Feb 2022 22:44:41 +0100 Message-ID: Subject: Re: "linker_load_file ... unsupported file type" after upgrade attempts on -CURRENT To: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="00000000000054728005d8a2422e" X-Rspamd-Queue-Id: 4K3CPd4PPHz4tsT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=e9Qfpcs4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::135 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::135:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000054728005d8a2422e Content-Type: text/plain; charset="UTF-8" to respond to myself: I bit the bullet and installed one of the latest memstick images of -CURRENT , and am back up and running - with amdgpu and drm-current, and KDE (which had stopped working for me on the previous setup a while ago). Sorry if anyone's gone to any lengths here, though I didn't get any feedback. Thx Michael On Sun, Feb 20, 2022 at 3:12 PM Michael Schuster wrote: > Hi, > > I'm currently running on -CURRENT from November, though I think the > message for amdgpu.ko ("kernel: linker_load_file: /boot/modules/amdgpu.ko - > unsupported file type") started to appear as early as last August. Since > this isn't my daily driver (yet!), I didn't notice for quite a while, and > scfb is adequate for what little I currently do on FreeBSD. > When I initially installed this machine in Aug 2020, my GPU (Vega10 > Renoir) wasn't supported by DRM, so over time I made several builds of the > graphics/drm-devel-kmod port, which worked for a while last year. > > In the last weeks, in the time I managed to set aside for this work, I > made several attempts to bring this machine up-to-date, using "pkg > upgrade", building my own from /usr/src (always up-to-date using 'git > pull'), and beinstall.sh. (both separately and in combination). I always > work with separate build environments for these attempts. > All my upgrade attempts have resulted in a system that boots, but neither > starts X nor lets me log in on a console. There are "linker_load_file ... " > message for several .ko files, all preceded by a line like this: > > "KLD hconf.ko: depends on kernel - not available or version mismatchmodule > name" > > here are the paths I get this message about: > > /boot/kernel/cuse.ko > /boot/kernel/hconf.ko > /boot/kernel/hms.ko > /boot/kernel/hmt.ko > /boot/kernel/intpm.ko > /boot/kernel/lindebugfs.ko > /boot/kernel/linux.ko > /boot/kernel/linux64.ko > /boot/modules/amdgpu.ko > /boot/modules/drm.ko > > The information I found on the Internet about this error message seem to > indicate that I need to re-build the .ko being reported by the message with > the current kernel, which is .. hard if I can't even log in ;-). I would > also not expect a version mismatch after a pkg upgrade (but no, I didn't go > through all the output that generated). > > Does anyone have an idea what I can do to get past this obstacle? I could > of course always re-install, but that feels like giving in :-) > > TIA > Michael > -- > Michael Schuster > http://recursiveramblings.wordpress.com/ > recursion, n: see 'recursion' > -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' --00000000000054728005d8a2422e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
to respond to myself: = I bit the bullet and installed one of the latest memstick images of -CURREN= T , and am back up and running - with amdgpu and drm-current, and KDE (whic= h had stopped working for me on the previous setup a while ago).
Sorry if anyone's gone to any lengths here, though I didn= 't get any feedback.

Thx
Michael

On Sun, Feb 20, 2022 at 3:1= 2 PM Michael Schuster <mich= aelsprivate@gmail.com> wrote:
Hi,

I'm currently running on -CUR= RENT from November, though I think the message for amdgpu.ko ("kernel:= linker_load_file: /boot/modules/amdgpu.ko - unsupported file type") s= tarted to appear as early as last August. Since this isn't my daily dri= ver (yet!), I didn't notice for quite a while, and scfb is adequate for= what little I currently do on FreeBSD.
When I initially installed this mac= hine in Aug 2020, my GPU (Vega10 Renoir) wasn't supported by DRM, so ov= er time I made several builds of the graphics/drm-devel-kmod port, which wo= rked for a while last year.

In the last weeks, in t= he time I managed to set aside for this work, I made several attempts to br= ing this machine up-to-date, using "pkg upgrade", building my own= from /usr/src (always up-to-date using 'git pull'), and beinstall.= sh. (both separately and in combination). I always work with separate build= environments for these attempts.
All my upgrade attempts have resulted in = a system that boots, but neither starts X nor lets me log in on a console. = There are "linker_load_file ... " message for several .ko files, = all preceded by a line like this:

"KLD hconf.ko: depends on kerne= l - not available or version mismatchmodule name"

here are t= he paths I get this message about:

/boot/kernel/cuse.ko
/boot/kerne= l/hconf.ko
/boot/kernel/hms.ko
/boot/kernel/hmt.ko
/boot/kernel/in= tpm.ko
/boot/kernel/lindebugfs.ko
/boot/kernel/linux.ko
/boot/kern= el/linux64.ko
/boot/modules/amdgpu.ko
/boot/modules/drm.ko
<= /div>

The information I found on the Internet about this err= or message seem to indicate that I need to re-build the .ko being reported = by the message with the current kernel, which is .. hard if I can't eve= n log in ;-). I would also not expect a version mismatch after a pkg upgrad= e (but no, I didn't go through all the output that generated).

Does anyone have an idea what I can do to get past th= is obstacle? I could of course always re-install, but that feels like givin= g in :-)

TIA
Michael
--
recursion, n: see 'recursion'


--
recursion, n: see 'recursion'=
--00000000000054728005d8a2422e-- From nobody Tue Feb 22 22:46:08 2022 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 A2B3319E33F5 for ; Tue, 22 Feb 2022 22:46:43 +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 4K3Dmy6VKXz3MDF; Tue, 22 Feb 2022 22:46:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 21MMkEkZ046936 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 23 Feb 2022 00:46:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 21MMk8xW046935; Wed, 23 Feb 2022 00:46:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Feb 2022 00:46:08 +0200 From: Konstantin Belousov To: Alexander Motin Cc: Mike Karels , Tomoaki AOKI , "Chen, Alvin W" , freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-ID: References: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> <59cbcfe2-cd53-69d8-65d6-7a79e656f494@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: <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4K3Dmy6VKXz3MDF X-Spamd-Bar: / 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 X-Spamd-Result: default: False [-0.82 / 15.00]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_SPAM_MEDIUM(0.40)[0.403]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.23)[-0.227]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 19, 2022 at 07:26:24PM -0500, Alexander Motin wrote: > On 19.02.2022 13:23, Konstantin Belousov wrote: > > On Sat, Feb 19, 2022 at 12:14:16PM -0500, Alexander Motin wrote: > > > On 19.02.2022 12:02, Mike Karels wrote: > > > > On 18 Feb 2022, at 20:55, Tomoaki AOKI wrote: > > > > > Just a thought, but can it be the reason with timing (e.g., rendezvous > > > > > within (i)threads, hardware controlls without using hardware timer) > > > > > problem? > > > > > > > > > > On FreeBSD, IIUC, multi processor (multi core) implementation assumes > > > > > SMP (differs only clock speed) and end up with difference of > > > > > performance at same clock speed within P-core and E-core, possibly. > > > > > > > > Another possibility is that the system is confused by having hyperthreading > > > > on the P cores but not the E cores. > > > > > > No, I've tried to disable SMT and different number of cores to make it look > > > identical and uniform for the scheduler. The only thing I could not test is > > > disabling all P cores to test only E, the motherboard does not allow that, > > > requiring at least one P core enabled. > > > > Does the kernel select MWAIT as the idle method? If you set idle to spin, > > is anything change? > > By default kernel selects ACPI, using MWAIT: > machdep.idle: acpi > dev.cpu.0.cx_method: C1/mwait/hwc C2/mwait/hwc C3/mwait/hwc > > I've tried to do in loader: > set machdep.idle_mwait=0 > set machdep.idle="spin" (also tried "hlt") > , but without visible positive effects. I was only interested in spin, for hlt there is no chance if spin did not worked. Ok, the next step is to get the CPU feature reports from P- vs. E- cores. Patch below should work, with verbose boot. diff --git a/sys/x86/x86/identcpu.c b/sys/x86/x86/identcpu.c index 849f532dbf8b..9e4da4722f77 100644 --- a/sys/x86/x86/identcpu.c +++ b/sys/x86/x86/identcpu.c @@ -246,7 +246,7 @@ printcpuinfo(void) u_int regs[4], i; char *brand; - printf("CPU: "); + printf("CPU %d: ", PCPU_GET(cpuid)); #ifdef __i386__ cpu_class = cpus[cpu].cpu_class; strncpy(cpu_model, cpus[cpu].cpu_name, sizeof (cpu_model)); diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c index 3b0e25172d0d..4299eb5348e6 100644 --- a/sys/x86/x86/mp_x86.c +++ b/sys/x86/x86/mp_x86.c @@ -1089,7 +1089,7 @@ init_secondary_tail(void) load_es(_udatasel); load_fs(_ufssel); #endif - +printcpuinfo(); mtx_unlock_spin(&ap_boot_mtx); /* Wait until all the AP's are up. */ From nobody Tue Feb 22 23:23:17 2022 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 3EFFA19EF1BE for ; Tue, 22 Feb 2022 23:23:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3FbD2h5Dz3rGK for ; Tue, 22 Feb 2022 23:23:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qv1-xf31.google.com with SMTP id o5so3929824qvm.3 for ; Tue, 22 Feb 2022 15:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Qux7oT66x+YeHNOdZkH7DSl0qJ2t4HPBQVlWd5ziAJs=; b=Dof61SAT9R/+s6x4hmyGdefdLSMw9N/0exvs88/86VEfFI1wAUGy+l/PBBK4Bf3+PL T2nlqjmPwQU6WC1UyqVB0tghV+Aw3t/VI88etRDxBrTr/CfuLRlWyfXJkk6+VFJF8+sI FBnPv7aWjudUJ9OtUBxjOvMnT2gOjR7ja4l18IHhZmP8SQJh3GrJVe7+uLaR2obfc80Q Q6Od/icLgbbikKaWliTsjuR5Gj3m6WC/iTJlwVvVirs8SXwQNwDq3lAWHi/GnN+/haD7 c/dDw311OMr+MybrnvcT15Wchrr4zMs8JGLv4NwAO7HL2AoVXBZnNPm2DiEAUlSLdu13 Okfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Qux7oT66x+YeHNOdZkH7DSl0qJ2t4HPBQVlWd5ziAJs=; b=MgKtbpF9hDkZqkF6c7ge98C59fgPr9sA8EkjPRafflvw6KDCrYfV57l1FOro8e6S6Q MUKMPXBPMKGKKOVQrxfTcnGvXdO838JcKzDJiPcC3LY3hnsYEBbkbSK50DcC7+ofRojK fnqRv97aGz37QcZEWZPmlM6MxUw+BewrzeJtRW8Zi/3v2MbdFDiJWTO6DqTJsI9xru/M clcwn+aWcNVxhHCYpHEMCEB9Lx6lANypn7JKtjP3irMjDqAuGsxyZH3aieon7kpxxofD dkyGKfZ6RZdmTG6J1L+rvOfSF5EuEnVclAShVcEjD9/fBqtVunldvT2UhDkeDHE+OnhJ ibLw== X-Gm-Message-State: AOAM531YdTctAGA3tfj1p0wbTRkJMJZrFwwuE4CodhFEV95Q90VTNdST RbnWZSfsI5uAk1REuL7CsV9jNo39syI= X-Google-Smtp-Source: ABdhPJyIAC4hRNwkMP0Ij25XZKVTa2bbZoVI1c7mLS59aCBTSSGtnRUVwOORZ44Uh/z5vjdBjVz6YA== X-Received: by 2002:ac8:7f83:0:b0:2d0:1769:f2c1 with SMTP id z3-20020ac87f83000000b002d01769f2c1mr24651812qtj.427.1645572199474; Tue, 22 Feb 2022 15:23:19 -0800 (PST) Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id n16sm650052qkn.115.2022.02.22.15.23.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Feb 2022 15:23:18 -0800 (PST) Message-ID: <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> Date: Tue, 22 Feb 2022 18:23:17 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Content-Language: en-US To: Konstantin Belousov Cc: Mike Karels , Tomoaki AOKI , "Chen, Alvin W" , freebsd-current@freebsd.org References: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> From: Alexander Motin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K3FbD2h5Dz3rGK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Dof61SAT; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::f31 as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-1.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f31:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 22.02.2022 17:46, Konstantin Belousov wrote: > Ok, the next step is to get the CPU feature reports from P- vs. E- cores. > Patch below should work, with verbose boot. Not much difference on that level: --- zzzp 2022-02-22 18:18:24.531704000 -0500 +++ zzze 2022-02-22 18:18:18.631236000 -0500 @@ -1,22 +1,21 @@ -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 Stepping=2 Features=0xbfebfbff Features2=0x7ffafbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x239ca7eb Structured Extended Features2=0x98c027ac Structured Extended Features3=0xfc1cc410 XSAVE Features=0xf IA32_ARCH_CAPS=0xd6b VT-x: Basic Features=0x3da0500 Pin-Based Controls=0xff Primary Processor Controls=0xfffbfffe Secondary Processor Controls=0xf5d7fff Exit Controls=0x3da0500 Entry Controls=0x3da0500 EPT Features=0x6f34141 VPID Features=0x10f01 TSC: P-state invariant, performance statistics -64-Byte prefetching -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line -- Alexander Motin From nobody Tue Feb 22 23:30:28 2022 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 8013919C92DD for ; Tue, 22 Feb 2022 23:30:58 +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 4K3Fm16bv4z3tgS; Tue, 22 Feb 2022 23:30:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 21MNUSxq057841 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 23 Feb 2022 01:30:31 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 21MNUSaS057840; Wed, 23 Feb 2022 01:30:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Feb 2022 01:30:28 +0200 From: Konstantin Belousov To: Alexander Motin Cc: Mike Karels , Tomoaki AOKI , "Chen, Alvin W" , freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-ID: References: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@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: <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4K3Fm16bv4z3tgS X-Spamd-Bar: + 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 X-Spamd-Result: default: False [1.55 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.42)[-0.421]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.97)[0.974]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > On 22.02.2022 17:46, Konstantin Belousov wrote: > > Ok, the next step is to get the CPU feature reports from P- vs. E- cores. > > Patch below should work, with verbose boot. > > Not much difference on that level: > > --- zzzp 2022-02-22 18:18:24.531704000 -0500 > +++ zzze 2022-02-22 18:18:18.631236000 -0500 > @@ -1,22 +1,21 @@ > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 Stepping=2 > Features=0xbfebfbff > Features2=0x7ffafbff > AMD Features=0x2c100800 > AMD Features2=0x121 > Structured Extended Features=0x239ca7eb > Structured Extended Features2=0x98c027ac > Structured Extended Features3=0xfc1cc410 > XSAVE Features=0xf > IA32_ARCH_CAPS=0xd6b > VT-x: Basic Features=0x3da0500 > Pin-Based Controls=0xff > Primary Processor Controls=0xfffbfffe > Secondary Processor Controls=0xf5d7fff > Exit Controls=0x3da0500 > Entry Controls=0x3da0500 > EPT Features=0x6f34141 > VPID Features=0x10f01 > TSC: P-state invariant, performance statistics > -64-Byte prefetching > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > Show me the full verbose dmesg of the boot then. As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. From nobody Thu Feb 24 01:23:51 2022 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 EC83C19D5A35 for ; Thu, 24 Feb 2022 01:24:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3wDd58jSz3jSk; Thu, 24 Feb 2022 01:24:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 21O1NvRi043884 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 24 Feb 2022 03:24:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 21O1Np0Y043881; Thu, 24 Feb 2022 03:23:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Feb 2022 03:23:51 +0200 From: Konstantin Belousov To: Alexander Motin Cc: Mike Karels , Tomoaki AOKI , "Chen, Alvin W" , freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-ID: References: <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <06768ef6-c88e-b6c7-0db3-f61eb4230937@FreeBSD.org> <470db559-7e7d-1af7-5983-2858814329d2@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=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4K3wDd58jSz3jSk X-Spamd-Bar: / 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 X-Spamd-Result: default: False [-0.31 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.23)[-0.228]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.917]; NEURAL_SPAM_LONG(0.84)[0.837]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Wed, Feb 23, 2022 at 12:25:24PM -0500, Alexander Motin wrote: > On 22.02.2022 19:00, Konstantin Belousov wrote: > > On Tue, Feb 22, 2022 at 06:53:09PM -0500, Alexander Motin wrote: > > > On 22.02.2022 18:41, Konstantin Belousov wrote: > > > > On Tue, Feb 22, 2022 at 06:38:24PM -0500, Alexander Motin wrote: > > > > > On 22.02.2022 18:30, Konstantin Belousov wrote: > > > > > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > > > > > > > > > > Do you mean it to be a workaround for TrueNAS 12, or it should provide some > > > > > information? The system is at the office and has no IPMI, so I can't switch > > > > > the boot device from home right now. > > > > I intended to see if it is the cause or related feature. > > > > > > I'll try that on the 12 tomorrow, if applicable. > > > > Yes should be relevant still. > > It did the trick. I repeated several times successful boots with the pcid > disabled, and failed ones with default enabled. In attachment you may find > verbose serial console output captures with pcid disabled and enabled, > though without the cpuinfo patch. During the testing I had only one P and > one E cores enabled to reduce noise. Only after that I found P core having > SMT enabled, but I then repeated without SMT also, so it is indeed > irrelevant. > > I'm curios, what in pcid could differentiate the P and E cores, and have it > got fixed in latest stable/13, or I am just "unlucky" to not reproduce it > there? I am curious as well. PCID works on both big Intel cores, and on small cores like Apollo Lake etc. So the fact that it does not properly interact in P/E settings either mean that there is something I did not accounted for from the spec, or there is a bug in silicon. I have no idea why do we work on stable/13 and HEAD. There were enough changes to PCID code there, but it was mostly restructuring and polishing. So the only way to get more understanding is to bisect to see which commit on HEAD fixed the boot. From nobody Thu Feb 24 02:21:56 2022 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 162E119E069F for ; Thu, 24 Feb 2022 02:21:58 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3xVs2Qfpz3qgT for ; Thu, 24 Feb 2022 02:21:57 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To: From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2+CZCjLCRXhuquV3YLVMZdYznvU2KJFQVUY1RB38INE=; b=sF+EMDfL5umHl3cioH7nCHZgjj 86bLcsTjosGw+rnRlpDPOYDeEyKbEXp4vEUufIqY9UkL6ssnRs+yUZpMWXelc5CE16zL2FNDVjMxd GWcY9s0cBp6fbzglRaPXgj4TaqSjJQ1k6RNWWGwa+cXtlxTGuqxSAl+RZxlioBPhvYPmyVa6CErm7 Ef02H41kzmVf1oO9dLX5yfSIOqaHIMP/q5pKg7GO2DF2gc4mxpirR8jOKsQBhAg8g8RbBAgEDOSEL 1sm/xToF9kw/gh9Le18aLIpZORFDOQtXW+x2oYpse+9TX7RWrpHGl30zL8GW6ru3H10bAcXC+iBmG Jh50X8hA==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:18653 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nN3lU-000LpY-4Y for freebsd-current@freebsd.org; Wed, 23 Feb 2022 20:21:56 -0600 Received: from 2600:1700:210:b18f:cd39:c42e:bc5b:5db5 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 23 Feb 2022 20:21:56 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Wed, 23 Feb 2022 20:21:56 -0600 From: Larry Rosenman To: Freebsd current Subject: ZFS PANIC: HELP. Message-ID: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K3xVs2Qfpz3qgT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=sF+EMDfL; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 've got my main dev box that crashes on 14 with the screen shot at https://www.lerctr.org/~ler/14-zfs-crash.png. Booting from a 13-REL USB installer it imports and scrubs. Ideas? I can either video conference with shared screen or give access to the console via my Dominion KVM. Any help/ideas/etc welcome I really need to get this box back. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Thu Feb 24 02:41:47 2022 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 E5F0819E3C72 for ; Thu, 24 Feb 2022 02:41:50 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3xxp14Jrz3tFN for ; Thu, 24 Feb 2022 02:41:50 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qv1-xf2f.google.com with SMTP id h13so1431041qvk.12 for ; Wed, 23 Feb 2022 18:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=BuHpE5+MTI/q8x3Z0YdHcmSZhqSVbns1CdK3KtxR/jM=; b=ZdPFlUdttJM381q6ev2cET90F6RE3+zVM5/VgCXE5kZFVlqD3+4P+EJyXO69f+qsCA fE7w9uvO0+C604c6T2RaqybmBnTVoY4f0UTrms25XZqtQFG1TdQBSUstJ166jx3aC5zq VFDSW/5S+hzETMgBJ+1kD0Xqai2tPRQF5rRhZQ5zLQSi5RaSquxnr5umZ3kO01P4WT1P 6cdtfx5Zqp6XuMmXdi/Y+tnhTdlDZE1IrojN2SQiKOrR82oduilgOGqidm5T3Tla8/hb rwoj2c59CJXctEe4XPUg2vcSiiMzfzg4xu2nTNUcMNhpfadiCVOwC/GEb1td/gdYpAk7 hitQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=BuHpE5+MTI/q8x3Z0YdHcmSZhqSVbns1CdK3KtxR/jM=; b=1ItCzYdc8Y+yAlgBdIOZsEKTykSoxgcwyugJj+8eEPNXRoxf45JqwxysM61doqR93X t4EVBc/3NtZ9f93IHRNKKCwok8CsbUtnnUQWF+9CRMM4P+pcEG4wA8IMVfs/fzTdY3qj uE5tXLCJWQgCgHOOCc7A38CmtI39/bDdHbKcvKqRMGYG7IvA3KpTlHdqt4G/+3M1gvSO lnopcMiK/6JOBLsYfxmbH8Zt3S8rY8mfeDVr8lIy2Gul1RCngiRKDyFGDT5XupVC2cmV jQIYvGU9i6bniQ6sn/aJtcf0qa0oO2CWkfq0EAryZrZuHHxd2qf1Iltq7C4eI4vhNVOB E/Fw== X-Gm-Message-State: AOAM532VQv+rUtLVJBLHn3YEXu15+2Q+xvaW+HEQ0Fst6yvtVVtwWfZq 8sBqft7TGrhFUP/W10cOugQhNMAMNTY= X-Google-Smtp-Source: ABdhPJx6GxSsv5kNyEzd2zu8lFSXcOb9FQbf0YA+d2RIS0abmzb1AnMJwmEOG3LDSQKsGCgfL0otYw== X-Received: by 2002:a05:622a:3c9:b0:2dd:7c32:7b9a with SMTP id k9-20020a05622a03c900b002dd7c327b9amr569712qtx.589.1645670509415; Wed, 23 Feb 2022 18:41:49 -0800 (PST) Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id h190sm720053qkf.70.2022.02.23.18.41.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Feb 2022 18:41:49 -0800 (PST) Message-ID: <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> Date: Wed, 23 Feb 2022 21:41:47 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: ZFS PANIC: HELP. Content-Language: en-US To: Larry Rosenman , Freebsd current References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> From: Alexander Motin In-Reply-To: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K3xxp14Jrz3tFN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZdPFlUdt; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::f2f as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; SUBJ_ALL_CAPS(1.20)[16]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2f:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Larry, The panic you are getting is an assertion, enabled by kernel built with INVARIANTS option. On 13 you may just not have that debugging enabled to hit the issue. But that may be only a consequence. Original problem I guess in possibly corrupted ZFS intent log records (or false positive), that could happen so due to use of -F recovery option on `zpool import`, that supposed to try import pool at earlier transaction group if there is some metadata corruption found. It is not supposed to work 100% and only a last resort. Though may be that assertion is just excessively strict for that specific recovery case. If as you say pool can be imported and scrubbed on 13, then I'd expect following clean export should allow later import on 14 without -F. On 23.02.2022 21:21, Larry Rosenman wrote: > > 've got my main dev box that crashes on 14 with the screen shot at > https://www.lerctr.org/~ler/14-zfs-crash.png. > Booting from a 13-REL USB installer it imports and scrubs. > > Ideas? > > I can either video conference with shared screen or give access to the > console via my Dominion KVM. > > Any help/ideas/etc welcome I really need to get this box back. > > -- Alexander Motin From nobody Thu Feb 24 02:52:00 2022 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 A226819E61A5 for ; Thu, 24 Feb 2022 02:52:02 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3y9Y3sTQz3vpq; Thu, 24 Feb 2022 02:52:01 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=zcqGsdyxiJjZbogg743dqRgp9TJujYU6E0iRdfyRIjs=; b=fAHdAmBREFAwj6DNLQ0GFzixY3 qI7GvKKZRqDNRfPYbCvdTn9blMjRuqMjkjtYUY7GFEioCb4/wvghnDazIUVAlW9bGOKxkoDUQFYzA 2aif3cvegrRn7Uj9bWOZBLrFCmCFM9/hjAqQqSZ9S6XlVTuzWcg3vlu10yVK5MKnoa80c5TAknR/p 7OSks+Ba7NCbkifPOeHXQPN8tO9xakAptwTkhyEWf+PBzzVnLtWonVpmxBv30BkYsm6SzA2q9P5zO wVLUat83toBIYMNFGMafi2wH56nM3HVOddWS06kXHOEBqIzy5cIseIimTVrVUUBFI9uDc0r8uJagX pspFUAQQ==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:52159 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nN4Ea-000Md0-9O; Wed, 23 Feb 2022 20:52:00 -0600 Received: from 2600:1700:210:b18f:cd39:c42e:bc5b:5db5 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 23 Feb 2022 20:52:00 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Wed, 23 Feb 2022 20:52:00 -0600 From: Larry Rosenman To: Alexander Motin Cc: Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> Message-ID: <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K3y9Y3sTQz3vpq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=fAHdAmBR; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02/23/2022 8:41 pm, Alexander Motin wrote: > Hi Larry, > > The panic you are getting is an assertion, enabled by kernel built > with INVARIANTS option. On 13 you may just not have that debugging > enabled to hit the issue. But that may be only a consequence. > Original problem I guess in possibly corrupted ZFS intent log records > (or false positive), that could happen so due to use of -F recovery > option on `zpool import`, that supposed to try import pool at earlier > transaction group if there is some metadata corruption found. It is > not supposed to work 100% and only a last resort. Though may be that > assertion is just excessively strict for that specific recovery case. > If as you say pool can be imported and scrubbed on 13, then I'd expect > following clean export should allow later import on 14 without -F. > > On 23.02.2022 21:21, Larry Rosenman wrote: >> >> 've got my main dev box that crashes on 14 with the screen shot at >> https://www.lerctr.org/~ler/14-zfs-crash.png. >> Booting from a 13-REL USB installer it imports and scrubs. >> >> Ideas? >> >> I can either video conference with shared screen or give access to the >> console via my Dominion KVM. >> >> Any help/ideas/etc welcome I really need to get this box back. >> >> How can I import the pool withOUT it mounting the FileSystems so I can export it cleanly on the 13 system? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Thu Feb 24 02:58:22 2022 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 D3C2519E7992 for ; Thu, 24 Feb 2022 02:58:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3yJw6WVPz4RPD for ; Thu, 24 Feb 2022 02:58:24 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qv1-xf2c.google.com with SMTP id x3so1518196qvd.8 for ; Wed, 23 Feb 2022 18:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=8bdJAF2bknVuHw4qGrRPteoO3y2yENI6EMK8kZAupmA=; b=iT6LF2OVLXDSyo9wp7RYBR8w0RC7yBvw9zP7IzXhSh5E7I9lhU53ZGnQ+08ISTLWy9 91xjzf2QhWTGqm0msw3ETjwH53gkXbgTEgkpAAs/4FE2Uz7+jU827kooGksT4ItlU5fp K3gK9PuH1Cf+P5NGcOR95G0i+304JNFwo3B2460MTiAeAEqvp8kN/8mFjMBs0R5r1skd h6lRDx9zICh4T08/EI3DJsC7pXuzHErUFfVMw9UNqe2HL66gE1sOS7lRBQaWMQUzr+iA FLE1jyt7df9Rbo8oj9x2glP85AbAHkQm7Wcxww8tisQEjuL7vUcyLXGrmHDiumR6gGlE oVBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=8bdJAF2bknVuHw4qGrRPteoO3y2yENI6EMK8kZAupmA=; b=aXE1ufm/VHpCDC+GR5uZEvkBPCQrmNiHEsraUV40ET/XPBruvR9vGUMeXPsG3xit16 bozoaWzceqNHwpnHOnElXDgMtRPo7Gm49i+PSR2NuV8g7x4GHIpLZqI4wRBxpY7QHy1N B9mV008K2fcTNMTq2XCCS18JXSso04rIiH//umSNkNJji89a51q3aBpYASiy/vCnhje0 a0BsY1mfUdAmVifNp2l6oLZ5yEYOzPQFJ5kcttLGhvJBga2o5zOt8Xxw6QdQXf+tuEyZ D2SpDjk6ZeEkyGz1EodCIumSQdi/66+sCa1vfGbcQAugUZwHP6gvWY5XwHaZ4WxEVbkV 3VOg== X-Gm-Message-State: AOAM533ypu1KmqhGzwYL2PTU+kEna+CtRvppxvWAxAFFs+3zr4eJjf9q nns78ezcvfnlhZC4zNEnliSS3UWp2Ss= X-Google-Smtp-Source: ABdhPJz0TIa2O0ugyezQrgf5j3ooFZ0NygyPCyrhqwM4EwLDmeFNCN7t52Yow54yFtkrak8jmT6S4w== X-Received: by 2002:a0c:e9cb:0:b0:42c:1810:820c with SMTP id q11-20020a0ce9cb000000b0042c1810820cmr456657qvo.5.1645671504130; Wed, 23 Feb 2022 18:58:24 -0800 (PST) Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id o11sm884534qta.79.2022.02.23.18.58.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Feb 2022 18:58:23 -0800 (PST) Message-ID: Date: Wed, 23 Feb 2022 21:58:22 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: ZFS PANIC: HELP. Content-Language: en-US To: Larry Rosenman Cc: Freebsd current References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> From: Alexander Motin In-Reply-To: <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K3yJw6WVPz4RPD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=iT6LF2OV; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::f2c as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; SUBJ_ALL_CAPS(1.20)[16]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2c:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 23.02.2022 21:52, Larry Rosenman wrote: > On 02/23/2022 8:41 pm, Alexander Motin wrote: >> Hi Larry, >> >> The panic you are getting is an assertion, enabled by kernel built >> with INVARIANTS option.  On 13 you may just not have that debugging >> enabled to hit the issue.  But that may be only a consequence. >> Original problem I guess in possibly corrupted ZFS intent log records >> (or false positive), that could happen so due to use of -F recovery >> option on `zpool import`, that supposed to try import pool at earlier >> transaction group if there is some metadata corruption found.  It is >> not supposed to work 100% and only a last resort.  Though may be that >> assertion is just excessively strict for that specific recovery case. >> If as you say pool can be imported and scrubbed on 13, then I'd expect >> following clean export should allow later import on 14 without -F. >> >> On 23.02.2022 21:21, Larry Rosenman wrote: >>> >>> 've got my main dev box that crashes on 14 with the screen shot at >>> https://www.lerctr.org/~ler/14-zfs-crash.png. >>> Booting from a 13-REL USB installer it imports and scrubs. >>> >>> Ideas? >>> >>> I can either video conference with shared screen or give access to >>> the console via my Dominion KVM. >>> >>> Any help/ideas/etc welcome I really need to get this box back. >>> >>> > How can I import the pool withOUT it mounting the FileSystems so I can > export it cleanly on the 13 system? Why do you need to import without mounting file systems? I think you may actually wish them to be mounted to replay their ZILs. Just use -R option to mount file systems in some different place. -- Alexander Motin From nobody Thu Feb 24 03:01:19 2022 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 A8C9F19E8CCC for ; Thu, 24 Feb 2022 03:01:22 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3yNK3pc0z4Sn2; Thu, 24 Feb 2022 03:01:21 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ISrhe2gwAUW3YsBibDoF4f0hoTS+3pHX8PcTQstI6xE=; b=YuJeY2ZiIZrU+nRIZSMcaSjUpj Rm+TIn+/WDJCkedUSasFGsMGcBiBmboXefnbqA/FvaCMC69nW3Z6Y4titfQFSuSwIaD3eNS+wfeVK eeQKPL09OsbMsQ9H9BY2bkpHKknbAVM0OS29zxUGnGWqMZQywhJ4uIlP/mun94JqW8eSID2AreHyY oIpnTkutZntFG3CoBZ2+FxHxOksptBBn7s41GG7nXH2uRwYMRsOxDQMAVn9QL2kogimjExGF2vxfR 5TOSres2vGXECpUbBW0z36dpyr17ahdwXad7ftcZc3S335FDz5Z0kG5sVVqwjx6EuZK1pzgbPD2wP SWSKYQpw==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:39327 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nN4Nc-000MnQ-De; Wed, 23 Feb 2022 21:01:20 -0600 Received: from 2600:1700:210:b18f:cd39:c42e:bc5b:5db5 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 23 Feb 2022 21:01:19 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Wed, 23 Feb 2022 21:01:19 -0600 From: Larry Rosenman To: Alexander Motin Cc: Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> Message-ID: <6182c57bf1859482e72af78037c399e4@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K3yNK3pc0z4Sn2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=YuJeY2Zi; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02/23/2022 8:58 pm, Alexander Motin wrote: > On 23.02.2022 21:52, Larry Rosenman wrote: >> On 02/23/2022 8:41 pm, Alexander Motin wrote: >>> Hi Larry, >>> >>> The panic you are getting is an assertion, enabled by kernel built >>> with INVARIANTS option.  On 13 you may just not have that debugging >>> enabled to hit the issue.  But that may be only a consequence. >>> Original problem I guess in possibly corrupted ZFS intent log records >>> (or false positive), that could happen so due to use of -F recovery >>> option on `zpool import`, that supposed to try import pool at earlier >>> transaction group if there is some metadata corruption found.  It is >>> not supposed to work 100% and only a last resort.  Though may be that >>> assertion is just excessively strict for that specific recovery case. >>> If as you say pool can be imported and scrubbed on 13, then I'd >>> expect >>> following clean export should allow later import on 14 without -F. >>> >>> On 23.02.2022 21:21, Larry Rosenman wrote: >>>> >>>> 've got my main dev box that crashes on 14 with the screen shot at >>>> https://www.lerctr.org/~ler/14-zfs-crash.png. >>>> Booting from a 13-REL USB installer it imports and scrubs. >>>> >>>> Ideas? >>>> >>>> I can either video conference with shared screen or give access to >>>> the console via my Dominion KVM. >>>> >>>> Any help/ideas/etc welcome I really need to get this box back. >>>> >>>> >> How can I import the pool withOUT it mounting the FileSystems so I can >> export it cleanly on the 13 system? > > Why do you need to import without mounting file systems? I think you > may actually wish them to be mounted to replay their ZILs. Just use > -R option to mount file systems in some different place. I get the errors shown at: https://www.lerctr.org/~ler/14-mount-R-output.png Should I worry? Or do something(tm) here? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Thu Feb 24 03:15:11 2022 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 8BF1A19EADD0 for ; Thu, 24 Feb 2022 03:15:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3yhR4Y7vz4VYf for ; Thu, 24 Feb 2022 03:15:19 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qk1-x72c.google.com with SMTP id j78so812265qke.2 for ; Wed, 23 Feb 2022 19:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=k2JPOKGQEGI4QrBOHkih+PjadiotiV7q8nEvmK7gjR8=; b=Hv05wPtAE0ggQ0KX/uo9cCxA6zxJWzADUwYh0EWA7Svdk9YUcETMkwD681y2XdELMx 53lhI/Fv12IyOMqDPMuILxyfeiJg6iMi6VO2xlUwYRvGe1ulq36Jp6KnFTwAnj+XqLEC habcYnzorZIuvScwtp2sEqR1Y2mMLHFcYUozVjSvngHbWHob2gyWqNYLuypeLaV2VgVs bH4e5Y4viKLTnQlgJVM31VBoAYZ3T9Lol34PV5Tw5xDP/WPKv65RRyZUkUvmIeByd5L+ jFYoezbc4M22TBpuxPqdTJcZza2uFP5OQ8zn0+0C9Cuf62Vz+rBnEwIYlLjAdP3C9pEn B36Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=k2JPOKGQEGI4QrBOHkih+PjadiotiV7q8nEvmK7gjR8=; b=cqwUhyr/JAtK8B+B0pScnQdGT72RvdtJz2YJWd3+v3ahMa9kLnCcw7lgeFxB0ho/ZP 3mkp2Qz28EZPEZc3Gn3YSbEL6nr40wCEDY2bCfeZhRJZjv3ImpRJ9Xh0rvVeLY4DBy/u MyWWg/Kngh313qX9T7gtM1P3wp7hkQwIWoNjoHzWCBGxeAukkWlbEJD1d7gaRsH3D7iQ 6B9inJETCkBJFjO7G+ZyoBgiJyHZRF+KwhSDaQmSfgPqpjWLIuVgBRGbDax3Cc8bkFT8 VQ3tLA8US4sBYRSPwmcZmF2rrY0QUPceDAildI90fh06oN1SGMLqyo8FfgYM9+WbiZ9c zYJg== X-Gm-Message-State: AOAM5336Q4lGqLCCsm69/mSb4awxFPgnE/mbl+JVFI1shEZ+7r+kAiAO hKLoXAWB7gk/jsHCtJsZlt0YmEh83Jk= X-Google-Smtp-Source: ABdhPJxI39YZiWoiunlWm1mCBjwvPsD0BVz1WboB1L+0ZcOFcYSbbARd52F+JZY/6eawPD3nnQGTBw== X-Received: by 2002:a05:620a:578:b0:649:63d7:bb15 with SMTP id p24-20020a05620a057800b0064963d7bb15mr111635qkp.3.1645672512824; Wed, 23 Feb 2022 19:15:12 -0800 (PST) Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234]) by smtp.gmail.com with ESMTPSA id e9sm745531qkm.27.2022.02.23.19.15.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Feb 2022 19:15:12 -0800 (PST) Message-ID: <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> Date: Wed, 23 Feb 2022 22:15:11 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: ZFS PANIC: HELP. Content-Language: en-US To: Larry Rosenman Cc: Freebsd current References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> From: Alexander Motin In-Reply-To: <6182c57bf1859482e72af78037c399e4@lerctr.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K3yhR4Y7vz4VYf X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Hv05wPtA; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::72c as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; SUBJ_ALL_CAPS(1.20)[16]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72c:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 23.02.2022 22:01, Larry Rosenman wrote: > On 02/23/2022 8:58 pm, Alexander Motin wrote: >> On 23.02.2022 21:52, Larry Rosenman wrote: >>> On 02/23/2022 8:41 pm, Alexander Motin wrote: >>>> Hi Larry, >>>> >>>> The panic you are getting is an assertion, enabled by kernel built >>>> with INVARIANTS option.  On 13 you may just not have that debugging >>>> enabled to hit the issue.  But that may be only a consequence. >>>> Original problem I guess in possibly corrupted ZFS intent log records >>>> (or false positive), that could happen so due to use of -F recovery >>>> option on `zpool import`, that supposed to try import pool at earlier >>>> transaction group if there is some metadata corruption found.  It is >>>> not supposed to work 100% and only a last resort.  Though may be that >>>> assertion is just excessively strict for that specific recovery case. >>>> If as you say pool can be imported and scrubbed on 13, then I'd expect >>>> following clean export should allow later import on 14 without -F. >>>> >>>> On 23.02.2022 21:21, Larry Rosenman wrote: >>>>> >>>>> 've got my main dev box that crashes on 14 with the screen shot at >>>>> https://www.lerctr.org/~ler/14-zfs-crash.png. >>>>> Booting from a 13-REL USB installer it imports and scrubs. >>>>> >>>>> Ideas? >>>>> >>>>> I can either video conference with shared screen or give access to >>>>> the console via my Dominion KVM. >>>>> >>>>> Any help/ideas/etc welcome I really need to get this box back. >>>>> >>>>> >>> How can I import the pool withOUT it mounting the FileSystems so I >>> can export it cleanly on the 13 system? >> >> Why do you need to import without mounting file systems?  I think you >> may actually wish them to be mounted to replay their ZILs.  Just use >> -R option to mount file systems in some different place. > > I get the errors shown at: > https://www.lerctr.org/~ler/14-mount-R-output.png > > Should I worry?  Or do something(tm) here? This looks weird, but may possibly depend on mount points topology, whether /mnt is writable, etc. What happen if you export it now and try to import it in normal way on 14 without -F? -- Alexander Motin From nobody Thu Feb 24 03:27:45 2022 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 F190E19EDA71 for ; Thu, 24 Feb 2022 03:27:47 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3yyq1rm2z4XYZ; Thu, 24 Feb 2022 03:27:47 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ij7UO/0xQeWQYWwcBpATilBdEBPdE/SZqt5/Chly1CI=; b=x4eGpLXE/AWMan17VXHAN8z5ZK AOnbjzQM3+R357vK//2GvEdu18iBJ8SgW7ISanvshf6y7zjJXkYD1fqGkZXpQIKGAXe3Vqc4nkpg/ MRyePYYygXGP1e9cqLeeX8xlju64FJWAcY8P0OpxzL8hHci2NyPyWuC+oD6Xzs0IBvcOMcL6AXWlR SA1zCAoUWQNEZJ7+JqTmnRataSrJlYQaViLxduhctYrTA1yJRFHVt57NWbtfelt3F7bL6iArqsNho +kFta9Uxj1qLXg+ieR3sSX4gqrKqepTSjlUtBjAVE7KhHa5XimsfpQdUBIdXSyO/hwi4ctmqatLLg gYDc8WEw==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:58369 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nN4nB-000NC1-Eu; Wed, 23 Feb 2022 21:27:45 -0600 Received: from 2600:1700:210:b18f:cd39:c42e:bc5b:5db5 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 23 Feb 2022 21:27:45 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Wed, 23 Feb 2022 21:27:45 -0600 From: Larry Rosenman To: Alexander Motin Cc: Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> Message-ID: <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K3yyq1rm2z4XYZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=x4eGpLXE; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.75 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-0.95)[-0.955]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02/23/2022 9:15 pm, Alexander Motin wrote: > On 23.02.2022 22:01, Larry Rosenman wrote: >> On 02/23/2022 8:58 pm, Alexander Motin wrote: >>> On 23.02.2022 21:52, Larry Rosenman wrote: >>>> On 02/23/2022 8:41 pm, Alexander Motin wrote: >>>>> Hi Larry, >>>>> >>>>> The panic you are getting is an assertion, enabled by kernel built >>>>> with INVARIANTS option.  On 13 you may just not have that debugging >>>>> enabled to hit the issue.  But that may be only a consequence. >>>>> Original problem I guess in possibly corrupted ZFS intent log >>>>> records >>>>> (or false positive), that could happen so due to use of -F recovery >>>>> option on `zpool import`, that supposed to try import pool at >>>>> earlier >>>>> transaction group if there is some metadata corruption found.  It >>>>> is >>>>> not supposed to work 100% and only a last resort.  Though may be >>>>> that >>>>> assertion is just excessively strict for that specific recovery >>>>> case. >>>>> If as you say pool can be imported and scrubbed on 13, then I'd >>>>> expect >>>>> following clean export should allow later import on 14 without -F. >>>>> >>>>> On 23.02.2022 21:21, Larry Rosenman wrote: >>>>>> >>>>>> 've got my main dev box that crashes on 14 with the screen shot at >>>>>> https://www.lerctr.org/~ler/14-zfs-crash.png. >>>>>> Booting from a 13-REL USB installer it imports and scrubs. >>>>>> >>>>>> Ideas? >>>>>> >>>>>> I can either video conference with shared screen or give access to >>>>>> the console via my Dominion KVM. >>>>>> >>>>>> Any help/ideas/etc welcome I really need to get this box back. >>>>>> >>>>>> >>>> How can I import the pool withOUT it mounting the FileSystems so I >>>> can export it cleanly on the 13 system? >>> >>> Why do you need to import without mounting file systems?  I think you >>> may actually wish them to be mounted to replay their ZILs.  Just use >>> -R option to mount file systems in some different place. >> >> I get the errors shown at: >> https://www.lerctr.org/~ler/14-mount-R-output.png >> >> Should I worry?  Or do something(tm) here? > > This looks weird, but may possibly depend on mount points topology, > whether /mnt is writable, etc. What happen if you export it now and > try to import it in normal way on 14 without -F? It crashes just after root mount (this is the boot pool and only pool on the system), seeL https://www.lerctr.org/~ler/14-BOOT-Crash.png -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Thu Feb 24 15:57:14 2022 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 6B2AB19D77B0 for ; Thu, 24 Feb 2022 15:57:17 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4Hbc4zj2z4twX; Thu, 24 Feb 2022 15:57:16 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+i4bG89VZm9005+mZsXIkj4LyXlrzf841nlwXIHPNL8=; b=JIv4kh/PyidLPb+8Kux2ZRJL0g 4Qp4leaFUHAyA/eKQBFwPfQ8pss5Xfq/Xt0iWu8POWj8HlxogbxBFLQ4C9tVMsrTYYTHcE94csVM4 Kk28geUAQPSsBWOOryr7Ea/4XXobd8LMzyXU/FYJ9SnRpil6GInCLihxMhC8MAbFB/KwFq1vmY1OS OwyT4jv9AmzWUDPgYsfCTn7FswdEhI+afPqbpl3et+Fr1o55IawvqdAyUcgUW0NpPDIs2hBcyqjOT OclN1/ayNXqarfHxC8S73amDR5DwTEC30MQMI+3RHr506l8uLVKolioY1/NUd+eikoUdLbs/I8Vdx tXk7JndQ==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:63382 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nNGUV-0008gX-0F; Thu, 24 Feb 2022 09:57:15 -0600 Received: from 2600:1700:210:b18f:cc53:f3ee:b613:c3a6 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Feb 2022 09:57:14 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Thu, 24 Feb 2022 09:57:14 -0600 From: Larry Rosenman To: Alexander Motin Cc: Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> Message-ID: <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K4Hbc4zj2z4twX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b="JIv4kh/P"; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-0.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02/23/2022 9:27 pm, Larry Rosenman wrote: > On 02/23/2022 9:15 pm, Alexander Motin wrote: >> On 23.02.2022 22:01, Larry Rosenman wrote: >>> On 02/23/2022 8:58 pm, Alexander Motin wrote: >>>> On 23.02.2022 21:52, Larry Rosenman wrote: >>>>> On 02/23/2022 8:41 pm, Alexander Motin wrote: >>>>>> Hi Larry, >>>>>> >>>>>> The panic you are getting is an assertion, enabled by kernel built >>>>>> with INVARIANTS option.  On 13 you may just not have that >>>>>> debugging >>>>>> enabled to hit the issue.  But that may be only a consequence. >>>>>> Original problem I guess in possibly corrupted ZFS intent log >>>>>> records >>>>>> (or false positive), that could happen so due to use of -F >>>>>> recovery >>>>>> option on `zpool import`, that supposed to try import pool at >>>>>> earlier >>>>>> transaction group if there is some metadata corruption found.  It >>>>>> is >>>>>> not supposed to work 100% and only a last resort.  Though may be >>>>>> that >>>>>> assertion is just excessively strict for that specific recovery >>>>>> case. >>>>>> If as you say pool can be imported and scrubbed on 13, then I'd >>>>>> expect >>>>>> following clean export should allow later import on 14 without -F. >>>>>> >>>>>> On 23.02.2022 21:21, Larry Rosenman wrote: >>>>>>> >>>>>>> 've got my main dev box that crashes on 14 with the screen shot >>>>>>> at https://www.lerctr.org/~ler/14-zfs-crash.png. >>>>>>> Booting from a 13-REL USB installer it imports and scrubs. >>>>>>> >>>>>>> Ideas? >>>>>>> >>>>>>> I can either video conference with shared screen or give access >>>>>>> to the console via my Dominion KVM. >>>>>>> >>>>>>> Any help/ideas/etc welcome I really need to get this box back. >>>>>>> >>>>>>> >>>>> How can I import the pool withOUT it mounting the FileSystems so I >>>>> can export it cleanly on the 13 system? >>>> >>>> Why do you need to import without mounting file systems?  I think >>>> you >>>> may actually wish them to be mounted to replay their ZILs.  Just use >>>> -R option to mount file systems in some different place. >>> >>> I get the errors shown at: >>> https://www.lerctr.org/~ler/14-mount-R-output.png >>> >>> Should I worry?  Or do something(tm) here? >> >> This looks weird, but may possibly depend on mount points topology, >> whether /mnt is writable, etc. What happen if you export it now and >> try to import it in normal way on 14 without -F? > > It crashes just after root mount (this is the boot pool and only pool > on the system), > seeL > https://www.lerctr.org/~ler/14-BOOT-Crash.png Where do I go from here? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Thu Feb 24 16:29:02 2022 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 985B119DE980 for ; Thu, 24 Feb 2022 16:29:05 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4JJJ5dBfz3GZ7 for ; Thu, 24 Feb 2022 16:29:04 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qv1-xf2b.google.com with SMTP id h13so4435450qvk.12 for ; Thu, 24 Feb 2022 08:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=n+INtMsgTge5+rE2M4gTtOJmJe/iLm6H9C7ITFs1mPE=; b=cJ4aU5ScRtfxna++14yQMaGyuK9As6dBQ8exfFH1oCbV/gSBi0dU5kG3bued2dDaYR ag2gxc7j9VkomIsguT9MMinKOSB3smXvZDW7JHLAGCT5KTMk5ki1Q8pdyY3QbcsGDGwT D3mkb/z8d/ZEYl/d6R/FWLNCAnK2N9EXvFulf23X7ZiMsBOalvq65MoY/3Y3ENXO/vYP jRGjri7OLpPiwTHrjWJvgE4O77YPqTj3i6C8qLvTadAntS3rLwkn/+OyP7Tg3gnLvDZ0 it7zNSL8wIZFrMlJ7W5lACTspnfEv6O7hpqE/JV2akkC7gtuskQx9oXp61g4yZqDvFjX y/Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=n+INtMsgTge5+rE2M4gTtOJmJe/iLm6H9C7ITFs1mPE=; b=juQYcbnd5Aw4igK5gcIkZuBTK/fNebJ+gANbzQdNVyDQa/V2hjbqZxvfrTyquaryfl Mdt5m7MCJltxtZRH1LlYgrrVVTuoN9QCGtyjxHY7/D4GgR8zxe8bBupIY7qZu7uqjf+n er+Y5So81JnrSBxzFPMtWAXh6Nd3pcZ4OOjUFpeq8n19tEdGPj1z72UVP1fmKxbmLvvM DP6uK3ZUKpaOI4+BMG0/ZkBeUx6WLey3hgsSfNOx0LulVMQZfv0YlwPG9B0Tyc4I8BVF jlGoGKAVFBuURQJnXN9KUzmoOJkgX9Q+xB7tvkFhU5/PBTWdaD0lUnokSG729dC6MspP trgw== X-Gm-Message-State: AOAM531nb8qWDQ3eFM2G+vAPN5Ld+wcbTBW19EJhH4q4kA+mtsM/YbnY dLTURyEDj78SgaoQD5TxwZfVr0DQcxQ= X-Google-Smtp-Source: ABdhPJxxj5txnIm0Wc1Um8WGoh/5ewzyi4XtmyuedV21yF3PawRf4DxhF+h9RUy5qyquVy8yM2rnwA== X-Received: by 2002:a05:622a:110:b0:2dd:461a:6126 with SMTP id u16-20020a05622a011000b002dd461a6126mr3081716qtw.379.1645720143835; Thu, 24 Feb 2022 08:29:03 -0800 (PST) Received: from [10.231.1.66] (075-130-069-034.biz.spectrum.com. [75.130.69.34]) by smtp.gmail.com with ESMTPSA id c7sm1580593qte.8.2022.02.24.08.29.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Feb 2022 08:29:03 -0800 (PST) Message-ID: Date: Thu, 24 Feb 2022 11:29:02 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: ZFS PANIC: HELP. Content-Language: en-US To: Larry Rosenman Cc: Freebsd current References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> From: Alexander Motin In-Reply-To: <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K4JJJ5dBfz3GZ7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=cJ4aU5Sc; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::f2b as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; SUBJ_ALL_CAPS(1.20)[16]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2b:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 24.02.2022 10:57, Larry Rosenman wrote: > On 02/23/2022 9:27 pm, Larry Rosenman wrote: >> It crashes just after root mount (this is the boot pool and only pool >> on the system), >> seeL >> https://www.lerctr.org/~ler/14-BOOT-Crash.png > > Where do I go from here? I see 2 ways: 1) Since it is only an assertion and 13 is working (so far), you may just build 14 kernel without INVARIANTS option and later recreate the pool when you have time. 2) You may treat it as metadata corruption: import pool read-only and evacuate the data. If you have recent enough snapshots you may be able to easily replicate the pool with all the settings to some other disk. ZIL is not replicated, so corruptions there should not be a problem. If there are no snapshots, then either copy on file level, or you may be able to create snapshot for replication in 13 (on 14 without INVARIANTS), importing pool read-write. -- Alexander Motin From nobody Thu Feb 24 16:35:22 2022 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 CF93E19E02C1 for ; Thu, 24 Feb 2022 16:35:24 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4JRc0yMWz3Hs6; Thu, 24 Feb 2022 16:35:24 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=XPaXFjLfo7QNY0csPMQL9Sqwji4sfxnZdurElldPc0c=; b=xGVYwkyfzqwmMk64lGQVDC90Ys EdAwVp/PZawxvQDacYUSkugAl9F7o5NrsKZeSbOvR4it7riR5Ydnau/GsS60+eCSu1xfEjaGXQSCO peBr1AyisB9xTksWV8gsHAXN4GmbMdkCZ2PEhVIbxsc4MphTFpdpYy9U3A4Hk5lz5+oekxx8rOdng Joa4YlLZrL1iuargW3CGX5s3oJ0+bvG4Y76H34dSk7IIeMOUL1EiR9krIAhAPzTUjELrO05KT3m+v dI+73onjULs1Lx0daAwW6jWdDTCQOJqHdcmfGAYJRxtNuejCHZMxDqiViMPUUI3grjgSFSZMZBC2k +Q15s7DQ==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:55722 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nNH5O-0009EK-Ic; Thu, 24 Feb 2022 10:35:22 -0600 Received: from 2600:1700:210:b18f:cc53:f3ee:b613:c3a6 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Feb 2022 10:35:22 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Thu, 24 Feb 2022 10:35:22 -0600 From: Larry Rosenman To: Alexander Motin Cc: Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> Message-ID: <5ee0a5ae0d0bc6a365f86e6002ada07c@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K4JRc0yMWz3Hs6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=xGVYwkyf; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-1.65 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.15)[0.151]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02/24/2022 10:29 am, Alexander Motin wrote: > On 24.02.2022 10:57, Larry Rosenman wrote: >> On 02/23/2022 9:27 pm, Larry Rosenman wrote: >>> It crashes just after root mount (this is the boot pool and only pool >>> on the system), >>> seeL >>> https://www.lerctr.org/~ler/14-BOOT-Crash.png >> >> Where do I go from here? > > I see 2 ways: 1) Since it is only an assertion and 13 is working (so > far), you may just build 14 kernel without INVARIANTS option and later > recreate the pool when you have time. 2) You may treat it as metadata > corruption: import pool read-only and evacuate the data. If you have > recent enough snapshots you may be able to easily replicate the pool > with all the settings to some other disk. ZIL is not replicated, so > corruptions there should not be a problem. If there are no snapshots, > then either copy on file level, or you may be able to create snapshot > for replication in 13 (on 14 without INVARIANTS), importing pool > read-write. Ugh. The box is a 6 disk R710, and all 6 disks are in the pool. I do have a FreeNAS box with enough space to copy the data out. There ARE snaps of MOST filesystems that are taken regularly. The 13 I'm booting from is the 13 memstick image. There are ~70 filesystems (IIRC) with poudriere, ports, et al. I'm not sure how to build the 14 kernel from the 13 booted box. Ideas? Methods? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Thu Feb 24 16:36:32 2022 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 68D6919E12E1 for ; Thu, 24 Feb 2022 16:36:48 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4JTB6CZVz3Jl7; Thu, 24 Feb 2022 16:36:46 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: by mail-ej1-x62c.google.com with SMTP id gb39so5614587ejc.1; Thu, 24 Feb 2022 08:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8lypYVqLiCgZAMh2hbiOcaYBXrEVDSnB6m5Tf2siWgU=; b=qTkGC/fhntT1MoXEVtWtcuUIk3qUDq6vHMskEmLlV/R8ADGnPyo5mWF1PPKb59h89V Fozm7WzoUA/SnASU8EJLxRUebPyUwV1VZNymyvSinJarx31ON4ogMyHg4nRL25Yc3WyC eQPs4RL0A4RonT3jsZWwCPOJuWpnkdMJle3opkX1at7B8Or79iMy7Z75WYKAmrrIi2uD e/eTnyLsMRbVPJZm3+GkS8uMdhb7Z91HE9mP3bFXHycU9ukqLL6WPfdVFlsTpWxlhgAE Z6H+mHktuZ6Xa9FAQQ5BwoC5W7NFxI3pAAZ4xU8JpcJEg0i4CFqJv6K55XP0pogbMMEE KP3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8lypYVqLiCgZAMh2hbiOcaYBXrEVDSnB6m5Tf2siWgU=; b=BXgnWz2pIcjyJ+a6b9yzA2ysQQwj1/uHnIZpKisKwLYP91I6RcqAhxmjNsrgu7hR/j t8cRTB9fWuuk6BJ0fYPEtNQ6TDPOoQpC/tqoW6puMyM2+EcJqHTC+am+4I9scYZjJkd0 oob9TntLBrHpfP+6OpLfz/VgdojDZ3CxsxwK+crp06oBHKZQd1nmGBbOhNTShVEolDkZ jxr5/e7iNJspmRUC3v/gx+bl/1YbAy1wMUHxiIA8TtZcd7OpAUazp6cqqEjyTSuoQW1Q hXMpce0JvleqrUWiwe3gJMd7zg+DrFSbeDQaCXTYUc0WZ1ZWQ+G4zsdlqv2yHYlwN+P+ t/Ng== X-Gm-Message-State: AOAM531/eUEs3i87JbxlOxY5yTXBxWzYEzqZX7eQi93NONAoUdkbpD6n F3f14z4fLWgZE/PMsg8ZvzLG8HtXLP//JxrJGimPnVpYeRE= X-Google-Smtp-Source: ABdhPJx4W1CxaQJ//zNhhunxcUXqVYrEaxTkoBQvkr7WH58taBJRSRj4UdQgbo9QPWliQGPtkYyM4Tpyw2hdCU5xb2I= X-Received: by 2002:a17:906:2a92:b0:6cd:4349:dc1a with SMTP id l18-20020a1709062a9200b006cd4349dc1amr2926097eje.648.1645720604457; Thu, 24 Feb 2022 08:36:44 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> In-Reply-To: From: Rob Wing Date: Thu, 24 Feb 2022 07:36:32 -0900 Message-ID: Subject: Re: ZFS PANIC: HELP. To: Alexander Motin Cc: Larry Rosenman , Freebsd current Content-Type: multipart/alternative; boundary="000000000000073ec005d8c6308c" X-Rspamd-Queue-Id: 4K4JTB6CZVz3Jl7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="qTkGC/fh"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of robfx907@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=robfx907@gmail.com X-Spamd-Result: default: False [-2.80 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; SUBJ_ALL_CAPS(1.20)[16]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000073ec005d8c6308c Content-Type: text/plain; charset="UTF-8" You might try setting `sysctl vfs.zfs.recover=1` and `sysctl vfs.zfs.spa.load_verify_metadata=0`. I had a similar error the other day (couple months ago). The best I did was being able to import the pool read only. I ended up restoring from backup. On Thu, Feb 24, 2022 at 7:30 AM Alexander Motin wrote: > On 24.02.2022 10:57, Larry Rosenman wrote: > > On 02/23/2022 9:27 pm, Larry Rosenman wrote: > >> It crashes just after root mount (this is the boot pool and only pool > >> on the system), > >> seeL > >> https://www.lerctr.org/~ler/14-BOOT-Crash.png > > > > Where do I go from here? > > I see 2 ways: 1) Since it is only an assertion and 13 is working (so > far), you may just build 14 kernel without INVARIANTS option and later > recreate the pool when you have time. 2) You may treat it as metadata > corruption: import pool read-only and evacuate the data. If you have > recent enough snapshots you may be able to easily replicate the pool > with all the settings to some other disk. ZIL is not replicated, so > corruptions there should not be a problem. If there are no snapshots, > then either copy on file level, or you may be able to create snapshot > for replication in 13 (on 14 without INVARIANTS), importing pool > read-write. > > -- > Alexander Motin > > --000000000000073ec005d8c6308c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You might try setting `sysctl vfs.zfs.recover=3D1` an= d `sysctl vfs.zfs.spa.load_verify_metadata=3D0`.

I had a similar error the other day (couple months ago). The best I did=20 was being able to import the pool read only. I ended up restoring from=20 backup.

On Thu, Feb 24, 2022 at 7:30 AM Alexander Motin <mav@freebsd.org> wrote:
On 24.02.2022 10:57, Larry Rosenman= wrote:
> On 02/23/2022 9:27 pm, Larry Rosenman wrote:
>> It crashes just after root mount (this is the boot pool and only p= ool
>> on the system),
>> seeL
>> https://www.lerctr.org/~ler/14-BOOT-Crash.png<= /a>
>
> Where do I go from here?

I see 2 ways: 1) Since it is only an assertion and 13 is working (so
far), you may just build 14 kernel without INVARIANTS option and later
recreate the pool when you have time.=C2=A0 2) You may treat it as metadata=
corruption: import pool read-only and evacuate the data.=C2=A0 If you have =
recent enough snapshots you may be able to easily replicate the pool
with all the settings to some other disk.=C2=A0 ZIL is not replicated, so <= br> corruptions there should not be a problem.=C2=A0 If there are no snapshots,=
then either copy on file level, or you may be able to create snapshot
for replication in 13 (on 14 without INVARIANTS), importing pool read-write= .

--
Alexander Motin

--000000000000073ec005d8c6308c-- From nobody Thu Feb 24 16:42:58 2022 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 99C5919E310B for ; Thu, 24 Feb 2022 16:43:00 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4JcM56dTz3Lnp; Thu, 24 Feb 2022 16:42:59 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To: From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=41ouALSvNEvvk+pLftIwEC1XHDjQTKdwHIF2kltzMbk=; b=vv2n7t9aX6j7mmn+NtGnnob26x IhtkI04hOR2ZwoaSrNrxIte82g3D2+QCEjMSZg3wphFwWnI+zypIkWUy9fNSXOesM4K4ePm0YapEV mss4twJtrnqrJ7N09E0G31emT1SmoMONHW0WziXlkalT3dBMFcdVdbhfXiogL+UPT6U4xa01BhH+E S9N6DUAQvE1t3HJR+KBEtAqaFgiC7bGgoo7TEy3oSJ7b1osDkJ684cBOHhRb35purzFJ2MyWUkvZB MfJ8a/DVAZ9IBSLINAI7ybwbLZnRtieYaYJaCm39oNv3NwewX0x3ndolPKGoLCnmf0h8pgbqwRI91 +r2xDNpA==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:29144 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nNHCk-0009Lf-C4; Thu, 24 Feb 2022 10:42:58 -0600 Received: from 2600:1700:210:b18f:cc53:f3ee:b613:c3a6 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Feb 2022 10:42:58 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Thu, 24 Feb 2022 10:42:58 -0600 From: Larry Rosenman To: Rob Wing Cc: Alexander Motin , Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> Message-ID: X-Sender: ler@lerctr.org Content-Type: multipart/alternative; boundary="=_5ec62bdc7c2e636e8be088ef8ce89e11" X-Rspamd-Queue-Id: 4K4JcM56dTz3Lnp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=vv2n7t9a; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_5ec62bdc7c2e636e8be088ef8ce89e11 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 02/24/2022 10:36 am, Rob Wing wrote: > You might try setting `sysctl vfs.zfs.recover=1` and `sysctl > vfs.zfs.spa.load_verify_metadata=0`. > > I had a similar error the other day (couple months ago). The best I did > was being able to import the pool read only. I ended up restoring from > backup. > >> Are those tunables that I can set in loader.conf? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 --=_5ec62bdc7c2e636e8be088ef8ce89e11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 02/24/2022 10:36 am, Rob Wing wrote:

You might try setting `sysctl vfs.zfs.recover=3D1` and `sysctl vfs.zfs= =2Espa.load_verify_metadata=3D0`.
 
I had a similar error the other day (couple months ago). The best I di= d was being able to import the pool read only. I ended up restoring from ba= ckup.



Are those tunables that I can set in loader.conf?


= -- 
Larry Rosenman     &n= bsp;            = ;   http://www.lerctr.org/~ler
Phone: +1 = 214-642-9640           &n= bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=
--=_5ec62bdc7c2e636e8be088ef8ce89e11-- From nobody Thu Feb 24 16:48:58 2022 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 72B2419E4FCD for ; Thu, 24 Feb 2022 16:49:18 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4Jld5DfQz3Nmg; Thu, 24 Feb 2022 16:49:17 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: by mail-ej1-x632.google.com with SMTP id qx21so5590094ejb.13; Thu, 24 Feb 2022 08:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XUxpcQLhRr82GZ7WO2c0jW2KoWPMWhyzSDbgydJntlU=; b=IUNw93EGFm/CvZfh3XI6PQYdrOGZWUPF7EBWO4RGCEPgo9ogmMiA4xZ9jGAlFS3IbY aFeQtCMEPThFzPY/v3IGlTkU+gYJnMnnUczeizkcSH1UrVVUgExQhgNi1PKqZb62afia 4eVS/eCff52eTDWF5K+pHxfOcTTsvE/oCpjaLBNKl6pZ9fKcARItY+Y1aRnYA6VfSItw V2oNBTx/2vcdAheJlxOHK+OvlW9KJ4U1ppAvUwdjecLqSNRtDwp1XKS8vC3onAXvQ16t GBRJvtO2GjVkypDIk+bZcYh35rB6rDAFePh/CB41VSaKfVAcvDwJxiKL4NtFWamv1FAj rurA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XUxpcQLhRr82GZ7WO2c0jW2KoWPMWhyzSDbgydJntlU=; b=WJgcGTLroAgcT9pfNz8ZbShW8wFioGPXNErLgmlImk9GbfwDYkqKxnrQA/6RXYom1u wAK3rIrFLi+Cib6s1Jh2EUY7Xf91dij3P1X/wFyvIWMqLs2WIORtM5sWERyptDyHmEII jsiwcXBdtPy7H4HzVdqLyViu2onApBE8M6yAwj+qA9anKOKWy9TXqL4MnzaSNKvIGXG5 n+zPT5NymnWmN8TR7QdwifTsj/YUbV1Ek5NZ6LeKG0cyWkRkMe/3ZyJlHCA9JAFuGsRZ DtBnsGZXpHk2ITkviGViLDJ7MyYeJvT/gfZ8Jz+cj1LvrnDK9abJPUl7KNfS7VHm/QOo Z8Mw== X-Gm-Message-State: AOAM530GzSAfzhNLAJgcejpc1L3sNnFM/5S3xau6BxY0PG3pPcp/zMmt P3rN8aKId6Jyd9wBlGBekw2Cwt7CJPs9Sxn13UylEnnS X-Google-Smtp-Source: ABdhPJxqLgdCFj9mFp32KxYFzflu0GvFn89Att7E2/4CpUsB4JDue6RJ52zvsbBSsQ4xWYxBDSMncJxMF6gwpirN4G0= X-Received: by 2002:a17:906:ce30:b0:6cf:1b03:e696 with SMTP id sd16-20020a170906ce3000b006cf1b03e696mr2974814ejb.505.1645721350269; Thu, 24 Feb 2022 08:49:10 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> In-Reply-To: From: Rob Wing Date: Thu, 24 Feb 2022 07:48:58 -0900 Message-ID: Subject: Re: ZFS PANIC: HELP. To: Larry Rosenman Cc: Alexander Motin , Freebsd current Content-Type: multipart/alternative; boundary="0000000000007b903905d8c65c66" X-Rspamd-Queue-Id: 4K4Jld5DfQz3Nmg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=IUNw93EG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of robfx907@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=robfx907@gmail.com X-Spamd-Result: default: False [-2.03 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; SUBJ_ALL_CAPS(1.20)[16]; NEURAL_HAM_SHORT(-0.23)[-0.229]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::632:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000007b903905d8c65c66 Content-Type: text/plain; charset="UTF-8" Yes, I believe so. On Thu, Feb 24, 2022 at 7:42 AM Larry Rosenman wrote: > On 02/24/2022 10:36 am, Rob Wing wrote: > > You might try setting `sysctl vfs.zfs.recover=1` and `sysctl > vfs.zfs.spa.load_verify_metadata=0`. > > I had a similar error the other day (couple months ago). The best I did > was being able to import the pool read only. I ended up restoring from > backup. > > > > Are those tunables that I can set in loader.conf? > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 > --0000000000007b903905d8c65c66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I believe so.

On Thu, Feb 24, 2022 at 7:42 AM Larr= y Rosenman <ler@lerctr.org> wro= te:

On 02/24/2022 10:36 am, Ro= b Wing wrote:

You might try setting `sysctl vfs.zfs.recover=3D1` and `sysctl vfs.zfs= .spa.load_verify_metadata=3D0`.
=C2=A0
I had a similar error the other day (couple months ago). The best I di= d was being able to import the pool read only. I ended up restoring from ba= ckup.



Are those tunables that I can set in loader.conf?


--=C2=A0<= br>Larry Rosenman =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tp://www.lerctr.org/~ler
Phone: +1 214-642-9640 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0E-Mail: ler@lerctr.o= rg
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--0000000000007b903905d8c65c66-- From nobody Thu Feb 24 19:27:59 2022 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 420A919DBBB3 for ; Thu, 24 Feb 2022 19:28:02 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4NGn3jh7z4WTW; Thu, 24 Feb 2022 19:28:01 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To: From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=PZQCESmvlNQ+yaO06v+4Ge8B2Xrk1xcCUU9SEfmte5I=; b=nMysnMGlLGu8RNqgkNpedaSSjV AP+lxdH4lo9g2XJB6xJ69NwwEInk9XuVfJxflmJd0g27xeQ++Ml3FhqutUIwfOpOg+n8KFQmiFWUj HPjjyIxVYwZZFRWM4YeWfcQP9uh6FUVtbSqKW20HFh+3aBtSLvPRhXNTZJEz5Z4SNQvHWZyAM8M8z xqNQV0GPKHQOvnsyUuoXK7gpFwYPRDB5SdRd2uGbtBm0u/PKRglL/ve67koeskIF9p95fO7qSBuM8 JzdPheYR7ZiOOHIsPID9yosO1BFy/D1Y3FQfcvUEMXeV6y2dmzJygWBLkDhiVUlIMcJZ2PsxsTvs4 bOq0z14w==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:32716 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nNJmR-000Bz8-HM; Thu, 24 Feb 2022 13:27:59 -0600 Received: from 2600:1700:210:b18f:cc53:f3ee:b613:c3a6 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Feb 2022 13:27:59 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Thu, 24 Feb 2022 13:27:59 -0600 From: Larry Rosenman To: Rob Wing Cc: Alexander Motin , Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> Message-ID: <36d3896af19acc4fdd1712822ba9d420@lerctr.org> X-Sender: ler@lerctr.org Content-Type: multipart/alternative; boundary="=_6077442894370f68cb8820da6cc6fd42" X-Rspamd-Queue-Id: 4K4NGn3jh7z4WTW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=nMysnMGl; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_6077442894370f68cb8820da6cc6fd42 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 02/24/2022 10:48 am, Rob Wing wrote: > Yes, I believe so. > > On Thu, Feb 24, 2022 at 7:42 AM Larry Rosenman wrote: > > On 02/24/2022 10:36 am, Rob Wing wrote: > > You might try setting `sysctl vfs.zfs.recover=1` and `sysctl > vfs.zfs.spa.load_verify_metadata=0`. > > I had a similar error the other day (couple months ago). The best I did > was being able to import the pool read only. I ended up restoring from > backup. Are those tunables that I can set in loader.conf? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 even with those set, I still get the panid. :( Let me see if I can compile a 14 non-INVARIANTS kernel on the 13-REL system. UGH. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 --=_6077442894370f68cb8820da6cc6fd42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 02/24/2022 10:48 am, Rob Wing wrote:

Yes, I believe so.

On Thu, Feb 24, 2022 at 7:42 AM Lar= ry Rosenman <ler@le= rctr.org> wrote:

On 02/24/2022 10:36 am, = Rob Wing wrote:

You might try setting `sysctl vfs.zfs.recover=3D1` and `sysctl vfs.zfs= =2Espa.load_verify_metadata=3D0`.
 
I had a similar error the other day (couple months ago). The best I di= d was being able to import the pool read only. I ended up restoring from ba= ckup.



Are those tunables that I can set in loader.conf?


--&= nbsp;
Larry Rosenman         &= nbsp;           http://www.lerctr.org/~ler
Phone: +1 214-642-9640  &nbs= p;            &= nbsp; E-Mail: ler= @lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

even with those set, I still get the panid. :( 

Let me see if I can compile a 14 non-INVARIANTS kernel on the 13-REL sys= tem.


UGH. 


= -- 
Larry Rosenman     &n= bsp;            = ;   http://www.lerctr.org/~ler
Phone: +1 = 214-642-9640           &n= bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=
--=_6077442894370f68cb8820da6cc6fd42-- From nobody Thu Feb 24 20:05:27 2022 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 0D8C619E2C45; Thu, 24 Feb 2022 20:05:44 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4P6H2Qd1z4c0R; Thu, 24 Feb 2022 20:05:43 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-qt1-x82f.google.com with SMTP id v3so526625qta.11; Thu, 24 Feb 2022 12:05:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KFGKRLMqHwXAGyq5rtZxeGU4x4Lsz1Xzh3y18G9xLjQ=; b=Zm6+f5PuLizA5fUfVuRMg+o8XEsn76CnR3+Fqkt0FHjA13sp8YKZ1lWYuWsPjeOXGd sF5WxGP91JGmruwLTg8UFuXoyi0n/Ob02Z4EqaqjGnVVVAoZ3DAWDG4JEpGYX2fBJWu3 2urXjxYTJWNb8XLCY9f4EKK1Ijw8UMiIVD64joNzGgYJE5i1WP7kEwS0kekN0uPPTSax MU9rBtooEWM9MPRieC04C8h24MEf7B4I7lisYqupnPwt0pkQl84wDif14umJYsDsV2Fe w51NB8Ce1wbuqpAdzSXZQAI+S7n2TvuK/361ZP0sBGsK1Wv4/BOwkxVu5NcWKMnfKfqH FFSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=KFGKRLMqHwXAGyq5rtZxeGU4x4Lsz1Xzh3y18G9xLjQ=; b=dJqFC0uXPrfEKdLBTJJtUd8uzTJyiF3caT8EGk92k2cu4NDsTHe2XiVjJfnAEOMpLl euFvLl1k+dCnAdTHwwYjpB4LFStxfaJBRo/2OJbTSqVXSrN8ltQYzatNSd7NnNF9hVeA Tk/6gK8b19VKplWjghIcqnSSwhdDZ9U1PKKoPqRih9RsvlgjiId3i2gvKEEs95OP6fbd uuxMsYAP7QLAmBaiiZlf6ovplJdYXjVFnkUUiXGz06qUT1qS7iY93Hk9CQD+7uyyU5Bq UoXTIs9cvUY7N7JncgMDFUEtKtEY8p6dExzZGthBOH2560k8DS9C2M/Oc6khuYirT6Ox CTiA== X-Gm-Message-State: AOAM530O485yExKLcuq9A1o+7cbdDZQf9KangjPJkTWoSIyx1+dvgKoT JPilwbBrXn4KkUhqYJcQKLEhmDr303X+Ld1sjKd2U7Z1 X-Google-Smtp-Source: ABdhPJyxKEOqEWcc/4kg2okwMBBbZh84cxlppJKPnI25hjAz4Y9PACUIaNBqLwNVEjbtboHY0SvkQmQO4xc9ATnjfkc= X-Received: by 2002:ac8:13c1:0:b0:2d5:3c22:8e22 with SMTP id i1-20020ac813c1000000b002d53c228e22mr3916881qtj.306.1645733136539; Thu, 24 Feb 2022 12:05:36 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Sami Halabi Date: Thu, 24 Feb 2022 22:05:27 +0200 Message-ID: Subject: Re: linux debian jail - network problems To: freebsd-jail@freebsd.org, freebsd-net@freebsd.org, freebsd-emulation@freebsd.org, FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000ffa55705d8c91ab9" X-Rspamd-Queue-Id: 4K4P6H2Qd1z4c0R X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Zm6+f5Pu; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sodynet1@gmail.com designates 2607:f8b0:4864:20::82f as permitted sender) smtp.mailfrom=sodynet1@gmail.com X-Spamd-Result: default: False [-1.99 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[5]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.987]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82f:from]; HTTP_TO_IP(1.00)[]; MLMMJ_DEST(0.00)[freebsd-jail,freebsd-net,freebsd-emulation,freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000ffa55705d8c91ab9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Added Current, maybe will be lucky ;) Anyone have idea how approach and fix this? Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=92=D7=B3, 22 = =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2022, 23:30, =D7=9E=D7=90=D7=AA Sami Halabi = =E2=80=8F: > Hi all, > sorry for the cross post but I need help and I'm not sure where it hangs. > > I create linux jail (debian bullseye) via cbsd. > the jail is being populated with the debian userland.. > so far so good... services running (sshd) and I can login to the jail, I > also can update packages and I can install apache httpd and all works fin= e > (apt install or make from src). > I also manage to install packages even if their scripts depend on "ip" > command that fails: > cbsd@j2> ip > Cannot open netlink socket: Address family not supported by protocol > > ifconfig show empty interfaces: > cbsd@j2> ifconfig > eth0: flags=3D4163 mtu 1500 > ether 00:50:56:0a:b3:a0 (Ethernet) > RX packets 139798314 bytes 12029597009 (11.2 GiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 26879143 bytes 34400160833 (32.0 GiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > lo0: flags=3D4169 mtu 16384 > loop (Local Loopback) > RX packets 28548 bytes 160312960 (152.8 MiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 28548 bytes 160312960 (152.8 MiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > I know linux emulation doesn't implement netlink.. so what I do is fake > the response by replacing /bin/ip by a bash script that prints the correc= t > IP and fakes some other (needed by packages i Installed): > #!/bin/bash > if [ "$1" =3D "-o" ]; then > echo "1: eth0 inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0" > elif [ "$1" =3D "route" ]; then > if [ "$2" =3D "get" ]; then > echo "8.8.8.8 via 192.168.1.2 dev eth0 src > 192.168.1.2 " > else > echo "default via 192.168.1.2 dev eth0" > fi > else > echo "1: eth0: mtu 1500 qdisc mq state > UP qlen 1000" > echo " inet 192.168.1.2 /24 brd 192.168.1.255 scope global eth0" > > > still ifconfig shows no IP... its time to say it a regular jail and *NOT* > VNET. > > *however* package that pull ips via libraries fail.. > eg: installed bind916 (name) in the logs I see these errors (relevant > only): > cbsd@j2> service named start > Starting domain name service...: namednamed: prctl(PR_SET_DUMPABLE) > failed: Invalid argument > cbsd@j2> > > > log file shows: > 22-Feb-2022 23:11:58.705 general: notice: BIND 9 is maintained by Interne= t > Systems Consortium, > 22-Feb-2022 23:11:58.705 general: notice: Inc. (ISC), a non-profit > 501(c)(3) public-benefit > 22-Feb-2022 23:11:58.705 general: notice: corporation. Support and > training for BIND 9 are > 22-Feb-2022 23:11:58.705 general: notice: available at > https://www.isc.org/support > 22-Feb-2022 23:11:58.705 general: notice: > ---------------------------------------------------- > 22-Feb-2022 23:11:58.705 general: info: found 6 CPUs, using 6 worker > threads > 22-Feb-2022 23:11:58.705 general: info: using 6 UDP listeners per interfa= ce > 22-Feb-2022 23:11:58.705 general: info: using up to 21000 sockets > 22-Feb-2022 23:11:58.715 general: info: loading configuration from > '/etc/bind/named.conf' > 22-Feb-2022 23:11:58.715 general: info: reading built-in trust anchors > from file '/etc/bind/bind.keys' > 22-Feb-2022 23:11:58.715 general: info: looking for GeoIP2 databases in > '/usr/share/GeoIP' > 22-Feb-2022 23:11:58.715 general: info: using default UDP/IPv4 port range= : > [1024, 65535] > 22-Feb-2022 23:11:58.715 general: info: using default UDP/IPv6 port range= : > [1024, 65535] > 22-Feb-2022 23:11:58.715 network: info: no IPv6 interfaces found > 22-Feb-2022 23:11:58.715 general: error: ifiter_getifaddrs.c:79: > unexpected error: > 22-Feb-2022 23:11:58.715 general: error: getting interface addresses: > getifaddrs: Address family not supported by protocol > 22-Feb-2022 23:11:58.715 network: warning: not listening on any interface= s > *snip* > *snip* > 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected error: > 22-Feb-2022 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS) > failed: Protocol not available > 22-Feb-2022 23:11:58.735 general: notice: couldn't add command channel > 127.0.0.1#953: permission denied > 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected error: > 22-Feb-2022 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS) > failed: Protocol not available > 22-Feb-2022 23:11:58.735 general: notice: couldn't add command channel > 127.0.0.1#953: permission denied > 22-Feb-2022 23:11:58.735 zoneload: info: managed-keys-zone: loaded serial > 24 > 22-Feb-2022 23:11:58.735 zoneload: info: zone 0.in-addr.arpa/IN: loaded > serial 1 > 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected error: > 22-Feb-2022 23:11:58.735 general: error: setsockopt(512, IP_RECVTOS) > failed: Protocol not available > 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected error: > 22-Feb-2022 23:11:58.735 general: error: setsockopt(513, IP_RECVTOS) > failed: Protocol not available > 22-Feb-2022 23:11:58.745 zoneload: info: zone 255.in-addr.arpa/IN: loaded > serial 1 > 22-Feb-2022 23:11:58.745 zoneload: info: zone j1.royalshells.com/IN: > loaded serial 2022022106 > 22-Feb-2022 23:11:58.745 notify: info: zone j1.royalshells.com/IN: > sending notifies (serial 2022022106) > 22-Feb-2022 23:11:58.745 general: error: socket.c:2405: unexpected error: > 22-Feb-2022 23:11:58.745 general: error: setsockopt(514, IP_RECVTOS) > failed: Protocol not available > 22-Feb-2022 23:11:58.745 zoneload: info: zone localhost/IN: loaded serial= 2 > 22-Feb-2022 23:11:58.745 general: error: socket.c:2405: unexpected error: > 22-Feb-2022 23:11:58.745 general: error: setsockopt(515, IP_RECVTOS) > failed: Protocol not available > 22-Feb-2022 23:11:58.745 zoneload: info: zone 127.in-addr.arpa/IN: loaded > serial 1 > 22-Feb-2022 23:11:58.745 general: notice: all zones loaded > 22-Feb-2022 23:11:58.745 general: notice: running > 22-Feb-2022 23:11:58.795 general: error: socket.c:2405: unexpected error: > 22-Feb-2022 23:11:58.795 general: error: setsockopt(50, IP_RECVTOS) > failed: Protocol not available > 22-Feb-2022 23:12:58.811 general: error: ifiter_getifaddrs.c:79: > unexpected error: > 22-Feb-2022 23:12:58.811 general: error: getting interface addresses: > getifaddrs: Address family not supported by protocol > 22-Feb-2022 23:12:58.811 network: warning: not listening on any interface= s > > Any Idea how to fix this?? > > cbsd@j2> named -V > BIND 9.16.22-Debian (Extended Support Version) > running on Linux x86_64 3.2.0 FreeBSD 12.3-RELEASE-p1 GENERIC > > installing newer versions > > I have also problems with dovecot mail package.. but will leave it for no= w > > Thanks in advance, > Sami > > --000000000000ffa55705d8c91ab9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Added Current, maybe will be lucky ;= )

Anyone have idea how a= pproach and fix this?

Sa= mi

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=92=D7= =B3, 22 =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2022, 23:30, =D7=9E=D7=90=D7=AA Sami= Halabi =E2=80=8F<sodynet1@gmail.c= om>:
Hi all= ,
sorry for the cross post but I need help and I'm not sure where i= t hangs.

I create linux jail (debian bullseye) via= cbsd.
the jail is being populated with the debian userland..
so far so good... services running (sshd) and I can login to the jai= l, I also can update packages=C2=A0and I can install apache httpd and all w= orks fine (apt install or make from src).
I also manage to instal= l packages even if their scripts depend on "ip" command that fail= s:
cbsd@j2> ip
Cannot open netlink socket: Address family n= ot supported by protocol

ifconfig show empty i= nterfaces:
cbsd@j2> ifconfig
eth0: flags=3D4163<UP,BROAD= CAST,RUNNING,MULTICAST> =C2=A0mtu 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 et= her 00:50:56:0a:b3:a0 =C2=A0(Ethernet)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RX pa= ckets 139798314 =C2=A0bytes 12029597009 (11.2 GiB)
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 RX errors 0 =C2=A0dropped 0 =C2=A0overruns 0 =C2=A0frame 0
=C2=A0= =C2=A0 =C2=A0 =C2=A0 TX packets 26879143 =C2=A0bytes 34400160833 (32.0 GiB= )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TX errors 0 =C2=A0dropped 0 overruns 0 =C2= =A0carrier 0 =C2=A0collisions 0

lo0: flags=3D4169<UP,LOOPBACK,RUN= NING,MULTICAST> =C2=A0mtu 16384
=C2=A0 =C2=A0 =C2=A0 =C2=A0 loop =C2= =A0(Local Loopback)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RX packets 28548 =C2=A0b= ytes 160312960 (152.8 MiB)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RX errors 0 =C2= =A0dropped 0 =C2=A0overruns 0 =C2=A0frame 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = TX packets 28548 =C2=A0bytes 160312960 (152.8 MiB)
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 TX errors 0 =C2=A0dropped 0 overruns 0 =C2=A0carrier 0 =C2=A0collisi= ons 0

I know linux emulation doesn't imple= ment netlink.. so what I do is fake the response by replacing /bin/ip by a = bash script that prints the correct IP and fakes some other (needed by pack= ages i Installed):
#!/bin/bash
if [ "$1" =3D &qu= ot;-o" ]; then
echo "1: eth0 inet 192.168.1.2/24 brd 192.168.1= .255 scope global eth0"
elif [ "$1" =3D "route"= ]; then
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if [ "$2" =3D "get&q= uot; ]; then
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ech= o "8.8.8.8 via=C2=A0 192.168.1.2=C2=A0=C2=A0=C2=A0dev eth0 =C2=A0src=C2=A0 192.168.1.2=C2=A0 "
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 echo "default via=C2=A0 192.168.1.2=C2=A0=C2=A0=C2=A0dev eth0"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = fi
else
echo "1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> m= tu 1500 qdisc mq state UP qlen 1000"
echo " =C2=A0inet=C2=A0 192.168.1.2=C2=A0 /24 brd=C2=A0 192.168.1.255 scope global eth0"

still ifconfig shows no IP... its time to say it a regular jail= and *NOT* VNET.

*however* package that pull ips v= ia libraries fail..
eg: installed bind916 (name) in the logs I se= e these errors (relevant only):
cbsd@j2> service named startStarting domain name service...: namednamed: prctl(PR_SET_DUMPABLE) faile= d: Invalid argument
cbsd@j2>


<= div>log file shows:
22-Feb-2022 23:11:58.705 general: notice: BIN= D 9 is maintained by Internet Systems Consortium,
22-Feb-2022 23:11:58.7= 05 general: notice: Inc. (ISC), a non-profit 501(c)(3) public-benefit
22= -Feb-2022 23:11:58.705 general: notice: corporation.=C2=A0 Support and trai= ning for BIND 9 are
22-Feb-2022 23:11:58.705 general: notice: available = at https://www.isc.org/support
22-Feb-2022 23:11:58.705 general: n= otice: ----------------------------------------------------
22-Feb-2022 = 23:11:58.705 general: info: found 6 CPUs, using 6 worker threads
22-Feb-= 2022 23:11:58.705 general: info: using 6 UDP listeners per interface
22-= Feb-2022 23:11:58.705 general: info: using up to 21000 sockets
22-Feb-20= 22 23:11:58.715 general: info: loading configuration from '/etc/bind/na= med.conf'
22-Feb-2022 23:11:58.715 general: info: reading built-in t= rust anchors from file '/etc/bind/bind.keys'
22-Feb-2022 23:11:5= 8.715 general: info: looking for GeoIP2 databases in '/usr/share/GeoIP&= #39;
22-Feb-2022 23:11:58.715 general: info: using default UDP/IPv4 port= range: [1024, 65535]
22-Feb-2022 23:11:58.715 general: info: using defa= ult UDP/IPv6 port range: [1024, 65535]
22-Feb-2022 23:11:58.715 network:= info: no IPv6 interfaces found
22-Feb-2022 23:11:58.715 general: error:= ifiter_getifaddrs.c:79: unexpected error:
22-Feb-2022 23:11:58.715 gene= ral: error: getting interface addresses: getifaddrs: Address family not sup= ported by protocol
22-Feb-2022 23:11:58.715 network: warning: not listen= ing on any interfaces
*snip*
*snip*
22-Fe= b-2022 23:11:58.735 general: error: socket.c:2405: unexpected error:
22-= Feb-2022 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS) failed: Pr= otocol not available
22-Feb-2022 23:11:58.735 general: notice: couldn= 9;t add command channel 127.0.0.1#953: permission denied
22-F= eb-2022 23:11:58.735 general: error: socket.c:2405: unexpected error:
22= -Feb-2022 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS) failed: P= rotocol not available
22-Feb-2022 23:11:58.735 general: notice: couldn&#= 39;t add command channel 127.0.0.1#953: permission denied
22-Feb-2022 23= :11:58.735 zoneload: info: managed-keys-zone: loaded serial 24
22-Feb-20= 22 23:11:58.735 zoneload: info: zone 0.in-addr.arpa/IN: loaded serial 1
= 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected error:22-Feb-2022 23:11:58.735 general: error: setsockopt(512, IP_RECVTOS) fail= ed: Protocol not available
22-Feb-2022 23:11:58.735 general: error: sock= et.c:2405: unexpected error:
22-Feb-2022 23:11:58.735 general: error: se= tsockopt(513, IP_RECVTOS) failed: Protocol not available
22-Feb-2022 23:= 11:58.745 zoneload: info: zone 255.in-addr.arpa/IN: loaded serial 1
22-F= eb-2022 23:11:58.745 zoneload: info: zone j1.royalshells.com/IN: loa= ded serial 2022022106
22-Feb-2022 23:11:58.745 notify: info: zone j1.= royalshells.com/IN: sending notifies (serial 2022022106)
22-Feb-2022= 23:11:58.745 general: error: socket.c:2405: unexpected error:
22-Feb-20= 22 23:11:58.745 general: error: setsockopt(514, IP_RECVTOS) failed: Protoco= l not available
22-Feb-2022 23:11:58.745 zoneload: info: zone localhost/= IN: loaded serial 2
22-Feb-2022 23:11:58.745 general: error: socket.c:24= 05: unexpected error:
22-Feb-2022 23:11:58.745 general: error: setsockop= t(515, IP_RECVTOS) failed: Protocol not available
22-Feb-2022 23:11:58.7= 45 zoneload: info: zone 127.in-addr.arpa/IN: loaded serial 1
22-Feb-2022= 23:11:58.745 general: notice: all zones loaded
22-Feb-2022 23:11:58.745= general: notice: running
22-Feb-2022 23:11:58.795 general: error: socke= t.c:2405: unexpected error:
22-Feb-2022 23:11:58.795 general: error: set= sockopt(50, IP_RECVTOS) failed: Protocol not available
22-Feb= -2022 23:12:58.811 general: error: ifiter_getifaddrs.c:79: unexpected error= :
22-Feb-2022 23:12:58.811 general: error: getting interface addresses: = getifaddrs: Address family not supported by protocol
22-Feb-2= 022 23:12:58.811 network: warning: not listening on any interfaces

Any Idea how to fix this??

cb= sd@j2> named -V
BIND 9.16.22-Debian (Extended Support Version) <id= :59bfaba>
running on Linux x86_64 3.2.0 FreeBSD 12.3-RELEASE-p1 GENER= IC

installing newer=C2=A0versions=C2=A0
<= div>
I have also problems with dovecot mail package.. but wil= l leave it for now

Thanks in advance,
Sa= mi

--000000000000ffa55705d8c91ab9-- From nobody Fri Feb 25 02:07:18 2022 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 B9DF519DAF4D for ; Fri, 25 Feb 2022 02:07:31 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4Y7k6vJlz3J5x; Fri, 25 Feb 2022 02:07:30 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To: From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Xcmfa+72tFVkt4LJkvFGi2cv4hVhh1JUGcRwEcCPMLs=; b=vCngrMJRxjU2zB6mzVqS5fyVC8 nVGGXfz5Rfbr1ztrTyMWW7BdskESoho/Iv+2Yj1qHiUA/bVtihvMLd9+6bExvX3kPWqmBlQl0Vkgw iYmNR8/sSSM2ezCpWwbboQUS4x66WGqa45sEsXeNPD9MmUlS1C2MDNe8JaWhUlgQ6WX9hgB5ii96X QPhU/h92Ee1b11NAHaVm2tbyroLZfF8DAmWXx81XO5TtxjwgcSZ0ru7X+EM/Xect+GieTrtlGLzpE PiOC8xaw5Yn70G+G3dtVG/aRIM7aT43IRihWY928bU8wBtEhPC+h3XZXJHN+c0btDn8cKxiye3KG5 nx9IiZjQ==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:54088 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nNQ0s-000I4e-DM; Thu, 24 Feb 2022 20:07:18 -0600 Received: from 2600:1700:210:b18f:cc53:f3ee:b613:c3a6 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Feb 2022 20:07:18 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Thu, 24 Feb 2022 20:07:18 -0600 From: Larry Rosenman To: Rob Wing Cc: Alexander Motin , Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: <36d3896af19acc4fdd1712822ba9d420@lerctr.org> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> Message-ID: <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> X-Sender: ler@lerctr.org Content-Type: multipart/alternative; boundary="=_96283fdaafda73ecef915822aa54d716" X-Rspamd-Queue-Id: 4K4Y7k6vJlz3J5x X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=vCngrMJR; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_96283fdaafda73ecef915822aa54d716 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 02/24/2022 1:27 pm, Larry Rosenman wrote: > On 02/24/2022 10:48 am, Rob Wing wrote: > >> even with those set, I still get the panid. :( > > Let me see if I can compile a 14 non-INVARIANTS kernel on the 13-REL > system. > > UGH. I chroot'd to the pool, and built a no invariants kernel. It booted and seems(!) to be running. Is there any diagnostics/clearing the crappy ZIL? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 --=_96283fdaafda73ecef915822aa54d716 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 02/24/2022 1:27 pm, Larry Rosenman wrote:

On 02/24/2022 10:48 am, Rob Wing wrote:

even with those set, I st= ill get the panid. :( 

Let me see if I can compile a 14 non-INVARIANTS kernel on the 13-REL sys= tem.


UGH. 


I chroot'd to the pool, and built a no invariants kernel.  It boote= d and seems(!) to be running.

Is there any diagnostics/clearing the crappy ZIL?



= -- 
Larry Rosenman     &n= bsp;            = ;   http://www.lerctr.org/~ler
Phone: +1 = 214-642-9640           &n= bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=
--=_96283fdaafda73ecef915822aa54d716-- From nobody Fri Feb 25 02:19:45 2022 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 A31E519DE789 for ; Fri, 25 Feb 2022 02:19:47 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4YPv0qCpz3LX6; Fri, 25 Feb 2022 02:19:47 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To: From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=uygOTdRKtcqGa/riMM50ieBVXHEfc+ei2hbtbQX10Nk=; b=QmppBr9IMrS35KPeqVuliNf7AM fvGLCiGyTtBEVFG0fGECZqd0cOHTpT4G5qjaAzZpk4VJxp7gJBAbLaZ4F18XRYjM31tNPuDhnbNyy TSZp19bAhXrhBBs5oL/7IJfbMI8eFhmutB4m1duXfWPYWHAf1Fo143qasyMIE47493fOmVQWkgpll VZ/ctNhujItdevr/Is4oJHDjMGMBvAhIN4+KMKU3i1TMPVPLfbn2JhVPVTnJg11wOj+9kcuupOhJ2 RNkwd6mDa8uDxb0o4IQoYO7Q6hmw2/vovh9XeGsEuDh/PUOjdQ+RiUehdOjG32EOt5W1W/2kDTQCv xLNSbSOA==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:25215 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nNQCv-000IIc-IL; Thu, 24 Feb 2022 20:19:45 -0600 Received: from 2600:1700:210:b18f:cc53:f3ee:b613:c3a6 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 24 Feb 2022 20:19:45 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Thu, 24 Feb 2022 20:19:45 -0600 From: Larry Rosenman To: Rob Wing Cc: Alexander Motin , Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> Message-ID: X-Sender: ler@lerctr.org Content-Type: multipart/alternative; boundary="=_4df75b1e66f6a28175491c26802f8fc2" X-Rspamd-Queue-Id: 4K4YPv0qCpz3LX6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=QmppBr9I; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.79 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_4df75b1e66f6a28175491c26802f8fc2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 02/24/2022 8:07 pm, Larry Rosenman wrote: > On 02/24/2022 1:27 pm, Larry Rosenman wrote: > > On 02/24/2022 10:48 am, Rob Wing wrote: > > even with those set, I still get the panid. :( > > Let me see if I can compile a 14 non-INVARIANTS kernel on the 13-REL > system. > > UGH. I chroot'd to the pool, and built a no invariants kernel. It booted and seems(!) to be running. Is there any diagnostics/clearing the crappy ZIL? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 I tried a scrub -- it panic'd on a fatal double fault. Suggestions? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 --=_4df75b1e66f6a28175491c26802f8fc2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 02/24/2022 8:07 pm, Larry Rosenman wrote:

On 02/24/2022 1:27 pm, Larry Rosenman wrote:

On 02/24/2022 10:48 am, Rob Wing wrote:

even with those set, I st= ill get the panid. :( 

Let me see if I can compile a 14 non-INVARIANTS kernel on the 13-REL sys= tem.


UGH. 


I chroot'd to the pool, and built a no invariants kernel.  It boote= d and seems(!) to be running.

Is there any diagnostics/clearing the crappy ZIL?



-- 
Larry Rosenman    &nb= sp;            =     http://www.lerctr.org/~ler
Phone= : +1 214-642-9640          &nb= sp;      E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr,= Round Rock, TX 78665-2106

I tried a scrub -- it panic'd on a fatal double fault. 

Suggestions?


= -- 
Larry Rosenman     &n= bsp;            = ;   http://www.lerctr.org/~ler
Phone: +1 = 214-642-9640           &n= bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=
--=_4df75b1e66f6a28175491c26802f8fc2-- From nobody Fri Feb 25 06:34:57 2022 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 950E319DD040; Fri, 25 Feb 2022 06:35:17 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4g4h4Xzcz4RQk; Fri, 25 Feb 2022 06:35:16 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-qt1-x832.google.com with SMTP id bc10so1645834qtb.5; Thu, 24 Feb 2022 22:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fWBo/URZoi7GG03o7vt9qXqiXnYq5muufK8Jg8Xiu00=; b=j87/lFRWmTvftRlyexHI3vUGMB6QWsFMryMTSVvqhyyWXZ6a1ECyUpWQ5EmBNdt4pK AQa8Q5mWGCnlkuP6N3yOCgucXcSKOZb5YwM+cMe5SHJ6leHPZu/edn7rzXVPjiHThX7s WXBYrGdJ9kbkEGq5dMH8qqDBBdIxn+qr2mz9djZ+zDqNZvnRPLUZ3DOSrxTa/b/thQ+y +6Wje0urS0TFid5BajQ+zsFuykJym2HBeG7zc43V059Y5qG8aKiYwGGt16i7mONQBEfm jXQvGjMpQqyjf8MRsGSpmk5pl7KAQdZ8Iddo9wfnx9wRr349ZKxhxQH+1tGbtg0RLrh3 MgSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fWBo/URZoi7GG03o7vt9qXqiXnYq5muufK8Jg8Xiu00=; b=Vt1XmhGAyaYBT60++KgDz9TUZANutBVAVKXYZkMKF1XQrqn8DqGWD8Y7i47O5nqVCn +2G1dVXEIS4iG9McHH1XoOgRWJw7mfKZv4C6o9EpitM/1xCMI51PcYX/mCbaDFpkEefm ijQbhTbhMiXx8E9TtYKWwBEL5SvSAfnIr1lkN7W1LBEdluRW/02AjyunwQPtAj8/5Yda Vh9+N6oc4oE5Z0IIAxQSsUZ+VHL01vi3Df5t2kZZuTontRRKfIXVwGi38pySBSMYlYCB WKrpNe4BovBsju0Refvs4wj+VrnhPTsndwSYdLdFUosQUoal53V3oX6JuZWJsW2V5Eb2 oHow== X-Gm-Message-State: AOAM531US9E169+7pBVU1DXnIP1nK2Imm4nu7HQMje23Amcvceg+oIPn MRKyj14Zol1u8mIhevb+LqAjmAVAL5eheQWEOzp11+eJ X-Google-Smtp-Source: ABdhPJxjM+w/VPzaFpdLyU0Lp32W+EWL2gU3bKR4kOTWpeXg03n5BtrCKcQnz0kjhH6uopcBuPqpsD8aQu5cEwcn48o= X-Received: by 2002:ac8:5a49:0:b0:2de:6fa3:f928 with SMTP id o9-20020ac85a49000000b002de6fa3f928mr5581228qta.677.1645770909898; Thu, 24 Feb 2022 22:35:09 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <8020452A-63EA-4424-8D20-CC9B9397B603@gmail.com> In-Reply-To: <8020452A-63EA-4424-8D20-CC9B9397B603@gmail.com> From: Sami Halabi Date: Fri, 25 Feb 2022 08:34:57 +0200 Message-ID: Subject: Re: linux debian jail - network problems To: Zhenlei Huang Cc: freebsd-jail@freebsd.org, freebsd-net@freebsd.org, freebsd-emulation@freebsd.org, FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000775b5f05d8d1e65b" X-Rspamd-Queue-Id: 4K4g4h4Xzcz4RQk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="j87/lFRW"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sodynet1@gmail.com designates 2607:f8b0:4864:20::832 as permitted sender) smtp.mailfrom=sodynet1@gmail.com X-Spamd-Result: default: False [0.00 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[5]; RCPT_COUNT_FIVE(0.00)[5]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::832:from]; HTTP_TO_IP(1.00)[]; MLMMJ_DEST(0.00)[freebsd-jail,freebsd-net,freebsd-emulation,freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000775b5f05d8d1e65b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thank you for your response.. I wonder if Is it really only netlink problem= ? Their are fee problems in the logs.. I dont kbow if they all related only to netlink (prctl immutable for example).. I also saw oncompatibilities in socket.c .... Btw: I tried to enter the link you sent and it asked for username and password.. its not public review? Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=95=D7=B3, 25 = =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2022, 04:18, =D7=9E=D7=90=D7=AA Zhenlei Huan= g =E2=80=8F< zlei.huang@gmail.com>: > Hi, > You can also track the WIP netlink feature, > https://reviews.freebsd.org/D33975 > > On Feb 25, 2022, at 4:05 AM, Sami Halabi wrote: > > Hi, > Added Current, maybe will be lucky ;) > > Anyone have idea how approach and fix this? > > Sami > > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=92=D7=B3, 22 = =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2022, 23:30, =D7=9E=D7=90=D7=AA Sami Halabi = =E2=80=8F >: > >> Hi all, >> sorry for the cross post but I need help and I'm not sure where it hangs= . >> >> I create linux jail (debian bullseye) via cbsd. >> the jail is being populated with the debian userland.. >> so far so good... services running (sshd) and I can login to the jail, I >> also can update packages and I can install apache httpd and all works fi= ne >> (apt install or make from src). >> I also manage to install packages even if their scripts depend on "ip" >> command that fails: >> cbsd@j2> ip >> Cannot open netlink socket: Address family not supported by protocol >> >> ifconfig show empty interfaces: >> cbsd@j2> ifconfig >> eth0: flags=3D4163 mtu 1500 >> ether 00:50:56:0a:b3:a0 (Ethernet) >> RX packets 139798314 bytes 12029597009 (11.2 GiB) >> RX errors 0 dropped 0 overruns 0 frame 0 >> TX packets 26879143 bytes 34400160833 (32.0 GiB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> >> lo0: flags=3D4169 mtu 16384 >> loop (Local Loopback) >> RX packets 28548 bytes 160312960 (152.8 MiB) >> RX errors 0 dropped 0 overruns 0 frame 0 >> TX packets 28548 bytes 160312960 (152.8 MiB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >> >> I know linux emulation doesn't implement netlink.. so what I do is fake >> the response by replacing /bin/ip by a bash script that prints the corre= ct >> IP and fakes some other (needed by packages i Installed): >> #!/bin/bash >> if [ "$1" =3D "-o" ]; then >> echo "1: eth0 inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0" >> elif [ "$1" =3D "route" ]; then >> if [ "$2" =3D "get" ]; then >> echo "8.8.8.8 via 192.168.1.2 dev eth0 src >> 192.168.1.2 " >> else >> echo "default via 192.168.1.2 dev eth0" >> fi >> else >> echo "1: eth0: mtu 1500 qdisc mq state >> UP qlen 1000" >> echo " inet 192.168.1.2 /24 brd 192.168.1.255 scope global eth0" >> >> >> still ifconfig shows no IP... its time to say it a regular jail and *NOT= * >> VNET. >> >> *however* package that pull ips via libraries fail.. >> eg: installed bind916 (name) in the logs I see these errors (relevant >> only): >> cbsd@j2> service named start >> Starting domain name service...: namednamed: prctl(PR_SET_DUMPABLE) >> failed: Invalid argument >> cbsd@j2> >> >> >> log file shows: >> 22-Feb-2022 23:11:58.705 general: notice: BIND 9 is maintained by >> Internet Systems Consortium, >> 22-Feb-2022 23:11:58.705 general: notice: Inc. (ISC), a non-profit >> 501(c)(3) public-benefit >> 22-Feb-2022 23:11:58.705 general: notice: corporation. Support and >> training for BIND 9 are >> 22-Feb-2022 23:11:58.705 general: notice: available at >> https://www.isc.org/support >> 22-Feb-2022 23:11:58.705 general: notice: >> ---------------------------------------------------- >> 22-Feb-2022 23:11:58.705 general: info: found 6 CPUs, using 6 worker >> threads >> 22-Feb-2022 23:11:58.705 general: info: using 6 UDP listeners per >> interface >> 22-Feb-2022 23:11:58.705 general: info: using up to 21000 sockets >> 22-Feb-2022 23:11:58.715 general: info: loading configuration from >> '/etc/bind/named.conf' >> 22-Feb-2022 23:11:58.715 general: info: reading built-in trust anchors >> from file '/etc/bind/bind.keys' >> 22-Feb-2022 23:11:58.715 general: info: looking for GeoIP2 databases in >> '/usr/share/GeoIP' >> 22-Feb-2022 23:11:58.715 general: info: using default UDP/IPv4 port >> range: [1024, 65535] >> 22-Feb-2022 23:11:58.715 general: info: using default UDP/IPv6 port >> range: [1024, 65535] >> 22-Feb-2022 23:11:58.715 network: info: no IPv6 interfaces found >> 22-Feb-2022 23:11:58.715 general: error: ifiter_getifaddrs.c:79: >> unexpected error: >> 22-Feb-2022 23:11:58.715 general: error: getting interface addresses: >> getifaddrs: Address family not supported by protocol >> 22-Feb-2022 23:11:58.715 network: warning: not listening on any interfac= es >> *snip* >> *snip* >> 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected error= : >> 22-Feb-2022 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS) >> failed: Protocol not available >> 22-Feb-2022 23:11:58.735 general: notice: couldn't add command channel >> 127.0.0.1#953: permission denied >> 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected error= : >> 22-Feb-2022 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS) >> failed: Protocol not available >> 22-Feb-2022 23:11:58.735 general: notice: couldn't add command channel >> 127.0.0.1#953: permission denied >> 22-Feb-2022 23:11:58.735 zoneload: info: managed-keys-zone: loaded seria= l >> 24 >> 22-Feb-2022 23:11:58.735 zoneload: info: zone 0.in-addr.arpa/IN: loaded >> serial 1 >> 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected error= : >> 22-Feb-2022 23:11:58.735 general: error: setsockopt(512, IP_RECVTOS) >> failed: Protocol not available >> 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected error= : >> 22-Feb-2022 23:11:58.735 general: error: setsockopt(513, IP_RECVTOS) >> failed: Protocol not available >> 22-Feb-2022 23:11:58.745 zoneload: info: zone 255.in-addr.arpa/IN: loade= d >> serial 1 >> 22-Feb-2022 23:11:58.745 zoneload: info: zone j1.royalshells.com/IN: >> loaded serial 2022022106 >> 22-Feb-2022 23:11:58.745 notify: info: zone j1.royalshells.com/IN: >> sending notifies (serial 2022022106) >> 22-Feb-2022 23:11:58.745 general: error: socket.c:2405: unexpected error= : >> 22-Feb-2022 23:11:58.745 general: error: setsockopt(514, IP_RECVTOS) >> failed: Protocol not available >> 22-Feb-2022 23:11:58.745 zoneload: info: zone localhost/IN: loaded seria= l >> 2 >> 22-Feb-2022 23:11:58.745 general: error: socket.c:2405: unexpected error= : >> 22-Feb-2022 23:11:58.745 general: error: setsockopt(515, IP_RECVTOS) >> failed: Protocol not available >> 22-Feb-2022 23:11:58.745 zoneload: info: zone 127.in-addr.arpa/IN: loade= d >> serial 1 >> 22-Feb-2022 23:11:58.745 general: notice: all zones loaded >> 22-Feb-2022 23:11:58.745 general: notice: running >> 22-Feb-2022 23:11:58.795 general: error: socket.c:2405: unexpected error= : >> 22-Feb-2022 23:11:58.795 general: error: setsockopt(50, IP_RECVTOS) >> failed: Protocol not available >> 22-Feb-2022 23:12:58.811 general: error: ifiter_getifaddrs.c:79: >> unexpected error: >> 22-Feb-2022 23:12:58.811 general: error: getting interface addresses: >> getifaddrs: Address family not supported by protocol >> 22-Feb-2022 23:12:58.811 network: warning: not listening on any interfac= es >> >> Any Idea how to fix this?? >> >> cbsd@j2> named -V >> BIND 9.16.22-Debian (Extended Support Version) >> running on Linux x86_64 3.2.0 FreeBSD 12.3-RELEASE-p1 GENERIC >> >> installing newer versions >> >> I have also problems with dovecot mail package.. but will leave it for n= ow >> >> Thanks in advance, >> Sami >> >> > --000000000000775b5f05d8d1e65b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Thank you for your response.. I wond= er if Is it really only netlink problem?
Their are f= ee problems in the logs.. I dont kbow if they all related only to netlink (= prctl immutable for example).. I also saw oncompatibilities in socket.c ...= .

Btw: I tried to enter = the link you sent and it asked for username and password.. its not public r= eview?

Sami
<= br>
=D7=91= =D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=95=D7=B3, 25 =D7=91= =D7=A4=D7=91=D7=A8=D7=B3 2022, 04:18, =D7=9E=D7=90=D7=AA Zhenlei Huang =E2= =80=8F<zlei.huang@gmail.com&= gt;:
Hi,
You can also track the WIP netli= nk feature,=C2=A0https://reviews.freebsd.org/D33975
On Feb 25, 2022, at 4:05 AM, Sami Halabi &= lt;sodynet1@gmail.com> wrote:

Hi,Added Current, maybe will be lucky ;)

Anyone have idea how approach and fix this?

Sami

=D7=91=D7=AA=D7= =90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=92=D7=B3, 22 =D7=91=D7=A4=D7= =91=D7=A8=D7=B3 2022, 23:30, =D7=9E=D7=90=D7=AA Sami Halabi =E2=80=8F<so= dynet1@gmail.com>:
Hi all,
sorry for the cross post but I need help and I'm n= ot sure where it hangs.

I create linux jail (debia= n bullseye) via cbsd.
the jail is being populated with the debian= userland..
so far so good... services running (sshd) and I can l= ogin to the jail, I also can update packages=C2=A0and I can install apache = httpd and all works fine (apt install or make from src).
I also m= anage to install packages even if their scripts depend on "ip" co= mmand that fails:
cbsd@j2> ip
Cannot open netlink socket: A= ddress family not supported by protocol

ifconf= ig show empty interfaces:
cbsd@j2> ifconfig
eth0: flags=3D4= 163<UP,BROADCAST,RUNNING,MULTICAST> =C2=A0mtu 1500
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 ether 00:50:56:0a:b3:a0 =C2=A0(Ethernet)
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 RX packets 139798314 =C2=A0bytes 12029597009 (11.2 GiB)
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 RX errors 0 =C2=A0dropped 0 =C2=A0overruns 0 =C2= =A0frame 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TX packets 26879143 =C2=A0bytes 3= 4400160833 (32.0 GiB)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TX errors 0 =C2=A0drop= ped 0 overruns 0 =C2=A0carrier 0 =C2=A0collisions 0

lo0: flags=3D416= 9<UP,LOOPBACK,RUNNING,MULTICAST> =C2=A0mtu 16384
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 loop =C2=A0(Local Loopback)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RX pa= ckets 28548 =C2=A0bytes 160312960 (152.8 MiB)
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 RX errors 0 =C2=A0dropped 0 =C2=A0overruns 0 =C2=A0frame 0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 TX packets 28548 =C2=A0bytes 160312960 (152.8 MiB)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 TX errors 0 =C2=A0dropped 0 overruns 0 =C2=A0ca= rrier 0 =C2=A0collisions 0

I know linux emulat= ion doesn't implement netlink.. so what I do is fake the response by re= placing /bin/ip by a bash script that prints the correct IP and fakes some = other (needed by packages i Installed):
#!/bin/bash
if [ &= quot;$1" =3D "-o" ]; then
echo "1: eth0 inet = 192.168.1.2/24 brd 192.168.1.255 scope global eth0"
elif [ &quo= t;$1" =3D "route" ]; then
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if = [ "$2" =3D "get" ]; then
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 echo "8.8.8.8 via=C2=A0 192.168.1.2=C2=A0=C2=A0=C2=A0dev eth0 =C2=A0src=C2=A0 192.168.1.2=C2=A0 "
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 echo "default via=C2=A0 192.168.1.2=C2=A0=C2=A0=C2=A0dev eth0"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = fi
else
echo "1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> m= tu 1500 qdisc mq state UP qlen 1000"
echo " =C2=A0inet=C2=A0 192.168.1.2=C2=A0 /24 brd=C2=A0 192.168.1.255 scope global eth0"

still ifconfig shows no IP... its time to say it a regular jail= and *NOT* VNET.

*however* package that pull ips v= ia libraries fail..
eg: installed bind916 (name) in the logs I se= e these errors (relevant only):
cbsd@j2> service named startStarting domain name service...: namednamed: prctl(PR_SET_DUMPABLE) faile= d: Invalid argument
cbsd@j2>


<= div>log file shows:
22-Feb-2022 23:11:58.705 general: notice: BIN= D 9 is maintained by Internet Systems Consortium,
22-Feb-2022 23:11:58.7= 05 general: notice: Inc. (ISC), a non-profit 501(c)(3) public-benefit
22= -Feb-2022 23:11:58.705 general: notice: corporation.=C2=A0 Support and trai= ning for BIND 9 are
22-Feb-2022 23:11:58.705 general: notice: available = at https://www.isc.org/support
22-Feb-2022 23:11:58.705= general: notice: ----------------------------------------------------
2= 2-Feb-2022 23:11:58.705 general: info: found 6 CPUs, using 6 worker threads=
22-Feb-2022 23:11:58.705 general: info: using 6 UDP listeners per inter= face
22-Feb-2022 23:11:58.705 general: info: using up to 21000 sockets22-Feb-2022 23:11:58.715 general: info: loading configuration from '/= etc/bind/named.conf'
22-Feb-2022 23:11:58.715 general: info: reading= built-in trust anchors from file '/etc/bind/bind.keys'
22-Feb-2= 022 23:11:58.715 general: info: looking for GeoIP2 databases in '/usr/s= hare/GeoIP'
22-Feb-2022 23:11:58.715 general: info: using default UD= P/IPv4 port range: [1024, 65535]
22-Feb-2022 23:11:58.715 general: info:= using default UDP/IPv6 port range: [1024, 65535]
22-Feb-2022 23:11:58.7= 15 network: info: no IPv6 interfaces found
22-Feb-2022 23:11:58.715 gene= ral: error: ifiter_getifaddrs.c:79: unexpected error:
22-Feb-2022 23:11:= 58.715 general: error: getting interface addresses: getifaddrs: Address fam= ily not supported by protocol
22-Feb-2022 23:11:58.715 network: warning:= not listening on any interfaces
*snip*
*snip*
22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected er= ror:
22-Feb-2022 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS)= failed: Protocol not available
22-Feb-2022 23:11:58.735 general: notice= : couldn't add command channel 127.0.0.1#953: permission denied
22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected e= rror:
22-Feb-2022 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS= ) failed: Protocol not available
22-Feb-2022 23:11:58.735 general: notic= e: couldn't add command channel 127.0.0.1#953: permission denied
22-= Feb-2022 23:11:58.735 zoneload: info: managed-keys-zone: loaded serial 2422-Feb-2022 23:11:58.735 zoneload: info: zone 0.in-addr.arpa/IN: loaded s= erial 1
22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpect= ed error:
22-Feb-2022 23:11:58.735 general: error: setsockopt(512, IP_RE= CVTOS) failed: Protocol not available
22-Feb-2022 23:11:58.735 general: = error: socket.c:2405: unexpected error:
22-Feb-2022 23:11:58.735 general= : error: setsockopt(513, IP_RECVTOS) failed: Protocol not available
22-F= eb-2022 23:11:58.745 zoneload: info: zone 255.in-addr.arpa/IN: loaded seria= l 1
22-Feb-2022 23:11:58.745 zoneload: info: zone j1.royal= shells.com/IN: loaded serial 2022022106
22-Feb-2022 23:11:58.745 not= ify: info: zone j1.royalshells.com/IN: sending notifies (= serial 2022022106)
22-Feb-2022 23:11:58.745 general: error: socket.c:240= 5: unexpected error:
22-Feb-2022 23:11:58.745 general: error: setsockopt= (514, IP_RECVTOS) failed: Protocol not available
22-Feb-2022 23:11:58.74= 5 zoneload: info: zone localhost/IN: loaded serial 2
22-Feb-2022 23:11:5= 8.745 general: error: socket.c:2405: unexpected error:
22-Feb-2022 23:11= :58.745 general: error: setsockopt(515, IP_RECVTOS) failed: Protocol not av= ailable
22-Feb-2022 23:11:58.745 zoneload: info: zone 127.in-addr.arpa/I= N: loaded serial 1
22-Feb-2022 23:11:58.745 general: notice: all zones l= oaded
22-Feb-2022 23:11:58.745 general: notice: running
22-Feb-2022 2= 3:11:58.795 general: error: socket.c:2405: unexpected error:
22-Feb-2022= 23:11:58.795 general: error: setsockopt(50, IP_RECVTOS) failed: Protocol n= ot available
22-Feb-2022 23:12:58.811 general: error: ifiter_= getifaddrs.c:79: unexpected error:
22-Feb-2022 23:12:58.811 general: err= or: getting interface addresses: getifaddrs: Address family not supported b= y protocol
22-Feb-2022 23:12:58.811 network: warning: not lis= tening on any interfaces

Any Idea how to fix t= his??

cbsd@j2> named -V
BIND 9.16.22-Debian = (Extended Support Version) <id:59bfaba>
running on Linux x86_64 3.= 2.0 FreeBSD 12.3-RELEASE-p1 GENERIC

installing= newer=C2=A0versions=C2=A0

I have also problems wi= th dovecot mail package.. but will leave it for now

Thanks in advance,
Sami


--000000000000775b5f05d8d1e65b-- From nobody Fri Feb 25 08:11:20 2022 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 7336819CD89B for ; Fri, 25 Feb 2022 08:11:36 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4jCq44Zkz4cMK; Fri, 25 Feb 2022 08:11:35 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id A259422504; Fri, 25 Feb 2022 09:11:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1645776686; 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=9PzUKgt9+BmjEc/aQkTY9syJP9A0NiU4Wr5cf8pn9lY=; b=fs5cYeAR5iwCvNTWJ96hBaNqA8gS4b6FRzNzJSg7ypnDQ4MR2JZyOsz/2OoU1uq9EiE3ab yLvCYPAd2SFrGD/UQa7foxxsVVAmvtujHZxZ9pIfMWv17v1Ug1clP5ghlFs0ojLcDQNxYD Kreg9NMG5tpNtsEF/dZJGOaVJiPl7p+SymoLVNt9b0NSkVON4DNddXi8pYOhy7WlP+G6ab SECnNaxGYN5gkY8wvyeKj7i+4R6IKmJuGyxTwqbGubW+EQtvUkToXdX9v+9EMbmuPZ2MCL oSiy/fdLqSrtMK40CwVJFVce0UBTL9YqRaWwpTZsQhXDZ+44wYJuzBuX52SA4A== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id E2BBEA34F; Fri, 25 Feb 2022 09:11:23 +0100 (CET) Date: Fri, 25 Feb 2022 09:11:20 +0100 Message-ID: <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> From: Alexander Leidinger To: Larry Rosenman Cc: Rob Wing , Alexander Motin , Freebsd current Subject: Re: ZFS PANIC: HELP. References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_xFrLR_GIlchgPFnKjZgKxpv"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4K4jCq44Zkz4cMK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=fs5cYeAR; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-3.32 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; SUBJ_ALL_CAPS(1.20)[16]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.919]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_xFrLR_GIlchgPFnKjZgKxpv Content-Type: multipart/alternative; boundary="=_4JozhWVC1sH2Lb3fj6rS8VE" This message is in MIME format. --=_4JozhWVC1sH2Lb3fj6rS8VE Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Description: Textnachricht Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Larry Rosenman (from Thu, 24 Feb 2022=20=20 20:19:45=20-0600): > I tried a scrub -- it panic'd on a fatal double fault.=C2=A0 > > Suggestions? The safest / cleanest (but not fastest) is data export and pool=20=20 re-creation.=20If you export dataset by dataset (instead of recursively=20= =20 all),=20you can even see which dataset is causing the issue. In case=20=20 this=20per dataset export narrows down the issue and it is a dataset you=20= =20 don't=20care about (as in: 1) no issue to recreate from scratch or 2)=20=20 there=20is a backup available) you could delete this (or each such)=20=20 dataset=20and re-create it in-place (=3D not re-creating the entire pool). Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_4JozhWVC1sH2Lb3fj6rS8VE Content-Type: text/html; charset=utf-8 Content-Description: HTML-Nachricht Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Quoting Larry Rosenman <ler@lerctr.= org> (from Thu, 24 Feb 2022 20:19:45 -0600):

I tried a scrub -- it panic'd on a fatal double fault. 

Suggestions?

The safest / cleanest (but not fastest) is data export and pool re-creat= ion. If you export dataset by dataset (instead of recursively all), you can= even see which dataset is causing the issue. In case this per dataset expo= rt narrows down the issue and it is a dataset you don't care about (as in: = 1) no issue to recreate from scratch or 2) there is a backup available) you= could delete this (or each such) dataset and re-create it in-place (=3D no= t re-creating the entire pool).

Bye,
Alexander.

--=_4JozhWVC1sH2Lb3fj6rS8VE-- --=_xFrLR_GIlchgPFnKjZgKxpv Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmIYjycACgkQEg2wmwP4 2IZWAw/+P59dn2jnmsVWepX9cVt30jfbDyoGQEJfYwmlaCwsMp1p8YA4vIHK0uFZ Ytb/kQrzDmqs3iqKCjMD312ZdUHagFUkuyLhvElr/ycybC6HasMCVPca8t/JLUi+ 8j+JAx1Lj6yMc2MkkYNxE3N4aysLn4QDBysR/UFlS0zwCKXM40dyCyCwcphtkMhI KqYfwlJQct9aaDoqdIXPC01k/ubE0MKIFhOcIkhDFndD/YTqppkJc9AWTf8lEGWW eQXS7aeR6SUgNqL9wmpo5gW/sTSZqEKlfInktd2gok5my40RLSe8UlxvFIjw+f8G KmsC2OpsTGCgSLoDXcSKvwtpuNLTsUyzrM235ZVvxwwMJMBJbC0zBLEVGSJLPjPs jcw8Gbb+yUF45L00oNpyjKl0leCKLGlMTn8tzHcrpYsdTAMuGFVZMkvY0WsKt70T ttNzkWvnMsU0sTjwh1KsFCS0MykO6VGHVxV5Sov3mxf8Ywk3cE+CzOCL7j1oq1qS d7b9Fj913LZJW5bbQQVIGW0PLhM+I3wREXdy2NGf8z28x0UG4cJr7K0ex14USfop PNgqN0x1tmnI5M5w0x6wBQjjbMIzh83uWhFtOUwFuiAcA8crKsNTToiwhvmLob7f OdzIZcgivs56iZ2VaeRqEIrPUQvoAqlsajTqHWnW4fUi2dPAO3w= =Ihx8 -----END PGP SIGNATURE----- --=_xFrLR_GIlchgPFnKjZgKxpv-- From nobody Fri Feb 25 10:49:36 2022 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 A436319E9AB9 for ; Fri, 25 Feb 2022 10:49:57 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic308-56.consmr.mail.ne1.yahoo.com (sonic308-56.consmr.mail.ne1.yahoo.com [66.163.187.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4mkX5r5Sz3C0C for ; Fri, 25 Feb 2022 10:49:56 +0000 (UTC) (envelope-from filippomore@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1645786178; bh=fzIygfxpsL3VsIEmyhxnppIssO4ogTGg4qN4fDBgvqM=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=TxkKoN2v49wxDjkkLlPT6qII0adAI5n9YlTGonufMH49GfAsStPmsuHlFZxLLlzHI0vbJN4V3H33+fPyZlZvae3S+sp331wOzSwzXcCvsT9ETZdX+Ftz9YPFNUHMGjV32hjWCAleuXcSrfmKg7tyJVqhiKn5ar+ljBA9dgRy++o0xruQMaG1MFrjlPwRG/QsmC72D1siwBxr2hQkhwgyuNLZX/3U+obQ1PJlhPii7w1O4EDcFFtECGuPq0/Q+WqLS+mVgCJv6hLYcPHGiPlUgwEBTaMS3QoKsodL1D9MziC+1idxoE7tPG/bkvk7HNOfrGIt03eh5HYouxOz0Jrv9w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1645786178; bh=c7xxqZteFNLkzIcc5FnTVQ8ulIE6MUuYD+eGukzMY/W=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=h3S/Ql7hvWRaQUqaDa7rx3qI/SBaN8ldmON+XhxpNeK1K6x8KnE2Tj5w2+rxvHAsDSzJIOP7ODxgpf07CrbbtiQtyHRoTrr9IIxJauCjflNbtMKH5r7DOT6xolCAdjIVmtjWwWggTIPUY21PjsWUSRwEQFLbApmxOyDTC5ccH0LIMjMMimtaxpY3ABR/3PAR5KuERRBeMxtsLdUM8+bgC1SUgXH1lrrTSB4obnEvqOsBomFYGGLRMbFe4vbDZAXWfzRGlKn+Bkybnf56Iat71BM+wxTQRw82s0krj14ea5EGhvzOGk36xKSfualKl+uM6VEBkjBnosJe1CUvuVqawQ== X-YMail-OSG: HRy7BcUVM1nfpEK_.wXfCmctJYDZ84KPQxZEN.5IM7y63iLEYGiQFqAL7GKZUJ9 DOsVtI2Of0QDBtu0p81slCz.4ixhI16OfT8rPjNS41.9lAO2LD_iDZSiAPQcuUoQCCL95UjpKpDh vHAtkaUHpY9_WhHWB2UR2fb4bLMFcXSy6MwEp_PLOwVzuZTXFmbX36IDDIWCWJ1rP_ZCFW6Porz3 Vdc9RZ6DuGaY9ceABQqqCI78Y92TFZOaHRLf3yraWZ90RFG0FoqtiFhxBnE3WYhu5NNKxheu9RwS rYKiPehoSKjtqYQ1_epA6JTs.cOc8CYqkrrBH7adhOkds44XplKrMprcKZvO9MILlqwxdEJmAz5e J7obsp6Cj0IBgInJbJRh.wOQ03k0YEf3nr13xFDGPn5Sn.YaZ7A8oAKBRG6sYnv_od2TvVoC5vQM i8pyLU04yXNW4Z89uYGdhBUjRGugCMedqRmrnXCN9386MZKdnm0hrytW1y3C5ZNqbOqweQCWO2Kc gRfRdUqqGSqaMLo_7VwgwoTUGN.86LmWjpaM9S0cl15Gxlc6QsP7qEYKm8aHU0Vt2dJuvY8IG909 Hjiwuu7s6vOdlCgie2aYo5_NRbFXrYhfTe.ybACqiqHgBhFBIkaV.T4BPkYPOJQaYGKVYfdqcQc9 rP8Qvt9QQpGXZQdEzFggqaFtzEEV2V3M9cNGD728Y0.Ndh6zrvvxID71qIELTThvUIoVAI_fcIPi tQoBu6UoQq0EqiMgLzkBnlFDzJfEoFMVjZGYgS2mdMtPx8V1UCm07x5_kAToAcAnFBJFYVukZz8s m5tBO_tohRMvJBXXz7.cqjHpmAkMbqzXXppRadagqobkSX5zJbU4gkwlAEyAx.I4LCCJ2VIWm48W 1wJeBY7muUx2if.65.lBhEErJMj9ScCX1WYCjALG6rSUpL0V_dpfA8eHLbXxnZ0V5ybYKEX0pgJk TcvdTeYM9Ut5iKRhc7yi83Oz29NnRcRHWvyZLIcBYFM8yB02eocIZtxuHfrjKZu2Enf7bUzfxcsz FS8SzHt4dySSSyOwr5ScCIDCUrxfdQ.MgCawiur4LtF1wB6KymujVvbGNT0KLTcpmuzJJB.f8btQ P_Nfxrbe_nswi_Aggac8SSItdvFKmOk8ZIh0tAFZv_Oem4j6m26VgEwAD8T637TlhRnVX9muvg8g m.Wf8reATta4l2RtOThOomM.jIvNulZMw9QTkfO2H1aAf1V4gNTzKguHvVoFyTUzWXx8XglT6gos zMqJUjrGjQtbc14DVd0xIEz7TB1s4Emd03wKxc8A0HEZ6Qdp5DEBj6tx47dDgGqBTdJ_HDNarl4F x8BDy.NgjczK1dXzr_Bu_UN6TJFLHwsMorFJgDiXb_1j1cZmpREHk0TEj0E3zz.15XVmBPIJkhT5 ECju8JKuCFNTcw3_GLZ25i.HbnQyU9Y.VlgFHJA_xoKAAwQ5glwZQhHaw.CghExgDdVPjWK1b_fD DqMYk2WV1uHYQ52v9Iy1HiArcKi7Whog0OTLrFyf30UWYDrD3Al2pdxaf5ln_L9_1fsHHrVnMrEm 9SW.kfREJLR05r5N1zB_zM9nNYfb3Zy51AxOjq9TicjdpgcEoozJ598UlUe7YvjtSz69xN7tDXBe XpA7DG9lWUWgBHf_LAqH2gNb9IOom3TVVyTTdrVdDquj9r9pzn8wQfiY5DA5cxjPp1d8Ng2uU0KI WhQRVPR3B80YwI4wsAxFBeFvAML1PZGK4_xqyuUs7VUZ5cUwADwnpAPUKY8ssR002EfESPDWQath pIcUOIYJV7hpcrjNpQ6ynUVnHs0BDp04ogpDzPgCBbd0a1yb6J_EffJKCbCL0.9VRLAexd7Em9qf xx6QDUYs6PU7DvGgnppWLBMNto7rx_O4l2ZOjNUW8aH4N5bxWwKuLHQN23poRz6VrQP1tM3K6IGS 9FuuNvFBc4v6F46qVJ8UMUYpBzVTnMreVYLvSgBEvW6Q46sqjeSO5EHtPUsMsn21UfsDc08.e8J1 epn2lIe8Ui51gu7N22cATq_tsvCIQRVIQZQ8ExhL6CzKYNU1GGxct74palZZIJANNtwQM9TfjIDd Mc9Quy2vlxdA0SqCNPuJpL9Mj.ogb7YHwCNr6gp4ue8OsgG0FTap8hSoYOA9EAQBZ4jTE1jZX.wl 8nJM8U_1KsYOexP590qraSDGa7NQdhsSFvDg- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 25 Feb 2022 10:49:38 +0000 Date: Fri, 25 Feb 2022 10:49:36 +0000 (UTC) From: Filippo Moretti To: FreeBSD Current Message-ID: <2108564249.2590143.1645786176428@mail.yahoo.com> Subject: Error building openoffice in current 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_2590142_2114968040.1645786176427" References: <2108564249.2590143.1645786176428.ref@mail.yahoo.com> X-Mailer: WebService/1.1.19797 YMailNorrin X-Rspamd-Queue-Id: 4K4mkX5r5Sz3C0C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=TxkKoN2v; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.187.31 as permitted sender) smtp.mailfrom=filippomore@yahoo.com X-Spamd-Result: default: False [-3.78 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.187.31:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[66.163.187.31:from]; NEURAL_HAM_SHORT(-0.78)[-0.776]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_2590142_2114968040.1645786176427 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable gmake[1]: Leaving directory '/usr/ports/editors/openoffice-4/work/aoo-4.1.1= 1/main/sw' sw deliver deliver -- version: 275594 COPY: build.lst -> /usr/ports/editors/openoffice-4/work/aoo-4.1.11/main/sol= ver/4111/unxfbsdx.pro/inc/sw/build.lst LOG: writing /usr/ports/editors/openoffice-4/work/aoo-4.1.11/main/solver/41= 11/unxfbsdx.pro/inc/sw/deliver.log Module 'sw' delivered successfully. 1 files copied, 0 files unchanged 1 module(s):=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 testtools need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /usr/ports/editors/openoffice-4/wo= rk/aoo-4.1.11/main/testtools/source/bridgetest When you have fixed the errors in that module you can resume the build by r= unning: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 build --from testtoolsI get this= error when trying to update openoffice-4any help appreciatedFilippo ------=_Part_2590142_2114968040.1645786176427 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
gmake[1]: Leaving directory '/usr/ports= /editors/openoffice-4/work/aoo-4.1.11/main/sw'
sw deliver
deliver -- = version: 275594
COPY: build.lst -> /usr/ports/editors/openoffice-4/wo= rk/aoo-4.1.11/main/solver/4111/unxfbsdx.pro/inc/sw/build.lst
LOG: writin= g /usr/ports/editors/openoffice-4/work/aoo-4.1.11/main/solver/4111/unxfbsdx= .pro/inc/sw/deliver.log
Module 'sw' delivered successfully. 1 files copi= ed, 0 files unchanged

1 module(s):
     = ;   testtools
need(s) to be rebuilt

Reason(s):

E= RROR: error 65280 occurred while making /usr/ports/editors/openoffice-4/wor= k/aoo-4.1.11/main/testtools/source/bridgetest

When you have fixed th= e errors in that module you can resume the build by running:

 &= nbsp;      build --from testtools
I get this error when= trying to update openoffice-4
= any help appreciated
Filippo
=
------=_Part_2590142_2114968040.1645786176427-- From nobody Sat Feb 26 02:03:51 2022 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 8930A19CF389 for ; Sat, 26 Feb 2022 02:03:56 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K59174Pkhz4nW1; Sat, 26 Feb 2022 02:03:55 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To: From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=HxfOZSVIxhhoYc6J4FcK74owBsjp14CKDKJjIWDQFxQ=; b=naTHpb6klnQ6zUxX/+VzvaY4vn uprGPL1dZCb7ZVpfoRqx1yvMOPcGSmu28NoJWZKoYj8BjHoOGWBXHwoU3iMaHZK0Snq7iaslBuaX5 6KbO55aPpJ3ZBV+EhwVq91UPGGP/aDtJZBQq/mBQguTvrbpIZWvuz2w+ImqtCAwHjU90btgDMQWhb kKrOdjCgAkdVVg6JO0umIhQOELw1fC10gU152OL6AivkSQF9l7otDbtfJAzjVWI1mpyUZF+U/yjz+ GVEPApPhCqQUPdBBEPpqlCNGi7I43eGd8hdkIyUlg1EaT5oPlPHqIx3yHpNkgQHSVvH6PnPsoNo8T FRc8VpUQ==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:60374 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nNmR5-000CL5-TX; Fri, 25 Feb 2022 20:03:51 -0600 Received: from 2600:1700:210:b18f:97c:f609:c6e2:df80 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 25 Feb 2022 20:03:51 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Fri, 25 Feb 2022 20:03:51 -0600 From: Larry Rosenman To: Alexander Leidinger Cc: Rob Wing , Alexander Motin , Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> Message-ID: X-Sender: ler@lerctr.org Content-Type: multipart/alternative; boundary="=_c7968c98c9db15b5ca066756c67c3273" X-Rspamd-Queue-Id: 4K59174Pkhz4nW1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=naTHpb6k; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_c7968c98c9db15b5ca066756c67c3273 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 02/25/2022 2:11 am, Alexander Leidinger wrote: > Quoting Larry Rosenman (from Thu, 24 Feb 2022 20:19:45 > -0600): > >> I tried a scrub -- it panic'd on a fatal double fault. >> >> Suggestions? > > The safest / cleanest (but not fastest) is data export and pool > re-creation. If you export dataset by dataset (instead of recursively > all), you can even see which dataset is causing the issue. In case this > per dataset export narrows down the issue and it is a dataset you don't > care about (as in: 1) no issue to recreate from scratch or 2) there is > a backup available) you could delete this (or each such) dataset and > re-create it in-place (= not re-creating the entire pool). > > Bye, > Alexander. > > http://www.Leidinger.net Alexander@Leidinger.net: PGP > 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP > 0x8F31830F9F2772BF I'm running this script: #!/bin/sh for i in $(zfs list -H | awk '{print $1}') do FS=$1 FN=$(echo ${FS} | sed -e s@/@_@g) sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh ler@freenas.lerctr.org cat - \> $FN done How will I know a "Problem" dataset? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 --=_c7968c98c9db15b5ca066756c67c3273 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 02/25/2022 2:11 am, Alexander Leidinger wrote:

Quoting Larry Rosenman <ler@lerctr.org> (from Thu, 24 Feb 2022 20:19:45 -0600):

I tried a scrub -- it panic'd on a fatal double fault. 

Suggestions?

The safest / cleanest (but not fastest) is data export and pool re-creat= ion. If you export dataset by dataset (instead of recursively all), you can= even see which dataset is causing the issue. In case this per dataset expo= rt narrows down the issue and it is a dataset you don't care about (as in: = 1) no issue to recreate from scratch or 2) there is a backup available) you= could delete this (or each such) dataset and re-create it in-place (=3D no= t re-creating the entire pool).

Bye,
Alexander.

http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2= 772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : P= GP 0x8F31830F9F2772BF

I'm running this script:
#!/bin/sh
for i in $(zfs list -H | aw= k '{print $1}')
do
  FS=3D$1
  FN=3D$(echo ${FS} |= sed -e s@/@_@g)
  sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh = ler@freenas.lerctr.org cat - \> $FN
done


How will I know a "Problem" dataset?


= -- 
Larry Rosenman     &n= bsp;            = ;   http://www.lerctr.org/~ler
Phone: +1 = 214-642-9640           &n= bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=
--=_c7968c98c9db15b5ca066756c67c3273-- From nobody Sat Feb 26 12:04:12 2022 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 3DD0219E6AC2 for ; Sat, 26 Feb 2022 12:04:20 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K5QKt4XkBz4d4d for ; Sat, 26 Feb 2022 12:04:17 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 21QC4Dp9044039 for ; Sat, 26 Feb 2022 21:04:13 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 26 Feb 2022 21:04:12 +0900 From: Tomoaki AOKI To: "freebsd-current@freebsd.org" Subject: Build faulure of editors/libreoffice only on src main (stable/13 is OK) Message-Id: <20220226210412.f3599f415923a0b369c248bb@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K5QKt4XkBz4d4d X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.27 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.67)[-0.672]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received] X-ThisMailContainsUnwantedMimeParts: N (Re-sent as not yet delivered in more than 5 hours) Hi. I have a build failure of editors/libreoffice on src main, amd64. As I've reported on Bug 262008 [1], problems on stable/13 is already fixed, but still fails on main with different faulure mode. A tool gengal.bin, built within whole libreoffice build, coredumps but it went OK on stable/13. Port options are now default on both main and stable/13. I now come to suspect the differences about toolchains within main and stable/13, but as editors/libreoffivce is giant and this failure happenes almost at the end of build, usual bisecting is not realistic. (Would require tens of weekends, maybe.) Any thoughts? Or am I missing something to check for? Regards. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008 -- Tomoaki AOKI From nobody Sat Feb 26 13:14:08 2022 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 9817A19CD48B for ; Sat, 26 Feb 2022 13:14:15 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K5RtZ0JnQz4p8N; Sat, 26 Feb 2022 13:14:13 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 21QDE8JR052436; Sat, 26 Feb 2022 22:14:08 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 26 Feb 2022 22:14:08 +0900 From: Tomoaki AOKI To: Michael Gmelin Cc: "freebsd-current@freebsd.org" Subject: Re: Build faulure of editors/libreoffice only on src main (stable/13 is OK) Message-Id: <20220226221408.6717d4517fdafe15dfad2f20@dec.sakura.ne.jp> In-Reply-To: References: <20220226210412.f3599f415923a0b369c248bb@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.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-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K5RtZ0JnQz4p8N X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-0.96 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.36)[-0.363]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received] X-ThisMailContainsUnwantedMimeParts: N Thanks. But unfortunately, as I've described at Comment 21 [2] of Bug 262008, setting kern.elf64.aslr.enable=0 didn't help. As I'm building on amd64 and not built for compat32, I've not touched kern.elf32.aslr.enable. And as these are regular writable sysctl (and also are tunables, too), setting these in /boot/loader.conf and reboot before build is not tested. Should I set more sysctl's? I thought setting above actually disable all aslr related features (for 64bit), regardless its 1 ro 0. Error messages (with "MAKE_JOBS_UNSAFE=yes") and backtraces are described at Comment 20 [3]. [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008#c21 [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008#c20 On Sat, 26 Feb 2022 13:29:26 +0100 Michael Gmelin wrote: > Maybe it$B!G(Bs related to ASLR? (or is it also enabled in 13/stable?) > > > On 26. Feb 2022, at 13:05, Tomoaki AOKI wrote: > > > > $B".(B(Re-sent as not yet delivered in more than 5 hours) > > > > Hi. > > > > I have a build failure of editors/libreoffice on src main, amd64. > > As I've reported on Bug 262008 [1], problems on stable/13 is already > > fixed, but still fails on main with different faulure mode. > > > > A tool gengal.bin, built within whole libreoffice build, coredumps but > > it went OK on stable/13. > > > > Port options are now default on both main and stable/13. > > > > I now come to suspect the differences about toolchains within main and > > stable/13, but as editors/libreoffivce is giant and this failure > > happenes almost at the end of build, usual bisecting is not realistic. > > (Would require tens of weekends, maybe.) > > > > Any thoughts? Or am I missing something to check for? > > > > Regards. > > > > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008 > > > > -- > > Tomoaki AOKI > > -- $B@DLZ(B $BCNL@(B [Tomoaki AOKI] From nobody Sat Feb 26 16:13:39 2022 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 6418D19EBFDE for ; Sat, 26 Feb 2022 16:13:55 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K5Wst3mPhz3MJ0; Sat, 26 Feb 2022 16:13:54 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id D0E4B237B7; Sat, 26 Feb 2022 17:13:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1645892025; 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=kWgUEynMTDnM47zyudvrse81hIy58AP/Hc6AsYraCAM=; b=Y9Sx7Xk4+k+L1ToxK0gcnRnBxijJzb/fk+o7/ZLIHZdi1M9y5MUUB9HB1o2/oq1tzLWugi Nc1+WOkPE5VHJNVVbONDZefecekhUeVojrRfSdk87JAMYUGEMTSuYb1v2iC8+9Qegl0KEb 3QhMTmoOJ6N/6KlyEWwb+p0aSUHDdbfmxAc+oqazUeCgpPMkkyaUaYHktsREKD+J6JooR4 MIkynCpjANoblYzLDSD6/BFNz83RDKo3SMWc+u2riiEM2MpVmyU2ovHuRZ5HstQPOEPRJx nWjkj9ziLpKpMUTdvVN5q0ux/pVnsnWKQt6sOkqbayYLlalRYwZCv2u2aaWceA== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 3769FA221; Sat, 26 Feb 2022 17:13:43 +0100 (CET) Date: Sat, 26 Feb 2022 17:13:39 +0100 Message-ID: <20220226171339.Horde.l4P5gYzg-XT3ZRAFvL4KBNq@webmail.leidinger.net> From: Alexander Leidinger To: Larry Rosenman Cc: Rob Wing , Alexander Motin , Freebsd current Subject: Re: ZFS PANIC: HELP. References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_6wtqejNbDh9PhdsKDTzVZom"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4K5Wst3mPhz3MJ0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=Y9Sx7Xk4; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-3.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; SUBJ_ALL_CAPS(1.20)[16]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_6wtqejNbDh9PhdsKDTzVZom Content-Type: multipart/alternative; boundary="=_IsRE-cZPUR6cZuTgtb5REjG" This message is in MIME format. --=_IsRE-cZPUR6cZuTgtb5REjG Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Description: Textnachricht Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Larry Rosenman (from Fri, 25 Feb 2022=20=20 20:03:51=20-0600): > On 02/25/2022 2:11 am, Alexander Leidinger wrote: > >> Quoting Larry Rosenman (from Thu, 24 Feb 2022=20=20 >>=2020:19:45 -0600): >> >>> I tried a scrub -- it panic'd on a fatal double fault.=C2=A0 >>> >>> Suggestions? >> >> The safest / cleanest (but not fastest) is data export and=20=20 >>=20pool re-creation. If you export dataset by dataset (instead of=20=20 >>=20recursively all), you can even see which dataset is causing the=20=20 >>=20issue. In case this per dataset export narrows down the issue and=20= =20 >>=20it is a dataset you don't care about (as in: 1) no issue to=20=20 >>=20recreate from scratch or 2) there is a backup available) you could=20= =20 >>=20delete this (or each such) dataset and re-create it in-place (=3D not= =20=20 >>=20re-creating the entire pool). >> >> Bye, >> Alexander. >> http://www.Leidinger.net Alexander@Leidinger.net: PGP=20=20 >>=200x8F31830F9F2772BF >> http://www.FreeBSD.org=C2=A0 =C2=A0 netchild@FreeBSD.org=C2=A0 : PGP 0x8= F31830F9F2772BF > > I'm running this script: > #!/bin/sh > for i in $(zfs list -H | awk '{print $1}') > do > =C2=A0 FS=3D$1 > =C2=A0 FN=3D$(echo ${FS} | sed -e s@/@_@g) > =C2=A0 sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh=20=20 >=20ler@freenas.lerctr.org cat - \> $FN > done > > =C2=A0 > > How will I know a "Problem" dataset? You told a scrub is panicing the system. A scrub only touches occupied=20= =20 blocks.=20As such a problem-dataset should panic your system. If it=20=20 doesn't=20panic at all, the problem may be within a snapshot which=20=20 contains=20data which is deleted in later versions of the dataset. Bye, Alexander. --=20 http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_IsRE-cZPUR6cZuTgtb5REjG Content-Type: text/html; charset=utf-8 Content-Description: HTML-Nachricht Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Quoting Larry Rosenman <ler@lerctr.= org> (from Fri, 25 Feb 2022 20:03:51 -0600):

On 02/25/2022 2:11 am, Alexander Leidinger wrote:

Quoting Larry Rosenman <ler@lerctr.org> (from Thu, 24 Feb 2022 20:19:45 -0600):

I tried a scrub -- it panic'd on a fatal double fault. 

Suggestions?

The safest / cleanest (but not fastest) is data export and pool re-creat= ion. If you export dataset by dataset (instead of recursively all), you can= even see which dataset is causing the issue. In case this per dataset expo= rt narrows down the issue and it is a dataset you don't care about (as in: = 1) no issue to recreate from scratch or 2) there is a backup available) you= could delete this (or each such) dataset and re-create it in-place (=3D no= t re-creating the entire pool).

Bye,
Alexander.

http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2= 772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F3183= 0F9F2772BF

I'm running this script:
#!/bin/sh
for i in $(zfs list -H | awk '{print $1}')
do
  FS=3D$1
  FN=3D$(echo ${FS} | sed -e s@/@_@g)
  sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh ler@freenas.lerctr.org= cat - \> $FN
done

 

How will I know a "Problem" dataset?

You told a scrub is panicing the system. A scrub only touches occupied b= locks. As such a problem-dataset should panic your system. If it doesn't pa= nic at all, the problem may be within a snapshot which contains data which = is deleted in later versions of the dataset.

Bye,
Alexander.

--=_IsRE-cZPUR6cZuTgtb5REjG-- --=_6wtqejNbDh9PhdsKDTzVZom Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmIaUbIACgkQEg2wmwP4 2IbSuA//T121fzZQ8X/pGxkBSDRqBU95Nq4ZSSxw/9jMCLLN97smAYD/YTeer4W3 uzk1nEIfP3Mvq5fVoBlE3S2K/lWPP9sE4n2MmSzQJmlZO/P9VkW+FhFn2aEAjDlm SzRjnOd2qgqdGVAuJKqAfcVudJaqKqC/W/8+4taE+/o2EhbwY3j0fr+kSvp6hjRr WnKMLpMaVOnSOEZ3BOdhilXssDZ8/hEuCrQV8mpAEHDeJz/taTI+Vqi+0nxOQ+zl P3gfgmBQZwiKtzT3lemS8fNeS7ktSsSGaXzPAc9uAfFJacQuIR+/jzE/FMwQOa9H eZxc/QwkgHZMhY5uz61zPTvU2kM/184wqJ6wsQlK13rw80SjaY+3voaDD7+L9oWz 7THTjMlRzgZEzV90bdhTbFzMa/UmwbAeVsZJmM70p5mAOUJn1fRDqehzEZ4FqFQk nLqgD+B8rjf5kVJYl/0/24JOvfx4TZxUgAgTI2mWRetVxT+zvk6IjyUJnqSCnXri 7mUp/6Knu98AJU2gQUAygQcIFlpkD7fczKCicWEGIDFYQm4Erecks5b+QwMQFLJh bkRFFCnsy/Lw6oX8T59l7DQ7oxl2Av1/rZb43G7JjB+AZFvSgge+3yM/aYHvbxrz Xzmo6tsNgjgwJPUzWVvRSZVxOR3dUp6i2cmRGbz+/zfp2QHZksI= =wrbT -----END PGP SIGNATURE----- --=_6wtqejNbDh9PhdsKDTzVZom-- From nobody Sat Feb 26 16:42:39 2022 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 3E31719D0E25 for ; Sat, 26 Feb 2022 16:43:12 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) (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 4K5XWg3156z3Qqq for ; Sat, 26 Feb 2022 16:43:11 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from excmbx-03.um.gwdg.de ([134.76.9.218] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1nO09v-000UqY-VX; Sat, 26 Feb 2022 17:43:03 +0100 Received: from [192.168.2.104] (10.250.9.199) by EXCMBX-03.um.gwdg.de (134.76.9.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.2375.18; Sat, 26 Feb 2022 17:43:03 +0100 Message-ID: <2ac89863-c9b1-6572-d44c-317b5e839e44@gwdg.de> Date: Sat, 26 Feb 2022 17:42:39 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: Build faulure of editors/libreoffice only on src main (stable/13 is OK) Content-Language: en-US To: Tomoaki AOKI CC: "freebsd-current@freebsd.org" References: <20220226210412.f3599f415923a0b369c248bb@dec.sakura.ne.jp> <20220226221408.6717d4517fdafe15dfad2f20@dec.sakura.ne.jp> Reply-To: Rainer Hurling From: Rainer Hurling In-Reply-To: <20220226221408.6717d4517fdafe15dfad2f20@dec.sakura.ne.jp> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: excmbx-16.um.gwdg.de (134.76.9.227) To EXCMBX-03.um.gwdg.de (134.76.9.218) X-Virus-Scanned: (clean) by clamav X-Rspamd-Queue-Id: 4K5XWg3156z3Qqq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rhurlin@gwdg.de designates 134.76.10.18 as permitted sender) smtp.mailfrom=rhurlin@gwdg.de X-Spamd-Result: default: False [-2.49 / 15.00]; HAS_REPLYTO(0.00)[rhurlin@FreeBSD.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23]; REPLYTO_DN_EQ_FROM_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[134.76.10.18:from]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:134.76.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[rhurlin]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.01)[0.007]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; DMARC_NA(0.00)[gwdg.de]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current] X-ThisMailContainsUnwantedMimeParts: N Am 26.02.22 um 14:14 schrieb Tomoaki AOKI: > Thanks. > But unfortunately, as I've described at Comment 21 [2] of Bug 262008, > setting kern.elf64.aslr.enable=0 didn't help. > As I'm building on amd64 and not built for compat32, I've not touched > kern.elf32.aslr.enable. > And as these are regular writable sysctl (and also are tunables, too), > setting these in /boot/loader.conf and reboot before build is not > tested. I just tried building _after a reboot_ whith kern.elf64.aslr.enable=0 on recent CURRENT and it doesn't work for me. 14.0-CURRENT #0 main-n253393-2bfdc1ee9b1 amd64 Best wishes, Rainer > Should I set more sysctl's? I thought setting above actually disable > all aslr related features (for 64bit), regardless its 1 ro 0. > > Error messages (with "MAKE_JOBS_UNSAFE=yes") and backtraces are > described at Comment 20 [3]. > > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008#c21 > > [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008#c20 > > > On Sat, 26 Feb 2022 13:29:26 +0100 > Michael Gmelin wrote: > >> Maybe it’s related to ASLR? (or is it also enabled in 13/stable?) >> >>> On 26. Feb 2022, at 13:05, Tomoaki AOKI wrote: >>> >>> 〓(Re-sent as not yet delivered in more than 5 hours) >>> >>> Hi. >>> >>> I have a build failure of editors/libreoffice on src main, amd64. >>> As I've reported on Bug 262008 [1], problems on stable/13 is already >>> fixed, but still fails on main with different faulure mode. >>> >>> A tool gengal.bin, built within whole libreoffice build, coredumps but >>> it went OK on stable/13. >>> >>> Port options are now default on both main and stable/13. >>> >>> I now come to suspect the differences about toolchains within main and >>> stable/13, but as editors/libreoffivce is giant and this failure >>> happenes almost at the end of build, usual bisecting is not realistic. >>> (Would require tens of weekends, maybe.) >>> >>> Any thoughts? Or am I missing something to check for? >>> >>> Regards. >>> >>> >>> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008 >>> >>> -- >>> Tomoaki AOKI >> >> > > From nobody Sat Feb 26 16:57:55 2022 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 8C25B19D4749 for ; Sat, 26 Feb 2022 16:58:20 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K5Xs73x5yz3jbT; Sat, 26 Feb 2022 16:58:19 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=caCGaXj1hvdz9kB1j69fmCbtNdRKLdsB2EXm2jFB2hE=; b=p5egD5Pzi/VPlsUtFN00/2A+FR 6+rZq8OkrX0X8dORV8Tfl87ffZhvtvNtOwg6720NFln/zk6TKfQIJq+zj4VVQ/ceHvpgNfqcrFc6n gfIhF1vmPz2qzhY9/wxVSitI1y26jgv9bWSjbxOG3jT+Qdzuju9THs9v4jBHjwryyu6r7LXcnSsg8 og/sNC1TuY3ftU6wA65RxY3zKvrHSYnrEcOlmtRrmpAP3tgC4ZjlcXoGMP4UDKFWI+P5yeDMMZNqk +RtN8AaCB95dEEVjZ00mVDCLT5tHdTOhMm1myxGQ7sI7RwFfrh7p2BZv3Z/ruvzPbjt9jLU4VeowZ 2D/qnROA==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:25396 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nO0OJ-000NBY-H4; Sat, 26 Feb 2022 10:57:55 -0600 Received: from 2600:1700:210:b18f:ce5:6450:39a1:bac by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sat, 26 Feb 2022 10:57:55 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Sat, 26 Feb 2022 10:57:55 -0600 From: Larry Rosenman To: Juraj Lutter Cc: Alexander Leidinger , Rob Wing , Alexander Motin , Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: <04CB94C0-93FE-402B-A24E-1BDAC0D87C5D@lutter.sk> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> <04CB94C0-93FE-402B-A24E-1BDAC0D87C5D@lutter.sk> Message-ID: <8df623691922973b5e9b8609d78c4cfa@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K5Xs73x5yz3jbT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=p5egD5Pz; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-1.29 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; NEURAL_HAM_SHORT(-0.99)[-0.993]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_CC(0.00)[leidinger.net,gmail.com,freebsd.org]; SUSPICIOUS_RECIPS(1.50)[] X-ThisMailContainsUnwantedMimeParts: N On 02/26/2022 10:37 am, Juraj Lutter wrote: >> On 26 Feb 2022, at 03:03, Larry Rosenman wrote: >> I'm running this script: >> #!/bin/sh >> for i in $(zfs list -H | awk '{print $1}') >> do >> FS=$1 >> FN=$(echo ${FS} | sed -e s@/@_@g) >> sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh ler@freenas.lerctr.org >> cat - \> $FN >> done >> >> >> > I’d put, like: > > echo ${FS} > > before “sudo zfs sendâ€, to get at least a bit of a clue on where it can > get to. > > otis > > > — > Juraj Lutter > otis@FreeBSD.org I just looked at the destination to see where it died (it did!) and I bectl destroy'd the BE that crashed it, and am running a new scrub -- we'll see whether that was sufficient. Thanks, all! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Sat Feb 26 17:08:43 2022 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 1204C19D7756 for ; Sat, 26 Feb 2022 17:08:48 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K5Y5C3bsZz3lcY; Sat, 26 Feb 2022 17:08:47 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=EXPoW6KV5lulC4/naFwd1Q1CQr3hZlAjlzSdaAenRj4=; b=Az+ILLQ4BNslMgB1SX0We4/BOw cLnJz2tTR/QNvLJ7yHv0Xu/ExEXdMJBmIJruawah1lpDkVb8iR450sSIAAAf0Sok97FJ6pZGTvcBJ gWGRDO/fP6+fimbpAMsDb/cbUyHj3fLQPaRa537v6fwPeRxv+5v+mI9ugS9gqmEAtdY4lZVPAYVQE KvZJcrTsfmduwlEqW5IJhiBJxZWodqas16tZwU1UPflJnJLYfQGaHNAvpRtW1HFCll1/rTokFNenH yUZDVVZ++Sj3ngM38f1DCdcyeaO1S4Qe45pdzjvnjNRckZLed/8g3dgqH5aKIExOyeddDL7VmW5Uu nTAsM98A==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:38794 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nO0Yl-000NPM-Im; Sat, 26 Feb 2022 11:08:43 -0600 Received: from 2600:1700:210:b18f:ce5:6450:39a1:bac by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sat, 26 Feb 2022 11:08:43 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Sat, 26 Feb 2022 11:08:43 -0600 From: Larry Rosenman To: Juraj Lutter Cc: Alexander Leidinger , Rob Wing , Alexander Motin , Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: <8df623691922973b5e9b8609d78c4cfa@lerctr.org> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> <04CB94C0-93FE-402B-A24E-1BDAC0D87C5D@lutter.sk> <8df623691922973b5e9b8609d78c4cfa@lerctr.org> Message-ID: <85057850abd46331c95b9a2f3a0c07d8@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K5Y5C3bsZz3lcY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=Az+ILLQ4; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-1.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_CC(0.00)[leidinger.net,gmail.com,freebsd.org]; SUSPICIOUS_RECIPS(1.50)[] X-ThisMailContainsUnwantedMimeParts: N On 02/26/2022 10:57 am, Larry Rosenman wrote: > On 02/26/2022 10:37 am, Juraj Lutter wrote: >>> On 26 Feb 2022, at 03:03, Larry Rosenman wrote: >>> I'm running this script: >>> #!/bin/sh >>> for i in $(zfs list -H | awk '{print $1}') >>> do >>> FS=$1 >>> FN=$(echo ${FS} | sed -e s@/@_@g) >>> sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh >>> ler@freenas.lerctr.org cat - \> $FN >>> done >>> >>> >>> >> I’d put, like: >> >> echo ${FS} >> >> before “sudo zfs sendâ€, to get at least a bit of a clue on where it >> can get to. >> >> otis >> >> >> — >> Juraj Lutter >> otis@FreeBSD.org > I just looked at the destination to see where it died (it did!) and I > bectl destroy'd the > BE that crashed it, and am running a new scrub -- we'll see whether > that was sufficient. > > Thanks, all! Well, it was NOT sufficient.... More zfs export fun to come :( -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Sun Feb 27 01:10:18 2022 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 A457919E5D3C for ; Sun, 27 Feb 2022 01:10:28 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K5lmz2qKdz3hD8 for ; Sun, 27 Feb 2022 01:10:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1645924220; bh=MBKyCGqWMcLUap9P8FgFz0h0MkA2LkBG7s+nhuHduXI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=h11WPJ9Xfp9IHeJd1NBgCLZ5Tjl1VBxNzx1vGOJEdsUYzjcdJysHK3TwmXH4bGf8xARWnLEnhh937RcjO+cGvvCX9PtwOEHZ4G7RtlYHaqZTh52GmuVbTmx9KThwk2OfEreIeoU2aKTU03SMJELqVxMtzmlEim84IkvsTlgR4bnGLG2bzRVJ2qwjyzlWaP2/XP4hz4V8MraI/hkRDPTYBECW3KKfTrIYuEU3sFndLRGIDj/MvxiEjljCMEtzM1Oh0WEL/7OjSbJ93meQGyQ9PfRLQF7y0GRXePfQXNRIFfyT66EogoSvClDrKgqcSfxGcsndGmPg5H0fOafIs5nxFg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1645924220; bh=f7+oZdRmNuYvEPs2vJpglJ57ksWMl0ecn1eQOZ+38kM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=j6fL9GXe5ynr8gz/TdZe2KTwO7LQ8LEkD5Xb+RjsBk0odwP6jaWARbPbe1OqIlT+1eoLArg+jDRS0DkN1JvmRjBfOX+9MnXcogTVIy07ubHKYsB+dHIedl+ghGR0pj/zG10fF4tOEhSlPcKL/N/BDVskxxkD/9IlQuy5FzkDsgD4/7hAuekQ81MbU9I92j+65Qnkwk6O/EElOskzf+czwoputuC1a0Y5ywN6RAPIFF7QqbxwW8cNMDfWi7GcL9/c889Bt52p2b4Fq4IgTCodiIiTdW6QYEKxjQfisH+oFr6PqSMZUosCaNXKfG8EMdnK5ZDBgdIS4bzL9C3OADpXlA== X-YMail-OSG: YVOmL_kVM1lWENDiQuUIkrSt60W6kNnFO74JiiKZVvJec5OzoN2716C4KpHu3OI 0r5xdmL6JkmsZVtSpI7EWvCh7aNUZFawMhbhfjfNma7OualHVnuxBYjF3OoTyQNQ0gy.MUAv2Kum uOR_RpRAUyyt2BfTWprVv1i.GmQZM9QYBwIiXrn8VWpeDWWm1fFCqiRdTPyzghQxN3fXmD4NePbL bOXoFbODyQgbzVK099Ocn1gazmX8FXCwYWboIZZfAjLi3MzNYA0JQ7nCS78pmLmOzHzIJS9k1mUU y5yH_AUigp42x77QK3ouAaen2SCao5udfgM.9hjhkWPr2JgFmrkZKRCMAJF7UPHP70aRSwPMqF_8 t2IHLT185B2Bqd48gmXNDEunRNDcrZtHCSwrex_F1jzkE2H5nnSBtNENOoFem_PSdR_gIXy0NpMQ sRbXimjWALIn1kwAx6RsvN00nt5MURl2ReAJfDVMPfGII6hD1nkNR5zylTxCD9_msAixx6pdqNYb af6ttovm7HqF.kaFKCunIX5a63tOMS8VtpwiocZRnMcybcLOytPbsEaSwjFea1u7KJ7QRESLcZIz eYNDP8brRqznNMOr8r6dGNJhFrDzf8iIessdQ2F1zAbYwknLIhZlL.WBf4tT4YS.b.2KqUa35kzd pyAqera7zl87POSFyH4unkIUEaYkRGMj8sT1SUc7DM1oJCe_B5NUpFMyyC4SKfrud4qvA.bGjG2i aadS4bGQVZsA4irZps5gBYKrcz1jiOvYOjF_0tJwqxRuSC67dLojUGY_iSmauyOpzFF5T2uo3oz2 CirVj2fjzmgBlsdBPz_V16Ux49wbFcl0FEtU522_ai2KYGtDEPME4J1NzujSME7aQZUhLwIYRcRo LBWNtsiJX_sSx8EJLgDIM.0EVCI6ErT2sOdej_AW6st0wYmT9WUbZKbcfhBHI8vazHcmcNSbvWO1 OJyhHi_llKJiA8u6GlMk98lSbxVBpvddt97xEQWbNZXMoZsrTBg3vt0yar7tx3IRB7jvGEwyhcK. bejE_OVOSqA8vGftF9886rY7kgw3L5KbLRLqBYjLEVTQo2KoyySbAAJmixr7U.Q4WUawqoUwfW7I CrquR08epQpvINfVMpwtq3ogZfaaTsMU2b6j_7bSekyWxykeU7II1wetSBpOPoVrXRT9o9hS8SHP 0qNMxyWSHk0eUSYO2zr9hxnx3cmxFn0E4prTtJef0yzS3I8oBIBfF1luhD432p3PmpQ0sFXTfx7k K8VeHyWeIlndQ8Frg9_h.D7uX41eWhG.6ysg4abm4rlakI5Vv2ryMHUBAtanCpPYbYUUxCnsESWd SZs3vOPMNxZd.KP3u_NWVPJFo_Bfcmaj2WzMfRx75RgJH100LyL07HoZpisDa0ZFo3GfRmlbNZLp nuTEzuOLUrN4GdkwvlI1P2Lxl94YC6rtNkIqv_Dedl83dJb7fuLK3zYY3DG2Dj_a_t_06uGJSo1A Sw73apY_gKLEZG..lOrmlCCkKmB79MTGOnw1UsjHp5BzClD0DH2HLemq1CqbJq9hI3FZgI4d.Ua6 16Cw9fXrO.nTbJKB95RRcxfdglCFVJcgT0jv3N_ncDgtvagnxHsTQyDEteq5VvPDJT.ZZ9uYWHCL d4Ggrf.8iLO7BEOvshbUzJpuPt14SeWmi2sQITM0EIa2hnt3IdBW8yDmJyJJutf33CTXgjFOO4MQ 4IcTMf0LdOsfQmj3wyc3CPGnqkwBs.62h7stGp_XHXUHY6m.f6peatH9khShVQGvT1lIB7VO4nht 3S7bJlcvvogOO9GEIpkprOrUEIfzYJinpcEcnGQLWxNHymP4.7AxCTXT7zh5rjYiyDG67AnPL8kB mgiGovb6CzKXnJ0kTk66ln8bxjY1N2IkZmSybJlwOIDhjM8Km1fx81GUyL9q.nmz7fwXebYQdIKg 5_Xgm7br3y6Dj_Ad8byOOxzlHiFBBqFZh..m7tZJzHV1HNa0runiE7eO8Dwx_3UUL.ZTpmIE.q4l eGiz.JXuwYjnOPmT8YWf_MeYoYQB09D.Ct0Tg3mAGyiTviKhg3egiHfq4fz2j7MCsn_bXiQ9XzxE w3fgop0XBhDBuRUU3vAj5MGMLCuIc1imEzABHjmmUqmOE_u3kL011kgbzMVL4fhELupnrV_7t.xx 1yzuz499JBcLa9PfVntcb6vYxbkILLEK_iUqSHk5Cv.HA7W4Crw0ypfj2oc8YClZKn91jj4L7KGQ c_eMjvcXivGitFY3dPxIglpiAOfuUBnnyCCQK4vO6K5TQUy4Cih70YR8LdaHZXNPVoUDY5qvrCBX mo_QV.qEK70OUhe5pZI5f X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 27 Feb 2022 01:10:20 +0000 Received: by kubenode512.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 13e13fc81b224f28691ca119b921ae9f; Sun, 27 Feb 2022 01:10:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 4a864f624a70 - main - vm_pageout: Print a more accurate message to the console before an OOM kill [MFC in time for 13.1?] From: Mark Millard In-Reply-To: Date: Sat, 26 Feb 2022 17:10:18 -0800 Cc: freebsd-current , dev-commits-src-main@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1EF55D96-F7E3-4AA6-A331-782362A70878.ref@yahoo.com> <1EF55D96-F7E3-4AA6-A331-782362A70878@yahoo.com> To: Mark Johnston , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4K5lmz2qKdz3hD8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=h11WPJ9X; 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 X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-15, at 07:55, Mark Johnston wrote: > On Fri, Jan 14, 2022 at 09:38:56PM -0800, Mark Millard wrote: >> Thanks. This will allow me to remove part of my personal additions >> in this area --and my having to explain the misnomer when trying >> to help someone analyze why they end up with OOM activity so they >> can figure out what to do about it. >>=20 >> There seem to be two separate sources of VM_OOM_SWAPZ. Showing >> my personal additions for them (just making them explicit in the >> sequence of messages generated): >>=20 >> diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c >> index 01cf9233329f..280621ca51be 100644 >> --- a/sys/vm/swap_pager.c >> +++ b/sys/vm/swap_pager.c >> @@ -2091,6 +2091,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) >> 0, 1)) >> printf("swap blk zone = exhausted, " >> "increase = kern.maxswzone\n"); >> + printf("swp_pager_meta_build: swap = blk uma zone exhausted\n"); >> vm_pageout_oom(VM_OOM_SWAPZ); >> pause("swzonxb", 10); >> } else >> @@ -2121,6 +2122,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) >> 0, 1)) >> printf("swap pctrie zone = exhausted, " >> "increase = kern.maxswzone\n"); >> + printf("swp_pager_meta_build: swap = pctrie uma zone exhausted\n"); >> vm_pageout_oom(VM_OOM_SWAPZ); >> pause("swzonxp", 10); >> } else >>=20 >> Care to comment on the distinctions and why there are two >> contexts classified as "out of swap space"? Would either >> one show the swap space as (nearly?) all used in, say, top? >> Or might one of them still end up looking like a misnomer >> from just a top (or whatever) display? >=20 > Hmm, those cases should likely be changed from "out of swap space" to > "failed to allocate swap metadata" or something like that. The above does not seem to have happened yet in main [so: 14]. Will 13.1 get an MFC of 4a864f624a70 in time, possibly with the above change also in place to fully avoid misnomer reporting that misleads folks? 4a864f624a70 listed: MFC after: 2 weeks but it has been more than a month. > . . . >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Feb 27 19:16:44 2022 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 F283C19E2754 for ; Sun, 27 Feb 2022 19:17:14 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6Cty0D9Mz3lnk; Sun, 27 Feb 2022 19:17:14 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=DCyFqoIGFRGOIm6BpHzqGJEYMBVPSnhqEcChFKe37Gk=; b=ggNF9KU8xEeuMY/6hQsBbcpy0g OahtRkDhlorC6IRY9gyuLt6ae+eO6dQUePFPiEptZNX+Kzzs9TUDv67nXIybPMhpkvuoiNO4KqUWH 8+/nH4EywxnHmaqHcrCN+tDyqMY7CVo7twPvPXgkhv3Bgbz84WfutVUn1eZO5JnPjvWy3YhgP7Prv yjqKaOPLulmZBmkd9aaMNTaGY4gkzi1Ui6f6gMHNI9o9E/NM3apHIb4gsBAqTTUo4R5+8T6imXM/5 ANUlMdiynXHi8TkN+7tn5A+Hfska1ZnEvFNrrae8+2NKejxhPXpVRcnsjzxD7WlXn8AMjS4qnklBN Wc1QlAwQ==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:12467 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nOP2D-000HX3-1k; Sun, 27 Feb 2022 13:16:45 -0600 Received: from 2600:1700:210:b18f:148c:fa9b:bdf:1b29 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sun, 27 Feb 2022 13:16:44 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Sun, 27 Feb 2022 13:16:44 -0600 From: Larry Rosenman To: Juraj Lutter Cc: Alexander Leidinger , Rob Wing , Alexander Motin , Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: <85057850abd46331c95b9a2f3a0c07d8@lerctr.org> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> <04CB94C0-93FE-402B-A24E-1BDAC0D87C5D@lutter.sk> <8df623691922973b5e9b8609d78c4cfa@lerctr.org> <85057850abd46331c95b9a2f3a0c07d8@lerctr.org> Message-ID: <740a16472bb1073174efa709f795896c@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K6Cty0D9Mz3lnk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=ggNF9KU8; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-1.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_CC(0.00)[leidinger.net,gmail.com,freebsd.org]; SUSPICIOUS_RECIPS(1.50)[] X-ThisMailContainsUnwantedMimeParts: N On 02/26/2022 11:08 am, Larry Rosenman wrote: > On 02/26/2022 10:57 am, Larry Rosenman wrote: >> On 02/26/2022 10:37 am, Juraj Lutter wrote: >>>> On 26 Feb 2022, at 03:03, Larry Rosenman wrote: >>>> I'm running this script: >>>> #!/bin/sh >>>> for i in $(zfs list -H | awk '{print $1}') >>>> do >>>> FS=$1 >>>> FN=$(echo ${FS} | sed -e s@/@_@g) >>>> sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh >>>> ler@freenas.lerctr.org cat - \> $FN >>>> done >>>> >>>> >>>> >>> I’d put, like: >>> >>> echo ${FS} >>> >>> before “sudo zfs sendâ€, to get at least a bit of a clue on where it >>> can get to. >>> >>> otis >>> >>> >>> — >>> Juraj Lutter >>> otis@FreeBSD.org >> I just looked at the destination to see where it died (it did!) and I >> bectl destroy'd the >> BE that crashed it, and am running a new scrub -- we'll see whether >> that was sufficient. >> >> Thanks, all! > Well, it was NOT sufficient.... More zfs export fun to come :( I was able to export the rest of the datasets, and re-install 14-CURRENT from a recent snapshot, and restore the datasets I care about. I'm now seeing: mfi0: IOCTL 0x40086481 not handled mfi0: IOCTL 0x40086481 not handled mfi0: IOCTL 0x40086481 not handled mfi0: IOCTL 0x40086481 not handled pid 48 (zpool), jid 0, uid 0: exited on signal 6 mfi0: IOCTL 0x40086481 not handled mfi0: IOCTL 0x40086481 not handled mfi0: IOCTL 0x40086481 not handled mfi0: IOCTL 0x40086481 not handled pid 54 (zpool), jid 0, uid 0: exited on signal 6 On boot. Ideas? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Sun Feb 27 21:03:56 2022 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 9F8E519DBF58 for ; Sun, 27 Feb 2022 21:04:05 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6GGD2V27z4Zy5 for ; Sun, 27 Feb 2022 21:04:04 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1645995836; bh=+iBSHteK/7AGXm+HEN5I9rqUXFSXKvtpPBBu CV+M+6Q=; b=Q4Qljk99KYqJTubAvU3pj9H4fRKFXbZoPr6zuxw/BQzpCkp/1Fna aU/yrLebfvZTfA1L8mf2N9Adxn6vmSos1UHg80wUoKKg90b86mM7Y50t9bfYZ2RF bk5HfBWlOzBtG6v3aOjSaVgCGvInyYlXL4Qgmu6TNSRocnyTMxaB9U8= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id CB5014D4FC; Sun, 27 Feb 2022 16:03:56 -0500 (EST) Message-ID: <43c376af-4f59-0ef0-dfd5-cabde7fa2427@protected-networks.net> Date: Sun, 27 Feb 2022 16:03:56 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: ZFS PANIC: HELP. Content-Language: en-NZ To: Larry Rosenman Cc: Freebsd current References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> <04CB94C0-93FE-402B-A24E-1BDAC0D87C5D@lutter.sk> <8df623691922973b5e9b8609d78c4cfa@lerctr.org> <85057850abd46331c95b9a2f3a0c07d8@lerctr.org> <740a16472bb1073174efa709f795896c@lerctr.org> From: Michael Butler In-Reply-To: <740a16472bb1073174efa709f795896c@lerctr.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K6GGD2V27z4Zy5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=Q4Qljk99; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-1.79 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.01)[0.007]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N [ cc list trimmed ] On 2/27/22 14:16, Larry Rosenman wrote: > > I was able to export the rest of the datasets, and re-install 14-CURRENT > from a recent snapshot, and restore the datasets I care about. > > I'm now seeing: > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > pid 48 (zpool), jid 0, uid 0: exited on signal 6 > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > pid 54 (zpool), jid 0, uid 0: exited on signal 6 > > On boot.  Ideas? These messages may or may not be related. I found both the mfi and mrsas drivers to be 'chatty' in this way - IOCTL complaints. I ended up setting the debug flag for mrsas in /etc/sysctl.conf .. dev.mrsas.0.mrsas_debug=0 There's an equivalent for mfi Michael From nobody Sun Feb 27 21:09:20 2022 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 CF82E19DD94E for ; Sun, 27 Feb 2022 21:09:22 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6GNK62Ffz4f8M for ; Sun, 27 Feb 2022 21:09:21 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=biV1sAwPR4a/R/rk7+aeMoEAODc1czs4xbWscc6opWM=; b=MTa8tNYLqlKB4lxquDZ9t73PeO ChI2T9B60TEgOh7IJOQU5B9QekiHbjGn8OiUiNdwFla5f+5iPV5PiJcIa2dyP/ipFVEDzB2entSWb AHLcrsNUJT4qtAxV5rAe8ZZeXOgGfj6i/+tkNQ6ik9ctNwXMsPSaRIWX7WuLvVpQQrfR7KYxgQPnc ez+9Ko9rYVKk0IMQ1lwfRT7p0RCEf0H6udW+1H1d40eAToBxe9s5KLFOco9s/dLjk32/NHkFxfHPX HVUv4t0fEpyC8XNKbNZXY6HnOMimmOeT8XNvx7EirGlRWKgSqs0gpxaoZoUE2PcvCiwlbOyjyt1jJ S5ciL03g==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:35038 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nOQnA-000JEd-CE; Sun, 27 Feb 2022 15:09:20 -0600 Received: from 2600:1700:210:b18f:148c:fa9b:bdf:1b29 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sun, 27 Feb 2022 15:09:20 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Sun, 27 Feb 2022 15:09:20 -0600 From: Larry Rosenman To: Michael Butler Cc: Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: <43c376af-4f59-0ef0-dfd5-cabde7fa2427@protected-networks.net> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> <04CB94C0-93FE-402B-A24E-1BDAC0D87C5D@lutter.sk> <8df623691922973b5e9b8609d78c4cfa@lerctr.org> <85057850abd46331c95b9a2f3a0c07d8@lerctr.org> <740a16472bb1073174efa709f795896c@lerctr.org> <43c376af-4f59-0ef0-dfd5-cabde7fa2427@protected-networks.net> Message-ID: <18adb6fed40e5ae7f611e12dc027fb4e@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K6GNK62Ffz4f8M X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=MTa8tNYL; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.78 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-0.99)[-0.989]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02/27/2022 3:03 pm, Michael Butler wrote: > [ cc list trimmed ] > > On 2/27/22 14:16, Larry Rosenman wrote: >> >> I was able to export the rest of the datasets, and re-install >> 14-CURRENT from a recent snapshot, and restore the datasets I care >> about. >> >> I'm now seeing: >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> pid 48 (zpool), jid 0, uid 0: exited on signal 6 >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> pid 54 (zpool), jid 0, uid 0: exited on signal 6 >> >> On boot.  Ideas? > > These messages may or may not be related. I found both the mfi and > mrsas drivers to be 'chatty' in this way - IOCTL complaints. I ended > up setting the debug flag for mrsas in /etc/sysctl.conf .. > > dev.mrsas.0.mrsas_debug=0 > > There's an equivalent for mfi > > Michael I don't see it: ✖1 ⯠sysctl dev.mfi dev.mfi.0.keep_deleted_volumes: 0 dev.mfi.0.delete_busy_volumes: 0 dev.mfi.0.%parent: pci3 dev.mfi.0.%pnpinfo: vendor=0x1000 device=0x0079 subvendor=0x1028 subdevice=0x1f17 class=0x010400 dev.mfi.0.%location: slot=0 function=0 dbsf=pci0:3:0:0 dev.mfi.0.%driver: mfi dev.mfi.0.%desc: Dell PERC H700 Integrated dev.mfi.%parent: -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Sun Feb 27 21:19:43 2022 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 9E05E19E20DA for ; Sun, 27 Feb 2022 21:19:44 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6GcJ0l25z4jZ6 for ; Sun, 27 Feb 2022 21:19:44 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1645996783; bh=AL22ojb0XUm45HxjBDo/vWzHNhRmC06VEBCj AOm8Pv4=; b=ocysfmtAGKUBWxObUOuHAxkflF4F4O2dfz3j1x2U1KSC7hz+XFwY /3o6sKwRobXyjrD1J9O4gPJkAFfAE8t53JBOKHxXXoYxK2onkbp+6sdZK3JL9IiT gRU7wCUL+EcwZ3FO1Lk4rcElF2oPR8PlmllpN34D/lVT5bvFtId8CSg= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 4B5504DE05; Sun, 27 Feb 2022 16:19:43 -0500 (EST) Message-ID: <10355a05-e41f-f20e-04b0-10b44ffeef09@protected-networks.net> Date: Sun, 27 Feb 2022 16:19:43 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: ZFS PANIC: HELP. Content-Language: en-NZ To: Larry Rosenman Cc: Freebsd current References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> <04CB94C0-93FE-402B-A24E-1BDAC0D87C5D@lutter.sk> <8df623691922973b5e9b8609d78c4cfa@lerctr.org> <85057850abd46331c95b9a2f3a0c07d8@lerctr.org> <740a16472bb1073174efa709f795896c@lerctr.org> <43c376af-4f59-0ef0-dfd5-cabde7fa2427@protected-networks.net> <18adb6fed40e5ae7f611e12dc027fb4e@lerctr.org> From: Michael Butler In-Reply-To: <18adb6fed40e5ae7f611e12dc027fb4e@lerctr.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K6GcJ0l25z4jZ6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=ocysfmtA; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-1.82 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.02)[-0.022]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2/27/22 16:09, Larry Rosenman wrote: > On 02/27/2022 3:03 pm, Michael Butler wrote: >> [ cc list trimmed ] >> >> On 2/27/22 14:16, Larry Rosenman wrote: >>> >>> I was able to export the rest of the datasets, and re-install >>> 14-CURRENT from a recent snapshot, and restore the datasets I care >>> about. >>> >>> I'm now seeing: >>> mfi0: IOCTL 0x40086481 not handled >>> mfi0: IOCTL 0x40086481 not handled >>> mfi0: IOCTL 0x40086481 not handled >>> mfi0: IOCTL 0x40086481 not handled >>> pid 48 (zpool), jid 0, uid 0: exited on signal 6 >>> mfi0: IOCTL 0x40086481 not handled >>> mfi0: IOCTL 0x40086481 not handled >>> mfi0: IOCTL 0x40086481 not handled >>> mfi0: IOCTL 0x40086481 not handled >>> pid 54 (zpool), jid 0, uid 0: exited on signal 6 >>> >>> On boot.  Ideas? >> >> These messages may or may not be related. I found both the mfi and >> mrsas drivers to be 'chatty' in this way - IOCTL complaints. I ended >> up setting the debug flag for mrsas in /etc/sysctl.conf .. >> >> dev.mrsas.0.mrsas_debug=0 >> >> There's an equivalent for mfi >> >>     Michael > > I don't see it: > ✖1 ⯠sysctl dev.mfi > dev.mfi.0.keep_deleted_volumes: 0 > dev.mfi.0.delete_busy_volumes: 0 > dev.mfi.0.%parent: pci3 > dev.mfi.0.%pnpinfo: vendor=0x1000 device=0x0079 subvendor=0x1028 > subdevice=0x1f17 class=0x010400 > dev.mfi.0.%location: slot=0 function=0 dbsf=pci0:3:0:0 > dev.mfi.0.%driver: mfi > dev.mfi.0.%desc: Dell PERC H700 Integrated > dev.mfi.%parent: my brain-fade - you're right; it is only there and tunable in the mrsas driver. My apologies :-( Michael From nobody Sun Feb 27 21:36:13 2022 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 145A719E579E for ; Sun, 27 Feb 2022 21:36:31 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6Gzf32tcz4m2l for ; Sun, 27 Feb 2022 21:36:30 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x136.google.com with SMTP id i1so8633279ila.7 for ; Sun, 27 Feb 2022 13:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=CXGL/XPZSyeSGj7dj/dd+uTIjpQ0JfcxDyFvhUcRoes=; b=aNpLJ5DBHbfACRVc8nWMWaqJPcb57O/x9tZlfXKCWp6kbDykIuVgpTF6e68wSAGXZ8 Sh0KVjBWsw8P3F++whN/lQJtXtPEGEGJfj0xfmedvRmY5hKM6ohilFuxiEg4prdpP5+Q cxr2usuxIZLAVvG9MWeulgi5bvKcRCg3eDZCI/BOUlFFKulvHEUB5W/Z7dF2GjG2rcOY HQ/t9WqA2/Kmks7idGG2MCuoc+V0NX+QAZc0lSvLZJQoF2Y/Vk5HD47Md2RDYZsLvg5F +Givf/tNLg8W3YLNWUuOHvuEgJFULfcq+WVBqr0YLfhYriU8oHbArPDBKzOlDQSipWLa GYQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CXGL/XPZSyeSGj7dj/dd+uTIjpQ0JfcxDyFvhUcRoes=; b=WW7O+xoMbwwhXj5HkR+MyQi5lMym2XrjdxWCLoD73Ul2kWKkCePwJtJJ2WFZDNg6bk rlQG+ZngWCP2v5jPKD7bP1ucOaVPGWbWl1WmjyG/DsPgnjl8JrOBGhbJj7fME96uHdGA f90O2RrKKP3CM2k11MGT5BXGk7Dd8zAKoJOm5Ch5iHVg7Hv9oWQiIywSEk3R280UkgHj w3kct+bKYmdg4uDUSZEIfYvqADQbCCAPWsk2iIJ6UFMRSEhxCDhX37GgAyFhB5CF7mIX /hgE4scaSkR456bKPJeh0g/PfH7LFeJKFc/rHea1yqHqh0/0P3hlsGE3EdcKUwBoqt+a gYrA== X-Gm-Message-State: AOAM531Vv1pqfflSL70/QQFl584O9Ty4gaAipiE54iVE8LBJqeG6YjmV UspIQ5mHLnCc6NNtzkzDR48I4Ov+8+7QMy34jBb1SSAUFjoYVQ== X-Google-Smtp-Source: ABdhPJyzBeAzLqOM2rnqNeW8p1kKlpKvzfmNR+pXIN1VVf3fDwFWeZO/kpbgL5ZV/z4BUJdXyF1dtI643mpuDCv37Tw= X-Received: by 2002:a92:cc04:0:b0:2c2:9771:378a with SMTP id s4-20020a92cc04000000b002c29771378amr16079026ilp.63.1645997784312; Sun, 27 Feb 2022 13:36:24 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Michael Schuster Date: Sun, 27 Feb 2022 22:36:13 +0100 Message-ID: Subject: "vidcontrol -i mode" shows no output except header (in search of smaller console font) To: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="0000000000003c2f3505d906b9ec" X-Rspamd-Queue-Id: 4K6Gzf32tcz4m2l X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=aNpLJ5DB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::136 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.02 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.03)[-0.028]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-0.999]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::136:from]; NEURAL_HAM_SHORT(-1.00)[-0.997]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000003c2f3505d906b9ec Content-Type: text/plain; charset="UTF-8" Hi all, I'm trying to get a smaller font in my text-consoles (using vt) on my Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD CURRENT from last week. My research led me to believe that using vidcontrol would help me here, but however I do try, "vidcontrol -i mode" prints nothing except the header line, and other "vidcontrol" subcommands give me "Inappropriate ioctl for device". I tried a few things - switched to sc via setting "kern.vty=sc" in /boot/loader.conf, this caused a hang on reboot - setting "hw.vga.textmode" to 1 - "kldload vesa" ... and probably a few other things I now forget, all to no effect - I still get nothing. I then performed an update from a freshly 'git pulled' source today (kernel, world, drm-devel-kmod), a simple "vidcontrol" test still shows the same. I know it can work because I had a smaller font before I re-installed over the previous installation (which originally came from ghostbsd in Aug 2020), so - I assume - it can't be rocket science :-) I'd appreciate further hints/pointers/RTFMs (though I've tried quite a few of those). TIA Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' --0000000000003c2f3505d906b9ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I'm trying to get a smaller font in my text-conso= les (using vt) on my Ryzen 4700 and Vega10 Renoir - based laptop with a fre= sh install of FreeBSD CURRENT from last week.
=
My research led me to believe that using vidco= ntrol would help me here, but however I do try, "vidcontrol -i mode&qu= ot; prints nothing except the header line, and other "vidcontrol"= subcommands give me "Inappropriate ioctl for device".

I tried= a few things
- switched to sc via setting "ke= rn.vty=3Dsc" in /boot/loader.conf, this caused a hang on reboot
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">- setting "hw.vga.textmode" to 1
- "kldload vesa"
... and probab= ly a few other things I now forget, all to no effect - I still get nothing.=

I then performe= d an update from a freshly 'git pulled' source today (kernel, world= , drm-devel-kmod), a simple "vidcontrol" test still shows the sam= e.

I know it can w= ork because I had a smaller font before I re-installed over the previous in= stallation (which originally came from ghostbsd in Aug 2020), so - I assume= - it can't be rocket science :-)
I'd appre= ciate further hints/pointers/RTFMs (though I've tried quite a few of th= ose).

TIA
Michael
--
recursion, n: see 'recursion'
--0000000000003c2f3505d906b9ec-- From nobody Sun Feb 27 21:54:30 2022 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 C59EE19E9CF1 for ; Sun, 27 Feb 2022 21:54:43 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-ztbu10011701.me.com (pv50p00im-ztbu10011701.me.com [17.58.6.53]) (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 4K6HNg03Xbz4pwG for ; Sun, 27 Feb 2022 21:54:43 +0000 (UTC) (envelope-from tsoome@me.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1645998876; bh=yqrttgqYj9rGFUGlvXY3uckgt20JfAXlrGLpGqnrsa8=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=gbsp+HugW0M0q2/0wWTzupZ8x1q857lbh3n4YTl5pIXJntU/6SJmKRSk9EV0YyEG/ Y95hJKvjkXVTH9GTd736vDfbmqoiBKau7Gwva+sYM7bpIRtPAzQ9+Gy+tvU09Qzzog FEoL8RnP6tS7B3vbWTMZNEQGcNl2q2Ufvna3FB5fXScVtxpiUWbsFm/nYBhZb33UWS ScKrWnN22GtHUO9uk0szGYFXgTKn9gAKfdKECojdvXmT6OZjOanvuZm1NaVyjOAQ2i VtMgmta5A8mPyhFMFhhx3yrcS3lqy6NRSHmDF+6oKL/+Hyoog5jK4fOPqozMPje2yT C91AbK5L/oLcg== Received: from smtpclient.apple (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-ztbu10011701.me.com (Postfix) with ESMTPSA id 7D1CAB4064A; Sun, 27 Feb 2022 21:54:34 +0000 (UTC) From: Toomas Soome Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2E6F6973-124B-48A2-9BEE-D30FA2D48D3F" 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 15.0 \(3693.60.0.1.1\)) Subject: Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font) Date: Sun, 27 Feb 2022 23:54:30 +0200 In-Reply-To: Cc: FreeBSD CURRENT To: Michael Schuster References: X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.816 definitions=2022-02-27_09:2022-02-26,2022-02-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2009150000 definitions=main-2202270149 X-Rspamd-Queue-Id: 4K6HNg03Xbz4pwG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=gbsp+Hug; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.53 as permitted sender) smtp.mailfrom=tsoome@me.com X-Spamd-Result: default: False [-2.71 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[me.com]; ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.53:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.11)[-0.107]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_VERYGOOD(0.00)[17.58.6.53:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_2E6F6973-124B-48A2-9BEE-D30FA2D48D3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 27. Feb 2022, at 23:36, Michael Schuster = wrote: >=20 > Hi all, >=20 > I'm trying to get a smaller font in my text-consoles (using vt) on my = Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of = FreeBSD CURRENT from last week.=20 >=20 > My research led me to believe that using vidcontrol would help me = here, but however I do try, "vidcontrol -i mode" prints nothing except = the header line, and other "vidcontrol" subcommands give me = "Inappropriate ioctl for device". >=20 > I tried a few things > - switched to sc via setting "kern.vty=3Dsc" in /boot/loader.conf, = this caused a hang on reboot > - setting "hw.vga.textmode" to 1 > - "kldload vesa" > ... and probably a few other things I now forget, all to no effect - I = still get nothing. >=20 > I then performed an update from a freshly 'git pulled' source today = (kernel, world, drm-devel-kmod), a simple "vidcontrol" test still shows = the same. >=20 > I know it can work because I had a smaller font before I re-installed = over the previous installation (which originally came from ghostbsd in = Aug 2020), so - I assume - it can't be rocket science :-) > I'd appreciate further hints/pointers/RTFMs (though I've tried quite a = few of those). >=20 UEFI or BIOS setup? With UEFI, sc and hw.vga.textmode has no effect. = With UEFI or BIOS+hw.vga.textmode=3D0, you can set screen.font variable = (empty value will cause the values list to be printed), or use loadfont = command with your custom font file (created with vtfontcvt). rgds, toomas --Apple-Mail=_2E6F6973-124B-48A2-9BEE-D30FA2D48D3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 27. Feb 2022, at 23:36, Michael Schuster <michaelsprivate@gmail.com> wrote:

Hi = all,

I'm = trying to get a smaller font in my text-consoles (using vt) on my Ryzen = 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD = CURRENT from last week.

My = research led me to believe that using vidcontrol would help me here, but = however I do try, "vidcontrol -i mode" prints nothing except the header = line, and other "vidcontrol" subcommands give me "Inappropriate ioctl = for device".

I tried = a few things
- = switched to sc via setting "kern.vty=3Dsc" in /boot/loader.conf, this = caused a hang on reboot
- = setting "hw.vga.textmode" to 1
- = "kldload vesa"
... and = probably a few other things I now forget, all to no effect - I still get = nothing.

I then = performed an update from a freshly 'git pulled' source today (kernel, = world, drm-devel-kmod), a simple "vidcontrol" test still shows the = same.

I know = it can work because I had a smaller font before I re-installed over the = previous installation (which originally came from ghostbsd in Aug 2020), = so - I assume - it can't be rocket science :-)
I'd = appreciate further hints/pointers/RTFMs (though I've tried quite a few = of those).


UEFI = or BIOS setup? With UEFI, sc and hw.vga.textmode has no effect. With = UEFI or BIOS+hw.vga.textmode=3D0, you can set screen.font variable = (empty value will cause the values list to be printed), or use loadfont = command with your custom font file (created with = vtfontcvt).

rgds,
toomas

= --Apple-Mail=_2E6F6973-124B-48A2-9BEE-D30FA2D48D3F-- From nobody Sun Feb 27 21:58:42 2022 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 29EFF19EB344 for ; Sun, 27 Feb 2022 21:58:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6HTR2zDJz4r2X for ; Sun, 27 Feb 2022 21:58:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x733.google.com with SMTP id b20so1657579qkn.9 for ; Sun, 27 Feb 2022 13:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=H24pLG6yq90y19Q9fFGw6AIWM70odFiK0tyYZfphiOk=; b=ZuM0m8GKKl/Lqmv0+RBhk96Gp9zNQQZ0Ozt4iDm5ACWdUm8j2X2FZJTpg7TePl75Su IMR6P1D57cMcV6VKQfHjhEqWzVXRfhTOsZOukxIxZ2d/YYKzf/J+ASgQLoGR4B+1eaFi Q1davYLxPDE+JhcEuzqKGfks0o9SYsmHNVNbRATdki8opSiZ6JBk5s7UBMULuQoi+QxV D0DkqY45FnQ0n2KzN1VPcZuZfqiXm6hmUCeS4mgJ0yj2XDtF6DA7UTs1GisUQYN88aJK 0qloxGlaIHVEHEcIUWksszGML2y+Q4oPGNgGD2tCeLLzc6FozWzsgj5C7TBSTUUa+2ZM pZeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=H24pLG6yq90y19Q9fFGw6AIWM70odFiK0tyYZfphiOk=; b=EWApFw85QK+jvqfKb8FB+mr8NCzetcFH7pH3MNG5ch93ez36wDq1jScPba2hxwmUlq RyklivBMQ+EcZWs6Hmx452Fao8Ph4OPDzUAETYQnut8pQ5F3WkZCJTTXEdGb36jHMo4N IYPtXyWn2ZSnylfZRMJIvzC9qLslwywz19vcmOWtQkx+5nbsEY2XBwVc5w/LnSvhYQzo xf/JCANqcVO3ClflxF2C9h+TLuN1M+2p5XeBkZtxb3BLc+G9V3xJN84yX91dBmW1o0xm GPRpMzbhTuFcs8VTEOL9RkGQ0xp0o+cadttZuZ2mNo3aTA0tsi3QVlPT8BMEMIUr3+2T U3MA== X-Gm-Message-State: AOAM530qJwmiWst8pjxlwvnebMg9cGEVpZH16KS4oD/aLuTvw3jwFFmV ReZafkK4k7SR+WlZ8X2l5q4lj32OC6U= X-Google-Smtp-Source: ABdhPJy7sPGYtoDEafzXPU+0hc6JKmb87ozxRjToqkknjhPIb2Dy5GqUOGVVW/f18h6YVlYUMSHw9g== X-Received: by 2002:a37:27d0:0:b0:4e1:a93:412b with SMTP id n199-20020a3727d0000000b004e10a93412bmr9816758qkn.360.1645999125322; Sun, 27 Feb 2022 13:58:45 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id 141-20020a370393000000b00649498f69dbsm4291727qkd.91.2022.02.27.13.58.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 27 Feb 2022 13:58:44 -0800 (PST) Date: Sun, 27 Feb 2022 16:58:42 -0500 From: Mark Johnston To: Larry Rosenman Cc: Freebsd current Subject: Re: ZFS PANIC: HELP. Message-ID: References: <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> <04CB94C0-93FE-402B-A24E-1BDAC0D87C5D@lutter.sk> <8df623691922973b5e9b8609d78c4cfa@lerctr.org> <85057850abd46331c95b9a2f3a0c07d8@lerctr.org> <740a16472bb1073174efa709f795896c@lerctr.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <740a16472bb1073174efa709f795896c@lerctr.org> X-Rspamd-Queue-Id: 4K6HTR2zDJz4r2X X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZuM0m8GK; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::733 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [0.06 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; SUBJ_ALL_CAPS(1.20)[16]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.97)[-0.972]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.53)[0.527]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::733:from]; MLMMJ_DEST(0.00)[freebsd-current]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Feb 27, 2022 at 01:16:44PM -0600, Larry Rosenman wrote: > On 02/26/2022 11:08 am, Larry Rosenman wrote: > > On 02/26/2022 10:57 am, Larry Rosenman wrote: > >> On 02/26/2022 10:37 am, Juraj Lutter wrote: > >>>> On 26 Feb 2022, at 03:03, Larry Rosenman wrote: > >>>> I'm running this script: > >>>> #!/bin/sh > >>>> for i in $(zfs list -H | awk '{print $1}') > >>>> do > >>>> FS=$1 > >>>> FN=$(echo ${FS} | sed -e s@/@_@g) > >>>> sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh > >>>> ler@freenas.lerctr.org cat - \> $FN > >>>> done > >>>> > >>>> > >>>> > >>> I’d put, like: > >>> > >>> echo ${FS} > >>> > >>> before “sudo zfs sendâ€, to get at least a bit of a clue on where it > >>> can get to. > >>> > >>> otis > >>> > >>> > >>> — > >>> Juraj Lutter > >>> otis@FreeBSD.org > >> I just looked at the destination to see where it died (it did!) and I > >> bectl destroy'd the > >> BE that crashed it, and am running a new scrub -- we'll see whether > >> that was sufficient. > >> > >> Thanks, all! > > Well, it was NOT sufficient.... More zfs export fun to come :( > > I was able to export the rest of the datasets, and re-install 14-CURRENT > from a recent snapshot, and restore the datasets I care about. > > I'm now seeing: > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > pid 48 (zpool), jid 0, uid 0: exited on signal 6 > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > mfi0: IOCTL 0x40086481 not handled > pid 54 (zpool), jid 0, uid 0: exited on signal 6 > > On boot. Ideas? That ioctl is DIOCGMEDIASIZE, i.e., something is asking /dev/mfi0, the controller device node, about the size of a disk. Presumably this is the result of some kind of misconfiguration somewhere, and /dev/mfid0 was meant instead. From nobody Mon Feb 28 00:16:53 2022 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 E098419DC745 for ; Mon, 28 Feb 2022 00:16:55 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6LXl0HFwz57cM; Mon, 28 Feb 2022 00:16:55 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tixOveRqF0vJjItXLlBCa/L+X87u8LqaeaS9Dl1huy0=; b=G7HcT9TVxANOa5I4ule3Kbe+AO LmVvfCah4A9++f6mlXmVNoEIf9MhwF561yljHrMyja+iRIPEUfJ7tei+WcD1DjD5eDFDlCQnoW/+R MUbD50G65VV8kfZ9rHzqCrcW0ow1vb/sBepKs90L7yc8N7iTwFjEqX9D8nR9I5jCNvP/6aO+DM7VT 2q1C+e+rzqkpv+XAc54dCfn6fN2NqHV5ZoDSa+ElIgfzXUtV+280OqB8eGU1YL9Ev864MZxdBY28z /l0tvQc167uIOTawQeODKpb+ZvKmqF9zIKhmVQnu8iFB11optou+XTD38Rx8JHRH73aaVGIO39IG6 kpwDxxiQ==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2001:470:1f0f:3ad:bb:dcff:fe50:d900 as permitted sender) client-ip=2001:470:1f0f:3ad:bb:dcff:fe50:d900; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:56160 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nOTif-000MAK-DU; Sun, 27 Feb 2022 18:16:53 -0600 Received: from 2600:1700:210:b18f:148c:fa9b:bdf:1b29 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sun, 27 Feb 2022 18:16:53 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Sun, 27 Feb 2022 18:16:53 -0600 From: Larry Rosenman To: Mark Johnston Cc: Freebsd current Subject: Re: ZFS PANIC: HELP. In-Reply-To: References: <36d3896af19acc4fdd1712822ba9d420@lerctr.org> <9f6a8ad62fc0dbd6f3a19c7d695bd302@lerctr.org> <20220225091120.Horde.76VjoVNtr5BsqAw_5ftjpRZ@webmail.leidinger.net> <04CB94C0-93FE-402B-A24E-1BDAC0D87C5D@lutter.sk> <8df623691922973b5e9b8609d78c4cfa@lerctr.org> <85057850abd46331c95b9a2f3a0c07d8@lerctr.org> <740a16472bb1073174efa709f795896c@lerctr.org> Message-ID: <20d8b59ddfa82275ac771a50921f9300@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K6LXl0HFwz57cM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=G7HcT9TV; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; SUBJ_ALL_CAPS(1.20)[16]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8166, ipnet:192.147.25.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02/27/2022 3:58 pm, Mark Johnston wrote: > On Sun, Feb 27, 2022 at 01:16:44PM -0600, Larry Rosenman wrote: >> On 02/26/2022 11:08 am, Larry Rosenman wrote: >> > On 02/26/2022 10:57 am, Larry Rosenman wrote: >> >> On 02/26/2022 10:37 am, Juraj Lutter wrote: >> >>>> On 26 Feb 2022, at 03:03, Larry Rosenman wrote: >> >>>> I'm running this script: >> >>>> #!/bin/sh >> >>>> for i in $(zfs list -H | awk '{print $1}') >> >>>> do >> >>>> FS=$1 >> >>>> FN=$(echo ${FS} | sed -e s@/@_@g) >> >>>> sudo zfs send -vecLep ${FS}@REPAIR_SNAP | ssh >> >>>> ler@freenas.lerctr.org cat - \> $FN >> >>>> done >> >>>> >> >>>> >> >>>> >> >>> I’d put, like: >> >>> >> >>> echo ${FS} >> >>> >> >>> before “sudo zfs sendâ€, to get at least a bit of a clue on where it >> >>> can get to. >> >>> >> >>> otis >> >>> >> >>> >> >>> — >> >>> Juraj Lutter >> >>> otis@FreeBSD.org >> >> I just looked at the destination to see where it died (it did!) and I >> >> bectl destroy'd the >> >> BE that crashed it, and am running a new scrub -- we'll see whether >> >> that was sufficient. >> >> >> >> Thanks, all! >> > Well, it was NOT sufficient.... More zfs export fun to come :( >> >> I was able to export the rest of the datasets, and re-install >> 14-CURRENT >> from a recent snapshot, and restore the datasets I care about. >> >> I'm now seeing: >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> pid 48 (zpool), jid 0, uid 0: exited on signal 6 >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> mfi0: IOCTL 0x40086481 not handled >> pid 54 (zpool), jid 0, uid 0: exited on signal 6 >> >> On boot. Ideas? > > That ioctl is DIOCGMEDIASIZE, i.e., something is asking /dev/mfi0, the > controller device node, about the size of a disk. Presumably this is > the result of some kind of misconfiguration somewhere, and /dev/mfid0 > was meant instead. per advice from markj@ I deleted the /{etc,boot}/zfs/zpool.cache files, and this issue went away. Stale cache files which are no longer needed. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Mon Feb 28 06:23:41 2022 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 8647D19ED08D for ; Mon, 28 Feb 2022 06:23:53 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6Vh85bF9z3tVS for ; Mon, 28 Feb 2022 06:23:52 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-yb1-xb32.google.com with SMTP id p19so18455434ybc.6 for ; Sun, 27 Feb 2022 22:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=14VjlZW3Yo/qE8NdcAZanJOSXfRq+YYiwDCnbTHvtb4=; b=GWN6U4NuquLT7843wmmBNQxKQxWNXsuF69EGPIwljUK9FonbIbT9qaxGDjdMwnIOKX Xq5Lu+ozI2OEDCw78JQGZ7QuYG7NJh/Jh2OsQrMKWJhdMkqdprk6Ul2FJK1+J8LP+nLR P+3Cus63Xbr9Tn/OiZIdwcb/Gr/VTVqbHlOrIa9WupfERwFN6R5E+O8eA0oMFXzzB/s9 PqbEzU8hiqMIfSP5LsullLbsk+MbmmVzGt0LVfdiq6u7M+S/0iF4UHWNoel4d5HmKrpb vzIJGEHCUxGRTgQ7EcgoXI4AXe/buIuBiUe5IPtMZHuZnZL7Cs2vplS+Ny1ugCMiyail /T1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=14VjlZW3Yo/qE8NdcAZanJOSXfRq+YYiwDCnbTHvtb4=; b=QD2FD96mAGSj1Ckh7N0jmJfAa6L+62PfRY8aTI86PJI51qECpZ/9NX4/sXKbYHZp7H XpUwlX+0WBvbzxPssfmqoQF8WQEcGf+UQuYLf5QAi//rlQF2icFXOkmdelmGcpY7n280 WX9sVYA4PT/MPtVWtDym4ulldoDj8CqRFg1Z1eyTPIBMrZdYFBqiwShrnScnyaEaibn7 R1kOVGLUVtsmecxXHzFhk2aRHth8VlBkoeW2NzTwfY9YgbCcjGfv5ox9pKrnh4YLrCZa LzUagIqYsc/VA5s8T/oq7Oc1zNrtoi/1ONEUyt+XWmlSY5Jcaoq0RpNJUVyia3Mvzwvn tSxg== X-Gm-Message-State: AOAM531WHkHQkKd52/82UhSagSnskig70Tx2kXOhqHWVFaVQKuxtlqzH smTI8YcrM7FuaSpT2CyuLLR27gOkOOptK24H3N0798wTLdOfZk5q X-Google-Smtp-Source: ABdhPJyf1L362BxHIp4S71xd+5516p5WiSOgoPP6Qv/Jx6r24fk4L0TxyWVEoQAc473q2UVHWGX13U+y2n/nc/HZrUE= X-Received: by 2002:a25:d883:0:b0:624:1ac:5d62 with SMTP id p125-20020a25d883000000b0062401ac5d62mr17565214ybg.602.1646029432144; Sun, 27 Feb 2022 22:23:52 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Michael Schuster Date: Mon, 28 Feb 2022 07:23:41 +0100 Message-ID: Subject: Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font) To: Toomas Soome Cc: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="00000000000097c89705d90e1788" X-Rspamd-Queue-Id: 4K6Vh85bF9z3tVS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=GWN6U4Nu; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::b32 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b32:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000097c89705d90e1788 Content-Type: text/plain; charset="UTF-8" Hi Toomas, On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome wrote: > > > On 27. Feb 2022, at 23:36, Michael Schuster > wrote: > > Hi all, > > I'm trying to get a smaller font in my text-consoles (using vt) on my > Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD > CURRENT from last week. > > [...] > UEFI or BIOS setup? > UEFI > With UEFI, sc and hw.vga.textmode has no effect. With UEFI or > BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will > cause the values list to be printed), or use loadfont command with your > custom font file (created with vtfontcvt). > I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm first time. Many thanks! Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' --00000000000097c89705d90e1788 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Toomas,


On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome <tsoome@me.com> wrote:


On 27. Feb 2022, at = 23:36, Michael Schuster <michaelsprivate@gmail.com> wrote:

Hi all,

I'm trying to get a smaller font in my text-consol= es (using vt) on my Ryzen 4700 and Vega10 Renoir - based laptop with a fres= h install of FreeBSD CURRENT from last week.

[...]=C2=A0


=
UEFI or BIOS setup?

UEFI
=C2=A0
With UEFI, sc and h= w.vga.textmode has no effect. With UEFI or BIOS+hw.vga.textmode=3D0, you ca= n set screen.font variable (empty value will cause the values list to be pr= inted), or use loadfont command with your custom font file (created with vt= fontcvt).

I added= 'screen.font=3D"8x16"' to /boot/loader.conf, worked like= a charm first time.=C2=A0

Many thanks= !
Michael
--
recursion, n: see 'recursion= '
--00000000000097c89705d90e1788-- From nobody Mon Feb 28 07:28:14 2022 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 A658519DC397 for ; Mon, 28 Feb 2022 07:28:21 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-ztbu10011701.me.com (pv50p00im-ztbu10011701.me.com [17.58.6.53]) (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 4K6X6X6yX2z4bjT for ; Mon, 28 Feb 2022 07:28:20 +0000 (UTC) (envelope-from tsoome@me.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1646033300; bh=WzGeaoeyWjrF5sriwjRHaZ8HPuI8EGBM0bpRuW+hx5E=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=XVrQ767VypEIs9rBPzPphDcmqm/WOHTfPPVnZMV/55gsEgFTZVHdz0HzLt0z2uqI+ xp1lLuqP1qZfVW/LEYJbZuUi7YZ21zHD6fb7dFVCX4KtrDiPEA1guB4w7k029YPab5 e8E6uULlofC7cFHLP+HeZkIEiH6ZHawGpRAzJbVLZXx9k81zzgIy8fuwMfYjO3Bm6r Xk53zUvSYNsKY/Mlgi6AsYP/k1BLM3T9uvd0cFf9qwleZf6xyEVljbK9kaAMrLGz5P sD32edvf16uH3TJ8s5GZPCu6QeZxipLJlnM81mqmoG+uxg43W4JDK6UaHbA8HS2FDi 4JSOenFht4Gkg== Received: from smtpclient.apple (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-ztbu10011701.me.com (Postfix) with ESMTPSA id A82F1B4034B; Mon, 28 Feb 2022 07:28:18 +0000 (UTC) From: Toomas Soome Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_278782AB-E677-4225-A064-C762AECA1278" 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 15.0 \(3693.60.0.1.1\)) Subject: Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font) Date: Mon, 28 Feb 2022 09:28:14 +0200 In-Reply-To: Cc: FreeBSD CURRENT To: Michael Schuster References: X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.816 definitions=2022-02-28_02:2022-02-26,2022-02-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2009150000 definitions=main-2202280042 X-Rspamd-Queue-Id: 4K6X6X6yX2z4bjT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=XVrQ767V; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.53 as permitted sender) smtp.mailfrom=tsoome@me.com X-Spamd-Result: default: False [-3.51 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-0.91)[-0.912]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.53:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[me.com]; ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_VERYGOOD(0.00)[17.58.6.53:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_278782AB-E677-4225-A064-C762AECA1278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 28. Feb 2022, at 08:23, Michael Schuster = wrote: >=20 > Hi Toomas, >=20 >=20 > On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome > wrote: >=20 >=20 >> On 27. Feb 2022, at 23:36, Michael Schuster = > wrote: >>=20 >> Hi all, >>=20 >> I'm trying to get a smaller font in my text-consoles (using vt) on my = Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of = FreeBSD CURRENT from last week.=20 >>=20 >=20 > [...]=20 >=20 >=20 > UEFI or BIOS setup? >=20 > UEFI > =20 > With UEFI, sc and hw.vga.textmode has no effect. With UEFI or = BIOS+hw.vga.textmode=3D0, you can set screen.font variable (empty value = will cause the values list to be printed), or use loadfont command with = your custom font file (created with vtfontcvt). >=20 > I added 'screen.font=3D"8x16"' to /boot/loader.conf, worked like a = charm first time.=20 >=20 > Many thanks! > Michael You are welcome. rgds, toomas --Apple-Mail=_278782AB-E677-4225-A064-C762AECA1278 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 28. Feb 2022, at 08:23, Michael Schuster <michaelsprivate@gmail.com> wrote:

Hi = Toomas,


On Sun, Feb 27, 2022 at 10:54 PM Toomas = Soome <tsoome@me.com> wrote:


On 27. = Feb 2022, at 23:36, Michael Schuster <michaelsprivate@gmail.com> wrote:

Hi all,

I'm trying to get a smaller font in my text-consoles (using = vt) on my Ryzen 4700 and Vega10 Renoir - based laptop with a fresh = install of FreeBSD CURRENT from last week.

<= div class=3D"">[...] 


UEFI or BIOS setup?

UEFI
&n= bsp;
With = UEFI, sc and hw.vga.textmode has no effect. With UEFI or = BIOS+hw.vga.textmode=3D0, you can set screen.font variable (empty value = will cause the values list to be printed), or use loadfont command with = your custom font file (created with = vtfontcvt).

I added = 'screen.font=3D"8x16"' to /boot/loader.conf, worked like a charm first = time. 

Many = thanks!
Michael

You are = welcome.

rgds,
toomas


= --Apple-Mail=_278782AB-E677-4225-A064-C762AECA1278-- From nobody Mon Feb 28 08:31:26 2022 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 BD91A19E6F70 for ; Mon, 28 Feb 2022 08:31:29 +0000 (UTC) (envelope-from SRS0=Agkv=TL=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 4K6YWN1N3qz4j4k for ; Mon, 28 Feb 2022 08:31:28 +0000 (UTC) (envelope-from SRS0=Agkv=TL=klop.ws=ronald-lists@realworks.nl) Date: Mon, 28 Feb 2022 09:31:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1646037086; 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; bh=SeFRtdyJqdEa8ikhI7Yfivyzv7IjQrKmWCNyd2IFZus=; b=C6iqoUtuD6h8fivKMyAvmijbJ9mGRwoRRPN3gzyDbvUX8dTKucT78Z7JeLMxQYu3l383m3 BR065Whx3PPHn+YfHaMF7bIbOAiCOcDz1OU6PxrgB84IfljbFEMbpzySg9lgb8pdZQKqas eYKQe3fkNNMYcDx5V+k/Js5xEoc3HSfzWAMcWfP1OrNH+MVBUnA/ucOxxVFsBs4l/gBUeE 0HudOHrJ+9qv09jysKXQbGMxwa26KStuZewv0Zo25TDT0AdWTOI/GN2oWSHKqodWUZ6eAE QmhgxSSX03FsUk6IfD9SaIaFyHa0c/SC1TYa/dlSodyQ/SnghlBlH5VKZAJOng== From: Ronald Klop To: Michael Schuster , FreeBSD CURRENT , Toomas Soome Message-ID: <1843171392.1568.1646037086280@localhost> In-Reply-To: Subject: Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font) 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_1567_986349528.1646037086278" X-Mailer: Realworks (596.36.420274e) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4K6YWN1N3qz4j4k X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=C6iqoUtu; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=Agkv=TL=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=Agkv=TL=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-1.27 / 15.00]; ARC_NA(0.00)[]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=Agkv=TL=klop.ws=ronald-lists@realworks.nl]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.93)[0.933]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org,me.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=Agkv=TL=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_1567_986349528.1646037086278 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Where would this sysctl needed to be documented for the OP to find it? Regards, Ronald Van: Toomas Soome Datum: 28 februari 2022 08:29 Aan: Michael Schuster CC: FreeBSD CURRENT Onderwerp: Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font) > > > > >> >> On 28. Feb 2022, at 08:23, Michael Schuster wrote: >> >> Hi Toomas, >> >> >> On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome wrote: >>> >>> >>>> >>>> On 27. Feb 2022, at 23:36, Michael Schuster wrote: >>>> >>>> Hi all, >>>> >>>> I'm trying to get a smaller font in my text-consoles (using vt) on my Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD CURRENT from last week. >>>> >>> >>> __blockquote_end__ >>> [...] >>> >>>> >>>> >>>> UEFI or BIOS setup? >>> >>> >>> UEFI >>> >>> __blockquote_end__ >>> >>> UEFI >>> >>> __blockquote_start__ >>> With UEFI, sc and hw.vga.textmode has no effect. With UEFI or BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will cause the values list to be printed), or use loadfont command with your custom font file (created with vtfontcvt). >> >> >> I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm first time. >> >> Many thanks! >> Michael > > You are welcome. > > rgds, > toomas > > > > ------=_Part_1567_986349528.1646037086278 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi,

Where would this sysctl n= eeded to be documented  for the OP to find it?

<= div>Regards,
Ronald


Van: Toomas Soome <tsoome@me.com>
Datum:<= /strong> 28 februari 2022 08:29
Aan: Michael Schuster= <michaelsprivate@gmail.com>
CC: FreeBSD CURREN= T <freebsd-current@freebsd.org>
Onderwerp: Re: = "vidcontrol -i mode" shows no output except header (in search of = smaller console font)



On 28. Feb 2022, at 08:23, Michael = Schuster <michaelspri= vate@gmail.com> wrote:

Hi Toomas,


= On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome <tsoome@me.com> wrote:


On 27. Feb 2022= , at 23:36, Michael Schuster <michaelsprivate@gmail.com> wrote:
Hi all,

<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small" class= =3D"do_not_remove">I'm trying to get a smaller font in my text-consoles (us= ing vt) on my Ryzen 4700 and Vega10 Renoir - based laptop with a fresh inst= all of FreeBSD CURRENT from last week.

<= /div>
[...] 


UEFI or BI= OS setup?

UEFI
 
With UEFI, sc and hw.vga.textmode has no effect. With U= EFI or BIOS+hw.vga.textmode=3D0, you can set screen.font variable (empty va= lue will cause the values list to be printed), or use loadfont command with= your custom font file (created with vtfontcvt).

I added 'screen.font=3D"8x16"' to /boot/loader.conf, work= ed like a charm first time. 

Many thanks!
Michael

<= /div>
You are welcome.

rgds,
toomas





------=_Part_1567_986349528.1646037086278-- From nobody Mon Feb 28 08:35:05 2022 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 D947719E86F9 for ; Mon, 28 Feb 2022 08:35:23 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6Ybv2Ngkz4kFJ for ; Mon, 28 Feb 2022 08:35:23 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-2d6923bca1aso98995337b3.9 for ; Mon, 28 Feb 2022 00:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5nC4ISowc9TcoFrK+L+ftw0tIyg0xJsZR9GUrcYbIAQ=; b=OFKiNIpv4ljdKC0bJ2sOPqU+65y8smaurUpXh6ShJPacC4Me9lZ4q2MzeeUzfp4qS1 ohYfvd7CWHOeTiII8e81R7KNMgD0DIvL8QkoTsD6nplK64boPlqMXPRJprBqCNd398XX v34LbTsZiisYKIaL1GWotpwwWaZibXizf+KfmcuXvvlxOPv+QmOCmtwrzjjQ8ExzfEmg 9Jt3jW52kwra0nLjeBT/16AS48bfslb92G11jKVF2kYndJfgrB5/V0AQn/0DnpEQ1u2Q r2OBEjDWk6DIzeTe8utnflhxKgAaJ0uqrcWYij8NIZYJ2C6lbym1nPmDSCHiWZMKeQnQ il6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5nC4ISowc9TcoFrK+L+ftw0tIyg0xJsZR9GUrcYbIAQ=; b=ZR6QF+KAkF5y1fG6b2qYaHH+zkHXu9LwHzRBGa/glpF/vexWSZtJld9k4yDGG44RR7 6BkwJgBHwoDtTkbdJPaGHQn5WR61EDxb9JTMRRP224gUNVaOFapPWzZwxRVmlvcmZ/1u pBsKHJ9jM7MXe/z2LNGzkH1QnlxQO+LN8/mYNpsT9kdOuHEGX3dBukBkc5VRTTZGDGKq e0nyncItqTdTMH+XyQwsCdTcolMMjfijKh43Z7t+xrLl63yIDLOWkUV6G+LsLfzrYtA5 gIJ5Wfi+4OMg/Mkcm3aedNGFvGny2hqyq+IFvODZHtN3zDwuqNwF3g2LvboziXNRe4Mi dlQg== X-Gm-Message-State: AOAM5310UO+Gx4C8ifXvfdQ5tkeKfZCW69Nj9zz+3Tczq/rxxEDGhQKu 1NDdMxLTOw973XUwvhsk47NKD1OtB7XgKlBTGVE= X-Google-Smtp-Source: ABdhPJz/k7g7LAdchCOeelWOk9BA8IgiYzsbdnsnfy/2Kps7tyRRcZKwJo+uSM/pOxhL4xQsE8WnieSx3W0SiDvVDt4= X-Received: by 2002:a81:4524:0:b0:2db:3b9b:e3ea with SMTP id s36-20020a814524000000b002db3b9be3eamr9005631ywa.263.1646037316751; Mon, 28 Feb 2022 00:35:16 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <1843171392.1568.1646037086280@localhost> In-Reply-To: <1843171392.1568.1646037086280@localhost> From: Michael Schuster Date: Mon, 28 Feb 2022 09:35:05 +0100 Message-ID: Subject: Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font) To: Ronald Klop Cc: FreeBSD CURRENT , Toomas Soome Content-Type: multipart/alternative; boundary="0000000000008d55cd05d90fed69" X-Rspamd-Queue-Id: 4K6Ybv2Ngkz4kFJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=OFKiNIpv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::112f as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-2.18 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.82)[0.822]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112f:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[freebsd.org,me.com]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000008d55cd05d90fed69 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 28, 2022 at 9:31 AM Ronald Klop wrote: > Hi, > > Where would this sysctl needed to be documented for the OP to find it? > IMO vt(4) would have been a good place. > > Regards, > Ronald > > > *Van:* Toomas Soome > *Datum:* 28 februari 2022 08:29 > *Aan:* Michael Schuster > *CC:* FreeBSD CURRENT > *Onderwerp:* Re: "vidcontrol -i mode" shows no output except header (in > search of smaller console font) > > > > On 28. Feb 2022, at 08:23, Michael Schuster > wrote: > > Hi Toomas, > > > On Sun, Feb 27, 2022 at 10:54 PM Toomas Soome wrote: > >> >> >> On 27. Feb 2022, at 23:36, Michael Schuster >> wrote: >> >> Hi all, >> >> I'm trying to get a smaller font in my text-consoles (using vt) on my >> Ryzen 4700 and Vega10 Renoir - based laptop with a fresh install of FreeBSD >> CURRENT from last week. >> >> [...] > > >> UEFI or BIOS setup? >> > > UEFI > > >> With UEFI, sc and hw.vga.textmode has no effect. With UEFI or >> BIOS+hw.vga.textmode=0, you can set screen.font variable (empty value will >> cause the values list to be printed), or use loadfont command with your >> custom font file (created with vtfontcvt). >> > > I added 'screen.font="8x16"' to /boot/loader.conf, worked like a charm > first time. > > Many thanks! > Michael > > > You are welcome. > > rgds, > toomas > > > > > > -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' --0000000000008d55cd05d90fed69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb = 28, 2022 at 9:31 AM Ronald Klop <ronald-lists@klop.ws> wrote:
Hi,

Where would this sysctl ne= eded to be documented =C2=A0for the OP to find it?
=

IMO vt(4) would have been a good place.

Regards,
Ronald

=

Van: Toomas Soome <tsoome@me.com>
Datum: 28 februari 2022 08:29
Aan: Michael Schuster &l= t;michaelspr= ivate@gmail.com>
CC: FreeBSD CURRENT <freebsd-current@f= reebsd.org>
Onderwerp: Re: "vidcontrol -i m= ode" shows no output except header (in search of smaller console font)=



On 28. Feb 2022, at 08:23, Michael Schuster &= lt;michaelsp= rivate@gmail.com> wrote:

Hi Toomas,


On Sun, Feb 27,= 2022 at 10:54 PM Toomas Soome <tsoome@me.com> wrote:


On 27. Feb 2022= , at 23:36, Michael Schuster <michaelsprivate@gmail.com> wrote:

Hi all,

I'm trying to get a smaller font in my text-consoles (usi= ng vt) on my Ryzen 4700 and Vega10 Renoir - based laptop with a fresh insta= ll of FreeBSD CURRENT from last week.

[...]=C2=A0


UEFI or BIOS setup?

UEFI
=C2=A0
With UEFI, sc and hw.vga.textmode has no effect. = With UEFI or BIOS+hw.vga.textmode=3D0, you can set screen.font variable (em= pty value will cause the values list to be printed), or use loadfont comman= d with your custom font file (created with vtfontcvt).

I added 'screen.font=3D"8x16"' to /boot/loa= der.conf, worked like a charm first time.=C2=A0

Many thanks!
Michael
=

You are welcome.

rgds,
toomas






<= div>
--
recursion, n: see 'recursion'
--0000000000008d55cd05d90fed69-- From nobody Mon Feb 28 14:50:31 2022 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 4174619E0841 for ; Mon, 28 Feb 2022 14:50:41 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 4K6jww2CRdz4k6H for ; Mon, 28 Feb 2022 14:50:40 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800:0:0:0:0:a135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 21SEoWO5038704; Mon, 28 Feb 2022 15:50:32 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id D6E20929; Mon, 28 Feb 2022 15:50:31 +0100 (CET) Subject: Re: "vidcontrol -i mode" shows no output except header (in search of smaller console font) To: Michael Schuster , Ronald Klop Cc: FreeBSD CURRENT , Toomas Soome References: <1843171392.1568.1646037086280@localhost> From: Harry Schmalzbauer Organization: OmniLAN Message-ID: Date: Mon, 28 Feb 2022 15:50:31 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4K6jww2CRdz4k6H X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de X-Spamd-Result: default: False [-1.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[omnilan.de]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[0.999]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com,klop.ws]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE]; FREEMAIL_CC(0.00)[freebsd.org,me.com]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Am 28.02.2022 um 09:35 schrieb Michael Schuster: > On Mon, Feb 28, 2022 at 9:31 AM Ronald Klop > wrote: > > Hi, > > Where would this sysctl needed to be documented  for the OP to > find it? > There's many things to consider these days, so hard to find a single place I guess... (and IMHO currently no severe issue, since these days, if defaults don't match perfectly, users get too big fonts instead of unreadable small fonts) > > IMO vt(4) would have been a good place. vt(4) is no consumer of the 'screen.font' loader tunable.  In case vt(4) uses efifb for output, resolution is unchangeable and vidfont(1)/kbdmap(1) refers to a different set of fonts by default as loader does.  Of course, there's filesystem boundaries to consider, but I don't know the reason why /usr/share/vt/fonts isn't simply a link to /boot/fonts/ - both sets are almost identical in size. Some time ago, I proposed a generic boot/loader.conf file, which I created as a starting point to describe the BIOS/UEFI|loader|console(vt(4)\sc(4)) relations: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256343 This is only a proposal, and reflects just my own needs/confusion of the past, but probably help other too, getting an overview and finding the corresponding docs/man pages. It is quiet large, but I felt it's necessary to also mention KMS/drm. It's boot/loader description biased, but also contains Serial console and Video console specific hints. -harry From nobody Mon Feb 28 15:15:45 2022 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 C4F9B19E655D; Mon, 28 Feb 2022 15:15:57 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6kV42PVHz4pPf; Mon, 28 Feb 2022 15:15:56 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 6A9B610A32E8; Mon, 28 Feb 2022 16:15:48 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 8885D10A3308; Mon, 28 Feb 2022 16:15:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1646061346; 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=ARH83yi8Caw1S4UOmTrf0EbQak4CgsLv9xgtVffwm1g=; b=HmLqD38VYnQUNHjNNjsOYST7Bt0iqO9Qfc8uIDchT4vcH3KmP9yZ9eBFdWs6kEy1de5O1I 8nZl2T+DIDBssDVrJPxsoSTsVRiN2BscnHlx52XyBjczW43/LKDlRf1qe/NPm89T27ynjx FpzqMvVmtiJXOGx2/aPT733m1p9jDE0oiuGJ8DPBDeBxnJ83SV/r10MvqUWAl2XGNt4H5V r1R7Q8ICVwgR6dUBIMnJIRA9lQCnzjkQJSUAOAXWxAWfFv7lBzVNa0X+9YXWXXfyuZpwOY pURVCj2igkHkwbuiy4JUmxwxilTfTTFOwjHwTybjgEDNgR2WP249XtSqxszBsQ== Received: from hermann (dynamic-2a01-0c22-ad8a-3000-954e-91b4-d2cb-c2d0.c22.pool.telefonica.de [IPv6:2a01:c22:ad8a:3000:954e:91b4:d2cb:c2d0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 3D7C410A3306; Mon, 28 Feb 2022 16:15:46 +0100 (CET) Date: Mon, 28 Feb 2022 16:15:45 +0100 From: FreeBSD User To: FreeBSD virtualization , FreeBSD CURRENT Subject: bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted! Message-ID: <20220228161545.251fe0d8@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 57d998 X-Rspamd-UID: b72891 X-Rspamd-Queue-Id: 4K6kV42PVHz4pPf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=HmLqD38V; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.78 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.88)[-0.885]; SUBJECT_ENDS_EXCLAIM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-virtualization]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from] X-ThisMailContainsUnwantedMimeParts: N Hello folks, we run at least two poudriere build systems on recent CURRENT boxes and one of these poudriere build systems is working within a jail - setup via FreeBSD's /etc/jail.conf and by misusing the port ezjail for copying/deploying our self-compiled jail binary. The poudriere jail uses ZFS and is, to make it short, working like a charme. Now we try to setup another poudriere, but this time the base is XigmaNAS 12.3.0.4/9009, which is based upon 12.X-RELENG, utilizing "bastille". Bastille is up to date (in terms od the XigmaNAS plugin). Following the setup we used on the native CURRENT "jailed poudriere" builder and also following this reference (for those who want to check on this) https://www.mimar.rs/blog/host-your-own-services-with-freebsd-jails-part-3-poudriere which seems quite recent and with the exception, that we use "vnet" on all of our systems for jails and so does XigmaNAS. Starting a building process via poudriere ends up with # poudriere bulk -p head -z default -j 123-amd64 -f /usr/local/etc/poudriere.d/zeit4-default.pkglist [00:00:00] Creating the reference jail... done [00:00:01] Mounting system devices for 123-amd64-head-default [00:00:01] Warning: Using packages from previously failed, or uncommitted, build: /mnt/poudriere/data/packages/123-amd64-head-default/.building [00:00:01] Mounting ports from: /mnt/poudriere/ports/head [00:00:01] Mounting packages from: /mnt/poudriere/data/packages/123-amd64-head-default [00:00:01] Mounting distfiles from: /mnt/poudriere/ports/distfiles [00:00:01] Copying /var/db/ports from: /usr/local/etc/poudriere.d/head-amd64-head-default-options [00:00:02] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf -> /mnt/poudriere/data/.m/123-amd64-head-default/ref/etc/resolv.conf [00:00:02] Starting jail 123-amd64-head-default jail: jail_set: Operation not permitted [00:00:02] Cleaning up [00:00:02] Unmounting file systems poudriere jail -l: # poudriere jail -l JAILNAME VERSION ARCH METHOD TIMESTAMP PATH 123-amd64 12.3-RELEASE amd64 url=https://download.freebsd.org/releases/a ... 3-RELEASE/ 2022-02-24 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64 url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24 14:11:32 /mnt/poudriere/jails/130-amd64 The jail.conf for this specific jail is as follows: [...] pulverfass-001 { devfs_ruleset = 13; enforce_statfs = 1; exec.clean; exec.consolelog = /mnt/extensions/bastille/logs/pulverfass-001_console.log; exec.start = '/bin/sh /etc/rc'; exec.stop = '/bin/sh /etc/rc.shutdown'; host.hostname = XXXXXXXXX; mount.devfs; mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab; path = /mnt/extensions/bastille/jails/pulverfass-001/root; securelevel = 0; vnet; vnet.interface = e0b_bastille4; exec.prestart += "jib addm bastille4 igb0"; exec.prestart += "ifconfig e0a_bastille4 description \"vnet host interface for Bastille jail pulverfass-001\""; exec.poststop += "jib destroy bastille4"; allow.mount; allow.mount.fdescfs; allow.mount.devfs; allow.mount.tmpfs; allow.mount.nullfs; allow.mount.procfs; allow.mount.linsysfs; allow.mount.linprocfs; allow.mount.zfs; allow.chflags; allow.raw_sockets; allow.socket_af; allow.sysvipc; linux = new; exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere"; exec.start += "/sbin/zfs mount -a"; exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere"; } [...] Tracking the execution of the build process by issuing poudriere -x bulk ... and examin the resulting trace doesn' tgive me any hint, the error reported above immediately occurs when the jail is about to be started: + set -u +x + jail -c persist 'name=123-amd64-head-default' 'path=/mnt/poudriere/data/.m/ \ 123-amd64-head-default/ref' 'host.hostname=basehost.local.domain' \ 'ip4.addr=127.0.0.1' 'ip6.addr=::1' allow.chflags allow.sysvipc jail: jail_set: Operation not permitted + exit_handler [...] Searching the net revealed some issues with setting IP4 and IP6 in poudriere, but those findings are dated back to 2017 and 2014 and I guess this is solved right now. The difference between our manually jail.conf driven setup and the XigmaNAS/bastille based one is, bastille uses jib/netgraph based seutups of the vnet and the ip4/ip6 is setup from rc.conf, while we use epair in the other world and the ip is setup from withing the jail definition in jail.conf. I'm out of ideas here and after two days of trial and error and trying to understand what's going on lost ... Any hints or tipps? Thanks in advance, O. Hartmann From nobody Mon Feb 28 16:11:00 2022 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 A394719D9EFB; Mon, 28 Feb 2022 16:11:04 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6ljg568Pz3F3S; Mon, 28 Feb 2022 16:11:03 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lj1-x22f.google.com with SMTP id r20so18120829ljj.1; Mon, 28 Feb 2022 08:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ba9jPzhu9XMVHjHyx/w8NF08TqK9t+60oP+1ZhuShXo=; b=ILDAw1CZVjI/20mJhQLHSv6wNbjYUlqnuImzlXNYiHKK808/Ys/v4B8QEcZjb0l8f6 Et65oh+DqEGg/iy9AfQ5WIAb7hQzbIYUVwi0B4EGDOZYaexH7Oo3/IzZSe03mvv58xDY lXn9GB/xLIQILRAORxN0iSkHQP+FU9kje9ErIM5lq4mtVSD0NoowT154LDM/Dt+mPgg2 FCL9HZY0sO7TXyFShXHnZ0394zPo0OO49iEXl0LMu7LwL/gGrYGNVngRqXbAsNkhnm+b 6+LdoRK9Q/+gInsHXPWzzA3Cow/izhcG/h1p09tFmxB2/qGzNByB7Gu0t0jN9qfC8O5K iT1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ba9jPzhu9XMVHjHyx/w8NF08TqK9t+60oP+1ZhuShXo=; b=QCevoaCpUVavJWDF26+vxHBYUsR72muAuJP0WpnwEEFbW82xclkRbmoi1AmIHPEuzZ WM8/RgxdJUaGbfBRySaF9REJCcmXbV+79TXEAkddVJKDi8AGAf1brsLvxWr5vq7fGnpA JdBomCE8kpf7GWLVlJSawSMLQFzMp0ZrPYJyczUm/ZPX62qqbWzxjgOddnMHW/W8pIbD GkZ4sxHwGbH9W24UwmErXOpVzRza3zX/2JTHWfQjOqARq1omt3+SOKv/vJvoNihto2jq 8MdlWyf6YusL3zRsIg/UD2AWsDP1OlTb6wVbGAn7n7eIpgs58EaNaWr6VB46PQZ6eWE6 ALSQ== X-Gm-Message-State: AOAM533dt/B/XQi3BIAxYZvYWF76V8mhn8/IFw9FNPx5uTK8SZt0F63v GjTeW6wPDzwGGaXGKaNlfcJQIEfel3T5mImsZ+k= X-Google-Smtp-Source: ABdhPJxbMODoZrzDzaFe9QQCNTGzBFgJGekQjgYVNPQWoW+9NmjgWnP0N4U/dYjHfkwlY4l73OHyT979Pop7t8Fx56g= X-Received: by 2002:a2e:9cd5:0:b0:246:3ec0:7505 with SMTP id g21-20020a2e9cd5000000b002463ec07505mr15058457ljj.434.1646064661550; Mon, 28 Feb 2022 08:11:01 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:6520:4da0:b0:1a1:e0c6:12e5 with HTTP; Mon, 28 Feb 2022 08:11:00 -0800 (PST) In-Reply-To: <20220228161545.251fe0d8@hermann> References: <20220228161545.251fe0d8@hermann> From: Mateusz Guzik Date: Mon, 28 Feb 2022 17:11:00 +0100 Message-ID: Subject: Re: bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted! To: FreeBSD User Cc: FreeBSD virtualization , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4K6ljg568Pz3F3S X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ILDAw1CZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::22f as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22f:from]; SUBJECT_ENDS_EXCLAIM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-virtualization,freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N There is a number of places which can return EPERM, to paste an example: if (gotslevel) { if (slevel < ppr->pr_securelevel) { error = EPERM; goto done_deref_locked; } } if (gotchildmax) { if (childmax >= ppr->pr_childmax) { error = EPERM; goto done_deref_locked; } } if (gotenforce) { if (enforce < ppr->pr_enforce_statfs) { error = EPERM; goto done_deref_locked; } } I see in your config you have enforce_statfs = 1; , perhaps that's smaller than what the host has and in that case you would get the error. Ultimately, while cumbersome, you can add printf to the code to find out which case is giving you the error. The real thing to do here would be implement something like SET_ERROR from illumos, which would allow to immediately pin point where the problem is coming from. On 2/28/22, FreeBSD User wrote: > Hello folks, > > we run at least two poudriere build systems on recent CURRENT boxes and one > of these > poudriere build systems is working within a jail - setup via FreeBSD's > /etc/jail.conf and > by misusing the port ezjail for copying/deploying our self-compiled jail > binary. The > poudriere jail uses ZFS and is, to make it short, working like a charme. > > Now we try to setup another poudriere, but this time the base is XigmaNAS > 12.3.0.4/9009, > which is based upon 12.X-RELENG, utilizing "bastille". Bastille is up to > date (in terms > od the XigmaNAS plugin). > > Following the setup we used on the native CURRENT "jailed poudriere" builder > and also > following this reference (for those who want to check on this) > > https://www.mimar.rs/blog/host-your-own-services-with-freebsd-jails-part-3-poudriere > > which seems quite recent and with the exception, that we use "vnet" on all > of our systems > for jails and so does XigmaNAS. > > Starting a building process via poudriere ends up with > > > # poudriere bulk -p head -z default -j 123-amd64 -f > /usr/local/etc/poudriere.d/zeit4-default.pkglist [00:00:00] Creating the > reference > jail... done [00:00:01] Mounting system devices for 123-amd64-head-default > [00:00:01] Warning: Using packages from previously failed, or uncommitted, > build: > /mnt/poudriere/data/packages/123-amd64-head-default/.building [00:00:01] > Mounting ports > from: /mnt/poudriere/ports/head [00:00:01] Mounting packages from: > /mnt/poudriere/data/packages/123-amd64-head-default [00:00:01] Mounting > distfiles from: > /mnt/poudriere/ports/distfiles [00:00:01] Copying /var/db/ports from: > /usr/local/etc/poudriere.d/head-amd64-head-default-options [00:00:02] > Appending to > make.conf: /usr/local/etc/poudriere.d/make.conf /etc/resolv.conf -> > /mnt/poudriere/data/.m/123-amd64-head-default/ref/etc/resolv.conf [00:00:02] > Starting > jail 123-amd64-head-default jail: jail_set: Operation not permitted > [00:00:02] Cleaning up > [00:00:02] Unmounting file systems > > poudriere jail -l: > > # poudriere jail -l > JAILNAME VERSION ARCH METHOD TIMESTAMP PATH > 123-amd64 12.3-RELEASE amd64 url=https://download.freebsd.org/releases/a ... > 3-RELEASE/ > 2022-02-24 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE > amd64 > url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24 > 14:11:32 > /mnt/poudriere/jails/130-amd64 > > The jail.conf for this specific jail is as follows: > > [...] > pulverfass-001 { > devfs_ruleset = 13; > enforce_statfs = 1; > exec.clean; > exec.consolelog = /mnt/extensions/bastille/logs/pulverfass-001_console.log; > exec.start = '/bin/sh /etc/rc'; > exec.stop = '/bin/sh /etc/rc.shutdown'; > host.hostname = XXXXXXXXX; > mount.devfs; > mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab; > path = /mnt/extensions/bastille/jails/pulverfass-001/root; > securelevel = 0; > > vnet; > vnet.interface = e0b_bastille4; > exec.prestart += "jib addm bastille4 igb0"; > exec.prestart += "ifconfig e0a_bastille4 description \"vnet host interface > for Bastille > jail pulverfass-001\""; exec.poststop += "jib destroy bastille4"; > > allow.mount; > allow.mount.fdescfs; > allow.mount.devfs; > allow.mount.tmpfs; > allow.mount.nullfs; > allow.mount.procfs; > allow.mount.linsysfs; > allow.mount.linprocfs; > allow.mount.zfs; > > allow.chflags; > allow.raw_sockets; > allow.socket_af; > allow.sysvipc; > > linux = new; > > exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere"; > exec.start += "/sbin/zfs mount -a"; > exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere"; > > } > [...] > > Tracking the execution of the build process by issuing > > poudriere -x bulk ... > > and examin the resulting trace doesn' tgive me any hint, the error reported > above > immediately occurs when the jail is about to be started: > > + set -u +x > + jail -c persist 'name=123-amd64-head-default' > 'path=/mnt/poudriere/data/.m/ \ > 123-amd64-head-default/ref' 'host.hostname=basehost.local.domain' \ > 'ip4.addr=127.0.0.1' 'ip6.addr=::1' allow.chflags allow.sysvipc > jail: jail_set: Operation not permitted > + exit_handler > [...] > > Searching the net revealed some issues with setting IP4 and IP6 in > poudriere, but those > findings are dated back to 2017 and 2014 and I guess this is solved right > now. > > The difference between our manually jail.conf driven setup and the > XigmaNAS/bastille > based one is, bastille uses jib/netgraph based seutups of the vnet and the > ip4/ip6 is > setup from rc.conf, while we use epair in the other world and the ip is > setup from > withing the jail definition in jail.conf. > > I'm out of ideas here and after two days of trial and error and trying to > understand > what's going on lost ... Any hints or tipps? > > Thanks in advance, > > O. Hartmann > > -- Mateusz Guzik From nobody Mon Feb 28 16:11:27 2022 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 C744E19DB893; Mon, 28 Feb 2022 16:11:43 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6lkP6DKhz3Fdr; Mon, 28 Feb 2022 16:11:41 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 051ec02a; Mon, 28 Feb 2022 16:11:32 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id d2f374be (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Mon, 28 Feb 2022 16:11:29 +0000 (UTC) Date: Mon, 28 Feb 2022 17:11:27 +0100 From: Michael Gmelin To: FreeBSD User Cc: FreeBSD virtualization , FreeBSD CURRENT Subject: Re: bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted! Message-ID: <20220228171127.2469a57d.grembo@freebsd.org> In-Reply-To: <20220228161545.251fe0d8@hermann> References: <20220228161545.251fe0d8@hermann> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K6lkP6DKhz3Fdr X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [-1.17 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-0.50)[-0.495]; NEURAL_HAM_LONG(-0.58)[-0.576]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_CONTAINS_FROM(1.00)[]; SUBJECT_ENDS_EXCLAIM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-virtualization]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 28 Feb 2022 16:15:45 +0100 FreeBSD User wrote: > Hello folks, > > we run at least two poudriere build systems on recent CURRENT boxes > and one of these poudriere build systems is working within a jail - > setup via FreeBSD's /etc/jail.conf and by misusing the port ezjail > for copying/deploying our self-compiled jail binary. The poudriere > jail uses ZFS and is, to make it short, working like a charme. > > Now we try to setup another poudriere, but this time the base is > XigmaNAS 12.3.0.4/9009, which is based upon 12.X-RELENG, utilizing > "bastille". Bastille is up to date (in terms od the XigmaNAS plugin). > > Following the setup we used on the native CURRENT "jailed poudriere" > builder and also following this reference (for those who want to > check on this) > > https://www.mimar.rs/blog/host-your-own-services-with-freebsd-jails-part-3-poudriere > > which seems quite recent and with the exception, that we use "vnet" > on all of our systems for jails and so does XigmaNAS. > > Starting a building process via poudriere ends up with > > > # poudriere bulk -p head -z default -j 123-amd64 -f > /usr/local/etc/poudriere.d/zeit4-default.pkglist [00:00:00] Creating > the reference jail... done [00:00:01] Mounting system devices for > 123-amd64-head-default [00:00:01] Warning: Using packages from > previously failed, or uncommitted, build: > /mnt/poudriere/data/packages/123-amd64-head-default/.building > [00:00:01] Mounting ports from: /mnt/poudriere/ports/head [00:00:01] > Mounting packages from: > /mnt/poudriere/data/packages/123-amd64-head-default [00:00:01] > Mounting distfiles from: /mnt/poudriere/ports/distfiles [00:00:01] > Copying /var/db/ports from: > /usr/local/etc/poudriere.d/head-amd64-head-default-options [00:00:02] > Appending to make.conf: /usr/local/etc/poudriere.d/make.conf > /etc/resolv.conf -> > /mnt/poudriere/data/.m/123-amd64-head-default/ref/etc/resolv.conf > [00:00:02] Starting jail 123-amd64-head-default jail: jail_set: > Operation not permitted [00:00:02] Cleaning up [00:00:02] Unmounting > file systems > > poudriere jail -l: > > # poudriere jail -l > JAILNAME VERSION ARCH METHOD TIMESTAMP PATH > 123-amd64 12.3-RELEASE amd64 > url=https://download.freebsd.org/releases/a ... 3-RELEASE/ 2022-02-24 > 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64 > url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24 > 14:11:32 /mnt/poudriere/jails/130-amd64 > > The jail.conf for this specific jail is as follows: > > [...] > pulverfass-001 { > devfs_ruleset = 13; > enforce_statfs = 1; > exec.clean; > exec.consolelog = > /mnt/extensions/bastille/logs/pulverfass-001_console.log; exec.start > = '/bin/sh /etc/rc'; exec.stop = '/bin/sh /etc/rc.shutdown'; > host.hostname = XXXXXXXXX; > mount.devfs; > mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab; > path = /mnt/extensions/bastille/jails/pulverfass-001/root; > securelevel = 0; > > vnet; > vnet.interface = e0b_bastille4; > exec.prestart += "jib addm bastille4 igb0"; > exec.prestart += "ifconfig e0a_bastille4 description \"vnet host > interface for Bastille jail pulverfass-001\""; exec.poststop += "jib > destroy bastille4"; > > allow.mount; > allow.mount.fdescfs; > allow.mount.devfs; > allow.mount.tmpfs; > allow.mount.nullfs; > allow.mount.procfs; > allow.mount.linsysfs; > allow.mount.linprocfs; > allow.mount.zfs; > > allow.chflags; > allow.raw_sockets; > allow.socket_af; > allow.sysvipc; > > linux = new; > > exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere"; > exec.start += "/sbin/zfs mount -a"; > exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere"; > > } > [...] > > Tracking the execution of the build process by issuing > > poudriere -x bulk ... > > and examin the resulting trace doesn' tgive me any hint, the error > reported above immediately occurs when the jail is about to be > started: > > + set -u +x > + jail -c persist 'name=123-amd64-head-default' > 'path=/mnt/poudriere/data/.m/ \ 123-amd64-head-default/ref' > 'host.hostname=basehost.local.domain' \ 'ip4.addr=127.0.0.1' > 'ip6.addr=::1' allow.chflags allow.sysvipc jail: jail_set: Operation > not permitted > + exit_handler > [...] > > Searching the net revealed some issues with setting IP4 and IP6 in > poudriere, but those findings are dated back to 2017 and 2014 and I > guess this is solved right now. > > The difference between our manually jail.conf driven setup and the > XigmaNAS/bastille based one is, bastille uses jib/netgraph based > seutups of the vnet and the ip4/ip6 is setup from rc.conf, while we > use epair in the other world and the ip is setup from withing the > jail definition in jail.conf. > > I'm out of ideas here and after two days of trial and error and > trying to understand what's going on lost ... Any hints or tipps? > > Thanks in advance, > > O. Hartmann Hi Oliver, I don't see `children.max` set in any of the configuration you shared above. Cheers Michael -- Michael Gmelin From nobody Mon Feb 28 16:58:35 2022 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 C004119E529F; Mon, 28 Feb 2022 16:58:43 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6mmf3Z24z3NvN; Mon, 28 Feb 2022 16:58:42 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id BF70610A32F1; Mon, 28 Feb 2022 17:58:40 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id B364610A1E89; Mon, 28 Feb 2022 17:58:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1646067516; 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=9tGdWIFMYoaxMOyUXHGum8i8wzVvIMZiNUZ71xDmbTw=; b=j6i2gRLI3CQeQ+4veRo1qOkSNuh8k9/TXw3ELEgUBuScVzfDgpJ41VOECL77tmGJEdIAf7 yLT43nLkxuzD0r5DDrvC06FNxb/NwfFdkAQzaHWvexmoNnQpgFM2PZeLtPnO0DVsLaMG6Y ePHoR9HzAzj3nrL+J2PKrkc2HF1Gmy6ozvrGQ0KOJCejWUL+FwC+GpaN9MyaSv6Kx4EutA b3W0GOtj5RN/Y3UESn0amM+1WMuwR6P5K3TapjSRmgftkTZ6RLKOvdov8ELDRRxpCv82X4 i7Fa5CreCowDcPMmwYHFCZ2wfx0j9pxozeQP9PwgNPkH66yX7XAK7SwXWxTGMA== Received: from hermann (dynamic-2a01-0c22-ad8a-3000-954e-91b4-d2cb-c2d0.c22.pool.telefonica.de [IPv6:2a01:c22:ad8a:3000:954e:91b4:d2cb:c2d0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 6F1E610A1E85; Mon, 28 Feb 2022 17:58:36 +0100 (CET) Date: Mon, 28 Feb 2022 17:58:35 +0100 From: FreeBSD User To: Michael Gmelin Cc: FreeBSD virtualization , FreeBSD CURRENT , Mateusz Guzik Subject: Re: bastille : poudriere not working in jail: jail: jail:_set: Operation not permitted! Message-ID: <20220228175835.624eb178@hermann> In-Reply-To: <20220228171127.2469a57d.grembo@freebsd.org> References: <20220228161545.251fe0d8@hermann> <20220228171127.2469a57d.grembo@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-Transfer-Encoding: 7bit X-Rspamd-UID: 27bc31 X-Rspamd-UID: 717799 X-Rspamd-Queue-Id: 4K6mmf3Z24z3NvN X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=j6i2gRLI; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SUBJECT_ENDS_EXCLAIM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-virtualization]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from] X-ThisMailContainsUnwantedMimeParts: N On Mon, 28 Feb 2022 17:11:27 +0100 Michael Gmelin wrote: [...] schnipp [...] > > > > poudriere jail -l: > > > > # poudriere jail -l > > JAILNAME VERSION ARCH METHOD TIMESTAMP PATH > > 123-amd64 12.3-RELEASE amd64 > > url=https://download.freebsd.org/releases/a ... 3-RELEASE/ 2022-02-24 > > 14:14:25 /mnt/poudriere/jails/123-amd64 130-amd64 13.0-RELEASE amd64 > > url=https://download.freebsd.org/releases/a ... 0-RELEASE/ 2022-02-24 > > 14:11:32 /mnt/poudriere/jails/130-amd64 > > > > The jail.conf for this specific jail is as follows: > > > > [...] > > pulverfass-001 { > > devfs_ruleset = 13; > > enforce_statfs = 1; > > exec.clean; > > exec.consolelog = > > /mnt/extensions/bastille/logs/pulverfass-001_console.log; exec.start > > = '/bin/sh /etc/rc'; exec.stop = '/bin/sh /etc/rc.shutdown'; > > host.hostname = XXXXXXXXX; > > mount.devfs; > > mount.fstab = /mnt/extensions/bastille/jails/pulverfass-001/fstab; > > path = /mnt/extensions/bastille/jails/pulverfass-001/root; > > securelevel = 0; > > > > vnet; > > vnet.interface = e0b_bastille4; > > exec.prestart += "jib addm bastille4 igb0"; > > exec.prestart += "ifconfig e0a_bastille4 description \"vnet host > > interface for Bastille jail pulverfass-001\""; exec.poststop += "jib > > destroy bastille4"; > > > > allow.mount; > > allow.mount.fdescfs; > > allow.mount.devfs; > > allow.mount.tmpfs; > > allow.mount.nullfs; > > allow.mount.procfs; > > allow.mount.linsysfs; > > allow.mount.linprocfs; > > allow.mount.zfs; > > > > allow.chflags; > > allow.raw_sockets; > > allow.socket_af; > > allow.sysvipc; > > > > linux = new; > > > > exec.created += "/sbin/zfs jail ${name} BUNKER00/poudriere"; > > exec.start += "/sbin/zfs mount -a"; > > exec.poststop += "/sbin/zfs unjail BUNKER00/poudriere"; > > > > } > > [...] > > > > Tracking the execution of the build process by issuing > > > > poudriere -x bulk ... > > > > and examin the resulting trace doesn' tgive me any hint, the error > > reported above immediately occurs when the jail is about to be > > started: > > > > + set -u +x > > + jail -c persist 'name=123-amd64-head-default' > > 'path=/mnt/poudriere/data/.m/ \ 123-amd64-head-default/ref' > > 'host.hostname=basehost.local.domain' \ 'ip4.addr=127.0.0.1' > > 'ip6.addr=::1' allow.chflags allow.sysvipc jail: jail_set: Operation > > not permitted > > + exit_handler > > [...] > > > > Searching the net revealed some issues with setting IP4 and IP6 in > > poudriere, but those findings are dated back to 2017 and 2014 and I > > guess this is solved right now. > > > > The difference between our manually jail.conf driven setup and the > > XigmaNAS/bastille based one is, bastille uses jib/netgraph based > > seutups of the vnet and the ip4/ip6 is setup from rc.conf, while we > > use epair in the other world and the ip is setup from withing the > > jail definition in jail.conf. > > > > I'm out of ideas here and after two days of trial and error and > > trying to understand what's going on lost ... Any hints or tipps? > > > > Thanks in advance, > > > > O. Hartmann > > Hi Oliver, > > I don't see `children.max` set in any of the configuration you shared > above. > > Cheers > Michael > Hello Michael, bummer! I was so selfconfident because I copied the initial config from a working test and had this attribute already set that I never checked again its existence - and started reorganizing the jail.conf attributes ... A fine observation and a full hit: after setting children.max= 128; the poudriere jail started working ... didn't wait for the finish so far. I'm sorry for the noise - thanks for you eyes ... Kind regards, Oliver From nobody Mon Feb 28 19:04:28 2022 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 C23EB19FCF8C for ; Mon, 28 Feb 2022 19:04:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K6qYy4nfhz4Sgk for ; Mon, 28 Feb 2022 19:04:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646075070; bh=FoK5iMw7XqjVUCusJwRhHjOqebE2ImUt6qVe6wvUWf8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=aZtlmugjdvpmjaMz2oLekv/CMSYXLEQJTkrFptLrdQ1zRaqDklCX73Uc96hj0a8ZTbDCR/CoUoSNNvwD3Ax0DtTpdYtd9t1CkdHkycZQHvOWpwaAVdbw4ERYMoMkOGR9gyyiRhzLeefwk1APzdTLqB7HigVRhCKr+C/6eNhaGrxAylPb4vJMtMfmyqgJv+qR7riqJq8p67KF4vsP5mLtAJ6jhyBoQepkFv9u4qkhdtwW9w6WBZLxv5tn7/QHsYUhsU+ny1u139t1yMqzoCv4EjdFIrHQLMZG1JMz5UWM9yGPw+mjGe/diT4cMmUyrPigUbOFYM2L8Ak0AcjWHXJjmA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646075070; bh=a6wvs2fYb2sIjeSDdKV3VzkfH5hG0dDRzGZKh6uyOlP=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=JhsCKHckHWyOu2Pnj8/LAqjl05NlDSK+txelr04ulNGQuzuHd4+KBWIWB5JoiAszabqvBAwgBCDEFX0et7oLu28ChnySB4IUp23LE4KtlxmhnkhBtTbcKmm8ekygeIUXidTrr+riHtrtj3m3Q1ZzmRgFppRFr6GRVfxjOs1PhxX0W7SxKX4f1DIe7pZa+Y73GQRkDNY/lYDw/yc2/uvE2rOYeBi8EaO0aNZJp7x+mm/yAXw8KWMYC/BGR9xgSsjTmVyBagCAhG1/ObT3ixfe9GAOjPbHavAtDsK5RV641wcbhyKjEYP5P0oHsvgSyH1jYXOo5wrdlDDvD4uKTtPZwQ== X-YMail-OSG: kHqwLNcVM1kdnmI3TZY87q30bmQJhYZHpYAjgQT0Q.AQ4ZgwbRBTDzL7mmittST U38f5sw.oVATbzPlT47QwHVPuhf4Q9.UhGvEQBqXVFV9RFnnyzbrXlh44p2Qfb_kGFb2cmE98NZ5 Q_uwA9Ducc1uw0J0x_xtD..B3dLgCzjL4q32dxC.Euh9BP_phHSKC3VV8Tz70aWyXdrFDgQeqJNd w7mSxi_ZHlZieU3CqWxfAdEvUT67JEH8eBRVo4.5LuuQoBiYu8TdHb62Wwe1lyXWec0H4flzXWr6 FkJeI7Bav1Z0Yx1Ax7faA9GyvEN0X5oAwQFNC88ZDpJaVEWmT.paxwYj4ZFeLY8VYIndGhL60BGX uguqrIC5YdLrojDv1lNG0EsC3OBXIPDpXui8fVDM8fIO.ABsU7eSxAThfpsQ3aADVRZny0Jl4_Gy gUvD6aEWK9hM_tFzYjGcJPDHIy.NIrVeyONmAzUZvddqAQzMJ4JlyVDssKhbWLJYs6dpHzT820pm 5wkoD7zh_og_BASGToSGYk6xk2c90KO58ucZ_tofbCUaomOtX6qp70CB_RJUUfyT6nGH2Jgy_VKs ShFc8cUQ7eXnoJXdKvaj1X5.mSkDZ3W3wk1K01mZOa2N_2HDbrTkn8cI5KIwg2P.dn9yTDNkNa2X VeGw_bg4TqiiO8qLXruBuEubBnmC8inXofzeb427WWzIIvSeVTZ1OAE1ElxUYqUHaxb_PkJtmImM 34223kvEOHRkDoIAOE9yt.tnySXdOVHrGylVfBcMne2sbFHFYaLUOGrxHgDIEeIYAyfKNKBkZbFp FOPbG3vJE9RnPhhOAKPV1HeZIZ52EEX.GqS.g6lyD7.neOz4GqI8T4uHFzQI84PZMXtK85gYoaRR xXN7_CDXM81O90lQgzGKeZ_l_IOSsLB7wMwedVJ9N46PjhMq.89Llq2BU5uCmCV1H4ChxDQEp.MI Pr.ioUPqeF123t3X3rbZCNXXmmXVzb9xTwrZqxhPG8UCVfeiB6lfNoqVtQXF3kHZgIx7ue4eGTFc VrOXcr1oVtzuoueqNDOHhS7lEYs7Mnez76rdir8f2vZk3xBhjXzb1flYj3rmOCuHP2eTZUfAlhFk ZSzn0xt0JQaK8lFvoJvY__cMm6clnWF2JDo0ZCMVby_7yA9_AQI7bY7RkU0jg27LTowvypcuA.7S EFip1GW2QQ6VHGh132BnX17SdwdmVqLl0YE_m7.SsEi4Sr7tNFbQzD4jYhJObE6rpJ9f5Ap.NsnS .2W6iPCNJ6rWUnR.LHZVlp_SGPXLB9l1lAcM2wiLO1XIFpv6IjXrC0BPo8Yv2jwCfhR.9euBOQ8x RGGXLGclIH5dR1iMoP_qdNZUlZrudBMdO5e.rtHABxIbBvzyAkdN9JC.l_6Nsy1c0WLfXnS9PKBR SezLpHZgALNqeEpyONtdjjbhey.nMmgtHLjyP6hvamIShaSIa9n86M1NKqd2Le3n0xrpp51qP_tH r_mzDmyRf6iz26KyvUkuAWSyVR8r4R9eqM8MIb21ZcKqNIReRQIPgG4GYion2kIcmakiHAFgTsy6 ie5V1ic6FLZ112sm.A8HUO6dk5_BwtHDqdP1PyIy1yOS9S3i9aYTVa1P7RcsnTzDCGkpU33n.ZyT QqfJrRIPGRmmcwl854vP4sovLINO_f9qrLtLqzfyp25jZoX0yiUpdFNPPcap88O2Q5R8x.aWj46z LfqKSkwVj7BZOTo2sMGVztPljpeFKfIX00a_5sPHr2wIm68AIiOHftLFbTC.2INj5JE4nuO7Jl6h 9FLnJQtuhucN00_FgEtVs1W0KqSPHIlmpT3jRQMuQbBwtCKfwi_tybGZrBQUfC0IwUFPPv9oN.Y0 F_bBzKrl9Tvl2P4C8rc1RQ9kpbupw6zwZT2RvuIPejwu7iwdiQua_RKL2Diceplpui01joQpYwow DzwyqkGwvKymZnQCYWHGuvp1c1LC2Rue5LOnCE5Q_z0niv6SKht2KTvZabyz7DYvnFxyL8_GktOU hXo.mscgNICEkkGfIEgiCfVRhLdBCVa_kDjBmX4BBZ1vbNyiFVakTtc8ORAt_Zn7p9PB69S6Vl9r k4uXJBLWp57A4VUbNnPNLTW6CGprgiewoyNlLXC0OTqNSjKNJari_bxnLBhT3jftGHb81YoqQMjn e9fG3czHswW_rp3k50LH_h1mXr40NfP4NSxMthiTxTGAaAvuGFrh9DwPv2S_fUkrOKxCRj8wQuUa gpVvXpm_Q8lJRCrIePdxKgVHrrULUErGY0KwtHRS8_6kKJ1fgbmYw.JqMVpAOsjZSciv7wHtPl3C l71HEjhrZrvjLJn2FGghZDg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 28 Feb 2022 19:04:30 +0000 Received: by kubenode512.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 93b09ef7edd5ea69ef32b18fa25b3b85; Mon, 28 Feb 2022 19:04:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: git: 4a864f624a70 - main - vm_pageout: Print a more accurate message to the console before an OOM kill [MFC in time for 13.1?] From: Mark Millard In-Reply-To: Date: Mon, 28 Feb 2022 11:04:28 -0800 Cc: freebsd-current , dev-commits-src-main@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <49BCAD72-1D83-4D85-912F-DF6FD92BB440@yahoo.com> References: <1EF55D96-F7E3-4AA6-A331-782362A70878.ref@yahoo.com> <1EF55D96-F7E3-4AA6-A331-782362A70878@yahoo.com> To: Mark Johnston , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4K6qYy4nfhz4Sgk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aZtlmugj; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Feb-26, at 17:10, Mark Millard wrote: > On 2022-Jan-15, at 07:55, Mark Johnston wrote: >=20 >> On Fri, Jan 14, 2022 at 09:38:56PM -0800, Mark Millard wrote: >>> Thanks. This will allow me to remove part of my personal additions >>> in this area --and my having to explain the misnomer when trying >>> to help someone analyze why they end up with OOM activity so they >>> can figure out what to do about it. >>>=20 >>> There seem to be two separate sources of VM_OOM_SWAPZ. Showing >>> my personal additions for them (just making them explicit in the >>> sequence of messages generated): >>>=20 >>> diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c >>> index 01cf9233329f..280621ca51be 100644 >>> --- a/sys/vm/swap_pager.c >>> +++ b/sys/vm/swap_pager.c >>> @@ -2091,6 +2091,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) >>> 0, 1)) >>> printf("swap blk zone = exhausted, " >>> "increase = kern.maxswzone\n"); >>> + printf("swp_pager_meta_build: swap = blk uma zone exhausted\n"); >>> vm_pageout_oom(VM_OOM_SWAPZ); >>> pause("swzonxb", 10); >>> } else >>> @@ -2121,6 +2122,7 @@ swp_pager_meta_build(vm_object_t object, = vm_pindex_t pindex, daddr_t swapblk) >>> 0, 1)) >>> printf("swap pctrie zone = exhausted, " >>> "increase = kern.maxswzone\n"); >>> + printf("swp_pager_meta_build: swap = pctrie uma zone exhausted\n"); >>> vm_pageout_oom(VM_OOM_SWAPZ); >>> pause("swzonxp", 10); >>> } else >>>=20 >>> Care to comment on the distinctions and why there are two >>> contexts classified as "out of swap space"? Would either >>> one show the swap space as (nearly?) all used in, say, top? >>> Or might one of them still end up looking like a misnomer >>> from just a top (or whatever) display? >>=20 >> Hmm, those cases should likely be changed from "out of swap space" to >> "failed to allocate swap metadata" or something like that. >=20 > The above does not seem to have happened yet in main [so: 14]. >=20 > Will 13.1 get an MFC of 4a864f624a70 in time, possibly with the > above change also in place to fully avoid misnomer reporting > that misleads folks? >=20 > 4a864f624a70 listed: >=20 > MFC after: 2 weeks >=20 > but it has been more than a month. >=20 >> . . . >>=20 >=20 Thanks for the stable/13 MFC as 13ba1d283676. It provides a big improvement over the prior messaging for the OOM kills. For reference, I do still view: + case VM_OOM_SWAPZ: + reason =3D "out of swap space"; + break; as using a confusing misnomer ("swap space") for its message. But, so far as I know, VM_OOM_SWAPZ is a rarity and possibly very difficult to produce. If so, any confusions from the message should also be rare. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Mar 2 02:22:33 2022 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 4DC5B19DA3EB; Wed, 2 Mar 2022 02:22:48 +0000 (UTC) (envelope-from zlei.huang@gmail.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7dF31Ftjz4l4H; Wed, 2 Mar 2022 02:22:47 +0000 (UTC) (envelope-from zlei.huang@gmail.com) Received: by mail-pj1-x102d.google.com with SMTP id bx5so508264pjb.3; Tue, 01 Mar 2022 18:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dF8GjNyhrJygx7QdROuqlz/OYPY28u9QW81FNQZNIH0=; b=dEon5KNtA6m8Vm+ot8JDvUYr7mn4XBsFEeUHc+1B5bQkB4xezaF+lNHp3eZ+raQoS0 duLeacQ8N/TtczVwLNa34XBluBM47PhBmFtoTcguC7t/xFA+F4zvdVLs+mRiBKLamO9/ x2t+HRmvvS5BWgLo1m8UQBdp9ZBQS46fNiSFrN/A/uyHviwWu5nD0YceRG6yyIA5wdwX Esd2Oi2XRb5hwW03aEUj4WYk6lU6/TQGq52GO7haU1fvN/TjfHlkB38Z5g0oTK7KoSEe qfbjudFrDEqYIfzChd6HHYaS1pEMRSiHblwYfqrkMO1mm9qqlVHsbr8Nej4A3HhPyzJO 9RbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dF8GjNyhrJygx7QdROuqlz/OYPY28u9QW81FNQZNIH0=; b=QWEF825u145sE/LrqC0XvrtqRPZyQ7Layj5CpvyHqjwiSk2CxP1JZlV6RHV6v1SGwJ tBwQbYkAUXCCFOZ9v7R1m75nYiToF6BlENrTlAdA5cv09ifB/6h9BvIsyPbo2eyLiIQ7 pwTxXieTCtOf7mFhqIRq94SojYyXCwMQGSOGhRTlEN5BsFpiXrgGT1rbvvBH5lg8tQ4x 4scLpLwFSjfJdSXpCUhIxtrJOHXmvS5ce4ObKkImnR/AzoAUZVxad75AwRgq3X2LbLt9 x+WORIKxZRRuIu+YWSgXSaxbPu9SFb6xNTIEjgUvOQ3ai6gUhlhZB4E9p3wlOTiXeb1D WfkA== X-Gm-Message-State: AOAM531Z3gg2HVgo93N00qHBxt3EMyVRtZ9P/Er2o+UKkTa/VthLo8mq KU9lA1xvfC69HYqsLGMkbhlEpT4SrCEoqAJT X-Google-Smtp-Source: ABdhPJyyJD/1PTDvBB0G4A7iiKl9d1RqIpN8fZ/agq6bFzMtr1V11vNZDtASVQu/R7Xin1cN1Aa3IQ== X-Received: by 2002:a17:902:e88e:b0:150:25e3:739c with SMTP id w14-20020a170902e88e00b0015025e3739cmr24569044plg.13.1646187765902; Tue, 01 Mar 2022 18:22:45 -0800 (PST) Received: from [172.17.252.129] (ns1.oxydns.net. [45.32.91.63]) by smtp.gmail.com with ESMTPSA id j9-20020a056a00234900b004f3b1c23497sm18700478pfj.101.2022.03.01.18.22.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Mar 2022 18:22:45 -0800 (PST) From: Zhenlei Huang Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_783D5F85-39C4-4639-BA1C-DCB831F843AE" 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 13.4 \(3608.120.23.2.7\)) Subject: Re: linux debian jail - network problems Date: Wed, 2 Mar 2022 10:22:33 +0800 In-Reply-To: Cc: freebsd-jail@freebsd.org, freebsd-net@freebsd.org, FreeBSD Current , "Alexander V. Chernikov" To: Sami Halabi References: <8020452A-63EA-4424-8D20-CC9B9397B603@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4K7dF31Ftjz4l4H X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=dEon5KNt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of zleihuang@gmail.com designates 2607:f8b0:4864:20::102d as permitted sender) smtp.mailfrom=zleihuang@gmail.com X-Spamd-Result: default: False [-2.35 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.85)[-0.846]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102d:from]; HTTP_TO_IP(1.00)[]; MLMMJ_DEST(0.00)[freebsd-jail,freebsd-net,freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_783D5F85-39C4-4639-BA1C-DCB831F843AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 1, 2022, at 6:42 PM, Sami Halabi wrote: >=20 > How can I see the netlink wip status ? Sorry it is not currently public visible. FreeBSD's Phabricator is a = tool that is development focused. If you're interested in it, please CC the author Alexander V. Chernikov = . >=20 > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=95=D7=B3, = 25 =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2022, 08:34, =D7=9E=D7=90=D7=AA Sami = Halabi =E2=80=8F>: > Hi, > Thank you for your response.. I wonder if Is it really only netlink = problem? Maybe is or not. I'm not familiar with Linux emulation. You can refer to=20= 1. https://docs.freebsd.org/en/articles/linux-emulation/ = 2. https://wiki.freebsd.org/Linuxulator = > Their are fee problems in the logs.. I dont kbow if they all related = only to netlink (prctl immutable for example).. I also saw = oncompatibilities in socket.c .... >=20 > Btw: I tried to enter the link you sent and it asked for username and = password.. its not public review? >=20 > Sami >=20 > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=95=D7=B3, = 25 =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2022, 04:18, =D7=9E=D7=90=D7=AA = Zhenlei Huang =E2=80=8F>: > Hi, > You can also track the WIP netlink feature, = https://reviews.freebsd.org/D33975 >=20 >> On Feb 25, 2022, at 4:05 AM, Sami Halabi > wrote: >>=20 >> Hi, >> Added Current, maybe will be lucky ;) >>=20 >> Anyone have idea how approach and fix this? >>=20 >> Sami >>=20 >> =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=92=D7=B3, = 22 =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2022, 23:30, =D7=9E=D7=90=D7=AA Sami = Halabi =E2=80=8F>: >> Hi all, >> sorry for the cross post but I need help and I'm not sure where it = hangs. >>=20 >> I create linux jail (debian bullseye) via cbsd. >> the jail is being populated with the debian userland.. >> so far so good... services running (sshd) and I can login to the = jail, I also can update packages and I can install apache httpd and all = works fine (apt install or make from src). >> I also manage to install packages even if their scripts depend on = "ip" command that fails: >> cbsd@j2> ip >> Cannot open netlink socket: Address family not supported by protocol >>=20 >> ifconfig show empty interfaces: >> cbsd@j2> ifconfig >> eth0: flags=3D4163 mtu 1500 >> ether 00:50:56:0a:b3:a0 (Ethernet) >> RX packets 139798314 bytes 12029597009 (11.2 GiB) >> RX errors 0 dropped 0 overruns 0 frame 0 >> TX packets 26879143 bytes 34400160833 (32.0 GiB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >>=20 >> lo0: flags=3D4169 mtu 16384 >> loop (Local Loopback) >> RX packets 28548 bytes 160312960 (152.8 MiB) >> RX errors 0 dropped 0 overruns 0 frame 0 >> TX packets 28548 bytes 160312960 (152.8 MiB) >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >>=20 >> I know linux emulation doesn't implement netlink.. so what I do is = fake the response by replacing /bin/ip by a bash script that prints the = correct IP and fakes some other (needed by packages i Installed): >> #!/bin/bash >> if [ "$1" =3D "-o" ]; then >> echo "1: eth0 inet 192.168.1.2/24 brd = 192.168.1.255 scope global eth0" >> elif [ "$1" =3D "route" ]; then >> if [ "$2" =3D "get" ]; then >> echo "8.8.8.8 via 192.168.1.2 dev eth0 src = 192.168.1.2 " >> else >> echo "default via 192.168.1.2 dev eth0" >> fi >> else >> echo "1: eth0: mtu 1500 qdisc mq = state UP qlen 1000" >> echo " inet 192.168.1.2 /24 brd 192.168.1.255 scope global eth0" >>=20 >>=20 >> still ifconfig shows no IP... its time to say it a regular jail and = *NOT* VNET. >>=20 >> *however* package that pull ips via libraries fail.. >> eg: installed bind916 (name) in the logs I see these errors (relevant = only): >> cbsd@j2> service named start >> Starting domain name service...: namednamed: prctl(PR_SET_DUMPABLE) = failed: Invalid argument >> cbsd@j2> >>=20 >>=20 >> log file shows: >> 22-Feb-2022 23:11:58.705 general: notice: BIND 9 is maintained by = Internet Systems Consortium, >> 22-Feb-2022 23:11:58.705 general: notice: Inc. (ISC), a non-profit = 501(c)(3) public-benefit >> 22-Feb-2022 23:11:58.705 general: notice: corporation. Support and = training for BIND 9 are >> 22-Feb-2022 23:11:58.705 general: notice: available at = https://www.isc.org/support >> 22-Feb-2022 23:11:58.705 general: notice: = ---------------------------------------------------- >> 22-Feb-2022 23:11:58.705 general: info: found 6 CPUs, using 6 worker = threads >> 22-Feb-2022 23:11:58.705 general: info: using 6 UDP listeners per = interface >> 22-Feb-2022 23:11:58.705 general: info: using up to 21000 sockets >> 22-Feb-2022 23:11:58.715 general: info: loading configuration from = '/etc/bind/named.conf' >> 22-Feb-2022 23:11:58.715 general: info: reading built-in trust = anchors from file '/etc/bind/bind.keys' >> 22-Feb-2022 23:11:58.715 general: info: looking for GeoIP2 databases = in '/usr/share/GeoIP' >> 22-Feb-2022 23:11:58.715 general: info: using default UDP/IPv4 port = range: [1024, 65535] >> 22-Feb-2022 23:11:58.715 general: info: using default UDP/IPv6 port = range: [1024, 65535] >> 22-Feb-2022 23:11:58.715 network: info: no IPv6 interfaces found >> 22-Feb-2022 23:11:58.715 general: error: ifiter_getifaddrs.c:79: = unexpected error: >> 22-Feb-2022 23:11:58.715 general: error: getting interface addresses: = getifaddrs: Address family not supported by protocol >> 22-Feb-2022 23:11:58.715 network: warning: not listening on any = interfaces >> *snip* >> *snip* >> 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected = error: >> 22-Feb-2022 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS) = failed: Protocol not available >> 22-Feb-2022 23:11:58.735 general: notice: couldn't add command = channel 127.0.0.1#953: permission denied >> 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected = error: >> 22-Feb-2022 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS) = failed: Protocol not available >> 22-Feb-2022 23:11:58.735 general: notice: couldn't add command = channel 127.0.0.1#953: permission denied >> 22-Feb-2022 23:11:58.735 zoneload: info: managed-keys-zone: loaded = serial 24 >> 22-Feb-2022 23:11:58.735 zoneload: info: zone 0.in-addr.arpa/IN: = loaded serial 1 >> 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected = error: >> 22-Feb-2022 23:11:58.735 general: error: setsockopt(512, IP_RECVTOS) = failed: Protocol not available >> 22-Feb-2022 23:11:58.735 general: error: socket.c:2405: unexpected = error: >> 22-Feb-2022 23:11:58.735 general: error: setsockopt(513, IP_RECVTOS) = failed: Protocol not available >> 22-Feb-2022 23:11:58.745 zoneload: info: zone 255.in-addr.arpa/IN: = loaded serial 1 >> 22-Feb-2022 23:11:58.745 zoneload: info: zone j1.royalshells.com/IN = : loaded serial 2022022106 >> 22-Feb-2022 23:11:58.745 notify: info: zone j1.royalshells.com/IN = : sending notifies (serial 2022022106) >> 22-Feb-2022 23:11:58.745 general: error: socket.c:2405: unexpected = error: >> 22-Feb-2022 23:11:58.745 general: error: setsockopt(514, IP_RECVTOS) = failed: Protocol not available >> 22-Feb-2022 23:11:58.745 zoneload: info: zone localhost/IN: loaded = serial 2 >> 22-Feb-2022 23:11:58.745 general: error: socket.c:2405: unexpected = error: >> 22-Feb-2022 23:11:58.745 general: error: setsockopt(515, IP_RECVTOS) = failed: Protocol not available >> 22-Feb-2022 23:11:58.745 zoneload: info: zone 127.in-addr.arpa/IN: = loaded serial 1 >> 22-Feb-2022 23:11:58.745 general: notice: all zones loaded >> 22-Feb-2022 23:11:58.745 general: notice: running >> 22-Feb-2022 23:11:58.795 general: error: socket.c:2405: unexpected = error: >> 22-Feb-2022 23:11:58.795 general: error: setsockopt(50, IP_RECVTOS) = failed: Protocol not available >> 22-Feb-2022 23:12:58.811 general: error: ifiter_getifaddrs.c:79: = unexpected error: >> 22-Feb-2022 23:12:58.811 general: error: getting interface addresses: = getifaddrs: Address family not supported by protocol >> 22-Feb-2022 23:12:58.811 network: warning: not listening on any = interfaces >>=20 >> Any Idea how to fix this?? >>=20 >> cbsd@j2> named -V >> BIND 9.16.22-Debian (Extended Support Version) >> running on Linux x86_64 3.2.0 FreeBSD 12.3-RELEASE-p1 GENERIC >>=20 >> installing newer versions=20 >>=20 >> I have also problems with dovecot mail package.. but will leave it = for now >>=20 >> Thanks in advance, >> Sami >>=20 >=20 --Apple-Mail=_783D5F85-39C4-4639-BA1C-DCB831F843AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 1, 2022, at 6:42 PM, Sami Halabi <sodynet1@gmail.com> = wrote:

How can I see the netlink wip status = ?

Sorry it is not = currently public visible. FreeBSD's Phabricator is a tool that is = development focused.
If you're interested in it, please CC the = author Alexander V. Chernikov .


=D7=91=D7=AA=D7= =90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=95=D7=B3, 25 =D7=91=D7=A4=D7=91= =D7=A8=D7=B3 2022, 08:34, =D7=9E=D7=90=D7=AA Sami Halabi =E2=80=8F<sodynet1@gmail.com>:
Hi,
Thank you for your response.. I wonder if Is it really only = netlink = problem?

Maybe is or not. I'm not familiar with Linux = emulation. You can refer to 
=
Their are fee problems in the = logs.. I dont kbow if they all related only to netlink (prctl immutable = for example).. I also saw oncompatibilities in socket.c ....

Btw: I tried to enter the link you sent and it asked for = username and password.. its not public review?

Sami

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A = =D7=99=D7=95=D7=9D =D7=95=D7=B3, 25 =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2022, = 04:18, =D7=9E=D7=90=D7=AA Zhenlei Huang =E2=80=8F<zlei.huang@gmail.com>:
Hi,
You can also track the WIP netlink = feature, https://reviews.freebsd.org/D33975

On Feb 25, 2022, at 4:05 AM, Sami Halabi <sodynet1@gmail.com> wrote:

Hi,
Added Current, maybe will be lucky ;)

Anyone have idea how approach and fix this?

Sami

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A = =D7=99=D7=95=D7=9D =D7=92=D7=B3, 22 =D7=91=D7=A4=D7=91=D7=A8=D7=B3 2022, = 23:30, =D7=9E=D7=90=D7=AA Sami Halabi =E2=80=8F<sodynet1@gmail.com>:
Hi all,
sorry for the cross post but I need = help and I'm not sure where it hangs.

I create linux jail (debian bullseye) = via cbsd.
the jail is being populated with the = debian userland..
so far so good... services = running (sshd) and I can login to the jail, I also can update = packages and I can install apache httpd and all works fine (apt = install or make from src).
I also manage to install = packages even if their scripts depend on "ip" command that = fails:
cbsd@j2> ip
Cannot open = netlink socket: Address family not supported by protocol

ifconfig show empty interfaces:
cbsd@j2> ifconfig
eth0: = flags=3D4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 00:50:56:0a:b3:a0 =  (Ethernet)
        RX packets = 139798314  bytes 12029597009 (11.2 GiB)
    =     RX errors 0  dropped 0  overruns 0  frame = 0
        TX packets 26879143 =  bytes 34400160833 (32.0 GiB)
      =   TX errors 0  dropped 0 overruns 0  carrier 0 =  collisions 0

lo0: = flags=3D4169<UP,LOOPBACK,RUNNING,MULTICAST>  mtu 16384
        loop  (Local Loopback)
        RX packets 28548  bytes = 160312960 (152.8 MiB)
        RX = errors 0  dropped 0  overruns 0  frame 0
        TX packets 28548  bytes = 160312960 (152.8 MiB)
        TX = errors 0  dropped 0 overruns 0  carrier 0  collisions = 0

I know linux emulation doesn't implement netlink.. so what I = do is fake the response by replacing /bin/ip by a bash script that = prints the correct IP and fakes some other (needed by packages i = Installed):
#!/bin/bash
if [ "$1" =3D "-o" ]; then
echo "1: eth0 inet = 192.168.1.2/24 brd = 192.168.1.255 scope global eth0"
elif [ "$1" =3D "route" = ]; then
        if [ "$2" =3D "get" ]; = then
              =   echo "8.8.8.8 via  192.168.1.2   dev eth0  src  192.168.1.2  "
        else
                echo = "default via  192.168.1.2   dev eth0"
    =     fi
else
echo "1: eth0: = <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen = 1000"
echo "  inet  192.168.1.2  /24 brd  192.168.1.255 scope global eth0"


still ifconfig shows no IP... its time to say it a regular = jail and *NOT* VNET.

*however* package that pull ips via libraries = fail..
eg: installed bind916 (name) in the logs I = see these errors (relevant only):
cbsd@j2> = service named start
Starting domain name service...: = namednamed: prctl(PR_SET_DUMPABLE) failed: Invalid argument
cbsd@j2>


log = file shows:
22-Feb-2022 23:11:58.705 general: = notice: BIND 9 is maintained by Internet Systems Consortium,
22-Feb-2022 23:11:58.705 general: notice: Inc. (ISC), a = non-profit 501(c)(3) public-benefit
22-Feb-2022 = 23:11:58.705 general: notice: corporation.  Support and training = for BIND 9 are
22-Feb-2022 23:11:58.705 general: notice: = available at https://www.isc.org/support
22-Feb-2022 = 23:11:58.705 general: notice: = ----------------------------------------------------
22-Feb-2022 23:11:58.705 general: info: found 6 CPUs, using 6 = worker threads
22-Feb-2022 23:11:58.705 general: info: = using 6 UDP listeners per interface
22-Feb-2022 = 23:11:58.705 general: info: using up to 21000 sockets
22-Feb-2022 23:11:58.715 general: info: loading configuration = from '/etc/bind/named.conf'
22-Feb-2022 23:11:58.715 = general: info: reading built-in trust anchors from file = '/etc/bind/bind.keys'
22-Feb-2022 23:11:58.715 general: = info: looking for GeoIP2 databases in '/usr/share/GeoIP'
22-Feb-2022 23:11:58.715 general: info: using default = UDP/IPv4 port range: [1024, 65535]
22-Feb-2022 = 23:11:58.715 general: info: using default UDP/IPv6 port range: [1024, = 65535]
22-Feb-2022 23:11:58.715 network: info: no IPv6 = interfaces found
22-Feb-2022 23:11:58.715 general: error: = ifiter_getifaddrs.c:79: unexpected error:
22-Feb-2022 = 23:11:58.715 general: error: getting interface addresses: getifaddrs: = Address family not supported by protocol
22-Feb-2022 = 23:11:58.715 network: warning: not listening on any interfaces
*snip*
*snip*
22-Feb-2022 23:11:58.735 general: = error: socket.c:2405: unexpected error:
22-Feb-2022 = 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS) failed: Protocol = not available
22-Feb-2022 23:11:58.735 general: notice: = couldn't add command channel 127.0.0.1#953: permission denied
22-Feb-2022 23:11:58.735 general: = error: socket.c:2405: unexpected error:
22-Feb-2022 = 23:11:58.735 general: error: setsockopt(50, IP_RECVTOS) failed: Protocol = not available
22-Feb-2022 23:11:58.735 general: notice: = couldn't add command channel 127.0.0.1#953: permission denied
22-Feb-2022 23:11:58.735 zoneload: info: managed-keys-zone: = loaded serial 24
22-Feb-2022 23:11:58.735 zoneload: info: = zone 0.in-addr.arpa/IN: loaded serial 1
22-Feb-2022 = 23:11:58.735 general: error: socket.c:2405: unexpected error:
22-Feb-2022 23:11:58.735 general: error: setsockopt(512, = IP_RECVTOS) failed: Protocol not available
22-Feb-2022 = 23:11:58.735 general: error: socket.c:2405: unexpected error:
22-Feb-2022 23:11:58.735 general: error: setsockopt(513, = IP_RECVTOS) failed: Protocol not available
22-Feb-2022 = 23:11:58.745 zoneload: info: zone 255.in-addr.arpa/IN: loaded serial = 1
22-Feb-2022 23:11:58.745 zoneload: info: zone j1.royalshells.com/IN: = loaded serial 2022022106
22-Feb-2022 23:11:58.745 notify: = info: zone j1.royalshells.com/IN: sending notifies (serial = 2022022106)
22-Feb-2022 23:11:58.745 general: error: = socket.c:2405: unexpected error:
22-Feb-2022 23:11:58.745 = general: error: setsockopt(514, IP_RECVTOS) failed: Protocol not = available
22-Feb-2022 23:11:58.745 zoneload: info: zone = localhost/IN: loaded serial 2
22-Feb-2022 23:11:58.745 = general: error: socket.c:2405: unexpected error:
22-Feb-2022= 23:11:58.745 general: error: setsockopt(515, IP_RECVTOS) failed: = Protocol not available
22-Feb-2022 23:11:58.745 zoneload: = info: zone 127.in-addr.arpa/IN: loaded serial 1
22-Feb-2022 = 23:11:58.745 general: notice: all zones loaded
22-Feb-2022 = 23:11:58.745 general: notice: running
22-Feb-2022 = 23:11:58.795 general: error: socket.c:2405: unexpected error:
22-Feb-2022 23:11:58.795 general: error: setsockopt(50, = IP_RECVTOS) failed: Protocol not available
22-Feb-2022 23:12:58.811 general: error: = ifiter_getifaddrs.c:79: unexpected error:
22-Feb-2022 = 23:12:58.811 general: error: getting interface addresses: getifaddrs: = Address family not supported by protocol
22-Feb-2022 23:12:58.811 network: warning: not listening on = any interfaces

Any Idea how to fix this??

cbsd@j2> named -V
BIND 9.16.22-Debian (Extended Support Version) = <id:59bfaba>
running on Linux x86_64 3.2.0 FreeBSD = 12.3-RELEASE-p1 GENERIC

installing = newer versions 

I have also problems with dovecot mail package.. but will = leave it for now

Thanks in advance,
Sami



= --Apple-Mail=_783D5F85-39C4-4639-BA1C-DCB831F843AE-- From nobody Thu Mar 3 20:06:58 2022 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 B7A5119E6857 for ; Thu, 3 Mar 2022 20:07:10 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K8hpk1JLcz3H6h for ; Thu, 3 Mar 2022 20:07:10 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd36.google.com with SMTP id c14so7045456ioa.12 for ; Thu, 03 Mar 2022 12:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=p8SSqkxcgFwcaWp7PkRKJf1y7WFriMwT8HrQEBHu+ZY=; b=oV3dnDvUqvhXDVKle/rCQlxo0fvgyW4FrHw/i6WT8Bztc2h+0PkTQjn+K3oqc4GEUl 7k0pdyBNvH6nXzYDxvwIR0sjyfpovQLces7Yqt5oQjvbf1/gRlNVvfuojC+uiCRjsTt/ 83y70lDYMqLqHqq6jWpdTDNoGtEZQmKzm57nGt4sDNRT28JxhFA2cNOtK/XivFPUeAho hnp1vROrItgOxcy/ghMhMqCi6dlAgRU+aLcM3oWTGUmXgYWrKVuQo0/eWUQ7x5BAKiAm RS5scMAkP0aVhYUB7+LRXzNOKkOPifqGcJPyoqmoxj5lFZ1NvOzB2bZfwXKrfLbffX2D /B5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=p8SSqkxcgFwcaWp7PkRKJf1y7WFriMwT8HrQEBHu+ZY=; b=L75iEBd01rhk4xMBkGGZtNv35RbE3ypuKinFanjA84FEm2GMieYrAJyACqwzBp8oEI nr8HqkbqGo/uaUOulbdvfj71Scr/h+PICW/R2kdKTviA5+4sZ7ovvszQUGHqqPD8+7x7 yjNxHTenLV2GYWgCurx1DTb12bJFjxXoto9lqlNy/fMsFqKxp4AIc4b5skwiHULk6UA+ mA1C5l63eTCJkqBV4zrK1s3/CBBsrT5uS2/OwiweozscMhJIZPOJo01T5xuHLnB7Zy/p heRv+2RvOJJfTWfyNwRoYTdXqquWVbNA2Z1ZRKMEWpNklURRWsG3sC9Yf8tF3BetKyrM V0mg== X-Gm-Message-State: AOAM533KToC/jttTQjtt0Cyjg0T3b0ztiMqPpyn2mzJ6cHWVddfysiP2 CGaq0/9aw7M8EqtSo5MPT9pp5GbAR6BfbOzO53jMw/af/MUD3tMo X-Google-Smtp-Source: ABdhPJweSUxHfwAi1hvjg+i/LxPfxsbHxswPYh+ZaskHXvpIxDNTRfzoFifpbfhu2rWx7IXxAukUt+8iNlGjmVy8hnU= X-Received: by 2002:a05:6602:2dc6:b0:645:13e4:cc2e with SMTP id l6-20020a0566022dc600b0064513e4cc2emr13947669iow.54.1646338029350; Thu, 03 Mar 2022 12:07:09 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Michael Schuster Date: Thu, 3 Mar 2022 21:06:58 +0100 Message-ID: Subject: CURRENT doesn't recognise synaptics touchpad To: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="0000000000006b722305d955f170" X-Rspamd-Queue-Id: 4K8hpk1JLcz3H6h X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=oV3dnDvU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::d36 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.978]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d36:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000006b722305d955f170 Content-Type: text/plain; charset="UTF-8" Hi all, I have another issue with my recent re-installation to Current: touchpad support seems to have vanished. I know it works because the keyboard lights up when I touch it, it also works under linux (dual-boot), and it worked with the previous installation of FreeBSD, where I installed iichid (and others, I guess) from the sources. I've been searching high and low for things to test or set, with no visible success: - create an /etc/X11/xorg.conf - add or remove various settings from /boot/loader.conf I have libinput and xf86-input-libinput installed. TIA for all and any advice/pointers/RTFMs. cheers Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' --0000000000006b722305d955f170 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I have another issue with my recent re-installation t= o Current: touchpad support seems to have vanished. I know it works because= the keyboard lights up when I touch it, it also works under linux (dual-bo= ot), and it worked with the previous installation of FreeBSD, where I insta= lled iichid (and others, I guess) from the sources.
=

I've been searching high and low= for things to test or set, with no visible success:
- create an /etc/X11/xorg.conf
- add or remove va= rious settings from /boot/loader.conf

I have libinput and xf86-input-libinput installed.

TIA for all and any advice/poi= nters/RTFMs.

cheers
Michael
--
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'
--0000000000006b722305d955f170-- From nobody Fri Mar 4 14:36:16 2022 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 5249519F86A7 for ; Fri, 4 Mar 2022 14:36:24 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K99Qb6Gnhz3MDB for ; Fri, 4 Mar 2022 14:36:23 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-ej1-x631.google.com with SMTP id r13so17932589ejd.5 for ; Fri, 04 Mar 2022 06:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:from :subject:content-transfer-encoding; bh=/7KpEosJGc/+jIgcVgJetmkT38TRZr7SOhYCf+WJJjY=; b=Rc5IxfRe+1Xm/SI8X4U6yYmPJi5pQEZLoBHb8jTHWmZflYLvedghYMYbnbZtI7FufH Oxt654K3kKHXY3Nna0XU6I91jpPOwkPvwcUWUQmE0tDp3os+E/jL7oSzdzJyVVXbB5oQ VeYFO+LkmnRGIByjhsJSbzLeAsejek/YeuHyGr6TfknUFxfxb3crG8YODvoN2Y7UXwlm 82ri/Z8ciBH6eyeIdqfIBZYBRJalDms3InoCWLk37XmAI962eq8k1CHQmol85RlaxDMd 7N9EzfTz/NMGT7VOHHp+fDq2uUYMdnQ0qv6FJAaHaBcSLQtn84VrtTyHybpoInFIGKOz EVcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:content-transfer-encoding; bh=/7KpEosJGc/+jIgcVgJetmkT38TRZr7SOhYCf+WJJjY=; b=SauHeVwhTX2aihKWTmeSSMhDMOljeAeveX0N+o9C3b6nHzVFnjeXEEBt+7Tgmq1d7j Kfd9vdFQvCdYibIEpTPsGLXcPlACdOv0ywkSdSy7xbpv/hs2HyzjnBMcAtlMrE7zFd3Q iv9tiBXf6YQ9bXL7hbJv3CgfwGb418ebcBikc22nFASBivhSkfO26J6tP1KGkAeHQ3mu YCwmTb0inUQMp4C0Z0Uvx6KeYXCse+PuVd3qrnMVyH6TuJNZ/eynNjcsk7vbKCEOsXWG pkzbb9TchK7rQz2EGQYZUYF98o+a302nL21Uj466G3N6ZzZe+TOWRx7iEwp2+1gnjhr8 WUsQ== X-Gm-Message-State: AOAM531XGWxEqHKlSoy7l2bHdXpQfih84WwF3iSIEVVwQ1GUUg1TP+Sx CQYJ+Fw2CiM2aoaVU506weYVyvrOIxI= X-Google-Smtp-Source: ABdhPJywLs5KUs7wtG0leGgoaXUYRuub2Vzw0vUM2NsgmDzSmqAE4IepI5yTEOF2T0I//FbUAkAyZw== X-Received: by 2002:a17:906:16cc:b0:6ce:e607:ff02 with SMTP id t12-20020a17090616cc00b006cee607ff02mr30315975ejd.418.1646404582481; Fri, 04 Mar 2022 06:36:22 -0800 (PST) Received: from [192.168.1.24] (85-147-130-226.cable.dynamic.v4.ziggo.nl. [85.147.130.226]) by smtp.gmail.com with ESMTPSA id e12-20020a056402190c00b0041615cd434csm62271edz.60.2022.03.04.06.36.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Mar 2022 06:36:21 -0800 (PST) Message-ID: Date: Fri, 4 Mar 2022 15:36:16 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: FreeBSD Current From: Johan Hendriks Subject: vnet jails loose network connectivity Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4K99Qb6Gnhz3MDB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Rc5IxfRe; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of johhendriks@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=johhendriks@gmail.com X-Spamd-Result: default: False [-3.93 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.93)[-0.926]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello all, i use jails for some testing, but i can not seem to make it stable. I use vnet jails with a bridge but when i put some load on it, some jails loose there network connectivity. My setup is as follows, haproxy internal IP 10.233.185.20 using binat to make it Public accessable. Then a varnish jail, and two web servers al on the 10.233.185.x range. If i give it a little load with hey (hey -h2 -n 10 -c 20 -z 60s https://wp.test.nl) than within the test the haproxy jail is not reachable anymore it is not pingable from the host machine, and from the other jails. restarting the jails solves it, if i leave the system alone for some time i saw the varnish jail become unresponsive. If i do a tcpdump on the epair${name}a interface i do see the packages from the host machine to the jail but the jail itself is not reachable. There is nothing in the logs from the host and the jail itself, i can ping the jails ip adres from the jail itself. I do not think i have a special setup, but i could be doing something wrong. my jail.conf # Global settings applied to all jails. $domain = "test.nl"; $subdomain = ""; exec.start = "/bin/sh /etc/rc"; exec.stop = "/bin/sh /etc/rc.shutdown"; exec.clean; mount.fstab = "/storage/jails/$name.fstab"; exec.system_user  = "root"; exec.jail_user    = "root"; mount.devfs; sysvshm="new"; sysvsem="new"; allow.raw_sockets; allow.set_hostname = 0; allow.sysvipc; enforce_statfs = "2"; devfs_ruleset     = "11"; path = "/storage/jails/${name}"; host.hostname = "${name}${subdomain}.${domain}"; # Networking $uplinkdev        = "vtnet1"; $epid             = "${ip}"; $subnet           = "10.233.185."; $cidr             = "/24"; $ipv4_addr        = "${subnet}${ip}${cidr}"; vnet; vnet.interface    = "vnet0"; $epair=epair${ip}; vnet; #vnet.interface    = "${epair}b";  # default vnet interface exec.prestart     = "ifconfig bridge0 > /dev/null 2>&1 || ( ifconfig bridge0 create up && ifconfig bridge0 addm $uplinkdev )"; exec.prestart    += "ifconfig ${epair} create up description jail_${name}   || echo 'Skipped creating epair (exists?)'"; exec.prestart    += "ifconfig bridge0 addm ${epair}a           || echo 'Skipped adding bridge member (already member?)'"; exec.created      = "ifconfig ${epair}b name vnet0"; exec.start        = "/bin/sh /etc/rc"; exec.consolelog   = "/var/log/jail/$name.test.nl"; exec.stop         = "/bin/sh /etc/rc.shutdown"; exec.poststop     = "ifconfig bridge0 deletem ${epair}a"; exec.poststop    += "ifconfig ${epair}a destroy"; varnish01 {     $ip = 16;     mount.fstab = "";     path = "/storage/jails/${name}"; } web01 {     $ip = 18; } web02 {     $ip = 19; } haproxy {     $ip = 20;     mount.fstab = "";     path = "/storage/jails/${name}"; } My ifconfig bridge0: flags=8843 metric 0 mtu 1500     ether 58:9c:fc:10:ff:82     inet 10.233.185.1 netmask 0xffffff00 broadcast 10.233.185.255     id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15     maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200     root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0     member: epair20a flags=143             ifmaxaddr 0 port 13 priority 128 path cost 2000     member: epair19a flags=143             ifmaxaddr 0 port 53 priority 128 path cost 2000     member: epair18a flags=143             ifmaxaddr 0 port 48 priority 128 path cost 2000     member: epair16a flags=143             ifmaxaddr 0 port 28 priority 128 path cost 2000     groups: bridge     nd6 options=9 epair16a: flags=8963 metric 0 mtu 1500     description: jail_varnish01     options=8     ether 02:76:32:8e:0e:0a     groups: epair     media: Ethernet 10Gbase-T (10Gbase-T )     status: active     nd6 options=29 epair18a: flags=8963 metric 0 mtu 1500     description: jail_web01     options=8     ether 02:6d:be:b8:36:0a     groups: epair     media: Ethernet 10Gbase-T (10Gbase-T )     status: active     nd6 options=29 epair19a: flags=8963 metric 0 mtu 1500     description: jail_web02     options=8     ether 02:54:fd:77:9a:0a     groups: epair     media: Ethernet 10Gbase-T (10Gbase-T )     status: active     nd6 options=29 epair20a: flags=8963 metric 0 mtu 1500     description: jail_haproxy     options=8     ether 02:f8:58:06:78:0a     groups: epair     media: Ethernet 10Gbase-T (10Gbase-T )     status: active     nd6 options=29 This is on both 13-STABLE and 14-HEAD. From nobody Fri Mar 4 18:46:41 2022 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 EDA3A19E1F31 for ; Fri, 4 Mar 2022 18:46:53 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K9Gzd1B22z4hf1 for ; Fri, 4 Mar 2022 18:46:53 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd2b.google.com with SMTP id q8so10551891iod.2 for ; Fri, 04 Mar 2022 10:46:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hNVZAgIPz4oGCHQYce5V4SnsRRW9JOg3tG8AtU6OM9g=; b=Wye0WWbsvTBrdxe8UwC57W6oDw4SivOKz5piU6/B48V0YkM3gnqXW1bb5IqP2Jg/P9 oTf+bA8rGGgpDRQacYaHG7xPNdpYfO2JQj1vrxkurCEdAd2/iTmEQJGTD/d7SPo8akPl oGNgSRU+T8iUCCeOmsrqXjMReU03dE0fIqmiBk7wXnSjZW4GwOjeEJE0+L5q8F+m+3XF 0R6cA3zkuWOM/qDWVzb9iNGTbQin5kCfXSs+qZ0GRX2AcguaHSKJ1vz4Y6Z8rIesFr6Q SROecrx5mgAHspLVjep95J3KS8Z3gVBL7z+yC+CagFfJXjzfWh1dt86b4oEdlpwkLkMl WJVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hNVZAgIPz4oGCHQYce5V4SnsRRW9JOg3tG8AtU6OM9g=; b=VtCLCJzySWTUM7GB3GBO0QWlGIo53XZ0vHFR/XZMtXGR+XfETUiPm4ZReVOez5ZHsR ZscJcuR8feuJe4hXZLfBZ2HQF8ZfCHdTd/vkOICpRRtKJxtAYvoW0iqKx48OXlatLoAf Jx/8kvma0jmBxCOZWP6F022cqwLI+Fc/savGUYtlDkOH6f4JNRL8HGGqq+tlp89h5Ywr TNSFl91Dk2rzAaVZ6Pwpy4uUnKsOif9Ba2QXaQdrnFAty0KsCdVSICkmJXtiKXje2Ddy BbOdMPLEMnWkjfNhOLotpP00YJYYLm2HUYgNMBZjAEUN5YNgDTsMLogGvLAjcNPxA6fz L6Nw== X-Gm-Message-State: AOAM532knUn12KTD1aFQbV3dLf2PkYuWFRMfCg/kooyLl1zvHGc5PA4q HS2yIQLO0WzKg2Y6VASqvH/CqxfxHe8JTFqayPnSy2g1syZw3R7B X-Google-Smtp-Source: ABdhPJzu+fGcXiTEBrCSZGUSlWA2DcZXcoaY+ivAoxgi3nWEW38HN7J06lwBa/QVfRRsgL6LiU/gdmgXX/twRDbS2v8= X-Received: by 2002:a05:6602:1403:b0:63d:715a:269b with SMTP id t3-20020a056602140300b0063d715a269bmr4627iov.188.1646419612131; Fri, 04 Mar 2022 10:46:52 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Michael Schuster Date: Fri, 4 Mar 2022 19:46:41 +0100 Message-ID: Subject: solved: [Re: CURRENT doesn't recognise synaptics touchpad] To: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="00000000000021e92f05d968f053" X-Rspamd-Queue-Id: 4K9Gzd1B22z4hf1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Wye0WWbs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::d2b as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.58 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.58)[-0.582]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2b:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000021e92f05d968f053 Content-Type: text/plain; charset="UTF-8" Hi all, sometimes, reading documentation does help :-) I followed the instructions at https://github.com/wulf7/iichid and added this: ig4_load="YES" iicbus_load="YES" to the already present iichid_load="YES" in /boot/loader.conf, and now touchpad works. cheers! Michael On Thu, Mar 3, 2022 at 9:06 PM Michael Schuster wrote: > Hi all, > > I have another issue with my recent re-installation to Current: touchpad > support seems to have vanished. I know it works because the keyboard lights > up when I touch it, it also works under linux (dual-boot), and it worked > with the previous installation of FreeBSD, where I installed iichid (and > others, I guess) from the sources. > > I've been searching high and low for things to test or set, with no > visible success: > - create an /etc/X11/xorg.conf > - add or remove various settings from /boot/loader.conf > > I have libinput and xf86-input-libinput installed. > > TIA for all and any advice/pointers/RTFMs. > > cheers > Michael > -- > Michael Schuster > http://recursiveramblings.wordpress.com/ > recursion, n: see 'recursion' > -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' --00000000000021e92f05d968f053 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

sometimes, reading documentation doe= s help :-)
I followed the instructions at https://github.com/wulf7/iichid an= d added this:

=C2=A0= =C2=A0=C2=A0 ig4_load=3D"YES"
=C2=A0=C2=A0=C2=A0 iicbus_load= =3D"YES"

to = the already present

=C2=A0=C2=A0=C2=A0 iichid_load=3D"YES"
in /boot/loader.conf, and now touchpad works= .

cheers!
Mi= chael

On Thu, Mar 3, 2022 at 9:06 PM Michael Schuster <michaelsprivate@gmail.com> wrote:
=
Hi al= l,

I have another issue with my recent re-installation to Current: tou= chpad support seems to have vanished. I know it works because the keyboard = lights up when I touch it, it also works under linux (dual-boot), and it wo= rked with the previous installation of FreeBSD, where I installed iichid (a= nd others, I guess) from the sources.

I've been searching high and low for things to test or set, with no vi= sible success:
- create an /etc/X11/xorg.conf
- add or remove various setti= ngs from /boot/loader.conf

I have libinput and xf86-input-libinput ins= talled.

TIA for all and any advice/pointers/RTFMs.

cheers
Mic= hael
--
recursion= , n: see 'recursion'


--
recursion, n: see 'recursion'=
--00000000000021e92f05d968f053-- From nobody Fri Mar 4 22:51:32 2022 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 D0C7B19EC338 for ; Fri, 4 Mar 2022 22:51:40 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K9NQ40SX6z3pKm for ; Fri, 4 Mar 2022 22:51:39 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 224MpWu6018135; Fri, 4 Mar 2022 14:51:32 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 224MpWE6018134; Fri, 4 Mar 2022 14:51:32 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202203042251.224MpWE6018134@gndrsh.dnsmgr.net> Subject: Re: CURRENT doesn't recognise synaptics touchpad In-Reply-To: To: Michael Schuster Date: Fri, 4 Mar 2022 14:51:32 -0800 (PST) CC: FreeBSD CURRENT X-Mailer: ELM [version 2.4ME+ PL121h (25)] 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4K9NQ40SX6z3pKm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-1.95 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.85)[-0.847]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > Hi all, > > I have another issue with my recent re-installation to Current: touchpad > support seems to have vanished. I know it works because the keyboard lights > up when I touch it, it also works under linux (dual-boot), and it worked > with the previous installation of FreeBSD, where I installed iichid (and > others, I guess) from the sources. > > I've been searching high and low for things to test or set, with no visible > success: > - create an /etc/X11/xorg.conf > - add or remove various settings from /boot/loader.conf > > I have libinput and xf86-input-libinput installed. > > TIA for all and any advice/pointers/RTFMs. I do recall someplace along not to distant past reading some commits that indicated changes to defaults with respected to the synaptic touch pad, some time in the last year or year and a half, not sure how old your prior install was.... > > cheers > Michael > -- > Michael Schuster > http://recursiveramblings.wordpress.com/ > recursion, n: see 'recursion' -- Rod Grimes rgrimes@freebsd.org From nobody Sat Mar 5 11:16:04 2022 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 908CB1A04ED1 for ; Sat, 5 Mar 2022 11:16:13 +0000 (UTC) (envelope-from SRS0=ngnO=TQ=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 4K9hx82s7Pz3pF5 for ; Sat, 5 Mar 2022 11:16:12 +0000 (UTC) (envelope-from SRS0=ngnO=TQ=klop.ws=ronald-lists@realworks.nl) Date: Sat, 5 Mar 2022 12:16:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1646478964; 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=jEBTy9soQIW1/FJPoko3xOt4Rwv3O6E+av46SDNuyN4=; b=ImiTRsQnP8mNWMjVYoL+3ElEp/Pr7gy1IA/CPmOgz6hffhOLVUAYHMW67r0ytGPLUvTbE9 ooK9aa5zvdcj/jq0ZU+WBkuKcDWUCCZA3jNn+0dL48FMKIPAWoIp4St67qhIIDD4pg9l+l h7kPl6VlHBQ/x7hjqOiefh7xjt6mhIRJujcv8mVdIBV6s3WJ0ortAfWzCFS6T6pabgFJGT 9sVwTB7bN/Mt5UnuKXsK2iw3WZ8n/p2kYqrFKxcTcb7n5tQ48r1n5stxGRscGdRr0kJGjl AOQ/HiIcnZZzbNxTznJbn1OsLgLDrdsOn0jI+8gsuuUSAeVBFAYg6nzAEUxLuA== From: Ronald Klop To: FreeBSD Current Message-ID: <1716388080.66.1646478964882@mailrelay> Subject: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28) 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_65_2019188658.1646478964747" X-Mailer: Realworks (599.209.9d862f3) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4K9hx82s7Pz3pF5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=ImiTRsQn; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=ngnO=TQ=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=ngnO=TQ=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-1.37 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.81)[0.805]; NEURAL_HAM_LONG(-1.00)[-0.996]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=ngnO=TQ=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=ngnO=TQ=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_65_2019188658.1646478964747 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Repeated panics on 14-CURRENT/aarch64. This happens e.g. when the nigthly backup is started. # uname -a FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-5f702d6d9a: Mon Feb 28 06:12:48 CET 2022 ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64 It was stable with all kernels until (and including) "FreeBSD 14.0-CURRENT #21 main-e11ad014d1-dirty: Sat Feb 5 00:09:08 CET 2022". It runs ZFS-on-root via an USB disk. No other FS involved. # gpart show => 40 1953458096 da0 GPT (931G) 40 102400 1 efi (50M) 102440 8388608 2 freebsd-swap (4.0G) 8491048 1944967088 3 freebsd-zfs (927G) Output on serial console: x0: ffffa000059c1380 x1: ffffa000059b1600 x2: 3 x3: ffffa001862779a0 x4: 0 x5: 9438238792a1a x6: d217e9df58308 x7: 14 x8: ffffa000059c1398 x9: 1 x10: ffffa000059b1600 x11: 2 x12: 1 x13: f2557a42c5b0f240 x14: 1013e6b85a8ecbe4 x15: 24f981889f30 x16: ffff4afedeb89cb8 x17: fffffffffffffff2 x18: ffff0000fe666800 (g_ctx + fcfa6a54) x19: 0 x20: ffff0000fec41000 (g_ctx + fd581254) x21: 3 x22: ffff0000419bb090 (g_ctx + 402fb2e4) x23: ffff000000c09bb7 (lockstat_enabled + 0) x24: 180 x25: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28) x26: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28) x27: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28) x28: 0 x29: ffff0000fe666800 (g_ctx + fcfa6a54) sp: ffff0000fe666800 lr: ffff00000154ca38 (zio_dva_throttle + 13c) elr: ffff00000154ca80 (zio_dva_throttle + 184) spsr: 20000045 far: 1f24979f8000 panic: Unknown kernel exception 0 esr_el1 2000000 cpuid = 2 time = 1646433952 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 do_el1h_sync() at do_el1h_sync+0x184 handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0x2000000 zio_dva_throttle() at zio_dva_throttle+0x184 zio_execute() at zio_execute+0x58 KDB: enter: panic [ thread pid 0 tid 100128 ] Stopped at kdb_enter+0x44: undefined f901c11f db> I'm going to build a newer kernel to see if the problem persists. I can keep the current kernel to reproduce this if needed. Regards, Ronald. ------=_Part_65_2019188658.1646478964747 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Repeated panics on 14-CURRENT/aarch64. This happens e.g. when the nigthly backup is started. 
# uname -a
FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-5f702d6d9a: Mon Feb 28 06:12:48 CET 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64

It was stable with all kernels until (and including) "FreeBSD 14.0-CURRENT #21 main-e11ad014d1-dirty: Sat Feb  5 00:09:08 CET 2022".

It runs ZFS-on-root via an USB disk. No other FS involved. 
# gpart show
=>        40  1953458096  da0  GPT  (931G)
          40      102400    1  efi  (50M)
      102440     8388608    2  freebsd-swap  (4.0G)
     8491048  1944967088    3  freebsd-zfs  (927G)


Output on serial console: 
x0: ffffa000059c1380                                                                                                       
  x1: ffffa000059b1600                                                                                                              
  x2:                3                                                                                                              
  x3: ffffa001862779a0                                                                                                              
  x4:                0        
  x5:    9438238792a1a
  x6:    d217e9df58308
  x7:               14
  x8: ffffa000059c1398
  x9:                1
 x10: ffffa000059b1600
 x11:                2
 x12:                1
 x13: f2557a42c5b0f240
 x14: 1013e6b85a8ecbe4
 x15:     24f981889f30
 x16: ffff4afedeb89cb8
 x17: fffffffffffffff2
 x18: ffff0000fe666800 (g_ctx + fcfa6a54)
 x19:                0
 x20: ffff0000fec41000 (g_ctx + fd581254)
 x21:                3
 x22: ffff0000419bb090 (g_ctx + 402fb2e4)
 x23: ffff000000c09bb7 (lockstat_enabled + 0)
 x24:              180
 x25: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x26: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x27: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x28:                0
 x29: ffff0000fe666800 (g_ctx + fcfa6a54)
  sp: ffff0000fe666800
  lr: ffff00000154ca38 (zio_dva_throttle + 13c)
 elr: ffff00000154ca80 (zio_dva_throttle + 184)
spsr:         20000045
 far:     1f24979f8000
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 2
time = 1646433952
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x184
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
zio_dva_throttle() at zio_dva_throttle+0x184
zio_execute() at zio_execute+0x58
KDB: enter: panic
[ thread pid 0 tid 100128 ]
Stopped at      kdb_enter+0x44: undefined       f901c11f
db>
I'm going to build a newer kernel to see if the problem persists. I can keep the current kernel to reproduce this if needed.

Regards,
Ronald. ------=_Part_65_2019188658.1646478964747-- From nobody Sat Mar 5 15:09:17 2022 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 D158D1A0F02E for ; Sat, 5 Mar 2022 15:09:20 +0000 (UTC) (envelope-from SRS0=ngnO=TQ=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 4K9p674ZpPz4n0d for ; Sat, 5 Mar 2022 15:09:19 +0000 (UTC) (envelope-from SRS0=ngnO=TQ=klop.ws=ronald-lists@realworks.nl) Date: Sat, 5 Mar 2022 16:09:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1646492957; 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=QVxOGVjXQPW5MO+EeB6TfHv3veL5QnxIBGVZeOFkCQE=; b=nCRP0vqkDW1UtqUaeb2cB0ANQvwNcD8eehTvHjuTvz1Q3qAkQ0SAWfNNIzYiiwUgdNFlZI qSl2CT4JkAYisXJ07x4/+G4C0K/OkuQAd/foZofse/obSDINHudEipOhqAI/PtPN9X3D0M SAZZB+iN1LkpfcCAX22IsQb0xjI844QAzmC9a04rwZXrsDUKP/30NT6YuP0OtbinpxDgfg 9MpT6Ik/1ytZYpb0C61lJSys106gHQB508W3b7j7qt5SUP/E6stt6O8FCeOb+xvbXnO1sx Joh88IiLCm7lHSTiROjcFsi9PwYp3aC7IffjpvR2NupMyzNYldLyKU6kase/4Q== From: Ronald Klop To: FreeBSD Current Message-ID: <989767310.86.1646492957581@mailrelay> In-Reply-To: <1716388080.66.1646478964882@mailrelay> References: <1716388080.66.1646478964882@mailrelay> Subject: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) 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_85_417069800.1646492957521" X-Mailer: Realworks (599.209.9d862f3) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4K9p674ZpPz4n0d X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=nCRP0vqk; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=ngnO=TQ=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=ngnO=TQ=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.13 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.93)[-0.926]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=ngnO=TQ=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=ngnO=TQ=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_85_417069800.1646492957521 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Another panic while building world/kernel. Different panic message and trace. x0: 1f5e152c32cc x1: ffff0000b630a000 (g_ctx + b4c4a254) x2: 1 x3: 2e x4: ffffa000bb46d600 x5: 0 x6: 0 x7: ffff000000f05104 (has_pan + 0) x8: 1 x9: 809c227c x10: bd x11: 40 x12: 0 x13: 1 x14: 1782f000 x15: 1001 x16: 1782f003 x17: 1f5e957392f0 x18: ffff00010719e630 (next_index + 2cac528) x19: ffff00010719e768 (next_index + 2cac660) x20: 1 x21: ffff0000b630a000 (g_ctx + b4c4a254) x22: 1 x23: ffffffbf x24: ffff00010719e758 (next_index + 2cac650) x25: ffffa00026cdd160 x26: 1 x27: ffffa000bb46d600 x28: ffff00000092815a (do_execve.fexecv_proc_title + 5483) x29: ffff00010719e630 (next_index + 2cac528) sp: ffff00010719e630 lr: ffff00000053e890 (uiomove_faultflag + 128) elr: ffff000000804f80 (byte_by_byte + 4) spsr: 45 far: ffff0000b630a000 (g_ctx + b4c4a254) esr: 96000047 panic: data abort in critical section or under mutex cpuid = 2 time = 1646489189 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 data_abort() at data_abort+0x2a8 handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0x96000047 byte_by_byte() at byte_by_byte+0x4 pipe_write() at pipe_write+0x668 KDB: enter: panic [ thread pid 68336 tid 100593 ] Stopped at kdb_enter+0x44: undefined f901c11f db> Regards, Ronald. Van: Ronald Klop Datum: zaterdag, 5 maart 2022 12:16 Aan: FreeBSD Current Onderwerp: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28) > > Hi, > > Repeated panics on 14-CURRENT/aarch64. This happens e.g. when the nigthly backup is started. > # uname -a > FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-5f702d6d9a: Mon Feb 28 06:12:48 CET 2022 ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64 > > It was stable with all kernels until (and including) "FreeBSD 14.0-CURRENT #21 main-e11ad014d1-dirty: Sat Feb 5 00:09:08 CET 2022". > > It runs ZFS-on-root via an USB disk. No other FS involved. > # gpart show > => 40 1953458096 da0 GPT (931G) > 40 102400 1 efi (50M) > 102440 8388608 2 freebsd-swap (4.0G) > 8491048 1944967088 3 freebsd-zfs (927G) > > > Output on serial console: > x0: ffffa000059c1380 > x1: ffffa000059b1600 > x2: 3 > x3: ffffa001862779a0 > x4: 0 > x5: 9438238792a1a > x6: d217e9df58308 > x7: 14 > x8: ffffa000059c1398 > x9: 1 > x10: ffffa000059b1600 > x11: 2 > x12: 1 > x13: f2557a42c5b0f240 > x14: 1013e6b85a8ecbe4 > x15: 24f981889f30 > x16: ffff4afedeb89cb8 > x17: fffffffffffffff2 > x18: ffff0000fe666800 (g_ctx + fcfa6a54) > x19: 0 > x20: ffff0000fec41000 (g_ctx + fd581254) > x21: 3 > x22: ffff0000419bb090 (g_ctx + 402fb2e4) > x23: ffff000000c09bb7 (lockstat_enabled + 0) > x24: 180 > x25: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28) > x26: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28) > x27: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28) > x28: 0 > x29: ffff0000fe666800 (g_ctx + fcfa6a54) > sp: ffff0000fe666800 > lr: ffff00000154ca38 (zio_dva_throttle + 13c) > elr: ffff00000154ca80 (zio_dva_throttle + 184) > spsr: 20000045 > far: 1f24979f8000 > panic: Unknown kernel exception 0 esr_el1 2000000 > cpuid = 2 > time = 1646433952 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x174 > panic() at panic+0x44 > do_el1h_sync() at do_el1h_sync+0x184 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x2000000 > zio_dva_throttle() at zio_dva_throttle+0x184 > zio_execute() at zio_execute+0x58 > KDB: enter: panic > [ thread pid 0 tid 100128 ] > Stopped at kdb_enter+0x44: undefined f901c11f > db> > > > I'm going to build a newer kernel to see if the problem persists. I can keep the current kernel to reproduce this if needed. > > Regards, > Ronald. ------=_Part_85_417069800.1646492957521 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Another panic while building world/kernel. Different panic message and trace.
  
  x0:     1f5e152c32cc                                                                                                       
  x1: ffff0000b630a000 (g_ctx + b4c4a254)                                                                                           
  x2:                1                                                                                                              
  x3:               2e                                                                                                              
  x4: ffffa000bb46d600                                                                                                              
  x5:                0                                                                                                              
  x6:                0  x7: ffff000000f05104 (has_pan + 0)
  x8:                1
  x9:         809c227c
 x10:               bd
 x11:               40
 x12:                0
 x13:                1
 x14:         1782f000
 x15:             1001
 x16:         1782f003
 x17:     1f5e957392f0
 x18: ffff00010719e630 (next_index + 2cac528)
 x19: ffff00010719e768 (next_index + 2cac660)
 x20:                1
 x21: ffff0000b630a000 (g_ctx + b4c4a254)
 x22:                1
 x23:         ffffffbf
 x24: ffff00010719e758 (next_index + 2cac650)
 x25: ffffa00026cdd160
 x26:                1
 x27: ffffa000bb46d600
 x28: ffff00000092815a (do_execve.fexecv_proc_title + 5483)
 x29: ffff00010719e630 (next_index + 2cac528)
  sp: ffff00010719e630
  lr: ffff00000053e890 (uiomove_faultflag + 128)
 elr: ffff000000804f80 (byte_by_byte + 4)
spsr:               45
 far: ffff0000b630a000 (g_ctx + b4c4a254)
 esr:         96000047
panic: data abort in critical section or under mutex
cpuid = 2
time = 1646489189
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2a8
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000047
byte_by_byte() at byte_by_byte+0x4
pipe_write() at pipe_write+0x668
KDB: enter: panic
[ thread pid 68336 tid 100593 ]
Stopped at      kdb_enter+0x44: undefined       f901c11f
db>

Regards,
Ronald.


 

Van: Ronald Klop <ronald-lists@klop.ws>
Datum: zaterdag, 5 maart 2022 12:16
Aan: FreeBSD Current <freebsd-current@freebsd.org>
Onderwerp: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)

Hi,

Repeated panics on 14-CURRENT/aarch64. This happens e.g. when the nigthly backup is started. 
# uname -a
FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-5f702d6d9a: Mon Feb 28 06:12:48 CET 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64

It was stable with all kernels until (and including) "FreeBSD 14.0-CURRENT #21 main-e11ad014d1-dirty: Sat Feb  5 00:09:08 CET 2022".

It runs ZFS-on-root via an USB disk. No other FS involved. 
# gpart show
=>        40  1953458096  da0  GPT  (931G)
          40      102400    1  efi  (50M)
      102440     8388608    2  freebsd-swap  (4.0G)
     8491048  1944967088    3  freebsd-zfs  (927G)


Output on serial console: 
x0: ffffa000059c1380                                                                                                       
  x1: ffffa000059b1600                                                                                                              
  x2:                3                                                                                                              
  x3: ffffa001862779a0                                                                                                              
  x4:                0        
  x5:    9438238792a1a
  x6:    d217e9df58308
  x7:               14
  x8: ffffa000059c1398
  x9:                1
 x10: ffffa000059b1600
 x11:                2
 x12:                1
 x13: f2557a42c5b0f240
 x14: 1013e6b85a8ecbe4
 x15:     24f981889f30
 x16: ffff4afedeb89cb8
 x17: fffffffffffffff2
 x18: ffff0000fe666800 (g_ctx + fcfa6a54)
 x19:                0
 x20: ffff0000fec41000 (g_ctx + fd581254)
 x21:                3
 x22: ffff0000419bb090 (g_ctx + 402fb2e4)
 x23: ffff000000c09bb7 (lockstat_enabled + 0)
 x24:              180
 x25: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x26: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x27: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x28:                0
 x29: ffff0000fe666800 (g_ctx + fcfa6a54)
  sp: ffff0000fe666800
  lr: ffff00000154ca38 (zio_dva_throttle + 13c)
 elr: ffff00000154ca80 (zio_dva_throttle + 184)
spsr:         20000045
 far:     1f24979f8000
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 2
time = 1646433952
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x184
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
zio_dva_throttle() at zio_dva_throttle+0x184
zio_execute() at zio_execute+0x58
KDB: enter: panic
[ thread pid 0 tid 100128 ]
Stopped at      kdb_enter+0x44: undefined       f901c11f
db>
I'm going to build a newer kernel to see if the problem persists. I can keep the current kernel to reproduce this if needed.

Regards,
Ronald.
------=_Part_85_417069800.1646492957521-- From nobody Sun Mar 6 22:22:42 2022 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 547DE19EBC14 for ; Sun, 6 Mar 2022 22:22:51 +0000 (UTC) (envelope-from SRS0=EhES=TR=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 4KBbgt2dpsz3l4j for ; Sun, 6 Mar 2022 22:22:50 +0000 (UTC) (envelope-from SRS0=EhES=TR=klop.ws=ronald-lists@realworks.nl) Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1646605363; 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=LoTT3mC2lSgthi3owYipU1aPDBI6CdXSq5PPa9+87r4=; b=de4ZWNtWYh+mF6T2y4AU+P09Rmpgunwu574wRFkzBjP9y7HCuUfFsJeDWyqn/V9HqLn8FQ SjZWmWFokMCxWs2VTzRd9Ysc7aAKacMiOFF7ZnJCFtrRhBQZoFEwMA33nh0KT02oSvi6RA XjsWLmoQ8cJR/ZLjin8wAwy4icZsaFFA0xlgKcRkK9NbGbAY1SEJHUl+Nm1uicWPiCKBhf TXdEtqCvnl/zeHrW3dgaICaiaw14xS9jZDfDLmpRCSl+BygULZaKkvhPL7giim4noiaJN8 BTMakfQNi8BQ8gcCKPq0/fmi7Y3zBGj2QBL76ghPPs2kNVOs3THppN1QW95b9Q== From: Ronald Klop To: FreeBSD Current Message-ID: <710436463.96.1646605362794@mailrelay> In-Reply-To: <989767310.86.1646492957581@mailrelay> References: <1716388080.66.1646478964882@mailrelay> <989767310.86.1646492957581@mailrelay> Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) 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_95_599078998.1646605362707" X-Mailer: Realworks (599.209.9d862f3) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4KBbgt2dpsz3l4j X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=de4ZWNtW; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=EhES=TR=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=EhES=TR=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=EhES=TR=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=EhES=TR=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_95_599078998.1646605362707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Did some binary search with kernels from artifact.ci.freebsd.org. I suspect "rmlock: Micro-optimize read locking" as cause. https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a And "rmlock: Add required compiler barriers to _rm_runlock()" as solution. https://cgit.freebsd.org/src/commit/?id=89ae8eb74e87ac19aa2d7abe4ba16bcccd32bb9f So I probably just had a bad day. Regards, Ronald. Van: Ronald Klop Datum: zaterdag, 5 maart 2022 16:09 Aan: FreeBSD Current Onderwerp: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) > > Hi, > > Another panic while building world/kernel. Different panic message and trace. > > x0: 1f5e152c32cc > x1: ffff0000b630a000 (g_ctx + b4c4a254) > x2: 1 > x3: 2e > x4: ffffa000bb46d600 > x5: 0 > x6: 0 x7: ffff000000f05104 (has_pan + 0) > x8: 1 > x9: 809c227c > x10: bd > x11: 40 > x12: 0 > x13: 1 > x14: 1782f000 > x15: 1001 > x16: 1782f003 > x17: 1f5e957392f0 > x18: ffff00010719e630 (next_index + 2cac528) > x19: ffff00010719e768 (next_index + 2cac660) > x20: 1 > x21: ffff0000b630a000 (g_ctx + b4c4a254) > x22: 1 > x23: ffffffbf > x24: ffff00010719e758 (next_index + 2cac650) > x25: ffffa00026cdd160 > x26: 1 > x27: ffffa000bb46d600 > x28: ffff00000092815a (do_execve.fexecv_proc_title + 5483) > x29: ffff00010719e630 (next_index + 2cac528) > sp: ffff00010719e630 > lr: ffff00000053e890 (uiomove_faultflag + 128) > elr: ffff000000804f80 (byte_by_byte + 4) > spsr: 45 > far: ffff0000b630a000 (g_ctx + b4c4a254) > esr: 96000047 > panic: data abort in critical section or under mutex > cpuid = 2 > time = 1646489189 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x174 > panic() at panic+0x44 > data_abort() at data_abort+0x2a8 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x96000047 > byte_by_byte() at byte_by_byte+0x4 > pipe_write() at pipe_write+0x668 > KDB: enter: panic > [ thread pid 68336 tid 100593 ] > Stopped at kdb_enter+0x44: undefined f901c11f > db> > > > > Regards, > Ronald. > > > > Van: Ronald Klop > Datum: zaterdag, 5 maart 2022 12:16 > Aan: FreeBSD Current > Onderwerp: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28) >> >> Hi, >> >> Repeated panics on 14-CURRENT/aarch64. This happens e.g. when the nigthly backup is started. >> # uname -a >> FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-5f702d6d9a: Mon Feb 28 06:12:48 CET 2022 ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64 >> >> It was stable with all kernels until (and including) "FreeBSD 14.0-CURRENT #21 main-e11ad014d1-dirty: Sat Feb 5 00:09:08 CET 2022". >> >> It runs ZFS-on-root via an USB disk. No other FS involved. >> # gpart show >> => 40 1953458096 da0 GPT (931G) >> 40 102400 1 efi (50M) >> 102440 8388608 2 freebsd-swap (4.0G) >> 8491048 1944967088 3 freebsd-zfs (927G) >> >> >> Output on serial console: >> x0: ffffa000059c1380 >> x1: ffffa000059b1600 >> x2: 3 >> x3: ffffa001862779a0 >> x4: 0 >> x5: 9438238792a1a >> x6: d217e9df58308 >> x7: 14 >> x8: ffffa000059c1398 >> x9: 1 >> x10: ffffa000059b1600 >> x11: 2 >> x12: 1 >> x13: f2557a42c5b0f240 >> x14: 1013e6b85a8ecbe4 >> x15: 24f981889f30 >> x16: ffff4afedeb89cb8 >> x17: fffffffffffffff2 >> x18: ffff0000fe666800 (g_ctx + fcfa6a54) >> x19: 0 >> x20: ffff0000fec41000 (g_ctx + fd581254) >> x21: 3 >> x22: ffff0000419bb090 (g_ctx + 402fb2e4) >> x23: ffff000000c09bb7 (lockstat_enabled + 0) >> x24: 180 >> x25: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28) >> x26: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28) >> x27: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28) >> x28: 0 >> x29: ffff0000fe666800 (g_ctx + fcfa6a54) >> sp: ffff0000fe666800 >> lr: ffff00000154ca38 (zio_dva_throttle + 13c) >> elr: ffff00000154ca80 (zio_dva_throttle + 184) >> spsr: 20000045 >> far: 1f24979f8000 >> panic: Unknown kernel exception 0 esr_el1 2000000 >> cpuid = 2 >> time = 1646433952 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >> vpanic() at vpanic+0x174 >> panic() at panic+0x44 >> do_el1h_sync() at do_el1h_sync+0x184 >> handle_el1h_sync() at handle_el1h_sync+0x10 >> --- exception, esr 0x2000000 >> zio_dva_throttle() at zio_dva_throttle+0x184 >> zio_execute() at zio_execute+0x58 >> KDB: enter: panic >> [ thread pid 0 tid 100128 ] >> Stopped at kdb_enter+0x44: undefined f901c11f >> db> >> >> >> I'm going to build a newer kernel to see if the problem persists. I can keep the current kernel to reproduce this if needed. >> >> Regards, >> Ronald. > ------=_Part_95_599078998.1646605362707 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Did some binary search with kernels from artifact.ci.freebsd.org.

I suspect "rmlock: Micro-optimize read locking" as cause.
https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a

And "rmlock: Add required compiler barriers to _rm_runlock()" as solution.
https://cgit.freebsd.org/src/commit/?id=89ae8eb74e87ac19aa2d7abe4ba16bcccd32bb9f

So I probably just had a bad day.

Regards,
Ronald.

 

Van: Ronald Klop <ronald-lists@klop.ws>
Datum: zaterdag, 5 maart 2022 16:09
Aan: FreeBSD Current <freebsd-current@freebsd.org>
Onderwerp: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))

Hi,

Another panic while building world/kernel. Different panic message and trace.
  
  x0:     1f5e152c32cc                                                                                                       
  x1: ffff0000b630a000 (g_ctx + b4c4a254)                                                                                           
  x2:                1                                                                                                              
  x3:               2e                                                                                                              
  x4: ffffa000bb46d600                                                                                                              
  x5:                0                                                                                                              
  x6:                0  x7: ffff000000f05104 (has_pan + 0)
  x8:                1
  x9:         809c227c
 x10:               bd
 x11:               40
 x12:                0
 x13:                1
 x14:         1782f000
 x15:             1001
 x16:         1782f003
 x17:     1f5e957392f0
 x18: ffff00010719e630 (next_index + 2cac528)
 x19: ffff00010719e768 (next_index + 2cac660)
 x20:                1
 x21: ffff0000b630a000 (g_ctx + b4c4a254)
 x22:                1
 x23:         ffffffbf
 x24: ffff00010719e758 (next_index + 2cac650)
 x25: ffffa00026cdd160
 x26:                1
 x27: ffffa000bb46d600
 x28: ffff00000092815a (do_execve.fexecv_proc_title + 5483)
 x29: ffff00010719e630 (next_index + 2cac528)
  sp: ffff00010719e630
  lr: ffff00000053e890 (uiomove_faultflag + 128)
 elr: ffff000000804f80 (byte_by_byte + 4)
spsr:               45
 far: ffff0000b630a000 (g_ctx + b4c4a254)
 esr:         96000047
panic: data abort in critical section or under mutex
cpuid = 2
time = 1646489189
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2a8
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000047
byte_by_byte() at byte_by_byte+0x4
pipe_write() at pipe_write+0x668
KDB: enter: panic
[ thread pid 68336 tid 100593 ]
Stopped at      kdb_enter+0x44: undefined       f901c11f
db>

Regards,
Ronald.


 

Van: Ronald Klop <ronald-lists@klop.ws>
Datum: zaterdag, 5 maart 2022 12:16
Aan: FreeBSD Current <freebsd-current@freebsd.org>
Onderwerp: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)

Hi,

Repeated panics on 14-CURRENT/aarch64. This happens e.g. when the nigthly backup is started. 
# uname -a
FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #22 main-5f702d6d9a: Mon Feb 28 06:12:48 CET 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64

It was stable with all kernels until (and including) "FreeBSD 14.0-CURRENT #21 main-e11ad014d1-dirty: Sat Feb  5 00:09:08 CET 2022".

It runs ZFS-on-root via an USB disk. No other FS involved. 
# gpart show
=>        40  1953458096  da0  GPT  (931G)
          40      102400    1  efi  (50M)
      102440     8388608    2  freebsd-swap  (4.0G)
     8491048  1944967088    3  freebsd-zfs  (927G)


Output on serial console: 
x0: ffffa000059c1380                                                                                                       
  x1: ffffa000059b1600                                                                                                              
  x2:                3                                                                                                              
  x3: ffffa001862779a0                                                                                                              
  x4:                0        
  x5:    9438238792a1a
  x6:    d217e9df58308
  x7:               14
  x8: ffffa000059c1398
  x9:                1
 x10: ffffa000059b1600
 x11:                2
 x12:                1
 x13: f2557a42c5b0f240
 x14: 1013e6b85a8ecbe4
 x15:     24f981889f30
 x16: ffff4afedeb89cb8
 x17: fffffffffffffff2
 x18: ffff0000fe666800 (g_ctx + fcfa6a54)
 x19:                0
 x20: ffff0000fec41000 (g_ctx + fd581254)
 x21:                3
 x22: ffff0000419bb090 (g_ctx + 402fb2e4)
 x23: ffff000000c09bb7 (lockstat_enabled + 0)
 x24:              180
 x25: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x26: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x27: ffff000000c09000 (sdt_vfs_vop_vop_spare1_entry + 28)
 x28:                0
 x29: ffff0000fe666800 (g_ctx + fcfa6a54)
  sp: ffff0000fe666800
  lr: ffff00000154ca38 (zio_dva_throttle + 13c)
 elr: ffff00000154ca80 (zio_dva_throttle + 184)
spsr:         20000045
 far:     1f24979f8000
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 2
time = 1646433952
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x184
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
zio_dva_throttle() at zio_dva_throttle+0x184
zio_execute() at zio_execute+0x58
KDB: enter: panic
[ thread pid 0 tid 100128 ]
Stopped at      kdb_enter+0x44: undefined       f901c11f
db>
I'm going to build a newer kernel to see if the problem persists. I can keep the current kernel to reproduce this if needed.

Regards,
Ronald.
------=_Part_95_599078998.1646605362707-- From nobody Mon Mar 7 01:01:30 2022 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 6D13B1A079C0 for ; Mon, 7 Mar 2022 01:01:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KBgCG04n4z4VKV for ; Mon, 7 Mar 2022 01:01:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646614898; bh=qJXed/5Q88ToOyEdiQZiR5ivJB6/QvkGlux+mxdrBXA=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=bziJam2bMUiiuJzuOJjVUoxb63IdUUFMqW5r4Jsc4IUeEW0pTOV0wYNstAu9FrReKbNyswT/NU842nHTJYdHkUfX4z2rDkZb92rFiCrheegCKiJJ4xiZUP7fi08ZV94C/FG7k3NAfZOgVq0mLQGZ2dKiU1MM1opVeMJitZUPmVJtw6NF2FIxscetQzifPy7cM3k8xx+d/uhBdvtcYcVaSe47Z3bWya/7ZbpA/pkqmdaGUuRA2w2Oc2DwIeG1XTUB/ddawxBDKCqMTDOduYXxscv3LFQRDW6T7rRoM4wzZ2qYczu4DlBnTSQqj/ZPD93fryS/thlMBI4KP87YgCcDqA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646614898; bh=MZL3X/f9pfSnBKp9SEVMo9+WKXeScXT9W4nAr3OGxmI=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=bmL81e5mKR5d2CxJu5EhaEGf50hGApd379WTIsTogeYiAymy1/A817xri+MlWRxQgqm20lfF/zv7YoEvkNIqoDduy9yu1gnXfdkHb5uSgjlhWtcU2PBcE7vQQ8NhVwZGPdXFZGyZvlkKQNoBT1uY+XAVhWECSWa5h11pRk8VhAyz8zPHoCH94NgTyAWQL3jNCAiPi6/1XNubewcCN1gZqPyPhv05Hd4bFm94SfKLlGAtc++wEKD+8cqzP/rGNp2xZ9vTxV8e13z5LQrojcfnJqK29P29555+0LBqn5ztD+t/gklDnoAoSqB2x4PyV3wVZzBaRsVwBGqaKRFE/vq9eQ== X-YMail-OSG: bVTJIrAVM1mfAlMmVvS2GgciBhLvrFvnoyT70TO_VIHFofWVroaPX_M6_Tr1xap nX2XokGJevFTImCbu9n4URvKNF20d4gWuf1QT.4pd4xFD.6c5xKpArFJEMyT0m7nQ0XS0ShcrIBm 7navi8RZ7LVkV8Cm2lJhxYhcCfteratbSe9g8C4lFQ5lk8IDHAqOZKNSSfxUJSKHdLwbt0xyPdqG 9avq94nDWcam1nnaps4yDijswVXkXnn1tJuxtMqbsz4k3Nqdt5pAkL5kcHIuFcey6iRGhROCPdQ3 x_KN3_K7PHpj_VnGCzttjfkMy3Dl8OI8MrUpr1LLrD0TdDM9M255DhG1RIJMtiFn0yGGxXmFRTJ5 sP8bRO2LnJjLsdevTu9NXP66Wjehf6M8W1AN5S1cqipHSA54vUgwSPXPgG3qtkpeJ2fIrCA1FhM6 34vRFoXph5qKxmX4IN4.MM0LbT0MyipthQN8YPDe9jUGj6eYPRadQ12jqRAF_hIKRU4nJsBh7n9V GkJKOkdLd2.X_E5cJTFsn1i1ym5vuYDY9EZ36CaGHxdN5E93Dk2E22K5GiqALqPfQ5HiBga13qwk SyTrQNgsyPtBEtcnTLr2IYVGJmx_NZoYXEUaEYG.g3aweqSNiHXs8QfSMBG_K1RO9Ir_O2e.J9Mp xhfaUg0yEWUsRseUPLCNQIOLHJN9rkDTeIBMthK6QQ01.wCCSSpR0iYkvEh3xB9QQHqOm8V8zvV. AR6D9bHCVHj0Xd14ShxKMgp0RPYu2yY0vPudLPEUdvWZG03p._lXEwXWKnVTo048nCzaMY3Zy_a6 SORSbiTju3TW1x9mbE1JtQo0W8lFqy6IFlsWyKCAM452ng8chbQwgyUlICPs.V8Vg_O000lK5Nw8 wjX8HYUlz4dacskhb6LhohdMuD2F.C8gNVN0WImxTXPQpBzLE4Zb0j0nVJiTXHmUdtbKPvHZrSRo QI4PWIs5voZQ3KuCBcqdC0HAAUlwJLQmppUwx7oULO.KL5lySt4WN6M_5p6zQf4Q71MOz76vkMFS Co6AxI4Pr4EDCt1lqYhsBoQuGSlE5ndUCVsMsWkgLBNupj5l11VHa.7mz6m_OaVZnDcZzWeMNO4X C2HTYB6r4W19tst0k7SbpauylI6NJn6d9jABH2SKS5nDoKh92uEpL9_hz8lrPpAroreTk8TeGxF9 Ku25TEWxVj6LabZ8Vp8WNpXd.TsvsS9SPQ8Rt8lcRzEblZY412OHubQcsG0ZNjd4FPhoLlhWyYqR vCHmOobfnfWQTFbc3CxpGqsvMUs0y7xTTERCEizHD0FHh2W0FKZ7rfeHqMGjJKbYQ5IpBx2bW891 lGei4DNT3quayuBS01IAQrVVOLmy9fJ4YFtqOl3XsfrzHZRRetaAjO2LR9rkECD0RhAirwYrTuHR HL73F6zfYt3ShgNWjgXZu3gWnN3.TSK55044IqMDzc85w0UbDmpjpaBgyRem4Ed_v9x1a2ZDsKeD NSKRYF9.HfXB.0qa.sQS7RReVExaX4O0o1wS_KSsdXXHXD77vGNAF6FzsQxbeAs4.PDdVsOis99E V2BP1yDbL1yt2W0MTb0CE64XvydVL9r71JYNvrecobs0vXzYRShO6xyDCPBWICX8H8h4.lIZRDHT p7DcnjFm0eZgNcP9tT.3cH2GeY0BkzGStmYKauzhTD.x3Vb5geawKEJtr7DFwLl8DctGgBLP5vhR 165c.v4JhC05psQoBeYZORU6l0TiKXTu8AMH..nXhf.cs8E65zoBK8Oup5ic8LOW5N5Ppu1w4HK4 upyQ0Yny0q2Lv77QIDBadrJa5MEsiQ0WSes1DNVrCvIDm7pY6kTRDaKhSqmc43v4eC78KoJJ8IsB 2thlCj8ACfAPqzlyGbYcfaYRWY6PPkT3Qr0JeZ6IlsDA74RUCDbTjtmzjY0SKtgOHFAXgp9E96ZV WuIPvh.XSLrqiE5tWDMYAhYRR2bL5rDk5t2ypeCJNSKyFIM1oYqZ3T.9bLX26akqTJLdKsiZ295K 9gOzf0hT9Rd2XXCXHnqn0GIWKRoutTLLTBhpJ.sLMKxp7MDxHBTZvPykOp8kJWLl3F.ChUHOsdn3 Qa4TWMf3nX4E1HFppv90Fsm3klyyxvcCeEGAWf7U7GVUIAvcgpkZiZNuCjSgIbS_TUIBk9VM79yn BDtk0QHU1uI1CO5N0T8TK9_k2bwK2AV3nK8mrwjhdv9XQTf5NQ__rMjC3hFZIa.nOn8lv5QCShoJ IohJCN28kG2kPUt2IeqlNURtmJ2B.iQDavGM0E7IqZf41hacMvNwHY5.FP07OyHYBwcxHzWpKMYv 77NDgWdO7vruJ15fW7mcE9ColemwaZWRxvimORb7B7be65jtIVTBdsaykIpzLyeetiwQ7cdVV5ZI ZR_Qb X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Mar 2022 01:01:38 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cbba54f0c60057021da8cc5638ef069e; Mon, 07 Mar 2022 01:01:33 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) Message-Id: Date: Sun, 6 Mar 2022 17:01:30 -0800 Cc: freebsd-current , bob prohaska To: Ronald Klop X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4KBgCG04n4z4VKV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=bziJam2b; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.09 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.60)[-0.597]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N From: Ronald Klop wrote on Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) : > Did some binary search with kernels from artifact.ci.freebsd.org. >=20 > I suspect "rmlock: Micro-optimize read locking" as cause. >=20 > = https://cgit.freebsd.org/src/commit/?id=3Dc84bb8cd771ce4bed58152e47a32dda4= 70bef23a >=20 >=20 > And "rmlock: Add required compiler barriers to _rm_runlock()" as = solution. >=20 > = https://cgit.freebsd.org/src/commit/?id=3D89ae8eb74e87ac19aa2d7abe4ba16bcc= cd32bb9f >=20 >=20 > So I probably just had a bad day. Well, there is a report of a buildkernel crash after that pair: https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.html that references additional information at: http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme and reported: QUOTE The console connection dropped before the crash (unrelated) I didn't get the preamble, all I have is the backtrace and buildkernel log.=20 Here's the backtrace: db> bt Tracing pid 14795 tid 100098 td 0xffffa00017815600 db_trace_self() at db_trace_self db_stack_trace() at db_stack_trace+0x11c db_command() at db_command+0x368 db_command_loop() at db_command_loop+0x54 db_trap() at db_trap+0xf8 kdb_trap() at kdb_trap+0x1cc handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0xf2000000 kdb_enter() at kdb_enter+0x44 vpanic() at vpanic+0x1b0 panic() at panic+0x44 data_abort() at data_abort+0x2e8 handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0x96000004 _rm_rlock_debug() at _rm_rlock_debug+0x8c sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140 sysctl_root() at sysctl_root+0x1ac userland_sysctl() at userland_sysctl+0x140 sys___sysctl() at sys___sysctl+0x68 do_el0_sync() at do_el0_sync+0x520 handle_el0_sync() at handle_el0_sync+0x40 --- exception, esr 0x56000000 END QUOTE The above material does reference _rm_rlock_debug . Might be related? The readme reports: main-n253603-0b25cbc79d3: Thu Mar 3 22:48:31 PST 2022 for the system doing the buildkernel. This is after 89ae8eb74e8 . (It also mentions another panic earlier in the week, apparently not reported to the lists at the time.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Mar 7 07:57:32 2022 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 D0D541A03669 for ; Mon, 7 Mar 2022 07:57:45 +0000 (UTC) (envelope-from Weike.Chen@Dell.com) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 4KBrRD5HkLz3NLl; Mon, 7 Mar 2022 07:57:44 +0000 (UTC) (envelope-from Weike.Chen@Dell.com) Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 226FZ3Xs012885; Mon, 7 Mar 2022 02:57:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=09tGl4aMA2kETsTSQ4EBOepAdpWNfKIM6374UcebHdE=; b=AAJ4QdXYsyDt37TO1FHFiKpDD5wFy4PCy1SCm4RqFY7oY2kMheY00mkECejeKg5HPMdd mp+/2O1ylRvfZwU8e2lP1jasqncHK8SvEpMf/qyWi2heVASKAK2Ym+AIi9381UJ9tjGv 1VinQSnjeyU1tebbf0+0v/lzgU3qH9cpduzJ5MW4q8DHTOZkT6KXbhSA+r8udryoccIo 5X8qZz1F7iPDsGT1wdM2Jgco+8S8ptxRaaWnKouwdgykFiacAb5ueVivkW+j6Jhilyhz HjvtP8LOVOkK3w+vBkc9p8KfMQMx9I4EPO6++IdQ2ZUTdiFcfsdVBuakHTYpxUCNKEAr YA== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com (PPS) with ESMTPS id 3em1twv6cj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Mar 2022 02:57:34 -0500 Received: from pps.filterd (m0089483.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 2277orhi026784; Mon, 7 Mar 2022 02:57:34 -0500 Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2171.outbound.protection.outlook.com [104.47.59.171]) by mx0b-00154901.pphosted.com with ESMTP id 3emnqn6pq1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 07 Mar 2022 02:57:34 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Roc8uDsDsbINl7VF+zaiqOzJ9HlWO6svo3S6aR9k034H2v0jrb8qqC+2hd+hAfB/v6uxa9/Fvga/0N9muf1QMXhI48882hG8H2rdbzQn45wJt1zEZt5+HO3hfc7lWE3JIVGXnBugXgtu3jod8cMOrCL8XGOPCXGY9sFT4Fghn4MFxo1q5qPSQTM3HN4mkGScndqJ0K/45AZRc/NCgMmFkT52Xoa6W/4ax1AviFedeFLG9lQ0CvxHUn35cwnwqO7PDr+Bodn9bO1Ors/UyOwcv+DDYjB7nWUcxM/RKmiGXkqJrFWJrww/LZwvqE3PQ1FnOJ2Y+zkM4liiLCfdIRlxfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=09tGl4aMA2kETsTSQ4EBOepAdpWNfKIM6374UcebHdE=; b=Lz7GTcoc7/ztvFEKdkxwi8kzzc+46ORkSsEqbGu2AGO1ingiMb+ZE/iibEWKqr//tF8Wmnd+3tp+HBJJ8ekRySd0qwInfTAmbock7jGGooaMnOx2r3lJKizVBMCYhpqdQin2KjEELjabi+caFvOnPZi9Zn2XfH88pkE0Se1k+NSqovhnkJCET14F3X0GOKqScNv4uX+Tfmg2aLHl5Z/nGLF8pulIHXCDT5SzMFn43J2+zgdl2J3a3ByIGPmu9OYCDHXbxTt0SKCbrUTdiIxJK4MkwFh1e8O8l8uJyY0f+LHH550N3QpsU5Yx46ZZ2CGpaexz3V+MrI57hy1xZ0svCA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none Received: from PH0PR19MB4938.namprd19.prod.outlook.com (2603:10b6:510:94::9) by DM6PR19MB4735.namprd19.prod.outlook.com (2603:10b6:5:20e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.14; Mon, 7 Mar 2022 07:57:32 +0000 Received: from PH0PR19MB4938.namprd19.prod.outlook.com ([fe80::704f:ebed:4242:35ed]) by PH0PR19MB4938.namprd19.prod.outlook.com ([fe80::704f:ebed:4242:35ed%6]) with mapi id 15.20.5038.027; Mon, 7 Mar 2022 07:57:32 +0000 From: "Chen, Alvin W" To: Konstantin Belousov , Alexander Motin CC: Mike Karels , Tomoaki AOKI , "freebsd-current@freebsd.org" Subject: RE: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Thread-Topic: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Thread-Index: AQHYJbKLejWhUNFpRUKF3j1TMIPwW6ybHNkAgAATZYCAAGVYAIAEmvsAgAAKYYCAAAICAIABLF83gACFo4CAEbd8sA== Date: Mon, 7 Mar 2022 07:57:32 +0000 Message-ID: References: <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <06768ef6-c88e-b6c7-0db3-f61eb4230937@FreeBSD.org> <470db559-7e7d-1af7-5983-2858814329d2@FreeBSD.org> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Enabled=true; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SetDate=2022-03-07T07:57:30Z; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Method=Standard; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Name=No Protection (Label Only) - Internal Use; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ActionId=785f6775-ce0a-4f55-88a4-02ee225c9037; MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ContentBits=2 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f0e099db-c30e-449d-8e1a-08da00102284 x-ms-traffictypediagnostic: DM6PR19MB4735:EE_ x-microsoft-antispam-prvs: x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QLh2IJDowvf0mOSnzzuRkLip9urtXLBm/z5zfWlCwRF3FmzisOuf58VrHQxi0QPv4yjUempE5Ihztw1vz7jurNdtyVTS7XYg6KMfntlkB58eioCx8XZUmjt8vLZNV93NXB+9x8hgo8nSbFiue3L8yUh1fzg5h4qEv0YHsq1yq6j0DZI7KgCcjlt9MfJrgx5olPUWI7V3kub4LH03vQM8YC0omDc3WWIIZt/hYrJjbm9kLO5FEO6VDFOY7EZrLD3J1dd5oFCfJBurWyLAxMy/EpIfVIUP+1kJWaMGtNLM8xrFyfWwQiBNxnsHPN1EejaxSiL5Tk7LtVqhH/TxyAcEJigVnrhgSEr/Ta3qvTgWAdGK2owY3Nizzso2UIjfRQnQL3E/W9A7F5X/y7JNZGkHl5p0PSG5CDpoYqDGSmM0CZTgeUaR0u2jWGT3lTSgLgTaYAyOcS361A4Xmig3vRsdnUJjsdmmVm1dsIjVJGlLxNVhrwxzaeCxYVpWRZSFkdE0aPhO1ZHVNcgJgvayihyEL7IXzklXUeOucM6ckSNpLaXPgqBZjzCVbeuBmj6MVO41stZMN0CM3JFAweu0f2Kfxm6xpfyryQowkTE0fI1hJ3+DVRU7ppvwLZpFlZsPdgqtqrvgtiqL37mFWaes9GYfaCi0/SLIO+8lfXvRQlyFk1tC/TYKAYioxE+yCS04SQQ8zfFKoa2rseW1Y+6Rm8LxFA== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR19MB4938.namprd19.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(9686003)(82960400001)(38100700002)(53546011)(5660300002)(8676002)(7696005)(122000001)(6506007)(33656002)(2906002)(186003)(26005)(66476007)(66446008)(8936002)(508600001)(38070700005)(71200400001)(786003)(83380400001)(110136005)(54906003)(52536014)(55016003)(316002)(86362001)(66556008)(76116006)(66946007)(64756008)(4326008);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?TjRUdlBSVzJUQVRkN21KM3hZZXhEUXRkZzM5ZWNtSENhVmdUb2tGS2pi?= =?iso-2022-jp?B?cWlDdnFpTTJXRFVNa0JzYSs4QlB3d3Rqdjk4TmJrRmVHUUFCUytRbWVZ?= =?iso-2022-jp?B?ejloUlFpTXlPY1hTcjlWRW82TzJzQnBDR1VoQ3pZOVhaRldwbGpzM1Vj?= =?iso-2022-jp?B?ckxhdm9neVlrOHd6amtrUHdTZFRXUmxrTkV0eW1BK0UxY0tFbnQwZHlK?= =?iso-2022-jp?B?SnBodmlYdDV0N1djcWtvS0V0eGorTDdSVEY0V3ZRVldXNFlaQ0dQb3JL?= =?iso-2022-jp?B?WUlieWFLanpqRWh3QURJNEZCRm9wbGRCUEs1bDBLOHhVZ3VPYUlobnIr?= =?iso-2022-jp?B?eEI5cGhBa3hsczM2c3JpTXRpNk1lQmZQY29scG8yQzlwYnNyYVUzL2U2?= =?iso-2022-jp?B?VXVIS1J1YWRzRHpNaG9KSkZJTm0yUm5paHhyZitURENKOE9qSDN4Rld0?= =?iso-2022-jp?B?TitzdC9taE05dGdaYU9SOXdoeS9oeFdZNFpXcDU5L2VnRmdpYlhWU0Rs?= =?iso-2022-jp?B?bEVMRFFSS1RNQkY3YWxEZDVZWmdVTzUzQlltS01FUzdRQkZYcDN0cUpC?= =?iso-2022-jp?B?Qk5KeWtrd1ExdWxqV2tRemNuMkR6UHNybEgrN2FzVVRrL010aE01T1Zp?= =?iso-2022-jp?B?YXlYK0tQK0pkenpDWTJ5SGc1NHJTMXdqQlpWMUFRdlV0dStMVHpTWk1m?= =?iso-2022-jp?B?bHZwbnVaRVNqYjRObFNFRDVEVXhWdnRnU08yUWtMMnRsaW4xbUNKVGRC?= =?iso-2022-jp?B?QmNFdTR0WWpIenJBb0xFdFJVcEJoaExIT1d3ZHprMzM4V3h2Q3pyNk9o?= =?iso-2022-jp?B?cWxYclI2MHVxRjBwcWdqeU43eFM5R2lENVJlWEcydzhRc3lwMHY3aC9o?= =?iso-2022-jp?B?K2F3NE1LM0VYWUlsS01UVVg3Y2M1cVkydWl6RnZmYWtZWDE0RHgvdVFh?= =?iso-2022-jp?B?STc0K3NYcnQ0SlFGd3dZcGFxRnlYQytVWk9FV2FqTHRmK0Z1WkR4dXVq?= =?iso-2022-jp?B?cGgyWWx5dGFMcjJEWVhpclc2QmxRTXA3VTcwM0JhS2picnAxK2FGQVRO?= =?iso-2022-jp?B?eFVQVG1Uc2pQc0pMMThCNXhic2dNSU1wSGhPVk90b3RvZXAwblNmQXFF?= =?iso-2022-jp?B?WE9nWUJHQUlRRVREQjlyMFAzU28vcE5UVHplbkhWdnFHK2QrN2YvTUFX?= =?iso-2022-jp?B?VSs1NzFINi9VZkdBa0ZiTUE3U2R0cDhBSXhOVm1zMHZodkFIQzdxV2c4?= =?iso-2022-jp?B?NEVpa1R6VHhuSDZyZ1J0NHY0eEgydDNZTWNaVytIblFaSWEzZFBiRUU1?= =?iso-2022-jp?B?Z2wyeEdxdGhzbGw1cUtReE5lODBVUEJ5Q2I0RWVIa0dUU0s4ZFEyWEdS?= =?iso-2022-jp?B?NlZsaTZQMHZURWxNNGNhSkRnRXY4U09NbWRINm9mSUZNMm9IbmhubzdF?= =?iso-2022-jp?B?bEpJQzh3U3pUOExEWnh3R1BDbm1kbFViK0paMFBqMGtnNXJFSEgyaVhU?= =?iso-2022-jp?B?WkNDeEFpVHkxVGkwZTAvb0lTUndYclNqb2ZHK1BvdmowMk5LS2NMSEZo?= =?iso-2022-jp?B?aHhuNmdoUnZPSEYzano2eStwYzlZSHc0bnYrM0FVRGFQQWpiSG1LMWVk?= =?iso-2022-jp?B?WmZZb0tPTytFN2VMYTEwUHFQNnZyL3lCNUhJbzNicVRwdjJPR1BYR0I1?= =?iso-2022-jp?B?NGhITDMvaWJsblVja24yRWY4SVNIaDJPYnRMdHhadWozcFN5Ykp0Ynlj?= =?iso-2022-jp?B?WlFXUW9McmZrYlk5Nk9hdUk4aDY0UHp1ZUpUY0RKZ09Hem5hK3JIenRy?= =?iso-2022-jp?B?QkxRYndpZ1hnUEZwM0k0Ti9vMkRqcGZTcTFhQWpGKzF6V2gwZjFITVFu?= =?iso-2022-jp?B?bzJVcnBhaENENFZ1TG5QeG4rRTdLQU5tNTlpQnEyQ0laTHY5MldjNTFU?= =?iso-2022-jp?B?MHpHaG5wbitjZ2NucXkyNUZNNHZWMFRLeGpOblptK3dVYnlZMnRsRXdF?= =?iso-2022-jp?B?Rm5OYnRvZEY3WDBwQzFnWFpTU3ZkVUtTQzluUjZDVmZJZnVUS1RUOCtQ?= =?iso-2022-jp?B?RTIxRGorMldpSmc1Z2Z4ZWZYM0h2d1ZkdEtaUXV6YXJ0a08rMDlsU1U1?= =?iso-2022-jp?B?SHdtMHNNb1ZkbGFPYTk3MUUvSnB6N0RaWUJMZnQvM1FaeFE3SE1sYU5D?= =?iso-2022-jp?B?YTRIaUxXMWhBZGZ6elptQVZaWmlCRU5DcUZiY0VsUC9kS1pua0YzZy9R?= =?iso-2022-jp?B?T1NZbkI1UXJrWkV2M0JoUmVYazhDNlIxNUxQemxtRFlKZUtDNEdnNkZa?= =?iso-2022-jp?B?MytKRUd6NjFzTDNYS3p6bWVWRlU4UEZnMmM2R3J1Ny9MeXMxL3JXVjF5?= =?iso-2022-jp?B?dERMSWM9?= Content-Type: text/plain; charset="iso-2022-jp" 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 X-OriginatorOrg: Dell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR19MB4938.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0e099db-c30e-449d-8e1a-08da00102284 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2022 07:57:32.3842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: //+JvmNo6JLmsdUxTAmOguVUdedtezkNRUENJgIkSUKwRyM0wWff9Z4TWiIwDDJSUoziiCTmoi7VrLhpNyeMjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR19MB4735 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.816 definitions=2022-03-07_01:2022-03-03,2022-03-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 mlxlogscore=999 clxscore=1011 phishscore=0 spamscore=0 adultscore=0 mlxscore=0 suspectscore=0 malwarescore=0 bulkscore=0 impostorscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203070046 X-Proofpoint-ORIG-GUID: dkj3YKTir0yVwy0WUo5Pi53I9LIOKBTz X-Proofpoint-GUID: dkj3YKTir0yVwy0WUo5Pi53I9LIOKBTz X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 spamscore=0 bulkscore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203070047 X-Rspamd-Queue-Id: 4KBrRD5HkLz3NLl X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dell.com header.s=smtpout1 header.b=AAJ4QdXY; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); dmarc=pass (policy=none) header.from=Dell.com; spf=pass (mx1.freebsd.org: domain of Weike.Chen@Dell.com designates 148.163.137.20 as permitted sender) smtp.mailfrom=Weike.Chen@Dell.com X-Spamd-Result: default: False [-6.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:148.163.137.20]; RCPT_COUNT_FIVE(0.00)[5]; ARC_REJECT(2.00)[signature check failed: fail, {[1] = sig:microsoft.com:reject}]; RWL_MAILSPIKE_EXCELLENT(0.00)[148.163.137.20:from]; DKIM_TRACE(0.00)[dell.com:+]; DMARC_POLICY_ALLOW(-0.50)[Dell.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22843, ipnet:148.163.137.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.157.37:received]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[dell.com:s=smtpout1]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[dell.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[104.47.59.171:received]; MLMMJ_DEST(0.00)[freebsd-current]; WHITELIST_SPF_DKIM(-3.00)[dell.com:d:+,Dell.com:s:+]; RCVD_COUNT_SEVEN(0.00)[7] X-ThisMailContainsUnwantedMimeParts: N Hi guys, Any progresses for this issue? Regards, Alvin Chen Dell | Comercial Client Group office +86-10-82862506, fax +86-10-82861554, Dell Lync 8672506 weike_chen@d= ell.com Internal Use - Confidential -----Original Message----- From: Konstantin Belousov =20 Sent: 2022=1B$BG/=1B(B2=1B$B7n=1B(B24=1B$BF|=1B(B 9:24 To: Alexander Motin Cc: Mike Karels; Tomoaki AOKI; Chen, Alvin W; freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition c= ause data corrupt due to P-Core&E-Core [EXTERNAL EMAIL]=20 On Wed, Feb 23, 2022 at 12:25:24PM -0500, Alexander Motin wrote: > On 22.02.2022 19:00, Konstantin Belousov wrote: > > On Tue, Feb 22, 2022 at 06:53:09PM -0500, Alexander Motin wrote: > > > On 22.02.2022 18:41, Konstantin Belousov wrote: > > > > On Tue, Feb 22, 2022 at 06:38:24PM -0500, Alexander Motin wrote: > > > > > On 22.02.2022 18:30, Konstantin Belousov wrote: > > > > > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabl= ed=3D0. > > > > >=20 > > > > > Do you mean it to be a workaround for TrueNAS 12, or it should=20 > > > > > provide some information? The system is at the office and has=20 > > > > > no IPMI, so I can't switch the boot device from home right now. > > > > I intended to see if it is the cause or related feature. > > >=20 > > > I'll try that on the 12 tomorrow, if applicable. > >=20 > > Yes should be relevant still. >=20 > It did the trick. I repeated several times successful boots with the=20 > pcid disabled, and failed ones with default enabled. In attachment=20 > you may find verbose serial console output captures with pcid disabled=20 > and enabled, though without the cpuinfo patch. During the testing I=20 > had only one P and one E cores enabled to reduce noise. Only after=20 > that I found P core having SMT enabled, but I then repeated without=20 > SMT also, so it is indeed irrelevant. >=20 > I'm curios, what in pcid could differentiate the P and E cores, and=20 > have it got fixed in latest stable/13, or I am just "unlucky" to not=20 > reproduce it there? I am curious as well. PCID works on both big Intel cores, and on small cor= es like Apollo Lake etc. So the fact that it does not properly interact in= P/E settings either mean that there is something I did not accounted for f= rom the spec, or there is a bug in silicon. I have no idea why do we work on stable/13 and HEAD. There were enough cha= nges to PCID code there, but it was mostly restructuring and polishing. So the only way to get more understanding is to bisect to see which commit = on HEAD fixed the boot. From nobody Mon Mar 7 10:38:59 2022 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 EB43819FDE01; Mon, 7 Mar 2022 10:39:03 +0000 (UTC) (envelope-from SRS0=34E+=TS=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 4KBw1L53S7z3sbn; Mon, 7 Mar 2022 10:39:02 +0000 (UTC) (envelope-from SRS0=34E+=TS=klop.ws=ronald-lists@realworks.nl) Date: Mon, 7 Mar 2022 11:38:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1646649539; 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=+qQZYHdB3YNrYW6YzD6SgwhJkJg6yyGjGAPj2WC58aE=; b=bpEOvOrCbEoRyPHrp/lk8ojpayCo+NS/oLWUlUbadR+pgAnyYovx5lSh0KSctQsZhNs71D t6Nsmg0LmZamQcZEGj9GfYwgHbOQ6Fd6Bf3KEbUABX+OCz7YpUdD0e6+luDljMEw0eZ74F 9TXQ8klZWK2AKiYDyJMefhXl9HcCWc9lB3/P9rDPt+Wf6HlwiSbAL4FOhKKjb7fETRuVJe m1IgAa6fF59ci8zDtxyzfWOzcE8hC2ff0R8uZhi+Xi4J6dogTubYwFDq2xWNkMq21odRK5 wbcD277oDjJaew3c92VIdWi+0Wd/tNJB9KZsPXxXbUTVkKLlGZ0Df3n8J6j2Pw== From: Ronald Klop To: Mark Millard Cc: bob prohaska , freebsd-current , freebsd-arm@freebsd.org Message-ID: <1800459695.1.1646649539521@mailrelay> In-Reply-To: References: Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) 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_0_597764175.1646649539431" X-Mailer: Realworks (599.211.aa1e011) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4KBw1L53S7z3sbn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=bpEOvOrC; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=34E@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=34E@realworks.nl" X-Spamd-Result: default: False [-3.15 / 15.00]; ARC_NA(0.00)[]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=34E@realworks.nl]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.95)[-0.953]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; TAGGED_FROM(0.00)[=TS=klop.ws=ronald-lists]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=34E@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_0_597764175.1646649539431 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Yes, I spoke to soon too. Often it crashes as soon as I start a parallel po= udriere build. But this time it went very far. As soon as nightly backups k= icked in it was game over again. I had read the mail of Bob on the arm@ ML. But I wanted to let the conclusi= on that it is about the same problem to the developers. (Have seen enough o= f wrong guessing of causes in my work. =F0=9F=98=89) I will need to go further into the binary search of working kernels. This was: FreeBSD 14.0-CURRENT #0 912df91: Wed Mar 2 00:36:35 UTC 2022 Fatal data abort: = =20 x0: ffff000000f1efd8 x0: ffff000000f1efd8 (mac_policy_rm + 0) (mac_polic= y_rm + 0) =20 = =20 x1: 2 x1: 2 = =20 = =20 x2: ffff00000087dcf2 x2: ffff00000087dcf2 (cam_status_table + 2f28a) = =20 (cam_status_table + 2f28a) x3: ffff00000087dcf2 = =20 x3: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + 2f28a= ) =20 = =20 x4: 102 x4: 102 = =20 = =20 x5: 7 x5: 1 = =20 = =20 x6: 0 x6: ff = =20 = =20 x7: 0 x7: ffffa00011fc2800 = =20 x8: 1 = =20 = =20 x8: 1 x9: ffff000000f37c10 = =20 x9: ffff0000419d9090 (pcpu0 + 90) (g_ctx + 40278fe4) = =20 = =20 x10: ffffa0017be2a600 x10: ffffa000010fa600 = =20 x11: 394aed08d0003a48 = =20 = =20 x12: 350001a8b946a108 x11: 0 = =20 = =20 x12: ffff000000f37c10 x13: badecce4 (pcpu0 + 90) = =20 = =20 x13: ffffa0001fbde6b0 x14: 0 = =20 = =20 x14: 4965ae49 x15: 1 = =20 = =20 x15: 1000193 x16: ffff0000016a4238 = =20 x16: ffff000100482d38 (__stop_set_modmetadata_set + d00) (__stop_set_modme= tadata_set + 448) =20 = =20 x17: ffff00000044a998 x17: ffff00000058ff30 (free + 0) (if_inc_counter + 0= ) =20 = =20 x18: ffff0000b49a23c0 x18: ffff000103f11b80 (g_ctx + b3242314) = =20 (next_index + 3a228c0) x19: 102 = =20 = =20 x19: 102 x20: ffff0000b49a2428 = =20 x20: ffff000103f11be8 (g_ctx + b324237c) (next_index + 3a22928) = =20 x21: ffff00000087dcf2 x21: ffff00000087dcf2 (cam_status_table + 2f28a) (ca= m_status_table + 2f28a) x22: ffff000000f1efd8 x22: ffff000000f1efd8 (mac_policy_rm + 0) (mac_polic= y_rm + 0) x23: ffff00000086f107 x23: 0 (cam_status_table + 2069f) x24: ffffa0001fbde6c8 x24: ffffa0008cba0d00 x25: 0 x25: ffff00000088aa11 x26: 4 (do_execve.fexecv_proc_title += 76b7) x27: 0 x26: ffffa0017be2a600 x28: ffff00010209fcf0 x27: ffffa00025626a80 (next_index + 1bb0a30) x28: ffff000103f11ce0 x29: ffff0000b49a23e0 (next_index + 3a22a20) (g_ctx = + b3242334) x29: ffff000103f11ba0 sp: ffff0000b49a23c0 (next_index + 3a228e0) lr: ffff00000046ef98 sp: ffff000103f11b80 (_rm_runlock_debug + 60) lr: ffff00000046ef98 elr: ffff00000046dc0c (_rm_runlock_debug + 60) (_rm_assert + a4) elr: ffff00000046dc0cspsr: 45 (_rm_assert + a4) far: 10 esr: 96000004 spsr: 45 panic: data abort in critical section or under mutex cpuid =3D 1 time =3D 1646609483 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 data_abort() at data_abort+0x2d4 handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0x96000004 _rm_assert() at _rm_assert+0xa4 _rm_runlock_debug() at _rm_runlock_debug+0x5c mac_inpcb_check_deliver() at mac_inpcb_check_deliver+0x74 tcp_input_with_port() at tcp_input_with_port+0xab4 tcp_input() at tcp_input+0xc ip_input() at ip_input+0x2e8 netisr_dispatch_src() at netisr_dispatch_src+0xe4 ether_demux() at ether_demux+0x178 ether_nh_input() at ether_nh_input+0x3e8 netisr_dispatch_src() at netisr_dispatch_src+0xe4 ether_input() at ether_input+0x80 if_input() at if_input+0xc gen_intr() at gen_intr+0x444 ithread_loop() at ithread_loop+0x2a0 fork_exit() at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x14 KDB: enter: panic [ thread pid 12 tid 100063 ] Stopped at kdb_enter+0x44: undefined f902011f db> NB: db> reboot/reset/halt does not work on my RPI4. Luckily I have a wifi c= onnected power switch on it. Regards, Ronald. =20 Van: Mark Millard Datum: maandag, 7 maart 2022 02:01 Aan: Ronald Klop CC: freebsd-current , bob prohaska Onderwerp: Re: panic: data abort in critical section or under mutex (was: R= e: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64= Feb 28)) >=20 > From: Ronald Klop wrote on > Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) : >=20 > > Did some binary search with kernels from artifact.ci.freebsd.org. > > > > I suspect "rmlock: Micro-optimize read locking" as cause. > > > > https://cgit.freebsd.org/src/commit/?id=3Dc84bb8cd771ce4bed58152e47a32d= da470bef23a > > > > > > And "rmlock: Add required compiler barriers to _rm_runlock()" as soluti= on. > > > > https://cgit.freebsd.org/src/commit/?id=3D89ae8eb74e87ac19aa2d7abe4ba16= bcccd32bb9f > > > > > > So I probably just had a bad day. >=20 > Well, there is a report of a buildkernel crash after that pair: >=20 > https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.html >=20 > that references additional information at: >=20 > http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme >=20 > and reported: >=20 > QUOTE > The console connection dropped before the crash (unrelated) I didn't > get the preamble, all I have is the backtrace and buildkernel log. > Here's the backtrace: > db> bt > Tracing pid 14795 tid 100098 td 0xffffa00017815600 > db_trace_self() at db_trace_self > db_stack_trace() at db_stack_trace+0x11c > db_command() at db_command+0x368 > db_command_loop() at db_command_loop+0x54 > db_trap() at db_trap+0xf8 > kdb_trap() at kdb_trap+0x1cc > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0xf2000000 > kdb_enter() at kdb_enter+0x44 > vpanic() at vpanic+0x1b0 > panic() at panic+0x44 > data_abort() at data_abort+0x2e8 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x96000004 > _rm_rlock_debug() at _rm_rlock_debug+0x8c > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140 > sysctl_root() at sysctl_root+0x1ac > userland_sysctl() at userland_sysctl+0x140 > sys___sysctl() at sys___sysctl+0x68 > do_el0_sync() at do_el0_sync+0x520 > handle_el0_sync() at handle_el0_sync+0x40 > --- exception, esr 0x56000000 > END QUOTE >=20 > The above material does reference _rm_rlock_debug . Might be > related? >=20 > The readme reports: >=20 > main-n253603-0b25cbc79d3: Thu Mar 3 22:48:31 PST 2022 >=20 > for the system doing the buildkernel. This is after > 89ae8eb74e8 . >=20 > (It also mentions another panic earlier in the week, > apparently not reported to the lists at the time.) >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > =20 >=20 >=20 >=20 ------=_Part_0_597764175.1646649539431 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, I spoke to soon too. Often it crashes as soon= as I start a parallel poudriere build. But this time it went very far. As = soon as nightly backups kicked in it was game over again.
I had read the mail of Bob on the arm@ ML. But I wanted to let the conclusi= on that it is about the same problem to the developers. (Have seen enough o= f wrong guessing of causes in my work. =F0=9F=98=89)

I will need to go further into the binary search of working kernels.

This was: FreeBSD 14.0-CURRENT #0 912df91: Wed Mar  2 00:36:35 UTC 202= 2 
Fatal data abort:         &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     
  x0: ffff000000f1efd8  x0: ffff000000f1efd8 (mac_policy_rm + 0) =
(mac_policy_rm + 0)         &n=
bsp;            =
;            &n=
bsp;            &nbs=
p;
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x1:           =
;     2  x1:      &n=
bsp;         2   &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;         
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x2: ffff00000087dcf2  x2: ffff00000087dcf2 (cam_status_table + =
2f28a)           &nb=
sp;            =
            &nb=
sp;            =
            
 (cam_status_table + 2f28a)  x3: ffff00000087dcf2  &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     
  x3: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + =
2f28a)           &nb=
sp;            =
            &nb=
sp;            =
       
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x4:           =
;   102  x4:        =
      102       =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x5:           =
;     7  x5:      &n=
bsp;         1   &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;         
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x6:           =
;     0  x6:      &n=
bsp;        ff    &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;        
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x7:           =
;     0  x7: ffffa00011fc2800   &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;         
  x8:           =
;     1        =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
  
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
  x8:           =
;     1  x9: ffff000000f37c10   &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;         
  x9: ffff0000419d9090 (pcpu0 + 90) (g_ctx + 40278fe4)  &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;            
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x10: ffffa0017be2a600 x10: ffffa000010fa600    &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;        
 x11: 394aed08d0003a48        =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
  
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x12: 350001a8b946a108 x11:       &=
nbsp;        0    &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;        
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x12: ffff000000f37c10 x13:       &=
nbsp; badecce4 (pcpu0 + 90)        =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;    
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x13: ffffa0001fbde6b0 x14:       &=
nbsp;        0    &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;        
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x14:         4965ae49 x15:&nb=
sp;            =
   1          &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;  
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x15:          1000193 x1=
6: ffff0000016a4238         &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;   
 x16: ffff000100482d38 (__stop_set_modmetadata_set + d00) (__stop_set_=
modmetadata_set + 448)         =
;            &n=
bsp;            =
;      
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x17: ffff00000044a998 x17: ffff00000058ff30 (free + 0) (if_inc_counte=
r + 0)           &nb=
sp;            =
            &nb=
sp;            =
       
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x18: ffff0000b49a23c0 x18: ffff000103f11b80 (g_ctx + b3242314) &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     
 (next_index + 3a228c0) x19:       =
       102      =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      

            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
      
 x19:           =
;   102 x20: ffff0000b49a2428      =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       
 x20: ffff000103f11be8 (g_ctx + b324237c) (next_index + 3a22928) =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;    

 x21: ffff00000087dcf2 x21: ffff00000087dcf2 (cam_status_table + 2f28a=
) (cam_status_table + 2f28a)

 x22: ffff000000f1efd8 x22: ffff000000f1efd8 (mac_policy_rm + 0) (mac_=
policy_rm + 0)

 x23: ffff00000086f107 x23:       &=
nbsp;        0 (cam_status_table + 2069f=
)

 x24: ffffa0001fbde6c8 x24: ffffa0008cba0d00
 x25:           =
;     0

 x25: ffff00000088aa11 x26:       &=
nbsp;        4 (do_execve.fexecv_proc_ti=
tle + 76b7)

 x27:           =
;     0 x26: ffffa0017be2a600
 x28: ffff00010209fcf0
 x27: ffffa00025626a80 (next_index + 1bb0a30)

 x28: ffff000103f11ce0 x29: ffff0000b49a23e0 (next_index + 3a22a20) (g=
_ctx + b3242334)

 x29: ffff000103f11ba0  sp: ffff0000b49a23c0
 (next_index + 3a228e0)  lr: ffff00000046ef98
  sp: ffff000103f11b80
 (_rm_runlock_debug + 60)  lr: ffff00000046ef98
 elr: ffff00000046dc0c (_rm_runlock_debug + 60) (_rm_assert + a4)

 elr: ffff00000046dc0cspsr:       &=
nbsp;       45
 (_rm_assert + a4) far:        =
;       10

 esr:         96000004
spsr:           &nbs=
p;   45

panic: data abort in critical section or under mutex
cpuid =3D 1
time =3D 1646609483
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2d4
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
_rm_assert() at _rm_assert+0xa4
_rm_runlock_debug() at _rm_runlock_debug+0x5c
mac_inpcb_check_deliver() at mac_inpcb_check_deliver+0x74
tcp_input_with_port() at tcp_input_with_port+0xab4
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x2e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_demux() at ether_demux+0x178
ether_nh_input() at ether_nh_input+0x3e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_input() at ether_input+0x80
if_input() at if_input+0xc
gen_intr() at gen_intr+0x444
ithread_loop() at ithread_loop+0x2a0
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100063 ]
Stopped at      kdb_enter+0x44: undefined &nb=
sp;     f902011f
db>

NB: db> reboot/reset/halt does not work on my RPI4. Luckily I have a wif= i connected power switch on it.

Regards,
Ronald.

 

Van: Mark Millard <marklmi@yahoo.com>
Datum: maandag, 7 maart 2022 02:01
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: freebsd-current <freebsd-current@freebsd.org>, b= ob prohaska <fbsd@www.zefox.net>
Onderwerp: Re: panic: data abort in critical section or un= der mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 1= 4-CURRENT/aarch64 Feb 28))

From: Ronald Klop <ronald-list= s_at_klop.ws> wrote on
Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) :

> Did some binary search with kernels from artifact.ci.freebsd.org.
>
> I suspect "rmlock: Micro-optimize read locking" as cause. >
> https://cgit.freebsd.org/src/commit/?id=3Dc84bb8cd= 771ce4bed58152e47a32dda470bef23a
>
>
> And "rmlock: Add required compiler barriers to _rm_runlock()"= ; as solution.
>
> https://cgit.freebsd.org/src/commit/?id=3D89ae8eb7= 4e87ac19aa2d7abe4ba16bcccd32bb9f
>
>
> So I probably just had a bad day.

Well, there is a report of a buildkernel crash after that pair:

https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.htm= l

that references additional information at:

http://= www.zefox.net/~fbsd/rpi3/crashes/20220304/readme

and reported:

QUOTE
The console connection dropped before the crash (unrelated) I didn't
get the preamble, all  I have is the backtrace and buildkernel log. Here's the backtrace:
db> bt
Tracing pid 14795 tid 100098 td 0xffffa00017815600
db_trace_self() at db_trace_self
db_stack_trace() at db_stack_trace+0x11c
db_command() at db_command+0x368
db_command_loop() at db_command_loop+0x54
db_trap() at db_trap+0xf8
kdb_trap() at kdb_trap+0x1cc
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0xf2000000
kdb_enter() at kdb_enter+0x44
vpanic() at vpanic+0x1b0
panic() at panic+0x44
data_abort() at data_abort+0x2e8
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
_rm_rlock_debug() at _rm_rlock_debug+0x8c
sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140
sysctl_root() at sysctl_root+0x1ac
userland_sysctl() at userland_sysctl+0x140
sys___sysctl() at sys___sysctl+0x68
do_el0_sync() at do_el0_sync+0x520
handle_el0_sync() at handle_el0_sync+0x40
--- exception, esr 0x56000000
END QUOTE

The above material does reference _rm_rlock_debug . Might be
related?

The readme reports:

main-n253603-0b25cbc79d3: Thu Mar  3 22:48:31 PST 2022

for the system doing the buildkernel. This is after
89ae8eb74e8 .

(It also mentions another panic earlier in the week,
apparently not reported to the lists at the time.)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com
 
------=_Part_0_597764175.1646649539431-- From nobody Mon Mar 7 11:16:09 2022 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 819F61A0619E for ; Mon, 7 Mar 2022 11:16:23 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::221]) (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 4KBwrQ03QWz4VLN for ; Mon, 7 Mar 2022 11:16:21 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: (Authenticated sender: ganael.laplanche@martymac.org) by mail.gandi.net (Postfix) with ESMTPSA id 7782524000F for ; Mon, 7 Mar 2022 11:16:13 +0000 (UTC) From: Ganael Laplanche To: freebsd-current@freebsd.org Subject: fts(3) not checking for readdir(3) errors Date: Mon, 07 Mar 2022 12:16:09 +0100 Message-ID: <5661335.Zv9zXsTiuT@home.martymac.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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4KBwrQ03QWz4VLN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ganael.laplanche@martymac.org designates 2001:4b98:dc4:8::221 as permitted sender) smtp.mailfrom=ganael.laplanche@martymac.org X-Spamd-Result: default: False [-1.94 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:4b98:dc4:8::/64]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.14)[-0.143]; DMARC_NA(0.00)[martymac.org]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; CTE_CASE(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Hello, For one of my projects, I've received a patch to our implementation of fts(3) which does not check for readdir(3) errors. The patch seemed obvious and looked OK to me so I merged it to my project. I think we should merge it to FreeBSD too so I've opened a PR (with the patch) here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262038 Could a src committer have a look at it please ? Thanks in advance, Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From nobody Mon Mar 7 13:46:09 2022 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 8B93519FCB88; Mon, 7 Mar 2022 13:46:13 +0000 (UTC) (envelope-from SRS0=34E+=TS=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 4KC09J2yY3z4vRp; Mon, 7 Mar 2022 13:46:12 +0000 (UTC) (envelope-from SRS0=34E+=TS=klop.ws=ronald-lists@realworks.nl) Date: Mon, 7 Mar 2022 14:46:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1646660769; 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=loPRI9HeODZSw7f9ycpQAjFrmToqcGoe6XqdEdwAgNg=; b=br12TzQSUvGpgQR9Z56F/OEV88yVvYb0RON3JDglBicovXSf9SBAA7RCVbWEY/GeCAUKRC MBpIMHtDqYhU6Jvb5GZWlqm6cM6U+vC+rTv5sgf1gWWHyxKTJ+jMskmAe6vwzlpM7NZiNH I4tEFDLeDOsxvi5O2sAaNH3ELc4QW2oRjbVTmrYN7vr+XJxrATmCWFTDCyTMJgHFmRCTa7 aTP6mP36eiydAFa297epEo9GHPNTK2xKBubYuY9uav3JexxW8yAu5LDS17zlfl9Iz5hMXw 9lMspIzK3ZmdeQRLwfmJNCxmjadskrQnOYJO259Hu2PP9ArhhPFFxgi9qa/JBQ== From: Ronald Klop To: Mark Johnston Cc: bob prohaska , Mark Millard , freebsd-arm@freebsd.org, freebsd-current Message-ID: <132978150.92.1646660769467@mailrelay> In-Reply-To: <1800459695.1.1646649539521@mailrelay> References: <1800459695.1.1646649539521@mailrelay> Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) 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_91_1813909039.1646660769454" X-Mailer: Realworks (599.211.aa1e011) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4KC09J2yY3z4vRp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=br12TzQS; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=34E@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=34E@realworks.nl" X-Spamd-Result: default: False [-3.18 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.98)[-0.978]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=34E@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; TAGGED_FROM(0.00)[=TS=klop.ws=ronald-lists]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=34E@realworks.nl]; FREEMAIL_CC(0.00)[www.zefox.net,yahoo.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_91_1813909039.1646660769454 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear Mark Johnston, I did some binary search in the kernels and came to the conclusion that https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e still works and https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a panics. I suspect your commit in https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a. Last panic: panic: vm_fault failed: ffff00000046e708 error 1 cpuid = 1 time = 1646660058 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 data_abort() at data_abort+0x2e8 handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0x96000004 _rm_rlock_debug() at _rm_rlock_debug+0x8c osd_get() at osd_get+0x5c zio_execute() at zio_execute+0xf8 taskqueue_run_locked() at taskqueue_run_locked+0x178 taskqueue_thread_loop() at taskqueue_thread_loop+0xc8 fork_exit() at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x14 KDB: enter: panic [ thread pid 0 tid 100129 ] Stopped at kdb_enter+0x44: undefined f902011f db> A more recent kernel (912df91) still panics. See below. Do you have time to look into this? What can I provide in information to help? Regards, Ronald. Van: Ronald Klop Datum: maandag, 7 maart 2022 11:38 Aan: Mark Millard CC: bob prohaska , freebsd-current , freebsd-arm@freebsd.org Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) > > Yes, I spoke to soon too. Often it crashes as soon as I start a parallel poudriere build. But this time it went very far. As soon as nightly backups kicked in it was game over again. > I had read the mail of Bob on the arm@ ML. But I wanted to let the conclusion that it is about the same problem to the developers. (Have seen enough of wrong guessing of causes in my work. ) > > I will need to go further into the binary search of working kernels. > > This was: FreeBSD 14.0-CURRENT #0 912df91: Wed Mar 2 00:36:35 UTC 2022 > Fatal data abort: > x0: ffff000000f1efd8 x0: ffff000000f1efd8 (mac_policy_rm + 0) (mac_policy_rm + 0) > > x1: 2 x1: 2 > > x2: ffff00000087dcf2 x2: ffff00000087dcf2 (cam_status_table + 2f28a) > (cam_status_table + 2f28a) x3: ffff00000087dcf2 > x3: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + 2f28a) > > x4: 102 x4: 102 > > x5: 7 x5: 1 > > x6: 0 x6: ff > > x7: 0 x7: ffffa00011fc2800 > x8: 1 > > x8: 1 x9: ffff000000f37c10 > x9: ffff0000419d9090 (pcpu0 + 90) (g_ctx + 40278fe4) > > x10: ffffa0017be2a600 x10: ffffa000010fa600 > x11: 394aed08d0003a48 > > x12: 350001a8b946a108 x11: 0 > > x12: ffff000000f37c10 x13: badecce4 (pcpu0 + 90) > > x13: ffffa0001fbde6b0 x14: 0 > > x14: 4965ae49 x15: 1 > > x15: 1000193 x16: ffff0000016a4238 > x16: ffff000100482d38 (__stop_set_modmetadata_set + d00) (__stop_set_modmetadata_set + 448) > > x17: ffff00000044a998 x17: ffff00000058ff30 (free + 0) (if_inc_counter + 0) > > x18: ffff0000b49a23c0 x18: ffff000103f11b80 (g_ctx + b3242314) > (next_index + 3a228c0) x19: 102 > > > x19: 102 x20: ffff0000b49a2428 > x20: ffff000103f11be8 (g_ctx + b324237c) (next_index + 3a22928) > > x21: ffff00000087dcf2 x21: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + 2f28a) > > x22: ffff000000f1efd8 x22: ffff000000f1efd8 (mac_policy_rm + 0) (mac_policy_rm + 0) > > x23: ffff00000086f107 x23: 0 (cam_status_table + 2069f) > > x24: ffffa0001fbde6c8 x24: ffffa0008cba0d00 > x25: 0 > > x25: ffff00000088aa11 x26: 4 (do_execve.fexecv_proc_title + 76b7) > > x27: 0 x26: ffffa0017be2a600 > x28: ffff00010209fcf0 > x27: ffffa00025626a80 (next_index + 1bb0a30) > > x28: ffff000103f11ce0 x29: ffff0000b49a23e0 (next_index + 3a22a20) (g_ctx + b3242334) > > x29: ffff000103f11ba0 sp: ffff0000b49a23c0 > (next_index + 3a228e0) lr: ffff00000046ef98 > sp: ffff000103f11b80 > (_rm_runlock_debug + 60) lr: ffff00000046ef98 > elr: ffff00000046dc0c (_rm_runlock_debug + 60) (_rm_assert + a4) > > elr: ffff00000046dc0cspsr: 45 > (_rm_assert + a4) far: 10 > > esr: 96000004 > spsr: 45 > > panic: data abort in critical section or under mutex > cpuid = 1 > time = 1646609483 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x174 > panic() at panic+0x44 > data_abort() at data_abort+0x2d4 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x96000004 > _rm_assert() at _rm_assert+0xa4 > _rm_runlock_debug() at _rm_runlock_debug+0x5c > mac_inpcb_check_deliver() at mac_inpcb_check_deliver+0x74 > tcp_input_with_port() at tcp_input_with_port+0xab4 > tcp_input() at tcp_input+0xc > ip_input() at ip_input+0x2e8 > netisr_dispatch_src() at netisr_dispatch_src+0xe4 > ether_demux() at ether_demux+0x178 > ether_nh_input() at ether_nh_input+0x3e8 > netisr_dispatch_src() at netisr_dispatch_src+0xe4 > ether_input() at ether_input+0x80 > if_input() at if_input+0xc > gen_intr() at gen_intr+0x444 > ithread_loop() at ithread_loop+0x2a0 > fork_exit() at fork_exit+0x74 > fork_trampoline() at fork_trampoline+0x14 > KDB: enter: panic > [ thread pid 12 tid 100063 ] > Stopped at kdb_enter+0x44: undefined f902011f > db> > > NB: db> reboot/reset/halt does not work on my RPI4. Luckily I have a wifi connected power switch on it. > > Regards, > Ronald. > > > Van: Mark Millard > Datum: maandag, 7 maart 2022 02:01 > Aan: Ronald Klop > CC: freebsd-current , bob prohaska > Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) >> >> From: Ronald Klop wrote on >> Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) : >> >> > Did some binary search with kernels from artifact.ci.freebsd.org. >> > >> > I suspect "rmlock: Micro-optimize read locking" as cause. >> > >> > https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a >> > >> > >> > And "rmlock: Add required compiler barriers to _rm_runlock()" as solution. >> > >> > https://cgit.freebsd.org/src/commit/?id=89ae8eb74e87ac19aa2d7abe4ba16bcccd32bb9f >> > >> > >> > So I probably just had a bad day. >> >> Well, there is a report of a buildkernel crash after that pair: >> >> https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.html >> >> that references additional information at: >> >> http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme >> >> and reported: >> >> QUOTE >> The console connection dropped before the crash (unrelated) I didn't >> get the preamble, all I have is the backtrace and buildkernel log. >> Here's the backtrace: >> db> bt >> Tracing pid 14795 tid 100098 td 0xffffa00017815600 >> db_trace_self() at db_trace_self >> db_stack_trace() at db_stack_trace+0x11c >> db_command() at db_command+0x368 >> db_command_loop() at db_command_loop+0x54 >> db_trap() at db_trap+0xf8 >> kdb_trap() at kdb_trap+0x1cc >> handle_el1h_sync() at handle_el1h_sync+0x10 >> --- exception, esr 0xf2000000 >> kdb_enter() at kdb_enter+0x44 >> vpanic() at vpanic+0x1b0 >> panic() at panic+0x44 >> data_abort() at data_abort+0x2e8 >> handle_el1h_sync() at handle_el1h_sync+0x10 >> --- exception, esr 0x96000004 >> _rm_rlock_debug() at _rm_rlock_debug+0x8c >> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140 >> sysctl_root() at sysctl_root+0x1ac >> userland_sysctl() at userland_sysctl+0x140 >> sys___sysctl() at sys___sysctl+0x68 >> do_el0_sync() at do_el0_sync+0x520 >> handle_el0_sync() at handle_el0_sync+0x40 >> --- exception, esr 0x56000000 >> END QUOTE >> >> The above material does reference _rm_rlock_debug . Might be >> related? >> >> The readme reports: >> >> main-n253603-0b25cbc79d3: Thu Mar 3 22:48:31 PST 2022 >> >> for the system doing the buildkernel. This is after >> 89ae8eb74e8 . >> >> (It also mentions another panic earlier in the week, >> apparently not reported to the lists at the time.) >> >> === >> Mark Millard >> marklmi at yahoo.com >> >> >> >> > ------=_Part_91_1813909039.1646660769454 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Mark Johnston,

I did some binary search in the kernels and came to the conclusion that https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e still works and https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a panics.

I suspect your commit in https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a.

Last panic:

panic: vm_fault failed: ffff00000046e708 error 1
cpuid = 1
time = 1646660058
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2e8
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
_rm_rlock_debug() at _rm_rlock_debug+0x8c
osd_get() at osd_get+0x5c
zio_execute() at zio_execute+0xf8
taskqueue_run_locked() at taskqueue_run_locked+0x178
taskqueue_thread_loop() at taskqueue_thread_loop+0xc8
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 0 tid 100129 ]
Stopped at      kdb_enter+0x44: undefined       f902011f
db>

A more recent kernel (912df91) still panics. See below.

Do you have time to look into this? What can I provide in information to help?

Regards,
Ronald.

 

Van: Ronald Klop <ronald-lists@klop.ws>
Datum: maandag, 7 maart 2022 11:38
Aan: Mark Millard <marklmi@yahoo.com>
CC: bob prohaska <fbsd@www.zefox.net>, freebsd-current <freebsd-current@freebsd.org>, freebsd-arm@freebsd.org
Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))

Yes, I spoke to soon too. Often it crashes as soon as I start a parallel poudriere build. But this time it went very far. As soon as nightly backups kicked in it was game over again.
I had read the mail of Bob on the arm@ ML. But I wanted to let the conclusion that it is about the same problem to the developers. (Have seen enough of wrong guessing of causes in my work. )

I will need to go further into the binary search of working kernels.

This was: FreeBSD 14.0-CURRENT #0 912df91: Wed Mar  2 00:36:35 UTC 2022 
Fatal data abort:                                                                                                                   
  x0: ffff000000f1efd8  x0: ffff000000f1efd8 (mac_policy_rm + 0) (mac_policy_rm + 0)                                                
                                                                                                                                    
  x1:                2  x1:                2                                                                                        
                                                                                                                                    
  x2: ffff00000087dcf2  x2: ffff00000087dcf2 (cam_status_table + 2f28a)                                                             
 (cam_status_table + 2f28a)  x3: ffff00000087dcf2                                                                                   
  x3: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + 2f28a)                                                        
                                                                                                                                    
  x4:              102  x4:              102                                                                                        
                                                                                                                                    
  x5:                7  x5:                1                                                                                        
                                                                                                                                    
  x6:                0  x6:               ff                                                                                        
                                                                                                                                    
  x7:                0  x7: ffffa00011fc2800                                                                                        
  x8:                1                                                                                                              
                                                                                                                                    
  x8:                1  x9: ffff000000f37c10                                                                                        
  x9: ffff0000419d9090 (pcpu0 + 90) (g_ctx + 40278fe4)                                                                              
                                                                                                                                    
 x10: ffffa0017be2a600 x10: ffffa000010fa600                                                                                        
 x11: 394aed08d0003a48                                                                                                              
                                                                                                                                    
 x12: 350001a8b946a108 x11:                0                                                                                        
                                                                                                                                    
 x12: ffff000000f37c10 x13:         badecce4 (pcpu0 + 90)                                                                           
                                                                                                                                    
 x13: ffffa0001fbde6b0 x14:                0                                                                                        
                                                                                                                                    
 x14:         4965ae49 x15:                1                                                                                        
                                                                                                                                    
 x15:          1000193 x16: ffff0000016a4238                                                                                        
 x16: ffff000100482d38 (__stop_set_modmetadata_set + d00) (__stop_set_modmetadata_set + 448)                                        
                                                                                                                                    
 x17: ffff00000044a998 x17: ffff00000058ff30 (free + 0) (if_inc_counter + 0)                                                        
                                                                                                                                    
 x18: ffff0000b49a23c0 x18: ffff000103f11b80 (g_ctx + b3242314)                                                                     
 (next_index + 3a228c0) x19:              102                                                                                       

                                                                                                                                   
 x19:              102 x20: ffff0000b49a2428                                                                                        
 x20: ffff000103f11be8 (g_ctx + b324237c) (next_index + 3a22928)                                                                    

 x21: ffff00000087dcf2 x21: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + 2f28a)

 x22: ffff000000f1efd8 x22: ffff000000f1efd8 (mac_policy_rm + 0) (mac_policy_rm + 0)

 x23: ffff00000086f107 x23:                0 (cam_status_table + 2069f)

 x24: ffffa0001fbde6c8 x24: ffffa0008cba0d00
 x25:                0

 x25: ffff00000088aa11 x26:                4 (do_execve.fexecv_proc_title + 76b7)

 x27:                0 x26: ffffa0017be2a600
 x28: ffff00010209fcf0
 x27: ffffa00025626a80 (next_index + 1bb0a30)

 x28: ffff000103f11ce0 x29: ffff0000b49a23e0 (next_index + 3a22a20) (g_ctx + b3242334)

 x29: ffff000103f11ba0  sp: ffff0000b49a23c0
 (next_index + 3a228e0)  lr: ffff00000046ef98
  sp: ffff000103f11b80
 (_rm_runlock_debug + 60)  lr: ffff00000046ef98
 elr: ffff00000046dc0c (_rm_runlock_debug + 60) (_rm_assert + a4)

 elr: ffff00000046dc0cspsr:               45
 (_rm_assert + a4) far:               10

 esr:         96000004
spsr:               45

panic: data abort in critical section or under mutex
cpuid = 1
time = 1646609483
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2d4
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
_rm_assert() at _rm_assert+0xa4
_rm_runlock_debug() at _rm_runlock_debug+0x5c
mac_inpcb_check_deliver() at mac_inpcb_check_deliver+0x74
tcp_input_with_port() at tcp_input_with_port+0xab4
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x2e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_demux() at ether_demux+0x178
ether_nh_input() at ether_nh_input+0x3e8
netisr_dispatch_src() at netisr_dispatch_src+0xe4
ether_input() at ether_input+0x80
if_input() at if_input+0xc
gen_intr() at gen_intr+0x444
ithread_loop() at ithread_loop+0x2a0
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100063 ]
Stopped at      kdb_enter+0x44: undefined       f902011f
db>

NB: db> reboot/reset/halt does not work on my RPI4. Luckily I have a wifi connected power switch on it.

Regards,
Ronald.

 

Van: Mark Millard <marklmi@yahoo.com>
Datum: maandag, 7 maart 2022 02:01
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: freebsd-current <freebsd-current@freebsd.org>, bob prohaska <fbsd@www.zefox.net>
Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))

From: Ronald Klop <ronald-lists_at_klop.ws> wrote on
Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) :

> Did some binary search with kernels from artifact.ci.freebsd.org.
>
> I suspect "rmlock: Micro-optimize read locking" as cause.
>
> https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a
>
>
> And "rmlock: Add required compiler barriers to _rm_runlock()" as solution.
>
> https://cgit.freebsd.org/src/commit/?id=89ae8eb74e87ac19aa2d7abe4ba16bcccd32bb9f
>
>
> So I probably just had a bad day.

Well, there is a report of a buildkernel crash after that pair:

https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.html

that references additional information at:

http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme

and reported:

QUOTE
The console connection dropped before the crash (unrelated) I didn't
get the preamble, all  I have is the backtrace and buildkernel log.
Here's the backtrace:
db> bt
Tracing pid 14795 tid 100098 td 0xffffa00017815600
db_trace_self() at db_trace_self
db_stack_trace() at db_stack_trace+0x11c
db_command() at db_command+0x368
db_command_loop() at db_command_loop+0x54
db_trap() at db_trap+0xf8
kdb_trap() at kdb_trap+0x1cc
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0xf2000000
kdb_enter() at kdb_enter+0x44
vpanic() at vpanic+0x1b0
panic() at panic+0x44
data_abort() at data_abort+0x2e8
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000004
_rm_rlock_debug() at _rm_rlock_debug+0x8c
sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140
sysctl_root() at sysctl_root+0x1ac
userland_sysctl() at userland_sysctl+0x140
sys___sysctl() at sys___sysctl+0x68
do_el0_sync() at do_el0_sync+0x520
handle_el0_sync() at handle_el0_sync+0x40
--- exception, esr 0x56000000
END QUOTE

The above material does reference _rm_rlock_debug . Might be
related?

The readme reports:

main-n253603-0b25cbc79d3: Thu Mar  3 22:48:31 PST 2022

for the system doing the buildkernel. This is after
89ae8eb74e8 .

(It also mentions another panic earlier in the week,
apparently not reported to the lists at the time.)

===
Mark Millard
marklmi at yahoo.com
 
------=_Part_91_1813909039.1646660769454-- From nobody Mon Mar 7 14:37:46 2022 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 6D1B11A091DC for ; Mon, 7 Mar 2022 14:37:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KC1Jz4RMGz3MvP for ; Mon, 7 Mar 2022 14:37:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646663868; bh=7kHVrKu9oXlIEbV3NBPRG6N/pa7eH09AMl3KAfRQxWk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oAJxDSwmrS34oKP5Hhbiof6YTwidw8J8R4zVmrmSgemeohFeSnwJe0XldqC1QxWTyd2WhkGx1YAv1+Ak98d+wEkWw/GFJH8/BRh1UbhILyYzft8Rl1oMxCGkMAjmpgUT2vYG0WrCkfOSc4cu7sPmu0cyaTZIc6dKOzC/uDRGmCENozRxK+paEb86ccw2GnrVPH/VDlWzXwTzsaZTiukp2wIjKXYrhGo6msgAOaHM8IEbDi828t7Jt+yWEjGrmWl0AvG5XCtLKXDZHgxNmZ2qshuibWYoXm5wfyuxMRTlfj5qYfgjRDN1HUZzgMhpTFmIQepSJVjqlt+8RMdOfZB+jQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646663868; bh=LdrCv26l+T62kLuaxuIxgGxCCWrx1VMnanmN8oql19c=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rbbBIA542RDgZ9+HOdb/DX5iHhJb2s+zsMno+YuNLPH/q3h0lzDAgK3f3kW2WfOYW/jRCto1begxtHe8i9LEDx5fvVee+40GrkoKn8akk+rKxxeUczeIlmDLcNJx14WEehKf00sNdyVEA06auStG6A+WalJ8jEHtI0PW797qKXCSvlmg2EMtjy/r9BIpaP0nzzFlVZSKHi/3btAHWfj/1I88WN/tB3l6FobX6szhzCXDQYCjJ8DRB+6opiPwzsDcCRZc90cXxNezFYW6ShJGNwXe5h4SpMGcglKHPCxy+9Rf7rRHTe9gGCMVw6QehojJ5YumoFADgyFdaHtEVYDsmA== X-YMail-OSG: Bb_cLScVM1nHCq0Tn57u5zAbCRG0P3eEuLc_kgI67v9NteVA657teiE1KPx0yIG HtVLRsnn33vh5GIdfdh5eqbOgk4ULgT5IMmDDvKi_1GAziSAHlSr3MqtdMARtH3l3xD12CClGsy4 3YfT2DR7HvN0UEI5aldyoIYa1vPq6EtznDN0Vp3LlUAVs5P6x0pEoq1oCZCRCSVDL.qsHxS6CHVj wJuIxRIDiFPXUxzDzKUZeSnFBMq9MnxJu__C6Df2hqo6k34lf60eaDXOJE_yMI7X9k6U7r.vZ.dG gArgEofvBFDpyV4l6AiQvbk6r4i0rEnzyq.PN11G_iE93lx5a6Ag5ddjijcApFv_UvhcEV2xaVEF V50mQPb0Cy0w7ZmfnWinjHOvdWjyXi0OHcPDBDh9WMmVAt2xwiTnYqRhvH9Wc4YDINyH_yBdCQFN KNIAC19Z_13sej2LI8XoywVEJeQhrzuWQ0DabNS6Ekqx_Uu.WDTPq9NDXxa7jDHWkjfR199o0MTD k4ciW.NdkC.rMxYsFKsz4Qb5hVCifMCBl2ad2VXu1TpG2g4s4kh9vm5pa0wKXBMPStMZHBbOR9oz WC0iWgpPhcyVz8v1jlMKUkZToJEUbwn9U0OpIqj51KKViXadNZH3ToLfdN4Cw5LMBVxPACRGm0Wr xo_CVtnmqiz7KRIPwVTVujHeVvzQfxerkoQXfX1MOs.uPQcAfdY.4h4UUQJnCbqGfYMIW11HABxA D2BRj0Aqdp6AXCDjIKLWDOZzpioi17sSrJO1SkhhcfwGZZRIs9gZzPAmXGwH7ORWdc8se0JZqjwc GeuSDXZ4dFEeuW7Sc9u_v.P2UABsDKXk2T.uxCeb2XvbUFMx_nggeYuqrHcmomNM1RFL0wljrBGH ZlAgfY9gd5St83j5bMtOqudOIPyp1NWKWFUfJrynPXjIVKN87HLU.oo0XFvv7RnXIZQmKBlnK4yM zI1ex99ar4iU0lrmarLZqZWvXT2Ov59Ykte2ioNR2oEy7LsZvnc8dE0xGeRJQcET4g1lBsWPWXUR Hhv4_jhn4s6VRrlY_bOHh_ffkb5DGuZx4._riHu2yjar39RqCRvN0lgxlxxv7I2KvnEaghi_xbj9 XPe02Eyq9dUYs_C64jMhr36D2HxQMEt1eEoNN_cQDtucSJ1QuXp...hKPu.myCyXRFDMXICgpk.f A13feBmqd9yBqI.AR6fRvmE9RWhGXT0GloJZIX6qpeM96_cjcvClNB.ocxy0cIHC4XbBkRKCH11N FPNIqTYekXogYya9g8XtbgAovqztP6ppoTEhQsNMmFIN2HzFCKw4QH3M.HGl_ZcpnxbF4BnmJ3ZY owKT.y99ya_k33gIUez8E75U.0.nRsm_gF_D._Yr0Fk5InkymV318cbfM7tGDOkWrEmlgLUFFoCZ jOQQFfe6UbAmt_hkR2q2aXvHSy3IcZrm4yUciU.iS8XIPyHPQ_BlpR3JNaAk3r3oORQI3RDYsEyp Oq8tesBRrFNDF4Gj6s9HetZ4gVt98fjAlySHR9PodJB0jAd8v7PiJcde59wEK_dXfPYxetYLyxaY 8okEJuEFPFPvrPMlv0jRPeqPXAgKuRHn8tCCKrHhx8GOXaJG4n_c33mv8tFrRZn6R64R9JLHBdC1 qa25rn2b5U1UDmRT8OkG9bNA7F70j.fzllyILrZ9CWRcIz0rTsnpdRff3iv.VEwBuXLmxkuHEE1y 2SHBE8IotCjFzgaArFKGiJVF_DTkydrR8bFNZwi8BhCHRC65_viSTYGPYcdaHStQqlI5wPnJIZ4z iz2OPothyXqz5nvspYo_A2Kt.Vynlo8jvOi1.D75dEaFzI4I0b4Q7oFEOR8LUmMZi81Tr2fE2AJJ UiB3DR6rpCF.uOt_KfSCgycSlbZgowxzwRiQLTYj8vlvZaOm8Wn.6Cmqenw4ioZr3cu3CyyO9n7r WnJXW1jTNOFGY.NQkAkuNLooS5vqBM1svoVxO63PKvaUT.EQSwB7CbMCDBKFad31KTLU0oEX9nes Xi_mkzz4nBjyKKW_R1oMPxRyjqp8F.NS8D_iFwEfyryk3Azbpc_U2doknfXfkVW.pMwuNu4vjOd5 mfKsvk0KnDRJiNeWc4p1U7uQIrs9bj_lmsCFs2XU8sHBoekuhMAqttvKuAKxXdXaWU7KmSQI86ju 0Bh9Rx7x7uHEXVK6oFUpSQBQQHCy4GZM5nFw9eFuttCz_l_ySLRiSE1g6gMowPkGWBx6zsdNNqgk tNP0Jo0y9SB9Mx8HyCR62yyUsrhlz.O0AOvCY3WWgxVzfdEYsPsN6TD4iMSbVOXzLEZxLBYohYmt EhcteZ83a84DEJvRcHaP7gKlLXvwh8fQZ9XyIw1.qWBqK7uNf5LhLfNLFHyX502B_tLiiIOr6OfC mhwEyYl2T6g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Mar 2022 14:37:48 +0000 Received: by kubenode549.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e531a35fae5a7c14a8e4be774e4c7a63; Mon, 07 Mar 2022 14:37:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) From: Mark Millard X-Priority: 3 (Normal) In-Reply-To: <132978150.92.1646660769467@mailrelay> Date: Mon, 7 Mar 2022 06:37:46 -0800 Cc: bob prohaska , Free BSD , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <10724FB9-8E75-4DB7-A0F4-CFF55D21272B@yahoo.com> References: <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay> To: Ronald Klop , Mark Johnston X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KC1Jz4RMGz3MvP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=oAJxDSwm; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.54 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.73)[-0.727]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.69)[0.690]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Mar-7, at 05:46, Ronald Klop wrote: > Dear Mark Johnston, >=20 > I did some binary search in the kernels and came to the conclusion = that = https://cgit.freebsd.org/src/commit/?id=3D1517b8d5a7f58897200497811de1b188= 09c07d3e still works and = https://cgit.freebsd.org/src/commit/?id=3D407c34e735b5d17e2be574808a09e6d7= 29b0a45a panics. >=20 > I suspect your commit in = https://cgit.freebsd.org/src/commit/?id=3Dc84bb8cd771ce4bed58152e47a32dda4= 70bef23a. >=20 > Last panic: >=20 > panic: vm_fault failed: ffff00000046e708 error 1 > cpuid =3D 1 > time =3D 1646660058 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x174 > panic() at panic+0x44 > data_abort() at data_abort+0x2e8 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x96000004 > _rm_rlock_debug() at _rm_rlock_debug+0x8c > osd_get() at osd_get+0x5c > zio_execute() at zio_execute+0xf8 > taskqueue_run_locked() at taskqueue_run_locked+0x178 > taskqueue_thread_loop() at taskqueue_thread_loop+0xc8 > fork_exit() at fork_exit+0x74 > fork_trampoline() at fork_trampoline+0x14 > KDB: enter: panic > [ thread pid 0 tid 100129 ] > Stopped at kdb_enter+0x44: undefined f902011f > db> Was this a WITNESS/DEBUG kernel? Non-WITNESS? Non-debug? Which aarch64 variant? Bob's was Cortex-A53 (RPi3). > A more recent kernel (912df91) still panics. See below. >=20 > Do you have time to look into this? What can I provide in information = to help? >=20 > Regards, > Ronald. >=20 > Van: Ronald Klop > Datum: maandag, 7 maart 2022 11:38 > Aan: Mark Millard > CC: bob prohaska , freebsd-current = , freebsd-arm@freebsd.org > Onderwerp: Re: panic: data abort in critical section or under mutex = (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on = 14-CURRENT/aarch64 Feb 28)) >=20 > Yes, I spoke to soon too. Often it crashes as soon as I start a = parallel poudriere build. But this time it went very far. As soon as = nightly backups kicked in it was game over again. > I had read the mail of Bob on the arm@ ML. But I wanted to let the = conclusion that it is about the same problem to the developers. (Have = seen enough of wrong guessing of causes in my work. ) >=20 > I will need to go further into the binary search of working kernels. >=20 > This was: FreeBSD 14.0-CURRENT #0 912df91: Wed Mar 2 00:36:35 UTC = 2022 > Fatal data abort: = =20 > x0: ffff000000f1efd8 x0: ffff000000f1efd8 (mac_policy_rm + 0) = (mac_policy_rm + 0) =20 > = =20 > x1: 2 x1: 2 = =20 > = =20 > x2: ffff00000087dcf2 x2: ffff00000087dcf2 (cam_status_table + = 2f28a) =20 > (cam_status_table + 2f28a) x3: ffff00000087dcf2 = =20 > x3: ffff00000087dcf2 (cam_status_table + 2f28a) (cam_status_table + = 2f28a) =20 > = =20 > x4: 102 x4: 102 = =20 > = =20 > x5: 7 x5: 1 = =20 > = =20 > x6: 0 x6: ff = =20 > = =20 > x7: 0 x7: ffffa00011fc2800 = =20 > x8: 1 = =20 > = =20 > x8: 1 x9: ffff000000f37c10 = =20 > x9: ffff0000419d9090 (pcpu0 + 90) (g_ctx + 40278fe4) = =20 > = =20 > x10: ffffa0017be2a600 x10: ffffa000010fa600 = =20 > x11: 394aed08d0003a48 = =20 > = =20 > x12: 350001a8b946a108 x11: 0 = =20 > = =20 > x12: ffff000000f37c10 x13: badecce4 (pcpu0 + 90) = =20 > = =20 > x13: ffffa0001fbde6b0 x14: 0 = =20 > = =20 > x14: 4965ae49 x15: 1 = =20 > = =20 > x15: 1000193 x16: ffff0000016a4238 = =20 > x16: ffff000100482d38 (__stop_set_modmetadata_set + d00) = (__stop_set_modmetadata_set + 448) =20= > = =20 > x17: ffff00000044a998 x17: ffff00000058ff30 (free + 0) = (if_inc_counter + 0) = =20 > = =20 > x18: ffff0000b49a23c0 x18: ffff000103f11b80 (g_ctx + b3242314) = =20 > (next_index + 3a228c0) x19: 102 = =20 >=20 > = =20 > x19: 102 x20: ffff0000b49a2428 = =20 > x20: ffff000103f11be8 (g_ctx + b324237c) (next_index + 3a22928) = =20 >=20 > x21: ffff00000087dcf2 x21: ffff00000087dcf2 (cam_status_table + = 2f28a) (cam_status_table + 2f28a) >=20 > x22: ffff000000f1efd8 x22: ffff000000f1efd8 (mac_policy_rm + 0) = (mac_policy_rm + 0) >=20 > x23: ffff00000086f107 x23: 0 (cam_status_table + = 2069f) >=20 > x24: ffffa0001fbde6c8 x24: ffffa0008cba0d00 > x25: 0 >=20 > x25: ffff00000088aa11 x26: 4 = (do_execve.fexecv_proc_title + 76b7) >=20 > x27: 0 x26: ffffa0017be2a600 > x28: ffff00010209fcf0 > x27: ffffa00025626a80 (next_index + 1bb0a30) >=20 > x28: ffff000103f11ce0 x29: ffff0000b49a23e0 (next_index + 3a22a20) = (g_ctx + b3242334) >=20 > x29: ffff000103f11ba0 sp: ffff0000b49a23c0 > (next_index + 3a228e0) lr: ffff00000046ef98 > sp: ffff000103f11b80 > (_rm_runlock_debug + 60) lr: ffff00000046ef98 > elr: ffff00000046dc0c (_rm_runlock_debug + 60) (_rm_assert + a4) >=20 > elr: ffff00000046dc0cspsr: 45 > (_rm_assert + a4) far: 10 >=20 > esr: 96000004 > spsr: 45 >=20 > panic: data abort in critical section or under mutex > cpuid =3D 1 > time =3D 1646609483 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x174 > panic() at panic+0x44 > data_abort() at data_abort+0x2d4 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x96000004 > _rm_assert() at _rm_assert+0xa4 > _rm_runlock_debug() at _rm_runlock_debug+0x5c > mac_inpcb_check_deliver() at mac_inpcb_check_deliver+0x74 > tcp_input_with_port() at tcp_input_with_port+0xab4 > tcp_input() at tcp_input+0xc > ip_input() at ip_input+0x2e8 > netisr_dispatch_src() at netisr_dispatch_src+0xe4 > ether_demux() at ether_demux+0x178 > ether_nh_input() at ether_nh_input+0x3e8 > netisr_dispatch_src() at netisr_dispatch_src+0xe4 > ether_input() at ether_input+0x80 > if_input() at if_input+0xc > gen_intr() at gen_intr+0x444 > ithread_loop() at ithread_loop+0x2a0 > fork_exit() at fork_exit+0x74 > fork_trampoline() at fork_trampoline+0x14 > KDB: enter: panic > [ thread pid 12 tid 100063 ] > Stopped at kdb_enter+0x44: undefined f902011f > db> >=20 >=20 > NB: db> reboot/reset/halt does not work on my RPI4. Luckily I have a = wifi connected power switch on it. >=20 > Regards, > Ronald. >=20 > Van: Mark Millard > Datum: maandag, 7 maart 2022 02:01 > Aan: Ronald Klop > CC: freebsd-current , bob prohaska = > Onderwerp: Re: panic: data abort in critical section or under mutex = (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on = 14-CURRENT/aarch64 Feb 28)) >=20 > From: Ronald Klop wrote on > Date: Sun, 6 Mar 2022 23:22:42 +0100 (CET) : >=20 > > Did some binary search with kernels from artifact.ci.freebsd.org. > > > > I suspect "rmlock: Micro-optimize read locking" as cause. > > > > = https://cgit.freebsd.org/src/commit/?id=3Dc84bb8cd771ce4bed58152e47a32dda4= 70bef23a > > > > > > And "rmlock: Add required compiler barriers to _rm_runlock()" as = solution. > > > > = https://cgit.freebsd.org/src/commit/?id=3D89ae8eb74e87ac19aa2d7abe4ba16bcc= cd32bb9f > > > > > > So I probably just had a bad day. >=20 > Well, there is a report of a buildkernel crash after that pair: >=20 > https://lists.freebsd.org/archives/freebsd-arm/2022-March/001078.html >=20 > that references additional information at: >=20 > http://www.zefox.net/~fbsd/rpi3/crashes/20220304/readme >=20 > and reported: >=20 > QUOTE > The console connection dropped before the crash (unrelated) I didn't > get the preamble, all I have is the backtrace and buildkernel log. > Here's the backtrace: > db> bt > Tracing pid 14795 tid 100098 td 0xffffa00017815600 > db_trace_self() at db_trace_self > db_stack_trace() at db_stack_trace+0x11c > db_command() at db_command+0x368 > db_command_loop() at db_command_loop+0x54 > db_trap() at db_trap+0xf8 > kdb_trap() at kdb_trap+0x1cc > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0xf2000000 > kdb_enter() at kdb_enter+0x44 > vpanic() at vpanic+0x1b0 > panic() at panic+0x44 > data_abort() at data_abort+0x2e8 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x96000004 > _rm_rlock_debug() at _rm_rlock_debug+0x8c > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140 > sysctl_root() at sysctl_root+0x1ac > userland_sysctl() at userland_sysctl+0x140 > sys___sysctl() at sys___sysctl+0x68 > do_el0_sync() at do_el0_sync+0x520 > handle_el0_sync() at handle_el0_sync+0x40 > --- exception, esr 0x56000000 > END QUOTE This was a WITNESS and debug kernel as I understand. Also, this was a RPi3, so Cortex-A53, that has in-order-execution cores. (Unlike Cortex-A72's, for example). > The above material does reference _rm_rlock_debug . Might be > related? >=20 > The readme reports: >=20 > main-n253603-0b25cbc79d3: Thu Mar 3 22:48:31 PST 2022 >=20 > for the system doing the buildkernel. This is after > 89ae8eb74e8 . >=20 > (It also mentions another panic earlier in the week, > apparently not reported to the lists at the time.) >=20 So far as I have noticed, all reports of the crashes in _rm_rlock_debug are on aarch64 hardware. So may be the problem is tied to the weak memory model --but for something that matters to a Cortex-A53's executes-in-order cores? (Just athought.) But, then, the constrasting(?) status of powerpc64 might be of note. (And I'll stop guessing here.) I do not know if any non-WITNESS/non-debug kernel builds have failed. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Mar 7 15:13:37 2022 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 DB13619EA01A; Mon, 7 Mar 2022 15:13:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KC26F0Lm9z3ltp; Mon, 7 Mar 2022 15:13:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x835.google.com with SMTP id b23so13476645qtt.6; Mon, 07 Mar 2022 07:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ke+WAIsIlx2cs1GtXexL6lDfk0mefkBVKXgofAu6iss=; b=BpTPXuU3R9MN/OHmXFHiq0A5tXnaua8zmaMgzkGmYm0a6E3OPCfSu8hQc4t+4W3bZN HM3Vtl4FW7/YPIKjMKRGqgGLC0fmdXp+uWInKBlKalpeywsEk4fSSi04m72MijRILcNW tIKsnM5yXpVMkurPP9M/YlTp1gyqkM6nBP8fgv7Cg8vw84OjIxPoTIm468P/oQKlnD+s kl/4/RQOQerohsWrs+76faqcxTQWSYuU1v7086barR+q3b8hKgsQ44zMCRuSNb4QGZWa U2sCXak5Z0KA49umbPPOwljEgI9bKp/RmJVje2OdQpnum6oz/jzK1e3/jQORdEngTqjc 87Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=ke+WAIsIlx2cs1GtXexL6lDfk0mefkBVKXgofAu6iss=; b=WdGEQ2LTJIVfwnHvOy7/OAGuStOm5L6PmA7dHv3q14K8oR3qE5Wb+TZgDaVlwH1Ns9 xgFTT4/xeHEsKS8AR6PNMj39MicuS+kPPfQTrBHiHiHLEon2d0l5UfCF6cfZpgX1vR3C WqvL6XnqKPNl5fFP1s/oDWqZgcuoNwqxjEZ8w8BEqnK374auFJH+1BSePRsgqCqKY+Ji 0RzZDRgaYIfY0FKfydUq5zV8DUVloDLYGupsO5BEwQEj0FEPTIsYYqYRh5JgkHGhe9AW JxDWEoXaRGTD8SjONjuyRmKf7IHxgefsTUCI7oTHVJ9+mqGnIXY9xAfN86au4jUuD0yv nlVQ== X-Gm-Message-State: AOAM533qSuWTaPmtn8fKbBOIhp8k6So6lbj01tBN999nYwa52UhhykzQ MKrbnlQhgGnZ8dghkDGOxgY= X-Google-Smtp-Source: ABdhPJwHRV9IVngDb8Or+gaomMiu8lsMa9kNgVNzqo6DDq2FQqkpa/WosWGUb0VO6LLFGxHDylQVYQ== X-Received: by 2002:ac8:5b0f:0:b0:2e0:5a1f:9910 with SMTP id m15-20020ac85b0f000000b002e05a1f9910mr8892131qtw.356.1646666020161; Mon, 07 Mar 2022 07:13:40 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id w9-20020a05620a148900b005f188f755adsm6304214qkj.32.2022.03.07.07.13.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Mar 2022 07:13:39 -0800 (PST) Date: Mon, 7 Mar 2022 10:13:37 -0500 From: Mark Johnston To: Ronald Klop Cc: bob prohaska , Mark Millard , freebsd-arm@freebsd.org, freebsd-current Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) Message-ID: References: <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay> 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: <132978150.92.1646660769467@mailrelay> X-Rspamd-Queue-Id: 4KC26F0Lm9z3ltp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=BpTPXuU3; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::835 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::835:from]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[www.zefox.net,yahoo.com,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Mar 07, 2022 at 02:46:09PM +0100, Ronald Klop wrote: > Dear Mark Johnston, > > I did some binary search in the kernels and came to the conclusion that https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e still works and https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a panics. > > I suspect your commit in https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a. > > Last panic: > > panic: vm_fault failed: ffff00000046e708 error 1 > cpuid = 1 > time = 1646660058 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x174 > panic() at panic+0x44 > data_abort() at data_abort+0x2e8 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x96000004 > _rm_rlock_debug() at _rm_rlock_debug+0x8c > osd_get() at osd_get+0x5c > zio_execute() at zio_execute+0xf8 > taskqueue_run_locked() at taskqueue_run_locked+0x178 > taskqueue_thread_loop() at taskqueue_thread_loop+0xc8 > fork_exit() at fork_exit+0x74 > fork_trampoline() at fork_trampoline+0x14 > KDB: enter: panic > [ thread pid 0 tid 100129 ] > Stopped at kdb_enter+0x44: undefined f902011f > db> > > A more recent kernel (912df91) still panics. See below. > > Do you have time to look into this? What can I provide in information to help? Hmm. So after my rmlock commits, we have the following disassembly for _rm_rlock() (with a few annotations added by me). Note that the pcpu pointer is stored in register x18 by convention. 0xffff00000046e304 <+0>: stp x29, x30, [sp, #-16]! 0xffff00000046e308 <+4>: mov x29, sp 0xffff00000046e30c <+8>: ldr x8, [x18] 0xffff00000046e310 <+12>: ldr x9, [x18] 0xffff00000046e314 <+16>: ldr x10, [x18] 0xffff00000046e318 <+20>: cmp x9, x10 0xffff00000046e31c <+24>: b.ne 0xffff00000046e3cc <_rm_rlock+200> // b.any 0xffff00000046e320 <+28>: ldr x9, [x18] 0xffff00000046e324 <+32>: ldrh w9, [x9, #314] 0xffff00000046e328 <+36>: cbnz w9, 0xffff00000046e3c0 <_rm_rlock+188> 0xffff00000046e32c <+40>: str wzr, [x1, #32] 0xffff00000046e330 <+44>: stp x0, x8, [x1, #16] 0xffff00000046e334 <+48>: ldrb w9, [x0, #10] 0xffff00000046e338 <+52>: tbz w9, #4, 0xffff00000046e358 <_rm_rlock+84> 0xffff00000046e33c <+56>: ldr x9, [x18] 0xffff00000046e340 <+60>: ldr w10, [x9, #888] 0xffff00000046e344 <+64>: add w10, w10, #0x1 0xffff00000046e348 <+68>: str w10, [x9, #888] 0xffff00000046e34c <+72>: ldr x9, [x18] 0xffff00000046e350 <+76>: ldr w9, [x9, #888] 0xffff00000046e354 <+80>: cbz w9, 0xffff00000046e3f4 <_rm_rlock+240> 0xffff00000046e358 <+84>: ldr w9, [x8, #1212] 0xffff00000046e35c <+88>: add x10, x18, #0x90 0xffff00000046e360 <+92>: add w9, w9, #0x1 0xffff00000046e364 <+96>: str w9, [x8, #1212] <------- critical_enter 0xffff00000046e368 <+100>: str x10, [x1, #8] 0xffff00000046e36c <+104>: ldr x9, [x18, #144] 0xffff00000046e370 <+108>: str x9, [x1] 0xffff00000046e374 <+112>: str x1, [x9, #8] 0xffff00000046e378 <+116>: str x1, [x18, #144] 0xffff00000046e37c <+120>: ldr x9, [x18] 0xffff00000046e380 <+124>: ldr w10, [x9, #356] 0xffff00000046e384 <+128>: add w10, w10, #0x1 0xffff00000046e388 <+132>: str w10, [x9, #356] 0xffff00000046e38c <+136>: ldr w9, [x8, #1212] 0xffff00000046e390 <+140>: sub w9, w9, #0x1 0xffff00000046e394 <+144>: str w9, [x8, #1212] <------- critical_exit 0xffff00000046e398 <+148>: ldrb w8, [x8, #304] 0xffff00000046e39c <+152>: ldr w9, [x18, #60] <------- loading &pc->pc_cpuid ... A (the?) problem is that the compiler is treating "pc" as an alias for x18, but the rmlock code assumes that the pcpu pointer is loaded once, as it dereferences "pc" outside of the critical section. On arm64, if a context switch occurs between the store at _rm_rlock+144 and the load at +152, and the thread is migrated to another CPU, then we'll end up using the wrong CPU ID in the rm->rm_writecpus test. I suspect the problem is unique to arm64 as its get_pcpu() implementation is different from the others in that it doesn't use volatile-qualified inline assembly. This has been the case since https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762 . I haven't been able to reproduce any crashes running poudriere in an arm64 AWS instance, though. Could you please try the patch below and confirm whether it fixes your panics? I verified that the apparent problem described above is gone with the patch. diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c index 0cdcfb8fec62..e51c25136ae0 100644 --- a/sys/kern/kern_rmlock.c +++ b/sys/kern/kern_rmlock.c @@ -437,6 +437,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) { struct thread *td = curthread; struct pcpu *pc; + int cpuid; if (SCHEDULER_STOPPED()) return (1); @@ -452,6 +453,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) atomic_interrupt_fence(); pc = get_pcpu(); + cpuid = pc->pc_cpuid; rm_tracker_add(pc, tracker); sched_pin(); @@ -463,7 +465,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) * conditional jump. */ if (__predict_true(0 == (td->td_owepreempt | - CPU_ISSET(pc->pc_cpuid, &rm->rm_writecpus)))) + CPU_ISSET(cpuid, &rm->rm_writecpus)))) return (1); /* We do not have a read token and need to acquire one. */ From nobody Mon Mar 7 16:25:22 2022 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 D993819FF2FB; Mon, 7 Mar 2022 16:26:06 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4KC3jk4kpCz4Zg5; Mon, 7 Mar 2022 16:26:01 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtpclient.apple (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id E00234E691; Mon, 7 Mar 2022 16:25:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1646670325; bh=7XrO+HaAx4iY3x3pFrVg45yl1uV5r+TSyOoKSvgfHkk=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=RFijEnsVrMOCC4A0q561JG7eVkbahX00Nqx9p1mxa9VBezirmPks/x3mpCbmygZH0 eB59BuSrztQHKsdU6oqMqmy4v3PzOMaoGDAV9IWfa5tVx0gZXdKl0Tgd6IgSPKGqsf AFNOpRvecWe8+7LC7K4M2llmCqxw9OJsGO5yk6XIT4TP0rjhNytpbTHU8jddLQOCWF 8i8PrFIfIeyJVg805dB5x5jjavd2geqJSCQW7ILbAQzB1C2woJ4BEOISGyN5KwlTxf ALvOlw1CjF/WER8xwPs8hD2Ug4iCx/PmBvdOfWm8DRERtAj2/EphDWKz3whGjoH3vr L9lpsWNC3sH+ayr1Y0Db95EhZTaDKUaQecGBLE8JqS0Y7/9jAnEgwfmMs5sdoWxe1t fpCeSUyxKUOzp/yQYLlbXKBft02yBX6bOiPGt+BAQ3fvWUE4qZiitR1YFOuyDToq1b qh3ZS0VsKtAuvgM97RqVusGT4w6Kaxl4xoyT1gcH8AAIItVO+COVEG+c5PoV/uoNux EAXypYPS4Fy8ltgItPfmKoN7qSxUyL5OkAyse61e3MbfxZf3LcZ+ju1Fh+7f9B2sRM NGQhbDHDaLsfdT3FVu2zu/Imr7pUXXpFBFCwxvmCNOZtpvTehUAyLDIpKGMe4/MtKy u7AE3Q2svHWOHNodoDZAgckU= From: Andrew Turner Message-Id: <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz> Content-Type: multipart/alternative; boundary="Apple-Mail=_26F7CFA2-6340-472E-A50C-7E288B1E046B" 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 15.0 \(3693.60.0.1.1\)) Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) Date: Mon, 7 Mar 2022 16:25:22 +0000 In-Reply-To: Cc: Ronald Klop , bob prohaska , Mark Millard , freebsd-arm@freebsd.org, freebsd-current To: Mark Johnston References: <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay> X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Rspamd-Queue-Id: 4KC3jk4kpCz4Zg5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fubar.geek.nz header.s=mail header.b=RFijEnsV; dmarc=pass (policy=none) header.from=fubar.geek.nz; spf=pass (mx1.freebsd.org: domain of andrew@fubar.geek.nz designates 139.59.165.16 as permitted sender) smtp.mailfrom=andrew@fubar.geek.nz X-Spamd-Result: default: False [-3.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=mail]; FREEFALL_USER(0.00)[andrew]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[fubar.geek.nz:+]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US]; FREEMAIL_CC(0.00)[klop.ws,www.zefox.net,yahoo.com,freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_26F7CFA2-6340-472E-A50C-7E288B1E046B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 7 Mar 2022, at 15:13, Mark Johnston wrote: > ... > A (the?) problem is that the compiler is treating "pc" as an alias > for x18, but the rmlock code assumes that the pcpu pointer is loaded > once, as it dereferences "pc" outside of the critical section. On > arm64, if a context switch occurs between the store at _rm_rlock+144 = and > the load at +152, and the thread is migrated to another CPU, then = we'll > end up using the wrong CPU ID in the rm->rm_writecpus test. >=20 > I suspect the problem is unique to arm64 as its get_pcpu() > implementation is different from the others in that it doesn't use > volatile-qualified inline assembly. This has been the case since > = https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbddf85ad04fc8e= 99e73762 = > . >=20 > I haven't been able to reproduce any crashes running poudriere in an > arm64 AWS instance, though. Could you please try the patch below and > confirm whether it fixes your panics? I verified that the apparent > problem described above is gone with the patch. Alternatively (or additionally) we could do something like the = following. There are only a few MI users of get_pcpu with the main place = being in rm locks. diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h index 09f6361c651c..59b890e5c2ea 100644 --- a/sys/arm64/include/pcpu.h +++ b/sys/arm64/include/pcpu.h @@ -58,7 +58,14 @@ struct pcpu; register struct pcpu *pcpup __asm ("x18"); -#define get_pcpu() pcpup +static inline struct pcpu * +get_pcpu(void) +{ + struct pcpu *pcpu; + + __asm __volatile("mov %0, x18" : "=3D&r"(pcpu)); + return (pcpu); +} static inline struct thread * get_curthread(void) Andrew --Apple-Mail=_26F7CFA2-6340-472E-A50C-7E288B1E046B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = 7 Mar 2022, at 15:13, Mark Johnston <markj@freebsd.org> = wrote:
...
A (the?) problem is that the compiler is treating "pc" as an = alias
for x18, but = the rmlock code assumes that the pcpu pointer is loaded
once, as it dereferences "pc" = outside of the critical section.  On
arm64, if a context switch occurs between the store at = _rm_rlock+144 and
the load at +152, and the thread is migrated to another CPU, = then we'll
end up using = the wrong CPU ID in the rm->rm_writecpus test.

I suspect the problem is unique = to arm64 as its get_pcpu()
implementation is different from the others in that it = doesn't use
volatile-qualified inline assembly.  This has been the = case since
https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbdd= f85ad04fc8e99e73762
.

I haven't = been able to reproduce any crashes running poudriere in an
arm64 AWS instance, though. =  Could you please try the patch below and
confirm whether it fixes your = panics?  I verified that the apparent
problem described above is gone with the patch.

Alternatively= (or additionally) we could do something like the following. There are = only a few MI users of get_pcpu with the main place being in rm = locks.

diff --git = a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
index = 09f6361c651c..59b890e5c2ea 100644
--- = a/sys/arm64/include/pcpu.h
+++ = b/sys/arm64/include/pcpu.h
@@ -58,7 +58,14 @@ struct = pcpu;

 register struct pcpu = *pcpup __asm ("x18");

-#define =        get_pcpu()     =  pcpup
+static inline struct pcpu = *
+get_pcpu(void)
+{
+     =   struct pcpu *pcpu;
+
+       = __asm __volatile("mov   %0, x18" : "=3D&r"(pcpu));
+ =       return (pcpu);
+}

 static inline struct thread = *
 get_curthread(void)

Andrew

= --Apple-Mail=_26F7CFA2-6340-472E-A50C-7E288B1E046B-- From nobody Mon Mar 7 16:45:02 2022 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 8A3E31A051E3; Mon, 7 Mar 2022 16:45:18 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KC47x4SgQz4j3s; Mon, 7 Mar 2022 16:45:17 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x832.google.com with SMTP id 11so13716589qtt.9; Mon, 07 Mar 2022 08:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5UYaPmaTEqBJoZRQrb8hIFwZZsI3StJpQcF7a5ffnfk=; b=IUstT1RgGaFjTpv9oNTVMo1dYUCStoh3nxph2gw4dwsis6vbIOGlGWPlVWAstKDebr acR6FfELyFpfuz6HielHo7OC62fd8tdEimZ85ZSVRmrcKm2w2NlRvhFUlLZJzPhgx3UD BJW2XvkIOysMA72JUnidH8VmMBwZONz0K13vC2W3TOpffCfekoK9d7WewwfJa1TLproh jZr1r/fxA8buyNSNFATRH/9CdYjZ/5bUZ12wYeNjwS7gE2qlR375pgQGV3JZx5RNp+4x 1KBf4d7BlC9e2eYSaSFiMCPkuoG9jiR3sw0KBlssdXvgk2X4B94RNLFDDGhX/3Na9thJ n4pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=5UYaPmaTEqBJoZRQrb8hIFwZZsI3StJpQcF7a5ffnfk=; b=xsKBbnhS7/xUTi4pItNkI5W4Gtug28BlrRC9LuOsx3YMeDkwIfWkG6OaTgzLlySNpE FDApXEz8M/JjaPdAdi/KQ9PCEqDcymTm+z1KiIbIDUhdAsMBopSZuI8kdhXeffy28D25 zA1zXCHGML4x3kdJpzl/6qkE5PtjsbnGQ0a495QH9+fbbHTPeQViz6AXw9KIQFbygGJg xj0bHq2IypDQQNzWwRkfVpgf9SLMWFmDgTfhLeawlUKkFetfLZ5x1iLS/Jrcq98qYi/3 wYf4WCJ6jtLmTK/V0muHrwqNfnA3wcHBSDXbpaBKqR7NH3K4vS3tE8vD2XfYLHUXfTsv ZN9g== X-Gm-Message-State: AOAM530uvVmimp3lSx1/E3lblh6r1PjRY9bWhkcLoxBGgXl7hjdkzEgl y/g4L0+Ek+eCdBV12FJ3jdY= X-Google-Smtp-Source: ABdhPJzlc0Zggspr8Cto8dM8HsXuYqdkHYszZmwu09XKCJ89gVohiVxquCEfHtkVH4aSHYXG1GX8xQ== X-Received: by 2002:ac8:5c4e:0:b0:2de:7191:7480 with SMTP id j14-20020ac85c4e000000b002de71917480mr10169763qtj.489.1646671511395; Mon, 07 Mar 2022 08:45:11 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id 15-20020ac8570f000000b002e05a1f990dsm4841181qtw.65.2022.03.07.08.45.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Mar 2022 08:45:10 -0800 (PST) Date: Mon, 7 Mar 2022 11:45:02 -0500 From: Mark Johnston To: Andrew Turner Cc: Ronald Klop , bob prohaska , Mark Millard , freebsd-arm@freebsd.org, freebsd-current Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) Message-ID: References: <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay> <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz> 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: <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz> X-Rspamd-Queue-Id: 4KC47x4SgQz4j3s X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=IUstT1Rg; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::832 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::832:from]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[klop.ws,www.zefox.net,yahoo.com,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote: > > > On 7 Mar 2022, at 15:13, Mark Johnston wrote: > > ... > > A (the?) problem is that the compiler is treating "pc" as an alias > > for x18, but the rmlock code assumes that the pcpu pointer is loaded > > once, as it dereferences "pc" outside of the critical section. On > > arm64, if a context switch occurs between the store at _rm_rlock+144 and > > the load at +152, and the thread is migrated to another CPU, then we'll > > end up using the wrong CPU ID in the rm->rm_writecpus test. > > > > I suspect the problem is unique to arm64 as its get_pcpu() > > implementation is different from the others in that it doesn't use > > volatile-qualified inline assembly. This has been the case since > > https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762 > > . > > > > I haven't been able to reproduce any crashes running poudriere in an > > arm64 AWS instance, though. Could you please try the patch below and > > confirm whether it fixes your panics? I verified that the apparent > > problem described above is gone with the patch. > > Alternatively (or additionally) we could do something like the following. There are only a few MI users of get_pcpu with the main place being in rm locks. > > diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h > index 09f6361c651c..59b890e5c2ea 100644 > --- a/sys/arm64/include/pcpu.h > +++ b/sys/arm64/include/pcpu.h > @@ -58,7 +58,14 @@ struct pcpu; > > register struct pcpu *pcpup __asm ("x18"); > > -#define get_pcpu() pcpup > +static inline struct pcpu * > +get_pcpu(void) > +{ > + struct pcpu *pcpu; > + > + __asm __volatile("mov %0, x18" : "=&r"(pcpu)); > + return (pcpu); > +} > > static inline struct thread * > get_curthread(void) Indeed, I think this is probably the best solution. From nobody Mon Mar 7 18:03:51 2022 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 3A2C719F5359 for ; Mon, 7 Mar 2022 18:04:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KC5ts0mCZz3CdG for ; Mon, 7 Mar 2022 18:04:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646676237; bh=QNJmAQMRxgmElsmewRjV6HwzLY6BrLjlqtFuBV2iLXY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=G18lIaRC0WkvovsONRYxNO6qaxtOIkNxt6nVsb3zuk29jBwj44ukb8P8DTh3q+Cyj2I2czWjkTRhHi3NUOoQv6ihtfBcNa6GSfewkdDZpw8lwnxcUnHTczfQxsjrpqv4S+Uy9eoXCchFDSODkzyBRjhBCY4wXQjQvc6p8sLpTqmp4KqkM007Hgxn8JUhPiQqyfnrflqjSLgrN2jOBKwDrPmGpmS8117riUicAv7n7E8cL60Ujqz3wlz5R2wWcHlm3PTCqi/abXGrGDxnTO/CrzYqlOcC32SRZPvMNWNv7khc9LQqMYwqDCxXllIBjaM96dVBNvW2HsSIztxLycjyww== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646676237; bh=D3B0Zj4SUlq3Qcq4JJd0joW0jjk5s2cohbbX9zsEFNu=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=FxoXkzSrJIgquaSw/URh2GneEDRbsyHYd4+6hQ4lQoqeX47OVk6WzRJUk/RciQd98bm+s3D+yj0wV68Gp5ccEFWRPUF07hfHyN+3UyT1xsqvzK+x4kkKNoqTFvhPArsBHIGE3gtLY3U9TLZAoFahWWHoxS0b8Icgl2GdRz6Wn5AQpiixDKPt1ciu3UjS+joLkFh58mbfqVK3kGU2yPjVvqD57y/2JXFLLcaDKHalTeAknwUZ06eut2bEztaiVPNZUw5j5MUKOuKCBbPVoxlhHTYw1bBZD0rOn8PsiaDPSxrbRQPBKFsgYoth2RyoPYcFGgqMhjhQl5Uf5UTQOqHrTw== X-YMail-OSG: f0XSjhAVM1ntBc.DAjrpYvHF8g7bQAQyqUXDaPNvHjX0cpGrck4Ss1wEdNEWdWg E76LC0CMwrzz7xQ8zgGMm6ozXOxHvaSq25HI4arbyvFJr6qeG.UMnQznP1iqu2q_W6XWyYlET7Tx cXRPF_1sZXr1GvI9xS6QMngRuaYuSemRHNd_BSSmy98sRvYskmX08cPq6tgz.WsIskxUT7LJa_XE jyfn0MjIc4sLi7S..DdbUUFrFQGE48pLEuRCnKQcoPNnP2SmPru.L14W1dG1ENq.o1FDUbe3gKro Bh4gAxVd23EqncWBulqaPa6A6GVia_4__LrHH1WMzo0vNcA1uZlH7gB59al73nng3kQgxF2jRgMl UT6zblYD3NcYp6xh.zw3b.hBM3h0CCeufoBI1X83IBCZy1SUMrtUIE7pj5VLvtfyEsBtP18X0_sZ 1LNhNFaA8CJIidEleS0a98xEqZvNwiw_KJAe_vV2dRuB4JrzHyOUMQUN0FICV97hRKEozaX6Ea7W h79A5E0xBUVEaZlIkcAdjyUsyBQDmjg.PoQKm3sN78lhP25C3lgiv.wBxY.YzWdSM7DGS1Xc2wQD Qew8vVGgzTHVz8JgdNidrwiQEbo6IiJI1P85bO0NTA2Fo01y0dS7G_3AEN6iFQPFAwsKCWykIpIy CfFUOEWpdMqch_ARfcW5X_ffTL2g4iD_ZCbIjyDS2j7iFRfPx_2QC_7Cabr6btd_UkVVkX3f5Cpl 5XiViVBlrkbPZ4_.UoPL72XbZjJqyVUub3jeVLUsF5X53._jVIbKjE1G5bbqRKK1KQJIvoYZ8U2a kFZe6tyPgSWmhcVBs6ru4CphT1tjmiRgZYNfyPZYUBXwk7F0AOKfxXmL4KZX.PfxOoUqzCZW4uIw IM41JrnIB1PTiWVT6WS1.0php59gJlHGz.z0KN2qfgDA8iIOxfBuo.i_NH6nikr4SLMdbvCtv7KJ 1VGWiXBhsUTzJeSNQL1rCcI9h2qleVaibpp4Pc9HnyS6y_dNLbNpNv_Gsv8vYkL4g49bhxHj2X5b EcNiN6rCZHdGQAvLqf4A6SSMiFlnSO.dLFT8QvQ5pOY10NsKSAZFXUnrAACaRDrZQ8PzYNPXdlBq nzWErbuXt7n9xdmy6FPVEOr1Dnhl8Cdl7vbpjbR.bZn5W_cUcmU9z4UeGPUoJRRHBTxBcti8wUVp 3rj_dVQCURlLkRNv57IgfmA4ZeHEl3BbCYnyNFrXbsFHnoYY0BgHINjV_zWNNROObQyKEryfcHdk MS2Uy.jnpvnNK2mbwtNTBflsUM0p9BzI.VBYcTih9kxJSuOa.Exj08MIxObJsushj5.uy0MGPpBv cSGpYcd4D9jiumShDWCUMDGg5hSG.ioCZU7h3rc.OqClOo6r2xM5NQx7QI9_hg13yrtAKsv0Kl7j GPtxgeNrIJ8kskLEpkq8NH_907QK_Bc9YRSPNwJ5jSV2XCLYtvqoQ_WawILeCvVMyW41eEWU90YI qSJptWb5JwdnD6CeYl5SX0n10D6Wx0xo12zcelN96ZFD.a3M7ql_QlvCkhI2purGUBFnAZZvc1BO hZUI3y0KSTmLGYPqoseQRSqOHW1KHs4TaXQgyThdk8dweQSDVtWttm9S8KMqDTmfyJN15rhQRvtl sNhWNZZuD13KF0NyQrVRE..n8J_36OiF2twwpaW0NjaD2VDDYzx4fqXrTimXTC9A7LayW0VYLo8m NvvBmNvZomV0RuYhTNmUv6ngbhPxUp1F5LejWh2DDsJ0i6g7DJe_IimoDsL2RUBS_vRV5bOgNAGK .H4dLb3n9PCeb1ml7ZjaKWFLCkBd0C3ysbsug5HiRk9KQXJJKA5deg4qdF8.J7NyM9ReEzJrq6UU iWsZGniT7mjgreGLmM6mi.lbnvKeJrgHzIVVCC7z_dMLiAUxfkRNTWh6uo1GFmPH8Q0okKnjYPeQ OsDImabpVwq790f23IMRreoZ07.QuyTVDs7E5vPjCoFoa3R9xmAzfTB5CY1HTQkEStvj3n8rpBAX GAQhrkhlkeRFevnJB0_wH5Ut50rHhGQjTPhBgmcpRnm6d8bN_rI.PdNXnpul8Ekf7jGgHanvtKW4 mP5SC_d1jwQNGTy4goiMri4yYuTn.tWPVNcMeUq5sMjPc2y4O3qFL0k4zZMF4Ciaa084PK_rXJNe Pvq0TZJF80EkL3W7_5LDtC1F54cnz9.Lf71nBo1Cpu.Fd9MkgNVwzGFmGkzP8Xd2er.14dpePSRD oBbpplsw2o1_dwhAdgg7yOL3z29Y5NJmctztjJfYZv_t2jc_pjKF7LRnNMQpvribcQRd5f9bjnLm Vc1gLEf8cIIaeEhHfgSPN0huC7JX6iDxGViwHQAAUVUDtg6agrZAmPf4gSn910Jz964vUE9NOAuS jwgAOSQ_EMRGaEBg- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Mar 2022 18:03:57 +0000 Received: by kubenode518.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID beef9abb4f3e81af87e938ac5564e7ad; Mon, 07 Mar 2022 18:03:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) From: Mark Millard In-Reply-To: Date: Mon, 7 Mar 2022 10:03:51 -0800 Cc: Andrew Turner , Ronald Klop , bob prohaska , Free BSD , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay> <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz> To: Mark Johnston , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KC5ts0mCZz3CdG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=G18lIaRC; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Mar-7, at 08:45, Mark Johnston wrote: > On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote: >>=20 >>> On 7 Mar 2022, at 15:13, Mark Johnston wrote: >>> ... >>> A (the?) problem is that the compiler is treating "pc" as an alias >>> for x18, but the rmlock code assumes that the pcpu pointer is loaded >>> once, as it dereferences "pc" outside of the critical section. On >>> arm64, if a context switch occurs between the store at _rm_rlock+144 = and >>> the load at +152, and the thread is migrated to another CPU, then = we'll >>> end up using the wrong CPU ID in the rm->rm_writecpus test. >>>=20 >>> I suspect the problem is unique to arm64 as its get_pcpu() >>> implementation is different from the others in that it doesn't use >>> volatile-qualified inline assembly. This has been the case since >>> = https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbddf85ad04fc8e= 99e73762 = >>> . >>>=20 >>> I haven't been able to reproduce any crashes running poudriere in an >>> arm64 AWS instance, though. Could you please try the patch below = and >>> confirm whether it fixes your panics? I verified that the apparent >>> problem described above is gone with the patch. >>=20 >> Alternatively (or additionally) we could do something like the = following. There are only a few MI users of get_pcpu with the main place = being in rm locks. >>=20 >> diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h >> index 09f6361c651c..59b890e5c2ea 100644 >> --- a/sys/arm64/include/pcpu.h >> +++ b/sys/arm64/include/pcpu.h >> @@ -58,7 +58,14 @@ struct pcpu; >>=20 >> register struct pcpu *pcpup __asm ("x18"); >>=20 >> -#define get_pcpu() pcpup >> +static inline struct pcpu * >> +get_pcpu(void) >> +{ >> + struct pcpu *pcpu; >> + >> + __asm __volatile("mov %0, x18" : "=3D&r"(pcpu)); >> + return (pcpu); >> +} >>=20 >> static inline struct thread * >> get_curthread(void) >=20 > Indeed, I think this is probably the best solution. Is this just partially reverting: https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56 If so, there might need to be comments about why the updated code is as it will be. Looks like stable/13 picked up sensitivity to the get_pcpu details in rmlock in: https://cgit.freebsd.org/src/commit/?h=3Dstable/13&id=3D543157870da5 (a 2022-03-04 commit) and stable/13 also has the get_pcpu misdefinition in: = https://cgit.freebsd.org/src/commit/sys/arm64/include/pcpu.h?h=3Dstable/13= &id=3D63c858a04d56 . So an MFC would be appropriate in order for aarch64 to be reliable for any variations in get_pcpu in stable/13 (and for 13.1 to be so as well). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Mar 7 19:04:09 2022 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 2DAAB1A1F105; Mon, 7 Mar 2022 19:04:14 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KC7DF0d3Bz4jrG; Mon, 7 Mar 2022 19:04:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf2a.google.com with SMTP id e22so12812278qvf.9; Mon, 07 Mar 2022 11:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=esZKyfTOPNgtjph7i3nXEvXHagQgF99ajXO9YY9+DcA=; b=HPCKDDbtO/a2bGU0A4jEhKuQUdPD9kptMpjYNICoshgaRLrvEEABe7WblRyU7V0wmv hYVTK4OlSAXKwbSmV6kHrz5PO4RWqM65DzeU5EJtIEUderTZ+tPfk3XrKzUQdoFJlBzz JKnunZK9u+qLpRXsn0uHEhL2B6Vp9V0wZr6ldN+ZBGaRwkqdOBOlD9Sfjp6TeRLbLBif YFS/9KvEcdJZOlzkzEUTbJcsFX6LOz98lakup6sBdviMky0n3KtWlLXyGFD2S7ZguI/G gxLB41m32vtxK0H8hr6DqaEkMx5/AhoG5VRgnEJOtheK4rxJZvpzEGz4rTQ3plmxxCWR VInw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=esZKyfTOPNgtjph7i3nXEvXHagQgF99ajXO9YY9+DcA=; b=Bhsl154d+G8oc+vqwhJauFTkBLHjLoAc/8bnpBB7y7jSIX+hxrrio6h3gwwMQULBzn o3TxD5X412AO0Qz2d7/8q4Y/U1yNfF0RHW+LW8EMKm15IsVDELPsLevTI7puitDSim9w VTS9x4zJuCOCDMwNbsXhTpP4wqSTK5wgvPEDbEWPcfSLgTRbcYAyP59j4zpVUTv9cNBH Brsm777aqvmpd8EJlKnwWvMW1CjcrbkHYQmEqXEieP1ktytZ+v2WNWrxZzmgPKexR1cV qasFVXFar9FYbdrJNcxCX59/KdHfXyYRTE76UKG3rOzh1f8uIq8BHtOU97PE0vVnh3VH /qcg== X-Gm-Message-State: AOAM532ZoCOu8lbbeL9jU9ah+CNa5xmttMFkK+C+vxjbKEIDtrgUCy44 a4W1qyEo36Me1xBGEeEAAVo= X-Google-Smtp-Source: ABdhPJy7JZKbZ0toPNLBBJU8r3OvQzaua82asbIDbzSEYtvHi8xspeNNTsqmyhjQSHaQhPS73TgJdA== X-Received: by 2002:a05:6214:d06:b0:435:6794:f929 with SMTP id 6-20020a0562140d0600b004356794f929mr9402128qvh.101.1646679852446; Mon, 07 Mar 2022 11:04:12 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id x26-20020ae9f81a000000b005f1916fc61fsm6400480qkh.106.2022.03.07.11.04.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Mar 2022 11:04:11 -0800 (PST) Date: Mon, 7 Mar 2022 14:04:09 -0500 From: Mark Johnston To: Mark Millard Cc: FreeBSD-STABLE Mailing List , Andrew Turner , Ronald Klop , bob prohaska , Free BSD , freebsd-current Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) Message-ID: References: <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay> <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KC7DF0d3Bz4jrG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=HPCKDDbt; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f2a as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.68 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_SEVEN(0.00)[7]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.983]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2a:from]; MLMMJ_DEST(0.00)[freebsd-stable,freebsd-arm,freebsd-current]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Mar 07, 2022 at 10:03:51AM -0800, Mark Millard wrote: > > > On 2022-Mar-7, at 08:45, Mark Johnston wrote: > > > On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote: > >> > >>> On 7 Mar 2022, at 15:13, Mark Johnston wrote: > >>> ... > >>> A (the?) problem is that the compiler is treating "pc" as an alias > >>> for x18, but the rmlock code assumes that the pcpu pointer is loaded > >>> once, as it dereferences "pc" outside of the critical section. On > >>> arm64, if a context switch occurs between the store at _rm_rlock+144 and > >>> the load at +152, and the thread is migrated to another CPU, then we'll > >>> end up using the wrong CPU ID in the rm->rm_writecpus test. > >>> > >>> I suspect the problem is unique to arm64 as its get_pcpu() > >>> implementation is different from the others in that it doesn't use > >>> volatile-qualified inline assembly. This has been the case since > >>> https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762 > >>> . > >>> > >>> I haven't been able to reproduce any crashes running poudriere in an > >>> arm64 AWS instance, though. Could you please try the patch below and > >>> confirm whether it fixes your panics? I verified that the apparent > >>> problem described above is gone with the patch. > >> > >> Alternatively (or additionally) we could do something like the following. There are only a few MI users of get_pcpu with the main place being in rm locks. > >> > >> diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h > >> index 09f6361c651c..59b890e5c2ea 100644 > >> --- a/sys/arm64/include/pcpu.h > >> +++ b/sys/arm64/include/pcpu.h > >> @@ -58,7 +58,14 @@ struct pcpu; > >> > >> register struct pcpu *pcpup __asm ("x18"); > >> > >> -#define get_pcpu() pcpup > >> +static inline struct pcpu * > >> +get_pcpu(void) > >> +{ > >> + struct pcpu *pcpu; > >> + > >> + __asm __volatile("mov %0, x18" : "=&r"(pcpu)); > >> + return (pcpu); > >> +} > >> > >> static inline struct thread * > >> get_curthread(void) > > > > Indeed, I think this is probably the best solution. Thinking a bit more, even with that patch, code like this may not behave the same on arm64 as on other platforms: critical_enter(); ptr = &PCPU_GET(foo); critical_exit(); bar = *ptr; since as far as I can see the compiler may translate it to critical_enter(); critical_exit(); bar = PCPU_GET(foo); > Is this just partially reverting: > > https://cgit.freebsd.org/src/commit/?id=63c858a04d56 > > If so, there might need to be comments about why the updated > code is as it will be. > > Looks like stable/13 picked up sensitivity to the get_pcpu > details in rmlock in: > > https://cgit.freebsd.org/src/commit/?h=stable/13&id=543157870da5 > > (a 2022-03-04 commit) and stable/13 also has the get_pcpu > misdefinition in: > > https://cgit.freebsd.org/src/commit/sys/arm64/include/pcpu.h?h=stable/13&id=63c858a04d56 > > . So an MFC would be appropriate in order for aarch64 > to be reliable for any variations in get_pcpu in stable/13 > (and for 13.1 to be so as well). I reverted the rmlock commit in stable/13 already. Either get_pcpu() will be fixed shortly or 13.1 will ship without the rmlock commit. From nobody Mon Mar 7 20:40:21 2022 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 E6A901A07A7C for ; Mon, 7 Mar 2022 20:40:26 +0000 (UTC) (envelope-from joh.hendriks@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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KC9MG0L7Zz3pX8 for ; Mon, 7 Mar 2022 20:40:26 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-ed1-x536.google.com with SMTP id s10so431794edd.0 for ; Mon, 07 Mar 2022 12:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language :from:to:references:in-reply-to:content-transfer-encoding; bh=7tjtvBuK6YYG4kOxX13KGCajhIbOj45i+RaTLFdKVAo=; b=Lvs4Z2gSlB+P++bt+R5FKV1HOHWzZmyqSYl7Bk6JFXxcz8WsHC8D/b5D/49n8INmS+ rq3JvnVYlxoQWoJZn6G96n71cVSCrPrbg2rscpoI5DzJpPvRtCqORn4f/54CHpRXXLPZ Og3hUpsxBv6palxOBHA6QyOOJSRo7Hdszf4VlozmA2V7/bgAZyXlp0MYhYPjIz41PZOD 8DF0TA4+BoBsdoIdfFPY/79WLbe2WHoEYJw4nQyvelsyZqw0W/bKOnWLcAcdVd/xJ4+n Yp7qNDieXZlvK9d40vWtwEZFkQaDTgu92eKZcZ6i5UtUMjZYf58wAP3K9XxxDTZkeOCB mYqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:references:in-reply-to :content-transfer-encoding; bh=7tjtvBuK6YYG4kOxX13KGCajhIbOj45i+RaTLFdKVAo=; b=GbpXmHsr0cLHT73nU4kL+D76aag9uefqqLtg1osMsNUq2YV596Pvaqcc5NyJHoSePu /XWqFZGFXlY4InTD7H7V6ExDqf3o8X3K7rhwxmbr5L+sp6wy06jZncdp7r6FruT9OCYd wljdj6gM61nl6C3dJyUAJIg6JHUwZ126bFpqpkln0wBWKlQjgjTezoEFWfypx0Ojag37 FjLyd1OipMqH+zI6XfeypLYDJ+i0rORiumRp+J0pjL15FS/qChSsK3Q+qBoBVHdkNUb5 J9tJ5c+apuFQdp2iUeWW1xfX3JBPJBOnmP6GwQp7IvCX/rdvgh4SuKhi+IrBFY8k4vEl tpjQ== X-Gm-Message-State: AOAM530a5X0c9Bm3X3s099Veb8l66bFZDnCXaoCTPBi5KaYOZ3Eldf53 mL7aZ+6gY0vmi48Ac7n6f5f0jKUd+r4= X-Google-Smtp-Source: ABdhPJxXTDFvlzIiauJ11WAmFYs8yjG95bgoLSJUDppK+6BWaslS/bdyMIJ3ogEO+KTB2KfDzmdjbA== X-Received: by 2002:a05:6402:1e8f:b0:3fa:72cb:1733 with SMTP id f15-20020a0564021e8f00b003fa72cb1733mr13120456edf.24.1646685624689; Mon, 07 Mar 2022 12:40:24 -0800 (PST) Received: from [192.168.1.18] (85-147-130-226.cable.dynamic.v4.ziggo.nl. [85.147.130.226]) by smtp.gmail.com with ESMTPSA id k23-20020a1709062a5700b006ccd8fdc300sm5039908eje.180.2022.03.07.12.40.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Mar 2022 12:40:24 -0800 (PST) Message-ID: Date: Mon, 7 Mar 2022 21:40:21 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: vnet jails loose network connectivity Content-Language: en-US From: Johan Hendriks To: FreeBSD Current References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KC9MG0L7Zz3pX8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Lvs4Z2gS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of johhendriks@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=johhendriks@gmail.com X-Spamd-Result: default: False [-3.87 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.91)[-0.905]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.962]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 04/03/2022 15:36, Johan Hendriks wrote: > Hello all, i use jails for some testing, but i can not seem to make it > stable. > I use vnet jails with a bridge but when i put some load on it, some > jails loose there network connectivity. > > My setup is as follows, haproxy internal IP 10.233.185.20 using binat > to make it Public accessable. > Then a varnish jail, and two web servers al on the 10.233.185.x range. > > If i give it a little load with hey (hey -h2 -n 10 -c 20 -z 60s > https://wp.test.nl) than within the test the haproxy jail is not > reachable anymore it is not pingable from the host machine, and from > the other jails. restarting the jails solves it, if i leave the system > alone for some time i saw the varnish jail become unresponsive. > > If i do a tcpdump on the epair${name}a interface i do see the packages > from the host machine to the jail but the jail itself is not reachable. > > There is nothing in the logs from the host and the jail itself, i can > ping the jails ip adres from the jail itself. > > > I do not think i have a special setup, but i could be doing something > wrong. > my jail.conf > > # Global settings applied to all jails. > $domain = "test.nl"; > $subdomain = ""; > > exec.start = "/bin/sh /etc/rc"; > exec.stop = "/bin/sh /etc/rc.shutdown"; > exec.clean; > > mount.fstab = "/storage/jails/$name.fstab"; > > exec.system_user  = "root"; > exec.jail_user    = "root"; > mount.devfs; > sysvshm="new"; > sysvsem="new"; > allow.raw_sockets; > allow.set_hostname = 0; > allow.sysvipc; > enforce_statfs = "2"; > devfs_ruleset     = "11"; > > path = "/storage/jails/${name}"; > host.hostname = "${name}${subdomain}.${domain}"; > > # Networking > $uplinkdev        = "vtnet1"; > $epid             = "${ip}"; > $subnet           = "10.233.185."; > $cidr             = "/24"; > $ipv4_addr        = "${subnet}${ip}${cidr}"; > vnet; > vnet.interface    = "vnet0"; > > $epair=epair${ip}; > vnet; > #vnet.interface    = "${epair}b";  # default vnet interface > exec.prestart     = "ifconfig bridge0 > /dev/null 2>&1 || ( ifconfig > bridge0 create up && ifconfig bridge0 addm $uplinkdev )"; > exec.prestart    += "ifconfig ${epair} create up description > jail_${name}   || echo 'Skipped creating epair (exists?)'"; > exec.prestart    += "ifconfig bridge0 addm ${epair}a           || echo > 'Skipped adding bridge member (already member?)'"; > exec.created      = "ifconfig ${epair}b name vnet0"; > exec.start        = "/bin/sh /etc/rc"; > exec.consolelog   = "/var/log/jail/$name.test.nl"; > exec.stop         = "/bin/sh /etc/rc.shutdown"; > exec.poststop     = "ifconfig bridge0 deletem ${epair}a"; > exec.poststop    += "ifconfig ${epair}a destroy"; > > varnish01 { >     $ip = 16; >     mount.fstab = ""; >     path = "/storage/jails/${name}"; > } > > web01 { >     $ip = 18; > } > > web02 { >     $ip = 19; > } > > haproxy { >     $ip = 20; >     mount.fstab = ""; >     path = "/storage/jails/${name}"; > } > > My ifconfig > > bridge0: flags=8843 metric 0 > mtu 1500 >     ether 58:9c:fc:10:ff:82 >     inet 10.233.185.1 netmask 0xffffff00 broadcast 10.233.185.255 >     id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >     maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >     root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >     member: epair20a flags=143 >             ifmaxaddr 0 port 13 priority 128 path cost 2000 >     member: epair19a flags=143 >             ifmaxaddr 0 port 53 priority 128 path cost 2000 >     member: epair18a flags=143 >             ifmaxaddr 0 port 48 priority 128 path cost 2000 >     member: epair16a flags=143 >             ifmaxaddr 0 port 28 priority 128 path cost 2000 >     groups: bridge >     nd6 options=9 > epair16a: flags=8963 > metric 0 mtu 1500 >     description: jail_varnish01 >     options=8 >     ether 02:76:32:8e:0e:0a >     groups: epair >     media: Ethernet 10Gbase-T (10Gbase-T ) >     status: active >     nd6 options=29 > epair18a: flags=8963 > metric 0 mtu 1500 >     description: jail_web01 >     options=8 >     ether 02:6d:be:b8:36:0a >     groups: epair >     media: Ethernet 10Gbase-T (10Gbase-T ) >     status: active >     nd6 options=29 > epair19a: flags=8963 > metric 0 mtu 1500 >     description: jail_web02 >     options=8 >     ether 02:54:fd:77:9a:0a >     groups: epair >     media: Ethernet 10Gbase-T (10Gbase-T ) >     status: active >     nd6 options=29 > epair20a: flags=8963 > metric 0 mtu 1500 >     description: jail_haproxy >     options=8 >     ether 02:f8:58:06:78:0a >     groups: epair >     media: Ethernet 10Gbase-T (10Gbase-T ) >     status: active >     nd6 options=29 > > This is on both 13-STABLE and 14-HEAD. > > For the sake of testing i tried it with FreeBSD 13.0-RELEASE-p7 and this works fine. This is an exact copy of the setup i use on 14-CURRENT and 13-STABLE. (i did a ZFS send and receive of the jails and a copy of the jail.conf. pf.conf and so on) I did run the hey command targeting the 13-0-RELEASE multiple times. hey -h2 -n 10 -c 30 -z 300s https://wp.test.nl Summary:   Total:    300.0045 secs   Slowest:    0.1137 secs   Fastest:    0.0006 secs   Average:    0.0090 secs   Requests/sec:    4627.4504 Response time histogram:   0.001 [1]    |   0.012 [977291]    |â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â– â–    0.023 [21236]    |â–    0.035 [1125]    |   0.046 [230]    |   0.057 [12]    |   0.068 [18]    |   0.080 [9]    |   0.091 [18]    |   0.102 [30]    |   0.114 [30]    | Latency distribution:   10% in 0.0037 secs   25% in 0.0046 secs   50% in 0.0061 secs   75% in 0.0080 secs   90% in 0.0096 secs   95% in 0.0106 secs   99% in 0.0133 secs Details (average, fastest, slowest):   DNS+dialup:    0.0000 secs, 0.0006 secs, 0.1137 secs   DNS-lookup:    0.0000 secs, 0.0000 secs, 0.0028 secs   req write:    0.0001 secs, 0.0000 secs, 0.1126 secs   resp wait:    0.0192 secs, 0.0000 secs, 214.9645 secs   resp read:    0.0018 secs, 0.0002 secs, 0.1076 secs Status code distribution:   [200]    1000000 responses All is fine on the 13.0-RELEASE-p7 also with a higher concurrency, however if i do it against the 14-CURRENT or the 13-STABLE, even a run of 60 seconds kills the network connectivity of the jail. (haproxy in my case) regards, Johan From nobody Mon Mar 7 20:54:26 2022 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 CD11219F3841; Mon, 7 Mar 2022 20:54:29 +0000 (UTC) (envelope-from SRS0=34E+=TS=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 4KC9gT00PNz3rwN; Mon, 7 Mar 2022 20:54:28 +0000 (UTC) (envelope-from SRS0=34E+=TS=klop.ws=ronald-lists@realworks.nl) Date: Mon, 7 Mar 2022 21:54:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1646686466; 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=5WNf6aELst4UDlOXYajv/u8+6WSw4kSQiOjBQwM7D+M=; b=jAlcHq6vTJ7WTgxh0OfUPPh78lWhxKuZAUdEMpYO5yY2sZ6V5+/e4cgpvogNum7vStsSAj RumkfT+eKvfn/gyo3UserZHdTngoyzsNoVlH+jL5IGLuM36gkkCgXmWjgN9zgfoo8wYX1L YGqk2OtcZX6e3d+mBc1Vxo+p9RC4dHBmuXDTiPQmI6OM0H0sxbBkxrhZ5KMUNwr/R28BVf R9MljJf/KNllvctYD0HCQOPz8qckUKIFCCu5mWuKjL3dUyozp9GFcWS5D+QOyi+AB3Qkk/ 8OVkU0uvkCaM7gL7nLu4NAmoEu0BECadRgWqNK02Bw8aYQvWhje3o6CY928Tzw== From: Ronald Klop To: Mark Johnston Cc: bob prohaska , Mark Millard , freebsd-arm@freebsd.org, freebsd-current Message-ID: <1302689164.173.1646686466515@mailrelay> In-Reply-To: References: <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay> Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) 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_172_1254189170.1646686466401" X-Mailer: Realworks (599.211.aa1e011) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4KC9gT00PNz3rwN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=jAlcHq6v; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=34E@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=34E@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=34E@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; TAGGED_FROM(0.00)[=TS=klop.ws=ronald-lists]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=34E@realworks.nl]; FREEMAIL_CC(0.00)[www.zefox.net,yahoo.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_172_1254189170.1646686466401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Mark Johnston Datum: maandag, 7 maart 2022 16:13 Aan: Ronald Klop CC: bob prohaska , Mark Millard , freebsd-arm@freebsd.org, freebsd-current Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) > > On Mon, Mar 07, 2022 at 02:46:09PM +0100, Ronald Klop wrote: > > Dear Mark Johnston, > > > > I did some binary search in the kernels and came to the conclusion that https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e still works and https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a panics. > > > > I suspect your commit in https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a. > > > > Last panic: > > > > panic: vm_fault failed: ffff00000046e708 error 1 > > cpuid = 1 > > time = 1646660058 > > KDB: stack backtrace: > > db_trace_self() at db_trace_self > > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > > vpanic() at vpanic+0x174 > > panic() at panic+0x44 > > data_abort() at data_abort+0x2e8 > > handle_el1h_sync() at handle_el1h_sync+0x10 > > --- exception, esr 0x96000004 > > _rm_rlock_debug() at _rm_rlock_debug+0x8c > > osd_get() at osd_get+0x5c > > zio_execute() at zio_execute+0xf8 > > taskqueue_run_locked() at taskqueue_run_locked+0x178 > > taskqueue_thread_loop() at taskqueue_thread_loop+0xc8 > > fork_exit() at fork_exit+0x74 > > fork_trampoline() at fork_trampoline+0x14 > > KDB: enter: panic > > [ thread pid 0 tid 100129 ] > > Stopped at kdb_enter+0x44: undefined f902011f > > db> > > > > A more recent kernel (912df91) still panics. See below. > > > > Do you have time to look into this? What can I provide in information to help? > > Hmm. So after my rmlock commits, we have the following disassembly for > _rm_rlock() (with a few annotations added by me). Note that the pcpu > pointer is stored in register x18 by convention. > > 0xffff00000046e304 <+0>: stp x29, x30, [sp, #-16]! > 0xffff00000046e308 <+4>: mov x29, sp > 0xffff00000046e30c <+8>: ldr x8, [x18] > 0xffff00000046e310 <+12>: ldr x9, [x18] > 0xffff00000046e314 <+16>: ldr x10, [x18] > 0xffff00000046e318 <+20>: cmp x9, x10 > 0xffff00000046e31c <+24>: b.ne 0xffff00000046e3cc <_rm_rlock+200> // b.any > 0xffff00000046e320 <+28>: ldr x9, [x18] > 0xffff00000046e324 <+32>: ldrh w9, [x9, #314] > 0xffff00000046e328 <+36>: cbnz w9, 0xffff00000046e3c0 <_rm_rlock+188> > 0xffff00000046e32c <+40>: str wzr, [x1, #32] > 0xffff00000046e330 <+44>: stp x0, x8, [x1, #16] > 0xffff00000046e334 <+48>: ldrb w9, [x0, #10] > 0xffff00000046e338 <+52>: tbz w9, #4, 0xffff00000046e358 <_rm_rlock+84> > 0xffff00000046e33c <+56>: ldr x9, [x18] > 0xffff00000046e340 <+60>: ldr w10, [x9, #888] > 0xffff00000046e344 <+64>: add w10, w10, #0x1 > 0xffff00000046e348 <+68>: str w10, [x9, #888] > 0xffff00000046e34c <+72>: ldr x9, [x18] > 0xffff00000046e350 <+76>: ldr w9, [x9, #888] > 0xffff00000046e354 <+80>: cbz w9, 0xffff00000046e3f4 <_rm_rlock+240> > 0xffff00000046e358 <+84>: ldr w9, [x8, #1212] > 0xffff00000046e35c <+88>: add x10, x18, #0x90 > 0xffff00000046e360 <+92>: add w9, w9, #0x1 > 0xffff00000046e364 <+96>: str w9, [x8, #1212] <------- critical_enter > 0xffff00000046e368 <+100>: str x10, [x1, #8] > 0xffff00000046e36c <+104>: ldr x9, [x18, #144] > 0xffff00000046e370 <+108>: str x9, [x1] > 0xffff00000046e374 <+112>: str x1, [x9, #8] > 0xffff00000046e378 <+116>: str x1, [x18, #144] > 0xffff00000046e37c <+120>: ldr x9, [x18] > 0xffff00000046e380 <+124>: ldr w10, [x9, #356] > 0xffff00000046e384 <+128>: add w10, w10, #0x1 > 0xffff00000046e388 <+132>: str w10, [x9, #356] > 0xffff00000046e38c <+136>: ldr w9, [x8, #1212] > 0xffff00000046e390 <+140>: sub w9, w9, #0x1 > 0xffff00000046e394 <+144>: str w9, [x8, #1212] <------- critical_exit > 0xffff00000046e398 <+148>: ldrb w8, [x8, #304] > 0xffff00000046e39c <+152>: ldr w9, [x18, #60] <------- loading &pc->pc_cpuid > ... > > A (the?) problem is that the compiler is treating "pc" as an alias > for x18, but the rmlock code assumes that the pcpu pointer is loaded > once, as it dereferences "pc" outside of the critical section. On > arm64, if a context switch occurs between the store at _rm_rlock+144 and > the load at +152, and the thread is migrated to another CPU, then we'll > end up using the wrong CPU ID in the rm->rm_writecpus test. > > I suspect the problem is unique to arm64 as its get_pcpu() > implementation is different from the others in that it doesn't use > volatile-qualified inline assembly. This has been the case since > https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762 > . > > I haven't been able to reproduce any crashes running poudriere in an > arm64 AWS instance, though. Could you please try the patch below and > confirm whether it fixes your panics? I verified that the apparent > problem described above is gone with the patch. > > diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c > index 0cdcfb8fec62..e51c25136ae0 100644 > --- a/sys/kern/kern_rmlock.c > +++ b/sys/kern/kern_rmlock.c > @@ -437,6 +437,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) > { > struct thread *td = curthread; > struct pcpu *pc; > + int cpuid; > > if (SCHEDULER_STOPPED()) > return (1); > @@ -452,6 +453,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) > atomic_interrupt_fence(); > > pc = get_pcpu(); > + cpuid = pc->pc_cpuid; > rm_tracker_add(pc, tracker); > sched_pin(); > > @@ -463,7 +465,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) > * conditional jump. > */ > if (__predict_true(0 == (td->td_owepreempt | > - CPU_ISSET(pc->pc_cpuid, &rm->rm_writecpus)))) > + CPU_ISSET(cpuid, &rm->rm_writecpus)))) > return (1); > > /* We do not have a read token and need to acquire one. */ > > > Hi, This patch paniced again: x0: ffffa00005a31500 x1: ffffa00005a0e000 x2: 2 x3: ffffa00076c4e9a0 x4: 0 x5: e672743c8f9e5 x6: dc89f70500ab1 x7: 14 x8: ffffa00005a31518 x9: 1 x10: ffffa00005a0e000 x11: 0 x12: 0 x13: a x14: 1013e6b85a8ecbe4 x15: 1dce740d11a5 x16: ffff3ea86e2434bf x17: fffffffffffffff2 x18: ffff0000fe661800 (g_ctx + fcf9fa54) x19: ffffa00076c4e9a0 x20: ffff0000fec39000 (g_ctx + fd577254) x21: 2 x22: ffff0000419b6090 (g_ctx + 402f42e4) x23: ffff000000c0b137 (lockstat_enabled + 0) x24: 100 x25: ffff000000c0b000 (version + a0) x26: ffff000000c0b000 (version + a0) x27: ffff000000c0b000 (version + a0) x28: 0 x29: ffff0000fe661800 (g_ctx + fcf9fa54) sp: ffff0000fe661800 lr: ffff00000154ea50 (zio_dva_throttle + 154) elr: ffff00000154ea80 (zio_dva_throttle + 184) spsr: 60000045 far: 2b753286b0b8 panic: Unknown kernel exception 0 esr_el1 2000000 cpuid = 1 time = 1646685857 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 do_el1h_sync() at do_el1h_sync+0x184 handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0x2000000 zio_dva_throttle() at zio_dva_throttle+0x184 zio_execute() at zio_execute+0x58 KDB: enter: panic [ thread pid 0 tid 100129 ] Stopped at kdb_enter+0x44: undefined f901c11f db> Will try the patch of Andrew next. Compilation might take a while so maybe it wil be tomorrow. Regards, Ronald. ------=_Part_172_1254189170.1646686466401 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Van: Mark Johnston <markj@freebsd.org>
Datum: maandag, 7 maart 2022 16:13
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: bob prohaska <fbsd@www.zefox.net>, Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org, freebsd-current <freebsd-current@freebsd.org>
Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28))

On Mon, Mar 07, 2022 at 02:46:09PM +0100, Ronald Klop wrote:
> Dear Mark Johnston,
>
> I did some binary search in the kernels and came to the conclusion that https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e still works and https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a panics.
>
> I suspect your commit in https://cgit.freebsd.org/src/commit/?id=c84bb8cd771ce4bed58152e47a32dda470bef23a.
>
> Last panic:
>
> panic: vm_fault failed: ffff00000046e708 error 1
> cpuid = 1
> time = 1646660058
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> data_abort() at data_abort+0x2e8
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000004
> _rm_rlock_debug() at _rm_rlock_debug+0x8c
> osd_get() at osd_get+0x5c
> zio_execute() at zio_execute+0xf8
> taskqueue_run_locked() at taskqueue_run_locked+0x178
> taskqueue_thread_loop() at taskqueue_thread_loop+0xc8
> fork_exit() at fork_exit+0x74
> fork_trampoline() at fork_trampoline+0x14
> KDB: enter: panic
> [ thread pid 0 tid 100129 ]
> Stopped at      kdb_enter+0x44: undefined       f902011f
> db>
>
> A more recent kernel (912df91) still panics. See below.
>
> Do you have time to look into this? What can I provide in information to help?

Hmm.  So after my rmlock commits, we have the following disassembly for
_rm_rlock() (with a few annotations added by me).  Note that the pcpu
pointer is stored in register x18 by convention.

   0xffff00000046e304 <+0>:     stp     x29, x30, [sp, #-16]!
   0xffff00000046e308 <+4>:     mov     x29, sp
   0xffff00000046e30c <+8>:     ldr     x8, [x18]
   0xffff00000046e310 <+12>:    ldr     x9, [x18]
   0xffff00000046e314 <+16>:    ldr     x10, [x18]
   0xffff00000046e318 <+20>:    cmp     x9, x10
   0xffff00000046e31c <+24>:    b.ne    0xffff00000046e3cc <_rm_rlock+200>  // b.any
   0xffff00000046e320 <+28>:    ldr     x9, [x18]
   0xffff00000046e324 <+32>:    ldrh    w9, [x9, #314]
   0xffff00000046e328 <+36>:    cbnz    w9, 0xffff00000046e3c0 <_rm_rlock+188>
   0xffff00000046e32c <+40>:    str     wzr, [x1, #32]
   0xffff00000046e330 <+44>:    stp     x0, x8, [x1, #16]
   0xffff00000046e334 <+48>:    ldrb    w9, [x0, #10]
   0xffff00000046e338 <+52>:    tbz     w9, #4, 0xffff00000046e358 <_rm_rlock+84>
   0xffff00000046e33c <+56>:    ldr     x9, [x18]
   0xffff00000046e340 <+60>:    ldr     w10, [x9, #888]
   0xffff00000046e344 <+64>:    add     w10, w10, #0x1
   0xffff00000046e348 <+68>:    str     w10, [x9, #888]
   0xffff00000046e34c <+72>:    ldr     x9, [x18]
   0xffff00000046e350 <+76>:    ldr     w9, [x9, #888]
   0xffff00000046e354 <+80>:    cbz     w9, 0xffff00000046e3f4 <_rm_rlock+240>
   0xffff00000046e358 <+84>:    ldr     w9, [x8, #1212]
   0xffff00000046e35c <+88>:    add     x10, x18, #0x90
   0xffff00000046e360 <+92>:    add     w9, w9, #0x1
   0xffff00000046e364 <+96>:    str     w9, [x8, #1212]  <------- critical_enter
   0xffff00000046e368 <+100>:   str     x10, [x1, #8]
   0xffff00000046e36c <+104>:   ldr     x9, [x18, #144]
   0xffff00000046e370 <+108>:   str     x9, [x1]
   0xffff00000046e374 <+112>:   str     x1, [x9, #8]
   0xffff00000046e378 <+116>:   str     x1, [x18, #144]
   0xffff00000046e37c <+120>:   ldr     x9, [x18]
   0xffff00000046e380 <+124>:   ldr     w10, [x9, #356]
   0xffff00000046e384 <+128>:   add     w10, w10, #0x1
   0xffff00000046e388 <+132>:   str     w10, [x9, #356]
   0xffff00000046e38c <+136>:   ldr     w9, [x8, #1212]
   0xffff00000046e390 <+140>:   sub     w9, w9, #0x1
   0xffff00000046e394 <+144>:   str     w9, [x8, #1212]  <------- critical_exit
   0xffff00000046e398 <+148>:   ldrb    w8, [x8, #304]
   0xffff00000046e39c <+152>:   ldr     w9, [x18, #60]   <------- loading &pc->pc_cpuid
   ...

A (the?) problem is that the compiler is treating "pc" as an alias
for x18, but the rmlock code assumes that the pcpu pointer is loaded
once, as it dereferences "pc" outside of the critical section.  On
arm64, if a context switch occurs between the store at _rm_rlock+144 and
the load at +152, and the thread is migrated to another CPU, then we'll
end up using the wrong CPU ID in the rm->rm_writecpus test.

I suspect the problem is unique to arm64 as its get_pcpu()
implementation is different from the others in that it doesn't use
volatile-qualified inline assembly.  This has been the case since
https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762
.

I haven't been able to reproduce any crashes running poudriere in an
arm64 AWS instance, though.  Could you please try the patch below and
confirm whether it fixes your panics?  I verified that the apparent
problem described above is gone with the patch.

diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c
index 0cdcfb8fec62..e51c25136ae0 100644
--- a/sys/kern/kern_rmlock.c
+++ b/sys/kern/kern_rmlock.c
@@ -437,6 +437,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
 {
    struct thread *td = curthread;
    struct pcpu *pc;
+   int cpuid;
 
    if (SCHEDULER_STOPPED())
        return (1);
@@ -452,6 +453,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
    atomic_interrupt_fence();
 
    pc = get_pcpu();
+   cpuid = pc->pc_cpuid;
    rm_tracker_add(pc, tracker);
    sched_pin();
 
@@ -463,7 +465,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock)
     * conditional jump.
     */
    if (__predict_true(0 == (td->td_owepreempt |
-       CPU_ISSET(pc->pc_cpuid, &rm->rm_writecpus))))
+       CPU_ISSET(cpuid, &rm->rm_writecpus))))
        return (1);
 
    /* We do not have a read token and need to acquire one. */

Hi,

This patch paniced again: 
x0: ffffa00005a31500                                                                                             
  x1: ffffa00005a0e000                                                                                                            
  x2:                2                                                                                                            
  x3: ffffa00076c4e9a0                                                                                                            
  x4:                0                                                                                                            
  x5:    e672743c8f9e5                                                                                                            
  x6:    dc89f70500ab1
  x7:               14
  x8: ffffa00005a31518
  x9:                1
 x10: ffffa00005a0e000
 x11:                0
 x12:                0
 x13:                a
 x14: 1013e6b85a8ecbe4
 x15:     1dce740d11a5
 x16: ffff3ea86e2434bf
 x17: fffffffffffffff2
 x18: ffff0000fe661800 (g_ctx + fcf9fa54)
 x19: ffffa00076c4e9a0
 x20: ffff0000fec39000 (g_ctx + fd577254)
 x21:                2
 x22: ffff0000419b6090 (g_ctx + 402f42e4)
 x23: ffff000000c0b137 (lockstat_enabled + 0)
 x24:              100
 x25: ffff000000c0b000 (version + a0)
 x26: ffff000000c0b000 (version + a0)
 x27: ffff000000c0b000 (version + a0)
 x28:                0
 x29: ffff0000fe661800 (g_ctx + fcf9fa54)
  sp: ffff0000fe661800
  lr: ffff00000154ea50 (zio_dva_throttle + 154)
 elr: ffff00000154ea80 (zio_dva_throttle + 184)
spsr:         60000045
 far:     2b753286b0b8
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 1
time = 1646685857
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x184
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
zio_dva_throttle() at zio_dva_throttle+0x184
zio_execute() at zio_execute+0x58
KDB: enter: panic
[ thread pid 0 tid 100129 ]
Stopped at      kdb_enter+0x44: undefined       f901c11f
db>  
Will try the patch of Andrew next. Compilation might take a while so maybe it wil be tomorrow.

Regards,
Ronald.
  ------=_Part_172_1254189170.1646686466401-- From nobody Mon Mar 7 21:17:56 2022 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 70AC319F828F for ; Mon, 7 Mar 2022 21:18:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KCBBj7092z3vvd for ; Mon, 7 Mar 2022 21:18:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646687878; bh=mCcHKlyBPNimdscd7fOFHd6k1HiIvRhwt6DQ7NzFRkI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=nx3fLBE0zfYQStJCgBtlJ9X+9Rx8i2Sl7RgQ6DSr96zNxKQDl57ddKZcSNoJBS1ILDJIWP6x7Olte2zMIxH1N62y1HwzCapJzgWMeXM3tpdU6qpNKJiihKTgopVGPCcUg9QQihrVc+YxNWYvZ+QKE0nipmkXaWSUZSaX3wgmhJ6u93sfcbNVmzWhd2RBQmUgetPFN457AlKawo45tjl7rWgUhnDTInAerZ1kWrwocbFzXFs/GQrofn4W9Jz9i/HQhc+Mmrs7iFJ9XnPXxdvntdVrxfigsfkEI89kJSgcu/w23E6rJXG/cDRXWo3LUaPI9tW1pyLHwpJRGTjLbIRX0Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646687878; bh=5yhuMu/hrdZgUGc/kWru4Er/LpCJ6hXxGsKMw5ybvs8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TSO0nJe5VS8xc8MOXgS8b8+AKjyYq/uheS963BpjdIrMbxv/re49c8ZAvrvXQaStq9FTcTEslQfftt4z5TGwsB+dFuNN5UIUPmvGbEE42DahdzKuYaqYAY7kE0mVvgGJ++RxpIJWmP8GgpMwxTqSRc1Ofn4M7/P5+fv3f3i6cIlme8evjjlrFwNLwwhltB1XJ0WLTGvG6hb5AP/qL+pwEJtNiT1ZpOzQ4XSs8n9pmIrlFlfHyW006YOa8nhRCdrh/ejfSbaKoVUv6WdSqJWdwyFmqj/Z9ZU1AsUWx5mamVcEz+5BszRFDFfnpy62H8gl4b+QtkMjPdHYLV24nFUETQ== X-YMail-OSG: IGkmHDkVM1mDTahsWpU94Y_ch5zSIEfGGpzxdFxx.iAUNBmgEmRy2asCQK34.1v 7AuRZ1RyJ4R2ZMvKhhRHIx6D41ZiSvT.cpsn5OYr3de99T5mr1hOXUhWntq2CPuoSIwQRCDVsCc2 T1yngpqtdwuhlSZxi7wsgC.96b3WKHjRmFtVtlBJszyGhV2djRstrrLQHZCTi4qCWlYs4jZeSIWY QbbfdVzGJ0h1RfUUYsh5KjDaQRmHaf8sIdHTIgv_vnDJP_dtAPaGvs95LA.P2ZegoIEEhAqkNBOi noasm91mMM5fIfo_0N.GvWVw4dCbfNB3Rk2dCrhOfzRxoxw6Jr3h8CzD8q0QYRw0Ke8UHKJmxKNZ 9upF1ZBi8jlmbRtoSMmJFxWJSStH3QExV_FF0poWxJ3Hx9vz2wi9J4XxYwwwiKJQJZzop_VGqb_3 HwuH_1J0htSxMNnx0FoUOGXxOwCnsZD3N_RymV9dHTilElMJbmoFCs_130Old2qYMlSFTtc0e4kS u.r5fXfvkh6LDqaf.mf2gOPdsqvvRmpIU1IP_WgpUKTKb8fuYByYmus3Nrs5QUvbY9ccbuUfnv07 VvtVrIhm4ICl7rTErdg_NhL76.gdRBSEgscgUcDnrh9Ia5Tf4.NZxcMy2zENDed2ANJ2kmxeApvd FonfnWFczQv7nKoaa5Mpbtrj7Iaj3.jI7ToNUczHXS2EZiFIS2seqBto9Rn.sVg5nk3.ITwviBQe GoQIA7uBB47RDX4NpcZdwF8u77_yBMNQ0Fw1G43YMpaZKk3eOhVErVxxiRIhPnN4k37Bi6Vf4u0u 88RQMRfGdhcQS16FrQT.bnWYFtpM0QCzMVaBdLoXiIpZPp_CjnwPWk4QWv3X62jmtzsr1xeUGroQ EZU9tfQ8LzsIo6eDDpWJaNugKRwJI7Ke47aoq8vwEftwuNXXg32HKWZ9GPUp8CNNAXr1IYAXiomA Fg4tI2cS272Kd5HPQhg40zIvTWOowe85NScANDeQMcGJn20YYTDkWMOMSSGjC0i0y5DA3qA4PXEV fLVWsDXX6KZenOtNqORkDCw8RjcxpqhtvXp6zYvd2T2bo7bWRJVvxBs8YsCYsiLT_077.1MbkqGx Rjsu7m9ojFjRSwx0G66WSQHZEg0Hv2t1ScR04knkHSZ5G8O5Y4Kb7Kxj7E10yC75gPVBHwkNKwwv 9WYUxQL0QRRZcMXwpm4YCV9v_kc.fhBMTNhxdH4Ttwuk.gWRUUypKqjiWDSThTPXyu.w9vrBnqOi zbnrUUcAJWY9XQiYaQ0QXO3B2p8DCBRXvOGIrZWlOy8.9PmQ60RJmzCYeGEAKK.uiVefZmnRQPgR dKYuzkIMCSMkPY2BDxqqYxTceTbMQuhqEV3bfrW3WV3mzSEdOmR0dz3f4XgWmFs3F.ptZ4XdpZuR nmBRRoACT3bwI5AwmQwfo9J36oiglpaB1Y_nKdy2Wo38B3m1MGBRqFi3ZZmmoBdYFtV_Eg_U83em _jq59HrwDLWwFWtjhb_cwt4zBR91hUI3R5CtOs3HKLgoFcLWEKrQPasdH3WJ_n41NpTTgF2t5_.A .8aL4oipiIEd1Z_qoNlgVvUrHDTe2SRGg6460TXoOpy6NK2gQWIa4ZoCxGGqAVozwXM6LvumEnhM uNPZ7d9T22ADTVa6RfR0xMYAm4L.arQlVK5hZ8ZEPJ_72nMvYolSQrvkswHj_MpCevTcJFVft4O7 P8hCPgOCQn68kVAVZ9p1tfdD5LIh7kWG.qZ1KJ5cjPjKvx2F4CLfBWyOh59UqV.EByaLc5cXLTbw Cz4guN_ojV3rZubBTrcGL42cCZ0RJHpB6Z2IFLXBzrZ_hWQVamhlhVGNoposuVAEiccdpbgF9rAy FXqLwdYR2ZAOmKxMNgtcXWg5VuYVLdkhbopYJyB0fTT3krVTngeU.1k3auD0btnZQngOT_JmbvPM qT3s.wAlz18g312PdNoJIa.hwjPBscs_5ty4rYoSG8QVu.Wwqwpjveo99QS59e6hQsKobgdZ_F7c jdu3qQYwQ0GNTjMA_Ev1VDsMj8lwNhaMW7NlLb59DPAcF6K0vkw4WElSIvanrXhrUgHqaYcaa5Jp WVy03bGEk4ghjXEjAFBVErgW.7XKf9snjxBztAOFvcPTKxiDOsK4_W3.I4q7WxKxvoKzsylyUwX7 9Bgxbn5N180TIyzaQtR8pvZ72RGNtKwH_9mLJGO_YLQA6ZUf2KGKxSVuiN4vj_UwlyedBkTgFUmd c_cr5dmOZXMJkljoqfmc4rrTcQW4DCTJ8FH0tuzADtx.MxyKYM7grugVJ32pugwp6Q4e_zFX1sf7 hFC1.CJYmPvpWHIIQdsFqf.Hoc6oTJi2hPW4.4DbSGRDMalhy0pd6AVihKJp9zl61RZevqcbtVYm TKADKMqVIhwaAZmfWRMnz9w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Mar 2022 21:17:58 +0000 Received: by kubenode521.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e1549565dc8fadf08c44473826d7d7bb; Mon, 07 Mar 2022 21:17:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) From: Mark Millard X-Priority: 3 (Normal) In-Reply-To: <1302689164.173.1646686466515@mailrelay> Date: Mon, 7 Mar 2022 13:17:56 -0800 Cc: Mark Johnston , bob prohaska , Free BSD , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay> <1302689164.173.1646686466515@mailrelay> To: Ronald Klop X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KCBBj7092z3vvd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nx3fLBE0; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Mar-7, at 12:54, Ronald Klop wrote: > Van: Mark Johnston > Datum: maandag, 7 maart 2022 16:13 > Aan: Ronald Klop > CC: bob prohaska , Mark Millard = , freebsd-arm@freebsd.org, freebsd-current = > Onderwerp: Re: panic: data abort in critical section or under mutex = (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on = 14-CURRENT/aarch64 Feb 28)) >=20 > On Mon, Mar 07, 2022 at 02:46:09PM +0100, Ronald Klop wrote: > > Dear Mark Johnston, > > > > I did some binary search in the kernels and came to the conclusion = that = https://cgit.freebsd.org/src/commit/?id=3D1517b8d5a7f58897200497811de1b188= 09c07d3e still works and = https://cgit.freebsd.org/src/commit/?id=3D407c34e735b5d17e2be574808a09e6d7= 29b0a45a panics. > > > > I suspect your commit in = https://cgit.freebsd.org/src/commit/?id=3Dc84bb8cd771ce4bed58152e47a32dda4= 70bef23a. > > > > Last panic: > > > > panic: vm_fault failed: ffff00000046e708 error 1 > > cpuid =3D 1 > > time =3D 1646660058 > > KDB: stack backtrace: > > db_trace_self() at db_trace_self > > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > > vpanic() at vpanic+0x174 > > panic() at panic+0x44 > > data_abort() at data_abort+0x2e8 > > handle_el1h_sync() at handle_el1h_sync+0x10 > > --- exception, esr 0x96000004 > > _rm_rlock_debug() at _rm_rlock_debug+0x8c > > osd_get() at osd_get+0x5c > > zio_execute() at zio_execute+0xf8 > > taskqueue_run_locked() at taskqueue_run_locked+0x178 > > taskqueue_thread_loop() at taskqueue_thread_loop+0xc8 > > fork_exit() at fork_exit+0x74 > > fork_trampoline() at fork_trampoline+0x14 > > KDB: enter: panic > > [ thread pid 0 tid 100129 ] > > Stopped at kdb_enter+0x44: undefined f902011f > > db> > > > > A more recent kernel (912df91) still panics. See below. > > > > Do you have time to look into this? What can I provide in = information to help? >=20 > Hmm. So after my rmlock commits, we have the following disassembly = for > _rm_rlock() (with a few annotations added by me). Note that the pcpu > pointer is stored in register x18 by convention. >=20 > 0xffff00000046e304 <+0>: stp x29, x30, [sp, #-16]! > 0xffff00000046e308 <+4>: mov x29, sp > 0xffff00000046e30c <+8>: ldr x8, [x18] > 0xffff00000046e310 <+12>: ldr x9, [x18] > 0xffff00000046e314 <+16>: ldr x10, [x18] > 0xffff00000046e318 <+20>: cmp x9, x10 > 0xffff00000046e31c <+24>: b.ne 0xffff00000046e3cc = <_rm_rlock+200> // b.any > 0xffff00000046e320 <+28>: ldr x9, [x18] > 0xffff00000046e324 <+32>: ldrh w9, [x9, #314] > 0xffff00000046e328 <+36>: cbnz w9, 0xffff00000046e3c0 = <_rm_rlock+188> > 0xffff00000046e32c <+40>: str wzr, [x1, #32] > 0xffff00000046e330 <+44>: stp x0, x8, [x1, #16] > 0xffff00000046e334 <+48>: ldrb w9, [x0, #10] > 0xffff00000046e338 <+52>: tbz w9, #4, 0xffff00000046e358 = <_rm_rlock+84> > 0xffff00000046e33c <+56>: ldr x9, [x18] > 0xffff00000046e340 <+60>: ldr w10, [x9, #888] > 0xffff00000046e344 <+64>: add w10, w10, #0x1 > 0xffff00000046e348 <+68>: str w10, [x9, #888] > 0xffff00000046e34c <+72>: ldr x9, [x18] > 0xffff00000046e350 <+76>: ldr w9, [x9, #888] > 0xffff00000046e354 <+80>: cbz w9, 0xffff00000046e3f4 = <_rm_rlock+240> > 0xffff00000046e358 <+84>: ldr w9, [x8, #1212] > 0xffff00000046e35c <+88>: add x10, x18, #0x90 > 0xffff00000046e360 <+92>: add w9, w9, #0x1 > 0xffff00000046e364 <+96>: str w9, [x8, #1212] <------- = critical_enter > 0xffff00000046e368 <+100>: str x10, [x1, #8] > 0xffff00000046e36c <+104>: ldr x9, [x18, #144] > 0xffff00000046e370 <+108>: str x9, [x1] > 0xffff00000046e374 <+112>: str x1, [x9, #8] > 0xffff00000046e378 <+116>: str x1, [x18, #144] > 0xffff00000046e37c <+120>: ldr x9, [x18] > 0xffff00000046e380 <+124>: ldr w10, [x9, #356] > 0xffff00000046e384 <+128>: add w10, w10, #0x1 > 0xffff00000046e388 <+132>: str w10, [x9, #356] > 0xffff00000046e38c <+136>: ldr w9, [x8, #1212] > 0xffff00000046e390 <+140>: sub w9, w9, #0x1 > 0xffff00000046e394 <+144>: str w9, [x8, #1212] <------- = critical_exit > 0xffff00000046e398 <+148>: ldrb w8, [x8, #304] > 0xffff00000046e39c <+152>: ldr w9, [x18, #60] <------- = loading &pc->pc_cpuid > ... >=20 > A (the?) problem is that the compiler is treating "pc" as an alias > for x18, but the rmlock code assumes that the pcpu pointer is loaded > once, as it dereferences "pc" outside of the critical section. On > arm64, if a context switch occurs between the store at _rm_rlock+144 = and > the load at +152, and the thread is migrated to another CPU, then = we'll > end up using the wrong CPU ID in the rm->rm_writecpus test. >=20 > I suspect the problem is unique to arm64 as its get_pcpu() > implementation is different from the others in that it doesn't use > volatile-qualified inline assembly. This has been the case since > = https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbddf85ad04fc8e= 99e73762 > . >=20 > I haven't been able to reproduce any crashes running poudriere in an > arm64 AWS instance, though. Could you please try the patch below and > confirm whether it fixes your panics? I verified that the apparent > problem described above is gone with the patch. >=20 > diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c > index 0cdcfb8fec62..e51c25136ae0 100644 > --- a/sys/kern/kern_rmlock.c > +++ b/sys/kern/kern_rmlock.c > @@ -437,6 +437,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker = *tracker, int trylock) > { > struct thread *td =3D curthread; > struct pcpu *pc; > + int cpuid; > =20 > if (SCHEDULER_STOPPED()) > return (1); > @@ -452,6 +453,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker = *tracker, int trylock) > atomic_interrupt_fence(); > =20 > pc =3D get_pcpu(); > + cpuid =3D pc->pc_cpuid; > rm_tracker_add(pc, tracker); > sched_pin(); > =20 > @@ -463,7 +465,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker = *tracker, int trylock) > * conditional jump. > */ > if (__predict_true(0 =3D=3D (td->td_owepreempt | > - CPU_ISSET(pc->pc_cpuid, &rm->rm_writecpus)))) > + CPU_ISSET(cpuid, &rm->rm_writecpus)))) > return (1); > =20 > /* We do not have a read token and need to acquire one. */ >=20 > Hi, >=20 > This patch paniced again: > x0: ffffa00005a31500 = =20 > x1: ffffa00005a0e000 = =20 > x2: 2 = =20 > x3: ffffa00076c4e9a0 = =20 > x4: 0 = =20 > x5: e672743c8f9e5 = =20 > x6: dc89f70500ab1 > x7: 14 > x8: ffffa00005a31518 > x9: 1 > x10: ffffa00005a0e000 > x11: 0 > x12: 0 > x13: a > x14: 1013e6b85a8ecbe4 > x15: 1dce740d11a5 > x16: ffff3ea86e2434bf > x17: fffffffffffffff2 > x18: ffff0000fe661800 (g_ctx + fcf9fa54) > x19: ffffa00076c4e9a0 > x20: ffff0000fec39000 (g_ctx + fd577254) > x21: 2 > x22: ffff0000419b6090 (g_ctx + 402f42e4) > x23: ffff000000c0b137 (lockstat_enabled + 0) > x24: 100 > x25: ffff000000c0b000 (version + a0) > x26: ffff000000c0b000 (version + a0) > x27: ffff000000c0b000 (version + a0) > x28: 0 > x29: ffff0000fe661800 (g_ctx + fcf9fa54) > sp: ffff0000fe661800 > lr: ffff00000154ea50 (zio_dva_throttle + 154) > elr: ffff00000154ea80 (zio_dva_throttle + 184) > spsr: 60000045 > far: 2b753286b0b8 > panic: Unknown kernel exception 0 esr_el1 2000000 > cpuid =3D 1 > time =3D 1646685857 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x174 > panic() at panic+0x44 > do_el1h_sync() at do_el1h_sync+0x184 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x2000000 > zio_dva_throttle() at zio_dva_throttle+0x184 > zio_execute() at zio_execute+0x58 > KDB: enter: panic > [ thread pid 0 tid 100129 ] > Stopped at kdb_enter+0x44: undefined f901c11f > db> =20 Hmm. My somewhat older source code shows zio_dva_throttle as having: mutex_enter(&spa->spa_allocs[allocator].spaa_lock); avl_add(&spa->spa_allocs[allocator].spaa_tree, zio); nio =3D zio_io_to_allocate(spa, allocator); mutex_exit(&spa->spa_allocs[allocator].spaa_lock); return (nio); That might have implications if the issue is actually analogous to _rm_rlock_debug crashes in some way. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Mar 7 21:42:54 2022 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 5277919FD8FA; Mon, 7 Mar 2022 21:42:59 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KCBlQ3Ssfz4T8b; Mon, 7 Mar 2022 21:42:58 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82d.google.com with SMTP id bc10so14527994qtb.5; Mon, 07 Mar 2022 13:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=keQ4L7UbBstjJ4Z8l3tC/GCwog+37U4yNm5EHWpkJyI=; b=YELCZYJVzFSkd+idx/YfA9Oyt9zrPW4l4hTnpgFxkIw0g4cVnTc+oOZHzT6pnVLh+0 P5j81luLKkOxJF+Chxwkps5FMEpukmrgyH1E7EFko6LndBrY4In2V41MAjp4Le87ukuy kIZa/BG7ERp8/gvjZcod7fElWLpR9TD8tUEQhqRztyN0eazVyGw41nEzJLhM9xdvF/vK jdBzwZbJSY2lDaOn7uoB0tFV1Njo3MpT4AWJPBpKdab/0TQ6R6068014AgBVtQ7jm0VR cVptbpymyg3SPPyqI4SVV46DTV2ueK2cF5u7anNPHOWCFRSStqT9mMKloEoBRz3L9Rzv qE+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=keQ4L7UbBstjJ4Z8l3tC/GCwog+37U4yNm5EHWpkJyI=; b=3oXnGZ0i137szOeQgHrQtLtVRt37WLf2oCIk1hydT7lMJP4Icn0oBynvMt407Axtk4 2hBCpAUoO9MWQgoGZ5oP315BxDO6KsmRIci9G9FKvXnVDXMg1lMVwC2ZGSSSvgGs6D3f uUhi5yCSIZxVkXQdAILs+2kbBt5jRHIoJQ19tnGzScxzOoL2gpbxBsHfK9yxdl2o/mxk C6naaDvrWBTQYIKaUaza2bJIAFNASr0pkXvQk3ScmvBGId3seW2mE5MPutArVaxDy6C1 fflz3iSvDwskDzpqHS667wQNiuFDzldaM/d70WYz4lLyzWcuefxf0zKOSCaF15YbM9yi 1COQ== X-Gm-Message-State: AOAM533IQcBZSn3/1bZ7P+QmRTnkBlCfKZzzDWzo/cfEogeUn4c1Yksp pSsQeSSYLtmTb5CNxj/gcrI= X-Google-Smtp-Source: ABdhPJyCwNnxkvBhwxel+dTah4K5okKROtOb+iOTIiXy+V8phQN1otM3q5nebqF5dgc2s0RLsfuFFg== X-Received: by 2002:ac8:5986:0:b0:2de:97e9:a517 with SMTP id e6-20020ac85986000000b002de97e9a517mr11100340qte.599.1646689377836; Mon, 07 Mar 2022 13:42:57 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id x21-20020a05622a001500b002e064e63fc2sm3271935qtw.70.2022.03.07.13.42.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Mar 2022 13:42:56 -0800 (PST) Date: Mon, 7 Mar 2022 16:42:54 -0500 From: Mark Johnston To: Ronald Klop Cc: bob prohaska , Mark Millard , freebsd-arm@freebsd.org, freebsd-current Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) Message-ID: References: <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay> <1302689164.173.1646686466515@mailrelay> 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: <1302689164.173.1646686466515@mailrelay> X-Rspamd-Queue-Id: 4KCBlQ3Ssfz4T8b X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=YELCZYJV; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82d:from]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[www.zefox.net,yahoo.com,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Mar 07, 2022 at 09:54:26PM +0100, Ronald Klop wrote: > > Van: Mark Johnston > Datum: maandag, 7 maart 2022 16:13 > Aan: Ronald Klop > CC: bob prohaska , Mark Millard , freebsd-arm@freebsd.org, freebsd-current > > I haven't been able to reproduce any crashes running poudriere in an > > arm64 AWS instance, though. Could you please try the patch below and > > confirm whether it fixes your panics? I verified that the apparent > > problem described above is gone with the patch. > > > > diff --git a/sys/kern/kern_rmlock.c b/sys/kern/kern_rmlock.c > > index 0cdcfb8fec62..e51c25136ae0 100644 > > --- a/sys/kern/kern_rmlock.c > > +++ b/sys/kern/kern_rmlock.c > > @@ -437,6 +437,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) > > { > > struct thread *td = curthread; > > struct pcpu *pc; > > + int cpuid; > > > > if (SCHEDULER_STOPPED()) > > return (1); > > @@ -452,6 +453,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) > > atomic_interrupt_fence(); > > > > pc = get_pcpu(); > > + cpuid = pc->pc_cpuid; > > rm_tracker_add(pc, tracker); > > sched_pin(); > > > > @@ -463,7 +465,7 @@ _rm_rlock(struct rmlock *rm, struct rm_priotracker *tracker, int trylock) > > * conditional jump. > > */ > > if (__predict_true(0 == (td->td_owepreempt | > > - CPU_ISSET(pc->pc_cpuid, &rm->rm_writecpus)))) > > + CPU_ISSET(cpuid, &rm->rm_writecpus)))) > > return (1); > > > > /* We do not have a read token and need to acquire one. */ > > > > > > > > Hi, > > This patch paniced again: > x0: ffffa00005a31500 > x1: ffffa00005a0e000 > x2: 2 > x3: ffffa00076c4e9a0 > x4: 0 > x5: e672743c8f9e5 > x6: dc89f70500ab1 > x7: 14 > x8: ffffa00005a31518 > x9: 1 > x10: ffffa00005a0e000 > x11: 0 > x12: 0 > x13: a > x14: 1013e6b85a8ecbe4 > x15: 1dce740d11a5 > x16: ffff3ea86e2434bf > x17: fffffffffffffff2 > x18: ffff0000fe661800 (g_ctx + fcf9fa54) > x19: ffffa00076c4e9a0 > x20: ffff0000fec39000 (g_ctx + fd577254) > x21: 2 > x22: ffff0000419b6090 (g_ctx + 402f42e4) > x23: ffff000000c0b137 (lockstat_enabled + 0) > x24: 100 > x25: ffff000000c0b000 (version + a0) > x26: ffff000000c0b000 (version + a0) > x27: ffff000000c0b000 (version + a0) > x28: 0 > x29: ffff0000fe661800 (g_ctx + fcf9fa54) > sp: ffff0000fe661800 > lr: ffff00000154ea50 (zio_dva_throttle + 154) > elr: ffff00000154ea80 (zio_dva_throttle + 184) > spsr: 60000045 > far: 2b753286b0b8 > panic: Unknown kernel exception 0 esr_el1 2000000 > cpuid = 1 > time = 1646685857 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x174 > panic() at panic+0x44 > do_el1h_sync() at do_el1h_sync+0x184 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x2000000 > zio_dva_throttle() at zio_dva_throttle+0x184 > zio_execute() at zio_execute+0x58 > KDB: enter: panic > [ thread pid 0 tid 100129 ] > Stopped at kdb_enter+0x44: undefined f901c11f > db> ZFS doesn't make use of rm locks as far as I can see, so this is a little weird. I reverted the original rmlock commit in main, so it may be worth verifying that the problem really is gone before digging deeper. In other words, I'm a bit suspicious that this is a different bug. From nobody Tue Mar 8 12:26:05 2022 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 27C6F1A0E302; Tue, 8 Mar 2022 12:26:14 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4KCZLX1LlVz3R6t; Tue, 8 Mar 2022 12:26:11 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtpclient.apple (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id B05B04E6E9; Tue, 8 Mar 2022 12:26:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1646742370; bh=QlmT9QpM8WqrTLMpNA3WqsHqQTGYbmLrfGhj6giEddI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=S69YN5Qr/GurddKIFUXN3AyhqA08qFEDoAhibVnsTlyrvTikcm2FL0lS8xwSRJ05W Kq9rpVAhkNJi4jybZIA0z18zP9T2N3Bg4Jfhr1v8YcUdT9z1WzVNcBt2JvsNdYB/1v OD4iMtdscr4E4UfMB7YuoqWQYG9/9DcuLOS4zwW4zorUQS8ZkhcMZfyPbvlUY/SWGJ JDzhvkIHR5JDB0DIujgrwicZdW5rxolwORGq3j8TZ0LFrIXECkxNGLHEUfL04GIOfA 8wf/fvnhEZeHThURC9AptRmzQFup9LWoNEJYuJ3l5IrkOdkWirS3s+SBpxkTjUojwW kyqn9Xu7qZbdFZBHTMHTFi273qedG3eYneN4NHQeyRRXB3i/XLplTjZaooVB61/3vt /RyPofZt7GWUGk30YVd2XjVJ55F+WcTZc5fMg9de8v5M7ZnTZKhBd+gA/H66eR95qk xCpD8GOm7yfd3Mz734oRIEvzSNPx+abAJ4rgvsYGGBkWWvXvv3Cr/FjKw71pV0x+cz 514JNI+8TL9rwn/F/kbCpU4qU18HWvt53mkYgrCCGKT6Ar3sIdG9BSN7Sk6AsFQmV0 z57I3Khh/mmQcl8fqHfGdrDbK7rS6JZZFBHqJlbz6kLzRjX9kKq7BtmG8qLNLt0nkq tq74XaluCbqW7stcxtWtDnHc= From: Andrew Turner Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_27C8038E-6248-4772-9061-7457E0DFDA9B" 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 15.0 \(3693.60.0.1.1\)) Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) Date: Tue, 8 Mar 2022 12:26:05 +0000 In-Reply-To: Cc: Mark Millard , FreeBSD-STABLE Mailing List , Ronald Klop , bob prohaska , Free BSD , freebsd-current To: Mark Johnston References: <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay> <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz> X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Rspamd-Queue-Id: 4KCZLX1LlVz3R6t X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fubar.geek.nz header.s=mail header.b=S69YN5Qr; dmarc=pass (policy=none) header.from=fubar.geek.nz; spf=pass (mx1.freebsd.org: domain of andrew@fubar.geek.nz designates 139.59.165.16 as permitted sender) smtp.mailfrom=andrew@fubar.geek.nz X-Spamd-Result: default: False [-3.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=mail]; FREEFALL_USER(0.00)[andrew]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-0.999]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[fubar.geek.nz:+]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current,freebsd-stable]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US]; FREEMAIL_CC(0.00)[yahoo.com,freebsd.org,klop.ws,www.zefox.net]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_27C8038E-6248-4772-9061-7457E0DFDA9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Mar 2022, at 19:04, Mark Johnston wrote: >=20 > On Mon, Mar 07, 2022 at 10:03:51AM -0800, Mark Millard wrote: >>=20 >>=20 >> On 2022-Mar-7, at 08:45, Mark Johnston wrote: >>=20 >>> On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote: >>>>=20 >>>>> On 7 Mar 2022, at 15:13, Mark Johnston wrote: >>>>> ... >>>>> A (the?) problem is that the compiler is treating "pc" as an alias >>>>> for x18, but the rmlock code assumes that the pcpu pointer is = loaded >>>>> once, as it dereferences "pc" outside of the critical section. On >>>>> arm64, if a context switch occurs between the store at = _rm_rlock+144 and >>>>> the load at +152, and the thread is migrated to another CPU, then = we'll >>>>> end up using the wrong CPU ID in the rm->rm_writecpus test. >>>>>=20 >>>>> I suspect the problem is unique to arm64 as its get_pcpu() >>>>> implementation is different from the others in that it doesn't use >>>>> volatile-qualified inline assembly. This has been the case since >>>>> = https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbddf85ad04fc8e= 99e73762 = >>>>> . >>>>>=20 >>>>> I haven't been able to reproduce any crashes running poudriere in = an >>>>> arm64 AWS instance, though. Could you please try the patch below = and >>>>> confirm whether it fixes your panics? I verified that the = apparent >>>>> problem described above is gone with the patch. >>>>=20 >>>> Alternatively (or additionally) we could do something like the = following. There are only a few MI users of get_pcpu with the main place = being in rm locks. >>>>=20 >>>> diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h >>>> index 09f6361c651c..59b890e5c2ea 100644 >>>> --- a/sys/arm64/include/pcpu.h >>>> +++ b/sys/arm64/include/pcpu.h >>>> @@ -58,7 +58,14 @@ struct pcpu; >>>>=20 >>>> register struct pcpu *pcpup __asm ("x18"); >>>>=20 >>>> -#define get_pcpu() pcpup >>>> +static inline struct pcpu * >>>> +get_pcpu(void) >>>> +{ >>>> + struct pcpu *pcpu; >>>> + >>>> + __asm __volatile("mov %0, x18" : "=3D&r"(pcpu)); >>>> + return (pcpu); >>>> +} >>>>=20 >>>> static inline struct thread * >>>> get_curthread(void) >>>=20 >>> Indeed, I think this is probably the best solution. I=E2=80=99ve pushed the above to git in ed3066342660 & will MFC in a few = days. >=20 > Thinking a bit more, even with that patch, code like this may not = behave > the same on arm64 as on other platforms: >=20 > critical_enter(); > ptr =3D &PCPU_GET(foo); > critical_exit(); > bar =3D *ptr; >=20 > since as far as I can see the compiler may translate it to >=20 > critical_enter(); > critical_exit(); > bar =3D PCPU_GET(foo); If we think this will be a problem we could change the PCPU_PTR macro to = use get_pcpu again, however I only see two places it=E2=80=99s used in = the MI code in subr_witness.c and kern_clock.c. Neither of these appear = to be problematic from a quick look as there are no critical sections, = although I=E2=80=99m not familiar enough with the code to know for = certain. Andrew= --Apple-Mail=_27C8038E-6248-4772-9061-7457E0DFDA9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 7 Mar 2022, at 19:04, Mark Johnston <markj@freebsd.org> = wrote:

On Mon, Mar 07, 2022 at 10:03:51AM -0800, Mark Millard = wrote:


On 2022-Mar-7, at 08:45, Mark Johnston <markj@FreeBSD.org> = wrote:

On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner = wrote:

On 7 Mar 2022, at 15:13, = Mark Johnston <markj@freebsd.org> wrote:
...
A (the?) problem is that the compiler is treating "pc" as an = alias
for x18, but the rmlock code assumes that the pcpu = pointer is loaded
once, as it dereferences "pc" outside of = the critical section.  On
arm64, if a context switch = occurs between the store at _rm_rlock+144 and
the load at = +152, and the thread is migrated to another CPU, then we'll
end up using the wrong CPU ID in the rm->rm_writecpus = test.

I suspect the problem is unique to = arm64 as its get_pcpu()
implementation is different from = the others in that it doesn't use
volatile-qualified = inline assembly.  This has been the case since
https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbdd= f85ad04fc8e99e73762 <https://cgit.freebsd.org/src/commit/?id=3D63c858a04d56529eddbdd= f85ad04fc8e99e73762>
.

I= haven't been able to reproduce any crashes running poudriere in an
arm64 AWS instance, though.  Could you please try the = patch below and
confirm whether it fixes your panics? =  I verified that the apparent
problem described above = is gone with the patch.

Alternatively (or additionally) we could do something like = the following. There are only a few MI users of get_pcpu with the main = place being in rm locks.

diff --git = a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
index = 09f6361c651c..59b890e5c2ea 100644
--- = a/sys/arm64/include/pcpu.h
+++ = b/sys/arm64/include/pcpu.h
@@ -58,7 +58,14 @@ struct = pcpu;

register struct pcpu *pcpup __asm = ("x18");

-#define =        get_pcpu() =      pcpup
+static inline struct = pcpu *
+get_pcpu(void)
+{
+ =       struct pcpu *pcpu;
+
+       __asm __volatile("mov =   %0, x18" : "=3D&r"(pcpu));
+ =       return (pcpu);
+}

static inline struct thread *
get_curthread(void)

Indeed, I think this is probably the best solution.

I=E2=80=99ve pushed the above to git = in ed3066342660 & will MFC in a few days.


Thinking a bit more, even with = that patch, code like this may not behave
the same on arm64 as on other platforms:

critical_enter();
ptr =3D = &PCPU_GET(foo);
critical_exit();
bar =3D *ptr;

since as far as I can see the compiler may translate it = to

critical_enter();
critical_exit();
bar =3D PCPU_GET(foo);

If we think this will be a problem we could change = the PCPU_PTR macro to use get_pcpu again, however I only see two = places it=E2=80=99s used in the MI code in subr_witness.c = and kern_clock.c. Neither of these appear to be problematic from a = quick look as there are no critical sections, although I=E2=80=99m not = familiar enough with the code to know for certain.

Andrew
= --Apple-Mail=_27C8038E-6248-4772-9061-7457E0DFDA9B-- From nobody Tue Mar 8 15:42:04 2022 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 CBF201A1436A; Tue, 8 Mar 2022 15:42:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KCfhR2ymrz4c3D; Tue, 8 Mar 2022 15:41:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 228Fg6vo037302 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 8 Mar 2022 07:42:06 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 228Fg5Cc037301; Tue, 8 Mar 2022 07:42:05 -0800 (PST) (envelope-from fbsd) Date: Tue, 8 Mar 2022 07:42:04 -0800 From: bob prohaska To: Mark Johnston Cc: Andrew Turner , Ronald Klop , Mark Millard , freebsd-arm@freebsd.org, freebsd-current , bob prohaska Subject: Re: panic: data abort in critical section or under mutex (was: Re: panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb 28)) Message-ID: <20220308154204.GA37265@www.zefox.net> References: <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay> <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KCfhR2ymrz4c3D X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [-0.92 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.944]; NEURAL_HAM_LONG(-0.88)[-0.878]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_SEVEN(0.00)[7]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; FREEMAIL_CC(0.00)[fubar.geek.nz,klop.ws,yahoo.com,freebsd.org,www.zefox.net]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, Mar 07, 2022 at 11:45:02AM -0500, Mark Johnston wrote: > On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote: > > > > > On 7 Mar 2022, at 15:13, Mark Johnston wrote: > > > ... > > > A (the?) problem is that the compiler is treating "pc" as an alias > > > for x18, but the rmlock code assumes that the pcpu pointer is loaded > > > once, as it dereferences "pc" outside of the critical section. On > > > arm64, if a context switch occurs between the store at _rm_rlock+144 and > > > the load at +152, and the thread is migrated to another CPU, then we'll > > > end up using the wrong CPU ID in the rm->rm_writecpus test. > > > > > > I suspect the problem is unique to arm64 as its get_pcpu() > > > implementation is different from the others in that it doesn't use > > > volatile-qualified inline assembly. This has been the case since > > > https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762 > > > . > > > > > > I haven't been able to reproduce any crashes running poudriere in an > > > arm64 AWS instance, though. Could you please try the patch below and > > > confirm whether it fixes your panics? I verified that the apparent > > > problem described above is gone with the patch. > > > > Alternatively (or additionally) we could do something like the following. There are only a few MI users of get_pcpu with the main place being in rm locks. > > > > diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h > > index 09f6361c651c..59b890e5c2ea 100644 > > --- a/sys/arm64/include/pcpu.h > > +++ b/sys/arm64/include/pcpu.h > > @@ -58,7 +58,14 @@ struct pcpu; > > > > register struct pcpu *pcpup __asm ("x18"); > > > > -#define get_pcpu() pcpup > > +static inline struct pcpu * > > +get_pcpu(void) > > +{ > > + struct pcpu *pcpu; > > + > > + __asm __volatile("mov %0, x18" : "=&r"(pcpu)); > > + return (pcpu); > > +} > > > > static inline struct thread * > > get_curthread(void) > > Indeed, I think this is probably the best solution. Just for fun I tried the patch on a Pi3 running -current, updated a day or two prior. The patch applied, compiled and seemed to run acceptably, but when I left a -j2 -DWITH_META_MODE buildworld running it crashed overnight, reporting login: panic: rm_rlock: recursed on non-recursive rmlock sysctl lock @ /usr/src/sys/kern/kern_sysctl.c:193 cpuid = 0 time = 1646720264 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 _rm_rlock_debug() at _rm_rlock_debug+0x214 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140 sysctl_root() at sysctl_root+0x1ac userland_sysctl() at userland_sysctl+0x140 sys___sysctl() at sys___sysctl+0x68 do_el0_sync() at do_el0_sync+0x520 handle_el0_sync() at handle_el0_sync+0x40 --- exception, esr 0x56000000 KDB: enter: panic [ thread pid 869 tid 100091 ] Stopped at kdb_enter+0x44: undefined f902011f I tried typing bt at the debugger prompt but got no more output. I've put the buildworld log file at http://www.zefox.net/~fbsd/rpi3/crashes/20220307/ Hope this is of some use.... bob prohaska From nobody Tue Mar 8 21:00:29 2022 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 E71F81A01C11; Tue, 8 Mar 2022 21:00:47 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KCnmH2KDnz3nqT; Tue, 8 Mar 2022 21:00:47 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-qv1-xf2f.google.com with SMTP id eq14so453830qvb.3; Tue, 08 Mar 2022 13:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=vHrVESQpZYjZq79y8iE93xFejNfeYSxoh8AhQAukmkg=; b=CUn71zvZeWPajTqHGFMoFBHvwXMs2dwCVVu7csz8Uv0fgNTDq3Mzi4tXyNKUk2LNKy 1HIjDpPw2TDa5Sz9Hcg+60J5oXshMe7f0imltF6e0RuYcKgcTx6iHBvKR3QRTxMNeD6e oTCDcqntLCB3eClTcxmDmYhOqO2Cnc9hc2o8CO5F+Q29dOcaAJhCd2dAZquMdb2Q/0hz kmEhfVJ7v4wSQNnydYJgr7c/qPjJPuQawDq/5H3krvo1Q5xaY4pqkhnrxVYRWQAUZLlv l1zbTCj/P/xM36oon1dbx5aYlEc2UjwJp2QIUgBamC0X/uh7hkHVZYWLC7TnBSkzp2+r K5Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vHrVESQpZYjZq79y8iE93xFejNfeYSxoh8AhQAukmkg=; b=B3JtwHoMubwIDMeX332mXu394Q7Z6EXjvZ/AFWV9uotdNSZ2Cm7XhZrTmsmwhfWnc1 0QFt+XFep3Vjxa9gbuy+N9eMDRGNr8MOmq+pvpMXiUQTBmf4VqQqcl8P6BeXWfeaZ1Gr qZCn2CuGPOKPSE1gxJqHxk7hVCEi1Ucr7YSOXr329/CUMsUukdQ7RR7CSpmosuOIDmMp /py7Cw4TqAhjuCFpfhXksrcg4tj84elA6TqNLBP5frUHf03ChO0SdvDYhjo6zauex69J vXneQyfpL/jGp3CTpQH1Zm14i6TTNiiQGqjUiZ7DeyktV9SNCNYED5I7mYNNQv4RqWP5 QnzQ== X-Gm-Message-State: AOAM531yQ6IeKs3E0RNQjO+lz5hCz+d3FXI9Z1/NJd012kvKtJCDYu1r 8qdfep1cI3XJz+utxqzq+1cxrSRIDTEBC33BeRuoqx0LPa4= X-Google-Smtp-Source: ABdhPJxfMXt3ApE+nJMvDARBbNTmATVsr8zVHmqtGTUv/WbPILtKgy29E09KFY2uaaCb+LGrPP/+aEjGnyn+K9xRQ+E= X-Received: by 2002:a05:6214:4103:b0:42d:7ad0:44ff with SMTP id kc3-20020a056214410300b0042d7ad044ffmr13850533qvb.42.1646773240780; Tue, 08 Mar 2022 13:00:40 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Sami Halabi Date: Tue, 8 Mar 2022 23:00:29 +0200 Message-ID: Subject: running cron jobs setpriority permission denied To: freebsd-stable@freebsd.org, FreeBSD Current , freebsd-jail@freebsd.org, freebsd-net@freebsd.org, Oleg Ginzburg Content-Type: multipart/alternative; boundary="0000000000000add3605d9bb4698" X-Rspamd-Queue-Id: 4KCnmH2KDnz3nqT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=CUn71zvZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sodynet1@gmail.com designates 2607:f8b0:4864:20::f2f as permitted sender) smtp.mailfrom=sodynet1@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2f:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-stable,freebsd-current,freebsd-jail,freebsd-net]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000000add3605d9bb4698 Content-Type: text/plain; charset="UTF-8" Hi, I have a jail ran by cbsd which has a cronjob like this: * * * * * root /usr/local/directadmin/dataskq I see every minute this error logged in /var/log/messages: cron[71002]: setpriority 'root' (daemon): Permission denied I see in ps xau that it runs but at nobody user even when loggin to the jail I have: cron[68825]: setpriority 'root' (daemon): Permission denied login[68900]: setpriority 'root' (root): Permission denied jexec[69404]: setpriority 'root' (root): Permission denied # uname -a FreeBSD j5.sody.com 12.3-RELEASE-p1 FreeBSD 12.3-RELEASE-p1 GENERIC amd64 what am I missing? Sami -- Sami Halabi Information Systems Engineer NMS Projects Expert, FreeBSD SysAdmin Expert Asterisk Expert --0000000000000add3605d9bb4698 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have a jail ran by cbsd which has= a cronjob=C2=A0like this:
* * * * * root /usr/local/directadmin/= dataskq

I see every minute this error logged i= n /var/log/messages:
cron[71002]: setpriority 'root' (dae= mon): Permission denied

I see in ps xau that i= t runs but at nobody user

even when loggin=C2=A0to= the jail I have:
cron[68825]: setpriority 'root' (daemon= ): Permission denied
login[68900]: setpriority 'root'= (root): Permission denied
jexec[69404]: setpriority 'roo= t' (root): Permission denied

# uname -aFreeBSD j5.sody.com 12.3-RELEASE-p1 Fre= eBSD 12.3-RELEASE-p1 GENERIC =C2=A0amd64

what = am I missing?

Sami

--
Sami Halabi
Informati= on Systems Engineer
NMS Projects Expert,=C2=A0FreeBSD SysAdmin Expert
Asterisk Expert
--0000000000000add3605d9bb4698-- From nobody Wed Mar 9 09:03:56 2022 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 D7FF819FA5D7; Wed, 9 Mar 2022 09:04:05 +0000 (UTC) (envelope-from SRS0=sC6H=TU=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 4KD5pr3pdTz4gWg; Wed, 9 Mar 2022 09:04:04 +0000 (UTC) (envelope-from SRS0=sC6H=TU=klop.ws=ronald-lists@realworks.nl) Date: Wed, 9 Mar 2022 10:03:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1646816636; 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=yTkVxsRMh9D2eu1hkij8TjsNIR7AGZ1Xg9QlN9It/t4=; b=DB0RM0mNR/pro7jjn0q4HSFgZrTYNvqo027gy1vxvfMvXTwzyWTxn9nqaEtDSoXdF3KanW kdd/DBU2WCyV7YTcR9+C9XtagKb2EWLK/AXdDDWwk9ldrDg38+WWx7pAPhOgyZIj9QTj+R EGQ+N9seSgex1kzpkAJyJybbSKVdBnS3PVDQwE13cGoHsTLE3xwQ07BC6/QESnFWecPO/n gtJNQfHSCXow0XoniNMgeHv2hXTdUhmXWmtmSSeL8xZ/P5Awzfax+GQtvRITRcVdiBRCUn 1oSqbbwjizo731jFzlkah81tU+DjokOwiPrOrZekeF00HsS+gYGBUT6QcaOYkw== From: Ronald Klop To: Sami Halabi Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, freebsd-jail@freebsd.org, FreeBSD Current , Oleg Ginzburg Message-ID: <465361599.31.1646816636649@mailrelay> In-Reply-To: References: Subject: Re: running cron jobs setpriority permission denied 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_30_1988691437.1646816636583" X-Mailer: Realworks (599.216.fd11bde) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4KD5pr3pdTz4gWg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=DB0RM0mN; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=sC6H=TU=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=sC6H=TU=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-1.78 / 15.00]; ARC_NA(0.00)[]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=sC6H=TU=klop.ws=ronald-lists@realworks.nl]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.42)[0.424]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-jail,freebsd-net,freebsd-stable]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=sC6H=TU=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_30_1988691437.1646816636583 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It sounds similar to this issue. https://github.com/cbsd/cbsd/issues/437 "default nice 1 prevents cron in jail #437" Does that help? Regards, Ronald. Van: Sami Halabi Datum: dinsdag, 8 maart 2022 22:00 Aan: freebsd-stable@freebsd.org, FreeBSD Current , freebsd-jail@freebsd.org, freebsd-net@freebsd.org, Oleg Ginzburg Onderwerp: running cron jobs setpriority permission denied > > Hi, > > I have a jail ran by cbsd which has a cronjob like this: > * * * * * root /usr/local/directadmin/dataskq > > I see every minute this error logged in /var/log/messages: > cron[71002]: setpriority 'root' (daemon): Permission denied > > I see in ps xau that it runs but at nobody user > > even when loggin to the jail I have: > cron[68825]: setpriority 'root' (daemon): Permission denied > login[68900]: setpriority 'root' (root): Permission denied > jexec[69404]: setpriority 'root' (root): Permission denied > > # uname -a > FreeBSD j5.sody.com 12.3-RELEASE-p1 FreeBSD 12.3-RELEASE-p1 GENERIC amd64 > > what am I missing? > > Sami > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert ------=_Part_30_1988691437.1646816636583 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit It sounds similar to this issue.

https://github.com/cbsd/cbsd/issues/437 "default nice 1 prevents cron in jail #437"

Does that help?

Regards,
Ronald.

 

Van: Sami Halabi <sodynet1@gmail.com>
Datum: dinsdag, 8 maart 2022 22:00
Aan: freebsd-stable@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, freebsd-jail@freebsd.org, freebsd-net@freebsd.org, Oleg Ginzburg <olevole@olevole.ru>
Onderwerp: running cron jobs setpriority permission denied

Hi,
 
I have a jail ran by cbsd which has a cronjob like this:
* * * * * root /usr/local/directadmin/dataskq
 
I see every minute this error logged in /var/log/messages:
cron[71002]: setpriority 'root' (daemon): Permission denied
 
I see in ps xau that it runs but at nobody user
 
even when loggin to the jail I have:
cron[68825]: setpriority 'root' (daemon): Permission denied
login[68900]: setpriority 'root' (root): Permission denied
jexec[69404]: setpriority 'root' (root): Permission denied
 
# uname -a
FreeBSD j5.sody.com 12.3-RELEASE-p1 FreeBSD 12.3-RELEASE-p1 GENERIC  amd64
 
what am I missing?
 
Sami
 
--
Sami Halabi
Information Systems Engineer
NMS Projects Expert, FreeBSD SysAdmin Expert
Asterisk Expert
------=_Part_30_1988691437.1646816636583-- From nobody Wed Mar 9 11:24:15 2022 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 434321A150E8; Wed, 9 Mar 2022 11:24:29 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KD8wr4FVgz3Fwl; Wed, 9 Mar 2022 11:24:28 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-qv1-xf2d.google.com with SMTP id e22so1674929qvf.9; Wed, 09 Mar 2022 03:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hOErKVoem/0p/g6CJngpwAoj0n1R8dEb84EvsQQKKUc=; b=J/xE09S5XGd7oQgSB3C1B2qwL4c22PGEGRiMPlizBoshKpcr/o8tzSjBORTfQ9H5pU DST4U/A1cM9k+p3pxJQWiiNPxN9aj+VnlmVGjC6FcW1hpqiWdrxZrapgWs6MzVWUzMTy ePOQ/hFc7RzK9yqJjkXGrpneYeNICKhBceTtcG6PBpH6fpfjjWh8jPct0zr/mWedYKAj ZDA6PdkgVQTu09Hx+WvKEIGSbAiRuD4Hz2zUuew8ZNi2hw0A6Y6V7V70wfqATTF9AZOM fhUxVID6HIjqlWVxUN1hbAASGDR0xzfVVZ98Im86MQqvOg80mYPNpybkVNQRlInXLmWR MvdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hOErKVoem/0p/g6CJngpwAoj0n1R8dEb84EvsQQKKUc=; b=BnI4+MO33QddXhOORzpJJ1BVs2ZVSe+H25SsIJG6QKekKIU26Dwe4jUT1tW1sXasD2 /ENmj3ihFfY99+NaACxXlr44LUNeLXg1QsHS+ewVv0YLJ8AWdvz3rTgzLXkr2tLlmyLR dkTC6hsAHMVDMTAEtgdH65g+58ByF9G0lBWnb2qa4+qEchF7PMvQy8xkqx3hqTf7Gl1t qvi+NnLHx1rxaf/UmqTN/xB4jXtmn0VIckw+rokIdAz7EF4lyOhMi1lYnbp4v2DhC+PR KJ7T1mni7Ey9vHfYE+Hi1RDO1p0zNMkliBjYIFzJhxuHGhOEQvjyAsLZgqewaY4ZnEW5 r1mg== X-Gm-Message-State: AOAM531emqfCRi9U8sskY5+Am5xLS0zh0S67uOkYQgfek+kkbLPRCdmg 4UsdlBSaQdMr1xEYPGMQouzw+PmPelqe849aveJVwCkz7OY= X-Google-Smtp-Source: ABdhPJyodp7KXZC9fixfZt+p522di5346EIZBUk988I8VMToku2LNVRUomV9ujV9BCyAinIItbGMnHqVvW5Z64vUopY= X-Received: by 2002:a05:6214:4103:b0:42d:7ad0:44ff with SMTP id kc3-20020a056214410300b0042d7ad044ffmr15785822qvb.42.1646825062333; Wed, 09 Mar 2022 03:24:22 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <465361599.31.1646816636649@mailrelay> In-Reply-To: <465361599.31.1646816636649@mailrelay> From: Sami Halabi Date: Wed, 9 Mar 2022 13:24:15 +0200 Message-ID: Subject: Re: running cron jobs setpriority permission denied To: Ronald Klop Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, freebsd-jail@freebsd.org, FreeBSD Current , Oleg Ginzburg Content-Type: multipart/alternative; boundary="000000000000d9004c05d9c7565a" X-Rspamd-Queue-Id: 4KD8wr4FVgz3Fwl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="J/xE09S5"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sodynet1@gmail.com designates 2607:f8b0:4864:20::f2d as permitted sender) smtp.mailfrom=sodynet1@gmail.com X-Spamd-Result: default: False [-3.29 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.29)[-0.294]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2d:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-net,freebsd-stable,freebsd-jail,freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000d9004c05d9c7565a Content-Type: text/plain; charset="UTF-8" Hi, Thank You!! indeed that helped! Sami On Wed, Mar 9, 2022 at 11:03 AM Ronald Klop wrote: > It sounds similar to this issue. > > https://github.com/cbsd/cbsd/issues/437 "default nice 1 prevents cron in > jail #437" > > Does that help? > > Regards, > Ronald. > > > > *Van:* Sami Halabi > *Datum:* dinsdag, 8 maart 2022 22:00 > *Aan:* freebsd-stable@freebsd.org, FreeBSD Current < > freebsd-current@freebsd.org>, freebsd-jail@freebsd.org, > freebsd-net@freebsd.org, Oleg Ginzburg > *Onderwerp:* running cron jobs setpriority permission denied > > Hi, > > I have a jail ran by cbsd which has a cronjob like this: > * * * * * root /usr/local/directadmin/dataskq > > I see every minute this error logged in /var/log/messages: > cron[71002]: setpriority 'root' (daemon): Permission denied > > I see in ps xau that it runs but at nobody user > > even when loggin to the jail I have: > cron[68825]: setpriority 'root' (daemon): Permission denied > login[68900]: setpriority 'root' (root): Permission denied > jexec[69404]: setpriority 'root' (root): Permission denied > > # uname -a > FreeBSD j5.sody.com 12.3-RELEASE-p1 FreeBSD 12.3-RELEASE-p1 GENERIC amd64 > > what am I missing? > > Sami > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert > > -- Sami Halabi Information Systems Engineer NMS Projects Expert, FreeBSD SysAdmin Expert Asterisk Expert --000000000000d9004c05d9c7565a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Thank You!! indeed that helped!

Sami

On Wed, Mar 9, 2022 at 11:03 AM Ronald Klop <ronald-lists@klop.ws> wrote:
=
It sounds similar to= this issue.

https= ://github.com/cbsd/cbsd/issues/437 "default nice 1 prevents cron i= n jail #437"

Does that help?

Regards,
Ronald.

=C2=A0

Van: Sami Halabi <sodynet1@gmail.com>
Datum: dinsdag, 8 maart 2022 22:00
Aan: freebsd-stable@freebsd.org, FreeBSD Current <freebsd-current@freeb= sd.org>, freebsd-jail@freebsd.org, freebsd-net@freebsd.org, Oleg Ginzburg <olevole@olevole.ru>=
Onderwerp: running cron jobs setpriority permission denied=

Hi,
=C2=A0
I have a jail ran by cbsd which has a cronjob=C2=A0like this:
* * * * * root /usr/local/directadmin/dataskq
=C2=A0
I see every minute this error logged in /var/log/messages:
cron[71002]: setpriority 'root' (daemon): Permission denied
=C2=A0
I see in ps xau that it runs but at nobody user
=C2=A0
even when loggin=C2=A0to the jail I have:
cron[68825]: setpriority 'root' (daemon): Permission denied
login[68900]: setpriority 'root' (root): Permission denied
jexec[69404]: setpriority 'root' (root): Permission denied
=C2=A0
# uname -a
FreeBSD j5.sody.com 12= .3-RELEASE-p1 FreeBSD 12.3-RELEASE-p1 GENERIC =C2=A0amd64
=C2=A0
what am I missing?
=C2=A0
Sami
=C2=A0
--
Sami Halabi
Information Systems Engineer
NMS Projects Expert,=C2=A0FreeBSD Sys= Admin Expert
Asterisk Expert


-- <= br>
Sami Halabi
Information Systems Engineer
NMS Projec= ts Expert,=C2=A0FreeBSD SysAdmin Expert
Asterisk Expert
--000000000000d9004c05d9c7565a-- From nobody Thu Mar 10 15:27:14 2022 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 0CF9A1A03804 for ; Thu, 10 Mar 2022 15:27:30 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KDtGn24h8z3jYX for ; Thu, 10 Mar 2022 15:27:25 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id BD5D18D4A15D for ; Thu, 10 Mar 2022 15:27:17 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 275D6E70814 for ; Thu, 10 Mar 2022 15:27:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 4gX2LoSnCWOz for ; Thu, 10 Mar 2022 15:27:16 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D24C6E707BB for ; Thu, 10 Mar 2022 15:27:15 +0000 (UTC) Date: Thu, 10 Mar 2022 15:27:14 +0000 (UTC) From: "Bjoern A. Zeeb" To: current@FreeBSD.org Subject: ktrace on NFSroot failing? Message-ID: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4KDtGn24h8z3jYX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-1.69 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.40)[-0.397]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_HAM_SHORT(-0.99)[-0.991]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MLMMJ_DEST(0.00)[current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I am having a weird issue with ktrace on an nfsroot machine: root:/tmp # ktrace sleep 1 root:/tmp # kdump -559038242 Events dropped. kdump: bogus length 0xdeadc0de Anyone seen something like this before? -- Bjoern A. Zeeb r15:7 From nobody Thu Mar 10 16:14:51 2022 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 856031A0C72C for ; Thu, 10 Mar 2022 16:14:54 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KDvKT2gxlz3q8F for ; Thu, 10 Mar 2022 16:14:53 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lj1-x229.google.com with SMTP id v28so8401986ljv.9 for ; Thu, 10 Mar 2022 08:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AV2TZ1ePcF77Yt4bx0uUgmfBH9xdTSmRBqc1VtUQQ6k=; b=O9Gzj1LzxVhAZH+qAlLFxPwgIGqeI8++g8LqVg3yf3BTMqv9CIjPTVSWl6NzLVghSk dgrUMXD8Y7lyy9hmaxTyWRk58OLn/XQv1Yb6dlQQCE6vHyIUOjnqbmRxgS03f1Bsf9dE P2ahqZBCFpjPd6gLyYW6/TjhAaBJY5Z1czfULBVlPn7Aa99h5MqcY6nSOKSXnzxln4ZG 28hHRykfFxWP+2zkG0KTISUDlMNNdzP+OjsFy6r1r+LzsEw6+oe7YLJ4LGrMHHikDEP6 GmesqGENg3VocKUs1f13zu5cdl6Qarusj0RO52mMjWSwzLpZmnSiQRjb9UD6GWpYum8Z wXig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AV2TZ1ePcF77Yt4bx0uUgmfBH9xdTSmRBqc1VtUQQ6k=; b=zgIAw9xFBcQUgrFhd73+P/tq8MTfTfhuETQUS0mvFf/UVYDbP2z6ihR0Pe3DXCajJz TmAEfxyrMzdbrTRiwyqgrgt3mjx3rm5sZT2KxxyAebUYTE5JFUR9xhl5/Cq8vmBP2SI6 VODKzDuhINQUyY1dIQBq8S4cVpM8x4jkAlOfFBgtr12bcKUdPqe9FCMDvBIadm0dwHNt IlbwAMZhd1rPH0CxirU5gDETUNlJGwXAjS28vbuc6WhA8sAQijZ3oWWDG3estRD14Zwk I2ctK3f3jseRIiiBSwbRm9ZyeNiNpKRJQF/mwBaegnMvjM5sb/p3XoPRow5WSz73Im4B DsXA== X-Gm-Message-State: AOAM5300mAszosGYhZr6P9I6XRK1SWHstcWt71cbIbbNmfmAQqFrHYiS 7dXt5xY9CaZS1M4TfBCpquYQtSJhxlD6iyBkBA/am33h X-Google-Smtp-Source: ABdhPJx/KJu1eiAyw5X1wdXQETwQqfP7o0FD8J0oUGUkk60LtVZRZMg2NdWzUPpfbVX0XC0CEBW3Goz/9mLYRlZNhHE= X-Received: by 2002:a2e:a909:0:b0:246:479b:2546 with SMTP id j9-20020a2ea909000000b00246479b2546mr3553194ljq.53.1646928891935; Thu, 10 Mar 2022 08:14:51 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:aa6:cb4f:0:b0:1a3:8d4b:4aec with HTTP; Thu, 10 Mar 2022 08:14:51 -0800 (PST) In-Reply-To: References: From: Mateusz Guzik Date: Thu, 10 Mar 2022 17:14:51 +0100 Message-ID: Subject: Re: ktrace on NFSroot failing? To: "Bjoern A. Zeeb" Cc: current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KDvKT2gxlz3q8F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=O9Gzj1Lz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::229 as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-2.96 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.962]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::229:from]; MLMMJ_DEST(0.00)[current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/10/22, Bjoern A. Zeeb wrote: > Hi, > > I am having a weird issue with ktrace on an nfsroot machine: > > root:/tmp # ktrace sleep 1 > root:/tmp # kdump > -559038242 Events dropped. > kdump: bogus length 0xdeadc0de > > Anyone seen something like this before? > I just did a quick check and it definitely fails on nfs mounts: # ktrace pwd /root/mjg # kdump -559038242 Events dropped. kdump: bogus length 0xdeadc0de I don't have time to look into it this week though. > -- > Bjoern A. Zeeb r15:7 > > -- Mateusz Guzik From nobody Fri Mar 11 02:21:18 2022 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 BA8F61A1BA0F; Fri, 11 Mar 2022 02:21:19 +0000 (UTC) (envelope-from jrm@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KF8nC4c0Wz4gLD; Fri, 11 Mar 2022 02:21:19 +0000 (UTC) (envelope-from jrm@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646965279; 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; bh=uJP7+WG22kNTkZZMa+ZoHfGOuI5Gy+T7XJ4OPziUd2Q=; b=aQAJERfb9wYfKbjEJidt/JdZTPL6SHO4M2NE+wrtqo/drgdj4bgRg7dRyuVeAHi6QqmAmR 6+EoHu6rSNJRYu1rx+TEs7wpdd9llN5jf2ZCoabtBixXVe1Vk+4jMPiFP62TTRg10qazhl kSQUUXpyCujE4Z0QQv3ZUsZyJdos4QTjkvDVFvWXmUOfNi0y6kkI3keJQDQxmXGbsdWykT yf+b138cJYjMmPPkksEYmDgSWypkaGEHlKRKWLxxP5ePudE/VcVbbQKkwKMIlNof2mHEEl 69Z7zbmGOt9I1rLelRQygCJzUqSjV/XTyC0pvt333N9fFXwcXGztux3hLJ4frg== Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-156-34-173-250.dhcp-dynamic.fibreop.ns.bellaliant.net [156.34.173.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jrm/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 11CBF26C04; Fri, 11 Mar 2022 02:21:19 +0000 (UTC) (envelope-from jrm@freebsd.org) From: Joseph Mingrone To: hackers@FreeBSD.org Cc: current@FreeBSD.org, stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Fourth Quarter 2021 Date: Thu, 10 Mar 2022 22:21:18 -0400 Message-ID: <86czitgrfl.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646965279; 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; bh=uJP7+WG22kNTkZZMa+ZoHfGOuI5Gy+T7XJ4OPziUd2Q=; b=b0/cK2n/RpWd5wZk1ZJFLfwLH0fzc6En1vgKoZiys4inzpAUXfr06Ono2muvK1r7rBI8Os OBVZTc0RStrJZNrtEm96iYbXK1i3O/0keS2TgHF/ZJ4i2I3MFXl9zE/agDsL6FkQIOao2k hl7a5gouO3RAVUwcHJFDMm0yA7XejXTIHE5yvaelAzKts6rT8Oi/6o0H1tX45CbsMOFWUn wGeWKKNjgfeABTINaWfTohI/zkHXk1+HTqp0LX91rq/nkCzrE2H0IZFWO/X92L9o9n+3zh 50ok5OKFG/+2IUU9HnShG4RDr9Khyul5XjqtDi+5NB5QeMiqcsl+4NZ8AfwwCw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646965279; a=rsa-sha256; cv=none; b=WqN8wneto/LPxwjYWUMvY97QqQ6EkJ1H7uOhdheEG9Rd3JVV8TTwn+cpfEQwHIK6swLsIS ZzMkAKJj9CgtmeNxXYxT8H57o/KcN/SZuc2OL4krhYecZdhnfXEcGLfPr5gL1xI1Ms+dlj DEAjOTPJB6JCC4fA5jAwXm5Ty56ySVJnPwsBNN8tgVve1aYprwJoHBokuiM4778uU+nYgx Xq6EoMfsAEypHevX1OK0dWGrlzia3Y4mNF0UnoQeq784kewZKdNsDsGnjwql6GuzM6hdOY Nu1fTZQ2RLBMu+Mp59E52SN8O83uAlUOhvYbcrI7vzKVVPGIKIuRYjOGIaknLg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 RnJlZUJTRCBRdWFydGVybHkgU3RhdHVzIFJlcG9ydCA0dGggUXVhcnRlciAyMDIxDQoNClRoaXMg cmVwb3J0IGNvdmVycyBGcmVlQlNEIHJlbGF0ZWQgcHJvamVjdHMgZm9yIHRoZSBwZXJpb2QgYmV0 d2VlbiBPY3RvYmVyIGFuZA0KRGVjZW1iZXIuIEl0IGlzIHRoZSBmb3VydGggb2YgZm91ciBwbGFu bmVkIHJlcG9ydHMgZm9yIDIwMjEsIGFuZCBjb250YWlucyAxOQ0KZW50cmllcy4gSGlnaGxpZ2h0 cyBpbmNsdWRlIGZhc3RlciBib290IHRpbWVzLCBtb3JlIExMREIgd29yaywgYSBiYXNlIE9wZW5T U0gNCnVwZGF0ZSwgYW5kIG1vcmUgd2lyZWxlc3MgZGV2ZWxvcG1lbnQuDQoNCllvdXJzLA0KUGF1 IEFtbWEsIERhbmllbCBFYmRydXAsIEpvaG4tTWFyayBHdXJuZXksIGFuZCBKb2UgTWluZ3JvbmUN Cg0K4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSBDQpUYWJsZSBvZiBDb250ZW50cw0KDQogIOKAoiBGcmVlQlNEIFRlYW0gUmVw b3J0cw0KICAgICAg4pahIEZyZWVCU0QgRm91bmRhdGlvbg0KICAgICAg4pahIFBvcnRzIENvbGxl Y3Rpb24NCiAgICAgIOKWoSBEb2N1bWVudGF0aW9uIEVuZ2luZWVyaW5nIFRlYW0NCiAgICAgIOKW oSBGcmVlQlNEIFdlYnNpdGUgUmV2YW1wIC0gV2ViQXBwcyB3b3JraW5nIGdyb3VwDQogIOKAoiBQ cm9qZWN0cw0KICAgICAg4pahIEVuYWJsZSBBU0xSIGJ5IGRlZmF1bHQgZm9yIDY0LWJpdCBleGVj dXRhYmxlcw0KICAgICAg4pahIEJvb3QgUGVyZm9ybWFuY2UgSW1wcm92ZW1lbnRzDQogICAgICDi lqEgTExEQiBEZWJ1Z2dlciBJbXByb3ZlbWVudHMNCiAgICAgIOKWoSBOWFAgTFMxMDI4QS8xMDI3 QSBTb0Mgc3VwcG9ydA0KICAgICAg4pahIHNjaGVkX2dldGNwdSgyKSwgbWVtYmFycmllcigyKSwg YW5kIHJzZXEoMikgc3lzY2FsbHMNCiAgICAgIOKWoSBCYXNlIFN5c3RlbSBPcGVuU1NIIFVwZGF0 ZQ0KICAgICAg4pahIFZEU08gb24gYW1kNjQNCiAg4oCiIEtlcm5lbA0KICAgICAg4pahIFRoZSBB VlggYnVnIG9uIGFtZDY0DQogICAgICDilqEgRU5BIEZyZWVCU0QgRHJpdmVyIFVwZGF0ZQ0KICAg ICAg4pahIEludGVsIFdpcmVsZXNzIGRyaXZlciBzdXBwb3J0DQogICAgICDilqEgS2VybmVsIENy eXB0byBjaGFuZ2VzIHRvIHN1cHBvcnQgV2lyZUd1YXJkDQogIOKAoiBQb3J0cw0KICAgICAg4pah IEtERSBvbiBGcmVlQlNEDQogICAgICDilqEgRnJlZUJTRCBPZmZpY2UgVGVhbQ0KICDigKIgVGhp cmQtUGFydHkgUHJvamVjdHMNCiAgICAgIOKWoSBoZWxsb1N5c3RlbQ0KICAgICAg4pahIENvbnRh aW5lcnMgJiBGcmVlQlNEOiBQb3QsIFBvdGx1Y2sgJiBQb3RtYW4NCg0K4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSBDQoNCkZy ZWVCU0QgVGVhbSBSZXBvcnRzDQoNCkVudHJpZXMgZnJvbSB0aGUgdmFyaW91cyBvZmZpY2lhbCBh bmQgc2VtaS1vZmZpY2lhbCB0ZWFtcywgYXMgZm91bmQgaW4gdGhlDQpBZG1pbmlzdHJhdGlvbiBQ YWdlLg0KDQpGcmVlQlNEIEZvdW5kYXRpb24NCg0KTGlua3M6DQpGcmVlQlNEIEZvdW5kYXRpb24g VVJMOiBodHRwczovL3d3dy5GcmVlQlNERm91bmRhdGlvbi5vcmcNClRlY2hub2xvZ3kgUm9hZG1h cCBVUkw6IGh0dHBzOi8vRnJlZUJTREZvdW5kYXRpb24ub3JnL2Jsb2cvdGVjaG5vbG9neS1yb2Fk bWFwLw0KRG9uYXRlIFVSTDogaHR0cHM6Ly93d3cuRnJlZUJTREZvdW5kYXRpb24ub3JnL2RvbmF0 ZS8NCkZvdW5kYXRpb24gUGFydG5lcnNoaXAgUHJvZ3JhbSBVUkw6IGh0dHBzOi8vd3d3LkZyZWVC U0RGb3VuZGF0aW9uLm9yZy8NCkZyZWVCU0QtZm91bmRhdGlvbi1wYXJ0bmVyc2hpcC1wcm9ncmFt DQpGcmVlQlNEIEpvdXJuYWwgVVJMOiBodHRwczovL3d3dy5GcmVlQlNERm91bmRhdGlvbi5vcmcv am91cm5hbC8NCkZvdW5kYXRpb24gTmV3cyBhbmQgRXZlbnRzIFVSTDogaHR0cHM6Ly93d3cuRnJl ZUJTREZvdW5kYXRpb24ub3JnLw0KbmV3cy1hbmQtZXZlbnRzLw0KDQpDb250YWN0OiBEZWIgR29v ZGtpbiA8ZGViQEZyZWVCU0RGb3VuZGF0aW9uLm9yZz4NCg0KVGhlIEZyZWVCU0QgRm91bmRhdGlv biBpcyBhIDUwMShjKSgzKSBub24tcHJvZml0IG9yZ2FuaXphdGlvbiBkZWRpY2F0ZWQgdG8NCnN1 cHBvcnRpbmcgYW5kIHByb21vdGluZyB0aGUgRnJlZUJTRCBQcm9qZWN0IGFuZCBjb21tdW5pdHkg d29ybGR3aWRlLiBEb25hdGlvbnMNCmZyb20gaW5kaXZpZHVhbHMgYW5kIGNvcnBvcmF0aW9ucyBh cmUgdXNlZCB0byBmdW5kIGFuZCBtYW5hZ2Ugc29mdHdhcmUNCmRldmVsb3BtZW50IHByb2plY3Rz LCBjb25mZXJlbmNlcywgYW5kIGRldmVsb3BlciBzdW1taXRzLiBXZSBhbHNvIHByb3ZpZGUNCnRy YXZlbCBncmFudHMgdG8gRnJlZUJTRCBjb250cmlidXRvcnMsIHB1cmNoYXNlIGFuZCBzdXBwb3J0 IGhhcmR3YXJlIHRvIGltcHJvdmUNCmFuZCBtYWludGFpbiBGcmVlQlNEIGluZnJhc3RydWN0dXJl LCBhbmQgcHJvdmlkZSByZXNvdXJjZXMgdG8gaW1wcm92ZSBzZWN1cml0eSwNCnF1YWxpdHkgYXNz dXJhbmNlLCBhbmQgcmVsZWFzZSBlbmdpbmVlcmluZyBlZmZvcnRzLiBXZSBwdWJsaXNoIG1hcmtl dGluZw0KbWF0ZXJpYWwgdG8gcHJvbW90ZSwgZWR1Y2F0ZSwgYW5kIGFkdm9jYXRlIGZvciB0aGUg RnJlZUJTRCBQcm9qZWN0LCBmYWNpbGl0YXRlDQpjb2xsYWJvcmF0aW9uIGJldHdlZW4gY29tbWVy Y2lhbCB2ZW5kb3JzIGFuZCBGcmVlQlNEIGRldmVsb3BlcnMsIGFuZCBmaW5hbGx5LA0KcmVwcmVz ZW50IHRoZSBGcmVlQlNEIFByb2plY3QgaW4gZXhlY3V0aW5nIGNvbnRyYWN0cywgbGljZW5zZSBh Z3JlZW1lbnRzLCBhbmQNCm90aGVyIGxlZ2FsIGFycmFuZ2VtZW50cyB0aGF0IHJlcXVpcmUgYSBy ZWNvZ25pemVkIGxlZ2FsIGVudGl0eS4NCg0KSGVyZSBhcmUgc29tZSBoaWdobGlnaHRzIG9mIHdo YXQgd2UgZGlkIHRvIGhlbHAgRnJlZUJTRCBsYXN0IHF1YXJ0ZXI6DQoNCkZ1bmRyYWlzaW5nIEVm Zm9ydHMNCg0KV2UgZGlkIGl0ISBXZSBtZXQgb3VyIDIwMjEgZnVuZHJhaXNpbmcgZ29hbCBieSBy YWlzaW5nICQxLDI4MSw0MzchISBPbiBiZWhhbGYNCm9mIHRoZSBGb3VuZGF0aW9uLCBJIHdhbnQg dG8gdGhhbmsgeW91IGZvciB5b3VyIGZpbmFuY2lhbCBzdXBwb3J0IGxhc3QgeWVhciwNCnRoYXQg d2lsbCBoZWxwIHVzIGNvbnRpbnVlIGFuZCBpbmNyZWFzZSBvdXIgc3VwcG9ydCBmb3IgRnJlZUJT RCBpbiAyMDIyLiBJbg0KYWRkaXRpb24sIGZvbGtzIGFyZSBhbHJlYWR5IHNlbmRpbmcgdXMgdGhl aXIgMjAyMiBjb250cmlidXRpb25zLCB3aGljaCBpcw0KaW5jcmVkaWJseSBoZWFydHdhcm1pbmch IFdl4oCZbGwgc3RhcnQgdXBkYXRpbmcgdGhlIGZ1bmRyYWlzaW5nIG1ldGVyIGZvciAyMDIyIGJ5 DQp0aGUgZW5kIG9mIEphbnVhcnkuDQoNCkluIHRoaXMgUXVhcnRlcmx5IFN0YXR1cyByZXBvcnQg eW914oCZbGwgcmVhZCBhYm91dCBtYW55IG9mIHRoZSBhcmVhcyB3ZSBmdW5kZWQNCmluIFE0IHRv IGltcHJvdmUgRnJlZUJTRCBhbmQgYWR2b2NhdGUgZm9yIHRoZSBQcm9qZWN0ICh0aGUgdHdvIG1h aW4gYXJlYXMgd2UNCnNwZW5kIG1vbmV5IG9uKS4gQ2hlY2sgb3V0IHJlcG9ydHMgb24gdGhlIGV4 dGVybmFsbHkgZnVuZGVkIHByb2plY3RzIGxpa2UgTExEQg0Kc3VwcG9ydCwgUmFpZC1aIEV4cGFu c2lvbiwgV2lyZUd1YXJkLCBhbmQgd2lmaSwgYXMgd2VsbCBhcywgaW50ZXJuYWxseQ0Kc3VwcG9y dGVkIHdvcmsgbGlrZSBpbXByb3ZlZCBzZWN1cml0eSwgdGllci0xIGFyY2hpdGVjdHVyZSBzdXBw b3J0LCBhbmQNCnByb3ZpZGluZyBvbmxpbmUgb3Bwb3J0dW5pdGllcyB0byBjb25uZWN0IGFuZCBl ZHVjYXRlIHRoZSBjb21tdW5pdHkuDQoNCklmIHlvdSB3YW50IHRvIGhlbHAgdXMgY29udGludWUg b3VyIGVmZm9ydHMsIHBsZWFzZSBjb25zaWRlciBtYWtpbmcgYSBkb25hdGlvbg0KdG93YXJkcyBv dXIgMjAyMiBmdW5kcmFpc2luZyBjYW1wYWlnbiEgaHR0cHM6Ly93d3cuRnJlZUJTREZvdW5kYXRp b24ub3JnL2RvbmF0ZS8uDQoNCldlIGFsc28gaGF2ZSBhIFBhcnRuZXJzaGlwIFByb2dyYW0gZm9y IGxhcmdlciBjb21tZXJjaWFsIGRvbm9ycy4gWW91IGNhbiByZWFkDQphYm91dCBpdCBhdCBodHRw czovL3d3dy5GcmVlQlNERm91bmRhdGlvbi5vcmcvDQpGcmVlQlNELWZvdW5kYXRpb24tcGFydG5l cnNoaXAtcHJvZ3JhbS8uDQoNCk9TIEltcHJvdmVtZW50cw0KDQpEdXJpbmcgdGhlIGZvdXJ0aCBx dWFydGVyLCBGb3VuZGF0aW9uIHN0YWZmIGFuZCBncmFudCByZWNpcGllbnRzIGNvbW1pdHRlZCA0 NzINCnNyYyB0cmVlIGNoYW5nZXMsIDk4IHBvcnRzIHRyZWUgY2hhbmdlcywgYW5kIDExIGRvYyB0 cmVlIGNoYW5nZXMuIFRoaXMNCnJlcHJlc2VudHMgNDElLCA0MSUsIGFuZCAxMyUgb2Ygc3JjLCBw b3J0cywgYW5kIGRvYyBjb21taXRzIGlkZW50aWZ5aW5nIGENCnNwb25zb3IuDQoNCllvdSBjYW4g cmVhZCBhYm91dCBGb3VuZGF0aW9uLXNwb25zb3JlZCBwcm9qZWN0cyBpbiBpbmRpdmlkdWFsIHF1 YXJ0ZXJseSByZXBvcnQNCmVudHJpZXM6DQoNCiAg4oCiIFRoZSBBVlggYnVnIG9uIGFtZDY0DQoN CiAg4oCiIENyeXB0byBjaGFuZ2VzIGZvciBXaXJlR3VyYXJkDQoNCiAg4oCiIEludGVsIFdpcmVs ZXNzIGRyaXZlciBzdXBwb3J0DQoNCiAg4oCiIExMREIgRGVidWdnZXIgSW1wcm92ZW1lbnRzDQoN CiAg4oCiIEJhc2UgU3lzdGVtIE9wZW5TU0ggVXBkYXRlDQoNCiAg4oCiIHNjaGVkX2dldGNwdSgy KSwgbWVtYmFycmllcigyKSwgYW5kIHJzZXEoMikgc3lzY2FsbHMNCg0KICDigKIgVkRTTyBvbiBh bWQ2NA0KDQpIZXJlIGlzIGEgc21hbGwgc2FtcGxlIG9mIG90aGVyIGJhc2Ugc3lzdGVtIGltcHJv dmVtZW50cyBmcm9tIEZvdW5kYXRpb24NCmRldmVsb3BlcnMgdGhpcyBxdWFydGVyIHRoYXQgZG8g bm90IGhhdmUgc2VwYXJhdGUgcmVwb3J0IGVudHJpZXMuDQoNCmtlcm4ucHJvYy5wYXRobmFtZSBj YW5vbmljYWwgaGFyZCBsaW5rDQoNClNvbWUgcHJvZ3JhbXMgYWRqdXN0IHRoZWlyIGJlaGF2aW9y IGRlcGVuZGluZyBvbiB3aGljaCBuYW1lIHdhcyB1c2VkIGZvcg0KZXhlY3V0aW9uLiBGb3IgdGhl c2UgcHJvZ3JhbXMsIGl0IGlzIG9mdGVuIGltcG9ydGFudCB0byBoYXZlIGEgY29uc2lzdGVudCBu YW1lDQppbiBhcmd2WzBdLCBzeXNjdGwga2Vybi5wcm9jLnBhdGhuYW1lLCBhdXh2IEFUX0VYRUNQ QVRILCBhbmQgYW55IHByb2NmcyBmaWxlDQpzeW1saW5rLiBCZWZvcmUgdGhpcyB3b3JrLCBhbGwg bGlzdGVkIGtlcm5lbCBpbnRlcmZhY2VzIHRyaWVkIHRvIGNhbGN1bGF0ZSBzb21lDQpuYW1lIGZv ciB0aGUgdGV4dCB2bm9kZSBhbmQgcmV0dXJuZWQgdGhlIHJlc3VsdC4gSWYgdGhlIGV4ZWN1dGVk IGJpbmFyeSBoYXMNCm1vcmUgdGhhbiBvbmUgaGFyZGxpbmssIHRoZSByZXR1cm5lZCBuYW1lcyB3 ZXJlIGFyYml0cmFyaWx5IGNob3NlbiBmcm9tIHRoZQ0KbGlzdCBvZiB2YWxpZCBuYW1lcyBmb3Ig dGhlIGZpbGUuIEFmdGVyIHdvcmsgY29tcGxldGVkIHRoaXMgcXVhcnRlciBieQ0KRm91bmRhdGlv biBkZXZlbG9wZXIgS29uc3RhbnRpbiBCZWxvdXNvdiwgdGhlIHN5c3RlbSBub3cgaG9sZHMgdGhl IHBhcmVudA0KZGlyZWN0b3J5IGFuZCB0aGUgbmFtZSBvZiB0aGUgdGV4dCBmaWxlIGZvciB0aGUg cnVubmluZyBpbWFnZS4gVGhpcyBpcyB1c2VkIHRvDQpyZWNvbnN0cnVjdCB0aGUgY29ycmVjdCBu YW1lIG9mIHRoZSB0ZXh0IGZpbGUgd2hlbiByZXF1ZXN0ZWQuDQoNCnN3YXBvbi9zd2Fwb2ZmLCBm aWxlIHN3YXBwaW5nDQoNCkFmdGVyIHdvcmsgdG8gZml4IGFzc2VydHMgZm9yIGNoYXJhY3RlciBk ZXZpY2Ugdm5vZGUgbG9ja2luZywgdGhlcmUgd2FzIGENCnJlcG9ydCB0aGF0IHN3YXAgb24gZmls ZSBjb2RlIGJyb2tlIHRoZSBWRlMgbG9ja2luZyBwcm90b2NvbC4gU29tZSBvdGhlcg0KcmVncmVz c2lvbnMgaW4gdGhlIHN3YXAgb24gZmlsZSB3ZXJlIGFsc28gaWRlbnRpZmllZC4gRm9yIGluc3Rh bmNlLCBvbg0Kc2h1dGRvd24sIGZpbGVzeXN0ZW1zIHdlcmUgdW5tb3VudGVkIGJlZm9yZSBzd2Fw b2ZmLCB3aGljaCBtYWtlcyBzd2Fwb2ZmIHBhbmljDQpvbiBwYWdlLWluLiBUaGVzZSBidWdzIHdl cmUgZml4ZWQgYW5kIGEgc3dhcG9mZigyKSBmZWF0dXJlIHdhcyBhZGRlZCB0byBhdm9pZA0Kc29t ZSB2ZXJ5IGNvbnNlcnZhdGl2ZSBlc3RpbWF0aW9ucyBmb3IgcHJvdGVjdGlvbiBhZ2FpbnN0IG1l bW9yeSBhbmQgc3dhcCBzcGFjZQ0Kc2hvcnRhZ2VzLg0KDQpmY250bChGX0tJTkZPKQ0KDQpBcHBs aWNhdGlvbiBkZXZlbG9wZXJzIG9mdGVuIHJlcXVlc3QgYW4gaW50ZXJmYWNlIHRvIHJldHVybiB0 aGUgZmlsZSBwYXRoIGZvcg0KYW4gb3BlbiBmaWxlIGRlc2NyaXB0b3IuIE91ciBvbmx5IHVzZWZ1 bCBmYWNpbGl0eSBmb3IgdGhpcyB3YXMNCmtlcm4ucHJvYy5maWxlZGVzYyBzeXNjdGwsIHdoaWNo IGlzIHNvbWV3aGF0IHVzYWJsZSwgYnV0IGluY3VycyB0b28gaGlnaCBvZiBhbg0Kb3ZlcmhlYWQg d2hlbiBhIHByb2Nlc3MgaGFzIG1hbnkgb3BlbiBmaWxlcy4gQSBmY250bChGX0tJTkZPKSBpbnRl cmZhY2Ugd2FzDQphZGRlZCwgd2hpY2ggcmV0dXJucyBhIHN0cnVjdCBraW5mb19maWxlIGp1c3Qg Zm9yIHRoZSBzcGVjaWZpZWQgZmlsZQ0KZGVzY3JpcHRvci4gQW1vbmcgb3RoZXIgdXNlZnVsIGRh dGEsIGtpbmZvX2ZpbGUgcHJvdmlkZXMgdGhlIGNhbGN1bGF0ZWQgcGF0aCwNCndoZW4gYXZhaWxh YmxlLg0KDQpDb250aW51b3VzIEludGVncmF0aW9uIGFuZCBRdWFsaXR5IEFzc3VyYW5jZQ0KDQpU aGUgRm91bmRhdGlvbiBwcm92aWRlcyBhIGZ1bGwtdGltZSBzdGFmZiBtZW1iZXIgYW5kIGZ1bmRz IHByb2plY3RzIHRvIGltcHJvdmUNCmNvbnRpbnVvdXMgaW50ZWdyYXRpb24sIGF1dG9tYXRlZCB0 ZXN0aW5nLCBhbmQgb3ZlcmFsbCBxdWFsaXR5IGFzc3VyYW5jZQ0KZWZmb3J0cyBmb3IgdGhlIEZy ZWVCU0QgcHJvamVjdC4NCg0KU3VwcG9ydGluZyBGcmVlQlNEIEluZnJhc3RydWN0dXJlDQoNClRo ZSBGb3VuZGF0aW9uIHByb3ZpZGVzIGhhcmR3YXJlIGFuZCBzdXBwb3J0IGZvciB0aGUgUHJvamVj dC4gSW4gdGhlIGZvdXJ0aA0KcXVhcnRlciBvZiAyMDIxLCB3ZSBiZWdhbiBzZWFyY2hpbmcgZm9y IGEgbmV3IEF1c3RyYWxpYW4gbWlycm9yIHNlcnZlci4gQXQgdGhlDQp0aW1lIG9mIHdyaXRpbmcs IHRoZSBzZXJ2ZXIgaXMgcHVyY2hhc2VkLCBidXQgd2l0aCBkZWxheXMgb2J0YWluaW5nIGNvbXBv bmVudHMNCmFuZCBzaGlwcGluZywgaXQgbWF5IG5vdCBiZSBhY3RpdmUgdW50aWwgdGhlIHNlY29u ZCBvciB0aGlyZCBxdWFydGVyIG9mIDIwMjIuDQpCZXR0ZXIgYW5kIGZhc3RlciBhY2Nlc3MgdG8g b3VyIHNpdGVzIGZvciB0aGUgQXVzdHJhbGlhbiBGcmVlQlNEIGNvbW11bml0eSBpcw0KY29taW5n Lg0KDQpGcmVlQlNEIEFkdm9jYWN5IGFuZCBFZHVjYXRpb24NCg0KTXVjaCBvZiBvdXIgZWZmb3J0 IGlzIGRlZGljYXRlZCB0byBQcm9qZWN0IGFkdm9jYWN5LiBUaGlzIG1heSBpbnZvbHZlDQpoaWdo bGlnaHRpbmcgaW50ZXJlc3RpbmcgRnJlZUJTRCB3b3JrLCBwcm9kdWNpbmcgbGl0ZXJhdHVyZSwg YXR0ZW5kaW5nIGV2ZW50cywNCm9yIGdpdmluZyBwcmVzZW50YXRpb25zLiBUaGUgZ29hbCBvZiB0 aGUgbGl0ZXJhdHVyZSB3ZSBwcm9kdWNlIGlzIHRvIHRlYWNoDQpwZW9wbGUgRnJlZUJTRCBiYXNp Y3MgYW5kIGhlbHAgbWFrZSB0aGVpciBwYXRoIHRvIGFkb3B0aW9uIG9yIGNvbnRyaWJ1dGlvbg0K ZWFzaWVyLiBPdGhlciB0aGFuIGF0dGVuZGluZyBhbmQgcHJlc2VudGluZyBhdCBldmVudHMsIHdl IGVuY291cmFnZSBhbmQgaGVscA0KY29tbXVuaXR5IG1lbWJlcnMgcnVuIHRoZWlyIG93biBGcmVl QlNEIGV2ZW50cywgZ2l2ZSBwcmVzZW50YXRpb25zLCBvciBzdGFmZg0KRnJlZUJTRCB0YWJsZXMu DQoNClRoZSBGcmVlQlNEIEZvdW5kYXRpb24gc3BvbnNvcnMgbWFueSBjb25mZXJlbmNlcywgZXZl bnRzLCBhbmQgc3VtbWl0cyBhcm91bmQNCnRoZSBnbG9iZS4gVGhlc2UgZXZlbnRzIGNhbiBiZSBC U0QtcmVsYXRlZCwgb3BlbiBzb3VyY2UsIG9yIHRlY2hub2xvZ3kgZXZlbnRzDQpnZWFyZWQgdG93 YXJkcyB1bmRlcnJlcHJlc2VudGVkIGdyb3Vwcy4gV2Ugc3VwcG9ydCB0aGUgRnJlZUJTRC1mb2N1 c2VkIGV2ZW50cw0KdG8gaGVscCBwcm92aWRlIGEgdmVudWUgZm9yIHNoYXJpbmcga25vd2xlZGdl LCB3b3JraW5nIHRvZ2V0aGVyIG9uIHByb2plY3RzLA0KYW5kIGZhY2lsaXRhdGluZyBjb2xsYWJv cmF0aW9uIGJldHdlZW4gZGV2ZWxvcGVycyBhbmQgY29tbWVyY2lhbCB1c2Vycy4gVGhpcw0KYWxs IGhlbHBzIHByb3ZpZGUgYSBoZWFsdGh5IGVjb3N5c3RlbS4gV2Ugc3VwcG9ydCB0aGUgbm9uLUZy ZWVCU0QgZXZlbnRzIHRvDQpwcm9tb3RlIGFuZCByYWlzZSBhd2FyZW5lc3Mgb2YgRnJlZUJTRCwg dG8gaW5jcmVhc2UgdGhlIHVzZSBvZiBGcmVlQlNEIGluDQpkaWZmZXJlbnQgYXBwbGljYXRpb25z LCBhbmQgdG8gcmVjcnVpdCBtb3JlIGNvbnRyaWJ1dG9ycyB0byB0aGUgUHJvamVjdC4gV2UgYXJl DQpjb250aW51aW5nIHRvIGF0dGVuZCB2aXJ0dWFsIGV2ZW50cyBhbmQgaGVsZCBhIHZpcnR1YWwg dmVuZG9yIHN1bW1pdCB0aGlzIHBhc3QNCk5vdmVtYmVyLg0KDQpDaGVjayBvdXQgc29tZSBvZiB0 aGUgYWR2b2NhY3kgYW5kIGVkdWNhdGlvbiB3b3JrIHdlIGRpZCBsYXN0IHF1YXJ0ZXI6DQoNCiAg 4oCiIFByb21vdGVkIGFuZCBwYXJ0aWNpcGF0ZWQgYXMgYSBtZWRpYSBzcG9uc29yIGZvciBBTEwg VGhpbmdzIE9wZW4gMjAyMQ0KDQogIOKAoiBDb21taXR0ZWQgdG8gYmVpbmcgYSBNZWRpYSBTcG9u c29yIGZvciBTQ0FMRSAxOXgNCg0KICDigKIgQ29tbWl0dGVkIHRvIGhvc3RpbmcgYSBzdGFuZCBh dCBGT1NERU0gMjAyMg0KDQogIOKAoiBTZW50IG91dCB0aGUgRmFsbCAyMDIxIE5ld3NsZXR0ZXIN Cg0KICDigKIgSGVsZCBhIEZyZWVCU0QgRnJpZGF5IHRhbGs6IFRoZSBXcml0aW5nIFNjaG9sYXLi gJlzIEd1aWRlIHRvIEZyZWVCU0QsICh0ZXh0DQogICAgZXF1aXZhbGVudCkNCg0KICDigKIgR2F2 ZSBhIEZvdW5kYXRpb24gdGFsayBhdCBTZW1pLUJ1ZywgTm92ZW1iZXIgMTYsIDIwMjENCg0KICDi gKIgR2F2ZSBGb3VuZGF0aW9uIGFuZCBGcmVlQlNEIHRhbGtzIGF0IFNlYWdhdGUgT1NQTywgRGVj ZW1iZXIgOSwgMjAyMQ0KDQogIOKAoiBIZWxwZWQgb3JnYW5pemUgdGhlIDIgZGF5IEZyZWVCU0Qg VmlydHVhbCBWZW5kb3IgU3VtbWl0LCBOb3ZlbWJlciAxOC0xOSwNCiAgICAyMDIxLiBWaWRlb3Mg Y2FuIGJlIGZvdW5kIG9uIHRoZSBQcm9qZWN04oCZcyBZb3V0dWJlIENoYW5uZWwNCg0KICDigKIg TmV3IGJsb2cgYW5kIHZpZGVvIHBvc3RzOg0KDQogICAgICDilqEgRnJlZUJTRCBGb3VuZGF0aW9u IEZhbGwgMjAyMSBVcGRhdGUNCg0KICAgICAg4pahIDIwMjEgaW4gUmV2aWV3OiBBZHZvY2FjeQ0K DQogICAgICDilqEgMjAyMSBpbiBSZXZpZXc6IEluZnJhc3RydWN0dXJlIFN1cHBvcnQNCg0KICAg ICAg4pahIDIwMjEgaW4gUmV2aWV3OiBTb2Z0d2FyZSBEZXZlbG9wbWVudA0KDQogICAgICDilqEg T3BlbiBTb3VyY2UgU3VtbWl0IDIwMjEgQ29uZmVyZW5jZSBSZWNhcA0KDQogIOKAoiBOZXcgSG93 LVRvIEd1aWRlOiBJbnRyb2R1Y3Rpb24gdG8gRnJlZUJTRA0KDQpXZSBoZWxwIGVkdWNhdGUgdGhl IHdvcmxkIGFib3V0IEZyZWVCU0QgYnkgcHVibGlzaGluZyB0aGUgcHJvZmVzc2lvbmFsbHkNCnBy b2R1Y2VkIEZyZWVCU0QgSm91cm5hbC4gQXMgd2UgbWVudGlvbmVkIHByZXZpb3VzbHksIHRoZSBG cmVlQlNEIEpvdXJuYWwgaXMNCm5vdyBhIGZyZWUgcHVibGljYXRpb24uIEZpbmQgb3V0IG1vcmUg YW5kIGFjY2VzcyB0aGUgbGF0ZXN0IGlzc3VlcyBhdCBodHRwczovLw0Kd3d3LkZyZWVCU0Rmb3Vu ZGF0aW9uLm9yZy9qb3VybmFsLy4NCg0KWW91IGNhbiBmaW5kIG91dCBtb3JlIGFib3V0IGV2ZW50 cyB3ZSBhdHRlbmRlZCBhbmQgdXBjb21pbmcgZXZlbnRzIGF0IGh0dHBzOi8vDQp3d3cuRnJlZUJT RGZvdW5kYXRpb24ub3JnL25ld3MtYW5kLWV2ZW50cy8uDQoNCkxlZ2FsL0ZyZWVCU0QgSVANCg0K VGhlIEZvdW5kYXRpb24gb3ducyB0aGUgRnJlZUJTRCB0cmFkZW1hcmtzLCBhbmQgaXQgaXMgb3Vy IHJlc3BvbnNpYmlsaXR5IHRvDQpwcm90ZWN0IHRoZW0uIFdlIGFsc28gcHJvdmlkZSBsZWdhbCBz dXBwb3J0IGZvciB0aGUgY29yZSB0ZWFtIHRvIGludmVzdGlnYXRlDQpxdWVzdGlvbnMgdGhhdCBh cmlzZS4NCg0KR28gdG8gaHR0cHM6Ly93d3cuRnJlZUJTREZvdW5kYXRpb24ub3JnIHRvIGZpbmQg bW9yZSBhYm91dCBob3cgd2Ugc3VwcG9ydA0KRnJlZUJTRCBhbmQgaG93IHdlIGNhbiBoZWxwIHlv dSENCg0K4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSBDQoNClBvcnRzIENvbGxlY3Rpb24NCg0KTGlua3M6DQpBYm91dCBGcmVl QlNEIFBvcnRzIFVSTDogaHR0cHM6Ly93d3cuRnJlZUJTRC5vcmcvcG9ydHMvDQpDb250cmlidXRp bmcgdG8gUG9ydHMgVVJMOiBodHRwczovL2RvY3MuZnJlZWJzZC5vcmcvZW4vYXJ0aWNsZXMvY29u dHJpYnV0aW5nLyMNCnBvcnRzLWNvbnRyaWJ1dGluZw0KRnJlZUJTRCBQb3J0cyBNb25pdG9yaW5n IFVSTDogaHR0cDovL3BvcnRzbW9uLmZyZWVic2Qub3JnLw0KUG9ydHMgTWFuYWdlbWVudCBUZWFt IFVSTDogaHR0cHM6Ly93d3cuZnJlZWJzZC5vcmcvcG9ydG1nci8NClBvcnRzIFRhcmJhbGwgVVJM OiBodHRwOi8vZnRwLmZyZWVic2Qub3JnL3B1Yi9GcmVlQlNEL3BvcnRzL3BvcnRzLw0KDQpDb250 YWN0OiBSZW7DqSBMYWRhbiA8cG9ydG1nci1zZWNyZXRhcnlARnJlZUJTRC5vcmc+DQpDb250YWN0 OiBGcmVlQlNEIFBvcnRzIE1hbmFnZW1lbnQgVGVhbSA8cG9ydG1nckBGcmVlQlNELm9yZz4NCg0K VGhlIFBvcnRzIE1hbmFnZW1lbnQgVGVhbSBpcyByZXNwb25zaWJsZSBmb3Igb3ZlcnNlZWluZyB0 aGUgb3ZlcmFsbCBkaXJlY3Rpb24NCm9mIHRoZSBQb3J0cyBUcmVlLCBidWlsZGluZyBwYWNrYWdl cywgYW5kIHBlcnNvbm5lbCBtYXR0ZXJzLiBCZWxvdyBpcyB3aGF0DQpoYXBwZW5lZCBpbiB0aGUg bGFzdCBxdWFydGVyLg0KDQpXZSBjdXJyZW50bHkgaGF2ZSA0Niw3MDAgcG9ydHMgaW4gdGhlIFBv cnRzIENvbGxlY3Rpb24gYWNjb3JkaW5nIHRvIEZyZXNoUG9ydHMuDQpUaGVyZSBhcmUgY3VycmVu dGx5IDIsNjY2IG9wZW4gcG9ydHMgUFJzIG9mIHdoaWNoIDYxMSBhcmUgdW5hc3NpZ25lZC4gVGhp cw0KcXVhcnRlciBzYXcgOSw1MzUgY29tbWl0cyBmcm9tIDE2NiBjb21taXR0ZXJzIG9uIHRoZSBt YWluIGJyYW5jaCBhbmQgNjQ0DQpjb21taXRzIGZyb20gNjIgY29tbWl0dGVycyBvbiB0aGUgcXVh cnRlcmx5IGJyYW5jaC4gQ29tcGFyZWQgdG8gbGFzdCBxdWFydGVyLA0KdGhpcyBtZWFucyBhIHNs aWdodCBkcm9wIGluIHRoZSBudW1iZXIgb2YgY29tbWl0cyBhbHRob3VnaCBtb3JlIGNvbW1pdHRl cnMgd2VyZQ0KYWN0aXZlLCBhbmQgYSBzbGlnaHQgaW5jcmVhc2UgaW4gdGhlIG51bWJlciBvZiBv cGVuIFBScy4NCg0KRHVyaW5nIHRoZSBsYXN0IHF1YXJ0ZXIsIHdlIHdlbGNvbWVkIERyaWVzIE1p Y2hpZWxzIChkcmllc21AKSBhbmQgc2FpZCBnb29kYnllDQp0byBrdXJpeWFtYUAgYW5kIGZqb2VA LiBUaGVyZSB3YXMgYWxzbyBhIGNoYW5nZSBpbiBwb3J0bWdyOiBhZGFtd0Agc3RlcHBlZCBkb3du DQphZnRlciBmaXZlIHllYXJzIG9mIHNlcnZpY2UgYW5kIHRjYmVybmVyQCBpcyBub3cgYSBmdWxs IG1lbWJlciBvZiBwb3J0bWdyQC4NCg0KVGhyZWUgbmV3IFVTRVMgd2VyZSBpbnRyb2R1Y2VkOg0K DQogIOKAoiBtYWdpY2sgdG8gaGFuZGxlIGRlcGVuZGVuY2llcyBvbiBJbWFnZU1hZ2ljaw0KDQog IOKAoiBub2RlanMgdG8gcHJvdmlkZSBzdXBwb3J0IGZvciBOb2RlSlMgKHdpdGggYSBuZXcgZGVm YXVsdCB2ZXJzaW9uIE5PREVKUz0NCiAgICBsdHMpDQoNCiAg4oCiIHRyaWdnZXIgdG8gaGFuZGxl IHBrZyB0cmlnZ2VycyB1c2luZyB0aGUgVFJJR0dFUlMgdmFyaWFibGUNCg0KVGhlIGRlZmF1bHQg dmVyc2lvbiBvZiBQR1NRTCBzd2l0Y2hlZCB0byAxMy4gRnVydGhlcm1vcmUsIElOU1RBTExTX0lD T05TIGhhcw0KYmVlbiByZXBsYWNlZCBieSBhIHRyaWdnZXIgb24gZ3RrLXVwZGF0ZS1pY29uLWNh Y2hlIGFuZCB0aGUgbWFjcm8gaXMgbm8gbG9uZ2VyDQpmdW5jdGlvbmFsLg0KDQpBcyBhbHdheXMs IHRoZXJlIHdlcmUgc29tZSB1cGRhdGVzIHRvICJiaWciIHBhY2thZ2VzOiBwa2cgd2FzIHVwZGF0 ZWQgdG8NCjEuMTcuNSwgQ2hyb21pdW0gdG8gOTQuMC40NjA2LjgxXzMsIGFuZCBGaXJlZm94IHRv IDk1LjAuMl8xLDIuIFJ1YnkgMy4xLjAgYW5kDQpQeXRob24gMy4xMSBhcmUgbm93IGF2YWlsYWJs ZSBmb3IgdXNlIGJ5IHVzZXJzIGFuZCBvdGhlciBwb3J0cy4NCg0K4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSBDQoNCkRvY3Vt ZW50YXRpb24gRW5naW5lZXJpbmcgVGVhbQ0KDQpMaW5rczoNCkZyZWVCU0QgRG9jdW1lbnRhdGlv biBQcm9qZWN0IFVSTDogaHR0cHM6Ly93d3cuZnJlZWJzZC5vcmcvZG9jcHJvai8NCkZyZWVCU0Qg RG9jdW1lbnRhdGlvbiBQcm9qZWN0IFByaW1lciBmb3IgTmV3IENvbnRyaWJ1dG9ycyBVUkw6IGh0 dHBzOi8vDQpkb2NzLmZyZWVic2Qub3JnL2VuL2Jvb2tzL2ZkcC1wcmltZXIvDQpEb2N1bWVudGF0 aW9uIEVuZ2luZWVyaW5nIFRlYW0gVVJMOiBodHRwczovL3d3dy5mcmVlYnNkLm9yZy9hZG1pbmlz dHJhdGlvbi8jDQp0LWRvY2VuZw0KDQpDb250YWN0OiBGcmVlQlNEIERvY2VuZyBUZWFtIDxkb2Nl bmdARnJlZUJTRC5vcmc+DQoNClRoZSBkb2NlbmdAIHRlYW0gaXMgYSBib2R5IHRvIGhhbmRsZSBz b21lIG9mIHRoZSBtZXRhLXByb2plY3QgaXNzdWVzIGFzc29jaWF0ZWQNCndpdGggdGhlIEZyZWVC U0QgRG9jdW1lbnRhdGlvbiBQcm9qZWN0OyBmb3IgbW9yZSBpbmZvcm1hdGlvbiwgc2VlIEZyZWVC U0QNCkRvY2VuZyBUZWFtIENoYXJ0ZXIuDQoNCk5vIG5ldyBkb2N1bWVudGF0aW9uIGNvbW1pdCBi aXQgd2FzIGdyYW50ZWQgZHVyaW5nIHRoZSBsYXN0IHF1YXJ0ZXIsIGFuZCBvbmx5DQpvbmUgY29t bWl0IGJpdCB3YXMgc2FmZSBrZXB0Lg0KDQpTZXZlcmFsIHRhc2tzIHdlcmUgY29tcGxldGVkIHJl bGF0ZWQgdG8gdGhlIGRvYyB0cmVlIGR1cmluZyB0aGUgbGFzdCBxdWFydGVyOg0KDQogIOKAoiBB IENPUFlSSUdIVCBmaWxlIHdhcyBhZGRlZCBpbiB0aGUgcm9vdCBkaXJlY3Rvcnkgb2YgdGhlIGRv YyByZXBvc2l0b3J5LiBUaGUNCiAgICBsaWNlbnNlIHdhcyBhbHNvIHVwZGF0ZWQgdG8gcmVmbGVj dCB0aGUgY3VycmVudCB0b29sY2hhaW4gdGhlIHByb2plY3QgaXMNCiAgICB1c2luZyBub3cuDQoN CiAg4oCiIENsZWFudXAgb2YgTWFpbG1hbiBpbmZvcm1hdGlvbiBpbiB0aGUgZG9jIHRyZWUuIEZv bGxvd2luZyBtYWlsaW5nIGxpc3RzDQogICAgbWlncmF0aW9uIGZyb20gTWFpbG1hbiB0byBNbG1t aiwgdmVyeSBvbGQgbWFpbGluZyBsaXN0cyB3ZXJlIHJlbW92ZWQ7IG1vc3QNCiAgICBvZiB0aGUg d29yayB3YXMgbWFkZSBvbiBFbmdsaXNoIGRvY3VtZW50cy4NCg0KICDigKIgVGFnIEZyZWVCU0Qg ZG9jc2V0IGZvciAxMi4zLVJFTEVBU0UuDQoNCiAg4oCiIFVwZGF0ZSBhbGwgcG9ydHMvcGFja2Fn ZXMgbWlzYy9mcmVlYnNkLWRvYy0qLg0KDQogIOKAoiBNb3ZlIGFydGljbGVzL2NvbnRyaWJ1dG9y cy9jb250cmliLSogZmlsZXMgdG8gdGhlIGRvYyBzaGFyZWQgZGlyZWN0b3J5Lg0KDQogIOKAoiBB ZGQgb3B0aW9uIGluIGRvY3VtZW50YXRpb24gTWFrZWZpbGUgdG8gYXJjaGl2ZS9jb21wcmVzcyBE b2N1bWVudGF0aW9uL0hUTUwNCiAgICBvZmZsaW5lIGZpbGVzLCBhIG5lY2Vzc2FyeSBzdGVwIGJl Zm9yZSB1cGRhdGluZyBodHRwczovLw0KICAgIGRvd25sb2FkLmZyZWVic2Qub3JnL2Z0cC8uIFRo aXMgd2FzIGFmdGVyIGEgZGlzY3Vzc2lvbiB3aXRoIGNsdXN0ZXJhZG1AIHRvDQogICAgdXBkYXRl IHRoZSBvZmZsaW5lIGFzc2V0cyAoSFRNTC9QREYpLg0KDQogIOKAoiBBZGQgZXhwZXJpbWVudGFs IHN1cHBvcnQgZm9yIEVQVUIgb3V0cHV0IChib29rcy9hcnRpY2xlcykuDQoNCiAg4oCiIFRhbGtp bmcgd2l0aCBjbHVzdGVyYWRtQCB0byBpbXByb3ZlIHRoZSBwZXJmb3JtYW5jZSBvZiBodHRwczov Lw0KICAgIHd3dy5mcmVlYnNkLm9yZyBhbmQgaHR0cHM6Ly9kb2NzLmZyZWVic2Qub3JnLg0KDQri lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIENCg0KRnJlZUJTRCBXZWJzaXRlIFJldmFtcCAtIFdlYkFwcHMgd29ya2luZyBncm91 cA0KDQpDb250YWN0OiBTZXJnaW8gQ2FybGF2aWxsYSA8Y2FybGF2aWxsYUBGcmVlQlNELm9yZz4N Cg0KV29ya2luZyBncm91cCBpbiBjaGFyZ2Ugb2YgY3JlYXRpbmcgdGhlIG5ldyBGcmVlQlNEIERv Y3VtZW50YXRpb24gUG9ydGFsIGFuZA0KcmVkZXNpZ25pbmcgdGhlIEZyZWVCU0QgbWFpbiB3ZWJz aXRlIGFuZCBpdHMgY29tcG9uZW50cy4gRnJlZUJTRCBkZXZlbG9wZXJzIGNhbg0KZm9sbG93IGFu ZCBqb2luIHRoZSB3b3JraW5nIGdyb3VwIG9uIHRoZSBGcmVlQlNEIFNsYWNrIGNoYW5uZWwgI3dn LXd3dzIxLiBUaGUNCndvcmsgd2lsbCBiZSBkaXZpZGVkIGludG8gZm91ciBwaGFzZXM6DQoNCiAx LiBSZWRlc2lnbiBvZiB0aGUgRG9jdW1lbnRhdGlvbiBQb3J0YWwNCg0KICAgIENyZWF0ZSBhIG5l dyBkZXNpZ24sIHJlc3BvbnNpdmUgYW5kIHdpdGggZ2xvYmFsIHNlYXJjaC4gKENvbXBsZXRlKQ0K DQogICAgQWN0aXZhdGUgYW4gZWRpdCBsaW5rIGluIHRoZSBEb2N1bWVudGF0aW9uIChib29rcy9h cnRpY2xlcykgcG9pbnRpbmcgdG8NCiAgICBHaXRIdWIgYW5kIGVuY291cmFnaW5nIEdpdEh1YiBw dWxsIHJlcXVlc3RzLiAoQ29tcGxldGUpDQoNCiAyLiBSZWRlc2lnbiBvZiB0aGUgTWFudWFsIFBh Z2VzIG9uIHdlYg0KDQogICAgU2NyaXB0cyB0byBnZW5lcmF0ZSB0aGUgSFRNTCBwYWdlcyB1c2lu ZyBtYW5kb2MuIChXb3JrIGluIHByb2dyZXNzKQ0KDQogMy4gUmVkZXNpZ24gb2YgdGhlIFBvcnRz IHBhZ2Ugb24gd2ViDQoNCiAgICBQb3J0cyBzY3JpcHRzIHRvIGNyZWF0ZSBhbiBhcHBsaWNhdGlv bnMgcG9ydGFsLiAoV29yayBpbiBwcm9ncmVzcykNCg0KIDQuIFJlZGVzaWduIG9mIHRoZSBGcmVl QlNEIG1haW4gd2Vic2l0ZQ0KDQogICAgTmV3IGRlc2lnbiwgcmVzcG9uc2l2ZSBhbmQgZGFyayB0 aGVtZS4gKE5vdCBzdGFydGVkKQ0KDQrilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIENCg0KUHJvamVjdHMNCg0KUHJvamVjdHMg dGhhdCBzcGFuIG11bHRpcGxlIGNhdGVnb3JpZXMsIGZyb20gdGhlIGtlcm5lbCBhbmQgdXNlcnNw YWNlIHRvIHRoZQ0KUG9ydHMgQ29sbGVjdGlvbiBvciBleHRlcm5hbCBwcm9qZWN0cy4NCg0KRW5h YmxlIEFTTFIgYnkgZGVmYXVsdCBmb3IgNjQtYml0IGV4ZWN1dGFibGVzDQoNCkNvbnRhY3Q6IERh d2lkIEdvcmVja2kgPGRnckBzZW1paGFsZi5jb20+DQpDb250YWN0OiBNYXJjaW4gV29qdGFzIDxt d0BzZW1paGFsZi5jb20+DQoNCkFkZHJlc3MgU3BhY2UgTGF5b3V0IFJhbmRvbWl6YXRpb24gKEFT TFIpIGlzIGFuIGV4cGxvaXQgbWl0aWdhdGlvbiB0ZWNobmlxdWUNCmltcGxlbWVudGVkIGluIHRo ZSBtYWpvcml0eSBvZiBtb2Rlcm4gb3BlcmF0aW5nIHN5c3RlbXMuIEl0IGludm9sdmVzIHJhbmRv bWx5DQpwb3NpdGlvbmluZyB0aGUgYmFzZSBhZGRyZXNzIG9mIGFuIGV4ZWN1dGFibGUgYW5kIHRo ZSBwb3NpdGlvbiBvZiBsaWJyYXJpZXMsDQpoZWFwLCBhbmQgc3RhY2ssIGluIGEgcHJvY2Vzc+KA mXMgYWRkcmVzcyBzcGFjZS4gQWx0aG91Z2ggb3ZlciB0aGUgeWVhcnMgQVNMUg0KcHJvdmVkIHRv IG5vdCBndWFyYW50ZWUgZnVsbCBPUyBzZWN1cml0eSBvbiBpdHMgb3duLCB0aGlzIG1lY2hhbmlz bSBjYW4gbWFrZQ0KZXhwbG9pdGF0aW9uIG1vcmUgZGlmZmljdWx0Lg0KDQpUaGUgU2VtaWhhbGYg dGVhbSBtYWRlIGFuIGVmZm9ydCB0byBzd2l0Y2ggb24gdGhlIGFkZHJlc3MgbWFwIHJhbmRvbWl6 YXRpb24gZm9yDQpQSUUgKFBvc2l0aW9uIEluZGVwZW5kZW50IEV4ZWN1dGFibGVzKSAmIG5vbi1Q SUUgNjQtYml0IGJpbmFyaWVzLiBPbmNlIHRoZQ0KcGF0Y2ggd2FzIG1lcmdlZCB0byBIRUFELCB0 aGUgQVNMUiBmZWF0dXJlIGJlY2FtZSBlbmFibGVkIGZvciBhbGwgNjQtYml0DQphcmNoaXRlY3R1 cmVzLg0KDQpBZGRpdGlvbmFsbHksIHRoZSBtZW50aW9uZWQgY2hhbmdlIGRpc2FibGVkIFNCUkss IGluIG9yZGVyIHRvIGFsbG93IHV0aWxpemF0aW9uDQpvZiB0aGUgYnNzIGdyb3cgcmVnaW9uIGZv ciBtYXBwaW5ncy4gSXQgaGFzIG5vIGVmZmVjdCB3aXRob3V0IEFTTFIsIHNvIGl0IHdhcw0KYXBw bGllZCB0byBhbGwgYXJjaGl0ZWN0dXJlcy4NCg0KVE9ETzoNCg0KICDigKIgSW1wcm92ZSBzdGFj a2dhcCBmZWF0dXJlIGltcGxlbWVudGF0aW9uLg0KDQogIOKAoiBNRkMgdG8gc3RhYmxlLzEzIGJy YW5jaC4NCg0KU3BvbnNvcjogU3Rvcm1zaGllbGQNCg0K4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSBDQoNCkJvb3QgUGVyZm9y bWFuY2UgSW1wcm92ZW1lbnRzDQoNCkxpbmtzOg0KV2lraSBwYWdlIFVSTDogaHR0cHM6Ly93aWtp LmZyZWVic2Qub3JnL0Jvb3RUaW1lDQpPUyBib290IHRpbWUgY29tcGFyaXNvbiBVUkw6IGh0dHBz Oi8vd3d3LmRhZW1vbm9sb2d5Lm5ldC9ibG9nLw0KMjAyMS0wOC0xMi1FQzItYm9vdC10aW1lLWJl bmNobWFya2luZy5odG1sDQoNCkNvbnRhY3Q6IENvbGluIFBlcmNpdmFsIDxjcGVyY2l2YUBGcmVl QlNELm9yZz4NCg0KQ29saW4gUGVyY2l2YWwgaXMgY29vcmRpbmF0aW5nIGFuIGVmZm9ydCB0byBz cGVlZCB1cCB0aGUgRnJlZUJTRCBib290IHByb2Nlc3MuDQpGb3IgYmVuY2htYXJraW5nIHB1cnBv c2VzLCBoZSBpcyBwcmltYXJpbHkgdXNpbmcgYW4gRUMyIGM1LnhsYXJnZSBpbnN0YW5jZSBhcyBh DQpyZWZlcmVuY2UgcGxhdGZvcm0gYW5kIGlzIG1lYXN1cmluZyB0aGUgdGltZSBiZXR3ZWVuIHdo ZW4gdGhlIHZpcnR1YWwgbWFjaGluZQ0KZW50ZXJzIHRoZSBFQzIgInJ1bm5pbmciIHN0YXRlIGFu ZCB3aGVuIGl0IGlzIHBvc3NpYmxlIHRvIFNTSCBpbnRvIHRoZQ0KaW5zdGFuY2UuDQoNClRoaXMg d29yayBzdGFydGVkIGluIDIwMTcsIGFuZCBhcyBvZiB0aGUgZW5kIG9mIFNlcHRlbWJlciAyMDIx IHRoZSBGcmVlQlNEIGJvb3QNCnRpbWUgd2FzIHJlZHVjZWQgZnJvbSBhcHByb3hpbWF0ZWx5IDMw IHNlY29uZHMgdG8gYXBwcm94aW1hdGVseSAxNSBzZWNvbmRzLg0KDQpEdXJpbmcgMjAyMVE0LCBm dXJ0aGVyIGltcHJvdmVtZW50cyBoYXZlIHNoYXZlZCBtb3JlIHRpbWUgb2ZmIHRoZSBib290IHBy b2Nlc3MsDQp0YWtpbmcgaXQgZG93biB0byByb3VnaGx5IDEwIHNlY29uZHMuIEEgZnVydGhlciA0 IHNlY29uZHMgb2YgaW1wcm92ZW1lbnRzIGFyZQ0KaW4gcHJvY2Vzcy4NCg0KSW4gYWRkaXRpb24s IHRoZSB1c2VybGFuZCBib290IHByb2Nlc3MgaXMgbm93IGJlaW5nIHByb2ZpbGVkIHVzaW5nIFRT TE9HLA0KbWFraW5nIGl0IHBvc3NpYmxlIHRvIHNlZSBmbGFtZWNoYXJ0cyBvZiB0aGUgZW50aXJl IGJvb3QgcHJvY2VzczsgYW5kIHRoZQ0KZWMyLWJvb3QtYmVuY2ggdG9vbCBpcyBub3cgYWJsZSB0 byBnZW5lcmF0ZSBNUDQgdmlkZW9zIG9mIHRoZSBib290IHByb2Nlc3MgYnkNCnRha2luZyBzbmFw c2hvdHMgb2YgdGhlIEVDMiBWR0EgY29uc29sZS4NCg0KSXNzdWVzIGFyZSBsaXN0ZWQgb24gdGhl IHdpa2kgcGFnZSBhcyB0aGV5IGFyZSBpZGVudGlmaWVkOyB0aGUgd2lraSBwYWdlIGFsc28NCmhh cyBpbnN0cnVjdGlvbnMgZm9yIHBlcmZvcm1pbmcgcHJvZmlsaW5nLiBVc2VycyBhcmUgZW5jb3Vy YWdlZCB0byBwcm9maWxlIHRoZQ0KYm9vdCBwcm9jZXNzIG9uIHRoZWlyIG93biBzeXN0ZW1zLCBp biBjYXNlIHRoZXkgZXhwZXJpZW5jZSBkZWxheXMgd2hpY2ggZG9u4oCZdA0Kc2hvdyB1cCBvbiB0 aGUgc3lzdGVtIENvbGluIGlzIHVzaW5nIGZvciB0ZXN0aW5nLg0KDQpUaGlzIHdvcmsgaXMgc3Vw cG9ydGVkIGJ5IENvbGlu4oCZcyBGcmVlQlNEL0VDMiBQYXRyZW9uLg0KDQpTcG9uc29yOiBodHRw czovL3d3dy5wYXRyZW9uLmNvbS9jcGVyY2l2YQ0KDQrilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIENCg0KTExEQiBEZWJ1Z2dl ciBJbXByb3ZlbWVudHMNCg0KTGlua3M6DQpNb3JpdHogU3lzdGVtcyBQcm9qZWN0IERlc2NyaXB0 aW9uIFVSTDogaHR0cHM6Ly93d3cubW9yaXR6LnN5c3RlbXMvYmxvZy8NCmZyZWVic2Qta2dkYi1z dXBwb3J0LWluLWxsZGIvDQpQcm9ncmVzcyBSZXBvcnQgMyBVUkw6IGh0dHBzOi8vd3d3Lm1vcml0 ei5zeXN0ZW1zL2Jsb2cvDQpsbGRiLXNlcmlhbC1wb3J0LWNvbW11bmljYXRpb24tc3VwcG9ydC8N ClByb2dyZXNzIFJlcG9ydCA0IFVSTDogaHR0cHM6Ly93d3cubW9yaXR6LnN5c3RlbXMvYmxvZy8N CmxsZGItZnJlZWJzZC1rZXJuZWwtY29yZS1kdW1wLXN1cHBvcnQvDQpMTFZNIEdpdCBSZXBvc2l0 b3J5IFVSTDogaHR0cHM6Ly9naXRodWIuY29tL21vcml0ei1zeXN0ZW1zL2xsdm0tcHJvamVjdA0K bGliZmJzZHZtY29yZSBHaXQgUmVwb3NpdG9yeSBVUkw6IGh0dHBzOi8vZ2l0aHViLmNvbS9tb3Jp dHotc3lzdGVtcy8NCmxpYmZic2R2bWNvcmUNCg0KQ29udGFjdDogS2FtaWwgUnl0YXJvd3NraSA8 a2FtaWxAbW9yaXR6LnN5c3RlbXM+DQpDb250YWN0OiBNaWNoYcWCIEfDs3JueSA8bWdvcm55QG1v cml0ei5zeXN0ZW1zPg0KDQpBY2NvcmRpbmcgdG8gdGhlIHVwc3RyZWFtIGRlc2NyaXB0aW9uLCAi TExEQiBpcyBhIG5leHQgZ2VuZXJhdGlvbiwNCmhpZ2gtcGVyZm9ybWFuY2UgZGVidWdnZXIuIEl0 IGlzIGJ1aWx0IGFzIGEgc2V0IG9mIHJldXNhYmxlIGNvbXBvbmVudHMgd2hpY2gNCmhpZ2hseSBs ZXZlcmFnZSBleGlzdGluZyBsaWJyYXJpZXMgaW4gdGhlIGxhcmdlciBMTFZNIFByb2plY3QsIHN1 Y2ggYXMgdGhlDQpDbGFuZyBleHByZXNzaW9uIHBhcnNlciBhbmQgTExWTSBkaXNhc3NlbWJsZXIu Ig0KDQpGcmVlQlNEIGluY2x1ZGVzIExMREIgaW4gdGhlIGJhc2Ugc3lzdGVtLiBBdCBwcmVzZW50 LCBpdCBoYXMgc29tZSBsaW1pdGF0aW9ucw0KY29tcGFyZWQgdG8gdGhlIEdOVSBHREIgZGVidWdn ZXIsIGFuZCBkb2VzIG5vdCB5ZXQgcHJvdmlkZSBhIGNvbXBsZXRlDQpyZXBsYWNlbWVudC4gVGhp cyBwcm9qZWN0IHNwYW5zIGZyb20gSnVseSAyMDIxIHRvIEphbnVhcnkgMjAyMiBhbmQgYWltcyB0 byBtYWtlDQpMTERCIHN1aXRhYmxlIGZvciBkZWJ1Z2dpbmcgRnJlZUJTRCBrZXJuZWxzLg0KDQpU aGUgZWFybGllciBwYXJ0IG9mIHRoZSBwcm9qZWN0IHdhcyBmb2N1c2VkIG9uIGltcHJvdmluZyBj b21wYXRpYmlsaXR5IGJldHdlZW4NCkxMREIgYW5kIG90aGVyIHNlcnZlcnMgaW1wbGVtZW50aW5n IHRoZSBHREIgUmVtb3RlIFByb3RvY29sLiBUaGlzIHdhcyBmb2xsb3dlZA0KYnkgaW1wbGVtZW50 aW5nIGEgZnVsbHktZmVhdHVyZWQgc2VyaWFsIHBvcnQgc3VwcG9ydCBhbmQgdGhlbiBzdXBwb3J0 IGZvcg0KRnJlZUJTRCBrZXJuZWwgY29yZSBkdW1wcyAodm1jb3JlcykuDQoNClRoZSBMTERCIGNs aWVudCBnYWluZWQgbXVjaCBpbXByb3ZlZCBzdXBwb3J0IGZvciBjb25uZWN0aW5nIHRvIHRoZSBy ZW1vdGUNCnNlcnZlciBvdmVyIGEgc2VyaWFsIHBvcnQsIGFuZCB0aGUgTExEQiBzZXJ2ZXIgZ2Fp bmVkIHN1cHBvcnQgZm9yIGFjY2VwdGluZw0KY29tbXVuaWNhdGlvbiBvdmVyIGEgc2VyaWFsIHBv cnQuIFRoaXMgb3BlbmVkIHRoZSBwb3NzaWJpbGl0eSBvZiB1c2luZyBMTERCIHRvDQpkZWJ1ZyBl bWJlZGRlZCBkZXZpY2VzIHRoYXQgdXNlIHRoZSBSUzIzMiBpbnRlcmZhY2UuIEl0IGNhbiBhbHNv IGFpZCBkZWJ1Z2dpbmcNCmtlcm5lbHMgb24gcmVndWxhciBQQ3MgYXMgaXQgZG9lcyBub3QgcmVs eSBvbiB0aGUgbmV0d29yayBzdGFjay4NCg0KU3VwcG9ydCBmb3IgRnJlZUJTRCB2bWNvcmVzIGhh cyBhbHNvIGJlZW4gYWRkZWQgdG8gTExEQi4gVGhpcyBtYWtlcyBpdCBwb3NzaWJsZQ0KdG8gaW5z cGVjdCB0aGUgY3Jhc2hlZCBrZXJuZWwgc3RhdGUgd2l0aG91dCBoYXZpbmcgdG8gcmVzb3J0IHRv IEtHREIgb3INCm1hbnVhbGx5IGNvbnZlcnQgdGhlIHZtY29yZSBpbnRvIHRoZSBzdGFuZGFyZCBF TEYgZm9ybWF0IHN1cHBvcnRlZCBieSBMTERCLg0KDQpUaGUgaW50cm9kdWNlZCBjaGFuZ2VzIGFy ZSBleHBlY3RlZCB0byBiZSBzaGlwcGVkIHdpdGggTExEQiAxNC4wLg0KDQpTcG9uc29yOiBUaGUg RnJlZUJTRCBGb3VuZGF0aW9uDQoNCuKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgQ0KDQpOWFAgTFMxMDI4QS8xMDI3QSBTb0Mg c3VwcG9ydA0KDQpDb250YWN0OiBLb3JuZWwgRHVsxJliYSA8bWluZGFsQHNlbWloYWxmLmNvbT4N CkNvbnRhY3Q6IEFydHVyIFJvamVrIDxhckBzZW1paGFsZi5jb20+DQpDb250YWN0OiBIdWJlcnQg TWF6dXIgPGh1bUBzZW1paGFsZi5jb20+DQpDb250YWN0OiBXb2pjaWVjaCBNYWNlayA8d21hQHNl bWloYWxmLmNvbT4NCg0KVGhlIFNlbWloYWxmIHRlYW0gaGFzIGJlZW4gd29ya2luZyBvbiBhZGRp bmcgdGhlIEZyZWVCU0Qgc3VwcG9ydCBmb3IgdGhlIE5YUA0KTFMxMDI4QSBTb0MsIGFzIHdlbGwg YXMgaXRzIEdQVS1sZXNzIHZhcmlhbnQgKE5YUCBMUzEwMjdBKS4NCg0KTlhQIExTMTAyOEEvTFMx MDI3QSBTb0MgaXMgYSBkdWFsLWNvcmUgNjQtYml0IEFSTXY4IENvcnRleC1BNzIgYXBwbGljYXRp b24NCnByb2Nlc3NvciB3aXRoIGhpZ2gtc3BlZWQgcGVyaXBoZXJhbHMgc3VjaCBhcyAyIFRpbWUt U2Vuc2l0aXZlDQpOZXR3b3JraW5nLWNhcGFibGUgKFRTTikgRXRoZXJuZXQgY29udHJvbGxlcnMs IHF1YWQtcG9ydCBUU04tZW5hYmxlZCBzd2l0Y2gsDQpQQ0lFLCBTRC9NTUMsIFVTQjMuMCBhbmQg b3RoZXJzLg0KDQpUaGUgb3JpZ2luYWwgc3VwcG9ydCB3YXMgZXh0ZW5kZWQgaW4gdGhlIGZvbGxv d2luZyB3YXk6DQoNCiAg4oCiIEVORVRDIEV0aGVybmV0IGRyaXZlcg0KDQogICAgICDilqEgQWRk IHN1cHBvcnQgZm9yIFBIWSBpbnRlcnJ1cHRzDQoNCiAgICAgIOKWoSBGaXggVklEL21jYXN0IGFk ZHJlc3MgaGFzaCBjYWxjdWxhdGlvbg0KDQogICAgICDilqEgU2VyaWFsaXplIE1ESU8gdHJhbnNh Y3Rpb25zDQoNCiAgICAgIOKWoSBBbGxvdyBsb2FkaW5nIGRyaXZlciBhcyBhIG1vZHVsZQ0KDQog IOKAoiBJbXByb3ZlbWVudHMgaW4gdGhlIEZTTCBTREhDSSBkcml2ZXINCg0KICAgICAg4pahIEFk ZCBzdXBwb3J0IGZvciBIUzIwMC9IUzQwMCBtb2Rlcw0KDQogICAgICDilqEgQWRkIGZ1bGwgc3Vw cG9ydCBmb3Igc29mdHdhcmUgcmVzZXQNCg0KICAgICAg4pahIFByb3ZpZGUgbW9yZSBhY2N1cmF0 ZSBjbGsgY2FsY3VsYXRpb24NCg0KICAgICAg4pahIEltcGxlbWVudCBwdWxzZSB3aWR0aCBkZXRl Y3Rpb24gZXJyYXRhDQoNCiAgICAgIOKWoSBGaXggdmNjcSByZWNvbmZpZ3VyYXRpb24NCg0KICDi gKIgRkxFWCBTUEkgTk9SIGNvbnRyb2xsZXIgZHJpdmVyDQoNCiAg4oCiIEFkZGl0aW9uYWwgZmVh dHVyZXM6DQoNCiAgICAgIOKWoSBUTVA0NjEgdGhlcm1hbCBzZW5zb3IgZHJpdmVyDQoNCiAgICAg IOKWoSBQQ0Y4NTA2MyBSVEMgZHJpdmVyIGRyaXZlcg0KDQogICAgICDilqEgVENBNjQwOCBJMkMg R1BJTyBleHBhbmRlciBkcml2ZXINCg0KVE9ETzoNCg0KICDigKIgSW1wcm92ZSBNTUMgSFMyMDAv SFM0MDAgc3VwcG9ydCBmb3Igb3RoZXIgU29DcyB1c2luZyB0aGUgRlNMIFNESENJDQogICAgY29u dHJvbGxlci4NCg0KU3BvbnNvcjogQWxzdG9tIEdyb3VwDQoNCuKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgQ0KDQpzY2hlZF9n ZXRjcHUoMiksIG1lbWJhcnJpZXIoMiksIGFuZCByc2VxKDIpIHN5c2NhbGxzDQoNCkNvbnRhY3Q6 IEtvbnN0YW50aW4gQmVsb3Vzb3YgPGtpYkBGcmVlQlNELm9yZz4NCg0KTGlua3M6DQpMaW51eCBt YW5wYWdlIGZvciBtZW1iYXJyaWVyKDIpIFVSTDogaHR0cHM6Ly9raWIua2lldi51YS9raWIvbWVt YmFycmllci5wZGYNCm1lbWJhcnJpZXIoMikgaW1wbGVtZW50YXRpb24gVVJMOiBodHRwczovL3Jl dmlld3MuZnJlZWJzZC5vcmcvRDMyMzYwDQpMaW51eCBtYW5wYWdlIGZvciByc2VxKDIpIFVSTDog aHR0cHM6Ly9raWIua2lldi51YS9raWIvcnNlcS5wZGYNCnJzZXEoMikgYW5kIHVzZXJzcGFjZSBi aW5kaW5ncyBpbXBsZW1lbnRhdGlvbiBVUkw6IGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy8N CkQzMjUwNQ0KDQpMaW51eCBwcm92aWRlcyBhIHNldCBvZiBzeXNjYWxscyB0aGF0IGFsbG93IHRv IGRldmVsb3AgbW9zdGx5IHN5c2NhbGwtbGVzcw0Kc2NhbGFibGUgYWxnb3JpdGhtcyBpbiB1c2Vy c3BhY2UuIFRoZSBtZWNoYW5pc21zIGFyZSBiYXNlZCBvbiBvcHRpbWlzdGljDQpleGVjdXRpb24g dXNpbmcgQ1BVLWxvY2FsIGRhdGEgd2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0IHJhcmUgZXZlbnRz IGxpa2UNCmNvbnRleHQgc3dpdGNoZXMgb3Igc2lnbmFsIGRlbGl2ZXJ5IGRvIG5vdCBvY2N1ciBm b3IgdGhlIGdpdmVuIGNhbGN1bGF0aW9uLCBhbmQNCmlmIHRoZXkgZG8gb2NjdXIsIHJvbGxiYWNr IGFuZCByZXN0YXJ0IGlzIHBlcmZvcm1lZC4gVGhpcyB2ZXJ5IGhpZ2gtbGV2ZWwNCmFwcHJvYWNo IGlzIHVzZWQsIGFzIEkgdW5kZXJzdGFuZCwgZm9yIGltcGxlbWVudGF0aW9uIG9mIHRvb2xzIGxp a2UgVVJDVSwgZmFzdA0KbWFsbG9jIGFsbG9jYXRvcnMgKHRjbWFsbG9jKSBhbmQgb3RoZXIgdXNl cnNwYWNlIGluZnJhc3RydWN0dXJlIHByb2plY3RzIGFpbWVkDQphdCBsYXJnZSBwYXJ0aXRpb25l ZCBtYWNoaW5lcy4NCg0KRm9yIGluc3RhbmNlLCBzY2hlZF9nZXRjcHUoMikgc3lzY2FsbCByZXR1 cm5zIHRoZSBDUFUgaWQgb2YgdGhlIENQVSB3aGVyZSB0aGUNCmN1cnJlbnQgdGhyZWFkIGlzIGN1 cnJlbnRseSBleGVjdXRpbmcuIE9uIGFtZDY0LCBpZiBhdmFpbGFibGUsIHdlIHVzZSBhIFJEVFND UA0Kb3IgUkRQSUQgaW5zdHJ1Y3Rpb24gdG8gcXVlcnkgdGhlIENQVSBpZCB3aXRob3V0IGNoYW5n aW5nIENQVSBtb2RlLCBvdGhlcndpc2UNCnRoaXMgaXMgYSBsaWdodC13ZWlnaHQgc3lzY2FsbC4g T2YgY291cnNlLCB0aGUgYW5zd2VyIHByb3ZpZGVkIGlzIG9ic29sZXRlIHRoZQ0KbW9tZW50IGl0 IGlzIGNyZWF0ZWQsIGV2ZW4gYmVmb3JlIGl0IGlzIHJldHVybmVkIHRvIHVzZXJzcGFjZS4gQnV0 IGl0IGFsbG93cw0Kc2VlZGluZyB2YWx1ZXMgaW4gc29tZSBzdHJ1Y3R1cmVzIHRoYXQgYXJlIHZh bGlkIGZvciBhIGxvbmcgdGltZSAoYXQgdGhlIENQVQ0Kc3BlZWQgc2NhbGUpIGFuZCBhcmUgYXV0 b21hdGljYWxseSBjb3JyZWN0ZWQgb24gZXhjZXB0aW9uYWwgY29udHJvbCBmbG93IGV2ZW50cw0K bGlrZSBjb250ZXh0IHN3aXRjaGVzLCBhbmQgdXNlcnNwYWNlIGNhbiBlaXRoZXIgZGV0ZWN0IGFu ZCByb2xsYmFjayBvciBzeW5jIGFuZA0Kcm9sbGJhY2sgd2l0aCB0aGUgZXhjZXB0aW9ucy4NCg0K VGhlcmUgYXJlIHR3byBjb3JuZXJzdG9uZSBzeXNjYWxscyB0aGF0IGFsbG93IHVzZXJzcGFjZSB0 byBpbXBsZW1lbnQgdGhlc2UNCmVmZmljaWVudCBhbGdvcml0aG1zOiBtZW1iYXJyaWVyKDIpIGFu ZCByc2VxKDIpLg0KDQpNZW1iYXJyaWVyIGlzIGEgZmFjaWxpdHkgdGhhdCBoZWxwcyBpbXBsZW1l bnRpbmcgZmFzdCBDUFUgb3JkZXJpbmcgYmFycmllcnMsDQp0eXBpY2FsbHkgdXNlZCBmb3IgYXN5 bW1ldHJpYy9iaWFzZWQgbG9ja2luZy4gSW4gdGhlc2UgbG9jayBpbXBsZW1lbnRhdGlvbg0Kc2No ZW1lcywgdGhlIG93bmVyIG9mIHRoZSBvYmplY3Qgb2Z0ZW4gYXNzdW1lcyB0aGF0IHRoZXJlIGFy ZSBjb250ZW5kZXJzLw0KcGFyYWxsZWwgdGhyZWFkcyB0aGF0IG5lZWQgY29vcmRpbmF0aW5nIHdp dGguIElmIHNvbWUgdGhyZWFkIHN0YXJ0cyBhY2Nlc3NpbmcNCnRoZSBzYW1lIHJlc291cmNlLCB0 aGVuIGl0IGlzIGl0cyBkdXR5IHRvIGVuc3VyZSBjb3JyZWN0bmVzcy4gRXhhbXBsZXMgb2YNCid0 cmFwcycgdGhhdCBmYXN0IGNvZGUgcGF0aCB1dGlsaXplIGFyZSByZWFkcyBmcm9tIGEgZGVkaWNh dGVkIHBhZ2UgdGhhdCBpcw0KdW5tYXBwZWQgYnkgY29udGVuZGVycywgdG8gc3dpdGNoIHRoZSBm YXN0IHBhdGggdG8gdGhlIHNsb3cgb25lLiBPciB3ZSBjb3VsZA0Kc2VuZCBhIHNpZ25hbCB0byBh bGwgdGhyZWFkcyB0aGF0IHBvdGVudGlhbGx5IGhhdmUgYWNjZXNzIHRvIHRoYXQgb2JqZWN0LCB0 bw0KaW5zZXJ0IGEgYmFycmllci4gT3Igd2UgY2FuIHVzZSB0aGUgbWVtYmFycmllcigyKSBmYWNp bGl0eSwgd2hpY2ggaW5jdXJzDQpzaWduaWZpY2FudGx5IGxlc3Mgb3ZlcmhlYWQgdGhhbiBzaWdu YWxsaW5nIGFsbCB0aHJlYWRzLg0KDQpNZW1iYXJyaWVyKDIpIGluc2VydHMgYSBiYXJyaWVyLCB3 aGljaCBpcyB0aGUgdHlwaWNhbCB1bmRlcmx5aW5nIGhhcmR3YXJlDQpvcGVyYXRpb24gdG8gZW5z dXJlIG9yZGVyaW5nLCBpbnRvIHRoZSBzcGVjaWZpZWQgc2V0IG9mIENQVXMsIGlmIHRoZXNlIENQ VXMgYXJlDQpleGVjdXRpbmcgdGhlIHNwZWNpZmllZCB0aHJlYWQuIElmIHRoZXNlIENQVXMgYXJl IG5vdCBleGVjdXRpbmcgdGhlIHRhcmdldGVkDQp0aHJlYWRzLCBpdCBpcyBhc3N1bWVkIHRoYXQg c2VxdWVudGlhbCBjb25zaXN0ZW5jeSBndWFyYW50ZWVzIGZyb20gdGhlIGNvbnRleHQNCnN3aXRj aCBhcmUgZW5vdWdoIHRvIGZ1bGZpbGwgdGhlIHJlcXVpcmVtZW50IG9mIG1lbWJhcnJpZXIoMiku IE92ZXJhbGwsIHRoZQ0KZmFzdCBwYXRoIGNhbiBiZSBpbXBsZW1lbnRlZCB3aXRob3V0IHNsb3cg aW5zdHJ1Y3Rpb25zLCBhbmQgdGhlIHNsb3cgcGF0aA0KaW5qZWN0cyByZXF1aXJlZCBmZW5jZXMg aW50byB0aGUgZmFzdCBwYXRoIGF0IHRoZSBjb3N0IG9mIElQSS4NCg0KVGhlIGZhY2lsaXR5IHRv IGRldGVjdCBleGNlcHRpb25hbCBjb25kaXRpb25zIGluIHRoZSB1c2Vyc3BhY2UgdGhyZWFkIGV4 ZWN1dGlvbg0Kd2FzIGRldmVsb3BlZCBpbiBMaW51eCBhbmQgY2FsbGVkIHJzZXEoMikuIEl0IGlz IGEgZmVhdHVyZSBvZnRlbiBjYWxsZWQNClJlc3RhcnRhYmxlIEF0b21pYyBTZXF1ZW5jZXMsIHdo aWNoIGV4cGxhaW5zIHRoZSBhY3JvbnltLiBUaGUgYWJpbGl0eSB0bw0KY2hlYXBseSBkbyB0aGF0 IGFsbG93cyBjb2RlIGxvbmdlciB0aGFuIGEgc2luZ2xlIGluc3RydWN0aW9uIHRvIGV4ZWN1dGUN CmF0b21pY2FsbHksIHdpdGhvdXQgdGhlIG5lZWQgdG8gcHJvcG9zZSBhbmQgaW1wbGVtZW50IHVu c2FmZSBvcGVyYXRpb25zIGxpa2UNCmRpc2FibGluZyBwcmVlbXB0aW9uLCB3aGljaCBpcyBub3Qg ZmVhc2libGUgZm9yIHVzZXJzcGFjZS4gRm9yIGluc3RhbmNlLCBjb2RlDQptaWdodCB1c2UgQ1BV LWxvY2FsIHJlc291cmNlcywgd2hpY2ggb3RoZXJ3aXNlIGRvZXMgbm90IGNvcGUgd2VsbCB3aXRo IGNvbnRleHQNCnN3aXRjaGVzLiBUaGVyZSBjYW5ub3QgYmUgYW4gYW5hbG9nIG9mIGNyaXRpY2Fs X2VudGVyKDkpIGluIHVzZXJzcGFjZS4gKEENCmZhY2lsaXR5IHRvIGNoZWFwbHkgYmxvY2sgc2ln bmFsIGRlbGl2ZXJ5IGV4aXN0cyBpbiBGcmVlQlNELCBzZWUgc2lnZmFzdGJsb2NrDQooMiksIGJ1 dCBjb3JyZWN0bHkgdXNpbmcgaXQgaXMgcHJvdmFibHkgdG9vIGhhcmQgdG8gaW1wbGVtZW50IGlu DQpnZW5lcmFsLXB1cnBvc2UgY29kZSwgZXNwLiBiZWNhdXNlIGl0IHJlcXVpcmVzIHZlcnNpb24t ZGVwZW5kZW50IGNvb3JkaW5hdGlvbg0Kd2l0aCBydGRsIGFuZCBsaWJ0aHIuKQ0KDQpyc2VxKDIp IHRha2VzIHBlci10aHJlYWQgYmxvY2sgb2YgbWVtb3J5LCB3aGVyZSB0aGUgdGhyZWFkIHdyaXRl cyB0aGUgY3VycmVudA0KQ1BVIGlkIChzZWUgc2NoZWRfZ2V0Y3B1KDIpKSBhbmQgc3BlY2lmaWVz IHRoZSBibG9jayBvZiBjcml0aWNhbCBjb2RlIHRoYXQgbXVzdA0KYmUgdW53b3VuZCBpZiBhbiBl eGNlcHRpb25hbCBzaXR1YXRpb24gbGlrZSBhIGNvbnRleHQgc3dpdGNoIG9jY3VycmVkIHdoaWxl IHRoZQ0KYmxvY2sgd2FzIGV4ZWN1dGluZy4gVGhlIGZhc3QgY29kZSBwYXRoIHVzZXMgcGVyLWNw dSBkYXRhIGFuZCB0eXBpY2FsbHkgZG9lcw0Kbm90IG5lZWQgYW55IGNvcnJlY3Rpb25zLCBidXQg d291bGQgYSBjb250ZXh0IHN3aXRjaCBvY2N1ciwgdHJhbnNmZXIgb2YgY29udHJvbA0KdG8gdGhl IGFib3J0IGhhbmRsZXIgaW5mb3JtcyB1c2Vyc3BhY2UgYWJvdXQgdGhlIGV2ZW50LiBTbyBpbnN0 ZWFkIG9mIGRpc2FibGluZw0KY29udGV4dCBzd2l0Y2hlcywgY29kZSBjYW4gY2hlYXBseSBjaGVj ayBmb3Igb25lIGFmdGVyIHRoZSBjYWxjdWxhdGlvbiBhbmQNCnJldHJ5IGlmIG5lZWRlZC4NCg0K QW4gaW50ZXJlc3RpbmcgcnNlcSgyKSBpbXBsZW1lbnRhdGlvbiBkZXRhaWwgaXMgdGhhdCBpdCBp cyBpbXBvc3NpYmxlIChhbmQgbm90DQpuZWVkZWQpIHRvIGFjY2Vzcy91cGRhdGUgcnNlcSBzdHJ1 Y3R1cmVzIGZyb20ga2VybmVsIGR1cmluZyB0aGUgYWN0dWFsIGNvbnRleHQNCnN3aXRjaCwgYmVj YXVzZSB3ZSBjYW5ub3QgYWNjZXNzIHVzZXJzcGFjZSBmcm9tIHVuZGVyIGEgc3BpbmxvY2suIElu IG90aGVyDQp3b3JkcywgdGhyZWFkcyB1c2luZyByc2VxIGRvIG5vdCBpbmN1ciBhbnkgcGVyZm9y bWFuY2UgY29zdCBmcm9tIHN5c3RlbS1nbG9iYWwNCmNvbnRleHQgc3dpdGNoZXMuIEluc3RlYWQs IGlmIHRoZSBwcm9jZXNzIHJlZ2lzdGVyZWQgZm9yIHJzZXEoMiksIG9uIGFueSByZXR1cm4NCnRv IHVzZXIgbW9kZSB3ZSBjaGVjayBpZiBhbnkgZXhjZXB0aW9uYWwgZXZlbnRzIGhhcHBlbmVkIHdo aWxlIHRoZSB0aHJlYWQgd2FzDQppbiB0aGUga2VybmVsIChjb250ZXh0IHN3aXRjaGVzIG1heSBo YXBwZW4gb25seSB3aGlsZSB0aGUgdGhyZWFkIGlzIGluIGtlcm5lbA0KbW9kZSksIGFuZCBpZiBh IGNvbnRleHQgc3dpdGNoIGluZGVlZCBvY2N1cmVkLCB3ZSBmaXJlIGFuIGFzdCB0byBjaGVjayB3 aGV0aGVyDQp0aGUgcHJvZ3JhbSBjb3VudGVyIGlzIGluc2lkZSB0aGUgY3JpdGljYWwgc2VjdGlv biBhbmQganVtcCB0byB0aGUgYWJvcnQNCmhhbmRsZXIgaWYgaXQgaXMuDQoNClRoZSBpbXBsZW1l bnRhdGlvbnMgb2YgbWVtYmFycmllcigyKSBhbmQgcnNlcSgyKSBhcmUgY2xlYW4tcm9vbTogSSB1 c2VkIExpbnV4DQptYW51YWwgcGFnZXMgYXMgdGhlIHJlZmVyZW5jZSBhbmQgcHVibGljIGRpc2N1 c3Npb25zIG9mIHRoZSBmZWF0dXJlcyBmb3INCmNsYXJpZnlpbmcgY29ybmVyIGNhc2VzLiBPbiBM aW51eC9nbGliYywgdGhlcmUgd2FzIG5vIHN0YWJsZSBnbGliYyBpbnRlcmZhY2UgdG8NCnRoZSBy c2VxIGZhY2lsaXR5LiBPbmUgcHJvcG9zZWQgaW50ZWdyYXRpb24gd2FzIGNvbW1pdHRlZCB0aGVu IHJldmVydGVkIGZyb20NCmdsaWJjLiBJdCBtaWdodCBiZSBwcnVkZW50IHRvIHdhaXQgc29tZSBt b3JlIGZvciB0aGUgcnNlcSgyKSBpbnRlcmZhY2UgdG8NCnN0YWJpbGl6ZSBpbiBnbGliYyBiZWZv cmUgcHJvdmlkaW5nIGl0IGluIG91ciBsaWJjIG9yIHRvIHJlbHkgb24gdGlnaHQNCmludGVncmF0 aW9uIGJldHdlZW4ga2VybmVsIGFuZCB1c2Vyc3BhY2UgaW4gb3VyIGJhc2Ugc3lzdGVtLCBhbmQg dXNlIEFCSSB0cmlja3MNCmxpa2Ugc3ltYm9sIHZlcnNpb25pbmcgdG8gZXZvbHZlIHRoZSBpbnRl cmZhY2UuIFRoZXJlIGlzIG5vIGdvYWwgdG8gYmUgMTAwJQ0KY29tcGF0aWJsZSB3aXRoIExpbnV4 IGFueXdheS4NCg0KU3BvbnNvcjogVGhlIEZyZWVCU0QgRm91bmRhdGlvbg0KDQrilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIEN Cg0KQmFzZSBTeXN0ZW0gT3BlblNTSCBVcGRhdGUNCg0KTGlua3M6DQpPcGVuU1NIIFVSTDogaHR0 cHM6Ly93d3cub3BlbnNzaC5jb20vDQpBbm5vdW5jZW1lbnQgdG8gZnJlZWJzZC1zZWN1cml0eUAg VVJMOiBodHRwczovL2xpc3RzLmZyZWVic2Qub3JnL3BpcGVybWFpbC8NCmZyZWVic2Qtc2VjdXJp dHkvMjAyMS1TZXB0ZW1iZXIvMDEwNDczLmh0bWwNCg0KQ29udGFjdDogRWQgTWFzdGUgPGVtYXN0 ZUBmcmVlYnNkLm9yZz4NCg0KT3BlblNTSCwgYSBzdWl0ZSBvZiByZW1vdGUgbG9naW4gYW5kIGZp bGUgdHJhbnNmZXIgdG9vbHMsIHdhcyB1cGRhdGVkIGZyb20NCnZlcnNpb24gOC43cDEgdG8gOC44 cDEgaW4gdGhlIEZyZWVCU0QgYmFzZSBzeXN0ZW0uDQoNCk5PVEU6IE9wZW5TU0ggOC44cDEgZGlz YWJsZXMgdGhlIHNzaC1yc2Egc2lnbmF0dXJlIHNjaGVtZSBieSBkZWZhdWx0LiBGb3IgbW9yZQ0K aW5mb3JtYXRpb24gcGxlYXNlIHNlZSB0aGUgSW1wb3J0YW50IG5vdGUgZm9yIGZ1dHVyZSBGcmVl QlNEIGJhc2Ugc3lzdGVtDQpPcGVuU1NIIHVwZGF0ZSBtYWlsaW5nIGxpc3QgcG9zdC4NCg0KT3Bl blNTSCBzdXBwb3J0cyBGSURPL1UyRiBkZXZpY2VzLCBhbmQgc3VwcG9ydCBpcyBub3cgZW5hYmxl ZCBpbiB0aGUgYmFzZQ0Kc3lzdGVtLg0KDQpOZXh0IHN0ZXBzIGluY2x1ZGUgaW50ZWdyYXRpbmcg VTJGIGtleSBkZXZkIHJ1bGVzIGludG8gdGhlIGJhc2Ugc3lzdGVtLCBhbmQNCm1lcmdpbmcgdGhl IHVwZGF0ZWQgT3BlblNTSCBhbmQgRklETy9VMkYgc3VwcG9ydCB0byBzdGFibGUgYnJhbmNoZXMu DQoNClNwb25zb3I6IFRoZSBGcmVlQlNEIEZvdW5kYXRpb24NCg0K4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSBDQoNClZEU08g b24gYW1kNjQNCg0KQ29udGFjdDogS29uc3RhbnRpbiBCZWxvdXNvdiA8a2liQEZyZWVCU0Qub3Jn Pg0KDQpBIFZEU08sIG9yIFZpcnR1YWwgRHluYW1pYyBTaGFyZWQgT2JqZWN0LCBpcyBhIHNoYXJl ZCBvYmplY3QgKG1vcmUgY29tbW9ubHkNCmNhbGxlZCBkeW5hbWljIGxpYnJhcnkpIHRoYXQgaXMg aW5zZXJ0ZWQgaW50byB0aGUgZXhlY3V0ZWQgaW1hZ2UgYnkgYSBqb2ludA0KZWZmb3J0IG9mIHRo ZSBrZXJuZWwgYW5kIHRoZSBkeW5hbWljIGxpbmtlci4gSXQgZG9lcyBub3QgZXhpc3RzIG9uIGRp c2sgYXMgYQ0Kc3RhbmRhbG9uZSAuc28sIGFuZCB0aGVyZSBhcmUgbm8gaW5zdHJ1Y3Rpb25zIGlu IHRoZSBFTEYgZm9ybWF0IHRoYXQgY2F1c2UgdGhlDQppbnNlcnRpb24uIEl0IGlzIGRvbmUgYnkg dGhlIHN5c3RlbSB0byBpbXBsZW1lbnQgc29tZSBmdW5jdGlvbmFsaXR5IGZvciB0aGUgQw0KcnVu dGltZSBpbXBsZW1lbnRhdGlvbiBjb21wb25lbnRzLg0KDQpGcmVlQlNEIGFscmVhZHkgaGFzIGEg bG90IG9mIGZlYXR1cmVzIHR5cGljYWxseSBkb25lIHVzaW5nIFZEU08gKGluIExpbnV4KSwgYnV0 DQpyZWFsbHkgbm90IHJlcXVpcmluZyB0aGF0IGNvbXBsaWNhdGlvbi4gVGhlIG1haW4gcmVhc29u IHdoeSBpdCBpcyBwb3NzaWJsZSBpcw0KdGhlIG9mdGVuIG1lbnRpb25lZCBjby1ldm9sdXRpb24g b2YgdGhlIGtlcm5lbCBhbmQgQyBydW50aW1lLiBXZSBjYW4gbmF0dXJhbGx5DQppbnRyb2R1Y2Ug ZmVhdHVyZXMgdGhhdCByZXF1aXJlIGltcGxlbWVudGF0aW9uIGJvdGggaW4ga2VybmVsLCBhbmQg c3VwcG9ydCBpbg0KdGhlIHVzZXJzcGFjZSBwYXJ0cywgc2luY2UgRnJlZUJTRCBpcyBkZXZlbG9w ZWQgYXMgYSB3aG9sZS4gU3VycHJpc2luZ2x5LCBpdA0KYWxzbyBhbGxvd3MgdGhlIGtlcm5lbCBh bmQgZHluYW1pYyBsaW5rZXIgdG8ga25vdyBtdWNoIGxlc3MgKGFuZCBub3QgZW5mb3JjZQ0KYW55 dGhpbmcpIGFib3V0IHVzZXJzcGFjZSBjb25zdW1lcnMgb2YgaW50ZXJmYWNlcy4NCg0KRm9yIGlu c3RhbmNlLCBhIHN5c2NhbGwtbGVzcyB3YWxsIGNsb2NrIHdhcyBpbXBsZW1lbnRlZCBsb25nIGFn bywgYnkgdGhlIGtlcm5lbA0KcHJvdmlkaW5nIGEgdGltZSBoYW5kcyBibG9iIGluIHRoZSBzaGFy ZWQgcGFnZSwgYW5kIHRoZSBDIGxpYnJhcnkga25vd2luZyBhYm91dA0KaXRzIGxvY2F0aW9uIGFu ZCB0aGUgc3VwcG9ydGVkIGFsZ29yaXRobXMuIFRoZXJlIGlzIG5vIG5lZWQgZm9yIGEgVkRTTyB0 aGF0DQppbnRlcnBvc2VzIHNvbWUgbGliYyBzeW1ib2xzIG9yIHByb3ZpZGVzIHNlcnZpY2VzIHRo YXQgYXJlIG5hbWVkIGJ5IGtub3duDQpzeW1ib2xzIHRvIHVzZXJsYW5kLg0KDQpGcm9tIGFsbCB0 aGUgeWVhcnMgb2YgZXhwZXJpZW5jZSB3aXRoIHRoaXMgcHNldWRvLVZEU08gYXBwcm9hY2gsIHRo ZSBvbmx5DQpmZWF0dXJlIHRoYXQgd2FzIGltcG9zc2libGUgdG8gaW1wbGVtZW50IHdpdGhvdXQg cHJvdmlkaW5nIHJlYWwgVkRTTyBzdXBwb3J0DQp3YXMgdGhlIHNpZ25hbCB0cmFtcG9saW5lIERX QVJGIGFubm90YXRpb25zLCBmb3IgdGhlIGJlbmVmaXQgb2Ygc3RhY2sNCnVud2luZGVycy4NCg0K V2hlbiB0aGUga2VybmVsIGRlbGl2ZXJzIHNpZ25hbCB0byB1c2VybGFuZCwgaXQgY2hhbmdlcyBz b21lIGtleSByZWdpc3RlcnMNCihsaWtlIHRoZSBpbnN0cnVjdGlvbiBwb2ludGVyLCB0aGUgc3Rh Y2sgcG9pbnRlciwgYW5kIHdoYXRldmVyIGVsc2UgaXMgbmVlZGVkDQpieSB0aGUgYXJjaGl0ZWN0 dXJlKSBhbmQgcHVzaGVzIHRoZSBzYXZlZCBpbWFnZSBvZiB0aGUgd2hvbGUgdXNlcm1vZGUgQ1BV IHN0YXRlDQooY29udGV4dCkgb250byB0aGUgdXNlciBzdGFjay4gVGhlbiwgY29udHJvbCBpcyBw YXNzZWQgdG8gYSBzbWFsbCBwaWVjZSBvZiBjb2RlDQpsb2NhdGVkIGluIHRoZSBzaGFyZWQgcGFn ZSAoc2lnbmFsIHRyYW1wb2xpbmUpLCB3aGljaCBjYWxscyB0aGUgdXNlciBoYW5kbGVyDQpmdW5j dGlvbiBhbmQgb24gcmV0dXJuIGZyb20gdGhlIGhhbmRsZXIgaXNzdWVzIGEgc2lncmV0dXJuKDIp IHN5c2NhbGwgdG8gcmVsb2FkDQp0aGUgb2xkIGNvbnRleHQuDQoNCkZyb20gdGhpcyBkZXNjcmlw dGlvbiwgaXQgaXMgY2xlYXIgdGhhdCB0aGUgc3RhdGUgb2YgdGhlIG1hY2hpbmUgZHVyaW5nDQp0 cmFtcG9saW5lIGV4ZWN1dGlvbiBpcyBxdWl0ZSBkaWZmZXJlbnQgZnJvbSB0aGUgbm9ybWFsIEMg Y2FsbGluZyBmcmFtZXMuDQpVbndpbmRlcnMgdGhhdCBoYW5kbGUgdGhpbmdzIGxpa2UgQysrIGV4 Y2VwdGlvbnMsIFJ1c3QgcGFuaWNzLCBvciBvdGhlciBzaW1pbGFyDQptZWNoYW5pc21zIGluIHNw ZWNpZmljIGxhbmd1YWdlIHJ1bnRpbWVzLCBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIHNwZWNpYWxu ZXNzIG9mDQp0aGUgdHJhbXBvbGluZSBmcmFtZS4gVGhlIGN1cnJlbnQgYXBwcm9hY2ggaXMgdG8g aGFyZGNvZGUgdGhlIGRldGVjdGlvbiBvZiB0aGUNCnRyYW1wb2xpbmUsIGUuZy4gYnkgbWF0Y2hp bmcgdGhlIGluc3RydWN0aW9uIHBvaW50ZXIgYWdhaW5zdCBzeXNjdGwNCmtlcm4ucHJvYy5zaWd0 cmFtcC4NCg0KRFdBUkYgYW5ub3RhdGlvbnMgYXJlIGVub3VnaCB0byBwcm92aWRlIHRoZSByZXF1 aXJlZCBpbmZvcm1hdGlvbiB0byB1bndpbmRlcnMNCnRvIG1ha2UgdGhlIHRyYW1wb2xpbmUgZnJh bWUgbm90IHNwZWNpYWwgYW55bW9yZSwgYnV0IHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlcmUNCmlz IG5vIHdheSBmb3IgdW53aW5kZXJzIHRvIGZpbmQgdGhlIGFubm90YXRpb24gd2l0aG91dCBpbnRy b2R1Y2luZyBldmVuIG1vcmUNCnNwZWNpYWxuZXNzLiBJbnN0ZWFkLCB3ZSBjYW4gaW5zZXJ0IGEg VkRTTyB0aGF0IG9ubHkgc2VydmVzIHRvIGFwcGVhciBpbiB0aGUNCmVudW1lcmF0aW9uIG9mIERT T3MgbG9hZGVkIGludG8gdGhlIHByb2Nlc3MsIHdpdGggZWl0aGVyIGRsX2l0ZXJhdGVfcGhkcigz KQ0KKGluLXByb2Nlc3MpIG9yIHJfZGVidWcgKHJlbW90ZSksIHdpdGggUFRfR05VX0VIX0ZSQU1F IGhlYWRlciBwb2ludGluZyB0byB0aGUNCnJvb3Qgb2YgRFdBUkYgaW5mby4NCg0KVGhpcyBpcyBl eGFjdGx5IHdoYXQgdGhlIFZEU08gb24gRnJlZUJTRCBkb2VzOiBpdCB3cmFwcyBzaWduYWwgdHJh bXBvbGluZSBiaXRzDQphbmQgdGhlaXIgRFdBUkYgYW5ub3RhdGlvbiAoLmNmaSkgaW50byBhIHNo YXJlZCBvYmplY3QsIHdoaWNoIGlzIHB1dCBpbnRvIHRoZQ0Kc2hhcmVkIHBhZ2UgYW5kIGxpbmtl ZCBieSBydGxkKDEpIGludG8gdGhlIHNldCBvZiBwcmVsb2FkZWQgb2JqZWN0cyB1cG9uIGltYWdl DQphY3RpdmF0aW9uLg0KDQpFZmZvcnRzIHdlcmUgbWFkZSB0byBzdHJpcCBhcyBtYW55IHVubmVl ZGVkIHN0cnVjdHVyZXMgYW5kIGFzIG11Y2ggcGFkZGluZyBhcw0KcG9zc2libGUgZnJvbSB0aGUg VkRTTyBpbWFnZSwgYmVjYXVzZSBpdCBjb25zdW1lcyBzcGFjZSBpbiB0aGUgc2hhcmVkIHBhZ2Uu IEl0DQp3YXMgcHVzaGVkIGFzIGZhciBhcyB0aGUgY29tbW9uIGRlbm9taW5hdG9yIG9mIGxsZCBh bmQgbGQuYmZkIGFsbG93ZWQsIHdpdGgNCnNldmVyYWwgdHJpY2tzIGRvbmUgYnkgbGlua2VyIHNj cmlwdHMgYW5kIHNvbWUgdXNlIG9mIHNlZW1pbmdseSB1bmRvY3VtZW50ZWQNCmxpbmtlciBvcHRp b25zLg0KDQpXZSBuZWVkIGF0IGxlYXN0IHR3byBWRFNPcyBmb3IgYW1kNjQ6IGEgNjQtYml0IG9u ZSBmb3IgbmF0aXZlIGJpbmFyaWVzIGFuZCBhDQozMi1iaXQgb25lIGZvciBpYTMyIGJpbmFyaWVz LiBXaXRoIHRoZSBzaXplIG9mIGVhY2ggVkRTTyBhcm91bmQgMS41S0IsIHNwYWNlDQpiZWNvbWVz IHJlYWxseSB0aWdodCBpbiB0aGUgc2hhcmVkIHBhZ2UsIHdoaWNoIG5lZWRzIHNwYWNlIGZvciBv dGhlciBzdHVmZiBhcw0Kd2VsbCwgbGlrZSB0aW1laGFuZHMgb3IgcmFuZG9tIGdlbmVyYXRvciBz ZWVkcy4NCg0KQnVpbGQgc2NyaXB0cyBlbmZvcmNlIHRoYXQgVkRTT3MgZG8gbm90IGdyb3cgbGFy Z2VyIHRoYW4gMks7IGlmIHRoZXkgZG8sIHdlDQpuZWVkIHRvIGV4dGVuZCBzaGFyZWQgcGFnZSB0 byBiZWNvbWUgYXQgbGVhc3QgdHdvIHNoYXJlZCBwYWdlcy4gU2NyaXB0cyBhbHNvDQplbmZvcmNl IHRoYXQgVkRTTyBhcmUgcHVyZSBwb3NpdGlvbi1pbmRlcGVuZGVudCwgbm90IHJlcXVpcmluZyBy ZWxvY2F0aW9ucyBmb3INCmVpdGhlciBjb2RlIG9yIG1ldGFkYXRhICguY2ZpKS4NCg0KU3BvbnNv cjogVGhlIEZyZWVCU0QgRm91bmRhdGlvbg0KDQrilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIENCg0KS2VybmVsDQoNClVwZGF0 ZXMgdG8ga2VybmVsIHN1YnN5c3RlbXMvZmVhdHVyZXMsIGRyaXZlciBzdXBwb3J0LCBmaWxlc3lz dGVtcywgYW5kIG1vcmUuDQoNClRoZSBBVlggYnVnIG9uIGFtZDY0DQoNCkNvbW1pdDogNzNiMzU3 YmU5MjM4IFVSTDogaHR0cHM6Ly9jZ2l0LmZyZWVic2Qub3JnL3NyYy9jb21taXQvP2lkPQ0KNzNi MzU3YmU5MjM4NWNiYjcwYmExOWU3MDIzYTczNmFmMmM2YjQ5Mw0KDQpDb250YWN0OiBLb25zdGFu dGluIEJlbG91c292IDxraWJARnJlZUJTRC5vcmc+DQoNClNvbWUgQ1BVcyBzdXBwb3J0IHRoZSBz byBjYWxsZWQgaW5pdCBvcHRpbWl6YXRpb24gZm9yIFhTQVZFLCBidXQgbm90IGFsbCBDUFVzDQpk by4gQW5kIHdoZW4gdGhleSBkbywgJ2FjY29yZGluZyB0byBjb21wbGV4IGludGVybmFsIG1pY3Jv YXJjaGl0ZWN0dXJhbA0KY29uZGl0aW9ucycsIHRoZSBvcHRpbWl6YXRpb24gbWlnaHQgaGFwcGVu IG9yIG5vdC4gQmFzaWNhbGx5LCB0aGlzIG1lYW5zIHRoYXQNCnNvbWV0aW1lcyB0aGUgQ1BVIGRv ZXMgbm90IHdyaXRlIGFsbCBvZiB0aGUgc3RhdGUgb24gWFNBVkUgYW5kIHJlY29yZHMgaW4NCnhz dGF0ZV9idiB0aGF0IGl0IGRpZCBub3QuDQoNCk9uIHNpZ25hbCBkZWxpdmVyeSwgdGhlIE9TIHBy b3ZpZGVzIHRoZSBzYXZlZCBjb250ZXh0IGludGVycnVwdGVkIGJ5IHRoZSBzaWduYWwNCnRvIHRo ZSBzaWduYWwgaGFuZGxlci4gVGhlIGNvbnRleHQgaW5jbHVkZXMgYWxsIENQVSBzdGF0ZSBhdmFp bGFibGUgdG8NCnVzZXJzcGFjZSwgaW5jbHVkaW5nIEZQVSByZWdpc3RlcnMgKFhTQVZFIGFyZWEp LiBBbHNvLCBvbiByZXR1cm4gZnJvbSB0aGUNCnNpZ25hbCBoYW5kbGVyLCBjb250ZXh0IGlzIHJl c3RvcmVkLCB3aGljaCBhbGxvd3MgdGhlIGhhbmRsZXIgdG8gbW9kaWZ5IHRoZQ0KbWFpbiBwcm9n cmFtIGZsb3cuIFdoZW4gaW5pdCBvcHRpbWl6YXRpb24ga2lja3MgaW4sIHRoZSBPUyB0cmllcyB0 byBoaWRlIGluaXQNCnN0YXRlIG9wdGltaXphdGlvbiBmcm9tIHRoZSBzaWduYWwgaGFuZGxlciwg YnkgZmlsbGluZyBub24tc2F2ZWQgcGFydHMgb2YgdGhlDQpYU0FWRSBhcmVhLg0KDQpUaGlzIGlz IHdoZXJlIHRoZSBwcm9ibGVtIGhhcHBlbnMuIEZvciBzdGF0ZXMgcGFydHMgMCAoeDg3KSBhbmQg MSAoU1NFL1hNTSksDQpJbnRlbCBDUFVzIGRvIG5vdCBwcm92aWRlIGFuIGVudW1lcmF0aW9uIG9m IGxheW91dCBpbiBDUFVJRCwgYXNzdW1pbmcgdGhhdCB0aGUNCk9TIGtub3dzIGFib3V0IHRoZSBy ZWdpb25zIGFueXdheS4gVGhlIGJ1ZyB3YXMgdGhhdCB0aGUgYW1kNjQga2VybmVsIGhhcmRjb2Rl ZA0KYSAzMmJpdCBzaXplIGZvciB0aGUgWE1NIHNhdmUgYXJlYSwgZWZmZWN0aXZlbHkgZmlsbGlu ZyAlWE1NOC0lWE1NMTUgd2l0aA0KZ2FyYmFnZSBvbiBzaWduYWwgcmV0dXJuIHdoZW4gaW5pdCBv cHRpbWl6YXRpb24ga2lja2VkIGluLCBiZWNhdXNlIG9ubHkNCnNwZWNpZmllZCBwYXJ0IG9mIHRo ZSBTU0Ugc2F2ZSBhcmVhIHdhcyBjb3BpZWQgZnJvbSB0aGUgY2Fub25pY2FsIHNhdmUgYXJlYS4N Cg0KU3BvbnNvcjogVGhlIEZyZWVCU0QgRm91bmRhdGlvbg0KDQrilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIENCg0KRU5BIEZy ZWVCU0QgRHJpdmVyIFVwZGF0ZQ0KDQpMaW5rczoNCkVOQSBSRUFETUUgVVJMOiBodHRwczovL2dp dGh1Yi5jb20vYW16bi9hbXpuLWRyaXZlcnMvYmxvYi9tYXN0ZXIva2VybmVsL2Zic2QvDQplbmEv UkVBRE1FDQoNCkNvbnRhY3Q6IE1pY2hhbCBLcmF3Y3p5ayA8bWtAc2VtaWhhbGYuY29tPg0KQ29u dGFjdDogRGF3aWQgR29yZWNraSA8ZGdyQHNlbWloYWxmLmNvbT4NCkNvbnRhY3Q6IE1hcmNpbiBX b2p0YXMgPG13QHNlbWloYWxmLmNvbT4NCg0KRU5BIChFbGFzdGljIE5ldHdvcmsgQWRhcHRlcikg aXMgdGhlIHNtYXJ0IE5JQyBhdmFpbGFibGUgaW4gdGhlIHZpcnR1YWxpemVkDQplbnZpcm9ubWVu dCBvZiBBbWF6b24gV2ViIFNlcnZpY2VzIChBV1MpLiBUaGUgRU5BIGRyaXZlciBzdXBwb3J0cyBt dWx0aXBsZQ0KdHJhbnNtaXQgYW5kIHJlY2VpdmUgcXVldWVzIGFuZCBjYW4gaGFuZGxlIHVwIHRv IDEwMCBHYi9zIG9mIG5ldHdvcmsgdHJhZmZpYywNCmRlcGVuZGluZyBvbiB0aGUgaW5zdGFuY2Ug dHlwZSBvbiB3aGljaCBpdCBpcyB1c2VkLg0KDQpDb21wbGV0ZWQgc2luY2UgdGhlIGxhc3QgdXBk YXRlOg0KDQogIOKAoiBBZGQgSVB2NiBsYXllciA0IGNoZWNrc3VtIG9mZmxvYWQgc3VwcG9ydCB0 byB0aGUgZHJpdmVyDQoNCiAg4oCiIEFkZCBOVU1BIGF3YXJlbmVzcyB0byB0aGUgZHJpdmVyIHdo ZW4gdGhlIFJTUyBrZXJuZWwgb3B0aW9uIGlzIGVuYWJsZWQNCg0KICDigKIgUmV3b3JrIHZhbGlk YXRpb24gb2YgdGhlIFR4IHJlcXVlc3QgSUQNCg0KICDigKIgQ2hhbmdlIGxpZmV0aW1lIG9mIHRo ZSBkcml2ZXLigJlzIHRpbWVyIHNlcnZpY2UNCg0KICDigKIgQXZvaWQgcmVzZXQgdHJpZ2dlcmlu ZyB3aGVuIHRoZSBkZXZpY2UgaXMgdW5yZXNwb25zaXZlDQoNCldvcmsgaW4gcHJvZ3Jlc3M6DQoN CiAg4oCiIFByb3RvdHlwZSB0aGUgZHJpdmVyIHBvcnQgdG8gdGhlIGlmbGliIGZyYW1ld29yaw0K DQogIOKAoiBUZXN0cyBvZiB0aGUgaW5jb21pbmcgRU5BIGRyaXZlciByZWxlYXNlICh2Mi41LjAp DQoNClNwb25zb3I6IEFtYXpvbi5jb20gSW5jDQoNCuKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgQ0KDQpJbnRlbCBXaXJlbGVz cyBkcml2ZXIgc3VwcG9ydA0KDQpMaW5rczoNCml3bHdpZmkgc3RhdHVzIEZyZWVCU0Qgd2lraSBw YWdlIFVSTDogaHR0cHM6Ly93aWtpLmZyZWVic2Qub3JnL1dpRmkvSXdsd2lmaQ0KDQpDb250YWN0 OiBCam9lcm4gQS4gWmVlYiA8YnpARnJlZUJTRC5PUkc+DQoNClRoZSBJbnRlbCBXaXJlbGVzcyBk cml2ZXIgdXBkYXRlIHByb2plY3QgYWltcyB0byBicmluZyBzdXBwb3J0IGZvciBuZXdlcg0KY2hp cHNldHMgYWxvbmcgd2l0aCBtYWM4MDIxMSBMaW51eEtQSSBjb21wYXQgY29kZS4gVGhlIGR1YWwt bGljZW5zZWQgSW50ZWwNCmRyaXZlciBjb2RlIHdhcyBwb3J0ZWQgaW4gdGhlIHBhc3QgZm9yIHRo ZSBpd20oNCkgbmF0aXZlIGRyaXZlcjsgdXNpbmcgdGhlDQpMaW51eEtQSSBjb21wYXQgZnJhbWV3 b3JrIGFsbG93cyB1cyB0byB1c2UgdGhlIGRyaXZlciBkaXJlY3RseSwgd2l0aCBvbmx5IHZlcnkN Cm1pbm9yIG1vZGlmaWNhdGlvbnMgdGhhdCB3ZSBob3BlIHdpbGwgYmUgaW5jb3Jwb3JhdGVkIGlu dG8gdGhlIG9yaWdpbmFsIGRyaXZlci4NCg0KRHVyaW5nIERlY2VtYmVyIHRoZSBkcml2ZXIsIGZp cm13YXJlLCBhbmQgYWxsIHJlbWFpbmluZyBMaW51eEtQSSBjb21wYXRpYmlsaXR5DQpjb2RlIHdl cmUgY29tbWl0dGVkIHRvIEZyZWVCU0QgbWFpbiAoSEVBRCkgYW5kIG1lcmdlZCB0byB0aGUgc3Rh YmxlLzEzIGJyYW5jaC4NCkZ1cnRoZXIgZml4ZXMsIHVwZGF0ZXMsIGFuZCBpbXByb3ZlbWVudHMg d2lsbCBnbyBkaXJlY3RseSBpbnRvIEZyZWVCU0QsIG1lYW5pbmcNCnRoZSBuZWVkIHRvIGFwcGx5 IHNuYXBzaG90cyBpcyBnb25lIGFuZCBjaGFuZ2VzIGNhbiBiZSBkaXN0cmlidXRlZCBtb3JlIHRp bWVseS4NCg0KRHVyaW5nIHRoZSBsYXN0IG1vbnRocyB3ZSB0cmllZCB0byBlbnN1cmUgdGhhdCB0 aGUgbGF0ZXN0IEFYMjEwIGNoaXBzZXRzIGFyZQ0Kc3VwcG9ydGVkLiBUaGUgY29tcGF0IGNvZGUg d2FzIHJlc3RydWN0dXJlZCBib3RoIHRvIGJlIGFibGUgdG8gYmV0dGVyIHRyYWNlIGFuZA0KZGVi dWcgdGhlIG1hYzgwMjExIGNvbXBhdGliaWxpdHkgbGF5ZXIsIGJ1dCBhbHNvIHRvIGtlZXAgdGhl IG5ldDgwMjExIGFuZA0KbWFjODAyMTEgc3RhdGUgbWFjaGluZXMgZm9yIHN0YXRpb25zIGJldHRl ciBpbiBzeW5jLg0KDQpXaGlsZSB3ZSBrZWVwIHVwZGF0aW5nIHRoZSBkcml2ZXIgYW5kIGFsbCB0 aGUgY29tcGF0IGNvZGUgbmVlZGVkIGZvciB0aGF0LCB0aGUNCmZvY3VzIHJlbWFpbnMgb24gc3Rh YmlsaXR5IGFuZCBhZGRpbmcgc3VwcG9ydCBmb3IgbmV3ZXIgODAyLjExIHN0YW5kYXJkcy4gVGhl DQpkcml2ZXIgaXMgc3RpbGwgc2V0IHRvIDExYS9iL2ctb25seSBhbmQgMTFuIHdpbGwgYmUgbmV4 dCBiZWZvcmUgd2UgbG9vayBhdA0KMTFhYy4NCg0KV2l0aCB0aGUgY29kZSBpbiBGcmVlQlNEIGdp dCB3ZSBhbnRpY2lwYXRlIGJyb2FkZXIgdGVzdGluZyBhbmQgd2l0aCB0aGF0IGFsc28NCnNvbWUg ZmFsbG91dC4gRm9yIHRoZSBsYXRlc3Qgc3RhdGUgb2YgdGhlIGRldmVsb3BtZW50LCBwbGVhc2Ug Zm9sbG93IHRoZQ0KcmVmZXJlbmNlZCB3aWtpIHBhZ2UgYW5kIHRoZSBmcmVlYnNkLXdpcmVsZXNz IG1haWxpbmcgbGlzdC4NCg0KU3BvbnNvcjogVGhlIEZyZWVCU0QgRm91bmRhdGlvbg0KDQrilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIENCg0KS2VybmVsIENyeXB0byBjaGFuZ2VzIHRvIHN1cHBvcnQgV2lyZUd1YXJkDQoNCkNv bnRhY3Q6IEpvaG4gQmFsZHdpbiA8amhiQEZyZWVCU0Qub3JnPg0KDQpEdXJpbmcgdGhlIHBhc3Qg ZmV3IG1vbnRocywgSSBtZXJnZWQgc2V2ZXJhbCBjaGFuZ2VzIHRvIHRoZSBrZXJuZWwgdG8gYmV0 dGVyDQpzdXBwb3J0IHRoZSBXaXJlR3VhcmQgZHJpdmVyLiBUaGVzZSBpbmNsdWRlIGV4dGVuc2lv bnMgdG8gdGhlICdzdHJ1Y3QNCmVuY194Zm9ybScgaW50ZXJmYWNlIHRvIGJldHRlciBzdXBwb3J0 IEFFQUQgY2lwaGVycywgY2hhbmdlcyB0byAnc3RydWN0DQplbmNfeGZvcm0nIHRvIHN1cHBvcnQg bXVsdGktYmxvY2sgb3BlcmF0aW9ucyBmb3IgaW1wcm92ZWQgcGVyZm9ybWFuY2UsIGFuZCB0aGUN CmFkZGl0aW9uIG9mIHRoZSBYQ2hhQ2hhMjAtUG9seTEzMDUgQUVBRCBjaXBoZXIgc3VpdGUgdG8g T0NGLiBBZGRpdGlvbmFsbHksIHRoZQ0Ka2VybmVsIG5vdyBpbmNsdWRlcyBhIG5ldyAiZGlyZWN0 IiBBUEkgZm9yIENoYUNoYTIwLVBvbHkxMzA1IG9wZXJhdGlvbnMgb24NCnNtYWxsLCBmbGF0IGJ1 ZmZlcnMuIEEgY2hhbmdlIGluIHJldmlldyBhZGRzIGFuIEFQSSB0byBzdXBwb3J0IGN1cnZlMjU1 MTkNCm9wZXJhdGlvbnMuIFdpdGggdGhlc2UgY2hhbmdlcywgdGhlIFdpcmVHdWFyZCBkcml2ZXIg aXMgbW9zdGx5IGFibGUgdG8gdXNlDQpjcnlwdG8gQVBJcyBmcm9tIHRoZSBrZXJuZWwgcmF0aGVy IHRoYW4gaXRzIGludGVybmFsIGltcGxlbWVudGF0aW9ucy4NCg0KSW4gcGFyYWxsZWwgSSBoYXZl IGJlZW4gdXBkYXRpbmcgdGhlIFdpcmVHdWFyZCBkcml2ZXIgdG8gdXNlIHRoZSBuZXcgQVBJcw0K dmVyaWZ5aW5nIGludGVyb3BlcmFiaWxpdHkgd2l0aCB0aGUgZXhpc3RpbmcgZHJpdmVyLiBPbmUg b2YgdGhlIG5leHQgdGFza3MgaXMNCnRvIHJlZmluZSB0aGVzZSBjaGFuZ2VzIChhbG9uZyB3aXRo IHNvbWUgbWlub3IgYnVnIGZpeGVzKSBhcyBjYW5kaWRhdGVzIGZvcg0KdXBzdHJlYW1pbmcgaW50 byB0aGUgV2lyZUd1YXJkIGRyaXZlci4NCg0KU3BvbnNvcjogVGhlIEZyZWVCU0QgRm91bmRhdGlv bg0KDQrilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIENCg0KUG9ydHMNCg0KQ2hhbmdlcyBhZmZlY3RpbmcgdGhlIFBvcnRzIENv bGxlY3Rpb24sIHdoZXRoZXIgc3dlZXBpbmcgY2hhbmdlcyB0aGF0IHRvdWNoDQptb3N0IG9mIHRo ZSB0cmVlLCBvciBpbmRpdmlkdWFsIHBvcnRzIHRoZW1zZWx2ZXMuDQoNCktERSBvbiBGcmVlQlNE DQoNCkxpbmtzOg0KS0RFIEZyZWVCU0QgVVJMOiBodHRwczovL2ZyZWVic2Qua2RlLm9yZy8NCktE RSBDb21tdW5pdHkgRnJlZUJTRCBVUkw6IGh0dHBzOi8vY29tbXVuaXR5LmtkZS5vcmcvRnJlZUJT RA0KDQpDb250YWN0OiBBZHJpYWFuIGRlIEdyb290IDxrZGVARnJlZUJTRC5vcmc+DQoNClRoZSBL REUgb24gRnJlZUJTRCBwcm9qZWN0IGFpbXMgdG8gcGFja2FnZSB0aGUgc29mdHdhcmUgZnJvbSB0 aGUgS0RFIENvbW11bml0eSwNCmFsb25nIHdpdGggZGVwZW5kZW5jaWVzIGFuZCByZWxhdGVkIHNv ZnR3YXJlLCBmb3IgdGhlIEZyZWVCU0QgcG9ydHMgdHJlZS4gVGhhdA0KaW5jbHVkZXMgYSBmdWxs IGRlc2t0b3AgZW52aXJvbm1lbnQgY2FsbGVkIEtERSBQbGFzbWEgKGZvciBib3RoIFgxMSBhbmQN CldheWxhbmQpIGFuZCBodW5kcmVkcyBvZiBhcHBsaWNhdGlvbnMgdGhhdCBjYW4gYmUgdXNlZCBv biBhbnkgRnJlZUJTRCBtYWNoaW5lLg0KDQpUaGUgS0RFIHRlYW0gKGtkZUApIGlzIHBhcnQgb2Yg ZGVza3RvcEAgYW5kIHgxMUAgYXMgd2VsbCwgYnVpbGRpbmcgdGhlIHNvZnR3YXJlDQpzdGFjayB0 byBtYWtlIEZyZWVCU0QgYmVhdXRpZnVsIGFuZCB1c2FibGUgYXMgYSBkYWlseS1kcml2ZXIgZ3Jh cGhpY3MtYmFzZWQNCmRlc2t0b3AgbWFjaGluZS4NCg0KICDigKIgSnVzdCB0d28gQ01ha2UgdXBk YXRlcyB0aGlzIHF1YXJ0ZXIsIGVuZGluZyB1cCB3aXRoIENNYWtlIDMuMjIuMS4gU29tZSBtb3Jl DQogICAgcGF0Y2hlcyBoYXZlIGxhbmRlZCB1cHN0cmVhbSwgYW5kIENNYWtlIGlzIHNvb24gdG8g c3dpdGNoIHRvIHNoYXJlL21hbiBmb3INCiAgICBtYW5wYWdlcyBvbiBGcmVlQlNELiBXaGVuIGl0 IGRvZXMsIHRoZXJlIHdpbGwgYmUgcGxlbnR5IG9mIHBrZy1wbGlzdCBjaHVybi4NCg0KICDigKIg TW9udGhseSByZWxlYXNlcyBvZiBLREUgRnJhbWV3b3JrcywgS0RFIFBsYXNtYSwgYW5kIEtERSBH ZWFyIGtlcHQgdGhlDQogICAgZXhwLXJ1bnMgZ29pbmcuIGtkZUAgd291bGQgbGlrZSB0byB0aGFu ayBBbnRvaW5lIGZvciBvdmVyc2VlaW5nIG91ciBtYW55DQogICAgZXhwLXJ1biByZXF1ZXN0cy4g V2UgYXJlIG5vdyBhdCBLREUgRnJhbWV3b3JrcyA1Ljg5IChsYXRlc3QgcmVsZWFzZSBhcyBvZg0K ICAgIERlY2VtYmVyIDIwMjEpLCBLREUgUGxhc21hIERlc2t0b3AgNS4yMy40IGFuZCBLREUgR2Vh ciAyMS4xMi4NCg0KICDigKIgUXQgNSBpcyBub3QgcmVjZWl2aW5nIGFueSBvcGVuIHNvdXJjZSB1 cGRhdGVzIGZyb20gdGhlIFF0IENvbXBhbnksIGJ1dCB0aGUNCiAgICBLREUgQ29tbXVuaXR5IG1h aW50YWlucyBpdHMgb3duIHNldCBvZiBwYXRjaGVzIHRoYXQgYmFja3BvcnQgbWFueSBmaXhlcw0K ICAgIGZyb20gUXQgNi4gV29yayBpcyB1bmRlcndheSB0byBpbXBvcnQgdGhlIEtERSBwYXRjaCBj b2xsZWN0aW9uLg0KDQogIOKAoiBRdCA2IHJlbWFpbnMgdGFudGFsaXppbmdseSBjbG9zZS4gVGhl cmUgaGFzbuKAmXQgYmVlbiByZWFsIHByb2dyZXNzIG9uIHRoZQ0KICAgIGNyYXNoLW9uLWV4aXQg cHJvYmxlbSwgdGhvdWdoLg0KDQogIOKAoiBkZXNrdXRpbHMva2FsZW5kYXIgaXMgYSByZWxhdGl2 ZWx5IG5ldyBwb3J0IHRoYXQgdXNlcyBLREUgdGVjaG5vbG9naWVzIGZvcg0KICAgIGEgZGVza3Rv cCAoYXBwb2ludG1lbnRzKSBjYWxlbmRhci4NCg0KICDigKIgZGVza3V0aWxzL2xhdHRlLWRvY2ss IGFuIGFsdGVybmF0aXZlIGxhdW5jaGVyIGZvciBLREUgUGxhc21hIChhbmQgb3RoZXINCiAgICBl bnZpcm9ubWVudHMpIHdhcyB1cGRhdGVkIHRvIGVhY2ggb2YgaXRzIGJ1Z2ZpeCByZWxlYXNlcy4N Cg0KICDigKIgZGV2ZWwvcWJzIGFuZCBkZXZlbC9xdGNyZWF0b3Igd2VyZSB1cGRhdGVkLiBRYnMg KG9yICJRdCBCdWlsZCBTeXN0ZW0iKSBpcyBhDQogICAgZGVjbGFyYXRpdmUgYnVpbGQgc3lzdGVt IHN0eWxlZCBhbG9uZyB0aGUgbGluZXMgb2YgZGVjbGFyYXRpdmUgUU1MDQogICAgcHJvZ3JhbXMu IChOb3RlIHRoYXQgUWJzIGlzIG5vdCB1c2VkIGJ5IFF0IGl0c2VsZikuDQoNCiAg4oCiIGdyYXBo aWNzL2RpZ2lrYW0gd2FzIHVwZGF0ZWQgdG8gdGhlIGxhdGVzdCByZWxlYXNlIGFuZCBub3cgc3Vw cG9ydHMgYm90aA0KICAgIEltYWdlTWFnaWNrIDYgYW5kIEltYWdlTWFnaWNrIDcuIFNwZWFraW5n IG9mIHdoaWNoLCBhIG5ldyBVU0VTPW1hZ2ljayB3YXMNCiAgICBpbnRyb2R1Y2VkIHRvIHNpbXBs aWZ5IHBvcnRzIHRoYXQgZGVwZW5kIGluIEltYWdlTWFnaWNrLg0KDQogIOKAoiBncmFwaGljcy9r c25pcCwgb25lIG9mIHNldmVyYWwgc2NyZWVuc2hvdC1hcHBsaWNhdGlvbnMgZm9yIEtERSBQbGFz bWEgKGFuZA0KICAgIG90aGVyIGVudmlyb25tZW50cykgaGFkIGEgbG90cy1vZi1idWdmaXhlcyB1 cGRhdGUuDQoNCiAg4oCiIGdyYXBoaWNzL3NrYW5wYWdlIGlzIGEgbmV3IHBvcnQgdGhhdCBzY2Fu cyBtdWx0aXBsZSBwYWdlcyBhbmQgcHJvZHVjZXMgYQ0KICAgIFBERiBvZiB0aGUgd2hvbGUuDQoN CiAg4oCiIG11bHRpbWVkaWEvcXQ1LW11bHRpbWVkaWEgbm93IGlnbm9yZXMgZ3N0cmVhbWVyLWds IChyYXRoZXIgdGhhbiBpbXBsaWNpdGx5DQogICAgYnVpbGRpbmcgd2l0aCBpdCBhcyBhIGRlcGVu ZGVuY3kgaWYgaXQgaXMgaW5zdGFsbGVkIGEgYnVpbGQgdGltZSkuDQoNCiAg4oCiIG5ldC1pbS9y dXFvbGEgaXMgYSBSb2NrZXQgQ2hhdCBjbGllbnQsIHVwZGF0ZWQgdG8gdGhlIGxhdGVzdCByZWxl YXNlLg0KDQogIOKAoiBzZWN1cml0eS9xdGtleWNoYWluIGhhcyBhIG5ldyByZWxlYXNlLg0KDQpF bHNld2hlcmUgaW4gdGhlIHNvZnR3YXJlIHN0YWNrLCBrZGVAIGFsc28gbWFpbnRhaW5zIHBvcnRz IHRoYXQgc3VwcG9ydCB0aGUNCmRlc2t0b3AgaW4gZ2VuZXJhbC4gU29tZSBoaWdobGlnaHRzIGFy ZToNCg0KICDigKIgZGV2ZWwvbGlicGhvbmVudW1iZXIga2VlcHMgY2hhc2luZyBjaGFuZ2VzIHRv IHRoZSB3b3JsZOKAmXMgcGhvbmUgbnVtYmVycw0KICAgICh0aGUgRnJlZUJTRCBmb3VuZGF0aW9u IGNhbiBiZSByZWFjaGVkIGF0ICsxLjcyMC4yMDcuNTE0MikuDQoNCiAg4oCiIGdyYXBoaWNzL3Bv cHBsZXIgdXBkYXRlZCB0aGlzIG11Y2gtdXNlZCBQREYtcmVuZGVyaW5nIGxpYnJhcnkuDQoNCiAg 4oCiIG11bHRpbWVkaWEvcGlwZXdpcmUsIHRoZSBhdWRpby1hbmQtdmlkZW8gc3VjY2Vzc29yIHRv IHB1bHNlYXVkaW8sIHdhcw0KICAgIHVwZGF0ZWQgYW5kIG5vdyBzdXBwb3J0cyBTU0wgYXMgd2Vs bC4NCg0KICDigKIgbmV0L3B5LXB5dHJhZGZyaSBnb3Qgc2V2ZXJhbCB1cGRhdGVzIHNvIHlvdSBj YW4gY29udHJvbCB5b3VyIGxpZ2h0cyBmcm9tDQogICAgRnJlZUJTRC4NCg0KICDigKIgcHJpbnQv ZnJlZXR5cGUyIHdhcyB1cGRhdGVkIHRvIHRoZSBsYXRlc3QgcmVsZWFzZTsgcmVsYXRlZGx5LCB0 aGVyZSB3YXMgYW0NCiAgICB1cGRhdGUgdG8geDExLXRvb2xraXRzL2xpYlhmdC4NCg0KICDigKIg cHJpbnQvaGFyZmJ1enosIHRoZSB0ZXh0LXNoYXBpbmcgbGlicmFyeSwgd2FzIHVwZGF0ZWQgZm9y IG1vcmUgZm9udCB0eXBlDQogICAgc3VwcG9ydC4NCg0KICDigKIgc3lzdXRpbHMvYnNkaXNrcyBp cyBhbiBpbXBsZW1lbnRhdGlvbiBvZiBEQnVzIGludGVyZmFjZXMgZm9yIGV4YW1pbmluZw0KICAg IGRpc2tzIChkcml2ZXMsIHBhcnRpdGlvbnMsIGV0Yy4pLiBJdCBpcyBhbHNvIHVzZWQgZm9yIHJl bW92YWJsZS1kaXNrDQogICAgbm90aWZpY2F0aW9ucy4NCg0KICDigKIgeDExLXRoZW1lcy9hZHdh aXRhLXF0LCB3aGljaCBjb25uZWN0cyB0aGUgYWR3YWl0YSB0aGVtZSBlbmdpbmUgdG8gUXQtYmFz ZWQNCiAgICBhcHBsaWNhdGlvbnMsIHdhcyB1cGRhdGVkLg0KDQrilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIENCg0KRnJlZUJT RCBPZmZpY2UgVGVhbQ0KDQpMaW5rczoNClRoZSBGcmVlQlNEIE9mZmljZSBwcm9qZWN0IFVSTDog aHR0cHM6Ly93aWtpLmZyZWVic2Qub3JnL09mZmljZQ0KDQpDb250YWN0OiBGcmVlQlNEIE9mZmlj ZSB0ZWFtIE1MIDxvZmZpY2VARnJlZUJTRC5vcmc+DQpDb250YWN0OiBEaW1hIFBhbm92IDxmbHVm ZnlARnJlZUJTRC5vcmc+DQpDb250YWN0OiBMaS1XZW4gSHN1IDxsd2hzdUBGcmVlQlNELm9yZz4N Cg0KVGhlIEZyZWVCU0QgT2ZmaWNlIHRlYW0gd29ya3Mgb24gYSBudW1iZXIgb2Ygb2ZmaWNlLXJl bGF0ZWQgc29mdHdhcmUgc3VpdGVzIGFuZA0KdG9vbHMgc3VjaCBhcyBPcGVuT2ZmaWNlIGFuZCBM aWJyZU9mZmljZS4NCg0KV29yayBkdXJpbmcgdGhpcyBxdWFydGVyIHdhcyBmb2N1c2VkIG9uIHBy b3ZpZGluZyB0aGUgbGF0ZXN0IHN0YWJsZSByZWxlYXNlIG9mDQpMaWJyZU9mZmljZSBzdWl0ZSBh bmQgY29tcGFuaW9uIGFwcHMgdG8gYWxsIEZyZWVCU0QgdXNlcnMuDQoNCkxhdGVzdCBhbmQgcXVh cnRlcmx5IHBvcnRzIGJyYW5jaGVzIGdvdCBhIG5ldyBicmFuY2ggKDcuMikgb2YgdGhlIExpYnJl T2ZmaWNlDQpzdWl0ZSBhbmQgdXBkYXRlZCB0byB0aGUgNy4yLjQgcmVsZWFzZSB3aGlsZSBuZXcg cHJlbGVhc2VzIHN1Y2ggYXMgNy4yLjUuUkMyDQphbmQgNy4zLjAuUkMxIGFyZSBjb29raW5nIGlu IHRoZSBXSVAgc3RhZ2UgYXJlYS4NCg0KTWVhbndoaWxlLCBvdXIgV0lQIHJlcG9zaXRvcnkgZ290 IGJhY2sgYSB3b3JraW5nIENJIGluc3RhbmNlIGFnYWluLCB0aGFua3MgdG8NCkxpLVdlbiBIc3Uu DQoNCkFsc28gd2UgYXJlIHN0aWxsIHdvcmtpbmcgb24gdGhlIEJvb3N0IFdJUCByZXBvc2l0b3J5 IHRvIGJyaW5nIHRoZSBsYXRlc3QgQm9vc3QNCmxpYnJhcnkgdG8gdGhlIHBvcnRzLg0KDQpXZSBh cmUgbG9va2luZyBmb3IgcGVvcGxlIHRvIGhlbHAgd2l0aCB0aGUgb3BlbiB0YXNrczoNCg0KICDi gKIgVGhlIG9wZW4gYnVncyBsaXN0IGNvbnRhaW5zIGFsbCBmaWxlZCBpc3N1ZXMgd2hpY2ggbmVl ZCBzb21lIGF0dGVudGlvbg0KDQogIOKAoiBVcHN0cmVhbSBsb2NhbCBwYXRjaGVzIGluIHBvcnRz DQoNClBhdGNoZXMsIGNvbW1lbnRzIGFuZCBvYmplY3Rpb25zIGFyZSBhbHdheXMgd2VsY29tZSBp biB0aGUgbWFpbGluZyBsaXN0IGFuZA0KYnVnemlsbGEuDQoNCuKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgQ0KDQpUaGlyZC1Q YXJ0eSBQcm9qZWN0cw0KDQpNYW55IHByb2plY3RzIGJ1aWxkIHVwb24gRnJlZUJTRCBvciBpbmNv cnBvcmF0ZSBjb21wb25lbnRzIG9mIEZyZWVCU0QgaW50bw0KdGhlaXIgcHJvamVjdC4gQXMgdGhl c2UgcHJvamVjdHMgbWF5IGJlIG9mIGludGVyZXN0IHRvIHRoZSBicm9hZGVyIEZyZWVCU0QNCmNv bW11bml0eSwgd2Ugc29tZXRpbWVzIGluY2x1ZGUgYnJpZWYgdXBkYXRlcyBzdWJtaXR0ZWQgYnkg dGhlc2UgcHJvamVjdHMgaW4NCm91ciBxdWFydGVybHkgcmVwb3J0LiBUaGUgRnJlZUJTRCBwcm9q ZWN0IG1ha2VzIG5vIHJlcHJlc2VudGF0aW9uIGFzIHRvIHRoZQ0KYWNjdXJhY3kgb3IgdmVyYWNp dHkgb2YgYW55IGNsYWltcyBpbiB0aGVzZSBzdWJtaXNzaW9ucy4NCg0KaGVsbG9TeXN0ZW0NCg0K TGlua3M6DQpEb2N1bWVudGF0aW9uIFVSTDogaHR0cHM6Ly9oZWxsb3N5c3RlbS5naXRodWIuaW8v DQoNCkNvbnRhY3Q6IFNpbW9uIFBldGVyIDxwcm9ib25vQHB1cmVkYXJ3aW4ub3JnPg0KQ29udGFj dDogI2hlbGxvU3lzdGVtIG9uIGlyYy5saWJlcmEuY2hhdCwgbWlycm9yZWQgdG8gI2hlbGxvU3lz dGVtOm1hdHJpeC5vcmcNCm9uIE1hdHJpeA0KDQpXaGF0IGlzIGhlbGxvU3lzdGVtPw0KDQpoZWxs b1N5c3RlbSBpcyBGcmVlQlNEIHByZWNvbmZpZ3VyZWQgYXMgYSBkZXNrdG9wIG9wZXJhdGluZyBz eXN0ZW0gd2l0aCBhIGZvY3VzDQpvbiBzaW1wbGljaXR5LCBlbGVnYW5jZSwgYW5kIHVzYWJpbGl0 eS4gSXRzIGRlc2lnbiBmb2xsb3dzIHRoZSDigJxMZXNzLCBidXQNCmJldHRlcuKAnSBwaGlsb3Nv cGh5Lg0KDQpRNCAyMDIxIFN0YXR1cw0KDQogIOKAoiBWZXJzaW9uIDAuNy4wIG9mIGhlbGxvU3lz dGVtIGhhcyBiZWVuIHB1Ymxpc2hlZCBpbmNsdWRpbmcgbWFueSBjb250cmlidXRlZA0KICAgIGZl YXR1cmVzIGFuZCBidWdmaXhlcw0KDQogICAgICDilqEgaGVsbG9TeXN0ZW0gaXMgbm93IGJhc2Vk IG9uIEZyZWVCU0QgMTMuMC1SRUxFQVNFDQoNCiAgICAgIOKWoSBDb21wbGV0ZWx5IHJld29ya2Vk IExpdmUgSVNPIGFyY2hpdGVjdHVyZSwgcmVzdWx0aW5nIGluIDEvM3JkIGJvb3QgdGltZQ0KICAg ICAgICBhbmQgdW5kZXIgODAwIE1CIHNpemUgKGZpdHMgYSBDRC1ST00pDQoNCiAgICAgIOKWoSBE ZXZlbG9wZXIgVG9vbHMgYXJlIG5vdyBhIHNlcGFyYXRlIGRvd25sb2FkDQoNCiAgICAgIOKWoSBE aXNrIEltYWdlcyBhcmUgaW5jcmVhc2luZ2x5IHVzZWQgdGhyb3VnaG91dCB0aGUgc3lzdGVtLCBz dWNoIGFzIGZvcg0KICAgICAgICBhcHBsaWNhdGlvbiBkaXN0cmlidXRpb24gYW5kIExpbnV4dWxh dG9yIHVzZXJsYW5kIGRlcGxveW1lbnQNCg0KICAgICAg4pahIE1hbnkgbmV3IGZlYXR1cmVzIGFu ZCBHVUkgdXRpbGl0aWVzIHRvIG1ha2UgdGhlIGRlc2t0b3AgbW9yZSB1c2FibGUgZm9yDQogICAg ICAgICJtZXJlIG1vcnRhbHMiIHdpdGhvdXQgdGhlIG5lZWQgZm9yIGEgdGVybWluYWwNCg0KSW5z dGFsbGFibGUgTGl2ZSBJU08gaW1hZ2VzIGFuZCBhIGZ1bGwgY2hhbmdlbG9nIGFyZSBhdmFpbGFi bGUgYXQgaHR0cHM6Ly8NCmdpdGh1Yi5jb20vaGVsbG9TeXN0ZW0vSVNPL3JlbGVhc2VzL3RhZy9y MC43LjANCg0KQ29udHJpYnV0aW5nDQoNClRoZSBwcm9qZWN0IGFwcHJlY2lhdGVzIGNvbnRyaWJ1 dGlvbnMgaW4gdmFyaW91cyBhcmVhcy4NCg0K4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSBDQoNCkNvbnRhaW5lcnMgJiBGcmVl QlNEOiBQb3QsIFBvdGx1Y2sgJiBQb3RtYW4NCg0KTGlua3M6DQpQb3Qgb24gZ2l0aHViIFVSTDog aHR0cHM6Ly9naXRodWIuY29tL3BpenphbWlnL3BvdA0KUG90bHVjayBSZXBvc2l0b3J5ICYgUHJv amVjdCBVUkw6IGh0dHBzOi8vcG90bHVjay5ob25leWd1aWRlLm5ldC8NClBvdGx1Y2sgb24gZ2l0 aHViIFVSTDogaHR0cHM6Ly9naXRodWIuY29tL2hueS1nZC9wb3RsdWNrDQpQb3RtYW4gb24gZ2l0 aHViIFVSTDogaHR0cHM6Ly9naXRodWIuY29tL2dyZW1iby9wb3RtYW4NCg0KQ29udGFjdDogTHVj YSBQaXp6YW1pZ2xpbyAoUG90KSA8cGl6emFtaWdAZnJlZWJzZC5vcmc+DQpDb250YWN0OiBTdGVw aGFuIExpY2h0ZW5hdWVyIChQb3RsdWNrKSA8c2xAaG9uZXlndWlkZS5ldT4NCkNvbnRhY3Q6IE1p Y2hhZWwgR21lbGluIChQb3RtYW4pIDxncmVtYm9ARnJlZUJTRC5vcmc+DQoNClBvdCBpcyBhIGph aWwgbWFuYWdlbWVudCB0b29sIHRoYXQgYWxzbyBzdXBwb3J0cyBvcmNoZXN0cmF0aW9uIHRocm91 Z2ggTm9tYWQuDQoNCkluIHRoZSBsYXN0IHF1YXJ0ZXIsIGEgbmV3IHJlbGVhc2UgMC4xNC4wIHdp dGggYSBudW1iZXIgb2YgZml4ZXMgYW5kIGZlYXR1cmVzDQpsaWtlIHRoZSBuZXcgY29weS1pbi1m bHYgY29tbWFuZCB3YXMgbWFkZSBhdmFpbGFibGUuDQoNClBvdGx1Y2sgYWltcyB0byBiZSB0byBG cmVlQlNEIGFuZCBQb3Qgd2hhdCBEb2NrZXJodWIgaXMgdG8gTGludXggYW5kIERvY2tlcjogYQ0K cmVwb3NpdG9yeSBvZiBQb3QgZmxhdm91cnMgYW5kIGNvbXBsZXRlIGNvbnRhaW5lciBpbWFnZXMg Zm9yIHVzYWdlIHdpdGggUG90IGFuZA0KaW4gbWFueSBjYXNlcyBOb21hZC4NCg0KSGVyZSB3ZSBh Z2FpbiBoYWQgYSBidXN5IHF1YXJ0ZXIuIEFsbCBpbWFnZXMgaGF2ZSBiZWVuIHJlYnVpbHQgZm9y IEZyZWVCU0QgMTIuMw0KYW5kIHBvdCAwLjEzLjAuDQpBbHNvIHRoZSBpbWFnZXMgdGhhdCBjYW4g YmUgdXNlZCB0byBidWlsZCBhIHZpcnR1YWwgZGF0YSBjZW50ZXIgbGlrZSBOb21hZCwNCkNvbnN1 bCBhbmQgVmF1bHQgaGF2ZSByZWNlaXZlZCBhIGxvdCBtb3JlIHRlbmRlciBsb3ZlIGFuZCBjYXJl IGFuZCBhcmUNCm1lYW53aGlsZSBpbiBwcmUtcHJvZHVjdGlvbiB1c2Ugb24gYSBjbHVzdGVyIGF0 IGEgZmludGVjaC4NCk5vdCBhbGwgdGhlc2UgY2hhbmdlcyBoYXZlIHlldCBiZWVuIGNvbW1pdHRl ZCB0byB0aGUgZ2l0aHViIHJlcG9zaXRvcnkgdGhvdWdoLA0KdGhpcyBpcyBwbGFubmVkIGZvciB0 aGUgbmV4dCBxdWFydGVyLiBBZGRpdGlvbmFsbHksIG5ldyBpbWFnZXMgbGlrZQ0KbXVsdGktbWFz dGVyIE9wZW5MREFQIGhhdmUgYmVlbiBhZGRlZCwgdG9vLg0KDQpQb3RtYW4gYWltcyB0byBzaW1w bGlmeSBidWlsZGluZyBQb3QgaW1hZ2VzIHdpdGggVmFncmFudCBhbmQgVmlydHVhbEJveCBiYXNl ZA0Kb24gdGhlIFBvdGx1Y2sgYXBwcm9hY2gsIGUuZy4gYXMgcGFydCBvZiBhIERldk9wcyB3b3Jr ZmxvdyBmb3Igc29mdHdhcmUNCmRldmVsb3BtZW50IGluY2x1ZGluZyB0ZXN0aW5nIGFuZCBwdWJs aXNoaW5nIHRoZW0gdG8gYSByZXBvc2l0b3J5Lg0KDQpIZXJlIHdlIGhhdmUgbm90IHlldCBtYWRl IGEgbG90IG9mIGhlYWR3YXkgd2l0aCBvdXIgcGxhbiB0byB1dGlsaXNlIFBvdG1hbiBpbg0KdGhl IFBvdGx1Y2sgbGlicmFyeSBidWlsZCBwcm9jZXNzIGJ1dCB0aGlzIGlzIHN0aWxsIG9uIG91ciBU T0RPLWxpc3QsIGxpa2UNCmltcHJvdmluZyB0aGUgZG9jdW1lbnRhdGlvbiBmb3IgdXNpbmcgdGhl IFZpcnR1YWwgREMgaW1hZ2VzIGZyb20gdGhlIFBvdGx1Y2sNCmxpYnJhcnkuDQoNCkFzIGFsd2F5 cywgZmVlZGJhY2sgYW5kIHBhdGNoZXMgYXJlIHdlbGNvbWUuDQoNCuKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgQ0K --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKkBAEBCgCOFiEEVbCTpybDiFVxIrrVNqQMg7DW754FAmIqsh5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUQHGpybUBmcmVl YnNkLm9yZwAKCRA2pAyDsNbvnj1pD/41O1IJ9LMpGJjwDEJ1h4uDQWgbvduuH1Mi 6qwYY9lD/o3/K2cOAfImmkjqJG5sepE6i8Nr9OKG0xHwSrumB+2V/3bJydujCENI SouKllhGUsUDo4tHBHgaTWIe30wjhaI2NSk6kqmSI4UJ030qrxaPamfx2pN8IRVz OPYW5JwisaEFwp0UXTtGY2cFZA8gb0YTvhrazRzH8sQGNOYkHOzHpSUozRc+9D9G GinMHOdmqsJ4ewj/9M24u3HJ4+aBLH8XaYt8MyJho5RBwIn52Z8358M5abDPkEbS 4xKYrktagp79kOSU7nNUoBEKdxCLeKrd7pvdQK9jd5st0PItWuAbd2QTQiYDtoUc Q3R/T68FpMxPS1kSCJ1siDui214eNPHQIfhdwOXSDCRTm4oIYzaxAUsBdV5uvoJr 1NUtRfXSbAyxDze/qDVOPeyzuZoo0C/4KwSbX0YRfYa1EoSvJgRIJd8jbLK0MRBe cqR/WYmyOJhTVh+QL368gbfEwQ9ZlkXEwUtofqZkM2yC4Lje6Dr7OYKArfOkgFWt pMGudE/qiKdTFVE/VvWeDQ/wmq1agVqZEX204YEyszuwXn5DH4tLqoqlydZoHcAL d0EfWO/Z8RTIokc/4I+mB6A2YOH4QIo+h7NH7naoPfuFNf5PNwzwVfNYok0dgbd+ e31h8a10rw== =TTeE -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 11 09:49:42 2022 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 EE0F41A09D6C for ; Fri, 11 Mar 2022 09:50:06 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature ECDSA (P-256)) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KFLl14bHmz4Yt1 for ; Fri, 11 Mar 2022 09:50:05 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) client-signature ECDSA (P-256)) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id A68802CDDA for ; Fri, 11 Mar 2022 10:50:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1646992203; 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=8qaHiNEEWMaQr8H8+/W6bM/j3+D47WtKbztJoNSOgak=; b=d0nV2sHUIO0rC+18k7dYZpSc5TI5nybtH1XK10Zkd3qQ3wGgKysn6iCBJrSWJQHX+cgckA iaLugesz5ylNBN5ePYclYu2jkEVc5TzkqsRyrQV/81O6qQ7z9ZA+RWmCRnM57bzF+Lxc4Q lDnUV41NDzzBnhBRJc4qZDiTTwcLKvcRcQHKNWvz4nfcYJRdd9LrOX0RxOj4CLklNnofeO kqLuVjMrjA+ne8z9KNASvYhrNfM/DAkz3Ba9tpp9s1f7TH4dt7z+Przcj4Et11AtsbMCJU 2ay89oetknY++6q52kjX0DC7coGKSS3lpIub6LMwvG5cBiInMsy0x34KUYkKuQ== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 16534A787 for ; Fri, 11 Mar 2022 10:50:01 +0100 (CET) Date: Fri, 11 Mar 2022 10:49:42 +0100 Message-ID: <20220311104942.Horde.BX4nDaPVTH6Lz85SCVNcopM@webmail.leidinger.net> From: Alexander Leidinger To: current@freebsd.org Subject: What are the in-kernel functions to format time? Accept-Language: de,en Content-Type: multipart/signed; boundary="=_BChPT2C6CYfMiNo_F0TKnqH"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4KFLl14bHmz4Yt1 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=d0nV2sHU; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-5.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_BChPT2C6CYfMiNo_F0TKnqH Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm looking for a function to convert bintime to a human readable=20=20 format=20in the kernel... and what is the usual format we use? The use case for this is: if something throws a log from the kernel=20=20 about=20a signal, I want to know when it happened, or in terms of code=20= =20 see=20below (tabs are most probably messed up). Do we have some kind of policy in terms of kernel messages and=20=20 timestamps?=20Like "do not commit logging with timestamps"? I have the=20= =20 code=20below because I needed it at least once and think something like=20= =20 this=20(in a human readably shape) would be beneficial to have in the=20=20 tree. Code: ---snip--- diff=20--git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 4a15bd45355..a83eebe0736 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -80,6 +80,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -3440,14 +3441,18 @@ sigexit(struct thread *td, int sig) */ if (coredump(td) =3D=3D 0) sig |=3D WCOREFLAG; - if (kern_logsigexit) + if (kern_logsigexit) { + struct bintime now; + + getbintime(&now); log(LOG_INFO, - "pid %d (%s), jid %d, uid %d: exited on " - "signal %d%s\n", p->p_pid, p->p_comm, + "%zd: pid %d (%s), jid %d, uid %d: exited on " + "signal %d%s\n", now.sec, p->p_pid, p->p_comm, p->p_ucred->cr_prison->pr_id, td->td_ucred->cr_uid, sig &~ WCOREFLAG, sig & WCOREFLAG ? " (core dumped)" : ""); + } } else PROC_UNLOCK(p); exit1(td, 0, sig); ---snip--- Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_BChPT2C6CYfMiNo_F0TKnqH Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmIrGzUACgkQEg2wmwP4 2IZJnBAAni6vGDfXQIPS9JR9+vD7Ib1tf03qCij/AxLtvmxPR0DmxeDGvXayJifn 0L264r6CJZU/n/UyDca4bf6JDBs08gcN8aQgQl0dH9jaKpNCGqqUrPsilfIssg9f OuhRYiExwOfJuU7+omgt/a2tJjQG2r3iC2UyQFwuCMBxZF79tKosLsxfWN7wtW+a OrqhSf/IecXYtR1paLJvEFV7++zr4hdvxcbYy9hHHZA4mvB9i5PfhocU2TDdwhX9 XOsBrtRz0sLxomtDG2nJaHvYt8nGzu7cGUbigKkUcV9Fcs8CW2/ZYzI9FvkVemm4 Cj6V9c6/sTx820iPtGZ/fmilR07UPpcXJqRI2GazRAE4OyJMtohBb2nI0EBloH/h xWQD5Ph3Ps7O48gLxX9E1IvzTjy3DZSdcSyOBy5pd0Eg9wUIi8axHog0MLHAI9zj vjjfXNaMqAU9D0GMQh2+IM3hygbHy3NgUJf6mwFjcwuPZM+mT3H/Ua/brCDCK60u 2Uzry5ry5ugIUCUqts1X/5uO5LIXWTUplSW9IP4uH/x5sAtorac7wu8PprsNX1DO IwSilpml2bQ8JxBjSU9LNqsrLWVNS4hOe0Dj52O2u3gYwdASszGH+5EUPipbsUCr vIg42XjIfsMToSAFM9C4ploxZMilV2WiDUoDphhmnLAKW/khUmI= =P6mT -----END PGP SIGNATURE----- --=_BChPT2C6CYfMiNo_F0TKnqH-- From nobody Fri Mar 11 09:51:49 2022 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 B51E51A0B614 for ; Fri, 11 Mar 2022 09:51:56 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KFLn63k1Xz4bJb for ; Fri, 11 Mar 2022 09:51:54 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) client-signature ECDSA (P-256)) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 388D22CDDF for ; Fri, 11 Mar 2022 10:51:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1646992312; 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=jzsovUao9oRYI/6WrsW8+jaPw+pbqKPxCZ2NnS7PDbI=; b=Rd7syq4l9r3jcBzPPI/bfzJdtjrP59C9InfO98fhwAY4ZwX2P/umgf0Kr9lSAN65IWKA7a nOGehGejZ4keakzlBK+rTsHY6lYXjd4BhLTf6XML9Jzbf5UNDi/CA7tKsOvvx7n+i1o56r 4FArzFJaNrMPyNQXcpb1IU1qjSbceitpIDliKcuIXkpn8pcmMKMQyjIRwv6qLDlyhyZP4Y 4L0ogaYtHlQw8HYAgEGGjM4XJLzW0NKmj63NsO07v1GOAVHF79slTwEk6GD+GqKhcygW88 DejZB6wWLm7i2PZ1rthLeUlMlze9uIf8uET0VJji6Ht5m1hJV6KjDfO0meF7zA== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id E0DB6A11B for ; Fri, 11 Mar 2022 10:51:49 +0100 (CET) Date: Fri, 11 Mar 2022 10:51:49 +0100 Message-ID: <20220311105149.Horde.uO0yyQjwC3xmwZvuZWV1ADl@webmail.leidinger.net> From: Alexander Leidinger To: current@freebsd.org Subject: What are the in-kernel functions to print human readable timestamps (bintime)? Accept-Language: de,en Content-Type: multipart/signed; boundary="=_YHArA4YOh1lxGoFmGL8x-nN"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4KFLn63k1Xz4bJb X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=Rd7syq4l; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-5.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_YHArA4YOh1lxGoFmGL8x-nN Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm looking for a function to convert bintime to a human readable=20=20 format=20in the kernel... and what is the usual format we use? The use case for this is: if something throws a log from the kernel=20=20 about=20a signal, I want to know when it happened, or in terms of code=20= =20 see=20below (tabs are most probably messed up). Do we have some kind of policy in terms of kernel messages and=20=20 timestamps?=20Like "do not commit logging with timestamps"? I have the=20= =20 code=20below because I needed it at least once and think something like=20= =20 this=20(in a human readably shape) would be beneficial to have in the=20=20 tree. Code: ---snip--- diff=20--git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 4a15bd45355..a83eebe0736 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -80,6 +80,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -3440,14 +3441,18 @@ sigexit(struct thread *td, int sig) */ if (coredump(td) =3D=3D 0) sig |=3D WCOREFLAG; - if (kern_logsigexit) + if (kern_logsigexit) { + struct bintime now; + + getbintime(&now); log(LOG_INFO, - "pid %d (%s), jid %d, uid %d: exited on " - "signal %d%s\n", p->p_pid, p->p_comm, + "%zd: pid %d (%s), jid %d, uid %d: exited on " + "signal %d%s\n", now.sec, p->p_pid, p->p_comm, p->p_ucred->cr_prison->pr_id, td->td_ucred->cr_uid, sig &~ WCOREFLAG, sig & WCOREFLAG ? " (core dumped)" : ""); + } } else PROC_UNLOCK(p); exit1(td, 0, sig); ---snip--- Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_YHArA4YOh1lxGoFmGL8x-nN Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmIrG7QACgkQEg2wmwP4 2IZ/7A/+ODlQi5qYzhtss8qRThkoS851gcsLeMFGVmddBZ9SqGHzucmrQLC6T1o8 NmRefQeUUJrkTmm+Q8b2yk1KlBy2CQA2yBu2XWFgHVE/2mhytXJoMcR4QH/qEMSC Lu/wDthbF/WtKzYpjekrGRHtZfxfgfPTDH1WAEKP0oMhA3q8xRPy7UgT9qGEQV2I cykLXbHm+InqPpPwYlB6HqbZ+00KPugqUujK8K4qqSORg4pV/hkBo/Qse4s/dyLt LwrIv8Ve7s4ffZH86AeQFJcjjt3KsnEDd66/+LzYvof5SZ7x51hrkJ4gonwdAhTw xkzFJ8E0Gm98QGBecUFF0oy7Q9zLCAyn6nn0Bbr0+JONfNToADBN8WoVcVASLA+V qp6+qIgNdQOdxhKvkINl7NTt78R37CJBIM6HHDafibLZKvWqwwsPkS2KKqUX6d2H 3z/72OIn/nIzRF8hOgMpjEL1OKp8l6+W/hPv8bpGvGflmpw2BiU5VTnQ+JiJDupJ MS8QkL8hhdSpZWKuB6Y2nTfzRrf/gGG+CA3YLD9owDiqVbwDzChL7e28SF8sKc5O c7uWZqMta9zDHGwDAS8Gf4Js55ogOVGzUtphdH2uhcbocmVNks7ZmuUIEQPPseIj A9x6gdBTPW8G+FZyHmMMbxwLI6QG7BeRmsze/HNnze5Mk3V60IM= =CnUJ -----END PGP SIGNATURE----- --=_YHArA4YOh1lxGoFmGL8x-nN-- From nobody Fri Mar 11 10:01:03 2022 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 4FE921A0F863 for ; Fri, 11 Mar 2022 10:01:16 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KFLzv59Byz4h49 for ; Fri, 11 Mar 2022 10:01:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 87BF0261F05; Fri, 11 Mar 2022 11:01:14 +0100 (CET) Message-ID: Date: Fri, 11 Mar 2022 11:01:03 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: What are the in-kernel functions to format time? Content-Language: en-US To: Alexander Leidinger , current@freebsd.org References: <20220311104942.Horde.BX4nDaPVTH6Lz85SCVNcopM@webmail.leidinger.net> From: Hans Petter Selasky In-Reply-To: <20220311104942.Horde.BX4nDaPVTH6Lz85SCVNcopM@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KFLzv59Byz4h49 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.12 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-0.83)[-0.826]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 3/11/22 10:49, Alexander Leidinger wrote: > Hi, > > I'm looking for a function to convert bintime to a human readable format > in the kernel... and what is the usual format we use? > > > The use case for this is: if something throws a log from the kernel > about a signal, I want to know when it happened, or in terms of code see > below (tabs are most probably messed up). > > Do we have some kind of policy in terms of kernel messages and > timestamps? Like "do not commit logging with timestamps"? I have the > code below because I needed it at least once and think something like > this (in a human readably shape) would be beneficial to have in the tree. > Hi, I think our kernel printer doesn't support this: sys/kern/subr_prf.c If you need to extend the format, please check other OS'es too, like OpenBSD, NetBSD and Linux, what they support, so there won't be any obvious conflicts when moving code cross platforms! --HPS From nobody Fri Mar 11 11:20:39 2022 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 4ED561A1F8FA for ; Fri, 11 Mar 2022 11:20:46 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KFNlc6D8Wz4sRc for ; Fri, 11 Mar 2022 11:20:44 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-ej1-x62a.google.com with SMTP id a8so18393085ejc.8 for ; Fri, 11 Mar 2022 03:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=0AGYX2o1qvlLqCX2oXD/DGhZQW0YTOhSESGxyyDuJoE=; b=VXqMkEfaYeaGvoQYnPbfyX7RBS4Srt7Ws0r6K9Fj9qBZU4uMFyUAhJPAVSjBYlYoIb Zfsg9cBcIuZdEvdTjTIxdAuK0MLRGyPIvCYK6SNCWfq8TB6dCuZc88CA3+IM/8jri4LS FPZtR4J0qJR4Y4Ztu9eKKdL7mo12dUWyUZWkoWqEon2Oh4ljhPifhd36WzfB9KX8dAFD Octh1OdDPz+Vzvhy3rwhhhJ1PdmZz0HleK8hrwDsTchjPMSLX8Ke7nGJzAlidbULtqyX WEstYNDsdp/gQAc90dmlduweYn8kJ1t5hXTST1Bcjaq3FBMgv0lRt0Gv9UqDdwZu89Dh cdxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=0AGYX2o1qvlLqCX2oXD/DGhZQW0YTOhSESGxyyDuJoE=; b=OfEIOVVQD61xioY7zWADJmJzvLQrR3rM1GHviU2/d3gGinZ1Kq5tnqrCW1n/bXkS47 csjS0W9de63vM9ai2Pf/RNfKGtJ+CAw5HyvRFLMkQJbbX6eFf1UU9IXlthft9cnQCt+F 7dQLDDnr8vAThDuPQql3a7xJb3PiInTzLRm/1e5Go9iPTV1nOlHAJhsfQdSQX4bOab9S wn3Rx/4zxOF4VcTQh0QpNkz4f6x9VPKltmFanB6qFf8WoyYNRd6e+vsTn6DuUzNwoUDc 9+1v8hqBx3PeZjzEFiRUY6QqjAES/+YIJxq4a+iUQUamrHkkPWv1jYn3lCnXzerjPHj8 Y4Uw== X-Gm-Message-State: AOAM5303uXQdeNsf8zV0k66SxfhOIMlCT3U6rUkQA43r7vXoQF2fNAJ8 LreonEaYYnWm1Ki8Ff5QWzPHc2oAIbs= X-Google-Smtp-Source: ABdhPJydA/pgSWWOWGFmfDRHmIE/khlTrrpK3O4OE5O1k6GO/JusU419BIMlA4gyIcDD4Pps6GW/QA== X-Received: by 2002:a17:907:d16:b0:6d6:e3b6:9cd8 with SMTP id gn22-20020a1709070d1600b006d6e3b69cd8mr8148044ejc.94.1646997642647; Fri, 11 Mar 2022 03:20:42 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id gj18-20020a170907741200b006da82539c83sm2870118ejc.73.2022.03.11.03.20.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Mar 2022 03:20:41 -0800 (PST) Date: Fri, 11 Mar 2022 12:20:39 +0100 From: Gary Jennejohn To: Hans Petter Selasky Cc: Alexander Leidinger , current@freebsd.org Subject: Re: What are the in-kernel functions to format time? Message-ID: <20220311122039.4ecff61c@ernst.home> In-Reply-To: References: <20220311104942.Horde.BX4nDaPVTH6Lz85SCVNcopM@webmail.leidinger.net> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KFNlc6D8Wz4sRc X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=VXqMkEfa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-0.95 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.949]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[0.998]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from]; MLMMJ_DEST(0.00)[current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 11 Mar 2022 11:01:03 +0100 Hans Petter Selasky wrote: > On 3/11/22 10:49, Alexander Leidinger wrote: > > Hi, > > > > I'm looking for a function to convert bintime to a human readable format > in the kernel... and what is the usual format we use? > > > > > > The use case for this is: if something throws a log from the kernel > about a signal, I want to know when it happened, or in terms of code see > below (tabs are most probably messed up). > > > > Do we have some kind of policy in terms of kernel messages and > timestamps? Like "do not commit logging with timestamps"? I have the > code below because I needed it at least once and think something like > this (in a human readably shape) would be beneficial to have in the tree. > > > > Hi, > > I think our kernel printer doesn't support this: > > sys/kern/subr_prf.c > Do you mean the %zd? kvprintf() checks for a zflag and handles the argument as size_t or ssize_t, depending on whether the sign is positive or negative. However, %n isn't supported. > If you need to extend the format, please check other OS'es too, like > OpenBSD, NetBSD and Linux, what they support, so there won't be any > obvious conflicts when moving code cross platforms! > -- Gary Jennejohn From nobody Fri Mar 11 15:57:33 2022 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 209F21A11EED for ; Fri, 11 Mar 2022 15:57:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KFVvN00YWz4TkN for ; Fri, 11 Mar 2022 15:57:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe29.google.com with SMTP id g21so9940384vsp.6 for ; Fri, 11 Mar 2022 07:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7d4E251zW3L9IsIXeP7wuCsLY/w83UgSZMomz9t95Sw=; b=NLEJPnhdsF+v9I0X28OMP56mrk3pZzvOXWf0bPVRs/jGL40rxotSjyMk5/SKeempE6 FFTCRhEzbwMIyVrulD1VrtBZ9Q0PHfpi4VM+sCQPt0RdRp2XyV1QApIcBOVldenxgPFU JOHVuVBxDNv6xDuTin2zBfU59HMXeWIu3pFrjiW8PUSZjrwDn+1JoWmSzG997/90DckE BG6BGEl76wiByGZN7gDPKRbL3E2URaVFijP4BCcPg3zSXA93J7f0VSPmO/Oxr6BnIHzY sgqNR70c4DIT3Nw2NBx9Cfr2keC9YaiqZhHS0y5sLIEAdJbJPTuamdy/zt9FM/JijC38 Y7Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7d4E251zW3L9IsIXeP7wuCsLY/w83UgSZMomz9t95Sw=; b=J5XgtZKT0h5otEwYu2KBe4U9DZob7ecC+gMzG32bwQh5PS4mmwno2ltdD3tSjpjXb9 jCQ/SmgWfiwwsEltjas3UbQ7Y/7H+wymI72uFBDsRe3AGFFO0uAtBWxzp0J0PIHFJtxD DTAywmBzF4sy3gM+XFklawOqGAyoWRqkHQkQ+VccY+CKQKkRNVRP1AlQm2qJIPe2yEEU Y8V/AfuUjxXrjB+qc6qpmczI2ZPbBDXoAuzQ6iJ/mttO4MRrXJPHzeBOVuQch+O4eWZB o/KT6nZ+aE6TyfxusOpZK4IxTskzpbZaiTBTSqsZQvEgpa2edfe/BR9hfix4PLOLZGXV 4BYQ== X-Gm-Message-State: AOAM532aFUXn2kgZpqnww1m3njwE0GbqwSQFXOm56MdXXXS3ee60P6Et cH9KsE5pq4kYSxxKrU7R6wUNJrJarBgfKRbbqHufDrswTnw= X-Google-Smtp-Source: ABdhPJyAWEaPVN9KWURW4u2g53RMzMjE/+7nh85DX5/R1IltciHJVC5+iNG51sb8W5J6xZeaE1jAgvtbvFbNYPL7Kqs= X-Received: by 2002:a05:6102:2139:b0:320:cf2a:4f3c with SMTP id f25-20020a056102213900b00320cf2a4f3cmr5334429vsg.13.1647014264876; Fri, 11 Mar 2022 07:57:44 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20220311105149.Horde.uO0yyQjwC3xmwZvuZWV1ADl@webmail.leidinger.net> In-Reply-To: <20220311105149.Horde.uO0yyQjwC3xmwZvuZWV1ADl@webmail.leidinger.net> From: Warner Losh Date: Fri, 11 Mar 2022 08:57:33 -0700 Message-ID: Subject: Re: What are the in-kernel functions to print human readable timestamps (bintime)? To: Alexander Leidinger Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000032c60805d9f3648f" X-Rspamd-Queue-Id: 4KFVvN00YWz4TkN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=NLEJPnhd; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e29) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e29:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --00000000000032c60805d9f3648f Content-Type: text/plain; charset="UTF-8" On Fri, Mar 11, 2022 at 2:52 AM Alexander Leidinger wrote: > Hi, > > I'm looking for a function to convert bintime to a human readable > format in the kernel... and what is the usual format we use? > Yes. We don't generally log it. > > The use case for this is: if something throws a log from the kernel > about a signal, I want to know when it happened, or in terms of code > see below (tabs are most probably messed up). > > Do we have some kind of policy in terms of kernel messages and > timestamps? Like "do not commit logging with timestamps"? Correct. The kernel doesn't know enough to properly render timestamps, nor should it. It's a lot more complicated than you'd expect, and the simple, naive implementation has too many flaws... > I have the > code below because I needed it at least once and think something like > this (in a human readably shape) would be beneficial to have in the > tree. > I really don't want to see code like that in the tree. Having it per-message in an ad-hoc manner strikes me as quite unwise, since how do you interpret it after the fact, especially in the face of adjustments to boottime for any time adjustments that happen after the event. Now, having said that, having good timestamps in the dmesg buffer is a desirable feature. 'Good' is subjective here, and there are times early in boot where it's simply not possible to get a time better than '0' until the timehands are ticking... But the dmesg buffer has more than what dmesg prints: it has syslog'd things (at least some of them) as well. There's also a priority that some lines have. <3>Foo, for example. It would be better, imho, to add a timestamp to the start of the lines (perhaps optionally since that might be expensive in $HUGE systems, or at times of extreme dmesg spew and the could be omitted in those cases). If you are interested in just the log messages, it wouldn't be terrible since we already add stuff to what's printed for the priority. We could say <3,seconds-since-boot.fracsec> instead of just <3> and hack dmesg to print the right thing. Warner > Code: > ---snip--- > diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c > index 4a15bd45355..a83eebe0736 100644 > --- a/sys/kern/kern_sig.c > +++ b/sys/kern/kern_sig.c > @@ -80,6 +80,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -3440,14 +3441,18 @@ sigexit(struct thread *td, int sig) > */ > if (coredump(td) == 0) > sig |= WCOREFLAG; > - if (kern_logsigexit) > + if (kern_logsigexit) { > + struct bintime now; > + > + getbintime(&now); > log(LOG_INFO, > - "pid %d (%s), jid %d, uid %d: exited on " > - "signal %d%s\n", p->p_pid, p->p_comm, > + "%zd: pid %d (%s), jid %d, uid %d: exited on " > + "signal %d%s\n", now.sec, p->p_pid, p->p_comm, > p->p_ucred->cr_prison->pr_id, > td->td_ucred->cr_uid, > sig &~ WCOREFLAG, > sig & WCOREFLAG ? " (core dumped)" : ""); > + } > } else > PROC_UNLOCK(p); > exit1(td, 0, sig); > ---snip--- > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF > --00000000000032c60805d9f3648f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 11, 2022 at 2:52 AM Alexa= nder Leidinger <Alexander@lei= dinger.net> wrote:
Hi,

I'm looking for a function to convert bintime to a human readable=C2=A0=
format in the kernel... and what is the usual format we use?

Yes. We don't generally log it.
=C2=A0<= /div>

The use case for this is: if something throws a log from the kernel=C2=A0 <= br> about a signal, I want to know when it happened, or in terms of code=C2=A0 =
see below (tabs are most probably messed up).

Do we have some kind of policy in terms of kernel messages and=C2=A0
timestamps? Like "do not commit logging with timestamps"?

Correct. The kernel=C2=A0doesn't=C2=A0know en= ough to properly render timestamps,
nor should it. It's a lot= more complicated than you'd expect, and the simple,
naive=C2= =A0implementation has too many flaws...
=C2=A0
I have the=C2=A0
code below because I needed it at least once and think something like=C2=A0=
this (in a human readably shape) would be beneficial to have in the=C2=A0 <= br> tree.

I really don't want to see co= de like that in the tree. Having it per-message
in an ad-hoc mann= er strikes me as quite unwise, since how do you interpret
it afte= r the fact, especially in the face of adjustments to boottime=C2=A0for any<= /div>
time adjustments that happen after the event.

Now, having said that, having good timestamps in the dmesg buffer is<= /div>
a desirable feature. 'Good' is subjective here, and there= are times early
in boot where it's simply not possible to ge= t a time better than '0' until
the timehands=C2=A0are tic= king...=C2=A0 But the dmesg buffer has more than what
dmesg print= s: it has syslog'd=C2=A0things (at least some of them) as well. There&#= 39;s
also a priority that some lines have. <3>Foo, for exam= ple. It would be better,
imho, to add a timestamp to the start of= the lines (perhaps optionally
since that might be expensive in $= HUGE systems, or at times of
extreme dmesg spew and the could be = omitted in those cases).
If you are interested in just the log me= ssages, it wouldn't be terrible
since we already add stuff to= what's printed for the priority. We could say
<3,seconds-= since-boot.fracsec> instead of just <3> and hack dmesg
t= o print the right thing.

Warner
=C2=A0
Code:
---snip---
diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c
index 4a15bd45355..a83eebe0736 100644
--- a/sys/kern/kern_sig.c
+++ b/sys/kern/kern_sig.c
@@ -80,6 +80,7 @@ __FBSDID("$FreeBSD$");
=C2=A0 #include <sys/sysent.h>
=C2=A0 #include <sys/syslog.h>
=C2=A0 #include <sys/sysproto.h>
+#include <sys/time.h>
=C2=A0 #include <sys/timers.h>
=C2=A0 #include <sys/unistd.h>
=C2=A0 #include <sys/wait.h>
@@ -3440,14 +3441,18 @@ sigexit(struct thread *td, int sig)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (coredump(= td) =3D=3D 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0sig |=3D WCOREFLAG;
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (kern_logsigexit= )
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (kern_logsigexit= ) {
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0struct bintime now;
+
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0getbintime(&now);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0log(LOG_INFO,
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0"pid %d (%s), jid %d, uid %d: exited on "=
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0"signal %d%s\n", p->p_pid, p->p_com= m,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0"%zd: pid %d (%s), jid %d, uid %d: exited on &= quot;
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0"signal %d%s\n", now.sec, p->p_pid, p-= >p_comm,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0p->p_ucred->cr_prison->pr_id,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0td->td_ucred->cr_uid,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sig &~ WCOREFLAG,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sig & WCOREFLAG ? " (core dumped)&q= uot; : "");
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PROC_UNLOCK(p= );
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exit1(td, 0, sig);
---snip---

Bye,
Alexander.

--
h= ttp://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF=
htt= p://www.FreeBSD.org=C2=A0 =C2=A0 netchild@FreeBSD.org=C2=A0 : PGP 0x8F3= 1830F9F2772BF
--00000000000032c60805d9f3648f-- From nobody Fri Mar 11 16:17:11 2022 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 71BAA1A16A95 for ; Fri, 11 Mar 2022 16:17:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4KFWL16ySGz4XnM for ; Fri, 11 Mar 2022 16:17:29 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 7846D260197; Fri, 11 Mar 2022 17:17:22 +0100 (CET) Message-ID: Date: Fri, 11 Mar 2022 17:17:11 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: What are the in-kernel functions to format time? Content-Language: en-US To: gljennjohn@gmail.com Cc: Alexander Leidinger , current@freebsd.org References: <20220311104942.Horde.BX4nDaPVTH6Lz85SCVNcopM@webmail.leidinger.net> <20220311122039.4ecff61c@ernst.home> From: Hans Petter Selasky In-Reply-To: <20220311122039.4ecff61c@ernst.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KFWL16ySGz4XnM X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-0.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 3/11/22 12:20, Gary Jennejohn wrote: > Do you mean the %zd? kvprintf() checks for a zflag and handles the > argument as size_t or ssize_t, depending on whether the sign is > positive or negative. Hi, Given that time is a 64-bit value, then probably "%llu", and (unsigned long long)bintime would do it, but then you need that cast. ./_types.h:typedef __int64_t __sbintime_t; I was tinking of a %XXX that divides the value somehow into something more readable, maybe suffixing "ns" or "ms" or "us" or something. --HPS From nobody Fri Mar 11 17:20:34 2022 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 B7EB819FC690 for ; Fri, 11 Mar 2022 17:20:44 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4KFXkz4X6Jz4jCv for ; Fri, 11 Mar 2022 17:20:43 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 22BHKYBB085156; Fri, 11 Mar 2022 17:20:34 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 22BHKYOY085155; Fri, 11 Mar 2022 17:20:34 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202203111720.22BHKYOY085155@donotpassgo.dyslexicfish.net> Date: Fri, 11 Mar 2022 17:20:34 +0000 Organization: Dyslexic Fish To: imp@bsdimp.com, Alexander@leidinger.net Cc: current@FreeBSD.org Subject: Re: What are the in-kernel functions to print human readable timestamps (bintime)? References: <20220311105149.Horde.uO0yyQjwC3xmwZvuZWV1ADl@webmail.leidinger.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 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: 8bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Fri, 11 Mar 2022 17:20:35 +0000 (GMT) X-Rspamd-Queue-Id: 4KFXkz4X6Jz4jCv X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-2.36 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.66)[-0.656]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; MLMMJ_DEST(0.00)[current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: > since we already add stuff to what's printed for the priority. We could say > <3,seconds-since-boot.fracsec> instead of just <3> and hack dmesg > to print the right thing. Isn't that what kern.msgbuf_show_timestamp does already? I use that, along with this script: 17:15 (40.0°C 400) [2] (49) "completions" root@thompson# cat /usr/common/bin/dmesg-uptime-to-date #!/bin/sh -efu set -efu boottime="$(sysctl -n kern.boottime | gawk '{printf "%d", gensub ("^.* sec = ([1-9][0-9]*), .*$", "\\1", 1)}')" [ -z "$(printf '%s' "$boottime" | egrep '^0$|^[1-9][0-9]*$')" ] && { printf 'Invalid boottime retrieved.\n' >& 2; exit 1; } dmesg "$@" | gawk -v boottime="$boottime" ' { uptime = gensub ("^\\[([1-9][0-9]*)\\] .*$", "\\1", 1) if (uptime == $0) realtime = "??? ?? ??:??;??" else realtime = strftime ("%b %d %T", uptime + boottime) print realtime " " $0 }' Mar 11 00:41:51 [3568757] Limiting closed port RST response from 313 to 200 packets/sec Mar 11 00:41:54 [3568760] Limiting closed port RST response from 308 to 200 packets/sec Mar 11 06:23:28 [3589254] icmp redirect from 183.196.23.176: 192.168.2.104 => 183.196.23.161 etc. Cheers, Jamie From nobody Sat Mar 12 17:44:07 2022 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 40DE01A1C2AF for ; Sat, 12 Mar 2022 17:44:20 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KG9Cl01zXz4kgW for ; Sat, 12 Mar 2022 17:44:19 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) client-signature ECDSA (P-256)) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 189E21A01; Sat, 12 Mar 2022 18:44:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1647107050; 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=fRUW9WUBfHVDohcfMg4N6VylI+FJ9mGtha+AzWvbC+I=; b=WM7g9lZvZDA2RF95W8Wuev6T6U7DOLbfstbOaie0Ib8eVmk6mpI2yC2lXRz2Q0CEP/mIq5 0kPjCkluXmx6EiTIIddK7t4mIME7lhD9yGEJHuomcGQiB3xGzEynSUjxFVDttN76fs8s1y /jYKbR6SmMYGVryN8qa535TooKQJAmSYr21cOcYS/6Hj9PkWem+/KrVLLKeTbACemi4Y9K hmUSRMtPMrMG7mVgqsJ9D1CxkWIYr84NGMT29wfp7LPOL5anUEEc8HktRQCCaQYW86zcxT IiGrlXAjjvfJxIGjTPyIMz+gu7HL9XhAU9Gmh29v4lZn3TFDW9pjLnJ2i/kNtA== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id D6D10A387; Sat, 12 Mar 2022 18:44:07 +0100 (CET) Date: Sat, 12 Mar 2022 18:44:07 +0100 Message-ID: <20220312184407.Horde.T5lVaVvzo9-ulIE4UZaKY1H@webmail.leidinger.net> From: Alexander Leidinger To: Warner Losh Cc: FreeBSD Current Subject: Re: What are the in-kernel functions to print human readable timestamps (bintime)? References: <20220311105149.Horde.uO0yyQjwC3xmwZvuZWV1ADl@webmail.leidinger.net> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_cY8l_FQJmHsikIO5P-QFghT"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4KG9Cl01zXz4kgW X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=WM7g9lZv; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-5.07 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-0.97)[-0.969]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_cY8l_FQJmHsikIO5P-QFghT Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Warner Losh (from Fri, 11 Mar 2022 08:57:33 -0700)= : > On Fri, Mar 11, 2022 at 2:52 AM Alexander Leidinger > wrote: > >> Hi, >> >> I'm looking for a function to convert bintime to a human readable >> format in the kernel... and what is the usual format we use? >> > > Yes. We don't generally log it. Would it be acceptable in this particular case (or should I keep this=20=20 change=20for me)? I have to check out the kern.msgbuf_show_timestamp part in this=20=20 thread,=20which looks interesting. It may fit my needs here. >> The use case for this is: if something throws a log from the kernel >> about a signal, I want to know when it happened, or in terms of code >> see below (tabs are most probably messed up). >> >> Do we have some kind of policy in terms of kernel messages and >> timestamps? Like "do not commit logging with timestamps"? > > > Correct. The kernel doesn't know enough to properly render timestamps, > nor should it. It's a lot more complicated than you'd expect, and the > simple, > naive implementation has too many flaws... I'm aware that it is complicated. IMO too complicated for a full=20=20 implementation=20which will satisfy all needs. >> I have the >> code below because I needed it at least once and think something like >> this (in a human readably shape) would be beneficial to have in the >> tree. >> > > I really don't want to see code like that in the tree. Having it per-mess= age > in an ad-hoc manner strikes me as quite unwise, since how do you interpre= t > it after the fact, especially in the face of adjustments to boottime for = any > time adjustments that happen after the event. Sorry, I was not verbose enough in my mail it seems. I do _not_ want=20=20 to=20commit this code like it is. I was looking for stuff which could=20=20 print=20something human readable, like "2022-12-03 14:23:22.45=20=20 'kernel-time'"=20(just as an example). I don't want to push the TZ into=20= =20 the=20kernel, or the knowledge if the cmos clock is set to localtime or=20= =20 UTC.=20I want to provide an admin with a way to determine when such a=20=20 message=20may have printed. Currently there is no way to know at which=20= =20 time=20it was printed. The admin needs to know if the clock is set in=20=20 UTC=20or localtime, and how to calculate the wall-clock time from this,=20= =20 which=20is less heavy on the implementation and provides a mean to=20=20 correlate=20the mesage with some action on the machine. > Now, having said that, having good timestamps in the dmesg buffer is > a desirable feature. 'Good' is subjective here, and there are times early > in boot where it's simply not possible to get a time better than '0' unti= l > the timehands are ticking... But the dmesg buffer has more than what > dmesg prints: it has syslog'd things (at least some of them) as well. > There's > also a priority that some lines have. <3>Foo, for example. It would be > better, > imho, to add a timestamp to the start of the lines (perhaps optionally > since that might be expensive in $HUGE systems, or at times of > extreme dmesg spew and the could be omitted in those cases). > If you are interested in just the log messages, it wouldn't be terrible > since we already add stuff to what's printed for the priority. We could s= ay > <3,seconds-since-boot.fracsec> instead of just <3> and hack dmesg > to print the right thing. From the other message in the thread it looks like=20=20 kern.msgbuf_show_timestamp=20is what you describe here? And it looks like kern.msgbuf_show_timestamp is not the same as=20=20 printing=20a timestamp to the console... (it looks like the timestamp is=20= =20 printed=20in the dmesg, but not to the console, which is what I have in=20= =20 mind=20for this particular message... respectively could be added log()=20= =20 with=20a sysctl to activate it or not). Bye, Alexander. > Warner > > >> Code: >> ---snip--- >> diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c >> index 4a15bd45355..a83eebe0736 100644 >> --- a/sys/kern/kern_sig.c >> +++ b/sys/kern/kern_sig.c >> @@ -80,6 +80,7 @@ __FBSDID("$FreeBSD$"); >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -3440,14 +3441,18 @@ sigexit(struct thread *td, int sig) >> */ >> if (coredump(td) =3D=3D 0) >> sig |=3D WCOREFLAG; >> - if (kern_logsigexit) >> + if (kern_logsigexit) { >> + struct bintime now; >> + >> + getbintime(&now); >> log(LOG_INFO, >> - "pid %d (%s), jid %d, uid %d: exited on " >> - "signal %d%s\n", p->p_pid, p->p_comm, >> + "%zd: pid %d (%s), jid %d, uid %d: exited on= " >> + "signal %d%s\n", now.sec, p->p_pid, p->p_com= m, >> p->p_ucred->cr_prison->pr_id, >> td->td_ucred->cr_uid, >> sig &~ WCOREFLAG, >> sig & WCOREFLAG ? " (core dumped)" : ""); >> + } >> } else >> PROC_UNLOCK(p); >> exit1(td, 0, sig); >> ---snip--- >> >> Bye, >> Alexander. >> >> -- >> http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF >> http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF >> --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_cY8l_FQJmHsikIO5P-QFghT Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmIs2+YACgkQEg2wmwP4 2IYCyw//a5EQ6l4QVfwxXUXGOrRKRkBmL+QkfLvaGFLExi8V1i17/QGsRpOCf4Pl WKv5e1vVI9okZiiGeBwuL51lh4wzc9vRwOq2z2UvxRPaP9u+HfgOSOJYNJMW/+mf y/73d/NvCGLsELUDyYr08wKYTChURqrliPWeHvzn7UsgW8TPzht8hnOqOdr8vM1G JW7Kdk2FvgrXIvG8eE4FUwOtPBXhRNlViyr4cDBUhsTPiAlpIwH7OhxpnkNDEMkN bJZkBzfGAxxunfFNPaaUVkKuiGIcZ3FiKRn3Oa/arTsMO4vpjKLUzY8KWyqh5kCF GdIAbaZdXAov46A/7Zw67j272PA7vd9/Gw/6td8BZwVlTSC6KH/DLVCXLGm9k2LK ThDmxbjzrqBxZC9oV21df55Nj5E8A0X1gx6pYu43VVEWTWuw7a6GlDVcdGZ094Ky xA1kSlM19bPA1siK5n7laeI5zg2V67cYKnCUgVhtqP9cNAmWaicVPdP/ppumG2OI 2iKg+iK2LLwm+73AdYChCtGhQ8AcUMlZZTs83vu1Hhl66nWnoAq4LxyVH6euGfvb PnSlPaZPP3ECjc+Hh1iSkX6duGnTn0v7zh/akwMrdtbyjqPhTFcXJmLiPDcLy/Cy JvYS2opoYGibBTdavxkCf/zMEI9ObZdysvxdx2Vw9gqa9J4WBOs= =O5pL -----END PGP SIGNATURE----- --=_cY8l_FQJmHsikIO5P-QFghT-- From nobody Tue Mar 15 16:48:14 2022 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 9450C1A2ED76 for ; Tue, 15 Mar 2022 16:52:40 +0000 (UTC) (envelope-from yasu@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KHzwm3gkBz4tNZ; Tue, 15 Mar 2022 16:52:40 +0000 (UTC) (envelope-from yasu@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647363160; 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=N1f7v/w8PbLSzE37FHOvuIOy1pAPPmKv0bVZLB6VEqY=; b=e/CK4uIxGAH0nKnf2lw4CJWc7AReqHJbYZ3j+rQWHqEh8dtADotSZ7b1YebqJgmndsUXeD GuhMajPrFSYi/9SQg4ofV39qsHxrmM2vkHYRh9tmZJV2ZAAlhEM4BhmIW6HMlGTVCHTyN1 gl4hTHq8UDT/V5yo4ncmYMbAvWsZysiPrbcUQYbjM+ad0GkFM0jJSMK3wMDjzi/x40jfz8 Di0AWs82UK8Wf2cmzLkS+zPYTfdKhJbJe9oaTVxb3HKgHXnD8N61NS8CRoWNcXHfxxab0D VX9AXRidtkP2UpR5Lypd7PnvP/GidkS3OV/Cw2MNE/oeb+nIvx0zh6qJmsjONg== Received: from localhost (unknown [IPv6:240b:11:220:fe00:ddbe:4a78:8df7:bac1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: yasu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id A23DBF7FE; Tue, 15 Mar 2022 16:52:39 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Date: Wed, 16 Mar 2022 01:48:14 +0900 (JST) Message-Id: <20220316.014814.1921859297745365117.yasu@FreeBSD.org> To: freebsd-current@freebsd.org Subject: getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS From: Yasuhiro Kimura X-Mailer: Mew version 6.8 on Emacs 29.0.50 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: base64 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647363160; 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=N1f7v/w8PbLSzE37FHOvuIOy1pAPPmKv0bVZLB6VEqY=; b=klXHZICOAFO2vOe54/i+rm9MeWhmpOhqJ1wZ8+cpy3hZlF2xpHSZCiKntA5wtrEqFRTUnb 4W8JylFpoxeF0QlA87rCKloSXYIUjfuSPjCwYgVWZ9JuYmKI835o7UUMU3mNZTzmrOQTBM roucoL2izLt1lPP++SP7FFVEZBO1VbBDw3FHO4ld3xdTWs/vozIioqTdCqIO+dYLWX65fB MlO1/zER8bz0GOYLosmTaS+MRJdST8mFYUE+5YXaQivQV1Zt/4VgoWdmQMVWTwTVi7sDVx Ar7dy1p4TLzdOsQ03YutTgwKjJB9ugwsemJ/dmC9ZeYyOqOON3Z6heo93myTKg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647363160; a=rsa-sha256; cv=none; b=ZxVo9pwwkufxHnU8ZDycQh6ISuv/YGWQ/k8ogkL2xasl5/NXnbTnlJphFjYFoCgZb1JYNq pM2ECgeQHdmFlO2h0hb2PczzUPgnbwjvbgj5o+GafV/3YvpoW1YTMSsjBX9NxLRwacwf8c C6l4iTUrRYQxz+oGNl/t3MnWzTXp8/vj+hYX16WSOyXMTqp1vTZn2glxjqfzAxlloF7ZPS +zAPcseXSbb8OfrIvsbv4eR5XoJqgD6Pmvp6gDZjFOQnXZiYfvmVzAluGqkqXixhaf7uRH 666pfbvVd/c6QATul/+GIzPc+oGRWtIpR0tN7AniumqHDSqeK4IaKoG+LzS/pQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N SGVsbG8sDQoNCkkgdXNlIG5ldGdyb3VwIHN0b3JlZCBpbiBOSVMgZGF0YWJhc2UgdG8gY29udHJv bCBhY2Nlc3MgdG8gTkZTIHNlcnZlci4NClJlY2VudGx5IEkgYWRkZWQgc29tZSBob3N0cyB0byBu ZXRncm91cCB0aGF0IGFjY2VzcyB0byBORlMgc2VydmVyIGlzDQpwZXJtaXR0ZWQuIEFuZCBhZnRl ciB0aGF0IG1vdW50ZCg4KSB3cml0ZXMgc3VjaCBtZXNzYWdlcyBhcyBmb2xsb3dpbmcNCnRvIHN5 c2xvZy4NCg0KTWFyIDE1IDE3OjE2OjU5IHNlcnZlciBtb3VudGRbNDI3Nl06IGNhbid0IGdldCBh ZGRyZXNzIGluZm8gZm9yIGhvc3QgaG9zdDM0Lm5mcy4NCk1hciAxNSAxNzoxNjo1OSBzZXJ2ZXIg bW91bnRkWzQyNzZdOiBiYWQgaG9zdCBob3N0MzQubmZzLiBpbiBuZXRncm91cCBwZXJtaXR0ZWRf bmZzX2NsaWVudHMsIHNraXBwaW5nDQoNClRoZSBuZXRncm91cCBlbnRyeSB1c2VkIHRvIGNvbnRy b2wgYWNjZXNzIHRvIE5GUyBzZXJ2ZXIgaW5jbHVkZXMgYSBsb3QNCm9mIGhvc3Qgc3VjaCBhcyBm b2xsb3dpbmcNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KeWFzdUBzZXJ2ZXJbMTAwMl0lIHlwbWF0Y2ggLWsg cGVybWl0dGVkX25mc19jbGllbnRzICBuZXRncm91cA0KcGVybWl0dGVkX25mc19jbGllbnRzOiAo aG9zdDAxLm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAgICAgICAgICAgICAgKGhvc3QwMi5u ZnMuZXhhbXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAgIChob3N0MDMubmZzLmV4YW1wbGUu Y29tLCwpICAgICAgICAgICAgICAgICAgICAgICAoaG9zdDA0Lm5mcy5leGFtcGxlLmNvbSwsKSAg ICAgICAgICAgICAgICAgICAgICAoaG9zdDA1Lm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAg ICAgICAgICAgIChob3N0MDYubmZzLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAg IChob3N0MDcubmZzLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAoaG9zdDA4Lm5m cy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAgICAgICAgICAgICAgKGhvc3QwOS5uZnMuZXhhbXBs ZS5jb20sLCkgICAgICAgICAgICAgICAgICAgICAgKGhvc3QxMC5uZnMuZXhhbXBsZS5jb20sLCkg ICAgICAgICAgICAgICAgICAgICAoaG9zdDExLm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAg ICAgICAgICAgICAoaG9zdDEyLm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAgICAgICAgICAg KGhvc3QxMy5uZnMuZXhhbXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAgICAgIChob3N0MTQu bmZzLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAgIChob3N0MTUubmZzLmV4YW1w bGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAgKGhvc3QxNi5uZnMuZXhhbXBsZS5jb20sLCkg ICAgICAgICAgICAgICAgICAgICAgKGhvc3QxNy5uZnMuZXhhbXBsZS5jb20sLCkgICAgICAgICAg ICAgICAgICAgIChob3N0MTgubmZzLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAg ICAoaG9zdDE5Lm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAgICAgICAgICAgICAoaG9zdDIw Lm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAgICAgICAgICAgIChob3N0MjEubmZzLmV4YW1w bGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAgIChob3N0MjIubmZzLmV4YW1wbGUuY29tLCwp ICAgICAgICAgICAgICAgICAgICAoaG9zdDIzLm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAg ICAgICAgICAgICAgKGhvc3QyNC5uZnMuZXhhbXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAg ICAgKGhvc3QyNS5uZnMuZXhhbXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAgICAoaG9zdDI2 Lm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAgICAgICAgICAgICAoaG9zdDI3Lm5mcy5leGFt cGxlLmNvbSwsKSAgICAgICAgICAgICAgICAgICAgKGhvc3QyOC5uZnMuZXhhbXBsZS5jb20sLCkg ICAgICAgICAgICAgICAgICAgICAgIChob3N0MjkubmZzLmV4YW1wbGUuY29tLCwpICAgICAgICAg ICAgICAgICAgICAgIChob3N0MzAubmZzLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAg ICAgKGhvc3QzMS5uZnMuZXhhbXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAgICAgKGhvc3Qz Mi5uZnMuZXhhbXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAgIChob3N0MzMubmZzLmV4YW1w bGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAgICAoaG9zdDM0Lm5mcy5leGFtcGxlLmNvbSws KSAgICAgICAgICAgICAgICAgICAgICAoaG9zdDM1Lm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAg ICAgICAgICAgICAgIChob3N0MzYubmZzLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAg ICAgIChob3N0MzcubmZzLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAoaG9zdDM4 Lm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAgICAgICAgICAgICAgKGhvc3QzOS5uZnMuZXhh bXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAgICAgKGhvc3Q0MC5uZnMuZXhhbXBsZS5jb20s LCkgICAgICAgICAgICAgICAgICAgICAoaG9zdDQxLm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAg ICAgICAgICAgICAgICAoaG9zdDQyLm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAgICAgICAg ICAgKGhvc3Q0My5uZnMuZXhhbXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAgICAgIChob3N0 NDQubmZzLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAgIChob3N0NDUubmZzLmV4 YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAgKGhvc3Q0Ni5uZnMuZXhhbXBsZS5jb20s LCkgICAgICAgICAgICAgICAgICAgICAgKGhvc3Q0Ny5uZnMuZXhhbXBsZS5jb20sLCkgICAgICAg ICAgICAgICAgICAgIChob3N0NDgubmZzLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAg ICAgICAoaG9zdDQ5Lm5mcy5leGFtcGxlLmNvbSwsKSAgICAgICAgICAgICAgICAgICAgICAoaG9z dDUwLm5mcy5leGFtcGxlLmNvbSwsKQ0KeWFzdUBzZXJ2ZXJbMTA1NF0lDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCkFuZCBpZiBJIHJlbW92ZSBob3N0MzQubmZzLmV4YW1wbGUuY29tIGZyb20gcGVybWl0dGVk X25mc19jbGllbnRzLA0KdGhlbiBzeXNsb2cgbWVzc2FnZXMgb2YgbW91bnRkKDEpIGNoYW5nZXMg YXMgZm9sbG93aW5nLg0KDQpNYXIgMTUgMTc6MTY6NTkgc2VydmVyIG1vdW50ZFs0Mjc2XTogY2Fu J3QgZ2V0IGFkZHJlc3MgaW5mbyBmb3IgaG9zdCBob3N0MzUubmZzLg0KTWFyIDE1IDE3OjE2OjU5 IHNlcnZlciBtb3VudGRbNDI3Nl06IGJhZCBob3N0IGhvc3QzNS5uZnMuIGluIG5ldGdyb3VwIHBl cm1pdHRlZF9uZnNfY2xpZW50cywgc2tpcHBpbmcNCg0KSXQgc2VlbXMgdG8gc3RvcCBwYXJzaW5n IHRoZSB2YWx1ZSBvZiB0aGUgbmV0Z3JvdXAgZW50cnkgaW4gaXRzIG1pZGRsZQ0KaWYgdGhlIGxl bmd0aCBpcyBsb25nZXIgdGhhbiBhIGNlcnRhaW4gdmFsdWUuDQoNCkkgY2hlY2tlZCB1c3Iuc2Jp bi9tb3VudGQvbW91bnRkLmMgYW5kIGZvdW5kIGl0IHVzZXMgZ2V0bmV0Z3JlbnQoMykgdG8NCnBh cnNlIHRoZSB2YWx1ZSBvZiBuZXRncm91cCBlbnRyeS4gU28gSSB3cm90ZSBmb2xsb3dpbmcgcHJv Z3JhbSB0bw0KY2hlY2sgaXRzIGJlaGF2aW9yLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQp5YXN1QHNlcnZl clsxMTUyXSUgY2F0IGxpc3RfbmV0Z3JvdXBfZW50cnkuYw0KI2luY2x1ZGUgPHN0ZGlvLmg+DQoj aW5jbHVkZSA8bGliZ2VuLmg+DQojaW5jbHVkZSA8bmV0ZGIuaD4NCg0KaW50DQptYWluKGludCBh cmdjLCBjaGFyICoqYXJndikNCnsNCiAgICBpZiAoYXJnYyAhPSAyKSB7DQogICAgICAgIGZwcmlu dGYoc3RkZXJyLCAiVXNhZ2U6ICVzIE5hbWVPZk5ldGdyb3VwXG4iLCBiYXNlbmFtZShhcmd2WzBd KSk7DQogICAgICAgIHJldHVybiAxOw0KICAgIH0NCiAgICBzZXRuZXRncmVudChhcmd2WzFdKTsN CiAgICBwcmludGYoIm5ldGdyb3VwOiAlc1xuIiwgYXJndlsxXSk7DQogICAgY2hhciAqaG9zdCwg KnVzZXIsICpkb21haW47DQogICAgd2hpbGUgKGdldG5ldGdyZW50KCZob3N0LCAmdXNlciwgJmRv bWFpbikpDQogICAgICAgIHByaW50ZigiXHRob3N0OiAlcywgdXNlcjogJXMsIGRvbWFpbjogJXNc biIsIGhvc3QsIHVzZXIsIGRvbWFpbik7DQogICAgZW5kbmV0Z3JlbnQoKTsNCiAgICByZXR1cm4g MDsNCn0NCnlhc3VAc2VydmVyWzExNTJdJQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJZiBuZXRncm91cCBl bnRyeSBpcyBzdG9yZWQgaW4gL2V0Yy9uZXRncm91cCwgdGhlbiB0aGUgdmFsdWUgaXMgcGFyc2Vk DQpwcm9wZXJseS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KeWFzdUBzZXJ2ZXJbMTA2MV0lIGNhdCAvZXRj L25ldGdyb3VwDQp2ZXJ5X2xvbmdfZmlsZV9lbnRyeSAgICAoaG9zdDEubG9uZy5sb25nLmxvbmcu ZXhhbXBsZS5jb20sLCkgXA0KICAgICAgICAgICAgICAgICAgICAgICAgKGhvc3QyLmxvbmcubG9u Zy5sb25nLmV4YW1wbGUuY29tLCwpIFwNCiAgICAgICAgICAgICAgICAgICAgICAgIChob3N0My5s b25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwsKSBcDQogICAgICAgICAgICAgICAgICAgICAgICAo aG9zdDQubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkgXA0KICAgICAgICAgICAgICAgICAg ICAgICAgKGhvc3Q1LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwpIFwNCiAgICAgICAgICAg ICAgICAgICAgICAgIChob3N0Ni5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwsKSBcDQogICAg ICAgICAgICAgICAgICAgICAgICAoaG9zdDcubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkg XA0KICAgICAgICAgICAgICAgICAgICAgICAgKGhvc3Q4LmxvbmcubG9uZy5sb25nLmV4YW1wbGUu Y29tLCwpIFwNCiAgICAgICAgICAgICAgICAgICAgICAgIChob3N0OS5sb25nLmxvbmcubG9uZy5l eGFtcGxlLmNvbSwsKSBcDQogICAgICAgICAgICAgICAgICAgICAgICAoaG9zdDEwLmxvbmcubG9u Zy5sb25nLmV4YW1wbGUuY29tLCwpIFwNCiAgICAgICAgICAgICAgICAgICAgICAgIChob3N0MTEu bG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkgXA0KICAgICAgICAgICAgICAgICAgICAgICAg KGhvc3QxMi5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwsKSBcDQogICAgICAgICAgICAgICAg ICAgICAgICAoaG9zdDEzLmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwpIFwNCiAgICAgICAg ICAgICAgICAgICAgICAgIChob3N0MTQubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkgXA0K ICAgICAgICAgICAgICAgICAgICAgICAgKGhvc3QxNS5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNv bSwsKSBcDQogICAgICAgICAgICAgICAgICAgICAgICAoaG9zdDE2LmxvbmcubG9uZy5sb25nLmV4 YW1wbGUuY29tLCwpIFwNCiAgICAgICAgICAgICAgICAgICAgICAgIChob3N0MTcubG9uZy5sb25n LmxvbmcuZXhhbXBsZS5jb20sLCkgXA0KICAgICAgICAgICAgICAgICAgICAgICAgKGhvc3QxOC5s b25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwsKSBcDQogICAgICAgICAgICAgICAgICAgICAgICAo aG9zdDE5LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwpIFwNCiAgICAgICAgICAgICAgICAg ICAgICAgIChob3N0MjAubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkgXA0KICAgICAgICAg ICAgICAgICAgICAgICAgKGhvc3QyMS5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwsKSBcDQog ICAgICAgICAgICAgICAgICAgICAgICAoaG9zdDIyLmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29t LCwpIFwNCiAgICAgICAgICAgICAgICAgICAgICAgIChob3N0MjMubG9uZy5sb25nLmxvbmcuZXhh bXBsZS5jb20sLCkgXA0KICAgICAgICAgICAgICAgICAgICAgICAgKGhvc3QyNC5sb25nLmxvbmcu bG9uZy5leGFtcGxlLmNvbSwsKSBcDQogICAgICAgICAgICAgICAgICAgICAgICAoaG9zdDI1Lmxv bmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwpIFwNCiAgICAgICAgICAgICAgICAgICAgICAgICho b3N0MjYubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkgXA0KICAgICAgICAgICAgICAgICAg ICAgICAgKGhvc3QyNy5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwsKSBcDQogICAgICAgICAg ICAgICAgICAgICAgICAoaG9zdDI4LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwpIFwNCiAg ICAgICAgICAgICAgICAgICAgICAgIChob3N0MjkubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20s LCkgXA0KICAgICAgICAgICAgICAgICAgICAgICAgKGhvc3QzMC5sb25nLmxvbmcubG9uZy5leGFt cGxlLmNvbSwsKQ0KKw0KeWFzdUBzZXJ2ZXJbMTA2Ml0lIC4vbGlzdF9uZXRncm91cF9lbnRyeSB2 ZXJ5X2xvbmdfZmlsZV9lbnRyeQ0KbmV0Z3JvdXA6IHZlcnlfbG9uZ19maWxlX2VudHJ5DQogICAg ICAgIGhvc3Q6IGhvc3QzMC5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwgdXNlcjogLCBkb21h aW46IA0KICAgICAgICBob3N0OiBob3N0MjkubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVz ZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDI4LmxvbmcubG9uZy5sb25nLmV4YW1w bGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAgIGhvc3Q6IGhvc3QyNy5sb25nLmxvbmcu bG9uZy5leGFtcGxlLmNvbSwgdXNlcjogLCBkb21haW46IA0KICAgICAgICBob3N0OiBob3N0MjYu bG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9z dDogaG9zdDI1LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQog ICAgICAgIGhvc3Q6IGhvc3QyNC5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwgdXNlcjogLCBk b21haW46IA0KICAgICAgICBob3N0OiBob3N0MjMubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20s IHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDIyLmxvbmcubG9uZy5sb25nLmV4 YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAgIGhvc3Q6IGhvc3QyMS5sb25nLmxv bmcubG9uZy5leGFtcGxlLmNvbSwgdXNlcjogLCBkb21haW46IA0KICAgICAgICBob3N0OiBob3N0 MjAubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAg aG9zdDogaG9zdDE5LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjog DQogICAgICAgIGhvc3Q6IGhvc3QxOC5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwgdXNlcjog LCBkb21haW46IA0KICAgICAgICBob3N0OiBob3N0MTcubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5j b20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDE2LmxvbmcubG9uZy5sb25n LmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAgIGhvc3Q6IGhvc3QxNS5sb25n LmxvbmcubG9uZy5leGFtcGxlLmNvbSwgdXNlcjogLCBkb21haW46IA0KICAgICAgICBob3N0OiBo b3N0MTQubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAg ICAgaG9zdDogaG9zdDEzLmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFp bjogDQogICAgICAgIGhvc3Q6IGhvc3QxMi5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwgdXNl cjogLCBkb21haW46IA0KICAgICAgICBob3N0OiBob3N0MTEubG9uZy5sb25nLmxvbmcuZXhhbXBs ZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDEwLmxvbmcubG9uZy5s b25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAgIGhvc3Q6IGhvc3Q5Lmxv bmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAgIGhvc3Q6 IGhvc3Q4LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAg ICAgIGhvc3Q6IGhvc3Q3LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFp bjogDQogICAgICAgIGhvc3Q6IGhvc3Q2LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2Vy OiAsIGRvbWFpbjogDQogICAgICAgIGhvc3Q6IGhvc3Q1LmxvbmcubG9uZy5sb25nLmV4YW1wbGUu Y29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAgIGhvc3Q6IGhvc3Q0LmxvbmcubG9uZy5sb25n LmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAgIGhvc3Q6IGhvc3QzLmxvbmcu bG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAgIGhvc3Q6IGhv c3QyLmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAg IGhvc3Q6IGhvc3QxLmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjog DQp5YXN1QHNlcnZlclsxMDYzXSUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQnV0IGlmIGl0IGlzIHN0b3Jl ZCBpbiBOSVMgZGF0YWJhc2UsIHRoZW4gcGFyc2luZyBzdG9wcyBhdCB0aGUgbWlkZGxlDQpvZiBp dC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KeWFzdUBzZXJ2ZXJbMTA2M10lIHlwbWF0Y2ggLWsgdmVyeV9s b25nX25pc19lbnRyeSBuZXRncm91cA0KdmVyeV9sb25nX25pc19lbnRyeTogKGhvc3QxLmxvbmcu bG9uZy5sb25nLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAgICAoaG9zdDIubG9u Zy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkgIChob3N0My5sb25nLmxvbmcubG9uZy5leGFtcGxl LmNvbSwsKSAgICAgICAgICAgICAgICAgICAgIChob3N0NC5sb25nLmxvbmcubG9uZy5leGFtcGxl LmNvbSwsKSAgICAgICAgICAgICAgICAgICAgKGhvc3Q1LmxvbmcubG9uZy5sb25nLmV4YW1wbGUu Y29tLCwpICAgICAgICAgICAgICAgICAgIChob3N0Ni5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNv bSwsKSAgICAgICAgICAgICAgICAgICAgKGhvc3Q3LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29t LCwpICAgICAgICAgICAgICAgICAgIChob3N0OC5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSws KSAgICAgICAgICAgICAgICAgICAgKGhvc3Q5LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwp ICAgICAgICAgICAgICAgICAgIChob3N0MTAubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkg ICAgICAgICAgICAgICAgICAgKGhvc3QxMS5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwsKSAg ICAgICAgICAgICAgICAgIChob3N0MTIubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkgICAg ICAgICAgICAgICAgICAgKGhvc3QxMy5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwsKSAoaG9z dDE0LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgICAoaG9z dDE1LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgIChob3N0 MTYubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAoaG9zdDE3 LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgIChob3N0MTgu bG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAoaG9zdDE5Lmxv bmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgIChob3N0MjAubG9u Zy5sb25nLmxvbmcuZXhhbXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAoaG9zdDIxLmxvbmcu bG9uZy5sb25nLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgIChob3N0MjIubG9uZy5s b25nLmxvbmcuZXhhbXBsZS5jb20sLCkgICAgICAgICAgICAgICAgICAoaG9zdDIzLmxvbmcubG9u Zy5sb25nLmV4YW1wbGUuY29tLCwpICAgICAgICAgICAgICAgICAgIChob3N0MjQubG9uZy5sb25n LmxvbmcuZXhhbXBsZS5jb20sLCkgKGhvc3QyNS5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSws KSAgICAgICAgICAgICAgICAgICAgKGhvc3QyNi5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSws KSAgICAgICAgICAgICAgICAgICAoaG9zdDI3LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwp ICAgICAgICAgICAgICAgICAgKGhvc3QyOC5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwsKSAg ICAgICAgICAgICAgICAgICAoaG9zdDI5LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCwpICAg ICAgICAgICAgICAgICAgKGhvc3QzMC5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwsKQ0KeWFz dUBzZXJ2ZXJbMTA2NF0lIC4vbGlzdF9uZXRncm91cF9lbnRyeSB2ZXJ5X2xvbmdfbmlzX2VudHJ5 DQpuZXRncm91cDogdmVyeV9sb25nX25pc19lbnRyeQ0KICAgICAgICBob3N0OiBob3N0MjUubG9u Zy5sb25nLmxvbmcuZXhhbXAsIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDI0 LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAgIGhv c3Q6IGhvc3QyMy5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwgdXNlcjogLCBkb21haW46IA0K ICAgICAgICBob3N0OiBob3N0MjIubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6ICwg ZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDIxLmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29t LCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAgIGhvc3Q6IGhvc3QyMC5sb25nLmxvbmcubG9uZy5l eGFtcGxlLmNvbSwgdXNlcjogLCBkb21haW46IA0KICAgICAgICBob3N0OiBob3N0MTkubG9uZy5s b25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9z dDE4LmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAg IGhvc3Q6IGhvc3QxNy5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwgdXNlcjogLCBkb21haW46 IA0KICAgICAgICBob3N0OiBob3N0MTYubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6 ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDE1LmxvbmcubG9uZy5sb25nLmV4YW1wbGUu Y29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAgICAgIGhvc3Q6IGhvc3QxNC5sb25nLmxvbmcubG9u Zy5leGFtcGxlLmNvbSwgdXNlcjogLCBkb21haW46IA0KICAgICAgICBob3N0OiBob3N0MTMubG9u Zy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDog aG9zdDEyLmxvbmcubG9uZy5sb25nLmV4YW1wbGUuY29tLCB1c2VyOiAsIGRvbWFpbjogDQogICAg ICAgIGhvc3Q6IGhvc3QxMS5sb25nLmxvbmcubG9uZy5leGFtcGxlLmNvbSwgdXNlcjogLCBkb21h aW46IA0KICAgICAgICBob3N0OiBob3N0MTAubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVz ZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDkubG9uZy5sb25nLmxvbmcuZXhhbXBs ZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDgubG9uZy5sb25nLmxv bmcuZXhhbXBsZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDcubG9u Zy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDog aG9zdDYubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAg ICAgaG9zdDogaG9zdDUubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6ICwgZG9tYWlu OiANCiAgICAgICAgaG9zdDogaG9zdDQubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6 ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDMubG9uZy5sb25nLmxvbmcuZXhhbXBsZS5j b20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDIubG9uZy5sb25nLmxvbmcu ZXhhbXBsZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCiAgICAgICAgaG9zdDogaG9zdDEubG9uZy5s b25nLmxvbmcuZXhhbXBsZS5jb20sIHVzZXI6ICwgZG9tYWluOiANCnlhc3VAc2VydmVyWzEwNjVd JQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpTbyBpdCBzZWVtcyBnZXRuZXRncmVudCgzKSBmYWlscyB0byBw YXJzZSBsb25nIG5ldGdyb3VwIGVudHJ5IGlmIGl0IGlzDQpzdG9yZWQgaW4gTklTLg0KDQotLS0N Cllhc3VoaXJvIEtpbXVyYQ0K From nobody Tue Mar 15 23:15:30 2022 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 E1D8A1A1DC38 for ; Tue, 15 Mar 2022 23:15:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660047.outbound.protection.outlook.com [40.107.66.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KJ8Qf3N3vz4Qpr; Tue, 15 Mar 2022 23:15:38 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IUCkexjoee3JVn3I2CCKtQylWifGjssl6Ry7LInlqtZLEP5Zv7sAMo3oqpw0Zoc5PoHT59SloMF8gOLyvEWe6EQQWtybYABA2fCiDcEDP5trPD+cuQW9dXaxgJ8iUg4b/1qTR4evmXv6xthfHiF0ru3eo/KiqaDEi+kImdsjqkUjyNRE8R0J1fIIttppbjlmJ4hviCuA0pgHUP4JD2oM40XWal/W4UojVOefnL8oZn/SwGQCFEu+T7gSGjhxy/UJzYlgMb5xocy5iNI4jMe7vKkCqNNAYXChMHthGxFHlZ4E8O5zoLpnsO7GAv000kShHK1QkNxodefEsxzV0Xuv+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=G2NkmjMwbyPxSCvb7hnPvFo2fmwbAlSUFO5LEf7iSYc=; b=DwDx4TmkSfZZEEcaJ7rU9I3MIakdDOUBCDdRRgu6us5aM+jND5WZHs+WHuHj+CFLX5d1pwGiXuuWZNSIZou7k41P7R52E2SZt37jLQPnrZswfw88EqdRUwvuHyFdO8iXWQsWdK0KbSELJoauQ9FI4VuGERruy3/eMWMrrkSrMqUeoMYsHEx2yjdjh3KzorZmfsH6mLnQsYLEP/3N7iyQrKXvo3PzV/E5eMMgzD8E/LpDRykIhFh7GYZmvYo7f9z23O7mDh95wAqwj9cPT5U+VtgogtyTLhMv/q7uvBlX1Z8ogi99E+QKKpy130LCIvPS/iZqFIcoJ/EGZEMVfATtgA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G2NkmjMwbyPxSCvb7hnPvFo2fmwbAlSUFO5LEf7iSYc=; b=PyVCJt2UVP98JmYGRUn7FsXixiSQ8pvO8EX5ayVaLh/FU8Er/xB9kGuUnpMepzLnAD7uXmZdjUMKkUvFNGb96AaMfeNgd+7dBMfRwD1QXy/SvENOkUrvXmbCBvAADSH6HhrkJ8U79sRdm0ZG5by5ii9TAp+8aiZ8yf+Lt3SopOfNv7XR+kuMaMW37txaD1ONq9wfkVAJsf57GoZq/UUb9vOgpqdBjImoLjV/H/1WeK1H6hRDpDF2eXGgMLLy94X7QpUdM6UW4Drpl7OGq7G2x8PL3/AnFIqMtQNZjptE9F59NR4a4K7xPMnqoysIb9hznTkgqsQB6HkajdfrUGB4SQ== Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:de::14) by YQXPR01MB2533.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:4c::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.25; Tue, 15 Mar 2022 23:15:30 +0000 Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::cdc2:3e87:371d:8d2c]) by YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::cdc2:3e87:371d:8d2c%8]) with mapi id 15.20.5081.014; Tue, 15 Mar 2022 23:15:30 +0000 From: Rick Macklem To: Yasuhiro Kimura , "freebsd-current@freebsd.org" Subject: Re: getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS Thread-Topic: getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS Thread-Index: AQHYOI1LJULR+AKWHUq8CUSOjSq7OqzBE63z Date: Tue, 15 Mar 2022 23:15:30 +0000 Message-ID: References: <20220316.014814.1921859297745365117.yasu@FreeBSD.org> In-Reply-To: <20220316.014814.1921859297745365117.yasu@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: c433629c-7ebb-f4df-9e5f-2a00bc2af648 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 86431243-1b81-4fb9-3de0-08da06d9b2a7 x-ms-traffictypediagnostic: YQXPR01MB2533:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: J32J/+5f+sWtxtBrR/9yc2vRl7Ku0E5pRM0alHGlHQ0oERxJaGgCHySlICSTfk/r+iaTPqMfUpjzucXc98zwyalDRklrVgYk6MZXK8cg+UCP0yZOKgU1n2Ah1CZOH0HSmgDDDhBVv79NazW7k4tGdHh9wdFiFViiXtX9VNXqYMtCS7FcMYe7V4xvRC4kKo80ksYi3HxPqIMqttX6hiokajJHArOifxsIG/vP8NOM+MMTXEOiEM27ew6tTUAnAMOfa34kfSLOGjDo1tfw8hVml38jui5QpzvRe+lTLER3tYnG7abRqc23L0J0Qk8mlXwiNwKiFkSGXz0Lla6a7a9QULEUPVgbMIG9dpZVents7pRq7pZcHAGT1+vS+/WDsUutFXOdAcGBTM+4w2+EdnhfFcMRFjR7FCcGFCZkI3q2kIcLsaPGEeUg9LqqL8/up7orItMyZl//4VufWOZF4ItdR25SyjPhI72wTselUiMIHKsr5Dee26iyXv8TYPLsAHWaLWZdvTr9Csuc4HzQ9umTMX4TPb5qikDJ5Gk7K5FGEHNwr8/ZPpfWMLQw5CKFGCo4G5XohrLhU18BgtKcfQKLFZTXXgcrAxNSBDgUAy16sWxZOsV5D4xwd/1XlR8ZETtIulB75AGrcBO9QbgVqQpRN3FZx0WUCOLQN+p7Eu8+saDlxEtW1QQn/vD67DrTN0w7apYqgWrH3SazUL341GPr6FdvoDDLZTg5c0o03hCOqlyHQwOTYVrjIie+k816CCFrrH30HNpVQyjJqwn8dKwkqBIpWJbLb2nwP8LfTZC3FSs= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(366004)(84970400001)(33656002)(38100700002)(86362001)(38070700005)(122000001)(91956017)(786003)(450100002)(316002)(110136005)(5660300002)(52536014)(8936002)(8676002)(66946007)(76116006)(64756008)(66476007)(66446008)(66556008)(2906002)(83380400001)(30864003)(71200400001)(6506007)(508600001)(53546011)(55016003)(186003)(9686003)(7696005);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?WV+e2A3nUTgtBsOz74YeIh7lNZ6UTiT0TkTd4URCrT/mbxwz7rR6/xoL84hA?= =?us-ascii?Q?bmom966/8EseU4RPdAd6xD1rBV9QUn2WJNPAzO4yh+KHHSN2Htl/bl18GovU?= =?us-ascii?Q?0DDil/GNwy1oWJzGmFNuP7yFJYfUt58kH3j/TJJ3t7tANVLCXOvRKQI3kyHe?= =?us-ascii?Q?t9KD2iH+jCle9a7Vw4pq/a88F4fsNeXl210fMh33ozih3itUGLlyVOhpCcko?= =?us-ascii?Q?g7ijNbeGvNqCkl8le5OezCoiSzOwMLGTAc1AqQULQU9xrizaR/G79PXsXvQj?= =?us-ascii?Q?vIeYZbyJHn3GC66aJj1BAyVEt3Muxo3H2mpd8cEzU6fxAzkaaKggO8RdLR6P?= =?us-ascii?Q?Qvn3sTjS9Qf2WEVKoDPewe9epCWIrRRdMWDriErKqUhruEmxDlKp8zToEO9g?= =?us-ascii?Q?bZVSB44ddqhQFUE7YsewBUmWYMIL26z3QrnleLMboi7p6WJIW7Mm4JjdlEnK?= =?us-ascii?Q?3WnverhFK6cCoKU7WJELQRWneQYGOZTJksxwq2MJveKjDIin/ONlmWFH3LVz?= =?us-ascii?Q?g31FLvfzV0YSiVxZjb2cETNJ36YJZTWTP3FzC8U6lWrsdHRjQyyOGmYs6d+b?= =?us-ascii?Q?EBe4FFncnHYPuuDQGJvtUoqZ4cVEkyzpidm3sfLCARERNEu5FoSJ6Fk0ZHO3?= =?us-ascii?Q?mhUFIGJeQclfd5QV1XwkWIbgJmUvwVvDOHcE0snh6YJvbkI5GAo1SgU2rzCH?= =?us-ascii?Q?qdoGqnkHSU73hO0mDdPJCIf6CV4cPGCzXpe1rbDaJYxg0V8yPljQ0bCJm5/Y?= =?us-ascii?Q?b/IDGV7WV8w2WFCdcLHwmf46EQkbF4UlGbXkVGq+Msny8yS1vsWFq/uzb6H+?= =?us-ascii?Q?q8/0TjAbmvccU40zbBC8RbLm+ge9/mx7M75zsIviSRziXvG8NWg0ZiyH23jj?= =?us-ascii?Q?2PzCR+hQpAT0j0p6dsLdJG5SpXtmG+JthcC8wQLwmqsi4RsGoyH+aBnJDR2D?= =?us-ascii?Q?eyVnLs/RHdfkdPMM8MpVFYvAa2ybHAOLRTP+EUfarvXlNk/H3NPB599oGn+i?= =?us-ascii?Q?BUhheqDdeBYeuu/Q2t/O35/+h7pp4hbB+dvQEHVllLP9xDeb9Ih7w1BY+/Sd?= =?us-ascii?Q?zC+AgWSI+kqApALh7CStfYTjS7zk5BzK9SpJupZ4HU1mOqPUOdL5vSC7TIy+?= =?us-ascii?Q?IAKRh0ik8VVQOH2bqzJzuq10Z8w7vJ1GFwa882E/HuAAISRTdM9fuEl08D2c?= =?us-ascii?Q?5aMRo2PTKA3d/iH+rEwW55FCdXeOLj+zI6upQVwuRUk5oJPplDZFIsVFI8bg?= =?us-ascii?Q?ycf6UxYRNbLFzC6n8zARcG5/ZgAdAt9OgzSns/y3IBU/gI4oBJyHwYhLaTEf?= =?us-ascii?Q?VW9TBe7ENWsVzdJmHmVJn8WqagPXWSfubhC/cpbrxvzXfxb4gx2OhLP6eLhb?= =?us-ascii?Q?ZxtRWz91iT7ZIDaWllznySixuKtba/oISKOAFPTnmwhgA/w89DQ1hUp1wYXv?= =?us-ascii?Q?OQHqIFWyXxoYkCaZOfUOTRIKSJJk+PMkPHR5uDJEU+UZ9HU8LxbCmIkR4r0o?= =?us-ascii?Q?4vh0v4LvDsJEgIFaOIlwMvxdXWp/EvZz9Oew?= 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 86431243-1b81-4fb9-3de0-08da06d9b2a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2022 23:15:30.0851 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: B3X3cpcK0Xff4POdRVFz8IUXRiwxR3VkcFxaGnAP18L/H3A4Y+DHwiBFchaY812PyJrnR8qTVzPrsvHlHFHViQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB2533 X-Rspamd-Queue-Id: 4KJ8Qf3N3vz4Qpr X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=PyVCJt2U; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.47 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.99 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.47:from]; NEURAL_HAM_SHORT(-0.99)[-0.986]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.47:from] X-ThisMailContainsUnwantedMimeParts: N "man 5 netgroup" notes that a netgroup line is limited to 1024bytes. Are you sure you haven't just exceeded this limit? rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Yasuhiro Kimura Sent: Tuesday, March 15, 2022 12:48 PM To: freebsd-current@freebsd.org Subject: getnetgrent(3) fails to parse long netgroup entry if it is stored = in NIS CAUTION: This email originated from outside of the University of Guelph. Do= not click links or open attachments unless you recognize the sender and kn= ow the content is safe. If in doubt, forward suspicious emails to IThelp@uo= guelph.ca Hello, I use netgroup stored in NIS database to control access to NFS server. Recently I added some hosts to netgroup that access to NFS server is permitted. And after that mountd(8) writes such messages as following to syslog. Mar 15 17:16:59 server mountd[4276]: can't get address info for host host34= .nfs. Mar 15 17:16:59 server mountd[4276]: bad host host34.nfs. in netgroup permi= tted_nfs_clients, skipping The netgroup entry used to control access to NFS server includes a lot of host such as following ---------------------------------------------------------------------- yasu@server[1002]% ypmatch -k permitted_nfs_clients netgroup permitted_nfs_clients: (host01.nfs.example.com,,) (ho= st02.nfs.example.com,,) (host03.nfs.example.com,,) = (host04.nfs.example.com,,) (host05.nf= s.example.com,,) (host06.nfs.example.com,,) = (host07.nfs.example.com,,) (host08.nfs.example= .com,,) (host09.nfs.example.com,,) = (host10.nfs.example.com,,) (host11.nfs.example.com,,= ) (host12.nfs.example.com,,) (host1= 3.nfs.example.com,,) (host14.nfs.example.com,,) = (host15.nfs.example.com,,) (host16.nfs.= example.com,,) (host17.nfs.example.com,,) = (host18.nfs.example.com,,) (host19.nfs.example= .com,,) (host20.nfs.example.com,,) = (host21.nfs.example.com,,) (host22.nfs.example.com,,)= (host23.nfs.example.com,,) (host2= 4.nfs.example.com,,) (host25.nfs.example.com,,) = (host26.nfs.example.com,,) (host27.nfs.e= xample.com,,) (host28.nfs.example.com,,) = (host29.nfs.example.com,,) (host30.nfs.example.= com,,) (host31.nfs.example.com,,) = (host32.nfs.example.com,,) (host33.nfs.example.com,,) = (host34.nfs.example.com,,) (host35= .nfs.example.com,,) (host36.nfs.example.com,,) = (host37.nfs.example.com,,) (host38.nfs.exam= ple.com,,) (host39.nfs.example.com,,) = (host40.nfs.example.com,,) (host41.nfs.example.co= m,,) (host42.nfs.example.com,,) (ho= st43.nfs.example.com,,) (host44.nfs.example.com,,) = (host45.nfs.example.com,,) (host46.n= fs.example.com,,) (host47.nfs.example.com,,) = (host48.nfs.example.com,,) (host49.nfs.exam= ple.com,,) (host50.nfs.example.com,,) yasu@server[1054]% ---------------------------------------------------------------------- And if I remove host34.nfs.example.com from permitted_nfs_clients, then syslog messages of mountd(1) changes as following. Mar 15 17:16:59 server mountd[4276]: can't get address info for host host35= .nfs. Mar 15 17:16:59 server mountd[4276]: bad host host35.nfs. in netgroup permi= tted_nfs_clients, skipping It seems to stop parsing the value of the netgroup entry in its middle if the length is longer than a certain value. I checked usr.sbin/mountd/mountd.c and found it uses getnetgrent(3) to parse the value of netgroup entry. So I wrote following program to check its behavior. ---------------------------------------------------------------------- yasu@server[1152]% cat list_netgroup_entry.c #include #include #include int main(int argc, char **argv) { if (argc !=3D 2) { fprintf(stderr, "Usage: %s NameOfNetgroup\n", basename(argv[0])); return 1; } setnetgrent(argv[1]); printf("netgroup: %s\n", argv[1]); char *host, *user, *domain; while (getnetgrent(&host, &user, &domain)) printf("\thost: %s, user: %s, domain: %s\n", host, user, domain); endnetgrent(); return 0; } yasu@server[1152]% ---------------------------------------------------------------------- If netgroup entry is stored in /etc/netgroup, then the value is parsed properly. ---------------------------------------------------------------------- yasu@server[1061]% cat /etc/netgroup very_long_file_entry (host1.long.long.long.example.com,,) \ (host2.long.long.long.example.com,,) \ (host3.long.long.long.example.com,,) \ (host4.long.long.long.example.com,,) \ (host5.long.long.long.example.com,,) \ (host6.long.long.long.example.com,,) \ (host7.long.long.long.example.com,,) \ (host8.long.long.long.example.com,,) \ (host9.long.long.long.example.com,,) \ (host10.long.long.long.example.com,,) \ (host11.long.long.long.example.com,,) \ (host12.long.long.long.example.com,,) \ (host13.long.long.long.example.com,,) \ (host14.long.long.long.example.com,,) \ (host15.long.long.long.example.com,,) \ (host16.long.long.long.example.com,,) \ (host17.long.long.long.example.com,,) \ (host18.long.long.long.example.com,,) \ (host19.long.long.long.example.com,,) \ (host20.long.long.long.example.com,,) \ (host21.long.long.long.example.com,,) \ (host22.long.long.long.example.com,,) \ (host23.long.long.long.example.com,,) \ (host24.long.long.long.example.com,,) \ (host25.long.long.long.example.com,,) \ (host26.long.long.long.example.com,,) \ (host27.long.long.long.example.com,,) \ (host28.long.long.long.example.com,,) \ (host29.long.long.long.example.com,,) \ (host30.long.long.long.example.com,,) + yasu@server[1062]% ./list_netgroup_entry very_long_file_entry netgroup: very_long_file_entry host: host30.long.long.long.example.com, user: , domain: host: host29.long.long.long.example.com, user: , domain: host: host28.long.long.long.example.com, user: , domain: host: host27.long.long.long.example.com, user: , domain: host: host26.long.long.long.example.com, user: , domain: host: host25.long.long.long.example.com, user: , domain: host: host24.long.long.long.example.com, user: , domain: host: host23.long.long.long.example.com, user: , domain: host: host22.long.long.long.example.com, user: , domain: host: host21.long.long.long.example.com, user: , domain: host: host20.long.long.long.example.com, user: , domain: host: host19.long.long.long.example.com, user: , domain: host: host18.long.long.long.example.com, user: , domain: host: host17.long.long.long.example.com, user: , domain: host: host16.long.long.long.example.com, user: , domain: host: host15.long.long.long.example.com, user: , domain: host: host14.long.long.long.example.com, user: , domain: host: host13.long.long.long.example.com, user: , domain: host: host12.long.long.long.example.com, user: , domain: host: host11.long.long.long.example.com, user: , domain: host: host10.long.long.long.example.com, user: , domain: host: host9.long.long.long.example.com, user: , domain: host: host8.long.long.long.example.com, user: , domain: host: host7.long.long.long.example.com, user: , domain: host: host6.long.long.long.example.com, user: , domain: host: host5.long.long.long.example.com, user: , domain: host: host4.long.long.long.example.com, user: , domain: host: host3.long.long.long.example.com, user: , domain: host: host2.long.long.long.example.com, user: , domain: host: host1.long.long.long.example.com, user: , domain: yasu@server[1063]% ---------------------------------------------------------------------- But if it is stored in NIS database, then parsing stops at the middle of it. ---------------------------------------------------------------------- yasu@server[1063]% ypmatch -k very_long_nis_entry netgroup very_long_nis_entry: (host1.long.long.long.example.com,,) = (host2.long.long.long.example.com,,) (host3.long.long.long.example.co= m,,) (host4.long.long.long.example.com,,) = (host5.long.long.long.example.com,,) (host6.long.lo= ng.long.example.com,,) (host7.long.long.long.example.com= ,,) (host8.long.long.long.example.com,,) = (host9.long.long.long.example.com,,) (host10.long.long= .long.example.com,,) (host11.long.long.long.example.com,,= ) (host12.long.long.long.example.com,,) = (host13.long.long.long.example.com,,) (host14.long.long.long.example.com,,)= (host15.long.long.long.example.com,,) = (host16.long.long.long.example.com,,) (host17.long.long.l= ong.example.com,,) (host18.long.long.long.example.com,,) = (host19.long.long.long.example.com,,) (h= ost20.long.long.long.example.com,,) (host21.long.long.long= .example.com,,) (host22.long.long.long.example.com,,) = (host23.long.long.long.example.com,,) (host= 24.long.long.long.example.com,,) (host25.long.long.long.example.com,,) = (host26.long.long.long.example.com,,) (hos= t27.long.long.long.example.com,,) (host28.long.long.long.e= xample.com,,) (host29.long.long.long.example.com,,) = (host30.long.long.long.example.com,,) yasu@server[1064]% ./list_netgroup_entry very_long_nis_entry netgroup: very_long_nis_entry host: host25.long.long.long.examp, user: , domain: host: host24.long.long.long.example.com, user: , domain: host: host23.long.long.long.example.com, user: , domain: host: host22.long.long.long.example.com, user: , domain: host: host21.long.long.long.example.com, user: , domain: host: host20.long.long.long.example.com, user: , domain: host: host19.long.long.long.example.com, user: , domain: host: host18.long.long.long.example.com, user: , domain: host: host17.long.long.long.example.com, user: , domain: host: host16.long.long.long.example.com, user: , domain: host: host15.long.long.long.example.com, user: , domain: host: host14.long.long.long.example.com, user: , domain: host: host13.long.long.long.example.com, user: , domain: host: host12.long.long.long.example.com, user: , domain: host: host11.long.long.long.example.com, user: , domain: host: host10.long.long.long.example.com, user: , domain: host: host9.long.long.long.example.com, user: , domain: host: host8.long.long.long.example.com, user: , domain: host: host7.long.long.long.example.com, user: , domain: host: host6.long.long.long.example.com, user: , domain: host: host5.long.long.long.example.com, user: , domain: host: host4.long.long.long.example.com, user: , domain: host: host3.long.long.long.example.com, user: , domain: host: host2.long.long.long.example.com, user: , domain: host: host1.long.long.long.example.com, user: , domain: yasu@server[1065]% ---------------------------------------------------------------------- So it seems getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS. --- Yasuhiro Kimura From nobody Wed Mar 16 05:12:49 2022 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 3B7051A11E39 for ; Wed, 16 Mar 2022 05:12:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670088.outbound.protection.outlook.com [40.107.67.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KJJLx3jDMz4WG6; Wed, 16 Mar 2022 05:12:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aEDfiofVHRuUBcvjOV3qHCYrKM/xdhutOmhgnI0JmRNaPLXo07bNKkYMjkQFPgyXHEuWzWwA6sNHliWst1D1Do89XTxihuhGvQQoBK3Szmm1MFYYcJrCCB28KHOBR8OYHZXK02ZXO497WRMXY5jl6HP15GocmpmU/SAiqQOQuM2kmomk9EF5xKFZ2gFPG4eTWJ/7kthccF76vUNLqojkO0tafBNxJkh5uQV6LfLjpgz2hupjF1C7QoiVToMLgIsrvmULGZ0AyjfmlXx/WYypbTXDShcumLB/pMXQ6K2HzgATnNLXVd+VmBX+7MQo+vsH2HR+1e6B9CaUJIkQ6EIV3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=r2HjXRmASc16VgjXDtncU1OqshLt3ZWnujKlvGPC798=; b=laR3M+FwI58dIFlLx+qPSZJgoUKkD2GjcmqymZt5EiZTCXjHPAHDvS432Vg8Qu3GtRz0xnU2g9DpSxyCqyXf9ndqRnlHufzWbVF6x0kjVXhl0h28FeWOqnBvMVNowUrOvtAT5KvcETlKrRR7XtFie5GbBaXObc0u186w6aKPLz4sUGGUWhk+qAOEy7Lk8C0Aj2+EsA1Mb1Y8bQuXlDOFFe9e9uVcO0J+Igz1eOGmIbh0HwK69qfcRinkU/dpSL/WwP3YKRtU6MXPzi6b6gXWEiL4J+Tl/Zp6CfrTu8t6BmBkntYWjfh2B4XX+ueTJy6Yv7i7EzEYeWzYlM4U8inRdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r2HjXRmASc16VgjXDtncU1OqshLt3ZWnujKlvGPC798=; b=gupqfjiRPnCtJ3tZJSMNxRS4ouOzylVmQlcXAa2ilVG0IWlk9x575RhBhUKBLhyQWV7Rbia67qGm+Je3glm1ACFVrh7yA08ae7rWAWQWsgmtH/zR8mUinXnhRwpbJXzQsLNzBf1hzxymyhfO+2JHyrPH9Trf3SEI9nrmsxU0Alh5DgEfRDvkx8qIAcwND/ebpJm5SKh8D2Gkahq18mElLxL56FGps+KTUxFbOL5X40fp60nhEtG80elCsM9l+iJ6fSN5n1kc/8y+BU9BIa+sdlB9/Iz72vGxbPsS3uFJLJGqEL8CQ8DSzviwpprustj+fQot08V9qA3qKFs9hEA+mg== Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:de::14) by YT2PR01MB9956.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:d8::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.15; Wed, 16 Mar 2022 05:12:49 +0000 Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::cdc2:3e87:371d:8d2c]) by YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::cdc2:3e87:371d:8d2c%8]) with mapi id 15.20.5081.014; Wed, 16 Mar 2022 05:12:49 +0000 From: Rick Macklem To: Yasuhiro Kimura , "freebsd-current@freebsd.org" Subject: Re: getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS Thread-Topic: getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS Thread-Index: AQHYOI1LJULR+AKWHUq8CUSOjSq7OqzBdwsR Date: Wed, 16 Mar 2022 05:12:49 +0000 Message-ID: References: <20220316.014814.1921859297745365117.yasu@FreeBSD.org> In-Reply-To: <20220316.014814.1921859297745365117.yasu@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 2611b7c1-b30a-75b6-4aef-52061bec0062 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c856012-ed93-4332-eabd-08da070b9d9d x-ms-traffictypediagnostic: YT2PR01MB9956:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: e6HPwjDP6zf8bHerIn9Zt9gZ5h3kXTHU8FV9629tm9Bw5r0yY9q+JzruDn9NxNlzyBcC735t8N24/pCGiYno50VUY2H3IlJfcObmD4gfURA/4sJYG3tIGZKsEKPwcIZV5FVmLjwwlbjHW8Uazj+tQn/TwPaWG2Q4gBMfnF+MaBcmRrNgKRRfRt2kv+rFnDE3Z9CLBu5WCx5Ac3ynnDHD991Az+9ddt+jz4b/1RQKI/MlWO6BqhajdXLM0TicEraSTrtlB28pm9/dENz4RYnODBVbm6kd8zfn3bLvHwdLYXHrKqX+E6IXG4BX1a4dz3LED8cyOVbMo02L8vUBxi1uxw+0Ov/duPS9pZG7KJgyaSfrbJIzr+88n6M0s3pXAnSssQH3bW52VOtuOCDcoFzQkNjyBmAYIeKNtRm3bOVTL5iqFZE9YHOVSwhsXWWGuL7ooVnyij4N45K/vtV5Tj2BcAFjHgRV8r/FgSRLIITnRRDOrySYokAtSxyJ6ZNXUb9zXCGEuUtTV7Jc1b0DZyc7Wu49b63nENC6oCeK4ZBvWhopBFnJcsKvAgsf/CgYch+zEPGIzDhO8txTQTtDjxR29dyC7hKykFFFcuRvZLtLzW71FEnuZclqDIO4t+Ch7Q1XfIhyQNu6Au9X/7NKnpP2oxZTlBWnAYH9zlhtV4lHBnUqO6rxhdoT8JPskF6YGuimsS6GyG+zmypL7vwPtdWZrX/DfATxA6RiKZpHxwhXIDCXMubZFfeZu5BBUqHjLhEGML1x3n5GKHZRM63Q9ChMpHaU3+94s8YiZl0R87iWG/4= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(366004)(55016003)(30864003)(2906002)(5660300002)(52536014)(508600001)(53546011)(86362001)(7696005)(6506007)(9686003)(64756008)(38100700002)(66556008)(66946007)(76116006)(66476007)(66446008)(91956017)(450100002)(71200400001)(8676002)(84970400001)(33656002)(186003)(122000001)(8936002)(38070700005)(110136005)(83380400001)(316002)(786003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?LZ6v1f3O/58VuRVwLeKiyGFNylWqiyAkckE3NN6bIfLjixEPJqXI/2Jb+Kdn?= =?us-ascii?Q?Ps0BJgX6TNKmKZz6rZV3P53H8cVHv9YM2p6d7pVzg/J9fmOD6ou1xG2slZVb?= =?us-ascii?Q?uxmXcsHBjbVhzvlumVuBnwg3bLdBAeIeezwuipnpzB1Io+jWL3obX5wY3SN8?= =?us-ascii?Q?Gpfs9FVNQnqEQJN0jorjOt2gLd6hxchKLIs1Wa/UYjSs/nRvHmTYizlzyXYY?= =?us-ascii?Q?hfD8qMPRicnjQpUz3iGKYA0o3/C1Z43etrVPsR2E+QaLZja2URc05U/T5bKG?= =?us-ascii?Q?u9E+LXmuXjF+cH79XvK2zAEJgFdwkoeRf7p0ASA8BWWrpWqPe4y0Enu5k2td?= =?us-ascii?Q?vD7lI5JwBELf9xq36UO0qJoGYP6BsyFoaGLpUqGFcVjqRKgiS6wFi8AV5XC4?= =?us-ascii?Q?w66Xx2mT0cnhrFaO3r2lJq5ARqPMHNmfqRFVcKDZMpBIqWM9QmeAEWk6faIH?= =?us-ascii?Q?SuKP4pz6ywvwwmZVqbMeUUa+bxBg8s9/Glsj6MJnxCNBR6NbwCZFu2cjCP/Y?= =?us-ascii?Q?NeZHZdLG9mJGFK+EPk1fQCwGG1WHWL7Iw/oJSVOCwWl6YMr3nH4Nv8M0IaX6?= =?us-ascii?Q?slmZNdxKJqi+UvqlU8SfZdD7hGEY1qxbmnaQiU93cr9Q3P2d8k34aO654kZL?= =?us-ascii?Q?iWClXBv1BIP0+5r9dRtFDJ6iF8Lb+H94yBsYG6qVCAZVwbHBs8bj1w0M4yqd?= =?us-ascii?Q?JjmlVDxLu33c89G1PXmpqwBY1RCRGnafl0afNyxHdYnuBR2NmWOOb6LcnwIA?= =?us-ascii?Q?Z59sYEq+EQF5fDW9drLY82NBbdDhccZSM0l0XOq76qbQ4h1LabuO+AOTpIjI?= =?us-ascii?Q?fhRj8PmPmql1SMQPQ+3YIp49nh65YflpuKFLXgUGfsJg93bVoTIjIO5et9k0?= =?us-ascii?Q?ZmTvEkOAamHMaEkc45b6MHd78Z1Vk2LOzOdfMfTFvcFIRXk9ZJavJfnI33Es?= =?us-ascii?Q?V9N5E9QI7sbv+OLfr0yC6oXBI8swqEEnLYaXWkqlsAwRBxaDP6/benIRoBVA?= =?us-ascii?Q?Nuf/11e9sjy16uR93DO9OoIxCEDJrlUbOlHBEA9CCkkUb0y+57KkBfT4KG5l?= =?us-ascii?Q?JzWVghbhlJDwd0WMmSDakoqkS+1+/mdOPyrOJQo9xA6ZzGtiH86T9g8T6MOg?= =?us-ascii?Q?EWtaAiCcv3tIqkuFrSNpa+qH1VvOsEscInZqWKU7dAX9aDFksuVgMM39BC8H?= =?us-ascii?Q?IPpaVyomsyzM+M+v8VyW10AKq2CDRk0lBJoRKQgfdh5d4RV6iYxZ5Vc+w/yC?= =?us-ascii?Q?YO1oHAQzWSsYoc7EaFNwV779xyT0ZlnPYPu8qpU0UTQGp9vlWItYZiDvDopu?= =?us-ascii?Q?0y9nhdteFwQBsqxO2LTylNOUV2A0SPwlf/owk5TooEZfmlDeLragys5mLYnG?= =?us-ascii?Q?2QtEFHEE28g/+5OhNrgNXKgODp6cpNVooj2p7O3qF6604cCbxc8JTcqD8FE8?= =?us-ascii?Q?0d5zoGXlxBIek5jUC4oVNn+s/s85YYlMCtsdNfr+ty1OeVcB4o2qdAJP1mFS?= =?us-ascii?Q?sM8CLOGdG5J4i4ewO2EME1dIApffeCNZmUOh?= 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 7c856012-ed93-4332-eabd-08da070b9d9d X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2022 05:12:49.6285 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JFwHqHK0Ip8sJP1mRgmAnVzmx/qC2GLyzxAdjXqWTWX0CyqeZ9o7puQ8Rlj/73z6MpR7czanxJ7LhtYTVB7fjw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT2PR01MB9956 X-Rspamd-Queue-Id: 4KJJLx3jDMz4WG6 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=gupqfjiR; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.88 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.88:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.88:from] X-ThisMailContainsUnwantedMimeParts: N Oh, and you can have netgroups in netgroups, so you can do something like... net0 net1,net2 net1 (host1,,),(host2,,) net2 (host3,,),(host4,,) then net0 has all 4 hosts in it. I think you need to break the large netgroup up into sub netgroups where each one is <=3D 1024 bytes long. rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Yasuhiro Kimura Sent: Tuesday, March 15, 2022 12:48 PM To: freebsd-current@freebsd.org Subject: getnetgrent(3) fails to parse long netgroup entry if it is stored = in NIS CAUTION: This email originated from outside of the University of Guelph. Do= not click links or open attachments unless you recognize the sender and kn= ow the content is safe. If in doubt, forward suspicious emails to IThelp@uo= guelph.ca Hello, I use netgroup stored in NIS database to control access to NFS server. Recently I added some hosts to netgroup that access to NFS server is permitted. And after that mountd(8) writes such messages as following to syslog. Mar 15 17:16:59 server mountd[4276]: can't get address info for host host34= .nfs. Mar 15 17:16:59 server mountd[4276]: bad host host34.nfs. in netgroup permi= tted_nfs_clients, skipping The netgroup entry used to control access to NFS server includes a lot of host such as following ---------------------------------------------------------------------- yasu@server[1002]% ypmatch -k permitted_nfs_clients netgroup permitted_nfs_clients: (host01.nfs.example.com,,) (ho= st02.nfs.example.com,,) (host03.nfs.example.com,,) = (host04.nfs.example.com,,) (host05.nf= s.example.com,,) (host06.nfs.example.com,,) = (host07.nfs.example.com,,) (host08.nfs.example= .com,,) (host09.nfs.example.com,,) = (host10.nfs.example.com,,) (host11.nfs.example.com,,= ) (host12.nfs.example.com,,) (host1= 3.nfs.example.com,,) (host14.nfs.example.com,,) = (host15.nfs.example.com,,) (host16.nfs.= example.com,,) (host17.nfs.example.com,,) = (host18.nfs.example.com,,) (host19.nfs.example= .com,,) (host20.nfs.example.com,,) = (host21.nfs.example.com,,) (host22.nfs.example.com,,)= (host23.nfs.example.com,,) (host2= 4.nfs.example.com,,) (host25.nfs.example.com,,) = (host26.nfs.example.com,,) (host27.nfs.e= xample.com,,) (host28.nfs.example.com,,) = (host29.nfs.example.com,,) (host30.nfs.example.= com,,) (host31.nfs.example.com,,) = (host32.nfs.example.com,,) (host33.nfs.example.com,,) = (host34.nfs.example.com,,) (host35= .nfs.example.com,,) (host36.nfs.example.com,,) = (host37.nfs.example.com,,) (host38.nfs.exam= ple.com,,) (host39.nfs.example.com,,) = (host40.nfs.example.com,,) (host41.nfs.example.co= m,,) (host42.nfs.example.com,,) (ho= st43.nfs.example.com,,) (host44.nfs.example.com,,) = (host45.nfs.example.com,,) (host46.n= fs.example.com,,) (host47.nfs.example.com,,) = (host48.nfs.example.com,,) (host49.nfs.exam= ple.com,,) (host50.nfs.example.com,,) yasu@server[1054]% ---------------------------------------------------------------------- And if I remove host34.nfs.example.com from permitted_nfs_clients, then syslog messages of mountd(1) changes as following. Mar 15 17:16:59 server mountd[4276]: can't get address info for host host35= .nfs. Mar 15 17:16:59 server mountd[4276]: bad host host35.nfs. in netgroup permi= tted_nfs_clients, skipping It seems to stop parsing the value of the netgroup entry in its middle if the length is longer than a certain value. I checked usr.sbin/mountd/mountd.c and found it uses getnetgrent(3) to parse the value of netgroup entry. So I wrote following program to check its behavior. ---------------------------------------------------------------------- yasu@server[1152]% cat list_netgroup_entry.c #include #include #include int main(int argc, char **argv) { if (argc !=3D 2) { fprintf(stderr, "Usage: %s NameOfNetgroup\n", basename(argv[0])); return 1; } setnetgrent(argv[1]); printf("netgroup: %s\n", argv[1]); char *host, *user, *domain; while (getnetgrent(&host, &user, &domain)) printf("\thost: %s, user: %s, domain: %s\n", host, user, domain); endnetgrent(); return 0; } yasu@server[1152]% ---------------------------------------------------------------------- If netgroup entry is stored in /etc/netgroup, then the value is parsed properly. ---------------------------------------------------------------------- yasu@server[1061]% cat /etc/netgroup very_long_file_entry (host1.long.long.long.example.com,,) \ (host2.long.long.long.example.com,,) \ (host3.long.long.long.example.com,,) \ (host4.long.long.long.example.com,,) \ (host5.long.long.long.example.com,,) \ (host6.long.long.long.example.com,,) \ (host7.long.long.long.example.com,,) \ (host8.long.long.long.example.com,,) \ (host9.long.long.long.example.com,,) \ (host10.long.long.long.example.com,,) \ (host11.long.long.long.example.com,,) \ (host12.long.long.long.example.com,,) \ (host13.long.long.long.example.com,,) \ (host14.long.long.long.example.com,,) \ (host15.long.long.long.example.com,,) \ (host16.long.long.long.example.com,,) \ (host17.long.long.long.example.com,,) \ (host18.long.long.long.example.com,,) \ (host19.long.long.long.example.com,,) \ (host20.long.long.long.example.com,,) \ (host21.long.long.long.example.com,,) \ (host22.long.long.long.example.com,,) \ (host23.long.long.long.example.com,,) \ (host24.long.long.long.example.com,,) \ (host25.long.long.long.example.com,,) \ (host26.long.long.long.example.com,,) \ (host27.long.long.long.example.com,,) \ (host28.long.long.long.example.com,,) \ (host29.long.long.long.example.com,,) \ (host30.long.long.long.example.com,,) + yasu@server[1062]% ./list_netgroup_entry very_long_file_entry netgroup: very_long_file_entry host: host30.long.long.long.example.com, user: , domain: host: host29.long.long.long.example.com, user: , domain: host: host28.long.long.long.example.com, user: , domain: host: host27.long.long.long.example.com, user: , domain: host: host26.long.long.long.example.com, user: , domain: host: host25.long.long.long.example.com, user: , domain: host: host24.long.long.long.example.com, user: , domain: host: host23.long.long.long.example.com, user: , domain: host: host22.long.long.long.example.com, user: , domain: host: host21.long.long.long.example.com, user: , domain: host: host20.long.long.long.example.com, user: , domain: host: host19.long.long.long.example.com, user: , domain: host: host18.long.long.long.example.com, user: , domain: host: host17.long.long.long.example.com, user: , domain: host: host16.long.long.long.example.com, user: , domain: host: host15.long.long.long.example.com, user: , domain: host: host14.long.long.long.example.com, user: , domain: host: host13.long.long.long.example.com, user: , domain: host: host12.long.long.long.example.com, user: , domain: host: host11.long.long.long.example.com, user: , domain: host: host10.long.long.long.example.com, user: , domain: host: host9.long.long.long.example.com, user: , domain: host: host8.long.long.long.example.com, user: , domain: host: host7.long.long.long.example.com, user: , domain: host: host6.long.long.long.example.com, user: , domain: host: host5.long.long.long.example.com, user: , domain: host: host4.long.long.long.example.com, user: , domain: host: host3.long.long.long.example.com, user: , domain: host: host2.long.long.long.example.com, user: , domain: host: host1.long.long.long.example.com, user: , domain: yasu@server[1063]% ---------------------------------------------------------------------- But if it is stored in NIS database, then parsing stops at the middle of it. ---------------------------------------------------------------------- yasu@server[1063]% ypmatch -k very_long_nis_entry netgroup very_long_nis_entry: (host1.long.long.long.example.com,,) = (host2.long.long.long.example.com,,) (host3.long.long.long.example.co= m,,) (host4.long.long.long.example.com,,) = (host5.long.long.long.example.com,,) (host6.long.lo= ng.long.example.com,,) (host7.long.long.long.example.com= ,,) (host8.long.long.long.example.com,,) = (host9.long.long.long.example.com,,) (host10.long.long= .long.example.com,,) (host11.long.long.long.example.com,,= ) (host12.long.long.long.example.com,,) = (host13.long.long.long.example.com,,) (host14.long.long.long.example.com,,)= (host15.long.long.long.example.com,,) = (host16.long.long.long.example.com,,) (host17.long.long.l= ong.example.com,,) (host18.long.long.long.example.com,,) = (host19.long.long.long.example.com,,) (h= ost20.long.long.long.example.com,,) (host21.long.long.long= .example.com,,) (host22.long.long.long.example.com,,) = (host23.long.long.long.example.com,,) (host= 24.long.long.long.example.com,,) (host25.long.long.long.example.com,,) = (host26.long.long.long.example.com,,) (hos= t27.long.long.long.example.com,,) (host28.long.long.long.e= xample.com,,) (host29.long.long.long.example.com,,) = (host30.long.long.long.example.com,,) yasu@server[1064]% ./list_netgroup_entry very_long_nis_entry netgroup: very_long_nis_entry host: host25.long.long.long.examp, user: , domain: host: host24.long.long.long.example.com, user: , domain: host: host23.long.long.long.example.com, user: , domain: host: host22.long.long.long.example.com, user: , domain: host: host21.long.long.long.example.com, user: , domain: host: host20.long.long.long.example.com, user: , domain: host: host19.long.long.long.example.com, user: , domain: host: host18.long.long.long.example.com, user: , domain: host: host17.long.long.long.example.com, user: , domain: host: host16.long.long.long.example.com, user: , domain: host: host15.long.long.long.example.com, user: , domain: host: host14.long.long.long.example.com, user: , domain: host: host13.long.long.long.example.com, user: , domain: host: host12.long.long.long.example.com, user: , domain: host: host11.long.long.long.example.com, user: , domain: host: host10.long.long.long.example.com, user: , domain: host: host9.long.long.long.example.com, user: , domain: host: host8.long.long.long.example.com, user: , domain: host: host7.long.long.long.example.com, user: , domain: host: host6.long.long.long.example.com, user: , domain: host: host5.long.long.long.example.com, user: , domain: host: host4.long.long.long.example.com, user: , domain: host: host3.long.long.long.example.com, user: , domain: host: host2.long.long.long.example.com, user: , domain: host: host1.long.long.long.example.com, user: , domain: yasu@server[1065]% ---------------------------------------------------------------------- So it seems getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS. --- Yasuhiro Kimura From nobody Wed Mar 16 08:35:02 2022 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 36B2C1A24C99 for ; Wed, 16 Mar 2022 08:35:47 +0000 (UTC) (envelope-from yasu@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KJNrz0zRsz3HZv; Wed, 16 Mar 2022 08:35:47 +0000 (UTC) (envelope-from yasu@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647419747; 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=HAWt2bYRbWvkJ51cc5zZITJpEFAW1anyJQRyl5DkDoE=; b=FKoM9LfUBMkhlc+wIBgSeZYnh60S4PAdYWwI7twmCJxAFwAKuHW80ZVJtrontLC75rTazb 7aTakUlA0znakVLlUcS71ragKr8XFhOvcoH6q2r5PpS9nlf2Luw2SaLERPhhkKZgekzsGE 5exP/AadTMEa2FwrCRGwX0QKycn2zH/D/inzRWgkTyL4AQkjdG6FOVPoaQj63Bq/rql5b+ vsmcAd/FWoK7oYLspUuD/SL7rfgnAbHWKjhlmgfgR0p03NFI4aEhszdVCLKc1u7mY9M1UX CwZtTZcadaPwj9HdjV8GXB9aNDBAuDFMiclzd3C2MAB84RWO7jkXN7V94OOC2A== Received: from localhost (unknown [IPv6:240b:11:220:fe00:8db2:139b:2f84:dcc6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: yasu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 6B39F28A5F; Wed, 16 Mar 2022 08:35:46 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Date: Wed, 16 Mar 2022 17:35:02 +0900 (JST) Message-Id: <20220316.173502.1588712462049603767.yasu@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Re: getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS From: Yasuhiro Kimura In-Reply-To: References: <20220316.014814.1921859297745365117.yasu@FreeBSD.org> X-Mailer: Mew version 6.8 on Emacs 29.0.50 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647419747; 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=HAWt2bYRbWvkJ51cc5zZITJpEFAW1anyJQRyl5DkDoE=; b=l2PKY5wQeJe2zbIrjc6SPIafkuBFWqcRjt1mTGLnGXSEiG6hJh9iXJ/9qy5ldNKRQfrbzV Eqm67acPUXOSMjK60687iU0vmtxmTiTCo7v4jWB9BAl90iBUIBM/Qhq6lrRizgUGm1jdBW w13gdm3PPfW5Qsglb/kh0FLpuFLlbPa/4Tdtv06GsZLMPJZq4Upwd4CKwU2OvsNnMrlEJg NZ+q/Fdou7dqseu10gy7mctOV0E+Yx6tHfEdHpbdx9i2KrVlHUMDa9kRorGfLZB6TeSx6T pu8K3/9Jx6kAm3fM3b/VdlPuO7HHBppBg3J/HtV/zFhQfwONpd4NOdnP4QYSWw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647419747; a=rsa-sha256; cv=none; b=xkz8g3Y5of/zeZC6NDndiZFZMqc7cjNbhz5HCREO/gHnyLB8FKJLrlsJbnVc5RlLbaZKBZ zRfSttM8TbqwhhbuBlRaBbkZP4Lq0mGNKTDoUUwujZhicRUn0Y8aF4oPguDKI+LuL45Hie ppK3zhGtSEfKB5Juz45Xz62xh5jXyC+Y+svJmXtt6u18xQKjWOcnCeWRTbPkvFbUb691R3 ZRDlIzSgMcCV53mu3r27VdTgo17PVPvtKlIdg6XZf5iSr3BJXCEKRZ82VDUiW/u6TQJz2e dNuK8pWD5NREjuKO+J76iKwBZoz+j9fnv68qqfVn4Q7JSHKiDiaRlqg8D6DRKg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N From: Rick Macklem Subject: Re: getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS Date: Tue, 15 Mar 2022 23:15:30 +0000 > "man 5 netgroup" notes that a netgroup line is limited to > 1024bytes. > > Are you sure you haven't just exceeded this limit? Thanks for pointing out. It's exactly the cause of my problem. I didn't know there is such limit. From: Rick Macklem Subject: Re: getnetgrent(3) fails to parse long netgroup entry if it is stored in NIS Date: Wed, 16 Mar 2022 05:12:49 +0000 > Oh, and you can have netgroups in netgroups, so you can > do something like... > > net0 net1,net2 > net1 (host1,,),(host2,,) > net2 (host3,,),(host4,,) > > then net0 has all 4 hosts in it. > > I think you need to break the large netgroup up into sub netgroups > where each one is <= 1024 bytes long. I fixed the problem in this way. Thank you so much! --- Yasuhiro Kimura From nobody Fri Mar 18 16:08:02 2022 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 800181A109DC; Fri, 18 Mar 2022 16:08:21 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KKppD425Qz4WGB; Fri, 18 Mar 2022 16:08:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f51.google.com with SMTP id b16so9807604ioz.3; Fri, 18 Mar 2022 09:08:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=07/9qyjzQSEYvHhCN+QfmHWqdB4VnIQVd3mG/6kzuJw=; b=UVT/RwLZwU1aiXLq+CNvy5lYQjBh4ublHIQttyvG+wEwA8CwxS5D+mScSlmx85oU12 iBjWA6yK8D1WyMS3zo2ZuOELl1nh/L13gx1igjY191pLGHBwaJ7KEpnXkk+0O6G1RSFa 5smG+NQZRZethiuDlXrIkrxb6l2X42OnlEnNKsquuAp5UeIfGvwFhh6Zw7G2V0Gxtjxp DsxnnalsNhF3SMWrToSTJgzWWABal0M0bNLDQnR7crFLDLovQ5lhpxQ0r2umGCJjCIXI dPCLDZUzOQDqbvLO8GjqbR0jTkOurTkKqkSE+wyE072rWTRDc516XlJARRgBh4u2Ipcb m8AA== X-Gm-Message-State: AOAM5325y43hrFNcqCxOivCLg/+IundTsY1d9loTWNrtlh1+HCzsOqee MJ2p/RUQ/xcjOIJXNgpOle2AvA2ohjX1eRu9fuZnQKmYWqE= X-Google-Smtp-Source: ABdhPJw3+gfZyGUONwpNVMFXxtBFLqgM9aIGMpi44CtxMCdRhkjRfUcfYWvo0oHG/5CYxcissTEyfKuGboGFurSlG8g= X-Received: by 2002:a05:6638:130b:b0:317:cc10:1c88 with SMTP id r11-20020a056638130b00b00317cc101c88mr4996899jad.34.1647619693762; Fri, 18 Mar 2022 09:08:13 -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: Ed Maste Date: Fri, 18 Mar 2022 12:08:02 -0400 Message-ID: Subject: Deprecating ISA sound cards To: freebsd-stable stable , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KKppD425Qz4WGB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.51 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.89 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.89)[-0.892]; RCVD_TLS_ALL(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.51:from]; MLMMJ_DEST(0.00)[freebsd-stable,freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.51:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N ISA sound cards have been obsolete for more than a decade, and it is (past) time to retire their drivers. This includes the following drivers/devices: snd_ad1816 Analog Devices AD1816 SoundPort snd_ess Ensoniq ESS snd_gusc Gravis UltraSound snd_mss Microsoft Sound System snd_sbc Creative Sound Blaster I have a review open to add deprecation notices: https://reviews.freebsd.org/D34604 I expect to commit this in the near future, then MFC to stable branches and remove these drivers from main. Please follow up if there's a reason we should postpone the removal of any of these drivers. From nobody Fri Mar 18 20:05:50 2022 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 768F31A2D77C; Fri, 18 Mar 2022 20:06:01 +0000 (UTC) (envelope-from joel@vnode.se) Received: from oden.vnode.se (oden.vnode.se [IPv6:2001:19f0:6c01:6b7:5400:1ff:fe33:16b1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "oden.vnode.se", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KKw4S14vdz3hsw; Fri, 18 Mar 2022 20:06:00 +0000 (UTC) (envelope-from joel@vnode.se) Received: from ymer.vnode.se (81-225-158-129-no280.tbcn.telia.com [81.225.158.129]) by oden.vnode.se (Postfix) with ESMTPSA id A90841F409; Fri, 18 Mar 2022 21:05:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vnode.se; s=mail; t=1647633950; bh=qsCAPPX34fFlkNvrawd7uXprX0aM69GEY3hBV4g1JUg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=DQkDlWYV99hB7V94CyXP1RoPoJG/Emo1hXXNK5GJQltbXQQvkA5DOnQLAWI2lSS8J uugFBTy9sVxXmZ46P4l0tWSSiJITwEGsXfT5G763s5vD5i9OSiDTLV7faJ164p/FTP Ieh1vZdnavvo2YHCnlXakCj+xJgyQJtA7Z5gAcGc= Date: Fri, 18 Mar 2022 21:05:50 +0100 From: Joel Dahl To: Ed Maste Cc: freebsd-stable stable , FreeBSD Current Subject: Re: Deprecating ISA sound cards Message-ID: Mail-Followup-To: Ed Maste , freebsd-stable stable , FreeBSD Current References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KKw4S14vdz3hsw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=vnode.se header.s=mail header.b=DQkDlWYV; dmarc=pass (policy=quarantine) header.from=vnode.se; spf=pass (mx1.freebsd.org: domain of joel@vnode.se designates 2001:19f0:6c01:6b7:5400:1ff:fe33:16b1 as permitted sender) smtp.mailfrom=joel@vnode.se X-Spamd-Result: default: False [-2.08 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[vnode.se:s=mail]; FREEFALL_USER(0.00)[joel]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a:oden.vnode.se]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.92)[0.923]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[vnode.se:+]; DMARC_POLICY_ALLOW(-0.50)[vnode.se,quarantine]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:6c00::/38, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[81.225.158.129:received] X-ThisMailContainsUnwantedMimeParts: N On Fri, Mar 18, 2022 at 12:08:02PM -0400, Ed Maste wrote: > ISA sound cards have been obsolete for more than a decade, and it is > (past) time to retire their drivers. This includes the following > drivers/devices: > > snd_ad1816 Analog Devices AD1816 SoundPort > snd_ess Ensoniq ESS > snd_gusc Gravis UltraSound > snd_mss Microsoft Sound System > snd_sbc Creative Sound Blaster You can remove snd_aureal, snd_ds1 and snd_maestro as well while you're at it. They've been broken for 10+ years: https://lists.freebsd.org/pipermail/freebsd-multimedia/2012-January/012751.html -- Joel From nobody Fri Mar 18 20:37:42 2022 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 C72791A35544; Fri, 18 Mar 2022 20:38:02 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KKwnP5G4Dz3pkl; Fri, 18 Mar 2022 20:38:01 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f46.google.com with SMTP id q11so10603333iod.6; Fri, 18 Mar 2022 13:38:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JG1BTBBHil+LODEUsYlG/zBoCLw1xFLU1ono5TBLsYo=; b=IfFtQqRLmx1hdakbd8zy0ie3MTUZxJ0RDRWRlsVZ5jxPMl0VoZNkMKWfJAkh9VgxGX Bjbv0Ytxzqj9K+4YBFA2XP3LoZ2UJrWM8prox7xpU500v4i+EYfVdr2gS4lgJVpa9QK/ TUaYgywstKoVQUZGDurRzXOPB1aADGXa+qoWCN+3bjt54MD9B2SBqsqRo3LhU/343ZAm ZysveMlb44UgyGFr6kDfjvSphBjAoxjnBalEAz1JXDU8svwCZCDJp2xB8pXBx8cVNgau z+mciOg2bU59XZGDqV2fOHPsA36zklRMseQ8zckEn/3adxEKF+d9KTihZbe9GqcIVGKr 3Srw== X-Gm-Message-State: AOAM533J0HN5Kwhx071ecTBV6fIH38oyRL5QFVcwmf8zV5FgGiq1SYH/ d3Jh5UWH2r08SrXrPIWGOXvZjrVSAZETCyIQhcrFOifw X-Google-Smtp-Source: ABdhPJylrbeKUVnGHnotbkyqcofpHe0TLu9xyuuVNjQiDOD350Oq9R4GXkpxL8+PKIBHIMnpKhUnlglFYA+poE4Kd4o= X-Received: by 2002:a05:6602:2b8e:b0:5e9:74e7:6b01 with SMTP id r14-20020a0566022b8e00b005e974e76b01mr5378406iov.127.1647635874279; Fri, 18 Mar 2022 13:37:54 -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: Ed Maste Date: Fri, 18 Mar 2022 16:37:42 -0400 Message-ID: Subject: Re: Deprecating ISA sound cards To: Ed Maste , freebsd-stable stable , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KKwnP5G4Dz3pkl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.96 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.96)[-0.959]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.46:from]; MLMMJ_DEST(0.00)[freebsd-stable,freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.46:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 18 Mar 2022 at 16:06, Joel Dahl wrote: > > On Fri, Mar 18, 2022 at 12:08:02PM -0400, Ed Maste wrote: > > ISA sound cards have been obsolete for more than a decade, and it is > > (past) time to retire their drivers. This includes the following > > drivers/devices: > > > > ... > You can remove snd_aureal, snd_ds1 and snd_maestro as well while you're at it. > They've been broken for 10+ years: > https://lists.freebsd.org/pipermail/freebsd-multimedia/2012-January/012751.html Thanks for the note. I removed snd_aureal just now as it was not even connected to the build. I'll take care of the others soon. From nobody Fri Mar 18 23:47:04 2022 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 BA60E1A1EDB5 for ; Fri, 18 Mar 2022 23:47:14 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KL0zj5klmz4rT6 for ; Fri, 18 Mar 2022 23:47:13 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id VKSEnMEde43SgVMJGnWEnF; Fri, 18 Mar 2022 23:47:06 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id VMJFnXN42159UVMJGnIcdC; Fri, 18 Mar 2022 23:47:06 +0000 X-Authority-Analysis: v=2.4 cv=frTP2X0f c=1 sm=1 tr=0 ts=623519fa a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=o8Y5sQTvuykA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=dJq77ky0u75uFOt9mL4A:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 7C9D5382 for ; Fri, 18 Mar 2022 16:47:05 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 6C14AED; Fri, 18 Mar 2022 16:47:04 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-current@freebsd.org Subject: DTrace Brokenness 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 Date: Fri, 18 Mar 2022 16:47:04 -0700 Message-Id: <20220318234704.6C14AED@slippy.cwsent.com> X-CMAE-Envelope: MS4xfNZcnj3KtIFux1Q4sQkmToMJc6RxMLm8KsnLK1+u0HrwgytCEpt80eLNGr225D71Kf64RCmTIh4MpRquslFO5kO3ZHXcJ61wEIbNV7DpcyVc+4z2GJWI ji5Zd8mwRpmvtXN7B8FkvziSBa2jlF7Io/dxnrlSlZE7V6kpK5j6lyx5YL/huCB3EoU0wCiNro9qAfL6vxx7fk4LxFU+djPUk9g= X-Rspamd-Queue-Id: 4KL0zj5klmz4rT6 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [0.07 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[70.66.148.124:received]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.32:from]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.77)[0.772]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[3.97.99.32:from] X-ThisMailContainsUnwantedMimeParts: N It's been a while (~ 4-6 months) since I've last used dtrace. Needing to use it again today scripts that worked before fail to. A first example: cwfw# cat dt10.d #!/usr/sbin/dtrace -s fbt::ipf_check:entry { parintf("%x\n", (void) arg[1]); } cwfw# Results in this error: cwfw# ./dt10.d dtrace: failed to compile script ./dt10.d: "/usr/lib/dtrace/psinfo.d", line 1: cannot translate from "struct thread *" to "lwpsinfo_t *" cwfw# Another example, slippy# cat dtrace.d #!/usr/sbin/dtrace -s fbt::uma_reclaim:entry { printf("in uma_reclaim\n"); } slippy# Results in the same error: slippy# ./dtrace.d dtrace: failed to compile script ./dtrace.d: "/usr/lib/dtrace/psinfo.d", line 1: cannot translate from "struct thread *" to "lwpsinfo_t *" slippy# A variation of the second example, slippy# cat dtrace.sh #!/bin/sh - dtrace -n 'fbt::uma_reclaim:entry { printf("in uma_reclaim\n"); }' slippy# Results in two errors, the first being that the -n option results in an invalid probe specified and the second being the struct thread * error. slippy# ./dtrace.sh dtrace: invalid probe specifier fbt::uma_reclaim:entry { printf("in uma_reclaim\n"); }: "/usr/lib/dtrace/psinfo.d", line 1: cannot translate from "struct thread *" to "lwpsinfo_t *" slippy# I'm not sure if this is related to 2d5d2a986ce or something else. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From nobody Sat Mar 19 02:24:06 2022 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 E6E6E1A1E458; Sat, 19 Mar 2022 02:24:14 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "soaustin.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KL4St2w0Pz3pyd; Sat, 19 Mar 2022 02:24:14 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.222.6.11]) by mail.soaustin.net (Postfix) with ESMTPSA id 856661A145; Sat, 19 Mar 2022 02:24:07 +0000 (UTC) Date: Sat, 19 Mar 2022 02:24:06 +0000 From: Mark Linimon To: Ed Maste Cc: freebsd-stable stable , FreeBSD Current Subject: Re: Deprecating ISA sound cards Message-ID: <20220319022405.GA29646@lonesome.com> 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: User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 4KL4St2w0Pz3pyd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of linimon@lonesome.com has no SPF policy when checking 18.222.6.11) smtp.mailfrom=linimon@lonesome.com X-Spamd-Result: default: False [-0.07 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[linimon]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.981]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lonesome.com]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_MEDIUM(0.68)[0.676]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.40)[18.222.6.11:received,18.222.6.11:from]; NEURAL_HAM_SHORT(-0.36)[-0.364]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:18.220.0.0/14, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N Anyone objecting to this, be careful, I might ship a pile of such things to you from the depths of the closets :-) mcl From nobody Sat Mar 19 04:28:22 2022 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 A444E1A1722A for ; Sat, 19 Mar 2022 04:28:25 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KL7D85D5Qz4mT0 for ; Sat, 19 Mar 2022 04:28:24 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTP id VQPwnMVKh43SgVQhUnWn1b; Sat, 19 Mar 2022 04:28:24 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id VQhTnPqyXQV6mVQhUn2cO2; Sat, 19 Mar 2022 04:28:24 +0000 X-Authority-Analysis: v=2.4 cv=PbTsOwtd c=1 sm=1 tr=0 ts=62355be8 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=o8Y5sQTvuykA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=VxmjJ2MpAAAA:8 a=TbKV5qd_dphDPWYV2MIA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 a=7gXAzLPJhVmCkEl4_tsf:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 01C49153 for ; Fri, 18 Mar 2022 21:28:23 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 7219B10F; Fri, 18 Mar 2022 21:28:22 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-current@freebsd.org Subject: Re: DTrace Brokenness [Solved] In-reply-to: <20220318234704.6C14AED@slippy.cwsent.com> References: <20220318234704.6C14AED@slippy.cwsent.com> Comments: In-reply-to Cy Schubert message dated "Fri, 18 Mar 2022 16:47:04 -0700." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Mar 2022 21:28:22 -0700 Message-Id: <20220319042822.7219B10F@slippy.cwsent.com> X-CMAE-Envelope: MS4xfPG6yYwhxVRX/ZpuNkzs2ShzOygJtortaND9KiEdxbhVHBosIyAUdSuszGU+crtzfLz4cr/3iMs8oQ9TjB5cWLWp/j+fB9WOTgR78b/IMfJPjeNfJvmn RNG8pOhuq8Be8KMdh52A4MhtPzmarBlb6+F8Em9NRPeZEZxxelN4xVHTY1moPqOtpyjJSY2NnV5PKsOjb7TwEzBB+J+3nFBPsEs= X-Rspamd-Queue-Id: 4KL7D85D5Qz4mT0 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.60 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[70.66.148.124:received]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.32:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.900]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[3.97.99.32:from] X-ThisMailContainsUnwantedMimeParts: N A full clean build resolved the problem. It was likely some incompatible CTF or possibly some other patch that touched DTrace that left my obj tree in an inconsistent state. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. In message <20220318234704.6C14AED@slippy.cwsent.com>, Cy Schubert writes: > It's been a while (~ 4-6 months) since I've last used dtrace. Needing to > use it again today scripts that worked before fail to. > > A first example: > > cwfw# cat dt10.d > #!/usr/sbin/dtrace -s > > fbt::ipf_check:entry { > parintf("%x\n", (void) arg[1]); > } > > cwfw# > > Results in this error: > > cwfw# ./dt10.d > dtrace: failed to compile script ./dt10.d: "/usr/lib/dtrace/psinfo.d", line > 1: cannot translate from "struct thread *" to "lwpsinfo_t *" > cwfw# > > Another example, > > slippy# cat dtrace.d > #!/usr/sbin/dtrace -s > > fbt::uma_reclaim:entry { > printf("in uma_reclaim\n"); > } > slippy# > > Results in the same error: > > slippy# ./dtrace.d > dtrace: failed to compile script ./dtrace.d: "/usr/lib/dtrace/psinfo.d", > line 1: cannot translate from "struct thread *" to "lwpsinfo_t *" > slippy# > > > A variation of the second example, > > slippy# cat dtrace.sh > #!/bin/sh - > dtrace -n 'fbt::uma_reclaim:entry { printf("in uma_reclaim\n"); }' > slippy# > > Results in two errors, the first being that the -n option results in an > invalid probe specified and the second being the struct thread * error. > > slippy# ./dtrace.sh > dtrace: invalid probe specifier fbt::uma_reclaim:entry { printf("in > uma_reclaim\n"); }: "/usr/lib/dtrace/psinfo.d", line 1: cannot translate > from "struct thread *" to "lwpsinfo_t *" > slippy# > > I'm not sure if this is related to 2d5d2a986ce or something else. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > The need of the many outweighs the greed of the few. > > > From nobody Sat Mar 19 05:10:52 2022 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 098E21A24634; Sat, 19 Mar 2022 05:11:02 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KL89K2H7Cz3C7J; Sat, 19 Mar 2022 05:11:01 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id VCMtnwESMgTZYVRMdnAsjF; Sat, 19 Mar 2022 05:10:55 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id VRMbn1HSJd7RfVRMcn0w8M; Sat, 19 Mar 2022 05:10:55 +0000 X-Authority-Analysis: v=2.4 cv=XrLphHJ9 c=1 sm=1 tr=0 ts=623565df a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=o8Y5sQTvuykA:10 a=-FGs326eAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=ggNHfIRPQDHmMnDOOdYA:9 a=CjuIK1q_8ugA:10 a=t-_DgqN1gnUA:10 a=7Nw9HX5Nqxt2AnyyOhBr:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 4EFD01A5; Fri, 18 Mar 2022 22:10:53 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 277165D; Fri, 18 Mar 2022 22:10:53 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Mark Linimon cc: Ed Maste , freebsd-stable stable , FreeBSD Current Subject: Re: Deprecating ISA sound cards In-reply-to: <20220319022405.GA29646@lonesome.com> References: <20220319022405.GA29646@lonesome.com> Comments: In-reply-to Mark Linimon message dated "Sat, 19 Mar 2022 02:24:06 -0000." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Mar 2022 22:10:52 -0700 Message-Id: <20220319051053.277165D@slippy.cwsent.com> X-CMAE-Envelope: MS4xfHO4Wx4veCbpKa0DNy4zRZ6NTCp3QlQpI2SkGQTsI8Bx/qhrlFYAtlOmOYX0peL6xbfyqaUlbgVM8mjpijSyfAbLx1LjcHsDqdAEJYD5a8Md2aBTYWn6 pKvJ/nhQlLX2Ns3NtjlH8Cuq77jxe4ZTXN6Q7mKJjvl4/AwqPjoKe01ytqEU+hIVsj7iYQiXyODeOPj+LSPZA8v80l7XvtGGGP+Mf7xCNG9Z1kqeKMz27kow 8Kke//VtSZC/JtLQIovNP6FBES/NHb9ICTGolcBm4qWOaeCY1YVMqlO40Hy95YSiVXMyM6/GSRjrhtfnyBJozA== X-Rspamd-Queue-Id: 4KL89K2H7Cz3C7J X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [2.32 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[70.66.148.124:received]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(1.00)[0.999]; NEURAL_HAM_LONG(-0.97)[-0.969]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.988]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-stable,freebsd-current]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_VERYGOOD(0.00)[3.97.99.33:from] X-ThisMailContainsUnwantedMimeParts: N In message <20220319022405.GA29646@lonesome.com>, Mark Linimon writes: > Anyone objecting to this, be careful, I might ship a pile of such > things to you from the depths of the closets :-) <<=1 -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From nobody Sat Mar 19 19:28:16 2022 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 7001A1A216B1 for ; Sat, 19 Mar 2022 19:28:27 +0000 (UTC) (envelope-from ltning@anduin.net) Received: from mail.anduin.net (mail.anduin.net [185.42.170.45]) (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 4KLWBd6Sdjz4tFn for ; Sat, 19 Mar 2022 19:28:25 +0000 (UTC) (envelope-from ltning@anduin.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=anduin.net; s=dkim2021; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References: In-Reply-To:Date:To:From:Subject:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KdSC3cyn5KaYxo06iMwJjQ2Etk821Ic94e0BmsTdYVM=; t=1647718105; x=1648582105; b=dUWr6Kr0crKhGz7iJFXVOpORpKxJrUFiS4xxbZWBgaaKzyV8BVaCJJq8B/Hwjc7Y8LziNRl58mz 9rLRWXjDFT4jBGUZtDuZUuQ1cwoY1aK75+jmJ6r4Yk3LE8IgbseQMuzr2GPTQun2XG67RiC+zHYbC ygxvhtewFdGNSwp6JnsZe2yb/Gzx3fTbBmnJZc4/syO6dadzQ7VETxyosRje2RKtHNwY1QlsnFqhB 8tZGK1fuDSD4/2R8DF+7UuKW4rE76w18gAkSb2NZkpPG4UfEjsu6e9dPOkR8tg21WuXgFp0NNYQGo IGg+/kWO07VAm1vHc0aeB9Mk1hjkDFD4c3CQ==; Received: by mail.modirum.com with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1nVekL-0008Fy-6a for freebsd-current@freebsd.org; Sat, 19 Mar 2022 19:28:17 +0000 Message-ID: <03425cbd5948cd6460c3e9f5e1f1c2909493f238.camel@anduin.net> Subject: Re: Deprecating ISA sound cards From: Eirik =?ISO-8859-1?Q?=D8verby?= To: freebsd-current@freebsd.org Date: Sat, 19 Mar 2022 20:28:16 +0100 In-Reply-To: <20220319022405.GA29646@lonesome.com> References: <20220319022405.GA29646@lonesome.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 FreeBSD GNOME Team 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-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-Rspamd-Queue-Id: 4KLWBd6Sdjz4tFn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=anduin.net header.s=dkim2021 header.b=dUWr6Kr0; dmarc=none; spf=pass (mx1.freebsd.org: domain of ltning@anduin.net designates 185.42.170.45 as permitted sender) smtp.mailfrom=ltning@anduin.net X-Spamd-Result: default: False [-2.79 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[anduin.net:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_MIXED_CHARSET(0.71)[subject]; ASN(0.00)[asn:62248, ipnet:185.42.170.0/24, country:EE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[anduin.net:s=dkim2021]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[anduin.net]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, 2022-03-19 at 02:24 +0000, Mark Linimon wrote: > Anyone objecting to this, be careful, I might ship a pile of such > things to you from the depths of the closets :-) Such threats! :> But I've already volunteered as tribute here. I won't be arguing hard for keeping these drivers (seeing as I'm clearly the oddball for having FreeBSD running on hardware which has 1) ISA bus and 2) ISA sound cards..), but I'll be willing to suffer any pile of cards that would otherwise land on the trash heap.. /Eirik From nobody Sat Mar 19 21:24:36 2022 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 513A51A19868; Sat, 19 Mar 2022 21:24:50 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KLYmx5XSLz3pXg; Sat, 19 Mar 2022 21:24:49 +0000 (UTC) (envelope-from 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 22JLOb82035730; Sat, 19 Mar 2022 14:24:43 -0700 (PDT) (envelope-from bsd-lists@bsdforge.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 Date: Sat, 19 Mar 2022 14:24:36 -0700 From: Chris To: Ed Maste Cc: freebsd-stable stable , FreeBSD Current Subject: Re: Deprecating ISA sound cards In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <89c73d2114c1c7f8b5877e7174178a23@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_6688ab9f82bc0b96bd891e3b23e099e0" X-Rspamd-Queue-Id: 4KLYmx5XSLz3pXg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_6688ab9f82bc0b96bd891e3b23e099e0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-03-18 09:08, Ed Maste wrote: > ISA sound cards have been obsolete for more than a decade, and it is > (past) time to retire their drivers. This includes the following > drivers/devices: > > snd_ad1816 Analog Devices AD1816 SoundPort > snd_ess Ensoniq ESS > snd_gusc Gravis UltraSound > snd_mss Microsoft Sound System > snd_sbc Creative Sound Blaster > > I have a review open to add deprecation notices: > https://reviews.freebsd.org/D34604 > > I expect to commit this in the near future, then MFC to stable > branches and remove these drivers from main. Please follow up if > there's a reason we should postpone the removal of any of these > drivers. This only hurts from a nostalgic perspective. Those GUS cards were incredible! I have a board running freebsd that has 2 GUS cards in it running simultaneously. Sniff... cést la vié --=_6688ab9f82bc0b96bd891e3b23e099e0 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_6688ab9f82bc0b96bd891e3b23e099e0-- From nobody Sun Mar 20 14:43:49 2022 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 3DC9A1A1141C; Sun, 20 Mar 2022 14:43:52 +0000 (UTC) (envelope-from theraven@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KM0qr1GTxz3Fpv; Sun, 20 Mar 2022 14:43:52 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647787432; 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=z2pkBDLlfo5j2hVtSrU0SelbAs1WwE0TbSA5p/p3I0M=; b=giaq+apwbGCpTT5G5Fa7CX0/Mfm8Fuplelf8UMilNNJ+wtzF1jM4SZsduZWXQQVtlT+R/D W1HDI2W43X2EcXgyvRXkLL/GGtS0gRWVSML491WnTwGiX7xXSfhMb3hKSbiOrgpPCZIOx8 hNA24YOza/7BLKxudQchbon1PoEKvZSBx6iZhnAArZOQYtrNTSDQ1exgTiHakmxnDxovPv ZhJY/cOEAI9Y/UV4Y9CrHOdHnKBoBDpgpQEZAb9o8R9JWxWHUOitXoD5RaB94HiOLWPy1E lMOzE8L3iNbAs403K1NxtqLMw1wQsGA12t9Xxum3ZtHUe+3+O7hLyQbsao15Qg== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 05D12E8A8; Sun, 20 Mar 2022 14:43:52 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.64] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id C3EF22F627; Sun, 20 Mar 2022 14:43:50 +0000 (GMT) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: Deprecating ISA sound cards From: David Chisnall In-Reply-To: <89c73d2114c1c7f8b5877e7174178a23@bsdforge.com> Date: Sun, 20 Mar 2022 14:43:49 +0000 Cc: Ed Maste , freebsd-stable stable , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <04DBD89A-A857-4790-BE3B-C3B90AD563EC@FreeBSD.org> References: <89c73d2114c1c7f8b5877e7174178a23@bsdforge.com> To: Chris X-Mailer: Apple Mail (2.3608.120.23.2.7) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647787432; 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=z2pkBDLlfo5j2hVtSrU0SelbAs1WwE0TbSA5p/p3I0M=; b=C9k/3AdZvoI3ameEed7I1qWS82CfFiUa6PMDEw6ZojrE3kjo87u90E2GD1z724WWZyvKp8 n5UUegz0LWiVfQ3GKOBMXLLuRP0UNj9M3phKmdxpk7hbv+/X/DMSGNiIt1cZ0uR2BMlSxr //D9m1IXoLS5dQuZW/DeyAXaeGRBmafFbQWdh+Z00scmPGZw856Np4RIvzWgxEAk9Lwz1v yMlmeEElGiv9kLgw+3+Qsw3+Jj564rlkvYW4cmonZrWKedyfPF+qzCj/k23xpboamlEgnt depQrn1DbbWP7aNUe3/MRCkOXqjaTKaz6UznICeAV/XHNZEPj+wAUsYk5mobLA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647787432; a=rsa-sha256; cv=none; b=rO2XeUejrd1qHthlpTiny1R1yb0wHAj1Ox9F+IOSOMTqjWalOU4Q9rtYmYQsGIpmNe7ikY po0b2SO9zoyNnWJAZ0+yeIK+kvgX7/VnrJE9fNC91PCmkvR6z5J7k0RUgTI4lZaCB4chTY pXdIpQs5JcHnmvcmQ6C9LldlDMSxMrxevAbEJll2fgjI1PLpkUnUhprhe5G/81jlKjBcqT A/j9JL7ksXGTJqvFSX3LkJCopu+ghCBijmkfOPPPuaYmvae9peyEvd77yjMkMxZTym3OpY JtabNo11XTWdFtwy9lcdHgxsdWVP2b0bEPYGyK2gXTO+j1vcpBH+u0brKAxVNw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 19 Mar 2022, at 21:24, Chris wrote: >=20 > On 2022-03-18 09:08, Ed Maste wrote: >> ISA sound cards have been obsolete for more than a decade, and it is >> (past) time to retire their drivers. This includes the following >> drivers/devices: >> snd_ad1816 Analog Devices AD1816 SoundPort >> snd_ess Ensoniq ESS >> snd_gusc Gravis UltraSound >> snd_mss Microsoft Sound System >> snd_sbc Creative Sound Blaster >> I have a review open to add deprecation notices: >> https://reviews.freebsd.org/D34604 >> I expect to commit this in the near future, then MFC to stable >> branches and remove these drivers from main. Please follow up if >> there's a reason we should postpone the removal of any of these >> drivers. > This only hurts from a nostalgic perspective. Those GUS cards were = incredible! > I have a board running freebsd that has 2 GUS cards in it running Exactly my reaction. You can tell you=E2=80=99re old when drivers are = removed from the tree for mainstream hardware that you never owned but = wished that you could afford. David From nobody Sun Mar 20 19:16:42 2022 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 21E331A13B73; Sun, 20 Mar 2022 19:16:57 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KM6tv6cwrz4njh; Sun, 20 Mar 2022 19:16:55 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 1464eb57; Sun, 20 Mar 2022 19:16:47 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 5255dae0 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Sun, 20 Mar 2022 19:16:44 +0000 (UTC) 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 (1.0) Subject: Re: Deprecating ISA sound cards From: Michael Gmelin In-Reply-To: <04DBD89A-A857-4790-BE3B-C3B90AD563EC@FreeBSD.org> Date: Sun, 20 Mar 2022 20:16:42 +0100 Cc: Chris , Ed Maste , freebsd-stable stable , FreeBSD Current Message-Id: <6C820317-449B-4C3D-AB03-D18A763A7DC1@freebsd.org> References: <04DBD89A-A857-4790-BE3B-C3B90AD563EC@FreeBSD.org> To: David Chisnall X-Mailer: iPhone Mail (19D52) X-Rspamd-Queue-Id: 4KM6tv6cwrz4njh X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [2.92 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_LONG(0.52)[0.519]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 20. Mar 2022, at 15:45, David Chisnall wrote: >=20 > =EF=BB=BFOn 19 Mar 2022, at 21:24, Chris wrote: >>=20 >>> On 2022-03-18 09:08, Ed Maste wrote: >>> ISA sound cards have been obsolete for more than a decade, and it is >>> (past) time to retire their drivers. This includes the following >>> drivers/devices: >>> snd_ad1816 Analog Devices AD1816 SoundPort >>> snd_ess Ensoniq ESS >>> snd_gusc Gravis UltraSound >>> snd_mss Microsoft Sound System >>> snd_sbc Creative Sound Blaster >>> I have a review open to add deprecation notices: >>> https://reviews.freebsd.org/D34604 >>> I expect to commit this in the near future, then MFC to stable >>> branches and remove these drivers from main. Please follow up if >>> there's a reason we should postpone the removal of any of these >>> drivers. >> This only hurts from a nostalgic perspective. Those GUS cards were incred= ible! >> I have a board running freebsd that has 2 GUS cards in it running >=20 > Exactly my reaction. You can tell you=E2=80=99re old when drivers are rem= oved from the tree for mainstream hardware that you never owned but wished t= hat you could afford. >=20 I=E2=80=99ll never give away my GUS classic/GF1 with full 1MB onboard RAM(!)= . It was too much fun to program and tracker/demo support was superb. Plus, r= ed PCBs felt really 1337 back then. That said (and assuming it still works), it's unlikely I would use it with a= nything else but DOS these days. Cheers Michael From nobody Tue Mar 22 22:02:19 2022 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 E9AE81A440BE for ; Tue, 22 Mar 2022 22:02:32 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KNQT35pSmz3DyN for ; Tue, 22 Mar 2022 22:02:31 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: by mail-ej1-x633.google.com with SMTP id d10so39049316eje.10 for ; Tue, 22 Mar 2022 15:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=A4+ZoHXbY+Xiy/Onpojr7r/w7R4HHjb3NtwAe29e3yY=; b=Rb6vPErQpAinKxh93ENwbro70iZYS2VPmN9pmWiLq7wWITwDdYryx5cL1lze+yMY0A JpSioK/39FFDV+yYtMRLPujzYQshhIC3y5niOi8qwwYeAVryYVGg94ZsQEeGIYnE8vy1 +2ZkeTvP1O2fGKeZ53UBDqm56ITkFeOoYYCmkwiYwEUeeTBOzxDowfefDAxrYaDZCCF8 D3JBlSL1j+/2oWOHExIgjXCkr5vLyWt5GRc/dWx1KyGT2otURfiphUeMI2lnM+br7vXl FzEiIKNR6FU+5GFwrbLjFbnsjtycHv+hyDrChAI/PXAtvaSF0z0+wmkkN3RaPupZLRpX Buig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=A4+ZoHXbY+Xiy/Onpojr7r/w7R4HHjb3NtwAe29e3yY=; b=FKYiokE+eT3NTkDTkpWAvJTZMbMhhwhA/Xh//LCGpEUIrTIpgf/63yZ+xf4M/w5C0T Aj4lqqM6fuVTpF7S9SGdUAZ5ZjMVjYjm3jqQ4g3KbpIoTo2Bcia71bJMErtlIRj2XJA5 1ItFtxwJ/QttpjcLww3lR7yPWOMnz2kUuq5qK9Qc5QxpXlgvhTUxN2/c+2TsHZoIeX4i Rl1vYDGgzI7kPcfbJxKuO3UadroI5ARHm23N5db/wMnhTmGLIFPq/4qJP3y6nI/WLM89 C//W5IWXMLM9KUZm8TUXN3PhsxKAvXSiGay1sWXmx1M3Nh8EMVSm3tkqWRzq8y5hB/fZ y0Aw== X-Gm-Message-State: AOAM533DTGqvyR3EJ9+Pnb1x5oROvQQQkSf6lRiYXabOnCjkH70k8nUG NLkRUUot9kbfNU/tybhaWvM13B+LCJuLkhYbwWiEMYAq04U= X-Google-Smtp-Source: ABdhPJyuqPpAvMXQioI6589ycnmQnk7zhjj8Mr8VRjBtPOfxJ4KOuWV41BHcs9KpPmd162uV1MeHkicQhKpYAen4Zn8= X-Received: by 2002:a17:906:b155:b0:6c9:ea2d:3363 with SMTP id bt21-20020a170906b15500b006c9ea2d3363mr27431809ejb.729.1647986550370; Tue, 22 Mar 2022 15:02:30 -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: Chuck Tuffli Date: Tue, 22 Mar 2022 15:02:19 -0700 Message-ID: Subject: network address not restored on resume To: FreeBSD-Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KNQT35pSmz3DyN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Rb6vPErQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ctuffli@gmail.com designates 2a00:1450:4864:20::633 as permitted sender) smtp.mailfrom=ctuffli@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::633:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On a recent-ish current (git hash 66b86c8a7604), after resuming from sleep, the main network interface doesn't get restored. Further, manually fixing this via service netif or ifconfig seems to fail. Am I doing something wrong? root@stargate:~ # uname -a FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT #2 main-n253430-66b86c8a7604: Sat Feb 26 23:35:02 PST 2022 root@stargate:~ # ifconfig igc0 igc0: flags=8863 metric 0 mtu 1500 options=4e527bb ether 1c:69:7a:a9:cd:1c inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 root@stargate:~ # zzz root@stargate:~ # ifconfig igc0 igc0: flags=8c22 metric 0 mtu 1500 options=4e527bb ether 1c:69:7a:a9:cd:1c media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 root@stargate:~ # service netif restart igc0 Stopping Network: igc0. igc0: flags=8c22 metric 0 mtu 1500 options=4e527bb ether 1c:69:7a:a9:cd:1c media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 Starting Network: igc0. igc0: flags=8863 metric 0 mtu 1500 options=4e527bb ether 1c:69:7a:a9:cd:1c inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255 media: Ethernet autoselect status: no carrier nd6 options=29 root@stargate:~ # root@stargate:~ # ifconfig igc0 igc0: flags=8c22 metric 0 mtu 1500 options=4e527bb ether 1c:69:7a:a9:cd:1c media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 root@stargate:~ # ifconfig igc0 inet 192.168.5.10/24 igc0: flags=8c22 metric 0 mtu 1500 options=4e527bb ether 1c:69:7a:a9:cd:1c media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 root@stargate:~ # From nobody Tue Mar 22 23:24:57 2022 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 CA0C51A2CD55 for ; Tue, 22 Mar 2022 23:25:47 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KNSK70Hrxz3mTJ for ; Tue, 22 Mar 2022 23:25:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-oi1-x22c.google.com with SMTP id q129so78037oif.4 for ; Tue, 22 Mar 2022 16:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OX8l2mhkhEnkE5XlTn4S3SFB93ua+rG2zMhBRDNDvlA=; b=dPyYMuqB/o06humAgs162EEtzZFLDRs95Nq06o5NqGehOy+nIWqUfXIBu6nE3bk4zm 3r1BOqbE6DspByvw+ZF1dAOA3cGBZ6mNzr2c71oNLOYxKJezkMqNqZudmyjvs1M9VrxK SDvAbR+7E7P41CJ0THfgVHVX6Iy7HlZAvs3aO8Q0e5t+WN4cmn4WPemQulMA8bg5IbTO ztuzB5OccpaXhK0wLSEn3/V8UU6ifivlFPF9ba/dE3WCk3xU2XfVUn2HahiaWGbN6W4o XQX4hmD6jtCz410HsYquy8Cy4k0VLXseMCG+q9i07WzTzNSMD8GNGfCW+bLh5kiiWki3 fOHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OX8l2mhkhEnkE5XlTn4S3SFB93ua+rG2zMhBRDNDvlA=; b=eLe0ou0AsGQ9OYbCNiqd5ljWzsAhctpGOA0qTCQEzl0AICLo7oZGtb3nhC4aeJrjqD DGiu5U1ixY7AcROA0Z8i3b1f8WhQF/AAsCVFBFhx0jUXHKrVyTJKEBNNKRxTo0khAQqF 6KAn0FEQxTcsk/YyIhA5sVVDw6L3T1GNdoCv2Z/XwRHmUk3YK0310QTKI0TP4r5a/6YI Vdq9BmSZvc+SdRkiP4f0p0CtCu2I/6WWrvLDoR5HRvu6482syBFBXRRlKpEd623qwBNK 5RKm7UCIcHeujbgOt4ymHDMGhdiY7mC0ks8RKb9PJJJeb6PBeug/I/5n3O3ieQOyViho RZiw== X-Gm-Message-State: AOAM532+mtcdnIRk40yKtcqLwhD27kRYqftdUwg3EMn8SZrIN+l7Qbg2 IDygTlBoa/fwURFD3LWhJ3uJGBJmooAORklhsLs= X-Google-Smtp-Source: ABdhPJx/gWSap2BUM7WmKAg2rGdOmLoVljZfgvBHXPYCUO6pE+u5+/gC5qDnivpJSPiDcpXZdfSPD4W9pnVYmFJHu7s= X-Received: by 2002:a05:6808:1a93:b0:2da:59cc:7aff with SMTP id bm19-20020a0568081a9300b002da59cc7affmr3433254oib.142.1647991546128; Tue, 22 Mar 2022 16:25:46 -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: Kevin Oberman Date: Tue, 22 Mar 2022 16:24:57 -0700 Message-ID: Subject: Re: network address not restored on resume To: Chuck Tuffli Cc: FreeBSD-Current Content-Type: multipart/alternative; boundary="000000000000b32c0805dad6eed2" X-Rspamd-Queue-Id: 4KNSK70Hrxz3mTJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=dPyYMuqB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::22c as permitted sender) smtp.mailfrom=kob6558@gmail.com X-Spamd-Result: default: False [-1.70 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22c:from]; HTTP_TO_IP(1.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000b32c0805dad6eed2 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 22, 2022 at 3:03 PM Chuck Tuffli wrote: > On a recent-ish current (git hash 66b86c8a7604), after resuming from > sleep, the main network interface doesn't get restored. Further, > manually fixing this via service netif or ifconfig seems to fail. Am I > doing something wrong? > > root@stargate:~ # uname -a > FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT #2 > main-n253430-66b86c8a7604: Sat Feb 26 23:35:02 PST 2022 > root@stargate:~ # ifconfig igc0 > igc0: flags=8863 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > root@stargate:~ # zzz > root@stargate:~ # ifconfig igc0 > igc0: flags=8c22 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > root@stargate:~ # service netif restart igc0 > Stopping Network: igc0. > igc0: flags=8c22 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > Starting Network: igc0. > igc0: flags=8863 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255 > media: Ethernet autoselect > status: no carrier > nd6 options=29 > root@stargate:~ # > root@stargate:~ # ifconfig igc0 > igc0: flags=8c22 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > root@stargate:~ # ifconfig igc0 inet 192.168.5.10/24 > igc0: flags=8c22 metric 0 mtu 1500 > > options=4e527bb > ether 1c:69:7a:a9:cd:1c > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > root@stargate:~ # > Not enough information to guess. What is the content of /etc/rc.conf in regard to configuration of this interface? What shows up in the log file when this happens (usually /var/log/messages)? The log information is particularly important. (Note that I don't have an igc interface.) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --000000000000b32c0805dad6eed2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 22, 2022 at 3:03 PM= Chuck Tuffli <ctuffli@gmail.com> wrote:
On a recent-ish current (git hash 66b86c8a760= 4), after resuming from
sleep, the main network interface doesn't get restored. Further,
manually fixing this via service netif or ifconfig seems to fail. Am I
doing something wrong?

root@stargate:~ # uname -a
FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT #2
main-n253430-66b86c8a7604: Sat Feb 26 23:35:02 PST 2022
root@stargate:~ # ifconfig igc0
igc0: flags=3D8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 m= tu 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLA= N_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLA= N_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 1c:69:7a:a9:cd:1c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet 192.168.5.10 netmask 0xffffff00 broadcast = 192.168.5.255
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect (1000baseT <full-= duplex>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: active
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_= LINKLOCAL>
root@stargate:~ # zzz
root@stargate:~ # ifconfig igc0
igc0: flags=3D8c22<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu = 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLA= N_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLA= N_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 1c:69:7a:a9:cd:1c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect (1000baseT <full-= duplex>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: active
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_= LINKLOCAL>
root@stargate:~ # service netif restart igc0
Stopping Network: igc0.
igc0: flags=3D8c22<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu = 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLA= N_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLA= N_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 1c:69:7a:a9:cd:1c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect (1000baseT <full-= duplex>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: active
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_= LINKLOCAL>
Starting Network: igc0.
igc0: flags=3D8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 m= tu 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLA= N_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLA= N_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 1c:69:7a:a9:cd:1c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet 192.168.5.10 netmask 0xffffff00 broadcast = 192.168.5.255
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: no carrier
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_= LINKLOCAL>
root@stargate:~ #
root@stargate:~ # ifconfig igc0
igc0: flags=3D8c22<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu = 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLA= N_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLA= N_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 1c:69:7a:a9:cd:1c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect (1000baseT <full-= duplex>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: active
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_= LINKLOCAL>
root@stargate:~ # ifconfig igc0 inet 192.168.5.10/24
igc0: flags=3D8c22<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu = 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLA= N_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLA= N_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 1c:69:7a:a9:cd:1c
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect (1000baseT <full-= duplex>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: active
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_= LINKLOCAL>
root@stargate:~ #
=C2=A0
Not enoug= h information to guess.

What is the content = of /etc/rc.conf in regard to configuration of this interface? What shows up= in the log file when this happens (usually /var/log/messages)? The log inf= ormation is particularly important. (Note that I don't have an igc inte= rface.)
--
= Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail:= rkoberman@gmail.c= om
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055= 683
--000000000000b32c0805dad6eed2-- From nobody Wed Mar 23 15:03:29 2022 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 7305E1A417DE for ; Wed, 23 Mar 2022 15:03:42 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KNs7K4Ncwz4pLf for ; Wed, 23 Mar 2022 15:03:41 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: by mail-ej1-x634.google.com with SMTP id qa43so3376459ejc.12 for ; Wed, 23 Mar 2022 08:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EFIw63YuR6+S7qkYpALgKLbuygnEPFwLU69rph0Tzy4=; b=aVhbaBynASKx3JGTo9v7wU6riYhwlLNyDFI/f0ajk/mRHFvspxRe2+4OQ0vg5QSCWn UJrd57E4wqL0Dydx2ay0AkFYnXKDpoeIkdP4UWEzP/9rORmsuwYu3x5gFsFVpepiM4Ob DIDgHMgRd2sK0brpArM5Inqr4IECvnmZiEku/4tqi2TYwPm2zSDksIuPaCDVnfsuKG0W H6seRMnge4SYp+bRL+ncjhNARElzW/Fm3t7XUGCfgF/aandYiS1DTsm1sfUl419JEJmG IyYvyy3THYWVLPn/3h5U3Ge3rPO+37tzNdljPkl8SdYRo46mxOPSC5uXPQqVCt88KLi3 altQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EFIw63YuR6+S7qkYpALgKLbuygnEPFwLU69rph0Tzy4=; b=uqAptaCPmsWPqIBwGn6dfiWdKRcu9h2FAWDbs9esCZnW7P314uZ7bV0DIQUs3yoX+K hudHsufB9XCZOmTy9Wgo9tnu5kCa/1wwvvJCWpxgr1WiOl9ucLux22PbpRFb5t1fXhFG bDNNeglLA/qi6EL5YL2VEXvSwQKJ1/lBUwwISsZyAhSv7ujHHcbiV33m5EebdeWkUK1q xc6E6qGwdF82ZVkZXrS+sEMo2gEUjWrO26mG0PnFhTosFAFHB9cy0puT+n8QF2WNmiWd mY04Aeh1MHM2UZIF5EY+bTBAD2+rqwggDCI4kHrbZTv8m4bsx6boQqzcpubiMbaJlwbx K3BA== X-Gm-Message-State: AOAM5336aIJxRYVM1+NycMqDozLo7O6Y3U3ezgzI6vlQ3dcP/RFbPyJ5 UE/BWy0FetmP+qWsG56DM92t0+IHzKu1fzG2USjHhUJCRwU= X-Google-Smtp-Source: ABdhPJxKiMkDeCaJxTt6TsWVlqdi23j+B1yKVi++WiHf8zrIiy5tirDg8TKztWOzEMKl3dS1lGeJs5bofiOw42PF24I= X-Received: by 2002:a17:906:b155:b0:6c9:ea2d:3363 with SMTP id bt21-20020a170906b15500b006c9ea2d3363mr358675ejb.729.1648047820438; Wed, 23 Mar 2022 08:03: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: Chuck Tuffli Date: Wed, 23 Mar 2022 08:03:29 -0700 Message-ID: Subject: Re: network address not restored on resume To: Kevin Oberman Cc: FreeBSD-Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KNs7K4Ncwz4pLf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=aVhbaByn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ctuffli@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=ctuffli@gmail.com X-Spamd-Result: default: False [-3.95 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.966]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.986]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Mar 22, 2022 at 4:25 PM Kevin Oberman wrote: > Not enough information to guess. > > What is the content of /etc/rc.conf in regard to configuration of this interface? defaultrouter="192.168.5.1" ifconfig_igc0="inet 192.168.5.10 netmask 255.255.255.0" > What shows up in the log file when this happens (usually /var/log/messages)? The log information is particularly important. (Note that I don't have an igc interface.) Mostly USB noise, other than igc0: link state changed to UP at the end ... Mar 23 07:48:33 stargate acpi[2172]: resumed at 20220323 07:48:33 Mar 23 07:48:34 stargate kernel: ugen1.2: at usbus1 Mar 23 07:48:34 stargate kernel: uaudio0 on uhub1 Mar 23 07:48:34 stargate kernel: uaudio0: on usbus1 Mar 23 07:48:34 stargate kernel: uaudio0: Play[0]: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x2ms buffer. Mar 23 07:48:34 stargate kernel: uaudio0: Play[0]: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x2ms buffer. Mar 23 07:48:34 stargate kernel: uaudio0: Record[0]: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x2ms buffer. Mar 23 07:48:34 stargate kernel: uaudio0: Record[0]: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x2ms buffer. Mar 23 07:48:34 stargate kernel: uaudio0: No MIDI sequencer. Mar 23 07:48:34 stargate kernel: pcm2: on uaudio0 Mar 23 07:48:34 stargate kernel: uaudio0: HID volume keys found. Mar 23 07:48:34 stargate kernel: ugen1.3: at usbus1 Mar 23 07:48:34 stargate kernel: uhub2 on uhub1 Mar 23 07:48:34 stargate kernel: uhub2: on usbus1 Mar 23 07:48:34 stargate kernel: uhub2: MTT enabled Mar 23 07:48:35 stargate kernel: uhub2: 4 ports with 4 removable, self powered Mar 23 07:48:35 stargate kernel: ugen1.4: at usbus1 Mar 23 07:48:35 stargate kernel: ukbd0 on uhub2 Mar 23 07:48:35 stargate kernel: ukbd0: on usbus1 Mar 23 07:48:35 stargate kernel: kbd1 at ukbd0 Mar 23 07:48:35 stargate kernel: ums0 on uhub2 Mar 23 07:48:35 stargate kernel: ums0: on usbus1 Mar 23 07:48:35 stargate kernel: ums0: 16 buttons and [XYZT] coordinates ID=2 Mar 23 07:48:35 stargate kernel: uhid0 on uhub2 Mar 23 07:48:35 stargate kernel: uhid0: on usbus1 Mar 23 07:48:35 stargate kernel: ugen1.5: at usbus1 Mar 23 07:48:35 stargate kernel: ums1 on uhub2 Mar 23 07:48:35 stargate kernel: ums1: on usbus1 Mar 23 07:48:35 stargate kernel: ums1: 3 buttons and [XYZ] coordinates ID=0 Mar 23 07:48:35 stargate kernel: ukbd1 on uhub2 Mar 23 07:48:35 stargate kernel: ukbd1: on usbus1 Mar 23 07:48:35 stargate kernel: kbd2 at ukbd1 Mar 23 07:48:35 stargate kernel: uhid1 on uhub2 Mar 23 07:48:35 stargate kernel: uhid1: on usbus1 Mar 23 07:48:36 stargate kernel: ugen1.6: at usbus1 Mar 23 07:49:26 stargate kernel: igc0: link state changed to UP Mar 23 07:51:28 stargate shutdown[2287]: reboot by root: From nobody Wed Mar 23 21:44:34 2022 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 13FA81A3B6C3 for ; Wed, 23 Mar 2022 21:44: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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KP2274QGKz4sPx for ; Wed, 23 Mar 2022 21:44:47 +0000 (UTC) (envelope-from 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 22NLiZcX012375 for ; Wed, 23 Mar 2022 14:44:41 -0700 (PDT) (envelope-from bsd-lists@bsdforge.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 Date: Wed, 23 Mar 2022 14:44:34 -0700 From: Chris To: freebsd-current Subject: Is the graphics on AMD A8-7410 APU (Radeon R5 Graphics) supported? User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_265b0497ffddb5f29c118159ca29428e" X-Rspamd-Queue-Id: 4KP2274QGKz4sPx X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_265b0497ffddb5f29c118159ca29428e Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On a releng/13 install. I've installed the drm-kmod and loaded both the amdgpu and the radeonkms (at different times). I also installed the xf86-ati driver. But X isn't happy with it. This is in a laptop with the A8-7410. It claims Radeon R5 (formerly Carrizo). I find no mention of it in the on the FBSD Graphics wiki, or any of the links from there. Has anyone set one of these up sucessfully? Is it even possible? If so, what must I do? Thank you for all your time, and consideration. --Chris --=_265b0497ffddb5f29c118159ca29428e Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_265b0497ffddb5f29c118159ca29428e-- From nobody Wed Mar 23 21:57:05 2022 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 DF2D61A3F0A3 for ; Wed, 23 Mar 2022 21:57:15 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KP2JV49J1z4vTd for ; Wed, 23 Mar 2022 21:57:14 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1648072627; 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=859KQ8zXafrfMFmnNwrq0cLSlcTRRDHyhxnua+6pAh4=; b=Rx8EPrN+6oSIi1q1X2BluhPiWlQpqSZHgxFUE0DZSJ93/6RLvzpzxurFVOtkkhNqSl/GqZ NmVrmVGrskMTWTFkiAyFI4gAjkayDzccxwHVfpKj5tCJ68mpoHtg3G61hrwWaIjDM8hpni RK+s3AEB9Y/TeZRKYWNnc5hGdYM9yho= Received: from [192.168.1.160] (cpe-24-24-163-126.socal.res.rr.com [24.24.163.126]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 54a53538 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 23 Mar 2022 21:57:06 +0000 (UTC) Message-ID: <6fa47a27-7bb9-2806-f49d-ee548a10d169@nomadlogic.org> Date: Wed, 23 Mar 2022 14:57:05 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: Is the graphics on AMD A8-7410 APU (Radeon R5 Graphics) supported? Content-Language: en-US To: Chris , freebsd-current References: From: Pete Wright In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KP2JV49J1z4vTd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=Rx8EPrN+; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-2.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/23/22 14:44, Chris wrote: > On a releng/13 install. I've installed the drm-kmod and loaded both > the amdgpu > and the radeonkms (at different times). I also installed the xf86-ati > driver. > But X isn't happy with it. This is in a laptop with the A8-7410. It > claims > Radeon R5 (formerly Carrizo). I find no mention of it in the on the > FBSD Graphics > wiki, or any of the links from there. Has anyone set one of these up > sucessfully? > Is it even possible? If so, what must I do? hey chris - what happens when you load the amdgpu driver via rc.conf?  does it load correctly, or does the system crash on boot? for example what does "dmesg | grep drm" look like? assuming it does load successfully i think you are using the wrong xorg driver as the xf86-ati driver is ATI not amd devices.  Does loading xf86-video-amdgpu work better? cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Wed Mar 23 22:09:35 2022 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 D1E7E1A226A6 for ; Wed, 23 Mar 2022 22:09:44 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KP2Zw4dfxz3DWp for ; Wed, 23 Mar 2022 22:09:44 +0000 (UTC) (envelope-from 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 22NM9a2c056453; Wed, 23 Mar 2022 15:09:42 -0700 (PDT) (envelope-from bsd-lists@bsdforge.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 Date: Wed, 23 Mar 2022 15:09:35 -0700 From: Chris To: Pete Wright Cc: freebsd-current Subject: Re: Is the graphics on AMD A8-7410 APU (Radeon R5 Graphics) supported? In-Reply-To: <6fa47a27-7bb9-2806-f49d-ee548a10d169@nomadlogic.org> References: <6fa47a27-7bb9-2806-f49d-ee548a10d169@nomadlogic.org> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_59b3ba671be79c0df0fdee78620a70cd" X-Rspamd-Queue-Id: 4KP2Zw4dfxz3DWp X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_59b3ba671be79c0df0fdee78620a70cd Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-03-23 14:57, Pete Wright wrote: > On 3/23/22 14:44, Chris wrote: >> On a releng/13 install. I've installed the drm-kmod and loaded both the >> amdgpu >> and the radeonkms (at different times). I also installed the xf86-ati >> driver. >> But X isn't happy with it. This is in a laptop with the A8-7410. It claims >> Radeon R5 (formerly Carrizo). I find no mention of it in the on the FBSD >> Graphics >> wiki, or any of the links from there. Has anyone set one of these up >> sucessfully? >> Is it even possible? If so, what must I do? > > hey chris - what happens when you load the amdgpu driver via rc.conf?  does > it > load correctly, or does the system crash on boot? for example what does > "dmesg | > grep drm" look like? Hey pete, thanks for the prompt reply! It "flashes" but the resolution doesn't appear to change. It's booting UEFI, if that should matter. grep(1) output attached. It's a bit long to paste inline. > > assuming it does load successfully i think you are using the wrong xorg > driver as > the xf86-ati driver is ATI not amd devices.  Does loading xf86-video-amdgpu > work > better? You're probably right. I'll give that a try. Thanks again! :-) > > cheers, > -pete --Chris --=_59b3ba671be79c0df0fdee78620a70cd Content-Transfer-Encoding: base64 Content-Type: text/plain; name=DRM-OUT Content-Disposition: attachment; filename=DRM-OUT; size=7231 W2RybV0gcmFkZW9uIGtlcm5lbCBtb2Rlc2V0dGluZyBlbmFibGVkLgpkcm1uMDogPGRybW4+IG9u IHZnYXBjaTAKdmdhcGNpMDogY2hpbGQgZHJtbjAgcmVxdWVzdGVkIHBjaV9lbmFibGVfaW8Kdmdh cGNpMDogY2hpbGQgZHJtbjAgcmVxdWVzdGVkIHBjaV9lbmFibGVfaW8KW2RybV0gaW5pdGlhbGl6 aW5nIGtlcm5lbCBtb2Rlc2V0dGluZyAoTVVMTElOUyAweDEwMDI6MHg5ODUxIDB4MTAyODoweDA2 QkYgMHg0NSkuCltkcm1dIGRvb3JiZWxsIG1taW8gYmFzZTogMHhGMDAwMDAwMApbZHJtXSBkb29y YmVsbCBtbWlvIHNpemU6IDgzODg2MDgKW2RybSBFUlJPUiA6cmFkZW9uX2F0b21iaW9zX2luaXRd IFVuYWJsZSB0byBmaW5kIFBDSSBJL08gQkFSOyB1c2luZyBNTUlPIGZvciBBVE9NIElJTwpkcm1u MDogVlJBTTogMTAyNE0gMHgwMDAwMDAwMDAwMDAwMDAwIC0gMHgwMDAwMDAwMDNGRkZGRkZGICgx MDI0TSB1c2VkKQpkcm1uMDogR1RUOiAyMDQ4TSAweDAwMDAwMDAwNDAwMDAwMDAgLSAweDAwMDAw MDAwQkZGRkZGRkYKW2RybV0gRGV0ZWN0ZWQgVlJBTSBSQU09MTAyNE0sIEJBUj0yNTZNCltkcm1d IFJBTSB3aWR0aCAxMjhiaXRzIEREUgpbZHJtXSByYWRlb246IDEwMjRNIG9mIFZSQU0gbWVtb3J5 IHJlYWR5Cltkcm1dIHJhZGVvbjogMjA0OE0gb2YgR1RUIG1lbW9yeSByZWFkeS4KW2RybV0gTG9h ZGluZyBtdWxsaW5zIE1pY3JvY29kZQpkcm1uMDogc3VjY2Vzc2Z1bGx5IGxvYWRlZCBmaXJtd2Fy ZSBpbWFnZSAncmFkZW9uL211bGxpbnNfcGZwLmJpbicKZHJtbjA6IHN1Y2Nlc3NmdWxseSBsb2Fk ZWQgZmlybXdhcmUgaW1hZ2UgJ3JhZGVvbi9tdWxsaW5zX21lLmJpbicKZHJtbjA6IHN1Y2Nlc3Nm dWxseSBsb2FkZWQgZmlybXdhcmUgaW1hZ2UgJ3JhZGVvbi9tdWxsaW5zX2NlLmJpbicKZHJtbjA6 IHN1Y2Nlc3NmdWxseSBsb2FkZWQgZmlybXdhcmUgaW1hZ2UgJ3JhZGVvbi9tdWxsaW5zX21lYy5i aW4nCmRybW4wOiBzdWNjZXNzZnVsbHkgbG9hZGVkIGZpcm13YXJlIGltYWdlICdyYWRlb24vbXVs bGluc19ybGMuYmluJwpkcm1uMDogc3VjY2Vzc2Z1bGx5IGxvYWRlZCBmaXJtd2FyZSBpbWFnZSAn cmFkZW9uL211bGxpbnNfc2RtYS5iaW4nCltkcm1dIEludGVybmFsIHRoZXJtYWwgY29udHJvbGxl ciB3aXRob3V0IGZhbiBjb250cm9sCltkcm1dIHJhZGVvbjogZHBtIGluaXRpYWxpemVkCmRybW4w OiBzdWNjZXNzZnVsbHkgbG9hZGVkIGZpcm13YXJlIGltYWdlICdyYWRlb24vYm9uYWlyZV91dmQu YmluJwpbZHJtXSBGb3VuZCBVVkQgZmlybXdhcmUgVmVyc2lvbjogMS42NCBGYW1pbHkgSUQ6IDkK ZHJtbjA6IHN1Y2Nlc3NmdWxseSBsb2FkZWQgZmlybXdhcmUgaW1hZ2UgJ3JhZGVvbi9CT05BSVJF X3ZjZS5iaW4nCltkcm1dIEZvdW5kIFZDRSBmaXJtd2FyZS9mZWVkYmFjayB2ZXJzaW9uIDQwLjIu MiAvIDE1IQpbZHJtXSBHQVJUOiBudW0gY3B1IHBhZ2VzIDUyNDI4OCwgbnVtIGdwdSBwYWdlcyA1 MjQyODgKW2RybV0gUENJRSBHQVJUIG9mIDIwNDhNIGVuYWJsZWQgKHRhYmxlIGF0IDB4MDAwMDAw MDAwMDMwRTAwMCkuCmRybW4wOiBXQiBlbmFibGVkCmRybW4wOiBmZW5jZSBkcml2ZXIgb24gcmlu ZyAwIHVzZSBncHUgYWRkciAweDAwMDAwMDAwNDAwMDBjMDAgYW5kIGNwdSBhZGRyIDB4MHhmZmZm ZjgwMDA3OWYxYzAwCmRybW4wOiBmZW5jZSBkcml2ZXIgb24gcmluZyAxIHVzZSBncHUgYWRkciAw eDAwMDAwMDAwNDAwMDBjMDQgYW5kIGNwdSBhZGRyIDB4MHhmZmZmZjgwMDA3OWYxYzA0CmRybW4w OiBmZW5jZSBkcml2ZXIgb24gcmluZyAyIHVzZSBncHUgYWRkciAweDAwMDAwMDAwNDAwMDBjMDgg YW5kIGNwdSBhZGRyIDB4MHhmZmZmZjgwMDA3OWYxYzA4CmRybW4wOiBmZW5jZSBkcml2ZXIgb24g cmluZyAzIHVzZSBncHUgYWRkciAweDAwMDAwMDAwNDAwMDBjMGMgYW5kIGNwdSBhZGRyIDB4MHhm ZmZmZjgwMDA3OWYxYzBjCmRybW4wOiBmZW5jZSBkcml2ZXIgb24gcmluZyA0IHVzZSBncHUgYWRk ciAweDAwMDAwMDAwNDAwMDBjMTAgYW5kIGNwdSBhZGRyIDB4MHhmZmZmZjgwMDA3OWYxYzEwCmRy bW4wOiBmZW5jZSBkcml2ZXIgb24gcmluZyA1IHVzZSBncHUgYWRkciAweDAwMDAwMDAwMDAwNzhk MzAgYW5kIGNwdSBhZGRyIDB4MHhmZmZmZjgwMGUwMDc4ZDMwCmRybW4wOiBmZW5jZSBkcml2ZXIg b24gcmluZyA2IHVzZSBncHUgYWRkciAweDAwMDAwMDAwNDAwMDBjMTggYW5kIGNwdSBhZGRyIDB4 MHhmZmZmZjgwMDA3OWYxYzE4CmRybW4wOiBmZW5jZSBkcml2ZXIgb24gcmluZyA3IHVzZSBncHUg YWRkciAweDAwMDAwMDAwNDAwMDBjMWMgYW5kIGNwdSBhZGRyIDB4MHhmZmZmZjgwMDA3OWYxYzFj Cltkcm1dIFN1cHBvcnRzIHZibGFuayB0aW1lc3RhbXAgY2FjaGluZyBSZXYgMiAoMjEuMTAuMjAx MykuCltkcm1dIERyaXZlciBzdXBwb3J0cyBwcmVjaXNlIHZibGFuayB0aW1lc3RhbXAgcXVlcnku CmRybW4wOiByYWRlb246IHVzaW5nIE1TSS4KW2RybV0gcmFkZW9uOiBpcnEgaW5pdGlhbGl6ZWQu Cltkcm1dIHJpbmcgdGVzdCBvbiAwIHN1Y2NlZWRlZCBpbiAzIHVzZWNzCltkcm1dIHJpbmcgdGVz dCBvbiAxIHN1Y2NlZWRlZCBpbiAyIHVzZWNzCltkcm1dIHJpbmcgdGVzdCBvbiAyIHN1Y2NlZWRl ZCBpbiAyIHVzZWNzCltkcm1dIHJpbmcgdGVzdCBvbiAzIHN1Y2NlZWRlZCBpbiA0IHVzZWNzCltk cm1dIHJpbmcgdGVzdCBvbiA0IHN1Y2NlZWRlZCBpbiA0IHVzZWNzCltkcm1dIHJpbmcgdGVzdCBv biA1IHN1Y2NlZWRlZCBpbiAyIHVzZWNzCltkcm1dIFVWRCBpbml0aWFsaXplZCBzdWNjZXNzZnVs bHkuCltkcm1dIHJpbmcgdGVzdCBvbiA2IHN1Y2NlZWRlZCBpbiAyMCB1c2VjcwpbZHJtXSByaW5n IHRlc3Qgb24gNyBzdWNjZWVkZWQgaW4gMiB1c2VjcwpbZHJtXSBWQ0UgaW5pdGlhbGl6ZWQgc3Vj Y2Vzc2Z1bGx5LgpbZHJtXSBpYiB0ZXN0IG9uIHJpbmcgMCBzdWNjZWVkZWQgaW4gMCB1c2Vjcwpb ZHJtXSBpYiB0ZXN0IG9uIHJpbmcgMSBzdWNjZWVkZWQgaW4gMCB1c2VjcwpbZHJtXSBpYiB0ZXN0 IG9uIHJpbmcgMiBzdWNjZWVkZWQgaW4gMCB1c2VjcwpbZHJtXSBpYiB0ZXN0IG9uIHJpbmcgMyBz dWNjZWVkZWQgaW4gMCB1c2VjcwpbZHJtXSBpYiB0ZXN0IG9uIHJpbmcgNCBzdWNjZWVkZWQgaW4g MCB1c2VjcwpbZHJtXSBpYiB0ZXN0IG9uIHJpbmcgNSBzdWNjZWVkZWQKW2RybV0gaWIgdGVzdCBv biByaW5nIDYgc3VjY2VlZGVkCltkcm1dIGliIHRlc3Qgb24gcmluZyA3IHN1Y2NlZWRlZApbZHJt XSBDb25uZWN0b3IgZURQLTE6IGdldCBtb2RlIGZyb20gdHVuYWJsZXM6Cltkcm1dICAgLSBrZXJu LnZ0LmZiLm1vZGVzLmVEUC0xCltkcm1dICAgLSBrZXJuLnZ0LmZiLmRlZmF1bHRfbW9kZQpbZHJt XSBDb25uZWN0b3IgSERNSS1BLTE6IGdldCBtb2RlIGZyb20gdHVuYWJsZXM6Cltkcm1dICAgLSBr ZXJuLnZ0LmZiLm1vZGVzLkhETUktQS0xCltkcm1dICAgLSBrZXJuLnZ0LmZiLmRlZmF1bHRfbW9k ZQpbZHJtXSByYWRlb24gYXRvbSBESUcgYmFja2xpZ2h0IGluaXRpYWxpemVkCltkcm1dIFJhZGVv biBEaXNwbGF5IENvbm5lY3RvcnMKW2RybV0gQ29ubmVjdG9yIDA6Cltkcm1dICAgZURQLTEKW2Ry bV0gICBIUEQxCltkcm1dICAgRERDOiAweDY1MzAgMHg2NTMwIDB4NjUzNCAweDY1MzQgMHg2NTM4 IDB4NjUzOCAweDY1M2MgMHg2NTNjCltkcm1dICAgRW5jb2RlcnM6Cltkcm1dICAgICBMQ0QxOiBJ TlRFUk5BTF9VTklQSFkKW2RybV0gQ29ubmVjdG9yIDE6Cltkcm1dICAgSERNSS1BLTEKW2RybV0g ICBIUEQyCltkcm1dICAgRERDOiAweDY1NDAgMHg2NTQwIDB4NjU0NCAweDY1NDQgMHg2NTQ4IDB4 NjU0OCAweDY1NGMgMHg2NTRjCltkcm1dICAgRW5jb2RlcnM6Cltkcm1dICAgICBERlAxOiBJTlRF Uk5BTF9VTklQSFkKW2RybV0gZmIgbWFwcGFibGUgYXQgMHhFMDczMTAwMApbZHJtXSB2cmFtIGFw cGVyIGF0IDB4RTAwMDAwMDAKW2RybV0gc2l6ZSA1Nzg3NjQ4Cltkcm1dIGZiIGRlcHRoIGlzIDI0 Cltkcm1dICAgIHBpdGNoIGlzIDY0MDAKbmFtZT1kcm1uMCBmbGFncz0weDAgc3RyaWRlPTY0MDAg YnBwPTMyCmRybW4wOiBmYjA6IHJhZGVvbmRybWZiIGZyYW1lIGJ1ZmZlciBkZXZpY2UKW2RybV0g SW5pdGlhbGl6ZWQgcmFkZW9uIDIuNTAuMCAyMDA4MDUyOCBmb3IgZHJtbjAgb24gbWlub3IgMApb ZHJtXSBhbWRncHUga2VybmVsIG1vZGVzZXR0aW5nIGVuYWJsZWQuCmRybW4wOiA8ZHJtbj4gb24g dmdhcGNpMAp2Z2FwY2kwOiBjaGlsZCBkcm1uMCByZXF1ZXN0ZWQgcGNpX2VuYWJsZV9pbwp2Z2Fw Y2kwOiBjaGlsZCBkcm1uMCByZXF1ZXN0ZWQgcGNpX2VuYWJsZV9pbwpbZHJtXSBpbml0aWFsaXpp bmcga2VybmVsIG1vZGVzZXR0aW5nIChNVUxMSU5TIDB4MTAwMjoweDk4NTEgMHgxMDI4OjB4MDZC RiAweDQ1KS4KW2RybV0gcmVnaXN0ZXIgbW1pbyBiYXNlOiAweEZFQjAwMDAwCltkcm1dIHJlZ2lz dGVyIG1taW8gc2l6ZTogMjYyMTQ0Cltkcm1dIGFkZCBpcCBibG9jayBudW1iZXIgMCA8Y2lrX2Nv bW1vbj4KW2RybV0gYWRkIGlwIGJsb2NrIG51bWJlciAxIDxnbWNfdjdfMD4KW2RybV0gYWRkIGlw IGJsb2NrIG51bWJlciAyIDxjaWtfaWg+Cltkcm1dIGFkZCBpcCBibG9jayBudW1iZXIgMyA8Z2Z4 X3Y3XzA+Cltkcm1dIGFkZCBpcCBibG9jayBudW1iZXIgNCA8Y2lrX3NkbWE+Cltkcm1dIGFkZCBp cCBibG9jayBudW1iZXIgNSA8a3ZfZHBtPgpbZHJtXSBhZGQgaXAgYmxvY2sgbnVtYmVyIDYgPGRj ZV92OF8wPgpbZHJtXSBhZGQgaXAgYmxvY2sgbnVtYmVyIDcgPHV2ZF92NF8yPgpbZHJtXSBhZGQg aXAgYmxvY2sgbnVtYmVyIDggPHZjZV92Ml8wPgpkcm1uMDoga2ZkIG5vdCBzdXBwb3J0ZWQgb24g dGhpcyBBU0lDCltkcm1dIHZtIHNpemUgaXMgNjQgR0IsIDIgbGV2ZWxzLCBibG9jayBzaXplIGlz IDEwLWJpdCwgZnJhZ21lbnQgc2l6ZSBpcyA5LWJpdApkcm1uMDogVlJBTTogMTAyNE0gMHgwMDAw MDBGNDAwMDAwMDAwIC0gMHgwMDAwMDBGNDNGRkZGRkZGICgxMDI0TSB1c2VkKQpkcm1uMDogR0FS VDogMTAyNE0gMHgwMDAwMDBGRjAwMDAwMDAwIC0gMHgwMDAwMDBGRjNGRkZGRkZGCltkcm1dIERl dGVjdGVkIFZSQU0gUkFNPTEwMjRNLCBCQVI9MjU2TQpbZHJtXSBSQU0gd2lkdGggNjRiaXRzIFVO S05PV04KW2RybV0gYW1kZ3B1OiAxMDI0TSBvZiBWUkFNIG1lbW9yeSByZWFkeQpbZHJtXSBhbWRn cHU6IDMwNzJNIG9mIEdUVCBtZW1vcnkgcmVhZHkuCltkcm1dIEdBUlQ6IG51bSBjcHUgcGFnZXMg MjYyMTQ0LCBudW0gZ3B1IHBhZ2VzIDI2MjE0NApbZHJtXSBQQ0lFIEdBUlQgb2YgMTAyNE0gZW5h YmxlZCAodGFibGUgYXQgMHgwMDAwMDBGNDAwNTdGMDAwKS4KW2RybV0gU3VwcG9ydHMgdmJsYW5r IHRpbWVzdGFtcCBjYWNoaW5nIFJldiAyICgyMS4xMC4yMDEzKS4KW2RybV0gRHJpdmVyIHN1cHBv cnRzIHByZWNpc2UgdmJsYW5rIHRpbWVzdGFtcCBxdWVyeS4KZHJtbjA6IHN1Y2Nlc3NmdWxseSBs b2FkZWQgZmlybXdhcmUgaW1hZ2UgJ2FtZGdwdS9tdWxsaW5zX3BmcC5iaW4nCmRybW4wOiBzdWNj ZXNzZnVsbHkgbG9hZGVkIGZpcm13YXJlIGltYWdlICdhbWRncHUvbXVsbGluc19tZS5iaW4nCmRy bW4wOiBzdWNjZXNzZnVsbHkgbG9hZGVkIGZpcm13YXJlIGltYWdlICdhbWRncHUvbXVsbGluc19j ZS5iaW4nCmRybW4wOiBzdWNjZXNzZnVsbHkgbG9hZGVkIGZpcm13YXJlIGltYWdlICdhbWRncHUv bXVsbGluc19tZWMuYmluJwpkcm1uMDogc3VjY2Vzc2Z1bGx5IGxvYWRlZCBmaXJtd2FyZSBpbWFn ZSAnYW1kZ3B1L211bGxpbnNfcmxjLmJpbicKZHJtbjA6IHN1Y2Nlc3NmdWxseSBsb2FkZWQgZmly bXdhcmUgaW1hZ2UgJ2FtZGdwdS9tdWxsaW5zX3NkbWEuYmluJwpkcm1uMDogc3VjY2Vzc2Z1bGx5 IGxvYWRlZCBmaXJtd2FyZSBpbWFnZSAnYW1kZ3B1L211bGxpbnNfc2RtYTEuYmluJwpbZHJtXSBJ bnRlcm5hbCB0aGVybWFsIGNvbnRyb2xsZXIgd2l0aG91dCBmYW4gY29udHJvbApbZHJtXSBhbWRn cHU6IGRwbSBpbml0aWFsaXplZApbZHJtXSBDb25uZWN0b3IgZURQLTE6IGdldCBtb2RlIGZyb20g dHVuYWJsZXM6Cltkcm1dICAgLSBrZXJuLnZ0LmZiLm1vZGVzLmVEUC0xCltkcm1dICAgLSBrZXJu LnZ0LmZiLmRlZmF1bHRfbW9kZQpbZHJtXSBDb25uZWN0b3IgSERNSS1BLTE6IGdldCBtb2RlIGZy b20gdHVuYWJsZXM6Cltkcm1dICAgLSBrZXJuLnZ0LmZiLm1vZGVzLkhETUktQS0xCltkcm1dICAg LSBrZXJuLnZ0LmZiLmRlZmF1bHRfbW9kZQpbZHJtXSBhbWRncHUgYXRvbSBESUcgYmFja2xpZ2h0 IGluaXRpYWxpemVkCltkcm1dIEFNREdQVSBEaXNwbGF5IENvbm5lY3RvcnMKW2RybV0gQ29ubmVj dG9yIDA6Cltkcm1dICAgZURQLTEKW2RybV0gICBIUEQxCltkcm1dICAgRERDOiAweDE5NGMgMHgx OTRjIDB4MTk0ZCAweDE5NGQgMHgxOTRlIDB4MTk0ZSAweDE5NGYgMHgxOTRmCltkcm1dICAgRW5j b2RlcnM6Cltkcm1dICAgICBMQ0QxOiBJTlRFUk5BTF9VTklQSFkKW2RybV0gQ29ubmVjdG9yIDE6 Cltkcm1dICAgSERNSS1BLTEKW2RybV0gICBIUEQyCltkcm1dICAgRERDOiAweDE5NTAgMHgxOTUw IDB4MTk1MSAweDE5NTEgMHgxOTUyIDB4MTk1MiAweDE5NTMgMHgxOTUzCltkcm1dICAgRW5jb2Rl cnM6Cltkcm1dICAgICBERlAxOiBJTlRFUk5BTF9VTklQSFkKZHJtbjA6IHN1Y2Nlc3NmdWxseSBs b2FkZWQgZmlybXdhcmUgaW1hZ2UgJ2FtZGdwdS9tdWxsaW5zX3V2ZC5iaW4nCltkcm1dIEZvdW5k IFVWRCBmaXJtd2FyZSBWZXJzaW9uOiAxLjY0IEZhbWlseSBJRDogOQpkcm1uMDogc3VjY2Vzc2Z1 bGx5IGxvYWRlZCBmaXJtd2FyZSBpbWFnZSAnYW1kZ3B1L211bGxpbnNfdmNlLmJpbicKW2RybV0g Rm91bmQgVkNFIGZpcm13YXJlIFZlcnNpb246IDUwLjEwIEJpbmFyeSBJRDogMgpbZHJtXSBVVkQg aW5pdGlhbGl6ZWQgc3VjY2Vzc2Z1bGx5LgpbZHJtXSBWQ0UgaW5pdGlhbGl6ZWQgc3VjY2Vzc2Z1 bGx5LgpbZHJtXSBmYiBtYXBwYWJsZSBhdCAweEUwOTZCMDAwCltkcm1dIHZyYW0gYXBwZXIgYXQg MHhFMDAwMDAwMApbZHJtXSBzaXplIDU3ODc2NDgKW2RybV0gZmIgZGVwdGggaXMgMjQKW2RybV0g ICAgcGl0Y2ggaXMgNjQwMApuYW1lPWRybW4wIGZsYWdzPTB4MCBzdHJpZGU9NjQwMCBicHA9MzIK ZHJtbjA6IGZiMDogYW1kZ3B1ZHJtZmIgZnJhbWUgYnVmZmVyIGRldmljZQpbZHJtXSBJbml0aWFs aXplZCBhbWRncHUgMy4zNS4wIDIwMTUwMTAxIGZvciBkcm1uMCBvbiBtaW5vciAwCg== --=_59b3ba671be79c0df0fdee78620a70cd Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_59b3ba671be79c0df0fdee78620a70cd-- From nobody Wed Mar 23 22:45:23 2022 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 5FCDF1A2BBB0 for ; Wed, 23 Mar 2022 22:45:26 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KP3N54BB9z3LR1 for ; Wed, 23 Mar 2022 22:45:25 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1648075524; 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=S4B9Hybk/LKzjRbJs/Dl8i41D9m4us2Bh17Wk5do9w0=; b=WmS4h+ZUptirG2WdgairFfsbRQvoaaPVt1T2v6r1WOGngaYbvvh5d61dqO4xFmeUpRVMg6 ruMaYF+rBhNV6jjFG/OYoKxQaOeIxaKku0mt6/9jBC3xmE3V+KNtQe8GphcltyU4tL8Oq+ cES/l2InTyx0ZzyMaOuuE6ypBOHRgrw= Received: from [192.168.1.160] (cpe-24-24-163-126.socal.res.rr.com [24.24.163.126]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 1659117e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 23 Mar 2022 22:45:24 +0000 (UTC) Message-ID: <7b07983a-1d89-40df-750f-d9fb8762d8d1@nomadlogic.org> Date: Wed, 23 Mar 2022 15:45:23 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: Is the graphics on AMD A8-7410 APU (Radeon R5 Graphics) supported? Content-Language: en-US To: Chris Cc: freebsd-current References: <6fa47a27-7bb9-2806-f49d-ee548a10d169@nomadlogic.org> From: Pete Wright In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KP3N54BB9z3LR1 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=WmS4h+ZU; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-0.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.98)[0.979]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; NEURAL_HAM_SHORT(-0.46)[-0.461]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/23/22 15:09, Chris wrote: > On 2022-03-23 14:57, Pete Wright wrote: >> On 3/23/22 14:44, Chris wrote: >>> On a releng/13 install. I've installed the drm-kmod and loaded both >>> the amdgpu >>> and the radeonkms (at different times). I also installed the >>> xf86-ati driver. >>> But X isn't happy with it. This is in a laptop with the A8-7410. It >>> claims >>> Radeon R5 (formerly Carrizo). I find no mention of it in the on the >>> FBSD Graphics >>> wiki, or any of the links from there. Has anyone set one of these up >>> sucessfully? >>> Is it even possible? If so, what must I do? >> >> hey chris - what happens when you load the amdgpu driver via >> rc.conf?  does it >> load correctly, or does the system crash on boot? for example what >> does "dmesg | >> grep drm" look like? > Hey pete, thanks for the prompt reply! > It "flashes" but the resolution doesn't appear to change. It's booting > UEFI, if that > should matter. grep(1) output attached. It's a bit long to paste inline. >> >> assuming it does load successfully i think you are using the wrong >> xorg driver as >> the xf86-ati driver is ATI not amd devices.  Does loading >> xf86-video-amdgpu work >> better? > You're probably right. I'll give that a try. > > Thanks again! :-) no worries!  i took a peek at your dmesg and i think once you install the amdgpu xorg driver you'll be good to go.  the screen flash is just the display cutting over to the new driver and is expected. looks like it detected both of your displays too so you window manager should pick them up too.  a bunch of work was done recently to make xorg load up correctly without any configuration files - so you shouldn't even need to setup an xorg.conf or anything like that :) have fun! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Fri Mar 25 12:18:40 2022 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 EF2C01A3AACA for ; Fri, 25 Mar 2022 12:18:53 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ1ND5XRxz4nH0; Fri, 25 Mar 2022 12:18:52 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-ej1-x632.google.com with SMTP id bg10so15005300ejb.4; Fri, 25 Mar 2022 05:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=cROKKZaxvG7Etne02m3DxOq1Lv8T+e7avzldvHLAL9s=; b=dXJPYYJqB9ItsVjfjVG4o5ff5nL6sDvbZUXB7T514AtXJmUrTrshZ7QtCYvKNKDpNi qbOxFPpD9bu9E42mzMPZ/XM33KD2ZEu3Y4IKakg+66bS4OxsQ79YLdHSopl2T7N217u4 iU9RO0mhNgTe2DBs3xgZN3aNDRyLT/9Sha1+IhPdp3yQWdnaJMcUtIk2jRwIvruWarmv SRH0Rep9/lumxqoIQjVbrASq/MoYXPN5UTEgnp9ubsjhMC6U4S1YZzp40ewb4tXZ8ihk HepB6B84y6Jc5vS2hqMp+dXHiyA4yqauXG1XYBc9LO32CRihPMweq23PUoPVXBbldx/+ K5+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cROKKZaxvG7Etne02m3DxOq1Lv8T+e7avzldvHLAL9s=; b=yLxq6l9tkav2b/KHgvA6d0gh33kHm67CfOt+OU05iyc52wT4jKJXJ5e2tCak8iL7gn Vzmkg2S/AEBMEjEY6fu0MMfxvfakdkcDRKMcI01GDWMg0XV0PLU0L9wbqUHWG2hTs45D iuJXdmK4goWP+cJ5SWURFff6vJ27HxqpuK/PoPfHwC/St9Z34fUQwEZZel92XG1AIq4C RqjOPIJ4wWdfSATL09J3Le7GKXxoPHsKvcm/V+PQA4dvDCQ6yT02v0Wu9PlKwlFPQJGH CjOITJhw+3q0+1I3Ft08HgF6lPKOqcrvQ/BZ/CV92pRULcvs/JfHpilm+t6+mh0LY44b PA3A== X-Gm-Message-State: AOAM531ksZewRFmkiLTI3P4tZMZExMCukM+VXzlqLWGYJk8ow52ScLLT Xv+i5YexwqjKTvxkzARvwI/rBclg0rxAqlcgO1CrWY1QOp0= X-Google-Smtp-Source: ABdhPJyDVBIAV6MHMJ8jrqA1mVgpt5o/Jai7nmeGyrUvXQo3G02FqVN4QzfHrHOIxzyUq79zIKOnRdJd8JhMg/IyOXs= X-Received: by 2002:a17:907:72c3:b0:6df:91a4:32f4 with SMTP id du3-20020a17090772c300b006df91a432f4mr11244315ejc.638.1648210731493; Fri, 25 Mar 2022 05:18:51 -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: Guy Yur Date: Fri, 25 Mar 2022 15:18:40 +0300 Message-ID: Subject: Interrupted fputc followed by fprintf in _IOLBF mode causes core dump To: freebsd-current , Konstantin Belousov , Mark Johnston Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KQ1ND5XRxz4nH0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=dXJPYYJq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of guyyur@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=guyyur@gmail.com X-Spamd-Result: default: False [-3.21 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.25)[-0.248]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.995]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::632:from]; NEURAL_HAM_SHORT(-0.97)[-0.968]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Hi, dhcpcd on head (Mar 24) and 13.1-BETA2 crashes in fprintf/__sfvwrite. It doesn't crash if If I revert the __sflush/__sfvwrite commits: 86a16ada1ea608408cec370171d9f59353e97c77 and bafaa70b6f9098d83d074968c8e6747ecec1e118. Stack trace: 0 memcpy () at /usr/src/lib/libc/amd64/string/memmove.S:314 #1 0x00000008221c300a in __sfvwrite (fp=, uio=0x8207ad338) at /usr/src/lib/libc/stdio/fvwrite.c:182 #2 0x00000008221cc631 in __sprint (fp=0x26fffe, uio=0x8207ad2d7, locale=) at /usr/src/lib/libc/stdio/vfprintf.c:166 #3 io_flush (iop=0x8207ad330, locale=) at /usr/src/lib/libc/stdio/printfcommon.h:157 #4 __vfprintf (fp=fp@entry=0x8222892d0, locale=locale@entry=0x822288ab8 <__xlocale_global_locale>, fmt0=, fmt0@entry=0x204182 "%s", ap=, ap@entry=0x8207ad4e0) at /usr/src/lib/libc/stdio/vfprintf.c:1033 #5 0x00000008221c8aea in vfprintf_l (fp=0x8222892d0, locale=0x822288ab8 <__xlocale_global_locale>, fmt0=0x204182 "%s", ap=0x8207ad4e0) at /usr/src/lib/libc/stdio/vfprintf.c:285 #6 0x0000000000222efa in vlogprintf_r (ctx=0x270820 <_logctx>, stream=0x8222892d0, fmt=0x204182 "%s", args=0x8207adad0) at logerr.c:186 ... (gdb) frame 5 #5 0x00000008221c8aea in vfprintf_l (fp=0x8222892d0, locale=0x822288ab8 <__xlocale_global_locale>, fmt0=0x204182 "%s", ap=0x8207ad4e0) at /usr/src/lib/libc/stdio/vfprintf.c:285 285 ret = __vfprintf(fp, locale, fmt0, ap); (gdb) p *fp $1 = {_p = 0x27084f <_logctx+47> "e21:3e7c\n42a/64\n", _r = 0, _w = -1025, _flags = 2057, _file = 2, _bf = {_base = 0x270820 <_logctx> "*\"", _size = 1024}, _lbfsize = -1024, _cookie = 0x8222892d0, _close = 0x8221c7b40 <__sclose>, _read = 0x8221c7af0 <__sread>, _seek = 0x8221c7b30 <__sseek>, _write = 0x8221c7b10 <__swrite>, _ub = {_base = 0x0, _size = 0}, _up = 0x0, _ur = 0, _ubuf = "\000\000", _nbuf = "", _lb = {_base = 0x0, _size = 0}, _blksize = 4096, _offset = 0, _fl_mutex = 0x0, _fl_owner = 0x0, _fl_count = 0, _orientation = -1, _mbstate = {__mbstate8 = '\000' , _mbstateL = 0}, _flags2 = 0} (gdb) frame 1 #1 0x00000008221c300a in __sfvwrite (fp=, uio=0x8207ad338) at /usr/src/lib/libc/stdio/fvwrite.c:182 182 COPY(w); (gdb) p w $4 = -1 The dhcpcd flow leading to the crash: 1. init with setvbuf _IOLBF on stderr https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/logerr.c#L453 2. fputc with newline called on stderr but is interrupted https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/logerr.c#L187 3. next event received, vfprintf is called on stderr and crashes https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/logerr.c#L186 Simple program that eventually crashes: #include #include #include static void alrm(int signo __unused) { alarm(1); } char buf[1024]; /* use global to not corrupt stack trace in core dump */ int main() { struct sigaction sa; sa.sa_handler = alrm; sigemptyset(&sa.sa_mask); sa.sa_flags = 0; sigaction(SIGALRM, &sa, NULL); setvbuf(stderr, buf, _IOLBF, sizeof(buf)); alarm(1); while (!ferror(stderr)) { fputc('\n', stderr); } fprintf(stderr, "%s", "a"); return 0; } Regards, Guy Yur From nobody Fri Mar 25 14:50:41 2022 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 8570F1A4DD26 for ; Fri, 25 Mar 2022 14:50:51 +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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ4lZ2x52z53VY; Fri, 25 Mar 2022 14:50:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82b.google.com with SMTP id bp39so6675938qtb.6; Fri, 25 Mar 2022 07:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=J/RyFR9n/LBVliyXAxJ9KoviBQxVf7ExEkE4PP0+SlI=; b=anywS2BgIQUS7MQHXuVwjYqGXhUJYpY201Kf3miYkWFWmqzypdH2OA8ER/q+EJ2zEf Ova8+XUQzEKeu3O5/MLoRDUZ7Y9iuoxZs6+7OZ+KRXMBr6Q7kBHECGWR5qP7rCMO85l6 A7xswYr0mUrNIXhmOE3BIc8sQxlBLy83zSSuxA9Rs1OMXcbdVppBDWCr6DCXSrt33wHT wgraoE3NYWsCOPXmE73Nebq52jBsHU7wQgez6W1a3n6PuPo91pFbaaS5dwqUsZTAMe+O 88PSjb704L25PrRecBkpMm/d60/iQ5E9NlFWz/NQlap/Xr4Gl4fi02sZ7liHSdfWpTMb DZFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=J/RyFR9n/LBVliyXAxJ9KoviBQxVf7ExEkE4PP0+SlI=; b=Vi9Xi0onSLS5PAHSkJNxHvpQdgEKFewZElYRmCnd+1M+GBITHBOAHkOq+2g22/W4zt 3agysT1cAdIdV3bHjJbt4ynkEH6iitc3hfUR786U45TybERwOOMTXkkOlWmDUKSAEdBO om9nSAidk/SANspuv55izdiypElCEbsbseQE7AxcmAdWEcHlL1/atmWWlOuutOZD/9Zm WZuDzoOFEoo2qEwJMT1KOlGl6tIE6/rUnG8A3Hgz5uqfEAo+peSwjpr7PLuxITTQU/FY muy0Ml9KR22gwiwabj648Fi6m3+3eAmOmKfuAjxhzz8fwT246gymS7BuZZuGlwpag9uw SrPg== X-Gm-Message-State: AOAM530sB4XS6ovPJFIuJPQulD4vpl+AM7Y4otCD77lTYtVVg/X1hI2V fOzECR0pKQ3qR3iQ7V6xN577ZKMz2u4cug== X-Google-Smtp-Source: ABdhPJzn6vaTjon3Nrog9mWQb5e2gxifkX8w5FEcxIjX4Bbx2nfIyCNlZ0CsfJEpjzeFUcri9Hkc+A== X-Received: by 2002:a05:622a:1315:b0:2e2:2952:11b8 with SMTP id v21-20020a05622a131500b002e2295211b8mr9649747qtk.244.1648219844505; Fri, 25 Mar 2022 07:50:44 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id p8-20020a05620a22e800b0067e75955f5esm3212083qki.77.2022.03.25.07.50.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Mar 2022 07:50:43 -0700 (PDT) Date: Fri, 25 Mar 2022 10:50:41 -0400 From: Mark Johnston To: Guy Yur Cc: freebsd-current , Konstantin Belousov Subject: Re: Interrupted fputc followed by fprintf in _IOLBF mode causes core dump Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KQ4lZ2x52z53VY X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=anywS2Bg; dmarc=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 X-Spamd-Result: default: False [-0.57 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.883]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[0.999]; NEURAL_HAM_LONG(-0.98)[-0.983]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82b:from]; MLMMJ_DEST(0.00)[freebsd-current]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Mar 25, 2022 at 03:18:40PM +0300, Guy Yur wrote: > Hi, > > dhcpcd on head (Mar 24) and 13.1-BETA2 crashes in fprintf/__sfvwrite. > It doesn't crash if If I revert the __sflush/__sfvwrite commits: > 86a16ada1ea608408cec370171d9f59353e97c77 and > bafaa70b6f9098d83d074968c8e6747ecec1e118. > > Stack trace: > 0 memcpy () at /usr/src/lib/libc/amd64/string/memmove.S:314 > #1 0x00000008221c300a in __sfvwrite (fp=, > uio=0x8207ad338) at /usr/src/lib/libc/stdio/fvwrite.c:182 > #2 0x00000008221cc631 in __sprint (fp=0x26fffe, uio=0x8207ad2d7, > locale=) at /usr/src/lib/libc/stdio/vfprintf.c:166 > #3 io_flush (iop=0x8207ad330, locale=) at > /usr/src/lib/libc/stdio/printfcommon.h:157 > #4 __vfprintf (fp=fp@entry=0x8222892d0, locale=locale@entry=0x822288ab8 > <__xlocale_global_locale>, fmt0=, fmt0@entry=0x204182 "%s", > ap=, ap@entry=0x8207ad4e0) at > /usr/src/lib/libc/stdio/vfprintf.c:1033 > #5 0x00000008221c8aea in vfprintf_l (fp=0x8222892d0, locale=0x822288ab8 > <__xlocale_global_locale>, fmt0=0x204182 "%s", ap=0x8207ad4e0) > at /usr/src/lib/libc/stdio/vfprintf.c:285 > #6 0x0000000000222efa in vlogprintf_r (ctx=0x270820 <_logctx>, > stream=0x8222892d0, fmt=0x204182 "%s", args=0x8207adad0) at logerr.c:186 > ... > > (gdb) frame 5 > #5 0x00000008221c8aea in vfprintf_l (fp=0x8222892d0, locale=0x822288ab8 > <__xlocale_global_locale>, fmt0=0x204182 "%s", ap=0x8207ad4e0) > at /usr/src/lib/libc/stdio/vfprintf.c:285 > 285 ret = __vfprintf(fp, locale, fmt0, ap); > (gdb) p *fp > $1 = {_p = 0x27084f <_logctx+47> "e21:3e7c\n42a/64\n", _r = 0, _w = > -1025, _flags = 2057, _file = 2, _bf = {_base = 0x270820 <_logctx> > "*\"", _size = 1024}, > _lbfsize = -1024, _cookie = 0x8222892d0, _close = 0x8221c7b40 > <__sclose>, _read = 0x8221c7af0 <__sread>, _seek = 0x8221c7b30 > <__sseek>, > _write = 0x8221c7b10 <__swrite>, _ub = {_base = 0x0, _size = 0}, _up > = 0x0, _ur = 0, _ubuf = "\000\000", _nbuf = "", _lb = {_base = 0x0, > _size = 0}, > _blksize = 4096, _offset = 0, _fl_mutex = 0x0, _fl_owner = 0x0, > _fl_count = 0, _orientation = -1, _mbstate = {__mbstate8 = '\000' > , > _mbstateL = 0}, _flags2 = 0} > > (gdb) frame 1 > #1 0x00000008221c300a in __sfvwrite (fp=, > uio=0x8207ad338) at /usr/src/lib/libc/stdio/fvwrite.c:182 > 182 COPY(w); > (gdb) p w > $4 = -1 > > > The dhcpcd flow leading to the crash: > 1. init with setvbuf _IOLBF on stderr > https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/logerr.c#L453 > > 2. fputc with newline called on stderr but is interrupted > https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/logerr.c#L187 > > 3. next event received, vfprintf is called on stderr and crashes > https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/logerr.c#L186 > > > Simple program that eventually crashes: Thanks for the reproducer. The bug is akin to that fixed by bafaa70b6f9098d83d074968c8e6747ecec1e118. Could you please verify that the patch below fixes the original bug? commit 11f817e847b2f06bd543d1bd6cfdff53d69842dc Author: Mark Johnston Date: Fri Mar 25 10:46:24 2022 -0400 libc: Restore fp state upon flush error in fputc diff --git a/lib/libc/stdio/wbuf.c b/lib/libc/stdio/wbuf.c index e1aa70243e94..6cd75145a271 100644 --- a/lib/libc/stdio/wbuf.c +++ b/lib/libc/stdio/wbuf.c @@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$"); int __swbuf(int c, FILE *fp) { + unsigned char *old_p; int n; /* @@ -87,8 +88,15 @@ __swbuf(int c, FILE *fp) } fp->_w--; *fp->_p++ = c; - if (++n == fp->_bf._size || (fp->_flags & __SLBF && c == '\n')) - if (__fflush(fp)) + old_p = fp->_p; + if (++n == fp->_bf._size || (fp->_flags & __SLBF && c == '\n')) { + if (__fflush(fp)) { + if (fp->_p == old_p) { + fp->_p--; + fp->_w++; + } return (EOF); + } + } return (c); } From nobody Fri Mar 25 17:48:56 2022 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 42F061A3731D for ; Fri, 25 Mar 2022 17:49:09 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ8jJ2hfgz3tt1; Fri, 25 Mar 2022 17:49:08 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-ej1-x62e.google.com with SMTP id qa43so16788395ejc.12; Fri, 25 Mar 2022 10:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BvnBs8XLlsZuiehn9YJkdeKHZNusIWM0q1dtehcAsRM=; b=StVxafuxUwoG0DW/WscbuvOBIwzRnJel1Ia/tIwuKVA7Gj7utuU7nsWKZtTrHaMsP1 KBtzki+icZAPluL9BMkWe4nAtwu0ztY1vUmFUgQYtYpy4+UOC6HttbsC9hX5Dwv+JKAO Dz9t/U6LDLUNVy2b7r69iWn+473TJe2SciO3QGC4b5SQnHX2bOnyDrnd62XK40X9AzNq vPByW7ac+YsIDypxMcf7EuaNtTKaMPDU9MOTlCOQUo4PP36UpWc1FDQGJAJZN17+qDOc acgHsJ4uphsmWgGkpE4jaRi3uWP4zL3Gvg/1r3LXl3ZDegZPRIOFXIfLYNsom7Bc0Xdu 4Spw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BvnBs8XLlsZuiehn9YJkdeKHZNusIWM0q1dtehcAsRM=; b=tSqwVd92439e3uTYrCcqk0uXItm4FTWmhOYFCd90bztwwMJ31aBMobYVvUHl5u8hG3 VxECjExtzAzlgHzBcRAOxXuJP5CggR+7ZQUv06zBozsxJ+V9CGDXMN0W8dGI8Kbd8IhK tvK6aHCk0xSmBHLk6P19MFEF+u/J7yKZY2Y5BE6eqDxZ/6OcZCns7tzKYOiVbHXsyOrj iRk7gv0YBDtikdlQ6iz/Rom2nb5/W2GC0wuZgjfuP0bMEHgr2kdXThILY27sVBVTL2Zg x2N1QgoDqyzCGBGLzxCpJ88TVSOeTH2KbwR9w/qzD5oUeIRvHBEIKF0QZ5xTM/SCwdrr FSRw== X-Gm-Message-State: AOAM530r0hpMJOPa7x2C0OILosveWVuJ3n0KuG8zpOGlwO0cHLNtxuzF 7snooEsLs2pKOrCLSt04eP+NhA3508F+brQbfFcUB9ePYqA= X-Google-Smtp-Source: ABdhPJwU/2137DETKDG7M0tW77YoJKfPqaoNf/l0eIEfdxVamssMaxNP/9swnSIrdAKdvMhxw7NJ12G59pJ2SC4Xly8= X-Received: by 2002:a17:906:69c5:b0:6cf:d164:8b32 with SMTP id g5-20020a17090669c500b006cfd1648b32mr13064975ejs.233.1648230547004; Fri, 25 Mar 2022 10:49: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 References: In-Reply-To: From: Guy Yur Date: Fri, 25 Mar 2022 20:48:56 +0300 Message-ID: Subject: Re: Interrupted fputc followed by fprintf in _IOLBF mode causes core dump To: Mark Johnston Cc: freebsd-current , Konstantin Belousov Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KQ8jJ2hfgz3tt1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=StVxafux; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of guyyur@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=guyyur@gmail.com X-Spamd-Result: default: False [-2.26 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.09)[-0.095]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from]; NEURAL_HAM_SHORT(-0.17)[-0.168]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Fri, Mar 25, 2022 at 5:50 PM Mark Johnston wrote: > > On Fri, Mar 25, 2022 at 03:18:40PM +0300, Guy Yur wrote: > > Hi, > > > > dhcpcd on head (Mar 24) and 13.1-BETA2 crashes in fprintf/__sfvwrite. > > It doesn't crash if If I revert the __sflush/__sfvwrite commits: > > 86a16ada1ea608408cec370171d9f59353e97c77 and > > bafaa70b6f9098d83d074968c8e6747ecec1e118. > > > > ... > > Thanks for the reproducer. The bug is akin to that fixed by > bafaa70b6f9098d83d074968c8e6747ecec1e118. Could you please verify that > the patch below fixes the original bug? > > commit 11f817e847b2f06bd543d1bd6cfdff53d69842dc > Author: Mark Johnston > Date: Fri Mar 25 10:46:24 2022 -0400 > > libc: Restore fp state upon flush error in fputc > > diff --git a/lib/libc/stdio/wbuf.c b/lib/libc/stdio/wbuf.c > index e1aa70243e94..6cd75145a271 100644 > --- a/lib/libc/stdio/wbuf.c > +++ b/lib/libc/stdio/wbuf.c > @@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$"); > int > __swbuf(int c, FILE *fp) > { > + unsigned char *old_p; > int n; > > /* > @@ -87,8 +88,15 @@ __swbuf(int c, FILE *fp) > } > fp->_w--; > *fp->_p++ = c; > - if (++n == fp->_bf._size || (fp->_flags & __SLBF && c == '\n')) > - if (__fflush(fp)) > + old_p = fp->_p; > + if (++n == fp->_bf._size || (fp->_flags & __SLBF && c == '\n')) { > + if (__fflush(fp)) { > + if (fp->_p == old_p) { > + fp->_p--; > + fp->_w++; > + } > return (EOF); > + } > + } > return (c); > } Hi, With this patch applied, dhcpcd doesn't crash. Thanks, Guy From nobody Fri Mar 25 21:32:05 2022 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 535F21A2511C for ; Fri, 25 Mar 2022 21:32:07 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQFfb20Ntz4vnW; Fri, 25 Mar 2022 21:32:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648243927; 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=x+nGI/fknQwFNZMDoJsrvFJi6HZ2zCFvapUEXuQA1oY=; b=sng/cjHKU06Y9ujE4Qy4UgVtjkZ/WBfZqED2HScYDwucBgbnHTZHukzlxMhAUZ0qvOWIYr tfU7yc+9UNhaqcsi9ZHPQpThTZ+VGkHNESyOljVHjdAlkgkRqIOpGVGAinh8zVPfoeQ5ib l+BfkkiVdoZW0K9ZZIN1GXveCp8r7XxLiw5cC3F+Xepot9t6rtSsZGg1XTtYMuV3RtTMk8 grAbFWJx6vZMlwIv8nTcI88KEQj50kfAhk/VzjeanadY59ganQTOLyrwaV1ccnXyhsewHR EZERK0K/1Koi8mymInG626Eq2HMDoSpS/ffr66ZwsJrhJGnhcS+iLtLTRaoc8A== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id D33B32228B; Fri, 25 Mar 2022 21:32:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <70135754-84c2-b642-5641-0721e0b4690d@FreeBSD.org> Date: Fri, 25 Mar 2022 14:32:05 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: ktrace on NFSroot failing? Content-Language: en-US To: freebsd-current@freebsd.org References: From: John Baldwin Cc: Rick Macklem In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648243927; 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=x+nGI/fknQwFNZMDoJsrvFJi6HZ2zCFvapUEXuQA1oY=; b=vZiP8eWJc1kp9AOa4fuw4ORZyuPC6mZQv31RIc+3zvUlyA2L8oLnEeCEAIwsWCoLLvLlSX 043pGSGS8Wgg/GagWpz9ixv+p7I94XknsInfDdrLaFsUBXTFGv0eV7mazC7YhAIwX3EN8h uu73D/s1W4p6DCfUkjMI2F/pBD/qDclr/pwJTG5fg0KcrGwNprO/uV+8aWTal24ySFv2zi yFQPc9sclR8CWqMOv1UeZsWRTaiukItumOJ00vbJ510yKxN4P3zQfOud4iVZyuObr3CQa6 neHh5Yum8z4GcwKceQMMuSqThbM4nmZO0vlakejPBoRr1wQpF6ElUFDpu5gy+Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648243927; a=rsa-sha256; cv=none; b=dwZ4GA1IaCTxCDt05uzoMzD0atfxqPu5AeemuiQ/+9LdKFOI4jOzvDgRjdOh13MbKcr1vm +AgwNgUwMaSwBjtZIdin1M1ncmcggWq7T0lfRC6hXNoFmo3AQ0meo44XMS0sU+jm/3/eoX i6Fedzw7kaRYFsCtjlhC8oWmiNWRi9DctH1wD6ddY9ZkVvFOUcfx2sMyal5EW/CPGATjBG u1rH0b0TC2FurFwCvm4NUvjPnM8fiaTgTJaJKr9Y5GX2NUBOZrODflZhpcV0XPIg1DF6Td SpYmmaxjG1eSEhioozL5pYvJMnxzx5ukTufWYpSdshQrR/3YT6ad5G1mgczklQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 3/10/22 8:14 AM, Mateusz Guzik wrote: > On 3/10/22, Bjoern A. Zeeb wrote: >> Hi, >> >> I am having a weird issue with ktrace on an nfsroot machine: >> >> root:/tmp # ktrace sleep 1 >> root:/tmp # kdump >> -559038242 Events dropped. >> kdump: bogus length 0xdeadc0de >> >> Anyone seen something like this before? >> > > I just did a quick check and it definitely fails on nfs mounts: > # ktrace pwd > /root/mjg > # kdump > -559038242 Events dropped. > kdump: bogus length 0xdeadc0de > > I don't have time to look into it this week though. Possibly related: core dumps are no longer working for me on NFS mounts. I get a 0 byte foo.core instead of a valid core dump. -- John Baldwin From nobody Sat Mar 26 02:09:48 2022 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 311491A4A737 for ; Sat, 26 Mar 2022 02:09:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2056.outbound.protection.outlook.com [40.107.115.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQMq7250fz4Yb2; Sat, 26 Mar 2022 02:09:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lA3qNMFH+x/xjUh4SLNjrXhYf14JI/bHa6rUhcVE2aZFckNWXekK/wClh+CC19SfFAcwusbhtFl4HOTBrfyq+L7Re5rb7j1nWavGD2Ue9CmU9otCFm6pP8LBT8AJbzp+r3eWZBathXNZxim0UmZJsfFeFfoHC/2zAKfY+bmtY9Zb0qoL1swJbbXTG4az5ytpgWJXHleGdDfYnl1KaAKfLtRuFLXJJtI+VK7RQknkuyQTGPkaD6ahhbCYS9aoFRF+coFDuVRrVQMX0ypzq+ZvAgZ96TTomRhPkgPGH0JEe0avYQ+vlMhunfCWs0G6xGxJur/JaVNyzQ29EbqFK9YHiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Qjs1NXyKLFPFlKDJPrrCgUkGtmnHYIOXa7fDNkRA+0c=; b=LHH7EsFbe47dLi91cDZZ0sUPHDTMrclqClMf8yZBOfkRYGfh0GX26JVUhX73XDyWxAk78jbDBvT4V0XZFo6Erwy2qhU7btJBccrdJBzqVHfaAXJZu/3FypqXfwko8gRokwqoX8+CPR6AFtPOjQUU+FPH+tOQd8h6hFqNbFs8cfUCHIQ03ko1T+w7Hf45TSOcL3MpggkHBXdEB2i+bSrdjkJWHaB352v7so/lpTsRFBPhMC0ftc3CzzF5n6wHfugapKwHf50BU9JdrPwYQ+/lYQBBVNkgoAeGco/iyhkoAt4FXKIIMvZL2pzW2a5y0yeaK928EOGFA/89GnpYLHAg0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qjs1NXyKLFPFlKDJPrrCgUkGtmnHYIOXa7fDNkRA+0c=; b=M1yUzXG7aL362DEV0dcAn5kHkbz1AKspJARofSsBEMuUMTjMRKMAtsJDc45YgGzcgqlwcy8IUDRoW5lDzKfc8o28uNfk8/58Qrt/9kJY2BPPU5mStY8TRz18ay8R2t2qa92J5CvHHgUvz2xwjSGWNxZxsuvQquRwbKy3ZMi0oPnf7cLB9/vxlSgL6ox3+5H2Oh8VrthgT/TkAZBkwTk1UVB3995h++vvpJRKnn5mEpDn2OQXKahiBMpbTjZNpXzDesLtyDVGjsb0OUumU6CzaGhA+cHYXnxTbtP9f7k8B1Srk70VmKmvnWZ4zzgimARL4EfWB9GkH0U1QAO2GYZ54A== Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:de::14) by YT1PR01MB2810.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:4::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.15; Sat, 26 Mar 2022 02:09:48 +0000 Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::39d7:e98e:fd00:2591]) by YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::39d7:e98e:fd00:2591%6]) with mapi id 15.20.5102.021; Sat, 26 Mar 2022 02:09:48 +0000 From: Rick Macklem To: John Baldwin , "freebsd-current@freebsd.org" Subject: Re: ktrace on NFSroot failing? Thread-Topic: ktrace on NFSroot failing? Thread-Index: AQHYQI/JkEo0PYUUsU+bkJKIOYzP06zQ6ftQ Date: Sat, 26 Mar 2022 02:09:48 +0000 Message-ID: References: <70135754-84c2-b642-5641-0721e0b4690d@FreeBSD.org> In-Reply-To: <70135754-84c2-b642-5641-0721e0b4690d@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 355a4163-888a-edad-d4e7-e8b9fd8e565e x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 86d72eac-d265-45cf-263b-08da0ecdb450 x-ms-traffictypediagnostic: YT1PR01MB2810:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QvHgyXRtrlWZVAvbwQ/jRE4tXKjTCtbOiatl2rxE+XtTV/8QO7xGiJ6CkLFMdfbhI2gnJp8djJklnH8O3Ubhs/aHusPYZq50bqhCU4PVQXXrZUNvF8CskVu1WdaPfC48PsCt8N5AKq1xfKPu8oniXLNxhzU5Ibfpen7I9eci2n5jKwGKwOthnNMuShqqXVPzaMVeYpdMNt6oGQl2Ba24AAvWrTbUndJMJUOhQXk1He/SPyb7h/mq+sCZMN+/pDsWBWDyBHZ+kD7MPkQCkYjnZ9Uj73Bi8dd1onpU5oX/BQpBTbYu0sNnEQCosSTW8K9zkszH3DT/DjHxQ0GWVKzTCYOts7lORqq8bbpkq0PT6ISj6qa8uUaGbmxmcEZ0fPHTdfYiFIlj5tkiZ/qe+2z1GFlxwnLSEL+qAH3iV6EgyTKpb9Engu2Silw/A1JAGAdjx4hipLC0i60pVbk+2ir7/SWQljsVvYQsF2RD7ISOGG8WtNUlAlrX96MAalrHBixLyBLSWLfAed/mtgdZFoYGhw6TvGK1saXMOJ5LJHHZzMUnz4DARo1onYCYHKI91s8mvPOvtDheXOucYH/TBBWeOzM783Po/kwtqgrBDa6E/6oOvoq+4rW8TGTm/zRQGJUm7ELhs0SM/m6Zmphv/+IwlIk9NKRMOYBP0smnm4rsM0e5F9OPqqN542IXW6JPsBmHEWVkguLiJRdJWZnIAXKn6Q== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(366004)(71200400001)(186003)(6506007)(53546011)(7696005)(9686003)(83380400001)(8936002)(52536014)(2906002)(55016003)(5660300002)(110136005)(508600001)(64756008)(66946007)(76116006)(66446008)(66556008)(450100002)(66476007)(8676002)(316002)(786003)(91956017)(38070700005)(38100700002)(86362001)(3480700007)(33656002)(122000001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ZzHuiPcXWw9U/vbbhO+ukFceyAwc6gM8kCu1LtP1P0VHvZkSAj+ZDr+/Jv?= =?iso-8859-1?Q?z5u8zd6qvk4PLU94ETfDbQCGioOW5kTDrQqvez6dzym+Rju7nZec7C1iEY?= =?iso-8859-1?Q?wlwVk29FgXJVKHdmF/oGmhtE87R1M88AlesGkayCXgAEQAa5AyLxBTa7y2?= =?iso-8859-1?Q?UBHEsUOE+ersSAkJRq3bue22DC4vBKdNj2nVqrCIdDGy7Wl+hxD0oHa7yI?= =?iso-8859-1?Q?6gqxQBajJ/GTWJ/MqhVleNYaMj6hjF6kZ2NQb6KWatYPCNwCn+0hufXhzF?= =?iso-8859-1?Q?AgbyEANhVmiv5sQHMm2IXsnswB7ej4D5TJDDSG9w5RE2DRwWflQEPdX6Un?= =?iso-8859-1?Q?spmXSUmbN3vvERVu5i9DxwdcL3Ffc4WQ1R87ZgbcRzBk0d7kVpk7c9cymS?= =?iso-8859-1?Q?5d6ZHi4CyOiNVtfvUbhsljM08ofwJNqvzHUjPadoY8e1cIXwbu0IAP8dWD?= =?iso-8859-1?Q?ZtwPSCHBEX+4PwAQvApfkHd0vpDRSPBChT3xMSzJgE0NKECKBOUOH4PPcE?= =?iso-8859-1?Q?IEJR2D+6fIp/ey8nuPVT75cRfb1S0R2U7/SjJj79kmWILrZW3YmZ3nTG/X?= =?iso-8859-1?Q?ruVLkFgHiAjY5LvBLeDfd0M2eE9zq11vS10dnpP2gWARcxbltjZ2R78AO+?= =?iso-8859-1?Q?bOYE4nfq9PljT43IJFFytuF+82dNzr140wfZEEgjL7TLuOoSRUVLzx3tYq?= =?iso-8859-1?Q?N+FAV0yNJFzGUEqWkt0DJa3HibXoYqjDLYH8OX9xEfnzUf2jQ9b2Wd6rI+?= =?iso-8859-1?Q?RMrqehCIcS1pnvet0Zy5AxSVV5eMSwa9hi6V21BBKuX2rAKMWPhmAiDpL/?= =?iso-8859-1?Q?ZxQ3uACK5IkudEj5u2mM8zxqfM428x7hThXgou78LqRt48JcYJmQxVZtTh?= =?iso-8859-1?Q?vHY5SXPVoM5jdeYTMzNcjCfZbffhnP2mLPCMot4RK68j+X1RH2+rYElE5G?= =?iso-8859-1?Q?e6KRXUoP8Pz5HIqXG/wseqU6f2x4f7XFAW3MDQC/SbVFJam5MANFRwRHmA?= =?iso-8859-1?Q?PMfy52cVzNhjIKjt2nCDXxWpQvBLYwxJsC2UQczlPBwP28iDiNXXKBpVfh?= =?iso-8859-1?Q?Ie69J3hqjXlWeTJT7IDueN7BXJLwTUR+xnnCh5u0hMgmb1FtqGO2xNdGaW?= =?iso-8859-1?Q?15ze13IOPxwanUyFja5Rtuyv4kYDS1teOpL+qkh+FPdt20Z4vLWBHOtIz7?= =?iso-8859-1?Q?5+0cEPCelenXlDW/yFopZVIyrWwLp6eto1NcnoDAhL//zY2+fDQ6L1K8V8?= =?iso-8859-1?Q?Lz8toEUPns5Ywf3o+KKmonitAjo/W5UuW2go4JpfTO4DbAqQbQBaW0xdU4?= =?iso-8859-1?Q?6rd/pB2mHCWBn0b6q8ok5V32aSzsShCxSvq70RPLmgezPc91r9BjYEgHBx?= =?iso-8859-1?Q?nXp+0XOSCRNEgosCnK9GhGZ2B8ieJHJrXhjSLgYzcZ1baF9rNV5msk6vwI?= =?iso-8859-1?Q?X3aBEUi0boaxcmdgc8kHe/huLZlvxLx2MGPoklpzxleSSsNYc+E1qP6Jj/?= =?iso-8859-1?Q?k7qGLz/ExTY4kpKq75UZNzR7qyMbGdvx5tK88DIBJqg3jDSvQ4N95FnVNk?= =?iso-8859-1?Q?cx50ki3leUtqSfVgmbDeKvApQFdZ?= Content-Type: text/plain; charset="iso-8859-1" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 86d72eac-d265-45cf-263b-08da0ecdb450 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2022 02:09:48.2113 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Y32v4VsJ9cusUDB7LvaG/F4tdTUN0d/etBSM7QIotEaqXl/zI6re/GjvVW2giOa3mYLSAsSgvvU5qgzaSUcD8Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB2810 X-Rspamd-Queue-Id: 4KQMq7250fz4Yb2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=M1yUzXG7; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.115.56 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.115.56:from] X-ThisMailContainsUnwantedMimeParts: N John Baldwin wrote:=0A= > On 3/10/22 8:14 AM, Mateusz Guzik wrote:=0A= > > On 3/10/22, Bjoern A. Zeeb wrote:=0A= > >> Hi,=0A= > >>=0A= > >> I am having a weird issue with ktrace on an nfsroot machine:=0A= > >>=0A= > >> root:/tmp # ktrace sleep 1=0A= > >> root:/tmp # kdump=0A= > >> -559038242 Events dropped.=0A= > >> kdump: bogus length 0xdeadc0de=0A= > >>=0A= > >> Anyone seen something like this before?=0A= > >>=0A= > >=0A= > > I just did a quick check and it definitely fails on nfs mounts:=0A= > > # ktrace pwd=0A= > > /root/mjg=0A= > > # kdump=0A= > > -559038242 Events dropped.=0A= > > kdump: bogus length 0xdeadc0de=0A= > >=0A= > > I don't have time to look into it this week though.=0A= >=0A= > Possibly related: core dumps are no longer working for me on NFS=0A= > mounts. I get a 0 byte foo.core instead of a valid core dump.=0A= I just tried a core dump for a kernel built from main sources as of=0A= to-day and it worked ok.=0A= =0A= However my userland is several months old and I can't easily upgrade=0A= it for now.=0A= =0A= There was a recent ZFS problem that found its way into 13.0-p8 that=0A= I'm pretty sure is fixed now. If you had a fairly recent server exporting= =0A= ZFS, that *might* explain it?=0A= =0A= In particular, an NFSroot uses NFSv3 and nothing has changed for=0A= NFSv3 in a looonnggg time.=0A= =0A= rick=0A= =0A= --=0A= John Baldwin=0A= From nobody Sat Mar 26 04:03:46 2022 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 4D8F11A4279F for ; Sat, 26 Mar 2022 04:03:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2042.outbound.protection.outlook.com [40.107.115.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQQLd519Wz4pHn; Sat, 26 Mar 2022 04:03:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YdHYRscEt/GfTAxJUFSl9eI9jY4CjCUbc6OPP66tMzfe8e95Zt5yNVbm1ykOUpF4k+6m3dYnkOMzIINa9tnL59xWn+M3dTpk9lkAnjUMpStKtGqkY5eDVZgW+Sr33N2R0ZCnjbPR+Z8aJxuezAi0h9Kvcm9bg1dwHpy/H6ZcTV4uM5pXP3z2nwjQt1ZY9GkvgOM+1ASilnvCuppYnGszMUOVgE7Hi6xwmqDWoHuag4DSH1pft0wtua4LC6Yev3FNliq0eGiFQxEWw3GuJDXSh/qu4haVX9PXBegKjK7b1VKNqr8e7M/xDnnishRP6g/p/wPe1VbJdmvaC0/sRqomIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hYnXzY1QIOwEXK7iDCMH/LRF2NcXBu1jPF4ffPexmx4=; b=YiTrATKRRsr5ztRzU+oVCTwBCiXrgciz67wCK7MkHYifKgGo8kzq30o83wZju8pjol/3JCYhv9M+ig+tcaDNiteXlDLq0TzLUuix9vZBKODEvzY1RFTUlVv/1wHgHxzxVL2iu0+1NLHzjIZeJ/s5V2vqfqk+Vd6YOD8fEasi76KbnKeaHl5qi0lskUyX53ZM26Z6zHLUNqJj6sbwM6G3Gwcmd2fHbBDbiQsiF7n81PL9hS3RbgbSc13nsYAfxjYIqQi9QYXW5ueQPk2Y1D8bmlkBoFhTvLEo6m8d9qMg7RhoWt0kW42JIUFdjkKrOiJQB9SwiD7b/IM1G7O6gC8WVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hYnXzY1QIOwEXK7iDCMH/LRF2NcXBu1jPF4ffPexmx4=; b=PSHKTRQlsAm1DEbAVK+dqY01j3FJ5I7L/pXPBDoiZZx2Ts6DcEXx2OOa9vy3WzscxGhY5o4I+RPsO3fneL0I+ariwcVRZNC96kl7Vn676uraUerwpLz8iwNF5kw0MzKxCXgC7F/acz8q0uGiRmwaJfTgv+54PWX2cyEuK7SK6ieoB4OAe+CjxUNa+8gCpMzXIWHiofbq/+0C/lWeiSqjSLLSKF0Buhx18Mm2PfRhfXrSS2ECslXuiRiVXEPwMqdeMqZvn4WqRjLZSa7UiTrD5SMvc0OaYxjhC0+/KmcD0LUhoiYsdbDsYJRvlEBDUyLjdm8rTpG/1AM8V8j+68Jjjw== Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:de::14) by YTBPR01MB3023.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:1c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.16; Sat, 26 Mar 2022 04:03:47 +0000 Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::39d7:e98e:fd00:2591]) by YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::39d7:e98e:fd00:2591%6]) with mapi id 15.20.5102.021; Sat, 26 Mar 2022 04:03:46 +0000 From: Rick Macklem To: John Baldwin , "freebsd-current@freebsd.org" Subject: Re: ktrace on NFSroot failing? Thread-Topic: ktrace on NFSroot failing? Thread-Index: AQHYQI/JkEo0PYUUsU+bkJKIOYzP06zQ6ftQgAAf8BE= Date: Sat, 26 Mar 2022 04:03:46 +0000 Message-ID: References: <70135754-84c2-b642-5641-0721e0b4690d@FreeBSD.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: suggested_attachment_session_id: d01c8e14-9a1a-4986-187f-da997a3c125c x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 23442d84-59cc-437a-347c-08da0edda07c x-ms-traffictypediagnostic: YTBPR01MB3023:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sxNjUImi2Axy4EDoLV0Kb31E8IW8G28xcmvYXsOlhy4cE2+6vFyibtTs3pe1M6B+0oFS6580Rk0viqoOrfPN6oHIbfK4tSg3BZMbJ+kQVt6sHkJl/YL5eXYXMSOZq7IHvPF4unYHxsSISFfdCJh2ttNF6x6+lMxaCP2PazjqKDyuQDwddkxV/touVYWTc9fUbH+pOeptM9qloT75h3P4OhcpCQu1Vdgtu2OGxmtIs3Z9bi6TJwHoV/nSyBjrj1uCPzPqJ+aEmLE253JkGaTrsEeJMjSHuS+6DaxlyS/AZm4vaFfHPz78RwpcVG6Dk+cuoAldy+U63C42RFnuA6XvoZc38i4XwStRGLWCGBr3PtMntMHdEFNnUHzVuXZNq/nE/lqc5DP73rVXiRWlD88XxE1aToVFGKP1owgEIV8Rf9Q7AaF2qB6pQh05QDza5EyOtmY8G2Ju2q5o2SLgMOlw8pUGYbWtNlrai35vwx8NLltoP201MCN3w+xZgqOn0jfH/4ulQ9ROYJtoQmyATG2dny8ZTtFGoFz3rYIovBxAqya3Q22rfE7ygXR4hBcrvD0j6AQcx4q1bzLKrvM4kzizYGXszIVKGYTdVZIfaJ/NKUe7IRlFgcPwBXImdu59fW/VLMz0VCqr/2N/TjzLA1zWgiglizgtA5NJ0MX0C+Ph2nJf6vPsSAZPc5ZNVi1IfO9OVoZdy6Fx3kHsBjyRrohXqQ== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(366004)(91956017)(508600001)(450100002)(83380400001)(76116006)(5660300002)(53546011)(110136005)(186003)(52536014)(99936003)(66556008)(122000001)(8676002)(64756008)(66946007)(66476007)(66446008)(8936002)(55016003)(3480700007)(38100700002)(33656002)(86362001)(2906002)(9686003)(71200400001)(316002)(6506007)(7696005)(786003)(38070700005)(2940100002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?N7t20DfADCVdIxgp54BOB7twF7Ipx23QF9itUrgLgJnhvQKjNoShWkFny9?= =?iso-8859-1?Q?0FosheHttLx4V611mZEUFzvDUS3MY+6QXCjauhghuuidnA1oKJuw8pzXQH?= =?iso-8859-1?Q?/z/gxH0H44H7RlRCNHlfNJN5aNPaLDJFHHJYhPSuT/qe8R65Jt4+ZSsA1z?= =?iso-8859-1?Q?yEE6JeV3v1EL4Jv3ZXrChtg4dljp1dmB+Cw/HCt5cgEb4GojEPn/1SKS0B?= =?iso-8859-1?Q?1rVfysqQBxrWzxFc8wGj4CBOU+x3IoMhiuXEmdNRgLO+cwciyDbgxZjzmp?= =?iso-8859-1?Q?RM/5Jgq/kG76SbW59mW3hP2l9XPEGBhwmm68VsQPJG6htmuLM3oeYT5nt5?= =?iso-8859-1?Q?StYouZwkfzkKSPego/aT01mO72/zdCvODIfgl0CDVrOJ1zNQDa8qGg9zuj?= =?iso-8859-1?Q?ArYW3ri+IJow8tNo+yZ2uu/n1antBbdnyhYGuGCkb4eVkyxo3t3CfxCN18?= =?iso-8859-1?Q?4aDaPOEETjQLA6ErbmZAyoUeZDYbFUrmRYlx4etPZLIkcDJ4QIalcOA4ue?= =?iso-8859-1?Q?yTtV2m5OG0bf8RTuFn6bpIq73WfRS7v71uTAgFmJV+yZWDRXM15irgtFEq?= =?iso-8859-1?Q?RtWj9YqXYPewoaBvByZsh3eAa7mT/5N3zziuLawrC7m6h0miU9ZJYbsH9G?= =?iso-8859-1?Q?XdhO/vYE2z4LU86sh7Mk2GyoQnnFzudoXynluGf6de/tFAD/BHmcSGopLa?= =?iso-8859-1?Q?iNis1H5gF0Od03dPw58GMdN/RkNEcSfsuoL6PdfU0gpzzsGyyKFfgVXkI1?= =?iso-8859-1?Q?F934hiNBU8Y70qubjDc6J53a0PRy/qaXdaoVoh8Qii513AjdK0yre0cwIq?= =?iso-8859-1?Q?54iO+7DsqodDbbEBp8BKFGvcvLw6CsXIYiO1WM/e8hi4CzC56RS26BGbr0?= =?iso-8859-1?Q?FZngyyBPvAyB1NswlmQ3ab863Cp33RpL/ihLUtcsw+UNbBoISMOS4LS9gl?= =?iso-8859-1?Q?Wdawl1ZVwjcMLgGUIIpA1OZk/mbddL8LCicEK128S/+zULzyvHvxiEGSbH?= =?iso-8859-1?Q?Xv5r3waQdEuOfGDsuUYHdC4bFddin18+nksbKaCQQccpFdxRuAw1iX4l1/?= =?iso-8859-1?Q?kM21DunotfWS3RkxlLaQCIHcLw8YPMzxK65P3tN9XCcgLV0yWYRj74NxAj?= =?iso-8859-1?Q?wpQ2bUfyt/9UeBNaJ2Gf2WXg7Sj/4yKclDqy6dtbnyWgJaYDZWqd7a1hn1?= =?iso-8859-1?Q?b9jd2RBWEqkLEgg6F1NgD2LZo0r4p2xwFTqeWEEGe+RdOFZq6pZH22dwGy?= =?iso-8859-1?Q?c0yeeH74I11id8gCB88smd1Q9GQwy3UxUq2a6tBU8vHjsO0OVMNkvOBy2J?= =?iso-8859-1?Q?uCKsShugeRg61RpbKUWJV2nDi2zrtJ2P6Be9aMwv44Ufki3cZsh/TM+7YU?= =?iso-8859-1?Q?JZ2z4zadHyBA08W5GGGHFYA/erOVE4yy/k92ZT6UvntGARMDjhqJokxHjt?= =?iso-8859-1?Q?O/aUCaBnw0v1+dN8GfVluRhNXZzI6Jag6eW0XE3NWe2HV3txwbuRLfy5VP?= =?iso-8859-1?Q?pD7aK1SoqhPeRUQZCGTy8e2RyJdt6dNlsi+YRs4dV/IEooXEUjj2Dov5Mo?= =?iso-8859-1?Q?eETB3PIV7/gOUUt+hDKK3ryaiVy7S1o+sl8avTGOAkGAdDJ/Df0gVeyQ9s?= =?iso-8859-1?Q?Y6WlKPLVDrmnCOH0Ro0ioJbrfqhZCdv29fgSAGyxv7Sqr6MV6G8LMQDDUi?= =?iso-8859-1?Q?j4LCM36DTqPAk+5n1zpXTZ1TVEvgFz7bpVlEfqn5aPC+27NVrVmTy0Wr57?= =?iso-8859-1?Q?I5AdmWyAXJcY/HXN/ntK8+AcRxzfuBPxc27Qx63fiN24SS4mfirRZdiGja?= =?iso-8859-1?Q?64N3uYfVPo/O/7qYIc4ZzQXOiyBZMGlv2KYFHD1GqSg/N+s3iBr9nwvG3c?= =?iso-8859-1?Q?Jt?= x-ms-exchange-antispam-messagedata-1: zSefCdEeVmnZzA== Content-Type: multipart/mixed; boundary="_002_YT2PR01MB973039BE3072ED3F94CFE141DD1B9YT2PR01MB9730CANP_" 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-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 23442d84-59cc-437a-347c-08da0edda07c X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2022 04:03:46.6110 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YumUgNNLVr/UYNk/p9wjzucclgCw/ccY+n8F6mBtDVd7x9/kztp+D68CpsvBtpvfDUiCpIdnglDgyOzMvl3aHQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3023 X-Rspamd-Queue-Id: 4KQQLd519Wz4pHn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=PSHKTRQl; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.115.42 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.98 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-0.98)[-0.980]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.115.42:from]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-ThisMailContainsUnwantedMimeParts: N --_002_YT2PR01MB973039BE3072ED3F94CFE141DD1B9YT2PR01MB9730CANP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rick Macklem wrote:=0A= > John Baldwin wrote:=0A= > > On 3/10/22 8:14 AM, Mateusz Guzik wrote:=0A= > > > On 3/10/22, Bjoern A. Zeeb wrote:=0A= > > >> Hi,=0A= > > >>=0A= > > >> I am having a weird issue with ktrace on an nfsroot machine:=0A= > > >>=0A= > > >> root:/tmp # ktrace sleep 1=0A= > > >> root:/tmp # kdump=0A= > > >> -559038242 Events dropped.=0A= > > >> kdump: bogus length 0xdeadc0de=0A= > > >>=0A= > > >> Anyone seen something like this before?=0A= > > >>=0A= > > >=0A= > > > I just did a quick check and it definitely fails on nfs mounts:=0A= > > > # ktrace pwd=0A= > > > /root/mjg=0A= > > > # kdump=0A= > > > -559038242 Events dropped.=0A= > > > kdump: bogus length 0xdeadc0de=0A= > > >=0A= > > > I don't have time to look into it this week though.=0A= > >=0A= > > Possibly related: core dumps are no longer working for me on NFS=0A= > > mounts. I get a 0 byte foo.core instead of a valid core dump.=0A= > I just tried a core dump for a kernel built from main sources as of=0A= > to-day and it worked ok.=0A= > =0A= > However my userland is several months old and I can't easily upgrade=0A= > it for now.=0A= >=0A= > There was a recent ZFS problem that found its way into 13.0-p8 that=0A= > I'm pretty sure is fixed now. If you had a fairly recent server exporting= =0A= > ZFS, that *might* explain it?=0A= > =0A= > In particular, an NFSroot uses NFSv3 and nothing has changed for=0A= > NFSv3 in a looonnggg time.=0A= Oops, I did make a change that affected NFSv3 as well as NFSv4.=0A= Last December I committed a path to head that made IO_APPEND=0A= writes use nfs_directio_write() and avoid the buffer cache.=0A= =0A= Turns out nfs_directio_write() only worked for UIO_USERSPACE.=0A= The attached trivial patch fixes ktrace for me.=0A= I have no idea if core dumping ever does IO_APPEND VOP_WRITE()s?=0A= =0A= Please test the attached patch.=0A= =0A= Thanks, rick=0A= =0A= rick=0A= =0A= --=0A= John Baldwin=0A= =0A= --_002_YT2PR01MB973039BE3072ED3F94CFE141DD1B9YT2PR01MB9730CANP_ Content-Type: application/octet-stream; name="ktrace.patch" Content-Description: ktrace.patch Content-Disposition: attachment; filename="ktrace.patch"; size=416; creation-date="Sat, 26 Mar 2022 04:03:40 GMT"; modification-date="Sat, 26 Mar 2022 04:03:41 GMT" Content-Transfer-Encoding: base64 LS0tIHN5cy9mcy9uZnNjbGllbnQvbmZzX2NsYmlvLmMuc2F2CTIwMjItMDMtMjUgMTk6MzY6NTgu MzgxNTU4MDAwIC0wNzAwCisrKyBzeXMvZnMvbmZzY2xpZW50L25mc19jbGJpby5jCTIwMjItMDMt MjUgMTk6NDQ6MTUuMzg2NDY5MDAwIC0wNzAwCkBAIC03ODAsNyArNzgwLDcgQEAgZG9fc3luYzoK IAkJCXVpby51aW9faW92Y250ID0gMTsKIAkJCXVpby51aW9fb2Zmc2V0ID0gdWlvcC0+dWlvX29m ZnNldDsKIAkJCXVpby51aW9fcmVzaWQgPSBzaXplOwotCQkJdWlvLnVpb19zZWdmbGcgPSBVSU9f VVNFUlNQQUNFOworCQkJdWlvLnVpb19zZWdmbGcgPSB1aW9wLT51aW9fc2VnZmxnOwogCQkJdWlv LnVpb19ydyA9IFVJT19XUklURTsKIAkJCXVpby51aW9fdGQgPSB0ZDsKIAkJCWlvbW9kZSA9IE5G U1dSSVRFX0ZJTEVTWU5DOwo= --_002_YT2PR01MB973039BE3072ED3F94CFE141DD1B9YT2PR01MB9730CANP_-- From nobody Sat Mar 26 04:42:19 2022 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 8B59C1A4A6CB for ; Sat, 26 Mar 2022 04:42:33 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQRCD3rWrz4tPv for ; Sat, 26 Mar 2022 04:42:32 +0000 (UTC) (envelope-from 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 22Q4gKfh073258 for ; Fri, 25 Mar 2022 21:42:26 -0700 (PDT) (envelope-from bsd-lists@bsdforge.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 Date: Fri, 25 Mar 2022 21:42:19 -0700 From: Chris To: freebsd-current Subject: loading amfgpu results in immefiate power off on 12.3-STABLE r371721 User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_5167f7822564b81f04ce6019023092e5" X-Rspamd-Queue-Id: 4KQRCD3rWrz4tPv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_5167f7822564b81f04ce6019023092e5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed This probably isn't the correct list. But it's the closest of all the lists I'm subscribed to. Please forgive me. OK so here's what happened. I couldn't get the trackpad on a Dell laptop I just got to work in FreeBSD-13. So after a couple of days, I gave up and tried 12.3-STABLE r371721 today. Once I got the network (wifi) going. I pkg installed drm-kmod && it's depends. Added kld_list="amdgpu" to rc.conf && rebooted. The moment it loaded, the screen went black and it powered off. Booted to single-user, fsck && cp /var/log/messages to ~/ . I'm attaching a copy in case it sheds any light on the cause. The most interesting thing about all this, is that amdgpu worked flawlessly on 13 -- go figure. Thanks! --Chris --=_5167f7822564b81f04ce6019023092e5 Content-Transfer-Encoding: base64 Content-Type: text/plain; name=messages Content-Disposition: attachment; filename=messages; size=109683 TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAtLS08PEJPT1Q+Pi0tLQpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IEFQSUM6IFVzaW5nIHRoZSBNQURUIGVudW1lcmF0b3IuCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogQ29weXJpZ2h0IChjKSAxOTkyLTIwMjEgVGhl IEZyZWVCU0QgUHJvamVjdC4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBDb3B5cmln aHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5 OTMsIDE5OTQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJVGhlIFJlZ2VudHMgb2Yg dGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBGcmVlQlNEIDEyLjMtU1RBQkxFIHIzNzE3MjEgR0VORVJJQyBhbWQ2NApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IEZyZWVCU0QgY2xhbmcgdmVyc2lvbiAxMy4wLjAgKGdpdEBn aXRodWIuY29tOmxsdm0vbGx2bS1wcm9qZWN0LmdpdCBsbHZtb3JnLTEzLjAuMC0wLWdkN2I2Njli M2EzMDMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogUFBJTSAwOiBQQT0weGUwMDAw MDAwLCBWQT0weGZmZmZmZmZmODI3MTAwMDAsIHNpemU9MHg1N2YwMDAsIG1vZGU9MHgxCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcG1hcDogbGFyZ2UgbWFwIDggUE1MNCBzbG90cyAo NDA5NiBHYikKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBWVChlZmlmYik6IHJlc29s dXRpb24gMTYwMHg5MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBQcmVsb2FkZWQg ZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQgMHhmZmZmZmZmZjgyNWFiMDAwLgpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFByZWxvYWRlZCBib290X2VudHJvcHlfY2Fj aGUgIi9ib290L2VudHJvcHkiIGF0IDB4ZmZmZmZmZmY4MjViNDY1OC4KTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBQcmVsb2FkZWQgaG9zdHV1aWQgIi9ldGMvaG9zdGlkIiBhdCAweGZm ZmZmZmZmODI1YjQ2YjAuCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogUHJlbG9hZGVk IGVsZiBvYmogbW9kdWxlICIvYm9vdC9rZXJuZWwvaWZfYXRoLmtvIiBhdCAweGZmZmZmZmZmODI1 YjQ3MDAuCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogUHJlbG9hZGVkIGVsZiBvYmog bW9kdWxlICIvYm9vdC9rZXJuZWwvYXRoX2Rmcy5rbyIgYXQgMHhmZmZmZmZmZjgyNWI0YzY4LgpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFByZWxvYWRlZCBlbGYgb2JqIG1vZHVsZSAi L2Jvb3Qva2VybmVsL2F0aF9yYXRlLmtvIiBhdCAweGZmZmZmZmZmODI1YjUxZDAuCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogUHJlbG9hZGVkIGVsZiBvYmogbW9kdWxlICIvYm9vdC9r ZXJuZWwvYXRoX2hhbF9hcjkzMDAua28iIGF0IDB4ZmZmZmZmZmY4MjViNTdjMC4KTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiBQcmVsb2FkZWQgZWxmIG9iaiBtb2R1bGUgIi9ib290L2tl cm5lbC9hdGhfaGFsX2FyNTQxNi5rbyIgYXQgMHhmZmZmZmZmZjgyNWI1ZmIwLgpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFByZWxvYWRlZCBlbGYgb2JqIG1vZHVsZSAiL2Jvb3Qva2Vy bmVsL2F0aF9oYWxfYXI1MjEyLmtvIiBhdCAweGZmZmZmZmZmODI1YjY3YTAuCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogUHJlbG9hZGVkIGVsZiBvYmogbW9kdWxlICIvYm9vdC9rZXJu ZWwvYXRoX2hhbF9hcjUyMTEua28iIGF0IDB4ZmZmZmZmZmY4MjViNmY1MC4KTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBQcmVsb2FkZWQgZWxmIG9iaiBtb2R1bGUgIi9ib290L2tlcm5l bC9hdGhfaGFsX2FyNTIxMC5rbyIgYXQgMHhmZmZmZmZmZjgyNWI3NjQwLgpNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IENhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNsb2NrOiAy MTk1OTIxMzg1IEh6Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogQ1BVOiBBTUQgQTgt NzQxMCBBUFUgd2l0aCBBTUQgUmFkZW9uIFI1IEdyYXBoaWNzICAgICAoMjE5NS45Mi1NSHogSzgt Y2xhc3MgQ1BVKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6ICAgT3JpZ2luPSJBdXRo ZW50aWNBTUQiICBJZD0weDczMGYwMSAgRmFtaWx5PTB4MTYgIE1vZGVsPTB4MzAgIFN0ZXBwaW5n PTEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIEZlYXR1cmVzPTB4MTc4YmZiZmY8 RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0Es Q01PVixQQVQsUFNFMzYsQ0xGTFVTSCxNTVgsRlhTUixTU0UsU1NFMixIVFQ+Ck1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogICBGZWF0dXJlczI9MHg3ZWQ4MjIwYjxTU0UzLFBDTE1VTFFE USxNT04sU1NTRTMsQ1gxNixTU0U0LjEsU1NFNC4yLE1PVkJFLFBPUENOVCxBRVNOSSxYU0FWRSxP U1hTQVZFLEFWWCxGMTZDLFJEUkFORD4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAg IEFNRCBGZWF0dXJlcz0weDJlNTAwODAwPFNZU0NBTEwsTlgsTU1YKyxGRlhTUixQYWdlMUdCLFJE VFNDUCxMTT4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIEFNRCBGZWF0dXJlczI9 MHgxZDQwMzdmZjxMQUhGLENNUCxTVk0sRXh0QVBJQyxDUjgsQUJNLFNTRTRBLE1BUyxQcmVmZXRj aCxPU1ZXLElCUyxTS0lOSVQsV0RULFRvcG9sb2d5LFBOWEMsREJFLFBUU0MsUEwyST4KTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIFN0cnVjdHVyZWQgRXh0ZW5kZWQgRmVhdHVyZXM9 MHg4PEJNSTE+Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICBYU0FWRSBGZWF0dXJl cz0weDE8WFNBVkVPUFQ+Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICBTVk06IEZl YXR1cmVzPTB4MWNkZjxOUCxMYnJWaXJ0LFNWTUwsTlJJUFMsVHNjUmF0ZU1zcixGbHVzaEJ5QXNp ZCxEZWNvZGVBc3Npc3QsUGF1c2VGaWx0ZXIsRW5jcnlwdGVkTWNvZGVQYXRjaCxQYXVzZUZpbHRl clRocmVzaG9sZD4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBSZXZpc2lvbj0xLCBB U0lEcz04Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICBUU0M6IFAtc3RhdGUgaW52 YXJpYW50LCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogTDEgMk1CIGRhdGEgVExCOiA4IGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogTDEgMk1CIGluc3RydWN0aW9uIFRMQjogOCBlbnRy aWVzLCBmdWxseSBhc3NvY2lhdGl2ZQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IEwx IDRLQiBkYXRhIFRMQjogNDAgZW50cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBMMSA0S0IgaW5zdHJ1Y3Rpb24gVExCOiAzMiBlbnRyaWVzLCBm dWxseSBhc3NvY2lhdGl2ZQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IEwxIGRhdGEg Y2FjaGU6IDMyIGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDgtd2F5IGFzc29j aWF0aXZlCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogTDEgaW5zdHJ1Y3Rpb24gY2Fj aGU6IDMyIGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDItd2F5IGFzc29jaWF0 aXZlCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogTDIgMk1CIGRhdGEgVExCOiAyNTYg ZW50cmllcywgMi13YXkgYXNzb2NpYXRpdmUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBMMiAyTUIgaW5zdHJ1Y3Rpb24gVExCOiAwIGVudHJpZXMsIDItd2F5IGFzc29jaWF0aXZlCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogTDIgNEtCIGRhdGEgVExCOiA1MTIgZW50cmll cywgNC13YXkgYXNzb2NpYXRpdmUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBMMiA0 S0IgaW5zdHJ1Y3Rpb24gVExCOiA1MTIgZW50cmllcywgNC13YXkgYXNzb2NpYXRpdmUKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBMMiB1bmlmaWVkIGNhY2hlOiAyMDQ4IGtieXRlcywg NjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDE2LXdheSBhc3NvY2lhdGl2ZQpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHJlYWwgbWVtb3J5ICA9IDQyOTQ5NjcyOTYgKDQwOTYgTUIp Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMp OgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IDB4MDAwMDAwMDAwMDAxMDAwMCAtIDB4 MDAwMDAwMDAwMDA5ZWZmZiwgNTg1NzI4IGJ5dGVzICgxNDMgcGFnZXMpCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogMHgwMDAwMDAwMDAwMTAwMDAwIC0gMHgwMDAwMDAwMDAwMWZmZmZm LCAxMDQ4NTc2IGJ5dGVzICgyNTYgcGFnZXMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogMHgwMDAwMDAwMDAyNzAwMDAwIC0gMHgwMDAwMDAwMGI1NzYzZmZmLCAzMDAzNTMxMjY0IGJ5 dGVzICg3MzMyODQgcGFnZXMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogMHgwMDAw MDAwMGJkYzI1MDAwIC0gMHgwMDAwMDAwMGJkZGFiZmZmLCAxNjAxNTM2IGJ5dGVzICgzOTEgcGFn ZXMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogMHgwMDAwMDAwMGJlMzlkMDAwIC0g MHgwMDAwMDAwMGJlOWZjZmZmLCA2Njg0NjcyIGJ5dGVzICgxNjMyIHBhZ2VzKQpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IDB4MDAwMDAwMDBiZWZmZDAwMCAtIDB4MDAwMDAwMDBiZWZm ZmZmZiwgMTIyODggYnl0ZXMgKDMgcGFnZXMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogMHgwMDAwMDAwMTAwMDAwMDAwIC0gMHgwMDAwMDAwMTFlZmU3ZmZmLCA1MTk5OTUzOTIgYnl0 ZXMgKDEyNjk1MiBwYWdlcykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhdmFpbCBt ZW1vcnkgPSAzNTE3MDc5NTUyICgzMzU0IE1CKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IE1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDAgQUNQSSBJRCAxOiBlbmFibGVkCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogU01QOiBBZGRlZCBDUFUgMCAoQVApCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMSBBQ1BJIElEIDI6 IGVuYWJsZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBTTVA6IEFkZGVkIENQVSAx IChBUCkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBNQURUOiBGb3VuZCBDUFUgQVBJ QyBJRCAyIEFDUEkgSUQgMzogZW5hYmxlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IFNNUDogQWRkZWQgQ1BVIDIgKEFQKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IE1B RFQ6IEZvdW5kIENQVSBBUElDIElEIDMgQUNQSSBJRCA0OiBlbmFibGVkCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogU01QOiBBZGRlZCBDUFUgMyAoQVApCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogRXZlbnQgdGltZXIgIkxBUElDIiBxdWFsaXR5IDYwMApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IExBUElDOiBpcGlfd2FpdCgpIHVzIG11bHRpcGxpZXIgMTYg KHIgMTI5ODA0MzQgdHNjIDIxOTU5MjEzODUpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogQUNQSSBBUElDIFRhYmxlOiA8REVMTCAgIENMMDkgICA+Ck1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogUGFja2FnZSBJRCBzaGlmdDogMwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IEwyIGNhY2hlIElEIHNoaWZ0OiAyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogTDEgY2FjaGUgSUQgc2hpZnQ6IDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBD b3JlIElEIHNoaWZ0OiAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogSU5UUjogQWRk aW5nIGxvY2FsIEFQSUMgMSBhcyBhIHRhcmdldApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IElOVFI6IEFkZGluZyBsb2NhbCBBUElDIDIgYXMgYSB0YXJnZXQKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAzIGFzIGEgdGFyZ2V0Ck1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29y IFN5c3RlbSBEZXRlY3RlZDogNCBDUFVzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog RnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDQgY29yZShzKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IFBhY2thZ2UgSFcgSUQgPSAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogCUNvcmUgSFcgSUQgPSAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCQlD UFUwIChCU1ApOiBBUElDIElEOiAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCUNv cmUgSFcgSUQgPSAxCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCQlDUFUxIChBUCk6 IEFQSUMgSUQ6IDEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJQ29yZSBIVyBJRCA9 IDIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJCUNQVTIgKEFQKTogQVBJQyBJRDog MgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlDb3JlIEhXIElEID0gMwpNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAkJQ1BVMyAoQVApOiBBUElDIElEOiAzCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogQVBJQzogQ1BVIDAgaGFzIEFDUEkgSUQgMQpNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IEFQSUM6IENQVSAxIGhhcyBBQ1BJIElEIDIKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBBUElDOiBDUFUgMiBoYXMgQUNQSSBJRCAzCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogQVBJQzogQ1BVIDMgaGFzIEFDUEkgSUQgNApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGxhcGljMDogTUNFIFRocmVzaG9sZGluZyBFTFZU IHVubWFza2VkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYW1kX3RocmVzaG9sZGlu Z19tb25pdG9yOiBTdGFydGluZyBBTUQgdGhyZXNob2xkaW5nIG9uIGJhbmsgNApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFBlbnRpdW0gUHJvIE1UUlIgc3VwcG9ydCBlbmFibGVkCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogeDg2YmlvczogIElWVCAweDAwMDAwMC0weDAw MDRmZiBhdCAweGZmZmZmODAwMDAwMDAwMDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiB4ODZiaW9zOiBTU0VHIDB4MDllMDAwLTB4MDllZmZmIGF0IDB4ZmZmZmZlMDAwMTVlMDAwMApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHg4NmJpb3M6ICBST00gMHgwYTAwMDAtMHgw ZmVmZmYgYXQgMHhmZmZmZjgwMDAwMGEwMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcmFuZG9tOiByZWdpc3RlcmluZyBmYXN0IHNvdXJjZSBJbnRlbCBTZWN1cmUgS2V5IFJORwpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHJhbmRvbTogZmFzdCBwcm92aWRlcjogIklu dGVsIFNlY3VyZSBLZXkgUk5HIgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHJhbmRv bTogcmVhZCA0MDk2IGJ5dGVzIGZyb20gcHJlbG9hZGVkIGNhY2hlCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogcmFuZG9tOiB1bmJsb2NraW5nIGRldmljZS4KTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBWSU1BR0UgKHZpcnR1YWxpemVkIG5ldHdvcmsgc3RhY2spIGVuYWJs ZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBob3N0dXVpZDogdXNpbmcgNGM0YzQ1 NDQtMDA1NC00NjEwLTgwMzQtYzhjMDRmNGQ0MzMyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogVUxFOiBzZXR1cCBjcHUgMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFVM RTogc2V0dXAgY3B1IDEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBVTEU6IHNldHVw IGNwdSAyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogVUxFOiBzZXR1cCBjcHUgMwpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IEFDUEk6IFJTRFAgMHgwMDAwMDAwMEJEN0FF MDAwIDAwMDAyNCAodjAyIERFTEwgICkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBB Q1BJOiBYU0RUIDB4MDAwMDAwMDBCRDdBRTA5OCAwMDAwQUMgKHYwMSBERUxMICAgQ0wwOSAgICAg MDEwNzIwMDkgQU1JICAwMDAxMDAxMykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBB Q1BJOiBGQUNQIDB4MDAwMDAwMDBCRDdCNjVDMCAwMDAxMEMgKHYwNSBERUxMICAgQ0wwOSAgICAg MDEwNzIwMDkgQU1JICAwMDAxMDAxMykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBG aXJtd2FyZSBXYXJuaW5nIChBQ1BJKTogT3B0aW9uYWwgRkFEVCBmaWVsZCBQbTJDb250cm9sQmxv Y2sgaGFzIHZhbGlkIExlbmd0aCBidXQgemVybyBBZGRyZXNzOiAweDAwMDAwMDAwMDAwMDAwMDAv MHgxICgyMDIwMDQzMC90YmZhZHQtNzk2KQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IEFDUEk6IERTRFQgMHgwMDAwMDAwMEJEN0FFMUQwIDAwODNFQSAodjAyIERFTEwgICBDTDA5ICAg ICAwMTA3MjAwOSBJTlRMIDIwMDYxMTA5KQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IEFDUEk6IEZBQ1MgMHgwMDAwMDAwMEJEOEFEQzgwIDAwMDA0MApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IEFQSUMgMHgwMDAwMDAwMEJEN0I2NkQwIDAwMDA3RSAodjAzIERF TEwgICBDTDA5ICAgICAwMTA3MjAwOSBBTUkgIDAwMDEwMDEzKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IEZQRFQgMHgwMDAwMDAwMEJEN0I2NzUwIDAwMDA0NCAodjAxIERF TEwgICBDTDA5ICAgICAwMTA3MjAwOSBBTUkgIDAwMDEwMDEzKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IEZJRFQgMHgwMDAwMDAwMEJEN0I2Nzk4IDAwMDA5QyAodjAxIERF TEwgICBDTDA5ICAgICAwMTA3MjAwOSBBTUkgIDAwMDEwMDEzKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IE1DRkcgMHgwMDAwMDAwMEJEN0I2ODM4IDAwMDAzQyAodjAxIERF TEwgICBDTDA5ICAgICAwMTA3MjAwOSBNU0ZUIDAwMDEwMDEzKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IEJPT1QgMHgwMDAwMDAwMEJEN0I2ODc4IDAwMDAyOCAodjAxIERF TEwgICBDTDA5ICAgICAwMTA3MjAwOSBBTUkgIDAwMDEwMDEzKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IFNMSUMgMHgwMDAwMDAwMEJEN0I2OEEwIDAwMDE3NiAodjAxIERF TEwgICBDTDA5ICAgICAwMTA3MjAwOSBBTUkgIDAwMDEwMDEzKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IEhQRVQgMHgwMDAwMDAwMEJEN0I2QTE4IDAwMDAzOCAodjAxIERF TEwgICBDTDA5ICAgICAwMTA3MjAwOSBBTUkgIDAwMDAwMDA1KQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IFVFRkkgMHgwMDAwMDAwMEJEN0I2QTUwIDAwMDA0MiAodjAxICAg ICAgICAgICAgICAgICAwMDAwMDAwMCAgICAgIDAwMDAwMDAwKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IE1TRE0gMHgwMDAwMDAwMEJEN0I2QTk4IDAwMDA1NSAodjAzIERF TEwgICBDTDA5ICAgICAwMTA3MjAwOSBBTUkgIDAwMDEwMDEzKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IFZGQ1QgMHgwMDAwMDAwMEJEN0I2QUYwIDAwRUM4NCAodjAxIERF TEwgICBDTDA5ICAgICAwMDAwMDAwMSBBTUQgIDMxNTA0RjQ3KQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IEJHUlQgMHgwMDAwMDAwMEJEN0M1Nzc4IDAwMDAzOCAodjAxIERF TEwgICBDTDA5ICAgICAwMTA3MjAwOSBBTUkgIDAwMDEwMDEzKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IFNTRFQgMHgwMDAwMDAwMEJEN0M1N0IwIDAwMENCNCAodjAxIEFN RCAgICBBR0VTQSAgICAwMDAwMDAwMSBBTUQgIDAwMDAwMDAxKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IFNTRFQgMHgwMDAwMDAwMEJEN0M2NDY4IDAwNDhDRSAodjAyIEFN RCAgICBBR0VTQSAgICAwMDAwMDAwMiBNU0ZUIDA0MDAwMDAwKQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IFNTRFQgMHgwMDAwMDAwMEJEN0NBRDM4IDAwMDY5MiAodjAxIEFN RCAgICBDUE1BRFBTNCAwMDAwMDAwMSBJTlRMIDIwMDYxMTA5KQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IFNTRFQgMHgwMDAwMDAwMEJEN0NCM0QwIDAwMTVBOSAodjAxIEFN RCAgICBDUE1DTU4gICAwMDAwMDAwMSBJTlRMIDIwMDYxMTA5KQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEFDUEk6IFNTRFQgMHgwMDAwMDAwMEJEN0NDOTgwIDAwMTQ3RiAodjAxIEFN RCAgICBDUE1ERklHUCAwMDAwMDAwMSBJTlRMIDIwMDYxMTA5KQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IE1BRFQ6IEZvdW5kIElPIEFQSUMgSUQgNSwgSW50ZXJydXB0IDAgYXQgMHhm ZWMwMDAwMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGlvYXBpYzA6IHZlciAweDIx IG1heHJlZGlyIDB4MTcKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBpb2FwaWMwOiBS b3V0aW5nIGV4dGVybmFsIDgyNTlBJ3MgLT4gaW50cGluIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBNQURUOiBGb3VuZCBJTyBBUElDIElEIDYsIEludGVycnVwdCAyNCBhdCAweGZl YzAxMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaW9hcGljMTogdmVyIDB4MjEg bWF4cmVkaXIgMHgxZgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGxhcGljOiBSb3V0 aW5nIE5NSSAtPiBMSU5UMQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGxhcGljOiBM SU5UMSB0cmlnZ2VyOiBlZGdlCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogbGFwaWM6 IExJTlQxIHBvbGFyaXR5OiBoaWdoCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogTUFE VDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwgaXJxIDIKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBpb2FwaWMwOiBSb3V0aW5nIElSUSAwIC0+IGludHBpbiAyCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2Ug OSwgaXJxIDkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBpb2FwaWMwOiBpbnRwaW4g OSB0cmlnZ2VyOiBsZXZlbApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGlvYXBpYzA6 IGludHBpbiA5IHBvbGFyaXR5OiBsb3cKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBp b2FwaWMwIDxWZXJzaW9uIDIuMT4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogaW9hcGljMSA8VmVyc2lvbiAyLjE+IGlycXMgMjQtNTUgb24g bW90aGVyYm9hcmQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBsYXBpYzogRGl2aXNv ciAyLCBGcmVxdWVuY3kgNDk5MDczMDEgSHoKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBjcHUwIEJTUDoKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgICAgIElEOiAweDAw MDAwMDAwICAgVkVSOiAweDgwMDUwMDEwIExEUjogMHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQx OiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiAgIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAw IGVycjogMHgwMDAwMDBmMCBwbWM6IDB4MDAwMTA0MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiAgICBBTUQgZXh0IGZlYXR1cmVzOiAweDAwMDQwMDA3Ck1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQwOiAweDAwMDEwMDAwCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQxOiAweDAwMDAwMGYyCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQyOiAweDAwMDEwMDAwCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQzOiAweDAwMDEwMDAwCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQhCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogY3B1MSBBUDoKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAg ICAgIElEOiAweDAxMDAwMDAwICAgVkVSOiAweDgwMDUwMDEwIExEUjogMHgwMDAwMDAwMCBERlI6 IDB4ZmZmZmZmZmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIGxpbnQwOiAweDAw MDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJt OiAweDAwMDEwMDAwIGVycjogMHgwMDAwMDBmMCBwbWM6IDB4MDAwMTA0MDAKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiAgICBBTUQgZXh0IGZlYXR1cmVzOiAweDAwMDQwMDA3Ck1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQwOiAweDAwMDEwMDAwCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQxOiAweDAwMDEwMDAwCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQyOiAweDAwMDEwMDAwCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQzOiAweDAwMDEwMDAwCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogU01QOiBBUCBDUFUgIzIgTGF1bmNoZWQhCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3B1MiBBUDoKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiAgICAgIElEOiAweDAyMDAwMDAwICAgVkVSOiAweDgwMDUwMDEwIExEUjogMHgw MDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAg IGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6 IDB4MDAwMDAxZmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIHRpbWVyOiAweDAw MDEwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAwMDBmMCBwbWM6IDB4MDAwMTA0MDAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgICBBTUQgZXh0IGZlYXR1cmVzOiAweDAw MDQwMDA3Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQwOiAweDAw MDEwMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQxOiAweDAw MDEwMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQyOiAweDAw MDEwMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1EIGVsdnQzOiAweDAw MDEwMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogU01QOiBBUCBDUFUgIzMgTGF1 bmNoZWQhCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3B1MyBBUDoKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgICAgIElEOiAweDAzMDAwMDAwICAgVkVSOiAweDgwMDUw MDEwIExEUjogMHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiAgIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgw MDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAg IHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAwMDBmMCBwbWM6 IDB4MDAwMTA0MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgICBBTUQgZXh0IGZl YXR1cmVzOiAweDAwMDQwMDA3Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1E IGVsdnQwOiAweDAwMDEwMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1E IGVsdnQxOiAweDAwMDEwMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1E IGVsdnQyOiAweDAwMDEwMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICAgQU1E IGVsdnQzOiAweDAwMDEwMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogU01QOiBw YXNzZWQgVFNDIHN5bmNocm9uaXphdGlvbiB0ZXN0Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogVFNDIHRpbWVjb3VudGVyIGRpc2NhcmRzIGxvd2VyIDEgYml0KHMpCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogVGltZWNvdW50ZXIgIlRTQy1sb3ciIGZyZXF1ZW5jeSAxMDk3 OTYwNjkyIEh6IHF1YWxpdHkgMTAwMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHJh bmRvbTogZW50cm9weSBkZXZpY2UgZXh0ZXJuYWwgaW50ZXJmYWNlCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPgpNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IHNuZF91bml0X2luaXQoKSB1PTB4MDBmZjgwMDAgWzUxMl0gZD0weDAw MDA3YzAwIFszMl0gYz0weDAwMDAwM2ZmIFsxMDI0XQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IGZlZWRlcl9yZWdpc3Rlcjogc25kX3VuaXQ9LTEgc25kX21heGF1dG92Y2hhbnM9MTYg bGF0ZW5jeT0yIGZlZWRlcl9yYXRlX21pbj0xIGZlZWRlcl9yYXRlX21heD0yMDE2MDAwIGZlZWRl cl9yYXRlX3JvdW5kPTI1Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogV0FSTklORzog RGV2aWNlICJnX2N0bCIgaXMgR2lhbnQgbG9ja2VkIGFuZCBtYXkgYmUgZGVsZXRlZCBiZWZvcmUg RnJlZUJTRCAxNC4wLgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IG1lbTogPG1lbW9y eT4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAwMDAuMDAwMDE5IFs0MzQ0XSBuZXRt YXBfaW5pdCAgICAgICAgICAgICAgIG5ldG1hcDogbG9hZGVkIG1vZHVsZQpNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IG51bGw6IDxmdWxsIGRldmljZSwgbnVsbCBkZXZpY2UsIHplcm8g ZGV2aWNlPgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFdBUk5JTkc6IERldmljZSAi cGNpIiBpcyBHaWFudCBsb2NrZWQgYW5kIG1heSBiZSBkZWxldGVkIGJlZm9yZSBGcmVlQlNEIDE0 LjAuCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2F0aF9oYWxdIGxvYWRlZApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IG5mc2xvY2s6IHBzZXVkby1kZXZpY2UKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBjcnlwdG86IDxjcnlwdG8gY29yZT4KTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiB0Y3BfbG9nOiB0Y3BfbG9nIGRldmljZQpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IG1vZHVsZV9yZWdpc3Rlcl9pbml0OiBNT0RfTE9BRCAodmVz YSwgMHhmZmZmZmZmZjgxMTgxMTMwLCAwKSBlcnJvciAxOQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IGlvOiA8SS9PPgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGtiZDog bmV3IGFycmF5IHNpemUgNApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFdBUk5JTkc6 IERldmljZSAia2JkIiBpcyBHaWFudCBsb2NrZWQgYW5kIG1heSBiZSBkZWxldGVkIGJlZm9yZSBG cmVlQlNEIDE0LjAuCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDoga2JkMSBhdCBrYmRt dXgwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2F0aF9kZnNdIGxvYWRlZApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFthdGhfcmF0ZV0gbG9hZGVkCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogW2FyOTMwMF0gbG9hZGVkCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogW2FyNTIxMl0gbG9hZGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogW2FyNTQxNl0gbG9hZGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2FyNTIx MV0gbG9hZGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2FyNTIxMF0gbG9hZGVk Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2F0aF0gbG9hZGVkCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogbWx4NWVuOiBNZWxsYW5veCBFdGhlcm5ldCBkcml2ZXIgMy42 LjAgKERlY2VtYmVyIDIwMjApCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaHB0bnI6 IFI3NTAvREM3MjgwIGNvbnRyb2xsZXIgZHJpdmVyIHYxLjEuNQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IGhwdHJyOiBSb2NrZXRSQUlEIDE3eHgvMnh4eCBTQVRBIGNvbnRyb2xsZXIg ZHJpdmVyIHYxLjIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBocHQyN3h4OiBSb2Nr ZXRSQUlEIDI3eHggY29udHJvbGxlciBkcml2ZXIgdjEuMi44Ck1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogbmV4dXMwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogZWZpcnRj MDogPEVGSSBSZWFsdGltZSBDbG9jaz4gb24gbW90aGVyYm9hcmQKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBlZmlydGMwOiByZWdpc3RlcmVkIGFzIGEgdGltZS1vZi1kYXkgY2xvY2ss IHJlc29sdXRpb24gMS4wMDAwMDBzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3J5 cHRvc29mdDA6IDxzb2Z0d2FyZSBjcnlwdG8+IG9uIG1vdGhlcmJvYXJkCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogY3J5cHRvOiBhc3NpZ24gY3J5cHRvc29mdDAgZHJpdmVyIGlkIDAs IGZsYWdzIDB4NjAwMDAwMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNyeXB0bzog Y3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAxIGZsYWdzIDAgbWF4b3BsZW4gMApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAy IGZsYWdzIDAgbWF4b3BsZW4gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNyeXB0 bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAzIGZsYWdzIDAgbWF4b3BsZW4gMApNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFs ZyA0IGZsYWdzIDAgbWF4b3BsZW4gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNy eXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyA1IGZsYWdzIDAgbWF4b3BsZW4gMApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJz IGFsZyAxNiBmbGFncyAwIG1heG9wbGVuIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgNiBmbGFncyAwIG1heG9wbGVuIDAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lz dGVycyBhbGcgNyBmbGFncyAwIG1heG9wbGVuIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMzIgZmxhZ3MgMCBtYXhvcGxl biAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3J5cHRvOiBjcnlwdG9zb2Z0MCBy ZWdpc3RlcnMgYWxnIDE4IGZsYWdzIDAgbWF4b3BsZW4gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IGNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAxOSBmbGFncyAwIG1h eG9wbGVuIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBjcnlwdG86IGNyeXB0b3Nv ZnQwIHJlZ2lzdGVycyBhbGcgMjAgZmxhZ3MgMCBtYXhvcGxlbiAwCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDggZmxhZ3Mg MCBtYXhvcGxlbiAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3J5cHRvOiBjcnlw dG9zb2Z0MCByZWdpc3RlcnMgYWxnIDE1IGZsYWdzIDAgbWF4b3BsZW4gMApNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IGNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyA5IGZs YWdzIDAgbWF4b3BsZW4gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNyeXB0bzog Y3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAxMCBmbGFncyAwIG1heG9wbGVuIDAKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiBjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcg MTMgZmxhZ3MgMCBtYXhvcGxlbiAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3J5 cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDE0IGZsYWdzIDAgbWF4b3BsZW4gMApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJz IGFsZyAzNCBmbGFncyAwIG1heG9wbGVuIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMzUgZmxhZ3MgMCBtYXhvcGxlbiAw Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdp c3RlcnMgYWxnIDM2IGZsYWdzIDAgbWF4b3BsZW4gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IGNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAzNyBmbGFncyAwIG1heG9w bGVuIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBjcnlwdG86IGNyeXB0b3NvZnQw IHJlZ2lzdGVycyBhbGcgMTEgZmxhZ3MgMCBtYXhvcGxlbiAwCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDIyIGZsYWdzIDAg bWF4b3BsZW4gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNyeXB0bzogY3J5cHRv c29mdDAgcmVnaXN0ZXJzIGFsZyAyMyBmbGFncyAwIG1heG9wbGVuIDAKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMjUgZmxh Z3MgMCBtYXhvcGxlbiAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3J5cHRvOiBj cnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDI0IGZsYWdzIDAgbWF4b3BsZW4gMApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAy NiBmbGFncyAwIG1heG9wbGVuIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBjcnlw dG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMjcgZmxhZ3MgMCBtYXhvcGxlbiAwCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMg YWxnIDI4IGZsYWdzIDAgbWF4b3BsZW4gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IGNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAyMSBmbGFncyAwIG1heG9wbGVuIDAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lz dGVycyBhbGcgMTcgZmxhZ3MgMCBtYXhvcGxlbiAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDI5IGZsYWdzIDAgbWF4b3Bs ZW4gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNyeXB0bzogY3J5cHRvc29mdDAg cmVnaXN0ZXJzIGFsZyAzMCBmbGFncyAwIG1heG9wbGVuIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMzEgZmxhZ3MgMCBt YXhvcGxlbiAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3J5cHRvOiBjcnlwdG9z b2Z0MCByZWdpc3RlcnMgYWxnIDQwIGZsYWdzIDAgbWF4b3BsZW4gMApNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IGNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAzOSBmbGFn cyAwIG1heG9wbGVuIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBjcnlwdG86IGNy eXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMzggZmxhZ3MgMCBtYXhvcGxlbiAwCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogYWNwaTA6IDxERUxMIENMMDkgICA+IG9uIG1vdGhlcmJvYXJk Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogQUNQSTogNiBBQ1BJIEFNTCB0YWJsZXMg c3VjY2Vzc2Z1bGx5IGFjcXVpcmVkIGFuZCBsb2FkZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBQQ0llOiBNZW1vcnkgTWFwcGVkIGNvbmZpZ3VyYXRpb24gYmFzZSBAIDB4ZjgwMDAw MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBpb2FwaWMwOiByb3V0aW5nIGludHBp biA5IChJU0EgSVJRIDkpIHRvIGxhcGljIDAgdmVjdG9yIDQ4Ck1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogYWNwaTA6IHdha2V1cCBjb2RlIHZhIDB4ZmZmZmZlMDAwMTVmZjAwMCBw YSAweDljMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3B1MDogUHJvY2Vzc29y IFxfUFJfLlAwMDAgKEFDUEkgSUQgMSkgLT4gQVBJQyBJRCAwCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IGNwdTE6IFByb2Nlc3NvciBcX1BSXy5QMDAxIChBQ1BJIElEIDIpIC0+IEFQ SUMgSUQgMQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGNwdTE6IDxBQ1BJIENQVT4g b24gYWNwaTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBjcHUyOiBQcm9jZXNzb3Ig XF9QUl8uUDAwMiAoQUNQSSBJRCAzKSAtPiBBUElDIElEIDIKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBjcHUyOiA8QUNQSSBDUFU+IG9uIGFjcGkwCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogY3B1MzogUHJvY2Vzc29yIFxfUFJfLlAwMDMgKEFDUEkgSUQgNCkgLT4gQVBJ QyBJRCAzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogY3B1MzogPEFDUEkgQ1BVPiBv biBhY3BpMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhwZXQwOiA8SGlnaCBQcmVj aXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBpcnEgMCw4IG9u IGFjcGkwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaHBldDA6IHZlbmRvciAweDEw MjIsIHJldiAweDEsIDE0MzE4MTgwSHosIDMgdGltZXJzLCBsZWdhY3kgcm91dGUKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiBocGV0MDogIHQwOiBpcnFzIDB4MDBjMDAwMDAgKDApLCBw ZXJpb2RpYwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhwZXQwOiAgdDE6IGlycXMg MHgwMGMwMDAwMCAoMCksIHBlcmlvZGljCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog aHBldDA6ICB0MjogaXJxcyAweDAwYzAwMDAwICgwKSwgcGVyaW9kaWMKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBUaW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6 IHF1YWxpdHkgOTUwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXR0aW1lcjA6IDxB VCB0aW1lcj4gcG9ydCAweDQwLTB4NDMgaXJxIDAgb24gYWNwaTAKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1 YWxpdHkgMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGlvYXBpYzA6IHJvdXRpbmcg aW50cGluIDIgKElTQSBJUlEgMCkgdG8gbGFwaWMgMSB2ZWN0b3IgNDgKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBFdmVudCB0aW1lciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6 IHF1YWxpdHkgMTAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRydGMwOiA8QVQg cmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIG9uIGFjcGkwCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogYXRydGMwOiByZWdpc3RlcmVkIGFzIGEgdGltZS1vZi1kYXkgY2xvY2ss IHJlc29sdXRpb24gMS4wMDAwMDBzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaW9h cGljMDogcm91dGluZyBpbnRwaW4gOCAoSVNBIElSUSA4KSB0byBsYXBpYyAyIHZlY3RvciA0OApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDgg KElTQSBJUlEgOCkgdG8gbGFwaWMgMCB2ZWN0b3IgNDkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBFdmVudCB0aW1lciAiUlRDIiBmcmVxdWVuY3kgMzI3NjggSHogcXVhbGl0eSAwCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogQUNQSSB0aW1lcjogMS8xIDEvMSAwLzggMS8x IDEvMSAxLzEgMS8xIDAvOCAxLzEgMS8xIC0+IDgKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBUaW1lY291bnRlciAiQUNQSS1zYWZlIiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5 IDg1MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFjcGlfdGltZXIwOiA8MzItYml0 IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ODA4LTB4ODBiIG9uIGFjcGkwCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogYWNwaV9lYzA6IDxFbWJlZGRlZCBDb250cm9sbGVyOiBH UEUgMHgzPiBwb3J0IDB4NjIsMHg2NiBvbiBhY3BpMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBjaV9saW5rMDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDQgNSA3IDEwIDExIDE0IDE1Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDQgNSA3IDEwIDExIDE0 IDE1Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICBBZnRlciBEaXNhYmxlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDQgNSA3IDEwIDExIDE0IDE1Ck1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogcGNpX2xpbmsxOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIEluaXRpYWwgUHJvYmUgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgNCA1IDcgMTAgMTEgMTQgMTUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiAgIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNCA1IDcgMTAg MTEgMTQgMTUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIEFmdGVyIERpc2FibGUg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNCA1IDcgMTAgMTEgMTQgMTUKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBwY2lfbGluazI6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6ICAgSW5pdGlhbCBQcm9iZSAgICAg ICAwICAyNTUgICBOICAgICAwICA0IDUgNyAxMCAxMSAxNCAxNQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6ICAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICA0IDUg NyAxMCAxMSAxNCAxNQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6ICAgQWZ0ZXIgRGlz YWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICA0IDUgNyAxMCAxMSAxNCAxNQpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaV9saW5rMzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICBJbml0aWFsIFByb2Jl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDQgNSA3IDEwIDExIDE0IDE1Ck1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDQgNSA3IDEwIDExIDE0IDE1Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICBBZnRl ciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDQgNSA3IDEwIDExIDE0IDE1Ck1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpX2xpbms0OiAgICAgICAgSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIEluaXRpYWwg UHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNCA1IDcgMTAgMTEgMTQgMTUKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgNCA1IDcgMTAgMTEgMTQgMTUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAg IEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNCA1IDcgMTAgMTEgMTQgMTUK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2lfbGluazU6ICAgICAgICBJbmRleCAg SVJRICBSdGQgIFJlZiAgSVJRcwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6ICAgSW5p dGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICA0IDUgNyAxMCAxMSAxNCAxNQpNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6ICAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUg ICBOICAgICAwICA0IDUgNyAxMCAxMSAxNCAxNQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6ICAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICA0IDUgNyAxMCAxMSAx NCAxNQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaV9saW5rNjogICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog ICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDQgNSA3IDEwIDExIDE0IDE1 Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogICBWYWxpZGF0aW9uICAgICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDQgNSA3IDEwIDExIDE0IDE1Ck1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDQgNSA3IDEw IDExIDE0IDE1Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpX2xpbms3OiAgICAg ICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiAgIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNCA1IDcgMTAgMTEg MTQgMTUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAgIFZhbGlkYXRpb24gICAgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgNCA1IDcgMTAgMTEgMTQgMTUKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiAgIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNCA1 IDcgMTAgMTEgMTQgMTUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogPEFD UEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGRlY29kaW5nIDUgcmFuZ2UgMC0weGZmCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGRlY29kaW5nIDQgcmFuZ2UgMC0weDNh ZgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBkZWNvZGluZyA0IHJhbmdl IDB4M2UwLTB4Y2Y3Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGRlY29k aW5nIDQgcmFuZ2UgMHgzYjAtMHgzZGYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBw Y2liMDogZGVjb2RpbmcgNCByYW5nZSAweGQwMC0weGZmZmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBwY2liMDogZGVjb2RpbmcgMyByYW5nZSAweGEwMDAwLTB4YmZmZmYKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogZGVjb2RpbmcgMyByYW5nZSAweGMwMDAw LTB4ZGZmZmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogZGVjb2Rpbmcg MyByYW5nZSAweGUwMDAwMDAwLTB4ZmVkM2ZmZmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBwY2liMDogZGVjb2RpbmcgMyByYW5nZSAweGZlZDQ1MDAwLTB4ZmZmZmZmZmYKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaTA6IGRvbWFpbj0wLCBwaHlzaWNhbCBi dXM9MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAy MiwgZGV2PTB4MTU2NiwgcmV2aWQ9MHgwMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IAlkb21haW49MCwgYnVzPTAsIHNsb3Q9MCwgZnVuYz0wCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJY21kcmVnPTB4MDAwNCwgc3RhdHJlZz0weDAwMDAsIGNh Y2hlbG5zej0wIChkd29yZHMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWxhdHRp bWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2 PTB4OTg1MSwgcmV2aWQ9MHg0NQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlkb21h aW49MCwgYnVzPTAsIHNsb3Q9MSwgZnVuYz0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiAJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z ej0wIChkd29yZHMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlpbnRwaW49YSwgaXJxPTI1NQpNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IAlwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1 cnJlbnQgRDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJTVNJIHN1cHBvcnRzIDEg bWVzc2FnZSwgNjQgYml0Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCW1hcFsxMF06 IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhlMDAwMDAwMCwgc2l6 ZSAyOCwgZW5hYmxlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGUwMDAwMDAwLTB4ZWZmZmZmZmYpIGZvciByaWQgMTAgb2YgcGNpMDow OjE6MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAltYXBbMThdOiB0eXBlIFByZWZl dGNoYWJsZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZjAwMDAwMDAsIHNpemUgMjMsIGVuYWJs ZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhmMDAwMDAwMC0weGYwN2ZmZmZmKSBmb3IgcmlkIDE4IG9mIHBjaTA6MDoxOjAKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2Ug MzIsIGJhc2UgMHhmMDAwLCBzaXplICA4LCBlbmFibGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4ZjAwMC0weGYwZmYpIGZvciByaWQg MjAgb2YgcGNpMDowOjE6MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAltYXBbMjRd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZWIwMDAwMCwgc2l6ZSAxOCwgZW5hYmxl ZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGZlYjAwMDAwLTB4ZmViM2ZmZmYpIGZvciByaWQgMjQgb2YgcGNpMDowOjE6MApNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4OTg0 MCwgcmV2aWQ9MHgwMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlkb21haW49MCwg YnVzPTAsIHNsb3Q9MSwgZnVuYz0xCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWNs YXNzPTA0LTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiAJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChk d29yZHMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWxhdHRpbWVyPTB4MDAgKDAg bnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IAlpbnRwaW49YiwgaXJxPTI1NQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IAlwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQg RDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJTVNJIHN1cHBvcnRzIDEgbWVzc2Fn ZSwgNjQgYml0Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCW1hcFsxMF06IHR5cGUg TWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGZlYjY0MDAwLCBzaXplIDE0LCBtZW1vcnkgZGlzYWJs ZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhmZWI2NDAwMC0weGZlYjY3ZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6MDoxOjEKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDE1 NmIsIHJldmlkPTB4MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJZG9tYWluPTAs IGJ1cz0wLCBzbG90PTIsIGZ1bmM9MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlj bGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDAwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDE0MzksIHJl dmlkPTB4MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJZG9tYWluPTAsIGJ1cz0w LCBzbG90PTIsIGZ1bmM9MQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAljbGFzcz0w Ni0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdvcmRz KQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiAJaW50cGluPWEsIGlycT0yNTUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiAJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlzZWNidXM9MSwgc3ViYnVzPTEKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDE0 MzksIHJldmlkPTB4MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJZG9tYWluPTAs IGJ1cz0wLCBzbG90PTIsIGZ1bmM9MgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlj bGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiAJaW50cGluPWIsIGlycT0yNTUKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiAJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0 IGJpdApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlzZWNidXM9Miwgc3ViYnVzPTIK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRl dj0weDE0MzksIHJldmlkPTB4MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTIsIGZ1bmM9MwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IAljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlsYXR0aW1lcj0w eDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJaW50cGluPWMsIGlycT0yNTUKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiAJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50 IEQwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCU1TSSBzdXBwb3J0cyAxIG1lc3Nh Z2UsIDY0IGJpdApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlzZWNidXM9Mywgc3Vi YnVzPTMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEw MjIsIGRldj0weDE1MzcsIHJldmlkPTB4MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiAJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTgsIGZ1bmM9MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IAljbGFzcz0xMC04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMDEwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlsYXR0 aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQw IEQzICBjdXJyZW50IEQwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCU1TSS1YIHN1 cHBvcnRzIDIgbWVzc2FnZXMgaW4gbWFwIDB4MjQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiAJbWFwWzEwXTogdHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAw eGYwOTAwMDAwLCBzaXplIDE3LCBlbmFibGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjA5MDAwMDAtMHhmMDkxZmZmZikgZm9yIHJp ZCAxMCBvZiBwY2kwOjA6ODowCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCW1hcFsx OF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZlODAwMDAwLCBzaXplIDIwLCBlbmFi bGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4ZmU4MDAwMDAtMHhmZThmZmZmZikgZm9yIHJpZCAxOCBvZiBwY2kwOjA6ODowCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCW1hcFsxY106IHR5cGUgTWVtb3J5LCByYW5nZSAz MiwgYmFzZSAweGZlYjcwMDAwLCBzaXplIDEyLCBlbmFibGVkCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZmViNzAwMDAtMHhmZWI3MGZm ZikgZm9yIHJpZCAxYyBvZiBwY2kwOjA6ODowCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogCW1hcFsyNF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZlYjZhMDAwLCBzaXpl IDEzLCBlbmFibGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4ZmViNmEwMDAtMHhmZWI2YmZmZikgZm9yIHJpZCAyNCBvZiBwY2kwOjA6 ODowCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9MHgxMDIy LCBkZXY9MHg3ODE0LCByZXZpZD0weDExCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xNiwgZnVuYz0wCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogCWNsYXNzPTBjLTAzLTMwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAwMTAsIGNh Y2hlbG5zej0wIChkd29yZHMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWxhdHRp bWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlpbnRwaW49YSwgaXJxPTI1NQpNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJTVNJIHN1cHBvcnRzIDgg bWVzc2FnZXMsIDY0IGJpdApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlNU0ktWCBz dXBwb3J0cyA4IG1lc3NhZ2VzIGluIG1hcCAweDEwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGZlYjY4MDAwLCBz aXplIDEzLCBlbmFibGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4ZmViNjgwMDAtMHhmZWI2OWZmZikgZm9yIHJpZCAxMCBvZiBwY2kw OjA6MTY6MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4 MTAyMiwgZGV2PTB4NzgwMSwgcmV2aWQ9MHgzOQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IAlkb21haW49MCwgYnVzPTAsIHNsb3Q9MTcsIGZ1bmM9MApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IAljbGFzcz0wMS0wNi0wMSwgaGRydHlwZT0weDAwLCBtZmRldj0wCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjMw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAls YXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlpbnRwaW49YSwgaXJxPTI1NQpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJTVNJIHN1cHBv cnRzIDggbWVzc2FnZXMsIDY0IGJpdApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlt YXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGYxNDAsIHNpemUgIDMsIGVu YWJsZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5 cGUgNCAoMHhmMTQwLTB4ZjE0NykgZm9yIHJpZCAxMCBvZiBwY2kwOjA6MTc6MApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAltYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwg YmFzZSAweGYxMzAsIHNpemUgIDIsIGVuYWJsZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhmMTMwLTB4ZjEzMykgZm9yIHJpZCAxNCBv ZiBwY2kwOjA6MTc6MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAltYXBbMThdOiB0 eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGYxMjAsIHNpemUgIDMsIGVuYWJsZWQKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhm MTIwLTB4ZjEyNykgZm9yIHJpZCAxOCBvZiBwY2kwOjA6MTc6MApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IAltYXBbMWNdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGYx MTAsIHNpemUgIDIsIGVuYWJsZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2li MDogYWxsb2NhdGVkIHR5cGUgNCAoMHhmMTEwLTB4ZjExMykgZm9yIHJpZCAxYyBvZiBwY2kwOjA6 MTc6MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAltYXBbMjBdOiB0eXBlIEkvTyBQ b3J0LCByYW5nZSAzMiwgYmFzZSAweGYxMDAsIHNpemUgIDQsIGVuYWJsZWQKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhmMTAwLTB4ZjEw ZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6MTc6MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IAltYXBbMjRdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZWI2ZjAwMCwgc2l6 ZSAxMCwgZW5hYmxlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGZlYjZmMDAwLTB4ZmViNmYzZmYpIGZvciByaWQgMjQgb2YgcGNpMDow OjE3OjAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEw MjIsIGRldj0weDc4MDgsIHJldmlkPTB4MzkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiAJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE4LCBmdW5jPTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiAJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MApNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDJiMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJbGF0 dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJaW50cGluPWEsIGlycT0yNTUKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQx IEQyIEQzICBjdXJyZW50IEQwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCW1hcFsx MF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZlYjZlMDAwLCBzaXplICA4LCBlbmFi bGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4ZmViNmUwMDAtMHhmZWI2ZTBmZikgZm9yIHJpZCAxMCBvZiBwY2kwOjA6MTg6MApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGVoY2kgZWFybHk6IFNNTSBhY3RpdmUsIHJlcXVl c3Qgb3duZXIgY2hhbmdlCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogZm91bmQtPgl2 ZW5kb3I9MHgxMDIyLCBkZXY9MHg3ODA4LCByZXZpZD0weDM5Ck1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xOSwgZnVuYz0wCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogCWNsYXNzPTBjLTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJY21kcmVnPTB4MDAwNywgc3RhdHJl Zz0weDAyYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWludHBpbj1hLCBp cnE9MjU1Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IAltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZWI2ZDAwMCwgc2l6 ZSAgOCwgZW5hYmxlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGZlYjZkMDAwLTB4ZmViNmQwZmYpIGZvciByaWQgMTAgb2YgcGNpMDow OjE5OjAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBlaGNpIGVhcmx5OiBTTU0gYWN0 aXZlLCByZXF1ZXN0IG93bmVyIGNoYW5nZQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4NzgwYiwgcmV2aWQ9MHg0MgpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlkb21haW49MCwgYnVzPTAsIHNsb3Q9MjAsIGZ1bmM9MApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAljbGFzcz0wYy0wNS0wMCwgaGRydHlwZT0w eDAwLCBtZmRldj0xCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWNtZHJlZz0weDA0 MDMsIHN0YXRyZWc9MHgwMjIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQpNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IAlsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBmb3Vu ZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDc4MGQsIHJldmlkPTB4MDIKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiAJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIwLCBmdW5jPTIKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJY2xhc3M9MDQtMDMtMDAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAljbWRyZWc9MHgwMDA2LCBz dGF0cmVnPTB4MDQxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiAJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJaW50cGlu PWEsIGlycT0yNTUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJcG93ZXJzcGVjIDIg IHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGZlYjYwMDAwLCBzaXpl IDE0LCBlbmFibGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4ZmViNjAwMDAtMHhmZWI2M2ZmZikgZm9yIHJpZCAxMCBvZiBwY2kwOjA6 MjA6MgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAy MiwgZGV2PTB4NzgwZSwgcmV2aWQ9MHgxMQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IAlkb21haW49MCwgYnVzPTAsIHNsb3Q9MjAsIGZ1bmM9MwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IAljbGFzcz0wNi0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogCWNtZHJlZz0weDAwMGYsIHN0YXRyZWc9MHgwMjIwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlsYXR0 aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRl dj0weDc4MTMsIHJldmlkPTB4MDEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTIwLCBmdW5jPTcKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiAJY2xhc3M9MDgtMDUtMDEsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQpNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IAljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDIzMCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJbGF0dGltZXI9 MHgyNyAoMTE3MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWludHBpbj1hLCBpcnE9MjU1Ck1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3Vy cmVudCBEMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlNU0kgc3VwcG9ydHMgMSBt ZXNzYWdlLCA2NCBiaXQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJbWFwWzEwXTog dHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmViNmMwMDAsIHNpemUgIDgsIG1lbW9yeSBk aXNhYmxlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGZlYjZjMDAwLTB4ZmViNmMwZmYpIGZvciByaWQgMTAgb2YgcGNpMDowOjIwOjcK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRl dj0weDE1ODAsIHJldmlkPTB4MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTI0LCBmdW5jPTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiAJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQpNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IAljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVs bnN6PTAgKGR3b3JkcykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgx NTgxLCByZXZpZD0weDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWRvbWFpbj0w LCBidXM9MCwgc2xvdD0yNCwgZnVuYz0xCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog CWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiAJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0w IChkd29yZHMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTU4Miwg cmV2aWQ9MHgwMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlkb21haW49MCwgYnVz PTAsIHNsb3Q9MjQsIGZ1bmM9MgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAljbGFz cz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDAwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDE1ODMsIHJldmlk PTB4MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJZG9tYWluPTAsIGJ1cz0wLCBz bG90PTI0LCBmdW5jPTMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJY2xhc3M9MDYt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IAljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxNTg0LCByZXZpZD0weDAw Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0y NCwgZnVuYz00Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWNsYXNzPTA2LTAwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJ Y21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4MTAyMiwgZGV2PTB4MTU4NSwgcmV2aWQ9MHgwMApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1 bmM9NQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAljbGFzcz0wNi0wMC0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0xCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWNtZHJl Zz0weDAwMDAsIHN0YXRyZWc9MHgwMDAwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiB2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweGYwMDAtMHhmMGZmIG1l bSAweGUwMDAwMDAwLTB4ZWZmZmZmZmYsMHhmMDAwMDAwMC0weGYwN2ZmZmZmLDB4ZmViMDAwMDAt MHhmZWIzZmZmZiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiB2Z2FwY2kwOiBCb290IHZpZGVvIGRldmljZQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IGhkYWMwOiA8QVRJICgweDk4NDApIEhEQSBDb250cm9sbGVyPiBtZW0gMHhmZWI2 NDAwMC0weGZlYjY3ZmZmIGF0IGRldmljZSAxLjEgb24gcGNpMApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IGhkYWMwOiBQQ0kgY2FyZCB2ZW5kb3I6IDB4MTAyOCwgZGV2aWNlOiAweDA2 YmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFjMDogSERBIERyaXZlciBSZXZp c2lvbjogMjAxMjAxMjZfMDAwMgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWMw OiBDb25maWcgb3B0aW9uczogb249MHgwMDAwMDAwMCBvZmY9MHgwMDAwMDAwMApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWMwOiBhdHRlbXB0aW5nIHRvIGFsbG9jYXRlIDEgTVNJ IHZlY3RvcnMgKDEgc3VwcG9ydGVkKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IG1z aTogcm91dGluZyBNU0kgSVJRIDI1NiB0byBsb2NhbCBBUElDIDMgdmVjdG9yIDQ4Ck1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYzA6IHVzaW5nIElSUSAyNTYgZm9yIE1TSQpNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWMwOiBDYXBzOiBPU1MgMiwgSVNTIDAsIEJT UyAwLCBOU0RPIDIsIDY0Yml0LCBDT1JCIDI1NiwgUklSQiAyNTYKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyLjEg b24gcGNpMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIxOiBhdHRlbXB0aW5n IHRvIGFsbG9jYXRlIDEgTVNJIHZlY3RvcnMgKDEgc3VwcG9ydGVkKQpNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IG1zaTogcm91dGluZyBNU0kgSVJRIDI1NyB0byBsb2NhbCBBUElDIDAg dmVjdG9yIDUwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjE6IHVzaW5nIElS USAyNTcgZm9yIE1TSQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIxOiBbR0lB TlQtTE9DS0VEXQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIxOiBIb3RQbHVn IGNvbW1hbmQ6IDAwMDAgLT4gMTAyOApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBj aWIxOiAgIGRvbWFpbiAgICAgICAgICAgIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAxCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogcGNpYjE6ICAgc3Vib3JkaW5hdGUgYnVzICAgMQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IHBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDIuMiBvbiBw Y2kwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDQgKDB4ZTAwMC0weGVmZmYpIGZvciByaWQgMWMgb2YgcGNpYjIKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhmZWEwMDAwMC0weGZlYWZm ZmZmKSBmb3IgcmlkIDIwIG9mIHBjaWIyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjA4MDAwMDAtMHhmMDhmZmZmZikgZm9yIHJpZCAy NCBvZiBwY2liMgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIyOiAgIGRvbWFp biAgICAgICAgICAgIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMjogICBz ZWNvbmRhcnkgYnVzICAgICAyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjI6 ICAgc3Vib3JkaW5hdGUgYnVzICAgMgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBj aWIyOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZTAwMC0weGVmZmYKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBwY2liMjogICBtZW1vcnkgZGVjb2RlICAgICAweGZlYTAwMDAwLTB4ZmVh ZmZmZmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMjogICBwcmVmZXRjaGVk IGRlY29kZSAweGYwODAwMDAwLTB4ZjA4ZmZmZmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IHBjaWIyOiBhbGxvY2F0ZWQgYnVzIHJhbmdlICgyLTIpIGZvciByaWQgMCBvZiBw Y2kxCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpMTogZG9tYWluPTAsIHBoeXNp Y2FsIGJ1cz0yCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9 MHgxMGVjLCBkZXY9MHg4MTM2LCByZXZpZD0weDA3Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogCWRvbWFpbj0wLCBidXM9Miwgc2xvdD0wLCBmdW5jPTAKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiAJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAx MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJ bGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAg bnMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWludHBpbj1hLCBpcnE9MjU1Ck1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBE MSBEMiBEMyAgY3VycmVudCBEMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlNU0kg c3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiAJTVNJLVggc3VwcG9ydHMgNCBtZXNzYWdlcyBpbiBtYXAgMHgyMApNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IAltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAw eGUwMDAsIHNpemUgIDgsIGVuYWJsZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBw Y2liMjogYWxsb2NhdGVkIEkvTyBwb3J0IHJhbmdlICgweGUwMDAtMHhlMGZmKSBmb3IgcmlkIDEw IG9mIHBjaTA6MjowOjAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJbWFwWzE4XTog dHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmVhMDAwMDAsIHNpemUgMTIsIGVuYWJsZWQK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMjogYWxsb2NhdGVkIG1lbW9yeSBy YW5nZSAoMHhmZWEwMDAwMC0weGZlYTAwZmZmKSBmb3IgcmlkIDE4IG9mIHBjaTA6MjowOjAKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJbWFwWzIwXTogdHlwZSBQcmVmZXRjaGFibGUg TWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGYwODAwMDAwLCBzaXplIDE0LCBlbmFibGVkCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjI6IGFsbG9jYXRlZCBwcmVmZXRjaCByYW5n ZSAoMHhmMDgwMDAwMC0weGYwODAzZmZmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MjowOjAKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiByZTA6IDxSZWFsVGVrIDgxMHhFIFBDSWUgMTAvMTAw YmFzZVRYPiBwb3J0IDB4ZTAwMC0weGUwZmYgbWVtIDB4ZmVhMDAwMDAtMHhmZWEwMGZmZiwweGYw ODAwMDAwLTB4ZjA4MDNmZmYgYXQgZGV2aWNlIDAuMCBvbiBwY2kxCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogcmUwOiBNU0kgY291bnQgOiAxCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcmUwOiBNU0ktWCBjb3VudCA6IDQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiByZTA6IGF0dGVtcHRpbmcgdG8gYWxsb2NhdGUgMSBNU0ktWCB2ZWN0b3JzICg0IHN1cHBv cnRlZCkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBtc2k6IHJvdXRpbmcgTVNJLVgg SVJRIDI1OCB0byBsb2NhbCBBUElDIDEgdmVjdG9yIDQ5Ck1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcmUwOiB1c2luZyBJUlEgMjU4IGZvciBNU0ktWApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHJlMDogVXNpbmcgMSBNU0ktWCBtZXNzYWdlCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogcmUwOiBBU1BNIGRpc2FibGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcmUwOiBDaGlwIHJldi4gMHg0NDgwMDAwMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IHJlMDogTUFDIHJldi4gMHgwMDEwMDAwMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IG1paWJ1czA6IDxNSUkgYnVzPiBvbiByZTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBybHBoeTA6IDxSVEw4MjAxRSAxMC8xMDAgbWVkaWEgaW50ZXJmYWNlPiBQSFkg MSBvbiBtaWlidXMwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcmxwaHkwOiBPVUkg MHgwMGUwNGMsIG1vZGVsIDB4MDAwOCwgcmV2LiAyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogcmxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRY LUZEWCwgYXV0bywgYXV0by1mbG93Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcmUw OiBVc2luZyBkZWZhdWx0cyBmb3IgVFNPOiA2NTUxOC8zNS8yMDQ4Ck1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogcmUwOiBicGYgYXR0YWNoZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiByZTA6IEV0aGVybmV0IGFkZHJlc3M6IDI4OmYxOjBlOjJlOjg0OmExCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogcmUwOiBuZXRtYXAgcXVldWVzL3Nsb3RzOiBUWCAxLzI1 NiwgUlggMS8yNTYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMzogPEFDUEkg UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyLjMgb24gcGNpMApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGZlOTAwMDAwLTB4ZmU5ZmZm ZmYpIGZvciByaWQgMjAgb2YgcGNpYjMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBw Y2liMzogICBkb21haW4gICAgICAgICAgICAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNpYjM6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBjaWIzOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDMKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBwY2liMzogICBtZW1vcnkgZGVjb2RlICAgICAweGZlOTAwMDAwLTB4ZmU5ZmZm ZmYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2kyOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIzOiBhbGxvY2F0ZWQg YnVzIHJhbmdlICgzLTMpIGZvciByaWQgMCBvZiBwY2kyCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcGNpMjogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0zCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogZm91bmQtPgl2ZW5kb3I9MHgxNjhjLCBkZXY9MHgwMDM2LCByZXZpZD0w eDAxCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWRvbWFpbj0wLCBidXM9Mywgc2xv dD0wLCBmdW5jPTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJY2xhc3M9MDItODAt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IAljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogCWludHBpbj1hLCBpcnE9MjU1Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMApNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAlNU0kgc3VwcG9ydHMgNCBtZXNzYWdlcywgNjQgYml0 LCB2ZWN0b3IgbWFza3MKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJbWFwWzEwXTog dHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmU5MDAwMDAsIHNpemUgMTksIG1lbW9yeSBk aXNhYmxlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIzOiBhbGxvY2F0ZWQg bWVtb3J5IHJhbmdlICgweGZlOTAwMDAwLTB4ZmU5N2ZmZmYpIGZvciByaWQgMTAgb2YgcGNpMDoz OjA6MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGF0aDA6IDxRdWFsY29tbSBBdGhl cm9zIEFSOTU2NT4gbWVtIDB4ZmU5MDAwMDAtMHhmZTk3ZmZmZiBhdCBkZXZpY2UgMC4wIG9uIHBj aTIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMzogbWF0Y2hlZCBlbnRyeSBm b3IgMy4wLklOVEEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMzogc2xvdCAw IElOVEEgaGFyZHdpcmVkIHRvIElSUSAzMgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IGlvYXBpYzE6IHJvdXRpbmcgaW50cGluIDggKFBDSSBJUlEgMzIpIHRvIGxhcGljIDIgdmVjdG9y IDQ4Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogV0IzMzUgMi1BTlQgY2Fy ZCBkZXRlY3RlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGF0aDA6IEJsdWV0b290 aCBBbnRlbm5hIERpdmVyc2l0eSBjYXJkIGRldGVjdGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogYXI5MzAwX2ZsYXNoX21hcDogdW5pbXBsZW1lbnRlZCBmb3Igbm93Ck1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogUmVzdG9yaW5nIENhbCBkYXRhIGZyb20gRFJBTQpNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFJlc3RvcmluZyBDYWwgZGF0YSBmcm9tIEVFUFJP TQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFJlc3RvcmluZyBDYWwgZGF0YSBmcm9t IEZsYXNoCk1hciAyNSAxOTowODowMCBkZWxsYnNkIHN5c2xvZ2Q6IGxhc3QgbWVzc2FnZSByZXBl YXRlZCAxIHRpbWVzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogUmVzdG9yaW5nIENh bCBkYXRhIGZyb20gT1RQCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXI5MzAwX2h3 X2F0dGFjaDogYXI5MzAwX2VlcHJvbV9hdHRhY2ggcmV0dXJuZWQgMApNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IGF0aDA6IFJYIHN0YXR1cyBsZW5ndGg6IDQ4Ck1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogYXRoMDogUlggYnVmZmVyIHNpemU6IDQwOTYKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBhdGgwOiBUWCBkZXNjcmlwdG9yIGxlbmd0aDogMTI4Ck1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogVFggc3RhdHVzIGxlbmd0aDogMzYKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhdGgwOiBUWCBidWZmZXJzIHBlciBkZXNjcmlw dG9yOiA0Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogYXRoX2VkbWFfc2V0 dXBfcnhmaWZvOiB0eXBlPTAsIEZJRk8gZGVwdGggPSAxNiBlbnRyaWVzCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogYXRoMDogYXRoX2VkbWFfc2V0dXBfcnhmaWZvOiB0eXBlPTEsIEZJ Rk8gZGVwdGggPSAxMjggZW50cmllcwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGF0 aDA6IFJYIHRpbWVzdGFtcDogMzIgYml0cwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IGF0aDA6IFRYIHRpbWVzdGFtcDogMzIgYml0cwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IGF0aDA6IFtIVF0gZW5hYmxpbmcgSFQgbW9kZXMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBhdGgwOiBbSFRdIGVuYWJsaW5nIHNob3J0LUdJIGluIDIwTUh6IG1vZGUKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhdGgwOiBbSFRdIDEgc3RyZWFtIFNUQkMgcmVjZWl2 ZSBlbmFibGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogW0hUXSAxIFJY IHN0cmVhbXM7IDEgVFggc3RyZWFtcwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGF0 aDA6IDExYiByYXRlczogMU1icHMgMk1icHMgNS41TWJwcyAxMU1icHMKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBhdGgwOiAxMWcgcmF0ZXM6IDFNYnBzIDJNYnBzIDUuNU1icHMgMTFN YnBzIDZNYnBzIDlNYnBzIDEyTWJwcyAxOE1icHMgMjRNYnBzIDM2TWJwcyA0OE1icHMgNTRNYnBz Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogMVQxUgpNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IGF0aDA6IDExbmcgTUNTIDIwTUh6Ck1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogYXRoMDogTUNTIDAtNzogNi41TWJwcyAtIDY1TWJwcwpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGF0aDA6IDExbmcgTUNTIDIwTUh6IFNHSQpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGF0aDA6IE1DUyAwLTc6IDdNYnBzIC0gNzJNYnBzCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogMTFuZyBNQ1MgNDBNSHo6Ck1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogTUNTIDAtNzogMTMuNU1icHMgLSAxMzVNYnBz Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogMTFuZyBNQ1MgNDBNSHogU0dJ OgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGF0aDA6IE1DUyAwLTc6IDE1TWJwcyAt IDE1ME1icHMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhdGgwOiBRQ0E5NTY1IG1h YyA3MDQuMSBSRjUxMTAgcGh5IDE2MzguNgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IGF0aDA6IDJHSHogcmFkaW86IDB4MDAwMDsgNUdIeiByYWRpbzogMHgwMDAwCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogVXNlIGh3IHF1ZXVlIDEgZm9yIFdNRV9BQ19CRSB0 cmFmZmljCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogVXNlIGh3IHF1ZXVl IDAgZm9yIFdNRV9BQ19CSyB0cmFmZmljCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog YXRoMDogVXNlIGh3IHF1ZXVlIDIgZm9yIFdNRV9BQ19WSSB0cmFmZmljCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogYXRoMDogVXNlIGh3IHF1ZXVlIDMgZm9yIFdNRV9BQ19WTyB0cmFm ZmljCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogVXNlIGh3IHF1ZXVlIDgg Zm9yIENBQiB0cmFmZmljCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRoMDogVXNl IGh3IHF1ZXVlIDkgZm9yIGJlYWNvbnMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBh dGgwOiB1c2luZyBtdWx0aWNhc3Qga2V5IHNlYXJjaApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBjaTA6IDxlbmNyeXB0L2RlY3J5cHQ+IGF0IGRldmljZSA4LjAgKG5vIGRyaXZlciBh dHRhY2hlZCkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiB4aGNpMDogPEFNRCBGQ0gg VVNCIDMuMCBjb250cm9sbGVyPiBtZW0gMHhmZWI2ODAwMC0weGZlYjY5ZmZmIGF0IGRldmljZSAx Ni4wIG9uIHBjaTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiB4aGNpMDogMzIgYnl0 ZXMgY29udGV4dCBzaXplLCA2NC1iaXQgRE1BCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogeGhjaTA6IGF0dGVtcHRpbmcgdG8gYWxsb2NhdGUgMSBNU0ktWCB2ZWN0b3JzICg4IHN1cHBv cnRlZCkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBtc2k6IHJvdXRpbmcgTVNJLVgg SVJRIDI1OSB0byBsb2NhbCBBUElDIDMgdmVjdG9yIDQ5Ck1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogeGhjaTA6IHVzaW5nIElSUSAyNTkgZm9yIE1TSS1YCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogeGhjaTA6IE1TSS1YIGVuYWJsZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiB1c2J1czAgb24geGhjaTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiB4aGNpMDogdXNicGY6IEF0dGFjaGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog dXNidXMwOiA1LjBHYnBzIFN1cGVyIFNwZWVkIFVTQiB2My4wCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogYWhjaTA6IDxBTUQgSHVkc29uLTIgQUhDSSBTQVRBIGNvbnRyb2xsZXI+IHBv cnQgMHhmMTQwLTB4ZjE0NywweGYxMzAtMHhmMTMzLDB4ZjEyMC0weGYxMjcsMHhmMTEwLTB4ZjEx MywweGYxMDAtMHhmMTBmIG1lbSAweGZlYjZmMDAwLTB4ZmViNmYzZmYgYXQgZGV2aWNlIDE3LjAg b24gcGNpMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFoY2kwOiBhdHRlbXB0aW5n IHRvIGFsbG9jYXRlIDggTVNJIHZlY3RvcnMgKDggc3VwcG9ydGVkKQpNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IG1zaTogcm91dGluZyBNU0kgSVJRIDI2MCB0byBsb2NhbCBBUElDIDAg dmVjdG9yIDU2Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogbXNpOiByb3V0aW5nIE1T SSBJUlEgMjYxIHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTcKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBtc2k6IHJvdXRpbmcgTVNJIElSUSAyNjIgdG8gbG9jYWwgQVBJQyAwIHZlY3Rv ciA1OApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IG1zaTogcm91dGluZyBNU0kgSVJR IDI2MyB0byBsb2NhbCBBUElDIDAgdmVjdG9yIDU5Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogbXNpOiByb3V0aW5nIE1TSSBJUlEgMjY0IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNjAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBtc2k6IHJvdXRpbmcgTVNJIElSUSAyNjUg dG8gbG9jYWwgQVBJQyAwIHZlY3RvciA2MQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IG1zaTogcm91dGluZyBNU0kgSVJRIDI2NiB0byBsb2NhbCBBUElDIDAgdmVjdG9yIDYyCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogbXNpOiByb3V0aW5nIE1TSSBJUlEgMjY3IHRvIGxv Y2FsIEFQSUMgMCB2ZWN0b3IgNjMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhaGNp MDogdXNpbmcgSVJRcyAyNjAtMjY3IGZvciBNU0kKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBhaGNpMDogQUhDSSB2MS4zMCB3aXRoIDIgNkdicHMgcG9ydHMsIFBvcnQgTXVsdGlwbGll ciBzdXBwb3J0ZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhaGNpMDogQ2Fwczog NjRiaXQgTkNRIFNOVEYgTVBTIEFMUCBBTCBDTE8gNkdicHMgUE0gUE1EIFNTQyBQU0MgMzJjbWQg MnBvcnRzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYWhjaTA6IENhcHMyOgpNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFoY2ljaDA6IDxBSENJIGNoYW5uZWw+IGF0IGNo YW5uZWwgMCBvbiBhaGNpMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFoY2ljaDA6 IENhcHM6Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYWhjaWNoMTogPEFIQ0kgY2hh bm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogYWhjaWNoMTogQ2FwczoKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBlaGNpMDog PEFNRCBGQ0ggVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmZWI2ZTAwMC0weGZlYjZlMGZmIGF0 IGRldmljZSAxOC4wIG9uIHBjaTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2li MDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xOC5JTlRBCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogcGNpYjA6IHNsb3QgMTggSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE4Ck1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEg MTgpIHRvIGxhcGljIDEgdmVjdG9yIDUwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog dXNidXMxOiBFSENJIHZlcnNpb24gMS4wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog dXNidXMxIG9uIGVoY2kwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogZWhjaTA6IHVz YnBmOiBBdHRhY2hlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHVzYnVzMTogNDgw TWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog ZWhjaTE6IDxBTUQgRkNIIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZmViNmQwMDAtMHhmZWI2 ZDBmZiBhdCBkZXZpY2UgMTkuMCBvbiBwY2kwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTkuSU5UQQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHBjaWIwOiBzbG90IDE5IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxOApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHVzYnVzMjogRUhDSSB2ZXJzaW9uIDEuMApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHVzYnVzMiBvbiBlaGNpMQpNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IGVoY2kxOiB1c2JwZjogQXR0YWNoZWQKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiB1c2J1czI6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQg ZGV2aWNlIDIwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBoZGFjMTogPEFNRCBIdWRzb24tMiBIREEgQ29udHJvbGxlcj4gbWVtIDB4ZmViNjAw MDAtMHhmZWI2M2ZmZiBhdCBkZXZpY2UgMjAuMiBvbiBwY2kwCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogaGRhYzE6IFBDSSBjYXJkIHZlbmRvcjogMHgxMDI4LCBkZXZpY2U6IDB4MDZi ZgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWMxOiBIREEgRHJpdmVyIFJldmlz aW9uOiAyMDEyMDEyNl8wMDAyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYzE6 IENvbmZpZyBvcHRpb25zOiBvbj0weDAwMDAwMDAwIG9mZj0weDAwMDAwMDAwCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjAuSU5UQQpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBzbG90IDIwIElOVEEgaGFyZHdp cmVkIHRvIElSUSAxNgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDE2IChQQ0kgSVJRIDE2KSB0byBsYXBpYyAyIHZlY3RvciA0OQpNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWMxOiBDYXBzOiBPU1MgNCwgSVNTIDQsIEJTUyAw LCBOU0RPIDEsIDY0Yml0LCBDT1JCIDI1NiwgUklSQiAyNTYKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBpc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMjAuMyBvbiBwY2kw Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaXNhMDogPElTQSBidXM+IG9uIGlzYWIw Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogc2RoY2lfcGNpMDogPEdlbmVyaWMgU0Qg SENJPiBtZW0gMHhmZWI2YzAwMC0weGZlYjZjMGZmIGF0IGRldmljZSAyMC43IG9uIHBjaTAKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBzZGhjaV9wY2kwOiBhdHRlbXB0aW5nIHRvIGFs bG9jYXRlIDEgTVNJIHZlY3RvcnMgKDEgc3VwcG9ydGVkKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IG1zaTogcm91dGluZyBNU0kgSVJRIDI2OCB0byBsb2NhbCBBUElDIDMgdmVjdG9y IDUwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogc2RoY2lfcGNpMDogdXNpbmcgSVJR IDI2OCBmb3IgTVNJCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogc2RoY2lfcGNpMC1z bG90MDogNTBNSHogSFMgOGJpdHMgVkREOiAzLjNWIFZDQ1E6IDMuM1YgRFJWOiBCIERNQSByZW1v dmFibGUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBzZGhjaV9wY2kwLXNsb3QwOiA9 PT09PT09PT09PT09PSBSRUdJU1RFUiBEVU1QID09PT09PT09PT09PT09Ck1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogc2RoY2lfcGNpMC1zbG90MDogU3lzIGFkZHI6IDB4MDAwMDAwMDAg fCBWZXJzaW9uOiAgMHgwMDAwMTAwMQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHNk aGNpX3BjaTAtc2xvdDA6IEJsayBzaXplOiAweDAwMDAwMDAwIHwgQmxrIGNudDogIDB4MDAwMDAw MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBzZGhjaV9wY2kwLXNsb3QwOiBBcmd1 bWVudDogMHgwMDAwMDAwMCB8IFRybiBtb2RlOiAweDAwMDAwMDAwCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogc2RoY2lfcGNpMC1zbG90MDogUHJlc2VudDogIDB4MDBmMjAwMDAgfCBI b3N0IGN0bDogMHgwMDAwMDAwMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHNkaGNp X3BjaTAtc2xvdDA6IFBvd2VyOiAgICAweDAwMDAwMDAwIHwgQmxrIGdhcDogIDB4MDAwMDAwMDAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBzZGhjaV9wY2kwLXNsb3QwOiBXYWtlLXVw OiAgMHgwMDAwMDAwMCB8IENsb2NrOiAgICAweDAwMDAwMDAwCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogc2RoY2lfcGNpMC1zbG90MDogVGltZW91dDogIDB4MDAwMDAwMDAgfCBJbnQg c3RhdDogMHgwMDAwMDAwMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHNkaGNpX3Bj aTAtc2xvdDA6IEludCBlbmFiOiAweDAwMDAwMDAwIHwgU2lnIGVuYWI6IDB4MDAwMDAwMDAKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBzZGhjaV9wY2kwLXNsb3QwOiBBQzEyIGVycjog MHgwMDAwMDAwMCB8IEhvc3QgY3RsMjoweDAwMDAwMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogc2RoY2lfcGNpMC1zbG90MDogQ2FwczogICAgIDB4MjFmZTMyYjIgfCBDYXBzMjog ICAgMHgwMDAwMDA3MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHNkaGNpX3BjaTAt c2xvdDA6IE1heCBjdXJyOiAweDAwYzgwMDY0IHwgQURNQSBlcnI6IDB4MDAwMDAwMDAKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBzZGhjaV9wY2kwLXNsb3QwOiBBRE1BIGFkZHI6MHgw MDAwMDAwMCB8IFNsb3QgaW50OiAweDAwMDAwMGZmCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogc2RoY2lfcGNpMC1zbG90MDogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHNkaGNpX3BjaTA6IDEg c2xvdChzKSBhbGxvY2F0ZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhY3BpX2J1 dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3aXRjaD4gb24gYWNwaTAKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhY3BpX2J1dHRvbjE6IDxTbGVlcCBCdXR0b24+ IG9uIGFjcGkwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IDxBQ1BJ IENvbnRyb2wgTWV0aG9kIEJhdHRlcnk+IG9uIGFjcGkwCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogQWNwaU9zRXhlY3V0ZTogdGFzayBxdWV1ZSBub3Qgc3RhcnRlZApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFjcGlfYWNhZDA6IDxBQyBBZGFwdGVyPiBvbiBhY3BpMApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IEFjcGlPc0V4ZWN1dGU6IHRhc2sgcXVldWUg bm90IHN0YXJ0ZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhdGtiZGMwOiA8S2V5 Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEg MSBvbiBhdGtiZGMwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRrYmQ6IHRoZSBj dXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1hbmQgYnl0ZSAwMDY1Ck1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogYXRrYmQ6IGtleWJvYXJkIElEIDB4NDFhYiAoMikKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBrYmRjOiBSRVNFVF9LQkQgcmV0dXJuIGNvZGU6MDBmYQpNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGtiZGM6IFJFU0VUX0tCRCBzdGF0dXM6MDBhYQpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGtiZDAgYXQgYXRrYmQwCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDoga2JkMDogYXRrYmQwLCBBVCAxMDEvMTAyICgyKSwgY29uZmln OjB4MCwgZmxhZ3M6MHgxZDAwMDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBpb2Fw aWMwOiByb3V0aW5nIGludHBpbiAxIChJU0EgSVJRIDEpIHRvIGxhcGljIDAgdmVjdG9yIDUxCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBzbTA6IHVuYWJsZSB0byBhbGxvY2F0ZSBJUlEK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBBQ1BJOiBFbmFibGVkIDEgR1BFcyBpbiBi bG9jayAwMCB0byAxRgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGEwMDAwLTB4YTA3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTA4MDAt MHhhMGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMTAwMC0weGExN2ZmKSBmb3IgcmlkIDAgb2Yg b3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGExODAwLTB4YTFmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTIwMDAtMHhhMjdmZikg Zm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhhMjgwMC0weGEyZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGEz MDAwLTB4YTM3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTM4MDAtMHhhM2ZmZikgZm9yIHJpZCAw IG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhhNDAwMC0weGE0N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE0ODAwLTB4YTRm ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTUwMDAtMHhhNTdmZikgZm9yIHJpZCAwIG9mIG9ybTAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhhNTgwMC0weGE1ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE2MDAwLTB4YTY3ZmYpIGZvciBy aWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YTY4MDAtMHhhNmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhNzAwMC0w eGE3N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGE3ODAwLTB4YTdmZmYpIGZvciByaWQgMCBvZiBv cm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4YTgwMDAtMHhhODdmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhODgwMC0weGE4ZmZmKSBm b3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGE5MDAwLTB4YTk3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YTk4 MDAtMHhhOWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYTAwMC0weGFhN2ZmKSBmb3IgcmlkIDAg b2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGFhODAwLTB4YWFmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWIwMDAtMHhhYjdm ZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYjgwMC0weGFiZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGFjMDAwLTB4YWM3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWM4MDAtMHhhY2ZmZikgZm9yIHJp ZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhhZDAwMC0weGFkN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFkODAwLTB4 YWRmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YWUwMDAtMHhhZTdmZikgZm9yIHJpZCAwIG9mIG9y bTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhhZTgwMC0weGFlZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGFmMDAwLTB4YWY3ZmYpIGZv ciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4YWY4MDAtMHhhZmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMDAw MC0weGIwN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGIwODAwLTB4YjBmZmYpIGZvciByaWQgMCBv ZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4YjEwMDAtMHhiMTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMTgwMC0weGIxZmZm KSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGIyMDAwLTB4YjI3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 YjI4MDAtMHhiMmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMzAwMC0weGIzN2ZmKSBmb3Igcmlk IDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGIzODAwLTB4YjNmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjQwMDAtMHhi NDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNDgwMC0weGI0ZmZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGI1MDAwLTB4YjU3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjU4MDAtMHhiNWZmZikgZm9y IHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhiNjAwMC0weGI2N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI2ODAw LTB4YjZmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YjcwMDAtMHhiNzdmZikgZm9yIHJpZCAwIG9m IG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhiNzgwMC0weGI3ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI4MDAwLTB4Yjg3ZmYp IGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yjg4MDAtMHhiOGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhi OTAwMC0weGI5N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGI5ODAwLTB4YjlmZmYpIGZvciByaWQg MCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4YmEwMDAtMHhiYTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiYTgwMC0weGJh ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJiMDAwLTB4YmI3ZmYpIGZvciByaWQgMCBvZiBvcm0w Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4YmI4MDAtMHhiYmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiYzAwMC0weGJjN2ZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGJjODAwLTB4YmNmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmQwMDAt MHhiZDdmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZDgwMC0weGJkZmZmKSBmb3IgcmlkIDAgb2Yg b3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGJlMDAwLTB4YmU3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YmU4MDAtMHhiZWZmZikg Zm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhiZjAwMC0weGJmN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGJm ODAwLTB4YmZmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzAwMDAtMHhjMDdmZikgZm9yIHJpZCAw IG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhjMDgwMC0weGMwZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGMxMDAwLTB4YzE3 ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzE4MDAtMHhjMWZmZikgZm9yIHJpZCAwIG9mIG9ybTAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhjMjAwMC0weGMyN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGMyODAwLTB4YzJmZmYpIGZvciBy aWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4YzMwMDAtMHhjMzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjMzgwMC0w eGMzZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGM0MDAwLTB4YzQ3ZmYpIGZvciByaWQgMCBvZiBv cm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDMgKDB4YzQ4MDAtMHhjNGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjNTAwMC0weGM1N2ZmKSBm b3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBh bGxvY2F0ZWQgdHlwZSAzICgweGM1ODAwLTB4YzVmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzYw MDAtMHhjNjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjNjgwMC0weGM2ZmZmKSBmb3IgcmlkIDAg b2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQg dHlwZSAzICgweGM3MDAwLTB4Yzc3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Yzc4MDAtMHhjN2Zm ZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjODAwMC0weGM4N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGM4ODAwLTB4YzhmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4YzkwMDAtMHhjOTdmZikgZm9yIHJp ZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhjOTgwMC0weGM5ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGNhMDAwLTB4 Y2E3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog cGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4Y2E4MDAtMHhjYWZmZikgZm9yIHJpZCAwIG9mIG9y bTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhjYjAwMC0weGNiN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGNiODAwLTB4Y2JmZmYpIGZv ciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDMgKDB4Y2MwMDAtMHhjYzdmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjYzgw MC0weGNjZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGNkMDAwLTB4Y2Q3ZmYpIGZvciByaWQgMCBv ZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0 eXBlIDMgKDB4Y2Q4MDAtMHhjZGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjZTAwMC0weGNlN2Zm KSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIw OiBhbGxvY2F0ZWQgdHlwZSAzICgweGNlODAwLTB4Y2VmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4 Y2YwMDAtMHhjZjdmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhjZjgwMC0weGNmZmZmKSBmb3Igcmlk IDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGQwMDAwLTB4ZDA3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDA4MDAtMHhk MGZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkMTAwMC0weGQxN2ZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAz ICgweGQxODAwLTB4ZDFmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDIwMDAtMHhkMjdmZikgZm9y IHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhkMjgwMC0weGQyZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQzMDAw LTB4ZDM3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDM4MDAtMHhkM2ZmZikgZm9yIHJpZCAwIG9m IG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhkNDAwMC0weGQ0N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ0ODAwLTB4ZDRmZmYp IGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDUwMDAtMHhkNTdmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhk NTgwMC0weGQ1ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ2MDAwLTB4ZDY3ZmYpIGZvciByaWQg MCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRl ZCB0eXBlIDMgKDB4ZDY4MDAtMHhkNmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkNzAwMC0weGQ3 N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGQ3ODAwLTB4ZDdmZmYpIGZvciByaWQgMCBvZiBvcm0w Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMg KDB4ZDgwMDAtMHhkODdmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkODgwMC0weGQ4ZmZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxv Y2F0ZWQgdHlwZSAzICgweGQ5MDAwLTB4ZDk3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZDk4MDAt MHhkOWZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYTAwMC0weGRhN2ZmKSBmb3IgcmlkIDAgb2Yg b3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlw ZSAzICgweGRhODAwLTB4ZGFmZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGIwMDAtMHhkYjdmZikg Zm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhkYjgwMC0weGRiZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRj MDAwLTB4ZGM3ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGM4MDAtMHhkY2ZmZikgZm9yIHJpZCAw IG9mIG9ybTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhkZDAwMC0weGRkN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRkODAwLTB4ZGRm ZmYpIGZvciByaWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZGUwMDAtMHhkZTdmZikgZm9yIHJpZCAwIG9mIG9ybTAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhkZTgwMC0weGRlZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGRmMDAwLTB4ZGY3ZmYpIGZvciBy aWQgMCBvZiBvcm0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpYjA6IGFsbG9j YXRlZCB0eXBlIDMgKDB4ZGY4MDAtMHhkZmZmZikgZm9yIHJpZCAwIG9mIG9ybTAKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhaGNfaXNhX2lkZW50aWZ5IDA6IGlvcG9ydCAweGMwMCBh bGxvYyBmYWlsZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhaGNfaXNhX2lkZW50 aWZ5IDE6IGlvcG9ydCAweDFjMDAgYWxsb2MgZmFpbGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogYWhjX2lzYV9pZGVudGlmeSAyOiBpb3BvcnQgMHgyYzAwIGFsbG9jIGZhaWxlZApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFoY19pc2FfaWRlbnRpZnkgMzogaW9wb3J0 IDB4M2MwMCBhbGxvYyBmYWlsZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhaGNf aXNhX2lkZW50aWZ5IDQ6IGlvcG9ydCAweDRjMDAgYWxsb2MgZmFpbGVkCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogYWhjX2lzYV9pZGVudGlmeSA1OiBpb3BvcnQgMHg1YzAwIGFsbG9j IGZhaWxlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFoY19pc2FfaWRlbnRpZnkg NjogaW9wb3J0IDB4NmMwMCBhbGxvYyBmYWlsZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBhaGNfaXNhX2lkZW50aWZ5IDc6IGlvcG9ydCAweDdjMDAgYWxsb2MgZmFpbGVkCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYWhjX2lzYV9pZGVudGlmeSA4OiBpb3BvcnQgMHg4 YzAwIGFsbG9jIGZhaWxlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFoY19pc2Ff aWRlbnRpZnkgOTogaW9wb3J0IDB4OWMwMCBhbGxvYyBmYWlsZWQKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBhaGNfaXNhX2lkZW50aWZ5IDEwOiBpb3BvcnQgMHhhYzAwIGFsbG9jIGZh aWxlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFoY19pc2FfaWRlbnRpZnkgMTE6 IGlvcG9ydCAweGJjMDAgYWxsb2MgZmFpbGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogYWhjX2lzYV9pZGVudGlmeSAxMjogaW9wb3J0IDB4Y2MwMCBhbGxvYyBmYWlsZWQKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhaGNfaXNhX2lkZW50aWZ5IDEzOiBpb3BvcnQgMHhk YzAwIGFsbG9jIGZhaWxlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFoY19pc2Ff aWRlbnRpZnkgMTQ6IGlvcG9ydCAweGVjMDAgYWxsb2MgZmFpbGVkCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhdGtiZGM6IGF0a2JkYzAgYWxyZWFkeSBl eGlzdHM7IHNraXBwaW5nIGl0Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYXRydGM6 IGF0cnRjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBhdHRpbWVyOiBhdHRpbWVyMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBzYzogc2MwIGFscmVhZHkgZXhpc3RzOyBz a2lwcGluZyBpdApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGlzYV9wcm9iZV9jaGls ZHJlbjogcHJvYmluZyBub24tUG5QIGRldmljZXMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBzYzAgZmFpbGVkIHRvIHByb2JlIG9uIGlzYTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiB2Z2EwIGZhaWxlZCB0byBwcm9iZSBvbiBpc2EwCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4M2YwLTB4M2Y1KSBmb3Igcmlk IDAgb2YgZmRjMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSA0ICgweDNmNy0weDNmNykgZm9yIHJpZCAxIG9mIGZkYzAKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBmZGMwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2YwLTB4M2Y1 LDB4M2Y3IGlycSA2IGRycSAyIG9uIGlzYTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5nZQpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHBwYzAgZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTAKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgzZjgt MHgzZjgpIGZvciByaWQgMCBvZiB1YXJ0MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IHVhcnQwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2Y4IGlycSA0IG9uIGlzYTAKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgyZjgt MHgyZjgpIGZvciByaWQgMCBvZiB1YXJ0MQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IHVhcnQxIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4IGlycSAzIG9uIGlzYTAKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBpc2FfcHJvYmVfY2hpbGRyZW46IHByb2JpbmcgUG5Q IGRldmljZXMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBBY3BpT3NFeGVjdXRlOiB0 YXNrIHF1ZXVlIG5vdCBzdGFydGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIHN5c2xvZ2Q6IGxh c3QgbWVzc2FnZSByZXBlYXRlZCAzIHRpbWVzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogaHdwc3RhdGUwOiA8Q29vbGBuJ1F1aWV0IDIuMD4gb24gY3B1MApNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IERldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLgpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHByb2NmcyByZWdpc3RlcmVkCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHZsYW46IGluaXRpYWxpemVkLCB1c2luZyBoYXNoIHRh YmxlcyB3aXRoIGNoYWluaW5nCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogbG8wOiBi cGYgYXR0YWNoZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiB0Y3BfaW5pdDogbmV0 LmluZXQudGNwLnRjYmhhc2hzaXplIGF1dG8gdHVuZWQgdG8gMzI3NjgKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBJUHNlYzogSW5pdGlhbGl6ZWQgU2VjdXJpdHkgQXNzb2NpYXRpb24g UHJvY2Vzc2luZy4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBBY3BpT3NFeGVjdXRl OiBlbnF1ZXVlIDYgcGVuZGluZyB0YXNrcwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IGhwdG5yOiBubyBjb250cm9sbGVyIGRldGVjdGVkLgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IGhwdHJyOiBubyBjb250cm9sbGVyIGRldGVjdGVkLgpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IGhwdDI3eHg6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IGJhdHRlcnkgZW5pdGlhbGl6YXRpb24gc3Rh cnQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFjYzA6IDxBVEkgUjZ4eCBIREEg Q09ERUM+IGF0IGNhZCAwIG9uIGhkYWMwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog YmF0dGVyeTA6IHJldiA9IDAwMDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFh MDogYmF0dGVyeTA6IHVuaXRzID0gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGJh dHRlcnkwOiBkY2FwID0gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGJhdHRlcnkw OiBsZmNhcCA9IDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBiYXR0ZXJ5MDogYnRl Y2ggPSAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IGR2b2wgPSAw Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IHdjYXAgPSAwCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IGxjYXAgPSAwCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IGN5Y2xlcyA9IDAKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBiYXR0ZXJ5MDogYWNjdXJhY3kgPSAwCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IHN0bWF4ID0gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IGJhdHRlcnkwOiBzdG1pbiA9IDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBiYXR0ZXJ5MDogYWltYXggPSAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog YmF0dGVyeTA6IGFpbWluID0gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGJhdHRl cnkwOiBncmExID0gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IDxBVEkgUjZ4eCBB dWRpbyBGdW5jdGlvbiBHcm91cD5iYXR0ZXJ5MDogZ3JhMiA9IDAKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBiYXR0ZXJ5MDogYmF0dGVyeSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmll ZCAxIHRpbWVzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYWNwaV9hY2FkMDogYWNs aW5lIGluaXRpYWxpemF0aW9uIHN0YXJ0Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog YWNwaV9hY2FkMDogIGF0IG5pZCAxIG9uIGhkYWNjMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IGhkYWEwOiBPbiBMaW5lCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYWNw aV9hY2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9uIGRvbmUsIHRyaWVkIDEgdGltZXMKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBTdWJzeXN0ZW0gSUQ6IDB4MDBhYTAxMDAKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBiYXR0ZXJ5MDogcmV2ID0gMDAwMApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFoY2ljaDA6IGhkYWEwOiBiYXR0ZXJ5MDogdW5pdHMgPSAx Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IGRjYXAgPSAyODAwCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IGxmY2FwID0gMjgwMApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGJhdHRlcnkwOiBidGVjaCA9IDEKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiBiYXR0ZXJ5MDogTnVtR1BJTz0wIE51bUdQTz0wIE51bUdQ ST0wIEdQSVdha2U9MCBHUElVbnNvbD0wCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog ZHZvbCA9IDE0ODAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IHdj YXAgPSAyODAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBiYXR0ZXJ5MDogbGNhcCA9 IDg0Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IGN5Y2xlcyA9IDAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBiYXR0ZXJ5MDogYWNjdXJhY3kgPSAwCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTA6IGJhdHRlcnkwOiBzdG1heCA9IDAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBPcmlnaW5hbCBwaW5zIGNvbmZpZ3VyYXRp b246Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTA6IG5pZCAgIDB4ICAgIGFz IHNlcSBkZXZpY2UgICAgICAgY29ubiAgamFjayAgICBsb2MgICAgICAgIGNvbG9yICAgbWlzYwpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWEwOiAgMyAxODU2MDBmMCAxNSAwICBE aWdpdGFsLW91dCAgIEphY2sgIERpZ2l0YWwgMHgxOCAgICAgICBVbmtub3duIDAKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMDogIDUgNTg1NjAwZjAgMTUgMCAgRGlnaXRhbC1v dXQgICBOb25lICBEaWdpdGFsIDB4MTggICAgICAgVW5rbm93biAwCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogaGRhYTA6ICA3IDU4NTYwMGYwIDE1IDAgIERpZ2l0YWwtb3V0ICAgTm9u ZSAgRGlnaXRhbCAweDE4ICAgICAgIFVua25vd24gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IGhkYWEwOiBBSENJIHJlc2V0Li4uCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogUGF0Y2hlZCBwaW5zIGNvbmZpZ3VyYXRpb246Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogYWhjaWNoMDogaGRhYTA6IG5pZCAgIDB4ICAgIGFzIHNlcSBkZXZpY2UgICAgICAgY29u biAgamFjayAgICBsb2MgICAgICAgIGNvbG9yICAgbWlzYwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IGhkYWEwOiAgMyAxODU2MDBmMCAxNSAwICBEaWdpdGFsLW91dCAgIEphY2sgIERp Z2l0YWwgMHgxOCAgICAgICBVbmtub3duIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBoZGFhMDogIDUgNTg1NjAwZjAgMTUgMCAgRGlnaXRhbC1vdXQgICBOb25lICBEaWdpdGFsIDB4 MTggICAgICAgVW5rbm93biAwIERJU0EKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBo ZGFhMDogIDcgNTg1NjAwZjAgMTUgMCAgRGlnaXRhbC1vdXQgICBOb25lICBEaWdpdGFsIDB4MTgg ICAgICAgVW5rbm93biAwIERJU0EKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBTQVRB IGNvbm5lY3QgdGltZT0xMDB1cyBzdGF0dXM9MDAwMDAxMzMKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBhaGNpY2gwOiBBSENJIHJlc2V0OiBkZXZpY2UgZm91bmQKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBhaGNpY2gwOiBoZGFhMDogMSBhc3NvY2lhdGlvbnMgZm91bmQ6 Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTA6IEFzc29jaWF0aW9uIDAgKDE1 KSBvdXQ6Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTA6ICBQaW4gbmlkPTMg c2VxPTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMDogVHJhY2luZyBhc3Nv Y2lhdGlvbiAwICgxNSkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMDogIFBp biAzIHRyYWNlZCB0byBEQUMgMgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWEw OiBBc3NvY2lhdGlvbiAwICgxNSkgdHJhY2Ugc3VjY2VlZGVkCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogaGRhYTA6IExvb2tpbmcgZm9yIGFkZGl0aW9uYWwgREFDIGZvciBhc3NvY2lh dGlvbiAwICgxNSkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMDogVHJhY2lu ZyBpbnB1dCBtb25pdG9yCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTA6IFRy YWNpbmcgb3RoZXIgaW5wdXQgbW9uaXRvcnMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBBSENJIHJlc2V0OiBkZXZpY2UgcmVhZHkgYWZ0ZXIgMG1zCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogYWhjaWNoMTogaGRhYTA6IFRyYWNpbmcgYmVlcGVyCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogQUhDSSByZXNldC4uLgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IGhkYWEwOiBQaW4gc2Vuc2U6IG5pZD0zIHNlbnNlPTB4N2ZmZmZmZmYgKGRpc2Nvbm5l Y3RlZCwgRUxEIHZhbGlkKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWEwOiBG RyBjb25maWcvcXVpcmtzOiBmb3JjZXN0ZXJlbyBpdnJlZjUwIGl2cmVmODAgaXZyZWYxMDAgaXZy ZWYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBhaGNpY2gxOiBwY20wOiBTQVRBIGNv bm5lY3QgdGltZT0xOTAwdXMgc3RhdHVzPTAwMDAwMTEzCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogYWhjaWNoMTogQUhDSSByZXNldDogZGV2aWNlIGZvdW5kCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogYWhjaWNoMTogQUhDSSByZXNldDogZGV2aWNlIHJlYWR5IGFmdGVy IDBtcwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGJhdHRlcnkwOiBzdG1pbiA9IDAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBiYXR0ZXJ5MDogYWltYXggPSAwCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IGFpbWluID0gMApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGJhdHRlcnkwOiBncmExID0gMjY0Ck1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogYmF0dGVyeTA6IGdyYTIgPSAzNzgwCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogPEFUSSBSNnh4IChIRE1JKT4gYXQgbmlkIDMgb24gaGRhYTAKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20wOiBQbGF5YmFjazoKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBwY20wOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDUgQUMzIFBD TQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTA6ICAgICAgICAgUENNIGNhcDog MHgwMDAyMDA3MCAxNiBiaXRzLCAzMiA0NCA0OCBLSHoKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBwY20wOiAgICAgICAgICAgICBEQUM6IDIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBwY20wOiAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20wOiAgICAg bmlkPTMgW3BpbjogRGlnaXRhbC1vdXQgKEphY2spXQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBjbTA6ICAgICAgICsgPC0gbmlkPTIgW2F1ZGlvIG91dHB1dF0gW3NyYzogcGNtXQpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTA6IApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHBjbTA6IE1peGVyICJ2b2wiIC0+ICJub25lIjogY2hpbGQ9MHgwMDAwMDAx MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFoY2ljaDE6IHBjbTA6IE1peGVyICJw Y20iOiBwYXJlbnQ9InZvbCIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20wOiBT b2Z0IFBDTSBtaXhlciBFTkFCTEVECk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogU05U RiAweDAwMDEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20wOiBQbGF5YmFjayBj aGFubmVsIHNldCBpczogRnJvbnQgTGVmdCwgRnJvbnQgUmlnaHQsIApNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IHBjbTA6IFBsYXliYWNrIGNoYW5uZWwgbWF0cml4IGlzOiAyLjAgKGRp c2Nvbm5lY3RlZCkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFjYzE6IDxSZWFs dGVrIEFMQzI1NSBIREEgQ09ERUM+IGF0IGNhZCAwIG9uIGhkYWMxCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogaGRhYTE6IDxSZWFsdGVrIEFMQzI1NSBBdWRpbyBGdW5jdGlvbiBHcm91 cD4gYXQgbmlkIDEgb24gaGRhY2MxCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRh YTE6IFN1YnN5c3RlbSBJRDogMHgxMDI4MDZiZgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IGhkYWExOiBOdW1HUElPPTMgTnVtR1BPPTAgTnVtR1BJPTAgR1BJV2FrZT0wIEdQSVVuc29s PTEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMTogIEdQSU8wOiBkaXNhYmxl ZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWExOiAgR1BJTzE6IGRpc2FibGVk Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6ICBHUElPMjogZGlzYWJsZWQK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMTogT3JpZ2luYWwgcGlucyBjb25m aWd1cmF0aW9uOgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWExOiBuaWQgICAw eCAgICBhcyBzZXEgZGV2aWNlICAgICAgIGNvbm4gIGphY2sgICAgbG9jICAgICAgICBjb2xvciAg IG1pc2MKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMTogMTggOTBhNjAxNjAg NiAgMCAgTWljICAgICAgICAgICBGaXhlZCBEaWdpdGFsIEludGVybmFsICAgVW5rbm93biAxCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IDIwIDkwMTcwMTQwIDQgIDAgIFNw ZWFrZXIgICAgICAgRml4ZWQgQW5hbG9nICBJbnRlcm5hbCAgIFVua25vd24gMQpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWExOiAyMyA0MDAwMDAwMCAwICAwICBMaW5lLW91dCAg ICAgIE5vbmUgIFVua25vd24gMHgwMCAgICAgICBVbmtub3duIDAKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBoZGFhMTogMjQgNDExMTExZjAgMTUgMCAgU3BlYWtlciAgICAgICBOb25l ICAxLzggICAgIFJlYXIgICAgICAgQmxhY2sgICAxCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogaGRhYTE6IDI1IDQxMTExMWYwIDE1IDAgIFNwZWFrZXIgICAgICAgTm9uZSAgMS84ICAg ICBSZWFyICAgICAgIEJsYWNrICAgMQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhk YWExOiAyNiA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAg ICAgICBCbGFjayAgIDEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMTogMjcg NDExMTExZjAgMTUgMCAgU3BlYWtlciAgICAgICBOb25lICAxLzggICAgIFJlYXIgICAgICAgQmxh Y2sgICAxCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IDI5IDQwNzAwMDAx IDAgIDEgIE1vZGVtLWhhbmRzZXQgTm9uZSAgVW5rbm93biAweDAwICAgICAgIFVua25vd24gMApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWExOiAzMCA0MTExMTFmMCAxNSAwICBT cGVha2VyICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFjayAgIDEKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMTogMzMgMDIyMTEwNTAgNSAgMCAgSGVhZHBob25l cyAgICBKYWNrICAxLzggICAgIEZyb250ICAgICAgQmxhY2sgICAwCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogaGRhYTE6IFBhdGNoaW5nIHdpZGdldCBjYXBzIG5pZD0yOSAweDAwNDAw NDAwIC0+IDB4MDA3MDA0MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMTog UGF0Y2hlZCBwaW5zIGNvbmZpZ3VyYXRpb246Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogaGRhYTE6IG5pZCAgIDB4ICAgIGFzIHNlcSBkZXZpY2UgICAgICAgY29ubiAgamFjayAgICBs b2MgICAgICAgIGNvbG9yICAgbWlzYwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhk YWExOiAxOCA5MGE2MDE2MCA2ICAwICBNaWMgICAgICAgICAgIEZpeGVkIERpZ2l0YWwgSW50ZXJu YWwgICBVbmtub3duIDEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMTogMjAg OTAxNzAxNDAgNCAgMCAgU3BlYWtlciAgICAgICBGaXhlZCBBbmFsb2cgIEludGVybmFsICAgVW5r bm93biAxCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IDIzIDQwMDAwMDAw IDAgIDAgIExpbmUtb3V0ICAgICAgTm9uZSAgVW5rbm93biAweDAwICAgICAgIFVua25vd24gMCBE SVNBCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IDI0IDQxMTExMWYwIDE1 IDAgIFNwZWFrZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMSBESVNB Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IDI1IDQxMTExMWYwIDE1IDAg IFNwZWFrZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMSBESVNBCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IDI2IDQxMTExMWYwIDE1IDAgIFNw ZWFrZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMSBESVNBCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IDI3IDQxMTExMWYwIDE1IDAgIFNwZWFr ZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMSBESVNBCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IDMwIDQxMTExMWYwIDE1IDAgIFNwZWFrZXIg ICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMSBESVNBCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IDMzIDAyMjExMDUwIDUgIDAgIEhlYWRwaG9uZXMg ICAgSmFjayAgMS84ICAgICBGcm9udCAgICAgIEJsYWNrICAgMApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IGhkYWExOiAzIGFzc29jaWF0aW9ucyBmb3VuZDoKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBoZGFhMTogQXNzb2NpYXRpb24gMCAoNCkgb3V0OgpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWExOiAgUGluIG5pZD0yMCBzZXE9MApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWExOiBBc3NvY2lhdGlvbiAxICg1KSBvdXQ6Ck1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6ICBQaW4gbmlkPTMzIHNlcT0wCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IEFzc29jaWF0aW9uIDIgKDYpIGluOgpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWExOiAgUGluIG5pZD0xOCBzZXE9MApN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWExOiBUcmFjaW5nIGFzc29jaWF0aW9u IDAgKDQpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6ICBQaW4gMjAgdHJh Y2VkIHRvIERBQyAyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IEFzc29j aWF0aW9uIDAgKDQpIHRyYWNlIHN1Y2NlZWRlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IGhkYWExOiBUcmFjaW5nIGFzc29jaWF0aW9uIDEgKDUpCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogaGRhYTE6ICBQaW4gMzMgdHJhY2VkIHRvIERBQyAzCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IEFzc29jaWF0aW9uIDEgKDUpIHRyYWNlIHN1Y2NlZWRl ZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWExOiBUcmFjaW5nIGFzc29jaWF0 aW9uIDIgKDYpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6ICBQaW4gMTgg dHJhY2VkIHRvIEFEQyA4Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogaGRhYTE6IEFz c29jaWF0aW9uIDIgKDYpIHRyYWNlIHN1Y2NlZWRlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IGhkYWExOiBMb29raW5nIGZvciBhZGRpdGlvbmFsIERBQyBmb3IgYXNzb2NpYXRpb24g MCAoNCkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMTogTG9va2luZyBmb3Ig YWRkaXRpb25hbCBEQUMgZm9yIGFzc29jaWF0aW9uIDEgKDUpCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogaGRhYTE6IExvb2tpbmcgZm9yIGFkZGl0aW9uYWwgQURDIGZvciBhc3NvY2lh dGlvbiAyICg2KQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWExOiBUcmFjaW5n IGlucHV0IG1vbml0b3IKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBoZGFhMTogIFRy YWNpbmcgbmlkIDM1IHRvIG91dApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGhkYWEx OiBUcmFjaW5nIG90aGVyIGlucHV0IG1vbml0b3JzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogaGRhYTE6ICBUcmFjaW5nIG5pZCAxOCB0byBvdXQKTWFyIDI1IDE5OjA4OjAwIGRlbGxi c2Qga2VybmVsOiBoZGFhMTogVHJhY2luZyBiZWVwZXIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBoZGFhMTogIG5pZCAyOSB0cmFjZWQgdG8gb3V0Ck1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogaGRhYTE6IEZHIGNvbmZpZy9xdWlya3M6IGZvcmNlc3RlcmVvIGl2cmVmNTAg aXZyZWY4MCBpdnJlZjEwMCBpdnJlZgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBj bTE6IDxSZWFsdGVrIEFMQzI1NSAoSW50ZXJuYWwgQW5hbG9nKT4gYXQgbmlkIDIwIGFuZCAxOCBv biBoZGFhMQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6IFBsYXliYWNrOgpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6ICAgICAgU3RyZWFtIGNhcDogMHgw MDAwMDAwMSBQQ00KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20xOiAgICAgICAg IFBDTSBjYXA6IDB4MDAwZTAwNjAgMTYgMjAgMjQgYml0cywgNDQgNDggS0h6Ck1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTogICAgICAgICAgICAgREFDOiAyCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTogCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNtMTogICAgIG5pZD0yMCBbcGluOiBTcGVha2VyIChGaXhlZCldCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogcGNtMTogICAgICAgKyA8LSBuaWQ9MTIgW2F1ZGlvIG1peGVyXSBb c3JjOiBwY20sIHNwZWFrZXJdCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTog ICAgICAgICAgICAgICsgPC0gbmlkPTIgW2F1ZGlvIG91dHB1dF0gW3NyYzogcGNtXQpNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6ICAgICAgICAgICAgICArIDwtIG5pZD0xMSBb YXVkaW8gbWl4ZXJdIFtzcmM6IHNwZWFrZXJdCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNtMTogICAgICAgICAgICAgICAgICAgICArIDwtIG5pZD0yOSBbYmVlcCB3aWRnZXRdIFtz cmM6IHNwZWFrZXJdCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTogCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTogUmVjb3JkOgpNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IHBjbTE6ICAgICAgU3RyZWFtIGNhcDogMHgwMDAwMDAwMSBQQ00KTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20xOiAgICAgICAgIFBDTSBjYXA6IDB4MDAw ZTA1NjAgMTYgMjAgMjQgYml0cywgNDQgNDggOTYgMTkyIEtIegpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHBjbTE6ICAgICAgICAgICAgIEFEQzogOApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHBjbTE6IApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6 ICAgICBuaWQ9OCBbYXVkaW8gaW5wdXRdCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog cGNtMTogICAgICAgKyA8LSBuaWQ9MzUgW2F1ZGlvIG1peGVyXSBbc3JjOiBzcGVha2VyLCBtb25p dG9yXQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6ICAgICAgICAgICAgICAr IDwtIG5pZD0yOSBbYmVlcCB3aWRnZXRdIFtzcmM6IHNwZWFrZXJdCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogcGNtMTogICAgICAgICAgICAgICsgPC0gbmlkPTExIFthdWRpbyBtaXhl cl0gW3NyYzogc3BlYWtlcl0KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20xOiAg ICAgICAgICAgICAgICAgICAgICsgPC0gbmlkPTI5IFtiZWVwIHdpZGdldF0gW3NyYzogc3BlYWtl cl0KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20xOiAgICAgICAgICAgICAgKyA8 LSBuaWQ9MTggW3BpbjogTWljIChGaXhlZCldIFtzcmM6IG1vbml0b3JdCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogcGNtMTogCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog cGNtMTogTWFzdGVyIFZvbHVtZSAoT1NTOiB2b2wpOiAtNjUvMGRCCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogcGNtMTogICAgKy0gY3RsICAxIChuaWQgICAyIG91dCk6ICAgIC02NS8w ZEIgKDg4IHN0ZXBzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6ICAgICst IGN0bCAxMCAobmlkICAxMiBpbiAgIDApOiBtdXRlCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogcGNtMTogICAgKy0gY3RsIDExIChuaWQgIDEyIGluICAgMSk6IG11dGUKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20xOiAgICArLSBjdGwgMTYgKG5pZCAgMjAgaW4gKTog ICAgbXV0ZQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6IApNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6IFBDTSBWb2x1bWUgKE9TUzogcGNtKTogLTY1LzBk QgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6ICAgICstIGN0bCAgMSAobmlk ICAgMiBvdXQpOiAgICAtNjUvMGRCICg4OCBzdGVwcykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBwY20xOiAgICArLSBjdGwgMTAgKG5pZCAgMTIgaW4gICAwKTogbXV0ZQpNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6IApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBjbTE6IE1pY3JvcGhvbmUyIFZvbHVtZSAoT1NTOiBtb25pdG9yKTogMC8zMGRCCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTogICAgKy0gY3RsIDE1IChuaWQgIDE4 IG91dCk6ICAgIDAvMzBkQiAoNCBzdGVwcykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBwY20xOiAgICArLSBjdGwgMzYgKG5pZCAgMzUgaW4gICA2KTogbXV0ZQpNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6IApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IHBjbTE6IFNwZWFrZXIvQmVlcCBWb2x1bWUgKE9TUzogc3BlYWtlcik6IC0zNC8xMmRCCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTogICAgKy0gY3RsICA5IChuaWQgIDExIGlu ICAgNCk6IC0zNC8xMmRCICgzMiBzdGVwcykgKyBtdXRlCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcGNtMTogICAgKy0gY3RsIDExIChuaWQgIDEyIGluICAgMSk6IG11dGUKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20xOiAgICArLSBjdGwgMzQgKG5pZCAgMzUgaW4g ICA0KTogbXV0ZQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6ICAgICstIGN0 bCAzNSAobmlkICAzNSBpbiAgIDUpOiBtdXRlCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNtMTogCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTogUmVjb3JkaW5n IExldmVsIChPU1M6IHJlYyk6IC0xNy8zMGRCCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNtMTogICAgKy0gY3RsICAzIChuaWQgICA4IGluICAgMCk6IC0xNy8zMGRCICg2NCBzdGVw cykgKyBtdXRlCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTogICAgKy0gY3Rs IDE1IChuaWQgIDE4IG91dCk6ICAgIDAvMzBkQiAoNCBzdGVwcykKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBwY20xOiAgICArLSBjdGwgMzQgKG5pZCAgMzUgaW4gICA0KTogbXV0ZQpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6ICAgICstIGN0bCAzNSAobmlkICAz NSBpbiAgIDUpOiBtdXRlCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTogICAg Ky0gY3RsIDM2IChuaWQgIDM1IGluICAgNik6IG11dGUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBwY20xOiAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20xOiBJbnB1 dCBNb25pdG9yaW5nIExldmVsIChPU1M6IGlnYWluKTogMC8wZEIKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBwY20xOiAgICArLSBjdGwgMTEgKG5pZCAgMTIgaW4gICAxKTogbXV0ZQpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6IApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHBjbTE6IE1peGVyICJ2b2wiOgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBjbTE6IE1peGVyICJwY20iOgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IHBjbTE6IE1peGVyICJzcGVha2VyIjoKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBw Y20xOiBNaXhlciAicmVjIjoKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20xOiBN aXhlciAiaWdhaW4iOgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6IE1peGVy ICJvZ2FpbiI6Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTogTWl4ZXIgIm1v bml0b3IiOgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTE6IFBsYXliYWNrIGNo YW5uZWwgc2V0IGlzOiBGcm9udCBMZWZ0LCBGcm9udCBSaWdodCwgCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogcGNtMTogUGxheWJhY2sgY2hhbm5lbCBtYXRyaXggaXM6IDIuMCAodW5r bm93bikKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20xOiBBdXRvbWF0aWNhbGx5 IHNldCByZWMgc291cmNlIHRvOiBtb25pdG9yCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNtMTogUmVjb3JkaW5nIGNoYW5uZWwgc2V0IGlzOiBGcm9udCBMZWZ0LCBGcm9udCBSaWdo dCwgCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMTogUmVjb3JkaW5nIGNoYW5u ZWwgbWF0cml4IGlzOiAyLjAgKHVua25vd24pCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNtMjogPFJlYWx0ZWsgQUxDMjU1IChGcm9udCBBbmFsb2cgSGVhZHBob25lcyk+IGF0IG5p ZCAzMyBvbiBoZGFhMQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTI6IFBsYXli YWNrOgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTI6ICAgICAgU3RyZWFtIGNh cDogMHgwMDAwMDAwMSBQQ00KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20yOiAg ICAgICAgIFBDTSBjYXA6IDB4MDAwZTAwNjAgMTYgMjAgMjQgYml0cywgNDQgNDggS0h6Ck1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMjogICAgICAgICAgICAgREFDOiAzCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMjogCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcGNtMjogICAgIG5pZD0zMyBbcGluOiBIZWFkcGhvbmVzIChCbGFjayBKYWNrKV0K TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20yOiAgICAgICArIDwtIG5pZD0xMyBb YXVkaW8gbWl4ZXJdIFtzcmM6IHBjbSwgc3BlYWtlcl0KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBwY20yOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MyBbYXVkaW8gb3V0cHV0XSBbc3Jj OiBwY21dCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMjogICAgICAgICAgICAg ICsgPC0gbmlkPTExIFthdWRpbyBtaXhlcl0gW3NyYzogc3BlYWtlcl0KTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBwY20yOiAgICAgICAgICAgICAgICAgICAgICsgPC0gbmlkPTI5IFti ZWVwIHdpZGdldF0gW3NyYzogc3BlYWtlcl0KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBwY20yOiAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20yOiBNYXN0ZXIgVm9s dW1lIChPU1M6IHZvbCk6IC02NS8wZEIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBw Y20yOiAgICArLSBjdGwgIDIgKG5pZCAgIDMgb3V0KTogICAgLTY1LzBkQiAoODggc3RlcHMpCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMjogICAgKy0gY3RsIDEyIChuaWQgIDEz IGluICAgMCk6IG11dGUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20yOiAgICAr LSBjdGwgMTMgKG5pZCAgMTMgaW4gICAxKTogbXV0ZQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBjbTI6ICAgICstIGN0bCAyMyAobmlkICAzMyBpbiApOiAgICBtdXRlCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMjogCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogcGNtMjogUENNIFZvbHVtZSAoT1NTOiBwY20pOiAtNjUvMGRCCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogcGNtMjogICAgKy0gY3RsICAyIChuaWQgICAzIG91dCk6ICAgIC02 NS8wZEIgKDg4IHN0ZXBzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjbTI6ICAg ICstIGN0bCAxMiAobmlkICAxMyBpbiAgIDApOiBtdXRlCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcGNtMjogCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMjogU3Bl YWtlci9CZWVwIFZvbHVtZSAoT1NTOiBzcGVha2VyKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBjbTI6ICAgICstIGN0bCAxMyAobmlkICAxMyBpbiAgIDEpOiBtdXRlCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMjogCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogcGNtMjogSW5wdXQgTW9uaXRvcmluZyBMZXZlbCAoT1NTOiBpZ2Fpbik6IDAvMGRCCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNtMjogICAgKy0gY3RsIDEzIChuaWQgIDEz IGluICAgMSk6IG11dGUKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20yOiAKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20yOiBNaXhlciAidm9sIjoKTWFyIDI1IDE5 OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20yOiBNaXhlciAicGNtIjoKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBwY20yOiBNaXhlciAiaWdhaW4iOgpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHBjbTI6IE1peGVyICJvZ2FpbiI6Ck1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcGNtMjogUGxheWJhY2sgY2hhbm5lbCBzZXQgaXM6IEZyb250IExlZnQsIEZyb250 IFJpZ2h0LCAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY20yOiBQbGF5YmFjayBj aGFubmVsIG1hdHJpeCBpczogMi4wIChkaXNjb25uZWN0ZWQpCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogcGNpMDogZHJpdmVyIGFkZGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxNTM3LCByZXZpZD0weDAwCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWRvbWFpbj0wLCBidXM9MCwgc2xvdD04LCBmdW5j PTAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJY2xhc3M9MTAtODAtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAljbWRyZWc9 MHgwMDA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiAJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog CXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IAlNU0ktWCBzdXBwb3J0cyAyIG1lc3NhZ2VzIGluIG1hcCAweDI0Ck1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpMDowOjg6MDogcmVwcm9iaW5nIG9uIGRy aXZlciBhZGRlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGZvdW5kLT4JdmVuZG9y PTB4MTAyMiwgZGV2PTB4NzgwYiwgcmV2aWQ9MHg0MgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IAlkb21haW49MCwgYnVzPTAsIHNsb3Q9MjAsIGZ1bmM9MApNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IAljbGFzcz0wYy0wNS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWNtZHJlZz0weDA0MDMsIHN0YXRyZWc9MHgw MjIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IAlsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2kwOjA6MjA6MDogcmVwcm9i aW5nIG9uIGRyaXZlciBhZGRlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaTE6 IGRyaXZlciBhZGRlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaTI6IGRyaXZl ciBhZGRlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHVnZW4yLjE6IDxBTUQgRUhD SSByb290IEhVQj4gYXQgdXNidXMyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogdWh1 YjA6IDxBTUQgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+ IG9uIHVzYnVzMgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHVnZW4wLjE6IDwweDEw MjIgWEhDSSByb290IEhVQj4gYXQgdXNidXMwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogdWdlbjEuMTogPEFNRCBFSENJIHJvb3QgSFVCPiBhdCB1c2J1czEKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiB1aHViMTogPDB4MTAyMiBYSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAs IHJldiAzLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9ncHQvZmJzZDEyIFty d10uLi4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBSb290IG1vdW50IHdhaXRpbmcg Zm9yOiB1c2J1czB1aHViMjogIENBTTxBTUQgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYg Mi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6ICB1c2J1czEgdXNidXMyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogR0VPTTog bmV3IGRpc2sgYWRhMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFkYTAgYXQgYWhj aWNoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBhZGEwOiA8TVRGRERBSzEyOE1BTS0xSjEgMDcwSD4gQUNTLTIgQVRBIFNBVEEgMy54 IGRldmljZQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFkYTA6IFNlcmlhbCBOdW1i ZXIgMTQyMDBDMjJCODZCCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYWRhMDogNjAw LjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDMueCwgVURNQTUsIFBJTyA4MTkyYnl0ZXMpCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYWRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVk Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogYWRhMDogMTIyMTA0TUIgKDI1MDA2OTY4 MCA1MTIgYnl0ZSBzZWN0b3JzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBhc3Mw IGF0IGFoY2ljaDAgYnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAwCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogcGFzczA6IDxNVEZEREFLMTI4TUFNLTFKMSAwNzBIPiBBQ1MtMiBBVEEg U0FUQSAzLnggZGV2aWNlCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGFzczA6IFNl cmlhbCBOdW1iZXIgMTQyMDBDMjJCODZCCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog cGFzczA6IDYwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAzLngsIFVETUE1LCBQSU8gODE5MmJ5 dGVzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBhc3MwOiBDb21tYW5kIFF1ZXVl aW5nIGVuYWJsZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwYXNzMSBhdCBhaGNp Y2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4gMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBhc3MxOiA8UExEUyBEVkQrLVJXIERVLThBNUxIIDZEMTE+IFJlbW92YWJsZSBDRC1S T00gU0NTSSBkZXZpY2UKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwYXNzMTogU2Vy aWFsIE51bWJlciBZWUNSVzczNjM5NjcxN1BWUkEwNApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHBhc3MxOiAxNTAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMS54LCBVRE1BNiwgQVRB UEkgMTJieXRlcywgUElPIDgxOTJieXRlcykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVs OiBjZDAgYXQgYWhjaWNoMSBidXMgMCBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBjZDA6IDxQTERTIERWRCstUlcgRFUtOEE1TEggNkQxMT4gUmVt b3ZhYmxlIENELVJPTSBTQ1NJIGRldmljZQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IGNkMDogU2VyaWFsIE51bWJlciBZWUNSVzczNjM5NjcxN1BWUkEwNApNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IGNkMDogMTUwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDEueCwgVURN QTYsIEFUQVBJIDEyYnl0ZXMsIFBJTyA4MTkyYnl0ZXMpCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogY2QwOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJF QURZLCBNZWRpdW0gbm90IHByZXNlbnQgLSB0cmF5IGNsb3NlZApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IEdFT006IG5ldyBkaXNrIGNkMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IHVodWIxOiA0IHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVz MCB1c2J1czEgdXNidXMyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogdWh1YjI6IDIg cG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogdWdlbjAuMjogPFN1WWluIEludGVncmF0ZWRXZWJjYW1IRD4gYXQgdXNidXMw Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogdWdl bjEuMjogPHZlbmRvciAweDA0MzggcHJvZHVjdCAweDc5MDA+IGF0IHVzYnVzMQpNYXIgMjUgMTk6 MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHVodWIzIG9uIHVodWIyCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogdWh1YjM6IDx2ZW5kb3IgMHgwNDM4IHByb2R1Y3QgMHg3OTAwLCBjbGFzcyA5 LzAsIHJldiAyLjAwLzAuMTgsIGFkZHIgMj4gb24gdXNidXMxCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogdWdlbjIuMjogPHZlbmRvciAweDA0MzggcHJvZHVjdCAweDc5MDA+IGF0IHVz YnVzMgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHVodWI0IG9uIHVodWIwCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogdWh1YjQ6IDx2ZW5kb3IgMHgwNDM4IHByb2R1Y3Qg MHg3OTAwLCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMTgsIGFkZHIgMj4gb24gdXNidXMyCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMx IHVzYnVzMgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHVodWI0OiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IHVodWIzOiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHVnZW4yLjM6IDx2ZW5kb3IgMHgwY2YzIHByb2R1Y3Qg MHhlMDA1PiBhdCB1c2J1czIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiB1Z2VuMS4z OiA8R2VuZXJpYyBVU0IyLjAtQ1JXPiBhdCB1c2J1czEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiB1Z2VuMS40OiA8dmVuZG9yIDB4MDZjYiBwcm9kdWN0IDB4NzViZj4gYXQgdXNidXMx Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogbW91bnRyb290OiB3YWl0aW5nIGZvciBk ZXZpY2UgL2Rldi9ncHQvZmJzZDEyLi4uCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog ZWZpcnRjMDogcHJvdmlkaW5nIGluaXRpYWwgc3lzdGVtIHRpbWUKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vaW5pdApNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IGFub25faW5vZGVmcyByZWdpc3RlcmVkCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogZGVidWdmcyByZWdpc3RlcmVkCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogW2RybV0gYW1kZ3B1IGtlcm5lbCBtb2Rlc2V0dGluZyBlbmFibGVkLgpNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGRybW4wOiA8ZHJtbj4gb24gdmdhcGNpMApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHZnYXBjaTA6IGNoaWxkIGRybW4wIHJlcXVlc3Rl ZCBwY2lfZW5hYmxlX2lvCk1hciAyNSAxOTowODowMCBkZWxsYnNkIHN5c2xvZ2Q6IGxhc3QgbWVz c2FnZSByZXBlYXRlZCAxIHRpbWVzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2Ry bV0gaW5pdGlhbGl6aW5nIGtlcm5lbCBtb2Rlc2V0dGluZyAoTVVMTElOUyAweDEwMDI6MHg5ODUx IDB4MTAyODoweDA2QkYgMHg0NSkuCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2Ry bV0gcmVnaXN0ZXIgbW1pbyBiYXNlOiAweEZFQjAwMDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogW2RybV0gcmVnaXN0ZXIgbW1pbyBzaXplOiAyNjIxNDQKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBbZHJtXSBQQ0kgSS9PIEJBUiBpcyBub3QgZm91bmQuCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogW2RybV0gcHJvYmluZyBtbHcgZm9yIGRldmljZSAxMDAy Ojk4NTEgPSAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogQVRPTSBCSU9TOiBCUjQ2 MTkzLjAwMQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFtkcm1dIHZtIHNpemUgaXMg NjQgR0IsIDIgbGV2ZWxzLCBibG9jayBzaXplIGlzIDEwLWJpdCwgZnJhZ21lbnQgc2l6ZSBpcyA5 LWJpdApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGRybW4wOiBWUkFNOiA1MTJNIDB4 MDAwMDAwRjQwMDAwMDAwMCAtIDB4MDAwMDAwRjQxRkZGRkZGRiAoNTEyTSB1c2VkKQpNYXIgMjUg MTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGRybW4wOiBHVFQ6IDEwMjRNIDB4MDAwMDAwMDAwMDAw MDAwMCAtIDB4MDAwMDAwMDAzRkZGRkZGRgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IFN1Y2Nlc3NmdWxseSBhZGRlZCBXQyBNVFJSIGZvciBbMHhjMDAwMDAwMC0weGRmZmZmZmZmXTog MDsgCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2RybV0gRGV0ZWN0ZWQgVlJBTSBS QU09NTEyTSwgQkFSPTUxMk0KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBbZHJtXSBS QU0gd2lkdGggNjRiaXRzIFVOS05PV04KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBb VFRNXSBab25lICBrZXJuZWw6IEF2YWlsYWJsZSBncmFwaGljcyBtZW1vcnk6IDE3ODUzMjgga2lC Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW1RUTV0gSW5pdGlhbGl6aW5nIHBvb2wg YWxsb2NhdG9yCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2RybV0gYW1kZ3B1OiA1 MTJNIG9mIFZSQU0gbWVtb3J5IHJlYWR5Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog W2RybV0gYW1kZ3B1OiAyNjE1TSBvZiBHVFQgbWVtb3J5IHJlYWR5LgpNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IGlfc2l6ZV93cml0ZSB1bmltcGxlbWVudGVkCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogW2RybV0gR0FSVDogbnVtIGNwdSBwYWdlcyAyNjIxNDQsIG51bSBn cHUgcGFnZXMgMjYyMTQ0Ck1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2RybV0gUENJ RSBHQVJUIG9mIDEwMjRNIGVuYWJsZWQgKHRhYmxlIGF0IDB4MDAwMDAwRjQwMDA0MDAwMCkuCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogdmdhcGNpMDogYXR0ZW1wdGluZyB0byBhbGxv Y2F0ZSAxIE1TSSB2ZWN0b3JzICgxIHN1cHBvcnRlZCkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBtc2k6IHJvdXRpbmcgTVNJIElSUSAyNjkgdG8gbG9jYWwgQVBJQyAxIHZlY3RvciA1 MQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHZnYXBjaTA6IHVzaW5nIElSUSAyNjkg Zm9yIE1TSQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFtkcm1dIFN1cHBvcnRzIHZi bGFuayB0aW1lc3RhbXAgY2FjaGluZyBSZXYgMiAoMjEuMTAuMjAxMykuCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogW2RybV0gRHJpdmVyIHN1cHBvcnRzIHByZWNpc2UgdmJsYW5rIHRp bWVzdGFtcCBxdWVyeS4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBbZHJtXSBJbnRl cm5hbCB0aGVybWFsIGNvbnRyb2xsZXIgd2l0aG91dCBmYW4gY29udHJvbApNYXIgMjUgMTk6MDg6 MDAgZGVsbGJzZCBrZXJuZWw6IFtkcm1dIGFtZGdwdTogZHBtIGluaXRpYWxpemVkCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogW2RybV0gQ29ubmVjdG9yIGVEUC0xOiBnZXQgbW9kZSBm cm9tIHR1bmFibGVzOgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFtkcm1dICAgLSBr ZXJuLnZ0LmZiLm1vZGVzLmVEUC0xCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2Ry bV0gICAtIGtlcm4udnQuZmIuZGVmYXVsdF9tb2RlCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogW2RybV0gQ29ubmVjdG9yIEhETUktQS0xOiBnZXQgbW9kZSBmcm9tIHR1bmFibGVzOgpN YXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFtkcm1dICAgLSBrZXJuLnZ0LmZiLm1vZGVz LkhETUktQS0xCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2RybV0gICAtIGtlcm4u dnQuZmIuZGVmYXVsdF9tb2RlCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2RybV0g YW1kZ3B1IGF0b20gRElHIGJhY2tsaWdodCBpbml0aWFsaXplZApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IFtkcm1dIEFNREdQVSBEaXNwbGF5IENvbm5lY3RvcnMKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBbZHJtXSBDb25uZWN0b3IgMDoKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBbZHJtXSAgIGVEUC0xCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogW2RybV0gICBIUEQxCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2RybV0gICBE REM6IDB4MTk0YyAweDE5NGMgMHgxOTRkIDB4MTk0ZCAweDE5NGUgMHgxOTRlIDB4MTk0ZiAweDE5 NGYKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBbZHJtXSAgIEVuY29kZXJzOgpNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFtkcm1dICAgICBMQ0QxOiBJTlRFUk5BTF9VTklQ SFkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBbZHJtXSBDb25uZWN0b3IgMToKTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBbZHJtXSAgIEhETUktQS0xCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogW2RybV0gICBIUEQyCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogW2RybV0gICBEREM6IDB4MTk1MCAweDE5NTAgMHgxOTUxIDB4MTk1MSAweDE5NTIg MHgxOTUyIDB4MTk1MyAweDE5NTMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBbZHJt XSAgIEVuY29kZXJzOgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFtkcm1dICAgICBE RlAxOiBJTlRFUk5BTF9VTklQSFkKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBmaXJt d2FyZTogJ3JhZGVvbl9tdWxsaW5zX3BmcF9iaW4nIHZlcnNpb24gMDogODgzMiBieXRlcyBsb2Fk ZWQgYXQgMHhmZmZmZmZmZjgyZjg0MDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDog cmFkZW9uL211bGxpbnNfcGZwLmJpbjogY291bGQgbm90IGxvYWQgZmlybXdhcmUgaW1hZ2UsIGVy cm9yIDIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBkcm1uMDogZmFpbCAoMCkgdG8g Z2V0IGZpcm13YXJlIGltYWdlIHdpdGggbmFtZTogcmFkZW9uL211bGxpbnNfcGZwLmJpbgpNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGRybW4wOiBzdWNjZXNzZnVsbHkgbG9hZGVkIGZp cm13YXJlIGltYWdlIHdpdGggbWFwcGVkIG5hbWU6IHJhZGVvbl9tdWxsaW5zX3BmcF9iaW4KTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBmaXJtd2FyZTogJ3JhZGVvbl9tdWxsaW5zX21l X2JpbicgdmVyc2lvbiAwOiA4ODMyIGJ5dGVzIGxvYWRlZCBhdCAweGZmZmZmZmZmODJmODcwMDAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiByYWRlb24vbXVsbGluc19tZS5iaW46IGNv dWxkIG5vdCBsb2FkIGZpcm13YXJlIGltYWdlLCBlcnJvciAyCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogZHJtbjA6IGZhaWwgKDApIHRvIGdldCBmaXJtd2FyZSBpbWFnZSB3aXRoIG5h bWU6IHJhZGVvbi9tdWxsaW5zX21lLmJpbgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IGRybW4wOiBzdWNjZXNzZnVsbHkgbG9hZGVkIGZpcm13YXJlIGltYWdlIHdpdGggbWFwcGVkIG5h bWU6IHJhZGVvbl9tdWxsaW5zX21lX2JpbgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6 IGZpcm13YXJlOiAncmFkZW9uX211bGxpbnNfY2VfYmluJyB2ZXJzaW9uIDA6IDg4MzIgYnl0ZXMg bG9hZGVkIGF0IDB4ZmZmZmZmZmY4MmY4YTAwMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IHJhZGVvbi9tdWxsaW5zX2NlLmJpbjogY291bGQgbm90IGxvYWQgZmlybXdhcmUgaW1hZ2Us IGVycm9yIDIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBkcm1uMDogZmFpbCAoMCkg dG8gZ2V0IGZpcm13YXJlIGltYWdlIHdpdGggbmFtZTogcmFkZW9uL211bGxpbnNfY2UuYmluCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogZHJtbjA6IHN1Y2Nlc3NmdWxseSBsb2FkZWQg ZmlybXdhcmUgaW1hZ2Ugd2l0aCBtYXBwZWQgbmFtZTogcmFkZW9uX211bGxpbnNfY2VfYmluCk1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogZmlybXdhcmU6ICdyYWRlb25fbXVsbGluc19t ZWNfYmluJyB2ZXJzaW9uIDA6IDE3MDI0IGJ5dGVzIGxvYWRlZCBhdCAweGZmZmZmZmZmODJmOGQw MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiByYWRlb24vbXVsbGluc19tZWMuYmlu OiBjb3VsZCBub3QgbG9hZCBmaXJtd2FyZSBpbWFnZSwgZXJyb3IgMgpNYXIgMjUgMTk6MDg6MDAg ZGVsbGJzZCBrZXJuZWw6IGRybW4wOiBmYWlsICgwKSB0byBnZXQgZmlybXdhcmUgaW1hZ2Ugd2l0 aCBuYW1lOiByYWRlb24vbXVsbGluc19tZWMuYmluCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogZHJtbjA6IHN1Y2Nlc3NmdWxseSBsb2FkZWQgZmlybXdhcmUgaW1hZ2Ugd2l0aCBtYXBw ZWQgbmFtZTogcmFkZW9uX211bGxpbnNfbWVjX2JpbgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBr ZXJuZWw6IGZpcm13YXJlOiAncmFkZW9uX211bGxpbnNfcmxjX2JpbicgdmVyc2lvbiAwOiAxMDQ5 NiBieXRlcyBsb2FkZWQgYXQgMHhmZmZmZmZmZjgyZjkyMDAwCk1hciAyNSAxOTowODowMCBkZWxs YnNkIGtlcm5lbDogcmFkZW9uL211bGxpbnNfcmxjLmJpbjogY291bGQgbm90IGxvYWQgZmlybXdh cmUgaW1hZ2UsIGVycm9yIDIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBkcm1uMDog ZmFpbCAoMCkgdG8gZ2V0IGZpcm13YXJlIGltYWdlIHdpdGggbmFtZTogcmFkZW9uL211bGxpbnNf cmxjLmJpbgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGRybW4wOiBzdWNjZXNzZnVs bHkgbG9hZGVkIGZpcm13YXJlIGltYWdlIHdpdGggbWFwcGVkIG5hbWU6IHJhZGVvbl9tdWxsaW5z X3JsY19iaW4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBpX3NpemVfd3JpdGUgdW5p bXBsZW1lbnRlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBzeXNsb2dkOiBsYXN0IG1lc3NhZ2Ug cmVwZWF0ZWQgOCB0aW1lcwpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGZpcm13YXJl OiAncmFkZW9uX211bGxpbnNfc2RtYV9iaW4nIHZlcnNpb24gMDogNDQ1NiBieXRlcyBsb2FkZWQg YXQgMHhmZmZmZmZmZjgyZjk1MDAwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcmFk ZW9uL211bGxpbnNfc2RtYS5iaW46IGNvdWxkIG5vdCBsb2FkIGZpcm13YXJlIGltYWdlLCBlcnJv ciAyCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogZHJtbjA6IGZhaWwgKDApIHRvIGdl dCBmaXJtd2FyZSBpbWFnZSB3aXRoIG5hbWU6IHJhZGVvbi9tdWxsaW5zX3NkbWEuYmluCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogZHJtbjA6IHN1Y2Nlc3NmdWxseSBsb2FkZWQgZmly bXdhcmUgaW1hZ2Ugd2l0aCBtYXBwZWQgbmFtZTogcmFkZW9uX211bGxpbnNfc2RtYV9iaW4KTWFy IDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBmaXJtd2FyZTogJ3JhZGVvbl9tdWxsaW5zX3Nk bWExX2JpbicgdmVyc2lvbiAwOiA0NDU2IGJ5dGVzIGxvYWRlZCBhdCAweGZmZmZmZmZmODJmOTcw MDAKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiByYWRlb24vbXVsbGluc19zZG1hMS5i aW46IGNvdWxkIG5vdCBsb2FkIGZpcm13YXJlIGltYWdlLCBlcnJvciAyCk1hciAyNSAxOTowODow MCBkZWxsYnNkIGtlcm5lbDogZHJtbjA6IGZhaWwgKDApIHRvIGdldCBmaXJtd2FyZSBpbWFnZSB3 aXRoIG5hbWU6IHJhZGVvbi9tdWxsaW5zX3NkbWExLmJpbgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IGRybW4wOiBzdWNjZXNzZnVsbHkgbG9hZGVkIGZpcm13YXJlIGltYWdlIHdpdGgg bWFwcGVkIG5hbWU6IHJhZGVvbl9tdWxsaW5zX3NkbWExX2JpbgpNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IGlfc2l6ZV93cml0ZSB1bmltcGxlbWVudGVkCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIHN5c2xvZ2Q6IGxhc3QgbWVzc2FnZSByZXBlYXRlZCAxIHRpbWVzCk1hciAyNSAxOTow ODowMCBkZWxsYnNkIGtlcm5lbDogZmlybXdhcmU6ICdyYWRlb25fbXVsbGluc191dmRfYmluJyB2 ZXJzaW9uIDA6IDIzMjc1MiBieXRlcyBsb2FkZWQgYXQgMHhmZmZmZmZmZjgyZjk5MDAwCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcmFkZW9uL211bGxpbnNfdXZkLmJpbjogY291bGQg bm90IGxvYWQgZmlybXdhcmUgaW1hZ2UsIGVycm9yIDIKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qg a2VybmVsOiBkcm1uMDogZmFpbCAoMCkgdG8gZ2V0IGZpcm13YXJlIGltYWdlIHdpdGggbmFtZTog cmFkZW9uL211bGxpbnNfdXZkLmJpbgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGRy bW4wOiBzdWNjZXNzZnVsbHkgbG9hZGVkIGZpcm13YXJlIGltYWdlIHdpdGggbWFwcGVkIG5hbWU6 IHJhZGVvbl9tdWxsaW5zX3V2ZF9iaW4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBb ZHJtXSBGb3VuZCBVVkQgZmlybXdhcmUgVmVyc2lvbjogMS42NCBGYW1pbHkgSUQ6IDkKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBpX3NpemVfd3JpdGUgdW5pbXBsZW1lbnRlZApNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGZpcm13YXJlOiAncmFkZW9uX211bGxpbnNfdmNl X2JpbicgdmVyc2lvbiAwOiAxMDEwNzIgYnl0ZXMgbG9hZGVkIGF0IDB4ZmZmZmZmZmY4MmZkMjAw MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHJhZGVvbi9tdWxsaW5zX3ZjZS5iaW46 IGNvdWxkIG5vdCBsb2FkIGZpcm13YXJlIGltYWdlLCBlcnJvciAyCk1hciAyNSAxOTowODowMCBk ZWxsYnNkIGtlcm5lbDogZHJtbjA6IGZhaWwgKDApIHRvIGdldCBmaXJtd2FyZSBpbWFnZSB3aXRo IG5hbWU6IHJhZGVvbi9tdWxsaW5zX3ZjZS5iaW4KTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBkcm1uMDogc3VjY2Vzc2Z1bGx5IGxvYWRlZCBmaXJtd2FyZSBpbWFnZSB3aXRoIG1hcHBl ZCBuYW1lOiByYWRlb25fbXVsbGluc192Y2VfYmluCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtl cm5lbDogW2RybV0gRm91bmQgVkNFIGZpcm13YXJlIFZlcnNpb246IDUwLjEwIEJpbmFyeSBJRDog MgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGlfc2l6ZV93cml0ZSB1bmltcGxlbWVu dGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIHN5c2xvZ2Q6IGxhc3QgbWVzc2FnZSByZXBlYXRl ZCAxIHRpbWVzCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2RybTpnZnhfdjdfMF9y aW5nX3Rlc3RfcmluZ10gYW1kZ3B1OiByaW5nIDAgdGVzdCBmYWlsZWQgKHNjcmF0Y2goMHhDMDQw KT0weENBRkVERUFEKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFtkcm06YW1kZ3B1 X2RldmljZV9pcF9pbml0XSBod19pbml0IG9mIElQIGJsb2NrIDxnZnhfdjdfMD4gZmFpbGVkIC0y MgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGRybW4wOiBhbWRncHVfZGV2aWNlX2lw X2luaXQgZmFpbGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2RybTp1dmRfdjRf Ml9zdGFydF0gVVZEIG5vdCByZXNwb25kaW5nLCB0cnlpbmcgdG8gcmVzZXQgdGhlIFZDUFUhISEK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qgc3lzbG9nZDogbGFzdCBtZXNzYWdlIHJlcGVhdGVkIDkg dGltZXMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBbZHJtOnV2ZF92NF8yX3N0YXJ0 XSBVVkQgbm90IHJlc3BvbmRpbmcsIGdpdmluZyB1cCEhIQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IFtkcm06YW1kZ3B1X2RldmljZV9pcF9zZXRfcG93ZXJnYXRpbmdfc3RhdGVdIHNl dF9wb3dlcmdhdGluZ19zdGF0ZSBvZiBJUCBibG9jayA8dXZkX3Y0XzI+IGZhaWxlZCAtMQpNYXIg MjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFtkcm1dIGFtZGdwdSBhdG9tIExWRFMgYmFja2xp Z2h0IHVubG9hZGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW1RUTV0gRmluYWxp emluZyBwb29sIGFsbG9jYXRvcgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IFtUVE1d IFpvbmUgIGtlcm5lbDogVXNlZCBtZW1vcnkgYXQgZXhpdDogMCBraUIKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiBbZHJtXSBhbWRncHU6IHR0bSBmaW5hbGl6ZWQKTWFyIDI1IDE5OjA4 OjAwIGRlbGxic2Qga2VybmVsOiBkcm1uMDogRmF0YWwgZXJyb3IgZHVyaW5nIEdQVSBpbml0Ck1h ciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogW2RybV0gYW1kZ3B1OiBmaW5pc2hpbmcgZGV2 aWNlLgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGRldmljZV9hdHRhY2g6IGRybW4w IGF0dGFjaCByZXR1cm5lZCAyMgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGFjcGlf d21pMDogPEFDUEktV01JIG1hcHBpbmc+IG9uIGFjcGkwCk1hciAyNSAxOTowODowMCBkZWxsYnNk IGtlcm5lbDogcGNpMDogZHJpdmVyIGFkZGVkCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxNTM3LCByZXZpZD0weDAwCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogCWRvbWFpbj0wLCBidXM9MCwgc2xvdD04LCBmdW5jPTAK TWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiAJY2xhc3M9MTAtODAtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAljbWRyZWc9MHgw MDA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiAJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCXBv d2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IAlNU0ktWCBzdXBwb3J0cyAyIG1lc3NhZ2VzIGluIG1hcCAweDI0Ck1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogcGNpMDowOjg6MDogcmVwcm9iaW5nIG9uIGRyaXZl ciBhZGRlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGZvdW5kLT4JdmVuZG9yPTB4 MTAyMiwgZGV2PTB4NzgwYiwgcmV2aWQ9MHg0MgpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJu ZWw6IAlkb21haW49MCwgYnVzPTAsIHNsb3Q9MjAsIGZ1bmM9MApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IAljbGFzcz0wYy0wNS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCk1hciAy NSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogCWNtZHJlZz0weDA0MDMsIHN0YXRyZWc9MHgwMjIw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQpNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IAls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2kwOjA6MjA6MDogcmVwcm9iaW5n IG9uIGRyaXZlciBhZGRlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IGludHNtYjA6 IDxBTUQgRkNIIFNNQnVzIENvbnRyb2xsZXI+IGF0IGRldmljZSAyMC4wIG9uIHBjaTAKTWFyIDI1 IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiBwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHhjZDYt MHhjZDcpIGZvciByaWQgMCBvZiBpbnRzbWIwCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5l bDogcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4YjAwLTB4YjBmKSBmb3IgcmlkIDAgb2YgaW50 c21iMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHNtYnVzMDogPFN5c3RlbSBNYW5h Z2VtZW50IEJ1cz4gb24gaW50c21iMApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBj aTE6IGRyaXZlciBhZGRlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHBjaTI6IGRy aXZlciBhZGRlZApNYXIgMjUgMTk6MDg6MDAgZGVsbGJzZCBrZXJuZWw6IHdsYW4wOiBicGYgYXR0 YWNoZWQKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qgc3lzbG9nZDogbGFzdCBtZXNzYWdlIHJlcGVh dGVkIDEgdGltZXMKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2VybmVsOiB3bGFuMDogRXRoZXJu ZXQgYWRkcmVzczogOTQ6NTM6MzA6MDg6NGI6MjEKTWFyIDI1IDE5OjA4OjAwIGRlbGxic2Qga2Vy bmVsOiBsbzA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUApNYXIgMjUgMTk6MDg6MDAgZGVsbGJz ZCBrZXJuZWw6IHdsYW4wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKTWFyIDI1IDE5OjA4OjAw IGRlbGxic2Qga2VybmVsOiByZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dOCk1hciAyNSAx OTowODowMCBkZWxsYnNkIGtlcm5lbDogdWJ0MCBvbiB1aHViNApNYXIgMjUgMTk6MDg6MDAgZGVs bGJzZCBrZXJuZWw6IHVidDA6IDx2ZW5kb3IgMHgwY2YzIHByb2R1Y3QgMHhlMDA1LCBjbGFzcyAy MjQvMSwgcmV2IDEuMTAvMC4wMSwgYWRkciAzPiBvbiB1c2J1czIKTWFyIDI1IDE5OjA4OjAwIGRl bGxic2Qga2VybmVsOiBXQVJOSU5HOiBhdHRlbXB0IHRvIGRvbWFpbl9hZGQoYmx1ZXRvb3RoKSBh ZnRlciBkb21haW5maW5hbGl6ZSgpCk1hciAyNSAxOTowODowMCBkZWxsYnNkIGtlcm5lbDogV0FS TklORzogYXR0ZW1wdCB0byBkb21haW5fYWRkKG5ldGdyYXBoKSBhZnRlciBkb21haW5maW5hbGl6 ZSgpCk1hciAyNSAxOToxMToyNyBkZWxsYnNkIHN5c2xvZ2Q6IGV4aXRpbmcgb24gc2lnbmFsIDE1 CkZyZWVCU0QgZGVsbGJzZCAxMi4zLVNUQUJMRSBGcmVlQlNEIDEyLjMtU1RBQkxFIHIzNzE3MjEg R0VORVJJQyAgYW1kNjQK --=_5167f7822564b81f04ce6019023092e5 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_5167f7822564b81f04ce6019023092e5-- From nobody Sat Mar 26 12:41:17 2022 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 6C17C1A37226 for ; Sat, 26 Mar 2022 12:41:34 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic311-23.consmr.mail.ne1.yahoo.com (sonic311-23.consmr.mail.ne1.yahoo.com [66.163.188.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQdqx1FVsz4s4F for ; Sat, 26 Mar 2022 12:41:33 +0000 (UTC) (envelope-from filippomore@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648298486; bh=0bv5SEitoxsB2bRY+y/i9VgZC0Qg+vG5Pp92qm04G9o=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=QP57Tq6lLINd/xSAKqHQyUbatvPaqPxAJBM8zOj6L/rdQKeuvls65V2CeUl2+qzY0LGS7QL3rgVby2kMPq7PQIl12UvnSqn5J+akOuAWNaw7EAHX7+4vz96QxGWEkSbmlQilQFe+3eRrT/VAD1SoKXetj671mAqEkK5d/a/TmAFdV7DptSeeuOS7REB3PHXNscah9Yg50vGWykjZnxlbKNMKHXo9ky4mSR89L6Xnd6X3GB0IahBzA/pPnEYWgH/USyUJIsZyVf8yUbGpFXU9mvStr20CmiAVPT+xzhRQOphB7WOh42qm2rHPQ4v2pb4PbIyuJ8j2QA6TocgifMbspA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648298486; bh=scV7QK7Ig7S8uKMqH4K+xx7Rw1rOh1FkL44jSnyePxH=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=M4uK480NE3zjm5tvrY5g4XwKRtCQLi8vKrIbS/l+8sEXiCMCytrof9AzKLleBs6vBD9ev9VfUAAtOCvvxPVIJYxrxRvuJ4MN4Ia2x/IbWL7pSKsqaWwiaDGx6klxNchbOVdKXMCPo4bp0k3hB8kq+DKgQs7DvEkNMQV0IDsoMkSXHzpEO4y/wln/FBQc1CT6TdREwdNchhErcjDCidtUuswHaG3RErPDLIW1rB5Ps81hPc2O/PhkJRfBjqje/q3hWmG0odXyMJdrCUuYtHTlKipNLW5ZJvtIKFFgzm8pcYWIB8esua7Muvn4MfGBkP+2joipncdKNwQuIYlbKX/xtw== X-YMail-OSG: G5K9w4QVM1mAEiuPPFpmR84dFUthzr3lMNndSTuALdpxJnxcqsDfK30wwCJNXwS uJwXor7ui0OYkAOVUEcEffHbub9ORGLUbBYpyUQhOLVZYhLcWVWexNPuh9JC6ESMyrUKIPjgBS__ JZKz10f5JDPJQklMqB2oK1Y0PKk.Yk0JhjZY73nKqm8Mcn.D_jF9x7Fljv_.HqTABl86dhEJAUWn TiymIVnPlsRiYmu9o.OF.pTDpKLsiZ2CIh59JKdt5NSfXdZbSzZYWFw02c2Ifb7PD9p05S9BXOKh LCd_JCpvfNERLIj_RSwlT2yrKuGTQLUDDT0u5Lgx0CoyyX1pINcQYLlC8_Ie_yXbp1ole7icZI9k mH7s8TToK7zpmBn_bYZ5jfVbk6gsPF7gcRFJyl4bxowNOgDvVez5BlLQ.IhBt7Ycf4irGonYhVwa cx1OwTb_iG1w063djVS_Obx4kbLsWmw6q57Sgqg.uq3MS0BhgdmnRtWCnLgQUxIoJbYponoo551B tifrEDiY31CHptncv78TZ0j98NdV6ggfprXOnei5C1OsNuPJo_j.I8xhBOJ.u3emhI7C.LIzk3Xu rKVHYivBp1L_KZ8CR7jQUMa4zx4JbDXvDKXH4Bwc7kz_3_rvoRv2qph5godiS.FpGrkxi.Dsr0o9 wds6gRwgSitpU9ij4_WISCLEAeDnYUgJps3dME.Yi8Kb_9aJ0B5QZbqQtTJI7iwLvTaNhB.PoTY4 Uorp.2YNUlOq5FuLcIL9dQNLO_iiLnVge6rMk_r0.DpWUp5bun9FvnOIJwpJysHUppaa3SzHK0G5 utWZZ1Fvf3nOmVJTZATukHCQBW9EVGNrh_xTq_VSsEIyiDprCHoJJNJws2IluONwdztvWgIcZ01a k_i2n9hc2KkZks9Qj6utsEeGw2uh_WJUMkvsl1Lf9ywreMX5DlZzHT.IUBmSOqaKm6qtzB.Irx7e QvPO1zzkZG90bMiu70XotVEM.yaW5pSMfCuQGEjkQJYkjyJW7MlQfG5dhj.aVZ5zQUHXuBtI8wpW c67Qvstlwdl3BS5vdmqpSngRztYTUhye9HF87VXhtQxxN42KewvTwrXh3.JGl0wYwkkXUcxe4Y5Z K35MAFTJoEA2TC2sF8pQbQ0ParvDzpGrszGE8k12aLWEpljXvOF8oAEdnpS3hY8CF.6TQ8PD_SNz H1Q0xBC.jHfiZSfkcpC5hoaY0F7emJcCRPKhXnsvUaXRXrz0wiLdhVs_9aQkQgRcdvatAmYngDOp 6ZIkdFpGBa3e6XUZmmU.cvF4W06NBT5HHxt50vrVbS6rZ_t9gog6O6D1Qw5WreNluV6dwLno.OhQ Czp_gdqgrv1ekkMyZo9RbVmRO2Kk2dzczZrUpmW95ikWKIGc58PMb9HYQqWqeJCMrdM9biu1sciL 7D4Yt9qMWU7UenNwZDuyYLGEttkGIdAgwqcrwj3bL3_VcvajYkpWPjWVTDMSnteUSD18fb8xSpVZ tvYR4zVxRAetqkeEgY3j3qyIgl4jWBWEh1.WTBmeyRV.PIFiYezwEHyAb0jYWwkJYqMr3PdbhCv3 Mm3x.LQ90DpZliSMQ4L4551XJe4aNfxX22.batzGDzSvta5S48A9tMlamZScmTtirrQ03MAYxPhk qh42gio3_nF.XeW.HzKMjSH0z.mbnArpDpG3cv3S0huupwXIrPIH4sJGwZks2PM163b5zMytwTud 9m2Ysnyz6pHIT2JJjboK0bVymM5r7hndqvelWYrhybBbBvy_SIpHpxGqWVND13Zq18mTX_QZaKyF MbfahVFqCiYBj86RmFsqEfaaOk4OtExieaChVfB_aJv4QqOV2NxCJF8Fbu0fdCLqgVYr_Ro3SQYD R_Ru10kOxHqwrpSPGy8qpufqbZ6QL5lWfrAlCJScs52jNnXU9SL_MjVUShi1SHOGc2pTqlpSg6P6 Di275R3IsyPRh3mqNnDL5wS24XXSDBoLYu9TNGQ3dhVyldOxFbcO657tPn1KyO1SCTA35OY1Ip55 De7SXp_XqBFxV4SN32Qe_HgQFF2ahWKNRF7sU8WTxcMb03ONpcmrNCIKkNj29xp.F7spdZ1vt1kG tV6VBeTodRP0cYA.D1kEU9G62YIDHfOntDDN5Fj5C5qvzdMr5lR33k.aZKdzputXDAKV7b9Gqsrb R21fNqdeRnsb3rh1EtmePXdItgf6BvPnNxlWR27BhgUTSqlCtQM8vZQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Sat, 26 Mar 2022 12:41:26 +0000 Date: Sat, 26 Mar 2022 12:41:17 +0000 (UTC) From: Filippo Moretti To: FreeBSD Current Message-ID: <1471310235.534625.1648298477653@mail.yahoo.com> Subject: Problem compiling llvm14 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_534624_320306109.1648298477651" References: <1471310235.534625.1648298477653.ref@mail.yahoo.com> X-Mailer: WebService/1.1.19987 YMailNorrin X-Rspamd-Queue-Id: 4KQdqx1FVsz4s4F X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=QP57Tq6l; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.188.204 as permitted sender) smtp.mailfrom=filippomore@yahoo.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.188.204:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[0.996]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[66.163.188.204:from]; NEURAL_HAM_SHORT(-1.00)[-0.995]; MLMMJ_DEST(0.00)[current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_534624_320306109.1648298477651 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =C2=A0File "", line 219, in _call_with_frames_= removed=C2=A0 File "/usr/local/lib/python3.8/site-packages/sphinx/cmd/build= .py", line 25, in =C2=A0 =C2=A0 from sphinx.application import Sphi= nx=C2=A0 File "/usr/local/lib/python3.8/site-packages/sphinx/application.py= ", line 43, in =C2=A0 =C2=A0 from sphinx.registry import SphinxComp= onentRegistry=C2=A0 File "/usr/local/lib/python3.8/site-packages/sphinx/reg= istry.py", line 24, in =C2=A0 =C2=A0 from pkg_resources import iter= _entry_points=C2=A0 File "/usr/local/lib/python3.8/site-packages/pkg_resour= ces/__init__.py", line 3243, in =C2=A0 =C2=A0 def _initialize_maste= r_working_set():=C2=A0 File "/usr/local/lib/python3.8/site-packages/pkg_res= ources/__init__.py", line 3226, in _call_aside=C2=A0 =C2=A0 f(*args, **kwar= gs)=C2=A0 File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init= __.py", line 3255, in _initialize_master_working_set=C2=A0 =C2=A0 working_s= et =3D WorkingSet._build_master()=C2=A0 File "/usr/local/lib/python3.8/site= -packages/pkg_resources/__init__.py", line 570, in _build_master=C2=A0 =C2= =A0 return cls._build_from_requirements(__requires__)=C2=A0 File "/usr/loca= l/lib/python3.8/site-packages/pkg_resources/__init__.py", line 583, in _bui= ld_from_requirements=C2=A0 =C2=A0 dists =3D ws.resolve(reqs, Environment())= =C2=A0 File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.= py", line 772, in resolve=C2=A0 =C2=A0 raise DistributionNotFound(req, requ= irers)pkg_resources.DistributionNotFound: The 'idna<3,>=3D2.5' distribution= was not found and is required by requestsninja: build stopped: subcommand = failed.*** Error code 1 Stop.make[1]: stopped in /usr/ports/devel/llvm14*** Error code 1 Stop.make: stopped in /usr/ports/devel/llvm14 This is the error I have while compiling llvm14 onFreeBSD sting 14.0-CURREN= T FreeBSD 14.0-CURRENT #70 heads/main-n253908-f9413897cb8: Wed Mar 23 17:24= :20 CET 2022=C2=A0 =C2=A0 =C2=A0filippo@sting:/usr/obj/usr/src/amd64.amd64/= sys/STING amd64 ------=_Part_534624_320306109.1648298477651 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
 File "<frozen importlib._= bootstrap>", line 219, in _call_with_frames_removed
  Fil= e "/usr/local/lib/python3.8/site-packages/sphinx/cmd/build.py", line 25, in= <module>
    from sphinx.application import Sphi= nx
  File "/usr/local/lib/python3.8/site-packages/sphinx/app= lication.py", line 43, in <module>
    from sphin= x.registry import SphinxComponentRegistry
  File "/usr/local= /lib/python3.8/site-packages/sphinx/registry.py", line 24, in <module>= ;
    from pkg_resources import iter_entry_points
=
  File "/usr/local/lib/python3.8/site-packages/pkg_resources/__in= it__.py", line 3243, in <module>
    def _initial= ize_master_working_set():
  File "/usr/local/lib/python3.8/s= ite-packages/pkg_resources/__init__.py", line 3226, in _call_aside
    f(*args, **kwargs)
  File "/usr/local/lib/py= thon3.8/site-packages/pkg_resources/__init__.py", line 3255, in _initialize= _master_working_set
    working_set =3D WorkingSet._bui= ld_master()
  File "/usr/local/lib/python3.8/site-packages/p= kg_resources/__init__.py", line 570, in _build_master
  &nbs= p; return cls._build_from_requirements(__requires__)
  File = "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 58= 3, in _build_from_requirements
    dists =3D ws.resolve= (reqs, Environment())
  File "/usr/local/lib/python3.8/site-= packages/pkg_resources/__init__.py", line 772, in resolve
  =   raise DistributionNotFound(req, requirers)
pkg_resources.D= istributionNotFound: The 'idna<3,>=3D2.5' distribution was not found = and is required by requests
ninja: build stopped: subcommand fail= ed.
*** Error code 1

Stop.
mak= e[1]: stopped in /usr/ports/devel/llvm14
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/llvm14<= /div>

This is the error I have while compiling llvm14 o= n
FreeBSD sting 14.0-= CURRENT FreeBSD 14.0-CURRENT #70 heads/main-n253908-f9413897cb8: Wed Mar 23= 17:24:20 CET 2022     filippo@sting:/usr/obj/usr/src/amd64.= amd64/sys/STING amd64


------=_Part_534624_320306109.1648298477651-- From nobody Sat Mar 26 22:29:57 2022 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 473E11A33D14 for ; Sat, 26 Mar 2022 22:30:11 +0000 (UTC) (envelope-from meka@tilda.center) Received: from c3po.tilda.center (c3po.tilda.center [108.61.164.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQtv60gy1z3wRg for ; Sat, 26 Mar 2022 22:30:10 +0000 (UTC) (envelope-from meka@tilda.center) Received: from tilda.center (109-93-255-137.static.isp.telekom.rs [109.93.255.137]) by c3po.tilda.center (Postfix) with ESMTPSA id 55B6018BC5 for ; Sat, 26 Mar 2022 23:29:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tilda.center; s=c3po; t=1648333797; 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=qDaV2gI7G1pZ3tfD+d4Um+x3YYx6hb9Le+iUaHuffLE=; b=dthlsY+uQSAtaSj2J+XhZxqlu82MeOf4fJYaYD2N3NT+HSJN4t7dAxb/OxDKTt1aXvJ4yG /Ju9W45wJIKWfWCESU/zzLjr6BehAnDkpR02rZ9DB0iVh5d31nwqSeCftoCtLkjGU/E2Ng V2bh65GA8SIpRwPcXNr5UC04oLzyRJ8= Date: Sat, 26 Mar 2022 23:29:57 +0100 From: Goran =?utf-8?B?TWVracSH?= To: freebsd-current@freebsd.org Subject: DHCPDv6 in non-vnet jail Message-ID: <20220326222957.wuc7xwyiq3bjtlnv@tilda.center> 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="wgy26blm5sjgd5le" Content-Disposition: inline X-Rspamd-Queue-Id: 4KQtv60gy1z3wRg X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tilda.center header.s=c3po header.b=dthlsY+u; dmarc=pass (policy=reject) header.from=tilda.center; spf=pass (mx1.freebsd.org: domain of meka@tilda.center designates 108.61.164.129 as permitted sender) smtp.mailfrom=meka@tilda.center X-Spamd-Result: default: False [-5.35 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[tilda.center:s=c3po]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[tilda.center:+]; DMARC_POLICY_ALLOW(-0.50)[tilda.center,reject]; NEURAL_HAM_SHORT(-0.97)[-0.966]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.71)[subject]; ASN(0.00)[asn:20473, ipnet:108.61.164.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --wgy26blm5sjgd5le Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hello, I'm trying to run isc-dhcpd6 service inside a non-vnet jail without success. I already have isc-dhcpd in the same jail working, so I hoped v6 is similar enough for it not to require anything special, and I'm obviously wrong, as running the same config on the host itself works. I am using bridge interface in the non-vnet jail to set IPv4 and IPv6 address and as an interface for isc-dhcpd. I know I can't just assume that if something works on IPv4 will work on IPv6 too, but could you help me understand what is missing? Is it even possible to have isc-dhcpd6 in a non-vnet jail? If not, why, if yes, what am I doing wrong? Forgive me for not sending the full config as it would make this mail huge. I'm thinking if there's something obviously wrong in my asumption that isc-dhcpd6 can work in non-vnet jail, config wouldn't be much of the help, but if that's not the case I'll be happy to send any jail and related configuration. Regards, meka --wgy26blm5sjgd5le Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE1WIFkXy2ZeMKjjKEWj1TknovrLYFAmI/k+IACgkQWj1Tknov rLZ00Q/+Iv6fXO937V+JHl87U/dHEYyZ4sAuALsa+9xsKgYwYYX7aFCQ1ZeKxbGI KLlCqc3i06/NDsQglP6TqD+ZF7klkxp+GmRW6WpKsRjZp29f1Ah0e1hGrnNUJXtt 0Up4D2Xc6uZMmuTN+u+he88jmK+4Nhf0GzrKKTb/XU153wvSzdXujbWJRx74vmbx xBEhv0XMxXlxeTEb2THpP9TPdRIU1U1gly+bDapTcFmR0C7M9ZQWNqSj1TzjLSLY gfoi286UoQ4TFlEK8xO/HU8mkzoTG1dfxF+g6wYqUhBZ8Nw1JVb2LTb4fCrNdz4+ 9sgJZy/P8ypAe//8zMViAvXCPza23j6YTOMe9CAmwN4NpARIgy0Nf66GNGhN8o0P xyMoxbIr2dro8uzKZJqx3WiYF91IdvZ15seNgl4Ed6DO8nAAm7ATpQ8VymctSRZJ qjfv1EmvOqAQeLowataYg14BjOHvdvIfm1G9KNNPWie0+nXqI0YT0+xCLL6MFjyY aU1ffCMWyc8mmwXJGqhXHz1PQm00Menk7VcGlGzd7ab2n9cR7LltawUUoSrntz6G H/3J5PRUTU3RSZOI2hhH0MzjLFr74GxRH1gnj1kb5aGqHfmDr+I9Vq+ZjGJpkuwx rv8seFcA3V7zSVLkPVg9cMiUbtrjYdtn7vSoPvj8STDteqGzUIQ= =SAZG -----END PGP SIGNATURE----- --wgy26blm5sjgd5le-- From nobody Sat Mar 26 22:53:49 2022 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 322C91A3A490 for ; Sat, 26 Mar 2022 22:54:02 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQvQd1M8Cz4Vtt for ; Sat, 26 Mar 2022 22:54:01 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-2e5e176e1b6so115305347b3.13 for ; Sat, 26 Mar 2022 15:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=CW0VxSrkb9xUzatxSZ5Fy9ArSqkNYnfbMrUD+Cc/Yuw=; b=cs0J86qBYI2nGMHOjj6gngEQRgRgUnXXfWMkOt7ukk2gCG8Gx38og6TUtBXAALr1x9 jdCOlQSphxJvV6YdNhcLrT5pfLyEKKcHjtX20d5OrfK2PAZbb9kApSUvyrNDYOg6UKnN smJznnrqHJb3Gya1eFuKhw3w73exgTeekeTJolSqfDtulyjMStbb9hyKivxOkzsH7SAq C+mVCojYIU7fMQMex9fjqln8rPpeox0V8l5cylzJxlz9ZSLYOizPH3/h0nk03F1FA2ar 3iotVpY9D++hzJuBlByVGtqJOtwNeRpAjFtGmIRGkZ2MreUEwEer+LGjn+uNPEpl+a20 ul7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CW0VxSrkb9xUzatxSZ5Fy9ArSqkNYnfbMrUD+Cc/Yuw=; b=uV8dbEtmvbTBUGYZxny973DDWkHIyrbjob8ixCNMk/Pir+Jx4Ci0O4ZsBXBp+QQ+Y0 7VokqbmHSRyo9YfDKrH2BpCWcVArXMXmGYtsC8IyjNDK612CSyReYY1kEWJ/VIIYBNja hFeF9eOABfYKELjoYeg99Z/p14BJQMGtonVYwT9EMf+cuEFPSPRQExnBJWj4XG5ctzoe pdDadO68OyU76OlsRGDxAeppoYUhIqFwF3mpCKaAos/kC1qfNhw//pnzkohGSOLb06/P ZiGJ+uFLdPtSWdFXgSJPX6+3Pg4/DRM7I1r8lAbTBYWJmslZ8zzWzosaBrG8BQisGhyH hPgQ== X-Gm-Message-State: AOAM533ENXQ+mBh8yOj+2/PE+gPpoY9zJvI8NAmUhcrmQKdDQMEcqwBR tYgphqXJ5LV0nKiJmtLkXBkTyH/q1V1BDH1aUb1xHgaey94= X-Google-Smtp-Source: ABdhPJxZepRHPagU0A+WxG4n2Vyxn90X7t8cVYdXTIeD/dcSMJVQYMK/iWw4/p2EUpWpikc+U4g4EMg+wDDbhs5jANM= X-Received: by 2002:a81:79d5:0:b0:2e5:9d33:82ab with SMTP id u204-20020a8179d5000000b002e59d3382abmr18128291ywc.460.1648335239643; Sat, 26 Mar 2022 15:53:59 -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: Ryan Stone Date: Sat, 26 Mar 2022 18:53:49 -0400 Message-ID: Subject: /usr/share/locale/nn_NO.ISO8859-15/LC_MESSAGES is a symbolic link to itself on head To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KQvQd1M8Cz4Vtt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=cs0J86qB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) smtp.mailfrom=rysto32@gmail.com X-Spamd-Result: default: False [-3.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-0.999]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1134:from]; NEURAL_HAM_SHORT(-0.97)[-0.967]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N I happened to trip over this after doing a source upgrade on a machine running -HEAD. A fresh VM build from -HEAD that was done this morning shows the same issue. root@test:~ # uname -a FreeBSD test 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n253973-8f1543785f77: Sat Mar 26 02:40:01 EDT 2022 build@rstone-build:/usr/obj/srcpool/src/build/freebsd-build/amd64.amd64/sys/GENERIC amd64 root@test:~ # realpath /usr/share/locale/nn_NO.ISO8859-15/LC_MESSAGES realpath: /usr/share/locale/nn_NO.ISO8859-15/LC_MESSAGES: Too many levels of symbolic links root@test:~ # readlink /usr/share/locale/nn_NO.ISO8859-15/LC_MESSAGES ../nn_NO.ISO8859-15/LC_MESSAGES root@test:~ # ls -l /usr/share/locale/nn_NO.ISO8859-15 total 28 -r--r--r-- 1 root wheel 16464 Mar 26 02:40 LC_COLLATE lrwxr-xr-x 1 root wheel 28 Mar 26 02:40 LC_CTYPE -> ../en_US.ISO8859-15/LC_CTYPE lrwxr-xr-x 1 root wheel 31 Mar 26 02:40 LC_MESSAGES -> ../nn_NO.ISO8859-15/LC_MESSAGES -r--r--r-- 1 root wheel 33 Mar 26 02:40 LC_MONETARY lrwxr-xr-x 1 root wheel 29 Mar 26 02:40 LC_NUMERIC -> ../uk_UA.ISO8859-5/LC_NUMERIC -r--r--r-- 1 root wheel 392 Mar 26 02:40 LC_TIME From nobody Sun Mar 27 14:34:11 2022 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 AFCE91A44788 for ; Sun, 27 Mar 2022 14:34:22 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRJHd5W3Jz4k89 for ; Sun, 27 Mar 2022 14:34:21 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 018418D4A156; Sun, 27 Mar 2022 14:34:13 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 8AC20E707D9; Sun, 27 Mar 2022 14:34:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id o9pIyJpG6tBb; Sun, 27 Mar 2022 14:34:12 +0000 (UTC) Received: from [192.168.2.110] (unknown [IPv6:fde9:577b:c1a9:31:4530:d155:b132:a6e4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 17714E707AC; Sun, 27 Mar 2022 14:34:11 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Goran =?utf-8?q?Meki=C4=87?=" Cc: freebsd-current@freebsd.org Subject: Re: DHCPDv6 in non-vnet jail Date: Sun, 27 Mar 2022 14:34:11 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <4772ECB8-6482-4B94-A887-F04EC6272911@lists.zabbadoz.net> In-Reply-To: <20220326222957.wuc7xwyiq3bjtlnv@tilda.center> References: <20220326222957.wuc7xwyiq3bjtlnv@tilda.center> 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"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KRJHd5W3Jz4k89 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-3.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; NEURAL_HAM_LONG(-0.84)[-0.837]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zabbadoz.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 26 Mar 2022, at 22:29, Goran Mekić wrote: > Hello, > > I'm trying to run isc-dhcpd6 service inside a non-vnet jail without > success. I already have isc-dhcpd in the same jail working, so I hoped > v6 is similar enough for it not to require anything special, and I'm > obviously wrong, as running the same config on the host itself works. > I > am using bridge interface in the non-vnet jail to set IPv4 and IPv6 > address and as an interface for isc-dhcpd. I assume you have /dev/bpf available inside that jail by a devfs rule so effectively you have all network interfaces and traffic available? > > I know I can't just assume that if something works on IPv4 will work > on > IPv6 too, but could you help me understand what is missing? Is it even > possible to have isc-dhcpd6 in a non-vnet jail? If not, why, if yes, > what am I doing wrong? > > Forgive me for not sending the full config as it would make this mail > huge. I'm thinking if there's something obviously wrong in my > asumption > that isc-dhcpd6 can work in non-vnet jail, config wouldn't be much of > the help, but if that's not the case I'll be happy to send any jail > and > related configuration. You could send the error isc-dhcpd6 gives you? /bz From nobody Sun Mar 27 17:08:52 2022 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 72DA41A44299 for ; Sun, 27 Mar 2022 17:09:03 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRMk6151Hz3lZd for ; Sun, 27 Mar 2022 17:09:02 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1648400934; 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=WsVt8lr7i9rMbRXr8tfO7OWruGoOT//4O1JVWu7ui2g=; b=U6Y5cMI67fKN1LIp/t6OxvFcgAIjB7xZNJ5Kj4lYN2IDst05kC8A5mNeuZxtTsTugVP/aT RMbswvwKaEp1ah0aloos8uc5KbR8kcidESPCy+7X4HxOxEkWjcFSRND1fYw4ttLl5NbiNj NcUXPLppwHZhPWCz6+MNBm+8SDyhaTM= Received: from [192.168.1.160] (cpe-24-24-163-126.socal.res.rr.com [24.24.163.126]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id dd28c00c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 27 Mar 2022 17:08:53 +0000 (UTC) Message-ID: <25bc8195-9ed4-1ff1-02f9-078a605b5307@nomadlogic.org> Date: Sun, 27 Mar 2022 10:08:52 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: loading amfgpu results in immefiate power off on 12.3-STABLE r371721 Content-Language: en-US To: Chris , freebsd-current References: From: Pete Wright In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KRMk6151Hz3lZd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=U6Y5cMI6; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-2.05 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.94)[0.940]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/25/22 21:42, Chris wrote: > This probably isn't the correct list. But it's the closest of > all the lists I'm subscribed to. Please forgive me. > OK so here's what happened. I couldn't get the trackpad on a > Dell laptop I just got to work in FreeBSD-13. So after a couple > of days, I gave up and tried 12.3-STABLE r371721 today. Once I got > the network (wifi) going. I pkg installed drm-kmod && it's depends. > Added kld_list="amdgpu" to rc.conf && rebooted. The moment it > loaded, the screen went black and it powered off. Booted to > single-user, fsck && cp /var/log/messages to ~/ . > I'm attaching a copy in case it sheds any light on the cause. > The most interesting thing about all this, is that amdgpu > worked flawlessly on 13 -- go figure. > this discussion is probably best suited for the freebsd-x11 mailing list, but i think you can try a couple things: - give NomadBSD a spin (https://nomadbsd.org/).  it's a live USB image that does a really good job at auto-detecting hardware and giving you nice desktop.  it's based on freebsd-13.0.  you can also install it on your disk if everything looks good.  i frequently use it to test hardware support on new systems i encounter. - it's hard to tell without any hardware info provided, but its possible you have an older AMD gpu, as such you might want to try using radeonkms in rc.conf rather than amdgpu. if neither of those things help i'd definitely suggest subscribing to the freebsd-x11@ mailing list to get the appropriate eyes on things: https://lists.freebsd.org/subscription/freebsd-x11 -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Sun Mar 27 18:33:34 2022 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 4C7851A3AA35 for ; Sun, 27 Mar 2022 18:33:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRPc002WLz4Vg2 for ; Sun, 27 Mar 2022 18:33:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2e.google.com with SMTP id m84so6849001vke.1 for ; Sun, 27 Mar 2022 11:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L+pPZXPJPy72T1tOx36YXAppFDFcRrLxgfUu9z3UJxQ=; b=E8QPnRdG+N10r8r97KPbSaYRFflpn6vNaSA7rYeOxr4L8iRCmGyka9x7gaR2LRxxLs tYz8I2FKNOFJmNKAF7gLAqIWas3ljtiuooMwWO8uNjNoQeF0Zl4Gck1pKbqHDLi3klWd 2+9f6MHMNe1HoJP7yt5hzgAG+sizZp/lyVpscG9yBVnccPVXQTCDcN2k8giPfB/2Mm2A CXkjJDjNoqkxbL13hyfzBM1l696cecDxrVj59X1tvfusboXHJc72imeaTeSBAunge97a PBwZIKSGb5yKEyP4ARn/23RhwlhaUKE+4mobB9xAypqRjI0AMs6EVGQaotPSh2497QPo SpcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L+pPZXPJPy72T1tOx36YXAppFDFcRrLxgfUu9z3UJxQ=; b=20OpWntJ5DpOcnCod/Ut2Fx+ULA5/MxLruUjvhOyTkeD71AD1OpINhSrt+V5sscvX/ 8D/Ue1LtAYVTsFBdPqtw+lA8ZgjitFw8oQ0DIjR1PPf3ZTeXw1BUeLW6NWvgT/Ufmg1k dlglRKWMFT1y1nA99Ahe9+P0bs8msxp4X9Q4g59fyDYpiproVFD3EOGD15I2ork2Bgju 3jWlVxpj5XwHDmjd9n1uNqDpTAPaW0lGj3baHWiGsKCT2ILiacpaMOaSOtlpmzk+gbvB h2s6cIgGbueOZ2+mNHIETD8v/9Mh6WCtoyGzqO2NNYusnZQoZELrZRcOvgvoZ3b5AKpM uaOg== X-Gm-Message-State: AOAM533DPpMn6XMj/cQfsz6guTu4vBIvfALOArt2ebxvZUbSilMOimnD 1SIPVtIMYcYsu39oxR6F4c6lG3M2R1V81YupnZI4TA== X-Google-Smtp-Source: ABdhPJyIEQfS8kehkcl2F7rzM5spnSS1e/SPOCosA4Y/8XOMSrNVRNZfgCe18C3VNawVDrOU6YbTI5Eng7zLAJywSFw= X-Received: by 2002:a05:6122:508:b0:342:e9cd:3177 with SMTP id x8-20020a056122050800b00342e9cd3177mr2875375vko.40.1648406024679; Sun, 27 Mar 2022 11:33:44 -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: <25bc8195-9ed4-1ff1-02f9-078a605b5307@nomadlogic.org> In-Reply-To: <25bc8195-9ed4-1ff1-02f9-078a605b5307@nomadlogic.org> From: Warner Losh Date: Sun, 27 Mar 2022 12:33:34 -0600 Message-ID: Subject: Re: loading amfgpu results in immefiate power off on 12.3-STABLE r371721 To: Pete Wright Cc: Chris , freebsd-current Content-Type: multipart/alternative; boundary="0000000000008c087105db376f1c" X-Rspamd-Queue-Id: 4KRPc002WLz4Vg2 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=E8QPnRdG; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [0.07 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_SPAM_MEDIUM(0.03)[0.031]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_SPAM_LONG(0.99)[0.994]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2e:from]; NEURAL_HAM_SHORT(-0.95)[-0.950]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --0000000000008c087105db376f1c Content-Type: text/plain; charset="UTF-8" On Sun, Mar 27, 2022 at 11:09 AM Pete Wright wrote: > > > On 3/25/22 21:42, Chris wrote: > > This probably isn't the correct list. But it's the closest of > > all the lists I'm subscribed to. Please forgive me. > > OK so here's what happened. I couldn't get the trackpad on a > > Dell laptop I just got to work in FreeBSD-13. So after a couple > > of days, I gave up and tried 12.3-STABLE r371721 today. Once I got > > the network (wifi) going. I pkg installed drm-kmod && it's depends. > > Added kld_list="amdgpu" to rc.conf && rebooted. The moment it > > loaded, the screen went black and it powered off. Booted to > > single-user, fsck && cp /var/log/messages to ~/ . > > I'm attaching a copy in case it sheds any light on the cause. > > The most interesting thing about all this, is that amdgpu > > worked flawlessly on 13 -- go figure. > > > > this discussion is probably best suited for the freebsd-x11 mailing > list, but i think you can try a couple things: > > - give NomadBSD a spin (https://nomadbsd.org/). it's a live USB image > that does a really good job at auto-detecting hardware and giving you > nice desktop. it's based on freebsd-13.0. you can also install it on > your disk if everything looks good. i frequently use it to test > hardware support on new systems i encounter. > > - it's hard to tell without any hardware info provided, but its possible > you have an older AMD gpu, as such you might want to try using radeonkms > in rc.conf rather than amdgpu. > > if neither of those things help i'd definitely suggest subscribing to > the freebsd-x11@ mailing list to get the appropriate eyes on things: > https://lists.freebsd.org/subscription/freebsd-x11 > I'd like to share with people that I'm working on a statement of what works and what the graphics team will spend a lot of effort on vs continue to have build support in the tree. The short version is that the latest stable branch, the latest current and the last most-recent release will be the ones best supported. Anything older than that (prior stable branches, even those supported by the rest of the project) may work great, but may also be broken or perform less well or support fewer newer graphics cards. In addition, cards older than about a decade may stop working on an upgrade because upstream's attention to these isn't so great or the driver is a binary driver that the upstream vendor has not upgraded to support its older cards with newer interfaces, etc. Short of doubling or tripling the graphics team size (volunteers welcome), it's too hard to commit to more than this limited subset of support. Even with a larger active developer group, expanding beyond this envelope would be hard given the size of the testing matrix... Also, I don't think we've ever supported unloading the drm drivers, so it's not too surprising that didn't work. Also, I know the older hardware thing is hard to swallow. I get that people want that stuff to work forever because it performs adequately. However, we are heavily dependent on leveraging the work of others to support what we can, so when the work we depend on starts to bitrot, our support for that hardware suffers as well... Warner > -pete > > -- > Pete Wright > pete@nomadlogic.org > @nomadlogicLA > > > --0000000000008c087105db376f1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 27, 2022 at 11:09 AM Pete= Wright <pete@nomadlogic.org&= gt; wrote:


On 3/25/22 21:42, Chris wrote:
> This probably isn't the correct list. But it's the closest of<= br> > all the lists I'm subscribed to. Please forgive me.
> OK so here's what happened. I couldn't get the trackpad on a > Dell laptop I just got to work in FreeBSD-13. So after a couple
> of days, I gave up and tried 12.3-STABLE r371721 today. Once I got
> the network (wifi) going. I pkg installed drm-kmod && it's= depends.
> Added kld_list=3D"amdgpu" to rc.conf && rebooted. Th= e moment it
> loaded, the screen went black and it powered off. Booted to
> single-user, fsck && cp /var/log/messages to ~/ .
> I'm attaching a copy in case it sheds any light on the cause.
> The most interesting thing about all this, is that amdgpu
> worked flawlessly on 13 -- go figure.
>

this discussion is probably best suited for the freebsd-x11 mailing
list, but i think you can try a couple things:

- give NomadBSD a spin (https://nomadbsd.org/).=C2=A0 it's a live USB i= mage
that does a really good job at auto-detecting hardware and giving you
nice desktop.=C2=A0 it's based on freebsd-13.0.=C2=A0 you can also inst= all it on
your disk if everything looks good.=C2=A0 i frequently use it to test
hardware support on new systems i encounter.

- it's hard to tell without any hardware info provided, but its possibl= e
you have an older AMD gpu, as such you might want to try using radeonkms in rc.conf rather than amdgpu.

if neither of those things help i'd definitely suggest subscribing to <= br> the freebsd-x11@ mailing list to get the appropriate eyes on things:
https://lists.freebsd.org/subscription/freebsd-x11=

I'd like to share with people = that I'm working on a statement of what works
and what the gr= aphics team will spend a lot of effort on vs continue to have
bui= ld support in the tree.

The short version is that = the latest stable branch, the latest current and the
last most-re= cent release will be the ones best supported. Anything older
than= that (prior stable branches, even those supported by the rest of the
=
project) may work great, but may also be broken or perform less well o= r
support fewer newer graphics cards. In addition, cards older th= an about
a decade may stop working on an upgrade because upstream= 's attention
to these isn't so great or the driver is a b= inary driver that the upstream vendor
has not upgraded to support= its older cards with newer interfaces, etc.
Short of doubling or= tripling the graphics team size (volunteers welcome), it's too
hard to commit to more than this limited subset of support. Even with a = larger
active developer group, expanding beyond this envelope wou= ld be hard given
the size of the testing matrix...
=
Also, I don't think we've ever supported unloading t= he drm drivers, so it's not
too surprising that didn't wo= rk.

Also, I know the older hardware thing is hard = to swallow. I get that people want
that stuff to work forever bec= ause it performs adequately. However, we are heavily
dependent on= leveraging the work of others to support what we can, so when the
work we depend on starts to bitrot, our support for that hardware suffers= as well...

Warner
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> -pete

--
Pete Wright
pete@nomadlogic.or= g
@nomadlogicLA


--0000000000008c087105db376f1c-- From nobody Mon Mar 28 07:28:01 2022 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 962501A45AFF for ; Mon, 28 Mar 2022 07:28:13 +0000 (UTC) (envelope-from meka@tilda.center) Received: from c3po.tilda.center (c3po.tilda.center [108.61.164.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRknS3z0cz4YDY for ; Mon, 28 Mar 2022 07:28:12 +0000 (UTC) (envelope-from meka@tilda.center) Received: from tilda.center (109-93-255-137.static.isp.telekom.rs [109.93.255.137]) by c3po.tilda.center (Postfix) with ESMTPSA id DF3E11A914; Mon, 28 Mar 2022 09:28:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tilda.center; s=c3po; t=1648452484; 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=bhw+pV/ycJmS5ap85bVTHruQM26bcyfajS/i3xxlSro=; b=A2kMxcxpM8g/jR4LHrCJPJGM/l3aTIDjrz+rN6GVdU03hW6LW7/OsFUlNLFIoLwSWiGIq1 TOeR0MU+E4ARtnBsqf0sXEcJqFAPUiQ6BwfP6AriKCTXdd0NGjgUW+A4n/svskr6JAC7pV Mkn1Y/3ZMDwA6lsJyvJJfM4M38+quu8= Date: Mon, 28 Mar 2022 09:28:01 +0200 From: Goran =?utf-8?B?TWVracSH?= To: "Bjoern A. Zeeb" Cc: freebsd-current@freebsd.org Subject: Re: DHCPDv6 in non-vnet jail Message-ID: <20220328072801.dqp4udhsk2czdx5y@tilda.center> References: <20220326222957.wuc7xwyiq3bjtlnv@tilda.center> <4772ECB8-6482-4B94-A887-F04EC6272911@lists.zabbadoz.net> 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="vztapgptcxr77sbd" Content-Disposition: inline In-Reply-To: <4772ECB8-6482-4B94-A887-F04EC6272911@lists.zabbadoz.net> X-Rspamd-Queue-Id: 4KRknS3z0cz4YDY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tilda.center header.s=c3po header.b=A2kMxcxp; dmarc=pass (policy=reject) header.from=tilda.center; spf=pass (mx1.freebsd.org: domain of meka@tilda.center designates 108.61.164.129 as permitted sender) smtp.mailfrom=meka@tilda.center X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[tilda.center:s=c3po]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.32)[-0.321]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[tilda.center:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[tilda.center,reject]; NEURAL_HAM_SHORT(-0.90)[-0.900]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.62)[subject]; ASN(0.00)[asn:20473, ipnet:108.61.164.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --vztapgptcxr77sbd Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 27, 2022 at 02:34:11PM +0000, Bjoern A. Zeeb wrote: > I assume you have /dev/bpf available inside that jail by a devfs rule so > effectively you have all network interfaces and traffic available? You assume right, as I needed it for IPv4 DHCPD. > You could send the error isc-dhcpd6 gives you? >=20 > /bz Up until now I didn't see it (I probably missed it before) but I have this: unable to create icmp socket: Operation not permitted I changed jail settings to allow raw_sockets but I still see no log on the= =20 daemon side and same "Sending Solicit" on client side (dhcp6c -d -f). Daemo= n=20 side is non-vnet jail, client side is vnet jail. Same two jails have succes= sfull IPv4 DHCP working.=20 I have rtadvd working on host and the same vnet jail picks it up via rtsold, so I'm just guessing the client side is working. Regards, meka --vztapgptcxr77sbd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE1WIFkXy2ZeMKjjKEWj1TknovrLYFAmJBY34ACgkQWj1Tknov rLZoVQ/+PoHTgUa96oGIQULqoWcR6edgA217H7AMnEA7sN+JCvpZOuZbC4OXTlO4 K3Vx1VsJGhJ52nNKWrHQsRLs7aC9YObeMfpqqIiO5THz8cwB+eaEV6sHYuW/Ju5x CzqS/qSye7L+TujZ3p/o9f/mpnOlYdTuSto/Uy8sawzXnVlXYzFGykMEzC8WnDnQ 4FoaxsKgeevImocD60D2YKRmerD50fGUd1NCWnPy0T85GVQ02pJAaMM7ICy0pBSi iujeROl40c1F8SRPXBBLoVSzL6IMeBZLcHdnYbcGNqsP37TJ1yWwyu9wQPwIDKoE ZgZZZl3GCR9kUgC6MNXq5CXl4ujnP7f15Or94cKl3Slje4Y7P8MadAxxfEgQeQgB K8P57CNNurW/ISlGm/br/cHDvfn0adibAvUYH2TSBjk4jkp7JIjFNhPSRtOlgGnX +8rkBaIak0kHhL4x9HjVcBtktdwSbv0z3iyRPB5Nf7vHvX0GWHKpfbRYLGVJqcO4 Ax437QWQdRVRoDvlTwfudexvb9ju9jJpJWh/aYEnSDyp8uQu/c/8b6vfX0eTWALp r0x5E02FEFF+4RCBjhQld8LrRAyWO74wFnAZBdqjd8lJ+ytCuSJkPLcDYUEORlpF dbzZH0J14kw09h0eln3Zjk3JaYce0bfFCDMfo2bUDVo8Ytehu5c= =RQKF -----END PGP SIGNATURE----- --vztapgptcxr77sbd-- From nobody Mon Mar 28 08:23:59 2022 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 CA3421A33663 for ; Mon, 28 Mar 2022 08:24:11 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRm2266fWz4jgr for ; Mon, 28 Mar 2022 08:24:10 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1648455842; 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=LHgtNSgyCFBjqz0LJrgM4z4EyWgfmKpY+6HBLdrMG9A=; b=sqrm5u6+flXmQniIDdL9jkbAxlBCy+2MP0REXL8YRf8yViWUPOwHvt+hGtEWGm0QhKj0pE mfRCjicpNxoXBwmuF1gC3AQPw0FIqJOPgraddN8r9p+FD5IKEg9IhkG3ZHH/OVIUVP3nI1 rvuAzRoFD3L2t0owgFfhs8gV9dc94tw= Received: from skull.home.blih.net (lfbn-idf2-1-1209-45.w90-92.abo.wanadoo.fr [90.92.34.45]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 6ced9f1e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 28 Mar 2022 08:24:02 +0000 (UTC) Date: Mon, 28 Mar 2022 10:23:59 +0200 From: Emmanuel Vadot To: Warner Losh Cc: Pete Wright , Chris , freebsd-current Subject: Re: loading amfgpu results in immefiate power off on 12.3-STABLE r371721 Message-Id: <20220328102359.027999757a1e1723b324bcb3@bidouilliste.com> In-Reply-To: References: <25bc8195-9ed4-1ff1-02f9-078a605b5307@nomadlogic.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KRm2266fWz4jgr X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=sqrm5u6+; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-1.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_SPAM_LONG(0.96)[0.963]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, 27 Mar 2022 12:33:34 -0600 Warner Losh wrote: > On Sun, Mar 27, 2022 at 11:09 AM Pete Wright wrote: > > > > > > > On 3/25/22 21:42, Chris wrote: > > > This probably isn't the correct list. But it's the closest of > > > all the lists I'm subscribed to. Please forgive me. > > > OK so here's what happened. I couldn't get the trackpad on a > > > Dell laptop I just got to work in FreeBSD-13. So after a couple > > > of days, I gave up and tried 12.3-STABLE r371721 today. Once I got > > > the network (wifi) going. I pkg installed drm-kmod && it's depends. > > > Added kld_list="amdgpu" to rc.conf && rebooted. The moment it > > > loaded, the screen went black and it powered off. Booted to > > > single-user, fsck && cp /var/log/messages to ~/ . > > > I'm attaching a copy in case it sheds any light on the cause. > > > The most interesting thing about all this, is that amdgpu > > > worked flawlessly on 13 -- go figure. > > > > > > > this discussion is probably best suited for the freebsd-x11 mailing > > list, but i think you can try a couple things: > > > > - give NomadBSD a spin (https://nomadbsd.org/). it's a live USB image > > that does a really good job at auto-detecting hardware and giving you > > nice desktop. it's based on freebsd-13.0. you can also install it on > > your disk if everything looks good. i frequently use it to test > > hardware support on new systems i encounter. > > > > - it's hard to tell without any hardware info provided, but its possible > > you have an older AMD gpu, as such you might want to try using radeonkms > > in rc.conf rather than amdgpu. > > > > if neither of those things help i'd definitely suggest subscribing to > > the freebsd-x11@ mailing list to get the appropriate eyes on things: > > https://lists.freebsd.org/subscription/freebsd-x11 > > > > I'd like to share with people that I'm working on a statement of what works > and what the graphics team will spend a lot of effort on vs continue to have > build support in the tree. > > The short version is that the latest stable branch, the latest current and > the > last most-recent release will be the ones best supported. Anything older > than that (prior stable branches, even those supported by the rest of the > project) may work great, but may also be broken or perform less well or > support fewer newer graphics cards. In addition, cards older than about > a decade may stop working on an upgrade because upstream's attention > to these isn't so great or the driver is a binary driver that the upstream > vendor > has not upgraded to support its older cards with newer interfaces, etc. > Short of doubling or tripling the graphics team size (volunteers welcome), > it's too > hard to commit to more than this limited subset of support. Even with a > larger > active developer group, expanding beyond this envelope would be hard given > the size of the testing matrix... I do confirm the above. I'll also say that currently the graphics team is just me and wulf@ (and sometimes small contribution from others), we can't do everything. > Also, I don't think we've ever supported unloading the drm drivers, so it's > not > too surprising that didn't work. It used to work for i915kms, it never worked for amdgpu. I'm (well $WORK) is interested in unloading mostly for GPU-passthough. That will allow one user to boot FreeBSD, use the graphics, unload the module and start a Windows VM or whatever, use the graphics in it and after shutting down the VM one could use again the GPU on FreeBSD. It's a bit low on my todo list though. > Also, I know the older hardware thing is hard to swallow. I get that people > want > that stuff to work forever because it performs adequately. However, we are > heavily > dependent on leveraging the work of others to support what we can, so when > the > work we depend on starts to bitrot, our support for that hardware suffers > as well... > > Warner > > > > -pete > > > > -- > > Pete Wright > > pete@nomadlogic.org > > @nomadlogicLA > > > > > > -- Emmanuel Vadot From nobody Mon Mar 28 15:39:29 2022 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 71A4F1A36E6D; Mon, 28 Mar 2022 15:39:50 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRxhj5227z3ltg; Mon, 28 Mar 2022 15:39:49 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f178.google.com with SMTP id b9so10270699ila.8; Mon, 28 Mar 2022 08:39:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=AipIdpfDCxcEced5eOmiL8MzJCT+RIvubTImNF7cnSc=; b=sMsq+RvtcK7XbP4Q2cH4vXVa1qIqgQFq4vVDYOrj3G/X2yQDJJCtCgUF1A/muMFw0u hVGAgvqlLnhMbtDemuoKGhd4FvQvNRFyTv5qOotPFNMFeqWZnljIHX8naLoC20I8dHG4 FVNs5JWXdtPUcvtE+BxWl1A2VvhJrWS4ViTfs74TZl4vpxhhRqeEkCLkmO1DMbk7VbgO soAKozf2WlzRcM8YACLdjwUnAXwb4SeqYcag0wVTZztKfbd1EdLVQcxvxfxLGMbr2AgU ZzaA5eB2X96UsVurOV2eJYkMhBcezKMWyOCNMkqW7rwsZ39VqmSDOqwKeTv1I1z6HhQo s0Gw== X-Gm-Message-State: AOAM533FlpMql2A+wbANvbBTWkxmCQX2j4d/X3o1/iAqXtYRg45VNkyy oZ1iRa6SWJN4Wn4zFPaF7ZWD5C/+u+he+x3BIvlod6zp X-Google-Smtp-Source: ABdhPJzDdnGDfzTaplB7eJX9kAZmrpiNHwv4RbafBUNwv8rMdQGVWydxlTNgS5sdQtHEbAK5js0M2bJau5RovrZLUO4= X-Received: by 2002:a05:6e02:1c2c:b0:2c8:3753:59c with SMTP id m12-20020a056e021c2c00b002c83753059cmr6387754ilh.260.1648481981623; Mon, 28 Mar 2022 08:39:41 -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: <89c73d2114c1c7f8b5877e7174178a23@bsdforge.com> In-Reply-To: <89c73d2114c1c7f8b5877e7174178a23@bsdforge.com> From: Ed Maste Date: Mon, 28 Mar 2022 11:39:29 -0400 Message-ID: Subject: Re: Deprecating ISA sound cards To: freebsd-stable stable , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4KRxhj5227z3ltg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.178 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-0.66 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.975]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.67)[-0.671]; RCVD_TLS_ALL(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.178:from]; NEURAL_SPAM_SHORT(0.98)[0.983]; MLMMJ_DEST(0.00)[freebsd-stable,freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.178:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Sat, 19 Mar 2022 at 15:30, Eirik =C3=98verby wrote: > > I won't be arguing hard > for keeping these drivers (seeing as I'm clearly the oddball for having > FreeBSD running on hardware which has 1) ISA bus and 2) ISA sound > cards..) On Sat, 19 Mar 2022 at 17:24, Chris wrote: > > I have a board running freebsd that has 2 GUS cards in it running > simultaneously. Sniff... c=C3=A9st la vi=C3=A9 These drivers will (eventually) need to be updated for Giant locking / spl* leftovers, or be removed. I assumed that these were all museum-class hardware and nobody would use them with contemporary FreeBSD; NYC*BUG dmesgd[1] seemed to concur. That said, I don't think they have a significant maintenance burden in the near term. Any of these drivers that will actually be used with FreeBSD 14 could have their retirement postponed. If this is desired, please identify the specific driver(s), follow up here with a confirmation that they work with 12.3/13.0/CURRENT, and ideally send a dmesg to dmesgd. As far as I can tell there are no GUS cards listed in dmesgd at all. (I also had an original GF1 Ultrasound with 1MB on board although I think it sadly went to e-waste. I never used it with FreeBSD, and it seems the snd_gusc driver only supports UltraSound MAX and newer anyhow.) [1] https://dmesgd.nycbug.org/index.cgi From nobody Mon Mar 28 22:38:46 2022 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 ADDB61A38F6D for ; Mon, 28 Mar 2022 22:38:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660071.outbound.protection.outlook.com [40.107.66.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KS70G2ycLz4YBl; Mon, 28 Mar 2022 22:38:54 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GIr3Z+eJUq+LFuyT4GbL4NV85MhpI0CwMmkI/AtgGzl32PV0Oyx22czOcQhAgJXqday7pFzpijaf778zxengFW1JxgfFSGKq9K7M5t0xMe55o/7KOv5u8cpo/V9weKY22aOOcKGwNZGvjMyR0wplG+s7wZN3NLUqtjgmgLwmSjAxRQM0/lMWI4wBwydkZTaPcxngvLDlu5m9r155DuLDl2OJALw2scekAkn1NQxkvKyziRz1uOml7avPxWWidUJwKULKMmtxrZae+4oof/Zr7KcWrUi43vxrSFJQhQRcKZJPDvV4iUTMD4hiVal/1FB3yDCbim0TEF5yxYKgRwlLeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2OiwDkZXz1usnPlVfNhH24GRTY5XPeXlh99ZfUVXsd4=; b=MZLfrPB1sRgrIjJ61X/NJZyGTXxqzYdIuFtvgHegUq9R1l4VMGS2A2bZEV2LPzyUCL94w38PcLQhwwxCGJoPfP7WFe7OMe8tRs2TZWlGmxVSeVPI/B6aRI4E+AfqYpvijmAbVMetUvQ7WwpdTVch9dglDXEuDo2Q0UZgwWnqR/zoQNmd7hRoEVdwGncejuSSt0sAaYQ8TcbmuDB8cd40kaEEMozLcr3AG+N2huZrxIHpnHLpUeLJcP4mq67Pq33L7Pn/Y0+OKARKYNXxVgCd0CwA2+b+Iyay4tpeHDO6xa/jaxwovWv5th7arfssrqU8GYy5HoiIb+znTRP+EgFhyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2OiwDkZXz1usnPlVfNhH24GRTY5XPeXlh99ZfUVXsd4=; b=ZFej53W7yWgtSaLhotoWl7BUhXbs1IfP1z37MohIpaFYWdrJheSHpFbOrQEYa8EpPHJRcIh7nIezmOf0LAAqfA1MFAWe5W0V6oAObfSydkGTmj9jX5x0JwxNNq88JOa3gq5PmU3pHdGLHGoN2zUFsDCcv7EusgfXA3FMCigE3gkpuhLTQAX9snpUeyu9GWnqqWhQVUo2xMBlV7REk78rELEZt52j4TD2fkEySPGwf2Pl3CCHznihAwMY+jL1BFqkrOxmeGqDeO2HE8jaUJA2CplNSt7HcQwfg9z9zUfrN6M2T1/CdaHSf8hRwPakoRZf9rl0RKDaZf0wu+LXRSiHhA== Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:de::14) by YQXPR01MB3030.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:4d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.17; Mon, 28 Mar 2022 22:38:47 +0000 Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::39d7:e98e:fd00:2591]) by YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::39d7:e98e:fd00:2591%6]) with mapi id 15.20.5102.023; Mon, 28 Mar 2022 22:38:47 +0000 From: Rick Macklem To: John Baldwin , "freebsd-current@freebsd.org" Subject: Re: ktrace on NFSroot failing? Thread-Topic: ktrace on NFSroot failing? Thread-Index: AQHYQI/JkEo0PYUUsU+bkJKIOYzP06zVZriS Date: Mon, 28 Mar 2022 22:38:46 +0000 Message-ID: References: <70135754-84c2-b642-5641-0721e0b4690d@FreeBSD.org> In-Reply-To: <70135754-84c2-b642-5641-0721e0b4690d@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: cbbeefca-2b8d-80c4-a459-cd26d2dd0e23 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: adf9ce8f-0eba-4a6e-753e-08da110bb8dc x-ms-traffictypediagnostic: YQXPR01MB3030:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sBGM5Q7/GKzXrVUtb5jUk9udKxDB2jfwWxghYrHq6Smyqf3vvZTXEMZ2g1hzukvLVymseR/eWNYkdqLwhGd9U1YFA9bvUpO/wfr2VAm/inYcZwXuNLeGyaOI7klr/6iouqTefekbMrhgHOSHhQIFGYcL5rG/lgwxja33qavPuVQZc04hOV177I4agd3RBfBIScVyZTamkRF1204OjYWd/QZayYHofPmBE5y1EFX0HYV3uRkT3HRGXELEvrKhgdHMNJ87RxsfAZZr9VuZYg2G5dVMdu6zhK9AbaIE11gsGU0vWAGkD7adVv7NWVtQid4C6pxNgTAqoHuYtCs7NjMbQmjyP35DZEBB/J54jy+XeExjEtbi7OSW6PbVR9YH6A6MKKIFjiapXfAFg1tDif6qWpHLzpiIVl+YoQqebQmOJvalAr0DlWd+Yu7f36G2DnRpTSjM/Ao/FA6Z3GlemXHIXnEsDbn8G4Y3TWqJvwoQCZUXaX2eOgu4HtHb1zd1SeGGr78839ubNxkMReIMkQT9UxbyqHHMfcXhXvdUU0AT5pOi3DVffzv3OHLTbP1KSRSRbjE3bPdQpCoMcgLxHNjHAixD2I2SEATOdNHqxSEgVBADwnCOVEfsFO9CJ2rgbH88xpU/h3KKQ/pXZxtDS9FQ4AoJnb0ujvT2c7I20soGiwjU+QDoF1LG4J/+r2Xul6gm3u6k5cC5QxiAWszNSSQL0Q== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(366004)(3480700007)(33656002)(38100700002)(38070700005)(122000001)(86362001)(2906002)(110136005)(66476007)(508600001)(66556008)(76116006)(91956017)(450100002)(8936002)(316002)(8676002)(66946007)(64756008)(52536014)(66446008)(5660300002)(9686003)(55016003)(83380400001)(786003)(6506007)(71200400001)(7696005)(53546011)(186003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?kCTGnandh3QtOjz7hEaP0j/XRvfUPNG3Z8Qx88IALjZXq17qpD7y6W8q2j?= =?iso-8859-1?Q?zQGPohHxlvCac6Nj4GpnjjfMR85h6LegA1SOWGRQRSbSLmA3I5InnialaS?= =?iso-8859-1?Q?LWQsjZivZ4eBQ4oZfGejGZJU1IFgvS6K9Vhvg1WPJk1y17sKeSW4oWaK/L?= =?iso-8859-1?Q?kDdAeBNalE1MdVmOVVMAnzen2wvqcDQEEYbhDeYQVJqK5zitkdvuZe35FW?= =?iso-8859-1?Q?j2HQudzQzpUC9NeNh0VqV7YjqVMRNJQ1Rf6qPBkgcgOWAH5uhT23odGq80?= =?iso-8859-1?Q?f0A448X9Z77Fpk2AWW7uZjiGBYjNnpdAnV3XBoOwgFZ9DdhLA0b6Q2PzRJ?= =?iso-8859-1?Q?0aH/Lo9/V4tJ6tku0o2sSrO1dS7zo1DUxe3AaO3SvO9ayhjZEVsZ/oV4xb?= =?iso-8859-1?Q?xIMn6FXmAvS9xvAUj9A6+yvb+CJY7Ut40e4+ra44buIHJIIpzTn857XKEr?= =?iso-8859-1?Q?IO1NzEF8J8pOvrvtx/t6MhqQTHj22/2zuakDybIAPT6uOszc61nkUvAUYG?= =?iso-8859-1?Q?f2LMHVpDZcCmdl6yQpi6aSs0nFktzDHUG6k9OKbeJx5YuXoykaorAuS6iJ?= =?iso-8859-1?Q?Ob2AkgjZOtFKZetIRDM1pDui64bZdFi6Ceqs9ifhrM0m+w4zT+1qg/uQFk?= =?iso-8859-1?Q?VYHFChgDJyCxuP9UdmmpfOifMMtmg3VpOr39rxtiPwZFmPkUAEP7DVO4wZ?= =?iso-8859-1?Q?qf9IbSMwWNhRvTIXWDohr1SzobDfgrzJk0Xq0I6Vpj+QfjT/A71I9rNzFB?= =?iso-8859-1?Q?ubVtftkJ/vYyGvkGX4U8HOSCLRbvorS0DnMM7PmdJIf2+GthUJ4vkXsyFq?= =?iso-8859-1?Q?AaHbf+XCUuZtTjlB9bX+xMKWfHH3No3RyEzNdPDEVaQuuHdEadyOyOARx+?= =?iso-8859-1?Q?X2CgD7X1LaE9IPWa2JhdAJbVW6qWZO5OASsHt7DiKsK+tNAkXICLyqOE7H?= =?iso-8859-1?Q?8iugTNKUVAOeR4PUHp+6cttl98yVkWQI1jehKZKy0awXJ8w5jISsf7u0F3?= =?iso-8859-1?Q?J6ffrPKcF3Hqcc6QvD7hoP1Oq+qPuY99KRJevB7SsuonXjCYbna0K52zyJ?= =?iso-8859-1?Q?LI+ZNKuZJOzt8Za17gFO8OymqbpAlpI63YhVTi+jNEOW7la09kwsRdiBvB?= =?iso-8859-1?Q?GJ7VBF9xQsslnLW3F7egvJ3UUpHWbHOtsX7azbJcRQ4zhPMyHYxEgf/uXI?= =?iso-8859-1?Q?XjioMNfX/DM41XFdVCQ7Bn4E+cNS+F14pyd7a9AMQsXyT7vhODwW9yxxHM?= =?iso-8859-1?Q?AOBqSaUDd2bqTBrjDkgJ71aayhsFd1f8CmXN9eGiBbKHUYr7eixZ30LHvD?= =?iso-8859-1?Q?ZZndQ0tekTxyzYl/pO6erbY+qT61xMXmINwfGF1QaCZnfXtffsUsyWUZCU?= =?iso-8859-1?Q?uIg/o0lk2dAVpTi72u7w7KbY9+94jeQOEZWavSE1y9l7/7fMiy7LZXPN84?= =?iso-8859-1?Q?/y7s+5wK//+qb0dDaiOf8ARDrV8WnJASg/779HLJJKbriSdkVW3UPIfL2t?= =?iso-8859-1?Q?ML4QxrlLAAlOnnpEewvy0qwM31ri5WcWiNcUs4fksDRdw5/8StYzzAmUuw?= =?iso-8859-1?Q?8O4FoKwQxsR7vv9JHsCb5buLqm9ylLcK4Z53gc6ewdVfm3Q3JAEcGQgVXq?= =?iso-8859-1?Q?PI5m6cCRASHPhIgEyFyhKYhjwfSOAp5afJzT24TaOBOD3zFqn9L1kE6pTk?= =?iso-8859-1?Q?0hyAEVhLbdd2bA5peV8mdpRSj0tISfiWO5jgvynOm+Hi/ocFXPpL1v/rV1?= =?iso-8859-1?Q?wn+I2B4hupPcxH7Z8NZjsEXRieDwRrWC/95+Tkb5xdwSqCxK59gHkmmuR9?= =?iso-8859-1?Q?krJ6Twdz9DY5E7oWOsM/HC4Tg256fRC8IxytyYHoCDUFXMy1j31tZyjDJd?= =?iso-8859-1?Q?tn?= x-ms-exchange-antispam-messagedata-1: saGPQXnZUh02KQ== Content-Type: text/plain; charset="iso-8859-1" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: adf9ce8f-0eba-4a6e-753e-08da110bb8dc X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2022 22:38:46.9333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: g6CDjD23VBXRyo/i7arHauomI+r/2qezgqfEM8zJL8oODtR49YTfy2scZzJCzg0hIXuw+a9a0+A8OtLzt2ma2A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB3030 X-Rspamd-Queue-Id: 4KS70G2ycLz4YBl X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=ZFej53W7; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.71 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.71:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.71:from]; MLMMJ_DEST(0.00)[freebsd-current]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-ThisMailContainsUnwantedMimeParts: N John Baldwin wrote:=0A= > On 3/10/22 8:14 AM, Mateusz Guzik wrote:=0A= >> On 3/10/22, Bjoern A. Zeeb wrote:=0A= >>> Hi,=0A= >>>=0A= >>> I am having a weird issue with ktrace on an nfsroot machine:=0A= >>>=0A= >>> root:/tmp # ktrace sleep 1=0A= >>> root:/tmp # kdump=0A= >>> -559038242 Events dropped.=0A= >>> kdump: bogus length 0xdeadc0de=0A= >>>=0A= >>> Anyone seen something like this before?=0A= >>>=0A= >>=0A= >> I just did a quick check and it definitely fails on nfs mounts:=0A= >> # ktrace pwd=0A= >> /root/mjg=0A= >> # kdump=0A= >> -559038242 Events dropped.=0A= >> kdump: bogus length 0xdeadc0de=0A= >>=0A= >> I don't have time to look into it this week though.=0A= I have committed the patch (that was attached to a previous email)=0A= to main, since bz@ confirmed via email that it fixed the ktrace problem=0A= for him.=0A= =0A= >Possibly related: core dumps are no longer working for me on NFS=0A= >mounts. I get a 0 byte foo.core instead of a valid core dump.=0A= If core dumps still fail for a main with the patch, please let us know,=0A= so we can investigate further.=0A= =0A= Thanks and sorry for the breakage, rick=0A= =0A= --=0A= John Baldwin=0A= From nobody Tue Mar 29 08:11:29 2022 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 738C31A4F779 for ; Tue, 29 Mar 2022 08:11:39 +0000 (UTC) (envelope-from meka@tilda.center) Received: from c3po.tilda.center (c3po.tilda.center [108.61.164.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSMj60nl1z3GNr for ; Tue, 29 Mar 2022 08:11:37 +0000 (UTC) (envelope-from meka@tilda.center) Received: from tilda.center (109-93-255-137.static.isp.telekom.rs [109.93.255.137]) by c3po.tilda.center (Postfix) with ESMTPSA id 1E6D11C445; Tue, 29 Mar 2022 10:11:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tilda.center; s=c3po; t=1648541490; 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=am6F+9rj2CpiTcDotwPvcWdXi959WMfN8BQUwlPU2vQ=; b=CBzECyjGy8TOfeu97Kttr0AB7StFeMcby41ToSbcV8dUcrgmb8NqEzght1mZjIFBaDwet2 gDAyvtOlO6SdJcpQG2aymgkjjIuRn94Y8CMVOWmnZryEfu9lvNESVboYrxEtAjYoSqpIep 2cXBIFTiQ61KTii7wVFIPh6BY9bmgpQ= Date: Tue, 29 Mar 2022 10:11:29 +0200 From: Goran =?utf-8?B?TWVracSH?= To: "Bjoern A. Zeeb" Cc: freebsd-current@freebsd.org Subject: Re: DHCPDv6 in non-vnet jail Message-ID: <20220329081129.p5xtxlbiyw6klxcl@tilda.center> References: <20220326222957.wuc7xwyiq3bjtlnv@tilda.center> <4772ECB8-6482-4B94-A887-F04EC6272911@lists.zabbadoz.net> 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="ex7rflj7jy4kypzq" Content-Disposition: inline In-Reply-To: <4772ECB8-6482-4B94-A887-F04EC6272911@lists.zabbadoz.net> X-Rspamd-Queue-Id: 4KSMj60nl1z3GNr X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tilda.center header.s=c3po header.b=CBzECyjG; dmarc=pass (policy=reject) header.from=tilda.center; spf=pass (mx1.freebsd.org: domain of meka@tilda.center designates 108.61.164.129 as permitted sender) smtp.mailfrom=meka@tilda.center X-Spamd-Result: default: False [-5.46 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[tilda.center:s=c3po]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[tilda.center:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[tilda.center,reject]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.62)[subject]; ASN(0.00)[asn:20473, ipnet:108.61.164.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --ex7rflj7jy4kypzq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Sun, Mar 27, 2022 at 02:34:11PM +0000, Bjoern A. Zeeb wrote: > I assume you have /dev/bpf available inside that jail by a devfs rule so > effectively you have all network interfaces and traffic available? As a form of test I've put rtadvd inside the same non-vnet jail and I can see RA message arrive to the vnet jail. I though I "disconnected" something concerning IPv6, but that's obviously not the case. Let's take a step back. Is there any howto/tutorial on how to put isc-dhcpd6 in a non-vnet jail? I don't care if it's jail.conf or some jail manager. Can I somehow see where packets end up, like dtrace? Should I try some other server/client for DHCPv6? If I can make it work in any scenario, that would be good starting point for me to figure out what's wrong with my current setup. Regards, meka --ex7rflj7jy4kypzq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE1WIFkXy2ZeMKjjKEWj1TknovrLYFAmJCvy4ACgkQWj1Tknov rLbjXQ//WsTHB0UYWrSI96ojwoYSVZnqMS40Z86LgiUD8RH66K3zBBK4iYrBoA1j 4vkBI5/zdgXZMhL8z4WDxbOSJB/JeycckHb4O8RlSeprVfzNvPNPQW+fpJqVOq4C SE/UJM3vxnGjh16iwVJ2XtpK3OmZ5R/Sb0caUUmsDZnKqrnF8k+C8/44BoEUUlNo aW1Lo3EVCyxCLmXXdO+iUb7s63ZvnA7gmnYL9w/7LNYMxxmM44kLOBIg3SeU/afW Hw0CIQzAbFe1o8XGfj5riQfkK6+MaqPGThIVMJD9BpphYxFnq/QxrvGo6GqLgDdy tI5Uw1+3v/3Y3l3KoNMqPpjLQdY3YXx/rbhY503inguEJdwrcfu7Dx5QfnPQP9c/ kJesh0xOXLSvXq5OmA/V3XctpXHLT4mJRRNz/BpNAUcyUjI93ImQfZPCDAr9ek7b V48xvsPb6iQ9VOAMo/Jw0u8++qFowwZkV3exlSWpOPoDxntudJ31rjNcdn3bI4Mm K9+G/QHATS0Ruh1vYgfeJoZaMEaBIqLW5cp2g6uwNUiGhExxXPCTqG35RAugdVPX RcTKGqZNZ7kmJfU/ihvPabOAVKocgehVt7JMV7FIM876EP9lECLwFLfe6Sl8AhGe IA3gA/xi7LXa9IZAtZO2emRCumg8VPu98z1rHDfchsuB7qzP9Gs= =YjXY -----END PGP SIGNATURE----- --ex7rflj7jy4kypzq-- From nobody Tue Mar 29 10:14:20 2022 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 6659F1A4EEA3 for ; Tue, 29 Mar 2022 10:14:29 +0000 (UTC) (envelope-from SRS0=GV03=UI=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 4KSQQr1k7Xz3sxZ for ; Tue, 29 Mar 2022 10:14:28 +0000 (UTC) (envelope-from SRS0=GV03=UI=klop.ws=ronald-lists@realworks.nl) Date: Tue, 29 Mar 2022 12:14:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1648548860; 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=DYnOf72erJUK3xK2XQeuyBpDmnjvu5tBmzY6O79rxPc=; b=dlafUAt86xduuCDqBMb29Kv5ck744oUhJtK9AbghOuYNh2b6o/oyExOollzk8vGf1S71U+ qTJzF5WaB7p8OIeaU/STl0uVSxQ58ldx7wyDAr7//AvoYAkKWj6FqNowVSQh14sN/V9hkg xVF2+kqWXYUFr0TZkw+ecIy4vs+uK63td2a8th0BsTLC9d+LPobkQa/UuZRjf2WrZWl8Vi ZHmVYhNxPxX2DHlq8dj7IbvPKeVMIL5Jlb/bllQlA9viibC5YlcMsXE0hwWoZt6lhQnqoQ liFDT8EWjcC5mn4NBDR+A+PdEf0S3tI9Z8zrMCBKi4PQn7Fl004Eu9uKesbK3Q== From: Ronald Klop To: Goran Mekic Cc: freebsd-current@freebsd.org, "Bjoern A. Zeeb" Message-ID: <1527544025.66.1648548860391@mailrelay> In-Reply-To: <20220329081129.p5xtxlbiyw6klxcl@tilda.center> References: <20220326222957.wuc7xwyiq3bjtlnv@tilda.center> <4772ECB8-6482-4B94-A887-F04EC6272911@lists.zabbadoz.net> <20220329081129.p5xtxlbiyw6klxcl@tilda.center> Subject: Re: DHCPDv6 in non-vnet jail 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_65_558795370.1648548860306" X-Mailer: Realworks (602.328.5a345bb) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4KSQQr1k7Xz3sxZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=dlafUAt8; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=GV03=UI=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=GV03=UI=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.946]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RWL_MAILSPIKE_EXCELLENT(0.00)[194.109.157.24:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.93)[-0.927]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=GV03=UI=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=GV03=UI=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_65_558795370.1648548860306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: "Goran Mekic" Datum: dinsdag, 29 maart 2022 10:11 Aan: "Bjoern A. Zeeb" CC: freebsd-current@freebsd.org Onderwerp: Re: DHCPDv6 in non-vnet jail > > On Sun, Mar 27, 2022 at 02:34:11PM +0000, Bjoern A. Zeeb wrote: > > I assume you have /dev/bpf available inside that jail by a devfs rule so > > effectively you have all network interfaces and traffic available? > As a form of test I've put rtadvd inside the same non-vnet jail and I > can see RA message arrive to the vnet jail. I though I "disconnected" > something concerning IPv6, but that's obviously not the case. > > Let's take a step back. Is there any howto/tutorial on how to put > isc-dhcpd6 in a non-vnet jail? I don't care if it's jail.conf or some > jail manager. Can I somehow see where packets end up, like dtrace? > Should I try some other server/client for DHCPv6? If I can make it work > in any scenario, that would be good starting point for me to figure out > what's wrong with my current setup. > > Regards, > meka > > > > Hi, I think it will help if you share more of your configuration/logs. Besides you can take a look with tcpdump/wireshark on what happens on different interfaces of your machines to see the traffic flow between client and server. Regards, Ronald. ------=_Part_65_558795370.1648548860306 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Van: "Goran Mekic" <meka@tilda.center>
Datum: dinsdag, 29 maart 2022 10:11
Aan: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
CC: freebsd-current@freebsd.org
Onderwerp: Re: DHCPDv6 in non-vnet jail

On Sun, Mar 27, 2022 at 02:34:11PM +0000, Bjoern A. Zeeb wrote:
> I assume you have /dev/bpf available inside that jail by a devfs rule so
> effectively you have all network interfaces and traffic available?
As a form of test I've put rtadvd inside the same non-vnet jail and I
can see RA message arrive to the vnet jail. I though I "disconnected"
something concerning IPv6, but that's obviously not the case.

Let's take a step back. Is there any howto/tutorial on how to put
isc-dhcpd6 in a non-vnet jail? I don't care if it's jail.conf or some
jail manager. Can I somehow see where packets end up, like dtrace?
Should I try some other server/client for DHCPv6? If I can make it work
in any scenario, that would be good starting point for me to figure out
what's wrong with my current setup.

Regards,
meka
 


Hi,

I think it will help if you share more of your configuration/logs.
Besides you can take a look with tcpdump/wireshark on what happens on different interfaces of your machines to see the traffic flow between client and server.

Regards,
Ronald.
  ------=_Part_65_558795370.1648548860306-- From nobody Tue Mar 29 11:15:19 2022 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 A1A0B1A36915 for ; Tue, 29 Mar 2022 11:15:22 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSRn56Z9kz4YfK for ; Tue, 29 Mar 2022 11:15:21 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lf1-x129.google.com with SMTP id bu29so29757740lfb.0 for ; Tue, 29 Mar 2022 04:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=1mFz7O61Fx8Hfk0xhtdsbBsmQ1COZTE0bNt7/Pf2/XM=; b=WA88TSrPAGOLyRTaT7GUbFfJq862lOA3kyiy1HXrvN2XDS1cDD9DlI1vg6LFhFdtst W1gp4V78zOPJnXhKhxzeHA0ib+9vX51MaH3nGsb71/SSgB2Ky2PmY9mcoFEzMNS1UXzU 0uUAQ0N0bCVUau4nDT9g1PCus2eG02L49PMl7WWozQH8IPdUOMmn4i2f/Pi+BknlV+T7 S3fPljpNzzuSNBnq9mkWB57yRmNsf/1eSVD4j7+RsImmh8X2q6XcTQVpVJhB8I7Ol1Tv BTppiu0MAAhY2SmKEmIq6z5/G5BWynh8VVVqIY4QmzGZu0agTl4V7P3Esj/VDGvTONmm UPRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1mFz7O61Fx8Hfk0xhtdsbBsmQ1COZTE0bNt7/Pf2/XM=; b=8I3dFkq7EcMZPEl1qa3WNA9hxnmIrX+jz9G3I15bnS+DQ5wGlPfwha+6UYRraG9cz0 so0dT1mUI14CYeuJy8uKkZin/T4obhOCcqQPI/31wbc0tqpnd52Z/n6g7E+M6/3EamXB Pb9QpqywlfxfzOO4bibdJEfgCxZaIujRa+1efZcVdAHOWk9eaontOsidI7VYyHIzO0Ld tGL2RF5HykYj5yRqhHBl37vSTHUeEvLe3WUDN4WS5YhyXyMcmd+m4XBDYRCrHRsF3N0H QQcaEBixAIp0VLg5qgDZ+b+sP/kq+cdXcDDWMHnk+X1OsoHiDwLS+cJbJwJkf1p3f/mL 1wiA== X-Gm-Message-State: AOAM530wwpQispE9s7GRRN3fDfmFK9vyLmOVQAuDyLjExhEwO8RQsEMk /f4qhwQchuwRUQsweqxUbD0IfAIMJRNnibH/+4nnjH47 X-Google-Smtp-Source: ABdhPJxFGNfNd4N+MwwJPNxTvwhN2Jcp0C3K2bT45A9t5Xd2VNKfzBTtS8NYUhnZ/KgFmi2n9w6HWRvJ8QEVQzV2L2g= X-Received: by 2002:a05:6512:2827:b0:44a:8de0:15ae with SMTP id cf39-20020a056512282700b0044a8de015aemr2294521lfb.682.1648552520341; Tue, 29 Mar 2022 04:15:20 -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 Received: by 2002:aa6:cb4a:0:b0:1a5:d1a4:cb83 with HTTP; Tue, 29 Mar 2022 04:15:19 -0700 (PDT) From: Mateusz Guzik Date: Tue, 29 Mar 2022 13:15:19 +0200 Message-ID: Subject: "set but not used" warnings in the kernel To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KSRn56Z9kz4YfK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=WA88TSrP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::129 as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-3.55 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.965]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::129:from]; NEURAL_HAM_SHORT(-0.59)[-0.585]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N This is way too spammy and there is no consistent effort to clean them up, that I can see anyway. As such, I think these warns are doing more damage than help and should be disabled by default. Alternatively, perhaps people can step up. I'm pretty sure to date I got rid of more of these than anyone else. Comments? -- Mateusz Guzik From nobody Tue Mar 29 11:59:22 2022 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 B05C41A42CE7 for ; Tue, 29 Mar 2022 11:59:26 +0000 (UTC) (envelope-from SRS0=GV03=UI=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 4KSSlx4X0fz4jCf for ; Tue, 29 Mar 2022 11:59:25 +0000 (UTC) (envelope-from SRS0=GV03=UI=klop.ws=ronald-lists@realworks.nl) Date: Tue, 29 Mar 2022 13:59:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1648555162; 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=J8SvcdypxzB7XD+CRR0mXE6dhYFwF1ZsjJshkhJVkqg=; b=HuZSmQojkORFZh/bJ3LwssI8yl0Yghx/Uut9o/tScdY7PBk16pKimn0l9zQs0vOExq08Ex iImCyiwhF2RSo366dgrrtL91ffNUg+HmapQg644xWJj1dpXhtXPi46wchsiLcNTG0hlyE7 f+2nH0TSzsS8fFM0N97OgSxcLhp3gfPhIMzk+oPKE4N8AmHueRK6ZHM14pGcgK/OdKOLRx qIecA2zCmnggmK8JDlH72P0xMKJTmiSMTaxVpxtuD6uBHiE4T/9myDFXPUhqDzZIey+4uQ puAYguXvUdeNPeSjRs5IVYAGik7VD3bbsf9O2EL9/f5ZmnJ2fqcmx7VpqCCVJg== From: Ronald Klop To: Mateusz Guzik Cc: freebsd-current@freebsd.org Message-ID: <1033820507.79.1648555162370@mailrelay> In-Reply-To: References: Subject: Re: "set but not used" warnings in the kernel 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_78_1016422895.1648555162281" X-Mailer: Realworks (602.328.5a345bb) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4KSSlx4X0fz4jCf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=HuZSmQoj; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=GV03=UI=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=GV03=UI=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.19 / 15.00]; ARC_NA(0.00)[]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=GV03=UI=klop.ws=ronald-lists@realworks.nl]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RWL_MAILSPIKE_EXCELLENT(0.00)[194.109.157.24:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=GV03=UI=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_78_1016422895.1648555162281 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Is it time for WARNS=7 in the Makefiles? Regards, Ronald. Van: Mateusz Guzik Datum: dinsdag, 29 maart 2022 13:15 Aan: freebsd-current@freebsd.org Onderwerp: "set but not used" warnings in the kernel > > This is way too spammy and there is no consistent effort to clean them up, > that I can see anyway. > > As such, I think these warns are doing more damage than help and should be > disabled by default. > > Alternatively, perhaps people can step up. I'm pretty sure to date I got > rid of more of these than anyone else. > > Comments? > -- > Mateusz Guzik > > > > ------=_Part_78_1016422895.1648555162281 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Is it time for WARNS=7 in the Makefiles?

Regards,
Ronald.

 

Van: Mateusz Guzik <mjguzik@gmail.com>
Datum: dinsdag, 29 maart 2022 13:15
Aan: freebsd-current@freebsd.org
Onderwerp: "set but not used" warnings in the kernel

This is way too spammy and there is no consistent effort to clean them up,
that I can see anyway.

As such, I think these warns are doing more damage than help and should be
disabled by default.

Alternatively, perhaps people can step up. I'm pretty sure to date I got
rid of more of these than anyone else.

Comments?
-- 
Mateusz Guzik <mjguzik gmail.com>
 
------=_Part_78_1016422895.1648555162281-- From nobody Tue Mar 29 15:21:13 2022 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 582481A5449C for ; Tue, 29 Mar 2022 15:21:27 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSYF01Qwsz3n2q for ; Tue, 29 Mar 2022 15:21:23 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPS id 22TFLEwD014855 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 29 Mar 2022 17:21:14 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1648567274; bh=3rTqQP715z42cKdYM55ATvVwu3JoQMACylkwMFeIOvw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=rSie+jzcgTH6IR/qL8FV/NDpzFP37cu26vbFR4M6npwTe4ulT47UN5ULskyGJGNI9 8fvkJw4i9c7N+GWx5QKRuaLAfLdBJKHvCLzLRLMtg+XiCxe0xAbCP3AdXWsashFvl1 nyLBoKj3eg8MYx75I1X/dpCF5e8CCOoysE4piq1cJ8aE8x7tBSjmj4EM8et33mZGdw VWetE+xAb2ODkJpcekLYZLmt+A9uHP7e9kjAuLhBG3QIHPcrlBo9fbf6atxyrbzGzt HDoeTpayYA8KsYJieqhNNApV9jw8/zzPG6xLkYkNtvohvatOHVVNHJyhW+J8w3kSxv P0giANOEFPOrg== Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.17.1/8.17.1/Submit) id 22TFLDiY014853; Tue, 29 Mar 2022 17:21:13 +0200 (CEST) (envelope-from zarychtam) Date: Tue, 29 Mar 2022 17:21:13 +0200 From: Marek Zarychta To: Goran =?utf-8?B?TWVracSH?= Cc: "Bjoern A. Zeeb" , freebsd-current@freebsd.org Subject: Re: DHCPDv6 in non-vnet jail Message-ID: References: <20220326222957.wuc7xwyiq3bjtlnv@tilda.center> <4772ECB8-6482-4B94-A887-F04EC6272911@lists.zabbadoz.net> <20220329081129.p5xtxlbiyw6klxcl@tilda.center> 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: <20220329081129.p5xtxlbiyw6klxcl@tilda.center> X-Rspamd-Queue-Id: 4KSYF01Qwsz3n2q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=rSie+jzc; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-3.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Dnia Tue, Mar 29, 2022 at 10:11:29AM +0200, Goran Mekić napisał(a): > On Sun, Mar 27, 2022 at 02:34:11PM +0000, Bjoern A. Zeeb wrote: > > I assume you have /dev/bpf available inside that jail by a devfs rule so > > effectively you have all network interfaces and traffic available? > As a form of test I've put rtadvd inside the same non-vnet jail and I > can see RA message arrive to the vnet jail. I though I "disconnected" > something concerning IPv6, but that's obviously not the case. > > Let's take a step back. Is there any howto/tutorial on how to put > isc-dhcpd6 in a non-vnet jail? I don't care if it's jail.conf or some > jail manager. Can I somehow see where packets end up, like dtrace? > Should I try some other server/client for DHCPv6? If I can make it work > in any scenario, that would be good starting point for me to figure out > what's wrong with my current setup. > > Regards, > meka Running DHCPv6 in a jail is possible and pretty straigtforward if /dev/bpf is exposed, but I have never tried to run rtadvd(8) in the jail. The net/isc-dhcp44-server works flawlessy in dedicated DHCPv6 reduntant jails without VNET, but the RA is always done on the core switches for all suppoted subnets in my case. Please consider that DHCPv6 is never replacement, but addition to properly confiugred RA. Best regards, -- Marek Zarychta From nobody Tue Mar 29 16:11:05 2022 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 0ADD31A4CF1E for ; Tue, 29 Mar 2022 19:31:19 +0000 (UTC) (envelope-from meka@tilda.center) Received: from c3po.tilda.center (c3po.tilda.center [108.61.164.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSfnK519yz52NN for ; Tue, 29 Mar 2022 19:31:17 +0000 (UTC) (envelope-from meka@tilda.center) Received: from tilda.center (109-93-255-137.static.isp.telekom.rs [109.93.255.137]) by c3po.tilda.center (Postfix) with ESMTPSA id 32E131CBE9; Tue, 29 Mar 2022 21:31:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tilda.center; s=c3po; t=1648582275; 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=GZvvfHUgPekkZai2kChCRvjBq8ofdCkZJ0vHPwdwS/o=; b=KQ+RW9dKGEESqWkJrXH9mXV4FyyTxEM1rJjtauSOBqh/wJAjNyKCrLwV/oKwzfY/teidIG yxEiZkg0vAo6Y3Q8irfw1n9GVnj92luxSvIts7S3miSQ/+3NZIUTqxP5R1XGlsG7J9n9rZ zeqwaQwMe6zvBkmuJz+rodBSAWRD7OY= Date: Tue, 29 Mar 2022 18:11:05 +0200 From: Goran =?utf-8?B?TWVracSH?= To: Ronald Klop Cc: freebsd-current@freebsd.org, "Bjoern A. Zeeb" Subject: Re: DHCPDv6 in non-vnet jail Message-ID: <20220329161105.uw5aigvpazd77we4@tilda.center> References: <20220326222957.wuc7xwyiq3bjtlnv@tilda.center> <4772ECB8-6482-4B94-A887-F04EC6272911@lists.zabbadoz.net> <20220329081129.p5xtxlbiyw6klxcl@tilda.center> <1527544025.66.1648548860391@mailrelay> 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="jreevis3qtujrjsm" Content-Disposition: inline In-Reply-To: <1527544025.66.1648548860391@mailrelay> X-Rspamd-Queue-Id: 4KSfnK519yz52NN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tilda.center header.s=c3po header.b=KQ+RW9dK; dmarc=pass (policy=reject) header.from=tilda.center; spf=pass (mx1.freebsd.org: domain of meka@tilda.center designates 108.61.164.129 as permitted sender) smtp.mailfrom=meka@tilda.center X-Spamd-Result: default: False [-4.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[tilda.center:s=c3po]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_SPAM_SHORT(0.43)[0.433]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[tilda.center:+]; DMARC_POLICY_ALLOW(-0.50)[tilda.center,reject]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.62)[subject]; ASN(0.00)[asn:20473, ipnet:108.61.164.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --jreevis3qtujrjsm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Tue, Mar 29, 2022 at 12:14:20PM +0200, Ronald Klop wrote: > I think it will help if you share more of your configuration/logs. Inside non-vnet jail, this is ifconfig output cbsd0: flags=8843 metric 0 mtu 1500 description: lagg0 ether 58:9c:fc:10:9b:75 inet 172.16.0.253 netmask 0xffffffff broadcast 172.16.0.253 inet6 fd10:6c79:8ae5:8b91::2 prefixlen 128 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: epair1a flags=143 ifmaxaddr 0 port 7 priority 128 path cost 2000 member: epair5a flags=143 ifmaxaddr 0 port 11 priority 128 path cost 2000 member: epair4a flags=143 ifmaxaddr 0 port 10 priority 128 path cost 2000 member: epair3a flags=143 ifmaxaddr 0 port 9 priority 128 path cost 2000 member: epair2a flags=143 ifmaxaddr 0 port 8 priority 128 path cost 2000 groups: bridge nd6 options=21 There are bunch of other interfaces, but only cbsd0 (bridge interface) is set up with ip address. netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire 172.16.0.253 link#4 UH cbsd0 Internet6: Destination Gateway Flags Netif Expire fd10:6c79:8ae5:8b91::2 link#4 UHS lo0 grep -v '^#' /usr/local/etc/dhcpd6.conf default-lease-time 2592000; preferred-lifetime 604800; option dhcp-renewal-time 3600; option dhcp-rebinding-time 7200; allow leasequery; option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3f3e; option dhcp6.domain-search "test.example.com","example.com"; option dhcp6.info-refresh-time 21600; dhcpv6-lease-file-name "/var/db/dhcpd6/dhcpd6.leases"; subnet6 fd10:6c79:8ae5:8b91::/64 { range6 fd10:6c79:8ae5:8b91::/64; } ls -l /dev total 1 crw------- 1 root wheel 0x26 Mar 29 17:35 bpf lrwxr-xr-x 1 root wheel 3 Mar 28 09:31 bpf0 -> bpf crw-rw-rw- 1 root wheel 0x4a Mar 26 15:54 crypto dr-xr-xr-x 2 root wheel 512 Mar 29 03:38 fd crw-rw-rw- 1 root wheel 0x2a Mar 29 18:00 null crw-rw---- 1 root nsd 0x1a5 Mar 24 23:45 pf crw-rw---- 1 root nsd 0x4b Mar 26 15:54 pfil dr-xr-xr-x 2 root wheel 512 Mar 28 09:31 pts crw-r--r-- 1 root wheel 0x8 Mar 24 23:45 random lrwxr-xr-x 1 root wheel 4 Mar 28 09:31 stderr -> fd/2 lrwxr-xr-x 1 root wheel 4 Mar 28 09:31 stdin -> fd/0 lrwxr-xr-x 1 root wheel 4 Mar 28 09:31 stdout -> fd/1 lrwxr-xr-x 1 root wheel 6 Mar 28 09:31 urandom -> random crw-rw-rw- 1 root wheel 0x2b Mar 26 15:54 zero On the host I have /etc/rtadvd.conf: cbsd0:addr="fd10:6c79:8ae5:8b91::":raflags="m" On the host ifconfig cbsd0 cbsd0: flags=8843 metric 0 mtu 1500 description: lagg0 ether 58:9c:fc:10:9b:75 inet 172.16.0.254 netmask 0xffffff00 broadcast 172.16.0.255 inet 172.16.1.254 netmask 0xffffff00 broadcast 172.16.1.255 inet 172.16.0.253 netmask 0xffffffff broadcast 172.16.0.253 inet6 fe80::5a9c:fcff:fe10:9b75%cbsd0 prefixlen 64 scopeid 0x4 inet6 fd10:6c79:8ae5:8b91::1 prefixlen 64 inet6 fd10:6c79:8ae5:8b91::2 prefixlen 128 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: epair1a flags=143 ifmaxaddr 0 port 7 priority 128 path cost 2000 member: epair5a flags=143 ifmaxaddr 0 port 11 priority 128 path cost 2000 member: epair4a flags=143 ifmaxaddr 0 port 10 priority 128 path cost 2000 member: epair3a flags=143 ifmaxaddr 0 port 9 priority 128 path cost 2000 member: epair2a flags=143 ifmaxaddr 0 port 8 priority 128 path cost 2000 groups: bridge nd6 options=21 > Besides you can take a look with tcpdump/wireshark on what happens on different interfaces of your machines to see the traffic flow between client and server. Running tcpdump -i cbsd0 ip6 inside the non-vnet: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on cbsd0, link-type EN10MB (Ethernet), capture size 262144 bytes 18:02:29.081325 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 18:02:51.229813 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit 18:02:52.338420 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit 18:02:54.444709 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit 18:02:58.449268 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit 18:02:59.083071 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 18:03:06.545104 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit 18:03:12.355503 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 18:03:22.890933 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit 18:03:29.084154 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 18:03:54.837662 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit 18:03:59.081342 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 18:04:29.083992 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 18:04:41.028190 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 That happens while I'm running dhcp6c -d -f eth0 inside vnet jail (eth0 is epair that is renamed): Mar/29/2022 18:02:50: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory Mar/29/2022 18:02:50: failed initialize control message authentication Mar/29/2022 18:02:50: skip opening control port Mar/29/2022 18:02:50: cfparse: fopen(/usr/local/etc/dhcp6c.conf): No such file or directory Mar/29/2022 18:02:51: Sending Solicit Mar/29/2022 18:02:52: Sending Solicit Mar/29/2022 18:02:54: Sending Solicit Mar/29/2022 18:02:58: Sending Solicit Mar/29/2022 18:03:06: Sending Solicit Mar/29/2022 18:03:22: Sending Solicit Mar/29/2022 18:03:54: Sending Solicit Can I provide any more info? Regards, meka --jreevis3qtujrjsm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE1WIFkXy2ZeMKjjKEWj1TknovrLYFAmJDL5UACgkQWj1Tknov rLaTng//aDJ45nZnYn+hD8Dx1sfFf5jvfb13weMAQ2z/E+cTmMPyRF5H4R3F0Tr6 VWdth0RNO4/8ffueMSNf2hPFJVN06bYw3ddW8qBCxaOSl8VPOYa+QbF8Ol0wth3S BzuQzCDbotZBFIcZ7yKJMD3jRbBAWU93gYw7otmFLS4LQOjzr3J807VGO/B6zBjm DySc3aoCQL7FDqIpEq2yMcF+QeOgtnSrkIWMM1ZKzGXmDnGhs8MWEs3yksa4Ybn+ Yr+1j1Jzdsa0voIPU3dmC7Qxq5TxJGxTzoxRgnMDUEpFtrbjMG2o8r2FClBwzYS3 yI9qoIcII4jSAWnz1WyX/9jaBjo+ml2oiFNVxXagunvJlUC9i5PbowxVyw/QXsoS +u3C6M+32M16WGdyahuupK1TZ1te5UMqXQ2G/JmfHuGB3y84m8JyyDT+xQ3HbkYe qhsb0NVfvhAMrwXeq4Gbz7e1uzgY9aIQuMAS1MGBTfw28MrnHEw6zSMkIVSErw2F nITXmwul0/nQY2WtXEq5YKoIy/sBBVHo2z4dlA1IXec6Bnok4SNol6OAyULZs/gm PQr0Wc5gj1JuWBPhVl5L5lKLO4HNvGhcyGVkrk4V02VU5trK5SKqFBAP+VwXmZIq 4cE9L5nWE5u7D5WG5PS9PgP2e/csaqR+Ukfoy4HqtHvzFNAdCbA= =RmKY -----END PGP SIGNATURE----- --jreevis3qtujrjsm-- From nobody Tue Mar 29 16:22:53 2022 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 8A3501A518D9 for ; Tue, 29 Mar 2022 19:43:06 +0000 (UTC) (envelope-from meka@tilda.center) Received: from c3po.tilda.center (c3po.tilda.center [108.61.164.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSg2x5RqKz56Dq for ; Tue, 29 Mar 2022 19:43:05 +0000 (UTC) (envelope-from meka@tilda.center) Received: from tilda.center (109-93-255-137.static.isp.telekom.rs [109.93.255.137]) by c3po.tilda.center (Postfix) with ESMTPSA id 9071D1CC12; Tue, 29 Mar 2022 21:43:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tilda.center; s=c3po; t=1648582984; 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=Vo4uWSSdjLDw8bvfqnBHuEuzofwpzkn4V9faSEcUam4=; b=oz7D3KAUScUZnIGpkxb+GT+onGhre4HmwF/MNyuFbfEOSeWrQc3z5cCnBVlIWD28bb37Hi Pi8xHwz6gL22POuyicRExIqGDdesjUtryxFt93Srtj0BWWt4Pdm+G/cItMN5aw5m/BIdPZ 7p2ws0IZNssSvU8derZCKWCfTUJkHuQ= Date: Tue, 29 Mar 2022 18:22:53 +0200 From: Goran =?utf-8?B?TWVracSH?= To: Marek Zarychta Cc: "Bjoern A. Zeeb" , freebsd-current@freebsd.org Subject: Re: DHCPDv6 in non-vnet jail Message-ID: <20220329162253.h77no62qqtilwtoz@tilda.center> References: <20220326222957.wuc7xwyiq3bjtlnv@tilda.center> <4772ECB8-6482-4B94-A887-F04EC6272911@lists.zabbadoz.net> <20220329081129.p5xtxlbiyw6klxcl@tilda.center> 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="kjvys6whaicpakk4" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KSg2x5RqKz56Dq X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tilda.center header.s=c3po header.b=oz7D3KAU; dmarc=pass (policy=reject) header.from=tilda.center; spf=pass (mx1.freebsd.org: domain of meka@tilda.center designates 108.61.164.129 as permitted sender) smtp.mailfrom=meka@tilda.center X-Spamd-Result: default: False [-5.47 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[tilda.center:s=c3po]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[tilda.center:+]; DMARC_POLICY_ALLOW(-0.50)[tilda.center,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.62)[subject]; ASN(0.00)[asn:20473, ipnet:108.61.164.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --kjvys6whaicpakk4 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Tue, Mar 29, 2022 at 05:21:13PM +0200, Marek Zarychta wrote: > Running DHCPv6 in a jail is possible and pretty straigtforward if > /dev/bpf is exposed, but I have never tried to run rtadvd(8) in the > jail. The net/isc-dhcp44-server works flawlessy in dedicated DHCPv6 > reduntant jails without VNET, but the RA is always done on the core > switches for all suppoted subnets in my case. Please consider that > DHCPv6 is never replacement, but addition to properly confiugred RA. I ran rtadvd inside jail just to see if RA messages are going back and forth as I suspected I'm blocking something. Otherwise, I'm running rtadvd on the host. If I understand it right, rtadvd's raflags="m" should tell rtsold to run external script. I'm just running it by hand so I use the least amount of software possible. Is that wrong? Should dhcp6c be run with rtsold -M? I tried with rtsold_flags="-a -M /usr/local/bin/dhcp6c" without luck. Regards, meka --kjvys6whaicpakk4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE1WIFkXy2ZeMKjjKEWj1TknovrLYFAmJDMloACgkQWj1Tknov rLYNYA//YGbeBccj7GawOicIJrIxXhoMDGV1kfKMYbosCyIbwJtR+2DdIj0BpXdO FSeyBVZ4SxVjCAmAc6MD9iuaRJcIwJwNio51BBRTlaAtMqUqvjiMievxjHBZOOqk BB3eAT8QBMVRcLsfvIk04wLyj373YbI9oW2fvvFR4GNJwtiZO837sALZaCSAcb8Q W3knkKKkwb1mXPdqWtEKE9PWsc2m6wc65vRvN/MhDxaZoIwUCDLrH6vCJuG84Pip jkhmgMB745OUArEf9H4oK8TXAdoVBNIB8XyYF0hwm3azMpCYYp23vxKCmCfImgll QFHK+wrEB417fJrZcsOjHNRyi5Vln2UTc9+XVMxgqWwNzaXSBs/cW1qL4IL9QztQ WporIXp+2HTqYBzqFgDmRoyltLsVpLJGkuM3QyZGOxXzMNAkjORsoSHfjdMlZTSR Al3LglP30+odrhh/n4IDHSns43UA5Dg0zhPTqJkahhNNp1WbATVFVHYOCs9OtGt9 fabdk5FNu5hOkbHIUoDWk37eInRGdxAG2ARoRW+WJ8LgERATn5SNEmd1zIwgSf1v UdhbapB65t40Ukoraz+qB4TVNuF92s101PNKy6Aro53wtu+AYdUQ0l/3arJht2F5 roM3R3sb+qnANcWnTRfuo8KRCsOgkVXm+fZMBh+4YXdX/dV3Crg= =+H3m -----END PGP SIGNATURE----- --kjvys6whaicpakk4-- From nobody Wed Mar 30 12:45:17 2022 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 E690E1A3CDFF for ; Wed, 30 Mar 2022 12:45:26 +0000 (UTC) (envelope-from SRS0=+oX9=UJ=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 4KT5kY4jwpz4VpQ for ; Wed, 30 Mar 2022 12:45:25 +0000 (UTC) (envelope-from SRS0=+oX9=UJ=klop.ws=ronald-lists@realworks.nl) Date: Wed, 30 Mar 2022 14:45:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1648644317; 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=Kn/VSnx8pZVRWlhEudoNgDhFBKLDcMBCi+Za2whXRds=; b=ZdZDUjui2AyJ9uPVsrgSg+lj0OE4BWs8Ih8ISZVBwEFizdUAevoS2S/2GvgY4dWaFia1qA Vu7y5WLcjYKMQkzZeF4vFCm4qk47DWTlTJuEAWAhEZAqOqxLqANUjGs+MWTXfBLS6Z7Qes m6Ew6esPtPK7o/weq+3iYMTK+h/D/7P+U8l1RFM6kge1tOWo7yjsnq/FoQXnF2hdqEf9Dm OxBB4WsJqQJi6r3NzZwy6knemGKjYKoS2c8lTzu5jJzoWtHVtetSFJu94rulyQ+LaceURH IL98q6yAe76vMM+97NEhrmVXnCfrdlKdgtzYDzvgJ2hJhsY6otqPzEDLTFVKtg== From: Ronald Klop To: Goran Mekic Cc: freebsd-current@freebsd.org, "Bjoern A. Zeeb" Message-ID: <900760441.75.1648644317126@mailrelay> In-Reply-To: <20220329161105.uw5aigvpazd77we4@tilda.center> References: <20220326222957.wuc7xwyiq3bjtlnv@tilda.center> <4772ECB8-6482-4B94-A887-F04EC6272911@lists.zabbadoz.net> <20220329081129.p5xtxlbiyw6klxcl@tilda.center> <1527544025.66.1648548860391@mailrelay> <20220329161105.uw5aigvpazd77we4@tilda.center> Subject: Re: DHCPDv6 in non-vnet jail 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_74_956993994.1648644316049" X-Mailer: Realworks (602.338.ca2f1f9) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4KT5kY4jwpz4VpQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=ZdZDUjui; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RWL_MAILSPIKE_EXCELLENT(0.00)[194.109.157.24:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; TAGGED_FROM(0.00)[oX9=UJ=klop.ws=ronald-lists]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_74_956993994.1648644316049 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, First. I'm not an IPv6 expert. Got it running at home. Although with SLAAC, not DHCP yet. Another disclaimer is that I use VNET-jails nowadays. But I like to try and think along with you. What surprises me is that your non-vnet jail does not have a LINKLOCAL fe80::: address. These addresses are used for configuration in the local network (AFAIK). And your routing table does not contain a line like this: ff02::/16 ::1 UGRS lo0 So how is the ff02:: multicast routed in your network? But the tcpdump shows that the multicast solicit message is received on the non-vnet dhcp-server so that seems to work: 18:02:51.229813 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit I don't know if the dhcp-server program also sees this request coming in on its interface. Maybe extra logging can help there. According to https://en.wikipedia.org/wiki/DHCPv6#Example the dhcp-server would reply with a link-local fe80:: address. "Server replies with an advertise from [fe80::0011:22ff:fe33:5566]:547 to [fe80::aabb:ccff:fedd:eeff]:546." But your dhcp-server does not have an fe80::. So I'm wondering how that would work. More questions than answers. But I hope it helps. Regards, Ronald. Van: "Goran Mekic" Datum: dinsdag, 29 maart 2022 18:11 Aan: Ronald Klop CC: freebsd-current@freebsd.org, "Bjoern A. Zeeb" Onderwerp: Re: DHCPDv6 in non-vnet jail > > On Tue, Mar 29, 2022 at 12:14:20PM +0200, Ronald Klop wrote: > > I think it will help if you share more of your configuration/logs. > Inside non-vnet jail, this is ifconfig output > cbsd0: flags=8843 metric 0 mtu 1500 > description: lagg0 > ether 58:9c:fc:10:9b:75 > inet 172.16.0.253 netmask 0xffffffff broadcast 172.16.0.253 > inet6 fd10:6c79:8ae5:8b91::2 prefixlen 128 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: epair1a flags=143 > ifmaxaddr 0 port 7 priority 128 path cost 2000 > member: epair5a flags=143 > ifmaxaddr 0 port 11 priority 128 path cost 2000 > member: epair4a flags=143 > ifmaxaddr 0 port 10 priority 128 path cost 2000 > member: epair3a flags=143 > ifmaxaddr 0 port 9 priority 128 path cost 2000 > member: epair2a flags=143 > ifmaxaddr 0 port 8 priority 128 path cost 2000 > groups: bridge > nd6 options=21 > > There are bunch of other interfaces, but only cbsd0 (bridge interface) > is set up with ip address. > > > netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > 172.16.0.253 link#4 UH cbsd0 > > Internet6: > Destination Gateway Flags Netif Expire > fd10:6c79:8ae5:8b91::2 link#4 UHS lo0 > > > grep -v '^#' /usr/local/etc/dhcpd6.conf > > default-lease-time 2592000; > preferred-lifetime 604800; > option dhcp-renewal-time 3600; > option dhcp-rebinding-time 7200; > allow leasequery; > option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3f3e; > option dhcp6.domain-search "test.example.com","example.com"; > option dhcp6.info-refresh-time 21600; > dhcpv6-lease-file-name "/var/db/dhcpd6/dhcpd6.leases"; > > subnet6 fd10:6c79:8ae5:8b91::/64 { > range6 fd10:6c79:8ae5:8b91::/64; > } > > > ls -l /dev > total 1 > crw------- 1 root wheel 0x26 Mar 29 17:35 bpf > lrwxr-xr-x 1 root wheel 3 Mar 28 09:31 bpf0 -> bpf > crw-rw-rw- 1 root wheel 0x4a Mar 26 15:54 crypto > dr-xr-xr-x 2 root wheel 512 Mar 29 03:38 fd > crw-rw-rw- 1 root wheel 0x2a Mar 29 18:00 null > crw-rw---- 1 root nsd 0x1a5 Mar 24 23:45 pf > crw-rw---- 1 root nsd 0x4b Mar 26 15:54 pfil > dr-xr-xr-x 2 root wheel 512 Mar 28 09:31 pts > crw-r--r-- 1 root wheel 0x8 Mar 24 23:45 random > lrwxr-xr-x 1 root wheel 4 Mar 28 09:31 stderr -> fd/2 > lrwxr-xr-x 1 root wheel 4 Mar 28 09:31 stdin -> fd/0 > lrwxr-xr-x 1 root wheel 4 Mar 28 09:31 stdout -> fd/1 > lrwxr-xr-x 1 root wheel 6 Mar 28 09:31 urandom -> random > crw-rw-rw- 1 root wheel 0x2b Mar 26 15:54 zero > > > > On the host I have /etc/rtadvd.conf: > cbsd0:addr="fd10:6c79:8ae5:8b91::":raflags="m" > > > On the host ifconfig cbsd0 > cbsd0: flags=8843 metric 0 mtu 1500 > description: lagg0 > ether 58:9c:fc:10:9b:75 > inet 172.16.0.254 netmask 0xffffff00 broadcast 172.16.0.255 > inet 172.16.1.254 netmask 0xffffff00 broadcast 172.16.1.255 > inet 172.16.0.253 netmask 0xffffffff broadcast 172.16.0.253 > inet6 fe80::5a9c:fcff:fe10:9b75%cbsd0 prefixlen 64 scopeid 0x4 > inet6 fd10:6c79:8ae5:8b91::1 prefixlen 64 > inet6 fd10:6c79:8ae5:8b91::2 prefixlen 128 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: epair1a flags=143 > ifmaxaddr 0 port 7 priority 128 path cost 2000 > member: epair5a flags=143 > ifmaxaddr 0 port 11 priority 128 path cost 2000 > member: epair4a flags=143 > ifmaxaddr 0 port 10 priority 128 path cost 2000 > member: epair3a flags=143 > ifmaxaddr 0 port 9 priority 128 path cost 2000 > member: epair2a flags=143 > ifmaxaddr 0 port 8 priority 128 path cost 2000 > groups: bridge > nd6 options=21 > > > Besides you can take a look with tcpdump/wireshark on what happens on different interfaces of your machines to see the traffic flow between client and server. > Running tcpdump -i cbsd0 ip6 inside the non-vnet: > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on cbsd0, link-type EN10MB (Ethernet), capture size 262144 bytes > 18:02:29.081325 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 > 18:02:51.229813 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit > 18:02:52.338420 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit > 18:02:54.444709 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit > 18:02:58.449268 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit > 18:02:59.083071 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 > 18:03:06.545104 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit > 18:03:12.355503 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 > 18:03:22.890933 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit > 18:03:29.084154 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 > 18:03:54.837662 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit > 18:03:59.081342 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 > 18:04:29.083992 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 > 18:04:41.028190 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322 > > > That happens while I'm running dhcp6c -d -f eth0 inside vnet jail (eth0 > is epair that is renamed): > Mar/29/2022 18:02:50: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory > Mar/29/2022 18:02:50: failed initialize control message authentication > Mar/29/2022 18:02:50: skip opening control port > Mar/29/2022 18:02:50: cfparse: fopen(/usr/local/etc/dhcp6c.conf): No such file or directory > Mar/29/2022 18:02:51: Sending Solicit > Mar/29/2022 18:02:52: Sending Solicit > Mar/29/2022 18:02:54: Sending Solicit > Mar/29/2022 18:02:58: Sending Solicit > Mar/29/2022 18:03:06: Sending Solicit > Mar/29/2022 18:03:22: Sending Solicit > Mar/29/2022 18:03:54: Sending Solicit > > > > Can I provide any more info? > > Regards, > meka > > > > ------=_Part_74_956993994.1648644316049 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

First. I'm not an IPv6 expert. Got it running at home. Although with SLAAC, not DHCP yet.
Another disclaimer is that I use VNET-jails nowadays.
But I like to try and think along with you.

What surprises me is that your non-vnet jail does not have a LINKLOCAL fe80::: address. These addresses are used for configuration in the local network (AFAIK).
And your routing table does not contain a line like this:
ff02::/16                         ::1                           UGRS        lo0

So how is the ff02:: multicast routed in your network?

But the tcpdump shows that the multicast solicit message is received on the non-vnet dhcp-server so that seems to work:
18:02:51.229813 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
I don't know if the dhcp-server program also sees this request coming in on its interface. Maybe extra logging can help there.

According to https://en.wikipedia.org/wiki/DHCPv6#Example the dhcp-server would reply with a link-local fe80:: address.
"Server replies with an advertise from [fe80::0011:22ff:fe33:5566]:547 to [fe80::aabb:ccff:fedd:eeff]:546."
But your dhcp-server does not have an fe80::.

So I'm wondering how that would work.

More questions than answers. But I hope it helps.

Regards,
Ronald.


 

Van: "Goran Mekic" <meka@tilda.center>
Datum: dinsdag, 29 maart 2022 18:11
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: freebsd-current@freebsd.org, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
Onderwerp: Re: DHCPDv6 in non-vnet jail

On Tue, Mar 29, 2022 at 12:14:20PM +0200, Ronald Klop wrote:
> I think it will help if you share more of your configuration/logs.
Inside non-vnet jail, this is ifconfig output
cbsd0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    description: lagg0
    ether 58:9c:fc:10:9b:75
    inet 172.16.0.253 netmask 0xffffffff broadcast 172.16.0.253
    inet6 fd10:6c79:8ae5:8b91::2 prefixlen 128
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    member: epair1a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 7 priority 128 path cost 2000
    member: epair5a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 11 priority 128 path cost 2000
    member: epair4a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 10 priority 128 path cost 2000
    member: epair3a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 9 priority 128 path cost 2000
    member: epair2a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 8 priority 128 path cost 2000
    groups: bridge
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

There are bunch of other interfaces, but only cbsd0 (bridge interface)
is set up with ip address.


netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
172.16.0.253       link#4             UH        cbsd0

Internet6:
Destination                       Gateway                       Flags     Netif Expire
fd10:6c79:8ae5:8b91::2            link#4                        UHS         lo0


grep -v '^#' /usr/local/etc/dhcpd6.conf

default-lease-time 2592000;
preferred-lifetime 604800;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
allow leasequery;
option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3f3e;
option dhcp6.domain-search "test.example.com","example.com";
option dhcp6.info-refresh-time 21600;
dhcpv6-lease-file-name "/var/db/dhcpd6/dhcpd6.leases";

subnet6 fd10:6c79:8ae5:8b91::/64 {
  range6 fd10:6c79:8ae5:8b91::/64;
}


ls -l /dev
total 1
crw-------  1 root  wheel   0x26 Mar 29 17:35 bpf
lrwxr-xr-x  1 root  wheel      3 Mar 28 09:31 bpf0 -> bpf
crw-rw-rw-  1 root  wheel   0x4a Mar 26 15:54 crypto
dr-xr-xr-x  2 root  wheel    512 Mar 29 03:38 fd
crw-rw-rw-  1 root  wheel   0x2a Mar 29 18:00 null
crw-rw----  1 root  nsd    0x1a5 Mar 24 23:45 pf
crw-rw----  1 root  nsd     0x4b Mar 26 15:54 pfil
dr-xr-xr-x  2 root  wheel    512 Mar 28 09:31 pts
crw-r--r--  1 root  wheel    0x8 Mar 24 23:45 random
lrwxr-xr-x  1 root  wheel      4 Mar 28 09:31 stderr -> fd/2
lrwxr-xr-x  1 root  wheel      4 Mar 28 09:31 stdin -> fd/0
lrwxr-xr-x  1 root  wheel      4 Mar 28 09:31 stdout -> fd/1
lrwxr-xr-x  1 root  wheel      6 Mar 28 09:31 urandom -> random
crw-rw-rw-  1 root  wheel   0x2b Mar 26 15:54 zero



On the host I have /etc/rtadvd.conf:
cbsd0:addr="fd10:6c79:8ae5:8b91::":raflags="m"


On the host ifconfig cbsd0
cbsd0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    description: lagg0
    ether 58:9c:fc:10:9b:75
    inet 172.16.0.254 netmask 0xffffff00 broadcast 172.16.0.255
    inet 172.16.1.254 netmask 0xffffff00 broadcast 172.16.1.255
    inet 172.16.0.253 netmask 0xffffffff broadcast 172.16.0.253
    inet6 fe80::5a9c:fcff:fe10:9b75%cbsd0 prefixlen 64 scopeid 0x4
    inet6 fd10:6c79:8ae5:8b91::1 prefixlen 64
    inet6 fd10:6c79:8ae5:8b91::2 prefixlen 128
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    member: epair1a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 7 priority 128 path cost 2000
    member: epair5a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 11 priority 128 path cost 2000
    member: epair4a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 10 priority 128 path cost 2000
    member: epair3a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 9 priority 128 path cost 2000
    member: epair2a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 8 priority 128 path cost 2000
    groups: bridge
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

> Besides you can take a look with tcpdump/wireshark on what happens on different interfaces of your machines to see the traffic flow between client and server.
Running tcpdump -i cbsd0 ip6 inside the non-vnet:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cbsd0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:02:29.081325 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322
18:02:51.229813 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
18:02:52.338420 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
18:02:54.444709 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
18:02:58.449268 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
18:02:59.083071 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322
18:03:06.545104 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
18:03:12.355503 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322
18:03:22.890933 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
18:03:29.084154 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322
18:03:54.837662 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
18:03:59.081342 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322
18:04:29.083992 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322
18:04:41.028190 IP6 fe80::5a9c:fcff:fe10:9b75.10482 > ff12::8384.21027: UDP, length 322


That happens while I'm running dhcp6c -d -f eth0 inside vnet jail (eth0
is epair that is renamed):
Mar/29/2022 18:02:50: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Mar/29/2022 18:02:50: failed initialize control message authentication
Mar/29/2022 18:02:50: skip opening control port
Mar/29/2022 18:02:50: cfparse: fopen(/usr/local/etc/dhcp6c.conf): No such file or directory
Mar/29/2022 18:02:51: Sending Solicit
Mar/29/2022 18:02:52: Sending Solicit
Mar/29/2022 18:02:54: Sending Solicit
Mar/29/2022 18:02:58: Sending Solicit
Mar/29/2022 18:03:06: Sending Solicit
Mar/29/2022 18:03:22: Sending Solicit
Mar/29/2022 18:03:54: Sending Solicit



Can I provide any more info?

Regards,
meka
 
------=_Part_74_956993994.1648644316049-- From nobody Wed Mar 30 21:27:13 2022 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 324E01A45F4E for ; Wed, 30 Mar 2022 21:27:20 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTKJl6h2Mz4bmg for ; Wed, 30 Mar 2022 21:27:19 +0000 (UTC) (envelope-from 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 22ULRDE0001113 for ; Wed, 30 Mar 2022 14:27:19 -0700 (PDT) (envelope-from bsd-lists@bsdforge.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 Date: Wed, 30 Mar 2022 14:27:13 -0700 From: Chris To: freebsd-current Subject: Any hope for 802.11ac on an Atheros chip? User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_19ea2b084e2c9a3a69f378ab1ab66c7f" X-Rspamd-Queue-Id: 4KTKJl6h2Mz4bmg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_19ea2b084e2c9a3a69f378ab1ab66c7f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I recently got a laptop, and picked up an Atheros QCA6174 2x2 802.11ac card for it. But after putting it in. FreeBSD-(13 && 13.1) doesn't even know it's there. I was sure that they were supported, as it was reported to be "close/almost finished" in the July-September 2020 Quarterly report[1] as well as a report by Adrian that "We know whats missing"[2] somewhat later on the mailing list. So where can I find it? :-) Thank you for all your time, and consideration. --Chris 1. https://www.freebsd.org/status/report-2020-07-2020-09.html 2. https://www.mail-archive.com/freebsd-wireless@freebsd.org/msg06983.html --=_19ea2b084e2c9a3a69f378ab1ab66c7f Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_19ea2b084e2c9a3a69f378ab1ab66c7f-- From nobody Thu Mar 31 18:03:36 2022 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 32FC71A5C4D0 for ; Thu, 31 Mar 2022 18:03:47 +0000 (UTC) (envelope-from meka@tilda.center) Received: from c3po.tilda.center (c3po.tilda.center [108.61.164.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTrlP6DbFz3Fl8 for ; Thu, 31 Mar 2022 18:03:45 +0000 (UTC) (envelope-from meka@tilda.center) Received: from tilda.center (109-93-255-137.static.isp.telekom.rs [109.93.255.137]) by c3po.tilda.center (Postfix) with ESMTPSA id 6BE151EB06; Thu, 31 Mar 2022 20:03:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tilda.center; s=c3po; t=1648749817; 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=8UU1Xg/FbfKMDOxzOdUUqSSB3tTCl/iMnNV/zSKD99E=; b=T6i6sFPjK/d8M+7K9S/yOczdfq0+FOPHZb2oZyZiPtmLZOXAGfb8E1emwv9AqKnTeDYijS 1RcdmTGfuwCmp+X3+pKWhGaJ5KY18etZj+fFKAGOn1nBHimFOGnO0PUHQCpgbY4pBipt+0 g4HdeHPiZcUYMpiAdefunL4ujwAgUSQ= Date: Thu, 31 Mar 2022 20:03:36 +0200 From: Goran =?utf-8?B?TWVracSH?= To: Ronald Klop Cc: freebsd-current@freebsd.org, "Bjoern A. Zeeb" Subject: Re: DHCPDv6 in non-vnet jail Message-ID: <20220331175315.qr3brqiug6ujigks@tilda.center> References: <20220326222957.wuc7xwyiq3bjtlnv@tilda.center> <4772ECB8-6482-4B94-A887-F04EC6272911@lists.zabbadoz.net> <20220329081129.p5xtxlbiyw6klxcl@tilda.center> <1527544025.66.1648548860391@mailrelay> <20220329161105.uw5aigvpazd77we4@tilda.center> <900760441.75.1648644317126@mailrelay> 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="w3bc75zt3ylmwpnx" Content-Disposition: inline In-Reply-To: <900760441.75.1648644317126@mailrelay> X-Rspamd-Queue-Id: 4KTrlP6DbFz3Fl8 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tilda.center header.s=c3po header.b=T6i6sFPj; dmarc=pass (policy=reject) header.from=tilda.center; spf=pass (mx1.freebsd.org: domain of meka@tilda.center designates 108.61.164.129 as permitted sender) smtp.mailfrom=meka@tilda.center X-Spamd-Result: default: False [-5.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[tilda.center:s=c3po]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; HAS_ATTACHMENT(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[tilda.center:+]; DMARC_POLICY_ALLOW(-0.50)[tilda.center,reject]; NEURAL_HAM_SHORT(-0.93)[-0.928]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.62)[subject]; ASN(0.00)[asn:20473, ipnet:108.61.164.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --w3bc75zt3ylmwpnx Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2022 at 02:45:17PM +0200, Ronald Klop wrote: > Hi, >=20 > First. I'm not an IPv6 expert. Got it running at home. Although with SLAA= C, not DHCP yet. > Another disclaimer is that I use VNET-jails nowadays. > But I like to try and think along with you. >=20 > What surprises me is that your non-vnet jail does not have a LINKLOCAL fe= 80::: address. These addresses are used for configuration in the local netw= ork (AFAIK). > And your routing table does not contain a line like this: > ff02::/16 ::1 UGRS = lo0 >=20 > So how is the ff02:: multicast routed in your network? >=20 > But the tcpdump shows that the multicast solicit message is received on t= he non-vnet dhcp-server so that seems to work: > 18:02:51.229813 IP6 fe80::2a0:98ff:fe7d:cad.dhcpv6-client > ff02::1:2.dhc= pv6-server: dhcp6 solicit > I don't know if the dhcp-server program also sees this request coming in = on its interface. Maybe extra logging can help there. >=20 > According to https://en.wikipedia.org/wiki/DHCPv6#Example the dhcp-server= would reply with a link-local fe80:: address. > "Server replies with an advertise from [fe80::0011:22ff:fe33:5566]:547 to= [fe80::aabb:ccff:fedd:eeff]:546." > But your dhcp-server does not have an fe80::. >=20 > So I'm wondering how that would work. >=20 > More questions than answers. But I hope it helps. >=20 > Regards, > Ronald. Hello, It helps narrow down the search! I created a small lab and this is jail.conf: path =3D "/usr/jails/${name}"; exec.start =3D "/bin/sh /etc/rc"; exec.stop =3D "/bin/sh /etc/rc.shutdown"; exec.clean; mount.devfs; dhcp { host.hostname =3D dhcp.hal9000.meka.rs; host.domainname =3D hal9000.meka.rs; ip4.addr =3D 'bridge0|172.16.0.250'; ip6.addr =3D 'bridge0|fd10:6c79:8ae5:8b91::3'; ip6.addr +=3D 'bridge0|fe80::dead:beef'; enforce_statfs =3D 1;=20 sysvshm =3D new; sysvsem =3D new; devfs_ruleset =3D 7; allow.chflags; allow.mount.devfs; allow.mount.procfs; allow.mount; allow.mount.devfs; allow.mount.procfs; allow.mount.nullfs; allow.mount.tmpfs; allow.socket_af; allow.raw_sockets; persist; } client { $id =3D 10; host.hostname =3D client.hal9000.meka.rs; host.domainname =3D hal9000.meka.rs; enforce_statfs =3D 1;=20 sysvshm =3D new; sysvsem =3D new; devfs_ruleset =3D 8; allow.chflags; allow.mount.devfs; allow.mount.procfs; allow.mount; allow.mount.devfs; allow.mount.procfs; allow.mount.nullfs; allow.mount.tmpfs; allow.socket_af; allow.raw_sockets; persist; vnet; vnet.interface =3D "epair${id}b"; exec.prestart =3D "ifconfig epair${id} create up"; exec.prestart +=3D "ifconfig epair${id}a up descr vnet-${name}"; exec.prestart +=3D "ifconfig bridge0 addm epair${id}a up"; exec.prestop =3D "ifconfig epair${id}b -vnet ${name}"; exec.poststop =3D "ifconfig bridge00 deletem epair${id}a"; exec.poststop +=3D "ifconfig epair${id}a destroy"; } Note the "dead:beef" address. Even if I remove that line I get the same output of ifconfig inside dhcp jail: ifconfig re0: flags=3D8843 metric 0 mtu 1500 options=3D8209b ether bc:ae:c5:e1:31:d0 media: Ethernet autoselect (1000baseT ) status: active nd6 options=3D23 lo0: flags=3D8049 metric 0 mtu 16384 options=3D680003 groups: lo nd6 options=3D21 bridge0: flags=3D8843 metric 0 mtu = 1500 description: re0 ether 58:9c:fc:10:ff:90 inet 172.16.0.250 netmask 0xffffffff broadcast 172.16.0.250 inet6 fd10:6c79:8ae5:8b91::3 prefixlen 128 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: epair10a flags=3D143 ifmaxaddr 0 port 5 priority 128 path cost 2000 groups: bridge nd6 options=3D21 pflog0: flags=3D141 metric 0 mtu 33160 groups: pflog epair10a: flags=3D8943 metr= ic 0 mtu 1500 description: vnet-client options=3D8 ether 02:82:6f:d8:f0:0a groups: epair media: Ethernet 10Gbase-T (10Gbase-T ) status: active nd6 options=3D29 And this is relevant portion of /etc/rc.conf: cloned_interfaces=3D"bridge0" ifconfig_bridge0=3D"inet 172.16.0.254 netmask 255.255.255.0 description re0" ifconfig_bridge0_ipv6=3D"inet6 -ifdisabled auto_linklocal fd10:6c79:8ae5:8b= 91::1" The following is ifconfig on host re0: flags=3D8843 metric 0 mtu 1500 options=3D8209b ether bc:ae:c5:e1:31:d0 inet6 fe80::beae:c5ff:fee1:31d0%re0 prefixlen 64 scopeid 0x1 inet6 2001:470:1f1a:ae:beae:c5ff:fee1:31d0 prefixlen 64 autoconf inet 192.168.111.3 netmask 0xffffff00 broadcast 192.168.111.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=3D23 lo0: flags=3D8049 metric 0 mtu 16384 options=3D680003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=3D21 bridge0: flags=3D8843 metric 0 mtu = 1500 description: re0 ether 58:9c:fc:10:ff:90 inet 172.16.0.254 netmask 0xffffff00 broadcast 172.16.0.255 inet 172.16.0.250 netmask 0xffffffff broadcast 172.16.0.250 inet6 fe80::5a9c:fcff:fe10:ff90%bridge0 prefixlen 64 scopeid 0x3 inet6 fd10:6c79:8ae5:8b91::1 prefixlen 64 inet6 fd10:6c79:8ae5:8b91::3 prefixlen 128 inet6 fe80::dead:beef%bridge0 prefixlen 128 scopeid 0x3 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: epair10a flags=3D143 ifmaxaddr 0 port 5 priority 128 path cost 2000 groups: bridge nd6 options=3D21 pflog0: flags=3D141 metric 0 mtu 33160 groups: pflog epair10a: flags=3D8943 metr= ic 0 mtu 1500 description: vnet-client options=3D8 ether 02:82:6f:d8:f0:0a groups: epair media: Ethernet 10Gbase-T (10Gbase-T ) status: active nd6 options=3D29 I can see "dead:beef" address until I stop the dhcp jail. I can also see that auto_linklocal produced fe80 address (the first inet6 address) on the host but not inside the jail. Is there something I need to configure/start on the host or jail to have link-local address inside non-vnet jail? Regards, meka --w3bc75zt3ylmwpnx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE1WIFkXy2ZeMKjjKEWj1TknovrLYFAmJF7PUACgkQWj1Tknov rLZ/3g/+JX6r+awHoSVBVcqV8V6N/n8inxh3X1LIUBIEUMoAYcTob6uL/jLxcxKp RIHv+pK5riT9BpCpoTJPHTElHRp/Ju9Y2o7M2hzJoDwS1SstpfTWrtsk2EVzXThF mrvTKHmer6REU3c85Zr2I4UpLXasNdT+Zzo3aOflLcJvh5iliVgNBnHvvTL2LQir o76XBqTrm7dpHlAFBIqzTuEN4lZD8IdqFYOpLdbO/bATudKybZ1jNOHpyD+j3QvU ZN2T+D392x351BlrxhAah9bCb+d+F7v51UAN8xtsuNLEOuAteNT1/QCEEme+cetb TG9XnWG31k7Vtj8pOa1+WzQ3l/iBCfHP/1FsROyUINszOdAJhUo21udlAKZofMP8 vXUz0uD0JYUlyClH/gOtGal7tin5Q1h8xlCZAMf/rfxabpQglA4yoCzeiDaw0aJT KJCSBEc8mVp5xec2NDUZSW3L4H805755scr48XB8vEqQCYw49w9GPLvAzqO0L8Dq rqv4e6oXohmMMt69d/wsGpK/6lLUGbxwHDEjCjxeAypgIMuPDfj7jqd8jtAk6+MI pl4uZ3N4J11Opr60a35M1MkA7NVngL4eBuolXhsVV1zmjgNx7WOiaolsYcVJqdVE MYh6TvEHn97qsKyUX8UdrXf3CUX/JxoltUtgJ4clwk1iVCtOvCc= =YRyO -----END PGP SIGNATURE----- --w3bc75zt3ylmwpnx-- From nobody Fri Apr 1 00:15:02 2022 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 0385F1A4755C; Fri, 1 Apr 2022 00:15:09 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KV0zw6Sfpz3M7D; Fri, 1 Apr 2022 00:15:08 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648772108; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=pybIDdmOsMtgDNh9ZbK6eF5mIDBmhGsNFIr2U/2/bp0=; b=Er2uu5382n+z5fzgxt5EjfEfHbAmDjPfnM+JsX/SLNxFpzdp97FjZXdkKT+6OXGiu/JRef fp/zepOtXK3Z5wPkvhHt5Bbl0kvOkptjPMpbwUFe+2xoLBKxbMomn9jqc7j39Og84TL5uD 1EJTbk90ib/brPKCz2LOsMA09YHdcuMxs+qu1y4L4cy2n66fb1ScVwiJ/jajZAvSGxbAuK /mxjSfkKDiPc8TGsNaEElI7t6eQR4B21vqD2Vqeo1neft3fqT/MX7BjTUCIIBMkrtGcSxQ BdvD6ROhzBGpoDUtDNBuyU9szlECR68WAM+IeOnQ6UFWRLFlvcpD0reWk72SWw== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 7DC0ABC58; Fri, 1 Apr 2022 00:15:08 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 1 Apr 2022 00:15:02 +0000 From: Glen Barber To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Cc: FreeBSD Developers Subject: Considering stepping down from all of my FreeBSD responsibilities Message-ID: <20220401001502.GI13797@FreeBSD.org> Reply-To: gjb@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OmxNZ+k2SuGb8jfc" Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648772108; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=pybIDdmOsMtgDNh9ZbK6eF5mIDBmhGsNFIr2U/2/bp0=; b=C8N30phgjmoG5U0M3WJBRZQzzL5A2QMOqgoKKffYSxW3k5gmwUoBOWdVtAqH/xvA/E2WQO phyqAHhgv0iPw80xtoW0QbMSOp93xH0q2DmmTwTTOyPCJrQwoKObF+jfhB2aMWyNbwLR2+ DGgu+71y9x31ZTyt2o7bz3SproUSVf/EQqy71nVOVyeT4RjGOTsgfqv8I35PT6OLTxvawf VMSlEzdl96gpCJ+4bJyj+6hVLLU5PqzyDwZPelgIX+uKRi8pAPxWSRSec+lOxjwT6L2ktY nM9K6+qm5B3g8/XvKQ2+5kgYKcQamDmgsunpE++XirJDd3FzPgmC61PYxQh0Yw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648772108; a=rsa-sha256; cv=none; b=duaRrlVxONQwGs6HeS0kJGBuRWI+Ojc6BhDE8XPiznkVvXrB6UyW73BrJXRTWouJYCnBeU 9/yKIkTaMIioPdMj+GesfNFT1FhsxyvPlE8Ce4ur2Yz0d+ke8ktcxBuw9sFUf2aqD9UU9C 1Z4baQkIprnlCnjXvlFxQd1tvH40iHgNIV53YjAPmmIW3zreNypTH0lP3KGQkXhXDCBEiD wEqlRMNRMQvIOpOg4rOgxD6pqefItUNKzU7ptck32jtj8+97fQ5T224chupZltqEhkEqVU KRP8RQ/KCbu4FaAuswyTPSwfjwcUZ2mvKyTEItDD5EWnvLAjWL+ON5Yx0Ol/Rg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --OmxNZ+k2SuGb8jfc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear community, Given the mental toll the past two years or so have taken on me, I have decided to step down from all of my "hats" within the Project, and take some time to sort out what my future looks like going forward. Happy April 1st. I'm not going anywhere. :-) Glen --OmxNZ+k2SuGb8jfc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmJGRAAACgkQAxRYpUeP 4pNkXg//XVHkojhggTe8b+/rQ+esMV6uVHgBBniQYDuljoz8Q0wao4LlJ02EdDXZ zizjFeVsXZZJQDmTL+U5o8hHwY8ucC/z8Y1V/vIXRxvkunQACO8ABFKDfhVptDRJ bjRP8r2Y1T4h3qmC4CObE08PN7yb6BjXoCODSA2/rnffGRXHjkNa12V0wVJQLSu7 kla4ug43zPESL3mtLna2gn63NK8Fhu6uPvLz74Gjwju2xVbsN8P3EczVKVrLWf7W g9nCyZkaH7KhE7VvPNRVOnQhoFgkCCz9fw7u+8reaP/XKTMWLpgSaaA9Miq7nA64 tYRY58LWLeamVOdXyD11AVCJPC6TGrPqeH+nqsOzfIyUTJy+scXdZWkDr4yzz+p+ p0JxGPp+l+WKPPuAInOhcbIXE6O0Rdi88MA2N9q9b06LJFItjXLKMzXLamfb0PkZ ba1q+oP2u802igncD6unmw/YO9XGquYPZ/OsUzsOZhgAuwnEC6NC23Pf79oLqrnL TEZpHjiWR0VxrFlk2JED3fmbvdLiO3WEc76WtOVKoj4RxAlLsufjH3wMd3buW3vK plnYUtdUeuH3PJIBtX75rc/3ag9hIBkjJgjxjphglyOw+JwHtkIGOdhBbvO5pWlr sRCDXzGL/jEX+Mz5AcGXmeCXt+cLq/FwDv7vGDIp751pVqG4beI= =FMTZ -----END PGP SIGNATURE----- --OmxNZ+k2SuGb8jfc-- From nobody Fri Apr 1 00:18:16 2022 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 8A24C1A491DC; Fri, 1 Apr 2022 00:19:32 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor.nl2k.ab.ca (doctor.nl2k.ab.ca [204.209.81.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 4KV14z62ymz3PMs; Fri, 1 Apr 2022 00:19:31 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor by doctor.nl2k.ab.ca with local (Exim 4.95 (FreeBSD)) (envelope-from ) id 1na4zY-000GgA-O1; Thu, 31 Mar 2022 18:18:16 -0600 Date: Thu, 31 Mar 2022 18:18:16 -0600 From: The Doctor To: Glen Barber Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, FreeBSD Developers Subject: Re: Considering stepping down from all of my FreeBSD responsibilities Message-ID: References: <20220401001502.GI13797@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: <20220401001502.GI13797@FreeBSD.org> X-Rspamd-Queue-Id: 4KV14z62ymz3PMs X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=quarantine) header.from=nl2k.ab.ca; spf=pass (mx1.freebsd.org: domain of doctor@doctor.nl2k.ab.ca designates 204.209.81.1 as permitted sender) smtp.mailfrom=doctor@doctor.nl2k.ab.ca X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[nl2k.ab.ca,quarantine]; MLMMJ_DEST(0.00)[freebsd-stable,freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6171, ipnet:204.209.81.0/24, country:CA]; INTRODUCTION(2.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 01, 2022 at 12:15:02AM +0000, Glen Barber wrote: > Dear community, > > Given the mental toll the past two years or so have taken on me, I have > decided to step down from all of my "hats" within the Project, and take > some time to sort out what my future looks like going forward. > > Happy April 1st. I'm not going anywhere. :-) > Now for Linux and M$ to be a bad April Fools' joke. > Glen > -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Truth is the only progress. -unknown Beware https://mindspring.com From nobody Fri Apr 1 00:21:51 2022 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 AA2A51A4AD36; Fri, 1 Apr 2022 00:21:57 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KV17n4Qn3z3Qss; Fri, 1 Apr 2022 00:21:57 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648772517; 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=SG/cp1PQKiXqTvJGQEdZuwAbDv0nSlNqOSVRQsHV26A=; b=X2EVo5xLSfAlMuTzKlDPqVdle3YjfzttW+r2XUAhLxQyqdTbUfwYl6l4E8KEktzjKo7TiU +O7bSgIm1FL3AoYjt4rRyN2FDYqhxffo9R6SlfWG+Q/r/VVowbIHojjTzU3uXO7jUyV6ME R4Iy3oQUCT1HYlp+KNoTV9e6CKR9QjpnSk+UbN3KK6lV6UduC09w919Tn5vye8zDzGnD6Y 1rbR0wN9bzvt/l7yPUQT7O4wyy2bvFp46dabpExO+2cgqspHCHck3sLWZaWYTbNjXbkHBl EqLl+r5XCefwubfyDeIWPx59uGleQ1YeynRYJBDGx9H2gM13UJr9iIRtzeTsww== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 0F15ABF25; Fri, 1 Apr 2022 00:21:57 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 1 Apr 2022 00:21:51 +0000 From: Glen Barber To: The Doctor Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Considering stepping down from all of my FreeBSD responsibilities Message-ID: <20220401002151.GJ13797@FreeBSD.org> References: <20220401001502.GI13797@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7GuUjB7uchZRuW63" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648772517; 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=SG/cp1PQKiXqTvJGQEdZuwAbDv0nSlNqOSVRQsHV26A=; b=RgJ8NVZQ7YhvszzBQ+aOB86iflEgVGsNEc0/OFGAFGPINqfuwUsmTuVF/8a+Thuoermh+h VfsXM31xjNSTEWpOwh7lbsJgFtqyX8xve3IDvqhz22B2MKgvvCGd8BeiQMFOGcDCbkGN9z IBulXgn1SCe0E3mVKQ4W2x2uzvwF4q37bZfMdRd48s6J1TgrVUNo1ErlAkRLNXtgC8FmER eo8UvyyuNkvHP3kPdtLolGcAqpJnuFLIM51Hwo8pr4oh8IbJCrdVu2MG8XuYqBhkM4bmYJ oBXUPaD1SsAVy3sQJE1ZvaWQHRY2HVScAbmYmY+MkCmkIJ3vEumhCjUaceSslQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648772517; a=rsa-sha256; cv=none; b=U1mDqJxbq5hQhZVXz930CdeDMlv40i7y8OjjToOf8qYCCvxejCyDPC7HkiDj1zdiCsWQXg xgB+sXq63/npLpyShSlfJSbWxBiCwZ7QRcPBq/rONLCgmyhqmNG86efNRs2Ry7ZYvO0LCf eZ5poTPhaBWcisSAmp5zBmLNlcoMoxaP5G7m4Ekv9FBsw4kSSNO/Q35QLCzJLXmXKgEOu2 VPVRvL1qTq/l4gFSKiSqe6ICKkU84xmZfeltGH49sI2gPzsPqEITPtqvfPoxN37mzj7Fsg ervoy3SYL7D8GkCoqeA81W0oHsw2jDfquluDMpXp0C68z5CKyFA8bBhJYig6Tg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --7GuUjB7uchZRuW63 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2022 at 06:18:16PM -0600, The Doctor wrote: > On Fri, Apr 01, 2022 at 12:15:02AM +0000, Glen Barber wrote: > > Dear community, > >=20 > > Given the mental toll the past two years or so have taken on me, I have > > decided to step down from all of my "hats" within the Project, and take > > some time to sort out what my future looks like going forward. > >=20 > > Happy April 1st. I'm not going anywhere. :-) > > >=20 > Now for Linux and M$ to be a bad April Fools' joke. >=20 Damn, I did not think of that... :-) Glen --7GuUjB7uchZRuW63 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmJGRZ8ACgkQAxRYpUeP 4pP6nA/9HcS/A7Xjrt43p9NkhWd7YBYtSzVandDdo7X0FJKhvhokrYHePvrZ5Y/m VBVR+QELjBCObuvrnz+MprufvW1PtrpUp2ISwo0Hi8uUPyvoVLJl3Ogmfwab/1FQ n8WV92fcxTYI1sgswr1+oZdxLDwIz5Xlri+GHB2S/hNEl+thEXTqK5NX7PgIZi+B 526iwvfH4hwkURmnitYqx8M7ZJX9UFtG7i04/sT9mH9Rpq4SIIzO5NhuypPE7wEs Gvfb1X1yswHXJjANyqLjujK4WOgWKrpjpykAoVoTOji8lypVKGjAHF9eBr7k1Skk qbHZ79JpxiiTauLZ+2dVzhBjlu2+2b0qaggDqCDVXuObOxDpV/2jsxE4speHj3HC tg9zugZigkCK1uhyizdxMrceQOFMdwOWmUTbASrv+hjTNmUalKbmI6oYETvLEgmn POWTO8hVfOB4ci3nYSUU65lypA/O1Ew1jpG+oPvhYLxtF4rx3u/qpg5oLmVDv/vH DNOLhzwnWcjrmsvrVlAyc1HUIgkWg6FSEWb4z4rkcSf5q5VUcDIm5t/yqZpI1UcP celfA5SB1SG5M3Yh0sfZQe/S1V/7oKgdX24N7R73+xXp7JMcc/A9wxFmcJO+HtDD NzSHemA814UmIRlB0L+hyB66uoM+NMMCiNiaoPBH1ESnfKYmqnM= =h+f8 -----END PGP SIGNATURE----- --7GuUjB7uchZRuW63-- From nobody Fri Apr 1 05:20:31 2022 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 1A8661A5543F; Fri, 1 Apr 2022 05:21:42 +0000 (UTC) (envelope-from yasu@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KV7nd74XNz3rFB; Fri, 1 Apr 2022 05:21:41 +0000 (UTC) (envelope-from yasu@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648790502; 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=U9oE7kkig3BivTPeKU4dHXTGWW5b1MC1qdjYdc1xGcc=; b=gIyvmOveBdsRLOSb2wSR9xgLsqULDs8GCeLP/9cCjB4ICQi3uZF0MpzurKJp7U308MPDDl qT5kxMJShyN6hLF9k75S0vyK7cMsuE2O2keR0RZFuZ4skCr2OUbEiPrYaVFGLzrHiiLDqQ gXKxVlNMAUTJFc4Cd8oXEKd5X7RDMuqQD7T0LKd4Ap5py49hOltKvzGioP5jD7vupVXnCT gu4vmtgZdxm60dzvC8XUXqoXMnvte5Tw8mt2jNYr2XZqm/reOVgI1YZD1KBhIMxow+d4aS JPG//D0e/JNvTnEfLPIrznPKObmGillXG7U8fFRplAibSOfbm9Ki7EfUjOLuXA== Received: from localhost (unknown [IPv6:240b:11:220:fe00:212e:95d0:4e32:3a0f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: yasu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id B40392BC20; Fri, 1 Apr 2022 05:21:40 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Date: Fri, 01 Apr 2022 14:20:31 +0900 (JST) Message-Id: <20220401.142031.2286040474128292357.yasu@FreeBSD.org> To: gjb@freebsd.org Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: Considering stepping down from all of my FreeBSD responsibilities From: Yasuhiro Kimura In-Reply-To: <20220401001502.GI13797@FreeBSD.org> References: <20220401001502.GI13797@FreeBSD.org> X-Mailer: Mew version 6.8 on Emacs 29.0.50 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648790502; 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=U9oE7kkig3BivTPeKU4dHXTGWW5b1MC1qdjYdc1xGcc=; b=uy8Su7UnZ2PYD9o9z90AJlp4yTnBCh38J6jC9HDPp7ZsVSNA5XaIzVuPeT7pJUyr1zfcBN hY8OZvO7s0Zlqly8O9awBFNk+FknusBvDK5r+Fs3D4QJQnCejEo++j4QJ/tJgwMFLnxo0K d+4GcPdOROzEstQtf8DeP+TeTgRWXHzAaBi7KwoeGJNEnKHhaCrthhPvimHEHdJ/3ExVoS KyAu9bLMz5GcQwB1c4zyAvEq56461pDCItf8/jDB6vpfGPkswr7k+p5IIRX/+mP8WanSOU /2wxntQBPgv0NMlZRrOYg9nA1O1YmGsFdcBFIPn6SHwZwieJBpOuCscMZjeX3Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648790502; a=rsa-sha256; cv=none; b=Cvx72UyTCv08GekFvU7wKQ160ugGZo9udoSHCvYk6a0G9oT5vun72hklOemhk7bjk1x/1i QO8vqvMiHzM7zAEJzkpW/J6+JgP/JDA0nxBOTM+EQ6lAQ4pl6MKtcEwVoZRlwivdYIl2xx C1WmqZL1mJjrZVptEZoO/sQD+9fegD0BVMCjf/7ss+19pdCTQvCWsBmKnUwN/71qMdC8i5 FwpKETF+qYjKCFInztsUGKfCFznf6D5oBe//4FhL+d7FiTSUni0ENtKWDTCuifjxGzguiE wZ/YjTNpbY39o9j7AW8JPxMT92VVvgLsGhQqR8Cg0j7jvkK1hO9WorQfgkOw4w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hi Glen, From: Glen Barber Subject: Considering stepping down from all of my FreeBSD responsibilities Date: Fri, 1 Apr 2022 00:15:02 +0000 > Dear community, > > Given the mental toll the past two years or so have taken on me, I have > decided to step down from all of my "hats" within the Project, and take > some time to sort out what my future looks like going forward. > > Happy April 1st. I'm not going anywhere. :-) > > Glen We are waiting for the announce of FreeBSD 2.2.10-RELEASE. :-) Cf. https://lists.freebsd.org/pipermail/freebsd-announce/2006-April/001055.html --- Yasuhiro Kimura From nobody Fri Apr 1 05:58:39 2022 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 4A7271A5EF9E; Fri, 1 Apr 2022 05:58:40 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KV8cJ1jNfz4V3B; Fri, 1 Apr 2022 05:58:40 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648792720; 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=iH+Sq+VV5jXiG7O4ecrlSwwCmGnoXDg8drWC2g3HHNg=; b=BgwiQT3TNzFDJhtSDfLSmP7JMOam4KDD8DiLsFNBGSm49yQKYYCkaxgC67UpkpDwbjDE+Q WDfdtFYSZroOi5AoYnsGW4s9Y/l5IueW/V3RLbsFYrE8zLQTtiDlvwrDHTTJFatF3EnWIr bD7lQhwZarVZlsolhbt7EWyIuN80CNd4XtVsWvZN9dtFcrH5J5TnNHNVV4dvfcJhrMMELa iIgNP2irp0KBepzJBUtunFWYcseukfcY4McuNel0rxfEBoqrjzFtwP1BRNMJEryDO7AYzx Ap3TgGDTYhgv8Bl0+xbAe7TNSu/mnxB3FDbIVSWSgY/wiSEnsOfDtBu7JrzYMA== Received: by freefall.freebsd.org (Postfix, from userid 1033) id 10947DE1A; Fri, 1 Apr 2022 05:58:40 +0000 (UTC) Date: Fri, 1 Apr 2022 05:58:39 +0000 From: Alexey Dokuchaev To: Yasuhiro Kimura Cc: gjb@freebsd.org, freebsd-stable@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: Considering stepping down from all of my FreeBSD responsibilities Message-ID: References: <20220401001502.GI13797@FreeBSD.org> <20220401.142031.2286040474128292357.yasu@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: <20220401.142031.2286040474128292357.yasu@FreeBSD.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648792720; 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=iH+Sq+VV5jXiG7O4ecrlSwwCmGnoXDg8drWC2g3HHNg=; b=R3yW3BCMv/OR/9cxKtVy4HB0Mw3zLgaGKCyHBrjRv2s6GhmwKh+6SNMSZREtm4SzX2eU1k 9xZeGA/ot0Dprf1MmqD8V32kHQP+KIMzWOwlU/t99F7+6L6//NfkltG8u3HMMx7tnX6BSa 9DH0ImYPMm8JMU3mS/2SovD/Kt+R5JCwS8ovOBzwczUv8ZxbkjICzFgMKBq8M4Lv8W/5TR G11AQA/PXrudfEoLfny7cKd5taLYtzly0w1kpWL4fzr19Zz/9UUvyK5aO5ZgQSp6jbVgvb 3QsUMb/c6QZ+tO+71HwH4mfhE+WoMVDYOIUJc9u8IgtZpfXLv7DU7SqmFiOn/w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648792720; a=rsa-sha256; cv=none; b=Qrt5S1veV8EE+i6DZcab4/8oiU0UisqIxmyFGWPn1aHlLHk1qL+COtYnyXf1GvYWwYM4Vu 81R0Usz5p4V6wknFGIA74QNwG6/q2uaf5ELA4wLSc7cZvooV2fmt3aCMVXJbfW5vms9rDu D5RfZr+sqG+FzPfxTRgUtxAEJIlDnQR0a5oR5tdPSQl3+oKFvAfImOK3OQXaQrYj82SBen VtVad4Ldx2DRp5qFEbzkVSqcBuTYt5dCZqQYMldU9twLiuIyoNmm0T8K4Ym2Kt+z7iVSwe tW+1eB4TEJ90Tn8NmCiAKK267yx805IGAj1+iCB+eh64onlarqPZOcLNG2pd4g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 01, 2022 at 02:20:31PM +0900, Yasuhiro Kimura wrote: > Hi Glen, > > From: Glen Barber > Subject: Considering stepping down from all of my FreeBSD responsibilities > Date: Fri, 1 Apr 2022 00:15:02 +0000 > > > Dear community, > > > > Given the mental toll the past two years or so have taken on me, I have > > decided to step down from all of my "hats" within the Project, and take > > some time to sort out what my future looks like going forward. > > > > Happy April 1st. I'm not going anywhere. :-) > > We are waiting for the announce of FreeBSD 2.2.10-RELEASE. :-) > > Cf. https://lists.freebsd.org/pipermail/freebsd-announce/2006-April/001055.html I don't think 2.2.10 is warranted. 2.2.9 (or was it 2.2.8?) had improved Quake II support in Linuxolator, but since then we've got several native ports available in our collection which play just fine (modulo the problems caused by that shitty linuxish graphics stack we're confined to these days). ./danfe From nobody Fri Apr 1 06:48:16 2022 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 BA92F1A427F9; Fri, 1 Apr 2022 06:48:19 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4KV9jZ5tvSz4dGS; Fri, 1 Apr 2022 06:48:18 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253]) by lax.lemis.com (Postfix) with ESMTP id 87E9428114; Fri, 1 Apr 2022 06:48:17 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id C44652635C0; Fri, 1 Apr 2022 17:48:16 +1100 (AEDT) Date: Fri, 1 Apr 2022 17:48:16 +1100 From: Greg 'groggy' Lehey To: Alexey Dokuchaev Cc: Yasuhiro Kimura , gjb@freebsd.org, freebsd-stable@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: Considering stepping down from all of my FreeBSD responsibilities Message-ID: <20220401064816.GS60301@eureka.lemis.com> References: <20220401001502.GI13797@FreeBSD.org> <20220401.142031.2286040474128292357.yasu@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TSQPSNmi3T91JED+" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: https://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4KV9jZ5tvSz4dGS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of grog@lemis.com designates 45.32.70.18 as permitted sender) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [-3.91 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a:www.lemis.com]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[6]; HAS_ORG_HEADER(0.00)[]; NEURAL_SPAM_SHORT(0.09)[0.088]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; RCVD_NO_TLS_LAST(0.10)[]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --TSQPSNmi3T91JED+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 1 April 2022 at 5:58:39 +0000, Alexey Dokuchaev wrote: > On Fri, Apr 01, 2022 at 02:20:31PM +0900, Yasuhiro Kimura wrote: >> Hi Glen, >> >> From: Glen Barber >> Subject: Considering stepping down from all of my FreeBSD responsibilities >> Date: Fri, 1 Apr 2022 00:15:02 +0000 >> >>> Dear community, >>> >>> Given the mental toll the past two years or so have taken on me, I have >>> decided to step down from all of my "hats" within the Project, and take >>> some time to sort out what my future looks like going forward. >>> >>> Happy April 1st. I'm not going anywhere. :-) >> >> We are waiting for the announce of FreeBSD 2.2.10-RELEASE. :-) >> >> Cf. https://lists.freebsd.org/pipermail/freebsd-announce/2006-April/001055.html > > I don't think 2.2.10 is warranted. Agreed. The upgrade isn't sufficiently important. How about 2.2.9.1? Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php --TSQPSNmi3T91JED+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAmJGoDAACgkQIubykFB6QiNUgQCfRQvC3cJRYeZgtWggfgrntrCe pjwAnjioicWCGXMFIytE+t7/KCI2pK6C =vTqS -----END PGP SIGNATURE----- --TSQPSNmi3T91JED+-- From nobody Fri Apr 1 12:00:35 2022 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 0527919F9256; Fri, 1 Apr 2022 12:01:08 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVJfV5zRfz3vkj; Fri, 1 Apr 2022 12:01:06 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p508d4362.dip0.t-ipconnect.de [80.141.67.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id D4A4523E57; Fri, 1 Apr 2022 14:00:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1648814457; 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=vrZoto60ohjowkXyPGD+Cwv2G6ow+lqUe5Mb+PWLwak=; b=OV3++RhrAAje37ojtcN2EcWzLCD2ncl+biSG59/y8clnW9sbckTqeP+SGDRM8P0+6A9Plx dy4qlcNc3WrterVXOGqD/TaAfmmFh+oxx2bxc7OHzjKcAz2KSN2ydqNH3pWl7B0g6no349 Cydnc2ohr3wDPniTGg4FU4OhHTHX1YFgkO5blukcMrLss08bW+8L1YuG58Cppm+AAsNHe1 hKO/4XFanUJgl2hkbO6APoSZxsDUBFkb5bAsH76RfZdwT99MLa9QwJe3QN9McRmWown3s3 SgIejZc5cgZ/zygiZkIJN50a4/HcaVzbLo3NmxkVPBliOED1N5P59yJ6omrgZA== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 729E6C680; Fri, 1 Apr 2022 14:00:38 +0200 (CEST) Date: Fri, 01 Apr 2022 14:00:35 +0200 Message-ID: <20220401140035.Horde.LYLAkhpBnQPotxJtLawHfO8@webmail.leidinger.net> From: Alexander Leidinger To: current@freebsd.org, jail@freebsd.org Subject: injecting vars into rc-service-scripts at jail-start? Accept-Language: de,en Content-Type: multipart/signed; boundary="=_OFj-_eOqdGFBDWtOYkHfhOt"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4KVJfV5zRfz3vkj X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=OV3++Rhr; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-5.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current,jail]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[80.141.67.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_OFj-_eOqdGFBDWtOYkHfhOt Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm overlooking something fundamental it seems... Context: I'm working on my auto-jailing of services idea: if the auto-jail is=20=20 enabled,=20a service like syslog is started inside a jail (which=20=20 inherits=20the FS and depending on some settings also inherits network=20= =20 and=20other stuff or not). My previous implementation was using _rc_prefix (jailstart) to denote=20=20 the=20start of a service inside a jail so that "service XXX start" on a=20= =20 host=20would "service XXX jailstart" inside a jail. This had off course=20= =20 issues=20as there is no infrastructure for multiple prefix like=20=20 onejailstart=20or jailonestart... Problem: Now I try to find a way to do it without a prefix, and the first thing=20= =20 which=20comes to my mind is to do "jail xxx 'exec.start=3D/usr/bin/env=20= =20 _rc_svcs=3Djailing /usr/bin/service XXX CMD ARGS'". My expectation is, that this would set _rc_svcs=3Djailing for the=20=20 command=20service XXX CMND args. Having a "set -x" in rc.subr shows=20=20 clearly=20in the jail-console log, that inside that jail, the variable=20= =20 _rc_svcj=20is not set. Using "-v" for the env command shows in the log=20= =20 that=20it is called and it sets the var and executes the service command=20= =20 with=20syslog start as arguments. I tried to find some env-cleanup part in rc.subr, which would discard=20=20 all=20_rc* variables, but if there is something like that I overlooked it. For a stop, I call "jexec /usr/bin/env _rc_svcj=3Djailing=20=20 /usr/sbin/service=20XXX stop args", and it works, so I rather tend to=20=20 believe=20there is no env-cleanup. What am I doing wrong so that _rc_svcj is not picked up inside the jail? So here is my diff between "prefix driven" (=3D working) and "var=20=20 driven"=20(var not picked up inside the jail): ---snip--- case "$rc_arg" in start) - if [ "${_rc_prefix}" !=3D jail ]; t= hen + if [ "${_rc_svcj}" !=3D jailing ]; = then _return=3D1 $JAIL_CMD -c=20=20 $_svcj_generic_params=20$_svcj_cmd_options \ -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 exec.start=3D"/usr/sbin/service ${name} jailstart $rc_extra_args" \ -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 exec.stop=3D"/usr/sbin/service ${name} jailstop $rc_extra_args" \ +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 exec.start=3D"/usr/bin/env _rc_svcj=3Djailing /usr/sbin/service ${name}=20= =20 ${rc_arg}=20$rc_extra_args" \ +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 exec.stop=3D"/usr/bin/env _rc_svcj=3Djailing /usr/sbin/service ${name}=20= =20 ${rc_arg}=20$rc_extra_args" \ =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 exec.consolelog=3D"/var/log/svcj_${name}_console.log" \ name=3Dsvcj-${name}=20= =20 &&=20_return=3D0 else # normal start of=20= =20 _cmd=20via _run_rc_doit ---snip--- What set -x tells what it calls: ---snip--- + /usr/sbin/jail -c 'path=3D/' mount.nodevfs 'host=3Dinherit'=20=20 'ip4=3Dinherit' 'ip6=3Dinherit' allow.reserved_ports=20=20 'exec.start=3D/usr/bin/env -v _rc_svcj=3Djailing /usr/sbin/service -v=20=20 syslogd=20start ' 'exec.stop=3D/usr/bin/env _rc_svcj=3Djailing=20=20 /usr/sbin/service=20syslogd start '=20=20 'exec.consolelog=3D/var/log/svcj_syslogd_console.log' 'name=3Dsvcj-syslogd' ---snip--- Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_OFj-_eOqdGFBDWtOYkHfhOt Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJG6WIACgkQEg2wmwP4 2IbsvRAAqMPhMXAr4CVQULA0/Xt61LneIcNV2PkkPVXoUL/aJA2hC2OVFZXq0Wwf wnz6CuA3Dw50AJjUCfNySSkl4nCP4tGSiHaDu2iBZFiE3b4EehtPoqgpDghNJJ7M bj9+ZkSTCZs+RrUyS3A+tD5Ib7ugWN1absvJ35srEvLfviR05YDD7j2aIinWC/8D 7wWlYXYZLN2CAubuueuHZ1g+1HAJtPWlGA1vLJGgAtdT6Bp07SbCtTJB2GMYLvq4 XzAnDLXhWB31GPMQrscPzBqyTBqQ/xz4YCBSECP7l88Zv7oshu4R23jJEY1jhKe0 8elCzOKCK53pScT3iS6jMVQrsLfuv8sSLgVEVxa48oaqyNcBfKK74ircaCAHakKY NlG6main9TcO49lQVYidWcvZc1UHkgRsHy3yJucgUHoa+GH7KWvXEJoAmG4KlLHv DKl6jHPoS6amH79NITwFWQiXz34LjpxT/KqpKqnoIJ+sEq/GmcAmL2kuPoErG1NO hLlQMB3+3mB/nLHJW38Z8UBt8OQIl+8pXowr4b44lLKznom6zFIIARPpgd0VQ+z5 DEXDtqLgOM7ILwT3iiaeAMUwYNjQT31NnIWstAvdiK6iyoV1Xdga9N6062x7iX80 4NSQqXs9+VjUH3v8qegAhzcQl4UYxb4fTtgn5LS5O2BP+uL8Kf0= =fEbf -----END PGP SIGNATURE----- --=_OFj-_eOqdGFBDWtOYkHfhOt-- From nobody Fri Apr 1 12:26:27 2022 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 7EB9A1A38FC3; Fri, 1 Apr 2022 12:26:36 +0000 (UTC) (envelope-from schweikh@schweikhardt.net) Received: from ikarus.efm.de (ikarus.efm.de [195.190.148.243]) (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 4KVKCv5hD5z4VgH; Fri, 1 Apr 2022 12:26:35 +0000 (UTC) (envelope-from schweikh@schweikhardt.net) Received: from ikarus.efm.de (localhost [127.0.0.1]) by ikarus.efm.de (Postfix) with ESMTPS id CDB9529C0C0C; Fri, 1 Apr 2022 14:26:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ikarus.efm.de (Postfix) with ESMTP id BFA6029C19BA; Fri, 1 Apr 2022 14:26:27 +0200 (CEST) Received: from ikarus.efm.de ([127.0.0.1]) by localhost (ikarus.efm.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id K5hgA-gbfaVh; Fri, 1 Apr 2022 14:26:27 +0200 (CEST) Received: from ikarus.efm.de (ikarus.efm.de [195.190.148.243]) by ikarus.efm.de (Postfix) with ESMTP id 9F6AC29C0C0C; Fri, 1 Apr 2022 14:26:27 +0200 (CEST) Date: Fri, 1 Apr 2022 14:26:27 +0200 (CEST) From: Jens Schweikhardt To: Alexander Leidinger Cc: current@freebsd.org, jail@freebsd.org Message-ID: <2063721701.9653898.1648815987577.JavaMail.zimbra@schweikhardt.net> In-Reply-To: <20220401140035.Horde.LYLAkhpBnQPotxJtLawHfO8@webmail.leidinger.net> References: <20220401140035.Horde.LYLAkhpBnQPotxJtLawHfO8@webmail.leidinger.net> Subject: Re: injecting vars into rc-service-scripts at jail-start? 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: 7bit X-Mailer: Zimbra 8.8.15_GA_4203 (ZimbraWebClient - FF98 ([unknown])/8.8.15_GA_4232) Thread-Topic: injecting vars into rc-service-scripts at jail-start? Thread-Index: ftwRUKy4c6dRX2hwHkCgZQaENU7qeQ== X-Rspamd-Queue-Id: 4KVKCv5hD5z4VgH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of schweikh@schweikhardt.net has no SPF policy when checking 195.190.148.243) smtp.mailfrom=schweikh@schweikhardt.net X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FREEFALL_USER(0.00)[schweikh]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[schweikhardt.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.40)[195.190.148.243:received,195.190.148.243:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current,jail]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25411, ipnet:195.190.148.0/24, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Identifier confusion? You use _rc_svcs and _rc_svcj in your description. Jens From nobody Fri Apr 1 12:52:57 2022 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 9AF1F1A41284 for ; Fri, 1 Apr 2022 12:53:15 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVKpf4MR1z4dJ7 for ; Fri, 1 Apr 2022 12:53:14 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 3227C10A32F3 for ; Fri, 1 Apr 2022 14:53:06 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 7E93610A32F4 for ; Fri, 1 Apr 2022 14:53:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1648817584; 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=VGd6/X3JXP7XKUqqKn4XdA1dnhHVtDJLMN2yZXcxBl0=; b=S7Dlh5dcdGLwTnuFaUMBlLLEa91MMGpAHDB021V4NHVlXwwaUhMf++1o3DWbf3G2fQxQ4w D9qZ4ntFoZPxfLuZDcSeSdX96WFH+5f17GUGIGq290L/u93R0dHppyNPhIg4natTBizqr9 eAoEzCAavksul0ADNBOuuhnr18vw0pFo7Rot/DkfykDyWIdKb9H73UcbVKquzQOrtcZXj3 2e1f1XdtGa2cjXiGSF6+9csoIfKltUgXxfZjHTT8leqUw1uTp658llivHSSj9RCsUq2D1v 6J00Bern5SXj6XZBPI8xGAk1G/gnKckL1ZhLQCcbtmUoLFRhW4EMEuj3NvX6FQ== Received: from freyja (p5de88571.dip0.t-ipconnect.de [93.232.133.113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 497E410A1E85 for ; Fri, 1 Apr 2022 14:53:04 +0200 (CEST) Date: Fri, 1 Apr 2022 14:52:57 +0200 From: FreeBSD User To: freebsd-current Subject: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error Message-ID: <20220401145257.7317e887@freyja> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: e32763 X-Rspamd-UID: a4160b X-Rspamd-Queue-Id: 4KVKpf4MR1z4dJ7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=S7Dlh5dc; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt-de.de]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[93.232.133.113:received] X-ThisMailContainsUnwantedMimeParts: N On 14.0-CURRENT #134 main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 2022 amd64, it is without any problem possible to build most recent 13-STABLE sources as of today (stable/13-n250195-26e8bb3a4e1). On 14.0-CURRENT #18 main-n254160-4fc5a607fdf: Fri Apr 1 08:30:10 CEST 2022 amd64 this is not possible anymore, the build process dies with the error shown below: [...] >>> Install check world -------------------------------------------------------------- mkdir -p /tmp/install.l1zhrZWFwP progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp date echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm sed services_mkdb sh sort strip sysctl test true uname wc zic tzsetup makewhatis; do if progpath=`env PATH=/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/usr/sbin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/usr/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/usr/sbin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/usr/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/bin:/pool/sources/13-STABLE/obj/pool/sources/13-STABLE/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin which $prog`; then echo $progpath; else echo "Required tool $prog not found in PATH ($PATH)." >&2; exit 1; fi; done); if [ -z "" ] ; then libs=$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do set -- $line; if [ "$2 $3" != "not found" ]; then echo $2; else echo "Required library $1 not found." >&2; exit 1; fi; done); fi; cp $libs $progs /tmp/install.l1zhrZWFwP cp: [vdso]: No such file or directory *** Error code 1 Stop. make[5]: stopped in /pool/sources/13-STABLE/src *** Error code 1 From nobody Fri Apr 1 13:10:25 2022 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 330031A464B3; Fri, 1 Apr 2022 13:10:49 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVLBw2Vqtz4j42; Fri, 1 Apr 2022 13:10:48 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p508d4362.dip0.t-ipconnect.de [80.141.67.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 9EB6C23FD4; Fri, 1 Apr 2022 15:10:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1648818644; 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=31kyP7b/PGIhQZ92TPyDRRkzV3TSEBc0KT8wNxnPGP4=; b=Fz3PshCxjveHYKpHV0Zh2Rpuk3qBLWdntSjliyPDgLDENws0alGttfP4aWAL0Xegbo7NRx bmSByd58ccpsLzpyYNA8HthZJoAj5Ht7m4QQBwyYuA4tMLIhs5TVnacLzx3EC0lYcYIR9d WjyAE6fLO2YUzhgQYR/2/faPSqBY/87YDZMXHbVcZgB8uETK1ElH4M31byc62fal+eXtJS jV5EYoaB8ZL469NDjKyM/VjPJOFLf/VaHfVvoWJNGBJUCUUrbe1PkOQDbPTsMGwXfZgds6 +8/h95kQ3P4NcqVlGW5ykl/t3ojhqF4Ymuxpph1uU0griZgOoASIpsRtzigPCQ== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 5896AC282; Fri, 1 Apr 2022 15:10:26 +0200 (CEST) Date: Fri, 01 Apr 2022 15:10:25 +0200 Message-ID: <20220401151025.Horde.1Q8TGYwGtnEqeSARyDAkxSB@webmail.leidinger.net> From: Alexander Leidinger To: Jens Schweikhardt Cc: current@freebsd.org, jail@freebsd.org Subject: Re: injecting vars into rc-service-scripts at jail-start? References: <20220401140035.Horde.LYLAkhpBnQPotxJtLawHfO8@webmail.leidinger.net> <2063721701.9653898.1648815987577.JavaMail.zimbra@schweikhardt.net> In-Reply-To: <2063721701.9653898.1648815987577.JavaMail.zimbra@schweikhardt.net> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_y2mTEICHMU0zESw1Ibqzhqd"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4KVLBw2Vqtz4j42 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=Fz3PshCx; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-5.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current,jail]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[80.141.67.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_y2mTEICHMU0zESw1Ibqzhqd Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Jens Schweikhardt (from Fri, 1 Apr=20= =20 2022=2014:26:27 +0200 (CEST)): > Identifier confusion? You use _rc_svcs and _rc_svcj in your description. Typo.... s/svcs/svcj/ in the explanation. The diff/code has the vars correct (svcj) and the conditional and the=20=20 setting=20are close to each other and are "_rc_svcj". Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_y2mTEICHMU0zESw1Ibqzhqd Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJG+cEACgkQEg2wmwP4 2IZrvQ//R383L/qHZ0C+FcZ08WlafMyLGqSy1Qn4IeeWdmmXqeudgNPzpIkkevFh wpEMz10dMltpcd1yF3a9ayqXvXlbfZhqrpOzoiHpdSkzSZMQTFP/7MNWw7Or0izi m/OaRj/GW/Wsog5V4AMCEujZQ0LMPcWjV9quLW9Ct1JFizIXb54ydjFx+Ix9Pk2c 6lDsAtkh27RMqMp2TuJbWN8VG+1YSn71mEKyE2y7rdGiAx9h2zfcL9OMDr/r1fXR YAUPyguDz06mcQe5yYwP8t0h+YmP86qqeR1bIBoSKtjysOHaaSRRBtl4NkMFu/vQ 3dz6gWHwTKb7rF7LmM9roVM1PJZ8bjkYYSgptEaAhxHN37jX4AGCuhMKObNYaV/j uhd6XwnrIBfNsf2zSlLX5hkF8S+BLBxQjJS0ivuzRAH0icXFN5LAPf4bgaR1Qsgj MZscy9lPJgDIwcoDFMvrF/1IVh/12dfPENFC528kKW+dYnM+NcR+rKJ01prAdieN SAJvTkFwyaNF22VcFkY40MwuQiVA+m6zwZK22z9qLG1quYtzNR2Lfj3RRkSsZ53C Tg/1+FcbMhlWabXE17YeATMM+BSpZ35QKk9Np9tu8UDzR9R/05DvliqX61zwIFrs RDmHWAR3BL//sAPbV0toM4lhInE80DiMMb2gY2yjKd4WkInc2dw= =vw5a -----END PGP SIGNATURE----- --=_y2mTEICHMU0zESw1Ibqzhqd-- From nobody Fri Apr 1 13:50:31 2022 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 4EA321A38F02 for ; Fri, 1 Apr 2022 13:50:51 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVM564RqPz4qSn for ; Fri, 1 Apr 2022 13:50:50 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f54.google.com with SMTP id z7so3248317iom.1 for ; Fri, 01 Apr 2022 06:50:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6iFtZKS6qtV4enm7u/rDtRVheP+iDPwQZ6fN9VaWQF4=; b=zJfxs0KQc3uon4Ol9WSfwTZE9H2rR6SdZ9QUQKqx/EtbPxgpMoplGbjCcUPED8soSX gHLaTTpJR8eb4v3hMbBJx13c/uv8x+0d615YHrJEAfAyRSuzTIaI6FW7IY2qga8Pycfx 88HvdwPd1SeRAkX9GQg0yKGFpi4n4SR6PmIApKiQJxakl/SbUIYF3BKx9yPWhc+zWkNg Sf0bwK8OSH6Xzh0hT7WNGbdsjg/qpyfQP28N1fxdcn189CVAbehSHDmRxmZZMxaQ3SBS c+eQrBWejA2cHZwHzqHMuz8NPbGJI3SuDuk2D5T/IhmY1M0x0hXU3Fz2CjHTKHLYwu54 NDpA== X-Gm-Message-State: AOAM533/QFtMe/m2nkz3WKEY0e13sgD0mFX8s2E5BztofpSerYiDpr0Q n6m5VKMq5WR/wDeSXRMuwUCaLsqSuowtNihVMP2Uu7OQbks= X-Google-Smtp-Source: ABdhPJz44f50dHl+DXp28gU4yEIYqwDvT0IkR0RTWuENAJlcfz8n+CNLLg92kUYUINMP0jQmvStd8c7mckhIruUAKQo= X-Received: by 2002:a5e:924c:0:b0:646:390e:ce1b with SMTP id z12-20020a5e924c000000b00646390ece1bmr16916822iop.142.1648821043697; Fri, 01 Apr 2022 06:50:43 -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: <20220401145257.7317e887@freyja> In-Reply-To: <20220401145257.7317e887@freyja> From: Ed Maste Date: Fri, 1 Apr 2022 09:50:31 -0400 Message-ID: Subject: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error To: FreeBSD User Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KVM564RqPz4qSn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.54 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.94 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.96)[-0.961]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.987]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.54:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.54:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 1 Apr 2022 at 08:54, FreeBSD User wrote: > > On 14.0-CURRENT #134 main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 2022 > amd64, it is without any problem possible to build most recent 13-STABLE > sources as of today (stable/13-n250195-26e8bb3a4e1). > > On 14.0-CURRENT #18 main-n254160-4fc5a607fdf: Fri Apr 1 08:30:10 CEST 2022 > amd64 this is not possible anymore Could you give this patch a try? diff --git a/Makefile.inc1 b/Makefile.inc1 index c91034ed42fe..bd58f48a64d2 100644 --- a/Makefile.inc1 +++ b/Makefile.inc1 @@ -1366,6 +1366,9 @@ distributeworld installworld stageworld: _installcheck_world .PHONY libs=$$(ldd -f "%o %p\n" -f "%o %p\n" $$progs 2>/dev/null | sort -u | \ while read line; do \ set -- $$line; \ + if [ "$$1" = "[preloaded]"; then \ + break; \ + fi \ if [ "$$2 $$3" != "not found" ]; then \ echo $$2; \ else \ From nobody Fri Apr 1 14:00:10 2022 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 3F0F31A3BAB8 for ; Fri, 1 Apr 2022 14:00:13 +0000 (UTC) (envelope-from schweikh@schweikhardt.net) Received: from ikarus.efm.de (ikarus.efm.de [195.190.148.243]) (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 4KVMHw4rkHz4sWn; Fri, 1 Apr 2022 14:00:12 +0000 (UTC) (envelope-from schweikh@schweikhardt.net) Received: from ikarus.efm.de (localhost [127.0.0.1]) by ikarus.efm.de (Postfix) with ESMTPS id A579F29C08AB; Fri, 1 Apr 2022 16:00:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ikarus.efm.de (Postfix) with ESMTP id 97C5C29C19BA; Fri, 1 Apr 2022 16:00:10 +0200 (CEST) Received: from ikarus.efm.de ([127.0.0.1]) by localhost (ikarus.efm.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UbaQq-waAdSA; Fri, 1 Apr 2022 16:00:10 +0200 (CEST) Received: from ikarus.efm.de (ikarus.efm.de [195.190.148.243]) by ikarus.efm.de (Postfix) with ESMTP id 64F7E29C08AB; Fri, 1 Apr 2022 16:00:10 +0200 (CEST) Date: Fri, 1 Apr 2022 16:00:10 +0200 (CEST) From: Jens Schweikhardt To: Ed Maste Cc: FreeBSD User , freebsd-current Message-ID: <829437267.9678947.1648821610373.JavaMail.zimbra@schweikhardt.net> In-Reply-To: References: <20220401145257.7317e887@freyja> Subject: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error 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-Mailer: Zimbra 8.8.15_GA_4203 (ZimbraWebClient - FF98 ([unknown])/8.8.15_GA_4232) Thread-Topic: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error Thread-Index: c/YKTb+NTGeXErG+ZLp6BAWRiwe2WQ== X-Rspamd-Queue-Id: 4KVMHw4rkHz4sWn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of schweikh@schweikhardt.net has no SPF policy when checking 195.190.148.243) smtp.mailfrom=schweikh@schweikhardt.net X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_FIVE(0.00)[5]; FREEFALL_USER(0.00)[schweikh]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[schweikhardt.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.40)[195.190.148.243:received,195.190.148.243:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25411, ipnet:195.190.148.0/24, country:DE]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello *, Looks like a semicolon is missing after the "fi". Jens ----- Urspr=C3=BCngliche Mail ----- Von: "Ed Maste" An: "FreeBSD User" CC: "freebsd-current" Gesendet: Freitag, 1. April 2022 15:50:31 Betreff: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such fi= le or directory *** Error On Fri, 1 Apr 2022 at 08:54, FreeBSD User wrote: > > On 14.0-CURRENT #134 main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 20= 22 > amd64, it is without any problem possible to build most recent 13-STABLE > sources as of today (stable/13-n250195-26e8bb3a4e1). > > On 14.0-CURRENT #18 main-n254160-4fc5a607fdf: Fri Apr 1 08:30:10 CEST 20= 22 > amd64 this is not possible anymore Could you give this patch a try? diff --git a/Makefile.inc1 b/Makefile.inc1 index c91034ed42fe..bd58f48a64d2 100644 --- a/Makefile.inc1 +++ b/Makefile.inc1 @@ -1366,6 +1366,9 @@ distributeworld installworld stageworld: _installcheck_world .PHONY libs=3D$$(ldd -f "%o %p\n" -f "%o %p\n" $$progs 2>/dev/null | sort -u | \ while read line; do \ set -- $$line; \ + if [ "$$1" =3D "[preloaded]"; then \ + break; \ + fi \ if [ "$$2 $$3" !=3D "not found" ]; then \ echo $$2; \ else \ From nobody Fri Apr 1 14:08:11 2022 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 62AD51A3F199 for ; Fri, 1 Apr 2022 14:08:31 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVMTV3jq5z4vpK for ; Fri, 1 Apr 2022 14:08:30 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f53.google.com with SMTP id 9so3279104iou.5 for ; Fri, 01 Apr 2022 07:08:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ee0d5CN9KVe0SH4XIAGN3p2N2zR9922PvTIdEIS5eS4=; b=zNQm88michf2ZHszkSax5rNXxjkz2ImTLIA3Jy8jQFWY0gDZ9ZQkkkcJgF+aH/0XYg tB868Kl0gbtVZ5K4JhYPBzL4W3NVr2bR4S0FR36HMfjV6H5zLXZ4JklHDlmTF2hZpEln d+wT51nLq4XJc/SifjR1mgat93LXTd/a/BqItnX8ehz5LoTF5rUzFuk70eqDKMk5Beu2 hWqmKhm9bkXRmVVg4T9FeGvjx90p+9Y1ds+xWBXMeOCQMQNuvNt0Mv6r9pb34QRlibZf iKkjia9DHbNFnz5r/XhCu2+fUwuTHEq6SnDHLF6YvneP04ff9JhRBd5lrpVSbm6Tbq0M vpBQ== X-Gm-Message-State: AOAM531zZ+aS71eKSuIYUREtXWB8fYA/ncujdVNyLHHDsOkXvCd6r9FZ R+KPQH94/qdf0BkRKETM+w1zjkJXmJSGWUnuafTfGHjiwWw= X-Google-Smtp-Source: ABdhPJwsUJsNZ+QSJ1/hAlTkQHXYQ1rJQ5NlMVtQ2tFHld2K4d0FHFnrejFL+Jv7RiJKK17kZfA1f3ddoUageD/eAF8= X-Received: by 2002:a05:6638:2182:b0:323:a610:3eaf with SMTP id s2-20020a056638218200b00323a6103eafmr4947883jaj.204.1648822103702; Fri, 01 Apr 2022 07:08:23 -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: <20220401145257.7317e887@freyja> <829437267.9678947.1648821610373.JavaMail.zimbra@schweikhardt.net> In-Reply-To: <829437267.9678947.1648821610373.JavaMail.zimbra@schweikhardt.net> From: Ed Maste Date: Fri, 1 Apr 2022 10:08:11 -0400 Message-ID: Subject: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error To: Jens Schweikhardt Cc: FreeBSD User , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KVMTV3jq5z4vpK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.53 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(0.66)[0.663]; NEURAL_HAM_LONG(-0.97)[-0.971]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.53:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.53:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 1 Apr 2022 at 10:00, Jens Schweikhardt wrote: > > Hello *, > Looks like a semicolon is missing after the "fi". Indeed, and there was a close bracket missing as well. I've put a (hopefully) fixed version in review at https://reviews.freebsd.org/D34734. From nobody Fri Apr 1 15:11:41 2022 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 657AB1A4ED99 for ; Fri, 1 Apr 2022 15:12:15 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVNv22tmTz3Ngt; Fri, 1 Apr 2022 15:12:14 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id C018410A1EAD; Fri, 1 Apr 2022 17:12:11 +0200 (CEST) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 1B1A210A1E85; Fri, 1 Apr 2022 17:12:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1648825930; 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=OjhUqnKOLYtcXJzMLyhAbnKymddKw364SfGxVzhX1Cc=; b=C+ym3xRvxC8ULUptFnbyJ+bGLKXyioC+vi84jP6eP747rjO5P3t1LVM0/wQZTrp/NfTKIL nIfpWn/7RutfbzZ+swW+6ELq0RVcL7h5g8kVBy/hVbL4Vf8y03RW6rLCUp9bj9o7mzkyUg drvxiwxqos1imWxZcOZd+8hzgJFIaS3Q7JPx39PTozKFJsvqmoHPxtsImmWaLMj33CxB2j oY3wZFHQ79apVKssV7df7YaRu0mXh0q2SCkAAwhJI+zl6gTP4rIZaBljqdYNRGXKnFVf9f T//blN9sPMp9h/9RHwr44dRl0DczNM3GPSkOogNeNqCBgqw2fMLSyuf+n+wfgg== Received: from thor.intern.walstatt.dynvpn.de (dynamic-089-014-104-063.89.14.pool.telefonica.de [89.14.104.63]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id CB6EA10A3306; Fri, 1 Apr 2022 17:12:09 +0200 (CEST) Date: Fri, 1 Apr 2022 17:11:41 +0200 From: FreeBSD User To: Jens Schweikhardt Cc: Ed Maste , freebsd-current Subject: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error Message-ID: <20220401171208.13b711a9@thor.intern.walstatt.dynvpn.de> In-Reply-To: <829437267.9678947.1648821610373.JavaMail.zimbra@schweikhardt.net> References: <20220401145257.7317e887@freyja> <829437267.9678947.1648821610373.JavaMail.zimbra@schweikhardt.net> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-UID: d5b34c X-Rspamd-UID: 4ebf28 X-Rspamd-Queue-Id: 4KVNv22tmTz3Ngt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=C+ym3xRv; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[89.14.104.63:received] X-ThisMailContainsUnwantedMimeParts: N Am Fri, 1 Apr 2022 16:00:10 +0200 (CEST) Jens Schweikhardt schrieb: > Hello *, > Looks like a semicolon is missing after the "fi". > Jens >=20 > ----- Urspr=C3=BCngliche Mail ----- > Von: "Ed Maste" > An: "FreeBSD User" > CC: "freebsd-current" > Gesendet: Freitag, 1. April 2022 15:50:31 > Betreff: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such = file or directory > *** Error >=20 > On Fri, 1 Apr 2022 at 08:54, FreeBSD User wrote: > > > > On 14.0-CURRENT #134 main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET = 2022 > > amd64, it is without any problem possible to build most recent 13-STABLE > > sources as of today (stable/13-n250195-26e8bb3a4e1). > > > > On 14.0-CURRENT #18 main-n254160-4fc5a607fdf: Fri Apr 1 08:30:10 CEST = 2022 > > amd64 this is not possible anymore =20 >=20 > Could you give this patch a try? >=20 > diff --git a/Makefile.inc1 b/Makefile.inc1 > index c91034ed42fe..bd58f48a64d2 100644 > --- a/Makefile.inc1 > +++ b/Makefile.inc1 > @@ -1366,6 +1366,9 @@ distributeworld installworld stageworld: > _installcheck_world .PHONY > libs=3D$$(ldd -f "%o %p\n" -f "%o %p\n" $$progs > 2>/dev/null | sort -u | \ =20 > while read line; do \ > set -- $$line; \ > + if [ "$$1" =3D "[preloaded]"; then \ > + break; \ > + fi \ > if [ "$$2 $$3" !=3D "not found" ]; then \ > echo $$2; \ > else \ >=20 Hello, it is also impossible to installworld - same error. I'm on FreeBSD 14.0-CUR= RENT #134 main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 2022 amd64, sources are u= p to date as of now.=20 It isn't only an issue with crossbuilding another FreeBSD branch. Kind regards, O. Hartmann --=20 O. Hartmann From nobody Fri Apr 1 15:53:37 2022 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 7C3151A57884 for ; Fri, 1 Apr 2022 15:53:47 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVPpx49k4z3mCX for ; Fri, 1 Apr 2022 15:53:45 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Fri, 1 Apr 2022 17:53:37 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1648828417; bh=IYZmkIjYQ/oc6WocmpaqmP/e2q1euoGkvJgglzuQyJk=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=QMqBt6Fr/DJNcOb+otrtLr4KV0r69VikDcdsQySGHdzOxU1AN/ahr6WZAc0/YNfHN HsrPelXINqNyiEe2auRIlNkbWeEixYrqah3S7XMZhJ06CTLI+Ey/FwXRq5jdAb7dNN +JBaITQX3MoCgh92Fwg3tSzAxFAJlmkSpXrm/Hda1T1EbdjI9CAyji6qrLw1dptlWK zROvdH/ScS3VhBACMcnWjNEdL4UwSK9X9SAjgOC/C6M3OqgcdgwUZrqC/odJ4xm97M HQsg9lBLhNdqPzfhTdeBD21YFuw7ZEgG7aBNtI9ySKwwYqbbfuC96l9X+vjyQVUnyo gQmRV/unEvgpg== From: "Herbert J. Skuhra" To: current@freebsd.org Subject: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error Message-ID: References: <20220401145257.7317e887@freyja> <829437267.9678947.1648821610373.JavaMail.zimbra@schweikhardt.net> <20220401171208.13b711a9@thor.intern.walstatt.dynvpn.de> 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: <20220401171208.13b711a9@thor.intern.walstatt.dynvpn.de> X-Rspamd-Queue-Id: 4KVPpx49k4z3mCX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=mail202005 header.b=QMqBt6Fr; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at X-Spamd-Result: default: False [-3.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gojira.at]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[gojira.at:+]; NEURAL_HAM_SHORT(-0.96)[-0.958]; MLMMJ_DEST(0.00)[current]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE] X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 01, 2022 at 05:11:41PM +0200, FreeBSD User wrote: > > Hello, > > it is also impossible to installworld - same error. I'm on FreeBSD 14.0-CURRENT #134 > main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 2022 amd64, sources are up to date as of > now. I think I got this error last time I tried to update a 13.0 jail on main. AFAIR it's caused by a shared version library bump on main. -- Herbert From nobody Fri Apr 1 16:03:42 2022 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 933501A59E8C for ; Fri, 1 Apr 2022 16:04:20 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVQ372x9qz3pBK; Fri, 1 Apr 2022 16:04:19 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id B773410A1E86; Fri, 1 Apr 2022 18:04:12 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id B0CDC10A32F4; Fri, 1 Apr 2022 18:04:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1648829050; 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=P1KEuuqLjLrfKsZ9wbzCqQKjHTeOuMvQrT6L5qKMAWA=; b=QFJK/rxPegN4C2hXyPe1CtKTsLRcD9ebOh+tVxGPmzMZ74RShDDXMgTBNaXbGq+MmRkd+6 UbHqV5FEEdpg8r1qbxKguX/wG/lTKBUWRlXZUVV5kGBSg7d2pM1En1TaP/j6t312UtDabS LxXYNCZZvK5WnKt23mgN6kKO/ilcx/rrE2Szh7b4Zj+R78JQ5NmpjVSV63KOCZwmsX+oKG 4Hpl5LPIkOstGMDN7tFIDmKrTkWxRp7xi4yG/5cS+EBFF9eeDDwdXCMrcEmQPUqY2NnhR3 IemUQfO8PtEitR28ek5I5TQVdqIUokMHI+lOJ26ezAGexjSX+TrZKp0EUq7rGw== Received: from thor.intern.walstatt.dynvpn.de (dynamic-089-014-104-063.89.14.pool.telefonica.de [89.14.104.63]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 6950C10A330F; Fri, 1 Apr 2022 18:04:10 +0200 (CEST) Date: Fri, 1 Apr 2022 18:03:42 +0200 From: FreeBSD User To: Ed Maste Cc: Jens Schweikhardt , freebsd-current Subject: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error Message-ID: <20220401180409.6f4468ae@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20220401145257.7317e887@freyja> <829437267.9678947.1648821610373.JavaMail.zimbra@schweikhardt.net> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: bfc4af X-Rspamd-UID: b31214 X-Rspamd-Queue-Id: 4KVQ372x9qz3pBK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b="QFJK/rxP"; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:30) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-3.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; RECEIVED_SPAMHAUS_PBL(0.00)[89.14.104.63:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from] X-ThisMailContainsUnwantedMimeParts: N Am Fri, 1 Apr 2022 10:08:11 -0400 Ed Maste schrieb: > On Fri, 1 Apr 2022 at 10:00, Jens Schweikhardt > wrote: > > > > Hello *, > > Looks like a semicolon is missing after the "fi". > > Indeed, and there was a close bracket missing as well. I've put a > (hopefully) fixed version in review at > https://reviews.freebsd.org/D34734. > I tried the patch given at the URL above (Phabricator). Patch applied on recent CURRENT and trying to "make installworld" leaves me with this error, see bewlo. What I'm doing weong here? Kind reagrds, O. Hartmann [...] >>> Install check world -------------------------------------------------------------- --- installworld --- mkdir -p /tmp/install.7P7AV5IW4F progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp date echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm sed services_mkdb sh sort strip sysctl test time true uname wc zic tzsetup makewhatis; do if progpath=`env PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin which $prog`; then echo $progpath; else echo "Required tool $prog not found in PATH ($PATH)." >&2; exit 1; fi; done); if [ -z "" ] ; then libs=$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do $line; if [ "$1" = "[preloaded]" || "$1" = "[vdso]" ]; then continue; fi; if [ "$2 $3" != "not found" ]; then echo $2; else echo "Required library $1 not found." >&2; exit 1; fi; done); fi; cp $libs $progs /tmp/install.7P7AV5IW4F [: missing ] sh: [preloaded]: not found [: missing ] sh: [vdso]: not found [: missing ] sh: libc.so.7: not found [: missing ] sh: libcap_fileargs.so.1: not found [: missing ] sh: libcasper.so.1: not found [: missing ] sh: libedit.so.8: not found [: missing ] sh: libformw.so.6: not found [: missing ] sh: libm.so.5: not found [: missing ] sh: libmd.so.6: not found [: missing ] sh: libncursesw.so.9: not found [: missing ] sh: libnv.so.0: not found [: missing ] sh: libprivatebsddialog.so.0: not found [: missing ] sh: libregex.so.1: not found [: missing ] sh: libthr.so.3: not found [: missing ] sh: libtinfow.so.9: not found [: missing ] sh: libutil.so.9: not found [: missing ] sh: libxo.so.0: not found cp: [vdso]: No such file or directory *** [installworld] Error code 1 make[1]: stopped in /usr/src -- O. Hartmann From nobody Fri Apr 1 16:09:21 2022 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 6E7BA1A5AFE2 for ; Fri, 1 Apr 2022 16:09:41 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVQ9J3s46z3qF4 for ; Fri, 1 Apr 2022 16:09:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f52.google.com with SMTP id k25so3692657iok.8 for ; Fri, 01 Apr 2022 09:09:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sV8rrllTKPGR+Urp1fn1T0j4QbK+zidVjmdn5t13RFI=; b=pyIyL3NrY7i/9uW4Zvv4ZuhN05jNK9Kg6f7stvCkFEJnXGclrq27L7G9VdddpsVUIT 68pCAw/c3GZkQEkI6xIV493uIOtRIAPLVpDg/PIWdh/tIcLb9iTYSW22vuU2t0mPJBw5 hZK26JNSpEn8/izmbSBC6tflxmIF28T0u0clIvlyErpJlLWMw5ph3tj0rcpByfh3NX+E d0cd3yMlOVqOYhhOmNzr63rhyIw87p+a/cB6ZLjN0HiXRzmqiPvzREmAQEkIV1qRhB35 NWC9yJtPlvP1VyDd99pFrjeknY4kRLNHZ78yptLqQmz2U6C0jf4MurK5becT5eNTh7yy Xxkg== X-Gm-Message-State: AOAM530/ZMUhj3eAqMiNgSIb6RewwziZZsbuGDlc0b1TyyijwV8Nyctj 12XtkgcP6BaFlSVPlg40RbAs4oFRwm+HDzHl1Hg= X-Google-Smtp-Source: ABdhPJxOwZ4YKOlkiAOxj9ZdiMn+V8MrPNE/apGUMlHqfxYD1ULixD47Yy/b26WB9HBJsue01/fC7lORLA7GH1Tu9Rk= X-Received: by 2002:a05:6638:2182:b0:323:a610:3eaf with SMTP id s2-20020a056638218200b00323a6103eafmr5220712jaj.204.1648829374016; Fri, 01 Apr 2022 09:09:34 -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: <20220401145257.7317e887@freyja> <829437267.9678947.1648821610373.JavaMail.zimbra@schweikhardt.net> <20220401180409.6f4468ae@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20220401180409.6f4468ae@thor.intern.walstatt.dynvpn.de> From: Ed Maste Date: Fri, 1 Apr 2022 12:09:21 -0400 Message-ID: Subject: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error To: FreeBSD User Cc: Jens Schweikhardt , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KVQ9J3s46z3qF4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.98 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-0.98)[-0.984]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.52:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.52:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 1 Apr 2022 at 12:04, FreeBSD User wrote: > > I tried the patch given at the URL above (Phabricator). Patch applied on recent CURRENT and > trying to "make installworld" leaves me with this error, see bewlo. What I'm doing weong here? You're not doing anything wrong, I had another bug in the version of the patch you tried. I've updated Phabricator again, please try again. From nobody Fri Apr 1 16:38:07 2022 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 AC78D1A218A2; Fri, 1 Apr 2022 16:38:11 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVQpC2T6mz3vxF; Fri, 1 Apr 2022 16:38:11 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id aI8VnZcdE43SgaKHqnGMnT; Fri, 01 Apr 2022 16:38:10 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id aKHonSk4D159UaKHpnw9EQ; Fri, 01 Apr 2022 16:38:10 +0000 X-Authority-Analysis: v=2.4 cv=frTP2X0f c=1 sm=1 tr=0 ts=62472a72 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=CgZkTQGOwzZGz1Ui:21 a=kj9zAlcOel0A:10 a=z0gMJWrwH1QA:10 a=VY3jW7vHAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=VXVZ9nYamGOQNGkpEnEA:9 a=CjuIK1q_8ugA:10 a=wvJViTZbw86eNCrzd9Pk:22 a=UKjBECWEfCFPfndWmoCD:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 145A81CB; Fri, 1 Apr 2022 09:38:08 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id EB3D811F; Fri, 1 Apr 2022 09:38:07 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Greg 'groggy' Lehey cc: Alexey Dokuchaev , Yasuhiro Kimura , gjb@freebsd.org, freebsd-stable@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: Considering stepping down from all of my FreeBSD responsibilities In-reply-to: <20220401064816.GS60301@eureka.lemis.com> References: <20220401001502.GI13797@FreeBSD.org> <20220401.142031.2286040474128292357.yasu@FreeBSD.org> <20220401064816.GS60301@eureka.lemis.com> Comments: In-reply-to Greg 'groggy' Lehey message dated "Fri, 01 Apr 2022 17:48:16 +1100." 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 Date: Fri, 01 Apr 2022 09:38:07 -0700 Message-Id: <20220401163807.EB3D811F@slippy.cwsent.com> X-CMAE-Envelope: MS4xfG+YK5+BmKgIL4rXb0luQn+Sk2Es5Bpptp6Z9ddJ2EqmedL6/1na88fAWm4wsL4nvtNBmSD5HyOiYr7HJRoHIIw/u2LZUSQT5awwBfQgECwL0oqL2qBg 6qvctGXsUkiqFa/OYhCIC66iUH73bKbs8fiNwYd3SDyLzO00G6OuP6pxW0TxhgxsCSgQlHxVAcv1mqT/wMvJzqsshOmqFUx63L34xVzpfybfJUe6b2jHVV/C cWe5OHEREMdAbtgvdf7Dn6oMmIiDGTRLRypOQMaCTmJHBya5quDMNBy1w4WvNnn0BWk0OQJd5lbCanmDDmAYQ7kNGnS8WOsjjohce8R5x94YU90iSbJkEcDZ nn73/TiEO9JU7jr2sLlR61fZRdpuNXiDI/XDKv89eq0500kpcyY= X-Rspamd-Queue-Id: 4KVQpC2T6mz3vxF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N In message <20220401064816.GS60301@eureka.lemis.com>, Greg 'groggy' Lehey write s: > > --TSQPSNmi3T91JED+ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Friday, 1 April 2022 at 5:58:39 +0000, Alexey Dokuchaev wrote: > > On Fri, Apr 01, 2022 at 02:20:31PM +0900, Yasuhiro Kimura wrote: > >> Hi Glen, > >> > >> From: Glen Barber > >> Subject: Considering stepping down from all of my FreeBSD responsibilities > >> Date: Fri, 1 Apr 2022 00:15:02 +0000 > >> > >>> Dear community, > >>> > >>> Given the mental toll the past two years or so have taken on me, I have > >>> decided to step down from all of my "hats" within the Project, and take > >>> some time to sort out what my future looks like going forward. > >>> > >>> Happy April 1st. I'm not going anywhere. :-) > >> > >> We are waiting for the announce of FreeBSD 2.2.10-RELEASE. :-) > >> > >> Cf. https://lists.freebsd.org/pipermail/freebsd-announce/2006-April/001055 > .html > > > > I don't think 2.2.10 is warranted. > > Agreed. The upgrade isn't sufficiently important. > > How about 2.2.9.1? I had a different more sinister thought: Announcing that we've moved from BSDL to GPLv3 to be more like Linux. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From nobody Fri Apr 1 16:42:48 2022 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 E25711A240A1; Fri, 1 Apr 2022 16:42:50 +0000 (UTC) (envelope-from jhibbits@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVQvZ5WY7z4T61; Fri, 1 Apr 2022 16:42:50 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648831370; 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=3K7YYo697ahX7mOvKlrl3oYytD1ngHmRkVoagvf4KHI=; b=MEksn40FYeMrUhB3zjJ4Yq+75eKm/pjGh2lyFzhlYVbBmRiracq2m2sI/5pb3wTNke+ohC 4xAfSzYvoB0xcAghtOnVa6JhbeeIsCH0lcpxTG0LVvfL2mEUusdF5zw+Al63cuA6MtUgFQ 425JiPf59l4K1FGRTJn+oanL0oZ5ZSHSy1v9RDty7oNgMqDvZGAW4J+wL9Ey1QUyNcVPug qWeYYTbBlqvRRxyB2dFQg0o18opF6aqVgVDwX9r1Jhc1zmujCcnb2lYN790vSUXJ4KRlAB DVh17YTntaYr1/P1ez5uIQhw0+nicpa24HZGVQEbOSZpGTqL+ol2cNZvjIoAqw== Received: from ralga-linux (unknown [173.18.9.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jhibbits) by smtp.freebsd.org (Postfix) with ESMTPSA id 31A011928; Fri, 1 Apr 2022 16:42:50 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Fri, 1 Apr 2022 11:42:48 -0500 From: Justin Hibbits To: Cy Schubert Cc: Greg 'groggy' Lehey , Alexey Dokuchaev , Yasuhiro Kimura , gjb@freebsd.org, freebsd-stable@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: Considering stepping down from all of my FreeBSD responsibilities Message-ID: <20220401114248.1fb2bae6@ralga-linux> In-Reply-To: <20220401163807.EB3D811F@slippy.cwsent.com> References: <20220401001502.GI13797@FreeBSD.org> <20220401.142031.2286040474128292357.yasu@FreeBSD.org> <20220401064816.GS60301@eureka.lemis.com> <20220401163807.EB3D811F@slippy.cwsent.com> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; powerpc64le-unknown-linux-gnu) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648831370; 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=3K7YYo697ahX7mOvKlrl3oYytD1ngHmRkVoagvf4KHI=; b=d123f1p4oO/vO4in3JI6QF2Vrd7MSVCRpBijnP+OvSmBfmQ3RRpUHgiR8oRi+u+QuulcbH fW7CnduHeQR9xPm5Qg/WTEWjQfYOshJENSmXfFx1847ACmM3RPUlIDm1nS2IbibxzMJGny UuOeRzDYmizyq2sGfKnIvjfML7V08ciE6sOGws76/d22tUEgRXaa3Edac7RmCmqv4r0eli N3n+xkNtltGxyHA/6IW2tOqVRa/MQSpElYhcLcvz0DVtTWGBwoMTzF9xu0bv9vGJqCNrFd Uud96OTSuF3tDjGJBCDbVpIDftU7HPGXtr01KpJqyuDjMDzETcrpbD7GS6h/tg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648831370; a=rsa-sha256; cv=none; b=B/pUEFbWcOue69S8mFpSuC0Vr3Lp1pgcZFe1SfPx56vATYr/p9YlEJLgath/6SZ9P1R6MD 4uaSSCdl3jc4/i2kbXqguPaARkZEhvfiOOZbLSJjUuhgF40pgCPSUGDzw/gqmAJhGEtgn+ UgAHL3hiExyckOEIWc31aJrQ1+l/Q0FPLx79YZqRq1FyvpGRP4BQYD1k0KAWXctfFNJYC2 AYSeorHevSqe7ca/YJveJu6I6WxqG79ZVHhzqP3jSFaXzA+zixMBR6mXyY8DmrBqvPEs2e LLTHkYkwH2zEKQM6SU6OSUIaHabssRJ7Z7jGrpTiS5PHJJIFPPBWHA4l33mU/w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Fri, 01 Apr 2022 09:38:07 -0700 Cy Schubert wrote: > In message <20220401064816.GS60301@eureka.lemis.com>, Greg 'groggy' > Lehey write > s: > > > > --TSQPSNmi3T91JED+ > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > > > On Friday, 1 April 2022 at 5:58:39 +0000, Alexey Dokuchaev wrote: > > > > > On Fri, Apr 01, 2022 at 02:20:31PM +0900, Yasuhiro Kimura wrote: > > >> Hi Glen, > > >> > > >> From: Glen Barber > > >> Subject: Considering stepping down from all of my FreeBSD > > >> responsibilities Date: Fri, 1 Apr 2022 00:15:02 +0000 > > >> > > >>> Dear community, > > >>> > > >>> Given the mental toll the past two years or so have taken on > > >>> me, I have decided to step down from all of my "hats" within > > >>> the Project, and take some time to sort out what my future > > >>> looks like going forward. > > >>> > > >>> Happy April 1st. I'm not going anywhere. :-) > > >> > > >> We are waiting for the announce of FreeBSD 2.2.10-RELEASE. :-) > > >> > > >> Cf. > > >> https://lists.freebsd.org/pipermail/freebsd-announce/2006-April/001055 > > >> > > .html > > > > > > I don't think 2.2.10 is warranted. > > > > Agreed. The upgrade isn't sufficiently important. > > > > How about 2.2.9.1? > > I had a different more sinister thought: Announcing that we've moved > from BSDL to GPLv3 to be more like Linux. > > Take it to the next level. Since we're using git you can make the license change, do the commit, then send the commit email out, and it would have the valid hash and all. - Justin From nobody Fri Apr 1 16:48:48 2022 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 91CBC1A2730D; Fri, 1 Apr 2022 16:48:55 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVR2b3MYVz4XlL; Fri, 1 Apr 2022 16:48:55 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648831735; 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=ylRjaj0N5v+tL85K6B7jN/+LKmgIbJHrCKR2tcvBzvc=; b=xLryiUPOG8nrWW5LTF/BxMrXTeoENXbG7fIcg40Ha/N2/SH9pzaNelLukzqMtssJBmMNaj NP2bLhHJ+ljLAOAxujCs5qeKOTvY8ZtP1qmx8JFznSGRYeR9ZxVbHsw5d1HCjlEWhQTX+p Q3uejrqsijTcAPOFBD4J+w/kzAmOI2dV6xVrfeqSJpjgFGHEVIJAljIe24SgInKKNYDsyw fiYBc7dCDVWoE1QN+BqLRqM7Pq7PvC7IIRJGqO7eNFnBL6YcsDhR36bJ7+m+PI1fZobJmo yP4co/6Ru6XulM6/UNLPn7EQYwUBwLL5GoRhJZqwWQZRM5/+xQPULN4CQ1/E6w== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id CECB2101D0; Fri, 1 Apr 2022 16:48:54 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 1 Apr 2022 16:48:48 +0000 From: Glen Barber To: Justin Hibbits Cc: Cy Schubert , Greg 'groggy' Lehey , Alexey Dokuchaev , Yasuhiro Kimura , freebsd-stable@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: Considering stepping down from all of my FreeBSD responsibilities Message-ID: <20220401164848.GP13797@FreeBSD.org> References: <20220401001502.GI13797@FreeBSD.org> <20220401.142031.2286040474128292357.yasu@FreeBSD.org> <20220401064816.GS60301@eureka.lemis.com> <20220401163807.EB3D811F@slippy.cwsent.com> <20220401114248.1fb2bae6@ralga-linux> 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="Mua2edsUln3Jw4OC" Content-Disposition: inline In-Reply-To: <20220401114248.1fb2bae6@ralga-linux> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648831735; 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=ylRjaj0N5v+tL85K6B7jN/+LKmgIbJHrCKR2tcvBzvc=; b=OwVmIDl9LxervDhe2QxAyUekx6B7Agq4Gz+CG51de0xchx6Fi/8F1aQDJljPpz1FHyho+W 3S4WxobebEhW+zU/lDHaS18YfWmJ6N69R1KrXtAprzIoUXSPkTIXbrzpLJ64lUDe/Xbf2r k+k/0sLRCkmrzh/ZPKHNuZD3CKVFDoGhqJWVwISSsbziK1QDxGabytJuKM2TChAtxWcJNx bsIkjR6cd2GqlawA5fc2G5DAuAoPdjY4XkLAvDMlrb2C00+DcAVuLrX7XIkWz4aQqkonSl caw3zmTUv+eKGMFnlujNVsZIuPR5eDBalVvrpNYKadoYogwPk9rpj28hyj9muw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648831735; a=rsa-sha256; cv=none; b=EFQ0sr70iPDPSbqQy/+ECAB/WnhY5UypnOl48ehkcJCQDg9kY3BIBfnleW6N1yWymzXcVf kuNr8XhJsnCWk5fChURPn3kqZtSn+emWOkLbzKH3qhaXzBbhvy4Hg42nKhm1ass7JzvGKi X83EyCRHK7m1Vz6GaLLWmdf7HvX8/pwH+ymnIHbVep9JdUrxJYZ+49roZO28iunJbXesd1 rqu6Ft2sIXHLS/IFY/owt2INtkDjEPDBrVdJvB8YT6zFSEryvr4w8q4gggCHDRSVXdDXts JjapzFoPXt8yWmSayiNR+yo1n7Jw7lVpR0AHT1MScGlc10d5hRjMd90+z6ssMw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Mua2edsUln3Jw4OC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 01, 2022 at 11:42:48AM -0500, Justin Hibbits wrote: > On Fri, 01 Apr 2022 09:38:07 -0700 > Cy Schubert wrote: >=20 > > In message <20220401064816.GS60301@eureka.lemis.com>, Greg 'groggy' > > Lehey write > > s: > > >=20 > > > --TSQPSNmi3T91JED+ > > > Content-Type: text/plain; charset=3Dus-ascii > > > Content-Disposition: inline > > > > > > On Friday, 1 April 2022 at 5:58:39 +0000, Alexey Dokuchaev wrote: > > > =20 > > > > On Fri, Apr 01, 2022 at 02:20:31PM +0900, Yasuhiro Kimura wrote: = =20 > > > >> Hi Glen, > > > >> > > > >> From: Glen Barber > > > >> Subject: Considering stepping down from all of my FreeBSD > > > >> responsibilities Date: Fri, 1 Apr 2022 00:15:02 +0000 > > > >> =20 > > > >>> Dear community, > > > >>> > > > >>> Given the mental toll the past two years or so have taken on > > > >>> me, I have decided to step down from all of my "hats" within > > > >>> the Project, and take some time to sort out what my future > > > >>> looks like going forward. > > > >>> > > > >>> Happy April 1st. I'm not going anywhere. :-) =20 > > > >> > > > >> We are waiting for the announce of FreeBSD 2.2.10-RELEASE. :-) > > > >> > > > >> Cf. > > > >> https://lists.freebsd.org/pipermail/freebsd-announce/2006-April/00= 1055 > > > >> =20 > > > .html =20 > > > > > > > > I don't think 2.2.10 is warranted. =20 > > > > > > Agreed. The upgrade isn't sufficiently important. > > > > > > How about 2.2.9.1? =20 > >=20 > > I had a different more sinister thought: Announcing that we've moved > > from BSDL to GPLv3 to be more like Linux. > >=20 > >=20 >=20 > Take it to the next level. Since we're using git you can make the > license change, do the commit, then send the commit email out, and it > would have the valid hash and all. >=20 I was so very close to doing something similar, but I was more worried about screwing up my local trees. Glen --Mua2edsUln3Jw4OC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmJHLOoACgkQAxRYpUeP 4pP2bA/9HI73z19qq1mv29JyMQuJRaSHesxSeS+dNJmNrpKC1KDsSSPrwfVyYnt2 7bXdXa8+Zx35pHSIyAV+oR7YPLDi1tfiN2NeFb8ECMa+V63XXYxP5j+3n4EJnKvY a39yEW1ZtQdO9gWYjWQmk5dnUUBY2cmW6Po3g4t3VpbqKw68oRRVlaLSBCDGDAmx 0TpAUZopPe9jyLixjqDz0t3fDFzVklmw48fuWdU3lgXhoIZ4N26M6gsgt8IfQ5Ut Lm0GnLNCSQvVMHuSl4VLWErMPFFI7QaBxZVgWKw6K1PcGW9mtGR2jLejB3F+aOci 28Z0+nsYL3rsX1jxBrVSMvfhdGC378oJFY+LEq+Aq9fnWNq6bpw/NTw1xlyrmg64 S3OQKy4NKgbL2xX5V82gFAX25h7JinRNebUQ8VmJZvanJH3TSl7O+pfu2Gr+FLJA s2ZUb1dqzy04kch0VtS03HgNNRWCb5rltnIgqcvAB9BQ/m4SLJcOW0kPkUpYQ7T4 9WqoMYmHjnvluYayhsd/5RCQs1Zt8sFWN234sMCKrnp7l8SHU7VmeIu+PGMYetfN yhnZ9OgmzB0P9+OtXmZvwy/PTWUrpDnGN1ym3XziBIQTb5UpdVJqWcXZ3GXmNhs0 PnELX5Rc7ajb9zW/d6t/aRFfxGSXu4HDulPwZ5+0QoMF9OqjlCQ= =IhnJ -----END PGP SIGNATURE----- --Mua2edsUln3Jw4OC-- From nobody Fri Apr 1 17:01:37 2022 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 C6FB71A4484F; Fri, 1 Apr 2022 17:01:44 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVRKN2p0Jz4fHD; Fri, 1 Apr 2022 17:01:44 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648832504; 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=YI1WxI/D2MZjqkJ+jIMfl9KR/heDEnGMXZI37zh+iUA=; b=jJmVbbJrmVfBBGKzKp+Hu+KdrnvDrJMpPQLRa/YqB2WxruhYxwNP+pTg0T4itlbw9Rl98l vLH4pH3ylnmGnIcOIf2ObDUgi9hK/5Dlzjvk2L0rTcObczm9FNq7YyCfM95A/aL2uEavBm hm4Wz8lHKruhUk7Rk9kFkrBjSUU87rcvhHWe/2IjtM31gH1y1Dh3ndxr37QDbl6EmgsMqS xk8kEZEg3QiaIUvBIVyyHdC/AyZYTn+3v3W3YJxLGJ6SjgcVxnKoPop4DZnN92GnPwtqRo +QCKNwMJ4WLVAoCpU+b+0pfJFOZdDkf0cBR2pKekbqOIyyYXNa2QwINCbuX5wQ== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id B2DCE101FC; Fri, 1 Apr 2022 17:01:43 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 1 Apr 2022 17:01:37 +0000 From: Glen Barber To: "Patrick M. Hausen" Cc: Cy Schubert , Greg 'groggy' Lehey , Alexey Dokuchaev , Yasuhiro Kimura , freebsd-stable@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: Considering stepping down from all of my FreeBSD responsibilities Message-ID: <20220401170137.GQ13797@FreeBSD.org> References: <20220401001502.GI13797@FreeBSD.org> <20220401.142031.2286040474128292357.yasu@FreeBSD.org> <20220401064816.GS60301@eureka.lemis.com> <20220401163807.EB3D811F@slippy.cwsent.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KxOeEu8Cag6KFZma" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648832504; 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=YI1WxI/D2MZjqkJ+jIMfl9KR/heDEnGMXZI37zh+iUA=; b=Gmw3WQSZ+RIZHB1nPAjB3rm/PbXiCtUhIyOPgUtjGvjTrMrb/SRpmIFFbU3UmwHc4MwXds 2R1DHGJd+JznfU/F9Bcztm80Wd8K98OKag9/Uhh9OY6CV2U3grfULaq0KtR0qK8p1QrNGH iB6ElKAnvbYmF3qpHDTJiFLljNx4dBMPxwwvjyd4MYpoCWsi6OKmw5JQtVD3t8zj8w6kai NgnDRgiw+yzYM9VO3lr3A09VG79pofFjdwEwQrzwDCp6ENrtTs2shMdYbZ89uiZGyBOE6v 7apdUxAjI+YbQZJA1gZwWdbLmFhI+wDwg/pspJKWefL8//eSYWO9bP+z+mjOxQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648832504; a=rsa-sha256; cv=none; b=AnXbu3ZubtIdKm6+QqfYBQWaUx+MZiscJyMoP+TkxXhXgJXhAqDVGlqFcQk6y7m6uTU+FW SiwGCAx3eyqAWhQastneC0xR0smZPlZWfgLbEoepzVqrhAL4PaKt3OAt2d9vL3xBysHu5k cDFK4DYDPKTEc3IB52ONTgEXwXZSufqFzj1f1tJZX3K1TVVza1gCJgdRFNpVZD3IZzd3Y9 4bnu3vtgZTzc1bFgD6xAQTn800eyFv5JQommNXdpPg1dnt8d3p7I0cCc5LASYkyBGpg/ON ZxHx/9hQFZUUzdt3+D7AR8TEMgiLcLV5sihf+JpkXiIPiXB6g20cGAvOpTXX3w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --KxOeEu8Cag6KFZma Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 01, 2022 at 06:56:27PM +0200, Patrick M. Hausen wrote: > Hi all, >=20 > > Am 01.04.2022 um 18:38 schrieb Cy Schubert : > > I had a different more sinister thought: Announcing that we've moved fr= om=20 > > BSDL to GPLv3 to be more like Linux. >=20 > Don't we need explicit consent from every contributor for such a major li= cense change? > Shouldn't we start over from 1.1.5.1 in that case to keep the number of p= eople lower? >=20 You're joking, right? If so, amusing. If not, check the date... Glen --KxOeEu8Cag6KFZma Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmJHL/EACgkQAxRYpUeP 4pOQ4g//aYcirf3Q6Tzt/kh0qPAf/Lob4oz5OChA96ZNxoLdZzJLTHj9cx6TDkOp aK9nM7qL3cXKbAZct67XYfeVpg46eItNSycJo8m4ZArwz+0diWMlrP9+KLIm28gs EoPj6l4iFNbK5ZrcHtLsknFM41FCUhGYILZm9EPu4bGueOmZs8PR+2Qm9bTETogO S7KcfhrC7zZyt7X4RwGXe7KZhhWWu21p5Mt93ur1JMPtvpSjJ2dVlQiH+kqHURLi VGFIPVG2u0zrsPmmfFWmGkj65yknVRU8GnCjGCIaZt3l+hOfjM2083jd2j395nFY hpxC12cAlPNdcd5UkAqb06z5F6mBMa9XpxX3kkt4OniE7O2yDbZoeCnU9tYGmuDb rfJoEJoxs0CanC6oHxBPjhddT6AHKz0536N0vFHh2hr4/fs5FcCLW1rmiJAczGSp KsAp4ts5t1aR5J0SQwdyGNJA/SSygvghvuH130usr3wIotvLZ+ocPuw/6I5FmC0t KnZOT7bUjMq4tvtSNUXFA8VY6iN3ku+tLm2Yl57PGLFK1OsyGTGHZIi6rG3dTnZx NIvek5mZvKmrL32qw7Kgp742uIMSMk1ba6XtqMoSiuMgbvUILHlW1EF/mT/NWUU0 NHQ+aGnOSLaaNGkYbZ6hpGqvWIfd4BzQVea1ejozufCc0oFBcZw= =QHYH -----END PGP SIGNATURE----- --KxOeEu8Cag6KFZma-- From nobody Fri Apr 1 23:28:39 2022 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 342B71A5A2C2; Fri, 1 Apr 2022 23:28:43 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4KVbvs6Hcvz4pdy; Fri, 1 Apr 2022 23:28:41 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253]) by lax.lemis.com (Postfix) with ESMTP id BB86B28087; Fri, 1 Apr 2022 23:28:40 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 0C30B2635BE; Sat, 2 Apr 2022 10:28:40 +1100 (AEDT) Date: Sat, 2 Apr 2022 10:28:39 +1100 From: Greg 'groggy' Lehey To: Cy Schubert Cc: Alexey Dokuchaev , Yasuhiro Kimura , gjb@freebsd.org, freebsd-stable@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: Considering stepping down from all of my FreeBSD responsibilities Message-ID: <20220401232839.GT60301@eureka.lemis.com> References: <20220401001502.GI13797@FreeBSD.org> <20220401.142031.2286040474128292357.yasu@FreeBSD.org> <20220401064816.GS60301@eureka.lemis.com> <20220401163807.EB3D811F@slippy.cwsent.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y/XsGip80ttrIE8G" Content-Disposition: inline In-Reply-To: <20220401163807.EB3D811F@slippy.cwsent.com> Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: https://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4KVbvs6Hcvz4pdy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of grog@lemis.com designates 45.32.70.18 as permitted sender) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [-3.52 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:www.lemis.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_SPAM_SHORT(0.48)[0.478]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; RCVD_NO_TLS_LAST(0.10)[]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --y/XsGip80ttrIE8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 1 April 2022 at 9:38:07 -0700, Cy Schubert wrote: > In message <20220401064816.GS60301@eureka.lemis.com>, Greg 'groggy' Lehey > write > s: >> >> --TSQPSNmi3T91JED+ >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> >> On Friday, 1 April 2022 at 5:58:39 +0000, Alexey Dokuchaev wrote: >>> I don't think 2.2.10 is warranted. >> >> Agreed. The upgrade isn't sufficiently important. >> >> How about 2.2.9.1? > > I had a different more sinister thought: Announcing that we've moved from > BSDL to GPLv3 to be more like Linux. Well, since we have accepted (or at least put up with) git, why not? Of course, things go both ways. For those of you who missed it, www.lemis.com/grog/slashdot/ And that wasn't even 1 April. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php --y/XsGip80ttrIE8G Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAmJHiqcACgkQIubykFB6QiNWRACgh27uAIwsSHQHHKQYo90a402W g+sAnRANi2RXs8GXMc0mBB5mPssvXhdW =TOkr -----END PGP SIGNATURE----- --y/XsGip80ttrIE8G-- From nobody Sat Apr 2 17:15:05 2022 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 6953D1A63FDA for ; Sat, 2 Apr 2022 17:15:13 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 4KW3ZS5cN6z3vBg for ; Sat, 2 Apr 2022 17:15:12 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.1.14] (c-76-127-60-125.hsd1.nm.comcast.net [76.127.60.125]) (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) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 8B1561AF4F8 for ; Sat, 2 Apr 2022 17:15:06 +0000 (UTC) Message-ID: <85e190ca-d0f7-0caf-767e-49f00b180e0b@freebsd.org> Date: Sat, 2 Apr 2022 11:15:05 -0600 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: freebsd-current From: Sean Bruno Subject: xhci(4) hanging in early boot with drives attached Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KW3ZS5cN6z3vBg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 199.102.79.106 is neither permitted nor denied by domain of sbruno@freebsd.org) smtp.mailfrom=sbruno@freebsd.org X-Spamd-Result: default: False [-2.59 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:199.102.76.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.49)[-0.495]; FREEFALL_USER(0.00)[sbruno]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RECEIVED_SPAMHAUS_PBL(0.00)[76.127.60.125:received]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N As far as I can tell, xhci(4) is hanging on "something" during early boot (probably something uninitialized) that causes it to basically never attach drives. I only have one controller here, so it could be something special with my device. If I single user my machine and attach my storage array, probe/attach works just fine. Leaving the USB3 array attached during a full boot causes xhci(4) to become completely unresponsive and requires a reboot to resolve. I probably need someone who understand the early bits well enough to know what things a driver can/cannot do prior to single-user mode. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261912 sean From nobody Sun Apr 3 10:04:33 2022 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 3A8161A405BA for ; Sun, 3 Apr 2022 10:04:42 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4KWTzF2mDGz4kyG for ; Sun, 3 Apr 2022 10:04:41 +0000 (UTC) (envelope-from jamie@catflap.org) X-Catflap-Envelope-From: X-Catflap-Envelope-To: Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 233A4YXY000951 for ; Sun, 3 Apr 2022 11:04:34 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 233A4X9i000943 for freebsd-current@freebsd.org; Sun, 3 Apr 2022 11:04:33 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202204031004.233A4X9i000943@donotpassgo.dyslexicfish.net> Date: Sun, 03 Apr 2022 11:04:33 +0100 Organization: Dyslexic Fish To: freebsd-current@freebsd.org Subject: ps(1) with '-ww' / libxo truncating output User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sun, 03 Apr 2022 11:04:34 +0100 (BST) X-Rspamd-Queue-Id: 4KWTzF2mDGz4kyG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-3.66 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; NEURAL_HAM_SHORT(-0.97)[-0.973]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N I've noticed that ps(1) (even with '-ww') is truncating output if it exceeds a cerain length. Further investigation shows that this is due to the libxo module. The ps(1) man page implies there will be no truncation if "-ww" is used. Is this a manpage issue, or a libxo issue, or a ps issue in the way it calls libxo? Test cases. These commands (run under sh not csh/tcsh) stuff dummy variables into the environment. Note the truncated responses of test 1 and 2: 1) env -i $(jot 500 | awk '{print "testvar_"$0"=dummydummydummydummy"}') sh -c 'ps -wwe -p $$' 2) env -i $(jot 500 | awk '{print "testvar_"$0"=dummydummydummydummy"}') sh -c 'ps -wwe -p $$ --libxo text' 3) env -i $(jot 500 | awk '{print "testvar_"$0"=dummydummydummydummy"}') sh -c 'ps -wwe -p $$ --libxo xml' Cheers, Jamie From nobody Mon Apr 4 17:57:13 2022 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 68DD81A8EB1E for ; Mon, 4 Apr 2022 17:57:21 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KXJQ84bB2z3M3X for ; Mon, 4 Apr 2022 17:57:20 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-ej1-x62b.google.com with SMTP id i27so14497184ejd.9 for ; Mon, 04 Apr 2022 10:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:user-mail-address:date:message-id:user-agent :mime-version; bh=506aHxGpLpXIFcBsUVoOTssHBt/HIqIN+vADcpBXWl8=; b=kv1NgtN8B3SW6l6TVaDJvXj6JgZFRtNCt1hgCs8wSH6ST4X4k8mCER1sFKCnddt2r2 QpAV0ZYH4/gkQZe5xNaAKETMi5Yzv7KRm4C5rriPfJ8NZmalnzg4RzpkaoJUwFXocjy+ iC2atmxbuz+TNp+ySIVjsgOO1PvwieJZe1ecZ8C/Xn/rhuRmz5dE/iB99VcVXsGZRVm/ aVQJL6OenyHAHnUCEsjY7gtJjYYd8VfmWf8UZjXmWVo5bm9NDdpsXlDhS9q1w+6U6u2s Jcafagkc05qd9CStfT1464iRQ+qneBsNCXb7dEa+nEnfj7h5BoNhoPsDMbmS4LplbdIv ZJMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:user-mail-address:date :message-id:user-agent:mime-version; bh=506aHxGpLpXIFcBsUVoOTssHBt/HIqIN+vADcpBXWl8=; b=7Vtz5BRUfazBEYnBffRWKG1ScdkPX/vF/SVUCAuRzy/EBQpAha/yo53CqyUC27fp0B 59mW+AsjDboQZO4tpoay9OCe1Pdl9BOCLLplf+esyOz3J5jD0WUc7tJncWJo5AJlE9BS 61nJobcEFHaD6ayrysQ2A8EZ8Sw+5t39jG7cH6K+D7EKYFxsWmUfv/IUWOM26+8jTe8U Gb0iPVYjqwiZJ39wnOkHcbqTVMoBWi1h8kRSZ3j73Rp3d9BDRBmMHC2+AIEOYV4UMx8h Qn0TWGLY87BpQI4MwEAK98QXEehNxnu2x/q/0D0ZK8+xCMsCcyLWM4IjqODipQ00spaM VrnA== X-Gm-Message-State: AOAM530cVMYJyZR7APQOuEBMAGm08wqJNJqxJIVZQeBvxt13u5w18xYz QyP1WleXcNsS5cdxTftZg3IZ5e8JIIA= X-Google-Smtp-Source: ABdhPJzltISeKKXl29GLyRIpyz191RiwsWKqfXW9ve+l2XpGNP3zhAC64JTgFflaG9VzpRPqX7Peyg== X-Received: by 2002:a17:907:a088:b0:6e4:dad7:1b1f with SMTP id hu8-20020a170907a08800b006e4dad71b1fmr1290269ejc.84.1649095039695; Mon, 04 Apr 2022 10:57:19 -0700 (PDT) Received: from jedi.localdomain (adsl-dyn228.78-99-181.t-com.sk. [78.99.181.228]) by smtp.gmail.com with ESMTPSA id g14-20020a50e04e000000b0041cd8db541fsm1444093edl.74.2022.04.04.10.57.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 10:57:19 -0700 (PDT) Received: from localhost.my.domain (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (No client certificate requested) by jedi.localdomain (Postfix) with ESMTPS id 5DE4E9021A for ; Mon, 4 Apr 2022 19:57:14 +0200 (CEST) Received: (from koren@localhost) by localhost.my.domain (8.16.1/8.16.1/Submit) id 234HvEeB028455; Mon, 4 Apr 2022 19:57:14 +0200 (CEST) (envelope-from ludovit.koren@gmail.com) X-Authentication-Warning: localhost.my.domain: koren set sender to ludovit.koren@gmail.com using -f From: Ludovit Koren To: freebsd-current@freebsd.org Subject: current stopped booting on source between 20-th and 30th of March 22 User-Mail-Address: ludovit.koren@gmail.com Date: Mon, 04 Apr 2022 19:57:13 +0200 Message-ID: <86czhwenpi.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Rspamd-Queue-Id: 4KXJQ84bB2z3M3X X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=kv1NgtN8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::62b as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[78.99.181.228:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62b:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=-=-= Content-Type: text/plain Hi, I am running FreeBSD 14.0-CURRENT #0 main-n253876-1e9ce60a6d7 since Q321, on HP Elitebook. Please, see the attached file. The CURRENT stopped working between the March, 20th and the March, 30th. The machine cannot be booted. If there is something I can provide for the solution, let me know. Thank you. Regards, lk --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=dmesg.out Content-Transfer-Encoding: base64 LS0tPDxCT09UPj4tLS0KQ29weXJpZ2h0IChjKSAxOTkyLTIwMjIgVGhlIEZyZWVCU0QgUHJvamVj dC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkx LCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxp Zm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFk ZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxNC4wLUNVUlJFTlQgIzAg bWFpbi1uMjUzODc2LTFlOWNlNjBhNmQ3OiBTdW4gTWFyIDIwIDE1OjMyOjQ4IENFVCAyMDIyCiAg ICByb290QGplZGk6L3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC9zeXMvSFAgYW1kNjQKRnJl ZUJTRCBjbGFuZyB2ZXJzaW9uIDEzLjAuMCAoZ2l0QGdpdGh1Yi5jb206bGx2bS9sbHZtLXByb2pl Y3QuZ2l0IGxsdm1vcmctMTMuMC4wLTAtZ2Q3YjY2OWIzYTMwMykKV0FSTklORzogV0lUTkVTUyBv cHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClZUKGVmaWZiKTogcmVz b2x1dGlvbiAxOTIweDEwODAKQ1BVOiBJbnRlbChSKSBDb3JlKFRNKSBpNy0xMDcxMFUgQ1BVIEAg MS4xMEdIeiAoMTYwMC4wMC1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbj0iR2VudWluZUludGVs IiAgSWQ9MHhhMDY2MCAgRmFtaWx5PTB4NiAgTW9kZWw9MHhhNiAgU3RlcHBpbmc9MAogIEZlYXR1 cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNF UCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixT U0UsU1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDdmZmFmYmJmPFNTRTMsUENMTVVM UURRLERURVM2NCxNT04sRFNfQ1BMLFZNWCxFU1QsVE0yLFNTU0UzLFNEQkcsRk1BLENYMTYseFRQ UixQRENNLFBDSUQsU1NFNC4xLFNTRTQuMix4MkFQSUMsTU9WQkUsUE9QQ05ULFRTQ0RMVCxBRVNO SSxYU0FWRSxPU1hTQVZFLEFWWCxGMTZDLFJEUkFORD4KICBBTUQgRmVhdHVyZXM9MHgyYzEwMDgw MDxTWVNDQUxMLE5YLFBhZ2UxR0IsUkRUU0NQLExNPgogIEFNRCBGZWF0dXJlczI9MHgxMjE8TEFI RixBQk0sUHJlZmV0Y2g+CiAgU3RydWN0dXJlZCBFeHRlbmRlZCBGZWF0dXJlcz0weDI5YzY3YWY8 RlNHU0JBU0UsVFNDQURKLFNHWCxCTUkxLEFWWDIsU01FUCxCTUkyLEVSTVMsSU5WUENJRCxORlBV U0csTVBYLFJEU0VFRCxBRFgsU01BUCxDTEZMVVNIT1BULFBST0NUUkFDRT4KICBTdHJ1Y3R1cmVk IEV4dGVuZGVkIEZlYXR1cmVzMz0weGJjMDAwNDAwPE1EX0NMRUFSLElCUEIsU1RJQlAsTDFERkws QVJDSF9DQVAsU1NCRD4KICBYU0FWRSBGZWF0dXJlcz0weGY8WFNBVkVPUFQsWFNBVkVDLFhJTlVT RSxYU0FWRVM+CiAgSUEzMl9BUkNIX0NBUFM9MHgyYjxSRENMX05PLElCUlNfQUxMLFNLSVBfTDFE RkxfVk1FLE1EU19OTz4KICBWVC14OiBQQVQsSExULE1URixQQVVTRSxFUFQsVUcsVlBJRAogIFRT QzogUC1zdGF0ZSBpbnZhcmlhbnQsIHBlcmZvcm1hbmNlIHN0YXRpc3RpY3MKcmVhbCBtZW1vcnkg ID0gMzQzNTk3MzgzNjggKDMyNzY4IE1CKQphdmFpbCBtZW1vcnkgPSAzMzA3NjQyODgwMCAoMzE1 NDQgTUIpCkFDUEkgQVBJQyBUYWJsZTogPEhQUU9FTSA4NzIzICAgID4KRnJlZUJTRC9TTVA6IE11 bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMTIgQ1BVcwpGcmVlQlNEL1NNUDogMSBwYWNr YWdlKHMpIHggNiBjb3JlKHMpIHggMiBoYXJkd2FyZSB0aHJlYWRzCnJhbmRvbTogcmVnaXN0ZXJp bmcgZmFzdCBzb3VyY2UgSW50ZWwgU2VjdXJlIEtleSBSTkcKcmFuZG9tOiBmYXN0IHByb3ZpZGVy OiAiSW50ZWwgU2VjdXJlIEtleSBSTkciCnJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuCmlvYXBp YzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMTE5CkxhdW5jaGluZyBBUHM6IDEgMiA1IDkgMTEgNyAz IDggMTAgNiA0CkN1c2UgdjAuMS4zNiBAIC9kZXYvY3VzZQpyYW5kb206IGVudHJvcHkgZGV2aWNl IGV4dGVybmFsIGludGVyZmFjZQprYmQxIGF0IGtiZG11eDAKZWZpcnRjMDogPEVGSSBSZWFsdGlt ZSBDbG9jaz4KZWZpcnRjMDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrLCByZXNv bHV0aW9uIDEuMDAwMDAwcwpzbWJpb3MwOiA8U3lzdGVtIE1hbmFnZW1lbnQgQklPUz4gYXQgaW9t ZW0gMHg5MmQ4NjAwMC0weDkyZDg2MDFlCnNtYmlvczA6IFZlcnNpb246IDMuMiwgQkNEIFJldmlz aW9uOiAzLjIKYWVzbmkwOiA8QUVTLUNCQyxBRVMtQ0NNLEFFUy1HQ00sQUVTLUlDTSxBRVMtWFRT PgphY3BpMDogPEhQUU9FTSBTTElDLUJQQz4KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmNw dTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1l cj4gaW9tZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmIG9uIGFjcGkwClRpbWVjb3VudGVyICJIUEVU IiBmcmVxdWVuY3kgMjQwMDAwMDAgSHogcXVhbGl0eSA5NTAKRXZlbnQgdGltZXIgIkhQRVQiIGZy ZXF1ZW5jeSAyNDAwMDAwMCBIeiBxdWFsaXR5IDM1MApFdmVudCB0aW1lciAiSFBFVDEiIGZyZXF1 ZW5jeSAyNDAwMDAwMCBIeiBxdWFsaXR5IDM0MApFdmVudCB0aW1lciAiSFBFVDIiIGZyZXF1ZW5j eSAyNDAwMDAwMCBIeiBxdWFsaXR5IDM0MApFdmVudCB0aW1lciAiSFBFVDMiIGZyZXF1ZW5jeSAy NDAwMDAwMCBIeiBxdWFsaXR5IDM0MApFdmVudCB0aW1lciAiSFBFVDQiIGZyZXF1ZW5jeSAyNDAw MDAwMCBIeiBxdWFsaXR5IDM0MApFdmVudCB0aW1lciAiSFBFVDUiIGZyZXF1ZW5jeSAyNDAwMDAw MCBIeiBxdWFsaXR5IDM0MApFdmVudCB0aW1lciAiSFBFVDYiIGZyZXF1ZW5jeSAyNDAwMDAwMCBI eiBxdWFsaXR5IDM0MApFdmVudCB0aW1lciAiSFBFVDciIGZyZXF1ZW5jeSAyNDAwMDAwMCBIeiBx dWFsaXR5IDM0MAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzcgaXJx IDggb24gYWNwaTAKYXRydGMwOiBXYXJuaW5nOiBDb3VsZG4ndCBtYXAgSS9PLgphdHJ0YzA6IHJl Z2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9jaywgcmVzb2x1dGlvbiAxLjAwMDAwMHMKRXZl bnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMAphdHRpbWVyMDogPEFU IHRpbWVyPiBwb3J0IDB4NDAtMHg0MywweDUwLTB4NTMgaXJxIDAgb24gYWNwaTAKVGltZWNvdW50 ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKRXZlbnQgdGltZXIgImk4 MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMApUaW1lY291bnRlciAiQUNQSS1m YXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDkwMAphY3BpX3RpbWVyMDogPDI0LWJp dCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDE4MDgtMHgxODBiIG9uIGFjcGkwCmFjcGlf ZWMwOiA8RW1iZWRkZWQgQ29udHJvbGxlcjogR1BFIDB4NmU+IHBvcnQgMHg2MiwweDY2IG9uIGFj cGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNw aTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxl IGRpc3BsYXk+IHBvcnQgMHgzMDAwLTB4MzAzZiBtZW0gMHhkZjAwMDAwMC0weGRmZmZmZmZmLDB4 YTAwMDAwMDAtMHhhZmZmZmZmZiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKdmdhcGNpMDogQm9vdCB2 aWRlbyBkZXZpY2UKeGhjaTA6IDxYSENJIChnZW5lcmljKSBVU0IgMy4wIGNvbnRyb2xsZXI+IG1l bSAweGUwMTAwMDAwLTB4ZTAxMGZmZmYgYXQgZGV2aWNlIDIwLjAgb24gcGNpMAp4aGNpMDogMzIg Ynl0ZXMgY29udGV4dCBzaXplLCA2NC1iaXQgRE1BCnVzYnVzMCBvbiB4aGNpMAp1c2J1czA6IDUu MEdicHMgU3VwZXIgU3BlZWQgVVNCIHYzLjAKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2Ug MjAuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8bmV0d29yaz4gYXQgZGV2aWNlIDIwLjMg KG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPHNlcmlhbCBidXM+IGF0IGRldmljZSAyMS4wIChu byBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxzZXJpYWwgYnVzPiBhdCBkZXZpY2UgMjEuMSAobm8g ZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2UgMjIuMCAobm8g ZHJpdmVyIGF0dGFjaGVkKQpwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAy OC4wIG9uIHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpYjI6IDxBQ1BJIFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMC4wIG9uIHBjaTEKcGNpMjogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjIKcGNpYjM6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBwY2kyCnBj aTM6IDxQQ0kgYnVzPiBvbiBwY2liMwpwY2liNDogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2Ug MS4wIG9uIHBjaTIKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMi4wIG9u IHBjaTIKcGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUKeGhjaTE6IDxJbnRlbCBUaXRhbiBS aWRnZSBUaHVuZGVyYm9sdCAzIFVTQiBjb250cm9sbGVyPiBtZW0gMHhjNmYwMDAwMC0weGM2ZjBm ZmZmIGF0IGRldmljZSAwLjAgb24gcGNpNAp4aGNpMTogMzIgYnl0ZXMgY29udGV4dCBzaXplLCA2 NC1iaXQgRE1BCnVzYnVzMSBvbiB4aGNpMQp1c2J1czE6IDUuMEdicHMgU3VwZXIgU3BlZWQgVVNC IHYzLjAKcGNpYjY6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDQuMCBvbiBwY2kyCnBjaWI3 OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI5LjAgb24gcGNpMApwY2k1OiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liNwpudm1lMDogPEdlbmVyaWMgTlZNZSBEZXZpY2U+IG1lbSAweGUw MDAwMDAwLTB4ZTAwMDNmZmYgYXQgZGV2aWNlIDAuMCBvbiBwY2k1CmlzYWIwOiA8UENJLUlTQSBi cmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmhk YWMwOiA8SW50ZWwgQ29tZXQgTGFrZS1MUCBIREEgQ29udHJvbGxlcj4gbWVtIDB4NDA0YTEwODAw MC0weDQwNGExMGJmZmYsMHg0MDRhMDAwMDAwLTB4NDA0YTBmZmZmZiBhdCBkZXZpY2UgMzEuMyBv biBwY2kwCnBjaTA6IDxzZXJpYWwgYnVzPiBhdCBkZXZpY2UgMzEuNSAobm8gZHJpdmVyIGF0dGFj aGVkKQpiYXR0ZXJ5MDogPEFDUEkgQ29udHJvbCBNZXRob2QgQmF0dGVyeT4gb24gYWNwaTAKYWNw aV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFNsZWVwIEJ1dHRv bj4gb24gYWNwaTAKYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3aXRjaD4gb24gYWNw aTAKYWNwaV9idXR0b24xOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAphY3BpX3R6MDogPFRoZXJt YWwgWm9uZT4gb24gYWNwaTAKYWNwaV90ejE6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmFjcGlf dHoyOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMAphY3BpX3R6MzogPFRoZXJtYWwgWm9uZT4gb24g YWNwaTAKYWNwaV90ejQ6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmFjcGlfdHo1OiA8VGhlcm1h bCBab25lPiBvbiBhY3BpMAphY3BpX3R6NjogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAKYWNwaV90 ejc6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmFjcGlfdHo4OiA8VGhlcm1hbCBab25lPiBvbiBh Y3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2 NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMApr YmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmFjcGlfc3lzY29udGFpbmVyMDog PFN5c3RlbSBDb250YWluZXI+IG9uIGFjcGkwCmNvcmV0ZW1wMDogPENQVSBPbi1EaWUgVGhlcm1h bCBTZW5zb3JzPiBvbiBjcHUwCmh3cHN0YXRlX2ludGVsMDogPEludGVsIFNwZWVkIFNoaWZ0PiBv biBjcHUwCmh3cHN0YXRlX2ludGVsMTogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHUxCmh3cHN0 YXRlX2ludGVsMjogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHUyCmh3cHN0YXRlX2ludGVsMzog PEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHUzCmh3cHN0YXRlX2ludGVsNDogPEludGVsIFNwZWVk IFNoaWZ0PiBvbiBjcHU0Cmh3cHN0YXRlX2ludGVsNTogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBj cHU1Cmh3cHN0YXRlX2ludGVsNjogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHU2Cmh3cHN0YXRl X2ludGVsNzogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHU3Cmh3cHN0YXRlX2ludGVsODogPElu dGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHU4Cmh3cHN0YXRlX2ludGVsOTogPEludGVsIFNwZWVkIFNo aWZ0PiBvbiBjcHU5Cmh3cHN0YXRlX2ludGVsMTA6IDxJbnRlbCBTcGVlZCBTaGlmdD4gb24gY3B1 MTAKaHdwc3RhdGVfaW50ZWwxMTogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHUxMQpUaW1lY291 bnRlciAiVFNDIiBmcmVxdWVuY3kgMTYwNzk5OTc3OSBIeiBxdWFsaXR5IDEwMDAKVGltZWNvdW50 ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpaRlMgZmlsZXN5c3RlbSB2ZXJzaW9uOiA1ClpGUyBz dG9yYWdlIHBvb2wgdmVyc2lvbjogZmVhdHVyZXMgc3VwcG9ydCAoNTAwMCkKdWdlbjAuMTogPElu dGVsIFhIQ0kgcm9vdCBIVUI+IGF0IHVzYnVzMAp1aHViMCBvbiB1c2J1czAKdWh1YjA6IDxJbnRl bCBYSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAzLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXMwCnVnZW4xLjE6IDxJbnRlbCBYSENJIHJvb3QgSFVCPiBhdCB1c2J1czEKdWh1YjEgb24gdXNi dXMxCnVodWIxOiA8SW50ZWwgWEhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMy4wMC8xLjAw LCBhZGRyIDE+IG9uIHVzYnVzMQpudm1lMDogQWxsb2NhdGVkIDY0TUIgaG9zdCBtZW1vcnkgYnVm ZmVyCm52ZDA6IDxTYW1zdW5nIFNTRCA5ODAgMVRCPiBOVk1lIG5hbWVzcGFjZQpudmQwOiA5NTM4 NjlNQiAoMTk1MzUyNTE2OCA1MTIgYnl0ZSBzZWN0b3JzKQpoZGFjYzA6IDxSZWFsdGVrIEFMQzI4 NSBIREEgQ09ERUM+IGF0IGNhZCAwIG9uIGhkYWMwCmhkYWEwOiA8UmVhbHRlayBBTEMyODUgQXVk aW8gRnVuY3Rpb24gR3JvdXA+IGF0IG5pZCAxIG9uIGhkYWNjMApwY20wOiA8UmVhbHRlayBBTEMy ODUgKEFuYWxvZyAyLjArSFAvMi4wKT4gYXQgbmlkIDIwLDMzIGFuZCAyNSBvbiBoZGFhMApoZGFj YzE6IDxJbnRlbCBLYWJ5IExha2UgSERBIENPREVDPiBhdCBjYWQgMiBvbiBoZGFjMApoZGFhMTog PEludGVsIEthYnkgTGFrZSBBdWRpbyBGdW5jdGlvbiBHcm91cD4gYXQgbmlkIDEgb24gaGRhY2Mx CnBjbTE6IDxJbnRlbCBLYWJ5IExha2UgKEhETUkvRFAgOGNoKT4gYXQgbmlkIDMgb24gaGRhYTEK VHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB6ZnM6enJvb3QvUk9PVC9kZWZhdWx0IFtdLi4uCldB Uk5JTkc6IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNl Lgp1aHViMTogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjA6IDE4 IHBvcnRzIHdpdGggMTggcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5n IGZvcjogdXNidXMwCnVnZW4wLjI6IDxDaGljb255IEVsZWN0cm9uaWNzIENvLixMdGQuIEhQIEhE IENhbWVyYT4gYXQgdXNidXMwCnVnZW4wLjM6IDx2ZW5kb3IgMHgwNmNiIHByb2R1Y3QgMHgwMGRm PiBhdCB1c2J1czAKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMwCnVnZW4wLjQ6IDx2ZW5k b3IgMHg4MDg3IHByb2R1Y3QgMHgwMDI2PiBhdCB1c2J1czAKZHJtbjA6IDxkcm1uPiBvbiB2Z2Fw Y2kwCnZnYXBjaTA6IGNoaWxkIGRybW4wIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2lvCnZnYXBjaTA6 IGNoaWxkIGRybW4wIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2lvCltkcm1dIFVuYWJsZSB0byBjcmVh dGUgYSBwcml2YXRlIHRtcGZzIG1vdW50LCBodWdlcGFnZSBzdXBwb3J0IHdpbGwgYmUgZGlzYWJs ZWQoLTE5KS4KVlQ6IFJlcGxhY2luZyBkcml2ZXIgImVmaWZiIiB3aXRoIG5ldyAiZHVtbXkiLgpb ZHJtXSBHb3Qgc3RvbGVuIG1lbW9yeSBiYXNlIDB4MCwgc2l6ZSAweDAKW2RybV0gU3VwcG9ydHMg dmJsYW5rIHRpbWVzdGFtcCBjYWNoaW5nIFJldiAyICgyMS4xMC4yMDEzKS4KW2RybV0gRHJpdmVy IHN1cHBvcnRzIHByZWNpc2UgdmJsYW5rIHRpbWVzdGFtcCBxdWVyeS4KW2RybV0gQ29ubmVjdG9y IGVEUC0xOiBnZXQgbW9kZSBmcm9tIHR1bmFibGVzOgpbZHJtXSAgIC0ga2Vybi52dC5mYi5tb2Rl cy5lRFAtMQpbZHJtXSAgIC0ga2Vybi52dC5mYi5kZWZhdWx0X21vZGUKZHJtbjA6IHN1Y2Nlc3Nm dWxseSBsb2FkZWQgZmlybXdhcmUgaW1hZ2UgJ2k5MTUva2JsX2RtY192ZXIxXzA0LmJpbicKW2Ry bV0gRmluaXNoZWQgbG9hZGluZyBETUMgZmlybXdhcmUgaTkxNS9rYmxfZG1jX3ZlcjFfMDQuYmlu ICh2MS40KQpbZHJtXSBDb25uZWN0b3IgRFAtMTogZ2V0IG1vZGUgZnJvbSB0dW5hYmxlczoKW2Ry bV0gICAtIGtlcm4udnQuZmIubW9kZXMuRFAtMQpbZHJtXSAgIC0ga2Vybi52dC5mYi5kZWZhdWx0 X21vZGUKW2RybV0gQ29ubmVjdG9yIEhETUktQS0xOiBnZXQgbW9kZSBmcm9tIHR1bmFibGVzOgpb ZHJtXSAgIC0ga2Vybi52dC5mYi5tb2Rlcy5IRE1JLUEtMQpbZHJtXSAgIC0ga2Vybi52dC5mYi5k ZWZhdWx0X21vZGUKW2RybV0gQ29ubmVjdG9yIERQLTI6IGdldCBtb2RlIGZyb20gdHVuYWJsZXM6 Cltkcm1dICAgLSBrZXJuLnZ0LmZiLm1vZGVzLkRQLTIKW2RybV0gICAtIGtlcm4udnQuZmIuZGVm YXVsdF9tb2RlCltkcm1dIENvbm5lY3RvciBIRE1JLUEtMjogZ2V0IG1vZGUgZnJvbSB0dW5hYmxl czoKW2RybV0gICAtIGtlcm4udnQuZmIubW9kZXMuSERNSS1BLTIKW2RybV0gICAtIGtlcm4udnQu ZmIuZGVmYXVsdF9tb2RlCmRybW4wOiBGYWlsZWQgdG8gcHJvZ3JhbSBNT0NTIHJlZ2lzdGVyczsg ZXhwZWN0IHBlcmZvcm1hbmNlIGlzc3Vlcy4Kc3lzY3RsX3dhcm5fcmV1c2U6IGNhbid0IHJlLXVz ZSBhIGxlYWYgKGh3LmRyaS5kZWJ1ZykhCltkcm1dIEluaXRpYWxpemVkIGk5MTUgMS42LjAgMjAx OTA4MjIgZm9yIGRybW4wIG9uIG1pbm9yIDAKV0FSTklORzogRGV2aWNlICJmYiIgaXMgR2lhbnQg bG9ja2VkIGFuZCBtYXkgYmUgZGVsZXRlZCBiZWZvcmUgRnJlZUJTRCAxNC4wLgpWVDogUmVwbGFj aW5nIGRyaXZlciAiZHVtbXkiIHdpdGggbmV3ICJmYiIuCnRhc2txdWV1ZV9kcmFpbiB3aXRoIHRo ZSBmb2xsb3dpbmcgbm9uLXNsZWVwYWJsZSBsb2NrcyBoZWxkOgpleGNsdXNpdmUgc2xlZXAgbXV0 ZXggdnRkZXYgKHZ0ZGV2KSByID0gMCAoMHhmZmZmZmZmZjgwZTk4N2Y4KSBsb2NrZWQgQCAvdXNy L3NyYy9zeXMvZGV2L3Z0L3Z0X2NvcmUuYzozMDYxCnN0YWNrIGJhY2t0cmFjZToKIzAgMHhmZmZm ZmZmZjgwNzQyOTkxIGF0IHdpdG5lc3NfZGVidWdnZXIrMHg3MQojMSAweGZmZmZmZmZmODA3NDNh ZWEgYXQgd2l0bmVzc193YXJuKzB4M2VhCiMyIDB4ZmZmZmZmZmY4MDczNTI0MyBhdCB0YXNrcXVl dWVfZHJhaW4rMHgzMwojMyAweGZmZmZmZmZmODMwYWY1ODMgYXQgdnRfa21zX3Bvc3Rzd2l0Y2gr MHg3MwojNCAweGZmZmZmZmZmODA1OTRkNWQgYXQgdnRfZmJfaW5pdCsweGZkCiM1IDB4ZmZmZmZm ZmY4MDU5YzE1OCBhdCB2dF9yZXBsYWNlX2JhY2tlbmQrMHgxMTgKIzYgMHhmZmZmZmZmZjgwNTk0 ZTYzIGF0IHZ0X2ZiX2F0dGFjaCsweDEzCiM3IDB4ZmZmZmZmZmY4MzBiMDBiNyBhdCBsaW51eF9y ZWdpc3Rlcl9mcmFtZWJ1ZmZlcisweDUzNwojOCAweGZmZmZmZmZmODMwYjdhZGEgYXQgX19kcm1f ZmJfaGVscGVyX2luaXRpYWxfY29uZmlnX2FuZF91bmxvY2srMHg0NWEKIzkgMHhmZmZmZmZmZjgz MDFhZWQwIGF0IGludGVsX2ZiZGV2X2luaXRpYWxfY29uZmlnX2FzeW5jKzB4MjAKIzEwIDB4ZmZm ZmZmZmY4MmYwYTIxMSBhdCBpOTE1X2RyaXZlcl9wcm9iZSsweDEwNzEKIzExIDB4ZmZmZmZmZmY4 MmYyNWRlMyBhdCBpOTE1X3BjaV9wcm9iZSsweDYzCiMxMiAweGZmZmZmZmZmODA5N2MwNjEgYXQg bGludXhfcGNpX2F0dGFjaF9kZXZpY2UrMHg0MzEKIzEzIDB4ZmZmZmZmZmY4MDcwZDM3MSBhdCBk ZXZpY2VfYXR0YWNoKzB4M2MxCiMxNCAweGZmZmZmZmZmODA3MGNmMjAgYXQgZGV2aWNlX3Byb2Jl X2FuZF9hdHRhY2grMHg3MAojMTUgMHhmZmZmZmZmZjgwNzBlZjM3IGF0IGJ1c19nZW5lcmljX2Ry aXZlcl9hZGRlZCsweDY3CiMxNiAweGZmZmZmZmZmODA3MGE5ZTkgYXQgZGV2Y2xhc3NfZHJpdmVy X2FkZGVkKzB4MzkKIzE3IDB4ZmZmZmZmZmY4MDcwYTkyNyBhdCBkZXZjbGFzc19hZGRfZHJpdmVy KzB4MTQ3ClNsZWVwaW5nIG9uICJ0cV9kcmFpbiIgd2l0aCB0aGUgZm9sbG93aW5nIG5vbi1zbGVl cGFibGUgbG9ja3MgaGVsZDoKZXhjbHVzaXZlIHNsZWVwIG11dGV4IHZ0ZGV2ICh2dGRldikgciA9 IDAgKDB4ZmZmZmZmZmY4MGU5ODdmOCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL2Rldi92dC92dF9j b3JlLmM6MzA2MQpzdGFjayBiYWNrdHJhY2U6CiMwIDB4ZmZmZmZmZmY4MDc0Mjk5MSBhdCB3aXRu ZXNzX2RlYnVnZ2VyKzB4NzEKIzEgMHhmZmZmZmZmZjgwNzQzYWVhIGF0IHdpdG5lc3Nfd2Fybisw eDNlYQojMiAweGZmZmZmZmZmODA2ZGQ3YWIgYXQgX3NsZWVwKzB4NWIKIzMgMHhmZmZmZmZmZjgw NzM1MzBiIGF0IHRhc2txdWV1ZV9kcmFpbisweGZiCiM0IDB4ZmZmZmZmZmY4MzBhZjU4MyBhdCB2 dF9rbXNfcG9zdHN3aXRjaCsweDczCiM1IDB4ZmZmZmZmZmY4MDU5NGQ1ZCBhdCB2dF9mYl9pbml0 KzB4ZmQKIzYgMHhmZmZmZmZmZjgwNTljMTU4IGF0IHZ0X3JlcGxhY2VfYmFja2VuZCsweDExOAoj NyAweGZmZmZmZmZmODA1OTRlNjMgYXQgdnRfZmJfYXR0YWNoKzB4MTMKIzggMHhmZmZmZmZmZjgz MGIwMGI3IGF0IGxpbnV4X3JlZ2lzdGVyX2ZyYW1lYnVmZmVyKzB4NTM3CiM5IDB4ZmZmZmZmZmY4 MzBiN2FkYSBhdCBfX2RybV9mYl9oZWxwZXJfaW5pdGlhbF9jb25maWdfYW5kX3VubG9jaysweDQ1 YQojMTAgMHhmZmZmZmZmZjgzMDFhZWQwIGF0IGludGVsX2ZiZGV2X2luaXRpYWxfY29uZmlnX2Fz eW5jKzB4MjAKIzExIDB4ZmZmZmZmZmY4MmYwYTIxMSBhdCBpOTE1X2RyaXZlcl9wcm9iZSsweDEw NzEKIzEyIDB4ZmZmZmZmZmY4MmYyNWRlMyBhdCBpOTE1X3BjaV9wcm9iZSsweDYzCiMxMyAweGZm ZmZmZmZmODA5N2MwNjEgYXQgbGludXhfcGNpX2F0dGFjaF9kZXZpY2UrMHg0MzEKIzE0IDB4ZmZm ZmZmZmY4MDcwZDM3MSBhdCBkZXZpY2VfYXR0YWNoKzB4M2MxCiMxNSAweGZmZmZmZmZmODA3MGNm MjAgYXQgZGV2aWNlX3Byb2JlX2FuZF9hdHRhY2grMHg3MAojMTYgMHhmZmZmZmZmZjgwNzBlZjM3 IGF0IGJ1c19nZW5lcmljX2RyaXZlcl9hZGRlZCsweDY3CiMxNyAweGZmZmZmZmZmODA3MGE5ZTkg YXQgZGV2Y2xhc3NfZHJpdmVyX2FkZGVkKzB4MzkKbG9jayBvcmRlciByZXZlcnNhbDogKEdpYW50 IGFmdGVyIG5vbi1zbGVlcGFibGUpCiAxc3QgMHhmZmZmZmZmZjgwZTk4N2Y4IHZ0ZGV2ICh2dGRl diwgc2xlZXAgbXV0ZXgpIEAgL3Vzci9zcmMvc3lzL2Rldi92dC92dF9jb3JlLmM6MzA2MQogMm5k IDB4ZmZmZmZmZmY4MGUwMjljMCBHaWFudCAoR2lhbnQsIHNsZWVwIG11dGV4KSBAIC91c3Ivc3Jj L3N5cy9rZXJuL2tlcm5fc3luY2guYzoyMzIKbG9jayBvcmRlciBHaWFudCAtPiB2dGRldiBlc3Rh Ymxpc2hlZCBhdDoKIzAgMHhmZmZmZmZmZjgwNzQxYzdlIGF0IHdpdG5lc3NfY2hlY2tvcmRlcisw eDMxZQojMSAweGZmZmZmZmZmODA2YWM0MzQgYXQgX19tdHhfbG9ja19mbGFncysweDk0CiMyIDB4 ZmZmZmZmZmY4MDU5YjcyNSBhdCB2dF91cGdyYWRlKzB4MzY1CiMzIDB4ZmZmZmZmZmY4MDY1ODUz ZiBhdCBtaV9zdGFydHVwKzB4MjBmCiM0IDB4ZmZmZmZmZmY4MDJmM2QwMiBhdCBidGV4dCsweDIy CmxvY2sgb3JkZXIgdnRkZXYgLT4gR2lhbnQgYXR0ZW1wdGVkIGF0OgojMCAweGZmZmZmZmZmODA3 NDI1M2QgYXQgd2l0bmVzc19jaGVja29yZGVyKzB4YmRkCiMxIDB4ZmZmZmZmZmY4MDZhYzQzNCBh dCBfX210eF9sb2NrX2ZsYWdzKzB4OTQKIzIgMHhmZmZmZmZmZjgwNmRkYWNkIGF0IF9zbGVlcCsw eDM3ZAojMyAweGZmZmZmZmZmODA3MzUzMGIgYXQgdGFza3F1ZXVlX2RyYWluKzB4ZmIKIzQgMHhm ZmZmZmZmZjgzMGFmNTgzIGF0IHZ0X2ttc19wb3N0c3dpdGNoKzB4NzMKIzUgMHhmZmZmZmZmZjgw NTk0ZDVkIGF0IHZ0X2ZiX2luaXQrMHhmZAojNiAweGZmZmZmZmZmODA1OWMxNTggYXQgdnRfcmVw bGFjZV9iYWNrZW5kKzB4MTE4CiM3IDB4ZmZmZmZmZmY4MDU5NGU2MyBhdCB2dF9mYl9hdHRhY2gr MHgxMwojOCAweGZmZmZmZmZmODMwYjAwYjcgYXQgbGludXhfcmVnaXN0ZXJfZnJhbWVidWZmZXIr MHg1MzcKIzkgMHhmZmZmZmZmZjgzMGI3YWRhIGF0IF9fZHJtX2ZiX2hlbHBlcl9pbml0aWFsX2Nv bmZpZ19hbmRfdW5sb2NrKzB4NDVhCiMxMCAweGZmZmZmZmZmODMwMWFlZDAgYXQgaW50ZWxfZmJk ZXZfaW5pdGlhbF9jb25maWdfYXN5bmMrMHgyMAojMTEgMHhmZmZmZmZmZjgyZjBhMjExIGF0IGk5 MTVfZHJpdmVyX3Byb2JlKzB4MTA3MQojMTIgMHhmZmZmZmZmZjgyZjI1ZGUzIGF0IGk5MTVfcGNp X3Byb2JlKzB4NjMKIzEzIDB4ZmZmZmZmZmY4MDk3YzA2MSBhdCBsaW51eF9wY2lfYXR0YWNoX2Rl dmljZSsweDQzMQojMTQgMHhmZmZmZmZmZjgwNzBkMzcxIGF0IGRldmljZV9hdHRhY2grMHgzYzEK IzE1IDB4ZmZmZmZmZmY4MDcwY2YyMCBhdCBkZXZpY2VfcHJvYmVfYW5kX2F0dGFjaCsweDcwCiMx NiAweGZmZmZmZmZmODA3MGVmMzcgYXQgYnVzX2dlbmVyaWNfZHJpdmVyX2FkZGVkKzB4NjcKIzE3 IDB4ZmZmZmZmZmY4MDcwYTllOSBhdCBkZXZjbGFzc19kcml2ZXJfYWRkZWQrMHgzOQpzdGFydCBG Ql9JTkZPOgp0eXBlPTExIGhlaWdodD0xMDgwIHdpZHRoPTE5MjAgZGVwdGg9MzIKY21zaXplPTE2 IHNpemU9ODI5NDQwMApwYmFzZT0weGEwMDQwMDAwIHZiYXNlPTB4ZmZmZmY4MDBhMDA0MDAwMApu YW1lPWRybW4wIGZsYWdzPTB4MCBzdHJpZGU9NzY4MCBicHA9MzIKY21hcFswXT0wIGNtYXBbMV09 N2YwMDAwIGNtYXBbMl09N2YwMCBjbWFwWzNdPWM0YTAwMAplbmQgRkJfSU5GTwpkcm1uMDogZmIw OiBpOTE1ZHJtZmIgZnJhbWUgYnVmZmVyIGRldmljZQpJbnRlbChSKSBXaXJlbGVzcyBXaUZpIGJh c2VkIGRyaXZlciBmb3IgRnJlZUJTRAphY3BpX3dtaTA6IDxBQ1BJLVdNSSBtYXBwaW5nPiBvbiBh Y3BpMAphY3BpX3dtaTA6IEVtYmVkZGVkIE1PRiBmb3VuZApBQ1BJOiBcMTM0X1NCLldNSUIuV1Fa WjogMSBhcmd1bWVudHMgd2VyZSBwYXNzZWQgdG8gYSBub24tbWV0aG9kIEFDUEkgb2JqZWN0IChC dWZmZXIpICgyMDIxMDkzMC9uc2FyZ3VtZW50cy0zNjEpCmFjcGlfd21pMTogPEFDUEktV01JIG1h cHBpbmc+IG9uIGFjcGkwCmFjcGlfd21pMTogRW1iZWRkZWQgTU9GIGZvdW5kCkFDUEk6IFwxMzRf U0IuV01JVi5XUVpaOiAxIGFyZ3VtZW50cyB3ZXJlIHBhc3NlZCB0byBhIG5vbi1tZXRob2QgQUNQ SSBvYmplY3QgKEJ1ZmZlcikgKDIwMjEwOTMwL25zYXJndW1lbnRzLTM2MSkKYWNwaV93bWkyOiA8 QUNQSS1XTUkgbWFwcGluZz4gb24gYWNwaTAKYWNwaV93bWkyOiBFbWJlZGRlZCBNT0YgZm91bmQK YWNwaV93bWkzOiA8QUNQSS1XTUkgbWFwcGluZz4gb24gYWNwaTAKcGNodGhlcm0wOiA8Q29tZXRM YWtlLUxQIFRoZXJtYWwgU3Vic3lzdGVtPiBtZW0gMHg0MDRhMTExMDAwLTB4NDA0YTExMWZmZiBh dCBkZXZpY2UgMTguMCBvbiBwY2kwCml3bHdpZmkwOiA8aXdsd2lmaT4gbWVtIDB4ZTAxMTAwMDAt MHhlMDExM2ZmZiBhdCBkZXZpY2UgMjAuMyBvbiBwY2kwCmlnNGlpYzA6IDxJbnRlbCBDb21ldCBM YWtlLUxQIEkyQyBDb250cm9sbGVyLTA+IGF0IGRldmljZSAyMS4wIG9uIHBjaTAKaWc0aWljMDog VXNpbmcgTVNJCml3bHdpZmkwOiBjb3VsZCBub3QgbG9hZCBmaXJtd2FyZSBpbWFnZSAnaXdsd2lm aS1RdVotYTAtaHItYjAtNzAudWNvZGUnCml3bHdpZmkwOiBGaWxlIHNpemUgd2F5IHRvbyBzbWFs bCEKaXdsd2lmaTA6IGNvdWxkIG5vdCBsb2FkIGZpcm13YXJlIGltYWdlICdpd2x3aWZpLVF1Wi1h MC1oci1iMC02OS51Y29kZScKaXdsd2lmaTA6IEZpbGUgc2l6ZSB3YXkgdG9vIHNtYWxsIQppaWNi dXMwOiA8UGhpbGlwcyBJMkMgYnVzIChBQ1BJLWhpbnRlZCk+IG9uIGlnNGlpYzAKaXdsd2lmaTA6 IHN1Y2Nlc3NmdWxseSBsb2FkZWQgZmlybXdhcmUgaW1hZ2UgJ2l3bHdpZmktUXVaLWEwLWhyLWIw LTY4LnVjb2RlJwppd2x3aWZpMDogYXBpIGZsYWdzIGluZGV4IDIgbGFyZ2VyIHRoYW4gc3VwcG9y dGVkIGJ5IGRyaXZlcgppd2x3aWZpMDogVExWX0ZXX0ZTRVFfVkVSU0lPTjogRlNFUSBWZXJzaW9u OiA4OS4zLjM1LjM3Cml3bHdpZmkwOiBsb2FkZWQgZmlybXdhcmUgdmVyc2lvbiA2OC4wMWQzMGIw Yy4wIFF1Wi1hMC1oci1iMC02OC51Y29kZSBvcF9tb2RlIGl3bG12bQppd2x3aWZpMDogRGV0ZWN0 ZWQgSW50ZWwoUikgV2ktRmkgNiBBWDIwMSAxNjBNSHosIFJFVj0weDM1MQppd2x3aWZpMDogRGV0 ZWN0ZWQgUkYgSFIgQjMsIHJmaWQ9MHgxMGExMDAKaXdsd2lmaTA6IGJhc2UgSFcgYWRkcmVzczog Njg6NTQ6NWE6NTI6NWU6NzIKaWljYnVzMDogPHVua25vd24gY2FyZD4gYXQgYWRkciAweDJjCmln NGlpYzE6IDxJbnRlbCBDb21ldCBMYWtlLUxQIEkyQyBDb250cm9sbGVyLTE+IGF0IGRldmljZSAy MS4xIG9uIHBjaTAKaWc0aWljMTogVXNpbmcgTVNJCmlpY2J1czE6IDxQaGlsaXBzIEkyQyBidXMg KEFDUEktaGludGVkKT4gb24gaWc0aWljMQppY2hzbWIwOiA8SW50ZWwgQ29tZXQgTGFrZSBTTUJ1 cyBjb250cm9sbGVyPiBwb3J0IDB4ZWZhMC0weGVmYmYgbWVtIDB4NDA0YTEwYzAwMC0weDQwNGEx MGMwZmYgYXQgZGV2aWNlIDMxLjQgb24gcGNpMApzbWJ1czA6IDxTeXN0ZW0gTWFuYWdlbWVudCBC dXM+IG9uIGljaHNtYjAKdGFwMDogRXRoZXJuZXQgYWRkcmVzczogNTg6OWM6ZmM6MTA6ZmY6ODUK dGFwMTogRXRoZXJuZXQgYWRkcmVzczogNTg6OWM6ZmM6MTA6ZmY6OWMKYnJpZGdlMDogRXRoZXJu ZXQgYWRkcmVzczogNTg6OWM6ZmM6MTA6ZmY6ZjAKbG8wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8g VVAKdWJ0MCBvbiB1aHViMAp1YnQwOiA8dmVuZG9yIDB4ODA4NyBwcm9kdWN0IDB4MDAyNiwgY2xh c3MgMjI0LzEsIHJldiAyLjAxLzAuMDIsIGFkZHIgMz4gb24gdXNidXMwCmlpY2hpZDA6IDxTWU5B MzBCMTowMCAwNkNCOkNFMDcgSTJDIEhJRCBkZXZpY2U+IGF0IGFkZHIgMHgyYyBvbiBpaWNidXMw CmlpY2hpZDA6IEludGVycnVwdCBzZXR1cCBmYWlsZWQuIEZhbGxiYWNrIHRvIHNhbXBsaW5nCmhp ZGJ1czA6IDxISUQgYnVzPiBvbiBpaWNoaWQwCmhtczA6IDxTWU5BMzBCMTowMCAwNkNCOkNFMDcg TW91c2U+IG9uIGhpZGJ1czAKaG1zMDogMiBidXR0b25zIGFuZCBbWFldIGNvb3JkaW5hdGVzIElE PTIKaG10MDogPFNZTkEzMEIxOjAwIDA2Q0I6Q0UwNyBUb3VjaFBhZD4gb24gaGlkYnVzMApoY29u ZjA6IDxTWU5BMzBCMTowMCAwNkNCOkNFMDcgQ29uZmlndXJhdGlvbj4gb24gaGlkYnVzMApobXQw OiBNdWx0aXRvdWNoIHRvdWNocGFkIHdpdGggMCBleHRlcm5hbCBidXR0b25zLCBjbGljay1wYWQK aG10MDogNSBjb250YWN0cyB3aXRoIFtDXSBwcm9wZXJ0aWVzLiBSZXBvcnQgcmFuZ2UgWzA6MF0g LSBbMTI3Mjo2OTZdClNlY3VyaXR5IHBvbGljeSBsb2FkZWQ6IE1BQy9udHBkIChtYWNfbnRwZCkK d2xhbjA6IEV0aGVybmV0IGFkZHJlc3M6IDY4OjU0OjVhOjUyOjVlOjcyCml3bHdpZmkwOiBsa3Bp X3N0YV9zY2FuX3RvX2F1dGg6IHdhaXRpbmcgZm9yIDUgcXVldWVzIHRvIGJlIGFsbG9jYXRlZCBi eSBkcml2ZXIKd2xhbjA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUApJbnZhbGlkIFRYUSBpZAo= --=-=-=-- From nobody Mon Apr 4 17:59:23 2022 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 023291A8FC2F; Mon, 4 Apr 2022 17:59:38 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KXJSn3qfcz3NM4; Mon, 4 Apr 2022 17:59:37 +0000 (UTC) (envelope-from 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 234HxOg7068511; Mon, 4 Apr 2022 10:59:30 -0700 (PDT) (envelope-from bsd-lists@bsdforge.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 Date: Mon, 04 Apr 2022 10:59:23 -0700 From: Chris To: freebsd-wireless Cc: freebsd-current Subject: Which ath(4) cards are currently supported? User-Agent: UDNSMS/17.0 Message-ID: <4208488b364a91a6cc7d1e0aa746ae4f@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_f15d23a6d75a41dcda65f222ce99d78d" X-Rspamd-Queue-Id: 4KXJSn3qfcz3NM4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_f15d23a6d75a41dcda65f222ce99d78d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed OK I (mistakenly) picked up an Atheros 11ac mini-pcie card for a new laptop I picked up. But 80211ac isn't yet supported. :-( OK so what IS supported? ;-) I installed 13.1 and consulted RELEASE Hardware notes[1] which indicates: The ath(4) driver supports all Atheros Cardbus and PCI cards, except those that are based on the AR5005VL chipset. Which I think must be completely incorrect. As far as I can tell, with the exception of some hard work by bz@, FreeBSD WiFi is anywhere from 9-15yrs out. No 11ac or 11ax. WiFi-7 is also available, just not supported on FBSD. I not attempting to take shots here. Just trying to point out the fact that ath(4) doesn't cover all their chip-models as the RELEASE NOTES indicate. Does anyone have/provide a list? Does the SYNOPSIS in ath_hal(4) cover the entire list? Thank you for all your time, and consideration. 1. https://www.freebsd.org/releases/13.0R/hardware/ P.S. Mad props to Bjoern for his hard work on this! :-) --Chris --=_f15d23a6d75a41dcda65f222ce99d78d Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_f15d23a6d75a41dcda65f222ce99d78d-- From nobody Mon Apr 4 18:17:50 2022 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 56DF61A954DE; Mon, 4 Apr 2022 18:18:08 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KXJt73yngz3k6X; Mon, 4 Apr 2022 18:18:07 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-il1-x136.google.com with SMTP id y16so7496570ilc.7; Mon, 04 Apr 2022 11:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c5smCmq+14JwVQCK19RGLuPoTcXwVuGnrW1bmSbo2nU=; b=AT6FJ0WfPcLskDoemb5hTE4PPKa/KlCIVBpKers+o0jG1FypgQ3P392uhi/MjEqcS6 MbgjSTyhQ2+AE3ULGCuISE3NjXV51qxs1RdfiftDOOjqzar3hNgWP6r3IuDa0EO8shaa oqIcYbFYQuE+6YOW+lxZW1Rnt8kRVPRtFJWv5L1iDWPEJYlrMH9D9q78bpesajrgq9qt c7VlVWbnswvz2GxOOBTze1N+pyZA6g0MkK5OcCqEVvzE2+9TAFDC/oifau0oMCdtKk2N 3Rejs9y3/gQEXPy59TDwx8sM+2fRDjCGDv/UfgVwjckOW0LjeQQ0HhJ+woG0N81AphKH OgDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c5smCmq+14JwVQCK19RGLuPoTcXwVuGnrW1bmSbo2nU=; b=Z6hynqUt+kaBKhaouIc2C7T1+7pSg8Fs5gnndg6QqPOBzdbCTZR9JqmxgkSF7uvieq u8SCVsD0TZl/Dzn4wDvkiUitN5Vu4l9/v5g0RQ+M5DM7E8icQmT2cz96Rdd13j8ogNkS 4LpuinkDiVPC3JOMOex6DRDa7Wno8w8/RyG2aX1UAm4iDfCbblKqLzqAGwLwzWDw/CpG 1SvvWxIwfQqss5cYfdGLJEzzWNBsU59CvtTbRONYghWlYRLQ+aj+V5vQydflyS3EjdSt 1iS99//V8KVMwgleEYK/2JFhywsrWcuy60avMFukOCyvLgARfnQLLNPcthSlvqY+eKE3 QLNQ== X-Gm-Message-State: AOAM533Iq1j2a+UTRIzkTZjQcs5AzZEHw99OAb83VUv9vneAFvTb6gaW TXwX9FpdNIrtHxnpYSirqvEJYUELy8czclYL1Dm5ycbV X-Google-Smtp-Source: ABdhPJySk5r4Bj5uoIu0qiwpsj1piBy4FJpfdHPhg59k2iuxtLDIVIEiVzsMTFB1/X9//euUROmdexqfvNQ6KIwiAyo= X-Received: by 2002:a92:602:0:b0:2ca:480a:c19d with SMTP id x2-20020a920602000000b002ca480ac19dmr505649ilg.223.1649096281476; Mon, 04 Apr 2022 11:18: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: <4208488b364a91a6cc7d1e0aa746ae4f@bsdforge.com> In-Reply-To: <4208488b364a91a6cc7d1e0aa746ae4f@bsdforge.com> From: Freddie Cash Date: Mon, 4 Apr 2022 11:17:50 -0700 Message-ID: Subject: Re: Which ath(4) cards are currently supported? To: Chris Cc: freebsd-wireless , freebsd-current Content-Type: multipart/alternative; boundary="0000000000000ed39205dbd826b3" X-Rspamd-Queue-Id: 4KXJt73yngz3k6X X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=AT6FJ0Wf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of fjwcash@gmail.com designates 2607:f8b0:4864:20::136 as permitted sender) smtp.mailfrom=fjwcash@gmail.com X-Spamd-Result: default: False [-2.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.00)[-0.997]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::136:from]; MLMMJ_DEST(0.00)[freebsd-wireless,freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000000ed39205dbd826b3 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 4, 2022 at 11:01 AM Chris wrote: > OK I (mistakenly) picked up an Atheros 11ac mini-pcie card for a new > laptop I picked up. But 80211ac isn't yet supported. :-( > OK so what IS supported? ;-) I installed 13.1 and consulted RELEASE > Hardware notes[1] which indicates: > The ath(4) driver supports all Atheros Cardbus and PCI cards, except > those that are based on the AR5005VL chipset. > Note: PCI means PCI, not PCIe. :) The ath(4) driver supports the old PCI and CardBus adapters. It doesn't support PCIe, USB, M.2, or other formfactor adapters. While slightly ambiguous, the hardware notes are technically correct. -- Freddie Cash fjwcash@gmail.com --0000000000000ed39205dbd826b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 4, 2022 at 11:01 AM Chris <= ;bsd-lists@bsdforge.com> w= rote:
OK I (mistakenly) picked up an Atheros 11ac mini-pcie card= for a new
laptop I picked up. But 80211ac isn't yet supported. :-(
OK so what IS supported? ;-) I installed 13.1 and consulted RELEASE
Hardware notes[1] which indicates:
The ath(4) driver supports all Atheros Cardbus and PCI cards, except
those that are based on the AR5005VL chipset.

Note:=C2=A0 PCI means PCI, not PCIe.=C2=A0= :)=C2=A0 The ath(4) driver supports the old PCI and CardBus adapters.=C2= =A0 It doesn't support PCIe, USB, M.2, or other formfactor adapters.

While slightly ambiguous, the hardware notes are tec= hnically correct.

--
Freddie Cash
fjwcash@gmail.com
--0000000000000ed39205dbd826b3-- From nobody Mon Apr 4 19:30:36 2022 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 BB58A1A85564; Mon, 4 Apr 2022 19:30:44 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KXLTw42Fyz4S91; Mon, 4 Apr 2022 19:30:44 +0000 (UTC) (envelope-from 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 234JUbSW065392; Mon, 4 Apr 2022 12:30:43 -0700 (PDT) (envelope-from bsd-lists@bsdforge.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 Date: Mon, 04 Apr 2022 12:30:36 -0700 From: Chris To: Freddie Cash Cc: freebsd-wireless , freebsd-current Subject: Re: Which ath(4) cards are currently supported? In-Reply-To: References: <4208488b364a91a6cc7d1e0aa746ae4f@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_15b27ce574c0b8df4e83587863da1e76" X-Rspamd-Queue-Id: 4KXLTw42Fyz4S91 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_15b27ce574c0b8df4e83587863da1e76 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-04-04 11:17, Freddie Cash wrote: > On Mon, Apr 4, 2022 at 11:01 AM Chris wrote: > >> OK I (mistakenly) picked up an Atheros 11ac mini-pcie card for a new >> laptop I picked up. But 80211ac isn't yet supported. :-( >> OK so what IS supported? ;-) I installed 13.1 and consulted RELEASE >> Hardware notes[1] which indicates: >> The ath(4) driver supports all Atheros Cardbus and PCI cards, except >> those that are based on the AR5005VL chipset. >> > > Note: PCI means PCI, not PCIe. :) The ath(4) driver supports the old PCI > and CardBus adapters. It doesn't support PCIe, USB, M.2, or other > formfactor adapters. > > While slightly ambiguous, the hardware notes are technically correct. Sure OK. I simply moved down to the "Wireless Network Interfaces" to see if I could discover exactly *which* Atheros numbers I could safely buy to use FreeBSD effectively on my new laptop. You know; like: Atheros m.2. Which I could then compare to those indicated by FreeBSD as being supported. Oh well. I guess I'm stuck with the numbers given on the ath_hal(4) man page. Maybe that's the complete list? Thanks for taking the time to reply, Freddie! :-) --Chris --=_15b27ce574c0b8df4e83587863da1e76 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_15b27ce574c0b8df4e83587863da1e76-- From nobody Tue Apr 5 15:36:18 2022 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 ECC371A9B9E1 for ; Tue, 5 Apr 2022 15:36:26 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KXsF547Hsz4q0p for ; Tue, 5 Apr 2022 15:36:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 235FaJMK035885 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 5 Apr 2022 08:36:19 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 235FaIKT035884; Tue, 5 Apr 2022 08:36:18 -0700 (PDT) (envelope-from fbsd) Date: Tue, 5 Apr 2022 08:36:18 -0700 From: bob prohaska To: freebsd-current@freebsd.org Cc: bob prohaska Subject: Buildworld stops with ld: error: undefined symbol: AcpiWarning on -current Message-ID: <20220405153618.GA35843@www.zefox.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4KXsF547Hsz4q0p X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [-1.09 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N A Pi3 running -current is stopping with ld: error: undefined symbol: AcpiWarning during buildworld. The sources are up-to- date as of a few minutes ago. A series of related "Acpi..." errors follow. The build command line is make -j2 -DWITH_META_MODE buildworld > buildworld.log Thanks for reading, bob prohaska From nobody Mon Apr 11 15:17:03 2022 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 765151AB1271 for ; Mon, 11 Apr 2022 15:17:16 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KcXXC0xkWz3lN9 for ; Mon, 11 Apr 2022 15:17:15 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.109, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, T_SCC_BODY_TEXT_LINE -0.01, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 23BFH3nC022289 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [10.14.0.14] (static-198-54-132-57.cust.tzulo.com [198.54.132.57]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 23BFH3nC022289 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 11 Apr 2022 11:17:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1649690225; bh=66+7i0A3Nq+AAHh+5CDOsZJ1b5uMvNAr3JmzClwOtW0=; h=Date:To:From:Subject:From; b=FSluy7ezf9nLUc4g2U+czoiLLAKolSfNIlZGw8lVJkt/xXIaLUXjlyo4stysWMlK7 NNOHoNWNOu6wKYOWEbGWHbQ/v+BpcinvYFrrn+Cry1Shi5pvmy/QyBDAT3TS1+xVlW 9iWLJmbjvN+o2LVYqByCK45OognSKg6oGDiZjOK+yScJ66meOoDqoObrtWGOagUSdu ZDvSiX50OdbNFG4dvK27fNL72ryTeLLqjTQFGA4BRgSmYq8IKPeNgGfMdN0PV6hkfJ hsGFE+okUeWurDmUpZl1uCREnYwQgrZL4JOEIbT9c6wzKqqH/uaThIUnH/kKtMvb3L gGrPFSmCbjIZQ== Message-ID: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> Date: Mon, 11 Apr 2022 11:17:03 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: freebsd-current@freebsd.org Content-Language: en-US From: Dennis Clarke Subject: main-n254654-d4e8207317c results in "no pools available to import" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KcXXC0xkWz3lN9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=FSluy7ez; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[blastwave.org:+]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Did the usual git pull origin main and buildworld/buildkernel but after installkernel the machine will not boot. The rev seems to be main-n254654-d4e8207317c. I can boot single user mode and get a command prompt but nothing past that. Is there something borked in ZFS in CURRENT ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From nobody Mon Apr 11 18:18:48 2022 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 0A5DA11D036D for ; Mon, 11 Apr 2022 18:20:13 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 4KccbJ09zvz4ywW for ; Mon, 11 Apr 2022 18:20:11 +0000 (UTC) (envelope-from ronald-lists@klop.ws) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References: To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=h0HR1Y8pLasgHIo6znPpajQPdYFzdwayitHhkI50/gE=; b=piiHvCzDV93WFLLrpNHzlLmDNX ytWrkRYEQ0oUIWNLTmIh6HlUbd6yphE/8oyFHIB/G9B7rDd5QcN3CtY58jntyTsrrd5qQFMiVWD58 qAV2EfST2euxOmQZi8cQhlzftaoy4msn3JTcBmOoqy0WOuZMXMb/bDQ4kmmRerDRUE2M=; Message-ID: Date: Mon, 11 Apr 2022 20:18:48 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> From: Ronald Klop In-Reply-To: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.greenhost.nl X-Spam-Level: -- X-Spam-Score: -2.0 X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.2 X-Scan-Signature: 645486d610a00fe5591aab0f6aa1616b X-Rspamd-Queue-Id: 4KccbJ09zvz4ywW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=mail header.b=piiHvCzD; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=mail]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RWL_MAILSPIKE_EXCELLENT(0.00)[195.190.28.88:from]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from]; NEURAL_HAM_SHORT(-0.99)[-0.989]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/11/22 17:17, Dennis Clarke wrote: > > Did the usual git pull origin main and buildworld/buildkernel but after installkernel the machine will not boot. > > The rev seems to be main-n254654-d4e8207317c. > > I can boot single user mode and get a command prompt but nothing past > that. Is there something borked in ZFS in CURRENT ? > > > Up until now you are the only one with this error on the mailinglist today. So I doubt something is borked. You could consider to share more details about your setup to help people to think along with you. Regards, Ronald. From nobody Mon Apr 11 21:50:05 2022 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 D9B1111CE30D for ; Mon, 11 Apr 2022 21:50:24 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KcjFq4GyPz3ttL for ; Mon, 11 Apr 2022 21:50:22 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-31-137.area1b.commufa.jp [123.1.31.137]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 23BLo5i7095619; Tue, 12 Apr 2022 06:50:06 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 12 Apr 2022 06:50:05 +0900 From: Tomoaki AOKI To: Ronald Klop , Dennis Clarke Cc: freebsd-current@freebsd.org Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Message-Id: <20220412065005.235e5327a18cef8a49f43c8f@dec.sakura.ne.jp> In-Reply-To: References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KcjFq4GyPz3ttL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [0.40 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.31.137:received] X-ThisMailContainsUnwantedMimeParts: N On Mon, 11 Apr 2022 20:18:48 +0200 Ronald Klop wrote: > On 4/11/22 17:17, Dennis Clarke wrote: > > > > Did the usual git pull origin main and buildworld/buildkernel but after installkernel the machine will not boot. > > > > The rev seems to be main-n254654-d4e8207317c. > > > > I can boot single user mode and get a command prompt but nothing past > > that. Is there something borked in ZFS in CURRENT ? > > > > > > > > > Up until now you are the only one with this error on the mailinglist today. So I doubt something is borked. > You could consider to share more details about your setup to help people to think along with you. > > Regards, > Ronald. > I have main at git c79331a42c308139828c1117f49224bb83617a53 booting fine, and no commits relatd with ZFS exists within git d4e8207317c. So the info at which commit was running before update would be needed. I've encountered the situation like that, but it was far before OpenZFS was introduced into base. If it's the same issue, /sbin/zfs SHALL be updated in conjunction with kernel. *ATM, interface between kernel (or zfs.ko) and /sbin/zfs was changed. If you can boot with any emergency environment (memstick or another installation) and import now-non-bootable pool with e.g. `zpool import -R /mnt -f ZPOOL`, `cp /mnt/usr/obj/usr/src/[your.arch]/cddl/sbin/zfs/zfs /mnt/sbin/` then exporting the pool would be worth trying. Beware! If other updated components are mandatory for /sbin/zfs, the above procedure is not at all enough. But would crash before actually the pool is imported. -- Tomoaki AOKI From nobody Mon Apr 11 21:51:03 2022 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 0423311CF8A5 for ; Mon, 11 Apr 2022 21:51:15 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KcjGp1Kwwz3vPj for ; Mon, 11 Apr 2022 21:51:14 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.721, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -1.62, T_FILL_THIS_FORM_SHORT 0.01, T_SCC_BODY_TEXT_LINE -0.01, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 23BLp3ff003840 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [10.14.0.14] (static-198-54-132-57.cust.tzulo.com [198.54.132.57]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 23BLp3ff003840 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 11 Apr 2022 17:51:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1649713865; bh=4g+JRBuYCQ3VHNzc9RN7wSscW0i3EkPsVevCwwp8cdY=; h=Date:Subject:To:References:From:In-Reply-To:From; b=MDZ9w/bdzZjehWUsxqMVTOgv0+KcyiA2RWtjhZKFtEm8vndD7/0IE5g385dKBU45I 5Wl9/kN6AT0tQ1IoNIQeBDi1Is4p0UlgQ03QX4V53plGuAjSaeT8O2hodTi3VID4gM n21PcBelIoQ5quCiqzUe9WssFkgtelvWcMChST1cUuNbCGoO4o6iY9KjjSS0+jLZIG sXDTCDPwG3S1T0fEBdL/jd+eRdf5UZZMMDHBWmWeM1VT/eO01WBvgKUPRd/3VheWU1 nlSm/EuaIc586FcPfX0MMPWwYS9lDb3v9MuSF0Sy5dO/LCEYO+c6LvZgrz/uUqUHUx 8KGrRtsVYItXg== Message-ID: <3f666c51-d884-9b8f-04ff-bb0edf57f37a@blastwave.org> Date: Mon, 11 Apr 2022 17:51:03 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> From: Dennis Clarke In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KcjGp1Kwwz3vPj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b="MDZ9w/bd"; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[blastwave.org:+]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > > Up until now you are the only one with this error on the mailinglist > today. So I doubt something is borked. > You could consider to share more details about your setup to help people > to think along with you. > Nothing remotely interesting. I managed to boot kernel.old from the boot loader and reverted to : root@phobos:/usr/src # root@phobos:/usr/src # uname -apKU FreeBSD phobos 14.0-CURRENT FreeBSD 14.0-CURRENT #4 main-n253712-0784121c963: Fri Mar 11 03:59:31 UTC 2022 root@phobos:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400053 1400053 root@phobos:/usr/src # Where the zpool is the lone NVME device in this Lenovo laptop : root@phobos:/usr/src # zpool status pool: c3 state: ONLINE status: Some supported and requested features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(7) for details. config: NAME STATE READ WRITE CKSUM c3 ONLINE 0 0 0 nvd0p4 ONLINE 0 0 0 errors: No known data errors root@phobos:/usr/src # That is an interesting message about the zpool there. So zpool upgrade -v says : root@phobos:/usr/src # root@phobos:/usr/src # zpool upgrade -v This system supports ZFS pool feature flags. The following features are supported: FEAT DESCRIPTION ------------------------------------------------------------- async_destroy (read-only compatible) Destroy filesystems asynchronously. empty_bpobj (read-only compatible) Snapshots use less space. lz4_compress LZ4 compression algorithm support. multi_vdev_crash_dump Crash dumps to multiple vdev pools. spacemap_histogram (read-only compatible) Spacemaps maintain space histograms. enabled_txg (read-only compatible) Record txg at which a feature is enabled hole_birth Retain hole birth txg for more precise zfs send extensible_dataset Enhanced dataset functionality, used by other features. embedded_data Blocks which compress very well use even less space. bookmarks (read-only compatible) "zfs bookmark" command filesystem_limits (read-only compatible) Filesystem and snapshot limits. large_blocks Support for blocks larger than 128KB. large_dnode Variable on-disk size of dnodes. sha512 SHA-512/256 hash algorithm. skein Skein hash algorithm. edonr Edon-R hash algorithm. userobj_accounting (read-only compatible) User/Group object accounting. encryption Support for dataset level encryption project_quota (read-only compatible) space/object accounting based on project ID. device_removal Top-level vdevs can be removed, reducing logical pool size. obsolete_counts (read-only compatible) Reduce memory used by removed devices when their blocks are freed or remapped. zpool_checkpoint (read-only compatible) Pool state can be checkpointed, allowing rewind later. spacemap_v2 (read-only compatible) Space maps representing large segments are more efficient. allocation_classes (read-only compatible) Support for separate allocation classes. resilver_defer (read-only compatible) Support for deferring new resilvers when one is already running. bookmark_v2 Support for larger bookmarks redaction_bookmarks Support for bookmarks which store redaction lists for zfs redacted send/recv. redacted_datasets Support for redacted datasets, produced by receiving a redacted zfs send stream. bookmark_written Additional accounting, enabling the written# property (space written since a bookmark), and estimates of send stream sizes for incrementals from bookmarks. log_spacemap (read-only compatible) Log metaslab changes on a single spacemap and flush them periodically. livelist (read-only compatible) Improved clone deletion performance. device_rebuild (read-only compatible) Support for sequential mirror/dRAID device rebuilds zstd_compress zstd compression algorithm support. draid Support for distributed spare RAID zilsaxattr (read-only compatible) Support for xattr=sa extended attribute logging in ZIL. The following legacy versions are also supported: VER DESCRIPTION --- -------------------------------------------------------- 1 Initial ZFS version 2 Ditto blocks (replicated metadata) 3 Hot spares and double parity RAID-Z 4 zpool history 5 Compression using the gzip algorithm 6 bootfs pool property 7 Separate intent log devices 8 Delegated administration 9 refquota and refreservation properties 10 Cache devices 11 Improved scrub performance 12 Snapshot properties 13 snapused property 14 passthrough-x aclinherit 15 user/group space accounting 16 stmf property support 17 Triple-parity RAID-Z 18 Snapshot user holds 19 Log device removal 20 Compression using zle (zero-length encoding) 21 Deduplication 22 Received properties 23 Slim ZIL 24 System attributes 25 Improved scrub stats 26 Improved snapshot deletion performance 27 Improved snapshot creation performance 28 Multiple vdev replacements For more information on a particular version, including supported releases, see the ZFS Administration Guide. root@phobos:/usr/src # Where the zpool version info says : root@phobos:/usr/src # root@phobos:/usr/src # zpool version zfs-2.1.99-FreeBSD_g17b2ae0b2 zfs-kmod-2.1.99-FreeBSD_g17b2ae0b2 root@phobos:/usr/src # A zfs list shows the usual stuff : root@phobos:/usr/src # zfs list -o name,used,avail,usedbysnapshots,mounted,mountpoint NAME USED AVAIL USEDSNAP MOUNTED MOUNTPOINT c3 120G 326G 808K yes /c3 c3/ROOT 44.6G 326G 0B no none c3/ROOT/default 44.6G 326G 40.1G yes / c3/opt 13.6M 326G 3.17M yes /opt c3/tmp 2.59M 326G 2.48M yes /tmp c3/usr 75.0G 326G 0B no /usr c3/usr/home 2.21G 326G 126M yes /usr/home c3/usr/obj 63.4G 326G 52.8G yes /usr/obj c3/usr/ports 2.34G 326G 561M yes /usr/ports c3/usr/src 7.05G 326G 4.88G yes /usr/src c3/var 14.8M 326G 0B no /var c3/var/audit 944K 326G 848K yes /var/audit c3/var/crash 544K 326G 448K yes /var/crash c3/var/log 7.76M 326G 6.80M yes /var/log c3/var/mail 2.35M 326G 2.07M yes /var/mail c3/var/tmp 3.16M 326G 3.03M yes /var/tmp root@phobos:/usr/src # All filesystems are compressed with a sha512 checksum everywhere. I am using zstd compression but nothing oddball : root@phobos:/usr/src # zfs list -o name,used,avail,compression,mounted,mountpoint NAME USED AVAIL COMPRESS MOUNTED MOUNTPOINT c3 120G 326G lz4 yes /c3 c3/ROOT 44.6G 326G lz4 no none c3/ROOT/default 44.6G 326G lz4 yes / c3/opt 13.6M 326G zstd yes /opt c3/tmp 2.59M 326G lz4 yes /tmp c3/usr 75.0G 326G lz4 no /usr c3/usr/home 2.21G 326G lz4 yes /usr/home c3/usr/obj 63.4G 326G on yes /usr/obj c3/usr/ports 2.34G 326G lz4 yes /usr/ports c3/usr/src 7.05G 326G lz4 yes /usr/src c3/var 14.8M 326G lz4 no /var c3/var/audit 944K 326G lz4 yes /var/audit c3/var/crash 544K 326G lz4 yes /var/crash c3/var/log 7.76M 326G lz4 yes /var/log c3/var/mail 2.35M 326G lz4 yes /var/mail c3/var/tmp 3.16M 326G lz4 yes /var/tmp root@phobos:/usr/src # There are some snapshots on all filesystems : root@phobos:/usr/src # zfs list -o name,used,avail,usedbysnapshots,mounted,mountpoint -t all -r c3/var/tmp NAME USED AVAIL USEDSNAP MOUNTED MOUNTPOINT c3/var/tmp 3.16M 326G 3.03M yes /var/tmp c3/var/tmp@20211209104512 76K - - - - c3/var/tmp@20211209105732 68K - - - - c3/var/tmp@20211209110035 76K - - - - c3/var/tmp@20211226221122 68K - - - - c3/var/tmp@20220117113614 92K - - - - c3/var/tmp@20220118005539 76K - - - - c3/var/tmp@20220118005944 84K - - - - c3/var/tmp@20220120090537 76K - - - - c3/var/tmp@20220121024902 76K - - - - c3/var/tmp@20220121031721 76K - - - - c3/var/tmp@20220121033412 84K - - - - c3/var/tmp@20220121035649 76K - - - - c3/var/tmp@20220121040118 84K - - - - c3/var/tmp@20220121042929 76K - - - - c3/var/tmp@20220130114038 84K - - - - c3/var/tmp@20220130115954 76K - - - - c3/var/tmp@20220130121000 84K - - - - c3/var/tmp@20220226222228 84K - - - - c3/var/tmp@20220227211856 84K - - - - c3/var/tmp@20220228045355 92K - - - - c3/var/tmp@20220228180052 76K - - - - c3/var/tmp@20220228181542 76K - - - - c3/var/tmp@20220302194101 76K - - - - c3/var/tmp@20220306070845 84K - - - - c3/var/tmp@20220306080502 84K - - - - c3/var/tmp@20220306215850 84K - - - - c3/var/tmp@20220306220437 76K - - - - c3/var/tmp@20220306221245 76K - - - - c3/var/tmp@20220307003647 84K - - - - c3/var/tmp@20220310144525 92K - - - - c3/var/tmp@20220311030047 84K - - - - c3/var/tmp@20220311044203 84K - - - - c3/var/tmp@20220311044643 84K - - - - c3/var/tmp@20220311163309 84K - - - - c3/var/tmp@20220316134056 84K - - - - c3/var/tmp@20220316160003 84K - - - - c3/var/tmp@20220318012900 84K - - - - c3/var/tmp@20220410063610 84K - - - - root@phobos:/usr/src # Not sure what else to say. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From nobody Mon Apr 11 21:59:20 2022 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 5380311DA5C8 for ; Mon, 11 Apr 2022 21:59:37 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KcjSS4Hbpz4Ryh for ; Mon, 11 Apr 2022 21:59:36 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.731, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -1.62, T_SCC_BODY_TEXT_LINE -0.01, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 23BLxKaU003994 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [10.14.0.14] (static-198-54-132-57.cust.tzulo.com [198.54.132.57]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 23BLxKaU003994 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 11 Apr 2022 17:59:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1649714363; bh=2uie6wP9pQeXUeaiso3qy4DbRGKgy1tWz0LmRjojVXk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=gIFtVX+AsM2pUjaS1XsCAFE16oKLdFW+XhJKqOkOIKv3D6/h4R6KH+h9tmc+sCOHB 1e4G8T/tCTiLvRo6q3LEGY70qeo8IexuZjOBOppBmcooxo2rrxxW+4Et9JBOwWnj1M ADVj1JfXFngm2SmIfbsshQB9TgGTNK4pcbL6XqcYlP5/2mDLbMXN4bxuPTIfsGxveq Go92ISVaokS7cZTluR4bDS0gX7QdMhNphvAgA/CYBfgWFKhpaeQtPztqe8vMPN5GpZ FMvxDEfsma3EKBIw38c/XN6CUYsp/quk4BazFNrMq+RZSV4X913nO0hTu9aeY3z7sq K08xwIFz0NkGA== Message-ID: <689aaba0-52bb-741b-2da0-abbd60670c6e@blastwave.org> Date: Mon, 11 Apr 2022 17:59:20 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: Tomoaki AOKI , Ronald Klop Cc: freebsd-current@freebsd.org References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> <20220412065005.235e5327a18cef8a49f43c8f@dec.sakura.ne.jp> From: Dennis Clarke In-Reply-To: <20220412065005.235e5327a18cef8a49f43c8f@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KcjSS4Hbpz4Ryh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=gIFtVX+A; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [-4.17 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[blastwave.org:+]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-0.47)[-0.466]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/11/22 17:50, Tomoaki AOKI wrote: > On Mon, 11 Apr 2022 20:18:48 +0200 > Ronald Klop wrote: > >> On 4/11/22 17:17, Dennis Clarke wrote: >>> >>> Did the usual git pull origin main and buildworld/buildkernel but after installkernel the machine will not boot. >>> >>> The rev seems to be main-n254654-d4e8207317c. >>> >>> I can boot single user mode and get a command prompt but nothing past >>> that. Is there something borked in ZFS in CURRENT ? >>> >>> >>> >> >> >> Up until now you are the only one with this error on the mailinglist today. So I doubt something is borked. >> You could consider to share more details about your setup to help people to think along with you. >> >> Regards, >> Ronald. >> > > I have main at git c79331a42c308139828c1117f49224bb83617a53 booting > fine, and no commits relatd with ZFS exists within git d4e8207317c. I was just looking at that and there is one : root@phobos:/usr/src # root@phobos:/usr/src # /usr/local/bin/git --no-pager log -n 32 --pretty=oneline --abbrev-commit --graph * d4e8207317c (HEAD -> main, origin/main, origin/HEAD) vmm_instruction_emul.c: fix bhyve build * be0d16b0b05 bsdinstall: filter out disks that are unavailable from the list of options in ZFS * 5580e5bd716 nfscl: Clean up the code by removing unused arguments * 5a17f489d58 vmm: fix set but not used warning * 5241577a223 vmm: fix set but not used warning * 3587bfa797c vmm: fix set but not used warning * 5c272efaba2 vmm: fix set but not used warnings * f877977a034 vmm: fix set but not used warnings * 893a3dd697e vmm: fix set but not used warning * f3ef799f564 Only return a mapped address from efi_phys_to_kva * 57e47ae514b Include the EFI Runtime Code in the DMAP * bde57090337 UPDATING: Fix a few typos * c79331a42c3 bhyve: use linker set for ipc commands * 38c3cf6aede nfscl: Clean up the code by removing unused arguments * c45d934f6b7 nfscl: Ansify a function header * bd8701dede1 Document procstat(1) advlock command * a5229a255ea Implement procstat(1) advlocks command * e79866ddf1c procstat(1): add ability to specify subcommands not requiring pid lists * 50d3c72558f libprocstat: document procstat_getadvlock(3) * 039d1496b07 libprocstat: add procstat_getadvlock(3) * eca39864f70 Add sysctl KERN_LOCKF * 6ead1379fd4 sys/user.h: Add kinfo_lockf structure to report advisory locks * 147e4fe3f1f kern_lockf.c: remove no longer neeeded UFS headers * 59e85819be6 lockf: remove lf_inode from struct lockf_entry * 5c075d64049 ufs/acl.h: forward-declare struct inode * 8cc19b1e47d Style. * a3214fbe7ff mount: use pidfile_signal * 287451fd019 pidfile: add pidfile_signal * ecbdfbfd18d netgraph(3): Remove a double word in a source code comment * d048e8c6196 ofed: Fix a typo in a source code comment * 299fcf402dc fsck_ffs(8): Fix a typo in a source code comment * 009727ed577 routed(8): Remove a double word in a source code comment root@phobos:/usr/src # I see be0d16b0b05 bsdinstall: filter out disks that are unavailable from the list of options in ZFS Not sure what that does however. I am looking at : root@phobos:/usr/src # git pull origin main remote: Enumerating objects: 100, done. remote: Counting objects: 100% (16/16), done. remote: Compressing objects: 100% (3/3), done. remote: Total 100 (delta 13), reused 13 (delta 13), pack-reused 84 Receiving objects: 100% (100/100), 189.37 KiB | 1.38 MiB/s, done. Resolving deltas: 100% (57/57), completed with 12 local objects. From git.freebsd.org:src * branch main -> FETCH_HEAD d4e8207317c..673bce11ced main -> origin/main Updating d4e8207317c..673bce11ced Fast-forward lib/libc/sys/getdirentries.2 | 2 ++ sbin/ifconfig/ifconfig.8 | 5 +++-- stand/man/loader_lua.8 | 47 +++++++++++++++++++++++------------------------ sys/compat/linprocfs/linprocfs.c | 20 ++++++++++++++++++++ sys/compat/linux/linux_socket.c | 38 +++++++++++++++++++++++++++++--------- sys/compat/linux/linux_socket.h | 1 + sys/dev/axgbe/if_axgbe_pci.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++------------- sys/kern/vfs_subr.c | 1 + sys/kern/vfs_syscalls.c | 4 ++++ sys/netinet/ip_mroute.c | 26 ++++++++++++++++++++------ sys/netinet/ip_output.c | 2 +- sys/netinet6/ip6_output.c | 2 ++ sys/netpfil/ipfw/ip_fw2.c | 27 ++++++++++++--------------- sys/netpfil/ipfw/ip_fw_log.c | 7 +++++-- sys/netpfil/pf/pf_ioctl.c | 2 ++ sys/sys/vnode.h | 2 +- sys/vm/swap_pager.c | 4 ++-- 17 files changed, 180 insertions(+), 75 deletions(-) root@phobos:/usr/src # /usr/local/bin/git --no-pager log -n 32 --pretty=oneline --abbrev-commit --graph * 673bce11ced (HEAD -> main, origin/main, origin/HEAD) linux(4): Copyout actual size of addr to the user space in accept(). * bb0f644cd68 linux(4): Limit user-supplied sockaddr length in recvfrom(). * 68bfaefb3d9 linux(4): Remove unnecessary PTRIN(). * cf312f799a8 linux(4): Handle SO_DOMAIN in getsockopt syscall. * c6487446d7e getdirentries: return ENOENT for unlinked but still open directory. * bb46e9b5107 linux(4): Prevent an attempt to copy an uninitialized source address. * 6ca0ca7b4cb IPv4 multicast: fix LOR in shutdown path * 8e458a431eb Clean up some grammos I left behind. * 67f5810e07c Correct typos and more precise wording. * 632ea8ea984 ifconfig.8: Note that -l accepts -g in addition to -d and -u . . . . So again nothing from yesterday until today that says a word about ZFS. > So the info at which commit was running before update would be needed. > > I've encountered the situation like that, but it was far before OpenZFS > was introduced into base. If it's the same issue, /sbin/zfs SHALL be > updated in conjunction with kernel. > Right. I have seen it also but that was a long long time ago. Relatively speaking and OpenZFS has never been an issue. I wish I had a serial interface on the little laptop to boot to single usermode with and then can look around and capture the output. > If you can boot with any emergency environment (memstick or another > installation) and import now-non-bootable pool with e.g. `zpool import > -R /mnt -f ZPOOL`, I have been through that before and usually it was just to import a strange zpool from some other storage array onto some other machine. I don't think that is needed here. > Beware! If other updated components are mandatory for /sbin/zfs, the > above procedure is not at all enough. But would crash before actually > the pool is imported. Yep. Let's avoid that. I am going to see if I can build to commit 3587bfa797c on some other hardware and have a look. Just because I am curious. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From nobody Tue Apr 12 08:41:50 2022 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 90E3C11DE204 for ; Tue, 12 Apr 2022 08:41:58 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kczjd484kz3NYY for ; Tue, 12 Apr 2022 08:41:57 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.731, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -1.62, T_SCC_BODY_TEXT_LINE -0.01, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 23C8foNx021190 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [10.14.0.14] (static-198-54-132-57.cust.tzulo.com [198.54.132.57]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 23C8foNx021190 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 12 Apr 2022 04:41:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1649752912; bh=JYaRZ2RtdjVz3VjDAmX3QJvulrc7KMZNs6j69a/2T64=; h=Date:Subject:To:References:From:In-Reply-To:From; b=H2LjbXNYIN+JfTN69ae+VRuWmXa83aiV2Gu9T1xooGHEMAzqvVa9OrT4c9vREqOYh OeG0awqrQwU/4WIFvlQLVlMKfbBitP1qWuvtqW0b22NATqNGQ2mFSK/ZJDw4ovEG+G 76+adFvOiXANbk9vZddVZGMqE3sYwouJ1bGchgs8uAn3sM5kM18IHwZkFW+bKOG17G l040hS8Qj300Q1hW3Ge53mYLbEQunGt9ZE+5eCkxlXc4I83ajsgHNZo7vsEDvZmnpw zZR9uabqvk/OBUnrFUP46Vlk1QjD4zlVmzyjEDgYcs+dvsPzK7lCs9Qisjw7AYdkr4 3e0aKGNDcNiYw== Message-ID: <72bcb8cc-e3d7-77d8-a0b5-4bb351921d24@blastwave.org> Date: Tue, 12 Apr 2022 04:41:50 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> From: Dennis Clarke In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Kczjd484kz3NYY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=H2LjbXNY; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [-4.70 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[blastwave.org:+]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/11/22 14:18, Ronald Klop wrote: > On 4/11/22 17:17, Dennis Clarke wrote: >> >> Did the usual git pull origin main and buildworld/buildkernel but >> after installkernel the machine will not boot. >> >> The rev seems to be main-n254654-d4e8207317c. >> >> I can boot single user mode and get a command prompt but nothing past >> that. Is there something borked in ZFS in CURRENT ? >> >> >> > > > Up until now you are the only one with this error on the mailinglist > today. So I doubt something is borked. > You could consider to share more details about your setup to help people > to think along with you. > > Regards, > Ronald. I am officially baffled. I installed latest CURRENT snapshot on another system and then buildworld and buildkernel after checkout of d4e8207317c. At reboot, with a serial console I can get to single user mode no problem : . . . cd0 at ahcich3 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number K18C36A0237 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-4 ATA SATA 3.x device ada0: Serial Number S5VSNG0NB12944W ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors) ses0: pass0,ada0 in 'Slot 00', SATA Slot: scbus0 target 0 ses0: pass1,cd0 in 'Slot 03', SATA Slot: scbus3 target 0 GEOM: new disk ada0 Root mount waiting for: usbus0 uhub0: 26 ports with 26 removable, self powered ugen0.2: at usbus0 efirtc0: providing initial system time start_init: trying /sbin/init Enter root password, or ^D to go multi-user Password: Enter full pathname of shell or RETURN for /bin/sh: root@:/ # uname -apKU FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 d4e8207317c-n254654-d4e8207317c: Tue Apr 12 08:10:00 UTC 2022 root@europa:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400056 1400056 root@:/ # When I go to full multi-user mode I see the same message "no pools available to import" but the machine comes up just fine : root@:/ # exit Setting hostuuid: 688682c8-76df-3f6f-3af4-b06ebf2eb755. Setting hostid: 0xc646c1f3. no pools available to import Fast boot: skipping disk checks. Mounting local filesystems:. Autoloading module: acpi_wmi AuACPI: Processor \_PR_.CPU2 (ACPI ID 3) ignored ACPI: Processor \_PR_.CPU3 (ACPI ID 4) ignored ACPI: Processor \_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \_PR_.CPU7 (ACPI ID 8) ignored acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device acpi_wmi0: Embedded MOF found ACPI: \AMW0.WQMO: 1 arguments were passed to a non-method ACPI object (Buffer) (20220331/nsarguments-361) acpi_wmi1: on acpi0 acpi_wmi1: cannot find EC device pci0: driver added found-> vendor=0x8086, dev=0xa2ba, revid=0x00 domain=0, bus=0, slot=22, func=0 class=07-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit pci0:0:22:0: reprobing on driver added found-> vendor=0x8086, dev=0xa2a1, revid=0x00 domain=0, bus=0, slot=31, func=2 class=05-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pci0:0:31:2: reprobing on driver added found-> vendor=0x8086, dev=0xa2a3, revid=0x00 domain=0, bus=0, slot=31, func=4 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 pci0:0:31:4: reprobing on driver added ichsmb0: port 0xf040-0xf05f mem 0xf712a000-0xf712a0ff irq 16 at device 31.4 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 2 vector 53 smbus0: on ichsmb0 pci1: driver added pci2: driver added toloading module: ichsmb ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/perl5/5.32/malo0: link state changed to UP ch/CORE 32-bit compatibility ldconfig path: /usre0: link state changed to DOWN r/lib32 Setting hostname: europa. Setting up harvesting: PURE_RDRAND,[CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . Starting Network: lo0 re0. lo0: flags=8049 metric 0 mtu 16384 options=680003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 re0: flags=8843 metric 0 mtu 1500 options=8209b ether b0:6e:bf:2e:b7:55 inet 172.16.35.57 netmask 0xffffffc0 broadcast 172.16.35.63 media: Ethernet autoselect (none) status: no carrier nd6 options=29 Starting devd. Autoloading moduums0 on uhub0 ums0: on usbus0 le: uhid Autoloums0: 3 buttons and [XYZ] coordinates ID=0 ading module: ums Autoloading module: usbhid add host 127.0.0.1: gateway lo0 fib 0: route already in table add net default: gateway 172.16.35.1 add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Clearing /tmp. Upda FreeBSD/amd64 (europa) (ttyu0) login: FreeBSD/amd64 (europa) (ttyu0) login: I am baffled. On another machine, a Lenovo laptop I get to the message about "no pools available to import" and the machine hangs there. Not a clue why. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From nobody Tue Apr 12 10:49:00 2022 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 CE02C1A83D26 for ; Tue, 12 Apr 2022 10:49:09 +0000 (UTC) (envelope-from SRS0=Jbmd=UW=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 4Kd2XN4FVHz4T5Q for ; Tue, 12 Apr 2022 10:49:08 +0000 (UTC) (envelope-from SRS0=Jbmd=UW=klop.ws=ronald-lists@realworks.nl) Date: Tue, 12 Apr 2022 12:49:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1649760540; 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=Dg69zXTAUfjHNwyTfpSuGwMmbtZL8pONUVhPT3OxK10=; b=L+y98Xu268vn3VPWPrI/BGBxsR0EK2KcEn1s+eoUFjodI0uiZjjj9u/QCLDaKic+uJSaHG SrtQArEHM59vvWMUsev5MxsHtxRD24Q/vNgHbWemI55twOvK1q85Z9aEVSxyhPAio0FDOz 6HZJ7UVGlAo8N+I/C84d/RNNKUO5nIa100L3UAEJ4UVG7S3ejbkPvj2TW3jTLdob51oHUv 77yTYqI7FWW7w0ENmq0DQfPS24hzi65YStbvdFkxTxlYOBNE3rA6BwUF+YuF2N3nBeQknd 2gWmtQGF00YMohSgJtgNBtd9VOKHJX/F1Rcwd4ipdlqZkOqo6DX0tO2juEXnbg== From: Ronald Klop To: freebsd-current@freebsd.org Message-ID: <1726677380.227.1649760540485@localhost> In-Reply-To: <72bcb8cc-e3d7-77d8-a0b5-4bb351921d24@blastwave.org> References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> <72bcb8cc-e3d7-77d8-a0b5-4bb351921d24@blastwave.org> Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" 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_226_72080177.1649760540419" X-Mailer: Realworks (603.74.f07b9af) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4Kd2XN4FVHz4T5Q X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=L+y98Xu2; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=Jbmd=UW=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=Jbmd=UW=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-2.75 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RWL_MAILSPIKE_EXCELLENT(0.00)[194.109.157.24:from]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.55)[-0.550]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=Jbmd=UW=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=Jbmd=UW=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_226_72080177.1649760540419 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Dennis Clarke Datum: dinsdag, 12 april 2022 10:41 Aan: freebsd-current@freebsd.org Onderwerp: Re: main-n254654-d4e8207317c results in "no pools available to import" > > On 4/11/22 14:18, Ronald Klop wrote: > > On 4/11/22 17:17, Dennis Clarke wrote: > >> > >> Did the usual git pull origin main and buildworld/buildkernel but >> after installkernel the machine will not boot. > >> > >> The rev seems to be main-n254654-d4e8207317c. > >> > >> I can boot single user mode and get a command prompt but nothing past > >> that. Is there something borked in ZFS in CURRENT ? > >> > >> > >> > > > > > > Up until now you are the only one with this error on the mailinglist > today. So I doubt something is borked. > > You could consider to share more details about your setup to help people > to think along with you. > > > > Regards, > > Ronald. > > I am officially baffled. > > I installed latest CURRENT snapshot on another system and then buildworld and buildkernel after checkout of d4e8207317c. > > At reboot, with a serial console I can get to single user mode no problem : > > > . > . > . > cd0 at ahcich3 bus 0 scbus3 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: Serial Number K18C36A0237 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-4 ATA SATA 3.x device > ada0: Serial Number S5VSNG0NB12944W > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > ada0: Command Queueing enabled > ada0: 953869MB (1953525168 512 byte sectors) > ses0: pass0,ada0 in 'Slot 00', SATA Slot: scbus0 target 0 > ses0: pass1,cd0 in 'Slot 03', SATA Slot: scbus3 target 0 > GEOM: new disk ada0 > Root mount waiting for: usbus0 > uhub0: 26 ports with 26 removable, self powered > ugen0.2: at usbus0 > efirtc0: providing initial system time > start_init: trying /sbin/init > Enter root password, or ^D to go multi-user > Password: > Enter full pathname of shell or RETURN for /bin/sh: > root@:/ # uname -apKU > FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 d4e8207317c-n254654-d4e8207317c: Tue Apr 12 08:10:00 UTC 2022 root@europa:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400056 1400056 > root@:/ # > > > When I go to full multi-user mode I see the same message "no pools available to import" but the machine comes up just fine : > > > > root@:/ # exit > Setting hostuuid: 688682c8-76df-3f6f-3af4-b06ebf2eb755. > Setting hostid: 0xc646c1f3. > no pools available to import > Fast boot: skipping disk checks. > Mounting local filesystems:. > Autoloading module: acpi_wmi > AuACPI: Processor \_PR_.CPU2 (ACPI ID 3) ignored > ACPI: Processor \_PR_.CPU3 (ACPI ID 4) ignored > ACPI: Processor \_PR_.CPU4 (ACPI ID 5) ignored > ACPI: Processor \_PR_.CPU5 (ACPI ID 6) ignored > ACPI: Processor \_PR_.CPU6 (ACPI ID 7) ignored > ACPI: Processor \_PR_.CPU7 (ACPI ID 8) ignored > acpi_wmi0: on acpi0 > acpi_wmi0: cannot find EC device > acpi_wmi0: Embedded MOF found > ACPI: \AMW0.WQMO: 1 arguments were passed to a non-method ACPI object (Buffer) (20220331/nsarguments-361) > acpi_wmi1: on acpi0 > acpi_wmi1: cannot find EC device > pci0: driver added > found-> vendor=0x8086, dev=0xa2ba, revid=0x00 > domain=0, bus=0, slot=22, func=0 > class=07-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0002, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=16 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pci0:0:22:0: reprobing on driver added > found-> vendor=0x8086, dev=0xa2a1, revid=0x00 > domain=0, bus=0, slot=31, func=2 > class=05-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0002, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > pci0:0:31:2: reprobing on driver added > found-> vendor=0x8086, dev=0xa2a3, revid=0x00 > domain=0, bus=0, slot=31, func=4 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=16 > pci0:0:31:4: reprobing on driver added > ichsmb0: port 0xf040-0xf05f mem 0xf712a000-0xf712a0ff irq 16 at device 31.4 on pci0 > ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 2 vector 53 > smbus0: on ichsmb0 > pci1: driver added > pci2: driver added > toloading module: ichsmb > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/perl5/5.32/malo0: link state changed to UP > ch/CORE > 32-bit compatibility ldconfig path: /usre0: link state changed to DOWN > r/lib32 > Setting hostname: europa. > Setting up harvesting: PURE_RDRAND,[CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > Feeding entropy: . > Starting Network: lo0 re0. > lo0: flags=8049 metric 0 mtu 16384 > options=680003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=21 > re0: flags=8843 metric 0 mtu 1500 > > options=8209b > ether b0:6e:bf:2e:b7:55 > inet 172.16.35.57 netmask 0xffffffc0 broadcast 172.16.35.63 > media: Ethernet autoselect (none) > status: no carrier > nd6 options=29 > Starting devd. > Autoloading moduums0 on uhub0 > ums0: on usbus0 > le: uhid > Autoloums0: 3 buttons and [XYZ] coordinates ID=0 > ading module: ums > Autoloading module: usbhid > add host 127.0.0.1: gateway lo0 fib 0: route already in table > add net default: gateway 172.16.35.1 > add host ::1: gateway lo0 fib 0: route already in table > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > Clearing /tmp. > Upda > FreeBSD/amd64 (europa) (ttyu0) > > login: > > FreeBSD/amd64 (europa) (ttyu0) > > login: > > > I am baffled. On another machine, a Lenovo laptop I get to the message about "no pools available to import" and the machine hangs there. > > Not a clue why. > > > > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > GreyBeard and suspenders optional > > > > Hi, Some thoughts to narrow down on possibilities. How do you specify what pool to boot from? There are multiple options: - vfs.root.mountfrom=zfs:... in /boot/loader.conf - zpool get all | grep bootfs - Some cachefile. I think this is legacy. I don't see it on my ZFS anymore. - A definition in /etc/fstab. But I guess the FS must be mounted first before this can be read. - And probably other options I don't know about. And somewhere in the boot messages you should have a line like this. What does it say? "Trying to mount root from zfs:zrpi4/ROOT/14-2022_03_09" And what is the output of "gpart show"? Regards, Ronald. ------=_Part_226_72080177.1649760540419 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Van: Dennis Clarke <dclarke@blastwave.org>
Datum: dinsdag, 12 april 2022 10:41
Aan: freebsd-current@freebsd.org
Onderwerp: Re: main-n254654-d4e8207317c results in "no pools available to import"

On 4/11/22 14:18, Ronald Klop wrote:
> On 4/11/22 17:17, Dennis Clarke wrote:
>>
>> Did the usual git pull origin main and buildworld/buildkernel but >> after installkernel the machine will not boot.
>>
>> The rev seems to be main-n254654-d4e8207317c.
>>
>> I can boot single user mode and get a command prompt but nothing past
>> that. Is there something borked in ZFS in CURRENT ?
>>
>>
>>
>
>
> Up until now you are the only one with this error on the mailinglist > today. So I doubt something is borked.
> You could consider to share more details about your setup to help people > to think along with you.
>
> Regards,
> Ronald.

I am officially baffled.

I installed latest CURRENT snapshot on another system and then buildworld and buildkernel after checkout of d4e8207317c.

At reboot, with a serial console I can get to single user mode no problem :


.
.
.
cd0 at ahcich3 bus 0 scbus3 target 0 lun 0
cd0: <HL-DT-ST DVDRAM GH70N UGA0> Removable CD-ROM SCSI device
cd0: Serial Number K18C36A0237
cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <Samsung SSD 870 QVO 1TB SVQ01B6Q> ACS-4 ATA SATA 3.x device
ada0: Serial Number S5VSNG0NB12944W
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 953869MB (1953525168 512 byte sectors)
ses0: pass0,ada0 in 'Slot 00', SATA Slot: scbus0 target 0
ses0: pass1,cd0 in 'Slot 03', SATA Slot: scbus3 target 0
GEOM: new disk ada0
Root mount waiting for: usbus0
uhub0: 26 ports with 26 removable, self powered
ugen0.2: <PixArt USB Optical Mouse> at usbus0
efirtc0: providing initial system time
start_init: trying /sbin/init
Enter root password, or ^D to go multi-user
Password:
Enter full pathname of shell or RETURN for /bin/sh:
root@:/ # uname -apKU
FreeBSD  14.0-CURRENT FreeBSD 14.0-CURRENT #0 d4e8207317c-n254654-d4e8207317c: Tue Apr 12 08:10:00 UTC 2022 root@europa:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400056 1400056
root@:/ #


When I go to full multi-user mode I see the same message "no pools available to import" but the machine comes up just fine :



root@:/ # exit
Setting hostuuid: 688682c8-76df-3f6f-3af4-b06ebf2eb755.
Setting hostid: 0xc646c1f3.
no pools available to import
Fast boot: skipping disk checks.
Mounting local filesystems:.
Autoloading module: acpi_wmi
AuACPI: Processor \_PR_.CPU2 (ACPI ID 3) ignored
ACPI: Processor \_PR_.CPU3 (ACPI ID 4) ignored
ACPI: Processor \_PR_.CPU4 (ACPI ID 5) ignored
ACPI: Processor \_PR_.CPU5 (ACPI ID 6) ignored
ACPI: Processor \_PR_.CPU6 (ACPI ID 7) ignored
ACPI: Processor \_PR_.CPU7 (ACPI ID 8) ignored
acpi_wmi0: <ACPI-WMI mapping> on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi0: Embedded MOF found
ACPI: \AMW0.WQMO: 1 arguments were passed to a non-method ACPI object (Buffer) (20220331/nsarguments-361)
acpi_wmi1: <ACPI-WMI mapping> on acpi0
acpi_wmi1: cannot find EC device
pci0: driver added
found-> vendor=0x8086, dev=0xa2ba, revid=0x00
         domain=0, bus=0, slot=22, func=0
         class=07-80-00, hdrtype=0x00, mfdev=1
         cmdreg=0x0002, statreg=0x0010, cachelnsz=0 (dwords)
         lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
         intpin=a, irq=16
         powerspec 3  supports D0 D3  current D0
         MSI supports 1 message, 64 bit
pci0:0:22:0: reprobing on driver added
found-> vendor=0x8086, dev=0xa2a1, revid=0x00
         domain=0, bus=0, slot=31, func=2
         class=05-80-00, hdrtype=0x00, mfdev=1
         cmdreg=0x0002, statreg=0x0000, cachelnsz=0 (dwords)
         lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
pci0:0:31:2: reprobing on driver added
found-> vendor=0x8086, dev=0xa2a3, revid=0x00
         domain=0, bus=0, slot=31, func=4
         class=0c-05-00, hdrtype=0x00, mfdev=0
         cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords)
         lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
         intpin=a, irq=16
pci0:0:31:4: reprobing on driver added
ichsmb0: <Intel Kaby Lake SMBus controller> port 0xf040-0xf05f mem 0xf712a000-0xf712a0ff irq 16 at device 31.4 on pci0
ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 2 vector 53
smbus0: <System Management Bus> on ichsmb0
pci1: driver added
pci2: driver added
toloading module: ichsmb
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/perl5/5.32/malo0: link state changed to UP
ch/CORE
32-bit compatibility ldconfig path: /usre0: link state changed to DOWN
r/lib32
Setting hostname: europa.
Setting up harvesting: PURE_RDRAND,[CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
Starting Network: lo0 re0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
         options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
         inet6 ::1 prefixlen 128
         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
         inet 127.0.0.1 netmask 0xff000000
         groups: lo
         nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
 
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
         ether b0:6e:bf:2e:b7:55
         inet 172.16.35.57 netmask 0xffffffc0 broadcast 172.16.35.63
         media: Ethernet autoselect (none)
         status: no carrier
         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Starting devd.
Autoloading moduums0 on uhub0
ums0: <PixArt USB Optical Mouse, class 0/0, rev 1.10/1.00, addr 1> on usbus0
le: uhid
Autoloums0: 3 buttons and [XYZ] coordinates ID=0
ading module: ums
Autoloading module: usbhid
add host 127.0.0.1: gateway lo0 fib 0: route already in table
add net default: gateway 172.16.35.1
add host ::1: gateway lo0 fib 0: route already in table
add net fe80::: gateway ::1
add net ff02::: gateway ::1
add net ::ffff:0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
Clearing /tmp.
Upda
FreeBSD/amd64 (europa) (ttyu0)

login:

FreeBSD/amd64 (europa) (ttyu0)

login:


I am baffled. On another machine, a Lenovo laptop I get to the message about "no pools available to import" and the machine hangs there.

Not a clue why.



-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
 


Hi,

Some thoughts to narrow down on possibilities.

How do you specify what pool to boot from?
There are multiple options:
- vfs.root.mountfrom=zfs:...  in /boot/loader.conf
- zpool get all | grep bootfs
- Some cachefile. I think this is legacy. I don't see it on my ZFS anymore.
- A definition in /etc/fstab. But I guess the FS must be mounted first before this can be read.
- And probably other options I don't know about.

And somewhere in the boot messages you should have a line like this. What does it say?
"Trying to mount root from zfs:zrpi4/ROOT/14-2022_03_09"

And what is the output of "gpart show"?

Regards,
Ronald.
  ------=_Part_226_72080177.1649760540419-- From nobody Tue Apr 12 11:17:09 2022 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 DFCBC1A94B04 for ; Tue, 12 Apr 2022 11:17:17 +0000 (UTC) (envelope-from 010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@amazonses.com) Received: from a48-99.smtp-out.amazonses.com (a48-99.smtp-out.amazonses.com [54.240.48.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kd38r3VFTz4ZqK for ; Tue, 12 Apr 2022 11:17:16 +0000 (UTC) (envelope-from 010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1649762230; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=tes5OrIe0+4G5vWFv4OoYGBUCqJ+eITfOe5LjV7Eb6U=; b=Dir7gwcv/vMfbKiCv++eJ4eA3Oz1fm6qTsmO5Fnvo2Ng9sCRmU1a/pNmOFdGYlGm cAL9mlPWBNmIukf7eju4ZfRckrjmK8v05cx/blezQUokSE+wRTtwL/eVkVZe1NC63RG cWtxP7+DBZHRF246FUG0qDE+4dJ0PcPOvQmM7WyY= Message-ID: <010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@email.amazonses.com> Date: Tue, 12 Apr 2022 11:17:09 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> From: Thomas Laus In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES X-SES-Outgoing: 2022.04.12-54.240.48.99 X-Rspamd-Queue-Id: 4Kd38r3VFTz4ZqK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=Dir7gwcv; dmarc=none; spf=pass (mx1.freebsd.org: domain of 010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@amazonses.com designates 54.240.48.99 as permitted sender) smtp.mailfrom=010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@amazonses.com X-Spamd-Result: default: False [-0.69 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[54.240.48.99:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[acm.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[amazonses.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[54.240.48.99:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[lausts@acm.org,010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@amazonses.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 4/11/22 14:18, Ronald Klop wrote: > On 4/11/22 17:17, Dennis Clarke wrote: >> >> Did the usual git pull origin main and buildworld/buildkernel but >> after installkernel the machine will not boot. >> >> The rev seems to be main-n254654-d4e8207317c. >> >> I can boot single user mode and get a command prompt but nothing past >> that. Is there something borked in ZFS in CURRENT ? >> > Up until now you are the only one with this error on the mailinglist > today. So I doubt something is borked. > You could consider to share more details about your setup to help people > to think along with you. > I can confirm this issue. My last update was 'main-n253996-1b3af110bc' from March 31, 2022 that worked fine. My update yesterday received the same error and refused to boot past looking for kernel modules. I did receive the "no pools available to import" message a couple of lines earlier. My hardware is a Dell Inspiron laptop with a SSD and ZFS filesystem. I have a little time today and plan on git reverting back to March 31 to further isolate the problem. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From nobody Tue Apr 12 12:10:25 2022 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 C6E1B1A909F6 for ; Tue, 12 Apr 2022 12:10:40 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kd4LR5r63z4hS2 for ; Tue, 12 Apr 2022 12:10:39 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 6817C22913; Tue, 12 Apr 2022 14:10:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1649765431; 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=CYzZzvb/VpzzCc5X8zADG3A2ZMrZRmlI9wmsWa30+1A=; b=jnU9eK3DwfAKZxpX42ICUO9HjKgAKIwIdijLFWl5kO+DGYRIZJ+FhW/RWk3fNPZdo6Us7J JoaDGOdQ/dAiYYa7sLqZoe3//lsitNK5BBdjVrXtwEOkWZtk+UoPGx8qbr27jjIXvj+Vma jrVN3G7xUhLp/j9WAhkF13758yzBlsiUVlBMXQpbQzreV8j5cceB0IJ3H3BcjM+47oDKx8 aPiol9GIiYIOREJpjqbmfo9Pb74HoDHA4inXSb0sYcfVxVhMessFoL1kAPwDfusvMiieHQ pjmG/w4ihlMpxnum79DJvx2uuACACZBHYchGk4iDw9CKaTjGucilomyIbCfehw== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 27E8631DC; Tue, 12 Apr 2022 14:10:29 +0200 (CEST) Date: Tue, 12 Apr 2022 14:10:25 +0200 Message-ID: <20220412141025.Horde.qFDoIMkAMle-xQvg6sskxpe@webmail.leidinger.net> From: Alexander Leidinger To: Thomas Laus Cc: freebsd-current@freebsd.org Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> <010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@email.amazonses.com> In-Reply-To: <010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@email.amazonses.com> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_5YVruc0PsPpy6bcH0lvq88W"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4Kd4LR5r63z4hS2 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=jnU9eK3D; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-6.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_5YVruc0PsPpy6bcH0lvq88W Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Thomas Laus (from Tue, 12 Apr 2022 11:17:09 +0000)= : > On 4/11/22 14:18, Ronald Klop wrote: >> On 4/11/22 17:17, Dennis Clarke wrote: >>> >>> Did the usual git pull origin main and buildworld/buildkernel but=20=20 >>>=20after installkernel the machine will not boot. >>> >>> The rev seems to be main-n254654-d4e8207317c. >>> >>> I can boot single user mode and get a command prompt but nothing past >>> that. Is there something borked in ZFS in CURRENT ? >>> >> Up until now you are the only one with this error on the=20=20 >>=20mailinglist today. So I doubt something is borked. >> You could consider to share more details about your setup to help=20=20 >>=20people to think along with you. >> > I can confirm this issue. My last update was=20=20 >=20'main-n253996-1b3af110bc' from March 31, 2022 that worked fine. My=20= =20 >=20update yesterday received the same error and refused to boot past=20=20 >=20looking for kernel modules. I did receive the "no pools available=20= =20 >=20to import" message a couple of lines earlier. My hardware is a Dell=20= =20 >=20Inspiron laptop with a SSD and ZFS filesystem. I have a little time=20= =20 >=20today and plan on git reverting back to March 31 to further isolate=20= =20 >=20the problem. Some data point from a system with current as of 2022-04-06 15:23 (not=20= =20 sure=20if related or a red hering): pool imports fine, but iocage spits=20= =20 out=20a lot of "setting up zpool for iocage usage" during an "iocage=20=20 list".=20And it doesn't auto-start the iocage jails. As I only updated=20= =20 the=20OS and not the ports (besides: no change to iocage in ports), it=20= =20 may=20be the case that some kind of detection logic in zfs code is now=20= =20 misbehaving=20in some cases... Bye, Alexander. --=20 http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_5YVruc0PsPpy6bcH0lvq88W Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJVbDEACgkQEg2wmwP4 2IbQfQ/8DdNgr+rLnK15HARMpeth+fNu8PZwifCcHZbtwLq/krCyfoX743ok8YaB dZ32rMGT9c2jWw9oLuwjCXCemFbsxIAFsHjxRBcYB1l6CKfLDfYf+O4fsrywiwfM G2Gu4gFMJi01Zi2wVCbsml3B4jBmtN2TVUQgT9DRZBsZMy6hTAlQqj+HnOsdJ6L1 d/WrIIwvnv8PGH4vZj3tpTnMqj+8kPRIBvantQkO76lH5dixY0FvKdfDojLSZxee qNELUmrSfwhjYvVkI6GeYubWduHixyqMZytAn2DHgGkcX/RYkPDZrlf4ySKppGOJ VEqqe3YMMyyEg2fSo4j36W32KkpsEa0aZtjfgBRqaLuoNOSZj3BtdR6aOhNrV0Wg 7dMINcYmg4GnEnqkMveh/+9/DCQ+DZIpKkFgFqOKUsRmzNGSqX9wQB1waufT1YP7 jKTnpIENfd4LIi40DFT/hWL1dJtMAivaLGFfQne/d7jec4bkLGEau7f5hHEY8MzP thcgFSP20YA1JFuQVdKmHrBx3+2NczdGG9kT5Ie9yhW3Zrty+2qlIB4EDaGnqgP3 Mq2KbeWBKCVXOnZRxdSSkl7ifX5Uss7CPvW31I9KzLIsey7beE2fYFfFqChSFBwu nHUhF8hYfcQG+b4DA8YmgwJesXaoEzcOJK4Hv+N7kjcvRoNUjUk= =qQqR -----END PGP SIGNATURE----- --=_5YVruc0PsPpy6bcH0lvq88W-- From nobody Tue Apr 12 12:29:20 2022 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 B83C31A969FC for ; Tue, 12 Apr 2022 12:29:23 +0000 (UTC) (envelope-from SRS0=Jbmd=UW=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 4Kd4m26Kd3z4lKf for ; Tue, 12 Apr 2022 12:29:22 +0000 (UTC) (envelope-from SRS0=Jbmd=UW=klop.ws=ronald-lists@realworks.nl) Date: Tue, 12 Apr 2022 14:29:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1649766561; 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=oMcAocP1mykQsgqR4VNtrKvlCJ6JeNnC0K+apbGnG74=; b=jZGNMZRLCe9EBOXHMtQlrd45Ono/taNCeM99VaUQ2KmKzu/tcAidBfxr37d54y92A2I0JH dwloPiF39tGPnCKXMGNoKCvjny9Do/ytZToYYTSQZbZBaBb/dxb1b4C9uBVUn358t3LfwV 2YYFs11wBBT3/cx/w184r8uACZgOp0sZypNSFZKHu/b7TdzEFRVOpJ0gC8AaicQC2poPr+ HuBJPeagR0w3T2VSNUXNSHX8yb2r7Cyie39YbWa0SbbIh4SN1HnfstXIC9CYMiZ88Hslto Ymwk68AxmPzfywpAWxCsr8PKT+E80KtDuY558X2LzJyXlZkVZ9Fh5O0I1jX7Jw== From: Ronald Klop To: freebsd-current@freebsd.org Message-ID: <585833961.324.1649766560673@localhost> In-Reply-To: <010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@email.amazonses.com> References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> <010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@email.amazonses.com> Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" 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_323_957203271.1649766560628" X-Mailer: Realworks (603.74.f07b9af) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4Kd4m26Kd3z4lKf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=jZGNMZRL; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=Jbmd=UW=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=Jbmd=UW=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-3.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RWL_MAILSPIKE_EXCELLENT(0.00)[194.109.157.24:from]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=Jbmd=UW=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=Jbmd=UW=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_323_957203271.1649766560628 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Thomas Laus Datum: dinsdag, 12 april 2022 13:17 Aan: freebsd-current@freebsd.org Onderwerp: Re: main-n254654-d4e8207317c results in "no pools available to import" > > On 4/11/22 14:18, Ronald Klop wrote: > > On 4/11/22 17:17, Dennis Clarke wrote: > >> > >> Did the usual git pull origin main and buildworld/buildkernel but >> after installkernel the machine will not boot. > >> > >> The rev seems to be main-n254654-d4e8207317c. > >> > >> I can boot single user mode and get a command prompt but nothing past > >> that. Is there something borked in ZFS in CURRENT ? > >> > > Up until now you are the only one with this error on the mailinglist > today. So I doubt something is borked. > > You could consider to share more details about your setup to help people > to think along with you. > > > I can confirm this issue. My last update was 'main-n253996-1b3af110bc' from March 31, 2022 that worked fine. My update yesterday received the same error and refused to boot past looking for kernel modules. I did receive the "no pools available to import" message a couple of lines earlier. My hardware is a Dell Inspiron laptop with a SSD and ZFS filesystem. I have a little time today and plan on git reverting back to March 31 to further isolate the problem. > > Tom > > -- > Public Keys: > PGP KeyID = 0x5F22FDC1 > GnuPG KeyID = 0x620836CF > > > > Hi, Are you guys both using NVME or EFI? Just wondering if the common problem is in ZFS or some other component. Ronald. ------=_Part_323_957203271.1649766560628 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Van: Thomas Laus <lausts@acm.org>
Datum: dinsdag, 12 april 2022 13:17
Aan: freebsd-current@freebsd.org
Onderwerp: Re: main-n254654-d4e8207317c results in "no pools available to import"

On 4/11/22 14:18, Ronald Klop wrote:
> On 4/11/22 17:17, Dennis Clarke wrote:
>>
>> Did the usual git pull origin main and buildworld/buildkernel but >> after installkernel the machine will not boot.
>>
>> The rev seems to be main-n254654-d4e8207317c.
>>
>> I can boot single user mode and get a command prompt but nothing past
>> that. Is there something borked in ZFS in CURRENT ?
>>
> Up until now you are the only one with this error on the mailinglist > today. So I doubt something is borked.
> You could consider to share more details about your setup to help people > to think along with you.
>
I can confirm this issue.  My last update was 'main-n253996-1b3af110bc' from March 31, 2022 that worked fine.  My update yesterday received the same error and refused to boot past looking for kernel modules.  I did receive the "no pools available to import" message a couple of lines earlier.  My hardware is a Dell Inspiron laptop with a SSD and ZFS filesystem.  I have a little time today and plan on git reverting back to March 31 to further isolate the problem.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
 


Hi,

Are you guys both using NVME or EFI? Just wondering if the common problem is in ZFS or some other component.

Ronald.
  ------=_Part_323_957203271.1649766560628-- From nobody Tue Apr 12 13:20:28 2022 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 7353D5D343C for ; Tue, 12 Apr 2022 13:20:37 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kd5v81pVdz4ss5 for ; Tue, 12 Apr 2022 13:20:35 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.732, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -1.62, T_SCC_BODY_TEXT_LINE -0.01) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 23CDKS45029178 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [10.14.0.14] (static-198-54-132-57.cust.tzulo.com [198.54.132.57]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 23CDKS45029178 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 12 Apr 2022 09:20:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1649769630; bh=5yam6ARQe5npoxts9xiHm7OQUg3oZG/w7AzDF92WM5U=; h=Date:Subject:To:References:From:In-Reply-To:From; b=jZ9VIAG2gNpJWwWEH1TWfWLJP7yh4th10OyXjXNNFshz/HpeRsBrarZzQQ4AupsIb qJ1tQGb6J9lDHSiPfTgoEsnVo7tOu3P7BwbDH0qhrtjDo/AnKY/mpeFduxRc4NUNOa 9SFtxJIEy8kFzbZliRki4kMXyshfyBolXgFWrSRJzVsDi7lKKZ1EHndK/xWPlON2sN oZuE0jc/JPAfDHP8ubBhUWoM3NIZnTFpGX0+ESwzZaCujKqUHxHxxWJqwkIATKDf5x p00cbAima5nhFq1L32fYyPEaIjLm4e71NTnteWc9o5MIlMZAcFGhi36L3HM6t6wx2s 1LwW8j7Voe4cg== Message-ID: Date: Tue, 12 Apr 2022 09:20:28 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> <010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@email.amazonses.com> <585833961.324.1649766560673@localhost> From: Dennis Clarke In-Reply-To: <585833961.324.1649766560673@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Kd5v81pVdz4ss5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=jZ9VIAG2; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[blastwave.org:+]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/12/22 08:29, Ronald Klop wrote: > > Van: Thomas Laus > Datum: dinsdag, 12 april 2022 13:17 > Aan: freebsd-current@freebsd.org > Onderwerp: Re: main-n254654-d4e8207317c results in "no pools available > to import" >> >> On 4/11/22 14:18, Ronald Klop wrote: >> > On 4/11/22 17:17, Dennis Clarke wrote: >> >> >> >> Did the usual git pull origin main and buildworld/buildkernel but >> >> after installkernel the machine will not boot. >> >> >> >> The rev seems to be main-n254654-d4e8207317c. >> >> >> >> I can boot single user mode and get a command prompt but nothing past >> >> that. Is there something borked in ZFS in CURRENT ? >> >> >> > Up until now you are the only one with this error on the mailinglist >> > today. So I doubt something is borked. >> > You could consider to share more details about your setup to help >> people > to think along with you. >> > >> I can confirm this issue.  My last update was >> 'main-n253996-1b3af110bc' from March 31, 2022 that worked fine.  My >> update yesterday received the same error and refused to boot past >> looking for kernel modules.  I did receive the "no pools available to >> import" message a couple of lines earlier.  My hardware is a Dell >> Inspiron laptop with a SSD and ZFS filesystem.  I have a little time >> today and plan on git reverting back to March 31 to further isolate >> the problem. >> >> Tom >> >> -- >> Public Keys: >> PGP KeyID = 0x5F22FDC1 >> GnuPG KeyID = 0x620836CF >> >> >> >> > > > Hi, > > Are you guys both using NVME or EFI? Just wondering if the common > problem is in ZFS or some other component. > My problem machine is definately NVME based storage. As for EFI, I don't know. Is the thing pure UEFI? Yes it is. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From nobody Tue Apr 12 15:48:32 2022 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 6C6031A8CAAA for ; Tue, 12 Apr 2022 15:48:39 +0000 (UTC) (envelope-from 010001801e765246-32815251-8b4b-4acd-b29e-1043f4dc67f2-000000@amazonses.com) Received: from a48-106.smtp-out.amazonses.com (a48-106.smtp-out.amazonses.com [54.240.48.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kd99y5PRfz4Txw for ; Tue, 12 Apr 2022 15:48:38 +0000 (UTC) (envelope-from 010001801e765246-32815251-8b4b-4acd-b29e-1043f4dc67f2-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1649778512; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=P+gIDo65EfRJnQ+FXYZm8Zuma8pbcmNlNuKKs4g3UUA=; b=f25Cnpsr+uZwsYEhiQ7ZqjOX6Ccp1pOJcoKJo3AXuprmaYfXQ8f8szgW7xIPWIs7 B4GuN6v9UaZmNWgtCx+zsF2OK139Sirynx+s0wdKdIZpk/zSDb5hNA4iatP9IUtJ7N8 4h98whqBuf4kXuerozvnu3g9ftNB1EO3pZWTvmrU= Message-ID: <010001801e765246-32815251-8b4b-4acd-b29e-1043f4dc67f2-000000@email.amazonses.com> Date: Tue, 12 Apr 2022 15:48:32 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> <010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@email.amazonses.com> <585833961.324.1649766560673@localhost> From: Thomas Laus In-Reply-To: <585833961.324.1649766560673@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES X-SES-Outgoing: 2022.04.12-54.240.48.106 X-Rspamd-Queue-Id: 4Kd99y5PRfz4Txw X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=f25Cnpsr; dmarc=none; spf=pass (mx1.freebsd.org: domain of 010001801e765246-32815251-8b4b-4acd-b29e-1043f4dc67f2-000000@amazonses.com designates 54.240.48.106 as permitted sender) smtp.mailfrom=010001801e765246-32815251-8b4b-4acd-b29e-1043f4dc67f2-000000@amazonses.com X-Spamd-Result: default: False [-0.69 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[acm.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[amazonses.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.994]; RCVD_IN_DNSWL_NONE(0.00)[54.240.48.106:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[lausts@acm.org,010001801e765246-32815251-8b4b-4acd-b29e-1043f4dc67f2-000000@amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[54.240.48.106:from]; ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,010001801e765246-32815251-8b4b-4acd-b29e-1043f4dc67f2-000000@amazonses.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 4/12/22 08:29, Ronald Klop wrote: > Are you guys both using NVME or EFI? Just wondering if the common > problem is in ZFS or some other component. > I just repeated this issue on the desktop computer that is used for my weekly builds that get distributed to the other PC's in the house. In order to not contaminate the build with local changes, I blew away my /usr/obj and /usr/src. I cloned the repository and built world with a GENERIC kernel. The problem is on my desktop as well with a fresh clone as of a few hours ago. This desktop uses 2 SSD drives in a zpool mirror. It also uses EFI. The EFI partition was copied from /boot/loader.efi to the /EFI/BOOT/BOOTX64.efi file on ada0p1 and ada1p1 like I do each time before rebuilding my system. I made sure that the zpool was upgraded before cloning as well. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From nobody Tue Apr 12 22:15:05 2022 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 482611B05A8D for ; Tue, 12 Apr 2022 22:15:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdKm51jxrz3D51 for ; Tue, 12 Apr 2022 22:15:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649801710; bh=cyM0LydQ0hvKMWvorg8Zs8CcMOlYYYVBdstEr1iBLLk=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=oPvlBqiKGvShfqqyml6KWv838NbMxCJeCymBu0zFY4K87gaZ+8gDFG5TeylBYElPT3LRmmE39RdA0vp/qUTgIXSI5QUwAySMImvqv+Tm8XvTu9zUtb7yxbrBL3VLDKJujYKeLxl+Lzd+MSsasbk/ddyAtfgGh/xIZhu4tEGmyWcvwt2mcpBbID7j9QH40nSR5YeM3a28JC9jQ1IU3CvMG0vBiMaMHIU8wkeGhIluwNR6F36wNx8JF4bTPKmnraC6fwbys+Ze4l4CpAgy0I602rtSyiQN4oOjpynDenTFgABMPht0LFhyZ17oNLDnjkWIF3nf9gll/hcEskDGirqQTg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649801710; bh=FozWyZwdYhHV+fmQANmT/Qe2xMS/7g/xbRAYXbH6Qtw=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=bIYE6Tp6FKaU1/Q/9RMDqwPO3pxNfkwEVVlxsq4SNzECqfBT7vTa5tVIH5fu4SIb4uoY8Zh995m6QVERFIzYX0CiwzMlqYxg82GTcpzw3VrMXJGn/PZLUvJDtjLBbtpGmuB8+VeWlqOH5X6hRJWczm2Y8bFo3N/5t/M7H1FY8yTGU4h2bXFwAvNSpcKkFb7x59vBTA7IqiwtohwL//qKOP9qjuT8ZcVEjJkhZXc+Ci2rjnXERQJIKX6UoBP/mSy/2CyCaVL9EUNUf/QXmdTNNsXSKJRu+iRVJv7NYC3Za84a8weHh4sGHmPB8hfi0oXFxseE2MawsRLVNn8J7XR64w== X-YMail-OSG: TDFS41MVM1lLLhc30aqSJqNoL.J27DJZGVu.BC8K4fuh_w144BPh5hHhCXumoX4 l09afx.Vkiw2eDUciqr1XylI4.ExUdt.u2LUxA2y1sDWaEKyXZJ8AY2kSZk1fSwTjsRMDI80SKFP _V_sdDL76D4Yr_11g9ame__D8m7Od.8Clx95QhSb8an5m67oN8fn9KX4JXKaEMlfUw9m8HZDsdEE FLonwVdkxEN1mDEAwJ0hUrlsU59PZFlTWEytWqQ9WcFkU8kIBIbkZrJGj0SRVCaR5sXOx9UVqz12 AbLMIxZnCDE0.LR7SacVbkTCopN.7lGsU2cXG89WM9psrCP_DgWsEpI8506OvmVsQv1Wm6YTcGsq vW7i.vSlQckr.xTZ9yOnh2Uk5yenjTMGl20ZAD0x_v..7wO2_drDW_BIyXWXvlciVC5DpIjU0wKG jEfKtvIFKwg34ifvXgmzIIoGpFgl1tB3eGU5K6Pl2d31uP.tChrh.EJXbZn1yfo.wm3e1VLyhpKG AHYk2gciwi_6R92GWG0.VEYfyhyNMJTwq7S81hM1Ph2.Seiawe6CNpkaHlXKJWfhtsyKhw7bAo_a hn8iUGqjW1zgv8XbHiQ.1zWtmyX5S8d14Iwii57H91O81ZG6WP7agIOD1SBAwLtp1YPSDNipXeB. X3Ty5lOVTaB54e1SCcd7oRYg4DuF0O2cPAFhnQ22OmPIgdRT628xeb2YstaS5fdKCsSVW97oXib. Qgm0ikevAAo_WUi6uYfrNZE8mxIkyPrCbcLu8PzLg7p_cT4Ai2LvKBTWaLXj1IJEISo58RLyoFzv qsBCi7.4sj62mkQqGBf96lqyuy0oHOgdyTtga43UUACisUYrNqZ0s5M1EHimi2vMopBbCPGZz9RL cxRFsV_.xGhRVyi._ZtnhCSuEvefSaANuN9RZNqZbdR95Gbqr4D4mgwIs0uZoLw_uF87hkt5EEn8 GKzjTLnoeCek7VRT9BJU6bnKx_krsw.8X.4.wCLo5erIXRXZGpDITdaVJ2gAJPweoTkUFuwYlLKv 0SOk7lHH2hDhZFJL_FICrDis2ym0q0YYW_XspceutqeThoufi_Yh8UxDsz4BTiNzvkcWVYc4trVO WiSBq4NBY4kIdXdd.V.ak1k2pyzJQxelXBm7YeL80JNK0pRxWX8vZgSjJjxHcQCTya6HLRFMKng1 jULCxyqalLLB0gwjjSHYOnYjlUqo7tL3S_iIBBnp.CwH93vBIQ_dOJj.hsrZIlsKGRjO7KMt0e9e J3ouB23RsLyQU4Cezqgh9dBozNdy3P5wiv54dOwMCWERLM9ABLba_yAOClRfnlOoMJMG4TRGyEph SkO8zbAMrhX6E5IrpM_4KLOmuBCbIBrPbCjF.p_60F8zvp8h8O74ATmZZdhXAW.yctKMqYAXyHt0 kDkcgiOqU8xDtaj2j2hLXIerWj4E3Pl95uZmIX1DGyQeib24rXe5Eitwkt9je_7t9t6xqBfOre_P IzejRDd2l5Fqq1P5sTeMs4cdnIaLGlJPsSBq3PKsNZ43YOpi51vn7Md29nc83h2CnT65HTlw8Xww bWobkbLekCqCscf749FpYijSQ0uf8Rah4Pz5GRFPl06mryeuNANGKtvNESFRnfYh2bovaapzwflI ETCsCDQYvVYBHfrNfAfWrlUelX8.pCyX2I.YUX3TnCYX.wGhE2PF63g7tD4m.yUiDf4BSkw0Wtmd 5VzUcOnKJKrEVOyoXFrsaWqqGC_sOKnoXK4A0kBtzuJDxCzrsP.TqKxHVBDXavmDHGztifgKte8T lbkHiSaxeu1xfe_PFsS9i_CKDIo0v7JqB8ObrlWnzwDOguDpPexXNn8PamceCdlS8zxVK2DVKvJ7 Ujy_DrqFSLuGQ0ursllmuSA.KnywQ_NosAdXXRTrB.QGDC7uMBY4XIhfY8BvdaWSuZ96f97FoitW nL8eJemNuNQlxkny4kiOGoRxNLDsViAuRQQbN5nwoQ.kvhw9rFWoB0VJGpd9GViPTdCdAKGkKuBT YdvH5zdZsNA3d6vJDOfRmg7KYh.._A.P4UlX6he7gznaMJu36.Wpk38htBTVYQAdgbT22XrhOZGQ PQbDoGybvalk38Tv3dhxv5QZ_m17Ams3IBnjor5P7uqpWJrrA01dgrW3d9QBDW5Jtm2nSfXqsGqb f5cQS0IuemxsaqbUKVSbmpWnJzZW3HS2xr68Q37Bn5CR5S4mF_.g1f8pt8Sz3K7Mu0c07nNPABWV gJMhkoRlH7yIey1wfcIELrezHZM6XOfyHp.FaDymV5qJ98UopZWwtNYKaGujCoaIT69kLjf7s6V3 Z7ffAu8opKqYVXw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 12 Apr 2022 22:15:10 +0000 Received: by hermes--canary-production-bf1-665cdb9985-6hz22 (VZM Hermes SMTP Server) with ESMTPA ID 6d3c4c96bf9e791d12d09a2faffc85d9; Tue, 12 Apr 2022 22:15:08 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Message-Id: Date: Tue, 12 Apr 2022 15:15:05 -0700 Cc: Ronald Klop To: lausts@acm.org, Dennis Clarke , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4KdKm51jxrz3D51 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=oPvlBqiK; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.66 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.84)[0.842]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N From: Thomas Laus Date: Tue, 12 Apr 2022 15:48:32 +0000 : > On 4/12/22 08:29, Ronald Klop wrote: > > Are you guys both using NVME or EFI? Just wondering if the common > > problem is in ZFS or some other component. > > > I just repeated this issue on the desktop computer that is used for my > weekly builds that get distributed to the other PC's in the house. In > order to not contaminate the build with local changes, I blew away my > /usr/obj and /usr/src. I cloned the repository and built world with a > GENERIC kernel. The problem is on my desktop as well with a fresh clone > as of a few hours ago. This desktop uses 2 SSD drives in a zpool > mirror. It also uses EFI. The EFI partition was copied from > /boot/loader.efi to the /EFI/BOOT/BOOTX64.efi file on ada0p1 and ada1p1 > like I do each time before rebuilding my system. I made sure that the > zpool was upgraded before cloning as well. UEFI/ACPI ? UEFI/Device-Tree? Dennis Clarke's: https://lists.freebsd.org/archives/freebsd-current/2022-April/001759.html explicitly showed ACPI for one of his contexts: Autoloading module: acpi_wmi AuACPI: Processor \_PR_.CPU2 (ACPI ID 3) ignored ACPI: Processor \_PR_.CPU3 (ACPI ID 4) ignored ACPI: Processor \_PR_.CPU4 (ACPI ID 5) ignored ACPI: Processor \_PR_.CPU5 (ACPI ID 6) ignored ACPI: Processor \_PR_.CPU6 (ACPI ID 7) ignored ACPI: Processor \_PR_.CPU7 (ACPI ID 8) ignored acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device acpi_wmi0: Embedded MOF found ACPI: \AMW0.WQMO: 1 arguments were passed to a non-method ACPI object (Buffer) (20220331/nsarguments-361) acpi_wmi1: on acpi0 acpi_wmi1: cannot find EC device I can not tell about the other context. His: https://lists.freebsd.org/archives/freebsd-current/2022-April/001764.html reports: My problem machine is definately NVME based storage. I can not tell about the other context. === Mark Millard marklmi at yahoo.com From nobody Tue Apr 12 22:35:08 2022 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 EAC5C1AF2993 for ; Tue, 12 Apr 2022 22:35:21 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdLCF1tTSz3LBf for ; Tue, 12 Apr 2022 22:35:21 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.731, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -1.62, T_SCC_BODY_TEXT_LINE -0.01, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 23CMZ81m016882 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [10.14.0.14] (static-198-54-132-57.cust.tzulo.com [198.54.132.57]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 23CMZ81m016882 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 12 Apr 2022 18:35:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1649802910; bh=eQQIV+xMoOyi9t+/4FqowQ/DbJwmkvcEMzSs3QDog/4=; h=Date:Subject:To:References:From:In-Reply-To:From; b=K0uwLz2/wGsQtJJdI2FenzDwW2d87iFjEt/w3s2K5L9xc9HF+SKHdUF5C9DTZ10R3 FjxdRrJSrIVg9e9Rgu7XXmgOkdUteL57HcoXpLjZ6cgAwQEnofMaV2a64O8rz6fCsy 4QV9MzBNExxAzjDLRhGNgeRNC2HBqFuv5b3WLv82fmvgQWuL2p/UOxC2j5AR6YH9MJ u8LBYY1+g95RtuFqi0fvJ03uY960sPzngLjzPTL3Uet+vLFvPIq/ChBnPC/bhcA9AA 2rqZT0APYJCQH3/kb3sefit08wbLZnxPsB7So9jil4xyu4O98oSvjarqL1iTWfs2TI a0/ijGHTul1Tw== Message-ID: <093ec3cb-32a1-e316-a369-3a9e8559248a@blastwave.org> Date: Tue, 12 Apr 2022 18:35:08 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: From: Dennis Clarke In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KdLCF1tTSz3LBf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b="K0uwLz2/"; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; DKIM_TRACE(0.00)[blastwave.org:+]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/12/22 18:15, Mark Millard wrote: > From: Thomas Laus > Date: Tue, 12 Apr 2022 15:48:32 +0000 : > >> On 4/12/22 08:29, Ronald Klop wrote: >>> Are you guys both using NVME or EFI? Just wondering if the common >>> problem is in ZFS or some other component. >>> I will try to gather more information on the machine that actually demonstrates the problem in question. >> I just repeated this issue on the desktop computer that is used for my >> weekly builds that get distributed to the other PC's in the house. Excellent isolation test. I tried the same sort of process on a separate machine to no avail. I was not using NVME storage. I was using a brand new Samsung SSD and you can see that listed in the output : https://lists.freebsd.org/archives/freebsd-current/2022-April/001759.html * * * * the above should be considered a red herring * * * * That machine simply worked as expected. Slight surprise but then again no one else was seeing this issue. Until Thomas Laus also caught it : https://lists.freebsd.org/archives/freebsd-current/2022-April/001761.html So we have at least two examples in the wild. I will focus on the problem case I have and try to get better information. Somehow. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From nobody Wed Apr 13 01:04:05 2022 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 7F27B11CE700 for ; Wed, 13 Apr 2022 01:04:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660051.outbound.protection.outlook.com [40.107.66.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdPW04j8mz4Z0C for ; Wed, 13 Apr 2022 01:04:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I+CBTZpF+fyXp9qBnyW9XTCb0MZdoCMpt1vQd8ZCl5rf72Nr6Pp/RcBqqdXlhg+y8A4weCJ0FmAjXrD3EQdgOOpDu+vZw4cxKpVg/p5BkWHFxzBuPSZeUeIF2NngyOIe625GHHcGK4tNSSPDTfRaEk0U8Ycw1D7eou4JuabWcfdKwSCkgAlGnhNMtwFmCWxVUgt1n3aWO9c8/tqnTu1UTE+7u4ZwX7ITQTsTQDhzEjxq6qc9rLcbzwNtiFwchUZeakqiWFNwPBfu0TTARgp+mEBO+GqY3RMIUge1dU7XwxHlHSQPJhVKfe/QQYnT0y2pPohi8/Hoe8EuOwb558Qyug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0k6iz7GWlZO2HZQrrcpFqlixuDkFgF9BBPlSe+/58MY=; b=PD9uvO8M4O9p+JQ1H5vXWzYkRDMk1p3H112l7voELGAd24GCgTq/0/nFmX601mO5bQXFuy2XkG/isi5MPjErfa9ZrbdI8dbQO4aP4j5mxVAL61XcIo13MewkAGBnlyIxFheul1zfk73J5rDQiFYQ8Hfo84KnjGsdEbsfNrz11tX/YyYX0CWsub3JIHcK2J+dMawlhCKZZK823cOBoDvB7W42E7ahAFiAoQvBo98ikBAZqVtchXUsOwz1xRM5cICZk+KGofVy7IP3aszKSKHJ517WcL3uwKHo4qrNpq+Il2IstJv2+rB+VtTZvqPglGhRApNcs/EkucdX/ACnevL4sQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0k6iz7GWlZO2HZQrrcpFqlixuDkFgF9BBPlSe+/58MY=; b=NNcV6MtjP48VEEyXiIIBR9EhLRSY8c9dZDHf/ikpBDa/e7/+Zguot2+ibbSQgocl3/AZVYRe337jZ5iMvFBwiVqK0IRvXwoUtK3BF6yV2XnsWgyjfApKQEqESABX1mhtvPQlkFWAZ+BzyttKXUKtZF3LmMZZrAp4HVBiI5Douvb4jZmkGkiptD/Fp9+4zlSIC1SfszOiAYJK+jxk4NQG/WzXU12ihrOPau5BDEQJ3psmn5bV8GoYkPSN9zM1/237YymJfxJhjP6X1FkNvdcdE6jMRx4BO3572l6fYI7LaOgwHHw+Dpfg9ZHyWiJGEqxiG8UzXKcn4mZu9xwR5m4vzg== Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:de::14) by YQXPR01MB6592.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:4d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.18; Wed, 13 Apr 2022 01:04:05 +0000 Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::fdb1:ada8:7af0:3003]) by YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::fdb1:ada8:7af0:3003%7]) with mapi id 15.20.5144.030; Wed, 13 Apr 2022 01:04:05 +0000 From: Rick Macklem To: freebsd-current Subject: Sanity limit for length of user/group names? Thread-Topic: Sanity limit for length of user/group names? Thread-Index: AQHYTtGfx/S/qWX1pEyPaUr1cRjzAg== Date: Wed, 13 Apr 2022 01:04:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 170a6730-8de0-0a9d-1ae0-77bc17e7ed84 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f3e841d-fbc2-4b85-0d5f-08da1ce981a2 x-ms-traffictypediagnostic: YQXPR01MB6592:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iBF930I562W80VAxuzNbHjicAOYQXJM5nZD6drpyrS2wz5ZjpJXphdY0DYwRsh6Yp6Ozc+UgzcnKX6a4a0AEZIQa8aVMryzCXbpkf0V5zpCoU1xF2kgTFCsgXXsRF+4Zs6J6IwWso74+5ix1Is2QhnYT2/ZmK6RcuD9pnN0+Nzmzd7eHFMPLjTytECLeTNP+GssfSwp7EuxrV8oiO4nF5byJTB22EyBiSfFN4105xkVq601rA7QaCqlfmESqBqxfth73xMFuEpHi7cMCBLekvGUfTLYf+kLYzF90pEogJfBTWOLsIJaMYMaJA6dQbB6CDdhFsU65gG+FqwRksMFzIISK3FLtlthIONSbxntmIxmcfXHkQOtjWUUtIr1DnAXWHubk2iT+p9thA3UwmNOFVelzVxYAKrPZZnvXGufuJdCIsDmwxQCX/AxUxaYsDR96bUFAsMCbBfOR7Ku2XcGYgS79AINAxJArHmxmfXkX/3ne8IZuxAFRejgDShxYO0JHJn9vHpFCJ4v3bLUMZD64dATKIxPuRiln+/tHKEPWN5itdUnei8SCPkUTqmo6nUYk1awDhgX8K8h1fODNO9dZB1uCDpLB8aH70ZiXrQ7o5E11773W/AMJqGXabPowNTtISehvPwOGAMlnmk9/Ka7rXjoC/ZBr6bG13N8QRQ1/h/o9ooPsVgcmmC0EvrJ9jS4pMpc9iHgaTbCAUvXYRGWX+w== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(2906002)(186003)(83380400001)(9686003)(7696005)(6506007)(786003)(6916009)(316002)(33656002)(86362001)(508600001)(8936002)(91956017)(4744005)(64756008)(71200400001)(8676002)(66946007)(38100700002)(5660300002)(55016003)(66446008)(52536014)(38070700005)(122000001)(76116006)(66556008)(66476007);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?1pOm5zGjZ79SlESy+tprMJ0BFnm/6thkF5m2at2SW4H7Q4A1aRthVX24cJ?= =?iso-8859-1?Q?UCE09U/SNmbraO7eLT8axNEBhSNa0TpAIzbKB5/fdFVKEHLm5JlI39igor?= =?iso-8859-1?Q?dMFCkpbAstKD3nvStkTo3HsebSF5gopxsG5bYcgTreUJIqaQjuFCflCGVc?= =?iso-8859-1?Q?Wy3Pmc0Ghed/HMWkGq3LXjKndJy3xZ/DmoZr6rg1V0dPtRQnlkaMUfR9fu?= =?iso-8859-1?Q?FJQiToLlHAdXrb/N1byN4I9dJuKBok1Vo6/TkQ5zqR6Sw88aOkdgvc/2K2?= =?iso-8859-1?Q?Dsqj+A/gm+jEcQeG3+n6UI3KgXBiB76M4R2fCh+SKu1Qm7iDg/Vjmme/W/?= =?iso-8859-1?Q?BMXyoRQ7mCMKxoHIdIeMWETFE+KlS8/wOSBy6rJqwXsMcAItqYPHaPFGaW?= =?iso-8859-1?Q?jrc1YpwIqg4P0Ah9G/3T42U/Spswn7nb1VSqTlpP7HV4v2ya8ky42ca/Ed?= =?iso-8859-1?Q?T0rM2NXD/aAM1NIQPpz7/L08HD5hRkdS26Vy9OFHbAY0TR2oNMabcUK888?= =?iso-8859-1?Q?p0USrstlwkl6Li4u06OWmug92/DkdBEIBnNP7mLblGCftMhBL9bqccv66Q?= =?iso-8859-1?Q?HLjai7H420zH0TD3bpRt1lHU56bxSS3riBErK3W9fZA/ziRHZ59iLGo2Bo?= =?iso-8859-1?Q?fu+FMGA7t5ixPsqBF147Z5xfEBdJl6sufz/cR6pwvg164yReSFj1Pd3/ce?= =?iso-8859-1?Q?1UQE3S6tE7ifnjknJoRFLvikoAJMmHKH3cufmJ6hSlZT49ggHqTm7hToLJ?= =?iso-8859-1?Q?3g+cQUjfmDi1pddVIeMeU/Skj/klh9hjudTGNNHkqv4lR5crDMDHQhT1fO?= =?iso-8859-1?Q?GuHc4+mTp93V/bwdMKzJmzDRq/6vJKC+Ip9gnXkbwKNs/ui0bIRmgDMFkb?= =?iso-8859-1?Q?HCoQQF/uJd0z0WmbK0v9rUck3dpXOtkMyuC3s30fwygTt0J0gHiucOfpdN?= =?iso-8859-1?Q?At9ptxFz2633TFfEgecvcs+gsRC1ezLjWa8F+tKK7LoAjKPDU8QIe07t6u?= =?iso-8859-1?Q?MiXX+qHCudSwpHb1cJ3pWb4UcsyGL+QYM09KMfI/gLyzcXuXUedqrqHucM?= =?iso-8859-1?Q?uwIfcT0VR7o3yZ2tbj4Bu6HdSEadQot2KxUyt7W/WT0fHxdf1GWUB8At8O?= =?iso-8859-1?Q?WwHTaSeJm3S3yGH3fZM7zRNX16Neaobg96PyD+sQEwqEACAUDfR2utnrGT?= =?iso-8859-1?Q?uNBGT07aYrEDVqhVeIuk1HIIWu6mu6BMkD1EX8K0rK3wFG86qoBKQlSggy?= =?iso-8859-1?Q?V+b3jheOQIcpYqWPzV0BicaRwqmlsVxlACgdDK4y3azevd/iQV4wP0oY7X?= =?iso-8859-1?Q?LnG3x+x0F1l3dT7Enqx5qa7sxiFqLodA2yaT97kqWu8gHaBbHH3uskIPYf?= =?iso-8859-1?Q?95OHKSM3srPYq/DzAZ3EQpbWCq+5tgDhAexzSZsNwBNtTWgbLFiWcHsMi6?= =?iso-8859-1?Q?5qRJYYhd6ys6XA9x88X5ErA9t3Cv+UXL9al2gqOoqy87jne6gKPFdebgu6?= =?iso-8859-1?Q?69NDx7xWk6vYR878dYKvZ49ydLuow+xn/TuW9YWU0sPw8Kh1LpwWFOphuX?= =?iso-8859-1?Q?GD7Kbe+xkVaZcDpA0MyEC9aj0+n23tAaJwgUeQPPjYQxAEQC60W23U0bS8?= =?iso-8859-1?Q?jZv54HPNqeH69W7iXVao4qSB7DoROANUDMpn27yvhqQn5EmK197p8Y7jbR?= =?iso-8859-1?Q?PgwAJhapX6WBtdpPOHZ0uCx/7SN+VAGu8WElLhz6EnfpCB00Wlyuy+mDN9?= =?iso-8859-1?Q?iC6OLWeC0uqDphYuYiD+iwWRmUfC9x7Dv7kOtoXIGKFv6A5FVlAI5nWGgJ?= =?iso-8859-1?Q?+dG1kknulsYNdzk0Gf6ikOzqkwkRHKkQ5ZeeNKey+dRZmgCdRcNciE8yhs?= =?iso-8859-1?Q?bY?= x-ms-exchange-antispam-messagedata-1: HHRFONvUblJSOg== Content-Type: text/plain; charset="iso-8859-1" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 7f3e841d-fbc2-4b85-0d5f-08da1ce981a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2022 01:04:05.3404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ITOxUKPdFLlQAYr33uMiRlgDECehKgAZztWk/xccT3jSb5lAV2QupjlEjUFxFTo2C18wPvZ/aYF7phJ7z7dItg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB6592 X-Rspamd-Queue-Id: 4KdPW04j8mz4Z0C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=NNcV6Mtj; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.51 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.74 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.26)[0.261]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.51:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.51:from] X-ThisMailContainsUnwantedMimeParts: N Hi,=0A= =0A= The NFSv4 RFCs do not specify an upper limit for the length=0A= of a user or group (called Owner/Owner_group in NFSv4) string.=0A= =0A= However, PR#260546 notes that a sanity upper limit for their=0A= length is needed.=0A= =0A= Is there any constant in FreeBSD that defines the upper limit for=0A= the length of a user or group name?=0A= (I can find the maximum length of a hostname and I think that can=0A= be used as a safe upper limit for a domain name, as well. The Owner/=0A= Owner_group names include "@domain" on them.)=0A= =0A= Thanks for any help with this, rick=0A= From nobody Wed Apr 13 01:31:20 2022 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 D5BB211D6E12 for ; Wed, 13 Apr 2022 01:31:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdQ6V1Yp8z4gQR for ; Wed, 13 Apr 2022 01:31:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649813482; bh=ABcMpmTVze37fXj9i38QUSEFsoObloa6ILfEwAARhWA=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=KUBnw9FdU+uj8OMRnyrTQ4HmSJ3uMwoJp9WZBW5nzIk6HUDIfXiggQ0upZQm596+FWbzZQzXW3706NZmNbQ5l6gr7PNsaIXnV5FjGc2E012sBvaDQKFBHLkYYRlpoBo357w8KdvSOB8JAKpT1CAUl6ar/3QlBQOAxo7ms7tf/8ClhTa0eMTTabIlfQFEibuKnk4GJ0V4Oh6B17zc5njJ2VMHt8AzFATJCXOv7IzzwVykrLAyVrfMBoF+6nYKo/K3KKaY7iGds1tCMWyOj6ks7lHXuPKUAZyDoxyTAmw2z8N7r/joubzIfc5UnEXn08PZbxaEFEvjrgZl5koGkeAHZw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649813482; bh=wixBfC+DHnhtZL+WymlbSUCw8gFvb4Qrxdk4gvaWK3x=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=nNpTNIguxk0rhlOVS1xZ/Y7r7cfePW2QIrQVQkl8f3uF7JNZWs1xBskyc15twtyeD+1dtWSJOt5wyOFFlQ8dzKelpXRuwsn8IhbvjH8Gtr0Aw6l3ebKFnUG6xzsHDdTODG427TUTH3NAZe+b95P391siBXDqgbYwTwQ7XFoRbx/uyZ4eGIZ21GE0KdQsChYnS1iA9D7T09Lk8tQxt1swpnfKyVOAiRHiyqUfzRNcqaShOMeBcCm2BvSfpdQFlGiREV6kTzbhI9VWm5OdKMDPJcNNUYMraeBuFPWZe8JgJfXRahkuwtavJKzh0wB3Ows/r19sWsO4MYVPDnB/YByybQ== X-YMail-OSG: nlAG9FIVM1n4c2KIVjKELnVKr70T0qH_fCIDGkgC5yuP5b9XWIhxV7yIuurY1Zh SNVj5bg7rBIA.UynoSKVGyoG9cLSsc5orb2iF9qmoLVZR2L8fEbSYdivGfS0jZwMY6uvhJiJ9E1R ikqJOUDK9FLs8YsbYAevaC.KhhrbVLTglKD0SlqFPNwP7PGW9MBa0BBcrq5Weoms8pvBuowbKUHd K0UN1joH1LVjf2Qoy0.qtCsUv8mSIayMTEltFGyvd.6g5bbBNj62xszMCE0njpI7WB.s.ZXEpKoR _JG4LWlUoLXH60muVlaR3GWxXU2XJvGLqZierbv6RCUIwd2a5uqy.t0zJXJFeH.MDPumsnpivTmS .WKzNG3F8nAaARlUV0LrkKmHmVlOxaNgYc_obI0wX997fCJDhcHJqnAvIu5KFt20t79.FUSDV4oP WaFTqbu2YUdxLXtF9xvXXO4Zm2H2z9g4Wm1i39jV8s9gnfD43ABDmMreUUp5RVfdW_kEle1LnUZr lb9c2WMTHlqUaRaY1jcz27GBgk3yNd2ZI2xnLt921r54xQH_BI5wIYpJOgDMkHE84Yy3NYFFV_2b JrqtxlB1KF_Bmhl.GIZ2CtJ4MHRBh4QvquZZsHqqAhIWslJMo40r1FGhjaX7e8jJVQnXhJvebnI3 H80D2P5VuMyQ6o0ANK08KCJpkkeCs.5iI697OVIWcHCQSkySBi1q1uwEm9jmpkiuGK.euRStOTyC MVV5zaxSR4h4gRdmFl_nTPfT5lIPtoaiFDdt97EPfHZKDW0Fxgb8aDdBtwUoJ.eFjJiqxSqkuhqo BVWOIX282rutwaPRGqeuvn4TGlxRz_LIJFZ_h9AmXXiGLdQ7BRxM2A4JDypURUupq7p1aGJd1ltd GRI4KahkEinZERh1TOjdx660vZJ9d3pVUhVqOeXF76vSmufEoO7ztx40.SY6vAn887PZEV0ksJC2 elrv6mGJ2ZoxrrPzAJweBDClB0s6Gu6KPMS_a4YaYi_kXNqpb1fk.Vsx__nPxUU3pc8xDZgEjWlh D556nmgmtnnHVd7E7g8xa6XxLLsOEhVeZbygtBjCpLTPAocsowZTvkpZkzCL7EzgW9QVlqKAg_jD Oar3d2zPU0VKnAnnK.HSCkqQmurdgUcpTowKHn0Dx5N57bUeNsRaePrmPz8nc0YaJSAPhzYS7fSt okNob_Jl1gGg3pIgosorohMerE43BvRBjI.lNYFcipCcH4IAJgHJmj0Icyz73UeOn3vbm92oBJ_d JNtXUhCo_12gKLsCVfOVmKP2Zswe6crutMBhw2b.shK3TtWuZWkkBpMjvnEbQdDIbknzQxmW_F1t i5NdAaEzIuoQiT28KM8WJKWPOpPTKkxVRf.Xpla8S25CkVYV8idaR.03Glf8TYSSEyQfXAZjD3p4 9aMBDrtvezyahBZGsauw1fXUJHIYH7C.7WtTuVqwxylrX0uufxCZnWv.CSBvgKPYVWAN3b4RpteW ozZZ0aL3LvncreLbLRjWXfeOOcvCLAm3AFXvZmjSJGQT1Lnq4ExFi6ReB6qsQhgMJ07iJ5TNMxmN hnDCp3K3olT9hNPdM0pVFDMY56gvedCcrvaYRELDQcKznW1EKSFIk1LaMjaviEuTLnh2TDl6e7zy 3cwJkKEwPkAzoOp8q5_k4SiGY5iu1RhJIe.U2IN_0k6t7xMrxprGs1tTSIWTFYkQB8WjtvjqkPQl P5qemoz2xM3xoSWkRXklQlGzJeYtUuzzowBZTZGFqXOzY7_h.FW0ADxps4Pe7PU84TcMqv3R1IOH msgVP8ZzNf9.QKHhmfG1rPZYF6hsA8Bdii06hEv6zxDFUgBNjfnaexoZBLjf33xkKDM9fUKdZJCo hzbEs3o8Yc8LyalH_8Kptta4XEafw4ZJT6hd.ViGPXLZzSlzg8cIwZ0LmdlmAr6P1KrHliUxV__U P0SzmMpTSz_igh9wF2dYg_c.rfJf1Ja7FZtqWg2ygEVjSeeJpEMIvoZeCEEKnXlw7XhkFLRs0kGE eQjngVhhHOdiVnkDlFitNnzjHEGTciDnOxKR2LMkAxShy.uyMVFL23ZPbea5DeYQBl9U3fX3v1GY Cpk0F2vE1iJMQmU_XZMH6UHrdsPR5cALsS2dN7JOwemwuIKSeDsXxO0bjZVLvTXU_FjQvY9DOe90 JisrC.p.12Da2ViZZCAJsZDdHdTB8kAoqppcymA2T.ZKE_.LpjgD6_jM6j.4W505GS1YCO2vMHTy 1GxeZz65zJ1sC6eF9mn8PzbhM9tUt2oXBqSoOvwiG0l5dgv2ejYJh1PceNB7J9oYRq4X3vn7MFf1 6Wy_UiU0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 13 Apr 2022 01:31:22 +0000 Received: by hermes--canary-production-ne1-855b9c5d98-4qplv (VZM Hermes SMTP Server) with ESMTPA ID fd8d8c3667070cab7e2784b2dd44640e; Wed, 13 Apr 2022 01:31:21 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" [zfs updates in the identified range] Message-Id: <3ECD3E5C-05F0-4D81-8A30-3182DB127F1D@yahoo.com> Date: Tue, 12 Apr 2022 18:31:20 -0700 To: lausts@acm.org, Dennis Clarke , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <3ECD3E5C-05F0-4D81-8A30-3182DB127F1D.ref@yahoo.com> X-Rspamd-Queue-Id: 4KdQ6V1Yp8z4gQR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KUBnw9Fd; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Most recent good of good->failed update step reported: (extracted from dev-commits-src-main but shown in increasing-time order) Monday, 28 March 2022 =E2=80=A2 git: 1b3af110bcd5 - main - uudecode: add missing test = files to Makefile Piotr Pawel Stefaniak=20 =46rom there, zfs updates are: Tuesday, 29 March 2022 =E2=80=A2 git: da5137abdf46 - main - zfs: merge = openzfs/zfs_at_bc3f12bfa (master) into main Martin Matuska=20 =E2=80=A2 git: 8d0b6a7d4969 - main - zfs: update zfs_config.h = and zfs_gitrev.h Martin Matuska=20 . . . =E2=80=A2 git: 40c911e8da50 - main - zfs: use zero_region = instead of allocating a dedicated page Mateusz Guzik=20 Friday, 8 April 2022 =E2=80=A2 Re: git: 0c348b97eb05 - main - zfs: Disable = -Wunused-but-set-variable for a few files in zstd. John Baldwin=20 =E2=80=A2 git: 0c348b97eb05 - main - zfs: Disable = -Wunused-but-set-variable for a few files in zstd. John Baldwin=20 Note: bsdinstall was not in use/involved as far as I can tell from the = reporting. So I've omitted the reference. Oldest identified failure observation for a good->failed step: Sunday, 10 April 2022 =E2=80=A2 git: d4e8207317ca - main - vmm_instruction_emul.c: fix = bhyve build Robert Wing=20 As for da5137abdf46 : zfs: merge openzfs/zfs_at_bc3f12bfa (master) into main =20 Notable upstream pull request merges: #12083 libzfs: FreeBSD doesn't resize partitions for you #13106 add physical device size to SIZE column in 'zpool list -v' #13158 Allow zfs send to exclude datasets #13190 module: zfs: zio_inject: zio_match_handler: don't << -1 #13219 FreeBSD: add missing replay check to an assert in = zfs_xvattr_set #13220 module: freebsd: avoid a taking a destroyed lock in = zfs_zevent bits #13221 Fix ACL checks for NFS kernel server =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 13 01:49:22 2022 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 825241AF3255 for ; Wed, 13 Apr 2022 01:49:37 +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 ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdQWN47l1z4kLH for ; Wed, 13 Apr 2022 01:49:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649814569; bh=irLhb/Y1JNikYA0iPXqblVbqFZf6b+K5BNzPo7Qe2LA=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=tf1GCRGqp1O5ipMihEMFQrH1nMegEtaEVPxXqJc1zYSq205TAg9C9p451pahP3easYVkq+7++t0xYxNB2nRpMbVGCKQa62haGpxPCCyPiUVHXAJwXi8wdRPP3YZQ9mNs5x1AJ4hFge4tE3bjOWlDM9Y2/QvPQnpZbzARJicEIVF5tV+037f4qJjFpIdDPSFtmKC0HAhROqz6ZVj31gl+ZKtVmCS93lyqJ2pafMcCJFljREz6xMWVoap+jJGzzEx6v7wCjl1Qv9dmf9DhJgJqp1SN97IBg1UnaoanA7qZdVHTl2pHB2m7jCmk27Evku4QWTETjUWzKSu+r8eud1GJVA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649814569; bh=xrwOn0V3hlJ5v0F7QGmoD4ZBxU19WPyK+DEwWbnsYWw=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=PB7BgEvevEOjC2cNdpNCQSXZenyOoFAsincgMnGmOdH3DToy0u4LDsSZiBI8Gy0zruaY1pD+Xre8OGi/Z/GI9wNECcChPEhY2xpcgFL4yNC7F1xrsFZpDzZtfL1gJa4ltllWpmMqkER4na68NoqsWfaylfLiT9VPJPKKGOBZIAqEzucHrtDwQaRCuZ9fTvEOoK9nDUSH0c+7GjKBUfIqSzONq5gKgh7fUioPmKaIIuIfFlEgEJDQFGkjGCy0cj84IwfoJERMoChpua2jgnOvRKVBLWL8kPrB4gm9dOHTtvn4Bste321JsxWGfOzYcGoaI7t4xtdZQo2eOq0lKBysjg== X-YMail-OSG: SFfBzXcVM1lvUpH2Cl2mmtgLgR756c1KExv8z6GYrLMDSl0n_tY3uLzZ7Sijocx TFboHq44FXg9EewPr05UpMHlRklW1jjmKdfdMDbRAvyn8GYmioJ5RKflTX6QEB7hXRZUDOEmSCm8 Ezp5V_TL14iVW0Cv5UK1DkUy6xDhGE.pIVudhAjNVxgw5g.cxd1hZQVBMAlrJM4UB9aqVuS3QbA_ gUMz7Su705AYDXmIyBCKOLMe8pbdjm0r9YNSwi74.la.cf1Mhhxz1FVpfES.6iYQ3TRyR.Qpyxek zseojAbre8Dh4TmyMaNQaXKGB0YcHPqyjEX8h6DojIjv9FvE0wKS80Xdx3CGjMw7j8cwjd1zIdSN quukMpjHIGnESbAft4Ie7Eb68LGelGT3dTTok8BqdMZyzAjAyiq7fJOne.I3q3A2JOzsrF4XshLc C1y2XlIgnikOcKTDrIdxkLkjLryBQ94So1TDL6lNatiimikx4sPsGNcn0j9XhupTxzjFPqviC6wi y_MJqBiDTL_1D6hDfWOuf7.OoofX3pKxRXJCpPvHIc2j1xbU2JgYYX3Z1ozhQJx8U.g40YTxq3Rj yakFxutH4CU7kgTGJbnpRbQ6G0eslth3fohigVyHjJpUEdbgD7dtvrTkLnywJ1d7C5dC4VMHeCaT 4iwkbzjordiegRaqXc1bwVg_j2UrZ.B3JpEUW.Sa.u9ngBnms1nVXLTbWJqpDsrbqPGsXa.IIu0l NNSDj8hrf9HLn98RweJuz1v92AJH_8wtD173aqwnOiJqlT7jKrLsz_FWIoMmNGQuIwQKeFweQdfN Jhxr8Ev16YSDxEfQnnUSngbjOpYAhNwCjqGmNSYrqWnA4LjORyDubjIB0phj4FxCYwtL8Nf9JjvF BaEVlN7pgf3ghVe1d6dDciSwYs3oTumB9b7cbHGh_paNalBNjNeEm1TMV6uHPa3GVLn9FBvhLHxS muDAHEvg2gN.60fP6kpSDcjbs7DXXc4dXZIGmT7KGZq4pHLPcFrRvIumSNb690Zs25FCSoJ1ovp_ r9A8CblF_YpapvPgRFrm.Mxpjx_tWAhPlTdQL3e8tGj1ZgU9evgF3QQYlRDaChXobUXE67l3QmCJ C4FIXuLqfnT8mj_xdzuMrz_NG0M9cUWYuLt1pRHYy7xI_h_6IFCjsS1qfd7tUtnQ7mZKzKArCJR4 E_q0PoeLRJq_5pIn5ynz7HS6ZHBwhrUg3q2_3FENq1nQSzzaejU5gvjWBqilj0Yt0MjO81ZF0ANP X6itkyC8YtWzFyxbIWMhACdejmviC4uUvEAJNh.ZbkRaq8eBWvAywPWkJQtyc511HL506UdNOkdl HcTFqF1jf.NyAqCSryo9ufzXxWbU9VMHaKjmJzAdD_ReGd2zwiaGC3R8MLCsviy23L51bT41S8LJ 4wLAwYS.VhdxzNLb53LZb36PH0xYJj0kOGLTs2pRxfgne.e5aXYEglN52dAMZnyIqNBVW.RD9_kF sXaW61BQjbQn5KhUXB.9UDxOaueKvrxrM9tr.GwieRE4DlHw74mlAiqlpjcYu_bjMZLeaMabwMdJ iOSS.5BMYW3v38CcHKA8phHU1ywpGH8uKkMt5mZWudvSjRD5LD.sak2MCYXnra.E0hKYzpzPdhaR 23iwuAZD8wyeTt1.CcNJjnvRXEcNfGMADU1pwzTxUNJbHTsVti3EVE4yl.wJxqxvLd_eQRha_Jmf uqbYr7Zux6WtIRWko2lymUhNEwVtCPNw3RhtOpr8kNMmXckicKYnfbNq19hn9LqSGgCYbuRj60PD OtnaxpTHife6t9uxI33rt1hEn6eafmWniCIysiAgkfJcToWJkF8EJcSfjerBYKWj06nmSW7hpJv8 Po_Zrr5SP67uaQxRpNEn6jHzC9ckGVqqaoj8a8SoEBgFMMn62XRIM0csGgRkIfHcXpM1knZBvWe6 p5PDhFi65dk6_t1hnhPHJaD5g88Yi_fBx7I8B2hsQ_YtdU5MzKy_e.p12YRIzvtCl22Zv8w_yfaH 5YQX5TvkAK5GOFaQ2b7TQZwAUtYh3MeTnOq0SgFeamlfVs5iShO9Bsl8UE8ZuvgsXLcRHCsHTtJD j59Xnph0sn8BdvcLYVGsYZ9ybSBTtmMIt8NzAVfG1fw4sxS6bAvkgzXu9zynBW2C87yqIpzmDJcr biy_54N3cICR2MOKlxAAZ9ZYegLp.GWwAmBNZTFGEeAElCuS01a_fALdfE21Cx9_nAuSFfxYf3Z_ eGXuDL6aOEUHKfOURTYLBtTgIzDmTRXVhISrgbskhi5WBdwJEDYdL5.NCuCcKqLgqAg6CmYV_ZF. l.Xs- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 13 Apr 2022 01:49:29 +0000 Received: by hermes--canary-production-bf1-665cdb9985-5cw9w (VZM Hermes SMTP Server) with ESMTPA ID 251551f4348d6f4e203bc4abb2296818; Wed, 13 Apr 2022 01:49:25 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" [zfs/ACPI/NVMe updates in the identified range] Date: Tue, 12 Apr 2022 18:49:22 -0700 References: <3ECD3E5C-05F0-4D81-8A30-3182DB127F1D@yahoo.com> To: lausts@acm.org, Dennis Clarke , freebsd-current In-Reply-To: <3ECD3E5C-05F0-4D81-8A30-3182DB127F1D@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KdQWN47l1z4kLH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=tf1GCRGq; 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 X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-12, at 18:31, Mark Millard wrote: > Most recent good of good->failed update step reported: > (extracted from dev-commits-src-main but shown in increasing-time = order) >=20 > Monday, 28 March 2022 > =E2=80=A2 git: 1b3af110bcd5 - main - uudecode: add missing test = files to Makefile Piotr Pawel Stefaniak=20 >=20 > =46rom there, zfs updates are: >=20 > Tuesday, 29 March 2022 > =E2=80=A2 git: da5137abdf46 - main - zfs: merge = openzfs/zfs_at_bc3f12bfa (master) into main Martin Matuska=20 > =E2=80=A2 git: 8d0b6a7d4969 - main - zfs: update zfs_config.h = and zfs_gitrev.h Martin Matuska=20 > . . . > =E2=80=A2 git: 40c911e8da50 - main - zfs: use zero_region = instead of allocating a dedicated page Mateusz Guzik=20 >=20 > Friday, 8 April 2022 > =E2=80=A2 git: 0c348b97eb05 - main - zfs: Disable = -Wunused-but-set-variable for a few files in zstd. John Baldwin=20 > =E2=80=A2 Re: git: 0c348b97eb05 - main - zfs: Disable = -Wunused-but-set-variable for a few files in zstd. John Baldwin=20 [Adjusted the to match time order above.] > Note: bsdinstall was not in use/involved as far as I can tell from the = reporting. > So I've omitted the reference. >=20 > Oldest identified failure observation for a good->failed step: >=20 > Sunday, 10 April 2022 > =E2=80=A2 git: d4e8207317ca - main - vmm_instruction_emul.c: fix = bhyve build Robert Wing=20 >=20 >=20 > As for da5137abdf46 : >=20 > zfs: merge openzfs/zfs_at_bc3f12bfa (master) into main >=20 > Notable upstream pull request merges: > #12083 libzfs: FreeBSD doesn't resize partitions for you > #13106 add physical device size to SIZE column in 'zpool list -v' > #13158 Allow zfs send to exclude datasets > #13190 module: zfs: zio_inject: zio_match_handler: don't << -1 > #13219 FreeBSD: add missing replay check to an assert in = zfs_xvattr_set > #13220 module: freebsd: avoid a taking a destroyed lock in = zfs_zevent bits > #13221 Fix ACL checks for NFS kernel server For ACPI and NVMe there was: Friday, 1 April 2022 =E2=80=A2 git: ab71bbb75a92 - main - acpica: Import ACPICA = 20220331 Jung-uk Kim=20 =E2=80=A2 git: a70b5660f379 - main - nvme: MPS is a power of = two, not a size / 8k Warner Losh=20 =E2=80=A2 git: 6af6a52ee47b - main - nvme: Save cap_lo and = cap_hi Warner Losh=20 =E2=80=A2 git: 161fcf79941b - main - nvme: Publish the drive's = capabilities Warner Losh=20 Saturday, 9 April 2022 =E2=80=A2 git: 214df80a9cb3 - main - nvme: new define for size = of host memory buffer sizes Warner Losh=20 (I have ignored comment typo fixes and RE: messages this time.) =3D=3D=3D Mark Millard marklmi at yahoo.com =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 13 06:35:59 2022 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 3F5541AFE50F for ; Wed, 13 Apr 2022 06:36:03 +0000 (UTC) (envelope-from SRS0=qXL2=UX=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 4KdXst2GfFz4Ql9 for ; Wed, 13 Apr 2022 06:36:02 +0000 (UTC) (envelope-from SRS0=qXL2=UX=klop.ws=ronald-lists@realworks.nl) Date: Wed, 13 Apr 2022 08:35:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1649831760; 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; bh=UBLWruWNvErnUuU8ocE5M0CCyiCAaI7owNZNn8KjgR8=; b=fc6wEfqTawHoZuS5hTjVQYGIZEq7Iol4GhWP4WyeyaGfLZkTgLjlckHaoz6mzTK3WcGEnD boAIXu2lHfJRh/VmBDUS8uZnEEyiKesrSNWtwTLuj2AWLEH6r7Tpvtyye6dLRL+l7LYEM4 n6AsL+4X6ydqoWX/yWLeI4E7/KNi5bN0EWT0z1EX7VuoGaDsLcGYZFGZtMwTWeu1VN8Nf4 q1RuIABSqtwvh3vwH0PvL7+9Q6nwDBDLikOLZDxS1T0rHnV91v52egxvewLOJchAnJnb+4 pO1aPXFL/glVedAbChU9woqd9OXHjVzzTbRxNYCgQ3Poxp+2DEYJYqetS5Ihvg== From: Ronald Klop To: Rick Macklem , freebsd-current Message-ID: <837488522.1046.1649831759547@localhost> In-Reply-To: Subject: Re: Sanity limit for length of user/group names? 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_1045_1422177910.1649831759544" X-Mailer: Realworks (602.70.2cf484b) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4KdXst2GfFz4Ql9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=fc6wEfqT; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=qXL2=UX=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=qXL2=UX=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-1.68 / 15.00]; MID_RHS_NOT_FQDN(0.50)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-0.99)[-0.990]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RWL_MAILSPIKE_EXCELLENT(0.00)[194.109.157.24:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.51)[-0.512]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=qXL2=UX=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=qXL2=UX=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_1045_1422177910.1649831759544 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, A google search gives me this page: https://forums.freebsd.org/threads/username-length-16.28189/ . It talks about MAXLOGNAME and limits in utmp. Regards, Ronald Van: Rick Macklem Datum: 13 april 2022 03:08 Aan: freebsd-current Onderwerp: Sanity limit for length of user/group names? > > > Hi, > > The NFSv4 RFCs do not specify an upper limit for the length > of a user or group (called Owner/Owner_group in NFSv4) string. > > However, PR#260546 notes that a sanity upper limit for their > length is needed. > > Is there any constant in FreeBSD that defines the upper limit for > the length of a user or group name? > (I can find the maximum length of a hostname and I think that can > be used as a safe upper limit for a domain name, as well. The Owner/ > Owner_group names include "@domain" on them.) > > Thanks for any help with this, rick > > > > > ------=_Part_1045_1422177910.1649831759544 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

A google search gives me this page: https://forums.freebsd.org/threads/username-length-16.28189/ .
It talks about MAXLOGNAME and limits in utmp. 

Regards,
Ronald

Van: Rick Macklem <rmacklem@uoguelph.ca>
Datum: 13 april 2022 03:08
Aan: freebsd-current <freebsd-current@freebsd.org>
Onderwerp: Sanity limit for length of user/group names?

Hi,

The NFSv4 RFCs do not specify an upper limit for the length
of a user or group (called Owner/Owner_group in NFSv4) string.

However, PR#260546 notes that a sanity upper limit for their
length is needed.

Is there any constant in FreeBSD that defines the upper limit for
the length of a user or group name?
(I can find the maximum length of a hostname and I think that can
 be used as a safe upper limit for a domain name, as well. The Owner/
 Owner_group names include "@domain" on them.)

Thanks for any help with this, rick




------=_Part_1045_1422177910.1649831759544-- From nobody Wed Apr 13 11:17:25 2022 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 DB2141AF7F0C for ; Wed, 13 Apr 2022 11:17:31 +0000 (UTC) (envelope-from 0100018022a47721-e6e3ac23-8639-4b94-b3ae-eae4bcfd5493-000000@amazonses.com) Received: from a48-97.smtp-out.amazonses.com (a48-97.smtp-out.amazonses.com [54.240.48.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kdg6g2fdfz3NML for ; Wed, 13 Apr 2022 11:17:31 +0000 (UTC) (envelope-from 0100018022a47721-e6e3ac23-8639-4b94-b3ae-eae4bcfd5493-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1649848645; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=Zn55gIzr3Ls3X8Ua8k/8JAsNZPs4kWKhZnGEfdJU1pk=; b=kmLBs4yH4txAYfTso7YgErLNiOLfTpDRhJXv+r/MIAAr7AVFdE02YgwHNSffb1EK /1ek93d7x5IiSQsZAbzb9kiadklytaOd1YLLA0NX1RiVvwIQtnffSU70g8QU96Wexzw 5uZEy4rBuH4UICoD2ouoYv5s6VsZ3aa/DqrF5V+A= Message-ID: <0100018022a47721-e6e3ac23-8639-4b94-b3ae-eae4bcfd5493-000000@email.amazonses.com> Date: Wed, 13 Apr 2022 11:17:25 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <093ec3cb-32a1-e316-a369-3a9e8559248a@blastwave.org> From: Thomas Laus In-Reply-To: <093ec3cb-32a1-e316-a369-3a9e8559248a@blastwave.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES X-SES-Outgoing: 2022.04.13-54.240.48.97 X-Rspamd-Queue-Id: 4Kdg6g2fdfz3NML X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=kmLBs4yH; dmarc=none; spf=pass (mx1.freebsd.org: domain of 0100018022a47721-e6e3ac23-8639-4b94-b3ae-eae4bcfd5493-000000@amazonses.com designates 54.240.48.97 as permitted sender) smtp.mailfrom=0100018022a47721-e6e3ac23-8639-4b94-b3ae-eae4bcfd5493-000000@amazonses.com X-Spamd-Result: default: False [-0.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[acm.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RWL_MAILSPIKE_EXCELLENT(0.00)[54.240.48.97:from]; DKIM_TRACE(0.00)[amazonses.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[54.240.48.97:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[lausts@acm.org,0100018022a47721-e6e3ac23-8639-4b94-b3ae-eae4bcfd5493-000000@amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,0100018022a47721-e6e3ac23-8639-4b94-b3ae-eae4bcfd5493-000000@amazonses.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 4/12/22 18:35, Dennis Clarke wrote: > I will focus on the problem case I have and try to get better > information. Somehow. > I had an idea that maybe a GELI encrypted disk may have an issue. Both my laptop and desktop have encrypted disks. The gpart partitions have a .efi appended to the name that 'gpart list' shows. Not everyone uses GELI and that may be our difference and the reason for not finding any pools to import. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From nobody Wed Apr 13 13:53:40 2022 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 A1EAB1AF01D5 for ; Wed, 13 Apr 2022 13:53:59 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdkbB2XBCz4V28 for ; Wed, 13 Apr 2022 13:53:57 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-31-137.area1b.commufa.jp [123.1.31.137]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 23DDrfJT091153; Wed, 13 Apr 2022 22:53:42 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 13 Apr 2022 22:53:40 +0900 From: Tomoaki AOKI To: Ronald Klop , Dennis Clarke Cc: freebsd-current@freebsd.org Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Message-Id: <20220413225340.a610f6528c2c5dc6937ed33a@dec.sakura.ne.jp> In-Reply-To: <585833961.324.1649766560673@localhost> References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> <010001801d7dde5c-332ee2e3-0df9-4112-9081-46d99b689ea5-000000@email.amazonses.com> <585833961.324.1649766560673@localhost> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KdkbB2XBCz4V28 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.36 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.76)[-0.765]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.31.137:received] X-ThisMailContainsUnwantedMimeParts: N On Tue, 12 Apr 2022 14:29:20 +0200 (CEST) Ronald Klop wrote: > > Van: Thomas Laus > Datum: dinsdag, 12 april 2022 13:17 > Aan: freebsd-current@freebsd.org > Onderwerp: Re: main-n254654-d4e8207317c results in "no pools available to import" > > > > On 4/11/22 14:18, Ronald Klop wrote: > > > On 4/11/22 17:17, Dennis Clarke wrote: > > >> > > >> Did the usual git pull origin main and buildworld/buildkernel but >> after installkernel the machine will not boot. > > >> > > >> The rev seems to be main-n254654-d4e8207317c. > > >> > > >> I can boot single user mode and get a command prompt but nothing past > > >> that. Is there something borked in ZFS in CURRENT ? > > >> > > > Up until now you are the only one with this error on the mailinglist > today. So I doubt something is borked. > > > You could consider to share more details about your setup to help people > to think along with you. > > > > > I can confirm this issue. My last update was 'main-n253996-1b3af110bc' from March 31, 2022 that worked fine. My update yesterday received the same error and refused to boot past looking for kernel modules. I did receive the "no pools available to import" message a couple of lines earlier. My hardware is a Dell Inspiron laptop with a SSD and ZFS filesystem. I have a little time today and plan on git reverting back to March 31 to further isolate the problem. > > > > Tom > > > > -- > > Public Keys: > > PGP KeyID = 0x5F22FDC1 > > GnuPG KeyID = 0x620836CF > > > > > > > > > > > Hi, > > Are you guys both using NVME or EFI? Just wondering if the common problem is in ZFS or some other component. > > Ronald. > My booting-fine installation is still at git c79331a42c308139828c1117f49224bb83617a53 and is using both NVMe and UEFI, but via nda, not nvd. Non-Geli-encrypted bootfs. Note that my BOOTx64.efi is not a copy of loader.efi, but boot1.efi applied latest patch uploaded on Bug 207940 [1]. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 Basically, I upgrade pool only when I switch to latest stable branch that is just created, meaning that the zfs codes and boot codes are basically 100% match on main and latest stable. This way, both pools of main environment and of stable (now stable/13) environment have 100% equal features. -- Tomoaki AOKI From nobody Wed Apr 13 13:55:20 2022 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 B2E2C1AF0BD3 for ; Wed, 13 Apr 2022 13:55:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660046.outbound.protection.outlook.com [40.107.66.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kdkcv5Lc9z4W2d for ; Wed, 13 Apr 2022 13:55:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m7WWjNb2E8XFtjd7XoaBWHja/fIwoEGSgR/8J4W1AFTxA39IRn1XLEAbA0altt7QbAAkQAimCWqRmNyGob+pkJsSowG5g/kp0Ro+Vp0UIQp76H7+3eleZte276pqNrTwVO/AwVehq/twBT4GQMludMaEzOSkIJDG225K9pXiahsUU0BLzxwVG5ojV8s1wB1NaV0+1mfJbnzx5e96IomwIYXc59kKkvKEDMfLyQiAl2e1xZiaWe25Vx7w4FGrcj679TKdl0eereVreHummUsGV5Ce5RrnqPYN7oiHuAE3rTD00IB3R0R0Wp33TxA07zMQ3n8DbosUhURUXo4766FtAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iogXiI1/IJYxDtpKD3Hl2aUus5h6+kpj0kI0AswNaEo=; b=RINHy0I5a5oISB2XY6VOgRHX5msGz/MNmAj80wuJHveMV8ZlLK/4kb540XZ/xwmZcX7cLU9LHcOaLDhMsMP8KfeUNU762uIfK9h9tebJ9ykNeZGUv949hJYQmuPeaKqBYqj32pLaHG4Bq1ELIEh6Rzcmdpvu0g9mfaQwJpMiwMcn4msJZHF/6i3Iv0RiiaCrL51VwA0G6ulbmzDvUzmm33E2hTONNBlbrF9QMo1VzBJRmhK+KDfrkuen2ityuPcFmSjzqwz0wc132DQG1BHGxqsR9kMGLBh1o3hv7+3ewfmsKcXnd6aZbjnqp/9LbY6C7M55p/DrzK01XLC2RHNqkg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iogXiI1/IJYxDtpKD3Hl2aUus5h6+kpj0kI0AswNaEo=; b=eXfwp4sFxUxhRQmGhbIlkZNanB5Dn0cWxbOeASaUs+xkSiNlUQ8u0kbY9hBVL6i9fnJU7/UTpVsgCQR27k6tHO+HaRt16q61rmqIz2YhmLM4kvARhI6wqETqD1HaFY7kIttANpfCa4omOhbrjRnG3/OMIpR/9qWzZIs824IWn9FwQcuJOSChijRE9PHVjLDcJNC3prAg5ZjA0LPCYHfIKU64TwjwlGY1OjD6Duz3sJTs0EfXl7ab2DwkEYOQHv9KAddDQ6pgcudaVcK28MiJoNUNCwUJ8I35hw4+fTqbLnTMReVLKhtDam37eqw+a7GhHGf4y3K0+rcGAmBYkDyRAw== Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:de::14) by YT3PR01MB5392.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:64::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Wed, 13 Apr 2022 13:55:21 +0000 Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::fdb1:ada8:7af0:3003]) by YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::fdb1:ada8:7af0:3003%7]) with mapi id 15.20.5144.030; Wed, 13 Apr 2022 13:55:21 +0000 From: Rick Macklem To: Ronald Klop , freebsd-current Subject: Re: Sanity limit for length of user/group names? Thread-Topic: Sanity limit for length of user/group names? Thread-Index: AQHYTtGfx/S/qWX1pEyPaUr1cRjzAqztY9WAgAB5OhE= Date: Wed, 13 Apr 2022 13:55:20 +0000 Message-ID: References: <837488522.1046.1649831759547@localhost> In-Reply-To: <837488522.1046.1649831759547@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 91f128ce-ae79-94df-4852-9cebce288edf x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1dc8507e-04d4-47fa-0cf4-08da1d554009 x-ms-traffictypediagnostic: YT3PR01MB5392:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VaL5oFDYYYc7Dmmiw2Q0x+COM8rMKH+5WcWm8aBBJKCfyQd/eSLAd/OUicpoGOR62j7QYYQp8S3WWLMmZPSzO++ODW8JZQm1IxiGUDJOvKBtzVK5vayWtKw1ndT2WASpIqMfPmygFRuAhzM55l3BhcohwV8rRm4TpXcZHOTO7cQdSIKAwmudRZLKMbcAW/RwbNmYRvjBggYod88zg7LT5BY0bMiQBYCXsrMvSY25Wv9jp28AcI4hI20F8pdZubQNProi8esevS9/2rrvSiiqeTbluWAYFlTKuzLGDaD4mv6E7GHLucGYxX2Grx/MXjoGCFRhVZlHxwj/KWdp8PpASsQOJ5ga6u+uoAyquRbGSnYRUdQYXRu50xs6/Uso+7w8VlmEcXFTEXa/u2tqlvF2I7jSFXKgEwtMY9wIZmbkM96FTzwlHP1CajuQozLL5JWMY0QlI6E00dTZt82vNYOAlkAQWy/1w8RA3momofyv6nIzfQd4VlabjRaYZ1xTCwcgnmY/tljAD/PSYKMp9yPFiGb944/sCh8U27Py/+f0b4LxLp/H/xZDNRbiRa0CUF8kadOf78mNKnPULe5zfBBRDyDQaORAEdcDRhGsxLQMBUYAAbe/FZNwYevcfGPTt1oq25EzvOTWbPbgqz4mvEoOCYEzn40ze9ZZFwOuXOPXrIc+jDBCUBEQre3qL7Ck4BomuaUy+msnfm2uaT2+T3h5FJ1Wd20bAKu1WwOJVvF4LKnUaRc3Q+yfRpLS6INkfEPccXfVzclDBCzGuNy9P2iyDUDUSDMeVcXbrCDqTXisHEE= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(52536014)(122000001)(33656002)(38070700005)(6506007)(2906002)(38100700002)(316002)(186003)(8936002)(786003)(66946007)(91956017)(86362001)(64756008)(8676002)(71200400001)(83380400001)(55016003)(110136005)(966005)(7696005)(9686003)(508600001)(5660300002)(66476007)(66446008)(66556008)(76116006);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?DrjvGdd7lJS/ajmEqOevGsqsBH7oWnXCDarYpbdOd0NpAe7WdI3S7zoJK+?= =?iso-8859-1?Q?nCQy2aKgo6io3R4+yu6+I4iJ5Ij4vYYPTPlx7YB8gi2wjz3bnDaZntGw7K?= =?iso-8859-1?Q?1dUPH2bLPa8c8fFFe1fHyEmlMP+Pz3j++NZxX5dQteWaUOojNGTfCFm5Se?= =?iso-8859-1?Q?QwCeGJ4q4i+AWfv7dGD+j9ek1WoOy4zKq1kqaRuS+sJ78BtcoQkSuvJ2Eu?= =?iso-8859-1?Q?eie5OfZv8MFPSUnNmWsAfcCQNlw33s1XPgiIgtsda9419pmsJfM98CvOKm?= =?iso-8859-1?Q?IZkbXRQHEsiokXHvdd8py8U1+1RiCA81HGQ0bxPT2C4W8hcroFd+L3vxbR?= =?iso-8859-1?Q?Kx+HIqwNUa4pDBHlqNPrdwJsvld1kmKKvzcEsWCVwbVun8CIrJq4dVuxoT?= =?iso-8859-1?Q?1gTCTiTkg/2KPP9TBhC0n2Iz8AvtOwHHbO4Ur2EHa6VPoLSVTcvD+23xxv?= =?iso-8859-1?Q?n7rJx9UtxD7lKF+TLsR3vk9oW6ZjMZCvBOxEOSoe93cMcu/lGCskKnvtvT?= =?iso-8859-1?Q?qWusOX7SDIJxk5mZANxYz6xTdFmyeXPhhO+ZEkg5CyfVRDOK+YRMHUCM7h?= =?iso-8859-1?Q?rZ5D1o0f22Oj2M6d6i9lB+yp5bwv4KZmXxPU1PbxIVd1A02RUwka8zIqns?= =?iso-8859-1?Q?QAi4mJ+IQ4z5mZj/GMVMi0acMRW33SpCCGWOJ3RL4Ta1cZjyUcVzf3RjNR?= =?iso-8859-1?Q?iJyS9p9XxvbsQQO6eTo8X8NovjpKtjCIKML8Dhshruzm/qNpQl47CHy6GB?= =?iso-8859-1?Q?BTqQi3STaFoYEDlN52/ZRR6XRR59t4bgz2xwTMLUojYQw6z67xNC+HaYV7?= =?iso-8859-1?Q?qBVjS3LL33I14dVxXGzu/IepP/Bv3H5DEWtkYQIGaOZTI+Yt2vQBmXtM+2?= =?iso-8859-1?Q?k3kC/uvmeRO6g++Std7Yo3VJ06rFFQTXJHOj+ogNGW+5ztEWSmLUX17Azy?= =?iso-8859-1?Q?BhiwCayTyMga4rVkFusS0OmukBlh7rtmp1G8eijmcBcuyy94TNVcW2FWXA?= =?iso-8859-1?Q?KGWelzkW+1CIMfcU6GVLNml5kc+5Ae9NGbQc9mD3kz0dSj93FCF1wtKqUE?= =?iso-8859-1?Q?P1xNVmsZ5GpICPfE1Fi8EFVG+DF3c5M8CRNII6UJQIRpYMwG4+nCJHCyzk?= =?iso-8859-1?Q?OQgyk9oT3I+KLdgzGI8xS5xfSDdJt2WbXwLN8CLh4+twQ6SNGqOpFP/fkn?= =?iso-8859-1?Q?X9vf34EIS1M9E/qAm7PVStlojBZXf6zHBvbenKcRkqXGWGpWCNN/SoWv1G?= =?iso-8859-1?Q?1Rwy1UBOZfvwZS+x72GD7YqGqwW9UlQdz71ZJTKIcET3c6QjogscueYrMr?= =?iso-8859-1?Q?ClxoA1cwggvOGRStqrtRFpvoZuWls9NxK0IJtQqIMOVBw5sJZA32Tdcu52?= =?iso-8859-1?Q?GvwXwg7PEHb9Jgi05bhb0Y95UN24QbiaIEfeTX4s38t9F5Vx2SE+akjJie?= =?iso-8859-1?Q?/juT9DzXy1hQ0RF+HIZjjrKhmJVaKUQ6U345pgEQm95znbiT1vwfgdcwxV?= =?iso-8859-1?Q?/4ujzfk941RcBENf4FRvZkcqH5LzdeW5FaEP9/iykMSiYt/vLTzQmX/KwL?= =?iso-8859-1?Q?uxkY1pXrd/ZOCt6uX/2aeLuuM58Xzu97mppVKNd9wjECrwScwa+yPwqs55?= =?iso-8859-1?Q?O2kxnQ2Rtu9xH0KwCGJhEnnk/OGmoraDXpLoRSkzWsNOj2tSheMH74J/21?= =?iso-8859-1?Q?AfzYN/qgINlDmO87hLv8FgD6FUuVE3fk15GaTTGvPIpAeIt4o8M3zja55V?= =?iso-8859-1?Q?XthB9GWxVSk7/ZxfD4UzpP/H6JCsSPnpKhLKKHGuOpz5AHy1N6vAJ38vpJ?= =?iso-8859-1?Q?XMm3mmux+AzzXkr9Q/B2c3mAoL9nr+nns4TqyVPqQrRR6ylBxW28OFfRk4?= =?iso-8859-1?Q?Dl?= x-ms-exchange-antispam-messagedata-1: N7tAEdhgmSKflQ== Content-Type: text/plain; charset="iso-8859-1" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 1dc8507e-04d4-47fa-0cf4-08da1d554009 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2022 13:55:20.9638 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jomvqupLP/kg8PZMibqsTL2AExPuSYFUzegcwhu+OiZXYxKFzw2d1CglENLo2paBleZrX01YGSpEavI6AR/vJg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT3PR01MB5392 X-Rspamd-Queue-Id: 4Kdkcv5Lc9z4W2d X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=eXfwp4sF; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.46 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.46:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.46:from] X-ThisMailContainsUnwantedMimeParts: N Ronald Klop wrote:=0A= > Hi,=0A= >=0A= > A google search gives me this page: https://forums.freebsd.org/threads/us= ername-length-16.28189/ .=0A= > It talks about MAXLOGNAME and limits in utmp.=0A= Yep, I had forgotten about that one.=0A= However, it is very small (and can be increased for a build) and I think it= only applies=0A= to user names and not group names.=0A= =0A= When I look in getgrent.c, the only limit I see is for the entire "struct g= roup", which is=0A= GRP_STORAGE_MAX, set to 1Mbyte. (1Mbyte seems larger than I would want to s= et=0A= the sanity limit to.)=0A= I'll experiment with a long group name and see what happens, at least for t= he local=0A= /etc/group file case.=0A= =0A= Thanks, rick=0A= =0A= Regards,=0A= Ronald=0A= =0A= =0A= Van: Rick Macklem =0A= Datum: 13 april 2022 03:08=0A= Aan: freebsd-current =0A= Onderwerp: Sanity limit for length of user/group names?=0A= =0A= Hi,=0A= =0A= The NFSv4 RFCs do not specify an upper limit for the length=0A= of a user or group (called Owner/Owner_group in NFSv4) string.=0A= =0A= However, PR#260546 notes that a sanity upper limit for their=0A= length is needed.=0A= =0A= Is there any constant in FreeBSD that defines the upper limit for=0A= the length of a user or group name?=0A= (I can find the maximum length of a hostname and I think that can=0A= be used as a safe upper limit for a domain name, as well. The Owner/=0A= Owner_group names include "@domain" on them.)=0A= =0A= Thanks for any help with this, rick=0A= =0A= ________________________________=0A= =0A= =0A= =0A= From nobody Wed Apr 13 14:11:22 2022 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 7C2781AF4D2A for ; Wed, 13 Apr 2022 14:11:31 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660053.outbound.protection.outlook.com [40.107.66.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdkzQ2Y32z4Z2D for ; Wed, 13 Apr 2022 14:11:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KC8cnclcdSL51iI9k3Q68YIT2pCboLJ3+FjiSCECI46P1zgtZUP2qMn8bRFKZQ/H56TQnj5LhUIOKNvO6MtsY4iUbeSarn4W65X8fCjKu4XXDn3vOaSA+ScTGs7RTE7Bv1sqaMTeN/lT2NZpCs5ah6BqXtYRqbg5JhnuHKbkeysH4+14sH2gz+aHyqQOmyhtx2LOfMGZfqccFsbBK0NxyUO4xnUDAk1uhvFwRZV9Uv+Fekbg/FwrOs75dcdfl+TfHJvWUDfFaX+vTpgkrz7WpUmfF5dpZMycpyVJPYoBK03Olvg96TivY/Et7lOzsGMcbkwpIPUCxWEW/LQEDYuswQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VOc/TFjKvzN0E023pfyFu/iUBL2QkGykdAKdLY6xBJ0=; b=Ypd+TkdfyGbi/SC4TpOGgnv/QiBzqUlp2g9p58gXyjEmQjBmDgnsJX2eanixzlL3kYiyHY7KeKCDfEiWlaaUEo8EEZyWZkkUvOWUmK3a4fllGMZTtKWZ+p8Xwn7VobK9Oq9fhhk32F+YbqSCnUl0wg/xGVjOPOE0DDvFLT/QhpOJ3adXvk+x2pvX3VdSlNFYKZzGpKSns3Zjqy4QGiJ8IwRXn0fpqAOJ6SUKSdqWKUQm/zavEMFofTIvAK9RiAm4Em4aOh3FeSadtENfcDA2hvZaOWkzKRlIpYTwFEqoYfVAGdItiI7a4hpEv/v+XKuQ7PXNKPxuaxSZY7CqY4r2rg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VOc/TFjKvzN0E023pfyFu/iUBL2QkGykdAKdLY6xBJ0=; b=pR9+8eveF1/aAfIT80cRYE4nvWi09nwIFMoZJZEDfnoLgC6cK93PFTVE2w0pbh/1dFd1T7Pn2nRtRGgazU7MeHh6WQzmCTV6eppM9K0/mLsyIDKnRFmDUuB+IyyWyigvD3heV/0qCvfsy/NmIDhN+7ErBngtDeMzaap2Kt1QSna0cnMUNypB/BSf5uvd/lYuxNOudP22aOAM6etBM7j6KUkvwtdB282ugUKl1/vrIc7qIGNJoILtgsiKdKosowjMfg8GtlTcRl7MStjTRuA079U+PC9LBfqGPhbZql9t0BncjJ9kfbsbIzn6EPepUN2PhjaBwSWAitlnO9TkwMyjZA== Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:de::14) by YQXPR01MB5835.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:3c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5144.29; Wed, 13 Apr 2022 14:11:23 +0000 Received: from YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::fdb1:ada8:7af0:3003]) by YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM ([fe80::fdb1:ada8:7af0:3003%7]) with mapi id 15.20.5144.030; Wed, 13 Apr 2022 14:11:22 +0000 From: Rick Macklem To: Ronald Klop , freebsd-current Subject: Re: Sanity limit for length of user/group names? Thread-Topic: Sanity limit for length of user/group names? Thread-Index: AQHYTtGfx/S/qWX1pEyPaUr1cRjzAqztY9WAgAB5OhGAAAUNEA== Date: Wed, 13 Apr 2022 14:11:22 +0000 Message-ID: References: <837488522.1046.1649831759547@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 9e72ce4c-0a13-932f-2822-e87310f9b187 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fbe03b77-0940-40fd-d0ff-08da1d577d69 x-ms-traffictypediagnostic: YQXPR01MB5835:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w4PgN2gGgU+qFfITWL+Uguk7OBQ58in8YbT03bObmZ4WvsFbUVHxsdetAstdUylaxj47tunhB8kyj4NjE7kNLQGIx5sKgtJzmmweFehZPkJprzjFqU2kvQjw0ECWJWOqgtWI5ErxGivI74a8ZQRYW8LPuoTUYqesED7tT3U6xAjwXQ8nDBcnpUAEaBjD2JXpqsfpu0CNpfU3f5JCThtQP/IKBrISKboxgpxPZbOwzRyhUcS9M9n6T0vTa/gH+TjpoQUuLdNwfEBSGG0ZTDfk4I42uv4IOM8UIeP297/hQQkfe3ncY/6vKAorXdXvKTNne0UdGybVpv6UPaP9gQNrPz3Bt2aEYeFiYWVBl5kMULW52HBjQuAGvbF9grO27atpyKxzX56rOOoLwoydIQbZvWHD25cQESW63crd3qi/fLZzJBv1miWipjSyDm0T7mv0qPt2NkH0ijye5ANDzCASbwsrnOd3MZi57UL/LYqiHFhr34QIPl8dD0PHU2b3zfiRKCkd2hI8nJGUXmkpHyLug5FsSyiOm08kjIfH2874BFVBqcYsV4pd47syCLjb/mw+Hr9DGYvZS+DG1V6sA7zwEo64Lq4eBrekC7Xl99yIHM6lRZLvGrx3GGOnvNzaa8o7VUwGIMKdItkAPuPfA0lf6uCSEehr6WMFvJKx8VnAi7j+TOli8wfp4dCdI/zsgQrPy9CZZEuRKh8Q2mejxN+xtCXwHe2dFXlMnLUswkoSx0sXwCHQBL9bwLO4s1UZeEvuWj230G7yFByAtDppZGmM+hveEhkrHv6l5cFukaokWuc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(8676002)(8936002)(38070700005)(186003)(5660300002)(33656002)(2906002)(55016003)(786003)(316002)(966005)(83380400001)(76116006)(86362001)(64756008)(66946007)(508600001)(66556008)(110136005)(66446008)(91956017)(52536014)(66476007)(9686003)(7696005)(6506007)(71200400001)(2940100002)(122000001)(38100700002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?DUE8Uk7gr7YNKEnU1ajHrNDPEDnxnO5au4D7M/evUExIpKYGWR86k+w0R9?= =?iso-8859-1?Q?bBN1QPVD86QHihkJjmt0gng+PBrA4We/36wrKKqM+JglRE+3B9gcsSUSc6?= =?iso-8859-1?Q?IrvW+4gps2RPzoTIFC0YDhqEMY+/7vhSxiEaUBpKJ4mFXKbeNO5ZQWlpVS?= =?iso-8859-1?Q?+H6Aalt3GswSXn3IGMTjx4Ubl6YAC0dIfxIPaOJ9EMmylQQYrHLoJrK+pI?= =?iso-8859-1?Q?zUsNnopmv3oisKYvrPnNVvYXI5CGtcoU9bqTFhcg6KvWF1BfJ7Fn9O/rJY?= =?iso-8859-1?Q?SX/kzz3v4umSttOmT82SjMtGO0Ry21WMmtJFyFxeVOyaGLx3Up/E6q0/O6?= =?iso-8859-1?Q?O9kw0b7i0UdGbXIT34fNESmldImBGdeG4gB66+gWDJexvSJdZXshSxUMH5?= =?iso-8859-1?Q?6/kPk2MX5OU+Pq3WXVCStfK4Dgh/FA3AUNFP9SYuW412cJXphJsUqhBxDG?= =?iso-8859-1?Q?SQhUu7GBkUW/LsitMNbonfB9Sp2r4ctH+xGquAXEIWAktWLUGbpQcEuWBP?= =?iso-8859-1?Q?Gycv8AZkGj28e0NacrekjcOI1LFNfhZPeQXb7zE+JUFz6hRSqjctha8OIG?= =?iso-8859-1?Q?+b2OGHIgI+uqFj8kl13cDXvMJR7roXV3K4ow1IoHnmESpzWH1NWMF1M0wl?= =?iso-8859-1?Q?qMtHWdFQxDKAQBqMcSl+jhRh8w1+JtsVlmEc22Z9AFqD2KYIwhLP9teGHh?= =?iso-8859-1?Q?XCyj4ZJQT38H5aK5KuoPu+X19+jdiDT5/eY1Wdps1Xmg7rLEoMxxgy9ZSz?= =?iso-8859-1?Q?PQWljuQyGr5/uvn73724nyhwW/Pd9An082Y/kgaUpFR41VbkH5pRqCG6Xc?= =?iso-8859-1?Q?tI57PHScnFyr2r6RDRQM3PYL1opIFtd0OpQ6O2OB7M+mJdpTFBGqrf/bB0?= =?iso-8859-1?Q?Q/e8+/2aKcxaLbzlYjqsAhPx5y1QXirh8A6eQD10iEiF3FzwRQRu5Shkm6?= =?iso-8859-1?Q?FNjpBRiTa5fptLiMuOauWNAb9Ag2opCJvyiat85Eja745XLeFME89jCWyX?= =?iso-8859-1?Q?m6gPbIzr0BUSbRY1gNsWIP86fzVtCmq4a2TozegesDysTeWVpr85lkK1Ag?= =?iso-8859-1?Q?JnKH59bQ5+lcVU1tw2QJU0NjHkGqi+FPlgye9IaNu78w56IjWD9XIXZglc?= =?iso-8859-1?Q?FbnxLB4BPYRRfdIa9dcwF9YOB6eNfh1zJ0LvJRBZQL4XiSVagOdwWXo2de?= =?iso-8859-1?Q?8X7DCa4Mof6OcW+ecCXGtGDX2aKj9NtOrsfyRvUOWbkTLktqmeTXlL87Ge?= =?iso-8859-1?Q?ifysTyNoRwwymS5DMKJISymGUnUSaV07372SEI54RmplDFnhNG0XADPnJN?= =?iso-8859-1?Q?braElOBjExls0XtaeZXHMmNujbD224GyC1+Pv9rTdCR2Smd/UwvviDDkkB?= =?iso-8859-1?Q?ZA7xZ6H03F2YK19leMn57423ZsVa1vlTuvdLeMaDXbAfuDGTI67x5kFG9Y?= =?iso-8859-1?Q?et+83ZnsWX6LT4hsGZs+5XZK5zom/5QScrQyCs2UoEQIMiHJKyq6kHWJLd?= =?iso-8859-1?Q?KF0QFrJ8+lHJvN5ZLjuygh21kZD7tQi0y7kp8Ktl+RMZK2tQ5ZZ7knJNdM?= =?iso-8859-1?Q?h+9JorHab0Tgk1pbcbT6uAiJjzbJpzSx5Y6JwBZoGrpdDkAPMg0oqO/7td?= =?iso-8859-1?Q?MucL/j8a6jV71QClz94m0Tlnbefn0MCyUgdNdvifTaD07JjD5OLX4j3F6Q?= =?iso-8859-1?Q?eVqWnDaxf2AL1GvV9l1n/QVtCE7dmQp0lxLffR+iYI+1Zl4SNuCDYhOxZY?= =?iso-8859-1?Q?E8fYQUoFFEQ1nVMJ+asfW+L51KnNjLLPzjBQQLE1415MdPaKExGAUpC+y2?= =?iso-8859-1?Q?KEc/OZeSI6/7lwijkUzTIKr+mkOERlezBKd6wgo2Oir1VNVeo3PAiSuWUb?= =?iso-8859-1?Q?qs?= x-ms-exchange-antispam-messagedata-1: cBYR6+w2sA6RRQ== Content-Type: text/plain; charset="iso-8859-1" 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: fbe03b77-0940-40fd-d0ff-08da1d577d69 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2022 14:11:22.9012 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Sx6c60KC5VK/Ay0Q506ImsAfg8lVj54tDdw4Yk5n/51nwt5d06FS/igS6ZkC1qMK1C1KsfkvjBMVHbHAQpLJ2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB5835 X-Rspamd-Queue-Id: 4KdkzQ2Y32z4Z2D X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=pR9+8eve; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.53 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.53:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.53:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-ThisMailContainsUnwantedMimeParts: N Rick Macklem wrote:=0A= > Ronald Klop wrote:=0A= > > Hi,=0A= > >=0A= > > A google search gives me this page: https://forums.freebsd.org/threads/= username-length-16.28189/ .=0A= > > It talks about MAXLOGNAME and limits in utmp.=0A= > Yep, I had forgotten about that one.=0A= > However, it is very small (and can be increased for a build) and I think = it only applies=0A= > to user names and not group names.=0A= >=0A= > When I look in getgrent.c, the only limit I see is for the entire "struct= group", which is=0A= > GRP_STORAGE_MAX, set to 1Mbyte. (1Mbyte seems larger than I would want to= set=0A= > the sanity limit to.)=0A= > I'll experiment with a long group name and see what happens, at least for= the local=0A= > /etc/group file case.=0A= I just tried a group with a name > 1K and it worked, so it does appear that= the only limit=0A= is the 1Mbyte for the entire "struct group", at least for the local /etc/gr= oup=0A= file case.=0A= =0A= My current patch for the NFSv4 server uses 10K as a sanity limit and maybe = I'll=0A= just stick with that.=0A= =0A= Thanks, rick=0A= =0A= Regards,=0A= Ronald=0A= =0A= =0A= Van: Rick Macklem =0A= Datum: 13 april 2022 03:08=0A= Aan: freebsd-current =0A= Onderwerp: Sanity limit for length of user/group names?=0A= =0A= Hi,=0A= =0A= The NFSv4 RFCs do not specify an upper limit for the length=0A= of a user or group (called Owner/Owner_group in NFSv4) string.=0A= =0A= However, PR#260546 notes that a sanity upper limit for their=0A= length is needed.=0A= =0A= Is there any constant in FreeBSD that defines the upper limit for=0A= the length of a user or group name?=0A= (I can find the maximum length of a hostname and I think that can=0A= be used as a safe upper limit for a domain name, as well. The Owner/=0A= Owner_group names include "@domain" on them.)=0A= =0A= Thanks for any help with this, rick=0A= =0A= ________________________________=0A= =0A= =0A= =0A= From nobody Fri Apr 15 01:05:45 2022 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 717A51B38D9D for ; Fri, 15 Apr 2022 01:06:01 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KfdS81tW8z4WRk for ; Fri, 15 Apr 2022 01:06:00 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-5.633, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -2.52, T_SCC_BODY_TEXT_LINE -0.01, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 23F15kg2012942 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [10.14.0.8] (static-198-54-132-55.cust.tzulo.com [198.54.132.55]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 23F15kg2012942 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 14 Apr 2022 21:05:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1649984747; bh=1gnk6cA1FAjhtH9bXZq6MBsXLnsxQ8rnjmptcvXtO5E=; h=Date:Subject:To:References:From:In-Reply-To:From; b=JsbZiG7/T1867AotdHK73sjzF7A2MEXVgiyKWUmJkXnP+YH6Uh0T9aEhJvmae8uUo D9aD9OuS2bFlkgyHs1BacasT9QtzWXf2stm/Z1JadA8M9X3ZiY0FEEDSwqHJXAn5qb b4HebR1jl4iDSvHaIxGvcgYq8u3rGWoO+HGBOpV5yOHQMD1sv4ZWsSjIE5BQIf/ZsN pcvn91sNi1FLktV+99LtxpY1GAdze1k0cDXe9MTY2S3qA2aN3+xmE0UxAlnFsFgthD 2IXHl+wt0xE20fv6+JWx0907l+aXdnw92Wk4EfQmfI2E8ku6QaSlgJw5zGLUdpv7E4 xGeU/jfFPfeYQ== Message-ID: <9b498752-6e66-f0bc-8192-6eab906e9524@blastwave.org> Date: Thu, 14 Apr 2022 21:05:45 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <093ec3cb-32a1-e316-a369-3a9e8559248a@blastwave.org> <0100018022a47721-e6e3ac23-8639-4b94-b3ae-eae4bcfd5493-000000@email.amazonses.com> From: Dennis Clarke In-Reply-To: <0100018022a47721-e6e3ac23-8639-4b94-b3ae-eae4bcfd5493-000000@email.amazonses.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KfdS81tW8z4WRk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b="JsbZiG7/"; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [-4.68 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[blastwave.org:+]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-0.98)[-0.977]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/13/22 07:17, Thomas Laus wrote: > On 4/12/22 18:35, Dennis Clarke wrote: >> I will focus on the problem case I have and try to get better >> information. Somehow. >> > I had an idea that maybe a GELI encrypted disk may have an issue.  Both > my laptop and desktop have encrypted disks.  The gpart partitions have a > .efi appended to the name that 'gpart list' shows.  Not everyone uses > GELI and that may be our difference and the reason for not finding any > pools to import. > I don't even have a wild guess on that topic. Sorry. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From nobody Fri Apr 15 01:08:55 2022 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 221E11B3A6A9 for ; Fri, 15 Apr 2022 01:09:04 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KfdWg4sKqz4Xfn for ; Fri, 15 Apr 2022 01:09:03 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.109, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, T_SCC_BODY_TEXT_LINE -0.01, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 23F18tqF013054 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [10.14.0.8] (static-198-54-132-55.cust.tzulo.com [198.54.132.55]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 23F18tqF013054 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 14 Apr 2022 21:08:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1649984939; bh=OOKm0RSRixqv8/2FX2mG2D3si3n+j5s6AL/LaIcPzAM=; h=Date:To:From:Subject:From; b=EH/dEF448dIWzJ6T5bOLV4PdLeXTl1IEwBB7EXASdUgkcYQ92f9vCSmfHYpCBw5ff Om0yputeG13aM6v5zM0TLvK6BhROIfdA/Z3hFtZX07PkKABrAnKXlIImLXWshAgKaw 2xzqcZSNpBhXLLaRmYrTOCuHwdVEuytJ/JKMHWnPxudFIuX8lRp7oGfsh46W//wvRF 48/NdQyh4x1AAWJb/sbAksqe6dIIwGLKNrwK7zm+MVMNsoz7e4dJ+EOoluDOl1lib5 N4JNZHkGzRVNpPYElZlAc7Ayaniqsk3xE8ccIEFks5zwX8iKgCQnrSFJ8DlEUZeKxl dWnF/PIPkZ2gA== Message-ID: <94db94db-3c8f-eff5-49a5-81f7e7917497@blastwave.org> Date: Thu, 14 Apr 2022 21:08:55 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: freebsd-current@freebsd.org Content-Language: en-US From: Dennis Clarke Subject: main-n254654-d4e8207317c on RISC-V rv64imafdc works fine Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KfdWg4sKqz4Xfn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b="EH/dEF44"; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [-4.68 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[blastwave.org:+]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-0.98)[-0.980]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N So this is a RISC-V instance with ZFS only and definately EFI with no problems booting main-n254654-d4e8207317c kernel : admsys@ison:~ $ su - Password: root@ison:~ # zfs list NAME USED AVAIL REFER MOUNTPOINT rv64 16.2G 91.4G 96K /rv64 rv64/ROOT 1.79G 91.4G 96K none rv64/ROOT/default 1.79G 91.4G 1.42G / rv64/opt 150M 91.4G 10.3M /opt rv64/opt/bw 139M 91.4G 136M /opt/bw rv64/tmp 576K 91.4G 104K /tmp rv64/usr 14.2G 91.4G 96K /usr rv64/usr/home 8.29M 91.4G 6.48M /usr/home rv64/usr/local 158M 91.4G 147M /usr/local rv64/usr/obj 11.7G 91.4G 5.86G /usr/obj rv64/usr/ports 208K 91.4G 96K /usr/ports rv64/usr/src 2.34G 91.4G 2.20G /usr/src rv64/var 2.99M 91.4G 96K /var rv64/var/audit 208K 91.4G 96K /var/audit rv64/var/crash 152K 91.4G 96K /var/crash rv64/var/log 1.28M 91.4G 368K /var/log rv64/var/mail 472K 91.4G 128K /var/mail rv64/var/tmp 824K 91.4G 124K /var/tmp root@ison:~ # ls /boot beastie.4th gptboot.efi logo-orb.4th boot1.efi images logo-orbbw.4th brand-fbsd.4th kernel lua brand.4th kernel.old menu-commands.4th check-password.4th loader.4th menu.4th color.4th loader.conf menu.rc defaults loader.conf.d menusets.4th delay.4th loader.efi modules dtb loader.rc screen.4th efi loader_4th.efi shortcuts.4th efi.4th loader_lua.efi support.4th entropy loader_simp.efi uboot firmware logo-beastie.4th version.4th fonts logo-beastiebw.4th zfs frames.4th logo-fbsdbw.4th root@ison:~ # root@ison:~ # ls -lapb /boot/efi/efi/ total 64 drwxr-xr-x 1 root wheel 16384 Jan 29 19:21 ./ drwxr-xr-x 1 root wheel 16384 Jan 1 1980 ../ drwxr-xr-x 1 root wheel 16384 Jan 29 19:21 boot/ drwxr-xr-x 1 root wheel 16384 Jan 29 19:21 freebsd/ root@ison:~ # ls -lapb /boot/efi/efi/boot/ total 1408 drwxr-xr-x 1 root wheel 16384 Jan 29 19:21 ./ drwxr-xr-x 1 root wheel 16384 Jan 29 19:21 ../ -rwxr-xr-x 1 root wheel 1404812 Jan 29 19:21 bootriscv64.efi root@ison:~ # ls -lapb /boot/efi/efi/freebsd/ total 1408 drwxr-xr-x 1 root wheel 16384 Jan 29 19:21 ./ drwxr-xr-x 1 root wheel 16384 Jan 29 19:21 ../ -rwxr-xr-x 1 root wheel 1404812 Jan 29 19:21 loader.efi root@ison:~ # root@ison:~ # root@ison:~ # uname -apKU FreeBSD ison 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n254654-d4e8207317c-dirty: Thu Apr 14 21:08:09 UTC 2022 root@ison:/usr/obj/usr/src/riscv.riscv64/sys/GENERIC riscv riscv64 1400056 1400051 root@ison:~ # root@ison:~ # However on AMD64 for some certain machine config with UEFI we know the process fails. If only modern laptops had serial ports :\ -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From nobody Fri Apr 15 18:20:30 2022 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 F145B7C90D0; Fri, 15 Apr 2022 18:20:41 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail-out.smeets.xyz (mail-out.smeets.xyz [88.99.165.53]) (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 4Kg4Q05NNKz4SdQ; Fri, 15 Apr 2022 18:20:40 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail.smeets.xyz (mail.smeets.xyz [IPv6:2a01:4f8:10a:3543::25:3]) (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) (Client did not present a certificate) by mail-out.smeets.xyz (Postfix) with ESMTPS id 2C52E54738; Fri, 15 Apr 2022 20:20:33 +0200 (CEST) Received: from amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) by mail.smeets.xyz (Postfix) with ESMTP id 156DCB0599; Fri, 15 Apr 2022 20:20:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at smeets.xyz Received: from mail.smeets.xyz ([IPv6:2a01:4f8:10a:3543::25:3]) by amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) (amavisd-new, port 10025) with ESMTP id owFuhGb0pqPc; Fri, 15 Apr 2022 20:20:32 +0200 (CEST) Received: from [IPV6:2003:cf:df49:c97:7d1f:1687:311a:6ab1] (p2003000631376c977d1f1687311a6ab1.dip0.t-ipconnect.de [IPv6:2003:6:3137:6c97:7d1f:1687:311a:6ab1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail.smeets.xyz (Postfix) with ESMTPSA id 2F570B0593; Fri, 15 Apr 2022 20:20:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smeets.xyz; s=dkim; t=1650046832; 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=aaja1Tdxv7lQEa71GbhoevP1jPmz0FkMLa/OamfiZHk=; b=qCBqWZN5o1h98m+NdBz1u2LGklQ5zOS+MaHFulWLt/724969TEjelQBZfPHXXPPX3IPcej /dmYNuK0nuKd2LLR0V0D5wNozafCGbq+2ojO53W5unNswjrzGCiDh6xaG3qv89vEtGvnMx 1YcISlbl/p69aW0GpB88yvSluuZ2D99KbXFKkjRqUz2LEElCTzU6+LxvMDlIvjgHOq5TS6 O4bNKcer6t6KOM3J9VzTY2yMT/0dwNqiGgEf1WiY9X0uXm9gROrxKYCuQMaiuGXhfStCoj khfOlQXq6dWtf6M2z0a1Eq8AVewnh2bzRx/EM95XWV6/U9V8ybkXXerY/6UcmA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=smeets.xyz; s=ed25519_2022; t=1650046832; 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=aaja1Tdxv7lQEa71GbhoevP1jPmz0FkMLa/OamfiZHk=; b=jde2ZWQ+6tBxKxsVPeHQAmTgn7MAKv3GDp28dIvJRIJxnPsZDLRDu9ND0Ze6xthjq1WLFI jOK0dywDE8n8nYCA== Message-ID: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> Date: Fri, 15 Apr 2022 20:20:30 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-US From: Florian Smeets To: current@freebsd.org Subject: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------PTleDCbNB07093VzYW5hZ6e8" X-Rspamd-Queue-Id: 4Kg4Q05NNKz4SdQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smeets.xyz header.s=dkim header.b=qCBqWZN5; dkim=pass header.d=smeets.xyz header.s=ed25519_2022 header.b=jde2ZWQ+; dmarc=pass (policy=reject) header.from=smeets.xyz; spf=pass (mx1.freebsd.org: domain of flo@smeets.xyz designates 88.99.165.53 as permitted sender) smtp.mailfrom=flo@smeets.xyz X-Spamd-Result: default: False [-4.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[smeets.xyz:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[smeets.xyz,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_FIVE(0.00)[5]; FREEFALL_USER(0.00)[flo]; FROM_HAS_DN(0.00)[]; R_DKIM_ALLOW(-0.20)[smeets.xyz:s=dkim,smeets.xyz:s=ed25519_2022]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[current,net] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------PTleDCbNB07093VzYW5hZ6e8 Content-Type: multipart/mixed; boundary="------------0ujaIh6PzUFhTGi0E14TuIs0"; protected-headers="v1" From: Florian Smeets To: current@freebsd.org Message-ID: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> Subject: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored --------------0ujaIh6PzUFhTGi0E14TuIs0 Content-Type: multipart/mixed; boundary="------------LttqPBLYIjMXDmje60b1yxxG" --------------LttqPBLYIjMXDmje60b1yxxG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 W2JjYyB0byBuZXRAIGZvciB3aWRlciBleHBvc3VyZV0NCg0KSGksDQoNCnRoZXJlIHNlZW1z IHRvIGJlIGFuIGlzc3VlIHdpdGggbG9jYWwgSVB2NiBUQ1AgY29ubmVjdGlvbnMgb24gbWFp bi4gSSANCmhhdmUgYmVlbiBzZWVpbmcgdGhpcyBmb3IgYSBjb3VwbGUgb2YgbW9udGhzIGF0 IGxlYXN0LiBwa2cgdXBnciBvbiBteSANCndlYnNlcnZlciBob3N0aW5nIHRoZSBwa2cgcmVw byBpcyB2ZXJ5IHNsb3csIGFsbCBvdGhlciBob3N0cyBjYW4gY29ubmVjdCANCnRvIHRoZSBw a2cgcmVwbyBqdXN0IGZpbmUuIFNvIElQdjYgY29ubmVjdGlvbnMgZnJvbSBleHRlcm5hbCBo b3N0cyBhcmUgDQpub3QgYWZmZWN0ZWQuDQoNCkkgdGhvdWdodCBJIG11c3QgaGF2ZSBtaXNj b25maWd1cmVkIHNvbWV0aGluZywgYXMgbXkgc2V0dXAgaXMgYSBiaXQgDQp3ZWlyZC4gWWVz dGVyZGF5IEkgbm90aWNlZCB0aGUgc2FtZSBpc3N1ZSBvbiBhIGRpZmZlcmVudCBob3N0LCB0 dXJucyBvdXQgDQphbGwgbXkgMTQuMCBob3N0cyBzZWVtIHRvIGJlIGFmZmVjdGVkLCBjb2du ZXRAIGNvdWxkIGFsc28gcmVwcm9kdWNlIGl0IA0Kb24gb25lIG9mIGhpcyBzeXN0ZW1zLg0K DQpUaGUgc2VydmljZS9zb2Z0d2FyZSB1c2VkIGRvZXMgbm90IHNlZW0gdG8gbWF0dGVyLCBJ IHRyaWVkIHdpdGggcG9ydCAyMiwgDQoyNSwgODAgYW5kIDQ0My4NCg0KSUNNUCBhbmQgVURQ IGRvbid0IHNlZW0gdG8gYmUgYWZmZWN0ZWQuIHBpbmc2IGdldHMgcmVwbGllcyBpbW1lZGlh dGVseS4gDQpBbmQgVURQIGNvbm5lY3Rpb25zIHdpdGggbmMgLWwgLXUgLyBuYyAtdSBkb24n dCBoYXZlIGFueSBkZWxheSwgc2VudCANCmRhdGEgaXMgcmVjZWl2ZWQgaW1tZWRpYXRlbHku DQoNClRlc3RpbmcgbG9jYWwgVENQIGNvbm5lY3Rpb25zIHNob3cgdGhpczoNCg0KZmxvQHJw NjQ6fiAkIGlmY29uZmlnIGR3YzB8Z3JlcCAyMDAzDQoJaW5ldDYgMjAwMzpjZjpkZjQ5OmM5 Nzo0YzU5OmViZmY6ZmVjMTo0NjNkIHByZWZpeGxlbiA2NCBhdXRvY29uZg0KZmxvQHJwNjQ6 fiAkIG5jIC12IDIwMDM6Y2Y6ZGY0OTpjOTc6NGM1OTplYmZmOmZlYzE6NDYzZCAyMg0KWzMg c2Vjb25kIGRlbGF5IGhlcmVdDQpDb25uZWN0aW9uIHRvIDIwMDM6Y2Y6ZGY0OTpjOTc6NGM1 OTplYmZmOmZlYzE6NDYzZCAyMiBwb3J0IFt0Y3Avc3NoXSANCnN1Y2NlZWRlZCENClNTSC0y LjAtT3BlblNTSF84LjkgRnJlZUJTRC0yMDIyMDQxMw0KDQp0Y3BkdW1wIG9uIGxvMCBzaG93 cyB0aGF0IHRoZSBmaXJzdCB0d28gU1lOIHBhY2tldHMgYXJlIGlnbm9yZWQgLyB0aW1lIA0K b3V0LCB0aGVuIHRoZSBjb25uZWN0aW9uIGlzIHN1Y2Nlc3NmdWxseSBlc3RhYmxpc2hlZC4N Cg0KMTk6Mjg6MzguNjg1MTI4IElQNiAyMDAzOmNmOmRmNDk6Yzk3OjRjNTk6ZWJmZjpmZWMx OjQ2M2QuNjEyOTQgPiANCjIwMDM6Y2Y6ZGY0OTpjOTc6NGM1OTplYmZmOmZlYzE6NDYzZC4y MjogRmxhZ3MgW1NdLCBzZXEgMjQ4OTQ3OTU5NCwgd2luIA0KNjU1MzUsIG9wdGlvbnMgW21z cyAxNjMyNCxub3Asd3NjYWxlIDYsc2Fja09LLFRTIHZhbCAzNDEwNTA1NjQzIGVjciAwXSwg DQpsZW5ndGggMA0KDQoxOToyODozOS42OTYwNDcgSVA2IDIwMDM6Y2Y6ZGY0OTpjOTc6NGM1 OTplYmZmOmZlYzE6NDYzZC42MTI5NCA+IA0KMjAwMzpjZjpkZjQ5OmM5Nzo0YzU5OmViZmY6 ZmVjMTo0NjNkLjIyOiBGbGFncyBbU10sIHNlcSAyNDg5NDc5NTk0LCB3aW4gDQo2NTUzNSwg b3B0aW9ucyBbbXNzIDE2MzI0LG5vcCx3c2NhbGUgNixzYWNrT0ssVFMgdmFsIDM0MTA1MDY2 NTQgZWNyIDBdLCANCmxlbmd0aCAwDQoNCjE5OjI4OjQxLjg5NzgzNiBJUDYgMjAwMzpjZjpk ZjQ5OmM5Nzo0YzU5OmViZmY6ZmVjMTo0NjNkLjYxMjk0ID4gDQoyMDAzOmNmOmRmNDk6Yzk3 OjRjNTk6ZWJmZjpmZWMxOjQ2M2QuMjI6IEZsYWdzIFtTXSwgc2VxIDI0ODk0Nzk1OTQsIHdp biANCjY1NTM1LCBvcHRpb25zIFttc3MgMTYzMjQsbm9wLHdzY2FsZSA2LHNhY2tPSyxUUyB2 YWwgMzQxMDUwODg1NiBlY3IgMF0sIA0KbGVuZ3RoIDANCg0KMTk6Mjg6NDEuODk3OTA3IElQ NiAyMDAzOmNmOmRmNDk6Yzk3OjRjNTk6ZWJmZjpmZWMxOjQ2M2QuMjIgPiANCjIwMDM6Y2Y6 ZGY0OTpjOTc6NGM1OTplYmZmOmZlYzE6NDYzZC42MTI5NDogRmxhZ3MgW1MuXSwgc2VxIDI4 NTc1NTI0NzYsIA0KYWNrIDI0ODk0Nzk1OTUsIHdpbiA2NTUzNSwgb3B0aW9ucyBbbXNzIDE2 MzI0LG5vcCx3c2NhbGUgNixzYWNrT0ssVFMgdmFsIA0KMTg1ODM0OTQ4MiBlY3IgMzQxMDUw ODg1Nl0sIGxlbmd0aCAwDQoNCjE5OjI4OjQxLjg5Nzk2MiBJUDYgMjAwMzpjZjpkZjQ5OmM5 Nzo0YzU5OmViZmY6ZmVjMTo0NjNkLjYxMjk0ID4gDQoyMDAzOmNmOmRmNDk6Yzk3OjRjNTk6 ZWJmZjpmZWMxOjQ2M2QuMjI6IEZsYWdzIFsuXSwgYWNrIDEsIHdpbiAxMjc2LCANCm9wdGlv bnMgW25vcCxub3AsVFMgdmFsIDM0MTA1MDg4NTYgZWNyIDE4NTgzNDk0ODJdLCBsZW5ndGgg MA0KDQpJIG5lZWQgaGVscCBkZWJ1Z2dpbmcgdGhpcywgSSBkb24ndCBrbm93IGhvdyB0byBh bmFseXplIHRoaXMgZnVydGhlci4gSSANCndpbGwgc3RhcnQgYmlzZWN0aW5nIHRoaXMsIGJ1 dCBJIHRob3VnaHQgbWF5YmUgc29tZW9uZSBoYXMgYW4gaWRlYS4NCg0KVGhhbmtzLA0KRmxv cmlhbg0K --------------LttqPBLYIjMXDmje60b1yxxG Content-Type: application/pgp-keys; name="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Disposition: attachment; filename="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFpyBwsBEADLq0c46orEtbMn4SptX+VJxR1wB4YwaErZme1bqF4nZHIhlRNE T22HsHdQdoagaB4uACq0Rj5kHcu614ZnnNkLPyCxWQATx+cbdiFO4/hfT8tAvKnB tiy3awKJ5uGCNO2EzJwXW6KwdDA8XPRySqN8m1yPl+dW0Cls+/vO/QL/6+YLMupm EpSvFxRzAZTQuKyX4+xl+dYId24JiPd1yfCuDNOY3+OZ3QBMT00u/699N8lUWRti TwaQMwAOww8r/26YM6/SgcgFuLH2E/CVplY0sDvfoISlAj8agxdomNXfPjCMQ6w5 yGZmA+huFpPCVBTi3on/SWgbQO7dLVpN4BNPuScPosCb/dsOg0S74zCClsIU3gdU Gh9rwJY00/Ebid6V0R3c1Czwbg8LQedzlGDuXYXmzp6W2ujgr1cqbUD6lUWikUv2 IMdCbb8MxYhHLi3GYUs5Xpi+W7vM6T45KbuMr7O/1SjtcGOlNeDvGNgjcDk20fOg PPZ+M6i9vX5Q2oI9HoYaeTiYNwILkBLVP/L40kTo5EkiQOt4OW6BMbylqXPOaQMW uGVbmhCJQpbx8Vo80s2yiBBVWkLkWQIcIm3KZlLldJqKEFpQBWLBE1eFFqboYgAW zFn73CaV5tihobijMmmOV3a8cI1fI4kREyl3g+8bW+O0u3m3tuzVOpDpjwARAQAB zSBGbG9yaWFuIFNtZWV0cyA8ZmxvQEZyZWVCU0Qub3JnPsLBlAQTAQoAPhYhBOyz aLh5CL+2kU1yae9bpNzVqfPABQJh8E3MAhsDBQkLM37BBQsJCAcDBRUKCQgLBRYD AgEAAh4BAheAAAoJEO9bpNzVqfPAOjQP/1FdgHTug7m1OGP3kz5xOID6cuSDUZ1Q eFNvGOU/g0qty1Bda9/dcRJjOdbtIkpPXPUbOZiZWFLABBo82lxufjso1uzwlvCZ q/qMYMtpTys8LZUVOrbVeUM8KKLHtLq2DL49Et8DqwENcxaPa604RExsfvrBAMwO WF6kH8DC4cbCi+2B335NUCFoM/qYC3Ph0bCrWu0lsiEd0G3WJ8Wz8OiEgD+muoQt aEMKkg6B97TaCvcLf25j6VO0bTiySM3e1RwNPaTyu9GSh5L7PThPE67HuA27NXoh +oHDVbdM475OGIQ8IAWvuPyEJ6R91IjpQFR3qiyWeppR1Ag5XoB1DpQv8fKu2bQz m7lQWC07djntw+ScxcDxiuj7+PL1ClKKjezTSmvjJEA6G3wB17MtSnI8TMVnPR1N GsShTY5Fl5ihyQw1wg2eJLXJg0rYLubhPhJiyoiGOIk1BR340Aben1qDC33V9Qo5 CKFlXizvFygdy3h/aIJeq9m2uQvQpPkMM4Ije2tmvlK+Q3HJki0OnbeGf4vJa/dB VdnjAp7idYaVyKhV4D3daH1zOTWwxLrSHOv5ixpR+ZCmG6nmApEKE2q5lm/bx5ZA XP9SSwyLdV22PUbuiNGZ5eJx/9lhuX16nVZ3F2xJZnJuqQV7kWxAedxwaN5P5U8K TPFPgLRAD9U0zR9GbG9yaWFuIFNtZWV0cyA8ZmxvQHNtZWV0cy54eXo+wsGXBBMB CgBBAhsDBQkLM37BBQsJCAcDBRUKCQgLBRYDAgEAAh4BAheAFiEE7LNouHkIv7aR TXJp71uk3NWp88AFAmHwTcwCGQEACgkQ71uk3NWp88BpTRAAybyHhteWLV4VDlzl 7NPxbN8c9cDDv1r0HlaUVxfrSw+1rzycEdhqA8o75Wh5II4KAFTbX2igGckskcoO dqm68MU8+zAtVxVZaqX+EGNXSLWZgAzlf9rAHDm/O1ZBShZhn9EJyarYPaSRNBev VaR9bY6LEFmDacb6qnRVOH4Z/6O6fq/IxoXQqyV1NDmmObxtCcxwx71v+7mJoBMT ximtdrPmcpGesCQquiWKa6DyYjZIEZ9gQPttLQ+iYmwWJp6q68VULqY9X0zG7byc 3Xe7W/5oEoTA/gSWG0EbPOdfTS77TTNxhgBzFB6VY81PVAYzH419Q0b055XLTupo +JTQUb6bbluH6UJIBtIp1iJlGN42qvkMwqTogIdat/3aA+EWEfG7iWlx8Z1hFU3r 7GMJ5o8QLsloVNWAda+iHaidIJvU1fJa0U9v2r1d/KwYHj2qlMaQMZHjldULp7LP P/pITeQEnma3mZ6IX7cp6mUd8MOiVTPE42fPs8qBHKfuEcg7L07NcdRzzgS0LGQf v6fbnvNnvsDGAt4zGQ/Hj72Z5/eL1sDnoJQUHNHMJlNJieGplbLm3LacNQZa9979 BjwK+mUr1nPaaP4YR3czfVwTMrxPKT9kFBDZL4YQ8LbsH5JJC3As3EJdptIkANSm +hU54sG8QPz6TDsm7754d1n12M3CwXkEEwEKACMWIQSnAQMgO8q0Spj+yETnBT35 /4bwdgUCWnIHOAWDB4YfgAAKCRDnBT35/4bwdmNtEACU20uv5Lvuit3DtzQ5m4eP HAQzdeg6Uqpm7nNHB0KKGPCtKmf55bDVHfVuKS1pu1jBXFxGKyEKY5+QaxVrt9Dl iDqfqEPDmIqDdG13ch0cV3lan+3Jli3M2OwsHNac72MPFp++eAUbA9wgn6y6GlJx 9/oCtDuY9FucpL/P8zMbH5f00qBEKsC+lq8u+ZY/7lPYdVaZl3doLZcGCCsgbLP/ ytJPc7qzbHrW1wa7kBFKPLUhAbDFWTQz8L8Zt3cCDoqCc3N0rLZ419LA3NgROek9 nXuti9RG0AofI6t8tMKFBJs1oE9jbs1iqWzG0HdI25U/I0euAUwJNlkVBDwQIOgw HzLYqdnmVJD9HWxMv0cKNY9xVZEnCem1JJaK/+9nrbUtOOvp7l7PWRSbePWYQRT3 KCDZuhl0I7A1qWX+SU28cuxRkxsVni6wvUKEkuxpT07A6XhMmLtGOJSpTDR/hsky gBCs1YSdDJe0NZleaBJ5LIJ30/p68qIm1cFFRLm1hi3bwuBiHq3/SYVTdUWAR/Kl 4xscL8o9f3A7J/npOU126Zn63ItMguHWrangJdTUUINUlF0wleTmZYpTP5+ck7gc Br05VZGWXyNTMYChzS0oQXHCZYdAV9YghRhj2PWKLGhmB8Z+1vo49o1AmGFswlZe TGwUZ2r3d7pZUF0N9zOkbs7BTQRacgcLARAA0es6bm/J0r+KPXOQPItnNuiCTnOM yHqgCvdwfigZskc8uXIVlMJUFhTAPiSHo1XWwq5k55f9rKDJWDVHIu6WfOxzpiNc 4jGWqGpDAYjyTyywAikxJ/Tb3vzUI0XYcLjYKsl4e1c040M06Owy6jHOBr3MtAKH iMtOUT9NQmjopUAFYFVG1NWHZnvukq03uPY08UEe+nsrRYd9X5NieWyCOFQDQAJm dR0dLZhHMGELPNB6W53EHPnhL3FtSrWZ9l9XHwBsAZcXbPGjrye+8AAmfjweIFLd 0yEIZgkN1l2NrpB1QU+J6aKc7HCRTMKqYrGb4CPtRK57VJtlmonGYwjV4Xg6uT8E kkjvhn8WcmBhHhSQSIPcn8pShxAIgfd1oHX78JeWH30hvsA/5Aa4qTe+c0eHtUGr cT5UCIzktTQGaBb5x1E8eSLAzuwNrZWdXdWq9XtCagwqccXNQHo2fy4T6JqSnknz U+vryQM6ruQtbdScaaDU9SpuycJpOKYlvckBhbM5b/0Jhw+VsB0iqL7Afsw6h4v4 8D30DeRb/zzWsaZ45gXPOuw1Uu15r4Al9e2ngs3mA5Ug8imi8I1JVdcQqCXtri+N QbNUHOsfs/NP6ThdQRDA0IAJ8ZnEQTG2fLX1uO+6ZnSu/4AQAe+xZIpcdRUnMg2O p31SKhoRsoYA+U8AEQEAAcLBhgQYAQoAJhYhBOyzaLh5CL+2kU1yae9bpNzVqfPA BQJh8E3NAhsMBQkLM37BABQJEO9bpNzVqfPACRDvW6Tc1anzwPfkD/4yF78b+PSP mDiAsOffMd+U53MhT1Rem+PWxChsn4VqMtLArcr+vxqYcTrZNtb5bsYQgDMz47Zl L1N67PWfe129btyTkOSzA56o0eSfl4mhGhnGQRYczxAHw2bN4JtCwZW7kwhqcGG3 nglWVG9O9GPerSl4c1PB5EYGUjNCL5mn7/kTwSxoNMjOhEsQS+HgjLoRHi7+jNQu VW5hY53wrkTH7itAZohHxYd+zifPciQyUQw4P0hWe0XSVcwJN+xz81NhA5X0L6jl sy9G8xQmx8k37BOTKAqatPIesSlk4lzTNuVXmnbrIGGsvzYO46sMZiT+EPnmcf3Y Aq6mMNidmlWoVyOBKnclLzmEj/gFceIVrGCPGtG9pEdXAbpnSnYZcet++HCS1bRH YMnrPxB7E+1Xy6GVvylfahIcsXMt1mpI0FKzuJcH8O4Asv+QsKY6Q4tcjSX0CROH EnGO9lIaNOA7nYXP5hsuyIjHkPRZ/VgrwD+/z9PUKszqyDBIpwf4Rk9Cmg8z2+TP xnooLMBnTAQPNYIiI9fMyWOHtfPkLIiGUtGBHb7LAQZ7Pxsi5fR36+crhwJiQhpM brthm4VE2pwKnMlohLXnxQtoMMfTw9jzCpTjwuEEFYIIEte8X5GyXItfAm4b9z77 5PDS0JZbUcHZ1sv65OP599IaYgf3rzJnIw=3D=3D =3DYr0r -----END PGP PUBLIC KEY BLOCK----- --------------LttqPBLYIjMXDmje60b1yxxG-- --------------0ujaIh6PzUFhTGi0E14TuIs0-- --------------PTleDCbNB07093VzYW5hZ6e8 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE7LNouHkIv7aRTXJp71uk3NWp88AFAmJZt24FAwAAAAAACgkQ71uk3NWp88D9 OA/+Mdq8UmeSIz2VMCUuH55vL8aGnOwmjKu+p6UtV7DgM15b/xLRR2mIC0c02Ndqkbl7H1YEyjCc NBjOtFFJRLCXz81jtQMAKH3a1MFSSBUajavf+FoGM8Qzd00fAaTTgB4caXA4HSiTGF/AzXfpKMLh fA2bdJ3+YXQQvCaTiVl2HY2oFAYBLdJo0R23eQq0B6/0y6OF1jDGAUkZgWKWcw6IJnZ6z9evr5hE VtUciKeqMFotr8skiNF8ln+wsoK2DR94tvL3lH9kMkbiz5ER0xjTN+SrIjzTnm3qUfYLADhaa0lq axxN3d9EX+EHomM+00LxC1dC08FguzU9meSD7b54u5RwVTG+/0dIUw8HMdwHF7fMWkmRC2ctVCes bq7/1gr2sFEoQro9rv4S36hTTsPLxBGBSbyuQtwzTZ0rlC3iCRH+ePlyfWjqLSNn+xNFL551pfwJ sypkPkkSgVyie4wFi4nWEnhx5lNMBHNJK7B6FZsdi8geyBtEaZUT6/zfxpprEJ63XwIFiBrRx9Ge XdBrpS48qis3E00eIBZTMiDsvLBv0CBbHI+gAZFF7BDy3MN7Wz6ya1gLtv0psAOM8lYoSgiVceF5 CTzFRf/Ngpw8jiC/LelyHagwcwJ2xU7r2TY4tDP5wcmrcFab3VDDEVW7LMCQlmFd4FEMiWYGTCcX xQc= =3svJ -----END PGP SIGNATURE----- --------------PTleDCbNB07093VzYW5hZ6e8-- From nobody Fri Apr 15 19:24:20 2022 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 B2B0F8D2AD4 for ; Fri, 15 Apr 2022 19:24:30 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kg5qf0PDhz4gDp for ; Fri, 15 Apr 2022 19:24:30 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:3510:e557:b337:101a]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 07F18721E2806; Fri, 15 Apr 2022 21:24:20 +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 \(3696.80.82.1.1\)) Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored From: tuexen@freebsd.org In-Reply-To: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> Date: Fri, 15 Apr 2022 21:24:20 +0200 Cc: current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> To: Florian Smeets X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4Kg5qf0PDhz4gDp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 193.175.24.27 is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org X-Spamd-Result: default: False [-2.70 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[tuexen]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_SOFTFAIL(0.00)[~all:c]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[193.175.24.27:from] X-ThisMailContainsUnwantedMimeParts: N > On 15. Apr 2022, at 20:20, Florian Smeets wrote: >=20 > [bcc to net@ for wider exposure] >=20 > Hi, >=20 > there seems to be an issue with local IPv6 TCP connections on main. I = have been seeing this for a couple of months at least. pkg upgr on my = webserver hosting the pkg repo is very slow, all other hosts can connect = to the pkg repo just fine. So IPv6 connections from external hosts are = not affected. >=20 > I thought I must have misconfigured something, as my setup is a bit = weird. Yesterday I noticed the same issue on a different host, turns out = all my 14.0 hosts seem to be affected, cognet@ could also reproduce it = on one of his systems. >=20 > The service/software used does not seem to matter, I tried with port = 22, 25, 80 and 443. >=20 > ICMP and UDP don't seem to be affected. ping6 gets replies = immediately. And UDP connections with nc -l -u / nc -u don't have any = delay, sent data is received immediately. >=20 > Testing local TCP connections show this: >=20 > flo@rp64:~ $ ifconfig dwc0|grep 2003 > inet6 2003:cf:df49:c97:4c59:ebff:fec1:463d prefixlen 64 autoconf > flo@rp64:~ $ nc -v 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 > [3 second delay here] > Connection to 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 port [tcp/ssh] = succeeded! > SSH-2.0-OpenSSH_8.9 FreeBSD-20220413 >=20 > tcpdump on lo0 shows that the first two SYN packets are ignored / time = out, then the connection is successfully established. >=20 > 19:28:38.685128 IP6 2003:cf:df49:c97:4c59:ebff:fec1:463d.61294 > = 2003:cf:df49:c97:4c59:ebff:fec1:463d.22: Flags [S], seq 2489479594, win = 65535, options [mss 16324,nop,wscale 6,sackOK,TS val 3410505643 ecr 0], = length 0 >=20 > 19:28:39.696047 IP6 2003:cf:df49:c97:4c59:ebff:fec1:463d.61294 > = 2003:cf:df49:c97:4c59:ebff:fec1:463d.22: Flags [S], seq 2489479594, win = 65535, options [mss 16324,nop,wscale 6,sackOK,TS val 3410506654 ecr 0], = length 0 >=20 > 19:28:41.897836 IP6 2003:cf:df49:c97:4c59:ebff:fec1:463d.61294 > = 2003:cf:df49:c97:4c59:ebff:fec1:463d.22: Flags [S], seq 2489479594, win = 65535, options [mss 16324,nop,wscale 6,sackOK,TS val 3410508856 ecr 0], = length 0 >=20 > 19:28:41.897907 IP6 2003:cf:df49:c97:4c59:ebff:fec1:463d.22 > = 2003:cf:df49:c97:4c59:ebff:fec1:463d.61294: Flags [S.], seq 2857552476, = ack 2489479595, win 65535, options [mss 16324,nop,wscale 6,sackOK,TS val = 1858349482 ecr 3410508856], length 0 >=20 > 19:28:41.897962 IP6 2003:cf:df49:c97:4c59:ebff:fec1:463d.61294 > = 2003:cf:df49:c97:4c59:ebff:fec1:463d.22: Flags [.], ack 1, win 1276, = options [nop,nop,TS val 3410508856 ecr 1858349482], length 0 >=20 > I need help debugging this, I don't know how to analyze this further. = I will start bisecting this, but I thought maybe someone has an idea. Hi Florian, I can reproduce this locally, will try to figure out what is going on. = If you can bisect it, it would be great. Best regards Michael >=20 > Thanks, > Florian > From nobody Fri Apr 15 21:39:39 2022 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 CC0B27ED386 for ; Fri, 15 Apr 2022 21:39:44 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail-out.smeets.xyz (mail-out.smeets.xyz [88.99.165.53]) (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 4Kg8qg4wk7z3K4j; Fri, 15 Apr 2022 21:39:43 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail.smeets.xyz (mail.smeets.xyz [IPv6:2a01:4f8:10a:3543::25:3]) (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) (Client did not present a certificate) by mail-out.smeets.xyz (Postfix) with ESMTPS id 7709453FF3; Fri, 15 Apr 2022 23:39:41 +0200 (CEST) Received: from amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) by mail.smeets.xyz (Postfix) with ESMTP id 63B93B0599; Fri, 15 Apr 2022 23:39:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at smeets.xyz Received: from mail.smeets.xyz ([IPv6:2a01:4f8:10a:3543::25:3]) by amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) (amavisd-new, port 10025) with ESMTP id SoYVjHVn9UlF; Fri, 15 Apr 2022 23:39:41 +0200 (CEST) Received: from [IPV6:2003:cf:df49:c97:7d1f:1687:311a:6ab1] (p2003000631376c977d1f1687311a6ab1.dip0.t-ipconnect.de [IPv6:2003:6:3137:6c97:7d1f:1687:311a:6ab1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail.smeets.xyz (Postfix) with ESMTPSA id 6C6AFB0593; Fri, 15 Apr 2022 23:39:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smeets.xyz; s=dkim; t=1650058780; 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=nTcLAFrHx4EL9oKi8oqCMSweKaA3bDnVEe3S2GoOg/A=; b=gT2CIbIBZSB3uPB7u83IfRMYyUhyGD+vNIhCC8wY4obFNndNGCleaZQ2ybqe1BCA4GWxG7 YOl6/qtzSxK4JMW3kKI51JNknvZe4Rt2oZYrnQhbU5oM2dU8akFXlnpC2k1jSaESoJoNJq bciF2GORDjAVYQTakF8oB1FsEKg+5Vqfk4ZF3kfuYSzuV5AwqdXV+WI9m36wwI0TumwUgN /Mxb/Fso5I0wDXct20upn7WNPG9sGcywO7hF3TGrE+GdRis4p+cgKEDzNFHsGSzAsPpTwI iZdVA3pcHT2Eny8gykf+HHfW0bq8zqiZPf2Du7ppBJDJOuvKPSLvLGHnvZRaRg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=smeets.xyz; s=ed25519_2022; t=1650058780; 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=nTcLAFrHx4EL9oKi8oqCMSweKaA3bDnVEe3S2GoOg/A=; b=ZsiZ4Ti2S7h/MtH+Togkq/8e8XW488JRUMBnS11y44+4YLCXcAsxmARuNXfsQt6K8PWQgQ WEbiIRCjMd3gkuDA== Message-ID: <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> Date: Fri, 15 Apr 2022 23:39:39 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored Content-Language: en-US To: tuexen@freebsd.org, glebius@freebsd.org Cc: current@freebsd.org References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> From: Florian Smeets In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------fW6IZu6yHtnbwHBxb7P0vf2H" X-Rspamd-Queue-Id: 4Kg8qg4wk7z3K4j X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smeets.xyz header.s=dkim header.b=gT2CIbIB; dkim=pass header.d=smeets.xyz header.s=ed25519_2022 header.b=ZsiZ4Ti2; dmarc=pass (policy=reject) header.from=smeets.xyz; spf=pass (mx1.freebsd.org: domain of flo@smeets.xyz designates 88.99.165.53 as permitted sender) smtp.mailfrom=flo@smeets.xyz X-Spamd-Result: default: False [-3.35 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[smeets.xyz:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[smeets.xyz,reject]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_FIVE(0.00)[5]; FREEFALL_USER(0.00)[flo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; NEURAL_SPAM_SHORT(0.55)[0.546]; R_DKIM_ALLOW(-0.20)[smeets.xyz:s=dkim,smeets.xyz:s=ed25519_2022]; MLMMJ_DEST(0.00)[current] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------fW6IZu6yHtnbwHBxb7P0vf2H Content-Type: multipart/mixed; boundary="------------MAdo9CRRihpNRUQzzG1hUHkY"; protected-headers="v1" From: Florian Smeets To: tuexen@freebsd.org, glebius@freebsd.org Cc: current@freebsd.org Message-ID: <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> In-Reply-To: --------------MAdo9CRRihpNRUQzzG1hUHkY Content-Type: multipart/mixed; boundary="------------oPmGwA1wcIG4MICobFSg50ki" --------------oPmGwA1wcIG4MICobFSg50ki Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTUuMDQuMjIgMjE6MjQsIHR1ZXhlbkBmcmVlYnNkLm9yZyB3cm90ZToNCj4+IE9uIDE1 LiBBcHIgMjAyMiwgYXQgMjA6MjAsIEZsb3JpYW4gU21lZXRzIDxmbG9Ac21lZXRzLnh5ej4g d3JvdGU6DQo+Pg0KPj4NCj4+IEhpLA0KPj4NCj4+IHRoZXJlIHNlZW1zIHRvIGJlIGFuIGlz c3VlIHdpdGggbG9jYWwgSVB2NiBUQ1AgY29ubmVjdGlvbnMgb24gbWFpbi4gSSBoYXZlIGJl ZW4gc2VlaW5nIHRoaXMgZm9yIGEgY291cGxlIG9mIG1vbnRocyBhdCBsZWFzdC4gcGtnIHVw Z3Igb24gbXkgd2Vic2VydmVyIGhvc3RpbmcgdGhlIHBrZyByZXBvIGlzIHZlcnkgc2xvdywg YWxsIG90aGVyIGhvc3RzIGNhbiBjb25uZWN0IHRvIHRoZSBwa2cgcmVwbyBqdXN0IGZpbmUu IFNvIElQdjYgY29ubmVjdGlvbnMgZnJvbSBleHRlcm5hbCBob3N0cyBhcmUgbm90IGFmZmVj dGVkLg0KPj4NCj4+IEkgdGhvdWdodCBJIG11c3QgaGF2ZSBtaXNjb25maWd1cmVkIHNvbWV0 aGluZywgYXMgbXkgc2V0dXAgaXMgYSBiaXQgd2VpcmQuIFllc3RlcmRheSBJIG5vdGljZWQg dGhlIHNhbWUgaXNzdWUgb24gYSBkaWZmZXJlbnQgaG9zdCwgdHVybnMgb3V0IGFsbCBteSAx NC4wIGhvc3RzIHNlZW0gdG8gYmUgYWZmZWN0ZWQsIGNvZ25ldEAgY291bGQgYWxzbyByZXBy b2R1Y2UgaXQgb24gb25lIG9mIGhpcyBzeXN0ZW1zLg0KPj4NCj4+IFRoZSBzZXJ2aWNlL3Nv ZnR3YXJlIHVzZWQgZG9lcyBub3Qgc2VlbSB0byBtYXR0ZXIsIEkgdHJpZWQgd2l0aCBwb3J0 IDIyLCAyNSwgODAgYW5kIDQ0My4NCj4+DQo+PiBJQ01QIGFuZCBVRFAgZG9uJ3Qgc2VlbSB0 byBiZSBhZmZlY3RlZC4gcGluZzYgZ2V0cyByZXBsaWVzIGltbWVkaWF0ZWx5LiBBbmQgVURQ IGNvbm5lY3Rpb25zIHdpdGggbmMgLWwgLXUgLyBuYyAtdSBkb24ndCBoYXZlIGFueSBkZWxh eSwgc2VudCBkYXRhIGlzIHJlY2VpdmVkIGltbWVkaWF0ZWx5Lg0KPj4NCj4+IFRlc3Rpbmcg bG9jYWwgVENQIGNvbm5lY3Rpb25zIHNob3cgdGhpczoNCj4+DQo+PiBmbG9AcnA2NDp+ICQg aWZjb25maWcgZHdjMHxncmVwIDIwMDMNCj4+IAlpbmV0NiAyMDAzOmNmOmRmNDk6Yzk3OjRj NTk6ZWJmZjpmZWMxOjQ2M2QgcHJlZml4bGVuIDY0IGF1dG9jb25mDQo+PiBmbG9AcnA2NDp+ ICQgbmMgLXYgMjAwMzpjZjpkZjQ5OmM5Nzo0YzU5OmViZmY6ZmVjMTo0NjNkIDIyDQo+PiBb MyBzZWNvbmQgZGVsYXkgaGVyZV0NCj4+IENvbm5lY3Rpb24gdG8gMjAwMzpjZjpkZjQ5OmM5 Nzo0YzU5OmViZmY6ZmVjMTo0NjNkIDIyIHBvcnQgW3RjcC9zc2hdIHN1Y2NlZWRlZCENCj4+ IFNTSC0yLjAtT3BlblNTSF84LjkgRnJlZUJTRC0yMDIyMDQxMw0KPj4NCg0KPj4NCj4+IEkg bmVlZCBoZWxwIGRlYnVnZ2luZyB0aGlzLCBJIGRvbid0IGtub3cgaG93IHRvIGFuYWx5emUg dGhpcyBmdXJ0aGVyLiBJIHdpbGwgc3RhcnQgYmlzZWN0aW5nIHRoaXMsIGJ1dCBJIHRob3Vn aHQgbWF5YmUgc29tZW9uZSBoYXMgYW4gaWRlYS4NCj4gSGkgRmxvcmlhbiwNCj4gDQo+IEkg Y2FuIHJlcHJvZHVjZSB0aGlzIGxvY2FsbHksIHdpbGwgdHJ5IHRvIGZpZ3VyZSBvdXQgd2hh dCBpcyBnb2luZyBvbi4gSWYgeW91IGNhbiBiaXNlY3QgaXQsIGl0IHdvdWxkIGJlIGdyZWF0 Lg0KDQpGb3VuZCB0aGUgY3VscHJpdCAxODE3YmU0ODFiODcwM2FlODY3MzBiMTUxYTZmNDlj YzMwMjI5MzBmLiBBbmQgaW5kZWVkIA0KdG9nZ2xpbmcgbmV0LmluZXQ2LmlwNi5zb3VyY2Vf YWRkcmVzc192YWxpZGF0aW9uIG1ha2VzIHRoZSBpc3N1ZSBnbyBhd2F5IA0Kb24gbGF0ZXN0 IG1haW4uDQoNCkZsb3JpYW4NCg== --------------oPmGwA1wcIG4MICobFSg50ki Content-Type: application/pgp-keys; name="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Disposition: attachment; filename="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFpyBwsBEADLq0c46orEtbMn4SptX+VJxR1wB4YwaErZme1bqF4nZHIhlRNE T22HsHdQdoagaB4uACq0Rj5kHcu614ZnnNkLPyCxWQATx+cbdiFO4/hfT8tAvKnB tiy3awKJ5uGCNO2EzJwXW6KwdDA8XPRySqN8m1yPl+dW0Cls+/vO/QL/6+YLMupm EpSvFxRzAZTQuKyX4+xl+dYId24JiPd1yfCuDNOY3+OZ3QBMT00u/699N8lUWRti TwaQMwAOww8r/26YM6/SgcgFuLH2E/CVplY0sDvfoISlAj8agxdomNXfPjCMQ6w5 yGZmA+huFpPCVBTi3on/SWgbQO7dLVpN4BNPuScPosCb/dsOg0S74zCClsIU3gdU Gh9rwJY00/Ebid6V0R3c1Czwbg8LQedzlGDuXYXmzp6W2ujgr1cqbUD6lUWikUv2 IMdCbb8MxYhHLi3GYUs5Xpi+W7vM6T45KbuMr7O/1SjtcGOlNeDvGNgjcDk20fOg PPZ+M6i9vX5Q2oI9HoYaeTiYNwILkBLVP/L40kTo5EkiQOt4OW6BMbylqXPOaQMW uGVbmhCJQpbx8Vo80s2yiBBVWkLkWQIcIm3KZlLldJqKEFpQBWLBE1eFFqboYgAW zFn73CaV5tihobijMmmOV3a8cI1fI4kREyl3g+8bW+O0u3m3tuzVOpDpjwARAQAB zSBGbG9yaWFuIFNtZWV0cyA8ZmxvQEZyZWVCU0Qub3JnPsLBlAQTAQoAPhYhBOyz aLh5CL+2kU1yae9bpNzVqfPABQJh8E3MAhsDBQkLM37BBQsJCAcDBRUKCQgLBRYD AgEAAh4BAheAAAoJEO9bpNzVqfPAOjQP/1FdgHTug7m1OGP3kz5xOID6cuSDUZ1Q eFNvGOU/g0qty1Bda9/dcRJjOdbtIkpPXPUbOZiZWFLABBo82lxufjso1uzwlvCZ q/qMYMtpTys8LZUVOrbVeUM8KKLHtLq2DL49Et8DqwENcxaPa604RExsfvrBAMwO WF6kH8DC4cbCi+2B335NUCFoM/qYC3Ph0bCrWu0lsiEd0G3WJ8Wz8OiEgD+muoQt aEMKkg6B97TaCvcLf25j6VO0bTiySM3e1RwNPaTyu9GSh5L7PThPE67HuA27NXoh +oHDVbdM475OGIQ8IAWvuPyEJ6R91IjpQFR3qiyWeppR1Ag5XoB1DpQv8fKu2bQz m7lQWC07djntw+ScxcDxiuj7+PL1ClKKjezTSmvjJEA6G3wB17MtSnI8TMVnPR1N GsShTY5Fl5ihyQw1wg2eJLXJg0rYLubhPhJiyoiGOIk1BR340Aben1qDC33V9Qo5 CKFlXizvFygdy3h/aIJeq9m2uQvQpPkMM4Ije2tmvlK+Q3HJki0OnbeGf4vJa/dB VdnjAp7idYaVyKhV4D3daH1zOTWwxLrSHOv5ixpR+ZCmG6nmApEKE2q5lm/bx5ZA XP9SSwyLdV22PUbuiNGZ5eJx/9lhuX16nVZ3F2xJZnJuqQV7kWxAedxwaN5P5U8K TPFPgLRAD9U0zR9GbG9yaWFuIFNtZWV0cyA8ZmxvQHNtZWV0cy54eXo+wsGXBBMB CgBBAhsDBQkLM37BBQsJCAcDBRUKCQgLBRYDAgEAAh4BAheAFiEE7LNouHkIv7aR TXJp71uk3NWp88AFAmHwTcwCGQEACgkQ71uk3NWp88BpTRAAybyHhteWLV4VDlzl 7NPxbN8c9cDDv1r0HlaUVxfrSw+1rzycEdhqA8o75Wh5II4KAFTbX2igGckskcoO dqm68MU8+zAtVxVZaqX+EGNXSLWZgAzlf9rAHDm/O1ZBShZhn9EJyarYPaSRNBev VaR9bY6LEFmDacb6qnRVOH4Z/6O6fq/IxoXQqyV1NDmmObxtCcxwx71v+7mJoBMT ximtdrPmcpGesCQquiWKa6DyYjZIEZ9gQPttLQ+iYmwWJp6q68VULqY9X0zG7byc 3Xe7W/5oEoTA/gSWG0EbPOdfTS77TTNxhgBzFB6VY81PVAYzH419Q0b055XLTupo +JTQUb6bbluH6UJIBtIp1iJlGN42qvkMwqTogIdat/3aA+EWEfG7iWlx8Z1hFU3r 7GMJ5o8QLsloVNWAda+iHaidIJvU1fJa0U9v2r1d/KwYHj2qlMaQMZHjldULp7LP P/pITeQEnma3mZ6IX7cp6mUd8MOiVTPE42fPs8qBHKfuEcg7L07NcdRzzgS0LGQf v6fbnvNnvsDGAt4zGQ/Hj72Z5/eL1sDnoJQUHNHMJlNJieGplbLm3LacNQZa9979 BjwK+mUr1nPaaP4YR3czfVwTMrxPKT9kFBDZL4YQ8LbsH5JJC3As3EJdptIkANSm +hU54sG8QPz6TDsm7754d1n12M3CwXkEEwEKACMWIQSnAQMgO8q0Spj+yETnBT35 /4bwdgUCWnIHOAWDB4YfgAAKCRDnBT35/4bwdmNtEACU20uv5Lvuit3DtzQ5m4eP HAQzdeg6Uqpm7nNHB0KKGPCtKmf55bDVHfVuKS1pu1jBXFxGKyEKY5+QaxVrt9Dl iDqfqEPDmIqDdG13ch0cV3lan+3Jli3M2OwsHNac72MPFp++eAUbA9wgn6y6GlJx 9/oCtDuY9FucpL/P8zMbH5f00qBEKsC+lq8u+ZY/7lPYdVaZl3doLZcGCCsgbLP/ ytJPc7qzbHrW1wa7kBFKPLUhAbDFWTQz8L8Zt3cCDoqCc3N0rLZ419LA3NgROek9 nXuti9RG0AofI6t8tMKFBJs1oE9jbs1iqWzG0HdI25U/I0euAUwJNlkVBDwQIOgw HzLYqdnmVJD9HWxMv0cKNY9xVZEnCem1JJaK/+9nrbUtOOvp7l7PWRSbePWYQRT3 KCDZuhl0I7A1qWX+SU28cuxRkxsVni6wvUKEkuxpT07A6XhMmLtGOJSpTDR/hsky gBCs1YSdDJe0NZleaBJ5LIJ30/p68qIm1cFFRLm1hi3bwuBiHq3/SYVTdUWAR/Kl 4xscL8o9f3A7J/npOU126Zn63ItMguHWrangJdTUUINUlF0wleTmZYpTP5+ck7gc Br05VZGWXyNTMYChzS0oQXHCZYdAV9YghRhj2PWKLGhmB8Z+1vo49o1AmGFswlZe TGwUZ2r3d7pZUF0N9zOkbs7BTQRacgcLARAA0es6bm/J0r+KPXOQPItnNuiCTnOM yHqgCvdwfigZskc8uXIVlMJUFhTAPiSHo1XWwq5k55f9rKDJWDVHIu6WfOxzpiNc 4jGWqGpDAYjyTyywAikxJ/Tb3vzUI0XYcLjYKsl4e1c040M06Owy6jHOBr3MtAKH iMtOUT9NQmjopUAFYFVG1NWHZnvukq03uPY08UEe+nsrRYd9X5NieWyCOFQDQAJm dR0dLZhHMGELPNB6W53EHPnhL3FtSrWZ9l9XHwBsAZcXbPGjrye+8AAmfjweIFLd 0yEIZgkN1l2NrpB1QU+J6aKc7HCRTMKqYrGb4CPtRK57VJtlmonGYwjV4Xg6uT8E kkjvhn8WcmBhHhSQSIPcn8pShxAIgfd1oHX78JeWH30hvsA/5Aa4qTe+c0eHtUGr cT5UCIzktTQGaBb5x1E8eSLAzuwNrZWdXdWq9XtCagwqccXNQHo2fy4T6JqSnknz U+vryQM6ruQtbdScaaDU9SpuycJpOKYlvckBhbM5b/0Jhw+VsB0iqL7Afsw6h4v4 8D30DeRb/zzWsaZ45gXPOuw1Uu15r4Al9e2ngs3mA5Ug8imi8I1JVdcQqCXtri+N QbNUHOsfs/NP6ThdQRDA0IAJ8ZnEQTG2fLX1uO+6ZnSu/4AQAe+xZIpcdRUnMg2O p31SKhoRsoYA+U8AEQEAAcLBhgQYAQoAJhYhBOyzaLh5CL+2kU1yae9bpNzVqfPA BQJh8E3NAhsMBQkLM37BABQJEO9bpNzVqfPACRDvW6Tc1anzwPfkD/4yF78b+PSP mDiAsOffMd+U53MhT1Rem+PWxChsn4VqMtLArcr+vxqYcTrZNtb5bsYQgDMz47Zl L1N67PWfe129btyTkOSzA56o0eSfl4mhGhnGQRYczxAHw2bN4JtCwZW7kwhqcGG3 nglWVG9O9GPerSl4c1PB5EYGUjNCL5mn7/kTwSxoNMjOhEsQS+HgjLoRHi7+jNQu VW5hY53wrkTH7itAZohHxYd+zifPciQyUQw4P0hWe0XSVcwJN+xz81NhA5X0L6jl sy9G8xQmx8k37BOTKAqatPIesSlk4lzTNuVXmnbrIGGsvzYO46sMZiT+EPnmcf3Y Aq6mMNidmlWoVyOBKnclLzmEj/gFceIVrGCPGtG9pEdXAbpnSnYZcet++HCS1bRH YMnrPxB7E+1Xy6GVvylfahIcsXMt1mpI0FKzuJcH8O4Asv+QsKY6Q4tcjSX0CROH EnGO9lIaNOA7nYXP5hsuyIjHkPRZ/VgrwD+/z9PUKszqyDBIpwf4Rk9Cmg8z2+TP xnooLMBnTAQPNYIiI9fMyWOHtfPkLIiGUtGBHb7LAQZ7Pxsi5fR36+crhwJiQhpM brthm4VE2pwKnMlohLXnxQtoMMfTw9jzCpTjwuEEFYIIEte8X5GyXItfAm4b9z77 5PDS0JZbUcHZ1sv65OP599IaYgf3rzJnIw=3D=3D =3DYr0r -----END PGP PUBLIC KEY BLOCK----- --------------oPmGwA1wcIG4MICobFSg50ki-- --------------MAdo9CRRihpNRUQzzG1hUHkY-- --------------fW6IZu6yHtnbwHBxb7P0vf2H Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE7LNouHkIv7aRTXJp71uk3NWp88AFAmJZ5hsFAwAAAAAACgkQ71uk3NWp88Ay 7A//Y8V/UBviGn4kr2OKBQNkeMwK6uwFyz/fuFeqC1wIoL4TV1WBgfiU+F+eOJr58RUfFjQ6cOrU Axxkw7bOBsBzLrJvO6LInFW3gUQJNiestxdRwqdWUm42XhxTGExKHTp0TaoZT58fJp+wl7AFaICm mH+VEwwsYVnsZcaFWa2HY8MgHjvtkF5Mva1raL7GXZ/CnNFeqLCGsudCOnzncVZsHnFlUKQ1oapW sht+9s7qz4inVlXaOuGOU+qop2+81+Moty+QGCJiPHjDme83Xmm41y0JmgBHvQi4bQJJmD1s6ZoA hJHZLdAphVtdNvb/IEnWdVqzE7YpK0oCXYbld/FM+PPuX8MEWEDiZr/awed4v6awTJjq02+bGY+8 SyHXAHre+n8IjVwq7mowNignDryUH4HqDSoYDHqehkFPHkL5FrFJTMXa0c3UUY59Otp/cpqwNgBM Lj2AQY1ezOikuV9ukecHm6UO/q7qzNujsqX7u0zLsIzUiuP5hpC0XMpjvpJdI+Dr+doCfEiRQo+d CgIQcK1dFZ+YDEplyX2q7kpbyLXrwY3ks8D82ytywZetjQ+D9MseqDoWDSgy/nUsIViffyqy+pNK b4/GTbEMZyjGXK9pG0zniDGnMhjmRc+kh+gJXOEzDG2Lw1Ku1MEur/ChFI/+78g6bdT2IbplRY1Z hRM= =wz8/ -----END PGP SIGNATURE----- --------------fW6IZu6yHtnbwHBxb7P0vf2H-- From nobody Fri Apr 15 22:05:49 2022 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 C4E888D3E1D for ; Fri, 15 Apr 2022 22:05:56 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kg9Pv2LMyz3Nrq; Fri, 15 Apr 2022 22:05:55 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:3510:e557:b337:101a]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 747D1721E2806; Sat, 16 Apr 2022 00:05:50 +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 \(3696.80.82.1.1\)) Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored From: tuexen@freebsd.org In-Reply-To: <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> Date: Sat, 16 Apr 2022 00:05:49 +0200 Cc: Gleb Smirnoff , current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <46089B86-EF4C-4E4A-9240-51FEACE2BE3C@freebsd.org> References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> To: Florian Smeets X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4Kg9Pv2LMyz3Nrq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:638:a02:a001:20e:cff:fe4a:feaa is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org X-Spamd-Result: default: False [-2.56 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[tuexen]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.964]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 15. Apr 2022, at 23:39, Florian Smeets wrote: >=20 > On 15.04.22 21:24, tuexen@freebsd.org wrote: >>> On 15. Apr 2022, at 20:20, Florian Smeets wrote: >>>=20 >>>=20 >>> Hi, >>>=20 >>> there seems to be an issue with local IPv6 TCP connections on main. = I have been seeing this for a couple of months at least. pkg upgr on my = webserver hosting the pkg repo is very slow, all other hosts can connect = to the pkg repo just fine. So IPv6 connections from external hosts are = not affected. >>>=20 >>> I thought I must have misconfigured something, as my setup is a bit = weird. Yesterday I noticed the same issue on a different host, turns out = all my 14.0 hosts seem to be affected, cognet@ could also reproduce it = on one of his systems. >>>=20 >>> The service/software used does not seem to matter, I tried with port = 22, 25, 80 and 443. >>>=20 >>> ICMP and UDP don't seem to be affected. ping6 gets replies = immediately. And UDP connections with nc -l -u / nc -u don't have any = delay, sent data is received immediately. >>>=20 >>> Testing local TCP connections show this: >>>=20 >>> flo@rp64:~ $ ifconfig dwc0|grep 2003 >>> inet6 2003:cf:df49:c97:4c59:ebff:fec1:463d prefixlen 64 autoconf >>> flo@rp64:~ $ nc -v 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 >>> [3 second delay here] >>> Connection to 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 port [tcp/ssh] = succeeded! >>> SSH-2.0-OpenSSH_8.9 FreeBSD-20220413 >>>=20 >=20 >>>=20 >>> I need help debugging this, I don't know how to analyze this = further. I will start bisecting this, but I thought maybe someone has an = idea. >> Hi Florian, >> I can reproduce this locally, will try to figure out what is going = on. If you can bisect it, it would be great. >=20 > Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And indeed = toggling net.inet6.ip6.source_address_validation makes the issue go away = on latest main. Cool, thanks for providing the information. However, I don't understand = why results in dropping the first two SYN segments (this should not = happen) and why the third is accepted (they should all treated the same). Best regards Michael >=20 > Florian > From nobody Fri Apr 15 22:11:13 2022 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 A420B8D59CF for ; Fri, 15 Apr 2022 22:11:22 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kg9X94lgRz3Q6p for ; Fri, 15 Apr 2022 22:11:21 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1650060673; bh=S5Am48HHOAQRyHlxIbWwTB0J3fF95a8ct7GZ TJbr+9A=; b=Or2BlNr0vbZVAFxwU1xNc8zYbi3ffmecxztcFeaZCf5mFqnAQHip w68pOXdgvtUdsacQFgVxULv80PrHr+gjMZUMJQauf4Y/ajVjsBcpH2dFxh4UQBUg L8oO3X8SrcDed9XkPJNSYa6GDnHV1bUxMbyYo5lL6sLDeRdgeS69JM0= Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id C71743E702 for ; Fri, 15 Apr 2022 18:11:13 -0400 (EDT) Message-ID: Date: Fri, 15 Apr 2022 18:11:13 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored Content-Language: en-NZ To: freebsd-current@freebsd.org References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> From: Michael Butler In-Reply-To: <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Kg9X94lgRz3Q6p X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=Or2BlNr0; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[protected-networks.net:+]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/15/22 17:39, Florian Smeets wrote: > On 15.04.22 21:24, tuexen@freebsd.org wrote: >>> On 15. Apr 2022, at 20:20, Florian Smeets wrote: >>> >>> >>> Hi, >>> >>> there seems to be an issue with local IPv6 TCP connections on main. I >>> have been seeing this for a couple of months at least. pkg upgr on my >>> webserver hosting the pkg repo is very slow, all other hosts can >>> connect to the pkg repo just fine. So IPv6 connections from external >>> hosts are not affected. >>> >>> I thought I must have misconfigured something, as my setup is a bit >>> weird. Yesterday I noticed the same issue on a different host, turns >>> out all my 14.0 hosts seem to be affected, cognet@ could also >>> reproduce it on one of his systems. >>> >>> The service/software used does not seem to matter, I tried with port >>> 22, 25, 80 and 443. >>> >>> ICMP and UDP don't seem to be affected. ping6 gets replies >>> immediately. And UDP connections with nc -l -u / nc -u don't have any >>> delay, sent data is received immediately. >>> >>> Testing local TCP connections show this: >>> >>> flo@rp64:~ $ ifconfig dwc0|grep 2003 >>>     inet6 2003:cf:df49:c97:4c59:ebff:fec1:463d prefixlen 64 autoconf >>> flo@rp64:~ $ nc -v 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 >>> [3 second delay here] >>> Connection to 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 port [tcp/ssh] >>> succeeded! >>> SSH-2.0-OpenSSH_8.9 FreeBSD-20220413 >>> > >>> >>> I need help debugging this, I don't know how to analyze this further. >>> I will start bisecting this, but I thought maybe someone has an idea. >> Hi Florian, >> >> I can reproduce this locally, will try to figure out what is going on. >> If you can bisect it, it would be great. > > Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And indeed > toggling net.inet6.ip6.source_address_validation makes the issue go away > on latest main. I found this commit and the ipv4 analog also cause packets between non-VNET jails on the same host and to the host itself to be dropped :-( Michael From nobody Sat Apr 16 00:11:00 2022 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 679217CFBB7 for ; Sat, 16 Apr 2022 00:11:08 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgDBM2G91z3vwZ; Sat, 16 Apr 2022 00:11:07 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:3510:e557:b337:101a]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 1350A721E2806; Sat, 16 Apr 2022 02:11:00 +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 \(3696.80.82.1.1\)) Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored From: tuexen@freebsd.org In-Reply-To: <46089B86-EF4C-4E4A-9240-51FEACE2BE3C@freebsd.org> Date: Sat, 16 Apr 2022 02:11:00 +0200 Cc: Gleb Smirnoff , current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <430FE7E6-5B68-4843-8D2D-DE5FAB7C495F@freebsd.org> References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <46089B86-EF4C-4E4A-9240-51FEACE2BE3C@freebsd.org> To: Florian Smeets X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4KgDBM2G91z3vwZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 193.175.24.27 is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[tuexen]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[193.175.24.27:from] X-ThisMailContainsUnwantedMimeParts: N > On 16. Apr 2022, at 00:05, tuexen@freebsd.org wrote: >=20 >> On 15. Apr 2022, at 23:39, Florian Smeets wrote: >>=20 >> On 15.04.22 21:24, tuexen@freebsd.org wrote: >>>> On 15. Apr 2022, at 20:20, Florian Smeets wrote: >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> there seems to be an issue with local IPv6 TCP connections on main. = I have been seeing this for a couple of months at least. pkg upgr on my = webserver hosting the pkg repo is very slow, all other hosts can connect = to the pkg repo just fine. So IPv6 connections from external hosts are = not affected. >>>>=20 >>>> I thought I must have misconfigured something, as my setup is a bit = weird. Yesterday I noticed the same issue on a different host, turns out = all my 14.0 hosts seem to be affected, cognet@ could also reproduce it = on one of his systems. >>>>=20 >>>> The service/software used does not seem to matter, I tried with = port 22, 25, 80 and 443. >>>>=20 >>>> ICMP and UDP don't seem to be affected. ping6 gets replies = immediately. And UDP connections with nc -l -u / nc -u don't have any = delay, sent data is received immediately. >>>>=20 >>>> Testing local TCP connections show this: >>>>=20 >>>> flo@rp64:~ $ ifconfig dwc0|grep 2003 >>>> inet6 2003:cf:df49:c97:4c59:ebff:fec1:463d prefixlen 64 autoconf >>>> flo@rp64:~ $ nc -v 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 >>>> [3 second delay here] >>>> Connection to 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 port = [tcp/ssh] succeeded! >>>> SSH-2.0-OpenSSH_8.9 FreeBSD-20220413 >>>>=20 >>=20 >>>>=20 >>>> I need help debugging this, I don't know how to analyze this = further. I will start bisecting this, but I thought maybe someone has an = idea. >>> Hi Florian, >>> I can reproduce this locally, will try to figure out what is going = on. If you can bisect it, it would be great. >>=20 >> Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And = indeed toggling net.inet6.ip6.source_address_validation makes the issue = go away on latest main. > Cool, thanks for providing the information. However, I don't = understand why results in dropping the first two SYN segments (this = should not happen) > and why the third is accepted (they should all treated the same). The first two packets don't have the loopback interface as its rcv = interface, so Gleb's check for IFF_LOOPBACK fails. The second retransmission of the SYN has the loopback interface as its rcv = interface, so Gleb check passes. I also do not see the problem with ICMP6, UDP or SCTP over IPv6. Don't know what is special about TCP, maybe Gleb knows out of his = head... Best regards Michael >=20 > Best regards > Michael >>=20 >> Florian >> >=20 >=20 From nobody Sat Apr 16 05:22:59 2022 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 99A6E9F0610 for ; Sat, 16 Apr 2022 05:23:08 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgM6M40q4z4cyF for ; Sat, 16 Apr 2022 05:23:07 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 23G5N0Ea037943 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 Apr 2022 22:23:00 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 23G5MxE6037942; Fri, 15 Apr 2022 22:22:59 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Fri, 15 Apr 2022 22:22:59 -0700 From: Gleb Smirnoff To: Michael Butler , Florian Smeets Cc: freebsd-current@freebsd.org Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored Message-ID: References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KgM6M40q4z4cyF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [-3.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Florian, Hi Michael, On Fri, Apr 15, 2022 at 06:11:13PM -0400, Michael Butler wrote: M> >> I can reproduce this locally, will try to figure out what is going on. M> >> If you can bisect it, it would be great. M> > M> > Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And indeed M> > toggling net.inet6.ip6.source_address_validation makes the issue go away M> > on latest main. M> M> I found this commit and the ipv4 analog also cause packets between M> non-VNET jails on the same host and to the host itself to be dropped :-( I see your mails and will look into the problem ASAP. Meanwhile... Florian, can you please confirm you are using jails too? Michael, can you please confirm or decline that you see the packets that are dropped when you tcpdump on lo0? -- Gleb Smirnoff From nobody Sat Apr 16 06:29:53 2022 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 1B09F5D448D for ; Sat, 16 Apr 2022 06:30:09 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail-out.smeets.xyz (mail-out.smeets.xyz [IPv6:2a01:4f8:10a:3543:ffff:0:25:11]) (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 4KgNbg5g9Pz4jyg; Sat, 16 Apr 2022 06:30:07 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail.smeets.xyz (mail.smeets.xyz [IPv6:2a01:4f8:10a:3543::25:3]) (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) (Client did not present a certificate) by mail-out.smeets.xyz (Postfix) with ESMTPS id 1CC6E560B9; Sat, 16 Apr 2022 08:30:00 +0200 (CEST) Received: from amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) by mail.smeets.xyz (Postfix) with ESMTP id 07B56B05A2; Sat, 16 Apr 2022 08:30:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at smeets.xyz Received: from mail.smeets.xyz ([IPv6:2a01:4f8:10a:3543::25:3]) by amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) (amavisd-new, port 10025) with ESMTP id HRW1DrmTMsIr; Sat, 16 Apr 2022 08:29:59 +0200 (CEST) Received: from [IPV6:2003:cf:df49:c97:7d1f:1687:311a:6ab1] (p2003000631376c977d1f1687311a6ab1.dip0.t-ipconnect.de [IPv6:2003:6:3137:6c97:7d1f:1687:311a:6ab1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail.smeets.xyz (Postfix) with ESMTPSA id B6825B0599; Sat, 16 Apr 2022 08:29:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smeets.xyz; s=dkim; t=1650090599; 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=fGjHv9Cti1IfkhvYG+8jm9tTkmgHvAAyVBYJAgFcmq4=; b=Ts+v8mVhc9DdCAhDs7lX4XlwJymBJBd3+lZBLBC/7Xuk3Ysoulr250aE3L5QwGc/DTcnsE 12ipkvtpp5RWzg5eKFawEbJEC51+cw8il7VSnnj18xneNl+bUwJSYFZgGBLfJUxQEzHee9 bnzpboM2q2pYYoR+IEcIANKBsATeMDFSO3SGrwr3hx6/FlLiEEJehapS/9r888PSzDVp3b HI4jXcGfohN/MxLgPmjKIC1APTYQZ9VRo7KHxTfH8c48poFzlAuM7VB4qd2hoqj8ybiMyV TxgljdeUOppwsur3ajUSSbUg814oph18nnw/WbxWwqJ0dHjVCp31C0JuZesMoQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=smeets.xyz; s=ed25519_2022; t=1650090599; 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=fGjHv9Cti1IfkhvYG+8jm9tTkmgHvAAyVBYJAgFcmq4=; b=uJoH3vYuvrVGGMfeuhz0BSHgLTvZNAQYHdbeXzPhBvKXhBM0aDvwv6ArwL1uesniTTbAbh eOCJ5DgYe1i3kYAQ== Message-ID: <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> Date: Sat, 16 Apr 2022 08:29:53 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-US To: Gleb Smirnoff , Michael Butler Cc: freebsd-current@freebsd.org References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> From: Florian Smeets Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------k9cOxo0JCAlzTAKFiVqNvEYx" X-Rspamd-Queue-Id: 4KgNbg5g9Pz4jyg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smeets.xyz header.s=dkim header.b=Ts+v8mVh; dkim=pass header.d=smeets.xyz header.s=ed25519_2022 header.b=uJoH3vYu; dmarc=pass (policy=reject) header.from=smeets.xyz; spf=pass (mx1.freebsd.org: domain of flo@smeets.xyz designates 2a01:4f8:10a:3543:ffff:0:25:11 as permitted sender) smtp.mailfrom=flo@smeets.xyz X-Spamd-Result: default: False [-2.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[smeets.xyz:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[smeets.xyz,reject]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; RCVD_COUNT_FIVE(0.00)[5]; FREEFALL_USER(0.00)[flo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.99)[0.986]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[smeets.xyz:s=dkim,smeets.xyz:s=ed25519_2022]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------k9cOxo0JCAlzTAKFiVqNvEYx Content-Type: multipart/mixed; boundary="------------1LAr0tWtJ7FKk08BCvhFepdP"; protected-headers="v1" From: Florian Smeets To: Gleb Smirnoff , Michael Butler Cc: freebsd-current@freebsd.org Message-ID: <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> In-Reply-To: --------------1LAr0tWtJ7FKk08BCvhFepdP Content-Type: multipart/mixed; boundary="------------UheEKoMLVLvBqpkRKrIN9hqd" --------------UheEKoMLVLvBqpkRKrIN9hqd Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTYuMDQuMjIgMDc6MjIsIEdsZWIgU21pcm5vZmYgd3JvdGU6DQo+ICAgIEhpIEZsb3Jp YW4sIEhpIE1pY2hhZWwsDQoNCkhpIEdsZWIsDQoNCnRoYW5rcyBmb3IgbG9va2luZyBpbnRv IGl0Lg0KDQo+IA0KPiBPbiBGcmksIEFwciAxNSwgMjAyMiBhdCAwNjoxMToxM1BNIC0wNDAw LCBNaWNoYWVsIEJ1dGxlciB3cm90ZToNCj4gTT4gPg0KPiBNPiA+IEZvdW5kIHRoZSBjdWxw cml0IDE4MTdiZTQ4MWI4NzAzYWU4NjczMGIxNTFhNmY0OWNjMzAyMjkzMGYuIEFuZCBpbmRl ZWQNCj4gTT4gPiB0b2dnbGluZyBuZXQuaW5ldDYuaXA2LnNvdXJjZV9hZGRyZXNzX3ZhbGlk YXRpb24gbWFrZXMgdGhlIGlzc3VlIGdvIGF3YXkNCj4gTT4gPiBvbiBsYXRlc3QgbWFpbi4N Cj4gTT4NCj4gTT4gSSBmb3VuZCB0aGlzIGNvbW1pdCBhbmQgdGhlIGlwdjQgYW5hbG9nIGFs c28gY2F1c2UgcGFja2V0cyBiZXR3ZWVuDQo+IE0+IG5vbi1WTkVUIGphaWxzIG9uIHRoZSBz YW1lIGhvc3QgYW5kIHRvIHRoZSBob3N0IGl0c2VsZiB0byBiZSBkcm9wcGVkIDotKA0KPiAN Cj4gSSBzZWUgeW91ciBtYWlscyBhbmQgd2lsbCBsb29rIGludG8gdGhlIHByb2JsZW0gQVNB UC4NCj4gDQo+IE1lYW53aGlsZS4uLg0KPiANCj4gRmxvcmlhbiwgY2FuIHlvdSBwbGVhc2Ug Y29uZmlybSB5b3UgYXJlIHVzaW5nIGphaWxzIHRvbz8NCg0KTm8sIHR3byBvZiB0aGUgMyBo b3N0cyBJIHRlc3RlZCBvbiBkbyBub3QgdXNlIGphaWxzLg0KDQpGbG9yaWFuDQo= --------------UheEKoMLVLvBqpkRKrIN9hqd Content-Type: application/pgp-keys; name="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Disposition: attachment; filename="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFpyBwsBEADLq0c46orEtbMn4SptX+VJxR1wB4YwaErZme1bqF4nZHIhlRNE T22HsHdQdoagaB4uACq0Rj5kHcu614ZnnNkLPyCxWQATx+cbdiFO4/hfT8tAvKnB tiy3awKJ5uGCNO2EzJwXW6KwdDA8XPRySqN8m1yPl+dW0Cls+/vO/QL/6+YLMupm EpSvFxRzAZTQuKyX4+xl+dYId24JiPd1yfCuDNOY3+OZ3QBMT00u/699N8lUWRti TwaQMwAOww8r/26YM6/SgcgFuLH2E/CVplY0sDvfoISlAj8agxdomNXfPjCMQ6w5 yGZmA+huFpPCVBTi3on/SWgbQO7dLVpN4BNPuScPosCb/dsOg0S74zCClsIU3gdU Gh9rwJY00/Ebid6V0R3c1Czwbg8LQedzlGDuXYXmzp6W2ujgr1cqbUD6lUWikUv2 IMdCbb8MxYhHLi3GYUs5Xpi+W7vM6T45KbuMr7O/1SjtcGOlNeDvGNgjcDk20fOg PPZ+M6i9vX5Q2oI9HoYaeTiYNwILkBLVP/L40kTo5EkiQOt4OW6BMbylqXPOaQMW uGVbmhCJQpbx8Vo80s2yiBBVWkLkWQIcIm3KZlLldJqKEFpQBWLBE1eFFqboYgAW zFn73CaV5tihobijMmmOV3a8cI1fI4kREyl3g+8bW+O0u3m3tuzVOpDpjwARAQAB zSBGbG9yaWFuIFNtZWV0cyA8ZmxvQEZyZWVCU0Qub3JnPsLBlAQTAQoAPhYhBOyz aLh5CL+2kU1yae9bpNzVqfPABQJh8E3MAhsDBQkLM37BBQsJCAcDBRUKCQgLBRYD AgEAAh4BAheAAAoJEO9bpNzVqfPAOjQP/1FdgHTug7m1OGP3kz5xOID6cuSDUZ1Q eFNvGOU/g0qty1Bda9/dcRJjOdbtIkpPXPUbOZiZWFLABBo82lxufjso1uzwlvCZ q/qMYMtpTys8LZUVOrbVeUM8KKLHtLq2DL49Et8DqwENcxaPa604RExsfvrBAMwO WF6kH8DC4cbCi+2B335NUCFoM/qYC3Ph0bCrWu0lsiEd0G3WJ8Wz8OiEgD+muoQt aEMKkg6B97TaCvcLf25j6VO0bTiySM3e1RwNPaTyu9GSh5L7PThPE67HuA27NXoh +oHDVbdM475OGIQ8IAWvuPyEJ6R91IjpQFR3qiyWeppR1Ag5XoB1DpQv8fKu2bQz m7lQWC07djntw+ScxcDxiuj7+PL1ClKKjezTSmvjJEA6G3wB17MtSnI8TMVnPR1N GsShTY5Fl5ihyQw1wg2eJLXJg0rYLubhPhJiyoiGOIk1BR340Aben1qDC33V9Qo5 CKFlXizvFygdy3h/aIJeq9m2uQvQpPkMM4Ije2tmvlK+Q3HJki0OnbeGf4vJa/dB VdnjAp7idYaVyKhV4D3daH1zOTWwxLrSHOv5ixpR+ZCmG6nmApEKE2q5lm/bx5ZA XP9SSwyLdV22PUbuiNGZ5eJx/9lhuX16nVZ3F2xJZnJuqQV7kWxAedxwaN5P5U8K TPFPgLRAD9U0zR9GbG9yaWFuIFNtZWV0cyA8ZmxvQHNtZWV0cy54eXo+wsGXBBMB CgBBAhsDBQkLM37BBQsJCAcDBRUKCQgLBRYDAgEAAh4BAheAFiEE7LNouHkIv7aR TXJp71uk3NWp88AFAmHwTcwCGQEACgkQ71uk3NWp88BpTRAAybyHhteWLV4VDlzl 7NPxbN8c9cDDv1r0HlaUVxfrSw+1rzycEdhqA8o75Wh5II4KAFTbX2igGckskcoO dqm68MU8+zAtVxVZaqX+EGNXSLWZgAzlf9rAHDm/O1ZBShZhn9EJyarYPaSRNBev VaR9bY6LEFmDacb6qnRVOH4Z/6O6fq/IxoXQqyV1NDmmObxtCcxwx71v+7mJoBMT ximtdrPmcpGesCQquiWKa6DyYjZIEZ9gQPttLQ+iYmwWJp6q68VULqY9X0zG7byc 3Xe7W/5oEoTA/gSWG0EbPOdfTS77TTNxhgBzFB6VY81PVAYzH419Q0b055XLTupo +JTQUb6bbluH6UJIBtIp1iJlGN42qvkMwqTogIdat/3aA+EWEfG7iWlx8Z1hFU3r 7GMJ5o8QLsloVNWAda+iHaidIJvU1fJa0U9v2r1d/KwYHj2qlMaQMZHjldULp7LP P/pITeQEnma3mZ6IX7cp6mUd8MOiVTPE42fPs8qBHKfuEcg7L07NcdRzzgS0LGQf v6fbnvNnvsDGAt4zGQ/Hj72Z5/eL1sDnoJQUHNHMJlNJieGplbLm3LacNQZa9979 BjwK+mUr1nPaaP4YR3czfVwTMrxPKT9kFBDZL4YQ8LbsH5JJC3As3EJdptIkANSm +hU54sG8QPz6TDsm7754d1n12M3CwXkEEwEKACMWIQSnAQMgO8q0Spj+yETnBT35 /4bwdgUCWnIHOAWDB4YfgAAKCRDnBT35/4bwdmNtEACU20uv5Lvuit3DtzQ5m4eP HAQzdeg6Uqpm7nNHB0KKGPCtKmf55bDVHfVuKS1pu1jBXFxGKyEKY5+QaxVrt9Dl iDqfqEPDmIqDdG13ch0cV3lan+3Jli3M2OwsHNac72MPFp++eAUbA9wgn6y6GlJx 9/oCtDuY9FucpL/P8zMbH5f00qBEKsC+lq8u+ZY/7lPYdVaZl3doLZcGCCsgbLP/ ytJPc7qzbHrW1wa7kBFKPLUhAbDFWTQz8L8Zt3cCDoqCc3N0rLZ419LA3NgROek9 nXuti9RG0AofI6t8tMKFBJs1oE9jbs1iqWzG0HdI25U/I0euAUwJNlkVBDwQIOgw HzLYqdnmVJD9HWxMv0cKNY9xVZEnCem1JJaK/+9nrbUtOOvp7l7PWRSbePWYQRT3 KCDZuhl0I7A1qWX+SU28cuxRkxsVni6wvUKEkuxpT07A6XhMmLtGOJSpTDR/hsky gBCs1YSdDJe0NZleaBJ5LIJ30/p68qIm1cFFRLm1hi3bwuBiHq3/SYVTdUWAR/Kl 4xscL8o9f3A7J/npOU126Zn63ItMguHWrangJdTUUINUlF0wleTmZYpTP5+ck7gc Br05VZGWXyNTMYChzS0oQXHCZYdAV9YghRhj2PWKLGhmB8Z+1vo49o1AmGFswlZe TGwUZ2r3d7pZUF0N9zOkbs7BTQRacgcLARAA0es6bm/J0r+KPXOQPItnNuiCTnOM yHqgCvdwfigZskc8uXIVlMJUFhTAPiSHo1XWwq5k55f9rKDJWDVHIu6WfOxzpiNc 4jGWqGpDAYjyTyywAikxJ/Tb3vzUI0XYcLjYKsl4e1c040M06Owy6jHOBr3MtAKH iMtOUT9NQmjopUAFYFVG1NWHZnvukq03uPY08UEe+nsrRYd9X5NieWyCOFQDQAJm dR0dLZhHMGELPNB6W53EHPnhL3FtSrWZ9l9XHwBsAZcXbPGjrye+8AAmfjweIFLd 0yEIZgkN1l2NrpB1QU+J6aKc7HCRTMKqYrGb4CPtRK57VJtlmonGYwjV4Xg6uT8E kkjvhn8WcmBhHhSQSIPcn8pShxAIgfd1oHX78JeWH30hvsA/5Aa4qTe+c0eHtUGr cT5UCIzktTQGaBb5x1E8eSLAzuwNrZWdXdWq9XtCagwqccXNQHo2fy4T6JqSnknz U+vryQM6ruQtbdScaaDU9SpuycJpOKYlvckBhbM5b/0Jhw+VsB0iqL7Afsw6h4v4 8D30DeRb/zzWsaZ45gXPOuw1Uu15r4Al9e2ngs3mA5Ug8imi8I1JVdcQqCXtri+N QbNUHOsfs/NP6ThdQRDA0IAJ8ZnEQTG2fLX1uO+6ZnSu/4AQAe+xZIpcdRUnMg2O p31SKhoRsoYA+U8AEQEAAcLBhgQYAQoAJhYhBOyzaLh5CL+2kU1yae9bpNzVqfPA BQJh8E3NAhsMBQkLM37BABQJEO9bpNzVqfPACRDvW6Tc1anzwPfkD/4yF78b+PSP mDiAsOffMd+U53MhT1Rem+PWxChsn4VqMtLArcr+vxqYcTrZNtb5bsYQgDMz47Zl L1N67PWfe129btyTkOSzA56o0eSfl4mhGhnGQRYczxAHw2bN4JtCwZW7kwhqcGG3 nglWVG9O9GPerSl4c1PB5EYGUjNCL5mn7/kTwSxoNMjOhEsQS+HgjLoRHi7+jNQu VW5hY53wrkTH7itAZohHxYd+zifPciQyUQw4P0hWe0XSVcwJN+xz81NhA5X0L6jl sy9G8xQmx8k37BOTKAqatPIesSlk4lzTNuVXmnbrIGGsvzYO46sMZiT+EPnmcf3Y Aq6mMNidmlWoVyOBKnclLzmEj/gFceIVrGCPGtG9pEdXAbpnSnYZcet++HCS1bRH YMnrPxB7E+1Xy6GVvylfahIcsXMt1mpI0FKzuJcH8O4Asv+QsKY6Q4tcjSX0CROH EnGO9lIaNOA7nYXP5hsuyIjHkPRZ/VgrwD+/z9PUKszqyDBIpwf4Rk9Cmg8z2+TP xnooLMBnTAQPNYIiI9fMyWOHtfPkLIiGUtGBHb7LAQZ7Pxsi5fR36+crhwJiQhpM brthm4VE2pwKnMlohLXnxQtoMMfTw9jzCpTjwuEEFYIIEte8X5GyXItfAm4b9z77 5PDS0JZbUcHZ1sv65OP599IaYgf3rzJnIw=3D=3D =3DYr0r -----END PGP PUBLIC KEY BLOCK----- --------------UheEKoMLVLvBqpkRKrIN9hqd-- --------------1LAr0tWtJ7FKk08BCvhFepdP-- --------------k9cOxo0JCAlzTAKFiVqNvEYx Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE7LNouHkIv7aRTXJp71uk3NWp88AFAmJaYmEFAwAAAAAACgkQ71uk3NWp88Cn ow//YayN5K+dYbR+bxVuLtZlHNaq7NG2GrGougPm62C6fHpfywQKNLmp3ACYo1zckmZdtkkLtMim stsDZRByrKsNeamZEa6HUKRZeZZs2Qw5UMUVpVyZug7Sl6Xqj4em5eDDoi8DGwCpLOSyeLKO5gDI PiQz24JbLVWqdO97BOWLVDQinwYbskzBPoSulLfjuqke9MYWTIBNgBuPRejnGdmDcPJsehLDlm+B mZHFVTMKDdbJ+XW1icRK+GzJH56k2NIK7iJq4whnJExSvBf2sSs/Q/vrARbqqOTIlHYgwmlND+DU HehEi48blC0hAZlF8C/sFMp0cp8vgy/mBveHwC9bGGskV14rYrJwUsXHOY9PvlXmhmiuTDcC+HRi Hte0BHVe73F6zo97reKTY7g1yOtASlVnHhkLnRobzfgDqftU9eEeXAZC83SReDoRA28S4faZqrXh cBM/EyKj/f2AGE9GDiJ4wyJwiRsse3mUWAQ/0CBaIkdZpR0FPMAw8u0hqxJOAx3JlOATgkh1rFZY OWAwrrrDXqzl9WbndE49TcLZb7/ENZjge7AsPxllN6Z04g3J+0gfUXFAY1Gv0LgImVhZrkmHsHWz qWnmA/bpk+KSDTCm5iCC1Y+wPhKzrfwXxIpIi181btl9zZATiZ6AUjlGjl4u7nFulmuA3D9vul8P 1Ww= =UPoP -----END PGP SIGNATURE----- --------------k9cOxo0JCAlzTAKFiVqNvEYx-- From nobody Sat Apr 16 11:23:25 2022 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 CD5739F1BDE for ; Sat, 16 Apr 2022 11:23:38 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgW6K6VHjz3ptF for ; Sat, 16 Apr 2022 11:23:37 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-qk1-x733.google.com with SMTP id b189so8165431qkf.11 for ; Sat, 16 Apr 2022 04:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=A3/qt6EKKb9clcRP8K2tQ3QRjWFeHBV4KBFddppBCzQ=; b=e3zqMkkqZIugN8OYgDnPmsynMoW2Yy8isp5GG4GKkNneEVWOBq+JcnwAikoXWig7hZ jbFSo71fH1Q2hW15spkJUZ8tfVUbs2PaLPenDO+MOp5hJDB8zCw5OpUkZWr6e+vZBycZ fTPRu9qyhaES/pRYPgalVuOkijzL06fK9VkLFfqJj97Khg2n2ZXVuePUGkWWxaHgb8hb 13o/aXoGFaQbbmZ3LBmKmY2zeF3S1h2mLy3ZlzjeUgHLTq01/Ph63Gncb5hioXo9/ucg 3zyNo8E3ITjdQ0MWnvLdO80riEBfbzjG+Pp7a0oRdM8lJzzVN3DhgXaq6vPQQXvpF7AV vuJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=A3/qt6EKKb9clcRP8K2tQ3QRjWFeHBV4KBFddppBCzQ=; b=UBTaW3aWXEwPlAmGcUOCtjZrCTJV8vJOb0/DXAm/FY17iOcIlj2014DfeGBnYizKCF GYWqa9HsbQVUcQ+WtPjmPC2TyTOLsCqyltqIG5LumYTzYoWcqkNXYyyAnfXVgWL8Kv4I TPZb6eR0/DlyTZFbdaYpdOZj8IjxUVUTv/MZ8d9lcl3WUykDnvbxAqoD2vE5xBBwysEz MZKQ9xF/NvjN2K/XnANZtxHy6k90mwfcaZEY4Mjt8rGVszrm1hpMxMm8qlq8zOJMJBqE 2O78ZTPhRIbZMiD9QV2xef2ymy2EhJwE7Tj4Ak1BQRuGSrQArxtwcfP5Vdnqncw39k+d 4GbQ== X-Gm-Message-State: AOAM5301coTA89ujLRU1VSVQW9cJGfRfzS4mBjTOaPhOEv3s9Nd4PEeW wUHK47HBrqdXoZ/umB00CGlSaGXAreFbK8Gf30eCsOKF X-Google-Smtp-Source: ABdhPJwjNuG6XJ+GmwWb3d0SA319F8ggrcbi7nlH8x1iUN5CJpS+Z7GCmgujLmmHf5FOI4q3n9WoN8dXwBfz8h6iV8I= X-Received: by 2002:a37:9c8d:0:b0:69e:6ef8:1a5b with SMTP id f135-20020a379c8d000000b0069e6ef81a5bmr1530754qke.594.1650108217164; Sat, 16 Apr 2022 04:23:37 -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: Sami Halabi Date: Sat, 16 Apr 2022 14:23:25 +0300 Message-ID: Subject: recover deleted file To: FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000002007dc05dcc3c229" X-Rspamd-Queue-Id: 4KgW6K6VHjz3ptF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=e3zqMkkq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sodynet1@gmail.com designates 2607:f8b0:4864:20::733 as permitted sender) smtp.mailfrom=sodynet1@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::733:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000002007dc05dcc3c229 Content-Type: text/plain; charset="UTF-8" Hi, is there anyway easy to restore deleted file by accident in UFS???? Sami -- Sami Halabi Information Systems Engineer NMS Projects Expert, FreeBSD SysAdmin Expert Asterisk Expert --0000000000002007dc05dcc3c229 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
is there anyway easy to restore deleted file by ac= cident in UFS????

Sami

<= /div>--
Sami Halabi
Infor= mation Systems Engineer
NMS Projects Expert,=C2=A0FreeBSD SysAdmin Expert
Asterisk Expert<= /div>
--0000000000002007dc05dcc3c229-- From nobody Sat Apr 16 11:49:10 2022 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 C54BDC098C6 for ; Sat, 16 Apr 2022 11:49:20 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4KgWh014Lhz3vPG for ; Sat, 16 Apr 2022 11:49:20 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [188.174.59.102] (helo=pureos) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfgvQ-0003ZK-Jj for freebsd-current@freebsd.org; Sat, 16 Apr 2022 13:49:12 +0200 Date: Sat, 16 Apr 2022 13:49:10 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: recover deleted file Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.59.102 X-Rspamd-Queue-Id: 4KgWh014Lhz3vPG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of guru@unixarea.de has no SPF policy when checking 178.254.4.101) smtp.mailfrom=guru@unixarea.de X-Spamd-Result: default: False [-0.83 / 15.00]; HAS_REPLYTO(0.00)[guru@unixarea.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_NONE(0.00)[]; RWL_MAILSPIKE_EXCELLENT(0.00)[178.254.4.101:from]; NEURAL_HAM_SHORT(-0.90)[-0.898]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; RECEIVED_SPAMHAUS_PBL(0.00)[188.174.59.102:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.33)[-0.329]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[unixarea.de]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N El día sábado, abril 16, 2022 a las 02:23:25 +0300, Sami Halabi escribió: > Hi, > is there anyway easy to restore deleted file by accident in UFS???? Yes, restore it from a backup media. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Peace instead of NATO! Мир вмеÑто ÐÐТО! Frieden statt NATO! ¡Paz en vez de OTAN! From nobody Sat Apr 16 11:51:10 2022 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 79961C0AB14 for ; Sat, 16 Apr 2022 11:51:24 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgWkM1dglz4R96 for ; Sat, 16 Apr 2022 11:51:23 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-qt1-x829.google.com with SMTP id x18so1604924qtw.4 for ; Sat, 16 Apr 2022 04:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BcOCk/sEiCbAo5TNBoCyqvxUsLbHv6ExWYSX7buAlOs=; b=i/LcRl8GIy4rok6aJwpjNO2bA/9izHMR/vUGFVRqZUQHZO5ksP/cdUrKGCmOL6Zy2E qDVbToztIzB1PkunpoYqpkQ3JO8n9/YSUz7CLZFiuSR8EL5ypJDR/3r+e2mXFX3oETFQ rPS/cWLiK5FYJsfKmWpGT7uPcP4oMzYUfQQAhjtTZVAhOuhoRcUdGlcLwt5OAbA9DZ89 iC7cZEMU1n0DuSTs255/ix3WQGnNKMSM2Le8vyyBr1RtBrUuyAdWxjAHZO/npUURmtX2 MfLwjPyLAzEjXXRSqCIju0Or6o0R0YzTm+fC0KNN75vaHKlRKjtWNxXOwUL+NObvJ8LS 8nAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BcOCk/sEiCbAo5TNBoCyqvxUsLbHv6ExWYSX7buAlOs=; b=6Ylwz7kmH2slvdokiCzXt7raA82LJSOLjkqNNLRVVkr2Xf/UjhDbErqf5vSe/eJ/rZ Oqms5IS2cYF6AINoTPagBGScc82huqaWye9SHNTPa5zMbfkH1soIZDIDBwJU4GlX3x9z M66HdJL9LWMX5MNONcKXtdfHU3++JfllT1kvlgxYrkg6Qg1RBRes+q5YfXEERFJWTlGc 1EZIPbhHiq4DGDe92re9/XtZbiC5yeelw64LsoMOEGuzaBODccDYEYVedreSVN82hGPq Ku6+hThry19vhfGtIoTNIbid/zZ6sjAY4B0WaTmDPErfJHKtNyt4el3UIoCRIbD9SONG hNCg== X-Gm-Message-State: AOAM530tnBZU1b+Yv+f/s6A/DNZjv4ZZGzK2KIMHI68VktG6noJye3lu p7HkFEhXCNVolkiStTHrgJ8vQRAbx1BmZar7WPHTv50S X-Google-Smtp-Source: ABdhPJzBeyaYzdgtXOKLpTHZ9Mz7i2hi6Hb/8twJhXfD5KfEqM6TopYBIz8DR3orZoUOp3x+lTNi2bik3g2OldJb56U= X-Received: by 2002:a05:622a:48d:b0:2e1:d4ff:3179 with SMTP id p13-20020a05622a048d00b002e1d4ff3179mr1959046qtx.442.1650109882419; Sat, 16 Apr 2022 04:51:22 -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: Sami Halabi Date: Sat, 16 Apr 2022 14:51:10 +0300 Message-ID: Subject: Re: recover deleted file To: Matthias Apitz , FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000061d04d05dcc425e5" X-Rspamd-Queue-Id: 4KgWkM1dglz4R96 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="i/LcRl8G"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sodynet1@gmail.com designates 2607:f8b0:4864:20::829 as permitted sender) smtp.mailfrom=sodynet1@gmail.com X-Spamd-Result: default: False [-2.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.94)[0.938]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::829:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000061d04d05dcc425e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable well.. thats the trivial answer.. the problem is backups is a day before... if i can undelete it would save me loss of 1 day offset.. anyone? On Sat, Apr 16, 2022 at 2:49 PM Matthias Apitz wrote: > El d=C3=ADa s=C3=A1bado, abril 16, 2022 a las 02:23:25 +0300, Sami Halabi= escribi=C3=B3: > > > Hi, > > is there anyway easy to restore deleted file by accident in UFS???? > > Yes, restore it from a backup media. > > matthias > > > -- > Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > > Peace instead of NATO! =D0=9C=D0=B8=D1=80 =D0=B2=D0=BC=D0=B5=D1=81=D1=82= =D0=BE =D0=9D=D0=90=D0=A2=D0=9E! Frieden statt NATO! =C2=A1Paz en vez > de OTAN! > > --=20 Sami Halabi Information Systems Engineer NMS Projects Expert, FreeBSD SysAdmin Expert Asterisk Expert --00000000000061d04d05dcc425e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
well.. thats the trivial answer.. the problem is backups i= s a day before... if i can undelete it would save me loss of 1 day offset..=

anyone?

On Sat, Apr 16, 2022 at 2:49 PM Matthias A= pitz <guru@unixarea.de> wrote= :
El d=C3=ADa s= =C3=A1bado, abril 16, 2022 a las 02:23:25 +0300, Sami Halabi escribi=C3=B3:=

> Hi,
> is there anyway easy to restore deleted file by accident in UFS????
Yes, restore it from a backup media.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 matthias


--
Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Peace instead of NATO!=C2=A0 =D0=9C=D0=B8=D1=80 =D0=B2=D0=BC=D0=B5=D1=81=D1= =82=D0=BE =D0=9D=D0=90=D0=A2=D0=9E!=C2=A0 Frieden statt NATO! =C2=A1Paz en = vez de OTAN!



--
Sami Hala= bi
Information Systems Engineer
NMS Projects Expert,=C2=A0FreeBSD SysAdmin Expert
Aste= risk Expert
--00000000000061d04d05dcc425e5-- From nobody Sat Apr 16 11:57:25 2022 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 DA45AC0CB7E for ; Sat, 16 Apr 2022 11:57:45 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgWsh6x1tz4Sqx for ; Sat, 16 Apr 2022 11:57:44 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x135.google.com with SMTP id f5so6071572ilj.13 for ; Sat, 16 Apr 2022 04:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yYOwAa5RecLh1rYfBrrlisT3DfG0ATrzm3Nf0I7NdPg=; b=aYlryD2dzaDhZJlCC+h0oI4j7i+3uzQogU8SDyciru4Foe9a0Yx21j3O1UtejUbF9y /sk3qMh05LWF/ArAH1V5tx6w9Ghq2c0Ro7caO0gPmi3L1YHsqUYTX3GtpKdYrWwHuxaw oPJnGOBynhN2SHOWpzaNl/qI8Ww4m+GzhOB0PCPvT8MmzlvNdd1zqosYvXEn52S3uxo7 ovlvyZKcxg5FRZC3VPK44BeCJEA4yUayo+cCyNuzF1xd38DjZ2zuA/JzoxEbE/P4PdCo KyalfZj8sUHjsUNWwdwwcnY1Qw8lPIJAeWsxZNIhwg2xrxaQjdt4PyFh8rN8ULvAj5U6 YxbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yYOwAa5RecLh1rYfBrrlisT3DfG0ATrzm3Nf0I7NdPg=; b=IeGjKpRr79i2Y1PpK57+ZW1lddDNsF55WBvSEllBWMO0irO+PIWXm1mOM8SPDgtdBn LXiwLZz21MA9n5BhYOWFm5s+oiw6sth4LgYJ20hd6GWcaegK8uuyCHpOHTiR2nOFVLO3 57WT81gfoQaYS/M0pA1FLGvWONKj+hQ0jXRq1ozC1hzCGkiVUfJZ/GWbkQJIpcTl9CRx 6NTHx9L4To+57YPjD4awPBrNtALjlNcN7h2ZYZEF/8gUhu/7b756btQKgGOqx9C58wii JBLnJ5wxpVauYZ7/lHWjvpwCIFpSwouc17qK5sXqDiO2avwQLxtVCMLEuF2E3bAilf2e p0cg== X-Gm-Message-State: AOAM533XR4QXSVBF8IJNwfO6Us9AGNuJ40v8j0fsKgXJiuURxeep10JS Ml8SU1e8CPeO5AsuXcJOZ4m97dev/igA/XeoIFI= X-Google-Smtp-Source: ABdhPJzku3q/eS/WlLRXNZV7suaTn+VJJoscadYuqNXJw4RcPeqv7qU2SOcGbvKBx0/xsEGDwSZfCGkwld/lNVZNlzk= X-Received: by 2002:a05:6e02:16cb:b0:2ca:b5e8:db59 with SMTP id 11-20020a056e0216cb00b002cab5e8db59mr1087676ilx.277.1650110258506; Sat, 16 Apr 2022 04:57:38 -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: Michael Schuster Date: Sat, 16 Apr 2022 13:57:25 +0200 Message-ID: Subject: Re: recover deleted file To: Sami Halabi Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000cc72ab05dcc43b9b" X-Rspamd-Queue-Id: 4KgWsh6x1tz4Sqx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=aYlryD2d; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::135 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-2.04 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.960]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::135:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000cc72ab05dcc43b9b Content-Type: text/plain; charset="UTF-8" On Sat, Apr 16, 2022, 13:24 Sami Halabi wrote: > Hi, > is there anyway easy to restore deleted file by accident in UFS???? > If you used "rm" and didn't take the media offline immediately after, then no, not only not easy but probably impossible (depending on how active the FS is) > Sami > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert > --000000000000cc72ab05dcc43b9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Apr 16, 2022, 13:24 Sami Halabi= <sodynet1@gmail.com> wrote:
Hi,
is there anyway easy to restore deleted file b= y accident in UFS????

<= /div>
If you used "rm" and didn't take the m= edia offline immediately after, then no, not only not easy but probably imp= ossible (depending on how active the FS is)=C2=A0

Sami

--
Sami Halabi
Information Systems Engineer
NMS Projects Expert,=C2=A0FreeBSD Sy= sAdmin Expert
Asterisk Expert

--000000000000cc72ab05dcc43b9b-- From nobody Sat Apr 16 11:59:09 2022 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 5D520C0E4DD for ; Sat, 16 Apr 2022 11:59:24 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgWvb0z6tz4Tn2; Sat, 16 Apr 2022 11:59:22 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 6f46f9bd; Sat, 16 Apr 2022 11:59:14 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id bd0282a8 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Sat, 16 Apr 2022 11:59:11 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-B5AB60DB-00BE-4FAC-8247-AABB091449C1 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 (1.0) Subject: Re: recover deleted file From: Michael Gmelin In-Reply-To: Date: Sat, 16 Apr 2022 13:59:09 +0200 Cc: Matthias Apitz , FreeBSD Current Message-Id: <70EA83C9-61AE-4256-9FF4-458197BA261D@freebsd.org> References: To: Sami Halabi X-Mailer: iPhone Mail (19D52) X-Rspamd-Queue-Id: 4KgWvb0z6tz4Tn2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [-2.33 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.98)[-0.980]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.96)[-0.955]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.79)[-0.790]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail-B5AB60DB-00BE-4FAC-8247-AABB091449C1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Depends on the kind of file. You can always: 1. reboot the system into single user mode, mount the fs readonly (important= to not overwrite data you want to recover) 2. dd the partition and into a file 3. find the content of the deleted file in the dump I was able to recover a complete codebase i deleted accidentally that way a l= ong time ago. Good luck Michael > On 16. Apr 2022, at 13:52, Sami Halabi wrote: >=20 > =EF=BB=BF > well.. thats the trivial answer.. the problem is backups is a day before..= . if i can undelete it would save me loss of 1 day offset.. >=20 > anyone? >=20 >> On Sat, Apr 16, 2022 at 2:49 PM Matthias Apitz wrote: >> El d=C3=ADa s=C3=A1bado, abril 16, 2022 a las 02:23:25 +0300, Sami Halabi= escribi=C3=B3: >>=20 >> > Hi, >> > is there anyway easy to restore deleted file by accident in UFS???? >>=20 >> Yes, restore it from a backup media. >>=20 >> matthias >>=20 >>=20 >> --=20 >> Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-1= 76-38902045 >> Public GnuPG key: http://www.unixarea.de/key.pub >>=20 >> Peace instead of NATO! =D0=9C=D0=B8=D1=80 =D0=B2=D0=BC=D0=B5=D1=81=D1=82= =D0=BE =D0=9D=D0=90=D0=A2=D0=9E! Frieden statt NATO! =C2=A1Paz en vez de OT= AN! >>=20 >=20 >=20 > --=20 > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert --Apple-Mail-B5AB60DB-00BE-4FAC-8247-AABB091449C1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dep= ends on the kind of file.

Y= ou can always:
1. reboot the system into single user m= ode, mount the fs readonly (important to not overwrite data you want to reco= ver)
2. dd the partition and into a file
3. find the content of the deleted file in the dump

I was able to recover a complete codebase i= deleted accidentally that way a long time ago.

Good luck
Michael

On 16. Apr 2022, at 13:52, Sami Halabi &= lt;sodynet1@gmail.com> wrote:

=EF=BB=BF
well.. thats the trivial a= nswer.. the problem is backups is a day before... if i can undelete it would= save me loss of 1 day offset..

anyone?

On Sat, Apr 1= 6, 2022 at 2:49 PM Matthias Apitz <gu= ru@unixarea.de> wrote:
El d=C3=ADa s=C3=A1bado, abril 16, 2022 a las 02:23:25 +0300, Sa= mi Halabi escribi=C3=B3:

> Hi,
> is there anyway easy to restore deleted file by accident in UFS????
=
Yes, restore it from a backup media.

        matthias


--
Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Peace instead of NATO!  =D0=9C=D0=B8=D1=80 =D0=B2=D0=BC=D0=B5=D1=81=D1=82= =D0=BE =D0=9D=D0=90=D0=A2=D0=9E!  Frieden statt NATO! =C2=A1Paz en vez d= e OTAN!



--
Sami Halabi<= div>Information Systems Engineer
NMS Projects Expert, FreeBSD SysAdmin Expert
Asterisk E= xpert
= --Apple-Mail-B5AB60DB-00BE-4FAC-8247-AABB091449C1-- From nobody Sat Apr 16 12:31:11 2022 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 96BF35D67F9 for ; Sat, 16 Apr 2022 12:31:24 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgXcW63Dmz4cts; Sat, 16 Apr 2022 12:31:23 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-qv1-xf2c.google.com with SMTP id a10so8018158qvm.8; Sat, 16 Apr 2022 05:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TxpMKPDbzIQHO71KtHeTRUiwkb3TpWvuAfMRixmkrdI=; b=DhDm6wXNIo0zsK/Fot+x7UZwxaPUfNRMaz5j36NRRwMqX7SGee23UdLw+XrrogI338 3CtLaVQG/2glYYjS/fCKMpUwPNyX+6D4YITCbLxAMegCSrtbKRKG/l27GhL2T9t0vHLM 17N7cogRWGWqqbgZEZaVZ+iD4UFX6gh+VSvO7bKVOzARkIdk9QrN2VtOB71rgpFXIB7E 3WuZPoqROmgz6MgjCjBuF7istRaEc66dYwydf4ziYGB62cigwPU/QUv3z2/YiQqsnIZy jUbLtzghP9g2YS10Q2D20J43GKSGF7e+HWfe/hjrRZ+tyAsToXBRRRf2CeZwckBtXYsQ 8MzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TxpMKPDbzIQHO71KtHeTRUiwkb3TpWvuAfMRixmkrdI=; b=pvCWwIma1khQXLVzAcl4STJRgQYrh5yqEaGkn97r/1UPRFkKgnfVxMhsqZD4cWSgrV 7upqprCRdYuCtJx8ClfEf3YyUu8ni88VrwNvJ2qIcNz9EmoA9EIr8x+vSZNd/ptmSpaA GsosfiiKfBVWUr6BIcOD1/RzGp7eVmZHkPAckapav4EDRj0kvIIx/I8BQS8UdA9woOhH 3PNuJVRkex/Hn5VxFi0OIda9ZY+HT6pO+8HMFaq5iKWSHYUMiYydee2/WXSAN9xOpCwY swy5TQP4Hw6W3txyxQCJXao3izg8olMLtb6B82by0YqoDHbMcUif+GwJi2b5tAyR5Of3 /11Q== X-Gm-Message-State: AOAM532XqDpIBLrPbkNtRv3hZ+wEE6MrHPHReSynhOBoWUIEP7o2RmhA JaYLf7QjO46hW/PDeb9+OXavFIsKDzA4JwD++vMLxqlR X-Google-Smtp-Source: ABdhPJxvWczfonJNILZuyYbNkyhigntnbGAmZvzrMMKF4zpHYidTB+NqkUeGxPyfoBe+s8DFvc/E1hglWH5II2dErZA= X-Received: by 2002:a05:6214:4103:b0:440:e4d1:a2a0 with SMTP id kc3-20020a056214410300b00440e4d1a2a0mr2160930qvb.42.1650112283171; Sat, 16 Apr 2022 05:31:23 -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: <70EA83C9-61AE-4256-9FF4-458197BA261D@freebsd.org> In-Reply-To: <70EA83C9-61AE-4256-9FF4-458197BA261D@freebsd.org> From: Sami Halabi Date: Sat, 16 Apr 2022 15:31:11 +0300 Message-ID: Subject: Re: recover deleted file To: grembo@freebsd.org Cc: Matthias Apitz , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000007a5d6005dcc4b4bc" X-Rspamd-Queue-Id: 4KgXcW63Dmz4cts X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=DhDm6wXN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sodynet1@gmail.com designates 2607:f8b0:4864:20::f2c as permitted sender) smtp.mailfrom=sodynet1@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(1.00)[0.998]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2c:from]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000007a5d6005dcc4b4bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable how to do step 3 /? On Sat, Apr 16, 2022 at 2:59 PM Michael Gmelin wrote: > Depends on the kind of file. > > You can always: > 1. reboot the system into single user mode, mount the fs readonly > (important to not overwrite data you want to recover) > 2. dd the partition and into a file > 3. find the content of the deleted file in the dump > > I was able to recover a complete codebase i deleted accidentally that way > a long time ago. > > Good luck > Michael > > On 16. Apr 2022, at 13:52, Sami Halabi wrote: > > =EF=BB=BF > well.. thats the trivial answer.. the problem is backups is a day > before... if i can undelete it would save me loss of 1 day offset.. > > anyone? > > On Sat, Apr 16, 2022 at 2:49 PM Matthias Apitz wrote: > >> El d=C3=ADa s=C3=A1bado, abril 16, 2022 a las 02:23:25 +0300, Sami Halab= i escribi=C3=B3: >> >> > Hi, >> > is there anyway easy to restore deleted file by accident in UFS???? >> >> Yes, restore it from a backup media. >> >> matthias >> >> >> -- >> Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ >> +49-176-38902045 >> Public GnuPG key: http://www.unixarea.de/key.pub >> >> Peace instead of NATO! =D0=9C=D0=B8=D1=80 =D0=B2=D0=BC=D0=B5=D1=81=D1= =82=D0=BE =D0=9D=D0=90=D0=A2=D0=9E! Frieden statt NATO! =C2=A1Paz en vez >> de OTAN! >> >> > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert > > --=20 Sami Halabi Information Systems Engineer NMS Projects Expert, FreeBSD SysAdmin Expert Asterisk Expert --0000000000007a5d6005dcc4b4bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
how to do step 3 /?

On Sat, Apr 16, 2022 at 2:59 PM Michael= Gmelin <grembo@freebsd.org>= ; wrote:
Depends on the kind of f= ile.

You can always:
=
1. reboot the system into single user mode, mount the fs r= eadonly (important to not overwrite data you want to recover)
2. dd the partition and into a file
3. find = the content of the deleted file in the dump

I was able to recover a complete codebase i deleted accid= entally that way a long time ago.

Good luck
Michael

=
On 16. Apr 2022, at 13:52, Sami Halabi <sodynet1@gmail.com>= ; wrote:

=EF=BB=BF
well.. thats the trivial answer.. the problem = is backups is a day before... if i can undelete it would save me loss of 1 = day offset..

anyone?

On Sat, Apr 16, 2022 at 2:49 P= M Matthias Apitz <= guru@unixarea.de> wrote:
El d=C3=ADa s=C3=A1bado, abril 16, 2022 a las 02:23:25 +030= 0, Sami Halabi escribi=C3=B3:

> Hi,
> is there anyway easy to restore deleted file by accident in UFS????
Yes, restore it from a backup media.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 matthias


--
Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Peace instead of NATO!=C2=A0 =D0=9C=D0=B8=D1=80 =D0=B2=D0=BC=D0=B5=D1=81=D1= =82=D0=BE =D0=9D=D0=90=D0=A2=D0=9E!=C2=A0 Frieden statt NATO! =C2=A1Paz en = vez de OTAN!



--
Sami Halabi
Information Systems= Engineer
NMS Projects Expert,=C2=A0FreeBSD SysAdmin Expert
Asterisk Expert


--
<= div dir=3D"ltr">Sami Halabi
Information Systems Engineer
NMS = Projects Expert,=C2=A0FreeBSD SysAdmin Exp= ert
Asterisk Expert
--0000000000007a5d6005dcc4b4bc-- From nobody Sat Apr 16 12:44:43 2022 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 8C14D7CC1C9 for ; Sat, 16 Apr 2022 12:44:55 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgXw70NFmz4hVQ; Sat, 16 Apr 2022 12:44:55 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by mail-pg1-x52f.google.com with SMTP id t4so10815638pgc.1; Sat, 16 Apr 2022 05:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Osj9S8gVdc8D+zEUSOcUYXh2zBJJDOaTXH3ZcTPjJdM=; b=gi/DPhCFx80sYe9piytor98MC/oT+eQr014BakVENs2OgYCjLjf80/JSpdd1p7JAu4 Lac277NGZL1FWT3KIV+WPjJvhItuNcFVye+pPZdoTEX7F+SwC5nXfwgiUanX3v/ECthS xo3lx3ruDhwJIesDJz4X0cBBngXep64OSMcGrbd31o/02hR50tn2kgFj0RA/KZjpDghl rPUQX7fuS6Qb/MoZVEhcc9Mf39KS8nDpeVDeUtXsonJk0wWgcwY6LvjgoqnsjEACxugq kM8Hwc4ofDIPIBpZ4/XMASlFOUTfa8YQ4Q7SHIKn0zY6XPE+HQmpxnaC2ODbz7L79bef slKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Osj9S8gVdc8D+zEUSOcUYXh2zBJJDOaTXH3ZcTPjJdM=; b=AtBnbJepNl4pkagPUzgFSfsrOM43/+jWTciM8clyRygXE/V1apQquK/v/PttDVrVIA /KqRQo9bgF3I+R3vGzuGbnhqfj+8v/n2gZPIVMORxxP5YdqPkqZfCb0+mc7UkZJ/3ejE A6Ul09C8pdCHLJHnkRCOeclvZPW63AvhctlJcmHq2eecendCWrUcLTUsOZrJ+PZi/G+H xIjrdBiTLFJcd//PluH8b+Td3ayMeNNh0DKAYX0U1H6dWXxs5ZluEehKd+0N4QcbXeNr 1+ghvxRHPByIxgBnL3qfKiJxFNxWn8qZiM3w5wVPRXL5gXRYjZFf5NeLA+arVFK3wbJU qvFA== X-Gm-Message-State: AOAM532Q5wAHGF7iFjhun10Z4xna5Ox9O2Dp6uTGHIk3cElYu04AyQGi vLAvTLrOFCeyKIK0F8aKUR34NlZRPC7+S7h15yA= X-Google-Smtp-Source: ABdhPJzu6DCLHITxylkjOMDkp1bltUTvMhetiqkrlOZ9EzCmpWrv37SnI6QoUegHyqe1xWnxmvakRzI/EpJ8Mz8dIKQ= X-Received: by 2002:a63:f641:0:b0:3a2:cea2:bcf with SMTP id u1-20020a63f641000000b003a2cea20bcfmr2783971pgj.506.1650113094048; Sat, 16 Apr 2022 05:44:54 -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: <70EA83C9-61AE-4256-9FF4-458197BA261D@freebsd.org> In-Reply-To: From: Alexandre Biancalana Date: Sat, 16 Apr 2022 09:44:43 -0300 Message-ID: Subject: Re: recover deleted file To: Sami Halabi Cc: FreeBSD Current , Matthias Apitz , grembo@freebsd.org Content-Type: multipart/alternative; boundary="000000000000cf5d9a05dcc4e425" X-Rspamd-Queue-Id: 4KgXw70NFmz4hVQ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="gi/DPhCF"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of biancalana@gmail.com designates 2607:f8b0:4864:20::52f as permitted sender) smtp.mailfrom=biancalana@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52f:from]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000cf5d9a05dcc4e425 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 16 Apr 2022 at 09:33 Sami Halabi wrote: > how to do step 3 /? > > On Sat, Apr 16, 2022 at 2:59 PM Michael Gmelin wrote= : > >> Depends on the kind of file. >> >> You can always: >> 1. reboot the system into single user mode, mount the fs readonly >> (important to not overwrite data you want to recover) >> 2. dd the partition and into a file >> 3. find the content of the deleted file in the dump >> >> I was able to recover a complete codebase i deleted accidentally that wa= y >> a long time ago. >> >> Good luck >> Michael >> >> On 16. Apr 2022, at 13:52, Sami Halabi wrote: >> >> =EF=BB=BF >> well.. thats the trivial answer.. the problem is backups is a day >> before... if i can undelete it would save me loss of 1 day offset.. >> >> anyone? >> >> On Sat, Apr 16, 2022 at 2:49 PM Matthias Apitz wrote: >> >>> El d=C3=ADa s=C3=A1bado, abril 16, 2022 a las 02:23:25 +0300, Sami Hala= bi escribi=C3=B3: >>> >>> > Hi, >>> > is there anyway easy to restore deleted file by accident in UFS???? >>> >>> Yes, restore it from a backup media. >>> >>> matthias >>> >>> >>> -- >>> Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ >>> +49-176-38902045 >>> Public GnuPG key: http://www.unixarea.de/key.pub >>> >>> Peace instead of NATO! =D0=9C=D0=B8=D1=80 =D0=B2=D0=BC=D0=B5=D1=81=D1= =82=D0=BE =D0=9D=D0=90=D0=A2=D0=9E! Frieden statt NATO! =C2=A1Paz en >>> vez de OTAN! >>> >>> >> >> -- >> Sami Halabi >> Information Systems Engineer >> NMS Projects Expert, FreeBSD SysAdmin Expert >> Asterisk Expert >> >> > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert > Look at autopsy/photorec https://www.cgsecurity.org/wiki/PhotoRec_Data_Carving --000000000000cf5d9a05dcc4e425 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, 16 Apr 2022 at 09:33 Sami Halabi <sodynet1@gmail.com> wrote:
how to do step 3 /?

On Sat, Apr 16, = 2022 at 2:59 PM Michael Gmelin <grembo@freebsd.org> wrote:
=
Depends on the kind of file.

You can always:
1. reboot the sys= tem into single user mode, mount the fs readonly (important to not overwrit= e data you want to recover)
2. dd the partition and i= nto a file
3. find the content of the deleted file in= the dump

I was able to re= cover a complete codebase i deleted accidentally that way a long time ago.<= /div>

Good luck
Michael

On 16. Ap= r 2022, at 13:52, Sami Halabi <sodynet1@gmail.com> wrote:

=
=EF=BB=BF
well..= thats the trivial answer.. the problem is backups is a day before... if i = can undelete it would save me loss of 1 day offset..

any= one?

On Sat, Apr 16, 2022 at 2:49 PM Matthias Apitz <guru@unixarea.de> wrote:
=
El d=C3=ADa s=C3=A1= bado, abril 16, 2022 a las 02:23:25 +0300, Sami Halabi escribi=C3=B3:

> Hi,
> is there anyway easy to restore deleted file by accident in UFS????
Yes, restore it from a backup media.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 matthias


--
Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Peace instead of NATO!=C2=A0 =D0=9C=D0=B8=D1=80 =D0=B2=D0=BC=D0=B5=D1=81=D1= =82=D0=BE =D0=9D=D0=90=D0=A2=D0=9E!=C2=A0 Frieden statt NATO! =C2=A1Paz en = vez de OTAN!



--
Sami Halabi
Information Systems= Engineer
NMS Projects Expert,=C2=A0FreeBSD SysAdmin Expert
Asterisk Expert


--
Sami Halab= i
Information Systems Engineer
NMS Projects Expert,=C2=A0FreeBSD SysAdmin Expert
Aster= isk Expert

=
Look at autopsy/photorec

--000000000000cf5d9a05dcc4e425-- From nobody Sat Apr 16 12:44:52 2022 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 6B1C27CC056 for ; Sat, 16 Apr 2022 12:44:58 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgXw916qkz4hPj; Sat, 16 Apr 2022 12:44:57 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 2a68bef7; Sat, 16 Apr 2022 12:44:55 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 48deeb56 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Sat, 16 Apr 2022 12:44:54 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-27FE29C9-42D0-4733-BFEC-C59306D76E4F 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 (1.0) Subject: Re: recover deleted file From: Michael Gmelin In-Reply-To: Date: Sat, 16 Apr 2022 14:44:52 +0200 Cc: Matthias Apitz , FreeBSD Current Message-Id: <2FCD9AC4-CE69-4A22-90A5-F9C656064D7B@freebsd.org> References: To: Sami Halabi X-Mailer: iPhone Mail (19D52) X-Rspamd-Queue-Id: 4KgXw916qkz4hPj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [-2.49 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.95)[-0.949]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.945]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail-27FE29C9-42D0-4733-BFEC-C59306D76E4F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 16. Apr 2022, at 14:32, Sami Halabi wrote: >=20 > =EF=BB=BF > how to do step 3 /? E.g., grep for something you know (like a phrase, unique name etc) from the f= ile, then dump N times the expected file size from that position into anothe= r file, open the result in a =E2=80=9Crobust=E2=80=9D text editor and stitch= things together. If your lost file is something binary (or even worse, encrypted), things get= a lot more complicated of course. There might be tooling for this I=E2=80=99= m not aware of, the few times this happened to me, lost files where C++ sour= ces that were relatively easy to extract manually. Best Michael >=20 >> On Sat, Apr 16, 2022 at 2:59 PM Michael Gmelin wrote= : >> Depends on the kind of file. >>=20 >> You can always: >> 1. reboot the system into single user mode, mount the fs readonly (import= ant to not overwrite data you want to recover) >> 2. dd the partition and into a file >> 3. find the content of the deleted file in the dump >>=20 >> I was able to recover a complete codebase i deleted accidentally that way= a long time ago. >>=20 >> Good luck >> Michael >>=20 >>>> On 16. Apr 2022, at 13:52, Sami Halabi wrote: >>>>=20 >>> =EF=BB=BF >>> well.. thats the trivial answer.. the problem is backups is a day before= ... if i can undelete it would save me loss of 1 day offset.. >>>=20 >>> anyone? >>>=20 >>>> On Sat, Apr 16, 2022 at 2:49 PM Matthias Apitz wrote= : >>>> El d=C3=ADa s=C3=A1bado, abril 16, 2022 a las 02:23:25 +0300, Sami Hala= bi escribi=C3=B3: >>>>=20 >>>> > Hi, >>>> > is there anyway easy to restore deleted file by accident in UFS???? >>>>=20 >>>> Yes, restore it from a backup media. >>>>=20 >>>> matthias >>>>=20 >>>>=20 >>>> --=20 >>>> Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49= -176-38902045 >>>> Public GnuPG key: http://www.unixarea.de/key.pub >>>>=20 >>>> Peace instead of NATO! =D0=9C=D0=B8=D1=80 =D0=B2=D0=BC=D0=B5=D1=81=D1=82= =D0=BE =D0=9D=D0=90=D0=A2=D0=9E! Frieden statt NATO! =C2=A1Paz en vez de OT= AN! >>>>=20 >>>=20 >>>=20 >>> --=20 >>> Sami Halabi >>> Information Systems Engineer >>> NMS Projects Expert, FreeBSD SysAdmin Expert >>> Asterisk Expert >=20 >=20 > --=20 > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert --Apple-Mail-27FE29C9-42D0-4733-BFEC-C59306D76E4F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 16. Apr 2022, at 14= :32, Sami Halabi <sodynet1@gmail.com> wrote:

=EF=BB=BF
how to= do step 3 /?

E.g., grep for som= ething you know (like a phrase, unique name etc) from the file, then dump N t= imes the expected file size from that position into another file, open the r= esult in a =E2=80=9Crobust=E2=80=9D text editor and stitch things together.<= /div>

If your lost file is something binary (or even wors= e, encrypted), things get a lot more complicated of course. There might be t= ooling for this I=E2=80=99m not aware of, the few times this happened to me,= lost files where C++ sources that were relatively easy to extract manually.=

Best
Michael


Depends on the kind of file.

You can always:
1. reboot t= he system into single user mode, mount the fs readonly (important to not ove= rwrite data you want to recover)
2. dd the partition a= nd into a file
3. find the content of the deleted file= in the dump

I was able to r= ecover a complete codebase i deleted accidentally that way a long time ago.<= /div>

Good luck
Michael

On 16. Apr 2= 022, at 13:52, Sami Halabi <sodynet1@gmail.com> wrote:

=EF=BB=BF
well.. thats t= he trivial answer.. the problem is backups is a day before... if i can undel= ete it would save me loss of 1 day offset..

anyone?
=

O= n Sat, Apr 16, 2022 at 2:49 PM Matthias Apitz <guru@unixarea.de> wrote:
El d=C3=ADa s=C3=A1bado, abril 16,= 2022 a las 02:23:25 +0300, Sami Halabi escribi=C3=B3:

> Hi,
> is there anyway easy to restore deleted file by accident in UFS????
=
Yes, restore it from a backup media.

        matthias


--
Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Peace instead of NATO!  =D0=9C=D0=B8=D1=80 =D0=B2=D0=BC=D0=B5=D1=81=D1=82= =D0=BE =D0=9D=D0=90=D0=A2=D0=9E!  Frieden statt NATO! =C2=A1Paz en vez d= e OTAN!



--
=
Sami Halabi
Information Systems E= ngineer
NMS Projects Expert, FreeBSD SysAdmin Expert
Asterisk Expert
<= /div>


--
Sami Halabi
Information Systems Engineer
NMS Pro= jects Expert, FreeBSD SysAdmin Expert<= /span>
Asterisk Expert
= --Apple-Mail-27FE29C9-42D0-4733-BFEC-C59306D76E4F-- From nobody Sat Apr 16 12:48:47 2022 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 8A3BF7CF2B3 for ; Sat, 16 Apr 2022 12:49:18 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgY18618cz4l8R for ; Sat, 16 Apr 2022 12:49:16 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fe6d03e.dip0.t-ipconnect.de [79.230.208.62]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 23GCn3kN063545 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Apr 2022 14:49:07 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 23GCn25A031401; Sat, 16 Apr 2022 14:49:03 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 23GCmlIP044778; Sat, 16 Apr 2022 14:48:57 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202204161248.23GCmlIP044778@fire.js.berklix.net> To: Sami Halabi cc: FreeBSD Current Subject: Re: recover deleted file From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Sat, 16 Apr 2022 13:59:09 +0200." <70EA83C9-61AE-4256-9FF4-458197BA261D@freebsd.org> Date: Sat, 16 Apr 2022 14:48:47 +0200 X-Rspamd-Queue-Id: 4KgY18618cz4l8R X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.46 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; URI_HIDDEN_PATH(1.00)[http://berklix.com/~jhs/bin/.sh/lslf]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.30)[0.301]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-0.75)[-0.747]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.992]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[79.230.208.62:received] X-ThisMailContainsUnwantedMimeParts: N 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 > Depends on the kind of file. > > You can always: > 1. reboot the system into single user mode, mount the fs readonly (important= > to not overwrite data you want to recover) > 2. dd the partition and into a file > 3. find the content of the deleted file in the dump > > I was able to recover a complete codebase i deleted accidentally that way a l= > ong time ago. > > Good luck > Michael If it was my personal laptop with an external disk/ stick, I would _immediately_ pull the USB cable out. If a personal PC I would _immediately_ turn power off. I would Not do an unmount or sync or processes kill or shutdown. Then I would reboot single user, fsck & mount only the partitions the data was Not on., dd the partition to recover, then fsck the partition & mount it, & go multi user, then I'd make a 2nd copy of the partition with data to recover & start exploration with eg fsdb man fsdb: SEE ALSO editline(3), fs(5), clri(8), fsck(8), /usr/ports/ { graphics/recoverjpeg, sysutils/ { autopsy, dd_rescue, ddrescue, fatback, ffs2recov, foremost, gpart, magicrescue, recoverdm, scan_ffs, sleuthkit, testdisk } }. If you work had been on text using vi, then vi -r might show a recovery, hint copy the original before running vi -r file , as sometimes pre recovery is better than after. various lost+found may have stuff in http://berklix.com/~jhs/bin/.sh/lslf PS personaly I hand run numerous rdist6 or rsync through the day, when editing important stuff. They run fast, as incremental update, so avoid losing all but the last short period in a day. Cheers, -- Julian Stacey http://berklix.com/jhs/ http://StolenVotes.UK Kill / remove Putin to stop him killing & provoking world war. From nobody Sat Apr 16 13:19:57 2022 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 8C872CFA3B3 for ; Sat, 16 Apr 2022 13:20:05 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (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 "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgYhh3ZP7z3CJg; Sat, 16 Apr 2022 13:20:04 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1650115197; bh=Bp8zwmn9edONAlYY9SYAsVI+COa5C53cbAbv SoxOU2A=; b=XcPs9WdZoIk2ssFwt8rHVttrqtylHorrPtWhunr2zvkvPJQeO76M E/QnP2coITkDeKxhfqRqvPPrCxNJ8s/rHpU7LBIrDSrOXstEdIkz4kIIKXViV3IF 6iSJyJrxD04bDo5327zyZyL2KX2ogNlJ0PZi0zcGW4kC1aQyVTbWVso= Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id A86F14E734; Sat, 16 Apr 2022 09:19:57 -0400 (EDT) Message-ID: <0c261aa6-93d4-5627-d44d-f160323a7ca3@protected-networks.net> Date: Sat, 16 Apr 2022 09:19:57 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored Content-Language: en-NZ To: Gleb Smirnoff , Florian Smeets Cc: freebsd-current@freebsd.org References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> From: Michael Butler In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KgYhh3ZP7z3CJg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=XcPs9WdZ; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 2001:470:8d59:1::8 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-3.96 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-0.96)[-0.955]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/16/22 01:22, Gleb Smirnoff wrote: > Hi Florian, Hi Michael, > > On Fri, Apr 15, 2022 at 06:11:13PM -0400, Michael Butler wrote: > M> >> I can reproduce this locally, will try to figure out what is going on. > M> >> If you can bisect it, it would be great. > M> > > M> > Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And indeed > M> > toggling net.inet6.ip6.source_address_validation makes the issue go away > M> > on latest main. > M> > M> I found this commit and the ipv4 analog also cause packets between > M> non-VNET jails on the same host and to the host itself to be dropped :-( > > I see your mails and will look into the problem ASAP. > > Meanwhile... > > Florian, can you please confirm you are using jails too? > > Michael, can you please confirm or decline that you see the packets > that are dropped when you tcpdump on lo0? All the jails are aliased to share a single bridge interface. That results in the route to each jail being on lo0 so .. probably :-) Michael From nobody Sat Apr 16 15:01:54 2022 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 21FBA5D7FC2 for ; Sat, 16 Apr 2022 15:02:12 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgbyW2tplz3Pm9 for ; Sat, 16 Apr 2022 15:02:11 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-qt1-x831.google.com with SMTP id cp8so4564267qtb.6 for ; Sat, 16 Apr 2022 08:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2fOSkGnFiOG/7wsXq/x8J+iXsFc8rezlfctvmdTX1IM=; b=NVlcvzxUBH6INZ+OI8bApxz6kdNc9b3E3kOi6g6MJqX2cz+oXfxKxv4Fzumv6YIKgZ h7hpVexQa9eNlgZ34ftPu9Wu3lohFfdBnazBkqJOnsCrCCJmr9poZvjnebrTGdXtKcxA jDxxus9wrU6XjKDWqnJm0NIZO30oDLMbm9f0YjwYcKYeDwZKVPHSYIDP7wEO7HcYC3FV 2FgVJClCzmDKCuVQ32zo/WE/E6oqQNUf+EJ640qbQHW1Dgz7uMoe2r0D/OFD1avWzwmt W0L/2iGYVvyS/FWWlT6qSn5s1tNukKn2QmSqZwm3glMiT9r8RzfBsqKuYq9v4xP+LlQ0 yMhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2fOSkGnFiOG/7wsXq/x8J+iXsFc8rezlfctvmdTX1IM=; b=n5Ys2BL9Oh1Wmhkz3ziQcxQlHbCET1efgACbLFnZe4guHl0aIvR3k+BPrXSUBWlmzq xRCR50fSoc/C2e3qc2AtOHKEqvAbEO9zBKLZInlgq7JiQSAs6qBo1JPmchVzHdZKksKO UnKrA28XjXwPGXJrfCul/XPbNfG8uw2wtoNYXzrBdIAeZ7rQtgW4yYe/eAh8imVqKI7F HmsFAuauQA+ToOm/tbt7QVOGdy7a9S/z74t3sDhe5VfyQarI2MF7UlPinLRGhMyjh5SK FQreGhAY56vRG2bJ5rzFjyVxSmdZMQceRFF4tD3RTfRmuLaxIH5IuCEQNJH46A4mvEVZ T+kA== X-Gm-Message-State: AOAM5304kHNRRCVKwpExgckzjUlMiQUkBBvFvPnJCNDaTE5sqEhBv4L/ QM28imW4jbmntIDl0WPkEaIPx++wUprMvC/M1cnTRYE2 X-Google-Smtp-Source: ABdhPJxsIBpPfDmtji0eQNFGhnUEHI3moiTIcJ+fwvnTDL2MugyB5q2UeAgyMnX6pDiFb5tWaTfkXk8OdrWMFl7kezQ= X-Received: by 2002:ac8:4e39:0:b0:2f1:e3f1:2b57 with SMTP id d25-20020ac84e39000000b002f1e3f12b57mr2462770qtw.306.1650121325325; Sat, 16 Apr 2022 08:02:05 -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: <202204161248.23GCmlIP044778@fire.js.berklix.net> <202204161423.23GENCra046094@fire.js.berklix.net> In-Reply-To: <202204161423.23GENCra046094@fire.js.berklix.net> From: Sami Halabi Date: Sat, 16 Apr 2022 18:01:54 +0300 Message-ID: Subject: Re: recover deleted file To: "Julian H. Stacey" Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000006eafca05dcc6cf36" X-Rspamd-Queue-Id: 4KgbyW2tplz3Pm9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=NVlcvzxU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sodynet1@gmail.com designates 2607:f8b0:4864:20::831 as permitted sender) smtp.mailfrom=sodynet1@gmail.com X-Spamd-Result: default: False [-0.81 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.19)[0.191]; NEURAL_SPAM_SHORT(1.00)[0.998]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::831:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000006eafca05dcc6cf36 Content-Type: text/plain; charset="UTF-8" okay... all seems very time consuming operations!! There should be an os "undelete" as happens in NTFS for example.. which is very fast and can be done also with extra tools without a hassle. for now I got backup from last day .. caused me a lot of troubles, not say legal ones, but I passed the point to hold the machine down. any advice? Maybe UFS developer would do a rework so latest deleted inodes would put in a "recycle bin" (maybe with a sysctl or whatever) for say one day (or any other configurable sysctl) and allow to recover quickly or "force delete / empty recycle bin" , rather than delete and give back space immediately for use and destroy possibility to restore. my 2 cents. Sami On Sat, Apr 16, 2022 at 5:23 PM Julian H. Stacey wrote: > > Then I would reboot single user, > > fsck & mount only the partitions the data was Not on., > > dd the partition to recover, > > then fsck the partition & mount it, & go multi user, > > then I'd make a 2nd copy of the partition with data to recover > > Oops. I meant: > > ...... I'd make a 2nd copy (with cp) from the 1st image file, > not of course Not a copy of raw decice partition after fsck > has discarded blocks. > > The spare 2nd. copy because I've zapped data too often, trying to rescue > it, while fumbling with unfamiliar resue tools: its easier to > have a play image one can experimentaly try to recover from, & > periodicaly while one learns, & that gets in a mess, one can refresh > copy from master to experimental copy. > > If any recovery tools want to run on devices, & refuse images in files, use > mdconfig -a -t vnode -f imagefile > > I recall FS has journals etc, > Specalists on list fs@ > > Cheers, > -- > Julian Stacey http://berklix.com/jhs/ http://StolenVotes.UK > Kill / remove Putin to stop him killing & provoking world war. > -- Sami Halabi Information Systems Engineer NMS Projects Expert, FreeBSD SysAdmin Expert Asterisk Expert --0000000000006eafca05dcc6cf36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
okay...
all seems very time consuming opera= tions!!

There should be an os "undelete"= as happens in NTFS for example.. which=C2=A0is very fast and can be done a= lso with extra tools without a hassle.

for now I g= ot backup from last day .. caused me a lot of troubles, not say legal ones,= but I passed the point to hold the machine down.

= any advice?

Maybe UFS developer would do a rework = so latest deleted inodes would put in a "recycle bin" (maybe with= a sysctl or whatever) for say one day (or any other configurable sysctl) a= nd allow to recover quickly or "force delete / empty recycle bin"= , rather=C2=A0than delete and give back space immediately=C2=A0for use and= destroy possibility to restore.

my 2 cents.
=

Sami



On Sat, Apr 16,= 2022 at 5:23 PM Julian H. Stacey <jh= s@berklix.com> wrote:
> Then I would reboot single user,
> fsck & mount only the partitions the data was Not on.,
> dd the partition to recover,
> then fsck the partition & mount it, & go multi user,
> then I'd make a 2nd copy of the partition with data to recover

Oops. I meant:

...... I'd make a 2nd copy (with cp) from the 1st image file,
=C2=A0 =C2=A0 =C2=A0 =C2=A0not of course Not a copy of raw decice partition= after fsck
=C2=A0 =C2=A0 =C2=A0 =C2=A0has discarded blocks.

The spare 2nd. copy because I've zapped data too often, trying to rescu= e
it, while fumbling with unfamiliar resue tools: its easier to
have a play image one can experimentaly try to recover from, &
periodicaly while one learns, & that gets in a mess,=C2=A0 one can refr= esh
copy from master to experimental copy.

If any recovery tools want to run on devices, & refuse images in files,= use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mdconfig -a -t vnode -f imagefile

I recall FS has journals etc,
Specalists on list fs@

Cheers,
--
Julian Stacey=C2=A0 http://berklix.com/jhs/ http://StolenVotes.UK=C2=A0 <= br> Kill / remove Putin to stop him killing & provoking world war.


--
Sami Hala= bi
Information Systems Engineer
NMS Projects Expert,=C2=A0FreeBSD SysAdmin Expert
Aste= risk Expert
--0000000000006eafca05dcc6cf36-- From nobody Sat Apr 16 15:08:17 2022 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 7FF577CA3E6 for ; Sat, 16 Apr 2022 15:08:31 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::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 4Kgc5p2ftVz3hP3 for ; Sat, 16 Apr 2022 15:08:30 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nfk25-000FmV-JW; Sat, 16 Apr 2022 17:08:17 +0200 Date: Sat, 16 Apr 2022 17:08:17 +0200 From: Kurt Jaeger To: Sami Halabi Cc: "Julian H. Stacey" , FreeBSD Current Subject: Re: recover deleted file Message-ID: References: <202204161248.23GCmlIP044778@fire.js.berklix.net> <202204161423.23GENCra046094@fire.js.berklix.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Kgc5p2ftVz3hP3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:14f8:200::1 is neither permitted nor denied by domain of pi@freebsd.org) smtp.mailfrom=pi@freebsd.org X-Spamd-Result: default: False [-2.13 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[pi]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-0.40)[-0.401]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.63)[-0.633]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hi! > Maybe UFS developer would do a rework so latest deleted inodes would put in > a "recycle bin" Use ZFS and snapshots, that should help your use-case. -- pi@opsec.eu +49 171 3101372 Now what ? From nobody Sat Apr 16 15:46:56 2022 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 D41427EE391 for ; Sat, 16 Apr 2022 15:47:09 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgcyN65JMz3qdq for ; Sat, 16 Apr 2022 15:47:05 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: by mail-oi1-x22e.google.com with SMTP id r8so10892248oib.5 for ; Sat, 16 Apr 2022 08:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=X550gt2svAHqXdK1OlGVTaVJl3hPueK3cvU/qS808pI=; b=xtTm/5etw2WWJxs5hzfJqHrUx+Y9P3pGz8nWmDXkazdFEUetYv3+ZBl+sL+j6kb/sm R4Q8MJ69EhuO8+Vwv0/1ubrJD4HgL0GcIdtPyEOCjvA5Y7bH8qIGXuNct3SdjEZalEcZ r7Znxo+mPxmNssWjFXuidsNjRaNjQRvvhYrgxAOgPtWvWs0ROWV8A/h9odGJbwlVUXQE oUgJowPSCD60q9WzH17DoBLgUMwH/Gbfam3UK0ZFuG7kxQH8c4PSVTeW/Ka2FnQp/Z1j ckNtzZt7TbG9RRvK6z9gSUGn3WliYj3h0HxAXlI8nQqF3Lr0Gt6yBCDNqhzfIzxYBT22 lemw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=X550gt2svAHqXdK1OlGVTaVJl3hPueK3cvU/qS808pI=; b=ais+MIJukIV4k+TGqov1wUDV/71llhwJ4KVpa68gi8Uypef3w6eMFboRqXovImwfmX JQsar2BmTC60w8vcF91zx/R9mAeL2k9oryk48zlp4+4OAsgvotWYsnk7kJcqIBgD+uA9 HpwhUgOZriATsvEIs3oW5j9vJ/bX7qxDEQBjlAPBbpM+qkiG8Un1JJ5liJWnBRGxrzrr cRxofIbAVqo6YhEHXLtiRxluCLagmTQhhn/DkzbI2Wa1raWaeiNTT0RNfyS9AXFpycWc xl3Bpf/gOkhEr5D+LYus1SwRb3ATS3ri8pC9OMjFET7+GVem0qUuQzxiXeWcdqHv95B8 xnGQ== X-Gm-Message-State: AOAM533QuTonziH1m70uaV72NAoZhtjJ7IXpigek05PZygMSyw+eaZHG 7dKjqyFcKoRSHwEdDLZxtTzNp3NYfxnp1A== X-Google-Smtp-Source: ABdhPJwvUiirmIXuZ/u8Tb1q7IZfCr7UgyhRGPHvYh/HjkSIL4TFcxtHoG772q8hb1r+gFEOcUposQ== X-Received: by 2002:a54:488a:0:b0:2ec:f48f:8eea with SMTP id r10-20020a54488a000000b002ecf48f8eeamr3595293oic.166.1650124018757; Sat, 16 Apr 2022 08:46:58 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id 64-20020aca0643000000b002f9b8a6ca98sm2213563oig.4.2022.04.16.08.46.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Apr 2022 08:46:58 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-EF26BDCC-F50B-46E4-8B26-1D7A40357380 Content-Transfer-Encoding: 7bit From: Bakul Shah 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 (1.0) Subject: Re: recover deleted file Date: Sat, 16 Apr 2022 08:46:56 -0700 Message-Id: <07AF4B92-2BA2-43AC-8D60-52D299584C14@iitbombay.org> References: Cc: "Julian H. Stacey" , FreeBSD Current In-Reply-To: To: Sami Halabi X-Mailer: iPad Mail (19E258) X-Rspamd-Queue-Id: 4KgcyN65JMz3qdq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=iitbombay-org.20210112.gappssmtp.com header.s=20210112 header.b="xtTm/5et"; dmarc=none; spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2607:f8b0:4864:20::22e as permitted sender) smtp.mailfrom=bakul@iitbombay.org X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[iitbombay-org.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[iitbombay-org.20210112.gappssmtp.com:s=20210112]; FREEFALL_USER(0.00)[bakul]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[iitbombay.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22e:from]; MLMMJ_DEST(0.00)[FreeBSD-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail-EF26BDCC-F50B-46E4-8B26-1D7A40357380 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This may help? I=E2=80=99ve no experience with it, I just googled it for you= . The comp.sources.misc usenet group in volume 17 issue 23 (in 1991) has an u= ndelete program that supposedly works with 4.3BSD =E2=80=94 probably won=E2=80= =99t work with FreeBSD=E2=80=99s version but if you=E2=80=99re desperate it c= ould be a starting point. https://www.ufsexplorer.com/solutions/recover-deleted-files-bsd.php Since you asked for advice, this may just be the nature=E2=80=99s way of tel= ling you you really didn=E2=80=99t need the file. It can be a very =E2=80=9C= free=E2=80=9Ding experience :-) > On Apr 16, 2022, at 8:03 AM, Sami Halabi wrote: >=20 > =EF=BB=BF > okay... > all seems very time consuming operations!! >=20 > There should be an os "undelete" as happens in NTFS for example.. which is= very fast and can be done also with extra tools without a hassle. >=20 > for now I got backup from last day .. caused me a lot of troubles, not say= legal ones, but I passed the point to hold the machine down. >=20 > any advice? >=20 > Maybe UFS developer would do a rework so latest deleted inodes would put i= n a "recycle bin" (maybe with a sysctl or whatever) for say one day (or any o= ther configurable sysctl) and allow to recover quickly or "force delete / em= pty recycle bin" , rather than delete and give back space immediately for us= e and destroy possibility to restore. >=20 > my 2 cents. >=20 > Sami >=20 >=20 >=20 >> On Sat, Apr 16, 2022 at 5:23 PM Julian H. Stacey wrote:= >> > Then I would reboot single user,=20 >> > fsck & mount only the partitions the data was Not on., >> > dd the partition to recover, >> > then fsck the partition & mount it, & go multi user, >> > then I'd make a 2nd copy of the partition with data to recover >>=20 >> Oops. I meant: >>=20 >> ...... I'd make a 2nd copy (with cp) from the 1st image file, >> not of course Not a copy of raw decice partition after fsck >> has discarded blocks. >>=20 >> The spare 2nd. copy because I've zapped data too often, trying to rescue >> it, while fumbling with unfamiliar resue tools: its easier to >> have a play image one can experimentaly try to recover from, & >> periodicaly while one learns, & that gets in a mess, one can refresh >> copy from master to experimental copy. >>=20 >> If any recovery tools want to run on devices, & refuse images in files, u= se >> mdconfig -a -t vnode -f imagefile >>=20 >> I recall FS has journals etc,=20 >> Specalists on list fs@ >>=20 >> Cheers, >> --=20 >> Julian Stacey http://berklix.com/jhs/ http://StolenVotes.UK =20 >> Kill / remove Putin to stop him killing & provoking world war. >=20 >=20 > --=20 > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert --Apple-Mail-EF26BDCC-F50B-46E4-8B26-1D7A40357380 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thi= s may help? I=E2=80=99ve no experience with it, I just googled it for you. T= he comp.sources.misc usenet group in volume 17 issue 23 (in 1991) has an und= elete program that supposedly works with 4.3BSD =E2=80=94 probably won=E2=80= =99t work with FreeBSD=E2=80=99s version but if you=E2=80=99re desperate it c= ould be a starting point.

Since you asked for advice, this may just be the nature= =E2=80=99s way of telling you you really didn=E2=80=99t need the file. It ca= n be a very =E2=80=9Cfree=E2=80=9Ding experience :-)
<= br>
On Apr 16, 2022, at 8:03 AM, Sami Halabi <so= dynet1@gmail.com> wrote:

=EF=BB=BF
okay...
all se= ems very time consuming operations!!

There should b= e an os "undelete" as happens in NTFS for example.. which is very fast a= nd can be done also with extra tools without a hassle.

<= div>for now I got backup from last day .. caused me a lot of troubles, not s= ay legal ones, but I passed the point to hold the machine down.
any advice?

Maybe UFS developer would d= o a rework so latest deleted inodes would put in a "recycle bin" (maybe with= a sysctl or whatever) for say one day (or any other configurable sysctl) an= d allow to recover quickly or "force delete / empty recycle bin" , rather&nb= sp;than delete and give back space immediately for use and destroy poss= ibility to restore.

my 2 cents.

Sami



On Sat, Apr 16, 2022 at 5:23 PM= Julian H. Stacey <jhs@berklix.com= > wrote:
> T= hen I would reboot single user,
> fsck & mount only the partitions the data was Not on.,
> dd the partition to recover,
> then fsck the partition & mount it, & go multi user,
> then I'd make a 2nd copy of the partition with data to recover

Oops. I meant:

...... I'd make a 2nd copy (with cp) from the 1st image file,
       not of course Not a copy of raw decice partition a= fter fsck
       has discarded blocks.

The spare 2nd. copy because I've zapped data too often, trying to rescue
= it, while fumbling with unfamiliar resue tools: its easier to
have a play image one can experimentaly try to recover from, &
periodicaly while one learns, & that gets in a mess,  one can refre= sh
copy from master to experimental copy.

If any recovery tools want to run on devices, & refuse images in files, u= se
        mdconfig -a -t vnode -f imagefile

I recall FS has journals etc,
Specalists on list fs@

Cheers,
--
Julian Stacey  http://berklix.com/jhs/ http://StolenVotes.UK 
= Kill / remove Putin to stop him killing & provoking world war.


--
Sami Halabi<= div>Information Systems Engineer
NMS Projects Expert, FreeBSD SysAdmin Expert
Asterisk E= xpert
= --Apple-Mail-EF26BDCC-F50B-46E4-8B26-1D7A40357380-- From nobody Sat Apr 16 16:25:49 2022 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 8E1AADB81FB for ; Sat, 16 Apr 2022 16:26:11 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgdqQ37ppz4S7V for ; Sat, 16 Apr 2022 16:26:10 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fe6d03e.dip0.t-ipconnect.de [79.230.208.62]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 23GGQ5IW064780 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Apr 2022 18:26:09 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 23GGQ4ph032567; Sat, 16 Apr 2022 18:26:04 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 23GGPn6j049380; Sat, 16 Apr 2022 18:25:59 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202204161625.23GGPn6j049380@fire.js.berklix.net> To: Sami Halabi cc: FreeBSD Current Subject: Re: recover deleted file From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Sat, 16 Apr 2022 18:01:54 +0300." Date: Sat, 16 Apr 2022 18:25:49 +0200 X-Rspamd-Queue-Id: 4KgdqQ37ppz4S7V X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-0.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_HAM_MEDIUM(-0.46)[-0.458]; NEURAL_HAM_LONG(-0.69)[-0.692]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.65)[-0.651]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[79.230.208.62:received] X-ThisMailContainsUnwantedMimeParts: N 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 > okay... > all seems very time consuming operations!! Yes > There should be an os "undelete" as happens in NTFS for example.. which is > very fast and can be done also with extra tools without a hassle. A WIBNI (Wouldnt It Be Nice If) for Unix FS's for as long as I can remember (decades) but no one's ever done it. Ways to get it done: Get it listed as a Google Summer Of Code project for FreeBSD, Or Get your employer to help pay for it, eg chip in with other BSD user companies to pay some money to FreeBSD Foundation, & get them to pay for it to be developed. Or hire are an individual freelance BSD Consultant to do it, There's a global index here http://berklix.com/consultants/ & a mail list that's moderated jobs@freebsd Some author(s) of BSD FFS are on list fs@, Kirk is one name springs to mind ? Some freelancers on fs@ I recall. IMO Would be a fun job if funded :-) > > for now I got backup from last day .. caused me a lot of troubles, not say > legal ones, but I passed the point to hold the machine down. > > any advice? > > Maybe UFS developer would do a rework so latest deleted inodes would put in > a "recycle bin" (maybe with a sysctl or whatever) for say one day (or any > other configurable sysctl) and allow to recover quickly or "force delete / > empty recycle bin" , rather than delete and give back space immediately for > use and destroy possibility to restore. > > my 2 cents. > > Sami Cheers, -- Julian Stacey http://berklix.com/jhs/ http://StolenVotes.UK Kill / remove Putin to stop him killing & provoking world war. From nobody Sat Apr 16 16:53:42 2022 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 5E6D0DBF885 for ; Sat, 16 Apr 2022 16:53:48 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgfRG3gb2z4WxB for ; Sat, 16 Apr 2022 16:53:46 +0000 (UTC) (envelope-from ohauer@gmx.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1650128019; bh=PdcyLIZc7O8tiOeDXyogfkOUeEIkZrD7PDOyOCijEDQ=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=epwuuqwX2999bLv9mMOV6y9+x1cUeM8sAKzksCJiyfjkqGYp4VUvMw9kcAoFGkGBh WBoYqlrg14Y+yjm18oWvpAcOWloTMmKWz2oPSzV6tIhmf/eHHtFqCfwfvKJakSoDmO EJRc894JAHH8Y+fgELRRTfZNwzl8HdnPdUWJPm3M= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.137] ([87.139.233.65]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N7iCg-1o0xd23Y26-014moC; Sat, 16 Apr 2022 18:53:38 +0200 Message-ID: Date: Sat, 16 Apr 2022 18:53:42 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: recover deleted file Content-Language: en-GB To: FreeBSD Current Cc: Sami Halabi References: <202204161625.23GGPn6j049380@fire.js.berklix.net> From: olli hauer In-Reply-To: <202204161625.23GGPn6j049380@fire.js.berklix.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:w3eapoT4PuKRzGR0+XoRKJMgRcHa0cKvSh7E4upoIxLfx7y+pK/ xyqngLWosZ9Low6HMwLVuzPVFe/1yfpN6cOo+IFmgKTCvEdr0oCVq+3C8+g8RbPQ5u8eAXu yyo9cWOfe91HB33n7rUi8sI02pI0xbivvuWsGnrzH9hXSWyUeAS0COmRG5n4bIA0bWd7gxx kkhfT04q0vG6HQQxLL2jw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:w1x+CZSFRJY=:NFfNyDO/h/fbwrSo/SHOwB Gt8VFIr5E6R+9NBFZE4VBta7CFNizkAayk8jjbKlzlwRrJI4u3oGExLOztysdGpD3SbBTkBWs YYna6SXttW6xnxB3UV0PXVuuOhnZUUdEhrU6otH6r/bmvw1s9h40nGFORMLfzhq+PP4/MS04p fH4AK2QUvzzzwGuT/oszr2xqLkb+y/vymxfln7+B2Rsb20s07ExCJ9fN5nNFYwWadFiwDAFJX UGfUFKzZnJoWfZKjWYWMvi+6otlZsbcvCgm/ukkP08EXFjENPwyP06tnDp5JGLbblYSpP77Vl MkEBqo6/57LoddmqOVU7u5s2CpvVe+dVq68H+Kdh2h0t3MsGM/t0tMzNeqReG9Gs/mF6HHmH0 gDxGpItSG1tTlFVUGDVQp2b3yJNz7SnQO7GLAtuT3DIiiOQ4pBALK+G96s3Bmn7KH2tiu93L0 fqQJQHoNygmlCRcp1wlR6w0N7vs26JGqxCSLypAd/6S8/d1FUV1FYFW411S/MyZIFIUjP517q 90kZ8VIf9UWSA1brnyAij0fZ2e5aUxEn0mfmTK72OTaf8eTaMMXiR9e8Kzm89M2m2iQf5WM25 9IOjvaI7SJfJasS2GjnxUWJtRCPyw5jQGUS/TBYPrIPV5qF+huN5t/iCCBfsGMV5a3gOVq302 aaalZu+9rRTLEHfdwdIpvxQwcygi/NM/HwQbeH5e4Tl1YPpXqu/rp+1gwmmELsl/HA6ErFdkS GbJpqYr+3z59y/cYeb6hrBMJZ2+KNDcTy531c0EEBx8Xj9yMljYByTPxi8UCMS8uogvqoUACU oEvaXK3O6CEHBZcwUi3LBLwhhD6e6Bu91pe6V5gt0oTaF+z54XrjZcr+HXRnSapH5sCB2IMaH o+op8Fp49fflMBb7S8AiaJjikmk3JQbplapOntveYC5E7TC/wbmkN+vc2Pp2KBRJn2l2X4I4w QwWkayp3JdKkgRUyCVbsW5w76a7u8lxH6G1Bk9BcXNMLZe6R7Hdnc33HgczE67RDPKyROTEXt SYL7Mwa0f6ipabGA7uJqHa57YxO5iXqVk1C+8ZzzvMScy5sYZfImQF0gUz9cvdU6gjplP/zeD FXThZR+Ats9s/M= X-Rspamd-Queue-Id: 4KgfRG3gb2z4WxB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=epwuuqwX; dmarc=pass (policy=none) header.from=gmx.de; spf=pass (mx1.freebsd.org: domain of ohauer@gmx.de designates 212.227.17.21 as permitted sender) smtp.mailfrom=ohauer@gmx.de X-Spamd-Result: default: False [-4.17 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmx.de]; R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmx.de,none]; NEURAL_HAM_SHORT(-0.07)[-0.075]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.21:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmx.de]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; FREEFALL_USER(0.00)[ohauer]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[gmx.net:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_VERYGOOD(0.00)[212.227.17.21:from]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > Hi, > is there anyway easy to restore deleted file by accident in UFS???? depends, years ago i had to use sysutils/testdisk to restore files from UFS after a HD crash. Using the tools was easy but finding the right data in all the files the tool restored can be time consuming. -- Good luck olli From nobody Sat Apr 16 17:35:00 2022 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 045675D31DC; Sat, 16 Apr 2022 17:35:20 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KggMC0F8nz4glq; Sat, 16 Apr 2022 17:35:19 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-qk1-x72f.google.com with SMTP id e10so8654836qka.6; Sat, 16 Apr 2022 10:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HP5PasgGQbzzrashq1dEqKENbn43mG5cgWA0aDrFJvo=; b=eNObM+EqTfUbvxxCgT3UtYDRILEbjTf42NH6zWNu+XnjydOXgrwzKa/LN8F0U7nSD2 ozg1/AaFwzfyYudE1GLsIl+MS0fTycd39DKXdMFHAK9U9lo5B0ETEaEYW+FyjzNG+qn2 wRkMlYsE1LDHXOH3KDhAZASmybKeybvJ9aE7NeGuqyby63yoiyqHcCCyjCpWGwVlt6Ow Y51R3w4917ULNtc/BlRqCrinXJ2gFigBb8JCUEizUWDx3yYrBbOPDqn98bZCDYoNapP1 mbF2zwDZiv8xcwAT4a0LTibbE2nnRLjRVzoEhIeHEl8ar1U5Wz2bKZIMgGk1YIOYBpkg 2/dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HP5PasgGQbzzrashq1dEqKENbn43mG5cgWA0aDrFJvo=; b=1Elc5+vhuifCIhSTW6mlVN67floUk2A3TColiRkEcfjKqrmM+uFKYi9+xdp8LqnObC Z+pV3fG/5+4lQmFj+hD5KF3xK3sa5RPp5SwczRFPOUkFHVUZ0zjK0urLbxR3Z9S6EIsc pEkvgW2b9SPDLUbgfifWC79iCdHAyvcZYmbaR1bp8Q46Q8Rn0uE9GElVjKCx0J3cY4Fh DPhnlqloZnnMgwBum39ZWYJDAVFlwauojyDjtc8Iu/f6ZuWC+OVQgp7rB+gunaIJjguZ JXjbJTIyEWtjPUchvA+d+49+8p/T14Uzhekib7lwteNOZ9xRgXes5LaoVwlfo59WPVyd nxHg== X-Gm-Message-State: AOAM533DT43WwoJbIhiAPCOQpgCYRJmu5EKpTP/bVxmYdnWZ2q4Zydxd /Hv2gGObj1Wp45OnAGokLhYM2kjetAdRMgrIdS8= X-Google-Smtp-Source: ABdhPJxNJfRPaHbgrCvCd0HGhLq3MOw7pzHIuvO7H4oYXIMMGjgBL51fJnHBMavGcnUqXcldoZ6m1Sb63o4Rb23OaI0= X-Received: by 2002:a05:620a:2586:b0:680:f3c1:9d4a with SMTP id x6-20020a05620a258600b00680f3c19d4amr2496105qko.619.1650130511303; Sat, 16 Apr 2022 10:35:11 -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: <202204161625.23GGPn6j049380@fire.js.berklix.net> In-Reply-To: <202204161625.23GGPn6j049380@fire.js.berklix.net> From: Sami Halabi Date: Sat, 16 Apr 2022 20:35:00 +0300 Message-ID: Subject: Re: recover deleted file To: "Julian H. Stacey" , freebsd-fs@freebsd.org Cc: FreeBSD Current , mckusick@mckusick.com Content-Type: multipart/alternative; boundary="000000000000f5978305dcc8f272" X-Rspamd-Queue-Id: 4KggMC0F8nz4glq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=eNObM+Eq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sodynet1@gmail.com designates 2607:f8b0:4864:20::72f as permitted sender) smtp.mailfrom=sodynet1@gmail.com X-Spamd-Result: default: False [-2.15 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(0.85)[0.845]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72f:from]; NEURAL_HAM_SHORT(-0.99)[-0.994]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000f5978305dcc8f272 Content-Type: text/plain; charset="UTF-8" Hi, thanks for your response. Would someone from the foundation step in and put it in GSOC ideas? kirk@ - would it be possible for you to do it ? :) Sami On Sat, Apr 16, 2022 at 7:26 PM Julian H. Stacey wrote: > > okay... > > all seems very time consuming operations!! > > Yes > > > There should be an os "undelete" as happens in NTFS for example.. which > is > > very fast and can be done also with extra tools without a hassle. > > A WIBNI (Wouldnt It Be Nice If) for Unix FS's for as long as I can remember > (decades) but no one's ever done it. > > Ways to get it done: > Get it listed as a Google Summer Of Code project for FreeBSD, Or > > Get your employer to help pay for it, eg chip in with other BSD > user companies to pay some money to FreeBSD Foundation, & get > them to pay for it to be developed. > > Or hire are an individual freelance BSD Consultant to do it, > There's a global index here http://berklix.com/consultants/ > > & a mail list that's moderated jobs@freebsd > > Some author(s) of BSD FFS are on list fs@, Kirk is one name springs > to mind ? Some freelancers on fs@ I recall. > > IMO Would be a fun job if funded :-) > > > > > for now I got backup from last day .. caused me a lot of troubles, not > say > > legal ones, but I passed the point to hold the machine down. > > > > any advice? > > > > Maybe UFS developer would do a rework so latest deleted inodes would put > in > > a "recycle bin" (maybe with a sysctl or whatever) for say one day (or any > > other configurable sysctl) and allow to recover quickly or "force delete > / > > empty recycle bin" , rather than delete and give back space immediately > for > > use and destroy possibility to restore. > > > > my 2 cents. > > > > Sami > > Cheers, > -- > Julian Stacey http://berklix.com/jhs/ http://StolenVotes.UK > Kill / remove Putin to stop him killing & provoking world war. > -- Sami Halabi Information Systems Engineer NMS Projects Expert, FreeBSD SysAdmin Expert Asterisk Expert --000000000000f5978305dcc8f272 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
thanks for your response.

Would someone from the foundation step in and put it in GSOC ideas?
<= div>
kirk@ - would it be possible for you to do it ? :)
=

Sami


On Sat, Apr 16, 2022 at 7:26 P= M Julian H. Stacey <jhs@berklix.com> wrote:
&g= t; okay...
> all seems very time consuming operations!!

Yes

> There should be an os "undelete" as happens in NTFS for exam= ple.. which is
> very fast and can be done also with extra tools without a hassle.

A WIBNI (Wouldnt It Be Nice If) for Unix FS's for as long as I can reme= mber
(decades) but no one's ever done it.

Ways to get it done:
=C2=A0 Get it listed as a Google Summer Of Code project for FreeBSD, Or

=C2=A0 Get your employer to help pay for it, eg chip in with other BSD
=C2=A0 user companies to pay some money to FreeBSD Foundation, & get =C2=A0 them to pay for it to be developed.

=C2=A0 Or hire are an individual freelance BSD Consultant to do it,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 There's a global index here http://be= rklix.com/consultants/

=C2=A0 & a mail list that's moderated jobs@freebsd

=C2=A0 Some author(s) of BSD FFS are on list fs@, Kirk is one name springs<= br> =C2=A0 to mind ? Some freelancers on fs@ I recall.

=C2=A0 IMO Would be a fun job if funded :-)

>
> for now I got backup from last day .. caused me a lot of troubles, not= say
> legal ones, but I passed the point to hold the machine down.
>
> any advice?
>
> Maybe UFS developer would do a rework so latest deleted inodes would p= ut in
> a "recycle bin" (maybe with a sysctl or whatever) for say on= e day (or any
> other configurable sysctl) and allow to recover quickly or "force= delete /
> empty recycle bin" , rather than delete and give back space immed= iately for
> use and destroy possibility to restore.
>
> my 2 cents.
>
> Sami

Cheers,
--
Julian Stacey=C2=A0 http://berklix.com/jhs/ http://StolenVotes.UK=C2=A0 <= br> Kill / remove Putin to stop him killing & provoking world war.


--
Sami Hala= bi
Information Systems Engineer
NMS Projects Expert,=C2=A0FreeBSD SysAdmin Expert
Aste= risk Expert
--000000000000f5978305dcc8f272-- From nobody Sat Apr 16 17:40:58 2022 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 B79E85D576E; Sat, 16 Apr 2022 17:41:11 +0000 (UTC) (envelope-from kevans@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KggTz4jVwz4jsQ; Sat, 16 Apr 2022 17:41:11 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650130871; 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=XsCroXMuIiJZlntanAJGYBKpRDzhh0TGHnbcy7sIVXk=; b=Vd+rZJ5HmDy0zKvNk9MlsIs3wcNuRRjhlZatY/hqtOXsa4+g+VqB2ZwlQ4X5EAU2OFubDW cdhixDlZF/FOwGbubqUMKNBhhXgVG+8kKR1mDuQ8eKS2nVtzwuU2lIGiddAriuNwfkbQBk xAA05z30hadyQZBRiVVOst/XoCVm2ivXfq6ynQe/Cv2T0qzotD8dnsBfP9vcyKnxYVa7+A Rmp2ncoh57tgXnTr1h94/EXzc0k1u6IDBFU70AM4Dx4Ay+9/B+vnQznm0TW/xYYZSRIuuF kvhDj/uFpKQ+/4mLcAwhvkwIMdTV0s9ksce2+JZUQ5UfnpCdDl2RLj6MSmKM4A== Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 7C27C5152; Sat, 16 Apr 2022 17:41:11 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f51.google.com with SMTP id u19so18489582lff.4; Sat, 16 Apr 2022 10:41:11 -0700 (PDT) X-Gm-Message-State: AOAM5318J1CwuVqYezxIK/ywSmGAuq6VQFG2WBdhdu98c1fzKwUn0QUC da0b09loeDySToAQ8QWFm70G9XY9ymcrlKMA8ao= X-Google-Smtp-Source: ABdhPJw4h4aRK5P+vgpLgLODNpyuGR1vob7Rvw1C8LcfLsGVYOqA6vmaOHMCfXLW4B+NiziF7g0GA83wQC49KQlOL9I= X-Received: by 2002:a19:7b17:0:b0:46e:cb82:fe24 with SMTP id w23-20020a197b17000000b0046ecb82fe24mr2934276lfc.194.1650130869930; Sat, 16 Apr 2022 10:41:09 -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: <202204161625.23GGPn6j049380@fire.js.berklix.net> In-Reply-To: From: Kyle Evans Date: Sat, 16 Apr 2022 12:40:58 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: recover deleted file To: Sami Halabi Cc: "Julian H. Stacey" , freebsd-fs , FreeBSD Current , Kirk McKusick Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650130871; 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=XsCroXMuIiJZlntanAJGYBKpRDzhh0TGHnbcy7sIVXk=; b=a5NtZba45eDyk3fsefuqgIt28a2rwH2SSdBqNVzGSUJaKTbfAvWqEDN3Wmoy44Sg0kdVOP CYrYmTqwrzrRLDVJE4xmCzNfJ1pCHpdLM7xToyTYC/B6WGx8HVZoDYOU1ShWwAnNBNG3MT /CDDJGhnxHpks8nUo8fFPNvALCre4lOx+Ojr1X050KxK8PftCS1MEH852o92Qkjd61r+5L XVozASUBBWStwzeZS60E3Ef+pG1aYZ2CAuZTlfEW3ZUyyAks9p44G5Xs4to78LLXPjtyFI vB4MdsPWKKCHm3qdQvuxcxhkHwWXyUT+Ym7Luqzq1r5b9ljNBCZOxtCt+kQDtQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650130871; a=rsa-sha256; cv=none; b=fE7Lfq84ht5SbC4a56Uakc6QAVlBdotiO4McihYfrsghxbY0W/7y20OvELrjNVhGPqER7X OxQRLz3pzEbd+YHFktVj1K0tnxlRN20PATMqSPFRUkSxUlu8rPOHSxTnvEEHjhc4TKPF33 8oUVJDjpKzKewAP9H/XrRsG0Eg0e+TLEafetz9kxvttw6w3crR1uR5Aizypcub6liBO7Ap S3bkA9HUUcXhbAb4TySdT5YbY13JgZvXVKPBR5SdB2lUwaJoVc8a37iUFuy/Tz1Ev62zGh HQHwRd/aj9aZcJey0FeJzxFaLgPwURzngrC9i7ii1SNFGBHTZaVUONi1NEjGEQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sat, Apr 16, 2022 at 12:36 PM Sami Halabi wrote: > > Hi, > thanks for your response. > > Would someone from the foundation step in and put it in GSOC ideas? > > kirk@ - would it be possible for you to do it ? :) > Anyone with wiki access is able to add ideas, any student eligible for GSoC is able to propose ideas (regardless of whether we've pitched the ideas on our wiki or not). Thanks, Kyle Evans > > On Sat, Apr 16, 2022 at 7:26 PM Julian H. Stacey wrote: >> >> > okay... >> > all seems very time consuming operations!! >> >> Yes >> >> > There should be an os "undelete" as happens in NTFS for example.. which is >> > very fast and can be done also with extra tools without a hassle. >> >> A WIBNI (Wouldnt It Be Nice If) for Unix FS's for as long as I can remember >> (decades) but no one's ever done it. >> >> Ways to get it done: >> Get it listed as a Google Summer Of Code project for FreeBSD, Or >> >> Get your employer to help pay for it, eg chip in with other BSD >> user companies to pay some money to FreeBSD Foundation, & get >> them to pay for it to be developed. >> >> Or hire are an individual freelance BSD Consultant to do it, >> There's a global index here http://berklix.com/consultants/ >> >> & a mail list that's moderated jobs@freebsd >> >> Some author(s) of BSD FFS are on list fs@, Kirk is one name springs >> to mind ? Some freelancers on fs@ I recall. >> >> IMO Would be a fun job if funded :-) >> >> > >> > for now I got backup from last day .. caused me a lot of troubles, not say >> > legal ones, but I passed the point to hold the machine down. >> > >> > any advice? >> > >> > Maybe UFS developer would do a rework so latest deleted inodes would put in >> > a "recycle bin" (maybe with a sysctl or whatever) for say one day (or any >> > other configurable sysctl) and allow to recover quickly or "force delete / >> > empty recycle bin" , rather than delete and give back space immediately for >> > use and destroy possibility to restore. >> > >> > my 2 cents. >> > >> > Sami >> >> Cheers, >> -- >> Julian Stacey http://berklix.com/jhs/ http://StolenVotes.UK >> Kill / remove Putin to stop him killing & provoking world war. > > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert From nobody Sat Apr 16 19:07:42 2022 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 64D9EEAB169 for ; Sat, 16 Apr 2022 19:08:00 +0000 (UTC) (envelope-from weldon@excelsus.com) Received: from senna.excelsus.com (senna.excelsus.com [96.79.137.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgjQ66xtzz3CWW for ; Sat, 16 Apr 2022 19:07:58 +0000 (UTC) (envelope-from weldon@excelsus.com) Received: from localhost (localhost [127.0.0.1]) by senna.excelsus.com (Postfix) with ESMTP id F246CEAD6 for ; Sat, 16 Apr 2022 14:07:51 -0500 (CDT) Received: from senna.excelsus.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (maiad, port 10024) with ESMTP id 78153-03 for ; Sat, 16 Apr 2022 14:07:44 -0500 (CDT) Received: from smtpclient.apple (249.sub-174-212-160.myvzw.com [174.212.160.249]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: weldon@excelsusphoto.com) by senna.excelsus.com (Postfix) with ESMTPSA id 8E3F3EA63; Sat, 16 Apr 2022 14:07:44 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Weldon Godfrey 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 (1.0) Subject: Re: recover deleted file Date: Sat, 16 Apr 2022 15:07:42 -0400 Message-Id: References: <202204161625.23GGPn6j049380@fire.js.berklix.net> Cc: Sami Halabi , FreeBSD Current In-Reply-To: <202204161625.23GGPn6j049380@fire.js.berklix.net> To: "Julian H. Stacey" X-Mailer: iPhone Mail (19D52) X-Virus-Scanned: Maia Mailguard 1.0.4 X-Rspamd-Queue-Id: 4KgjQ66xtzz3CWW X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of weldon@excelsus.com has no SPF policy when checking 96.79.137.12) smtp.mailfrom=weldon@excelsus.com X-Spamd-Result: default: False [2.31 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[excelsus.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.908]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:96.64.0.0/11, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[174.212.160.249:received] X-ThisMailContainsUnwantedMimeParts: N > On Apr 16, 2022, at 12:27 PM, Julian H. Stacey wrote: >=20 > =EF=BB=BF >>=20 >> okay... >> all seems very time consuming operations!! >=20 > Yes >=20 >> There should be an os "undelete" as happens in NTFS for example.. which i= s >> very fast and can be done also with extra tools without a hassle. >=20 > A WIBNI (Wouldnt It Be Nice If) for Unix FS's for as long as I can remembe= r > (decades) but no one's ever done it.=20 >=20 > Ways to get it done: > Get it listed as a Google Summer Of Code project for FreeBSD, Or >=20 > Get your employer to help pay for it, eg chip in with other BSD > user companies to pay some money to FreeBSD Foundation, & get > them to pay for it to be developed. >=20 > Or hire are an individual freelance BSD Consultant to do it, > There's a global index here http://berklix.com/consultants/ >=20 > & a mail list that's moderated jobs@freebsd >=20 > Some author(s) of BSD FFS are on list fs@, Kirk is one name springs > to mind ? Some freelancers on fs@ I recall. >=20 > IMO Would be a fun job if funded :-) >=20 >>=20 >> for now I got backup from last day .. caused me a lot of troubles, not sa= y >> legal ones, but I passed the point to hold the machine down. >>=20 >> any advice? >>=20 >> Maybe UFS developer would do a rework so latest deleted inodes would put i= n >> a "recycle bin" (maybe with a sysctl or whatever) for say one day (or any= >> other configurable sysctl) and allow to recover quickly or "force delete /= >> empty recycle bin" , rather than delete and give back space immediately f= or >> use and destroy possibility to restore. >>=20 >> my 2 cents. >>=20 >> Sami >=20 >=20 or just use ZFS filesystem and leverage regular snapshots. I wrote a scrip= t that manages snapshots (moves to weekly, monthly and deletes snaps) but i b= elieve there is a utility in the ports collection that will do the automated= management.=20 >=20 From nobody Sat Apr 16 21:05:14 2022 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 DAFCECFD5FE for ; Sat, 16 Apr 2022 21:05:24 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kgm1b72v0z3Qfb for ; Sat, 16 Apr 2022 21:05:23 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id w4so14362825wrg.12 for ; Sat, 16 Apr 2022 14:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=w2w9YrU/PESDLtut5/qIkwwsqbsnEbhLfRn9M6bd+ug=; b=qm18JRAsMZ0BMOcnpDuEkI9Po/11+vFfUP/0+IdrIAkukPuz8YmskE0WRQyTMNNaGo 6ow5ViYge/RnJVWl5ou+DGXahVceBJBHEmcBQrVskjbuhdSk76OZMajHQhpR6tE6/xeW JKPyZg+nhI4BZu6cLh/INqYoyqqiyG7MV+HAzj4aW5RbTXHoHGwyB6iCylJLanTPEhUH qRERW8f4OgGy3Ojlj4tIGvSN9+7xIiB7rV5KCx767+PgTQdXT2gxmTYKBtpA2hGwphQd yjvYQ4qtTv2bqfTMBdmDZYx3shg/TXXhNB6Uoz0aBOVz0H+6z3XQDCr9bz3x3oQ8atOI /AmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=w2w9YrU/PESDLtut5/qIkwwsqbsnEbhLfRn9M6bd+ug=; b=qrvxAQ8uVLD4BGFCd56py10FVcDJYgow0RWaP/1RTCR+P/qqgxcUQNvU1p92ysC8bI /I6JJMMZ7LeK7YMeDUOOB1DwhjAMoTBKycSeWU+HgcTi5butkaUDrmjHZI8vltKP0E/p 5H6g29dislRb2AocPuWMb01+uxJZRT637+b1xSVG8mSNVDflkUWzL9eHACdXjZAakK4X WYaffifEqD12cq3kvFx5nYgZv1za4gG55sxPILCowzLRhWpm1M1uQTJ2hhRq/+bhfKlL 2Kc4uZszHWnFp/M75rSe07/aSxfomQmg7LcRdJBBeP5JCfZWHMUX6boFtIewaxgILxc0 jCKQ== X-Gm-Message-State: AOAM533VLXYlPjoXT77b6iqkgEGEhx3Ij5RYjsGYHb+3VgJLriWT4L2x HSBCgoohKw1qDYxlqahvAgYA/NlLigQ= X-Google-Smtp-Source: ABdhPJzV3HuM4mzC387PUJRZMMO2xduAR8hR7yNPe3k3Lrcg6R4Hhb1e84qOfa1WqhXhmKJJSiP26A== X-Received: by 2002:adf:9129:0:b0:207:b1e3:4b66 with SMTP id j38-20020adf9129000000b00207b1e34b66mr3293539wrj.608.1650143116393; Sat, 16 Apr 2022 14:05:16 -0700 (PDT) Received: from smtpclient.apple ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id k124-20020a1ca182000000b0038eb706c030sm11628256wme.39.2022.04.16.14.05.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Apr 2022 14:05:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: =?utf-8?Q?S=C3=B8ren_Schmidt?= 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 (1.0) Subject: Re: recover deleted file Date: Sat, 16 Apr 2022 23:05:14 +0200 Message-Id: References: Cc: "Julian H. Stacey" , Sami Halabi , FreeBSD Current In-Reply-To: To: Weldon Godfrey X-Mailer: iPhone Mail (19E258) X-Rspamd-Queue-Id: 4Kgm1b72v0z3Qfb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=qm18JRAs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::431 as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Spamd-Result: default: False [-2.66 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_MIXED_CHARSET(0.83)[subject]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_CC(0.00)[berklix.com,gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Just replace rm with a script that moves files to a trash folder, then eithe= r clean that automagically after some period of time or handle it manually. Doesn=E2=80=99t have to be complicated=E2=80=A6 -S=C3=B8ren > On 16 Apr 2022, at 21.08, Weldon Godfrey wrote: >=20 > =EF=BB=BF >=20 >> On Apr 16, 2022, at 12:27 PM, Julian H. Stacey wrote: >>=20 >> =EF=BB=BF >>>=20 >>> okay... >>> all seems very time consuming operations!! >>=20 >> Yes >>=20 >>> There should be an os "undelete" as happens in NTFS for example.. which i= s >>> very fast and can be done also with extra tools without a hassle. >>=20 >> A WIBNI (Wouldnt It Be Nice If) for Unix FS's for as long as I can rememb= er >> (decades) but no one's ever done it.=20 >>=20 >> Ways to get it done: >> Get it listed as a Google Summer Of Code project for FreeBSD, Or >>=20 >> Get your employer to help pay for it, eg chip in with other BSD >> user companies to pay some money to FreeBSD Foundation, & get >> them to pay for it to be developed. >>=20 >> Or hire are an individual freelance BSD Consultant to do it, >> There's a global index here http://berklix.com/consultants/ >>=20 >> & a mail list that's moderated jobs@freebsd >>=20 >> Some author(s) of BSD FFS are on list fs@, Kirk is one name springs >> to mind ? Some freelancers on fs@ I recall. >>=20 >> IMO Would be a fun job if funded :-) >>=20 >>>=20 >>> for now I got backup from last day .. caused me a lot of troubles, not s= ay >>> legal ones, but I passed the point to hold the machine down. >>>=20 >>> any advice? >>>=20 >>> Maybe UFS developer would do a rework so latest deleted inodes would put= in >>> a "recycle bin" (maybe with a sysctl or whatever) for say one day (or an= y >>> other configurable sysctl) and allow to recover quickly or "force delete= / >>> empty recycle bin" , rather than delete and give back space immediately f= or >>> use and destroy possibility to restore. >>>=20 >>> my 2 cents. >>>=20 >>> Sami >>=20 >>=20 >=20 > or just use ZFS filesystem and leverage regular snapshots. I wrote a scr= ipt that manages snapshots (moves to weekly, monthly and deletes snaps) but i= believe there is a utility in the ports collection that will do the automat= ed management.=20 >=20 >=20 >>=20 >=20 From nobody Sat Apr 16 21:42:04 2022 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 E9529F7E834 for ; Sat, 16 Apr 2022 21:42:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kgmr81kx4z3m04 for ; Sat, 16 Apr 2022 21:42:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2d.google.com with SMTP id 190so3862529vse.8 for ; Sat, 16 Apr 2022 14:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=beENDYFEDXWoZwKvyPF1IUjYLra4iUj31+VaKqrMHcg=; b=yomFsdE3QBpH18t+R5gIOSYxfNEf2Rjbk1qswFSqoa+sSnosbIWhpQXeyhHl+br/pc EdkQb0AyLYrpPglnrNnYFQ9Y4Xo/KGk58mou/tXRyxbIQDQKOmG7BzmmLG08bM9pcQDf NRTcbNuf1pX/ByJ//sIr6npUOmfH9MDcNcBUvfXSsD3MkXGA7k4u9gHJAlfoYFg9frfM gqooVhbZ3xCdhs19sf23Xcx5hRq7zuD8T9pIOY5XyjlmS2uS6GcxZvnIzxtOjE5cu+JH oNchJ5JCAb1GH6Aqcmcu2jSdeWROaTbYi341dwzZ0QNh5UaAe5zuqq6cF6JWRbNBxJYs u5bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=beENDYFEDXWoZwKvyPF1IUjYLra4iUj31+VaKqrMHcg=; b=UArgfjJsWxrYaOL5IuCFZWUSMtOBjxuAqVuKjvu2Z29eCqGJk+oB+1Z0yXvTd1RMGy 1tLjC9HQwUG3lnrbS/hkKQAfLfealL73b2DreLsKe27toxvyYak9t0HK5PphbGouRkf7 pUvWrzVDnGTNus0IF663aCnPMrJgit0qJqO/snwQkFRG8LpSkC+m5imjiJBtQ6bmkbBP wgdd4K64uvDbtDBdM4OOzIJIB5zUnZxwCOQ20b70u6n9wlbVPuEw4dFgDVJ7ar9VALUM YMBgddTQ1iZRljdM7Oeaj0uNxlHhyilzfdvVq4oo5/fKmgbu5e4Ral5WgsIYXaSf2u3B zE4g== X-Gm-Message-State: AOAM533iCk3eBNLTmNLzrmxzZeqI4/YNDtSFL9lk2oG+d8oH7ipT+SBj 1EcUX0QhjpE4xTQQ3/jZSgDblfrAf1q8zzWg7TVrpw== X-Google-Smtp-Source: ABdhPJxUFozU9FGmfoeobhOX2oMhXbWQhI0Gm4+RQH+cL/DU/NTSXK+/WJ0V+BkzKwkOGY2MYnf3gNF8XPVH5vcDeJk= X-Received: by 2002:a05:6102:38e:b0:32a:5175:b45d with SMTP id m14-20020a056102038e00b0032a5175b45dmr56774vsq.44.1650145335539; Sat, 16 Apr 2022 14:42:15 -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: Sat, 16 Apr 2022 15:42:04 -0600 Message-ID: Subject: Re: recover deleted file To: Sami Halabi Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000008d8bf305dccc661d" X-Rspamd-Queue-Id: 4Kgmr81kx4z3m04 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=yomFsdE3; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.99 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.993]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2d:from]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --0000000000008d8bf305dccc661d Content-Type: text/plain; charset="UTF-8" On Sat, Apr 16, 2022 at 5:24 AM Sami Halabi wrote: > Hi, > is there anyway easy to restore deleted file by accident in UFS???? > Do you know what the contents of the file is? At least the first, say, ~32k? The problem with unrm for ufs is that the directory entry has the inode number stored in it. Without the inode number, you won't get very far. With the inode number, you can get the first 12 filesystem blocks of the file and the first three indirect blocks. Once you have those, you can reconstruct the file. But only if the inode hasn't been zero'd out (which it likely has, another thing that makes UFS undelete harder). But all hope isn't lost... UFS has a predictable allocation algorithm that lets you get much of the file back (which is why I asked if you know how it should start: you can find where it starts in the data blocks and maybe get lucky with the rest if the data spills into indirect blocks). However, that's only if you don't have TRIM enabled on the filesystem. If you do, then UFS will do a BIO_DELETE of the blocks, which means their contents are likely gone at the drive level. I say likely because there's weasel words in the ATA spec that allows a drive to return the prior contents of the blocks, or all zeros or the drive's initialization pattern (usually all 1's) when the blocks are later read. Same goes for NVMe drives (with the additional constraint it must be deterministic). So there's may still be a chance you can read the old contents, but drives that do that are rare in my experience (which is admittedly quite narrow). But, if you want to use fsdb to try to recover this data, or write your own tools, then you should likely have a copy of the daemon book (The Design and Implementation of the FreeBSD Operating System). It explains a lot of the finer details of UFS and reference to it likely will catch me where my memory isn't quite right in the above descriptions. So, it's for all these reasons you can't find somebody with a unrm command for ufs like you can for DOS or other filesystems. I wish I had a better answer for you. Warner > Sami > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert > --0000000000008d8bf305dccc661d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Apr 16, 2022 at 5:24 AM Sami = Halabi <sodynet1@gmail.com>= wrote:
Hi,
is there anyway easy to restore deleted file by accident i= n UFS????

Do you know what the = contents of the file is? At least the first, say, ~32k?

The problem with unrm for ufs is that the directory entry has the ino= de number stored in it.
Without the inode number, you won't g= et very far.
With the inode number, you can get the first 12 file= system blocks of the file and the
first three indirect blocks. On= ce you have those, you can reconstruct the file.

B= ut only if the inode hasn't been zero'd out (which it likely has, a= nother thing that makes
UFS undelete harder). But all hope isn= 9;t lost...=C2=A0 UFS has a predictable allocation algorithm
that= lets you get much of the file back (which is why I asked if you know how i= t should start:
you can find where it starts in the data blocks a= nd maybe get lucky with the rest if the
data spills into indirect= blocks).

However, that's only if you don'= t have TRIM enabled on the filesystem. If you do,
then UFS will d= o a BIO_DELETE of the blocks, which means their contents are
like= ly gone at the drive level. I say likely because there's weasel words i= n the ATA
spec that allows a drive to return the prior contents o= f the blocks, or all zeros or
the drive's initialization patt= ern (usually all 1's) when the blocks are later read. Same
go= es for NVMe drives (with the additional constraint it must be deterministic= ). So there's
may still be a chance you can read the old cont= ents, but drives that do that are rare
in my experience (which is= admittedly quite narrow).

But, if you want to use= fsdb to try to recover this data, or write your own tools,
then = you should likely have a copy of the daemon book (The Design and Implementa= tion
of the FreeBSD Operating System). It explains a lot of the f= iner details of UFS and
reference to it likely will catch me wher= e my memory isn't quite right in the above
descriptions.

So, it's for all these reasons you can't find = somebody with a unrm command for ufs
like you can for DOS or othe= r filesystems. I wish I had a better answer for you.

Warner
=C2=A0
Sami

--
Sami Halabi
Infor= mation Systems Engineer
NMS Projects Expert,=C2=A0FreeBSD SysAdmin Expert
Asterisk Expert<= /div>
--0000000000008d8bf305dccc661d-- From nobody Sat Apr 16 22:13:02 2022 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 0D68411CDE89 for ; Sat, 16 Apr 2022 22:13:21 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgnX02zNLz3rJK for ; Sat, 16 Apr 2022 22:13:20 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: by mail-qk1-x732.google.com with SMTP id s4so8971883qkh.0 for ; Sat, 16 Apr 2022 15:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+0Za3+nd4f+SGj83R/Qoq+DwceS1EZSftK3YgP3+txc=; b=QDBd+qttT+Bfr7tOvhrfczMKh1bepfrPkhSdljKii/VpULJXnoygg6mNR5iITiiPgD zk8E8tUwaAFxaCVBrFFC2ZU3hwKgHU2f8TRVQ/NRxz7wXpw+us2vXuF7E5ARKs+422fg joVRCqG6hc9WYap1ZriQjbs11HyeG7/6uoQPctii35ki611yqDcP7DDDQZc5CyvWdPpX 6/zed/1bgQoOtLFYA90QJUQsBZeFEWV/BMTigegBMAqd0haxCIqCrmjK6cfZfMsxawMV 9e9EhmsSd/A4ui30j7scVfxP7lLWS0WCrq6Dh7bQ9E9N1OIioZENr8amkwV04dgXHjBT z7vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+0Za3+nd4f+SGj83R/Qoq+DwceS1EZSftK3YgP3+txc=; b=DaI7jP6jpriIj/iNCD4sVnTYvsQoaNZwShMSsf5HYRI7feLbqdc31WNeNSqDrQTY2H 4tv5P9Jf3So3z0VRX0zGrPvYOijGmIQrjpmFYGhNPob5YchZ4kN4298ixcayadYk87d/ p5CvH/wD2eEDxWiFPlSP4Q66RNxsn+g0hlsAzbGexxwf6l7fHTJi3f7LQxe4xAb8RXF8 CAQFray7XlXCKkoPPU4LPNKRymNFOW7gRn6MkJa02KUINj32igbf1Q59fAOSTS+51dNi scMS5uB6OhlL08sDl+h1A705zCzFfT7vuF+mfd3p+eb2gSfCydbVwGQXlGdEHzDaaPvf RoiA== X-Gm-Message-State: AOAM532UmIbeViZ8rZsSoBfoJ/tP6M3HifRVHWzCf+MV+aJBFKvujmSI 6yf2RXLckphZ9VFNXyfJntRtwjPYXmK3InOuvMWrqYWi X-Google-Smtp-Source: ABdhPJzxTUojoYvzMGkNKLDgBxL+1UF4GKoRvaVM9t0YV0OBGNlpB/WLl32OMfX51w6RJd4zttunUqwg89rfQy4fCuA= X-Received: by 2002:a05:620a:2a12:b0:69c:5ab9:a08d with SMTP id o18-20020a05620a2a1200b0069c5ab9a08dmr3000160qkp.326.1650147194134; Sat, 16 Apr 2022 15:13:14 -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: Sami Halabi Date: Sun, 17 Apr 2022 01:13:02 +0300 Message-ID: Subject: Re: recover deleted file To: Warner Losh Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000055623b05dcccd574" X-Rspamd-Queue-Id: 4KgnX02zNLz3rJK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=QDBd+qtt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sodynet1@gmail.com designates 2607:f8b0:4864:20::732 as permitted sender) smtp.mailfrom=sodynet1@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::732:from]; NEURAL_HAM_SHORT(-0.99)[-0.995]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000055623b05dcccd574 Content-Type: text/plain; charset="UTF-8" Hi warner, Thanks for trying :) Actually my use case was (if you read later replies, i gave up since the downtime was too long and couldn't wait more) a VM in ESXi. so all the underlying stuff of the disks/TRIM.. is hidden an inaccessible for me (hosting provider). In my case I tried to recover MariaDB database files, and some tar.gz file of backups of the db that I accidentally deleted all together (mysql* instead of mysql/* , my bad, deleted mysql/ & mysql_backups!!). I stopped all services immediately, so maybe I would succeed if I wasn't time limited. I understand its hard to undelete since no one designed UFS/ZFS to do so.. that why I asked in later replies to see if someone would step in and implement such a "feature" and I suggested some directions/thoughts. As soren@ suggested in later reply it maybe would be easier to implement custom rm script that moves files to "Recycle bin" directory (and empty it after some period) but as a programmer I know that perfection is needed :) so It might start as a simple task and end in many what-if's (unfortunattly I did my last C programming in late 2003!). What amzes me is that this "feature" was asked too much in the last decade or two and no one ever implemented it, maybe it's not needed in daily usage, but in disasters it would be super userful, save admins many time and nerves.. For now I did some backup tools locally and used chflags to mark them undeletable so I wouldn't do that mistake again, plus I rsync them to my home storage.. so probably I would be more resilent to such mistakes in the future.. but the same problem remains.. accidently deleted file(s)/directory(s) are the nightmare of all admins in earth!! Sami On Sun, Apr 17, 2022 at 12:42 AM Warner Losh wrote: > > > On Sat, Apr 16, 2022 at 5:24 AM Sami Halabi wrote: > >> Hi, >> is there anyway easy to restore deleted file by accident in UFS???? >> > > Do you know what the contents of the file is? At least the first, say, > ~32k? > > The problem with unrm for ufs is that the directory entry has the inode > number stored in it. > Without the inode number, you won't get very far. > With the inode number, you can get the first 12 filesystem blocks of the > file and the > first three indirect blocks. Once you have those, you can reconstruct the > file. > > But only if the inode hasn't been zero'd out (which it likely has, another > thing that makes > UFS undelete harder). But all hope isn't lost... UFS has a predictable > allocation algorithm > that lets you get much of the file back (which is why I asked if you know > how it should start: > you can find where it starts in the data blocks and maybe get lucky with > the rest if the > data spills into indirect blocks). > > However, that's only if you don't have TRIM enabled on the filesystem. If > you do, > then UFS will do a BIO_DELETE of the blocks, which means their contents are > likely gone at the drive level. I say likely because there's weasel words > in the ATA > spec that allows a drive to return the prior contents of the blocks, or > all zeros or > the drive's initialization pattern (usually all 1's) when the blocks are > later read. Same > goes for NVMe drives (with the additional constraint it must be > deterministic). So there's > may still be a chance you can read the old contents, but drives that do > that are rare > in my experience (which is admittedly quite narrow). > > But, if you want to use fsdb to try to recover this data, or write your > own tools, > then you should likely have a copy of the daemon book (The Design and > Implementation > of the FreeBSD Operating System). It explains a lot of the finer details > of UFS and > reference to it likely will catch me where my memory isn't quite right in > the above > descriptions. > > So, it's for all these reasons you can't find somebody with a unrm command > for ufs > like you can for DOS or other filesystems. I wish I had a better answer > for you. > > Warner > > >> Sami >> >> -- >> Sami Halabi >> Information Systems Engineer >> NMS Projects Expert, FreeBSD SysAdmin Expert >> Asterisk Expert >> > -- Sami Halabi Information Systems Engineer NMS Projects Expert, FreeBSD SysAdmin Expert Asterisk Expert --00000000000055623b05dcccd574 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi warner,
Thanks for trying :)

Actually my use case was (if you read later replies, i gave up since the= downtime was too long and couldn't wait more) a VM in ESXi.
= so all the underlying stuff of the disks/TRIM.. is hidden an inaccessible= =C2=A0for me (hosting provider).

In my case I trie= d to recover MariaDB database files, and some tar.gz file of backups of the= db that I accidentally=C2=A0deleted all=C2=A0together (mysql* instead of m= ysql/*=C2=A0 , my bad, deleted mysql/ & mysql_backups!!). I stopped all= services immediately, so maybe I would succeed if I wasn't time limite= d.

I understand=C2=A0its hard to undelete since no= one designed UFS/ZFS to do so.. that why I asked in later replies to see i= f someone would step in and implement such a "feature" and I sugg= ested=C2=A0some directions/thoughts.

As soren@ sug= gested in=C2=A0later reply it maybe would be easier to implement custom rm = script that moves files to "Recycle bin" directory (and empty it = after some period) but as a programmer I know that perfection is needed :) = so It might start as a simple task and end in many what-if's (unfortuna= ttly=C2=A0I did my last C programming in late=C2=A02003!).

What amzes me is that this "feature" was asked too much = in the last decade or two and no one ever implemented it, maybe it's no= t needed in daily usage, but in disasters it would be super userful, save a= dmins many time and nerves..

For now I did some ba= ckup tools locally and used chflags to mark them undeletable so I wouldn= 9;t do that mistake again, plus I rsync them to my home storage.. so probab= ly I would be more resilent=C2=A0to such mistakes in the future.. but the s= ame problem remains.. accidently deleted file(s)/directory(s) are the night= mare of all admins=C2=A0in earth!!

Sami

On Su= n, Apr 17, 2022 at 12:42 AM Warner Losh <imp@bsdimp.com> wrote:


On Sat, Apr 16, 2022= at 5:24 AM Sami Halabi <sodynet1@gmail.com> wrote:
Hi,
is there anyway easy to= restore deleted file by accident in UFS????
<= br>
Do you know what the contents of the file is? At least the fi= rst, say, ~32k?

The problem with unrm for ufs is t= hat the directory entry has the inode number stored in it.
Withou= t the inode number, you won't get very far.
With the inode nu= mber, you can get the first 12 filesystem blocks of the file and the
<= div>first three indirect blocks. Once you have those, you can reconstruct t= he file.

But only if the inode hasn't been zer= o'd out (which it likely has, another thing that makes
UFS un= delete harder). But all hope isn't lost...=C2=A0 UFS has a predictable = allocation algorithm
that lets you get much of the file back (whi= ch is why I asked if you know how it should start:
you can find w= here it starts in the data blocks and maybe get lucky with the rest if the<= /div>
data spills into indirect blocks).

Howev= er, that's only if you don't have TRIM enabled on the filesystem. I= f you do,
then UFS will do a BIO_DELETE of the blocks, which mean= s their contents are
likely gone at the drive level. I say likely= because there's weasel words in the ATA
spec that allows a d= rive to return the prior contents of the blocks, or all zeros or
= the drive's initialization pattern (usually all 1's) when the block= s are later read. Same
goes for NVMe drives (with the additional = constraint it must be deterministic). So there's
may still be= a chance you can read the old contents, but drives that do that are rare
in my experience (which is admittedly quite narrow).
But, if you want to use fsdb to try to recover this data, or wr= ite your own tools,
then you should likely have a copy of the dae= mon book (The Design and Implementation
of the FreeBSD Operating = System). It explains a lot of the finer details of UFS and
refere= nce to it likely will catch me where my memory isn't quite right in the= above
descriptions.

So, it's for al= l these reasons you can't find somebody with a unrm command for ufs
like you can for DOS or other filesystems. I wish I had a better ans= wer for you.

Warner
=C2=A0
Sami

--
Sami Halabi
Information Systems Engineer
NMS Pr= ojects Expert,=C2=A0FreeBSD SysAdmin Exper= t
Asterisk Expert


--
Sami Hala= bi
Information Systems Engineer
NMS Projects Expert,=C2=A0FreeBSD SysAdmin Expert
Aste= risk Expert
--00000000000055623b05dcccd574-- From nobody Sun Apr 17 00:29:54 2022 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 1E92DCFFD34; Sun, 17 Apr 2022 00:30:04 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4KgrYl2vXQz4Ynv; Sun, 17 Apr 2022 00:30:03 +0000 (UTC) (envelope-from jamie@catflap.org) X-Catflap-Envelope-From: X-Catflap-Envelope-To: freebsd-current@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 23H0TtdR047310; Sun, 17 Apr 2022 01:29:55 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 23H0Tsr4047309; Sun, 17 Apr 2022 01:29:54 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202204170029.23H0Tsr4047309@donotpassgo.dyslexicfish.net> Date: Sun, 17 Apr 2022 01:29:54 +0100 Organization: Dyslexic Fish To: sodynet1@gmail.com, jhs@berklix.com, freebsd-fs@FreeBSD.org Cc: mckusick@mckusick.com, freebsd-current@FreeBSD.org Subject: Re: recover deleted file References: <202204161625.23GGPn6j049380@fire.js.berklix.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sun, 17 Apr 2022 01:29:55 +0100 (BST) X-Rspamd-Queue-Id: 4KgrYl2vXQz4Ynv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-1.51 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_FIVE(0.00)[5]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.81)[-0.805]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-fs]; FREEMAIL_TO(0.00)[gmail.com,berklix.com,FreeBSD.org]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Sami Halabi wrote: > Hi, > thanks for your response. > > Would someone from the foundation step in and put it in GSOC ideas? > > kirk@ - would it be possible for you to do it ? :) > How would you handle file modifications? Backup every original too, or just deal with literal deletions? If you are just concerned with user accidental deletions, you can easily modify your view of "rm" to point to something that instead stores the file somewhere safe.. Jamie From nobody Sun Apr 17 04:13:07 2022 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 AA99B11D0AB7 for ; Sun, 17 Apr 2022 04:13:14 +0000 (UTC) (envelope-from peterj@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgxWG2306z3Kvt; Sun, 17 Apr 2022 04:13:14 +0000 (UTC) (envelope-from peterj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650168794; 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=1CCil5IJOdmiGxutW7EOOAcTHO2d7NrLtPrKguNk2Gg=; b=G1zPJssYHvmQ88lckioat9LcvnGmDH7K1nOzgkAWiI5N7JaMjsggnBjOBFtBylV8yNtf/M vl3qpDDU07a1pAc1wsyEp792qdlNfUDmcs5jieLNEzJ3Dfx+ft9JqeTth8zpfIkIX1KCIY wgCplS65AZ5nwQSasbuZhgc9ygxrBebzq6DKHGOrSRDFtbiAVYv+4+MCctsRdzda/LU9gd OERUN5K26XwJk4srwxtIkWGNoX6uBYboxjRbGopr4f+sF3m2tVHr8/PcCqiTHZ12F6hs82 wH+Tt0Xnno2U9CSJH9vacOBPGzpHxaReB9uh2DYi2GoLzPQfhAmBuQ/mJsI19g== Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id 37E55A934; Sun, 17 Apr 2022 04:13:12 +0000 (UTC) (envelope-from peterj@freebsd.org) Date: Sun, 17 Apr 2022 14:13:07 +1000 From: Peter Jeremy To: Sami Halabi Cc: FreeBSD Current Subject: Re: recover deleted file 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="omXB7HJ7cySNH9NA" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650168794; 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=1CCil5IJOdmiGxutW7EOOAcTHO2d7NrLtPrKguNk2Gg=; b=QJffk4jni5N2/eLgqT+bOzn4K91Al/citQ6B/LVGMumoKpIr2XPlIMV85pldu2PBacgXmI RjUnhP5lbUSomYTncJNL6ZZSCE+BcJWlODo5BS+bQCfd5bEAUMhY9nFrxXJcNjJ/sPB3n4 BuEIGmuaJbfvp+6LYqdLzOh94AfYcLB9NSI54K99gIhbCfepSBJUMuppkkhjQhFlVlDWYo RouZjTbUcVOyTfe2rgJczuFGA6bj4Hm9P4ukWNryBTJ5wh0VPlfDtaLpGB2Rjp1KVU87Bk fcO/IoUtGCtcfaH9JWB0gQB1yTkqauSYbBOaTlRCbr21q9heZyXbVe+k9as4qA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650168794; a=rsa-sha256; cv=none; b=oG8unwPwyOzqZSdG/jX89y1OGc9cxHA5nR6J67wVuANIbBwRX+jA8mcwFWdo3PJ973YV63 u3H2T6hQKHPU/jOFgcBLLvCOK8M3m9C7oOLeiUyWd9dVDOJpIkrk04YVPbhWEdA2gdeSR0 Y+YvM3n9C502TnpU4uUAVD2hKfHMfFxYXQkTH2xgR9IxAW9JbXHIMFzdfyV680vubl2R0E UkcwKiomEqqOpkKnrBmqLkYcnXxNYiNv1E/gZRze4bKxym6wGMeKO39VJzcqgyD/R03Qsk 9/bB/nFiEmCoFIBzF+2dOCmp95nO6zFWJLimozIZGp6P+HMI40McEMObxECS/g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --omXB7HJ7cySNH9NA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2022-Apr-17 01:13:02 +0300, Sami Halabi wrote: >I understand its hard to undelete since no one designed UFS/ZFS to do so.. >that why I asked in later replies to see if someone would step in and >implement such a "feature" and I suggested some directions/thoughts. As you point out, neither UFS nor ZFS were designed to support an "undelete" function: Once an inode has no references (open files or directory entries), the inode and all associated data blocks are returned to the free list and could be used by a subsequent allocation. What semantics would you like UFS or ZFS to implement instead? Is it just that the inode and associated data blocks should stay in limbo for some period? If, what controls the period? What if a file is truncated to 0 or overwritten before being unlinked? How much would you be willing to pay for "undelete" functionality? >As soren@ suggested in later reply it maybe would be easier to implement >custom rm script that moves files to "Recycle bin" directory (and empty it >after some period) Alternatively, you could alias "rm" to "rm -i". >but as a programmer I know that perfection is needed :) >so It might start as a simple task and end in many what-if's >(unfortunattly I did my last C programming in late 2003!). This doesn't need to be C. You could do this in your scripting language of choice. Or you could offer to pay someone to do this for you. >What amzes me is that this "feature" was asked too much in the last decade >or two and no one ever implemented it, maybe it's not needed in daily >usage, but in disasters it would be super userful, save admins many time >and nerves.. I went rummaging back through my mail archives and it actually doesn't seem to come up that often. You seem to be about the 3rd person this century on the lists I read. I did find a discussion in zfs-discuss =66rom May/June 2006 about supporting undelete but it seems that no agreement on the desired behaviour was achieved. >For now I did some backup tools locally and used chflags to mark them >undeletable so I wouldn't do that mistake again, You could also consider snapshots - both UFS and ZFS support snapshots. If the information is very critical (you mentioned legal consequences) then you might like to consider real-time replication of the MySQL redo logs to another systems - though that won't necessarily protect you =66rom someone accidently doing a "DELETE FROM xxx;" or "DROP TABLE xxx;" --=20 Peter Jeremy --omXB7HJ7cySNH9NA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmJbk8hfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzS6Lw//RlB1FQSz5/4bt0Z82lMstg9nGtA9JbWTpS9fX1J0mfYQdFzpy0Zv2PIE 3eYGQfBQP1j9qPNgaAasSkW3xpppd/AkDaJvnw8qM4zA6CYesrT9jwjfMnH6p1wI CPVd9DtBZcDbxmSIY/dvFaUUNO8HouR0GR8vtjcihgtjNT/zQ4E93Hz+M0ut4CSz YjsVe5e9hB678JPFHZsynjLnxOlB2G4s8aKZ33KEmdGtTdg3cI5qDx1US68LwNpv VESnKU879F7kSa8j6tY6nRyA/BXH0Hw4g+bnyFf6Pg5Nzwsrf7Cj4LGBUjHpaXZj faXdJtV1y1dXggWrqqWlJ7sQcdQUEi6epnx4PPNlll5/ZwqejQAftbklD27HT3Nz LnCXR5YbVGsKQ0KV/VbHGddhCYx0cfvy0F3oukOIE+TjL8kj6R28++L2HqOond1M dECNHleTqzZDbYN1urgu1QDpVbkar9jzqO9DmWFJAuRzd9FAwCOC0QrtnsDdumyP dtErpdqr3O+t/YOdW40NwHDEdN5QbHgLxcmdAtUsKUl0Oqbb4YUiTaSU+kqTPCF4 VNr8NcU5iMw4LgVJM1B+jimLZB5zDTUo4/DcrGh/mOEC7VFcjRoKzuluqhtNaCdl B6crGesRwG4hwFVMdoohJ9sQWwbQShE7koK7nFPdMcScMZoN6/c= =EuXT -----END PGP SIGNATURE----- --omXB7HJ7cySNH9NA-- From nobody Sun Apr 17 06:32:24 2022 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 54299CFF71C for ; Sun, 17 Apr 2022 06:32:24 +0000 (UTC) (envelope-from pstef@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kh0br1zDfz3r41; Sun, 17 Apr 2022 06:32:24 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650177144; 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=kiP5vH+Gm5j0hxSuXbZYb/gtoc5OZ9RAPxq9yJaL4HE=; b=pATouP++Pf8uhQpjZUuwuZkl6TAnsTaxg2OYZKzAkGj1seA1AfBlLgzgEIAGlNyQ8djPCm BEs3fROqH+f9DFDvK3qDuk+GSE6qYfIy6/UORoIkQvCFI6Xz7LvOJjC1gGjGE6eSc67feh faThXpD9QWltBJ38cuG+NERvmvzsUrt7ehsnbc5ZNu+UxRbnj6mt79QXClsKVSCJnJagKE YL2hdWxOpxCU1sFVuXfuqxkuy4NzcyLQWOiTcz2Jqw3FEzRjI+5OAvOsKgOv/f2/Et5KTq p9z44EufbDjRJgEarsmd74elP8fN+uUp0jgZj7J3QyPAx38UlnlEY94VuNeI7A== Received: by freefall.freebsd.org (Postfix, from userid 1403) id 2BFDE19C17; Sun, 17 Apr 2022 06:32:24 +0000 (UTC) Date: Sun, 17 Apr 2022 06:32:24 +0000 From: "Piotr P. Stefaniak" To: Peter Jeremy Cc: Sami Halabi , FreeBSD Current Subject: Re: recover deleted file 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; format=flowed Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650177144; 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=kiP5vH+Gm5j0hxSuXbZYb/gtoc5OZ9RAPxq9yJaL4HE=; b=HZ7ODchShoUWLlDhzKDf5X2SAaB4P9/YcNGgFOU3C3vCBCNlKHx+9KzgTky98O5a1o6kjP w4C2PklvAArbAtoH4na9pZ+DZuGt+ImwfCyyNy1ehnQbwebaBNpT0s8IktU9HwTojeZoPZ EhjXoX0agoLhkn/u/mavAwLgV0wjHwukntYtpM7ovQcOt8SbDER8JqsR160rFnx8ugN9GE MVXn8nloXlkDXKIrJkmN6Av/dQCEsgiMOJC4gieJ0tcdwE+wf5vGNulvjPAMmfSdJ6/KL8 GVc01ZxMFDCsS3eXR4pPwd0x4rSm7Xibfy/J/eIvLLoLwtoiPaiOv6QEsijshg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650177144; a=rsa-sha256; cv=none; b=LXy566n1xGY2lOhhnDiVp/7SPDFfaiSvxPzphU0aRy5xeDzv4MNxl1vi3o0t1hsNR4aqHl riC4AT4P7JJfgAwum9JZnZZtg5KRcVDyKN9jfzpIOBZAG3L9JR6bUp7kCWZdYoeP1dNHlR nlhxq9akOba2YaA9RGPs+W4t4kFRcJBDnHtxgSDrEdziiQhpIH713x06uR8gmLy47L9L8n pHh85ZmWaE1VvxDz3kWIKMi3j6F49IOBw0n8kaXFBNl9OAbWc0fiNCiqoSPQLc8Na4MYEa Ky/LsPy9TWoyu3cC8VfGhDc9dE50T5KbSf+f2z7pVG6CETn5oSMg4SH1ciWShQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 2022-04-17 14:13:07, Peter Jeremy wrote: >If the information is very critical (you mentioned legal consequences) >then you might like to consider real-time replication of the MySQL redo >logs to another systems - though that won't necessarily protect you >from someone accidently doing a "DELETE FROM xxx;" or "DROP TABLE xxx;" It won't, but if it's a delayed replica, you have some time to recover the data. Piotr From nobody Sun Apr 17 10:42:48 2022 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 704F511DAEC2 for ; Sun, 17 Apr 2022 10:42:53 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kh68r3mvCz4mLn; Sun, 17 Apr 2022 10:42:52 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id e996cce7; Sun, 17 Apr 2022 10:42:50 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id c310bdbd (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Sun, 17 Apr 2022 10:42:49 +0000 (UTC) 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 (1.0) Subject: Re: recover deleted file From: Michael Gmelin In-Reply-To: Date: Sun, 17 Apr 2022 12:42:48 +0200 Cc: Sami Halabi , FreeBSD Current Message-Id: References: To: Peter Jeremy X-Mailer: iPhone Mail (19D52) X-Rspamd-Queue-Id: 4Kh68r3mvCz4mLn X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [1.40 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 17. Apr 2022, at 06:20, Peter Jeremy wrote: >=20 > =EF=BB=BFOn 2022-Apr-17 01:13:02 +0300, Sami Halabi w= rote: >> I understand its hard to undelete since no one designed UFS/ZFS to do so.= . >> that why I asked in later replies to see if someone would step in and >> implement such a "feature" and I suggested some directions/thoughts. >=20 > As you point out, neither UFS nor ZFS were designed to support an > "undelete" function: Once an inode has no references (open files > or directory entries), the inode and all associated data blocks are > returned to the free list and could be used by a subsequent allocation. >=20 > What semantics would you like UFS or ZFS to implement instead? Is it > just that the inode and associated data blocks should stay in limbo > for some period? If, what controls the period? What if a file is > truncated to 0 or overwritten before being unlinked? How much would > you be willing to pay for "undelete" functionality? >=20 >> As soren@ suggested in later reply it maybe would be easier to implement >> custom rm script that moves files to "Recycle bin" directory (and empty i= t >> after some period) >=20 > Alternatively, you could alias "rm" to "rm -i". >=20 >> but as a programmer I know that perfection is needed :) >> so It might start as a simple task and end in many what-if's >> (unfortunattly I did my last C programming in late 2003!). >=20 > This doesn't need to be C. You could do this in your scripting > language of choice. Or you could offer to pay someone to do this > for you. >=20 >> What amzes me is that this "feature" was asked too much in the last decad= e >> or two and no one ever implemented it, maybe it's not needed in daily >> usage, but in disasters it would be super userful, save admins many time >> and nerves.. >=20 > I went rummaging back through my mail archives and it actually doesn't > seem to come up that often. You seem to be about the 3rd person this > century on the lists I read. I did find a discussion in zfs-discuss > from May/June 2006 about supporting undelete but it seems that no > agreement on the desired behaviour was achieved. >=20 >> For now I did some backup tools locally and used chflags to mark them >> undeletable so I wouldn't do that mistake again, >=20 > You could also consider snapshots - both UFS and ZFS support snapshots. >=20 > If the information is very critical (you mentioned legal consequences) > then you might like to consider real-time replication of the MySQL redo > logs to another systems - though that won't necessarily protect you > from someone accidently doing a "DELETE FROM xxx;" or "DROP TABLE xxx; It will, if you keep the binary logs/replication logs around. Combined with r= egular zfs snapshots (on the replicant=E2=80=98s side) you can do a robust a= nd relatively speedy point in time recovery that prevents data loss (ideally= , access to the main db and the replicant is segregated). Saved me more than= once. Best Michael From nobody Sun Apr 17 11:04:37 2022 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 EDEE211DFDE0 for ; Sun, 17 Apr 2022 11:04:51 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [85.220.129.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kh6fB5KK8z4q18 for ; Sun, 17 Apr 2022 11:04:50 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 5876410A1E85 for ; Sun, 17 Apr 2022 13:04:43 +0200 (CEST) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 3503410A1E8A for ; Sun, 17 Apr 2022 13:04:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1650193479; 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=N1/gchyGJ9Q7Al/mi9Q7yKw80zfCmCkfouC6SJjt2M8=; b=lUe8AR6Jf9YWzK1BYRsZLOdk2LnBE7NACpW1SDt0l+7MlpkTXhNfOMvApTQhNKIW31DLFc X3HU+b8udtfaWcAwmSvQuoDCL514RTWO3AriD91+0uAv0RRznV/FHA0lQiYvTwKM2XcgKo wThSC0R5SAwiuKIkt9z2JrGpN4Gd3FtdstKV7xYP6f5MS9nMecKC999sJQ48LcuheP1e+L CETFSQW12/QxgFE+b7QOyxZmNRUCgG6xfcMWAfKsGogmizhJpdqmOmOOkFs76wJpkk9UjX 6Nd4cFK8OCBTkLKx5RmEsKvqy0K8U/5pAd80NzdXWbsjfHOF4yp8EtvfbyykbA== Received: from hermann (dynamic-2a01-0c22-adcc-5900-e4f3-b483-6b4a-c139.c22.pool.telefonica.de [IPv6:2a01:c22:adcc:5900:e4f3:b483:6b4a:c139]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id ED27F10A1E89 for ; Sun, 17 Apr 2022 13:04:38 +0200 (CEST) Date: Sun, 17 Apr 2022 13:04:37 +0200 From: FreeBSD User To: FreeBSD CURRENT Subject: PAM: SSH: reject login when homdir does not exist? Message-ID: <20220417130437.740721de@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 0c22e4 X-Rspamd-UID: b38d4d X-Rspamd-Queue-Id: 4Kh6fB5KK8z4q18 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=lUe8AR6J; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.30) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [2.11 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.988]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt-de.de]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_NOT_FQDN(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_SPAM_SHORT(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.30:from] X-ThisMailContainsUnwantedMimeParts: N Hello fellows, happy Easter! I run into a security issue this morning here and tried to look for a solution. We use OpenLDAP for all "regular users" login on hosts and web services. Authentication is required from some cloud/moodle services via LDAP, but some users not having any homedirectory on any machine within the domain will still be allowed to login, even if the home dir is not present. They get loged in onto the root of the filesystem, when login via SSH. Is there a way to prohibit login if homedir isn't present? Can you point me to the right place (PAM or something, pam_env isn't available on FreeBSD)? If this is a trivial issue and caused by lack of my personell knowledge, please excuse. Kind regards, O. Hartmann From nobody Sun Apr 17 11:21:49 2022 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 126CF5D4534 for ; Sun, 17 Apr 2022 11:22:01 +0000 (UTC) (envelope-from contact@evilham.com) Received: from yggdrasil.evilham.com (yggdrasil.evilham.com [46.19.33.155]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kh7200nVMz4sk5 for ; Sun, 17 Apr 2022 11:22:00 +0000 (UTC) (envelope-from contact@evilham.com) From: Evilham DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=evilham.com; s=mail; t=1650194512; bh=qOAX2ZnnlhbPPLHILJZc49GWhmuELMN077xL1gyEPpc=; h=From:To:Cc:Subject:References:In-reply-to:Date; b=peHyMt/APCSA1SOnsJDT4M4nnKvWGGBM749uedrpFM01YuPcDeO4eTMEyVg9eG3y/ zQhjqQy0iWfnKKoR0yqqOCP6S6ivLyBYBPdoz1heqZvgXrL0sGpedHLzNtwNLjvSKQ W2LV3RDHsLRYW9dCyBDbhA1UxFyxHge6a2m5Yyts= To: FreeBSD User Cc: freebsd-current@freebsd.org Subject: Re: PAM: SSH: reject login when homdir does not exist? References: <20220417130437.740721de@hermann> In-reply-to: <20220417130437.740721de@hermann> Date: Sun, 17 Apr 2022 13:21:49 +0200 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; format=flowed X-Rspamd-Queue-Id: 4Kh7200nVMz4sk5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=evilham.com header.s=mail header.b="peHyMt/A"; dmarc=pass (policy=quarantine) header.from=evilham.com; spf=pass (mx1.freebsd.org: domain of contact@evilham.com designates 46.19.33.155 as permitted sender) smtp.mailfrom=contact@evilham.com X-Spamd-Result: default: False [-0.90 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[evilham.com:s=mail]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[evilham.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[evilham.com,quarantine]; NEURAL_HAM_SHORT(-0.90)[-0.901]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:196752, ipnet:46.19.32.0/21, country:NL] X-ThisMailContainsUnwantedMimeParts: N On dg., abr. 17 2022, FreeBSD User wrote: > Hello fellows, happy Easter! > > I run into a security issue this morning here and tried to look > for a solution. We use > OpenLDAP for all "regular users" login on hosts and web > services. Authentication is > required from some cloud/moodle services via LDAP, but some > users not having any > homedirectory on any machine within the domain will still be > allowed to login, even if > the home dir is not present. They get loged in onto the root of > the filesystem, when > login via SSH. > > Is there a way to prohibit login if homedir isn't present? Can > you point me to the right > place (PAM or something, pam_env isn't available on FreeBSD)? > > If this is a trivial issue and caused by lack of my personell > knowledge, please excuse. > > Kind regards, Hey, even if you manage to do that, you probably shouldn't address your problem this way: existence of a directory is a rather weak assertion to make when deciding whether or not someone should be able to get a shell. Take a look at AllowGroups and AllowUsers in man 5 sshd_config, that should fit your use-case much better. Other than that, you probably want to change their shell and stuff like that. Do check: https://docs.freebsd.org/en/books/handbook/security/#security-intro And adapt to your LDAP setup. Also, mid-term this M.W. Lucas' Absolute FreeBSD is a really good place to learn things: https://mwl.io/nonfiction/os#af3e PS: This mailing list is for things related to FreeBSD-CURRENT; it seems like this question might be a better fit for freebsd-questions@, since it is related to systems in general. Cheers, -- Evilham From nobody Mon Apr 18 14:45:54 2022 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 9E25511D9E4C for ; Mon, 18 Apr 2022 14:46:01 +0000 (UTC) (envelope-from 010001803d2320dd-11563fc8-755d-40fb-8634-cdaee0ad8669-000000@amazonses.com) Received: from a48-89.smtp-out.amazonses.com (a48-89.smtp-out.amazonses.com [54.240.48.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KhqVw75JQz4cqN for ; Mon, 18 Apr 2022 14:46:00 +0000 (UTC) (envelope-from 010001803d2320dd-11563fc8-755d-40fb-8634-cdaee0ad8669-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1650293154; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=wqjVrjXlv5Asd1M5vw18sLHf3TPJAHiiMEpE87/TIOE=; b=iFt0Bmz43E689Jg4l/PCm2Va4GHMj+7qpKzvNg6WYrfKI1L7NxMFLvA0sYrBxruP YF/FR03Wtr0x6twcbYwsHKInkODTYVmbJRQkPpFnGloBbWl4LB3tLuQRx6o2EmIc/Ap I4fn+40zING+ht3/QmD+lL2u5t1zsq5gL3trzU18= Message-ID: <010001803d2320dd-11563fc8-755d-40fb-8634-cdaee0ad8669-000000@email.amazonses.com> Date: Mon, 18 Apr 2022 14:45:54 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <093ec3cb-32a1-e316-a369-3a9e8559248a@blastwave.org> <0100018022a47721-e6e3ac23-8639-4b94-b3ae-eae4bcfd5493-000000@email.amazonses.com> From: Thomas Laus In-Reply-To: <0100018022a47721-e6e3ac23-8639-4b94-b3ae-eae4bcfd5493-000000@email.amazonses.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES X-SES-Outgoing: 2022.04.18-54.240.48.89 X-Rspamd-Queue-Id: 4KhqVw75JQz4cqN X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=iFt0Bmz4; dmarc=none; spf=pass (mx1.freebsd.org: domain of 010001803d2320dd-11563fc8-755d-40fb-8634-cdaee0ad8669-000000@amazonses.com designates 54.240.48.89 as permitted sender) smtp.mailfrom=010001803d2320dd-11563fc8-755d-40fb-8634-cdaee0ad8669-000000@amazonses.com X-Spamd-Result: default: False [2.50 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[acm.org]; NEURAL_SPAM_MEDIUM(0.98)[0.984]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.76)[-0.759]; DKIM_TRACE(0.00)[amazonses.com:+]; NEURAL_HAM_SHORT(-0.03)[-0.027]; RCVD_IN_DNSWL_NONE(0.00)[54.240.48.89:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[lausts@acm.org,010001803d2320dd-11563fc8-755d-40fb-8634-cdaee0ad8669-000000@amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[54.240.48.89:from]; ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,010001803d2320dd-11563fc8-755d-40fb-8634-cdaee0ad8669-000000@amazonses.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 4/13/22 07:17, Thomas Laus wrote: >> > I had an idea that maybe a GELI encrypted disk may have an issue.  Both > my laptop and desktop have encrypted disks.  The gpart partitions have a > .efi appended to the name that 'gpart list' shows.  Not everyone uses > GELI and that may be our difference and the reason for not finding any > pools to import. > Well, it looks like EFI may be the root cause of my problem. I built and loaded: 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n254879-47bcbde91de: Mon Apr 18 08:18:48 EDT 2022 Today for both my laptop and desktop. I gave up last week with the 'git revert' exercise and just waited a week since my last build. The problem with not finding any zfs pools still existed. Both computers can boot from either EFI or MBR, so I copied the gptzfsboot file to the EFI partition and everything came up OK on both computers. That eliminates any issue with ZFS and GELI encrypted disks in my case. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From nobody Mon Apr 18 19:23:11 2022 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 4E61D11DB291 for ; Mon, 18 Apr 2022 19:23:22 +0000 (UTC) (envelope-from filis+fbsdcurrent@filis.org) Received: from smtp1.nkhosting.net (smtp1.nkhosting.net [84.200.40.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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Khxfx3lW7z4Yb7 for ; Mon, 18 Apr 2022 19:23:21 +0000 (UTC) (envelope-from filis+fbsdcurrent@filis.org) Received: from [IPV6:2a01:170:1170:54:aaa1:59ff:fe9a:3960] (unknown [IPv6:2a01:170:1170:54:aaa1:59ff:fe9a:3960]) by smtp1.nkhosting.net (Postfix) with ESMTPSA id 9F9D3269F4 for ; Mon, 18 Apr 2022 21:23:12 +0200 (CEST) Message-ID: <0c1b4885-dd0f-b48f-2ffe-12ccfd2ec118@filis.org> Date: Mon, 18 Apr 2022 21:23:11 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: freebsd-current@FreeBSD.org Content-Language: en-US From: filis+fbsdcurrent@filis.org Subject: -CURRENT hangs since at least 2022-04-04 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Khxfx3lW7z4Yb7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of filis@filis.org does not designate 84.200.40.83 as permitted sender) smtp.mailfrom=filis@filis.org X-Spamd-Result: default: False [-2.10 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all:c]; FREEFALL_USER(0.00)[filis]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-current]; DMARC_NA(0.00)[filis.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44066, ipnet:84.200.0.0/16, country:DE]; TAGGED_FROM(0.00)[fbsdcurrent]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hi, I'm running -CURRENT on this one desktop box which is a "Ryzen 7 4800U with Radeon Graphics", since it didn't work on 13R. I use Boot environments and on 2022-04-04 I updated it and it started to completely freeze under X (I haven't tried letting it run without X) after a few dozen minutes. I went on vacation and came back today and updated it again to see if the issue went away, but it froze again. I went back to the latest BE before 2022-04-04, which is from 2022-03-21 and so far it works fine again. I use a different machine to build and then rsync /usr/src and /usr/obj over and run make installworld, etc locally and also pkg upgrade (I use FreeBSD -latest packages) everything, so I can't quite tell if this is related to base or drm-kmod and I'm not too familiar with changes in the timeframe between 2022-03-21 and 2022-04-04 that would affect my setup. Is there anything I can try and/or find or collect info to shed more light on this? Cheers, filis From nobody Mon Apr 18 19:32:48 2022 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 4F04311DF6E4 for ; Mon, 18 Apr 2022 19:32:58 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Khxt134Jnz4d7T for ; Mon, 18 Apr 2022 19:32:57 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1650310370; 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=zrwj1CB0nzLrTkLt6ydkF9sffF2QU5IiBDgF/72S5gw=; b=V7v7PxuNIJf+PhJM6v3YP8tTMhHD//zDiM5MuacztKMHPEDJn9/kFQcG3Vr1lQiQnWkBTC AjGrYdDq/HZS7k6eVWmut++gYxfjKZNTOnDJoAOpg4wlKNS12njTNsJ/L541AwaqXj0FeQ OzgNsQk5RrXr9HlqldnexOmVFyZrQMU= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 3dfbf369 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 18 Apr 2022 19:32:49 +0000 (UTC) Message-ID: <3b85072c-eb07-6a74-fae3-258c99756c11@nomadlogic.org> Date: Mon, 18 Apr 2022 12:32:48 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: -CURRENT hangs since at least 2022-04-04 Content-Language: en-US To: filis+fbsdcurrent@filis.org, freebsd-current@FreeBSD.org References: <0c1b4885-dd0f-b48f-2ffe-12ccfd2ec118@filis.org> From: Pete Wright In-Reply-To: <0c1b4885-dd0f-b48f-2ffe-12ccfd2ec118@filis.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Khxt134Jnz4d7T X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=V7v7PxuN; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[fbsdcurrent]; TO_DN_NONE(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/18/22 12:23, filis+fbsdcurrent@filis.org wrote: > Hi, > > I'm running -CURRENT on this one desktop box which is a "Ryzen 7 4800U > with Radeon Graphics", since it didn't work on 13R. > I use Boot environments and on 2022-04-04 I updated it and it started > to completely freeze under X (I haven't tried letting it run without > X) after a few dozen minutes. > I went on vacation and came back today and updated it again to see if > the issue went away, but it froze again. I went back to the latest BE > before 2022-04-04, which is from 2022-03-21 and so far it works fine > again. I use a different machine to build and then rsync /usr/src and > /usr/obj over and run make installworld, etc locally and also pkg > upgrade (I use FreeBSD -latest packages) everything, so I can't quite > tell if this is related to base or drm-kmod and I'm not too familiar > with changes in the timeframe between 2022-03-21 and 2022-04-04 that > would affect my setup. > Is there anything I can try and/or find or collect info to shed more > light on this? > After updating your CURRENT environment did you rebuild the drm-kmod package?  that's usually required as the LKPI is much more of a moving target on that branch compared to STABLE or RELEASE.  i have a pretty much identical setup and building/installing drm-devel-kmod has been working flawlessly for quite a while. after building/installing my latest world i do following (this is from a local script i use when rebuilding): cd $PORTS/graphics/drm-devel-kmod sudo pkg unlock -y drm-devel-kmod sudo make package sudo pkg upgrade -y work/pkg/*.pkg sudo pkg lock -y drm-devel-kmod -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Mon Apr 18 23:32:38 2022 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 7295411CD70A for ; Mon, 18 Apr 2022 23:32:52 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91]) by mx1.freebsd.org (Postfix) with ESMTP id 4Kj3Bq5RPfz3rhR for ; Mon, 18 Apr 2022 23:32:51 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) IronPort-SDR: cwHDB8SuOurvcQQ9JzCMH64K9SuvfbK+AzB4EzvJldyh8SfCixXOQr3zXqfErBysxqIV6/nb/v XF9YDv8qpn7GELW+L/3et4mDZS7C8Ig+0= X-Ambrisko-Me: Yes IronPort-Data: A9a23:Rt9yJa3sClqeKM1dnfbD5bNxkn2cJEfYwER7XKvMYLTBsI5bp2MPy mMYXmyBb/3ZYGuhf48jYIrgpBwHvMPXzdBgTQRq+CA2RRqmiyZl6fd1j6vUF3nPRiH7oc4OA /w2MrEsFuhtJpPhjkzF3obJ/CAUOZ6gFuKU5N7sYkiddCc8IMsToUsLd90R3uaEteOE7zal4 rselSF/1GiNgFaYOkpMg06KRYgGUP7a4Fv0tXRmDRxHUcO3e9D40fsiya+Nw3vQGuG4H8a7Q frO1rew+iXQ+h03C8imlfDwdUhirrz6ZFnUzCMIC+77xEIqSi8ais7XMNIVbE1Nii6KmPh4z d9XtIezTkEiOaikdOE1DkABTHAgVUFB0PqdSZSliuSd1UDLeWDghv5zFls7O5Ew9Px6DGtV+ bofMj9lU/wpr4pa25qgR/Nyi955asDuNpkeoXJnizreCJ4brVn4a/2izbdlMP0Y36iixN7SO JgUbyRBdhPFb0EdM1sbEshnzu6tjGP+aD5fgFuQr7A2+GvUigd21eG1YtbSf9WLQ+RTn1qZ9 j+epjWlWklCOYzN0yeB/1KtmvTLwXHxVrUNGeDq7fVtmlCSmDAeUUVESVuhrPCloUeiQNYDe VcM8y8joPFqpkymR9XwRTOip3uAskJOUtZcCbdjugiIwLDV+AWeLmEBRCRAc98h8sQxQGVyh FOOmtroAx1psaGUGS/Fr+bI9WvqNHFMf2EYZCICQQ8U2PXZodk+3kDVU9JuMK+pldmpSzv+9 C+H8XoljLIJgM9Vi6jipQLbgyihr4TiRxIu4lmFRXqs6w50adL3Z4Gs7lSHv/9MIJzDFwuAu mQJgc6X6KYHCJuXlTeOR6MGG7Twv6SJNzjVgFhOGZg99mTwoyfyIdgIuDwudl10NsskeCPyZ B6BsAxc05ZfIX+2YPIleIm2EckrkfDtGIi3TPzSddYSMJF9eBXdpHN1aFSO0nq31kEpm7s+I pScN82rCC9CW6hgyTO3QcYb0KMqln1mnDKPHcijwkT1y6eaaV6UVawBYQmHYe0O5a+ZpBnYr oREPMyQxhQDCODzb0E7K2LIwYzm+ZTjOa3Llg== IronPort-HdrOrdr: A9a23:800yh6350K/mETi3oj+XowqjBKwkLtp133Aq2lEZdPVwSL38qy nOpoV46faaslossR0b9uxoW5PwIk80l6QU3WB5B97LN2TbUQCTTb2Kg7GN/9XRcReVytJg Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 18 Apr 2022 15:29:19 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 23INWcri014769 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 18 Apr 2022 16:32:38 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com Received: (from ambrisko@localhost) by ambrisko.com (8.17.1/8.17.1/Submit) id 23INWcLp014768 for freebsd-current@freebsd.org; Mon, 18 Apr 2022 16:32:38 -0700 (PDT) (envelope-from ambrisko) Date: Mon, 18 Apr 2022 16:32:38 -0700 From: Doug Ambrisko To: freebsd-current@freebsd.org Subject: nullfs and ZFS issues Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4Kj3Bq5RPfz3rhR X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com X-Spamd-Result: default: False [2.91 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[ambrisko]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; HAS_XAW(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; NEURAL_SPAM_LONG(0.97)[0.970]; DMARC_NA(0.00)[ambrisko.com]; NEURAL_HAM_SHORT(-0.06)[-0.059]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I've switched my laptop to use nullfs and ZFS. Previously, I used localhost NFS mounts instead of nullfs when nullfs would complain that it couldn't mount. Since that check has been removed, I've switched to nullfs only. However, every so often my laptop would get slow and the the ARC evict and prune thread would consume two cores 100% until I rebooted. I had a 1G max. ARC and have increased it to 2G now. Looking into this has uncovered some issues: - nullfs would prevent vnlru_free_vfsops from doing anything when called from ZFS arc_prune_task - nullfs would hang onto a bunch of vnodes unless mounted with nocache - nullfs and nocache would break untar. This has been fixed now. With nullfs, nocache and settings max vnodes to a low number I can keep the ARC around the max. without evict and prune consuming 100% of 2 cores. This doesn't seem like the best solution but it better then when the ARC starts spinning. Looking into this issue with bhyve and a md drive for testing I create a brand new zpool mounted as /test and then nullfs mount /test to /mnt. I loop through untaring the Linux kernel into the nullfs mount, rm -rf it and repeat. I set the ARC to the smallest value I can. Untarring the Linux kernel was enough to get the ARC evict and prune to spin since they couldn't evict/prune anything. Looking at vnlru_free_vfsops called from ZFS arc_prune_task I see it static int vnlru_free_impl(int count, struct vfsops *mnt_op, struct vnode *mvp) { ... for (;;) { ... vp = TAILQ_NEXT(vp, v_vnodelist); ... /* * Don't recycle if our vnode is from different type * of mount point. Note that mp is type-safe, the * check does not reach unmapped address even if * vnode is reclaimed. */ if (mnt_op != NULL && (mp = vp->v_mount) != NULL && mp->mnt_op != mnt_op) { continue; } ... The vp ends up being the nulfs mount and then hits the continue even though the passed in mvp is on ZFS. If I do a hack to comment out the continue then I see the ARC, nullfs vnodes and ZFS vnodes grow. When the ARC calls arc_prune_task that calls vnlru_free_vfsops and now the vnodes go down for nullfs and ZFS. The ARC cache usage also goes down. Then they increase again until the ARC gets full and then they go down again. So with this hack I don't need nocache passed to nullfs and I don't need to limit the max vnodes. Doing multiple untars in parallel over and over doesn't seem to cause any issues for this test. I'm not saying commenting out continue is the fix but a simple POC test. It appears that when ZFS is asking for cached vnodes to be free'd nullfs also needs to free some up as well so that they are free'd on the VFS level. It seems that vnlru_free_impl should allow some of the related nullfs vnodes to be free'd so the ZFS ones can be free'd and reduce the size of the ARC. BTW, I also hacked the kernel and mount to show the vnodes used per mount ie. mount -v: test on /test (zfs, NFS exported, local, nfsv4acls, fsid 2b23b2a1de21ed66, vnodes: count 13846 lazy 0) /test on /mnt (nullfs, NFS exported, local, nfsv4acls, fsid 11ff002929000000, vnodes: count 13846 lazy 0) Now I can easily see how the vnodes are used without going into ddb. On my laptop I have various vnet jails and nullfs mount my homedir into them so pretty much everything goes through nullfs to ZFS. I'm limping along with the nullfs nocache and small number of vnodes but it would be nice to not need that. Thanks, Doug A. From nobody Tue Apr 19 01:43:37 2022 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 1244A5D3A16 for ; Tue, 19 Apr 2022 01:44:08 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kj66H1rbjz4fRJ for ; Tue, 19 Apr 2022 01:44:07 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x32e.google.com with SMTP id m15-20020a7bca4f000000b0038fdc1394b1so565303wml.2 for ; Mon, 18 Apr 2022 18:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=IXdBHjLSLJQ6cizRRWOBuCmpNe3Tnc3jbTX9kuBvyGY=; b=KI9ZBqb+zBLrY34+psIPnt2DtysRJCb+tJ85wKimEXu4e/PJLkUsF+M1O4KaIoduwF qwgPN1s1Zawx9rcKt7KDpxLiXvbGQlefjuw9rz/RPaA27hgq6Q2nEaItaHwpXEYO5R4u xmbwbuYTyvGquH2fzov4EbK55MpMJxWOn5RApMreHIfLqCQ8UgtyYZKzF5Dhi0XYQvPB I0ckUtmcmHEcDYq54V9OAvXUxDjzGCLPyYuHRQOL+oOKn91uABZvhJofG6eKYNi3uIZ/ EqJf5vg72af66+FLm31NvdHG/lG302FLq0QmCbFmh7fhlST/l+7hLnJxXXO2iiR3+XlH 8oiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=IXdBHjLSLJQ6cizRRWOBuCmpNe3Tnc3jbTX9kuBvyGY=; b=uMdwa3IShDwlwJiHseoy1M0H6BE8QPwxROCSK961NIqa6yplwoCf0b5KLfUSc8JFD/ 8uk/roQ5Gj1OsCYw/+FxBGyohW7M2a5bV67cdl+JJqJgWJsfCpTbCMB394NcQQqn31+H gXyYijKpkrub6+NB7B+zEktr1dgFbddLOBAvbdp6A7fXgI3CLvjXlrm85V4I6opS2eEm TnYBjXul2tzKWQJLNMFAECUSwSLhEE+x3ox8PWYATJb04XlSkJ0QundxZoDD5TzNnTpz E3XcZr0AqyZY+nWUClro5DIgIYr61oKfda+7Jokg/PSmK+6nv47XZ6hzoDizZd++FFO5 bOLw== X-Gm-Message-State: AOAM5300artEDfyOqYeWvnB+37hu1Oeq0mIVwsBv5k9Lc3llRhCUHkWe zi/p5tsIEr29uYlAItdOx1lmVfmlzmSyPQ== X-Google-Smtp-Source: ABdhPJwWAkT8oARe5S5rTzJ/KdijOpCpsnhaO+EDrqx/nn5As/5niIxRxKHxGOM96WkWUKWlZiv73g== X-Received: by 2002:a1c:acc6:0:b0:38e:b184:7721 with SMTP id v189-20020a1cacc6000000b0038eb1847721mr13391500wme.94.1650332639398; Mon, 18 Apr 2022 18:43:59 -0700 (PDT) Received: from [192.168.1.7] (88-108-159-26.dynamic.dsl.as9105.com. [88.108.159.26]) by smtp.gmail.com with ESMTPSA id r21-20020a05600c35d500b0039295759a55sm5148152wmq.12.2022.04.18.18.43.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Apr 2022 18:43:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------0Inz4yQwYt23DsPBcdXa7NLl" Message-ID: Date: Tue, 19 Apr 2022 02:43:37 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-GB To: freebsd-current@freebsd.org References: <093ec3cb-32a1-e316-a369-3a9e8559248a@blastwave.org> From: Graham Perrin In-Reply-To: <093ec3cb-32a1-e316-a369-3a9e8559248a@blastwave.org> X-Rspamd-Queue-Id: 4Kj66H1rbjz4fRJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=KI9ZBqb+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-2.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; URI_COUNT_ODD(1.00)[3]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[88.108.159.26:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32e:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------0Inz4yQwYt23DsPBcdXa7NLl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/04/2022 23:35, Dennis Clarke wrote: > … at least two examples in the wild. … Not the same symptom, but caught my eye: > RC3 Guided ZFS on root with encryption unmountable Beyond that, I have nothing useful to add (sorry). I do not get the "no pools available to import" symptom with any of the boot environments listed below (Git hash within the name of each BE). % bectl list -c creation BE                    Active Mountpoint Space Created n250511-5f73b3338ee-d -      -          4.94G 2021-11-13 15:43 n252381-75d20a5e386-b -      -          6.81G 2022-01-12 23:23 n252450-5efa7281a79-a -      -          6.49G 2022-01-14 19:27 n252483-c8f8299a230-b -      -          4.84G 2022-01-17 14:24 n252505-cc68614da82-a -      -          4.90G 2022-01-18 14:26 n252531-0ce7909cd0b-h -      -          5.71G 2022-02-06 12:24 n252997-b6724f7004c-c -      -          6.17G 2022-02-11 23:07 n253116-39a36707bd3-e -      -          5.66G 2022-02-20 07:03 n253343-9835900cb95-c -      -          1.54G 2022-02-27 14:58 n253776-d5ad1713cc3-b -      -          7.94G 2022-03-18 09:31 n253861-92e6b4712b5-e -      -          7.41G 2022-04-02 16:02 n254268-50e244964e9-d -      -          2.92G 2022-04-09 18:50 n254693-d7696096209-b -      -          388M  2022-04-17 03:38 n254693-d7696096209-c NR     /          188G  2022-04-17 23:55 % --------------0Inz4yQwYt23DsPBcdXa7NLl Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/04/2022 23:35, Dennis Clarke wrote:
… at least two examples in the wild. …

Not the same symptom, but <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263407> caught my eye:


RC3 Guided ZFS on root with encryption unmountable


Beyond that, I have nothing useful to add (sorry). I do not get the "no pools available to import" symptom with any of the boot environments listed below (Git hash within the name of each BE).

% bectl list -c creation
BE                    Active Mountpoint Space Created
n250511-5f73b3338ee-d -      -          4.94G 2021-11-13 15:43
n252381-75d20a5e386-b -      -          6.81G 2022-01-12 23:23
n252450-5efa7281a79-a -      -          6.49G 2022-01-14 19:27
n252483-c8f8299a230-b -      -          4.84G 2022-01-17 14:24
n252505-cc68614da82-a -      -          4.90G 2022-01-18 14:26
n252531-0ce7909cd0b-h -      -          5.71G 2022-02-06 12:24
n252997-b6724f7004c-c -      -          6.17G 2022-02-11 23:07
n253116-39a36707bd3-e -      -          5.66G 2022-02-20 07:03
n253343-9835900cb95-c -      -          1.54G 2022-02-27 14:58
n253776-d5ad1713cc3-b -      -          7.94G 2022-03-18 09:31
n253861-92e6b4712b5-e -      -          7.41G 2022-04-02 16:02
n254268-50e244964e9-d -      -          2.92G 2022-04-09 18:50
n254693-d7696096209-b -      -          388M  2022-04-17 03:38
n254693-d7696096209-c NR     /          188G  2022-04-17 23:55
%

--------------0Inz4yQwYt23DsPBcdXa7NLl-- From nobody Tue Apr 19 07:56:38 2022 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 6491D11D0075 for ; Tue, 19 Apr 2022 07:56:49 +0000 (UTC) (envelope-from contact@evilham.com) Received: from yggdrasil.evilham.com (yggdrasil.evilham.com [46.19.33.155]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjGNJ4Xx5z4SFp for ; Tue, 19 Apr 2022 07:56:48 +0000 (UTC) (envelope-from contact@evilham.com) From: Evilham DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=evilham.com; s=mail; t=1650355000; bh=6dDHTimuiJTcq2bgSHEZlSmjdi1znXX75W9bpQAmiVo=; h=From:To:Cc:Subject:References:In-reply-to:Date; b=awmVoscC6y8yU7gbWeeE6LyfNHeT5DA0oAHwXdlrOBiiWePhe5wwbqaM763yvr513 KRaQ7gLLwFv4VP4hnFQdlNRsTpXQcvmvit5QECzWD8eyluGrLJMykv8XeSh8gMamEU 1JvzuUH/jAxhoHngfpsN46UjtZa9a9aVj1tuudMQ= To: Pete Wright Cc: filis+fbsdcurrent@filis.org, freebsd-current@freebsd.org Subject: Re: -CURRENT hangs since at least 2022-04-04 References: <0c1b4885-dd0f-b48f-2ffe-12ccfd2ec118@filis.org> <3b85072c-eb07-6a74-fae3-258c99756c11@nomadlogic.org> In-reply-to: <3b85072c-eb07-6a74-fae3-258c99756c11@nomadlogic.org> Date: Tue, 19 Apr 2022 09:56:38 +0200 Message-ID: <29e49f2aec9683eb9736326d6596a63730cb@yggdrasil.evilham.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; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4KjGNJ4Xx5z4SFp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=evilham.com header.s=mail header.b=awmVoscC; dmarc=pass (policy=quarantine) header.from=evilham.com; spf=pass (mx1.freebsd.org: domain of contact@evilham.com designates 46.19.33.155 as permitted sender) smtp.mailfrom=contact@evilham.com X-Spamd-Result: default: False [-2.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[evilham.com:s=mail]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TAGGED_RCPT(0.00)[fbsdcurrent]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.99)[0.989]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[evilham.com:+]; DMARC_POLICY_ALLOW(-0.50)[evilham.com,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:196752, ipnet:46.19.32.0/21, country:NL] X-ThisMailContainsUnwantedMimeParts: N On dl., abr. 18 2022, Pete Wright wrote: > On 4/18/22 12:23, filis+fbsdcurrent@filis.org wrote: >> Hi, >> >> I'm running -CURRENT on this one desktop box which is a "Ryzen=20 >> 7 4800U with >> Radeon Graphics", since it didn't work on 13R. >> I use Boot environments and on 2022-04-04 I updated it and it=20 >> started to >> completely freeze under X (I haven't tried letting it run=20 >> without X) after a >> few dozen minutes. >> I went on vacation and came back today and updated it again to=20 >> see if the >> issue went away, but it froze again. I went back to the latest=20 >> BE before >> 2022-04-04, which is from 2022-03-21 and so far it works fine=20 >> again. I use a >> different machine to build and then rsync /usr/src and /usr/obj=20 >> over and run >> make installworld, etc locally and also pkg upgrade (I use=20 >> FreeBSD -latest >> packages) everything, so I can't quite tell if this is related=20 >> to base or >> drm-kmod and I'm not too familiar with changes in the timeframe=20 >> between >> 2022-03-21 and 2022-04-04 that would affect my setup. >> Is there anything I can try and/or find or collect info to shed=20 >> more light on >> this? >> > > After updating your CURRENT environment did you rebuild the=20 > drm-kmod package? > that's usually required as the LKPI is much more of a moving=20 > target on that > branch compared to STABLE or RELEASE.=C2=A0 i have a pretty much=20 > identical setup and > building/installing drm-devel-kmod has been working flawlessly=20 > for quite a > while. > > after building/installing my latest world i do following (this=20 > is from a local > script i use when rebuilding): > > cd $PORTS/graphics/drm-devel-kmod > sudo pkg unlock -y drm-devel-kmod > sudo make package > sudo pkg upgrade -y work/pkg/*.pkg > sudo pkg lock -y drm-devel-kmod > > -pete I too have recently noticed some freezes after a few hours on=20 -CURRENT that were not happening before. This with a matching drm-devel-kmod package (built with matching=20 source on matching kernel). The hw being: AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfx -- Evilham From nobody Tue Apr 19 08:49:23 2022 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 72BB911DE2AD for ; Tue, 19 Apr 2022 08:49:35 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjHYB3XhYz4dGF for ; Tue, 19 Apr 2022 08:49:34 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x133.google.com with SMTP id i8so5061725ila.5 for ; Tue, 19 Apr 2022 01:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SQhNkqHThB5H1n7WwqIg7oFqZZcziXly1z77daE6oec=; b=kuH6AvGx0L7BezXIJzBTaam+lNGF/sqGUkh2uYQw42DO3VF5buLdDG2YGR6855TuHm YdXdqx2ornliwj8jBOheS7pZoVv1cMNrfQ3IAh1xNihLvCT3y9hAHVs5+m0c8aKJR3jZ GdKIVSzZo+jKxUknfEUuDMfvJ85aTBODhzY+nMfs1Yrl0gNzfuBZrvJlERif4KxWBuFW 003Co3ZrIZpoQyCsvnXUywF2z6NVAhCxCl6gRbzpbd/iSa1BQBUIwnR7H4x3/w5BGPTs XqUzL7djCrq/xXga4RQYsL0TCxumznt/lsBF2FtgLM/jaXDgTrs5Q63HNmZhWPynGtEq +d6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SQhNkqHThB5H1n7WwqIg7oFqZZcziXly1z77daE6oec=; b=RmXKwf5ZKY/fzoXmNwgxRjB17x1kbjG4DD26jSOCmA3HlDOBUdQiaMGOk6Sd3iON9P OWC3scziw0ErmU70XzAYd899bbLJ6zFzFdKVDDFLEYp9bu+OmqjHxw0DloNvzjNssZfw O7maY0pBZKZIQTW9bVxho4k0u77qvm1D67hWe7/Q8k0iF18RkSJWcQWhQlq7tRrl+uId 4rdvpWYYZznW4eeQNYvajefrLgZjt0xbfwDGPfFiL9cuxjrf3hUPV39qgdurHbhsH5cF bvWc7Owj5gSE4VC6jeO7ZjZMy+km1nxjvu/IB4F8xkMROXED8OeuexxPs8y2oHVvER4v Dk/Q== X-Gm-Message-State: AOAM530X7k830EqzUN9z7SX7V99FnZYua+MTP+8tGvHOgiR6PuaZSF1D hM+xCTPRIinluSzwDeOdqv5EOlkWm/1SNuPo2T82wrLzcF0HvA== X-Google-Smtp-Source: ABdhPJwaCnPmYDsKQWU1VFSWGkfsqCATxzuRxfuXeg3XSw4PogKQhTx/nFUv/KqKm5OGdSTho80XVP6TFKhFC6hO/b8= X-Received: by 2002:a05:6e02:14c2:b0:2ca:b671:dea3 with SMTP id o2-20020a056e0214c200b002cab671dea3mr6125765ilk.63.1650358173503; Tue, 19 Apr 2022 01:49:33 -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: <0c1b4885-dd0f-b48f-2ffe-12ccfd2ec118@filis.org> <3b85072c-eb07-6a74-fae3-258c99756c11@nomadlogic.org> In-Reply-To: <3b85072c-eb07-6a74-fae3-258c99756c11@nomadlogic.org> From: Michael Schuster Date: Tue, 19 Apr 2022 10:49:23 +0200 Message-ID: Subject: advice sought: workflow with -CURRENT and amd GPU [Re: -CURRENT hangs since at least 2022-04-04] To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KjHYB3XhYz4dGF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=kuH6AvGx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::133 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::133:from]; NEURAL_HAM_SHORT(-0.99)[-0.995]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Hi, I'm highjacking and re-purposing the previous thread, I hope that's OK (I did change the subject ;-)) - I'm keeping some of the previous contents for reference. I have similar HW to OP (Ryzen 7 4700 w. Renoir Graphics), and have been using a similar approach to keep the machine up to date - or so I suspect. Still, after a while (several months), I end up with one or more of these: - I get some sort of panic in DRM (at startup or, currently, at shutdown) - when I boot into to a previous BE to attempt a fix and then again reboot into the current one, I get tons of messages like this "... kernel: KLD iic.ko: depends on kernel - not available or version mismatch ... kernel: linker_load_file: /boot/kernel/iic.ko - unsupported file type" and computer refuses to accept input (let alone start X) and some others I don't recall right now. Before I ask for advice (see below), let me explain the approaches I've taken so far. I install with ZFS from the beginning, current boot env is "N". These are outlines, not exact commands: I) never touch the current BE, always update a new one: 1) given current BE N, I create a new BE N+1 and mount it on /mnt, 2) 'cd /usr/src; git pull; sudo make DESTDIR=/mnt ... (build, install, etc)' 3) 'cd usr/ports/graphics/drm-devel-kmod; sudo make DESTDIR=/mnt install' 4) beadm activate BE N+1; reboot II) keep a "new" BE as backup/fallback, update current BE: 1) given current BE N, I create a new BE N+1 (mounting not required) (this is the intended 'fallback') 2) 'cd /usr/src; git pull"; then "make" as described in the Handbook "24.6. Updating FreeBSD from Source" 3) 'cd usr/ports/graphics/drm-devel-kmod; sudo make install' 4) reboot in both scenarios(sp?), I do "pkg update; pkg upgrade" from time to time (also following the resp. approach shown above). I suspect that I'm missing something fundamental in my approaches - does anyone have a (for them) foolproof approach along these lines, or can someone show me what I'm missing in either of mine (in private, if you prefer)? TIA for all and any advice Michael On Mon, Apr 18, 2022 at 9:33 PM Pete Wright wrote: > > > > On 4/18/22 12:23, filis+fbsdcurrent@filis.org wrote: > > Hi, > > > > I'm running -CURRENT on this one desktop box which is a "Ryzen 7 4800U > > with Radeon Graphics", since it didn't work on 13R. > > I use Boot environments and on 2022-04-04 I updated it and it started > > to completely freeze under X (I haven't tried letting it run without > > X) after a few dozen minutes. > [...] > > > After updating your CURRENT environment did you rebuild the drm-kmod > package? that's usually required as the LKPI is much more of a moving > target on that branch compared to STABLE or RELEASE. i have a pretty > much identical setup and building/installing drm-devel-kmod has been > working flawlessly for quite a while. > > after building/installing my latest world i do following (this is from a > local script i use when rebuilding): > > cd $PORTS/graphics/drm-devel-kmod > sudo pkg unlock -y drm-devel-kmod > sudo make package > sudo pkg upgrade -y work/pkg/*.pkg > sudo pkg lock -y drm-devel-kmod > > -pete > > -- > Pete Wright > pete@nomadlogic.org > @nomadlogicLA > > -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From nobody Tue Apr 19 09:12:27 2022 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 6D4D611E3B77 for ; Tue, 19 Apr 2022 09:12:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjJ3m2Xdyz4hc1 for ; Tue, 19 Apr 2022 09:12:36 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lf1-x12c.google.com with SMTP id b21so28260423lfb.5 for ; Tue, 19 Apr 2022 02:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4A8sy6LJ/KfPX9W5qEIhmpvtfz8fgVlk2MQP4WXqbLk=; b=AR6Gjzyu8bMvNNs29LJeqoUoLTO++60gD0iGsJQjr68PmkdhuKOCC4ypqlLVaoSCSp 5rjRLnoUkLmuTiMvy3V/grBlUAc77I2PT0HBWUQEA/Cjy/vQq64zzOkZ6WERhwk1cL2i USNi1hy97psEqwhsOwd5gRbwhEn5RGhpyYYKySw4W4zCHbQh8aVADtGnpvLcaM77Ol4C CWEOyn4a1e7pfOHWfVov+CwLj/WKxw4pcvZwXrwGItW+G0QgQzzCWz72rL7sMgFe81LX YDFV6WYH7q/9rfhg68y5kRkUh8qnEWpOYYiarg/IoMmZ6GgdoPbB3hhmakSXruwN1rXn eGnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4A8sy6LJ/KfPX9W5qEIhmpvtfz8fgVlk2MQP4WXqbLk=; b=QcLigl1gtkC8vejN6VpXHNOiNlmHReWchiGuRHLTM9eE67JMnz5UTgakHW2X1O8/iN 8JNZA30krLXiftO1/rHtycPUSPPxXJoRdbGnkxP0zLF/I1xCAl8E6rppe7nF5Zb/wrud fLbHQHrbzvvRGjwp4farIDYvHNKm8p/1O+IrY7EptQbanXN1hpmjXRjSQzRNwBimGUie Oh1bBH/WuwFUee2mF76AhKMTBt/M2eR43tzw+wWy4IqYxLL3wBJ/ngTkOqCE1dpF5Bag h/ecYDA3zJnuOqd9On4ijCeWHhnkCHRSZZTID4G43uHPKeqeVX+FwqcWtFswPYWsPFuS t4pw== X-Gm-Message-State: AOAM530fisoOq18TxNewkBYZNeqPSsrsee1YBxb7RE401fEfY02RVLUY 1lfNWxp2k/9HRHb8eSMmUEc5DnRyodyesNjg16kUxJTt X-Google-Smtp-Source: ABdhPJwyBGvue3cuE5hWazgBSNeWYCuoodbOnG8QAc5JRim8ArJj9boj5XTqjPrYjTygfXzOlzSdHKGQoqC5IEuJT0U= X-Received: by 2002:a05:6512:3a95:b0:471:886a:8117 with SMTP id q21-20020a0565123a9500b00471886a8117mr7996555lfu.682.1650359548533; Tue, 19 Apr 2022 02:12:28 -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 Received: by 2002:a05:6520:6145:b0:1bb:7433:4cdd with HTTP; Tue, 19 Apr 2022 02:12:27 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Tue, 19 Apr 2022 11:12:27 +0200 Message-ID: Subject: Re: nullfs and ZFS issues To: Doug Ambrisko Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KjJ3m2Xdyz4hc1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=AR6Gjzyu; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::12c as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-3.92 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12c:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-0.92)[-0.919]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 4/19/22, Doug Ambrisko wrote: > I've switched my laptop to use nullfs and ZFS. Previously, I used > localhost NFS mounts instead of nullfs when nullfs would complain > that it couldn't mount. Since that check has been removed, I've > switched to nullfs only. However, every so often my laptop would > get slow and the the ARC evict and prune thread would consume two > cores 100% until I rebooted. I had a 1G max. ARC and have increased > it to 2G now. Looking into this has uncovered some issues: > - nullfs would prevent vnlru_free_vfsops from doing anything > when called from ZFS arc_prune_task > - nullfs would hang onto a bunch of vnodes unless mounted with > nocache > - nullfs and nocache would break untar. This has been fixed now. > > With nullfs, nocache and settings max vnodes to a low number I can > keep the ARC around the max. without evict and prune consuming > 100% of 2 cores. This doesn't seem like the best solution but it > better then when the ARC starts spinning. > > Looking into this issue with bhyve and a md drive for testing I create > a brand new zpool mounted as /test and then nullfs mount /test to /mnt. > I loop through untaring the Linux kernel into the nullfs mount, rm -rf it > and repeat. I set the ARC to the smallest value I can. Untarring the > Linux kernel was enough to get the ARC evict and prune to spin since > they couldn't evict/prune anything. > > Looking at vnlru_free_vfsops called from ZFS arc_prune_task I see it > static int > vnlru_free_impl(int count, struct vfsops *mnt_op, struct vnode *mvp) > { > ... > > for (;;) { > ... > vp = TAILQ_NEXT(vp, v_vnodelist); > ... > > /* > * Don't recycle if our vnode is from different type > * of mount point. Note that mp is type-safe, the > * check does not reach unmapped address even if > * vnode is reclaimed. > */ > if (mnt_op != NULL && (mp = vp->v_mount) != NULL && > mp->mnt_op != mnt_op) { > continue; > } > ... > > The vp ends up being the nulfs mount and then hits the continue > even though the passed in mvp is on ZFS. If I do a hack to > comment out the continue then I see the ARC, nullfs vnodes and > ZFS vnodes grow. When the ARC calls arc_prune_task that calls > vnlru_free_vfsops and now the vnodes go down for nullfs and ZFS. > The ARC cache usage also goes down. Then they increase again until > the ARC gets full and then they go down again. So with this hack > I don't need nocache passed to nullfs and I don't need to limit > the max vnodes. Doing multiple untars in parallel over and over > doesn't seem to cause any issues for this test. I'm not saying > commenting out continue is the fix but a simple POC test. > I don't see an easy way to say "this is a nullfs vnode holding onto a zfs vnode". Perhaps the routine can be extrended with issuing a nullfs callback, if the module is loaded. In the meantime I think a good enough(tm) fix would be to check that nothing was freed and fallback to good old regular clean up without filtering by vfsops. This would be very similar to what you are doing with your hack. > It appears that when ZFS is asking for cached vnodes to be > free'd nullfs also needs to free some up as well so that > they are free'd on the VFS level. It seems that vnlru_free_impl > should allow some of the related nullfs vnodes to be free'd so > the ZFS ones can be free'd and reduce the size of the ARC. > > BTW, I also hacked the kernel and mount to show the vnodes used > per mount ie. mount -v: > test on /test (zfs, NFS exported, local, nfsv4acls, fsid 2b23b2a1de21ed66, > vnodes: count 13846 lazy 0) > /test on /mnt (nullfs, NFS exported, local, nfsv4acls, fsid > 11ff002929000000, vnodes: count 13846 lazy 0) > > Now I can easily see how the vnodes are used without going into ddb. > On my laptop I have various vnet jails and nullfs mount my homedir into > them so pretty much everything goes through nullfs to ZFS. I'm limping > along with the nullfs nocache and small number of vnodes but it would be > nice to not need that. > > Thanks, > > Doug A. > > -- Mateusz Guzik From nobody Tue Apr 19 09:15:42 2022 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 45C4411E6146 for ; Tue, 19 Apr 2022 09:15:45 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjJ7N47x5z4kJc for ; Tue, 19 Apr 2022 09:15:44 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lf1-x12d.google.com with SMTP id b21so28273984lfb.5 for ; Tue, 19 Apr 2022 02:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i0tq+F6csxZWxJ06LYr84hF10GXDLkir4mZGrgYGtP0=; b=h3P/Quzo5vlWhkfsL7xDqQI5yXmEnMMXx/6k3Y1PVNCE2C8CBmbnQRfwnhEcyHReJb VkLqEIzNGbSu9MF/JLhebDYltpISVTGQ9eDZNrI/m0K9ZuwFNvVMd5FpN6l1poySfiyW dAJYmhRvkuluhjHS894bxBjsYJIKjJ+jj9B46G2EFYUO1YRhCeYK/z6bpRMflMm06vha U/JsPrMOqBnN5gBwWiqcW/LKiFl1QMGiHgWHexI2rDm2xTL54ViOtAWDdnP4xRdVVkqt EsGJ6WWb09e5wnJ+h3xcwzsVRnK39j/FqvezYdGWLEEql8Z0eOdLby8WDp+MV+SasCh9 Dl5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i0tq+F6csxZWxJ06LYr84hF10GXDLkir4mZGrgYGtP0=; b=E5+m/bmts9Sd7tKaX68J3kOsDGZUYMLVIz8FukVXqhu1kJE4qLPMriMNGUgYCG/DZQ YUiOoHnYGAf44cf45bJMjEZbSnzl8m8Vf66xVOzcTSexULjjX6aGcr5IkSXQ4zUwE6wd 6+IeaTamxc/90QRR8KDRfPotJHX88bjenTfT67eSRFj1FNDV3c1Xvpdr4wANZ6VKqZlB uHzrepcTo2TXde3u3Y28SAOJDGD4cTQhg539Mqwi24IEFTuqj6W5Q2/X07jtmnNcOJjz 2uas7Mu+zSMVfhmntLAeD0zLf5KJbPHdNYO6vDVXsR2f8pexXF+hTklCMtZHqa8Ss0jJ znKQ== X-Gm-Message-State: AOAM532497+DCFZM87jQEzFMekF83nvjWUhkfYd3DCxqf2sfFzBw12Ge LgA4RnqckcyAvhQhIiZvvdrTTyY8Y3HcMkYCSjjrwr5v X-Google-Smtp-Source: ABdhPJwzml2ptjbWFseb7ooKFauOS42ph3ngqJW1MoZHmT202Q0E70IRXR+2pvcF6ho1Hhw8g217GSHHVuql9OJRJYA= X-Received: by 2002:a05:6512:3d13:b0:471:9471:5d57 with SMTP id d19-20020a0565123d1300b0047194715d57mr5763238lfv.366.1650359743411; Tue, 19 Apr 2022 02:15:43 -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 Received: by 2002:a05:6520:6145:b0:1bb:7433:4cdd with HTTP; Tue, 19 Apr 2022 02:15:42 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Tue, 19 Apr 2022 11:15:42 +0200 Message-ID: Subject: Re: nullfs and ZFS issues To: Doug Ambrisko Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KjJ7N47x5z4kJc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="h3P/Quzo"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::12d as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-3.78 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12d:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-0.80)[-0.798]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 4/19/22, Mateusz Guzik wrote: > On 4/19/22, Doug Ambrisko wrote: >> I've switched my laptop to use nullfs and ZFS. Previously, I used >> localhost NFS mounts instead of nullfs when nullfs would complain >> that it couldn't mount. Since that check has been removed, I've >> switched to nullfs only. However, every so often my laptop would >> get slow and the the ARC evict and prune thread would consume two >> cores 100% until I rebooted. I had a 1G max. ARC and have increased >> it to 2G now. Looking into this has uncovered some issues: >> - nullfs would prevent vnlru_free_vfsops from doing anything >> when called from ZFS arc_prune_task >> - nullfs would hang onto a bunch of vnodes unless mounted with >> nocache >> - nullfs and nocache would break untar. This has been fixed now. >> >> With nullfs, nocache and settings max vnodes to a low number I can >> keep the ARC around the max. without evict and prune consuming >> 100% of 2 cores. This doesn't seem like the best solution but it >> better then when the ARC starts spinning. >> >> Looking into this issue with bhyve and a md drive for testing I create >> a brand new zpool mounted as /test and then nullfs mount /test to /mnt. >> I loop through untaring the Linux kernel into the nullfs mount, rm -rf it >> and repeat. I set the ARC to the smallest value I can. Untarring the >> Linux kernel was enough to get the ARC evict and prune to spin since >> they couldn't evict/prune anything. >> >> Looking at vnlru_free_vfsops called from ZFS arc_prune_task I see it >> static int >> vnlru_free_impl(int count, struct vfsops *mnt_op, struct vnode *mvp) >> { >> ... >> >> for (;;) { >> ... >> vp = TAILQ_NEXT(vp, v_vnodelist); >> ... >> >> /* >> * Don't recycle if our vnode is from different type >> * of mount point. Note that mp is type-safe, the >> * check does not reach unmapped address even if >> * vnode is reclaimed. >> */ >> if (mnt_op != NULL && (mp = vp->v_mount) != NULL && >> mp->mnt_op != mnt_op) { >> continue; >> } >> ... >> >> The vp ends up being the nulfs mount and then hits the continue >> even though the passed in mvp is on ZFS. If I do a hack to >> comment out the continue then I see the ARC, nullfs vnodes and >> ZFS vnodes grow. When the ARC calls arc_prune_task that calls >> vnlru_free_vfsops and now the vnodes go down for nullfs and ZFS. >> The ARC cache usage also goes down. Then they increase again until >> the ARC gets full and then they go down again. So with this hack >> I don't need nocache passed to nullfs and I don't need to limit >> the max vnodes. Doing multiple untars in parallel over and over >> doesn't seem to cause any issues for this test. I'm not saying >> commenting out continue is the fix but a simple POC test. >> > > I don't see an easy way to say "this is a nullfs vnode holding onto a > zfs vnode". Perhaps the routine can be extrended with issuing a nullfs > callback, if the module is loaded. > > In the meantime I think a good enough(tm) fix would be to check that > nothing was freed and fallback to good old regular clean up without > filtering by vfsops. This would be very similar to what you are doing > with your hack. > Now that I wrote this perhaps an acceptable hack would be to extend struct mount with a pointer to "lower layer" mount (if any) and patch the vfsops check to also look there. > >> It appears that when ZFS is asking for cached vnodes to be >> free'd nullfs also needs to free some up as well so that >> they are free'd on the VFS level. It seems that vnlru_free_impl >> should allow some of the related nullfs vnodes to be free'd so >> the ZFS ones can be free'd and reduce the size of the ARC. >> >> BTW, I also hacked the kernel and mount to show the vnodes used >> per mount ie. mount -v: >> test on /test (zfs, NFS exported, local, nfsv4acls, fsid >> 2b23b2a1de21ed66, >> vnodes: count 13846 lazy 0) >> /test on /mnt (nullfs, NFS exported, local, nfsv4acls, fsid >> 11ff002929000000, vnodes: count 13846 lazy 0) >> >> Now I can easily see how the vnodes are used without going into ddb. >> On my laptop I have various vnet jails and nullfs mount my homedir into >> them so pretty much everything goes through nullfs to ZFS. I'm limping >> along with the nullfs nocache and small number of vnodes but it would be >> nice to not need that. >> >> Thanks, >> >> Doug A. >> >> > > > -- > Mateusz Guzik > -- Mateusz Guzik From nobody Tue Apr 19 09:47:22 2022 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 73F2B11FD825 for ; Tue, 19 Apr 2022 09:47:32 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjJr32PXjz4qZW for ; Tue, 19 Apr 2022 09:47:31 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lf1-x133.google.com with SMTP id u7so28385833lfs.8 for ; Tue, 19 Apr 2022 02:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cY2LnS4agAP4b9LwHs8WY1ZahM//I9Bir/vvMZnn+M8=; b=MUoKEgXgLPnifHtoU38g7F2y6i+HB6yqgOynN0ccK+CBAQnih/fBL7oPvYXtatXV7/ Uke8DqWhQAr/EuNQpm1iZFrfYvy/sRg3JO4HMYk8RIl2nZdVSfP1r/Z84yx2gRbkwlxJ TdXIwC1PlJKBhJqG+KMKqp16ySRq5EK5oBq7UJXQ5cLoZDHVJZVpYExalTr8qJPux5eZ wwrznuaoEcuMOluZ8Vv/lWLKD/Z4uwD3GPbHgwna1eGjABdGI+8dqyUtQl7N9HG1FGoa /FXP948fFiNaWFfKJrxHp6aF0ecM4cy+zSTf5WRZPTItnZq9teWhSddYzvKpPmosZu1l HZug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cY2LnS4agAP4b9LwHs8WY1ZahM//I9Bir/vvMZnn+M8=; b=B8+5Bzh7SmNLxRm8236sxbjyYaP35WRZB5r/L8LLqkjKHxAzdkySMIhiFwa83xkban OeuS50+Gyq954n0xHpGEZuk1Tp81WRSaBCFkNfoCGWxR44aVb+yTofKgW+wyOLG7CKfX v+kg6GQkg1W2aUwj9y+RdmnFzNXzLtUMhThEMK4OTRjJiO0QilheMdS9EJJnPYUthcYK F0l/J3+m/JvbDY1cQdJUzAzMmJcUA/GFi+CDwDfyjhBDaZcSJVtPnoRkmVGvkaLxgLMj fK5GxJknZizqNpTUFVZnxdEHqKrcUHaSswXZD1k0LiRdngUa2glWNobg0n2bAVvHL95u yo+A== X-Gm-Message-State: AOAM532NRn9mHhq0JAgEiTLc2R+3nxkdCLdYMLzd0Y/yLqfxk5EWzWTc 2/qtgdzGMv8fo2DZxy2K/xfXtGB1YEfFYauxCQWAc2Q3 X-Google-Smtp-Source: ABdhPJyIWvl7PsYxfAPQTi5tUzOptmcE/qXG1AuO+pZKDtEKVb2D+b0raOhQc06wr4eR/S9YmmCzZJw/R5h7uYrl74U= X-Received: by 2002:a05:6512:3a95:b0:471:886a:8117 with SMTP id q21-20020a0565123a9500b00471886a8117mr8078132lfu.682.1650361643792; Tue, 19 Apr 2022 02:47:23 -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 Received: by 2002:a05:6520:6145:b0:1bb:7433:4cdd with HTTP; Tue, 19 Apr 2022 02:47:22 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Tue, 19 Apr 2022 11:47:22 +0200 Message-ID: Subject: Re: nullfs and ZFS issues To: Doug Ambrisko Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KjJr32PXjz4qZW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=MUoKEgXg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::133 as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-2.04 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.978]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.93)[0.933]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::133:from]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Try this: https://people.freebsd.org/~mjg/vnlru_free_pick.diff this is not committable but should validate whether it works fine On 4/19/22, Mateusz Guzik wrote: > On 4/19/22, Mateusz Guzik wrote: >> On 4/19/22, Doug Ambrisko wrote: >>> I've switched my laptop to use nullfs and ZFS. Previously, I used >>> localhost NFS mounts instead of nullfs when nullfs would complain >>> that it couldn't mount. Since that check has been removed, I've >>> switched to nullfs only. However, every so often my laptop would >>> get slow and the the ARC evict and prune thread would consume two >>> cores 100% until I rebooted. I had a 1G max. ARC and have increased >>> it to 2G now. Looking into this has uncovered some issues: >>> - nullfs would prevent vnlru_free_vfsops from doing anything >>> when called from ZFS arc_prune_task >>> - nullfs would hang onto a bunch of vnodes unless mounted with >>> nocache >>> - nullfs and nocache would break untar. This has been fixed now. >>> >>> With nullfs, nocache and settings max vnodes to a low number I can >>> keep the ARC around the max. without evict and prune consuming >>> 100% of 2 cores. This doesn't seem like the best solution but it >>> better then when the ARC starts spinning. >>> >>> Looking into this issue with bhyve and a md drive for testing I create >>> a brand new zpool mounted as /test and then nullfs mount /test to /mnt. >>> I loop through untaring the Linux kernel into the nullfs mount, rm -rf >>> it >>> and repeat. I set the ARC to the smallest value I can. Untarring the >>> Linux kernel was enough to get the ARC evict and prune to spin since >>> they couldn't evict/prune anything. >>> >>> Looking at vnlru_free_vfsops called from ZFS arc_prune_task I see it >>> static int >>> vnlru_free_impl(int count, struct vfsops *mnt_op, struct vnode *mvp) >>> { >>> ... >>> >>> for (;;) { >>> ... >>> vp = TAILQ_NEXT(vp, v_vnodelist); >>> ... >>> >>> /* >>> * Don't recycle if our vnode is from different type >>> * of mount point. Note that mp is type-safe, the >>> * check does not reach unmapped address even if >>> * vnode is reclaimed. >>> */ >>> if (mnt_op != NULL && (mp = vp->v_mount) != NULL && >>> mp->mnt_op != mnt_op) { >>> continue; >>> } >>> ... >>> >>> The vp ends up being the nulfs mount and then hits the continue >>> even though the passed in mvp is on ZFS. If I do a hack to >>> comment out the continue then I see the ARC, nullfs vnodes and >>> ZFS vnodes grow. When the ARC calls arc_prune_task that calls >>> vnlru_free_vfsops and now the vnodes go down for nullfs and ZFS. >>> The ARC cache usage also goes down. Then they increase again until >>> the ARC gets full and then they go down again. So with this hack >>> I don't need nocache passed to nullfs and I don't need to limit >>> the max vnodes. Doing multiple untars in parallel over and over >>> doesn't seem to cause any issues for this test. I'm not saying >>> commenting out continue is the fix but a simple POC test. >>> >> >> I don't see an easy way to say "this is a nullfs vnode holding onto a >> zfs vnode". Perhaps the routine can be extrended with issuing a nullfs >> callback, if the module is loaded. >> >> In the meantime I think a good enough(tm) fix would be to check that >> nothing was freed and fallback to good old regular clean up without >> filtering by vfsops. This would be very similar to what you are doing >> with your hack. >> > > Now that I wrote this perhaps an acceptable hack would be to extend > struct mount with a pointer to "lower layer" mount (if any) and patch > the vfsops check to also look there. > >> >>> It appears that when ZFS is asking for cached vnodes to be >>> free'd nullfs also needs to free some up as well so that >>> they are free'd on the VFS level. It seems that vnlru_free_impl >>> should allow some of the related nullfs vnodes to be free'd so >>> the ZFS ones can be free'd and reduce the size of the ARC. >>> >>> BTW, I also hacked the kernel and mount to show the vnodes used >>> per mount ie. mount -v: >>> test on /test (zfs, NFS exported, local, nfsv4acls, fsid >>> 2b23b2a1de21ed66, >>> vnodes: count 13846 lazy 0) >>> /test on /mnt (nullfs, NFS exported, local, nfsv4acls, fsid >>> 11ff002929000000, vnodes: count 13846 lazy 0) >>> >>> Now I can easily see how the vnodes are used without going into ddb. >>> On my laptop I have various vnet jails and nullfs mount my homedir into >>> them so pretty much everything goes through nullfs to ZFS. I'm limping >>> along with the nullfs nocache and small number of vnodes but it would be >>> nice to not need that. >>> >>> Thanks, >>> >>> Doug A. >>> >>> >> >> >> -- >> Mateusz Guzik >> > > > -- > Mateusz Guzik > -- Mateusz Guzik From nobody Tue Apr 19 11:44:55 2022 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 A90A611DDD7B for ; Tue, 19 Apr 2022 11:45:09 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjMRm1x4xz3kxP for ; Tue, 19 Apr 2022 11:45:08 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id DEA0210A1E8D for ; Tue, 19 Apr 2022 13:44:58 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 4215F10A330F for ; Tue, 19 Apr 2022 13:44:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1650368697; 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=oU5YwxImKppcADuVqTvDrLb8qiakTL6gXi3N5nFWGfQ=; b=aSPfUepqM+jPuP/WnYhBtyZwx+CHcyHFXnoUxLIbc01Ue5E/ixQi7o9TO27eQHlm+fryJD 8HFpz7T9piN7pgGc/5Kca6AWlMHjv9Qnxnky4vqUJ0K0fliJkLKX0lei5woA5VYJ8ZugV1 GxwN1/7zy9giKUjXvimd6MxbaEUXah5pL2em4GWCbLfoNAnqubCMyCUW7Zujw5xd+xpw+H nYE30kXUvlIHsz0iT02O+Wuz1TRJmtWL0XSHpTxXKAKcUzCl1gJq03ltD2WdQkYTvb4XVH cCKi2lIaxVWdoboU+1CGgs0nJKkxzLtToBs4Is+AUXxx7n2T7mXOWkTFIXLJBQ== Received: from freyja (p4fc0ad29.dip0.t-ipconnect.de [79.192.173.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 04BDE10A1E88 for ; Tue, 19 Apr 2022 13:44:56 +0200 (CEST) Date: Tue, 19 Apr 2022 13:44:55 +0200 From: FreeBSD User To: freebsd-current Subject: 13-STABLE: can not cross build 13.0-RELENG and 13.1-RELENG, what on CURRENT works fine Message-ID: <20220419134455.1208de31@freyja> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: eed2b5 X-Rspamd-UID: e8d425 X-Rspamd-Queue-Id: 4KjMRm1x4xz3kxP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=aSPfUepq; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:30) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-0.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; RECEIVED_SPAMHAUS_PBL(0.00)[79.192.173.41:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt-de.de]; NEURAL_SPAM_MEDIUM(0.94)[0.941]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_HAM_SHORT(-0.95)[-0.946]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from] X-ThisMailContainsUnwantedMimeParts: N I regular build for a NanoBSD appliance 13-STABLE, 13.0-RELENG and 13.1-RELENG on either 14-CURRENT and 13-STABLE. Several days ago, some changes has been made to /usr/src/Makefile.inc1, first on CURRENT and shortly after on 13. As with today, building from sources either 13.1-RELENG and 13.0-RELENG on a CURRENT host (recent 14-CURRENT!) works without problems. On 13-STABLE (FreeBSD 13.1-STABLE #26 stable/13-n250478-bb8e1dfbff3: Thu Apr 14 10:47:51 CEST 2022 amd64) building either 13.0-RELENG or 13.1-RELENG fails! On building from sources 13.0-RELENG I receive while in installworld: [...] -------------------------------------------------------------- >>> Install check world -------------------------------------------------------------- mkdir -p /tmp/install.6R4Ifq8o ... cp: [vdso]: No such file or directory *** Error code 1 [...] and on building from sources 13.1-RELENG while in installworld we get: [...] ===> usr.bin/lex/lib (install) install -l h -o root -g wheel -m 444 /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/lib ln_p.a /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a install: link /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libln_p.a -> /home/ohartman n/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a: No such file or directory *** Error code 71 Thanks in advance, O. Hartmann From nobody Tue Apr 19 11:46:03 2022 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 F083911DE4CF for ; Tue, 19 Apr 2022 11:46:09 +0000 (UTC) (envelope-from 0100018041a4d46f-daec909d-8000-48e9-9259-5df61416a9dc-000000@amazonses.com) Received: from a48-102.smtp-out.amazonses.com (a48-102.smtp-out.amazonses.com [54.240.48.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjMSx2x6Xz3llD for ; Tue, 19 Apr 2022 11:46:09 +0000 (UTC) (envelope-from 0100018041a4d46f-daec909d-8000-48e9-9259-5df61416a9dc-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1650368763; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=xZN+JJOHColLTCnm5DW+jJonoJClWexQM/A4zkFbAVo=; b=AsNd+rvRBfhhzQ/lH0N4ag+YZJ+DiT98wGg5SLgc9k8MUiPfjUF3+itCRNla4mSb Ekp8nbz5F13D5gNDV/rHasWOddDTNGS1TvNsC6bjTNm34z1t4I5oUkPzQ/gmM6GeD5T A+5HaDUfiVSVKXbmoXoSteQ3i2RX99X+s6iehEnA= Message-ID: <0100018041a4d46f-daec909d-8000-48e9-9259-5df61416a9dc-000000@email.amazonses.com> Date: Tue, 19 Apr 2022 11:46:03 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <093ec3cb-32a1-e316-a369-3a9e8559248a@blastwave.org> From: Thomas Laus In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES X-SES-Outgoing: 2022.04.19-54.240.48.102 X-Rspamd-Queue-Id: 4KjMSx2x6Xz3llD X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=AsNd+rvR; dmarc=none; spf=pass (mx1.freebsd.org: domain of 0100018041a4d46f-daec909d-8000-48e9-9259-5df61416a9dc-000000@amazonses.com designates 54.240.48.102 as permitted sender) smtp.mailfrom=0100018041a4d46f-daec909d-8000-48e9-9259-5df61416a9dc-000000@amazonses.com X-Spamd-Result: default: False [1.63 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18:c]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[acm.org]; NEURAL_SPAM_MEDIUM(0.82)[0.816]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.49)[-0.486]; DKIM_TRACE(0.00)[amazonses.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[54.240.48.102:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[lausts@acm.org,0100018041a4d46f-daec909d-8000-48e9-9259-5df61416a9dc-000000@amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[54.240.48.102:from]; ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,0100018041a4d46f-daec909d-8000-48e9-9259-5df61416a9dc-000000@amazonses.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 4/18/22 21:43, Graham Perrin wrote: > On 12/04/2022 23:35, Dennis Clarke wrote: >> … at least two examples in the wild. … > > Not the same symptom, but > caught my eye: > >> RC3 Guided ZFS on root with encryption unmountable > > Beyond that, I have nothing useful to add (sorry). I do not get the "no > pools available to import" symptom with any of the boot environments > listed below (Git hash within the name of each BE). > Thanks for the link. I agree that there is something unexpected happening recently with booting a ZFS filesystem using EFI. I noticed that my system still flashes a "no pools available to import" message when using a MBR boot record at the same point that EFI boot just hangs but the booting process will complete soon afterward. Putting EFI boot back on that ada0p1 partition hangs at the same point again. I am fortunate that both systems can use either EFI or MBR boot records. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From nobody Tue Apr 19 12:48:04 2022 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 93C8211D1588 for ; Tue, 19 Apr 2022 12:48:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjNrc1XcSz4V0F for ; Tue, 19 Apr 2022 12:48:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe32.google.com with SMTP id a127so15475919vsa.3 for ; Tue, 19 Apr 2022 05:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nLq8Zng/pZh84cnYmrAOfWHnPtKFKGucDh3rZioYkEw=; b=xEpbkkOXuFacok8sbidaO6gEJ57FBtQo1S/4nfRr7B8h9jA9Onk7bIZ/8mTfs03xjP NObfubTsiUDUHhrCu0i35/m8v0kSCh8ovI/TfY2NNcQZKRyuL4eU22FhlB49/6F/iKad a/nHXRPvXwLqaw38qoXwrXMMOanrGCRhJEfEB+MJGXimrHeu1M8QIFYDvv6dIbFNc2/6 Zjt2saKDBsvT4NFWUqhqNA0d3kwzaEWvEfYR6t3loJSikeKDPbuBk6NZhpbYbcaVXkkk wge581kUX9iDMxrbvOMoTpcfy47WHIi5SuFzfczm37sh2nVQd9KdAvMbP5xUD8gj69e6 k1Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nLq8Zng/pZh84cnYmrAOfWHnPtKFKGucDh3rZioYkEw=; b=h6a3xMTCT8ahCF6g7UYbvbBUzTWhOX9nIbMH4BC/BImErTfelujjLsG8Nn6aC5+U3i DMO9m2JmP3Qt+Ri1YPRYEWuoGzIKcTWqqCNbN+vOV1BMJ82h+DkJ6m9jQICDMioGjf+3 eizyRku5r2co2N4D9fUPdyjhbGN43esSkPkWlA2dB8zksRl4Zl1o4dDZY25RMk5K/AwJ Snz8jgv3Oedx3PaDEBZlEXAzV472er09It/OMEyFKMOEijgS+/kagdxH7xz6u4hGo2xE y5g1qKJeRSY93+DtSllRdkDZRN2ALtu2TqIXYI4bt1Kvp6+aZvBwajPcEYqwheRz7tKz 4BFg== X-Gm-Message-State: AOAM531H3JFl0p5hxaB7UiY87zxepG8Gg0hGRSaZNNMv25g+aAo491In CXIwgYZuyRa358w8puBB45GHjDthH9sw4TXmk7/2mFdCGcZCYQ== X-Google-Smtp-Source: ABdhPJzAx726A2bfqNTa8fmmVSHrGrvcanxmSR4eu8fO2dduulw+l7hoq52KX4MnV1w8xCmTv9Ro9LAtZgbrdFC6fu8= X-Received: by 2002:a05:6102:956:b0:32a:6820:36bf with SMTP id a22-20020a056102095600b0032a682036bfmr1401533vsi.42.1650372495357; Tue, 19 Apr 2022 05:48:15 -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: <20220419134455.1208de31@freyja> In-Reply-To: <20220419134455.1208de31@freyja> From: Warner Losh Date: Tue, 19 Apr 2022 06:48:04 -0600 Message-ID: Subject: Re: 13-STABLE: can not cross build 13.0-RELENG and 13.1-RELENG, what on CURRENT works fine To: FreeBSD User Cc: freebsd-current Content-Type: multipart/alternative; boundary="000000000000554d9405dd014a29" X-Rspamd-Queue-Id: 4KjNrc1XcSz4V0F X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=xEpbkkOX; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e32) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.05 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.95)[0.950]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e32:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000554d9405dd014a29 Content-Type: text/plain; charset="UTF-8" The vdso error is fixed by cherry-picking b3b462229f972e2ed24d450d7d2f8855cdd58a87. I'm not sure about the second error, though if it's a general profile error, you make need WITHOUT_PROFILE=t in both the build and install phases. On Tue, Apr 19, 2022 at 5:46 AM FreeBSD User wrote: > I regular build for a NanoBSD appliance 13-STABLE, 13.0-RELENG and > 13.1-RELENG > on either 14-CURRENT and 13-STABLE. Several days ago, some changes has been > made to /usr/src/Makefile.inc1, first on CURRENT and shortly after on 13. > > As with today, building from sources either 13.1-RELENG and 13.0-RELENG on > a > CURRENT host (recent 14-CURRENT!) works without problems. > > On 13-STABLE (FreeBSD 13.1-STABLE #26 stable/13-n250478-bb8e1dfbff3: Thu > Apr 14 > 10:47:51 CEST 2022 amd64) building either 13.0-RELENG or 13.1-RELENG fails! > > On building from sources 13.0-RELENG I receive while in installworld: > > [...] > -------------------------------------------------------------- > >>> Install check world > -------------------------------------------------------------- > mkdir -p /tmp/install.6R4Ifq8o > ... > cp: [vdso]: No such file or directory > *** Error code 1 > [...] > > and on building from sources 13.1-RELENG while in installworld we get: > > [...] > ===> usr.bin/lex/lib (install) > install -l h -o root -g wheel -m 444 > > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/lib > ln_p.a > > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a > install: link > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libln_p.a > -> /home/ohartman > > n/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a: > No such file or directory > *** Error code 71 > > > Thanks in advance, > > O. Hartmann > > --000000000000554d9405dd014a29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The vdso error is fixed by cherry-picking b3b462229f972e2e= d24d450d7d2f8855cdd58a87.
I'm not sure about the second error, thou= gh if it's a general profile error, you make need WITHOUT_PROFILE=3Dt i= n both the build and install phases.


On Tue, Apr 19, 20= 22 at 5:46 AM FreeBSD User <fr= eebsd@walstatt-de.de> wrote:
I regular build for a NanoBSD appliance 13-STABLE, 13.0= -RELENG and 13.1-RELENG
on either 14-CURRENT and 13-STABLE. Several days ago, some changes has been=
made to /usr/src/Makefile.inc1, first on CURRENT and shortly after on 13.
As with today, building from sources either 13.1-RELENG and 13.0-RELENG on = a
CURRENT host (recent 14-CURRENT!) works without problems.

On 13-STABLE (FreeBSD 13.1-STABLE #26 stable/13-n250478-bb8e1dfbff3: Thu Ap= r 14
10:47:51 CEST 2022 amd64) building either 13.0-RELENG or 13.1-RELENG fails!=

On building from sources 13.0-RELENG I receive while in installworld:

[...]
--------------------------------------------------------------
>>> Install check world
--------------------------------------------------------------
mkdir -p /tmp/install.6R4Ifq8o
...
cp: [vdso]: No such file or directory
*** Error code 1
[...]

and on building from sources 13.1-RELENG while in installworld we get:

[...]
=3D=3D=3D> usr.bin/lex/lib (install)
install -l h -o root -g wheel -m 444
/home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/a= md64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/lib
ln_p.a
/home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/a= md64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a
install: link
/home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/a= md64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libln_p.a -> /home/ohartman<= br> n/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-= amd64-13.1-RELENG/_.w/usr/lib/libl_p.a:
No such file or directory
*** Error code 71


Thanks in advance,

O. Hartmann

--000000000000554d9405dd014a29-- From nobody Tue Apr 19 15:58:55 2022 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 6118911E15E1 for ; Tue, 19 Apr 2022 15:58:58 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91]) by mx1.freebsd.org (Postfix) with ESMTP id 4KjT4d3Jtkz3LPj for ; Tue, 19 Apr 2022 15:58:57 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) IronPort-SDR: rvQfQcey05edcGJmoCb1FSGrFSRxPLsLOmQgq3B2KREXes4rq0csK3G8xUP6FWjAr9WqcwxIeF IwaaRW2uSkHlxH1bzCKQNTKsqAjgYxTow= X-Ambrisko-Me: Yes IronPort-Data: A9a23:CBezz6iaoIBSidOlK8i877ydX161HRAKZh0ujC45NGQN5FlHY01je htvXzzQOP2DYzCnLtkgPIng908FvcPRmt41Tgo/+Hg2F3lH+JHPbTi7wuccHM8zwunrFh8PA /3z5rAsFehsJpPmjk7F3oXJ9hGQ64nZH9IQN8aUYkiddSc8IMsQoUoLd9wR2+aEsvDla++5g u4eluWEULOTN56YBUpPg06LgEsHUP0fI1r0tHRmDRxAlAe2e3X4kPvzjExsRkYUTLW4HsbiL wrC5LC/4m7D+R4pTNqgmKz6aU4NBLXVOGBiiFIPCvLk20YS4HV0iM7XN9JEAatTozyMlcpw0 9ZKnZW1Qx0oJa7L3u8aVnG0FgkjZPcepeavzX+X9Jb7I1f9W37uzOh8DUIeMogR++IxCmZLn dQWMj0AZAuPwumr2qi2TPVEiN4uIcPwMMUYoH4I8N1zJZ7KWrjYTr/U6MUCmj41jNpPBvXZI cEebFJSgN37S0UnEj8q5FgWxY9EX1HzLG9Vrky7v60y7zSBxQB9yuK0YtPQcMaLXsZStk+dr HjH5Gf+RBodMYXHmzaC93utgM7JnD/6CN9KTezkrqYyjQ3B3HEXBT0XSUC//auzhHmhVo8NM EcT4Ccv8/Q/rRT5UtnnUhSki3eYpRpACcFIGug35VjVmKrZ6gqUHEYeSTtFZIB0vcM6X2Zzh FaMlcnoHj9omLSQQ2ic7bST6zi1PHFNf2MFYCYFSyoD4sXi8Nxr10OTFo47Hffs3NPvGDz2z zSblwQEhu0e3ZwRyqG23VHbmDbw9JLHeRE4u1fMVWW/4wInOIP8P9606ULW5OprJZqCSgXTp 2ANnsWT4bxcDZyJkyDREuwBEKvzvqSENiHRm1hmG98o8j63+mWgesZb5zQnfBVlNcMNeDnIZ k7PuFMMvMYCYCPyNaInMZisD8kKzLT7EYW3X//ZWdNCf5xteVLV5yppf0ORgzjgnRR+i605I pvHI8+gAWxAUfZ8wSCoSv1Hl7YuzDo/3mDUA5v8yk3/g7aZYXeUT5YDMUePPr1htfLY+F2N/ oYNLdaOxjVeTPb6M3ve/oMkJFwXKWQ2WMLtoMtNe+/fegdrFQnN0RMKLW/Nr2C9o5loqw== IronPort-HdrOrdr: A9a23:+rxhbKnRsqaVOjjalBWVhgicCjPpDfIs3DAbv31ZSRFFG/FwWf rOoB0+726StN9xYgBFpTnuAsW9qB/nmqKdpLNhW4tKPzOW3VdATrsSjrcKqgeIc0aSygce79 YDT0EUMr3N5DZB4/oT0GODeeod/A== Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 19 Apr 2022 07:55:34 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 23JFwt6T080302 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 19 Apr 2022 08:58:55 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com Received: (from ambrisko@localhost) by ambrisko.com (8.17.1/8.17.1/Submit) id 23JFwtAo080301; Tue, 19 Apr 2022 08:58:55 -0700 (PDT) (envelope-from ambrisko) Date: Tue, 19 Apr 2022 08:58:55 -0700 From: Doug Ambrisko To: Mateusz Guzik Cc: freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KjT4d3Jtkz3LPj X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[ambrisko]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[ambrisko.com]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Apr 19, 2022 at 11:47:22AM +0200, Mateusz Guzik wrote: | Try this: https://people.freebsd.org/~mjg/vnlru_free_pick.diff | | this is not committable but should validate whether it works fine As a POC it's working. I see the vnode count for the nullfs and ZFS go up. The ARC cache also goes up until it exceeds the ARC max. size tten the vnodes for nullfs and ZFS goes down. The ARC cache goes down as well. This all repeats over and over. The systems seems healthy. No excessive running of arc_prune or arc_evict. My only comment is that the vnode freeing seems a bit agressive. Going from ~15,000 to ~200 vnode for nullfs and the same for ZFS. The ARC drops from 70M to 7M (max is set at 64M) for this unit test. Thanks, Doug A. | On 4/19/22, Mateusz Guzik wrote: | > On 4/19/22, Mateusz Guzik wrote: | >> On 4/19/22, Doug Ambrisko wrote: | >>> I've switched my laptop to use nullfs and ZFS. Previously, I used | >>> localhost NFS mounts instead of nullfs when nullfs would complain | >>> that it couldn't mount. Since that check has been removed, I've | >>> switched to nullfs only. However, every so often my laptop would | >>> get slow and the the ARC evict and prune thread would consume two | >>> cores 100% until I rebooted. I had a 1G max. ARC and have increased | >>> it to 2G now. Looking into this has uncovered some issues: | >>> - nullfs would prevent vnlru_free_vfsops from doing anything | >>> when called from ZFS arc_prune_task | >>> - nullfs would hang onto a bunch of vnodes unless mounted with | >>> nocache | >>> - nullfs and nocache would break untar. This has been fixed now. | >>> | >>> With nullfs, nocache and settings max vnodes to a low number I can | >>> keep the ARC around the max. without evict and prune consuming | >>> 100% of 2 cores. This doesn't seem like the best solution but it | >>> better then when the ARC starts spinning. | >>> | >>> Looking into this issue with bhyve and a md drive for testing I create | >>> a brand new zpool mounted as /test and then nullfs mount /test to /mnt. | >>> I loop through untaring the Linux kernel into the nullfs mount, rm -rf | >>> it | >>> and repeat. I set the ARC to the smallest value I can. Untarring the | >>> Linux kernel was enough to get the ARC evict and prune to spin since | >>> they couldn't evict/prune anything. | >>> | >>> Looking at vnlru_free_vfsops called from ZFS arc_prune_task I see it | >>> static int | >>> vnlru_free_impl(int count, struct vfsops *mnt_op, struct vnode *mvp) | >>> { | >>> ... | >>> | >>> for (;;) { | >>> ... | >>> vp = TAILQ_NEXT(vp, v_vnodelist); | >>> ... | >>> | >>> /* | >>> * Don't recycle if our vnode is from different type | >>> * of mount point. Note that mp is type-safe, the | >>> * check does not reach unmapped address even if | >>> * vnode is reclaimed. | >>> */ | >>> if (mnt_op != NULL && (mp = vp->v_mount) != NULL && | >>> mp->mnt_op != mnt_op) { | >>> continue; | >>> } | >>> ... | >>> | >>> The vp ends up being the nulfs mount and then hits the continue | >>> even though the passed in mvp is on ZFS. If I do a hack to | >>> comment out the continue then I see the ARC, nullfs vnodes and | >>> ZFS vnodes grow. When the ARC calls arc_prune_task that calls | >>> vnlru_free_vfsops and now the vnodes go down for nullfs and ZFS. | >>> The ARC cache usage also goes down. Then they increase again until | >>> the ARC gets full and then they go down again. So with this hack | >>> I don't need nocache passed to nullfs and I don't need to limit | >>> the max vnodes. Doing multiple untars in parallel over and over | >>> doesn't seem to cause any issues for this test. I'm not saying | >>> commenting out continue is the fix but a simple POC test. | >>> | >> | >> I don't see an easy way to say "this is a nullfs vnode holding onto a | >> zfs vnode". Perhaps the routine can be extrended with issuing a nullfs | >> callback, if the module is loaded. | >> | >> In the meantime I think a good enough(tm) fix would be to check that | >> nothing was freed and fallback to good old regular clean up without | >> filtering by vfsops. This would be very similar to what you are doing | >> with your hack. | >> | > | > Now that I wrote this perhaps an acceptable hack would be to extend | > struct mount with a pointer to "lower layer" mount (if any) and patch | > the vfsops check to also look there. | > | >> | >>> It appears that when ZFS is asking for cached vnodes to be | >>> free'd nullfs also needs to free some up as well so that | >>> they are free'd on the VFS level. It seems that vnlru_free_impl | >>> should allow some of the related nullfs vnodes to be free'd so | >>> the ZFS ones can be free'd and reduce the size of the ARC. | >>> | >>> BTW, I also hacked the kernel and mount to show the vnodes used | >>> per mount ie. mount -v: | >>> test on /test (zfs, NFS exported, local, nfsv4acls, fsid | >>> 2b23b2a1de21ed66, | >>> vnodes: count 13846 lazy 0) | >>> /test on /mnt (nullfs, NFS exported, local, nfsv4acls, fsid | >>> 11ff002929000000, vnodes: count 13846 lazy 0) | >>> | >>> Now I can easily see how the vnodes are used without going into ddb. | >>> On my laptop I have various vnet jails and nullfs mount my homedir into | >>> them so pretty much everything goes through nullfs to ZFS. I'm limping | >>> along with the nullfs nocache and small number of vnodes but it would be | >>> nice to not need that. | >>> | >>> Thanks, | >>> | >>> Doug A. | >>> | >>> | >> | >> | >> -- | >> Mateusz Guzik | >> | > | > | > -- | > Mateusz Guzik | > | | | -- | Mateusz Guzik From nobody Tue Apr 19 16:02:04 2022 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 2A25711E233E for ; Tue, 19 Apr 2022 16:02:19 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (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 4KjT8T60Mdz3Mgk for ; Tue, 19 Apr 2022 16:02:17 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 70B8C45537; Tue, 19 Apr 2022 12:02:05 -0400 (EDT) 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 \(3696.80.82.1.1\)) Subject: Re: advice sought: workflow with -CURRENT and amd GPU [Re: -CURRENT hangs since at least 2022-04-04] From: Paul Mather In-Reply-To: Date: Tue, 19 Apr 2022 12:02:04 -0400 Cc: Michael Schuster Content-Transfer-Encoding: quoted-printable Message-Id: References: <0c1b4885-dd0f-b48f-2ffe-12ccfd2ec118@filis.org> <3b85072c-eb07-6a74-fae3-258c99756c11@nomadlogic.org> To: FreeBSD CURRENT X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4KjT8T60Mdz3Mgk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none); spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 2001:468:c80:a103:2:5000:5555:5555) smtp.mailfrom=paul@gromit.dlib.vt.edu X-Spamd-Result: default: False [-2.18 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none]; FREEFALL_USER(0.00)[paul]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.99)[-0.989]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.958]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.73)[-0.730]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Apr 19, 2022, at 4:49 AM, Michael Schuster = wrote: > Hi, >=20 > I'm highjacking and re-purposing the previous thread, I hope that's OK > (I did change the subject ;-)) - I'm keeping some of the previous > contents for reference. >=20 > I have similar HW to OP (Ryzen 7 4700 w. Renoir Graphics), and have > been using a similar approach to keep the machine up to date - or so I > suspect. Still, after a while (several months), I end up with one or > more of these: > - I get some sort of panic in DRM (at startup or, currently, at = shutdown) > - when I boot into to a previous BE to attempt a fix and then again > reboot into the current one, I get tons of messages like this > "... kernel: KLD iic.ko: depends on kernel - not available or > version mismatch > ... kernel: linker_load_file: /boot/kernel/iic.ko - unsupported = file type" > and computer refuses to accept input (let alone start X) >=20 > and some others I don't recall right now. >=20 > Before I ask for advice (see below), let me explain the approaches > I've taken so far. I install with ZFS from the beginning, current boot > env is "N". These are outlines, not exact commands: >=20 > I) never touch the current BE, always update a new one: > 1) given current BE N, I create a new BE N+1 and mount it on /mnt, > 2) 'cd /usr/src; git pull; sudo make DESTDIR=3D/mnt ... (build, = install, etc)' > 3) 'cd usr/ports/graphics/drm-devel-kmod; sudo make DESTDIR=3D/mnt = install' > 4) beadm activate BE N+1; reboot >=20 > II) keep a "new" BE as backup/fallback, update current BE: > 1) given current BE N, I create a new BE N+1 (mounting not required) > (this is the intended 'fallback') > 2) 'cd /usr/src; git pull"; then "make" as described in the Handbook > "24.6. Updating FreeBSD from Source" > 3) 'cd usr/ports/graphics/drm-devel-kmod; sudo make install' > 4) reboot >=20 > in both scenarios(sp?), I do "pkg update; pkg upgrade" from time to > time (also following the resp. approach shown above). >=20 > I suspect that I'm missing something fundamental in my approaches - > does anyone have a (for them) foolproof approach along these lines, or > can someone show me what I'm missing in either of mine (in private, if > you prefer)? I don't know whether you're missing anything, but I wanted to mention I recently found a tool useful in helping my own BE-based source upgrades: /usr/src/tools/build/beinstall.sh I've found it helps with the build/upgrade steps. See man beinstall(8) for details. Cheers, Paul. From nobody Tue Apr 19 18:32:32 2022 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 5B29F11E0613; Tue, 19 Apr 2022 18:32:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjXV05wQ0z4WSC; Tue, 19 Apr 2022 18:32:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 23JIWWIh001473 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 19 Apr 2022 11:32:32 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 23JIWWH8001472; Tue, 19 Apr 2022 11:32:32 -0700 (PDT) (envelope-from sgk) Date: Tue, 19 Apr 2022 11:32:32 -0700 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Daily black screen of death Message-ID: Reply-To: sgk@troutmask.apl.washington.edu List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4KjXV05wQ0z4WSC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.03 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.982]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(0.95)[0.955]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-x11]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N FYI, I'm experiencing an almost daily black screen of death panic. Kernel, world, drm-current-kmod, and gpu-firmware-kmod were all rebuilt and installed at the same time. Uname shows FreeBSD 14.0-CURRENT #0 main-n254360-eb9d205fa69: Tue Apr 5 13:49:47 PDT 2022 So, April 5th sources. The panic results in a keyboard lock and no dump. The system does not have a serial console. Only recourse is a hard rest. Hand transcribed from photo _sleep() at _sleep+0x38a/frame 0xfffffe012b7c0680 buf_daemon_shutdown() at buf_daemon_shutdown+0x6b/frame 0xfffffe012b7c06a0 kern_reboot() at kern_reboot+0x2ae/frame 0xfffffe012b7c06e0 vpanic() at vpanic+0x1ee/frame 0xfffffe012b7c0730 panic() at panic+0x43/frame 0xfffffe012b7c0790 Above repeats 100s of time scrolling off the screen with ever increasing frame pointer. Final message, mi_switch() at mi_switch+0x18e/frame 0xfffffe012b7c14b0 __mtx_lock_sleep() at __mtx_lock_sleep+0x173/frame 0xfffffe012b7c1510 __mtx_lock_flags() at __mtx_lock_flags+0xc0/frame 0xfffffe012b7c1550 linux_wake_up() at linux_wake_up+0x38/frame 0xfffffe012b7c15a0 radeon_fence_is_signaled() at radeon_fence_is_signaled+0x99/frame 0xfffffe012b7c15f0 dma_resv_add_shared_fence() at dma_resv_add_shared_fence+0x99/frame 0xfffffe012b7c1640 ttm_eu_fence_buffer_objects() at ttm_eu_fence_buffer_objects+0x79/frame 0xfffffe012b7c1680 radeon_cs_parser_fini() at radeon_cs_parser_fini+0x53/frame 0xfffffe012b7c16b0 radeaon_cs_ioctl() at radeaon_cs_ioctl+0x75e/frame 0xfffffe012b7c1b30 drm_ioctl_kernel() at drm_ioctl_kernel+0xc7/frame 0xfffffe012b7c1b80 drm_ioctl() at drm_ioctl+0x2c3/frame 0xfffffe012b7c1c70 linux_file_ioctl() at linux_file_ioctl+0x309/frame 0xfffffe012b7c1cd0 kern_ioctl() at kern_ioctl+0x1dc/frame 0xfffffe012b7c1d40 sys_ioctl() at sys_ioctl+0x121/frame 0xfffffe012b7c1e10 amd64_syscall() at amd64_syscall+0x108/frame 0xfffffe012b7c1f30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe012b7c1f30 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x36a096c34ea, rsp = 0x3fa11e623eb8, \ rbp = 0x3fa11e623ee0 --- panic: _sleep: curthread not running cpuid = 4 time = 1650389478 KDB: stack backtrace: One common trigger appears to be the use of firefox-99.0,2 from the ports collection. -- Steve From nobody Tue Apr 19 22:37:52 2022 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 8EECE11CA505 for ; Tue, 19 Apr 2022 22:38:25 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjdxX5sZdz3N3k for ; Tue, 19 Apr 2022 22:38:24 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x335.google.com with SMTP id ay36-20020a05600c1e2400b0038ebc885115so1527866wmb.1 for ; Tue, 19 Apr 2022 15:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:to:content-language:from :subject:content-transfer-encoding; bh=p7aiBzaHQaUwn6e9OPAFyJBG6yNY7JCExY7RYKgfAnM=; b=Lip2rAnzE+JJdkv0bJNlziCvMqWos3Lp5wKYaA37nxLuno/+B3U6RGpWnAdH2JhWf/ BzNdVU6x4q6m9q4pqWck/pfvDJwfJl1EJM3uT8Lsva3W6P9pSIF9LskrYMnrDhsshZ8p uI6GWMGT2HOLt2ut2hYBVQxerG4+ALH0UV6rb1k/qneL1s+UXk5wwJoDTzU9yFE7N7c4 9jgrDvWjLbn5jxlCeB2LjyCbym1hTUg88co7m0TXmE3n+XeDDTZcVaBvqdoraij+W2oC 12e1EMDIbrMDKLiWVGUlvTRBQ+22fu+dXMKx96LR/fQEPH8krxvQrXlPFETjUrveoBWK K5Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to :content-language:from:subject:content-transfer-encoding; bh=p7aiBzaHQaUwn6e9OPAFyJBG6yNY7JCExY7RYKgfAnM=; b=O7yMwO+iUUyMy/AUw9H3LB89jvgWCin8sPUAE3mvgAkuaY/LVCjDyzJ9DfzmJ3K/Pq y1NR6OWY41Ch+PaNvkeekm/OADYdre4D0YB6CyYR4K4LxeYMlK7ful+i52vUipUT6JZm +fdH9FhzwjPokJMkZ1dT90RYp/fEDGxlG8nODS1mGBDIkNodG19S9i11etzG0qrCev6P ijOuUHfoAib1FGkoyanBq9FpUVEGhOETZmRRTxK3Oa02T08FeIANiVAV0wR32iuauoYX itvWk2IwDJ3Rt5bU/cOeZkHCHmrcwvF50w1ks9HpmdlN2CSe1rNDosdZH2BBDxgj9KRz k5AA== X-Gm-Message-State: AOAM532U/0SIXBqBP2r582N/iCkTYi4a6/O6lr4AkJcBQs8UZu6Xh/RB tcs6CkEy/+b9jFHTVIylbO92a2mvY/sfZg== X-Google-Smtp-Source: ABdhPJzowDgKtySuJM8PIaiGK7Y7S0QADI3zyxkoyoIQBM6YIUSRqUD9BlXIcW/EiaROh0TgZOsqtg== X-Received: by 2002:a7b:ce84:0:b0:37c:52fe:a3ff with SMTP id q4-20020a7bce84000000b0037c52fea3ffmr696243wmj.48.1650407896266; Tue, 19 Apr 2022 15:38:16 -0700 (PDT) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id k65-20020a1ca144000000b003929a64ab63sm5822683wme.38.2022.04.19.15.38.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Apr 2022 15:38:15 -0700 (PDT) Message-ID: Date: Tue, 19 Apr 2022 23:37:52 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 To: FreeBSD-CURRENT Content-Language: en-GB From: Graham Perrin Subject: EFI framebuffer information, then nothing Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KjdxX5sZdz3N3k X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Lip2rAnz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::335 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.38 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.977]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.40)[-0.402]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::335:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Sometimes, boot gets no further than EFI framebuffer information. Whenever this occurs, the computer will stop immediately in response to a simple, short press on the power button. The two lines preceding framebuffer information (copy typed from a photograph): staging 0xadc00000 (not copying) tramp 0xbecfe000 PT4 0xbecf5000 Start @ 0xffffffff80389000 ... I can not make the issue consistently reproducible. Originally, it seemed that the minority of boots were bugged. For a while, probably more than a week, the majority of boots were bugged (sometimes five or more successive failures). More recently, again, the minority of boots are bugged. There's a strong sense of randomness, so I can not be certain that e.g. safe mode is a workaround. At least once, boot failed whilst the notebook was un-docked and completely without peripherals. Should I suspect any of the modules indicated below? % cat /boot/loader.conf | grep -v \# | sort | tr -s '\n' acpi_dock_load="YES" acpi_hp_load="YES" aesni_load="YES" autofs_load="YES" beastie_disable="NO" boot_mute="NO" boot_verbose="NO" cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" cuse_load="YES" efi_max_resolution="1600x900" geom_eli_load="YES" hw.pci.do_power_nodriver=3 hw.usb.no_boot_wait=0 kern.geom.label.disk_ident.enable="0" kern.geom.label.gptid.enable="0" kern.racct.enable=1 openzfs_load="NO" screen.font="8x16" sysctlbyname_improved_load="YES" sysctlinfo_load="YES" vboxdrv_load="YES" verbose_loading="NO" zfs_load="YES" % HP EliteBook 8570p, probed a few minutes ago: GELI encryption: % lsblk ada0 DEVICE        MAJ:MIN SIZE TYPE                 LABEL MOUNT ada0            0:119 932G GPT                      - -   ada0p1        0:121 260M efi           gpt/efiboot0 -           -:-   1.0M -                        - -   ada0p2        0:123  16G freebsd-swap     gpt/swap0 SWAP   ada0p2.eli    2:52   16G freebsd-swap             - SWAP   ada0p3        0:125 915G freebsd-zfs       gpt/zfs0   ada0p3.eli    0:131 915G -                        - -           -:-   708K -                        - - % Three photographs, the first of which is barely readable (sorry): (2022-02-18 21:31) (2022-03-18 15:44) (2022-04-17 18:58) From nobody Wed Apr 20 09:39:44 2022 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 8BF5B13A29A6 for ; Wed, 20 Apr 2022 09:40:19 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjwdG5Sx0z3tTt for ; Wed, 20 Apr 2022 09:40:18 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id D5DD42B5CE; Wed, 20 Apr 2022 11:40:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1650447604; 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; bh=Cv9rEmaYRV1ISY0hYc6816JsEU3941z19vP14F5Ttok=; b=c6ynwquDcT+cybKHb/RrIt2hxRXFEG5G8GZh3EmPeE9J9OdSS6MgTaDDhaSSGQYOkPmA/X S7bZEq7lQJ8T0X9DkmOGxwEkJhhtGezCsHVsjYileuAKbx2XGAE0FQOAkbHTQLd3t2qOB3 cERS/CNvBU6j014ihge0ueUUgYpvwRjStWagCWK+Pr2f3MQcwTy4YI9pD76uQWpiLHM0fr wk1IL5UfWAdI9bh0LybDw6CHQZ5PWhejnzUjfAXK6Dq2A8A6GjoGsW1JsXx/7nPOxe+qKx pY+A+2KI+hfbcYpdkEzO6zy4GbSJgRn6itJTafoaQySGfl2Wm5Aad+g5TrP1aQ== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id A693B3500; Wed, 20 Apr 2022 11:39:45 +0200 (CEST) Date: Wed, 20 Apr 2022 11:39:44 +0200 Message-ID: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> From: Alexander Leidinger To: Doug Ambrisko Cc: freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_x31BCKaWYbJuSbu6hHJ4cxa"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4KjwdG5Sx0z3tTt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=c6ynwquD; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-4.09 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_x31BCKaWYbJuSbu6hHJ4cxa Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Doug Ambrisko (from Mon, 18 Apr 2022=20=20 16:32:38=20-0700): > With nullfs, nocache and settings max vnodes to a low number I can Where is nocache documented? I don't see it in mount_nullfs(8),=20=20 mount(8)=20or nullfs(5). I tried a nullfs mount with nocache and it doesn't show up in the=20=20 output=20of "mount". Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_x31BCKaWYbJuSbu6hHJ4cxa Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJf1N8ACgkQEg2wmwP4 2Ib4vRAAg/ACjDbSe3rAS0OpMGSECxVSNuDIZgEMJ91mnWs8Xp0sHkimDqLCXbxJ P3yJX0jgqyvREcBUAM24vJ5sa3zL2TKoJGRE48rhodh+hDKJlsX7FtCADiYoBFPB 1zHij+YojmBAi9UFNSjBbL+1uKQnpkkQWZ5hzVcb0YIrPGk11rfnDTFip2JLvpPv zpPDyO5Hbi/V0LiPasdUG0il5BUeO9OAaQXAKvknSduLIMlozaHKsp1e5+y2crTB 8/HG3SnJhMqwlpUmG5JYSK2CDCSb/+YtPmgJBleMgBX4kPizTQXhAVoPC+UB+uwl 7Sd2SdGrE+1r5yuBmQBbojSOAvbzxXrYYLWR5zmNz6MjUywT7XdGcri7hk+VHHV0 DRbSHIHjODPnEmie+rqNkJlhHCTlB4/5d4Q8btxUa+9wZyWJANV6vck+KOsgJI5R M6p/5D+e4A51ikVGVehw7FwpRxnEySEyoGGdM9kp4HqrClTDjOpwdGL3qlLYcArD tZjR/zpKgIWsxPu92RyonNsrSs29opucfzDaI4KZvt465lhR0WCoFKgccCNnDf36 iHNdawOl5xgSuY93x45PVxAsNf+YldAT7qemR+fHgMtHMJdPKHSPHh0O687Xvp2g t1hFHz08VBouPTggMsGV1JbEeneOmKpX7+T/tbvgvp9Dl3UcXQA= =DNi+ -----END PGP SIGNATURE----- --=_x31BCKaWYbJuSbu6hHJ4cxa-- From nobody Wed Apr 20 09:43:10 2022 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 A95E813A3791 for ; Wed, 20 Apr 2022 09:43:13 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kjwhc74pkz3vhf for ; Wed, 20 Apr 2022 09:43:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lf1-x12a.google.com with SMTP id h27so1588954lfj.13 for ; Wed, 20 Apr 2022 02:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XuavJ3cmoR3Rorylh7hErg6tgMapT7o/OwnHl1VyB98=; b=CREUjbGoEEyGcMN27W/flD9roIzsWJUnzBdAo04DqE48hQ5IA49HuLFAjMODFW/AQ3 DbqMgp0P8cSQlvpddpEMROZvxr1ycyUZwnRqtMqthdOEgX9XZBFPmjhnTicCI2B/lfRl 7UyNovajDbTcCKSJ7Je2hgc/ZtuWExls32XQQh7EqxMPGQxuU3e6Bn75hTsx8mjW9wIZ ixJ/yZaIy32Dsk5naIPg+fLDdoi9OeWEwbcB+EJ9mwFJJFbHcg+UsHmkFIYSyCcznRJr P1Rdp4D/VIQa5Z5Tc88JFPfMGgNKZyHIeN3sp41FVagv84TQIDIQ2Vak4C4kgXHqqbW9 fO4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XuavJ3cmoR3Rorylh7hErg6tgMapT7o/OwnHl1VyB98=; b=xXnwK3bB439jOs+e1Fxk3iG85daJ6SyRkiYrqlqxw7qsVG1ov8CbfxdD70p3FeuAHO +9ukny9vMrcNtMhAbHx69GUhkSSfJwCj9PhZd0LCxc90IihUhN6cuFjyw9vxZi8Lxwzj cPMipuRi0DKU3kAeoRLuxnLLs/WdLVRwtEBkv954HZPWaUsut/UEFY1ysjxSBEWrT+GT f88SEqYTW/eJvM2LfWKIeLSTkLz30PtBPzLSJkoUoA3bVVB+eS7v8dCjvrpQtPAr8uad Ji0m6tO1xPyD1qVmAgqUXqwYJ6Q/IPZVvQ66SZD44/xOz9BhEqjIfFixJ9UEr8Kz9G0t tc+w== X-Gm-Message-State: AOAM53280NUgwhnbuPSvbKJpAkOflyhUCdlUEbvDJjliq1KBlKEAf+73 U9iD5cI+FDvG0e04Y72lym2VQwkqgxf1ZGvcY6eKB44c X-Google-Smtp-Source: ABdhPJxp+v5QNFEcP7s1Qd7jag0yw9taaZOfNFGyv+xqOj/t4x+olJdKtn84y63BEosf8JkPVQwaR0RPA9bDAEokURg= X-Received: by 2002:a05:651c:b0b:b0:24d:f050:2836 with SMTP id b11-20020a05651c0b0b00b0024df0502836mr1350865ljr.296.1650447791581; Wed, 20 Apr 2022 02:43:11 -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 Received: by 2002:a05:6520:6145:b0:1bb:7433:4cdd with HTTP; Wed, 20 Apr 2022 02:43:10 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Wed, 20 Apr 2022 11:43:10 +0200 Message-ID: Subject: Re: nullfs and ZFS issues To: Doug Ambrisko Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Kjwhc74pkz3vhf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=CREUjbGo; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12a:from]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 4/19/22, Doug Ambrisko wrote: > On Tue, Apr 19, 2022 at 11:47:22AM +0200, Mateusz Guzik wrote: > | Try this: https://people.freebsd.org/~mjg/vnlru_free_pick.diff > | > | this is not committable but should validate whether it works fine > > As a POC it's working. I see the vnode count for the nullfs and > ZFS go up. The ARC cache also goes up until it exceeds the ARC max. > size tten the vnodes for nullfs and ZFS goes down. The ARC cache goes > down as well. This all repeats over and over. The systems seems > healthy. No excessive running of arc_prune or arc_evict. > > My only comment is that the vnode freeing seems a bit agressive. > Going from ~15,000 to ~200 vnode for nullfs and the same for ZFS. > The ARC drops from 70M to 7M (max is set at 64M) for this unit > test. > Can you check what kind of shrinking is requested by arc to begin with? I imagine encountering a nullfs vnode may end up recycling 2 instead of 1, but even repeated a lot it does not explain the above. > > | On 4/19/22, Mateusz Guzik wrote: > | > On 4/19/22, Mateusz Guzik wrote: > | >> On 4/19/22, Doug Ambrisko wrote: > | >>> I've switched my laptop to use nullfs and ZFS. Previously, I used > | >>> localhost NFS mounts instead of nullfs when nullfs would complain > | >>> that it couldn't mount. Since that check has been removed, I've > | >>> switched to nullfs only. However, every so often my laptop would > | >>> get slow and the the ARC evict and prune thread would consume two > | >>> cores 100% until I rebooted. I had a 1G max. ARC and have increased > | >>> it to 2G now. Looking into this has uncovered some issues: > | >>> - nullfs would prevent vnlru_free_vfsops from doing anything > | >>> when called from ZFS arc_prune_task > | >>> - nullfs would hang onto a bunch of vnodes unless mounted with > | >>> nocache > | >>> - nullfs and nocache would break untar. This has been fixed > now. > | >>> > | >>> With nullfs, nocache and settings max vnodes to a low number I can > | >>> keep the ARC around the max. without evict and prune consuming > | >>> 100% of 2 cores. This doesn't seem like the best solution but it > | >>> better then when the ARC starts spinning. > | >>> > | >>> Looking into this issue with bhyve and a md drive for testing I > create > | >>> a brand new zpool mounted as /test and then nullfs mount /test to > /mnt. > | >>> I loop through untaring the Linux kernel into the nullfs mount, rm > -rf > | >>> it > | >>> and repeat. I set the ARC to the smallest value I can. Untarring > the > | >>> Linux kernel was enough to get the ARC evict and prune to spin since > | >>> they couldn't evict/prune anything. > | >>> > | >>> Looking at vnlru_free_vfsops called from ZFS arc_prune_task I see it > | >>> static int > | >>> vnlru_free_impl(int count, struct vfsops *mnt_op, struct vnode > *mvp) > | >>> { > | >>> ... > | >>> > | >>> for (;;) { > | >>> ... > | >>> vp = TAILQ_NEXT(vp, v_vnodelist); > | >>> ... > | >>> > | >>> /* > | >>> * Don't recycle if our vnode is from different type > | >>> * of mount point. Note that mp is type-safe, the > | >>> * check does not reach unmapped address even if > | >>> * vnode is reclaimed. > | >>> */ > | >>> if (mnt_op != NULL && (mp = vp->v_mount) != NULL && > | >>> mp->mnt_op != mnt_op) { > | >>> continue; > | >>> } > | >>> ... > | >>> > | >>> The vp ends up being the nulfs mount and then hits the continue > | >>> even though the passed in mvp is on ZFS. If I do a hack to > | >>> comment out the continue then I see the ARC, nullfs vnodes and > | >>> ZFS vnodes grow. When the ARC calls arc_prune_task that calls > | >>> vnlru_free_vfsops and now the vnodes go down for nullfs and ZFS. > | >>> The ARC cache usage also goes down. Then they increase again until > | >>> the ARC gets full and then they go down again. So with this hack > | >>> I don't need nocache passed to nullfs and I don't need to limit > | >>> the max vnodes. Doing multiple untars in parallel over and over > | >>> doesn't seem to cause any issues for this test. I'm not saying > | >>> commenting out continue is the fix but a simple POC test. > | >>> > | >> > | >> I don't see an easy way to say "this is a nullfs vnode holding onto a > | >> zfs vnode". Perhaps the routine can be extrended with issuing a nullfs > | >> callback, if the module is loaded. > | >> > | >> In the meantime I think a good enough(tm) fix would be to check that > | >> nothing was freed and fallback to good old regular clean up without > | >> filtering by vfsops. This would be very similar to what you are doing > | >> with your hack. > | >> > | > > | > Now that I wrote this perhaps an acceptable hack would be to extend > | > struct mount with a pointer to "lower layer" mount (if any) and patch > | > the vfsops check to also look there. > | > > | >> > | >>> It appears that when ZFS is asking for cached vnodes to be > | >>> free'd nullfs also needs to free some up as well so that > | >>> they are free'd on the VFS level. It seems that vnlru_free_impl > | >>> should allow some of the related nullfs vnodes to be free'd so > | >>> the ZFS ones can be free'd and reduce the size of the ARC. > | >>> > | >>> BTW, I also hacked the kernel and mount to show the vnodes used > | >>> per mount ie. mount -v: > | >>> test on /test (zfs, NFS exported, local, nfsv4acls, fsid > | >>> 2b23b2a1de21ed66, > | >>> vnodes: count 13846 lazy 0) > | >>> /test on /mnt (nullfs, NFS exported, local, nfsv4acls, fsid > | >>> 11ff002929000000, vnodes: count 13846 lazy 0) > | >>> > | >>> Now I can easily see how the vnodes are used without going into ddb. > | >>> On my laptop I have various vnet jails and nullfs mount my homedir > into > | >>> them so pretty much everything goes through nullfs to ZFS. I'm > limping > | >>> along with the nullfs nocache and small number of vnodes but it would > be > | >>> nice to not need that. > | >>> > | >>> Thanks, > | >>> > | >>> Doug A. > | >>> > | >>> > | >> > | >> > | >> -- > | >> Mateusz Guzik > | >> > | > > | > > | > -- > | > Mateusz Guzik > | > > | > | > | -- > | Mateusz Guzik > -- Mateusz Guzik From nobody Wed Apr 20 16:11:03 2022 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 7E47511D2CD0 for ; Wed, 20 Apr 2022 16:11:11 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91]) by mx1.freebsd.org (Postfix) with ESMTP id 4Kk5JG4L8Yz4RjD for ; Wed, 20 Apr 2022 16:11:10 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) IronPort-SDR: RYIqgUK2Jbv2l6ocabPyV6Yc3p52oyU2HaDmPqRdOL+VfbRVt7pB2wGrnvEhfzGcZXLxz6/4RF miTJbxcniJaj5UUrlgr1Bgsq0E2XuXP1A= X-Ambrisko-Me: Yes IronPort-Data: A9a23:aEKaL6500euyXA3J0oe8BwxRtEXHchMFZxGqfqrLsTDasY5as4F+v mAYDDvUaPneZzbxfdgnaIuxoE8G7JGDm4RkGQJp+XxhQiMRo6IpJzg5wmQcns+2BpeeJK5fA kl3huDodKjYdFeFzvuQGuOJQUdUhPjgqoXUWLas1hBZHWeIeQ954f5Rs7dRbr1A3bBVNziwV eba+KUzDrMFNwlcaQr444rbwP9mUW+bVDkw5jTSbtgT1LPSeuV84Dvy+MiMw3XErol8RoZWR s7Cyq205GXQ+1EkD9m/k634dQsBRbu60Qqm0ysMHfH80l4b4HZaPqUTbJLwbW9ejj+Tnstyz /1EsJaqSBwqOevHn+F1vxxwTngkZvEZkFPACT3l2SCJ9GXDcXTx0fRtJE4zNIwcvO1wBAlm+ +YVJToWYlWImviszbSnYud2i8kpN8WtO5kQ0kyMZxmx4e0OWp3ZXajQv5lR2T0qh9tNGrDVY M9xVNamVzyYCzUnB7vdIMtWcD6AiiatfjtGhkiSoKZrsWHfwBYrierkNdDPe8eJQu1cm0yCp 3nF+CLyBRRDbI6Tzj+M83SNgO7TnHOmANtDSOXgrvM60keOwmEzCQENUQfpq/eOlUPjCclUL FYZ+3RyoPFqplCrVNT0QzaxvGWA4kwHQ9NVHuBjsFONx6PY7hy3HG8BSjIdOtUquNVsHG4j0 1WTnsjqAhRmtbePSGme8fGfqjbrYXoZKmoLZCklSwoZ4om++Nhi0kqXFts6Sfy7lNz4Hz300 gumlilmiuVBl9MP2oW64UvD32CmqK/WQ1Nn/Q7QRG+ksF90Pdb3e4yy5FHHxv9cN4LFHEKZt X0JlsXCvuADCZaByH6ETOkXRuj75vCZPSfaiFopFpwr7TW2+HnldodVuWksKEBsO8cCWDnof E6D5FsItcMLZCOnPf1tfoa8K8U21qyxR93qW8fdYsdKfpUsJhSM+ztjZBLI0m2xwlIgl7ozZ cWSfcq2Vy5IEql90jesHaEU1LUxxzs9wiXYQpWil0ar1r+XZXi0T7YZMQvTNrlosPvc+AiFo cxCM8aqyglEVLysaybaxocfMFQWICVpHpvxscFWKraOLwcO9LvN0BMNLWfNo7BYopk= IronPort-HdrOrdr: A9a23:prO03q/7/SLT/vfeCDNuk+DYI+orL9Y04lQ7vn2ZhyY1TiW9rb HIoB17726RtN9/Yh0dcLy7V5VoBEmsk6KdgrNhWItKPjOW21dARbsKheCO/9SjIVydygc378 ddmsZFZuEZPTJB5/rH3A== Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 20 Apr 2022 08:07:38 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 23KGB3Vl076446 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 20 Apr 2022 09:11:03 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com Received: (from ambrisko@localhost) by ambrisko.com (8.17.1/8.17.1/Submit) id 23KGB3vu076445; Wed, 20 Apr 2022 09:11:03 -0700 (PDT) (envelope-from ambrisko) Date: Wed, 20 Apr 2022 09:11:03 -0700 From: Doug Ambrisko To: Mateusz Guzik Cc: freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Kk5JG4L8Yz4RjD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com X-Spamd-Result: default: False [-1.02 / 15.00]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[ambrisko]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.03)[-0.026]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[ambrisko.com]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Apr 20, 2022 at 11:43:10AM +0200, Mateusz Guzik wrote: | On 4/19/22, Doug Ambrisko wrote: | > On Tue, Apr 19, 2022 at 11:47:22AM +0200, Mateusz Guzik wrote: | > | Try this: https://people.freebsd.org/~mjg/vnlru_free_pick.diff | > | | > | this is not committable but should validate whether it works fine | > | > As a POC it's working. I see the vnode count for the nullfs and | > ZFS go up. The ARC cache also goes up until it exceeds the ARC max. | > size tten the vnodes for nullfs and ZFS goes down. The ARC cache goes | > down as well. This all repeats over and over. The systems seems | > healthy. No excessive running of arc_prune or arc_evict. | > | > My only comment is that the vnode freeing seems a bit agressive. | > Going from ~15,000 to ~200 vnode for nullfs and the same for ZFS. | > The ARC drops from 70M to 7M (max is set at 64M) for this unit | > test. | > | | Can you check what kind of shrinking is requested by arc to begin | with? I imagine encountering a nullfs vnode may end up recycling 2 | instead of 1, but even repeated a lot it does not explain the above. I dug it into a bit more and think there could be a bug in: module/zfs/arc.c arc_evict_meta_balanced(uint64_t meta_used) prune += zfs_arc_meta_prune; //arc_prune_async(prune); arc_prune_async(zfs_arc_meta_prune); Since arc_prune_async, is queuing up a run of arc_prune_task for each call it is actually already accumulating the zfs_arc_meta_prune amount. It makes the count to vnlru_free_impl get really big quickly since it is looping via restart. 1 HELLO arc_prune_task 164 ticks 2147465958 count 20480000 dmesg | grep arc_prune_task | uniq -c 14 HELLO arc_prune_task 164 ticks -2147343772 count 100 50 HELLO arc_prune_task 164 ticks -2147343771 count 100 46 HELLO arc_prune_task 164 ticks -2147343770 count 100 49 HELLO arc_prune_task 164 ticks -2147343769 count 100 44 HELLO arc_prune_task 164 ticks -2147343768 count 100 116 HELLO arc_prune_task 164 ticks -2147343767 count 100 1541 HELLO arc_prune_task 164 ticks -2147343766 count 100 53 HELLO arc_prune_task 164 ticks -2147343101 count 100 100 HELLO arc_prune_task 164 ticks -2147343100 count 100 75 HELLO arc_prune_task 164 ticks -2147343099 count 100 52 HELLO arc_prune_task 164 ticks -2147343098 count 100 50 HELLO arc_prune_task 164 ticks -2147343097 count 100 51 HELLO arc_prune_task 164 ticks -2147343096 count 100 783 HELLO arc_prune_task 164 ticks -2147343095 count 100 884 HELLO arc_prune_task 164 ticks -2147343094 count 100 Note I shrunk vfs.zfs.arc.meta_prune=100 to see how that might help. Changing it to 1, helps more! I see less agressive swings. I added printf("HELLO %s %d ticks %d count %ld\n",__FUNCTION__,__LINE__,ticks,nr_scan); to arc_prune_task. Adjusting both sysctl vfs.zfs.arc.meta_adjust_restarts=1 sysctl vfs.zfs.arc.meta_prune=100 without changing arc_prune_async(prune) helps avoid excessive swings. Thanks, Doug A. | > | On 4/19/22, Mateusz Guzik wrote: | > | > On 4/19/22, Mateusz Guzik wrote: | > | >> On 4/19/22, Doug Ambrisko wrote: | > | >>> I've switched my laptop to use nullfs and ZFS. Previously, I used | > | >>> localhost NFS mounts instead of nullfs when nullfs would complain | > | >>> that it couldn't mount. Since that check has been removed, I've | > | >>> switched to nullfs only. However, every so often my laptop would | > | >>> get slow and the the ARC evict and prune thread would consume two | > | >>> cores 100% until I rebooted. I had a 1G max. ARC and have increased | > | >>> it to 2G now. Looking into this has uncovered some issues: | > | >>> - nullfs would prevent vnlru_free_vfsops from doing anything | > | >>> when called from ZFS arc_prune_task | > | >>> - nullfs would hang onto a bunch of vnodes unless mounted with | > | >>> nocache | > | >>> - nullfs and nocache would break untar. This has been fixed | > now. | > | >>> | > | >>> With nullfs, nocache and settings max vnodes to a low number I can | > | >>> keep the ARC around the max. without evict and prune consuming | > | >>> 100% of 2 cores. This doesn't seem like the best solution but it | > | >>> better then when the ARC starts spinning. | > | >>> | > | >>> Looking into this issue with bhyve and a md drive for testing I | > create | > | >>> a brand new zpool mounted as /test and then nullfs mount /test to | > /mnt. | > | >>> I loop through untaring the Linux kernel into the nullfs mount, rm | > -rf | > | >>> it | > | >>> and repeat. I set the ARC to the smallest value I can. Untarring | > the | > | >>> Linux kernel was enough to get the ARC evict and prune to spin since | > | >>> they couldn't evict/prune anything. | > | >>> | > | >>> Looking at vnlru_free_vfsops called from ZFS arc_prune_task I see it | > | >>> static int | > | >>> vnlru_free_impl(int count, struct vfsops *mnt_op, struct vnode | > *mvp) | > | >>> { | > | >>> ... | > | >>> | > | >>> for (;;) { | > | >>> ... | > | >>> vp = TAILQ_NEXT(vp, v_vnodelist); | > | >>> ... | > | >>> | > | >>> /* | > | >>> * Don't recycle if our vnode is from different type | > | >>> * of mount point. Note that mp is type-safe, the | > | >>> * check does not reach unmapped address even if | > | >>> * vnode is reclaimed. | > | >>> */ | > | >>> if (mnt_op != NULL && (mp = vp->v_mount) != NULL && | > | >>> mp->mnt_op != mnt_op) { | > | >>> continue; | > | >>> } | > | >>> ... | > | >>> | > | >>> The vp ends up being the nulfs mount and then hits the continue | > | >>> even though the passed in mvp is on ZFS. If I do a hack to | > | >>> comment out the continue then I see the ARC, nullfs vnodes and | > | >>> ZFS vnodes grow. When the ARC calls arc_prune_task that calls | > | >>> vnlru_free_vfsops and now the vnodes go down for nullfs and ZFS. | > | >>> The ARC cache usage also goes down. Then they increase again until | > | >>> the ARC gets full and then they go down again. So with this hack | > | >>> I don't need nocache passed to nullfs and I don't need to limit | > | >>> the max vnodes. Doing multiple untars in parallel over and over | > | >>> doesn't seem to cause any issues for this test. I'm not saying | > | >>> commenting out continue is the fix but a simple POC test. | > | >>> | > | >> | > | >> I don't see an easy way to say "this is a nullfs vnode holding onto a | > | >> zfs vnode". Perhaps the routine can be extrended with issuing a nullfs | > | >> callback, if the module is loaded. | > | >> | > | >> In the meantime I think a good enough(tm) fix would be to check that | > | >> nothing was freed and fallback to good old regular clean up without | > | >> filtering by vfsops. This would be very similar to what you are doing | > | >> with your hack. | > | >> | > | > | > | > Now that I wrote this perhaps an acceptable hack would be to extend | > | > struct mount with a pointer to "lower layer" mount (if any) and patch | > | > the vfsops check to also look there. | > | > | > | >> | > | >>> It appears that when ZFS is asking for cached vnodes to be | > | >>> free'd nullfs also needs to free some up as well so that | > | >>> they are free'd on the VFS level. It seems that vnlru_free_impl | > | >>> should allow some of the related nullfs vnodes to be free'd so | > | >>> the ZFS ones can be free'd and reduce the size of the ARC. | > | >>> | > | >>> BTW, I also hacked the kernel and mount to show the vnodes used | > | >>> per mount ie. mount -v: | > | >>> test on /test (zfs, NFS exported, local, nfsv4acls, fsid | > | >>> 2b23b2a1de21ed66, | > | >>> vnodes: count 13846 lazy 0) | > | >>> /test on /mnt (nullfs, NFS exported, local, nfsv4acls, fsid | > | >>> 11ff002929000000, vnodes: count 13846 lazy 0) | > | >>> | > | >>> Now I can easily see how the vnodes are used without going into ddb. | > | >>> On my laptop I have various vnet jails and nullfs mount my homedir | > into | > | >>> them so pretty much everything goes through nullfs to ZFS. I'm | > limping | > | >>> along with the nullfs nocache and small number of vnodes but it would | > be | > | >>> nice to not need that. | > | >>> | > | >>> Thanks, | > | >>> | > | >>> Doug A. | > | >>> | > | >>> | > | >> | > | >> | > | >> -- | > | >> Mateusz Guzik | > | >> | > | > | > | > | > | > -- | > | > Mateusz Guzik | > | > | > | | > | | > | -- | > | Mateusz Guzik | > | | | -- | Mateusz Guzik From nobody Wed Apr 20 16:20:33 2022 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 6115311D5DED for ; Wed, 20 Apr 2022 16:20:35 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91]) by mx1.freebsd.org (Postfix) with ESMTP id 4Kk5W63TXdz4Tgc for ; Wed, 20 Apr 2022 16:20:34 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) IronPort-SDR: m/OyMYfGz1YuyPmZp8IBFF03aBy9KkA5kVzK2OWCZjhlNa+rFuVJlFPoX8KZkczUYNbeMpcGOU qFIjf1IeVwtxU5r+zfO43q7zkdHaIV5aY= X-Ambrisko-Me: Yes IronPort-Data: A9a23:3IZBhqzOUpcfSUVndOl6t+dMxirEfRIJ4+MujC+fZmUNrF6WrkVVy 2MXDTuHOqnfZWH9ettyYIyw9U9TsZGAmoUwSlc6qXw8FHgiRegppTi6wuYcGwvIc6UvdK/rh iknQoGowPocFxcwmz/2WlTfhSglvU23buqkYAL0EngZqT5MEE/Nuzo68wIKqtIAbeyCPu+4k YiaT/szmLOS82Uc3mo8s8pvof701Rj4kGtwUlcWPZinsLJC/pW84U92GE2/E5f4atE88u+SR uDfwau/92ef9hInENK+kbG9eUoPKlLQFVHf0DwPBfjk214YzsAx+v5T2P40YEJdkTSSnNdZw dBHr52rSgBvNarJ8AgYe0QBSXojZMWq/5eCexBTq/e75knLY3Lqz/h0JEU7PIEZ/Ol6GydI+ OBwAD4XYx2JnO7zy6+hUORqmuwtNsTmNpgT/HZ6wlnk4VwOKXzYa77H/8FVxm12j8VEB/fFZ M1fYj1qBCksqiZnYj8/YK/SVs/x7pUmWzEH+l+Tu4Qt5G3fkF543LT3aoOHc9mAX8ROnUGwr 2fM5WXiARZcP9uakGLX/nWpj+7JvCX6RINCSeXhp6Iy2AWelj4JFRkbdVqnuv3l2ESwbM1Sd h4P8S00oKlsqEHyFovhXwe1qWKvtwIHX4YCCPUz7QyAk/KG4wuQCmUeYCRGbdgq6J0/STAwj AbbltbjHz10s7q9QHeX7LaPrjT0Mi8QdDdQaSgBRAoDwt/ivIBj00qWH4o7SPa414SnFyvxz jaGqDkFq48S1cNbhb+m+V3ngi63osSbRAAC+QiKDHmu6Rl0ZdD5atXwu0Tb9/tJMK2QUkKF4 Cofg8Gb4e0DUcONmSiKTLlfFb2l/azcYjzanVN1GZAlsT2o8WSiZoNXpjp5IR4xYMoDfDboZ m7VuB9QtMILZSr2NfcvbtLjEdkuwIjhCc/hB6LdYdd5a5RscBOKoXN1bkmK0mGxyEUhzfMlN ZGAfZr+BHoWE/4/niG7XfkQy+VtzyU032LIRpe9xBOiiOLMaHmQQLYDEV2PcuFpsfvd8VmNq 45SZ5mQ1hFScOzieS2Go4ccIGcDIWU/GZ2r+ddccfSOI1Y+FWwsYxMLLWjNp2Cxc3xpq9r1 IronPort-HdrOrdr: A9a23:nSnYjK3PtqiswCLwGtR6AgqjBLIkLtp133Aq2lEZdPWaSK2lfu SV7ZMmPH7P+VIssR4b9exoVJPufZqYz+8S3WBzB8bGYOCFghrKEGgK1+KLqFDd8m/Fh4xgPM xbE5SWZuefMbBL5/yR3DWF Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 20 Apr 2022 08:17:09 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 23KGKXCH077049 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 20 Apr 2022 09:20:33 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com Received: (from ambrisko@localhost) by ambrisko.com (8.17.1/8.17.1/Submit) id 23KGKXYn077048; Wed, 20 Apr 2022 09:20:33 -0700 (PDT) (envelope-from ambrisko) Date: Wed, 20 Apr 2022 09:20:33 -0700 From: Doug Ambrisko To: Alexander Leidinger Cc: freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues Message-ID: References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> 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: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> X-Rspamd-Queue-Id: 4Kk5W63TXdz4Tgc X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com X-Spamd-Result: default: False [-0.37 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[ambrisko]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[ambrisko.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.62)[0.618]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.988]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Apr 20, 2022 at 11:39:44AM +0200, Alexander Leidinger wrote: | Quoting Doug Ambrisko (from Mon, 18 Apr 2022 | 16:32:38 -0700): | | > With nullfs, nocache and settings max vnodes to a low number I can | | Where is nocache documented? I don't see it in mount_nullfs(8), | mount(8) or nullfs(5). I didn't find it but it is in: src/sys/fs/nullfs/null_vfsops.c: if (vfs_getopt(mp->mnt_optnew, "nocache", NULL, NULL) == 0 || Also some file systems disable it via MNTK_NULL_NOCACHE | I tried a nullfs mount with nocache and it doesn't show up in the | output of "mount". Yep, I saw that as well. I could tell by dropping into ddb and then do a show mount on the FS and look at the count. That is why I added the vnode count to mount -v so I could see the usage without dropping into ddb. Doug A. From nobody Thu Apr 21 03:39:12 2022 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 729A111D2B8B for ; Thu, 21 Apr 2022 03:39:20 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (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 "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KkNZH33vZz3Gls for ; Thu, 21 Apr 2022 03:39:19 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:subject:subject:from:from:content-language :user-agent:mime-version:date:date:message-id; s=201508; t= 1650512353; bh=I3FrAIMODjbKyNXKvul6ocudCyLuJhLa2Wot36hRZ9I=; b=Q rHl4DBiScp5pM0bYtKDKA3zhYqafU3yyTQVa14t5RQWE+zNneIiS4VVMsbrB9LDU o03HDLQhV9/nP5LjI+uN6vpqomt6PR6K+2YyrplEL//EvSRFLvBgtxtDTigVdxex h9ScmNV/5HBAOBWlSMvvjvwqrJSBS+HeEduXXZOWug= Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 1115821E45 for ; Wed, 20 Apr 2022 23:39:13 -0400 (EDT) Message-ID: <263e16c4-0634-88e6-9652-50d0874f027e@protected-networks.net> Date: Wed, 20 Apr 2022 23:39:12 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-NZ To: freebsd-current From: Michael Butler Subject: 'set but unused' breaks drm-*-kmod Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KkNZH33vZz3Gls X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b="Q rHl4DB"; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 2001:470:8d59:1::8 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-3.94 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.94)[-0.938]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Seems this new requirement breaks kmod builds too .. The first of many errors was (I stopped chasing them all for lack of time) .. --- amdgpu_cs.o --- /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26: error: variable 'priority' set but not used [-Werror,-Wunused-but-set-variable] enum drm_sched_priority priority; ^ 1 error generated. *** [amdgpu_cs.o] Error code 1 From nobody Thu Apr 21 06:33:10 2022 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 3012E11D91FE for ; Thu, 21 Apr 2022 06:34:02 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KkSRs1Kf1z4S3v for ; Thu, 21 Apr 2022 06:34:01 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id E1E962C4B9; Thu, 21 Apr 2022 08:33:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1650522816; 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=JVIvolx5wp3uNJ1fmbUtHiTkXlPdLc0WLX7Cz60a0aY=; b=C5cdXhKqx2hMS3TlWmzy+aL5i0oPJ5BDn7w95QVJPS2EFmk4AeXyQ6hfrk1FmePBoJiVRU trHMx64zANRXbHO1Z2Ae2LqfwY7QdfxeTDuQPo84nAw+dA3emFKWxpdmlR+6Ji4qJPthWs 5Ti61EGwRwyrHn0HrGkIl/vz81t8+KNyuR7g2SqQiDW/2gXV0Iz1m+2l6MAzTIB9k0kt0E KTQ2sLz1sJlXF+jA85mk63mmUEaseoK7JzpxRWUMlWiwdJifJg1MISUTKTC7Hh/C6wjAfn fQ2eJZZtFtlILTqiWO6s0dR0nugayHC3oSFBp3vqG9lqZeeMZUcrwldrAn03ww== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id CE06D3125; Thu, 21 Apr 2022 08:33:13 +0200 (CEST) Date: Thu, 21 Apr 2022 08:33:10 +0200 Message-ID: <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> From: Alexander Leidinger To: Doug Ambrisko Cc: freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_ynM4CAvCMj8TmUI2uVA8vHP"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4KkSRs1Kf1z4S3v X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=C5cdXhKq; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-4.72 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain,text/diff]; HAS_ATTACHMENT(0.00)[]; NEURAL_SPAM_SHORT(0.38)[0.381]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_ynM4CAvCMj8TmUI2uVA8vHP Content-Type: multipart/mixed; boundary="=_NGnP2w2ySILE7xRtSYzRIXc" This message is in MIME format. --=_NGnP2w2ySILE7xRtSYzRIXc Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Doug Ambrisko (from Wed, 20 Apr 2022=20=20 09:20:33=20-0700): > On Wed, Apr 20, 2022 at 11:39:44AM +0200, Alexander Leidinger wrote: > | Quoting Doug Ambrisko (from Mon, 18 Apr 2022 > | 16:32:38 -0700): > | > | > With nullfs, nocache and settings max vnodes to a low number I can > | > | Where is nocache documented? I don't see it in mount_nullfs(8), > | mount(8) or nullfs(5). > > I didn't find it but it is in: > src/sys/fs/nullfs/null_vfsops.c: if (vfs_getopt(mp->mnt_optnew,=20=20 >=20"nocache", NULL, NULL) =3D=3D 0 || > > Also some file systems disable it via MNTK_NULL_NOCACHE Does the attached diff look ok? > | I tried a nullfs mount with nocache and it doesn't show up in the > | output of "mount". > > Yep, I saw that as well. I could tell by dropping into ddb and then > do a show mount on the FS and look at the count. That is why I added > the vnode count to mount -v so I could see the usage without dropping > into ddb. I tried nocache on a system with a lot of jails which use nullfs,=20=20 which=20showed very slow behavior in the daily periodic runs (12h runs=20= =20 in=20the night after boot, 24h or more in subsequent nights). Now the=20=20 first=20nightly run after boot was finished after 4h. What is the benefit of not disabling the cache in nullfs? I would=20=20 expect=20zfs (or ufs) to cache the (meta)data anyway. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_NGnP2w2ySILE7xRtSYzRIXc Content-Type: text/diff; charset=utf-8; name=mount.8.diff Content-Disposition: attachment; size=520; filename=mount.8.diff Content-Transfer-Encoding: quoted-printable diff --git a/sbin/mount/mount.8 b/sbin/mount/mount.8 index 2a877c04c07..823df63953d 100644 --- a/sbin/mount/mount.8 +++ b/sbin/mount/mount.8 @@ -28,7 +28,7 @@ .\" @(#)mount.8 8.8 (Berkeley) 6/16/94 .\" $FreeBSD$ .\" -.Dd March 17, 2022 +.Dd April 21, 2022 .Dt MOUNT 8 .Os .Sh NAME @@ -245,6 +245,9 @@ This file system should be skipped when is run with the .Fl a flag. +.It Cm nocache +Disable caching. +Some filesystems may not support this. .It Cm noclusterr Disable read clustering. .It Cm noclusterw --=_NGnP2w2ySILE7xRtSYzRIXc-- --=_ynM4CAvCMj8TmUI2uVA8vHP Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJg+qUACgkQEg2wmwP4 2Iai7xAAoBfUaimRkru9wrcadW8zCL7sUG2owGufjCZV5r9OE8XGUmMRwvL8RzZV Vo9nim8nXP6JQ3fSw2LguMNk+KEP0vQfkuB0xrvFRqldOkbsGmDU+T+isSHMW+z0 Pi1fsm6qtr5+p74ETGiMK03rwIfQThYUfsTdzIust8dD7yg+LyFSDK92+tG/BlKV YmWuA1KAMC7S6a4VCx1IpElnk9upnxP+fdOMXRaRY4i0T+g3u2iJ4FOSw4kpsSLd UpECjbTbwiRenMRHhOATnNfC6fxqNO7V5xkcUhMgOg6ZDk8g11AbxClroEldrSNm tGKEoiLDAO5n0jvnS3L71i+b94HA1bHAwraL6Kt8RFthYQ2zYXkyIGYbkelI2clJ +mV73+rSTqkKUqUkB9pmRHEm5prlIMWhDOktdRIGyTBW+ZzhS+TZrToJw6RRttXw EkdAfRl5ACmdsjS020AgswfMR6IHZpjcLYjwHSD7Br9KkX7/bPHCB53zqRX/jCP7 xIFC5LIPc7FzyFwmCg9gh3fLOsl/fstZ+ASGzR/hBMy5fAoPv63PNEChKIEt27eH paM67lMpH2+uatLQl0Rix+X6Xvnt1IfZpdFEeLtvKSrK+TZGYAXQ/xuowmzFqMDp PPa3D/1i7hXU+dnIU/MXL75iWyADM0A4/aGq5op/3SzQxZg2Ocg= =KCG4 -----END PGP SIGNATURE----- --=_ynM4CAvCMj8TmUI2uVA8vHP-- From nobody Thu Apr 21 07:42:36 2022 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 9C828198A3F6 for ; Thu, 21 Apr 2022 07:42:34 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KkTyx4Hywz4bqV for ; Thu, 21 Apr 2022 07:42:33 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1650526945; 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=m9GHMriSeKQPUIPkfNiFcQBIwxWBiz3+W5VsDFFNaqE=; b=udoVD1SfjJIT1/Xd2/34XHtPdmj1rPeBHSZ0dpQJT1lgZKLAXID+6i4vPmyAVtsqRGLMDC B7Ak1/HdhvnK5ZGfRMSZC95011z0T+R0hsUk0eL2EjYe0e/+HtZ5qQZHiXPcxNNbVP34bW uSWPFN/yNnQzN2WX018T2UDdBicBXis= Received: from amy (lfbn-idf2-1-1209-45.w90-92.abo.wanadoo.fr [90.92.34.45]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 769234c8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 21 Apr 2022 07:42:25 +0000 (UTC) Date: Thu, 21 Apr 2022 09:42:36 +0200 From: Emmanuel Vadot To: Michael Butler Cc: freebsd-current Subject: Re: 'set but unused' breaks drm-*-kmod Message-Id: <20220421094236.3f023ac540666c140c04f884@bidouilliste.com> In-Reply-To: <263e16c4-0634-88e6-9652-50d0874f027e@protected-networks.net> References: <263e16c4-0634-88e6-9652-50d0874f027e@protected-networks.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KkTyx4Hywz4bqV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=udoVD1Sf; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.24 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.26)[0.262]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello Michael, On Wed, 20 Apr 2022 23:39:12 -0400 Michael Butler wrote: > Seems this new requirement breaks kmod builds too .. > > The first of many errors was (I stopped chasing them all for lack of > time) .. > > --- amdgpu_cs.o --- > /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26: > error: variable 'priority' set but not used > [-Werror,-Wunused-but-set-variable] > enum drm_sched_priority priority; > ^ > 1 error generated. > *** [amdgpu_cs.o] Error code 1 > How are you building the port, directly or with PORTS_MODULES ? I do make passes on the warning for drm and I did for set-but-not-used case but unfortunately this option doesn't exists in 13.0 so I couldn't apply those in every branch. Cheers, -- Emmanuel Vadot From nobody Thu Apr 21 07:44:04 2022 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 A4392198AE6D; Thu, 21 Apr 2022 07:43:55 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KkV0V50llz4cln; Thu, 21 Apr 2022 07:43:54 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1650527033; 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=J00Uv/VyYBSI7NfM1PJ9BLzg0m4bntQ/ljqYleMJ8vc=; b=n/A6SBRG6l4fjpRRWtpLul1Xxot8lkQemwBUBHywY6YZx1CNPhXbrtRoYU4S8XozwfNhQ/ shC6SDR8FqIS+A1KA/85pn50uOIpHgKA3ckf2WHk5QE/ruJknqIl4NG7JJ43CguWoOSaWt Q/ktaQ1f92YyOpwKsRqxdUCzTzSPZlA= Received: from amy (lfbn-idf2-1-1209-45.w90-92.abo.wanadoo.fr [90.92.34.45]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 56502a11 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 21 Apr 2022 07:43:53 +0000 (UTC) Date: Thu, 21 Apr 2022 09:44:04 +0200 From: Emmanuel Vadot To: sgk@troutmask.apl.washington.edu Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: Daily black screen of death Message-Id: <20220421094404.11cdf22e45c8bee5fc749ba5@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KkV0V50llz4cln X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b="n/A6SBRG"; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.22 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.72)[-0.717]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-x11,freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello Steve, On Tue, 19 Apr 2022 11:32:32 -0700 Steve Kargl wrote: > FYI, > > I'm experiencing an almost daily black screen of death panic. > Kernel, world, drm-current-kmod, and gpu-firmware-kmod were > all rebuilt and installed at the same time. Uname shows > > FreeBSD 14.0-CURRENT #0 main-n254360-eb9d205fa69: Tue Apr 5 13:49:47 PDT 2022 > > So, April 5th sources. > > The panic results in a keyboard lock and no dump. The system > does not have a serial console. Only recourse is a hard rest. > > Hand transcribed from photo > > _sleep() at _sleep+0x38a/frame 0xfffffe012b7c0680 > buf_daemon_shutdown() at buf_daemon_shutdown+0x6b/frame 0xfffffe012b7c06a0 > kern_reboot() at kern_reboot+0x2ae/frame 0xfffffe012b7c06e0 > vpanic() at vpanic+0x1ee/frame 0xfffffe012b7c0730 > panic() at panic+0x43/frame 0xfffffe012b7c0790 > > Above repeats 100s of time scrolling off the screen with ever > increasing frame pointer. > > Final message, > > mi_switch() at mi_switch+0x18e/frame 0xfffffe012b7c14b0 > __mtx_lock_sleep() at __mtx_lock_sleep+0x173/frame 0xfffffe012b7c1510 > __mtx_lock_flags() at __mtx_lock_flags+0xc0/frame 0xfffffe012b7c1550 > linux_wake_up() at linux_wake_up+0x38/frame 0xfffffe012b7c15a0 > radeon_fence_is_signaled() at radeon_fence_is_signaled+0x99/frame 0xfffffe012b7c15f0 > dma_resv_add_shared_fence() at dma_resv_add_shared_fence+0x99/frame 0xfffffe012b7c1640 > ttm_eu_fence_buffer_objects() at ttm_eu_fence_buffer_objects+0x79/frame 0xfffffe012b7c1680 > radeon_cs_parser_fini() at radeon_cs_parser_fini+0x53/frame 0xfffffe012b7c16b0 > radeaon_cs_ioctl() at radeaon_cs_ioctl+0x75e/frame 0xfffffe012b7c1b30 > drm_ioctl_kernel() at drm_ioctl_kernel+0xc7/frame 0xfffffe012b7c1b80 > drm_ioctl() at drm_ioctl+0x2c3/frame 0xfffffe012b7c1c70 > linux_file_ioctl() at linux_file_ioctl+0x309/frame 0xfffffe012b7c1cd0 > kern_ioctl() at kern_ioctl+0x1dc/frame 0xfffffe012b7c1d40 > sys_ioctl() at sys_ioctl+0x121/frame 0xfffffe012b7c1e10 > amd64_syscall() at amd64_syscall+0x108/frame 0xfffffe012b7c1f30 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe012b7c1f30 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x36a096c34ea, rsp = 0x3fa11e623eb8, \ > rbp = 0x3fa11e623ee0 --- > panic: _sleep: curthread not running > cpuid = 4 > time = 1650389478 > KDB: stack backtrace: > > One common trigger appears to be the use of firefox-99.0,2 from > the ports collection. > > -- > Steve > What version of drm are you using ? Since when do you experience this ? drm as not changed much for a long time now except adapting a few files for new linuxkpi addition. Cheers, -- Emmanuel Vadot From nobody Thu Apr 21 08:02:11 2022 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 44EEF19903DD for ; Thu, 21 Apr 2022 08:02:24 +0000 (UTC) (envelope-from contact@evilham.com) Received: from yggdrasil.evilham.com (yggdrasil.evilham.com [IPv6:2a02:2770::216:3eff:fee1:cf9]) (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 4KkVPq0HWxz4hS3 for ; Thu, 21 Apr 2022 08:02:23 +0000 (UTC) (envelope-from contact@evilham.com) From: Evilham DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=evilham.com; s=mail; t=1650528134; bh=ceiTHtgZ41hHtL2g96NlVTD/5Pz5EVxitE3rWGqHgIo=; h=From:To:Subject:References:In-reply-to:Date; b=oxK5o2SNdWN2xgSNZsWavJZjU+tSBgRSP8Ysc27j1clQiDraO2sO9HKQGhZh1iAJ9 6kP9t25olfpOji4lybgcK+IHKt7W50ct73ZsPJZ9FRmpBJrZ5gSys/v/HmPShOyC8x HNK5cgoOK5uihwpOJJf+YST3KyRSMx1/5/gOvfxA= To: freebsd-current@freebsd.org Subject: Re: 'set but unused' breaks drm-*-kmod References: <263e16c4-0634-88e6-9652-50d0874f027e@protected-networks.net> <20220421094236.3f023ac540666c140c04f884@bidouilliste.com> In-reply-to: <20220421094236.3f023ac540666c140c04f884@bidouilliste.com> Date: Thu, 21 Apr 2022 10:02:11 +0200 Message-ID: <43a186ff09129eac264090e12204fa857d9a@yggdrasil.evilham.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; format=flowed X-Rspamd-Queue-Id: 4KkVPq0HWxz4hS3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=evilham.com header.s=mail header.b=oxK5o2SN; dmarc=pass (policy=quarantine) header.from=evilham.com; spf=pass (mx1.freebsd.org: domain of contact@evilham.com designates 2a02:2770::216:3eff:fee1:cf9 as permitted sender) smtp.mailfrom=contact@evilham.com X-Spamd-Result: default: False [-3.58 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.76)[-0.758]; R_DKIM_ALLOW(-0.20)[evilham.com:s=mail]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[evilham.com:+]; DMARC_POLICY_ALLOW(-0.50)[evilham.com,quarantine]; NEURAL_HAM_SHORT(-0.82)[-0.823]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:196752, ipnet:2a02:2770::/32, country:NL] X-ThisMailContainsUnwantedMimeParts: N On dj., abr. 21 2022, Emmanuel Vadot wrote: > Hello Michael, > > On Wed, 20 Apr 2022 23:39:12 -0400 > Michael Butler wrote: > >> Seems this new requirement breaks kmod builds too .. >> >> The first of many errors was (I stopped chasing them all for >> lack of >> time) .. >> >> --- amdgpu_cs.o --- >> /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26: >> error: variable 'priority' set but not used >> [-Werror,-Wunused-but-set-variable] >> enum drm_sched_priority priority; >> ^ >> 1 error generated. >> *** [amdgpu_cs.o] Error code 1 >> > > How are you building the port, directly or with PORTS_MODULES ? > I do make passes on the warning for drm and I did for > set-but-not-used > case but unfortunately this option doesn't exists in 13.0 so I > couldn't > apply those in every branch. > > Cheers, Can confirm the breakage on 14-CURRENT building graphics/drm-devel-kmod in poudriere with matching sources and kernel. Probably due to 8b83d7e0ee54416b0ee58bd85f9c0ae7fb3357a1 -- Evilham From nobody Thu Apr 21 12:50:42 2022 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 27FD61997B74 for ; Thu, 21 Apr 2022 12:50:51 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kkcpf0L0Rz4RHB for ; Thu, 21 Apr 2022 12:50:50 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lf1-x12f.google.com with SMTP id w1so8522443lfa.4 for ; Thu, 21 Apr 2022 05:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pQhFeqih9jjYAgNMe0HJ0GyXfNt+0KwauZfsyVqCgp8=; b=deU6LR0/NDHhl6tQhLf/EBc5L8X1B6+LT50tCu09xpu/a6KJArEzTXTSOp5mVk0Tz2 rA0UCOh1F91r0Jac/3XbqdK6VwRXwIj4yOpmTZPWTDcYM/j40bKCVIERDJ5yJq/6J7A9 U/6yM56Hz0/RVfOt5WEllfUqZk76Cou6Gdl+1pEKQKY0sdmG87QC9n2uHluT6FGGnYz9 Do4MjmZLeLlBNAYC/2r1zD4g5bBnPASVmBFYINlB05W6ectRkL1Fh6jPA+V+QVOu5Gej Dt2uPb5gZuUC/TnzhggpGzTeeURBeIZfi0awepBaTgs4jq254QrWCo591eQJeeZj4vMa 603A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pQhFeqih9jjYAgNMe0HJ0GyXfNt+0KwauZfsyVqCgp8=; b=hf6EFErzXsH5JIGL8RElwCRZ4WVycjE1LVPB7YtPTGG7T4r3RkFb/iIcQcpaUdUhlB rsUVMzezHp3JqT3E5rb7tIPlDXb18vMOQrjrICdMjnIaNSgUh/jns8GGB0ED0mr+Yq9P 2UH61X6xDZ+ILFMqTNqrinECy9dt/TEhl7drNPZIK5CgmMlEh4ueJilFjou42N3U3m9x 6y+7Ei8tPXZxZ83MMrIWBTMJlhyRN1nqCoXfsFUSzoghyAlUEPAW7rR+350GLBJxn71L c01lOQMQa+i3SKnGoJJukZISnRJheISRiB7z+r4KtdLvPIkXLLQKuu/gbAL6Z4F2Z6A2 P7pQ== X-Gm-Message-State: AOAM532eW10NlnoBN3Zbc5y/q5OupVs4j9Pf8qPPdQiXD563L4n7EozI ZLiN9oW+OhxgFT5sygo/Mux/o4ukWL88Yoev9NmRO+yo X-Google-Smtp-Source: ABdhPJyzlG/KVvzFlOKDz9CekG/z8G64mw30egFlb3/0Aq3p4R9m07sIx1UnpanbCzQvjlbaYT1S4fbuc7I75NmReWs= X-Received: by 2002:a05:6512:10c5:b0:471:a703:bca4 with SMTP id k5-20020a05651210c500b00471a703bca4mr9266847lfg.581.1650545443229; Thu, 21 Apr 2022 05:50:43 -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 Received: by 2002:a05:6520:6145:b0:1bb:7433:4cdd with HTTP; Thu, 21 Apr 2022 05:50:42 -0700 (PDT) In-Reply-To: <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> From: Mateusz Guzik Date: Thu, 21 Apr 2022 14:50:42 +0200 Message-ID: Subject: Re: nullfs and ZFS issues To: Alexander Leidinger Cc: Doug Ambrisko , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Kkcpf0L0Rz4RHB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="deU6LR0/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-1.94 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-0.93)[-0.926]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.986]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12f:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 4/21/22, Alexander Leidinger wrote: > Quoting Doug Ambrisko (from Wed, 20 Apr 2022 > 09:20:33 -0700): > >> On Wed, Apr 20, 2022 at 11:39:44AM +0200, Alexander Leidinger wrote: >> | Quoting Doug Ambrisko (from Mon, 18 Apr 2022 >> | 16:32:38 -0700): >> | >> | > With nullfs, nocache and settings max vnodes to a low number I can >> | >> | Where is nocache documented? I don't see it in mount_nullfs(8), >> | mount(8) or nullfs(5). >> >> I didn't find it but it is in: >> src/sys/fs/nullfs/null_vfsops.c: if (vfs_getopt(mp->mnt_optnew, >> "nocache", NULL, NULL) == 0 || >> >> Also some file systems disable it via MNTK_NULL_NOCACHE > > Does the attached diff look ok? > >> | I tried a nullfs mount with nocache and it doesn't show up in the >> | output of "mount". >> >> Yep, I saw that as well. I could tell by dropping into ddb and then >> do a show mount on the FS and look at the count. That is why I added >> the vnode count to mount -v so I could see the usage without dropping >> into ddb. > > I tried nocache on a system with a lot of jails which use nullfs, > which showed very slow behavior in the daily periodic runs (12h runs > in the night after boot, 24h or more in subsequent nights). Now the > first nightly run after boot was finished after 4h. > > What is the benefit of not disabling the cache in nullfs? I would > expect zfs (or ufs) to cache the (meta)data anyway. > does the poor performance show up with https://people.freebsd.org/~mjg/vnlru_free_pick.diff ? if the long runs are still there, can you get some profiling from it? sysctl -a before and after would be a start. My guess is that you are the vnode limit and bumping into the 1 second sleep. -- Mateusz Guzik From nobody Thu Apr 21 12:51:26 2022 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 368E7199820B for ; Thu, 21 Apr 2022 12:51:35 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KkcqV3JM5z4S5l for ; Thu, 21 Apr 2022 12:51:34 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1650545486; bh=YV4/AfVolmCMwHvf8YPMDayjHtgiNPWqU01l VPxIEH0=; b=eTgBDu8qis0jn/D67EVij1PtrmetxPevrqG0Y6wnw1leJcQw0ODi q3LUwtAJ5ymYpTDu+FLv4MPf3v87YZULoRqKuncWNOu7LiqS7wrvZYrJMbg0a7dk ISm5IiwyBeNsrPyBACyGFtWkmU6/ZoXaIJ5dXdD92wOTHg2g88zdpF0= Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 8A0402D359; Thu, 21 Apr 2022 08:51:26 -0400 (EDT) Message-ID: Date: Thu, 21 Apr 2022 08:51:26 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: 'set but unused' breaks drm-*-kmod Content-Language: en-NZ To: Emmanuel Vadot Cc: freebsd-current References: <263e16c4-0634-88e6-9652-50d0874f027e@protected-networks.net> <20220421094236.3f023ac540666c140c04f884@bidouilliste.com> From: Michael Butler In-Reply-To: <20220421094236.3f023ac540666c140c04f884@bidouilliste.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KkcqV3JM5z4S5l X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=eTgBDu8q; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-2.17 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.83)[0.830]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/21/22 03:42, Emmanuel Vadot wrote: > > Hello Michael, > > On Wed, 20 Apr 2022 23:39:12 -0400 > Michael Butler wrote: > >> Seems this new requirement breaks kmod builds too .. >> >> The first of many errors was (I stopped chasing them all for lack of >> time) .. >> >> --- amdgpu_cs.o --- >> /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26: >> error: variable 'priority' set but not used >> [-Werror,-Wunused-but-set-variable] >> enum drm_sched_priority priority; >> ^ >> 1 error generated. >> *** [amdgpu_cs.o] Error code 1 >> > > How are you building the port, directly or with PORTS_MODULES ? > I do make passes on the warning for drm and I did for set-but-not-used > case but unfortunately this option doesn't exists in 13.0 so I couldn't > apply those in every branch. I build this directly on -current. I'm guessing that these are what triggered this behaviour: commit 8b83d7e0ee54416b0ee58bd85f9c0ae7fb3357a1 Author: John Baldwin Date: Mon Apr 18 16:06:27 2022 -0700 Make -Wunused-but-set-variable a fatal error for clang 13+ for kernel builds. Reviewed by: imp, emaste Differential Revision: https://reviews.freebsd.org/D34949 commit 615d289ffefe2b175f80caa9b1e113c975576472 Author: John Baldwin Date: Mon Apr 18 16:06:14 2022 -0700 Re-enable set but not used warnings for kernel builds. make tinderbox now passes with this warning enabled as a fatal error, so revert the change to hide it in preparation for making it fatal. This reverts commit e8e691983bb75e80153b802f47733f1531615fa2. Reviewed by: imp, emaste Differential Revision: https://reviews.freebsd.org/D34948 From nobody Thu Apr 21 13:44:02 2022 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 ED24211CC9C4 for ; Thu, 21 Apr 2022 13:44:29 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kkf0X5GL8z4c06 for ; Thu, 21 Apr 2022 13:44:28 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 08FA12CA41; Thu, 21 Apr 2022 15:44:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1650548654; 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=I8knDJe2WlQGuPb4/nU7gDzOYDEjFu89Api2hsWjvec=; b=frobDpTVjv+RUdzy1YC851cDfoinPQGpcy5pDHCGOSlj91SDiyB6UUSAIVo3MHOsxXqcpE qC10Eq6S/tS4zGwpylT+QESu+m87sXLgOrW/dVT0JEG5/+Ri+mu6iVOIAK4tfgJiztHC88 HLXxAaAcIJd+xQdWX4zXRhnPJuHSmyzoJaQaRdcVUPXKynLCpkPGfTOFv1cBsdVflQGu1z wEWDhuTo8UBZfoNys+Xt0mnKtCPs12E2by3VweGL9z1R8zKMpmnQRdvncwC9DvFDi9HJaS haLg4rP7LYkiGM1Of+mQfR4zyaOsavPe7hqAqCtZ6WVNVxyuT+392StReG56hQ== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 3364C3716; Thu, 21 Apr 2022 15:44:04 +0200 (CEST) Date: Thu, 21 Apr 2022 15:44:02 +0200 Message-ID: <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> From: Alexander Leidinger To: Mateusz Guzik Cc: Doug Ambrisko , freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_mCoQQKdVyX4TDmpIgE_NwAt"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4Kkf0X5GL8z4c06 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=frobDpTV; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-4.15 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-0.99)[-0.994]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_SPAM_MEDIUM(0.94)[0.940]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_mCoQQKdVyX4TDmpIgE_NwAt Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Mateusz Guzik (from Thu, 21 Apr 2022=20=20 14:50:42=20+0200): > On 4/21/22, Alexander Leidinger wrote: >> I tried nocache on a system with a lot of jails which use nullfs, >> which showed very slow behavior in the daily periodic runs (12h runs >> in the night after boot, 24h or more in subsequent nights). Now the >> first nightly run after boot was finished after 4h. >> >> What is the benefit of not disabling the cache in nullfs? I would >> expect zfs (or ufs) to cache the (meta)data anyway. >> > > does the poor performance show up with > https://people.freebsd.org/~mjg/vnlru_free_pick.diff ? I would like to have all the 22 jails run the periodic scripts a=20=20 second=20night in a row before trying this. > if the long runs are still there, can you get some profiling from it? > sysctl -a before and after would be a start. > > My guess is that you are the vnode limit and bumping into the 1 second sl= eep. That would explain the behavior I see since I added the last jail=20=20 which=20seems to have crossed a threshold which triggers the slow=20=20 behavior. Current=20status (with the 112 nullfs mounts with nocache): kern.maxvnodes: 10485760 kern.numvnodes: 3791064 kern.freevnodes: 3613694 kern.cache.stats.heldvnodes: 151707 kern.vnodes_created: 260288639 The maxvnodes value is already increased by 10 times compared to the=20=20 default=20value on this system. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_mCoQQKdVyX4TDmpIgE_NwAt Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJhX6IACgkQEg2wmwP4 2IZTeA//cJhz26bByMcB3GGJiE1hbe/vkBg5GmXXecD5mD6BSDbBoMM3lA5IW/v5 a9JDus3iY+oeAhyJO5ig5znRwVkfpOhHbO9dFqIdp6mwIN1k2+91AMr6SMTEHhnu cvlLVUnlhZeSLzW4ty79iKsLYXyheC06MMrHVawrJs/i22XOS4+zPyT33N/WNMLs UGNqWFuyYw5+PQCGcX46NSbEZYiDLN9AMM9lXwY2RnY8ziX5JnW6lEU88OrW7O/v F5Y2uDj1UPsmkPwsaVtblDpzpcI/bEoR2/YECSjX07kVJ/r5cLI9FMbAxBn4Nbyb mKpYYYX+ORzmS9uKML/pZJUsATCM552AALU8LLtbUyZ2V09uOo3nsICdDbB8CAvi A/E9acuGqQFbHE/iXQrU+U01GmRrb9A+OG7oYMHmMqQccmi5hDYWzXpGzrU/8jGU J2q/32chB2czyYg9QT0U4KVKuxE2Gpn2Vxl60A1EmrLTtnbsbMugJIQOr2fpekYo 1BoFdqyUpfL5VP+GuPiTzCPikLWEAFk4v1wVpdd6vd0MMXcghyTZ9hXoWTAYW80V xnSpT92sI/VoMyjcTjPAwevvdfbSKtSPOg2WKa3/XTJUKCn0m+x2LQwTydjO+olp NP63zlpAwuIQzg46pNdX3PYCy+418Dwb0vh9JkoHKgPxfWsxe/0= =OibP -----END PGP SIGNATURE----- --=_mCoQQKdVyX4TDmpIgE_NwAt-- From nobody Thu Apr 21 13:45:55 2022 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 ACE3311CCD9D for ; Thu, 21 Apr 2022 13:45:58 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kkf2D736Xz4cyL for ; Thu, 21 Apr 2022 13:45:56 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1650548755; 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=xfeWKvu5fjbqZvJBak25lvm6W4D6mvthZYhgc9zvUyg=; b=mfoLKQg2eWoBNCrbTBh3zDa4gDsNJ5h4dnP2X8S1oBZDYu/FV/e0FI2aLWRE84t+vo2La/ pint8o6uDSt6grR6oXz9YLj+NSdj91NeGrk9dQNQWI19/oGqVSWVlqJLnuHu6QrB7Wfqem i6V8HVqNgsDGUGyoiT2/hveh6H0fgGU= Received: from skull.home.blih.net (lfbn-idf2-1-1209-45.w90-92.abo.wanadoo.fr [90.92.34.45]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 4ae7e8b7 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 21 Apr 2022 13:45:55 +0000 (UTC) Date: Thu, 21 Apr 2022 15:45:55 +0200 From: Emmanuel Vadot To: Michael Butler Cc: freebsd-current Subject: Re: 'set but unused' breaks drm-*-kmod Message-Id: <20220421154555.8a69a542d97d6cf36472b75f@bidouilliste.com> In-Reply-To: References: <263e16c4-0634-88e6-9652-50d0874f027e@protected-networks.net> <20220421094236.3f023ac540666c140c04f884@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Kkf2D736Xz4cyL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=mfoLKQg2; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-1.84 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.66)[0.655]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 21 Apr 2022 08:51:26 -0400 Michael Butler wrote: > On 4/21/22 03:42, Emmanuel Vadot wrote: > > > > Hello Michael, > > > > On Wed, 20 Apr 2022 23:39:12 -0400 > > Michael Butler wrote: > > > >> Seems this new requirement breaks kmod builds too .. > >> > >> The first of many errors was (I stopped chasing them all for lack of > >> time) .. > >> > >> --- amdgpu_cs.o --- > >> /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26: > >> error: variable 'priority' set but not used > >> [-Werror,-Wunused-but-set-variable] > >> enum drm_sched_priority priority; > >> ^ > >> 1 error generated. > >> *** [amdgpu_cs.o] Error code 1 > >> > > > > How are you building the port, directly or with PORTS_MODULES ? > > I do make passes on the warning for drm and I did for set-but-not-used > > case but unfortunately this option doesn't exists in 13.0 so I couldn't > > apply those in every branch. > > I build this directly on -current. I'm guessing that these are what > triggered this behaviour: > > commit 8b83d7e0ee54416b0ee58bd85f9c0ae7fb3357a1 > Author: John Baldwin > Date: Mon Apr 18 16:06:27 2022 -0700 > > Make -Wunused-but-set-variable a fatal error for clang 13+ for > kernel builds. > > Reviewed by: imp, emaste > Differential Revision: https://reviews.freebsd.org/D34949 > > commit 615d289ffefe2b175f80caa9b1e113c975576472 > Author: John Baldwin > Date: Mon Apr 18 16:06:14 2022 -0700 > > Re-enable set but not used warnings for kernel builds. > > make tinderbox now passes with this warning enabled as a fatal error, > so revert the change to hide it in preparation for making it fatal. > > This reverts commit e8e691983bb75e80153b802f47733f1531615fa2. > > Reviewed by: imp, emaste > Differential Revision: https://reviews.freebsd.org/D34948 > > Ok I see, I won't have time until monday (maybe tuesday to fix this) but if someone wants to beat me to it we should add some new CWARNFLAGS for each problematic files in the 5.4-lts and 5.7-table branches of drm-kmod (master which is following 5.10 is already good) only if $ {COMPILER_VERSION} >= 130000. Cheers, -- Emmanuel Vadot From nobody Thu Apr 21 15:03:39 2022 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 6BF27198C8F5; Thu, 21 Apr 2022 15:03:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KkgmC3kWZz3C8k; Thu, 21 Apr 2022 15:03:55 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 23LF3fOI049797 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 21 Apr 2022 08:03:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 23LF3doS049796; Thu, 21 Apr 2022 08:03:39 -0700 (PDT) (envelope-from sgk) Date: Thu, 21 Apr 2022 08:03:39 -0700 From: Steve Kargl To: Emmanuel Vadot Cc: freebsd-current@freebsd.org, freebsd-x11@freebsd.org Subject: Re: Daily black screen of death Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <20220421094404.11cdf22e45c8bee5fc749ba5@bidouilliste.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: <20220421094404.11cdf22e45c8bee5fc749ba5@bidouilliste.com> X-Rspamd-Queue-Id: 4KkgmC3kWZz3C8k X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [1.38 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.04)[-0.043]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(0.46)[0.460]; NEURAL_SPAM_SHORT(0.97)[0.968]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-x11]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Thu, Apr 21, 2022 at 09:44:04AM +0200, Emmanuel Vadot wrote: > > Hello Steve, > > On Tue, 19 Apr 2022 11:32:32 -0700 > Steve Kargl wrote: > > > FYI, > > > > I'm experiencing an almost daily black screen of death panic. > > Kernel, world, drm-current-kmod, and gpu-firmware-kmod were > > all rebuilt and installed at the same time. Uname shows > > > > FreeBSD 14.0-CURRENT #0 main-n254360-eb9d205fa69: Tue Apr 5 13:49:47 PDT 2022 > > > > So, April 5th sources. > > > > The panic results in a keyboard lock and no dump. The system > > does not have a serial console. Only recourse is a hard rest. > > > > Hand transcribed from photo > > > > _sleep() at _sleep+0x38a/frame 0xfffffe012b7c0680 > > buf_daemon_shutdown() at buf_daemon_shutdown+0x6b/frame 0xfffffe012b7c06a0 > > kern_reboot() at kern_reboot+0x2ae/frame 0xfffffe012b7c06e0 > > vpanic() at vpanic+0x1ee/frame 0xfffffe012b7c0730 > > panic() at panic+0x43/frame 0xfffffe012b7c0790 > > > > Above repeats 100s of time scrolling off the screen with ever > > increasing frame pointer. > > > > Final message, > > > > mi_switch() at mi_switch+0x18e/frame 0xfffffe012b7c14b0 > > __mtx_lock_sleep() at __mtx_lock_sleep+0x173/frame 0xfffffe012b7c1510 > > __mtx_lock_flags() at __mtx_lock_flags+0xc0/frame 0xfffffe012b7c1550 > > linux_wake_up() at linux_wake_up+0x38/frame 0xfffffe012b7c15a0 > > radeon_fence_is_signaled() at radeon_fence_is_signaled+0x99/frame 0xfffffe012b7c15f0 > > dma_resv_add_shared_fence() at dma_resv_add_shared_fence+0x99/frame 0xfffffe012b7c1640 > > ttm_eu_fence_buffer_objects() at ttm_eu_fence_buffer_objects+0x79/frame 0xfffffe012b7c1680 > > radeon_cs_parser_fini() at radeon_cs_parser_fini+0x53/frame 0xfffffe012b7c16b0 > > radeaon_cs_ioctl() at radeaon_cs_ioctl+0x75e/frame 0xfffffe012b7c1b30 > > drm_ioctl_kernel() at drm_ioctl_kernel+0xc7/frame 0xfffffe012b7c1b80 > > drm_ioctl() at drm_ioctl+0x2c3/frame 0xfffffe012b7c1c70 > > linux_file_ioctl() at linux_file_ioctl+0x309/frame 0xfffffe012b7c1cd0 > > kern_ioctl() at kern_ioctl+0x1dc/frame 0xfffffe012b7c1d40 > > sys_ioctl() at sys_ioctl+0x121/frame 0xfffffe012b7c1e10 > > amd64_syscall() at amd64_syscall+0x108/frame 0xfffffe012b7c1f30 > > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe012b7c1f30 > > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x36a096c34ea, rsp = 0x3fa11e623eb8, \ > > rbp = 0x3fa11e623ee0 --- > > panic: _sleep: curthread not running > > cpuid = 4 > > time = 1650389478 > > KDB: stack backtrace: > > > > One common trigger appears to be the use of firefox-99.0,2 from > > the ports collection. > > > > -- > > Steve > > > > What version of drm are you using ? > Since when do you experience this ? > drm as not changed much for a long time now except adapting a few > files for new linuxkpi addition. > drm-current-kmod-5.4.144.g20220223 gpu-firmware-kmod-g20210330 I upgraded a Jan 2022 kernel+world+drm+gpu 2 to 3 weeks ago. The Jan 2022 system just worked. I've had the problem since the upgrade. I've also rebuild firefox, libdrm, the X-server, and X11 libraries. Still see the panic. As the panic messages scroll off the screen, I'm not sure the above last bit is the actual cause or simply a side effect. Some additional info from a dmesg after the reboot. WARNING: / was not properly dismounted [drm] radeon kernel modesetting enabled. drmn0: on vgapci0 vgapci0: child drmn0 requested pci_enable_io vgapci0: child drmn0 requested pci_enable_io sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)! [drm] initializing kernel modesetting (CAICOS 0x1002:0x6779 0x1092:0x6450 0x00). [drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO for ATOM IIO ATOM BIOS: C26401 drmn0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) drmn0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF [drm] Detected VRAM RAM=1024M, BAR=256M [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 8359708 KiB [TTM] Zone dma32: Available graphics memory: 2097152 KiB [TTM] Initializing pool allocator [drm] radeon: 1024M of VRAM memory ready [drm] radeon: 1024M of GTT memory ready. [drm] Loading CAICOS Microcode drmn0: successfully loaded firmware image 'radeon/CAICOS_pfp.bin' drmn0: successfully loaded firmware image 'radeon/CAICOS_me.bin' drmn0: successfully loaded firmware image 'radeon/BTC_rlc.bin' drmn0: successfully loaded firmware image 'radeon/CAICOS_mc.bin' drmn0: successfully loaded firmware image 'radeon/CAICOS_smc.bin' [drm] Internal thermal controller with fan control [drm] radeon: dpm initialized drmn0: successfully loaded firmware image 'radeon/SUMO_uvd.bin' [drm] GART: num cpu pages 262144, num gpu pages 262144 [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000). drmn0: WB enabled drmn0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0x0xfffff8000be96c00 drmn0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0x0xfffff8000be96c0c drmn0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0x0xfffff800c0072118 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. drmn0: radeon: MSI limited to 32-bit drmn0: radeon: using MSI. [drm] radeon: irq initialized. [drm] ring test on 0 succeeded in 4 usecs [drm] ring test on 3 succeeded in 6 usecs [drm] ring test on 5 succeeded in 3 usecs [drm] UVD initialized successfully. [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 0 usecs [drm] ib test on ring 5 succeeded [drm] Connector HDMI-A-1: get mode from tunables: [drm] - kern.vt.fb.modes.HDMI-A-1 [drm] - kern.vt.fb.default_mode [drm] Connector DVI-I-1: get mode from tunables: [drm] - kern.vt.fb.modes.DVI-I-1 [drm] - kern.vt.fb.default_mode [drm] Connector VGA-1: get mode from tunables: [drm] - kern.vt.fb.modes.VGA-1 [drm] - kern.vt.fb.default_mode [drm] Radeon Display Connectors [drm] Connector 0: [drm] HDMI-A-1 [drm] HPD2 [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY1 [drm] Connector 1: [drm] DVI-I-1 [drm] HPD4 [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY [drm] Connector 2: [drm] VGA-1 [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] fb mappable at 0xC0363000 [drm] vram apper at 0xC0000000 [drm] size 8294400 [drm] fb depth is 24 [drm] pitch is 7680 WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0. VT: Replacing driver "vga" with new "fb". taskqueue_drain with the following non-sleepable locks held: exclusive sleep mutex vtdev (vtdev) r = 0 (0xffffffff80c8a750) locked @ /usr/src/sys/dev/vt/vt_core.c:3061 stack backtrace: #0 0xffffffff80690415 at witness_debugger+0x65 #1 0xffffffff80691579 at witness_warn+0x3e9 #2 0xffffffff80683363 at taskqueue_drain+0x33 #3 0xffffffff818b6383 at vt_kms_postswitch+0x73 #4 0xffffffff804d5d04 at vt_fb_init+0xf4 #5 0xffffffff804dcb89 at vt_replace_backend+0x109 #6 0xffffffff804d5e13 at vt_fb_attach+0x13 #7 0xffffffff818b6e80 at linux_register_framebuffer+0x510 #8 0xffffffff818be1f9 at __drm_fb_helper_initial_config_and_unlock+0x459 #9 0xffffffff817b7f5e at radeon_fbdev_init+0xde #10 0xffffffff817b3cb6 at radeon_modeset_init+0x8d6 #11 0xffffffff817c095a at radeon_driver_load_kms+0x16a #12 0xffffffff8188e5f6 at drm_dev_register+0xe6 #13 0xffffffff817b7160 at radeon_pci_probe+0x230 #14 0xffffffff8083e151 at linux_pci_attach_device+0x431 #15 0xffffffff8065cb71 at device_attach+0x3c1 #16 0xffffffff8065e820 at bus_generic_driver_added+0x90 #17 0xffffffff8065a3d9 at devclass_driver_added+0x39 Sleeping on "tq_drain" with the following non-sleepable locks held: exclusive sleep mutex vtdev (vtdev) r = 0 (0xffffffff80c8a750) locked @ /usr/src/sys/dev/vt/vt_core.c:3061 stack backtrace: #0 0xffffffff80690415 at witness_debugger+0x65 #1 0xffffffff80691579 at witness_warn+0x3e9 #2 0xffffffff80632494 at _sleep+0x54 #3 0xffffffff8068342b at taskqueue_drain+0xfb #4 0xffffffff818b6383 at vt_kms_postswitch+0x73 #5 0xffffffff804d5d04 at vt_fb_init+0xf4 #6 0xffffffff804dcb89 at vt_replace_backend+0x109 #7 0xffffffff804d5e13 at vt_fb_attach+0x13 #8 0xffffffff818b6e80 at linux_register_framebuffer+0x510 #9 0xffffffff818be1f9 at __drm_fb_helper_initial_config_and_unlock+0x459 #10 0xffffffff817b7f5e at radeon_fbdev_init+0xde #11 0xffffffff817b3cb6 at radeon_modeset_init+0x8d6 #12 0xffffffff817c095a at radeon_driver_load_kms+0x16a #13 0xffffffff8188e5f6 at drm_dev_register+0xe6 #14 0xffffffff817b7160 at radeon_pci_probe+0x230 #15 0xffffffff8083e151 at linux_pci_attach_device+0x431 #16 0xffffffff8065cb71 at device_attach+0x3c1 #17 0xffffffff8065e820 at bus_generic_driver_added+0x90 lock order reversal: (Giant after non-sleepable) 1st 0xffffffff80c8a750 vtdev (vtdev, sleep mutex) @ /usr/src/sys/dev/vt/vt_core.c:3061 2nd 0xffffffff80c02840 Giant (Giant, sleep mutex) @ /usr/src/sys/kern/kern_synch.c:232 lock order Giant -> vtdev established at: #0 0xffffffff8068f733 at witness_checkorder+0x323 #1 0xffffffff80609689 at __mtx_lock_flags+0x99 #2 0xffffffff804dc186 at vt_upgrade+0x2d6 #3 0xffffffff805b98a3 at mi_startup+0x123 #4 0xffffffff802ca3b2 at btext+0x22 lock order vtdev -> Giant attempted at: #0 0xffffffff8068ffdb at witness_checkorder+0xbcb #1 0xffffffff80609689 at __mtx_lock_flags+0x99 #2 0xffffffff8063277d at _sleep+0x33d #3 0xffffffff8068342b at taskqueue_drain+0xfb #4 0xffffffff818b6383 at vt_kms_postswitch+0x73 #5 0xffffffff804d5d04 at vt_fb_init+0xf4 #6 0xffffffff804dcb89 at vt_replace_backend+0x109 #7 0xffffffff804d5e13 at vt_fb_attach+0x13 #8 0xffffffff818b6e80 at linux_register_framebuffer+0x510 #9 0xffffffff818be1f9 at __drm_fb_helper_initial_config_and_unlock+0x459 #10 0xffffffff817b7f5e at radeon_fbdev_init+0xde #11 0xffffffff817b3cb6 at radeon_modeset_init+0x8d6 #12 0xffffffff817c095a at radeon_driver_load_kms+0x16a #13 0xffffffff8188e5f6 at drm_dev_register+0xe6 #14 0xffffffff817b7160 at radeon_pci_probe+0x230 #15 0xffffffff8083e151 at linux_pci_attach_device+0x431 #16 0xffffffff8065cb71 at device_attach+0x3c1 #17 0xffffffff8065e820 at bus_generic_driver_added+0x90 start FB_INFO: type=11 height=1080 width=1920 depth=32 cmsize=16 size=8294400 pbase=0xc0363000 vbase=0xfffff800c0363000 name=drmn0 flags=0x0 stride=7680 bpp=32 cmap[0]=0 cmap[1]=7f0000 cmap[2]=7f00 cmap[3]=c4a000 end FB_INFO drmn0: fb0: radeondrmfb frame buffer device [drm] Initialized radeon 2.50.0 20080528 for drmn0 on minor 0 -- steve From nobody Thu Apr 21 16:38:35 2022 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 1B44D11D9D50 for ; Thu, 21 Apr 2022 16:38:44 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91]) by mx1.freebsd.org (Postfix) with ESMTP id 4Kkjsb07Ysz3qxc for ; Thu, 21 Apr 2022 16:38:42 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) IronPort-SDR: Oxb0QkHfuzd96W7nqZa3jTRObFgbe5keEkLQlTk3utBhms6OaQYqqrM9gCOLoQflMpP8pAiUNb e9viX4i496+i6IpRpqKe5NE8WwHPknhK8= X-Ambrisko-Me: Yes IronPort-Data: A9a23:6trXMq/jLF+Wx+4uPXHRDrUDlH6TJUtcMsCJ2f8bNWPcYEJGY0x3m GFKC2GPOv+LZmDwfNlyOYqw8R4C7MTWmtNlQANo+HhgHilAwSbn6XR1DatR0we6dJCroHqKY 6zyU/GYRCwOZia0SiqFadANk1EtjMlkeZKsUIYoCggpLeNVYH9JZSBLwobVsaY06TSNOD5hj PupyyHp1P9J7BYvWo4cw/rrRBqCJ50eshtA1rA1TagjUFMzCxD5pX/CTJxdIUcUQqEMdgK7b +fF0Lyj+GrduR4oAMmkibX8NEYNR9Y+PyDX2yAQAvbyxEEE/ETe0Y5jXBYYQU5SgS+IhNN24 NxIv4axUgQueKbLnYzxVjEFSnshZvcuFLjvZCLXXdao52TCfmvlxfljFmkyMIwU++B4DHsI8 /EEQBgIbB+eleO16L2+Q+howM8kKaHDMpkSt3t7wXTSEOw8TJbfa6vQ6NJSxzt2gdpBdcsyz eJxhSFHdxnafRBVYBEeDZgknfyrgT/0dDgwlb5cnoJvi0C78eC7+OGF3AP9doPYSMNLsFyfo 26arW31DgtAbY6WzDCf82mvgcfGmCnhWZkRE/uz8fsz2A+fwWkaCRs3U1qnoKnk0hfvB4oHc 0FEqDAzqaUS9VCwSoWvVROPv3PZ7AUXXMBdErNm5VjVmLbU+QuQGkMNUiVFNI49rMYzSDFzj g2JktrlCCZBqrqQTX7BpL6YoSnoYHocKGUYZDQHSiMM5tP5oZowiVTESdM6SPy5idj8GDfRx TGWrXhj3+xC0ZZTj6jipALJmTOhoJTNXzUZ3ASPUzL39B59aa6ke5estQrR48FfIdvLVVKGp nUFxZSTtbhcEZGXmSWRa+wRB7X1te2dOTjRjFMzTZks8zOhpyyqcYxKumgsJUF1P9wCcDuva UrZowJK55gVN3yvNPclb4W0AsUs7K7hCdW1C6iNP4YWOsB8JF2d4SVjRU+MxGS8wkEjnJY2N YqfbcvxX20RDr5qzWbuSupBg6UnwDsymTHaSZzhlUz1yreEenOPE/EMNVGUb/s66+WPpwCMq 4RTMM6DyhN+VuziY3mKqddCcQhSdXVrV4rrr8F3d/KYJls0EW4sPPbd3Lc9dtE3hK9SjOrJo imwV0IwJIATXpEbxdFmskxeVY4= IronPort-HdrOrdr: A9a23:Vh73U6lt1J0urNRgXvqQmAQVYePpDfIs3DAbv31ZSRFFG/FwWf rOoB0+726StN9xYgBFpTnuAsW9qB/nmqKdpLNhW4tKPzOW3VdATrsSjrcKqgeIc0aSygce79 YDT0EUMr3N5DZB4/oT0GODeeod/A== Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 21 Apr 2022 08:35:07 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 23LGcZ8o074385 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 21 Apr 2022 09:38:35 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com Received: (from ambrisko@localhost) by ambrisko.com (8.17.1/8.17.1/Submit) id 23LGcZ7o074384; Thu, 21 Apr 2022 09:38:35 -0700 (PDT) (envelope-from ambrisko) Date: Thu, 21 Apr 2022 09:38:35 -0700 From: Doug Ambrisko To: Alexander Leidinger Cc: Mateusz Guzik , freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues Message-ID: References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="HAyyfbF3IpFncfdR" Content-Disposition: inline In-Reply-To: <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> X-Rspamd-Queue-Id: 4Kkjsb07Ysz3qxc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com X-Spamd-Result: default: False [-1.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; FREEFALL_USER(0.00)[ambrisko]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-diff]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[ambrisko.com]; HAS_ATTACHMENT(0.00)[]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --HAyyfbF3IpFncfdR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 21, 2022 at 03:44:02PM +0200, Alexander Leidinger wrote: | Quoting Mateusz Guzik (from Thu, 21 Apr 2022 | 14:50:42 +0200): | | > On 4/21/22, Alexander Leidinger wrote: | >> I tried nocache on a system with a lot of jails which use nullfs, | >> which showed very slow behavior in the daily periodic runs (12h runs | >> in the night after boot, 24h or more in subsequent nights). Now the | >> first nightly run after boot was finished after 4h. | >> | >> What is the benefit of not disabling the cache in nullfs? I would | >> expect zfs (or ufs) to cache the (meta)data anyway. | >> | > | > does the poor performance show up with | > https://people.freebsd.org/~mjg/vnlru_free_pick.diff ? | | I would like to have all the 22 jails run the periodic scripts a | second night in a row before trying this. | | > if the long runs are still there, can you get some profiling from it? | > sysctl -a before and after would be a start. | > | > My guess is that you are the vnode limit and bumping into the 1 second sleep. | | That would explain the behavior I see since I added the last jail | which seems to have crossed a threshold which triggers the slow | behavior. | | Current status (with the 112 nullfs mounts with nocache): | kern.maxvnodes: 10485760 | kern.numvnodes: 3791064 | kern.freevnodes: 3613694 | kern.cache.stats.heldvnodes: 151707 | kern.vnodes_created: 260288639 | | The maxvnodes value is already increased by 10 times compared to the | default value on this system. I've attached mount.patch that when doing mount -v should show the vnode usage per filesystem. Note that the problem I was running into was after some operations arc_prune and arc_evict would consume 100% of 2 cores and make ZFS really slow. If you are not running into that issue then nocache etc. shouldn't be needed. On my laptop I set ARC to 1G since I don't use swap and in the past ARC would consume to much memory and things would die. When the nullfs holds a bunch of vnodes then ZFS couldn't release them. FYI, on my laptop with nocache and limited vnodes I haven't run into this problem. I haven't tried the patch to let ZFS free it's and nullfs vnodes on my laptop. I have only tried it via bhyve test. I use bhyve and a md drive to avoid wearing out my SSD and it's faster to test. I have found the git, tar, make world etc. could trigger the issue before but haven't had any issues with nocache and capping vnodes. Thanks, Doug A. --HAyyfbF3IpFncfdR Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="mount.patch" diff --git a/sbin/mount/mount.c b/sbin/mount/mount.c index 79d9d6cb0ca..00eefb3a5e0 100644 --- a/sbin/mount/mount.c +++ b/sbin/mount/mount.c @@ -692,6 +692,13 @@ prmount(struct statfs *sfp) xo_emit("{D:, }{Lw:fsid}{:fsid}", fsidbuf); free(fsidbuf); } + if (sfp->f_nvnodelistsize != 0 || sfp->f_lazyvnodelistsize != 0) { + xo_open_container("vnodes"); + xo_emit("{D:, }{Lwc:vnodes}{Lw:count}{w:count/%ju}{Lw:lazy}{:lazy/%ju}", + (uintmax_t)sfp->f_nvnodelistsize, + (uintmax_t)sfp->f_lazyvnodelistsize); + xo_close_container("vnodes"); + } } xo_emit("{D:)}\n"); } diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c index a495ad86ac4..3648ef8d080 100644 --- a/sys/kern/vfs_mount.c +++ b/sys/kern/vfs_mount.c @@ -2625,6 +2626,8 @@ __vfs_statfs(struct mount *mp, struct statfs *sbp) sbp->f_version = STATFS_VERSION; sbp->f_namemax = NAME_MAX; sbp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK; + sbp->f_nvnodelistsize = mp->mnt_nvnodelistsize; + sbp->f_lazyvnodelistsize = mp->mnt_lazyvnodelistsize; return (mp->mnt_op->vfs_statfs(mp, sbp)); } diff --git a/sys/sys/mount.h b/sys/sys/mount.h index 3383bfe8f43..95dd3c76ae5 100644 --- a/sys/sys/mount.h +++ b/sys/sys/mount.h @@ -91,7 +91,9 @@ struct statfs { uint64_t f_asyncwrites; /* count of async writes since mount */ uint64_t f_syncreads; /* count of sync reads since mount */ uint64_t f_asyncreads; /* count of async reads since mount */ - uint64_t f_spare[10]; /* unused spare */ + uint32_t f_nvnodelistsize; /* (i) # of vnodes */ + uint32_t f_lazyvnodelistsize; /* (l) # of lazy vnodes */ + uint64_t f_spare[9]; /* unused spare */ uint32_t f_namemax; /* maximum filename length */ uid_t f_owner; /* user that mounted the filesystem */ fsid_t f_fsid; /* filesystem id */ --HAyyfbF3IpFncfdR-- From nobody Thu Apr 21 16:49:02 2022 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 4B20011DCE83 for ; Thu, 21 Apr 2022 16:49:04 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91]) by mx1.freebsd.org (Postfix) with ESMTP id 4Kkk5W35x2z3smZ for ; Thu, 21 Apr 2022 16:49:03 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) IronPort-SDR: aanghzseMsgfgaKliHOonJuZdmnhikJLr6IWp1E8L13vPR8h8w+NA0k6IcxXy8WqrLN0E9I8S1 bAwGuAshAp8ex4b1IsBV6fZ5cN1t74IP4= X-Ambrisko-Me: Yes IronPort-Data: A9a23:LRuywKt8iReaoOwfofSwpm5Y+efnVEJeMUV32f8akzHdYApBsoF/q tZmKW6GP62LN2b9fI8nPdi+o09X7JGHm4VqTAZk/npkFHgTpJueD7x1DKtQ0wB+jyHnZBg6h ykmh1WpwPkcFhcwnD/0WlTchSIUOZ+gF+OU5NHsangZqT9MEE/NuDo78wILqtcAbeuRX2thj ejPT/j3YzdJ7dLU3lU8sMpvoDs31Bj7VahxUlYWPZint3eG/5UZ4Q52yQhc8hLFrodo8u6SH 44vzZm4+H/U5REkDpWsl7zhc1YJRfjZOg3mZnh+Avn4xEEc9mprlPxT2Pk0MS+7jx2Amtpry c5OsrS5TA0zP7bPn6IWVBww/yRWYPQcp+SaSZS4mYnJp6HcSFPFx/h+BUc6MJcw/ut2DWBI+ vECbjYAcnirguC53aC6ScFjg80iKI/gO4Z3kn96wDzTFvpjSo3ZWajM+fdWxjo9jNtCW/HEa KIkhZBHBPjbSwZCIEkaEsh4leKinHjkcDoeo1WQzZfbKlP7lGRZuIUB+vKMEjBTbckKzEueu Ezc+GH1XkMTONCFk2PX+3emnO7UniTTUYcYDryj9fksi1qWnzRBBBoTXFq9gP+4lk/uBooGe hBMonIj/foo6UimbtjhRBnk8nSKiQERBohLGOog5QDTlqeNu1SFBnIJRyJqYcA9sJNkXiQj0 1KExou7BTFmvLCPZ2ia87OY8WG7NSQPdzZQbCoOVwoe4N7LqYQ5lBPUTdElG6mw14WnFTb1y jGMjS4/m7RD0JZShvnjpQjK2mv+qILIQwg54hTscliktg4pNpS4Y4GI6ETA6aoSJoiuUVTc7 mMPnNKT7b5SAMjVxjCNWugEAJqg++2BbG/HmVdqEpQsq2at9nqkcdwC6T1yPh0wYMcCZTLzZ kbX/wpU7oVSJ3itK6RwZtvpWcgtyKHhE/XjV+zVPocWO8ktLFff8XE8f1OU0kDsjFMowPM2N pqseMqxCWoXVPZ8xz2sSuZBibImmnIkyWXIScypxhiry+DGNmWYU6kIKgHIZ+Uz9qKfowKT+ NFabpPYxxJaWez4Qy/W7Y9DcAhTfCRjXcj7+55Na+qOAgt6A2VwWfbezIQod5Fhg6kIxPzD+ WuwWxMAxVfy7ZEdxd5mtpy3hGvTYKtC IronPort-HdrOrdr: A9a23:52+F2K1rSMbKA+AbE90oHgqjBLIkLtp133Aq2lEZdPWaSK2lfu SV7ZMmPH7P+VIssR4b9exoVJPufZqYz+8S3WBzB8bGYOCFghrKEGgK1+KLqFDd8m/Fh4xgPM xbE5SWZuefMbBL5/yR3DWF Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 21 Apr 2022 08:45:34 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 23LGn27L075125 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 21 Apr 2022 09:49:02 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com Received: (from ambrisko@localhost) by ambrisko.com (8.17.1/8.17.1/Submit) id 23LGn2hU075124; Thu, 21 Apr 2022 09:49:02 -0700 (PDT) (envelope-from ambrisko) Date: Thu, 21 Apr 2022 09:49:02 -0700 From: Doug Ambrisko To: Alexander Leidinger Cc: Mateusz Guzik , freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues Message-ID: References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> 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: <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> X-Rspamd-Queue-Id: 4Kkk5W35x2z3smZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com X-Spamd-Result: default: False [-0.48 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.866]; FREEFALL_USER(0.00)[ambrisko]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[ambrisko.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.39)[0.391]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Apr 21, 2022 at 03:44:02PM +0200, Alexander Leidinger wrote: | Quoting Mateusz Guzik (from Thu, 21 Apr 2022 | 14:50:42 +0200): | | > On 4/21/22, Alexander Leidinger wrote: | >> I tried nocache on a system with a lot of jails which use nullfs, | >> which showed very slow behavior in the daily periodic runs (12h runs | >> in the night after boot, 24h or more in subsequent nights). Now the | >> first nightly run after boot was finished after 4h. | >> | >> What is the benefit of not disabling the cache in nullfs? I would | >> expect zfs (or ufs) to cache the (meta)data anyway. | >> | > | > does the poor performance show up with | > https://people.freebsd.org/~mjg/vnlru_free_pick.diff ? | | I would like to have all the 22 jails run the periodic scripts a | second night in a row before trying this. | | > if the long runs are still there, can you get some profiling from it? | > sysctl -a before and after would be a start. | > | > My guess is that you are the vnode limit and bumping into the 1 second sleep. | | That would explain the behavior I see since I added the last jail | which seems to have crossed a threshold which triggers the slow | behavior. | | Current status (with the 112 nullfs mounts with nocache): | kern.maxvnodes: 10485760 | kern.numvnodes: 3791064 | kern.freevnodes: 3613694 | kern.cache.stats.heldvnodes: 151707 | kern.vnodes_created: 260288639 | | The maxvnodes value is already increased by 10 times compared to the | default value on this system. With the patch, you shouldn't mount with nocache! However, you might want to tune: vfs.zfs.arc.meta_prune vfs.zfs.arc.meta_adjust_restarts Since the code on restart will increment the prune amount by vfs.zfs.arc.meta_prune and submit that amount to the vnode reclaim code. So then it will end up reclaiming a lot of vnodes. The defaults of 10000 * 4096 and submitting it each loop can most of the cache to be freed. With relative small values of them, then the cache didn't shrink to much. Doug A. From nobody Fri Apr 22 02:16:42 2022 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 6C27411D53D0 for ; Fri, 22 Apr 2022 02:16:53 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kkyhh235tz3Jl0 for ; Fri, 22 Apr 2022 02:16:52 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1650593804; 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=O3a9JFzHB+e8k7I0g4jNizcmOFjpxb+MRMCON7LL+Ss=; b=VkvDuH/SpG48OZUiZCAwmOxHOSUq5O+HkCbK5mozZJQhlhEjZACNgfHqNT0EIUdU+ZP+Lg MPyppO8BKV5GdjtVA4CZUbf7oi+6HJPL8Drfd8EntLPfdSGhXMhdEf6zusWF/OI/dg+2ee 9FnSWs2WKxvGcAPzOkbvsuYXT8/jBhM= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id bdf083d9 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 22 Apr 2022 02:16:43 +0000 (UTC) Message-ID: Date: Thu, 21 Apr 2022 19:16:42 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: FreeBSD Current From: Pete Wright Subject: Chasing OOM Issues - good sysctl metrics to use? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Kkyhh235tz3Jl0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b="VkvDuH/S"; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-2.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N hello - on my workstation running CURRENT (amd64/32g of ram) i've been running into a scenario where after 4 or 5 days of daily use I get an OOM event and both chromium and firefox are killed.  then in the next day or so the system will become very unresponsive in the morning when i unlock my screensaver in the morning forcing a manual power cycle. one thing i've noticed is growing swap usage but plenty of free and inactive memory as well as a GB or so of memory in the Laundry state according top.  my understanding is that seeing swap usage grow over time is expected and doesn't necessarily indicate a problem.  but what concerns me is the system locking up while seeing quite a bit of disk i/o (maybe from paging back in?). in order to help chase this down i've setup the prometheus_sysctl_exporter(8) to send data to a local prometheus instance.  the goal is to examine memory utilizaton over time to help detect any issues. so my question is this: what OID's would be useful to help see to help diagnose weird memory issues like this? i'm currently looking at: sysctl_vm_domain_0_stats_laundry sysctl_vm_domain_0_stats_active sysctl_vm_domain_0_stats_free_count sysctl_vm_domain_0_stats_inactive_pps thanks in advance - and i'd be happy to share my data if anyone is interested :) -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Fri Apr 22 04:18:37 2022 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 93FEA199D43B for ; Fri, 22 Apr 2022 04:18:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kl1PP2vmgz3n4s for ; Fri, 22 Apr 2022 04:18:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650601122; bh=AMxRAcJHYP4a1MF9ItzIuqm55U2r3ahaAWjsIBNlmX0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=VdoxvGOFN6x6kkINGEOGQyYh2hl8GMQMpfARK/oKwAlLPPcCW7o54YrXm3nKHUSZiu3WmWjH+AurkaKwsjpD/S1+gtGPUEk0ygusZ5u0wk/qPaq295PS5hFjv+f31bmySqX5gcCgyxz0l90OeMnAmwhMlTl5v7zp47cyw91KsSd7rAMEMbw/7APCSTgy14GLfWtvGFpCBGhkU/9WgrlCmk+cmPd1lAW58eU1xfq4qdSUvCwZb+EFse1LLiAdE9KpGPTD56j3yhyBrWGuOFgCPfyjUyBjzaAso9rjPGVIZH4+I5AQ3ZAdK6pIsZ1Sjs1j1G4CrweGtO9Sl10A6DPL2g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650601122; bh=ClCHouNOIspJjnrLQgZmS9iMrS0KuNRC6rwCzO7pcwo=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=r/5aupZNsbwLmREC0txGhcvUX8yVOoMvfUfbOBj/Lhs0yWDZ1Q1v9Ma5fSGUjjSpGZ0FE4HOKEaMvtqaCAiYlJjRA9vRjp2HCYVB51eNS6f0zT3YCPpZN9QK9r6GjQoaT/1F7nNuYUOaBe1n8LM0telSUPa37bciD08i6anvmfwn85+Aw10lHobtCwWcFvkpu/IXITzF2TkQc/6Hz9qRpplidIAJfUkmPQeBZrdIJFPwD1oj8dkf7hvlv4ORlX+/pWEKlb7JQGN+mdNEiWKJgvHyFdpRN2KHc2ux/hA/jLyFxpB9VzvsVX8/VYQqmIxHVFuF5eWSUrQyMU97Du+20w== X-YMail-OSG: VPS2OUIVM1m0HTBzTaQs_eyfVAtELPiPWlh76p2Jj4Sg85IFZ43xxsgRapNJPqK 6ONL2kipuqtiY7OGMREFUQsobZPqRbtebIXhuFGB.eseCvYQrW0RsBks0O8HTgM3KEKtxwKhuDuH 4qbtu5vFpZt3h7_60pxYZfpbV771ZLdz_yBvObOGsxgMLpg0g_UpM0.ErGAqVqGq7zebiAI.oCt0 U7n6uraSHLqAz6_aWL1GQ03cu74_F.aKTjEqvo.Z_aHEBQEOzZFlJHqzOQqfjf18db2Rx0qpyDJZ XmKUtzqQvWxesBBNQYL9EJ5RYpqsqghEbgteVTUPq3mlKNPQV7pVXkzAvs.KBO7_F_OU0To7FvbR Wi2wE2wFeQdwrZz1cakwoxldA14xjqYrfbPJ5z_WavLza3fqsc8vJR3Ps4ZYiirtr1ZKMlq45JCV Obr85HVjmhmkDVIADFeFplliu32HWKFQNH387i7hFxcZ86m4q91MmjFMGjfhLYApqSd5elaVc_2L QGoj44tssJJPSyVRHd51fRpCjeSPTIXSe1zKbJSH2K4UExEv7Uglm7f4tYtSOVVm7VENph4k7zEe KQQyMEyxL5oIhYhaixEEICPP1Fuaop7SwjPebdxqW1tEPP0UoIjpCrTFTMeP9uuvqevO.gbF6f83 g4JafTzNVm8Ki8YF1rdas.5pAmpLyRWPTDb0EYGqI3Q7pkLr0g0ZKoZn6ahIg1pQcyYwIBo_CsJ2 5bO5sFhAY5YMboUYjQRao6KczRy2mpP7tRHVl3Qy1W0x1B5VxlS7eOq8gZ.GRKZfbLJ3xjoAnMnp fUbVyGFvb68Fc2TTcYlORvG0iLypCc2zOh5Om1hFXi_c2PJ8he92YDA6hAhfPqz5.Ef3XoxPerjJ TLd21H0Ama_tZ0fRqqui9cakzVGlw2LByXQklBHCFua4IGLgukivIXgiHAN7KAJH79lsXZYSDG87 JgLYpnICR..VS7gARfrrlRQMYTFrtMtzft.68pFAeto58eKDn0glEeWEzJ1mzyKT5Qh6_adVJVQa gYR4e4iB8oXlNf9oh.4qaF1FKFGXAp8yiFSy1nFbxUbx_zRsvvsxkSl.hNpfAcFFE2aZpqIHs4Oj QyyB66gZpVV049IN8u74wTPhnfC0yHcgr6iZjAo4FRXFsVz9XUoXGXuOAQK7oBZqmeSTU7J4B5.S sUtYUwI0fwGWlh.C8FMMN3CpYc2Z.IpE8PM6NSTEZcZIpAiA6RmWMO4Ho_iQLZafKFCQUBXS42sC dzcumM4b8baDV1PQaw.LB9_15F6t7PIhEtC2Eb01SaGT_0bKdyJLx4N9szf0QlZY8b5NZSJNvYAO _LYTUFaDQBmdyjAuE00DLQVWH1kPXJNUP345KVOZSg0NRaIzeJ7d4AOAHhu85_MX6RPYMxWvMGem DUrAopBHKz2KOWZ9DC24U6hYjHwt6MVo725zzlMR6a_9h8vKGcsjBvtIMy2AuEaejtYr7Ds_.xKi FPMNo0jphf.t.sC9tWIbJwMBLgo3MvM0RFObvqUT8rJX52k8WD40FrT.3h.vk3UiidgLlSLvTLq0 8MJoW2fdki5hzIxWoTNMT80iLcRl8ywyHLPJPEAzFzs_OF8zVloPP8lPvu6YqI4PfVLfXSJtsrXs vu_CpY5T39qCX0qykucLTDNchHakbb1HIZ_NQlA58ItPybE6yyfE4.OIAPdw9KFwPDLDK6Pdp6wT WlRdNs4JI3yOwfZR7M3YuW1Y8LayVrdX5DPUkyKoUv.3NDZp75HvrRjm686NeVwY43lqjZe.bzyn NWB5sAz8wBlxcZbisHGA1czixRqOjqi4qSEPXprbsfU4ZUNsZ4ziFAGaljMzSTZSi9_.0QSQvKxt rDNJ6RC1n7x4n0vSzfZHgWBA0UM7hfikUuBv4BmHCTOsDHh1csQLUz5hy.k6_GPt3.nGoeZaonwI kqMg1FGsIlf0dZQGczBN6J_Uf.Pa3TaZa43hJ3TvY9t_aGdHC4y6dAXR2plpOlP.cMftdrPTlWx. 3YTkJ0OQ59tjqzO7tdEPUO.IKRBgW7hrrtpXV8lJYFg4skc86c79stEi2eMRkl1BCFUe5wtlMHJf 1Nnm9ldPuPZU1pu.Btghf3GZI2U8dVL0ccvAuAoecwwE3dzJJuBNF94CngXTjqTo3pksfhb5kt04 KlxaMk0SptHSraoOkE1KF58qkJruNYvzP4Jt5tnbNSB8vUtcaTWkgPe59Y96B9b2aYd16eA0HU_n yx7WDqEBfEz2w5O1lnUUYpDHRVd8WBgsM_UizyFQgRMkQq7rVPN9jhz4SJ4k54yQrXy7XKPaysca 9qJVOdPmIGspE X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 22 Apr 2022 04:18:42 +0000 Received: by hermes--canary-production-ne1-6855c48695-8fndv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a024e799fcf82a1d9a56cdbcbe773ee9; Fri, 22 Apr 2022 04:18:38 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Message-Id: <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> Date: Thu, 21 Apr 2022 21:18:37 -0700 To: pete@nomadlogic.org, freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> X-Rspamd-Queue-Id: 4Kl1PP2vmgz3n4s X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=VdoxvGOF; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Pete Wright wrote on Date: Thu, 21 Apr 2022 19:16:42 -0700 : > on my workstation running CURRENT (amd64/32g of ram) i've been running=20= > into a scenario where after 4 or 5 days of daily use I get an OOM = event=20 > and both chromium and firefox are killed. then in the next day or so=20= > the system will become very unresponsive in the morning when i unlock = my=20 > screensaver in the morning forcing a manual power cycle. >=20 > one thing i've noticed is growing swap usage but plenty of free and=20 > inactive memory as well as a GB or so of memory in the Laundry state=20= > according top. my understanding is that seeing swap usage grow over=20= > time is expected and doesn't necessarily indicate a problem. but what=20= > concerns me is the system locking up while seeing quite a bit of disk=20= > i/o (maybe from paging back in?). >=20 > in order to help chase this down i've setup the=20 > prometheus_sysctl_exporter(8) to send data to a local prometheus=20 > instance. the goal is to examine memory utilizaton over time to help=20= > detect any issues. so my question is this: >=20 > what OID's would be useful to help see to help diagnose weird memory=20= > issues like this? >=20 > i'm currently looking at: > sysctl_vm_domain_0_stats_laundry > sysctl_vm_domain_0_stats_active > sysctl_vm_domain_0_stats_free_count > sysctl_vm_domain_0_stats_inactive_pps >=20 >=20 > thanks in advance - and i'd be happy to share my data if anyone is=20 > interested :) Messages in the console out would be appropriate to report. Messages might also be available via the following at appropriate times: # dmesg -a . . . or: # more /var/log/messages . . . Generally messages from after the boot is complete are more relevant. Messages like the following are some examples that would be of interest: pid . . .(c++), jid . . ., uid . . ., was killed: failed to reclaim = memory pid . . .(c++), jid . . ., uid . . ., was killed: a thread waited too = long to allocate a page pid . . .(c++), jid . . ., uid . . ., was killed: out of swap space (That last is somewhat of a misnomer for the internal issue that leads to it.) I'm hoping you got message(s) of one or more of the above kinds. But others are also relevant: . . . kernel: swap_pager: out of swap space . . . kernel: swp_pager_getswapspace(7): failed . . . kernel: swap_pager: indefinite wait buffer: bufobj: . . ., blkno: = . . ., size: . . . (Those messages do not announce a process kill but give some evidence about context.) Some of the messages with part of the text matching actually identify somewhat different contexts --so each message type is relevant. There may be other types of messages that are relevant. The sequencing of the messages could be relevant. Do you have any swap partitions set up and in use? The details could be relevant. Do you have swap set up some other way than via swap partition use? No swap? If 1+ swap partitions are in use, things that suggest the speeds/latency characteristics of the I/O to the drive could be relevant. ZFS (so with ARC)? UFS? Both? The first block of lines from a top display could be relevant, particularly when it is clearly progressing towards having the problem. (After the problem is too late.) (I just picked top as a way to get a bunch of the information all together automatically.) These sorts of things might help folks help you. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 22 07:04:39 2022 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 38B891A80C05 for ; Fri, 22 Apr 2022 07:04:49 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kl54v5Fvfz4dyT for ; Fri, 22 Apr 2022 07:04:47 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 88CBF7EF; Fri, 22 Apr 2022 09:04:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1650611084; 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=b1LWFXIqHVfRbZtCN42iEdLyBsyrwD80Fzi9VGeqmO8=; b=K+/PUFvm5x7ny63JSiDl1uyCLTlruQzEr9s9g/633zFkEM81Of4ZZxkMAcKoJgY2tSe/bE QoQTdAcwg+UtGInLllye4aMX2pPMVm23llK+bDhnQeHVN4c11EOHx9BRGCgNOCnpN7EPW0 Z0ZGbqhoLadFtXHa2gyQ4pr4h/YAcxV8bzQYrqL+0H+8rs8Hq3ezBQ6d9bKFJVQZtpvIPQ fpdOvL+lBWTow3GZVwSpNo78qrSP2srV7v2Xx1VijscOW0KkC/LfMDWGy+DH7WRqKlyz2s 8YeSVOMbUaRBmzn+ClvyVIAysd7TQuvpct/yb6emhvvSiD5lOuC+BbfwJ+RXTA== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 715F14683; Fri, 22 Apr 2022 09:04:40 +0200 (CEST) Date: Fri, 22 Apr 2022 09:04:39 +0200 Message-ID: <20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN@webmail.leidinger.net> From: Alexander Leidinger To: Doug Ambrisko Cc: Mateusz Guzik , freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_OOmCLJCGKh7pUIN2ebU7UkJ"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4Kl54v5Fvfz4dyT X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b="K+/PUFvm"; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-6.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_OOmCLJCGKh7pUIN2ebU7UkJ Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Doug Ambrisko (from Thu, 21 Apr 2022=20=20 09:38:35=20-0700): > On Thu, Apr 21, 2022 at 03:44:02PM +0200, Alexander Leidinger wrote: > | Quoting Mateusz Guzik (from Thu, 21 Apr 2022 > | 14:50:42 +0200): > | > | > On 4/21/22, Alexander Leidinger wrote: > | >> I tried nocache on a system with a lot of jails which use nullfs, > | >> which showed very slow behavior in the daily periodic runs (12h runs > | >> in the night after boot, 24h or more in subsequent nights). Now the > | >> first nightly run after boot was finished after 4h. > | >> > | >> What is the benefit of not disabling the cache in nullfs? I would > | >> expect zfs (or ufs) to cache the (meta)data anyway. > | >> > | > > | > does the poor performance show up with > | > https://people.freebsd.org/~mjg/vnlru_free_pick.diff ? > | > | I would like to have all the 22 jails run the periodic scripts a > | second night in a row before trying this. > | > | > if the long runs are still there, can you get some profiling from it? > | > sysctl -a before and after would be a start. > | > > | > My guess is that you are the vnode limit and bumping into the 1=20=20 >=20second sleep. > | > | That would explain the behavior I see since I added the last jail > | which seems to have crossed a threshold which triggers the slow > | behavior. > | > | Current status (with the 112 nullfs mounts with nocache): > | kern.maxvnodes: 10485760 > | kern.numvnodes: 3791064 > | kern.freevnodes: 3613694 > | kern.cache.stats.heldvnodes: 151707 > | kern.vnodes_created: 260288639 > | > | The maxvnodes value is already increased by 10 times compared to the > | default value on this system. > > I've attached mount.patch that when doing mount -v should > show the vnode usage per filesystem. Note that the problem I was > running into was after some operations arc_prune and arc_evict would > consume 100% of 2 cores and make ZFS really slow. If you are not > running into that issue then nocache etc. shouldn't be needed. I don't run into this issue, but I have a huge perf difference when=20=20 using=20nocache in the nightly periodic runs. 4h instead of 12-24h (22=20= =20 jails=20on this system). > On my laptop I set ARC to 1G since I don't use swap and in the past > ARC would consume to much memory and things would die. When the > nullfs holds a bunch of vnodes then ZFS couldn't release them. > > FYI, on my laptop with nocache and limited vnodes I haven't run > into this problem. I haven't tried the patch to let ZFS free > it's and nullfs vnodes on my laptop. I have only tried it via I have this patch and your mount patch installed now, without nocache=20=20 and=20reduced arc reclaim settings (100, 1). I will check the runtime=20=20 for=20the next 2 days. Your mount patch to show the per mount vnodes count looks useful, not=20=20 only=20for this particular case. Do you intend to commit it? Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_OOmCLJCGKh7pUIN2ebU7UkJ Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJiU4YACgkQEg2wmwP4 2IbOog//UdLh0K5ti6ozpLt2s7aj7u71uwYtvloew6wL2RD0BQTzDMDUni0ttv49 XCKnz3fHjW4nraKJ1JXY5VAwbNzEDd+y4QowiO7qxM97K6GRyMfpfVJoCHdrBq2v TCdjKKhuy7/gq96u5ko7cQUc4bbO6LCsC6Uja4S2HeEvRn/dQGROlzjQabbkV0NJ 3NS5A0HrPaZvkMTP9IXYEmItrVA1rwlndvy37AAMqXrsYfx+32PRLj8bbT2flXgh CTbVRYg4iKXRI03OzfVdg1t+73tBrZRT9GfnlvaZf/tU0Q5+/fgVqPszAK58aLpR HBSSeOTI1ZAVzYL078Xvd+CxmZwuYp3mJ/VlrOjH8wYVtlEG86en+gIZW3OjzxQI E4YlWSjjoEmTuHcTkiOwe7m0nfbaIpB6pvwouKv3/DdbeJK1nrHlftqXY7qDVb0z VVSMaJKwGQWoKYqWmB/NcBg/G1EkkJ1W3241dc3XcRVve84hDVOyfvOcOaiptST5 fOFZaUZbL8V1IgZB4I4oMQlWpNHiKUoTFsdRCNQ52fyNlNpmGLlrg/npk9s+27FM ZwtywCP02ibeK67X+Hy/CInEJE7J2cCJDNI4jenNTkGEM+8+BlWBdRMYzHOnOEfI Q5BUC8sfgbClQEw/941H2U7uSq2e8VJ8vM5lL5Si86Rx/QqtQ+8= =gJu9 -----END PGP SIGNATURE----- --=_OOmCLJCGKh7pUIN2ebU7UkJ-- From nobody Fri Apr 22 14:36:22 2022 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 6A961198ECD9 for ; Fri, 22 Apr 2022 14:36:26 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91]) by mx1.freebsd.org (Postfix) with ESMTP id 4KlH612BGjz3qCK for ; Fri, 22 Apr 2022 14:36:25 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) IronPort-SDR: H8BMEIoPYf7crTlgGhb/nSdzcmpmDYRKbXp2GqEHIaptiD9USKExHfrrcfAOS4Vm0uKIyVr2xv RZkD0ixZTCtJfWLnPWEdcx8KF4hcP2Osc= X-Ambrisko-Me: Yes IronPort-Data: A9a23:8BdkdqIsP5srdl2FFE+RxZUlxSXFcZb7ZxGr2PjKsXjdYENS0WZVz zZKXGCOa62PMTfwKdxxb4vg8kgB68XTnNA2TQU5pCpnJ55oRWopJjg4wmPYZX76wvUuwCuL1 u1GAjX6BJlcokL0/X9BDJCw9BGQ6onYHtIQOMacUsxAbVcMpBUJ0HqPqMZl6mJcuuVVNivW0 T/ET20zD3f+s9J8Gjp8B6tuM3qDttyq0N8TlgRWifymIDYyPpTIZa/zK51dL1OgKmVVNu+8W +vZyri9uGrc9Q0sEdCi1L38dyXmQJaLbFLI0yQGHfHk2HCupQRquko/HPMZY11WkDaOt9l0w s9Mrp+3DwwuO8UgncxACkIBS34W0apuveWvzWKEmeWXwl3PdXfh2d1qAUA6PIsX9/wxB2xSn dQdKj8QfBGAr+2zybO/DOJrg6wLItPmMYkEtjRr0CvDAPA6aZ7ZTqjA/tMe2y0/7v2it962i 9Excjd1chnaOVtGP10NCYk9m6GjgXyXTtGRk3rNzYJf3oQZ5FUZPGHFPIWHd9qUa99Sm0rE9 GvK836jW0MTMdaFyCGG9Vqlg+XVnDj4X8QZE7jhrqxmh1iax2oyDhwKVAvm+aDo1hbmA98Pe VYJ/icOrLQp8BD5RNfKQBDl8mWPuQQRWoQMHrRiuh2N0Kfd/y2QGnMAEmxacNUjucJvHW4q2 1aFksnHHztqtLHJG3uR+q3O9GG7PCIPLHQBYgcNSAEf4sLgp8c4iReWFoRvF6u8j9vUHzDsw mDX9HFv2+1L1cNSjve151HKhT6ot6PldA9t61WFRH+h4yN4eJWhO96i52/E4KsSN42eVFSA4 iQJwpDM8OAUAJiRvyWRW+FRTqqx7vOIPTCA015iG54tq2ak93K5J9kC4TdiKV1vO8JCcDrje k7IugQX75hWZSP4YahyaoO3KsIr0amwSIy8B6yMNoJDMspraQuK3CByfkrBjWninX8lnbw7J ZrGI92nCmwXCPg/wTfqFf0R16QnmnI3yW/JH8ip1Bm9z7eEPjicTL0fMUCNaaYy66bd+FfZ9 NNWNs2rzRRDUb2jOnCGrdZLdV1af2ImAZ3WqtBMcr/RKwVrL2gtFvvNzO5zYIdihalUyr/F8 3zVtpW0E7Yjaakr8Tm3V00= IronPort-HdrOrdr: A9a23:M6onNKhvFpNm3eGscw7o01aGI3BQXtoji2hC6mlwRA09TyVXra GTddAgpHjJYVcqKRUdcL+7VJVoLUmyyXcx2/h2AV7AZniChILLFvAA0WKK+VSJcEDDH6xmpM VdmsNFaOEYY2IVsS7LijPTL+od Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 22 Apr 2022 06:32:52 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 23MEaNEY061946 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 22 Apr 2022 07:36:23 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com Received: (from ambrisko@localhost) by ambrisko.com (8.17.1/8.17.1/Submit) id 23MEaMMB061945; Fri, 22 Apr 2022 07:36:22 -0700 (PDT) (envelope-from ambrisko) Date: Fri, 22 Apr 2022 07:36:22 -0700 From: Doug Ambrisko To: Alexander Leidinger Cc: Mateusz Guzik , freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues Message-ID: References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> <20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN@webmail.leidinger.net> 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: <20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN@webmail.leidinger.net> X-Rspamd-Queue-Id: 4KlH612BGjz3qCK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com X-Spamd-Result: default: False [-1.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FREEFALL_USER(0.00)[ambrisko]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[ambrisko.com]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.90)[-0.901]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 22, 2022 at 09:04:39AM +0200, Alexander Leidinger wrote: | Quoting Doug Ambrisko (from Thu, 21 Apr 2022 | 09:38:35 -0700): | | > On Thu, Apr 21, 2022 at 03:44:02PM +0200, Alexander Leidinger wrote: | > | Quoting Mateusz Guzik (from Thu, 21 Apr 2022 | > | 14:50:42 +0200): | > | | > | > On 4/21/22, Alexander Leidinger wrote: | > | >> I tried nocache on a system with a lot of jails which use nullfs, | > | >> which showed very slow behavior in the daily periodic runs (12h runs | > | >> in the night after boot, 24h or more in subsequent nights). Now the | > | >> first nightly run after boot was finished after 4h. | > | >> | > | >> What is the benefit of not disabling the cache in nullfs? I would | > | >> expect zfs (or ufs) to cache the (meta)data anyway. | > | >> | > | > | > | > does the poor performance show up with | > | > https://people.freebsd.org/~mjg/vnlru_free_pick.diff ? | > | | > | I would like to have all the 22 jails run the periodic scripts a | > | second night in a row before trying this. | > | | > | > if the long runs are still there, can you get some profiling from it? | > | > sysctl -a before and after would be a start. | > | > | > | > My guess is that you are the vnode limit and bumping into the 1 | > second sleep. | > | | > | That would explain the behavior I see since I added the last jail | > | which seems to have crossed a threshold which triggers the slow | > | behavior. | > | | > | Current status (with the 112 nullfs mounts with nocache): | > | kern.maxvnodes: 10485760 | > | kern.numvnodes: 3791064 | > | kern.freevnodes: 3613694 | > | kern.cache.stats.heldvnodes: 151707 | > | kern.vnodes_created: 260288639 | > | | > | The maxvnodes value is already increased by 10 times compared to the | > | default value on this system. | > | > I've attached mount.patch that when doing mount -v should | > show the vnode usage per filesystem. Note that the problem I was | > running into was after some operations arc_prune and arc_evict would | > consume 100% of 2 cores and make ZFS really slow. If you are not | > running into that issue then nocache etc. shouldn't be needed. | | I don't run into this issue, but I have a huge perf difference when | using nocache in the nightly periodic runs. 4h instead of 12-24h (22 | jails on this system). I wouldn't do the nocache then! It would be good to see what Mateusz patch does without nocache for your env. | > On my laptop I set ARC to 1G since I don't use swap and in the past | > ARC would consume to much memory and things would die. When the | > nullfs holds a bunch of vnodes then ZFS couldn't release them. | > | > FYI, on my laptop with nocache and limited vnodes I haven't run | > into this problem. I haven't tried the patch to let ZFS free | > it's and nullfs vnodes on my laptop. I have only tried it via | | I have this patch and your mount patch installed now, without nocache | and reduced arc reclaim settings (100, 1). I will check the runtime | for the next 2 days. | | Your mount patch to show the per mount vnodes count looks useful, not | only for this particular case. Do you intend to commit it? I should since it doesn't change the size of the structure etc. I need to put it up for review. Thanks, Doug A. From nobody Fri Apr 22 20:39:15 2022 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 C7CA6199967B for ; Fri, 22 Apr 2022 20:39:24 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 4KlR8q4hNlz3nRS for ; Fri, 22 Apr 2022 20:39:23 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 75BE55C02A4 for ; Fri, 22 Apr 2022 16:39:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 22 Apr 2022 16:39:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1650659957; x=1650746357; bh=bFTE5gjJQB T2aqhU0NawXR2qJvU02P2V8r8UvuUdGFs=; b=H7RBDksO1apdENBEJPeibKIvDY sG+oHGqPUcmUlTtA2p6DHO02bVo7lTszS17XA73VBxFf8WQI3l97q24ZTkI/y+K8 iFVtWZV/11htzEPRuFWh4jHC0jmJ6EPDK5h+APrcBsBXLrAAC9hWCT0XvzX2X+i9 8e9zr+CLqBOv6TEz8I8Lu+YFJlJBus5KbmJXJ+Hef/SwCzQGUqBH2ppn29EWIwzK heBzx1EYBrY2NKkftE8evi2pAos7DtBNE+HR33Gl+GIPv91zKBEPE/iladdw+iQL 1QyDL0+y84XpEyH1o911hNpWFfROHAp7FyQS7RgvHC4CruSCgQzFKNShjNUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1650659957; x= 1650746357; bh=bFTE5gjJQBT2aqhU0NawXR2qJvU02P2V8r8UvuUdGFs=; b=E 4mMWBAeAxiTOnV+gvLFEprm9hksZSBi4BweiGFUdzT09o1hZsEyLGcSBRlniQPl3 SxyP0Q1tfgMuhnQaYMNcajMsqyr440uyEjXlctYrgK505L+Ex3n1fUbkzIXvCdpg QlkFvxCl5thyiNDascocPU3Ge4nCHAz8LGASngAVkmwF6Kgaym+lhsGb/oTVvYDK n3tB1mVufK/i86lySS++Kqx8oCHy7dpVk8t04G9ziJyo4LeTbWflBCUg35snOCYZ ZEBPHG+FiQupB1w6ct0urcpQFHNdY21FEcMbR0mLOavReJv830G2jC3jiVn+diPf BGqoJS14FiYGVDxs6oGkQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrtdeggdduheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtudenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeevffeujefggefhfeekudetvdehtd ehudfgffeigeefveefheegvddvtdehffeljeenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 22 Apr 2022 16:39:16 -0400 (EDT) Date: Fri, 22 Apr 2022 21:39:15 +0100 From: tech-lists To: freebsd-current@freebsd.org Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LPEGaSQsH9s0WkY8" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KlR8q4hNlz3nRS X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm2 header.b=H7RBDksO; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="E 4mMWBA"; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.29 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-5.68 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.991]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm2,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[freebsd-current] X-ThisMailContainsUnwantedMimeParts: N --LPEGaSQsH9s0WkY8 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Apr 21, 2022 at 07:16:42PM -0700, Pete Wright wrote: >hello - > >on my workstation running CURRENT (amd64/32g of ram) i've been running >into a scenario where after 4 or 5 days of daily use I get an OOM event >and both chromium and firefox are killed.=A0 then in the next day or so >the system will become very unresponsive in the morning when i unlock my >screensaver in the morning forcing a manual power cycle. I have the following set in /etc/sysctl.conf on a stable/13 workstation.=20 Am using zfs with 32GB RAM. vm.pageout_oom_seq=3D120 vm.pfault_oom_attempts=3D-1 vm.pageout_update_period=3D0 Since setting these here, OOM is a rarity. I don't profess to exactly know what they do in detail though. But my experience since these were set is hardly any OOM and big users of memory like firefox don't crash. --=20 J. --LPEGaSQsH9s0WkY8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmJjEmkACgkQs8o7QhFz NAWfsQ/9FRdkcoQfbT1NK3Fg4dphc7J4+6Sfv9bvQ0NYM3cfjQ2u/Y96Jm0CF0zN DZq+TNM2QDk1P+oOUgqc8BrOebaAbVraQYKeB8kSjdk99OMYGgqLeJsrkpM5uE4f OsvTEBCV/sWJx69GUAeXLLugMgB4J62bC6GMYehMBtAd+XTXtmTfoHXdZpRWIxDU 85dR2gnwS+YTLWpxDhTls8O26aWwi4lkOSnQ8H0CqPwOBMgRDmaGQVaze45wam3h Xgywca4g7ROVjBJymuZ9XoON+qyOy468UVu8Hqu5HbsCg+LSMP4dE4z7Ew7ul//1 xe5AWBOaprHRuQrvTDIoITogDeV2P+ViFPbZsjXgLglHeTGsI0rGPXj3M3MJuor9 BrOUg2TFjieNdUXdYMYrwp8NsZMwOOQKbTxKxEkvr/na5UxIK/YS1vaCLmfIUbbR LdXeub0xtkc3B3OPeaNmI2VROGtXw6Dy7Y8g1j639P0NU/4/tl9yuC61iT4qctAk FzcmXjSA5EgrMtRcv0wIHVex5yNsgS36v3ftFNzKBiUo50/O+sVg/C7HZlPTdKGF FN/UJxF4t94wuI/F1o89++tyi7DIfJWWRQv8dHoja4RtkHo5xYsdVetBLDIRaljn uArYzJKvomBF+vurdRxjIrVV/7CfCZkUXQLIbDaIpwqHEKFlToE= =FQCd -----END PGP SIGNATURE----- --LPEGaSQsH9s0WkY8-- From nobody Fri Apr 22 21:31:31 2022 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 A8FD41A8625D for ; Fri, 22 Apr 2022 21:31:34 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 4KlSK1556Bz4RD6 for ; Fri, 22 Apr 2022 21:31:33 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8152F5C01D7 for ; Fri, 22 Apr 2022 17:31:33 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 22 Apr 2022 17:31:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t= 1650663093; x=1650749493; bh=P7F5z+N1CxeY/MWhQJfSs42hFxT0SrdvyQh dWUF/Py0=; b=dH5gmz53kK/iIMkA8M4xzDThZW07kd240MZj5yOrhsEQG8EoLkw 5Vb6zgoEK8o3nrfvQKNWmixske7RwVPtLqTtSvSTe1HbddsPjsZoGFUkCuZ2AE/k YkiEig0duIp1E056EV98qU9ORmjBJHVaM150rCSCy3l0peWzQucBN6ceJ7LSpvUe DRHvencTsvnBTUyaaaMoeDatIv0HDb9UQEeFBg1PFVGcLoBzmKK3XT1ibHlZzksp MNhlCYW4e+m7Aos1JSJU0k7cSubdvhWgsRspu1IfUDEfj7ar/HCH/vDbM2uKQorR Bm4g79oDu7yYMsuYwIBxDhM9t3CndfIIX0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1650663093; x=1650749493; bh=P7F5z+N1CxeY/ MWhQJfSs42hFxT0SrdvyQhdWUF/Py0=; b=pBxNUr77cTJjMptqcAWe9W8D9/cVf mb8Ik3jdBPhyVNmFTNrKBBYvVAUio+shSIUMxv1MRL5wd0d2L9DvK04g+DzkVTs0 HRQpFbVBULyBEqbkPkOS8MGEt+K75ylduzEhS7gEM8em3FuTptQsA7EHcvdb6ZxA BAEYTgIB24gRI5kGgpFa0+sLkv+ll+zwqt81N3nP9L6uWby2Iz1GMHsw4jQEDpWx IVULokxZBcB7PAmp+18dqyIUDSPoXHKa9wEaJsdMnf3o/E2Ur0s2wbM/+jSV2t8i DYFrFL8YuHY/Qhk2O6eYg33In31xdN28FdL5uNxTWToLEwgHDwRJMezdA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrtdeggdduieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesghdtreertd dtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseiihiig shhtrdhnvghtqeenucggtffrrghtthgvrhhnpeevgffhffdtfeekleelhedtjeelvdfhvd egieejveffgfduvdfhteegjeeujeeuieenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 22 Apr 2022 17:31:32 -0400 (EDT) Date: Fri, 22 Apr 2022 22:31:31 +0100 From: tech-lists To: freebsd-current@freebsd.org Subject: bsdinstall partition error when installing to nvme Message-ID: Mail-Followup-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V7aOkRCNlQMzBeuK" Content-Disposition: inline X-Rspamd-Queue-Id: 4KlSK1556Bz4RD6 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm2 header.b=dH5gmz53; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=pBxNUr77; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.29 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.69 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm2,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from] X-ThisMailContainsUnwantedMimeParts: N --V7aOkRCNlQMzBeuK Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Attempting to install from:=20 FreeBSD-14.0-CURRENT-amd64-20220421-b91a48693a5-254961-memstick.img to brand-new hardware, the installer failed at the stage after where one selects partition schema (so, GPT in this case) and UFS filesystem with an error like (sorry to be paraphrasing this from memory as the=20 hardware is no longer available) "autopart failed -5" I thought it might be down to it being a nvme stick. The hardware in question is Crucial;CT1000P5PSSD8 1TB. Is this a known issue with nvme? On that machine, this was the only "disk". Can nvme be used as the primary disk on FreeBSD? thanks, --=20 J. --V7aOkRCNlQMzBeuK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmJjHqkACgkQs8o7QhFz NAVLwQ//bgzFDkILlAgtU8yZe4E8DIi5XE/ymejA7PDz06nM3XxRmOT4XUZu1I6B 5oxYLoJgnMRAUr7JBhS3O7CKsfiRyoDMwjLt7KX82nrGGQICoL01yXTdbWlI833u gG0Y63m0UKNAGgbO7iduMomVrbxauHb6QAdCwIDIgEbsXl/2geAAAfGMIjT3iAkE bzeNPVx9FNPgEjSWCoXlMOjLwlJBJjq7sYFLjgcrG2qlpT6YY3IkoJFH3dkvD/kE xqn7ujq+KSAORBcSXBHjdgz67YhxzQSbm9gYvJBqYXoyez/niePiIBHvO54uEBHM Jqyqm8HeAHA0LEp1NL3ymYOSoevM3TYp4khgF4pokmiYCPV72GvtOmEw+WfGBor+ LT7vmzFg2+mV4Db74pX4dXKFSJi3Zkske6rnnP0SjLRbF78zmNvEhL3Wp8HhOv1f 1aiWGGX7PkThjV/fR+M0sYBYWAanzJj2Or6sJ3uVF7motWh652aC+JIHxGEoJVEy cB4O2zgAV8a5RdXGe1ynDf5NlyuBDapn1mpp7VgADbEZz+5LIxxsXdiZE+3q5rmN 2A2orUTUseqk/+Spq9nSHMthptAKYdvHChw8xj/b+3h+ZdnxPY9ADnfMrTIRCb99 jBBnZJnnyakeTxAlOuuoDqF0R2tscLOxHFbQsflDMS8Zx8F/6Zo= =xwDi -----END PGP SIGNATURE----- --V7aOkRCNlQMzBeuK-- From nobody Fri Apr 22 21:36:45 2022 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 1A3031A87DD0 for ; Fri, 22 Apr 2022 21:36:52 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlSR76wxzz4ShD; Fri, 22 Apr 2022 21:36:51 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650663412; 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=YKtdbmsoDOQGrizMO7QM71A45cnW3HrsWRPyqb/vSL0=; b=j2H5cSoyYQ6KH9+DIOtWFbTF6TcQN/wXN41DjCc+lBGYhKaxwZqhQxs1TKcsLgilOeSz4a 2vaXSExLOPNDwlNIGFQt7SKSQlAwwTBZmG/xTyjzNzJU/CJQ7FzlCk3U9uZdhDGdJRwnNG 1DGtKxWepacu9qL2PNYTGqF4CkoVWmYRtx1+jZs+8EGwe04J1KmwEn6gBVpuGCI3QxbwxJ bGA6y9TEpakE9B+NcUWHGE4WoIaN1S9NGuAHz/3hxMOA0EzMwIYKTSw+sbFgi1BPgezoHi Xiu02tmwDkvOUb8Nk83bR76PD0vrMT364j8aAPo1eIEqXkMQc8UAop/9HBDkhw== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 7CACE14368; Fri, 22 Apr 2022 21:36:51 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 22 Apr 2022 21:36:45 +0000 From: Glen Barber To: tech-lists Cc: freebsd-current@freebsd.org Subject: Re: bsdinstall partition error when installing to nvme Message-ID: <20220422213645.GN28996@FreeBSD.org> References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ubLUeOwAbUG/ZPBB" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650663412; 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=YKtdbmsoDOQGrizMO7QM71A45cnW3HrsWRPyqb/vSL0=; b=w7dcVPq+HXcwXUV2PsMwXmP+ZxKiWrftmL/Y5nWHg749Is10NkExBP4W30DvD8w0q2Jd0m UycrCtsviAq1q58Ex2N5vgSx3aNHDoGY7TzUmWo9JGUo0Ge6K35U8ALVpEhE1QkjTZW2wz sYVsLk47nPSEnSVrLZnQxycztG2xzXVDqf9tjzIjuOGXb66kxvzt/U1GVjUkVNFQTuAlti UohPjcgic3LWIfvSvdgt+s2ye7R06yJxOsg0j6J1zPg81a7AKqYl7lDbJgQKJiHzkP/0Wu MjaPJOGXIw6lgZ4wmrZ+5OQfBSSpfJlXpynZ2pi2fmR5EfBtsk6pghqvKFo2ng== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650663412; a=rsa-sha256; cv=none; b=RMG0h9wxswGo+aiqQobNb4iDjY4VWB2FOlRlsnGP34/YPs3rJXE2jaoJrGsU6Zmddwlp8P SeuXXUNejg0RXB+jnZpV2vw+rLuNowIgXPrHJfbi+qX/XFYeNvynJzxWZgLjgKa43MJQI5 HahG7fl+IgkA98CN3yVpM4xlvuoOer/hWLsr0uVgNO8wqrHSb46EqpSQcxQQDbDIJ6naZa jCCJo2/oi306McyAZ3v+XEC2aAUmhAw4cdS/VVvpa8apMTCSBhwkJSHJiAWZDlG7cV36bA uqO5Mz0vjuRjGB9pksZP9DW3C6zklMFV242N0PHGfEYWkBAiweNcFabukTlJWg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --ubLUeOwAbUG/ZPBB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2022 at 10:31:31PM +0100, tech-lists wrote: > Hi, >=20 > Attempting to install from: > FreeBSD-14.0-CURRENT-amd64-20220421-b91a48693a5-254961-memstick.img >=20 > to brand-new hardware, the installer failed at the stage after where one > selects partition schema (so, GPT in this case) and UFS filesystem > with an error like (sorry to be paraphrasing this from memory as the > hardware is no longer available) >=20 > "autopart failed -5" >=20 > I thought it might be down to it being a nvme stick. The hardware > in question is Crucial;CT1000P5PSSD8 1TB. Is this a known issue > with nvme? On that machine, this was the only "disk". Can > nvme be used as the primary disk on FreeBSD? >=20 This may be related to: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263473 Glen --ubLUeOwAbUG/ZPBB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmJjH+gACgkQAxRYpUeP 4pOEcQ//QNP+A8j3RUTfB48aRq1QgsKp8d2Sc1UN+7cyNAENO9gYUZg5WZXfwINL mUzBe7CAq0HWkjcL+DVZIZ5VQYHyuDcJSNSO8OyvHV0mq9fhA0YbUyZp3XEHFvVP scI1N2QxBhHV1TMSjFPkyJBRvRAj0uqNZr+s2ip2StUT7tFXsPtcDzPkuk6yTS/T Ld7zDSYVJUirA+9mJDc6XvpqkP6kisDexu8V2iGyRsd8zmVhzKc8Vs2wUCQ7TTPE UjRTVxts0HrtzUnVZVzMVQ+95CYzv/Y6OKGXaIlCOUzk4IVW1aLY6hA9ECfunZDc 3wHutF+AsRZC6+cB2nbFLGzTR25SM0EHzRHRSgXtTPxihhBUv+d21C8nyUxcANWk CQd+fotlrBlIpVyzG054coy3Rf8tyVER9bECcFG8/0gR/ikY04e9rXZesNjPyN8w lnR18tUdJyUI1YNUGZfoK8PKdeUVR6r2YJmwB1/RDBdmLx6UiYsvF9JeuDtKVAvT j6Ey187QarEI3vOLk09tCmDLF6+/mCq9+OItz0cKKad0V/I4rpM5jAq11tKWqfe0 vdUp10hBNW31EdvTP1VwbB70+YQHfB+DBRxQ1nBWmkWxd6lHltwECynaSxHC+Ovl wUd8eFVNjbhttrL4Hos0znrC22WXWTCns+50xXpEY4j9MwrsLZc= =oE7B -----END PGP SIGNATURE----- --ubLUeOwAbUG/ZPBB-- From nobody Fri Apr 22 22:04:29 2022 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 0FED819888CC for ; Fri, 22 Apr 2022 22:04:33 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlT343NBmz4Zm1 for ; Fri, 22 Apr 2022 22:04:32 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 26BF85C00CB for ; Fri, 22 Apr 2022 18:04:32 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 22 Apr 2022 18:04:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1650665072; x=1650751472; bh=4iVds4qz3C zAyxu1sMQhRPurcR/WzsN3lPgsv9h5P4M=; b=WlGKglMRpYId7sgCFl2B4m/JwV 6+c9TfHRvnLguTXeI5FlHUmVxSZz2VV6j5QbQW79iRiZieru9bZ0Lo5bIygf5sfd zOkIooDHDdv6iDMwwPy6RDj2SJWCInnRIruCckFnmYp4hCqsdJHIDZEOC3shZ8zs hp7koFvyR4b5oVYvYB2cNIHvkxOBk0leWFbonsQZP9/Z7PUVJ1YJzSsVkYSkKIDD TBmubFDDhmCOjGXEDbd21DRDCdeF/8t8b3xDYx2nM821j3I7NyXzrUpFM5wfnoIy rkb23zWnOQ/VkHYAIetIeZ3mpikrIZ+BmrzJkY1IBuvaA9Cao7dzzICQ1D/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1650665072; x= 1650751472; bh=4iVds4qz3CzAyxu1sMQhRPurcR/WzsN3lPgsv9h5P4M=; b=p h5+/I7Vu+Uso6mKeGhoa/EGyWOOv25bvH5j41TcJghayppu579ij7p+3EfG4qdkJ puOlGUAKfdWrl9ZoefU/iuKQ7vF51K+nQe9V6T6CDuSDGoHE+PFHcBsahr8bL+zA Ot9p2oKEVA2AsD9s0bwEjev7ws/D/MRNEg43snwOeoKxCRtz8sGMMgRz/bAcy8PV dlD3YQ66sNfev7p6PVcL7aK4WB9KpivxZvWrxXyAeEhoU8hkWSwXRRebkIpKaALx /XWHuGffesL43B64nPlgsOFN44VF4V98b00bBSJ7reXLfGksWg62qACqPShp1xkl oW2/HQAHL5dbNZ0O4gJ5Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrtdehgddtjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptedttdduuefggeeghfekkeetkeejle efffelheejfffgffdtfeeftdejgeeuieffnecuffhomhgrihhnpehfrhgvvggsshgurdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepth gvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 22 Apr 2022 18:04:31 -0400 (EDT) Date: Fri, 22 Apr 2022 23:04:29 +0100 From: tech-lists To: freebsd-current@freebsd.org Subject: Re: bsdinstall partition error when installing to nvme Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <20220422213645.GN28996@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H+cGwTOGvR6FOGS3" Content-Disposition: inline In-Reply-To: <20220422213645.GN28996@FreeBSD.org> X-Rspamd-Queue-Id: 4KlT343NBmz4Zm1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm2 header.b=WlGKglMR; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="p h5+/I7"; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.29 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.66 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm2,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-0.96)[-0.961]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from] X-ThisMailContainsUnwantedMimeParts: N --H+cGwTOGvR6FOGS3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Glen, On Fri, Apr 22, 2022 at 09:36:45PM +0000, Glen Barber wrote: > >This may be related to: > >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263473 Do you think it'd be useful to the ticket if I added my error? My context was a little different (current/14 and bsdinstall) thanks, --=20 J. --H+cGwTOGvR6FOGS3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmJjJmMACgkQs8o7QhFz NAVnjRAAl0RalO88OfYrYpcSoSGDWQBrpyUPwTddCbY7q5BY09YHp8gROqKZ/1Ck ZMThRJ24WaJEmPZah+kDXx471qUBNRhXwo2Yt71YadGWDYsG0lAo6ObgcS3LAYe2 gGtCyY2FvwsdQq9fm3X4OvZxZHlm1/lrSlYvye+l3jIDYBZc145cV+B3E5+4IvnN a+zhzEEvDDefyf7j4xBwONuIPCOZ2M7Y/V3PePQFOUu2VsZAE/ecI3RWnSDGVS5/ nEBJDh4OuVZMwL0iL1R2PtTklmPy9WQTwage+hHI2xu1FO+pAFCUED7QivjrG+aH 37sxMUsDR70blJwLK4Uyk90/GPf6ZYlwcREG8Ua9yS66nztEagzMgJvqVtrCwPwv flZ1kZalMDHW6kZvTP6q+PgVPHOdmJuKsxXZnSdoPHNDgMwnOQWWlMjuQunnulww AMsGi0Ide9KMsijIpLQCJXLROQ17EwGQCu/QG2LibUBNZCA8XjEOzD2I1Q6pv4qB aQif8pTHUqJK4dESaQqZyvMTPTTPxYmvh4C0JZDY0kDDVeH1g8vb/cLt1woIGPgT JzgZYFVxEhglPJH8gny14m4RgoYNNJordap0hsaAc8i4lHVPT7bUDWgPMV8GLfhp 6uvf9xr+ABfGXe/kGfaJ4Tkl+nCa0Slvx44MvDwTzYYSc2ILNyU= =/wLB -----END PGP SIGNATURE----- --H+cGwTOGvR6FOGS3-- From nobody Fri Apr 22 22:16:07 2022 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 5B4C7198C343 for ; Fri, 22 Apr 2022 22:16:14 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlTJZ222hz4f22; Fri, 22 Apr 2022 22:16:14 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650665774; 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=bL/mN9CNgkjFcdXKa9ZOnTDLJ/CMFmf/Q8A9slMyfK4=; b=Y7kjvk8STIfatkaeyWr/CxdcXvyuDS4TRMo90ovNKul/pERqxjd+8ptrPSvM4l27isIzmO CRIQShtWLC820QE7b5bW3F712iRsUVtSbix/DNcnDfu69QnWzyzbLaqlhmsK3rO3CyVwAt SnbOaX9bqWt7OinfLgahwvV6KdORdRPbZ+KQdKRJnEj2yAmXibFWkrjrL/5ZRGOWABEz+3 sq+FO71J+thCzq2IhpzS0c7ZfrjJTpZENEoOh0shTGrxtsWh5O0Yip04p5axG+4IS5eZTZ 8aHqBWK06rhXRLgTwGNvP/tGH7qiBfJUA/QrpFyGeXexm5ZU0Iw1t8x65rpFeg== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id DC58E145C9; Fri, 22 Apr 2022 22:16:13 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 22 Apr 2022 22:16:07 +0000 From: Glen Barber To: tech-lists Cc: freebsd-current@freebsd.org Subject: Re: bsdinstall partition error when installing to nvme Message-ID: <20220422221607.GO28996@FreeBSD.org> References: <20220422213645.GN28996@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hR5hZbB3sAoKVpMi" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650665774; 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=bL/mN9CNgkjFcdXKa9ZOnTDLJ/CMFmf/Q8A9slMyfK4=; b=A+gDhV+2PAt+NjpbRt2wAf4ofnE9GFUhDrV/7tpKV0J985TKhF8P0dxL9EwYsDO5XybciU PsUIYeerLuqC6+u+8Ds1NJmyyLKMK1RPQk7RECWmdPVmPDSq3Y8L1JjPjBZaHNT/hhFaLZ 445vQxZX35+YcRaJKB+UnQWAEgESDKAo5vUrGZAYLo8XBLM4axN8lTb+XR5lFBNuN6t+16 3sSZd9mvkcmTUdocJZOJyMFXRaPiKvduQa23ARSQCi2AfahGTJcXGtRD7hNE3ZLAIV9Jpa VlgjtDNpIyJHFo76y/3mNq7lG8qLwRQ+3TlTYUq/1+J95lYpIFDBU+eMuW/spQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650665774; a=rsa-sha256; cv=none; b=qBDyaF/SDSaHxyhmnLf4JTtlv/0gjIhBUAZhgyTI9BReoRxJMmwN246hasGwhxYRtW2RUh xgvczfSNd2vixOY1zg/7igAof4cJ6zV+0hf7JmhvoZwRQpg0Ab0GBYNnsdmfRN/1eiN5lP qZDwhQ+e3Y1owrXEJtyb2Ih2WNAZ7taUdjDhI7q1YbN8YfOom7JtlNRR3ctyZzYc2knYER X4kAn2Ui5cI53bAl8lZiPoK/16xwJJjGPCKWjMRemIdHmBtAWu+6XbI1vumSKsxpZgd78u XJuDAMme7W+xNjXynUjN/mORDbsTQ6/alrah4VzQtvChfSVB1OPY+J1hCqDlJA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --hR5hZbB3sAoKVpMi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2022 at 11:04:29PM +0100, tech-lists wrote: > Hi Glen, >=20 > On Fri, Apr 22, 2022 at 09:36:45PM +0000, Glen Barber wrote: > >=20 > > This may be related to: > >=20 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263473 >=20 > Do you think it'd be useful to the ticket if I added my > error? >=20 > My context was a little different (current/14 and bsdinstall) >=20 Yes, please do, in case it is indeed related. Glen --hR5hZbB3sAoKVpMi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmJjKScACgkQAxRYpUeP 4pOJVg//ZeYbHTOIaL6+D8skIDeqENL/J6WIsJRevlrSEZYd/6j5coohFpQjoV6a DKz+7dIdRTUKxWWO2XiGiWAOMMA0IwO86RjsgZCnvcvRydLg/Cfw2XABlX1P/eQZ daEJJyaTiHQsjJW3eiL/3VwQBT/+ldnYpwJk5k/3vB+uOJdCYAnTum4zxKo0i+Sv CxyCfc+H98AFsAmvghAMeZwL5JNTsjYM1mgfC/AmHusS8Dz5Pp6RXPq52CFT6/GA aUpGtp5BY28pu5Kt0/RdDkG2AYPLtV49WDq6mVSjdKhSL021vbfJWd7SP0WGNCM0 QDgrdx9AvQRwphHm3QgGocuuqL3KvHE9fPaxYSFcjqxYgZ7dEa0SKq8UV2kUcrmc PoFbXBxEIeKvNVj2CNHiW6/DFSmRabjul88is6eE+iItGu6LWXQA8uOnYPjst8Wo tgbgP/M8yDU+Z3tYNgjnqhscJlh0ZXQlVcYqDli+UoYrBclYqDac1EY/LhSVQqZQ 1QbZlz0oWVSDFahvBU6C26H9mtUAvCRM1XK5NJYNRNzWglOCDXpIOD2fW+obyNta cWPUIV0lasBN/FzfTIwHPMG1uaH7SoBIapCEyXsfwc2A4EH0HRwR/HG/+m1I3QfC jBCh9uRNdfjP60xgnmWC5SRZhcAtA58I1Se/qOcm8FNUlIRqqj4= =6Plm -----END PGP SIGNATURE----- --hR5hZbB3sAoKVpMi-- From nobody Fri Apr 22 22:33:29 2022 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 7B98E1991D9D for ; Fri, 22 Apr 2022 22:33:32 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlThW4dswz4kSF for ; Fri, 22 Apr 2022 22:33:31 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 81BBF5C0304 for ; Fri, 22 Apr 2022 18:33:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 22 Apr 2022 18:33:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1650666811; x=1650753211; bh=ThmVhWwIRx MEauQyL/jVTUkDwaugBlkXzx4ACfSe/LY=; b=hDKNwdOo1cXwzrkDvjWm6At3d5 VuSpuBklS36WAdzWukDdteLrVNq+0w0gWr1MAVpYEH/envI30jSRKMBPFSmi6G8G vWFDMMTghOC/jeAmF96OgLdft3tYO2c8Xv1VFZXvIf3mAecfynRqxex4oQBJhxWf fsl72QE76AdMJ0AUqikiEPikQo1+uaGVQExCyFgswh6lcwAVaBnSb0YXv4zcPMHG WcV3q/KDQ1vz4EFbQn9vg+vwBno8cZ8c8rSxCraXPZtN+ipNjZa8YMko9eRdkiVq SDskIoG+UiB+D/fIkI8qPAhjQU/KvQ2wXOkZ7hRoYnIWYrxamu5fxBLldOJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1650666811; x= 1650753211; bh=ThmVhWwIRxMEauQyL/jVTUkDwaugBlkXzx4ACfSe/LY=; b=v qKUzlPbqkSQeRh9XpcVXolcufWhFKL+GsJcVEnu1uZvbjgrJqwOpDE7aqhu5GS7+ FFO6vS7SM1fAmrSSpm+E/kxqm8R937QbgeH4ZKs7ScHujNGkesi91vsrVaFmBBIW lEmEtihPtDArEmEwEtgKYZ48Vdkzg5HSD1iakpTBgCG3gfFT2TfZC9UO1BR56Ipv l1BcR6YWBcBCpEwxgG3FbIQmZh7SMTpQRQ0+L8zFikFOidEBkfVvsJo6JRyVPvED CBIrA87VSNzkAFoNbUZIyn7Nh7B053AFxlQSBFThxci+RFYnwyk8DrnwBeLjbV6A XtU3y39NWDGnmbo98ErkQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrtdehgdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptdehiefgvddufeekkedvtdefvdettd dtkeduvdegveelffdtkeffudejvdfhudetnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 22 Apr 2022 18:33:30 -0400 (EDT) Date: Fri, 22 Apr 2022 23:33:29 +0100 From: tech-lists To: freebsd-current@freebsd.org Subject: Re: bsdinstall partition error when installing to nvme Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <20220422213645.GN28996@FreeBSD.org> <20220422221607.GO28996@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UNER9l+0xeAi1Ss/" Content-Disposition: inline In-Reply-To: <20220422221607.GO28996@FreeBSD.org> X-Rspamd-Queue-Id: 4KlThW4dswz4kSF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm2 header.b=hDKNwdOo; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="v qKUzlP"; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.29 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.69 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm2,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from] X-ThisMailContainsUnwantedMimeParts: N --UNER9l+0xeAi1Ss/ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2022 at 10:16:07PM +0000, Glen Barber wrote: >Yes, please do, in case it is indeed related. done! thanks, --=20 J. --UNER9l+0xeAi1Ss/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmJjLS0ACgkQs8o7QhFz NAXIpg//ayAb7uBeYbINzvD3LQMjrb4kM8rce50cb2qVnNksQSxu+kCL+6/b9Iy2 uF5T+tl+n61I4ocQYfb+4VHnyoVz5uuOyEH6p5D2JWqpSuOEADETe7MTPQ0xYaJy /PKPhBcD0T3viSZuzXRP3ZFoitHV6YssDzLdvbYk7gC4AC4C6ti/hi/9jSbcw3lq hV5ZZUXMmlI4H7+CtAnAsgP0Zl4IdoUFacUX5t7RvKMdVPthDwvf2odQqdPisSy5 S1PGZuIO7Q8SgCL2NI3P0nJ6Qh2th6ZFUgWawxhjjmDAKbSCEa15ag1rKdvl4oNo qe+WNwJmJw1M4DOSu2uD93QJbKGWQe2nukyhNVTbcWgUkoMiYfHpDaLpxsVsZXCJ u+s5yc9wtRfy2EJhJwLrxhNK2b3ZtJpGNkXbMYJXQV6hgKvl/Os+r7RScwp6gvpL zuXOMnH9aLVq6iwLNLymzO0drFzXMt6ROLSbJtcRGuUlzYAfQ7YUwYZKSHXzxotO rg9Ojf1Dj5tv5eqrv3TgS+9CjUUDaaXtpFBDbPfhVJxFLJ+t+Ui9jHsYQsLhjjOc d8EiJV5rcTaLg1z6riCxCrXwLwAzBx753Vhb7gkSgbqvdT8qW75zkS4fEghGjIvZ 9bUZQ1F6ZbV6+t83Z3BLZdgHb1Yn1VPsLiDdyFjPMCJIdPNfMMg= =mwk/ -----END PGP SIGNATURE----- --UNER9l+0xeAi1Ss/-- From nobody Fri Apr 22 23:38:38 2022 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 A4E341A20DDE for ; Fri, 22 Apr 2022 23:38:48 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlW7q3sM3z3Cdq for ; Fri, 22 Apr 2022 23:38:47 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 23MNcerD063514 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 22 Apr 2022 16:38:40 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 23MNcchV063513; Fri, 22 Apr 2022 16:38:38 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Fri, 22 Apr 2022 16:38:38 -0700 From: Gleb Smirnoff To: Florian Smeets Cc: Michael Butler , freebsd-current@freebsd.org Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored Message-ID: References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="XgW92qlAwpHkZehI" Content-Disposition: inline In-Reply-To: <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> X-Rspamd-Queue-Id: 4KlW7q3sM3z3Cdq X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [-1.29 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.85)[-0.847]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-diff]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[freebsd.org]; HAS_ATTACHMENT(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.39)[0.394]; NEURAL_HAM_MEDIUM(-0.74)[-0.740]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --XgW92qlAwpHkZehI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Florian, here is a patch that should help with the IPv6 problem. I'm not yet committing it, it might be not final. -- Gleb Smirnoff --XgW92qlAwpHkZehI Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ip6.sav.diff" diff --git a/sys/netinet6/ip6_input.c b/sys/netinet6/ip6_input.c index 3a13d2a9dc7..625de6d3657 100644 --- a/sys/netinet6/ip6_input.c +++ b/sys/netinet6/ip6_input.c @@ -825,7 +825,7 @@ ip6_input(struct mbuf *m) ip6_sprintf(ip6bufd, &ip6->ip6_dst))); goto bad; } - if (V_ip6_sav && !(rcvif->if_flags & IFF_LOOPBACK) && + if (V_ip6_sav && !(m->m_flags & M_LOOP) && __predict_false(in6_localip_fib(&ip6->ip6_src, rcvif->if_fib))) { IP6STAT_INC(ip6s_badscope); /* XXX */ --XgW92qlAwpHkZehI-- From nobody Fri Apr 22 23:39:30 2022 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 D19291A21A76 for ; Fri, 22 Apr 2022 23:39:32 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlW8h06slz3CnB for ; Fri, 22 Apr 2022 23:39:31 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 23MNdUIB063526 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 22 Apr 2022 16:39:30 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 23MNdUk4063525; Fri, 22 Apr 2022 16:39:30 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Fri, 22 Apr 2022 16:39:30 -0700 From: Gleb Smirnoff To: Michael Butler Cc: Florian Smeets , freebsd-current@freebsd.org Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored Message-ID: References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <0c261aa6-93d4-5627-d44d-f160323a7ca3@protected-networks.net> 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: <0c261aa6-93d4-5627-d44d-f160323a7ca3@protected-networks.net> X-Rspamd-Queue-Id: 4KlW8h06slz3CnB X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [-1.25 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.881]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_SHORT(0.62)[0.620]; NEURAL_HAM_LONG(-0.89)[-0.888]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Apr 16, 2022 at 09:19:57AM -0400, Michael Butler wrote: M> > Michael, can you please confirm or decline that you see the packets M> > that are dropped when you tcpdump on lo0? M> M> All the jails are aliased to share a single bridge interface. That M> results in the route to each jail being on lo0 so .. probably :-) This probably is somehow related to bridge. Can you please help me providing minimal configuration of bridge/jails where the problem shows up? -- Gleb Smirnoff From nobody Fri Apr 22 23:42:42 2022 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 310FA1A238B1 for ; Fri, 22 Apr 2022 23:42:46 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlWDN6MK5z3Fwj for ; Fri, 22 Apr 2022 23:42:44 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1650670963; 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=PePm2wK6y++KI/S0usQ5PsGlLCzWFyqifGFuffI8qaM=; b=ORmrIJVj4kywk+0726j8d+aPn9GSDa4w6c3OwSsOxNcAiphtiyQmnoeSPxOJ0dxNM5nzp0 JTxGduSLb5hqQdapNZXjWUrd8UoV6ewSENK0sSqeD++F3oXoYw8omn8bEV+f2DrjdKIicn o7LIp8TogwhWArc64ta6kkpOxeCv3Zc= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id b82d73ba (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 22 Apr 2022 23:42:42 +0000 (UTC) Message-ID: Date: Fri, 22 Apr 2022 16:42:42 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Content-Language: en-US To: Mark Millard , freebsd-current References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> From: Pete Wright In-Reply-To: <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KlWDN6MK5z3Fwj X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=ORmrIJVj; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-1.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.70)[0.696]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/21/22 21:18, Mark Millard wrote: > > Messages in the console out would be appropriate > to report. Messages might also be available via > the following at appropriate times: that is what is frustrating.  i will get notification that the processes are killed: Apr 22 09:55:15 topanga kernel: pid 76242 (chrome), jid 0, uid 1001, was killed: failed to reclaim memory Apr 22 09:55:19 topanga kernel: pid 76288 (chrome), jid 0, uid 1001, was killed: failed to reclaim memory Apr 22 09:55:20 topanga kernel: pid 76259 (firefox), jid 0, uid 1001, was killed: failed to reclaim memory Apr 22 09:55:22 topanga kernel: pid 76252 (firefox), jid 0, uid 1001, was killed: failed to reclaim memory Apr 22 09:55:23 topanga kernel: pid 76267 (firefox), jid 0, uid 1001, was killed: failed to reclaim memory Apr 22 09:55:24 topanga kernel: pid 76234 (chrome), jid 0, uid 1001, was killed: failed to reclaim memory Apr 22 09:55:26 topanga kernel: pid 76275 (firefox), jid 0, uid 1001, was killed: failed to reclaim memory the system in this case had killed both firefox and chrome while i was afk.  i logged back in and started them up to do more more, then the next logline is from this morning when i had to force power off/on the system as they keyboard and network were both unresponsive: Apr 22 09:58:20 topanga syslogd: kernel boot file is /boot/kernel/kernel > Do you have any swap partitions set up and in use? The > details could be relevant. Do you have swap set up > some other way than via swap partition use? No swap? yes i have a 2GB of swap that resides on a nvme device. > ZFS (so with ARC)? UFS? Both? i am using ZFS and am setting my vfs.zfs.arc.max to 10G.  i have also experienced this crash with that set to the default unlimited value as well. > > The first block of lines from a top display could be > relevant, particularly when it is clearly progressing > towards having the problem. (After the problem is too > late.) (I just picked top as a way to get a bunch of > the information all together automatically.) since the initial OOM events happen when i am AFK it is difficult to get relevant stats out of top. this is why i've started collecting more detailed metrics in prometheus.  my hope is i'll be able to do a better job observing how my system is behaving over time, in the run up to the OOM event as well as right before and after.  there are heaps of metrics collected though so hoping someone can point me in the right direction :) -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Fri Apr 22 23:46:20 2022 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 982121A2575F for ; Fri, 22 Apr 2022 23:46:22 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlWJY6SFNz3HYj for ; Fri, 22 Apr 2022 23:46:21 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1650671180; 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=lwFcF9CSNVI8kts/g99F9U++r1AwJNxN6fEY7puoKTg=; b=WR8W9EFNSSydpPpx5TTrx29aj3f+9YJjmzCwXjjxteO37wgGXHcuzYo8Sno8Fsxhhpbi9B mB/5wHWZKbd8/pzQNa2QHb+8By5hE1Dcm/rAm5SDZvbrfS+LGF8aDF418YPONVMWzWql0D Ncex6S8pfwCD7WESPC3ldM0tjK5l0Go= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 983dfdbd (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 22 Apr 2022 23:46:20 +0000 (UTC) Message-ID: Date: Fri, 22 Apr 2022 16:46:20 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Content-Language: en-US To: freebsd-current@freebsd.org References: From: Pete Wright In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KlWJY6SFNz3HYj X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=WR8W9EFN; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-1.08 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.92)[0.919]; DKIM_TRACE(0.00)[nomadlogic.org:+]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/22/22 13:39, tech-lists wrote: > Hi, > > On Thu, Apr 21, 2022 at 07:16:42PM -0700, Pete Wright wrote: >> hello - >> >> on my workstation running CURRENT (amd64/32g of ram) i've been running >> into a scenario where after 4 or 5 days of daily use I get an OOM event >> and both chromium and firefox are killed.  then in the next day or so >> the system will become very unresponsive in the morning when i unlock my >> screensaver in the morning forcing a manual power cycle. > > I have the following set in /etc/sysctl.conf on a stable/13 > workstation. Am using zfs with 32GB RAM. > > vm.pageout_oom_seq=120 > vm.pfault_oom_attempts=-1 > vm.pageout_update_period=0 > > Since setting these here, OOM is a rarity. I don't profess to exactly > know > what they do in detail though. But my experience since these were set > is hardly any OOM and big users of memory like firefox don't crash. nice, i will give those a test next time i crash which will be by next thurs if the pattern continues. looking at the sysctl descriptions: vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM vm.pfault_oom_attempts: Number of page allocation attempts in page fault handler before it triggers OOM handling vm.pageout_update_period: Maximum active LRU update period i could certainly see how those could be helpful.  in an ideal world i'd find the root cause of the system lock-ups, but it would be nice to just move on from this :) cheers, -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Sat Apr 23 00:24:04 2022 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 EE3AA198F2FA for ; Sat, 23 Apr 2022 00:24:06 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlX860wMKz3NYQ; Sat, 23 Apr 2022 00:24:06 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 23N0O4xQ063657 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 22 Apr 2022 17:24:04 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 23N0O4BL063656; Fri, 22 Apr 2022 17:24:04 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Fri, 22 Apr 2022 17:24:04 -0700 From: Gleb Smirnoff To: Michael Tuexen Cc: Florian Smeets , Michael Butler , freebsd-current@freebsd.org, melifaro@freebsd.org Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored Message-ID: References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KlX860wMKz3NYQ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [-0.77 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.83)[-0.829]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.92)[0.919]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-0.76)[-0.759]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Michael, On Sat, Apr 23, 2022 at 01:54:25AM +0200, Michael Tuexen wrote: M> > here is a patch that should help with the IPv6 problem. I'm not M> > yet committing it, it might be not final. M> M> when I was looking at the code, I was also wondering if it would make M> more sense to check for M_LOOP. M> M> However, isn't the rcvif wrong for the first two received packets? I M> would expect it always to be the loopback interface. Is that expectation M> wrong? The IPv6 has a special feature of calling (ifp->if_output)(origifp, ... I don't fully understand it, but Alexander does. What I can observe is that it works differently for the original packet, its first retransmit and second retransmit. Still unclear to me why. Here is how to observe it: dtrace -n 'fbt::ip6_output:entry { printf("ro %p ifp %p\n", args[2], args[2]->ro_nh ? args[2]->ro_nh->nh_ifp : 0); }' -n 'fbt::ip6_output_send:entry { printf("ifp %p origifp %p\n", args[1], args[2]); }' And you will see this: 1 45625 ip6_output:entry ro fffff800122c19a0 ifp 0 1 22539 ip6_output_send:entry ifp fffff800027cb800 origifp fffff800020db000 0 45625 ip6_output:entry ro fffff800122c19a0 ifp fffff800027cb800 0 22539 ip6_output_send:entry ifp fffff800027cb800 origifp fffff800020db000 0 45625 ip6_output:entry ro fffff800122c19a0 ifp fffff800027cb800 0 22539 ip6_output_send:entry ifp fffff800027cb800 origifp fffff800027cb800 So, on packet three (second retransmit) the origifp is equal to ifp (is lo0) and now packet passes validation. However, the more I read it, the more it seems to me that actually packet three is incorrect and first two are correct :) To cope with this self inflicted damage of (ifp->if_output)(origifp, IPV6 introduced M_LOOP and uses it internally. Looks like a quick solution for IPv6 is to use it. However, I will commit it only once we got understanding why the hell a second retransmit is different. M> I also have an additional question: M> Why is this check protected by an (ia != NULL) condition? It does not make M> any use of ia? It is a host protection feature, so checks only packets that are destined to us. This allows to do basic antispoof checks for a host not equipped with any firewall. For a machine acting as a router better behavior is not to drop anything routed through unless explicitly told so by a filtering policy. -- Gleb Smirnoff From nobody Sat Apr 23 01:36:27 2022 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 D970C1A8055A for ; Sat, 23 Apr 2022 01:36:32 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlYlh25QQz3p34; Sat, 23 Apr 2022 01:36:32 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:3c04:dbac:3dcb:cb4d]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 4E963721E2808; Sat, 23 Apr 2022 03:36:28 +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 \(3696.80.82.1.1\)) Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored From: tuexen@freebsd.org In-Reply-To: Date: Sat, 23 Apr 2022 03:36:27 +0200 Cc: Florian Smeets , Michael Butler , freebsd-current@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <592A0A46-C703-4F93-9F43-5D167469A921@freebsd.org> References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> To: Gleb Smirnoff X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4KlYlh25QQz3p34 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 193.175.24.27 is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org X-Spamd-Result: default: False [-2.58 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[tuexen]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.98)[-0.981]; R_SPF_SOFTFAIL(0.00)[~all:c]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.961]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.942]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[193.175.24.27:from] X-ThisMailContainsUnwantedMimeParts: N > On 23. Apr 2022, at 01:38, Gleb Smirnoff wrote: > > Hi Florian, > > here is a patch that should help with the IPv6 problem. I'm not > yet committing it, it might be not final. Hi Gleb, when I was looking at the code, I was also wondering if it would make more sense to check for M_LOOP. However, isn't the rcvif wrong for the first two received packets? I would expect it always to be the loopback interface. Is that expectation wrong? I also have an additional question: Why is this check protected by an (ia != NULL) condition? It does not make any use of ia? Best regards Michael > -- > Gleb Smirnoff > From nobody Sat Apr 23 01:46:56 2022 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 1B6041A83DC9 for ; Sat, 23 Apr 2022 01:47:11 +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 ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlYzx277fz3rL6 for ; Sat, 23 Apr 2022 01:47:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650678422; bh=BOuDlGBOdTo+iX3nq1ikGs6jHkjqF7p1aMbqWgng6uo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=aFPMnPnbLDNFkmwkpqvfwgz9otpQygrIRoqsydtAprawrpczQj9Khyvq3PhkXvhWw78fSmhYDNX2Mf34b6F32P7SvVHg5fKaD0mUz8g0nyLIQ4OHMCBNdh54ztRDxjQzQpsk0c8VHeUgyzOowR6utyzGDMHiakrkQZBwSfBaiyWLYtdB+39a1zmKdI0L4PEiDmUHQs5cqACXRjgbtx+gBpOqiJonbXZV42+t4qXPVSk+pzMyPY7ZElBrMBnT8Kj6SRrFwXyvmDlyb+p1Cja3O+MOT0mTsABIKXj/dtl8/l3yvSSpdOu3QgI+biuVkyI2dgQiSps5IN52ahFEfJOyHQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650678422; bh=+MNW7omTO82MqqPcz/frMTS3YAHvxpkFqb4+nN0CML7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PPgsdfnHrHwZpCbYkIOhA+Eku9vEEB8dylN6RnNYUX4/648b9UH7eALqsDM4bnKw2q+nLxY/hD5/ewYP5aev1Z6mveS2R5Fd/lmeLQw8aCOJeQoDz5DJK3+PIuSGAjdRO7R450QydAskDk1Nv8D4q4gVjPh7qHahdOoVM0tyKUWQjn0yDJbMkNIGtDDGxLaAcfry1fuqR6DvAmJfoIDiUiSowOmUgqb06zzh591lm2HYMOjLltraZTroASVsSYESqmpo3Qw6zrKxjOi+eSkuv0sQfa8hRoHOccm82VQoxSX2aG1gxfiC7u/smDT7zHCVlgvS2+zA+m6xis0Y+IZ2+g== X-YMail-OSG: iuV.Q5oVM1mxBbgdG_etjxJfNZ1lU0mw4t5CffrGqCArd08t.lBDnkBKSZQ5j_Y 6MOdlRRVN8VcEI8pNS01CJ8Xjq_DvlmnPxqMV64zbObahNhN3cs0xMawKtkXvZcc62qMcW27WaVK qUSaBLdAijj.lCSYOXK11DySgOFGpTLpwt8eoTfEpNIAMcXKmjjw65ALse3t7Gr4SlmPGcDtonIP M.DeWnoBnFzwMsXw7Mo3B4z_Roig_4Hiy2dZOxT4TYmAbCnE4MAGxv.FIrQu5HsjJJJkNPWAoXoF L0MfGPU5zwCoQ9q06hCLqamafDDYbnXpNhvEDdDU6EScKTEjLuwKlKiMv_ei2xyRXZfMzL3fcu7J FgsJ94X1Bd7zGv.iMEfaxQyOO37WrR.MaWdVMWcWHOl0MHbK4sQlbmstEP9LywJkTJHVK6eHzLc5 PRf6MheWeozJOYo6lhWMl1.FpX8cLkK9crLvZo6QwToTERMPktnckD97epfkOJKCKnhQzJu8eXl6 kzinHvujDRYUfmApkoB98SeqWUtYKz_hpwMAyc91lfzqelt.OyblRcNurcEsxpQSsCh.Gdt_w8sK pbKhao8nFJRG17w6QmLOmzML9oLYWN48W5RTkN6JYX_2P7sQH5HS2iNUO4XfhBWmXPCa4XiN4_Lf AUbyfwYA7OyuV4nNH1uG1KgEw6beEthJ6rlBZHPkbwYPtJ3YwRw_kitHlMVRGv7wkyRJqzSeQrzk Pdb5N6_C1jV37VdvbcJPv5FfqoPFxCK7IBg3xl7CHSQy7Fn3lC069.eRWrUxNLnAlSy1kpqQ7vuM WqRKmd_NFM9YaTvZhfp5pSSxYKO5YYHRtsdlynFEWmqWo_Ga88c.wGXIWJcrGKwc94EBS.m76BSu vBrYdbTfLl9qgkaAw4n2sQ.jZZgTbxrSbgovIicrj4omOlfjOCEnX6wDLcuTNU.6FHDJAHMvClBJ t0hkF78GA7sJ3GKgkiTjCHX_zJ2Q34MfR_24cNp4zmLUFyXVBry4D2dPUJ57.OLbhwDfuyHZ8tj6 oRVPBvu1QF6R3wDdAGOJ6W8iwr6thL2oFikpChDj2H_wAfWJwWn1X0KOFYkkENH8Yf7abC09QREP qiJhj8NJreoZkkLgi_hsS5jzaFXCvX4dbOMfcyoG9a3IbRKrpfZyu9f0NcqNOAwYTDfroCc5XK4X 9iN7briEPy0.DM4R92b_CFQ_KKfldGqbLFFggRVQ_1gkxRCVe1JgtWBQ9j9tf1FWfvztfQ9EBAse hwGX4gkQRGFNRjYzuI.skyBsGGu1Ko7dRX4wY5.CpTN2UAWo1KFYcY0hxSU5gH42935stZ4t2wJT n4uG4zO6i8ypWnrTU44d8RjM5Ysp.H4IKCA35Pt5ss83MSvVKQsiCabbcVulbSrKfK4euyyDmlgu _xq8hugilBCmiRK3en3oQE0pUioTpZx__H0XIy07l2HyMkaNYMzZhvABuR76KaOJxyfVKXZ._XFc LgdeXrJQwKMG.ggCkNpGt0Bg2J9QQcrLyl_94qwZw0XFy67rekull0_mijcjUloEBaWqLnJUdZ4F NR7540LV4W82Rls6Su8nriR7GZdUVXAFP1FH5d74XtM6vyutzMAuYy3CJHl8DZSHO8kuIw1Felcm 1ZTMBEFNdDvcnHDjTOGbHJTZNiYulzqoQP8ySQMXE0Q8YJ_uXfInNm2DBvYCX_SS0hboy4LHjUDA oyQbulcUNNcHisVm2g1v9HAUna3uysdN1E5zkOPtV7vqa1tYMz53lZVpOyJOd8UBlgwt8NLBk89Q vMgVtbJVC4EF8_.aFR0QR8hUnuzfiXrvoBDa.jNmAhdGv9Ej9Ba31vlTlxD82bnr8O5WVSVWv_gw xrDXczKgMuuV5Ldj.RVor_1eBiSNBHy4Oy60Txamws3FYgpKtdvRq7nKXxmbAzf7MjYnHK9s_yBN VI1n5cBzIuZp7mBNH3s9GfVaYEZusHUAGxwMCvFH4SqUqS0tnYPeQsOwDE611azrX4Txeelql8bv fGP.X7MKL4FFV1meAH9R07s3fvyMku8H1r54KOw4Zntr6pkN1EziBaMnNz3dm1TiNUwLygAMXzBU FtejCdqTqv32p0QfbzZlY3qHRBhUwbG40S2my1PAbT9WSlBDRNpkbF7scmzDSO25FoGHklDC8XX4 YSED4MqOv0GUllK_R.jXFkkiVoeepBGYr4_cqo.CxJ4QelbRDpZm0FyMeNBo0HzCfnda3Geltycz YycWE2gPxxjkfXJ351qlSQOwi4jnOzRPYEQdyFgOW_hc3tKFJwdlE4E3QAzA9eeRJLWaHRiJsk1w QT1pnPRHeW7qVDQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Apr 2022 01:47:02 +0000 Received: by hermes--canary-production-gq1-6b7487d8dd-zffkr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 45ebfc647c1efabf60596bee80269486; Sat, 23 Apr 2022 01:46:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? From: Mark Millard In-Reply-To: Date: Fri, 22 Apr 2022 18:46:56 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> To: Pete Wright X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KlYzx277fz3rL6 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aFPMnPnb; 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 X-Spamd-Result: default: False [-0.62 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.85)[0.852]; NEURAL_HAM_LONG(-0.97)[-0.971]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-22, at 16:42, Pete Wright wrote: > On 4/21/22 21:18, Mark Millard wrote: >>=20 >> Messages in the console out would be appropriate >> to report. Messages might also be available via >> the following at appropriate times: >=20 > that is what is frustrating. i will get notification that the = processes are killed: > Apr 22 09:55:15 topanga kernel: pid 76242 (chrome), jid 0, uid 1001, = was killed: failed to reclaim memory > Apr 22 09:55:19 topanga kernel: pid 76288 (chrome), jid 0, uid 1001, = was killed: failed to reclaim memory > Apr 22 09:55:20 topanga kernel: pid 76259 (firefox), jid 0, uid 1001, = was killed: failed to reclaim memory > Apr 22 09:55:22 topanga kernel: pid 76252 (firefox), jid 0, uid 1001, = was killed: failed to reclaim memory > Apr 22 09:55:23 topanga kernel: pid 76267 (firefox), jid 0, uid 1001, = was killed: failed to reclaim memory > Apr 22 09:55:24 topanga kernel: pid 76234 (chrome), jid 0, uid 1001, = was killed: failed to reclaim memory > Apr 22 09:55:26 topanga kernel: pid 76275 (firefox), jid 0, uid 1001, = was killed: failed to reclaim memory Those messages are not reporting being out of swap as such. They are reporting sustained low free RAM despite a number of less drastic attempts to gain back free RAM (to above some threshold). FreeBSD does not swap out the kernel stacks for processes that stay in a runnable state: it just continues to page. Thus just one large process that has a huge working set of active pages can lead to OOM kills in a context were no other set of processes would be enough to gain the free RAM required. Such contexts are not really a swap issue. Based on there being only 1 "killed:" reason, I have a suggestion that should allow delaying such kills for a long time. That in turn may help with investigating without actually suffering the kills during the activity: more time with low free RAM to observe. Increase: # sysctl -d vm.pageout_oom_seq vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM The default value was 12, last I checked. My /boot/loader.conf contains the following relative to that and another type of kill context (just comments currently for that other type): # # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: #vm.pfault_oom_attempts=3D-1 # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes (showing defaults at the time): #vm.pfault_oom_attempts=3D 3 #vm.pfault_oom_wait=3D 10 # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied, even for nearly the same total.) There is no value of vm.pageout_oom_seq that disables the mechanism. But you can set large values, like I did --or even larger-- to wait for more attempts to free some RAM before the kills. Some notes about that follow. The 120 I use allows even low end arm Small Board Computers to manage buildworld buildkernel without such kills. The buildworld buildkernel completion is sufficient that the low-free-RAM status is no longer true and the OOM attempts stop --so the count goes back to 0. But those are large but finite activities. If you want to leave something running for days, weeks, months, or whatever that produces the sustained low free RAM conditions, the problem will eventually happen. Ultimately one may have to exit and restart such processes once and a while, exiting enough of them to give a little time with sufficient free RAM. > the system in this case had killed both firefox and chrome while i was = afk. i logged back in and started them up to do more more, then the = next logline is from this morning when i had to force power off/on the = system as they keyboard and network were both unresponsive: >=20 > Apr 22 09:58:20 topanga syslogd: kernel boot file is = /boot/kernel/kernel >=20 >> Do you have any swap partitions set up and in use? The >> details could be relevant. Do you have swap set up >> some other way than via swap partition use? No swap? > yes i have a 2GB of swap that resides on a nvme device. I assume a partition style. Otherwise there are other issues involved --that likely should be avoided by switching to partition style. >> ZFS (so with ARC)? UFS? Both? >=20 > i am using ZFS and am setting my vfs.zfs.arc.max to 10G. i have also = experienced this crash with that set to the default unlimited value as = well. I use ZFS on systems with at least 8 GiBytes of RAM, but I've never tuned ZFS. So I'm not much help for that side of things. For systems with under 8 GiBytes of RAM, I uses UFS unless doing an odd experiment. >> The first block of lines from a top display could be >> relevant, particularly when it is clearly progressing >> towards having the problem. (After the problem is too >> late.) (I just picked top as a way to get a bunch of >> the information all together automatically.) >=20 > since the initial OOM events happen when i am AFK it is difficult to = get relevant stats out of top. If you use vm.pageout_oom_seq=3D120 (or more) and check once and a while, I expect you would end up seeing the activity in top without suffering a kill in short order. Once noticed, you could start your investigation, including via top if desired. > this is why i've started collecting more detailed metrics in = prometheus. my hope is i'll be able to do a better job observing how my = system is behaving over time, in the run up to the OOM event as well as = right before and after. there are heaps of metrics collected though so = hoping someone can point me in the right direction :) I'm hoping that vm.pageout_oom_seq=3D120 (or more) makes it so you do not have to have identified everything up front and can explore easier. Note that vm.pageout_oom_seq is both a loader tunable and a writeable runtime tunable: # sysctl -T vm.pageout_oom_seq vm.pageout_oom_seq: 120 amd64_ZFS amd64 1400053 1400053 # sysctl -W vm.pageout_oom_seq vm.pageout_oom_seq: 120 So you can use it to extend the time when the machine is already running. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 23 01:57:42 2022 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 F3CD31A86760 for ; Sat, 23 Apr 2022 01:57:53 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlZDJ6H6tz3sw9; Sat, 23 Apr 2022 01:57:52 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:3c04:dbac:3dcb:cb4d]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id AED97721E2808; Sat, 23 Apr 2022 03:57:42 +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 \(3696.80.82.1.1\)) Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored From: tuexen@freebsd.org In-Reply-To: Date: Sat, 23 Apr 2022 03:57:42 +0200 Cc: Florian Smeets , Michael Butler , freebsd-current@freebsd.org, melifaro@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <43CF838A-0C48-4ABC-8A5F-FBC0C39B21AA@freebsd.org> References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> To: Gleb Smirnoff X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4KlZDJ6H6tz3sw9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:638:a02:a001:20e:cff:fe4a:feaa is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org X-Spamd-Result: default: False [-1.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[tuexen]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.59)[-0.588]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.806]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 23. Apr 2022, at 02:24, Gleb Smirnoff wrote: >=20 > Michael, >=20 > On Sat, Apr 23, 2022 at 01:54:25AM +0200, Michael Tuexen wrote: > M> > here is a patch that should help with the IPv6 problem. I'm not > M> > yet committing it, it might be not final. > M>=20 > M> when I was looking at the code, I was also wondering if it would = make > M> more sense to check for M_LOOP. > M>=20 > M> However, isn't the rcvif wrong for the first two received packets? = I > M> would expect it always to be the loopback interface. Is that = expectation > M> wrong? >=20 > The IPv6 has a special feature of calling (ifp->if_output)(origifp, = ... >=20 > I don't fully understand it, but Alexander does. >=20 > What I can observe is that it works differently for the original = packet, > its first retransmit and second retransmit. Still unclear to me why. I consider this also strange. The three packets are identical. So I would expect, that all of these are handled the same way. >=20 > Here is how to observe it: >=20 > dtrace > -n 'fbt::ip6_output:entry > { printf("ro %p ifp %p\n", args[2], args[2]->ro_nh ? = args[2]->ro_nh->nh_ifp : 0); }' > -n 'fbt::ip6_output_send:entry { printf("ifp %p origifp %p\n", = args[1], args[2]); }' >=20 > And you will see this: >=20 > 1 45625 ip6_output:entry ro fffff800122c19a0 ifp 0 > 1 22539 ip6_output_send:entry ifp fffff800027cb800 = origifp fffff800020db000 >=20 > 0 45625 ip6_output:entry ro fffff800122c19a0 ifp = fffff800027cb800 > 0 22539 ip6_output_send:entry ifp fffff800027cb800 = origifp fffff800020db000 >=20 > 0 45625 ip6_output:entry ro fffff800122c19a0 ifp = fffff800027cb800 > 0 22539 ip6_output_send:entry ifp fffff800027cb800 = origifp fffff800027cb800 >=20 > So, on packet three (second retransmit) the origifp is equal to ifp = (is lo0) and now > packet passes validation. However, the more I read it, the more it = seems to me that > actually packet three is incorrect and first two are correct :) >=20 > To cope with this self inflicted damage of (ifp->if_output)(origifp, = IPV6 introduced > M_LOOP and uses it internally. Looks like a quick solution for IPv6 is = to use it. > However, I will commit it only once we got understanding why the hell = a second retransmit > is different. >=20 > M> I also have an additional question: > M> Why is this check protected by an (ia !=3D NULL) condition? It does = not make > M> any use of ia? >=20 > It is a host protection feature, so checks only packets that are = destined to us. > This allows to do basic antispoof checks for a host not equipped with = any firewall. Understood. I was confused, since all other code protected by (ia !=3D = NULL) actually depends on ia not being the NULL pointer. Best regards Michael >=20 > For a machine acting as a router better behavior is not to drop = anything routed > through unless explicitly told so by a filtering policy. >=20 > --=20 > Gleb Smirnoff From nobody Sat Apr 23 05:51:10 2022 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 1E86D1A969FC for ; Sat, 23 Apr 2022 05:51:12 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlgPW15Kdz4rfZ for ; Sat, 23 Apr 2022 05:51:11 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: by mail-ej1-x629.google.com with SMTP id g13so20092942ejb.4 for ; Fri, 22 Apr 2022 22:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=gB8ruTxzzg3OB4vNHsj0VcGapg8M0Qyq9IyTrmYcBmE=; b=KagmXGC6VlnnwfuHlchE/1DhNYtgnkLub89XBTePJaSfr2i/Z3W2UWue2hlKcaBXXH ldkKMRCgScYg3mnBXVc5fQRDjHNWJqLiE1SVqmqUoeNE7ZSas1jXd4KZkmyrITuTYzdL lYWdNulQDGAQthq9Ct1MVmnJQ1vY1jhiDlnvriMgNqXLF/k0WolsuGuJ4ACVRcCK7fig 36Gu486q/lMV2Kk48LwcOuZZYb3YH4hBtTk0d+dCHmedSCyrkvjHA6IO46ITNzg4UU0a K+zbj8cm/TZwVTvOuYyNmaMi3F1du2hrZZbmZ7b/Qn6OzmiLRRgd8LCi3+fVHvHd4YeG EQ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=gB8ruTxzzg3OB4vNHsj0VcGapg8M0Qyq9IyTrmYcBmE=; b=BKVxf9vKw32oU6jmyUYcj2CagcS2l8i1sgxopZngwe4kBsTlix0zswwfiy7NOuHPKk aDbKgXnPPgt0KOpKT5+XfBnrH/6QUHsx0TOcKP2JlP+SG1+MPpMvGLrNGVpKHTmvaVx9 q13NziXBsS75LKQz7BAnZDBkJF4UDMbSH2390c0C4h9PheKtdG/YXM9+uVAiottz/b5Q uEaN8v0oEY5HOoYKibIV/UDxXmNkMdC4nA43V/EWnJCG6Wz3fRVrfIOsLLam0wMow4Ma oGRd9gvsEBo4G9b10tv0ruq1/25qA4fM5AmOD2U8ViV7GvbfFvAoAl+wzi7seNS+xM+W dh0g== X-Gm-Message-State: AOAM532DOFjGoxSVc2Exj8Z8a34BoBGQmiEf2gh3NceJvDci5qUN4/zi JqwuKDi+AsdS7a/Dz0ElKUGyPxa3Fhk= X-Google-Smtp-Source: ABdhPJzQIALlWW634u4DhjBjjhGyvt5VsosHJKj3x3aZlEWxdiqo1+yEq8nsiBwwWkRMPAxrvbJD6w== X-Received: by 2002:a17:907:d29:b0:6f2:48a0:7186 with SMTP id gn41-20020a1709070d2900b006f248a07186mr5875730ejc.102.1650693070206; Fri, 22 Apr 2022 22:51:10 -0700 (PDT) Received: from [192.168.1.31] (host-79-47-8-16.retail.telecomitalia.it. [79.47.8.16]) by smtp.gmail.com with ESMTPSA id j4-20020a170906278400b006e99f136c78sm1364925ejc.23.2022.04.22.22.51.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 Apr 2022 22:51:09 -0700 (PDT) Message-ID: <93888cc1-ffef-25e0-8910-c90391778a4f@gmail.com> Date: Sat, 23 Apr 2022 07:51:10 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: bsdinstall partition error when installing to nvme Content-Language: en-US To: freebsd-current@freebsd.org References: From: "Alfonso S. Siciliano" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KlgPW15Kdz4rfZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=KagmXGC6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of alfix86@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=alfix86@gmail.com X-Spamd-Result: default: False [-2.53 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[79.47.8.16:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.47)[0.474]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/22/22 23:31, tech-lists wrote: > Hi, > > Attempting to install from: > FreeBSD-14.0-CURRENT-amd64-20220421-b91a48693a5-254961-memstick.img > > to brand-new hardware, the installer failed at the stage after where one > selects partition schema (so, GPT in this case) and UFS filesystem > with an error like (sorry to be paraphrasing this from memory as the > hardware is no longer available) > > "autopart failed -5" > > I thought it might be down to it being a nvme stick. The hardware > in question is Crucial;CT1000P5PSSD8 1TB. Is this a known issue > with nvme? On that machine, this was the only "disk". Can > nvme be used as the primary disk on FreeBSD? > Thank you for the report, Reading "autopart failed -5", probably you chose "Auto UFS Guided Disk", I found a problem with Auto Partitioning in CURRENT. This should solve: . However, to be sure, you could reinstall choosing "Manual" Partitioning to understand if the cause is "nvme" or "bsdinstall". Alfonso From nobody Sat Apr 23 11:53:36 2022 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 1017E11C8856 for ; Sat, 23 Apr 2022 11:53:40 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 4KlqRl1GL1z4ZMx for ; Sat, 23 Apr 2022 11:53:38 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6E9725C0140 for ; Sat, 23 Apr 2022 07:53:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 23 Apr 2022 07:53:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1650714818; x=1650801218; bh=6sl2ZPVMB2 s21Nh37dcsX/mIiAxAQUQReWY9YsP6IOM=; b=ITY6ucF+y6faQalBwSl8P+mKfv mNsfe3jzSAqjfUzIwNht1FUV5LAXMxApFlVMWw96G6xYPi4q+rThtSK8i9B7lxBR YsyKzclEHU0Gmd0YLik8HdqSd7p5UibJNAlkBNwB3Sc88iL/PEQMtbvTk8s2wWc8 aGYxjYypCMgiQ6RfzJgZT+xVAi5xV6LX2TQ2gkEbVXtPXM7zONiZlVe+DaMPxio5 m8XG+nEZpUxqV3I29B/wmsZiTaWiXPGyLTByoOfFmyIsIzOyIDB8J5NRe47ggkuU 9Mt5FNCzPrrYtovC8FoAJIMROUDzIGSBGiOYsbJtA9z20PY/mXihLfGs0IIw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1650714818; x= 1650801218; bh=6sl2ZPVMB2s21Nh37dcsX/mIiAxAQUQReWY9YsP6IOM=; b=Y cV8qah304rTErccmplN1f3low9x9sfJdEDj15kLQQifG8QuB+WK2VTI+kEuGFLDD KQE/AA/ENejgoQ4Mc1nyiUYM8LQkDvO6B7pW/gFviD22pNvfBa1M8lcFDzm8Tdyv V5QSurPjrOJHYRSr20obtUYIWcTacUrkJWhzVeR4jp+9VsVJQsYQsLnQSc8ctao9 Su5FDV62fMMrgxnnqe4PtZWi6/9h1b1tpmqNBiZ0EBt5gd+L19txQt63LufUO55e I4DSUD7E+kgWIJv62nKjBGrO+2vJ1eqkxdunQHMXZBlp37Cgcck6jLnQtMdrsyHA EpgkfAHQQBYcyzGStke0w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrtdeigdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtderre dttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshesiiih gihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptedttdduuefggeeghfekkeetkeejle efffelheejfffgffdtfeeftdejgeeuieffnecuffhomhgrihhnpehfrhgvvggsshgurdho rhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepth gvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 23 Apr 2022 07:53:37 -0400 (EDT) Date: Sat, 23 Apr 2022 12:53:36 +0100 From: tech-lists To: freebsd-current@freebsd.org Subject: Re: bsdinstall partition error when installing to nvme Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <93888cc1-ffef-25e0-8910-c90391778a4f@gmail.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UIS6znQNCOctNeJ6" Content-Disposition: inline In-Reply-To: <93888cc1-ffef-25e0-8910-c90391778a4f@gmail.com> X-Rspamd-Queue-Id: 4KlqRl1GL1z4ZMx X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm2 header.b=ITY6ucF+; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="Y cV8qah"; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.29 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.36 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm2,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-0.66)[-0.660]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from] X-ThisMailContainsUnwantedMimeParts: N --UIS6znQNCOctNeJ6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Sat, Apr 23, 2022 at 07:51:10AM +0200, Alfonso S. Siciliano wrote: > >Thank you for the report, > > >Reading "autopart failed -5", probably you chose "Auto UFS Guided Disk", Yes, this is true, it's what was tried first.=20 >I found a problem with Auto Partitioning in CURRENT. >This should solve: . > >However, to be sure, you could reinstall choosing "Manual" Partitioning >to understand if the cause is "nvme" or "bsdinstall". I *think* i tried this. I remember thinking "hmm why is autopart=20 invoked in a manual context" but I can't be 100% sure, and can't test again until i'm in a position to install to nvme hardware again. But thanks for looking at this and fixing it. --=20 J. --UIS6znQNCOctNeJ6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmJj6LYACgkQs8o7QhFz NAWgJQ/+MDTC919VZpa2OEUVVtmS3UxrXLLVh8gih+3FjyDpGd5C4gEtiwG8YSKw cXOXUjEbCZBLJ4DttckJ/3DPWd+ioKgg8aZibfyKNTbCguxBJ7TaLFAaJ5qxB3Ee nGzcWrZLQ1MZcPsShqdvJU3GcyPrNjxnf5cZEdTbR7EJtyqh5z4SoF9/ZkmAFMWB sEI1ebwIkLUK1UYjc0E09fD2mWTHKcjy9xj96eDMvjWEqGadKSi89FYkc01EjVVB BrnaYBQKY3e/x/wB8UsH99JNLAL15TFbr+GyRWBoj3XuEDlkvDaDcEmEsytHlQXi h+jouPESzfbovqogURtf+5Qbyp11WAW+Akb6v3g01xgUue0FkLPIdAX+3CLB8/dw Ez/eM+BE2kxJ2IA7yQE+NbLNYkv57lT1JTc7VBlqWuP7TgIgxxvigEt5fwOHnMjr YE4aOmZE3PAoZNDVZEM/8j1+en6DJ4SJmPoXpG+SyP/hcqt0blvKkiu5iNxo8B7H Lc1kvfBJoC2j1g/NZEPcnqcN3DpY51a5g1P/7vwvwVjMfqnnUQA6jsRGecgDGExE KVqiQaC5n2ES7ak6hMvVw+iUzBQQ56z7eSvQBJ8A7qy/hkVONPhF5O4JzrvgCKQU xC90LKjnWDEtwUgyq3SUUOCXqG9p0OtnApTEQlYmoRm92IkozOY= =M9mH -----END PGP SIGNATURE----- --UIS6znQNCOctNeJ6-- From nobody Sat Apr 23 16:35:49 2022 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 639F9199AC03 for ; Sat, 23 Apr 2022 16:36:00 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [IPv6:2a0c:5a00:149::26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlxjW5QWNz3N8X for ; Sat, 23 Apr 2022 16:35:59 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1niIjd-002sYj-N3; Sat, 23 Apr 2022 18:35:49 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iherebuywisely.com; s=selector1; h=Message-Id:In-Reply-To:Date:Subject:CC: To:From:MIME-Version:Content-Transfer-Encoding:Content-Type; bh=0o3gCun3I087c+kt9FPk/3N5v0HywcitnVjDx6tPmMM=; b=HDnIHYbVso3eGQpmEEzQNkCl+V wNWFYW9+bhUsyBoUYg9vtcH4m2ONjbhdNi+uvcLBH1lk4UJty6gKuXq7/ThaRc3Xafo/FRE0u1uNr jSBnCj8bI8sree4mKWN8PCD7N7lfUcWwOl2TzEHbPwG0ILburcogzBRmR6ebHRTahGt2EdYF0/wiL GJxht/Mx0wZNwYADmZ3YnJV4z8Av5W7a1WyoKBKZh/tDhATDlvFKmzUP6os9aBIlAseBHnT0ObrGM TQe6EErrdGHcIDcWwsllZN/OcB3HUmJpnQpAfMS8BWqdKLVM3BnFz+jE3vB14ZaNUbIQmme09JG14 f7ufBZhg==; Received: from [10.9.9.128] (helo=rmmprod06.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1niIjd-0007QK-60; Sat, 23 Apr 2022 18:35:49 +0200 Received: from mail by rmmprod06.runbox with local (Exim 4.86_2) (envelope-from ) id 1niIjd-0000mL-4y; Sat, 23 Apr 2022 18:35:49 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline 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 Received: from [Authenticated alias (650894)] by runbox.com with http (RMM6); Sat, 23 Apr 2022 16:35:49 GMT From: "Jeffrey Bouquet" To: "Pete Wright" CC: "freebsd-current" Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Date: Sat, 23 Apr 2022 09:35:49 -0700 (PDT) X-RMM-Aliasid: 650894 X-Mailer: RMM6 In-Reply-To: Message-Id: X-Rspamd-Queue-Id: 4KlxjW5QWNz3N8X X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=iherebuywisely.com header.s=selector1 header.b=HDnIHYbV; dmarc=none; spf=pass (mx1.freebsd.org: domain of jbtakk@iherebuywisely.com designates 2a0c:5a00:149::26 as permitted sender) smtp.mailfrom=jbtakk@iherebuywisely.com X-Spamd-Result: default: False [0.77 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.41)[-0.410]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a0c:5a00:149::26]; NEURAL_SPAM_SHORT(0.57)[0.569]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[iherebuywisely.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[iherebuywisely.com:~]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.01)[0.008]; R_DKIM_PERMFAIL(0.00)[iherebuywisely.com:s=selector1]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:50304, ipnet:2a0c:5a00::/29, country:NO]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2a0c:5a00:149::26:from] X-ThisMailContainsUnwantedMimeParts: N On Fri, 22 Apr 2022 16:46:20 -0700, Pete Wright wrote: >=20 >=20 > On 4/22/22 13:39, tech-lists wrote: > > Hi, > > > > On Thu, Apr 21, 2022 at 07:16:42PM -0700, Pete Wright wrote: > >> hello - > >> > >> on my workstation running CURRENT (amd64/32g of ram) i've been running > >> into a scenario where after 4 or 5 days of daily use I get an OOM event > >> and both chromium and firefox are killed.=C2=A0 then in the next day o= r so > >> the system will become very unresponsive in the morning when i unlock = my > >> screensaver in the morning forcing a manual power cycle. > > > > I have the following set in /etc/sysctl.conf on a stable/13=20 > > workstation. Am using zfs with 32GB RAM. > > > > vm.pageout_oom_seq=3D120 > > vm.pfault_oom_attempts=3D-1 > > vm.pageout_update_period=3D0 > > > > Since setting these here, OOM is a rarity. I don't profess to exactly=20 > > know > > what they do in detail though. But my experience since these were set > > is hardly any OOM and big users of memory like firefox don't crash. >=20 > nice, i will give those a test next time i crash which will be by next=20 > thurs if the pattern continues. >=20 > looking at the sysctl descriptions: > vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM > vm.pfault_oom_attempts: Number of page allocation attempts in page fault= =20 > handler before it triggers OOM handling > vm.pageout_update_period: Maximum active LRU update period >=20 > i could certainly see how those could be helpful.=C2=A0 in an ideal world= i'd=20 > find the root cause of the system lock-ups, but it would be nice to just= =20 > move on from this :) >=20 > cheers, > -p >=20 > --=20 > Pete Wright > pete@nomadlogic.org > @nomadlogicLA I don't know if it would help this discussion, but I installed security/pic= ocrypt and memory usage started going thru the roof*. Maybe that port could be use= d to test any fix found in this thread, iow if that port runs better without /wi= th some sysctl... if could be used for the issues discussed here so far.=20=20 * and I had to desintall. FWIW I had set the three vm listed above a sh= ort while prior.=20= From nobody Sat Apr 23 17:26:18 2022 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 6EB721A86259 for ; Sat, 23 Apr 2022 17:26:28 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Klyql1S5Qz3l3g for ; Sat, 23 Apr 2022 17:26:27 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1650734779; 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=Pzw8Jhb64NUfrVnVaO26Eo0FmdOA2t5nIS/8ndWB5Y4=; b=XMG8QvaaIV+iU4LpfKpEXeqO69DD/he8JbK/i7xtUxyb6nCmbv6xgrAskmcqFY59Fcx9Dk hl64DKeFP6yFcTTBo43EMvU3nq68AVMxfJ9ElZBL1amm4r1KcRoEH7/SVLYCzvdvF9UDZf 3QH+K5Qi6U+iq6FJIJoTzRGbSOw+tXc= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 4925665a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 23 Apr 2022 17:26:18 +0000 (UTC) Message-ID: <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> Date: Sat, 23 Apr 2022 10:26:18 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Content-Language: en-US To: Mark Millard Cc: freebsd-current References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> From: Pete Wright In-Reply-To: <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Klyql1S5Qz3l3g X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=XMG8Qvaa; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-2.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.99)[-0.987]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/22/22 18:46, Mark Millard wrote: > On 2022-Apr-22, at 16:42, Pete Wright wrote: > >> On 4/21/22 21:18, Mark Millard wrote: >>> Messages in the console out would be appropriate >>> to report. Messages might also be available via >>> the following at appropriate times: >> that is what is frustrating. i will get notification that the processes are killed: >> Apr 22 09:55:15 topanga kernel: pid 76242 (chrome), jid 0, uid 1001, was killed: failed to reclaim memory >> Apr 22 09:55:19 topanga kernel: pid 76288 (chrome), jid 0, uid 1001, was killed: failed to reclaim memory >> Apr 22 09:55:20 topanga kernel: pid 76259 (firefox), jid 0, uid 1001, was killed: failed to reclaim memory >> Apr 22 09:55:22 topanga kernel: pid 76252 (firefox), jid 0, uid 1001, was killed: failed to reclaim memory >> Apr 22 09:55:23 topanga kernel: pid 76267 (firefox), jid 0, uid 1001, was killed: failed to reclaim memory >> Apr 22 09:55:24 topanga kernel: pid 76234 (chrome), jid 0, uid 1001, was killed: failed to reclaim memory >> Apr 22 09:55:26 topanga kernel: pid 76275 (firefox), jid 0, uid 1001, was killed: failed to reclaim memory > Those messages are not reporting being out of swap > as such. They are reporting sustained low free RAM > despite a number of less drastic attempts to gain > back free RAM (to above some threshold). > > FreeBSD does not swap out the kernel stacks for > processes that stay in a runnable state: it just > continues to page. Thus just one large process > that has a huge working set of active pages can > lead to OOM kills in a context were no other set > of processes would be enough to gain the free > RAM required. Such contexts are not really a > swap issue. Thank you for this clarification/explanation - that totally makes sense! > > Based on there being only 1 "killed:" reason, > I have a suggestion that should allow delaying > such kills for a long time. That in turn may > help with investigating without actually > suffering the kills during the activity: more > time with low free RAM to observe. Great idea thank-you!  and thanks for the example settings and descriptions as well. > But those are large but finite activities. If > you want to leave something running for days, > weeks, months, or whatever that produces the > sustained low free RAM conditions, the problem > will eventually happen. Ultimately one may have > to exit and restart such processes once and a > while, exiting enough of them to give a little > time with sufficient free RAM. perfect - since this is a workstation my run-time for these processes is probably a week as i update my system and pkgs over the weekend, then dog food current during the work week. >> yes i have a 2GB of swap that resides on a nvme device. > I assume a partition style. Otherwise there are other > issues involved --that likely should be avoided by > switching to partition style. so i kinda lied - initially i had just a 2G swap, but i added a second 20G swap a while ago to have enough space to capture some cores while testing drm-kmod work.  based on this comment i am going to only use the 20G file backed swap and see how that goes. this is my fstab entry currently for the file backed swap: md99 none swap sw,file=/root/swap1,late 0 0 > >>> ZFS (so with ARC)? UFS? Both? >> i am using ZFS and am setting my vfs.zfs.arc.max to 10G. i have also experienced this crash with that set to the default unlimited value as well. > I use ZFS on systems with at least 8 GiBytes of RAM, > but I've never tuned ZFS. So I'm not much help for > that side of things. since we started this thread I've gone ahead and removed the zfs.arc.max setting since its cruft at this point.  i initially added it to test a configuration i deployed to a sever hosting a bunch of VMs. > I'm hoping that vm.pageout_oom_seq=120 (or more) makes it > so you do not have to have identified everything up front > and can explore easier. > > > Note that vm.pageout_oom_seq is both a loader tunable > and a writeable runtime tunable: > > # sysctl -T vm.pageout_oom_seq > vm.pageout_oom_seq: 120 > amd64_ZFS amd64 1400053 1400053 # sysctl -W vm.pageout_oom_seq > vm.pageout_oom_seq: 120 > > So you can use it to extend the time when the > machine is already running. fantastic.  thanks again for taking your time and sharing your knowledge and experience with me Mark! these types of journeys are why i run current on my daily driver, it really helps me better understand the OS so that i can be a better admin on the "real" servers i run for work.  its also just fun to learn stuff too heh. -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Sat Apr 23 19:31:35 2022 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 9C9121A807CC for ; Sat, 23 Apr 2022 19:31:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Km1cM5236z4VqY for ; Sat, 23 Apr 2022 19:31:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650742299; bh=ctTCAgqF//+AAiw+nMkXGb8dgYHGU1dC9DaxM/IyEr4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ThQZkwjzNGD7PoXE58o9sYBVJwEXi793x26dVRpFriOvkwY5QkrFu5+7u4/6izoBmIR+y58FUQPrTT8Gf6onPWbWgxF0VtuMqHZdwEoPZYyRoB/Vcl8ev8KEXdLCJxz4grR3HSMTb2KJVuQ9yfgjvKHKMxUYZ31amJSr9tJJB5JjPiwxubUCCD5qssZvi8aK9p0Oi3HtkC2Sj7IC3JgrHhpdXsnYTiDC6JkN01U+m7qB597HIsbeteyX4TWKmK7GTSKAwuvDj1FIZ0NVaMaIHq0JX9tG+SQTdBOAYbrz4Y02Z2BGVJro/EpjGkRWiVs+3c+IcNRBJ/z0ciYGOnyslg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650742299; bh=4wV3QeTvOF4ZIH92wMuywjr6k9HKMF5I0tTDSpCpEol=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NPciqJL4ACPxA7kk4iFV3QOMo4YSY8zQhNpjUOBlY58HR3s1vMdSKJ1PJekVpOiu/bEH/ElbXvs68Y5f6kWAwDD1Bcn3VrgvEtn/36BR3P4hf+AF7yaOSoooPHAlKVHDQG3oCRjmMG0+LQ9A02jdD2yFufsM3HFADB8AekXyMEN2ZH5QWrZ9ReNEmtNF5iqQj5kNeQ1gkR9lY6zRQOPmf9ZNdWu5J09flX6f1RYbGp5414VpI8Q8WZfKRmBRXTyyHyLjlhGlWPVhMyZQr53bPQgknZOsYIs09bUF0P1aeeaCen4Q7byv+KRYvk3WOWa/iPLVOtoFUUKSt9E18VVr4w== X-YMail-OSG: WHLcV2gVM1lcVtDkEqyW_Ulmc1C.pNNJ_H90jMfnS0_6ByM5Yozy4Utst6GQLuj HMu5PSw3yrwZLHXWHRbZZWX3JVkVJhyqG0zmwP5QNvabA4MF2f77kYdFTi.0HhxjqToxUOpJv.Lc bCy_HOrbfO4PBCjs3QhT8_GR34riWz1_PZtLkqJeV2e1eFuaT1q9JVacxnnGDE9SBZBBwiYIzlTE 9ba97M1I1KGm2xl.Ec6o7xXQaJfJaLX1x3um7WYEYki77rNPxxJbfMGsRG4QntvDpFeJBs2lNYlp ds.rYNC3sVtwkAYy81a1F46p9XDhtNafwZwD6CI7uCacYZ7Ss7T.C6r.Yo7Cf4F.jGdhHtPl03FH 8P_mMklfAxFR4hINHSizkjgEY7gy1q9e9TWkP9Pto4lt26yybvDSc.F1vyLmJvKfzGrU6_hqRplK fZvdtfyHFRE7W6e0bac_.ntH6Te4VJnrKauvSrfT06dx5iXrq1wU7W_HM77P8TXuVEzrKGogfbHI cTzMV4pTKz2ukeqeLy8lhMIwaJRPZJdFw13C8hQ.n1HY1Goll.f_IYTSx427pws0dVPNsei8CRJv Q.AR_ON13dB7DQyo_pz1oyQGjS0SwtcQ8J9xRcXaFrnBZrXZEgu7i_b0eKCs6UPijoNJhvjMqodj qqI1P6YC9H.qyP71903.o299rTj62VbLMMvN.KpjrGSFMp.mVLW2I7YZJSQ4uht3Z9bj1jdTyUBz CVOERDfilxQgtkp0v1_g4XDLXwopN472piZXw8x3m_vbILGGwORwkxUeg0sd_DZnwfJDpxbmqog0 3tgrsR3o10IZCYuftPJZdDIp5GBTZpLpil2EA.xHOoZBPRfiU5of1l6Y0Yci6VqmOidSokm5nvgE lDckLJcLhza77fnC3Nw4LjdfWTdIKAv6xZxf8xJtLCxomUgJTfi.ddGYOeZYGw2VavogCZ0gV5hs G9AR4dVsEiIK7QQ2oKRVv9Q1em.yqaRlT1maxFyo9qWPJfhPvt7Y6GVpJ7qOAJ1DEQ0f9OE4U5pQ CVl8M.kZc0ay9nAtXoihJxWjfE6J9tA4kRpPos.Kmtde01D7KaKzLA2lfUFe3EtpXOuqaeBx6ZaV 8fidSHPqdE3jW7EELsQhyChAz_oy8y5F5d7_6RYl4BVNZAIQYr12N0EPgXf1p4elkYDI2cHenLHs xjEUncth1dmplEbkyxbko5TZwvI4GbDml5Mdg_laBi8MmQb7Z3odr6aCCrCyrF677jfJB2s4sly0 1McCnDW63WUE7.clFQwIRdRBl4rp9xY3RfG2oWpEZxv30OuwqDtaXAT2dTKyaN3TIikonZHVoZKG fWYqXSGrNyR1GfYYmbvo61uYzGvlZqFOb79YmpuFzuExS4ywN3dqku9bDOsJOl._1XO6lVqrREA9 Ghfz6uNNBdzhk1Hup6RCEylbnix16uvx9vpwLbBhp6fiwCUflVyVP2h6c6YwIZO4zRWQuzFdckEX rFQfbpTXIOghA4TCCndOYaD2hUL4lks_MTek5BW3xxvC3axZU8NqzN798Hac02NM6hMLygXY.bvV _7LrM9jxxZV6_Ixu5uJnIv8Q9YMUPNTnmyCpvpXFx4Q7QF4SCyN3vVL8lywSPYJC6VD.LqBjRG_8 g8kVjvBpvY4uOJEiZWVywuBsVgxsbo3y1Urm4._IioTp_zCmXlrUIihWnZiPRMBrVoTDlfXSBxSG 5._a7XYWAh7KXyeUuO2EzIhLH0F0wXFsmn7xKDs7BZ2VsB4WX_gImgVIqe5.FTxFGc_QXfXgd0Il uGaAsDZ.GQC9KlmzdYptf.MGNL39R.wv5FhikuuVSUbAgILzbdR3yAJ.KkygrrV3AUCOKr7dB208 hTcq09USPBIvY_zwEj8HR9lROHpVesSG52aPHsEgl6G3yrQKb._S5DzhWAAW13EU2ERvV4hZfqVU _ZHUy_s3Z2Kl_A6tki5qPhBAZ_501VN9eRg7mhfYO67zvJvI1hYvAupn9CR7Y2VQ9wGzkNgrhpPK j6CS7mJ3eE.GSloASFjdok79v48.qGbrvz.SwCEFimwRUvmAzTT_b1CFrcfn9gCSSRgIlbSKdU6s zYAp_TpiTNzR713rr9kSAB.LepyRHIYxTrzhLi_IZXYYCoCH6qjAjha_yOzvP.K2RebwcFQlcMDc 2sjavcNKgSCkaL9LGuNLmYvuczR2EIcoHJILDGM8pCHdAmOuWw2IqlVw.igmCj0d_ed5w9gXpfIX hR4wdPOKtLPGQy8DqXjZc4hp7ic7V0v4FG62uT2l2UEuzScomse9QN92GAH1zLEMVuPUNueVPd1F 128uf0jxz X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Apr 2022 19:31:39 +0000 Received: by hermes--canary-production-ne1-6855c48695-pbbz7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 43e328663df93d23343e95fc23d6b35c; Sat, 23 Apr 2022 19:31:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? From: Mark Millard In-Reply-To: <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> Date: Sat, 23 Apr 2022 12:31:35 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> To: Pete Wright X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Km1cM5236z4VqY X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ThQZkwjz; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [1.86 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.64)[-0.643]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-23, at 10:26, Pete Wright wrote: > On 4/22/22 18:46, Mark Millard wrote: >> On 2022-Apr-22, at 16:42, Pete Wright wrote: >>=20 >>> On 4/21/22 21:18, Mark Millard wrote: >>>> Messages in the console out would be appropriate >>>> to report. Messages might also be available via >>>> the following at appropriate times: >>> that is what is frustrating. i will get notification that the = processes are killed: >>> Apr 22 09:55:15 topanga kernel: pid 76242 (chrome), jid 0, uid 1001, = was killed: failed to reclaim memory >>> Apr 22 09:55:19 topanga kernel: pid 76288 (chrome), jid 0, uid 1001, = was killed: failed to reclaim memory >>> Apr 22 09:55:20 topanga kernel: pid 76259 (firefox), jid 0, uid = 1001, was killed: failed to reclaim memory >>> Apr 22 09:55:22 topanga kernel: pid 76252 (firefox), jid 0, uid = 1001, was killed: failed to reclaim memory >>> Apr 22 09:55:23 topanga kernel: pid 76267 (firefox), jid 0, uid = 1001, was killed: failed to reclaim memory >>> Apr 22 09:55:24 topanga kernel: pid 76234 (chrome), jid 0, uid 1001, = was killed: failed to reclaim memory >>> Apr 22 09:55:26 topanga kernel: pid 76275 (firefox), jid 0, uid = 1001, was killed: failed to reclaim memory >> Those messages are not reporting being out of swap >> as such. They are reporting sustained low free RAM >> despite a number of less drastic attempts to gain >> back free RAM (to above some threshold). >>=20 >> FreeBSD does not swap out the kernel stacks for >> processes that stay in a runnable state: it just >> continues to page. Thus just one large process >> that has a huge working set of active pages can >> lead to OOM kills in a context were no other set >> of processes would be enough to gain the free >> RAM required. Such contexts are not really a >> swap issue. >=20 > Thank you for this clarification/explanation - that totally makes = sense! >=20 >>=20 >> Based on there being only 1 "killed:" reason, >> I have a suggestion that should allow delaying >> such kills for a long time. That in turn may >> help with investigating without actually >> suffering the kills during the activity: more >> time with low free RAM to observe. >=20 > Great idea thank-you! and thanks for the example settings and = descriptions as well. >> But those are large but finite activities. If >> you want to leave something running for days, >> weeks, months, or whatever that produces the >> sustained low free RAM conditions, the problem >> will eventually happen. Ultimately one may have >> to exit and restart such processes once and a >> while, exiting enough of them to give a little >> time with sufficient free RAM. > perfect - since this is a workstation my run-time for these processes = is probably a week as i update my system and pkgs over the weekend, then = dog food current during the work week. >=20 >>> yes i have a 2GB of swap that resides on a nvme device. >> I assume a partition style. Otherwise there are other >> issues involved --that likely should be avoided by >> switching to partition style. >=20 > so i kinda lied - initially i had just a 2G swap, but i added a second = 20G swap a while ago to have enough space to capture some cores while = testing drm-kmod work. based on this comment i am going to only use the = 20G file backed swap and see how that goes. >=20 > this is my fstab entry currently for the file backed swap: > md99 none swap sw,file=3D/root/swap1,late 0 0 I think you may have taken my suggestion backwards . . . Unfortunately, vnode (file) based swap space should be *avoided* and partitions are what should be used in order to avoid deadlocks: On 2017-Feb-13, at 7:20 PM, Konstantin Belousov = wrote on the freebsd-arm list: QUOTE 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 The developers handbook has a section debugging deadlocks that he referenced in a response to another report (on freebsd-hackers). = https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneld= ebug-deadlocks >>>> ZFS (so with ARC)? UFS? Both? >>> i am using ZFS and am setting my vfs.zfs.arc.max to 10G. i have = also experienced this crash with that set to the default unlimited value = as well. >> I use ZFS on systems with at least 8 GiBytes of RAM, >> but I've never tuned ZFS. So I'm not much help for >> that side of things. >=20 > since we started this thread I've gone ahead and removed the = zfs.arc.max setting since its cruft at this point. i initially added it = to test a configuration i deployed to a sever hosting a bunch of VMs. >=20 >> I'm hoping that vm.pageout_oom_seq=3D120 (or more) makes it >> so you do not have to have identified everything up front >> and can explore easier. >>=20 >>=20 >> Note that vm.pageout_oom_seq is both a loader tunable >> and a writeable runtime tunable: >>=20 >> # sysctl -T vm.pageout_oom_seq >> vm.pageout_oom_seq: 120 >> amd64_ZFS amd64 1400053 1400053 # sysctl -W vm.pageout_oom_seq >> vm.pageout_oom_seq: 120 >>=20 >> So you can use it to extend the time when the >> machine is already running. >=20 > fantastic. thanks again for taking your time and sharing your = knowledge and experience with me Mark! >=20 > these types of journeys are why i run current on my daily driver, it = really helps me better understand the OS so that i can be a better admin = on the "real" servers i run for work. its also just fun to learn stuff = too heh. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Apr 24 02:20:24 2022 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 525211A8D400 for ; Sun, 24 Apr 2022 02:20:28 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KmBgv0frMz4SHm for ; Sun, 24 Apr 2022 02:20:26 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1650766825; 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=jGAVRTGHNxdcgz/Ap3DoI93lQ98RnrvgbXrlvyAKDwg=; b=eVWElq2Wh0xWitEMz1/AZeHr4wElovOt0K4XYSbORZCZmc16ADjWwkEUIJjZD4pm2PtdIS CBr2yofD9D2hwr5zP6CB6ZcaxyBEZzynYGy34mgIalLJFwk9iFqodELHfp/47yQzZ36Sn8 82SMhFA8eKaWh8HwJ9yYu2x8n3kpLeQ= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id b2e45472 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 24 Apr 2022 02:20:24 +0000 (UTC) Message-ID: Date: Sat, 23 Apr 2022 19:20:24 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Content-Language: en-US To: Mark Millard Cc: freebsd-current References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> From: Pete Wright In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KmBgv0frMz4SHm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=eVWElq2W; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-2.97 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; NEURAL_HAM_SHORT(-0.97)[-0.969]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/23/22 12:31, Mark Millard wrote: > I think you may have taken my suggestion backwards . . . > > Unfortunately, vnode (file) based swap space should be *avoided* > and partitions are what should be used in order to avoid deadlocks: > > On 2017-Feb-13, at 7:20 PM, Konstantin Belousov wrote > on the freebsd-arm list: > > QUOTE > 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 > > The developers handbook has a section debugging deadlocks that he > referenced in a response to another report (on freebsd-hackers). > > https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneldebug-deadlocks d'oh - thanks for the correction! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Sun Apr 24 02:43:21 2022 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 49530199306B for ; Sun, 24 Apr 2022 02:43:39 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msc14.plala.or.jp (msc14.plala.or.jp [60.36.166.24]) by mx1.freebsd.org (Postfix) with ESMTP id 4KmCBd02c9z4XCH for ; Sun, 24 Apr 2022 02:43:36 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from localhost ([2400:4050:9320:7a00::8]) by msc14.plala.or.jp with ESMTP id <20220424024328.XASG9370.msc14.plala.or.jp@localhost> for ; Sun, 24 Apr 2022 11:43:28 +0900 Date: Sun, 24 Apr 2022 11:43:21 +0900 (JST) Message-Id: <20220424.114321.363863903991217889.ish@amail.plala.or.jp> To: freebsd-current@freebsd.org Subject: How can I suppress ACPI Warning messages ? From: Masachika ISHIZUKA X-Mailer: Mew version 6.8 on Emacs 28.1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-VirusScan: Outbound; mvir-ac14; Sun, 24 Apr 2022 11:43:28 +0900 X-Rspamd-Queue-Id: 4KmCBd02c9z4XCH X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ish@amail.plala.or.jp designates 60.36.166.24 as permitted sender) smtp.mailfrom=ish@amail.plala.or.jp X-Spamd-Result: default: False [1.16 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[plala.or.jp]; R_SPF_ALLOW(-0.20)[+ip4:60.36.166.0/24]; MID_CONTAINS_FROM(1.00)[]; NEURAL_SPAM_SHORT(0.96)[0.955]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4713, ipnet:60.32.0.0/12, country:JP]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_LOW(-0.10)[60.36.166.24:from] X-ThisMailContainsUnwantedMimeParts: N I'm using 14.0-current on old DELL xps12 notebook. Xconsole on it is fillfulled the 'ACPI Warning: Firmware issue: Excessive sleep time (0x0000000000000014 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347)' messages and I'm failling to see other important messages. How can I suppress this ACPI warning messages ? -- Masachika ISHIZUKA From nobody Sun Apr 24 04:06:06 2022 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 52CDD1A831EC for ; Sun, 24 Apr 2022 04:06:19 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from us-smtp-delivery-197.mimecast.com (us-smtp-delivery-197.mimecast.com [170.10.129.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mimecast.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KmF214QW2z4j4j for ; Sun, 24 Apr 2022 04:06:17 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from MAIL-HUB.pai.local (175.158.26.216.gopai.com [216.26.158.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id us-mta-539-O6xxo7K1PHe8xxDpiWWc_Q-1; Sun, 24 Apr 2022 00:06:08 -0400 X-MC-Unique: O6xxo7K1PHe8xxDpiWWc_Q-1 Received: from MAIL-HUB.pai.local (10.10.0.250) by MAIL-HUB.pai.local (10.10.0.250) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Sun, 24 Apr 2022 00:06:06 -0400 Received: from MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8]) by MAIL-HUB.pai.local ([fe80::a02e:93c2:c16a:6af8%15]) with mapi id 15.00.1497.033; Sun, 24 Apr 2022 00:06:06 -0400 From: Michael Jung To: Mark Millard , Pete Wright CC: freebsd-current Subject: RE: Chasing OOM Issues - good sysctl metrics to use? Thread-Topic: Chasing OOM Issues - good sysctl metrics to use? Thread-Index: AQHYVgAJle9Kg2SVvUGAz910OVPYq6z83F8AgAAitgCAAQZ0AIAAIwGAgAAtWBA= Date: Sun, 24 Apr 2022 04:06:06 +0000 Message-ID: References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.0.59] x-c2processedorg: 474f336e-f930-49ec-9717-e3226b5b6e6e 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-Mimecast-Spam-Score: 0 X-Mimecast-Originator: paymentallianceintl.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_e2322e858bfb4f1caadaafedfb3ec6a7MAILHUBpailocal_" X-Rspamd-Queue-Id: 4KmF214QW2z4j4j X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=paymentallianceintl.com; spf=pass (mx1.freebsd.org: domain of mikej@paymentallianceintl.com designates 170.10.129.197 as permitted sender) smtp.mailfrom=mikej@paymentallianceintl.com X-Spamd-Result: default: False [-2.88 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:170.10.129.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.985]; DMARC_POLICY_ALLOW(-0.50)[paymentallianceintl.com,none]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[yahoo.com,nomadlogic.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:30031, ipnet:170.10.128.0/23, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[170.10.129.197:from] X-ThisMailContainsUnwantedMimeParts: N --_000_e2322e858bfb4f1caadaafedfb3ec6a7MAILHUBpailocal_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi: I guess I'm kind of high jacking this thread but I think what I'm going to ask is close enough to the topic at hand to ask instead of starting a new thread and referencing this one. I use sysutils/monit to what running processes and then restart them I as I want. I use protect(1) to make sure that monit would not dies. In /etc/rc.local "protect -i monit" protect seems in the end simply call PROC_SPROTECT with the INHERIT flag and as documented in procctl(2) So I followed a bit of code I guess that cools if I got it right but I know about .0001% about system internals. Can anyone speak to how protect(1) works and is it in itself is prone to wh= at has been discussed? For my use case is protect "good enough" or do I really need to tuning like= has been talked about? If protect is the right answer and someone could explain how it does Its thing at a slighter higher technical barrier I would love to hear more about why I'm either doing it wrong, that that what I'm doing it ok, o= r why I should really be doing something completely different and the why I should be doing it differently. I suspect there are many that would like to know this but would never ask, at least not on list. Always the seeker of new knowledge. Thanks in advance. --mikej CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4000 or notify us at: PAI, Dept. 99, 2101 High Wickham Place, Suite 101, Louisville, KY 40245 From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freeb= sd.org] On Behalf Of Mark Millard Sent: Saturday, April 23, 2022 3:32 PM To: Pete Wright Cc: freebsd-current Subject: Re: Chasing OOM Issues - good sysctl metrics to use? On 2022-Apr-23, at 10:26, Pete Wright > wrote: > On 4/22/22 18:46, Mark Millard wrote: >> On 2022-Apr-22, at 16:42, Pete Wright > wrote: >> >>> On 4/21/22 21:18, Mark Millard wrote: >>>> Messages in the console out would be appropriate >>>> to report. Messages might also be available via >>>> the following at appropriate times: >>> that is what is frustrating. i will get notification that the processes= are killed: >>> Apr 22 09:55:15 topanga kernel: pid 76242 (chrome), jid 0, uid 1001, wa= s killed: failed to reclaim memory >>> Apr 22 09:55:19 topanga kernel: pid 76288 (chrome), jid 0, uid 1001, wa= s killed: failed to reclaim memory >>> Apr 22 09:55:20 topanga kernel: pid 76259 (firefox), jid 0, uid 1001, w= as killed: failed to reclaim memory >>> Apr 22 09:55:22 topanga kernel: pid 76252 (firefox), jid 0, uid 1001, w= as killed: failed to reclaim memory >>> Apr 22 09:55:23 topanga kernel: pid 76267 (firefox), jid 0, uid 1001, w= as killed: failed to reclaim memory >>> Apr 22 09:55:24 topanga kernel: pid 76234 (chrome), jid 0, uid 1001, wa= s killed: failed to reclaim memory >>> Apr 22 09:55:26 topanga kernel: pid 76275 (firefox), jid 0, uid 1001, w= as killed: failed to reclaim memory >> Those messages are not reporting being out of swap >> as such. They are reporting sustained low free RAM >> despite a number of less drastic attempts to gain >> back free RAM (to above some threshold). >> >> FreeBSD does not swap out the kernel stacks for >> processes that stay in a runnable state: it just >> continues to page. Thus just one large process >> that has a huge working set of active pages can >> lead to OOM kills in a context were no other set >> of processes would be enough to gain the free >> RAM required. Such contexts are not really a >> swap issue. > > Thank you for this clarification/explanation - that totally makes sense! > >> >> Based on there being only 1 "killed:" reason, >> I have a suggestion that should allow delaying >> such kills for a long time. That in turn may >> help with investigating without actually >> suffering the kills during the activity: more >> time with low free RAM to observe. > > Great idea thank-you! and thanks for the example settings and description= s as well. >> But those are large but finite activities. If >> you want to leave something running for days, >> weeks, months, or whatever that produces the >> sustained low free RAM conditions, the problem >> will eventually happen. Ultimately one may have >> to exit and restart such processes once and a >> while, exiting enough of them to give a little >> time with sufficient free RAM. > perfect - since this is a workstation my run-time for these processes is = probably a week as i update my system and pkgs over the weekend, then dog f= ood current during the work week. > >>> yes i have a 2GB of swap that resides on a nvme device. >> I assume a partition style. Otherwise there are other >> issues involved --that likely should be avoided by >> switching to partition style. > > so i kinda lied - initially i had just a 2G swap, but i added a second 20= G swap a while ago to have enough space to capture some cores while testing= drm-kmod work. based on this comment i am going to only use the 20G file b= acked swap and see how that goes. > > this is my fstab entry currently for the file backed swap: > md99 none swap sw,file=3D/root/swap1,late 0 0 I think you may have taken my suggestion backwards . . . Unfortunately, vnode (file) based swap space should be *avoided* and partitions are what should be used in order to avoid deadlocks: On 2017-Feb-13, at 7:20 PM, Konstantin Belousov wr= ote on the freebsd-arm list: QUOTE 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 The developers handbook has a section debugging deadlocks that he referenced in a response to another report (on freebsd-hackers). https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kernelde= bug-deadlocks >>>> ZFS (so with ARC)? UFS? Both? >>> i am using ZFS and am setting my vfs.zfs.arc.max to 10G. i have also ex= perienced this crash with that set to the default unlimited value as well. >> I use ZFS on systems with at least 8 GiBytes of RAM, >> but I've never tuned ZFS. So I'm not much help for >> that side of things. > > since we started this thread I've gone ahead and removed the zfs.arc.max = setting since its cruft at this point. i initially added it to test a confi= guration i deployed to a sever hosting a bunch of VMs. > >> I'm hoping that vm.pageout_oom_seq=3D120 (or more) makes it >> so you do not have to have identified everything up front >> and can explore easier. >> >> >> Note that vm.pageout_oom_seq is both a loader tunable >> and a writeable runtime tunable: >> >> # sysctl -T vm.pageout_oom_seq >> vm.pageout_oom_seq: 120 >> amd64_ZFS amd64 1400053 1400053 # sysctl -W vm.pageout_oom_seq >> vm.pageout_oom_seq: 120 >> >> So you can use it to extend the time when the >> machine is already running. > > fantastic. thanks again for taking your time and sharing your knowledge a= nd experience with me Mark! > > these types of journeys are why i run current on my daily driver, it real= ly helps me better understand the OS so that i can be a better admin on the= "real" servers i run for work. its also just fun to learn stuff too heh. > =3D=3D=3D Mark Millard marklmi at yahoo.com Disclaimer The information contained in this communication from the sender is confiden= tial. It is intended solely for use by the recipient and others authorized = to receive it. If you are not the recipient, you are hereby notified that a= ny disclosure, copying, distribution or taking action in relation of the co= ntents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been auto= matically archived by Mimecast, a leader in email security and cyber resili= ence. Mimecast integrates email defenses with brand protection, security aw= areness training, web security, compliance and other essential capabilities= . Mimecast helps protect large and small organizations from malicious activ= ity, human error and technology failure; and to lead the movement toward bu= ilding a more resilient world. To find out more, visit our website. --_000_e2322e858bfb4f1caadaafedfb3ec6a7MAILHUBpailocal_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <= /head>

Hi:

 

I guess I’m kind of high jacking this thread but I t= hink what I’m

going to ask is close enough to the topic at hand to ask i= nstead

of starting a new thread and referencing this one.

 

I use sysutils/monit to what running processes and then re= start them

I as I want.

 

I use  protect(1) to make sure that monit would not d= ies.

 

In /etc/rc.local “protect –i monit”=

 

protect seems in the end simply call

 

     PROC_SPROTECT with the INHERIT fl= ag and as documented in procctl(2)

 

So I followed a bit of code I guess that cools if I got it= right but I know

about .0001% about system internals.

 

Can anyone speak to how protect(1) works and is it in itse= lf is prone to what has been discussed?

 

For my use case is protect “good enough” or do= I really need to tuning like has been talked about?

 

If protect is the right answer and someone could explain h= ow it does

Its thing at a slighter higher technical barrier I would l= ove to hear

more about why I’m either doing it wrong, that that = what I’m doing it ok, or

why I should really be doing something completely differen= t and the why I

should be doing it differently.

 

I suspect there are many that would like to know this but = would never ask,

at least not on list.

 

Always the seeker of new knowledge.

 

Thanks in advance.

 

--mikej

 

 

 

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245



From: owner-freebsd-current@freebsd.= org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Mark Millard
Sent: Saturday, April 23, 2022 3:32 PM
To: Pete Wright <pete@nomadlogic.org>
Cc: freebsd-current <freebsd-current@freebsd.org>
Subject: Re: Chasing OOM Issues - good sysctl metrics to use?

 

On 2022-Apr-23, at 10= :26, Pete Wright <pete@nomadlogic= .org> wrote:

> On 4/22/22 18:46, Mark Millard wrote:
>> On 2022-Apr-22, at 16:42, Pete Wright <pete@nomadlogic.org> wrote:
>>
>>> On 4/21/22 21:18, Mark Millard wrote:
>>>> Messages in the console out would be appropriate
>>>> to report. Messages might also be available via
>>>> the following at appropriate times:
>>> that is what is frustrating. i will get notification that the = processes are killed:
>>> Apr 22 09:55:15 topanga kernel: pid 76242 (chrome), jid 0, uid= 1001, was killed: failed to reclaim memory
>>> Apr 22 09:55:19 topanga kernel: pid 76288 (chrome), jid 0, uid= 1001, was killed: failed to reclaim memory
>>> Apr 22 09:55:20 topanga kernel: pid 76259 (firefox), jid 0, ui= d 1001, was killed: failed to reclaim memory
>>> Apr 22 09:55:22 topanga kernel: pid 76252 (firefox), jid 0, ui= d 1001, was killed: failed to reclaim memory
>>> Apr 22 09:55:23 topanga kernel: pid 76267 (firefox), jid 0, ui= d 1001, was killed: failed to reclaim memory
>>> Apr 22 09:55:24 topanga kernel: pid 76234 (chrome), jid 0, uid= 1001, was killed: failed to reclaim memory
>>> Apr 22 09:55:26 topanga kernel: pid 76275 (firefox), jid 0, ui= d 1001, was killed: failed to reclaim memory
>> Those messages are not reporting being out of swap
>> as such. They are reporting sustained low free RAM
>> despite a number of less drastic attempts to gain
>> back free RAM (to above some threshold).
>>
>> FreeBSD does not swap out the kernel stacks for
>> processes that stay in a runnable state: it just
>> continues to page. Thus just one large process
>> that has a huge working set of active pages can
>> lead to OOM kills in a context were no other set
>> of processes would be enough to gain the free
>> RAM required. Such contexts are not really a
>> swap issue.
>
> Thank you for this clarification/explanation - that totally makes sens= e!
>
>>
>> Based on there being only 1 "killed:" reason,
>> I have a suggestion that should allow delaying
>> such kills for a long time. That in turn may
>> help with investigating without actually
>> suffering the kills during the activity: more
>> time with low free RAM to observe.
>
> Great idea thank-you! and thanks for the example settings and descript= ions as well.
>> But those are large but finite activities. If
>> you want to leave something running for days,
>> weeks, months, or whatever that produces the
>> sustained low free RAM conditions, the problem
>> will eventually happen. Ultimately one may have
>> to exit and restart such processes once and a
>> while, exiting enough of them to give a little
>> time with sufficient free RAM.
> perfect - since this is a workstation my run-time for these processes = is probably a week as i update my system and pkgs over the weekend, then do= g food current during the work week.
>
>>> yes i have a 2GB of swap that resides on a nvme device.
>> I assume a partition style. Otherwise there are other
>> issues involved --that likely should be avoided by
>> switching to partition style.
>
> so i kinda lied - initially i had just a 2G swap, but i added a second= 20G swap a while ago to have enough space to capture some cores while test= ing drm-kmod work. based on this comment i am going to only use the 20G fil= e backed swap and see how that goes.
>
> this is my fstab entry currently for the file backed swap:
> md99 none swap sw,file=3D/root/swap1,late 0 0

I think you may have taken my suggestion backwards . . .

Unfortunately, vnode (file) based swap space should be *avoided*
and partitions are what should be used in order to avoid deadlocks:

On 2017-Feb-13, at 7:20 PM, Konstantin Belousov <kostikbel at gmail.com&= gt; wrote
on the freebsd-arm list:

QUOTE
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

The developers handbook has a section debugging deadlocks that he
referenced in a response to another report (on freebsd-hackers).

https://docs.freebsd.org/en/books/developers-hand= book/kerneldebug/#kerneldebug-deadlocks

>>>> ZFS (so with ARC)? UFS? Both?
>>> i am using ZFS and am setting my vfs.zfs.arc.max to 10G. i hav= e also experienced this crash with that set to the default unlimited value = as well.
>> I use ZFS on systems with at least 8 GiBytes of RAM,
>> but I've never tuned ZFS. So I'm not much help for
>> that side of things.
>
> since we started this thread I've gone ahead and removed the zfs.arc.m= ax setting since its cruft at this point. i initially added it to test a co= nfiguration i deployed to a sever hosting a bunch of VMs.
>
>> I'm hoping that vm.pageout_oom_seq=3D120 (or more) makes it
>> so you do not have to have identified everything up front
>> and can explore easier.
>>
>>
>> Note that vm.pageout_oom_seq is both a loader tunable
>> and a writeable runtime tunable:
>>
>> # sysctl -T vm.pageout_oom_seq
>> vm.pageout_oom_seq: 120
>> amd64_ZFS amd64 1400053 1400053 # sysctl -W vm.pageout_oom_seq
>> vm.pageout_oom_seq: 120
>>
>> So you can use it to extend the time when the
>> machine is already running.
>
> fantastic. thanks again for taking your time and sharing your knowledg= e and experience with me Mark!
>
> these types of journeys are why i run current on my daily driver, it r= eally helps me better understand the OS so that i can be a better admin on = the "real" servers i run for work. its also just fun to learn stu= ff too heh.
>


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



<= b>Disclaimer

The information contained in this communication from the sender i= s confidential. It is intended solely for use by the recipient and others a= uthorized to receive it. If you are not the recipient, you are hereby notif= ied that any disclosure, copying, distribution or taking action in relation= of the contents of this information is strictly prohibited and may be unla= wful.

This email has been scanned for viruses and malware, and may h= ave been automatically archived by Mimecast, a leader in email security and= cyber resilience. Mimecast integrates email defenses with brand protection= , security awareness training, web security, compliance and other essential= capabilities. Mimecast helps protect large and small organizations from ma= licious activity, human error and technology failure; and to lead the movem= ent toward building a more resilient world. To find out more, visit our web= site.

--_000_e2322e858bfb4f1caadaafedfb3ec6a7MAILHUBpailocal_-- From nobody Sun Apr 24 07:49:48 2022 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 146C01A89433 for ; Sun, 24 Apr 2022 07:50:00 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail-out.smeets.xyz (mail-out.smeets.xyz [IPv6:2a01:4f8:10a:3543:ffff:0:25:11]) (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 4KmL063Lptz3NnK; Sun, 24 Apr 2022 07:49:58 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail.smeets.xyz (mail.smeets.xyz [IPv6:2a01:4f8:10a:3543::25:3]) (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) (Client did not present a certificate) by mail-out.smeets.xyz (Postfix) with ESMTPS id 8C3E796298; Sun, 24 Apr 2022 09:49:50 +0200 (CEST) Received: from amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) by mail.smeets.xyz (Postfix) with ESMTP id 79D41B05A4; Sun, 24 Apr 2022 09:49:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at smeets.xyz Received: from mail.smeets.xyz ([IPv6:2a01:4f8:10a:3543::25:3]) by amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) (amavisd-new, port 10025) with ESMTP id aZ37Vi_7o1pq; Sun, 24 Apr 2022 09:49:50 +0200 (CEST) Received: from [IPV6:2003:cf:df49:c97:28c7:2fab:293:a393] (p2003000631376c9728c72fab0293a393.dip0.t-ipconnect.de [IPv6:2003:6:3137:6c97:28c7:2fab:293:a393]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail.smeets.xyz (Postfix) with ESMTPSA id 0FFB8B0593; Sun, 24 Apr 2022 09:49:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smeets.xyz; s=dkim; t=1650786590; 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=664GonA2lj0NZBoV+GxR4vSUI3hho21r5HrsmDSV5CY=; b=FFcUQmjAJiMd6gXPRbWabPNJpBcg8IxvrE/L6G8IvcVkYR9II/xNSaGS6AoaVaZEJiNyXy /LcPHAso60DmWrgxsjZmq9KD+tpg1MHZfLzCSAAdyfqbKzBTuvG20w6ZUhBQy89sRbOi59 su+mRZdzg4MmKAxIHc1YkOBCMOG5CGVrVQI53opw4/M+UMFudvdUKse4nq07ae1urfJN9a 8w1PDgjpWTzlS7nxMWY8dwi2Rt/rpD0G8Zbf0nJRm0o7Igxggge71bsuZN5yV8vXfaORCd sZxQckeWLNm/74qDLTfdCZwzSpTupEU12cJBwFOPdUoY01p96vPi4iCbzcAzzQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=smeets.xyz; s=ed25519_2022; t=1650786590; 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=664GonA2lj0NZBoV+GxR4vSUI3hho21r5HrsmDSV5CY=; b=8joo0S2BsRz9rXBEKeav+sJrDi8O1ljpMfNQkdXwndtqFU8sIYjfwAhKqyWoyC6DtkhHiO 0hJrY32zoDv4oMAQ== Message-ID: <49214a89-28e6-acbb-b10d-38bf2685b78b@smeets.xyz> Date: Sun, 24 Apr 2022 09:49:48 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Gleb Smirnoff Cc: Michael Butler , freebsd-current@freebsd.org References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> From: Florian Smeets Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------nf0fELrRoa02cUZdSDq0S70c" X-Rspamd-Queue-Id: 4KmL063Lptz3NnK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smeets.xyz header.s=dkim header.b=FFcUQmjA; dkim=pass header.d=smeets.xyz header.s=ed25519_2022 header.b=8joo0S2B; dmarc=pass (policy=reject) header.from=smeets.xyz; spf=pass (mx1.freebsd.org: domain of flo@smeets.xyz designates 2a01:4f8:10a:3543:ffff:0:25:11 as permitted sender) smtp.mailfrom=flo@smeets.xyz X-Spamd-Result: default: False [-4.71 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[smeets.xyz:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[smeets.xyz,reject]; NEURAL_HAM_SHORT(-0.87)[-0.866]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.946]; RCVD_COUNT_FIVE(0.00)[5]; FREEFALL_USER(0.00)[flo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[smeets.xyz:s=dkim,smeets.xyz:s=ed25519_2022]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------nf0fELrRoa02cUZdSDq0S70c Content-Type: multipart/mixed; boundary="------------ZeVbcLtkeujlgHF9O0iUKTSJ"; protected-headers="v1" From: Florian Smeets To: Gleb Smirnoff Cc: Michael Butler , freebsd-current@freebsd.org Message-ID: <49214a89-28e6-acbb-b10d-38bf2685b78b@smeets.xyz> Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> In-Reply-To: --------------ZeVbcLtkeujlgHF9O0iUKTSJ Content-Type: multipart/mixed; boundary="------------tRu2yROQG0VZG223JDp8ZVia" --------------tRu2yROQG0VZG223JDp8ZVia Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjMuMDQuMjIgMDE6MzgsIEdsZWIgU21pcm5vZmYgd3JvdGU6DQo+ICAgIEhpIEZsb3Jp YW4sDQo+IA0KPiBoZXJlIGlzIGEgcGF0Y2ggdGhhdCBzaG91bGQgaGVscCB3aXRoIHRoZSBJ UHY2IHByb2JsZW0uIEknbSBub3QNCj4geWV0IGNvbW1pdHRpbmcgaXQsIGl0IG1pZ2h0IGJl IG5vdCBmaW5hbC4NCj4gDQoNCkhpIEdsZWIsDQoNCnllcywgdGhlIHBhdGNoIHJlc29sdmVz IHRoZSBpc3N1ZS4gVGhlcmUgaXMganVzdCBvbmUgU1lOIHBhY2tldCwgYW5kIGl0IA0KZ2V0 cyBhIHJlcGx5IGltbWVkaWF0ZWx5Lg0KDQpUaGFua3MsDQpGbG9yaWFuDQo= --------------tRu2yROQG0VZG223JDp8ZVia Content-Type: application/pgp-keys; name="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Disposition: attachment; filename="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFpyBwsBEADLq0c46orEtbMn4SptX+VJxR1wB4YwaErZme1bqF4nZHIhlRNE T22HsHdQdoagaB4uACq0Rj5kHcu614ZnnNkLPyCxWQATx+cbdiFO4/hfT8tAvKnB tiy3awKJ5uGCNO2EzJwXW6KwdDA8XPRySqN8m1yPl+dW0Cls+/vO/QL/6+YLMupm EpSvFxRzAZTQuKyX4+xl+dYId24JiPd1yfCuDNOY3+OZ3QBMT00u/699N8lUWRti TwaQMwAOww8r/26YM6/SgcgFuLH2E/CVplY0sDvfoISlAj8agxdomNXfPjCMQ6w5 yGZmA+huFpPCVBTi3on/SWgbQO7dLVpN4BNPuScPosCb/dsOg0S74zCClsIU3gdU Gh9rwJY00/Ebid6V0R3c1Czwbg8LQedzlGDuXYXmzp6W2ujgr1cqbUD6lUWikUv2 IMdCbb8MxYhHLi3GYUs5Xpi+W7vM6T45KbuMr7O/1SjtcGOlNeDvGNgjcDk20fOg PPZ+M6i9vX5Q2oI9HoYaeTiYNwILkBLVP/L40kTo5EkiQOt4OW6BMbylqXPOaQMW uGVbmhCJQpbx8Vo80s2yiBBVWkLkWQIcIm3KZlLldJqKEFpQBWLBE1eFFqboYgAW zFn73CaV5tihobijMmmOV3a8cI1fI4kREyl3g+8bW+O0u3m3tuzVOpDpjwARAQAB zSBGbG9yaWFuIFNtZWV0cyA8ZmxvQEZyZWVCU0Qub3JnPsLBlAQTAQoAPhYhBOyz aLh5CL+2kU1yae9bpNzVqfPABQJh8E3MAhsDBQkLM37BBQsJCAcDBRUKCQgLBRYD AgEAAh4BAheAAAoJEO9bpNzVqfPAOjQP/1FdgHTug7m1OGP3kz5xOID6cuSDUZ1Q eFNvGOU/g0qty1Bda9/dcRJjOdbtIkpPXPUbOZiZWFLABBo82lxufjso1uzwlvCZ q/qMYMtpTys8LZUVOrbVeUM8KKLHtLq2DL49Et8DqwENcxaPa604RExsfvrBAMwO WF6kH8DC4cbCi+2B335NUCFoM/qYC3Ph0bCrWu0lsiEd0G3WJ8Wz8OiEgD+muoQt aEMKkg6B97TaCvcLf25j6VO0bTiySM3e1RwNPaTyu9GSh5L7PThPE67HuA27NXoh +oHDVbdM475OGIQ8IAWvuPyEJ6R91IjpQFR3qiyWeppR1Ag5XoB1DpQv8fKu2bQz m7lQWC07djntw+ScxcDxiuj7+PL1ClKKjezTSmvjJEA6G3wB17MtSnI8TMVnPR1N GsShTY5Fl5ihyQw1wg2eJLXJg0rYLubhPhJiyoiGOIk1BR340Aben1qDC33V9Qo5 CKFlXizvFygdy3h/aIJeq9m2uQvQpPkMM4Ije2tmvlK+Q3HJki0OnbeGf4vJa/dB VdnjAp7idYaVyKhV4D3daH1zOTWwxLrSHOv5ixpR+ZCmG6nmApEKE2q5lm/bx5ZA XP9SSwyLdV22PUbuiNGZ5eJx/9lhuX16nVZ3F2xJZnJuqQV7kWxAedxwaN5P5U8K TPFPgLRAD9U0zR9GbG9yaWFuIFNtZWV0cyA8ZmxvQHNtZWV0cy54eXo+wsGXBBMB CgBBAhsDBQkLM37BBQsJCAcDBRUKCQgLBRYDAgEAAh4BAheAFiEE7LNouHkIv7aR TXJp71uk3NWp88AFAmHwTcwCGQEACgkQ71uk3NWp88BpTRAAybyHhteWLV4VDlzl 7NPxbN8c9cDDv1r0HlaUVxfrSw+1rzycEdhqA8o75Wh5II4KAFTbX2igGckskcoO dqm68MU8+zAtVxVZaqX+EGNXSLWZgAzlf9rAHDm/O1ZBShZhn9EJyarYPaSRNBev VaR9bY6LEFmDacb6qnRVOH4Z/6O6fq/IxoXQqyV1NDmmObxtCcxwx71v+7mJoBMT ximtdrPmcpGesCQquiWKa6DyYjZIEZ9gQPttLQ+iYmwWJp6q68VULqY9X0zG7byc 3Xe7W/5oEoTA/gSWG0EbPOdfTS77TTNxhgBzFB6VY81PVAYzH419Q0b055XLTupo +JTQUb6bbluH6UJIBtIp1iJlGN42qvkMwqTogIdat/3aA+EWEfG7iWlx8Z1hFU3r 7GMJ5o8QLsloVNWAda+iHaidIJvU1fJa0U9v2r1d/KwYHj2qlMaQMZHjldULp7LP P/pITeQEnma3mZ6IX7cp6mUd8MOiVTPE42fPs8qBHKfuEcg7L07NcdRzzgS0LGQf v6fbnvNnvsDGAt4zGQ/Hj72Z5/eL1sDnoJQUHNHMJlNJieGplbLm3LacNQZa9979 BjwK+mUr1nPaaP4YR3czfVwTMrxPKT9kFBDZL4YQ8LbsH5JJC3As3EJdptIkANSm +hU54sG8QPz6TDsm7754d1n12M3CwXkEEwEKACMWIQSnAQMgO8q0Spj+yETnBT35 /4bwdgUCWnIHOAWDB4YfgAAKCRDnBT35/4bwdmNtEACU20uv5Lvuit3DtzQ5m4eP HAQzdeg6Uqpm7nNHB0KKGPCtKmf55bDVHfVuKS1pu1jBXFxGKyEKY5+QaxVrt9Dl iDqfqEPDmIqDdG13ch0cV3lan+3Jli3M2OwsHNac72MPFp++eAUbA9wgn6y6GlJx 9/oCtDuY9FucpL/P8zMbH5f00qBEKsC+lq8u+ZY/7lPYdVaZl3doLZcGCCsgbLP/ ytJPc7qzbHrW1wa7kBFKPLUhAbDFWTQz8L8Zt3cCDoqCc3N0rLZ419LA3NgROek9 nXuti9RG0AofI6t8tMKFBJs1oE9jbs1iqWzG0HdI25U/I0euAUwJNlkVBDwQIOgw HzLYqdnmVJD9HWxMv0cKNY9xVZEnCem1JJaK/+9nrbUtOOvp7l7PWRSbePWYQRT3 KCDZuhl0I7A1qWX+SU28cuxRkxsVni6wvUKEkuxpT07A6XhMmLtGOJSpTDR/hsky gBCs1YSdDJe0NZleaBJ5LIJ30/p68qIm1cFFRLm1hi3bwuBiHq3/SYVTdUWAR/Kl 4xscL8o9f3A7J/npOU126Zn63ItMguHWrangJdTUUINUlF0wleTmZYpTP5+ck7gc Br05VZGWXyNTMYChzS0oQXHCZYdAV9YghRhj2PWKLGhmB8Z+1vo49o1AmGFswlZe TGwUZ2r3d7pZUF0N9zOkbs7BTQRacgcLARAA0es6bm/J0r+KPXOQPItnNuiCTnOM yHqgCvdwfigZskc8uXIVlMJUFhTAPiSHo1XWwq5k55f9rKDJWDVHIu6WfOxzpiNc 4jGWqGpDAYjyTyywAikxJ/Tb3vzUI0XYcLjYKsl4e1c040M06Owy6jHOBr3MtAKH iMtOUT9NQmjopUAFYFVG1NWHZnvukq03uPY08UEe+nsrRYd9X5NieWyCOFQDQAJm dR0dLZhHMGELPNB6W53EHPnhL3FtSrWZ9l9XHwBsAZcXbPGjrye+8AAmfjweIFLd 0yEIZgkN1l2NrpB1QU+J6aKc7HCRTMKqYrGb4CPtRK57VJtlmonGYwjV4Xg6uT8E kkjvhn8WcmBhHhSQSIPcn8pShxAIgfd1oHX78JeWH30hvsA/5Aa4qTe+c0eHtUGr cT5UCIzktTQGaBb5x1E8eSLAzuwNrZWdXdWq9XtCagwqccXNQHo2fy4T6JqSnknz U+vryQM6ruQtbdScaaDU9SpuycJpOKYlvckBhbM5b/0Jhw+VsB0iqL7Afsw6h4v4 8D30DeRb/zzWsaZ45gXPOuw1Uu15r4Al9e2ngs3mA5Ug8imi8I1JVdcQqCXtri+N QbNUHOsfs/NP6ThdQRDA0IAJ8ZnEQTG2fLX1uO+6ZnSu/4AQAe+xZIpcdRUnMg2O p31SKhoRsoYA+U8AEQEAAcLBhgQYAQoAJhYhBOyzaLh5CL+2kU1yae9bpNzVqfPA BQJh8E3NAhsMBQkLM37BABQJEO9bpNzVqfPACRDvW6Tc1anzwPfkD/4yF78b+PSP mDiAsOffMd+U53MhT1Rem+PWxChsn4VqMtLArcr+vxqYcTrZNtb5bsYQgDMz47Zl L1N67PWfe129btyTkOSzA56o0eSfl4mhGhnGQRYczxAHw2bN4JtCwZW7kwhqcGG3 nglWVG9O9GPerSl4c1PB5EYGUjNCL5mn7/kTwSxoNMjOhEsQS+HgjLoRHi7+jNQu VW5hY53wrkTH7itAZohHxYd+zifPciQyUQw4P0hWe0XSVcwJN+xz81NhA5X0L6jl sy9G8xQmx8k37BOTKAqatPIesSlk4lzTNuVXmnbrIGGsvzYO46sMZiT+EPnmcf3Y Aq6mMNidmlWoVyOBKnclLzmEj/gFceIVrGCPGtG9pEdXAbpnSnYZcet++HCS1bRH YMnrPxB7E+1Xy6GVvylfahIcsXMt1mpI0FKzuJcH8O4Asv+QsKY6Q4tcjSX0CROH EnGO9lIaNOA7nYXP5hsuyIjHkPRZ/VgrwD+/z9PUKszqyDBIpwf4Rk9Cmg8z2+TP xnooLMBnTAQPNYIiI9fMyWOHtfPkLIiGUtGBHb7LAQZ7Pxsi5fR36+crhwJiQhpM brthm4VE2pwKnMlohLXnxQtoMMfTw9jzCpTjwuEEFYIIEte8X5GyXItfAm4b9z77 5PDS0JZbUcHZ1sv65OP599IaYgf3rzJnIw=3D=3D =3DYr0r -----END PGP PUBLIC KEY BLOCK----- --------------tRu2yROQG0VZG223JDp8ZVia-- --------------ZeVbcLtkeujlgHF9O0iUKTSJ-- --------------nf0fELrRoa02cUZdSDq0S70c Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE7LNouHkIv7aRTXJp71uk3NWp88AFAmJlARwFAwAAAAAACgkQ71uk3NWp88Ce Hg//diNd/5ZtshcpW5sqdNau2ndd9rka6zrGtVTl7SJ158OwosBtBExecG/UmZaSHKjs6eOwcGvS wjE4n5TvuLFNb3TkGcOQ4nqfgSdBQjShTumeaUkiILEYxkH8ud2+6dT7Crp5mC6MH5FmI+sMWFZ9 SWASbLHepdLuFhaGcseH9JIi+JCnmQoKkXQ+kjAFHzzYYxI/vRKg3S/iuKgYb7ubpLwZnM0az8sV 1wbpbqeVuJQpgrOO0K7YqzNZlxPhPcLPkOhD8iQvWMhAALJsY+4cqYAl0B7OqgPDVstmzQmQHidN dXjodzk1The1B5k1FHxm/bY3fNeVywjjNTmv3R1RrTJcXHzlIVeQMQFlAbOTqLVtYksdNjkM4SUd XIjbuGwDpgO/VkoKGn4TAZViOr7KBKhbW09iV2DR1gvEOOCHYDCIW1axU5MKF6M066yx9Y17PkfN VvP5x2zRKjQ3WGsgwXrdQ5aA6fRZvB5pWmsdi2n+OU18KBDknvwi/pyeV4VXllFJm3zU0+pn05t6 wgrGIxqYoD2TsQZ+k6xcfPylUcUaQqEYNlqZJHrKJj98rDxXr0MGybDHgZnYxXKt7T1pf/v8Bd71 e7o6yktiJaDSR+7ZBRlf4947Ls2s/S957+uTi1JxQvwOyorZmr0I52wpWtPBuLX04r1mFRSo+HiS 6ak= =k+aE -----END PGP SIGNATURE----- --------------nf0fELrRoa02cUZdSDq0S70c-- From nobody Sun Apr 24 17:58:17 2022 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 4B904199A8A3 for ; Sun, 24 Apr 2022 17:58:48 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KmbVb1J01z4WPq for ; Sun, 24 Apr 2022 17:58:47 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 73733525; Sun, 24 Apr 2022 19:58:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1650823117; 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=qh/Uv+eBuRGe11/DCoT9VlCDYsXrKvRigr1CnsErkRQ=; b=KvmG2iJMUF56pXo6y5ZiGSPYxsSXCabN5jmI/XmO4lMoZPlZjgVL77aUlpbR2deRycias3 uwecbV0Q5wbQTgas4YwJyKX7jX/DFYr52tpBTAIAFV+N6gUjpsO8A8qoKu9v79Ky1uaCVY ePy8McuvP9B75PO/1SPF94BUycKrftoWTZ16MHipq6qE0c5i4K5YEVdpm/uK47+Hlv3MmX LqgJqDdP3aAYlkPyf5q6Grx61k+iEA2lfqXfyyXdzG5TknwYV1yNb//7MqfnMBBG+WDWRH p3qD301rXrngVKDvkS5FpJZUf5m28i72MGr3UTsn7NkrIDww587B2Q7jasJXMg== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 4BC934726; Sun, 24 Apr 2022 19:58:19 +0200 (CEST) Date: Sun, 24 Apr 2022 19:58:17 +0200 Message-ID: <20220424195817.Horde.W5ApGT13KmR06W2pKA0COxB@webmail.leidinger.net> From: Alexander Leidinger To: Doug Ambrisko Cc: Mateusz Guzik , freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> <20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN@webmail.leidinger.net> In-Reply-To: <20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN@webmail.leidinger.net> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_gIG_MBnt3QHSkVWyF6an8Jh"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4KmbVb1J01z4WPq X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=KvmG2iJM; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-6.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-0.94)[-0.938]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_gIG_MBnt3QHSkVWyF6an8Jh Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Alexander Leidinger (from Fri, 22=20=20 Apr=202022 09:04:39 +0200): > Quoting Doug Ambrisko (from Thu, 21 Apr 2022=20= =20 >=2009:38:35 -0700): >> I've attached mount.patch that when doing mount -v should >> show the vnode usage per filesystem. Note that the problem I was >> running into was after some operations arc_prune and arc_evict would >> consume 100% of 2 cores and make ZFS really slow. If you are not >> running into that issue then nocache etc. shouldn't be needed. > > I don't run into this issue, but I have a huge perf difference when=20=20 >=20using nocache in the nightly periodic runs. 4h instead of 12-24h (22=20= =20 >=20jails on this system). > >> On my laptop I set ARC to 1G since I don't use swap and in the past >> ARC would consume to much memory and things would die. When the >> nullfs holds a bunch of vnodes then ZFS couldn't release them. >> >> FYI, on my laptop with nocache and limited vnodes I haven't run >> into this problem. I haven't tried the patch to let ZFS free >> it's and nullfs vnodes on my laptop. I have only tried it via > > I have this patch and your mount patch installed now, without=20=20 >=20nocache and reduced arc reclaim settings (100, 1). I will check the=20= =20 >=20runtime for the next 2 days. 9-10h runtime with the above settings (compared to 4h with nocache and=20= =20 12-24h=20without any patch and without nocache). I changed the sysctls back to the defaults and will see in the next=20=20 run=20(in 7h) what the result is with just the patches. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_gIG_MBnt3QHSkVWyF6an8Jh Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJlj7kACgkQEg2wmwP4 2IbzBg/9F2s+3OP2ZpEVFg7ACQjZLCGef7NXz4viI68s0ZMvn1zEk7rW5HI7tAOZ 2XpvuuWhxWoF1ChDKSiJR7C2ddTmOieZkfQbNF2Au/pyYZ9pooKcFoO1hHCvEwD8 WbwbhNx0z/MnZfCcUJ3kidFEzlk/jKDxDNwsNM2aXr2sPJ1UjtclQhaCMp+3pRHW 95PNO2XQBsTSDPmZJF8xc0T5ehQzD1x+27b/kBN6QjNi/xC9MhXKPP4OrVZYxT6g WFWBgLP2M5P1oJigPZ11sarp7Ss0L5pOwEfscUqNymKqjE1CmiKgt6qAP9Ndv4rV IeTBMx3Hpm17UgFPcxciy86n3Q9EIZk0YeT3P/S09D5B5LJIyv+dGiY7J/Xl6GWm 0mjl2exAtrOc0JpWoUiO+A92dpTrZjSOHH76lyU/CMTye9vCQevxYbRZ9bcXVrll 5c5V/ybzTh3sKn2FVS3GuKVs5aVDtmCtj3gGHrSSFTeAv4LiiQ+O18812OaLoNvk j89+YbtsxCVOlN5Xlk0R7+ZTnc8FjSIUJWtBhIpCT9HZKqerBaH7xrAF/4W2MjpL 0ty3qAb5KBbYQMmIuFjI3hjPwA1cypqKLnv89ZggONbuPic1iuyiI0lzZOZH8WRj BjRF/yFW4FCfXNLdIhtDzUnvh2QrJRbHDtDAl0IFkYlCh9pyD/U= =jC0g -----END PGP SIGNATURE----- --=_gIG_MBnt3QHSkVWyF6an8Jh-- From nobody Mon Apr 25 13:27:27 2022 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 570281A9976D for ; Mon, 25 Apr 2022 13:28:00 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kn5Rg4TCWz4pBK; Mon, 25 Apr 2022 13:27:59 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 88FC011E3; Mon, 25 Apr 2022 15:27:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1650893266; 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=g9UUOOueLUQEzv+kjTbJoCTjtZ9flr+v7TpynihJnfw=; b=16EM43juvS+/swoo5hqwDBvQ5ev3JV/5qnrXaLGoy6+NLSKS9w623ZUCvPhF2OD3+FQFPj SR6H42SUxeCuHzH8pvjkF4+TPOBoQfgmE6e74R0FEwz/vrUiHlEWr+9VUMXEYqmgb4olnU bk5EMfV6b0E9tYJTiMZ6GTtpa7ZnYRU38P7blc93W3V7NEGSYWi8rtnB6dRad0LZiuwMQ5 IqmmaxMRgXznxXmaIs8arFz9j2fMBZJyX0SuTJQKWZjMsUOPy+E9EkR+gBMl76TQ7h/JGc ll/E2vVt426I0o74KbejICfftloJua+OiaEIewbXaltG+8VNd9O+g4kF/vTPMg== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 9F88341AE; Mon, 25 Apr 2022 15:27:28 +0200 (CEST) Date: Mon, 25 Apr 2022 15:27:27 +0200 Message-ID: <20220425152727.Horde.YqhquyTW0ZM3HAbI1kyskic@webmail.leidinger.net> From: Alexander Leidinger To: Doug Ambrisko Cc: Mateusz Guzik , freebsd-current@freebsd.org, pstef@freebsd.org Subject: Re: nullfs and ZFS issues References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> <20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN@webmail.leidinger.net> <20220424195817.Horde.W5ApGT13KmR06W2pKA0COxB@webmail.leidinger.net> In-Reply-To: <20220424195817.Horde.W5ApGT13KmR06W2pKA0COxB@webmail.leidinger.net> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_Fs4hNnq1O6CY8cmh2SLOJ4q"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4Kn5Rg4TCWz4pBK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=16EM43ju; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-4.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_SPAM_SHORT(1.00)[0.998]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_Fs4hNnq1O6CY8cmh2SLOJ4q Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Alexander Leidinger (from Sun, 24=20=20 Apr=202022 19:58:17 +0200): > Quoting Alexander Leidinger (from Fri, 22=20=20 >=20Apr 2022 09:04:39 +0200): > >> Quoting Doug Ambrisko (from Thu, 21 Apr=20=20 >>=202022 09:38:35 -0700): > >>> I've attached mount.patch that when doing mount -v should >>> show the vnode usage per filesystem. Note that the problem I was >>> running into was after some operations arc_prune and arc_evict would >>> consume 100% of 2 cores and make ZFS really slow. If you are not >>> running into that issue then nocache etc. shouldn't be needed. >> >> I don't run into this issue, but I have a huge perf difference when=20= =20 >>=20using nocache in the nightly periodic runs. 4h instead of 12-24h=20=20 >>=20(22 jails on this system). >> >>> On my laptop I set ARC to 1G since I don't use swap and in the past >>> ARC would consume to much memory and things would die. When the >>> nullfs holds a bunch of vnodes then ZFS couldn't release them. >>> >>> FYI, on my laptop with nocache and limited vnodes I haven't run >>> into this problem. I haven't tried the patch to let ZFS free >>> it's and nullfs vnodes on my laptop. I have only tried it via >> >> I have this patch and your mount patch installed now, without=20=20 >>=20nocache and reduced arc reclaim settings (100, 1). I will check the=20= =20 >>=20runtime for the next 2 days. > > 9-10h runtime with the above settings (compared to 4h with nocache=20=20 >=20and 12-24h without any patch and without nocache). > I changed the sysctls back to the defaults and will see in the next=20=20 >=20run (in 7h) what the result is with just the patches. And again 9-10h runtime (I've seen a lot of the find processes in the=20=20 periodic=20daily run of those 22 jails in the state "*vnode"). Seems=20=20 nocache=20gives the best perf for me in this case. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_Fs4hNnq1O6CY8cmh2SLOJ4q Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJmob4ACgkQEg2wmwP4 2IZUsg//Y0qPWaTPXK7ymy3P1TeXCjTm0pvd9PpeyJDC49twl6Gx7uYK6SuGR9tw JGrJV/ZehCkLwV9I5tP/COGHEp3iReijna7b+zC1/5v+rnLPXQSRVAEf2MHN+jo2 dnP+QTVLun89XYaOBqkIXcOarTKLjafSRWZe1PUeEwFNtqASR/Yjan53hdqI3ArI 5hNp3TVKRgAyTx4nPXbykLDrCs1MHLwjnego80ysTimMNG5yk1gl+zjwBuRwmC7f /lMccRyy2wS4o8LzAWqRpjLrg+q2lZDIdzC4P/+ItvItYq+ky7K5VbEyrjDIj1+0 8z5SXEBLU6qBF4rPD6qxE0+YUNKkmqs4dNcU47m728hN4jP/aCU6pz+iwFpMBLs5 OGQkz4r2f6FXzlxM1t/+KIsYK77wRZlfRFYd2eEEE3eUEWE2hj59GWuGlcoK5j9G 819+CxURqEq8IX6ElXxwJ8tPDYnJfG3Lc9bwGTfatcwHV1GbT1JIAz9GXjA1Rxrf IhbsbD1peW4Q2j8w/vacUh5m/qiUNxM91Wp3O36UsvE9OeL92IADHgGKq0AG4bhk F88N8b77G9c2FOzA8Ix/Y+neafiH1pD4qnCYF7m+IYkBGgtP1HJ6wshEqZTjMSS4 JkWzTtjGPT/bR30wy0DB6NNygZS0WLPmFf4cKurHwkGPYJFTIKE= =jj93 -----END PGP SIGNATURE----- --=_Fs4hNnq1O6CY8cmh2SLOJ4q-- From nobody Mon Apr 25 16:44:19 2022 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 BC6771A9BAFC for ; Mon, 25 Apr 2022 16:44:22 +0000 (UTC) (envelope-from ltning@anduin.net) Received: from mail.anduin.net (mail.anduin.net [185.42.170.45]) (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 4Kn9pF3nKGz3mCx for ; Mon, 25 Apr 2022 16:44:21 +0000 (UTC) (envelope-from ltning@anduin.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=anduin.net; s=dkim2021; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References: In-Reply-To:Date:To:From:Subject:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=TM6BhJvhYhljCX0El7Y709H+jfrgGOSwoCtXxtaJuuk=; t=1650905061; x=1651769061; b=BBXW+By+aMPX52c+TKXFezve0Px/bcIXr2HaRGYdAqRET7ijeXGmoEOZaep8+PN6LMc+oISUJzF mHGrFgyfe/+GwESQ2Xp35rj8qq7jQTyKVzwZwfePXuuzNYdldiTsW/7fB3Yk0oOZ+QaHXp+sU/eJm NSPFr2PcdpaPt9FZ4/wLNWl1jGM1O4uw0ZM2wIVelsdjFL3P2CRLuY9u0ofIW3rNPR8lYLWytxluE zYaCZ03Z4bj7KC6hkKi+OOXLbsBdxNsYXeAHjg5fgBA2vUxO83UVdrH8/eNrZXnAxyOJvGQbfFiQV bfq5oy2ezPnFdqhLs/RaodIWwg1lDFhvWlNA==; Received: by mail.modirum.com with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nj1oy-000EXX-81 for freebsd-current@freebsd.org; Mon, 25 Apr 2022 16:44:20 +0000 Message-ID: Subject: Re: nullfs and ZFS issues From: Eirik =?ISO-8859-1?Q?=D8verby?= To: freebsd-current@freebsd.org Date: Mon, 25 Apr 2022 18:44:19 +0200 In-Reply-To: <20220425152727.Horde.YqhquyTW0ZM3HAbI1kyskic@webmail.leidinger.net> References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> <20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN@webmail.leidinger.net> <20220424195817.Horde.W5ApGT13KmR06W2pKA0COxB@webmail.leidinger.net> <20220425152727.Horde.YqhquyTW0ZM3HAbI1kyskic@webmail.leidinger.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 FreeBSD GNOME Team 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-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-Rspamd-Queue-Id: 4Kn9pF3nKGz3mCx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=anduin.net header.s=dkim2021 header.b=BBXW+By+; dmarc=none; spf=pass (mx1.freebsd.org: domain of ltning@anduin.net designates 185.42.170.45 as permitted sender) smtp.mailfrom=ltning@anduin.net X-Spamd-Result: default: False [-2.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[anduin.net:s=dkim2021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[anduin.net]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[anduin.net:+]; NEURAL_HAM_SHORT(-0.61)[-0.612]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_MIXED_CHARSET(0.71)[subject]; ASN(0.00)[asn:62248, ipnet:185.42.170.0/24, country:EE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 2022-04-25 at 15:27 +0200, Alexander Leidinger wrote: > Quoting Alexander Leidinger (from Sun, 24 > Apr 2022 19:58:17 +0200): > > > Quoting Alexander Leidinger (from Fri, 22 > > Apr 2022 09:04:39 +0200): > > > > > Quoting Doug Ambrisko (from Thu, 21 Apr > > > 2022 09:38:35 -0700): > > > > > > I've attached mount.patch that when doing mount -v should > > > > show the vnode usage per filesystem. Note that the problem I was > > > > running into was after some operations arc_prune and arc_evict would > > > > consume 100% of 2 cores and make ZFS really slow. If you are not > > > > running into that issue then nocache etc. shouldn't be needed. > > > > > > I don't run into this issue, but I have a huge perf difference when > > > using nocache in the nightly periodic runs. 4h instead of 12-24h > > > (22 jails on this system). > > > > > > > On my laptop I set ARC to 1G since I don't use swap and in the past > > > > ARC would consume to much memory and things would die. When the > > > > nullfs holds a bunch of vnodes then ZFS couldn't release them. > > > > > > > > FYI, on my laptop with nocache and limited vnodes I haven't run > > > > into this problem. I haven't tried the patch to let ZFS free > > > > it's and nullfs vnodes on my laptop. I have only tried it via > > > > > > I have this patch and your mount patch installed now, without > > > nocache and reduced arc reclaim settings (100, 1). I will check the > > > runtime for the next 2 days. > > > > 9-10h runtime with the above settings (compared to 4h with nocache > > and 12-24h without any patch and without nocache). > > I changed the sysctls back to the defaults and will see in the next > > run (in 7h) what the result is with just the patches. > > And again 9-10h runtime (I've seen a lot of the find processes in the > periodic daily run of those 22 jails in the state "*vnode"). Seems > nocache gives the best perf for me in this case. Sorry for jumping in here - I've got a couple of questions: - Will this also apply to nullfs read-only mounts? Or is it only in case of writing "through" a nullfs mount that these problems are seen? - Is it a problem also in 13, or is this "new" in -CURRENT? We're having weird and unexplained CPU spikes on several systems, even after tuning geli to not use gazillions of threads. So far our suspicion has been ZFS snapshot cleanups but this is an interesting contender - unless the whole "read only" part makes it moot. /Eirik From nobody Mon Apr 25 19:07:47 2022 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 5753F1A93444 for ; Mon, 25 Apr 2022 19:07:50 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (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 4KnDzn62WKz4ZSv for ; Mon, 25 Apr 2022 19:07:49 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 1885F8; Mon, 25 Apr 2022 21:07:47 +0200 From: "Patrick M. Hausen" 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 \(3696.80.82.1.1\)) Date: Mon, 25 Apr 2022 21:07:47 +0200 Subject: Cross-compile worked, cross-install not so much ... Message-Id: <3D48BE93-7D42-4AB2-82D4-88BBF4E1FD40@hausen.com> To: "freebsd-current@freebsd.org" X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4KnDzn62WKz4ZSv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pmh@hausen.com has no SPF policy when checking 217.29.33.228) smtp.mailfrom=pmh@hausen.com X-Spamd-Result: default: False [-1.59 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hausen.com]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi all, getting into FreeBSD ARM64 I tried to compile a current system on a fast = AMD64 VM and now I am somewhat stuck - no help using search engines and the like. 1st step: # checkout main aka 14-CURRENT cd /usr/src make -j 8 TARGET=3Darm64 TARGET_ARCH=3Daarch64 buildworld = buildkernel That worked like a charm and I seem to have a well populated = /usr/obj/usr/src/arm64.aarch64. 2nd step: I then mounted /usr/src and /usr/obj on my Raspberry Pi via NFS. The = binaries in /usr/obj are the correct architecture and run perfectly well: root@pi8:~ # file /usr/obj/usr/src/arm64.aarch64/bin/sh/sh /usr/obj/usr/src/arm64.aarch64/bin/sh/sh: ELF 64-bit LSB pie = executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, = interpreter /libexec/ld-elf.so.1, for FreeBSD 14.0 (1400057), = FreeBSD-style, not stripped root@pi8:~ # /usr/obj/usr/src/arm64.aarch64/bin/sh/sh root@pi8:~ # ^D 3rd step: root@pi8:/usr/src # make TARGET=3Darm64 TARGET_ARCH=3Daarch64 = installkernel -------------------------------------------------------------- >>> Install check kernel -------------------------------------------------------------- -------------------------------------------------------------- >>> Installing kernel GENERIC on Mon Apr 25 21:03:58 CEST 2022 -------------------------------------------------------------- cd /usr/obj/usr/src/arm64.aarch64/sys/GENERIC; = MACHINE_ARCH=3Daarch64 MACHINE=3Darm64 CPUTYPE=3D CC=3D"cc -target = aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp= -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX=3D"c++ -target = aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp= -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP=3D"cpp -target = aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp= -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" AS=3D"as" AR=3D"ar" = ELFCTL=3D"elfctl" LD=3D"ld" LLVM_LINK=3D"" NM=3Dnm OBJCOPY=3D"objcopy" = RANLIB=3Dranlib STRINGS=3D SIZE=3D"size" STRIPBIN=3D"strip" = PATH=3D/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch= 64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/sr= c/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/leg= acy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src= /arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin = make KERNEL=3Dkernel install /bin/sh: make: Exec format error *** Error code 126 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src So via that complicated PATH setting it seems to run: = /usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin/make Which surprisingly is an amd64 binary: root@pi8:/usr/src # file = /usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin/make /usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin/make: ELF = 64-bit LSB pie executable, x86-64, version 1 (FreeBSD), dynamically = linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.0 (1400057), = FreeBSD-style, stripped So what did I do wrong? Thanks for all help, Patrick From nobody Mon Apr 25 19:18:23 2022 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 933411A97006 for ; Mon, 25 Apr 2022 19:18:30 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 4KnFD55011z4cZZ for ; Mon, 25 Apr 2022 19:18:29 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 871B73C0199; Mon, 25 Apr 2022 19:18:23 +0000 (UTC) Date: Mon, 25 Apr 2022 19:18:23 +0000 From: Brooks Davis To: "Patrick M. Hausen" Cc: "freebsd-current@freebsd.org" Subject: Re: Cross-compile worked, cross-install not so much ... Message-ID: <20220425191823.GA89506@spindle.one-eyed-alien.net> References: <3D48BE93-7D42-4AB2-82D4-88BBF4E1FD40@hausen.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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <3D48BE93-7D42-4AB2-82D4-88BBF4E1FD40@hausen.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4KnFD55011z4cZZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-1.98 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_SHORT(0.88)[0.883]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net] X-ThisMailContainsUnwantedMimeParts: N --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2022 at 09:07:47PM +0200, Patrick M. Hausen wrote: > Hi all, >=20 > getting into FreeBSD ARM64 I tried to compile a current system on a fast = AMD64 VM and > now I am somewhat stuck - no help using search engines and the like. >=20 > 1st step: >=20 > # checkout main aka 14-CURRENT > cd /usr/src > make -j 8 TARGET=3Darm64 TARGET_ARCH=3Daarch64 buildworld buildkernel >=20 > That worked like a charm and I seem to have a well populated /usr/obj/usr= /src/arm64.aarch64. >=20 > 2nd step: >=20 > I then mounted /usr/src and /usr/obj on my Raspberry Pi via NFS. The bina= ries > in /usr/obj are the correct architecture and run perfectly well: >=20 > root@pi8:~ # file /usr/obj/usr/src/arm64.aarch64/bin/sh/sh > /usr/obj/usr/src/arm64.aarch64/bin/sh/sh: ELF 64-bit LSB pie executable,= ARM aarch64, version 1 (FreeBSD), dynamically linked, interpreter /libexec= /ld-elf.so.1, for FreeBSD 14.0 (1400057), FreeBSD-style, not stripped > root@pi8:~ # /usr/obj/usr/src/arm64.aarch64/bin/sh/sh > root@pi8:~ # ^D >=20 > 3rd step: >=20 > root@pi8:/usr/src # make TARGET=3Darm64 TARGET_ARCH=3Daarch64 installker= nel > -------------------------------------------------------------- > >>> Install check kernel > -------------------------------------------------------------- > -------------------------------------------------------------- > >>> Installing kernel GENERIC on Mon Apr 25 21:03:58 CEST 2022 > -------------------------------------------------------------- > cd /usr/obj/usr/src/arm64.aarch64/sys/GENERIC; MACHINE_ARCH=3Daarch64 = MACHINE=3Darm64 CPUTYPE=3D CC=3D"cc -target aarch64-unknown-freebsd14.0 --= sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch= 64/tmp/usr/bin" CXX=3D"c++ -target aarch64-unknown-freebsd14.0 --sysroot= =3D/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/= usr/bin" CPP=3D"cpp -target aarch64-unknown-freebsd14.0 --sysroot=3D/usr/o= bj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" = AS=3D"as" AR=3D"ar" ELFCTL=3D"elfctl" LD=3D"ld" LLVM_LINK=3D"" NM=3Dnm OB= JCOPY=3D"objcopy" RANLIB=3Dranlib STRINGS=3D SIZE=3D"size" STRIPBIN=3D"st= rip" PATH=3D/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.a= arch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr= /src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/l= egacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/sr= c/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin make= KERNEL=3Dkernel install > /bin/sh: make: Exec format error > *** Error code 126 >=20 > Stop. > make[1]: stopped in /usr/src > *** Error code 1 >=20 > Stop. > make: stopped in /usr/src >=20 > So via that complicated PATH setting it seems to run: /usr/obj/usr/src/ar= m64.aarch64/tmp/legacy/usr/bin/make >=20 > Which surprisingly is an amd64 binary: >=20 > root@pi8:/usr/src # file /usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/b= in/make > /usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin/make: ELF 64-bit LSB p= ie executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter= /libexec/ld-elf.so.1, for FreeBSD 14.0 (1400057), FreeBSD-style, stripped >=20 >=20 > So what did I do wrong? Cross install is not supported. As you have seen, certain tools are bootstrapped on the build host and used during the install process. You might be able to get away with nuking /usr/obj/usr/src/arm64.aarch64/tmp/legacy (or maybe tmp) and then running `make toolchain` to build native versions of those tools. -- Brooks --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJiZvP+AAoJEKzQXbSebgfAO2YH/AlpfPiw7YHHW9AwJS20cMKz J4cbCSEpx/g+tc22NhjOwpPFw0Mo4SrpXma1bHBHkPkGHcSCtXt4FcNJWgaxDeA/ rDkZqnR4GzPhnQk1allJp9Dnkaz2VITCyANv2h9M6VcA/kFcp9Xu3Q58XQo94zrr 9q33ckDWyKPRLAuxfTRCFYlkCLbqaSXqBolOUy/8GGHzJMCpMK5n9e2NiGJh1tjn 8geps7gZwGvhswR44b3B2K0mus8yPwQBBhBItunPErAWzCZ9RVkUsnRvLoMyeap6 sR/WtQuQayRqkKOt45V1IYinWvqD2DLrUlKvqjPBor05LYfV5YYwxr+N8HiqzIA= =/NVF -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From nobody Mon Apr 25 19:26:04 2022 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 7ABFE1A99969 for ; Mon, 25 Apr 2022 19:26:07 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (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 4KnFNt5B2Qz4fRX for ; Mon, 25 Apr 2022 19:26:06 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 3E801E; Mon, 25 Apr 2022 21:26:05 +0200 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 \(3696.80.82.1.1\)) Subject: Re: Cross-compile worked, cross-install not so much ... From: "Patrick M. Hausen" In-Reply-To: <20220425191823.GA89506@spindle.one-eyed-alien.net> Date: Mon, 25 Apr 2022 21:26:04 +0200 Cc: "freebsd-current@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.com> References: <3D48BE93-7D42-4AB2-82D4-88BBF4E1FD40@hausen.com> <20220425191823.GA89506@spindle.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4KnFNt5B2Qz4fRX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pmh@hausen.com has no SPF policy when checking 217.29.33.228) smtp.mailfrom=pmh@hausen.com X-Spamd-Result: default: False [-1.58 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hausen.com]; ARC_NA(0.00)[]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.985]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, > Am 25.04.2022 um 21:18 schrieb Brooks Davis : > Cross install is not supported. As you have seen, certain tools are > bootstrapped on the build host and used during the install process. = You > might be able to get away with nuking > /usr/obj/usr/src/arm64.aarch64/tmp/legacy (or maybe tmp) and then > running `make toolchain` to build native versions of those tools. that comes as a big surprise and disappointment. What is the point of = cross-compiling, then? How to update a small slow embedded platform? I tried your suggestion - unfortunately no worky: cd /usr/src/tools/build; make DIRPRFX=3Dtools/build/ = DESTDIR=3D/usr/obj/usr/src/arm64.aarch64/tmp/legacy host-symlinks Linking host tools into /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin cp: chflags: /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin/basename: = Operation not supported *** Error code 1 So I will probably need to checkout and compile on the Pi. What are = typical build times on a CM3+? Plus I am going to wear down the builtin eMMC = much faster. Kind regards and thanks, Patrick= From nobody Mon Apr 25 19:47:03 2022 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 D21341A9EC74 for ; Mon, 25 Apr 2022 19:47:40 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KnFsm1DYKz4j1N; Mon, 25 Apr 2022 19:47:40 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ot1-x336.google.com with SMTP id l9-20020a056830268900b006054381dd35so11545217otu.4; Mon, 25 Apr 2022 12:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dL6laFIraYwm1d7uagKDU8uuye1Xp5x/AHm/E9C7KdU=; b=iZue50jxcm6CsSnVoEMd8LTlfloSb7IbiaRaKwo425U+l4VelSBjEVcCxK4c7hHBYG ybjdoSfvfjLOM7s4E2W+4DVdCBAwx4wJ3MuXnI4QsmesyWna1vY4Ur109YrAaR6swKRg oio2Grt2Ie5bu7EluoLstfZpn3HbmJ2oYrwlRYk21W8tIfpdC7Qg2Na/6FmuONCXnVB4 COgQ1PHkNwdm3MYrqeD5/G7NF0+KUoaN84p1xPHg92FvrXbgNf1fMi1MsNwJne9RtPMG KaX4/nBF/X3TxAd34lNgcfpOxGUgY0kci5M5ngtff/w/cl3D5+HnojInzckyd0q2O9y0 o7sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dL6laFIraYwm1d7uagKDU8uuye1Xp5x/AHm/E9C7KdU=; b=IU8J4bWQEBy4if49CZtrTMZpGmDgMNcn9wsGStD3gRCULYMptiuxk+R5+BTEyzapLI a26iJtlIFmp+ldTUP/WyXFMpWDMPHKQfz8LSSuK69LvwGBiGjyOOkP+QEE9JshSI/W3P SBn8WtHHPFLQM/U5wY5oaPeRWcHPY5Wy1tB8XFGtA+Pf+B0pTTObpERhu+/VRSsKMOAP vTK2cwh8C3jjFYFBtUjPVwYyoTFVa3RV9d3f1ndRXMW6HBIW7uYeObEXhasVZ9G3J5wn hCi44p/D4uHe2ySVX/CrxXa2lk+PrXNmS8Bj1p+SacEceJLHIQoPNUZtLo5vIfw53M3o 6ttg== X-Gm-Message-State: AOAM532zx4p3YNgYI80lc90fi5w/zYBnJqC6k1AV0IlyyHxQEh4K6EOg uMDzZLIXyiW1EQ1jGM2JJD0dNyrQFsXwXtJqvfXBO8nTC9A= X-Google-Smtp-Source: ABdhPJwlaoZ4diyREz27MVUmZrs34vCUs4arcVsfIaQt1NLb/Y8y6NkxttWB5FkohbUQZE1gdL23Ui700f4IGHwYHzA= X-Received: by 2002:a9d:114:0:b0:604:8e3f:f5fe with SMTP id 20-20020a9d0114000000b006048e3ff5femr7121955otu.252.1650916059430; Mon, 25 Apr 2022 12:47:39 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <3D48BE93-7D42-4AB2-82D4-88BBF4E1FD40@hausen.com> <20220425191823.GA89506@spindle.one-eyed-alien.net> <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.com> In-Reply-To: <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.com> From: Mehmet Erol Sanliturk Date: Mon, 25 Apr 2022 22:47:03 +0300 Message-ID: Subject: Re: Cross-compile worked, cross-install not so much ... To: "Patrick M. Hausen" Cc: Brooks Davis , "freebsd-current@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000046c31b05dd7fd9da" X-Rspamd-Queue-Id: 4KnFsm1DYKz4j1N X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=iZue50jx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mesanliturk@gmail.com designates 2607:f8b0:4864:20::336 as permitted sender) smtp.mailfrom=mesanliturk@gmail.com X-Spamd-Result: default: False [-3.96 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.96)[-0.958]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::336:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000046c31b05dd7fd9da Content-Type: text/plain; charset="UTF-8" On Mon, Apr 25, 2022 at 10:26 PM Patrick M. Hausen wrote: > Hi, > > > Am 25.04.2022 um 21:18 schrieb Brooks Davis : > > Cross install is not supported. As you have seen, certain tools are > > bootstrapped on the build host and used during the install process. You > > might be able to get away with nuking > > /usr/obj/usr/src/arm64.aarch64/tmp/legacy (or maybe tmp) and then > > running `make toolchain` to build native versions of those tools. > > that comes as a big surprise and disappointment. What is the point of > cross-compiling, then? > How to update a small slow embedded platform? > > You can cross compile a program and then use it on a related system . Please think this is a contribution . In that way , piece by piece you may construct another system . You are right : Being able to construct an installable system is a good idea . When it is not available as a whole , having a partial capability is a good step . Mehmet Erol Sanliturk > I tried your suggestion - unfortunately no worky: > > cd /usr/src/tools/build; make DIRPRFX=tools/build/ > DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp/legacy host-symlinks > Linking host tools into /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin > cp: chflags: /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin/basename: > Operation not supported > *** Error code 1 > > So I will probably need to checkout and compile on the Pi. What are typical > build times on a CM3+? Plus I am going to wear down the builtin eMMC much > faster. > > Kind regards and thanks, > Patrick > --00000000000046c31b05dd7fd9da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 25, 2022= at 10:26 PM Patrick M. Hausen <pmh@ha= usen.com> wrote:
Hi,

> Am 25.04.2022 um 21:18 schrieb Brooks Davis <brooks@freebsd.org>:
> Cross install is not supported.=C2=A0 As you have seen, certain tools = are
> bootstrapped on the build host and used during the install process.=C2= =A0 You
> might be able to get away with nuking
> /usr/obj/usr/src/arm64.aarch64/tmp/legacy (or maybe tmp) and then
> running `make toolchain` to build native versions of those tools.

that comes as a big surprise and disappointment. What is the point of cross= -compiling, then?
How to update a small slow embedded platform?



You can cross= compile a program and then use it
on a related system = .
Please think this is a contribution . In that way , p= iece by piece
you may construct another system .
You are right : Being able to construct an installable system is a
good idea . When it is not available as a whole , having
a partial capability is a good step .


Mehmet Erol Sanliturk




<= br>

=C2=A0
I tried your suggestion - unfortunately no worky:

cd /usr/src/tools/build;=C2=A0 make DIRPRFX=3Dtools/build/ DESTDIR=3D/usr/o= bj/usr/src/arm64.aarch64/tmp/legacy host-symlinks
Linking host tools into /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin
cp: chflags: /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin/basename: Operat= ion not supported
*** Error code 1

So I will probably need to checkout and compile on the Pi. What are typical=
build times on a CM3+? Plus I am going to wear down the builtin eMMC much f= aster.

Kind regards and thanks,
Patrick
--00000000000046c31b05dd7fd9da-- From nobody Mon Apr 25 19:54:16 2022 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 1E8E01990B00 for ; Mon, 25 Apr 2022 19:54:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KnG1j3CP9z4kSx for ; Mon, 25 Apr 2022 19:54:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2e.google.com with SMTP id j16so15476045vsv.2 for ; Mon, 25 Apr 2022 12:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PO1L6o1655IuM20neb68k1neQno+avXcN3bk2i1kjgg=; b=m6wqdXlrj9ZRg69LDuRJMJhbCK5bjgGCRENICh6nGwJ6eDRlFxejc/pTz1L5ugEOMc YWAmBXJu2/ddv5D8yJK/wrf0CQ1IxVCiz6a0sYvvc4jlced0x6RsM7f+SpI1fOe6EabZ fjtGDqDw412ejVoGYGXxk2Ynpa9fyQYVJe6YOXMvnk2Qqmx7Azgo50kRHQMxiJgWtEWx cPl25QjRA4UKnGef/fzs/0tcrbHOhg5o7Bs7MofkFtItVA82RC5rPrcfF4YnhD5+eecK DCHc9yrJ1CFVANl0TjGVBd3HbUzf4wxnAhRfof1bjmnxvvnpEqeRbWK0M0LZBvfgaos6 WymQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PO1L6o1655IuM20neb68k1neQno+avXcN3bk2i1kjgg=; b=V9F5GXFeyxE9kGkzFzGUZExae61bWxONe00gMO5DNfgmGf/NYYJ2TW/1bcfMhGYZ+7 RTy+O/fICQsvjKuxujidDnFob+WyM+JJrkCMpCiHot4tAyegOLD+QD/bF1Zwn9z5Ng2n 7oNKBJ/1T1IUEAwwW2NKdtSx3UjeRhNnWKfF/XYhpVqtGSxga/zBfdjIQq5DYLd9jkjt DK+whnXUEkaGqdTjWTdkBklbU42iOqnMDhL/P1FhdTZHYivm68ZjhctOh9MZjtP7mRqr KW/CworAGlnufRIJ2UWaV1nJYJD8oKV0Q73ZFrXOVKp8Spl7OjMgBLot1Jri986h7iWH IsdA== X-Gm-Message-State: AOAM530IGA9x//6JltQTOzaxht89J2XlAR1Mj8qrpgVNAWJWCdKQIwBr HYc6mi5uVrgjphqTY5TcOjZUJGIWqLAvyYGx5StvQhMxbFw= X-Google-Smtp-Source: ABdhPJwUuKazgL1dPvgwD4gfe5HVo2ijsH7YtHMyoL7OvJtzxLR+cNAoesqcCDJAYbsiOujtMsjgctcZm1447oOkFBc= X-Received: by 2002:a05:6102:956:b0:32a:6820:36bf with SMTP id a22-20020a056102095600b0032a682036bfmr5517209vsi.42.1650916467447; Mon, 25 Apr 2022 12:54:27 -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: <3D48BE93-7D42-4AB2-82D4-88BBF4E1FD40@hausen.com> <20220425191823.GA89506@spindle.one-eyed-alien.net> <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.com> In-Reply-To: <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.com> From: Warner Losh Date: Mon, 25 Apr 2022 13:54:16 -0600 Message-ID: Subject: Re: Cross-compile worked, cross-install not so much ... To: "Patrick M. Hausen" Cc: Brooks Davis , "freebsd-current@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000098c21e05dd7ff114" X-Rspamd-Queue-Id: 4KnG1j3CP9z4kSx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=m6wqdXlr; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.95 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.95)[-0.950]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2e:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000098c21e05dd7ff114 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 25, 2022 at 1:26 PM Patrick M. Hausen wrote: > Hi, > > > Am 25.04.2022 um 21:18 schrieb Brooks Davis : > > Cross install is not supported. As you have seen, certain tools are > > bootstrapped on the build host and used during the install process. You > > might be able to get away with nuking > > /usr/obj/usr/src/arm64.aarch64/tmp/legacy (or maybe tmp) and then > > running `make toolchain` to build native versions of those tools. > > that comes as a big surprise and disappointment. What is the point of > cross-compiling, then? > How to update a small slow embedded platform? > Cross installing is supported. Native installing of a cross build world isn't. When I've had to do this in the past, I've just mounted the embedded system on my beefy server under /mumble (allowing root on the embedded system for NFS) and did a sudo make installworld ... DESTDIR=/mumble. Though I've forgotten the gymnastics to do etcupdate/mergemaster this way. Warner > I tried your suggestion - unfortunately no worky: > > cd /usr/src/tools/build; make DIRPRFX=tools/build/ > DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp/legacy host-symlinks > Linking host tools into /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin > cp: chflags: /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin/basename: > Operation not supported > *** Error code 1 > > So I will probably need to checkout and compile on the Pi. What are typical > build times on a CM3+? Plus I am going to wear down the builtin eMMC much > faster. > > Kind regards and thanks, > Patrick > --00000000000098c21e05dd7ff114 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 25, 2022 at 1:26 PM Patri= ck M. Hausen <pmh@hausen.com> w= rote:
Hi,

> Am 25.04.2022 um 21:18 schrieb Brooks Davis <brooks@freebsd.org>:
> Cross install is not supported.=C2=A0 As you have seen, certain tools = are
> bootstrapped on the build host and used during the install process.=C2= =A0 You
> might be able to get away with nuking
> /usr/obj/usr/src/arm64.aarch64/tmp/legacy (or maybe tmp) and then
> running `make toolchain` to build native versions of those tools.

that comes as a big surprise and disappointment. What is the point of cross= -compiling, then?
How to update a small slow embedded platform?

Cross installing is supported. Native installing of a cross build wo= rld isn't.

When I've had to do this in the= past, I've just mounted the embedded system on my
beefy serv= er under /mumble (allowing root on the embedded system for NFS) and did
a sudo make installworld ... DESTDIR=3D/mumble. Though I've forg= otten the gymnastics
to do etcupdate/mergemaster this way.
<= div>
Warner
=C2=A0
I tried your suggestion - unfortunately no worky:

cd /usr/src/tools/build;=C2=A0 make DIRPRFX=3Dtools/build/ DESTDIR=3D/usr/o= bj/usr/src/arm64.aarch64/tmp/legacy host-symlinks
Linking host tools into /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin
cp: chflags: /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin/basename: Operat= ion not supported
*** Error code 1

So I will probably need to checkout and compile on the Pi. What are typical=
build times on a CM3+? Plus I am going to wear down the builtin eMMC much f= aster.

Kind regards and thanks,
Patrick
--00000000000098c21e05dd7ff114-- From nobody Mon Apr 25 21:31:58 2022 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 AF0231A8BD38 for ; Mon, 25 Apr 2022 21:32:02 +0000 (UTC) (envelope-from maciphone3@googlemail.com) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KnJB92mNDz4vQq for ; Mon, 25 Apr 2022 21:32:01 +0000 (UTC) (envelope-from maciphone3@googlemail.com) Received: by mail-wr1-x42f.google.com with SMTP id d5so7495370wrb.6 for ; Mon, 25 Apr 2022 14:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=xSMikmRLUyDZWJjW2Yvjs15B9n2ZDh7JzvgbIMqxRJE=; b=QFNKUXMcvr/gV8xoWHerx1tA4yyIllC/XrgR1nw1j8lJmJOibBSLBA1N+rXFaMcuSG 6BPMTk8TPdHOUv3SD91+DEOw9e0ItmFKwvhnFUnwhK/0eNKxDOEgvgR+gejQLZX+3veN Z2e/nl2GKWUT690+usltZWAU1GmVHIC+vYa0Wk3d9NZJEFbncVTu5rK4838LRkovtImi 5haJo/EUbtaKmWwWwrt9JJEEGX5AmGg+g6zPkSYoyx08JCnEjFTwfhswOMIMRKouGunU 7e/gSnCIClpRfU7QDMostgxlT76ZHfBADqHkHAdLvI6fN3MYQpwAUWQFbMOz/CaiQB53 NgKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=xSMikmRLUyDZWJjW2Yvjs15B9n2ZDh7JzvgbIMqxRJE=; b=ThC27tTKiuUTbmYJ0JknaUr0e1IK5WLdHU1GiNlkeI/g/mOUlApkIPdZAVyzbvAA7C O/999yMi2I/sgQMXDnHhSRe1vzlDznodaTiWyaO/4xuYWGjtFdsXvJtI84RgWEiic5E2 RYccpSdF2F0V3YAxiy0WLX4d0yX3MQBMzYDSDVK8yiQSeNh9l2ZdPlTh3CNoSgBT0nN/ xIJTe0Kq2olulUr9C58JaAU5FXizPRJKvxNjgpn+L/AICbK5+K+GY5VeNT232GjpNKek ocaEP7qjIqS5JQecRSl3Q9xGlrZlqNU3Nd0hC1m/iH7tAWa8JcD3YouL3zyoZc6O/OgF T2yA== X-Gm-Message-State: AOAM532mWZe5VLaivem3I9brvsnlO0eWH/AQxqtt2qiWsARpg9NRSod0 9fnI9D0DbROEdNvRPQkoYq3hH71vvaA= X-Google-Smtp-Source: ABdhPJy1i4EBU7lp3cKqI83J4xhrrTghQYpF3Yh0th/z7m+k8ErHqOwgkHDkKB7hWxo+4m/tfJxAFw== X-Received: by 2002:a5d:6b11:0:b0:20a:a247:25f4 with SMTP id v17-20020a5d6b11000000b0020aa24725f4mr15567470wrw.234.1650922320202; Mon, 25 Apr 2022 14:32:00 -0700 (PDT) Received: from smtpclient.apple (dynamic-046-114-031-181.46.114.pool.telefonica.de. [46.114.31.181]) by smtp.googlemail.com with ESMTPSA id g5-20020adfd1e5000000b0020a97e7ba9fsm11503458wrd.92.2022.04.25.14.31.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Apr 2022 14:31:59 -0700 (PDT) From: Klaus Kuechemann 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 \(3696.80.82.1.1\)) Subject: Re: Cross-compile worked, cross-install not so much ... Date: Mon, 25 Apr 2022 23:31:58 +0200 References: <063D5E36-126F-497C-97AF-827BADC1ED2F.ref@yahoo.com> <063D5E36-126F-497C-97AF-827BADC1ED2F@yahoo.com> <90A23579-61B7-4619-AFD7-68439FCC16F3@yahoo.com> <4515C859-98C7-4FE2-AFBA-08CFF28D0774@yahoo.com> To: freebsd-current@freebsd.org, pmh@hausen.com, Warner Losh In-Reply-To: Message-Id: <581FE0A3-E831-412C-BDE3-966802A244BE@googlemail.com> X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4KnJB92mNDz4vQq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=googlemail.com header.s=20210112 header.b=QFNKUXMc; dmarc=pass (policy=quarantine) header.from=googlemail.com; spf=pass (mx1.freebsd.org: domain of maciphone3@googlemail.com designates 2a00:1450:4864:20::42f as permitted sender) smtp.mailfrom=maciphone3@googlemail.com X-Spamd-Result: default: False [-3.46 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.31.181:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.966]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.99)[-0.991]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42f:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N You can : - setenv DESTDIR /wherever make -jWhatever TARGET_ARCH=3Daarch64 -DNO_ROOT DESTDIR=3D$DESTDIR = installworld make -jWhatever TARGET_ARCH=3Daarch64 -DNO_ROOT DESTDIR=3D$DESTDIR = distribution make -jWhatever TARGET_ARCH=3Daarch64 -DNO_ROOT DESTDIR=3D$DESTDIR = installkernel - Patrick M. Hausen wrote: > What are typical > build times on a CM3+? depends on how long you sleep at night if yo want it finished after = wakeup ;-), .. on the Pi4 approx. 8 to 9 hours w/o fine-tuning but with powerd = configured . you can immediately PXE-boot your -DNO_ROOT from a pxe-configured = server(e.g. where your DESTDIR lives) if you=E2=80=99re not in the mood of waiting so long. K.= From nobody Mon Apr 25 21:40:00 2022 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 407EA1A8DE11 for ; Mon, 25 Apr 2022 21:40:01 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 4KnJMN4f3Wz3Cft for ; Mon, 25 Apr 2022 21:40:00 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 2CF423C0199; Mon, 25 Apr 2022 21:40:00 +0000 (UTC) Date: Mon, 25 Apr 2022 21:40:00 +0000 From: Brooks Davis To: "Patrick M. Hausen" Cc: "freebsd-current@freebsd.org" Subject: Re: Cross-compile worked, cross-install not so much ... Message-ID: <20220425214000.GB89506@spindle.one-eyed-alien.net> References: <3D48BE93-7D42-4AB2-82D4-88BBF4E1FD40@hausen.com> <20220425191823.GA89506@spindle.one-eyed-alien.net> <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4KnJMN4f3Wz3Cft X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-2.77 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.911]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_SHORT(0.04)[0.040]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net] X-ThisMailContainsUnwantedMimeParts: N --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 25, 2022 at 09:26:04PM +0200, Patrick M. Hausen wrote: > Hi, >=20 > > Am 25.04.2022 um 21:18 schrieb Brooks Davis : > > Cross install is not supported. As you have seen, certain tools are > > bootstrapped on the build host and used during the install process. You > > might be able to get away with nuking > > /usr/obj/usr/src/arm64.aarch64/tmp/legacy (or maybe tmp) and then > > running `make toolchain` to build native versions of those tools. >=20 > that comes as a big surprise and disappointment. What is the point of cro= ss-compiling, then? > How to update a small slow embedded platform? The traditional answer is: build a new image and install it as a whole-sale replacement for the device image or in a nanobsd system with two boot partitions. If someone was motivated they could presumably work things out so we could cross compile the boostrap tools, but that would be a fair bit of work. It would probably be easier to figure out how to process the METALOG file in a sysroot to extract the files you want to update and install them in the right order (the order mostly doesn't matter until it really does and everything explodes as you crossthread rtld/libc/libthr). If I had time, this is the path I would pursue. > I tried your suggestion - unfortunately no worky: >=20 > cd /usr/src/tools/build; make DIRPRFX=3Dtools/build/ DESTDIR=3D/usr/obj/= usr/src/arm64.aarch64/tmp/legacy host-symlinks > Linking host tools into /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin > cp: chflags: /usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin/basename: Oper= ation not supported > *** Error code 1 You might try editing tools/build/Makefile and dropping -p from _COPY_HOST_TOOL or just tweaking the code to take the !FreeBSD branch. I'm not fully convinced that cp -p should fail if file flags can't be manipulated, but apparently it does. -- Brooks --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJiZxUvAAoJEKzQXbSebgfAQMUIAIPXaqFgNgweNZkfcftrk3mk qlXc2+GWTDbFcS2KRvLt9T1LZT+RaDhbpUIQkD3AdNaLeQyi2uuYx+gBGLDafzGA Mx05UIJ06nStODM4NUncXs3eEOfVw4QDKYvw80i+ySMSkYucZ4FzYx34Gp5DbBbD Bjbok2DMJTlwwM/fA98AsOP5FfRMRMkrhonqCvWoEcHHqX4fEEK3MKjc2anqFsug 39zi0gl4dDs29RBA1bzCBBjHLMXXjWpNAg3UA0yMG3V8cspGMH0MzGHOJbyplLGf Zrml2fgpot0tujpRpOEZY0UfbunAO0E8W3JmlsWspKZLKnNLsGmgIryrhuumook= =sQpS -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From nobody Mon Apr 25 23:17:18 2022 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 BF5C91993A95 for ; Mon, 25 Apr 2022 23:17:31 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (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 4KnLWt69sdz3PhP; Mon, 25 Apr 2022 23:17:30 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 4580038EAD; Mon, 25 Apr 2022 19:17:19 -0400 (EDT) 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 \(3696.80.82.1.1\)) Subject: Re: Cross-compile worked, cross-install not so much ... From: Paul Mather In-Reply-To: <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.com> Date: Mon, 25 Apr 2022 19:17:18 -0400 Cc: Brooks Davis , "freebsd-current@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D48BE93-7D42-4AB2-82D4-88BBF4E1FD40@hausen.com> <20220425191823.GA89506@spindle.one-eyed-alien.net> <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.com> To: "Patrick M. Hausen" X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4KnLWt69sdz3PhP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none); spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 2001:468:c80:a103:2:5000:5555:5555) smtp.mailfrom=paul@gromit.dlib.vt.edu X-Spamd-Result: default: False [-1.65 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[paul]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.47)[-0.475]; NEURAL_HAM_MEDIUM(-0.67)[-0.671]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1312, ipnet:2001:468:c80::/48, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Apr 25, 2022, at 3:26 PM, Patrick M. Hausen wrote: > Hi, >=20 >> Am 25.04.2022 um 21:18 schrieb Brooks Davis : >> Cross install is not supported. As you have seen, certain tools are >> bootstrapped on the build host and used during the install process. = You >> might be able to get away with nuking >> /usr/obj/usr/src/arm64.aarch64/tmp/legacy (or maybe tmp) and then >> running `make toolchain` to build native versions of those tools. >=20 > that comes as a big surprise and disappointment. What is the point of = cross-compiling, then? > How to update a small slow embedded platform? At least as far back as July 2016 I kept my FreeBSD/arm systems updated = by cross-building on a FreeBSD/amd64 system and using PkgBase to update = the OS on the FreeBSD/arm systems: = https://lists.freebsd.org/pipermail/freebsd-arm/2016-July/014444.html This worked well for me, at least until I stopped running FreeBSD on my = ARM systems. I don't know whether it still works. Cheers, Paul. From nobody Tue Apr 26 06:15:45 2022 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 1AC65199B589 for ; Tue, 26 Apr 2022 06:16:15 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KnWq15250z3F5K for ; Tue, 26 Apr 2022 06:16:13 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 064741D27; Tue, 26 Apr 2022 08:16:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1650953767; 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=hQ0yLqrV2AMBlfaeS7+FEklDYOzVM4GZgUbJ0qf/wMU=; b=MOGsWVgOiJPofwQxMt7QMVXI2tYOn/eXfsfvlYfb8kqPV1bcYsvTqF/evee0Md9D/6CKqc hlj5mPgCylm3+mS63CJRJpVwTN7sqDQ8KJ/SkCuwjrLiiiCBZVzKkwuSPtIGfvQ2YgCbzt AweEzrK3kgFO4KYo9+tCn8riOhu8XyjLx2hJSYUjGW7ZgWvH1x/7mZfdMj7WhVc0nI1P5m cTJbqPCexr0fC2UUyAEKNLtDctssJXfIFIqyNjo0ndu4wji39PThxCa/hiJIf//Wfe63Z2 Skg6x4mxA++RH8cB7NdgshhSK9dWVD5OM1FMDKx2dVvQrWRfAzUYh5IV2IIrnw== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id AB81843E9; Tue, 26 Apr 2022 08:15:48 +0200 (CEST) Date: Tue, 26 Apr 2022 08:15:45 +0200 Message-ID: <20220426081545.Horde.IzWT3chMkImG5Hr28ZuCwFT@webmail.leidinger.net> From: Alexander Leidinger To: Eirik =?utf-8?b?w5h2ZXJieQ==?= Cc: freebsd-current@freebsd.org Subject: Re: nullfs and ZFS issues References: <20220420113944.Horde.5qBL80-ikDLIWDIFVJ4VgzX@webmail.leidinger.net> <20220421083310.Horde.r7YT8777_AvGU_6GO1cC90G@webmail.leidinger.net> <20220421154402.Horde.I6m2Om_fxqMtDMUqpiZAxtP@webmail.leidinger.net> <20220422090439.Horde.TabULDW9aIeaNLxngZxdvvN@webmail.leidinger.net> <20220424195817.Horde.W5ApGT13KmR06W2pKA0COxB@webmail.leidinger.net> <20220425152727.Horde.YqhquyTW0ZM3HAbI1kyskic@webmail.leidinger.net> In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_M0tS0UKMgrrriOAIvn4fVPG"; protocol="application/pgp-signature"; micalg=pgp-sha256 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-Rspamd-Queue-Id: 4KnWq15250z3F5K X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=MOGsWVgO; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-6.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_M0tS0UKMgrrriOAIvn4fVPG Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Eirik =C3=98verby (from Mon, 25 Apr 2022=20=20 18:44:19=20+0200): > On Mon, 2022-04-25 at 15:27 +0200, Alexander Leidinger wrote: >> Quoting Alexander Leidinger (from Sun, 24 >> Apr 2022 19:58:17 +0200): >> >> > Quoting Alexander Leidinger (from Fri, 22 >> > Apr 2022 09:04:39 +0200): >> > >> > > Quoting Doug Ambrisko (from Thu, 21 Apr >> > > 2022 09:38:35 -0700): >> > >> > > > I've attached mount.patch that when doing mount -v should >> > > > show the vnode usage per filesystem. Note that the problem I was >> > > > running into was after some operations arc_prune and arc_evict wou= ld >> > > > consume 100% of 2 cores and make ZFS really slow. If you are not >> > > > running into that issue then nocache etc. shouldn't be needed. >> > > >> > > I don't run into this issue, but I have a huge perf difference when >> > > using nocache in the nightly periodic runs. 4h instead of 12-24h >> > > (22 jails on this system). >> > > >> > > > On my laptop I set ARC to 1G since I don't use swap and in the pas= t >> > > > ARC would consume to much memory and things would die. When the >> > > > nullfs holds a bunch of vnodes then ZFS couldn't release them. >> > > > >> > > > FYI, on my laptop with nocache and limited vnodes I haven't run >> > > > into this problem. I haven't tried the patch to let ZFS free >> > > > it's and nullfs vnodes on my laptop. I have only tried it via >> > > >> > > I have this patch and your mount patch installed now, without >> > > nocache and reduced arc reclaim settings (100, 1). I will check the >> > > runtime for the next 2 days. >> > >> > 9-10h runtime with the above settings (compared to 4h with nocache >> > and 12-24h without any patch and without nocache). >> > I changed the sysctls back to the defaults and will see in the next >> > run (in 7h) what the result is with just the patches. >> >> And again 9-10h runtime (I've seen a lot of the find processes in the >> periodic daily run of those 22 jails in the state "*vnode"). Seems >> nocache gives the best perf for me in this case. > > Sorry for jumping in here - I've got a couple of questions: > - Will this also apply to nullfs read-only mounts? Or is it only in > case of writing "through" a nullfs mount that these problems are seen? > - Is it a problem also in 13, or is this "new" in -CURRENT? > > We're having weird and unexplained CPU spikes on several systems, even > after tuning geli to not use gazillions of threads. So far our > suspicion has been ZFS snapshot cleanups but this is an interesting > contender - unless the whole "read only" part makes it moot. For me this started after creating one more jail on this system and I=20=20 dont't=20see CPU spikes (as the system is running permanently at 100%=20=20 and=20the distribution of the CPU looks as I would expect it). The=20=20 experience=20of Doug is a little bit different, as he experiences a high=20= =20 amount=20of CPU usage "for nothing" or even a dead-lock like situation.=20= =20 So=20I would say we see different things based on similar triggers. The nocache option for nullfs is affecting the number of vnodes in use=20= =20 on=20the system no matter if ro or rw. As such you can give it a try.=20=20 Note,=20depending on the usage pattern, the nocache option may increase=20= =20 lock=20contention. So it may or may not have a positive or negative=20=20 performance=20impact. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_M0tS0UKMgrrriOAIvn4fVPG Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmJnjhAACgkQEg2wmwP4 2IY0Ew/+MAgJ6GkpOD+3jmRxFznSmnIGyVgOHVb6+vt+iuFXanPrNwKMutkHOsqz mFXMYfgyC7sCyC0zu6SMF0Tdv9b6JOb8TzSoyujjvLbdVAWL7ccozgFslQLyCGtk VFKmS+oB1/3gWQp3NwnrHdNVFxCfrqUcIGjJ+aKHP1hVi6LD9S0OYljQiys9ZKCI 90q8PCDd9qPl4vA3XGTmAqBpWYD3blYeTQNwl/YmH381pc6Sul5jD86QDETrCZUR LdCqukhtL7qdoSyJnHU4mSM+iXIynDGsBtid7z20YLTqrsrwWC3Oo8UtY8enkA67 mxBw4HBWxLHt1CU/YJ5Wc4wF2NIumCuM/F6xJmio4ZMWLfHBnQQuBO0HpYFstb09 yBGdfhVHYZcfSlVGjjGZ8vpoYO9js5yj3OPjgOXztjWsu1EZ0RFwSoVs0LRHgCdD lj4gpW0OVIn0pOZBLB2zfDIOrv4mBoXEJ8mShpqrKS1Mb6Hz0yFxCUvL8wxUSwZY AVQzASquJcFp1bm6NZsRx98gXPHCssiY9M+8P5CKTGj4Fi+NTBq204s9uqY+Ze8G /jCv1Kdm1jvteelZnKIdugFQk8eNJF1LzFkshIaq8YrByHkk1wqm4Mfjup6DG42T 5/iKqZStd4V5TTCMba8AhAYMI4Sel5RT1Utn951sWrqHRwdcL/A= =gYPL -----END PGP SIGNATURE----- --=_M0tS0UKMgrrriOAIvn4fVPG-- From nobody Tue Apr 26 07:14:19 2022 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 49E3A1A9FFA5 for ; Tue, 26 Apr 2022 07:14:23 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (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 4KnY6627C0z3MhG; Tue, 26 Apr 2022 07:14:22 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 0599AF; Tue, 26 Apr 2022 09:14:19 +0200 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 \(3696.80.82.1.1\)) Subject: Re: Cross-compile worked, cross-install not so much ... From: "Patrick M. Hausen" In-Reply-To: Date: Tue, 26 Apr 2022 09:14:19 +0200 Cc: Brooks Davis , "freebsd-current@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <68DCDD88-F7EB-4904-AAD6-D15ED3FF4259@hausen.com> References: <3D48BE93-7D42-4AB2-82D4-88BBF4E1FD40@hausen.com> <20220425191823.GA89506@spindle.one-eyed-alien.net> <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.com> To: Warner Losh X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4KnY6627C0z3MhG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pmh@hausen.com has no SPF policy when checking 217.29.33.228) smtp.mailfrom=pmh@hausen.com X-Spamd-Result: default: False [-0.46 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hausen.com]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.50)[-0.504]; NEURAL_HAM_MEDIUM(-0.36)[-0.361]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi all, > Am 25.04.2022 um 21:54 schrieb Warner Losh : > Cross installing is supported. Native installing of a cross build = world isn't. >=20 > When I've had to do this in the past, I've just mounted the embedded = system on my > beefy server under /mumble (allowing root on the embedded system for = NFS) and did > a sudo make installworld ... DESTDIR=3D/mumble. Though I've forgotten = the gymnastics > to do etcupdate/mergemaster this way. I'll try that tonight, thanks. How do you get chflags to work over NFS? Kind regards, Patrick= From nobody Tue Apr 26 13:59:02 2022 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 4BF4E1AB4144 for ; Tue, 26 Apr 2022 13:59:08 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (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 4Knk566r0Kz3F3B for ; Tue, 26 Apr 2022 13:59:06 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 1ED161; Tue, 26 Apr 2022 15:59:03 +0200 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 \(3696.80.82.1.1\)) Subject: Re: Cross-compile worked, cross-install not so much ... From: "Patrick M. Hausen" In-Reply-To: <68DCDD88-F7EB-4904-AAD6-D15ED3FF4259@hausen.com> Date: Tue, 26 Apr 2022 15:59:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <40C559A4-6D1C-48EB-A4AF-3240717C2A13@hausen.com> References: <3D48BE93-7D42-4AB2-82D4-88BBF4E1FD40@hausen.com> <20220425191823.GA89506@spindle.one-eyed-alien.net> <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.com> <68DCDD88-F7EB-4904-AAD6-D15ED3FF4259@hausen.com> To: "freebsd-current@freebsd.org" X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4Knk566r0Kz3F3B X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pmh@hausen.com has no SPF policy when checking 217.29.33.228) smtp.mailfrom=pmh@hausen.com X-Spamd-Result: default: False [-0.34 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hausen.com]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_SPAM_LONG(0.26)[0.264]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi all, I just threw a bit of hardware at the problem for now. In addition to the seven-node TuringPi that I would like to run with FreeBSD after I cannot make Raspbian run stable even when completely idle I have another actively cooled single CM3+ system (the "pi8" you saw in my first post) So I connected a USB powered SSD and compile on the Pi now. System is CPU bound, so no bottleneck because of USB: -------- CPU: 95.4% user, 0.0% nice, 4.5% system, 0.1% interrupt, 0.0% idle Mem: 395M Active, 95M Inact, 384K Laundry, 224M Wired, 97M Buf, 187M = Free Swap: 4096M Total, 27M Used, 4069M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU = COMMAND 39861 root 1 100 0 248M 162M CPU0 0 0:55 96.39% = c++ 39867 root 1 86 0 124M 54M CPU1 1 0:06 96.34% = c++ 39865 root 1 87 0 124M 56M RUN 2 0:07 91.54% = c++ 39863 root 1 99 0 224M 138M RUN 3 0:45 83.17% = c++ -------- I'd rather run 13.1 and use freebsd-update, but 13 does not support the = CM3(+). That was in fact the first not so pleasant surprise - thought, ARM64 was = tier 1, now? Anyway, if -current works for now, there will be a 14.0-RELEASE, = eventually. Thanks for your help, folks. Patrick= From nobody Tue Apr 26 20:17:02 2022 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 030B31AB11AF for ; Tue, 26 Apr 2022 20:17:10 +0000 (UTC) (envelope-from 0100018067852db2-d5d49468-de3a-4c53-93c2-511b8d707a34-000000@amazonses.com) Received: from a8-25.smtp-out.amazonses.com (a8-25.smtp-out.amazonses.com [54.240.8.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KntTK2MFPz4WZ6 for ; Tue, 26 Apr 2022 20:17:09 +0000 (UTC) (envelope-from 0100018067852db2-d5d49468-de3a-4c53-93c2-511b8d707a34-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1651004223; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=2JFpswFE5OtZEkKoGjiawTbBMKOFNXov35dgXQc+kRM=; b=D4K6Nw8E0oXK9tQ2MxG5WOSuTbHHzMrZep4jIThxV6EE054ja6yGIqPyzW0B19ZI 7ysKv6T1gskI9mxm32UdB4diZcJEH+I64muL52FEWkveZNghi+naiD9x8bjtiGkUaHS G8FKayBVHnAsAlZT4+b7g3X6YruzWTbhrdFEvM7I= Message-ID: <0100018067852db2-d5d49468-de3a-4c53-93c2-511b8d707a34-000000@email.amazonses.com> Date: Tue, 26 Apr 2022 20:17:02 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: [FIXED] Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> From: Thomas Laus In-Reply-To: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES X-SES-Outgoing: 2022.04.26-54.240.8.25 X-Rspamd-Queue-Id: 4KntTK2MFPz4WZ6 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=D4K6Nw8E; dmarc=none; spf=pass (mx1.freebsd.org: domain of 0100018067852db2-d5d49468-de3a-4c53-93c2-511b8d707a34-000000@amazonses.com designates 54.240.8.25 as permitted sender) smtp.mailfrom=0100018067852db2-d5d49468-de3a-4c53-93c2-511b8d707a34-000000@amazonses.com X-Spamd-Result: default: False [-0.28 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[acm.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.997]; DKIM_TRACE(0.00)[amazonses.com:+]; NEURAL_HAM_SHORT(-0.58)[-0.580]; RCVD_IN_DNSWL_NONE(0.00)[54.240.8.25:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[lausts@acm.org,0100018067852db2-d5d49468-de3a-4c53-93c2-511b8d707a34-000000@amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; RWL_MAILSPIKE_POSSIBLE(0.00)[54.240.8.25:from]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14618, ipnet:54.240.8.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,0100018067852db2-d5d49468-de3a-4c53-93c2-511b8d707a34-000000@amazonses.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 4/11/22 11:17, Dennis Clarke wrote: > > Did the usual git pull origin main and buildworld/buildkernel but after > installkernel the machine will not boot. > > The rev seems to be main-n254654-d4e8207317c. > > I can boot single user mode and get a command prompt but nothing past > that. Is there something borked in ZFS in CURRENT ? > Group: Everything is running back to normal for me today after my weekly build of MAIN. My combination of EFI, GELI and ZFS are working for me after: FreeBSD 14.0-CURRENT #1 main-n255058-fa8a6585c75: Tue Apr 26 12:13:10 EDT 2022 It looks like another update to something else fixed the "no pools available to import" issue Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From nobody Tue Apr 26 21:18:39 2022 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 C43A91997D00 for ; Tue, 26 Apr 2022 21:19:02 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Knvrk00rxz4jKZ for ; Tue, 26 Apr 2022 21:19:01 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.956, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -1.86, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 23QLIdBr015777 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [10.14.0.14] (static-198-54-132-73.cust.tzulo.com [198.54.132.73]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 23QLIdBr015777 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 26 Apr 2022 17:18:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1651007929; bh=ZBzUbNmsFoR5p9kaeTPMefeTkV654aZmGg/vlwo9TAU=; h=Date:Subject:To:References:From:In-Reply-To:From; b=h946TfzXNLkJSaRLg7yKyEr3qpq8/oMzPISf7dSr0GYvOGm2hzERcLQWaDv9dUGR1 uLcInrcE9iZ+BzgqWksU8okUCvyPhmSR9+E30R5N1IRb40gdGYYdjWGP2neuGbDAJm T7I5KnWrJq41eNEiVsrdjVrf8uXXdSxO0fGcsRLPIEEAGTOIMYV+Fu9D2eKRhIlKxi cgQ0Aso/ed+Oej88FIh2HNplz8M7SX5HMsUb3fp6JBU7BDv6KNtithrYHOWG/qozeY z0lK7vRBSUizTuLjVySB/9GIFMiczSJuuwMv38/OD5s9xoYImopEYwyp2mk8ML3W5i ULntFFOtPEIRA== Message-ID: Date: Tue, 26 Apr 2022 17:18:39 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [FIXED] Re: main-n254654-d4e8207317c results in "no pools available to import" Content-Language: en-US To: freebsd-current@freebsd.org References: <778a795c-5413-9c79-5312-e34dd6bb29c1@blastwave.org> <0100018067852db2-d5d49468-de3a-4c53-93c2-511b8d707a34-000000@email.amazonses.com> From: Dennis Clarke In-Reply-To: <0100018067852db2-d5d49468-de3a-4c53-93c2-511b8d707a34-000000@email.amazonses.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Knvrk00rxz4jKZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=h946TfzX; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[blastwave.org:+]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/26/22 16:17, Thomas Laus wrote: > On 4/11/22 11:17, Dennis Clarke wrote: >> >> Did the usual git pull origin main and buildworld/buildkernel but >> after installkernel the machine will not boot. >> >> The rev seems to be main-n254654-d4e8207317c. >> >> I can boot single user mode and get a command prompt but nothing past >> that. Is there something borked in ZFS in CURRENT ? >> > Group: > > Everything is running back to normal for me today after my weekly build > of MAIN.  My combination of EFI, GELI and ZFS are working for me after: > > FreeBSD 14.0-CURRENT #1 main-n255058-fa8a6585c75: Tue Apr 26 12:13:10 > EDT 2022 > > It looks like another update to something else fixed the "no pools > available to import" issue > Same here : FreeBSD phobos 14.0-CURRENT FreeBSD 14.0-CURRENT #7 main-n255054-67fc95025cc: Tue Apr 26 06:58:45 UTC 2022 root@phobos:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400057 1400057 Somethng "magic" has changed and whatever that was it fixed the EFI boot issue. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From nobody Wed Apr 27 08:37:04 2022 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 B5B751995605 for ; Wed, 27 Apr 2022 08:37:25 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpBvS1tvKz3HdQ; Wed, 27 Apr 2022 08:37:24 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 74A6C10A1E8F; Wed, 27 Apr 2022 10:37:15 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 5F9F110A1E87; Wed, 27 Apr 2022 10:37:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1651048633; 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=4pJGh3mwZwFkcRRLQ8QoC3B8zCBp8ynykIB1jQ96WLc=; b=WNA4lfhy0mr3dEfc2yYba/X8ihdp0lbuXtQBc4pao5W2r4GCfDaMKHLA8gzzOzrNokDqPW +1mn22UGRd9PKTK22BDWeHNS3PBTq5+vOYjgqyyEeU53xLYuUrk+qL9HaOuNftf9hlu6vB XPueJIqZl3Y+RyTHoxe9z9FSxeNagTGOQIYS0avgMVP4kZowlbecxk3KvkueFj1M3AjjF1 CAG2W6Y82OtIQjajj5XQgrzSJQLrD5R7VfMrTxxB6mUJNkyDb0uky7/R/AF4FIJ0aRmyxb t4Jg4Jjnks3BsD8PzmvFVDeiNuHjmN94cvyNbuazFpDF50PdotwayTKTSFdRxg== Received: from freyja (p4fc0ad29.dip0.t-ipconnect.de [79.192.173.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 0E66B10A32F4; Wed, 27 Apr 2022 10:37:12 +0200 (CEST) Date: Wed, 27 Apr 2022 10:37:04 +0200 From: FreeBSD User To: Ed Maste Cc: Jens Schweikhardt , freebsd-current Subject: Re: CURRENT: can't build 13-STABLE anymore: cp: [vdso]: No such file or directory *** Error Message-ID: <20220427103704.3da33d00@freyja> In-Reply-To: References: <20220401145257.7317e887@freyja> <829437267.9678947.1648821610373.JavaMail.zimbra@schweikhardt.net> <20220401180409.6f4468ae@thor.intern.walstatt.dynvpn.de> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: d687ce X-Rspamd-UID: 26fb30 X-Rspamd-Queue-Id: 4KpBvS1tvKz3HdQ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=WNA4lfhy; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-0.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.90)[0.896]; NEURAL_HAM_LONG(-0.99)[-0.995]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[79.192.173.41:received] X-ThisMailContainsUnwantedMimeParts: N On Fri, 1 Apr 2022 12:09:21 -0400 Ed Maste wrote: > On Fri, 1 Apr 2022 at 12:04, FreeBSD User wrote: > > > > I tried the patch given at the URL above (Phabricator). Patch applied on > > recent CURRENT and trying to "make installworld" leaves me with this error, > > see bewlo. What I'm doing weong here? > > You're not doing anything wrong, I had another bug in the version of > the patch you tried. I've updated Phabricator again, please try again. > Hello, sorry for the very late response. After the commit, everything on CURRENT was all right and worked as expected. Many thanks for the fast response! Kind regards, O. Hartmann From nobody Wed Apr 27 08:59:03 2022 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 6468C199A329 for ; Wed, 27 Apr 2022 08:59:17 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpCNh2j34z3LPj for ; Wed, 27 Apr 2022 08:59:16 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 2932810A1E95; Wed, 27 Apr 2022 10:59:15 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 0C4D110A1E87; Wed, 27 Apr 2022 10:59:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1651049945; 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=W+65uYXTh5JD8mYobk/OqfNfGbOFpAUjXTtzda6NIR8=; b=hsR53yqOH+MbLnF2O3sTOVI9FqMb8ott0lYPfUNbyFMH0dJ35qo2y+Zt7sjlpD5Wa+Ir3L +BAeRaJtPDAZG85otAhHDJsUPUGz1x9R8Pbk/ZFbjiDQxGO9wzENGOeok3c5MBJ2IhN80s XldgaAM08ld46F/wb0d1oyzadxMft1jH7qfvnkoLPlndq6uhLTfmPujpKzQsTkFfIomuPb /R4ivvPEdS2SlDlRG2e+uFnmQWTmjKJgnUsOJnD6kYQOR65Vmy+eZdnoTxhnb/9H5/8JXk orsSwUFP5tSVjWUKlgnXvONNypd6yTTiKVTGZh6nB/2q3uhf2nvhv1l89xdhmw== Received: from freyja (p4fc0ad29.dip0.t-ipconnect.de [79.192.173.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id BC85110A1E91; Wed, 27 Apr 2022 10:59:04 +0200 (CEST) Date: Wed, 27 Apr 2022 10:59:03 +0200 From: FreeBSD User To: Warner Losh Cc: freebsd-current Subject: Re: 13-STABLE: can not cross build 13.0-RELENG and 13.1-RELENG, what on CURRENT works fine Message-ID: <20220427105903.11da08de@freyja> In-Reply-To: References: <20220419134455.1208de31@freyja> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 0b8877 X-Rspamd-UID: 227e59 X-Rspamd-Queue-Id: 4KpCNh2j34z3LPj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=hsR53yqO; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.46 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.66)[-0.664]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[79.192.173.41:received] X-ThisMailContainsUnwantedMimeParts: N On Tue, 19 Apr 2022 06:48:04 -0600 Warner Losh wrote: Hello again, I'm on 13-STABLE, version FreeBSD 13.1-STABLE #30 stable/13-n250552-364a69a529b: Tue Apr 26 07:32:42 CEST 2022 amd64 (builder host). Sources for a NanoBSD of 13.0-RELENG (latest as of today) doesn't build, still the reported [vdso] error (see below). > The vdso error is fixed by cherry-picking > b3b462229f972e2ed24d450d7d2f8855cdd58a87. Still does not build. > I'm not sure about the second error, though if it's a general profile > error, you make need WITHOUT_PROFILE=t in both the build and install phases. This is now working on the above reported builder host version. The key was, indeed, setting WITHOUT_PROFILE=t. Thank you for the hint. On CURRENT I can build both, 13.0-RELENG and 13.1-RELENG without issues. Kind regards, Oliver Hartmann > > > On Tue, Apr 19, 2022 at 5:46 AM FreeBSD User wrote: > > > I regular build for a NanoBSD appliance 13-STABLE, 13.0-RELENG and > > 13.1-RELENG > > on either 14-CURRENT and 13-STABLE. Several days ago, some changes has been > > made to /usr/src/Makefile.inc1, first on CURRENT and shortly after on 13. > > > > As with today, building from sources either 13.1-RELENG and 13.0-RELENG on > > a > > CURRENT host (recent 14-CURRENT!) works without problems. > > > > On 13-STABLE (FreeBSD 13.1-STABLE #26 stable/13-n250478-bb8e1dfbff3: Thu > > Apr 14 > > 10:47:51 CEST 2022 amd64) building either 13.0-RELENG or 13.1-RELENG fails! > > > > On building from sources 13.0-RELENG I receive while in installworld: > > > > [...] > > -------------------------------------------------------------- > > >>> Install check world > > -------------------------------------------------------------- > > mkdir -p /tmp/install.6R4Ifq8o > > ... > > cp: [vdso]: No such file or directory > > *** Error code 1 > > [...] > > > > and on building from sources 13.1-RELENG while in installworld we get: > > > > [...] > > ===> usr.bin/lex/lib (install) > > install -l h -o root -g wheel -m 444 > > > > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/lib > > ln_p.a > > > > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a > > install: link > > /home/ohartmann/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libln_p.a > > -> /home/ohartman > > > > n/Projects/TEST/fbsd13.1-dev/os-base/systemconf/../../world/amd64/TEST-DEV-amd64-13.1-RELENG/_.w/usr/lib/libl_p.a: > > No such file or directory > > *** Error code 71 > > > > > > Thanks in advance, > > > > O. Hartmann > > > > From nobody Wed Apr 27 12:23:24 2022 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 56D18199BB6E for ; Wed, 27 Apr 2022 12:24:00 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpHwv3mMHz4XZD for ; Wed, 27 Apr 2022 12:23:59 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 23RCNU9M021698 for ; Wed, 27 Apr 2022 08:23:53 -0400 Received: from w92expo29.exchange.mit.edu (18.7.74.41) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Wed, 27 Apr 2022 08:22:28 -0400 Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by w92expo29.exchange.mit.edu (18.7.74.41) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 27 Apr 2022 08:23:24 -0400 Received: from OC11EXPO29.exchange.mit.edu ([18.9.4.102]) by oc11expo29.exchange.mit.edu ([18.9.4.102]) with mapi id 15.00.1497.023; Wed, 27 Apr 2022 08:23:24 -0400 From: John F Carr To: "freebsd-current@freebsd.org" Subject: Can't build with INVARIANTS but not WITNESS Thread-Topic: Can't build with INVARIANTS but not WITNESS Thread-Index: AQHYWjGXMPjuwHsIuU6J79kbYfEoxg== Date: Wed, 27 Apr 2022 12:23:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [108.7.221.50] Content-Type: text/plain; charset="us-ascii" Content-ID: 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 X-Rspamd-Queue-Id: 4KpHwv3mMHz4XZD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=mit.edu; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.58 as permitted sender) smtp.mailfrom=jfc@mit.edu X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.58:from]; DMARC_POLICY_ALLOW(-0.50)[mit.edu,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N My -CURRENT kernel has INVARIANTS (inherited from GENERIC) but not WITNESS: include GENERIC ident STRIATUS nooptions WITNESS nooptions WITNESS_SKIPSPIN My kernel build fails: /usr/home/jfc/freebsd/src/sys/kern/vfs_lookup.c:102:13: error: variable 'li= ne' set but not used [-Werror,-Wunused-but-set-variable] int flags, line __diagused; ^ /usr/home/jfc/freebsd/src/sys/kern/vfs_lookup.c:101:14: error: variable 'fi= le' set but not used [-Werror,-Wunused-but-set-variable] const char *file __diagused; The problem is, __diagused expands to nothing if INVARIANTS _or_ WITNESS is= defined, but the variable in vfs_lookup.c is only used if WITNESS is defin= ed. #if defined(INVARIANTS) || defined(WITNESS) #define __diagused #else #define __diagused __unused #endif I think this code is trying to be too clever and causing more trouble than = it prevents. Change the || to &&, or replace __diagused with __unused ever= ywhere. From nobody Wed Apr 27 13:31:48 2022 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 4E5DD1AB59C1 for ; Wed, 27 Apr 2022 13:31:56 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpKRH4H81z4pMp for ; Wed, 27 Apr 2022 13:31:55 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-e93bbb54f9so1902432fac.12 for ; Wed, 27 Apr 2022 06:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f/fRaaPBbd394gdhnhSbzDJdKxRj988axutF2Tzrar8=; b=Z7kiDxg7ujWvZRiiPlw4LTknErHJd1RQU5+Fk1d/se93aM508JNscoG56NEhnT8zDi vgYpprTeLx7RvMft04NxC1JhGWyslFwZn5pd9ARuCupu0bz1JJZffDUX0MELtVvtSYTZ 100XLSah1IrACKbUAsX2BbG15TIzWbqo+m8Oi3cq9A/WycJPd0eGbgfy/mDWy1l1nO0w l9fEZ23UvMvNSvSd00msDBzQO6AesMtpqiDUEu+i/tOtsWnuNNg606fDpGoGM0iTJBYf ZiEeJglAE4HgSaal66YSpwgvaB5RWJ2Swg1Ruq+N8ZoUjrcxjVTfpu5gDzWsOSp1judF wtSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f/fRaaPBbd394gdhnhSbzDJdKxRj988axutF2Tzrar8=; b=OZvq9GsHCYrh61JrhU3fClQYB189FR/ZQM0xM9a4mr0TnVwxGCCn2Sek0qlR9AcbvM aRwsNTGWgWaCsy2fRrVhRBlY4R9LJR57I1RCI+VCUhkko/wVgQFpahA0+UdrfQ9FgKTg EMnPS2HYyWSJu5yKnaxrocEJ7TAeC0f/0drWJnXA9xdF+A3+I9p4hqD4C58D7k0PsvIF 1IYTSmsAHLKk+09NbH1SAiljsJuq1QIIcttrlPx0lxtMJUxIx7yQRh9c8zu6cNjXMGLb VoneVTMiNBPtvooAGkxrtAaNPeAHRX33lTRVKv6vrQGiWFkO+TtUCPcDpcE5z0Vk9XjE wyUA== X-Gm-Message-State: AOAM5324aoStclv3/mL+Q7EEp+A/0KblP5a8DVAOE/JE22jW26SpLgbV 2Wfm70Aw7lqeE58kXj2eQ+JWIbxh9m0dPDoRaLohAjrs X-Google-Smtp-Source: ABdhPJwy2JqTN73yaUtZs+/FNe8a8kZCghLorbQUui8HdZefor5cVEyvZycEAR4MNjd/wZhe4eDOI649Nn21qhhz4lM= X-Received: by 2002:a05:6870:d288:b0:e9:257d:db3f with SMTP id d8-20020a056870d28800b000e9257ddb3fmr8209478oae.96.1651066309042; Wed, 27 Apr 2022 06:31: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 Received: by 2002:a8a:d82:0:b0:422:d8ed:35a0 with HTTP; Wed, 27 Apr 2022 06:31:48 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Wed, 27 Apr 2022 15:31:48 +0200 Message-ID: Subject: Re: Can't build with INVARIANTS but not WITNESS To: John F Carr Cc: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KpKRH4H81z4pMp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Z7kiDxg7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2001:4860:4864:20::33 as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-2.03 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(0.97)[0.969]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::33:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/27/22, John F Carr wrote: > My -CURRENT kernel has INVARIANTS (inherited from GENERIC) but not WITNESS: > > include GENERIC > ident STRIATUS > nooptions WITNESS > nooptions WITNESS_SKIPSPIN > > My kernel build fails: > > /usr/home/jfc/freebsd/src/sys/kern/vfs_lookup.c:102:13: error: variable > 'line' set but not used [-Werror,-Wunused-but-set-variable] > int flags, line __diagused; > ^ > /usr/home/jfc/freebsd/src/sys/kern/vfs_lookup.c:101:14: error: variable > 'file' set but not used [-Werror,-Wunused-but-set-variable] > const char *file __diagused; > > The problem is, __diagused expands to nothing if INVARIANTS _or_ WITNESS is > defined, but the variable in vfs_lookup.c is only used if WITNESS is > defined. > > #if defined(INVARIANTS) || defined(WITNESS) > #define __diagused > #else > #define __diagused __unused > #endif > > I think this code is trying to be too clever and causing more trouble than > it prevents. Change the || to &&, or replace __diagused with __unused > everywhere. > I disagree. The entire point is to not end up with actually unused variables even when is enabled. I patched it up in https://cgit.FreeBSD.org/src/commit/?id=b40c0db6f6d61ed594118d81dc691b9263a7e4d7 . This still allows for actually vars when only one of INVARIANTS or WITNESS is defined, but that's a much smaller problem than allowing it in general. -- Mateusz Guzik From nobody Wed Apr 27 18:23:26 2022 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 D604C1AB351E for ; Wed, 27 Apr 2022 18:23:27 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpRvg5Wp0z4ndt; Wed, 27 Apr 2022 18:23:27 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651083807; 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=GP/bP5K3Dt3FSURWtu2Juqb7LdbZcIks6/XgsRPkMrI=; b=r7j5MqkJEheJaxh5KKqvIQyk5I+iriF8PeEmZ3gvKmmhPWf0e6LAuWpQBvt+r2GDmegVxm 0C3gNKvmH0OfGvvr86/SuWgRrmqhD8jaz2skQ/hg0g6IwP0d3qITLJmFhEiub3Zz7p2HHt RM0wBVd8FkvwBiknzzYy8VS/YVePVWCF1Q2+xyYL2cF7k+bDcR/8e/AteX3efjcyCfgRaC 6pW5DW1nR8k1ij1E/haKzGBP4zQ3U1n2d49v1AplD2+8GBIu3Wn5r6U/UIyal5UDuJd2Oz K1khxS7I/kQyZUjE1H2t7RUMaTv58XGjbFsT6Ld6BkF6Xl+SnlTQj0xZReZ9Sw== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 27130B84C; Wed, 27 Apr 2022 18:23:27 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <80c36da0-6430-5727-375f-680c8343a37c@FreeBSD.org> Date: Wed, 27 Apr 2022 11:23:26 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: 'set but unused' breaks drm-*-kmod Content-Language: en-US To: Emmanuel Vadot , Michael Butler Cc: freebsd-current References: <263e16c4-0634-88e6-9652-50d0874f027e@protected-networks.net> <20220421094236.3f023ac540666c140c04f884@bidouilliste.com> <20220421154555.8a69a542d97d6cf36472b75f@bidouilliste.com> From: John Baldwin In-Reply-To: <20220421154555.8a69a542d97d6cf36472b75f@bidouilliste.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651083807; 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=GP/bP5K3Dt3FSURWtu2Juqb7LdbZcIks6/XgsRPkMrI=; b=bbE0YZGF/JB9SxvzwTysF5HSZO5W/8RVBLuEL1OH7SM6ukxjjUe/t5d8PNn+YS2myZZriH hoq0ZHGPCDzFV/dehjTovh+FzmEty27l42DQ/7C6MwokYvCfJ6ULbX6HHkKouUIWcUa3fZ 2QoABLHkU99be7M1+2VAdVVMoRJoeAR8RhfZkFojJC8nLKBTDToqfp5exom5y28VIZaHVe neaMX7XAPPF0LeYe5MQqLwZCi8Q9qp6Q2RPd+gF118s1yg0m7GxPA+afGCQ6ouDPg9xSfi uAPMRF9fVTa3oC71fQanBVGSZYmDtgwNCzDWMzXUH23o4OP2pnQBEaD7gxeZ9Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651083807; a=rsa-sha256; cv=none; b=bqNFBsx8DDMruIaSLGtKhgUaOvNDB3bmrghWtU+ZxkZzjfrQqdqsKQckBBh5MxrMyycpOt 4F6phZZzPG2pDNT4QkTVUXr0P0iWbHlvVw/kENSAyPborISesZQEAk0mMRGg76N3z8ldXq JMvGhAQ365Xi2383jhBUUU4Y3QnMQfjHfNYRWiMyFdPqQeo08GlvqrNNfQ2QtZ3/5FeoU7 kircSvZzB95tELl3GohoxBFGTF3IJxgIP+km2cTmBMCV9Y4psRbkWZbpTt/H5kHFY2G96e +aNF9o5xp2xb9dp2u82pw3yFSdWPKa7+JBLoEAqDcc5y+sFM250RSw44K6X3lQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 4/21/22 6:45 AM, Emmanuel Vadot wrote: > On Thu, 21 Apr 2022 08:51:26 -0400 > Michael Butler wrote: > >> On 4/21/22 03:42, Emmanuel Vadot wrote: >>> >>> Hello Michael, >>> >>> On Wed, 20 Apr 2022 23:39:12 -0400 >>> Michael Butler wrote: >>> >>>> Seems this new requirement breaks kmod builds too .. >>>> >>>> The first of many errors was (I stopped chasing them all for lack of >>>> time) .. >>>> >>>> --- amdgpu_cs.o --- >>>> /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26: >>>> error: variable 'priority' set but not used >>>> [-Werror,-Wunused-but-set-variable] >>>> enum drm_sched_priority priority; >>>> ^ >>>> 1 error generated. >>>> *** [amdgpu_cs.o] Error code 1 >>>> >>> >>> How are you building the port, directly or with PORTS_MODULES ? >>> I do make passes on the warning for drm and I did for set-but-not-used >>> case but unfortunately this option doesn't exists in 13.0 so I couldn't >>> apply those in every branch. >> >> I build this directly on -current. I'm guessing that these are what >> triggered this behaviour: >> >> commit 8b83d7e0ee54416b0ee58bd85f9c0ae7fb3357a1 >> Author: John Baldwin >> Date: Mon Apr 18 16:06:27 2022 -0700 >> >> Make -Wunused-but-set-variable a fatal error for clang 13+ for >> kernel builds. >> >> Reviewed by: imp, emaste >> Differential Revision: https://reviews.freebsd.org/D34949 >> >> commit 615d289ffefe2b175f80caa9b1e113c975576472 >> Author: John Baldwin >> Date: Mon Apr 18 16:06:14 2022 -0700 >> >> Re-enable set but not used warnings for kernel builds. >> >> make tinderbox now passes with this warning enabled as a fatal error, >> so revert the change to hide it in preparation for making it fatal. >> >> This reverts commit e8e691983bb75e80153b802f47733f1531615fa2. >> >> Reviewed by: imp, emaste >> Differential Revision: https://reviews.freebsd.org/D34948 >> >> > > Ok I see, > > I won't have time until monday (maybe tuesday to fix this) but if > someone wants to beat me to it we should add some new CWARNFLAGS for > each problematic files in the 5.4-lts and 5.7-table branches of > drm-kmod (master which is following 5.10 is already good) only > if $ {COMPILER_VERSION} >= 130000. There is already a helper you can use that deals with compiler versions: CWARNFLAGS+= ${NO_WUNUSED_BUT_SET_VARIABLE} or some such. -- John Baldwin From nobody Wed Apr 27 19:59:58 2022 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 270D31AAA79D for ; Wed, 27 Apr 2022 20:00:18 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpV3P3vrSz3PhT for ; Wed, 27 Apr 2022 20:00:17 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd34.google.com with SMTP id e15so4446387iob.3 for ; Wed, 27 Apr 2022 13:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=8IbmDzrNt+TBKDBBshgjR56cCzXvNdzH/TO4VLTrzN4=; b=V+Cz0HlpOpYDFvc0O4apbAdGeU+f0EeVyoIn98LpYMcuoUmr2XEBDS3rTYedZ9j1ao NE5HpMpJMgx/fDOXdIc7O+6ccvjHb0yr3+RpBeKULEXf0G6OQLnOv4lGC3Yb8BsMHpVx PEQFJDRWlbVqpwFVE/quB3TKcr0duL26kYa9rW1lJgWhgflghvMs0DRylqjtdqb3DdzN 8Z9OLAFpVfV/+poUNY1/5IYLKt+RN0hx9FGjbahGHoOlMzyNBgr4jBPVOj5FhgFK5P08 IbHWuOohOL9MPO6O1Nx5gttYT6xW8pEo20LTrKAtFHzxuHFN29JhAcHtz7DY6WeIcRNY 3Fug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8IbmDzrNt+TBKDBBshgjR56cCzXvNdzH/TO4VLTrzN4=; b=md5S+u6jFzdgWO/fDrc9Mr6Of7kPVeGKWk4TRXpXIAbRwGwizN781ovj/Mk6Fh1LGq zcTpvj2xqN5NVlZswULTVUkuflRvtTn97VaPpvIRk4BnjiU8PnZ+d7cSkMVdRbKQMoTm bRRgQPvVK76vZXZG+HuabNM7D/VwpGKjLO3lky7JSJc7vZDPuSf0lr8JsQX4FU9RCZvM hWxKqw4jQSg9WWNCEtI/d4giLDF0J92nSZg+mejFIZNuKsJ+Jn8F1ni70qESUJEZ5ZTS jiftL7lny8yvGqNztOmgf7mc5lj7E6fC7B58k+sKVRH18Fj5sgicF12D0pGrvt7orRIk khtA== X-Gm-Message-State: AOAM532HoR14IH69pq8Hp6hmFGvYl7IxOAtczn8fJ8qCH+Ul49YbKu7h DMWWJQmBV1PcC9lt3m04ydMKEFMoWMWefixH8NAhj6g8SvNu5GEiev4= X-Google-Smtp-Source: ABdhPJxSIm2assN3y/r5hVobCZqsFG//RGIJgTp+wuxMHV4y3G3ZYYAC1CF4mNvkv6ILZTyVVt58YshndeL5dJTBlKQ= X-Received: by 2002:a02:950c:0:b0:323:918d:a98f with SMTP id y12-20020a02950c000000b00323918da98fmr12058981jah.190.1651089609633; Wed, 27 Apr 2022 13:00:09 -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: Michael Schuster Date: Wed, 27 Apr 2022 21:59:58 +0200 Message-ID: Subject: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory" To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KpV3P3vrSz3PhT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=V+Cz0Hlp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::d34 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-2.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d34:from]; NEURAL_SPAM_SHORT(0.99)[0.986]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Hi, $subject happened to me just now on current. I researched it on the internet, the answer to this issue seems to be a universal "uninstall and install the package" which seems to have worked in all cases I saw it suggested. I'm trying to embed this command into a script and would like to avoid manual intervention (I have to admit, this is the first time I've encountered this error in the two years I've been doodling with FreeBSD again) ... Is anything more known about this error behaviour, and what I can do to avoid it? TIA Michael PS: in case it matters: the full path shown in the error message is /usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG, the package being extracted is grantleetheme-22.04.0 -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From nobody Thu Apr 28 02:19:07 2022 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 3A8B41AACF1D for ; Thu, 28 Apr 2022 02:19:16 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpfSg5skLz3DwY for ; Thu, 28 Apr 2022 02:19:15 +0000 (UTC) (envelope-from 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 23S2J8lQ050791; Wed, 27 Apr 2022 19:19:14 -0700 (PDT) (envelope-from bsd-lists@bsdforge.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 Date: Wed, 27 Apr 2022 19:19:07 -0700 From: Chris To: Michael Schuster Cc: FreeBSD CURRENT Subject: Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory" In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <93f322eb1d99783e568262a5cd9f5fd9@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_77c3eeb30f402e6ca15386a0e1da841f" X-Rspamd-Queue-Id: 4KpfSg5skLz3DwY X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_77c3eeb30f402e6ca15386a0e1da841f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-04-27 12:59, Michael Schuster wrote: > Hi, > > $subject happened to me just now on current. I researched it on the > internet, the answer to this issue seems to be a universal "uninstall > and install the package" which seems to have worked in all cases I saw > it suggested. > > I'm trying to embed this command into a script and would like to avoid > manual intervention (I have to admit, this is the first time I've > encountered this error in the two years I've been doodling with > FreeBSD again) ... > Is anything more known about this error behaviour, and what I can do > to avoid it? > > TIA > Michael > > PS: in case it matters: the full path shown in the error message is > /usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG, > the package being extracted is grantleetheme-22.04.0 This looks more a case for the Maintainer of the GrantleeTheme than for current@ --=_77c3eeb30f402e6ca15386a0e1da841f Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_77c3eeb30f402e6ca15386a0e1da841f-- From nobody Thu Apr 28 03:40:10 2022 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 CBD631ABB320 for ; Thu, 28 Apr 2022 03:40:28 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KphGM4RT3z3Q4y for ; Thu, 28 Apr 2022 03:40:27 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x136.google.com with SMTP id k12so1212926ilv.3 for ; Wed, 27 Apr 2022 20:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uUud6bGV5JOTecx9ES3Ksw3U1c7oX16UFUuN3H9abRs=; b=QjR8zjs3/s3kCC9AcygFXbZLkeUID35WwDBMFGhRP1X+Lu+kZdqiptxy3WTTU4rTct 3KObcXmoQSE5VNd3+GgKd1+DPhVKS8wtTQpHoTtOLkq+lnuoa6nZ3LgZHWU4TIQrqOqO 139nrOFRG1P+WCn0dPmEg15xOQZLn2wX424RybzQ32sYug3Gr6o2lEJVsZxjKcWJcW16 6ELFTu1/dMJVJoXeYTQmCSXujZIY3PKSEbooqtwzrzcfPk3ABBJkJ7lhZqW4GnNLSrDE QtH2vvpEGmh7Y+vs1dIv9VMKBY0iV5hskxfQfwFaCqJ5zeGt8rEULk7p8zN2Xv4OWIwx 6DPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uUud6bGV5JOTecx9ES3Ksw3U1c7oX16UFUuN3H9abRs=; b=IdOq9qBzNF+hVIea0YvHMlIXEliVfJMIOd71Ca0Fxm7KwYWPj4P1PAWHDuCfl1utYq WtetddjFOGSAgnZ0VelVB3bRwdl19gNM8eqQ6T8ZXM4EKqCA4Ka9qvtEcHu9JaKbBSBk gAfQFn/a9R8rsVrDhWUrqThIg3hzFGlxbgMLl8bQzTe6JymiB/S/RTUVMi+jFddHr1hp w1uVfj/SqI9HL/oVuia0ZWGs0kusczICALRoexqjgivSOSUEbLwp2P1E+JdJTZ4muIQ6 FdSqqGZzRYs+3Ko37X0rVKMLiqkXPM80inPWrUP9tbPLpHt8MQ/5yFN2e3+DXPiFLySQ SwMQ== X-Gm-Message-State: AOAM530erqEnktI44YHr09ZmriW5pefnEyODjwkr/ZzDU7XOnRxdtmzJ iRl4q32WXhnWqZawmaVqHieIrsyUbj8HAjI/Szmj3+MOG6MblUg+86c= X-Google-Smtp-Source: ABdhPJw87CHb6PyLs9Ro4eIoSOJqrn8AlClgJ31OIxiHfQQdz2BMnS9L5lT2bb/C3SCP6V0PkzihdKT2ak7dCuvxDmM= X-Received: by 2002:a05:6e02:1ca9:b0:2cc:584c:40f4 with SMTP id x9-20020a056e021ca900b002cc584c40f4mr11728670ill.128.1651117221244; Wed, 27 Apr 2022 20:40:21 -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: <93f322eb1d99783e568262a5cd9f5fd9@bsdforge.com> In-Reply-To: <93f322eb1d99783e568262a5cd9f5fd9@bsdforge.com> From: Michael Schuster Date: Thu, 28 Apr 2022 05:40:10 +0200 Message-ID: Subject: Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory" To: Chris Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KphGM4RT3z3Q4y X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=QjR8zjs3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::136 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::136:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-0.98)[-0.984]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Chris, thx for your response. However .... On Thu, Apr 28, 2022 at 4:19 AM Chris wrote: > > On 2022-04-27 12:59, Michael Schuster wrote: > > Hi, > > > > $subject happened to me just now on current. I researched it on the > > internet, the answer to this issue seems to be a universal "uninstall > > and install the package" which seems to have worked in all cases I saw > > it suggested. > > > > I'm trying to embed this command into a script and would like to avoid > > manual intervention (I have to admit, this is the first time I've > > encountered this error in the two years I've been doodling with > > FreeBSD again) ... > > Is anything more known about this error behaviour, and what I can do > > to avoid it? > > > > TIA > > Michael > > > > PS: in case it matters: the full path shown in the error message is > > /usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG, > > the package being extracted is grantleetheme-22.04.0 > This looks more a case for the Maintainer of the GrantleeTheme than for > current@ ... maybe. OTOH, the instances I found mentioned on the 'net are all about different packages: eg: https://forums.freebsd.org/threads/pkg-upgrade-fail-to-create-temporary-file.67923/ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237767 I feel there's something different at work here than just one maintainer's oversight. Thx Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From nobody Thu Apr 28 03:47:26 2022 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 A08851ABCDA6 for ; Thu, 28 Apr 2022 03:47:33 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KphQY3Gfsz3hLv for ; Thu, 28 Apr 2022 03:47:33 +0000 (UTC) (envelope-from 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 23S3lQl3083232; Wed, 27 Apr 2022 20:47:32 -0700 (PDT) (envelope-from bsd-lists@bsdforge.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 Date: Wed, 27 Apr 2022 20:47:26 -0700 From: Chris To: Michael Schuster Cc: FreeBSD CURRENT Subject: Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory" In-Reply-To: References: <93f322eb1d99783e568262a5cd9f5fd9@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: <8364fbb11098ffb0799829972cc6a35d@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_f356684a356c22162284e9badfc307db" X-Rspamd-Queue-Id: 4KphQY3Gfsz3hLv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_f356684a356c22162284e9badfc307db Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-04-27 20:40, Michael Schuster wrote: > Chris, > > thx for your response. However .... > > On Thu, Apr 28, 2022 at 4:19 AM Chris wrote: >> >> On 2022-04-27 12:59, Michael Schuster wrote: >> > Hi, >> > >> > $subject happened to me just now on current. I researched it on the >> > internet, the answer to this issue seems to be a universal "uninstall >> > and install the package" which seems to have worked in all cases I saw >> > it suggested. >> > >> > I'm trying to embed this command into a script and would like to avoid >> > manual intervention (I have to admit, this is the first time I've >> > encountered this error in the two years I've been doodling with >> > FreeBSD again) ... >> > Is anything more known about this error behaviour, and what I can do >> > to avoid it? >> > >> > TIA >> > Michael >> > >> > PS: in case it matters: the full path shown in the error message is >> > /usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG, >> > the package being extracted is grantleetheme-22.04.0 >> This looks more a case for the Maintainer of the GrantleeTheme than for >> current@ > > ... maybe. OTOH, the instances I found mentioned on the 'net are all > about different packages: > > eg: > https://forums.freebsd.org/threads/pkg-upgrade-fail-to-create-temporary-file.67923/ > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237767 > > I feel there's something different at work here than just one > maintainer's oversight. You may well be correct. On the surface, to me it looked like a port problem so I thought you might get quicker results via it's maintainer. :-) Good luck! :-) > > Thx > Michael --=_f356684a356c22162284e9badfc307db Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_f356684a356c22162284e9badfc307db-- From nobody Thu Apr 28 07:11:40 2022 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 40E97199367B for ; Thu, 28 Apr 2022 07:11:44 +0000 (UTC) (envelope-from bapt@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kpmy81PyCz4bjq; Thu, 28 Apr 2022 07:11:44 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651129904; 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=DoOKkaag9N79Ntx/YTLkxrTzY8vMCsZzFktj7bgFhSs=; b=Cj/6HQzWgx3mxGjrA3EO+6J4Oi93Pakwp/nPOi3WP+grXjv93fT1eAevQV0NCDeRiyH/Ku lAZRWmVK8qjS9TXGukvdLvGC1EBlYtppfDBUZHiXzdnJ+wjZNPy10bqXp9ZWMRTjV4gvmM ss0uF0/mPVm4E4efy707mynneMQTjUh8rtGubuXT+u9CZ+EUsVm7kH15LJelcmBaqozOJ4 iyy5w8a7QkOWDt45sOvc/p4ollNHQhOiSPAGby313qFw8Qju0nwH5njyvo/E8shZp52P2c cl/7O45i6YvH56k3ML8lyaNUTae4yod9G6Yvh+Wjt2rSJyYkmJQDCzgGSQPRIg== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id F26F822A08; Thu, 28 Apr 2022 07:11:43 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id CF65EE889F; Thu, 28 Apr 2022 09:11:40 +0200 (CEST) Date: Thu, 28 Apr 2022 09:11:40 +0200 From: Baptiste Daroussin To: Chris Cc: Michael Schuster , FreeBSD CURRENT Subject: Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory" Message-ID: <20220428071140.iuydpxyuryqfs4c4@aniel.nours.eu> References: <93f322eb1d99783e568262a5cd9f5fd9@bsdforge.com> <8364fbb11098ffb0799829972cc6a35d@bsdforge.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: <8364fbb11098ffb0799829972cc6a35d@bsdforge.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651129904; 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=DoOKkaag9N79Ntx/YTLkxrTzY8vMCsZzFktj7bgFhSs=; b=GNKv1S8Te8EI6qlGfVQROMXBfIXYRpAYztSRf9Iv5cUQ4hdasV21fBfJ/TszrkJ279Qk2X g7HCRlX/YvOW7ceT/7d9DKfyKwQHV2HLASgl4msrlBMcw0RWWZojVAWr+2sZAxW+TEZBSy sHWa4FoHhXbM0vnWoE4Y7RAoLXDYunGKvQQyibuNUWcduK97ohAZSY2QR90Yfs5F3EdRwy +YMo/EIPItcAV0rLci8J9NS8LHg64pe4q0dzXOoByB8Xx8NoDFAoSgcM3iLX4vVSQnVOCH GgatyMCYS0p3WgN/vbaIbbUkf62D/5ZvUJx+30kCnw6RbA9w9wLUr0V2Aww19w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651129904; a=rsa-sha256; cv=none; b=KTDsMp4zHLnZk4pWiIqGY/yKswejfyMr3rYiVzxCpRBWXWwd6MDLZoaIi1dpTWYe2CQv4s KGExo96MCEQfT5mXvHplvwcOof8wb3RZ7AEUottsx9+HX5c8YIvNywWFGQm0UjYGKMt5H/ ud5mWEi9ybPBja82a+VRGUuOp03ZwKZKBOMEnw2TAm2WOjxoETHlsNnh+f9WSaWiJ7BQcM UftVvDSeXpdIHmG0nt5LscMzLMBgfF53CkWVkrxR6ozm+9RGehspC2d1hEETtYZanoTLaZ wekbjR1hV8ImWeFWCC22cUX0IQhVvtSdtb+ONMoWA9cH1rpZKtvVNsVf6oC8hQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Wed, Apr 27, 2022 at 08:47:26PM -0700, Chris wrote: > On 2022-04-27 20:40, Michael Schuster wrote: > > Chris, > > > > thx for your response. However .... > > > > On Thu, Apr 28, 2022 at 4:19 AM Chris wrote: > > > > > > On 2022-04-27 12:59, Michael Schuster wrote: > > > > Hi, > > > > > > > > $subject happened to me just now on current. I researched it on the > > > > internet, the answer to this issue seems to be a universal "uninstall > > > > and install the package" which seems to have worked in all cases I saw > > > > it suggested. > > > > > > > > I'm trying to embed this command into a script and would like to avoid > > > > manual intervention (I have to admit, this is the first time I've > > > > encountered this error in the two years I've been doodling with > > > > FreeBSD again) ... > > > > Is anything more known about this error behaviour, and what I can do > > > > to avoid it? > > > > > > > > TIA > > > > Michael > > > > > > > > PS: in case it matters: the full path shown in the error message is > > > > /usr/local/include/KF5/GrantleeTheme/GrantleeTheme/.pkgtemp.GenericFormatter.qSk5LxEaheWG, > > > > the package being extracted is grantleetheme-22.04.0 > > > This looks more a case for the Maintainer of the GrantleeTheme than for > > > current@ > > > > ... maybe. OTOH, the instances I found mentioned on the 'net are all > > about different packages: > > > > eg: > > https://forums.freebsd.org/threads/pkg-upgrade-fail-to-create-temporary-file.67923/ > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237767 > > > > I feel there's something different at work here than just one > > maintainer's oversight. > You may well be correct. On the surface, to me it looked like a port problem > so I thought > you might get quicker results via it's maintainer. :-) > > Good luck! :-) > > > > Thx > > Michael It is 2 things, it is a port problem of maintainers who do not check for upgradability of their packages, and it can also been seen as something pkg can deal with, but a complicated case, so I don't know yet how. The main issue is a file in vX which becomes a directory in vX+1 which goes in the way pkg does extract files to be as atomic as possible. Best regards, Bapt From nobody Thu Apr 28 08:43:55 2022 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 509341AAEA71 for ; Thu, 28 Apr 2022 08:44:03 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from smtp.burggraben.net (smtp.burggraben.net [88.198.69.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.burggraben.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kpq0f4Z9zz4nV6 for ; Thu, 28 Apr 2022 08:44:02 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from elch.exwg.net (elch.exwg.net [IPv6:2001:470:7120:1:127b:44ff:fe4f:148d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "elch.exwg.net", Issuer "R3" (not verified)) by smtp.burggraben.net (Postfix) with ESMTPS id A24BBC0182C; Thu, 28 Apr 2022 10:43:55 +0200 (CEST) Received: by elch.exwg.net (Postfix, from userid 1000) id 13C743AB27; Thu, 28 Apr 2022 10:43:55 +0200 (CEST) Date: Thu, 28 Apr 2022 10:43:55 +0200 From: Christoph Moench-Tegeder To: Michael Schuster Cc: FreeBSD CURRENT Subject: Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory" 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=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.3 (2022-04-12) X-Rspamd-Queue-Id: 4Kpq0f4Z9zz4nV6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of cmt@burggraben.net designates 88.198.69.140 as permitted sender) smtp.mailfrom=cmt@burggraben.net X-Spamd-Result: default: False [-3.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[cmt]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:88.198.69.140]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[burggraben.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[88.198.69.140:from]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.77)[-0.770]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.198.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N ## Michael Schuster (michaelsprivate@gmail.com): > $subject happened to me just now on current. I researched it on the > internet, Don't look that far, the answer is in UPDATING: 20220426: AFFECTS: users of deskutils/grantleetheme Regards, Christoph -- Spare Space From nobody Thu Apr 28 10:31:06 2022 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 BC3741992E45 for ; Thu, 28 Apr 2022 10:31:11 +0000 (UTC) (envelope-from se@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpsNH4mC0z3Jcm; Thu, 28 Apr 2022 10:31:11 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651141871; 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=j2ZXhIReSpvrvs36ZGLVZkTlH4gCTbf1w9GcM7+N5Ws=; b=m7EKb5OL1l9II/0sOUuyjBpLY/ImSQRAID67gpJHVmrmDM1KyA/gUzIWrS1psfRNdyfZWc +UE1rXIpySIfARi1OVTZp0POUTdU86jmNCEKepvd6sFVc7yOE2RKVZCIwwp5MG0eBp31s9 uvP5jOyAMZnZRBjAYs6S1tqozdNKQWzoF+QgYLoNCtJHL40IcTdxs/9OmieqWJHdwHZ/mq A2T7ep+3Kx06AMWRF2UHAUIGB03cwhWoqt0nUuOHEaj2uVwvnyUZC6iOZMe0URbqTqCrw9 Is+14Yk5h+2FCCPXz0OjZ1sjW79moDOjdA+bJ4FaklD0CKNyFkcW7Nbx08W8BQ== Received: from [IPV6:2003:cd:5f05:c200:503:1c91:5403:5264] (p200300cd5f05c20005031c9154035264.dip0.t-ipconnect.de [IPv6:2003:cd:5f05:c200:503:1c91:5403:5264]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id DB283243D0; Thu, 28 Apr 2022 10:31:10 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <5662fa98-7926-85e9-3ba9-36d6c4877de4@FreeBSD.org> Date: Thu, 28 Apr 2022 12:31:06 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory" Content-Language: en-US To: Baptiste Daroussin Cc: Michael Schuster , FreeBSD CURRENT , Chris References: <93f322eb1d99783e568262a5cd9f5fd9@bsdforge.com> <8364fbb11098ffb0799829972cc6a35d@bsdforge.com> <20220428071140.iuydpxyuryqfs4c4@aniel.nours.eu> From: Stefan Esser In-Reply-To: <20220428071140.iuydpxyuryqfs4c4@aniel.nours.eu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------xFmvaNmD2fr7K94Y32qHto0D" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651141871; 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=j2ZXhIReSpvrvs36ZGLVZkTlH4gCTbf1w9GcM7+N5Ws=; b=ljT4utKsXsI56UOxEA81EDzMfv59aR2s3WJFgNBbp9XIeZ/EH10YWzXTh+4EO08ZJMA8zM e/3P1TbgncnYtWT7SfrW8rkTLyeesQSm/p8GeFePHg7IYlxqKqmiXmPTt0chcsvjZujrvf lCbgmBHSDsp+Kyett+LegdxZJyriVWTbYOH48IBtFQVWvjyiz8ALuFKQqmEcNLMnUR2mUu lW+u7Qnng7m/7Ak3vAQYkIUPW2CM/Pf1ftaY9BaqgtRT3NQrKOt31Y742XHgrs9QoQupUL Ps2MIyf6Gzj12UVdW+ZcExsdQciSOWelhXGJ1Uwt7wiSs2gLOXu3tufk2KDIjg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651141871; a=rsa-sha256; cv=none; b=Tic31mVvD64rWDzI5XifuSXgkdAdg19pbOZCqiVqJjqp5wkIRV0dbDFX0W9cx9Wa4WXniN xhLtCRyXi+eZlCKgJjCSUvj7D8+fcbegE5wYvaY5TMNwpGrsJvBZwd2Hz+M8l1E3R9JzFn stvn06vSPN4EWirxFCPLITQ5y4hPZOTHaUHpuSZA5UydnFIau1FyebEYlWl95CXcfygQrz 96MVALMJJb0cu9/A9Kwr9HB+m2MN0ZbBD9b5n1gsO2zUBqkKOVX4kUVwFQY5/4Yapnsetk dQ+Mm1r27qge9c6a9eFbkFO4kWk6W3NwvO+wPJu1hyJcS59Mv6b1JIeXy9sAWA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------xFmvaNmD2fr7K94Y32qHto0D Content-Type: multipart/mixed; boundary="------------9AyrwfcmOzbZiZUUfMNG2k0D"; protected-headers="v1" From: Stefan Esser To: Baptiste Daroussin Cc: Michael Schuster , FreeBSD CURRENT , Chris Message-ID: <5662fa98-7926-85e9-3ba9-36d6c4877de4@FreeBSD.org> Subject: Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory" References: <93f322eb1d99783e568262a5cd9f5fd9@bsdforge.com> <8364fbb11098ffb0799829972cc6a35d@bsdforge.com> <20220428071140.iuydpxyuryqfs4c4@aniel.nours.eu> In-Reply-To: <20220428071140.iuydpxyuryqfs4c4@aniel.nours.eu> --------------9AyrwfcmOzbZiZUUfMNG2k0D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 28.04.22 um 09:11 schrieb Baptiste Daroussin> It is 2 things, it is a = port problem of maintainers who do not check for > upgradability of their packages, and it can also been seen as something= pkg can > deal with, but a complicated case, so I don't know yet how. >=20 > The main issue is a file in vX which becomes a directory in vX+1 which = goes in > the way pkg does extract files to be as atomic as possible. This case could be caught and dealt with by removing the file or by movin= g it out of the way (to a temporary name to allow it to be recovered if the= subsequent steps fail or to be deleted if they succeed). Further special conditions may apply - but since there is no way a file and directory can exist under the same name (on FreeBSD, at least), it is= safe to assume that the file will not be kept when the package is install= ed. Regards, STefan --------------9AyrwfcmOzbZiZUUfMNG2k0D-- --------------xFmvaNmD2fr7K94Y32qHto0D Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmJqbOoFAwAAAAAACgkQR+u171r99UQM Swf/SEXWrTI7BtOQa5fnnMVDbnU9eopaah8zHdV2d/iDSdNE0PxPHJFEEW6E+831g3A3q005rBJX vSQzWfPdiPd9ByCNELXhF7PcfZKq0HT12kva+fOD4qTmLQqArf26Hifd4HunbgwwMppPasjy+pik ri9R5N9/BP500DQmNeH1MuDVknqhC27oHhA8AiVzWLbft3/jU0IGzdhrZns8nddlCUgOl3O/Q+Iu G1XQURjZd5aqvntgce5fO5AInLV8NI4XQVm9F3SoziiLcqV3IytzcWdeNX+SWqvJJ1VK/+kID9qj y13s42xlK2C9xJZeGIRe2pNCn2K50I3TaDGohCE2kg== =RZJB -----END PGP SIGNATURE----- --------------xFmvaNmD2fr7K94Y32qHto0D-- From nobody Thu Apr 28 12:20:48 2022 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 979FB1AAF7B7 for ; Thu, 28 Apr 2022 12:21:20 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpvqL6jDqz3kbb; Thu, 28 Apr 2022 12:21:18 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 348c0a81; Thu, 28 Apr 2022 12:21:10 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 944975cb (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Thu, 28 Apr 2022 12:21:10 +0000 (UTC) Date: Thu, 28 Apr 2022 14:20:48 +0200 From: Michael Gmelin To: Stefan Esser Cc: Baptiste Daroussin , Michael Schuster , FreeBSD CURRENT , Chris Subject: Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory" Message-ID: <20220428142048.38c33556.grembo@freebsd.org> In-Reply-To: <5662fa98-7926-85e9-3ba9-36d6c4877de4@FreeBSD.org> References: <93f322eb1d99783e568262a5cd9f5fd9@bsdforge.com> <8364fbb11098ffb0799829972cc6a35d@bsdforge.com> <20220428071140.iuydpxyuryqfs4c4@aniel.nours.eu> <5662fa98-7926-85e9-3ba9-36d6c4877de4@FreeBSD.org> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KpvqL6jDqz3kbb X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [0.79 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.10)[-0.098]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MID_CONTAINS_FROM(1.00)[]; NEURAL_SPAM_SHORT(0.99)[0.988]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; FREEMAIL_CC(0.00)[FreeBSD.org,gmail.com,freebsd.org,bsdforge.com]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 28 Apr 2022 12:31:06 +0200 Stefan Esser wrote: > Am 28.04.22 um 09:11 schrieb Baptiste Daroussin> It is 2 things, it > is a port problem of maintainers who do not check for > > upgradability of their packages, and it can also been seen as > > something pkg can deal with, but a complicated case, so I don't > > know yet how. > > > > The main issue is a file in vX which becomes a directory in vX+1 > > which goes in the way pkg does extract files to be as atomic as > > possible. > > This case could be caught and dealt with by removing the file or by > moving it out of the way (to a temporary name to allow it to be > recovered if the subsequent steps fail or to be deleted if they > succeed). > > Further special conditions may apply - but since there is no way a > file and directory can exist under the same name (on FreeBSD, at > least), it is safe to assume that the file will not be kept when the > package is installed. The opposite case seems more interesting/problematic. -m -- Michael Gmelin From nobody Thu Apr 28 19:21:45 2022 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 0C8C11ABADFB for ; Thu, 28 Apr 2022 19:21:58 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kq58h623sz3P6d for ; Thu, 28 Apr 2022 19:21:56 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id B4EDD10A1E8D for ; Thu, 28 Apr 2022 21:21:48 +0200 (CEST) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 10E2010A1E86 for ; Thu, 28 Apr 2022 21:21:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1651173707; 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=TJeljfXEFB9Tk4d7K4XZpKdgUDK4Hvczzoqx+ElvHDY=; b=j1Tyd/C/0noYciqEMn8WsTdA+8TYgfbkhWxhgrqBkP4chpVpC5gmhvq9SKANVPK30oCWet c9bSsLfTgT6sL3GYnfctxDlQoAm2neALTDnr74AHwGoaFDVndVzPVicAzLnppBypyvzFbh 9Us892QdEnM7EuvJxaglPs90Ez/GsiLEuVSy7uxVyHI//lyJuZFuht4ucqATNm41fSre9Z YdFnk2NJBVePA4ArFU30zNpjA/ixJN9SrjZyYjQLY7QTBkc3sXsJbKik8Xcaptw5JWY95U 6EvLC/VB9Q7DM2C3IIi1hLUGNGjS+WK61G1oX3r9NVR3bQ2jb7XQtmNSaIWj3A== Received: from hermann (dynamic-2a01-0c23-645c-5500-285f-d883-3bbc-9048.c23.pool.telefonica.de [IPv6:2a01:c23:645c:5500:285f:d883:3bbc:9048]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id CC3A810A32FA for ; Thu, 28 Apr 2022 21:21:46 +0200 (CEST) Date: Thu, 28 Apr 2022 21:21:45 +0200 From: FreeBSD User To: FreeBSD CURRENT Subject: ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery Message-ID: <20220428212145.499a9cdd@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: c72a27 X-Rspamd-UID: bab04b X-Rspamd-Queue-Id: 4Kq58h623sz3P6d X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b="j1Tyd/C/"; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:30) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.85 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt-de.de]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_HAM_SHORT(-0.95)[-0.947]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from] X-ThisMailContainsUnwantedMimeParts: N Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to rescue them and store the data on ZFS volumes. Mounting of the HDD doesn't work, FreeBSD 12.3 obviously lack in some etx2 features, namely "needs_recovery". The kernel reports: WARNING: mount of da4p3 denied due to unsupported optional features: needs_recovery How can this problem be solved? Thanks in advance, oh From nobody Thu Apr 28 19:27:38 2022 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 733D21ABC4F7 for ; Thu, 28 Apr 2022 19:27:49 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kq5HS1l1Kz3QZv for ; Thu, 28 Apr 2022 19:27:48 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 23SJRbXU003430 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 28 Apr 2022 21:27:38 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1651174058; bh=HbqH7cdITe1AW+cchBjPo4j9u9/FNa/IveeZeoPx7+k=; h=Date:Subject:To:References:From:In-Reply-To; b=merkGvxuK2tOSsAlKoN5bDowLyBCSVwbTEly18CC90gYRhsAXoXLQ+P6+KhNmaqpt CHr+Fqodc19KP/6R0hiFpM1ZS8GshZN9FuZMXfbyRIXMeQdVa1JlaviNv+FdClTOeA 17mFggF+YggmJ0tA43fFnIGGDt4lKBOUIcpVyD3BiUy9EK61/2BbUeSx5xdDNBgn70 TKyBf1GHqmip4t0kXy4Dpd1bWPZNkH5EJf4VstXbzrQFsY+ryCUWW/rV9FsCxU/wDR KhDhndxNuw+34RIFB9xXfHyan4Utqkui8AKPA1s7z8f3oVwy4j58l5K/fbStSX/OBa 8EQeY7gtojUaA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: <6648abc2-0ffa-dd88-2767-007ef833869a@plan-b.pwste.edu.pl> Date: Thu, 28 Apr 2022 21:27:38 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery Content-Language: en-US To: FreeBSD User , FreeBSD CURRENT References: <20220428212145.499a9cdd@hermann> From: Marek Zarychta In-Reply-To: <20220428212145.499a9cdd@hermann> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Kq5HS1l1Kz3QZv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=merkGvxu; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-3.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N W dniu 28.04.2022 o 21:21, FreeBSD User pisze: > Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to rescue them and > store the data on ZFS volumes. Mounting of the HDD doesn't work, FreeBSD 12.3 obviously > lack in some etx2 features, namely "needs_recovery". The kernel reports: > > WARNING: mount of da4p3 denied due to unsupported optional features: > needs_recovery > > How can this problem be solved? > > Thanks in advance, > > oh > Probably as the name of the mailing list suggest you should upgrade to 14.0-CURRENT and maybe run fsck.ext2(8) on this partition to fix it. -- Marek Zarychta From nobody Thu Apr 28 19:36:21 2022 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 436191ABE9C0 for ; Thu, 28 Apr 2022 19:36:41 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oa1-f51.google.com (mail-oa1-f51.google.com [209.85.160.51]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kq5Th1c1Zz3j0x for ; Thu, 28 Apr 2022 19:36:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-d39f741ba0so6133926fac.13 for ; Thu, 28 Apr 2022 12:36:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PB1HLK7wgAuNumJMw2jSw3dEdFHhXTy9lEDDUix9whI=; b=SNft0tpJaPtArw1E6KX0JHqHnNCiX5b1AkAn0ng3fW9p9r4O/G1w44limXgrZpU38h yo5hxEBYQovXhjswa0m4unzeMScml49X5z3A/b4EFb8IR3lLjRsnnbgAQbHq1O0yWsfl BwjTIIZ8iUHbtu3RjMUQDemI6RQkWKz8eWCnNe48Du1lqFXAHURXAqnE8Q56RbTksU6d 1ozNeO9uGjLsPM8RC4j9oz1Knb7am1bNyv3twQip7a8FDrrbA15Z8hvYKOYCT0JZlmoS r0TWLTKSJxlhdQE5SgGPAeteJw/sDDJpi5LkXKi1N1VZW+Jak9YUBPkSkirpa6AS1eF6 npWg== X-Gm-Message-State: AOAM530VGHbBUuMmq4uHST4/sQaIrZJ/E5q6DzYgW1OUUeAxuFUFBgnu qKS9Uuy4m6qncDClzvGnNAcmI4OeAgVkB7ci8KRUyKsO X-Google-Smtp-Source: ABdhPJw+oP1AodAd27yA++wxpuyHwFqu+9KuBwKv70xRovN9zQipu20t9SkaR5BH6y1uxJEiQdTQQgnY75l+8keSABs= X-Received: by 2002:a05:6870:a2d2:b0:d7:60ca:5065 with SMTP id w18-20020a056870a2d200b000d760ca5065mr19086933oak.72.1651174592759; Thu, 28 Apr 2022 12:36:32 -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: <20220428212145.499a9cdd@hermann> <6648abc2-0ffa-dd88-2767-007ef833869a@plan-b.pwste.edu.pl> In-Reply-To: <6648abc2-0ffa-dd88-2767-007ef833869a@plan-b.pwste.edu.pl> From: Alan Somers Date: Thu, 28 Apr 2022 13:36:21 -0600 Message-ID: Subject: Re: ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery To: Marek Zarychta Cc: FreeBSD User , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Kq5Th1c1Zz3j0x X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.160.51 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RWL_MAILSPIKE_GOOD(0.00)[209.85.160.51:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.51:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, Apr 28, 2022 at 1:29 PM Marek Zarychta wrote: > > W dniu 28.04.2022 o 21:21, FreeBSD User pisze: > > Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to rescue them and > > store the data on ZFS volumes. Mounting of the HDD doesn't work, FreeBSD 12.3 obviously > > lack in some etx2 features, namely "needs_recovery". The kernel reports: > > > > WARNING: mount of da4p3 denied due to unsupported optional features: > > needs_recovery > > > > How can this problem be solved? > > > > Thanks in advance, > > > > oh > > > Probably as the name of the mailing list suggest you should upgrade to > 14.0-CURRENT and maybe run fsck.ext2(8) on this partition to fix it. > > -- > Marek Zarychta > You might also try sysutils/fusefs-ext2 from ports. From nobody Fri Apr 29 03:33:54 2022 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 E10A41AAA0BE for ; Fri, 29 Apr 2022 03:34:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4KqJ4W1Nslz3NJ9 for ; Fri, 29 Apr 2022 03:34:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651203241; bh=AInJasH+YSK4rxjAx5dV7Te32giu6Q9tE2z63S3+Rhc=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=lAth9PWfxU37KdcgRHdMfUbJQqI6oue4QJGXFcC+XaVWi0YBT3o8aNOv7Nypk0oic1JgPGEqnrAW29ri/FJg2Qjl+sUcb7ZVNqPalv0yoabkJeimwj9LW2gt3KCrqshxgOQDgpA3/moPsYnJ6aicYVSNtcwZnZ3Fq/uoYoX3v4UFi/AAAPxSBk5K26UmmmCO/5JupPdehbuNizENtPPoXjEiWxIOkSPmhLtVOrkYzUzxo4JJtMU6w+HKO++Pd8pUqeM+UEEGbizfS58/hFXyPjKaREcmbPDcXOxy3WJhkgCLvwgEPqvmQXC6zQG8rl9afhS0vagSJkrNGQ1x2fx54w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651203241; bh=nx/r7OAb33szMhXtk07q2TkZfvyuAeYgiR/GPldFqzJ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=qeiy3K7wh+WlztHR8t5aSv9bRD3G+brG4fEnfOV2fSipWy1Yi8bpBjaRW0hIY5A4o9mf3mh2jw8v6xDuS9R4Gj2wWLrIx4aZFLisfmT6bgPKA2eDNu56mDMtglT/MZZdo0MiEZx/mzcyY5AX6HSJqNdEMpTHXmfTqqk0UeWyvrzB29kRhSkLm8leXsC1bxNfjNXnnFaEX9plNd5DBAdLfe7upIdF9zP3vEs9UzDvmXeHVKQfbp7Pc2RhB8m5ITRI1dhse84wslr4IKYUxThY/kjb4Sklf8c/+bQ4qYGY8ZNaTEacUlqgx8uHn9xJqxOkfdKDoGvNV9JMc+7tCXwCAA== X-YMail-OSG: mrhvApwVM1mtIxjmI9d2jSWw3IV5rBp7x0_TYnueewuo9ApsN4JwXBwtCZPISz3 WEv3Kequ7l3AFhQtZJQdMjTGEqKji6Sf534dr.EY6eldTjhxm_RL6BKZDzVxwu_ZTHurcaTiAan8 Y0d1tzlAxyrOc7QVnRpdVpP3UrVU.IqISH7JQVH_7sOdzlGc4ehdQgDziedyxX6ZXWc_HXbhEWJL WZbj0PyPzwgmjFuLwtrT6mnAlEGY9CCzYy7Cz2xKlrszaMlaC7pt7rCow4WleeAzGjyevSYbmAPo J27xu6UmpMjicfpuClWUOCdzo0Fiec2sD_536rTW8GblK9KOV16.G9gEnP_Hbn2ofR2cA44URWnf jOvNz.7l5_gWautRWgkPZ4ZIb0yUyCrcqvKd36O_TLBrJ0yWr.s9NUjTz9greOOzlLA1xvQtjBft wem3JuAu.FWQk_eARwKAsMcP1A6UOP8cYoF_v9dGducGZONqWMP0J9apK.kGjx6jKiS5CKbq6cE_ Iqoczi2YhaDtdEsS8Gm99HG1EGo8fGp52bNo7wxGhC0eGGmfBxw5o6Tp0WwdRAX9KnicarwFKbgT FsbgW9Tsjvd0QRINXEMVxMhSh8sI4KohPIKhp.o0gr4D6Ub2tXrgK0iD.QmAtNb.9Lvpi2TEKPrr orvNGUo3n4qBa.6R9aJrtsSvUOBcuYt_jOWHeG.uSug3wS53wIfKKAkx9HFswqNxllUH5R4Ui9rH cgs1pGjueSPj8RbFA9.4mc0H0Pem4tV_cMWMPzqTa6jvlFGjjUVCG3sEQ9ph1LVPYvl7EakCCcFg KS9GeN.3vYOl5HlNeE_0gAPRBMyYEiFo6cKEs4WfdWM7D.CdJFasus7DuOKKqeKFTAsLFdj9vK33 zdlkUeRNm2EqH66GPmKwJ6AiG1sOe8fxNWuXbE8bJR_hFeDITgzvNQr9a25G72oD7mXRFEoYvlPB 5sQJQcYrh47uSg7Mku1x0ZU_BGCfLhBrNjuhvadkdVOd9MRfvQtJo.w0E3C0UDHnzrzhnfolwwAX L8RWer1PF4mx8QV6QF3VwNDmivZ2Nf.xSio20hPY6NgTUHd6ib13R0e7zG7nzNMHBcEzbTWmvELd TJbYXijIU8JplqR86dpU0MtQzWQ7jpbvdCeauvLHSB_Wxj9p512zAhMRqH35lI5jVIWPaaVDevV4 xkKLmHI9iUc7BPkFEna9_EUi.pED_luIcXJf4G7ETX1UZL8lZ65b1S_JhY71oXIJ3eNFeTJkKFKX oyArVMnTx3hxx4UYDHz59cPDz3zCqu46FY9OtmSkUvAEFNx3X6wgm7mRMPmmuVtZgXoUznANehUP K0g41HI9kMHMB2ue6tmVieuZH9LeXnzJ1S1atlac_zD9fFGndKqFf_S4y6rc6D1tO8T8bZ0hBi9Z jVcIam64RIzOlgiWzjlih42e_gSBggYROPDu5fgRuc_m4JTGjkVXkKa4Fje7g3MUwYQnhgoooPyd o3hNqvdDsqn99xrFUEfGggEBzhHoZBpyIF_ukNVik_jkxWRom7NSqQMqSM_ZWILYi4ZaQ9gtkBU9 8CY6yxg3Z833U2CJNSrVtnB59FK3DrZW1XPS72XhzU1hK1FrTEzB4QTaKEgGh48PlMeE3oZwhIqi oFxfMJmAQ1DIr37AbH6Ibuu7aVJXREO7RtDWlgzCQ5THRffUHrXPFqcVQzs5iByYyFrGfwY62Sky 5wv7R5rFuEGpsKjlpTp_nYCwyYF4hWIjsqfF1F73EZXzaj0QtKLAFDYjiqnURq3oU43dsyuwK9ri yf0_hlq.kCQ62gedeebDLzZYNHVfLbSORYcWqRxqNxWR1J9U61YA.uGDWaG_1xTuAFtRdQ2yBUO1 XpXLPvTQLDQvtNBOGVMWXJXMOPElxZbzZdpnnMHANXjnnESl_xWg1AQ8XbWq5yu5c.httwLBgIXf GYMYfGyRKjPKXpnqGqOJ6j1acxANsbt63LO1Nl6gA_6db9mpkM0jEJx00Ax8VKwcUmtRiBMJfp17 bQdXx87.Ri07zIEo1C7aaRqJsBiRJXjCfPGVAQnKIvXbuk_822kg26mvvBQlHzrMk6t8S9RbNmDV 74XajqIVG6I16dZJMFF92O5zAEKAc8ivLEh_QZ.pU2DqTNcmbkzwFvpFs2JMJI_KB8ePaBfw7oz6 CcfA2C1IchsladJCt9p6K0y1IsXUrQCfLSCVZSG2fJwvBaIDgCZ6By6IfJMN2_ljIzAhZf3sdn8l fteZRDME3OINSHStx0wD8dkjpOOyTtboaZQFq5C2fr_aC5hkniboRu6pf_VRnmBr46_hIjJT73ce ID702jg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Apr 2022 03:34:01 +0000 Received: by hermes--canary-production-bf1-5f4c6455f8-rlf6p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9d6a87c330764699ade55e78f8045f66; Fri, 29 Apr 2022 03:33:57 +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 14.0 \(3654.120.0.1.13\)) Subject: sys/arm/broadcom/bcm2835/bcm2838_xhci.c:184:21: error: variable 'sc' set but not used [-Werror,-Wunused-but-set-variable] Message-Id: Date: Thu, 28 Apr 2022 20:33:54 -0700 Cc: "freebsd-arm@freebsd.org" To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4KqJ4W1Nslz3NJ9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lAth9PWf; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.48 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; NEURAL_HAM_SHORT(-0.98)[-0.979]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N In attempting to update from main-n253904-4d1ba6febfa7 based to main-n255108-9fb40baf6043 based, targeting aarch64, the following code from sys/arm/broadcom/bcm2835/bcm2838_xhci.c was rejected: static int bcm_xhci_attach(device_t dev) { struct xhci_softc *sc; int error; sc =3D device_get_softc(dev); bcm_xhci_install_xhci_firmware(dev); error =3D xhci_pci_attach(dev); return (error); } as follows: --- bcm2838_xhci.o --- /usr/main-src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c:184:21: error: = variable 'sc' set but not used [-Werror,-Wunused-but-set-variable] struct xhci_softc *sc; ^ Building = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER= IC-NODBG-CA72/imx_i2c.o 1 error generated. *** [bcm2838_xhci.o] Error code 1 make[2]: stopped in = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER= IC-NODBG-CA72 .ERROR_TARGET=3D'bcm2838_xhci.o' = .ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm= 64.aarch64/sys/GENERIC-NODBG-CA72/bcm2838_xhci.o.meta' .MAKE.LEVEL=3D'2' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose curdirOk=3Dyes' _ERROR_CMD=3D'cc -target aarch64-unknown-freebsd14.0 = --sysroot=3D/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch= 64/tmp = -B/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr= /bin -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. = -I/usr/main-src/sys -I/usr/main-src/sys/contrib/ck/include = -I/usr/main-src/sys/contrib/libfdt = -I/usr/main-src/sys/contrib/device-tree/include -D_KERNEL = -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common = -mcpu=3Dcortex-a72 -DLINUX_DTS_VERSION=3D\""5.13"\" = -mstack-protector-guard=3Dsysreg -mstack-protector-guard-reg=3Dsp_el0 = -mstack-protector-guard-offset=3D0 -fno-omit-frame-pointer = -mno-omit-leaf-frame-pointer = -fdebug-prefix-map=3D./machine=3D/usr/main-src/sys/arm64/include = -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector = -Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign = -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs = -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-error=3Dtautological-compare -Wno-error=3Dempty-body = -Wno-error=3Dparentheses-equality -Wno-error=3Dunused-function = -Wno-error=3Dpointer-sign -Wno-error=3Dshift-negative-value = -Wno-address-of-packed-member -Wno-format-zero-length -mcpu=3Dcortex-a72= -std=3Diso9899:1999 -Werror = /usr/main-src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c; ctfconvert -L = VERSION -g bcm2838_xhci.o;' = .CURDIR=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6= 4/sys/GENERIC-NODBG-CA72' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6= 4/sys/GENERIC-NODBG-CA72' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm64' MACHINE_ARCH=3D'aarch64' MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/usr/main-src/share/mk' MAKE_VERSION=3D'20220208' = PATH=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/t= mp/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tm= p/usr/sbin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6= 4/tmp/usr/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aar= ch64/tmp/legacy/usr/sbin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-sr= c/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/u= sr/main-src/arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA72-nodbg-c= lang/usr/main-src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sb= in:/usr/bin' SRCTOP=3D'/usr/main-src' OBJTOP=3D'/usr/main-src' .MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk = /usr/main-src/share/mk/local.sys.env.mk = /usr/main-src/share/mk/src.sys.env.mk = /usr/home/root/src.configs/src.conf.CA72-nodbg-clang.aarch64-host = /usr/main-src/share/mk/bsd.mkopt.mk = /usr/main-src/share/mk/src.sys.obj.mk /usr/main-src/share/mk/auto.obj.mk = /usr/main-src/share/mk/bsd.suffixes.mk = /usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk = /usr/main-src/share/mk/src.sys.mk /dev/null Makefile = /usr/main-src/sys/conf/kern.pre.mk /usr/main-src/share/mk/bsd.own.mk = /usr/main-src/share/mk/bsd.opts.mk /usr/main-src/share/mk/bsd.cpu.mk = /usr/main-src/share/mk/bsd.compiler.mk = /usr/main-src/share/mk/bsd.endian.mk = /usr/main-src/share/mk/bsd.linker.mk /usr/main-src/sys/conf/kern.opts.mk = /usr/main-src/sys/conf/kern.post.mk /usr/main-src/sys/conf/kern.mk' .PATH=3D'. = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER= IC-NODBG-CA72' 1 error =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 29 03:39:55 2022 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 239311AABF88 for ; Fri, 29 Apr 2022 03:40:04 +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 4KqJCR1ZTxz3QF4 for ; Fri, 29 Apr 2022 03:40:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651203596; bh=ctOggl3IxsgNzu+vQLJ/0lgNpkCS3m42ynU9rxcsyPc=; h=From:Subject:Date:In-Reply-To:Cc:References:From:Subject:Reply-To; b=IAk3zpTqiOwmz6oqO2OKtI364RpTAsiLkrSgTqzfq3mghVHHmAxLE4VwvBZi33ci9CEyYLsq3MijFUv1b6lFrR8XObwxGl/1gcWMloHPlcXHc3SAapE1g47Zrknz+da7kXt9LWy2FbGkacdFOJXAnkE6NRblOP/Wxayf8cJwBqq5OGoTj5hcG+sK21f06AziFltFZHtL4RoTjb4GsD/fA2tejX5yF6JR41rgLaTx4Y6IoWQwZSGgrviPw05IHVgXqeWMTVn9s3UQLO1BwWXz9OZKKD7C5pfTKKOCicAERl/NoRlT1XhPnxbXO8rZi27A93RUzR59G2y7qCVC9WIrbw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651203596; bh=YOVF3H3XrvCNob4RbNzP8WAFBY3hPbkn2LdijwNtag5=; h=X-Sonic-MF:From:Subject:Date:From:Subject; b=ZFNp7TDZ0RabQq4W92443UrSCq708oxL7Gxq83rT6cdolACWYqW1vtkomtLRBU0qExbr0Lu9NYu0UsbTtNjuYAndNdwlDDwjOolMlBUTCx0GXdwX0qzG3GP12TlfEzJ+CKEg5JNVm0QwK8LN/rnJjyEJX5xx2W3gaRCQkR8lgC/IDkfrkFp7603wjZ1wi8uYs2RAVydvw4T4Hs0WOauqewQ/Pq8fMqmk7m7N94d4cV9baaXl+gd+Kdy6HlukmeMsXyx9EYG9FOWyn1gkeHIzpHas3fDHHnfnmb/O7fOK+4op6AcaHgKPFMrnBJcMns3VpLRY/Djkm/Z0Dzd9RBIXXg== X-YMail-OSG: _34r5YsVM1m596975NzMplx8.Hj3i0AWQ0R2ICC9Zyb5vw9BmzHMR1x2.gc4R1T MdwO5vSTXq.agHiW3O2XsJXpbIS.yDcwxpY59FLA6zK_2X4.4hzRpsSDz8QPRneJUkQUP_7sExAn PwAiE4yl2Ps5TbxuwxkpnoHFEWJz_FoeLOFF3XoLroTaexTsdteqQYfoFeVlGTE8gqV85ZG1hSdm 4Qaj4stLwNFpzBkdbAQ8cWZ3ThSAkhtTuNmVjkFIapZ.q.VCM8CvxsNEhRjwjRYnTO2CVfYI.2bk EYWxaP083KF63CjdNIp6hqmhuHO_pDkqbL7LXIGw4vEDnRgCUmvzK5FYpw2iVeQ09YxreMPD49xr _Q4JWUJ7Bex_QALX7FAWkeBcA1yi4zOGf39_VCtRhtsdV75tLePAuKC4kKyHJ3hNQ2XF6VT_LugK 0iaGONBN7ASM2.IGh2tsvKkNSWSVNWYwupHgpnuqTLkq8dO42yD8eT6tTn.le3JxrCwZooA6_d_q Sx_HjE0KfBW0TXlXwW.LTCDiJ4u3ZYR2ahaVHRWZAvE.m7IgjTptAcl5_IynCbl3vBlRfPD5iDeS mPUIJlN0J0LFUR4w8EgKfvnBNrZrjTh6QlS6rg1bY5xTtwZ5ZESFS8PISCGO3yhn7xK68jFJrJLr 2S7u0lzldM6ezcNj5crgauxEhvHmiY9vBZPjByrzZyEaOZzBhlIlb8.0fp1ePceAUZ0.vkK04kdN RCv5I8EtqD7KcheDS8DOQii4wyz0rfzA8QtekNp1eUnLmmJMMGkeF5Tf.Q.GrG1S.NengrhcCpoF eGrz87S8di5yhU5cySlxGJzgKLwzjb6YufydbMY4.H.SVTwILysDHrEWp8nIgKjp3kt2wltdzEyw cTn7dySejwKQnGwqHktl4LV1mdXGCGyZJtCUGKcoKbsAkd0m02lnCwmY3fs0u3iwTIoohIuS_OEK Cvj4M_xRVopEjY0uxAzJVOTSC.Wi5VU8R1_woaQfBDbDuXUmHXPE4swlpeMnWHX.lcLbd_pIITNL 9j37VlTgg621EraUMt9f_OsDSgmUeeJYLTSbGUp4WJKJaWmOwlWAOBRXmEN0qjGuynNqTRJ2TXJA HIJJV6Mb4IrMwWpSvjIOOA8sSLk23CfW8_GgjkHydx82BT80CsPgaKo1FVnAkQEwZ9Q9QJAzzi1D v24Hb.wbAaayUDNURfR3UHxIOGjFbMWy_O7uRre.Bju7T7vEAC.gRS7Ai0i4wmKgAz9EAHN1OkFy F4hYnMoUCxGRLJqo6NmxqytVuYvvE2d4rilha3zsWLqvj9Ukg7z_pCurO_aYGihLf3Q.emUCNlgl inPLcd9lqVVRlKrRvF80Ai8x8.trAY4ts9V4amCgcGPmmaniGekWxsiXTe9._g1synovigGyzqXh D3FiscsKhRQKYVf4AD4jzpYUxH.dRrzxRl84w5Ox.FcBbm8vcwTbpQWu1SrftIeFdu3Q0r3va2SV xPmOS7wbQ.rKf5ui0QGbRMqnFVPwXgcAi1wjMpefBbms0.rIko6omTPhLgQCOw5ADZ1zdxBol3WI xru9jP2YD8XqnqhVYZsPSEQTOo_F4vbCgHmgJ9i7lmlBlMPImwQbNDamLUG7l84o1Bd3mnq6GY_3 2U67EyZNGR1ltLZJzLRG_gFtBszDORwoTSd63GFH0d9sNIaGrU5cFpJdwGUJFNTmgFYh.r_wffiT 5m_y1GdRz5hKRkkZw0EsulaFDPGfwmNONUfetpUnzrBPULY54yFIV7AWv8YOg4kZmzCGOPD_Qwyy VYXv6nN2CUVFTZrdTDqem5nst.QnI7I9GiRE5HRf4MvBO.OdOJPnvFzKgT1Q0JOc2hpWptEvvAI9 VEV5IuD.rwzj9uQzmHlkS98JLGO1q6W3nCJx5tl6YAFu5f0iicnUS46Du3t9HOToS3.XYziTnds. aEZQ6kOE5sgUZKqDci7GReXfueU7CisLUv8eDJASBfpCcFhm3EY2lwLe2hunvabgBLVBoMPjoubj I0BFhim_hLZNiaOF8UHtMlpDkf6pwCTkYMKfecGEGnIUMC0vOZOzvGyUc1GBhkHjbT7ALBHS058A gfH_I643s8fjHBq0V2RSiTajKJzgYjK3Ws2Q3jyseHqByt8IVNNrUz0c7sp9aPUdKnggLDERsrJx BN_TTpvlKqfBVbQ7Fs2OiUa7Qi0dbwxjXCdzqKz0TfMn7bB.krI4av26UpVF5zBEAJ8iuOOJNTqa I5EQR7V2ctiun1yjNV4NX4ISBarnn4qgXkynMgqensmIU1N78Uzuj0UPeBcsHvKaUiaQ53Ee4UEd xhcWhUy1mKPlfLA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Apr 2022 03:39:56 +0000 Received: by hermes--canary-production-gq1-647b99747d-7f5lh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 10e379f45a115d8f19a095f4bc212960; Fri, 29 Apr 2022 03:39:55 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: sys/arm/broadcom/bcm2835/bcm2838_xhci.c:184:21: error: variable 'sc' set but not used [-Werror,-Wunused-but-set-variable] Date: Thu, 28 Apr 2022 20:39:55 -0700 In-Reply-To: Cc: freebsd-current , "freebsd-arm@freebsd.org" References: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KqJCR1ZTxz3QF4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=IAk3zpTq; 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 X-Spamd-Result: default: False [-1.46 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MISSING_TO(2.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.968]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N IGNORE. On 2022-Apr-28, at 20:33, Mark Millard wrote: > In attempting to update from main-n253904-4d1ba6febfa7 based to > main-n255108-9fb40baf6043 based, targeting aarch64, the following > code from sys/arm/broadcom/bcm2835/bcm2838_xhci.c was rejected: >=20 > static int > bcm_xhci_attach(device_t dev) > { > struct xhci_softc *sc; > int error; >=20 > sc =3D device_get_softc(dev); >=20 > bcm_xhci_install_xhci_firmware(dev); >=20 > error =3D xhci_pci_attach(dev); > return (error); > } >=20 > as follows: >=20 > --- bcm2838_xhci.o --- > /usr/main-src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c:184:21: error: = variable 'sc' set but not used [-Werror,-Wunused-but-set-variable] > struct xhci_softc *sc; > ^ > Building = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER= IC-NODBG-CA72/imx_i2c.o > 1 error generated. > *** [bcm2838_xhci.o] Error code 1 >=20 > make[2]: stopped in = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER= IC-NODBG-CA72 > .ERROR_TARGET=3D'bcm2838_xhci.o' > = .ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm= 64.aarch64/sys/GENERIC-NODBG-CA72/bcm2838_xhci.o.meta' > .MAKE.LEVEL=3D'2' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose curdirOk=3Dyes' > _ERROR_CMD=3D'cc -target aarch64-unknown-freebsd14.0 = --sysroot=3D/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch= 64/tmp = -B/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr= /bin -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. = -I/usr/main-src/sys -I/usr/main-src/sys/contrib/ck/include = -I/usr/main-src/sys/contrib/libfdt = -I/usr/main-src/sys/contrib/device-tree/include -D_KERNEL = -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common = -mcpu=3Dcortex-a72 -DLINUX_DTS_VERSION=3D\""5.13"\" = -mstack-protector-guard=3Dsysreg -mstack-protector-guard-reg=3Dsp_el0 = -mstack-protector-guard-offset=3D0 -fno-omit-frame-pointer = -mno-omit-leaf-frame-pointer = -fdebug-prefix-map=3D./machine=3D/usr/main-src/sys/arm64/include = -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector = -Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign = -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs = -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-error=3Dtautological-compare -Wno-error=3Dempty-body = -Wno-error=3Dparentheses-equality -Wno-error=3Dunused-function = -Wno-error=3Dpointer-sign -Wno-error=3Dshift-negative-value = -Wno-address-of-packed-member -Wno-format-zero-length -mcpu=3Dcortex-a72= -std=3Diso9899:1999 -Werror = /usr/main-src/sys/arm/broadcom/bcm2835/bcm2838_xhci.c; ctfconvert -L = VERSION -g bcm2838_xhci.o;' > = .CURDIR=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6= 4/sys/GENERIC-NODBG-CA72' > .MAKE=3D'make' > = .OBJDIR=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6= 4/sys/GENERIC-NODBG-CA72' > .TARGETS=3D'all' > DESTDIR=3D'' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'arm64' > MACHINE_ARCH=3D'aarch64' > MAKEOBJDIRPREFIX=3D'' > MAKESYSPATH=3D'/usr/main-src/share/mk' > MAKE_VERSION=3D'20220208' > = PATH=3D'/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/t= mp/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/tm= p/usr/sbin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch6= 4/tmp/usr/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aar= ch64/tmp/legacy/usr/sbin:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-sr= c/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA72-nodbg-clang/u= sr/main-src/arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA72-nodbg-c= lang/usr/main-src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sb= in:/usr/bin' > SRCTOP=3D'/usr/main-src' > OBJTOP=3D'/usr/main-src' > .MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk = /usr/main-src/share/mk/local.sys.env.mk = /usr/main-src/share/mk/src.sys.env.mk = /usr/home/root/src.configs/src.conf.CA72-nodbg-clang.aarch64-host = /usr/main-src/share/mk/bsd.mkopt.mk = /usr/main-src/share/mk/src.sys.obj.mk /usr/main-src/share/mk/auto.obj.mk = /usr/main-src/share/mk/bsd.suffixes.mk = /usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk = /usr/main-src/share/mk/src.sys.mk /dev/null Makefile = /usr/main-src/sys/conf/kern.pre.mk /usr/main-src/share/mk/bsd.own.mk = /usr/main-src/share/mk/bsd.opts.mk /usr/main-src/share/mk/bsd.cpu.mk = /usr/main-src/share/mk/bsd.compiler.mk = /usr/main-src/share/mk/bsd.endian.mk = /usr/main-src/share/mk/bsd.linker.mk /usr/main-src/sys/conf/kern.opts.mk = /usr/main-src/sys/conf/kern.post.mk /usr/main-src/sys/conf/kern.mk' > .PATH=3D'. = /usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENER= IC-NODBG-CA72' > 1 error >=20 This is because of my experimental patches for RPi4 related issues. Sorry for the noise. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 29 05:56:48 2022 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 79FA3199CEFF for ; Fri, 29 Apr 2022 05:56:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KqMFN2Y0nz3tMd for ; Fri, 29 Apr 2022 05:56:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 23T5unH2019302 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 28 Apr 2022 22:56:49 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 23T5um6K019301 for freebsd-current@freebsd.org; Thu, 28 Apr 2022 22:56:48 -0700 (PDT) (envelope-from sgk) Date: Thu, 28 Apr 2022 22:56:48 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Profiled libraries on freebsd-current Message-ID: Reply-To: sgk@troutmask.apl.washington.edu List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4KqMFN2Y0nz3tMd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-2.59 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.63)[-0.626]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N If one looks at src.conf(5), one finds WITH_PROFILE Build profiled libraries for use with gprof(8). This option is deprecated and is not present in FreeBSD 14. I assume that the *_p.a libraries will no longer be built and installed on FreeBSD 14 and later. Is this correct? -- Steve From nobody Fri Apr 29 17:12:04 2022 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 0FA061AB2780 for ; Fri, 29 Apr 2022 17:12:08 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KqfDQ3cCmz4cWj for ; Fri, 29 Apr 2022 17:12:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 23THC4vc021126 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 29 Apr 2022 10:12:04 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 23THC4hh021125 for freebsd-current@freebsd.org; Fri, 29 Apr 2022 10:12:04 -0700 (PDT) (envelope-from sgk) Date: Fri, 29 Apr 2022 10:12:04 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Re: Profiled libraries on freebsd-current Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KqfDQ3cCmz4cWj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-0.17 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.980]; NEURAL_SPAM_LONG(0.98)[0.980]; NEURAL_HAM_MEDIUM(-0.17)[-0.168]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Thu, Apr 28, 2022 at 10:56:48PM -0700, Steve Kargl wrote: > If one looks at src.conf(5), one finds > > WITH_PROFILE > Build profiled libraries for use with gprof(8). This option is > deprecated and is not present in FreeBSD 14. > > I assume that the *_p.a libraries will no longer be built and > installed on FreeBSD 14 and later. Is this correct? > Empirical evidence suggests that src.conf(5) manpage is incorrect. Adding WITH_PROFILE to /etc/src.conf, cd msun cd make clean && make ls /usr/obj/usr/src/amd64.amd64/lib/msun/libm* /usr/obj/usr/src/amd64.amd64/lib/msun/libm.a /usr/obj/usr/src/amd64.amd64/lib/msun/libm.so@ /usr/obj/usr/src/amd64.amd64/lib/msun/libm.so.5* /usr/obj/usr/src/amd64.amd64/lib/msun/libm_p.a so libm_p.a is built. I haven't tried to install it. git blame share/man/man5/src.conf.5 ... f94360971e64 (Ed Maste 2021-06-28 17:30:48 -0400 1392) f94360971e64 (Ed Maste 2021-06-28 17:30:48 -0400 1393) git log -r f94360971e64 commit f94360971e649fa684ef3b7e72839b59c7242bdb Author: Ed Maste Date: Mon Jun 28 17:30:48 2021 -0400 Clarify notice for profiled libraries in FreeBSD 14 Well, that certainly clarifies the situation. Could someone please fix src.conf(5)? -- Steve From nobody Fri Apr 29 18:08:22 2022 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 AF12B1ABE0CE for ; Fri, 29 Apr 2022 18:08:26 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KqgTP4gw6z4mg3 for ; Fri, 29 Apr 2022 18:08:25 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1651255703; 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=1C5cQBZYHdGBVAQ3u3s7z9YW3IJcKBXnzXYHALpdK6c=; b=qTxk/FLHo8hPDKMJX3AnB9KhDfjf6z3B1mzMpk3DlDo+dX3BucIIZYQestCPw/6/GySksD UP9+j+3/eWzH+8f0pw6G7E74JpWjn2NKJ1WwrJ7NK1ioXv47JY5rAb2rPffou0ICnwoRnE /SExDBfT7O6/CoC1Qx07hXcGalEVE1A= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id a6d6fd56 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 29 Apr 2022 18:08:22 +0000 (UTC) Message-ID: Date: Fri, 29 Apr 2022 11:08:22 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Content-Language: en-US From: Pete Wright To: Mark Millard Cc: freebsd-current References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KqgTP4gw6z4mg3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b="qTxk/FLH"; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-2.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; NEURAL_HAM_SHORT(-0.74)[-0.742]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/23/22 19:20, Pete Wright wrote: > >> The developers handbook has a section debugging deadlocks that he >> referenced in a response to another report (on freebsd-hackers). >> >> https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneldebug-deadlocks >> > > d'oh - thanks for the correction! > > -pete > > hello, i just wanted to provide an update on this issue.  so the good news is that by removing the file backed swap the deadlocks have indeed gone away!  thanks for sorting me out on that front Mark! i still am seeing a memory leak with either firefox or chrome (maybe both where they create a voltron of memory leaks?).  this morning firefox and chrome had been killed when i first logged in. fortunately the system has remained responsive for several hours which was not the case previously. when looking at my metrics i see vm.domain.0.stats.inactive take a nose dive from around 9GB to 0 over the course of 1min.  the timing seems to align with around the time when firefox crashed, and is proceeded by a large spike in vm.domain.0.stats.active from ~1GB to 7GB 40mins before the apps crashed.  after the binaries were killed memory metrics seem to have recovered (laundry size grew, and inactive size grew by several gigs for example). maybe i'll have to gather data and post it online for anyone who would be interested in seeing this in graph form.  although, frankly i feel like it's a browser problem which i can work around by running them in jails with resource limits in place via rctl. -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Fri Apr 29 18:38:13 2022 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 531A71995C0D for ; Fri, 29 Apr 2022 18:38:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kqh8127pKz4s8X for ; Fri, 29 Apr 2022 18:38:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651257497; bh=uV5bxg0Ze4bRMxG+SKLIdjMc1bbIt5NSBKoCsQuhYq4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WGEgHAjxTcwDbVeHgsqOuQAPsmmGDl9Fw2fHb5qMgbKgQVsx1VKwoFD75eZXOyhUJLI+1MfW/Otqq5surArbr1rXM5rPKVzMsRp46KbO+9LmUcn3qWJE01zpCebc4859LXzjZ5xYhTQKuEhSk2fyaiKa+hU2+dLhHP2QqbKUg8i981YxeFeu0s6spKKXBtTspIQVGKsAcfAfNRRIrwZVQnY5n6rzHSEywbHHSt5ufgI6yRT6g89lgcRJf9ShBz3R7bptlkjgmw+HKcdhtSdDtMypjlywCpI+kfxeUpxmqto3S7ip7EuApFA13Y7gGy8pDWny6qHD9Sy8Ia9dLa0hYA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651257497; bh=lkE7QsBsalSQ0g8JXwYUCpeTZNHstbjrOwvX7NjA1/q=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kkPwOSCm8PrVCYSyFGfiiiu383Fzulpd4/1pPuXgamITeuOKxcs5V9S80lciAErcza2bEIozSX75tZsDJ+z3SWKISGDwo/Tdtsgfa08E1f5BU7PLKELevwyGlAhZtBnP6NNttBhikAFFCgFIcIjuedDBGRMD6sXV0EzaBJv5WG1i0QKzamcT6t4DrYugJQxJRAycIkV3hFd2/WvFUiSH0TZwNzKEnuUUufgd0cGx5WOLfyHjj0IaD3uu6UYJNvJ11cqNoFNYggcUJZCp4oCh4fmWuNRpoKvyVpklLf6OhKXu5e21Cy47z6/Ji5RThKFbWi/2201F/77Fn6jDLNeP+g== X-YMail-OSG: TTP8jqAVM1mctnsNKWZwSWWskVpaeRhNteiUOdexp7vxp.HCZ3yvY4WPjqxxG6M t52Jia9uCR.OoNFMUeNN9iTDZWBD0iH0RYA2vsyoTjpoOtZRjdTsfjp.HBB8nJGRE.wI7.XyIgyH wLIwJubcOhczqbAQWizIwaQY3Q3vNVfDvexl5mEXbD7dNGC6EkFqo3TUbpWDZAccjNbDGtzmqXIj jGvfY6h4gG6vXnYf7iBb1RPMh3Tg0LJqjHbB5Zw_VU.lMTxPHIiZ1MXIvbsmPa8_i1JcNO6Cp79I lUz3RdKmU4jFbyOQ3ydATmlA1dhn7RBcnWswKhAAQfqYEz6WostyJ2q6UcfkbwJkMZHqItuqJWQc sWzU7WY4wxiIeyeqK2pLli7slLiU5R1ycjtD7_zQa2FIR44kU_ZmBtXALrJ5WHDxyfB4Z3iynLtC oll_js0L.46Qbd96KDe5xX3Zpfj0yD5h9CH6goh7QYt0y9fXKXGeZShrtWPk3iOCEiVtfer.9ovh YCAlvPJSLkcNg8945yxFVuHfs8BiBDQWolWxHjOcSf6aMhcOopRMh3ElIo_A2yVqiS8DQxI4nTah qfCOljQ76WhEbL0APD5jmAY5Zo6gpJAgy8NGUHbrTcz2BZXo9QO2bITs7QCY1jcZ3r9.sDwTxBtL aobaGB8jTgNUvnsUnQ7iA_kNuXCHFYrWIS1kqfAGas_E4hBqhHeSZ5lgzh4ZCjGjJlUP0YsHU9Vr eOfygwyU2J9jXoZQ.i4JxYEXhmyBZalFFzY4Yf4ws1bWSGZKY5PLruEMSwPBnnzaTNihNs2H0sls Ar7XBbakztO0unHs_NgCn.TusbuS52CPpnzhgATbpqNrOAuV6lPQO6Fn1IE1uN2qzae1Wm3YFuiK v9yOLyXBFi3xXHlNQXwS8MjkqRRCV_4SNcQQK7hzD_kcmD6fUEvJP0SZLGDA1XeO8hIBUgRmSY5F 7i.CHYP156ov2GTwaPt9nODLkfHWL5LPl5ZHqodKtiFmKgbD4QFFABL0CXYAnb0kdc_2iYIcjsbe sgUERF56NUOY7r6g2rW5rF98OOxbCB2c1_qKA9TmRZ6_P8voE2u0LFgD3wKghL1_ZK.pKnBIMTwH RFxXwiq6UO8g3h8EC27M1zwkHRkYhbWrydy0hclUiabZ8NRkCMTSFq_lD7KYIy75DVrN5tkHUrdi cqJwNt8MrdiIwIdf2Z9CMlEWX4L1zAOwco_HPz6SZ42Qrm8bPjLJnB.nR6BMOaR2o8nHbrFah5A. YcCd1sPF8DUSJ3NIcatSLZmjoAUkGjeDshpkVwux0F37vh26lBAev662kgx.111iGV_fSoqMKQcY TLln7dirz3qmqZV69BuXaQv2qftn2XhP0gSiK8w5mnS2m_HMmTkwFUM2LUpOtFD47yzaojbV62V4 AhovU_OZHE101vzpOxPeQ58zhOdEMwrREI2nazXF2WtZRsmLehc9siVkmp4wxHamUomZA2wQFvmM 1xu5ig7ewn9MtwDxMfJXx1sKBohkgTLCSWE0DuuOR7go5B9NLlHHrFgz2UNanH7vWvwc6jI4fSSg 4Jz.vOD3T.AgtoUp1HnBPS1H9J0qUTUY9nCtUEcjgNANzbkFCppznbT21oeqq8Hq4eL8l9WiBIOl Oo.8gWexs._vCn5iKO.bcoVw4N93h32SGdS_0TiZR.Bd18RQqvAvqqIYwEu675GvniQabELSAeZT 4YzDt0f8xGoY_zmt5RZE4nW1rHMdlczb474QN9KPtoay1YYPKhTJwgFjqvkz7m1TKXRtozQYOzjU f12JwTo1G.ioA9ARgM6brypNHGWKZVHgBtZLwKVrQJoZ2CPD1FSPAE0iFILDuSvMl0fJCQV.5Rdt OnMvQhj6iPX_Q33Ty1m7OT8h8NGHpdgU7ddZgDf_6FM8bWslwGhrBNlAGQfluXLo104S4HKw_vwe .IXdir2N8wtzQww4d.ycwkWQhVMQzIF4FIUJ08EvLETcNaoLxbuyvQnURBrnIpKuLS7c4L6Xnfyx h55jDP75.NnBvkeuJkl98xVm4aeY8kiSX6TnI0uDLG12y7NXQZu8GphIeirt7Q7oHw.2cFdTVxAa a2D.kXEicKtJofpZJXncP3VzZuztjFRLyt82JA632ebYOqM8V_Jh9u.0K8PobGr77dJgIlRjXLcI sFn4Z3ARTSEekKgYhVdViU2hzJAxP6zgbyyBnovv74vcIsZK9G.y4KnuZth7_EsthOwYa2L3_Of6 dGvUTC4h8bVVT660xySJN_V4OCii2HFTVS2T4IasPjd1l7l09f5yeC_Ye2T55jGXWl0qxobAD8Gx tr_2Ea75FO6tC X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Apr 2022 18:38:17 +0000 Received: by hermes--canary-production-bf1-5f4c6455f8-qwrqm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8bbf46de4c52f96172fec0e517f34c52; Fri, 29 Apr 2022 18:38:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? From: Mark Millard In-Reply-To: Date: Fri, 29 Apr 2022 11:38:13 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> To: Pete Wright X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Kqh8127pKz4s8X X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WGEgHAjx; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.99 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.51)[0.510]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-29, at 11:08, Pete Wright wrote: > On 4/23/22 19:20, Pete Wright wrote: >>=20 >>> The developers handbook has a section debugging deadlocks that he >>> referenced in a response to another report (on freebsd-hackers). >>>=20 >>> = https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneld= ebug-deadlocks=20 >>=20 >> d'oh - thanks for the correction! >>=20 >> -pete >>=20 >>=20 >=20 > hello, i just wanted to provide an update on this issue. so the good = news is that by removing the file backed swap the deadlocks have indeed = gone away! thanks for sorting me out on that front Mark! Glad it helped. > i still am seeing a memory leak with either firefox or chrome (maybe = both where they create a voltron of memory leaks?). this morning = firefox and chrome had been killed when i first logged in. fortunately = the system has remained responsive for several hours which was not the = case previously. >=20 > when looking at my metrics i see vm.domain.0.stats.inactive take a = nose dive from around 9GB to 0 over the course of 1min. the timing = seems to align with around the time when firefox crashed, and is = proceeded by a large spike in vm.domain.0.stats.active from ~1GB to 7GB = 40mins before the apps crashed. after the binaries were killed memory = metrics seem to have recovered (laundry size grew, and inactive size = grew by several gigs for example). Since the form of kill here is tied to sustained low free memory ("failed to reclaim memory"), you might want to report the vm.domain.0.stats.free_count figures from various time frames as well: vm.domain.0.stats.free_count: Free pages (It seems you are converting pages to byte counts in your report, the units I'm not really worried about so long as they are obvious.) There are also figures possibly tied to the handling of the kill activity but some being more like thresholds than usage figures, such as: vm.domain.0.stats.free_severe: Severe free pages vm.domain.0.stats.free_min: Minimum free pages vm.domain.0.stats.free_reserved: Reserved free pages vm.domain.0.stats.free_target: Target free pages vm.domain.0.stats.inactive_target: Target inactive pages Also, what value were you using for: vm.pageout_oom_seq ? > maybe i'll have to gather data and post it online for anyone who would = be interested in seeing this in graph form. although, frankly i feel = like it's a browser problem which i can work around by running them in = jails with resource limits in place via rctl. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 29 19:38:27 2022 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 DF81F1AAA5BB for ; Fri, 29 Apr 2022 19:38:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KqjTN63YFz50yC for ; Fri, 29 Apr 2022 19:38:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651261110; bh=VOCGdns6kZ5fmWcno+jU0r78NTqXttNuiJ/cag5e3sI=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=ovOCWO/cGeynefRHvMxDVsABOr6AR16PZSaZLRea/waVlB/5VMU5pBgBP+BdNuSmgm9iduQgGjd3ReXuoOejJZ5ioEXruc/kMoH/b+HQjXYL7kywI8cWapzKzX+Ya4yAaqxareGp85PDh6DYKsEEbNWkYA5x4fmbnsT0GTdI1xgfjlsEQX2O1Nv0EHcNVNP5UUa3OxTNpmIbyz8atVi7lg4qsR6BTfBt0Q2YYgcKYPdOwOhmFiJP6qyxDM6F8zAu91DYDLue+6iByQR1r78RaMVFtwY80EY4LWxanozL3JQuy6CpB64eXtyrsYR6rJmGSQ6XBoJ7YnsphvIuevQW2A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651261110; bh=r5dlDL6/1dZucbvulaTOKWODycgWgkDHI3Ae9Xdb/4N=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=SsbgszARISaA7X3wA4mAXWfabIC2APrHJfdoTsURPEH7u4KFdjjAb/Ac5idwtM2pApB0EQQT2jHfRVTo4VW/gLc2jp0HRzisvUZvVkWJUNV2Qgt8wF9M2qJW5aaS4APXyLj6OfEXNAIR6P6l5iYNkP8B3lay7HnYA7yosUCDXwxxUkLgsgLph2ZxZsXPUZYBfAWZNic+1KNFACMGsq0SI95Unki1rNl9TryebE9pMu1KGBngbCGezVZY0/Tehl5+4fWhOo+rsQd5aTv+X/2JX36W1UW50+A+qTYyAKcW7pztgsctv87lRiZhX5Hjo7NELnevcbS+Bt3uW3zQ8PXDIw== X-YMail-OSG: iQm5qXQVM1mXwCBh0PdlX6VFuqxDo5VafZZcq8cy68jfmvXVeoTZAEHmbtPlDEU ppPt1BDR9g60dWa0.137srtg9qRJQdpUSGqfGP3uNlw5HSVinysu69pFZ6_gyOpERptnQXeqc9oM .a41eGfxZL0vhKzRHzd.K.2paW5XgBUyR1vpK_9zg474cOyZShWJ28KajF2rmIrWUbWangw4FKWd vww1UEvdeku8W2_fq8zFSJfKic8_vRwkBOVI4urygxog5AW8RwjHW1qUtHh2VCz6XO9npsVgbKq7 GGinU66jiwLcf5E3Fro67LJl6MD2XXiogEb_BKiRujzum5SFBLpbmkTgEXbf5iThGYuWnvyfoaLZ MFQ.NfbSka83Bzer7biMHaxXwH1tEOf6b33XH6yWTla63M53f3mxyq525e3SMvhO1.s_TidrHwti MIQTWiwb_mXnLUvI3GK2lstuoKld0ZVw_SLRHouUCwv0_DVc9CGKgzEh7u4hwSx1g1jCFYZpc3Pf Dnx6LeoiI39jZJ7wUnl.KxE5djbUjpWfX15utTTi6pKl4nQcCLW4ZcaydCy2lqmEFso47acSOpMF .4UJKHTUYNKiaBut3H4Rto.c.B13.Q4UXpZcpcStxkfBZ56gEQcgw5F4k4k.EYMCMC1ieQETWqyf yvUiXMmtpReKL7Sd8ROHqx70pznB9UxT1CPAxncT_UurVuUJKMlU0MeMF8Oz3Q1m34NSX4LIQR_V GV.APUG__jFgHn9hg181HBJvs_V8B9zzxpL3TbGSbaS_jDRHB4H4TDg59PELAMM34eHJfUddv9DE kZ72aPV9xo79y1T.jcPWN0U0vYKrCSku9GqpQu6jk_Baak3HRwP_EpoQC6o8BtIJFTRQRbJr.SBj MytsRJIWmCvp.B7M.KamqymTWkcdPvLSJSInQxrGjOSwx6eNy7po7qARbopWPMKsSCMidZlGYEjr _h_mBAjmi9poLGkIq5CmTBE0WEubjhmIAjVG5oQHb2FV6.5sr78VA9cXyJo6Fny5KK5Ck2NVySOh LCJRt2XRmf6u9ha8XH.4B3yFY7v4bnGmTdWgBAQIHHe1VDD7EjMolkiJSjMG_qOOQXVnIa8S1C_7 Bm9E24XLRtufSvImeisM84CX13SUa02F__KUTX6X17tj9RZEYBtUeM7XCW0dxeFgxEhagLNOA_bY Kf4E5ofU2S4MSnpGlCYFgR32auZ2923yVbXL.mcICUU3vnLxmLe5O2nLgx9xqlnwDT5UgiAhSMQ6 hy_B_g0780.KIdN.nuoSSzMW7C7fa5xPPpPTu.nExrsLgKONwKtR2Od1aPwql2l6hiyXLaPc0Skq 9DuxZlVi8w6T0UtEQah_MaOZSxcHaN128DFeTfa2bJnQMY6aCoGksnLbPWFDCfNSXO96Pwalc0VU ater471hso4N5YnJVmU4kRBS.n0P6tUU8NVWFSyladRT.UBE29udeuf4.h3XC7oAiN3RPwmQw56K LzPj9loFJHVa8OmydpcwEFUavaNtLCXMq0idf_5BXfUeydRrmZCeo9FoNNKyXg0ENlaNc0f1ZsHG 1Atkv4rcgyx2buf0VLQJgKu2fKukTJofReZgMrw6sK35jmt_yGqjMdADQuk9IamJcSjTSA8S8bva IY.gZ5E5uTCjrIL2LO_spwc7DNrcOd9fih7ZO.rgnEkf6eyPOP25vZaO1KlOf2rzSt0uiwQf0vrn Ze8E2lTPZeTN44b70bUJS31qrADWhPE3RxEtn095ZrWhKbKA0A8m3U1m2gbo6EERo.RQiBkp4Al. hFr3_.CO6B_KYdTdt6gmNW3b1wMGwfYfS.g8eSxRf039Jo7tTAx7e4tKbvxPbNnU6DPwJzOF18Ur f.OcrvF__g2yeQlwRHbM5EMfAZJpYPIby15lUgeuWK82xq8siQ94byAZRg2xvJU3M9RsO4FZRlPA LRsa.15uHS7yzHNbcijil5IbZJ2aIamEF_M8R9hhnUGnzu3P9ViQLLUOUT75Ft87YNAz7fqHCfOL Vcghq8LhZPypMYpkDCBKvB5nHdDRIk6nG6lipvEVSWodXLZhXJe4u4tPuwQvREBjEOI1n4TuXr8v EpdNn88KEuWBRWVqUVkoI3aSlfKVymE9NwT0EFOldcYicA7AV_kvcn58aiiMcMa1gF_gBoR8B0sb lzux9ky5A_KqIBadDD.Lo54EXgVTHEBi3oMkqAna2UI9jbqX1ezw6B5m9xB20S_sSz6oLi2y5gG6 0NyOfrEGmVCNaB7z5gA1Pk0_IPMC48hHmuKfsbEj2MnAJtYbRjwPLowXKfdn_3zD7kdm3oUG45QY fTVY8RxQZJRbVDR7MDsKV4AHouv5LVJiKFYrV_JlAZ6G0OAVPxIfOLiMI3tTHJ6FDupTFQdFTgqi jxFZBq6SyAks3 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Apr 2022 19:38:30 +0000 Received: by hermes--canary-production-bf1-5f4c6455f8-qwrqm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID de371db9d877f2708bb70cfae9e539dd; Fri, 29 Apr 2022 19:38:29 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Profiled libraries on freebsd-current Message-Id: Date: Fri, 29 Apr 2022 12:38:27 -0700 To: Steve Kargl , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4KqjTN63YFz50yC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="ovOCWO/c"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N h= ttps://cgit.freebsd.org/src/commit/?id=3D175841285e289edebb6603da39f025495= 21ce950 says the following (later), but first I quote the part tbat dirves the interpretation: QUOTE Clang's -pg support and mcount() remain, so building with -pg can still be used on code that the user builds; we just do not provide prebuilt libraries compiled with -pg. END QUOTE No WITH_PROFILE options means no "prebuilt libraries compiled with -pg". The overall notice was: author Ed Maste 2021-06-27 17:21:26 +0000 committer Ed Maste 2021-06-28 15:36:59 = +0000 commit 175841285e289edebb6603da39f02549521ce950 (patch) tree 9c2d3b05546961457bb18faeebd2302a25559b49 parent 243b95978debac3db06df6d26ca9f8d84f6cbd83 (diff) download src-175841285e289edebb6603da39f02549521ce950.tar.gz src-175841285e289edebb6603da39f02549521ce950.zip Add deprecation notice for WITH_PROFILE option As discussed on freebsd-current [1] and freebsd-arch [2] and review D30833, FreeBSD 14 will ship without the _p.a libraries built with -pg. Both upstream and base system (in commit b762974cf4b9) Clang have been modified to remove the special case for linking against these libraries. Clang's -pg support and mcount() remain, so building with -pg can still be used on code that the user builds; we just do not provide prebuilt libraries compiled with -pg. A similar change is still needed for GCC. [1] =20 = https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075105.ht= ml [2]=20 https://lists.freebsd.org/archives/freebsd-arch/2021-June/000016.html MFC after: 1 week Sponsored by: The FreeBSD Foundation END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 29 19:51:12 2022 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 76E111AAE00C for ; Fri, 29 Apr 2022 19:51:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KqjmB3gzBz539j for ; Fri, 29 Apr 2022 19:51:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651261875; bh=0qcW9yamdVCxKKHzAPLcI6WzWTyGyGzOBNRGb6gJYH0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=paG3SJhGcUHgSS2dmida5yth1oYjXNIVk/uMFip+cM/Rjxx1Y8mvEZCqhvsqTjcOdP/mJtDOLdDA1hNDDWxctnbvgBm9kfRAMl7pCl+x+NyuLtABmSpNuAmjd/2/5sFIjjfW/XzItEN6tujYXgKHVX4idpegH33xPogNgKSnkhQRi56+FLnLoOife5VPxhPVKIu3J5as3eIY8pthtsBoMI9v1j6bwSQgPaj9qT6XmAZO1ZmUnvw8zu5xZUPTGo9EDWLWbpufOr9CQIeEtJbr/L5Ziyay4lYtufhypcV+m38y7q+gSC6xC+8ZK02FTgpQxb5Do33Vfd1iiiV5uV1TKw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651261875; bh=kEMGC00mUHk6A264lpsspmvqutXfAW/D1GR+ZdlraO+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=VgKmaDIQa7l7Lgz3OJ99lXFI/shaKzFhGW1+yir5RlH926SUdy/aq+XZBh5LDV0DnCdhfrLf5NeSxzXtYkwfT4cc7UdxoRdwa2E9TkepHl4gbGr1JkN7QLvCUUDBHnStCXjm0auNB3HCJ4TDqig+7eMoB3KdvoiQ7sF6AMROrzclmo67mhOrodiAgSqcPztUPoSNN6EMDMc6IrWIOF83SMQ3sDQDE/MQpEoJbLo36enB3A8aMdq0PxFPsNDLStixMW99U3Gm7z+SMBpkObPSygO1RRruFjTtokbrJqvLmYCnE0JzNWFKOEff8GzcSjUYh6KHr2n9NYU/9PW5d1myBw== X-YMail-OSG: 4GNyiJUVM1k_04kZgJ2G5IR0p6ll2BCkStIjvLQPGYLZ2ZkICeHDygN3WqtvA48 bTwggpmGnLH2uJwkZU_SJPlrlflxQ__hdJmMc7vMAppDtX4ay.HIf_pdQ4Y0qGNM7QiXPwAzqXm0 OsQqK2mIwax8WbLGmdt2VaoOHmHYM4N.SSWLBT7.XtqOBUnq1h1zbthr6dbtbPhZrszn6lebytTa YKVKuPYUPxBIjTPSlK3OEDdUUAixxgf0Bz4Y0nREiQCN31_NtIL.z9E9.GHUS4aFyZyZQ0ZG932D AzVd6jYR9hREaLdxBSplrTnByT4ndOG3UTMmwQc2jaPFI08qYFbBWIYX6KIUeuFe1EIRp1Fjww0H VkAyTlkkl5j26.8ns5Tq0LTonvchXZKrNUUPBWHSwcknEBjdWNeouBIGXqgbI6l1_LmoZrBwx7_B 2N4BbwxHN1I7RGMXyL2Mq4U1zMun3skIyg0t6k1kHudySRnprtbmVJ0ndr6CslFhTcXbLmxCGnTf eUCfhshkbHQ9LTd2UxQIr8N32moKe5R8ZcndpykjUdDVw4d8b1.ZSb6uzvmGqX6lU9qiNRnxSprK 6o0dlwgVCWIMHhzjPyXK7gXcpUNUx3FiSGgdUeM5eF1dk4g2ZaDlyJKYnn1aAbc51kc4MpeI7C3Q LkMxMfDCWulq0VX1w_mZb2zOX5bCpk.u4YfHhZoFO43brYI4lEmf1FhSd_cFJ.IeQt5OOks.eKkN NbGaOUt_aB5x6DNNpIWzxuzr6bK_GDRrjPA7UHxFxwRsXrX5X5fLohj65wJuLZyOkpMBcrZWGXBb aVF9lZRUIF.CiJg7Y0OiXlYur1wcZQDivYCdQ.aqCJyoc5UUORhkSYltDpMT2jSiesP9urKjAOWT DLcGJm1b7pSm1rV.7PkVpNuWqsO4gBOfEf5UuikEadAK9tXZ1couFTP475_n2uQIjwX9s6NqJoUg zv0CwcZ8pq38rdjjHsybRq1xqrWG8yeIvhUPGlEQRSWAvt_Tqu6vQcnOmIMDlQJcTVtIUJfzUXE3 sGQ5o7o5dZqL6D_O3GJAXmXED34K78IfwHHjyTd_7v9A2Z8_BH6F6J_n_OhGNqZOorQoFlUnXgyL aP9tND7gn3OpFwWXgW8wlu8pbjnFQg8Trwt_MjY4f2bcEPYJ.AxSatCLZirOMfqZZ8tJXYh.Nc7s RxWXtq9dE.4tJ6Z6KTUfZUwBihYjQVtlOUMNrOLe._zk17zf2MQGeZpjC0mGQwmCC.2Yt5ffCbut 1_SwD0qZmcqboNH7p7Td.pLk7fk1kW5B_OpDFP6mTQHQnBqrvzmU8dxwCUqzUvP9ggRlurJVeZP0 JoSzxkBl3.axPkJej5P90QFuRDM5yzC8_h4Hg_BM1Xagpxpkk25NFS5ASJJOKiMSNr4sNEFvW57q vzNXaI7WOfWSJGWI2OdWDA4DDwDjU3ktZIRy1wopcaTvQx2JxxdviY53bEJKhOWhf872Pe3CW9nj drhQLLBdoXB_lLEzPkIgHcZHBLrDFyh42B3BAPA6uynM0Gvo5iDm7lOus.u20TRVprdFpos_LoW9 8ZfqN89ajfxFIMKeRNw8fDvl9JZfC5ynJ_sOwfLjyENwF82nJbGzYt1wA5VDBMyvkZnJJnR.yXXP wgPvVzDKMrkkURTYgqj93xtcDTTBCdLUTehAOuIDBgxtdHtZ.MIcZnKh3KH7o6M6lMU7XsVu26s7 x5MkOiImen7ji_rHc7SbS_prK6SZR0Nf1mnqmuWGuMn_IdZHsSKIVECI7DZovWOhuRnPU60_hISj GOWb10akZkdIkidcfTGR1MoNPuq34sdYZmXDjr9UNSre624.15_jBvOL3UGNIJ0UaCx9Dp3_0i6. ERLTORnXUf.B280_.ei2i9X.JKK3pC5htJ0eKqYb2HRbeyztR7JcOziEy0trZ0eMXGRR37oS6YPO TQNfG5Q6tLV4JmqyibhVWOYPv6uXJO29Lv4MxjQ7JkEfwEqoU1N5znaLkFVqRQ0_5nYnw_ulDfN4 CKJOKdTgBuI70iQgY13UzgbbvEhSyzqklodErsv1azQ091AO80Cxu46mqMe8_Zg3hsvXoJk3kQaz F2SzeefvaU5sKEatmsvqF67AeAiLSdBzBhpS.FBrCQk0tXF.kobl87Ju0PBXpqGrXFXIZ.AfbZNU Y.H5Mi3eyBP1T908g6PJjRaWUbu_iasmnBWEFaLZVlTD5WEFmGHXYm9efz1aE_MGUujkjX9txm0O zCFwa5KIgMM3O__6oWrcWHlnZ_mL1_ZAXspI_DWJTQ.aUpzt1GPKpb.FE3XtmjayETQeEtilMW2N kj2smQ_CcsNBnwDAZbmx4p9MLOJD0.1_KokCexUabL08AUHbKuUxYnDqy.4F7_IE8FxWCxMoHKis K9P3S8.aPY6EvwQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Apr 2022 19:51:15 +0000 Received: by hermes--canary-production-gq1-647b99747d-ndj76 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 79fd6cb74c52b38fb4cb9ee6a9482658; Fri, 29 Apr 2022 19:51:13 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: Profiled libraries on freebsd-current Date: Fri, 29 Apr 2022 12:51:12 -0700 References: To: Steve Kargl , freebsd-current In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KqjmB3gzBz539j X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=paG3SJhG; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; NEURAL_HAM_SHORT(-0.80)[-0.804]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-29, at 12:38, Mark Millard wrote: > = https://cgit.freebsd.org/src/commit/?id=3D175841285e289edebb6603da39f02549= 521ce950 > says the following (later), but first I quote the part tbat dirves the > interpretation: >=20 > QUOTE > Clang's -pg support and mcount() remain, so building with -pg can = still > be used on code that the user builds; we just do not provide prebuilt > libraries compiled with -pg. > END QUOTE >=20 > No WITH_PROFILE options means no "prebuilt libraries compiled with = -pg". >=20 >=20 > The overall notice was: >=20 > author Ed Maste 2021-06-27 17:21:26 = +0000 > committer Ed Maste 2021-06-28 15:36:59 = +0000 > commit 175841285e289edebb6603da39f02549521ce950 (patch) > tree 9c2d3b05546961457bb18faeebd2302a25559b49 > parent 243b95978debac3db06df6d26ca9f8d84f6cbd83 (diff) > download src-175841285e289edebb6603da39f02549521ce950.tar.gz > src-175841285e289edebb6603da39f02549521ce950.zip >=20 > Add deprecation notice for WITH_PROFILE option >=20 > As discussed on freebsd-current [1] and freebsd-arch [2] and review > D30833, FreeBSD 14 will ship without the _p.a libraries built with = -pg. > Both upstream and base system (in commit b762974cf4b9) Clang have been > modified to remove the special case for linking against these = libraries. >=20 > Clang's -pg support and mcount() remain, so building with -pg can = still > be used on code that the user builds; we just do not provide prebuilt > libraries compiled with -pg. A similar change is still needed for = GCC. >=20 > [1] =20 > = https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075105.ht= ml >=20 > [2]=20 > https://lists.freebsd.org/archives/freebsd-arch/2021-June/000016.html >=20 >=20 > MFC after: 1 week > Sponsored by: The FreeBSD Foundation > END QUOTE >=20 I probably should have been explicit: the actual removal of WITH_PROFILE has not happened yet. So testing attempts to use it are not yet expected to have the new behavior yet. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 29 20:12:57 2022 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 19B751AB2A8C for ; Fri, 29 Apr 2022 20:13:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KqkF71HR2z560g for ; Fri, 29 Apr 2022 20:12:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 23TKCvNZ021945 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 29 Apr 2022 13:12:57 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 23TKCvlI021944; Fri, 29 Apr 2022 13:12:57 -0700 (PDT) (envelope-from sgk) Date: Fri, 29 Apr 2022 13:12:57 -0700 From: Steve Kargl To: Mark Millard Cc: freebsd-current Subject: Re: Profiled libraries on freebsd-current Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KqkF71HR2z560g X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-0.68 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_HAM_LONG(-0.68)[-0.678]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.996]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 29, 2022 at 12:51:12PM -0700, Mark Millard wrote: > On 2022-Apr-29, at 12:38, Mark Millard wrote: > > > https://cgit.freebsd.org/src/commit/?id=175841285e289edebb6603da39f02549521ce950 > > says the following (later), but first I quote the part tbat dirves the > > interpretation: > > > > QUOTE > > Clang's -pg support and mcount() remain, so building with -pg can still > > be used on code that the user builds; we just do not provide prebuilt > > libraries compiled with -pg. > > END QUOTE > > > > No WITH_PROFILE options means no "prebuilt libraries compiled with -pg". > > > > > > The overall notice was: > > > > author Ed Maste 2021-06-27 17:21:26 +0000 > > committer Ed Maste 2021-06-28 15:36:59 +0000 > > commit 175841285e289edebb6603da39f02549521ce950 (patch) > > tree 9c2d3b05546961457bb18faeebd2302a25559b49 > > parent 243b95978debac3db06df6d26ca9f8d84f6cbd83 (diff) > > download src-175841285e289edebb6603da39f02549521ce950.tar.gz > > src-175841285e289edebb6603da39f02549521ce950.zip > > > > Add deprecation notice for WITH_PROFILE option > > > > As discussed on freebsd-current [1] and freebsd-arch [2] and review > > D30833, FreeBSD 14 will ship without the _p.a libraries built with -pg. > > Both upstream and base system (in commit b762974cf4b9) Clang have been > > modified to remove the special case for linking against these libraries. > > > > Clang's -pg support and mcount() remain, so building with -pg can still > > be used on code that the user builds; we just do not provide prebuilt > > libraries compiled with -pg. A similar change is still needed for GCC. > > > > [1] > > https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075105.html > > > > [2] > > https://lists.freebsd.org/archives/freebsd-arch/2021-June/000016.html > > > > > > MFC after: 1 week > > Sponsored by: The FreeBSD Foundation > > END QUOTE > > > > I probably should have been explicit: the actual removal of WITH_PROFILE > has not happened yet. So testing attempts to use it are not yet expected > to have the new behavior yet. > The evenual absence of libc_p.a and libm_p.a will break GCC's -pg option in GCC. One will then need to know how to change the GCC source or install symlinks for to point *_p.a a the *.a libs. -- Steve From nobody Fri Apr 29 20:41:15 2022 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 C55A01AB7CBC for ; Fri, 29 Apr 2022 20:41:19 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kqksp46tRz59Qc for ; Fri, 29 Apr 2022 20:41:18 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1651264876; 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=41UXKa+LLprShwGi0fw5VZCL2xjaNsEl7RaOVcg4ifY=; b=qAZ2K6B+er3cVu8rHiQ3QilbzNLcFxbaysDkHUZq9iHOgiEosW/eVTb46SQugshJDvCR31 MdX/hOw3Y/7caYTtlaSvPE1AZ2jZDP2Uj7I0n9D061q/q9yKVsEV5okMt4q+7zZQ3XqdJN fYkxp5wDOVkijtLrge/a6OLkCorQMJU= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id c26f386e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 29 Apr 2022 20:41:15 +0000 (UTC) Message-ID: <446d5913-a8c2-7dd0-860b-792fa9fe7c5b@nomadlogic.org> Date: Fri, 29 Apr 2022 13:41:15 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Content-Language: en-US To: Mark Millard Cc: freebsd-current References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> From: Pete Wright In-Reply-To: <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Kqksp46tRz59Qc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=qAZ2K6B+; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-1.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.70)[0.699]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/29/22 11:38, Mark Millard wrote: > On 2022-Apr-29, at 11:08, Pete Wright wrote: > >> On 4/23/22 19:20, Pete Wright wrote: >>>> The developers handbook has a section debugging deadlocks that he >>>> referenced in a response to another report (on freebsd-hackers). >>>> >>>> https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneldebug-deadlocks >>> d'oh - thanks for the correction! >>> >>> -pete >>> >>> >> hello, i just wanted to provide an update on this issue. so the good news is that by removing the file backed swap the deadlocks have indeed gone away! thanks for sorting me out on that front Mark! > Glad it helped. d'oh - went out for lunch and workstation locked up.  i *knew* i shouldn't have said anything lol. >> i still am seeing a memory leak with either firefox or chrome (maybe both where they create a voltron of memory leaks?). this morning firefox and chrome had been killed when i first logged in. fortunately the system has remained responsive for several hours which was not the case previously. >> >> when looking at my metrics i see vm.domain.0.stats.inactive take a nose dive from around 9GB to 0 over the course of 1min. the timing seems to align with around the time when firefox crashed, and is proceeded by a large spike in vm.domain.0.stats.active from ~1GB to 7GB 40mins before the apps crashed. after the binaries were killed memory metrics seem to have recovered (laundry size grew, and inactive size grew by several gigs for example). > Since the form of kill here is tied to sustained low free memory > ("failed to reclaim memory"), you might want to report the > vm.domain.0.stats.free_count figures from various time frames as > well: > > vm.domain.0.stats.free_count: Free pages > > (It seems you are converting pages to byte counts in your report, > the units I'm not really worried about so long as they are > obvious.) > > There are also figures possibly tied to the handling of the kill > activity but some being more like thresholds than usage figures, > such as: > > vm.domain.0.stats.free_severe: Severe free pages > vm.domain.0.stats.free_min: Minimum free pages > vm.domain.0.stats.free_reserved: Reserved free pages > vm.domain.0.stats.free_target: Target free pages > vm.domain.0.stats.inactive_target: Target inactive pages ok thanks Mark, based on this input and the fact i did manage to lock up my system, i'm going to get some metrics up on my website and share them publicly when i have time.  i'll definitely take you input into account when sharing this info. > > Also, what value were you using for: > > vm.pageout_oom_seq $ sysctl vm.pageout_oom_seq vm.pageout_oom_seq: 120 $ cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Fri Apr 29 20:57:56 2022 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 BB73319990EF for ; Fri, 29 Apr 2022 20:58:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KqlFG3zBBz3HJm for ; Fri, 29 Apr 2022 20:58:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651265883; bh=iiLvSKqOpOwiamcyprZvGk4SJsJxCgjGZupXXvLXoOQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BBKfV6Syy9LOkG1cJC9RCkFzdfeJRT1yVvUew+qDczQL+W/KnUKpKj18GZfLP5ABPF31PqAV81hGeDe7BFxt6IJnBUmTvMNaYempk9Rt3EGc7w6g2Tph+t9sfQeImVnN4oY4GlPGPftCwFAxqwyGkCdUmNXnySuMJuONdVvbdqLXMqxYJ87dkoqZqHNucmipfabcziHGT2ZPfUHMiKWPVdiw+VIENjQLHM2TDagCy8L5IWIlSNAEURCpxEMNw6vmc+/iJ1g3GmCVE0N3We9Ez4L7mlGKgQrkk2dmEgGKdE+Xau/6DZCQM+7B36TVhzv3HG8A3KaG2nsIQqmeeCIGzw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651265883; bh=Ks+WwF0jv981hHWqK40JUFw8VHTds2/h+T7/VAatoh9=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=h1joWWDnOZgI2E+LPRhnCS6sbuw5EqDrup8gqtLrUgRA7cuEpen1gKm01hO0mKd2HawxX3Zp4cOOvcp2CkzpopFMsPwFvqpwbsXEkC0G2p3z0ZuhDe6y9KhgxLbJspjbBSs7gHj0qPmlhU4xCq0XI3wEqZKa/2PzedvLn2GkUI9hIKPnR6yWW+51MJfqnKDSzmbIJSNNofVA9/oqGxvhtkx2kALhPSYcTLeOs05u4RX05r6Yikitio90yG0XJUf9Hh8PhK4B/xFPlvdfoNeCFv7He5jH/4oO+peDXwit+0B9BHr6acyOpOwUVaezh0MFAs+EYRbd8QAoB/aeY6rMxg== X-YMail-OSG: Z.Ff5P8VM1m644_Oc735IW4UL4xYh7wiHKyKy9z_P4NTZFs8AO1RiSizJJKGX4L kMKixt5uvssjGP7zb1nqpOWmmAjt8O33127i2Z1MsZ1GPX44RK1AXaW7_WUcgbcVyznF1bth585k nDxg6AAkax8aseg2v5yG6cdzEtX2Tp_KJMvYSDGFWV2n_t7YnfzVAABga1zdH_v3JoB0JFepq_aD dyv7C6LtIXIlnNqjtL0HOLi916IwW9Gx46VhoguVbx45MT1DJMopPwv57VasdXhyTc5qRIrjkQDE uwCwme2TbvOey4gmcnTO94wiOCFbRrIdDe22mO5dwhZpTLkCxKh8TSTRv6QartU3WCWcERNWtX2i w47HpAbgseYjTNO_sPhqYFkRFxItRKpdd6WLsyjR7Zm5MqiE97QG1WJmtXey451NmTkLuzM_8xv0 xLwThw288cqPoHuLtrr2fRHY2DEfvAdc43Z7JFKLEsP4aC_zzgahgwmpJCu2QS_U5rgMGqcU_JKu zqlRTYtxPAdzkNddT6.ME9ON90uylYNrULtjCCVtE5nKUKFEk0eifN9mXfoWeI7us6muMuKbyUrc Ax3IUzqA5EKUM6trMxXqg3n6mjs7s32.kGZKXHIq3jPcrF7hCv3tjlRBroUntprXa9H5l9s5VoBU UyfFUAsdt7Ui.IkWXu6S2h5Npn8DCPSK09GjdkRsqby3.MnkWqgP00GA5QccOSLPwax5ri1zdoii sKygQTTCpoWClfZoRGivSIlaYuFsSY1wj3XfUbBPoml8mohX8nSFywh9iRTiTWhxIWiclSJkMIyC kwCJe.3dNM3wKfOHmmrItIscZldslt1dQZyH8y_1mRDs2GH.Sccc1KVhG5fIwOQ2CgrzemODn3Kd rTQ_2xhwbve2rCIHXa.FwOr7S8aN577.hoeTTpsQcimc2P7epT1zqNbfERpdDxUZF916V1_36mg6 MnsXAkBTSNV_iInbvExPSODiTte652BpzqXY7GxsJyo7I3P41In4EwDe1jNCloEILccNAxdhZkuM Yi.QP0MWlnfrdESwuWKaQoGeyF8Thp0W2OCrAIgiEij9I0D7C.7koVVk86kMRChaLDYu7V13CTyS FxTTh9F09ZkXG8vd_qkcFJukdSxz4zr9iKvBJC1sEPkKrRxdLdSfgt.J75Qv69d7gQn_CazEGsOY n30NGjzDtL6kl4ZZ3viD4JppJ8NngKXLmAuXEDo8JvPxh8Ww2Fqj8mGyBSerjxBE45FYlCdLAhSE vIq71tTQ64N8A7MLD3Rns9IGj.gwcJ_rRg5CNzUKjDf7fZ_hdaxCsbXdRNFgMivSqhb_ww6FUvNC ufoKVr5BPz3VDMEikr7tfB7vgdge4dc5Q5aeE.yb4hifdkc9ZC.0m3UVsEOdz5oPSDBcRnCNMCGC tPEPw9dncwyasNghD5jt5MUPyr4GxfOutThzgKiRAcLNw7BYm.0y8YXE2X2G6lY612kIVrrIIJ.B iqhnVfyU.Z.gYITJ.2k_z0poOP3Zp8EHqTNNtcXV7IYgn._aPcs2Ee9QKx8u1Z2yj8QMc_jf9HFz 17Q4KqvRVFaIA8cB9gzeUI672nIMXvonkcJpVrNQUN6YRrsqTNiFHo2vWYZm0crS.Rlq8DuawzcM 7KaGcouR.ArWqOJN8pnOgGzL.fpL2VbUH9A7yERKQYuHjrQf6m6iJdwscgamp3pD8sTAvBbZusbA LEXeaAsvHn8.dUhUHeeFFSBysyNtgTCLpyJ9C0w9uBaHhksgXPRH.NpOaTSazd9EPPtwYAqUHSSr U89qcdjmmef1_6.vDL4AYo0nN1Mha0nB8FEhEngIrgkTa.f78GNvOQLjSTK.krxaB55QY7yrFjA. gTpWH75XhzcKuEekfERd764CYJzr1r81rNQYoAGIBu0SGcq1MswDks81LmIwkRTch_a3aKuMo1qZ zeBUhbDib_Vk7fdaCoVUEweYwYNEn50CA6d.kySC9accTpGfJwipGj1zvfV79L91k2_Hy8WVO3H8 KLnt9167h4LV9178dkVAXlQv6FBSXVDUgCgyUWs3ntUrf31XeuS9GralWvvzuzuOkpux7iNeqgDL p1YgrdWwQ6umi62T6SlpEE2bk9l6CXUi2rrzUWmJ79sbPJoXxHxU8koejdPvx879cZ_y1Z0buvVq QHzhKtEhlu.zZRt8Xio_qBrBXh2FSOSSvrO8iztbtL9AWvpLVsJIqPQXJsyxHX8mFXBQ4MG21EiU t8IOCA8c.mQH5I4WwgqzBF0r8Gdx3n2KZPiR23lcL21jt_YM4bnI8IHffltCqiolw8lNxpFhukyR ugBPm9E0MHFk6RQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Apr 2022 20:58:03 +0000 Received: by hermes--canary-production-ne1-75b69fcf97-rv68v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 180da11ad4a86d85afbb15ec720be79a; Fri, 29 Apr 2022 20:57:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? From: Mark Millard In-Reply-To: <446d5913-a8c2-7dd0-860b-792fa9fe7c5b@nomadlogic.org> Date: Fri, 29 Apr 2022 13:57:56 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <33B740AA-A431-49CB-9F27-50B8C49734A2@yahoo.com> References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> <446d5913-a8c2-7dd0-860b-792fa9fe7c5b@nomadlogic.org> To: Pete Wright X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KqlFG3zBBz3HJm X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=BBKfV6Sy; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.70 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.79)[0.794]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-29, at 13:41, Pete Wright wrote: >=20 > On 4/29/22 11:38, Mark Millard wrote: >> On 2022-Apr-29, at 11:08, Pete Wright wrote: >>=20 >>> On 4/23/22 19:20, Pete Wright wrote: >>>>> The developers handbook has a section debugging deadlocks that he >>>>> referenced in a response to another report (on freebsd-hackers). >>>>>=20 >>>>> = https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneld= ebug-deadlocks >>>> d'oh - thanks for the correction! >>>>=20 >>>> -pete >>>>=20 >>>>=20 >>> hello, i just wanted to provide an update on this issue. so the = good news is that by removing the file backed swap the deadlocks have = indeed gone away! thanks for sorting me out on that front Mark! >> Glad it helped. >=20 > d'oh - went out for lunch and workstation locked up. i *knew* i = shouldn't have said anything lol. Any interesting console messages ( or dmesg -a or /var/log/messages )? >>> i still am seeing a memory leak with either firefox or chrome (maybe = both where they create a voltron of memory leaks?). this morning = firefox and chrome had been killed when i first logged in. fortunately = the system has remained responsive for several hours which was not the = case previously. >>>=20 >>> when looking at my metrics i see vm.domain.0.stats.inactive take a = nose dive from around 9GB to 0 over the course of 1min. the timing = seems to align with around the time when firefox crashed, and is = proceeded by a large spike in vm.domain.0.stats.active from ~1GB to 7GB = 40mins before the apps crashed. after the binaries were killed memory = metrics seem to have recovered (laundry size grew, and inactive size = grew by several gigs for example). >> Since the form of kill here is tied to sustained low free memory >> ("failed to reclaim memory"), you might want to report the >> vm.domain.0.stats.free_count figures from various time frames as >> well: >>=20 >> vm.domain.0.stats.free_count: Free pages >>=20 >> (It seems you are converting pages to byte counts in your report, >> the units I'm not really worried about so long as they are >> obvious.) >>=20 >> There are also figures possibly tied to the handling of the kill >> activity but some being more like thresholds than usage figures, >> such as: >>=20 >> vm.domain.0.stats.free_severe: Severe free pages >> vm.domain.0.stats.free_min: Minimum free pages >> vm.domain.0.stats.free_reserved: Reserved free pages >> vm.domain.0.stats.free_target: Target free pages >> vm.domain.0.stats.inactive_target: Target inactive pages > ok thanks Mark, based on this input and the fact i did manage to lock = up my system, i'm going to get some metrics up on my website and share = them publicly when i have time. i'll definitely take you input into = account when sharing this info. >=20 >>=20 >> Also, what value were you using for: >>=20 >> vm.pageout_oom_seq > $ sysctl vm.pageout_oom_seq > vm.pageout_oom_seq: 120 > $ Without knowing vm.domain.0.stats.free_count it is hard to tell, but you might try, say, sysctl vm.pageout_oom_seq=3D12000 in hopes of getting notably more time with the vm.domain.0.stats.free_count staying small. That may give you more time to notice the low free RAM (if you are checking periodically, rather than just waiting for failure to make it obvious). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 29 21:54:17 2022 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 65E091AAD83E for ; Fri, 29 Apr 2022 21:54:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KqmVH2337z3lH5 for ; Fri, 29 Apr 2022 21:54:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651269263; bh=N6QAbCiffZiRBgl0er6i7yy3N5VDxKRGR/YXGoRH8so=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=VatY44F6fy8h35wCJdxmwOzc7V+u7VC1oWRlQJ142ruE9z0BGYbEwIE94GOIT/2RvcFNH3D0YZar7c4oRewOqtwOdxfR2gBH/diKS7LnKE0s2Y/nkxC30wKX7uUzgyHlrTR0n68y6Iuxk2Ren1TCaoRz42dKCQmE8Oqgannp04yvERQkOjJVenyUoZgxFKAeoTxHIeK1iDhSAxu8Acp0E1sC0viFbgpomFrdXWywkD3g8FaH8a9DMWDPFCOIipnWYxDATctoiE3iKjhAHhS/BiENXvBMniB7PbyawABYx8Wu26Chjnp9yVoaN+1ZNCQoq56Wvosj4zloYD7pa++cKQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651269263; bh=3pAzQJk3zJU0zg4irGqVOoQhBTB5KhMlFAROWLjBCGi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=dojKeI7pSSF9ZiUDhzvNHRNVI56eo0Qg6y12qGf9Dl4ZxouOg5Q8VRpArUBdJqdRJ8MFVbf89+rzgslO+fleDrHGSAzegoK7Kj0elXb4obbeqbuDvWuI1igrOlbKXArwR5IKBOYVIZsdR5vOF38PFN4fWh45C/JzygHBGVStX1EOtLkj1qp5xFmCUsZY+KpolMbOwrVIEJrTjbqRoA+iM1ceoMRPIPHa8v4QAo5iAhZ1Q667X9RBVXkPiw0UVFJkUcTxPfpCFIRsaCg1EwqM7tv0CmHiZ5R5TID1Vx8s2C44wg93V3rKM15TiUefe+Cc8qXJHGW4G8bV0WKmwRKEBg== X-YMail-OSG: PQ96kx4VM1ne1W2Y9UzHUVNmOfH4qCvGYCMvLJEZlKscBOJqGjzFLnDtBp8eBCP g5UWp9Owp28rB.mwDDGlx4r.RYfm6z8tg3FVHZPkRfScG99RqI9E83j.t11wsf95uJ_YbATF7Ci6 fuDJXLLy13Nm79d2_Ae.20jPgpG1_PvNasBIdcAIVbXl_hdoIiujKQ3wnONqTUqaxrROqzJPn7Jq 2PIJE4qrnG0bzn0aIiY5GbIrgL.jFPsDD2kFHDC2PgkAu6X4b01Lqt4c4SO_id7ySVaKQLkUk2dX YSSAxV6SXePCe9rBfbR1SHPN6gzOsMwFF8V0xFJ1anBe930lJ_yPMB5j97mhaLkgi6ga8t6Ha2Kg kFQ2KyOKDZI7_oaZKTzgt2DWNGQu4Wva5Q8or5DZYYuU_gZLQW_1SPZLzX4s460VauJc5WHkSzCB Nt85O7Uk6yxD63cQ3W5MhUBGmftLyxU.LbMeSEIWpfQVVipA.9r7hjyJNVGiP9IErwu3E2Rr2Lx9 ydQogCkrOgkrGDCj4dmVecJqL0.u6Bi_trX3TT.O5NeJrT5wiPtv1ZsjbIigm5.bVUuPYaXIUag. bu7xGQekvhJ2xVdvG_ObZwax0A0QZVwu3VsPZdx6Vk8GjkwIO3QwS4oIWKLBhWXY0RH6BLOt7xMP Xrwf0N8MdrzOQN.BY4j1ZsE_hb4szNc5mtYDGbkpshSZaJwFo92WVrPfuXpQxne1yd9Zju0ocU3f fB02KHcs4XXSjbtaMqoik.phFEuoch3hgOt0GH_kGO7gjY9oA8gjTsWizomnNV5L3l2.pOI63eM5 i8bpIJOyyF72UtAgd57p2xj4rriD33h7J004xRbQvecstqUTKT4rPS8MIk1NRya7ELfAMktYdrSY 94_d0UdTYz1XSfCmKF5KDdeOatrxWJyd5F0_2ge9Qsoti.7FiForedthPWTOQYJqhF4.cJbOAxOD c8P39YWxbgdXzCHa1QVfdoF.hZm0aPrC7iK6QwPiXDoUiXPHKheDk_X75hURxLKMV8Wey7RRn_tF raq0qSKuVPNxMhfqWa0CrA7AW3XsUP5vTXSVfp.1Q3afX.JPKeVi08F1Ncju0JcjrIMSxNOcE2Sr nkLsKm_YsUYN9YLrMC1s0bcTwVN5lFcZSjBrF.P8uADODumM8JoortvIdwEtq7tRDMhCl_huf_8n 2WSHixqgLtUJTWCmeJsgnU5pGt5xlY0kGHJQ5OpS9lPVpFz0wk45dNt9cN4CXoixGJp93x4ZRMiQ UygH4qI7BEqq3u5W4BsE6DrftIhAM8KBrjSQzIWCoOGv4nJS6HDa4H4r0mJK808jyqERty3v2r9Z sOJ6iGd22aRU3AUN2Qh89KcyE8HNy9qRBfBcwAjHn0J_DNDH9W_G712j4UC3Hu9XiUhGkaR4H2BB JQPCi16CJ9SaIryQwnapQUYfQdMP48nYMcW9SBkdeRE0IWJlelCOcJmV9CqC32xLHNr1E0zDFZqn BfWqECGL0fZiFJ.h5ajBS1Nb9C7eHg2ZLM86FiVNOoh.MhDhO0BtfwzU3gHewc9QVRjWNoia8tbm bfn0U0QHN1ih1uxtVEkrO2WujSemXFwYsg.s9ycipflys2h09gJRa.6qqA.GjQ6yHTPUZRIHcliU p9aRxSIvWe5ZOOasPXr_Pq6KWy5jKbgyoa3ZR1s1YnXMh6eJdoEIOfRcewfC89qjHXfc__7yQRKC YRshlIRITW1Ow8kQxxTIVvgqodr0T9yFjgvKlLpKk6LdOOw0MAD9ZbjGn_t1_2s3IyIaKgzTDco8 pz1L9yBsTSRL_jlgycbdKZsVmh3NcLeG51xp85bEkyEHL4nbDBSAg0Myq6_RxtUlwFW0JMVHKBGU Qd2b35ecDnUhKpwMLc0DhEUjG0TMzl3Kf.tlUaL24HBFvqIeu3qA_NWi8SPhYHMxMsU1ZVhOiqUT JBU5NBah20s23W2Gxib4gMM2lnDKxel0r6d.XctSvbw4_iZ3epNgXjcM1li3sqCXyWmW0RSBeKCE i4yA_ZT_BfvGKtEslg33t_yeWw3A3dx.Gr3Ouk8s14FDVwKbug1xTbPBwBrd7ABVuCKnbJDRZzkD dbJOS._5IIKIhcsujsZnMcFa6d9NBsqKVxdzBFqucgAyroPqS55rYCb48TPQQcTRStHiU8ylNX7z ekG1Okbhjy_uIbPx8_8xMYyDNaHI2sj134GHHfRKYl7d4lRxH0tqEnH2EL1DBXqpArjajznoI2cY ZVW8QzCu62rmWvMEw_5YLu9Iah21lgDrXnxR2L.a0vP5ueEyaDo6OyOuuAwc.8QIvoBKxH.gTej9 aJYa1JiiXO3XaTRffwEO2GcoDa1KkBeZUpFhjGe.kgirAOz_fSkhLKsd.QV2OZBL_vPLhJRErONP Y87jlpSVP7ssVJ6JQ X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Apr 2022 21:54:23 +0000 Received: by hermes--canary-production-bf1-5f4c6455f8-qwrqm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID da198588c7a41d8ffa4a7ffc6903fbe5; Fri, 29 Apr 2022 21:54:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Profiled libraries on freebsd-current From: Mark Millard In-Reply-To: Date: Fri, 29 Apr 2022 14:54:17 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <54761641-8AD3-44A6-8620-F1341ED9AB56@yahoo.com> References: To: sgk@troutmask.apl.washington.edu X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KqmVH2337z3lH5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=VatY44F6; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-29, at 13:12, Steve Kargl = wrote: > On Fri, Apr 29, 2022 at 12:51:12PM -0700, Mark Millard wrote: >> On 2022-Apr-29, at 12:38, Mark Millard wrote: >>=20 >>> = https://cgit.freebsd.org/src/commit/?id=3D175841285e289edebb6603da39f02549= 521ce950 >>> says the following (later), but first I quote the part tbat dirves = the >>> interpretation: >>>=20 >>> QUOTE >>> Clang's -pg support and mcount() remain, so building with -pg can = still >>> be used on code that the user builds; we just do not provide = prebuilt >>> libraries compiled with -pg. >>> END QUOTE >>>=20 >>> No WITH_PROFILE options means no "prebuilt libraries compiled with = -pg". >>>=20 >>>=20 >>> The overall notice was: >>>=20 >>> author Ed Maste 2021-06-27 17:21:26 = +0000 >>> committer Ed Maste 2021-06-28 15:36:59 = +0000 >>> commit 175841285e289edebb6603da39f02549521ce950 (patch) >>> tree 9c2d3b05546961457bb18faeebd2302a25559b49 >>> parent 243b95978debac3db06df6d26ca9f8d84f6cbd83 (diff) >>> download src-175841285e289edebb6603da39f02549521ce950.tar.gz >>> src-175841285e289edebb6603da39f02549521ce950.zip >>>=20 >>> Add deprecation notice for WITH_PROFILE option >>>=20 >>> As discussed on freebsd-current [1] and freebsd-arch [2] and review >>> D30833, FreeBSD 14 will ship without the _p.a libraries built with = -pg. >>> Both upstream and base system (in commit b762974cf4b9) Clang have = been >>> modified to remove the special case for linking against these = libraries. >>>=20 >>> Clang's -pg support and mcount() remain, so building with -pg can = still >>> be used on code that the user builds; we just do not provide = prebuilt >>> libraries compiled with -pg. A similar change is still needed for = GCC. >>>=20 >>> [1] =20 >>> = https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075105.ht= ml >>>=20 >>> [2]=20 >>> = https://lists.freebsd.org/archives/freebsd-arch/2021-June/000016.html >>>=20 >>>=20 >>> MFC after: 1 week >>> Sponsored by: The FreeBSD Foundation >>> END QUOTE >>>=20 >>=20 >> I probably should have been explicit: the actual removal of = WITH_PROFILE >> has not happened yet. So testing attempts to use it are not yet = expected >> to have the new behavior yet. >>=20 >=20 > The evenual absence of libc_p.a and libm_p.a will break GCC's > -pg option in GCC. One will then need to know how to change the > GCC source or install symlinks for to point *_p.a a the *.a libs. >=20 src/tree/tools/build/mk/OptionalObsoleteFiles.inc shows the following that does include those 2 files as ones considered obsolete (i.e., to be removed) by WITHOUT_PROFILE: .if ${MK_PROFILE} =3D=3D no OLD_FILES+=3Dusr/lib/lib80211_p.a OLD_FILES+=3Dusr/lib/lib9p_p.a OLD_FILES+=3Dusr/lib/libBlocksRuntime_p.a OLD_FILES+=3Dusr/lib/libalias_dummy_p.a OLD_FILES+=3Dusr/lib/libalias_ftp_p.a OLD_FILES+=3Dusr/lib/libalias_irc_p.a OLD_FILES+=3Dusr/lib/libalias_nbt_p.a OLD_FILES+=3Dusr/lib/libalias_p.a OLD_FILES+=3Dusr/lib/libalias_pptp_p.a OLD_FILES+=3Dusr/lib/libalias_skinny_p.a OLD_FILES+=3Dusr/lib/libalias_smedia_p.a OLD_FILES+=3Dusr/lib/libarchive_p.a OLD_FILES+=3Dusr/lib/libasn1_p.a OLD_FILES+=3Dusr/lib/libauditd_p.a OLD_FILES+=3Dusr/lib/libavl_p.a OLD_FILES+=3Dusr/lib/libbe_p.a OLD_FILES+=3Dusr/lib/libbegemot_p.a OLD_FILES+=3Dusr/lib/libblacklist_p.a OLD_FILES+=3Dusr/lib/libbluetooth_p.a OLD_FILES+=3Dusr/lib/libbsdxml_p.a OLD_FILES+=3Dusr/lib/libbsm_p.a OLD_FILES+=3Dusr/lib/libbsnmp_p.a OLD_FILES+=3Dusr/lib/libbz2_p.a OLD_FILES+=3Dusr/lib/libc++_p.a OLD_FILES+=3Dusr/lib/libc_p.a OLD_FILES+=3Dusr/lib/libcalendar_p.a OLD_FILES+=3Dusr/lib/libcam_p.a OLD_FILES+=3Dusr/lib/libcom_err_p.a OLD_FILES+=3Dusr/lib/libcompat_p.a OLD_FILES+=3Dusr/lib/libcompiler_rt_p.a OLD_FILES+=3Dusr/lib/libcrypt_p.a OLD_FILES+=3Dusr/lib/libcrypto_p.a OLD_FILES+=3Dusr/lib/libctf_p.a OLD_FILES+=3Dusr/lib/libcurses_p.a OLD_FILES+=3Dusr/lib/libcursesw_p.a OLD_FILES+=3Dusr/lib/libcuse_p.a OLD_FILES+=3Dusr/lib/libcxxrt_p.a OLD_FILES+=3Dusr/lib/libdevctl_p.a OLD_FILES+=3Dusr/lib/libdevinfo_p.a OLD_FILES+=3Dusr/lib/libdevstat_p.a OLD_FILES+=3Dusr/lib/libdialog_p.a OLD_FILES+=3Dusr/lib/libdl_p.a OLD_FILES+=3Dusr/lib/libdpv_p.a OLD_FILES+=3Dusr/lib/libdtrace_p.a OLD_FILES+=3Dusr/lib/libdwarf_p.a OLD_FILES+=3Dusr/lib/libedit_p.a OLD_FILES+=3Dusr/lib/libefivar_p.a OLD_FILES+=3Dusr/lib/libelf_p.a OLD_FILES+=3Dusr/lib/libexecinfo_p.a OLD_FILES+=3Dusr/lib/libfetch_p.a OLD_FILES+=3Dusr/lib/libfigpar_p.a OLD_FILES+=3Dusr/lib/libfl_p.a OLD_FILES+=3Dusr/lib/libform_p.a OLD_FILES+=3Dusr/lib/libformw_p.a OLD_FILES+=3Dusr/lib/libgcc_eh_p.a OLD_FILES+=3Dusr/lib/libgcc_p.a OLD_FILES+=3Dusr/lib/libgeom_p.a OLD_FILES+=3Dusr/lib/libgpio_p.a OLD_FILES+=3Dusr/lib/libgssapi_krb5_p.a OLD_FILES+=3Dusr/lib/libgssapi_ntlm_p.a OLD_FILES+=3Dusr/lib/libgssapi_p.a OLD_FILES+=3Dusr/lib/libgssapi_spnego_p.a OLD_FILES+=3Dusr/lib/libhdb_p.a OLD_FILES+=3Dusr/lib/libheimbase_p.a OLD_FILES+=3Dusr/lib/libheimntlm_p.a OLD_FILES+=3Dusr/lib/libheimsqlite_p.a OLD_FILES+=3Dusr/lib/libhistory_p.a OLD_FILES+=3Dusr/lib/libhx509_p.a OLD_FILES+=3Dusr/lib/libicp_p.a OLD_FILES+=3Dusr/lib/libicp_rescue_p.a OLD_FILES+=3Dusr/lib/libipsec_p.a OLD_FILES+=3Dusr/lib/libipt_p.a OLD_FILES+=3Dusr/lib/libjail_p.a OLD_FILES+=3Dusr/lib/libkadm5clnt_p.a OLD_FILES+=3Dusr/lib/libkadm5srv_p.a OLD_FILES+=3Dusr/lib/libkafs5_p.a OLD_FILES+=3Dusr/lib/libkdc_p.a OLD_FILES+=3Dusr/lib/libkiconv_p.a OLD_FILES+=3Dusr/lib/libkrb5_p.a OLD_FILES+=3Dusr/lib/libkvm_p.a OLD_FILES+=3Dusr/lib/libl_p.a OLD_FILES+=3Dusr/lib/libln_p.a OLD_FILES+=3Dusr/lib/liblzma_p.a OLD_FILES+=3Dusr/lib/libm_p.a OLD_FILES+=3Dusr/lib/libmagic_p.a OLD_FILES+=3Dusr/lib/libmd_p.a OLD_FILES+=3Dusr/lib/libmemstat_p.a OLD_FILES+=3Dusr/lib/libmenu_p.a OLD_FILES+=3Dusr/lib/libmenuw_p.a OLD_FILES+=3Dusr/lib/libmilter_p.a OLD_FILES+=3Dusr/lib/libmp_p.a OLD_FILES+=3Dusr/lib/libmt_p.a OLD_FILES+=3Dusr/lib/libncurses_p.a OLD_FILES+=3Dusr/lib/libncursesw_p.a OLD_FILES+=3Dusr/lib/libnetgraph_p.a OLD_FILES+=3Dusr/lib/libnetmap_p.a OLD_FILES+=3Dusr/lib/libngatm_p.a OLD_FILES+=3Dusr/lib/libnv_p.a OLD_FILES+=3Dusr/lib/libnvpair_p.a OLD_FILES+=3Dusr/lib/libopencsd_p.a OLD_FILES+=3Dusr/lib/libopie_p.a OLD_FILES+=3Dusr/lib/libpanel_p.a OLD_FILES+=3Dusr/lib/libpanelw_p.a OLD_FILES+=3Dusr/lib/libpathconv_p.a OLD_FILES+=3Dusr/lib/libpcap_p.a OLD_FILES+=3Dusr/lib/libpjdlog_p.a OLD_FILES+=3Dusr/lib/libpmc_p.a OLD_FILES+=3Dusr/lib/libprivateatf-c++_p.a OLD_FILES+=3Dusr/lib/libprivateatf-c_p.a OLD_FILES+=3Dusr/lib/libprivateauditd_p.a OLD_FILES+=3Dusr/lib/libprivatebsdstat_p.a OLD_FILES+=3Dusr/lib/libprivatedevdctl_p.a OLD_FILES+=3Dusr/lib/libprivateevent_p.a OLD_FILES+=3Dusr/lib/libprivateevent1_p.a OLD_FILES+=3Dusr/lib/libprivategmock_main_p.a OLD_FILES+=3Dusr/lib/libprivategmock_p.a OLD_FILES+=3Dusr/lib/libprivategtest_main_p.a OLD_FILES+=3Dusr/lib/libprivategtest_p.a OLD_FILES+=3Dusr/lib/libprivateheimipcc_p.a OLD_FILES+=3Dusr/lib/libprivateheimipcs_p.a OLD_FILES+=3Dusr/lib/libprivateifconfig_p.a OLD_FILES+=3Dusr/lib/libprivateldns_p.a OLD_FILES+=3Dusr/lib/libprivatesqlite3_p.a OLD_FILES+=3Dusr/lib/libprivatessh_p.a OLD_FILES+=3Dusr/lib/libprivateucl_p.a OLD_FILES+=3Dusr/lib/libprivateunbound_p.a OLD_FILES+=3Dusr/lib/libprivatezstd_p.a OLD_FILES+=3Dusr/lib/libproc_p.a OLD_FILES+=3Dusr/lib/libprocstat_p.a OLD_FILES+=3Dusr/lib/libpthread_p.a OLD_FILES+=3Dusr/lib/libradius_p.a OLD_FILES+=3Dusr/lib/libregex_p.a OLD_FILES+=3Dusr/lib/libroken_p.a OLD_FILES+=3Dusr/lib/librpcsvc_p.a OLD_FILES+=3Dusr/lib/librss_p.a OLD_FILES+=3Dusr/lib/librt_p.a OLD_FILES+=3Dusr/lib/librtld_db_p.a OLD_FILES+=3Dusr/lib/libsbuf_p.a OLD_FILES+=3Dusr/lib/libsdp_p.a OLD_FILES+=3Dusr/lib/libsmb_p.a OLD_FILES+=3Dusr/lib/libspl_p.a OLD_FILES+=3Dusr/lib/libssl_p.a OLD_FILES+=3Dusr/lib/libstats_p.a OLD_FILES+=3Dusr/lib/libstdbuf_p.a OLD_FILES+=3Dusr/lib/libstdc++_p.a OLD_FILES+=3Dusr/lib/libstdthreads_p.a OLD_FILES+=3Dusr/lib/libsupc++_p.a OLD_FILES+=3Dusr/lib/libsysdecode_p.a OLD_FILES+=3Dusr/lib/libtacplus_p.a OLD_FILES+=3Dusr/lib/libtermcap_p.a OLD_FILES+=3Dusr/lib/libtermcapw_p.a OLD_FILES+=3Dusr/lib/libtermlib_p.a OLD_FILES+=3Dusr/lib/libtermlibw_p.a OLD_FILES+=3Dusr/lib/libthr_p.a OLD_FILES+=3Dusr/lib/libthread_db_p.a OLD_FILES+=3Dusr/lib/libtinfo_p.a OLD_FILES+=3Dusr/lib/libtinfow_p.a OLD_FILES+=3Dusr/lib/libtpool_p.a OLD_FILES+=3Dusr/lib/libufs_p.a OLD_FILES+=3Dusr/lib/libugidfw_p.a OLD_FILES+=3Dusr/lib/libulog_p.a OLD_FILES+=3Dusr/lib/libumem_p.a OLD_FILES+=3Dusr/lib/libusb_p.a OLD_FILES+=3Dusr/lib/libusbhid_p.a OLD_FILES+=3Dusr/lib/libutempter_p.a OLD_FILES+=3Dusr/lib/libutil_p.a OLD_FILES+=3Dusr/lib/libuutil_p.a OLD_FILES+=3Dusr/lib/libvgl_p.a OLD_FILES+=3Dusr/lib/libvmmapi_p.a OLD_FILES+=3Dusr/lib/libwind_p.a OLD_FILES+=3Dusr/lib/libwrap_p.a OLD_FILES+=3Dusr/lib/libxo_p.a OLD_FILES+=3Dusr/lib/liby_p.a OLD_FILES+=3Dusr/lib/libypclnt_p.a OLD_FILES+=3Dusr/lib/libz_p.a OLD_FILES+=3Dusr/lib/libzfs_core_p.a OLD_FILES+=3Dusr/lib/libzfs_p.a OLD_FILES+=3Dusr/lib/libzfsbootenv_p.a OLD_FILES+=3Dusr/lib/libzutil_p.a OLD_FILES+=3Dusr/lib/libprivateldns_p.a OLD_FILES+=3Dusr/lib/libprivatessh_p.a .endif I expect that this is part of the mechanism that will ultimately remove those then-out-of-date files from systems when WITH_PROFILE is no longer supported. Metion was made of "[a] similar change is still needed for GCC" --but I've no clue of the details or status. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 30 06:13:36 2022 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 3C0D61AA9A22 for ; Sat, 30 Apr 2022 06:13:46 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KqzZK02S6z3rYj for ; Sat, 30 Apr 2022 06:13:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 23U6DamS023502 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 29 Apr 2022 23:13:36 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 23U6DaRa023501; Fri, 29 Apr 2022 23:13:36 -0700 (PDT) (envelope-from sgk) Date: Fri, 29 Apr 2022 23:13:36 -0700 From: Steve Kargl To: Mark Millard Cc: freebsd-current Subject: Re: Profiled libraries on freebsd-current Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <54761641-8AD3-44A6-8620-F1341ED9AB56@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54761641-8AD3-44A6-8620-F1341ED9AB56@yahoo.com> X-Rspamd-Queue-Id: 4KqzZK02S6z3rYj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [0.20 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(0.20)[0.202]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 29, 2022 at 02:54:17PM -0700, Mark Millard wrote: > On 2022-Apr-29, at 13:12, Steve Kargl wrote: > > > The evenual absence of libc_p.a and libm_p.a will break GCC's > > -pg option in GCC. One will then need to know how to change the > > GCC source or install symlinks for to point *_p.a a the *.a libs. > > > > src/tree/tools/build/mk/OptionalObsoleteFiles.inc shows the > following that does include those 2 files as ones considered > obsolete (i.e., to be removed) by WITHOUT_PROFILE: > (snip) > > I expect that this is part of the mechanism that will > ultimately remove those then-out-of-date files from > systems when WITH_PROFILE is no longer supported. > > Metion was made of "[a] similar change is still needed > for GCC" --but I've no clue of the details or status. > Therein lies the problem. None of the people pushing the removal of WITH[OUT]_PROFILE have submitted a patch to fix GCC. Anyone installing a lang/gccXXX port will be met with errors when using -pg. -- Steve From nobody Sat Apr 30 13:39:32 2022 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 5FC741AB65F1 for ; Sat, 30 Apr 2022 13:39:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kr9T42nr8z3mLP for ; Sat, 30 Apr 2022 13:39:52 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-wm1-f41.google.com with SMTP id bi24-20020a05600c3d9800b00393ff664705so6171090wmb.4 for ; Sat, 30 Apr 2022 06:39:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JGbTD2tcm1IzUcixZ77kL5jHR/K0R3sydKxWZR8zprk=; b=bbO02X+p4LRyF48s9bD41wDm7GBcDWvOQQfG/5aOQY776d95lu6+sFaigUtH56PD2f 4O2i1VcXRHDzZmVMQSdFRTj/mIUl34JCKa27MFT8ILzJ7dQIYAi/Cj50jyWfuFoITHg6 DLeDEK9PNKHUSzfm+GowVqOPfU3PuiKnjLSt4vxt7cnCuk+LUfvK9oT+cLFyKafnF7JI 35wnU8tmjrv0xPmDwXD0HRQ8+p3tZPs6kcxCRIYvXryvCWpSo6Nvhcj3XOBRFgoBTHKQ YDhudro9fAe2EKlebXxoZVSPD521HRtTWV063p5+wYhSE1eQorvn7XvY+koOucWp+91J 1JfQ== X-Gm-Message-State: AOAM532hRywzsxtZMONvaRvJ+zarrd95c+5L04OQ8KnO8hI941rYvW6/ 8hKTi1epVcsMpDTBKe995E65bSSxJOXC6SvXr8DPPiFM+ng= X-Google-Smtp-Source: ABdhPJyfoc5Pbdx1liZBV5r8Y6L/3CdM3cNhvj4G494fjfF7fgRDEG8kPCujdJycTLIXmSpRKcnC1u8RTxSN9MROocs= X-Received: by 2002:a05:600c:1f1a:b0:394:29c1:6d82 with SMTP id bd26-20020a05600c1f1a00b0039429c16d82mr3405121wmb.111.1651325985140; Sat, 30 Apr 2022 06:39:45 -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: Ed Maste Date: Sat, 30 Apr 2022 09:39:32 -0400 Message-ID: Subject: Re: Profiled libraries on freebsd-current To: Steve Kargl Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Kr9T42nr8z3mLP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [0.89 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.92)[0.922]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.128.41:from]; NEURAL_SPAM_LONG(0.97)[0.970]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.128.41:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 29 Apr 2022 at 01:58, Steve Kargl wrote: > > If one looks at src.conf(5), one finds > > WITH_PROFILE > Build profiled libraries for use with gprof(8). This option is > deprecated and is not present in FreeBSD 14. > > I assume that the *_p.a libraries will no longer be built and > installed on FreeBSD 14 and later. Is this correct? FreeBSD 14 is not yet released, of course, but that is indeed the intent. PR256874 reports that a GCC patch (to stop linking against _p.a) is in the works but unfortunately has not had an update for some time. From nobody Sat Apr 30 15:34:43 2022 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 43201199D279 for ; Sat, 30 Apr 2022 15:34:46 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KrD1d1vR0z4Wrt; Sat, 30 Apr 2022 15:34:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 23UFYhaJ025791 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 30 Apr 2022 08:34:43 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 23UFYh3b025790; Sat, 30 Apr 2022 08:34:43 -0700 (PDT) (envelope-from sgk) Date: Sat, 30 Apr 2022 08:34:43 -0700 From: Steve Kargl To: Ed Maste Cc: FreeBSD Current Subject: Re: Profiled libraries on freebsd-current Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KrD1d1vR0z4Wrt X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-0.63 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.902]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.73)[-0.732]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Sat, Apr 30, 2022 at 09:39:32AM -0400, Ed Maste wrote: > On Fri, 29 Apr 2022 at 01:58, Steve Kargl > wrote: > > > > If one looks at src.conf(5), one finds > > > > WITH_PROFILE > > Build profiled libraries for use with gprof(8). This option is > > deprecated and is not present in FreeBSD 14. > > > > I assume that the *_p.a libraries will no longer be built and > > installed on FreeBSD 14 and later. Is this correct? > > FreeBSD 14 is not yet released, of course, but that is indeed the > intent. PR256874 reports that a GCC patch (to stop linking against > _p.a) is in the works but unfortunately has not had an update for some > time. I see. It only took me 2+ years to get https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 committed to the GCC repository. Good luck with getting your patch upstream. -- Steve From nobody Sat Apr 30 17:46:59 2022 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 1FF60199FC79 for ; Sat, 30 Apr 2022 17:47:17 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KrGyX39Dbz3L8F for ; Sat, 30 Apr 2022 17:47:16 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x132.google.com with SMTP id o5so5794593ils.11 for ; Sat, 30 Apr 2022 10:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i2LrHkqHres31uXkjl0U2bj2W3ERh7klCVgzPtGVtZA=; b=kC/rXwxDU3YPgT6tjvxSq64Klf/a/17kU+2oEEsXpU9/ec4dP1tMT2KNOc7X5iLPkF 1psmYRfRjvH99ADR09aHnpZjql7ijCbxhNAbSqjpSNhfGfR1xiRp0cOADjpCtaRyCjnl kCBAXxqDh/9S0RagLI5Ks24VCyrNVv4Z3cxlBQUxrh2fwoimkliHH+NuZ/Oo106BLXeT pYAnX7+QUgw3SIXW/ovF1LQj13JgwEpptk2O25a98j61cSspR/5Qocr6DTLC2Xg8yYOC vWv6Cyq620uVqnF0fnZHynLpZy3KNIlwDg8ihhyVUXKWVAxquoqYJGOr6rlO3CpSKydO iXZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i2LrHkqHres31uXkjl0U2bj2W3ERh7klCVgzPtGVtZA=; b=uGO0blXj3hEYpyGwhn3qVmYadXAM/vwmzC3mFW+TVP313SkHZuEPtw+3SrOHtdML2F oKGrbPxuX/AFvxVB8bJvZRAa+wzqFReXWhIqVXSdhotpCXmuvDY4+bsEUWm8rvdhkI7t W2pSGYzn9JRTdav4uLvXcRiesMFgdZkpyrs5fBk9x3wdvVmDFjuL9qQnEJs0f2OSYSVc ckTHtzV6Qi99YmT5fu28t1DtoZB2HSoAYRvbb8cSQDASa0e53cxfOGCkJdbRsGGIEHc6 cuqpPnD4iF9X9uga+32Ra4mz2D7M8LP/QklVmPB7WeDec3envjb0uIVHrjbqrISEIw04 A7Tg== X-Gm-Message-State: AOAM530IGaKetWVPMh3detUFjNUMQQBz0ryBHhc1DfTEql/27mxl0wIV 9vRj6mxk63X90XdcWiLNkC+YCNEYFC/bFNpUcx86NvTpIoKB+wby X-Google-Smtp-Source: ABdhPJwl/zk9DqMfewz0ENOz2UvW5AdEJsGhPEZ2uAZyMXln6l71F1Hqf4p12yVjqOsx7EkSrNZW8V+ns9XR1/vZpSw= X-Received: by 2002:a92:7d08:0:b0:2c2:d72c:62bf with SMTP id y8-20020a927d08000000b002c2d72c62bfmr1966184ilc.167.1651340829645; Sat, 30 Apr 2022 10:47:09 -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: Michael Schuster Date: Sat, 30 Apr 2022 19:46:59 +0200 Message-ID: Subject: Re: "pkg upgrade" failing with "Fail to create temporary file: ... Not a directory" To: Christoph Moench-Tegeder Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KrGyX39Dbz3L8F X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="kC/rXwxD"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::132 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-1.97 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-0.98)[-0.984]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::132:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Thu, Apr 28, 2022 at 10:43 AM Christoph Moench-Tegeder wrote: > > ## Michael Schuster (michaelsprivate@gmail.com): > > > $subject happened to me just now on current. I researched it on the > > internet, > > Don't look that far, the answer is in UPDATING: > 20220426: > AFFECTS: users of deskutils/grantleetheme thx all - that was the relevant hint here. regards Michael > > Regards, > Christoph > > -- > Spare Space -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From nobody Sat Apr 30 19:22:01 2022 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 F10C41ABB676 for ; Sat, 30 Apr 2022 19:22:13 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [85.220.129.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KrK443shjz3nrB; Sat, 30 Apr 2022 19:22:12 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 0E12B10A1E4C; Sat, 30 Apr 2022 21:22:05 +0200 (CEST) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 5FBBF10A3317; Sat, 30 Apr 2022 21:22:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1651346523; 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=Fd7Z/eZ/8oj1sBZE7jzq3yQsw0R1tSZLan7ZM7ZufiA=; b=RIpHT2lzAK2zauooezdGz6IYA+TKTEC5pTX3OVJY9/K1rAj5m7MptRUsFIXngyq0ukQc89 hTYS3CZfFV29kBO5zrh/DaOxNI6a+X7ygTnDqNNmqj0iDPLf8aJA246DE6r0od22cQ8MPV /2sLU2eibwcGeIskG4drAE+KBnQBa/m8+aAKqmjGhMah1asfOfpUf7gfhkN9/gFIxIknZb DYNctUZo0Wkroj0EaienVVuF4YGwu0OaUyNV05NPnXUWtv4dxKcOn1pAHavJ0Y5zKxj2wK VRfgFdpT72mF3lBnR/ytl8r5crEgFhy3GARPmaFhnz1lqDoFHP+roIJ30YsVZg== Received: from hermann (dynamic-2a01-0c22-a4ac-f100-1d57-526f-8182-eb64.c22.pool.telefonica.de [IPv6:2a01:c22:a4ac:f100:1d57:526f:8182:eb64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id F151A10A3306; Sat, 30 Apr 2022 21:22:02 +0200 (CEST) Date: Sat, 30 Apr 2022 21:22:01 +0200 From: FreeBSD User To: Alan Somers Cc: Marek Zarychta , FreeBSD CURRENT Subject: Re: ext2fs: WARNING: mount of XXXX denied due to unsupported optional features: needs_recovery Message-ID: <20220430212201.4e234ac4@hermann> In-Reply-To: References: <20220428212145.499a9cdd@hermann> <6648abc2-0ffa-dd88-2767-007ef833869a@plan-b.pwste.edu.pl> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 9254ae X-Rspamd-UID: 89749e X-Rspamd-Queue-Id: 4KrK443shjz3nrB X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=RIpHT2lz; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.30) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-0.78 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-0.88)[-0.879]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.30:from] X-ThisMailContainsUnwantedMimeParts: N On Thu, 28 Apr 2022 13:36:21 -0600 Alan Somers wrote: > On Thu, Apr 28, 2022 at 1:29 PM Marek Zarychta > wrote: > > > > W dniu 28.04.2022 o 21:21, FreeBSD User pisze: > > > Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to rescue > > > them and store the data on ZFS volumes. Mounting of the HDD doesn't work, FreeBSD > > > 12.3 obviously lack in some etx2 features, namely "needs_recovery". The kernel > > > reports: > > > > > > WARNING: mount of da4p3 denied due to unsupported optional features: > > > needs_recovery > > > > > > How can this problem be solved? > > > > > > Thanks in advance, > > > > > > oh > > > > > Probably as the name of the mailing list suggest you should upgrade to > > 14.0-CURRENT and maybe run fsck.ext2(8) on this partition to fix it. > > > > -- > > Marek Zarychta > > > > You might also try sysutils/fusefs-ext2 from ports. > Hi all, thanks for the response. First of all, I'm bound to FreeBSD 12.3, which is the base for XigmaNAS (used for the ease of use for those colleagues without FreeBSD experience). No clue, when this project will jump over to 13.0 or 13.1. Last time I installed ports on Xigmanas itself and tried to remove those ports, some of the base system essential also got removed - so the system was wrecked. Therefore, I'm planning to try jails and grant access to the jail and try to bind/mount the HDDs in question into the jail for backup - if this task is not an impossible mission on FBSD. Last, but the most problematic issue is: I do not know what the HDDs filesystem in reality really is! There is an EFI partition (FAT32), there is a second one, fstyp report unknown and here is the large partition identified as ext2fs by fstyp. But I think he former administration in the department used LVM on the more recent Linux boxes, so I might have to deal with that also. Kind regards, O. Hartmann Another issue on several of those HDDs in question seems to be From nobody Sat Apr 30 20:07:48 2022 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 E992F1AC50C2 for ; Sat, 30 Apr 2022 20:08:08 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KrL535W6Hz4R9G for ; Sat, 30 Apr 2022 20:08:07 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-wm1-f54.google.com with SMTP id o12-20020a1c4d0c000000b00393fbe2973dso7847267wmh.2 for ; Sat, 30 Apr 2022 13:08:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mutL6MKufCIO37uUA1qlUY8eSpzWxhpBuEx7S/KpU6s=; b=W2WYRkuJyKAwtNNGPcACPDr3ViAKN6cvabM1nLY3aUGbQqZC+EiCJSGqiBj3MBHtQ7 KgRJOBspwA1QMBoL5Mbt+dLhQuf/X2AQJVYAA3xVjscA7JNj8slAv4tIoZspnFRRKVpz sNcYPshlFOMlcFjPrUWrM00SsynbTA13tqNT90yPcRA6YFk0YGt5UyOnUtkfuJglq00p FRbPNpB5a/RoUoLZ1obhmBch2S2qAiWhPzSDh/hRFYJmnAXo10bzMp7E8cTVM4yWpvPN 0luaPz6cj6tJaIZA3f5Owskfhom4N5aa5PU6uHIY7xLJGmxq2Ti0mP17di+x/RCymVAq NsjA== X-Gm-Message-State: AOAM530Pu1YP9bIORTh1uJtly9LlSPrUoHnxpDI5z0zUoYZfIGQ1gJBV x9m+nkiMnjpgfKyRkADdJvalNYMMpOS00Ye8zQaKgzSE X-Google-Smtp-Source: ABdhPJzHG3/cbFj1ujpJZl49C4k/WvHTlHuAX31I8mnuJbma+mLBMCBcq+OfWDhpcdzHF3Fo7v5OIljuTMaT5IggJOQ= X-Received: by 2002:a05:600c:1f1a:b0:394:29c1:6d82 with SMTP id bd26-20020a05600c1f1a00b0039429c16d82mr4475764wmb.111.1651349281052; Sat, 30 Apr 2022 13:08: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: In-Reply-To: From: Ed Maste Date: Sat, 30 Apr 2022 16:07:48 -0400 Message-ID: Subject: Re: Profiled libraries on freebsd-current To: Steve Kargl Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KrL535W6Hz4R9G X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [1.15 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.96)[0.964]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.63)[-0.634]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.128.54:from]; NEURAL_SPAM_LONG(0.82)[0.818]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.128.54:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Sat, 30 Apr 2022 at 11:34, Steve Kargl wrote: > > On Sat, Apr 30, 2022 at 09:39:32AM -0400, Ed Maste wrote: > > On Fri, 29 Apr 2022 at 01:58, Steve Kargl > > wrote: > > > > > > If one looks at src.conf(5), one finds > > > > > > WITH_PROFILE > > > Build profiled libraries for use with gprof(8). This option is > > > deprecated and is not present in FreeBSD 14. > > > > > > I assume that the *_p.a libraries will no longer be built and > > > installed on FreeBSD 14 and later. Is this correct? > > > > FreeBSD 14 is not yet released, of course, but that is indeed the > > intent. PR256874 reports that a GCC patch (to stop linking against > > _p.a) is in the works but unfortunately has not had an update for some > > time. > > I see. It only took me 2+ years to get > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 > > committed to the GCC repository. Good luck with > getting your patch upstream. Heh, thanks. I have just now changed the WITH_PROFILE description to state "a future version of FreeBSD" since it may well not happen for FreeBSD 14. We could also just install libc_p.a as a symlink to libc.a (and same for the other _p.a archives). From nobody Sun May 1 03:13:43 2022 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 9E7D2199FF06 for ; Sun, 1 May 2022 03:14:01 +0000 (UTC) (envelope-from qroxana@protonmail.com) Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25]) (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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KrWXS4vp9z3m7J for ; Sun, 1 May 2022 03:14:00 +0000 (UTC) (envelope-from qroxana@protonmail.com) Date: Sun, 01 May 2022 03:13:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1651374832; bh=aN/SSiT1xFY6R7ITx93M+kPsFOUaDUoE0CsG75wMaFU=; h=Date:To:From:Reply-To:Subject:Message-ID:Feedback-ID:From:To:Cc: Date:Subject:Reply-To:Feedback-ID:Message-ID; b=Y+4R6uvMpL2PnCevjGONyuWBbR571FtRIeSHWuc3JODZ6imnxkC2uCW5QtJER4A9w SFHfiAaIyDs8XQY7EiHkaP1CDL1Pl54bhX30oLEhOLnK8l6qJxlhlMdvYjEJI8fvQM WG6tgrxF4qF+Mp25UU80qGg6gFlsfTHL0VbKGkpRqxbbaFNv98XCzOq/Yf2ZiD7qIe frF0lmw+d6ZBBjsY3eX2VsCo0QO/5k0rbcw7W+kTJYhJfIvf+DHyy6L5Ee37vuSqmm SqI9lMPsw/WTTB8wTwEMAuYisoJe5SvefFMRsRWbHV4rKT0rGad+vhf8SIjY/gb0Yo 1jJocIvs9RrMg== To: "freebsd-current@freebsd.org" , "freebsd-arm@freebsd.org" From: qroxana Reply-To: qroxana Subject: Kernel panic on armv7 when PF is enabled Message-ID: Feedback-ID: 29996633:user:proton 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="b1_KLMBgySICMKCy7cAmgd167xn7vD9D1vF7GZ5ze9K4Y" X-Rspamd-Queue-Id: 4KrWXS4vp9z3m7J X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail2 header.b=Y+4R6uvM; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of qroxana@protonmail.com designates 185.70.43.25 as permitted sender) smtp.mailfrom=qroxana@protonmail.com X-Spamd-Result: default: False [-0.15 / 15.00]; HAS_REPLYTO(0.00)[qroxana@protonmail.com]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.23)[-0.230]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail2]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.984]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_KLMBgySICMKCy7cAmgd167xn7vD9D1vF7GZ5ze9K4Y Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWZ0ZXIgZ2l0IGJpc2VjdGluZyB0aGUgcGFuaWMgc3RhcnRlZCBzaW5jZSB0aGlzIGNvbW1pdC4K CmNvbW1pdCA3OGJjM2Q1ZTE3MTJiYzE2NDlhYTU1NzRkMmI4ZDE1M2Y5NjY1MTEzCgpBdXRob3I6 IEtyaXN0b2YgUHJvdm9zdCA8CmtwQEZyZWVCU0Qub3JnCj4KCkRhdGU6ICAgTW9uIEZlYiAxNCAy MDowOTo1NCAyMDIyICswMTAwCgp2bGFuOiBhbGxvdyBuZXQubGluay52bGFuLm10YWdfcGNwIHRv IGJlIHNldCBwZXIgdm5ldAoKVGhlIHByaW1hcnkgcmVhc29uIGZvciB0aGlzIGNoYW5nZSBpcyB0 byBmYWNpbGl0YXRlIHRlc3RpbmcuCgpNRkMgYWZ0ZXI6ICAgICAgMSB3ZWVrCgpzeXMvbmV0L2lm X2V0aGVyc3Vici5jIHwgOSArKysrKy0tLS0KCnN5cy9uZXQvaWZfdmxhbi5jICAgICAgfCA1ICsr Ky0tCgoyIGZpbGVzIGNoYW5nZWQsIDggaW5zZXJ0aW9ucygrKSwgNiBkZWxldGlvbnMoLSkKClRo ZSBhcm12NyBib2FyZCBib290cyBmcm9tIGEgTkZTIHJvb3QsCgppdCBjYW4gYm9vdCB3aXRob3V0 IGFueSBwcm9ibGVtIGlmIFBGIGlzIGRpc2FibGVkLgoKQW55IGhlbHBzPwoKYWRkIGhvc3QgOjox OiBnYXRld2F5IGxvMCBmaWIgMDogcm91dGUgYWxyZWFkeSBpbiB0YWJsZQphZGQgbmV0IGZlODA6 OjogZ2F0ZXdheSA6OjEKYWRkIG5ldCBmZjAyOjo6IGdhdGV3YXkgOjoxCmFkZCBuZXQgOjpmZmZm OjAuMC4wLjA6IGdhdGV3YXkgOjoxCmFkZCBuZXQgOjowLjAuMC4wOiBnYXRld2F5IDo6MQpFbmFi bGluZyBwZi4KS2VybmVsIHBhZ2UgZmF1bHQgd2l0aCB0aGUgZm9sbG93aW5nIG5vbi1zbGVlcGFi bGUgbG9ja3MgaGVsZDoKc2hhcmVkIHJtIHBmIHJ1bGVzZXRzIChwZiBydWxlc2V0cykgciA9IDAg KDB4ZTMwOTk0MzApIGxvY2tlZCBAIC91c3Ivc3JjL3N5cy9uZXRwZmlsL3BmL3BmLmM6NjQ5Mwpl eGNsdXNpdmUgcncgdGNwaW5wICh0Y3BpbnApIHIgPSAwICgweGRiNzQ4ZDg4KSBsb2NrZWQgQCAv dXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdXNycmVxLmM6MTAwOApzdGFjayBiYWNrdHJhY2U6CiMw IDB4YzAzNTVjYWMgYXQgd2l0bmVzc19kZWJ1Z2dlcisweDdjCiMxIDB4YzAzNTZlZjAgYXQgd2l0 bmVzc193YXJuKzB4M2ZjCiMyIDB4YzA1ZWMwNDggYXQgYWJvcnRfaGFuZGxlcisweDFkOAojMyAw eGMwNWNiNWFjIGF0IGV4Y2VwdGlvbl9leGl0KzAKIzQgMHhlMzA4M2MxMCBhdCBwZl9zeW5jb29r aWVfdmFsaWRhdGUrMHg2MAojNSAweGUzMDQ5NmE4IGF0IHBmX3Rlc3QrMHg1MTgKIzYgMHhlMzA2 ZDc2OCBhdCBwZl9jaGVja19vdXQrMHgzMAojNyAweGMwNDE1YjQ0IGF0IHBmaWxfcnVuX2hvb2tz KzB4YmMKIzggMHhjMDQ0NWNmYyBhdCBpcF9vdXRwdXQrMHhjZTgKIzkgMHhjMDQ1YmM5YyBhdCB0 Y3BfZGVmYXVsdF9vdXRwdXQrMHgyMGFjCiMxMCAweGMwNDcxZWI0IGF0IHRjcF91c3Jfc2VuZCsw eDFhYwojMTEgMHhjMDM4OTQ2NCBhdCBzb3NlbmRfZ2VuZXJpYysweDQ5MAojMTIgMHhjMDM4OTc5 MCBhdCBzb3NlbmQrMHg2NAojMTMgMHhjMDUwMjg4OCBhdCBjbG50X3ZjX2NhbGwrMHg1NjAKIzE0 IDB4YzA1MDA5ZDggYXQgY2xudF9yZWNvbm5lY3RfY2FsbCsweDE3MAojMTUgMHhjMDFlN2IxNCBh dCBuZXduZnNfcmVxdWVzdCsweGIyMAojMTYgMHhjMDIzMDIxOCBhdCBuZnNjbF9yZXF1ZXN0KzB4 NjAKIzE3IDB4YzAyMGQ5YmMgYXQgbmZzcnBjX2dldGF0dHIrMHhiMApGYXRhbCBrZXJuZWwgbW9k ZSBkYXRhIGFib3J0OiAnQWxpZ25tZW50IEZhdWx0JyBvbiByZWFkCnRyYXBmcmFtZTogMHhkZjFm MWM5MApGU1I9MDAwMDAwMDEsIEZBUj1kNzg0MDI2NCwgc3Bzcj00MDAwMDAxMwpyMCA9NmEyMjhl ZGEsIHIxID1kYWMwZDc4NSwgcjIgPWQ3ODQwMjY0LCByMyA9ZGI1NTI3YzAKcjQgPWRmMWYxZTAw LCByNSA9ZGFjMGQ3NWYsIHI2ID0wMDAwMDAxOCwgcjcgPWQ5NDIyYzAwCnI4ID1jMDkzZTVlNCwg cjkgPTAwMDAwMDAxLCByMTA9ZGYxZjFmNWMsIHIxMT1kZjFmMWQzOApyMTI9ZTMwOThkZDAsIHNz cD1kZjFmMWQyMCwgc2xyPWUzMDgzYmRjLCBwYyA9ZTMwODNjMTAKCnBhbmljOiBGYXRhbCBhYm9y dApjcHVpZCA9IDEKdGltZSA9IDE2NTEzNjYwODkKS0RCOiBzdGFjayBiYWNrdHJhY2U6CmRiX3Ry YWNlX3NlbGYoKSBhdCBkYl90cmFjZV9zZWxmCiAgICAgICAgIHBjID0gMHhjMDVjOGMwMCAgbHIg PSAweGMwMDdhYzhjIChkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgzMCkKICAgICAgICAgc3AgPSAw eGRmMWYxYTY4ICBmcCA9IDB4ZGYxZjFiODAKZGJfdHJhY2Vfc2VsZl93cmFwcGVyKCkgYXQgZGJf dHJhY2Vfc2VsZl93cmFwcGVyKzB4MzAKICAgICAgICAgcGMgPSAweGMwMDdhYzhjICBsciA9IDB4 YzAyZTI4OWMgKHZwYW5pYysweDE3MCkKICAgICAgICAgc3AgPSAweGRmMWYxYjg4ICBmcCA9IDB4 ZGYxZjFiYTgKICAgICAgICAgcjQgPSAweDAwMDAwMTAwICByNSA9IDB4MDAwMDAwMDAKICAgICAg ICAgcjYgPSAweGMwNzgwNTI5ICByNyA9IDB4YzA5MGVhMTAKdnBhbmljKCkgYXQgdnBhbmljKzB4 MTcwCiAgICAgICAgIHBjID0gMHhjMDJlMjg5YyAgbHIgPSAweGMwMmUyNjRjIChkb2FkdW1wKQog ICAgICAgICBzcCA9IDB4ZGYxZjFiYjAgIGZwID0gMHhkZjFmMWJiNAogICAgICAgICByNCA9IDB4 ZGYxZjFjOTAgIHI1ID0gMHgwMDAwMDAxMwogICAgICAgICByNiA9IDB4ZDc4NDAyNjQgIHI3ID0g MHgwMDAwMDAwMQogICAgICAgICByOCA9IDB4MDAwMDAwMDEgIHI5ID0gMHhkYjU1MjdjMAogICAg ICAgIHIxMCA9IDB4ZDc4NDAyNjQKZG9hZHVtcCgpIGF0IGRvYWR1bXAKICAgICAgICAgcGMgPSAw eGMwMmUyNjRjICBsciA9IDB4YzA1ZWM2OTggKGFib3J0X2FsaWduKQogICAgICAgICBzcCA9IDB4 ZGYxZjFiYmMgIGZwID0gMHhkZjFmMWJlOAogICAgICAgICByNCA9IDB4ZDc4NDAyNjQgIHI1ID0g MHhkZjFmMWJiNAogICAgICAgICByNiA9IDB4YzAyZTI2NGMgcjEwID0gMHhkZjFmMWJiYwphYm9y dF9hbGlnbigpIGF0IGFib3J0X2FsaWduCiAgICAgICAgIHBjID0gMHhjMDVlYzY5OCAgbHIgPSAw eGMwNWVjMTk4IChhYm9ydF9oYW5kbGVyKzB4MzI4KQogICAgICAgICBzcCA9IDB4ZGYxZjFiZjAg IGZwID0gMHhkZjFmMWM4OAogICAgICAgICByNCA9IDB4MDAwMDAwMTMgIHI1ID0gMHhkNzg0MDI2 NAphYm9ydF9oYW5kbGVyKCkgYXQgYWJvcnRfaGFuZGxlcisweDMyOAogICAgICAgICBwYyA9IDB4 YzA1ZWMxOTggIGxyID0gMHhjMDVjYjVhYyAoZXhjZXB0aW9uX2V4aXQpCiAgICAgICAgIHNwID0g MHhkZjFmMWM5MCAgZnAgPSAweGRmMWYxZDM4CiAgICAgICAgIHI0ID0gMHhkZjFmMWUwMCAgcjUg PSAweGRhYzBkNzVmCiAgICAgICAgIHI2ID0gMHgwMDAwMDAxOCAgcjcgPSAweGQ5NDIyYzAwCiAg ICAgICAgIHI4ID0gMHhjMDkzZTVlNCAgcjkgPSAweDAwMDAwMDAxCiAgICAgICAgcjEwID0gMHhk ZjFmMWY1YwpleGNlcHRpb25fZXhpdCgpIGF0IGV4Y2VwdGlvbl9leGl0CiAgICAgICAgIHBjID0g MHhjMDVjYjVhYyAgbHIgPSAweGUzMDgzYmRjIChwZl9zeW5jb29raWVfdmFsaWRhdGUrMHgyYykK ICAgICAgICAgc3AgPSAweGRmMWYxZDIwICBmcCA9IDB4ZGYxZjFkMzgKICAgICAgICAgcjAgPSAw eDZhMjI4ZWRhICByMSA9IDB4ZGFjMGQ3ODUKICAgICAgICAgcjIgPSAweGQ3ODQwMjY0ICByMyA9 IDB4ZGI1NTI3YzAKICAgICAgICAgcjQgPSAweGRmMWYxZTAwICByNSA9IDB4ZGFjMGQ3NWYKICAg ICAgICAgcjYgPSAweDAwMDAwMDE4ICByNyA9IDB4ZDk0MjJjMDAKICAgICAgICAgcjggPSAweGMw OTNlNWU0ICByOSA9IDB4MDAwMDAwMDEKICAgICAgICByMTAgPSAweGRmMWYxZjVjIHIxMiA9IDB4 ZTMwOThkZDAKcGZfc3luY29va2llX3ZhbGlkYXRlKCkgYXQgcGZfc3luY29va2llX3ZhbGlkYXRl KzB4NjAKICAgICAgICAgcGMgPSAweGUzMDgzYzEwICBsciA9IDB4ZTMwNDk2YTggKHBmX3Rlc3Qr MHg1MTgpCiAgICAgICAgIHNwID0gMHhkZjFmMWQ0MCAgZnAgPSAweGRmMWYxZWE4CiAgICAgICAg IHI0ID0gMHgwMDAyMDAwMCAgcjUgPSAweGRiNGE2MTAwCiAgICAgICAgIHI2ID0gMHgwMDAwMDAx OCAgcjcgPSAweGQ5NDIyYzAwCiAgICAgICAgIHI4ID0gMHgwMDAwMDAwMiAgcjkgPSAweDAwMDAw MDAxCnBmX3Rlc3QoKSBhdCBwZl90ZXN0KzB4NTE4CiAgICAgICAgIHBjID0gMHhlMzA0OTZhOCAg bHIgPSAweGUzMDZkNzY4IChwZl9jaGVja19vdXQrMHgzMCkKICAgICAgICAgc3AgPSAweGRmMWYx ZWIwICBmcCA9IDB4ZGYxZjFlYzAKICAgICAgICAgcjQgPSAweGRmMWYxZjVjICByNSA9IDB4ZTMw NmQ3MzgKICAgICAgICAgcjYgPSAweGRiNmJhNjYwICByNyA9IDB4MDAwMDAwMDAKICAgICAgICAg cjggPSAweGQ5NDIyYzAwICByOSA9IDB4ZGI3NDhkODAKICAgICAgICByMTAgPSAweGZmZjcwMDAw CnBmX2NoZWNrX291dCgpIGF0IHBmX2NoZWNrX291dCsweDMwCiAgICAgICAgIHBjID0gMHhlMzA2 ZDc2OCAgbHIgPSAweGMwNDE1YjQ0IChwZmlsX3J1bl9ob29rcysweGJjKQogICAgICAgICBzcCA9 IDB4ZGYxZjFlYzggIGZwID0gMHhkZjFmMWVmMAogICAgICAgICByNCA9IDB4MDAwMjAwMDAgIHI1 ID0gMHhlMzA2ZDczOApwZmlsX3J1bl9ob29rcygpIGF0IHBmaWxfcnVuX2hvb2tzKzB4YmMKICAg ICAgICAgcGMgPSAweGMwNDE1YjQ0ICBsciA9IDB4YzA0NDVjZmMgKGlwX291dHB1dCsweGNlOCkK ICAgICAgICAgc3AgPSAweGRmMWYxZWY4ICBmcCA9IDB4ZGYxZjFmYTgKICAgICAgICAgcjQgPSAw eDAwMDAwMTBhICByNSA9IDB4MDAwMDBhMGEKICAgICAgICAgcjYgPSAweGRiNGE2MTU4ICByNyA9 IDB4YzA5NDY5MDgKICAgICAgICAgcjggPSAweGRiNWJlYzAwICByOSA9IDB4ZDk0MjJjMDAKICAg ICAgICByMTAgPSAweDAwMDAwNWRjCmlwX291dHB1dCgpIGF0IGlwX291dHB1dCsweGNlOAogICAg ICAgICBwYyA9IDB4YzA0NDVjZmMgIGxyID0gMHhjMDQ1YmM5YyAodGNwX2RlZmF1bHRfb3V0cHV0 KzB4MjBhYykKICAgICAgICAgc3AgPSAweGRmMWYxZmIwICBmcCA9IDB4ZGYxZjIwZTAKICAgICAg ICAgcjQgPSAweDAwMDAwMDAxICByNSA9IDB4MDAwMDAwMDAKICAgICAgICAgcjYgPSAweDAwMDAw MDM0ICByNyA9IDB4ZGI3NDYwMDAKICAgICAgICAgcjggPSAweGRiNGE2MTZjICByOSA9IDB4ZGI0 YTYxMDAKICAgICAgICByMTAgPSAweGRiNzgyMDAwCnRjcF9kZWZhdWx0X291dHB1dCgpIGF0IHRj cF9kZWZhdWx0X291dHB1dCsweDIwYWMKICAgICAgICAgcGMgPSAweGMwNDViYzljICBsciA9IDB4 YzA0NzFlYjQgKHRjcF91c3Jfc2VuZCsweDFhYykKICAgICAgICAgc3AgPSAweGRmMWYyMGU4ICBm cCA9IDB4ZGYxZjIxNjAKICAgICAgICAgcjQgPSAweGMwYWY5NTVjICByNSA9IDB4ZGI3ODIwMDAK ICAgICAgICAgcjYgPSAweDAwMDAwMDAwICByNyA9IDB4ZGI3NDYwMDAKICAgICAgICAgcjggPSAw eDAwMDAwMDAwICByOSA9IDB4ZGI3NDhkODAKICAgICAgICByMTAgPSAweDAwMDAwMDAwCnRjcF91 c3Jfc2VuZCgpIGF0IHRjcF91c3Jfc2VuZCsweDFhYwogICAgICAgICBwYyA9IDB4YzA0NzFlYjQg IGxyID0gMHhjMDM4OTQ2NCAoc29zZW5kX2dlbmVyaWMrMHg0OTApCiAgICAgICAgIHNwID0gMHhk ZjFmMjE2OCAgZnAgPSAweGRmMWYyMWQwCiAgICAgICAgIHI0ID0gMHhjMDQ3MWQwOCAgcjUgPSAw eDAwMDQ0MDAwCiAgICAgICAgIHI2ID0gMHhkYjc0NjAwMCAgcjcgPSAweGRiNTUyN2MwCiAgICAg ICAgIHI4ID0gMHgwMDAwMDAwMCAgcjkgPSAweGRiNzQ2MWI4CiAgICAgICAgcjEwID0gMHhkYjRi MjkwMApzb3NlbmRfZ2VuZXJpYygpIGF0IHNvc2VuZF9nZW5lcmljKzB4NDkwCiAgICAgICAgIHBj ID0gMHhjMDM4OTQ2NCAgbHIgPSAweGMwMzg5NzkwIChzb3NlbmQrMHg2NCkKICAgICAgICAgc3Ag PSAweGRmMWYyMWQ4ICBmcCA9IDB4ZGYxZjIyMDAKICAgICAgICAgcjQgPSAweDAwMDAwMDAwICBy NSA9IDB4YzAzODhmZDQKICAgICAgICAgcjYgPSAweGRiNTUyN2MwICByNyA9IDB4MDAwMDAwMDAK ICAgICAgICAgcjggPSAweDVlNGE2ZjI4ICByOSA9IDB4MDAwMDAxMDAKICAgICAgICByMTAgPSAw eGM3MmZjNDkwCnNvc2VuZCgpIGF0IHNvc2VuZCsweDY0CiAgICAgICAgIHBjID0gMHhjMDM4OTc5 MCAgbHIgPSAweGMwNTAyODg4IChjbG50X3ZjX2NhbGwrMHg1NjApCiAgICAgICAgIHNwID0gMHhk ZjFmMjIwOCAgZnAgPSAweGRmMWYyMmU4CiAgICAgICAgIHI0ID0gMHhjMDc2ZTEzMiAgcjUgPSAw eGRmMWYyMmFjCiAgICAgICAgIHI2ID0gMHhjNzJmYzVhMCAgcjcgPSAweGMwNGZkMzQ4CiAgICAg ICAgIHI4ID0gMHhjNzJmYzQ4MCByMTAgPSAweGM3MmZjNDkwCmNsbnRfdmNfY2FsbCgpIGF0IGNs bnRfdmNfY2FsbCsweDU2MAogICAgICAgICBwYyA9IDB4YzA1MDI4ODggIGxyID0gMHhjMDUwMDlk OCAoY2xudF9yZWNvbm5lY3RfY2FsbCsweDE3MCkKICAgICAgICAgc3AgPSAweGRmMWYyMmYwICBm cCA9IDB4ZGYxZjIzNzgKICAgICAgICAgcjQgPSAweGMwNTAyMzI4ICByNSA9IDB4YzA3NjgxMzcK ICAgICAgICAgcjYgPSAweGRiNjViYzQwICByNyA9IDB4YzcyZmM2MTAKICAgICAgICAgcjggPSAw eGM3MmZjNjAwICByOSA9IDB4MDAwMDAwMDAKICAgICAgICByMTAgPSAweGRmMWYyNDM4CmNsbnRf cmVjb25uZWN0X2NhbGwoKSBhdCBjbG50X3JlY29ubmVjdF9jYWxsKzB4MTcwCiAgICAgICAgIHBj ID0gMHhjMDUwMDlkOCAgbHIgPSAweGMwMWU3YjE0IChuZXduZnNfcmVxdWVzdCsweGIyMCkKICAg ICAgICAgc3AgPSAweGRmMWYyMzgwICBmcCA9IDB4ZGYxZjI0YTgKICAgICAgICAgcjQgPSAweDAw MDAwMTJjICByNSA9IDB4YzA1MDA4NjgKICAgICAgICAgcjYgPSAweDAwMDAwMDAwICByNyA9IDB4 MDAwMDAwMDAKICAgICAgICAgcjggPSAweGRmMWYyNTEwICByOSA9IDB4YzA3MjY3NjEKICAgICAg ICByMTAgPSAweDAwMDAwMDAwCm5ld25mc19yZXF1ZXN0KCkgYXQgbmV3bmZzX3JlcXVlc3QrMHhi MjAKICAgICAgICAgcGMgPSAweGMwMWU3YjE0ICBsciA9IDB4YzAyMzAyMTggKG5mc2NsX3JlcXVl c3QrMHg2MCkKICAgICAgICAgc3AgPSAweGRmMWYyNGIwICBmcCA9IDB4ZGYxZjI0ZTgKICAgICAg ICAgcjQgPSAweDAwMDAwMDAwICByNSA9IDB4MDAwMTg2YTMKICAgICAgICAgcjYgPSAweDAwMDAw MDAzICByNyA9IDB4MDAwMDAwMDEKICAgICAgICAgcjggPSAweGRmMWYyNmM4ICByOSA9IDB4YzBh Zjk1NWMKICAgICAgICByMTAgPSAweDAwMDAwMDAwCm5mc2NsX3JlcXVlc3QoKSBhdCBuZnNjbF9y ZXF1ZXN0KzB4NjAKICAgICAgICAgcGMgPSAweGMwMjMwMjE4ICBsciA9IDB4YzAyMGQ5YmMgKG5m c3JwY19nZXRhdHRyKzB4YjApCiAgICAgICAgIHNwID0gMHhkZjFmMjRmMCAgZnAgPSAweGRmMWYy NjE4CiAgICAgICAgIHI0ID0gMHgwMDAwMDAwMCAgcjUgPSAweGRiNWFmZDAwCiAgICAgICAgIHI2 ID0gMHhkYjU1MjdjMCAgcjcgPSAweGUyOWQ0NTNjCm5mc3JwY19nZXRhdHRyKCkgYXQgbmZzcnBj X2dldGF0dHIrMHhiMAogICAgICAgICBwYyA9IDB4YzAyMGQ5YmMgIGxyID0gMHhjMDIyM2I4OCAo bmZzX2dldGF0dHIrMHhjOCkKICAgICAgICAgc3AgPSAweGRmMWYyNjIwICBmcCA9IDB4ZGYxZjI3 YjAKICAgICAgICAgcjQgPSAweDAwMDAwMDAwICByNSA9IDB4ZTI5ZDQ1M2MKICAgICAgICAgcjYg PSAweGUyOWQ2NjcwICByNyA9IDB4MDAwMDAwMDAKICAgICAgICAgcjggPSAweGRiNTUyN2MwICBy OSA9IDB4ZGYxZjI4MzAKICAgICAgICByMTAgPSAweGRiNTUyN2MwCm5mc19nZXRhdHRyKCkgYXQg bmZzX2dldGF0dHIrMHhjOAogICAgICAgICBwYyA9IDB4YzAyMjNiODggIGxyID0gMHhjMDNiOWI4 MCAodm9wX3NpZ2RlZmVyKzB4MzQpCiAgICAgICAgIHNwID0gMHhkZjFmMjdiOCAgZnAgPSAweGRm MWYyN2M4CiAgICAgICAgIHI0ID0gMHhkZjFmMjk5OCAgcjUgPSAweGZmZmZmZmZmCiAgICAgICAg IHI2ID0gMHhjMDIyM2FjMCAgcjcgPSAweDAwMDAwMDAwCiAgICAgICAgIHI4ID0gMHhkZjFmMmQ2 MCAgcjkgPSAweGRiNzk1ODAwCnZvcF9zaWdkZWZlcigpIGF0IHZvcF9zaWdkZWZlcisweDM0CiAg ICAgICAgIHBjID0gMHhjMDNiOWI4MCAgbHIgPSAweGMwMjIxYTAwIChuZnNfbG9va3VwKzB4MzQ0 KQogICAgICAgICBzcCA9IDB4ZGYxZjI3ZDAgIGZwID0gMHhkZjFmMmFhOAogICAgICAgICByNCA9 IDB4ZTI5ZDY2NzAgIHI1ID0gMHhkZjFmMjgzMAogICAgICAgICByNiA9IDB4ZTI5ZDY2NjAgcjEw ID0gMHhkYjU1MjdjMApuZnNfbG9va3VwKCkgYXQgbmZzX2xvb2t1cCsweDM0NAogICAgICAgICBw YyA9IDB4YzAyMjFhMDAgIGxyID0gMHhjMDNiOWI4MCAodm9wX3NpZ2RlZmVyKzB4MzQpCiAgICAg ICAgIHNwID0gMHhkZjFmMmFiMCAgZnAgPSAweGRmMWYyYWMwCiAgICAgICAgIHI0ID0gMHhkZjFm MmFlNCAgcjUgPSAweDAwMDAwMDAwCiAgICAgICAgIHI2ID0gMHhjMDIyMTZiYyAgcjcgPSAweDAw MDgwMDAwCiAgICAgICAgIHI4ID0gMHhkZjFmMmQ2MCAgcjkgPSAweDAwMDAwMDAyCiAgICAgICAg cjEwID0gMHgwMDAwMDAwMAp2b3Bfc2lnZGVmZXIoKSBhdCB2b3Bfc2lnZGVmZXIrMHgzNAogICAg ICAgICBwYyA9IDB4YzAzYjliODAgIGxyID0gMHhjMDNiZTU1YyAobG9va3VwKzB4NDZjKQogICAg ICAgICBzcCA9IDB4ZGYxZjJhYzggIGZwID0gMHhkZjFmMmIxMAogICAgICAgICByNCA9IDB4ZGYx ZjJkMDAgIHI1ID0gMHhkYjllNGVhOAogICAgICAgICByNiA9IDB4ZGYxZjJkNTggcjEwID0gMHgw MDAwMDAwMApsb29rdXAoKSBhdCBsb29rdXArMHg0NmMKICAgICAgICAgcGMgPSAweGMwM2JlNTVj ICBsciA9IDB4YzAzYmQ0NTAgKG5hbWVpKzB4M2NjKQogICAgICAgICBzcCA9IDB4ZGYxZjJiMTgg IGZwID0gMHhkZjFmMmJiOAogICAgICAgICByNCA9IDB4ZGYxZjJkMDAgIHI1ID0gMHhmZmZmZjgx YwogICAgICAgICByNiA9IDB4MDAwMDAwMDAgIHI3ID0gMHhkYjNiY2M5MAogICAgICAgICByOCA9 IDB4YzBiNWE0OGMgIHI5ID0gMHhkYjU1MjdjMAogICAgICAgIHIxMCA9IDB4ZGYxZjJkNjAKbmFt ZWkoKSBhdCBuYW1laSsweDNjYwogICAgICAgICBwYyA9IDB4YzAzYmQ0NTAgIGxyID0gMHhjMDNl NGU5OCAodm5fb3Blbl9jcmVkKzB4NDVjKQogICAgICAgICBzcCA9IDB4ZGYxZjJiYzAgIGZwID0g MHhkZjFmMmNjOAogICAgICAgICByNCA9IDB4MDAwMDAwMDEgIHI1ID0gMHgwMDAwMDAwMAogICAg ICAgICByNiA9IDB4MDAxMDAwMDEgIHI3ID0gMHhkZjFmMmQ2MAogICAgICAgICByOCA9IDB4ZmZm ZmZmOWMgIHI5ID0gMHhkZjFmMmQwMAogICAgICAgIHIxMCA9IDB4ZGYxZjJkNTgKdm5fb3Blbl9j cmVkKCkgYXQgdm5fb3Blbl9jcmVkKzB4NDVjCiAgICAgICAgIHBjID0gMHhjMDNlNGU5OCAgbHIg PSAweGMwM2U0YTM0ICh2bl9vcGVuKzB4MjQpCiAgICAgICAgIHNwID0gMHhkZjFmMmNkMCAgZnAg PSAweGRmMWYyY2Q4CiAgICAgICAgIHI0ID0gMHhkYjU1MjdjMCAgcjUgPSAweGRmMWYyZDAwCiAg ICAgICAgIHI2ID0gMHgwMDAwMDAwMCAgcjcgPSAweGRmMWYyZDAwCiAgICAgICAgIHI4ID0gMHhm ZmZmZmY5YyAgcjkgPSAweDAwMDAwMDEyCiAgICAgICAgcjEwID0gMHgyMDA3NmIwNAp2bl9vcGVu KCkgYXQgdm5fb3BlbisweDI0CiAgICAgICAgIHBjID0gMHhjMDNlNGEzNCAgbHIgPSAweGMwM2Ri NDI4IChrZXJuX29wZW5hdCsweDI1NCkKICAgICAgICAgc3AgPSAweGRmMWYyY2UwICBmcCA9IDB4 ZGYxZjJkYjgKa2Vybl9vcGVuYXQoKSBhdCBrZXJuX29wZW5hdCsweDI1NAogICAgICAgICBwYyA9 IDB4YzAzZGI0MjggIGxyID0gMHhjMDNkYjZiMCAoc3lzX29wZW5hdCsweDJjKQogICAgICAgICBz cCA9IDB4ZGYxZjJkYzAgIGZwID0gMHhkZjFmMmRjOAogICAgICAgICByNCA9IDB4ZGI1NTI3YzAg IHI1ID0gMHgwMDAwMDAwMQogICAgICAgICByNiA9IDB4YzA4ZDk5Y2MgIHI3ID0gMHgwMDAwMDAw MAogICAgICAgICByOCA9IDB4MDAwMDAwMDAgIHI5ID0gMHhkYjU1MmE2OAogICAgICAgIHIxMCA9 IDB4ZGJhMjljODAKc3lzX29wZW5hdCgpIGF0IHN5c19vcGVuYXQrMHgyYwogICAgICAgICBwYyA9 IDB4YzAzZGI2YjAgIGxyID0gMHhjMDVlYjliNCAoc3dpX2hhbmRsZXIrMHgxNWMpCiAgICAgICAg IHNwID0gMHhkZjFmMmRkMCAgZnAgPSAweGRmMWYyZTQwCnN3aV9oYW5kbGVyKCkgYXQgc3dpX2hh bmRsZXIrMHgxNWMKICAgICAgICAgcGMgPSAweGMwNWViOWI0ICBsciA9IDB4YzA1Y2I1M2MgKHN3 aV9leGl0KQogICAgICAgICBzcCA9IDB4ZGYxZjJlNDggIGZwID0gMHhiZmJmZTcyMAogICAgICAg ICByNCA9IDB4MjAyN2QyZjQgIHI1ID0gMHgwMDA2NWM0MAogICAgICAgICByNiA9IDB4MjAwNzZh YzggIHI3ID0gMHgwMDAwMDFmMwogICAgICAgICByOCA9IDB4MDAwMDAwMDEgIHI5ID0gMHgwMDA2 NWM0MAogICAgICAgIHIxMCA9IDB4MDAwNjRkODgKc3dpX2V4aXQoKSBhdCBzd2lfZXhpdAogICAg ICAgICBwYyA9IDB4YzA1Y2I1M2MgIGxyID0gMHhjMDVjYjUzYyAoc3dpX2V4aXQpCiAgICAgICAg IHNwID0gMHhkZjFmMmU0OCAgZnAgPSAweGJmYmZlNzIwCktEQjogZW50ZXI6IHBhbmljClsgdGhy ZWFkIHBpZCA1NzkgdGlkIDEwMDEyMiBdClN0b3BwZWQgYXQgICAgICBrZGJfZW50ZXIrMHg1ODog bGRyYiAgICByMTUsIFtyMTUsIHIxNSwgcm9yIHIxNV0h --b1_KLMBgySICMKCy7cAmgd167xn7vD9D1vF7GZ5ze9K4Y Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij48cHJlPkFm dGVyIGdpdCBiaXNlY3RpbmcgdGhlIHBhbmljIHN0YXJ0ZWQgc2luY2UgdGhpcyBjb21taXQuPGJy Pjxicj48c3Bhbj5jb21taXQgNzhiYzNkNWUxNzEyYmMxNjQ5YWE1NTc0ZDJiOGQxNTNmOTY2NTEx Mzwvc3Bhbj48ZGl2PjxzcGFuPkF1dGhvcjogS3Jpc3RvZiBQcm92b3N0ICZsdDs8YSB0YXJnZXQ9 Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIiBocmVmPSJtYWlsdG86 a3BARnJlZUJTRC5vcmciPmtwQEZyZWVCU0Qub3JnPC9hPiZndDs8L3NwYW4+PC9kaXY+PGRpdj48 c3Bhbj5EYXRlOiAmbmJzcDsgTW9uIEZlYiAxNCAyMDowOTo1NCAyMDIyICswMTAwPC9zcGFuPjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7ICZuYnNwOyB2bGFuOiBhbGxvdyBu ZXQubGluay52bGFuLm10YWdfcGNwIHRvIGJlIHNldCBwZXIgdm5ldDwvc3Bhbj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOyAmbmJzcDsgVGhlIHByaW1hcnkgcmVhc29uIGZv ciB0aGlzIGNoYW5nZSBpcyB0byBmYWNpbGl0YXRlIHRlc3RpbmcuPC9zcGFuPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7ICZuYnNwOyBNRkMgYWZ0ZXI6ICZuYnNwOyAmbmJz cDsgJm5ic3A7MSB3ZWVrPC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4+Jm5i c3A7c3lzL25ldC9pZl9ldGhlcnN1YnIuYyB8IDkgKysrKystLS0tPC9zcGFuPjwvZGl2PjxkaXY+ PHNwYW4+Jm5ic3A7c3lzL25ldC9pZl92bGFuLmMgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IDUgKysr LS08L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDsyIGZpbGVzIGNoYW5nZWQsIDggaW5zZXJ0 aW9ucygrKSwgNiBkZWxldGlvbnMoLSk8L3NwYW4+PC9kaXY+PGJyPlRoZSBhcm12NyBib2FyZCBi b290cyBmcm9tIGEgTkZTIHJvb3QsPGJyPml0IGNhbiBib290IHdpdGhvdXQgYW55IHByb2JsZW0g aWYgUEYgaXMgZGlzYWJsZWQuPGJyPkFueSBoZWxwcz88YnI+PGJyPmFkZCBob3N0IDo6MTogZ2F0 ZXdheSBsbzAgZmliIDA6IHJvdXRlIGFscmVhZHkgaW4gdGFibGUNCmFkZCBuZXQgZmU4MDo6OiBn YXRld2F5IDo6MQ0KYWRkIG5ldCBmZjAyOjo6IGdhdGV3YXkgOjoxDQphZGQgbmV0IDo6ZmZmZjow LjAuMC4wOiBnYXRld2F5IDo6MQ0KYWRkIG5ldCA6OjAuMC4wLjA6IGdhdGV3YXkgOjoxDQpFbmFi bGluZyBwZi4NCktlcm5lbCBwYWdlIGZhdWx0IHdpdGggdGhlIGZvbGxvd2luZyBub24tc2xlZXBh YmxlIGxvY2tzIGhlbGQ6DQpzaGFyZWQgcm0gcGYgcnVsZXNldHMgKHBmIHJ1bGVzZXRzKSByID0g MCAoMHhlMzA5OTQzMCkgbG9ja2VkIEAgL3Vzci9zcmMvc3lzL25ldHBmaWwvcGYvcGYuYzo2NDkz DQpleGNsdXNpdmUgcncgdGNwaW5wICh0Y3BpbnApIHIgPSAwICgweGRiNzQ4ZDg4KSBsb2NrZWQg QCAvdXNyL3NyYy9zeXMvbmV0aW5ldC90Y3BfdXNycmVxLmM6MTAwOA0Kc3RhY2sgYmFja3RyYWNl Og0KIzAgMHhjMDM1NWNhYyBhdCB3aXRuZXNzX2RlYnVnZ2VyKzB4N2MNCiMxIDB4YzAzNTZlZjAg YXQgd2l0bmVzc193YXJuKzB4M2ZjDQojMiAweGMwNWVjMDQ4IGF0IGFib3J0X2hhbmRsZXIrMHgx ZDgNCiMzIDB4YzA1Y2I1YWMgYXQgZXhjZXB0aW9uX2V4aXQrMA0KIzQgMHhlMzA4M2MxMCBhdCBw Zl9zeW5jb29raWVfdmFsaWRhdGUrMHg2MA0KIzUgMHhlMzA0OTZhOCBhdCBwZl90ZXN0KzB4NTE4 DQojNiAweGUzMDZkNzY4IGF0IHBmX2NoZWNrX291dCsweDMwDQojNyAweGMwNDE1YjQ0IGF0IHBm aWxfcnVuX2hvb2tzKzB4YmMNCiM4IDB4YzA0NDVjZmMgYXQgaXBfb3V0cHV0KzB4Y2U4DQojOSAw eGMwNDViYzljIGF0IHRjcF9kZWZhdWx0X291dHB1dCsweDIwYWMNCiMxMCAweGMwNDcxZWI0IGF0 IHRjcF91c3Jfc2VuZCsweDFhYw0KIzExIDB4YzAzODk0NjQgYXQgc29zZW5kX2dlbmVyaWMrMHg0 OTANCiMxMiAweGMwMzg5NzkwIGF0IHNvc2VuZCsweDY0DQojMTMgMHhjMDUwMjg4OCBhdCBjbG50 X3ZjX2NhbGwrMHg1NjANCiMxNCAweGMwNTAwOWQ4IGF0IGNsbnRfcmVjb25uZWN0X2NhbGwrMHgx NzANCiMxNSAweGMwMWU3YjE0IGF0IG5ld25mc19yZXF1ZXN0KzB4YjIwDQojMTYgMHhjMDIzMDIx OCBhdCBuZnNjbF9yZXF1ZXN0KzB4NjANCiMxNyAweGMwMjBkOWJjIGF0IG5mc3JwY19nZXRhdHRy KzB4YjANCkZhdGFsIGtlcm5lbCBtb2RlIGRhdGEgYWJvcnQ6ICdBbGlnbm1lbnQgRmF1bHQnIG9u IHJlYWQNCnRyYXBmcmFtZTogMHhkZjFmMWM5MA0KRlNSPTAwMDAwMDAxLCBGQVI9ZDc4NDAyNjQs IHNwc3I9NDAwMDAwMTMNCnIwID02YTIyOGVkYSwgcjEgPWRhYzBkNzg1LCByMiA9ZDc4NDAyNjQs IHIzID1kYjU1MjdjMA0KcjQgPWRmMWYxZTAwLCByNSA9ZGFjMGQ3NWYsIHI2ID0wMDAwMDAxOCwg cjcgPWQ5NDIyYzAwDQpyOCA9YzA5M2U1ZTQsIHI5ID0wMDAwMDAwMSwgcjEwPWRmMWYxZjVjLCBy MTE9ZGYxZjFkMzgNCnIxMj1lMzA5OGRkMCwgc3NwPWRmMWYxZDIwLCBzbHI9ZTMwODNiZGMsIHBj ID1lMzA4M2MxMA0KDQpwYW5pYzogRmF0YWwgYWJvcnQNCmNwdWlkID0gMQ0KdGltZSA9IDE2NTEz NjYwODkNCktEQjogc3RhY2sgYmFja3RyYWNlOg0KZGJfdHJhY2Vfc2VsZigpIGF0IGRiX3RyYWNl X3NlbGYNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzA1YzhjMDAg Jm5ic3A7bHIgPSAweGMwMDdhYzhjIChkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgzMCkNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjFhNjggJm5ic3A7ZnAgPSAw eGRmMWYxYjgwDQpkYl90cmFjZV9zZWxmX3dyYXBwZXIoKSBhdCBkYl90cmFjZV9zZWxmX3dyYXBw ZXIrMHgzMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhjMDA3YWM4 YyAmbmJzcDtsciA9IDB4YzAyZTI4OWMgKHZwYW5pYysweDE3MCkNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjFiODggJm5ic3A7ZnAgPSAweGRmMWYxYmE4DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjQgPSAweDAwMDAwMTAwICZuYnNwO3I1 ID0gMHgwMDAwMDAwMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I2ID0gMHhj MDc4MDUyOSAmbmJzcDtyNyA9IDB4YzA5MGVhMTANCnZwYW5pYygpIGF0IHZwYW5pYysweDE3MA0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhjMDJlMjg5YyAmbmJzcDts ciA9IDB4YzAyZTI2NGMgKGRvYWR1bXApDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7c3AgPSAweGRmMWYxYmIwICZuYnNwO2ZwID0gMHhkZjFmMWJiNA0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3I0ID0gMHhkZjFmMWM5MCAmbmJzcDtyNSA9IDB4MDAwMDAwMTMN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4ZDc4NDAyNjQgJm5ic3A7 cjcgPSAweDAwMDAwMDAxDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAw eDAwMDAwMDAxICZuYnNwO3I5ID0gMHhkYjU1MjdjMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHIxMCA9IDB4ZDc4NDAyNjQNCmRvYWR1bXAoKSBhdCBkb2FkdW1wDQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwMmUyNjRjICZuYnNwO2xyID0gMHhjMDVlYzY5 OCAoYWJvcnRfYWxpZ24pDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAw eGRmMWYxYmJjICZuYnNwO2ZwID0gMHhkZjFmMWJlOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3I0ID0gMHhkNzg0MDI2NCAmbmJzcDtyNSA9IDB4ZGYxZjFiYjQNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4YzAyZTI2NGMgcjEwID0gMHhkZjFmMWJi Yw0KYWJvcnRfYWxpZ24oKSBhdCBhYm9ydF9hbGlnbg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3BjID0gMHhjMDVlYzY5OCAmbmJzcDtsciA9IDB4YzA1ZWMxOTggKGFib3J0X2hh bmRsZXIrMHgzMjgpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAweGRm MWYxYmYwICZuYnNwO2ZwID0gMHhkZjFmMWM4OA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3I0ID0gMHgwMDAwMDAxMyAmbmJzcDtyNSA9IDB4ZDc4NDAyNjQNCmFib3J0X2hhbmRs ZXIoKSBhdCBhYm9ydF9oYW5kbGVyKzB4MzI4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cGMgPSAweGMwNWVjMTk4ICZuYnNwO2xyID0gMHhjMDVjYjVhYyAoZXhjZXB0aW9uX2V4 aXQpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYxYzkwICZu YnNwO2ZwID0gMHhkZjFmMWQzOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I0 ID0gMHhkZjFmMWUwMCAmbmJzcDtyNSA9IDB4ZGFjMGQ3NWYNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtyNiA9IDB4MDAwMDAwMTggJm5ic3A7cjcgPSAweGQ5NDIyYzAwDQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAweGMwOTNlNWU0ICZuYnNwO3I5ID0g MHgwMDAwMDAwMQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4ZGYxZjFmNWMN CmV4Y2VwdGlvbl9leGl0KCkgYXQgZXhjZXB0aW9uX2V4aXQNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzA1Y2I1YWMgJm5ic3A7bHIgPSAweGUzMDgzYmRjIChwZl9z eW5jb29raWVfdmFsaWRhdGUrMHgyYykNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtzcCA9IDB4ZGYxZjFkMjAgJm5ic3A7ZnAgPSAweGRmMWYxZDM4DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7cjAgPSAweDZhMjI4ZWRhICZuYnNwO3IxID0gMHhkYWMwZDc4NQ0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3IyID0gMHhkNzg0MDI2NCAmbmJzcDty MyA9IDB4ZGI1NTI3YzANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4 ZGYxZjFlMDAgJm5ic3A7cjUgPSAweGRhYzBkNzVmDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7cjYgPSAweDAwMDAwMDE4ICZuYnNwO3I3ID0gMHhkOTQyMmMwMA0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I4ID0gMHhjMDkzZTVlNCAmbmJzcDtyOSA9IDB4MDAw MDAwMDENCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByMTAgPSAweGRmMWYxZjVjIHIxMiA9 IDB4ZTMwOThkZDANCnBmX3N5bmNvb2tpZV92YWxpZGF0ZSgpIGF0IHBmX3N5bmNvb2tpZV92YWxp ZGF0ZSsweDYwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGUzMDgz YzEwICZuYnNwO2xyID0gMHhlMzA0OTZhOCAocGZfdGVzdCsweDUxOCkNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjFkNDAgJm5ic3A7ZnAgPSAweGRmMWYxZWE4 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjQgPSAweDAwMDIwMDAwICZuYnNw O3I1ID0gMHhkYjRhNjEwMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I2ID0g MHgwMDAwMDAxOCAmbmJzcDtyNyA9IDB4ZDk0MjJjMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtyOCA9IDB4MDAwMDAwMDIgJm5ic3A7cjkgPSAweDAwMDAwMDAxDQpwZl90ZXN0 KCkgYXQgcGZfdGVzdCsweDUxOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bj ID0gMHhlMzA0OTZhOCAmbmJzcDtsciA9IDB4ZTMwNmQ3NjggKHBmX2NoZWNrX291dCsweDMwKQ0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFmMWViMCAmbmJzcDtm cCA9IDB4ZGYxZjFlYzANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4 ZGYxZjFmNWMgJm5ic3A7cjUgPSAweGUzMDZkNzM4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7cjYgPSAweGRiNmJhNjYwICZuYnNwO3I3ID0gMHgwMDAwMDAwMA0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I4ID0gMHhkOTQyMmMwMCAmbmJzcDtyOSA9IDB4ZGI3 NDhkODANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByMTAgPSAweGZmZjcwMDAwDQpwZl9j aGVja19vdXQoKSBhdCBwZl9jaGVja19vdXQrMHgzMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3BjID0gMHhlMzA2ZDc2OCAmbmJzcDtsciA9IDB4YzA0MTViNDQgKHBmaWxfcnVu X2hvb2tzKzB4YmMpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAweGRm MWYxZWM4ICZuYnNwO2ZwID0gMHhkZjFmMWVmMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3I0ID0gMHgwMDAyMDAwMCAmbmJzcDtyNSA9IDB4ZTMwNmQ3MzgNCnBmaWxfcnVuX2hv b2tzKCkgYXQgcGZpbF9ydW5faG9va3MrMHhiYw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3BjID0gMHhjMDQxNWI0NCAmbmJzcDtsciA9IDB4YzA0NDVjZmMgKGlwX291dHB1dCsw eGNlOCkNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjFlZjgg Jm5ic3A7ZnAgPSAweGRmMWYxZmE4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 cjQgPSAweDAwMDAwMTBhICZuYnNwO3I1ID0gMHgwMDAwMGEwYQ0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3I2ID0gMHhkYjRhNjE1OCAmbmJzcDtyNyA9IDB4YzA5NDY5MDgNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyOCA9IDB4ZGI1YmVjMDAgJm5ic3A7cjkg PSAweGQ5NDIyYzAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcjEwID0gMHgwMDAwMDVk Yw0KaXBfb3V0cHV0KCkgYXQgaXBfb3V0cHV0KzB4Y2U4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7cGMgPSAweGMwNDQ1Y2ZjICZuYnNwO2xyID0gMHhjMDQ1YmM5YyAodGNwX2Rl ZmF1bHRfb3V0cHV0KzB4MjBhYykNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtz cCA9IDB4ZGYxZjFmYjAgJm5ic3A7ZnAgPSAweGRmMWYyMGUwDQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7cjQgPSAweDAwMDAwMDAxICZuYnNwO3I1ID0gMHgwMDAwMDAwMA0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I2ID0gMHgwMDAwMDAzNCAmbmJzcDtyNyA9 IDB4ZGI3NDYwMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyOCA9IDB4ZGI0 YTYxNmMgJm5ic3A7cjkgPSAweGRiNGE2MTAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg cjEwID0gMHhkYjc4MjAwMA0KdGNwX2RlZmF1bHRfb3V0cHV0KCkgYXQgdGNwX2RlZmF1bHRfb3V0 cHV0KzB4MjBhYw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhjMDQ1 YmM5YyAmbmJzcDtsciA9IDB4YzA0NzFlYjQgKHRjcF91c3Jfc2VuZCsweDFhYykNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjIwZTggJm5ic3A7ZnAgPSAweGRm MWYyMTYwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjQgPSAweGMwYWY5NTVj ICZuYnNwO3I1ID0gMHhkYjc4MjAwMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3I2ID0gMHgwMDAwMDAwMCAmbmJzcDtyNyA9IDB4ZGI3NDYwMDANCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtyOCA9IDB4MDAwMDAwMDAgJm5ic3A7cjkgPSAweGRiNzQ4ZDgwDQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcjEwID0gMHgwMDAwMDAwMA0KdGNwX3Vzcl9zZW5k KCkgYXQgdGNwX3Vzcl9zZW5kKzB4MWFjDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7cGMgPSAweGMwNDcxZWI0ICZuYnNwO2xyID0gMHhjMDM4OTQ2NCAoc29zZW5kX2dlbmVyaWMr MHg0OTApDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYyMTY4 ICZuYnNwO2ZwID0gMHhkZjFmMjFkMA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3I0ID0gMHhjMDQ3MWQwOCAmbmJzcDtyNSA9IDB4MDAwNDQwMDANCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4ZGI3NDYwMDAgJm5ic3A7cjcgPSAweGRiNTUyN2MwDQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAweDAwMDAwMDAwICZuYnNwO3I5 ID0gMHhkYjc0NjFiOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4ZGI0YjI5 MDANCnNvc2VuZF9nZW5lcmljKCkgYXQgc29zZW5kX2dlbmVyaWMrMHg0OTANCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAzODk0NjQgJm5ic3A7bHIgPSAweGMwMzg5 NzkwIChzb3NlbmQrMHg2NCkNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9 IDB4ZGYxZjIxZDggJm5ic3A7ZnAgPSAweGRmMWYyMjAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7cjQgPSAweDAwMDAwMDAwICZuYnNwO3I1ID0gMHhjMDM4OGZkNA0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I2ID0gMHhkYjU1MjdjMCAmbmJzcDtyNyA9IDB4 MDAwMDAwMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyOCA9IDB4NWU0YTZm MjggJm5ic3A7cjkgPSAweDAwMDAwMTAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcjEw ID0gMHhjNzJmYzQ5MA0Kc29zZW5kKCkgYXQgc29zZW5kKzB4NjQNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAzODk3OTAgJm5ic3A7bHIgPSAweGMwNTAyODg4IChj bG50X3ZjX2NhbGwrMHg1NjApDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3Ag PSAweGRmMWYyMjA4ICZuYnNwO2ZwID0gMHhkZjFmMjJlOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3I0ID0gMHhjMDc2ZTEzMiAmbmJzcDtyNSA9IDB4ZGYxZjIyYWMNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4YzcyZmM1YTAgJm5ic3A7cjcgPSAw eGMwNGZkMzQ4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAweGM3MmZj NDgwIHIxMCA9IDB4YzcyZmM0OTANCmNsbnRfdmNfY2FsbCgpIGF0IGNsbnRfdmNfY2FsbCsweDU2 MA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhjMDUwMjg4OCAmbmJz cDtsciA9IDB4YzA1MDA5ZDggKGNsbnRfcmVjb25uZWN0X2NhbGwrMHgxNzApDQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYyMmYwICZuYnNwO2ZwID0gMHhkZjFm MjM3OA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I0ID0gMHhjMDUwMjMyOCAm bmJzcDtyNSA9IDB4YzA3NjgxMzcNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDty NiA9IDB4ZGI2NWJjNDAgJm5ic3A7cjcgPSAweGM3MmZjNjEwDQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7cjggPSAweGM3MmZjNjAwICZuYnNwO3I5ID0gMHgwMDAwMDAwMA0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4ZGYxZjI0MzgNCmNsbnRfcmVjb25uZWN0 X2NhbGwoKSBhdCBjbG50X3JlY29ubmVjdF9jYWxsKzB4MTcwDQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwNTAwOWQ4ICZuYnNwO2xyID0gMHhjMDFlN2IxNCAobmV3 bmZzX3JlcXVlc3QrMHhiMjApDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3Ag PSAweGRmMWYyMzgwICZuYnNwO2ZwID0gMHhkZjFmMjRhOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3I0ID0gMHgwMDAwMDEyYyAmbmJzcDtyNSA9IDB4YzA1MDA4NjgNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4MDAwMDAwMDAgJm5ic3A7cjcgPSAw eDAwMDAwMDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAweGRmMWYy NTEwICZuYnNwO3I5ID0gMHhjMDcyNjc2MQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHIx MCA9IDB4MDAwMDAwMDANCm5ld25mc19yZXF1ZXN0KCkgYXQgbmV3bmZzX3JlcXVlc3QrMHhiMjAN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAxZTdiMTQgJm5ic3A7 bHIgPSAweGMwMjMwMjE4IChuZnNjbF9yZXF1ZXN0KzB4NjApDQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYyNGIwICZuYnNwO2ZwID0gMHhkZjFmMjRlOA0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I0ID0gMHgwMDAwMDAwMCAmbmJzcDtyNSA9 IDB4MDAwMTg2YTMNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4MDAw MDAwMDMgJm5ic3A7cjcgPSAweDAwMDAwMDAxDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cjggPSAweGRmMWYyNmM4ICZuYnNwO3I5ID0gMHhjMGFmOTU1Yw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4MDAwMDAwMDANCm5mc2NsX3JlcXVlc3QoKSBhdCBuZnNj bF9yZXF1ZXN0KzB4NjANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4 YzAyMzAyMTggJm5ic3A7bHIgPSAweGMwMjBkOWJjIChuZnNycGNfZ2V0YXR0cisweGIwKQ0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFmMjRmMCAmbmJzcDtmcCA9 IDB4ZGYxZjI2MTgNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4MDAw MDAwMDAgJm5ic3A7cjUgPSAweGRiNWFmZDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cjYgPSAweGRiNTUyN2MwICZuYnNwO3I3ID0gMHhlMjlkNDUzYw0KbmZzcnBjX2dldGF0 dHIoKSBhdCBuZnNycGNfZ2V0YXR0cisweGIwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cGMgPSAweGMwMjBkOWJjICZuYnNwO2xyID0gMHhjMDIyM2I4OCAobmZzX2dldGF0dHIr MHhjOCkNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjI2MjAg Jm5ic3A7ZnAgPSAweGRmMWYyN2IwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 cjQgPSAweDAwMDAwMDAwICZuYnNwO3I1ID0gMHhlMjlkNDUzYw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3I2ID0gMHhlMjlkNjY3MCAmbmJzcDtyNyA9IDB4MDAwMDAwMDANCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyOCA9IDB4ZGI1NTI3YzAgJm5ic3A7cjkg PSAweGRmMWYyODMwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcjEwID0gMHhkYjU1Mjdj MA0KbmZzX2dldGF0dHIoKSBhdCBuZnNfZ2V0YXR0cisweGM4DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwMjIzYjg4ICZuYnNwO2xyID0gMHhjMDNiOWI4MCAodm9w X3NpZ2RlZmVyKzB4MzQpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3AgPSAw eGRmMWYyN2I4ICZuYnNwO2ZwID0gMHhkZjFmMjdjOA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3I0ID0gMHhkZjFmMjk5OCAmbmJzcDtyNSA9IDB4ZmZmZmZmZmYNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4YzAyMjNhYzAgJm5ic3A7cjcgPSAweDAw MDAwMDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjggPSAweGRmMWYyZDYw ICZuYnNwO3I5ID0gMHhkYjc5NTgwMA0Kdm9wX3NpZ2RlZmVyKCkgYXQgdm9wX3NpZ2RlZmVyKzB4 MzQNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAzYjliODAgJm5i c3A7bHIgPSAweGMwMjIxYTAwIChuZnNfbG9va3VwKzB4MzQ0KQ0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFmMjdkMCAmbmJzcDtmcCA9IDB4ZGYxZjJhYTgNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4ZTI5ZDY2NzAgJm5ic3A7cjUg PSAweGRmMWYyODMwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYgPSAweGUy OWQ2NjYwIHIxMCA9IDB4ZGI1NTI3YzANCm5mc19sb29rdXAoKSBhdCBuZnNfbG9va3VwKzB4MzQ0 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwMjIxYTAwICZuYnNw O2xyID0gMHhjMDNiOWI4MCAodm9wX3NpZ2RlZmVyKzB4MzQpDQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYyYWIwICZuYnNwO2ZwID0gMHhkZjFmMmFjMA0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I0ID0gMHhkZjFmMmFlNCAmbmJzcDtyNSA9 IDB4MDAwMDAwMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4YzAy MjE2YmMgJm5ic3A7cjcgPSAweDAwMDgwMDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cjggPSAweGRmMWYyZDYwICZuYnNwO3I5ID0gMHgwMDAwMDAwMg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4MDAwMDAwMDANCnZvcF9zaWdkZWZlcigpIGF0IHZvcF9z aWdkZWZlcisweDM0DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMw M2I5YjgwICZuYnNwO2xyID0gMHhjMDNiZTU1YyAobG9va3VwKzB4NDZjKQ0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFmMmFjOCAmbmJzcDtmcCA9IDB4ZGYxZjJi MTANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4ZGYxZjJkMDAgJm5i c3A7cjUgPSAweGRiOWU0ZWE4DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYg PSAweGRmMWYyZDU4IHIxMCA9IDB4MDAwMDAwMDANCmxvb2t1cCgpIGF0IGxvb2t1cCsweDQ2Yw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhjMDNiZTU1YyAmbmJzcDts ciA9IDB4YzAzYmQ0NTAgKG5hbWVpKzB4M2NjKQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3NwID0gMHhkZjFmMmIxOCAmbmJzcDtmcCA9IDB4ZGYxZjJiYjgNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4ZGYxZjJkMDAgJm5ic3A7cjUgPSAweGZmZmZm ODFjDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYgPSAweDAwMDAwMDAwICZu YnNwO3I3ID0gMHhkYjNiY2M5MA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I4 ID0gMHhjMGI1YTQ4YyAmbmJzcDtyOSA9IDB4ZGI1NTI3YzANCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyByMTAgPSAweGRmMWYyZDYwDQpuYW1laSgpIGF0IG5hbWVpKzB4M2NjDQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwM2JkNDUwICZuYnNwO2xyID0gMHhj MDNlNGU5OCAodm5fb3Blbl9jcmVkKzB4NDVjKQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3NwID0gMHhkZjFmMmJjMCAmbmJzcDtmcCA9IDB4ZGYxZjJjYzgNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4MDAwMDAwMDEgJm5ic3A7cjUgPSAweDAwMDAw MDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYgPSAweDAwMTAwMDAxICZu YnNwO3I3ID0gMHhkZjFmMmQ2MA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I4 ID0gMHhmZmZmZmY5YyAmbmJzcDtyOSA9IDB4ZGYxZjJkMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyByMTAgPSAweGRmMWYyZDU4DQp2bl9vcGVuX2NyZWQoKSBhdCB2bl9vcGVuX2NyZWQr MHg0NWMNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAzZTRlOTgg Jm5ic3A7bHIgPSAweGMwM2U0YTM0ICh2bl9vcGVuKzB4MjQpDQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7c3AgPSAweGRmMWYyY2QwICZuYnNwO2ZwID0gMHhkZjFmMmNkOA0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I0ID0gMHhkYjU1MjdjMCAmbmJzcDtyNSA9 IDB4ZGYxZjJkMDANCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNiA9IDB4MDAw MDAwMDAgJm5ic3A7cjcgPSAweGRmMWYyZDAwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cjggPSAweGZmZmZmZjljICZuYnNwO3I5ID0gMHgwMDAwMDAxMg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHIxMCA9IDB4MjAwNzZiMDQNCnZuX29wZW4oKSBhdCB2bl9vcGVuKzB4 MjQNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYyA9IDB4YzAzZTRhMzQgJm5i c3A7bHIgPSAweGMwM2RiNDI4IChrZXJuX29wZW5hdCsweDI1NCkNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtzcCA9IDB4ZGYxZjJjZTAgJm5ic3A7ZnAgPSAweGRmMWYyZGI4DQpr ZXJuX29wZW5hdCgpIGF0IGtlcm5fb3BlbmF0KzB4MjU0DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7cGMgPSAweGMwM2RiNDI4ICZuYnNwO2xyID0gMHhjMDNkYjZiMCAoc3lzX29w ZW5hdCsweDJjKQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFm MmRjMCAmbmJzcDtmcCA9IDB4ZGYxZjJkYzgNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtyNCA9IDB4ZGI1NTI3YzAgJm5ic3A7cjUgPSAweDAwMDAwMDAxDQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYgPSAweGMwOGQ5OWNjICZuYnNwO3I3ID0gMHgwMDAwMDAw MA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3I4ID0gMHgwMDAwMDAwMCAmbmJz cDtyOSA9IDB4ZGI1NTJhNjgNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByMTAgPSAweGRi YTI5YzgwDQpzeXNfb3BlbmF0KCkgYXQgc3lzX29wZW5hdCsweDJjDQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwM2RiNmIwICZuYnNwO2xyID0gMHhjMDVlYjliNCAo c3dpX2hhbmRsZXIrMHgxNWMpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3Ag PSAweGRmMWYyZGQwICZuYnNwO2ZwID0gMHhkZjFmMmU0MA0Kc3dpX2hhbmRsZXIoKSBhdCBzd2lf aGFuZGxlcisweDE1Yw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BjID0gMHhj MDVlYjliNCAmbmJzcDtsciA9IDB4YzA1Y2I1M2MgKHN3aV9leGl0KQ0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3NwID0gMHhkZjFmMmU0OCAmbmJzcDtmcCA9IDB4YmZiZmU3MjAN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyNCA9IDB4MjAyN2QyZjQgJm5ic3A7 cjUgPSAweDAwMDY1YzQwDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cjYgPSAw eDIwMDc2YWM4ICZuYnNwO3I3ID0gMHgwMDAwMDFmMw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3I4ID0gMHgwMDAwMDAwMSAmbmJzcDtyOSA9IDB4MDAwNjVjNDANCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyByMTAgPSAweDAwMDY0ZDg4DQpzd2lfZXhpdCgpIGF0IHN3aV9l eGl0DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGMgPSAweGMwNWNiNTNjICZu YnNwO2xyID0gMHhjMDVjYjUzYyAoc3dpX2V4aXQpDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7c3AgPSAweGRmMWYyZTQ4ICZuYnNwO2ZwID0gMHhiZmJmZTcyMA0KS0RCOiBlbnRl cjogcGFuaWMNClsgdGhyZWFkIHBpZCA1NzkgdGlkIDEwMDEyMiBdDQpTdG9wcGVkIGF0ICZuYnNw OyAmbmJzcDsgJm5ic3A7a2RiX2VudGVyKzB4NTg6IGxkcmIgJm5ic3A7ICZuYnNwO3IxNSwgW3Ix NSwgcjE1LCByb3IgcjE1XSENCjwvcHJlPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj4NCg0K --b1_KLMBgySICMKCy7cAmgd167xn7vD9D1vF7GZ5ze9K4Y-- From nobody Sun May 1 15:54:14 2022 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 B6CD3199C00F for ; Sun, 1 May 2022 15:54:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KrrPp5Xd9z4bPG; Sun, 1 May 2022 15:54:22 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 241FsElQ029891 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 1 May 2022 08:54:14 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 241FsE3h029890; Sun, 1 May 2022 08:54:14 -0700 (PDT) (envelope-from sgk) Date: Sun, 1 May 2022 08:54:14 -0700 From: Steve Kargl To: Ed Maste Cc: FreeBSD Current Subject: Re: Profiled libraries on freebsd-current Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KrrPp5Xd9z4bPG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [0.17 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.11)[-0.111]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(0.39)[0.390]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.11)[-0.107]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Sat, Apr 30, 2022 at 04:07:48PM -0400, Ed Maste wrote: > On Sat, 30 Apr 2022 at 11:34, Steve Kargl > wrote: > > > > On Sat, Apr 30, 2022 at 09:39:32AM -0400, Ed Maste wrote: > > > On Fri, 29 Apr 2022 at 01:58, Steve Kargl > > > wrote: > > > > > > > > If one looks at src.conf(5), one finds > > > > > > > > WITH_PROFILE > > > > Build profiled libraries for use with gprof(8). This option is > > > > deprecated and is not present in FreeBSD 14. > > > > > > > > I assume that the *_p.a libraries will no longer be built and > > > > installed on FreeBSD 14 and later. Is this correct? > > > > > > FreeBSD 14 is not yet released, of course, but that is indeed the > > > intent. PR256874 reports that a GCC patch (to stop linking against > > > _p.a) is in the works but unfortunately has not had an update for some > > > time. > > > > I see. It only took me 2+ years to get > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 > > > > committed to the GCC repository. Good luck with > > getting your patch upstream. > > Heh, thanks. > > I have just now changed the WITH_PROFILE description to state "a > future version of FreeBSD" since it may well not happen for FreeBSD > 14. > > We could also just install libc_p.a as a symlink to libc.a (and same > for the other _p.a archives). This works for me, but there is one addition place dealing with -pg in freebsd-spec.h diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h index 594487829b5..1e8ab2e1827 100644 --- a/gcc/config/freebsd-spec.h +++ b/gcc/config/freebsd-spec.h @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see (similar to the default, except no -lg, and no -p). */ #ifdef FBSD_NO_THREADS +#if FBSD_MAJOR < 14 #define FBSD_LIB_SPEC " \ - %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \ + %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \ is built with the --enable-threads configure-time option.} \ %{!shared: \ %{!pg: -lc} \ %{pg: -lc_p} \ }" #else +#define FBSD_LIB_SPEC " \ + %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \ +is built with the --enable-threads configure-time option.} \ + }" +#endif +#else +#if FBSD_MAJOR < 14 #define FBSD_LIB_SPEC " \ %{!shared: \ %{!pg: %{pthread:-lpthread} -lc} \ @@ -109,6 +117,15 @@ is built with the --enable-threads configure-time option.} \ %{shared: \ %{pthread:-lpthread} -lc \ }" +#else +#define FBSD_LIB_SPEC " \ + %{!shared: \ + %{pthread:-lpthread} -lc \ + } \ + %{shared: \ + %{pthread:-lpthread} -lc \ + }" +#endif #endif /* To make matters interesting, we can't actually use __FreeBSD_version -- Steve From nobody Sun May 1 15:29:27 2022 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 C0FDB199DEAB for ; Sun, 1 May 2022 16:00:41 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (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 4KrrY43VLLz4dLD for ; Sun, 1 May 2022 16:00:40 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 2696B4; Sun, 1 May 2022 17:29:28 +0200 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 \(3696.80.82.1.1\)) Subject: Re: Cross-compile worked, cross-install not so much ... From: "Patrick M. Hausen" In-Reply-To: <20220426154710.GA28444@www.zefox.net> Date: Sun, 1 May 2022 17:29:27 +0200 Content-Transfer-Encoding: 7bit Message-Id: <01953B28-24C2-4E05-8ABC-D7C6F82DCFC2@hausen.com> References: <3D48BE93-7D42-4AB2-82D4-88BBF4E1FD40@hausen.com> <20220425191823.GA89506@spindle.one-eyed-alien.net> <7FA0C88D-4446-47DD-BBC0-3300B26D6A27@hausen.com> <68DCDD88-F7EB-4904-AAD6-D15ED3FF4259@hausen.com> <20220426154710.GA28444@www.zefox.net> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4KrrY43VLLz4dLD X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pmh@hausen.com has no SPF policy when checking 217.29.33.228) smtp.mailfrom=pmh@hausen.com X-Spamd-Result: default: False [-0.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[hausen.com]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.31)[-0.311]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi all, > Am 26.04.2022 um 17:47 schrieb bob prohaska : > If the result is unsatisfactory, self-hosting isn't impossible. I've been > doing it for a few years now, albeit with much help from the list. On a > Pi3 running aarch64 memory and swap are a constraint. I'd suggest 4 GB > of swap and -j2 or -j3, perhaps increasing to -j4 as you see how things > go. If you can split the swap across devices it helps some. Useful > /boot/loader.conf tweaks include > > vm.pageout_oom_seq="4096" > vm.pfault_oom_attempts="120" > vm.pfault_oom_wait="20" > > Mark Millard made me aware of these parameters over the list. without any additional tuning but with an SSD connected via USB and 4GB swap on that I was able to compile with -j4 and a mostly CPU bound system. -------------------------------------------------------------- >>> World build completed on Thu Apr 28 10:30:53 CEST 2022 >>> World built in 155832 seconds, ncpu: 4, make -j4 -------------------------------------------------------------- -------------------------------------------------------------- >>> Kernel build for GENERIC completed on Thu Apr 28 13:11:37 CEST 2022 >>> Kernel(s) GENERIC built in 9643 seconds, ncpu: 4, make -j4 -------------------------------------------------------------- Thanks everyone for your valuable hints. Guess I will subscribe to -arm, since there are some more rough edges compared to "just put a Debian or Ubuntu image on it". And then I wonder what workload I can put on a seven-node FreeBSD cluster, since it won't be k8s, obviously. Let's start with Ceph, I guess. Kind regards Patrick From nobody Sun May 1 21:53:32 2022 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 6E7B11AB0418 for ; Sun, 1 May 2022 21:53:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ks0NT0yMvz4cWb for ; Sun, 1 May 2022 21:53:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651442017; bh=2gChDu23QKAmX5medQOFevaN8vzJWF0pgdH7yHVjB9A=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=kcrYaEZy+PVbU4+B2QilqukkFPRAx27qiuFFXhFux9t+mjJGnVu6sJ8xX87/H049vxfzgA+k5r1GkMW8HqFpOE+rJ/HV48QWGciSNIZ7i7Av+YN1J5x1IQWpopIJkehDJEn2qrdtC+vGKksrGox4p2yEK6D3Lpp5k/s1LSXRqSPNlbewjEs3i/ApMy+6xZ3uJ+R/kCByLIy5dERiLVzW0ljdp0s0UNzXJjdh0D4wwwBV3uKf1FIFr9q5iI57eTssTT8xEeSveiNHLqC9/xhovIB0T+evqofrF1/DTgdv+fzBSY4N6yPgQm9sNrztv8AoHEDC3ze/QH8TlCmWWyAafQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651442017; bh=AvxxmfeHWM865Yiact5XmzLDnEcl/rk3+TverUkl6iu=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ZyHCMNpwdedG/UCWbu//anEmVO0dsjanFykF8m19IA6VFTlEf1C3rmm2NRfH9G47T2PyhwzaVU8Ufk2o+tWfN18iPr1T7242IcawKe+wpfWBzb0CxpsbrBbOhVq1ch4QBZD9/28us8h5hvkAP/TkYwZs0zsf5mHyLfpvji97LdHE/Q39VQq1Hi0QWoQ3h2VKKBjsqwlZeH0BKg0fVSzS1tyHs6D69P3Jcc3X/PweDS1zUnEH/zAsqlmYlSzb3gQLj/s9A36VVT1xtdPqpk/Yq+/XYY5G1ok0RLmW+Drf8BYfpmC/EuHVIBuDOCynMyQd/71y0IGbhRiEWWbsqar/CQ== X-YMail-OSG: _6ugAxgVM1nijpPixr09OdoCQFL.gf.Mt0FAYbNMY9PNZn.D.KCdSAM7wq4X8kF sDKtgNoY5NL.VjH9wpXcXiLwg8q5XoIi4ozFDBFVqWUTgkdwM5OxinhL5VvKDtLBmVndtufGFc68 CYUnr_Q_ctOtDdd.M1KbQyC17TR51YSV22lRujh9IDxBNJPtZehnIwW21t_DfHEHdhMCzv_nvu7k ZIu8_P3xHKPFZdbjc0zCTWYwxkhOmz0wYV_.tLuuwGSUbucJbMF.5RsIYQ1YIHcCyLy0Sazz_hO_ MU1E5j7mcdMp37CPkPom5.knRmQjaQQz29szVNeFL.ofoEzegVbaoY9MgPMBV.surjNTwJcPH_Qv zpRYZKiJn4wmV4m9j92icagZYMiMrTLaCF9ozXgRMCUKfQmz_SdvbFoy.5pnUbNg9IbxP9FeFpeo yc0ti9XMP4LALW0TtR.TNuJeKyLdLtBk6Bs.Xc86nv3Qr5nFXIeuFQOBAjyF24RpS44mIPGHqLYD szltCTbygzn1pFHLpUF4IPv.tgU2PCn2ebbKhSQbKgHixjFS.JslYI7xWd3L3EDhv0bywKZs60L0 q_HNuOQ1GHtaBPZ2yMxOwxZLfIOCpT1jCTGIqZxbdbpgGM97pqF8_CJZCLCbpU74ncdQ3TYCDItu HK31ZrCfI8IQWs0VY19IEG0agzt0fLOdGQNsrgTQoZVSJJquKF9KdbBXBBVR2l9xFx_0U6oXiFGn cz4kbk3TGEPilK0Hx48hLbxUVuRoLh8rySyMSJPZG.HP4gMofStI5SAHyBxsW564qqLwf6_UA.6c jnVrY0rVQ9Fhb9dZrfP09eBLdDjCCeJ.91BFSKYBaKUBs2QBNaV3pVBa6W1iGxeWeyi97_GCXckU bK3mEWQU3b6Eq3sVmId_b4tCd7LtVK86zLlG1vfkheHb4XMo7Db2w8B5RJ1Mo_yPD9rRxcTUBCVD sesXJQucL0hs24Kd7evk4t9.0GyiNqMd8t_CgKPX1QD9l0aeBPUtaCLeAmdiG0Of7sIByIKKyuZF fhHvHKUcje1Coo9wy7EJ.9IPomB.I0S3cfWFhDCoddfpYtzgPI4cHJ1fpKLlChNVQZiFTCtR._cS f9C9S5co9bBpYhfvxbMFyQ2DzW7fjMzgeOGto.Dgs5SYcNCeaE4DO8d6tYPDKxlwpeTyIwgXC4eI Lj1OAXhe3636MWAO4.xEms933_ckc80xZdH4maGzGBJp21EJdZF2MTactgvuO442SaGxZy.MreYw MWzPVQLinkVvPwIbXGmaAJiRUuVkjJbmYs36pCe3m9KzfVIzc3Od3YLVysZDxjfupxj4sMosPeKz kEBTRmKzEFQFb4.4W2Kl2bIPXwNTzx7KNKkmcXUWVr0.KPQ0wuyKEPueHLiaDluj.Hz4lJII43Sc wJJgXlCMQU7KwfqlZWtkBUE7QX3LRLGA6qHwf5Df8xDV8iITa6ZoBLuU6m6UznDFRVFQ7UFTZ2V. ayao1j9rCaSCZUN_.7HH.hX8BqpTQety4SGH8Oo3LWhE4peeN2kkwjRRWQUmr_dKcrJ.8bbeMcyi Dz6KZj4OguLrUjESfIdi0K5MkGgz7fvbbs54pcqpJZKZiAuQTZXphWChDDXsUnwGbTYnyHs_tnhq aWM89tzwuVf1zRyAYt8UsMlOwimre6Nc1zjLH5ecox_Uye_rqk5m_C78RaJB1JTZcHuhjM.SHtJL skvXvnq7C2cu6zDvYhXKDJ8205wuF1Z5rP2DT2ncIQhFeFPRh49NjzMjjaFvEc5_cpfh09VuXwhC Oya7dF.Z25qaFwpytYe38QWlrJPfN3XAbwAJP2z0JWkVcTBO3zHY4vDhj4CaMPXCCgxY6nix74RM zQoMso_nwCmHBoH3mxIAdgiA4VNWIndLuhL42eGX6ZtTu0HITxHhlowyb1IUQHwp8.eFuA2DIvTK HWADjk.9tJT_BR_geEX4TXCxTWmAUEuco8f0LSHta9huNqbWhltFGmdkewl4MNzZ5Xl_PbHjzpOl E.naiW47CqY0.40ree6F6hmVeqx_m3x2M5q1ta3D0AbwpOHMua8nipauh65f.lYEdY5Hdy_qwXcb u38GpqJ5ZXkvmjK3srSwfhjBx5lrnhaJT89zJP5Algb94g.Rxnq25PfZOHQespY._XRpZmkR7l8Y .XbnsVAMfOirDKMl6b84UFo_6S4GY.P5Gyz9LEFnHIj4eKH.kN2Np5Oa9_PK6QLuw9KEuIolh.I9 Nt_1UCFBUNRkmlN20e6dVLPxOMGTNRzfB1JeC6zU97U5nTSwqIgiMtHeU1EIUc5hdUBfdE9Trxh9 w33tIsRE1uT0w9w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 May 2022 21:53:37 +0000 Received: by hermes--canary-production-ne1-75b69fcf97-8xk25 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 62025c63a2cfcb187d5fa331aebad27a; Sun, 01 May 2022 21:53:34 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Cross-compile worked, cross-install not so much ... Message-Id: Date: Sun, 1 May 2022 14:53:32 -0700 To: pmh@hausen.com, freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4Ks0NT0yMvz4cWb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kcrYaEZy; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Patrick M. Hausen wrote on Date: Sun, 1 May 2022 17:29:27 +0200 : > > Am 26.04.2022 um 17:47 schrieb bob prohaska : > > If the result is unsatisfactory, self-hosting isn't impossible. I've been > > doing it for a few years now, albeit with much help from the list. On a > > Pi3 running aarch64 memory and swap are a constraint. I'd suggest 4 GB > > of swap and -j2 or -j3, perhaps increasing to -j4 as you see how things > > go. If you can split the swap across devices it helps some. Useful > > /boot/loader.conf tweaks include > > > > vm.pageout_oom_seq="4096" > > vm.pfault_oom_attempts="120" > > vm.pfault_oom_wait="20" > > > > Mark Millard made me aware of these parameters over the list. And going back farther: Mark Johnston made us both aware of vm.pageout_oom_seq and its use back when you were having problems with the system killing processes. He had provided some investigative patches that we used as well. THat is part of how Mark J. determiened that vm.pageout_oom_seq use was appropraite. Konstantin Belousov als corrected my mistaken mental model relative to FreeBSD swapping/paging back in that time frame --and that feeds into what vm.pageout_oom_seq controls. In recent enough 13.1-??? , stable/13 , and main : Console messages with: was killed: failed to reclaim memory are tied to what vm.pageout_oom_seq controls: the number of tries to reclaim the targeted amount of free RAM before initiating kills to do so. Console messages with: was killed: a thread waited too long to allocate a page are tied to the combination of vm.pfault_oom_attempts and vm.pfault_oom_wait used, which, together result in an overall time frame (multiply the two) before such kills start. There can be messages with: was killed: out of swap space which is somewhat of a misnomer: the out-of-space is actually in one or both of a couple of related kernel data structures for managing the swap space, not the swap partition content itself. As near as I can tell, this type of failure is rare. But I'll note that in FreeBSD versions before the messages were added for "failed to reclaim memory" and "waited too long to allocate a page", the messaging always said words about "out of swap space" for all 3 types of contexts: rather misleading. > without any additional tuning but with an SSD connected via USB > and 4GB swap on that I was able to compile with -j4 and a mostly CPU > bound system. > > -------------------------------------------------------------- > >>> World build completed on Thu Apr 28 10:30:53 CEST 2022 > >>> World built in 155832 seconds, ncpu: 4, make -j4 > -------------------------------------------------------------- > -------------------------------------------------------------- > >>> Kernel build for GENERIC completed on Thu Apr 28 13:11:37 CEST 2022 > >>> Kernel(s) GENERIC built in 9643 seconds, ncpu: 4, make -j4 > -------------------------------------------------------------- So: a little under 46 hours, if I calculated right. I'll note that in some past experiments on some types of RPi*'s, using -j3 actually took less overall time than -j4 when deliberately repeating from-scratch builds. The differences were not all that large as I remember. But, if -j3 and -j4 end up with even similar time frames, then -j3 has the additional advantage in limited-RAM contexts of not being as likely to have resource problems. So -j3 could be appropriate. I do not know if -j3 would work out better for you or not. I'm just noting that it may be worth experimenting with. > Thanks everyone for your valuable hints. Guess I will subscribe to > -arm, since there are some more rough edges compared to "just put a > Debian or Ubuntu image on it". > > And then I wonder what workload I can put on a seven-node FreeBSD > cluster, since it won't be k8s, obviously. Let's start with Ceph, I guess. === Mark Millard marklmi at yahoo.com From nobody Mon May 2 08:49:31 2022 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 991041AB9D26; Mon, 2 May 2022 08:49:44 +0000 (UTC) (envelope-from qroxana@protonmail.com) Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) (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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsGxM2qWZz4p9M; Mon, 2 May 2022 08:49:43 +0000 (UTC) (envelope-from qroxana@protonmail.com) Date: Mon, 02 May 2022 08:49:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1651481375; bh=sNybVuKPxHy0LR7qkI9AJdEKxppkOR7t0v1Dl54ILks=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=EHG+DE1udFzVrJ9AbVxKDlghUReSyPQD1dg1ACMrsiZTyEzPMXQnu5FLRAMVpa+ff cuAGjIcI1YJBzLgjrsYhtMfXUb9TQfRtboXsJbPseJnNXHs5tFayJma/vzTxIFNA+j zrbIbxlPJ5kPMGnyrLFgPsPeSJ6FBgpexk07Zx1Vi2CuEsbRBDlEqvrC5Hf+QMyY43 mWLRTs6nS685KKDmC2R5kMIyPw/MY+JohJ6Qc5B2PGaFD6lF0f72iwAifAIPyYU6QP TaTpWA7iP4AsC9lw+1qptG9O7W16FSf9UhEuEdfOhHS8tAKwrRF4HeSg6ZTqS/1Apb 6S/lufA3TZCeQ== To: "freebsd-current@freebsd.org" , "freebsd-arm@freebsd.org" From: qroxana Reply-To: qroxana Subject: Re: Kernel panic on armv7 when PF is enabled Message-ID: In-Reply-To: References: Feedback-ID: 29996633:user:proton 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="b1_iLtuRwHRJcv2T8nUaHcj6INGyNbfd2eSj8g2OzXOM" X-Rspamd-Queue-Id: 4KsGxM2qWZz4p9M X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail2 header.b=EHG+DE1u; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of qroxana@protonmail.com designates 185.70.43.18 as permitted sender) smtp.mailfrom=qroxana@protonmail.com X-Spamd-Result: default: False [3.00 / 15.00]; HAS_REPLYTO(0.00)[qroxana@protonmail.com]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail2]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.913]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.986]; NEURAL_SPAM_LONG(1.00)[1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_iLtuRwHRJcv2T8nUaHcj6INGyNbfd2eSj8g2OzXOM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 T24gU3VuLCAwMSBNYXkgMjAyMiAwMzoxMzo0MyArMDAwMCwgcXJveGFuYSA8cXJveGFuYUBwcm90 b25tYWlsLmNvbT4gd3JvdGU6Cgo+IEFmdGVyIGdpdCBiaXNlY3RpbmcgdGhlIHBhbmljIHN0YXJ0 ZWQgc2luY2UgdGhpcyBjb21taXQuCj4KPiBjb21taXQgNzhiYzNkNWUxNzEyYmMxNjQ5YWE1NTc0 ZDJiOGQxNTNmOTY2NTExMwo+IEF1dGhvcjogS3Jpc3RvZiBQcm92b3N0IDxrcEBGcmVlQlNELm9y Zz4KPiBEYXRlOiAgIE1vbiBGZWIgMTQgMjA6MDk6NTQgMjAyMiArMDEwMAo+Cj4gICAgIHZsYW46 IGFsbG93IG5ldC5saW5rLnZsYW4ubXRhZ19wY3AgdG8gYmUgc2V0IHBlciB2bmV0Cj4KPiAgICAg VGhlIHByaW1hcnkgcmVhc29uIGZvciB0aGlzIGNoYW5nZSBpcyB0byBmYWNpbGl0YXRlIHRlc3Rp bmcuCj4KPiAgICAgTUZDIGFmdGVyOiAgICAgIDEgd2Vlawo+Cj4gc3lzL25ldC9pZl9ldGhlcnN1 YnIuYyB8IDkgKysrKystLS0tCj4gc3lzL25ldC9pZl92bGFuLmMgICAgICB8IDUgKysrLS0KPiAy IGZpbGVzIGNoYW5nZWQsIDggaW5zZXJ0aW9ucygrKSwgNiBkZWxldGlvbnMoLSkKPgo+IFRoZSBh cm12NyBib2FyZCBib290cyBmcm9tIGEgTkZTIHJvb3QsCj4KPiBpdCBjYW4gYm9vdCB3aXRob3V0 IGFueSBwcm9ibGVtIGlmIFBGIGlzIGRpc2FibGVkLgoKSXQgYXBwZWFycyB0aGlzIG9ubHkgb2Nj dXJzIHdoZW4gdGhlIHJvb3RmcyBpcyBORlMsCkkgYWxzbyB0cmllZCB0byBib290IGl0IGZyb20g YSBtaWNybyBTRCBjYXJkLCBubyBrZXJuZWwgcGFuaWMuCgpBbm90aGVyIHdvcmthcm91bmQgdG8g YXZvaWQgdGhlIHBhbmljIGlzIHRvIGRlbGF5CnN0YXJ0aW5nIC9ldGMvcmMuZC9wZiB0byBTRVJW RVJTCgotLS0gcGYub3JpZwkyMDIyLTAzLTEyIDEyOjI2OjQ3LjAwMDAwMDAwMCArMDAwMAorKysg cGYJMjAyMi0wNS0wMiAwMjo1OToyOC4xMzEwMjY4NjIgKzAwMDAKQEAgLTQsNyArNCw3IEBACiAj CgogIyBQUk9WSURFOiBwZgotIyBSRVFVSVJFOiBGSUxFU1lTVEVNUyBuZXRpZiBwZmxvZyBwZnN5 bmMgcm91dGluZworIyBSRVFVSVJFOiBTRVJWRVJTIG5ldGlmIHBmbG9nIHBmc3luYyByb3V0aW5n CiAjIEtFWVdPUkQ6IG5vamFpbHZuZXQKCiAuIC9ldGMvcmMuc3VicgoKVGhhbmtzLA== --b1_iLtuRwHRJcv2T8nUaHcj6INGyNbfd2eSj8g2OzXOM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHByZT5PbiBTdW4sIDAxIE1heSAyMDIyIDAzOjEzOjQzICswMDAwLCBxcm94YW5hICZsdDtxcm94 YW5hQHByb3Rvbm1haWwuY29tJmd0OyB3cm90ZToNCg0KJmd0OyBBZnRlciBnaXQgYmlzZWN0aW5n IHRoZSBwYW5pYyBzdGFydGVkIHNpbmNlIHRoaXMgY29tbWl0Lg0KJmd0Ow0KJmd0OyBjb21taXQg NzhiYzNkNWUxNzEyYmMxNjQ5YWE1NTc0ZDJiOGQxNTNmOTY2NTExMw0KJmd0OyBBdXRob3I6IEty aXN0b2YgUHJvdm9zdCAmbHQ7a3BARnJlZUJTRC5vcmcmZ3Q7DQomZ3Q7IERhdGU6ICZuYnNwOyBN b24gRmViIDE0IDIwOjA5OjU0IDIwMjIgKzAxMDANCiZndDsNCiZndDsgJm5ic3A7ICZuYnNwOyB2 bGFuOiBhbGxvdyBuZXQubGluay52bGFuLm10YWdfcGNwIHRvIGJlIHNldCBwZXIgdm5ldA0KJmd0 Ow0KJmd0OyAmbmJzcDsgJm5ic3A7IFRoZSBwcmltYXJ5IHJlYXNvbiBmb3IgdGhpcyBjaGFuZ2Ug aXMgdG8gZmFjaWxpdGF0ZSB0ZXN0aW5nLg0KJmd0Ow0KJmd0OyAmbmJzcDsgJm5ic3A7IE1GQyBh ZnRlcjogJm5ic3A7ICZuYnNwOyAmbmJzcDsxIHdlZWsNCiZndDsNCiZndDsgc3lzL25ldC9pZl9l dGhlcnN1YnIuYyB8IDkgKysrKystLS0tDQomZ3Q7IHN5cy9uZXQvaWZfdmxhbi5jICZuYnNwOyAm bmJzcDsgJm5ic3A7fCA1ICsrKy0tDQomZ3Q7IDIgZmlsZXMgY2hhbmdlZCwgOCBpbnNlcnRpb25z KCspLCA2IGRlbGV0aW9ucygtKQ0KJmd0Ow0KJmd0OyBUaGUgYXJtdjcgYm9hcmQgYm9vdHMgZnJv bSBhIE5GUyByb290LA0KJmd0Ow0KJmd0OyBpdCBjYW4gYm9vdCB3aXRob3V0IGFueSBwcm9ibGVt IGlmIFBGIGlzIGRpc2FibGVkLg0KDQpJdCBhcHBlYXJzIHRoaXMgb25seSBvY2N1cnMgd2hlbiB0 aGUgcm9vdGZzIGlzIE5GUywNCkkgYWxzbyB0cmllZCB0byBib290IGl0IGZyb20gYSBtaWNybyBT RCBjYXJkLCBubyBrZXJuZWwgcGFuaWMuDQoNCkFub3RoZXIgd29ya2Fyb3VuZCB0byBhdm9pZCB0 aGUgcGFuaWMgaXMgdG8gZGVsYXkNCnN0YXJ0aW5nIC9ldGMvcmMuZC9wZiB0byBTRVJWRVJTDQoN Ci0tLSBwZi5vcmlnCTIwMjItMDMtMTIgMTI6MjY6NDcuMDAwMDAwMDAwICswMDAwDQorKysgcGYJ MjAyMi0wNS0wMiAwMjo1OToyOC4xMzEwMjY4NjIgKzAwMDANCkBAIC00LDcgKzQsNyBAQA0KJm5i c3A7Iw0KJm5ic3A7DQombmJzcDsjIFBST1ZJREU6IHBmDQotIyBSRVFVSVJFOiBGSUxFU1lTVEVN UyBuZXRpZiBwZmxvZyBwZnN5bmMgcm91dGluZw0KKyMgUkVRVUlSRTogU0VSVkVSUyBuZXRpZiBw ZmxvZyBwZnN5bmMgcm91dGluZw0KJm5ic3A7IyBLRVlXT1JEOiBub2phaWx2bmV0DQombmJzcDsN CiZuYnNwOy4gL2V0Yy9yYy5zdWJyDQoNClRoYW5rcywNCjwvcHJlPjxicj4= --b1_iLtuRwHRJcv2T8nUaHcj6INGyNbfd2eSj8g2OzXOM-- From nobody Mon May 2 09:02:53 2022 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 6A5311ABDC1A; Mon, 2 May 2022 09:02:57 +0000 (UTC) (envelope-from kp@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsHDd2WDFz4rh2; Mon, 2 May 2022 09:02:57 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651482177; 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=SzB63xMfF68oKDS5871Hon0krdh6z5t9G3RCEDEf2eM=; b=WxQBJ7su0zWHHNNip8+KEzm1TOwTiRCNMfJa6bfokBxdFgpguH8ztPrf77F2CVkiGNBgOF 2+LhuQfrBuNIgKbH+/hmIZAoUpOGfoe5UoWw+cPlx1E2rQgcDFmgF3q8x9Vo8xlSuyicxI cPVb/FNxtWzv+0igHSNvyZS1aeWPLA1CSOvFdCb8HZrt8/mVsxNFf8G28mgPl27I4dxWcW bbukoEEifWOWWXHfJZvyhmY+o1RzRPRknq5f+r21ON4yd/QBM5fPSssBBlVr3IJqKYO3MS /WOBiPkMm7EIXJlS9hJS7CcRz41M+fzz4JbUYSdNkfKwejrXy2vPHKtuTdH0jA== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 0E24A7904; Mon, 2 May 2022 09:02:57 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 8280211A66; Mon, 2 May 2022 11:02:54 +0200 (CEST) From: Kristof Provost To: qroxana Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Kernel panic on armv7 when PF is enabled Date: Mon, 02 May 2022 11:02:53 +0200 X-Mailer: MailMate (1.14r5852) Message-ID: In-Reply-To: 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/alternative; boundary="=_MailMate_43ACE16C-8FBB-4703-A9C0-5E8ED6BC4AE9_=" Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651482177; 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=SzB63xMfF68oKDS5871Hon0krdh6z5t9G3RCEDEf2eM=; b=lEecktoBnLy1JivDk8uNkhhKS3zFBxoUEvlsl9/gN5YaV6QoiQRKJPFH+7NxapimBDBLL3 nM3OGnpDmXlJ58pXl0qyPIsLWHr23pA1BsCzuKYPF85TxZaB5WAT+NfyWEE1DemIvKPktw 7wxGvsVOLQAbj+EfFI5dDqDfbsEiK7PYN2S3UHDs9vSjkP5xZQquiGGVhh7wW4Jm3k5B+H P7rPwHmT1Vzizo8odZGRmhBKiiLZ7suocHqTgLtq03FlQScyob+7L28tnVdspstSD+dNm2 WLwI6NhvPd8qNjfOW9hNuV9AhuYv7bjaevRMrQ+SvmqPDLcmnkuchvzOhHjIMg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651482177; a=rsa-sha256; cv=none; b=i3c8526DS6JIz+CpUedqxgwxL4Pfi2YDQCQg9qGdcvBkqgOhmDNWhn2FoWPE9B28F9GHF9 v2lQZzAEMnFzrg5JcX082/Gi3HfeCcp8GWpjxvqe/eYrnvgn353lE7IJLg4uSDexcrNLft oK23jWsPcIy5m//ebOPv3j0RqErsWWYgnQyzAypbeB6mU1fWUwyMej0l+vJBXUJmM2SB+c arnlmSH+FIZuB8beRwv5iNkYOgAd5DeKbUUu8Tdpm0YTHLPZBAT4O8OAdqJhrrxknGBJab 0YHvpra0ruwP2eOFuD/bQeAoTLzFJEc6RE3Xf5133b9oWs24sB9kS54jD2qjkA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --=_MailMate_43ACE16C-8FBB-4703-A9C0-5E8ED6BC4AE9_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1 May 2022, at 5:13, qroxana wrote: > After git bisecting the panic started since this commit. > > commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113 > > Author: Kristof Provost < > kp@FreeBSD.org >> > > Date: Mon Feb 14 20:09:54 2022 +0100 > > vlan: allow net.link.vlan.mtag_pcp to be set per vnet > > The primary reason for this change is to facilitate testing. > > MFC after: 1 week > > sys/net/if_ethersubr.c | 9 +++++---- > > sys/net/if_vlan.c | 5 +++-- > > 2 files changed, 8 insertions(+), 6 deletions(-) > > The armv7 board boots from a NFS root, > > it can boot without any problem if PF is disabled. > > Any helps? > > add host ::1: gateway lo0 fib 0: route already in table > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > Enabling pf. > Kernel page fault with the following non-sleepable locks held: > shared rm pf rulesets (pf rulesets) r = 0 (0xe3099430) locked @ > /usr/src/sys/netpfil/pf/pf.c:6493 > exclusive rw tcpinp (tcpinp) r = 0 (0xdb748d88) locked @ > /usr/src/sys/netinet/tcp_usrreq.c:1008 > stack backtrace: > #0 0xc0355cac at witness_debugger+0x7c > #1 0xc0356ef0 at witness_warn+0x3fc > #2 0xc05ec048 at abort_handler+0x1d8 > #3 0xc05cb5ac at exception_exit+0 > #4 0xe3083c10 at pf_syncookie_validate+0x60 > #5 0xe30496a8 at pf_test+0x518 > #6 0xe306d768 at pf_check_out+0x30 > #7 0xc0415b44 at pfil_run_hooks+0xbc > #8 0xc0445cfc at ip_output+0xce8 > #9 0xc045bc9c at tcp_default_output+0x20ac > #10 0xc0471eb4 at tcp_usr_send+0x1ac > #11 0xc0389464 at sosend_generic+0x490 > #12 0xc0389790 at sosend+0x64 > #13 0xc0502888 at clnt_vc_call+0x560 > #14 0xc05009d8 at clnt_reconnect_call+0x170 > #15 0xc01e7b14 at newnfs_request+0xb20 > #16 0xc0230218 at nfscl_request+0x60 > #17 0xc020d9bc at nfsrpc_getattr+0xb0 > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xdf1f1c90 > FSR=00000001, FAR=d7840264, spsr=40000013 > r0 =6a228eda, r1 =dac0d785, r2 =d7840264, r3 =db5527c0 > r4 =df1f1e00, r5 =dac0d75f, r6 =00000018, r7 =d9422c00 > r8 =c093e5e4, r9 =00000001, r10=df1f1f5c, r11=df1f1d38 > r12=e3098dd0, ssp=df1f1d20, slr=e3083bdc, pc =e3083c10 > > The commit you point at is entirely unrelated to the code where the panic occurred, so I’m pretty sure something went wrong in your bisect. The backtrace would suggest the issue occurs in the pf_syncookie_validate() function, and likely in the line `if (atomic_load_64(&V_pf_status.syncookies_inflight[cookie.flags.oddeven]) == 0)` The obvious way for that to panic would be to call it without the curvnet context set, but pf_test() uses it earlier, so that’s going to be fine. Given that this is unique to armv7 I’d recommend talking to the armv7 maintainer about 64 bit atomic operations. You can probably avoid the atomic load with this patch (and not enabling syncookie support): diff --git a/sys/netpfil/pf/pf_syncookies.c b/sys/netpfil/pf/pf_syncookies.c index 5230502be30c..c86d469d3cef 100644 --- a/sys/netpfil/pf/pf_syncookies.c +++ b/sys/netpfil/pf/pf_syncookies.c @@ -313,6 +313,9 @@ pf_syncookie_validate(struct pf_pdesc *pd) ack = ntohl(pd->hdr.tcp.th_ack) - 1; cookie.cookie = (ack & 0xff) ^ (ack >> 24); + if (V_pf_status.syncookies_mode == PF_SYNCOOKIES_NEVER) + return (0); + /* we don't know oddeven before setting the cookie (union) */ if (atomic_load_64(&V_pf_status.syncookies_inflight[cookie.flags.oddeven]) == 0) That shouldn’t be required though. Br, Kristof --=_MailMate_43ACE16C-8FBB-4703-A9C0-5E8ED6BC4AE9_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 1 May 2022, at 5:13, qroxana wrote:

After git bisecting the panic start= ed since this commit.

commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113

Author: Kristof Provost <
kp@FreeBSD.org

Date: Mon Feb 14 20:09:54 2022 +0100

vlan: allow net.link.vlan.mtag_pcp to be set per vnet

=

The primary reason for this change is to facilitate testi= ng.

MFC after: 1 week

sys/net/if_ethersubr.c | 9 +++++----

sys/net/if_vlan.c | 5 +++--

2 files changed, 8 insertions(+), 6 deletions(-)

The armv7 board boots from a NFS root,

it can boot without any problem if PF is disabled.

Any helps?

add host ::1: gateway lo0 fib 0: route already in table
add net fe80::: gateway ::1
add net ff02::: gateway ::1
add net ::ffff:0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
Enabling pf.
Kernel page fault with the following non-sleepable locks held:
shared rm pf rulesets (pf rulesets) r =3D 0 (0xe3099430) locked @ /usr/sr= c/sys/netpfil/pf/pf.c:6493
exclusive rw tcpinp (tcpinp) r =3D 0 (0xdb748d88) locked @ /usr/src/sys/n= etinet/tcp_usrreq.c:1008
stack backtrace:
#0 0xc0355cac at witness_debugger+0x7c
#1 0xc0356ef0 at witness_warn+0x3fc
#2 0xc05ec048 at abort_handler+0x1d8
#3 0xc05cb5ac at exception_exit+0
#4 0xe3083c10 at pf_syncookie_validate+0x60
#5 0xe30496a8 at pf_test+0x518
#6 0xe306d768 at pf_check_out+0x30
#7 0xc0415b44 at pfil_run_hooks+0xbc
#8 0xc0445cfc at ip_output+0xce8
#9 0xc045bc9c at tcp_default_output+0x20ac
#10 0xc0471eb4 at tcp_usr_send+0x1ac
#11 0xc0389464 at sosend_generic+0x490
#12 0xc0389790 at sosend+0x64
#13 0xc0502888 at clnt_vc_call+0x560
#14 0xc05009d8 at clnt_reconnect_call+0x170
#15 0xc01e7b14 at newnfs_request+0xb20
#16 0xc0230218 at nfscl_request+0x60
#17 0xc020d9bc at nfsrpc_getattr+0xb0
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xdf1f1c90
FSR=3D00000001, FAR=3Dd7840264, spsr=3D40000013
r0 =3D6a228eda, r1 =3Ddac0d785, r2 =3Dd7840264, r3 =3Ddb5527c0
r4 =3Ddf1f1e00, r5 =3Ddac0d75f, r6 =3D00000018, r7 =3Dd9422c00
r8 =3Dc093e5e4, r9 =3D00000001, r10=3Ddf1f1f5c, r11=3Ddf1f1d38
r12=3De3098dd0, ssp=3Ddf1f1d20, slr=3De3083bdc, pc =3De3083c10


The commit you point at is entirely unrelated to the code= where the panic occurred, so I=E2=80=99m pretty sure something went wron= g in your bisect.

The backtrace would suggest the issue occurs in the pf_s= yncookie_validate() function, and likely in the line if (atomic_loa= d_64(&V_pf_status.syncookies_inflight[cookie.flags.oddeven]) =3D=3D 0= )

The obvious way for that to panic would be to call it wit= hout the curvnet context set, but pf_test() uses it earlier, so that=E2=80= =99s going to be fine.

Given that this is unique to armv7 I=E2=80=99d recommend = talking to the armv7 maintainer about 64 bit atomic operations.

You can probably avoid the atomic load with this patch (a= nd not enabling syncookie support):

diff --git a/sys/netpfil/pf/pf_syncookies.c b/sys/netpfil/=
pf/pf_syncookies.c
index 5230502be30c..c86d469d3cef 100644
--- a/sys/netpfil/pf/pf_syncookies.c
+++ b/sys/netpfil/pf/pf_syncookies.c
@@ -313,6 +313,9 @@ pf_syncookie_validate(struct pf_pdesc *pd)
        ack =3D ntohl(pd->hdr.tcp.th_ack) - 1;
        cookie.cookie =3D (ack & 0xff) ^ (ack >> 24);

+       if (V_pf_status.syncookies_mode =3D=3D PF_SYNCOOKIES_NEVER)
+               return (0);
+
        /* we don't know oddeven before setting the cookie (union) */
         if (atomic_load_64(&V_pf_status.syncookies_inflight[cookie.f=
lags.oddeven])
            =3D=3D 0)

That shouldn=E2=80=99t be required though.

Br,
Kristof

--=_MailMate_43ACE16C-8FBB-4703-A9C0-5E8ED6BC4AE9_=-- From nobody Mon May 2 16:32:25 2022 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 9D8261AC28A1 for ; Mon, 2 May 2022 16:32:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsTCd62rnz4qDt for ; Mon, 2 May 2022 16:32:45 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-wr1-f50.google.com with SMTP id k2so20225690wrd.5 for ; Mon, 02 May 2022 09:32:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jnI+eLMDu6XONKsA6CBn9aogiaJOgjXCjVf7QDIUTzc=; b=okQXGcR9DJEQBwX930LdvdP36shoJAbo2ryPpngyDbjbB+YbmmlyuMs+Qjjktraryb a6dZFrJd0ZZovC4z9jPL4spa1DSz6ryklXGSL8thtiKI4E1jvfcj5TMV8bujX/Hddmpr 5Huz7i4hWy+xpD8CRXxeRfFcJiwShL7VxgEvJ2A/TqpgjV3+SStOZRqp3audEH2YDGj1 IPMFPrnXKBzEkIkIIJB8o8Zpvc2ChACw0btrE47oBC2VbxuiPxSt/cz/YGCEOXZ2IF6y sX5HunGHTxbkXqJMJJp5+7logYZBVUIcJc40XqMFn5f5mDnWI4RKhjM7tb+gxJSls5y+ n3RA== X-Gm-Message-State: AOAM5313cvXmdQ2b1HzpPUsSHDrAheYCEHlWU2fsQn0SMIUDmExA3Dob 3QbrWqnyd7L0QmkoDbYejf0jFO3EMON8P4AHSXzmi73s X-Google-Smtp-Source: ABdhPJx67/5eSPSRgLw45YsxblxqdpeM4hP5A82Fb9xwf/Q6g1uLeSlXghI3P/jOs73/stqJtmqIWwKiAgtzgXr71JA= X-Received: by 2002:a5d:64ca:0:b0:20c:64e3:949e with SMTP id f10-20020a5d64ca000000b0020c64e3949emr3726613wri.584.1651509159447; Mon, 02 May 2022 09:32:39 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Mon, 2 May 2022 12:32:25 -0400 Message-ID: Subject: Re: Profiled libraries on freebsd-current To: Steve Kargl Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KsTCd62rnz4qDt X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.82 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.86)[-0.863]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.221.50:from]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.221.50:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Sun, 1 May 2022 at 11:54, Steve Kargl wrote: > > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h > index 594487829b5..1e8ab2e1827 100644 > --- a/gcc/config/freebsd-spec.h > +++ b/gcc/config/freebsd-spec.h > @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see > (similar to the default, except no -lg, and no -p). */ > > #ifdef FBSD_NO_THREADS I wonder if we can simplify things now, and remove this `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC targets I looked at. From nobody Mon May 2 17:37:00 2022 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 A3F121AAC035 for ; Mon, 2 May 2022 17:37:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsVdw3gJpz3Nrf; Mon, 2 May 2022 17:37:08 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 242Hb08p001783 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 2 May 2022 10:37:00 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 242Hb0PK001782; Mon, 2 May 2022 10:37:00 -0700 (PDT) (envelope-from sgk) Date: Mon, 2 May 2022 10:37:00 -0700 From: Steve Kargl To: Ed Maste Cc: FreeBSD Current Subject: Re: Profiled libraries on freebsd-current Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KsVdw3gJpz3Nrf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-2.98 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.979]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote: > On Sun, 1 May 2022 at 11:54, Steve Kargl > wrote: > > > > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h > > index 594487829b5..1e8ab2e1827 100644 > > --- a/gcc/config/freebsd-spec.h > > +++ b/gcc/config/freebsd-spec.h > > @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see > > (similar to the default, except no -lg, and no -p). */ > > > > #ifdef FBSD_NO_THREADS > > I wonder if we can simplify things now, and remove this > `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC > targets I looked at. That I don't know. FBSD_NO_THREADS is defined in freebsd-nthr.h. In fact, it's the only thing in that header (except copyright broilerplate). freebsd-nthr.h only appears in config.gcc and seems to only get added to the build if someone runs configure with --enable-threads=no. Looking at my last config.log for gcc trunk, I see "Thread model: posix", which appears to be the default case or if someone does --enable-threads=yes or --enable-threads=posix. So, I suppose it comes down to two questions: (1) is libpthread.* available on all supported targets and versions? (2) does anyone build gcc without threads support? -- Steve From nobody Mon May 2 18:24:17 2022 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 8692B1AB895B; Mon, 2 May 2022 18:24:28 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsWhW36J3z3nj3; Mon, 2 May 2022 18:24:27 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [IPV6:2001:470:71:d47:c0c4:7b61:cb80:fb4f] ([IPv6:2001:470:71:d47:c0c4:7b61:cb80:fb4f]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 242IOHJb088391 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 2 May 2022 20:24:17 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1651515858; bh=eVYGuQjYpl+dMQKz54RSlhtJMiVJmn4HHNyTRr0EaoI=; h=Date:From:To:Subject; b=A0v27+Ci0K2u/kI+zNvQS4b6JYcwLfvVmejjdZ3Qnr63oKPLx62wZ0VPDLkzimByl kGqgwC2U2T7kMB3SNDEeXv1EISM39ameBCCsrZpRDx9KQEl1wK41IsieDEFQg+uhO1 9PbVp/b46tC3n14O1n7KeEKtQ7ngkDJ7iKnA1WwxeqF+cf++7JieH8PYX65igJy/Ml OLZrdwAL/XliBeanPQPzINNTAYYHbAHpAZwyQItWPfTjA/i8y3TNrSKh59ly+fAYAt rSSmBdjXzMW3/8iZngAMLcxVxGrckMIx/Fikq4uL7bWp/x84PnpAsnZBRdteT0+DLC xV/sfKi0ZbCHw== Content-Type: multipart/alternative; boundary="------------NihIw8oFMGKyRecHWZphbckN" Message-ID: <4ba8458e-db94-6f74-a8e0-ba71692ea72a@plan-b.pwste.edu.pl> Date: Mon, 2 May 2022 20:24:17 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 From: Marek Zarychta Content-Language: en-US To: freeBSD Current , freebsd-hackers@freebsd.org Subject: discussion on future removal of empty $FreeBSD$ tags X-Rspamd-Queue-Id: 4KsWhW36J3z3nj3 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=A0v27+Ci; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SUBJECT_HAS_CURRENCY(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; URI_COUNT_ODD(1.00)[3]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------NihIw8oFMGKyRecHWZphbckN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear subscribers, after one of the recent commits[1] surprisingly we got rid of $FreeBSD$ from among others, two configuration files: /etc/ssh/ssh_config and /etc/ssh/sshd_config. I was told these IDs are going to be deprecated in the whole source tree when 12.x branch reaches EoL, what is surprising news, at least for me. While indeed empty $FreeBSD$ tags after the transition to git became useless, leaving them in config files, still might be handy. Please let me explain why. After the transition to git, a lot of people complained about breakage in mergemaster(8). Finally, they were told that this tool is outdated, cannot do 3-way merge, has no maintainer, etc. so it's going to be deprecated soon. Then appropriate notice was added, the handbook got updated, so seemingly everyone was fine with this depreciation. I am not going to bring any serious arguments against etcupdate(8), but when providing support on IRC, a few cases of foot shooting with this tool had been reported to me and the last one happened this year IIRC. Moreover some people, including me, just like and are used to old sdiff(1)-way work of mergemaster(8).  So soon after the transition to git to overcome this deficiency I wrote for myself a git primer helping with quick creation of local repository including $FreeBSD$ recreation for mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this primer[2] for users here, maybe someone (noncommitter) will benefit from this (if it will not get burned with fire here earlier). Please don't get me wrong, I am not fighting with etcupdate(8) which works almost flawlessly in unison with freebsd-update(8), but people who follow STABLE/CURRENT really do appreciate the existence of mergemaster(8) and still use it behind the scenes, including probably members of core@ team. I am only asking for leaving these empty $FreeBSD$ IDs in config files. This will of course add some burden to committers' work but might be beneficial in the future. I am neither committer, nor contributor, but the voice from the userbase. Best regards, Marek Zarychta [1] https://cgit.freebsd.org/src/commit/?id=835ee05f [2] ######################################################## # # FreeBSD Git src with worktrees and clean/smudge filters # for mergemaster(8) # ######################################################## # Preparation of the tree zfs create zroot/usr/src_head zfs create zroot/usr/src_13 ######################################################## # Making src of stable/13 mountable in /usr/src echo "/usr/src_13 /usr/src nullfs rw,late 0 0" >> /etc/fstab mount -al ######################################################## # Cloning the repository cd /usr/src_head git clonehttps://git.freebsd.org/src.git/ ./ ######################################################## # Adding filters # Filters require lang/ruby and lang/perl installed git config filter.freebsdid.smudge expand_freebsd git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"' ######################################################## # Limiting filters scope # In /usr/src_head create file .git/info/attributes with # following contents (at least): ------------cut------------ cat > .git/info/attributes << EOF etc/* filter=freebsdid etc/*/* filter=freebsdid libexec/rc/* filter=freebsdid libexec/rc/rc.d/* filter=freebsdid *.conf filter=freebsdid dot.??* filter=freebsdid lib/libc/gen/shells filter=freebsdid lib/libc/net/hosts filter=freebsdid lib/libpam/pam.d/* filter=freebsdid lib/libwrap/hosts.allow filter=freebsdid usr.sbin/services_mkdb/services filter=freebsdid usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=freebsdid usr.sbin/periodic/etc/* filter=freebsdid usr.sbin/cron/cron/crontab filter=freebsdid crypto/openssh/ssh*_config filter=freebsdid EOF ------------cut------------ ######################################################## # Smudge filter setup # Create file /usr/local/bin/expand_freebsd with following # contents and make it executable. ------------cut------------ #!/usr/bin/env ruby data = STDIN.read last_info = `git log --pretty=format:"%h %ae %ad" -1` puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s + '$') ------------cut------------ chmod a+x /usr/local/bin/expand_freebsd ######################################################## # Adding worktrees # Add worktree for stable/13, filters will be applied git worktree add /usr/src_13 stable/13 # To have IDs in main (HEAD) # do checkout of filtered files again cd /usr/src_head rm etc/master.passwd etc/group rm libexec/rc/rc.d/* git checkout -f -- . ######################################################## # To find more files with $FreeBSD tags which might # be added to .git/info/attributes file issue command: find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD' -- Marek Zarychta --------------NihIw8oFMGKyRecHWZphbckN Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Dear subscribers,

after one of the recent commits[1] surprisingly we got rid of $FreeBSD$ from among others, two configuration files: /etc/ssh/ssh_config and /etc/ssh/sshd_config. I was told these IDs are going to be deprecated in the whole source tree when 12.x branch reaches EoL, what is surprising news, at least for me. While indeed empty $FreeBSD$ tags after the transition to git became useless, leaving them in config files, still might be handy. Please let me explain why.

After the transition to git, a lot of people complained about breakage in mergemaster(8). Finally, they were told that this tool is outdated, cannot do 3-way merge, has no maintainer, etc. so it's going to be deprecated soon. Then appropriate notice was added, the handbook got updated, so seemingly everyone was fine with this depreciation. I am not going to bring any serious arguments against etcupdate(8), but when providing support on IRC, a few cases of foot shooting with this tool had been reported to me and the last one happened this year IIRC. Moreover some people, including me, just like and are used to old sdiff(1)-way work of mergemaster(8).  So soon after the transition to git to overcome this deficiency I wrote for myself a git primer helping with quick creation of local repository including $FreeBSD$ recreation for mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this primer[2] for users here, maybe someone (noncommitter) will benefit from this (if it will not get burned with fire here earlier).

Please don't get me wrong, I am not fighting with etcupdate(8) which works almost flawlessly in unison with freebsd-update(8), but people who follow STABLE/CURRENT really do appreciate the existence of mergemaster(8) and still use it behind the scenes, including probably members of core@ team. I am only asking for leaving these empty $FreeBSD$ IDs in config files. This will of course add some burden to committers' work but might be beneficial in the future. I am neither committer, nor contributor, but the voice from the userbase.

Best regards,

Marek Zarychta

[1] https://cgit.freebsd.org/src/commit/?id=835ee05f

[2]

########################################################
#
# FreeBSD Git src with worktrees and clean/smudge filters 
# for mergemaster(8)
#
########################################################
# Preparation of the tree

zfs create zroot/usr/src_head
zfs create zroot/usr/src_13

########################################################
# Making src of stable/13 mountable in /usr/src
 
echo "/usr/src_13 	/usr/src 		nullfs rw,late 0 0" >> /etc/fstab
mount -al

########################################################
# Cloning the repository

cd /usr/src_head
git clone https://git.freebsd.org/src.git/ ./

########################################################
# Adding filters
# Filters require lang/ruby and lang/perl installed

git config filter.freebsdid.smudge expand_freebsd
git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"'

########################################################
# Limiting filters scope
# In /usr/src_head create file .git/info/attributes with 
# following contents (at least):

------------cut------------
cat > .git/info/attributes << EOF
etc/* 	                filter=freebsdid
etc/*/*                 filter=freebsdid
libexec/rc/*            filter=freebsdid
libexec/rc/rc.d/*       filter=freebsdid
*.conf                  filter=freebsdid
dot.??*                 filter=freebsdid
lib/libc/gen/shells     filter=freebsdid
lib/libc/net/hosts      filter=freebsdid
lib/libpam/pam.d/*      filter=freebsdid
lib/libwrap/hosts.allow filter=freebsdid
usr.sbin/services_mkdb/services filter=freebsdid
usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=freebsdid
usr.sbin/periodic/etc/* filter=freebsdid
usr.sbin/cron/cron/crontab filter=freebsdid
crypto/openssh/ssh*_config filter=freebsdid
EOF
------------cut------------

########################################################
# Smudge filter setup
# Create file /usr/local/bin/expand_freebsd with following 
# contents and make it executable.

------------cut------------
#!/usr/bin/env ruby
data = STDIN.read
last_info = `git log --pretty=format:"%h %ae %ad" -1`
puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s + '$')
------------cut------------

chmod a+x /usr/local/bin/expand_freebsd 

########################################################
# Adding worktrees
# Add worktree for stable/13, filters will be applied

git worktree add /usr/src_13 stable/13

# To have IDs in main (HEAD) 
# do checkout of filtered files again

cd /usr/src_head
rm etc/master.passwd etc/group 
rm libexec/rc/rc.d/*
git checkout -f -- .

########################################################
# To find more files with $FreeBSD tags which might
# be added to .git/info/attributes file issue command: 

find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD' 

-- 
Marek Zarychta
--------------NihIw8oFMGKyRecHWZphbckN-- From nobody Mon May 2 20:09:30 2022 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 09B6A1AB287F for ; Mon, 2 May 2022 20:09:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsZ1y0LQdz4gB8 for ; Mon, 2 May 2022 20:09:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa30.google.com with SMTP id y27so7082755vkl.8 for ; Mon, 02 May 2022 13:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0czNl5xnHcV3Jnxk26qsimE18Iq0rxQ5O6Wwkcqwybk=; b=A0xOvPFHkkH71ehKCe/4LKG+R9pSE602MSHRuVw6d8vdCu8/WGh57DcVZwcqiiAz8O xbp1XJGJPqpufS712Z91O8/KraB+3K4cLjPiOYZ2PO8S6UJtT77j6NEPzmp1cQn8yF95 ljnizS9NNWlRzyOvoZnC8y2ddP2eqmhi61cJ3LBLcmfeunuaWESD0nTRjaA9zuB3iEyz P8dL0p5r+13Apeb489uAkjOeMe6bN20OMQ1f8qYCBotyIs4AO3th5WSsXIatYC5cbBTp Yt/++DiOVdLDDfrBRkOkRh0SkHBssDbsohZRhx0zpj1Zc9d1vkf/3o2mSNC9IoH50Oq3 fEwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0czNl5xnHcV3Jnxk26qsimE18Iq0rxQ5O6Wwkcqwybk=; b=h6owIwOG+0icq4HDqXxnt60HsweKyedMwpRncGYvxmcG2izDY7VQSE9BnwXrM3rGKo PQry8j/J53bBQskfOgwRIschYZUqHGhhtylj8/2j2qEAUCsKPWm6GRE4mtnYHnpHjnQG MsfmBkfoC6WYm/nSNhayiPK+tTN59xxikEFKw1Ck1bJCJWlwPGaFIWAnfYkr90tMUMLc DBclbdVkaUrkloVulQejU5YM9a6NylTFp13Gq0RLjx9/zMlCs0YyizeiR8rbafIvcEzX MfdHSXprwu8PPrsR71uledKWDbIvVGvmUzCYu463dtZtv2MdBhtTF0gIwrvb9vEff+m5 8HJA== X-Gm-Message-State: AOAM532+8xu15/KK1Iz5oX0u3RoFDHxqeq5Aoijz20FpsenTQBrGRO/q Z9zCOYI/PERuRV+OQFmhZBNn4Xy3RFw2GsTiW5Klj26pSWo= X-Google-Smtp-Source: ABdhPJxy95DeusrKMPmELu9DLI2QtWdFVKSWpo4ikHFIYnuIUBNIN2ihZEKZ9PVty0JHSgrJ0ba628XkqBKfCnNiSiA= X-Received: by 2002:a1f:ce46:0:b0:34e:b018:c8a4 with SMTP id e67-20020a1fce46000000b0034eb018c8a4mr2015055vkg.26.1651522181348; Mon, 02 May 2022 13:09:41 -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: <4ba8458e-db94-6f74-a8e0-ba71692ea72a@plan-b.pwste.edu.pl> In-Reply-To: <4ba8458e-db94-6f74-a8e0-ba71692ea72a@plan-b.pwste.edu.pl> From: Warner Losh Date: Mon, 2 May 2022 14:09:30 -0600 Message-ID: Subject: Re: discussion on future removal of empty $FreeBSD$ tags To: Marek Zarychta Cc: freeBSD Current , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000f552fa05de0cf892" X-Rspamd-Queue-Id: 4KsZ1y0LQdz4gB8 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=A0xOvPFH; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a30) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; SUBJECT_HAS_CURRENCY(1.00)[]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a30:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000f552fa05de0cf892 Content-Type: text/plain; charset="UTF-8" The current plans are to keep $FreeBSD$ in main until stable/12 is out of support. no new files will have it added, unless they are to be merged to stable/12 and are installed / managed by mergemaster. We'll do a coordinated sweep of the tree removing them after stable/12 drops out of support and we'll do similar commits to stable/13 to reduce as much as possible any merge conflicts after that point. stable/13 and newer they are, of course, just noise. mergemaster doesn't require them to be non-empty, but will skip modified files if they match. Though it's been a while since I've used mergemaster... It has no maintainer and only receives emergency fixes when something breaks (and it usually takes a while for the right people to notice). Warner On Mon, May 2, 2022 at 12:25 PM Marek Zarychta < zarychtam@plan-b.pwste.edu.pl> wrote: > Dear subscribers, > > after one of the recent commits[1] surprisingly we got rid of $FreeBSD$ > from among others, two configuration files: /etc/ssh/ssh_config and > /etc/ssh/sshd_config. I was told these IDs are going to be deprecated in > the whole source tree when 12.x branch reaches EoL, what is surprising > news, at least for me. While indeed empty $FreeBSD$ tags after the > transition to git became useless, leaving them in config files, still might > be handy. Please let me explain why. > > After the transition to git, a lot of people complained about breakage in > mergemaster(8). Finally, they were told that this tool is outdated, cannot > do 3-way merge, has no maintainer, etc. so it's going to be deprecated > soon. Then appropriate notice was added, the handbook got updated, so > seemingly everyone was fine with this depreciation. I am not going to bring > any serious arguments against etcupdate(8), but when providing support on > IRC, a few cases of foot shooting with this tool had been reported to me > and the last one happened this year IIRC. Moreover some people, including > me, just like and are used to old sdiff(1)-way work of mergemaster(8). So > soon after the transition to git to overcome this deficiency I wrote for > myself a git primer helping with quick creation of local repository > including $FreeBSD$ recreation for mergemaster(8) relying on empty > $FreeBSD$ tags. I will attach this primer[2] for users here, maybe someone > (noncommitter) will benefit from this (if it will not get burned with fire > here earlier). > > Please don't get me wrong, I am not fighting with etcupdate(8) which works > almost flawlessly in unison with freebsd-update(8), but people who follow > STABLE/CURRENT really do appreciate the existence of mergemaster(8) and > still use it behind the scenes, including probably members of core@ team. > I am only asking for leaving these empty $FreeBSD$ IDs in config files. > This will of course add some burden to committers' work but might be > beneficial in the future. I am neither committer, nor contributor, but the > voice from the userbase. > > Best regards, > > Marek Zarychta > > [1] https://cgit.freebsd.org/src/commit/?id=835ee05f > > [2] > > ######################################################## > # > # FreeBSD Git src with worktrees and clean/smudge filters > # for mergemaster(8) > # > ######################################################## > # Preparation of the tree > > zfs create zroot/usr/src_head > zfs create zroot/usr/src_13 > > ######################################################## > # Making src of stable/13 mountable in /usr/src > > echo "/usr/src_13 /usr/src nullfs rw,late 0 0" >> /etc/fstab > mount -al > > ######################################################## > # Cloning the repository > > cd /usr/src_head > git clone https://git.freebsd.org/src.git/ ./ > > ######################################################## > # Adding filters > # Filters require lang/ruby and lang/perl installed > > git config filter.freebsdid.smudge expand_freebsd > git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"' > > ######################################################## > # Limiting filters scope > # In /usr/src_head create file .git/info/attributes with > # following contents (at least): > > ------------cut------------ > cat > .git/info/attributes << EOF > etc/* filter=freebsdid > etc/*/* filter=freebsdid > libexec/rc/* filter=freebsdid > libexec/rc/rc.d/* filter=freebsdid > *.conf filter=freebsdid > dot.??* filter=freebsdid > lib/libc/gen/shells filter=freebsdid > lib/libc/net/hosts filter=freebsdid > lib/libpam/pam.d/* filter=freebsdid > lib/libwrap/hosts.allow filter=freebsdid > usr.sbin/services_mkdb/services filter=freebsdid > usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=freebsdid > usr.sbin/periodic/etc/* filter=freebsdid > usr.sbin/cron/cron/crontab filter=freebsdid > crypto/openssh/ssh*_config filter=freebsdid > EOF > ------------cut------------ > > ######################################################## > # Smudge filter setup > # Create file /usr/local/bin/expand_freebsd with following > # contents and make it executable. > > ------------cut------------ > #!/usr/bin/env ruby > data = STDIN.read > last_info = `git log --pretty=format:"%h %ae %ad" -1` > puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s + '$') > ------------cut------------ > > chmod a+x /usr/local/bin/expand_freebsd > > ######################################################## > # Adding worktrees > # Add worktree for stable/13, filters will be applied > > git worktree add /usr/src_13 stable/13 > > # To have IDs in main (HEAD) > # do checkout of filtered files again > > cd /usr/src_head > rm etc/master.passwd etc/group > rm libexec/rc/rc.d/* > git checkout -f -- . > > ######################################################## > # To find more files with $FreeBSD tags which might > # be added to .git/info/attributes file issue command: > > find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD' > > -- > Marek Zarychta > > --000000000000f552fa05de0cf892 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The current plans are to keep $FreeBSD$ in main until stab= le/12 is out of support. no new files will have it added, unless they are t= o be merged to stable/12 and are installed / managed by mergemaster.
We'll do a coordinated sweep of the tree removing them aft= er stable/12 drops out of support and we'll do similar commits to stabl= e/13 to reduce as much as possible any merge conflicts after that point.

stable/13 and newer they are, of course, just noise.= mergemaster doesn't require them to be non-empty, but will skip modifi= ed files if they match. Though it's been a while since I've used me= rgemaster... It has no maintainer and only receives emergency fixes when so= mething breaks (and it usually takes a while for the right people to notice= ).

Warner

On Mon, May 2, 2022 at 12:25 PM Mar= ek Zarychta <zarychtam@= plan-b.pwste.edu.pl> wrote:
=20 =20 =20

Dear subscribers,

after one of the recent commits[1] surprisingly we got rid of $FreeBSD$ from among others, two configuration files: /etc/ssh/ssh_config and /etc/ssh/sshd_config. I was told these IDs are going to be deprecated in the whole source tree when 12.x branch reaches EoL, what is surprising news, at least for me. While indeed empty $FreeBSD$ tags after the transition to git became useless, leaving them in config files, still might be handy. Please let me explain why.

After the transition to git, a lot of people complained about breakage in mergemaster(8). Finally, they were told that this tool is outdated, cannot do 3-way merge, has no maintainer, etc. so it's going to be deprecated soon. Then appropriate notice was added, the handbook got updated, so seemingly everyone was fine with this depreciation. I am not going to bring any serious arguments against etcupdate(8), but when providing support on IRC, a few cases of foot shooting with this tool had been reported to me and the last one happened this year IIRC. Moreover some people, including me, just like and are used to old sdiff(1)-way work of mergemaster(8).=C2=A0 So soon after the transition to git to overcome this deficiency I wrote for myself a git primer helping with quick creation of local repository including $FreeBSD$ recreation for mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this primer[2] for users here, maybe someone (noncommitter) will benefit from this (if it will not get burned with fire here earlier).

Please don't get me wrong, I am not fighting with etcupdate(8) which works almost flawlessly in unison with freebsd-update(8), but people who follow STABLE/CURRENT really do appreciate the existence of mergemaster(8) and still use it behind the scenes, including probably members of core@ team. I am only asking for leaving these empty $FreeBSD$ IDs in config files. This will of course add some burden to committers' work but might be beneficia= l in the future. I am neither committer, nor contributor, but the voice from the userbase.

Best regards,

Marek Zarychta

[1] https://cgit.freebsd.org/src/commit/?id=3D835ee05f

[2]

########################################################
#
# FreeBSD Git src with worktrees and clean/smudge filters=20
# for mergemaster(8)
#
########################################################
# Preparation of the tree

zfs create zroot/usr/src_head
zfs create zroot/usr/src_13

########################################################
# Making src of stable/13 mountable in /usr/src
=20
echo "/usr/src_13 	/usr/src 		nullfs rw,late 0 0" >> /etc/f=
stab
mount -al

########################################################
# Cloning the repository

cd /usr/src_head
git clone ht=
tps://git.freebsd.org/src.git/ ./

########################################################
# Adding filters
# Filters require lang/ruby and lang/perl installed

git config filter.freebsdid.smudge expand_freebsd
git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*=
\\\$/\\\$FreeBSD\\\$/"'

########################################################
# Limiting filters scope
# In /usr/src_head create file .git/info/attributes with=20
# following contents (at least):

------------cut------------
cat > .git/info/attributes << EOF
etc/* 	                filter=3Dfreebsdid
etc/*/*                 filter=3Dfreebsdid
libexec/rc/*            filter=3Dfreebsdid
libexec/rc/rc.d/*       filter=3Dfreebsdid
*.conf                  filter=3Dfreebsdid
dot.??*                 filter=3Dfreebsdid
lib/libc/gen/shells     filter=3Dfreebsdid
lib/libc/net/hosts      filter=3Dfreebsdid
lib/libpam/pam.d/*      filter=3Dfreebsdid
lib/libwrap/hosts.allow filter=3Dfreebsdid
usr.sbin/services_mkdb/services filter=3Dfreebsdid
usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=3Dfreebsdid
usr.sbin/periodic/etc/* filter=3Dfreebsdid
usr.sbin/cron/cron/crontab filter=3Dfreebsdid
crypto/openssh/ssh*_config filter=3Dfreebsdid
EOF
------------cut------------

########################################################
# Smudge filter setup
# Create file /usr/local/bin/expand_freebsd with following=20
# contents and make it executable.

------------cut------------
#!/usr/bin/env ruby
data =3D STDIN.read
last_info =3D `git log --pretty=3Dformat:"%h %ae %ad" -1`
puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s +=
 '$')
------------cut------------

chmod a+x /usr/local/bin/expand_freebsd=20

########################################################
# Adding worktrees
# Add worktree for stable/13, filters will be applied

git worktree add /usr/src_13 stable/13

# To have IDs in main (HEAD)=20
# do checkout of filtered files again

cd /usr/src_head
rm etc/master.passwd etc/group=20
rm libexec/rc/rc.d/*
git checkout -f -- .

########################################################
# To find more files with $FreeBSD tags which might
# be added to .git/info/attributes file issue command:=20

find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD'=
; 

--=20
Marek Zarychta
--000000000000f552fa05de0cf892-- From nobody Mon May 2 20:31:35 2022 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 9B6561AB95E2; Mon, 2 May 2022 20:31:43 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsZWL05WTz4m5Z; Mon, 2 May 2022 20:31:41 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [IPV6:2001:470:71:d47:c0c4:7b61:cb80:fb4f] ([IPv6:2001:470:71:d47:c0c4:7b61:cb80:fb4f]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 242KVZVq088798 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 2 May 2022 22:31:36 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1651523496; bh=mSZsQvdN+0bT/X0FKGoubjS3lZAWFTB9nxdkLze1B+o=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=Ny3nwP5deR0xudSnE2tItmtulN8H7dKoSWzNxId9dNzRQ7kTCpzWhSC9E9aBQiw58 St40Z+JPFiYcvudqGhkaCzIzhiVnW3swXye+fwUzv4TEysR7kuKy6Igl7sO1x42zrS aF+C0llacYc2xnQSxWYZtb1PLm4+SzYDu0P9PRrYWiw64AVXkGp2t9zR07VCDMn4T4 T4KR0m1U5pfkjvi9257hshcjUvKzqBthoJuC5JDRQ3yVFPfmdaCbPyuaPSnKCA2qrZ gF/z40ZK4kbWwmKrNfw7jidXnb4+PzZd7wsQ24051sJKH+DiZYERCitv7T/Z0KtjLH 8AC5pg47k9paQ== Content-Type: multipart/alternative; boundary="------------AmnHHBLpn03nhE2I6GGre0ZE" Message-ID: <8fc7dc93-4fcb-832c-d950-05c85dcde893@plan-b.pwste.edu.pl> Date: Mon, 2 May 2022 22:31:35 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: discussion on future removal of empty $FreeBSD$ tags Content-Language: en-US To: Warner Losh Cc: freeBSD Current , FreeBSD Hackers References: <4ba8458e-db94-6f74-a8e0-ba71692ea72a@plan-b.pwste.edu.pl> From: Marek Zarychta In-Reply-To: X-Rspamd-Queue-Id: 4KsZWL05WTz4m5Z X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=Ny3nwP5d; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [1.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.28)[0.282]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SUBJECT_HAS_CURRENCY(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------AmnHHBLpn03nhE2I6GGre0ZE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit W dniu 2.05.2022 o 22:09, Warner Losh pisze: > The current plans are to keep $FreeBSD$ in main until stable/12 is out > of support. no new files will have it added, unless they are to be > merged to stable/12 and are installed / managed by mergemaster. > > We'll do a coordinated sweep of the tree removing them after stable/12 > drops out of support and we'll do similar commits to stable/13 to > reduce as much as possible any merge conflicts after that point. > > stable/13 and newer they are, of course, just noise. mergemaster > doesn't require them to be non-empty, but will skip modified files if > they match. Though it's been a while since I've used mergemaster... It > has no maintainer and only receives emergency fixes when something > breaks (and it usually takes a while for the right people to notice). > > Warner Thank you for the reply and for revealing your official plans regarding $FreeBSD$ tags. Marek Zarychta > > On Mon, May 2, 2022 at 12:25 PM Marek Zarychta > wrote: > > Dear subscribers, > > after one of the recent commits[1] surprisingly we got rid of > $FreeBSD$ from among others, two configuration files: > /etc/ssh/ssh_config and /etc/ssh/sshd_config. I was told these IDs > are going to be deprecated in the whole source tree when 12.x > branch reaches EoL, what is surprising news, at least for me. > While indeed empty $FreeBSD$ tags after the transition to git > became useless, leaving them in config files, still might be > handy. Please let me explain why. > > After the transition to git, a lot of people complained about > breakage in mergemaster(8). Finally, they were told that this tool > is outdated, cannot do 3-way merge, has no maintainer, etc. so > it's going to be deprecated soon. Then appropriate notice was > added, the handbook got updated, so seemingly everyone was fine > with this depreciation. I am not going to bring any serious > arguments against etcupdate(8), but when providing support on IRC, > a few cases of foot shooting with this tool had been reported to > me and the last one happened this year IIRC. Moreover some people, > including me, just like and are used to old sdiff(1)-way work of > mergemaster(8).  So soon after the transition to git to overcome > this deficiency I wrote for myself a git primer helping with quick > creation of local repository including $FreeBSD$ recreation for > mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this > primer[2] for users here, maybe someone (noncommitter) will > benefit from this (if it will not get burned with fire here earlier). > > Please don't get me wrong, I am not fighting with etcupdate(8) > which works almost flawlessly in unison with freebsd-update(8), > but people who follow STABLE/CURRENT really do appreciate the > existence of mergemaster(8) and still use it behind the scenes, > including probably members of core@ team. I am only asking for > leaving these empty $FreeBSD$ IDs in config files. This will of > course add some burden to committers' work but might be beneficial > in the future. I am neither committer, nor contributor, but the > voice from the userbase. > > Best regards, > > Marek Zarychta > > [1] https://cgit.freebsd.org/src/commit/?id=835ee05f > > [2] > > ######################################################## > # > # FreeBSD Git src with worktrees and clean/smudge filters > # for mergemaster(8) > # > ######################################################## > # Preparation of the tree > > zfs create zroot/usr/src_head > zfs create zroot/usr/src_13 > > ######################################################## > # Making src of stable/13 mountable in /usr/src > > echo "/usr/src_13 /usr/src nullfs rw,late 0 0" >> /etc/fstab > mount -al > > ######################################################## > # Cloning the repository > > cd /usr/src_head > git clonehttps://git.freebsd.org/src.git/ ./ > > ######################################################## > # Adding filters > # Filters require lang/ruby and lang/perl installed > > git config filter.freebsdid.smudge expand_freebsd > git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"' > > ######################################################## > # Limiting filters scope > # In /usr/src_head create file .git/info/attributes with > # following contents (at least): > > ------------cut------------ > cat > .git/info/attributes << EOF > etc/* filter=freebsdid > etc/*/* filter=freebsdid > libexec/rc/* filter=freebsdid > libexec/rc/rc.d/* filter=freebsdid > *.conf filter=freebsdid > dot.??* filter=freebsdid > lib/libc/gen/shells filter=freebsdid > lib/libc/net/hosts filter=freebsdid > lib/libpam/pam.d/* filter=freebsdid > lib/libwrap/hosts.allow filter=freebsdid > usr.sbin/services_mkdb/services filter=freebsdid > usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=freebsdid > usr.sbin/periodic/etc/* filter=freebsdid > usr.sbin/cron/cron/crontab filter=freebsdid > crypto/openssh/ssh*_config filter=freebsdid > EOF > ------------cut------------ > > ######################################################## > # Smudge filter setup > # Create file /usr/local/bin/expand_freebsd with following > # contents and make it executable. > > ------------cut------------ > #!/usr/bin/env ruby > data = STDIN.read > last_info = `git log --pretty=format:"%h %ae %ad" -1` > puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s + '$') > ------------cut------------ > > chmod a+x /usr/local/bin/expand_freebsd > > ######################################################## > # Adding worktrees > # Add worktree for stable/13, filters will be applied > > git worktree add /usr/src_13 stable/13 > > # To have IDs in main (HEAD) > # do checkout of filtered files again > > cd /usr/src_head > rm etc/master.passwd etc/group > rm libexec/rc/rc.d/* > git checkout -f -- . > > ######################################################## > # To find more files with $FreeBSD tags which might > # be added to .git/info/attributes file issue command: > > find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD' > > -- > Marek Zarychta > --------------AmnHHBLpn03nhE2I6GGre0ZE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
W dniu 2.05.2022 o 22:09, Warner Losh pisze:
The current plans are to keep $FreeBSD$ in main until stable/12 is out of support. no new files will have it added, unless they are to be merged to stable/12 and are installed / managed by mergemaster.

We'll do a coordinated sweep of the tree removing them after stable/12 drops out of support and we'll do similar commits to stable/13 to reduce as much as possible any merge conflicts after that point.

stable/13 and newer they are, of course, just noise. mergemaster doesn't require them to be non-empty, but will skip modified files if they match. Though it's been a while since I've used mergemaster... It has no maintainer and only receives emergency fixes when something breaks (and it usually takes a while for the right people to notice).

Warner

Thank you for the reply and for revealing your official plans regarding $FreeBSD$ tags.

Marek Zarychta


On Mon, May 2, 2022 at 12:25 PM Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:

Dear subscribers,

after one of the recent commits[1] surprisingly we got rid of $FreeBSD$ from among others, two configuration files: /etc/ssh/ssh_config and /etc/ssh/sshd_config. I was told these IDs are going to be deprecated in the whole source tree when 12.x branch reaches EoL, what is surprising news, at least for me. While indeed empty $FreeBSD$ tags after the transition to git became useless, leaving them in config files, still might be handy. Please let me explain why.

After the transition to git, a lot of people complained about breakage in mergemaster(8). Finally, they were told that this tool is outdated, cannot do 3-way merge, has no maintainer, etc. so it's going to be deprecated soon. Then appropriate notice was added, the handbook got updated, so seemingly everyone was fine with this depreciation. I am not going to bring any serious arguments against etcupdate(8), but when providing support on IRC, a few cases of foot shooting with this tool had been reported to me and the last one happened this year IIRC. Moreover some people, including me, just like and are used to old sdiff(1)-way work of mergemaster(8).  So soon after the transition to git to overcome this deficiency I wrote for myself a git primer helping with quick creation of local repository including $FreeBSD$ recreation for mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this primer[2] for users here, maybe someone (noncommitter) will benefit from this (if it will not get burned with fire here earlier).

Please don't get me wrong, I am not fighting with etcupdate(8) which works almost flawlessly in unison with freebsd-update(8), but people who follow STABLE/CURRENT really do appreciate the existence of mergemaster(8) and still use it behind the scenes, including probably members of core@ team. I am only asking for leaving these empty $FreeBSD$ IDs in config files. This will of course add some burden to committers' work but might be beneficial in the future. I am neither committer, nor contributor, but the voice from the userbase.

Best regards,

Marek Zarychta

[1] https://cgit.freebsd.org/src/commit/?id=835ee05f

[2]

########################################################
#
# FreeBSD Git src with worktrees and clean/smudge filters 
# for mergemaster(8)
#
########################################################
# Preparation of the tree

zfs create zroot/usr/src_head
zfs create zroot/usr/src_13

########################################################
# Making src of stable/13 mountable in /usr/src
 
echo "/usr/src_13 	/usr/src 		nullfs rw,late 0 0" >> /etc/fstab
mount -al

########################################################
# Cloning the repository

cd /usr/src_head
git clone https://git.freebsd.org/src.git/ ./

########################################################
# Adding filters
# Filters require lang/ruby and lang/perl installed

git config filter.freebsdid.smudge expand_freebsd
git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"'

########################################################
# Limiting filters scope
# In /usr/src_head create file .git/info/attributes with 
# following contents (at least):

------------cut------------
cat > .git/info/attributes << EOF
etc/* 	                filter=freebsdid
etc/*/*                 filter=freebsdid
libexec/rc/*            filter=freebsdid
libexec/rc/rc.d/*       filter=freebsdid
*.conf                  filter=freebsdid
dot.??*                 filter=freebsdid
lib/libc/gen/shells     filter=freebsdid
lib/libc/net/hosts      filter=freebsdid
lib/libpam/pam.d/*      filter=freebsdid
lib/libwrap/hosts.allow filter=freebsdid
usr.sbin/services_mkdb/services filter=freebsdid
usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=freebsdid
usr.sbin/periodic/etc/* filter=freebsdid
usr.sbin/cron/cron/crontab filter=freebsdid
crypto/openssh/ssh*_config filter=freebsdid
EOF
------------cut------------

########################################################
# Smudge filter setup
# Create file /usr/local/bin/expand_freebsd with following 
# contents and make it executable.

------------cut------------
#!/usr/bin/env ruby
data = STDIN.read
last_info = `git log --pretty=format:"%h %ae %ad" -1`
puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s + '$')
------------cut------------

chmod a+x /usr/local/bin/expand_freebsd 

########################################################
# Adding worktrees
# Add worktree for stable/13, filters will be applied

git worktree add /usr/src_13 stable/13

# To have IDs in main (HEAD) 
# do checkout of filtered files again

cd /usr/src_head
rm etc/master.passwd etc/group 
rm libexec/rc/rc.d/*
git checkout -f -- .

########################################################
# To find more files with $FreeBSD tags which might
# be added to .git/info/attributes file issue command: 

find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD' 

-- 
Marek Zarychta
--------------AmnHHBLpn03nhE2I6GGre0ZE-- From nobody Tue May 3 00:15:22 2022 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 406B51ABEB2C for ; Tue, 3 May 2022 00:16:17 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsgVS2TdTz3p1H for ; Tue, 3 May 2022 00:16:16 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x429.google.com with SMTP id c11so11564707wrn.8 for ; Mon, 02 May 2022 17:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:to:content-language:from :subject:content-transfer-encoding; bh=DXNOL5V9ul+f6M/eT0Lal8aMsEPHE3m4jVZ1Wzf+Dxc=; b=FLvRe7rz75dcf6MZCoSt7y0RDG+NsdWbIts7fGA5AT/nEAHDqp0FqnXQbOSM5nhRo4 iN9fXqTTpm5iwEpD5IxpRpSGv1g1pU8WV4X85ANt9I1SJEJjPlRgnya/XnzXhblx8sVT SygS4f+O5GETcQ9Pm7LCmrQRGB6nqBC1KL7Yi0pguwpmYXt4APzlXqu5voGrU82nOEvF Isii2jKHeSExQUGgFeyn+Ec+y1seNKfPwQojeSTnhiaugY8hvyYX56FsW1fGLQ6qm+Wl PDyrq4Y+NH649ZkqWfUfNSKFAngRulK+FzZwt+CvwPEs8d+8z+OYJXU7qrVeBCWiTIEp PNIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to :content-language:from:subject:content-transfer-encoding; bh=DXNOL5V9ul+f6M/eT0Lal8aMsEPHE3m4jVZ1Wzf+Dxc=; b=5xWiCoiSjV2bX+z728ed5UchQjOkP5WicBYq2yuJfkQS4n6iFI3/lJtB14mh3oF0Dz Qmfb9mIrqosN618UXMNpi3rvHCFa2e6GVRw42/ZefW6gmVtE4tgZiZ1sduJ/YlurT7Kd XSLtJhRcSnz+N9X12LBNiKMOQYp7TqteVB14jiOQ8ORSgx2XVHF2bK+nhvGX9kaJXxj9 seIvSzRJkq37Sb1MNUJEpVBOsgRfF+XKoST1/sCy3UmUwyAhin20t+6+4tnrCnF4e8We WkFMQHxWcz2brwGvMPdeYvlIlOPEfyqY+gXxBnCWGo/8rBi0Myv6X7/5FrTih9Sm6c+e SUwg== X-Gm-Message-State: AOAM531DaFbYKAivuGVn1FL8GHM8RPoD0aFth5ybXUFkTpz2zG1/1EAG yFRqjUiaLFzUeZ3iYggw7BgWwSf1QpKuig== X-Google-Smtp-Source: ABdhPJwpNTsiqhrS5r80Nv8s+AepguN5cVQvQlvUUNaCYhmIuI+QXOTLPpJOgPLei5ntYtc9+JzcFA== X-Received: by 2002:a5d:4e05:0:b0:20a:d4a6:32b1 with SMTP id p5-20020a5d4e05000000b0020ad4a632b1mr10597154wrt.174.1651536974877; Mon, 02 May 2022 17:16:14 -0700 (PDT) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id t8-20020a7bc3c8000000b0038eba413181sm566759wmj.1.2022.05.02.17.16.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 May 2022 17:16:14 -0700 (PDT) Message-ID: <20b1c8ea-71ef-784f-a6bd-de1abce406a0@gmail.com> Date: Tue, 3 May 2022 01:15:22 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 To: freebsd-current@freebsd.org Content-Language: en-GB From: Graham Perrin Subject: (263489) (D35109) freebsd-update: restart sshd after upgrade Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KsgVS2TdTz3p1H X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=FLvRe7rz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::429 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.21 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.23)[-0.233]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.975]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::429:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N (line 3028) How will freebsd-update behave in this case? > Cannot 'status' sshd. Set sshd_enable to YES in /etc/rc.conf or use > 'onestatus' instead of 'status'. (I'd test for myself, but it's late, and I'd like to seed the thought before I forget.) From nobody Tue May 3 00:18:42 2022 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 0288E1ABF551 for ; Tue, 3 May 2022 00:18:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsgYH6GGhz3pXs; Tue, 3 May 2022 00:18:43 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 2430IgVg013913 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 2 May 2022 17:18:42 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 2430IgVt013912; Mon, 2 May 2022 17:18:42 -0700 (PDT) (envelope-from sgk) Date: Mon, 2 May 2022 17:18:42 -0700 From: Steve Kargl To: Ed Maste Cc: FreeBSD Current Subject: Re: Profiled libraries on freebsd-current Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KsgYH6GGhz3pXs X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-0.35 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.47)[-0.466]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-0.53)[-0.528]; NEURAL_SPAM_SHORT(0.65)[0.648]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Mon, May 02, 2022 at 10:37:00AM -0700, Steve Kargl wrote: > On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote: > > On Sun, 1 May 2022 at 11:54, Steve Kargl > > wrote: > > > > > > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h > > > index 594487829b5..1e8ab2e1827 100644 > > > --- a/gcc/config/freebsd-spec.h > > > +++ b/gcc/config/freebsd-spec.h > > > @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see > > > (similar to the default, except no -lg, and no -p). */ > > > > > > #ifdef FBSD_NO_THREADS > > > > I wonder if we can simplify things now, and remove this > > `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC > > targets I looked at. > > That I don't know. FBSD_NO_THREADS is defined in freebsd-nthr.h. > In fact, it's the only thing in that header (except copyright > broilerplate). freebsd-nthr.h only appears in config.gcc and > seems to only get added to the build if someone runs configure > with --enable-threads=no. Looking at my last config.log for > gcc trunk, I see "Thread model: posix", which appears to be > the default case or if someone does --enable-threads=yes or > --enable-threads=posix. So, I suppose it comes down to > two questions: (1) is libpthread.* available on all supported > targets and versions? (2) does anyone build gcc without > threads support? > Well, I built and executed gcc testsuite with and without threads enabled. Either a few new test failures in the disable case may unilaterally assume threads are available, or these are in fact issues (with a rarely used configure option). config 1 ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran,lto \ --enable-bootstrap --disable-nls --enable-checking --disable-multilib config 2 ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran,lto \ --enable-bootstrap --disable-nls --enable-checking --disable-multilib \ --enable-threads=no --disable-threads === g++ Summary === config 1 config 2 # of expected passes 225442 225348 # of unexpected failures 675 724 # of expected failures 2071 2071 # of unresolved testcases 11 47 # of unsupported tests 10342 10342 === gcc Summary === # of expected passes 175562 175401 # of unexpected failures 1046 1116 # of unexpected successes 20 20 # of expected failures 1459 1459 # of unresolved testcases 10 92 # of unsupported tests 3260 3260 === gfortran Summary === # of expected passes 66124 66046 # of unexpected failures 6 84 # of expected failures 272 272 # of unresolved testcases 2 2 # of unsupported tests 100 100 -- Steve From nobody Tue May 3 01:53:24 2022 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 9235F1AB3527 for ; Tue, 3 May 2022 01:53:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ksjfv5z5Gz4WVk for ; Tue, 3 May 2022 01:53:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa29.google.com with SMTP id m203so7362292vke.13 for ; Mon, 02 May 2022 18:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hWfoHvrcndBpi0KLugFRK4L/F6Dz6oSgIdUudH3jUvU=; b=uBfMofmATEtlQiDdVyGDOoLQaRtgN1e6ckgZmjRvpPvzq+MwGLsZLh1mPqlADOx74K W4C6Un7bSLhQBI7eHUUlYJmrFYT3Jqn75CfvoaKAR/uQ3IabzFdvAs/9My9L81/NZ777 +8dWRb2jHOzc2Tc2cF8dCRgS4h3m+2B45wXD7pKN3N2Ewqbs2NIov1Fj6749NAle/i1v guzDoA5a4aZwdpcVk4jEiNpP5/y/XE7Rc1w7ZQh4LiXUSHSyh3EYwM251h+PluxIaM1I Hgle/fulkM9SH+s2GpAVnrBexJiNi6tBJ4YQARrpoQGImH7C1zbzTRHnlUTNGLlLPU+7 vAuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hWfoHvrcndBpi0KLugFRK4L/F6Dz6oSgIdUudH3jUvU=; b=pFM4R2mhpIfD+45QNgEIS+OrlLEebUWMohezzGiZTZU7nDCBPjkqh7aiAFyDDAyudu aFrpRx5zeBlinnJJ95BHPSBff2Ukj7VfJFWnINBQsv5XvbJk24K3Zfgr/7DcdU7qg4Y6 AHbb7kEQgffoJSM+leDGfafXFpDXK+Ckpy+xThPv3b8zV8N9FHqMNq2b+5XYq8rBpKIs wLPMDKUboenrwNkAPORzTGbK67ZQufSNzcHt4cPrqk3G+k0ZJSyVwZ1P54//cyNZE599 UU6LIaVBi1pUOLBM3JYEzz9LAak6Q8hFhVSGIjFicqYug+BWAadz+bxD/pc1YdMKMKrT h28w== X-Gm-Message-State: AOAM533b+yFhofUSs2V/PytMQVFkI2tS53ojy13UJYrC4XGgve11lLxS cDPfq2YLAn//ii72jtb1jKGC50kx7LfA+z883FIJSQ== X-Google-Smtp-Source: ABdhPJwXBoQxV0ikeQwby6JRdyrX2zwzrQ3b/ATQmItVKaA5jK9JMZ7niTQK1UypPjMRqKcjyHCGTirfWhW3h2AR+MY= X-Received: by 2002:a1f:aa11:0:b0:349:8fe5:6639 with SMTP id t17-20020a1faa11000000b003498fe56639mr4045316vke.15.1651542816630; Mon, 02 May 2022 18:53:36 -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: <4ba8458e-db94-6f74-a8e0-ba71692ea72a@plan-b.pwste.edu.pl> <980b2e8a16a0417b5bf11eadce03471e@gundo.com> In-Reply-To: <980b2e8a16a0417b5bf11eadce03471e@gundo.com> From: Warner Losh Date: Mon, 2 May 2022 19:53:24 -0600 Message-ID: Subject: Re: discussion on future removal of empty $FreeBSD$ tags To: Pau Amma Cc: Marek Zarychta , freeBSD Current , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000eabe6d05de11c67d" X-Rspamd-Queue-Id: 4Ksjfv5z5Gz4WVk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=uBfMofmA; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a29) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.86)[-0.864]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.77)[0.768]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; SUBJECT_HAS_CURRENCY(1.00)[]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a29:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000eabe6d05de11c67d Content-Type: text/plain; charset="UTF-8" On Mon, May 2, 2022, 4:37 PM Pau Amma wrote: > On 2022-05-02 20:09, Warner Losh wrote: > > The current plans are to keep $FreeBSD$ in main until stable/12 is out > > of > > support. no new files will have it added, unless they are to be merged > > to > > stable/12 and are installed / managed by mergemaster. > > > > We'll do a coordinated sweep of the tree removing them after stable/12 > > drops out of support and we'll do similar commits to stable/13 to > > reduce as > > much as possible any merge conflicts after that point. > > Tangentially, what about things that used to be part of base but were > later spun off into ports? https://github.com/freebsd/calendar-data is > an example: there may be others. Do these need the $FreeBSD$ tag removed > as well, and when if so? > There is no reason to keep them at all. They can be removed any time as can tags in ports or docs. Warner -- > #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters > #StandWithUkrainians > English: he/him/his (singular they/them/their/theirs OK) > French: il/le/lui (iel/iel and ielle/ielle OK) > Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) > --000000000000eabe6d05de11c67d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 2, 2022, 4:37 PM Pau Amma <pauamma@gundo.com> wrote:
On 2022-05-02 20:09, Warner Losh wrote:
> The current plans are to keep $FreeBSD$ in main until stable/12 is out=
> of
> support. no new files will have it added, unless they are to be merged=
> to
> stable/12 and are installed / managed by mergemaster.
>
> We'll do a coordinated sweep of the tree removing them after stabl= e/12
> drops out of support and we'll do similar commits to stable/13 to =
> reduce as
> much as possible any merge conflicts after that point.

Tangentially, what about things that used to be part of base but were
later spun off into ports? https://github.com/fre= ebsd/calendar-data is
an example: there may be others. Do these need the $FreeBSD$ tag removed as well, and when if so?

=
There is no reason to keep them at all. They can be= removed any time as can tags in ports or docs.

=
Warner=C2=A0

--
#BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters
#StandWithUkrainians
English: he/him/his (singular they/them/their/theirs OK)
French: il/le/lui (iel/iel and ielle/ielle OK)
Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila)
<= /div>



--000000000000eabe6d05de11c67d-- From nobody Tue May 3 09:08:09 2022 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 083C31AC2A69 for ; Tue, 3 May 2022 09:08:20 +0000 (UTC) (envelope-from SRS0=o5I+=VL=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4KsvJL60CMz4RyW for ; Tue, 3 May 2022 09:08:18 +0000 (UTC) (envelope-from SRS0=o5I+=VL=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 541AD28411 for ; Tue, 3 May 2022 11:08:11 +0200 (CEST) Received: from illbsd.quip.test (ip-78-45-215-131.net.upcbroadband.cz [78.45.215.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 2402028417 for ; Tue, 3 May 2022 11:08:10 +0200 (CEST) Subject: Re: (263489) (D35109) freebsd-update: restart sshd after upgrade To: freebsd-current@freebsd.org References: <20b1c8ea-71ef-784f-a6bd-de1abce406a0@gmail.com> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <382c2b83-bd65-9534-a273-8eb17ba6aaf5@quip.cz> Date: Tue, 3 May 2022 11:08:09 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 In-Reply-To: <20b1c8ea-71ef-784f-a6bd-de1abce406a0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: cs Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KsvJL60CMz4RyW X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=o5I@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=o5I@elsa.codelab.cz" X-Spamd-Result: default: False [-0.65 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(0.08)[0.076]; NEURAL_HAM_SHORT(-0.92)[-0.923]; DMARC_NA(0.00)[quip.cz]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=o5I@elsa.codelab.cz]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; TAGGED_FROM(0.00)[=VL=quip.cz=000.fbsd]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=o5I@elsa.codelab.cz]; RECEIVED_SPAMHAUS_PBL(0.00)[78.45.215.131:received] X-ThisMailContainsUnwantedMimeParts: N On 03/05/2022 02:15, Graham Perrin wrote: > > (line 3028) > > How will freebsd-update behave in this case? > >> Cannot 'status' sshd. Set sshd_enable to YES in /etc/rc.conf or use >> 'onestatus' instead of 'status'. > > (I'd test for myself, but it's late, and I'd like to seed the thought > before I forget.) Shouldn't it be user configurable if (any) service should be restarted during update / upgrade? I remember sshd not starting after upgrade in the past. I don't use freebsd-update, but doing sshd restart by hand and sometimes there are some incompatible changes which prevent sshd from starting. This "safety" sshd restart can be dangerous too. Kind regards Miroslav Lachman From nobody Tue May 3 12:36:07 2022 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 C115E1AC5A4E for ; Tue, 3 May 2022 12:36:23 +0000 (UTC) (envelope-from qroxana@protonmail.com) Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) (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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KszwQ3mZ3z3BrQ for ; Tue, 3 May 2022 12:36:22 +0000 (UTC) (envelope-from qroxana@protonmail.com) Date: Tue, 03 May 2022 12:36:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1651581375; bh=XupXUCnRJOhITh2B2Yh1HGJRUEUZrQgV9tVmeLA1RiE=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=a4VzN04gxfN2R+s6qq6eD4PoU34yDtMqwSssY+3yoGdUzFFjmJjQrZ482He3C8+5u vsb1ZEssWe9k1HplDJ8odss0OPLSStgWznEoWIGZEZKRnV19058dYfno3ml4OUSKQN GfIU9gc5BElWBC43zxTiKYoFOhyWBBwwjIbtohwahZ38Cm/pys39lG6MtvlHNxJVeK i2UV9h1Q1s+kmyavTZWscDUxEgNWQ8pFfjWCpNdSTi6cROXOwzKHssJniOQJ2K0TBZ pioXayuVNv3XkX6F6s8w/PtOPkLpMc4zPWf8xpIMIw3BYLpmwNHe83Qd7C61zcQczt lm0whKegcZN0w== To: Kristof Provost From: qroxana Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Reply-To: qroxana Subject: Re: Kernel panic on armv7 when PF is enabled Message-ID: <83Y13opkQnjBkBmEsEU8Y9TJX06SXVmwSnCQfQCt0a6fInNoiEVaUcEnnrWr3h34dcFZJosg8AksGQr1v9zW_ljw5JIZIpBRm4qR5ga9FZM=@protonmail.com> In-Reply-To: References: Feedback-ID: 29996633:user:proton 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-Queue-Id: 4KszwQ3mZ3z3BrQ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail2 header.b=a4VzN04g; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of qroxana@protonmail.com designates 185.70.40.137 as permitted sender) smtp.mailfrom=qroxana@protonmail.com X-Spamd-Result: default: False [-0.02 / 15.00]; HAS_REPLYTO(0.00)[qroxana@protonmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail2]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; NEURAL_HAM_LONG(-0.98)[-0.981]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(0.96)[0.961]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.999]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Monday, May 2nd, 2022 at 9:02 AM, Kristof Provost wrote= : > On 1 May 2022, at 5:13, qroxana wrote: > > > After git bisecting the panic started since this commit. > > > > commit 78bc3d5e1712bc1649aa5574d2b8d153f9665113 > > > > Author: Kristof Provost < > > kp@FreeBSD.org > > > > Date: Mon Feb 14 20:09:54 2022 +0100 > > > > vlan: allow net.link.vlan.mtag_pcp to be set per vnet > > > > The primary reason for this change is to facilitate testing. > > > > MFC after: 1 week > > > > sys/net/if_ethersubr.c | 9 +++++---- > > > > sys/net/if_vlan.c | 5 +++-- > > > > 2 files changed, 8 insertions(+), 6 deletions(-) > > > > The armv7 board boots from a NFS root, > > > > it can boot without any problem if PF is disabled. > > > > Any helps? > > > > add host ::1: gateway lo0 fib 0: route already in table > > add net fe80::: gateway ::1 > > add net ff02::: gateway ::1 > > add net ::ffff:0.0.0.0: gateway ::1 > > add net ::0.0.0.0: gateway ::1 > > Enabling pf. > > Kernel page fault with the following non-sleepable locks held: > > shared rm pf rulesets (pf rulesets) r =3D 0 (0xe3099430) locked @ /usr/= src/sys/netpfil/pf/pf.c:6493 > > exclusive rw tcpinp (tcpinp) r =3D 0 (0xdb748d88) locked @ /usr/src/sys= /netinet/tcp_usrreq.c:1008 > > stack backtrace: > > #0 0xc0355cac at witness_debugger+0x7c > > #1 0xc0356ef0 at witness_warn+0x3fc > > #2 0xc05ec048 at abort_handler+0x1d8 > > #3 0xc05cb5ac at exception_exit+0 > > #4 0xe3083c10 at pf_syncookie_validate+0x60 > > #5 0xe30496a8 at pf_test+0x518 > > #6 0xe306d768 at pf_check_out+0x30 > > #7 0xc0415b44 at pfil_run_hooks+0xbc > > #8 0xc0445cfc at ip_output+0xce8 > > #9 0xc045bc9c at tcp_default_output+0x20ac > > #10 0xc0471eb4 at tcp_usr_send+0x1ac > > #11 0xc0389464 at sosend_generic+0x490 > > #12 0xc0389790 at sosend+0x64 > > #13 0xc0502888 at clnt_vc_call+0x560 > > #14 0xc05009d8 at clnt_reconnect_call+0x170 > > #15 0xc01e7b14 at newnfs_request+0xb20 > > #16 0xc0230218 at nfscl_request+0x60 > > #17 0xc020d9bc at nfsrpc_getattr+0xb0 > > Fatal kernel mode data abort: 'Alignment Fault' on read > > trapframe: 0xdf1f1c90 > > FSR=3D00000001, FAR=3Dd7840264, spsr=3D40000013 > > r0 =3D6a228eda, r1 =3Ddac0d785, r2 =3Dd7840264, r3 =3Ddb5527c0 > > r4 =3Ddf1f1e00, r5 =3Ddac0d75f, r6 =3D00000018, r7 =3Dd9422c00 > > r8 =3Dc093e5e4, r9 =3D00000001, r10=3Ddf1f1f5c, r11=3Ddf1f1d38 > > r12=3De3098dd0, ssp=3Ddf1f1d20, slr=3De3083bdc, pc =3De3083c10 > > The commit you point at is entirely unrelated to the code where the panic= occurred, so I=E2=80=99m pretty sure something went wrong in your bisect. > > The backtrace would suggest the issue occurs in the pf_syncookie_validate= () function, and likely in the line `if (atomic_load_64(&V_pf_status.syncoo= kies_inflight[cookie.flags.oddeven]) =3D=3D 0)` > > The obvious way for that to panic would be to call it without the curvnet= context set, but pf_test() uses it earlier, so that=E2=80=99s going to be = fine. > > Given that this is unique to armv7 I=E2=80=99d recommend talking to the a= rmv7 maintainer about 64 bit atomic operations. > > You can probably avoid the atomic load with this patch (and not enabling = syncookie support): > > diff --git a/sys/netpfil/pf/pf_syncookies.c b/sys/netpfil/pf/pf_synco= okies.c > index 5230502be30c..c86d469d3cef 100644 > --- a/sys/netpfil/pf/pf_syncookies.c > +++ b/sys/netpfil/pf/pf_syncookies.c > @@ -313,6 +313,9 @@ pf_syncookie_validate(struct pf_pdesc *pd) > ack =3D ntohl(pd->hdr.tcp.th_ack) - 1; > cookie.cookie =3D (ack & 0xff) ^ (ack >> 24); > > + if (V_pf_status.syncookies_mode =3D=3D PF_SYNCOOKIES_NEVER) > + return (0); > + > /* we don't know oddeven before setting the cookie (union) */ > if (atomic_load_64(&V_pf_status.syncookies_inflight[cookie.f= lags.oddeven]) > =3D=3D 0) > > > That shouldn=E2=80=99t be required though. > > Br, > Kristof Thank you sir. You were right. I tested patch with the latest kernel. It can boot successfully with the patch, and still got kernel panic without the patch. From nobody Tue May 3 14:09:35 2022 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 76F2C1ABD56B; Tue, 3 May 2022 14:09:43 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kt2054TH9z3lLX; Tue, 3 May 2022 14:09:41 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [IPV6:2001:470:71:d47:4c06:dff6:5a69:7c54] ([IPv6:2001:470:71:d47:4c06:dff6:5a69:7c54]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 243E9ZNZ091945 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 3 May 2022 16:09:36 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1651586976; bh=sbU+D8vc69kzOtQsmtkqJvuT48xz+hFgrwURDpSTp+U=; h=Date:To:Cc:References:From:Subject:In-Reply-To; b=KCWVJHBDpl1Q3UIMc4Atj55Z/32FB6P2RsSuPa6f9ghNkmYqASU3jeBU4O7eADP8J nAACqUS1kHt2A7+ZVY92djoVhmjkFspsYMbu638ZOvxHutA0SvrPq10vm/+5KzTtgd AJsWSrDeb4VvcWHeUYhiUyx9EyTQrdRqQ9hPHmbHEE4LK/KIJJ/BAJ5gKBuFJ7SlN8 C7UTsRMEJmHVewJEFcRh01ZYNlWyni6g58Q2clDfpq2N4bVN3rPiQk5TcmS+LFfEJq NCJd1gU2g8+6LIoQR//l8gl/zqt/4NfQRrDhVL2uPBzLiNKBT5D0AZXgjZe0qIQJTb S98CVDYjEjD0g== Message-ID: Date: Tue, 3 May 2022 16:09:35 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: pl To: Kristof Provost , qroxana Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org References: From: Marek Zarychta Subject: Re: Kernel panic on armv7 when PF is enabled In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Lg0N7bEEfhhztaGlbQeZa0qv" X-Rspamd-Queue-Id: 4Kt2054TH9z3lLX X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=KCWVJHBD; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-5.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-current]; FREEMAIL_TO(0.00)[FreeBSD.org,protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Lg0N7bEEfhhztaGlbQeZa0qv Content-Type: multipart/mixed; boundary="------------snUu1J87zM0pGEKwNJnUWVep"; protected-headers="v1" From: Marek Zarychta To: Kristof Provost , qroxana Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Message-ID: Subject: Re: Kernel panic on armv7 when PF is enabled References: In-Reply-To: --------------snUu1J87zM0pGEKwNJnUWVep Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VyBkbml1IDIuMDUuMjAyMiBvwqAxMTowMiwgS3Jpc3RvZiBQcm92b3N0IHBpc3plOg0KPiBP biAxIE1heSAyMDIyLCBhdCA1OjEzLCBxcm94YW5hIHdyb3RlOg0KPiANCj4gICAgIEFmdGVy IGdpdCBiaXNlY3RpbmcgdGhlIHBhbmljIHN0YXJ0ZWQgc2luY2UgdGhpcyBjb21taXQuDQo+ IA0KPiAgICAgY29tbWl0IDc4YmMzZDVlMTcxMmJjMTY0OWFhNTU3NGQyYjhkMTUzZjk2NjUx MTMNCj4gDQo+ICAgICBBdXRob3I6IEtyaXN0b2YgUHJvdm9zdCA8DQo+ICAgICBrcEBGcmVl QlNELm9yZw0KPiANCj4gICAgIERhdGU6IE1vbiBGZWIgMTQgMjA6MDk6NTQgMjAyMiArMDEw MA0KPiANCj4gICAgIHZsYW46IGFsbG93IG5ldC5saW5rLnZsYW4ubXRhZ19wY3AgdG8gYmUg c2V0IHBlciB2bmV0DQo+IA0KPiAgICAgVGhlIHByaW1hcnkgcmVhc29uIGZvciB0aGlzIGNo YW5nZSBpcyB0byBmYWNpbGl0YXRlIHRlc3RpbmcuDQo+IA0KPiAgICAgTUZDIGFmdGVyOiAx IHdlZWsNCj4gDQo+ICAgICBzeXMvbmV0L2lmX2V0aGVyc3Vici5jIHwgOSArKysrKy0tLS0N Cj4gDQo+ICAgICBzeXMvbmV0L2lmX3ZsYW4uYyB8IDUgKysrLS0NCj4gDQo+ICAgICAyIGZp bGVzIGNoYW5nZWQsIDggaW5zZXJ0aW9ucygrKSwgNiBkZWxldGlvbnMoLSkNCj4gDQo+ICAg ICBUaGUgYXJtdjcgYm9hcmQgYm9vdHMgZnJvbSBhIE5GUyByb290LA0KPiANCj4gICAgIGl0 IGNhbiBib290IHdpdGhvdXQgYW55IHByb2JsZW0gaWYgUEYgaXMgZGlzYWJsZWQuDQo+IA0K PiAgICAgQW55IGhlbHBzPw0KPiANCj4gICAgIGFkZCBob3N0IDo6MTogZ2F0ZXdheSBsbzAg ZmliIDA6IHJvdXRlIGFscmVhZHkgaW4gdGFibGUNCj4gICAgIGFkZCBuZXQgZmU4MDo6OiBn YXRld2F5IDo6MQ0KPiAgICAgYWRkIG5ldCBmZjAyOjo6IGdhdGV3YXkgOjoxDQo+ICAgICBh ZGQgbmV0IDo6ZmZmZjowLjAuMC4wOiBnYXRld2F5IDo6MQ0KPiAgICAgYWRkIG5ldCA6OjAu MC4wLjA6IGdhdGV3YXkgOjoxDQo+ICAgICBFbmFibGluZyBwZi4NCj4gICAgIEtlcm5lbCBw YWdlIGZhdWx0IHdpdGggdGhlIGZvbGxvd2luZyBub24tc2xlZXBhYmxlIGxvY2tzIGhlbGQ6 DQo+ICAgICBzaGFyZWQgcm0gcGYgcnVsZXNldHMgKHBmIHJ1bGVzZXRzKSByID0gMCAoMHhl MzA5OTQzMCkgbG9ja2VkIEANCj4gICAgIC91c3Ivc3JjL3N5cy9uZXRwZmlsL3BmL3BmLmM6 NjQ5Mw0KPiAgICAgZXhjbHVzaXZlIHJ3IHRjcGlucCAodGNwaW5wKSByID0gMCAoMHhkYjc0 OGQ4OCkgbG9ja2VkIEANCj4gICAgIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF91c3JyZXEu YzoxMDA4DQo+ICAgICBzdGFjayBiYWNrdHJhY2U6DQo+ICAgICAjMCAweGMwMzU1Y2FjIGF0 IHdpdG5lc3NfZGVidWdnZXIrMHg3Yw0KPiAgICAgIzEgMHhjMDM1NmVmMCBhdCB3aXRuZXNz X3dhcm4rMHgzZmMNCj4gICAgICMyIDB4YzA1ZWMwNDggYXQgYWJvcnRfaGFuZGxlcisweDFk OA0KPiAgICAgIzMgMHhjMDVjYjVhYyBhdCBleGNlcHRpb25fZXhpdCswDQo+ICAgICAjNCAw eGUzMDgzYzEwIGF0IHBmX3N5bmNvb2tpZV92YWxpZGF0ZSsweDYwDQo+ICAgICAjNSAweGUz MDQ5NmE4IGF0IHBmX3Rlc3QrMHg1MTgNCj4gICAgICM2IDB4ZTMwNmQ3NjggYXQgcGZfY2hl Y2tfb3V0KzB4MzANCj4gICAgICM3IDB4YzA0MTViNDQgYXQgcGZpbF9ydW5faG9va3MrMHhi Yw0KPiAgICAgIzggMHhjMDQ0NWNmYyBhdCBpcF9vdXRwdXQrMHhjZTgNCj4gICAgICM5IDB4 YzA0NWJjOWMgYXQgdGNwX2RlZmF1bHRfb3V0cHV0KzB4MjBhYw0KPiAgICAgIzEwIDB4YzA0 NzFlYjQgYXQgdGNwX3Vzcl9zZW5kKzB4MWFjDQo+ICAgICAjMTEgMHhjMDM4OTQ2NCBhdCBz b3NlbmRfZ2VuZXJpYysweDQ5MA0KPiAgICAgIzEyIDB4YzAzODk3OTAgYXQgc29zZW5kKzB4 NjQNCj4gICAgICMxMyAweGMwNTAyODg4IGF0IGNsbnRfdmNfY2FsbCsweDU2MA0KPiAgICAg IzE0IDB4YzA1MDA5ZDggYXQgY2xudF9yZWNvbm5lY3RfY2FsbCsweDE3MA0KPiAgICAgIzE1 IDB4YzAxZTdiMTQgYXQgbmV3bmZzX3JlcXVlc3QrMHhiMjANCj4gICAgICMxNiAweGMwMjMw MjE4IGF0IG5mc2NsX3JlcXVlc3QrMHg2MA0KPiAgICAgIzE3IDB4YzAyMGQ5YmMgYXQgbmZz cnBjX2dldGF0dHIrMHhiMA0KPiAgICAgRmF0YWwga2VybmVsIG1vZGUgZGF0YSBhYm9ydDog J0FsaWdubWVudCBGYXVsdCcgb24gcmVhZA0KPiAgICAgdHJhcGZyYW1lOiAweGRmMWYxYzkw DQo+ICAgICBGU1I9MDAwMDAwMDEsIEZBUj1kNzg0MDI2NCwgc3Bzcj00MDAwMDAxMw0KPiAg ICAgcjAgPTZhMjI4ZWRhLCByMSA9ZGFjMGQ3ODUsIHIyID1kNzg0MDI2NCwgcjMgPWRiNTUy N2MwDQo+ICAgICByNCA9ZGYxZjFlMDAsIHI1ID1kYWMwZDc1ZiwgcjYgPTAwMDAwMDE4LCBy NyA9ZDk0MjJjMDANCj4gICAgIHI4ID1jMDkzZTVlNCwgcjkgPTAwMDAwMDAxLCByMTA9ZGYx ZjFmNWMsIHIxMT1kZjFmMWQzOA0KPiAgICAgcjEyPWUzMDk4ZGQwLCBzc3A9ZGYxZjFkMjAs IHNscj1lMzA4M2JkYywgcGMgPWUzMDgzYzEwDQo+IA0KPiANCj4gVGhlIGNvbW1pdCB5b3Ug cG9pbnQgYXQgaXMgZW50aXJlbHkgdW5yZWxhdGVkIHRvIHRoZSBjb2RlIHdoZXJlIHRoZSAN Cj4gcGFuaWMgb2NjdXJyZWQsIHNvIEnigJltIHByZXR0eSBzdXJlIHNvbWV0aGluZyB3ZW50 IHdyb25nIGluIHlvdXIgYmlzZWN0Lg0KDQpJIHdhcyBleHBlcmllbmNpbmcgdGhpcyBwYW5p YyBhbHNvIHJ1bm5pbmcgRnJlZUJTRCAxNC4wLUNVUlJFTlQgIzEgDQptYWluLW4yNTMwMjgt MmVjOWE0MjdjODU6IFR1ZSBGZWIgIDggMTc6NDk6MjUgQ0VUIDIwMjIgb24gYXJtdjcsIHNv IGl0J3MgDQp1bnJlbGF0ZWQgdG8gYWZvcmVtZW50aW9uZWQgY29tbWl0IHdoaWNoIGlzIGRh dGVkIDIwMjItMDItMTQuDQoNCkl0J3MgdmVyeSBpbnRlcmVzdGluZyBhbmQgd2VpcmQgYnVn LCBsb2FkaW5nIHBmLmtvLCBlbmFibGluZyBQRiwgbG9hZGluZyANCnRoZSBydWxlcyB3b3Jr IGFzIGV4cGVjdGVkLCBidXQgcHJvY2Vzc2luZyB0aGUgZmlsdGVyZWQgdHJhZmZpYyBieSBQ RiANCnRyaWdnZXJzIHRoZSBwYW5pYy4NCg0KPiANCj4gVGhlIGJhY2t0cmFjZSB3b3VsZCBz dWdnZXN0IHRoZSBpc3N1ZSBvY2N1cnMgaW4gdGhlIA0KPiBwZl9zeW5jb29raWVfdmFsaWRh dGUoKSBmdW5jdGlvbiwgYW5kIGxpa2VseSBpbiB0aGUgbGluZSB8aWYgDQo+IChhdG9taWNf bG9hZF82NCgmVl9wZl9zdGF0dXMuc3luY29va2llc19pbmZsaWdodFtjb29raWUuZmxhZ3Mu b2RkZXZlbl0pIA0KPiA9PSAwKXwNCj4gDQo+IFRoZSBvYnZpb3VzIHdheSBmb3IgdGhhdCB0 byBwYW5pYyB3b3VsZCBiZSB0byBjYWxsIGl0IHdpdGhvdXQgdGhlIA0KPiBjdXJ2bmV0IGNv bnRleHQgc2V0LCBidXQgcGZfdGVzdCgpIHVzZXMgaXQgZWFybGllciwgc28gdGhhdOKAmXMg Z29pbmcgdG8gDQo+IGJlIGZpbmUuDQo+IA0KPiBHaXZlbiB0aGF0IHRoaXMgaXMgdW5pcXVl IHRvIGFybXY3IEnigJlkIHJlY29tbWVuZCB0YWxraW5nIHRvIHRoZSBhcm12NyANCj4gbWFp bnRhaW5lciBhYm91dCA2NCBiaXQgYXRvbWljIG9wZXJhdGlvbnMuDQo+IA0KPiBZb3UgY2Fu IHByb2JhYmx5IGF2b2lkIHRoZSBhdG9taWMgbG9hZCB3aXRoIHRoaXMgcGF0Y2ggKGFuZCBu b3QgZW5hYmxpbmcgDQo+IHN5bmNvb2tpZSBzdXBwb3J0KToNCj4gDQo+IHxkaWZmIC0tZ2l0 IGEvc3lzL25ldHBmaWwvcGYvcGZfc3luY29va2llcy5jIA0KPiBiL3N5cy9uZXRwZmlsL3Bm L3BmX3N5bmNvb2tpZXMuYyBpbmRleCA1MjMwNTAyYmUzMGMuLmM4NmQ0NjlkM2NlZiAxMDA2 NDQgDQo+IC0tLSBhL3N5cy9uZXRwZmlsL3BmL3BmX3N5bmNvb2tpZXMuYyArKysgDQo+IGIv c3lzL25ldHBmaWwvcGYvcGZfc3luY29va2llcy5jIEBAIC0zMTMsNiArMzEzLDkgQEAgDQo+ IHBmX3N5bmNvb2tpZV92YWxpZGF0ZShzdHJ1Y3QgcGZfcGRlc2MgKnBkKSBhY2sgPSANCj4g bnRvaGwocGQtPmhkci50Y3AudGhfYWNrKSAtIDE7IGNvb2tpZS5jb29raWUgPSAoYWNrICYg MHhmZikgXiAoYWNrID4+IA0KPiAyNCk7ICsgaWYgKFZfcGZfc3RhdHVzLnN5bmNvb2tpZXNf bW9kZSA9PSBQRl9TWU5DT09LSUVTX05FVkVSKSArIHJldHVybiANCj4gKDApOyArIC8qIHdl IGRvbid0IGtub3cgb2RkZXZlbiBiZWZvcmUgc2V0dGluZyB0aGUgY29va2llICh1bmlvbikg Ki8gaWYgDQo+IChhdG9taWNfbG9hZF82NCgmVl9wZl9zdGF0dXMuc3luY29va2llc19pbmZs aWdodFtjb29raWUuZmxhZ3Mub2RkZXZlbl0pIA0KPiA9PSAwKSB8DQo+IA0KPiBUaGF0IHNo b3VsZG7igJl0IGJlIHJlcXVpcmVkIHRob3VnaC4NCj4gDQo+IEJyLA0KPiBLcmlzdG9mDQo+ IA0KDQoNCi0tIA0KTWFyZWsgWmFyeWNodGENCg== --------------snUu1J87zM0pGEKwNJnUWVep-- --------------Lg0N7bEEfhhztaGlbQeZa0qv Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmJxN58FAwAAAAAACgkQHZW8vIFppoKj ZwgAhhfGV0nHZDLk9AMkfsmvUDKMH9CqikEAtFaQccrVdpqoY4AjaJsmaR/Kz1WyAOVj0IfhzZXb 4QAUyO1IajHp1+z98mt3Gp0s1B69VbsInlRGFOzCyD8nCXT4MPSAG0rU2KX9iU9T70K5TgkaGIsq v4EQVHu6KuoXXh8Bk1FK4xdmzzoZ8FD5QSsWCYfN7ianb06ShLcn/K8+C3rH88ZN8GDlPuJ5aQtT vYGM9dP+vyWvGLEJSWU1twGBulbsZfEWPN9NUEi42Xq3i8Uuev7tSX4AYahmyvNsrOzwj0CF6jRu a1xLEuoo45bN4R4mJBO67mT+EhVbJw+VhbQ5wcDWtA== =E5na -----END PGP SIGNATURE----- --------------Lg0N7bEEfhhztaGlbQeZa0qv-- From nobody Tue May 3 14:46:48 2022 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 2CCA81AC655F; Tue, 3 May 2022 14:47:37 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kt2qr0rgwz3t6h; Tue, 3 May 2022 14:47:35 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fe6d03e.dip0.t-ipconnect.de [79.230.208.62]) (authenticated bits=128) by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 243ElE58078931 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 May 2022 14:47:28 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 243El8Nw082427; Tue, 3 May 2022 16:47:09 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 243EkmY5077471; Tue, 3 May 2022 16:47:08 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202205031447.243EkmY5077471@fire.js.berklix.net> To: freebsd-stable@FreeBSD.org cc: freebsd-current@FreeBSD.org, Eugene Grosbein , Ed Maste Subject: Re: breaking modules From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Fri, 29 Apr 2022 23:57:02 +0200." <202204292157.23TLv232063233@fire.js.berklix.net> Date: Tue, 03 May 2022 16:46:48 +0200 X-Rspamd-Queue-Id: 4Kt2qr0rgwz3t6h X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-0.15 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.95)[0.954]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[79.230.208.62:received] X-ThisMailContainsUnwantedMimeParts: N 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 Hi, Reference: > From: "Julian H. Stacey" > Date: Fri, 29 Apr 2022 23:57:02 +0200 "Julian H. Stacey" wrote: > Ed Maste wrote: > > On Thu, 28 Apr 2022 at 11:28, Julian H. Stacey wrote: > > > > > > but that's crude. It's nice to be able to build most modules ready > > > in case wanted later, so how about a DUDS env. mechanism like ports/ ? > > > > I'd rather not add additional complexity to our build infrastructure > > to address a situation that shouldn't exist. Modules should build & > > function on an ongoing basis (and, I believe they generally do). CI > > doesn't report any issues on either stable branch or main at present. > > I'm building stable-12 not stable-13. It's broken here. I've seen modules break > for years, I used to suspect modules werent built by default by > build engines as often as main src/, so modules had more time to rot against > changing includes & libs, maybe now build engines might compile > them as often as eg bin/ls/ ? I don't know; But I'm seeing modules breaks. > > I just refetched with git this mid Friday afternoon (TZ=+02:00) 12.3-STABLE > & the 2 breaks are still present. See below. > > Setting a MODULE_DUDS would save work rather than repetitively retro > patching out the same modules in Makefile after each git pull --ff-only. > > I'd happily develop a patch for sys/modules/, but if someone > else prefers to, that might increase the chance of it being commited. > I'd be happy to test or develop a fix for sys/modules/Makefile. Eugene Grosbein wrote: > Unfortunately, CI does not catch stand-alone module build failures, > out of kernel build directory. > > For example: > > if_em https://cgit.freebsd.org/src/commit/?id=c0460cf2e42d2819c1f191a1d6e1b3dc0c7ea010 > if_epair https://cgit.freebsd.org/src/commit/?id=7a382e744b0b0ba9b51dc34bfa0cd1515f744f25 > linuxkpi https://cgit.freebsd.org/src/commit/?id=f5a2e7b0e8483bf51519046fd149a6a31acef6b1 I developed a fix, patch appended, mastered inc. a mini test Makefile at http://berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/sys/modules/ Filed with https://bugs.freebsd.org/bugzilla/enter_bug.cgi as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263758 I added cc: current@, Would someone like to try it please ? BTW I've not yet but will later read how DUDS is implemented in /usr/ports/Mk/bsd.port.subdir.mk Cheers, -- Julian Stacey http://berklix.com/jhs/ http://StolenVotes.UK Kill / remove Putin: He kills innocents & causes global grain & fuel shortage. From nobody Tue May 3 16:24:24 2022 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 98EEF1AB74C2; Tue, 3 May 2022 16:24:56 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kt5076Hj9z4kL0; Tue, 3 May 2022 16:24:55 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fe6d03e.dip0.t-ipconnect.de [79.230.208.62]) (authenticated bits=128) by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 243GOoMp081457 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 May 2022 16:24:54 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 243GOiE3083190; Tue, 3 May 2022 18:24:44 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 243GOOjw078964; Tue, 3 May 2022 18:24:39 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202205031624.243GOOjw078964@fire.js.berklix.net> To: Eugene Grosbein cc: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org, Ed Maste Subject: Re: breaking modules From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Tue, 03 May 2022 22:13:26 +0700." <1143af76-e4fe-6169-0cc8-9397b54c2afd@grosbein.net> Date: Tue, 03 May 2022 18:24:24 +0200 X-Rspamd-Queue-Id: 4Kt5076Hj9z4kL0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-2.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[79.230.208.62:received] X-ThisMailContainsUnwantedMimeParts: N 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 Hi, Reference: > From: Eugene Grosbein > Date: Tue, 3 May 2022 22:13:26 +0700 Eugene Grosbein wrote: > 03.05.2022 21:46, Julian H. Stacey wrote: > > > Hi, Reference: > >> From: "Julian H. Stacey" > >> Date: Fri, 29 Apr 2022 23:57:02 +0200 > > > > "Julian H. Stacey" wrote: > >> Ed Maste wrote: > >>> On Thu, 28 Apr 2022 at 11:28, Julian H. Stacey wrote: > >>>> > >>>> but that's crude. It's nice to be able to build most modules ready > >>>> in case wanted later, so how about a DUDS env. mechanism like ports/ ? > >>> > >>> I'd rather not add additional complexity to our build infrastructure > >>> to address a situation that shouldn't exist. Modules should build & > >>> function on an ongoing basis (and, I believe they generally do). CI > >>> doesn't report any issues on either stable branch or main at present. > >> > >> I'm building stable-12 not stable-13. It's broken here. I've seen modules break > >> for years, I used to suspect modules werent built by default by > >> build engines as often as main src/, so modules had more time to rot against > >> changing includes & libs, maybe now build engines might compile > >> them as often as eg bin/ls/ ? I don't know; But I'm seeing modules breaks. > >> > >> I just refetched with git this mid Friday afternoon (TZ=+02:00) 12.3-STABLE > >> & the 2 breaks are still present. See below. > >> > >> Setting a MODULE_DUDS would save work rather than repetitively retro > >> patching out the same modules in Makefile after each git pull --ff-only. > >> > >> I'd happily develop a patch for sys/modules/, but if someone > >> else prefers to, that might increase the chance of it being commited. > >> I'd be happy to test or develop a fix for sys/modules/Makefile. > > > > Eugene Grosbein wrote: > >> Unfortunately, CI does not catch stand-alone module build failures, > >> out of kernel build directory. > >> > >> For example: > >> > >> if_em https://cgit.freebsd.org/src/commit/?id=c0460cf2e42d2819c1f191a1d6e1b3dc0c7ea010 > >> if_epair https://cgit.freebsd.org/src/commit/?id=7a382e744b0b0ba9b51dc34bfa0cd1515f744f25 > >> linuxkpi https://cgit.freebsd.org/src/commit/?id=f5a2e7b0e8483bf51519046fd149a6a31acef6b1 > > > > > > I developed a fix, patch appended, mastered inc. a mini test Makefile at > > http://berklix.com/~jhs/src/bsd/fixes/freebsd/src/gen/sys/modules/ > > > > Filed with https://bugs.freebsd.org/bugzilla/enter_bug.cgi as > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263758 > > > > I added cc: current@, Would someone like to try it please ? > > > > BTW I've not yet but will later read how DUDS is implemented in > > /usr/ports/Mk/bsd.port.subdir.mk > > I filled https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263750 > with a patch fixing standalone build of random_fortuna and random_other. > > Please test the patch in the PR 263750 and report back if it fixes the problem for you, too. Yes, I confirm the logic of your patch marked Comment2 2022-05-03 09:12:25 UTC lets both random_fortuna and random_other compile on my 12.3-STABLE. Thanks ! However, a patch quibble: First I saved the page with firefox, scissored the pre & post HTML crud, cd /sys/modules ; patch -p2 < ~/Downloads/263750.diff failed, so I hand patched. The patch command failed as excess spaces in the patch, original tabs lost. fetch 'https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263750' confirms unwanted spaces in the patch. There are tabs in 12.3-STABLE. Cheers, -- Julian Stacey http://berklix.com/jhs/ http://StolenVotes.UK Kill / remove Putin: He kills innocents & causes global grain & fuel shortage. From nobody Tue May 3 17:08:46 2022 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 BFB781AC2764 for ; Tue, 3 May 2022 17:08:50 +0000 (UTC) (envelope-from glebius@freebsd.org) 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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kt5yn4sNlz4tCc for ; Tue, 3 May 2022 17:08:49 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 243H8lTB002440 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 3 May 2022 10:08:47 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 243H8kSQ002439; Tue, 3 May 2022 10:08:46 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Tue, 3 May 2022 10:08:46 -0700 From: Gleb Smirnoff To: Florian Smeets Cc: Michael Butler , freebsd-current@freebsd.org Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored Message-ID: References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> <49214a89-28e6-acbb-b10d-38bf2685b78b@smeets.xyz> 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: <49214a89-28e6-acbb-b10d-38bf2685b78b@smeets.xyz> X-Rspamd-Queue-Id: 4Kt5yn4sNlz4tCc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [-3.10 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Apr 24, 2022 at 09:49:48AM +0200, Florian Smeets wrote: F> On 23.04.22 01:38, Gleb Smirnoff wrote: F> > Hi Florian, F> > F> > here is a patch that should help with the IPv6 problem. I'm not F> > yet committing it, it might be not final. F> F> yes, the patch resolves the issue. There is just one SYN packet, and it F> gets a reply immediately. Alexander provided a patch against the ip6_output inconsistency: https://reviews.freebsd.org/D35117 You might be interested in testing it together with my patch. I will commit mine only after Alexander commits his. -- Gleb Smirnoff From nobody Tue May 3 18:05:41 2022 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 1B48E1AB1A5E; Tue, 3 May 2022 18:06:14 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kt7F11sJjz3MnJ; Tue, 3 May 2022 18:06:13 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fe6d03e.dip0.t-ipconnect.de [79.230.208.62]) (authenticated bits=128) by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 243I67gk084277 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 May 2022 18:06:11 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 243I61ZM083864; Tue, 3 May 2022 20:06:01 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 243I5fOl080287; Tue, 3 May 2022 20:05:51 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202205031805.243I5fOl080287@fire.js.berklix.net> To: lwhsu@FreeBSD.org cc: Eugene Grosbein , freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org, Ed Maste Subject: Re: breaking modules From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Tue, 03 May 2022 18:24:24 +0200." Date: Tue, 03 May 2022 20:05:41 +0200 X-Rspamd-Queue-Id: 4Kt7F11sJjz3MnJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-1.21 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.11)[-0.108]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[79.230.208.62:received] X-ThisMailContainsUnwantedMimeParts: N 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 > From: bugzilla-noreply@freebsd.org > Date: Tue, 03 May 2022 17:20:14 +0000 > To: jhs@berklix.com > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263758 > > Li-Wen Hsu changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |lwhsu@FreeBSD.org > Status|New |Open > > --- Comment #2 from Li-Wen Hsu --- > Does WITHOUT_MODULES in make.conf(5) work here? Ouch ! Thanks ! I didn't know that existed ! I may have wasted time re-inventing the wheel, I'll look more at both. PS Seems to me a whole slew of that man make.conf more properly now belongs in src.conf ? Cheers, -- Julian Stacey http://berklix.com/jhs/ http://StolenVotes.UK Kill / remove Putin: He kills innocents & causes global grain & fuel shortage. From nobody Tue May 3 18:43:39 2022 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 012161ABC846 for ; Tue, 3 May 2022 18:43:42 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [209.51.186.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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kt84F1y78z3n65 for ; Tue, 3 May 2022 18:43:41 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.3] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id 15CBF314F8; Tue, 3 May 2022 18:43:41 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 15CBF314F8 Message-ID: <3b7915ac-261d-c547-d94a-a1030965cf9e@freebsd.org> Date: Tue, 3 May 2022 14:43:39 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: breaking modules Content-Language: en-US To: freebsd-current@freebsd.org References: <202205031805.243I5fOl080287@fire.js.berklix.net> Cc: "Julian H. Stacey" From: Allan Jude In-Reply-To: <202205031805.243I5fOl080287@fire.js.berklix.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Kt84F1y78z3n65 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 209.51.186.6 is neither permitted nor denied by domain of allanjude@freebsd.org) smtp.mailfrom=allanjude@freebsd.org X-Spamd-Result: default: False [-2.52 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[allanjude]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.99)[-0.989]; R_SPF_SOFTFAIL(0.00)[~all:c]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.44)[-0.435]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:209.51.160.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/3/2022 2:05 PM, Julian H. Stacey wrote: >> From: bugzilla-noreply@freebsd.org >> Date: Tue, 03 May 2022 17:20:14 +0000 >> To: jhs@berklix.com >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263758 >> >> Li-Wen Hsu changed: >> >> What |Removed |Added >> ---------------------------------------------------------------------------- >> CC| |lwhsu@FreeBSD.org >> Status|New |Open >> >> --- Comment #2 from Li-Wen Hsu --- >> Does WITHOUT_MODULES in make.conf(5) work here? > > Ouch ! Thanks ! I didn't know that existed ! I may have wasted time > re-inventing the wheel, I'll look more at both. > > PS Seems to me a whole slew of that man make.conf more properly now > belongs in src.conf ? > > Cheers, make.conf applies to everything you try to compile. src.conf applies just to FreeBSD's buildworld/buildkernel etc. -- Allan Jude From nobody Tue May 3 18:54:14 2022 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 D36331ABF9C9 for ; Tue, 3 May 2022 18:54:25 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail-out.smeets.xyz (mail-out.smeets.xyz [88.99.165.53]) (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 4Kt8Jc3STqz3q28; Tue, 3 May 2022 18:54:24 +0000 (UTC) (envelope-from flo@smeets.xyz) Received: from mail.smeets.xyz (mail.smeets.xyz [IPv6:2a01:4f8:10a:3543::25:3]) (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) (Client did not present a certificate) by mail-out.smeets.xyz (Postfix) with ESMTPS id C9CF84B5A2; Tue, 3 May 2022 20:54:16 +0200 (CEST) Received: from amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) by mail.smeets.xyz (Postfix) with ESMTP id B56B4B062A; Tue, 3 May 2022 20:54:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at smeets.xyz Received: from mail.smeets.xyz ([IPv6:2a01:4f8:10a:3543::25:3]) by amavis.smeets.xyz (amavis.smeets.xyz [IPv6:2a01:4f8:10a:3543::aa:4]) (amavisd-new, port 10025) with ESMTP id XTYsCv78h5df; Tue, 3 May 2022 20:54:16 +0200 (CEST) Received: from [IPV6:2003:cf:df49:c97:2537:c80e:1d41:3380] (p2003000631376c972537c80e1d413380.dip0.t-ipconnect.de [IPv6:2003:6:3137:6c97:2537:c80e:1d41:3380]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail.smeets.xyz (Postfix) with ESMTPSA id C2DF4B0595; Tue, 3 May 2022 20:54:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smeets.xyz; s=dkim; t=1651604056; 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=ygJshdmF9+g0p/oKkcJNdIAzZM7dgQUsDl6ykeZtH6I=; b=DZUaOTZFRjS/3cinWtu7r6wSxWAiP1u3OfPl61vMI3lFX2F6vgsXK8Jgy3TsgKr4BGoVd8 SZaemsSVbi4Uf053+5IMCQ3C/4WdxvMRUq8w1mnRgomBFac67vL+cW6vb57+OhJSIgzvx2 Wcag3wsHlRf+bTozXEw/his60C0iNktYWOU16+eAHuYuauuFYd/O25x4oIsZy/sbywCrcf wFALcJ1kujZ84drZbKT73zAfOJxw8nC6DjhlfENVBqu/q1PFUEG+OeJm6zbUV0f49Aw5pP WHhprZC/JlpmGMgJVIpgZgzDiVQu00FhGYaVNvRjnIlzhiGMRJ5Os3DeX9GHYQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=smeets.xyz; s=ed25519_2022; t=1651604056; 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=ygJshdmF9+g0p/oKkcJNdIAzZM7dgQUsDl6ykeZtH6I=; b=Vm+DLGTWAp1PUplHmcMvDAdYN9ZTXxxVYj57pIUj4/2dYgDs3LNYVTIm6A1TZ/Cu7TPn2N odybxX0NYsUfYtDg== Message-ID: Date: Tue, 3 May 2022 20:54:14 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored Content-Language: en-US To: Gleb Smirnoff Cc: Michael Butler , freebsd-current@freebsd.org References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> <49214a89-28e6-acbb-b10d-38bf2685b78b@smeets.xyz> From: Florian Smeets In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------M29Rh5tqDE77yI1HF6npJysM" X-Rspamd-Queue-Id: 4Kt8Jc3STqz3q28 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smeets.xyz header.s=dkim header.b=DZUaOTZF; dkim=pass header.d=smeets.xyz header.s=ed25519_2022 header.b=Vm+DLGTW; dmarc=pass (policy=reject) header.from=smeets.xyz; spf=pass (mx1.freebsd.org: domain of flo@smeets.xyz designates 88.99.165.53 as permitted sender) smtp.mailfrom=flo@smeets.xyz X-Spamd-Result: default: False [-4.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[smeets.xyz:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[smeets.xyz,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; MIME_UNKNOWN(0.10)[application/pgp-keys]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_FIVE(0.00)[5]; FREEFALL_USER(0.00)[flo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[smeets.xyz:s=dkim,smeets.xyz:s=ed25519_2022]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------M29Rh5tqDE77yI1HF6npJysM Content-Type: multipart/mixed; boundary="------------GR9u3C52wLdKPMow5vc0Sqd3"; protected-headers="v1" From: Florian Smeets To: Gleb Smirnoff Cc: Michael Butler , freebsd-current@freebsd.org Message-ID: Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> <49214a89-28e6-acbb-b10d-38bf2685b78b@smeets.xyz> In-Reply-To: --------------GR9u3C52wLdKPMow5vc0Sqd3 Content-Type: multipart/mixed; boundary="------------knZP9V0AZW0fWEdc2mYli3x2" --------------knZP9V0AZW0fWEdc2mYli3x2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDMuMDUuMjIgMTk6MDgsIEdsZWIgU21pcm5vZmYgd3JvdGU6DQo+IE9uIFN1biwgQXBy IDI0LCAyMDIyIGF0IDA5OjQ5OjQ4QU0gKzAyMDAsIEZsb3JpYW4gU21lZXRzIHdyb3RlOg0K PiBGPiBPbiAyMy4wNC4yMiAwMTozOCwgR2xlYiBTbWlybm9mZiB3cm90ZToNCj4gRj4gPiAg ICBIaSBGbG9yaWFuLA0KPiBGPiA+DQo+IEY+ID4gaGVyZSBpcyBhIHBhdGNoIHRoYXQgc2hv dWxkIGhlbHAgd2l0aCB0aGUgSVB2NiBwcm9ibGVtLiBJJ20gbm90DQo+IEY+ID4geWV0IGNv bW1pdHRpbmcgaXQsIGl0IG1pZ2h0IGJlIG5vdCBmaW5hbC4NCj4gRj4NCj4gRj4geWVzLCB0 aGUgcGF0Y2ggcmVzb2x2ZXMgdGhlIGlzc3VlLiBUaGVyZSBpcyBqdXN0IG9uZSBTWU4gcGFj a2V0LCBhbmQgaXQNCj4gRj4gZ2V0cyBhIHJlcGx5IGltbWVkaWF0ZWx5Lg0KPiANCj4gQWxl eGFuZGVyIHByb3ZpZGVkIGEgcGF0Y2ggYWdhaW5zdCB0aGUgaXA2X291dHB1dCBpbmNvbnNp c3RlbmN5Og0KPiANCj4gaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0QzNTExNw0KPiAN Cj4gWW91IG1pZ2h0IGJlIGludGVyZXN0ZWQgaW4gdGVzdGluZyBpdCB0b2dldGhlciB3aXRo IG15IHBhdGNoLiBJIHdpbGwNCj4gY29tbWl0IG1pbmUgb25seSBhZnRlciBBbGV4YW5kZXIg Y29tbWl0cyBoaXMuDQo+IA0KDQpXaXRoIGJvdGggcGF0Y2hlcyBhcHBsaWVkIGl0J3Mgd29y a2luZyBmaW5lIGFuZCBJIGNhbm5vdCByZXByb2R1Y2UgdGhlIA0KaW5pdGlhbCBpc3N1ZS4N Cg0KVGhhbmtzDQpGbG9yaWFuDQo= --------------knZP9V0AZW0fWEdc2mYli3x2 Content-Type: application/pgp-keys; name="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Disposition: attachment; filename="OpenPGP_0xEF5BA4DCD5A9F3C0.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFpyBwsBEADLq0c46orEtbMn4SptX+VJxR1wB4YwaErZme1bqF4nZHIhlRNE T22HsHdQdoagaB4uACq0Rj5kHcu614ZnnNkLPyCxWQATx+cbdiFO4/hfT8tAvKnB tiy3awKJ5uGCNO2EzJwXW6KwdDA8XPRySqN8m1yPl+dW0Cls+/vO/QL/6+YLMupm EpSvFxRzAZTQuKyX4+xl+dYId24JiPd1yfCuDNOY3+OZ3QBMT00u/699N8lUWRti TwaQMwAOww8r/26YM6/SgcgFuLH2E/CVplY0sDvfoISlAj8agxdomNXfPjCMQ6w5 yGZmA+huFpPCVBTi3on/SWgbQO7dLVpN4BNPuScPosCb/dsOg0S74zCClsIU3gdU Gh9rwJY00/Ebid6V0R3c1Czwbg8LQedzlGDuXYXmzp6W2ujgr1cqbUD6lUWikUv2 IMdCbb8MxYhHLi3GYUs5Xpi+W7vM6T45KbuMr7O/1SjtcGOlNeDvGNgjcDk20fOg PPZ+M6i9vX5Q2oI9HoYaeTiYNwILkBLVP/L40kTo5EkiQOt4OW6BMbylqXPOaQMW uGVbmhCJQpbx8Vo80s2yiBBVWkLkWQIcIm3KZlLldJqKEFpQBWLBE1eFFqboYgAW zFn73CaV5tihobijMmmOV3a8cI1fI4kREyl3g+8bW+O0u3m3tuzVOpDpjwARAQAB zSBGbG9yaWFuIFNtZWV0cyA8ZmxvQEZyZWVCU0Qub3JnPsLBlAQTAQoAPhYhBOyz aLh5CL+2kU1yae9bpNzVqfPABQJh8E3MAhsDBQkLM37BBQsJCAcDBRUKCQgLBRYD AgEAAh4BAheAAAoJEO9bpNzVqfPAOjQP/1FdgHTug7m1OGP3kz5xOID6cuSDUZ1Q eFNvGOU/g0qty1Bda9/dcRJjOdbtIkpPXPUbOZiZWFLABBo82lxufjso1uzwlvCZ q/qMYMtpTys8LZUVOrbVeUM8KKLHtLq2DL49Et8DqwENcxaPa604RExsfvrBAMwO WF6kH8DC4cbCi+2B335NUCFoM/qYC3Ph0bCrWu0lsiEd0G3WJ8Wz8OiEgD+muoQt aEMKkg6B97TaCvcLf25j6VO0bTiySM3e1RwNPaTyu9GSh5L7PThPE67HuA27NXoh +oHDVbdM475OGIQ8IAWvuPyEJ6R91IjpQFR3qiyWeppR1Ag5XoB1DpQv8fKu2bQz m7lQWC07djntw+ScxcDxiuj7+PL1ClKKjezTSmvjJEA6G3wB17MtSnI8TMVnPR1N GsShTY5Fl5ihyQw1wg2eJLXJg0rYLubhPhJiyoiGOIk1BR340Aben1qDC33V9Qo5 CKFlXizvFygdy3h/aIJeq9m2uQvQpPkMM4Ije2tmvlK+Q3HJki0OnbeGf4vJa/dB VdnjAp7idYaVyKhV4D3daH1zOTWwxLrSHOv5ixpR+ZCmG6nmApEKE2q5lm/bx5ZA XP9SSwyLdV22PUbuiNGZ5eJx/9lhuX16nVZ3F2xJZnJuqQV7kWxAedxwaN5P5U8K TPFPgLRAD9U0zR9GbG9yaWFuIFNtZWV0cyA8ZmxvQHNtZWV0cy54eXo+wsGXBBMB CgBBAhsDBQkLM37BBQsJCAcDBRUKCQgLBRYDAgEAAh4BAheAFiEE7LNouHkIv7aR TXJp71uk3NWp88AFAmHwTcwCGQEACgkQ71uk3NWp88BpTRAAybyHhteWLV4VDlzl 7NPxbN8c9cDDv1r0HlaUVxfrSw+1rzycEdhqA8o75Wh5II4KAFTbX2igGckskcoO dqm68MU8+zAtVxVZaqX+EGNXSLWZgAzlf9rAHDm/O1ZBShZhn9EJyarYPaSRNBev VaR9bY6LEFmDacb6qnRVOH4Z/6O6fq/IxoXQqyV1NDmmObxtCcxwx71v+7mJoBMT ximtdrPmcpGesCQquiWKa6DyYjZIEZ9gQPttLQ+iYmwWJp6q68VULqY9X0zG7byc 3Xe7W/5oEoTA/gSWG0EbPOdfTS77TTNxhgBzFB6VY81PVAYzH419Q0b055XLTupo +JTQUb6bbluH6UJIBtIp1iJlGN42qvkMwqTogIdat/3aA+EWEfG7iWlx8Z1hFU3r 7GMJ5o8QLsloVNWAda+iHaidIJvU1fJa0U9v2r1d/KwYHj2qlMaQMZHjldULp7LP P/pITeQEnma3mZ6IX7cp6mUd8MOiVTPE42fPs8qBHKfuEcg7L07NcdRzzgS0LGQf v6fbnvNnvsDGAt4zGQ/Hj72Z5/eL1sDnoJQUHNHMJlNJieGplbLm3LacNQZa9979 BjwK+mUr1nPaaP4YR3czfVwTMrxPKT9kFBDZL4YQ8LbsH5JJC3As3EJdptIkANSm +hU54sG8QPz6TDsm7754d1n12M3CwXkEEwEKACMWIQSnAQMgO8q0Spj+yETnBT35 /4bwdgUCWnIHOAWDB4YfgAAKCRDnBT35/4bwdmNtEACU20uv5Lvuit3DtzQ5m4eP HAQzdeg6Uqpm7nNHB0KKGPCtKmf55bDVHfVuKS1pu1jBXFxGKyEKY5+QaxVrt9Dl iDqfqEPDmIqDdG13ch0cV3lan+3Jli3M2OwsHNac72MPFp++eAUbA9wgn6y6GlJx 9/oCtDuY9FucpL/P8zMbH5f00qBEKsC+lq8u+ZY/7lPYdVaZl3doLZcGCCsgbLP/ ytJPc7qzbHrW1wa7kBFKPLUhAbDFWTQz8L8Zt3cCDoqCc3N0rLZ419LA3NgROek9 nXuti9RG0AofI6t8tMKFBJs1oE9jbs1iqWzG0HdI25U/I0euAUwJNlkVBDwQIOgw HzLYqdnmVJD9HWxMv0cKNY9xVZEnCem1JJaK/+9nrbUtOOvp7l7PWRSbePWYQRT3 KCDZuhl0I7A1qWX+SU28cuxRkxsVni6wvUKEkuxpT07A6XhMmLtGOJSpTDR/hsky gBCs1YSdDJe0NZleaBJ5LIJ30/p68qIm1cFFRLm1hi3bwuBiHq3/SYVTdUWAR/Kl 4xscL8o9f3A7J/npOU126Zn63ItMguHWrangJdTUUINUlF0wleTmZYpTP5+ck7gc Br05VZGWXyNTMYChzS0oQXHCZYdAV9YghRhj2PWKLGhmB8Z+1vo49o1AmGFswlZe TGwUZ2r3d7pZUF0N9zOkbs7BTQRacgcLARAA0es6bm/J0r+KPXOQPItnNuiCTnOM yHqgCvdwfigZskc8uXIVlMJUFhTAPiSHo1XWwq5k55f9rKDJWDVHIu6WfOxzpiNc 4jGWqGpDAYjyTyywAikxJ/Tb3vzUI0XYcLjYKsl4e1c040M06Owy6jHOBr3MtAKH iMtOUT9NQmjopUAFYFVG1NWHZnvukq03uPY08UEe+nsrRYd9X5NieWyCOFQDQAJm dR0dLZhHMGELPNB6W53EHPnhL3FtSrWZ9l9XHwBsAZcXbPGjrye+8AAmfjweIFLd 0yEIZgkN1l2NrpB1QU+J6aKc7HCRTMKqYrGb4CPtRK57VJtlmonGYwjV4Xg6uT8E kkjvhn8WcmBhHhSQSIPcn8pShxAIgfd1oHX78JeWH30hvsA/5Aa4qTe+c0eHtUGr cT5UCIzktTQGaBb5x1E8eSLAzuwNrZWdXdWq9XtCagwqccXNQHo2fy4T6JqSnknz U+vryQM6ruQtbdScaaDU9SpuycJpOKYlvckBhbM5b/0Jhw+VsB0iqL7Afsw6h4v4 8D30DeRb/zzWsaZ45gXPOuw1Uu15r4Al9e2ngs3mA5Ug8imi8I1JVdcQqCXtri+N QbNUHOsfs/NP6ThdQRDA0IAJ8ZnEQTG2fLX1uO+6ZnSu/4AQAe+xZIpcdRUnMg2O p31SKhoRsoYA+U8AEQEAAcLBhgQYAQoAJhYhBOyzaLh5CL+2kU1yae9bpNzVqfPA BQJh8E3NAhsMBQkLM37BABQJEO9bpNzVqfPACRDvW6Tc1anzwPfkD/4yF78b+PSP mDiAsOffMd+U53MhT1Rem+PWxChsn4VqMtLArcr+vxqYcTrZNtb5bsYQgDMz47Zl L1N67PWfe129btyTkOSzA56o0eSfl4mhGhnGQRYczxAHw2bN4JtCwZW7kwhqcGG3 nglWVG9O9GPerSl4c1PB5EYGUjNCL5mn7/kTwSxoNMjOhEsQS+HgjLoRHi7+jNQu VW5hY53wrkTH7itAZohHxYd+zifPciQyUQw4P0hWe0XSVcwJN+xz81NhA5X0L6jl sy9G8xQmx8k37BOTKAqatPIesSlk4lzTNuVXmnbrIGGsvzYO46sMZiT+EPnmcf3Y Aq6mMNidmlWoVyOBKnclLzmEj/gFceIVrGCPGtG9pEdXAbpnSnYZcet++HCS1bRH YMnrPxB7E+1Xy6GVvylfahIcsXMt1mpI0FKzuJcH8O4Asv+QsKY6Q4tcjSX0CROH EnGO9lIaNOA7nYXP5hsuyIjHkPRZ/VgrwD+/z9PUKszqyDBIpwf4Rk9Cmg8z2+TP xnooLMBnTAQPNYIiI9fMyWOHtfPkLIiGUtGBHb7LAQZ7Pxsi5fR36+crhwJiQhpM brthm4VE2pwKnMlohLXnxQtoMMfTw9jzCpTjwuEEFYIIEte8X5GyXItfAm4b9z77 5PDS0JZbUcHZ1sv65OP599IaYgf3rzJnIw=3D=3D =3DYr0r -----END PGP PUBLIC KEY BLOCK----- --------------knZP9V0AZW0fWEdc2mYli3x2-- --------------GR9u3C52wLdKPMow5vc0Sqd3-- --------------M29Rh5tqDE77yI1HF6npJysM Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE7LNouHkIv7aRTXJp71uk3NWp88AFAmJxelYFAwAAAAAACgkQ71uk3NWp88AU sQ//YEgP88Lgcm7YLiA2Wc/PfYo/Z/e7FxLprlwNj9XBn2/jJ2CrukFz4iSfQTxRxHuT2dN9wLXo ljVnq54Eo/FA7rJjP1oHjsIQz4guFPHVvTKcJPHxY2uvGO9QcMWHpD/9dtzbMy1g7FgfH32rYq1e tFUdhznC9rLwqNJ+DgYE4hCvGwVGLqhmoXnYr6Jldjgi0sFz/mLFMo50DeI1x7Xhp6DTvpHy17cL 2FjVMaRFzChAtEaR3eY9+hfSaJqJOzcrxiTL9mjV9NP4l6esAbDONyMwwmxzF1NdflZspKj495bp +1uXieRWwIXg+W9SyM1LoWSrT6K3BMNSdXYYERkTHCTw+HuZJjD2TSEnNuY1g84/K0hwJJ36yHfm RM6hSqqQkeB2BlgngjgpKZdW5DhFSoGluWpQ4qJFXGhK6SATpIut1p3FQncxiaT3Tw7XecodGnAp 6OkMPKL/RRQ9HeCY/2gHVohGazRS32y2CJL3yEKWvOPdxZVkAdgFDJmyqZATly6lZ/XhIDHjrID8 nKrnj5HR+XrcLa5olZ386MyYjf6keXIxQ6mD3vT7gN89vK0dsYT0dIkrmL98dN6aUDxpnLW90v3V Ij5peH+zbef6OAQFTX6ooHOH5IIIMb9dbSOSbB1TMW0cnKIcQHAuAf9pTYoj4lC9r094OmaGhYCd 8cE= =eYs4 -----END PGP SIGNATURE----- --------------M29Rh5tqDE77yI1HF6npJysM-- From nobody Tue May 3 21:56:55 2022 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 3B1AA1AC678F; Tue, 3 May 2022 21:57:28 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KtDMq11Qrz3Fyy; Tue, 3 May 2022 21:57:26 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fe6d03e.dip0.t-ipconnect.de [79.230.208.62]) (authenticated bits=128) by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 243LvL28090373 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 May 2022 21:57:25 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 243LvFO0085389; Tue, 3 May 2022 23:57:15 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 243Lut1R083899; Tue, 3 May 2022 23:57:05 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202205032157.243Lut1R083899@fire.js.berklix.net> To: lwhsu@FreeBSD.org cc: Eugene Grosbein , freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org, Ed Maste Subject: Re: breaking modules From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Tue, 03 May 2022 20:05:41 +0200." Date: Tue, 03 May 2022 23:56:55 +0200 X-Rspamd-Queue-Id: 4KtDMq11Qrz3Fyy X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-2.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-stable]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[79.230.208.62:received] X-ThisMailContainsUnwantedMimeParts: N 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 I wrote: > > > From: bugzilla-noreply@freebsd.org > > Date: Tue, 03 May 2022 17:20:14 +0000 > > To: jhs@berklix.com > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263758 > > > > Li-Wen Hsu changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > CC| |lwhsu@FreeBSD.org > > Status|New |Open > > > > --- Comment #2 from Li-Wen Hsu --- > > Does WITHOUT_MODULES in make.conf(5) work here? > > Ouch ! Thanks ! I didn't know that existed ! I may have wasted time > re-inventing the wheel, I'll look more at both. > > PS Seems to me a whole slew of that man make.conf more properly now > belongs in src.conf ? Thanks to Li-Wen Hsu :-) I read & tested the section of /sys/modules/Makefile .for reject in ${WITHOUT_MODULES} SUBDIR:= ${SUBDIR:N${reject}} .endfor & that code works fine with both 1 & 2 modules listed. The existing code is also lots smaller than my DUD_MODULES patch, that does not use the sophistication modern bsd make ofers. So I rejected my own patch, & closed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263758 Cheers, -- Julian Stacey http://berklix.com/jhs/ http://StolenVotes.UK Kill / remove Putin: He kills innocents & causes global grain & fuel shortage. From nobody Tue May 3 22:38:39 2022 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 5798D1AAFCE6 for ; Tue, 3 May 2022 22:38:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KtFHZ5fttz3LgX for ; Tue, 3 May 2022 22:38:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651617523; bh=vMQbYLt5dp5WNGsFjMRTEWy1oVp4booHFQCi+Lq0tPc=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Irb/avR8XyIVsyOFfRj8qIeYlN51nOAxhmQtBRuw41pxnQSAt8xMfjCxWK1Du56EMZ6YgJlNx52UDw89GaoYyf7AiKw7ghjn9Veq2Ris5cVYAJ6QoHJxEOSqheMc6b6+ee+8h60r9OBjO8qRlyGzgKIYKoJmDCfMZqqI4eFTxe/ExPXihNq6uACQu0NYMOh1UXKh0GTQI/g7pVAruUp0e4WjThmj45x9v5EBHRa5Krt3mfB6XFa1siV51CN6NxtkXW0Wea3rOXE4R5NopskSSkTUJY+WCo4PmvUiwC0g00qDwJmHbK75NoCq5rDouzcGWr8Lrw/7EGg0w8mhfyRgOw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651617523; bh=g7dPbeUTwRVd3NIDOKFAohD5qOHoGmjZov9iQpuOK9L=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=f/Dl6y0TvXb9Eg+mSWpBohq2rkSvQ/ouZaUzTq0IIKcEWJtiWrNKbp/trdTosnHTXD3aM9b2YQcvkIVBnmUMG6lkr5IocajX1FDoHkDCoW2G26OyrxbXcVNONA3f7OMbstIeYBUJnzqqTuPFOym12hr9Jo9ZIFAGzKuBrl5BFrou9nN4aZvrebIooPVNj49rG9qWHBcs2LiQ305Mihjj8swda6raI1rMPBjb120GlR0Mg3qinxIJpjjYrNKK/QuoUX9sXNPQwwrfOXspWE2nFyBE8M3Qg7Bi8trOqubCEPN/9zt3XKgehh+Mg40VAe9e1UfUT7WutYQHU5mc9TnGzA== X-YMail-OSG: E4_KDiIVM1n1iQ3HP6vvnMDQPN9XOBqtBU8ywV.4dTAcapRd7FJOWNqZNUq3yD2 Zo6sG.z38vgTTizTINlKZlew0IjLwz73BOHDHO2ijlPfMIaLzI8ML1pw87Z.7GielJrpMsF3WxZk ixWqYyGaeCYMRBdxrZQpL75fEtR9wXK7JdsZpfsNo3d9W8ypOCIX6DZGc8hgoWN5Gqd_YeOB9hvn R_JJzaJJayzh4Selfi3VriOcrobUc6HuGt7ALvTk.0bV30u3.qajzpTCZiVuxWXNn.8yFniYHyPd dRSvxRNhmuRfwLmtoOaYUJbqktJ.6SXcCiItOPrRbIMjAQ09FZV99QsswKINOkv50Fv2pjlj_Zyk fs5zkReJf6VXR9N4SP8PbmlfCPFOGes63fiHJOrA90JMlBW9rDOw0kQVQYlEUdkH2xjNJ_BejvKU FkVSGEknoEs4c_dIkfp0dyJT8_OcOERXfnyrRTzCPcWhiBCmiKsHsIe5WxfuLcWe00sH5q_03zMa yO5.fL4AnW1tD8f9qg_9RYH2cUhgJ_xV9d7xfPjpRdUSi7vCnk_cKGW.IhBndI4JvZhoCpoAJS_I uuk1rkyhdT8.DsYmaGM1b65JJcrlgbdXQsQbaQnpN0a9s.ZRmTy8fQQPKmtScp1nzWN4.XRUzi8Y mV2PeSZKtjNkwcJxHzKe9o8VCyFrlxNF8Oi2SkkLh58P3NwEIJyLiSNA32mqKWen5ufOrW5mv9m2 rdBffKvZDnsPZjN7_CUWM8vx8NiHplwVGfzAYEJNSppBFj2YYSMq2GZh0OM6jw53LaSmSmlCGJy5 O8UWzorR9nF9_U51XU4juoDIRdS1Ye74LqU5HHU.l7vHH_aKQ5lmS0IqieX4aeu5t3ewEcZ2ldd6 938R9omNlBDTwgdP.rm5nlCGWKVgXdKTMwR_IUEtv8AlfBFQSI6O7qs9mb7XZV5oVmb_h6hVRRoj .2elVfMZIRHWDeeyuZHOBxbs7J_r1czeFenDZ95y6dSqBB0GOSQylHLDGFSQ13Q4Toi1gLZfnPA. 2YWgtKr6swI4R4WrRFQDcALgE_3YNUbuxMBS2k3BRaykwcvFto5aZHLib3Gv_EuxzfO8CAdSk.ZA TpxLAiUSi42zyGfNdkVc6IAy7b9Q5acTe9C9Uq3AkKjlamgflheRsEYYUYQgLIr2nvcZahHQsNTS zXZEP4_gm2bacSSLcc6ACIhY7q.rWJUoMAZfnSsl5QnqKtJbJ6c9yoa_On42TCMuqG_0H2IZL7nh R1WEuCugwnwdmOXv3RjTxWlgCar7P8apL4snF8NQbSBHVrg5QFzz1g27SdihY62OG5YeU5WlymA1 56PUWUMUXKB8LM_4cX8wZCUWx.WRCkfa0t.6QLAVeDezVzM5MRHarVJFaN9nIpxWdDI51zSKebY2 QfgGBCo2rkGngCSHtOwxgk4uVFy.X2dtttqnpjj_6x6VQskihlXkgjCcM_kinew6dm_SGLjAArgi nnoTeUkbk64Zq1zhGhaumqG_rDAvVcNcFBInfe0d0HvcLLLW9ldF_mP53KA9Sxd5z3B8q__tZyhx QNTfOi3AcHeF54lxOOkI9g9duw2Myiv9Y2N9NtcKNZJw3S3sx_AcKfCq4BoJ__uC_6RPU4fQHDqI i2NdkNH5zxum0UTmzK6SlDbxef5IdGcN3_OivhhX2Mel7usuEmqqiTY4eg9_d0MT7bjkGzoyLvIj M8a95Ghwd32LvSjdA14ZQfuVoelXrerfPx6uFKBC7B3mxdeTwCsNOfSxZwDiH1LY.GtSYY1RsMEu oXA1rx_zxM1pP.c1aoxasi.J7op2Dsje4IlnAYIwlw5jlSxpPeawpnwTKdSwmAHefhAQLHIUQzl0 Y3TeK1vTHip_Y.7QYMOAkknUgg9.8z0t6SJnnWRe8A.0NTuCdloUWhJTEG0gTGgUe8nQoRS160dA Rvuu49NrCOukXr7eHCOx4tAY7iEapaj3S36oKqcMDFMyHAX1LRjO6pBtuhp5SLZpndLImFNAfPm4 Ib2ucpuzAfWtR.sE3MFUO5_zxmiOHwWz.IH5NYFGlVLL9Jc_Ta939EXMn5yHROrPjAbWMWNjUM2l L01fDASOX4PUrBz1N_fZNsKSVtCrRP.FSa9KKsdb2AJq0Kzlv1AnL2F.4O5jxSkEOih_sXd01pHY 7KqSECIW7AoZ9ZEtkVtiCgwpXvIrd7tTNpKwah6FT7PsdJBGTK70wJIRdLejOUw3z6_VP.JsROyN tRDhRaXDLiGsIw2kHXHaKixIB4cwgWUKKIq2XCt9.JAjoC4VeD9ABod8CAx70ioBanaVQ1DP8Pox 49g2t X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 May 2022 22:38:43 +0000 Received: by hermes--canary-production-gq1-647b99747d-7f5lh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6da7e76a8e67d4358cf2797005743a74; Tue, 03 May 2022 22:38:42 +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 14.0 \(3654.120.0.1.13\)) Subject: aaarch64 main 9a3583bfbd17 debug build broken: "clri.lo: No such file or directory" so "make[4]: stopped in /usr/main-src/rescue/rescue" Message-Id: <1E666CF2-AC41-42EE-AD2E-1BF1D8E00818@yahoo.com> Date: Tue, 3 May 2022 15:38:39 -0700 To: freebsd-current , "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <1E666CF2-AC41-42EE-AD2E-1BF1D8E00818.ref@yahoo.com> X-Rspamd-Queue-Id: 4KtFHZ5fttz3LgX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="Irb/avR8"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.99)[-0.992]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ branch: main merge-base: 9a3583bfbd1740a158b3916432286190e0f2bf60 merge-base: CommitDate: 2022-05-03 19:12:42 +0000 9a3583bfbd17 (HEAD -> main, freebsd/main, freebsd/HEAD) OpenSSL: Merge = OpenSSL 1.1.1o n255160 (--first-parent --count for merge-base) got: --- all_subdir_rescue --- Building = /usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc= ue/clri.lo . . . --- all_subdir_rescue --- --- clri.lo --- clri.lo: No such file or directory . . . --- all_subdir_rescue --- *** [clri.lo] Error code 1 make[5]: stopped in = /usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc= ue .ERROR_TARGET=3D'clri.lo' = .ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64= .aarch64/rescue/rescue/clri.lo.meta' .MAKE.LEVEL=3D'5' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose curdirOk=3Dyes' . . . --- all_subdir_rescue --- _ERROR_CMD=3D'cc -mcpu=3Dcortex-a72 -target aarch64-unknown-freebsd14.0 = --sysroot=3D/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64= /tmp = -B/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/usr/b= in -O2 -pipe -fno-common -std=3Dgnu99 -Wno-format-zero-length = -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type = -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter = -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition = -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-variable -Qunused-arguments -static = -nostdlib -r -o clri.lo clri_stub.o = /usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc= ue//usr/main-src/sbin/clri/clri.o; crunchide -k _crunched_clri_stub = clri.lo;' = .CURDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/= rescue/rescue' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/= rescue/rescue' .TARGETS=3D'exe' = DESTDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/= tmp' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm64' MACHINE_ARCH=3D'aarch64' MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/usr/main-src/share/mk' MAKE_VERSION=3D'20220418' = PATH=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp= /bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/us= r/sbin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/= usr/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp= /legacy/usr/sbin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aa= rch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/= arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-= src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/main-src' OBJTOP=3D'/usr/main-src' .MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk = /usr/main-src/share/mk/local.sys.env.mk = /usr/main-src/share/mk/src.sys.env.mk = /usr/home/root/src.configs/src.conf.CA72-dbg-clang.aarch64-host = /usr/main-src/share/mk/bsd.mkopt.mk = /usr/main-src/share/mk/src.sys.obj.mk = /usr/main-src/share/mk/bsd.suffixes.mk = /usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk = /usr/main-src/share/mk/src.sys.mk /dev/null rescue.mk' .PATH=3D'. = /usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc= ue' 1 error =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue May 3 22:44:55 2022 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 5F33B1AB1CF6 for ; Tue, 3 May 2022 22:45:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KtFQr1wC1z3Nvq for ; Tue, 3 May 2022 22:45:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651617900; bh=p5/STqFZCgEXmDppyTj7ZB2+IKgSzjyq4vK0JIVmMzw=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=fePBV1sUBW1shwwTQHL9e4Rg61qbFXd252HURoq2XXz+qhhAtHQd7xsfKWaU363LDTVpAf9Lxh4H4bSenD0ajDwnFni7+2artY1twW6MCyMZSIGCUsDALW2OcG4dA2FlBoNXmGCDbJiy0iXV7nuF+jFEaLlzyUJVosxoO+I4EnBHjpb42LtHRbCZxyI7xGfrzXIot19enyF28SM20d76ZLC/tQpsCO0maeaUegaOYqW9kiOD4tE/gV0clOUahkVjAqNGKzMoYcPRLxSA8piT5dYZKO6+ut4C1QCTzqeac/G7aCkOhQAO8aRuQu4kWKcHeIX0EO3qf1HdELDiQLfRFg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651617900; bh=T6EhH18PIJNStkKJjFczcgg7WiAg4OTCguIche/gx6J=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=PzpAnYtDgL77FHLDY3ALP3XdJvzI2LJjIS5g5T5TCsklOgj+fj9cVqBMMIZhuUY+Iqsxzr+FzoCtr0ZQKf1IWrhCLIuzmfGNkBHBBGtL5TBCq54Fp0Vdh4x5HfCFNZ7qYnFhmQ7BRQCtvV1KNGnZ4i42+buuQv8Swe+uhm57aGjgHolrJDvV2X5LLJ85EjdUO5L46OKOg4XI1Frzd1GIllP+rdkvU+YugBLaChk7dKMW+vVFAIqRgkMfj3RpQjm3+/9i8CUS3LFkOFR2gP5ysfZB4G/Kx+JRviuwRKkZkVlMmhEj5/XJCwZ8LqsGkOFzwEv+pvG6ugDAAbEP3wskfA== X-YMail-OSG: DugEAMgVM1nbuqp93IpyQSisQgw.9zTt3XdiAX7Zf9pJ.U_Ssd62Oq93lSEFQsy lCer90v1Fg29jG_CgaKu4U3Rbs13VZcKOv3_lNo06dETW4u1KLx_ZzMwXF7xAGwkZX7Yk9cbovBR PwU369AicChwaROAgailrJWw1xRQRnL9Kg_7FwEbCp9JGrOpgL5bBLd5876oWtGVSEyqjKPcgRUw laeWr5Dlb_qaWcONSS_p9L4imQqvZ47EN14_eAY34eF8Vg6C2P4wcJ3WQvonR4tbcFg8lPHx_HIK UF3bFTZ18U_CDBWWxtZAtyNzDxvqoVhRpToGZx3vFTSS_8NZ3bJXGTMUZK5txt9e86es7Owwv5f9 iiFUWTwLMZTcQ6j6PZeZ6_qPQlAMqC9ZeEvmQkmVq9hjCEkX1k8EjJtV1RJoz_DdWvZLdmQwIUuB 0lj.bIyMK14pC4_J7F.ysPLlAjajHrx2Yh6LP4Q.gK8E0aRxrlk4_9mzIgjURSqam7t2N3m9lPHR s3omis8u1kYP_FdWz8YM1AOuvhdWWJOx0ZORRWt8e_It_AFegSq1K864M_Pd.7mo_7EeS3Tje5W_ 2JXUHt7kBFACROfxCktpxem6jrG89XYYNiIYZQ3bSweK8girWoHwAzUU4dugfi0vCpABljOYcetS v6tuFhXnJIu13kjaj0wuBLTGPAsEulvaHBvHOu1sytJhDqopekdOgByRmkIU1dFrmlrkzKrom_Gh sBR.YBkoI9jBd3aRSdggO8hun2Jd6z5acsSKCHfWk8oSLKkY4a5ukSi4sp5hqXMCGJd03nRNxByN Rj2jxGmTz_xAP7NFsSM7sz5p2OB0bAaJoNFCgZ_GTviH_khaJOoViRfYEZebU20wK2d.hfB0dYtK 18SnOLMIvzhq4sTSVUgHPracs6wGCRwJ21DtnJGq3CWzXLTS7YleCxoZ43IiS85PtjBbQryQgDeq tAmEctkAlZRmpdiH2QFOQRSSukYVHQpHox6HAqW.Qr2BgfG788eby5O31ymLnS8EJ4KCvZ.lamVA BaMSTselvY59HQ.vcULq0zuwIpqHDKve19hgeuI.PhcUKBv_8wnNz3ddsIcA.rhoqckBk5lR5P91 lF2xhKHnSjoOjrwzzSltIJtvoTO5LePlvmrUm621jvTlXAqoBHmdsT_1_WgpJMtxMxXoiZz3aK3R DA.SYZZiHUfYQnc4sr3_l8P8ociLTUNdaIBw5mEB3WhpgCwJsELCIcBaWyubG3DkScrBPMFbdBRO Rr4WnekRoycyZtx.hvajaEwZSmuM0ZOP7OSbw4iF_Z..RNcIzC4uLjdSm8LqsDVKZmoB6d7DC20f pIxAbpbwZhEFzsH8eyayusK.cP4dauSv_mKCjSKP_vN1.zvKaplzimOvuEX35TG.fmoIHBmiiUVC 7sUB268TCI1PsRPRzDwKtPpjPFJdG6uFTV3c6nE4J7jFaxO8In60htRMqzMkafyA3J1r4dvZ7Kqw 79pjOHYX7GXRHnOHDwvrGtTeHth10k8JeJDTZ7A7CGNQbkzeumDSi_U5BEhmnuQ_z5tTBzNzak7v 8pwXTpjx4mf1JVKaOTk4ILJ28Qs0wrMXfQP9FWVGZ.n4pTCA_55N1UrzEwlfDq4L60IWiPvdWReH .K6gC8N3zgzNiRoAGQiq3VCcXQMqhegunn_PO7xytY4qnYp4PLM7ycPhVCihXXQCFLXeKhCc8lEj FlKXTdSkjb95dQdWOzmdmuN_jWaMrd7NEiadSyv1SmFlnc_CmnegQ9GleFQWM0exHL2jVZcZai2j sy8xLwewZ0rMPmlcE7FvBDmxq8lq5rCvVRs1oPPVZzT9h6asBbgntFhCZzAwPaPvBJ4trKeM4fRX SPgidJQGi3VkZEyL4XlvNUC35AnqRtFHTg6NhSO7bz8UdCwWK0pTpIw5DhYxRGvtO17GRIBzuUkr 8pGmj5xUbz9ks6R7d_V1pDIbKIjcy5S3mSY1MJTCT58robd9MxnBJH6IntmOlcF.MR.tedy_ifZQ znM2ZvSP89.ouuv0dwK8fIUi5chLAzV4Mgy8kHCE.LqLnjY28FEpvYQpd6fyA3iZG2mxd7iMXgom 9MBnYXonzGpo1w65qDy8NMB92n2c3sXDMd8ZnmwqCho2CZGXR7w5GmHrvDlL0uzYye4rRUnV5mwT XEqMSCcCiDmZqQZs.PvgCj948iPuwQb3a5lgCgAax2aJAPmQUMVnGtUClxClrY5vHDa4aJUOrJGB XoraDTikvje.mZDeyhyzAZm9LKBw1fHjx7rVKfIAIdOqfFEznGL114_ZY_fpArfS4etyTe3Ay.JW K5AWBUA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 May 2022 22:45:00 +0000 Received: by hermes--canary-production-gq1-647b99747d-xkjwp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cc0d3885b5e6e89156121fc595cfd2b3; Tue, 03 May 2022 22:44:57 +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 14.0 \(3654.120.0.1.13\)) Subject: Re: aaarch64 main 9a3583bfbd17 debug build broken (race?): "clri.lo: No such file or directory" so "make[4]: stopped in /usr/main-src/rescue/rescue" Date: Tue, 3 May 2022 15:44:55 -0700 References: <1E666CF2-AC41-42EE-AD2E-1BF1D8E00818@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <1E666CF2-AC41-42EE-AD2E-1BF1D8E00818@yahoo.com> Message-Id: <7363F687-5F17-4A6B-9436-B13C4545B527@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KtFQr1wC1z3Nvq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fePBV1sU; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.17 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.69)[-0.691]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-0.98)[-0.978]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N [Looks to be some form of build race.] On 2022-May-3, at 15:38, Mark Millard wrote: > # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ > branch: main > merge-base: 9a3583bfbd1740a158b3916432286190e0f2bf60 > merge-base: CommitDate: 2022-05-03 19:12:42 +0000 > 9a3583bfbd17 (HEAD -> main, freebsd/main, freebsd/HEAD) OpenSSL: Merge = OpenSSL 1.1.1o > n255160 (--first-parent --count for merge-base) >=20 > got: >=20 > --- all_subdir_rescue --- > Building = /usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc= ue/clri.lo > . . . > --- all_subdir_rescue --- > --- clri.lo --- > clri.lo: No such file or directory > . . . > --- all_subdir_rescue --- > *** [clri.lo] Error code 1 >=20 > make[5]: stopped in = /usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc= ue > .ERROR_TARGET=3D'clri.lo' > = .ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64= .aarch64/rescue/rescue/clri.lo.meta' > .MAKE.LEVEL=3D'5' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose curdirOk=3Dyes' > . . . > --- all_subdir_rescue --- > _ERROR_CMD=3D'cc -mcpu=3Dcortex-a72 -target = aarch64-unknown-freebsd14.0 = --sysroot=3D/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64= /tmp = -B/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/usr/b= in -O2 -pipe -fno-common -std=3Dgnu99 -Wno-format-zero-length = -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type = -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter = -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition = -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-variable -Qunused-arguments -static = -nostdlib -r -o clri.lo clri_stub.o = /usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc= ue//usr/main-src/sbin/clri/clri.o; crunchide -k _crunched_clri_stub = clri.lo;' > = .CURDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/= rescue/rescue' > .MAKE=3D'make' > = .OBJDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/= rescue/rescue' > .TARGETS=3D'exe' > = DESTDIR=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/= tmp' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'arm64' > MACHINE_ARCH=3D'aarch64' > MAKEOBJDIRPREFIX=3D'' > MAKESYSPATH=3D'/usr/main-src/share/mk' > MAKE_VERSION=3D'20220418' > = PATH=3D'/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp= /bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/us= r/sbin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp/= usr/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/tmp= /legacy/usr/sbin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aa= rch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/= arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-= src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP=3D'/usr/main-src' > OBJTOP=3D'/usr/main-src' > .MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk = /usr/main-src/share/mk/local.sys.env.mk = /usr/main-src/share/mk/src.sys.env.mk = /usr/home/root/src.configs/src.conf.CA72-dbg-clang.aarch64-host = /usr/main-src/share/mk/bsd.mkopt.mk = /usr/main-src/share/mk/src.sys.obj.mk = /usr/main-src/share/mk/bsd.suffixes.mk = /usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk = /usr/main-src/share/mk/src.sys.mk /dev/null rescue.mk' > .PATH=3D'. = /usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/resc= ue' > 1 error So I started another buildworld buildkernel , letting it continue from where it had gotten to. That build completed. So: Possibly some form of build race where clri.lo just was not ready yet when it complained but was in place for the 2nd attempt. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed May 4 07:49:26 2022 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 B3D1D1AAAB1F for ; Wed, 4 May 2022 07:49:43 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (venus.morante.net [63.247.147.163]) by mx1.freebsd.org (Postfix) with ESMTP id 4KtTWB4g3lz3r35 for ; Wed, 4 May 2022 07:49:42 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (zenon.morante.com [192.168.0.233]) by saturn.morante.com (Postfix) with ESMTP id DB51911F80B for ; Wed, 4 May 2022 03:49:33 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on zenon.morante.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SPF_PASS autolearn=ham autolearn_force=no version=3.4.5 X-Spam-RelaysUntrusted: Received-SPF: pass (venus.morante.net: 192.168.0.2 is whitelisted) receiver=venus.morante.net; client-ip=192.168.0.2; helo=[192.168.0.2]; envelope-from=daniel@morante.net; x-software=SPF Validation 2.001 http://pacyworld.com/spf with libspf2-1.2.10; Received: from [192.168.0.2] (my-room.morante.com [192.168.0.2]) by venus.morante.net (Postfix) with ESMTPSA id 529D711F809 for ; Wed, 4 May 2022 03:49:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morante.net; s=default; t=1651650573; bh=TYvz95aARXYIUhRGPlOfMxLg8H9t3eNXbw0adciB/+Q=; h=Date:From:Subject:To; b=sP0aq+1nb6Rfy7QNPUZA88/DZFHrc/LuiK/RDyzm8b9yWtaUH6LznQFVJoBlZeroW d72A6XN8n/h0K0VUvdqLVrx6TTi3NMamkM6PI0Xcsrer2hIIUiQE6ytYbZXTiyr3Jn 0/eFZOBRZ+tPlQBiC7FNcwMwERSEZ4cWXk3/X3hI= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.104.2 at zenon.morante.com Message-ID: Date: Wed, 4 May 2022 03:49:26 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 From: Daniel Morante Subject: Testing 14-CURRENT-f44280bf5fb on aarch64 To: "freebsd-current@freebsd.org" Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KtTWB4g3lz3r35 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=morante.net header.s=default header.b=sP0aq+1n; dmarc=pass (policy=reject) header.from=morante.net; spf=pass (mx1.freebsd.org: domain of daniel@morante.net designates 63.247.147.163 as permitted sender) smtp.mailfrom=daniel@morante.net X-Spamd-Result: default: False [-3.84 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[morante.net:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[morante.net:+]; DMARC_POLICY_ALLOW(-0.50)[morante.net,reject]; NEURAL_HAM_SHORT(-0.94)[-0.941]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:30221, ipnet:63.247.144.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I have been testing 14-CURRENT-f44280bf5fb for the last few days and so far it's been okay on my hardware (Cavium ThunderX2). Most of the details of the system are saved in http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-f44280bf5fb. I've only had one kernel panic (seen under panic1.txt). I'm still using the sysctl option "hw.usb.disable_enumeration=1" to prevent the USB devices from disconnecting/reconnecting every few seconds.  Other than that the improvement in stability with 14-CURRENT on aarach64 on this hardware is much better since the last time I tried, back in late February 2022. I figured I would share my experience since I don't know what's the best way for me to help with testing new hardware with FreeBSD (besides opening PR's for hardware that's not detected). From nobody Wed May 4 08:10:17 2022 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 F24791AB0DC1 for ; Wed, 4 May 2022 08:10:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KtTz15y6gz3vBg for ; Wed, 4 May 2022 08:10:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [176.74.213.87]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id ED10C260189; Wed, 4 May 2022 10:10:18 +0200 (CEST) Message-ID: <61edce0e-948a-d9da-47b9-090a9201694e@selasky.org> Date: Wed, 4 May 2022 10:10:17 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: Testing 14-CURRENT-f44280bf5fb on aarch64 Content-Language: en-US To: Daniel Morante , "freebsd-current@freebsd.org" References: From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KtTz15y6gz3vBg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.29 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.993]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/4/22 09:49, Daniel Morante wrote: > I'm still using the sysctl option "hw.usb.disable_enumeration=1" to > prevent the USB devices from disconnecting/reconnecting every few > seconds.  Other than that the improvement in stability with 14-CURRENT > on aarach64 on this hardware is much better since the last time I tried, > back in late February 2022. Hi Daniel, Could you try the very latest 14-current as of now? I've made a couple of USB fixes which may fix the issue you are seeing. --HPS From nobody Wed May 4 10:19:41 2022 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 9B2641AB1E93 for ; Wed, 4 May 2022 10:20:04 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KtXrg3l7gz4mvp; Wed, 4 May 2022 10:20:03 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fe6d03e.dip0.t-ipconnect.de [79.230.208.62]) (authenticated bits=128) by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 244AJvqq036444 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 May 2022 10:20:02 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 244AJpAA090386; Wed, 4 May 2022 12:19:51 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 244AJfSd094471; Wed, 4 May 2022 12:19:51 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202205041019.244AJfSd094471@fire.js.berklix.net> To: Allan Jude cc: freebsd-current@freebsd.org Subject: Re: breaking modules From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Tue, 03 May 2022 14:43:39 -0400." <3b7915ac-261d-c547-d94a-a1030965cf9e@freebsd.org> Date: Wed, 04 May 2022 12:19:41 +0200 X-Rspamd-Queue-Id: 4KtXrg3l7gz4mvp X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-0.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.48)[0.484]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-0.87)[-0.873]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[79.230.208.62:received] X-ThisMailContainsUnwantedMimeParts: N 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 Allan Jude wrote: > On 5/3/2022 2:05 PM, Julian H. Stacey wrote: > >> From: bugzilla-noreply@freebsd.org > >> Date: Tue, 03 May 2022 17:20:14 +0000 > >> To: jhs@berklix.com > >> > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263758 > >> > >> Li-Wen Hsu changed: > >> > >> What |Removed |Added > >> ---------------------------------------------------------------------------- > >> CC| |lwhsu@FreeBSD.org > >> Status|New |Open > >> > >> --- Comment #2 from Li-Wen Hsu --- > >> Does WITHOUT_MODULES in make.conf(5) work here? > > > > Ouch ! Thanks ! I didn't know that existed ! I may have wasted time > > re-inventing the wheel, I'll look more at both. > > > > PS Seems to me a whole slew of that man make.conf more properly now > > belongs in src.conf ? > > > > Cheers, > > make.conf applies to everything you try to compile. > src.conf applies just to FreeBSD's buildworld/buildkernel etc. Right. But some parts of `man make.conf` such as WITHOUT_MODULES & BOOT_ are heirloom text, just for src, not src + ports, not yet moved to newer `man src.conf`, where they would be easier to discover. Cheers, -- Julian Stacey http://berklix.com/jhs/ http://stolenVotes.uk Arm Ukraine, kill Putin mass murderer causing global grain & fuel shortage. From nobody Wed May 4 13:12:09 2022 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 AE8051AB19BC for ; Wed, 4 May 2022 13:13:06 +0000 (UTC) (envelope-from f451@imap.cc) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (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 4KtchK62wrz3DSc for ; Wed, 4 May 2022 13:13:05 +0000 (UTC) (envelope-from f451@imap.cc) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 7B64B3200904 for ; Wed, 4 May 2022 09:12:59 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute3.internal (MEProxy); Wed, 04 May 2022 09:12:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imap.cc; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm1; t=1651669978; x=1651756378; bh=vKvvFJuMgs ZYL4cJGtFKXMNglLQQlaYVdmag6FNVhfY=; b=Xjv/57DG6GzxO/CCrZZmLFglPo JZws/YTreXQeaLhqVGPGHzeskMDs8Bm77be8KSRMWxVsiQ5XnMKR59hfIX6iNpzJ AFn9G5vGnGz+tclvfpmppGHPVSr60N/dyvP0W1HArmSbxq0QeTO7V9rP9yol5p00 kN5F8u1pOLupFqisj7xt1KywvlBQfv5dS7d8TVxnPprX+/W58GI+EHLO61N+jfbx R4c6tnzUXyCvKyGwYkdMDsnE/zKnYmNbtqWlxV0Z9vGNp9DpNBDFHWIWBM3cnAT8 45emYKnNS46idfZquW+00uUZxpCSDYwLz7hSAuLvuQK716fY3hwwQkHYtttA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1651669978; x= 1651756378; bh=vKvvFJuMgsZYL4cJGtFKXMNglLQQlaYVdmag6FNVhfY=; b=K Qk9xDBWLTcFkp7NB1RLja1WbQC+DgrxsdjygtDXZ2Z963FCU8jm5npeunoSAiiTv 7msOzo2UyDvLoBVH2f28oIEfgjSjNgOEjmtmo4svLy4XDKFWMHjwgFSenqvvRW4P oJd6ru7Z9IDYk6w2b/80s7NGRbWnq7li+sK3Nz67gpH/+8Fc4sHO86yD+mAc3YBa Ju4IdOqjRfTEmLw13uNhA+Sc4PTyiHWCjv1lzUUJPEb9wf/XdeJwOGEv3Jcax29X a4cJdL+laQq3vXuzRrpudhbKOCoKXkt3rjgZ/ytzvG/Add5z92VAG8DE2p4cGxEf U1VWLCkasVq4UX47Hztdg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdelgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecufghrlhcuvffnffculdduhedmnecujfgurhepofgfgg fkfffhvffutgfgsehtqhertderreejnecuhfhrohhmpehfgeehudcuoehfgeehudesihhm rghprdgttgeqnecuggftrfgrthhtvghrnhepvdeutddtffefffekgfekleduvdevtdegue fftefftdeijeffteejfeegvdeijeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepfheghedusehimhgrphdrtggt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A9C322A2005D; Wed, 4 May 2022 09:12:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 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 Message-Id: Date: Wed, 04 May 2022 13:12:09 +0000 From: f451 To: freebsd-current@freebsd.org Subject: is gptzfsboot relevant on arm64? Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4KtchK62wrz3DSc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=imap.cc header.s=fm1 header.b="Xjv/57DG"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="K Qk9xDB"; dmarc=pass (policy=none) header.from=imap.cc; spf=pass (mx1.freebsd.org: domain of f451@imap.cc designates 64.147.123.20 as permitted sender) smtp.mailfrom=f451@imap.cc X-Spamd-Result: default: False [-3.06 / 15.00]; XM_UA_NO_VERSION(0.01)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20:c]; FREEMAIL_FROM(0.00)[imap.cc]; TO_DN_NONE(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[imap.cc:+,messagingengine.com:+]; DMARC_POLICY_ALLOW(-0.50)[imap.cc,none]; NEURAL_HAM_SHORT(-0.97)[-0.975]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[imap.cc]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[imap.cc:s=fm1,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N Hello, On arm64 I have this:- % uname -KU 1400057 1400057 % man 8 gptzfsboot No manual entry for gptzfsboot % Is gptzfsboot only for certain archs? I only query it because recently z= pool offered an=20 upgrade and suggested looking at it. I see that man 8 gptzfsboot is avai= lable on=20 13-stable on amd64. --=20 =E2=80=9CWhen they give you lined paper, write the other way.=E2=80=9D =E2=80=95 Ray Bradbury, Fahrenheit 451 From nobody Wed May 4 13:21:53 2022 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 0FB351AB3897 for ; Wed, 4 May 2022 13:22:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ktctj2d5qz3GCW for ; Wed, 4 May 2022 13:22:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2a.google.com with SMTP id e10so1195315vsr.1 for ; Wed, 04 May 2022 06:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8+aXChQeq0fI0vnnas0PVzcOuz+i7oOz+KXeb3qcV/c=; b=WYN5bVV+D7EwTP0TAk4NmoTy+aCFu9QJqMVavJeiASRS3uLX2insbpfKvklFrfH97O SQRvIbd0nSPfGjaFze43lTyPO9lM1DRMJXacvBczOyPTJHe7VjeKoPqobdGs7BuIWmI8 qeafJi1Dlyg22rMpa3/QVEyI8t7PlKwuuh+BB6spo3cBFlz23BfZZuuuRCGB6RvFC2Dt +ufOxun9HRq3IrbyFd87D0fv8ZW5dgbpJxuR4+Qu89iK+Qai52Al2ILYq64wHmde9Xsx eBBLcqZ0Jn2OguFFwgajHbxrD3hj7jPdpDx0WQOGLHqmlNzLw9/fk+UaiN3zJk7gCAzf AchA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8+aXChQeq0fI0vnnas0PVzcOuz+i7oOz+KXeb3qcV/c=; b=aCmv0KsITLznfTDSD5AGcf0X21U/JFolQT+MonvyHtbyRU2Yuyf0KgtC8Agsdhy/Vw aVF/BWV3woenDxszMW9LPgN9qjG5NBnMCvqsSFAqR2qfXF+Jpim/mT+sziUiZLx01wR/ ujCYoBXM7uaZHdV0lB6zJplpnFNSi7wuVmjoBAKzYJugbhWC1BBZ0JJXP07+VX/X6eH3 8gH1S4hhvTm3+f/13b2f3r68vQ0i/TmtnrWMX6AS6QTgXsIAFOnMMpkLcnj6VSfNxzCV YdEeoYyPXk0vNsYRCaOMJL5PsqxYDl2f4JulxuW9RtL3bk4ENkMxt/WpaWbwhloo6Ug2 7boQ== X-Gm-Message-State: AOAM53316IITwFfS61BAotgJMH4lbBV2y3iQfnmIyFXVgN7fcwxYiCdt 170vf6LR6ME+PdBShEO+fEcEXQXMF9Or4vqIEG6bpfWCu3w= X-Google-Smtp-Source: ABdhPJyf/9Eyr4tlXhsKv3GnQ6tm1csE3c9hzYl+zmWAJV7xsnisXpOi5p5da8ju5I7b7lltGzKXBSeD16Gp9oL8XDw= X-Received: by 2002:a67:1547:0:b0:32c:f3a1:bdd8 with SMTP id 68-20020a671547000000b0032cf3a1bdd8mr6651460vsv.44.1651670524754; Wed, 04 May 2022 06:22:04 -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: Wed, 4 May 2022 07:21:53 -0600 Message-ID: Subject: Re: is gptzfsboot relevant on arm64? To: f451 Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000ea11b005de2f824c" X-Rspamd-Queue-Id: 4Ktctj2d5qz3GCW X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=WYN5bVV+; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2a) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.94 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2a:from]; NEURAL_HAM_SHORT(-0.94)[-0.943]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[imap.cc]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000ea11b005de2f824c Content-Type: text/plain; charset="UTF-8" On Wed, May 4, 2022 at 7:13 AM f451 wrote: > Hello, > > On arm64 I have this:- > > % uname -KU > 1400057 1400057 > % man 8 gptzfsboot > No manual entry for gptzfsboot > % > > Is gptzfsboot only for certain archs? I only query it because recently > zpool offered an > upgrade and suggested looking at it. I see that man 8 gptzfsboot is > available on > 13-stable on amd64. > No. It's not relevant for ARM 64. It's only relevant for BIOS systems, which are exclusive i386/amd64. ARM64 uses UEFI exclusively for booting, and has a combined boot loader for both ZFS and UFS systems (gptzfsboot exists because of space limitations on x86 and the kinda funky way that ZFS reserves space for a boot loader). Warner --000000000000ea11b005de2f824c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 4, 2022 at 7:13 AM f451 &= lt;f451@imap.cc> wrote:
Hello,

On arm64 I have this:-

% uname -KU
1400057 1400057
% man 8 gptzfsboot
No manual entry for gptzfsboot
%

Is gptzfsboot only for certain archs? I only query it because recently zpoo= l offered an
upgrade and suggested looking at it. I see that man 8 gptzfsboot is availab= le on
13-stable on amd64.

No. It's not re= levant for ARM 64. It's only relevant for BIOS systems, which are exclu= sive i386/amd64.
ARM64 uses UEFI exclusively for booting, and has= a combined boot loader for both ZFS and UFS
systems (gptzfsboot = exists because of space limitations on x86 and the kinda funky way that ZFS=
reserves space for a boot loader).

Warn= er=C2=A0
--000000000000ea11b005de2f824c-- From nobody Wed May 4 17:01:15 2022 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 8F05C1ACB503 for ; Wed, 4 May 2022 17:01:39 +0000 (UTC) (envelope-from f451@imap.cc) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ktjm23bmgz4jCb for ; Wed, 4 May 2022 17:01:38 +0000 (UTC) (envelope-from f451@imap.cc) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id DBBA632001FF for ; Wed, 4 May 2022 13:01:36 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute3.internal (MEProxy); Wed, 04 May 2022 13:01:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imap.cc; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1651683696; x= 1651770096; bh=Ryvkzyudp3NGtchV25GTx0fyewBciaW64Yv36BM2gv4=; b=n w8JZ+EOT31NaGjUN6Ob9W5Vj78Ixytja0Qqi253id8C5CYql+K0gESzp2TKPcsvt bbaUI5Nejjqq+plSKMIOHVja+qeUgylEg3sGlU/ufqG3Vjy5pM08TGcYFE2+OocN keKLZAy/iL8LnQVkzpxdNm3JuepDBAZDOwFdPmslhhH4FfWwme60MwoMzpO8baCO 0It5TPysFGH8RLUXMu8tffD2fB0z8L26/Fa19iUiz43lnjxbCCov6Mj53yA3V6oB ykhy829eNp9J+IaMjiXBo7IigQvGq7Wd1rhBQSzHI9pz48HZ7xYoWX7o3B+Zy5Mv HWptzpAby3J4E92W5Ub4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1651683696; x=1651770096; bh=Ryvkzyudp3NGtchV25GTx0fyewBc iaW64Yv36BM2gv4=; b=B+TMDE9hkh1yBiSflIrYqZSvddL57Ahz9gC2fsX9qqDj aCUDGCt2Ol86tZL5W5dy1ujW3NWd9b+wKZtyPtMYYWRvtKGZO995KPzJR7EbYbfx qYcJlrrMDOe0BuW/qD6WvkhCg3jHnyqBaTkaxc1z4/TT2Vr82Fzbm5lDm9Hzwq9d D0RyQr+OxLz6dwP5weJhA4ZUUFhlMWi6g848xRl1G9+qR8y2p69iXzIwkcv4bQg3 /8IVgfkLN0zuqsNQCKgtTM0g8V+SLQDtjpQ2uSw1WSDcv5yoZ6XHLdCsrkZb03mz aXcY7NEEgKEDgUr9KbnDKRO30TmZIIv66uhY0ggojg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdelgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgfrhhlucfvnfffucdludehmdenucfjughrpefofg ggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfhegheduuceofheghedu sehimhgrphdrtggtqeenucggtffrrghtthgvrhhnpefggedvvdevhfdvfefggfffueduue duleefheefvdffteeuvdffgfeuhfetteffgeenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehfgeehudesihhmrghprdgttg X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EDD052A2005F; Wed, 4 May 2022 13:01:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 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 Message-Id: In-Reply-To: References: Date: Wed, 04 May 2022 17:01:15 +0000 From: f451 To: freebsd-current@freebsd.org Subject: Re: is gptzfsboot relevant on arm64? Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Ktjm23bmgz4jCb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=imap.cc header.s=fm1 header.b="n w8JZ+E"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=B+TMDE9h; dmarc=pass (policy=none) header.from=imap.cc; spf=pass (mx1.freebsd.org: domain of f451@imap.cc designates 64.147.123.19 as permitted sender) smtp.mailfrom=f451@imap.cc X-Spamd-Result: default: False [-3.09 / 15.00]; XM_UA_NO_VERSION(0.01)[]; FREEMAIL_FROM(0.00)[imap.cc]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.19]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[imap.cc:+,messagingengine.com:+]; DMARC_POLICY_ALLOW(-0.50)[imap.cc,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[imap.cc]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.19:from]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[imap.cc:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[freebsd-current]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 4 May 2022, at 13:21, Warner Losh wrote: > No. It's not relevant for ARM 64. It's only relevant for BIOS systems, > which are exclusive i386/amd64. Thanks for the explanation. Would you think it worthwhile for me to (I don't know where or precisely how yet) update the output so it notes that gptzfsboot is irrelevant for !i386/amd64 in the=20 spirit of causing less astonishment? --=20 =E2=80=9CWhen they give you lined paper, write the other way.=E2=80=9D =E2=80=95 Ray Bradbury, Fahrenheit 451 From nobody Wed May 4 18:12:55 2022 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 54AAA1AB3195 for ; Wed, 4 May 2022 18:12:57 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KtlLJ6z1Wz4t89; Wed, 4 May 2022 18:12:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651687977; 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=VJ5xpco61opfGgdXInliopKgpvJtLsT4Q0TbRZ3dfXE=; b=lJTjJChKxfbHwnnEvhoxRSFbR7fecsGLds4FUCcYxH2DLiEss/RT7nY/fISIOxxsbZ1A+M mWMtWPPqoq72MAUDuKyq1iLY/eIpbZNKXMwVrebTBxk3R7LKMsUtyGR+y7tj81F0XfzMEx kc4697ZKpFEjwKDwk/YIoHogAX2Gwf1CuKRnNncn8AlvxFNh1xRtu8kQc78MleOzAlERnb 6kQl0Gd169xWfS8hXbn+6PwUyLPp1/HkQbYlu9vqm7zo7OyhrtvxB26+FneeiZMpN+USo0 FUo5C73Dh1HvreCjlYXSrv0wYLVixYQUre6MfetSJvssqWNlwPHpEhg/iGCtFg== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 7075C64CF; Wed, 4 May 2022 18:12:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <80e38cf3-0d53-fce6-76e6-936c47d95c91@FreeBSD.org> Date: Wed, 4 May 2022 11:12:55 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Profiled libraries on freebsd-current Content-Language: en-US To: sgk@troutmask.apl.washington.edu, Ed Maste Cc: FreeBSD Current References: From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651687977; 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=VJ5xpco61opfGgdXInliopKgpvJtLsT4Q0TbRZ3dfXE=; b=VX2kAutE+5SNB1qekeJCQIsXT1j1WpW4lOQsJ+szKly2GmAhjEdVyiqyKiR+lkh0SQcamx /LHtjwdSxnbaSil08twcKHOXGKXNfMM5AZVLcYZwYd48e02scVhlP3j9OGfz6eWSmd4/2m RsgXrePxzuSKJRTAnKtt51jZAFVu1Yp5LAy4YuMlB7no4039B0xeGHnFtC13UvEbKYTsFF USgM5UAi3vktsvDO72gdX03sDVAZOMMHrX8iv8eq2PpkfnqFr1tPwO0iVK1ZifWO46VdAs +ENXmpn54XPlgdIKqn8/wX5/v3X+zgZvCXBXIFJWVrQaBDZtiO3n9Ba+Y4pKTw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651687977; a=rsa-sha256; cv=none; b=heqlgIFDzEZCay1v16/GaytVe1odgkDj6feNQFCnP8fLn4Eq21ynkSUxeXFyqcH5i7NCKi rDg3Dsg6HUGE6brLuSDioUXPR8LDAOHMLAg06i+bdrNEndRzN0G9PFjEwnsawWeaM0P2nP f12hZ0wCJIYz6VJYHeOhRWf4nDMKUf9Y+XcwozFX/YSljOgHi4ilX6HVYaoCPrPiQvjPqr DKIIExwbsykOnBQqJ/SD/o2Z5V857sUQhQ89UGQbfliSwBunAbtVdoJBQxuNIUIYt796eb KpCiAU+gXQqjrMBwydRYunSYA92dvLczt2IKku0KP5QpwEg0E6LGxJuTnnipIw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 5/2/22 10:37 AM, Steve Kargl wrote: > On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote: >> On Sun, 1 May 2022 at 11:54, Steve Kargl >> wrote: >>> >>> diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h >>> index 594487829b5..1e8ab2e1827 100644 >>> --- a/gcc/config/freebsd-spec.h >>> +++ b/gcc/config/freebsd-spec.h >>> @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see >>> (similar to the default, except no -lg, and no -p). */ >>> >>> #ifdef FBSD_NO_THREADS >> >> I wonder if we can simplify things now, and remove this >> `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC >> targets I looked at. > > That I don't know. FBSD_NO_THREADS is defined in freebsd-nthr.h. > In fact, it's the only thing in that header (except copyright > broilerplate). freebsd-nthr.h only appears in config.gcc and > seems to only get added to the build if someone runs configure > with --enable-threads=no. Looking at my last config.log for > gcc trunk, I see "Thread model: posix", which appears to be > the default case or if someone does --enable-threads=yes or > --enable-threads=posix. So, I suppose it comes down to > two questions: (1) is libpthread.* available on all supported > targets and versions? (2) does anyone build gcc without > threads support? libpthread is available on all supported architectures on all supported versions. libthr has been the default threading library since 7.0 and the only supported library since 8.0. In GDB I just assume libthr style threads, and I think GCC can safely do the same. -- John Baldwin From nobody Wed May 4 19:53:17 2022 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 59F991AA9DA1 for ; Wed, 4 May 2022 19:53:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KtnZD105Bz3Q8N; Wed, 4 May 2022 19:53:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 244JrHN7024947 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 4 May 2022 12:53:17 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 244JrHmO024946; Wed, 4 May 2022 12:53:17 -0700 (PDT) (envelope-from sgk) Date: Wed, 4 May 2022 12:53:17 -0700 From: Steve Kargl To: John Baldwin Cc: Ed Maste , FreeBSD Current Subject: Re: Profiled libraries on freebsd-current Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <80e38cf3-0d53-fce6-76e6-936c47d95c91@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: <80e38cf3-0d53-fce6-76e6-936c47d95c91@FreeBSD.org> X-Rspamd-Queue-Id: 4KtnZD105Bz3Q8N X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-2.65 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-0.68)[-0.678]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.974]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote: > On 5/2/22 10:37 AM, Steve Kargl wrote: > > On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote: > > > On Sun, 1 May 2022 at 11:54, Steve Kargl > > > wrote: > > > > > > > > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h > > > > index 594487829b5..1e8ab2e1827 100644 > > > > --- a/gcc/config/freebsd-spec.h > > > > +++ b/gcc/config/freebsd-spec.h > > > > @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see > > > > (similar to the default, except no -lg, and no -p). */ > > > > > > > > #ifdef FBSD_NO_THREADS > > > > > > I wonder if we can simplify things now, and remove this > > > `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC > > > targets I looked at. > > > > That I don't know. FBSD_NO_THREADS is defined in freebsd-nthr.h. > > In fact, it's the only thing in that header (except copyright > > broilerplate). freebsd-nthr.h only appears in config.gcc and > > seems to only get added to the build if someone runs configure > > with --enable-threads=no. Looking at my last config.log for > > gcc trunk, I see "Thread model: posix", which appears to be > > the default case or if someone does --enable-threads=yes or > > --enable-threads=posix. So, I suppose it comes down to > > two questions: (1) is libpthread.* available on all supported > > targets and versions? (2) does anyone build gcc without > > threads support? > > libpthread is available on all supported architectures on all > supported versions. libthr has been the default threading library > since 7.0 and the only supported library since 8.0. In GDB I just > assume libthr style threads, and I think GCC can safely do the > same. > I don't know the entire FreeBSD ecosystem. Do people use FreeBSD on embedded systems (e.g., nanobsd) where libthr may be stripped out? Thus, --enable-threads=no is needed. gcc/config/freebsd-nthr.h was committed on May 22, 2001. There have been no changes to the file other than cosmetic ones (e.g., updating copyright notice). gcc/config/freebsd-spec.h has had a number of changes. Someone with a better understanding of the spec file will need to clean that up. -- Steve From nobody Wed May 4 20:22:57 2022 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 340B31AB14C5 for ; Wed, 4 May 2022 20:22:59 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KtpDM0yJXz3l5f; Wed, 4 May 2022 20:22:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651695779; 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=WXqX6gjUE1Fq3AnUkgq7miVsoqc84NzMQAFZZA+v+3A=; b=aqob+0WsFO2EG/qYgSmGhYjyLGvXz0H88tfyML1AQ7eeFt/jfQrLhQ197cDVDtEirDjzFb bXfUBOuekGLNBmdCDQPNe36zaJsZEfvd5Abpdwk3n6xAA1+NG673PixYFTpplkZ+V7LUJU 1ZKdDVcFEMJMqvx8EktC9xE2w+8a+5iJRlauA48yT5f/H/CPk147C2BKnLKch8jGjKUMcq /G2CiaoLBPuxboJpQqFHIPYusYpRUMawftgLFaAUcZWxRkYCENVhaF9AM8SS7ZKBxB/00e tyoX7F0HnVvp+lYc26ia4tCg7VzMVUHX1UF4pzzeiIlrHm4lBNCyE2JIUr8z4Q== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 9A73A78C2; Wed, 4 May 2022 20:22:58 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <4b128639-f233-acfe-aeb4-5830aa973cb6@FreeBSD.org> Date: Wed, 4 May 2022 13:22:57 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Profiled libraries on freebsd-current Content-Language: en-US To: sgk@troutmask.apl.washington.edu Cc: Ed Maste , FreeBSD Current References: <80e38cf3-0d53-fce6-76e6-936c47d95c91@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651695779; 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=WXqX6gjUE1Fq3AnUkgq7miVsoqc84NzMQAFZZA+v+3A=; b=hnMXzrqyrzBaLKfaJMt2f2jP9GWRhWKIquOcW0oyBVznL2EU2gh2x+u1Cohr4szbD66SCE 9ENYQ1j9JCo6JhUxwsSAyLr9TB8BeJ4XyRko5uP0DOFd5/CXDUOxPQw4abVaTN7mU7WQjd P1zSj2QVf0ypCc3Pj9USfuHq9PmOsGBisafET6IYoX1c6VifdMVGgDbPGHx3HOWEb/oESY Y/7zFEid5stKD3Ngu43Xw8KPUXvfPhUui+WP400PPqx3mv/jp7nl9NE03lNaq7eAdWULnP CZ7pLhLeBHhAYeWVOn6YYyKnejRG/kuNxvQBn28n2px74w9gVe0bQ5EuF2txMA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651695779; a=rsa-sha256; cv=none; b=Fwnr7mrPULMIC6pwvApRW/YLDZfbWxuO7l5CvdlZGz7xR91R9CwpMWguw3/XcVgJGWvCvJ +3BkftjQjtimDv/1+WTqAtozsCGl8xlIvvgc3qgfsaZA1/xCsi7U1mF2dspPztFwXBJwhl w2AXkFhQBEH9ZJuflXF4shSXEfenpRQ14ycNGAHb21oqAooUy1DEQXxa4JQRXb+uiZurbT tiiC3j/3caGRjDh6LHUcQrjBzPsy3vWc+RA0ATdzRr8AQhduVHNq/s6G4uBKAB4U/kyB5K ftTgx3YoIKD+H9vnnvFHGt1ZPpdBEAUxn+hEgHF9IsOdGuadLi8HolhibRxaZw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 5/4/22 12:53 PM, Steve Kargl wrote: > On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote: >> On 5/2/22 10:37 AM, Steve Kargl wrote: >>> On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote: >>>> On Sun, 1 May 2022 at 11:54, Steve Kargl >>>> wrote: >>>>> >>>>> diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h >>>>> index 594487829b5..1e8ab2e1827 100644 >>>>> --- a/gcc/config/freebsd-spec.h >>>>> +++ b/gcc/config/freebsd-spec.h >>>>> @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see >>>>> (similar to the default, except no -lg, and no -p). */ >>>>> >>>>> #ifdef FBSD_NO_THREADS >>>> >>>> I wonder if we can simplify things now, and remove this >>>> `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC >>>> targets I looked at. >>> >>> That I don't know. FBSD_NO_THREADS is defined in freebsd-nthr.h. >>> In fact, it's the only thing in that header (except copyright >>> broilerplate). freebsd-nthr.h only appears in config.gcc and >>> seems to only get added to the build if someone runs configure >>> with --enable-threads=no. Looking at my last config.log for >>> gcc trunk, I see "Thread model: posix", which appears to be >>> the default case or if someone does --enable-threads=yes or >>> --enable-threads=posix. So, I suppose it comes down to >>> two questions: (1) is libpthread.* available on all supported >>> targets and versions? (2) does anyone build gcc without >>> threads support? >> >> libpthread is available on all supported architectures on all >> supported versions. libthr has been the default threading library >> since 7.0 and the only supported library since 8.0. In GDB I just >> assume libthr style threads, and I think GCC can safely do the >> same. >> > > I don't know the entire FreeBSD ecosystem. Do people > use FreeBSD on embedded systems (e.g., nanobsd) where > libthr may be stripped out? Thus, --enable-threads=no > is needed. If they do, they are also using a constrained userland and probably are not shipping a GCC binary either. However, it's not clear to me what --enable-threads means. Does this enable -pthread as an option? If so, that should definitely just always be on. It's still an option users have to opt into via a command line flag and doesn't prevent building non-threaded programs. If it's enabling use of threads at runtime within GCC itself, I'd say that also should probably just be allowed to be on. I can't really imagine what else it might mean (and I doubt it means the latter). -- John Baldwin From nobody Wed May 4 20:38:36 2022 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 21C781AB7636 for ; Wed, 4 May 2022 20:38:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KtpZQ3lNsz3qxP; Wed, 4 May 2022 20:38:38 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 244KcaIt025269 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 4 May 2022 13:38:36 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 244KcaeD025268; Wed, 4 May 2022 13:38:36 -0700 (PDT) (envelope-from sgk) Date: Wed, 4 May 2022 13:38:36 -0700 From: Steve Kargl To: John Baldwin Cc: Ed Maste , FreeBSD Current Subject: Re: Profiled libraries on freebsd-current Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <80e38cf3-0d53-fce6-76e6-936c47d95c91@FreeBSD.org> <4b128639-f233-acfe-aeb4-5830aa973cb6@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: <4b128639-f233-acfe-aeb4-5830aa973cb6@FreeBSD.org> X-Rspamd-Queue-Id: 4KtpZQ3lNsz3qxP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.01 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.986]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Wed, May 04, 2022 at 01:22:57PM -0700, John Baldwin wrote: > On 5/4/22 12:53 PM, Steve Kargl wrote: > > On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote: > > > > I don't know the entire FreeBSD ecosystem. Do people > > use FreeBSD on embedded systems (e.g., nanobsd) where > > libthr may be stripped out? Thus, --enable-threads=no > > is needed. > > If they do, they are also using a constrained userland and > probably are not shipping a GCC binary either. However, it's > not clear to me what --enable-threads means. > > Does this enable -pthread as an option? If so, that should > definitely just always be on. It's still an option users have > to opt into via a command line flag and doesn't prevent > building non-threaded programs. > > If it's enabling use of threads at runtime within GCC itself, > I'd say that also should probably just be allowed to be on. > > I can't really imagine what else it might mean (and I doubt > it means the latter). > AFAICT, it controls whether -lpthread is automatically added to the command line. In the case of -pg, it is -lpthread_p. The relevant lines are #ifdef FBSD_NO_THREADS #define FBSD_LIB_SPEC " \ %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \ is built with the --enable-threads configure-time option.} \ %{!shared: \ %{!pg: -lc} \ %{pg: -lc_p} \ }" #else #define FBSD_LIB_SPEC " \ %{!shared: \ %{!pg: %{pthread:-lpthread} -lc} \ %{pg: %{pthread:-lpthread_p} -lc_p} \ } \ %{shared: \ %{pthread:-lpthread} -lc \ }" #endif Ed is wondering if one can get rid of FBSD_NO_THREADS. With the pending removal of WITH_PROFILE, the above reduces to #define FBSD_LIB_SPEC " \ %{!shared: \ %{pthread:-lpthread} -lc \ } \ %{shared: \ %{pthread:-lpthread} -lc \ }" If one can do the above, then freebsd-nthr.h is no longer needed and can be deleted and config.gcc's handling of --enable-threads can be updated/removed. -- Steve From nobody Wed May 4 20:47:04 2022 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 E25361ABA8F1 for ; Wed, 4 May 2022 20:47:05 +0000 (UTC) (envelope-from jhb@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ktpm95g7Tz3tNt; Wed, 4 May 2022 20:47:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651697225; 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=byv81HHW3j/en8ulEm3eK67V00eWTmBNkD9t58ERo4g=; b=WuiblLy3021Rhub9dntTaF7gZ2Uww5ZfVlp3pP/YSP6zKFRRyU3bEbKUTUXDOk9nq9qSRZ QI2+v4ew+zpT+H4TfWYiyk/BYrBaq3R4LBNtbHuJHi2m2S0GK3g4TbHukP+4fyz2T9vZnn kROc1VLXcfb91CXuS2kVvzV+MJ154bTFTmpTcnfsK/KT7Hq+BYtYxLgtnFmrOdDiWp2Ybg dfOGaAswuDVHB6vtgCOsjaygS+jyllZBMYbmsZ7DqY+eKu9WNESD69s9vfGWH+TJc4xKRA O9Mw0g6oPU2JtrnY0oId7ZTfHegz8eevczMyAerS/rop06DOB+fpnXuVWXIW3A== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 48F9472C0; Wed, 4 May 2022 20:47:05 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <1ab2b5dc-c98b-5a4d-de34-7472e936d395@FreeBSD.org> Date: Wed, 4 May 2022 13:47:04 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Profiled libraries on freebsd-current Content-Language: en-US To: sgk@troutmask.apl.washington.edu Cc: Ed Maste , FreeBSD Current References: <80e38cf3-0d53-fce6-76e6-936c47d95c91@FreeBSD.org> <4b128639-f233-acfe-aeb4-5830aa973cb6@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1651697225; 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=byv81HHW3j/en8ulEm3eK67V00eWTmBNkD9t58ERo4g=; b=RwKbBaqrug43v8AW0kQKQALcBjukGkNRhqqQX0Pjn5wlkRR5nZ7ZCxOXe2O6VOpEP0KWkh kGcs9oySNK2Z8YxbvK62JIETM6oeIKZcen8S37jTig+BU94Zcoub2q2iN5GOnGApJYmai0 6PIWrBZ3DqQIR1EfiCXVaRRI6IQTs4od54zcdFm0rQJmp6ZrpRKB8SLoGhNY51ONw29kwn cmnsWMTkjVc+d3etomPZPb0cn0aH48xI1R4BF5OxN8rY9mU3oWk5kteSejfAKuKI8iV/6k mwQ8bqgeJEuHc36m0TBUfRuPZQ4PEGVAi1QZQVr6dgJO0ghGKfZmvZMvxT2N2A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1651697225; a=rsa-sha256; cv=none; b=aJ9vWFpDYPuOZVWOv+ry61hNDrZGkKyDO7jGdsBbmhbDx5pi5Va+dHGVGaLQrr3z2tKFRZ 1f52dARYE8hp9SKBcTFhOAS6P7hOkSiE39HzE0dxlzvWK2ef2LiYzjTa5q4EhAKwPmYjbp Z9x5Z1SBKLEkPf9OgfWmhAXeSOHvLVj9xXe2qnNbkZXofSWzbICk+UEvsvG0M/A7/KrIp2 hxfrqHCDM79qUx8AaIDTWP9xSvB8PmKdIH0uezMfhtNLhS8ju58ARt99Y1ib5uZ4TQcoyB okY0dIsE/OH9N92Zw4hkP1a/3ueYBv+mb6W/YC7egp9dtx9tkGrp56sLNaUb/A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 5/4/22 1:38 PM, Steve Kargl wrote: > On Wed, May 04, 2022 at 01:22:57PM -0700, John Baldwin wrote: >> On 5/4/22 12:53 PM, Steve Kargl wrote: >>> On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote: >>> >>> I don't know the entire FreeBSD ecosystem. Do people >>> use FreeBSD on embedded systems (e.g., nanobsd) where >>> libthr may be stripped out? Thus, --enable-threads=no >>> is needed. >> >> If they do, they are also using a constrained userland and >> probably are not shipping a GCC binary either. However, it's >> not clear to me what --enable-threads means. >> >> Does this enable -pthread as an option? If so, that should >> definitely just always be on. It's still an option users have >> to opt into via a command line flag and doesn't prevent >> building non-threaded programs. >> >> If it's enabling use of threads at runtime within GCC itself, >> I'd say that also should probably just be allowed to be on. >> >> I can't really imagine what else it might mean (and I doubt >> it means the latter). >> > > AFAICT, it controls whether -lpthread is automatically added to > the command line. In the case of -pg, it is -lpthread_p. > The relevant lines are > > #ifdef FBSD_NO_THREADS > #define FBSD_LIB_SPEC " \ > %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \ > is built with the --enable-threads configure-time option.} \ > %{!shared: \ > %{!pg: -lc} \ > %{pg: -lc_p} \ > }" > #else > #define FBSD_LIB_SPEC " \ > %{!shared: \ > %{!pg: %{pthread:-lpthread} -lc} \ > %{pg: %{pthread:-lpthread_p} -lc_p} \ > } \ > %{shared: \ > %{pthread:-lpthread} -lc \ > }" > #endif > > Ed is wondering if one can get rid of FBSD_NO_THREADS. With the > pending removal of WITH_PROFILE, the above reduces to > > #define FBSD_LIB_SPEC " \ > %{!shared: \ > %{pthread:-lpthread} -lc \ > } \ > %{shared: \ > %{pthread:-lpthread} -lc \ > }" > > If one can do the above, then freebsd-nthr.h is no longer needed > and can be deleted and config.gcc's handling of --enable-threads > can be updated/removed. Ok, so it's just if -pthread is supported (%{pthread:-lpthread} only adds -lpthread if -pthread was given on the command line). That can just be on all the time and Ed is correct that it is safe to remove the FBSD_NO_THREADS case and assume it is always present instead. -- John Baldwin From nobody Thu May 5 00:03:16 2022 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 9EF451AC1DA2 for ; Thu, 5 May 2022 00:03:27 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ktv6k1vqxz3Cr7; Thu, 5 May 2022 00:03:25 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-111-80.area1b.commufa.jp [123.1.111.80]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 24503Ghf046436; Thu, 5 May 2022 09:03:17 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 5 May 2022 09:03:16 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: imp@FreeBSD.org Subject: Massive "Found bio_cmd = 0x5" with options CAM_IOSCHED_DYNAMIC Message-Id: <20220505090316.1df9a1bc2e07e69b1da8cb64@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Ktv6k1vqxz3Cr7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [0.36 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.96)[0.964]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; URIBL_BLOCKED(0.00)[sakura.ne.jp:email]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.111.80:received] X-ThisMailContainsUnwantedMimeParts: N Hi. After updating src main git: f44280bf5fbb to git: 1599fc904d35, with options CAM_IOSCHED_DYNAMIC on kernel config file, A plenty of "Found bio_cmd = 0x5" appear on console and dmesg. With quick look under src/sys/, bio_cmd = 0x5 means BIO_FLUSH, and the printf() only appears on src/sys/cam/cam_iosched.c line 1621.[1] Maybe it actually wouldn't be harmful (just annoying), but possibly any conditions blocking BIO_FLUSH to reach there would be lost. (The printf() itself was already there at git: f44280bf5fbb.) If it's actualy not at all harmful, and BIO_FLUSH case is coming through here is intentional change, is it really needed to be printed? There were 4 commits to cam_iosched.c within the span. cc1572ddeb8cd82879ce0cca634bf6a8830c0f40 [2] cam iosched: Remove write bias when read bias = 0 b65803ba5773d5fb37fa2403105db199569a5811 [3] cam iosched: default to no read bias in dynamic ioscheduling d592c0db8ba773c143eeea28610288f800fa651a [4] cam: add hw.cam.iosched.read_bias 1599fc904d35cfa8eecad92818d1f4b55de6818f [5] iosched: Move bio_next() inside of the CAM_IOSCHED_DYNAMIC ifdef [1] https://cgit.freebsd.org/src/tree/sys/cam/cam_iosched.c#n1621 [2] https://cgit.freebsd.org/src/commit/?id=cc1572ddeb8cd82879ce0cca634bf6a8830c0f40 [3] https://cgit.freebsd.org/src/commit/?id=b65803ba5773d5fb37fa2403105db199569a5811 [4] https://cgit.freebsd.org/src/commit/?id=d592c0db8ba773c143eeea28610288f800fa651a [5] https://cgit.freebsd.org/src/commit/?id=1599fc904d35cfa8eecad92818d1f4b55de6818f Regards. -- Tomoaki AOKI From nobody Thu May 5 02:16:37 2022 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 BD49E1AB86DA for ; Thu, 5 May 2022 02:16:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kty4S4f8yz3pd1 for ; Thu, 5 May 2022 02:16:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2f.google.com with SMTP id b81so1482853vkf.1 for ; Wed, 04 May 2022 19:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Afz8TU8R5xXvRp882lCuSWtHD47cYIF79xTL9apeJdc=; b=M2UueIhPf6+OSCvms49uyXS03pNK243EQhbu2Os2kq/AMRBHkQcyClZ780r4m/9hAj iqpcIE1ywoJFoMdLt8O9Xnz3UvHCc9qIESo8rvs04h2qwewbxxYXUd/mBnIbOcm2oZO7 +DjwCGvN1EpxQA+USmIblexUupTUW2+uvi17XItNqBPwERy0TNP/MHF0EdiRBRN2weJN zQMnNTR9q/swRNfWgPRCtSFYQCupC2VF3wLIQLcpajoXV0CgOiwlH4HIyDwTiI8DwfJ0 STkyco5oNF9z/pwkbmcSd2A/J7fxhvCAcYTngHLh8w9qiSSvZbYLSnYeY6q1O9UvJinN qMBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Afz8TU8R5xXvRp882lCuSWtHD47cYIF79xTL9apeJdc=; b=E4X7FOR34TIXcnhR1HBx+gyCKRitU6lhrVHMuUwo2vHiSNF3GkZLHdRJP+g9HVD/jI ZZxOvXSx77kj4jW5nAMAV+MEb9LnEBvA63CF0c/OsEUEbQ4GzARffFQVqc6ZfUNsaJAm YOh1rC3lJ6cEFY9g/buTPepOHgQnNjNCUaZqjQZFe4Xa05lEAsywxISOYeUu8W/jN9Zd UC6CuqTvWOetmmrxFEqSb4TZ3tsJ+uj7rGwkLQP9l9qUA3xD8hEnQ2SpdcvRMrJT9YHC R8Wt4j0OSukJHLniqs0C7b0Eb0aSxEUVcN4O46NylbxJSGTNVcoEIcqemRWMX960vw1N AdLQ== X-Gm-Message-State: AOAM5311ad6nyqeWf0UTsH5kBI+DcCphSZJ/7+4WZSPJcs+JEpcQyyWb x9vS1Wf5/nlMMRARLK0uHC9n4MhbPKxWiGRLI4qSTb0jctw= X-Google-Smtp-Source: ABdhPJzi+aH14C+MbNp/Ll0AzJwT7UfgI7W04rSbCylIiz+4yaVICXbQA2VcH2biSh4CFCL9uMMoNk9yzns/aYfzghg= X-Received: by 2002:ac5:c856:0:b0:34e:d0b4:7a10 with SMTP id g22-20020ac5c856000000b0034ed0b47a10mr6147606vkm.39.1651716994584; Wed, 04 May 2022 19:16:34 -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: <20220505090316.1df9a1bc2e07e69b1da8cb64@dec.sakura.ne.jp> In-Reply-To: <20220505090316.1df9a1bc2e07e69b1da8cb64@dec.sakura.ne.jp> From: Warner Losh Date: Wed, 4 May 2022 20:16:37 -0600 Message-ID: Subject: Re: Massive "Found bio_cmd = 0x5" with options CAM_IOSCHED_DYNAMIC To: Tomoaki AOKI Cc: FreeBSD Current , Warner Losh Content-Type: multipart/alternative; boundary="000000000000bb64db05de3a5454" X-Rspamd-Queue-Id: 4Kty4S4f8yz3pd1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=M2UueIhP; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.98 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.98)[-0.984]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2f:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000bb64db05de3a5454 Content-Type: text/plain; charset="UTF-8" Sorry for the top post... However, which device(s) are you using? Warner On Wed, May 4, 2022 at 6:03 PM Tomoaki AOKI wrote: > Hi. > > After updating src main git: f44280bf5fbb to git: 1599fc904d35, > with options CAM_IOSCHED_DYNAMIC on kernel config file, > A plenty of "Found bio_cmd = 0x5" appear on console and dmesg. > > With quick look under src/sys/, bio_cmd = 0x5 means BIO_FLUSH, > and the printf() only appears on src/sys/cam/cam_iosched.c line 1621.[1] > > Maybe it actually wouldn't be harmful (just annoying), but possibly > any conditions blocking BIO_FLUSH to reach there would be lost. > (The printf() itself was already there at git: f44280bf5fbb.) > > If it's actualy not at all harmful, and BIO_FLUSH case is coming > through here is intentional change, is it really needed to be printed? > > There were 4 commits to cam_iosched.c within the span. > > cc1572ddeb8cd82879ce0cca634bf6a8830c0f40 [2] > cam iosched: Remove write bias when read bias = 0 > b65803ba5773d5fb37fa2403105db199569a5811 [3] > cam iosched: default to no read bias in dynamic ioscheduling > d592c0db8ba773c143eeea28610288f800fa651a [4] > cam: add hw.cam.iosched.read_bias > 1599fc904d35cfa8eecad92818d1f4b55de6818f [5] > iosched: Move bio_next() inside of the CAM_IOSCHED_DYNAMIC ifdef > > > [1] https://cgit.freebsd.org/src/tree/sys/cam/cam_iosched.c#n1621 > > [2] > > https://cgit.freebsd.org/src/commit/?id=cc1572ddeb8cd82879ce0cca634bf6a8830c0f40 > > [3] > > https://cgit.freebsd.org/src/commit/?id=b65803ba5773d5fb37fa2403105db199569a5811 > > [4] > > https://cgit.freebsd.org/src/commit/?id=d592c0db8ba773c143eeea28610288f800fa651a > > [5] > > https://cgit.freebsd.org/src/commit/?id=1599fc904d35cfa8eecad92818d1f4b55de6818f > > > Regards. > > -- > Tomoaki AOKI > --000000000000bb64db05de3a5454 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the top post...

Ho= wever, which device(s) are you using?

Warner

On= Wed, May 4, 2022 at 6:03 PM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
Hi.

After updating src main git: f44280bf5fbb to git: 1599fc904d35,
with options CAM_IOSCHED_DYNAMIC on kernel config file,
A plenty of "Found bio_cmd =3D 0x5" appear on console and dmesg.<= br>
With quick look under src/sys/, bio_cmd =3D 0x5 means BIO_FLUSH,
and the printf() only appears on src/sys/cam/cam_iosched.c line 1621.[1]
Maybe it actually wouldn't be harmful (just annoying), but possibly
any conditions blocking BIO_FLUSH to reach there would be lost.
(The printf() itself was already there at git: f44280bf5fbb.)

If it's actualy not at all harmful, and BIO_FLUSH case is coming
through here is intentional change, is it really needed to be printed?

There were 4 commits to cam_iosched.c within the span.

=C2=A0 cc1572ddeb8cd82879ce0cca634bf6a8830c0f40=C2=A0 =C2=A0 [2]
=C2=A0 =C2=A0 cam iosched: Remove write bias when read bias =3D 0
=C2=A0 b65803ba5773d5fb37fa2403105db199569a5811=C2=A0 =C2=A0 [3]
=C2=A0 =C2=A0 cam iosched: default to no read bias in dynamic ioscheduling<= br> =C2=A0 d592c0db8ba773c143eeea28610288f800fa651a=C2=A0 =C2=A0 [4]
=C2=A0 =C2=A0 cam: add hw.cam.iosched.read_bias
=C2=A0 1599fc904d35cfa8eecad92818d1f4b55de6818f=C2=A0 =C2=A0 [5]
=C2=A0 =C2=A0 iosched: Move bio_next() inside of the CAM_IOSCHED_DYNAMIC if= def


[1] https://cgit.freebsd.org/src/tree/s= ys/cam/cam_iosched.c#n1621

[2]
https://cgit.freeb= sd.org/src/commit/?id=3Dcc1572ddeb8cd82879ce0cca634bf6a8830c0f40

[3]
https://cgit.freeb= sd.org/src/commit/?id=3Db65803ba5773d5fb37fa2403105db199569a5811

[4]
https://cgit.freeb= sd.org/src/commit/?id=3Dd592c0db8ba773c143eeea28610288f800fa651a

[5]
https://cgit.freeb= sd.org/src/commit/?id=3D1599fc904d35cfa8eecad92818d1f4b55de6818f


Regards.

--
Tomoaki AOKI=C2=A0 =C2=A0 <junchoon@dec.sakura.ne.jp>
--000000000000bb64db05de3a5454-- From nobody Thu May 5 02:37:41 2022 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 8A3E81ABDAA5 for ; Thu, 5 May 2022 02:37:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KtyXh3lqQz3sXx for ; Thu, 5 May 2022 02:37:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe34.google.com with SMTP id c62so2972467vsc.10 for ; Wed, 04 May 2022 19:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/rL+6ijrsaZPidumVIApRYqb1D/TBR0HwJCe9dZgc0Y=; b=piFF7g7w95bqPG1QyPOpkEndvL5TmUtnlpWb8DHjb9bADr2JELJ6oj/4VOBOs+L7Uf oiNfQGPqEZwFYRukz4pCNOLdDaJ/K8p507JTVtBYhXjveoo+BIcPL5gAOX1qwuVUG/cm 9pTolJiHJAWl14V018Ws9U0fKyOfH/RzYcvlCcYsEHgQWAiU3H5kT1i8YrU0VoJemqs4 Ve1Ae/T9m7HzU2PF6tGArCsChokOXx0XZy12qxvXSh4fQOWSa/ecaToYmY1B5igt/95j HBspi8QcqRHlegMAlS2fvPMN1tPJypDoQviuGu+PmOkmRlnknQ+0AfVpSC25cinn7Fdt UGog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/rL+6ijrsaZPidumVIApRYqb1D/TBR0HwJCe9dZgc0Y=; b=iDF//SP57TUm2Sb99FdC8+m0ysdPiBObqswdXbemwi+guToucAWWcnKKmO0gIkXiT0 VoK5EmCekU6Iembr4qrij4c97Sy0eFe27AXa4YpzexEaOSmAgvObVzmQzVWNQxULo2+q pLZ8pdgimbrEHnntey9VwlBXETvjGbidGyqP9oYKfpJaf1EgW2qJ5FI/V9DeXQmjbrcD gFufgfjHPwyqgZ72e4uJfhhCHO3KpF0aUElFzTXIfRjW/306t4ARDybDNJJde590YWLA xV9bQtAjzZUb19WK/y4BT3aAqeZ220xidpD5MTbxDgqUnjVnPz64al/6cu6fS2/9z/dd hApQ== X-Gm-Message-State: AOAM532iHo3uzlonGhGrEkN+KNflyYFJh3zG6wj6v+db027Qof6wM7Lr Kl/oBpcvywGD0n4mXzQqntY123vzLyAdvCYsxioHtQ== X-Google-Smtp-Source: ABdhPJyknRSG8IOO9O4eP3+dumm6CO2yR1sqg3FEz/GGs95Q+i8QNioRwyz4QzGAyzkhASF0aKkUcCBm7jLiYBd2IO0= X-Received: by 2002:a67:f445:0:b0:32c:c32c:c7c1 with SMTP id r5-20020a67f445000000b0032cc32cc7c1mr7621489vsn.51.1651718259911; Wed, 04 May 2022 19:37:39 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20220505090316.1df9a1bc2e07e69b1da8cb64@dec.sakura.ne.jp> In-Reply-To: <20220505090316.1df9a1bc2e07e69b1da8cb64@dec.sakura.ne.jp> From: Warner Losh Date: Wed, 4 May 2022 20:37:41 -0600 Message-ID: Subject: Re: Massive "Found bio_cmd = 0x5" with options CAM_IOSCHED_DYNAMIC To: Tomoaki AOKI Cc: FreeBSD Current , Warner Losh Content-Type: multipart/alternative; boundary="00000000000026c19a05de3aa0bc" X-Rspamd-Queue-Id: 4KtyXh3lqQz3sXx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=piFF7g7w; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e34) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.93 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.93)[-0.934]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e34:from]; MLMMJ_DEST(0.00)[freebsd-current]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000026c19a05de3aa0bc Content-Type: text/plain; charset="UTF-8" On Wed, May 4, 2022 at 6:03 PM Tomoaki AOKI wrote: > Hi. > > After updating src main git: f44280bf5fbb to git: 1599fc904d35, > with options CAM_IOSCHED_DYNAMIC on kernel config file, > A plenty of "Found bio_cmd = 0x5" appear on console and dmesg. > > With quick look under src/sys/, bio_cmd = 0x5 means BIO_FLUSH, > and the printf() only appears on src/sys/cam/cam_iosched.c line 1621.[1] > > Maybe it actually wouldn't be harmful (just annoying), but possibly > any conditions blocking BIO_FLUSH to reach there would be lost. > (The printf() itself was already there at git: f44280bf5fbb.) > > If it's actualy not at all harmful, and BIO_FLUSH case is coming > through here is intentional change, is it really needed to be printed? > It's a useless printf. I've removed it and posted an analysis in the commit message. Basically, read_bias == 0 will queue other operations to bio_queue now, so the printf is a false positive to find transactions that shouldn't be on the queue. If you set read_bias = 1, then the messages will go away until you can recompile. I also don't need to know the storage, since this is independent of the periphs... Warner > There were 4 commits to cam_iosched.c within the span. > > cc1572ddeb8cd82879ce0cca634bf6a8830c0f40 [2] > cam iosched: Remove write bias when read bias = 0 > b65803ba5773d5fb37fa2403105db199569a5811 [3] > cam iosched: default to no read bias in dynamic ioscheduling > d592c0db8ba773c143eeea28610288f800fa651a [4] > cam: add hw.cam.iosched.read_bias > 1599fc904d35cfa8eecad92818d1f4b55de6818f [5] > iosched: Move bio_next() inside of the CAM_IOSCHED_DYNAMIC ifdef > > > [1] https://cgit.freebsd.org/src/tree/sys/cam/cam_iosched.c#n1621 > > [2] > > https://cgit.freebsd.org/src/commit/?id=cc1572ddeb8cd82879ce0cca634bf6a8830c0f40 > > [3] > > https://cgit.freebsd.org/src/commit/?id=b65803ba5773d5fb37fa2403105db199569a5811 > > [4] > > https://cgit.freebsd.org/src/commit/?id=d592c0db8ba773c143eeea28610288f800fa651a > > [5] > > https://cgit.freebsd.org/src/commit/?id=1599fc904d35cfa8eecad92818d1f4b55de6818f > > > Regards. > > -- > Tomoaki AOKI > --00000000000026c19a05de3aa0bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 4, 2022 at 6:03 PM Tomoak= i AOKI <junchoon@dec.sakura= .ne.jp> wrote:
Hi.

After updating src main git: f44280bf5fbb to git: 1599fc904d35,
with options CAM_IOSCHED_DYNAMIC on kernel config file,
A plenty of "Found bio_cmd =3D 0x5" appear on console and dmesg.<= br>
With quick look under src/sys/, bio_cmd =3D 0x5 means BIO_FLUSH,
and the printf() only appears on src/sys/cam/cam_iosched.c line 1621.[1]
Maybe it actually wouldn't be harmful (just annoying), but possibly
any conditions blocking BIO_FLUSH to reach there would be lost.
(The printf() itself was already there at git: f44280bf5fbb.)

If it's actualy not at all harmful, and BIO_FLUSH case is coming
through here is intentional change, is it really needed to be printed?
<= /blockquote>

It's a useless printf. I've removed= it and posted an analysis in the commit
message. Basically, read= _bias =3D=3D 0 will queue other operations to bio_queue
now, so t= he printf is a false positive to find transactions that shouldn't be
on the queue.

If you set read_bias =3D 1, = then the messages will go away until you can
recompile.

I also don't need to know the storage, since this is in= dependent of the
periphs...

Warner
=C2=A0
There were 4 commits to cam_iosched.c within the span.

=C2=A0 cc1572ddeb8cd82879ce0cca634bf6a8830c0f40=C2=A0 =C2=A0 [2]
=C2=A0 =C2=A0 cam iosched: Remove write bias when read bias =3D 0
=C2=A0 b65803ba5773d5fb37fa2403105db199569a5811=C2=A0 =C2=A0 [3]
=C2=A0 =C2=A0 cam iosched: default to no read bias in dynamic ioscheduling<= br> =C2=A0 d592c0db8ba773c143eeea28610288f800fa651a=C2=A0 =C2=A0 [4]
=C2=A0 =C2=A0 cam: add hw.cam.iosched.read_bias
=C2=A0 1599fc904d35cfa8eecad92818d1f4b55de6818f=C2=A0 =C2=A0 [5]
=C2=A0 =C2=A0 iosched: Move bio_next() inside of the CAM_IOSCHED_DYNAMIC if= def


[1] https://cgit.freebsd.org/src/tree/s= ys/cam/cam_iosched.c#n1621

[2]
https://cgit.freeb= sd.org/src/commit/?id=3Dcc1572ddeb8cd82879ce0cca634bf6a8830c0f40

[3]
https://cgit.freeb= sd.org/src/commit/?id=3Db65803ba5773d5fb37fa2403105db199569a5811

[4]
https://cgit.freeb= sd.org/src/commit/?id=3Dd592c0db8ba773c143eeea28610288f800fa651a

[5]
https://cgit.freeb= sd.org/src/commit/?id=3D1599fc904d35cfa8eecad92818d1f4b55de6818f


Regards.

--
Tomoaki AOKI=C2=A0 =C2=A0 <junchoon@dec.sakura.ne.jp>
--00000000000026c19a05de3aa0bc-- From nobody Thu May 5 21:10:18 2022 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 AD2B61ABB6E9 for ; Thu, 5 May 2022 21:10:28 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KvRDh0VD6z3Kt6 for ; Thu, 5 May 2022 21:10:28 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd2c.google.com with SMTP id h85so6087615iof.12 for ; Thu, 05 May 2022 14:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=HMG4mE8rmqWIq9EqADgMXTxl3uFJR2xB0VJQcWBBMS4=; b=jKj/2CklXswHj4dxXmJzRVwVcqsjM/848B3C1hwQeQftEw1tDazhwbzl7F1TfWctyv lnQ+5yGCJqXavI+TmAoHVBHB7RokC46WdodBrRU3jk+WL4yP/pE+hELnDeB568otcgd8 HXmRB56PKg2LCjfLsbhd76dvtJwQI3Bf1W2ebpk9Ji4E+xMaoVcUG/Lap8S7NANOdb52 bmx8/hfxjMWMM7Gzl302TO3Cv7yz1SLa2W1VZ/klhgoKrRa2hzJ+uzOiMts7rqJK8rhV JCIUjcPggXEYvu36QSYi6NO0YnBRC7/4qvyCxFxspiB4+R8etW+62OEwXHy7FacTMNG2 9pow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HMG4mE8rmqWIq9EqADgMXTxl3uFJR2xB0VJQcWBBMS4=; b=b168akkIq49qK6ozmHEwS18lWtrrDNhC5B2gq022LfQpYhR0XChKasHCA9lrTsbS7n bymoeenQTNXRrbwfr1USvBnd0o2zQamJA63DKlvLh00cr8UQzb/JOdDzCxWFo3ysMqdp cWxe10CXG5Y7/ABDduBm0ntkgDE4VvTzYIz/j5EVuNp6wVr61YItmNbMWJYyxoAymy7A W4RHU7p2u3TVlbi5SbZvGLfXQR3/nmq5P1TWa0HXLPAOv7qWyN4Uv6Zh396NeL1LAKNq 07E9C5ZHg/UeU7y/+KGHRMBlqDvhCtYqPJcjSQNOLzp4yjmeSLnTACE5kFQUQQXolUvJ qfkQ== X-Gm-Message-State: AOAM530nhRxf8KjPyxK1mTR0HMnGD/haDEQ//N4pkoYhqVaGmhapm2cI nHuhaxPtlLnGkJqjHiJcLwIVaYq78R72FCQsupf8VHKc28PWLWKQ X-Google-Smtp-Source: ABdhPJw+R1Z8Gyy+VWG2tIlH09wWhKNysH6lVBMIWY4BfGwcjhmRFAvRGrB7OOnZ6BVEYmqMScN+XcjH5wsl8/6gWN8= X-Received: by 2002:a05:6638:3896:b0:32b:95e2:cb81 with SMTP id b22-20020a056638389600b0032b95e2cb81mr79115jav.78.1651785027001; Thu, 05 May 2022 14:10:27 -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: Michael Schuster Date: Thu, 5 May 2022 23:10:18 +0200 Message-ID: Subject: FreeBSD, boot environments and /dev To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KvRDh0VD6z3Kt6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="jKj/2Ckl"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::d2c as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2c:from]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Hi all, while still working (slowly) on an answer to my own question on the right workflow to keep current up to date reliably with boot environments, I noticed that after creating and mounting a new BE, that new BE's /dev (eg /mnt/dev) is very sparsely populated: [22:44:45: ~ 0] $ ll /mnt/dev total 20 9 dr-xr-xr-x 4 root wheel 7 Apr 18 00:35 . 9 drwxr-xr-x 23 root wheel 30 May 5 22:44 .. 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 fd 1 lrwxr-xr-x 1 root wheel 12 Apr 17 20:41 log -> /var/run/log 1 -rw-r--r-- 1 root wheel 63 May 3 22:19 null 1 -rw-r--r-- 1 root wheel 1 May 3 22:18 null.bak 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 shm [22:44:48: ~ 0] $ (no matter whether I use "beadm create" or "bectl create -r") I can then mount devfs: # mount -t devfs devfs /mnt/dev and it will look (and work) as expected (eg for "pkg -c /mnt update" (*)) ... as long as the BE is mounted. When I try to boot from (into?) that BE though, it fails, and on the console I can see messages about missing /dev/... entries. I sneaked a peek into beinstall.sh, found no inspiration there, I'm afraid. I believe I noticed this apparent requirement to mount devfs separately not so long ago ... definitely this year, while I've been experimenting with boot environments for quite a bit longer. Was I just lucky all along, or did something change ... and, more importantly, how do I make my boot environments bootable again? TIA for hints, pointers, advice Michael *) I first noticed something was amiss when "pkg -c /mnt ... " complained about /dev/null missing, IIRC ... -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From nobody Thu May 5 22:12:37 2022 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 A73C31AC9E31 for ; Thu, 5 May 2022 22:12:45 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KvScW4sZ9z3lrM; Thu, 5 May 2022 22:12:43 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-111-80.area1b.commufa.jp [123.1.111.80]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 245MCbip009479; Fri, 6 May 2022 07:12:38 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 6 May 2022 07:12:37 +0900 From: Tomoaki AOKI To: Warner Losh Cc: FreeBSD Current , Warner Losh Subject: Re: Massive "Found bio_cmd = 0x5" with options CAM_IOSCHED_DYNAMIC Message-Id: <20220506071237.31a11f26398bcd5a698cac85@dec.sakura.ne.jp> In-Reply-To: References: <20220505090316.1df9a1bc2e07e69b1da8cb64@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KvScW4sZ9z3lrM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.48 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_HAM_MEDIUM(-0.89)[-0.891]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.111.80:received] X-ThisMailContainsUnwantedMimeParts: N On Wed, 4 May 2022 20:37:41 -0600 Warner Losh wrote: > On Wed, May 4, 2022 at 6:03 PM Tomoaki AOKI > wrote: > > > Hi. > > > > After updating src main git: f44280bf5fbb to git: 1599fc904d35, > > with options CAM_IOSCHED_DYNAMIC on kernel config file, > > A plenty of "Found bio_cmd = 0x5" appear on console and dmesg. > > > > With quick look under src/sys/, bio_cmd = 0x5 means BIO_FLUSH, > > and the printf() only appears on src/sys/cam/cam_iosched.c line 1621.[1] > > > > Maybe it actually wouldn't be harmful (just annoying), but possibly > > any conditions blocking BIO_FLUSH to reach there would be lost. > > (The printf() itself was already there at git: f44280bf5fbb.) > > > > If it's actualy not at all harmful, and BIO_FLUSH case is coming > > through here is intentional change, is it really needed to be printed? > > > > It's a useless printf. I've removed it and posted an analysis in the commit > message. Basically, read_bias == 0 will queue other operations to bio_queue > now, so the printf is a false positive to find transactions that shouldn't > be > on the queue. > > If you set read_bias = 1, then the messages will go away until you can > recompile. > > I also don't need to know the storage, since this is independent of the > periphs... > > Warner Thanks! Confirmed that... *Setting kern.cam.iosched.read_bias to any value from 1 to 100 via sysctl command didn't stop the flood. Even though it's defined via SYSCTL_INT() [not TUNABLE_INT()], it seems to act as pure tunable. *Setting kern.cam.iosched.read_bias=1 on /boot/loader.conf stopped the flood BEFORE rebuild. *Updating after git: a85fea31c5cb (actually, git: 9f580526e45a for me) stopped the flood even if kern.cam.iosched.read_bias=0 on boot. (Obvious from git: a85fea31c5cb.) > > > > There were 4 commits to cam_iosched.c within the span. > > > > cc1572ddeb8cd82879ce0cca634bf6a8830c0f40 [2] > > cam iosched: Remove write bias when read bias = 0 > > b65803ba5773d5fb37fa2403105db199569a5811 [3] > > cam iosched: default to no read bias in dynamic ioscheduling > > d592c0db8ba773c143eeea28610288f800fa651a [4] > > cam: add hw.cam.iosched.read_bias > > 1599fc904d35cfa8eecad92818d1f4b55de6818f [5] > > iosched: Move bio_next() inside of the CAM_IOSCHED_DYNAMIC ifdef > > > > > > [1] https://cgit.freebsd.org/src/tree/sys/cam/cam_iosched.c#n1621 > > > > [2] > > > > https://cgit.freebsd.org/src/commit/?id=cc1572ddeb8cd82879ce0cca634bf6a8830c0f40 > > > > [3] > > > > https://cgit.freebsd.org/src/commit/?id=b65803ba5773d5fb37fa2403105db199569a5811 > > > > [4] > > > > https://cgit.freebsd.org/src/commit/?id=d592c0db8ba773c143eeea28610288f800fa651a > > > > [5] > > > > https://cgit.freebsd.org/src/commit/?id=1599fc904d35cfa8eecad92818d1f4b55de6818f > > > > > > Regards. > > > > -- > > Tomoaki AOKI > > -- Tomoaki AOKI From nobody Thu May 5 22:21:00 2022 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 A66931ACAB3D for ; Thu, 5 May 2022 22:15:16 +0000 (UTC) (envelope-from jwmaag@gmail.com) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KvSgR53TWz3n7M for ; Thu, 5 May 2022 22:15:15 +0000 (UTC) (envelope-from jwmaag@gmail.com) Received: by mail-yb1-xb35.google.com with SMTP id w187so9991606ybe.2 for ; Thu, 05 May 2022 15:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HeloBSN9MjOIB0aa398tsYHXq25CMPbVkHfG0bCUD9Y=; b=BP/Nd6ILB0Ra+ue/2a3hqVRNyoFU8DE6NYSXC81M9tCVoGanoEbk5p7ldzz+cqgRge 8FlAqRQFlnFq2J3HhBf+8xB5JiEKxAEnCWyVjm/Pit1IAJK5RIGCpm2LXluw1B1YN9KM n8FQ+2QfTZpmTc8iOxX/KSm6LTJvx8hiy7n3aS0/VSchNUu7N7887rgexFPf3Acvt27F hW1Y2xCmfzLErTq9XQAawWdVMv0rPBetGCtSnTF3iBIKJnBZg53yMQ9JBy8aI6LbK6NF fPsLbJDM2Tk1NC5549rHu0WSK7F7EeHO61VNcR5h3MdE5gvN4vsAOw0aA6bTOr3cixrQ kLdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HeloBSN9MjOIB0aa398tsYHXq25CMPbVkHfG0bCUD9Y=; b=jE6x2aRGthxMl+nn6VaHpNjXAzU/Awt725uxwk8CCT06aWqIwcJuNhMAoYhyOGxmM4 3mZUsPMlGN3AGBuvFgI27ygGKLJ4Y25G8WVZ0l7Ucsp4tUde45Q6cV7YilTCaaJRwt2j 2vSXY2uAiNR9A7Q33oxiDnPZMLOjLVvujk8SF/ZQ7+gtn+0XG6eYQmmQ8ZpLeuW0VQNp AsKALxuifejVSJJySXYErxpt9vVkx6gTXWpmYaA50PeEqSHid7Kk4tfpUjzzllxWZljZ ZRmLr0kJDEEMvWhs12IvjRptg8wwg2z3DeLc9gONqMmDUZX0tlYOnqFXAdxxlF77Ubt2 NOTQ== X-Gm-Message-State: AOAM531XrPqKsZzh/ORwCL2L/UXJABXl+fRGGRpqe/V5lvYi9X1XGkHy OmNnjbZudiDPtqwJmX9v092TDGjTLB/r2bT5Id1pGp+feJs= X-Google-Smtp-Source: ABdhPJw96PNqviRSlOJ1Obldpurom5otKEb3AQAIrEq9DXwagKU0iBjJGG7Bq4wAeMOWTGSFcOgkMNuJ1MWWaNuJuyc= X-Received: by 2002:a25:4506:0:b0:648:cfc2:301d with SMTP id s6-20020a254506000000b00648cfc2301dmr274862yba.380.1651788915013; Thu, 05 May 2022 15:15:15 -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: Wes Maag Date: Thu, 5 May 2022 17:21:00 -0500 Message-ID: Subject: Re: FreeBSD, boot environments and /dev To: Michael Schuster Cc: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="00000000000085ff5605de4b13ed" X-Rspamd-Queue-Id: 4KvSgR53TWz3n7M X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="BP/Nd6IL"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jwmaag@gmail.com designates 2607:f8b0:4864:20::b35 as permitted sender) smtp.mailfrom=jwmaag@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b35:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000085ff5605de4b13ed Content-Type: text/plain; charset="UTF-8" On Thu, May 5, 2022 at 4:10 PM Michael Schuster wrote: > Hi all, > > while still working (slowly) on an answer to my own question on the > right workflow to keep current up to date reliably with boot > environments, I noticed that after creating and mounting a new BE, > that new BE's /dev (eg /mnt/dev) is very sparsely populated: > > [22:44:45: ~ 0] $ ll /mnt/dev > total 20 > 9 dr-xr-xr-x 4 root wheel 7 Apr 18 00:35 . > 9 drwxr-xr-x 23 root wheel 30 May 5 22:44 .. > 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 fd > 1 lrwxr-xr-x 1 root wheel 12 Apr 17 20:41 log -> /var/run/log > 1 -rw-r--r-- 1 root wheel 63 May 3 22:19 null > 1 -rw-r--r-- 1 root wheel 1 May 3 22:18 null.bak > 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 shm > [22:44:48: ~ 0] $ > > (no matter whether I use "beadm create" or "bectl create -r") > > I can then mount devfs: > # mount -t devfs devfs /mnt/dev > > and it will look (and work) as expected (eg for "pkg -c /mnt update" > (*)) ... as long as the BE is mounted. > When I try to boot from (into?) that BE though, it fails, and on the > console I can see messages about missing /dev/... entries. I sneaked a > peek into beinstall.sh, found no inspiration there, I'm afraid. > > I believe I noticed this apparent requirement to mount devfs > separately not so long ago ... definitely this year, while I've been > experimenting with boot environments for quite a bit longer. Was I > just lucky all along, or did something change ... and, more > importantly, how do I make my boot environments bootable again? > > TIA for hints, pointers, advice > Michael > > *) I first noticed something was amiss when "pkg -c /mnt ... " > complained about /dev/null missing, IIRC ... > -- > Michael Schuster > http://recursiveramblings.wordpress.com/ > recursion, n: see 'recursion' > > getting /dev/null errors with pkg -c makes sense. I wouldn't expect /dev to contain anything after a create. Why it is not populated on boot seems odd to me though... It's possible, if you created a deep boot environment, you created a pool/ROOT/dev dataset and it is overwriting the initial /dev from boot (I have not tested this theory). Tough to say without more information about the BE layout, and maybe a look at fstab. FWIW I typically run "pkg -r /tmp/be_mount.XXXX" after mounting with "bectl mount" which should give you the same effect as -c without the rooted devfs requirement -- Wes --00000000000085ff5605de4b13ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 5, 2022 at 4:10 PM Michae= l Schuster <michaelsprivate= @gmail.com> wrote:
Hi all,

while still working (slowly) on an answer to my own question on the
right workflow to keep current up to date reliably with boot
environments, I noticed that after creating and mounting a new BE,
that new BE's /dev (eg /mnt/dev) is very sparsely populated:

[22:44:45: ~ 0] $ ll /mnt/dev
total 20
9 dr-xr-xr-x=C2=A0 =C2=A04 root=C2=A0 wheel=C2=A0 =C2=A07 Apr 18 00:35 . 9 drwxr-xr-x=C2=A0 23 root=C2=A0 wheel=C2=A0 30 May=C2=A0 5 22:44 ..
1 drwxr-xr-x=C2=A0 =C2=A02 root=C2=A0 wheel=C2=A0 =C2=A02 Apr 18 00:35 fd 1 lrwxr-xr-x=C2=A0 =C2=A01 root=C2=A0 wheel=C2=A0 12 Apr 17 20:41 log ->= /var/run/log
1 -rw-r--r--=C2=A0 =C2=A01 root=C2=A0 wheel=C2=A0 63 May=C2=A0 3 22:19 null=
1 -rw-r--r--=C2=A0 =C2=A01 root=C2=A0 wheel=C2=A0 =C2=A01 May=C2=A0 3 22:18= null.bak
1 drwxr-xr-x=C2=A0 =C2=A02 root=C2=A0 wheel=C2=A0 =C2=A02 Apr 18 00:35 shm<= br> [22:44:48: ~ 0] $

(no matter whether I use "beadm create" or "bectl create -r&= quot;)

I can then mount devfs:
# mount -t devfs devfs /mnt/dev

and it will look (and work) as expected (eg for "pkg -c /mnt update&qu= ot;
(*)) ... as long as the BE is mounted.
When I try to boot from (into?) that BE though, it fails, and on the
console I can see messages about missing /dev/... entries. I sneaked a
peek into beinstall.sh, found no inspiration there, I'm afraid.

I believe I noticed this apparent requirement to mount devfs
separately not so long ago ... definitely this year, while I've been experimenting with boot environments for quite a bit longer. Was I
just lucky all along, or did something change ... and, more
importantly, how do I make my boot environments bootable again?

TIA for hints, pointers, advice
Michael

*) I first noticed something was amiss when "pkg -c /mnt ... " complained about /dev/null missing, IIRC ...
--
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'

=C2=A0
getting /dev/null errors with p= kg -c makes sense. I wouldn't expect /dev to contain anything after a c= reate.

Why it is not populated on boot seems odd t= o me though... It's possible, if you created a deep boot environment, y= ou created a pool/ROOT/dev dataset
and it is overwriting the init= ial /dev from boot (I have not tested this theory). Tough to say without mo= re information about the BE layout, and maybe a look at fstab.

FWIW I typically run "pkg -r /tmp/be_mount.XXXX"= after mounting with "bectl mount" which should give you the same= effect as -c without the rooted devfs requirement

=
--
Wes
=C2=A0
--00000000000085ff5605de4b13ed-- From nobody Sat May 7 15:32:37 2022 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 887DA1ABD51B for ; Sat, 7 May 2022 15:32:52 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KwWfC3Wq0z3pvJ for ; Sat, 7 May 2022 15:32:51 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x136.google.com with SMTP id z12so6598693ilp.8 for ; Sat, 07 May 2022 08:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jWUlQRxMnrZGj7Eix01X95Bo15Q82y/E0D6FrjvLX1I=; b=ALySjmYIVkfsgEZm5taYL9WU7AyyUiA8DxhefiMGfNiD+iWP+RfcyY8Lvao39ajJ43 NDa4t753Ow3cWLCpJvOvseSmErj8LlZo6j/KOOqEDwslQa6SBE5D3E+0+svVNLUQV8iT d8vgzz+oE4TSVtoIt1pDgbvRrTePyZMQvaekgkGeQLYXegHey7jSbj0FhEHG98iwYgH3 sFG5J9GNlctCgDx3M8HZVZTVVFxYbp9ff0O7Vb17TR4JlKPmEU+MoA4mBDJv2ikbO6/g watuYFbzojpDZYR9SOuvXs2YbS72e1pl8s+n0TKXVtTIXANEKfCQiJC+54dNVcaMWH0f GKPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jWUlQRxMnrZGj7Eix01X95Bo15Q82y/E0D6FrjvLX1I=; b=b9ObS4TOQufc2meH+72ikkxaww6a6dKUzeUlcQ/UhnA6XS3jhB5OHkyHJWWxpJIHib v8SoJRudCVlx8PZ4hvBaC00dyptO+1Mjn5OTj8IcTcNg9He7Pa2qQdyG1juIjqmcbokf v6y1wIrsB35GmAgH/gvPlUoIQC5bCTyi6A9kfjM+u1xcYSfexpgHToiI3rjygq/rDJ/H m4qdGtQd05V+u9HPMpcGUZnV00IIJbhnnirKGyr9jbKsAezWXZZ/MWvMOPypr9O22yFW jskX8U9Rs7h0hAJl9sK5KaX7u7tDDsqjnBXdwAn3NW89TjbdhjFBbgtWOf9XxKsFD8sN UIWg== X-Gm-Message-State: AOAM531DJiphUnS6zqDxlZ3rHP3JO3kMrenakuPJfcpxuACVoNI+vzF3 kzG7i99s6hUhTkB8iZCnMb1PEVKt8DhpqFlDqaez4PWBdd5lV3Y6 X-Google-Smtp-Source: ABdhPJyOstY//Phms8MTDERgIALKLQXxtZfCP9xnV9QwoiOkyrhJB1JZITOy4vcxaVwErAnGf0nzUHdvvmkt/7EncGo= X-Received: by 2002:a05:6e02:5a2:b0:2cf:8e6e:a5ab with SMTP id k2-20020a056e0205a200b002cf8e6ea5abmr1569137ils.63.1651937565372; Sat, 07 May 2022 08:32:45 -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: Michael Schuster Date: Sat, 7 May 2022 17:32:37 +0200 Message-ID: Subject: Re: FreeBSD, boot environments and /dev To: Wes Maag Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KwWfC3Wq0z3pvJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ALySjmYI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::136 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::136:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Wes, finally I get round to responding (below) ... On Fri, May 6, 2022 at 12:15 AM Wes Maag wrote: > > > > On Thu, May 5, 2022 at 4:10 PM Michael Schuster wrote: >> >> Hi all, >> >> while still working (slowly) on an answer to my own question on the >> right workflow to keep current up to date reliably with boot >> environments, I noticed that after creating and mounting a new BE, >> that new BE's /dev (eg /mnt/dev) is very sparsely populated: >> >> [22:44:45: ~ 0] $ ll /mnt/dev >> total 20 >> 9 dr-xr-xr-x 4 root wheel 7 Apr 18 00:35 . >> 9 drwxr-xr-x 23 root wheel 30 May 5 22:44 .. >> 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 fd >> 1 lrwxr-xr-x 1 root wheel 12 Apr 17 20:41 log -> /var/run/log >> 1 -rw-r--r-- 1 root wheel 63 May 3 22:19 null >> 1 -rw-r--r-- 1 root wheel 1 May 3 22:18 null.bak >> 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 shm >> [22:44:48: ~ 0] $ >> >> (no matter whether I use "beadm create" or "bectl create -r") >> >> I can then mount devfs: >> # mount -t devfs devfs /mnt/dev >> >> and it will look (and work) as expected (eg for "pkg -c /mnt update" >> (*)) ... as long as the BE is mounted. >> When I try to boot from (into?) that BE though, it fails, and on the >> console I can see messages about missing /dev/... entries. I sneaked a >> peek into beinstall.sh, found no inspiration there, I'm afraid. >> >> I believe I noticed this apparent requirement to mount devfs >> separately not so long ago ... definitely this year, while I've been >> experimenting with boot environments for quite a bit longer. Was I >> just lucky all along, or did something change ... and, more >> importantly, how do I make my boot environments bootable again? >> >> TIA for hints, pointers, advice >> Michael >> >> *) I first noticed something was amiss when "pkg -c /mnt ... " >> complained about /dev/null missing, IIRC ... >> -- >> Michael Schuster >> http://recursiveramblings.wordpress.com/ >> recursion, n: see 'recursion' >> > > getting /dev/null errors with pkg -c makes sense. I wouldn't expect /dev to contain anything after a create. as I wrote, I *thought* that worked automatically ... apparently not. > Why it is not populated on boot seems odd to me though... It's possible, if you created a deep boot environment, you created a pool/ROOT/dev dataset > and it is overwriting the initial /dev from boot (I have not tested this theory). Tough to say without more information about the BE layout, and maybe a look at fstab. (after beadm create and beadm mount): $ zfs list -tall [...] tank/ROOT/BE_20220507_171901_adm 184K 397G 17.9G / tank/ROOT/BE_20220507_171901_adm/ports 8K 397G 1.92G /usr/ports tank/ROOT/BE_20220507_171901_adm/src 8K 397G 2.57G /usr/src $ mount | grep dev devfs on /dev (devfs) /dev/nvd0p1 on /boot/efi (msdosfs, local) devfs on /compat/linux/dev (devfs) fdescfs on /compat/linux/dev/fd (fdescfs) tmpfs on /compat/linux/dev/shm (tmpfs, local) $ cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/nvd0p1 /boot/efi msdosfs rw 2 2 /dev/nvd0p3 none swap sw 0 0 proc /proc procfs rw 0 0 > FWIW I typically run "pkg -r /tmp/be_mount.XXXX" after mounting with "bectl mount" which should give you the same effect as -c without the rooted devfs requirement good point ... until now, "pkg -c" worked as expected, I never looked further ;-) I'll keep it in mind! I expected (perhaps naively) that with -c, pkg would be using the "new" stuff I'd installed in the previous step (see below), not the currently running bits ... Any thoughts on that? One more data point, perhaps that's relevant: I've been updating these BEs using a sequence of installing freshly built current into /mnt (using "DESTDIR=/mnt"), following by a few ports (drm-devel, primarily), and then doing pkg update/upgrade. thx Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From nobody Mon May 9 06:25:44 2022 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 1B4A91AB889A for ; Mon, 9 May 2022 06:26:02 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KxWQK3Dqfz3vcr for ; Mon, 9 May 2022 06:26:01 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd2b.google.com with SMTP id c125so14259977iof.9 for ; Sun, 08 May 2022 23:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sVSSUKYYxshkFWfluA/1a7FeoQ8bdPEYwsrLQkq357E=; b=LWbfyqiEHMSif+bc+ieUEQ0wSVz2kC+5HQ2YnsoihmNY6eeiKWNxOQ/4zBmM2VkbPB XJ4c+rXgkSvaSEcbIn3cs45yPPtTyohrfQStC3Uu7Fzxz28xOrDNcifaHD1purcXLnrV frlMan22ANtog7y3f0iB63CRXE6Ul5Xc7d9eb3hjHuBQSZ4GKfKC3/zeUE9JRtmAIecY Fgra6rji2Q+Z0wk04avJWVuj6y4+xNENTS44qYia3zinoQ3AkhwYZTAlhe30y8zvU7hU YQLHUREPTZR+3jkD10wrIJehP1LhqXzxyvaqersLHU49ZLWJvXK8t7y8kRqehsGY6OJP 7tyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sVSSUKYYxshkFWfluA/1a7FeoQ8bdPEYwsrLQkq357E=; b=l+VLY7a5NZZcQiBSBCPydkcVAVS6VXivFavXsV30HMNKzmYsclnYO+9gbSPUVPYOT4 0cG/hbpvnKvl7UM4TU/G6Il0gfDyIof0e5P/yEXflSTkv1pus2wSxe7pzlds6BIECF80 Ld7wfH5gjmVszU/DXeg1/T6J7EuS5+QIkq+mDz7IxUyaZUmBQFMsCm5zK4p9pYebEAnG gcir9W76yrHii6j/fl5KByRaCcyqvtlTbaZsW3FKSP3qEODnSdb9YRACOWYpmMM4FRSO toIPvIO9eem62QTLRxtbf+V/4ZSab9mWcqpEIM1MgaQ/kxqeRd/GOyah1UTDm/zc4h58 qsKw== X-Gm-Message-State: AOAM530e4esfVgBCIngsc2c2Gq+AoEymKSX3lCDhI/DDhVHGUTOg4D9U B4n7L9HYpk4/MZ6tq9AAa7EV05OQAry5tX6BQr0NZbCMo1eUY0ZI X-Google-Smtp-Source: ABdhPJyHTKCiaOYp6NT9Tol9wXZLtVc/mEhPSq63uTZWxO38g2Rige7Oxxx3afjxhTvoQQsmXGj8gsv8c37E9X6Tgic= X-Received: by 2002:a6b:c808:0:b0:657:c3ee:623c with SMTP id y8-20020a6bc808000000b00657c3ee623cmr5868823iof.48.1652077555254; Sun, 08 May 2022 23:25: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: In-Reply-To: From: Michael Schuster Date: Mon, 9 May 2022 08:25:44 +0200 Message-ID: Subject: Re: FreeBSD, boot environments and /dev To: Wes Maag Cc: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000d28da405de8e4748" X-Rspamd-Queue-Id: 4KxWQK3Dqfz3vcr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=LWbfyqiE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::d2b as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2b:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000d28da405de8e4748 Content-Type: text/plain; charset="UTF-8" On Fri, May 6, 2022 at 12:15 AM Wes Maag wrote: > > > On Thu, May 5, 2022 at 4:10 PM Michael Schuster > wrote: > >> Hi all, >> >> while still working (slowly) on an answer to my own question on the >> right workflow to keep current up to date reliably with boot >> environments, I noticed that after creating and mounting a new BE, >> that new BE's /dev (eg /mnt/dev) is very sparsely populated: >> >> [22:44:45: ~ 0] $ ll /mnt/dev >> total 20 >> 9 dr-xr-xr-x 4 root wheel 7 Apr 18 00:35 . >> 9 drwxr-xr-x 23 root wheel 30 May 5 22:44 .. >> 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 fd >> 1 lrwxr-xr-x 1 root wheel 12 Apr 17 20:41 log -> /var/run/log >> 1 -rw-r--r-- 1 root wheel 63 May 3 22:19 null >> 1 -rw-r--r-- 1 root wheel 1 May 3 22:18 null.bak >> 1 drwxr-xr-x 2 root wheel 2 Apr 18 00:35 shm >> [22:44:48: ~ 0] $ >> >> (no matter whether I use "beadm create" or "bectl create -r") >> >> I can then mount devfs: >> # mount -t devfs devfs /mnt/dev >> >> and it will look (and work) as expected (eg for "pkg -c /mnt update" >> (*)) ... as long as the BE is mounted. >> When I try to boot from (into?) that BE though, it fails, and on the >> console I can see messages about missing /dev/... entries. I sneaked a >> peek into beinstall.sh, found no inspiration there, I'm afraid. >> >> I believe I noticed this apparent requirement to mount devfs >> separately not so long ago ... definitely this year, while I've been >> experimenting with boot environments for quite a bit longer. Was I >> just lucky all along, or did something change ... and, more >> importantly, how do I make my boot environments bootable again? >> >> TIA for hints, pointers, advice >> Michael >> >> *) I first noticed something was amiss when "pkg -c /mnt ... " >> complained about /dev/null missing, IIRC ... >> >> > getting /dev/null errors with pkg -c makes sense. I wouldn't expect /dev > to contain anything after a create. > > Why it is not populated on boot seems odd to me though... It's possible, > if you created a deep boot environment, you created a pool/ROOT/dev dataset > and it is overwriting the initial /dev from boot (I have not tested this > theory). Tough to say without more information about the BE layout, and > maybe a look at fstab. > > FWIW I typically run "pkg -r /tmp/be_mount.XXXX" after mounting with > "bectl mount" which should give you the same effect as -c without the > rooted devfs requirement > thx Wes and others for feedback, on or off list. For now I'd like to keep the simplest setting in focus: When I do: # beadm create new_BE # beadm activate new_BE # reboot I would expect new_BE to boot and also otherwise to all intents and purposes behave just like the previous BE I just "left"; similarly, if I skip the 'activate' step and select new_BE from the FreeBSD boot menu. thx Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' --000000000000d28da405de8e4748 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, May = 6, 2022 at 12:15 AM Wes Maag <jwmaag= @gmail.com> wrote:


On Thu, May 5, 2022 at 4:1= 0 PM Michael Schuster <michaelsprivate@gmail.com> wrote:
Hi all,

while still working (slowly) on an answer to my own question on the
right workflow to keep current up to date reliably with boot
environments, I noticed that after creating and mounting a new BE,
that new BE's /dev (eg /mnt/dev) is very sparsely populated:

[22:44:45: ~ 0] $ ll /mnt/dev
total 20
9 dr-xr-xr-x=C2=A0 =C2=A04 root=C2=A0 wheel=C2=A0 =C2=A07 Apr 18 00:35 . 9 drwxr-xr-x=C2=A0 23 root=C2=A0 wheel=C2=A0 30 May=C2=A0 5 22:44 ..
1 drwxr-xr-x=C2=A0 =C2=A02 root=C2=A0 wheel=C2=A0 =C2=A02 Apr 18 00:35 fd 1 lrwxr-xr-x=C2=A0 =C2=A01 root=C2=A0 wheel=C2=A0 12 Apr 17 20:41 log ->= /var/run/log
1 -rw-r--r--=C2=A0 =C2=A01 root=C2=A0 wheel=C2=A0 63 May=C2=A0 3 22:19 null=
1 -rw-r--r--=C2=A0 =C2=A01 root=C2=A0 wheel=C2=A0 =C2=A01 May=C2=A0 3 22:18= null.bak
1 drwxr-xr-x=C2=A0 =C2=A02 root=C2=A0 wheel=C2=A0 =C2=A02 Apr 18 00:35 shm<= br> [22:44:48: ~ 0] $

(no matter whether I use "beadm create" or "bectl create -r&= quot;)

I can then mount devfs:
# mount -t devfs devfs /mnt/dev

and it will look (and work) as expected (eg for "pkg -c /mnt update&qu= ot;
(*)) ... as long as the BE is mounted.
When I try to boot from (into?) that BE though, it fails, and on the
console I can see messages about missing /dev/... entries. I sneaked a
peek into beinstall.sh, found no inspiration there, I'm afraid.

I believe I noticed this apparent requirement to mount devfs
separately not so long ago ... definitely this year, while I've been experimenting with boot environments for quite a bit longer. Was I
just lucky all along, or did something change ... and, more
importantly, how do I make my boot environments bootable again?

TIA for hints, pointers, advice
Michael

*) I first noticed something was amiss when "pkg -c /mnt ... " complained about /dev/null missing, IIRC ...

=C2=A0
getting /dev/null errors with p= kg -c makes sense. I wouldn't expect /dev to contain anything after a c= reate.

Why it is not populated on boot seems odd t= o me though... It's possible, if you created a deep boot environment, y= ou created a pool/ROOT/dev dataset
and it is overwriting the init= ial /dev from boot (I have not tested this theory). Tough to say without mo= re information about the BE layout, and maybe a look at fstab.

FWIW I typically run "pkg -r /tmp/be_mount.XXXX"= after mounting with "bectl mount" which should give you the same= effect as -c without the rooted devfs requirement

thx Wes and others for fe= edback, on or off list.
For now I'd like to kee= p the simplest setting in focus:

When I do:
# beadm create new_BE
# beadm activate new_BE
# reboot

I would expect new_BE t= o boot and also otherwise to all intents and purposes behave just like the = previous BE I just "left"; similarly, if I skip the 'activate= ' step and select new_BE from the FreeBSD boot menu.

thx
Michael
= --
recursion, n: see 'recursion'
<= /div> --000000000000d28da405de8e4748-- From nobody Mon May 9 08:04:05 2022 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 86E241ACCB33 for ; Mon, 9 May 2022 08:04:32 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 4KxYbz2qQGz4c7D for ; Mon, 9 May 2022 08:04:31 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8AE6F5C0108; Mon, 9 May 2022 04:04:25 -0400 (EDT) Received: from imap44 ([10.202.2.94]) by compute2.internal (MEProxy); Mon, 09 May 2022 04:04:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1652083465; x=1652169865; bh=FK Am42C5Xkl9GLeyKiRSFmtA4vg0ibyHDAt0Hp36dzo=; b=Zmk5VIKbdwR7+7GoZs DpxupEEqhZpXAp7nXUZAQ+kFMHiUpl+MsogiEDkdiDr3mWWRt6Xu85fd+VQiZryf M4PEbtLN4tNb/5ghTbs6mj/1ZfcVtu0JW5rpfaHG6mA7FUtL5JzGiBdKnHBgzFet NhoepZqMiyc0vsYQYwhNvy50Eykb3haksXzpCQJsK+yMNgQD8f2qcNG9tZZRokvY ynHOKDnfv4ZkiNzcnnGW6Rz2brRpY2FLTP0w6r2/h26pSjKohPrJLsH7vXq1snSK DLYShO2/P9+/RkLYPe/jpCjDEZfT4OZD09kpoTcPTffLrqR2CIgr5VJAiYGWOPhf cd7w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1652083465; x= 1652169865; bh=FKAm42C5Xkl9GLeyKiRSFmtA4vg0ibyHDAt0Hp36dzo=; b=R 3XdR95RgIeQz0AWSlXV97dpoczKX/dBfiHBOHJDGIduQqlzVryiF7otGdZRMM+Hz u0AjajXDHWn+1iIFdArY9fiC0nyma7kl1nnfoJZcCBDidQMNK6LM9xtdgpILV8hH BxeHhU27guUfDMXZ82OuTELwm+bkcDpbOhoUIujOEOv7UX1OMNCPRYB5edrWmhRk qjhAVFO2083hVlD1Sc0MfIlXiZuh8e3ztuURrV4oxna5fpP0w1ljyUgmA1eXrepC 61BSfte+C/tG7EKb2IUmYXtCMgQ9S3zx+xGAYDBa0JYLTEi0ZXVri/bG5uyh8Iz1 eQVAJA2lo4Z3HmTY+AuVg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeekgdduvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfffgr vhgvucevohhtthhlvghhuhgsvghrfdcuoegutghhsehskhhunhhkfigvrhhkshdrrghtqe enucggtffrrghtthgvrhhnpedttdetuddvffeuvdeihfejtdelgfeglefhleeitefghedt udeigedutdektdduhfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegutghhsehskhhunhhkfigvrhhkshdrrght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4ABF736A005E; Mon, 9 May 2022 04:04:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 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 Message-Id: <481e0739-bdc4-4ce6-a856-a80cf5294d03@www.fastmail.com> In-Reply-To: References: Date: Mon, 09 May 2022 08:04:05 +0000 From: "Dave Cottlehuber" To: "Michael Schuster" , "Wes Maag" Cc: freebsd-current Subject: Re: FreeBSD, boot environments and /dev Content-Type: text/plain X-Rspamd-Queue-Id: 4KxYbz2qQGz4c7D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm2 header.b=Zmk5VIKb; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="R 3XdR95"; dmarc=none; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 66.111.4.28 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-3.59 / 15.00]; XM_UA_NO_VERSION(0.01)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.28:from]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm2,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[dch]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[skunkwerks.at]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 9 May 2022, at 06:25, Michael Schuster wrote: > On Fri, May 6, 2022 at 12:15 AM Wes Maag wrote: >> >> >> On Thu, May 5, 2022 at 4:10 PM Michael Schuster wrote: >>> Hi all, >>> >>> while still working (slowly) on an answer to my own question on the >>> right workflow to keep current up to date reliably with boot >>> environments, I noticed that after creating and mounting a new BE, >>> that new BE's /dev (eg /mnt/dev) is very sparsely populated: This is expected; /dev would usually be empty until devfs is mounted. Looking into the unmounted /dev via the last zfs snapshot of your / filesystem should also be empty: $ ls -AFGhl /.zfs/snapshot/$(ls -rt /.zfs/snapshot/ | tail -1)/dev total 0 If it's not I'd guess these are stray garbage from BE experiments where /dev wasn't mounted and various scripts & tools tried to pipe via /dev/{fd,zero,null,...}. If you created a hypothetical "empty" BE from scratch, unpacked src tarballs into it, it would also be empty. A+ Dave From nobody Tue May 10 07:37:18 2022 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 E6AB91AD39D4 for ; Tue, 10 May 2022 07:37:42 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (venus.morante.net [63.247.147.163]) by mx1.freebsd.org (Postfix) with ESMTP id 4Ky8yY5qJLz3sjv for ; Tue, 10 May 2022 07:37:41 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (zenon.morante.com [192.168.0.233]) by saturn.morante.com (Postfix) with ESMTP id 28D3E11F809 for ; Tue, 10 May 2022 03:37:34 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on zenon.morante.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED,NICE_REPLY_A, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.5 X-Spam-RelaysUntrusted: Received-SPF: pass (venus.morante.net: 192.168.0.2 is whitelisted) receiver=venus.morante.net; client-ip=192.168.0.2; helo=[192.168.0.2]; envelope-from=daniel@morante.net; x-software=SPF Validation 2.001 http://pacyworld.com/spf with libspf2-1.2.10; Received: from [192.168.0.2] (my-room.morante.com [192.168.0.2]) by venus.morante.net (Postfix) with ESMTPSA id 9395C11F816 for ; Tue, 10 May 2022 03:37:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morante.net; s=default; t=1652168253; bh=nUR6zHDrQXqh52NZUotzJ1KdlX7SzBAH6idiwMBq4nY=; h=Date:Subject:To:References:From:In-Reply-To; b=atg/zcPBmFvvBnouxk7AviFZSA1N/+86oREPEi47x5ewsEGw2BN8bRI72wyy4i7WU ykmy4k0IQC/6Eocv2iHxaESPZR2zE8doT/j492+gKsl7huwCNJeMplFEASypsFmbIp EYw5e8zFc0aWZpNpEZpW/FKvjIWfkFoktI0z1hqM= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.104.2 at zenon.morante.com Message-ID: <7ba934b2-af12-4006-2828-a1741e84ffa2@morante.net> Date: Tue, 10 May 2022 03:37:18 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Testing 14-CURRENT-f44280bf5fb on aarch64 Content-Language: en-US To: freebsd-current@freebsd.org References: <61edce0e-948a-d9da-47b9-090a9201694e@selasky.org> From: Daniel Morante In-Reply-To: <61edce0e-948a-d9da-47b9-090a9201694e@selasky.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Ky8yY5qJLz3sjv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=morante.net header.s=default header.b="atg/zcPB"; dmarc=pass (policy=reject) header.from=morante.net; spf=pass (mx1.freebsd.org: domain of daniel@morante.net designates 63.247.147.163 as permitted sender) smtp.mailfrom=daniel@morante.net X-Spamd-Result: default: False [-3.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[morante.net:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[morante.net:+]; DMARC_POLICY_ALLOW(-0.50)[morante.net,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:30221, ipnet:63.247.144.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Updated to the latest (14.0-CURRENT #2 main-n255521-10f44229dcd: Tue May 10 02:52:27 EDT 2022) and removed the sysctl option (hw.usb.disable_enumeration=1). Still seeing the problem.  The below just endlessly prints out on the console: ``` FreeBSD/arm64 (mars.morante.com) (ttyu0) login: ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub_attach: port 1 power on or off failed, USB_ERR_IOERROR uhub_attach: port 2 power on or off failed, USB_ERR_IOERROR uhub_attach: port 3 power on or off failed, USB_ERR_IOERROR uhub_attach: port 4 power on or off failed, USB_ERR_IOERROR uhub4: 4 ports with 4 removable, self powered uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 1 uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 2 uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 3 uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 4 ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.2: at usbus0 (disconnected) uhub4: at uhub0, port 1, addr 1 (disconnected) uhub4: detached ugen0.2: at usbus0 uhub4 numa-domain 0 on uhub0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ``` On 5/4/2022 4:10 AM, Hans Petter Selasky wrote: > On 5/4/22 09:49, Daniel Morante wrote: >> I'm still using the sysctl option "hw.usb.disable_enumeration=1" to >> prevent the USB devices from disconnecting/reconnecting every few >> seconds.  Other than that the improvement in stability with >> 14-CURRENT on aarach64 on this hardware is much better since the last >> time I tried, back in late February 2022. > > Hi Daniel, > > Could you try the very latest 14-current as of now? I've made a couple > of USB fixes which may fix the issue you are seeing. > > --HPS > From nobody Tue May 10 08:01:52 2022 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 22C8A1AD801D for ; Tue, 10 May 2022 08:02:09 +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 4Ky9Vm07x4z4Qqn for ; Tue, 10 May 2022 08:02:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652169719; bh=y6FauHuBTXpRD5lVsu35PiXIGHmwod6NCGC8lQDPs6k=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lsT7ZgK9efvbZt0L67X2C691Rv6aOvYoKBRSt/OsBLxqnl/k9d+uEKSLz2cz51YPfDTLMyyEA8ahe7EBsssbMtsdFdVdKacwtUmIdf9OWKsEdS/HbvSCVVRs0ONt87feXAy27HoSGZeShXFl3H4t5jbCnA4SSJccZxQlrMEn/ChB7MKDnosVz4cBOu2216RyccSq1/vpfLcTSSZEmKeVLTe87DSObnJ0i2n+E8RRJCutD6HTJEVQi45iF7nW/PyuGZtiIGAJQegYGNqdQZkVg5R5an8WS9nbJq9mqUB/K16L3r5nUFq/M8j+5ejvoFof8PV3JGVqCo6yKsBqR0tYlA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652169719; bh=BBwh2ufIgLkz3zU/DS/UW1PlNP78auj8E97u3hUiHIi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uRC9RfbtY0gvtLv2iXdC8UMPlVeU5WiG3eATsGft7t1fghhiFb53Ztqo1F//DcCxnW7JAlYByl+aCau4HvJWHWE47ksHUfEX1dmOP3bItuTljfQoVQqNIOxpiody8/JC2ZrsJXgV1bIPC0EE4gD4WnSkO2NjP6llqSKwKvCwTehfdk2DFPEpDxg6mOOTwRXPV7LGwWX3S+21UcCHBH5Pr5+VX0YIiS0umCAvdOV8Vg/HtohOEoZrQc1FT7gqzUuwUbTS5H3cnm1tMVO1bo0ISzQyhbWz8Zx5j2VPf1F4qHPLsUSZP2N1z1eNolsovyh7FMRu4KF8Oa8ZAAQSe2z6mg== X-YMail-OSG: rifv4NIVM1kdjmQz1muJyGVF4pc_v9XG.mMJLxzXjEWI3CHi2MhUwVYnugp8vP8 5vF4qoEMBGhVqB9AqaVjaqbxVhKskUNpyjRmaixODozzEeMQPOvTLI9wXjF1ytp5IqKaKGxQohus X44usTnQHRrFtejA3utoSh_xVpbLU0vHQDUu_XwGYLpH02HKdsWfPXj4Agrya5XCLgi0ItVntv8k Jr9YY5Q5QORQ_PakFIKktDuBlWb_K80lPgZM4dWzOLh_js_GY88pbxQhFHAUxOCNFnheMHHNUnGq 4rGpRx2zD4inVBjiYUvzM5Yojb_K.QwW0swWElEwLPl7MjJ.4gms69viLiMDXaCkNi4pk3k.FuL6 0.42igUxxzxBMFPD6ff.o91Cr7.ElOu38MibEGDop.XPUvHBXo1z7upoXWp2dwHXimkQ1nzIcwSS LIGrmBZGP4JI4A3hDR39fEdypfA3_XrBEChhu1hu432BE6CnPAvK7juJXrfFz71d0JMCU9CAz3I4 CxLB7bfrgB9Arg7hzUO0LI9tc8.XrWZJoH9R9WtzjoB.ySk6uagIZbIGo204NOkAwFQC_ZG70wwK LezSS7DjMu92JR4ONHyt_Ir.kywrg6cq_cLsnMkZ.rmQZ4NaZuN4OJPpg7aXwLBV2bEpWHVkpjCX I728oOLgIE2x7aoy4PKELAnXOWFFe_F9BSrsc1Sw9VH_.ooPtTsDa.aem0T.DDNplUtkkPgsOOAX Pfv_1PtMIvOCNTkdfdzX1PyDDDN5lS8vxZjX7F44FPHSlcrHZUCe9bTh_EyGWblVM1nWRzTpt41j 8G5mwB3xo4WCBCqyGd7zewbcpQvceiNSdEFTK3UNImjUMT5TZl_0xTOmdPmVAcTgkMZRq8fanJff C8_zKXB8S22l6nxrsOHuSD18vu2xCdp4H43ve7lXVyrwIamHCILyQ4Kqsr.KDW7szf6OhGxWBzu. uGxgdep05SGboUahLqdcbooCpG4BOt58ntOXDCA8brnYDZfV6Q1pn8dJRnq1F_8NwKUumhYazL0f 2bpG.fIy4KgbTlfcnjGA9MYm9s2ZpEbVkhgUJHrESGua76jcvFTrbCRjmHvxB_sU_zX1ftPAbyJJ Ft0W0a1TqHBEgGUtvC8tqMWMdfhU7FyLinl5sDy5XXzGc5ckp3pLsvBrIljkOTjQMJlPoTRQPimL cK7c0HJ7Lxw4h.yctQfXZ2FNAB9ATC50ecuzLe2MjxBROmJ.r7zE.ft9dhBiBcS1qflgAvZ87Wsc B4tJX9nM98IBI__buZGTJ87lHYoaDd1xIhlZHdLSvxS_hpM_xOZIBKx0.O2uKXM6ANkIPNQqh936 bBALD1obBK66RuP8QIAMDwKX68Rjk5weDU_Yw2vR8kOhAx.mibn.BOEKKAQ6ij0b46PB0g_YyFka 6mwdDUqVATTc9br3avfGDTkTCyuYggMIMtQRgBoWpUIlAd97k6w47ayiRPY9ov.WsluBIL6uRf3C hAGHH1jKYlIGmVsPY538Lh39SHL3faEDFTqi5dBB52yU0YaRyKhGvGxR3sAqW3EagmBRgOQ0IErh edDTXzAjdE_Ywkb5dI_mDZ7y__FF05Wfc.ghDZTQTgc5sX5WasmdZqvudk3620a0swUJrfdKd78I SY4cUJ.3aQ2DuVi4SFhESc2yDpq8xwWT_nxSx7PObPlBV3SpRVfbHMXqD.xEjfABI_szDtmhgrUC yaIDPDkJEUUENxxdPCpVExYcOunpNo6btqcgH3znxz9J.xZ05rM1KDc8u4TcIQlqKYfFul8eKoZ7 hoUYPY5CR6SqxiO218qWRkFkoIFzWXWWGyDN2aKBk_UFEpC7MWWD52gsH_7_EFT1XGo582cWqJJT W66_sYwdr.DnTElR2bi_5UtwR1Z.s.dbwAoH_58T0WXcgjztKLa86ftCYdkKcRPVq3vbqub4dQbL 0tABMiuTJUAqd6VUSkiJOfTg1I3viEo.LWqaUpvw7MEolYTXOrO1NjBxt.bTtQFVgO0qnO5EDcPG TsJqMDRMId3VEj38C9EIM9c1Oz7R5.MS90dI0k3ITeZUxsjDcuEhvl2V6m_TPyJvwz585Ht3yW9p q3QHuGtZlL45VqYE9.oYgK4OlVwoXLqm23.6zAdLk9LimP6SlJFrtnwdO.rp969teyepyyLk9NHm _LpgapdhKWM4dmMRQKHpBj67jmLBAv0yL010Lia6aD7sqSFOODpMGQ2JcjYz5HWf80Hyp2LXj1wH u7Kj5m4fQVLCo.Z_Tf.Jso2UCowwK3WV2dOAzINeeBfEwaGAx4c28iGaJFEV6MkqbLJ1Xj7GMG8P Yia2VPE1C X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 10 May 2022 08:01:59 +0000 Received: by hermes--canary-production-ne1-8676f67b88-hk4wg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 56389975409d266b5648baef06b84a82; Tue, 10 May 2022 08:01:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? From: Mark Millard In-Reply-To: <33B740AA-A431-49CB-9F27-50B8C49734A2@yahoo.com> Date: Tue, 10 May 2022 01:01:52 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <3C5C183F-1471-4139-A53C-0B3815CFC25E@yahoo.com> References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> <446d5913-a8c2-7dd0-860b-792fa9fe7c5b@nomadlogic.org> <33B740AA-A431-49CB-9F27-50B8C49734A2@yahoo.com> To: Pete Wright X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Ky9Vm07x4z4Qqn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lsT7ZgK9; 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 X-Spamd-Result: default: False [-2.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-29, at 13:57, Mark Millard wrote: > On 2022-Apr-29, at 13:41, Pete Wright wrote: >>=20 >>> . . . >>=20 >> d'oh - went out for lunch and workstation locked up. i *knew* i = shouldn't have said anything lol. >=20 > Any interesting console messages ( or dmesg -a or /var/log/messages )? >=20 I've been doing some testing of a patch by tijl at FreeBSD.org and have reproduced both hang-ups (ZFS/ARC context) and kills (UFS/noARC and ZFS/ARC) for "was killed: failed to reclaim memory", both with and without the patch. This is with only a tiny fraction of the swap partition(s) enabled being put to use. So far, the testing was deliberately with vm.pageout_oom_seq=3D12 (the default value). My testing has been with main [so: 14]. But I also learned how to avoid the hang-ups that I got --but it costs making kills more likely/quicker, other things being equal. I discovered that the hang-ups that I got were from all the processes that I interact with the system via ending up with the process's kernel threads swapped out and were not being swapped in. (including sshd, so no new ssh connections). In some contexts I only had escaping into the kernel debugger available, not even ^T would work. Other times ^T did work. So, when I'm willing to risk kills in order to maintain the ability to interact normally, I now use in /etc/sysctl.conf : vm.swap_enabled=3D0 This disables swapping out of process kernel stacks. It is just with that option removedfor gaining free RAM, there fewer options tried before a kill is initiated. It is not a loader-time tunable but is writable, thus the /etc/sysctl.conf placement. Note that I get kills both for vm.swap_enabled=3D0 and for vm.swap_enabled=3D1 . It is just what looks like a hangup that I'm trying to control via using =3D0 . For now, I view my use as experimental. It might require adjusting my vm.pageout_oom_seq=3D120 usage. I've yet to use protect to also prevent kills of processes needed for the interactions ( see: man 1 protect ). Most likely I'd try to protect enough to allow the console interactions to avoid being killed. For reference . . . The type of testing is to use the likes of: # stress -m 2 --vm-bytes ????M --vm-keep and part of the time with grep activity also running, such as: # grep -r nfreed /usr/*-src/sys/ | more for specific values where the * is. (I have 13_0R , 13_1R , 13S , and main .) Varying the value leads to reading new material instead of referencing buffered/cached material from the prior grep(s). The ???? is roughly set up so that the system ends up about where its initial Free RAM is used up, so near (above or below) where some sustained paging starts. I explore figures that make the system land in this state. I do not have a use-exactly-this computed figure technique. But I run into the problems fairly easily/quickly so far. As stress itself uses some memory, the ???? need not be strictly based on exactly 1/2 of the initial Free RAM value --but that figure suggests were I explore around. The kills sometimes are not during the grep but somewhat after. Sometimes, after grep is done, stopping stress and starting it again leads to a fairly quick kill. The system used for the testing is an aarch64 MACCHIATObin Double Shot (4 Cortex-A72s) with 16 GiBytes of RAM. I can boot either its ZFS media or its UFS media. (The other OS media is normally ignored by the system configuration.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue May 10 08:10:00 2022 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 323B31ADB176 for ; Tue, 10 May 2022 08:10:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ky9h562hBz4Tnp for ; Tue, 10 May 2022 08:10:13 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [176.74.213.87]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id DCBE22600D5; Tue, 10 May 2022 10:10:03 +0200 (CEST) Message-ID: <53b2dd8d-08cc-3604-02c8-ed74a6d4430a@selasky.org> Date: Tue, 10 May 2022 10:10:00 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: Testing 14-CURRENT-f44280bf5fb on aarch64 Content-Language: en-US To: Daniel Morante , freebsd-current@freebsd.org References: <61edce0e-948a-d9da-47b9-090a9201694e@selasky.org> <7ba934b2-af12-4006-2828-a1741e84ffa2@morante.net> From: Hans Petter Selasky In-Reply-To: <7ba934b2-af12-4006-2828-a1741e84ffa2@morante.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Ky9h562hBz4Tnp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/10/22 09:37, Daniel Morante wrote: > Updated to the latest (14.0-CURRENT #2 main-n255521-10f44229dcd: Tue May > 10 02:52:27 EDT 2022) and removed the sysctl option > (hw.usb.disable_enumeration=1). > > Still seeing the problem.  The below just endlessly prints out on the > console: > > ``` > > FreeBSD/arm64 (mars.morante.com) (ttyu0) > > login: ugen0.2: at usbus0 (disconnected) > uhub4: at uhub0, port 1, addr 1 (disconnected) > uhub4: detached > ugen0.2: at usbus0 > uhub4 numa-domain 0 on uhub0 > uhub4: on usbus0 > uhub4: 4 ports with 4 removable, self powered > ugen0.2: at usbus0 (disconnected) > uhub4: at uhub0, port 1, addr 1 (disconnected) > uhub4: detached > ugen0.2: at usbus0 > uhub4 numa-domain 0 on uhub0 > uhub4: on usbus0 > uhub4: 4 ports with 4 removable, self powered > ugen0.2: at usbus0 (disconnected) > uhub4: at uhub0, port 1, addr 1 (disconnected) > uhub4: detached > ugen0.2: at usbus0 > uhub4 numa-domain 0 on uhub0 > uhub4: on usbus0 > uhub_attach: port 1 power on or off failed, USB_ERR_IOERROR > uhub_attach: port 2 power on or off failed, USB_ERR_IOERROR > uhub_attach: port 3 power on or off failed, USB_ERR_IOERROR > uhub_attach: port 4 power on or off failed, USB_ERR_IOERROR > uhub4: 4 ports with 4 removable, self powered > uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 1 > uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 2 > uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 3 > uhub_reattach_port: device problem (USB_ERR_IOERROR), disabling port 4 > ugen0.2: at usbus0 (disconnected) > uhub4: at uhub0, port 1, addr 1 (disconnected) > uhub4: detached > ugen0.2: at usbus0 > uhub4 numa-domain 0 on uhub0 > uhub4: on usbus0 > uhub4: 4 ports with 4 removable, self powered > ugen0.2: at usbus0 (disconnected) > uhub4: at uhub0, port 1, addr 1 (disconnected) > uhub4: detached > ugen0.2: at usbus0 > uhub4 numa-domain 0 on uhub0 > uhub4: on usbus0 > uhub4: 4 ports with 4 removable, self powered > ugen0.2: at usbus0 (disconnected) > uhub4: at uhub0, port 1, addr 1 (disconnected) > uhub4: detached > ugen0.2: at usbus0 > uhub4 numa-domain 0 on uhub0 > uhub4: on usbus0 > uhub4: 4 ports with 4 removable, self powered > ugen0.2: at usbus0 (disconnected) > uhub4: at uhub0, port 1, addr 1 (disconnected) > uhub4: detached > ugen0.2: at usbus0 > uhub4 numa-domain 0 on uhub0 > uhub4: on usbus0 > uhub4: 4 ports with 4 removable, self powered > ugen0.2: at usbus0 (disconnected) > uhub4: at uhub0, port 1, addr 1 (disconnected) > uhub4: detached > ugen0.2: at usbus0 > uhub4 numa-domain 0 on uhub0 > uhub4: on usbus0 > uhub4: 4 ports with 4 removable, self powered > ugen0.2: at usbus0 (disconnected) > uhub4: at uhub0, port 1, addr 1 (disconnected) > uhub4: detached > ugen0.2: at usbus0 > uhub4 numa-domain 0 on uhub0 > uhub4: on usbus0 > uhub4: 4 ports with 4 removable, self powered > ugen0.2: at usbus0 (disconnected) > uhub4: at uhub0, port 1, addr 1 (disconnected) > uhub4: detached > ugen0.2: at usbus0 > uhub4 numa-domain 0 on uhub0 > uhub4: on usbus0 > uhub4: 4 ports with 4 removable, self powered > ugen0.2: at usbus0 (disconnected) > uhub4: at uhub0, port 1, addr 1 (disconnected) > uhub4: detached > ugen0.2: at usbus0 > uhub4 numa-domain 0 on uhub0 > uhub4: on usbus0 > uhub4: 4 ports with 4 removable, self powered > ``` > Hi, Does it help to do a "usbconfig -d X.Y reset" of the parent USB HUB of the failing one, I guess this is ugen0.1 . --HPS From nobody Tue May 10 15:05:56 2022 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 9D5831ADFB01 for ; Tue, 10 May 2022 15:06:08 +0000 (UTC) (envelope-from cristian.cardoso11@gmail.com) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KyLw01Rdmz3nlR for ; Tue, 10 May 2022 15:06:08 +0000 (UTC) (envelope-from cristian.cardoso11@gmail.com) Received: by mail-qv1-xf32.google.com with SMTP id l1so10417322qvh.1 for ; Tue, 10 May 2022 08:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=Y7PXQT7GTWJI1nuJFnfUlh57gjXNyGQvj39wiPU5lZ8=; b=JfU5aIunWq3bgtyShI6uL9Thx3ncaTuNXzJfl9EJ10eNxome1DNG7cVYL+dRUpYU/3 fhjBKf5iIwzbuFhrb+K1rlOJFsmwZ5Q34EDfdggAZWbT51XvrP5c1Xpajb37nOw8yS8b V8VfasGLITnBzPn76amA1XOfUrdwfwkmRXOT/9CIxcV2OI5mn9wc9cCWs8PV8Q8zDeKp OsXZBWQHe1T+z7j5Zm5uieFwwBmyyzvc/mjMqEWu8JY5x6OqNmME4UBSD4tIxo1NyR3D IfhtI8BPt2J0DDxSi0MVnd6/LDJ1WB/3ZgPkH9sXQvDuniYB9xFYpSsi0l6hitbzq8BX n1Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Y7PXQT7GTWJI1nuJFnfUlh57gjXNyGQvj39wiPU5lZ8=; b=21A8+FPEIRlJrhHW1PcJ34Tw+Th0jkB1rnInrqLAQ+7HooEHtp6/GBT3icuiB4cPRi uwf06gwSmZma06KKlofxSWv7sWXygqINEegTmkW5K+CIUSuE+5Ab4FchXvHt5Wu82DZe 2AwcZbuNiVm1VyJxEzpd4/9DcS+a3UAYvoVqZA/3g0MneMIKWntXPW+BIZUb4sloigFs lBlqPncU2l5N2wcOr9FNMSyvEVMKt/S5ymtZwq3JsPbN1gQXs7aMkzWxJjfk6mZ5eFSM r/AVPlw/62Nd+cMMZZBmEhP3nL+0FNGK3R1803QZ5pZ6Aemqhy5zmxsANZg/oCFseDZK 0LQQ== X-Gm-Message-State: AOAM5332CtHJ5oEjKE1hP56xAFQ3H/RQHwMznDPYz1d0na/ZjiEnZJ6T LCtNyMr6wKSzRVDGJlX8C3Kqtuz40BlW0j6FwkfxMLcFgw== X-Google-Smtp-Source: ABdhPJwjlBl/ugzr4AE4Vj43U0HVB6kNSvGzONgFzlIxcqX3QTnZ7YBtESFjn6kOU9NX2x4FaZs1mWgX5iHLoubPD8Y= X-Received: by 2002:a05:6214:2304:b0:438:458e:eafc with SMTP id gc4-20020a056214230400b00438458eeafcmr17996680qvb.118.1652195167601; Tue, 10 May 2022 08:06: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: Cristian Cardoso Date: Tue, 10 May 2022 12:05:56 -0300 Message-ID: Subject: Upgrade automation To: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000010883205dea9aa67" X-Rspamd-Queue-Id: 4KyLw01Rdmz3nlR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=JfU5aIun; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of cristiancardoso11@gmail.com designates 2607:f8b0:4864:20::f32 as permitted sender) smtp.mailfrom=cristiancardoso11@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f32:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000010883205dea9aa67 Content-Type: text/plain; charset="UTF-8" Hi I have some FreeBSD servers in my machine park and I would like to perform the version upgrade in an automated way with ansible. In my example, I want to perform the upgrade from version 12.3 to 13, it is possible to run the upgrade with the command below: freebsd-update --not-running-from-cron upgrade -r 12.2-RELEASE I ask this, because I don't know if it's the most correct way to execute this. Grateful for any assistance. --00000000000010883205dea9aa67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

I have some FreeBSD servers in my machine park a= nd I would like to perform the version upgrade in an automated way with ans= ible.

In my example, I want to perform the upgrade from version 12.3= to 13, it is possible to run the upgrade with the command below:

fr= eebsd-update --not-running-from-cron upgrade -r 12.2-RELEASE

I ask t= his, because I don't know if it's the most correct way to execute t= his.

Grateful for any assistance.
--00000000000010883205dea9aa67-- From nobody Tue May 10 15:46:51 2022 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 4199A1AE7389 for ; Tue, 10 May 2022 15:47:10 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oa1-f52.google.com (mail-oa1-f52.google.com [209.85.160.52]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KyMqK3cr2z3vQH for ; Tue, 10 May 2022 15:47:09 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oa1-f52.google.com with SMTP id 586e51a60fabf-e5e433d66dso18744233fac.5 for ; Tue, 10 May 2022 08:47:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zCFqovSUZFBC71QH7d+A2ClTlLjf4E03epqNnUhfmq0=; b=pvB47w5GUs+KsID7pHJ0g5DCDmvUX7elMYSr8Y/KiyS6c7zi3u8VT16A+NjJ9TQJoO ALriEZXEGLmhvi4DKJbSYfwEkx/Dl8V6/NEx7Lmg3nP9JEOWOGGQieARj8rULaKv/rPT ODAHLNrIUnulqM28Xo13gjtxCPw97J5bk6lydlz/ePm+TjwGWOCIsZKSN0rjfDXaQt1c J9WIxBq2pm8E/xy4gvYIG8/t/eoGcT3Gfm9s1eiTmaRguLHDiUoWd4niJMrbKuTxA11h 8F1gZiVAc/mMObWCLUfHAlAXneRZsscF+1BMR6d/TpOZeIJ+h+zzQw9t7os5+B50WSNa KTjA== X-Gm-Message-State: AOAM533DjkBOuRDmrH9RWPBT0tXhltxKVWcVFJ9B/pdwX1iWATFWiAk0 oUpCwjgmyPcEM30CukrOEUg+s88QEHbbcl7V9r6S5f7e X-Google-Smtp-Source: ABdhPJzYusn169BLS+uyl06jaVzvRguYkeZkTYEfQTrAzoJ/q7jaZKiEGToaLWOC0OK7JKv5QnUgwZP0GWvVPrjLR6g= X-Received: by 2002:a05:6870:a2d2:b0:d7:60ca:5065 with SMTP id w18-20020a056870a2d200b000d760ca5065mr426832oak.72.1652197623200; Tue, 10 May 2022 08:47:03 -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: Alan Somers Date: Tue, 10 May 2022 09:46:51 -0600 Message-ID: Subject: Re: Upgrade automation To: Cristian Cardoso Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KyMqK3cr2z3vQH X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.160.52 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-0.95 / 15.00]; RWL_MAILSPIKE_GOOD(0.00)[209.85.160.52:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.91)[-0.911]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.96)[0.964]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.52:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, May 10, 2022 at 9:08 AM Cristian Cardoso wrote: > > Hi > > I have some FreeBSD servers in my machine park and I would like to perform the version upgrade in an automated way with ansible. > > In my example, I want to perform the upgrade from version 12.3 to 13, it is possible to run the upgrade with the command below: > > freebsd-update --not-running-from-cron upgrade -r 12.2-RELEASE > > I ask this, because I don't know if it's the most correct way to execute this. > > Grateful for any assistance. Yes, that's perfect. But there's another step too. You'll have to do: freebsd-update install And _this_ step isn't easy to perfectly automate, because etcupdate may ask for your input when it merges config files. If you know exactly which etc files you've modified, you can add them to IgnorePaths. That way etcupdate won't run interactively, it will simply throw away changes from upstream. Whenever I need to upgrade multiple machines at once, I start tmux, split it into multiple panes, ssh to each server from one pane, then do ":synchronize-panes on" so my input will be directed to multiple panes simultaneously. Usually, that works for 90% of the upgrade. But invariably there are a few files that aren't synchronized between the servers, and I have to desynchronize my panes to deal with that. -Alan From nobody Tue May 10 15:47:06 2022 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 3CB581AE70E3 for ; Tue, 10 May 2022 15:47:25 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4KyMqb6L4Lz3vWB for ; Tue, 10 May 2022 15:47:23 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 87732 invoked by uid 907); 10 May 2022 15:47:14 -0000 Received: from i5E8640AA.versanet.de (HELO smtpclient.apple) (94.134.64.170) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Wed, 11 May 2022 01:47:14 +1000 Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? From: Jan Mikkelsen In-Reply-To: <3C5C183F-1471-4139-A53C-0B3815CFC25E@yahoo.com> Date: Tue, 10 May 2022 17:47:06 +0200 Cc: Pete Wright , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <75C02C8C-6A5E-4E19-AC7D-B5DB704E8F16@transactionware.com> References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> <446d5913-a8c2-7dd0-860b-792fa9fe7c5b@nomadlogic.org> <33B740AA-A431-49CB-9F27-50B8C49734A2@yahoo.com> <3C5C183F-1471-4139-A53C-0B3815CFC25E@yahoo.com> To: Mark Millard X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KyMqb6L4Lz3vWB X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of janm@transactionware.com has no SPF policy when checking 203.14.245.7) smtp.mailfrom=janm@transactionware.com X-Spamd-Result: default: False [1.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[transactionware.com]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 10 May 2022, at 10:01, Mark Millard wrote: >=20 > On 2022-Apr-29, at 13:57, Mark Millard wrote: >=20 >> On 2022-Apr-29, at 13:41, Pete Wright wrote: >>>=20 >>>> . . . >>>=20 >>> d'oh - went out for lunch and workstation locked up. i *knew* i = shouldn't have said anything lol. >>=20 >> Any interesting console messages ( or dmesg -a or /var/log/messages = )? >>=20 >=20 > I've been doing some testing of a patch by tijl at FreeBSD.org > and have reproduced both hang-ups (ZFS/ARC context) and kills > (UFS/noARC and ZFS/ARC) for "was killed: failed to reclaim > memory", both with and without the patch. This is with only a > tiny fraction of the swap partition(s) enabled being put to > use. So far, the testing was deliberately with > vm.pageout_oom_seq=3D12 (the default value). My testing has been > with main [so: 14]. >=20 > But I also learned how to avoid the hang-ups that I got --but > it costs making kills more likely/quicker, other things being > equal. >=20 > I discovered that the hang-ups that I got were from all the > processes that I interact with the system via ending up with > the process's kernel threads swapped out and were not being > swapped in. (including sshd, so no new ssh connections). In > some contexts I only had escaping into the kernel debugger > available, not even ^T would work. Other times ^T did work. >=20 > So, when I'm willing to risk kills in order to maintain > the ability to interact normally, I now use in > /etc/sysctl.conf : >=20 > vm.swap_enabled=3D0 I have been looking at an OOM related issue. Ignoring the actual leak, = the problem leads to a process being killed because the system was out = of memory. This is fine. After that, however, the system console was = black with a single block cursor and the console keyboard was = unresponsive. Caps lock and num lock didn=E2=80=99t toggle their lights = when pressed. Using an ssh session, the system looked fine. USB events for the = keyboard being disconnected and reconnected appeared but the keyboard = stayed unresponsive. Setting vm.swap_enabled=3D0, as you did above, resolved this problem. = After the process was killed a perfectly normal console returned. The interesting thing is that this test system is configured with no = swap space. This is on 13.1-RC5. > This disables swapping out of process kernel stacks. It > is just with that option removedfor gaining free RAM, there > fewer options tried before a kill is initiated. It is not a > loader-time tunable but is writable, thus the > /etc/sysctl.conf placement. Is that really what it does? =46rom a quick look at the code in = vm/vm_swapout.c, it seems little more complex. Regards, Jan M. From nobody Tue May 10 15:57:03 2022 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 7E5061ABA4F8 for ; Tue, 10 May 2022 15:57:15 +0000 (UTC) (envelope-from cristian.cardoso11@gmail.com) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KyN2y5Nmbz4SbR; Tue, 10 May 2022 15:57:14 +0000 (UTC) (envelope-from cristian.cardoso11@gmail.com) Received: by mail-qk1-x72b.google.com with SMTP id b20so13512973qkc.6; Tue, 10 May 2022 08:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Y2JJi/38v4njFZkx/TEPjKwC+x3EIKz/Knk4Q6jNkI=; b=IRF81kdVvC5Yrj8WqMJUbVVga3VYCzKWlP303RFxj1A2v2T2bX+kR+hPvoNzKEV4IU c+kvrdTcFiSEF7COCvdv2Lix4vXkqmy+sD126IqQgM+AKh4Vs4vweTYpsK6wkGPveehR bYLNejeiJjuc28eMF6STaU1pJDeOTNrCHz7nlSNCzALo2iADuoIi6R6MiJSqWzY82RiN V3reD3mSZDLcKW1RRNFalE5p5Ov3twwbu94AP3RczLc8acWuICyMowP7/Fxy0AEroGW/ q9w7V+31PftB3QggOsO424kaWBU9MG9M9cP5iFnHT+KY9olpZdtfHCjTRo8kaS/d8t5B wqQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6Y2JJi/38v4njFZkx/TEPjKwC+x3EIKz/Knk4Q6jNkI=; b=yKLFaFy1pKqOvcMtt3nWY+eLgSwc1UpRJ8bp8qfa7wlpNdTNKcewe1bs20pIHctO1m LLdvXe6lRBct1voZZDsJMuCI82sOZE3nty9RSQ1vvsN48l/bX+HcuSUUDDKD6Qma7y4x 8eWbTphOvvXKO/cxH/bgEHM3x016uyV/NdYDwGnqopZ4LcxT1MWIKr8nQZXwK4V8efM1 AM/Gsu3YXm18Iff5NvOA1AbpUOm4vc2cqL4zoy8JfSe/CRm8oNKp/gbiF/seP/15Mu31 qC3luj7R9rajiw67DsT/CNsqiQY4ekdVMiyo5X44hHm7Kjs188iXRNwElmnfuV2hCuNl DvOw== X-Gm-Message-State: AOAM533Pu+LuVul8bOSAop8GBV47SaQCq4u/Yj03V/Hj6Rgq4es4pOIK oquGo32LZdNlCOYPar5gF4DJ8uNu0V5O8V19rC2siNe2/A== X-Google-Smtp-Source: ABdhPJzpFxpVEQy8/32Cxx4gWdxoRQeJMiOyFDfN0JAxMpp+tgury9tPRugYI+nY4DHkQ0yxBEMeLx0wQ0MTCHq+Cg0= X-Received: by 2002:a05:620a:56e:b0:6a0:1857:4ee7 with SMTP id p14-20020a05620a056e00b006a018574ee7mr15042719qkp.172.1652198234046; Tue, 10 May 2022 08:57:14 -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: Cristian Cardoso Date: Tue, 10 May 2022 12:57:03 -0300 Message-ID: Subject: Re: Upgrade automation To: Alan Somers Cc: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000d6d2f705deaa60ae" X-Rspamd-Queue-Id: 4KyN2y5Nmbz4SbR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=IRF81kdV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of cristiancardoso11@gmail.com designates 2607:f8b0:4864:20::72b as permitted sender) smtp.mailfrom=cristiancardoso11@gmail.com X-Spamd-Result: default: False [-2.04 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.96)[0.956]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72b:from]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000d6d2f705deaa60ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I currently update patches this way: - name: Checking for updates on FreeBSD command: freebsd-update fetch when: - ansible_distribution =3D=3D "FreeBSD" register: result_update changed_when: "'No updates needed' not in result_update.stdout" become: yes tags: - check-update - name: Applying update on FreeBSD command: freebsd-update install when: - ansible_distribution =3D=3D "FreeBSD" and result_update.changed register: result_update_install become: yes tags: - apply-update Maybe to get around the situation after the version upgrade task, you can do something like this: - name: Reboot system to apply new kernel shell: "sleep 5 && reboot" async: 1 poll: 0 become: True - name: Wait for reconnection to system to continue update wait_for_connection: connect_timeout: 20 sleep: 20 delay: 60 timeout: 600 - name: Applying update on FreeBSD command: freebsd-update install when: - ansible_distribution =3D=3D "FreeBSD" and result_update.changed register: result_update_install become: yes Em ter., 10 de mai. de 2022 =C3=A0s 12:47, Alan Somers escreveu: > On Tue, May 10, 2022 at 9:08 AM Cristian Cardoso > wrote: > > > > Hi > > > > I have some FreeBSD servers in my machine park and I would like to > perform the version upgrade in an automated way with ansible. > > > > In my example, I want to perform the upgrade from version 12.3 to 13, i= t > is possible to run the upgrade with the command below: > > > > freebsd-update --not-running-from-cron upgrade -r 12.2-RELEASE > > > > I ask this, because I don't know if it's the most correct way to execut= e > this. > > > > Grateful for any assistance. > > Yes, that's perfect. But there's another step too. You'll have to do: > freebsd-update install > And _this_ step isn't easy to perfectly automate, because etcupdate > may ask for your input when it merges config files. If you know > exactly which etc files you've modified, you can add them to > IgnorePaths. That way etcupdate won't run interactively, it will > simply throw away changes from upstream. > > Whenever I need to upgrade multiple machines at once, I start tmux, > split it into multiple panes, ssh to each server from one pane, then > do ":synchronize-panes on" so my input will be directed to multiple > panes simultaneously. Usually, that works for 90% of the upgrade. > But invariably there are a few files that aren't synchronized between > the servers, and I have to desynchronize my panes to deal with that. > > -Alan > --000000000000d6d2f705deaa60ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I currently update patches this way:


- name: C= hecking for updates on FreeBSD
=C2=A0 =C2=A0command: freebsd-update fetc= h
=C2=A0 =C2=A0when:
=C2=A0 =C2=A0 =C2=A0- ansible_distribution =3D= =3D "FreeBSD"
=C2=A0 =C2=A0register: result_update
=C2=A0 = =C2=A0changed_when: "'No updates needed' not in result_update.= stdout"
=C2=A0 =C2=A0become: yes
=C2=A0 =C2=A0tags:
=C2=A0 = =C2=A0- check-update

- name: Applying update on FreeBSD
=C2=A0 = =C2=A0command: freebsd-update install
=C2=A0 =C2=A0when:
=C2=A0 =C2= =A0 =C2=A0- ansible_distribution =3D=3D "FreeBSD" and result_upda= te.changed
=C2=A0 =C2=A0register: result_update_install
=C2=A0 =C2=A0= become: yes
=C2=A0 =C2=A0tags:
=C2=A0 =C2=A0- apply-update


Maybe to get around the situatio= n after the version upgrade task, you can do something like this:

- name: Reboot system to apply new kernel
=C2=A0 =C2=A0shell: "sl= eep 5 && reboot"
=C2=A0 =C2=A0async: 1
=C2=A0 =C2=A0poll= : 0
=C2=A0 =C2=A0become: True

- name: Wait for reconnection to sy= stem to continue update
=C2=A0 =C2=A0wait_for_connection:
=C2=A0 =C2= =A0 =C2=A0connect_timeout: 20
=C2=A0 =C2=A0 =C2=A0sleep: 20
=C2=A0 = =C2=A0 =C2=A0delay: 60
=C2=A0 =C2=A0 =C2=A0timeout: 600

- name: A= pplying update on FreeBSD
=C2=A0 =C2=A0command: freebsd-update install=C2=A0 =C2=A0when:
=C2=A0 =C2=A0 =C2=A0- ansible_distribution =3D=3D &= quot;FreeBSD" and result_update.changed
=C2=A0 =C2=A0register: resu= lt_update_install
=C2=A0 =C2=A0become: yes

=

Em ter., 10 de mai. de 2022 =C3=A0s 12:47, Alan Somers <= asomers@freebsd.org> escreveu= :
On Tue, May 10= , 2022 at 9:08 AM Cristian Cardoso
<crist= ian.cardoso11@gmail.com> wrote:
>
> Hi
>
> I have some FreeBSD servers in my machine park and I would like to per= form the version upgrade in an automated way with ansible.
>
> In my example, I want to perform the upgrade from version 12.3 to 13, = it is possible to run the upgrade with the command below:
>
> freebsd-update --not-running-from-cron upgrade -r 12.2-RELEASE
>
> I ask this, because I don't know if it's the most correct way = to execute this.
>
> Grateful for any assistance.

Yes, that's perfect.=C2=A0 But there's another step too.=C2=A0 You&= #39;ll have to do:
freebsd-update install
And _this_ step isn't easy to perfectly automate, because etcupdate
may ask for your input when it merges config files.=C2=A0 If you know
exactly which etc files you've modified, you can add them to
IgnorePaths.=C2=A0 That way etcupdate won't run interactively, it will<= br> simply throw away changes from upstream.

Whenever I need to upgrade multiple machines at once, I start tmux,
split it into multiple panes, ssh to each server from one pane, then
do ":synchronize-panes on" so my input will be directed to multip= le
panes simultaneously.=C2=A0 Usually, that works for 90% of the upgrade.
But invariably there are a few files that aren't synchronized between the servers, and I have to desynchronize my panes to deal with that.

-Alan
--000000000000d6d2f705deaa60ae-- From nobody Tue May 10 16:38:32 2022 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 E43661AC3E15 for ; Tue, 10 May 2022 16:38:42 +0000 (UTC) (envelope-from SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4KyNyn5S8vz4ZSm; Tue, 10 May 2022 16:38:41 +0000 (UTC) (envelope-from SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id CFAFC28417; Tue, 10 May 2022 18:38:33 +0200 (CEST) Received: from illbsd.quip.test (ip-78-45-215-131.net.upcbroadband.cz [78.45.215.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id BCA0B28411; Tue, 10 May 2022 18:38:32 +0200 (CEST) Subject: Re: Upgrade automation To: Alan Somers , Cristian Cardoso Cc: FreeBSD CURRENT References: From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Tue, 10 May 2022 18:38:32 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: cs Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KyNyn5S8vz4ZSm X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz" X-Spamd-Result: default: False [0.52 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.67)[-0.674]; NEURAL_SPAM_LONG(1.00)[0.998]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=9pn6=VS=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[78.45.215.131:received] X-ThisMailContainsUnwantedMimeParts: N On 10/05/2022 17:46, Alan Somers wrote: > On Tue, May 10, 2022 at 9:08 AM Cristian Cardoso > wrote: >> >> Hi >> >> I have some FreeBSD servers in my machine park and I would like to perform the version upgrade in an automated way with ansible. >> >> In my example, I want to perform the upgrade from version 12.3 to 13, it is possible to run the upgrade with the command below: >> >> freebsd-update --not-running-from-cron upgrade -r 12.2-RELEASE >> >> I ask this, because I don't know if it's the most correct way to execute this. >> >> Grateful for any assistance. > > Yes, that's perfect. But there's another step too. You'll have to do: > freebsd-update install > And _this_ step isn't easy to perfectly automate, because etcupdate > may ask for your input when it merges config files. If you know > exactly which etc files you've modified, you can add them to > IgnorePaths. That way etcupdate won't run interactively, it will > simply throw away changes from upstream. Automation with etcupdate sounds very scary to me because etcupdate breaks real life configuration files inplace. Mergemaster did it on temporary copies. But if you let etcupdate to left something (after merge conflict) in vital config file(s) wich will have syntax error on next boot, then you are out. It would be much better if etcupdate do not edit target file on merge conflicts. Kind regards Miroslav Lachman From nobody Tue May 10 18:49:46 2022 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 30FDB1AC4D0C for ; Tue, 10 May 2022 18:50:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KyRtJ07FJz3MPg for ; Tue, 10 May 2022 18:49:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652208593; bh=dosDbFcjQkk6Bh5dJAVReCnBgWIz7XhJTxo+i8bsN4Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fcGDPs0Te3o90mR2NeTa8heJFNsTurCA2S+UUsOYgLV5d17PWIbOztjWWAraPB4jQD4v+HMUnOvHND8ugt7HIeURMzHGwYUr2Sfyw1LSGoayRcUflkhguftLD3fqI66OrtDAsr6LIBJ55hfl4N/SPVBncOwj+50HF5HfobsfiZCTwTkyXkwKBRsZil0QsdXmjR1cZGxkkGfQDveGH4LytJNmOXgpPNjTMgOnOYasSDPK7h92y/Y4xkXLkg/xPYgbEy9mxtDq8yPlf/SnJuVsrZwc8sLpdFPzXbwxm7Vy9FYWIW5uoHNwcH2OwhsoVodQ2FT0zuprKRNDGDjizqtfXA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652208593; bh=BJ2vAa+MmbRoibzLrM4hr6hcuWunJfMQ5bAOvs6s9ah=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=d1INaMN7xbQntWpzr5REIPbhoA1t2Bpw/cMEsoeTSVM8+VIdx5Dw0u6QqsZX2snJaQVlR3jZ/vCNq/EHKhVeN2Tud6aQgHCHbujfhvbBIO2u2lZnncnb74S9uF/3J3XZs1WpbgWVDgB0GtqpiHfFJ5ogbiQ7wqy4D+h298oJbmkouXgvJ0mbK9Atj3UUZRrZDOiDlMtiYNrS2A5q/vB3BUYInrBubZUtNgbXA+ieawXXEgHGX/umUB5wyq96YI3w8VSin6PBWCZws82BaNE1nJEBrtOGnG/MzgxaOBjfvLqGs0JVovr9ErTcMCUuY6Zn2w0Lo35lW4PbnURL0vcYXg== X-YMail-OSG: D1adEBIVM1l0ouDcaWA_o.ysty8ij2GnQFUGtGtrgeHwWkiLxuIXsFFrz9Ps4wi OjPn_oayJ9eAeZikOLkf5W6xc6tOlYnY_idgdQSkWRrN4aF2mwTzR0QOK8OsOVlAg.pSgG8SoTZL LpAD9jEPEImcVidiMpYF09WnV9GHT7e.JhvxNDop6F1dhYtgA87sNmpNE.XD2Shq6WXKCiYqU4Gn MFN5FnJHt18S6tXHZ84.bni1Qhhp.oD9Nufw79WQKdUcrAJzQ1Jz_rvoeRlTS3T2JZLZWUZSbvca xSCeJaTOntQwDsLKImXKnIlo1MpySApATHespomEcLKiJOVCVHCTP11unKlMUImizquKCZn90jVo VuLjili4_PVhqR3M88FA7O6nYhOCFpnIQi7ougdAyOAcVWDwNBZ2vwrHK5MIfGJB0PxY2A9iUpp4 BBvMuj40iVKRghbkDZGUo5pep5xG7BrLjcgU5OAF4q9zSh0WIMpH5BOC5QmyYot9Y.ukHHCTgwmc Yo8OpYpKmL5nkfOeJN4yT_Sc74BKuTYD6Ln3SuIe0at54N8VA1Sq3oQVwkViWef4wFTGF.6ZSagP u8npvIAAuXgE01pAtWAlWybhdSS.5zGh_ACBfv5xQZH0A3Allzi2RvhMysizC40fkibUUkIl76KE vy2TU.tMnEBi_cA_V7twaWru3I85zfND7cIgLngAuwpDXMAmQh.0ZXI29z3PDes3sPhb0mHDEVLP QUgY42LDvbDx2XNZHjpMBeJy9kXpdzP550QpySt0GK9p5PAx78gYd16Z.EACkg93X5XU_5U_qGJu inqBsguGtEJ.aVoVuEnZ4.duOiL38lsxl9GONRLqOaf9ql9YLQncMHRFi36m9jvXMIfBqYHGOFAy QkTmebfD7CdAwu1kaj7FOcPN4VDcrcWfkMb0fTMYTkt25EO.L_BTWsYi30xuwim3EWU0rujGHtPG zjrASSSk_Bh4V8o1lFH_KbYMEb5YRCwZP_GhXZIWmuVojSbRUh9iG5wY1w6DgZSIN65oIjzI9JQ8 DGq_nHSR1ryDzaxlI3RDlz6d62P7Pw7eU8Z8ClWwgIsE8HYvcG5eeaDhwnx0A1bH.t3KinaexIez o7sp9HjIS8GnpwI.c6dEQ8FYBk8v4lYDpMLl8qArRXY1ndGZSkjeUq6KFKpxkRYTlMb2QGSPWwaD fUS3so8d2esq9wWGaWkjOA..mgSTeN0ygmlFcurAZa240iNISEixSSxfEiDmTNm4HReM_p2KTd.J KeOmIX57Lfg4n0at2RTR8AltfRH.zy7MJ7mvKH91uO2NIoAb46yeGp.IskFnlNwh6CSJy_6UPO4_ g2bI1RlaPLBOfCiuM.SCUXB96Boop9NmUt.xuavRtsqbdML_v5oneKa7fgRvwLp34kcsZwkrPZQG npYloYKzOx5PzIxTLN03Y1hhrdcrrn3i4TzF4nTRAWXWctpBUYCcM_s.1rVxcz5SxwEh7xIG6lwI 0dCh_Q5deNolO9kGEhkqcy75u9CMErtw8gLWLQ25Y0JDgQwZsZfRhMJi2mmn_hfG.vVzuH1iPi9O ETujCe18Uki5Y4SEL9sz6N7FN.NDbm6BiqzBDpPZ15hTieMv48siWprLGiAzKDC.ZKu2V7WSJSlJ X.wJoYRhs27PP95lKZqJTlzGZNUTjX6W7BuDExY4ODKllfcLXJPO7Ea.yXAG9gMj8uDOoZ2ULFoP ni3yOz6Rumq46bANvoI3p5wBGvG5e355MJlsYUTWISectXXaovf2BjjTIyHN0jYwqDJ7bBo3RGrX tkvDmUkNVJoJJvVwkoQP6tEHGM6sw6VrXKwEC8Hd9VuL67OSwBryIV7Jh5_HHbH3vOiolJj8f9LZ z3C8UlAsGzjoq1h9scu87AUCqSqYp_oEu2XuO0Lgbss_LA_RSnRj4mbumId31Q1fLJfoGpavrEen DKnvfS0fBstsj9s6a4KlrkD29CITIg.t6Th.wbu1FeblfrMAfiwrEhwUEXh774.l5TH4GfjuWyNS Z7.ply_XHjyOjEfM1IZY5osUMIYD8QxPpq9hjY19cC.dng0U5pGPMQ6uQej1RGAnbEvoB4F4AzH_ UsxjdnOaPWI3Rn6.VDvNwwIK_3XJiQSqmveV1O.8inkCGjta7vfqMgWNcsiu0wOghje3uK2kcVMP XurMdCEJzizXfSGE89aR7sqElgkj.qL_bTHIk0sTja.gQg5UhHxRnQag4gMeI7fBMyQ8GbCaGKBf QabX0JzgF1eYyra9EQSjts9wgD0xsswFPoBC1C8TsOZY.wJgVMSCWo0evH68CzdcdIdyqg8xLNmr M854SgPDf X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Tue, 10 May 2022 18:49:53 +0000 Received: by hermes--canary-production-gq1-55bffbc6f9-t9x9t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bace21c8032641ca74130dc8e333f0f5; Tue, 10 May 2022 18:49:49 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? From: Mark Millard In-Reply-To: <75C02C8C-6A5E-4E19-AC7D-B5DB704E8F16@transactionware.com> Date: Tue, 10 May 2022 11:49:46 -0700 Cc: Pete Wright , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> <446d5913-a8c2-7dd0-860b-792fa9fe7c5b@nomadlogic.org> <33B740AA-A431-49CB-9F27-50B8C49734A2@yahoo.com> <3C5C183F-1471-4139-A53C-0B3815CFC25E@yahoo.com> <75C02C8C-6A5E-4E19-AC7D-B5DB704E8F16@transactionware.com> To: Jan Mikkelsen X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KyRtJ07FJz3MPg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fcGDPs0T; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.86 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.36)[-0.358]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-May-10, at 08:47, Jan Mikkelsen = wrote: > On 10 May 2022, at 10:01, Mark Millard wrote: >>=20 >> On 2022-Apr-29, at 13:57, Mark Millard wrote: >>=20 >>> On 2022-Apr-29, at 13:41, Pete Wright wrote: >>>>=20 >>>>> . . . >>>>=20 >>>> d'oh - went out for lunch and workstation locked up. i *knew* i = shouldn't have said anything lol. >>>=20 >>> Any interesting console messages ( or dmesg -a or /var/log/messages = )? >>>=20 >>=20 >> I've been doing some testing of a patch by tijl at FreeBSD.org >> and have reproduced both hang-ups (ZFS/ARC context) and kills >> (UFS/noARC and ZFS/ARC) for "was killed: failed to reclaim >> memory", both with and without the patch. This is with only a >> tiny fraction of the swap partition(s) enabled being put to >> use. So far, the testing was deliberately with >> vm.pageout_oom_seq=3D12 (the default value). My testing has been >> with main [so: 14]. >>=20 >> But I also learned how to avoid the hang-ups that I got --but >> it costs making kills more likely/quicker, other things being >> equal. >>=20 >> I discovered that the hang-ups that I got were from all the >> processes that I interact with the system via ending up with >> the process's kernel threads swapped out and were not being >> swapped in. (including sshd, so no new ssh connections). In >> some contexts I only had escaping into the kernel debugger >> available, not even ^T would work. Other times ^T did work. >>=20 >> So, when I'm willing to risk kills in order to maintain >> the ability to interact normally, I now use in >> /etc/sysctl.conf : >>=20 >> vm.swap_enabled=3D0 >=20 > I have been looking at an OOM related issue. Ignoring the actual leak, = the problem leads to a process being killed because the system was out = of memory. This is fine. After that, however, the system console was = black with a single block cursor and the console keyboard was = unresponsive. Caps lock and num lock didn=E2=80=99t toggle their lights = when pressed. >=20 > Using an ssh session, the system looked fine. USB events for the = keyboard being disconnected and reconnected appeared but the keyboard = stayed unresponsive. >=20 > Setting vm.swap_enabled=3D0, as you did above, resolved this problem. = After the process was killed a perfectly normal console returned. >=20 > The interesting thing is that this test system is configured with no = swap space. >=20 > This is on 13.1-RC5. >=20 >> This disables swapping out of process kernel stacks. It >> is just with that option removedfor gaining free RAM, there >> fewer options tried before a kill is initiated. It is not a >> loader-time tunable but is writable, thus the >> /etc/sysctl.conf placement. >=20 > Is that really what it does? =46rom a quick look at the code in = vm/vm_swapout.c, it seems little more complex. I was going by its description: # sysctl -d vm.swap_enabled vm.swap_enabled: Enable entire process swapout Based on the below, it appears that the description presumes vm.swap_idle_enabled=3D=3D0 (the default). In my context vm.swap_idle_enabled=3D=3D0 . Looks like I should also list: vm.swap_idle_enabled=3D0 in my /etc/sysctl.conf with a reminder comment that the pair of =3D0's are required for avoiding the observed hang-ups. The analysis goes like . . . I see in the code that vm.swap_enabled !=3D0 causes VM_SWAP_NORMAL : void vm_swapout_run(void) { =20 if (vm_swap_enabled) vm_req_vmdaemon(VM_SWAP_NORMAL); } and that in turn leads to vm_daemon to: if (swapout_flags !=3D 0) { /* * Drain the per-CPU page queue batches as a = deadlock * avoidance measure. */ if ((swapout_flags & VM_SWAP_NORMAL) !=3D 0) vm_page_pqbatch_drain(); swapout_procs(swapout_flags); } Note: vm.swap_idle_enabled=3D=3D0 && vm.swap_enabled=3D=3D0 ends up with swapout_flags=3D=3D0. vm.swap_idle. . . defaults seem to be (in my context): # sysctl -a | grep swap_idle vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 vm.swap_idle_enabled: 0 For reference: /* * Idle process swapout -- run once per second when pagedaemons are * reclaiming pages. */ void vm_swapout_run_idle(void) { static long lsec; =20 if (!vm_swap_idle_enabled || time_second =3D=3D lsec) return; vm_req_vmdaemon(VM_SWAP_IDLE); lsec =3D time_second; } [So vm.swap_idle_enabled=3D=3D0 avoids VM_SWAP_IDLE status.] static void vm_req_vmdaemon(int req) { static int lastrun =3D 0; =20 mtx_lock(&vm_daemon_mtx); vm_pageout_req_swapout |=3D req; if ((ticks > (lastrun + hz)) || (ticks < lastrun)) { wakeup(&vm_daemon_needed); lastrun =3D ticks; } mtx_unlock(&vm_daemon_mtx); } [So VM_SWAP_IDLE and VM_SWAP_NORMAL are independent bits in vm_pageout_req_swapout.] vm_deamon does: mtx_lock(&vm_daemon_mtx); msleep(&vm_daemon_needed, &vm_daemon_mtx, PPAUSE, = "psleep", vm_daemon_timeout); swapout_flags =3D vm_pageout_req_swapout; vm_pageout_req_swapout =3D 0; mtx_unlock(&vm_daemon_mtx); So vm_pageout_req_swapout is regenerated after thata each time. I'll not show the code for vm.swap_idle_enabled!=3D0 . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed May 11 00:49:49 2022 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 82A9D1AC1F80 for ; Wed, 11 May 2022 00:50:02 +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 4Kybsj3bydz4slQ for ; Wed, 11 May 2022 00:50:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652230194; bh=wplqi3e0gcZ7BtbfygQiKnh7hTiSWnKvwzMPGWN3hjM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ABgn/eFwKhaNBX2n2qM1VOZPWjBQTVwujN0HQ7fAPNkS6hOzlvAcReXA+ecfjQQRCDdod2YyEX5RmxEA7hpQFIT23ZFPIfB8YKt9jJIK/t5d9Sp9V756dKX0aiglB8IgokXtVIACuAsNnDLGCbxj4LcqQhAerV8ho76FmSD3JClVldJZoyyavDKj5AosU4XB7kyGgATXKbnY/Qt8/Uok7BgySSStVUb6sHmHJ7ZtdNVuzpziANVL4RhilbaJ4j31AlPnlMT7PIQCNB0bsmQvJ8k9gODbHhUMczR7X96bOS0mCP8spKe3U+1E97Sx/YC9h1CGuus/5EFuBDXyeyNuiA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652230194; bh=4xLjo3N8iAcpDUXcxyfi4FGVAWS5jINe0P2exEwS1Sh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=N34Svhn5udGD9VkJ5GJozSo0gQQA0j54agJP8jnXATYSBE53D2Sh8cVyB1HlxnPEe4F2CIIlHVjy5iok+SG5o3FdMaJ/MczOQ7esR7FXHKN2JpQIk6dNlUHJ6e5LMeHmy1HV7sTZT976GBH8D0KyNiY2DgT3n/S0Ro0o7H+h3KV2zdvFlX8U9fSCf078KLbeDYet8cIs90UhICCBOKpId/8ELyrXerHd0diPAN7RtUaN0I9WBS8Rt0jzpapyVHjM3q5rlqhTKyQk2BQ8Uzx+9wowF8Y7p/a53KUdn37DMxGrKA2qd3OvhDGrsgJHAyEi5unvIWTEnetCaiQ/UOzojA== X-YMail-OSG: zvg3_uwVM1llEa5eeWCl6UVcF6AF8dFb2fyxlC.cQwDN00VS2k5Ru9JTViT5d6_ kmWfm5Cr2oPEbdtgrDJa1aO2odBio362pT4LNT48A0tN0rNfdwoOFvYbVOahDjhTM2EawbZQheHr N59kQ3c3hKf1sCew4umUHgRLCyh07Be2UcGUyKqGMnMbaNYJxtOKQ.rBcBqyy_fS4ZIK0jMq1fyr ULJnzAUn5ZeHXE4ZfSAASMZFfArGh3U1YFSvqTEK.A6ajnZ.DmlqMAiF89tx12JOnQegq8lfdQdc 2f059MFZTXgXEbfNtZc8O9RUGO0mMKI2Dlvncc_ES3Mfz6i7R_dA01rnxxvLldpNKleo4F_7ztAq xHDrmiCX0AK1SlscgA_TE4vSO4Qb6RdCcGF2LXthI1iL9Gzj8agUnhfWDyfkEmhtJFKh5JoZcrt9 EHfF8ix6UyB_ZtRd5On9qfwJWPwN8xq_w4ewu7MWiqvAHEPEBUE1RB78_Nvih7jIdFXOxsUT2Gwr Emgw2B5gTgPUK241F3CSjGAQ6.dAGRTdxbwyMLOK8Mwgrhoc4Zi7PvO9eofbDMY_kCh_H1n_hzsL QhK4FGbAhyX5UwuprdrVPfxo6vS8I52qVe.7AbIWq4QDXEiXxtSHIA1GYtF86mGhYX18EAdMOV47 t70R769S7_XJwjcRdUFTAv4QJuooX5oS75kV0WFgyw8pmVwNwRVKOOtPvsZAGW4t5gI8kuAFzAwA 8MIF2G0nRNFgXXZwpe85_KqItXFHg9eJGH5maVGX.j0ZTAsUHpVBa5NmDu.vVBdKtJoQPBATrEWl PnKbPDnEZ_lvtfKHMHHe1O4CBJivHzpuihhJ8tmwt37cAU.Mp5NiS8hBLfY0sbLQjaALzLlkBOl8 R5VHiQtfNXMsM_QBFHG3PdBRjB3MogtUa1xgWJFekxcmGxWuFBqD_tkBWlehIE6c9IBQgVT3qce2 zS4ML7SW_OHuwhUBpfQKahGLCWFHjdWRdCvwuCKcvUUbaQMCkqiSejgkvV1qC_Fo5lkhfIFzhZlZ kta.yhXnUK1JkZ2d6UORNJyLGHoZy2Qn17nLd8AJX4K5A_s9QGb4QhVtv1RLPKbe0na3s1QvnV02 e9kmqm9ZdDEIQTrb9p0y3fuuffGokAYwim3EfNWg6k4LAYH4TyzPL9p3Dd9sULTYMGcJ9gwVH3WA F6bteU4MpFDPQUCy4FWeeHpdOTZ3DClz8GqvXtHEc6Ujp25iugnnBNllLS6tFltLcsMfyuVj6Mt5 nEUWU20Q6trkTvr7_OQGi51lZAsA24sXoPcfq1GwD8B7o.0QXNwi0O_QOQWBaNJkHqFt7mngm1iZ 4iTMhWaUneCCttPg.MaC6WMiXUrNyzZyNID_Jkv9x9EgA95LcRdioYnHFdSOWbnHSgwWEPuFCTKp XjpCAem_2g6J9Op3DqIq1dfhxxd5R8ryiZx3ydBU.U2BDnIdnDUaeJ3UlhB3DDDyaIRaERnthEvg TIsm9ilz80YyJq2e8HtwNfG7Y5kTX9TONCZqjE8_tjmrjUYht9HVnu4sA76PCqmYryS6RLj.gXBk pWPvTtHHo_EqNOgJReAqeIwFjlzSCER3PlRtcjM1a0LVA2G4D2f.oKR_gM1EPhriru9ZquHEnXWY QGB3qqhFJyEKRT65wHCVcqnCBDdBWb2p979FyXl9aTsL7AGodYT.MRlrcQJNXdo1eRYi_tNkS4Ii gvDcjh9IlCtooUc4wyCVj.sLrO_J7V10LUJji14_pDC46xheh0bI_5nM0m41hyOlG9QQUCp2REpz byLs_cKyaZk_Kjjf9CHFWGY3OTcvqiCFygwAnVkXx0tX5e104v43C7l6OeXGowbH7dH_GYUkGDBj ITA1y_cx_KH3.ksjhOV833EUsndEIIBdJ_p1Mdo1Ry18sNp3j5XfeXB7QHTKesjeP1SsRUnKaZLS fFztSrgzpgYvOZSiljh648zH52ID6FxkqoLQYGKE3Vi0OAB_aYT73oATXHI.FLfyIJBKD91weDi0 X_n30SHyKna3rC13lQLR3EcT55MIlixZinFOLakqlR3E5HdUOkQxV_Au6eK.fqJKeP34hagGANXz xnAE2ymWQBoedM2zAsoezTub7uoHgQ3uT_xvMrxIvZYiuMNWAO1n2pY13pI1SMzcuIivN.M3x2cy y.oRRZd0IoRkfAK7k7LuwyR0f97yQugw6EmI_dw4r36qqpAqQrrOunml7k2_7Uix1qmZlH78rbYb jeIh6CqYATW9xfNcf.ZDke6qEK3Z8QXbjJ9Myfu3pKxaeFnW0OmceTXI63x.s2nx9WeXVf6ZV.u0 DHbxkgtezzJFk_Cs.7sql X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 11 May 2022 00:49:54 +0000 Received: by hermes--canary-production-gq1-55bffbc6f9-bklb9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9234404eed8d8a486ddfd38ff39546f1; Wed, 11 May 2022 00:49:52 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? From: Mark Millard In-Reply-To: Date: Tue, 10 May 2022 17:49:49 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> <446d5913-a8c2-7dd0-860b-792fa9fe7c5b@nomadlogic.org> <33B740AA-A431-49CB-9F27-50B8C49734A2@yahoo.com> <3C5C183F-1471-4139-A53C-0B3815CFC25E@yahoo.com> <75C02C8C-6A5E-4E19-AC7D-B5DB704E8F16@transactionware.com> To: Jan Mikkelsen , Pete Wright X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Kybsj3bydz4slQ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="ABgn/eFw"; 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 X-Spamd-Result: default: False [-0.02 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.37)[0.371]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.11)[0.107]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-May-10, at 11:49, Mark Millard wrote: > On 2022-May-10, at 08:47, Jan Mikkelsen = wrote: >=20 >> On 10 May 2022, at 10:01, Mark Millard wrote: >>>=20 >>> On 2022-Apr-29, at 13:57, Mark Millard wrote: >>>=20 >>>> On 2022-Apr-29, at 13:41, Pete Wright wrote: >>>>>=20 >>>>>> . . . >>>>>=20 >>>>> d'oh - went out for lunch and workstation locked up. i *knew* i = shouldn't have said anything lol. >>>>=20 >>>> Any interesting console messages ( or dmesg -a or /var/log/messages = )? >>>>=20 >>>=20 >>> I've been doing some testing of a patch by tijl at FreeBSD.org >>> and have reproduced both hang-ups (ZFS/ARC context) and kills >>> (UFS/noARC and ZFS/ARC) for "was killed: failed to reclaim >>> memory", both with and without the patch. This is with only a >>> tiny fraction of the swap partition(s) enabled being put to >>> use. So far, the testing was deliberately with >>> vm.pageout_oom_seq=3D12 (the default value). My testing has been >>> with main [so: 14]. >>>=20 >>> But I also learned how to avoid the hang-ups that I got --but >>> it costs making kills more likely/quicker, other things being >>> equal. >>>=20 >>> I discovered that the hang-ups that I got were from all the >>> processes that I interact with the system via ending up with >>> the process's kernel threads swapped out and were not being >>> swapped in. (including sshd, so no new ssh connections). In >>> some contexts I only had escaping into the kernel debugger >>> available, not even ^T would work. Other times ^T did work. >>>=20 >>> So, when I'm willing to risk kills in order to maintain >>> the ability to interact normally, I now use in >>> /etc/sysctl.conf : >>>=20 >>> vm.swap_enabled=3D0 >>=20 >> I have been looking at an OOM related issue. Ignoring the actual = leak, the problem leads to a process being killed because the system was = out of memory. This is fine. After that, however, the system console was = black with a single block cursor and the console keyboard was = unresponsive. Caps lock and num lock didn=E2=80=99t toggle their lights = when pressed. >>=20 >> Using an ssh session, the system looked fine. USB events for the = keyboard being disconnected and reconnected appeared but the keyboard = stayed unresponsive. >>=20 >> Setting vm.swap_enabled=3D0, as you did above, resolved this problem. = After the process was killed a perfectly normal console returned. >>=20 >> The interesting thing is that this test system is configured with no = swap space. >>=20 >> This is on 13.1-RC5. >>=20 >>> This disables swapping out of process kernel stacks. It >>> is just with that option removedfor gaining free RAM, there >>> fewer options tried before a kill is initiated. It is not a >>> loader-time tunable but is writable, thus the >>> /etc/sysctl.conf placement. >>=20 >> Is that really what it does? =46rom a quick look at the code in = vm/vm_swapout.c, it seems little more complex. >=20 > I was going by its description: >=20 > # sysctl -d vm.swap_enabled > vm.swap_enabled: Enable entire process swapout >=20 > Based on the below, it appears that the description > presumes vm.swap_idle_enabled=3D=3D0 (the default). In > my context vm.swap_idle_enabled=3D=3D0 . Looks like I > should also list: >=20 > vm.swap_idle_enabled=3D0 >=20 > in my /etc/sysctl.conf with a reminder comment that the > pair of =3D0's are required for avoiding the observed > hang-ups. >=20 >=20 > The analysis goes like . . . >=20 > I see in the code that vm.swap_enabled !=3D0 causes > VM_SWAP_NORMAL : >=20 > void > vm_swapout_run(void) > { >=20 > if (vm_swap_enabled) > vm_req_vmdaemon(VM_SWAP_NORMAL); > } >=20 > and that in turn leads to vm_daemon to: >=20 > if (swapout_flags !=3D 0) { > /* > * Drain the per-CPU page queue batches as a = deadlock > * avoidance measure. > */ > if ((swapout_flags & VM_SWAP_NORMAL) !=3D 0) > vm_page_pqbatch_drain(); > swapout_procs(swapout_flags); > } >=20 > Note: vm.swap_idle_enabled=3D=3D0 && vm.swap_enabled=3D=3D0 ends > up with swapout_flags=3D=3D0. vm.swap_idle. . . defaults seem > to be (in my context): >=20 > # sysctl -a | grep swap_idle > vm.swap_idle_threshold2: 10 > vm.swap_idle_threshold1: 2 > vm.swap_idle_enabled: 0 >=20 > For reference: >=20 > /* > * Idle process swapout -- run once per second when pagedaemons are > * reclaiming pages. > */ > void > vm_swapout_run_idle(void) > { > static long lsec; >=20 > if (!vm_swap_idle_enabled || time_second =3D=3D lsec) > return; > vm_req_vmdaemon(VM_SWAP_IDLE); > lsec =3D time_second; > } >=20 > [So vm.swap_idle_enabled=3D=3D0 avoids VM_SWAP_IDLE status.] >=20 > static void > vm_req_vmdaemon(int req) > { > static int lastrun =3D 0; >=20 > mtx_lock(&vm_daemon_mtx); > vm_pageout_req_swapout |=3D req; > if ((ticks > (lastrun + hz)) || (ticks < lastrun)) { > wakeup(&vm_daemon_needed); > lastrun =3D ticks; > } > mtx_unlock(&vm_daemon_mtx); > } >=20 > [So VM_SWAP_IDLE and VM_SWAP_NORMAL are independent bits > in vm_pageout_req_swapout.] >=20 > vm_deamon does: >=20 > mtx_lock(&vm_daemon_mtx); > msleep(&vm_daemon_needed, &vm_daemon_mtx, PPAUSE, = "psleep", > vm_daemon_timeout); > swapout_flags =3D vm_pageout_req_swapout; > vm_pageout_req_swapout =3D 0; > mtx_unlock(&vm_daemon_mtx); >=20 > So vm_pageout_req_swapout is regenerated after thata > each time. >=20 > I'll not show the code for vm.swap_idle_enabled!=3D0 . >=20 Well, with continued experiments I got an example of a hangup for which looking via the db> prompt did not show any swapping out of process kernel stacks ( vm.swap_enabled=3D0 was the context, so expected ). The environment was ZFS (so with ARC). But this was testing with vm.pageout_oom_seq=3D120 instead of the default vm.pageout_oom_seq=3D12 . It may be that let sit long enough things would have unhung (external perspective). It is part of what I'm experimenting with so we will see. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed May 11 03:31:35 2022 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 B5AF21ADE39B for ; Wed, 11 May 2022 03:31:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.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 4KygSN4q9nz3QbT for ; Wed, 11 May 2022 03:31:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652239900; bh=ldnkwlQa4Cs655eecb1pcSOiwAItLSoXZkNbfl1PeLk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Boyy9Slr1u5tWQ3Z24+DP2JYxHoQyguoiLPudK6QD0UbLP2Zyxdsww0krifT8hvKzc67xZv6DGF4VUGi3E3WG29VxgsaFl1W9jJ5zaYTeAzPc4Jj7L2ULzMQxafqidVZDCdlKRiuDMLhJhUGEzK9odrI07Cw8aq/NDVCOfjKJcauQO0tW3Rvd1kDCfm66Ap0k1onv+XMtDRVNxhYA+tAVgvOpoMWU0NDIkDKiNokTbxgg6I9LL9TXqdA2+Zm2ei33Yvj/61fro91AxupiaiOunJv2BJ6shodkWH3Sfk7ma1kZY//4qi+mBILOwdLX97sHWpiEuTHvAza1hiBW1BHzQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652239900; bh=w3pySNr3ojw2LbI5PDfHCa4ljB6halRrwu3odvLQSUn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=G77zeMhH/vp7RDf/lzOHKrOasxMZu2lX0lBFOYEFjWByKRV9jbE/ZJ5VARhMZFdveMPzPf+iroWkTzSho7N8b7odlMFyWvBcpAI2ZnD8CIDrzDNbJB65UEjZzSuKHEUkDttls4JjX6PC9Hh/crY9Vz78Ju8vlm6/sMQ04M4DqNRvIepaOgjfwim+IN5pX42DNgepEXNA4g6GJHDeJTsfAWSHR+j95oTL5XwyHwlJ2Tl4rdtoU+dh5Xuhdp45oN00VMJqbztmAFz+WpWuiVlqh+8eEvH2NU9ayghAmQt0YfGITRl0SaN3dLbCswmQrgjSCBIMY2WP7imMxNNWLnSXcw== X-YMail-OSG: HLamKZ0VM1kbcuy97PaWVeIsq7JQdhnZmluatPNWsj.MFoA8_hK4QN8Xi2FG_Xm 0QsCTdYZqbXihPPN9YuwnhZ9ML_3dmrOCCKYwtI_zKWYzUKrdzwGFBC8j_EaDZoi04IRmiUitkeG F4JUtemxCUJizVAPWMemT8ghtKNQfUZSu9_B4Npq0bjMwRUSTYcrhtDfHGyX7Fljlve1n_0X1KNk iNzuZVHEUB56.VDMojymuJnKa.ZgO62861QisL4bbd5I0clF03EzGcSaWkATUszZfNW0Wwku1wA. 16R09yEJ5mcNPf4qb2IPcXNpEtU27bW6Mjy7iZy9gGlQic_GAbEneQeV105ezpCh.0d8hGGR8XsT LEPG.7F7j0XZu0RLxYyk4XjR9OHTO24_N_XbrVHhJjp5_3TUP35sABtvXPSEB.zKtSjReF8e5jcQ ax0OVNpW7JxqifcHk.RtcglHjRdzn.j0EskiNaRYiVTu.1T963lfzZFbeltxmUsgeW6xIVWtEemm itBnrVvTJtVJrndTRKYokh1KNKq6Atx.VKdGCNC4iuaECwNgk_v3XUkdBK72T1HqPeTraxM4z41q SsRDnAcq3dEFrHPWLH3pxJDRZGa._U9rGSkhZfOE7H3Fo5kye9yUFPNiPbedP.SeKa9HlrezDchx BAwhJJViheOo6ekVJv_hQWfQROK_fo902sJwXIQuoChk4LWXirooGbBVv91PLSYYrQw6zyxJx8zv 7j0yzCA.qBnnbX49Tkr_oaMld5JDX2yWG7BkxwJZYBD50mr4X4WItfuThXDi4YvGJfk7ASwBJ6Nw MyaKg3sIsLVN9bBrnjbGVTXgi9A85o1vRPuaWWVNHeEGj.pFQMGRiM_tHXBNnK_R7OXkleRo71gI Op07JLAeOv0uVqYSI4mWcLZD1U6QDnfjEh2AbwU946CBXEfEk0Wlko6nJdeWs08NCdPjSsI9hB_B jvPGAFFl.5jZ49an85lfY9IDu.bTcMMfr8Hr4RJV6jK7SAjip.f_E_oBjOkm7jr7tSRYJJvF34Iy ZokvSEVnKVMuNVpf.CZ3EBZaSPug.vETZSOEPe7cw6rwEPHY9JQ7f0J9LWJh0Ggq6Psru5p1mb.e X.1Wk53YbI.EoitpDGY5PiR8mTTV5HkYx8hXIjenh_LI6VEOZuc1r3cerwAu77xnjMi99_EZX6zd CO.ot1omMhsAEboCDWsOsg8QT8tyLTmpslJaFXBlvZSIzPgG4ihGvyf2kcwsTM9bsLDa6LGwKemX iNvsbVpNv7tvB65UMryLuksm99.gRjctT1xzaoohirQV5MS7pjwTten01g38rBSDsnN4kqTp3td1 Z7BMNz3kuBqbiiJZX3U91terDWef.TlWuTfL4JJfWNuazPnG5xyDIz9CTC.ZyaWF7HtOLB65wyo_ qXCwqAXxRItD15k2ggmVM.VWRbgLa75.r0dPruVzyiLDPd61T0RsWtMyZX1TJDopuZGK_mmzPotr .8NhOfizE6hicaEN53V_Aew6fVZOTsxvcMTo_e9zl9DWLHefUkqwm6m0z27v7Ml_VHv6CfuxplvP yw8dg._woApdBZt.ewfGclAeEcUM0lJWOx.azZZFjAG3RhGJYgzisI6htdfiz.OCf8U17KwQZsdB SBXpWNPTi4kqJjedRzkvTiJEbzCK2flh9AAnYhvuMERyGvUgoqR4_s0ExfKT.vhEM4JCWXm_yaLQ BBZ1qI9R50eB54C.z_iJn4atNQRRdoIbSfXOUS9aD6mszzEAzMZy2tpRFmHMTfghjY.HdHk1o3cx TtSoNnSnwCeT9cw6I6tp.w9Dx6l8daYyyDrz9rQWiSpJR6ialRK0LtXsG4WlY3l1c3IQTH3TJUsN ilwp4V8Ky.KWbWxKkelzNFRdhhG69LDiZT9kw0DfdgcnQ2fqVaytx_hMX73T6NyFjjTaIKsT2qPY tw3QEWoKHNywoVvIPpcFjQR2bqgIQ03W9806fqnBp7SSw8J2jkA.8L3sLarqBQqVLd5bWt6VbimU ZnPdMnkVwtjPZfJhbe0whSzt9bbL6ITiLjQ.z7VjSzxbBdTXlom1txB0yCm_F5LwQUx0sHU.ycgK Bi0MJuc5xC.LFxpXIQ41qIRJgeK5V_EiIM3DQViWLSSR3fMvDtT6aSaunog4jfcBxjfGScqLy3Dd iSKtPuyolu4gCwHVWkkls3DppQ16XiAC7OzqPXwYpkuTC2sc5FZpz9gybFCrYtxkirXbnoEOsj7t 5bvn5AOfFFFl9WZz3800ZYZ8SFV2kYgXhJMzMznuCTOZbeJk3UL.7vBbKnM8Bn2TI21IoUX8IkaZ AxAp5.a9SIB8qivLJvDua X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 11 May 2022 03:31:40 +0000 Received: by hermes--canary-production-ne1-8676f67b88-d48nl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 56e72f7e16dfc5a4bd912a9e53d2df4f; Wed, 11 May 2022 03:31:38 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? From: Mark Millard In-Reply-To: Date: Tue, 10 May 2022 20:31:35 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> <446d5913-a8c2-7dd0-860b-792fa9fe7c5b@nomadlogic.org> <33B740AA-A431-49CB-9F27-50B8C49734A2@yahoo.com> <3C5C183F-1471-4139-A53C-0B3815CFC25E@yahoo.com> <75C02C8C-6A5E-4E19-AC7D-B5DB704E8F16@transactionware.com> To: Jan Mikkelsen , Pete Wright X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KygSN4q9nz3QbT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Boyy9Slr; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.44 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.94)[-0.945]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-May-10, at 17:49, Mark Millard wrote: > On 2022-May-10, at 11:49, Mark Millard wrote: >=20 >> On 2022-May-10, at 08:47, Jan Mikkelsen = wrote: >>=20 >>> On 10 May 2022, at 10:01, Mark Millard wrote: >>>>=20 >>>> On 2022-Apr-29, at 13:57, Mark Millard wrote: >>>>=20 >>>>> On 2022-Apr-29, at 13:41, Pete Wright wrote: >>>>>>=20 >>>>>>> . . . >>>>>>=20 >>>>>> d'oh - went out for lunch and workstation locked up. i *knew* i = shouldn't have said anything lol. >>>>>=20 >>>>> Any interesting console messages ( or dmesg -a or = /var/log/messages )? >>>>>=20 >>>>=20 >>>> I've been doing some testing of a patch by tijl at FreeBSD.org >>>> and have reproduced both hang-ups (ZFS/ARC context) and kills >>>> (UFS/noARC and ZFS/ARC) for "was killed: failed to reclaim >>>> memory", both with and without the patch. This is with only a >>>> tiny fraction of the swap partition(s) enabled being put to >>>> use. So far, the testing was deliberately with >>>> vm.pageout_oom_seq=3D12 (the default value). My testing has been >>>> with main [so: 14]. >>>>=20 >>>> But I also learned how to avoid the hang-ups that I got --but >>>> it costs making kills more likely/quicker, other things being >>>> equal. >>>>=20 >>>> I discovered that the hang-ups that I got were from all the >>>> processes that I interact with the system via ending up with >>>> the process's kernel threads swapped out and were not being >>>> swapped in. (including sshd, so no new ssh connections). In >>>> some contexts I only had escaping into the kernel debugger >>>> available, not even ^T would work. Other times ^T did work. >>>>=20 >>>> So, when I'm willing to risk kills in order to maintain >>>> the ability to interact normally, I now use in >>>> /etc/sysctl.conf : >>>>=20 >>>> vm.swap_enabled=3D0 >>>=20 >>> I have been looking at an OOM related issue. Ignoring the actual = leak, the problem leads to a process being killed because the system was = out of memory. This is fine. After that, however, the system console was = black with a single block cursor and the console keyboard was = unresponsive. Caps lock and num lock didn=E2=80=99t toggle their lights = when pressed. >>>=20 >>> Using an ssh session, the system looked fine. USB events for the = keyboard being disconnected and reconnected appeared but the keyboard = stayed unresponsive. >>>=20 >>> Setting vm.swap_enabled=3D0, as you did above, resolved this = problem. After the process was killed a perfectly normal console = returned. >>>=20 >>> The interesting thing is that this test system is configured with no = swap space. >>>=20 >>> This is on 13.1-RC5. >>>=20 >>>> This disables swapping out of process kernel stacks. It >>>> is just with that option removedfor gaining free RAM, there >>>> fewer options tried before a kill is initiated. It is not a >>>> loader-time tunable but is writable, thus the >>>> /etc/sysctl.conf placement. >>>=20 >>> Is that really what it does? =46rom a quick look at the code in = vm/vm_swapout.c, it seems little more complex. >>=20 >> I was going by its description: >>=20 >> # sysctl -d vm.swap_enabled >> vm.swap_enabled: Enable entire process swapout >>=20 >> Based on the below, it appears that the description >> presumes vm.swap_idle_enabled=3D=3D0 (the default). In >> my context vm.swap_idle_enabled=3D=3D0 . Looks like I >> should also list: >>=20 >> vm.swap_idle_enabled=3D0 >>=20 >> in my /etc/sysctl.conf with a reminder comment that the >> pair of =3D0's are required for avoiding the observed >> hang-ups. >>=20 >>=20 >> The analysis goes like . . . >>=20 >> I see in the code that vm.swap_enabled !=3D0 causes >> VM_SWAP_NORMAL : >>=20 >> void >> vm_swapout_run(void) >> { >>=20 >> if (vm_swap_enabled) >> vm_req_vmdaemon(VM_SWAP_NORMAL); >> } >>=20 >> and that in turn leads to vm_daemon to: >>=20 >> if (swapout_flags !=3D 0) { >> /* >> * Drain the per-CPU page queue batches as a = deadlock >> * avoidance measure. >> */ >> if ((swapout_flags & VM_SWAP_NORMAL) !=3D 0) >> vm_page_pqbatch_drain(); >> swapout_procs(swapout_flags); >> } >>=20 >> Note: vm.swap_idle_enabled=3D=3D0 && vm.swap_enabled=3D=3D0 ends >> up with swapout_flags=3D=3D0. vm.swap_idle. . . defaults seem >> to be (in my context): >>=20 >> # sysctl -a | grep swap_idle >> vm.swap_idle_threshold2: 10 >> vm.swap_idle_threshold1: 2 >> vm.swap_idle_enabled: 0 >>=20 >> For reference: >>=20 >> /* >> * Idle process swapout -- run once per second when pagedaemons are >> * reclaiming pages. >> */ >> void >> vm_swapout_run_idle(void) >> { >> static long lsec; >>=20 >> if (!vm_swap_idle_enabled || time_second =3D=3D lsec) >> return; >> vm_req_vmdaemon(VM_SWAP_IDLE); >> lsec =3D time_second; >> } >>=20 >> [So vm.swap_idle_enabled=3D=3D0 avoids VM_SWAP_IDLE status.] >>=20 >> static void >> vm_req_vmdaemon(int req) >> { >> static int lastrun =3D 0; >>=20 >> mtx_lock(&vm_daemon_mtx); >> vm_pageout_req_swapout |=3D req; >> if ((ticks > (lastrun + hz)) || (ticks < lastrun)) { >> wakeup(&vm_daemon_needed); >> lastrun =3D ticks; >> } >> mtx_unlock(&vm_daemon_mtx); >> } >>=20 >> [So VM_SWAP_IDLE and VM_SWAP_NORMAL are independent bits >> in vm_pageout_req_swapout.] >>=20 >> vm_deamon does: >>=20 >> mtx_lock(&vm_daemon_mtx); >> msleep(&vm_daemon_needed, &vm_daemon_mtx, PPAUSE, = "psleep", >> vm_daemon_timeout); >> swapout_flags =3D vm_pageout_req_swapout; >> vm_pageout_req_swapout =3D 0; >> mtx_unlock(&vm_daemon_mtx); >>=20 >> So vm_pageout_req_swapout is regenerated after thata >> each time. >>=20 >> I'll not show the code for vm.swap_idle_enabled!=3D0 . >>=20 >=20 > Well, with continued experiments I got an example of > a hangup for which looking via the db> prompt did not > show any swapping out of process kernel stacks > ( vm.swap_enabled=3D0 was the context, so expected ). > The environment was ZFS (so with ARC). >=20 > But this was testing with vm.pageout_oom_seq=3D120 instead > of the default vm.pageout_oom_seq=3D12 . It may be that > let sit long enough things would have unhung (external > perspective). >=20 > It is part of what I'm experimenting with so we will see. >=20 Looks like I might have overreacted, in that for my current tests there can be brief periods of delayed response, but things respond in a little bit. Definately not like the hang-ups I was getting with vm.swap_enabled=3D1 . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed May 11 05:15:31 2022 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 4A3FC1ABF422 for ; Wed, 11 May 2022 05:15:45 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KyjmJ3dn8z3prs for ; Wed, 11 May 2022 05:15:44 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-ej1-x634.google.com with SMTP id i27so1701230ejd.9 for ; Tue, 10 May 2022 22:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=xmbO0ffwtUBH3nWQ84mAjGbB106G1KPUCyOWdgDfkZg=; b=L9XcNQ+fmzSz3+1fWKqong0YHoi62ijQG9NsxTp4pmO2gbiryhV8XpMM6gkQqRqG/R 2aHpAlbC7l3D2Um3XOaEYS9D0IanJQ5jpPvyJg3AlJWDsn5OK9y5vRP1f/h8iBEQczrc tOukWhhvLmO0XNr420+Cz/AQWiLEDSSRRXCCMNxGVvrtxlrF1ncdN5prLLmnd+ChDqgM EbSg/3awdvdkCI3QSDgxfZ1NzDBj32YEmz2OXiD9Kg0/r+3xaOJ51IPK24te00PvM9vK c/KZ4Esl2RCCCk9jl0ZW/e0j6nQx/KIu2ZG41IyfCax/TRC+IkNQzFCiSE2HqjlEssHY ywyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xmbO0ffwtUBH3nWQ84mAjGbB106G1KPUCyOWdgDfkZg=; b=QhRjT9YjqbZsJLQK5iw8s7kMCBwzoXjXTBmMCCnxMF5Q1LFdTDJdeByP6VGTbcy8cJ kBan5WbTahPL/3py2p20Ptz9q4cQHWHrhtNuCQ73XBrUacoqbbe3FzeNwll6Np1ti5Se mFlOz1M48ArB7sjLaK/Sx4VrEGn4a+kBQtdj8gFrgIZMCMXiLfGQioOqK3a6wZXfGWzR okN8umkNmLyylUY7x26g5eKrgLa2Zw3W1cLPUflWg9csv5dh/R9fi6Rj5MIDD1YiVOGL UYa7yiUmRnGYek62kQuqzwQS86pclOdcdiUGlKc285R4yloSVvpDtA2MmrSHqtllGLQn O3Lw== X-Gm-Message-State: AOAM53258T5Me72ErGoaGc7IGrbqeSEOAAW1QBUoWIlsNFD83ma5kHGA EkjuXLpWhyaino9raM+kTNnPmdX7nkRchxUV1lxQmdF7AYA= X-Google-Smtp-Source: ABdhPJwPd2rfIT9yldDQGKIb1TrYeL2+E/z4bp8fDJUqRRQ7SBHmB6ZxZUPoOhlAAVZnFrc5kjcfvobY3LuXmZALEmg= X-Received: by 2002:a17:907:1693:b0:6f4:ee60:16e8 with SMTP id hc19-20020a170907169300b006f4ee6016e8mr21531430ejc.312.1652246142335; Tue, 10 May 2022 22:15:42 -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: Dustin Marquess Date: Wed, 11 May 2022 00:15:31 -0500 Message-ID: Subject: VNET lock reversal To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KyjmJ3dn8z3prs X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=L9XcNQ+f; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dmarquess@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=dmarquess@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Just updated my -CURRENT box from a build almost exactly 14 days ago to one just about an hour old. When a VNET jail starts, I'm seeing a lock reversal: lock order reversal: 1st 0xffffffff81e893a8 allprison (allprison, sx) @ /usr/src/sys/kern/kern_jail.c:1378 2nd 0xffffffff81f99fe8 vnet_sysinit_sxlock (vnet_sysinit_sxlock, sx) @ /usr/src/sys/net/vnet.c:579 lock order allprison -> vnet_sysinit_sxlock attempted at: #0 0xffffffff80c9b7c6 at witness_checkorder+0xbd6 #1 0xffffffff80c35c67 at _sx_slock_int+0x67 #2 0xffffffff80d92185 at vnet_alloc+0x115 #3 0xffffffff80be7e02 at kern_jail_set+0x1722 #4 0xffffffff80be92f0 at sys_jail_set+0x40 #5 0xffffffff811200aa at amd64_syscall+0x13a #6 0xffffffff810f12eb at fast_syscall_common+0xf8 I'll try and see if I can get a bisect going if somebody else hasn't seen this yet. -Dustin From nobody Wed May 11 14:58:27 2022 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 273111AC95A4 for ; Wed, 11 May 2022 14:58:45 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kyyj03Fbgz3PYd for ; Wed, 11 May 2022 14:58:44 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd2c.google.com with SMTP id a10so2317440ioe.9 for ; Wed, 11 May 2022 07:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5Vj3KRN06A8jdRJprwGFnM2PbK9SNAIiX6E3jQ6XFa8=; b=aXj2hiVYKbvt4g0MhBHNlOX5UxBnTZPeRyOkkMxU7t8yJfltZoFTeC2GgHgsAtOm8s 4go6EHWznN6i6P1TZ3LnlU/Wgi0NiEO2PutQUV6gXsduF+M+c4s7Yi2QysH3/0VPnv5W CV3/6hJE0KVukToD4vBNaEv8VnEYljH6ilYZW3Qjh+MyTfb7pcKjTFDPOuoQakXDnTM0 3IDq6vET5AWd32h2BUbRrNGT+ZycaTuQaM6cMo9US8rlx5WBKVLi9AiQYernydpYQGjY r4heg7C9/BG8NXBTvhMwdGxV2G2Tj5Ud5ciywDyslgxLl8Gc2YUX/dwSMU5kWMjFW1mY MD3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5Vj3KRN06A8jdRJprwGFnM2PbK9SNAIiX6E3jQ6XFa8=; b=uVYzkdMq/60U5RnFiWwgOByH7hcnSeUv3NA9mGE/Y+tScdrp0G8WoqwysjbHNTZI8k BT+c5Hh3vpi3l1yobU71r39usdo8vinCpcR1AhL+FrUc8YRUXfw522u/4KEPFdAZvnro GbVy6YjFEQiamJPMmtcbYJLJe7PGjO4kSbfptA0xYrD9+p4fvn6ZK+ZCGFNvJMjIu4CL pRe8LJU8eZ5HMTzxySnjS3802J8z0DKOE5iQZt12ySawxwS+lxpIUs8xMGFKhJsDBhB9 cWXTMePytAFQJUyed2jfC1bolyHT1/N2yjUIY9WQO0kJD9Bdt2Ma96DZYRc9hp8zTq5n 1mcg== X-Gm-Message-State: AOAM533idsBBpXeVLZgnnnld64tD+nDt0BnaI76hWNFin/VE5jeDlstI gqsBcq+LQ/T/fA3em2t6Wjzx1ti/vkgdvWfStIM= X-Google-Smtp-Source: ABdhPJxgeXIBwbiYVIHwquDAwrAqOjW1D9vy+Bm//oPNx5R8H5pwDQVmyB1F6Fn9CKTDttyYXH0cRiXvr1TCYtLrkPY= X-Received: by 2002:a05:6602:2c4e:b0:657:4115:d9e4 with SMTP id x14-20020a0566022c4e00b006574115d9e4mr11099638iov.91.1652281117736; Wed, 11 May 2022 07:58:37 -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: <481e0739-bdc4-4ce6-a856-a80cf5294d03@www.fastmail.com> In-Reply-To: <481e0739-bdc4-4ce6-a856-a80cf5294d03@www.fastmail.com> From: Michael Schuster Date: Wed, 11 May 2022 16:58:27 +0200 Message-ID: Subject: Re: FreeBSD, boot environments and /dev To: Dave Cottlehuber Cc: Wes Maag , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Kyyj03Fbgz3PYd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=aXj2hiVY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::d2c as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-0.02 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.98)[0.977]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2c:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, May 9, 2022 at 10:04 AM Dave Cottlehuber wrote: > > On Mon, 9 May 2022, at 06:25, Michael Schuster wrote: > > On Fri, May 6, 2022 at 12:15 AM Wes Maag wrote: > >> > >> > >> On Thu, May 5, 2022 at 4:10 PM Michael Schuster wrote: > >>> Hi all, > >>> > >>> while still working (slowly) on an answer to my own question on the > >>> right workflow to keep current up to date reliably with boot > >>> environments, I noticed that after creating and mounting a new BE, > >>> that new BE's /dev (eg /mnt/dev) is very sparsely populated: > > This is expected; /dev would usually be empty until devfs is mounted. You're right - I have a few "historical" BEs lying around, and for most of them, /dev/ is empty. As you guess (below), for the others, they're most likely remnants of the first time I tried to do "pkg -c /mnt" without /mnt/dev being mounted. (as an aside: when was that changed? I know for sure that this hasn't always been necessary) I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only regular files and empty directories). Booting into that BE didn't work either, I got errors about missing "/dev/" files (can't recall the exact names). What do you guys (plural ;-)) think? Thx Michael > > Looking into the unmounted /dev via the last zfs snapshot of your > / filesystem should also be empty: > > $ ls -AFGhl /.zfs/snapshot/$(ls -rt /.zfs/snapshot/ | tail -1)/dev > total 0 > > If it's not I'd guess these are stray garbage from BE experiments > where /dev wasn't mounted and various scripts & tools tried to pipe > via /dev/{fd,zero,null,...}. > > If you created a hypothetical "empty" BE from scratch, unpacked > src tarballs into it, it would also be empty. > > A+ > Dave -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From nobody Wed May 11 16:20:37 2022 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 C641C1AD941E for ; Wed, 11 May 2022 16:20:49 +0000 (UTC) (envelope-from cristian.cardoso11@gmail.com) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kz0Wj14pTz3qXc; Wed, 11 May 2022 16:20:49 +0000 (UTC) (envelope-from cristian.cardoso11@gmail.com) Received: by mail-qt1-x82d.google.com with SMTP id g3so1100206qtb.7; Wed, 11 May 2022 09:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yfZy4u3jmHCMW8bGr4cy6SgIhAqHyHrJ+JcGrgHahuE=; b=aAnPTS3jc1ueNS41YpW7iV6TBW8A3GmjbMV9+GVGvMDyOl9LSlWyNQ7jwMGgX+Q/JD nNex9bYukZ+zw3D/DSTsYVc2bSCBs//ZfI34KBpQqAMG7nc2s/ngs1t956rAHY/ANF4w yG5YN+P+SWnEK0/NTVZU+kB9ZpGp2R484tB3GBJ4LxkkePfD4Smc+S0HFqXc7N/FCU3y PnnvxqGy+3H62L2J7p8ht573Ow4qG+pKb1SW++1CwfGK6GqzuFixyaWja5JLh9X6hvDE XTItk5ypucUh4TEV1vv53y4j+KFk/OqCCDAdmyPtxaa51oZLncGHJ0ODMmWYG0cIApdw tPHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yfZy4u3jmHCMW8bGr4cy6SgIhAqHyHrJ+JcGrgHahuE=; b=NTewigbnHoxdmjUq0oYMx2orplD45xbU8KXvRhE4q1EmRc4vLx1//9ELzM1W8iZStO 3+1xN5yGHOGOfbc6U4O1o4BAHbw5Gp7G4RBHVFl6awEfl9Wwr+i2TBAgHO03gL4iU7Vp SZl8jfUHkTOKC18Yo25I+Pq4O1+QrwKYOFnyvBlyQSm5XXTfRuw2EoLfu741uWuS3fB0 9H/4fzJjQYDONv84kDz+hvC86mbv1uI6/+nEclT0M3P2XWEcJw5VQJGYmV9vB5CkrFRW 3UQQP03cJZ/W5zHsFk/76QzJm2VPuc3+BpDRQ+lptmRK/EnyDVCiZtldak6PpE9YL3VW y2Og== X-Gm-Message-State: AOAM532drBApYWV2dQ7Flmgbe1MKHJgJYj8TJ4VzZvAWXnP2bxPHtUvx gAAArA34da9kmQyJ+l+hXmJRGYdcV1f+VXcS9VBsOK4kig== X-Google-Smtp-Source: ABdhPJyhM8cSbDVH2rHyll03NHsohaFKg8WC/WMV7NxzFuNoN4zo+7Pd2nFDBxyTqsrAgxeAFcg3WBb39HkCJxACAOk= X-Received: by 2002:a05:622a:5ca:b0:2f3:ecfb:e062 with SMTP id d10-20020a05622a05ca00b002f3ecfbe062mr5664235qtb.624.1652286048144; Wed, 11 May 2022 09:20:48 -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: Cristian Cardoso Date: Wed, 11 May 2022 13:20:37 -0300 Message-ID: Subject: Re: Upgrade automation To: Alan Somers , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000f791b305debed2ca" X-Rspamd-Queue-Id: 4Kz0Wj14pTz3qXc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=aAnPTS3j; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of cristiancardoso11@gmail.com designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=cristiancardoso11@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82d:from]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000f791b305debed2ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I create this playbook: - name: Applying major version upgrade command: freebsd-update --not-running-from-cron upgrade -r {{ version }} become: yes tags: - freebsd-upgrade - name: Apply update installation command: freebsd-update --not-running-from-cron install become: yes tags: - freebsd-upgrade - name: Reboot after upgrade shell: "sleep 5 && reboot" async: 1 poll: 0 become: yes tags: - freebsd-upgrade - name: Waiting for machine reboot (max 600s) wait_for_connection: connect_timeout: 20 sleep: 20 delay: 60 timeout: 600 tags: - freebsd-upgrade - name: Running freebsd install userland command: freebsd-update --not-running-from-cron install become: yes tags: - freebsd-upgrade But since the command doesn't support -y no -not-running-from-cron for the upgrade command, I believe everything is stalling on this question and the playbook has no proceeding and it stays on this question below: The following components of FreeBSD do not seem to be installed: world/base-dbg world/lib32-dbg Does this look reasonable (y/n)? Em ter., 10 de mai. de 2022 =C3=A0s 13:38, Miroslav Lachman <000.fbsd@quip.= cz> escreveu: > On 10/05/2022 17:46, Alan Somers wrote: > > On Tue, May 10, 2022 at 9:08 AM Cristian Cardoso > > wrote: > >> > >> Hi > >> > >> I have some FreeBSD servers in my machine park and I would like to > perform the version upgrade in an automated way with ansible. > >> > >> In my example, I want to perform the upgrade from version 12.3 to 13, > it is possible to run the upgrade with the command below: > >> > >> freebsd-update --not-running-from-cron upgrade -r 12.2-RELEASE > >> > >> I ask this, because I don't know if it's the most correct way to > execute this. > >> > >> Grateful for any assistance. > > > > Yes, that's perfect. But there's another step too. You'll have to do: > > freebsd-update install > > And _this_ step isn't easy to perfectly automate, because etcupdate > > may ask for your input when it merges config files. If you know > > exactly which etc files you've modified, you can add them to > > IgnorePaths. That way etcupdate won't run interactively, it will > > simply throw away changes from upstream. > > Automation with etcupdate sounds very scary to me because etcupdate > breaks real life configuration files inplace. Mergemaster did it on > temporary copies. But if you let etcupdate to left something (after > merge conflict) in vital config file(s) wich will have syntax error on > next boot, then you are out. > It would be much better if etcupdate do not edit target file on merge > conflicts. > > Kind regards > Miroslav Lachman > --000000000000f791b305debed2ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I create this playbook:


-=
 name: Applying major version upgrade
   command: freebsd-update --not-running-from-cron upgrade -r {{ version }}
   become: yes
   tags:
   - freebsd-upgrade

- name: Apply update installation
   command: freebsd-update --not-running-from-cron install
   become: yes
   tags:
   - freebsd-upgrade

- name: Reboot after upgrade
   shell: "sleep 5 && reboot"
   async: 1
   poll: 0
   become: yes
   tags:
   - freebsd-upgrade


- name: Waiting for machine reboot (max 600s)
   wait_for_connection:
     connect_timeout: 20
     sleep: 20
     delay: 60
     timeout: 600
   tags:
   - freebsd-upgrade

- name: Running freebsd install userland
   command: freebsd-update --not-running-from-cron install
   become: yes
   tags:
   - freebsd-upgrade


=
But since the command doesn't support -y no -not-running-from-cron= for the upgrade command, I believe everything is stalling on this question= and the playbook has no proceeding and it stays on this question below:

The following components of FreeBSD do not seem to be installed:
world/base-dbg world/lib32-dbg

Does this look reasonable (y/n)?


=




Em ter., 10 de mai. de 2022 = =C3=A0s 13:38, Miroslav Lachman <000= .fbsd@quip.cz> escreveu:
On 10/05/2022 17:46, Alan Somers wrote:
> On Tue, May 10, 2022 at 9:08 AM Cristian Cardoso
> <= cristian.cardoso11@gmail.com> wrote:
>>
>> Hi
>>
>> I have some FreeBSD servers in my machine park and I would like to= perform the version upgrade in an automated way with ansible.
>>
>> In my example, I want to perform the upgrade from version 12.3 to = 13, it is possible to run the upgrade with the command below:
>>
>> freebsd-update --not-running-from-cron upgrade -r 12.2-RELEASE
>>
>> I ask this, because I don't know if it's the most correct = way to execute this.
>>
>> Grateful for any assistance.
>
> Yes, that's perfect.=C2=A0 But there's another step too.=C2=A0= You'll have to do:
> freebsd-update install
> And _this_ step isn't easy to perfectly automate, because etcupdat= e
> may ask for your input when it merges config files.=C2=A0 If you know<= br> > exactly which etc files you've modified, you can add them to
> IgnorePaths.=C2=A0 That way etcupdate won't run interactively, it = will
> simply throw away changes from upstream.

Automation with etcupdate sounds very scary to me because etcupdate
breaks real life configuration files inplace. Mergemaster did it on
temporary copies. But if you let etcupdate to left something (after
merge conflict) in vital config file(s) wich will have syntax error on
next boot, then you are out.
It would be much better if etcupdate do not edit target file on merge
conflicts.

Kind regards
Miroslav Lachman
--000000000000f791b305debed2ca-- From nobody Wed May 11 19:52:28 2022 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 7CD3F1ADA761 for ; Wed, 11 May 2022 19:52:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kz5DG3knCz4nCM for ; Wed, 11 May 2022 19:52:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652298758; bh=PB2bU10ctaceXksHz6ZKN3k5Cu5aWdX5y/8D7woUUps=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kAJFgj7Qf5N+yPq8V25uwZAyC9c3pW1VjzcBgr+3fYGsld/l/YOgXhRJn8BdwsHB5A/JXrGrlsWzUf2d0RzWWM4ieQxkI0YXvnUvtdS1Sn8TJ8TnnpAS2w0T3GcJ1CwPDHouPKR+WcS5VPqZ7HBwW5OViIoy5VnoMePpBrOcES3E407da6d9vBkRBOqhXRVjedlOci+UTK1YobZygC8q7ryIH5TXQ1AD/tf18ToaQ5qdk74XQGz2zw3PpsaN7byrl0+yIG/Ebac7wqi6q78Lbd6JjwmvUMsWhS//hGI4h/b9z5GWTTDhTK1aXnbY/Uf9uak7ockBw18vom7r5Wc/lw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652298758; bh=VQJiq2hGYSOBdhDFBS6NUECiIOIofdTEyzcjl47bCMA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IwQKaeHtnbcALeoCss1ZU91TM0WHRZxkTwbiDbbNRxRS+Dqbt2Br/wKor2nFMDSmhiJ74OFyIa/3JQ6cF+Lp2v3QtCsHKgfcXYHXt9IwOpv7L8u3dpDmHAK8SlwY6K79Lf3ZLydeONMMHSiM3YHRjQ49G8fNae0FL+cCL1am1oYFqCEPSiAFaQBKtdjfUIb9Vem2lPf+Wu0qgRIvpSwm7jXep77lUVNKNboSApEuY5Pv9DPakCiB4ruC9DlEHahU7R6I8j1PJp3d26BtMx+Yl77/OmvqOM+JWFYSrz4PwNBzhEK3K5NEbbs3fdEYIjdnJczpdpYNV/me4NiTt1P4tg== X-YMail-OSG: 1Z48tIwVM1l4LFot.TOLojW_qZi4YHJ0KNSa6LmWwji.Ouc.wCd1rKxjJPrKhrJ wRHNGbBRxaBmYIR8JloT9lzTOMJGe3DSEp1jr_5Pf1gzU3D_XZMwp87WwLvXeNfVkIOGhMX.NbKj xXvu768KuWQy4j2sW4c_CpTgMTuDhETSfAz.RmB.23N7ndbSBTKuTqezuPIDYyi2M6FDQZuvKZEX k0Tzd3kOV_6ErbozskhHPFbijwrPpN2Hnd3oJV8rCecJQo7SVMKekvQgIliPxNN8JcNi9A9rOdlE oiHzVkPz.9zhrF5Vm9WcZrFXIulDzKmCYezYgZkuiDNbMrg4z2.eyiK5xYkRx9w8gh8YwnttKFT8 M2k4YQxA4Usp6k.3yJKX1XsjeWX6sP7aWnBlkRvos1l_RunS8GgzR_ynKQ4_HUNijvKCXcwMFqqv 3ihzrgB2RX0ku..bsYc9Qm4_UHMe2i8LSURTpfvwheUomdCpWi_7IKl1jKeUVQDY714QGD.5kBo8 DQ12CU3GEvyUQtn6Egg2O0qjvWiO56Y42zoXhOQy172HijdoXoYZv4._dZWbrdD12Hje00G5tGM_ YDtg8P9hZLe9AjK.I9UcV5GYUIoRSW_HLttfRtT_lp2IfY6moodezZmGwsjy6T.szZriYic92plR _BKfsxgYl1EDKS9APpAkaNJO4nN1wjvEmd29XDVOCuJeFEL..QZoOAHg5ivhhaCcmn9pmmRUlvT3 6tUxmkPr8r89xRcMN5jbs28xuxERV.4ir_7V1f5dr_dN2BYp9iLD9hMLyHfKGF9zbWAjifeFEqG6 2OvjmF4.VRQSaSx1NpTkLS9_MLS9Qn4ORntwrdOkx2MILr_7BnHm1bb4ubnJL_gFmkGQogTmnb4d z_08hRbrpBw.npwpa2cBid4bbVkLl_xhEy74_v90phB7a7nvKjAnAqNebdzA0jhG_7ySD7m0iIIy STropbdkMTSTGOlG3AyVhadA1nw1nsNcxOTMuCQEIedMEQaysW37BoXNen0HXvl3ZPfy.SfETfJ5 1D7pP44sXBuDkZ3IzrROBxFA2zP1RKai3aYgfIgMTyQTbz5uZlEbITkuB22Ts3Scz29vmPAUxgJn ULTzensDw2G_xl7oeMtbu7QvM_Qf2B3NqmXG9Yuo4MceZCr9hbJHw7HacdQ536an2trN6YH6Q.m. 9cQ76MLi7jGp.JR8PsJCEAzSjifn1X0duGc1Mu0U7lBDvPvOrBfHigMrtunVB1DeeootknvNnbvJ 0JwuvKpGPwo4_6q5scDbM3at310vXomYCUynVmMOMAPZ5fM3b7BM53fYmGwpnorAP.oJg_vBRXwS ajKSJmtUxgoUplCpErqk6wq1gE8IgsDg6xZQq3vyjF8m5jug5JjI8EA3DPvw61o9c8qVLyow.rfH l9iz96RpMdfD.Jnd5ERK.0zmnfPyu31JghBOCK6Xww9nYzFFVxMeIPxGhC9_SUKdk0swsur7ztMC aOd_kd9M0M8Ro.syNEsGJwC3awJjN8zct74qrQbWVFFrwXNTLfi.p4OiDFsnV7ghwAFNL513RaNN 1H3oROXMRht06xqEvGRwl2BkwEHwVG6YG3WmK8JX_8qTwikYOjVCrfPqJJI2DJQBrCamVGlt8g8x Td91NCQy77.G6Wmh9B8GiCxHmP_cuiAslxQohgETKqOcOSai0oO86bZfzzYs2PwCYhWOcWzSgUm7 PZfHalvQfYPxaWFKeqP9dNMj9GMMG6mWIEERoldeJDK_JH1Nwcyh0zhvShGW6zbDO5jnifFgfLyV BELkU7d_0wzg3c6q9eRR8BE.g18Wjgc.S8Gydk_Pfsf8EIio0FLY8GfO4vZxAC1EL7fg2..gEUEA htM7bofVcR8u5qdo9YBi2299tHh1nvJm50GYdSrINXSZ25ZQ_IFku0U.D7ybrAJS9jnROK05EgUG oa3ddkGXbdK9fi4YQ02ZtPm8uWEeWdx7Z4Ig1AGUfxVzsdLQRXdCXM1ClrNCpFL5ZjvEzjvykkYT 1OB4GteUpiehmL6q5VfZFhkUhgLVykhWetOXJKyeS976nmq00TePZ.2xKBpTv21Pp79dX46GwblR abQymm2bNGE3KDSmKi0mJB.qb9q91itZ38HNryeUFs8LditIyZ1M7hkDSwyfGQioy.G_QEhPy80T d5JtE.aDsRavSgIR7FQxkh2cI9zQLml.FdCOpHPxqMvBmODjlHFebC3pzskJxs1yWBcF554IHomB utpBxWtUONJj5LDbQO4oereeNnpZPF9ki.cMnRsIkPH4NNS2phkPxdVWU39AkIIhIHYqN08ETv75 DT6Pmt5yoWmpR9GltanbQgNhR X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 11 May 2022 19:52:38 +0000 Received: by hermes--canary-production-bf1-579c78cbb7-nckdv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d4f4d215f941b334ec004a9e148c41a5; Wed, 11 May 2022 19:52:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? From: Mark Millard In-Reply-To: Date: Wed, 11 May 2022 12:52:28 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <0E44A609-A040-4801-B3FA-E0B410F0C3D3@yahoo.com> References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> <446d5913-a8c2-7dd0-860b-792fa9fe7c5b@nomadlogic.org> <33B740AA-A431-49CB-9F27-50B8C49734A2@yahoo.com> <3C5C183F-1471-4139-A53C-0B3815CFC25E@yahoo.com> <75C02C8C-6A5E-4E19-AC7D-B5DB704E8F16@transactionware.com> To: Jan Mikkelsen , Pete Wright X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Kz5DG3knCz4nCM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kAJFgj7Q; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.83 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.73)[-0.735]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.59)[-0.594]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-May-10, at 20:31, Mark Millard wrote: > On 2022-May-10, at 17:49, Mark Millard wrote: >=20 >> On 2022-May-10, at 11:49, Mark Millard wrote: >>=20 >>> On 2022-May-10, at 08:47, Jan Mikkelsen = wrote: >>>=20 >>>> On 10 May 2022, at 10:01, Mark Millard wrote: >>>>>=20 >>>>> On 2022-Apr-29, at 13:57, Mark Millard wrote: >>>>>=20 >>>>>> On 2022-Apr-29, at 13:41, Pete Wright = wrote: >>>>>>>=20 >>>>>>>> . . . >>>>>>>=20 >>>>>>> d'oh - went out for lunch and workstation locked up. i *knew* i = shouldn't have said anything lol. >>>>>>=20 >>>>>> Any interesting console messages ( or dmesg -a or = /var/log/messages )? >>>>>>=20 >>>>>=20 >>>>> I've been doing some testing of a patch by tijl at FreeBSD.org >>>>> and have reproduced both hang-ups (ZFS/ARC context) and kills >>>>> (UFS/noARC and ZFS/ARC) for "was killed: failed to reclaim >>>>> memory", both with and without the patch. This is with only a >>>>> tiny fraction of the swap partition(s) enabled being put to >>>>> use. So far, the testing was deliberately with >>>>> vm.pageout_oom_seq=3D12 (the default value). My testing has been >>>>> with main [so: 14]. >>>>>=20 >>>>> But I also learned how to avoid the hang-ups that I got --but >>>>> it costs making kills more likely/quicker, other things being >>>>> equal. >>>>>=20 >>>>> I discovered that the hang-ups that I got were from all the >>>>> processes that I interact with the system via ending up with >>>>> the process's kernel threads swapped out and were not being >>>>> swapped in. (including sshd, so no new ssh connections). In >>>>> some contexts I only had escaping into the kernel debugger >>>>> available, not even ^T would work. Other times ^T did work. >>>>>=20 >>>>> So, when I'm willing to risk kills in order to maintain >>>>> the ability to interact normally, I now use in >>>>> /etc/sysctl.conf : >>>>>=20 >>>>> vm.swap_enabled=3D0 >>>>=20 >>>> I have been looking at an OOM related issue. Ignoring the actual = leak, the problem leads to a process being killed because the system was = out of memory. This is fine. After that, however, the system console was = black with a single block cursor and the console keyboard was = unresponsive. Caps lock and num lock didn=E2=80=99t toggle their lights = when pressed. >>>>=20 >>>> Using an ssh session, the system looked fine. USB events for the = keyboard being disconnected and reconnected appeared but the keyboard = stayed unresponsive. >>>>=20 >>>> Setting vm.swap_enabled=3D0, as you did above, resolved this = problem. After the process was killed a perfectly normal console = returned. >>>>=20 >>>> The interesting thing is that this test system is configured with = no swap space. >>>>=20 >>>> This is on 13.1-RC5. >>>>=20 >>>>> This disables swapping out of process kernel stacks. It >>>>> is just with that option removedfor gaining free RAM, there >>>>> fewer options tried before a kill is initiated. It is not a >>>>> loader-time tunable but is writable, thus the >>>>> /etc/sysctl.conf placement. >>>>=20 >>>> Is that really what it does? =46rom a quick look at the code in = vm/vm_swapout.c, it seems little more complex. >>>=20 >>> I was going by its description: >>>=20 >>> # sysctl -d vm.swap_enabled >>> vm.swap_enabled: Enable entire process swapout >>>=20 >>> Based on the below, it appears that the description >>> presumes vm.swap_idle_enabled=3D=3D0 (the default). In >>> my context vm.swap_idle_enabled=3D=3D0 . Looks like I >>> should also list: >>>=20 >>> vm.swap_idle_enabled=3D0 >>>=20 >>> in my /etc/sysctl.conf with a reminder comment that the >>> pair of =3D0's are required for avoiding the observed >>> hang-ups. >>>=20 >>>=20 >>> The analysis goes like . . . >>>=20 >>> I see in the code that vm.swap_enabled !=3D0 causes >>> VM_SWAP_NORMAL : >>>=20 >>> void >>> vm_swapout_run(void) >>> { >>>=20 >>> if (vm_swap_enabled) >>> vm_req_vmdaemon(VM_SWAP_NORMAL); >>> } >>>=20 >>> and that in turn leads to vm_daemon to: >>>=20 >>> if (swapout_flags !=3D 0) { >>> /* >>> * Drain the per-CPU page queue batches as a = deadlock >>> * avoidance measure. >>> */ >>> if ((swapout_flags & VM_SWAP_NORMAL) !=3D 0) >>> vm_page_pqbatch_drain(); >>> swapout_procs(swapout_flags); >>> } >>>=20 >>> Note: vm.swap_idle_enabled=3D=3D0 && vm.swap_enabled=3D=3D0 ends >>> up with swapout_flags=3D=3D0. vm.swap_idle. . . defaults seem >>> to be (in my context): >>>=20 >>> # sysctl -a | grep swap_idle >>> vm.swap_idle_threshold2: 10 >>> vm.swap_idle_threshold1: 2 >>> vm.swap_idle_enabled: 0 >>>=20 >>> For reference: >>>=20 >>> /* >>> * Idle process swapout -- run once per second when pagedaemons are >>> * reclaiming pages. >>> */ >>> void >>> vm_swapout_run_idle(void) >>> { >>> static long lsec; >>>=20 >>> if (!vm_swap_idle_enabled || time_second =3D=3D lsec) >>> return; >>> vm_req_vmdaemon(VM_SWAP_IDLE); >>> lsec =3D time_second; >>> } >>>=20 >>> [So vm.swap_idle_enabled=3D=3D0 avoids VM_SWAP_IDLE status.] >>>=20 >>> static void >>> vm_req_vmdaemon(int req) >>> { >>> static int lastrun =3D 0; >>>=20 >>> mtx_lock(&vm_daemon_mtx); >>> vm_pageout_req_swapout |=3D req; >>> if ((ticks > (lastrun + hz)) || (ticks < lastrun)) { >>> wakeup(&vm_daemon_needed); >>> lastrun =3D ticks; >>> } >>> mtx_unlock(&vm_daemon_mtx); >>> } >>>=20 >>> [So VM_SWAP_IDLE and VM_SWAP_NORMAL are independent bits >>> in vm_pageout_req_swapout.] >>>=20 >>> vm_deamon does: >>>=20 >>> mtx_lock(&vm_daemon_mtx); >>> msleep(&vm_daemon_needed, &vm_daemon_mtx, PPAUSE, = "psleep", >>> vm_daemon_timeout); >>> swapout_flags =3D vm_pageout_req_swapout; >>> vm_pageout_req_swapout =3D 0; >>> mtx_unlock(&vm_daemon_mtx); >>>=20 >>> So vm_pageout_req_swapout is regenerated after thata >>> each time. >>>=20 >>> I'll not show the code for vm.swap_idle_enabled!=3D0 . >>>=20 >>=20 >> Well, with continued experiments I got an example of >> a hangup for which looking via the db> prompt did not >> show any swapping out of process kernel stacks >> ( vm.swap_enabled=3D0 was the context, so expected ). >> The environment was ZFS (so with ARC). >>=20 >> But this was testing with vm.pageout_oom_seq=3D120 instead >> of the default vm.pageout_oom_seq=3D12 . It may be that >> let sit long enough things would have unhung (external >> perspective). >>=20 >> It is part of what I'm experimenting with so we will see. >>=20 >=20 > Looks like I might have overreacted, in that for my > current tests there can be brief periods of delayed > response, but things respond in a little bit. > Definately not like the hang-ups I was getting with > vm.swap_enabled=3D1 . >=20 The following is based on using vm.pageout_oom_seq=3D120 which greatly delays kills. (I've never waited long enough.) vm.pageout_oom_seq=3D12 tends to get a kill fairly quickly, making the below hard to observe. More testing has shown it can hang up with use of vm.swap_enabled=3D0 with vm.swap_idle_enabled=3D0 --but the details I've observed suggest a livelock rather than a deadlock. It appears that the likes of (db> use output extractions): 1171 1168 1168 0 R+ CPU 2 stress 1170 1168 1168 0 R+ CPU 0 stress and: 18 0 0 0 RL (threaded) [pagedaemon] 100120 Run CPU 1 [dom0] 100132 D launds 0xffff000000f1dc44 [laundry: = dom0] 100133 D umarcl 0xffff0000007d8424 [uma] stay busy using power like when I have just those significantly active and the system is not hung-up. (30.6W..30.8W or so range, where idle is more like 26W and more general activity being involved ends up with the power jumping around over a wider range, for example.) I have observed non-hung-up tests where the 2 stress processes using the memory were getting around 99% in top and and [pagedaemon{dom0}] was getting around 90% but a grep was getting more like 0.04%. This looks like a near-livelock and it was what inspired looking if more suggested a livelock for a hang-up. Looking via db> use always has looked like the above. (Sometimes I've used 3 memory-using stress processes but now usually 2, leaving one CPU typically being idle.) That in turn lead to monitoring the power, ending up as mentioned above. I have also observed hang-up-like cases where the top that had been running would sometimes get individual screen updates many minutes apart. With the power usage pattern it again seems like a (near) livelock. Relative to avoiding hang-ups, so far it seems that use of vm.swap_enabled=3D0 with vm.swap_idle_enabled=3D0 makes hang-ups less likely/less frequent/harder to produce examples of. But is no guarantee of lack of a hang-up. Its does change the cause of the hang-up (in that it avoids processes with kernel stacks swapped out being involved). What I do to avoid rebooting for a hang-up I'd done with is to kill the memory using stress processes via db> use and then c out of the kernel debugger (i.e., continue). So far the system has always returned to normal in response. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed May 11 21:37:20 2022 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 9A6051AC4DB1 for ; Wed, 11 May 2022 21:38:43 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 4Kz7ZV5rdGz3GDl for ; Wed, 11 May 2022 21:38:42 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8FBF95C01AB; Wed, 11 May 2022 17:38:36 -0400 (EDT) Received: from imap44 ([10.202.2.94]) by compute2.internal (MEProxy); Wed, 11 May 2022 17:38:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1652305116; x=1652391516; bh=NlieQP29XW JOw1EsLIhCKEgLw/yrVRrdWL9pvuQ5qc4=; b=Hz4CWBZ+76vmZD10eORVqeLaXl QWgjVvgQtH48YSNfkfYGJynZNVBOHVLZoO/9y8GOvFiQpnBFJw6vPeu50zg9Hkac WHwcUAZUijxnbtq/UARO9Ui3rwmtPhtcuK1xMFyGg6Go+dXyyiBZX3xmJy2b5GXm g4BMi24yE1hgNqan533WPsUe+nsAQ5QatcmMdJsfp3a+uV/1fxZGkHvUKDkzGS3L uMBldmimpKnAQoT5DaOnqd/elQiXDFPtfJ90Cvu8O7Gh9VHaY2k1LgVUo/JZUAzu vyVWY3BpUh4KN9GicMjBYGflMdk2D72VGuW4jMDZWrAZVfn81lU2zplfW7hw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1652305116; x= 1652391516; bh=NlieQP29XWJOw1EsLIhCKEgLw/yrVRrdWL9pvuQ5qc4=; b=x 5L9IzyTnC88xq3Bo0qfrpveLqoXvZY2OiJYBrcfhCKGTRESL5hCnrVBna2LQb6b3 wIEKxr8wTblTBlBy9owuaYBXipbbFU2EfUU+j0fijC2Co4qZ2989KS0g+WMN4H60 ds28RTwesQecm5B13W/IxY0gDtiRWa62PO4P1Mp1MVWSZSZreGNoEiR48fH95xje 8hF347W2aTnXEXLj22itmSW6OpBrKcGmbptCss/cyDUA5QO4ePphVYvMX5e7LuVq SfOMNulFvpnp06FtkoUTV3ZwRsEbXIeXw1+2/EJRmhD5/udNYW0ET4jXXfZj9SAO QMG7T/SREAM0vPaGlapWQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrgeeigddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdffrghvvgcuvehothhtlhgvhhhusggvrhdfuceouggthhes shhkuhhnkhifvghrkhhsrdgrtheqnecuggftrfgrthhtvghrnhepkefffedvfeetkeffge fgffdvfeeugfeuhffhhfdufedvtefgieelueejffehvdejnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepuggthhesshhkuhhnkhifvghrkhhsrd grth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5857036A005D; Wed, 11 May 2022 17:38:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 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 Message-Id: <5fff8840-6f1e-4edd-8ddf-2728227c8818@www.fastmail.com> In-Reply-To: References: <481e0739-bdc4-4ce6-a856-a80cf5294d03@www.fastmail.com> Date: Wed, 11 May 2022 21:37:20 +0000 From: "Dave Cottlehuber" To: freebsd-current , "Michael Schuster" Subject: Re: FreeBSD, boot environments and /dev Content-Type: text/plain X-Rspamd-Queue-Id: 4Kz7ZV5rdGz3GDl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm2 header.b=Hz4CWBZ+; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="x 5L9Izy"; dmarc=none; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 66.111.4.28 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-3.52 / 15.00]; XM_UA_NO_VERSION(0.01)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.28:from]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.93)[-0.933]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm2,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[dch]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[skunkwerks.at]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 11 May 2022, at 14:58, Michael Schuster wrote: > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only > regular files and empty directories). Booting into that BE didn't work > either, I got errors about missing "/dev/" files (can't recall the > exact names). > > What do you guys (plural ;-)) think? this works for me: # zfs create -o canmount=noauto -o mountpoint=/ zroot/ROOT/vanilla # bectl mount vanilla /mnt # cd /some/path/to/sets/ # tar xzpf ./kernel.txz -C /mnt/ # tar xzpf ./base.txz -C /mnt/ # tzsetup -C /mnt UTC # pwd_mkdb -p -d /mnt/etc /mnt/etc/master.passwd # ln -s /usr/home /mnt/home ### copy in & amend /etc/fstab /etc/rc.conf /boot/loader.conf as required # bectl activate -t vanilla # reboot try that and let us know what, if any, errors you get? A+ Dave From nobody Wed May 11 21:47:03 2022 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 B0B4F1AC78DA for ; Wed, 11 May 2022 21:47:24 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kz7mX4LJ6z3Hx5; Wed, 11 May 2022 21:47:24 +0000 (UTC) (envelope-from dch@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1652305644; 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=ccyflKKpyuct2DPxYC0DJKFBSk2KCx/ji6VMvE2R05w=; b=VK9RZeDtAGrg5IlN1RcwLFrZE0DFC7LPBJxfwqUUesTgWcm2wNm2aF0daIFO7PWHc/pjbm L/57PYw+Gx9vKDZE0xjP9SbGJ9zbEXYg9FsOpt/YIRbWhM7Dmh2xiSxnWohPDE479VMv3G rEwkYxF12+3ixQk7cXpVUJpGUf0kFCptp6EL0WcnAZRfEpyKtqtkTTI1K6Cr8DkgPwLYkU 8mLPHkDeZTkkmqQQKdrvLxBJX2C7mSk/Cx86p0o69FSDE7OiC4epBalPENjCSOFuH2jsHB qJ8fTrdfglrgkQ41HQrnQFnKDdOQ82mCFhONnmKjkRNlIj2TVmagJ042vu6KlA== Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: dch/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 6D99A31F2; Wed, 11 May 2022 21:47:24 +0000 (UTC) (envelope-from dch@FreeBSD.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 3BEBD27C0060; Wed, 11 May 2022 17:47:24 -0400 (EDT) Received: from imap44 ([10.202.2.94]) by compute2.internal (MEProxy); Wed, 11 May 2022 17:47:24 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrgeeigddtvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvfevufgtgfesth hqredtreerjeenucfhrhhomhepfdffrghvvgcuvehothhtlhgvhhhusggvrhdfuceouggt hheshfhrvggvuefuffdrohhrgheqnecuggftrfgrthhtvghrnheptdfgffekjeejjeejhf elhffgfeelheduuddtveeuffdvgfekgffhueevhfeuffelnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepuggthhdomhgvshhmthhprghuthhhph gvrhhsohhnrghlihhthidquddvgeeluddtfeeguddquddvudefuddujeejqdgutghhpeep hfhrvggvuefuffdrohhrghesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 09D0036A005D; Wed, 11 May 2022 17:47:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 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 Message-Id: <4d3106ce-8f7c-4542-9cfa-996a09b0fa7d@www.fastmail.com> In-Reply-To: References: Date: Wed, 11 May 2022 21:47:03 +0000 From: "Dave Cottlehuber" To: cristian.cardoso11@gmail.com Cc: freebsd-current@freebsd.org Subject: Re: Upgrade automation Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1652305644; 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=ccyflKKpyuct2DPxYC0DJKFBSk2KCx/ji6VMvE2R05w=; b=g2WlcVsExwOUJO0m/FXvg9VYUYfZRHhTXevCO214QUqZzfLyZA3mU+0oiz5uOoLWBdDuCK 0AmbkP0QwEsoKZ9T75y3BdtuhW0P6a1Ff5PZG8C4JvaNHC9EEXB7guUSgbN5Shx6qgXgZ5 dpAWOWhqL7mVu8OQBVRv1Md7I0v8qVilx5ZDC3v10A/gdp4PkNhx+v0FXQgKhALKj/y3To 7tMpJMsIQ4V92Yqy/C/WVzUv0ysOhJOcAWIFzR437j2fHIOMbOGIys7nXUf6ZE/Y/0ZhuT C99g8d2ShjVe6wGQpdIroGU+caCn0UoGMbUXKG604eFdDlssKM7fVyAboT2cUQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1652305644; a=rsa-sha256; cv=none; b=aJruDH17/kcSJePX/wiXWdw9N74Ai2KCaegWQmc0cbgQEqyFYv7fevlGxcQbpm7C65e1F6 9Volceo7llrENhkJAJaXWsARbZ7JvsC+asjRIRw0qxiZTGirWNCxCfh75Uuo1533gMliq+ E0rt5oAF571B20XXeBBsr1+J9+rJ+M9om0Q6NdYWgm581ZXbNavX6U1QvlOsEDpxGMU9Jx 1RQKdaNBr88Ketb6bTiRkhLfXoBfFx9FqtwL/xWZW36Z9YBabnv9YrlvHac0Au4ZgpTTHa K6YEeTExOAETVrKoTHad+jC5dAVxfp2P+UG2G09BHi1xlq9gp9DITG0qnqYlPQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Wed, 11 May 2022, at 16:20, Cristian Cardoso wrote: > > But since the command doesn't support -y no -not-running-from-cron for=20 > the upgrade command, I believe everything is stalling on this question=20 > and the playbook has no proceeding and it stays on this question below: > > `The following components of FreeBSD do not seem to be installed: > world/base-dbg world/lib32-dbg > > Does this look reasonable (y/n)?` Use `StrictComponents yes` in /etc/freebsd-update.conf to force that. And obviously you'll have to set your `Components ...` correctly per host. Thanks for sharing the playbook snippet. A+ Dave =E2=80=94 O for a muse of fire, that would ascend the brightest heaven of inventio= n! From nobody Thu May 12 07:12:59 2022 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 299971AE38BB for ; Thu, 12 May 2022 07:13:17 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KzNKS3WpRz3D0D for ; Thu, 12 May 2022 07:13:16 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd33.google.com with SMTP id z26so4385322iot.8 for ; Thu, 12 May 2022 00:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c8l8MfRRpkQi3FUul1be/qcLyYMoKOHAE6Za6ceXvcQ=; b=ctPNIDO5bH3UElLiGZ+XnYV3t2muIuBN911xdGSHfeA6YLOQdxdn4qTTLSFQyNQSob PdnvifOuRof91P2csETbrq5mIDK782lSvj8thKUbZbCz0MuNjivzY4LH1nEPxGPqu0AT 1d5qCBW7ctwcwuJah3Xfc59o1a1RmigSWU9Yj0121bjFujFGfq7QJtxXDHL0ofFqEVz1 6ZsiHoWjXsjccxqj4/jBFDxP70GqtJjfyM+h7q2RsbyigDZuAPrS5aUMgG+RXzmsBt+D wrdPD2BbzouVWZHaCtfHZwHQ78WYTFQmc9SDPwCOnq5gYx77B1fGKX4bjZGdyFkjgAej AV1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c8l8MfRRpkQi3FUul1be/qcLyYMoKOHAE6Za6ceXvcQ=; b=ToKJern2uresxsnMjRibhWohtxp+ElbrpgT1BtRT8+1Rr9t+NoL655n6q9fuWmykNO yz4YkkFJBRgQkKH3JiwT6Y0GKfDyhYmKXjiQiJbhDne1X/3Y1kjZDxLG2BZr7NoKt2Tk MLLaBblG89QBW+D4Zbwmm2ydRnov3JurRZRy0kmLMNkb7Lm/y20PHWzrvUxWhURMhbE5 W8/DSKlMcs7nX8vTIgjX4S5444Nlx0va3oFxZ+V2F1b6kfDN3fnT7mJKptKHvdHnrVNH V/O/nWmtZj795p3TL9XsnylqdJpo1iU3gH6B54oFCHsWF+T9YCXDbNKdB9X1L874pOJ5 yQrA== X-Gm-Message-State: AOAM532wVWd2JuWfM8hrFLka5bt+faBNgXaQ19r6/3HSeG/edv0v2vdh YSYiF+ky1R8eWvGFTu1TNd10VDzXcyvK7EDktGRMTJTUx1iJuTM8 X-Google-Smtp-Source: ABdhPJw/M2dXs6fXe5YMssndX3AQJIHUrKFLsgbl2Y9/aSXzLG8GTAebrYyLze6CcKsstXGZ6JECPF+mLaThcGAbsbw= X-Received: by 2002:a6b:c808:0:b0:657:c3ee:623c with SMTP id y8-20020a6bc808000000b00657c3ee623cmr12586975iof.48.1652339590041; Thu, 12 May 2022 00:13:10 -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: <481e0739-bdc4-4ce6-a856-a80cf5294d03@www.fastmail.com> <5fff8840-6f1e-4edd-8ddf-2728227c8818@www.fastmail.com> In-Reply-To: <5fff8840-6f1e-4edd-8ddf-2728227c8818@www.fastmail.com> From: Michael Schuster Date: Thu, 12 May 2022 09:12:59 +0200 Message-ID: Subject: Re: FreeBSD, boot environments and /dev To: Dave Cottlehuber Cc: freebsd-current Content-Type: multipart/alternative; boundary="0000000000005017b305decb4a7f" X-Rspamd-Queue-Id: 4KzNKS3WpRz3D0D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ctPNIDO5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::d33 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d33:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000005017b305decb4a7f Content-Type: text/plain; charset="UTF-8" On Wed, May 11, 2022 at 11:38 PM Dave Cottlehuber wrote: > On Wed, 11 May 2022, at 14:58, Michael Schuster wrote: > > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only > > regular files and empty directories). Booting into that BE didn't work > > either, I got errors about missing "/dev/" files (can't recall the > > exact names). > > > > What do you guys (plural ;-)) think? > Hi Dave, thx for your perseverance :-) I have (at least) one question for you before I attempt this: > this works for me: > > # zfs create -o canmount=noauto -o mountpoint=/ zroot/ROOT/vanilla > # bectl mount vanilla /mnt > # cd /some/path/to/sets/ > # tar xzpf ./kernel.txz -C /mnt/ > # tar xzpf ./base.txz -C /mnt/ > showing my ignorance here: where do I get these .txz files? # tzsetup -C /mnt UTC > # pwd_mkdb -p -d /mnt/etc /mnt/etc/master.passwd > # ln -s /usr/home /mnt/home > ### copy in & amend /etc/fstab /etc/rc.conf /boot/loader.conf as required > should devfs be in /etc/fstab? in my current BE, it isn't ... if so: do you have an example of such a line? In the instances I looked up, I wasn't quite able to make it work (but perhaps that's a dead end anyway). # bectl activate -t vanilla > does that ("activate -t") work on UEFI systems? The last time I used it (at least a year ago), it wasn't. Thx Michael # reboot > > try that and let us know what, if any, errors you get? > > A+ > Dave > -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' --0000000000005017b305decb4a7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May = 11, 2022 at 11:38 PM Dave Cottlehuber <dch@skunkwerks.at> wrote:
On Wed, 11 May 2022, at 14:58, Michael Schuster wrote:=
> I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only<= br> > regular files and empty directories). Booting into that BE didn't = work
> either, I got errors about missing "/dev/" files (can't = recall the
> exact names).
>
> What do you guys (plural ;-)) think?

Hi Dave,
thx for your perseverance= :-)

I have (at leas= t) one question for you before I attempt this:
this works for me:

# zfs create -o canmount=3Dnoauto -o mountpoint=3D/ zroot/ROOT/vanilla
# bectl mount vanilla /mnt
# cd /some/path/to/sets/
# tar xzpf ./kernel.txz -C /mnt/
# tar xzpf ./base.txz -C /mnt/

showing my ignorance here: where do I get these .txz files?

# tzsetup -C /mnt UTC
# pwd_mkdb -p -d /mnt/etc /mnt/etc/master.passwd
# ln -s /usr/home /mnt/home
### copy in & amend /etc/fstab /etc/rc.conf /boot/loader.conf as requir= ed

should devfs be in /et= c/fstab? in my current BE, it isn't ...=C2=A0
i= f so: do you have an example of such a line? In the instances I looked up, = I wasn't quite able to make it work (but perhaps that's a dead end = anyway).

# bectl activate -t vanilla

does that ("activate -t") work on UEFI systems? The last time = I used it (at least a year ago), it wasn't.
Thx
Michael

# reboot

try that and let us know what, if any, errors you get?

A+
Dave


--
recursion, n: see 'rec= ursion'
--0000000000005017b305decb4a7f-- From nobody Thu May 12 07:20:40 2022 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 C3A0F1AE5278 for ; Thu, 12 May 2022 07:21:10 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 4KzNVY59kmz3FPM for ; Thu, 12 May 2022 07:21:09 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9D43F5C010D; Thu, 12 May 2022 03:21:03 -0400 (EDT) Received: from imap44 ([10.202.2.94]) by compute2.internal (MEProxy); Thu, 12 May 2022 03:21:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1652340063; x=1652426463; bh=hf FO2nix1k35KWRiIq4I7ereP6F7PP+c2vdyeIJvx2Q=; b=rzAKF3v5UsFtkotrKv cVVBZn7MWFqnY5NP7xDxpCXci5Ua8huLGsUnbU5K4gH/9D/aDRq2WEsyFxA8Gggn h49SNGBllrJXwbDWRcwnSwjcTfOOYMpzUKZB2tQzvbpzz+lfZYXMnS62IlTFNLgv G0NIhztDLtca+gjpqufQUiNP1BptCG36mR9F8xiYPPmPUkE07vksmEWkcDC5Nvpz zFH7s75p84wdbpcBbUOTig9LVb4VPQbEcEDP35CyLLj0aICPIvYTlAKjD0cnB1Uz iSUtiLXftYkMwf9GrMMBAAPv7DFrVho8h8BWbwzSIoh577jB9E2D8VfhNjzTBy68 1N6Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1652340063; x= 1652426463; bh=hfFO2nix1k35KWRiIq4I7ereP6F7PP+c2vdyeIJvx2Q=; b=V k00zOmRY7m40doyBbqAIrkx3dpdOZOn0erfkFl4CJ3bNf1P9aeRkzp5Ea50tnCPR sQsJeCEtze1WAlbBgMcyJpgxs0sF4nRAJDlYR9zl7Ht175yZqPzcfR5jedJxSDSV H6Uvb6Zt+05O/y/kT+x3w2ZBFC2rZdyjXxHK0qzN4glGfkon/XowVfRwtX9HG3UL Lux6bo5HfVXogVL8QQ44/WSc4uV9ZTMtb6T19rQDj0QsPdJ//jhl89PCtrqpO9+Y MBTRAunaZWPC78OPAFA/eQQtwA+EzCyQAkewjBb9jbVhgKWyIw6rGGtZvcYjnY0n MyqeCC010E22ZihN6jF/w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrgeeigdduudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvvefutgesth dtredtreertdenucfhrhhomhepfdffrghvvgcuvehothhtlhgvhhhusggvrhdfuceouggt hhesshhkuhhnkhifvghrkhhsrdgrtheqnecuggftrfgrthhtvghrnhepkeeukeefjeekge dufefgvedutddufeevheekudfghfeugfdvgedtveetudehudehnecuffhomhgrihhnpehf rhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepuggthhesshhkuhhnkhifvghrkhhsrdgrth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5039836A005D; Thu, 12 May 2022 03:21:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 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 Message-Id: <3bcf856c-c048-4b4d-adfc-c6ba352e3b20@www.fastmail.com> In-Reply-To: References: <481e0739-bdc4-4ce6-a856-a80cf5294d03@www.fastmail.com> <5fff8840-6f1e-4edd-8ddf-2728227c8818@www.fastmail.com> Date: Thu, 12 May 2022 07:20:40 +0000 From: "Dave Cottlehuber" To: "Michael Schuster" Cc: freebsd-current Subject: Re: FreeBSD, boot environments and /dev Content-Type: text/plain X-Rspamd-Queue-Id: 4KzNVY59kmz3FPM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm2 header.b=rzAKF3v5; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="V k00zOm"; dmarc=none; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 66.111.4.29 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-3.24 / 15.00]; XM_UA_NO_VERSION(0.01)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.65)[-0.651]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm2,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[dch]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[skunkwerks.at]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 12 May 2022, at 07:12, Michael Schuster wrote: > On Wed, May 11, 2022 at 11:38 PM Dave Cottlehuber wrote: >> On Wed, 11 May 2022, at 14:58, Michael Schuster wrote: >> > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only >> > regular files and empty directories). Booting into that BE didn't work >> > either, I got errors about missing "/dev/" files (can't recall the >> > exact names). >> > >> > What do you guys (plural ;-)) think? > > Hi Dave, > thx for your perseverance :-) > > I have (at least) one question for you before I attempt this: > where do I get these .txz files? https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/ https://download.freebsd.org/ftp/releases/amd64/amd64/13.1-RC6/ > should devfs be in /etc/fstab? in my current BE, it isn't ... this is the bare minimum I used. NB my partitions have artisanal GPT labels, yours will probably be different. # Device Mountpoint FStype Options Dump Pass# #/dev/gpt/swap0 none swap sw 0 0 /dev/gpt/efiboot /boot/efi msdosfs rw,late,longnames 0 0 tmpfs /tmp tmpfs rw,mode=01777,size=120g 0 0 thats all I needed to boot to userland & login. I'm reasonably sure that, assuming you have a default zfs install, you'd not need anything in /etc/fstab to boot. > if so: do you have an example of such a line? In the instances I looked > up, I wasn't quite able to make it work (but perhaps that's a dead end > anyway). > >> # bectl activate -t vanilla > > does that ("activate -t") work on UEFI systems? The last time I used it > (at least a year ago), it wasn't. Yes it does here. failing that just use `bectl activate`. The -t is a very nice addition. Well, we're definitely on the FreeBSD-current email list here, so it's definitely in CURRENT, and 13.1 RC. A+ Dave From nobody Thu May 12 13:08:29 2022 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 5D1E61ADBEDA for ; Thu, 12 May 2022 13:08:47 +0000 (UTC) (envelope-from jwmaag@gmail.com) Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KzXCf2fj2z4Z8h for ; Thu, 12 May 2022 13:08:46 +0000 (UTC) (envelope-from jwmaag@gmail.com) Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-2f7d621d1caso55394507b3.11 for ; Thu, 12 May 2022 06:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=utykp2US9tcTmgLp+xOWWhgwrUGU6wZPKDe/MyCelNk=; b=pbVKhBDsbKr1dBTX3ze572OeHfMnrfO1lhhFxaw5jXVTVuBQ/kpnPH8F/3AOpF1go9 I9nzSsXodqgQ3K+ZfT/JGmG1GhQwSjJ5YVS6ruJlhse2uvxcHR/ooabMDpnckRzHtdL+ pTrfITXYSfz5Go5vG5zWn/0VK0V2+pxch0ZWBxEEJ6Gsu/6r346nMOorHWhDPaG03oxJ ucpUhdxvmxFNtvz7aSReFyVCXg0IHOPiU6P/vLhElYpvAY9r5R9jFtG0CnzSzW7/4II+ pp4StAUEb2rAkeChJCNPDQGxY2njAJEDMgrhtE5e3L8Lwha2/wKO2WbE2E6QTd46VTPB DI+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=utykp2US9tcTmgLp+xOWWhgwrUGU6wZPKDe/MyCelNk=; b=6Vu+4GoSxjgdKNL8EoS2ic1eGtTep8c2viroIRSfY3On8LkfafT3sTsdk6xahi0lNR iBafVn70dlrDulDBIS7AuQVNLyDtPcpA9gig3RDg1+rf/5EPoVh37/42Z6ZS2moGJI8X zApNb/Of3cSCdqJSKm9M8eFvJbQGPZICDrkud2CLIWOf+o78LOfhVv6mI7ZazU5iWaXG gAlVR4TzTeW9x4DdOE0tjsDAPCXW2Z4t8S8QiPNNnniE+D2m+Z9uFuM+3JoUfbfYHLxj SudnAQ0o3CQJ7Lr94S3rIHlmnZU5vsaCfayLa4UgkaP/FyKUFPW84ZzaQwh2TC2/BKA/ yz4Q== X-Gm-Message-State: AOAM533aNnnPNLOWfxmy4WSeo/mnwz36FDpxGWzXOFvjK83BDeAMl90T a+dvxiyYvCtpKFuAA8L70dPgpZTG58F6/PViWs8= X-Google-Smtp-Source: ABdhPJwBD8Fcf1zlLH28dFQzhc1J2bv/8DFag8S06LGu1OKR4zaBxizfN/4IhuUAbW7kptqXeuijRU7pgZ7aVo5H/Lc= X-Received: by 2002:a81:4b8a:0:b0:2fb:2b30:ea30 with SMTP id y132-20020a814b8a000000b002fb2b30ea30mr30137104ywa.294.1652360920149; Thu, 12 May 2022 06:08: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: <481e0739-bdc4-4ce6-a856-a80cf5294d03@www.fastmail.com> In-Reply-To: From: Wes Maag Date: Thu, 12 May 2022 08:08:29 -0500 Message-ID: Subject: Re: FreeBSD, boot environments and /dev To: Michael Schuster Cc: Dave Cottlehuber , freebsd-current Content-Type: multipart/alternative; boundary="000000000000afb22c05ded04163" X-Rspamd-Queue-Id: 4KzXCf2fj2z4Z8h X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=pbVKhBDs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jwmaag@gmail.com designates 2607:f8b0:4864:20::1136 as permitted sender) smtp.mailfrom=jwmaag@gmail.com X-Spamd-Result: default: False [-3.75 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.75)[-0.754]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1136:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000afb22c05ded04163 Content-Type: text/plain; charset="UTF-8" On Wed, May 11, 2022 at 9:58 AM Michael Schuster wrote: > I got errors about missing "/dev/" files (can't recall the > exact names). > This is still confusing me. It doesn't look as if anything is clobbering /dev. IIRC init(8) should be mounting it, so I would look specifically for errors with that. Maybe look in /var/log/init.log or messages of the failed BE assuming that's not outside your BE parent. I think Dave's suggestion will tell us that your current environment is broken (or at least the children of it are), knowing what broke it though... I'm at a loss. Wes --000000000000afb22c05ded04163 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 11, 2022 at 9:58 AM Micha= el Schuster <michaelsprivate@gmail.com> wrote:
=C2=A0I got errors about missing "/dev/&q= uot; files (can't recall the
exact names).

This is still confusing m= e. It doesn't=C2=A0look as if anything is clobbering /dev. IIRC init(8)= should be mounting it, so I would look specifically for errors with that. = Maybe look in /var/log/init.log or messages of the failed BE assuming that&= #39;s not outside your BE parent.
I think Dave's suggestion w= ill tell us that your current environment is broken (or at least the childr= en of it are), knowing what broke it though... I'm at a loss.


Wes
<= /div>
--000000000000afb22c05ded04163-- From nobody Fri May 13 11:16:39 2022 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 8A96D1ACE50E for ; Fri, 13 May 2022 11:17:41 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L05j05n61z3kxg for ; Fri, 13 May 2022 11:17:40 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: by mail-pj1-x1036.google.com with SMTP id j10-20020a17090a94ca00b001dd2131159aso10564318pjw.0 for ; Fri, 13 May 2022 04:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=C2/CJeJEvzqmZ8OtlURgWVAglodL1sS3ZseuGxwSiQc=; b=C9QIGiQFqz4z4UnVMIzdKqgvfCZyTk87YMXAHVtwF4SiA2Wpc+ILGcelqPbtjGYZUz 8IrQZVf5fqPKS9gQQ2+PNGe4pNV6SNbgV7LzpmCMH6CL/7xPGlcPiVrGv/3wbAQfvnao gl/hDVRq0ovmavGLRCxjnle5EPzUdHZi+VaHEp4N0GEM/nN5w+ywFiUnpdc0WINAyvE3 opCSQyWRVBKOzhk9jXlSlGU8kaHf3a0GDo6eyNu5pEdX2OYZkku00EkXCh3RQa5RgJ9v 7wFrrGiEq5pumwwg88HsZGD5sJdmGmOycL3FNyjHbzyhoaidxaSxET1x60Xl6lxRADle NCFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=C2/CJeJEvzqmZ8OtlURgWVAglodL1sS3ZseuGxwSiQc=; b=pbVACtUV4Io+EDZdFJWUWg1EnOqgz+yHZPfhg8KgbQY7bW/dIKVZKLgKTev6xhx1b7 ObSwvvmo8eJ8+RzQ/ZWb909kDdhQbnixzjowMq+Yz6XKUZR49LzbBpcQoPkYq42Z7lXD c5Fnt/4GYpOKvvQOznI63Ch1+lfmWNzPm56wHVyUU4aaW6fnkzJvM5nS7pKsYGCsVqH5 ibje0SBZ0oNYJPRkSsH9djlU3jb4AEB3wTNHpIyxgH6INx1DwGynw5G3TPvw2HAz83y6 Vmh2sFmFHXpChKj2L33RRRwJg1kam6O+h3Jn2D90KrIlhkzrO9PSYZaXLjKyCUV3zsFQ YgCA== X-Gm-Message-State: AOAM530h2iOdHR6I749d0Tn2/D1G1FtOf3vxdRsrJWum04UyH7kL4Ke9 9U16JObpkbxUfaulmUAw5wFAjPnoclT+t92gj0K7oTWzwlw= X-Google-Smtp-Source: ABdhPJw1LTdiNDJsh9psqom860ujgvk6zxERwezV4K67Ox3GTELPIS1fYhbUw39OYv333sPwWc/zyxHE8N4YH7AyOKU= X-Received: by 2002:a17:902:bf06:b0:156:af5b:e6c with SMTP id bi6-20020a170902bf0600b00156af5b0e6cmr4083944plb.147.1652440653511; Fri, 13 May 2022 04:17:33 -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: obiwac Date: Fri, 13 May 2022 13:16:39 +0200 Message-ID: Subject: rtld: Relocation from unversioned binary matches oldest version instead of "default" To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4L05j05n61z3kxg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=C9QIGiQF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of obiwac@gmail.com designates 2607:f8b0:4864:20::1036 as permitted sender) smtp.mailfrom=obiwac@gmail.com X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1036:from]; NEURAL_HAM_SHORT(-0.90)[-0.904]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Wassup, This may not be strictly speaking a bug with rtld, but it sure is weird/awkward behaviour considering the existing information I could gather. In an unversioned shared object which references a symbol which has multiple versions (e.g. readdir@@FBSD_1.5 & readdir@FBSD_1.0, found with 'readelf -s /lib/libc.so.7 | grep readdir@'), the dynamic linker always selects the oldest version (so readdir@FBSD_1.0 in this case). But as I understand it from documents such as [1], shouldn't the default symbol (readdir@@FBSD_1.5) be used instead? ("Default" means "unhidden" in the context of rtld afaiu, i.e. a symbol where '!(versym & VER_NDX_HIDDEN)'.) The code in question in rtld which exhibits this behaviour is in 'libexec/rtld-elf/rtld.c:matched_symbol': /* * If we are not called from dlsym (i.e. this is a normal * relocation from unversioned binary, accept the symbol * immediately if it happens to have first version after * this shared object became versioned. Otherwise, if * symbol is versioned and not hidden, remember it. If it * is the only symbol with this name exported by the * shared object, it will be returned as a match at the * end of the function. If symbol is global (verndx < 2) * accept it unconditionally. */ if ((req->flags & SYMLOOK_DLSYM) == 0 && verndx == VER_NDX_GIVEN) { result->sym_out = symp; return (true); } else if (verndx >= VER_NDX_GIVEN) { if ((versym & VER_NDX_HIDDEN) == 0) { if (result->vsymp == NULL) result->vsymp = symp; result->vcount++; } return (false); } I imagine the intention behind this is to not break older unversioned shared objects if the default symbol for a certain function it uses is updated while the older version is still provided, but it makes it such that you're forced to provide a version for your symbols in newer programs. This means the common method for creating shared objects for instance is incorrect and yields difficult to debug errors, e.g. in the case of readdir, where a new program will use the new 'dirent' structure, but 'readdir' will be in reality relocated to 'freebsd11_readdir', which assumes the use of 'freebsd11_dirent': % cc -g -fPIC -c lib.c -o lib.o % ld -shared lib.o -o liblib.so % readelf -sD liblib.so | grep readdir # shows readdir unversioned 4: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND readdir Simple fix on the user's end would be to force 'liblib.so' to use versioned symbols: % ld -shared lib.o -o liblib.so /lib/libc.so.7 % readelf -sD liblib.so | grep readdir # shows readdir versioned 4: 0000000000000000 0 FUNC GLOBAL DEFAULT UND readdir@FBSD_1.5 (3) But that's a bit awkward I feel, and I don't see anyone suggesting to do such a thing. One other bit of weirdness is that LLVM equivalents to GNU tools (e.g. 'llvm-objdump') don't seem to have/care about the notion of a "default" version: % objdump -T /lib/libc.so.7 | grep readdir 00000000000af200 g DF .text 00000000000000be FBSD_1.5 readdir_r 00000000000af3b0 g DF .text 00000000000000ed (FBSD_1.0) readdir_r 00000000000af1a0 g DF .text 0000000000000053 FBSD_1.5 readdir 00000000000af2c0 g DF .text 00000000000000ed (FBSD_1.0) readdir % llvm-objdump -T /lib/libc.so.7 | grep readdir 00000000000af200 g DF .text 00000000000000be readdir_r 00000000000af3b0 g DF .text 00000000000000ed readdir_r 00000000000af1a0 g DF .text 0000000000000053 readdir 00000000000af2c0 g DF .text 00000000000000ed readdir This difference in functionality is very frustratingly not mentioned anywhere that I can find in llvm-objdump's documentation, but perhaps this is an indication that unversioned binaries are deprecated and should not be used at all going forward? I don't know, and it irks me quite a bit I can't find any information about this. Currently I'm using a patched version of rtld which behaves the way I understood it should, but I'm still asking here to clarify things, because this stuff has given me quite a few questions and I can't seem to find very many answers. Perhaps kib@ could help with this? [1]: https://people.freebsd.org/~deischen/symver/library_versioning.txt From nobody Fri May 13 20:43:11 2022 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 A63331AE5259 for ; Fri, 13 May 2022 20:43:15 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0LFZ3jzLz3Jd9 for ; Fri, 13 May 2022 20:43:13 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1652474592; 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=zlcB5/xhvYboIcqWKApBUN8ol8j5ykXBBuCoGCxsJYw=; b=kkZiGX2YTZHvIGjM09H1vkreGysliSyuPzbtgMFLjSzO6sMx3pdCX0sbeC2ISy2ZBHVcwc UTv1bLmuI2xWmW+PHGskzZnptQwxZfZYU3NYubLPo/h6qTDZb9UUrZcNxWkJYgoRfQCSNd LPi/HujnT+M2gvIxsD1Jfiw52gYGb9o= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 84ed5f9f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 13 May 2022 20:43:11 +0000 (UTC) Content-Type: multipart/mixed; boundary="------------y3V06LKg9WtVz16sasyhpvp0" Message-ID: Date: Fri, 13 May 2022 13:43:11 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Content-Language: en-US To: freebsd-current@freebsd.org References: <83A713B9-A973-4C97-ACD6-830DF6A50B76.ref@yahoo.com> <83A713B9-A973-4C97-ACD6-830DF6A50B76@yahoo.com> <94B2E2FD-2371-4FEA-8E01-F37103F63CC0@yahoo.com> <0fcb5a4a-5517-e57b-2b69-4f3b3b10589a@nomadlogic.org> <464ED220-0DE4-4D2F-9DA2-AFD00D8D42B7@yahoo.com> <446d5913-a8c2-7dd0-860b-792fa9fe7c5b@nomadlogic.org> <33B740AA-A431-49CB-9F27-50B8C49734A2@yahoo.com> <3C5C183F-1471-4139-A53C-0B3815CFC25E@yahoo.com> <75C02C8C-6A5E-4E19-AC7D-B5DB704E8F16@transactionware.com> <0E44A609-A040-4801-B3FA-E0B410F0C3D3@yahoo.com> From: Pete Wright In-Reply-To: <0E44A609-A040-4801-B3FA-E0B410F0C3D3@yahoo.com> X-Rspamd-Queue-Id: 4L0LFZ3jzLz3Jd9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=kkZiGX2Y; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-1.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------y3V06LKg9WtVz16sasyhpvp0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/11/22 12:52, Mark Millard wrote: > > > Relative to avoiding hang-ups, so far it seems that > use of vm.swap_enabled=0 with vm.swap_idle_enabled=0 > makes hang-ups less likely/less frequent/harder to > produce examples of. But is no guarantee of lack of > a hang-up. Its does change the cause of the hang-up > (in that it avoids processes with kernel stacks swapped > out being involved). thanks for the above analysis Mark.  i am going to test these settings out now as i'm still seeing the lockup. this most recent hang-up was using a patch tijl@ asked me to test (attached to this email), and the default setting of vm.pageout_oom_seq: 12.  interestingly enough with the patch applied i observed a smaller amount of memory used for laundry as well as less swap space used until right before the crash. cheers, -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA --------------y3V06LKg9WtVz16sasyhpvp0 Content-Type: text/x-patch; charset=UTF-8; name="vm_pageout_worker.patch" Content-Disposition: attachment; filename="vm_pageout_worker.patch" Content-Transfer-Encoding: base64 RnJvbSBmMzI2MGEyZWIxY2RjODZmOTIxNmI3OTIzZDdiMDk3MDRhMzdlNzlkIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBUaWpsIENvb3NlbWFucyA8dGlqbEBGcmVlQlNELm9y Zz4KRGF0ZTogU3VuLCA4IE1heSAyMDIyIDEyOjE5OjI4ICswMjAwClN1YmplY3Q6IFtQQVRD SF0gdm06IHN0b3AgYmFja2dyb3VuZCBsYXVuZGVyaW5nIHdoZW4gbm8gcHJvZ3Jlc3MKCkxl dCB2bV9wYWdlb3V0X2xhdW5kcnlfd29ya2VyIGdvIHRvIHNsZWVwIHdoZW4gaXQgY2Fubm90 IG1ha2UKcHJvZ3Jlc3MgKG5mcmVlZCA9PSAwKS4gIFRoaXMgYWxsb3dzIG90aGVyIHRocmVh ZHMgdG8gcnVuIHNvIHRoZXkKY2FuIGhvcGVmdWxseSBmcmVlIHNvbWUgbWVtb3J5LgoKVGhp cyByZXN0b3JlcyBiZWhhdmlvdXIgZnJvbSBiZWZvcmUgYzA5ODc2OGU0ZGFkIGFuZCA2MDY4 NDg2MjU4OGYKYW5kIHByZXZlbnRzIHNvbWUgT09NIGtpbGxzLgoKVGVzdGVkIGJ5OglQZXRl IFdyaWdodCA8cGV0ZUBub21hZGxvZ2ljLm9yZz4KTUZDIGFmdGVyOgkyIHdlZWtzCi0tLQog c3lzL3ZtL3ZtX3BhZ2VvdXQuYyB8IDYgKystLS0tCiAxIGZpbGUgY2hhbmdlZCwgMiBpbnNl cnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy92bS92bV9wYWdl b3V0LmMgYi9zeXMvdm0vdm1fcGFnZW91dC5jCmluZGV4IDM2ZDVmMzI3NTgwMC4uZmJiMmNk NDEyOGYwIDEwMDY0NAotLS0gYS9zeXMvdm0vdm1fcGFnZW91dC5jCisrKyBiL3N5cy92bS92 bV9wYWdlb3V0LmMKQEAgLTEwNjEsMTUgKzEwNjEsMTMgQEAgdm1fcGFnZW91dF9sYXVuZHJ5 X3dvcmtlcih2b2lkICphcmcpCiAJCSAqIGNsZWFuIHBhZ2VzIGZyZWVkIGJ5IHRoZSBwYWdl IGRhZW1vbiBzaW5jZSB0aGUgbGFzdAogCQkgKiBiYWNrZ3JvdW5kIGxhdW5kZXJpbmcuICBU aHVzLCBhcyB0aGUgcmF0aW8gb2YgZGlydHkgdG8KIAkJICogY2xlYW4gaW5hY3RpdmUgcGFn ZXMgZ3Jvd3MsIHRoZSBhbW91bnQgb2YgbWVtb3J5IHByZXNzdXJlCi0JCSAqIHJlcXVpcmVk IHRvIHRyaWdnZXIgbGF1bmRlcmluZyBkZWNyZWFzZXMuICBXZSBlbnN1cmUKLQkJICogdGhh dCB0aGUgdGhyZXNob2xkIGlzIG5vbi16ZXJvIGFmdGVyIGFuIGluYWN0aXZlIHF1ZXVlCi0J CSAqIHNjYW4sIGV2ZW4gaWYgdGhhdCBzY2FuIGZhaWxlZCB0byBmcmVlIGEgc2luZ2xlIGNs ZWFuIHBhZ2UuCisJCSAqIHJlcXVpcmVkIHRvIHRyaWdnZXIgbGF1bmRlcmluZyBkZWNyZWFz ZXMuCiAJCSAqLwogdHJ5YmFja2dyb3VuZDoKIAkJbmNsZWFuID0gdm1kLT52bWRfZnJlZV9j b3VudCArCiAJCSAgICB2bWQtPnZtZF9wYWdlcXVldWVzW1BRX0lOQUNUSVZFXS5wcV9jbnQ7 CiAJCW5kaXJ0eSA9IHZtZC0+dm1kX3BhZ2VxdWV1ZXNbUFFfTEFVTkRSWV0ucHFfY250Owot CQlpZiAodGFyZ2V0ID09IDAgJiYgbmRpcnR5ICogaXNxcnQoaG93bWFueShuZnJlZWQgKyAx LAorCQlpZiAodGFyZ2V0ID09IDAgJiYgbmRpcnR5ICogaXNxcnQoaG93bWFueShuZnJlZWQs CiAJCSAgICB2bWQtPnZtZF9mcmVlX3RhcmdldCAtIHZtZC0+dm1kX2ZyZWVfbWluKSkgPj0g bmNsZWFuKSB7CiAJCQl0YXJnZXQgPSB2bWQtPnZtZF9iYWNrZ3JvdW5kX2xhdW5kZXJfdGFy Z2V0OwogCQl9Ci0tIAoyLjM1LjEKCg== --------------y3V06LKg9WtVz16sasyhpvp0-- From nobody Fri May 13 23:57:33 2022 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 511AB1AE1000 for ; Fri, 13 May 2022 23:57:49 +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 4L0QZ43Ft8z4QsR for ; Fri, 13 May 2022 23:57:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 24DNvXc1027138 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 14 May 2022 02:57:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 24DNvXc1027138 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 24DNvXIC027137; Sat, 14 May 2022 02:57:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 May 2022 02:57:33 +0300 From: Konstantin Belousov To: obiwac Cc: freebsd-current@freebsd.org Subject: Re: rtld: Relocation from unversioned binary matches oldest version instead of "default" 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=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4L0QZ43Ft8z4QsR X-Spamd-Bar: -- 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 X-Spamd-Result: default: False [-2.33 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.33)[-0.333]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Fri, May 13, 2022 at 01:16:39PM +0200, obiwac wrote: > Wassup, > > This may not be strictly speaking a bug with rtld, but it sure is > weird/awkward behaviour considering the existing information I could > gather. > > In an unversioned shared object which references a symbol which has > multiple versions (e.g. readdir@@FBSD_1.5 & readdir@FBSD_1.0, found > with 'readelf -s /lib/libc.so.7 | grep readdir@'), the dynamic linker > always selects the oldest version (so readdir@FBSD_1.0 in this case). > But as I understand it from documents such as [1], shouldn't the > default symbol (readdir@@FBSD_1.5) be used instead? ("Default" means > "unhidden" in the context of rtld afaiu, i.e. a symbol where '!(versym > & VER_NDX_HIDDEN)'.) > > The code in question in rtld which exhibits this behaviour is in > 'libexec/rtld-elf/rtld.c:matched_symbol': > > /* > * If we are not called from dlsym (i.e. this is a normal > * relocation from unversioned binary, accept the symbol > * immediately if it happens to have first version after > * this shared object became versioned. Otherwise, if > * symbol is versioned and not hidden, remember it. If it > * is the only symbol with this name exported by the > * shared object, it will be returned as a match at the > * end of the function. If symbol is global (verndx < 2) > * accept it unconditionally. > */ > if ((req->flags & SYMLOOK_DLSYM) == 0 && verndx == VER_NDX_GIVEN) { > result->sym_out = symp; > return (true); > } > else if (verndx >= VER_NDX_GIVEN) { > if ((versym & VER_NDX_HIDDEN) == 0) { > if (result->vsymp == NULL) result->vsymp = symp; > result->vcount++; > } > return (false); > } > > I imagine the intention behind this is to not break older unversioned > shared objects if the default symbol for a certain function it uses is > updated while the older version is still provided, but it makes it > such that you're forced to provide a version for your symbols in newer > programs. > > This means the common method for creating shared objects for instance > is incorrect and yields difficult to debug errors, e.g. in the case of > readdir, where a new program will use the new 'dirent' structure, but > 'readdir' will be in reality relocated to 'freebsd11_readdir', which > assumes the use of 'freebsd11_dirent': > > % cc -g -fPIC -c lib.c -o lib.o > % ld -shared lib.o -o liblib.so > % readelf -sD liblib.so | grep readdir # shows readdir unversioned > 4: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND readdir > > Simple fix on the user's end would be to force 'liblib.so' to use > versioned symbols: > > % ld -shared lib.o -o liblib.so /lib/libc.so.7 > % readelf -sD liblib.so | grep readdir # shows readdir versioned > 4: 0000000000000000 0 FUNC GLOBAL DEFAULT UND readdir@FBSD_1.5 (3) > > But that's a bit awkward I feel, and I don't see anyone suggesting to > do such a thing. It is not awkward, it is intended. What you do is called underlinking and is controlled by --allow-shlib-undefined or similar ld(1) switch. It is generally considered a wrong to allow underlinking, for obvious reasons that the result is problematic. Base system turns on ld(1) error on unresolved symbol use in shared libraries, and I think it is a trend in most Linux distributions as well. In other words, underlinking is not recommended/avoided. The biggest problem from underlinking for users is that they could end up referencing non-existing symbols, or depend on the implementation details of the used library. For later, if you link library A which DT_NEEEDED library B and B provides symbol X, then it is quite common to use X. This breaks when A stops neededing B, breaking ABI. Another problem in your proposal is that the versioning inheritance does not work the way you described, there is no 'latest' version of the symbol. Imagine the following version script: VER_A { global: X; }; VER_B { global: X; } VER_A; VER_C { global: X; } VER_A; what is the 'latest' X there? It just the FreeBSD conventions that we enforce linear inheritance, but this is not true for third party version scripts. And the last thing, changing the rtld behaviour there would be very subtle ABI break. > > One other bit of weirdness is that LLVM equivalents to GNU tools (e.g. > 'llvm-objdump') don't seem to have/care about the notion of a > "default" version: > > % objdump -T /lib/libc.so.7 | grep readdir > 00000000000af200 g DF .text 00000000000000be FBSD_1.5 readdir_r > 00000000000af3b0 g DF .text 00000000000000ed (FBSD_1.0) readdir_r > 00000000000af1a0 g DF .text 0000000000000053 FBSD_1.5 readdir > 00000000000af2c0 g DF .text 00000000000000ed (FBSD_1.0) readdir > % llvm-objdump -T /lib/libc.so.7 | grep readdir > 00000000000af200 g DF .text 00000000000000be readdir_r > 00000000000af3b0 g DF .text 00000000000000ed readdir_r > 00000000000af1a0 g DF .text 0000000000000053 readdir > 00000000000af2c0 g DF .text 00000000000000ed readdir > > This difference in functionality is very frustratingly not mentioned > anywhere that I can find in llvm-objdump's documentation, but perhaps > this is an indication that unversioned binaries are deprecated and > should not be used at all going forward? I don't know, and it irks me > quite a bit I can't find any information about this. > > Currently I'm using a patched version of rtld which behaves the way I > understood it should, but I'm still asking here to clarify things, > because this stuff has given me quite a few questions and I can't seem > to find very many answers. > > Perhaps kib@ could help with this? > > [1]: https://people.freebsd.org/~deischen/symver/library_versioning.txt From nobody Sat May 14 07:05:39 2022 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 7A94E1ADE19D for ; Sat, 14 May 2022 07:06:54 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0c593mCPz53dx for ; Sat, 14 May 2022 07:06:53 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id i5so13905041wrc.13 for ; Sat, 14 May 2022 00:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language :from:to:references:in-reply-to:content-transfer-encoding; bh=j4k5FIkpiKdSDBbThpZUxACoILYkLh2URHDhY6we2JQ=; b=ndbusQ/w2mL70P/cv608eMXKXRUG2RtaGhn8/1yvtox1yK2RcGxcuuhMwuRM+lsJxs JBrJLl/fSPnM2nOk9XrOO4nJL5ufkrX5AyzfvIyLCn8+B+ZDG3z/DHpg4GiUGBvMZY2U LYCx+Poj9rMoKMshHXhiFTqGlLpSVZf511PG4RUxC4Ni/zW1ePDt5RvmOA8mjulVzs11 ziU5cIa0MFMUVwaelZq/cXXrX9Qv7s21Lja7FuvGtKeqpqI38lyezlvpETl8tEcvr4rc Xn91ZaMViCfLlgHP4eq8eUYfegVsYvQGDYJ1/tNM4kPdFjwyZxkNPROw5a/mawpsDxHA LT3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:references:in-reply-to :content-transfer-encoding; bh=j4k5FIkpiKdSDBbThpZUxACoILYkLh2URHDhY6we2JQ=; b=QasvoT6sujS74gTTYZw40agb7b2LtvMfsD8dAQq+rOlWNumMhJwxdSiDXn052fVu+A 2GqRfTwBZrubPNz8xoUJVRXIiOTpD+Gzk7wmpUZCO/36w/90RD9/EgdUbIcowjZBVXfb Io4aIkk/qZAv7KoWmm41rAi663ANN0rVT1ZAw3Lqkac/KBa+Dkn9nim77rfnELeyJ3uA LpkYeJ10rlZP2pgJdyOGWwwjXUFZx/DRZ4qXNUVrJtaykFqVO84NsumiJy8YdGuM5h6C quDTNbvrAmgJFvsA6DHKlMjAaB6DLE6k/ZHPDE1g6cl8aGBiU8zR6j46Ao8qWq01w0iN JJDA== X-Gm-Message-State: AOAM531UFSe/aztS0+CATLbvtO8otEJQfPw/ne6uopaijSxqUbASCfuI F4yIlCWeRYw80arMzhA/Bq8kYoSmnszTxQ== X-Google-Smtp-Source: ABdhPJxnzCG+mURQUc4biViV5vpFci5FYQys2hT3p3j7wiTg8d+8gWxrp4P7dHzsyPKTWQdXaX5Cmw== X-Received: by 2002:a5d:47c9:0:b0:20c:80bb:a296 with SMTP id o9-20020a5d47c9000000b0020c80bba296mr6555780wrc.384.1652512011629; Sat, 14 May 2022 00:06:51 -0700 (PDT) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id h16-20020adf9cd0000000b0020c5253d8casm3896614wre.22.2022.05.14.00.06.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 May 2022 00:06:51 -0700 (PDT) Message-ID: <32a85424-fb0d-c1e5-867b-e73f27388b9a@gmail.com> Date: Sat, 14 May 2022 08:05:39 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: EFI framebuffer information, then nothing: GENERIC-NODEBUG Content-Language: en-GB From: Graham Perrin To: FreeBSD-CURRENT References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4L0c593mCPz53dx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="ndbusQ/w"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::431 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 19/04/2022 23:37, Graham Perrin wrote: > Sometimes, boot gets no further than EFI framebuffer information. > Whenever this occurs, the computer will stop immediately in response > to a simple, short press on the power button. … When I first wrote , I omitted a key point: I normally install GENERIC-NODEBUG. I wondered whether GENERIC would be less prone to the problem. For around two weeks I ran GENERIC e140d551b78 without a problem. For the next upgrade, I chose GENERIC-NODEBUG 01235012e5b. Problems recurred immediately; a series of six or seven boot failures. IIRC the first successful boot was with a combination of single user + verbose mode. Since then: a mixture of failures and successes, with an ongoing sense that single user + verbose mode is likely to work around the problem. This morning I changed loader.conf from boot_verbose="NO"   to boot_verbose="YES" – I'll reboot frequently over the next few days, to get an idea of whether verbosity reduces the likelihood of the problem. Gut feeling: it will make little or no difference (I'm almost certain that I tried verbose boot alone, at the boot loader menu, a few times in the past, without success). (2022-04-27) (2022-05-12) % bectl list -c creation BE                    Active Mountpoint Space Created n250511-5f73b3338ee-d -      -          64.6G 2021-11-13 15:43 n252381-75d20a5e386-b -      -          23.5G 2022-01-12 23:23 n252450-5efa7281a79-a -      -          6.87G 2022-01-14 19:27 n252483-c8f8299a230-b -      -          7.85G 2022-01-17 14:24 n252505-cc68614da82-a -      -          5.24G 2022-01-18 14:26 n252531-0ce7909cd0b-h -      -          10.1G 2022-02-06 12:24 n252997-b6724f7004c-c -      -          8.10G 2022-02-11 23:07 n253116-39a36707bd3-e -      -          7.58G 2022-02-20 07:03 n253343-9835900cb95-c -      -          9.32G 2022-02-27 14:58 n253776-d5ad1713cc3-b -      -          14.1G 2022-03-18 09:31 n253861-92e6b4712b5-e -      -          14.5G 2022-04-02 16:02 n254268-50e244964e9-d -      -          11.0G 2022-04-09 18:50 n254693-d7696096209-f -      -          14.2G 2022-04-27 17:41 n255078-e140d551b78-h -      -          7.06M 2022-05-11 21:18 n255588-01235012e5b-a -      -          19.4M 2022-05-12 22:23 n255588-01235012e5b-b NR     /          13.4G 2022-05-12 23:36 % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #11 main-n255588-01235012e5b-dirty: Thu May 12 21:45:43 BST 2022     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC -NODEBUG amd64 1400058 1400058 % grep -v \# /etc/src.conf | sort KERNCONF=GENERIC-NODEBUG WITH_CCACHE_BUILD=yes WITH_MALLOC_PRODUCTION=yes % From nobody Sat May 14 08:09:30 2022 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 550481AE92D4 for ; Sat, 14 May 2022 08:09:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0dTk0LG0z59HV for ; Sat, 14 May 2022 08:09:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652515777; bh=DKBnlcA/ZsekJq8CeOYQEt9OysOOGQcce+Ebs6DFMmU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=ir+jQ1dqOxxxRYS2ZnuDBRR0SMY9ZhJbXk9ypkTxvA5Z5M6sV3v+97bf593yVrUTYO7kBLopOuex+hhNQssZ6OLOf1E9XaNKpdlcHAv8PSblGtDGU5iEk0NSZ8RRcCqzNwKjTaI2WyHN509IbxA5DnOOgVxWkie+DW1uB867/90VYihhuVAkJyIdMAmdNYN5DVPCcsGq2uWj+3ePu15ME1CeYV0XXgbrOTJme+bYt/12Y12nOMSNCjVVA457rGxE47RUb2hCjJknYj5NafQBqSzc3ou7raD3L0k6/UjVAwZacuOQ0dZiLQ3hMA1at3hjX6GUOjJU81dNcrdYmGrSKA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652515777; bh=8SE6Neexw8aF+UAJ0auqFEAxHvJexXZB6QuCx6VWXwb=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=T8Kt3fTvKra/vB7EFba1D6+ABnc4PPDWXOsTXdw1UinPKUvhSqlSNYzBneNFq3VyZUt8Sj+2mozkM9YO95Br/slcLGLW3Uc+xCKP4c2LnIZ8dCGh9f2ZgmgL7nHVXkuCsKYoWzUZK/UbEIRbIk2Dg0Dyqgd6Yho1zDJ7TnlzMpKTV04tkxx1lfBTr22C/GcjMywAuHLw0oQTS8OAqiSYVZ0UApvngwXNCFH9SaB/1NmcCW6D/FWD6YV6RxORZMTfOkb9s2n7BBxeEGg7sXk53AqLplrNixOLs6Py4Pf0Ys/Dw+gPk8Uz1iq0+N6cXgDUAPb4g9BrYQJw2dXxO7pbDw== X-YMail-OSG: oZ4ecZ0VM1k.iQZiK1U7jybxtIlGcQe9_wDRr52FoGH6XynhDBlFivKS3GXo5yU Zsk90x_Uw_0AyiSp6X7FUSPDyO6Fd5XVGfhn7iYASokiLmJ_D8fJ.II7Mtjr8r4ICwrbEDnOVpBh kyYSUMawsQ0QchyEpWKEWK4iWZoarNpsYqMDrH6K69L6erZgjdLPG7G.zLf0EGSnMAQdygy5t1bp kpVIl_xQyhDznxkPYHpwNT18X6.2L5gyh1Q31y1.fEJMguIM6Z.MTGLYpRnDmA3HtB1.3ztwbU9S 7xl465tpgNx5rpwrlTQgpHXIXOZFrSL2HZWBz1ZQGX06oxKwS7g6vwz7Igx7V6WfdlOfdI3Tqj6c HVquTd9T2O.Z_0BNhzHZ.mw3hdU94Wbd8lqu3eNGPUf0bavNqbOEUchRvU0vdk_DO_S5uK_VnpMe _IEuVn7clpU2uqCNPQ9YRk3KKZfql6OkF2UlAkF..OeEUILiSujh3iOhZV559Uq3QF2TE_sTUTsP auSb1mpW_uWORZHUbdAT52lsXqFKlTNh.U0KjZoYVzesfnGq5CsqkpfC.kgYHveYNr7lxJRpxXxh MyTcuNqRD3iFNpP_lHZ08uzvPUVbdTtynFg3LkxTQdI6Du1Apz4iDf1fgD9RsQ_sH6ih..knGA42 Ao5fRaTbsTp6ala_FAfG_OBlhOZsVch9Y2yjLgf.AACwQoAs91kPjX7KTmkt2BhNHK6CyHtN85Tc odrCdUisBgbybrDsZUpTypNdh7O4gQwx0lYrF.28PzpqeJ3bczeIC_yz_jz7qq6buMO7BNjTbuym A77znEZH9Sy7FfwDEMS4BcUuIX10QzG6bKntiXHcbvTTR0xhxz_NiqxY.5MDcLmRmRdw_w8.ww9P td6PS69.paH.j480x0MSX5a_NTPlCRZ4nIf2CaiCi6Xe_Io29TW0ImKmwyilRZmCsuoSvXE.u5kW Wyj1Q7CUXdY4DlJmK_RQaherc.rMeWW76Lv0zxlOnCyPsGzGWzKdyAGYqN98RHkxFP8CSfXmUngW 40Y607ANtUqYnYTrg1WgFPoHQwjN1_E1xR4K7Zwpd141FYVtm5_Pt6f6Dd9neda0WMFNcMNLEpJs YUlvQY2k_cTUzNicN5iT.UrCRs1LzhfV0ieB6gMAyveV_c4Tjq6AMqt.oPLRGiCpKn801jwmGbNX ykfHYQzmahdCcpuE63HyxwDt7cuGtam0zaaztOYOzgATmNARLFtfwizAQvnB.gBJlfCwug9Uttqf Zc0G5vmfo_mltMxAaAOZ1ZxoGnJjCjuu3caYUzdlET6Y6ewIcwnonmbWSRsTC.1TpMl5yO2PWD45 OgjnarOSGpnLpwonG2nk4PNu1ctmbGciLFIz5YuKumEOB5nQhB8kOw5IAalA_3Kve7X6UsG_Ir94 hCXvwD4g2_0EH95jDG1KW28Zz1iWkil6qmg7nuMFw2A8R5U4f4lHf757HdOC1UCWCUqUFIb9xiBg emfuVMwPFgKbp2jBn5Umlrg0fBLbeZPTXNGf1ZeuCdVb_DmamuN500isPhDnB1f8KZE_Ku4rs0KB r80hYjTIPsQ78Ei_yWvsSZyRVit_TYqrfmJOqWlisNivqkFO09Q1aiYuj6.jR3zxOycmQoRWGcNP QSRHxzdOg8Dq.0mq_NWK77yXUeqilqONBMFsmt3s1Yq2lwyA3.e2cVhjSMQDnwe8dDrPInCtmJhB PKB2bDHAVwK4uCqcz5TtrjCv2z4kXcuDDHbKGiExVi2j5XSAit0YRgTiWUSm_RYqNTIDx5bh3cvs eCyWU8yWZg7tN3eY7SgG6etg6vSlrfWY1CdMob7OqD9J1le3mmpF9ahmOw5AO4XktdxOuJWVQvu4 kRmtmY0UKyXysuOwZ59hL86nhA71DyVfvEJLaoA5Gu7KIhnTTFJUmhcDMjbS8GaWWR1lHocayOlI zykH7wgVcXJ9T.621bX5GRy4a2bVP4JwBnzAEH4sXGzeGPaSB3BgMR5RruPDrqYCMwgpdhstzjNc l0KzaUM20W3ts873l5iPZ5ywXaHw_LliYSy2NpFAHySfhz8ye995pLgsCf1MzRJIW3w1oO9MXiZk JRl4raqliZ2j0tnvsBiCIx6z5N_NbdC4AkL96sxaDt0Oiqa137xU7Hz8n09AoZFHLlGFRDYoe406 qKNWDwyK19.XNE_Qg2UjHylTL8Dpfo8OyT9Dv8lqsc6GQ_wUI5rIfDKngJRY1AUR1pojjeVeUMw3 7wYN88PRl9C66qbRQM2RwHfoQuHsK3TGSsw_By2UhAD8px17s2hvzKnDBzibMxvV44FnJlqurPi3 aHlS_dZzRKqvWvw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sat, 14 May 2022 08:09:37 +0000 Received: by hermes--canary-production-bf1-579c78cbb7-lxrpx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6a8a2233e0b69a3cd7b077c3b722d3bd; Sat, 14 May 2022 08:09:34 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Chasing OOM Issues - good sysctl metrics to use? Message-Id: <8C14A90D-3429-437C-A815-E811B7BFBF05@yahoo.com> Date: Sat, 14 May 2022 01:09:30 -0700 To: Pete Wright , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <8C14A90D-3429-437C-A815-E811B7BFBF05.ref@yahoo.com> X-Rspamd-Queue-Id: 4L0dTk0LG0z59HV X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ir+jQ1dq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.91 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.42)[-0.420]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.30:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Pete Wright wrote on Date: Fri, 13 May 2022 13:43:11 -0700 : > On 5/11/22 12:52, Mark Millard wrote: > > > > > > Relative to avoiding hang-ups, so far it seems that > > use of vm.swap_enabled=3D0 with vm.swap_idle_enabled=3D0 > > makes hang-ups less likely/less frequent/harder to > > produce examples of. But is no guarantee of lack of > > a hang-up. Its does change the cause of the hang-up > > (in that it avoids processes with kernel stacks swapped > > out being involved). >=20 > thanks for the above analysis Mark. i am going to test these settings=20= > out now as i'm still seeing the lockup. >=20 > this most recent hang-up was using a patch tijl_at_ asked me to test=20= > (attached to this email), and the default setting of = vm.pageout_oom_seq:=20 > 12. I also had been run various tests for tijl_at_ , the same sort of 'removal of the " + 1" patch'. I had found a basic way to tell if a fundamental problem was completely avoided or not, without having to wait long periods of activity to do so. But that does not mean the test is a good simulation of your context's sequence that leads to issues. Nor does it indicate how wide a range of activity is fairly likely to reach the failing conditions. You could see how vm.pageout_oom_seq=3D120 does for you with the patch. I was never patient enough to wait long enough for this to OOM kill or hang-up in my test context. I've been reporting the likes of: # sysctl vm.domain.0.stats # done after the fact vm.domain.0.stats.inactive_pps: 1037 vm.domain.0.stats.free_severe: 15566 vm.domain.0.stats.free_min: 25759 vm.domain.0.stats.free_reserved: 5374 vm.domain.0.stats.free_target: 86914 vm.domain.0.stats.inactive_target: 130371 vm.domain.0.stats.unswppdpgs: 0 vm.domain.0.stats.unswappable: 0 vm.domain.0.stats.laundpdpgs: 858845 vm.domain.0.stats.laundry: 9 vm.domain.0.stats.inactpdpgs: 1040939 vm.domain.0.stats.inactive: 1063 vm.domain.0.stats.actpdpgs: 407937767 vm.domain.0.stats.active: 1032 vm.domain.0.stats.free_count: 3252526 But I also have a kernel that reports just before the call that is to cause a OOM kill, ending up with output like: vm_pageout_mightbe_oom: kill context: v_free_count: 15306, = v_inactive_count: 1, v_laundry_count: 64, v_active_count: 3891599 May 11 00:44:11 CA72_Mbin_ZFS kernel: pid 844 (stress), jid 0, uid 0, = was killed: failed to reclaim memory (I was testing main [so: 14].) So I report that as well. Since I was using stress as part of my test context, there were also lines like: stress: FAIL: [843] (415) <-- worker 844 got signal 9 stress: WARN: [843] (417) now reaping child worker processes stress: FAIL: [843] (451) failed run completed in 119s (tijl_at_ had me add v_laundry_count and v_active_count to what I've had carried forward since back in 2018 when Mark J. provided the original extra message.) Turns out the kernel debugger (db> prompt) can report the same general sort of figures: db> show page vm_cnt.v_free_count: 15577 vm_cnt.v_inactive_count: 1 vm_cnt.v_active_count: 3788852 vm_cnt.v_laundry_count: 0 vm_cnt.v_wire_count: 272395 vm_cnt.v_free_reserved: 5374 vm_cnt.v_free_min: 25759 vm_cnt.v_free_target: 86914 vm_cnt.v_inactive_target: 130371 db> show pageq pq_free 15577 dom 0 page_cnt 4077116 free 15577 pq_act 3788852 pq_inact 1 pq_laund 0 = pq_unsw 0 (Note: pq_unsw is a non-swappable count that excludes the wired count, apparently matching vm.domain.0.stats.unswappable .) The above is the most extremely small pq_inact+pq_laund that I saw at the OOM kill time or during a "hang-up" (what I saw across example "hang-ups" suggests to me a livelock context, not a deadlock context). > interestingly enough with the patch applied i observed a smaller=20 > amount of memory used for laundry as well as less swap space used = until=20 > right before the crash. If your logging of values has been made public, I've not (yet?) looked at it at all. None of my testing reached a stage of having much swap space in use. But the test is biased to produce the problems quickly, rather than to explore a range of ways to reach conditions with the problem. I've stopped testing for now and am doing a round of OS building and upgrading, port (re-)building and installing and the like, mostly for aarch64 but also for armv7 and amd64. (This is without the 'remove " + 1"' patch.) One of the points is to see if I get any evidence of vm.swap_enabled=3D0 with vm.swap_idle_enabled=3D0 ending up contributing to any problems in my normal usage. So far: no. vm.pageout_oom_seq=3D120 is in use for this, my normal context since sometime in 2018. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat May 14 09:39:23 2022 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 A75E91AD1487 for ; Sat, 14 May 2022 09:39:34 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0gTK4gLQz3L6w for ; Sat, 14 May 2022 09:39:33 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 7F7FD10A1E85 for ; Sat, 14 May 2022 11:39:26 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id DBCE610A32F4 for ; Sat, 14 May 2022 11:39:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1652521164; 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=lUgwIb88NBIwa5jgHyeUyJAX4mVmlmqgNMQtVNYsyJI=; b=J1+0TpypQzPX/g2q2EEbV7lE49DZUKORnFw52Z7rkHVJyvd0jH6vNkpqcZIbkQTzDl7ydL sITrO7rVmiiXIDAMe/m7bCrn8Geqvyu23cn4bdeJJ4L5i4H+YUZBmcXKG0guXmrnz0nD4h 7c6Oxsivq4beAHFzD3Fexvqc2EIFFVvinJZDrunP68PeGOm0BNzaDAAI0KZbySPBFVPwgx j745Vt7qqGbnnxHHFpEW/oHKH6w2ZE5/4lNPpd42NWB5keGrkAnUTNku1GbLYJPU3tfuPj on7kwcOT9xmp98KjVTSxvkCkNFxrqTpw0P4KhRYOLnWcpaZvK7wXe+HH/uf4Fg== Received: from hermann (dynamic-2a01-0c23-5de7-7300-fc43-3716-9269-5894.c23.pool.telefonica.de [IPv6:2a01:c23:5de7:7300:fc43:3716:9269:5894]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id A129F10A330F for ; Sat, 14 May 2022 11:39:24 +0200 (CEST) Date: Sat, 14 May 2022 11:39:23 +0200 From: FreeBSD User To: FreeBSD CURRENT Subject: vnet/if_bridge: ARP issues: connection failure Message-ID: <20220514113923.523f1ea9@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: ce95d9 X-Rspamd-UID: 3ea6f9 X-Rspamd-Queue-Id: 4L0gTK4gLQz3L6w X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=J1+0Tpyp; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.15 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt-de.de]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; NEURAL_HAM_SHORT(-0.26)[-0.262]; MLMMJ_DEST(0.00)[freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from] X-ThisMailContainsUnwantedMimeParts: N Hello, the problem I'm about to report is not specific to CURRENT, I report this to CURRENT because I'm list member. The problem occurs on FreeBSD 12.3-RELEASE-p5. Setup: connecting to vnet jails bound to a dedicated NIC via if_bridge results in an erratic behaviour (from my point of view). The box has two NICs, em0 which is dedicated for managing the host and igb0 for services like NFS, SMB and jails (the host is de facto a Xigmanas box). The NIC igb0 also has an IPv4 which is accessible without problem (sshd is listening on em0 and igb0 and any service bound to igb0 and its IP itself works like a charme, execept anything that is connected via if_bridge/vnet). Both, em0 and igb0, are member of the same network and connected to the same switch (I guess, it's the campus infrastructure, I have no access to that). Phenomenon: trying to ping a jail results initially in a long term waiting and often in "Host is down" - but then, sudenly, the jail is responding. Trying to connect to port 22/tcp of any jail doesn't work in 90% of the cases, but randomly, a host (out of five) does respond and the connection can be established. Terminating the connection and tryin again is in 99% then a fail. Once connected the ssh connection fries after a couple of seconds of inactivity. Checking ARP on the jail (login via host and jexec) and listening via tcpdump -XXvi vnet0 arp on a jail while pinging the jail from the netowrk shows up the typical requests, but not every request is then acompanied by a reply. I'm not firm in terms of networking and investigating ARP issues, so I followed some instructions found with ARP issues on FBSD, vnet and routing. MIB settings (on the host itself, vnet untouched): net.inet.ip.forwarding: 0 net.link.bridge.ipfw: 0 net.link.bridge.allow_llz_overlap: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 0 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_bridge: 0 net.link.bridge.pfil_onlyip: 0 I also realised that on the igb0 interace checksum errors occured while rxcsum is enabled. I disbaled special features via "ifconfig igb0 -rxcsum -txcsum -tso -lro I'm out of ideas here. Another box, the same base OS, similar setup (two NICs, same ambition), but with the difference that the second NIC resides on a different network and is connected to a different switch, also if_bridge and vnet attached jails, there is no problem. Either there is a serious bug in 12.3-p5 (haven't had the chance to check on 13/CURRENT) or I'm doing something terribly wrong. Some technical details: em0@pci0:0:25:0: class=0x020000 card=0x29828016 chip=0x153b8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection I217-V' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf7d00000, size 131072, enabled bar [14] = type Memory, range 32, base 0xf7d35000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0xf080, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP gb0@pci0:4:0:0: class=0x020000 card=0x00028086 chip=0x15848086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I210 Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf7900000, size 1048576, enabled bar [1c] = type Memory, range 32, base 0xf7a00000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 5 messages, enabled Table in map 0x1c[0x0], PBA in map 0x1c[0x2000] cap 10[a0] = PCI-Express 2 endpoint max data 128(512) FLR NS max read 512 link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 xxxxxxxxxxxxxxxxxxxxx ecap 0017[1a0] = TPH Requester 1 Kind regards, oh From nobody Sat May 14 19:40:56 2022 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 D681E1AD8DAB for ; Sat, 14 May 2022 19:41:14 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0wqZ07c1z3wKG for ; Sat, 14 May 2022 19:41:13 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd35.google.com with SMTP id z26so12141733iot.8 for ; Sat, 14 May 2022 12:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yt+1SqoRFww3UBd3URAUnB9cjKwKNyQxJu/h/kD2fmg=; b=TG4Lx1Oah+SGYkwhgxhThGnJJsWJuRwPVymvD3FNbaTlX12YGziOm5Jxze1JbZq2Uf b6K5klfifjS54rCmxX3o2GGnc/JYCPXyyUppdhnNsO5IT1uET+oPBwb0sje0hpjrS1eU a5M+oZvl9TR4t/BG6q4xmWl66nvJI2OZp6GlXfDcm1dbcDkZm9u/9ISAfdrDYIgJa7hJ ejGdC1+kPrQBHdQaWgiVevN7ZMwJ0UTfjjOhVonE8Hm3fqomZFHTBU5Xun5LiOXKcTI/ Qv9/atC8id43TyjxWj1NfAZS4+PHDgxnYs7h7dZJKBOAymPHu/jOqZwvTZalRd2XfDBe zYPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Yt+1SqoRFww3UBd3URAUnB9cjKwKNyQxJu/h/kD2fmg=; b=4ZFGLKmJhqVkgTUfPoFcpeb5ekk8N+tlnNtE/wcvfRk4Kix6dzRlFWyWGOIhWmDn8s PXNaflIVCRXmfd/IZAnF91yNAm+1Ts0hd7zWVIwskLQ945rq0krSbnpV5wyK++mfWVBW 0TyUzbTm2SpmR4hi1O2HfALxUQzID1IK9V/OxHNuhVxmZse4p5ie6tdPIXdnAriGURU/ HcAfxsPH+pqXIpUDVPnS2UskGOF7uZ/DTPSbdKA0saCj/GcIS7Du5tSCDfExBU69jp5C gQWvQgZi7BmaJ9DbuYqCvPRL+PENT+W+Mf4Tvd3bblSlE4JmDLtMlalvsbvRhkwr7UZf StwQ== X-Gm-Message-State: AOAM530+2ygNK/uA4JEGFlBTqcxJqtPJEweVDFwP65k8dPIZG+J3TQlH oKBligQXbIr39D+pJ5wXUlQvShka8Sw+JFLngbd8CnMCpO+q7fMT X-Google-Smtp-Source: ABdhPJwviV6KmlklvjWS23h0kOhgLmP9WaubjDevHw9hRZ/jYFMNPtxeuJsd69jaOkfUm1R/pdQw0b4iMVj2d03sFxo= X-Received: by 2002:a05:6638:4195:b0:32b:e68b:237a with SMTP id az21-20020a056638419500b0032be68b237amr5581502jab.269.1652557267270; Sat, 14 May 2022 12:41: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 References: <481e0739-bdc4-4ce6-a856-a80cf5294d03@www.fastmail.com> <5fff8840-6f1e-4edd-8ddf-2728227c8818@www.fastmail.com> <3bcf856c-c048-4b4d-adfc-c6ba352e3b20@www.fastmail.com> In-Reply-To: <3bcf856c-c048-4b4d-adfc-c6ba352e3b20@www.fastmail.com> From: Michael Schuster Date: Sat, 14 May 2022 21:40:56 +0200 Message-ID: Subject: Re: FreeBSD, boot environments and /dev To: Dave Cottlehuber Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4L0wqZ07c1z3wKG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=TG4Lx1Oa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::d35 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d35:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-0.99)[-0.991]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Thu, May 12, 2022 at 9:21 AM Dave Cottlehuber wrote: > > On Thu, 12 May 2022, at 07:12, Michael Schuster wrote: > > On Wed, May 11, 2022 at 11:38 PM Dave Cottlehuber wrote: > >> On Wed, 11 May 2022, at 14:58, Michael Schuster wrote: > >> > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only > >> > regular files and empty directories). Booting into that BE didn't work > >> > either, I got errors about missing "/dev/" files (can't recall the > >> > exact names). > >> > > >> > What do you guys (plural ;-)) think? > > > > Hi Dave, > > thx for your perseverance :-) > > > > I have (at least) one question for you before I attempt this: > > where do I get these .txz files? > > https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/ > https://download.freebsd.org/ftp/releases/amd64/amd64/13.1-RC6/ > > > should devfs be in /etc/fstab? in my current BE, it isn't ... > > this is the bare minimum I used. NB my partitions have artisanal > GPT labels, yours will probably be different. > > # Device Mountpoint FStype Options Dump Pass# > #/dev/gpt/swap0 none swap sw 0 0 > /dev/gpt/efiboot /boot/efi msdosfs rw,late,longnames 0 0 > tmpfs /tmp tmpfs rw,mode=01777,size=120g 0 0 > > thats all I needed to boot to userland & login. I'm reasonably sure that, > assuming you have a default zfs install, you'd not need anything in /etc/fstab > to boot. > > > if so: do you have an example of such a line? In the instances I looked > > up, I wasn't quite able to make it work (but perhaps that's a dead end > > anyway). > > > >> # bectl activate -t vanilla > > > > does that ("activate -t") work on UEFI systems? The last time I used it > > (at least a year ago), it wasn't. > > Yes it does here. failing that just use `bectl activate`. The -t is > a very nice addition. > > Well, we're definitely on the FreeBSD-current email list here, so it's > definitely in CURRENT, and 13.1 RC. Dave, all: findings: 1) temporary activation doesn't work for me: bectl accepts the option but there's no effect I noticed(*), beadm refuses the option. 2) booting into 'vanilla' worked - I got into a root shell on the console. Since I copied the files you mention (/etc/fstab /etc/rc.conf /boot/loader.conf) unchanged, that looks good. so ... this is probably a good starting point (again ;-)). I rebooted into the last "good" BE, mounted vanilla a clone of vanilla on /mnt (with vanilla a point to start again if anything goes wrong) and started with "pkg -r /mnt install pkg" ... but I admit it's getting late today, so I'll be lazy and ask if you have any further recommendations - I've come to expect them to work nicely :-) (and yes, I am grateful!) *) unless the first BE to be shown when I select 'boot environments' at boot isn't in fact the active one cheers Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From nobody Sat May 14 20:30:25 2022 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 74FFC1AE50D9 for ; Sat, 14 May 2022 20:30:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0xwb42wyz4bcF for ; Sat, 14 May 2022 20:30:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652560231; bh=4wEThtbAFZCv3HYT7vCWZWegLksW3AHv5lP9MoxARmo=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=qgIDpBDYRV/vXXTe9t48AeoImTsBN6T09N7Ej/XhKVvScGZsailcDL3CCRn/GV29d5qbt06lZ2M98moXQMi7L62GUMHKA9WnJoHjMYLIYGJgaJ9PIP990G+yAAscftCvpd+bUJds7JWUW5+bH6fMXZpq7rbuTJB2zn4L9sbsFfSiv3Yl2VWFH4GB+1T4yxxyASptyT41/G+4jaUZBcp1wsI5Q53Va6eQgC1z4wmuf8urGn03A6pgcUW1CzDw2uFweGKAdnJ6/trY/Q16lkBoNKAiiYq8CiBO8rg14+zFGdyx6vB1Z+DtgP6PevtJj0xIHWZUSgEH0aaNY9aPeuA7Nw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652560231; bh=xHRCtVIyoXl6PvE8FjgHNqxVeEeYngtSI4H+sT+9tFN=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=eKF/jVKF20QoYLoE2L/PnS0Gy/+lA5rrll/TygRGzn67y92Dixb+KzEGEBQBENdMybfux6uHT/ykBJCy0LDVoLMsz+PAqba4EkpkX4EIbSZfhCuOplsQGacEnfF0ZiNoq4lFUgczfNMogJW0/XliedchCLj6lZWV3H0urQBMFKWtvHUJC7H9DYs5YRVnyZgEwxTyALBVWncDc+U3rD0Z6/51Rtrzi75CvZgIgnTgQVzU5EM1QSDripIdYYfKNbOdhb9AMZDRfiVm/kWs49FbtADFWZc8I7o1yUuF/MgB4qd/LQhL1+yLDeDQ1EyvNqs1TeW9gP0Mw7t6ADLvC56eVQ== X-YMail-OSG: RkaEFBkVM1ljN0gYmQn.uIMPq52RSW.O9DslaFOKzcAZKmHh1Nv6G02883Pqnry ICJdoPwhz72pJsKVwcz9_F8TlF0plpOh96xv9FkT6TLMTbsDEV0Kjuh06OfWECuZ1y7TLc7OHcpE fm.8Xys7P3vfnE4aTJk3uNUApzs8dCekqWgCzbJpC5alnatmMGSSYM2FIc7KQhFZ9uDOJWF3XLMO DErCmvV8PkeuAbhdkRWpB4Wa2MqSyOwlHq006LXq.ZdAZOPhSIBE1d00NlhQ4RlaINwJa.XmEeF9 s2RuTN.zZa8BmZP9BRLhQwkhBA1stQ7CqsR3JRWMf8GYdbQw9EOtNeHuxfP_hgMXK0z0G4EFBUtY esqjLbUVNpMf.8OJRd3AfWzFBkfuyJ8N5OOlrTKny1wedjnwhct4wghv9ewBC0qMIt_Mvoty5dEJ hajBj.npdhJNbrWBtX.nVnekp7X_l5Q5BFx0mzVmHFt8OTReMi7B9MxM7eoOQcovdLP4xheiS8xX t9E4CCMvilPLXtbu4frMET9_Fsc.UIannEdiqXCkzc8RIvmmA21K6mdykwVMtIB_mhOyBb53EVOn twqHQJkJS_mXte5UL6WJd8Om.HYYZZMA0mQAi.Z7Km4qQ_smcl0zANkaq.HbohyP1Kuo4Zj5.zW5 5TEwIMH54ej37VwUY19F0JN38vcLgqw_8.R2aw3r.JsBOhbFX_yTXJyvK8wi6Oa8TCeQ3REFPvr1 IbzZxyiPZsMCWJLDz4M2qPiS1x12zzd5_Hg3efmKI0JrUwyy36UpGUkQNYRa52ZvrM98GZDij5qK H58W08NNHa7DWT0XwVB.9Kwru4jMm9tX8UAMBHXcy04V1KQooOBllm3P32NNE7yJs2urzWk3w_55 9.DBhsBAlioq7AVDUiM8YUVvTQQHuFjOrILbR.Cc5_upaoIpVVeaFhxE9UCD0mzwsqDRysw5S.VK XBhSc4lTUx.wNKqXC0frIVDXz7ad1h3GW.ovI_YMbH7eH9Mk.Sox0S9WyIchTSqgmaUGYWTYzPvs rcAqyTsYgmJMYDZDCh6DnnPYK3uIoZ84YWhldKAchi9.d9TCn9g4Gw3ixse16V5WjuVGATyGvXjX .KUggzWAcUQHA0YxKcVOy8yD7ySck5v4l1UZ8v.t__L2jvlGJazuF3S1jz5J9YUVXUt4hAHxYENn 1qBgopRCR2mfV5B427ZwfGQL2j_8pGLm_csRjP_RtPwRSL2AZq3yvpbFO9iDBBNbkR.QkRD1uk3_ MPq10g0xX6JMJxMU7cJaLQkJzwTo.cntdpuBkOnFfGQ_600h6U8fykm7MudtLWaZR4ExQEX55oDs pqKL8B3lfSgyQEs9Omdte3yirqpUkFMiNfi0NbuEhPFpqhFj7HiRxjPKuoTga9LxA9UfmJW4VxJq XGjOM4_AFUv90ec.hOw_liPF9d2TD6WFF6CzOe9g7QNjInTUXdtVS7PSsXAD5QvmNGxvTaUvpS6x oi8lhrjs6WY31Kr4NN6QB7ezC0tnVg_tl_FK4M1m3DFpt9VuFOE3aWgZ1K02BhJ5tnrlV20T2.3G Y.jSNVpa4bu0Iyy3sgELVZ6nqDJrVMpzei.8LCGTellE3K9Wn86tn3_Ys9kqRK4eRqISgPnGRe9R EuROUN7__4sBK0loJK35TOQVrfaUfrBTBUW_oQuifZ.XO4BH3E61xqlJflKWj6y5NQqqyuYHjL4T H9j4MiROuXBM184FNPtehzR5kOB_18KwwmJdrZAt5dz01XFV2qz6YkhTlT89Se2Im8EEv0aDzz1Q dylM3GV5m7bezLQsPkeVW8Nn.vtSsus73jdjtmDTjXhItitoc3q_G8djF.eYKXgBJSsSrC0Kj18M ORzoVu3tPCuPKinqsRkQCgeXTn.xFTBJEr0tqJqFQcbe6UpHBK2TelT1T_BEHQ7IPzc5VCRZqT3. LMMxsb7khNgmROGSH0s5fXStkOGjLGi_OmswVUDjB0rgRD1YpVAW_15uL_k1eZJiJAxvENb7V.9f ytUk4LQ3haR1sfpZV1w7DqSKE3fOguSOTjR16GnlEc1Tl6UKwz1eWH8lrIBEKSOxWsRfK7N1nHs3 0NTKNIgdLN07TCWpaVIos41jHatOVDrxfy9jJwbuhtks1m3kzHpo4Mnzm0VtS5nGEZ1uJFLwQ2n7 MMoIzf7N3WlKR3t7ABiK1LpRhnXUpoCJ7kmAL.yjatrM8afzbt3FKt_O8xxa_Us7u_MD_AxddZU3 mftpRBAFNC97ifTKzcBcVuBkgfPKgNBXiHtW2c1zXWh2e8smZ947rogUhc9_S_kVrzzPXfdI.zD4 XRl2ODAeN X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 14 May 2022 20:30:31 +0000 Received: by hermes--canary-production-ne1-8676f67b88-d48nl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6c84eb5a978692e6dc330064934123d9; Sat, 14 May 2022 20:30:28 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: FreeBSD, boot environments and /dev Message-Id: Date: Sat, 14 May 2022 13:30:25 -0700 To: michaelsprivate@gmail.com, freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4L0xwb42wyz4bcF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qgIDpBDY; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Michael Schuster wrote on Date: Sat, 14 May 2022 21:40:56 +0200 : > findings: > 1) temporary activation doesn't work for me: bectl accepts the option > but there's no effect I noticed(*), beadm refuses the option. > . . . > *) unless the first BE to be shown when I select 'boot environments' > at boot isn't in fact the active one Do not implicitly take control of what boots by that selection: Instead just let it default through every stage, not looking around first. Look after booting, not before. I expect that you will find the temporary activation worked just fine, as it always has for me: UEFI/ACPI booting of a ThreadRipper 1950X, for example. After establishing the behavior for that, one can figure out how to see what will boot at an earlier stage if needed (and if possible), not that I've bothered. What I have done on occasion is to deliberately select something other than what I'd set as a temporary default when I changed my mind for some reason after starting the reboot that would otherwise have lead to the temporary activation's boot. And, yes, temporary activation is specific to the newer bectl. As I remember, that agrees with the documentation for them. === Mark Millard marklmi at yahoo.com From nobody Sun May 15 14:31:23 2022 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 77DEC1AE05E1 for ; Sun, 15 May 2022 14:31:41 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L1Pvw3c7hz4nvV for ; Sun, 15 May 2022 14:31:40 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd33.google.com with SMTP id f4so13565697iov.2 for ; Sun, 15 May 2022 07:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bQPi4H9E+BMbvjxeSrxmzoEu1lHKnNlYnbsz7pqXbXk=; b=DNdoWV+1oRv4tzFRUwzHi8YAvSeXzFFf46vwE1ACtz7E3Qi878DrnwxB9uXqoL/mF0 JXaJSvaTQYBFInI4zIImlcpTI0S9whKRsavN0OZI+1OgaSJxkDVTDRzRJfHBJOl8/Xme w+Mni5q04SxnErSGiVhOmhuaAXWYTC+IxWcsMMujyYfCHcHOcSCF4OBq34cQTbmH4jHu ZIA/bSAJUJdYQ4KKEiKLc0o2cm1lh6xFhkuxJYcL9wYmUkakMsVq6lDrjxTAhjdx1vMS lJD7idJl3pE/rRjFcaz5NyTGDCVMGhYlh3uzCdWwB47tHGb0FGHMBeNYFxugRjXEoO8U 22NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bQPi4H9E+BMbvjxeSrxmzoEu1lHKnNlYnbsz7pqXbXk=; b=byYzqajPz32s7RIXI63sV+DqldoKpfk98iz6PCD0yJiFT3IAt/1iTRlRjdpli4p9zC HKepSbePexSjzH1OlDKEbSLCRupTrBAaidLi0IyFRh6ow74rjlngbECTw4PaYwm4OGrc 5k6ZgnVE6GnLJaMD7u6SQOEgUgonejsb+uly3aK3jJD1RWE2WtifFth72zcUIS3NiBp5 W3XtoWNxFx8S4JmIVuylCYzeZQWYRfSZfUjqa4+cWlLlfU97kWcN0aKkRxAK+aVL+yVd 8esJW0AYXPMfO1D13wi72zXYyj8r3WT8Co+n2pra8mC4Fl8Xo5cfQo9s5kBI+eP0V8ry rqow== X-Gm-Message-State: AOAM533jvryHdKz9JhZN9wdxTauaFjhbsJw+6E1SOk5rYT91V97LV7ML GbivZSZfSWh4RitugpnLjTVLgMOp9UL5qmnd9ea9E0ZptVCm/w== X-Google-Smtp-Source: ABdhPJyvxVZSA8DRCvkkFOCVpccP7r4flh+v4+M6GD+SFpNBmjy9oedFexCEV4rHZ802nBafTmQA32oN6FRSH84a1QA= X-Received: by 2002:a05:6638:3896:b0:32b:95e2:cb81 with SMTP id b22-20020a056638389600b0032b95e2cb81mr7076134jav.78.1652625094365; Sun, 15 May 2022 07:31:34 -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: Michael Schuster Date: Sun, 15 May 2022 16:31:23 +0200 Message-ID: Subject: Re: FreeBSD, boot environments and /dev To: Mark Millard Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4L1Pvw3c7hz4nvV X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=DNdoWV+1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::d33 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-2.51 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.49)[0.486]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d33:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, May 14, 2022 at 10:30 PM Mark Millard wrote: > > Michael Schuster wrote on > Date: Sat, 14 May 2022 21:40:56 +0200 : > > > findings: > > 1) temporary activation doesn't work for me: bectl accepts the option > > but there's no effect I noticed(*), beadm refuses the option. > > . . . > > *) unless the first BE to be shown when I select 'boot environments' > > at boot isn't in fact the active one [...] > > I expect that you will find the temporary activation worked just > fine, as it always has for me: you are right - it did! thanks for the advice (a bit surprising, but who am I to judge ;-)) cheers -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From nobody Wed May 18 06:49:55 2022 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 D3B1C1AE5518 for ; Wed, 18 May 2022 06:49:37 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 4L33WP0R40z4kL1 for ; Wed, 18 May 2022 06:49:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (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 phk.freebsd.dk (Postfix) with ESMTPS id 47EA88929D for ; Wed, 18 May 2022 06:49:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 24I6ntaA095762 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 18 May 2022 06:49:55 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 24I6ntQZ095761; Wed, 18 May 2022 06:49:55 GMT (envelope-from phk) Message-Id: <202205180649.24I6ntQZ095761@critter.freebsd.dk> To: current@freebsd.org Subject: RockPRO64 exception 22 esr_el1 8a000000 From: Poul-Henning Kamp 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-ID: <95759.1652856595.1@critter.freebsd.dk> Date: Wed, 18 May 2022 06:49:55 +0000 X-Rspamd-Queue-Id: 4L33WP0R40z4kL1 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.03 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_SPAM_SHORT(0.97)[0.973]; DMARC_NA(0.00)[freebsd.dk]; MLMMJ_DEST(0.00)[current]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N With GENERIC-NODEBUG 14.0-CURRENT #10 main-n255667-9b88ecd674a I reproducibly get: panic: Unknown kernel exception 22 esr_el1 8a000000 Happens in: ip_output() at ip_output+0x9a4 udp_send() at udp_send+0xb5c sosend_dgram() at sosend_dgram+0x4a4 [...] As I understand it, that is in "undefined instruction" territory, so it could be anything from LLVM over compiler flags to kernel ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Wed May 18 12:45:18 2022 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 400AC1ADABA9 for ; Wed, 18 May 2022 12:45:31 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L3CQ22QvHz4TqF for ; Wed, 18 May 2022 12:45:30 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x133.google.com with SMTP id s14so1366793ild.6 for ; Wed, 18 May 2022 05:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UnL2moNKUmqKSPd5WTh4KsrWtiyuchbx8/1/waJBYaI=; b=l6a5oUYfChwQLLglZxzPBdzCmGUWwUnNPYx68DycjKlxng90//mToZm9Oa+nhn8CEE wl+ZuB+uDfILQ3K7pQBCorwF4aY7bilDwAJwnltB7X4+UqTa/l6YPN5NQJUriQiesiD2 okmJBcTjfzSe/AsB4IyzhWUUKq9v+eaaO2dyeVC19/+fSTMLUO1SpYMpnQ9tAWGetkpV i/wNZg4kDVOYkooGwlm7NPen05i4Tob008/he19DMSEEYlgylQWePo5wBPHpBwM37KVx mqWilWzPdLdrfywVHZH9blr7ahQHDNRIqK67weuI7/NI6TxK7BN2Svdc9LwYd1xyLqnH mS9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UnL2moNKUmqKSPd5WTh4KsrWtiyuchbx8/1/waJBYaI=; b=Cz9LgpiE/kArt7ILbqFVMfA0ORo7m81IHUwDVUuoze7WZZ7lkUQZSaOqoHk73ZTiE1 UMjBfHqcLeGwvgEKlYn96kQAGEjsf13Oj9Yxd9N2TXAO2x3HntuNWNqj2G3qRDPHdN7A 2qymfAMuBgTawlKc1iaFqvHjjuz9Rd6oDEO8hcDLk4aZwF+D6u9LYV1l4r5orf5dFGuS osiFC25AnznKAON/4HCFZzJfuQTFOGDpFui/0Xv6HKgOXtJKXdhaMeDGHI7LOQZzEZjV 4VYblRnYum2zu48zB1hR9LMGGkM6VF6/H0fqSF1Qz2+suypqfY0BwXw45aGRobFLo2/1 pQpA== X-Gm-Message-State: AOAM532l7FNX1LzYKVN+3u5sWIjisz/e6I11wt3uOuFEiv5oDIh3hUmj 6SouY+ouAg15IEmtxnnoB3IQCnrVxRWDWLatO6BMm/Gl4PwgZA== X-Google-Smtp-Source: ABdhPJyYRBHNOgYAU4SVjUTPWyjJmr/wfOneEiByaBP5EIyqWWXd2UrUBUyDcreYwALIxuu1DSyGoRDoLp5ZuL1YH0U= X-Received: by 2002:a05:6e02:5a2:b0:2cf:8e6e:a5ab with SMTP id k2-20020a056e0205a200b002cf8e6ea5abmr14390575ils.63.1652877929445; Wed, 18 May 2022 05:45:29 -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: <481e0739-bdc4-4ce6-a856-a80cf5294d03@www.fastmail.com> <5fff8840-6f1e-4edd-8ddf-2728227c8818@www.fastmail.com> <3bcf856c-c048-4b4d-adfc-c6ba352e3b20@www.fastmail.com> In-Reply-To: From: Michael Schuster Date: Wed, 18 May 2022 14:45:18 +0200 Message-ID: Subject: Re: FreeBSD, boot environments and /dev To: Dave Cottlehuber Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4L3CQ22QvHz4TqF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=l6a5oUYf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::133 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.53)[-0.526]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::133:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Sat, May 14, 2022, 21:40 Michael Schuster wrote: > > On Thu, May 12, 2022 at 9:21 AM Dave Cottlehuber wrote: > > > > On Thu, 12 May 2022, at 07:12, Michael Schuster wrote: > > > On Wed, May 11, 2022 at 11:38 PM Dave Cottlehuber wrote: > > >> On Wed, 11 May 2022, at 14:58, Michael Schuster wrote: > > >> > I then created a new BE, mounted it on /mnt, removed /mnt/dev/* (only > > >> > regular files and empty directories). Booting into that BE didn't work > > >> > either, I got errors about missing "/dev/" files (can't recall the > > >> > exact names). > > >> > > > >> > What do you guys (plural ;-)) think? > > > > > > Hi Dave, > > > thx for your perseverance :-) > > > > > > I have (at least) one question for you before I attempt this: > > > where do I get these .txz files? > > > > https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/ > > https://download.freebsd.org/ftp/releases/amd64/amd64/13.1-RC6/ > > > > > should devfs be in /etc/fstab? in my current BE, it isn't ... > > > > this is the bare minimum I used. NB my partitions have artisanal > > GPT labels, yours will probably be different. > > > > # Device Mountpoint FStype Options Dump Pass# > > #/dev/gpt/swap0 none swap sw 0 0 > > /dev/gpt/efiboot /boot/efi msdosfs rw,late,longnames 0 0 > > tmpfs /tmp tmpfs rw,mode=01777,size=120g 0 0 > > > > thats all I needed to boot to userland & login. I'm reasonably sure that, > > assuming you have a default zfs install, you'd not need anything in /etc/fstab > > to boot. > > > > > if so: do you have an example of such a line? In the instances I looked > > > up, I wasn't quite able to make it work (but perhaps that's a dead end > > > anyway). > > > > > >> # bectl activate -t vanilla > > > > > > does that ("activate -t") work on UEFI systems? The last time I used it > > > (at least a year ago), it wasn't. > > > > Yes it does here. failing that just use `bectl activate`. The -t is > > a very nice addition. > > > > Well, we're definitely on the FreeBSD-current email list here, so it's > > definitely in CURRENT, and 13.1 RC. > > Dave, all: > > findings: > 1) temporary activation doesn't work for me: bectl accepts the option > but there's no effect I noticed(*), beadm refuses the option. update (answered in a different thread, but to keep this here too): temporary activation does in fact work, it's not reflected in the list of BEs presented at the boot menu I'm still working on a "full" installation of what I have on the running BE into the new one ("vanilla") - if you have any ideas, I welcome them :-) thx Michael > > 2) booting into 'vanilla' worked - I got into a root shell on the console. > > Since I copied the files you mention (/etc/fstab /etc/rc.conf > /boot/loader.conf) unchanged, that looks good. > > so ... this is probably a good starting point (again ;-)). > > I rebooted into the last "good" BE, mounted vanilla a clone of vanilla > on /mnt (with vanilla a point to start again if anything goes wrong) > and started with "pkg -r /mnt install pkg" ... > > but I admit it's getting late today, so I'll be lazy and ask if you > have any further recommendations - I've come to expect them to work > nicely :-) (and yes, I am grateful!) > > *) unless the first BE to be shown when I select 'boot environments' > at boot isn't in fact the active one > From nobody Thu May 19 06:26:24 2022 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 5F62E1AEE004 for ; Thu, 19 May 2022 06:26:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 4L3fxg3CJPz4ZHP for ; Thu, 19 May 2022 06:25:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (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 phk.freebsd.dk (Postfix) with ESMTPS id B1CBC8929D for ; Thu, 19 May 2022 06:25:57 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 24J6QOc2000630 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 19 May 2022 06:26:24 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 24J6QOOe000629; Thu, 19 May 2022 06:26:24 GMT (envelope-from phk) Message-Id: <202205190626.24J6QOOe000629@critter.freebsd.dk> To: current@freebsd.org Subject: Re: RockPRO64 exception 22 esr_el1 8a000000 From: "Poul-Henning Kamp" 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-ID: <627.1652941584.1@critter.freebsd.dk> Date: Thu, 19 May 2022 06:26:24 +0000 X-Rspamd-Queue-Id: 4L3fxg3CJPz4ZHP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-2.00 / 15.00]; FAKE_REPLY(1.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I managed to capture the full console output this time: Fatal data abort: x0: 0 x1: 6 x2: 0 x3: 0 x4: 0 x5: ffffa000beeb9b98 x6: ff x7: ffffa00000c2e100 x8: ffffa000b79305a8 x9: 0 x10: 20000 x11: 0 x12: 0 x13: 0 x14: ffffa00000ce3700 x15: 0 x16: ffff0000e5cbfff8 (_DYNAMIC + 4a0) x17: ffff000000589828 (sosend + 0) x18: ffff0000e6707490 (ratelimit_v6 + a37280) x19: 0 x20: ffff0000e6707518 (ratelimit_v6 + a37308) x21: 0 x22: 0 x23: 14 x24: 40 x25: ffff0000e6707538 (ratelimit_v6 + a37328) x26: 0 x27: 0 x28: ffffa00081055d3c x29: ffff0000e6707490 (ratelimit_v6 + a37280) sp: ffff0000e6707490 lr: ffff000000657724 (fib4_lookup + 40) elr: 0 spsr: 60000045 far: 0 esr: 86000004 panic: vm_fault failed: 0 error 1 cpuid = 4 time = 1652940940 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 data_abort() at data_abort+0x2c4 handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0x86000004 (null)() at 0 ip_output() at ip_output+0x9a4 udp_send() at udp_send+0xb5c sosend_dgram() at sosend_dgram+0x4a4 sosend() at sosend+0x2c wg_send() at wg_send+0x108 wg_deliver_out() at wg_deliver_out+0x17c gtaskqueue_run_locked() at gtaskqueue_run_locked+0x17c gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x130 fork_exit() at fork_exit+0x88 fork_trampoline() at fork_trampoline+0x14 KDB: enter: panic [ thread pid 0 tid 100280 ] Stopped at kdb_enter+0x40: undefined f907827f db> Poul-Henning Kamp writes: > With GENERIC-NODEBUG 14.0-CURRENT #10 main-n255667-9b88ecd674a > > I reproducibly get: > > panic: Unknown kernel exception 22 esr_el1 8a000000 > > Happens in: > > ip_output() at ip_output+0x9a4 > udp_send() at udp_send+0xb5c > sosend_dgram() at sosend_dgram+0x4a4 > [...] > > As I understand it, that is in "undefined instruction" territory, > so it could be anything from LLVM over compiler flags to kernel ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Thu May 19 09:40:48 2022 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 772711AEEB0F for ; Thu, 19 May 2022 09:40:51 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4L3lGT56vrz531n for ; Thu, 19 May 2022 09:40:49 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtpclient.apple (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 438524E687; Thu, 19 May 2022 09:40:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1652953249; bh=UpND2TrfGv58S9ws7Ywr6uSobAsBB5vyJdisNOonF3E=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=rdr/Z1M3ael5iEhy2vxM1MuGJkBq5GTAfhfxQt3VytzRDz7/uDoEOxegfx0F1WpEx BI7swP4zir5KFfm7WQnJNkfxPpW9IN7IsmjDLQJTK+Cu6LvE2DdZEOT7WUDe3GLxUf rBRmpC162uy8j6jMsXBad6G8nalEesGcKIMsnBZCQpHxHgyVwZtUNgBH79SfCZ17O8 oaMT+ZzsNIF2ggz+/oDJckIJnZuW0aUcpZb9jNsAdXfocnU1/dK77v9R1qBxtk3vYY ChlRZ1I2Kjm6UkTgj6eyvDYllSHDtde1JYXaQWXr4L2hiSUFaqomf5Pe+w0FR131iS f8QfnHcCB9JAyixae6ssAOhinThXnQp8pSi4YmXRVyLX1u6C5FcfW6z8icYV2qdw7s DsgkX1Q3fvuCtsRFesjRD1wFhokOMLBuv+W+EvN0UiRSAh0m6uz+umcWF0D23iBMf6 89QPl85F1wJAfyy9SfZRQ+3rG1cIeeUC7MgBnocZRZbCRO91XC5iOFA4HoQC6NL4v9 b2VjZgmf3NjyLx5m8Gs2PHXSfGQX3aOD1ul7DqMxXCVBW/Jwdc/W8/OmY8EOniK5eQ NTmVpLE7jOTpYHf+hBNoa2tkVld0R2kRfmoPhDkQxXeh552wUJFOMnJp88/rgTzKDc JEzm4dNk8YjklUlgWdNA3vEc= 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 \(3696.80.82.1.1\)) Subject: Re: RockPRO64 exception 22 esr_el1 8a000000 From: Andrew Turner In-Reply-To: <202205190626.24J6QOOe000629@critter.freebsd.dk> Date: Thu, 19 May 2022 10:40:48 +0100 Cc: current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <202205190626.24J6QOOe000629@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4L3lGT56vrz531n X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fubar.geek.nz header.s=mail header.b="rdr/Z1M3"; dmarc=pass (policy=none) header.from=fubar.geek.nz; spf=pass (mx1.freebsd.org: domain of andrew@fubar.geek.nz designates 139.59.165.16 as permitted sender) smtp.mailfrom=andrew@fubar.geek.nz X-Spamd-Result: default: False [-3.38 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=mail]; FREEFALL_USER(0.00)[andrew]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[fubar.geek.nz:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; MLMMJ_DEST(0.00)[current]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 19 May 2022, at 07:26, Poul-Henning Kamp = wrote: >=20 > I managed to capture the full console output this time: >=20 > Fatal data abort: > x0: 0 > x1: 6 > x2: 0 > x3: 0 > x4: 0 > x5: ffffa000beeb9b98 > x6: ff > x7: ffffa00000c2e100 > x8: ffffa000b79305a8 > x9: 0 > x10: 20000 > x11: 0 > x12: 0 > x13: 0 > x14: ffffa00000ce3700 > x15: 0 > x16: ffff0000e5cbfff8 (_DYNAMIC + 4a0) > x17: ffff000000589828 (sosend + 0) > x18: ffff0000e6707490 (ratelimit_v6 + a37280) > x19: 0 > x20: ffff0000e6707518 (ratelimit_v6 + a37308) > x21: 0 > x22: 0 > x23: 14 > x24: 40 > x25: ffff0000e6707538 (ratelimit_v6 + a37328) > x26: 0 > x27: 0 > x28: ffffa00081055d3c > x29: ffff0000e6707490 (ratelimit_v6 + a37280) > sp: ffff0000e6707490 > lr: ffff000000657724 (fib4_lookup + 40) > elr: 0 > spsr: 60000045 > far: 0 > esr: 86000004 > panic: vm_fault failed: 0 error 1 > cpuid =3D 4 > time =3D 1652940940 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x174 > panic() at panic+0x44 > data_abort() at data_abort+0x2c4 > handle_el1h_sync() at handle_el1h_sync+0x10 > --- exception, esr 0x86000004 > (null)() at 0 > ip_output() at ip_output+0x9a4 > udp_send() at udp_send+0xb5c > sosend_dgram() at sosend_dgram+0x4a4 > sosend() at sosend+0x2c > wg_send() at wg_send+0x108 > wg_deliver_out() at wg_deliver_out+0x17c > gtaskqueue_run_locked() at gtaskqueue_run_locked+0x17c > gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x130 > fork_exit() at fork_exit+0x88 > fork_trampoline() at fork_trampoline+0x14 > KDB: enter: panic > [ thread pid 0 tid 100280 ] > Stopped at kdb_enter+0x40: undefined f907827f > db>=20 This looks like the kernel is jumping to a NULL pointer. Looking at fib4_lookup + 40 on a recent kernel leads me to believe the = issue is likely due to dp->f being invalid. Andrew= From nobody Fri May 20 08:38:50 2022 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 BEE1D1B37E25 for ; Fri, 20 May 2022 08:38:53 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4KrY16N0z3v1R for ; Fri, 20 May 2022 08:38:53 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-ej1-x62e.google.com with SMTP id n10so14302109ejk.5 for ; Fri, 20 May 2022 01:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:from :subject:content-transfer-encoding; bh=B4jvvoeAau7UwEe2nk5FPT7cT+5sJRXyLv7oTe8QE2E=; b=QB2leajsCLtpC/iNGWO41g9lQrWOdpwU8S2jk9piWFhzaDbdb+td+cQpBywDbPSuxS sOO5fcKQp2656HozFCfos+uHBHs34IeFrIiwSizJfcjqeb5H2DRlynXRzUmGZEdIrw0D 4s56MUXf3p/+jfQ9Lk3WkGbPUt+YhN6PZU5kLCEgMUpugeC3xG4TpjhXZoCoYlRpwXbB loSGqFuK57kbM/dN+QhFWXfe3QhpL49cJII6sRwcBpCVp7CX1MhiG4kt/q/Xb62vZk0D GwLmHeEZNgqK54Lvpi+IaalbVBdRvwFL4T7G1ydCFxHM8RINjGr+pGBiwwpckdmVSwfs +yFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:content-transfer-encoding; bh=B4jvvoeAau7UwEe2nk5FPT7cT+5sJRXyLv7oTe8QE2E=; b=E6ZtgYMFueKzv2SIO8h7Mpf5MnUe608EDF1dWM7m9R4+aug5Xm9xE9bFcH0d/8qu7M DmUKdlsgU2ikbWeu8uDdP4TAQJwo+jTVSBDrpPQ7drQe3QzG+dSjpITiqMxqrgn22XYN UwgE3tziXw3l2rfFewikmvHeQBRRJfQZ5leQt3ApF2nX/OqAhMgTT+nRq1qGwWVrFj2M BI5oWp1Isv6EzYmZQ49serngy1eKwgksaAY2ID/Pc3z0PuIyYygGvt+jW1+mzyWWI24e gteNGlWiS9m5jw1TlaqsrcnwOgl9YjyJd6whyypvsGyShmwtpmAR/lEb3b/Dji5lFRjg Uf7A== X-Gm-Message-State: AOAM530jgw1yqizzeBwiIWq6fjOzkCaBHY49l8UTmQ75woUb04zwCaRi d6iah+uSdoZJrmw0fidzG2fQpyPdFwY= X-Google-Smtp-Source: ABdhPJwdnSh35sRYEBmJVaeKRHaiYWVEHaENo51NV7u5D/2/JVVxkn8OzWQLvrYj1jUMbVNF2T0p+g== X-Received: by 2002:a17:907:9615:b0:6f4:92ab:4fce with SMTP id gb21-20020a170907961500b006f492ab4fcemr7904562ejc.95.1653035931953; Fri, 20 May 2022 01:38:51 -0700 (PDT) Received: from [192.168.1.16] (85-147-130-226.cable.dynamic.v4.ziggo.nl. [85.147.130.226]) by smtp.gmail.com with ESMTPSA id ig1-20020a1709072e0100b006fe7b0e124esm2971476ejc.18.2022.05.20.01.38.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 May 2022 01:38:51 -0700 (PDT) Message-ID: <3f367b95-a418-f298-5fe2-972bf2bc1fd4@gmail.com> Date: Fri, 20 May 2022 10:38:50 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: FreeBSD Current From: Johan Hendriks Subject: Zpool with latest feature com.delpfix:head_errlog can not be booted from. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L4KrY16N0z3v1R X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=QB2leajs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of johhendriks@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=johhendriks@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from]; MLMMJ_DEST(0.00)[freebsd-current]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I did upgrade my FreeBSD Current and with that i updated my storage pool and my zroot pool. I did add the new gptboot code on the disk. After the reboot i can not boot anymore. So i did reinstall the os on one disk of the old zroot mirror pool and did leave the second untouched. Then i can import the pools. If i boot with the latest snapshot ISO (FreeBSD-14.0-CURRENT-amd64-20220519-716fd348e01-255696-disc1.iso) i see the following when i boot. BIOS drive A: is fd0 BIOS drive B: is fd1 BIOS drive K: is disk9 ZFS: unsupported feature: com.delpfix:head_errlog ZFS: pool zroot is not supported ZFS: unsupported feature: com.delpfix:head_errlog ZFS: pool storage is not supported BIOS 624kB/2000420kB available memory Then the OS is loaded, if i then go to the shell of the installer and do a zpool import, ik can import the pool zroot and storage. So this snapshot has the latest ZFS version with the com.delpfix:head_errlog feature. So it looks like the bootloader is not able to use the new feature and thus renders your system unbootable. regards Johan From nobody Fri May 20 09:47:29 2022 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 732521B45E48 for ; Fri, 20 May 2022 09:47:45 +0000 (UTC) (envelope-from tsoome@me.com) Received: from ci74p00im-qukt09081901.me.com (ci74p00im-qukt09081901.me.com [17.57.156.8]) (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 4L4MN05TDKz4Zd7 for ; Fri, 20 May 2022 09:47:44 +0000 (UTC) (envelope-from tsoome@me.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1653040054; bh=H7++FtlSHcEgo02XjD5XnmXx0hbSZmEbYeksQfPNF6E=; h=Content-Type:From:Mime-Version:Subject:Date:Message-Id:To; b=EeasC8uHfjBVuOCiB0s3S1qHsD3lnXnqaW3HFomdo4IqkjR59Hrg6eyK6uV+/ezvp QAj2+tgOfzhLOeiUjHQmESqtiu6JgkbZ+HvnGGEHGR3hFVxxu8cDuHU1ybSQ2GfwVx s+nsKGC9AzUsFTl+VHx7kpNdIfQ7xZ7VZwr/ODvfatx38cAGIIZo6iTrVVpKCm3lPR nn8qhx6xO1aBNd/0lg0HfCWYvan7deF4gr2DK/egmD/StJ9aCCo3Wi5OuOHBpTOizL Yi+Uo9xlEX1hrHenEMO9IVaVMgMNv/xpL4yPBn9YTswsUjk7UT2Atli3g/XiFibJ8S 4pLZ1krOSXMeQ== Received: from smtpclient.apple (ci77p00im-dlb-asmtp-mailmevip.me.com [17.57.156.26]) by ci74p00im-qukt09081901.me.com (Postfix) with ESMTPSA id 3B0485AC059E; Fri, 20 May 2022 09:47:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Toomas Soome 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 (1.0) Subject: Re: Zpool with latest feature com.delpfix:head_errlog can not be booted from. Date: Fri, 20 May 2022 12:47:29 +0300 Message-Id: References: <3f367b95-a418-f298-5fe2-972bf2bc1fd4@gmail.com> Cc: FreeBSD Current In-Reply-To: <3f367b95-a418-f298-5fe2-972bf2bc1fd4@gmail.com> To: Johan Hendriks X-Mailer: iPhone Mail (19E258) X-Proofpoint-GUID: FgmNQcULMdNX8KktL-1h0gxDnz7wSdGI X-Proofpoint-ORIG-GUID: FgmNQcULMdNX8KktL-1h0gxDnz7wSdGI X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.572,17.11.62.513.0000000_definitions?= =?UTF-8?Q?=3D2020-02-14=5F11:2020-02-14=5F02,2020-02-14=5F11,2021-12-02?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 clxscore=1015 adultscore=0 phishscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205200071 X-Rspamd-Queue-Id: 4L4MN05TDKz4Zd7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=EeasC8uH; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.57.156.8 as permitted sender) smtp.mailfrom=tsoome@me.com X-Spamd-Result: default: False [-3.57 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:17.57.156.0/24]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[me.com]; ASN(0.00)[asn:714, ipnet:17.57.156.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[17.57.156.8:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; NEURAL_HAM_LONG(-0.97)[-0.968]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[17.57.156.8:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I=E2=80=99ll see into it. It would be nice to have at least heads up message= about such features, or zfs code does have means to block feature upgrade o= n boot pool. Rgds, Toomas > On 20. May 2022, at 11:39, Johan Hendriks wrote: >=20 > =EF=BB=BFI did upgrade my FreeBSD Current and with that i updated my stora= ge pool and my zroot pool. > I did add the new gptboot code on the disk. After the reboot i can not boo= t anymore. >=20 > So i did reinstall the os on one disk of the old zroot mirror pool and did= leave the second untouched. >=20 > Then i can import the pools. > If i boot with the latest snapshot ISO (FreeBSD-14.0-CURRENT-amd64-2022051= 9-716fd348e01-255696-disc1.iso) i see the following when i boot. >=20 > BIOS drive A: is fd0 > BIOS drive B: is fd1 > > BIOS drive K: is disk9 > ZFS: unsupported feature: com.delpfix:head_errlog > ZFS: pool zroot is not supported > ZFS: unsupported feature: com.delpfix:head_errlog > ZFS: pool storage is not supported > BIOS 624kB/2000420kB available memory >=20 > Then the OS is loaded, if i then go to the shell of the installer and do a= zpool import, ik can import the pool zroot and storage. So this snapshot ha= s the latest ZFS version with the com.delpfix:head_errlog feature. So it loo= ks like the bootloader is not able to use the new feature and thus renders y= our system unbootable. >=20 > regards > Johan >=20 >=20 From nobody Fri May 20 17:00:34 2022 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 024041AEEAEA for ; Fri, 20 May 2022 17:00:46 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4Xzd1zBDz4byw for ; Fri, 20 May 2022 17:00:45 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3C9418D4A129 for ; Fri, 20 May 2022 17:00:37 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B2A33E707CA for ; Fri, 20 May 2022 17:00:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id CfNYiAkZd7Q5 for ; Fri, 20 May 2022 17:00:35 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 906F9E707AE for ; Fri, 20 May 2022 17:00:35 +0000 (UTC) Date: Fri, 20 May 2022 17:00:34 +0000 (UTC) From: "Bjoern A. Zeeb" To: current@freebsd.org Subject: loader_4th.efi broke? Message-ID: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4L4Xzd1zBDz4byw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-1.63 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.33)[-0.330]; MLMMJ_DEST(0.00)[current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, something between 255692.f70de61e567df59bceb2d18c8bc1b54943a7466b and 255723.b3fa36efe797445cb0b4fd26d79226836db2a2b3 made loader_4th.efi go all "failed to allocate staging area: 9" I am netbooting booting, no ZFS involved. One other data point: the base system compile may have changed in that time. I haven't dug into yet. Is anyone else seeing this? /bz -- Bjoern A. Zeeb r15:7 From nobody Fri May 20 17:05:40 2022 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 D108D1B30900 for ; Fri, 20 May 2022 17:05:56 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr85p00im-hyfv06021301.me.com (mr85p00im-hyfv06021301.me.com [17.58.23.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4Y5b5m5kz4dXG for ; Fri, 20 May 2022 17:05:55 +0000 (UTC) (envelope-from tsoome@me.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1653066349; bh=VBuvGyOcSvuJbVOQ0xtFBoGpxQHos1Tv60V6hcq/gWI=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=jCoUKLnGSRbiYoQ32VLgjLacLIoN6D1p1DQFNCvf/L/Khu/fB3nKjJYmx3yginKh9 hJnaT/tye6DXGqgf/4zNDqzh1zUrX94z3m2Jtrzb7jIT/ZyV4OYgfnN0wVTTGRknf9 /B7pyVQw4LShwzn3VG1jS4UDxa1x3GRcvX4DHWGaeviQ3vg5tCby5mevj/zf9YSI7K bSHUgq/ib5ZqlFxwliVyJFTSfhfhPv9NGIBKNtX4hhGZn9BUZa499XxS152LgZ5+Jw clR7W/M5sl8Nn66qNftg10fh0Vut9BUZBn7b7fHt9NRA0XNvi3kco/Wg4aRDMlz06W pi2iNVRLGW/wQ== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-hyfv06021301.me.com (Postfix) with ESMTPSA id 8043A2151101; Fri, 20 May 2022 17:05:47 +0000 (UTC) From: Toomas Soome Message-Id: <71D61E79-B3A5-49FA-9B9E-26E124A5B4EF@me.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2AEA816F-71DC-4E0C-A0F6-C154E06C6AD2" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: loader_4th.efi broke? Date: Fri, 20 May 2022 20:05:40 +0300 In-Reply-To: Cc: current@freebsd.org To: "Bjoern A. Zeeb" References: X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Proofpoint-GUID: RE913150qzFqEoU7bolYgSF73RKTqGS0 X-Proofpoint-ORIG-GUID: RE913150qzFqEoU7bolYgSF73RKTqGS0 X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.816,17.11.62.513.0000000_definitions?= =?UTF-8?Q?=3D2022-01-18=5F01:2020-02-14=5F02,2022-01-18=5F01,2021-12-02?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=840 malwarescore=0 mlxscore=0 adultscore=0 bulkscore=0 suspectscore=0 spamscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205200111 X-Rspamd-Queue-Id: 4L4Y5b5m5kz4dXG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=jCoUKLnG; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.23.188 as permitted sender) smtp.mailfrom=tsoome@me.com X-Spamd-Result: default: False [-2.29 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; DKIM_TRACE(0.00)[me.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-0.69)[-0.686]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.23.188:from]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[me.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_2AEA816F-71DC-4E0C-A0F6-C154E06C6AD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 20. May 2022, at 20:00, Bjoern A. Zeeb = wrote: >=20 > Hi, >=20 > something between > 255692.f70de61e567df59bceb2d18c8bc1b54943a7466b and > 255723.b3fa36efe797445cb0b4fd26d79226836db2a2b3 > made loader_4th.efi go all > "failed to allocate staging area: 9" >=20 > I am netbooting booting, no ZFS involved. > One other data point: the base system compile may have changed in that = time. >=20 > I haven't dug into yet. Is anyone else seeing this? >=20 > /bz >=20 > --=20 > Bjoern A. Zeeb = r15:7 >=20 staging area will be allocated very early, so for some reason either the = memory map is fragmented or there is just too low memory. 9 is EFI_OUT_OF_RESOURCES. rgds, toomas= --Apple-Mail=_2AEA816F-71DC-4E0C-A0F6-C154E06C6AD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 20. May 2022, at 20:00, Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> wrote:

Hi,
something between
= 255692.f70de61e567df59bceb2d18c8bc1b54943a7466b and
= 255723.b3fa36efe797445cb0b4fd26d79226836db2a2b3
made = loader_4th.efi go all
"failed to allocate staging area: = 9"

I am netbooting booting, no ZFS = involved.
One other data point: the base system compile = may have changed in that time.

I haven't = dug into yet.  Is anyone else seeing this?

/bz

--
Bjoern A. = Zeeb =             &n= bsp;           &nbs= p;            =             &n= bsp;  r15:7


staging area will be allocated very early, so for some reason = either the memory map is fragmented or there is just too low = memory.

9 = is EFI_OUT_OF_RESOURCES.

rgds,
toomas
= --Apple-Mail=_2AEA816F-71DC-4E0C-A0F6-C154E06C6AD2-- From nobody Fri May 20 17:09:02 2022 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 157CB1B31CF9 for ; Fri, 20 May 2022 17:09:13 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4Y9N2GcHz4fS7 for ; Fri, 20 May 2022 17:09:12 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id AF1D68D4A129; Fri, 20 May 2022 17:09:05 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 467EDE707CA; Fri, 20 May 2022 17:09:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id SQcpqit-8I97; Fri, 20 May 2022 17:09:03 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 1DB5CE707AE; Fri, 20 May 2022 17:09:03 +0000 (UTC) Date: Fri, 20 May 2022 17:09:02 +0000 (UTC) From: "Bjoern A. Zeeb" To: Graham Perrin cc: FreeBSD-CURRENT Subject: Re: EFI framebuffer information, then nothing: GENERIC-NODEBUG In-Reply-To: <32a85424-fb0d-c1e5-867b-e73f27388b9a@gmail.com> Message-ID: References: <32a85424-fb0d-c1e5-867b-e73f27388b9a@gmail.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1226734367-1653066543=:68830" X-Rspamd-Queue-Id: 4L4Y9N2GcHz4fS7 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [2.35 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131:c]; NEURAL_SPAM_SHORT(0.36)[0.360]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_SPAM_MEDIUM(0.97)[0.975]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; CTYPE_MIXED_BOGUS(1.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.31)[0.313]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1226734367-1653066543=:68830 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 14 May 2022, Graham Perrin wrote: > On 19/04/2022 23:37, Graham Perrin wrote: >> Sometimes, boot gets no further than EFI framebuffer information. Whenever >> this occurs, the computer will stop immediately in response to a simple, >> short press on the power button. … > > When I first wrote > , > I omitted a key point: I normally install GENERIC-NODEBUG. Is this similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256722 Something I found while booting my rpi3b+ using UEFI was that sometimes I had to set console="comconsole" in loader as "efi" seemed to hang. I don't think I ever dug into that. Worth a try? Would be another data point to narrow this down. -- Bjoern A. Zeeb r15:7 --0-1226734367-1653066543=:68830-- From nobody Fri May 20 17:11:23 2022 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 807E71B3294F for ; Fri, 20 May 2022 17:11:27 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4YCy6mTNz4gTX for ; Fri, 20 May 2022 17:11:26 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id ED0E88D4A178; Fri, 20 May 2022 17:11:25 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 89242E707CA; Fri, 20 May 2022 17:11:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id ZX3iU559MHyJ; Fri, 20 May 2022 17:11:24 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 50300E707AE; Fri, 20 May 2022 17:11:24 +0000 (UTC) Date: Fri, 20 May 2022 17:11:23 +0000 (UTC) From: "Bjoern A. Zeeb" To: Toomas Soome cc: current@freebsd.org Subject: Re: loader_4th.efi broke? In-Reply-To: <71D61E79-B3A5-49FA-9B9E-26E124A5B4EF@me.com> Message-ID: References: <71D61E79-B3A5-49FA-9B9E-26E124A5B4EF@me.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4L4YCy6mTNz4gTX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-0.45 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_SPAM_MEDIUM(0.30)[0.303]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.45)[-0.454]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current]; FREEMAIL_TO(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 20 May 2022, Toomas Soome wrote: >> On 20. May 2022, at 20:00, Bjoern A. Zeeb wrote: >> >> Hi, >> >> something between >> 255692.f70de61e567df59bceb2d18c8bc1b54943a7466b and >> 255723.b3fa36efe797445cb0b4fd26d79226836db2a2b3 >> made loader_4th.efi go all >> "failed to allocate staging area: 9" >> >> I am netbooting booting, no ZFS involved. >> One other data point: the base system compile may have changed in that time. >> >> I haven't dug into yet. Is anyone else seeing this? >> > > staging area will be allocated very early, so for some reason either the memory map is fragmented or there is just too low memory. > > 9 is EFI_OUT_OF_RESOURCES. The UEFI hasn't changed; 64GB of memory haven't changed. Power cycling didn't make a difference. Going back to the old one immediately worked again. I saw no changes in stand/ relevant. Is there a way to debug this or should we simply "stop" if this fails rather than endlessly fill the console with it? /bz -- Bjoern A. Zeeb r15:7 From nobody Fri May 20 17:19:58 2022 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 918981B35DDC for ; Fri, 20 May 2022 17:20:10 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-zteg10021301.me.com (pv50p00im-zteg10021301.me.com [17.58.6.46]) (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 4L4YQ15TZSz4kQB for ; Fri, 20 May 2022 17:20:09 +0000 (UTC) (envelope-from tsoome@me.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1653067203; bh=aLUyr0yczOHpWtV7WpuIdhF2YGlwk/Wx0UlmxBKrn6I=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=qet6qCL2puN0mhukUKz31HsSB4UPUUkgk+aKjOqQZLgeMuaKTB9cALi7mmUp7I0+A GgPXDHfRbUMJdzWeyspaFft0Gg+M/NeliApahJsLceevey/d6a20yLMecxuX+yG7wb KHV8EQnAP03ykmwo6TZtlPstgp0ISBH6HG8PD1AP15uWKwsSTtgX+jvCqH44AkT22o jFcQ/myBSDkNHvpEqxTRQSZ4rkRzVic+dv1SgqFY3SW8/IynCnCvJvo4pdgJkU35lJ KBl23UBUGJTKeOubUIn8rlFMvytbjbWyb269vduxDcb0ARucz0RGPun35no7tEdJxH ugp88iSJHoXHw== Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10]) by pv50p00im-zteg10021301.me.com (Postfix) with ESMTPSA id 8E2075004DB; Fri, 20 May 2022 17:20:01 +0000 (UTC) From: Toomas Soome Message-Id: <1BA529E5-064B-46A8-A412-3D7A66AD6D2F@me.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0C16D237-30DE-4FDC-BEB8-60E2C5F0ED0C" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: loader_4th.efi broke? Date: Fri, 20 May 2022 20:19:58 +0300 In-Reply-To: Cc: current@freebsd.org To: "Bjoern A. Zeeb" References: <71D61E79-B3A5-49FA-9B9E-26E124A5B4EF@me.com> X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.874 definitions=2022-05-20_05:2022-05-20,2022-05-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2009150000 definitions=main-2205200112 X-Rspamd-Queue-Id: 4L4YQ15TZSz4kQB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=qet6qCL2; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.46 as permitted sender) smtp.mailfrom=tsoome@me.com X-Spamd-Result: default: False [-2.14 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; DKIM_TRACE(0.00)[me.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-0.54)[-0.545]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.46:from]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[me.com]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.56.9.10:received]; MLMMJ_DEST(0.00)[current]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_0C16D237-30DE-4FDC-BEB8-60E2C5F0ED0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20. May 2022, at 20:11, Bjoern A. Zeeb = wrote: >=20 > On Fri, 20 May 2022, Toomas Soome wrote: >=20 >>> On 20. May 2022, at 20:00, Bjoern A. Zeeb = wrote: >>>=20 >>> Hi, >>>=20 >>> something between >>> 255692.f70de61e567df59bceb2d18c8bc1b54943a7466b and >>> 255723.b3fa36efe797445cb0b4fd26d79226836db2a2b3 >>> made loader_4th.efi go all >>> "failed to allocate staging area: 9" >>>=20 >>> I am netbooting booting, no ZFS involved. >>> One other data point: the base system compile may have changed in = that time. >>>=20 >>> I haven't dug into yet. Is anyone else seeing this? >>>=20 >>=20 >> staging area will be allocated very early, so for some reason either = the memory map is fragmented or there is just too low memory. >>=20 >> 9 is EFI_OUT_OF_RESOURCES. >=20 > The UEFI hasn't changed; 64GB of memory haven't changed. Power > cycling didn't make a difference. Going back to the old one > immediately worked again. I saw no changes in stand/ relevant. >=20 > Is there a way to debug this or should we simply "stop" if this fails > rather than endlessly fill the console with it? >=20 um, ok 64GB should be plenty;) of course, if the firmware is squashing = low memory map to small chunks, then there is problem (we are asking to = use low 4GB because of buggy firmwares=E2=80=A6), but you can try = loader_lua.efi. The other cause could be grown kernel modules - we try = to allocate 64MB staging area first, if it is not enough, then we try to = get larger chunk=E2=80=A6. Of course, screen spamming is bug, that should not happen.=20 rgds, toomas= --Apple-Mail=_0C16D237-30DE-4FDC-BEB8-60E2C5F0ED0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 20. May 2022, at 20:11, Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> wrote:

On Fri, 20 May 2022, Toomas Soome wrote:

On 20. May 2022, at = 20:00, Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> wrote:
Hi,

something between
= 255692.f70de61e567df59bceb2d18c8bc1b54943a7466b and
= 255723.b3fa36efe797445cb0b4fd26d79226836db2a2b3
made = loader_4th.efi go all
"failed to allocate staging area: = 9"

I am netbooting booting, no ZFS = involved.
One other data point: the base system compile = may have changed in that time.

I haven't = dug into yet. Is anyone else seeing this?


staging area will be allocated = very early, so for some reason either the memory map is fragmented or = there is just too low memory.

9 is = EFI_OUT_OF_RESOURCES.

The UEFI hasn't changed; 64GB of memory haven't changed. = Power
cycling = didn't make a difference. Going back to the old one
immediately = worked again. I saw no changes in stand/ relevant.

Is there a = way to debug this or should we simply "stop" if this fails
rather than = endlessly fill the console with it?


um, = ok 64GB should be plenty;) of course, if the firmware is squashing low = memory map to small chunks, then there is problem (we are asking to use = low 4GB because of buggy firmwares=E2=80=A6), but you can try = loader_lua.efi. The other cause could be grown kernel modules - we try = to allocate 64MB staging area first, if it is not enough, then we try to = get larger chunk=E2=80=A6.

Of = course, screen spamming is bug, that should not = happen. 

rgds,
toomas
= --Apple-Mail=_0C16D237-30DE-4FDC-BEB8-60E2C5F0ED0C-- From nobody Fri May 20 17:33:34 2022 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 1BF401B3A616 for ; Fri, 20 May 2022 17:33:41 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4Yjc03wsz4nmW for ; Fri, 20 May 2022 17:33:39 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1653068011; 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=mJYc3nPdPd/5rMP/sfJgBCKZW3FUIOylP5sD2ar3yDc=; b=pkWrBonj58mSmfCA461uOe8az0QaVv7x5KGkb2vaFK9xii5klbbZADtfrb62LA020B4Sq8 kbylCiGwv0l/ClS1Ic4L7KMDLvRZ3xSc4AUCk1UjewGSFmzMalKDIE2akJN923xe3jSUlr atK81HOk2z5kAfBogbXnPUQO9cv0AEA= Received: from amy (lfbn-idf2-1-1518-133.w92-169.abo.wanadoo.fr [92.169.82.133]) by mx.blih.net (OpenSMTPD) with ESMTPSA id f5b6238d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 20 May 2022 17:33:31 +0000 (UTC) Date: Fri, 20 May 2022 19:33:34 +0200 From: Emmanuel Vadot To: Toomas Soome Cc: "Bjoern A. Zeeb" , current@freebsd.org Subject: Re: loader_4th.efi broke? Message-Id: <20220520193334.2a791540c8eefaf73d0173fe@bidouilliste.com> In-Reply-To: <1BA529E5-064B-46A8-A412-3D7A66AD6D2F@me.com> References: <71D61E79-B3A5-49FA-9B9E-26E124A5B4EF@me.com> <1BA529E5-064B-46A8-A412-3D7A66AD6D2F@me.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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-Rspamd-Queue-Id: 4L4Yjc03wsz4nmW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=pkWrBonj; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[current]; FREEMAIL_TO(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 20 May 2022 20:19:58 +0300 Toomas Soome wrote: >=20 >=20 > > On 20. May 2022, at 20:11, Bjoern A. Zeeb wrote: > >=20 > > On Fri, 20 May 2022, Toomas Soome wrote: > >=20 > >>> On 20. May 2022, at 20:00, Bjoern A. Zeeb wrote: > >>>=20 > >>> Hi, > >>>=20 > >>> something between > >>> 255692.f70de61e567df59bceb2d18c8bc1b54943a7466b and > >>> 255723.b3fa36efe797445cb0b4fd26d79226836db2a2b3 > >>> made loader_4th.efi go all > >>> "failed to allocate staging area: 9" > >>>=20 > >>> I am netbooting booting, no ZFS involved. > >>> One other data point: the base system compile may have changed in tha= t time. > >>>=20 > >>> I haven't dug into yet. Is anyone else seeing this? > >>>=20 > >>=20 > >> staging area will be allocated very early, so for some reason either t= he memory map is fragmented or there is just too low memory. > >>=20 > >> 9 is EFI_OUT_OF_RESOURCES. > >=20 > > The UEFI hasn't changed; 64GB of memory haven't changed. Power > > cycling didn't make a difference. Going back to the old one > > immediately worked again. I saw no changes in stand/ relevant. > >=20 > > Is there a way to debug this or should we simply "stop" if this fails > > rather than endlessly fill the console with it? > >=20 >=20 >=20 > um, ok 64GB should be plenty;) of course, if the firmware is squashing lo= w memory map to small chunks, then there is problem (we are asking to use l= ow 4GB because of buggy firmwares?), but you can try loader_lua.efi. The ot= her cause could be grown kernel modules - we try to allocate 64MB staging a= rea first, if it is not enough, then we try to get larger chunk?. >=20 > Of course, screen spamming is bug, that should not happen.=20 >=20 > rgds, > toomas See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264021 It was bisected to the latest llvm update, I haven't digged yet. --=20 Emmanuel Vadot From nobody Fri May 20 17:45:47 2022 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 55AAE1B3E339 for ; Fri, 20 May 2022 17:45:51 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4Yzf5Kt8z4rdb for ; Fri, 20 May 2022 17:45:50 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 789A48D4A178; Fri, 20 May 2022 17:45:49 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 12D96E707CA; Fri, 20 May 2022 17:45:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id ODCiwUoOOIBw; Fri, 20 May 2022 17:45:48 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 04E9CE707AE; Fri, 20 May 2022 17:45:47 +0000 (UTC) Date: Fri, 20 May 2022 17:45:47 +0000 (UTC) From: "Bjoern A. Zeeb" To: Emmanuel Vadot cc: current@freebsd.org Subject: Re: loader_4th.efi broke? In-Reply-To: <20220520193334.2a791540c8eefaf73d0173fe@bidouilliste.com> Message-ID: References: <71D61E79-B3A5-49FA-9B9E-26E124A5B4EF@me.com> <1BA529E5-064B-46A8-A412-3D7A66AD6D2F@me.com> <20220520193334.2a791540c8eefaf73d0173fe@bidouilliste.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4L4Yzf5Kt8z4rdb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-2.15 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zabbadoz.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.88)[-0.885]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 20 May 2022, Emmanuel Vadot wrote: > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264021 > > It was bisected to the latest llvm update, I haven't digged yet. Thanks a lot manu for pointing to this; hadn't seen it yet. Happy weekend, Bjoern -- Bjoern A. Zeeb r15:7 From nobody Sat May 21 00:56:41 2022 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 230961B47C40 for ; Sat, 21 May 2022 00:56:47 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4lXt0wBMz4jPC for ; Sat, 21 May 2022 00:56:46 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References: In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=uPS+gQ/aqslXoD/Eg6Q6mS5glcZE0ZTXxSEEAOY3EbE=; b=uKJEsvJwnCubrNM526WzuZyodX QmXBcAsCjqzP1xfq1dyouBxeWkVK17t1atF/UhyI6NMaGqn4WS2sKdDOKuBEwL12bkWLij0iZuIyP n24/wmvPcdA8Ac94sc4eMmPxf/td7X/Gn68y9ldXBmeaWrr1MU78CMVxgZXudBULF1C0kc8tkH0iI 3amLrZ5LCajHW84/vnHPB3Nm/DBbDIKpcANWc88RL6WiqSv7gGECSTlDtDccp+yAxNPBW1RAvRQ0T eDwx1MNXQNTx2jbmwQyLlHWN7FW5/y6bD8J1LYn0uAh/xM9SEsAD3s+e3K6tbqd1ly75nAfLiL0X9 rv+UIuew==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:32928 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nsDQ9-000COo-OO; Fri, 20 May 2022 19:56:41 -0500 Received: from 2600:1700:210:b18f:dc51:5c5c:8010:caa6 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Fri, 20 May 2022 19:56:41 -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 Date: Fri, 20 May 2022 19:56:41 -0500 From: Larry Rosenman To: Toomas Soome Cc: Johan Hendriks , FreeBSD Current Subject: Re: Zpool with latest feature com.delpfix:head_errlog can not be booted from. In-Reply-To: References: <3f367b95-a418-f298-5fe2-972bf2bc1fd4@gmail.com> Message-ID: <2c388d289aaa4ab83ee36622e852adca@lerctr.org> X-Sender: ler@lerctr.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4L4lXt0wBMz4jPC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=uKJEsvJw; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-2.57 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.43)[0.428]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:55103, ipnet:192.147.25.0/24, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Can you let me know when a replacement binary is available for EFI? I have my buildbox/dev system in a non-bootable state. It's RAIDZ-1 pool, and no place to put another disk. Thanks for any help. (If can email the replacement binary that would be wonderful). On 05/20/2022 4:47 am, Toomas Soome wrote: > I’ll see into it. It would be nice to have at least heads up message > about such features, or zfs code does have means to block feature > upgrade on boot pool. > > Rgds, > Toomas > > >> On 20. May 2022, at 11:39, Johan Hendriks >> wrote: >> >> I did upgrade my FreeBSD Current and with that i updated my storage >> pool and my zroot pool. >> I did add the new gptboot code on the disk. After the reboot i can not >> boot anymore. >> >> So i did reinstall the os on one disk of the old zroot mirror pool and >> did leave the second untouched. >> >> Then i can import the pools. >> If i boot with the latest snapshot ISO >> (FreeBSD-14.0-CURRENT-amd64-20220519-716fd348e01-255696-disc1.iso) i >> see the following when i boot. >> >> BIOS drive A: is fd0 >> BIOS drive B: is fd1 >> >> BIOS drive K: is disk9 >> ZFS: unsupported feature: com.delpfix:head_errlog >> ZFS: pool zroot is not supported >> ZFS: unsupported feature: com.delpfix:head_errlog >> ZFS: pool storage is not supported >> BIOS 624kB/2000420kB available memory >> >> Then the OS is loaded, if i then go to the shell of the installer and >> do a zpool import, ik can import the pool zroot and storage. So this >> snapshot has the latest ZFS version with the com.delpfix:head_errlog >> feature. So it looks like the bootloader is not able to use the new >> feature and thus renders your system unbootable. >> >> regards >> Johan >> >> -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 From nobody Sat May 21 06:23:30 2022 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 A73C41B35D05 for ; Sat, 21 May 2022 06:23:44 +0000 (UTC) (envelope-from tsoome@me.com) Received: from ci74p00im-qukt09090302.me.com (ci74p00im-qukt09090302.me.com [17.57.156.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4tp75lYcz3sXT for ; Sat, 21 May 2022 06:23:43 +0000 (UTC) (envelope-from tsoome@me.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1653114216; bh=N5U2utD5dDsMb/oU6sVH+OCl6Y7YHJZ57RGqUNi/VV0=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=CTVmt0aUD+bzV70Ct1QsCG7erzszJZRXVCj2Dcn4LTfTuhKhkQfmCA7kF0hd/e6A3 TpTt55Vh0rj4MMjvA88mw/HOur0osITMvEhlWq/WSH/Aki4fDRNlnd1o3/G7xK3AEQ khlrMhwJuXOAd0XZNB1R66KuDqiZ0j6usC+yVpXl/VrXpRCOSiwZj8g9xwHhBIP3HM Svv+Mz274mVDy4fF4z2F+p+dPYYuguPFdS8mzlwjMYq5iF8eWTz7FAXjAW93jjBM9b GDxOroWb1Hq5biFqT2Ia5IekgqLGrLeUfKma3+Tp8QJCJCSdWKFuDbqAk+r7irUf0E KMbFTk7/9TQug== Received: from smtpclient.apple (ci77p00im-dlb-asmtp-mailmevip.me.com [17.57.156.26]) by ci74p00im-qukt09090302.me.com (Postfix) with ESMTPSA id BF6FA5BC054D; Sat, 21 May 2022 06:23:34 +0000 (UTC) From: Toomas Soome Message-Id: <3603BC68-C972-4DC6-9D94-6863699D9950@me.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7F70D6D3-1C2E-427A-B4B0-7A4F9D422BFF" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: Zpool with latest feature com.delpfix:head_errlog can not be booted from. Date: Sat, 21 May 2022 09:23:30 +0300 In-Reply-To: <2c388d289aaa4ab83ee36622e852adca@lerctr.org> Cc: Johan Hendriks , FreeBSD Current To: Larry Rosenman References: <3f367b95-a418-f298-5fe2-972bf2bc1fd4@gmail.com> <2c388d289aaa4ab83ee36622e852adca@lerctr.org> X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Proofpoint-GUID: Ps7sgifCGtaVOqgtPafx--k85WNeec-S X-Proofpoint-ORIG-GUID: Ps7sgifCGtaVOqgtPafx--k85WNeec-S X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.572,17.0.605.474.0000000_definitions?= =?UTF-8?Q?=3D2020-02-14=5F11:2020-02-14=5F02,2020-02-14=5F11,2020-01-23?= =?UTF-8?Q?=5F02_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 clxscore=1011 spamscore=0 mlxscore=0 malwarescore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205210037 X-Rspamd-Queue-Id: 4L4tp75lYcz3sXT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=CTVmt0aU; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.57.156.21 as permitted sender) smtp.mailfrom=tsoome@me.com X-Spamd-Result: default: False [-3.33 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:17.57.156.0/24]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-0.73)[-0.726]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[me.com]; ASN(0.00)[asn:714, ipnet:17.57.156.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[17.57.156.21:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_7F70D6D3-1C2E-427A-B4B0-7A4F9D422BFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! You can find binaries from boot.tar = root@freebsd:~ # zpool get all NAME PROPERTY VALUE = SOURCE zroot size 29.6G - zroot capacity 68% - zroot altroot - = default zroot health ONLINE - zroot guid 7047501746656921268 - zroot version - = default zroot bootfs zroot/ROOT/default-15 = local zroot delegation on = default zroot autoreplace off = default zroot cachefile - = default zroot failmode wait = default zroot listsnapshots off = default zroot autoexpand on = local zroot dedupratio 1.00x - zroot free 9.36G - zroot allocated 20.3G - zroot readonly off - zroot ashift 0 = default zroot comment - = default zroot expandsize - - zroot freeing 0 - zroot fragmentation 66% - zroot leaked 0 - zroot multihost off = default zroot checkpoint - - zroot load_guid 17322783153073627560 - zroot autotrim off = default zroot compatibility off = default zroot feature@async_destroy enabled = local zroot feature@empty_bpobj active = local zroot feature@lz4_compress active = local zroot feature@multi_vdev_crash_dump enabled = local zroot feature@spacemap_histogram active = local zroot feature@enabled_txg active = local zroot feature@hole_birth active = local zroot feature@extensible_dataset active = local zroot feature@embedded_data active = local zroot feature@bookmarks enabled = local zroot feature@filesystem_limits enabled = local zroot feature@large_blocks enabled = local zroot feature@large_dnode enabled = local zroot feature@sha512 enabled = local zroot feature@skein enabled = local zroot feature@edonr enabled = local zroot feature@userobj_accounting active = local zroot feature@encryption enabled = local zroot feature@project_quota active = local zroot feature@device_removal enabled = local zroot feature@obsolete_counts enabled = local zroot feature@zpool_checkpoint enabled = local zroot feature@spacemap_v2 active = local zroot feature@allocation_classes enabled = local zroot feature@resilver_defer enabled = local zroot feature@bookmark_v2 enabled = local zroot feature@redaction_bookmarks enabled = local zroot feature@redacted_datasets enabled = local zroot feature@bookmark_written enabled = local zroot feature@log_spacemap active = local zroot feature@livelist enabled = local zroot feature@device_rebuild enabled = local zroot feature@zstd_compress enabled = local zroot feature@draid enabled = local zroot feature@zilsaxattr active = local zroot feature@head_errlog active = local root@freebsd:~ #=20 after re.installing boot programs, it does boot, also does work: root@freebsd:~ # /usr/obj/usr/src/amd64.amd64/stand/userboot/test/test = -d /dev/da0 the fix is already pushed. rgds, toomas > On 21. May 2022, at 03:56, Larry Rosenman wrote: >=20 > Can you let me know when a replacement binary is available for EFI? I = have my buildbox/dev system in a non-bootable > state. It's RAIDZ-1 pool, and no place to put another disk. >=20 > Thanks for any help. > (If can email the replacement binary that would be = wonderful). >=20 >=20 > On 05/20/2022 4:47 am, Toomas Soome wrote: >> I=E2=80=99ll see into it. It would be nice to have at least heads up = message >> about such features, or zfs code does have means to block feature >> upgrade on boot pool. >> Rgds, >> Toomas >>> On 20. May 2022, at 11:39, Johan Hendriks = wrote: >>> =EF=BB=BFI did upgrade my FreeBSD Current and with that i updated my = storage pool and my zroot pool. >>> I did add the new gptboot code on the disk. After the reboot i can = not boot anymore. >>> So i did reinstall the os on one disk of the old zroot mirror pool = and did leave the second untouched. >>> Then i can import the pools. >>> If i boot with the latest snapshot ISO = (FreeBSD-14.0-CURRENT-amd64-20220519-716fd348e01-255696-disc1.iso) i see = the following when i boot. >>> BIOS drive A: is fd0 >>> BIOS drive B: is fd1 >>> >>> BIOS drive K: is disk9 >>> ZFS: unsupported feature: com.delpfix:head_errlog >>> ZFS: pool zroot is not supported >>> ZFS: unsupported feature: com.delpfix:head_errlog >>> ZFS: pool storage is not supported >>> BIOS 624kB/2000420kB available memory >>> Then the OS is loaded, if i then go to the shell of the installer = and do a zpool import, ik can import the pool zroot and storage. So this = snapshot has the latest ZFS version with the com.delpfix:head_errlog = feature. So it looks like the bootloader is not able to use the new = feature and thus renders your system unbootable. >>> regards >>> Johan >=20 > --=20 > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 --Apple-Mail=_7F70D6D3-1C2E-427A-B4B0-7A4F9D422BFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi!

You = can find binaries from boot.tar

root@freebsd:~ # zpool get all
NAME =   PROPERTY                 =       VALUE            =               SOURCE
zroot  size             =               29.6G    =                     =   -
zroot  capacity     =                   68%  =                     =       -
zroot  altroot            =             -        =                     =   default
zroot  health       =                   ONLINE =                     =     -
zroot  guid       =                     = 7047501746656921268            = -
zroot  version      =                   -  =                     =         default
zroot  bootfs             =             zroot/ROOT/default-15  =         local
zroot  delegation           =           on           =                   = default
zroot  autoreplace    =                 off    =                     =     default
zroot  cachefile          =             -        =                     =   default
zroot  failmode     =                   wait =                     =       default
zroot  listsnapshots          =         off            =                 = default
zroot  autoexpand     =                 on     =                     =     local
zroot  dedupratio     =                 1.00x  =                     =     -
zroot  free       =                     = 9.36G                  =         -
zroot  allocated          =             20.3G      =                     = -
zroot  readonly     =                   off  =                     =       -
zroot  ashift             =             0        =                     =   default
zroot  comment      =                   -  =                     =         default
zroot  expandsize           =           -          =                     = -
zroot  freeing      =                   0  =                     =         -
zroot  fragmentation          =         66%            =                 = -
zroot  leaked       =                   0  =                     =         -
zroot  multihost          =             off        =                     = default
zroot  checkpoint     =                 -    =                     =       -
zroot  load_guid          =             17322783153073627560   =         -
zroot  autotrim           =             off        =                     = default
zroot  compatibility    =               off      =                     =   default
zroot  feature@async_destroy  =         enabled          =               local
zroot  feature@empty_bpobj        =     active               =           local
zroot  feature@lz4_compress         =   active                 =         local
zroot  feature@multi_vdev_crash_dump  enabled  =                     =   local
zroot  feature@spacemap_histogram =     active               =           local
zroot  feature@enabled_txg        =     active               =           local
zroot  feature@hole_birth         =     active               =           local
zroot  feature@extensible_dataset     active =                     =     local
zroot  feature@embedded_data  =         active           =               local
zroot  feature@bookmarks        =       enabled            =             local
zroot  feature@filesystem_limits      = enabled                  =       local
zroot  feature@large_blocks         =   enabled                =         local
zroot  feature@large_dnode        =     enabled              =           local
zroot  feature@sha512           =       enabled            =             local
zroot  feature@skein          =         enabled          =               local
zroot  feature@edonr          =         enabled          =               local
zroot  feature@userobj_accounting     active =                     =     local
zroot  feature@encryption   =           enabled        =                 = local
zroot  feature@project_quota  =         active           =               local
zroot  feature@device_removal       =   enabled                =         local
zroot  feature@obsolete_counts      =   enabled                =         local
zroot  feature@zpool_checkpoint       = enabled                  =       local
zroot  feature@spacemap_v2        =     active               =           local
zroot  feature@allocation_classes     = enabled                  =       local
zroot  feature@resilver_defer       =   enabled                =         local
zroot  feature@bookmark_v2        =     enabled              =           local
zroot  feature@redaction_bookmarks    = enabled                  =       local
zroot  feature@redacted_datasets      = enabled                  =       local
zroot  feature@bookmark_written       = enabled                  =       local
zroot  feature@log_spacemap         =   active                 =         local
zroot  feature@livelist         =       enabled            =             local
zroot  feature@device_rebuild       =   enabled                =         local
zroot  feature@zstd_compress        =   enabled                =         local
zroot  feature@draid          =         enabled          =               local
zroot  feature@zilsaxattr         =     active               =           local
zroot  feature@head_errlog        =     active               =           local
root@freebsd:~ # 

after re.installing boot programs, it = does boot, also does work:
root@freebsd:~ # = /usr/obj/usr/src/amd64.amd64/stand/userboot/test/test -d = /dev/da0

the = fix is already pushed.

rgds,
toomas

On 21. May 2022, at 03:56, = Larry Rosenman <ler@lerctr.org> wrote:

Can = you let me know when a replacement binary is available for EFI?  I = have my buildbox/dev system in a non-bootable
state. =  It's RAIDZ-1 pool, and no place to put another disk.

Thanks for any help.
(If = <someone> can email the replacement binary that would be = wonderful).


On 05/20/2022 = 4:47 am, Toomas Soome wrote:
I=E2=80=99ll see into it. It would be nice to have at least = heads up message
about such features, or zfs code does = have means to block feature
upgrade on boot pool.
Rgds,
Toomas
On 20. May 2022, at 11:39, Johan Hendriks = <joh.hendriks@gmail.com> wrote:
=EF=BB=BFI = did upgrade my FreeBSD Current and with that i updated my storage pool = and my zroot pool.
I did add the new gptboot code on the = disk. After the reboot i can not boot anymore.
So i did = reinstall the os on one disk of the old zroot mirror pool and did leave = the second untouched.
Then i can import the pools.
If i boot with the latest snapshot ISO = (FreeBSD-14.0-CURRENT-amd64-20220519-716fd348e01-255696-disc1.iso) i see = the following when i boot.
BIOS drive A: is fd0
BIOS drive B: is fd1
<SNAP>
BIOS drive K: is disk9
ZFS: unsupported = feature: com.delpfix:head_errlog
ZFS: pool zroot is not = supported
ZFS: unsupported feature: = com.delpfix:head_errlog
ZFS: pool storage is not = supported
BIOS 624kB/2000420kB available memory
Then the OS is loaded, if i then go to the shell of the = installer and do a zpool import, ik can import the pool zroot and = storage. So this snapshot has the latest ZFS version with the = com.delpfix:head_errlog feature. So it looks like the bootloader is not = able to use the new feature and thus renders your system unbootable.
regards
Johan

--
Larry Rosenman =             &n= bsp;       http://www.lerctr.org/~ler
Phone: +1 = 214-642-9640 =             &n= bsp;   E-Mail:= ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, = TX 78665-2106

= --Apple-Mail=_7F70D6D3-1C2E-427A-B4B0-7A4F9D422BFF-- From nobody Sat May 21 06:28:39 2022 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 A8C391B37CCD for ; Sat, 21 May 2022 06:28:20 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 4L4tvR64jlz3ty3 for ; Sat, 21 May 2022 06:28:19 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (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 phk.freebsd.dk (Postfix) with ESMTPS id 744D689284; Sat, 21 May 2022 06:28:12 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 24L6SfDA014771 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 21 May 2022 06:28:41 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 24L6Sdr7014770; Sat, 21 May 2022 06:28:39 GMT (envelope-from phk) Message-Id: <202205210628.24L6Sdr7014770@critter.freebsd.dk> To: Andrew Turner cc: current@freebsd.org Subject: Re: RockPRO64 exception 22 esr_el1 8a000000 In-reply-to: From: "Poul-Henning Kamp" References: <202205190626.24J6QOOe000629@critter.freebsd.dk> 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-ID: <14768.1653114519.1@critter.freebsd.dk> Date: Sat, 21 May 2022 06:28:39 +0000 X-Rspamd-Queue-Id: 4L4tvR64jlz3ty3 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.29 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_SPAM_SHORT(0.71)[0.708]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I recompiled kernel, world and wireguard-kmod, and it still happens. Have opened https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264115 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Sat May 21 21:40:59 2022 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 1501C1B3E628 for ; Sat, 21 May 2022 21:41:02 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]) (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 "*.lerctr.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L5H8Y0Thdz3McC for ; Sat, 21 May 2022 21:41:01 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To: From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Ib2qpZ83c7fOizIztNPQTdLsCqGBFGYBAT4Jk2tcjC8=; b=K011AGEBBz0FvRzARUJDbXOP+g vtW6ihzVrkR+JKXCWBsBZ0ff9jsL1uIdRTHSvSKYRb0y6+4zowIMFPyWVWZj75eIVY+6Ow8cMMwjz of85L5g/2fff+9ujmBStDaaaayz9FVIB2g1BV+++nvZafmJNMbbAJqOEyAUjS67SN2MVk+Ut/t2Gj E4z3SUMU3Gnb0mut9wYb+5AFdyN7GqVoH1zIu1WO2PPfwxp7n7htYPgbVxmbCS2gm5T4qQLVd3U9O dd/2r0aBZuF+rWH3ttceo40cLgqNA0LOwpG8S7sJHALOeR9RSqssWTzSJDa0Yf2tcU493bUmApug2 qgXjiTWA==; Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org; Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:31391 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nsWqJ-0006T1-Ez; Sat, 21 May 2022 16:40:59 -0500 Received: from 2600:1700:210:b18f:2d0f:6fbd:3e75:113d by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sat, 21 May 2022 16:40:59 -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 Date: Sat, 21 May 2022 16:40:59 -0500 From: Larry Rosenman To: Toomas Soome Cc: Johan Hendriks , FreeBSD Current Subject: Re: Zpool with latest feature com.delpfix:head_errlog can not be booted from. In-Reply-To: <3603BC68-C972-4DC6-9D94-6863699D9950@me.com> References: <3f367b95-a418-f298-5fe2-972bf2bc1fd4@gmail.com> <2c388d289aaa4ab83ee36622e852adca@lerctr.org> <3603BC68-C972-4DC6-9D94-6863699D9950@me.com> Message-ID: X-Sender: ler@lerctr.org Content-Type: multipart/alternative; boundary="=_db4b03940083b5e34b3f280dc23c1bec" X-Rspamd-Queue-Id: 4L5H8Y0Thdz3McC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lerctr.org header.s=ler2019 header.b=K011AGEB; dmarc=pass (policy=none) header.from=lerctr.org; spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org X-Spamd-Result: default: False [-3.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019]; FREEFALL_USER(0.00)[ler]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[lerctr.org:+]; DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --=_db4b03940083b5e34b3f280dc23c1bec Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Thanks, Toomas! I'm back up. On 05/21/2022 1:23 am, Toomas Soome wrote: > Hi! > > You can find binaries from boot.tar [1] > > root@freebsd:~ # zpool get all > NAME PROPERTY VALUE > SOURCE > zroot size 29.6G - > zroot capacity 68% - > zroot altroot - > default > zroot health ONLINE - > zroot guid 7047501746656921268 - > zroot version - > default > zroot bootfs zroot/ROOT/default-15 > local > zroot delegation on > default > zroot autoreplace off > default > zroot cachefile - > default > zroot failmode wait > default > zroot listsnapshots off > default > zroot autoexpand on > local > zroot dedupratio 1.00x - > zroot free 9.36G - > zroot allocated 20.3G - > zroot readonly off - > zroot ashift 0 > default > zroot comment - > default > zroot expandsize - - > zroot freeing 0 - > zroot fragmentation 66% - > zroot leaked 0 - > zroot multihost off > default > zroot checkpoint - - > zroot load_guid 17322783153073627560 - > zroot autotrim off > default > zroot compatibility off > default > zroot feature@async_destroy enabled > local > zroot feature@empty_bpobj active > local > zroot feature@lz4_compress active > local > zroot feature@multi_vdev_crash_dump enabled > local > zroot feature@spacemap_histogram active > local > zroot feature@enabled_txg active > local > zroot feature@hole_birth active > local > zroot feature@extensible_dataset active > local > zroot feature@embedded_data active > local > zroot feature@bookmarks enabled > local > zroot feature@filesystem_limits enabled > local > zroot feature@large_blocks enabled > local > zroot feature@large_dnode enabled > local > zroot feature@sha512 enabled > local > zroot feature@skein enabled > local > zroot feature@edonr enabled > local > zroot feature@userobj_accounting active > local > zroot feature@encryption enabled > local > zroot feature@project_quota active > local > zroot feature@device_removal enabled > local > zroot feature@obsolete_counts enabled > local > zroot feature@zpool_checkpoint enabled > local > zroot feature@spacemap_v2 active > local > zroot feature@allocation_classes enabled > local > zroot feature@resilver_defer enabled > local > zroot feature@bookmark_v2 enabled > local > zroot feature@redaction_bookmarks enabled > local > zroot feature@redacted_datasets enabled > local > zroot feature@bookmark_written enabled > local > zroot feature@log_spacemap active > local > zroot feature@livelist enabled > local > zroot feature@device_rebuild enabled > local > zroot feature@zstd_compress enabled > local > zroot feature@draid enabled > local > zroot feature@zilsaxattr active > local > zroot feature@head_errlog active > local > root@freebsd:~ # > > after re.installing boot programs, it does boot, also does work: > root@freebsd:~ # /usr/obj/usr/src/amd64.amd64/stand/userboot/test/test > -d /dev/da0 > > the fix is already pushed. > > rgds, > toomas > > On 21. May 2022, at 03:56, Larry Rosenman wrote: > > Can you let me know when a replacement binary is available for EFI? I > have my buildbox/dev system in a non-bootable > state. It's RAIDZ-1 pool, and no place to put another disk. > > Thanks for any help. > (If can email the replacement binary that would be > wonderful). > > On 05/20/2022 4:47 am, Toomas Soome wrote: > I'll see into it. It would be nice to have at least heads up message > about such features, or zfs code does have means to block feature > upgrade on boot pool. > Rgds, > Toomas > On 20. May 2022, at 11:39, Johan Hendriks > wrote: > I did upgrade my FreeBSD Current and with that i updated my storage > pool and my zroot pool. > I did add the new gptboot code on the disk. After the reboot i can not > boot anymore. > So i did reinstall the os on one disk of the old zroot mirror pool and > did leave the second untouched. > Then i can import the pools. > If i boot with the latest snapshot ISO > (FreeBSD-14.0-CURRENT-amd64-20220519-716fd348e01-255696-disc1.iso) i > see the following when i boot. > BIOS drive A: is fd0 > BIOS drive B: is fd1 > > BIOS drive K: is disk9 > ZFS: unsupported feature: com.delpfix:head_errlog > ZFS: pool zroot is not supported > ZFS: unsupported feature: com.delpfix:head_errlog > ZFS: pool storage is not supported > BIOS 624kB/2000420kB available memory > Then the OS is loaded, if i then go to the shell of the installer and > do a zpool import, ik can import the pool zroot and storage. So this > snapshot has the latest ZFS version with the com.delpfix:head_errlog > feature. So it looks like the bootloader is not able to use the new > feature and thus renders your system unbootable. > regards > Johan -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 Links: ------ [1] http://148-52-235-80.sta.estpak.ee/boot.tar --=_db4b03940083b5e34b3f280dc23c1bec Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Thanks, Toomas!  I'm back up. 


On 05/21/2022 1:23 am, Toomas Soome wrote:

Hi!
 
You can find binaries from boot.tar
 
root@freebsd:~ # zpool get all
NAME   PROPERTY        = ;               VALUE     = ;                     SOU= RCE
zroot  size         &n= bsp;                 29.6G  &n= bsp;                     =   -
zroot  capacity        = ;               68%      =                      = ; -
zroot  altroot        =                 -    &nbs= p;                     &n= bsp;   default
zroot  health         =                 ONLINE    = ;                     -
zroot  guid         &n= bsp;                 70475017466569= 21268            -
zroot  version        =                 -    &nbs= p;                     &n= bsp;   default
zroot  bootfs         =                 zroot/ROOT/default-= 15          local
zroot  delegation       &nb= sp;             on        = ;                     def= ault
zroot  autoreplace      &nb= sp;             off       = ;                     def= ault
zroot  cachefile       = ;               -      &n= bsp;                     =   default
zroot  failmode        = ;               wait      = ;                     def= ault
zroot  listsnapshots      &= nbsp;           off        &nb= sp;                   default<= /span>
zroot  autoexpand       &nb= sp;             on        = ;                     loc= al
zroot  dedupratio       &nb= sp;             1.00x      &nb= sp;                   -=
zroot  free         &n= bsp;                 9.36G  &n= bsp;                     =   -
zroot  allocated       = ;               20.3G     = ;                     -
zroot  readonly        = ;               off      =                      = ; -
zroot  ashift         =                 0    &nbs= p;                     &n= bsp;   default
zroot  comment        =                 -    &nbs= p;                     &n= bsp;   default
zroot  expandsize       &nb= sp;             -        =                      = ; -
zroot  freeing        =                 0    &nbs= p;                     &n= bsp;   -
zroot  fragmentation      &= nbsp;           66%        &nb= sp;                   -=
zroot  leaked         =                 0    &nbs= p;                     &n= bsp;   -
zroot  multihost       = ;               off      =                      = ; default
zroot  checkpoint       &nb= sp;             -        =                      = ; -
zroot  load_guid       = ;               17322783153073627560 &nb= sp;         -
zroot  autotrim        = ;               off      =                      = ; default
zroot  compatibility      &= nbsp;           off        &nb= sp;                   default<= /span>
zroot  feature@async_destroy    =       enabled             = ;           local
zroot  feature@empty_bpobj    &n= bsp;       active             =             local
zroot  feature@lz4_compress     =       active              = ;           local
zroot  feature@multi_vdev_crash_dump = enabled                  &nbs= p;     local
zroot  feature@spacemap_histogram   &= nbsp; active                  =       local
zroot  feature@enabled_txg    &n= bsp;       active             =             local
zroot  feature@hole_birth     &n= bsp;       active             =             local
zroot  feature@extensible_dataset   &= nbsp; active                  =       local
zroot  feature@embedded_data    =       active              = ;           local
zroot  feature@bookmarks    &nbs= p;         enabled          &n= bsp;             local
zroot  feature@filesystem_limits  &nb= sp;   enabled                &= nbsp;       local
zroot  feature@large_blocks     =       enabled             = ;           local
zroot  feature@large_dnode    &n= bsp;       enabled            =             local
zroot  feature@sha512      =           enabled        &nbs= p;               local
zroot  feature@skein      &= nbsp;           enabled       =                 local
zroot  feature@edonr      &= nbsp;           enabled       =                 local
zroot  feature@userobj_accounting   &= nbsp; active                  =       local
zroot  feature@encryption     &n= bsp;       enabled            =             local
zroot  feature@project_quota    =       active              = ;           local
zroot  feature@device_removal    = ;     enabled              &nb= sp;         local
zroot  feature@obsolete_counts   = ;     enabled              &nb= sp;         local
zroot  feature@zpool_checkpoint   &nb= sp;   enabled                &= nbsp;       local
zroot  feature@spacemap_v2    &n= bsp;       active             =             local
zroot  feature@allocation_classes   &= nbsp; enabled                 =       local
zroot  feature@resilver_defer    = ;     enabled              &nb= sp;         local
zroot  feature@bookmark_v2    &n= bsp;       enabled            =             local
zroot  feature@redaction_bookmarks  &= nbsp; enabled                 =       local
zroot  feature@redacted_datasets  &nb= sp;   enabled                &= nbsp;       local
zroot  feature@bookmark_written   &nb= sp;   enabled                &= nbsp;       local
zroot  feature@log_spacemap     =       active              = ;           local
zroot  feature@livelist     &nbs= p;         enabled          &n= bsp;             local
zroot  feature@device_rebuild    = ;     enabled              &nb= sp;         local
zroot  feature@zstd_compress    =       enabled             = ;           local
zroot  feature@draid      &= nbsp;           enabled       =                 local
zroot  feature@zilsaxattr     &n= bsp;       active             =             local
zroot  feature@head_errlog    &n= bsp;       active             =             local
root@freebsd:~ # 
 
after re.installing boot programs, it does boot= , also does work:
root@freebsd:~ # /usr/obj/usr/src/amd64.amd64/s= tand/userboot/test/test -d /dev/da0
 
the fix is already pushed.
 
rgds,
toomas


Can you let me know when a replacement binary is available for EFI? &n= bsp;I have my buildbox/dev system in a non-bootable
state.  It's = RAIDZ-1 pool, and no place to put another disk.

Thanks for any h= elp.
(If <someone> can email the replacement binary that would b= e wonderful).


On 05/20/2022 4:47 am, Toomas Soome wrote:
I'll see into it. It would be nice to have at least he= ads up message
about such features, or zfs code does have means to blo= ck feature
upgrade on boot pool.
Rgds,
Toomas
On 20. May 2022, at 11:39, Johan Hendriks <joh.hendriks@gmail.co= m> wrote:
I did upgrade my FreeBSD Current and with that i upda= ted my storage pool and my zroot pool.
I did add the new gptboot code = on the disk. After the reboot i can not boot anymore.
So i did reinsta= ll the os on one disk of the old zroot mirror pool and did leave the second= untouched.
Then i can import the pools.
If i boot with the lates= t snapshot ISO (FreeBSD-14.0-CURRENT-amd64-20220519-716fd348e01-255696-disc= 1.iso) i see the following when i boot.
BIOS drive A: is fd0
BIOS= drive B: is fd1
<SNAP>
BIOS drive K: is disk9
ZFS: un= supported feature: com.delpfix:head_errlog
ZFS: pool zroot is not supp= orted
ZFS: unsupported feature: com.delpfix:head_errlog
ZFS: pool= storage is not supported
BIOS 624kB/2000420kB available memory
T= hen the OS is loaded, if i then go to the shell of the installer and do a z= pool import, ik can import the pool zroot and storage. So this snapshot has= the latest ZFS version with the com.delpfix:head_errlog feature. So it loo= ks like the bootloader is not able to use the new feature and thus renders = your system unbootable.
regards
Johan

--
Larry Rosenman        &nb= sp;            = http://www.lerctr.org/~ler
Phone: +1 214-642-9640  =             &nb= sp;  E-Mail:= ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=


= -- 
Larry Rosenman     &n= bsp;            = ;   http://www.lerctr.org/~ler
Phone: +1 = 214-642-9640           &n= bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=
--=_db4b03940083b5e34b3f280dc23c1bec-- From nobody Sat May 21 22:20:00 2022 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 B4CD81B463AE for ; Sat, 21 May 2022 22:21:04 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L5J2m23rlz3j0V for ; Sat, 21 May 2022 22:21:04 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: by mail-pl1-x62e.google.com with SMTP id m12so10077332plb.4 for ; Sat, 21 May 2022 15:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=/sLnr9WNV5DGSOFyw2wjIAg8N+QFI55SjFDS3pE8g5M=; b=OYkMyg9AyO9IQyMzB+98PeIWJJpYk1DvCTXWoLsXxMu6AU93x9NzMhqA5L2eSozzh2 KBiaY7Zkd99C6/nvBRp6Yvmeg2w9OccBy1dw6tpwvGzsUlHGXwVtdI3jzBu4pnKi+x4o YrflIsjqgotS2z3XRCQIuVWvf9BoIOE7eNLyQ53HHmJlRPOR+6juCZsI/0zUO/+COjjA tQkr+//7kHmk2AnTw+VmTJyttZbXrur9UWN5zH+ASPdLPqUakTdMUaZV8jVLt7ICI9wY uXN+7Hz0VALqCdHYhw6YctmmQMxRtCOhYRhlr3Iu0TekfA+qU5ndE7RzSn45lcLMr9B/ jytA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/sLnr9WNV5DGSOFyw2wjIAg8N+QFI55SjFDS3pE8g5M=; b=naOtnZ648O9o2luKyC/ZCsvvsPfztYeU7wEOjlBp38Vz0TGkxK/HJB4d298lykrGBD NtlLc+8yI3+2aO9qTQAlo1riDy62Z5leqerMcF/+3xRI5ONLA3g/o7YeI5hy64UnIXJ2 qwjmOr7hFY9xAKM1PPS8xusyu37jf0P4BlbzRlBE+KNOpe8QjSGpNPEi/G4/HXcoc840 Nw/ysEG+xT0zHrXP/wqmOX+KjSs7ckikOfCzN2Wzuhe6iWJOSoFbi6D/AHmsf1JKFkFz Gc/8h7xfSZ/gnaIzDLc11nCJByHpzWB5RccRBynajqDW2njdHS35xUj2z5w3GgpG6Bgi habQ== X-Gm-Message-State: AOAM5327tjOQcKcE812ah2UfBNyFWKrRAM9Yy5lOgJzhg7576mFNNF2A A4ddxytUNTtXhT7nPEL7G730lQnGntcgOZHu/QTNh7Jbw/0= X-Google-Smtp-Source: ABdhPJz/Qjt54PYlIiR5SoXPwxXpacCk+9j2cCT5evl4cA1GoJZ2+oPY4kIPZ7j+EcOUI9yX+8J2V8SNHvc8kokIl1Q= X-Received: by 2002:a17:90a:4f0a:b0:1df:b37b:75b1 with SMTP id p10-20020a17090a4f0a00b001dfb37b75b1mr18982911pjh.199.1653171662970; Sat, 21 May 2022 15:21:02 -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: obiwac Date: Sun, 22 May 2022 00:20:00 +0200 Message-ID: Subject: Writing to vt framebuffer To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4L5J2m23rlz3j0V X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=OYkMyg9A; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of obiwac@gmail.com designates 2607:f8b0:4864:20::62e as permitted sender) smtp.mailfrom=obiwac@gmail.com X-Spamd-Result: default: False [-2.32 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.60)[0.596]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.91)[-0.912]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::62e:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Good evening all, For a certain application I need to be able to draw directly to the VBE/GOP framebuffer without the help of xorg-server (too cumbersome), and I had no problems getting this to work with the old syscons driver a while back: ioctl(0, KDENABIO, 0); ioctl(0, VT_WAITACTIVE, 0); ioctl(0, KDSETMODE, KD_GRAPHICS); ioctl(0, _IO('V', 280 - M_VESA_BASE), 0); video_adapter_info_t adp; ioctl(0, CONS_ADPINFO, &adp); ioctl(0, CONS_SETWINORG, 0); uint8_t* fb = mmap(NULL, adp.va_window_size, PROT_READ | PROT_WRITE, MAP_FILE | MAP_SHARED, STDOUT_FILENO, 0); (Error handling omitted for the sake of brevity.) No problems up until here, but I'd like to move on to newcons (for UEFI, and because I've been having some slightly weird behaviour with it and the i915kms & radeonkms drivers). Problem is I can only find very little information about vt! By faffing around in the vt source (src/sys/dev/vt) & Xorg source (especially hw/xfree86/os-support/bsd/bsd_init.c), I've come up with: int fd = open("/dev/ttyv0", O_RDWR | O_NDELAY); int vtno = 2; // rolled a dice and it landed on 2 ioctl(fd, VT_ACTIVATE, vtno); ioctl(fd, VT_WAITACTIVE, vtno); This does... something, at least. If I'm running Xorg, it switches to a virtual terminal and displays random blocks of colours on screen (at least I think that's what it's doing; ngl I don't understand much of all this, mostly distilling what Xorg does... one thing I did gather from this little promenade through bsd_init.c is that vt is the same thing as pcvt on OpenBSD, or at the very least is meant to be compatible with it?) But further than this, I can't, it would seem, set modes, map framebuffer memory, or do anything of the sorts. And I'm a bit at wits end here; I seriously can't understand how Xorg does things after this. I don't even get how it can possibly work, actually, as the KD_SETMODE ioctl in vt_core.c doesn't seem like it's even doing anything at all. I don't really need to set modes either. Just having the correct mode set by the loader and being able to simply draw to a framebuffer would be all that I need. Hopefully someone can enlighten me on vt's mystique which transcends what the likes of mere mortals such as myself can comprehend. I think once (read: if) I wrap my head around all this I'll finally get vidcontrol working with vt (if that's possible at all) because that's been bugging me for a while too! From nobody Sat May 21 23:29:51 2022 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 9D71F1AECDDD for ; Sat, 21 May 2022 23:29:54 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L5KZ95Rclz3sPJ; Sat, 21 May 2022 23:29:53 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-111-80.area1b.commufa.jp [123.1.111.80]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 24LNTpKZ040012; Sun, 22 May 2022 08:29:51 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 22 May 2022 08:29:51 +0900 From: Tomoaki AOKI To: current@freebsd.org Cc: Dimitry Andric Subject: Bulld failure of editors/libreoffoce only on main (aka -current) Message-Id: <20220522082951.f7385d630c23cef986b766e6@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L5KZ95Rclz3sPJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [0.96 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.44)[-0.435]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.111.80:received] X-ThisMailContainsUnwantedMimeParts: N Hi. (CC'ing dim@ as dim@ would be the best person if it's base llvm problem.) I've filed Bug 263976 [1] as Ports & Packages / Individual Port(s) last week. But I'm still confusing whether... *it is because of intentional change(s) on base llvm/clang that editors/libreoffice team should chase, *or problem on base llvm/clang14 accidentally introduced. There were no feedback at all until now. Any ideas? The failure mode is error: no viable conversion from 'StrictNumeric' to 'float' The workaround without editing port Makefile is to set DEFAULT_VERSIONS+= llvm=13 for editors/libreoffice on /etc/make.conf with conditinal. Please visit the mentioned PR for more detail. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263976 Regards. -- Tomoaki AOKI From nobody Sun May 22 10:21:06 2022 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 93EAA1B540C6 for ; Sun, 22 May 2022 10:21:11 +0000 (UTC) (envelope-from fluffy@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L5c1g3dp1z3LtS; Sun, 22 May 2022 10:21:11 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653214871; 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=7+XC6ygkYF46znODWh9OiGSLL5NC3Q9Ms0pENAeq0DQ=; b=LP4GILeNNN5s/JBH42LRXN9Jxp6Y3xB1Zh6grwJA3Qpfi+dGurc+QoOJN0IbEsIVzmrihu Lp2U0tclWpUKhPVyH5CbphkzBLDX4fFR5ZcheswRtzMKJVH6HPynic9eY5Ctqv1mHljKy6 F8hdjUWJP13nyJR+0R51cqkDER0xKBGXBTbeRQ3rZWzJbs5ez+HJtEENfR8hziIQpTWC8t 3f85Vb2q8Fnjw7bknickozQwksX9M6WIDVM3U+8ii5S03zcE5NyedPGkv4TWhbrvM6Bvba rq+3xylMTku2ewHxbN6JkOuN/HL3VUkD9F3LOcIQBW5m2mQ/vnMBmYyxzwIf5A== Received: from [192.168.1.65] (95-27-194-67.broadband.corbina.ru [95.27.194.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: fluffy) by smtp.freebsd.org (Postfix) with ESMTPSA id B71E938C0; Sun, 22 May 2022 10:21:10 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) Message-ID: <2ae30822-f07d-53bd-9ed1-09a9a3b4f1f7@FreeBSD.org> Date: Sun, 22 May 2022 13:21:06 +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/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-GB To: Tomoaki AOKI , current@freebsd.org Cc: Dimitry Andric References: <20220522082951.f7385d630c23cef986b766e6@dec.sakura.ne.jp> From: Dima Panov Organization: FreeBSD.org Subject: Re: Bulld failure of editors/libreoffoce only on main (aka -current) In-Reply-To: <20220522082951.f7385d630c23cef986b766e6@dec.sakura.ne.jp> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------D76YdyHx324h9Yhb8irg6J0P" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653214871; 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=7+XC6ygkYF46znODWh9OiGSLL5NC3Q9Ms0pENAeq0DQ=; b=q3IfvEiNuAaIlEDiSG3NOvaOGfSWxyHYVyKf03rTPZod/rO56kd0E9vwcF3uMGU9Nh8b/H 9XzDMuqdGXkK4kc/fpp0ze2cpBtaSJ1lkTn6R5FPVj8hw2mVbL6jDut+xhqt1aSb835tob Q6XDKwJWZDuXSkTzAaOB534JQWZyH+JyldIPACS8LCUYINKLXWKFZwfEkRRO6YgWIakBYb uUPNguOssANFa/e/PGDFgEq0HrMjSPa6PFtSWq2NIyByG0hQ5UbusofldkCDVx02npbz89 ehoWJe+8YM5CWvCQWAJ8LziME0tcJv4JCP41v9dgvciVjrUzhiaHSRT9wq6Wxw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653214871; a=rsa-sha256; cv=none; b=akNvIjoZCNlse2O+9Ooboig13c689qqsDwzWYD7XtONYHoSrzARxJnXYCvL3kukvZF3FTi LyIskoTqPyKIu+WevZvcQ6jMbf58/N8jQiYYC1kXp6yuuTnnCv5oRsmgiY0D7MIbKfTvqD 7XJqEAXHmEtxQapMIG5KzaQRU4MghkvOwvcCT8p8G5WpTWmU1UAtF0iU0yh1aYqNl2wbP+ x+Z4dL7hwBjywjoeqR+lbjWx7anKj0TuEV0R+eNncQJSXcrZEOAvq3H7tK/AQ1YN3MEFCq +mtkj3Ku3llC3meanwdSIxoucyJIO5ckZDtXDweAVmlB2xg6cc43T5L96M+EBQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------D76YdyHx324h9Yhb8irg6J0P Content-Type: multipart/mixed; boundary="------------0S2PGxBTygVZb80TtMydOnUg"; protected-headers="v1" From: Dima Panov To: Tomoaki AOKI , current@freebsd.org Cc: Dimitry Andric Message-ID: <2ae30822-f07d-53bd-9ed1-09a9a3b4f1f7@FreeBSD.org> Subject: Re: Bulld failure of editors/libreoffoce only on main (aka -current) References: <20220522082951.f7385d630c23cef986b766e6@dec.sakura.ne.jp> In-Reply-To: <20220522082951.f7385d630c23cef986b766e6@dec.sakura.ne.jp> --------------0S2PGxBTygVZb80TtMydOnUg Content-Type: multipart/mixed; boundary="------------OeXEAbC491qs0Bt0mH008Q7e" --------------OeXEAbC491qs0Bt0mH008Q7e Content-Type: multipart/alternative; boundary="------------KkFgKwoYMvEYiFFGGYgmOUWa" --------------KkFgKwoYMvEYiFFGGYgmOUWa Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TW9pbiENCg0KQXMgbWFpbnRhaW5lciBvZiBsaWJyZW9mZmljZSBJIGhhdmUgbXkgMsKiIHRv IHNheS4NCg0KSXQgYnVpbGRzIGZpbmUgb24gYSByZWNlbnQgLWN1cnJlbnQgd2l0aCBjbGFu ZzE0LA0KaHR0cHM6Ly9idWlsZC5kaW1hcGFub3YuY29tL3BvdWRyaWVyZS8vZGF0YS8xNDBh bWQ2NC1kaW1hcG9ydHMvMjAyMi0wNS0yMV8xOWg1MG0zN3MvbG9ncy9saWJyZW9mZmljZS03 LjMuMy4yXzEubG9nDQoNCkhvd2V2ZXIsIGFsbCBteSBvd24gYnVpbGRzIHJ1biB3aXRob3V0 IExUTyBlbmFibGVkLCBpdCBtaWdodCBtYXR0ZXJzDQoNCk9uIDIyLjA1LjIwMjIgMDI6Mjks IFRvbW9ha2kgQU9LSSB3cm90ZToNCj4gSGkuDQo+IChDQydpbmcgZGltQCBhcyBkaW1AIHdv dWxkIGJlIHRoZSBiZXN0IHBlcnNvbiBpZiBpdCdzIGJhc2UgbGx2bQ0KPiBwcm9ibGVtLikN Cj4NCj4gSSd2ZSBmaWxlZCBCdWcgMjYzOTc2IFsxXSBhcyBQb3J0cyAmIFBhY2thZ2VzIC8g SW5kaXZpZHVhbCBQb3J0KHMpDQo+IGxhc3Qgd2Vlay4NCj4NCj4gQnV0IEknbSBzdGlsbCBj b25mdXNpbmcgd2hldGhlci4uLg0KPiAgICAqaXQgaXMgYmVjYXVzZSBvZiBpbnRlbnRpb25h bCBjaGFuZ2Uocykgb24gYmFzZSBsbHZtL2NsYW5nDQo+ICAgICB0aGF0IGVkaXRvcnMvbGli cmVvZmZpY2UgdGVhbSBzaG91bGQgY2hhc2UsDQo+DQo+ICAgICpvciBwcm9ibGVtIG9uIGJh c2UgbGx2bS9jbGFuZzE0IGFjY2lkZW50YWxseSBpbnRyb2R1Y2VkLg0KPg0KPiBUaGVyZSB3 ZXJlIG5vIGZlZWRiYWNrIGF0IGFsbCB1bnRpbCBub3cuDQo+IEFueSBpZGVhcz8NCj4NCj4g VGhlIGZhaWx1cmUgbW9kZSBpcw0KPg0KPiAgICBlcnJvcjogbm8gdmlhYmxlIGNvbnZlcnNp b24gZnJvbSAnU3RyaWN0TnVtZXJpYzxpbnQ+JyB0byAnZmxvYXQnDQo+DQo+IFRoZSB3b3Jr YXJvdW5kIHdpdGhvdXQgZWRpdGluZyBwb3J0IE1ha2VmaWxlIGlzIHRvIHNldA0KPiAgICBE RUZBVUxUX1ZFUlNJT05TKz0gbGx2bT0xMw0KPiBmb3IgZWRpdG9ycy9saWJyZW9mZmljZSBv biAvZXRjL21ha2UuY29uZiB3aXRoIGNvbmRpdGluYWwuDQo+DQo+IFBsZWFzZSB2aXNpdCB0 aGUgbWVudGlvbmVkIFBSIGZvciBtb3JlIGRldGFpbC4NCj4NCj4NCj4gWzFdaHR0cHM6Ly9i dWdzLmZyZWVic2Qub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0yNjM5NzYNCj4NCj4g UmVnYXJkcy4NCj4NCi0tIA0KU2luY2VyZWx5LA0KRGltYSAoZmx1ZmZ5QEZyZWVCU0Qub3Jn LGh0dHBzOi8vdC5tZS9kaW1hX3Bhbm92KQ0KKGRlc2t0b3AsIGtkZSwgeDExLCBvZmZpY2Us IHBvcnRzLXNlY3RlYW0pQEZyZWVCU0QgdGVhbQ0KDQo= --------------KkFgKwoYMvEYiFFGGYgmOUWa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Moin!

As maintainer of libreoffice I have my 2=C2= =A2 to say.

It builds fine on a recent -current with clang14,
https://build.dimapanov.com/poudriere//data/140amd64-dimapor= ts/2022-05-21_19h50m37s/logs/libreoffice-7.3.3.2_1.log

However, all my own builds run without LT= O enabled, it might matters

On 22.05.2022 02:29, Tomoaki AOKI wrote:
Hi.
(CC'ing dim@ as dim@ would be the best person if it's base llvm
problem.)

I've filed Bug 263976 [1] as Ports & Packages / Individual Port(s)
last week.

But I'm still confusing whether...
  *it is because of intentional change(s) on base llvm/clang
   that editors/libreoffice team should chase,

  *or problem on base llvm/clang14 accidentally introduced.

There were no feedback at all until now.
Any ideas?

The failure mode is

  error: no viable conversion from 'StrictNumeric<int>' to 'float'

The workaround without editing port Makefile is to set
  DEFAULT_VERSIONS+=3D llvm=3D13
for editors/libreoffice on /etc/make.conf with conditinal.

Please visit the mentioned PR for more detail.


[1] https://bugs.freebsd.org/bugzilla/show_=
bug.cgi?id=3D263976

Regards.


--=20
Sincerely, =20
Dima (fluffy@FreeBSD.org, https://t.me/dima_panov)
(desktop, kde, x11, office, ports-secteam)@FreeBSD team
--------------KkFgKwoYMvEYiFFGGYgmOUWa-- --------------OeXEAbC491qs0Bt0mH008Q7e Content-Type: application/pgp-keys; name="OpenPGP_0xFB8BA09DD5398F29_and_old_rev.asc" Content-Disposition: attachment; filename="OpenPGP_0xFB8BA09DD5398F29_and_old_rev.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBEp+xiUBEAD01RkOYcyzU/Fnam2FI7PPwYqW00SwVmfUHihvVniiaMwzaYzc hb+mzShaNsqRgjIN/i59OBpnS25OXMLEpQP7jDJnY2xKyJN2H4qn1HPHkF9cYuqv qkm+r5459g+2ZoGY9Sr1PA0XSzXJMSQ1nRK3cFfqlN/L2//P36U5VuOWXGZUTwr/ n2B/N0HAsYsqDOdjofLg7x9z8p8elqwJbT/O4ltg8JBVAnof+FzqefYW4CzqkHRj q/9ORiGYh14ST9ECsCaVpfdDUTor0wgpJqzCN1HsQcHqgdMmOqigWIgN7Eg4MRQU 3LDCISrNJ/45zvcKUXR0RHOjnSuflYba74q58XhZ4eCTqHeMHjA8st4IWRzy9l0V 4RunnZxjOTb806jyIhdxcb2m8o5tXwsqjf0TQ7vYowDHrQ6gXlhPg4Jvvwf+BwlB 2p+w7Cs/Y9QA0YHnIOIVZAwU1wv66YSI9IDL2AbnY2gQGx+dkHiC3S5LG8HcPrMc jayyThKKIi5KQsWa3snFeK5ky+cRpVEOPQfUXFOas++91v90Xe9j+lsmRofsyvuy gzoaZE2fud0kCsOgYEg+kiLPlQicNAx5IToOs8BrVFLcxmbPKuVBfbLdWsYLjXGz bXEmzV9fNDZ1r1uNmVema8YYCiNjUDZhxIfKt8nbp6cx8UgVLGRVDEfXeQARAQAB zTdEaW1hIFBhbm92IChGcmVlQlNELk9SRyBDb21taXR0ZXIpIDxmbHVmZnlARnJl ZUJTRC5PUkc+wsF2BBMBAgAgBQJKfsYlAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AACgkQ+4ugndU5jyk6dhAArHclTYjwVRjDnoRfO3Zfj9Ssab9Vrbo7DNFWeAqP E3OTCmiq9Q0fzRHzmhVyedYMm9qNA3i0J1De3KTnLanXOrBIqsmmZpSqmrp/xXdZ ngDLW5H6hpE0f2PeAPwxrb9uBQax8WMR7Z4STSHAP4GRjve30wNNS0MlawGllcs9 VKRxG5PsDA8k3ACTSjdpQ76RWldORN4LA8M40yHRX377SGMzO+XsCeOwad65GKyL rx+6Gnd3PMOjVCJCrqd04Jgqg9G0xKNImchwIZ5ulx9jAt+ixfNbY6hwslleqimr 2t5+MMqo6dRrvJ+BsR8NHt9vGi2Jy4+4smg05fR18fck0Sk4vCYyVvtvnOk3qZf0 F8zJu06GcjWWC2ZbDPbmksWXFIMxoJbyVxK55xOqcFs0t12sR6gbVJb8Nb88WrQu b3MgePyMF6R3TkfaOqkjvQur1xC2AXESTxtJw1FkdGSb3UopNKgvSPHSLFW8B0Lb yDxdYRTRWPGGEUhFP6tdXi5Rvb1210ks2EQAqF4Cm3iRIhYgtZvQqQgMSiO9fVye J0U6dYGDtg2Boi+NtXKRdmtL7pRSnI3nfAbVJ05Hhd7PBnJeob6R08nHRo9DdAG7 o8ToM+egUAuEsEvoRV+v4f6k3mShdxE7gG/anwVyeh3n6LGwg9KHDr1X2FODsLLx gUjNK0RpbWEgUGFub3YgKGF0IEhvbWUpIDxmbHVmZnlARmx1ZmZ5Lktodi5SVT7C wXYEEwECACAFAkp+xywCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRD7i6Cd 1TmPKb5kEADatAL8Hq26Uaqb8hemnQ+YAqVPhRvELz2Yi/RoLlscY39i6OelRyEL dzlfrNCfRl4et6OT1fSuq9b950mfR92Ah5J3uvaySD4bpz8rvzzSCKkP3xGpdeS9 tr6JTTvyP1ySkWOcOJCb2CXEmKch2+IJNNXfXcCppM3+yzVrClF+icwlBTH8F0mO FAFqEEUzSoX5hXRrLp+/qcavQPtQszG9AhuwWcAqfiC/GnCKfLhyDIUaEmBCMH8h Giff0GyIvkyoskmAY1eUUHg5XUQai7FtWH5iuktl9aLmuOiXglNubE5T5RWzyQvy elh9f4MSo4tlq5iPIuGmFchazJzsyck1ytDOs+zkeWRmakjz2Sj0s07CLPv2d2RZ xtqYJyi5ZUxGEfmnWlINAIsXaRElM0zVXibY+xLVaFU/JzpA2TVaDHG6OEJoQfps LFLxEOboygULRNMBUCufLwmsLOr4ITJRP9T5Wf38gqdjXAm7C1MWG5DPEt+lzqyz c/TSXxwdR3xw/zlxPMLMiKCIjpfcSoHjDmzz0iTesGhxuu3Qb7O6rbDhUAV9bgXc Mi0JlDLK8mAyOY733XyC2S18FTrNvJ/opr3ROHzJ0g/ojT0QzkpspPbpgf0DNn8v +gEBZKPyg9zuP3bR7dj4M76xf1yKlu0WDIO4NGWdnmAqO99nc5AhIc0sRGltYSBQ YW5vdiAoYXQgR01haWwpIDxmbHVmZnkua2h2QGdtYWlsLmNvbT7CwXYEEwECACAF Akp+x3kCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRD7i6Cd1TmPKREzD/9A NKU02qbh78yaccFZqvjyVE5Ysdo+HDOCtxcGKVxsVTiPJubLqv3KiCIL8alemZWG lLi69wnlaSAZiuB+5l6Y+gWYFrFstGAY6PPuyeQcQxaGpb5j23PbADaOrqfIvVyO B4Ld2fPm8r+t0Bwb4P8epmbG4mOPjJA+w9Eq7KMwFK0vIGuCFIOfK09bKNkjEgMY r/1KG28uVw8CKyQj38ACn1oojpV01E+SpbldHqFUoGkNbba4ojnZVST1IzO09V1X 4dDs4xGDvnJ04iSeifiTNYEjDnGbVA9TMFF4cUuV8dVeJQrc2+5iE3H7mSFLNCe9 DjFkmrRV+AnCn2bE5GYUiYA0o9N5OwRICmz6BhNZUMWVVGytQy0g4pdmxNSkAiMC A8FzCbY8BCn6XOOelF0EsHug5bqGvaKCn9CyoLEHhnZ6ttzJlpYO4AQlds3Rvi53 HouowEbWhQQxhiKRfvKPVwpXphR4PNIgkLXckv5MJD1IPL2eyzWCYdBY1lCCTA8s dnzdk7WLfDJzyAk5sEbf+mlGhywHKsu87yGOckEVKH2x6L0WGdroY5IfR4NMhzGQ OPDuLnX0r+SY/R6l+5vLyf7xni+VNkNpxt9PbVLt+JfdIbpVIe7HvQoxbBpqwy7B MAq23N31gROI6N31i8bAayoQ8YC8CPxH2E4J4bMIyc0eRGltYSBQYW5vdiA8Zmx1 ZmZ5LmtodkBtZS5jb20+wsF4BBMBAgAiBQJSaeszAhsDBgsJCAcDAgYVCAIJCgsE FgIDAQIeAQIXgAAKCRD7i6Cd1TmPKdlwD/93hdsd8b8SFwfWJ4UD5ruk6/Ajfjx4 kbORZO935npFT8hNs0A8ZF24LqHX9Sqa0CASpVWMjGQA7gTbvPlTk0i/V0UmvCqO 2YG3Zei+HXfICbm6si8YtjFZRXZHpqePtV9aPvSucegRItjtXCfS3IKEZhMyJhNt Lq6bTgjAFeGbfKCdH4IBtFYc9lTgOreumM02tFYzHnpBa/bVPz6qOmXs3lztwSNa skqLuvHym+c9VSyDUfu3B+NN4vS/eeJOuHnCzM080T6CoeL0GXWHKvl22PcN1fOk N57WukxiaW5PO/wIKWWB2rAlyZj2+Q8KYhKc9iP5EMIL9dJXNNSeIfGpcUJauUKf Yg7e7P55ZMrF1TLlb2sCdEN5xcnKIAN5Rowz72fRjumzD6eJbx8/+6Q5tKuJpH47 zz8dImXVpIpiM2ZR6f6fN3eqvzieAFTIcH2rJ5LzrOWUX601rOICLhu3UrsQpVwx yCzpP0S8cyZkq3xmCzV3HSu4gun2yIJXpCxxjvXTxwgbX5J9ezY99yhjrVR9982V e35U5EyE5XAN6+bXK21g2k10dLhHL7dUqgiZGMju9mLz4bd/z+W/n8eupkiwBC3T pp0ZOS23iqjk2UBLaRI5J3nrrC5QbTh1goW6WIHwB6+NaUzSP5tejeYzEJJgmn2o 4OHx0Wg/XncT480/0JTQvNC40YLRgNC40Lkg0J/QsNC90L7QsiAoUGVyc29uYWwg SUQpIDxkaW1hLnBhbm92QGljbG91ZC5jb20+wsF4BBMBAgAiBQJSaetpAhsDBgsJ CAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRD7i6Cd1TmPKbXcEAC9fJqDCOfW7CS9 SACUZJ8pSxrFzkNNTMqKODPiJ+NSaD9jH6m9DqMP1B3Xc+Gj5ieSycmajOff4PYU A+XTHwBjNg3sLsvsNjSHDeHOJi2JJKeMWRBE/7JlTS6gkPedOLBk4A/wQ5d/GbvO wUk5yj+bpqxxIraE24Rs64m/NqF1muWcIZvr5eCmE7JnPYmCPWiVOYTAagflEuDW ja0t2+0li4vy1N8j4thsxB28ELgdtFThHe57ZlXDqgKd0o8kJiDtv/66Q+8DPfEQ 7iWV6UlSw0FcJruPmhBSNvFHL2A8wrQaPhz9WrT1OO9ZoKf/TjT5ARtwS0bcUvqc WdGJgXtWrk1fCOXKYYEO2JitRB+pXD0OIB8si3zFZrCHzbAVGlrt1JUSH/mXdlQ1 HyiZgiOECVfMrI5mLml/SgzRzJOhBkkvMOT1SsNBFMFWX51LVKi5nR1wG7TcqkQo dBhvpc7rvb4kpyv+6YiBlO3UvJ6fgQhUEca/H8yKmLlumvPqghDHtvJuG86rRUCO llxwmFHpxgrAdfpIpdW0ngHacwRXZK16DJuw6aEf5aWFIXBq+uX8CDYZWoZ0GHrm KbM1TAK2iAMaSTPWawPHX7VFiwTfAijyvqVgayqzcJ06N/6r4c+hVG8lGJF77Zgc MqHDptz1aPA3TaekIIUHEWl3l8/e480/0JTQvNC40YLRgNC40Lkg0J/QsNC90L7Q siAoQEZhY2Vib29rKSA8Zmx1ZmZ5LmtodkBmYWNlYm9vay5jb20+wsF5BBMBCAAj BQJVbrwmAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ+4ugndU5jym3 xhAA5u0rVHXCXkf6XeUUe1CG2AgJFmgDoAnJXSMGeXwmKnI2mpSxe1hrNyqzRYfZ zG+wUc3kwaVh73IxD+OVqN0K2Y5X2vjmiTxj3qzPb6EkVzf0MhrYYHqIBuhDf1j2 O8spuF3EBWP5Y0shuq5VrxJ1a4zHgQHrPZabpN+znB1lGAtT107la6Q/fF1V4+eq 0qGTv19digf8HGT/DtnXKgDHVXQLzOEq2Ds44XRriFwJTCLQHBTED5N82yJtDmEo vVPbXDKy/p5L8PDKP8fWefe0Qnl7VA6Yp1+RbYfYTt9ZqNpBDanMdOykEczDdzw6 N1c+h+nW7b4RXLUaE9m74mdtEZrsczqYrk8BNRnHGpMn7qI2bQvqq2/6V53YYKFr IObh5TTSMRGNh2hUJZepS0lk5gWY3l5AmU3yeB0Qrz1VbfcbafQocfTDzeYopDOM oAG3o/ww6wnofbDehkUxL/Os1IL0HkeFOQMFZcnqXFcUBQC99oabFZfkJqxBc/yx EYnRFE8r/vY5oO73TdXQrU8GzUzNUB8ZZMTCHhpoWuk9H1HmgCbReJScCmh0ZwWt oLMlG2NPKsW2gcUVy3JTcO7wpOadTMTl+tgPnGoGcrWY6ak32e11eblVBe927kvx XkSoPvgn8uPR6B4Q5lG/Q0d829Oo8CHYIXKBA/lxEltanKvOwU0ESn7GJQEQAMBT MHQgb0vcPMAiRvb357ihlh/YYA22FXj4p3XTrDlBlRL0QCRq1I8XDeQmL3mG3s3N BtDXSefnNM06jZ3XCAfHIDBdxJJvQZZCXfvLp/JK7nnEuqoeqT6/oKs1MeZVdUnv h1nZhphs+Z6dl01GIE8YDpzT1JMD2f3G9PHChGi3Ddzqm3VdXt/87khYJkPbaf6E N5+vDthKgMjba8jwbQ+7IUPqkfnNFIZS6irZ2LYb79BLNI5JSl9lReSfEX2d8ByQ lLzuf0TS4voy3nWGeCyj6BIOMiRSxg+hZmJLYxhNkyK4GQVCt/rLT7dIfBQMsyBb X0Qw2NOcfba9VgdPZBgdrawwB4/xF9SA3NB0J0lUjhjpH9iG8NxlpleEg8OSUApy FZEJq2A/flns4kKzNH7AGYDOFORytDzA3qkgCJrZ7nzQSsdtZ2qbyAoze0tl+YrS hJhOcmQBtFemomhWVeJ8T/Bw1KH8M1ihrENBTSzYzLvN18YjNP6P0Dh/7Zda5yYI 8fNqd84K3Uq5xBiI0S6+qxViw84z2tJj8TxiNqFAk7Tbeo2Ximtq7uQ9UnFRSK3j w96yi19KU9rQQZs0xUjN5gn/tF5lBZWKjwuZCkcOiI0EWHAR+ATAEsFNXcuoC9CA GK5HFW4nI4WtE3pv1KYvivlGtF1wzf0QrhyeRrmxABEBAAHCwV8EGAECAAkFAkp+ xiUCGwwACgkQ+4ugndU5jymgKg//RvnI7zEDKv6nQUqKRyLawPTrCKCtQ2vSoWyT NgRB6byNS1w5wNSAMnqaESx2bdhauaxe167VEJYqgQy241yFslpC6v/xlH25Ppos +Jg6AKaQG/JABHO6Co4tHtBbNmM+14HESxAodA4NJuEU19iIPjRhUKC8F8R9xBmW 1uLpPiljU9Km0P3EIKjAdtdZNeMLhwsbSHBwJROFrxFGiTzWNREWZoZpQxgSbHYh wYbxHEbJi1cybl9IQvSGHrysctZsxD04Jxh6ogaziiT8aV6ear6BNh008yRf61Fv rinfG3USLR3iJO8aHap4QGCPjZ3cyT+DEq8/zVfDdeidTeNEhSgRKk856RcA+yAE 79KYdKkvmDUiC8poAJ7FGEYHMB+g/1+LczCr2g9GYkiB/53boYfU9esYYlarxCge dCrwXv6T48FZ3xxoH3XJ2KV8K6M8CUb04jj3kEeCwq+R6Bk2ZXrnMzyQmmn223X+ Zp89B/gchH32JY8y3j7BICcoZmgMu62XNMgWI/hRgfi3JlVCne6XPj3/w00JYG7v o+eTJOflqYr3WRTPYh7DxzYtshZswHmmkZtwizUQUZzF9dX2CM8nY7cKucEmtcnU pjGwXMOufa/DmCTlk8ggRZ0ukCUZOlIA4ILxp95sS2oqyucARv+pwMWvrqJ/LfbZ exSsIjLGwOIERVFagxEEAPOvrde0FCIYgD3xQDPYAdWGD7kTut/gqFFHPAgXCx2p mEr0StQSn4bblBdGqPEZiIQ76gLmcWeTt/Mdc9MuC8XzSCijAF65zz0jlTKIt4yh j22QsuD8zb9SISv4thfcEDO9lIgYb4hnpwgOCkYTJp7LTeShCQxRIiAdzfytOx17 AKDz6NCgiqDLGbPTDnsdqEbfBgmHYQQAlTQCnqJKaScuI8ThrZthRdQrWVIblIyj wLzt2RRTYFWCofcrs8pgBQhrAk3vg+C96EobaKr0AuzIv+hfkbzawpmOBogmtIEz D37KmnDbaV6ylqzIrYZdX7mwrRAp841QBQCp5c0fmTM0jWOa3fW/rWjUzZdzRtV4 rfBcYKL1r6sD/iuWxn98cumJKgq19IQYLWEoztduoGY4HbyU1CPXglAlkHoE4XSj n3t1YddIBAXU1Rl80buG0Ov+jxKhVA4s36rCzb3TThd/II4wKh1THxQL8/Vtn4+j MXyX0MmHLEPRmhENPQOunLvWTO3V1BqkNngHDKhNUt2yAzACxP/524cYwkkEIBEC AAkFAkp80gECHQEACgkQpiZ27ZPjsBhfYwCfUtv9ehaUPRH5c5ozNR0o34uTApkA oN3DzKFlQkZeQISOOdFG8GLBdwuVwkkEIBECAAkFAkVeC/ICHQAACgkQpiZ27ZPj sBhusgCg4LU23MNOcb1BXDzZbOAxx6L8WZcAoKl+3eN7JEHZqxeLQpUzq4dYtIt+ zStEaW1hIFBhbm92IChhdCBob21lKSA8Zmx1ZmZ5LmtodkBnbWFpbC5jb20+wmAE ExECACAFAkVRWoMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRCmJnbtk+Ow GKSIAJ9bmwywJuJ53N5Ebi/P7F8YSJi/VQCg0wNR4h4sYrMsffGqm4WqbeiHOo7N K0RpbWEgUGFub3YgKGF0IGhvbWUpIDxGbHVmZnlARmx1ZmZ5Lktodi5SVT7CYAQT EQIAIAUCSljD2AIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEKYmdu2T47AY 6uMAoLCrnoStn+QgC2HRkk3/ucYmM2oVAJ9+1jnUKXSOApvN6MEbbeRJ2qWfBc03 RGltYSBQYW5vdiAoRnJlZUJTRC5PUkcgQ29tbWl0dGVyKSA8Zmx1ZmZ5QEZyZWVC U0QuT1JHPsJfBBMRAgAgBQJKfNETAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AA CgkQpiZ27ZPjsBhK+gCgoB35KL/jPwFZqJK3OdTCtE8UvioAl0EMO6fEe+QBshu8 ZJcR+pGSbkfOwU0ERVFapBAIAIuGs7g5f8z8tMfxvSmG8BxhR5P9DiwHGg4XP24O BAo9eXQZWkFsSfsqUEtwhOtUMS1+XsCauP5h+UCZpbCxOfJFc6jktj93lLn2nM5R ExWp7ulCKHTT3EWKttD6alFo/xNpmJUY8Yf2yxuIQDfUMzSo5vLETURybPQqD5nk h/qyfFjED60ZdlhBSKEXGyIWsnooHE/UHlQiEzb/BnII4Y+OsURATayyTCMu2vRL 6sk2V0tI4MX3so5dLpxSGRr5AZrZU1Vq1UzHLuLvBZkPR7KEUM1tKN9oxDlLonUR IrbuL4/tyW/aaiINh4WJebbh/x+o9JgEk/waZYlVj4HFZosAAwYH/RB2xiNdQOhH 6ABXUgT6iITg6aH+um0xbyVNRHEXsVhmbLgSDAtJyfoa/KP9vQFDjPS+O/o1a1dT LWqWKZH2mVvQaItwsx+qAXDlEiC96zetidafTVHFfKznbe9Srz9ocIt0kHQSU4M3 0VLUVwNTRZt+8fLOmctw+cGlx0CW6RMCMH63kUqPQso+WytLdvCO/UN1lECOrYhW zeQTPm4D0IQ1AUg2163T6Pm7f+LSr6Rhphkh1K4Ivprqk8ubp7ZzlrKuhToSsERP VmFJ1N8mP9UA2MxmSHVB94Bmse8TyB5Uu91DNQt6rQ45NI7jx5C6ohcwdqoPukhc If02wQTnstrCSQQYEQIACQUCRVFapAIbDAAKCRCmJnbtk+OwGPcAAJ45LZPpB21M E5CUNNrSsvPF0v0XAwCg4br9QmhpEfiiKI8I8NLc1ZDf7kU=3D =3DjlxC -----END PGP PUBLIC KEY BLOCK----- --------------OeXEAbC491qs0Bt0mH008Q7e-- --------------0S2PGxBTygVZb80TtMydOnUg-- --------------D76YdyHx324h9Yhb8irg6J0P Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEELTAsy5mEEwxvh7r8+4ugndU5jykFAmKKDpIFAwAAAAAACgkQ+4ugndU5jyk8 9w//Ue8lrwulmBJdJdDmkpXpo9Kv9Hndz0M0dm8403jmetg8FEnqN2pQGtfg3seXgB3kwmlGwlc1 +UKPIYJfJZnN2JF8ng3tOwxZ+yAOAXMVJiaMKrHZpU73iGZo5Lh5MgQIf9KQvMGIZya/5BK1wOPt FwakxsRUSdhDRyt6RlvfhIpE06YvI6oS8Md/CBFI/DwSf6U1HE5iI4gYIP4PChrxwOIKFTdjcXUB r+0oX+gGpcYlLRU6h4NG1k9roGTgWNJT60a1pSQs0w3unQFMXR1AoWhxpVKbfFze6KIKg+hlub9D XiVkj9WC2KHn3HeD7OtwK3K4sE9cRbHOeFlqVlyy/JmFgYt1IY2ddqBUMetybxY3lOhgVAhPW70a 4EW2o3TsBxRDbTy4VvrjyT1tgLxebiPYFMZLyYy+qtTXl6hndkzQMghv+wUJfGp7F+8w8JXZacTT Sdck7VYF8zZ1Q4Jug/uZKNx223Ne/aKtSq0hQxGiHV8YSTLBAdSIH3CpR9N6WAb1Xt0slVOeOKNl rhEpABLZo1We3GcjTWaaWzFMNzgUJ763dJysOZmbkA3lqAcoRncnuEZ33FjcCYyO22W4BfPoqkdS IL1PYwLbscc9Xi9hyXYX6CLkPLidBEzh8YjLJp4x2Aqn+pJZ+IgOwwcmNYBt+oqZQUf0mZo0P+uZ dM8= =0cLD -----END PGP SIGNATURE----- --------------D76YdyHx324h9Yhb8irg6J0P-- From nobody Sun May 22 16:08:12 2022 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 2F1841B4576B for ; Sun, 22 May 2022 16:08:24 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L5lkH2397z4lqt for ; Sun, 22 May 2022 16:08:23 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1653235692; 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=yWUxgFnzARlK3yMYDen1/e0LTUw2x8EXm0tdyI+46KE=; b=FgxD9u7VbxmvVERjFaP/NibMJaJ+pPalRJ3GKYwGQyIuZHUkpOuLNcPAvr8w76Px4xnTIv dy+jcOGeiubvC9R72u5C6yrRrTdRka+xjIzNUFC5jH+nreypMacY8dwWXtSdyR/7byZkkK 8BRNpsCK4BLIFz22Ludy4ZQB+c4zGjY= Received: from [192.168.1.223] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id b747276d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Sun, 22 May 2022 16:08:12 +0000 (UTC) Message-ID: <279458c5-74ce-55ec-9dac-de4a064243a9@nomadlogic.org> Date: Sun, 22 May 2022 09:08:12 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: FreeBSD Current From: Pete Wright Subject: no hw.acpi.video.lcd0 with graphics/drm-510-kmod Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4L5lkH2397z4lqt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=FgxD9u7V; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N hello, i have a lenovo P43s laptop running current.  i've noticed that since graphics/drm-510-kmod became available hw.acpi.video.lcd0 ceases to exist (which makes it impossible to adjust screen brightness).  i've installed graphics/drm-54-kmod and things work as expected.  previously i was running drm-devel-kmod without issues, so i think it's probably an issue with the 5.10 driver? i can file a bug report for this (or just test out patches here if that's easier), but wanted to see if anyone here had observed this on other laptops first. cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Mon May 23 07:18:46 2022 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 300751B32CE2 for ; Mon, 23 May 2022 07:19:01 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L67x01Dt8z4ZGZ for ; Mon, 23 May 2022 07:19:00 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: by mail-oi1-x22a.google.com with SMTP id v65so16779315oig.10 for ; Mon, 23 May 2022 00:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L2R8126EfXngHZRh5pIsYFSIr6+drBRt1ckhnP3qz0U=; b=J4oK1zoRsO9aMOJw1EK0v2D/OCIhl0TJBeI8iiU+feEqAmTfUpAYDo40uYcQo4aSOj PNcbAbM074VfnPh3m1FUjOLWNHp0+CZf7zw9bqhk9WnoW1ksOC3a61Vdpwf/mWyPUxwz 8ONkCWVJd2NiFb9yh0wAXQMIj2zlSeM16Ru23qmJ6mq6U+RjOeGma0sWC0t3DnuJ/yz5 2UJ8nMyK4UrMyc65TJIAgHI2yNotamh7O8O3PpLX0C/GNvNNryAsKUIrexVxKBsM6PAB oQh/O1ve84TDWH5Y45rG1UA+ZENXmneeLmWjwb4mGyi8L2RT4Fhl0FO2ZnaJoS9O7gBs 6V9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L2R8126EfXngHZRh5pIsYFSIr6+drBRt1ckhnP3qz0U=; b=aZVrLhn+UqoT2fQ6cfwQW2lcJhwZMkgFjudSVlC6Mucc7Ur5W/gXfcWrvE1IgTpdOu AdX02ziyDmBPxsmA0yCAXF9YhakIrtk2DFiYaahYgefMN44YEoQsyOEunA8bQq0RHxGk 44awesJzs0Cj66zkgY3IRvIGB9yMl7an/BDb7JAefSMCdsDdn8Me3SsvjYhY04gXOjC6 P2cUWx38IktI6IVWsOP+RuDT3JHNow9QZfvRH6W0UPd06HWuOFNOzQIbpyC94zC6GWP1 BF2yAgJ2Lsy/T1kGuYhxnUf0qOKXYd5LmM7QMTS9xUsfWUR5WoSza5yK5KvVxIit05QM kTHw== X-Gm-Message-State: AOAM531Zo/m9elIoPXCjRrT6bNTsKI0j8zc50gCWNcJl+jDNhjl5WKHJ KEfLO5TQLdZe4uV0CtBQ/qQ821/tHFgMkBKgMZqMiZGtxTc= X-Google-Smtp-Source: ABdhPJyUE6xML41fAQ0472LFVG2FUheVj2eUcD0C4njRizfoBr91EOHReWiy17Od7vBRQ2IfmpUgD1XHJEwbXRe+KLY= X-Received: by 2002:a05:6808:219c:b0:326:4456:d0be with SMTP id be28-20020a056808219c00b003264456d0bemr10742181oib.79.1653290339464; Mon, 23 May 2022 00:18:59 -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: <279458c5-74ce-55ec-9dac-de4a064243a9@nomadlogic.org> In-Reply-To: <279458c5-74ce-55ec-9dac-de4a064243a9@nomadlogic.org> From: Maurizio Vairani Date: Mon, 23 May 2022 09:18:46 +0200 Message-ID: Subject: Re: no hw.acpi.video.lcd0 with graphics/drm-510-kmod To: Pete Wright Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000064f94d05dfa8a7c2" X-Rspamd-Queue-Id: 4L67x01Dt8z4ZGZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=J4oK1zoR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of maurizio1018@gmail.com designates 2607:f8b0:4864:20::22a as permitted sender) smtp.mailfrom=maurizio1018@gmail.com X-Spamd-Result: default: False [-2.05 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.95)[0.950]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22a:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000064f94d05dfa8a7c2 Content-Type: text/plain; charset="UTF-8" Il giorno dom 22 mag 2022 alle ore 18:08 Pete Wright ha scritto: > hello, > i have a lenovo P43s laptop running current. i've noticed that since > graphics/drm-510-kmod became available hw.acpi.video.lcd0 ceases to > exist (which makes it impossible to adjust screen brightness). i've > installed graphics/drm-54-kmod and things work as expected. previously > i was running drm-devel-kmod without issues, so i think it's probably an > issue with the 5.10 driver? > > i can file a bug report for this (or just test out patches here if > that's easier), but wanted to see if anyone here had observed this on > other laptops first. > > cheers, > -pete > > -- > Pete Wright > pete@nomadlogic.org > @nomadlogicLA > > > Hello, to adjust screen brightness, on a Lenovo ThinkPad T450, I use the graphics/intel-backlight port. Regards, Maurizio --00000000000064f94d05dfa8a7c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Il giorno dom 22 mag 2022 alle ore 18:08 = Pete Wright <pete@nomadlogic.org<= /a>> ha scritto:
hello,
i have a lenovo P43s laptop running current.=C2=A0 i've noticed that si= nce
graphics/drm-510-kmod became available hw.acpi.video.lcd0 ceases to
exist (which makes it impossible to adjust screen brightness).=C2=A0 i'= ve
installed graphics/drm-54-kmod and things work as expected.=C2=A0 previousl= y
i was running drm-devel-kmod without issues, so i think it's probably a= n
issue with the 5.10 driver?

i can file a bug report for this (or just test out patches here if
that's easier), but wanted to see if anyone here had observed this on <= br> other laptops first.

cheers,
-pete

--
Pete Wright
pete@nomadlogic.or= g
@nomadlogicLA


Hello,
to adjust screen brightness, on a Lenovo ThinkPad T450, I use the graphics= /intel-backlight port.
Regards,
Maurizio
--00000000000064f94d05dfa8a7c2-- From nobody Mon May 23 07:37:45 2022 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 E365A1B383C9 for ; Mon, 23 May 2022 07:37:48 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L68Lg3rZ3z4d9W for ; Mon, 23 May 2022 07:37:47 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1653291460; 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=3Rf1TegvGhnLWX41r9GBip9WW2IlXwfQOvElbwTckH0=; b=D9TZWtCM+qcJuKuP8ShR8Hgyxe1zR2ZtkXPzST4+2ECLofYPCl84UjWXqPAg+56vkVs5Gj 8g2MgUo+spGZv3mwIB8/9DwBeWue7+bcGzESSg9770EDecYzAPgjIn0AAiSWmHP/TzIWIB iAmaAL+tuh97AOqubrsABBaTV3PnaLw= Received: from amy (lfbn-idf2-1-1518-133.w92-169.abo.wanadoo.fr [92.169.82.133]) by mx.blih.net (OpenSMTPD) with ESMTPSA id ef91d180 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 23 May 2022 07:37:40 +0000 (UTC) Date: Mon, 23 May 2022 09:37:45 +0200 From: Emmanuel Vadot To: Pete Wright Cc: FreeBSD Current Subject: Re: no hw.acpi.video.lcd0 with graphics/drm-510-kmod Message-Id: <20220523093745.ab74225307d0ec8981849acd@bidouilliste.com> In-Reply-To: <279458c5-74ce-55ec-9dac-de4a064243a9@nomadlogic.org> References: <279458c5-74ce-55ec-9dac-de4a064243a9@nomadlogic.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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-Rspamd-Queue-Id: 4L68Lg3rZ3z4d9W X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=D9TZWtCM; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, 22 May 2022 09:08:12 -0700 Pete Wright wrote: > hello, > i have a lenovo P43s laptop running current.=A0 i've noticed that since=20 > graphics/drm-510-kmod became available hw.acpi.video.lcd0 ceases to=20 > exist (which makes it impossible to adjust screen brightness).=A0 i've=20 > installed graphics/drm-54-kmod and things work as expected.=A0 previously= =20 > i was running drm-devel-kmod without issues, so i think it's probably an= =20 > issue with the 5.10 driver? >=20 > i can file a bug report for this (or just test out patches here if=20 > that's easier), but wanted to see if anyone here had observed this on=20 > other laptops first. >=20 > cheers, > -pete >=20 > --=20 > Pete Wright > pete@nomadlogic.org > @nomadlogicLA >=20 >=20 Not sure what's happening as this sysctl is exposed by acpi_video(4) and not related to drm. But you shouldn't need this, backlight(8) should work everywhere once drm is loaded. Cheers, --=20 Emmanuel Vadot From nobody Mon May 23 14:59:07 2022 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 67C9C1B4F39B for ; Mon, 23 May 2022 14:59:16 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (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 "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L6L834RvCz4bjb for ; Mon, 23 May 2022 14:59:15 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1653317948; 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=vUA77dWFiqvy6+8AF517wCuPEX590+lHwpDe93AhlmE=; b=qdvwJubbb3XFqHobckXXkQEGKZfwrZLVu6AXBIHJobdbnW6LVG/9ZkR8XPdNbaFPedJInv wZlwK3+poRkYCu3lIxE78UHLQe32xwpdADSliKPtLJ86dlmk7rgqLTjGF4GW1ZEv/S7kjv 7jAVbc1bPg0ela9Bu4XPv2q2ij8m+m0= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 5ff7cdf2 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 23 May 2022 14:59:08 +0000 (UTC) Message-ID: Date: Mon, 23 May 2022 07:59:07 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: no hw.acpi.video.lcd0 with graphics/drm-510-kmod Content-Language: en-US To: Emmanuel Vadot Cc: FreeBSD Current References: <279458c5-74ce-55ec-9dac-de4a064243a9@nomadlogic.org> <20220523093745.ab74225307d0ec8981849acd@bidouilliste.com> From: Pete Wright In-Reply-To: <20220523093745.ab74225307d0ec8981849acd@bidouilliste.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4L6L834RvCz4bjb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=qdvwJubb; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-2.97 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.03)[0.029]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[nomadlogic.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/23/22 00:37, Emmanuel Vadot wrote: > On Sun, 22 May 2022 09:08:12 -0700 > Pete Wright wrote: > >> hello, >> i have a lenovo P43s laptop running current.  i've noticed that since >> graphics/drm-510-kmod became available hw.acpi.video.lcd0 ceases to >> exist (which makes it impossible to adjust screen brightness).  i've >> installed graphics/drm-54-kmod and things work as expected.  previously >> i was running drm-devel-kmod without issues, so i think it's probably an >> issue with the 5.10 driver? >> >> i can file a bug report for this (or just test out patches here if >> that's easier), but wanted to see if anyone here had observed this on >> other laptops first. >> >> cheers, >> -pete >> >> -- >> Pete Wright >> pete@nomadlogic.org >> @nomadlogicLA >> >> > Not sure what's happening as this sysctl is exposed by acpi_video(4) > and not related to drm. > But you shouldn't need this, backlight(8) should work everywhere once > drm is loaded. yea that's why i was confused, i investigated acpi_video changes and didn't see anything obvious. before i started trying to bisect recent acpi changes i thought it would be a good idea to test the drm-54-kmod port, which restored that sysctl knob.  sounds like i should continue to try to bisect the acpi kernel changes under 5.10 and see what i can find though. cheers, -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Mon May 23 15:53:55 2022 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 AA1CF1AEA05F for ; Mon, 23 May 2022 15:53:58 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L6MM95SQ3z4lGt; Mon, 23 May 2022 15:53:57 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-111-80.area1b.commufa.jp [123.1.111.80]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 24NFrta7066803; Tue, 24 May 2022 00:53:55 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 24 May 2022 00:53:55 +0900 From: Tomoaki AOKI To: Dima Panov Cc: current@freebsd.org, Dimitry Andric Subject: Re: Bulld failure of editors/libreoffoce only on main (aka -current) Message-Id: <20220524005355.575d32bf574c834cc7305867@dec.sakura.ne.jp> In-Reply-To: <2ae30822-f07d-53bd-9ed1-09a9a3b4f1f7@FreeBSD.org> References: <20220522082951.f7385d630c23cef986b766e6@dec.sakura.ne.jp> <2ae30822-f07d-53bd-9ed1-09a9a3b4f1f7@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.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-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L6MM95SQ3z4lGt X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.51 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.915]; MLMMJ_DEST(0.00)[current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.111.80:received] X-ThisMailContainsUnwantedMimeParts: N After some discussion with Mark Millard on Bug 263976 and some tests, I've changed the subject of it to "editors/libreoffice: Fails to build if LLVM_DEFAULT=90 (default) and LTO=on (non-default)". With LTO option enabled, port default devel/llvm* (now it's 90 according to Mk/bsd.default-versions.mk) is forcibly used, thus causing this problem. So overriding LLVM_DEFAULT to something safe should be needed on editors/libreoffice/Makefile. Currently, I've tried only 13 by putting if ${.CURDIR:M/usr/ports/editors/libreoffice} DEFAULT_VERSIONS+= llvm=13 .endif lines on /etc/make.conf and it helped. As some other giants such as www/chromium and www/firefox are using 13, I suggest 13 here, too. See details on Bug 263976, please. On Sun, 22 May 2022 13:21:06 +0300 Dima Panov wrote: > Moin! > > As maintainer of libreoffice I have my 2$B".(B to say. > > It builds fine on a recent -current with clang14, > https://build.dimapanov.com/poudriere//data/140amd64-dimaports/2022-05-21_19h50m37s/logs/libreoffice-7.3.3.2_1.log > > However, all my own builds run without LTO enabled, it might matters > > On 22.05.2022 02:29, Tomoaki AOKI wrote: > > Hi. > > (CC'ing dim@ as dim@ would be the best person if it's base llvm > > problem.) > > > > I've filed Bug 263976 [1] as Ports & Packages / Individual Port(s) > > last week. > > > > But I'm still confusing whether... > > *it is because of intentional change(s) on base llvm/clang > > that editors/libreoffice team should chase, > > > > *or problem on base llvm/clang14 accidentally introduced. > > > > There were no feedback at all until now. > > Any ideas? > > > > The failure mode is > > > > error: no viable conversion from 'StrictNumeric' to 'float' > > > > The workaround without editing port Makefile is to set > > DEFAULT_VERSIONS+= llvm=13 > > for editors/libreoffice on /etc/make.conf with conditinal. > > > > Please visit the mentioned PR for more detail. > > > > > > [1]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263976 > > > > Regards. > > > -- > Sincerely, > Dima (fluffy@FreeBSD.org,https://t.me/dima_panov) > (desktop, kde, x11, office, ports-secteam)@FreeBSD team > -- $B@DLZ(B $BCNL@(B [Tomoaki AOKI] From nobody Mon May 23 16:03:57 2022 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 0FFD71AEE16E for ; Mon, 23 May 2022 16:04:04 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L6MZq6wgkz4pHH; Mon, 23 May 2022 16:04:03 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653321844; 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=kIBAJjxbJBZv2B1wcvEcl0sXyx/WHcIpzwd10S9pJcc=; b=bHUHpnrabu/BdxJwwTamZEEaYL+4ng+eXKVPgq6XFZDnn5d4i+M37F4x/2x/t0DEo/rYtv ueAgOsSRcFW3D7Bu/8GczuU7d8FbKrwI7PTjp2NZ6mXwuQOcHTwXj+fjohObPkmmjhVywe NS8MW1865oX75IeKLOd4bs2C9FFcmORo21KoYUzGF0vs6//B0xlXU3cEMh8QsR6IIw/OdH 5JVB4SS3D81dv87bt3d3JSARLxLfLVPvK9J2t6iCgJk7Wv04zSkTJ2k7+77t/rTaqDMS7X LoFpZYNaNa9rNeSVzhQTCUaR0We59ON4pfx90KU88PpvgAhbBBiGIPKDj8+emQ== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id B266F246E7; Mon, 23 May 2022 16:04:03 +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 1AF7D44B52; Mon, 23 May 2022 18:04:02 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_AFC8F64A-43F8-4D1D-A9B6-016E397F36D3"; 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 \(3696.100.31\)) Subject: Re: Bulld failure of editors/libreoffoce only on main (aka -current) From: Dimitry Andric In-Reply-To: <20220524005355.575d32bf574c834cc7305867@dec.sakura.ne.jp> Date: Mon, 23 May 2022 18:03:57 +0200 Cc: Dima Panov , FreeBSD Current , Brooks Davis , FreeBSD Ports Management Team Message-Id: <7B7032E6-5350-4D4C-B542-8F4B5FDB5142@FreeBSD.org> References: <20220522082951.f7385d630c23cef986b766e6@dec.sakura.ne.jp> <2ae30822-f07d-53bd-9ed1-09a9a3b4f1f7@FreeBSD.org> <20220524005355.575d32bf574c834cc7305867@dec.sakura.ne.jp> To: Tomoaki AOKI X-Mailer: Apple Mail (2.3696.100.31) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653321844; 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=kIBAJjxbJBZv2B1wcvEcl0sXyx/WHcIpzwd10S9pJcc=; b=GNLDPrbIXpotFLgp4BF/wH0P0Fre4AmWV9RMw0gbFKDC2wmGTK1/cCGD26ikpwnc4PG3BA IlB2LgNvlDrfJfbS+uWho8xbXPF2qV5+s6CrNS6GdXciTtN2knpcruzaWVjGOYAV0pN3Mf XKeFdtVoZEx/MHUGm2SXCcsDPSPsbCAwBEdJqqfZYjNuMKb54pkWKKV6JkLJOZ+VtAJFaa /R/Uex+0DTuZVNcMi9azKrEgNdHiI+4kphSA1zbUj0hZE4SOxwTuJLYJQnzlln2CwEGUkW xMP3vG34heYAyesssFcaAp0loKuU/p/dWu7Lg5oCFPhMEXeJyVgj8Tqsgu+HZg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653321844; a=rsa-sha256; cv=none; b=gEQKkLXm1w9ZKIUEl3Llce6YwyaTxD2GVZOWQXh1TjF+Sxd/EPqBHFgmuRXlyLVFwSTipU 0NIe/nb/eE71GqOkPSyUVWS16YC8xxNnx5mM3SlvuG3yj9PxqHcI28q6RLMkzs64FVumZJ iDGmLB476TjV0IXEjTXbHAV/qX+kWIZ67IEExtRDHbKbvRlIwsQR1BQNk5/q23vZ8eMt/7 eihqg+GPyATxrRiwp1GfnBxzV5b2GHYPsNbzrH2AGveRT0OawbvvP7JSw7OM45pQ9Uo4oe jWlGQJvDvMJSLIk4Qud0A9WtECWrHfbrGsmlZtD8c9DSBSgociCpUO20HZG+HA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_AFC8F64A-43F8-4D1D-A9B6-016E397F36D3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 23 May 2022, at 17:53, Tomoaki AOKI wrote: > > After some discussion with Mark Millard on Bug 263976 and some tests, > I've changed the subject of it to "editors/libreoffice: Fails to build > if LLVM_DEFAULT=90 (default) and LTO=on (non-default)". > > With LTO option enabled, port default devel/llvm* (now it's 90 > according to Mk/bsd.default-versions.mk) is forcibly used, thus causing > this problem. Maybe it's time to bump the LLVM_DEFAULT version to 13 or 14 now? Although this would probably require an ex-run first. Brooks, do you think bumping to devel/llvm14 is too ambitious? -Dimitry --Apple-Mail=_AFC8F64A-43F8-4D1D-A9B6-016E397F36D3 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYouwbQAKCRCwXqMKLiCW o6nXAKDcyi5aJit7fLFkeTxQYK1PJgcosQCg1oKa0kRup16isJ6JVdJOhTlMNe4= =fakh -----END PGP SIGNATURE----- --Apple-Mail=_AFC8F64A-43F8-4D1D-A9B6-016E397F36D3-- From nobody Mon May 23 16:49:05 2022 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 21D351B396D1 for ; Mon, 23 May 2022 16:49:11 +0000 (UTC) (envelope-from fluffy@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L6NZv07yHz3DV1; Mon, 23 May 2022 16:49:11 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653324551; 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=l3Tq57i6Mpa/CbWls3Oh6GPNKtDLFMs8c5ZuM1bb/9M=; b=kTJIdUr13xdcZwqTPcSZSyBkH3jdOFNElis/pHrzQXYheHqfeTcpHAt50mxbO3O0gl0Va5 wpF0NpEhYrbwwUGXU2c6kKI7btt8WsPEMnCidlD4NJrQ4DPD/Z1bqbL5uIObgNAGSaJkdU +SFVyzNZ6f1NO46/YEMTRmoM1quCxBMm3mdJWvlVObafDQEMftX7JhAGK6i8ziz7q9Jaf2 yUf0T69azdU0R4Cp3FZCnz06ZDXl/L43+S4KH2LEQ8NiCskCwk6RlHv2+lZjohGk6lIT+G JeoiTOsb9opBZ3gdbuP4Wuc3eGbJaU5gsSblWdnU+rDRivjNR9Az9PVD9wuNXw== Received: from [192.168.1.65] (95-27-194-67.broadband.corbina.ru [95.27.194.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: fluffy) by smtp.freebsd.org (Postfix) with ESMTPSA id A944724DE0; Mon, 23 May 2022 16:49:09 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) Message-ID: Date: Mon, 23 May 2022 19:49:05 +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/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-GB To: Dimitry Andric , Tomoaki AOKI Cc: FreeBSD Current , Brooks Davis , FreeBSD Ports Management Team References: <20220522082951.f7385d630c23cef986b766e6@dec.sakura.ne.jp> <2ae30822-f07d-53bd-9ed1-09a9a3b4f1f7@FreeBSD.org> <20220524005355.575d32bf574c834cc7305867@dec.sakura.ne.jp> <7B7032E6-5350-4D4C-B542-8F4B5FDB5142@FreeBSD.org> From: Dima Panov Organization: FreeBSD.org Subject: Re: Bulld failure of editors/libreoffoce only on main (aka -current) In-Reply-To: <7B7032E6-5350-4D4C-B542-8F4B5FDB5142@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------VOxoHTIIKfXEFeRilLxh4CpJ" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653324551; 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=l3Tq57i6Mpa/CbWls3Oh6GPNKtDLFMs8c5ZuM1bb/9M=; b=kCSlZGnAV52pIHZxGEt/jP+V9yczFjpt4Jy7g1pv8K6wkg1XRxadwtnQGMvVqHjoqBlXMQ AoPBlmDqgTbCdtzgmkmwLhvMAHf/2mHNtnlGmMiiUwSHO2iP19+3o53gdA9YlalEpKJqct YyRttH18OTNPoJ0v+4WfYE18PD2OrRHCDp5O4htafkROICxu/kdgPxGiLO2GknCSY921qh NuJGnRsVn4neS8MMCfBMu89b0xIl4wrcqyRfZDaUct4qL7iLpIjOkmiPgmSaoEqvYwdcBN 7M0Xolt0OTnXUTTur0VBkixPrq9wOzd459sMIYZ1/vxxLNoODi7oOYknebr6iA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653324551; a=rsa-sha256; cv=none; b=fIX8d6ntjWhRa2BaVGNIT/YPdy+SFVfkJ3eEOP7ZkxeMuONz5AZd3NgpLecyXfF44HhPr6 09FtFhyhaGJMfDI8tUf0siZkPOiw4QoGUiAvtuVH4uumQ68+oQqLxCKj1Dye3xMuTgu5Ib xCe6CQhyl1HvgMFHWugO7c166AVmRRy+EEyqYiCh830WOa0yukIx6Ty4QLfahKC86gyvVd waV6OTj9lLbmKxViaXCFabNf+p4TcywfwsVM/IEG7Djt5G1jfG05bE3dlfakdumbfNP9CT Yr6BlI0BXd2x+qkYu6opmkGWT5JZhLX3nSS89ac/pcjnfgPqTw7xa6gGbemyJQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------VOxoHTIIKfXEFeRilLxh4CpJ Content-Type: multipart/mixed; boundary="------------F2pVs9tzHNA6J9tNpVyXs202"; protected-headers="v1" From: Dima Panov To: Dimitry Andric , Tomoaki AOKI Cc: FreeBSD Current , Brooks Davis , FreeBSD Ports Management Team Message-ID: Subject: Re: Bulld failure of editors/libreoffoce only on main (aka -current) References: <20220522082951.f7385d630c23cef986b766e6@dec.sakura.ne.jp> <2ae30822-f07d-53bd-9ed1-09a9a3b4f1f7@FreeBSD.org> <20220524005355.575d32bf574c834cc7305867@dec.sakura.ne.jp> <7B7032E6-5350-4D4C-B542-8F4B5FDB5142@FreeBSD.org> In-Reply-To: <7B7032E6-5350-4D4C-B542-8F4B5FDB5142@FreeBSD.org> --------------F2pVs9tzHNA6J9tNpVyXs202 Content-Type: multipart/mixed; boundary="------------3FUVuVTNz32zOoszZhHm6hnY" --------------3FUVuVTNz32zOoszZhHm6hnY Content-Type: multipart/alternative; boundary="------------u8rGS8hqGrmQXmbkw5uR8rEf" --------------u8rGS8hqGrmQXmbkw5uR8rEf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TW9pbiENCg0KT24gMjMuMDUuMjAyMiAxOTowMywgRGltaXRyeSBBbmRyaWMgd3JvdGU6DQo+ IE9uIDIzIE1heSAyMDIyLCBhdCAxNzo1MywgVG9tb2FraSBBT0tJPGp1bmNob29uQGRlYy5z YWt1cmEubmUuanA+ICB3cm90ZToNCj4+IEFmdGVyIHNvbWUgZGlzY3Vzc2lvbiB3aXRoIE1h cmsgTWlsbGFyZCBvbiBCdWcgMjYzOTc2IGFuZCBzb21lIHRlc3RzLA0KPj4gSSd2ZSBjaGFu Z2VkIHRoZSBzdWJqZWN0IG9mIGl0IHRvICJlZGl0b3JzL2xpYnJlb2ZmaWNlOiBGYWlscyB0 byBidWlsZA0KPj4gaWYgTExWTV9ERUZBVUxUPTkwIChkZWZhdWx0KSBhbmQgTFRPPW9uIChu b24tZGVmYXVsdCkiLg0KPj4NCj4+IFdpdGggTFRPIG9wdGlvbiBlbmFibGVkLCBwb3J0IGRl ZmF1bHQgZGV2ZWwvbGx2bSogKG5vdyBpdCdzIDkwDQo+PiBhY2NvcmRpbmcgdG8gTWsvYnNk LmRlZmF1bHQtdmVyc2lvbnMubWspIGlzIGZvcmNpYmx5IHVzZWQsIHRodXMgY2F1c2luZw0K Pj4gdGhpcyBwcm9ibGVtLg0KDQpsbHZtOTAgaXMgdG9vIG9sZCB0byBzdXBwb3J0IExUTyBh cyBpbnRlbmRlZCA6KA0KDQpNeSBvd24gYnVpbGQgZmFybSBmb3IgbGlicmVvZmZpY2UgYW5k IGNvbXBhbnkgaGF2ZSBMVE8gZGlzYWJsZWQgYXQgYWxsLCANCnNvIGFueSBnb29kIHN1Z2dl c3Rpb25zIGhvdyB0byBkZWFsIHdpdGggTFRPIHdpdGggbWluaW1hbCBpc3N1ZXMgd2lsbCBi ZSANCmFwcHJlY2lhdGVkLg0KDQo+IE1heWJlIGl0J3MgdGltZSB0byBidW1wIHRoZSBMTFZN X0RFRkFVTFQgdmVyc2lvbiB0byAxMyBvciAxNCBub3c/DQo+IEFsdGhvdWdoIHRoaXMgd291 bGQgcHJvYmFibHkgcmVxdWlyZSBhbiBleC1ydW4gZmlyc3QuIEJyb29rcywgZG8geW91DQo+ IHRoaW5rIGJ1bXBpbmcgdG8gZGV2ZWwvbGx2bTE0IGlzIHRvbyBhbWJpdGlvdXM/DQoNCk15 IHJlY2VudCAtY3VycmVudCBqYWlsIGlzIGFsc28gaGF2ZSBMTFZNX0RFRkFVTFQ9MTQgYW5k IG5vdCBoaXQgYW55IA0Kc2VyaW91cyBpc3N1ZSB5ZXQ6KQ0KDQoNCnRjYmVybmVyIHdhcyBp bml0aWF0ZWQgZXhwLXJ1biB0byBtYWtlIGxsdm0xMyBhcyBkZWZhdWx0IHNvbWUgdGltZSBh Z28NCg0KaHR0cHM6Ly9idWdzLmZyZWVic2Qub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9p ZD0yNjM0NTYNCg0KDQoNCi0tIA0KU2luY2VyZWx5LA0KRGltYSAoZmx1ZmZ5QEZyZWVCU0Qu b3JnLGh0dHBzOi8vdC5tZS9kaW1hX3Bhbm92KQ0KKGRlc2t0b3AsIGtkZSwgeDExLCBvZmZp Y2UsIHBvcnRzLXNlY3RlYW0pQEZyZWVCU0QgdGVhbQ0KDQo= --------------u8rGS8hqGrmQXmbkw5uR8rEf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Moin!

On 23.05.2022 19:03, Dimitry Andric wrote:
On 23 May 2022, at 17:53, To=
moaki AOKI <junchoon@dec.sakura.ne.jp> wrote:

After some discussion with Mark Millard on Bug 263976 and some tests,
I've changed the subject of it to "editors/libreoffice: Fails to build
if LLVM_DEFAULT=3D90 (default) and LTO=3Don (non-default)".

With LTO option enabled, port default devel/llvm* (now it's 90
according to Mk/bsd.default-versions.mk) is forcibly used, thus causing
this problem.

llvm90 is too old to support LTO as intended :(

My own build farm for libreoffice and company have LTO disabled at all, so any good suggestions how to deal with LTO with minimal issues will be appreciated.

Maybe it's time to bump the LLVM_DEFAULT version to 13 or 14 now?
Although this would probably require an ex-run first. Brooks, do you
think bumping to devel/llvm14 is too ambitious?

My recent -current jail is also have LLVM_DEFAULT=3D14 and not hit= any serious issue yet:)


tcberner was initiated exp-run to make llvm13 as default some time ago

https://bugs.freebsd.org/bugzilla/sh= ow_bug.cgi?id=3D263456




    

    
--=20
Sincerely, =20
Dima (fluffy@FreeBSD.org, https://t.me/dima_panov)
(desktop, kde, x11, office, ports-secteam)@FreeBSD team

  


--------------u8rGS8hqGrmQXmbkw5uR8rEf--
--------------3FUVuVTNz32zOoszZhHm6hnY
Content-Type: application/pgp-keys;
 name="OpenPGP_0xFB8BA09DD5398F29_and_old_rev.asc"
Content-Disposition: attachment;
 filename="OpenPGP_0xFB8BA09DD5398F29_and_old_rev.asc"
Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xsFNBEp+xiUBEAD01RkOYcyzU/Fnam2FI7PPwYqW00SwVmfUHihvVniiaMwzaYzc
hb+mzShaNsqRgjIN/i59OBpnS25OXMLEpQP7jDJnY2xKyJN2H4qn1HPHkF9cYuqv
qkm+r5459g+2ZoGY9Sr1PA0XSzXJMSQ1nRK3cFfqlN/L2//P36U5VuOWXGZUTwr/
n2B/N0HAsYsqDOdjofLg7x9z8p8elqwJbT/O4ltg8JBVAnof+FzqefYW4CzqkHRj
q/9ORiGYh14ST9ECsCaVpfdDUTor0wgpJqzCN1HsQcHqgdMmOqigWIgN7Eg4MRQU
3LDCISrNJ/45zvcKUXR0RHOjnSuflYba74q58XhZ4eCTqHeMHjA8st4IWRzy9l0V
4RunnZxjOTb806jyIhdxcb2m8o5tXwsqjf0TQ7vYowDHrQ6gXlhPg4Jvvwf+BwlB
2p+w7Cs/Y9QA0YHnIOIVZAwU1wv66YSI9IDL2AbnY2gQGx+dkHiC3S5LG8HcPrMc
jayyThKKIi5KQsWa3snFeK5ky+cRpVEOPQfUXFOas++91v90Xe9j+lsmRofsyvuy
gzoaZE2fud0kCsOgYEg+kiLPlQicNAx5IToOs8BrVFLcxmbPKuVBfbLdWsYLjXGz
bXEmzV9fNDZ1r1uNmVema8YYCiNjUDZhxIfKt8nbp6cx8UgVLGRVDEfXeQARAQAB
zTdEaW1hIFBhbm92IChGcmVlQlNELk9SRyBDb21taXR0ZXIpIDxmbHVmZnlARnJl
ZUJTRC5PUkc+wsF2BBMBAgAgBQJKfsYlAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC
F4AACgkQ+4ugndU5jyk6dhAArHclTYjwVRjDnoRfO3Zfj9Ssab9Vrbo7DNFWeAqP
E3OTCmiq9Q0fzRHzmhVyedYMm9qNA3i0J1De3KTnLanXOrBIqsmmZpSqmrp/xXdZ
ngDLW5H6hpE0f2PeAPwxrb9uBQax8WMR7Z4STSHAP4GRjve30wNNS0MlawGllcs9
VKRxG5PsDA8k3ACTSjdpQ76RWldORN4LA8M40yHRX377SGMzO+XsCeOwad65GKyL
rx+6Gnd3PMOjVCJCrqd04Jgqg9G0xKNImchwIZ5ulx9jAt+ixfNbY6hwslleqimr
2t5+MMqo6dRrvJ+BsR8NHt9vGi2Jy4+4smg05fR18fck0Sk4vCYyVvtvnOk3qZf0
F8zJu06GcjWWC2ZbDPbmksWXFIMxoJbyVxK55xOqcFs0t12sR6gbVJb8Nb88WrQu
b3MgePyMF6R3TkfaOqkjvQur1xC2AXESTxtJw1FkdGSb3UopNKgvSPHSLFW8B0Lb
yDxdYRTRWPGGEUhFP6tdXi5Rvb1210ks2EQAqF4Cm3iRIhYgtZvQqQgMSiO9fVye
J0U6dYGDtg2Boi+NtXKRdmtL7pRSnI3nfAbVJ05Hhd7PBnJeob6R08nHRo9DdAG7
o8ToM+egUAuEsEvoRV+v4f6k3mShdxE7gG/anwVyeh3n6LGwg9KHDr1X2FODsLLx
gUjNK0RpbWEgUGFub3YgKGF0IEhvbWUpIDxmbHVmZnlARmx1ZmZ5Lktodi5SVT7C
wXYEEwECACAFAkp+xywCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRD7i6Cd
1TmPKb5kEADatAL8Hq26Uaqb8hemnQ+YAqVPhRvELz2Yi/RoLlscY39i6OelRyEL
dzlfrNCfRl4et6OT1fSuq9b950mfR92Ah5J3uvaySD4bpz8rvzzSCKkP3xGpdeS9
tr6JTTvyP1ySkWOcOJCb2CXEmKch2+IJNNXfXcCppM3+yzVrClF+icwlBTH8F0mO
FAFqEEUzSoX5hXRrLp+/qcavQPtQszG9AhuwWcAqfiC/GnCKfLhyDIUaEmBCMH8h
Giff0GyIvkyoskmAY1eUUHg5XUQai7FtWH5iuktl9aLmuOiXglNubE5T5RWzyQvy
elh9f4MSo4tlq5iPIuGmFchazJzsyck1ytDOs+zkeWRmakjz2Sj0s07CLPv2d2RZ
xtqYJyi5ZUxGEfmnWlINAIsXaRElM0zVXibY+xLVaFU/JzpA2TVaDHG6OEJoQfps
LFLxEOboygULRNMBUCufLwmsLOr4ITJRP9T5Wf38gqdjXAm7C1MWG5DPEt+lzqyz
c/TSXxwdR3xw/zlxPMLMiKCIjpfcSoHjDmzz0iTesGhxuu3Qb7O6rbDhUAV9bgXc
Mi0JlDLK8mAyOY733XyC2S18FTrNvJ/opr3ROHzJ0g/ojT0QzkpspPbpgf0DNn8v
+gEBZKPyg9zuP3bR7dj4M76xf1yKlu0WDIO4NGWdnmAqO99nc5AhIc0sRGltYSBQ
YW5vdiAoYXQgR01haWwpIDxmbHVmZnkua2h2QGdtYWlsLmNvbT7CwXYEEwECACAF
Akp+x3kCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRD7i6Cd1TmPKREzD/9A
NKU02qbh78yaccFZqvjyVE5Ysdo+HDOCtxcGKVxsVTiPJubLqv3KiCIL8alemZWG
lLi69wnlaSAZiuB+5l6Y+gWYFrFstGAY6PPuyeQcQxaGpb5j23PbADaOrqfIvVyO
B4Ld2fPm8r+t0Bwb4P8epmbG4mOPjJA+w9Eq7KMwFK0vIGuCFIOfK09bKNkjEgMY
r/1KG28uVw8CKyQj38ACn1oojpV01E+SpbldHqFUoGkNbba4ojnZVST1IzO09V1X
4dDs4xGDvnJ04iSeifiTNYEjDnGbVA9TMFF4cUuV8dVeJQrc2+5iE3H7mSFLNCe9
DjFkmrRV+AnCn2bE5GYUiYA0o9N5OwRICmz6BhNZUMWVVGytQy0g4pdmxNSkAiMC
A8FzCbY8BCn6XOOelF0EsHug5bqGvaKCn9CyoLEHhnZ6ttzJlpYO4AQlds3Rvi53
HouowEbWhQQxhiKRfvKPVwpXphR4PNIgkLXckv5MJD1IPL2eyzWCYdBY1lCCTA8s
dnzdk7WLfDJzyAk5sEbf+mlGhywHKsu87yGOckEVKH2x6L0WGdroY5IfR4NMhzGQ
OPDuLnX0r+SY/R6l+5vLyf7xni+VNkNpxt9PbVLt+JfdIbpVIe7HvQoxbBpqwy7B
MAq23N31gROI6N31i8bAayoQ8YC8CPxH2E4J4bMIyc0eRGltYSBQYW5vdiA8Zmx1
ZmZ5LmtodkBtZS5jb20+wsF4BBMBAgAiBQJSaeszAhsDBgsJCAcDAgYVCAIJCgsE
FgIDAQIeAQIXgAAKCRD7i6Cd1TmPKdlwD/93hdsd8b8SFwfWJ4UD5ruk6/Ajfjx4
kbORZO935npFT8hNs0A8ZF24LqHX9Sqa0CASpVWMjGQA7gTbvPlTk0i/V0UmvCqO
2YG3Zei+HXfICbm6si8YtjFZRXZHpqePtV9aPvSucegRItjtXCfS3IKEZhMyJhNt
Lq6bTgjAFeGbfKCdH4IBtFYc9lTgOreumM02tFYzHnpBa/bVPz6qOmXs3lztwSNa
skqLuvHym+c9VSyDUfu3B+NN4vS/eeJOuHnCzM080T6CoeL0GXWHKvl22PcN1fOk
N57WukxiaW5PO/wIKWWB2rAlyZj2+Q8KYhKc9iP5EMIL9dJXNNSeIfGpcUJauUKf
Yg7e7P55ZMrF1TLlb2sCdEN5xcnKIAN5Rowz72fRjumzD6eJbx8/+6Q5tKuJpH47
zz8dImXVpIpiM2ZR6f6fN3eqvzieAFTIcH2rJ5LzrOWUX601rOICLhu3UrsQpVwx
yCzpP0S8cyZkq3xmCzV3HSu4gun2yIJXpCxxjvXTxwgbX5J9ezY99yhjrVR9982V
e35U5EyE5XAN6+bXK21g2k10dLhHL7dUqgiZGMju9mLz4bd/z+W/n8eupkiwBC3T
pp0ZOS23iqjk2UBLaRI5J3nrrC5QbTh1goW6WIHwB6+NaUzSP5tejeYzEJJgmn2o
4OHx0Wg/XncT480/0JTQvNC40YLRgNC40Lkg0J/QsNC90L7QsiAoUGVyc29uYWwg
SUQpIDxkaW1hLnBhbm92QGljbG91ZC5jb20+wsF4BBMBAgAiBQJSaetpAhsDBgsJ
CAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRD7i6Cd1TmPKbXcEAC9fJqDCOfW7CS9
SACUZJ8pSxrFzkNNTMqKODPiJ+NSaD9jH6m9DqMP1B3Xc+Gj5ieSycmajOff4PYU
A+XTHwBjNg3sLsvsNjSHDeHOJi2JJKeMWRBE/7JlTS6gkPedOLBk4A/wQ5d/GbvO
wUk5yj+bpqxxIraE24Rs64m/NqF1muWcIZvr5eCmE7JnPYmCPWiVOYTAagflEuDW
ja0t2+0li4vy1N8j4thsxB28ELgdtFThHe57ZlXDqgKd0o8kJiDtv/66Q+8DPfEQ
7iWV6UlSw0FcJruPmhBSNvFHL2A8wrQaPhz9WrT1OO9ZoKf/TjT5ARtwS0bcUvqc
WdGJgXtWrk1fCOXKYYEO2JitRB+pXD0OIB8si3zFZrCHzbAVGlrt1JUSH/mXdlQ1
HyiZgiOECVfMrI5mLml/SgzRzJOhBkkvMOT1SsNBFMFWX51LVKi5nR1wG7TcqkQo
dBhvpc7rvb4kpyv+6YiBlO3UvJ6fgQhUEca/H8yKmLlumvPqghDHtvJuG86rRUCO
llxwmFHpxgrAdfpIpdW0ngHacwRXZK16DJuw6aEf5aWFIXBq+uX8CDYZWoZ0GHrm
KbM1TAK2iAMaSTPWawPHX7VFiwTfAijyvqVgayqzcJ06N/6r4c+hVG8lGJF77Zgc
MqHDptz1aPA3TaekIIUHEWl3l8/e480/0JTQvNC40YLRgNC40Lkg0J/QsNC90L7Q
siAoQEZhY2Vib29rKSA8Zmx1ZmZ5LmtodkBmYWNlYm9vay5jb20+wsF5BBMBCAAj
BQJVbrwmAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ+4ugndU5jym3
xhAA5u0rVHXCXkf6XeUUe1CG2AgJFmgDoAnJXSMGeXwmKnI2mpSxe1hrNyqzRYfZ
zG+wUc3kwaVh73IxD+OVqN0K2Y5X2vjmiTxj3qzPb6EkVzf0MhrYYHqIBuhDf1j2
O8spuF3EBWP5Y0shuq5VrxJ1a4zHgQHrPZabpN+znB1lGAtT107la6Q/fF1V4+eq
0qGTv19digf8HGT/DtnXKgDHVXQLzOEq2Ds44XRriFwJTCLQHBTED5N82yJtDmEo
vVPbXDKy/p5L8PDKP8fWefe0Qnl7VA6Yp1+RbYfYTt9ZqNpBDanMdOykEczDdzw6
N1c+h+nW7b4RXLUaE9m74mdtEZrsczqYrk8BNRnHGpMn7qI2bQvqq2/6V53YYKFr
IObh5TTSMRGNh2hUJZepS0lk5gWY3l5AmU3yeB0Qrz1VbfcbafQocfTDzeYopDOM
oAG3o/ww6wnofbDehkUxL/Os1IL0HkeFOQMFZcnqXFcUBQC99oabFZfkJqxBc/yx
EYnRFE8r/vY5oO73TdXQrU8GzUzNUB8ZZMTCHhpoWuk9H1HmgCbReJScCmh0ZwWt
oLMlG2NPKsW2gcUVy3JTcO7wpOadTMTl+tgPnGoGcrWY6ak32e11eblVBe927kvx
XkSoPvgn8uPR6B4Q5lG/Q0d829Oo8CHYIXKBA/lxEltanKvOwU0ESn7GJQEQAMBT
MHQgb0vcPMAiRvb357ihlh/YYA22FXj4p3XTrDlBlRL0QCRq1I8XDeQmL3mG3s3N
BtDXSefnNM06jZ3XCAfHIDBdxJJvQZZCXfvLp/JK7nnEuqoeqT6/oKs1MeZVdUnv
h1nZhphs+Z6dl01GIE8YDpzT1JMD2f3G9PHChGi3Ddzqm3VdXt/87khYJkPbaf6E
N5+vDthKgMjba8jwbQ+7IUPqkfnNFIZS6irZ2LYb79BLNI5JSl9lReSfEX2d8ByQ
lLzuf0TS4voy3nWGeCyj6BIOMiRSxg+hZmJLYxhNkyK4GQVCt/rLT7dIfBQMsyBb
X0Qw2NOcfba9VgdPZBgdrawwB4/xF9SA3NB0J0lUjhjpH9iG8NxlpleEg8OSUApy
FZEJq2A/flns4kKzNH7AGYDOFORytDzA3qkgCJrZ7nzQSsdtZ2qbyAoze0tl+YrS
hJhOcmQBtFemomhWVeJ8T/Bw1KH8M1ihrENBTSzYzLvN18YjNP6P0Dh/7Zda5yYI
8fNqd84K3Uq5xBiI0S6+qxViw84z2tJj8TxiNqFAk7Tbeo2Ximtq7uQ9UnFRSK3j
w96yi19KU9rQQZs0xUjN5gn/tF5lBZWKjwuZCkcOiI0EWHAR+ATAEsFNXcuoC9CA
GK5HFW4nI4WtE3pv1KYvivlGtF1wzf0QrhyeRrmxABEBAAHCwV8EGAECAAkFAkp+
xiUCGwwACgkQ+4ugndU5jymgKg//RvnI7zEDKv6nQUqKRyLawPTrCKCtQ2vSoWyT
NgRB6byNS1w5wNSAMnqaESx2bdhauaxe167VEJYqgQy241yFslpC6v/xlH25Ppos
+Jg6AKaQG/JABHO6Co4tHtBbNmM+14HESxAodA4NJuEU19iIPjRhUKC8F8R9xBmW
1uLpPiljU9Km0P3EIKjAdtdZNeMLhwsbSHBwJROFrxFGiTzWNREWZoZpQxgSbHYh
wYbxHEbJi1cybl9IQvSGHrysctZsxD04Jxh6ogaziiT8aV6ear6BNh008yRf61Fv
rinfG3USLR3iJO8aHap4QGCPjZ3cyT+DEq8/zVfDdeidTeNEhSgRKk856RcA+yAE
79KYdKkvmDUiC8poAJ7FGEYHMB+g/1+LczCr2g9GYkiB/53boYfU9esYYlarxCge
dCrwXv6T48FZ3xxoH3XJ2KV8K6M8CUb04jj3kEeCwq+R6Bk2ZXrnMzyQmmn223X+
Zp89B/gchH32JY8y3j7BICcoZmgMu62XNMgWI/hRgfi3JlVCne6XPj3/w00JYG7v
o+eTJOflqYr3WRTPYh7DxzYtshZswHmmkZtwizUQUZzF9dX2CM8nY7cKucEmtcnU
pjGwXMOufa/DmCTlk8ggRZ0ukCUZOlIA4ILxp95sS2oqyucARv+pwMWvrqJ/LfbZ
exSsIjLGwOIERVFagxEEAPOvrde0FCIYgD3xQDPYAdWGD7kTut/gqFFHPAgXCx2p
mEr0StQSn4bblBdGqPEZiIQ76gLmcWeTt/Mdc9MuC8XzSCijAF65zz0jlTKIt4yh
j22QsuD8zb9SISv4thfcEDO9lIgYb4hnpwgOCkYTJp7LTeShCQxRIiAdzfytOx17
AKDz6NCgiqDLGbPTDnsdqEbfBgmHYQQAlTQCnqJKaScuI8ThrZthRdQrWVIblIyj
wLzt2RRTYFWCofcrs8pgBQhrAk3vg+C96EobaKr0AuzIv+hfkbzawpmOBogmtIEz
D37KmnDbaV6ylqzIrYZdX7mwrRAp841QBQCp5c0fmTM0jWOa3fW/rWjUzZdzRtV4
rfBcYKL1r6sD/iuWxn98cumJKgq19IQYLWEoztduoGY4HbyU1CPXglAlkHoE4XSj
n3t1YddIBAXU1Rl80buG0Ov+jxKhVA4s36rCzb3TThd/II4wKh1THxQL8/Vtn4+j
MXyX0MmHLEPRmhENPQOunLvWTO3V1BqkNngHDKhNUt2yAzACxP/524cYwkkEIBEC
AAkFAkp80gECHQEACgkQpiZ27ZPjsBhfYwCfUtv9ehaUPRH5c5ozNR0o34uTApkA
oN3DzKFlQkZeQISOOdFG8GLBdwuVwkkEIBECAAkFAkVeC/ICHQAACgkQpiZ27ZPj
sBhusgCg4LU23MNOcb1BXDzZbOAxx6L8WZcAoKl+3eN7JEHZqxeLQpUzq4dYtIt+
zStEaW1hIFBhbm92IChhdCBob21lKSA8Zmx1ZmZ5LmtodkBnbWFpbC5jb20+wmAE
ExECACAFAkVRWoMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRCmJnbtk+Ow
GKSIAJ9bmwywJuJ53N5Ebi/P7F8YSJi/VQCg0wNR4h4sYrMsffGqm4WqbeiHOo7N
K0RpbWEgUGFub3YgKGF0IGhvbWUpIDxGbHVmZnlARmx1ZmZ5Lktodi5SVT7CYAQT
EQIAIAUCSljD2AIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEKYmdu2T47AY
6uMAoLCrnoStn+QgC2HRkk3/ucYmM2oVAJ9+1jnUKXSOApvN6MEbbeRJ2qWfBc03
RGltYSBQYW5vdiAoRnJlZUJTRC5PUkcgQ29tbWl0dGVyKSA8Zmx1ZmZ5QEZyZWVC
U0QuT1JHPsJfBBMRAgAgBQJKfNETAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AA
CgkQpiZ27ZPjsBhK+gCgoB35KL/jPwFZqJK3OdTCtE8UvioAl0EMO6fEe+QBshu8
ZJcR+pGSbkfOwU0ERVFapBAIAIuGs7g5f8z8tMfxvSmG8BxhR5P9DiwHGg4XP24O
BAo9eXQZWkFsSfsqUEtwhOtUMS1+XsCauP5h+UCZpbCxOfJFc6jktj93lLn2nM5R
ExWp7ulCKHTT3EWKttD6alFo/xNpmJUY8Yf2yxuIQDfUMzSo5vLETURybPQqD5nk
h/qyfFjED60ZdlhBSKEXGyIWsnooHE/UHlQiEzb/BnII4Y+OsURATayyTCMu2vRL
6sk2V0tI4MX3so5dLpxSGRr5AZrZU1Vq1UzHLuLvBZkPR7KEUM1tKN9oxDlLonUR
IrbuL4/tyW/aaiINh4WJebbh/x+o9JgEk/waZYlVj4HFZosAAwYH/RB2xiNdQOhH
6ABXUgT6iITg6aH+um0xbyVNRHEXsVhmbLgSDAtJyfoa/KP9vQFDjPS+O/o1a1dT
LWqWKZH2mVvQaItwsx+qAXDlEiC96zetidafTVHFfKznbe9Srz9ocIt0kHQSU4M3
0VLUVwNTRZt+8fLOmctw+cGlx0CW6RMCMH63kUqPQso+WytLdvCO/UN1lECOrYhW
zeQTPm4D0IQ1AUg2163T6Pm7f+LSr6Rhphkh1K4Ivprqk8ubp7ZzlrKuhToSsERP
VmFJ1N8mP9UA2MxmSHVB94Bmse8TyB5Uu91DNQt6rQ45NI7jx5C6ohcwdqoPukhc
If02wQTnstrCSQQYEQIACQUCRVFapAIbDAAKCRCmJnbtk+OwGPcAAJ45LZPpB21M
E5CUNNrSsvPF0v0XAwCg4br9QmhpEfiiKI8I8NLc1ZDf7kU=3D
=3DjlxC
-----END PGP PUBLIC KEY BLOCK-----

--------------3FUVuVTNz32zOoszZhHm6hnY--

--------------F2pVs9tzHNA6J9tNpVyXs202--

--------------VOxoHTIIKfXEFeRilLxh4CpJ
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEELTAsy5mEEwxvh7r8+4ugndU5jykFAmKLuwEFAwAAAAAACgkQ+4ugndU5jykX
ExAAjLRlbaOe1ZyuzsArDvjYJKdtafn2xcc73/u/W3IDOdTHeyaXOLQidwDHXb93u2dzSRoPlR3M
182TQEgRRTIINTbrF7uoHR2GrHrpVkPC5MEhMIqPVGD3CPsRRrqfUFghCrfbXcYCRMpM+VoHHEKy
KoUONgXG31hAD8BZRFl6nB+YKfo3k12MVJ1pQBTtV8b1W2SDG/hpaALA6JxuH0WQGhKNtqz2DnOc
Xp3k8gcyCO1c7/EgUAUnHlY44cXXQ6lMnvuHNott77XiNkBPOcTtLkd7GoVqN6sCmKSIgDUycSQP
72sYHeMuB1jpL4oM/aZlHkqAkJLSi/vEABW1FaqfYmeaMYyj5Lbd9U4N1Oubnx0ONmg/XpjNuvRG
mdaSb/Ro+dwaGGkLeDx6+3XINAzRWUGAt+u5Cw6mvITiBdcnicQnSNMnyCvkd/q4no5hKEwKIkhC
k8nyEH0gzagbbuCQTkVMk/phrxKYmAljOAnnRsoAm30tZhkolBo0Z2GHfzVKipBxfJ5EJBym8e5t
+Li6lONL1x3HIAd6Jkk6jbemm9pciI0aV1iDz/KkeCk+sae5ahMpgwUBt/UPQDQk4EDhi2M/8UgB
pFAEuWnPMn5pWkKGPbdsaiKYWD9zf4ByAJteyK/a9g3ZzrrsnJvmDct1YveTzLIrjzeumie2/jZr
TdY=
=sxkD
-----END PGP SIGNATURE-----

--------------VOxoHTIIKfXEFeRilLxh4CpJ--

From nobody Mon May 23 17:17:46 2022
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 45C7F1B405F0
	for ; Mon, 23 May 2022 17:17:54 +0000 (UTC)
	(envelope-from imb@protected-networks.net)
Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.protected-networks.net", Issuer "R3" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L6PD14Jymz3K1v;
	Mon, 23 May 2022 17:17:53 +0000 (UTC)
	(envelope-from imb@protected-networks.net)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=
	protected-networks.net; h=content-transfer-encoding:content-type
	:content-type:in-reply-to:from:from:references:content-language
	:subject:subject:user-agent:mime-version:date:date:message-id;
	 s=201508; t=1653326267; bh=xLOioR67o4bRIyIyH1lHLuANgf5vKTsYEW6i
	ebBflDc=; b=ibtJsU4MfPoCwk7HCwgEcSEfsD4SZOiaytL9HMwN14J3KfH3nIVv
	MD5rweRoikCMmvE4vQ2Gm238TcStGgYfJQLcVa5XjwxQdkeVZw7MSGP22JffvN8j
	PZfeQZUe0yfNkCGO/088sfb0kZOz4AhIEpE1NHOxfsh+PUxR9UIW6+o=
Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(Client did not present a certificate)
	(Authenticated sender: imb@mail.protected-networks.net)
	by mail.protected-networks.net (Postfix) with ESMTPSA id 3D7525F637;
	Mon, 23 May 2022 13:17:47 -0400 (EDT)
Message-ID: <7c977c78-7ad2-8ef8-67b5-41e5271b6e24@protected-networks.net>
Date: Mon, 23 May 2022 13:17:46 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: Bulld failure of editors/libreoffoce only on main (aka -current)
Content-Language: en-NZ
To: Dima Panov , Dimitry Andric ,
 Tomoaki AOKI 
Cc: FreeBSD Current , Brooks Davis ,
 FreeBSD Ports Management Team 
References: <20220522082951.f7385d630c23cef986b766e6@dec.sakura.ne.jp>
 <2ae30822-f07d-53bd-9ed1-09a9a3b4f1f7@FreeBSD.org>
 <20220524005355.575d32bf574c834cc7305867@dec.sakura.ne.jp>
 <7B7032E6-5350-4D4C-B542-8F4B5FDB5142@FreeBSD.org>
 
From: Michael Butler 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4L6PD14Jymz3K1v
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protected-networks.net header.s=201508 header.b=ibtJsU4M;
	dmarc=pass (policy=reject) header.from=protected-networks.net;
	spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net
X-Spamd-Result: default: False [-3.97 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 NEURAL_HAM_LONG(-0.97)[-0.973];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 RCPT_COUNT_FIVE(0.00)[6];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[protected-networks.net:+];
	 DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 5/23/22 12:49, Dima Panov wrote:

> My recent -current jail is also have LLVM_DEFAULT=14 and not hit any 
> serious issue yet:)
> 
> tcberner was initiated exp-run to make llvm13 as default some time ago
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263456

I'd caution against adopting llvm14 for the moment.

One apparently architecturally-specific problem with llvm14 on 
rocketlake (Intel Xeon E-2334 here) is a never-ending compilation in 
devel/boost-libs if CPUTYPE is set.

The file libs/atomic/src/find_address_sse41.cpp causes c++ to run 
forever :-( It also seems to spin forever with CPUTYPE set to "native".

I just found this last night but setting CPUTYPE to "ivybridge" or 
leaving it unset allows it to run to completion,

	Michael

From nobody Tue May 24 03:36:37 2022
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 98DF51B3803A
	for ; Tue, 24 May 2022 03:39:16 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L6g103mwLz3q7M;
	Tue, 24 May 2022 03:39:16 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1653363556;
	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=Zbly2BO0xBp1D5uiC1oec73237CPRa0+hMnOVKRLBSM=;
	b=xpfqMTX7Jbz+wJFl8Aa9SbfdDkyaXX+kqV5pl4haAr94NpvquYIwJAgmS4NsYI5KuESXN5
	GV0wE42WBMa6JFDDewWuZ1/9PLUJJkvAS7R0Iimgk87YF5IlhgGUzfi5QwHTvVIYlHEyiR
	tlNHn68BmmhzXkznsgWjebZx4g5BM7q9wnWoJ8oqkYYJLbhc9ZGUmEUOf/vHIWGhxqchJr
	nj65K1gLtpkYJg0FY84zb79bfB1eND+vNpVDVGFQCInw38sLKd8iCH4GCxdwoEj+r92/aS
	WdsCvMIkB7RHmagN9VBEAXo1BzGxWIRoEINHiZwCjcpCFavSmfB8zu2jt+OgHg==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:d1ea:66de:f9b8:3419])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id CEC3329DFF;
	Tue, 24 May 2022 03:39:15 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Tue, 24 May 2022 12:36:37 +0900 (JST)
Message-Id: <20220524.123637.1579380844342215240.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: 20220519 snapshot: loader fails to find bootable partition of
	zfs-root system
From: Yasuhiro Kimura 
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1653363556;
	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=Zbly2BO0xBp1D5uiC1oec73237CPRa0+hMnOVKRLBSM=;
	b=avyE6LFKNpjKtE+3IVCLwk+3y19lWPg0m3ff4kEmliXAWCO7nBgHgS8QTlSwQ158ceonRe
	RqSDUCanJI8/N2lgXHsi5OEifYh3ovbaVNKKYfrG1Ui/PVbQ/Yy/O84yoHhy97UZI6Sjkx
	xhQiKLq/n7+OkaRms9peacVdK4NVDGuSerw8jmNirkGuWWzGL6QiIV34BfYhjAzArTuBwJ
	PxfgAiKsZ7bDAMLkrcIlBZ2A+1rZeAqooAZc26uzM/qjE4vcxHcxW3AYI+NX5owWiQtQi6
	7WkOzrUX7ZHoTBwhgoANgN4AJBP0NgAn2bsvkkltvFq0sDxbfW8vK5dLfsN0XQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653363556; a=rsa-sha256; cv=none;
	b=SpsG/ADuySozoOA814gn0lb1PI2IjDIg8uoIYYWvtBNrWBdwVuX9yXRKqA3yDTUAuaaxLQ
	zkN6E/RAEV8+UPBi1A8PRGN4BMTJYTNlUdq7KJyeo5KSX9panLbmoN3Oodbpdwe1AkXfFf
	iE5RC6TmIlt8PmWsWyL0DFZCGiCsfo9rvrPZ8NzJ936dq8BSjKEM9Tf6xHCUurbY1qbYoW
	2BgsYEH7PCztk1qMnDQHqERsAE4qha8HBwCE+I+mCC8ioOwLFsKMlPIsWS2vJegNWYDp5s
	nRdkHy+j/rW540t9neaZrSJpZzCEUkyjkdShjOOGgzgdkuO6wOMUmA8KcxV85g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

Hello,

I made clean install of zfs-root 14-CURRENT amd64 system with install
image of 20220519 snapshop. After installation completed and system is
rebooted, boot fails as loader fails to find bootable partition as
following.

https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220519snapshot.png

If I use 20220512 snapshop instead, then system starts up
successfully.

---
Yasuhiro Kimura

From nobody Tue May 24 05:03:57 2022
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 2B0191B47BD0
	for ; Tue, 24 May 2022 05:04:17 +0000 (UTC)
	(envelope-from nparhar@gmail.com)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L6hv4389nz4Tm2;
	Tue, 24 May 2022 05:04:16 +0000 (UTC)
	(envelope-from nparhar@gmail.com)
Received: by mail-ej1-x630.google.com with SMTP id y13so32189709eje.2;
        Mon, 23 May 2022 22:04:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=5vBr8wJVYG47bhjxWfN/iv6ORa60HJFdLBahqrQQ8DQ=;
        b=mgDnNYv5eONdifJVf7HV6937k1nVnK3wY2JvWhw1rtOV03mFR0AekusWIj56sPwpgv
         64krliAh+65jrSwdV5H9XFLfuWx2vfIt16iNh4EuSNkzTknWDQBFGpmjZGPq4IxpKmoc
         bY9JrFhvQ/MdooFSfpr5ZliAYKwxOrYLp861LGir43Pgy0V+1HMgJsfUc9pfgSW1Hgx1
         lcksjAQPgKyt092wwX/jYyy31hQtO4LRx6+1b4io5bgbsbOKf/2kAQJIA9qIoHtaJa2q
         Wk7jUV9OZL8QkDEvZjPLv3eVVRUEAQ+b3QuHMm5pochRrzesNbPyYiHQRjVcIsI/wQBl
         TAew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=5vBr8wJVYG47bhjxWfN/iv6ORa60HJFdLBahqrQQ8DQ=;
        b=QwemCW0JSWSRLURxrbszNR+twvc/sL5Stb3Y6QYgLDt2KYXTzerS7p9YCNrezI8GZU
         m6KIRadxVJP3l0T4UqDWOegr6JxlGxy/6SaE9IqP3qKCx3x85m80Sdzi7SSGgk++IPy2
         seJgLnB4TiG3xmPuKz6SQoZi/4VAZ3emzEbXvqGVdArNfWu0Q0Htq36LUk6j+R1jZr7Y
         8v93WHmqOD6kzrMy0s8T8biWzszA70+0+s7hA3sH+EdFSGXlvAoqXlaNu/PGU/XrlJ6t
         2QyWc67habyaMri5pcxZdOsAcr9+5Uenuy75jdaTZu6+KS8UyXKaB58oH4yO5hSLXNOz
         /71g==
X-Gm-Message-State: AOAM531IM52/+l/8EKLPPmE553rBebFdc3CNifEzAKOq0llxLK5GYIzJ
	0I5xvlqVPCKpzRVpXbfybys/F4XQbpYxYFS9Sjq8Muv3cJA=
X-Google-Smtp-Source: ABdhPJzprhQ0lwos3TCyIzAUN95RqAlTpiZDHUOWeIJ5E6jzsAckDDoQAIju9q3UVNWALameHyBQuuCh4mIS3zZ+Jkw=
X-Received: by 2002:a17:907:2cc3:b0:6fa:55f:8805 with SMTP id
 hg3-20020a1709072cc300b006fa055f8805mr23100747ejc.46.1653368648772; Mon, 23
 May 2022 22:04: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: <20220524.123637.1579380844342215240.yasu@FreeBSD.org>
In-Reply-To: <20220524.123637.1579380844342215240.yasu@FreeBSD.org>
From: Navdeep Parhar 
Date: Mon, 23 May 2022 22:03:57 -0700
Message-ID: 
Subject: Re: 20220519 snapshot: loader fails to find bootable partition of
 zfs-root system
To: Yasuhiro Kimura 
Cc: freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4L6hv4389nz4Tm2
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=mgDnNYv5;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of nparhar@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) smtp.mailfrom=nparhar@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::630:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, May 23, 2022 at 8:40 PM Yasuhiro Kimura  wrote:
>
> Hello,
>
> I made clean install of zfs-root 14-CURRENT amd64 system with install
> image of 20220519 snapshop. After installation completed and system is
> rebooted, boot fails as loader fails to find bootable partition as
> following.
>
> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220519snapshot.png
>
> If I use 20220512 snapshop instead, then system starts up
> successfully.

You need a loader with commit 9cd45772a44f268ccb3e20caf7f3f764f6b5e1a1
to deal with the latest OpenZFS.

Regards,
Navdeep

From nobody Tue May 24 18:58:44 2022
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 99E3B1AEC2D6
	for ; Tue, 24 May 2022 18:58:50 +0000 (UTC)
	(envelope-from mike@sentex.net)
Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L73Q169twz3vdb
	for ; Tue, 24 May 2022 18:58:49 +0000 (UTC)
	(envelope-from mike@sentex.net)
Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19])
	by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 24OIwh00014364
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL)
	for ; Tue, 24 May 2022 14:58:43 -0400 (EDT)
	(envelope-from mike@sentex.net)
Received: from [IPV6:2607:f3e0:0:4:a4e9:541f:6818:4d58] ([IPv6:2607:f3e0:0:4:a4e9:541f:6818:4d58])
	by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 24OIwgMj004651
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO)
	for ; Tue, 24 May 2022 14:58:43 -0400 (EDT)
	(envelope-from mike@sentex.net)
Message-ID: <1cd6bcff-92d5-f155-9b19-b3a16d75fe19@sentex.net>
Date: Tue, 24 May 2022 14:58:44 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Content-Language: en-US
To: freebsd-current 
From: mike tancsa 
Subject: make install[kernel|world] from read only /usr/obj possible ?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.84
X-Rspamd-Queue-Id: 4L73Q169twz3vdb
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net
X-Spamd-Result: default: False [-2.39 / 15.00];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[mike];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[sentex.net];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-0.99)[-0.991];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received]
X-ThisMailContainsUnwantedMimeParts: N

On RELENG_12, I was able to mount via NFS /usr/obj and src and do an 
installworld on read only mounts. However, with RELENG_13 and above, I 
get permission denied errors. The install seems to continue just fine, 
but I am not sure if something subtle is being missed. Looking at what 
gets installed, the kernel modules get installed just fine.  However, it 
seems installworld has some problems with static libs (.a files). They 
dont seem to get re-installed. However, not sure if thats by design as 
doing a quick checksum, there is no difference on the build server and 
target of the ~ 700 .a files I checked in /usr/lib32 and /usr/lib. So 
despite the time stamps being off, maybe it just does not bother to 
update the target if they have not changed?

e.g.

make KERNCONF=vtnet installkernel


make warning: /usr/obj/usr/src: Permission denied.
make[1] warning: /usr/src/: Permission denied.
make[2] warning: /usr/obj/usr/src/amd64.amd64: Permission denied.
--------------------------------------------------------------
 >>> Install check kernel
--------------------------------------------------------------
--------------------------------------------------------------
 >>> Installing kernel vtnet on Tue May 24 13:50:52 EDT 2022
--------------------------------------------------------------
cd /usr/obj/usr/src/amd64.amd64/sys/vtnet;  MACHINE_ARCH=amd64 
MACHINE=amd64  CPUTYPE= CC="cc -target x86_64-unknown-freebsd13.1 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="c++  -target 
x86_64-unknown-freebsd13.1 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  CPP="cpp -target 
x86_64-unknown-freebsd13.1 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  AS="as" AR="ar" 
ELFCTL="elfctl" LD="ld"  LLVM_LINK="" NM=nm OBJCOPY="objcopy" 
RANLIB=ranlib STRINGS=  SIZE="size" STRIPBIN="strip" 
PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin 
make  KERNEL=kernel install
make[2] warning: /usr/obj/usr/src/amd64.amd64/sys/vtnet: Permission denied.
thiskernel=`sysctl -n kern.bootfile || echo /boot/kernel/kernel` ;  if [ 
! "`dirname "$thiskernel"`" -ef /boot/kernel ] ; then chflags -R noschg 
/boot/kernel ;  rm -rf /boot/kernel ;  rm -rf /usr/lib/debug/boot/kernel 
;  else  if [ -d /boot/kernel.old ] ; then  chflags -R noschg 
/boot/kernel.old ;  rm -rf /boot/kernel.old ;  fi ;  mv /boot/kernel 
/boot/kernel.old ;  if [ -n "/usr/lib/debug" -a  -d 
/usr/lib/debug/boot/kernel ]; then  rm -rf 
/usr/lib/debug/boot/kernel.old ;  mv /usr/lib/debug/boot/kernel 
/usr/lib/debug/boot/kernel.old ;  fi ; sysctl 
kern.bootfile=/boot/kernel.old/"`basename "$thiskernel"`" ;  fi
kern.bootfile: /boot/kernel/kernel -> /boot/kernel.old/kernel
mkdir -p /boot/kernel
install -p -m 555 -o root -g wheel kernel /boot/kernel/
mkdir -p /usr/lib/debug/boot/kernel
install -p -m 555 -o root -g wheel kernel.debug /usr/lib/debug/boot/kernel/
cd /usr/src/sys/modules; 
MAKEOBJDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules 
KMODDIR=/boot/kernel MACHINE_CPUARCH=amd64 MACHINE=amd64 
MACHINE_ARCH=amd64 MODULES_EXTRA="" WITHOUT_MODULES="" ARCH_FLAGS="" 
DEBUG_FLAGS="-g" __MPATH="" 
KERNBUILDDIR="/usr/obj/usr/src/amd64.amd64/sys/vtnet" 
SYSDIR="/usr/src/sys" MODULE_TIED=yes WITH_CTF="1" KCSAN_ENABLED="yes" 
COMPAT_FREEBSD32_ENABLED="yes" make  install
make[3] warning: 
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules: 
Permission denied.
===> aac (install)
make[4] warning: 
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/aac: 
Permission denied.
install -T release -o root -g wheel -m 555   aac.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555   aac.ko.debug 
/usr/lib/debug/boot/kernel/
===> aacraid (install)
make[4] warning: 
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/aacraid: 
Permission denied.
install -T release -o root -g wheel -m 555   aacraid.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555   aacraid.ko.debug 
/usr/lib/debug/boot/kernel/
===> accf_data (install)
make[4] warning: 
/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/accf_data: 
Permission denied.


eg.

0{git}% ls -l /usr/lib32/libhei*
-r--r--r--  1 root  wheel  - 53622 Mar 17 20:02 /usr/lib32/libheimbase.a
lrwxr-xr-x  1 root  wheel  -    17 May 24 17:11 
/usr/lib32/libheimbase.so -> libheimbase.so.11
-r--r--r--  1 root  wheel  - 13224 May 24 17:11 /usr/lib32/libheimbase.so.11
-r--r--r--  1 root  wheel  - 54966 Mar 17 20:02 /usr/lib32/libheimbase_p.a
-r--r--r--  1 root  wheel  - 67598 Mar 17 20:02 /usr/lib32/libheimntlm.a
lrwxr-xr-x  1 root  wheel  -    17 May 24 17:11 
/usr/lib32/libheimntlm.so -> libheimntlm.so.11
-r--r--r--  1 root  wheel  - 23840 May 24 17:11 /usr/lib32/libheimntlm.so.11
-r--r--r--  1 root  wheel  - 68746 Mar 17 20:02 /usr/lib32/libheimntlm_p.a
0{git}%


Looking at the pcap, nothing stands out as to what the problem might be. 
Looking at the replies, the ERROR is just "ERROR: No such file or 
directory" and doesnt correlate to the permission denied errors

reading from file nfs.pcap, link-type EN10MB (Ethernet)
    2 xid  reply ok
3371 xid  reply ok getattr CHR 11734062556 ids
  951 xid  reply ok getattr CHR 12231260544 ids
  626 xid  reply ok getattr ERROR: No such
    2 xid  reply ok getattr FIFO 10432271160 ids
6758 xid  reply ok getattr FIFO 10731272141 ids
  165 xid  reply ok getattr FIFO 11433667553 ids
  214 xid  reply ok getattr FIFO 12231260544 ids
3373 xid  reply ok getattr LNK 10333067563 ids
    2 xid  reply ok getattr LNK 12231267145 ids
    2 xid  reply ok getattr unk-ft 10 10536061550
    2 xid  reply ok getattr unk-ft 13 10334462541
    2 xid  reply ok getattr unk-ft 15 12231261554
  673 xid  reply ok getattr unk-ft 6 10130661545
  879 xid  reply ok getattr unk-ft 6 11433667553
  126 xid  reply ok getattr unk-ft 8 12231260544
    2 xid  reply ok null



From nobody Tue May 24 19:04:06 2022
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 ADDAD1AEE293
	for ; Tue, 24 May 2022 19:04:19 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L73XL6z1qz4RVR
	for ; Tue, 24 May 2022 19:04:18 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe31.google.com with SMTP id h4so8156418vsr.13
        for ; Tue, 24 May 2022 12:04:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=gbhSJOJVLEa9TiYLoW2RusGV3iozVPn7D3Ueg9pPqDw=;
        b=IXeUKX9DnRR3PTRW07aWO7iPU4raUZ6rXz1Nl1M5nx15WG0e6AvRN4bMMF3orsbi1O
         F+1Cn+ZqNDb7Y6TqTwTrOOOnwL8YNIYhW/KVUZOMuAvmcL5P+xykdXkApYYIhxHQLJ1C
         3CzqmAj4YPEWb6C4dgiV2qhuIQ4yZRiwuIPoKqBLLDh2guor/AaWQym5Ng/5EC0Xgi9V
         IMDHq4y4iHJLQO7ZSg1gwGzYefzdPClWplJ/6Byyz2ZGd0LGw0yBbL8tWKu1sHAoWjcs
         I3dThGrBXKeNQWyHxi5aZL2+0/u2kT47/y5yn64NSdr970weQzOjRRmhO5+T3ZM88c6u
         d3mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=gbhSJOJVLEa9TiYLoW2RusGV3iozVPn7D3Ueg9pPqDw=;
        b=N5ucPVBer40bnDeqpsiNjnEwpQaliSuf9mfbi/TQZcQebYDIUfTDRR2SzuazUJr/nY
         1qDRDl9GSvLvfuu1Nu5vWCDijmfoDVuHvWi0cGpoKg+gK8bV5+CfatlUwcNt3kTn5jht
         nAtkLXQKL0FWKXqFFbqPoTfRknqWezSW6rBlpMHFVXThgIOhUGYfWWPynS5wUDo8maL0
         +/Noxy5K+OIDnWfYbzphbFjPYsvIAh+fYJkmDfH9IoBVZqJ3EXYyJgMmwfIGUc+Mhd1H
         by5MbBSwpBaOACSzwCVjg3PKrGfErA5fxqKUJo3chSIHyRG0XHT7yeOYyTotEdSUBBk+
         Czpg==
X-Gm-Message-State: AOAM531C3C7Lues1vA6fhXW7ic6rYFbtUzAyyZCTXkCvPXGZaEnP+Z0i
	8jSebXSgXa46472OGt58vRnoELzflJjbVaVnKEfkrkmpHvw=
X-Google-Smtp-Source: ABdhPJwvOk8NqsJF1pt4gHmhSP4WJNPb5eaOwOrV9aEejK9b2imIFZwZEvc8ZmR/Qgo2HmNKOqj6lbOECGQx40INvrU=
X-Received: by 2002:a67:1547:0:b0:32c:f3a1:bdd8 with SMTP id
 68-20020a671547000000b0032cf3a1bdd8mr11849865vsv.44.1653419058183; Tue, 24
 May 2022 12:04:18 -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: <1cd6bcff-92d5-f155-9b19-b3a16d75fe19@sentex.net>
In-Reply-To: <1cd6bcff-92d5-f155-9b19-b3a16d75fe19@sentex.net>
From: Warner Losh 
Date: Tue, 24 May 2022 13:04:06 -0600
Message-ID: 
Subject: Re: make install[kernel|world] from read only /usr/obj possible ?
To: mike tancsa 
Cc: freebsd-current 
Content-Type: multipart/alternative; boundary="000000000000a0d1ba05dfc69f84"
X-Rspamd-Queue-Id: 4L73XL6z1qz4RVR
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=IXeUKX9D;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e31) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000a0d1ba05dfc69f84
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry for the top post...

It should work. It has worked in the past. This is a regression.

Warner

On Tue, May 24, 2022, 12:59 PM mike tancsa  wrote:

> On RELENG_12, I was able to mount via NFS /usr/obj and src and do an
> installworld on read only mounts. However, with RELENG_13 and above, I
> get permission denied errors. The install seems to continue just fine,
> but I am not sure if something subtle is being missed. Looking at what
> gets installed, the kernel modules get installed just fine.  However, it
> seems installworld has some problems with static libs (.a files). They
> dont seem to get re-installed. However, not sure if thats by design as
> doing a quick checksum, there is no difference on the build server and
> target of the ~ 700 .a files I checked in /usr/lib32 and /usr/lib. So
> despite the time stamps being off, maybe it just does not bother to
> update the target if they have not changed?
>
> e.g.
>
> make KERNCONF=3Dvtnet installkernel
>
>
> make warning: /usr/obj/usr/src: Permission denied.
> make[1] warning: /usr/src/: Permission denied.
> make[2] warning: /usr/obj/usr/src/amd64.amd64: Permission denied.
> --------------------------------------------------------------
>  >>> Install check kernel
> --------------------------------------------------------------
> --------------------------------------------------------------
>  >>> Installing kernel vtnet on Tue May 24 13:50:52 EDT 2022
> --------------------------------------------------------------
> cd /usr/obj/usr/src/amd64.amd64/sys/vtnet;  MACHINE_ARCH=3Damd64
> MACHINE=3Damd64  CPUTYPE=3D CC=3D"cc -target x86_64-unknown-freebsd13.1
> --sysroot=3D/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX=3D"c++  -target
> x86_64-unknown-freebsd13.1 --sysroot=3D/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  CPP=3D"cpp -target
> x86_64-unknown-freebsd13.1 --sysroot=3D/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  AS=3D"as" AR=3D"ar"
> ELFCTL=3D"elfctl" LD=3D"ld"  LLVM_LINK=3D"" NM=3Dnm OBJCOPY=3D"objcopy"
> RANLIB=3Dranlib STRINGS=3D  SIZE=3D"size" STRIPBIN=3D"strip"
> PATH=3D/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/=
tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd6=
4.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin=
:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/t=
mp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
>
> make  KERNEL=3Dkernel install
> make[2] warning: /usr/obj/usr/src/amd64.amd64/sys/vtnet: Permission denie=
d.
> thiskernel=3D`sysctl -n kern.bootfile || echo /boot/kernel/kernel` ;  if =
[
> ! "`dirname "$thiskernel"`" -ef /boot/kernel ] ; then chflags -R noschg
> /boot/kernel ;  rm -rf /boot/kernel ;  rm -rf /usr/lib/debug/boot/kernel
> ;  else  if [ -d /boot/kernel.old ] ; then  chflags -R noschg
> /boot/kernel.old ;  rm -rf /boot/kernel.old ;  fi ;  mv /boot/kernel
> /boot/kernel.old ;  if [ -n "/usr/lib/debug" -a  -d
> /usr/lib/debug/boot/kernel ]; then  rm -rf
> /usr/lib/debug/boot/kernel.old ;  mv /usr/lib/debug/boot/kernel
> /usr/lib/debug/boot/kernel.old ;  fi ; sysctl
> kern.bootfile=3D/boot/kernel.old/"`basename "$thiskernel"`" ;  fi
> kern.bootfile: /boot/kernel/kernel -> /boot/kernel.old/kernel
> mkdir -p /boot/kernel
> install -p -m 555 -o root -g wheel kernel /boot/kernel/
> mkdir -p /usr/lib/debug/boot/kernel
> install -p -m 555 -o root -g wheel kernel.debug /usr/lib/debug/boot/kerne=
l/
> cd /usr/src/sys/modules;
> MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules
> KMODDIR=3D/boot/kernel MACHINE_CPUARCH=3Damd64 MACHINE=3Damd64
> MACHINE_ARCH=3Damd64 MODULES_EXTRA=3D"" WITHOUT_MODULES=3D"" ARCH_FLAGS=
=3D""
> DEBUG_FLAGS=3D"-g" __MPATH=3D""
> KERNBUILDDIR=3D"/usr/obj/usr/src/amd64.amd64/sys/vtnet"
> SYSDIR=3D"/usr/src/sys" MODULE_TIED=3Dyes WITH_CTF=3D"1" KCSAN_ENABLED=3D=
"yes"
> COMPAT_FREEBSD32_ENABLED=3D"yes" make  install
> make[3] warning:
> /usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules:
> Permission denied.
> =3D=3D=3D> aac (install)
> make[4] warning:
> /usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/aac:
> Permission denied.
> install -T release -o root -g wheel -m 555   aac.ko /boot/kernel/
> install -T dbg -o root -g wheel -m 555   aac.ko.debug
> /usr/lib/debug/boot/kernel/
> =3D=3D=3D> aacraid (install)
> make[4] warning:
> /usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/aacrai=
d:
>
> Permission denied.
> install -T release -o root -g wheel -m 555   aacraid.ko /boot/kernel/
> install -T dbg -o root -g wheel -m 555   aacraid.ko.debug
> /usr/lib/debug/boot/kernel/
> =3D=3D=3D> accf_data (install)
> make[4] warning:
> /usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/accf_d=
ata:
>
> Permission denied.
>
>
> eg.
>
> 0{git}% ls -l /usr/lib32/libhei*
> -r--r--r--  1 root  wheel  - 53622 Mar 17 20:02 /usr/lib32/libheimbase.a
> lrwxr-xr-x  1 root  wheel  -    17 May 24 17:11
> /usr/lib32/libheimbase.so -> libheimbase.so.11
> -r--r--r--  1 root  wheel  - 13224 May 24 17:11
> /usr/lib32/libheimbase.so.11
> -r--r--r--  1 root  wheel  - 54966 Mar 17 20:02 /usr/lib32/libheimbase_p.=
a
> -r--r--r--  1 root  wheel  - 67598 Mar 17 20:02 /usr/lib32/libheimntlm.a
> lrwxr-xr-x  1 root  wheel  -    17 May 24 17:11
> /usr/lib32/libheimntlm.so -> libheimntlm.so.11
> -r--r--r--  1 root  wheel  - 23840 May 24 17:11
> /usr/lib32/libheimntlm.so.11
> -r--r--r--  1 root  wheel  - 68746 Mar 17 20:02 /usr/lib32/libheimntlm_p.=
a
> 0{git}%
>
>
> Looking at the pcap, nothing stands out as to what the problem might be.
> Looking at the replies, the ERROR is just "ERROR: No such file or
> directory" and doesnt correlate to the permission denied errors
>
> reading from file nfs.pcap, link-type EN10MB (Ethernet)
>     2 xid  reply ok
> 3371 xid  reply ok getattr CHR 11734062556 ids
>   951 xid  reply ok getattr CHR 12231260544 ids
>   626 xid  reply ok getattr ERROR: No such
>     2 xid  reply ok getattr FIFO 10432271160 ids
> 6758 xid  reply ok getattr FIFO 10731272141 ids
>   165 xid  reply ok getattr FIFO 11433667553 ids
>   214 xid  reply ok getattr FIFO 12231260544 ids
> 3373 xid  reply ok getattr LNK 10333067563 ids
>     2 xid  reply ok getattr LNK 12231267145 ids
>     2 xid  reply ok getattr unk-ft 10 10536061550
>     2 xid  reply ok getattr unk-ft 13 10334462541
>     2 xid  reply ok getattr unk-ft 15 12231261554
>   673 xid  reply ok getattr unk-ft 6 10130661545
>   879 xid  reply ok getattr unk-ft 6 11433667553
>   126 xid  reply ok getattr unk-ft 8 12231260544
>     2 xid  reply ok null
>
>
>
>

--000000000000a0d1ba05dfc69f84
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Sorry for the top post...

It should work. It has worked in the past. This is a regressi=
on.=C2=A0

Warner=C2=A0

On Tue, May 24, 2022, 12:59 PM mike tancsa <mike@sentex.net> wrote:
On RELENG_12, I was able to mount via NFS /usr/obj and src and do an=
 

installworld on read only mounts. However, with RELENG_13 and above, I 

get permission denied errors. The install seems to continue just fine, 

but I am not sure if something subtle is being missed. Looking at what 

gets installed, the kernel modules get installed just fine.=C2=A0 However, =
it 

seems installworld has some problems with static libs (.a files). They 

dont seem to get re-installed. However, not sure if thats by design as 

doing a quick checksum, there is no difference on the build server and 

target of the ~ 700 .a files I checked in /usr/lib32 and /usr/lib. So 

despite the time stamps being off, maybe it just does not bother to 

update the target if they have not changed?



e.g.



make KERNCONF=3Dvtnet installkernel





make warning: /usr/obj/usr/src: Permission denied.

make[1] warning: /usr/src/: Permission denied.

make[2] warning: /usr/obj/usr/src/amd64.amd64: Permission denied.

--------------------------------------------------------------

=C2=A0>>> Install check kernel

--------------------------------------------------------------

--------------------------------------------------------------

=C2=A0>>> Installing kernel vtnet on Tue May 24 13:50:52 EDT 2022<=
br>
--------------------------------------------------------------

cd /usr/obj/usr/src/amd64.amd64/sys/vtnet;=C2=A0 MACHINE_ARCH=3Damd64 

MACHINE=3Damd64=C2=A0 CPUTYPE=3D CC=3D"cc -target x86_64-unknown-freeb=
sd13.1 

--sysroot=3D/usr/obj/usr/src/amd64.amd64/tmp 

-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX=3D"c++=C2=A0 -tar=
get 

x86_64-unknown-freebsd13.1 --sysroot=3D/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"=C2=A0 CPP=3D"cpp -tar=
get 

x86_64-unknown-freebsd13.1 --sysroot=3D/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"=C2=A0 AS=3D"as" =
AR=3D"ar" 

ELFCTL=3D"elfctl" LD=3D"ld"=C2=A0 LLVM_LINK=3D"&qu=
ot; NM=3Dnm OBJCOPY=3D"objcopy" 

RANLIB=3Dranlib STRINGS=3D=C2=A0 SIZE=3D"size" STRIPBIN=3D"s=
trip" 

PATH=3D/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tm=
p/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.=
amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/=
usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp=
/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin 

make=C2=A0 KERNEL=3Dkernel install

make[2] warning: /usr/obj/usr/src/amd64.amd64/sys/vtnet: Permission denied.=


thiskernel=3D`sysctl -n kern.bootfile || echo /boot/kernel/kernel` ;=C2=A0 =
if [ 

! "`dirname "$thiskernel"`" -ef /boot/kernel ] ; then c=
hflags -R noschg 

/boot/kernel ;=C2=A0 rm -rf /boot/kernel ;=C2=A0 rm -rf /usr/lib/debug/boot=
/kernel 

;=C2=A0 else=C2=A0 if [ -d /boot/kernel.old ] ; then=C2=A0 chflags -R nosch=
g 

/boot/kernel.old ;=C2=A0 rm -rf /boot/kernel.old ;=C2=A0 fi ;=C2=A0 mv /boo=
t/kernel 

/boot/kernel.old ;=C2=A0 if [ -n "/usr/lib/debug" -a=C2=A0 -d 
/usr/lib/debug/boot/kernel ]; then=C2=A0 rm -rf 

/usr/lib/debug/boot/kernel.old ;=C2=A0 mv /usr/lib/debug/boot/kernel 

/usr/lib/debug/boot/kernel.old ;=C2=A0 fi ; sysctl 

kern.bootfile=3D/boot/kernel.old/"`basename "$thiskernel"`&q=
uot; ;=C2=A0 fi

kern.bootfile: /boot/kernel/kernel -> /boot/kernel.old/kernel

mkdir -p /boot/kernel

install -p -m 555 -o root -g wheel kernel /boot/kernel/

mkdir -p /usr/lib/debug/boot/kernel

install -p -m 555 -o root -g wheel kernel.debug /usr/lib/debug/boot/kernel/=


cd /usr/src/sys/modules; 

MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules 

KMODDIR=3D/boot/kernel MACHINE_CPUARCH=3Damd64 MACHINE=3Damd64 

MACHINE_ARCH=3Damd64 MODULES_EXTRA=3D"" WITHOUT_MODULES=3D"&=
quot; ARCH_FLAGS=3D"" 

DEBUG_FLAGS=3D"-g" __MPATH=3D"" 

KERNBUILDDIR=3D"/usr/obj/usr/src/amd64.amd64/sys/vtnet" 

SYSDIR=3D"/usr/src/sys" MODULE_TIED=3Dyes WITH_CTF=3D"1"=
; KCSAN_ENABLED=3D"yes" 

COMPAT_FREEBSD32_ENABLED=3D"yes" make=C2=A0 install

make[3] warning: 

/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules: 

Permission denied.

=3D=3D=3D> aac (install)

make[4] warning: 

/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/aac: 
Permission denied.

install -T release -o root -g wheel -m 555=C2=A0=C2=A0 aac.ko /boot/kernel/=


install -T dbg -o root -g wheel -m 555=C2=A0=C2=A0 aac.ko.debug 

/usr/lib/debug/boot/kernel/

=3D=3D=3D> aacraid (install)

make[4] warning: 

/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/aacraid:=
 

Permission denied.

install -T release -o root -g wheel -m 555=C2=A0=C2=A0 aacraid.ko /boot/ker=
nel/

install -T dbg -o root -g wheel -m 555=C2=A0=C2=A0 aacraid.ko.debug 

/usr/lib/debug/boot/kernel/

=3D=3D=3D> accf_data (install)

make[4] warning: 

/usr/obj/usr/src/amd64.amd64/sys/vtnet/modules/usr/src/sys/modules/accf_dat=
a: 

Permission denied.





eg.



0{git}% ls -l /usr/lib32/libhei*

-r--r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 - 53622 Mar 17 20:02 /usr/lib32/l=
ibheimbase.a

lrwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 -=C2=A0=C2=A0=C2=A0 17 May 24 17:=
11 

/usr/lib32/libheimbase.so -> libheimbase.so.11

-r--r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 - 13224 May 24 17:11 /usr/lib32/l=
ibheimbase.so.11

-r--r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 - 54966 Mar 17 20:02 /usr/lib32/l=
ibheimbase_p.a

-r--r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 - 67598 Mar 17 20:02 /usr/lib32/l=
ibheimntlm.a

lrwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 -=C2=A0=C2=A0=C2=A0 17 May 24 17:=
11 

/usr/lib32/libheimntlm.so -> libheimntlm.so.11

-r--r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 - 23840 May 24 17:11 /usr/lib32/l=
ibheimntlm.so.11

-r--r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 - 68746 Mar 17 20:02 /usr/lib32/l=
ibheimntlm_p.a

0{git}%





Looking at the pcap, nothing stands out as to what the problem might be. 
Looking at the replies, the ERROR is just "ERROR: No such file or 

directory" and doesnt correlate to the permission denied errors



reading from file nfs.pcap, link-type EN10MB (Ethernet)

=C2=A0=C2=A0=C2=A0 2 xid=C2=A0 reply ok

3371 xid=C2=A0 reply ok getattr CHR 11734062556 ids

=C2=A0=C2=A0951 xid=C2=A0 reply ok getattr CHR 12231260544 ids

=C2=A0=C2=A0626 xid=C2=A0 reply ok getattr ERROR: No such

=C2=A0=C2=A0=C2=A0 2 xid=C2=A0 reply ok getattr FIFO 10432271160 ids

6758 xid=C2=A0 reply ok getattr FIFO 10731272141 ids

=C2=A0=C2=A0165 xid=C2=A0 reply ok getattr FIFO 11433667553 ids

=C2=A0=C2=A0214 xid=C2=A0 reply ok getattr FIFO 12231260544 ids

3373 xid=C2=A0 reply ok getattr LNK 10333067563 ids

=C2=A0=C2=A0=C2=A0 2 xid=C2=A0 reply ok getattr LNK 12231267145 ids

=C2=A0=C2=A0=C2=A0 2 xid=C2=A0 reply ok getattr unk-ft 10 10536061550

=C2=A0=C2=A0=C2=A0 2 xid=C2=A0 reply ok getattr unk-ft 13 10334462541

=C2=A0=C2=A0=C2=A0 2 xid=C2=A0 reply ok getattr unk-ft 15 12231261554

=C2=A0=C2=A0673 xid=C2=A0 reply ok getattr unk-ft 6 10130661545

=C2=A0=C2=A0879 xid=C2=A0 reply ok getattr unk-ft 6 11433667553

=C2=A0=C2=A0126 xid=C2=A0 reply ok getattr unk-ft 8 12231260544

=C2=A0=C2=A0=C2=A0 2 xid=C2=A0 reply ok null










--000000000000a0d1ba05dfc69f84--

From nobody Tue May 24 22:28:34 2022
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 501181B3CFAF
	for ; Tue, 24 May 2022 22:29:31 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L78571sy8z3HC7;
	Tue, 24 May 2022 22:29:31 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1653431371;
	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=ZYMP20D6wKsx0FrrOl+59OlRTK8pycC5lzsnZXvwDJw=;
	b=SVqnwEAdnMCii1KT+DNVj818fwB2V8nt6vgXDZE8EhX4nlFhq/1de/B59IMtAc4pSPlI+L
	dfCZsknvGMVfNPVTJRQWQxHam6j2dkFmtr+8WWCwp/lD7M4I4IgX/Rr+Rc3CPexuuaTNM9
	XEK4U+ByovX6t44ce9p3jCWD0hBDjy16u6o05RKAMX4q7AqM1cxUpjXWaGdINLGq4pR8EH
	dxLG0FCZgjeAALXgvPYZqC8KU9D/nLOwRxMnFJ4AJtmkgPkdvgZ2p5O7KNFsszYVVKQuSJ
	5EHQJeSEj8sIAwwH8hj+yUFHcuqUOdaVAIzk+Cx64DTuFPgQRENb7+hyrSxIpQ==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:41e2:b05:bb10:94fd])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 87DD94E86;
	Tue, 24 May 2022 22:29:30 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Wed, 25 May 2022 07:28:34 +0900 (JST)
Message-Id: <20220525.072834.2264782493695636925.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: 20220519 snapshot: loader fails to find bootable partition of
 zfs-root system
From: Yasuhiro Kimura 
In-Reply-To: 
References: <20220524.123637.1579380844342215240.yasu@FreeBSD.org>
	
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1653431371;
	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=ZYMP20D6wKsx0FrrOl+59OlRTK8pycC5lzsnZXvwDJw=;
	b=GRvd6oixxZcybbFug9mKkPFaFDvFlxZZ1h6pbYlcYTXrOAAiKswafOH6JoGV8zKShYVYEh
	w5usMVBAVG8nMSsnlm3AOADBW/BDnHTVZyw54mwU6CZVcbCX24d9vN3up+L8vhsDVXkt/x
	yfRk55DNhEtpGfZEFhn2MBE29JXlMXoPkFf1tJsdsu7JmqqmAGYfPxw7BNx9MVbcu112sM
	VuwsSOEaP1G3S+q83Fto3sIZgT1oN2XUtRxu8cAD6yZuMMYc0X6/kbvy/NbxtzNPA3irEG
	5nKrOvKZ8avqKalHBgOosRbhRA9/r5jklZKpJpig+tREw4f9Ii7S/ctU+Rqlbw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653431371; a=rsa-sha256; cv=none;
	b=SBlrzk3mlMU4TU6b/EnX2Cn54X4k/0kAj4y2SP7mTpwYCX7lR5qaUbux5xzTLhINwKtSY1
	xPATbW7Gda7kXjzq4tVFKifHJdVAYbUYkFGH/eNptSGldlf2lO7KvGNXAzFV+r5KSizcTI
	pUoQxrZ1aWMnaHzoVCDK9ikpMYGmWRkzrxe8d5RCKLf4zAZ5pWh5gT+0MGAVF6UXBw+i/L
	wNHwnbs9ikV3B7B3zOlKyKHQM+f0TzmtwEye1+IZwEA7BW2P3gYLz+jMDnh9QP5gGoPu58
	bvi2F1G9/wxt9JB/vRBN6iS6n7YsbdLDiH1Vv6HIGrvoDFhckKFLHwqmhdZBgA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

From: Navdeep Parhar 
Subject: Re: 20220519 snapshot: loader fails to find bootable partition of zfs-root system
Date: Mon, 23 May 2022 22:03:57 -0700

> On Mon, May 23, 2022 at 8:40 PM Yasuhiro Kimura  wrote:
>>
>> Hello,
>>
>> I made clean install of zfs-root 14-CURRENT amd64 system with install
>> image of 20220519 snapshop. After installation completed and system is
>> rebooted, boot fails as loader fails to find bootable partition as
>> following.
>>
>> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220519snapshot.png
>>
>> If I use 20220512 snapshop instead, then system starts up
>> successfully.
> 
> You need a loader with commit 9cd45772a44f268ccb3e20caf7f3f764f6b5e1a1
> to deal with the latest OpenZFS.
> 
> Regards,
> Navdeep
> 

Thanks for reply. I installed system with 20220512 snapshot, update it
to latest commit and upgraded zroot with `zpool upgrade zroot`. Then
it boots successfully.

---
Yasuhiro Kimura

From nobody Wed May 25 12:25:29 2022
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 09A161B5F55E
	for ; Wed, 25 May 2022 12:25:34 +0000 (UTC)
	(envelope-from matteo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L7Vdn6d6vz3G5y;
	Wed, 25 May 2022 12:25:33 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1653481533;
	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;
	bh=G4PH4KeIibF1fdfIlBMLogmwPGxpo6geB+KWVL5+kGk=;
	b=Zqt8QGQTF65V+H7aBV0WgoyWAqY5lhGogtqeC0jqqrygZwCjs1lr5KKcvO6JquDxEr+OBh
	PM+iyZSCqjgy19gR9977pma+IiFd1Ceb+vpO2IHtBHVIQyhLkrHenghMOfXAz9Q6Gngtux
	4vTxxVcugZgua1mC5SM1GzCPFEQkBDcBseD+2f8MHPvdu6eYdHPe1HcEqpyWjmVUGJ/kJm
	IXFctkQVXdZQvW01AI7r7OyWFIqJnRVpn/JiuzXkwEwVBMOIiEbhwyznWNBhxwvG5DsfFS
	/kXxqgStjjM/HAt4ksJZdD3PIN+lKUh61x2MafAQxnjjlrFoC6FpyfbV4VLO6Q==
Received: from host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu (unknown [IPv6:2601:19b:4400:1779::107b])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: matteo/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id A359BC9AB;
	Wed, 25 May 2022 12:25:33 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Date: Wed, 25 May 2022 08:25:29 -0400
From: Matteo Riondato 
To: freebsd-current@freebsd.org
Cc: Jim Harris 
Subject: nvme INVALID_FIELD in dmesg.boot
Message-ID: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
X-PGP-Key: http://rionda.to/files/matteogpg.asc
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="eg4wm5j6wmnbrobt"
Content-Disposition: inline
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1653481533;
	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;
	bh=G4PH4KeIibF1fdfIlBMLogmwPGxpo6geB+KWVL5+kGk=;
	b=gX3Jb9U+uSWPNSNxcxOQPQtPZrmFyB9XMlH7mlS6YX6lGh5JavLku5zlAGMQZaKtSm5Dhp
	hfsspNA9N43V1QlTG63vNSMPrz0mb4/TxTmv6mruefxW5PccjWE1fSsD4I2Q6iulXUhAmP
	TgQJNty1oy16uLHNFz3wiZmkUizVtM+vpk10jeRRbnSmPzl7Kf/cgspoepFvFNi7hXFb4F
	45kkDbugFSmNTChG2xpdnfmJiY2h/W7f87dXdUpSXTAZLhAyVY6+H2PfFsFhqm3mJjZ60B
	GoHlQaqdbpAVc1Lc67KA0XiWXnx+vpkytRDoZQqJrjmr4vBPuamy2UynYerkzw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653481533; a=rsa-sha256; cv=none;
	b=MeKDCzj5tJmQsKjA7f7j9dJGXaqEBTaVVqz7RP6TkCygsx8+xZUl/PR098Lo080W4+yJGX
	nBwzstyc8CktBN2y63tf27Fb4rl/qLlaDs6hlVFXfoBULBEVrungfMWjbw28si6GKR3xXC
	XEs8UhTaGA6DBoXvKEx5QVi1anpPAWc2mNxd2fNQhuvHRriP112nhPksQVTaPmRmjy7neg
	h2yqARTlXknGoVlAxxnGLmyrc6raeFX6YFfR7xt8uG2RpE/oGzpAiaYk8DpzQI9z0qfaAT
	8RFmzaHOZCptPT+d/A1t26Zn4msL3GkgCcsETV0tAPwlHvlGq2B/b90UKlLvCw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--eg4wm5j6wmnbrobt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Dear list,

My dmesg.boot contains the following entries containing "INVALID_FIELD"=20
about nvme (I use nda(4) for my nvme disks, with hw.nvme.use_nvd=3D0 in=20
loader.conf):

trismegistus ~ % grep -e 'nvme[0-9]\?' /var/run/dmesg.boot
nvme0:  mem 0xb8610000-0xb8613fff irq 40 at device 0.0=20
numa-domain 0 on pci7
nvme1:  mem 0xb8510000-0xb8513fff irq 47 at device 0.0=20
numa-domain 0 on pci8
nvme2:  mem 0xc5e10000-0xc5e13fff irq 48 at device 0.0=20
numa-domain 0 on pci10
nvme3:  mem 0xc5d10000-0xc5d13fff irq 55 at device 0.0=20
numa-domain 0 on pci11
nvme0: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b=20
cdw11:0000031f
nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nvme1: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b=20
cdw11:0000031f
nvme1: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nvme2: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b=20
cdw11:0000031f
nvme2: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nvme3: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b=20
cdw11:0000031f
nvme3: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nda0 at nvme0 bus 0 scbus16 target 0 lun 1
nda0: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
nda1 at nvme1 bus 0 scbus17 target 0 lun 1
nda1: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
nda2 at nvme2 bus 0 scbus18 target 0 lun 1
nda2: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
nda3 at nvme3 bus 0 scbus19 target 0 lun 1
nda3: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link

The disks seem to work fine, from what I can tell.

Are the "INVALID_FIELD" messages harmless, or can they be avoided with=20
some tuning, or maybe with some patch?

Thanks,
Matteo

--eg4wm5j6wmnbrobt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmKOICoTGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVAdaeEADGskJ2qokIyom6g9V7euBQ/niBIuob
F3m+8hvCcMZWiswQSyNQ0xQRPSCO+AsWAMQC56wSSadHcB92GsU/PN7aP1x+oibj
FfkiXxHtI/iLXXGSg90vZnS5RrpYclnHzGYWa95WAP1MiVHtS5c6nFEepb2JmyI3
lCBMLN5OaR9f5kYgsJNiXQbJZv1STzkspGqHR/hhhDQSZEcP11NnW3yiupxkevKq
CjRG/27jyy22mVgnOLW2/U743JS/7XmfoA4GnueONs7knUcTmCq4+3HAeLG/mFtj
UWD+IMJckHN676SdP3KefLY/5Sd62lcSPh6DfLAe8WUBJ3eaWe+h1nyUMuLGDTS1
TjNC1lsatjnQLaanUApH7fMvfxVf5GlqKf6BMudnwFnKya9QcGss3r3FAV+dSrg6
HpNcLxGmhQttyjiDPqFIqmyvOVwiloUFpynmNAowvvYmTe/Tn1NXxep4KPcMR5S4
zRs1bx+yFrwGp4kBYBAmhYre4X6kD5kTxKshuu4Jj6HzDsy584EcgEMIfR4lpfqg
Rz3HxXjd5EXkQjx/6zZgTh75yG5rCPdZZ2zv6uaS7S82gT6gG2eC+71rPssTqkxP
BvbESgL+cDSETvZVVEPVhhn0A1QOunTZNLJlwmy4n+tVnruTBPHOlh8BJ1NxBwaB
G/9d6G4yCeAa1w==
=xvSN
-----END PGP SIGNATURE-----

--eg4wm5j6wmnbrobt--

From nobody Wed May 25 13:01:38 2022
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 875021B3EB29
	for ; Wed, 25 May 2022 13:01:58 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L7WRn5qQrz3Ky5
	for ; Wed, 25 May 2022 13:01:57 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: by mail-ed1-f42.google.com with SMTP id j4so22502603edq.6
        for ; Wed, 25 May 2022 06:01:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=+ekbCdU3fxwuLxxxLHjVrEZv+TM/y5teKqfysrGiLxA=;
        b=tmJc5I20NiN/OgMyPCZvoI/rsz+68wL0K+HnZfBzX6gMSK41pzCRy2zeHO1H48y2ic
         +6l7rvQY2CsOoVHiIoHacy6lxKMgjw+aIQmexDnrVdLpacKp5bA/7hAqF3f//rnreTMB
         tJc3BpsSrtWY3+OoK3+z6MaZudVWwhdW7eCONCxIWi6MuTsln/7+tqJDoIQ4ffJL9JzY
         /KMLSA9tHJISFicSsA11eYDE4MGVfDQ/fAcxT/GcpQi6c4iGZ0M/8dmnzcYGW4u3GvLW
         Hk8iiL/D2KuffaivxVp1jJWoB0tQhqENb95tOuQwY8+T4YDKVn71FtDnf6Xf/FPiJhNe
         wkLg==
X-Gm-Message-State: AOAM533lvX/vwHnNZFgj1YyEntz7nqoMswC5x2zRg8oXHgYjs1usZB8f
	GFCh6ojZgL0Ssx85ndzhFnPO++1Xas/PxsErOj8=
X-Google-Smtp-Source: ABdhPJwXE8WTDZAQb2FmiVDbesVfzeBIVDNcMNEQkrF7ch0wF+DfXPq+nWEec8vrxytKemNy31mEXc+PbNY3zK6Taa8=
X-Received: by 2002:a05:6402:4306:b0:42b:694a:b84b with SMTP id
 m6-20020a056402430600b0042b694ab84bmr16192277edc.67.1653483710375; Wed, 25
 May 2022 06:01:50 -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: <20b1c8ea-71ef-784f-a6bd-de1abce406a0@gmail.com>
In-Reply-To: <20b1c8ea-71ef-784f-a6bd-de1abce406a0@gmail.com>
From: Ed Maste 
Date: Wed, 25 May 2022 09:01:38 -0400
Message-ID: 
Subject: Re: (263489) (D35109) freebsd-update: restart sshd after upgrade
To: Graham Perrin 
Cc: FreeBSD Current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4L7WRn5qQrz3Ky5
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FREEFALL_USER(0.00)[carpeddiem];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	 RCVD_TLS_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[freebsd.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[209.85.208.42:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.42:from];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	 FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 2 May 2022 at 20:17, Graham Perrin  wrote:
>
> 
> (line 3028)
>
> How will freebsd-update behave in this case?
>
> > Cannot 'status' sshd. Set sshd_enable to YES in /etc/rc.conf or use
> > 'onestatus' instead of 'status'.

If it's not already running nothing will happen.

From nobody Wed May 25 13:52:40 2022
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 7B38D1B47FB4
	for ; Wed, 25 May 2022 13:52:59 +0000 (UTC)
	(envelope-from ctuffli@gmail.com)
Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L7XZf5ZlQz3R0t;
	Wed, 25 May 2022 13:52:58 +0000 (UTC)
	(envelope-from ctuffli@gmail.com)
Received: by mail-ej1-f50.google.com with SMTP id i27so41813344ejd.9;
        Wed, 25 May 2022 06:52:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=zn3MzAJuNkzkQyX5i9Y00IOsnyg7Yb+Qga2/pNUBK/c=;
        b=jviucTUklgmnUXfwvPhwWeeNCknck0lwDstmAJj7U6MbGz0rtCtinhm5TE8nntRwy/
         +Ygm033T+YPIdr+oBm+6BJVdoWdww4x5XuRFtklSoh/drhMc0UbV4J8STAbrRflDQcGD
         5hJpADRosIsH0mypMg/aNA9cw6mnOlnZwkEx48dm9QxpmZ5XpufCuKfYhtOPxADL6SOU
         d4uwtI1/fUu4nhCARqEWowOg6FiyKs1CFJrv0jFdMc0S8ouLcVsv1iSeMKx8IxTy/NEp
         mO2tCwyDQMsW9XNVemtkpnlJtGBjBF/xdmAILHXzfOVJOywFEwdRftmhXU7v2zX18IMu
         sZCQ==
X-Gm-Message-State: AOAM5335U0ad1lIzVDY0FZM8KBGta2xuawe2/8QmFpnyGho8ABfQjfE7
	I+2AFzvURETdomwIMybMYpOMs5zYYAJV/w==
X-Google-Smtp-Source: ABdhPJwehqxETAtbHERn94OD4n6skldjtR7G2o/ZGutv/eGIyu3UBc7aC7UZLPqF08p8SPqf5hVIvA==
X-Received: by 2002:a17:907:7ea5:b0:6ff:1a57:28de with SMTP id qb37-20020a1709077ea500b006ff1a5728demr589591ejc.60.1653486772273;
        Wed, 25 May 2022 06:52:52 -0700 (PDT)
Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com. [209.85.218.49])
        by smtp.gmail.com with ESMTPSA id k9-20020a17090627c900b006febc1e9fc8sm4782030ejc.47.2022.05.25.06.52.51
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 25 May 2022 06:52:51 -0700 (PDT)
Received: by mail-ej1-f49.google.com with SMTP id rs12so30098204ejb.13;
        Wed, 25 May 2022 06:52:51 -0700 (PDT)
X-Received: by 2002:a17:906:3958:b0:6fe:90ef:c4b with SMTP id
 g24-20020a170906395800b006fe90ef0c4bmr29830437eje.36.1653486771464; Wed, 25
 May 2022 06:52:51 -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: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
In-Reply-To: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
From: Chuck Tuffli 
Date: Wed, 25 May 2022 06:52:40 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: nvme INVALID_FIELD in dmesg.boot
To: Matteo Riondato 
Cc: FreeBSD-Current , Jim Harris 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4L7XZf5ZlQz3R0t
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of ctuffli@gmail.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=ctuffli@gmail.com
X-Spamd-Result: default: False [-1.78 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 RCVD_TLS_ALL(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RWL_MAILSPIKE_GOOD(0.00)[209.85.218.50:from];
	 NEURAL_SPAM_SHORT(0.22)[0.219];
	 RCVD_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[209.85.218.50:from,209.85.218.49:received];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[chuck@freebsd.org,ctuffli@gmail.com];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	 FROM_NEQ_ENVFROM(0.00)[chuck@freebsd.org,ctuffli@gmail.com];
	 FREEMAIL_ENVFROM(0.00)[gmail.com]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, May 25, 2022 at 5:26 AM Matteo Riondato  wrote:
...
> nvme0: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
> cdw11:0000031f
> nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
...
> nda0 at nvme0 bus 0 scbus16 target 0 lun 1
> nda0: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
...
> The disks seem to work fine, from what I can tell.
>
> Are the "INVALID_FIELD" messages harmless, or can they be avoided with
> some tuning, or maybe with some patch?

The log messages mean the driver is sending the Set Features command
with an invalid parameter. Usually, this won't be fatal which seems to
be the case here as the nda appear.

If the logging output is to be believed, the invalid parameter is
CDW10 which shouldn't be 0x0. That said, I'm not immediately seeing
how that could be the case. It would be interesting to set
hw.nvme.verbose_cmd_dump to confirm this is happening.

--chuck

From nobody Wed May 25 13:58:54 2022
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 62E331B49AE1
	for ; Wed, 25 May 2022 13:59:04 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L7Xjg3KCQz3jV4;
	Wed, 25 May 2022 13:59:03 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: by mail-qk1-x72d.google.com with SMTP id j6so17343605qkp.9;
        Wed, 25 May 2022 06:59:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:message-id:date:mime-version:user-agent:subject
         :content-language:to:cc:references:from:in-reply-to
         :content-transfer-encoding;
        bh=YF+kB1Iy8IY0vfXlBSXrzmjMclm0F4wpn86oIuNL+/0=;
        b=aQLWdgs8YZRbsMFaFB33t0SYFqejpewkJYoCVM/BaoPL6LfaHX/mEhNuASIUlQHfNa
         OMYN8RaNauFsVlNH5O6+R/E2bi09XLpTr6ziiILGcaBh9PoTp2NmQOLPY1axrXMk2jaY
         6tELKZpqD7U1SWAacaZ1ueGeCeJOjQTb69gMEMmvptnr603qmAFOliZ78Yn3rALl4baI
         uk55/yXeaDHLnetWdSJy03ur6LRC0X4Ux6y/Q33VmlhW6cMiXWtHhKJo9UZbtYwb2xQa
         lUyEchHKKALkHA/5k8jFQ6k+HjhDfqly7MCRUamhNV+mnN2Fs0jrMvYsbEt+3M/A319X
         cQPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:message-id:date:mime-version:user-agent
         :subject:content-language:to:cc:references:from:in-reply-to
         :content-transfer-encoding;
        bh=YF+kB1Iy8IY0vfXlBSXrzmjMclm0F4wpn86oIuNL+/0=;
        b=7joitKthWGd7lzNLOY1VOAI+jAI1MlR8dyNcnyD0S99bzCf0lLTKURYkc6e1xKnyMa
         PPtZ9iBWkPinEPr2VzDaqMkjH4fK6KsgqnXfSc8bfOWyNrzijcb6oAI9SLCyyFKiMbK9
         U0QstSlW64lajTYKoaL7t4xAm2VUdSz6RAbLz/0caLP0WqhldIOqlsa7XVoESIdvDkAC
         cAAxtdilIrrJ8b9GbUZ98vcwQ57irPrNbRQHHVhlSPhtJgTG+Wd2a2m+gyJNxQA7KGpy
         BFoHvMCWtJX0dsapa3UTrKsxvft1lhZPKXEP9twGncpbSrgdIlYFYy9mA7F3yXsfnHX1
         uYcA==
X-Gm-Message-State: AOAM530F8FIQh5PYvJfC0Kfn6ltojLoGPzGP2+hfSNmr2P2u7MUsTJME
	9pz3lys9rRJtZ3UVrztYGX+pQBj1o4E=
X-Google-Smtp-Source: ABdhPJxKvyReL915WyxHvwUJHevxLJrT7ItziJx1+LVqYclsIg3iqYsSwjrF0Nhvn/Al0lzJUPW0Kg==
X-Received: by 2002:a37:b42:0:b0:6a3:6133:674c with SMTP id 63-20020a370b42000000b006a36133674cmr14401690qkl.325.1653487136607;
        Wed, 25 May 2022 06:58:56 -0700 (PDT)
Received: from ?IPV6:2603:3011:17c0:0:228:f8ff:fe04:d12? ([2603:3011:17c0:0:228:f8ff:fe04:d12])
        by smtp.gmail.com with ESMTPSA id i75-20020a379f4e000000b006a38debe62csm1324418qke.89.2022.05.25.06.58.55
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 25 May 2022 06:58:55 -0700 (PDT)
Message-ID: 
Date: Wed, 25 May 2022 09:58:54 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: nvme INVALID_FIELD in dmesg.boot
Content-Language: en-US
To: Matteo Riondato , freebsd-current@freebsd.org
Cc: Jim Harris 
References: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
From: Alexander Motin 
In-Reply-To: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4L7Xjg3KCQz3jV4
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=aQLWdgs8;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::72d as permitted sender) smtp.mailfrom=mavbsd@gmail.com
X-Spamd-Result: default: False [-2.87 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[FreeBSD.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 NEURAL_HAM_SHORT(-0.67)[-0.671];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72d:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com];
	 RCVD_TLS_ALL(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 25.05.2022 08:25, Matteo Riondato wrote:
> My dmesg.boot contains the following entries containing "INVALID_FIELD" 
> about nvme (I use nda(4) for my nvme disks, with hw.nvme.use_nvd=0 in 
> loader.conf):
> 
> trismegistus ~ % grep -e 'nvme[0-9]\?' /var/run/dmesg.boot
> nvme0:  mem 0xb8610000-0xb8613fff irq 40 at device 0.0 
> numa-domain 0 on pci7
> nvme1:  mem 0xb8510000-0xb8513fff irq 47 at device 0.0 
> numa-domain 0 on pci8
> nvme2:  mem 0xc5e10000-0xc5e13fff irq 48 at device 0.0 
> numa-domain 0 on pci10
> nvme3:  mem 0xc5d10000-0xc5d13fff irq 55 at device 0.0 
> numa-domain 0 on pci11
> nvme0: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b cdw11:0000031f
> nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> nvme1: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b cdw11:0000031f
> nvme1: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> nvme2: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b cdw11:0000031f
> nvme2: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> nvme3: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b cdw11:0000031f
> nvme3: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> nda0 at nvme0 bus 0 scbus16 target 0 lun 1
> nda0: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> nda1 at nvme1 bus 0 scbus17 target 0 lun 1
> nda1: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> nda2 at nvme2 bus 0 scbus18 target 0 lun 1
> nda2: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> nda3 at nvme3 bus 0 scbus19 target 0 lun 1
> nda3: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> 
> The disks seem to work fine, from what I can tell.
> 
> Are the "INVALID_FIELD" messages harmless, or can they be avoided with 
> some tuning, or maybe with some patch?

Those messages mean that driver tried to enable certain types of 
asynchronous events, but probably the hardware does not support some of 
those.  If you wish to experiment we could try to mask some of the bits 
in nvme_ctrlr_configure_aer() function to find out which one exactly, 
but for discontinued drives 4-5 years old it might not have too much 
sense.  It should not be critical unless you either overheat them, or 
somehow else they fail and wish to report it.

-- 
Alexander Motin

From nobody Wed May 25 14:17:15 2022
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 63A411B50969
	for ; Wed, 25 May 2022 14:17:43 +0000 (UTC)
	(envelope-from mattik@gwsit.com.au)
Received: from se4.syd.hostingplatform.net.au (se4.syd.hostingplatform.net.au [IPv6:2400:b800:4::52])
	(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 4L7Y786tcHz3qCL;
	Wed, 25 May 2022 14:17:40 +0000 (UTC)
	(envelope-from mattik@gwsit.com.au)
Received: from s02ad.syd2.hostingplatform.net.au ([103.27.32.38])
	by se4.syd.hostingplatform.net.au with esmtps (TLSv1.2:AES128-GCM-SHA256:128)
	(Exim 4.92)
	(envelope-from )
	id 1ntrp7-0004vt-QE; Thu, 26 May 2022 00:17:27 +1000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=gwsit.com.au; s=default; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender
	:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:
	Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:
	List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=p6Yw4u14fkmRSGl2OxY5Q86rIN9w+aKEW4bV4aGKDs4=; b=THvebqphkW3bevCb/mF5MFOg8S
	LM6Hq6F7fRRLadFAFmqKpZYHXbUvca+pUUWCJ+/A95JRu2vmY2TGygA/rc3BM8V/9jOu2cLHv1lts
	1ONpJ3qVHyo6PoYVypQ3gLRQRt8ZAoNI7po+alpBT3bylgRQHEAcwDnQLDTrYxPgxJDkVkkUdGr3C
	OdXaglw2lcT2/uCvTxiALl2tbJtjGnp0U22m7ferBLnGFg0rLuvQBvLIMn/OAiWTzgzg3YeIPikFd
	8hYhXMBU/+4FTVGB7QWsFyZVuhDtvjKsqesweiIjZOBqpVAgHPJfeg29WG6jb/cC2dAZMfYwcy9Dm
	2zFhDW2w==;
Received: from 180-150-31-87.b4961f.syd.static.aussiebb.net ([180.150.31.87]:65459 helo=ws1.wobblyboot.net)
	by s02ad.syd2.hostingplatform.net.au with esmtpsa  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.95)
	(envelope-from )
	id 1ntrp5-003aaz-TX;
	Thu, 26 May 2022 00:17:15 +1000
Date: Thu, 26 May 2022 00:17:15 +1000
From: matti k 
To: Alexander Motin 
Cc: Matteo Riondato , freebsd-current@freebsd.org, Jim
 Harris 
Subject: Re: nvme INVALID_FIELD in dmesg.boot
Message-ID: <20220526001715.4ffee96a@ws1.wobblyboot.net>
In-Reply-To: 
References: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
	
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - s02ad.syd2.hostingplatform.net.au
X-AntiAbuse: Original Domain - freebsd.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - gwsit.com.au
X-Get-Message-Sender-Via: s02ad.syd2.hostingplatform.net.au: authenticated_id: mattik@gwsit.com.au
X-Authenticated-Sender: s02ad.syd2.hostingplatform.net.au: mattik@gwsit.com.au
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Originating-IP: 103.27.32.38
X-SpamExperts-Domain: out-2.hostyourservices.net
X-SpamExperts-Username: 103.27.32.38
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ
 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x5gMyVinKuvnFxletoVJLScufRc/bwSLYvMEjTVgTqjsk+
 GvLznYtE3mvn5foh3HMTf/WiynJlK9xi5RktnVCMXm8l1fjy9m4uoDkHz+uZxkM123dNmjj9Xk/D
 oSm+npUYRKuVemGM4r2gbaSgcgS2WEN3NCBtCPrZwBXPIIYGbbQauorde96+jiFOqzBKo/JyDFEC
 R6DQvbeKezE2O5+g7jwKR0XFJHZ7YcbuH2uF9lhHe/ad6YoSe+/PctnxdX2oTijKVH6dW2gzI9YY
 qwIB8U54yHbe0U2Q73dIPYtLRWL18m90UK915zhQ3nGecqA0pBShsjuG4FWhl4kkoP5Ysi+5m7mm
 EWZZyR13gEslHyBqflY7HU0pbqzl3Wk1+b7OTcDLqbQSaN7y+jeAyQ/FfmlybO2t27Vlfxuh17XF
 ygEawskmC6nd/kpvbGXYaUGFtHAspirvr09NOD8SRR7oQTglYHOqhKyk9UK+PbRzMq6eJjazk+Qv
 52DA2lmFChTzGOBdlUi43AF+cJAY7kbRqq98AcBHl+gIueRT0ac4W7ZjLdEhS9gDm7pEQePtlf6i
 FuRgzMKn5yr0QiZanpmbIK/1NH5THMtlYvyHAYGOGvzjsGo8W6ownn+kprqMLP6xNi1VgTxfSMxe
 s4OGRCnw9DDDYNaW/zt60NI6QunrGSLMmGsWGQp99Dtng8VILT5aw6fJdkGVoKDC1jQ0XQReqYYB
 pu7LaaTIrPQqmJlr2980n95DI6eCalLXl9IiAiBysi/rrsEvQSkmXSBJ/V0W82cKxZFAhCYB6hPz
 A4TbjAE+R6KbYZdvwy3kNOAZWNvVkE9s01KRXGLleFW27GczWcO+1XTTYsHq/pVP4wxS4DxTqk34
 eZ/5qp8PmC1pGhVKvUqPAt4+POLHYyNocd5OctgzcDoFd+96Xw4QUNtTnVx/JD4hYOlykPNnJlRn
 b1UOWKWmImeKyhNb2TZsoUklVUanxVObDJn7JWiYO5x7b3We68XEKbaF8O17PEdfgmgN6jzr9Gra
 ws9NUvjUCFbwh2lMMB1MaqU1VQTkVxFz7dmof2kM5+Q84ff0YlyxD0EkKZwWSlyieMNP++l8AoPT
 nZ9KpkPhTOGAcqH42ivgv863yxTRnmoPIgfyhuMiIxBbElLU6JUHz57QwdFyzl7l
X-Report-Abuse-To: spam@se.syd.hostingplatform.net.au
X-Rspamd-Queue-Id: 4L7Y786tcHz3qCL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gwsit.com.au header.s=default header.b=THvebqph;
	dmarc=pass (policy=none) header.from=gwsit.com.au;
	spf=pass (mx1.freebsd.org: domain of mattik@gwsit.com.au designates 2400:b800:4::52 as permitted sender) smtp.mailfrom=mattik@gwsit.com.au
X-Spamd-Result: default: False [-3.97 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gwsit.com.au:s=default];
	 HAS_XOIP(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 HAS_X_SOURCE(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 R_SPF_ALLOW(-0.20)[+a];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[gwsit.com.au:+];
	 DMARC_POLICY_ALLOW(-0.50)[gwsit.com.au,none];
	 NEURAL_HAM_SHORT(-0.97)[-0.970];
	 HAS_X_GMSV(0.00)[mattik@gwsit.com.au];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 HAS_X_ANTIABUSE(0.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:45638, ipnet:2400:b800:4::/48, country:AU];
	 RCVD_TLS_ALL(0.00)[];
	 HAS_X_AS(0.00)[mattik@gwsit.com.au]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, 25 May 2022 09:58:54 -0400
Alexander Motin  wrote:

> On 25.05.2022 08:25, Matteo Riondato wrote:
> > My dmesg.boot contains the following entries containing
> > "INVALID_FIELD" about nvme (I use nda(4) for my nvme disks, with
> > hw.nvme.use_nvd=0 in loader.conf):
> > 
> > trismegistus ~ % grep -e 'nvme[0-9]\?' /var/run/dmesg.boot
> > nvme0:  mem 0xb8610000-0xb8613fff irq 40 at device
> > 0.0 numa-domain 0 on pci7
> > nvme1:  mem 0xb8510000-0xb8513fff irq 47 at device
> > 0.0 numa-domain 0 on pci8
> > nvme2:  mem 0xc5e10000-0xc5e13fff irq 48 at device
> > 0.0 numa-domain 0 on pci10
> > nvme3:  mem 0xc5d10000-0xc5d13fff irq 55 at device
> > 0.0 numa-domain 0 on pci11
> > nvme0: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
> > cdw11:0000031f nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> > nvme1: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
> > cdw11:0000031f nvme1: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> > nvme2: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
> > cdw11:0000031f nvme2: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> > nvme3: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
> > cdw11:0000031f nvme3: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> > nda0 at nvme0 bus 0 scbus16 target 0 lun 1
> > nda0: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> > nda1 at nvme1 bus 0 scbus17 target 0 lun 1
> > nda1: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> > nda2 at nvme2 bus 0 scbus18 target 0 lun 1
> > nda2: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> > nda3 at nvme3 bus 0 scbus19 target 0 lun 1
> > nda3: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> > 
> > The disks seem to work fine, from what I can tell.
> > 
> > Are the "INVALID_FIELD" messages harmless, or can they be avoided
> > with some tuning, or maybe with some patch?
> 
> Those messages mean that driver tried to enable certain types of 
> asynchronous events, but probably the hardware does not support some
> of those.  If you wish to experiment we could try to mask some of the
> bits in nvme_ctrlr_configure_aer() function to find out which one
> exactly, but for discontinued drives 4-5 years old it might not have
> too much sense.  It should not be critical unless you either overheat
> them, or somehow else they fail and wish to report it.
> 

I am intrigued to how you guru's know this, is it  because you know
the code well enough?



From nobody Wed May 25 14:32:05 2022
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 F29CA1B5439C
	for ; Wed, 25 May 2022 14:32:08 +0000 (UTC)
	(envelope-from rionda@gmail.com)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L7YRr0n6dz3stt;
	Wed, 25 May 2022 14:32:08 +0000 (UTC)
	(envelope-from rionda@gmail.com)
Received: by mail-qk1-x72c.google.com with SMTP id t2so13315118qkb.12;
        Wed, 25 May 2022 07:32:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to
         :references;
        bh=SsSEfG+VMHHWJTzshKUU1M/o+4a+LOdM3TFVPwa7+Hc=;
        b=kvRb0UZC2+hygLJXWtsG80PO2m4rSxZ2exIfEyypqqNHTRVIXvKCiobhyzxPxMeXbg
         1+0zMvHcuQV9JHI+Y3NEvxLyKnYP+ee2V+hg5+YOxlKwIk6lMFtVCDiHviswrnmG742O
         IMlaGoYWBom0Vu4YtafkS4kwNMuHBLuLeovOq7UHyBY5r8WoD4c5mKzrB2uVlo8c8WCH
         l1TJoByEUp1rZazfHnLuDLTuqwsG81Jjp4jJD1wMjh6DrwW8kuzev4KxysToFz+2lKo8
         GEq20iKfQ9fKAC5pbm3psZJEDv9eyfNvYdp7t5NSutBgqaMqSiXOqdg1rTObmkizqBoZ
         KjRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:from:message-id:mime-version:subject:date
         :in-reply-to:cc:to:references;
        bh=SsSEfG+VMHHWJTzshKUU1M/o+4a+LOdM3TFVPwa7+Hc=;
        b=5fQEXzdhWeULhuyMTP3YOAI+QNMLEFqOLh/usnJmyjqtQ5YbV2lDd0An5feqGyyE0a
         eXxiBqIWxFk7duEeA3YSN8ekQMmeIkQ3nBYg3PFQoXauxeB6+JJdXR3sECoyNmYhONMm
         m66OfncHgGSobcozJnuAht00nrI9TbpA10S3DMz8OVponUAXX1+6BJ2Tbf7ikdoSLa0K
         qo3MxzLDgXmlG5QCZuvpJihKBi7yqCxHHl2N81bIjirVg6qBXFndqHkoNlFhfkcGIHMO
         5Uk2Sn3IjkxZprVisF6RVseVO+X3j9YVi7irdENnfASHwZjLEuV0SNJmlnPaIU2rBJiJ
         WMPQ==
X-Gm-Message-State: AOAM532TKAWUJbF4l352zGqJIKXGGMKIHApNt55wnbWM8u0Q5i8eC5Pf
	qBP/F/X4k0FxFWLZGbBxw2UXLds0BkU=
X-Google-Smtp-Source: ABdhPJyYtQ09avrRdDWh5fbNZiEkac5oqNIbFfiVHh2vCQ+Qm4WpJGFjCaBNqibHbrvX9F0janLyKw==
X-Received: by 2002:a37:bf06:0:b0:6a3:4100:8456 with SMTP id p6-20020a37bf06000000b006a341008456mr18718991qkf.423.1653489127137;
        Wed, 25 May 2022 07:32:07 -0700 (PDT)
Received: from smtpclient.apple ([2601:19b:4400:1779::107b])
        by smtp.gmail.com with ESMTPSA id v4-20020ac873c4000000b002f906fc8530sm1362191qtp.46.2022.05.25.07.32.06
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 25 May 2022 07:32:06 -0700 (PDT)
From: Matteo Riondato 
Message-Id: <892F7305-97D6-4D78-B1E7-3BEC3809DD75@FreeBSD.org>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_BE11DF7B-1C71-4899-8149-2E281E0E4131"
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: nvme INVALID_FIELD in dmesg.boot
Date: Wed, 25 May 2022 10:32:05 -0400
In-Reply-To: 
Cc: freebsd-current@freebsd.org,
 Jim Harris 
To: Alexander Motin 
References: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
 
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4L7YRr0n6dz3stt
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=kvRb0UZC;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of rionda@gmail.com designates 2607:f8b0:4864:20::72c as permitted sender) smtp.mailfrom=rionda@gmail.com
X-Spamd-Result: default: False [-0.90 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 MV_CASE(0.50)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 FORGED_SENDER(0.30)[matteo@FreeBSD.org,rionda@gmail.com];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_NEQ_ENVFROM(0.00)[matteo@FreeBSD.org,rionda@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 DMARC_NA(0.00)[FreeBSD.org];
	 NEURAL_SPAM_SHORT(0.80)[0.797];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72c:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_BE11DF7B-1C71-4899-8149-2E281E0E4131
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On May 25, 2022, at 9:58 AM, Alexander Motin  wrote:
>=20
> On 25.05.2022 08:25, Matteo Riondato wrote:
>> My dmesg.boot contains the following entries containing =
"INVALID_FIELD" about nvme (I use nda(4) for my nvme disks, with =
hw.nvme.use_nvd=3D0 in loader.conf):
>> trismegistus ~ % grep -e 'nvme[0-9]\?' /var/run/dmesg.boot
>> nvme0:  mem 0xb8610000-0xb8613fff irq 40 at device =
0.0 numa-domain 0 on pci7
>> nvme1:  mem 0xb8510000-0xb8513fff irq 47 at device =
0.0 numa-domain 0 on pci8
>> nvme2:  mem 0xc5e10000-0xc5e13fff irq 48 at device =
0.0 numa-domain 0 on pci10
>> nvme3:  mem 0xc5d10000-0xc5d13fff irq 55 at device =
0.0 numa-domain 0 on pci11
>> nvme0: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b =
cdw11:0000031f
>> nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> nvme1: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b =
cdw11:0000031f
>> nvme1: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> nvme2: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b =
cdw11:0000031f
>> nvme2: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> nvme3: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b =
cdw11:0000031f
>> nvme3: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> nda0 at nvme0 bus 0 scbus16 target 0 lun 1
>> nda0: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> nda1 at nvme1 bus 0 scbus17 target 0 lun 1
>> nda1: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> nda2 at nvme2 bus 0 scbus18 target 0 lun 1
>> nda2: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> nda3 at nvme3 bus 0 scbus19 target 0 lun 1
>> nda3: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> The disks seem to work fine, from what I can tell.
>> Are the "INVALID_FIELD" messages harmless, or can they be avoided =
with some tuning, or maybe with some patch?
>=20
> Those messages mean that driver tried to enable certain types of =
asynchronous events, but probably the hardware does not support some of =
those.  If you wish to experiment we could try to mask some of the bits =
in nvme_ctrlr_configure_aer() function to find out which one exactly, =
but for discontinued drives 4-5 years old it might not have too much =
sense.  It should not be critical unless you either overheat them, or =
somehow else they fail and wish to report it.

Thank you, Alexander.

One question though: the messages report that the driver tried to set =
(?) cdw10 and cdw11, but the INVALID_FIELD is about cdw0 (sorry, I have =
no idea what these =E2=80=9Ccwd=E2=80=9D mean).  Is that expected? =
Unrelated?

(The disks are Intel DC P4510, I don=E2=80=99t know how long they=E2=80=99=
ve been around)

Thanks,
Matteo


--Apple-Mail=_BE11DF7B-1C71-4899-8149-2E281E0E4131
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On May 25, 2022, at 9:58 AM, Alexander Motin <mav@FreeBSD.org> =
wrote:

On 25.05.2022 08:25, Matteo Riondato wrote:
My dmesg.boot contains =
the following entries containing "INVALID_FIELD" about nvme (I use =
nda(4) for my nvme disks, with hw.nvme.use_nvd=3D0 in loader.conf):
trismegistus ~ % grep -e 'nvme[0-9]\?' /var/run/dmesg.boot
nvme0: <Intel DC PC4500> mem 0xb8610000-0xb8613fff irq =
40 at device 0.0 numa-domain 0 on pci7
nvme1: <Intel DC =
PC4500> mem 0xb8510000-0xb8513fff irq 47 at device 0.0 numa-domain 0 =
on pci8
nvme2: <Intel DC PC4500> mem =
0xc5e10000-0xc5e13fff irq 48 at device 0.0 numa-domain 0 on pci10
nvme3: <Intel DC PC4500> mem 0xc5d10000-0xc5d13fff irq =
55 at device 0.0 numa-domain 0 on pci11
nvme0: SET =
FEATURES (09) sqid:0 cid:15 nsid:0 =
cdw10:0000000b cdw11:0000031f
nvme0: INVALID_FIELD (00/02) =
sqid:0 cid:15 cdw0:0
nvme1: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b cdw11:0000031f
nvme1: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nvme2: SET FEATURES (09) =
sqid:0 cid:15 nsid:0 cdw10:0000000b =
cdw11:0000031f
nvme2: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nvme3: SET =
FEATURES (09) sqid:0 cid:15 nsid:0 =
cdw10:0000000b cdw11:0000031f
nvme3: INVALID_FIELD (00/02) =
sqid:0 cid:15 cdw0:0
nda0 =
at nvme0 bus 0 scbus16 target 0 lun 1
nda0: nvme version =
1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
nda1 at =
nvme1 bus 0 scbus17 target 0 lun 1
nda1: nvme version 1.2 =
x4 (max x4) lanes PCIe Gen3 (max Gen3) link
nda2 at nvme2 =
bus 0 scbus18 target 0 lun 1
nda2: nvme version 1.2 x4 =
(max x4) lanes PCIe Gen3 (max Gen3) link
nda3 at nvme3 bus =
0 scbus19 target 0 lun 1
nda3: nvme version 1.2 x4 (max =
x4) lanes PCIe Gen3 (max Gen3) link
The disks seem to work =
fine, from what I can tell.
Are the "INVALID_FIELD" =
messages harmless, or can they be avoided with some tuning, or maybe =
with some patch?

Those =
messages mean that driver tried to enable certain types of asynchronous =
events, but probably the hardware does not support some of those. =
 If you wish to experiment we could try to mask some of the bits in =
nvme_ctrlr_configure_aer() function to find out which one exactly, but =
for discontinued drives 4-5 years old it might not have too much sense. =
 It should not be critical unless you either overheat them, or =
somehow else they fail and wish to report it.

Thank you, =
Alexander.

One question though: the =
messages report that the driver tried to set (?) cdw10 and cdw11, but =
the INVALID_FIELD is about cdw0 (sorry, I have no idea what these =
=E2=80=9Ccwd=E2=80=9D mean).  Is that expected? =
Unrelated?

(The =
disks are Intel DC P4510, I don=E2=80=99t know how long they=E2=80=99ve =
been around)



Thanks,
Matteo




=

--Apple-Mail=_BE11DF7B-1C71-4899-8149-2E281E0E4131--

From nobody Wed May 25 15:29:26 2022
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 8E1FB1B40ECE
	for ; Wed, 25 May 2022 15:29:39 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L7ZkB34m1z4WvZ
	for ; Wed, 25 May 2022 15:29:38 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe36.google.com with SMTP id w10so19261363vsa.4
        for ; Wed, 25 May 2022 08:29:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=fzm1qKK3/3Z4nRwGmbK8hKNJY5SvrLnpD6aiuUdcpkQ=;
        b=oVGfiO3h0wPg67MV5Gz+sGfiCba/ukyfjKePLkeF1UhW+pEBbbS77CO4PoW98exzSw
         jroj7sjJSU49JNi/LN2CmlpPRCOYS2jwMq/tS7kAdCILqVrvoDLqwTlltyyy7tE1rZp6
         eDJS260vbybqs2wVih3FEj9S8kssclq8dXptFtChdQCoMYTb4NuvVyVeTDm/3Ki6XBmL
         akAMt9P357LY5Gk5YHSc2K+oT7GG2r34Mqv/1OeN2T6faDOXVSdfeYJGHd3Jc+HOX+MP
         9M9NDbe1vWpFTDPpPsBha6Rjx/FxQpr0fB4DTyxggp1HyfvFftsRzoif01U8Qw+5iqIU
         VRbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=fzm1qKK3/3Z4nRwGmbK8hKNJY5SvrLnpD6aiuUdcpkQ=;
        b=G3of7WPDtcTJ5zVkJqtEZeO3jUrkDT5TF1rg0jBoa61EK6AN8Dicy/IHHEJ9KxVvzY
         /+O+BGKMeP4o/mbZ7+QB8WbEXwSRwOfGJXGPKFiZtoF1N1p07PVSrtzFEVTFUDBMjULN
         s59pVr29uJZ021D/+VJD4MsgMZPH7vtoo5X44yyCXmVk010kbReZUiND0bMMnipK9yOf
         thPa5k9LOq3myH4MK+iMm6kIIrXSz9efX/M+/rr35XGPlrG+fCWFJx1BzEWHjWBIUL+m
         vzZCfiwrbfAAU9MJAHhb7h4urMQxENa1QNIMycVv35lpEjLkQJzxvvtLMNIr9EPdRUel
         7s3A==
X-Gm-Message-State: AOAM5334Rv/ZANNAI1YT2KsqntxSlgH0TTgG0QmzMhuU5LKMeP1Qm85p
	KRTuuCMSqRKMzK+79jr69FpJbNmR0GBSHm37ldRE1FZcLeK5Jg==
X-Google-Smtp-Source: ABdhPJyeE06glXKJ4e+drsmSpaJMzJrVPgcy8nqjuPagAKMnALe+0nA7pnqgO1abMqhIqNzwfbvFWHQwGVAj1Kum5Ec=
X-Received: by 2002:a67:f8ce:0:b0:335:d520:ab7f with SMTP id
 c14-20020a67f8ce000000b00335d520ab7fmr13137942vsp.51.1653492577745; Wed, 25
 May 2022 08:29:37 -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: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
  <20220526001715.4ffee96a@ws1.wobblyboot.net>
In-Reply-To: <20220526001715.4ffee96a@ws1.wobblyboot.net>
From: Warner Losh 
Date: Wed, 25 May 2022 09:29:26 -0600
Message-ID: 
Subject: Re: nvme INVALID_FIELD in dmesg.boot
To: matti k 
Cc: Alexander Motin , Matteo Riondato , 
	FreeBSD Current , Jim Harris 
Content-Type: multipart/alternative; boundary="000000000000bc532305dfd7bd2c"
X-Rspamd-Queue-Id: 4L7ZkB34m1z4WvZ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=oVGfiO3h;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e36) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.96 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-0.96)[-0.956];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e36:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000bc532305dfd7bd2c
Content-Type: text/plain; charset="UTF-8"

On Wed, May 25, 2022 at 8:18 AM matti k  wrote:

> On Wed, 25 May 2022 09:58:54 -0400
> Alexander Motin  wrote:
>
> > On 25.05.2022 08:25, Matteo Riondato wrote:
> > > My dmesg.boot contains the following entries containing
> > > "INVALID_FIELD" about nvme (I use nda(4) for my nvme disks, with
> > > hw.nvme.use_nvd=0 in loader.conf):
> > >
> > > trismegistus ~ % grep -e 'nvme[0-9]\?' /var/run/dmesg.boot
> > > nvme0:  mem 0xb8610000-0xb8613fff irq 40 at device
> > > 0.0 numa-domain 0 on pci7
> > > nvme1:  mem 0xb8510000-0xb8513fff irq 47 at device
> > > 0.0 numa-domain 0 on pci8
> > > nvme2:  mem 0xc5e10000-0xc5e13fff irq 48 at device
> > > 0.0 numa-domain 0 on pci10
> > > nvme3:  mem 0xc5d10000-0xc5d13fff irq 55 at device
> > > 0.0 numa-domain 0 on pci11
> > > nvme0: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
> > > cdw11:0000031f nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> > > nvme1: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
> > > cdw11:0000031f nvme1: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> > > nvme2: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
> > > cdw11:0000031f nvme2: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> > > nvme3: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
> > > cdw11:0000031f nvme3: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
> > > nda0 at nvme0 bus 0 scbus16 target 0 lun 1
> > > nda0: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> > > nda1 at nvme1 bus 0 scbus17 target 0 lun 1
> > > nda1: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> > > nda2 at nvme2 bus 0 scbus18 target 0 lun 1
> > > nda2: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> > > nda3 at nvme3 bus 0 scbus19 target 0 lun 1
> > > nda3: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
> > >
> > > The disks seem to work fine, from what I can tell.
> > >
> > > Are the "INVALID_FIELD" messages harmless, or can they be avoided
> > > with some tuning, or maybe with some patch?
> >
> > Those messages mean that driver tried to enable certain types of
> > asynchronous events, but probably the hardware does not support some
> > of those.  If you wish to experiment we could try to mask some of the
> > bits in nvme_ctrlr_configure_aer() function to find out which one
> > exactly, but for discontinued drives 4-5 years old it might not have
> > too much sense.  It should not be critical unless you either overheat
> > them, or somehow else they fail and wish to report it.
> >
>
> I am intrigued to how you guru's know this, is it  because you know
> the code well enough?
>

SET FEATURES (opcode 9) feature 0xb is indeed async event configuration.
0x31f is:
SMART WARNING for available spares (0x1)
SMART warning for temperature (0x2)
SMART WARNING for device reliability (0x4)
SMART WARNING for being read only (0x8)
SMART WARNING for volatile memory backup (0x10)
Namespace attribute change events (0x100)
Firmware activation events (0x200)

I wonder which one of those it doesn't like. My reading of the standard
suggests that those
should always be supported for a 1.2 and later drive... Thought maybe with
the possible
exception of the volatile memory backup, so let me do some digging here...

We can get the last two items from OAES field of the controller
identificaiton data. This is bytes 95:92,
which if I'm counting right is the last word on the 040: line in the
nvmecontrol identify -x nvmeX command:

040: 4e474e4b 30303150 000cca07 00230000 00010200 005b8d80 0030d400 00000100
----------------------------------------------------------------------------------------------------------^^^^^^^^^

It looks like we don't currently test these bits before we add the last two
(we do it unconditionally
for >= 1.2, and maybe we should check these bits >= 1.2).

Would you be able to test a fix for this?

Warner

--000000000000bc532305dfd7bd2c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, May 25, 2022 at 8:18 AM matti=
 k <mattik@gwsit.com.au> w=
rote:
On Wed, 25=
 May 2022 09:58:54 -0400

Alexander Motin <mav@FreeBSD.org> wrote:



> On 25.05.2022 08:25, Matteo Riondato wrote:

> > My dmesg.boot contains the following entries containing

> > "INVALID_FIELD" about nvme (I use nda(4) for my nvme di=
sks, with

> > hw.nvme.use_nvd=3D0 in loader.conf):

> > 

> > trismegistus ~ % grep -e 'nvme[0-9]\?' /var/run/dmesg.boo=
t

> > nvme0: <Intel DC PC4500> mem 0xb8610000-0xb8613fff irq 40 a=
t device

> > 0.0 numa-domain 0 on pci7

> > nvme1: <Intel DC PC4500> mem 0xb8510000-0xb8513fff irq 47 a=
t device

> > 0.0 numa-domain 0 on pci8

> > nvme2: <Intel DC PC4500> mem 0xc5e10000-0xc5e13fff irq 48 a=
t device

> > 0.0 numa-domain 0 on pci10

> > nvme3: <Intel DC PC4500> mem 0xc5d10000-0xc5d13fff irq 55 a=
t device

> > 0.0 numa-domain 0 on pci11

> > nvme0: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b

> > cdw11:0000031f nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0<=
br>
> > nvme1: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b

> > cdw11:0000031f nvme1: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0<=
br>
> > nvme2: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b

> > cdw11:0000031f nvme2: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0<=
br>
> > nvme3: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b

> > cdw11:0000031f nvme3: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0<=
br>
> > nda0 at nvme0 bus 0 scbus16 target 0 lun 1

> > nda0: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) lin=
k

> > nda1 at nvme1 bus 0 scbus17 target 0 lun 1

> > nda1: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) lin=
k

> > nda2 at nvme2 bus 0 scbus18 target 0 lun 1

> > nda2: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) lin=
k

> > nda3 at nvme3 bus 0 scbus19 target 0 lun 1

> > nda3: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) lin=
k

> > 

> > The disks seem to work fine, from what I can tell.

> > 

> > Are the "INVALID_FIELD" messages harmless, or can they =
be avoided

> > with some tuning, or maybe with some patch?

> 

> Those messages mean that driver tried to enable certain types of 

> asynchronous events, but probably the hardware does not support some
> of those.=C2=A0 If you wish to experiment we could try to mask some of=
 the

> bits in nvme_ctrlr_configure_aer() function to find out which one

> exactly, but for discontinued drives 4-5 years old it might not have
> too much sense.=C2=A0 It should not be critical unless you either over=
heat

> them, or somehow else they fail and wish to report it.

> 



I am intrigued to how you guru's know this, is it=C2=A0 because you kno=
w

the code well enough?

SET FEATURES (opc=
ode 9) feature 0xb is indeed async event configuration.
0x31f is:=

SMART WARNING for available spares (0x1)
SMART war=
ning for temperature (0x2)
SMART WARNING for device reliability (=
0x4)
SMART WARNING for being read only (0x8)
SMART WARN=
ING for volatile memory backup (0x10)
Namespace attribute change =
events (0x100)
Firmware activation events (0x200)

<=
/div>
I wonder which one of those it doesn't like. My reading of th=
e standard suggests that those
should always be supported for a 1=
.2 and later drive... Thought maybe with the possible
exception o=
f the volatile memory backup, so let me do some digging here...
<=
br>
We can get the last two items from OAES field of the controll=
er identificaiton data. This is bytes 95:92,
which if I'm cou=
nting right is the last word on the 040: line in the nvmecontrol identify -=
x nvmeX command:

040: 4e474e4b 30303150 000cca07 0=
0230000 00010200 005b8d80 0030d400 00000100
-----------------=
---------------------------------------------------------------------------=
--------------^^^^^^^^^

It looks like we don't=
 currently test these bits before we add the last two (we do it uncondition=
ally
for >=3D 1.2, and maybe we should check these bits >=
=3D 1.2).

Would you be able to test a fix for this=
?

Warner


--000000000000bc532305dfd7bd2c--

From nobody Wed May 25 15:39:20 2022
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 8FBF81B42E58
	for ; Wed, 25 May 2022 15:39:21 +0000 (UTC)
	(envelope-from matteo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L7ZxP3S7Zz4YqP;
	Wed, 25 May 2022 15:39:21 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1653493161;
	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=90CYH08vwNbwvExKpyGPSy5g34Bp2yXKzfvTgUaTRro=;
	b=g8ogUjpP1HQRt6Y8m7bPPu8VSUC2XzreecjffUa5OQGFcUzqwaFrIjrDuyWKTod6f4pncI
	AFpulKyclme2c2bCjmo7t1UE64JHQ2Oz3IF/376G96ps1l3kghYgQH2oyplcWqnSmzEzrU
	ePKIMe34UPmBIIosLu6FJGODgTTzbOZKDC8wIeO6Bk+V2twM2SlwIrSYwRbrswy3jtWmKz
	DkDNpSNVL/M3BoBP1JCXU5gBZ5xAfhbfvJsktxNyDTGOlpARPNT6y5pkw8SgBwEXxFt7va
	IJx2vYbiXgqbsuVfhCWhZhKYhzOWD2j85+sZOZ2RBofC3k/t0Clxk4+EsXp8kA==
Received: from ubertino.local (unknown [IPv6:2601:19b:4400:1779::107b])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: matteo/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 072CBDF99;
	Wed, 25 May 2022 15:39:20 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Date: Wed, 25 May 2022 11:39:20 -0400
From: Matteo Riondato 
To: Warner Losh 
Cc: matti k , Alexander Motin ,
	FreeBSD Current ,
	Jim Harris 
Subject: Re: nvme INVALID_FIELD in dmesg.boot
Message-ID: <20220525153920.sxzi7fhsfzv6yidv@ubertino.local>
X-PGP-Key: http://rionda.to/files/matteogpg.asc
References: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
 
 <20220526001715.4ffee96a@ws1.wobblyboot.net>
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="65nvyd67luamsejh"
Content-Disposition: inline
In-Reply-To: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1653493161;
	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=90CYH08vwNbwvExKpyGPSy5g34Bp2yXKzfvTgUaTRro=;
	b=gwYjzslrqNL/tMwS9B4zJJzfRo1qTk2GoMNfcoXHfUnDjWxKvv6iQtJOKgyxapWaOFePgo
	wIRqBDs1+W6W5CdaWLXt9q0x2yxKF19/1egE7WIs3WRo3wcZ94l/lGtLJY3j+e0zjPmXrE
	0UC/CUWWlst6lOEf65cfZi4inn82EZG7TwKTN/ztE7CRG2ij2Sn0M7O2W+nUUmniVJBuTu
	m2r752MorIb09rfXVETVMAqdkK2cUa7PMAAOD2K6F4HqrDVArL7Krj9cV6HJb+GxifdRz0
	tHjObYiWartRcH6zf7RInc8fI/HGlofNJ0hZ1vat9CclOeBG/JqJ4oEnTueO6w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653493161; a=rsa-sha256; cv=none;
	b=lHPUAo7KKqewQlYlLnsO/MMwtEWBNIL7l+2NKqiR2SUHcXA3aycZ0AfAjpk2tSe3mE6RMO
	mVjMk6L/OhEacALv3Ob9I83Mqj9Yx/PAoWp72tJjIy0f/5VDCOcGRxjMvvgzhM+1cBSxOQ
	pa5A1nSR1uGImqjNymop8TZwZwl9CFT7X0h3KOiYpd9rLMoYvHLAhYjmMSdjZhctKdnD80
	/NXbVuDvQ6cesIC0PHFLknL7P12FcAO/BAd5RwFqskbDMPgXFUsLttS5fqcdaFqJV3Fig6
	GMzU11FqV4rhnVCMBs5M8KGQ5JBjDX76/ZItR3K/wj9KLckcbdqAm9UR/85i2A==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--65nvyd67luamsejh
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-05-25 at 11:29 EDT, Warner Losh  wrote:
>
>SET FEATURES (opcode 9) feature 0xb is indeed async event=20
>configuration.
>0x31f is:
>SMART WARNING for available spares (0x1)
>SMART warning for temperature (0x2)
>SMART WARNING for device reliability (0x4)
>SMART WARNING for being read only (0x8)
>SMART WARNING for volatile memory backup (0x10)
>Namespace attribute change events (0x100)
>Firmware activation events (0x200)
>
>I wonder which one of those it doesn't like. My reading of the standard=20
>suggests that those should always be supported for a 1.2 and later=20
>drive... Thought maybe with the possible exception of the volatile=20
>memory backup, so let me do some digging here...
>
>We can get the last two items from OAES field of the controller=20
>identificaiton data. This is bytes 95:92, which if I'm counting right=20
>is the last word on the 040: line in the nvmecontrol identify -x nvmeX=20
>command:
>
>040: 4e474e4b 30303150 000cca07 00230000 00010200 005b8d80 0030d400=20
>00000100
>--------------------------------------------------------------------------=
--------------------------------^^^^^^^^^

On my system:

040: 31564456 30373130 5cd2e400 00000500 00010200 001e8480 002dc6c0=20
00000200

(same for all nvmeX, as far as I can tell)

>It looks like we don't currently test these bits before we add the last=20
>two (we do it unconditionally for >=3D 1.2, and maybe we should check=20
>these bits >=3D 1.2).
>
>Would you be able to test a fix for this?

Yes, I would be happy to, but I cannot do it for a couple of weeks=20
(running simulations for a deadline).

Thanks,
Matteo

--65nvyd67luamsejh
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmKOTacTGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVAQrmEADq3C7OD4UXRghoDttG3XOiFuRY2zY7
y6w6zZpAdlVw3wadHyW0yZ+UR5KdnnoSUnM99vDy8dxsPQ/xyuSb/sK6INENlX6t
2xFyP8OL4MQxdp0c17Pc9+MpU//nderecivMr4oB5HznipRuGl430SKTkk7/kIWw
0lSGUkfYDu+FLKg8TJNyJ9LCm3lCGA2tESOI4DJ9IDhSvQwnWskJJb0hOwB2TxiR
FjpYpIn2erLfauCidNIJSz1ieNYjl9iSCdzIjZm4WZ97xM3kJ27fouIATz6b8g+3
p+aW6srN3GBKr7uh9W5igH+4MSa9bYl6N0/tqA8tODOyq7yai/MIlAG7ZOpG42zr
EDJq5EbUY4yiL7KXrcbECir6uaYQmk5JBh626LcN1zWHBbrVWE/+va2s/xxuqBQg
2f7BFkhjH3TafHlBq+cTO8s8iGGXSjj7QVBQFXutkkye0t+LiFvdZH/IOfJaK2N/
l9JwA0rR/a6e6evAgM6vwAmfSmxLS7FcaujEfm7uMKCX5eAhWRA9tmNt698Rw+vd
h53ZRPu9JBq0RB5UUzZiEecZX9OguvoWE4iTNPNw8OaiJJzjoaebY234ug+IDVeJ
zqfT10DWxzrOsjQwYWBY1xdDKurAkXktuB3YTYUNUlC0bP+D7Tgsq3V+c9/t0S9c
FT8x/l4n9fxp+A==
=Y3uD
-----END PGP SIGNATURE-----

--65nvyd67luamsejh--

From nobody Wed May 25 15:43:11 2022
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 9CE3D1B44BF4
	for ; Wed, 25 May 2022 15:43:29 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L7b283Yh2z4brP
	for ; Wed, 25 May 2022 15:43:28 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vk1-xa32.google.com with SMTP id bs5so10080749vkb.4
        for ; Wed, 25 May 2022 08:43:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=O8ovHhiikfTGACHr0z6AM4rU+9ZU3h67oUrzqoWjH5Q=;
        b=uuKCZOjA7cogrRG+vMIE5c9MKFYRH4pJfi9Y6/dOPnlLxBOQenZkLdUT+tVpMG8JKX
         PNiDGel1rSpsYhFdB1CyOXfWK6a/fCioMJufZ64piWtvcNQlpokrZXYfyR7/JfgHYa5z
         GlGNAexfNprw8/4qGr3bKv6nihw0QgpTZw0Lnm+K4Luh6vLxz64moeBEgeRHhmISEGsl
         Xc6S1g1Qc3/ZWQSX8hG/ol+zK2su0nvBYvAi5XLrNOgiAU65KOIrfHjTCdNom+UuzwnQ
         RepMP+AfMqhACE5zCREyQAyFXDaC2CbDmf/i88tZnHLlE//YwGHmvALuNRh3qRT5x2LG
         AxSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=O8ovHhiikfTGACHr0z6AM4rU+9ZU3h67oUrzqoWjH5Q=;
        b=n/q3yqFGQPPZAmrbh4Ox5NK/MmlbgWlrWrHGRWL1RUZF3VsHOv5iLsYBeqJP9dMhDD
         2aZSmxBdhKBFYwKIUTgewaCSE3vTJ5ntYc3yVKafDtyogvtvw2NDnFYf32//+VAqRixV
         nOhzUfHSGplAlrWLlf7i/Kwn5L7e7ubwgWim+kapA7UI7CxNw9jN3Poef8DxKHnqrcL2
         2rnv060m6FWcciYmzGvp2gp07P+FtMmeeciuOTewOtuG9Wjc+v7NFMbMGvSycw1Y5GRH
         BurWe8BkGwPUO9p7xTZyiodiNo8yBUkXMFN2iIJGdGAuWQyjLZFqnlJr4bH9AdZO1/BJ
         vxbQ==
X-Gm-Message-State: AOAM532oEEiCujUJoC0Z0s7PhelJzx54snJl9Y0shFy2oU1JPZj40+Pf
	zWHrCX9ngMBaKWHMlXLqz/72AMd9xDTQygIMPGK2dQ==
X-Google-Smtp-Source: ABdhPJwXgVQ4B04f5+GtkN3FFEYuT9MmV8so0y6HSz/YUzuBZjWshKNJ1XCdjeF8VFDW4FCyo9/CrFB/hBZX1lje42Y=
X-Received: by 2002:a05:6122:2229:b0:32d:1642:b58b with SMTP id
 bb41-20020a056122222900b0032d1642b58bmr11940935vkb.27.1653493402414; Wed, 25
 May 2022 08:43:22 -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: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
  <20220526001715.4ffee96a@ws1.wobblyboot.net>
 
In-Reply-To: 
From: Warner Losh 
Date: Wed, 25 May 2022 09:43:11 -0600
Message-ID: 
Subject: Re: nvme INVALID_FIELD in dmesg.boot
To: matti k 
Cc: Alexander Motin , Matteo Riondato , 
	FreeBSD Current , Jim Harris 
Content-Type: multipart/alternative; boundary="000000000000e3c1a105dfd7ee8b"
X-Rspamd-Queue-Id: 4L7b283Yh2z4brP
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=uuKCZOjA;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a32) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a32:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e3c1a105dfd7ee8b
Content-Type: text/plain; charset="UTF-8"

Here's a patch that might fix it

diff --git a/sys/dev/nvme/nvme_ctrlr.c b/sys/dev/nvme/nvme_ctrlr.c
index 2c5d521ecaa1..72c511de3be8 100644
--- a/sys/dev/nvme/nvme_ctrlr.c
+++ b/sys/dev/nvme/nvme_ctrlr.c
@@ -854,8 +854,9 @@ nvme_ctrlr_configure_aer(struct nvme_controller *ctrlr)
            NVME_CRIT_WARN_ST_READ_ONLY |
            NVME_CRIT_WARN_ST_VOLATILE_MEMORY_BACKUP;
        if (ctrlr->cdata.ver >= NVME_REV(1, 2))
-               ctrlr->async_event_config |= NVME_ASYNC_EVENT_NS_ATTRIBUTE |
-                   NVME_ASYNC_EVENT_FW_ACTIVATE;
+               ctrlr->async_event_config |=
+                   ctrlr->cdata.oaes & (NVME_ASYNC_EVENT_NS_ATTRIBUTE |
+                       NVME_ASYNC_EVENT_FW_ACTIVATE);

        status.done = 0;
        nvme_ctrlr_cmd_get_feature(ctrlr, NVME_FEAT_TEMPERATURE_THRESHOLD,

Warner

On Wed, May 25, 2022 at 9:29 AM Warner Losh  wrote:

>
>
> On Wed, May 25, 2022 at 8:18 AM matti k  wrote:
>
>> On Wed, 25 May 2022 09:58:54 -0400
>> Alexander Motin  wrote:
>>
>> > On 25.05.2022 08:25, Matteo Riondato wrote:
>> > > My dmesg.boot contains the following entries containing
>> > > "INVALID_FIELD" about nvme (I use nda(4) for my nvme disks, with
>> > > hw.nvme.use_nvd=0 in loader.conf):
>> > >
>> > > trismegistus ~ % grep -e 'nvme[0-9]\?' /var/run/dmesg.boot
>> > > nvme0:  mem 0xb8610000-0xb8613fff irq 40 at device
>> > > 0.0 numa-domain 0 on pci7
>> > > nvme1:  mem 0xb8510000-0xb8513fff irq 47 at device
>> > > 0.0 numa-domain 0 on pci8
>> > > nvme2:  mem 0xc5e10000-0xc5e13fff irq 48 at device
>> > > 0.0 numa-domain 0 on pci10
>> > > nvme3:  mem 0xc5d10000-0xc5d13fff irq 55 at device
>> > > 0.0 numa-domain 0 on pci11
>> > > nvme0: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
>> > > cdw11:0000031f nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> > > nvme1: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
>> > > cdw11:0000031f nvme1: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> > > nvme2: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
>> > > cdw11:0000031f nvme2: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> > > nvme3: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b
>> > > cdw11:0000031f nvme3: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> > > nda0 at nvme0 bus 0 scbus16 target 0 lun 1
>> > > nda0: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> > > nda1 at nvme1 bus 0 scbus17 target 0 lun 1
>> > > nda1: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> > > nda2 at nvme2 bus 0 scbus18 target 0 lun 1
>> > > nda2: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> > > nda3 at nvme3 bus 0 scbus19 target 0 lun 1
>> > > nda3: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> > >
>> > > The disks seem to work fine, from what I can tell.
>> > >
>> > > Are the "INVALID_FIELD" messages harmless, or can they be avoided
>> > > with some tuning, or maybe with some patch?
>> >
>> > Those messages mean that driver tried to enable certain types of
>> > asynchronous events, but probably the hardware does not support some
>> > of those.  If you wish to experiment we could try to mask some of the
>> > bits in nvme_ctrlr_configure_aer() function to find out which one
>> > exactly, but for discontinued drives 4-5 years old it might not have
>> > too much sense.  It should not be critical unless you either overheat
>> > them, or somehow else they fail and wish to report it.
>> >
>>
>> I am intrigued to how you guru's know this, is it  because you know
>> the code well enough?
>>
>
> SET FEATURES (opcode 9) feature 0xb is indeed async event configuration.
> 0x31f is:
> SMART WARNING for available spares (0x1)
> SMART warning for temperature (0x2)
> SMART WARNING for device reliability (0x4)
> SMART WARNING for being read only (0x8)
> SMART WARNING for volatile memory backup (0x10)
> Namespace attribute change events (0x100)
> Firmware activation events (0x200)
>
> I wonder which one of those it doesn't like. My reading of the standard
> suggests that those
> should always be supported for a 1.2 and later drive... Thought maybe with
> the possible
> exception of the volatile memory backup, so let me do some digging here...
>
> We can get the last two items from OAES field of the controller
> identificaiton data. This is bytes 95:92,
> which if I'm counting right is the last word on the 040: line in the
> nvmecontrol identify -x nvmeX command:
>
> 040: 4e474e4b 30303150 000cca07 00230000 00010200 005b8d80 0030d400
> 00000100
>
> ----------------------------------------------------------------------------------------------------------^^^^^^^^^
>
> It looks like we don't currently test these bits before we add the last
> two (we do it unconditionally
> for >= 1.2, and maybe we should check these bits >= 1.2).
>
> Would you be able to test a fix for this?
>
> Warner
>

--000000000000e3c1a105dfd7ee8b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Here's a patch that might fix it

di=
ff --git a/sys/dev/nvme/nvme_ctrlr.c b/sys/dev/nvme/nvme_ctrlr.c
index 2=
c5d521ecaa1..72c511de3be8 100644
--- a/sys/dev/nvme/nvme_ctrlr.c
+++ =
b/sys/dev/nvme/nvme_ctrlr.c
@@ -854,8 +854,9 @@ nvme_ctrlr_configure_aer=
(struct nvme_controller *ctrlr)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 NVME_CRIT_WARN_ST_READ_ONLY |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 NVME_CRIT_WARN_ST_VOLATILE_MEMORY_BACKUP;
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 if (ctrlr->cdata.ver >=3D NVME_REV(1, 2))
- =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ctrlr->async_event_config |=3D NVME_ASYN=
C_EVENT_NS_ATTRIBUTE |
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 NVME_ASYNC_EVENT_FW_ACTIVATE;
+ =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ctrlr->async_event_config |=3D
+ =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ctrlr->cdata.oae=
s & (NVME_ASYNC_EVENT_NS_ATTRIBUTE |
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NVME_ASYNC_EVENT_FW_ACTIVA=
TE);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 status.done =3D 0;
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 nvme_ctrlr_cmd_get_feature(ctrlr, NVME_FEAT_TEMPERATURE_THRE=
SHOLD,

Warner

On Wed, May 25, 2022 at 9:2=
9 AM Warner Losh <imp@bsdimp.com&g=
t; wrote:


On Wed, May 25, 2022 at 8:18 AM matti k <=
;mattik@gwsit.com.=
au> wrote:
; Wed, 25 May 2022 15:50:14 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe2f.google.com with SMTP id 68so14225613vse.11
        for ; Wed, 25 May 2022 08:50:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=ajvmJ7jYrFnBzqZCMqFlvIy00a8dJIZmtHxDTvuqJac=;
        b=x/6jboQ+K2PwktSZCrBFEUpKLyrtAcWg4tjChO0oG8EbaF92SZpSZ6vcJSRAOWNb0G
         eL+HJh9OvxewRVz639jQO3fWBVG27ORUnStb99pKECN1NZAw2IatfvslTTn3BINeDlNJ
         68d1qMSIQ4WiYfxStyn1EQeX5Oj6iAGSeawD20IbjhlDMWJafEGFdEXCO1aZHqMW7kwn
         Rup4i8GcJYY+VAgb3su+8Km3HMjuq9z20qlSKt+2tOaETrP2+slQtJmro8JIrfVY825x
         h5BK1fgoCcsf0bAeLNRrj7/jDOOvh58EgZ3QzApvHiaIQVkK2Daa7HRJrzm218ElG/TX
         UF6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=ajvmJ7jYrFnBzqZCMqFlvIy00a8dJIZmtHxDTvuqJac=;
        b=503HmWgdZ/vbKmtshXeqGlFbpt6qro2jc4qvSdlHnGgqnZhtgFfwi+rcBAbBS9s1te
         pn+WHAySaDakY0T7X5dDLU62exwmm403tX/bJrlgYh1HynMs8Rpo2wC5hUw7C4lmY/+O
         ts/iiaTK2SaMSWRhbe9J1s+JY+uUeEDLqzMX4SZojuGWjgMPS/8vKbSmaEZGZUzJwGSp
         rm50tsDLmccsmS6uXoemfydOFijanv63Vb/L/wHH2NwsBvaReLkW6Ww2lbafOtR+ohf8
         Sv9fu1nGzZ1ibhdUTqQf79HokaM3hd1pXICZHSy3lcmnhtHt6+KYgEykygfK+gbfgxTb
         lg6Q==
X-Gm-Message-State: AOAM532B9KRDvXboi0rxnHCwEKECBC8dQ8tDCc0NKu0Zuav3Zcbiu5sn
	DVyIlxC3hxRChUQqtx0+/jyAQzHOq8ZpbkdEoEV+Ow==
X-Google-Smtp-Source: ABdhPJz6XdwxBGECtq644A00m47x467dxN9Sex3a1ciopswABCPPhLquQNNpiA95/XQL4gBXu8KKk+OROyWA2WYpwME=
X-Received: by 2002:a67:f8ce:0:b0:335:d520:ab7f with SMTP id
 c14-20020a67f8ce000000b00335d520ab7fmr13185892vsp.51.1653493808391; Wed, 25
 May 2022 08:50: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: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
  <20220526001715.4ffee96a@ws1.wobblyboot.net>
  <20220525153920.sxzi7fhsfzv6yidv@ubertino.local>
In-Reply-To: <20220525153920.sxzi7fhsfzv6yidv@ubertino.local>
From: Warner Losh 
Date: Wed, 25 May 2022 09:49:56 -0600
Message-ID: 
Subject: Re: nvme INVALID_FIELD in dmesg.boot
To: Matteo Riondato 
Cc: matti k , Alexander Motin , 
	FreeBSD Current , Jim Harris 
Content-Type: multipart/alternative; boundary="0000000000001678bb05dfd807e0"
X-Rspamd-Queue-Id: 4L7b9y3pylz4d7K
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="x/6jboQ+";
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2f) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2f:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000001678bb05dfd807e0
Content-Type: text/plain; charset="UTF-8"

On Wed, May 25, 2022 at 9:39 AM Matteo Riondato  wrote:

> On 2022-05-25 at 11:29 EDT, Warner Losh  wrote:
> >
> >SET FEATURES (opcode 9) feature 0xb is indeed async event
> >configuration.
> >0x31f is:
> >SMART WARNING for available spares (0x1)
> >SMART warning for temperature (0x2)
> >SMART WARNING for device reliability (0x4)
> >SMART WARNING for being read only (0x8)
> >SMART WARNING for volatile memory backup (0x10)
> >Namespace attribute change events (0x100)
> >Firmware activation events (0x200)
> >
> >I wonder which one of those it doesn't like. My reading of the standard
> >suggests that those should always be supported for a 1.2 and later
> >drive... Thought maybe with the possible exception of the volatile
> >memory backup, so let me do some digging here...
> >
> >We can get the last two items from OAES field of the controller
> >identificaiton data. This is bytes 95:92, which if I'm counting right
> >is the last word on the 040: line in the nvmecontrol identify -x nvmeX
> >command:
> >
> >040: 4e474e4b 30303150 000cca07 00230000 00010200 005b8d80 0030d400
> >00000100
>
> >----------------------------------------------------------------------------------------------------------^^^^^^^^^
>
> On my system:
>
> 040: 31564456 30373130 5cd2e400 00000500 00010200 001e8480 002dc6c0
> 00000200
>

Yea, 0x200 and we send 0x300, so maybe that's the cause of the message....


> (same for all nvmeX, as far as I can tell)
>
> >It looks like we don't currently test these bits before we add the last
> >two (we do it unconditionally for >= 1.2, and maybe we should check
> >these bits >= 1.2).
> >
> >Would you be able to test a fix for this?
>
> Yes, I would be happy to, but I cannot do it for a couple of weeks
> (running simulations for a deadline).
>

There's  no real rush... Your system will be fine without these events
given what
I think you are doing with it. You might want to check the smart log page
to see
if any of the drives have indicators of trouble... but most trouble you'd
care about
would likely torpedo your simulation very very shortly after they happen so
even
that likely isn't strictly required.

Warner

--0000000000001678bb05dfd807e0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, May 25, 2022 at 9:39 AM Matte=
o Riondato <matteo@freebsd.org=
> wrote:
On 2=
022-05-25 at 11:29 EDT, Warner Losh <imp@bsdimp.com> wrote:

>

>SET FEATURES (opcode 9) feature 0xb is indeed async event 

>configuration.

>0x31f is:

>SMART WARNING for available spares (0x1)

>SMART warning for temperature (0x2)

>SMART WARNING for device reliability (0x4)

>SMART WARNING for being read only (0x8)

>SMART WARNING for volatile memory backup (0x10)

>Namespace attribute change events (0x100)

>Firmware activation events (0x200)

>

>I wonder which one of those it doesn't like. My reading of the stan=
dard 

>suggests that those should always be supported for a 1.2 and later 

>drive... Thought maybe with the possible exception of the volatile 

>memory backup, so let me do some digging here...

>

>We can get the last two items from OAES field of the controller 

>identificaiton data. This is bytes 95:92, which if I'm counting rig=
ht 

>is the last word on the 040: line in the nvmecontrol identify -x nvmeX =


>command:

>

>040: 4e474e4b 30303150 000cca07 00230000 00010200 005b8d80 0030d400 
>00000100

>-----------------------------------------------------------------------=
-----------------------------------^^^^^^^^^



On my system:



040: 31564456 30373130 5cd2e400 00000500 00010200 001e8480 002dc6c0 

00000200

Yea, 0x200 and we send 0x300, =
so maybe that's the cause of the message....
=C2=A0

(same for all nvmeX, as far as I can tell)



>It looks like we don't currently test these bits before we add the =
last 

>two (we do it unconditionally for >=3D 1.2, and maybe we should chec=
k 

>these bits >=3D 1.2).

>

>Would you be able to test a fix for this?



Yes, I would be happy to, but I cannot do it for a couple of weeks 

(running simulations for a deadline).

T=
here's=C2=A0 no real rush... Your system will be fine without these eve=
nts given what
I think you are doing with it. You might want to c=
heck the smart log page to see
if any of the drives have indicato=
rs of trouble... but most trouble you'd care about
would like=
ly torpedo your simulation very very shortly after they happen so even
that likely isn't strictly required.

War=
ner


--0000000000001678bb05dfd807e0--

From nobody Wed May 25 16:19:04 2022
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 A316C1B4D7C2
	for ; Wed, 25 May 2022 16:19:24 +0000 (UTC)
	(envelope-from ctuffli@gmail.com)
Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4L7bqb4LBQz4j6F;
	Wed, 25 May 2022 16:19:23 +0000 (UTC)
	(envelope-from ctuffli@gmail.com)
Received: by mail-ej1-f42.google.com with SMTP id i27so42656028ejd.9;
        Wed, 25 May 2022 09:19:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=KqGxGtbIfTLfUJIb1cLdfLbsrAcp61hrK0fc4yI7aK8=;
        b=HLHTB+v9P09BJ241rW0LP6mKEXTFxGgcNwQ1on/njnTMETnAhEeIJlvYa1W/qXxDSr
         5Pkef4L8Jsohy8vUNbKqcl7BLhi0mEHMVwB8CdcD7zZmYsB/kAHhZa0Rj3MDAJiV5n4D
         Rn4xUsZOutcOBMGOZnJ1VrZP+RrkVG0usP9EtaB2t3Mypb1300EQxeinijIe9jBTMDUO
         EW72mmjtTjILdKuW0xdPTLKjwGsnWRiS8lJv6n3zDw0vWZ2IU8lYTEp3kYHwegHh4kLf
         9KoLQdE2CipFusLHLWQetmLfGmNksvPVbAdujXKsglZtmvmmi9xAEDddJvURHpZg3zOP
         ajQg==
X-Gm-Message-State: AOAM531T4iU7IhEYBCl2DkPah1WC2fMwBMg158hx5R8N96cxxri6clAu
	ymA+H/ZnuljcVmySYugzDPpPYyuQ9GfrzA==
X-Google-Smtp-Source: ABdhPJz6ifABtfh4Cd3IXpduP+8Q+Dj3IFfeFl6aCGfcP5D2Le+qZj8ziUr/MpCcMmpF+bE3cmSuPQ==
X-Received: by 2002:a17:907:7b9b:b0:6fe:dedf:6414 with SMTP id ne27-20020a1709077b9b00b006fededf6414mr14928019ejc.88.1653495556024;
        Wed, 25 May 2022 09:19:16 -0700 (PDT)
Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com. [209.85.218.45])
        by smtp.gmail.com with ESMTPSA id w9-20020aa7d289000000b0042ae2d4e2f2sm10836082edq.86.2022.05.25.09.19.15
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 25 May 2022 09:19:15 -0700 (PDT)
Received: by mail-ej1-f45.google.com with SMTP id rq11so20576675ejc.4;
        Wed, 25 May 2022 09:19:15 -0700 (PDT)
X-Received: by 2002:a17:906:58c5:b0:6fe:fa12:1da9 with SMTP id
 e5-20020a17090658c500b006fefa121da9mr11613111ejs.148.1653495555489; Wed, 25
 May 2022 09:19:15 -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: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
 
In-Reply-To: 
From: Chuck Tuffli 
Date: Wed, 25 May 2022 09:19:04 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: nvme INVALID_FIELD in dmesg.boot
To: Alexander Motin 
Cc: Matteo Riondato , FreeBSD-Current , 
	Jim Harris 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4L7bqb4LBQz4j6F
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of ctuffli@gmail.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=ctuffli@gmail.com
X-Spamd-Result: default: False [-2.97 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RWL_MAILSPIKE_GOOD(0.00)[209.85.218.42:from];
	 RCVD_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-0.97)[-0.968];
	 RCVD_IN_DNSWL_NONE(0.00)[209.85.218.45:received,209.85.218.42:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[chuck@freebsd.org,ctuffli@gmail.com];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	 FROM_NEQ_ENVFROM(0.00)[chuck@freebsd.org,ctuffli@gmail.com];
	 FREEMAIL_ENVFROM(0.00)[gmail.com]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, May 25, 2022 at 6:59 AM Alexander Motin  wrote:
...
> > nvme0: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:0000000b cdw11:0000031f
> > nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
...
> Those messages mean that driver tried to enable certain types of
> asynchronous events, but probably the hardware does not support some of

Du-oh! I read the 'b' in 0000000b as 'binary'. Alexander and Warner
are correct that this is from setting an AEN, and I was wrong about
CDW10 causing the error.

FWIW, "CDW" in NVMe-land is shorthand for Command DWord as NVMe
commands are composed of 32-bit fields (ancient Intel/Microsoft
"double words").

From nobody Thu May 26 11:42:33 2022
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 C9D771B4FCE0
	for ; Thu, 26 May 2022 11:42:41 +0000 (UTC)
	(envelope-from sbruno@freebsd.org)
Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106])
	(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 4L85dr5jN5z54Jr
	for ; Thu, 26 May 2022 11:42:40 +0000 (UTC)
	(envelope-from sbruno@freebsd.org)
Received: from [192.168.1.14] (unknown [98.60.75.233])
	(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)
	(Authenticated sender: sbruno@ignoranthack.me)
	by mail.ignoranthack.me (Postfix) with ESMTPSA id E6A591AF400
	for ; Thu, 26 May 2022 11:42:33 +0000 (UTC)
Message-ID: <824a8d57-1029-33e1-9882-e8089ecad54c@freebsd.org>
Date: Thu, 26 May 2022 05:42:33 -0600
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Content-Language: en-US
To: freebsd-current 
From: Sean Bruno 
Subject: installworld failure with poudriere
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4L85dr5jN5z54Jr
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 199.102.79.106 is neither permitted nor denied by domain of sbruno@freebsd.org) smtp.mailfrom=sbruno@freebsd.org
X-Spamd-Result: default: False [-2.10 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FREEFALL_USER(0.00)[sbruno];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[freebsd.org];
	 R_SPF_SOFTFAIL(0.00)[~all:c];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_SPAM_MEDIUM(0.00)[0.004];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:36236, ipnet:199.102.76.0/22, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 TO_DOM_EQ_FROM_DOM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

https://people.freebsd.org/~sbruno/poudriere_atf_debug.txt

I think that some of the atf_check(1) Makefiles aren't respecting 
WITHOUT_DEBUG_FILES and this change has happened in the last few months.

===> libexec/atf/atf-check (install)
--- _proginstall ---
install -N /usr/src/etc  -s -o root -g wheel -m 555   atf-check 
/usr/local/poudriere/jails/14amd64/usr/libexec/atf-check
install -N /usr/src/etc  -o root -g wheel -m 444  atf-check.debug 
/usr/local/poudriere/jails/14amd64/usr/lib/debug/usr/libexec/atf-check.debug
install: atf-check.debug: No such file or directory
*** [_proginstall] Error code 71


sean

From nobody Fri May 27 09:10:44 2022
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 1C6A61B42C0A
	for ; Fri, 27 May 2022 09:10:57 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic312-23.consmr.mail.ne1.yahoo.com (sonic312-23.consmr.mail.ne1.yahoo.com [66.163.191.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 4L8fDH75Xzz4SYZ
	for ; Fri, 27 May 2022 09:10:55 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1653642649; bh=tXO7zXsHsM2LSZ5eFRlUrDsFBjaDd/gYyl+9JS2SewM=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=uLlbR2puEFpur1YWBH3/+fnj7PgTqLQ3R2V7CdtxWvBPmjl11DV8v8d0smxpGS1+reeTOY+FKUFKrcgS5TG7e/lxBV05ThaRP/ZHLTZd1tExzNv64ZF/v23ur9F6YVtblvOIRBW1RJATA5Zph6eKcMB3UmIwf9bDFIcZMFe4BxInN25+d+43wznGNODTM4vXk4h/d8CD1qYlqKs8Q3BYBkbwtoKDdFhFawXBrpg42MF5h/VEDSkgDrKh7VFtPFQA0x0DOzErOdsxS8dkqzFxgghr7FHVD/5W2dIrOtM41Y7Tislgf3Jnzau2OCOja1K8X9OniS+oJgvw1sUFuBktjQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1653642649; bh=0vQEr4nlFUiIevKTqi0ag/AhIRFOzrDzL/H0AmBx7OA=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=gniLZEUy1Y6yKeogIJ+EEFg620VbGf++EOupgRgcu48VPrZU8ZiACsivg9groCT39+63AiRKkTM4dA5suVurgLCUKicziihtyynLSQ2wQvVxG3Nk0CZBQ3Atl/Et6QRgj85+0+Pq+1ZiLL/SveJ4Ev17Q23M/St4/E4g2v8x5T+s0HPVrYhzn+AKdYFfLzCYgInTrUPjzk2Peq0kuiRvlg+KyXfrnQMWqR4rGAlSGJd+aqAqhAppcxtE9vUKfXbFnxwPg9/3ymwFTPvNyrt6HLJW39IP/I7kTlwN3Eg+l/0EM4KoVCkznyP9o0DjteGsbG7PbyBzjt2o02GX+66NKw==
X-YMail-OSG: 9nZnxO8VM1nijap3PP_7LlYr.UD8fYys2Vno5mK8SW5bDdkU10EhBu3zHWK_WWF
 nMghtQv9ybMwhs9OwguXidmWCV_iaCbjST3DwmmJVcIKXzm12jp62tM_jpVg5sVWUGwQBDjpBlL4
 UPAoAFbXub19e_PyEBG9coEulcoDuNyROdlFC_KAy1iC89_dH2xaopzy9GQLN8X9.1vHBRF9nyvv
 8szqhUuegNaNXqQFzg0.gINRtMDGmPS99BlNGTVLudk7MzHFJiOuT55BS3AI..B6iK4VrTMGKf9_
 iKnJNrDPuggEBwx7QgcbymyINBtUkdgE_fZnwKAM3Etuyia6duh0d9zQMZb76d4167EY21RWbBml
 JKa1QncEjbsGyat4vfFMMMScv18_5oVT4zxTewgm3Ffwek3W0sJ8bh64NsSRC.8f.F7rfBvDgngC
 zUqw1xmLOveTKmItEIK4c424.9p9tDkemNsgfRzycyvXIpFoT0vMdBOmi3_uWsjlTOj4eEkmcUQt
 vCBq.3b3quHt6NjOqrN2htblgjTtx3RN0rpYlVNo2j2SzKEKjxbkrfiwylTLyF5B4n6ce.0iovQ5
 Aoze948gqxZB7R2Yct3v7DErdrsAVSNvG9FsZS6YMWsrE7XQWveaDuCenH9Z19oitreHK2v4ZItH
 43recxelOi2gYrJ9.rmDcssJdqlcnbcRUdCQztI4_iAcIb9Lq_hb0th3X3BEcMUfLeD5xcsKpF_f
 3N10_yziVvnILY3rKey_zJVLzkWf9Xvyql9PLuFLzHV9LFqcN0.fGECJ13DZkBjl9ujsKHAhzg5U
 QSKqBvXyKYH86LJrwu4stzaNzA1tKE7LUmEUryGTHC5ZrZxFCLdkXEsDEER7kF6_xMLkzgEfsOHf
 viKMo5Pb.r4c.9Jb7ITmbHnuQEkcvxUbHvypglst9iXSBvTvIx8Ds0yr0tKSJFJUy.TvSPHAJO9S
 QLHKxF_jMZ202bB6yFWymJqqKlEXwI31Swzz8OGKFmYapxsQKEzbrZ7Xx_Lh67O2FiL9hMsDJ32T
 HUnD7NK8_3LYQvs3yo1qgTC1RuMNCD9RItcoKJyhchJtVlqyc9xmNnyTCaVGO9KpVRl4xYbvVrJH
 gY3rNWHZmnA00NiduR3Cn3eg2DVAQ5UM7E95tu3sNA4ZCS2hM5FHIeCsGB6h2DBdzDGhmNj5CFiH
 3feeGJO7Cr3OioY.Fnvmwy3vn0lt4io6PIFyDa_Ja9DQf3Si.c5bu3gLcEnVnGp77McShfBS8zMc
 1spEmd3bRl3K3Qi5tyZLp4tQl.7c7bgZ92kjYYYPJBWkDtiKgdkYa27a7WUIu6RereskbvPAZEol
 ZHnTIv2UvdBBykw3J2SEK1a3TOdgxIiXMPO7_eogCCfuBdKBXuEeHB1B177knbotCmvhmg8K9B1m
 Fp9V6Xi7ZnLnu_qFOcf0d2QwKdBWpVNdAp2scPeJL9CQpBk6NuKQe1.0MSDJZHIe1GMNF.ZvxXCu
 zdWBLOzs.eILudm4xhRLR3vALKqJLxADHGC3Ffej_sNyrE1HwDhNQBd_bcIObRLDmBwAMNaw9J9K
 pEri.QIvNsax0.RW1OOobZDMMjGj0jWq7gx5cmqYM0fMRbb2q8F353y9O1BRZ78d3mdQ3rsAtYKP
 Ik4tdcrU7YMPDQ0ne4hFO78lSavlFRH1qtljasbi3mq5U9mWqfy5Wncq_GV4RGOxXnh0jQ0BNmd8
 JflLD9LQOKMWv_NlFj25ztLqWNFzG64iRwmGqWDTJnBAcVDMaBA4GOSxQQVls7swAR9wziOui7EE
 iRUNYeTi4EbJTAtU4WeDk225kguti9YVgYIYKwH7FMdvNKIFPmMb6fsaM67F4rE7KzotRUwy_vSe
 Iryq.gKCI1SE.JBJhidtYHZZ3g2u_.VAFZRYo2JRnFFG77TGX2OfZfFv2oCWYWdwXWpR8_lYqDbY
 M_dMC4JeKQTcBexvf1t3rxgvT5FvUrpGWXbQ3cjkSByUCKbCJIwT_8ewtITAEc9eYS5qRPA7FAgW
 AmsHSMOd3GpP7afjyNHxPulTHhKmfebqeHh586TfrWhtzj5lc44tDLA_F2zMt_bOHMpWzhf0tNw.
 wEdmObfmQhjdUQfcRZZVcuOkLhEm9Du2GE4U6hxFdPQJjFgXL3Ob6mwf77ri6RdsRRPg76gLS7i2
 u5GIwoqVkQPHzYqiMSsvTsbcC
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Fri, 27 May 2022 09:10:49 +0000
Date: Fri, 27 May 2022 09:10:44 +0000 (UTC)
From: Filippo Moretti 
To: FreeBSD Current 
Message-ID: <876713478.3758475.1653642644131@mail.yahoo.com>
Subject: Problem booting CURRENT
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_3758474_1495633804.1653642644130"
References: <876713478.3758475.1653642644131.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.20225 YMailNorrin
X-Rspamd-Queue-Id: 4L8fDH75Xzz4SYZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=uLlbR2pu;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.191.204 as permitted sender) smtp.mailfrom=filippomore@yahoo.com
X-Spamd-Result: default: False [-3.90 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-0.90)[-0.904];
	 RCPT_COUNT_ONE(0.00)[1];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[66.163.191.204:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_3758474_1495633804.1653642644130
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

I run into this problem after rebboting my computer with CURRENTzfs:zroot/ROOT/default failed with error 22the mountroot freezes and I have to power off to restart.I did not apgrade or any changes since I used it last time.Is it possible to recover my system?Filippo

------=_Part_3758474_1495633804.1653642644130
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


I run into this problem after rebboting my computer with CURRENT
zfs:zroot/ROOT/default failed with error 22
the mountroot freezes and I have to power off to restart.
I did not apgrade or any changes since I used it last time.
Is it possible to recover my system?
Filippo

------=_Part_3758474_1495633804.1653642644130--

From nobody Sun May 29 17:07:29 2022
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 021391B43AC4
	for ; Sun, 29 May 2022 17:07:46 +0000 (UTC)
	(envelope-from pete@nomadlogic.org)
Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226])
	(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 "mail.nomadlogic.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LB4jX53hXz4WpT
	for ; Sun, 29 May 2022 17:07:44 +0000 (UTC)
	(envelope-from pete@nomadlogic.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org;
	s=04242021; t=1653844052;
	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=DCw+eTIPb/SGKCHXyxSht8BOsReV/d3SmzYpWRJpX6E=;
	b=056fYzCLPUS3Cmgugvoe+EiShYcivxk8L8IOCiYYHPs0e/V8ILNeoFBQYcs4/xqi/kr9rT
	qGzX0V/WvIBNXrCkOhAbfKf6RSYA8b9kW4yfTPirK0G4PCufS9+ua3RLOsKV8NW9lFtlB4
	9ttJkRRddHeaRtlpdLKdKfmksIbygjA=
Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214])
	by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 010bbc8e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Sun, 29 May 2022 17:07:31 +0000 (UTC)
Message-ID: 
Date: Sun, 29 May 2022 10:07:29 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: Chasing OOM Issues - good sysctl metrics to use?
Content-Language: en-US
To: Mark Millard ,
 freebsd-current 
References: <8C14A90D-3429-437C-A815-E811B7BFBF05.ref@yahoo.com>
 <8C14A90D-3429-437C-A815-E811B7BFBF05@yahoo.com>
From: Pete Wright 
In-Reply-To: <8C14A90D-3429-437C-A815-E811B7BFBF05@yahoo.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LB4jX53hXz4WpT
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=056fYzCL;
	dmarc=pass (policy=quarantine) header.from=nomadlogic.org;
	spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org
X-Spamd-Result: default: False [-2.62 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 NEURAL_HAM_LONG(-0.99)[-0.991];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[nomadlogic.org:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine];
	 NEURAL_HAM_SHORT(-0.63)[-0.625];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[yahoo.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


On 5/14/22 01:09, Mark Millard wrote:
>
> One of the points is to see if I get any evidence of
> vm.swap_enabled=0 with vm.swap_idle_enabled=0 ending up
> contributing to any problems in my normal usage. So far: no.
> vm.pageout_oom_seq=120 is in use for this, my normal
> context since sometime in 2018.

So to revive an old thread here.

it looks like setting these two sysctl knobs have helped the situation:
vm.swap_enabled=0
vm.swap_idle_enabled=0

i've gone 7 days without any OOM events under normal work usage (as 
opposed to about 4days previously).  this includes the following patch 
to vm_pageout.c that tijl@ shared with us:

diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c
index 36d5f327580..df827af3075 100644
--- a/sys/vm/vm_pageout.c
+++ b/sys/vm/vm_pageout.c
@@ -1069,7 +1069,7 @@ vm_pageout_laundry_worker(void *arg)
                 nclean = vmd->vmd_free_count +
                     vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt;
                 ndirty = vmd->vmd_pagequeues[PQ_LAUNDRY].pq_cnt;
-               if (target == 0 && ndirty * isqrt(howmany(nfreed + 1,
+               if (target == 0 && ndirty * isqrt(howmany(nfreed,
                     vmd->vmd_free_target - vmd->vmd_free_min)) >= nclean) {
                         target = vmd->vmd_background_launder_target;
                 }


I have adjusted my behavior a little bit as well, since i do quite a bit 
of work in the AWS console in firefox I've been better at closing out 
all of those tabs when i'm not using them (their console is a serious 
memory hog).  i've also started using an official chrome binary inside 
an ubuntu jail which is where i run slack and discord, that seems to 
behave better as well in terms of memory utilization.

i am going to revert the vm_pageout.c patch today when i do my weekly 
rebuild of world to see how things go, maybe that'll give determine if 
its really the sysctl's helping or not.

cheers,
-pete

-- 
Pete Wright
pete@nomadlogic.org
@nomadlogicLA


From nobody Sun May 29 18:16:09 2022
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 3B2BA1B58D1C
	for ; Sun, 29 May 2022 18:16:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LB6Dm1GMPz4gC9
	for ; Sun, 29 May 2022 18:16:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1653848175; bh=wuMGqQrEpXEp1YpR5pzMM30ldIWJP+awpzpFLrtjzgc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=l1YxiJIY98lQ0JWijWhkYK4lJBWT7X7gd4Rl9jiYHMI0nCYrFOvf5cc69Jmw66yQo6SotiPDuI5+dMiYJS/s3ra8w80XSCtZC8KaATqKpCTrRe8UrMvDhY3HaspjjSfXP1yy72o6mCHyCZk1J4TaD1RRwevszDXviRTSphy8W6PiqGVIDwLVe2+gwujl+Jx019Jk1DnGvOLENLyaKb1P1DyKMEBDnm92if8o9CyPec2srFQrTVVDBqOdQ/B9vrjw+WJRFbIQbgYOAdxkUAh52LgOTmqoyD1RRcoyBE1ImIlYB+iI++xoS5Lr3VFhcRyjymT+x2YVBtg6ojlOYlrKRw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1653848175; bh=KJdAZObhEQz46argFZZzLjzBpmpq3kGZdLIrQDDCRDG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Y+VE+uo8wTzUavU+1N7zDia8rubj00fASktR08+3mLkkdDEIG8BYNE3cUdxwUbik3MGCtj2hc/UfHM4ecS0LfxtkjT1Bneu/QX3J+DqjIwwIj9/ezd0PGflsfJfXNhg8rfxH82JuJA+I6eY++J/s+dK0xcPjWU6ETdxGUCMH3hPITZrNaUHqGdiaKovFo/NG3XS49Y/QfydRBW9duKDUdX9lA0pseTvc1fLe6xGLm7TM6iJ+1wfZCTuRsg2+36Tx36sMqOeScDS/pwEv3aWgKXUAU5ug/0uTf9qdKCy/u/Pt5Fs0Cv11eoXa45X/FakCan95FO1vLtZ7QSj0Kj4EKQ==
X-YMail-OSG: o0yU854VM1l1utq5jVEzmMTRqt5H578ZH23LHWYkqIj_xqKC_l1JF8_iz7KWtAI
 1l10bNiYn2JNt79ESOWxRdZoE2q3mXkJIEgXmpf48QqK1pLJy1wxirVG.B_e_QeIH6Zl3EATgu4L
 s9jPzemLQ96WeauJgKbAu91rcWDqi99YgCSZ8GS4D7y5E0G7.FJpb5HmpQG3WFkjr25a4.Gl8tLZ
 LPWrgJEkhDnqEQ6V2bQDagNh9CwKLW2Mq4rWdvzEy4cohuOU5erpJXbQTpxiJt0TlWvdkKcfEbZQ
 CMbC_wL7NhJJoqJmBwp6iKOcoh9zN4sRNagUtTfg_tGwqXkC4LwXPUf8U6Yp6MOtkRfM3Tfsbwyt
 NVAOI3LD8SVB3AVRfFDlCZ4nEzXYX.Dirv3S9xi_p08WOR02UZXfgE6RisTKlRw2P9zW5iAaFWpR
 YSn96bmqZPXrSE6m0zjrR4IVCl1I3.imLCs09TjiDxEfHpe1prT54ccMm_wOfoBewZ3M9Dko2rJt
 tbHk8gRESrmQoi.NVBPao1tUM_DqBhQ8bs4LZCdVIxXtIz8USY2JcKDYqxdnSz4d2yE4MuNe5ytl
 .9jmqvafE31fHHfpDO1U0gkO4xaLG7Lzz0qLEtEDLaa5u1ZkCSyaXfBgeWzXHZD7pQz4uLsxBree
 lgG8cyNYUKJ2wzavGtK1LZxwLLCCOW51DAEXWdL1sWCK6QwlP1ZIeLEDfwvhb8y57nyGMg5BhUby
 jyXn24WG9CcqFtUJTuDZx3eUxscZF6ZmIfIGZ4oRhmx3mpzT_9cQsCRUmdPIIlTJ4B8ki0TbxL0s
 UlrRei4IHClJmjLDi9pWa6mHb71cMmbPWYQTDza8ne_jp0lGUOQATuzAGBgp5My1Hf4XXUytTAc.
 9Fw6qCCXb_qan9IKGyYHYasZR9BFkNxBQXLxmZ7Kr82Nfwe6KiLs35ukmaZTn8pebAPB5MPXf6dv
 RCPA6fRcqx8uwU_q5vkRpZ956BONN1FjLryBv26Ay6Pn5Q9ac2CN_DQHUFHan1B0f7pM1PYIPD50
 XQG.5yfyQes.Q_7XExM2WYuXqay3XZvGRofZmFdzTYvfZMrvg7hnWY_jFVn9RDe9pZajcYDik46w
 1qNT_QjY16S2KJMnv_qqURmDUkNNOn0gDyAd0aU8XlZNC7ZwKM2OShVAeTrdXovF87kIGJFT0tfN
 qKF96I5rdaw7lcI5L_TeUMlW1Swl8xp.h9c3FLbgP6_JSRpokVazf45jTrPbkMbheYplmjgDYPBm
 fCkE2J07C4Djx15H0SRdvd_1E0j9btx735wW7fB0KpeKA_0f9W3RmqMEoiUJpm_l.KYoozgea6DB
 th1xzfp41ufEfLTVylN0zx8F8510nH1zfMLt5wl0HAMH8hygm9KAOUpO2SgHcroUJjbkXYGKo0xv
 Z_f8OivfMyM9PGtohjvuOq5aouF1fcd3vLWICvyy_rrYOLjbG1JFkjJLiNffpArkXLhKAdWvLG8n
 2qnVq6H118X9hNjfheGt5GVNv.BoZuNAgVK9qj5xWs1qwajCOnwo_mleEgGNF1dixF5pauvUfIia
 iRrmW_gQ6d.sRvteyPqZM01YPy2fFyUYUJJMQ.GMI7sURFkpo9TL4L0.sWpheHJ595uoX2gEWxl_
 HS6tUamtBspiU4_ecjVX3POjRzLQ03htqawugTlmu1qGtSOG6T_INJ0T.Lkizs7pd2jz.rPiTREg
 15wa7jhOuvU6R_cYd4n3vSSZQKM6Zhyy9FNsA78yHFF1Q0A1oCktnk3PbwCa.etwX5A1rHN5MDEG
 14.cbC3Q6ZyhqK3gjB13_c3SLaVurbvtIweIcF99KOFsIyte.u0boHMwy5SeqAIAkATYFy6tTf95
 4WKoqH.YBsahZaFLB.xXMC42hLNx.OJmaDMmvQOEfdRYLg0ELNcy8RvaErOFTG7lPh59E.I1jTCZ
 5YBk12MmLTwnL4xKt8CR8RdYnoOoaSPcZah2T.BR.i3rPNVCL2hLuLVd17ORgfRQLIVtQAGAjs5E
 rs8W5ot7b0Z7OpxPZBrFvYfQNZpXeTb4YAY4Tf5C9690nsM7gp7fY6n1t5uDu3K9v0TgWqs_l7Au
 vwRt9PC1YpEcnTtj02qlBpiKes97WHSdOJCN4rcf1atplnftHEn2liNE0CQ5xMhNVA1U8bLKdpdc
 koSNLX2mMlF9Hv2S2OcNEijmUR3vm_V31.bo6YhYM5uFPVonoJ6P.n9WADC9hQhKy6Y7x8_00NDx
 YpLEst0Ca1nm49eNnlRFBHp83JgLEwu3PPjsty5Olx4_w0NnNlje6B5q9F0SLvxN.KGDDALdHhBd
 TN58gD.6hsZ_L
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 29 May 2022 18:16:15 +0000
Received: by hermes--canary-production-gq1-54945cc758-dgl4g (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 82d274c11d8a018bf0f2e871f8d8ee75;
          Sun, 29 May 2022 18:16:10 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: Chasing OOM Issues - good sysctl metrics to use?
From: Mark Millard 
In-Reply-To: 
Date: Sun, 29 May 2022 11:16:09 -0700
Cc: freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8C14A90D-3429-437C-A815-E811B7BFBF05.ref@yahoo.com>
 <8C14A90D-3429-437C-A815-E811B7BFBF05@yahoo.com>
 
To: Pete Wright 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LB6Dm1GMPz4gC9
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=l1YxiJIY;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [0.65 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-0.29)[-0.295];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_SPAM_SHORT(0.76)[0.762];
	 NEURAL_HAM_LONG(-0.32)[-0.318];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-May-29, at 10:07, Pete Wright  wrote:

> On 5/14/22 01:09, Mark Millard wrote:
>>=20
>> One of the points is to see if I get any evidence of
>> vm.swap_enabled=3D0 with vm.swap_idle_enabled=3D0 ending up
>> contributing to any problems in my normal usage. So far: no.
>> vm.pageout_oom_seq=3D120 is in use for this, my normal
>> context since sometime in 2018.
>=20
> So to revive an old thread here.
>=20
> it looks like setting these two sysctl knobs have helped the =
situation:
> vm.swap_enabled=3D0
> vm.swap_idle_enabled=3D0
>=20
> i've gone 7 days without any OOM events under normal work usage (as =
opposed to about 4days previously).

FYI, the combination:

vm.pageout_oom_seq=3D120 # in /boot/loader.conf
vm.swap_enabled=3D0      # in /etc/sysctl.conf
vm.swap_idle_enabled=3D0 # in /etc/sysctl.conf

still has not caused me any additional problems
and helps avoid loss of access by avoiding the
relevant interaction-processes from having their
kernel stacks swapped out. (Not that the effect
of vm.swap_enabled=3D0 is limited to
interaction-processes.)

So, the combination is now part of the
configuration of each FreeBSD that I use.

> this includes the following patch to vm_pageout.c that tijl@ shared =
with us:
>=20
> diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c
> index 36d5f327580..df827af3075 100644
> --- a/sys/vm/vm_pageout.c
> +++ b/sys/vm/vm_pageout.c
> @@ -1069,7 +1069,7 @@ vm_pageout_laundry_worker(void *arg)
>                 nclean =3D vmd->vmd_free_count +
>                     vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt;
>                 ndirty =3D vmd->vmd_pagequeues[PQ_LAUNDRY].pq_cnt;
> -               if (target =3D=3D 0 && ndirty * isqrt(howmany(nfreed + =
1,
> +               if (target =3D=3D 0 && ndirty * isqrt(howmany(nfreed,
>                     vmd->vmd_free_target - vmd->vmd_free_min)) >=3D =
nclean) {
>                         target =3D vmd->vmd_background_launder_target;
>                 }

FYI: I restored the original code after doing the testing
for tijl@ .

> I have adjusted my behavior a little bit as well, since i do quite a =
bit of work in the AWS console in firefox I've been better at closing =
out all of those tabs when i'm not using them (their console is a =
serious memory hog).  i've also started using an official chrome binary =
inside an ubuntu jail which is where i run slack and discord, that seems =
to behave better as well in terms of memory utilization.
>=20
> i am going to revert the vm_pageout.c patch today when i do my weekly =
rebuild of world to see how things go, maybe that'll give determine if =
its really the sysctl's helping or not.

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


From nobody Sun May 29 21:45:09 2022
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 195BD1B5392E
	for ; Sun, 29 May 2022 21:47:00 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBBvl3GxHz3Pkm
	for ; Sun, 29 May 2022 21:46:59 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: by mail-wr1-x431.google.com with SMTP id k19so4145613wrd.8
        for ; Sun, 29 May 2022 14:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=message-id:date:mime-version:user-agent:subject:content-language:to
         :references:from:in-reply-to;
        bh=0nxuC2OZqfvt5KOBFlA8960ZWs80dRkhYHCy9TmzRYo=;
        b=oKItD5bCHYBXwsZr+oWKrtk0kjay9fT9L1NnHecmNj3GQHdxv3D8Bt6OOZXEjzbZ3C
         P/VGermp0rl2OWM9oBXHfDRB3tGP1yFnbfPoTU5s+S6LnGQ3YT+PBYgjbFsgmCmD5HLY
         LWSVow2WBYkmRP4W2J0yxDbEKRCxjV0yKVwokllsBKP4fcHroh+9SXtyOzbXeKK4nr4h
         4rbHQBGauK2hI4BFAyf8OlGXjwHePqkY0kQPuRDnVwZk/3uu4uJr5Pah8qw8lfT+Ahd6
         PSpa/dTDgL+mm7gkQNfXn8zdynyuiBNkO7/D7+QL0jv5Ifgjk18JI9mpcMRvwRS8etJC
         DkcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
         :content-language:to:references:from:in-reply-to;
        bh=0nxuC2OZqfvt5KOBFlA8960ZWs80dRkhYHCy9TmzRYo=;
        b=lOs7c175A9z5K1Huq5nRy4FiSsMWZSSlkFa3AaJmyKik/rp5snTNDALlR8RhYqngA0
         jNV7F+Tm4I3X9dHLNoacrbKAE1Gf8mL4XkolIZOIgOPp0KX3iXXz4MXQbiDIwROSATp/
         l9b/LYRxyTwRYdKw6Hioedgf8EsYemXCT2zcPwkSt9iRhwSKHMSaim/fLMM7yJXPnQmC
         qXRasVhyJyW1m9A4t4Fma2+RVpNxaKCzxinFl0TNQrAmI3aG/GuKIxs5VgNA/nMk89Ph
         Q2bTQrXj/RUCgECglJQfNP2lGKxqoVhURtmBmXRizmpUY4IEGwhLr/+18kJn9KojCg6F
         jF4w==
X-Gm-Message-State: AOAM533gphqnykUNWg6aN/hkW844GkRvKqUoRLuKDnO5GV7OLBYfzTU2
	AadIAgGdyqghcuJCkEW/rvwPxj6/eck=
X-Google-Smtp-Source: ABdhPJyt5tfFBpPyakmxaZzj9OSUWAsjf6S8MkkbLMfw7jsGbxT9mI3lNZVo758PHAfqFMq8RwkAWw==
X-Received: by 2002:a05:6000:36b:b0:210:293b:8e17 with SMTP id f11-20020a056000036b00b00210293b8e17mr6193259wrf.440.1653860818260;
        Sun, 29 May 2022 14:46:58 -0700 (PDT)
Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2])
        by smtp.gmail.com with ESMTPSA id bd15-20020a05600c1f0f00b0039466988f6csm8654576wmb.31.2022.05.29.14.46.57
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 29 May 2022 14:46:57 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------eB2gk6Af4IkKQECWUcAfAl00"
Message-ID: 
Date: Sun, 29 May 2022 22:45:09 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: Problem booting CURRENT
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: <876713478.3758475.1653642644131.ref@mail.yahoo.com>
 <876713478.3758475.1653642644131@mail.yahoo.com>
From: Graham Perrin 
In-Reply-To: <876713478.3758475.1653642644131@mail.yahoo.com>
X-Rspamd-Queue-Id: 4LBBvl3GxHz3Pkm
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=oKItD5bC;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::431 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com
X-Spamd-Result: default: False [-3.67 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 TO_DN_NONE(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.67)[-0.674];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------eB2gk6Af4IkKQECWUcAfAl00
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 27/05/2022 10:10, Filippo Moretti wrote:
> I run into this problem after rebboting my computer with CURRENT
> zfs:zroot/ROOT/default failed with error 22
> the mountroot freezes and I have to power off to restart.
> I did not apgrade or any changes since I used it last time.
> Is it possible to recover my system?
> Filippo
GELI encrypted?
--------------eB2gk6Af4IkKQECWUcAfAl00
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 27/05/2022 10:10, Filippo Moretti
      wrote:

    

    

      
      

        
I run into this problem after
          rebboting my computer with CURRENT

        
zfs:zroot/ROOT/default failed
          with error 22

        
the mountroot freezes and I
          have to power off to restart.

        
I did not apgrade or any
          changes since I used it last time.

        
Is it possible to recover my
          system?

        
Filippo

        

      

    

    GELI encrypted?

  
  


--------------eB2gk6Af4IkKQECWUcAfAl00--

From nobody Sun May 29 23:10:52 2022
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 B5A071B45ADF
	for ; Sun, 29 May 2022 23:10:57 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBDmb2DDQz3sjL
	for ; Sun, 29 May 2022 23:10:55 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 24TNAq5T006467
	for ; Sun, 29 May 2022 23:10:53 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 24TNAq6K006466
	for current@freebsd.org; Sun, 29 May 2022 16:10:52 -0700 (PDT)
	(envelope-from david)
Date: Sun, 29 May 2022 16:10:52 -0700
From: David Wolfskill 
To: current@freebsd.org
Subject: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
Message-ID: 
Reply-To: current@freebsd.org
Mail-Followup-To: current@freebsd.org
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="7zQN9hfteQGZm4pO"
Content-Disposition: inline
X-Rspamd-Queue-Id: 4LBDmb2DDQz3sjL
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-0.25 / 15.00];
	 HAS_REPLYTO(0.00)[current@freebsd.org];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[david];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-0.99)[-0.985];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-0.90)[-0.900];
	 DMARC_NA(0.00)[catwhisker.org];
	 NEURAL_HAM_MEDIUM(-0.96)[-0.963];
	 MLMMJ_DEST(0.00)[current];
	 SIGNED_PGP(-2.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_COUNT_TWO(0.00)[2];
	 ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	 REPLYTO_EQ_TO_ADDR(5.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--7zQN9hfteQGZm4pO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

-- but only on one machine (of the 3 that I use for daily tracking head
(and stable/12 & stable/13) -- the build machine ("freebeast").

Each is amd64, using ... venerable ... BIOS/MBR & UFS -- stuff that has
generally been functionally stable for the last couple of decades.

So for yesterday and today, I've moved the new loader aside and copied
the one from Friday, which works just fine.

The build machine ("freebeast") uses a GENERIC kernel; the other 2 are
laptops, and use a kernel that includes GENERIC, then tweaks things a
bit (e.g., dropping support for tape drives; adding IPFIREWALL and
explicitly NOT setting IPFIREWALL_DEFAULT_TO_ACCEPT; adding sound stuff).

Info on the update history & copies of stuff like most recent
(verbosely-booted) dmesg.boot should be available at
https://www.catwhisker.org/~david/FreeBSD/history/ (and if you can't get
through, please send a note to dhw@freebsd.org and I'll do what I can to
fix it).

(Of the 2 laptops, I only have the one that I actuaqlly use in
day-to-day work represented.)

(I note that to recover, I boot from one the stable/* slices, move the
"head" slice's files around, then reboot from the "head" slice.)

AFAICT, there were no changes to stand/* since main-n255828-18054d0220c,
though yesterday (main-n255828-18054d0220c -> main-n255840-9cb70cb4769),
there were some changes to sys/ufs/ffs/ffs_subr.c (from
main-n255835-076002f24d35:

commit 076002f24d35962f0d21f44bfddd34ee4d7f015d
Author: Kirk McKusick 
Date:   Fri May 27 12:21:11 2022 -0700

    Do comprehensive UFS/FFS superblock integrity checks when reading a sup=
erblock.
   =20
    Historically only minimal checks were made of a superblock when it
    was read in as it was assumed that fsck would have been run to...

-- which doesn't seem a likely culprit to me).

That said, I am powering freebeast up, and plan to run a manual
full fsck on the "head" slice's root file system....  Maybe a few
others, while I'm here. :-}

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshniko=
va

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--7zQN9hfteQGZm4pO
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYpP9fF8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1EoGAP45WPJYKS+NfHpMHiq1m1Kvrn6mrX9GdrT2HMFUypZnKwEAxmokgNTXO9NM
Q4sHnfWo4G153+OSubPPK2XS7Wh9jAQ=
=YPMf
-----END PGP SIGNATURE-----

--7zQN9hfteQGZm4pO--

From nobody Mon May 30 00:59:34 2022
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 78A261B64ABF
	for ; Mon, 30 May 2022 00:59:53 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBHBJ2dV9z4hHQ
	for ; Mon, 30 May 2022 00:59:52 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x92b.google.com with SMTP id p3so1060973uam.12
        for ; Sun, 29 May 2022 17:59:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=93VO1JTL1cAS1FLLzxbdNbxDrfZtZodvgnhL7dkytqQ=;
        b=Dk+YR0iNsQxVdGSe32+b7q7N8snz0IQclijjkEHtr8WlJ/p4eR2y3toJPbF7+b2G7U
         9gbzMdVlv8aVbmN22Znv9bm3Ah6OiUL3AEkGs+Hk2KNXdD/IcRl+J1sHlCk/s209lHHQ
         ns58RYaaLfVUOHLElBNOEjB8aG+cTFNjICWfQhZWqtu5XO5teh5aLbJjpBFQr2HTXXoL
         +Iwth/fnHzq4KdgDGB6jvgm/vIaQxIUH1oH55H+iqYYkEtWFOPqbkyS3DRFX97r1kq7o
         rBH4ENC2WrZJ9Ep/ukW8LBmRIS7WBq+bLBvAdow5bizZLNlGxhLVzZSF4i0yrUBgO4SM
         mTlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=93VO1JTL1cAS1FLLzxbdNbxDrfZtZodvgnhL7dkytqQ=;
        b=7p+4tMMHZ5Btn5Q9fg4C7DtJzCk0Y0do2SMLFXaNbqudTN3yG/dKRmkMPfGgp6JNIj
         MOyxNB+pmgLE+AZqFudWCeB/jZU9dUcu1ftrOSOUHSFuG36FsxG3yKZMS8lKBIgAoRBn
         BxremEFDXCqgC+61wvrVJ5uv7dYz1W3UQwO/YEjKDfg/tXJLCDtRHGQDrlKT+SwZrg3L
         h4k5oqPDS+rd8Acnfr7xn3ynIPE1lR4KvfjgULY4QM4BGp2qcjNj8pQVg9KjeXYUfLtw
         rA+ngBoeu74mfZtlMvKbYSnviIMQMoIZMq5QDdoIib57evy/HJV0uYf1/05WvkYgON3W
         QcvA==
X-Gm-Message-State: AOAM532uUutiu4HRy/sh/RECKIYhuJwsX1pv7ml/e1pXWgaymbdNkl6b
	69VJzc+2zYy54tZvjb+ibQBqd3exHAwArNZTCghrYZin0kw=
X-Google-Smtp-Source: ABdhPJwWOgbTOsvaOMfpNH0s8Z5s3frquxAqZffdAV3T77uexYFAKR6UgWECGLFOHYxU7MitHP9HiGyZz4O1Q9pNuXE=
X-Received: by 2002:ab0:7285:0:b0:365:f08d:a27a with SMTP id
 w5-20020ab07285000000b00365f08da27amr18849834uao.93.1653872385802; Sun, 29
 May 2022 17:59:45 -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: Sun, 29 May 2022 18:59:34 -0600
Message-ID: 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c
To: FreeBSD Current 
Content-Type: multipart/alternative; boundary="0000000000000f5c5305e0302cad"
X-Rspamd-Queue-Id: 4LBHBJ2dV9z4hHQ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Dk+YR0iN;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92b) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.54 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.56)[-0.557];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-0.98)[-0.980];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92b:from];
	 MLMMJ_DEST(0.00)[current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000000f5c5305e0302cad
Content-Type: text/plain; charset="UTF-8"

Sorry for top posting...

Did you upgrade your boot blocks?

Warner

On Sun, May 29, 2022, 5:11 PM David Wolfskill  wrote:

> -- but only on one machine (of the 3 that I use for daily tracking head
> (and stable/12 & stable/13) -- the build machine ("freebeast").
>
> Each is amd64, using ... venerable ... BIOS/MBR & UFS -- stuff that has
> generally been functionally stable for the last couple of decades.
>
> So for yesterday and today, I've moved the new loader aside and copied
> the one from Friday, which works just fine.
>
> The build machine ("freebeast") uses a GENERIC kernel; the other 2 are
> laptops, and use a kernel that includes GENERIC, then tweaks things a
> bit (e.g., dropping support for tape drives; adding IPFIREWALL and
> explicitly NOT setting IPFIREWALL_DEFAULT_TO_ACCEPT; adding sound stuff).
>
> Info on the update history & copies of stuff like most recent
> (verbosely-booted) dmesg.boot should be available at
> https://www.catwhisker.org/~david/FreeBSD/history/ (and if you can't get
> through, please send a note to dhw@freebsd.org and I'll do what I can to
> fix it).
>
> (Of the 2 laptops, I only have the one that I actuaqlly use in
> day-to-day work represented.)
>
> (I note that to recover, I boot from one the stable/* slices, move the
> "head" slice's files around, then reboot from the "head" slice.)
>
> AFAICT, there were no changes to stand/* since main-n255828-18054d0220c,
> though yesterday (main-n255828-18054d0220c -> main-n255840-9cb70cb4769),
> there were some changes to sys/ufs/ffs/ffs_subr.c (from
> main-n255835-076002f24d35:
>
> commit 076002f24d35962f0d21f44bfddd34ee4d7f015d
> Author: Kirk McKusick 
> Date:   Fri May 27 12:21:11 2022 -0700
>
>     Do comprehensive UFS/FFS superblock integrity checks when reading a
> superblock.
>
>     Historically only minimal checks were made of a superblock when it
>     was read in as it was assumed that fsck would have been run to...
>
> -- which doesn't seem a likely culprit to me).
>
> That said, I am powering freebeast up, and plan to run a manual
> full fsck on the "head" slice's root file system....  Maybe a few
> others, while I'm here. :-}
>
> Peace,
> david
> --
> David H. Wolfskill                              david@catwhisker.org
> "Putin is a paranoid dictator.  Putin must go. He started a senseless war
> and is leading Russia into a ditch." - Egor Polyakov & Alexandra
> Miroshnikova
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>

--0000000000000f5c5305e0302cad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Sorry for top posting...

Did you upgrade your boot blocks?

<=
/div>
Warner=C2=A0

On Sun, May 29, 2022, 5:11 PM Davi=
d Wolfskill <david@catwhisker.or=
g> wrote:
-- but only on one=
 machine (of the 3 that I use for daily tracking head

(and stable/12 & stable/13) -- the build machine ("freebeast"=
).



Each is amd64, using ... venerable ... BIOS/MBR & UFS -- stuff that has=


generally been functionally stable for the last couple of decades.



So for yesterday and today, I've moved the new loader aside and copied<=
br>
the one from Friday, which works just fine.



The build machine ("freebeast") uses a GENERIC kernel; the other =
2 are

laptops, and use a kernel that includes GENERIC, then tweaks things a

bit (e.g., dropping support for tape drives; adding IPFIREWALL and

explicitly NOT setting IPFIREWALL_DEFAULT_TO_ACCEPT; adding sound stuff).


Info on the update history & copies of stuff like most recent

(verbosely-booted) dmesg.boot should be available at

https://www.catwhisker.org/~david/FreeB=
SD/history/ (and if you can't get

through, please send a note to dhw@freebsd.org and I'll do what I can =
to

fix it).



(Of the 2 laptops, I only have the one that I actuaqlly use in

day-to-day work represented.)



(I note that to recover, I boot from one the stable/* slices, move the

"head" slice's files around, then reboot from the "head&=
quot; slice.)



AFAICT, there were no changes to stand/* since main-n255828-18054d0220c,
though yesterday (main-n255828-18054d0220c -> main-n255840-9cb70cb4769),=


there were some changes to sys/ufs/ffs/ffs_subr.c (from

main-n255835-076002f24d35:



commit 076002f24d35962f0d21f44bfddd34ee4d7f015d

Author: Kirk McKusick <mckusick@FreeBSD.org>

Date:=C2=A0 =C2=A0Fri May 27 12:21:11 2022 -0700



=C2=A0 =C2=A0 Do comprehensive UFS/FFS superblock integrity checks when rea=
ding a superblock.



=C2=A0 =C2=A0 Historically only minimal checks were made of a superblock wh=
en it

=C2=A0 =C2=A0 was read in as it was assumed that fsck would have been run t=
o...



-- which doesn't seem a likely culprit to me).



That said, I am powering freebeast up, and plan to run a manual

full fsck on the "head" slice's root file system....=C2=A0 Ma=
ybe a few

others, while I'm here. :-}



Peace,

david

-- 

David H. Wolfskill=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 david@catwhisker.org=


"Putin is a paranoid dictator.=C2=A0 Putin must go. He started a sense=
less war

and is leading Russia into a ditch." - Egor Polyakov & Alexandra M=
iroshnikova



See https://www.catwhisker.org/~david/publ=
ickey.gpg for my public key.




--0000000000000f5c5305e0302cad--

From nobody Mon May 30 01:26:03 2022
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 C4F671B41F1A
	for ; Mon, 30 May 2022 01:26:08 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBHmb41WHz4lG7
	for ; Mon, 30 May 2022 01:26:07 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 24U1Q35p009573;
	Mon, 30 May 2022 01:26:03 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 24U1Q3tP009572;
	Sun, 29 May 2022 18:26:03 -0700 (PDT)
	(envelope-from david)
Date: Sun, 29 May 2022 18:26:03 -0700
From: David Wolfskill 
To: Warner Losh 
Cc: FreeBSD Current 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
Message-ID: 
Reply-To: current@freebsd.org
Mail-Followup-To: current@freebsd.org, Warner Losh 
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-sha512;
	protocol="application/pgp-signature"; boundary="0OBlzr3naWwxtngA"
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4LBHmb41WHz4lG7
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-0.45 / 15.00];
	 ARC_NA(0.00)[];
	 HAS_REPLYTO(0.00)[current@freebsd.org];
	 FREEFALL_USER(0.00)[david];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c];
	 NEURAL_SPAM_SHORT(0.99)[0.990];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
	 DMARC_NA(0.00)[catwhisker.org];
	 NEURAL_SPAM_MEDIUM(0.03)[0.028];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_SPAM_LONG(0.93)[0.930];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 MLMMJ_DEST(0.00)[current];
	 SIGNED_PGP(-2.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--0OBlzr3naWwxtngA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
> Sorry for top posting...
>=20
> Did you upgrade your boot blocks?

Thanks for the reply!

Hmmm....  Well, every time I rebuild FreeBSD head, the last step
just after "make installworld" and before the reboot is:

# gpart bootcode -b /boot/boot /dev/ada0s4

So *those* get updated.

I haven't updated from /boot/boot0 recently (and have a requirement that
whatever is in the MBR is able to boot stable/12, stable/13, and head).

Is updating (from head's /boot/bot0) recommended at this point?
> ....

(And in case it wasn't obvious, I made a silly typo in the Subject; it
should have read:

| Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after
|  main-n255828-18054d0220c

Sorry: I don't have loader messages showing up on serial console on that
machine at this point, so I had hand-typed it from memory and managed to
elide a letter.)

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshniko=
va

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--0OBlzr3naWwxtngA
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYpQdK18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1LLwAPsEwuvmu+Eig+3wOkgsLbWOZifxzXFCP+d4VwlAm+IKngEA9vaMYve+e9Hn
dRshYdzDWabzhr1xNp3hhM4GN4rhgA0=
=r3I5
-----END PGP SIGNATURE-----

--0OBlzr3naWwxtngA--

From nobody Mon May 30 03:42:50 2022
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 011341B61CEB
	for ; Mon, 30 May 2022 03:42:58 +0000 (UTC)
	(envelope-from pete@nomadlogic.org)
Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226])
	(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 "mail.nomadlogic.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBLpT0Bx4z3FXN
	for ; Mon, 30 May 2022 03:42:56 +0000 (UTC)
	(envelope-from pete@nomadlogic.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org;
	s=04242021; t=1653882171;
	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=/3qYwOV40uh3w22PRJaoWJXMxg5EokpHFZSwA2m3ebA=;
	b=JLgBODkPxyTjhFDeD8C9Bw16uWnbZn1G699HoSv3QSUUm7GLnzn1KeDn6Y5tVp0AggDi16
	Y7BEuWOdET1tVvUirlrdHCnp8R49y12wRfu2KMvstWvHPk2aBTI4GqEm4sAduD6B6Bsmm7
	c81hSMMuvhQRtcOCSIMCFUOMgIn8qms=
Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214])
	by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 222a7d03 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Mon, 30 May 2022 03:42:50 +0000 (UTC)
Message-ID: <499358a4-beec-67d1-460c-3fe61781fb0c@nomadlogic.org>
Date: Sun, 29 May 2022 20:42:50 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: Chasing OOM Issues - good sysctl metrics to use?
Content-Language: en-US
To: Mark Millard 
Cc: freebsd-current 
References: <8C14A90D-3429-437C-A815-E811B7BFBF05.ref@yahoo.com>
 <8C14A90D-3429-437C-A815-E811B7BFBF05@yahoo.com>
 
 
From: Pete Wright 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LBLpT0Bx4z3FXN
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=JLgBODkP;
	dmarc=pass (policy=quarantine) header.from=nomadlogic.org;
	spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org
X-Spamd-Result: default: False [-2.94 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 NEURAL_HAM_LONG(-0.99)[-0.990];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_MEDIUM(-0.97)[-0.971];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[nomadlogic.org:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine];
	 NEURAL_HAM_SHORT(-0.98)[-0.978];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On 5/29/22 11:16, Mark Millard wrote:
>
> FYI, the combination:
>
> vm.pageout_oom_seq=120 # in /boot/loader.conf
> vm.swap_enabled=0      # in /etc/sysctl.conf
> vm.swap_idle_enabled=0 # in /etc/sysctl.conf
>
> still has not caused me any additional problems
> and helps avoid loss of access by avoiding the
> relevant interaction-processes from having their
> kernel stacks swapped out. (Not that the effect
> of vm.swap_enabled=0 is limited to
> interaction-processes.)
>
> So, the combination is now part of the
> configuration of each FreeBSD that I use.

awesome thanks Mark!  i appreciate your feedback and input, i've 
certainly learned quite a bit as well which is awesome.

i'm going to revert the diff as well when i kick off my weekly rebuild now.

-pete

-- 
Pete Wright
pete@nomadlogic.org
@nomadlogicLA


From nobody Mon May 30 05:40:10 2022
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 DC2A11B45593
	for ; Mon, 30 May 2022 05:40:23 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from pv50p00im-ztdg10021901.me.com (pv50p00im-ztdg10021901.me.com [17.58.6.55])
	(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 4LBPPy1Kmgz3hTG
	for ; Mon, 30 May 2022 05:40:22 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1653889214; bh=h3LMyKeqabGh1m+fGcbOpICWubHqrOMYWZb/876nhKY=;
	h=Content-Type:From:Mime-Version:Subject:Date:Message-Id:To;
	b=LKMgzHHh2b8hBeKCcipFpTG4331+a8sZzg87k6Hl2V8ysowQBnvIRkjPIyKM2REwK
	 jTfSh+s2hl3z1ugxAnqhhiUp4gkf0Zp2K/Gv5tvALEWFLUbVM7z2iwi6yYoDVD0hKP
	 L51ANgqUzK9kfjV++1LZHlWI/T4Fdy6vC7jw5ZiBTuGKeCnnIUn68mFS9qHRbPedSa
	 dACM1yaRQ+M0BJC/K95OssHIv9llOF4PYp+vfOk9aEWk3CE2rk0Fz8jM1raNE95A0H
	 6AZwgcrsJUa04NSxWhUt9VwG/C2+cVDXqcBB1xhwKksUWRsAHEMG+K8UN5mK6Teqnt
	 1tHCepFbOdAcg==
Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10])
	by pv50p00im-ztdg10021901.me.com (Postfix) with ESMTPSA id 8F9A681668;
	Mon, 30 May 2022 05:40:13 +0000 (UTC)
Content-Type: multipart/mixed; boundary=Apple-Mail-7FE931F7-5189-4418-A607-E88055AD556D
Content-Transfer-Encoding: 7bit
From: Toomas Soome 
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 (1.0)
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c
Date: Mon, 30 May 2022 08:40:10 +0300
Message-Id: 
References: 
Cc: Warner Losh 
In-Reply-To: 
To: current@freebsd.org
X-Mailer: iPhone Mail (19F77)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.874
 definitions=2022-05-30_01:2022-05-27,2022-05-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0
 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-2009150000 definitions=main-2205300031
X-Rspamd-Queue-Id: 4LBPPy1Kmgz3hTG
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=LKMgzHHh;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.55 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-1.73 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[me.com];
	 MV_CASE(0.50)[];
	 HAS_ATTACHMENT(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16];
	 DKIM_TRACE(0.00)[me.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.55:from];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[me.com];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[me.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.77)[-0.769];
	 R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	 FREEFALL_USER(0.00)[tsoome];
	 FROM_HAS_DN(0.00)[];
	 ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US];
	 MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	 RECEIVED_SPAMHAUS_PBL(0.00)[17.56.9.10:received];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_SPAM_LONG(0.64)[0.639];
	 MLMMJ_DEST(0.00)[current];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail-7FE931F7-5189-4418-A607-E88055AD556D
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


> On 30. May 2022, at 04:26, David Wolfskill  wrote:
>=20
> =EF=BB=BFOn Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
>> Sorry for top posting...
>>=20
>> Did you upgrade your boot blocks?
>=20
> Thanks for the reply!
>=20
> Hmmm....  Well, every time I rebuild FreeBSD head, the last step
> just after "make installworld" and before the reboot is:
>=20
> # gpart bootcode -b /boot/boot /dev/ada0s4
>=20
> So *those* get updated.
>=20
> I haven't updated from /boot/boot0 recently (and have a requirement that
> whatever is in the MBR is able to boot stable/12, stable/13, and head).
>=20
> Is updating (from head's /boot/bot0) recommended at this point?
>> ....
>=20
> (And in case it wasn't obvious, I made a silly typo in the Subject; it
> should have read:
>=20
> | Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after
> |  main-n255828-18054d0220c
>=20
> Sorry: I don't have loader messages showing up on serial console on that
> machine at this point, so I had hand-typed it from memory and managed to
> elide a letter.)
>=20

Does loader_4th have same issue?

Rgds,
Toomas=20

> Peace,
> david
> --=20
> David H. Wolfskill                              david@catwhisker.org
> "Putin is a paranoid dictator.  Putin must go. He started a senseless war
> and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshnik=
ova
>=20
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--Apple-Mail-7FE931F7-5189-4418-A607-E88055AD556D
Content-Type: application/octet-stream;
	name=signature.asc;
	x-apple-part-url=07EBC939-30FC-4EF3-9ABE-839553279FA3
Content-Disposition: attachment;
	filename=signature.asc
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYpQdK18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1LLwAPsEwuvmu+Eig+3wOkgsLbWOZifxzXFCP+d4VwlAm+IKngEA9vaMYve+e9Hn
dRshYdzDWabzhr1xNp3hhM4GN4rhgA0=
=r3I5
-----END PGP SIGNATURE-----

--Apple-Mail-7FE931F7-5189-4418-A607-E88055AD556D--

From nobody Mon May 30 07:33:13 2022
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 914571B60897
	for ; Mon, 30 May 2022 07:33:21 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic315-22.consmr.mail.ne1.yahoo.com (sonic315-22.consmr.mail.ne1.yahoo.com [66.163.190.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 4LBRwJ3g4Nz3tCS
	for ; Mon, 30 May 2022 07:33:20 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1653895993; bh=wBVMs54wCOY3ITHvIPeX0Yo/krooPvtT7ijq0jCk7PE=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=GrCj3dGOhGQvPylObks/KpFA/c19xsIPm5CCF7ZnAVHewZ7lu8mMReYOJqewblQY3YWWohOdCpf8bTkqyb/vgbIHxqFSZqVqaBUzxdPP06Huj3bkXqABCjA25b2bS1A8UCDDdX8WP64oEzINXFhL2JpmlydjE0+B4jcMuXhiOJjIhUiU+DPktTdL+zcCoHFmjw1MicgNtva2pCn2om7L+CQAikh8STou4RQ30ZLpTA/LO7VAOK3rxVyfAI3nc/XsupB4aei9lE7z4AdBnb+kqq97n2sQPKvCPcA8i8sUpxWKjctbsKlDGs+1huJrZFCsUl3Oy+QmNnygzuuc3NbQpA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1653895993; bh=E8VDuTu3syUZf/ke1XDoWkJ2PhEh8QyczwSUjvJxHUN=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=R/FTLJ1rb428wD8uOSpwr1fCwZHm8UFVjfCxZLbfTbpNGoy/0Cb6SSybOCEyBGGTD2xXiyvWjseD5Q1oefufjx0nzW5sCgRXpQ2aYTnXR5WEwVF+0k8g8RC3LUP6zjNsaVNQe3jRRPvMzSnnjFoGW8Ar1J274+5uSTcZ25KeR/dYLhTeI92boyAep0SFr94xX3H0kSJgPVWhoFcep+47zyf50Vqv6movDp87Js/iVVT6Sdo+RgaskeAIKr25ChCk8riXCUMjQYF3sFI/NDkqccf4xG9vMgDcRj5eUUtEn48/dWODbF3itObdnynBxqfaJXF25ILPab6uCiBQ2zQpyA==
X-YMail-OSG: UggU3XcVM1mxsTWu7VdvqPoAxhaYCl9Z4km.e0wHEmtrup01eCSttkxYWxbZrte
 vLehXARHOxvHywNRidpwBavT94quapZzG1gzITYJOFZ1bXAb6H6YcIRd4Wkxg464Vh9S4XYr7fiv
 2mgIjDNx6Rz2arvcwJUVOQY.vkQZikXADvDrryIs6K7DTtaj78a0pG5zzDbjcYFmSrdXE_ybFtXQ
 ojGbHPDTjNczuLgAdQL_rmGF21r0ejR9IQMCBD.2hDf9bRwh9.w.5iKtH9NPbAk.sahgdt9F8BUt
 TjnCx9tK.qDNvtRkwmAXFvm.GME1KgG7Q6qZI_cReHjmrMb9tiq7VEtBY3m8rAgRDAAufF.sGetw
 5_NIDxnqoy420qxO1A9JCxEKQjaXrzR4e9wxWjR3vXUQhxEfanUM3siQ6hhlzFr2VJgxLdBjQJFu
 _ucjc2QkniV.QORyQ_t0VDgTzg6.4DoqCk3rzLxBwtW4XIdq.OGOY6cMUX5nzr4acedI1Kbuageu
 S.1S1EZNg81gpMc5xqrtlHP.6HQmFYwuhnvPdGGLMsba6FLoZ4m3RmwaaEYwcFR7GK2b1ZQX2gKb
 yXRvu8V1zMr1qnjnepjQbMxvK4ztXKzdHy4n.7CuO4CoBvd7ZtS0cx0SxZpKWgHnHLDU0P1yei_X
 jrdPCApNhUvzfCkEZ93UpTZbnbHlLzxCyjrIpRBWyNe4TJijHcf5ieoMKPcj228x.GrwoJs1XItQ
 qvG1Zg7E6z9xvMqn_JaIlY1oe.8GsrV5Wrq6dzwDh.FWMI6838HbJwFb.EmWtSqVmCFF5egXW8qA
 Ud4yax8kGctSbscbEZCg3MiYflcuwSOsZaFBYeQgC0WocQzCiEepDWqeSFQU7OQK9IBTxkovKulI
 zgikf202y94luZtutPbqTzbx9FUKhP_lb2y3r5l14sz3Zbtd3UFmbe3SzFoz3LvoJH0bqz7TUVxN
 U52yuPPcKrlhsgWVDK94f6WwHJQKxw5SAHxTiEm4jIYj2JoSmRSDhQGVFhsxGp6iB1zSCOEgutXq
 IEmx.N7KDkR8JLNOEmZpXNDBPoR__xTr3pTpSVOx9nzrvHyMtpdlP3SdJVN6uWeX93l5N3axgdqN
 KRt13MN2ZHssrB56B7vVqNM9Ld0rxq5QuNfP3wjo3Dv0KSp5M15lrPu8xdhf64i_a1fKmas2FFQ0
 aY6.5mBZHq5EP4D79N7wwaMXJ0Yr5CU2ZWWathlM7JQNNUm09.CMVBrIjNBgz9yyWFsHI7UIWrEW
 QL.q2uNqdSfyLnE7reL8ZZwk4v4uUXp_2EChhGr4tSwSIwObcgfjKoZY_jpyWdSIrRu8EbPnQgMS
 .JjQjOEHTi6g9aYbaIC0x5e8E0xg7BU8kl265Sc1QLItjCfFqaH9vmDo18yiGJ3oIZxf0ybFheZt
 VaWTsucJtSrdsaOf.SxLc8G0618ygNPNswmqG4pKUNcZH_u2QMWsrJkUFq8Boqzr99u6g5J32zxL
 lrJUnxlbFT97yrE.AGvqUTsxiyINY4qTWfg6dRPbemv6T5fVy1WECXHf.3alSrFZbU5A_llnnp6a
 u4a8p2LhyOPlqRtHYlmyGToiTDtNNBuWOLD6MlHyifht95YCtTDPdTEjcZEvnDqvivX_8NDACfuC
 05jbcYJz.bL.Jhk1fL1RymCDA9tkZEiBMxqkBKEJK1xoWGVdfPMcg0cRIc_xrcfkOXM1wDEOz3Vj
 jeC_i8bloVpUDFGRHYw6mtS2RgwMnLn3bcUVqulfTSBPZz5ZTM6YM.AUHXRtEyCSKuHYn3koNgMo
 t7jf83Bqm0UGIm6nOSRFO.IZiwVJWmTA.tks_b_jB7JsJeAEPCgLc77APm.Ukvi5SCgi5NWbPVa.
 6TOo303RC1FLSK7LLtBKyk8AXNsXAZZw6u0mNn_BKFhlMnnGs_EWy969_fnEJgfNHQcxw1Bf.09V
 DS6S_L8XDJK4m6Gi_07CRQhNIjui5Ihk57MoQSGV8PKRBnMLZx8f9DgVTCNleKerqbsBpsOLA2uQ
 HOsA8riz9yxrOe9I83OleMFlva1uMGSuMHyeJtrU4jUvCrsmolSnGj_GQ03njBeebdsScSSzcgm9
 ZYlQv_FbYdQk3tlde5h4Ww16Cp5mpzld5De3duGwc4KJfvQUmY4oXJ62.P_Glyfl.WYWSEHFLEIb
 x_duTliblRwxFIGcBNyaCa5bSS6t0iN_hsxrplsWkjeBTWPYgo5JQc_NhzzvabHZd275dAnDTZs2
 l0w--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Mon, 30 May 2022 07:33:13 +0000
Date: Mon, 30 May 2022 07:33:13 +0000 (UTC)
From: Filippo Moretti 
To: "freebsd-current@freebsd.org" , 
	Graham Perrin 
Message-ID: <95395383.4633978.1653895993601@mail.yahoo.com>
In-Reply-To: 
References: <876713478.3758475.1653642644131.ref@mail.yahoo.com> <876713478.3758475.1653642644131@mail.yahoo.com> 
Subject: Re: Problem booting CURRENT
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_4633977_1819096010.1653895993600"
X-Mailer: WebService/1.1.20225 YMailNorrin
X-Rspamd-Queue-Id: 4LBRwJ3g4Nz3tCS
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=GrCj3dGO;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.190.148 as permitted sender) smtp.mailfrom=filippomore@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.72)[-0.719];
	 FREEMAIL_TO(0.00)[freebsd.org,gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-0.77)[-0.768];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[66.163.190.148:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_4633977_1819096010.1653895993600
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

 I did not use GELI non was the hard disk encrypted.I did try to reinstall with snapshot of May the 27th and I had the same problem:I ended up reinstalling with UFS instead.Than you 
Filippo 

    On Sunday, May 29, 2022 at 11:49:01 PM GMT+2, Graham Perrin  wrote:  
 
  On 27/05/2022 10:10, Filippo Moretti wrote:
  
 
 I run into this problem after rebboting my computer with CURRENT zfs:zroot/ROOT/default failed with error 22 the mountroot freezes and I have to power off to restart. I did not apgrade or any changes since I used it last time. Is it possible to recover my system? Filippo
   GELI encrypted?
   
------=_Part_4633977_1819096010.1653895993600
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



        
I did not use GELI non was the hard disk encrypted.I did try to reinstall with snapshot of May the 27th and I had the same problem:I ended up reinstalling with UFS instead.
Than you 
Filippo 


        
        

            

                
                

                    On Sunday, May 29, 2022 at 11:49:01 PM GMT+2, Graham Perrin <grahamperrin@gmail.com> wrote:
                

                


                


                

    
On 27/05/2022 10:10, Filippo Moretti
      wrote:

    

    

      

        
I run into this problem after
          rebboting my computer with CURRENT

        
zfs:zroot/ROOT/default failed
          with error 22

        
the mountroot freezes and I
          have to power off to restart.

        
I did not apgrade or any
          changes since I used it last time.

        
Is it possible to recover my
          system?

        
Filippo

        

      

    
    GELI encrypted?

  

            

        

------=_Part_4633977_1819096010.1653895993600--

From nobody Mon May 30 07:54:08 2022
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 1B5781B64626
	for ; Mon, 30 May 2022 07:54:18 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic316-22.consmr.mail.ne1.yahoo.com (sonic316-22.consmr.mail.ne1.yahoo.com [66.163.187.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 4LBSNT1SjGz4R3r
	for ; Mon, 30 May 2022 07:54:17 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1653897250; bh=ZfRdbdhLwt5YJtDN6oOCme4D3QFNC/bF6X3uJppI7A8=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=XtadI4qnuoI5hZoMuQGmLtZnswoPLoPTP/ioQCmoLCvjUYvIxTpfwfy64irPOoVNSuzblh1IThVJyK+RHjCHeqt6PNCYzeL0Il/FUZy2n1WYg4/MW1XYwo+q6sd2B36mPsUMowdHBo5ydFAFjKHhJuTdRAxHBpR0UUg+WnfjMVHVojoozQ74d3BtdENl17dMmql59k6oJIJRy9kzgaBkk0CnOaXtymzPYFAMbvItuT9jSdrzCyTQAvWmnT/pJDK2tQbZqkZ25UNhkbuApwxPkSyF0TkZRmISkM7JV2Tm5WeEDQAthjrZqffKl7Kw8OJowqgikg6yU524fVRXpgtWsQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1653897250; bh=qSZdq4yixDu1q3fjaR8ma41qyIl9BXsvdviYcWlWQ2X=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=ro6xzEmohPiZnprC1U2cnlaerG30CLyJcu7QYSDqOZIkpcT3gGeklBYnpgVd0JgHm5rCbDPEn5Rb5DfGnOPLgzQO49+FPMhfyhTiIqCdQsGKY1TSemPPsck+HYlBZ98RXy3pLrZAvaGT1V/YqceTjA2U/im5TeuIIju/B0GXTQz03VlYXXHX5/RrEKJ8c0VAPq3D0O59iLO0taSQ7BNHzSQvpBONiXAdVBuAnv92L/2laz8PcTU98YuJD/yI0f1z6BnfckpQ75kFUdqJZNekOt1yRCa8CDvsNqXZYtmU3ur3la96BoBpzDxea4pY/MFiQN1JI+ha0TFFFU7dAwfU+g==
X-YMail-OSG: qgXA5BQVM1k97T2nXIEvr9sNmaz0w7TlOhCK39JE8x_qdkFnYsqIqgxZTuvFR1L
 o6W9X7uwN5f9QLXXJGsNbxVENEzvN5J3c5rPqAY059rTSOx3UZM1L6GE5vqwJFKYiVkeuwhcbQnq
 A_RNxlIABFs4pCFZWrPEete9ccGGISsJRJbScp6NAiko8xf5acngjuTZTgfX6FFeYWmKMUnqkYX.
 1kWFtq943GEBuRUI73DYwGhLgjlq9W2AMGSlVG1DdcjErqneWCxPAOHv33HUyuGTHaOv4A3byl5k
 U1YaefARKj_hAMpV_OuF_SOod44qSXqayzK1SvGpmvJ7V8zrcAnKCrG.xUkZP6WrbkKzU2D4m92r
 ZUR_IfIyCqInIkoL3a4a_pfPkunGHdCRm8Xt2KUUBgo80RESBNRoGcVJC3_P1IyXR0NzneAm3KMW
 zOUcEoETMQxshBod.JZ3EWymleKI0VeDleY8Gh600P5G60VNMvegjYEE1VsTxZnbw0xy6vWDvQel
 _FoMcAnFxpOjk5Wn9x8RkhPXERhgXTef.LMfZfs5.Wfecde0BX9B32d9.TJVzVNl7.cc7TbvwjYI
 UIg932jpSRRRUjsE173aFfGkS7rWRpem2.G2b1ANwBTx0yXWwQLWIjqFpDyJ2iggAx7t2YSIomCS
 _oKiODcR1F.oB0FN_NUOti6O2zBzxcv3U1zNMR.4ni.Tc8Mly5UhvP6IKPhRNhEOqGWcytmXoQPA
 cYVNh.pJgLSFzI7vYX6CIidZ_YWyruNmZjWotpt2pcztNMVSnpGXlNWYAbEIOihajOrnpFRE3nQ.
 6r8ImS8ujGeOO1vKDCsIpWIp6R8W475UFUbrAZrqHmAEEH_ENCFITiA42037CrAB1jta3wD.NEjn
 h2sCyHInNzln3BTSWC4W890CQr0ljGlZtW.ASuTMwf6WFK5O4pvwxdU8k9mREcqZdaGociO.xeVW
 MuRlV8seDRHqPY43UpUWHOzKduZI1G7l7_Li.LiF4iNTp_KxlsbBDZTX8pHJYez9U5M0feiohHd1
 5dL4leh9YkyDuLsFpDVQHH9San.3FvP80DVacLbAnPXjhaFmATRmqYgionaUktjCdeGHyLvZCSKX
 WNGQEanu4UCZggxG2DdB9nJQuJnmLp.q3WlxwMF9_MoaAY6mdr4nLq0Y3H9UrrrUxgvkfVdlUd5n
 7QUATfiRTWLRDoH7r3b_fOj5aF354rwtu5Me1hdpN0B1bQaBySQFexIVeaAwExfOQizOzc_pB8ra
 WlYoUvDzhJxp_sq0N0gJxt.biNmI7AtESke7hYz6CaFPlc17uGoIRMqU_qYIbH.lZgqq7x5SDrck
 Dx4R8yPOkZN_6IDNLOf0aF7vkEc_ZTead7rc6F2.9xPizmQMZJZ.I4zdTTLejVIf5nRM0X_GXbY8
 PWnl_K_MLNw.WQwJ2D.iatyZMCre5Rg3wlmcTmCC2wmM53hGM1QRz4sXNS2RoEy7LnNxoXnd4eGc
 .6cs4fx7Lx4kAZ02BOI2JOXa1mAnoVO8voLAwWApp5Xm3mvGXTbT4xkt.XMatMn2DmvZIvC0U1Z_
 Qw1Pj2GiDY6gDOqBi2YWxMLQqxXt1.jLyJIc4o0Ce0R6cukaPcaFHCa_T4chFyGdZCnfirAXDMtm
 5GkH5dURVOoLMwSsY50V_KAvnMQF.a.wQavsILNQ2KXi8L2.uK8bOjkUSZpi3UeIxRN4OWkJWAo4
 0T4LoQ7pfDZ0xLw4wBYQ3ETSiZP.il20Db94rIuR0TNtbhnZg_x_tyIOznKPU3j2xEamO.r1NW1b
 keAu9aDNx46R1OZLGDxWmh1k_N9ipFpTGALpmf0t7FWIwNHEuq3mO4VGvzEqcyLhmRRZzSq4Nn87
 gho9c0CpcG1pMW7iuon725LXOchV10JXsktlMSgliX1Mgxg7fkN5UlTiYhfDlwQM.wy2kPQKh7XN
 Jlwou9MDPj.eOj1bsNE71d0eJHSxqhS0KaToVp73GrOOIgFF5sbdNmH5COB0mr8.kuYlW3T6MyOu
 kuJyK6rslYhdYSkoVNRxZxgrmsKhCmbLKt_PKBDUR1tLWijJCKzmPe1Z7jnoG5dLEoo4i1MwvGuR
 zbBF0edUxP8cGZEZtOKYU1lSK4j3XKToIevJ3c.jdoie8t2GH7Q1diHHc.UvQfzJkg8pk.tkEMHn
 ewxmuNGuD8Sgg2KAOFlI3eImyAX0lc9wPvnZ.UPle2wHQL959_vIgv2k6fRWOJTl7YDZi9yQ-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Mon, 30 May 2022 07:54:10 +0000
Date: Mon, 30 May 2022 07:54:08 +0000 (UTC)
From: Filippo Moretti 
To: "freebsd-current@freebsd.org" 
Message-ID: <1494851149.4648135.1653897248383@mail.yahoo.com>
In-Reply-To: <95395383.4633978.1653895993601@mail.yahoo.com>
References: <876713478.3758475.1653642644131.ref@mail.yahoo.com> <876713478.3758475.1653642644131@mail.yahoo.com>  <95395383.4633978.1653895993601@mail.yahoo.com>
Subject: Re: Problem booting CURRENT
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_4648134_993512589.1653897248381"
X-Mailer: WebService/1.1.20225 YMailNorrin
X-Rspamd-Queue-Id: 4LBSNT1SjGz4R3r
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=XtadI4qn;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.187.148 as permitted sender) smtp.mailfrom=filippomore@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-0.92)[-0.921];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-0.99)[-0.993];
	 RCPT_COUNT_ONE(0.00)[1];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[66.163.187.148:from];
	 NEURAL_HAM_SHORT(-0.59)[-0.587];
	 TO_DN_EQ_ADDR_ALL(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_4648134_993512589.1653897248381
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 After world I can no longer boot my system:cannot open /boot/lua/loader:no=
 such file or directory
If I try=20
load=C2=A0 /boot/kernel.old/kernel /boot/kernel/kernel
can't find /boot/kernel.old/kernel nor /boot/kernel/kernelIt is rather stra=
nge I have never found these issues before.Filippo
    On Monday, May 30, 2022 at 09:34:43 AM GMT+2, Filippo Moretti  wrote: =20
=20
  I did not use GELI non was the hard disk encrypted.I did try to reinstall=
 with snapshot of May the 27th and I had the same problem:I ended up reinst=
alling with UFS instead.Than you=20
Filippo=20

    On Sunday, May 29, 2022 at 11:49:01 PM GMT+2, Graham Perrin  wrote: =20
=20
  On 27/05/2022 10:10, Filippo Moretti wrote:
 =20
=20
 I run into this problem after rebboting my computer with CURRENT zfs:zroot=
/ROOT/default failed with error 22 the mountroot freezes and I have to powe=
r off to restart. I did not apgrade or any changes since I used it last tim=
e. Is it possible to recover my system? Filippo
   GELI encrypted?
    =20
------=_Part_4648134_993512589.1653897248381
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



        
After world I can no longer boot my system:
cannot open /boot/lua/loader:no such file or directory
If I try 
load  /boot/kernel.old/kernel /boot/kernel/kernel
can't find /boot/kernel.old/kernel nor /boot/kernel/kernel
It is rather strange I have never found these issues before.
Filippo

        
        

            

                
                

                    On Monday, May 30, 2022 at 09:34:43 AM GMT+2, Filippo Moretti <filippomore@yahoo.com> wrote:
                

                


                


                

        
I did not use GELI non was the hard disk encrypted.I did try to reinstall with snapshot of May the 27th and I had the same problem:I ended up reinstalling with UFS instead.
Than you 
Filippo 


        
        

            

                
                

                    On Sunday, May 29, 2022 at 11:49:01 PM GMT+2, Graham Perrin <grahamperrin@gmail.com> wrote:
                

                


                


                

    
On 27/05/2022 10:10, Filippo Moretti
      wrote:

    

    

      

        
I run into this problem after
          rebboting my computer with CURRENT

        
zfs:zroot/ROOT/default failed
          with error 22

        
the mountroot freezes and I
          have to power off to restart.

        
I did not apgrade or any
          changes since I used it last time.

        
Is it possible to recover my
          system?

        
Filippo

        

      

    
    GELI encrypted?

  

            

        

            

        

------=_Part_4648134_993512589.1653897248381--

From nobody Mon May 30 07:59:40 2022
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 9CF1F1B65E3A
	for ; Mon, 30 May 2022 07:59:53 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic312-25.consmr.mail.ne1.yahoo.com (sonic312-25.consmr.mail.ne1.yahoo.com [66.163.191.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 4LBSVw2mCkz4SCX
	for ; Mon, 30 May 2022 07:59:52 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1653897585; bh=hjANACgAwesWBqwYl0irAz20xiGvz9WCIBe0OChD9tQ=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=SIcOBgB9nz/U8F1ydrw96YkyiA+Uek6TLs84Wf7OwdqYF9M3nhU3RlPVYIFuHN2wA+UVjYERNzEmRH8xvKJqpODm2vw+Hq0xq5eOYrCVS8euNtN2HOqtOGrNjri3cX3ZsSIp2BOa4uD+isAmSSHbIQHj15cI4paeISDCtvWTupf9q9qx5NdypPI6lvEMSe/oKJJnrz71egLR8E7DI7RCphgfddeFUibk+1DRQFUTaU85XZZOy6HRKsD5W8+bDtmaLTquKkxOKYyuFFZIiDviJ77AJ4iO4Jw8Bn8AXoa6N50rVHUZIJOxw8tYhJpBjEnC4JcMpzbaJkQQhjGYxGPjgg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1653897585; bh=rb4K9h4hOLjwVeyxg7D2cdSok1vMxyLtxOGcBXBm5NP=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=JdyCl65LofHMkE+Ak1gd6LmtHFx2+6rZCmSwycbUFdntgV4RQGfETmwaRYaknOKQvzPfmqyqVl6diK41VlNoup0Xd6EFzL/zqezx9NrAfA5Weo3fDEHKe1Jro0mQR0ZbXPYcd8MamTdor7vMf3VNk2VYcGpeYDRv5XHqO8DFa/RAExit7tM2sFTmbdXjCzoif2NDa3bEVuO1V5ZtE33zIr9WVXlTvTI6LjPu4eS5Cgrq3ZorfdRfALw7Xawk2Nj+w8b3bXRu5J5o9QxZ//7yDFd+a2JOAG0f9eB+JUqG5dzd9krvx+IiY5NkD02QbQfhtJqSm4VB1YdNvehUiR8xtA==
X-YMail-OSG: GBAcaT8VM1laxHIy6fzR9zYCWVYQCxRqYbq1Cmw9xS86a5hcwBWGzi7eddtDzER
 uf3gr4X3psJ65ymxn_W3JyKmXdJ3ZpT42dM4kOTFkXsBvi2BigLmhOm4hbVLQf20KSb_TLZgU.QI
 ._6cUD9mG1opkGNnbDrI2VTjysXh8252ajs4AbqvPJXI498SamYcs11z2TOGuaerlP_IMrnF3Ohn
 bjCKHrcoEBNXfRwhp4_wG1l4lJTLa.PcXAspqqMEduQONd.iNaNZD5s6vnEbApapmGKzObujVtQR
 9Obfy6EcvzVx.PtEHCwCRvtvIBfHufUt7Ae64FeOHuhXqvVO7tr_jRxbOF49afenMPZZyKH_woAi
 Jp54Ho7dZtlRSk8VymVrDQ14eCVQ08udWpox4cyyoD1jgNgV7F_fTcT.Hntw.NfI_qwtkq.D00py
 ig8M72EivaWY7kgjyDsH0QUgdhgQLuCb9DzuQ_2sBXTKmZk2EHzDQnsDMo8Hd4tfKpmY6FY6axKJ
 7ydm36AD4HKDh4zrV7.Fbcio41tWHVetaZClQ5kgytGvU5bJiqqENxewy5BIrYFriapSX5cUdCaI
 DYNWSKlE007pXPxYi70i.pLjcv.khTIeV_1bR9UC3NBlafb.hywrDvE_uYNR3PSuRDMwOya4tu0r
 eaMP9wurP3L0.dJFqbmPOpi.9PHR12s48KabXLbpnxrFn20.iwq9RQdugoUnk1kfIxWaq.LYJRIX
 UcXNZxIYL9cuhLqfvHCtVssMJwkeWV7MrxCL.dKSMQmwLUP187xD.ieR4k9uMnfn0XeZV.w1VxXE
 kKJro2lgh6K.DvlT6TIbldkLvk_fn1s3mwfzghCQs.qwB4jSpxcXUzwzIfbkcSL4gj.IEP_hw7W4
 r7FAT7zWyUXWfO9OwNybjSHobshY.Unr58s2gKJzYMDo3zeBMfyfDbeM.LQFiyTD0cOwk60y_hxG
 94JdxACd30wVVFieC6OgJ_QAk6Zd63_T0TaTqx1Bb_YrzzpqWOdG6e6s1FYUyWXx5X6DU9dfqLyi
 TWzDQpBgfps59nM8gIgtPEj7_IECVRpb3__KQxCkhcL6oW2SGHHDdn33iblJvP0dqk8XGU3b.7Gn
 4xcIjqWOppmNua2nXrVi7R9JVM2kVqAeSAVHYZG6_nKMVvLQFyHK6UwQASrFoYM7A6QDmjlZr3ik
 lC9kP.8e85E7m2Fc8865ES3dtfPpmw3Rx.XEqOY5Ge1SvxnypCY1S5jMh2KbOkJMzRMYubJr1NHT
 hbDFQRdQ1D_x2yqpOpvUJW7rLHfqPnj4w10zqB1EP2CLjzhET8miWwJv0vXlRCgrBF4CLd3atST8
 doOyqFSUMT1zAchNZnwtLW2DKLyaNn5zQQZR_uzZZsJzMOIwuQvP08TTVFZmZlnylwDMSDBHASaW
 judLUsgdgLIVabQPFIILQQB7fQ9rt3H7mCj7kom5W.h99lU4s7HDrOccnbt_u1RXEwa46HntUvk5
 jZsNw4yiviCZ1eX8wCRghx9cSuQ.4DjjvcO14lHmEq5SZc.C9oNjgj2ZxMfZ635gJd7KkMSQU87_
 haauN2QpwvdpB22yOa.Fzl9SYt4bCsqF9bcE_cYGvIq_g7Z431hF9W9wTYY33Dhg_NUby8lpMYRj
 .2VM6gdhOb1shv6frb4BHg2uJZ0FvyKHQTCYS8Pxes8RPsfog2e5cyb6zMYwFWRoYUEUlAc.yPbV
 AmzqaD8_Nz5ZFvC9H43ZMy3ESAfYnC_Y54TbvWcBBlHqXkkVpAG7BbPTOzIj_nXzy8uRTl3pnXFi
 m_g504.gMqRU22szwl_sXX7w7JA6OldZmkzv518jecSOj.f6MdBDwlla4ynMgD8DOXQwbXVwK67_
 GVbzKRKppA2sbzu77KtldsuA8PnCPvPHft3mkQ935AccwO.ldJZOpeCYWsuUDHgYeWhs._qrVyYL
 sn3LkIk0Pn0S_mY4V8cYhNq8cG8.tG7mU4fbio2OnfOWEWHCE1gkfMSpbehyv0P9kvrK.FqwZL4Y
 2oMhYnnXC2A4ED8ot6Yd0czAmVMXyJQtSM0k_.1liccXFfBdTw4Udw5YLyu1h4LljDZgGMiWmS2R
 y115virR6pKd9NP0nshUWrMlSBcP6.oMK3gkxUNR.7eKtWvw.JYkK.bR1Kkzv0KeIgGhiVKozAjw
 nXq7JB1a9OeUgH7ro9BpYW4HU4th5ThGzvLeR1QpWjFTGLMrsPnEzFq_8v5lywV4-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Mon, 30 May 2022 07:59:45 +0000
Date: Mon, 30 May 2022 07:59:40 +0000 (UTC)
From: Filippo Moretti 
To: FreeBSD Current 
Message-ID: <1421847788.4116396.1653897580434@mail.yahoo.com>
In-Reply-To: 
References:  
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
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_4116395_226965274.1653897580432"
X-Mailer: WebService/1.1.20225 YMailNorrin
X-Rspamd-Queue-Id: 4LBSVw2mCkz4SCX
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=SIcOBgB9;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.191.206 as permitted sender) smtp.mailfrom=filippomore@yahoo.com
X-Spamd-Result: default: False [-3.90 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-0.94)[-0.939];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-0.96)[-0.963];
	 RCPT_COUNT_ONE(0.00)[1];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[66.163.191.206:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_4116395_226965274.1653897580432
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=20
I have the same issue after installing my custom kernel and I did not run=
=20
gpart bootcode -bIt was never needed before.FilippoIs there a way to recove=
r the system?
    On Monday, May 30, 2022 at 07:41:50 AM GMT+2, Toomas Soome  wrote: =20
=20
=20
> On 30. May 2022, at 04:26, David Wolfskill  wrote:
>=20
> =EF=BB=BFOn Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
>> Sorry for top posting...
>>=20
>> Did you upgrade your boot blocks?
>=20
> Thanks for the reply!
>=20
> Hmmm....=C2=A0 Well, every time I rebuild FreeBSD head, the last step
> just after "make installworld" and before the reboot is:
>=20
> # gpart bootcode -b /boot/boot /dev/ada0s4
>=20
> So *those* get updated.
>=20
> I haven't updated from /boot/boot0 recently (and have a requirement that
> whatever is in the MBR is able to boot stable/12, stable/13, and head).
>=20
> Is updating (from head's /boot/bot0) recommended at this point?
>> ....
>=20
> (And in case it wasn't obvious, I made a silly typo in the Subject; it
> should have read:
>=20
> | Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after
> |=C2=A0 main-n255828-18054d0220c
>=20
> Sorry: I don't have loader messages showing up on serial console on that
> machine at this point, so I had hand-typed it from memory and managed to
> elide a letter.)
>=20

Does loader_4th have same issue?

Rgds,
Toomas=20

> Peace,
> david
> --=20
> David H. Wolfskill=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 david@catwhisker.org
> "Putin is a paranoid dictator.=C2=A0 Putin must go. He started a senseles=
s war
> and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshni=
kova
>=20
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
 =20
------=_Part_4116395_226965274.1653897580432
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



        

I have the sa=
me issue after installing my custom kernel and I did not run 
gpart bootcode -b
It was never needed before.
Filippo
Is t=
here a way to recover the system?

       =20
        

            

               =20
                

                    On Monday, May 30, 2022 at 07:41:50 AM GMT+2, Toomas So=
ome <tsoome@me.com> wrote:
                

                


                


                

> On 30. May 20=
22, at 04:26, David Wolfskill <david@catwhisker.org<=
/a>> wrote:
> 
> =EF=BB=BFOn S=
un, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
=
>> Sorry for top posting...
>> 
>> Did you upgrade your boot blocks?
> 
> Thanks for the reply!
> 
> Hmmm....  Well, every time I rebuild FreeBSD head, the =
last step
> just after "make installworld" and before =
the reboot is:
> 
> # gpart bootc=
ode -b /boot/boot /dev/ada0s4
> 
>=
; So *those* get updated.
> 
> I =
haven't updated from /boot/boot0 recently (and have a requirement that
> whatever is in the MBR is able to boot stable/12, stable=
/13, and head).
> 
> Is updating =
(from head's /boot/bot0) recommended at this point?
>&=
gt; ....
> 
> (And in case it was=
n't obvious, I made a silly typo in the Subject; it
> =
should have read:
> 
> | Subject:=
 Re: Loader can't find /boot/lua/loader.lua on UFS after
=
> |  main-n255828-18054d0220c
> 
> Sorry: I don't have loader messages showing up on serial console =
on that
> machine at this point, so I had hand-typed i=
t from memory and managed to
> elide a letter.)
> 

Does loader_4th have=
 same issue?

Rgds,
T=
oomas 

> Peace,
> david
=
> -- 
> David H. Wolfskill      &nbs=
p;                     &n=
bsp; david@catwhisker.org
> "P=
utin is a paranoid dictator.  Putin must go. He started a senseless wa=
r
> and is leading Russia into a ditch." - Egor Polyak=
ov & Alexandra Miroshnikova
> 
&=
gt; See https://www.catwhisker.org/~david/publickey.gpg =
for my public key.

            

        

------=_Part_4116395_226965274.1653897580432--

From nobody Mon May 30 10:26:45 2022
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 C66991B60656
	for ; Mon, 30 May 2022 10:26:49 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBWmS4zGgz4lLG
	for ; Mon, 30 May 2022 10:26:48 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 24UAQjtm013649;
	Mon, 30 May 2022 10:26:45 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 24UAQjK5013648;
	Mon, 30 May 2022 03:26:45 -0700 (PDT)
	(envelope-from david)
Date: Mon, 30 May 2022 03:26:45 -0700
From: David Wolfskill 
To: Toomas Soome 
Cc: current@freebsd.org, Warner Losh 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
Message-ID: 
Mail-Followup-To: David Wolfskill ,
	Toomas Soome , current@freebsd.org,
	Warner Losh 
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-sha512;
	protocol="application/pgp-signature"; boundary="fIilQ7nizqqcrJ7x"
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4LBWmS4zGgz4lLG
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-5.38 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[david];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 DMARC_NA(0.00)[catwhisker.org];
	 NEURAL_HAM_LONG(-1.00)[-0.998];
	 SIGNED_PGP(-2.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.985];
	 MLMMJ_DEST(0.00)[current];
	 FREEMAIL_TO(0.00)[me.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


--fIilQ7nizqqcrJ7x
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> ...=20
> Does loader_4th have same issue?
> ....

I don't know; I hadn't tried it.  I will do so later today & report
back.

Thanks!

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshniko=
va

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--fIilQ7nizqqcrJ7x
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYpSb5V8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1O+eAQCLltulPZbE3RZuurYWFssCwQZRmkFhmyMtLB9riIIBZwD+M3I8uRhzn3JD
wMZSkqaxMt3AFngg9Owwmlusn914Vgw=
=obGr
-----END PGP SIGNATURE-----

--fIilQ7nizqqcrJ7x--

From nobody Mon May 30 10:32:45 2022
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 4AC411B62513
	for ; Mon, 30 May 2022 10:32:55 +0000 (UTC)
	(envelope-from jbtakk@iherebuywisely.com)
Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [IPv6:2a0c:5a00:149::25])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBWvV3hr5z4mmN
	for ; Mon, 30 May 2022 10:32:54 +0000 (UTC)
	(envelope-from jbtakk@iherebuywisely.com)
Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com)
	by mailtransmit04.runbox.com with esmtps  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.93)
	(envelope-from )
	id 1nvcha-005XCu-6I
	for current@freebsd.org; Mon, 30 May 2022 12:32:46 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=iherebuywisely.com; s=selector2; h=Message-Id:In-Reply-To:Date:Subject:To:
	From:MIME-Version:Content-Transfer-Encoding:Content-Type;
	bh=GUbjDxwEvKFed0YMCf/7N2jYb+7NdVQxms8xwRfhnGg=; b=Xxt2JJEParYbgNjUj0PPSEM/oW
	sauh05/OotFHyCrDYY1xzYnBK/0Z9BDYRS+Mbvn71qo4OEEsbu3GtPfIAxcvRP9SytfR6YowcdrRS
	WBLg2n2lRgNgGukWkNU0iUMiYFuXghOZsQyKi6fo1iABDyQdXbk6imI0n31EDYZx4muZmbcB+own1
	opp0jK7vvawP5zuUFwBCstUtao384viY3YOgku0id9Q8xNBlfe/VGMZ5wTNmYcVl4kEmBXErVYT3L
	P4qM6iG9MbRDK78qfKfFJydluCT0fXVevrKuVTNYY4fa1VF6cDV4YUPixyj32ecE92qVDsptTHyWH
	gBaoXSdg==;
Received: from [10.9.9.127] (helo=rmmprod05.runbox)
	by mailtransmit02.runbox with esmtp (Exim 4.86_2)
	(envelope-from )
	id 1nvchZ-0000VH-Qk
	for current@freebsd.org; Mon, 30 May 2022 12:32:45 +0200
Received: from mail by rmmprod05.runbox with local (Exim 4.86_2)
	(envelope-from )
	id 1nvchZ-0003E5-PV
	for current@freebsd.org; Mon, 30 May 2022 12:32:45 +0200
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
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
Received: from [Authenticated alias (650894)] by runbox.com with http
 (RMM6); for ; Mon, 30 May 2022 10:32:45 GMT
From: "Jeffrey Bouquet" 
To: "current" 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
Date: Mon, 30 May 2022 03:32:45 -0700 (PDT)
X-RMM-Aliasid: 650894
X-Mailer: RMM6
In-Reply-To: 
Message-Id: 
X-Rspamd-Queue-Id: 4LBWvV3hr5z4mmN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none ("invalid DKIM record") header.d=iherebuywisely.com header.s=selector2 header.b=Xxt2JJEP;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of jbtakk@iherebuywisely.com designates 2a0c:5a00:149::25 as permitted sender) smtp.mailfrom=jbtakk@iherebuywisely.com
X-Spamd-Result: default: False [-3.39 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 RCVD_COUNT_FIVE(0.00)[5];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a0c:5a00:149::25];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 DMARC_NA(0.00)[iherebuywisely.com];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-0.99)[-0.993];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[iherebuywisely.com:~];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 R_DKIM_PERMFAIL(0.00)[iherebuywisely.com:s=selector2];
	 MLMMJ_DEST(0.00)[current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:50304, ipnet:2a0c:5a00::/29, country:NO];
	 RCVD_IN_DNSWL_LOW(-0.10)[2a0c:5a00:149::25:from]
X-ThisMailContainsUnwantedMimeParts: N



On Sun, 29 May 2022 18:26:03 -0700, David Wolfskill  =
wrote:

> On Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
> > Sorry for top posting...
> >=20
> > Did you upgrade your boot blocks?
>=20
> Thanks for the reply!
>=20
> Hmmm....  Well, every time I rebuild FreeBSD head, the last step
> just after "make installworld" and before the reboot is:
>=20
> # gpart bootcode -b /boot/boot /dev/ada0s4
>=20
> So *those* get updated.
>=20
> I haven't updated from /boot/boot0 recently (and have a requirement that
> whatever is in the MBR is able to boot stable/12, stable/13, and head).
>=20
> Is updating (from head's /boot/bot0) recommended at this point?
> > ....
>=20
> (And in case it wasn't obvious, I made a silly typo in the Subject; it
> should have read:
>=20
> | Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after
> |  main-n255828-18054d0220c
>=20
> Sorry: I don't have loader messages showing up on serial console on that
> machine at this point, so I had hand-typed it from memory and managed to
> elide a letter.)
>=20
> Peace,
> david
> --=20
> David H. Wolfskill                              david@catwhisker.org
> "Putin is a paranoid dictator.  Putin must go. He started a senseless war
> and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshni=
kova
>=20
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.


I've never heard of that. Why isnt it in UPDATING?=20=

From nobody Mon May 30 12:15:54 2022
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 94A8317F3E3B
	for ; Mon, 30 May 2022 12:15:59 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBZBQ2FKhz3DCd
	for ; Mon, 30 May 2022 12:15:58 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 24UCFsa6015825;
	Mon, 30 May 2022 12:15:54 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 24UCFspb015824;
	Mon, 30 May 2022 05:15:54 -0700 (PDT)
	(envelope-from david)
Date: Mon, 30 May 2022 05:15:54 -0700
From: David Wolfskill 
To: Toomas Soome , current@freebsd.org,
        Warner Losh 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
Message-ID: 
Reply-To: current@freebsd.org
Mail-Followup-To: current@freebsd.org, Toomas Soome ,
	Warner Losh 
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-sha512;
	protocol="application/pgp-signature"; boundary="72uTwMwN1wRLPBu4"
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4LBZBQ2FKhz3DCd
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-5.28 / 15.00];
	 ARC_NA(0.00)[];
	 HAS_REPLYTO(0.00)[current@freebsd.org];
	 FREEFALL_USER(0.00)[david];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c];
	 NEURAL_HAM_LONG(-0.89)[-0.893];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
	 DMARC_NA(0.00)[catwhisker.org];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-0.99)[-0.990];
	 SIGNED_PGP(-2.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 MLMMJ_DEST(0.00)[current];
	 FREEMAIL_TO(0.00)[me.com,freebsd.org,bsdimp.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--72uTwMwN1wRLPBu4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 30, 2022 at 03:26:45AM -0700, David Wolfskill wrote:
> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> > ...=20
> > Does loader_4th have same issue?
> > ....
>=20
> I don't know; I hadn't tried it.  I will do so later today & report
> back.
> ....

After updating sources from main-n255867-245b056556e to
main-n255871-7468332f551, the behavior with the Lua loader was the same:
it whined that it couldn't find /boot/lua/loader.lua, claiming "No such
file or directory" and it had not loaded anything.

I rebooted from one of the stabe/* slices and removed "loader"
and "zfsloader," then made them (hard) links to loader_4th.

On reboot, the (Forth) loader whined that it couldn't load "kernel" --
and as was the case with the Lua loader, it had not loaded anything.

So while the messages were a little different, the aspect of the
behavior that the loader was unable to load anything -- apparently
because it was unable to find anything to load -- remains quite similar,
AFAICT.

I had (as mentioned yesterday) run a manual "fsck" on the head / and
/usr file systems.  fsck asked me if I wanted to "ADD SUPERBLOCK
CHECK-HASH PROTECTION"; after a bit of dithering on my part, I told it
"yes."

I should also mention that the file systems are UFS+SU -- and not
(e.g.), UFS+SUJ.

Finally, I remind folks that I am not seeing this at all on the laptops
-- they Just Work (as usual).

Thanks again for spending time on this!

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshniko=
va

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--72uTwMwN1wRLPBu4
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYpS1el8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1EgIAP4rGidXXNK2aZHU68g6rFclSOjJ5LfSf2wRejt4KWCi5wEAvhgZmXHiaM3O
vruQvWyQ7nzzE3A2TBBFU/X5VJ9TSwU=
=9PiU
-----END PGP SIGNATURE-----

--72uTwMwN1wRLPBu4--

From nobody Mon May 30 12:16:57 2022
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 6D3D217F52FD
	for ; Mon, 30 May 2022 12:17:00 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBZCb3HyXz3F4k
	for ; Mon, 30 May 2022 12:16:59 +0000 (UTC)
	(envelope-from agh@riseup.net)
Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83])
	(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
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.riseup.net", Issuer "R3" (not verified))
	by mx0.riseup.net (Postfix) with ESMTPS id 4LBZCY6RrFz9spW;
	Mon, 30 May 2022 05:16:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
	t=1653913017; bh=umz2Mc8pMRaZlKa4JPTsLWDfVvaDeJiM0X3YJaLYfiw=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=XJ2OG4Hb9ISgV7Pc3AwTgJZ8ZjVw2JC73qFxVwBWgoYVNdB5GxyXQn84uIeNI97AE
	 6+8YBf+exeq/YF6uENh6omMGW9ULYUi8lIg0CubIKywYc6rmI5H6M2I/o0ABUwLIAa
	 y0qnL/ctybu9vJIYVDZjLp0kVw3Mn8DQ3t0BUAhI=
X-Riseup-User-ID: C1AC14410D01902F6CEEF95FCDC2D7F99A99AA4E5F7D80851C2E82E7A8256B73
Received: from [127.0.0.1] (localhost [127.0.0.1])
	 by fews1.riseup.net (Postfix) with ESMTPSA id 4LBZCY5LBKz5xgp;
	Mon, 30 May 2022 05:16:57 -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
Date: Mon, 30 May 2022 05:16:57 -0700
From: Alastair Hogge 
To: current@freebsd.org
Cc: David Wolfskill 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
In-Reply-To: 
References: 
Message-ID: <06ba3be54117e4feb8f250756b25c1c5@riseup.net>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LBZCb3HyXz3F4k
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=riseup.net header.s=squak header.b=XJ2OG4Hb;
	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
X-Spamd-Result: default: False [-4.10 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[riseup.net:s=squak];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mx0.riseup.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DWL_DNSWL_NONE(0.00)[riseup.net:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[riseup.net:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[riseup.net,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.6:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-05-30 07:10, David Wolfskill wrote:
> -- but only on one machine (of the 3 that I use for daily tracking head
> (and stable/12 & stable/13) -- the build machine ("freebeast").
> 
> Each is amd64, using ... venerable ... BIOS/MBR & UFS -- stuff that has
> generally been functionally stable for the last couple of decades.
> 
> So for yesterday and today, I've moved the new loader aside and copied
> the one from Friday, which works just fine.
> 
> The build machine ("freebeast") uses a GENERIC kernel; the other 2 are
> laptops, and use a kernel that includes GENERIC, then tweaks things a
> bit (e.g., dropping support for tape drives; adding IPFIREWALL and
> explicitly NOT setting IPFIREWALL_DEFAULT_TO_ACCEPT; adding sound stuff).
> 
> Info on the update history & copies of stuff like most recent
> (verbosely-booted) dmesg.boot should be available at
> https://www.catwhisker.org/~david/FreeBSD/history/ (and if you can't get
> through, please send a note to dhw@freebsd.org and I'll do what I can to
> fix it).
> 
> (Of the 2 laptops, I only have the one that I actuaqlly use in
> day-to-day work represented.)
> 
> (I note that to recover, I boot from one the stable/* slices, move the
> "head" slice's files around, then reboot from the "head" slice.)
> 
> AFAICT, there were no changes to stand/* since main-n255828-18054d0220c,
> though yesterday (main-n255828-18054d0220c -> main-n255840-9cb70cb4769),
> there were some changes to sys/ufs/ffs/ffs_subr.c (from
> main-n255835-076002f24d35:

Hey David,

I have not been able to use a new /boot/loader.efi (following -CURRENT)
since 
mid to late 2021, and your symptoms look the same; fortunately, I found
bug 
report 264282[0] last night, which I think is related. Yamagi has
already done 
the investigation, and found a possible cause. For the time being, in
the case 
of a GELI backed UFS mount, after GELI decrypts the mount, one has to
manually 
set currdev back to the correct disk.

0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282
--
To health and anarchy.
Alastair

From nobody Mon May 30 12:20:28 2022
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 1896817F703E
	for ; Mon, 30 May 2022 12:20:31 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBZHf0rxtz3HLK
	for ; Mon, 30 May 2022 12:20:30 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 24UCKS2E016044;
	Mon, 30 May 2022 12:20:28 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 24UCKSkq016043;
	Mon, 30 May 2022 05:20:28 -0700 (PDT)
	(envelope-from david)
Date: Mon, 30 May 2022 05:20:28 -0700
From: David Wolfskill 
To: Alastair Hogge 
Cc: current@freebsd.org
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
Message-ID: 
Mail-Followup-To: David Wolfskill ,
	Alastair Hogge , current@freebsd.org
References: 
 <06ba3be54117e4feb8f250756b25c1c5@riseup.net>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="82NxFylC5fpDiYmz"
Content-Disposition: inline
In-Reply-To: <06ba3be54117e4feb8f250756b25c1c5@riseup.net>
X-Rspamd-Queue-Id: 4LBZHf0rxtz3HLK
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-5.40 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FREEFALL_USER(0.00)[david];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 DMARC_NA(0.00)[catwhisker.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[current];
	 SIGNED_PGP(-2.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


--82NxFylC5fpDiYmz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 30, 2022 at 05:16:57AM -0700, Alastair Hogge wrote:
> ...
> I have not been able to use a new /boot/loader.efi (following -CURRENT)
> since=20
> mid to late 2021, and your symptoms look the same; fortunately, I found
> bug=20
> report 264282[0] last night, which I think is related. Yamagi has
> already done=20
> the investigation, and found a possible cause. For the time being, in
> the case=20
> of a GELI backed UFS mount, after GELI decrypts the mount, one has to
> manually=20
> set currdev back to the correct disk.
>=20
> 0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264282
> ....

Thanks!  I'll take a look -- though I am not using GELI-encryption on
anything needed up to the transition to multi-user mode (except for
swap).

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshniko=
va

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--82NxFylC5fpDiYmz
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYpS2jF8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1Bt1AP9E14P0bIAWfqff6B8B4yYeUsvlngvsRpqZBMSkOfH+EgD+LCYjF6BEtMwQ
gn9v92KpCgLBOM/S2Rj1De+UQNy6AQ0=
=+kRa
-----END PGP SIGNATURE-----

--82NxFylC5fpDiYmz--

From nobody Mon May 30 12:38:27 2022
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 06E881B43FA3
	for ; Mon, 30 May 2022 12:38:30 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBZhN6mnfz3LdK
	for ; Mon, 30 May 2022 12:38:28 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 24UCcRZ2016170;
	Mon, 30 May 2022 12:38:27 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 24UCcR1c016169;
	Mon, 30 May 2022 05:38:27 -0700 (PDT)
	(envelope-from david)
Date: Mon, 30 May 2022 05:38:27 -0700
From: David Wolfskill 
To: Alastair Hogge 
Cc: current@freebsd.org
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
Message-ID: 
Reply-To: current@freebsd.org
Mail-Followup-To: current@freebsd.org, Alastair Hogge 
References: 
 <06ba3be54117e4feb8f250756b25c1c5@riseup.net>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="+Ri6lU6BJRP8prAJ"
Content-Disposition: inline
In-Reply-To: <06ba3be54117e4feb8f250756b25c1c5@riseup.net>
X-Rspamd-Queue-Id: 4LBZhN6mnfz3LdK
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-3.47 / 15.00];
	 ARC_NA(0.00)[];
	 HAS_REPLYTO(0.00)[current@freebsd.org];
	 FREEFALL_USER(0.00)[david];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c];
	 NEURAL_HAM_LONG(-0.99)[-0.992];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
	 DMARC_NA(0.00)[catwhisker.org];
	 NEURAL_SPAM_SHORT(0.92)[0.923];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[current];
	 SIGNED_PGP(-2.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--+Ri6lU6BJRP8prAJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 30, 2022 at 05:16:57AM -0700, Alastair Hogge wrote:
> ...
> I have not been able to use a new /boot/loader.efi (following -CURRENT)
> since=20
> mid to late 2021, and your symptoms look the same; fortunately, I found
> bug=20
> report 264282[0] last night, which I think is related. Yamagi has
> already done=20
> the investigation, and found a possible cause. For the time being, in
> the case=20
> of a GELI backed UFS mount, after GELI decrypts the mount, one has to
> manually=20
> set currdev back to the correct disk.
>=20
> 0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264282
> ....

I (just) checked; after switching back to the Lua loader, the currdev
variable is set to "disk0s4a:", which is correct for my case.

Trying loader's "lsdev" command shows the expected disks, slices, and
partitions, correctly identified as FreeBSD UFS, swap, or ZFS.

Trying to (e.g.) "ls disk0s4a:" fails, saying that it can't find /.

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshniko=
va

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--+Ri6lU6BJRP8prAJ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYpS6wl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1D4uAP0bDJQa7bF5vQKnAZ800AHFQ3hbPDr8eEADwfsjHmYFjwD/Z6yVuiZZFnhu
zyM5GZI5zKetVHb6iANDV5kEv7bvSQ8=
=RncQ
-----END PGP SIGNATURE-----

--+Ri6lU6BJRP8prAJ--

From nobody Mon May 30 14:03:09 2022
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 A396B1B53607
	for ; Mon, 30 May 2022 14:03:22 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBcZK023Wz3lK9
	for ; Mon, 30 May 2022 14:03:21 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe2d.google.com with SMTP id j7so10894290vsj.7
        for ; Mon, 30 May 2022 07:03:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=7jQKCDzT6R817IeRPqkWmRQSqOeMUP/egLmfFy4BWnU=;
        b=vZkorZz+WZ5by6yoFqiyPAzYDYL+DVzsyHzVAGIllByw1XHGSdVXts5bJSUxOS7K3o
         7dZt4MC4x7qF3yE8PfAn0Xu7eJnub0t1P1T1NkDa1t1FxTZLtCS4QvxE4f/zpEEVwzmF
         BSwMTby6vLawCkhgNyIwv7+r7sS4pZ8VQfWraZCz5zzWb4uB+x+c/gk+igaHSyUCVgbD
         ZbIyUm41mKV24cdE4cJJWxpbwK0wvCPdVs/yHpq/oNMKpkRFzDhrbY+moMr1yDrsamct
         iXlUAN3tMME6sK/1kVLA5IkloUIZGsXbJUvEcfH9E35SayeYSlWrqGg6VNAzORA9CL0s
         2eVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=7jQKCDzT6R817IeRPqkWmRQSqOeMUP/egLmfFy4BWnU=;
        b=3Pt3ooOJU6Tt6fAywPYiIMD7BYyj/Fw0zy9yMGgUEHfRXqJRnkruEPJjBq1cjx6afc
         fnS96xMYYeFy74ZKmtoN/He4ejPHxKbtkBVUAcvdnC9O4s8U840pi5iBhNMPHMbU3nyO
         W0EaGuKeRMrtGiyTBEUSj33WEMxW2NfexJuSz0Ku8GmV2VJ+i2E6mKgQxvAsM/103cYl
         ksu0flNVeSp7SyONgN8rPXzJFpc7BYAAiiFswqBN50ok9+HNCmGk0u5X+tyzXKPGtWAH
         vGteFdLchnhYDNPFGktSSWFGVoEOQK0M93aoIluwZLdSyirQj129p4QBcEHwp+f6sw5V
         iQQg==
X-Gm-Message-State: AOAM531ghdabxRHvuSrGSyj112EDJevQdpuyUe+5mhzHjoYmVZlIFspA
	VoczmCJA+/6vdfsaSEqcggYVdJdE+YSIj6pjrkgtckOeFXE=
X-Google-Smtp-Source: ABdhPJwBboSOkRrZIkg3fWDQs0cJuljOS2kbZUoc3meue97AFqKsghrq+Nf1ba6tFPl72MoLUYlUAViBrroKUeWBMtQ=
X-Received: by 2002:a67:e01b:0:b0:337:9729:acc2 with SMTP id
 c27-20020a67e01b000000b003379729acc2mr17543277vsl.10.1653919400409; Mon, 30
 May 2022 07:03:20 -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, 30 May 2022 08:03:09 -0600
Message-ID: 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c
To: Jeffrey Bouquet 
Cc: current 
Content-Type: multipart/alternative; boundary="00000000000059508005e03b1ee2"
X-Rspamd-Queue-Id: 4LBcZK023Wz3lK9
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=vZkorZz+;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2d) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2d:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000059508005e03b1ee2
Content-Type: text/plain; charset="UTF-8"

On Mon, May 30, 2022 at 4:33 AM Jeffrey Bouquet 
wrote:

>
>
> On Sun, 29 May 2022 18:26:03 -0700, David Wolfskill 
> wrote:
>
> > On Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:
> > > Sorry for top posting...
> > >
> > > Did you upgrade your boot blocks?
> >
> > Thanks for the reply!
> >
> > Hmmm....  Well, every time I rebuild FreeBSD head, the last step
> > just after "make installworld" and before the reboot is:
> >
> > # gpart bootcode -b /boot/boot /dev/ada0s4
> >
> > So *those* get updated.
> >
> > I haven't updated from /boot/boot0 recently (and have a requirement that
> > whatever is in the MBR is able to boot stable/12, stable/13, and head).
> >
> > Is updating (from head's /boot/bot0) recommended at this point?
> > > ....
> >
> > (And in case it wasn't obvious, I made a silly typo in the Subject; it
> > should have read:
> >
> > | Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after
> > |  main-n255828-18054d0220c
> >
> > Sorry: I don't have loader messages showing up on serial console on that
> > machine at this point, so I had hand-typed it from memory and managed to
> > elide a letter.)
> >
> > Peace,
> > david
> > --
> > David H. Wolfskill                              david@catwhisker.org
> > "Putin is a paranoid dictator.  Putin must go. He started a senseless war
> > and is leading Russia into a ditch." - Egor Polyakov & Alexandra
> Miroshnikova
> >
> > See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>
>
> I've never heard of that. Why isnt it in UPDATING?


Re updating boot blocks: It's not a requirement. It's a diagnostic question
to see what code we're dealing with.
The only time it's been required was the ZFS update to OpenZFS after a
zpool upgrade because the latter
introduced new features the old boot blocks would reject as being a valid
ZFS that it recognized.

Warner

--00000000000059508005e03b1ee2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, May 30, 2022 at 4:33 AM Jeffr=
ey Bouquet <jbtakk@iherebuy=
wisely.com> wrote:




On Sun, 29 May 2022 18:26:03 -0700, David Wolfskill <david@catwhisker.org> wrote:<=
br>


> On Sun, May 29, 2022 at 06:59:34PM -0600, Warner Losh wrote:

> > Sorry for top posting...

> > 

> > Did you upgrade your boot blocks?

> 

> Thanks for the reply!

> 

> Hmmm....=C2=A0 Well, every time I rebuild FreeBSD head, the last step<=
br>
> just after "make installworld" and before the reboot is:

> 

> # gpart bootcode -b /boot/boot /dev/ada0s4

> 

> So *those* get updated.

> 

> I haven't updated from /boot/boot0 recently (and have a requiremen=
t that

> whatever is in the MBR is able to boot stable/12, stable/13, and head)=
.

> 

> Is updating (from head's /boot/bot0) recommended at this point?
> > ....

> 

> (And in case it wasn't obvious, I made a silly typo in the Subject=
; it

> should have read:

> 

> | Subject: Re: Loader can't find /boot/lua/loader.lua on UFS after=


> |=C2=A0 main-n255828-18054d0220c

> 

> Sorry: I don't have loader messages showing up on serial console o=
n that

> machine at this point, so I had hand-typed it from memory and managed =
to

> elide a letter.)

> 

> Peace,

> david

> -- 

> David H. Wolfskill=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 david@catwhisker.org

> "Putin is a paranoid dictator.=C2=A0 Putin must go. He started a =
senseless war

> and is leading Russia into a ditch." - Egor Polyakov & Alexan=
dra Miroshnikova

> 

> See https://www.catwhisker.org/~david/publickey.=
gpg for my public key.





I've never heard of that. Why isnt it in UPDATING?
Re updating boot blocks: It's not a requirement. It's a=
 diagnostic question to see what code we're dealing with.
The=
 only time it's been required was the ZFS update to OpenZFS after a zpo=
ol upgrade because the latter
introduced new features the old boo=
t blocks would reject as being a valid ZFS that it recognized.
Warner=C2=A0


--00000000000059508005e03b1ee2--

From nobody Mon May 30 14:06:32 2022
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 1F8B31B549A7
	for ; Mon, 30 May 2022 14:06:50 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBcfK2F9Zz3mmq
	for ; Mon, 30 May 2022 14:06:49 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe32.google.com with SMTP id z6so10947007vsp.0
        for ; Mon, 30 May 2022 07:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=lOBLt3YBMC5XTWdJSq8B4nPOKB8aIDDqzHOjq1dvzdA=;
        b=yuB8OszjPsJqY01lr/fjKbRfvFHCxUbgZnBAbC+soCzY+XWDO+i4g4430DZJ92XWXK
         Y0IQ62MiNeLnJzFIetyO3/DkNfdAa/xLDmSD9HhZ0/1Ue+C9kVzGkHBBFCxl4rxYSIaa
         5axO2ZhqTHQhmizgEcusadq8bkfb1hLDEG7xPixRPbsEbGuyhrpGf+VHxn8xFutGAKsh
         k1yv+sFvOn+jQrw045ZAHh6g0LbKtFP+WU9cc0V4KbyLsoyIqb+h6NbBZJ3T1Z2sLBPv
         OzvF9lD5AamdizzaTvGOp8ZLFDSqPyl2Gn+iMM2raz/xU9EEg+7VfAZAXaXVOoMy2dDO
         h+zA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=lOBLt3YBMC5XTWdJSq8B4nPOKB8aIDDqzHOjq1dvzdA=;
        b=Or3bkvIBQtc2QsOzUbFqo3WR4pe+dH5aDCk/OoGku1oxYvgeDsd3n+JAxIGSEihvPB
         d53eS93Tngsi07I2c7h3epSbMJ9xfMOWXXYRBi2F2sNB6pcp6RIL+r+yzBQkQ2IlVxXH
         d3hjno5LsC1d8QgYPMV6qnvmaDzqYay0jfK0yNjzgGfPHkj2RCfx8FHlCjtm6NL+CO2+
         epzX57aKzQnqMJPSWXhrr7lklt5Wy15/k0Xz5u0zVdCsFDuwRSJE/7qx4BX+aa/tHaXT
         tMiBKX+kf++2GTV/j1RbmTVgMSYOIfVDVTxP27Zv3u9afhxnfDrWP029NNcooaMUBjVR
         1Flg==
X-Gm-Message-State: AOAM531riFqOG/fNXqe6pPlfF5Z/EI6/gvRbYCtX5++OdLdK2rkz9M/U
	E5Dmr+zFFfZAM8GRi2vCIcox/DXRCeYvoKc8/bMMGb4WDI8=
X-Google-Smtp-Source: ABdhPJwoGOk36kzyLmrs63iT7CcCULMBeIxNBGBwGcklUjiT4AneAMyluGI6kJq6VFAah66GTNb540Ir2/t/2ASbaO8=
X-Received: by 2002:a05:6102:3054:b0:337:cd32:c39e with SMTP id
 w20-20020a056102305400b00337cd32c39emr13771786vsa.59.1653919603120; Mon, 30
 May 2022 07:06:43 -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, 30 May 2022 08:06:32 -0600
Message-ID: 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c
To: David Wolfskill , Toomas Soome , 
	FreeBSD Current , Warner Losh 
Content-Type: multipart/alternative; boundary="0000000000006e6ed905e03b2acb"
X-Rspamd-Queue-Id: 4LBcfK2F9Zz3mmq
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=yuB8Oszj;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e32) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.86 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.86)[-0.864];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-0.998];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e32:from];
	 MLMMJ_DEST(0.00)[current];
	 FREEMAIL_TO(0.00)[catwhisker.org,me.com,freebsd.org,bsdimp.com];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000006e6ed905e03b2acb
Content-Type: text/plain; charset="UTF-8"

On Mon, May 30, 2022 at 4:26 AM David Wolfskill 
wrote:

> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> > ...
> > Does loader_4th have same issue?
> > ....
>
> I don't know; I hadn't tried it.  I will do so later today & report
> back.
>

So if it's only one system, and it's only UFS, then what does fsck of that
UFS system tell you?
The loader can't find its UFS filesystem to read the configuration from. So
either its having trouble
finding the device (unlikely since that code hasn't changed in a long
time), or its having heartburn
with the UFS system for some reason it's being silent about (within the
realm of possibilities because
there might be an unknown edge case in Kirks recent  UFS integrity
changes). I suspect that the 4th
boot loader will have the same issue, but a different error message.

Others have reported issues with GELI, but that's not in play here, If I'm
reading this correctly. Right?

Warner

--0000000000006e6ed905e03b2acb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, May 30, 2022 at 4:26 AM David=
 Wolfskill <david@catwhisker.org=
> wrote:
=
On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:

> ... 

> Does loader_4th have same issue?

> ....



I don't know; I hadn't tried it.=C2=A0 I will do so later today &am=
p; report

back.

So if it's only one system, a=
nd it's only UFS, then what does fsck of that UFS system tell you?
The loader can't find its UFS filesystem to read the configuratio=
n from. So either its having trouble
finding the device (unlikely=
 since that code hasn't changed in a long time), or its having heartbur=
n
with the UFS system for some reason it's being silent about=
 (within the realm of possibilities because
there might be an unk=
nown edge case in Kirks recent=C2=A0 UFS integrity changes). I suspect that=
 the 4th
boot loader will have the same issue, but a differen=
t=C2=A0error message.

Others have reported issues =
with GELI, but that's not in play here, If I'm reading this correct=
ly. Right?

Warner


--0000000000006e6ed905e03b2acb--

From nobody Mon May 30 14:14:25 2022
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 7E4131B56C35
	for ; Mon, 30 May 2022 14:14:43 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from pv50p00im-ztdg10021801.me.com (pv50p00im-ztdg10021801.me.com [17.58.6.56])
	(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 4LBcqQ1J2lz3pkg
	for ; Mon, 30 May 2022 14:14:42 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1653920075; bh=lk4US4UPQ1MsfoV7Rxxb1MgS0UDSZpm6aAXZCMyT6dE=;
	h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To;
	b=pJ6QzabrBaRPxuvPqi6VhE1xBJtmBkkDDTgyTv3NdzaB+kFT+R/Yc6JU4Prr3aj4X
	 2dfVzEIinisUuYgvew/QuAbTCIkOrJX44c/XgMlb4DAQnOj5kLRXrptM6WNYi66eO6
	 6VTkQFmFnC3F0H7rleJFC7Lc4ZwUkxFptHYY7knunJIXam4fthwyeN29h1a2CyO9+r
	 fL3t+ZYFvHWUIAk08YpTENhpmMEKdC2LHw50l6Un9FlhIKCL0UIhp8oLAoG1sLSK5d
	 +pHhzyHcefi4E5rLFY5oiBY8JMgxUb5muUHheINlnSOTpLWn28zkFwpI+T5nwbNbMz
	 CNf3bH7dMcVpw==
Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10])
	by pv50p00im-ztdg10021801.me.com (Postfix) with ESMTPSA id B12221603F2;
	Mon, 30 May 2022 14:14:32 +0000 (UTC)
From: Toomas Soome 
Message-Id: <7BEE44CC-4D31-4CBC-BC12-9A327424299C@me.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_81B225C1-3C68-4500-A869-472F404EA478"
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
Date: Mon, 30 May 2022 17:14:25 +0300
In-Reply-To: 
Cc: David Wolfskill ,
 FreeBSD Current 
To: Warner Losh 
References: 
 
 
 
X-Mailer: Apple Mail (2.3696.100.31)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.874
 definitions=2022-05-30_05:2022-05-30,2022-05-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0
 mlxlogscore=983 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-2009150000 definitions=main-2205300075
X-Rspamd-Queue-Id: 4LBcqQ1J2lz3pkg
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=pJ6Qzabr;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.56 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-3.60 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FREEMAIL_FROM(0.00)[me.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[me.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine];
	 NEURAL_HAM_SHORT(-1.00)[-0.998];
	 RECEIVED_SPAMHAUS_PBL(0.00)[17.56.9.10:received];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[me.com];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	 FREEFALL_USER(0.00)[tsoome];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 DWL_DNSWL_NONE(0.00)[me.com:dkim];
	 RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.56:from];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MLMMJ_DEST(0.00)[current];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_81B225C1-3C68-4500-A869-472F404EA478
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 30. May 2022, at 17:06, Warner Losh  wrote:
>=20
>=20
>=20
> On Mon, May 30, 2022 at 4:26 AM David Wolfskill > wrote:
> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> > ...=20
> > Does loader_4th have same issue?
> > ....
>=20
> I don't know; I hadn't tried it.  I will do so later today & report
> back.
>=20
> So if it's only one system, and it's only UFS, then what does fsck of =
that UFS system tell you?
> The loader can't find its UFS filesystem to read the configuration =
from. So either its having trouble
> finding the device (unlikely since that code hasn't changed in a long =
time), or its having heartburn
> with the UFS system for some reason it's being silent about (within =
the realm of possibilities because
> there might be an unknown edge case in Kirks recent  UFS integrity =
changes). I suspect that the 4th
> boot loader will have the same issue, but a different error message.
>=20
> Others have reported issues with GELI, but that's not in play here, If =
I'm reading this correctly. Right?
>=20
> Warner

Ye, thats why I was asking about loader_4th. I=E2=80=99m trying to spot =
the issue from ufs image sample.=20

rgds,
toomas=

--Apple-Mail=_81B225C1-3C68-4500-A869-472F404EA478
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 30. May 2022, at 17:06, Warner Losh <imp@bsdimp.com> =
wrote:



On Mon, May 30, 2022 at 4:26 AM David =
Wolfskill <david@catwhisker.org> wrote:
On Mon, May 30, 2022 at 08:40:10AM =
+0300, Toomas Soome wrote:

> ... 

> Does loader_4th have same issue?

> ....



I don't know; I hadn't tried it.  I will do so later today & =
report

back.

So if it's only one system, and it's only UFS, then what =
does fsck of that UFS system tell you?
The loader =
can't find its UFS filesystem to read the configuration from. So either =
its having trouble
finding the device (unlikely =
since that code hasn't changed in a long time), or its having =
heartburn
with the UFS system for some reason it's =
being silent about (within the realm of possibilities because
there might be an unknown edge case in Kirks recent  UFS =
integrity changes). I suspect that the 4th
boot loader will have the same issue, but a =
different error message.

Others have reported issues with GELI, =
but that's not in play here, If I'm reading this correctly. =
Right?

Warner



Ye, thats why I =
was asking about loader_4th. I=E2=80=99m trying to spot the issue from =
ufs image sample. 

rgds,
toomas
=

--Apple-Mail=_81B225C1-3C68-4500-A869-472F404EA478--

From nobody Mon May 30 14:15:58 2022
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 8B8851B57564
	for ; Mon, 30 May 2022 14:16:03 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBcrx5FNsz3qYk
	for ; Mon, 30 May 2022 14:16:01 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 24UEFw4p016859;
	Mon, 30 May 2022 14:15:58 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 24UEFwiC016858;
	Mon, 30 May 2022 07:15:58 -0700 (PDT)
	(envelope-from david)
Date: Mon, 30 May 2022 07:15:58 -0700
From: David Wolfskill 
To: Warner Losh 
Cc: Toomas Soome , FreeBSD Current 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
Message-ID: 
Reply-To: current@freebsd.org
Mail-Followup-To: current@freebsd.org, Warner Losh ,
	Toomas Soome 
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-sha512;
	protocol="application/pgp-signature"; boundary="iHFn5ybGpaIhBRLr"
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4LBcrx5FNsz3qYk
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-2.97 / 15.00];
	 ARC_NA(0.00)[];
	 HAS_REPLYTO(0.00)[current@freebsd.org];
	 FREEFALL_USER(0.00)[david];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
	 DMARC_NA(0.00)[catwhisker.org];
	 NEURAL_SPAM_MEDIUM(0.77)[0.771];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-0.34)[-0.338];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 MLMMJ_DEST(0.00)[current];
	 SIGNED_PGP(-2.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	 FREEMAIL_CC(0.00)[me.com,freebsd.org];
	 RCVD_TLS_LAST(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


--iHFn5ybGpaIhBRLr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 30, 2022 at 08:06:32AM -0600, Warner Losh wrote:
> ...
> > On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> > > ...
> > > Does loader_4th have same issue?
> > > ....
> >
> > I don't know; I hadn't tried it.  I will do so later today & report
> > back.
> >
>=20
> So if it's only one system, and it's only UFS, then what does fsck of that
> UFS system tell you?

fsck reports that all is well.

> The loader can't find its UFS filesystem to read the configuration from. =
So
> either its having trouble
> finding the device (unlikely since that code hasn't changed in a long
> time), or its having heartburn
> with the UFS system for some reason it's being silent about (within the
> realm of possibilities because
> there might be an unknown edge case in Kirks recent  UFS integrity
> changes). I suspect that the 4th
> boot loader will have the same issue, but a different error message.

Pretty much, yeah.  And loader's "lsdev" shows the devices, slices, and
partitions just fine.  But loaders's "ls" doesn't find /.

Toomas has recieved a "dd" image for the first 5 MB of the file system,
and has reproduced the issue in hist test environment, so I'm hoping he
will be able to figure out a bit more.  (It's at
https://www.catwhisker.org/~david/FreeBSD/head/loader/ada0s4a, in case
anyone else wants a peek.)

> Others have reported issues with GELI, but that's not in play here, If I'm
> reading this correctly. Right?

Right: no GELI for any file systems on this machine (only for swap).

Thanks!

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshniko=
va

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--iHFn5ybGpaIhBRLr
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYpTRnl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1MREAQCO+SOK3AtiOiDmNx8YU0BWf+k24eb/kHpoZ6wPVHLJiwD/bV49fCU5ZfCJ
wjY5Glt4s+QE+0UMrkvP6S/XecX5uwk=
=Qgrk
-----END PGP SIGNATURE-----

--iHFn5ybGpaIhBRLr--

From nobody Mon May 30 14:16:20 2022
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 EAFD61B57CF7
	for ; Mon, 30 May 2022 14:16:34 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBcsY08TQz3qsb
	for ; Mon, 30 May 2022 14:16:32 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe31.google.com with SMTP id 68so10929471vse.11
        for ; Mon, 30 May 2022 07:16:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=2p1GsMG2IfHrQrwm21FTNrPYXGnD6sLcZaDR4RXf8vo=;
        b=0tCPcCYtx2Nlz7MbDOJY89f5QTvMuKdSjRxUnDQSJgi08beN4/0vwModYGBmJnSM6a
         gG6SR7v/FDrcYB436kr+342WjjGwr5Tlb0KbIY3qGQHFLT/Sp2zYNEmn/2GYimnFVsj9
         W1y9fv/bgot/V/dyGGKazG/A2sYvOFXUtiWY22mctN+YXs8ax9d25s7UApPztk+LzGdx
         vuIRzoYfckqjiCcFHRNEWGLh2RNj/ZmOtpnl7Z6FloOQ64545PBHgUVq/6RXUQSeJmHy
         r2tyKEHZrnuUXbibs5T4WKoK7XnSr5RExMizTMNz2tUY0RrevAXCOQuRNQDvhLGei82B
         IocA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=2p1GsMG2IfHrQrwm21FTNrPYXGnD6sLcZaDR4RXf8vo=;
        b=bQPUDNYDHsiwcsKoq5n6JAafQDm6ATXs0EaVKQxVWq/3UGPA5cI1XiSq1K/TB9tWpi
         k2gqAcpJCRwDrfo3zbUbR0X8HW3m7dDqm2HVYBSNEVgrvWuGBARq7zvwW1f+911YnjIm
         rDU+1dgpNvROTGbWj9eRrho7wFwxqbRMkWr2VO/YzmyG51oma1Krzk9fmLlPOLCB3C5v
         kqBGC5SRiAb3MtgMssaBjOlv6SCNhEKqk+dhabvV+dLEBO6NkZs9ht09ddR0Oe3aW57f
         Wf4RJyzacZuQtvcnBTOMPzSXTLlYQl0aH3eN+tfiq48VcguEmuzr48aWupe/rY7itK1w
         xvVQ==
X-Gm-Message-State: AOAM5307hKcpDKvI4l9+OXaeTPwKBziyLNeHGIyT/Aezdo6oWy1jCF/d
	V7PNwIVZWMORKOJGuwmnI1GA3kuHWN9fodNHu03smBvN9MM=
X-Google-Smtp-Source: ABdhPJzrONEWGgcBLiAKUsjKMkx2a0ggIpnTwxev1GSkHsg6WSA0x9afBodbXkxnfOemEL4JT0RIwC4O/GM73hu8pzM=
X-Received: by 2002:a67:e01b:0:b0:337:9729:acc2 with SMTP id
 c27-20020a67e01b000000b003379729acc2mr17634848vsl.10.1653920191773; Mon, 30
 May 2022 07:16:31 -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:  
  
 <7BEE44CC-4D31-4CBC-BC12-9A327424299C@me.com>
In-Reply-To: <7BEE44CC-4D31-4CBC-BC12-9A327424299C@me.com>
From: Warner Losh 
Date: Mon, 30 May 2022 08:16:20 -0600
Message-ID: 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c
To: Toomas Soome 
Cc: David Wolfskill , FreeBSD Current 
Content-Type: multipart/alternative; boundary="0000000000008495bd05e03b4d42"
X-Rspamd-Queue-Id: 4LBcsY08TQz3qsb
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=0tCPcCYt;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e31) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.97 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.97)[-0.973];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from];
	 MLMMJ_DEST(0.00)[current];
	 FREEMAIL_TO(0.00)[me.com];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000008495bd05e03b4d42
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 30, 2022 at 8:14 AM Toomas Soome  wrote:

>
>
> On 30. May 2022, at 17:06, Warner Losh  wrote:
>
>
>
> On Mon, May 30, 2022 at 4:26 AM David Wolfskill 
> wrote:
>
>> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
>> > ...
>> > Does loader_4th have same issue?
>> > ....
>>
>> I don't know; I hadn't tried it.  I will do so later today & report
>> back.
>>
>
> So if it's only one system, and it's only UFS, then what does fsck of tha=
t
> UFS system tell you?
> The loader can't find its UFS filesystem to read the configuration from.
> So either its having trouble
> finding the device (unlikely since that code hasn't changed in a long
> time), or its having heartburn
> with the UFS system for some reason it's being silent about (within the
> realm of possibilities because
> there might be an unknown edge case in Kirks recent  UFS integrity
> changes). I suspect that the 4th
> boot loader will have the same issue, but a different error message.
>
> Others have reported issues with GELI, but that's not in play here, If I'=
m
> reading this correctly. Right?
>
> Warner
>
>
> Ye, thats why I was asking about loader_4th. I=E2=80=99m trying to spot t=
he issue
> from ufs image sample.
>

I thought it was a good suggestion. My guess on it not working wasn't to
imply it wasn't.

Warner

--0000000000008495bd05e03b4d42
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, May 30, 2022 at 8:14 AM Tooma=
s Soome <tsoome@me.com> wrote:


On 30.=
 May 2022, at 17:06, Warner Losh <imp@bsdimp.com> wrote:

=



On Mon, May 30, 2022 at 4:26 AM David Wolfskill <david@catwhisker.or=
g> wrote:
On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:

> ... 

> Does loader_4th have same issue?

> ....



I don't know; I hadn't tried it.=C2=A0 I will do so later today &am=
p; report

back.

So if it's only one system, a=
nd it's only UFS, then what does fsck of that UFS system tell you?
The loader can't find its UFS filesystem to read the configuratio=
n from. So either its having trouble
finding the device (unlikely=
 since that code hasn't changed in a long time), or its having heartbur=
n
with the UFS system for some reason it's being silent about=
 (within the realm of possibilities because
there might be an unk=
nown edge case in Kirks recent=C2=A0 UFS integrity changes). I suspect that=
 the 4th
boot loader will have the same issue, but a differen=
t=C2=A0error message.

Others have reported issues =
with GELI, but that's not in play here, If I'm reading this correct=
ly. Right?

Warner



Ye, thats why I was asking about loader_4=
th. I=E2=80=99m trying to spot the issue from ufs image sample.=C2=A0
=


I thought it was a good suggestion. =
My guess on it not working wasn't to imply it wasn't.
Warner=C2=A0


--0000000000008495bd05e03b4d42--

From nobody Mon May 30 22:34:32 2022
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 C72281B5B3EE
	for ; Mon, 30 May 2022 22:34:36 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBqwC16vNz4Yvs
	for ; Mon, 30 May 2022 22:34:35 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250])
	by cmsmtp with ESMTP
	id vi4ons8RcwtwGvnxznrinM; Mon, 30 May 2022 22:34:27 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id vny5nfv11yz1uvny5nD33a; Mon, 30 May 2022 22:34:34 +0000
X-Authority-Analysis: v=2.4 cv=J4G5USrS c=1 sm=1 tr=0 ts=6295467a
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=oZkIemNP1mAA:10 a=HHGDD-5mAAAA:8 a=7Qk2ozbKAAAA:8
 a=JAf30KXuAAAA:8 a=BWvPGDcYAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8
 a=EkcXrb_YAAAA:8 a=4VOk7pbHtyGBV5aI4CYA:9 a=JOWeiY5itpwPQvuQ8dm/GawRuwE=:19
 a=CjuIK1q_8ugA:10 a=1lyxoWkJIXJV6VJUPhuM:22 a=GEL62FyrTCmHtEug2d3R:22
 a=pxhY87DP9d2VeQe4joPk:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22
 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id E3678371;
	Mon, 30 May 2022 15:34:32 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id D91C518F; Mon, 30 May 2022 15:34:32 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Warner Losh 
cc: Toomas Soome , David Wolfskill ,
    FreeBSD Current 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after 
 main-n255828-18054d0220c
In-reply-to: 
References:  
    <7BEE44CC-4D31-4CBC-BC12-9A327424299C@me.com> 
Comments: In-reply-to Warner Losh 
   message dated "Mon, 30 May 2022 08:16:20 -0600."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 30 May 2022 15:34:32 -0700
Message-Id: <20220530223432.D91C518F@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfLub0arT+ey2AKK5z58lno8qJXQaQa0ATb0uqXQ7XGVW/pQOFxovMxLsH7/KjKV2Y0A8sG6hqDnqYEmXrkIOSfo+lwcIKj3qtEY33fQHs03Sly+huY08
 eXOchOWExW27X3ndu0JVRjPrYwQNxr6BxkUpyk6Bd9aPJWJeLC1xSsu92Ly2c/msjGG0jTG1VI3+PEPsUW6jY9nk03FMtW+Z/UDZ+ADUGy9A+Du3vhkZ9C9I
 EhOafVBNIeX3ZtqfKcmBn5tHNGg4ptEHkDKhI6gsSr0=
X-Rspamd-Queue-Id: 4LBqwC16vNz4Yvs
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	 HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MV_CASE(0.50)[];
	 RCVD_COUNT_THREE(0.00)[4];
	 TO_DN_ALL(0.00)[];
	 RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 R_DKIM_NA(0.00)[];
	 ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	 MIME_TRACE(0.00)[0:+];
	 RECEIVED_SPAMHAUS_PBL(0.00)[70.66.148.124:received];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 REPLYTO_EQ_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MLMMJ_DEST(0.00)[current];
	 R_SPF_NA(0.00)[no SPF record];
	 FREEMAIL_CC(0.00)[me.com,catwhisker.org,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

In message 
, Warner Losh writes:
> --0000000000008495bd05e03b4d42
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, May 30, 2022 at 8:14 AM Toomas Soome  wrote:
>
> >
> >
> > On 30. May 2022, at 17:06, Warner Losh  wrote:
> >
> >
> >
> > On Mon, May 30, 2022 at 4:26 AM David Wolfskill 
> > wrote:
> >
> >> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote:
> >> > ...
> >> > Does loader_4th have same issue?
> >> > ....
> >>
> >> I don't know; I hadn't tried it.  I will do so later today & report
> >> back.
> >>
> >
> > So if it's only one system, and it's only UFS, then what does fsck of tha=
> t
> > UFS system tell you?
> > The loader can't find its UFS filesystem to read the configuration from.
> > So either its having trouble
> > finding the device (unlikely since that code hasn't changed in a long
> > time), or its having heartburn
> > with the UFS system for some reason it's being silent about (within the
> > realm of possibilities because
> > there might be an unknown edge case in Kirks recent  UFS integrity
> > changes). I suspect that the 4th
> > boot loader will have the same issue, but a different error message.
> >
> > Others have reported issues with GELI, but that's not in play here, If I'=
> m
> > reading this correctly. Right?
> >
> > Warner
> >
> >
> > Ye, thats why I was asking about loader_4th. I=E2=80=99m trying to spot t=
> he issue
> > from ufs image sample.
> >
>
> I thought it was a good suggestion. My guess on it not working wasn't to
> imply it wasn't.

Backing out 076002f24d35962f0d21f44bfddd34ee4d7f015d restored the one 
machine of mine that did have the problem. The other three were fine with 
that commit.

To summarize, things I tried:

- Reinstall all boot blocks.
- set currdev to my USB rescue disk, ls works, boots fine
- boot from my USB rescue disk, set currdev to the boot disk, boots
- boot from the USB rescue disk, copy /boot/loader* to the boot disk, works 
around the problem.
- Revert 076002f24d35962f0d21f44bfddd34ee4d7f015d resolves the problem.

Other data points:

My three AMD machines on Asus motherboards had no problem with the commit. 
My Acer laptop with Intel CPU suffered the same problem. Could it be that 
malloc() worked on the Asus/AMD machines while it failed on the Acer/Intel 
laptop?

If my hunch that this may be caused by a malloc() failure, would it be a 
good idea to print a nasty warning when malloc failures in loader occur? 
Because silently failing, resulting in weird behaviour is more of a POLA 
than a nasty message. If not this, a loader variable to enable verbose 
messages might help in debugging these kinds of problems. Again, this 
assumes my hunch that it's a malloc() failure is what actually happened.


-- 
Cheers,
Cy Schubert  or 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e**(i*pi)+1=0




From nobody Mon May 30 23:10:12 2022
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 6C6DA1B6488E
	for ; Mon, 30 May 2022 23:10:30 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LBrjd0m0rz4kY2
	for ; Mon, 30 May 2022 23:10:29 +0000 (UTC)
	(envelope-from agh@riseup.net)
Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83])
	(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
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.riseup.net", Issuer "R3" (not verified))
	by mx0.riseup.net (Postfix) with ESMTPS id 4LBrjV0JrBz9shn;
	Mon, 30 May 2022 16:10:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
	t=1653952222; bh=lbSnZMgqYElmQ7jxG1LfP4knHZM18H64NaQ0kxpdfhQ=;
	h=Date:From:To:Subject:In-Reply-To:References:From;
	b=Iw0U1aOPtJVbTT/Vu4M9k8apWtMwft04kRTgkaRtUQFFNvpnpw9A1jWl9kNedT1Og
	 6/2rKPjluSBP8BR3MJgtai+gClEnW+e6tOv+9Ci3a+TAbfe3aSNyNTLCfK0KL3E0zO
	 oXzy3wDUCzWPkbLBEsSUj9/azvPteUFbg1yjkk7g=
X-Riseup-User-ID: 1B85FD63589432F86BED18C9F2B8F228F950457FB57B770533B90468EDDB4715
Received: from [127.0.0.1] (localhost [127.0.0.1])
	 by fews1.riseup.net (Postfix) with ESMTPSA id 4LBrjS6M7rz5vVy;
	Mon, 30 May 2022 16:10:20 -0700 (PDT)
Date: Tue, 31 May 2022 07:10:12 +0800
From: Alastair Hogge 
To: current@freebsd.org, David Wolfskill 
Subject: =?US-ASCII?Q?Re=3A_Loader_can=27t_find_/boot/ua/loader=2El?= =?US-ASCII?Q?ua_on_UFS_after_main-n255828-18054d0220c?=
In-Reply-To: 
References:  <06ba3be54117e4feb8f250756b25c1c5@riseup.net> 
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-Rspamd-Queue-Id: 4LBrjd0m0rz4kY2
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=riseup.net header.s=squak header.b=Iw0U1aOP;
	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
X-Spamd-Result: default: False [-2.90 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[riseup.net:s=squak];
	 RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.6:from];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mx0.riseup.net];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[riseup.net:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[riseup.net,none];
	 SUBJ_EXCESS_QP(1.20)[];
	 MLMMJ_DEST(0.00)[current];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[riseup.net:dkim]
X-ThisMailContainsUnwantedMimeParts: N



On 30 May 2022 8:38:27 pm AWST, David Wolfskill  w=
rote:
>On Mon, May 30, 2022 at 05:16:57AM -0700, Alastair Hogge wrote:
>> =2E=2E=2E
>> I have not been able to use a new /boot/loader=2Eefi (following -CURREN=
T)
>> since=20
>> mid to late 2021, and your symptoms look the same; fortunately, I found
>> bug=20
>> report 264282[0] last night, which I think is related=2E Yamagi has
>> already done=20
>> the investigation, and found a possible cause=2E For the time being, in
>> the case=20
>> of a GELI backed UFS mount, after GELI decrypts the mount, one has to
>> manually=20
>> set currdev back to the correct disk=2E
>>=20
>> 0: https://bugs=2Efreebsd=2Eorg/bugzilla/show_bug=2Ecgi?id=3D264282
>> =2E=2E=2E=2E
>
>I (just) checked; after switching back to the Lua loader, the currdev
>variable is set to "disk0s4a:", which is correct for my case=2E
>
>Trying loader's "lsdev" command shows the expected disks, slices, and
>partitions, correctly identified as FreeBSD UFS, swap, or ZFS=2E
>
>Trying to (e=2Eg=2E) "ls disk0s4a:" fails, saying that it can't find /=2E

Thanks for having a look into that mate=2E

--=20
Sent from a device with a tiny bloody screen and no hard keyboard; please =
excuse my brevity=2E

From nobody Tue May 31 21:54:20 2022
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 7DD9C1B61FA1
	for ; Tue, 31 May 2022 21:54:32 +0000 (UTC)
	(envelope-from olivier@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LCQzX2kxcz3vpf
	for ; Tue, 31 May 2022 21:54:32 +0000 (UTC)
	(envelope-from olivier@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1654034072;
	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=xdF7nKiHdDlmeDfZ+Dvdt7V0IQ387VNUmgPB3ySE0vc=;
	b=PkHnl5Z8HNdWoSJoNUXoIF49+IRDN6+PRSwEOpdKLxLMWnwle6iRKoZcdi9snqwtX+YQqQ
	/quj8IhTF2xIuDihFbEp6MNuOKsWWUZsK/UfzTyZryT68HQbjxL+qgOi/4lynecNXmfLBh
	BEH3tM193nypLDoIsyLMajt1s7QE1olXUQoKcqQjLk1aAQVmit+dakGExnkktLqYGXxvKl
	nLtO612ute1BIO1U7M4+vwPt6kizdXQAMP2r20+nvCNMZbLjVIsRC86Y6atkZ9A+2Fs+yE
	Q8sLLwOs00lThsdrvXwwt1453ycolTz+PKydzn9acTgsw3bNWZsUswf4hJHnvg==
Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: olivier/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 3A4802F60C
	for ; Tue, 31 May 2022 21:54:32 +0000 (UTC)
	(envelope-from olivier@freebsd.org)
Received: by mail-qt1-f177.google.com with SMTP id hf10so2087074qtb.7
        for ; Tue, 31 May 2022 14:54:32 -0700 (PDT)
X-Gm-Message-State: AOAM532S+SewkifvA3IoUo/nPYbxK+SsKsjT3Zn7IttR9urlYUGWhiAM
	+JKik3Iqw4+E1C0c3n/XYCQPN6h6agOqdH2E/pM=
X-Google-Smtp-Source: ABdhPJy0540ck1DQ07i+d6fbHHeUaiPD5LLAfh639d8irgkT+2/9LXZ4TysKa5BSujDPPCbJGN9s7bU2YBRVBKnuHCA=
X-Received: by 2002:ac8:7f15:0:b0:2f9:38d0:abc8 with SMTP id
 f21-20020ac87f15000000b002f938d0abc8mr35861198qtk.509.1654034071759; Tue, 31
 May 2022 14:54:31 -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:  
  
 <7BEE44CC-4D31-4CBC-BC12-9A327424299C@me.com> 
 <20220530223432.D91C518F@slippy.cwsent.com>
In-Reply-To: <20220530223432.D91C518F@slippy.cwsent.com>
From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= 
Date: Tue, 31 May 2022 23:54:20 +0200
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c
To: FreeBSD Current 
Content-Type: multipart/alternative; boundary="0000000000004b33ce05e055d1cd"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654034072;
	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=xdF7nKiHdDlmeDfZ+Dvdt7V0IQ387VNUmgPB3ySE0vc=;
	b=im+mpDGhKMrdG+e/ukY6tqFxXw8f0sZUAhF0n/d0TtZ6DzGzHSW7f3BV6o6tHEwBMPS+Ab
	RSSqOzB9E6z3VfLfTTEfnr2T+sdSj0Lq3k5/H8uFEo5Ti3WjaQbtbjsbDzMgeC0bRTcNTR
	omH7o/5fLiNjf5ntd/UOHuvGGIkd/uih/bKEPDTK4MlNnAlvzK+odNOJzvaVNYK9S9R3eT
	yscNwVzuOtttR+bsQSyWAqovah4j4i2BmmOaVbNGdLo8tdgdpbBpOsrtV6vTPHrLudLcVY
	4g0snfe88vtbdygca6ic7T8ngi/CU2YdCj4Q/9cXD/9IvnmePyhPh2IB3/arHg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654034072; a=rsa-sha256; cv=none;
	b=s4aDud/5IyAqKqVB2VPvtwdmX/LROKio+C2y36mzuFW1MCSVu1ywHa/vav46WA8+BLWOhl
	6p+ER9Tgm94pdW+2deDyoF9x35r6mjCFkOE+08IA94g4G2xMwQs5aTN8V9yUPPrd1bhr/f
	yY1ihaOHsDSbWRjWIiJ6wfCa7MKoKwa1rixbr2FWEQQ9ThTkuZ54JNh73Mw+65Ah47JxYJ
	fqX25Xjk9wmtR6o5O/O5Tb+fE3SD8c4CvtQQepWv/F0yXH+zUoxP2c6oKcVYzxVlLEkTp0
	K5pEh22mVVopMljbA2ksHb2Ssk8QImMrf2JLseu9B6utPMe9VVZGkb7C0cIhRA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000004b33ce05e055d1cd
Content-Type: text/plain; charset="UTF-8"

Same problem here:
- I'm building FreeBSD head on a builder machine, and NFS mounting its
/usr/src and /usr/obj to 4 others

Results:
- 2 of them, UEFI+ZFS machines works great ((Thinkpad T420 and AMD Epyc
with Tyan motherboard)
- 2 of them, BIOS+UFS machines meet this "can't find /boot/ua/loader.lua"
(HP microserver and PC Engines APU2)

I had to boot from an USB stick, mounting the system partition and "cp
boot/loader_4th.old boot/loader".

--0000000000004b33ce05e055d1cd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Same problem=
 here:
- I'm building FreeBSD head on=
 a builder machine, and NFS mounting its /usr/src and /usr/obj to 4 others<=
/div>

Re=
sults:
- 2 of them, UEFI+ZFS machines wor=
ks great ((Thinkpad T420 and AMD Epyc with Tyan motherboard)
- 2 of them, BIOS+UFS machines meet this "can'=
t find /boot/ua/loader.lua" (HP microserver and PC Engines APU2)
=


I had t=
o boot from an USB stick, mounting the system partition and "cp boot/l=
oader_4th.old boot/loader".


--0000000000004b33ce05e055d1cd--

From nobody Tue May 31 23:05:41 2022
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 E3D3F1B6C563
	for ; Tue, 31 May 2022 23:05:53 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LCSYs1tkDz4WK0
	for ; Tue, 31 May 2022 23:05:53 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe33.google.com with SMTP id h4so15104855vsr.13
        for ; Tue, 31 May 2022 16:05:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=NfGYbuNdwnHy5o2IqsTPfUKVtOPBZES6k660Vo07+ko=;
        b=M4K4AjgUhMVh3g0exba/wMQ680xh828by0rnysqN4cAXCTZLpiMF+jOL4rEzf8Vr41
         D/alp3P5eseEomV4/5t0a8XeeY4lVFGIcFd/zAPHj0RHiB1gSssrJT5Rs/31Y7mp+Zl5
         1ht1FWLX43/7HNH42sSu1Dinli1cFj6q2DMk2N4dLKOk0RNof9TdJCVlUTJvLSQE0K9p
         BJj+Usj53+UvCzznj+MKE1jVrDaKWl9beJ+gsqA+J/T3WtCl0tHy3hPWVR27uXfUjuob
         TI8V4dcZj6J5S2QexG0rrJRtUMW+6+TI8d4svw0yxzSPhm6TefzZR5Q2KvPZby7iCx1u
         i2UQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=NfGYbuNdwnHy5o2IqsTPfUKVtOPBZES6k660Vo07+ko=;
        b=xlFxmHt5BmkeRiWHzNi0PjHwWt2jdsnxlAd/pPzAPPnwfW0Y08VRFVcaiA12iyHtyP
         8wLWMCUhs7LBm+TqoeeRDDbvnjrKrofsK25UiZiUflQL2oCsc2GH4kQm5lLiWqYqTzZO
         Ntf7l1oOioEQwj++/rql/CBDFCzaO5k471K1HLi3LrzuZ2vr8fvyxsc8E3daNBMKMxQz
         +Uwn8qt/CVHRlhTwGqMqxGRRBiq6t55rwiPcBdST56s5TqMaRFLbvc69jBjXXxltPlyV
         6IBuXbw5L+40kUXeewPIiDP0pXEm8ez3KNtrcNRzIXtJ9UBWyaPzjgTlOyrCBznejYcy
         aExA==
X-Gm-Message-State: AOAM531Qyq35R4isvBnQZ55B5Tya6SjRnMQzj1xYYQfVdFUot5mWadzd
	tPRbt70ObT1ITcaJBWOt+eURrBVCpiUBboppjZ8g23vVA/vSXw==
X-Google-Smtp-Source: ABdhPJx+bgH6Qna1Wst9EFWtfQP9+PHQV3iXgfL4DAoOqSOEmWCCxBjtVK3ueOb/OlU5dUehjyT55CbjR++KIitmDcI=
X-Received: by 2002:a05:6102:38d4:b0:337:a198:2fe9 with SMTP id
 k20-20020a05610238d400b00337a1982fe9mr20196760vst.83.1654038352715; Tue, 31
 May 2022 16:05:52 -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:  
  
 <7BEE44CC-4D31-4CBC-BC12-9A327424299C@me.com> 
 <20220530223432.D91C518F@slippy.cwsent.com> 
In-Reply-To: 
From: Warner Losh 
Date: Tue, 31 May 2022 17:05:41 -0600
Message-ID: 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c
To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= 
Cc: FreeBSD Current 
Content-Type: multipart/alternative; boundary="0000000000007573af05e056d04a"
X-Rspamd-Queue-Id: 4LCSYs1tkDz4WK0
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=M4K4AjgU;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e33) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e33:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000007573af05e056d04a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 31, 2022 at 3:55 PM Olivier Cochard-Labb=C3=A9 
wrote:

> Same problem here:
> - I'm building FreeBSD head on a builder machine, and NFS mounting its
> /usr/src and /usr/obj to 4 others
>
> Results:
> - 2 of them, UEFI+ZFS machines works great ((Thinkpad T420 and AMD Epyc
> with Tyan motherboard)
> - 2 of them, BIOS+UFS machines meet this "can't find /boot/ua/loader.lua"
> (HP microserver and PC Engines APU2)
>
> I had to boot from an USB stick, mounting the system partition and "cp
> boot/loader_4th.old boot/loader".
>

Kirk found that the boot loader defines MAXPHYS to be 128k, which only is
for the BIOS loader since it's 32-bit. UEFI
is 64-bits and just works because it's define to 1MB. So the UEFI machines
with ZFS are doubly safe. Kirk has a change
that relaxes the check and I think we should do this

diff --git a/sys/sys/param.h b/sys/sys/param.h
index 1f720ed31142..8cd9616e872e 100644
--- a/sys/sys/param.h
+++ b/sys/sys/param.h
@@ -176,7 +176,7 @@
 #define DFLTPHYS       (64 * 1024)     /* default max raw I/O transfer
size */
 #endif
 #ifndef MAXPHYS                                /* max raw I/O transfer
size */
-#ifdef __ILP32__
+#if defined(__ILP32__) && !defined(_STANDALONE) /* Always 1M for loader */
 #define MAXPHYS                (128 * 1024)
 #else
 #define MAXPHYS                (1024 * 1024)

as well to ensure that the loader always assumes a larger MAXPHYS (though
I'd kinda like the loader to not
define it at all, but that is a longer conversation after reflection not a
quick fix to get people back up and
running).

Warner

--0000000000007573af05e056d04a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, May 31, 2022 at 3:55 PM Olivi=
er Cochard-Labb=C3=A9 <olivier@fr=
eebsd.org> wrote:
Same problem here:
<=
div>- I'm building FreeBSD head on a builder machine, and NFS mounting =
its /usr/src and /usr/obj to 4 others

Results:
- 2 of them, UEFI+ZFS machines works great ((Thinkpad T420 and AMD E=
pyc with Tyan motherboard)
- 2 of them, BIOS+UFS machines meet th=
is "can't find /boot/ua/loader.lua" (HP microserver and PC En=
gines APU2)

I had to boot from an USB stick, mount=
ing the system partition and "cp boot/loader_4th.old boot/loader"=
.

Kirk found that the boo=
t loader defines MAXPHYS to be 128k, which only is for the BIOS loader sinc=
e it's 32-bit. UEFI
is 64-bits and just works because it'=
s define to 1MB. So the UEFI machines with ZFS are doubly safe. Kirk has a =
change
that relaxes the check and I think we should do this
=


diff --git a/sys/sys/param.h b/sys/sys/param.h
index=
 1f720ed31142..8cd9616e872e 100644
--- a/sys/sys/param.h
+++ b/sys/sy=
s/param.h
@@ -176,7 +176,7 @@
=C2=A0#define DFLTPHYS =C2=A0 =C2=A0 =
=C2=A0 (64 * 1024) =C2=A0 =C2=A0 /* default max raw I/O transfer size */=C2=A0#endif
=C2=A0#ifndef MAXPHYS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0/* max raw I/O transfer size */
-#ifdef __ILP32__
+#if defined(__I=
LP32__) && !defined(_STANDALONE) /* Always 1M for loader */
=C2=
=A0#define MAXPHYS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(=
128 * 1024)
=C2=A0#else
=C2=A0#define MAXPHYS =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(1024 * 1024)

as well to ensure that the loader always assumes a larger MAXPHYS (though=
 I'd kinda like the loader to not
define it at all, but that =
is a longer conversation after reflection not a quick fix to get people bac=
k up and
running).

Warner


--0000000000007573af05e056d04a--

From nobody Wed Jun  1 00:00:01 2022
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 04DB41B469EE;
	Wed,  1 Jun 2022 00:00:02 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LCTmK6fnZz4c0R;
	Wed,  1 Jun 2022 00:00:01 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1654041601;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=;
	b=y2Ru8rmZ+Xewk1J4k4j9By6OK7kzf1sSHr+10OWuBz500Pk29f8O7qk4MeNOhrKgsbtTfw
	JdRkY6NttquCja0Zs4k71ZZiTC0TFjojqduK0HJNABbg1Bc0OWMwXqmezDnYzyjFhbggLt
	slyAlxCTU3QN+ZPBg2UQLvOEHa9Wzf+4+z9w+cM+f8/ggp2jwYVJiye7Sy0Vn71AV708MC
	mj+693DjYeLxJBLzQdujc+zIjZoa3G5/w0tIrHE6/9jxIiRl0rq2ymV2jRjgrRTfXcZcQ0
	hp8lAYrZKi1+ER/fASYV9lbbfZNGcIU8NaO/tqUU2pxWffa7lBYOyg2UHAmrsw==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id C1B4710D73; Wed,  1 Jun 2022 00:00:01 +0000 (UTC)
To: freebsd-quarterly-calls@FreeBSD.org
Subject: Call for 2022Q2 quarterly status reports
Cc: martymac@FreeBSD.org,probono@puredarwin.org,mk@semihalf.com,freebsd-current@FreeBSD.org,freebsd-accessibility@freebsd.org,soc-mentors@FreeBSD.org,deb@FreeBSDFoundation.org,portmgr-secretary@FreeBSD.org,doceng@FreeBSD.org,jenkins-admin@FreeBSD.org,info@bsdcan.org,dsl@mcusim.org,freebsd-hackers@FreeBSD.org,kde@FreeBSD.org,cperciva@FreeBSD.org,grembo@freebsd.org,fluffy@FreeBSD.org,pauamma@gundo.com,gerald@pfeifer.com,soc-students@FreeBSD.org,mckusick@mckusick.com,bz@FreeBSD.ORG,pizzamig@freebsd.org,clusteradm@FreeBSD.org,asiciliano@FreeBSD.org,dgr@semihalf.com,portmgr@FreeBSD.org,sl@honeyguide.eu,office@FreeBSD.org,lwhsu@FreeBSD.org,pali.gabor@gmail.com,carlavilla@FreeBSD.org,re@FreeBSD.org,bz@FreeBSD.org,mw@semihalf.com,bapt@FreeBSD.org
Message-Id: <20220601000001.C1B4710D73@freefall.freebsd.org>
Date: Wed,  1 Jun 2022 00:00:01 +0000 (UTC)
From: Lorenzo Salvadore 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654041601;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=;
	b=ifgJOYuCGNMEpiea5DAreRjiZUhnE6QUzt+hk1nYWfw2JHCcVl1RqXw7Z/6STzb9lizzf1
	VQskIeGqGcaKCDESvuwYaYegC5ZoNrrdbQUJGjRfZqNojjSjWZydZPsN0v+RjI461Cp+wX
	Fqgg2/MtzlmoNmedTxygLzfhOLqXA80kMwRdcWX5YiSeTrX/5pc+LgO7RbdhyMDgjzGrEE
	ILTMcxbWBdaHTUhkO/WZ5mmjVH6FAVaND7UCe5NEfmOAhw/wL3NdYBxSxCe90GD6TER93k
	8fZbOGJmeXvhk1nYsecHaVNY22gyEFwsfX8MAnw8nKPqRyYwCBSeME29h6Onww==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654041601; a=rsa-sha256; cv=none;
	b=IcoVGjI+cdEKpVBGFd9UvG9jy77Q5M/LNkJRWnfhzNN6sE9qh+DxbmUs04QyT4AftILIug
	IQqbg2uFerXwD43gKwLAwJc+J17W8t8cE+DOtaXBNJHFP7rW9bg2rPklZWwxIiXTY7JZYc
	iChkVwDduk/OSFABUjYYNArCf0CgFlVGGBle71xZXOI40pVCfv/hR+cIycZTYH7FG9wING
	OMCZ+i536NDB1Yiv7iiXHRTo1JqAzdU/Q7ri8qooVHNA8qsIv8S1yM3BVaht6eEuuIzCGS
	afWx9t1ShjTO/QAUiawZ1cpW6h+/JII6LDXVXqIBdVhrNhT5gtKdsL/qlCtR3Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
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

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
June, 30th 2022 for work done since the last round of Quarterly Reports:
April 2022 - June 2022.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the AsciiDoctor template, fill it in, and
email it to quarterly-submissions@FreeBSD.org.
The new AsciiDoctor template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc

We look forward to seeing your 2022Q2 reports!

Thanks,

Lorenzo Salvadore (on behalf of quarterly@)

From nobody Wed Jun  1 13:55:35 2022
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 0CBE31B43BD7
	for ; Wed,  1 Jun 2022 13:54:25 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic315-20.consmr.mail.ne1.yahoo.com (sonic315-20.consmr.mail.ne1.yahoo.com [66.163.190.146])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LCrH35byMz4njD
	for ; Wed,  1 Jun 2022 13:54:23 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654091661; bh=X0GW8TDqkm4dN8kw75Ud1LF3ys4gByOvxdMrr0t5dKI=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=FrRi9FJ/NGuA6b1Qg4qUPC/jBpu7QLt0BHKUgKYiGD6s2iV0qCeN0FRaC9VlwU4eOMTawyVLVte7Ioegu0ezYSbwJA6oOep7cSYnc1kqiy9L3OT666BIvvDomIxFvakgzpIzNbURO7uksF/+ntcfg4FAGAcBfzCORps25cDQNZsQ2ElYGtT+5qRITWYVhoAT1bfl5oHcCq14nnzpT6EHGgGM4Oz853MFlMD5ZL0Z2BxjNZt0YwR272gTP+C1OpjT9eK2eS9YliM4Uu8kO8iOsXIOvGJKrUjhQvNqxbi/K7gMQ0tumAPtPl9TRsRjEg0+0d/AgOaKNlVsk6B4nX0H0w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654091661; bh=hyZN4rh/qzlLkekwlh1rPigKb02/ERDrk2DEwcq1la6=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=XF+PZQ55nmhjobgL21A4TOmRVaS0GYH5NazphiU+CGYpNWgDGyI9XhT0d5dHI42GiqB3qMmfw/2vkAi8aI2wF9cv3o3fJ48ZD+ylUsHpmBDSYKUEQEJ8+C4lcM0IOa9i7xqdMFJAb+ifxmZdwowgwdiTaTlrCPen1c0e833fxt9V5f/pw5+WEHTaiP9A58VaHLieYOQnTQzrzbTH16/W+W+DuQiPevzI7vflJ/RRjE0F7HruDdHIPjBrYD+URYTRDbFMMFOskm7OI/yh7mB+nxLgYq2Hou7GmJQLFecxBXxSGWvTy3yvWxqzAO1zlsCqjJNGY5fS3hsiOtIo1ClISg==
X-YMail-OSG: kB_QCjEVM1mwmjcUnm0C.pdgIaPcapRU6T8ceyRRsVQohlN7Q19eTrujrLN.4Kr
 HXOOvrHYn2UmJG33dH4Hb.U6xfJ0jj_vUoKeP4f8WwIQs65xjDWgD7BYrNG2NfKlzgPl1AOjHwQi
 qszQ38n7WBSIYIKL2g0vsl6L8iwnIcZ534lRZs_ub4g1130mUWedSbLJo46Vp76uugK2MnSHcVaT
 1rxJTYwY7khIhDy7.2nywJ4h9LjMSTMExgHKgJtn1UHU.FnIe03nAKlN1XCY7YttyQDk9X9AAMBe
 aIxewiVnaq3SS5m_9KQQHAy_oC97CbFb_yT3kvk4OFDwp4wU.iCW0UH4hxMTAqNWgGyGmCsIMCJ_
 9DAnG6wD1Fqiv_WouDve_tbQeDcGR0dG8yL0odxY_3z2HGcSVtXshnGbEgxmgngZNDZRny8FxbBp
 Evu1HP8IOkXhNv6a4UbCopYztoqoteALPUBNlf5T299ahv6Rxz3MEUg.ytbUMRUzdg9pm4xw7ab4
 nu.BTjqHeWemoAA9xYNb3IsHhY991BnAtCeA0Mnvcwn8pzap06zb6CPy3A0B0O.LJm3Dd2cwuk95
 0hFoNCLhPk3on8_cPm7rnx.Yj49PDTptng7.BtmF87OxOm3zO0LpIJA3.xizJVsSJsqvJksJAOWL
 W.xNrm41zxkYfYi0Z8cSLlscxTlUGp7pZl1pVtwjxPeI1C_2VGovu0Ul9_OrnUsHR2SoxXxeu9VB
 sgNcRTlmId01CGvOgSt8U3VvOh4.M7yH_nNiQUDjq6tDjmYlir.E4JlMvB2Z8ukXwZjE4RGfUBZQ
 QfiC8Iy4uVu1XwqihPxVkjnqNGzHfAcOFUrmYl.xyQBDoLWoHRF118foG8ZKEX0gqgVS8yTo4NM8
 vVhejoq.iBBGqFuBbqZr4hE5UtuRZkhRz9jeZobAfh_5kURUdo_A_irJF4YgT1XkmLTmAMvJisqV
 JzubZxKnVd8aaiEof71czV62LfCPe8uLecJ9E7_4171XnGLcD9oJQPuk3SNHtjB3vAlb3tjEt_hu
 njO5sux99Ph9_ev08bXPC1uMI1wMi3xI7qFV970ZztuZpBasPa1DT62pY.an0isQAm3H67tdXi30
 pl1Vrck.XlQojsi8PhIKPE026tUaLU2pdOJH2kQ3t0VOogAW142V4vp8Hi4BqDDlFtKXJEp5cIjn
 ZfUIoDBcmjaixtLjw.bBeMpe2uhR8gZtxT381c2tJMXmkoqrMEmBdBLzeyQSlaXE1NAU3nPkr5qj
 OUqzaju0N7ml4AOOmw0ae4g0SQzTkV_keJbeZ66CjDii6Ns.VuwOWCYakd0PCFfpWdHsuweljCZA
 c1l9TNNN2suUGJMMrxMzLwvmCdX1Fl0uyKfYkqraYroiBgIjiS4yYY4_QDSabFgrY_T_xeVH41jO
 9j6SCTQLb66LD_iYoMnhx8_OF_bQ2RB5blpNydNX3XKKH8FJp_Jb_Yh.xiGA2iUCUNEjtI8bUSP3
 ZXFY5F2Cm4QAxd4NlP1TBl4niVXm0uELMu.9Nyah0dCRlHzHJPA6LwsER13v4F09aGAS9YoowuYB
 t5Jhv0DYPETw76yE6GBKUyWhnyxgleDEcOE9kK9Flusp8iWoseg6cEQFKFcdgIjvkBLvgBAFz.Mb
 Sbt8UkSzS7bnO1wcSieK09V6488hq9g5utoFlf6LyqyidshizghafsdKJdQkGBAW8QoTDcUmIJ9m
 ufPZVOn5cNd2mfAzgeLkbDU8hAaT9AQBZAf_paH_SXmWsTYSpK7WCPMpN45t9CwD1jm_lpuM7b5c
 4hGnhz6ntMIZ_PPDFY78uLuzyn.jlIFHh8o3IuNC3fpdeGuBMhEJlLBuRbUDx_DBtV_YnjsVbFtQ
 tQspjOy_aFxxRPOHxvNl.zLIfsY5uS3kjVsPTkSImJ16i7GCEmyUVmimeaX8ugNpudhaln8wPurM
 F.RmYVR_OKV6h.J9I1wiGSQmmktvw3KN_nciUZXD7iLOj6ke9KyD1BuFN.UsCPG_8utlmKFTV1sd
 zDvcozdmQlaEeRnBaoxKUvAQb67CGRlWQ1z4MF8.RPDiV._jc9lF_z705.bb9nfIoHE1zroHkzIr
 j3We7d2ZGx_UlNWpRx0tIEPdaIgM6_iJsR15ysCHLNhp7sNu028HUZHUiQAgZKjjnT8MZRwAe3T4
 2bnFP9p3htLMXR63f2desu.qo
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Wed, 1 Jun 2022 13:54:21 +0000
Date: Wed, 1 Jun 2022 13:55:35 +0000 (UTC)
From: Filippo Moretti 
To: FreeBSD Current 
Message-ID: <667552683.5711890.1654091735450@mail.yahoo.com>
Subject: Problem booting current
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_5711889_1169062071.1654091735449"
References: <667552683.5711890.1654091735450.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.20225 YMailNorrin
X-Rspamd-Queue-Id: 4LCrH35byMz4njD
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="FrRi9FJ/";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.190.146 as permitted sender) smtp.mailfrom=filippomore@yahoo.com
X-Spamd-Result: default: False [-3.89 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[66.163.190.146:from];
	 NEURAL_HAM_SHORT(-0.90)[-0.895];
	 MLMMJ_DEST(0.00)[current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_5711889_1169062071.1654091735449
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I installed CURRENT with memstick of May the 27th.I tired first UEFI and al=
l I got was a flashing - on screenI then tried BIOS+ UEFI and I get a mount=
root prompt=20
due tozfs:zroot/ROOT/default failed with error 22=C2=A0 (wich is the same e=
rror I got from current a few days ago)reported in a previous message.Are t=
here other setting I could try?SincerelyFilippo

------=_Part_5711889_1169062071.1654091735449
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


I installed CURRENT with memstick of May the 27th.
I tired first UEFI and all I got was a flashing - on screen
I then tried BIOS+ UEFI and I get a mountroot prompt 
due to
zfs:zroot/ROOT/default failed with error 22  (wich is the same error I got from current a few days ago)reported in a previous message.
Are there other setting I could try?
Sincerely
Filippo

------=_Part_5711889_1169062071.1654091735449--

From nobody Wed Jun  1 14:06:58 2022
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 F09871B47765
	for ; Wed,  1 Jun 2022 14:07:12 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from pv50p00im-tydg10021701.me.com (pv50p00im-tydg10021701.me.com [17.58.6.54])
	(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 4LCrYr1TCcz4rCj
	for ; Wed,  1 Jun 2022 14:07:12 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1654092425; bh=Dednb7eWuI/nhrSCshfhxDZtMBg8XRtrbIxhsjJhFak=;
	h=Content-Type:From:Mime-Version:Subject:Date:Message-Id:To;
	b=huehW7lck4U1IJGTGN5KrqQZfUuWCA42SUwJ1zZM+FiKRzMUleC9avUIn6xR9yNh1
	 n8gHlNkHb/qHAN/Y5jT0yCIteQsG6irJ6AP9uECdqz8pdaogLp3YNFQIx8sTscioWx
	 ORCzAPD3Q4Gbtqi99aDBfG1rGFebEwtz67eBUhqFB786OQlxPQpEllqQT6pTiT9+pm
	 2sJWpGG2SMIbmSaATgml8X2GblDX01THqxSqg1gZiBFr0lp5yE192lLOyYxZdvUd6R
	 Q9yRziJLBgxG2N6IozebHXDjZ3+fkSOTmNMgqbLdhDVb8bhdwJQqkJr2eHIAc3R6kW
	 /weNDPpY/uPNA==
Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10])
	by pv50p00im-tydg10021701.me.com (Postfix) with ESMTPSA id 0696C3A0E1E;
	Wed,  1 Jun 2022 14:07:02 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-7E7A14C1-056F-4EFD-B3D4-3118CAA565E4
Content-Transfer-Encoding: 7bit
From: Toomas Soome 
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 (1.0)
Subject: Re: Problem booting current
Date: Wed, 1 Jun 2022 17:06:58 +0300
Message-Id: <35EAA600-C448-42EC-A420-89965923ADE1@me.com>
References: <667552683.5711890.1654091735450@mail.yahoo.com>
Cc: FreeBSD Current 
In-Reply-To: <667552683.5711890.1654091735450@mail.yahoo.com>
To: Filippo Moretti 
X-Mailer: iPhone Mail (19F77)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.874
 definitions=2022-06-01_05:2022-06-01,2022-06-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0
 mlxlogscore=948 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-2009150000 definitions=main-2206010066
X-Rspamd-Queue-Id: 4LCrYr1TCcz4rCj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=huehW7lc;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.54 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-3.39 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FREEMAIL_FROM(0.00)[me.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[me.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine];
	 NEURAL_HAM_SHORT(-0.80)[-0.803];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 RECEIVED_SPAMHAUS_PBL(0.00)[17.56.9.10:received];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[me.com];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.986];
	 R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	 FREEFALL_USER(0.00)[tsoome];
	 FROM_HAS_DN(0.00)[];
	 DWL_DNSWL_NONE(0.00)[me.com:dkim];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.54:from];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MLMMJ_DEST(0.00)[current];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail-7E7A14C1-056F-4EFD-B3D4-3118CAA565E4
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

If you boot cd/usb, zpool import -N zroot, then zpool get all, post the outp=
ut.

Sent from my iPhone

> On 1. Jun 2022, at 16:54, Filippo Moretti  wrote:
>=20
> =EF=BB=BF
> I installed CURRENT with memstick of May the 27th.
> I tired first UEFI and all I got was a flashing - on screen
> I then tried BIOS+ UEFI and I get a mountroot prompt=20
> due to
> zfs:zroot/ROOT/default failed with error 22  (wich is the same error I got=
 from current a few days ago)reported in a previous message.
> Are there other setting I could try?
> Sincerely
> Filippo

--Apple-Mail-7E7A14C1-056F-4EFD-B3D4-3118CAA565E4
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

If you boot cd/usb, zpool import -N zroot, t=
hen zpool get all, post the output.

Sent from my iPh=
one

On 1. Jun 2022, at 1=
6:54, Filippo Moretti <filippomore@yahoo.com> wrote:

=EF=BB=BF
I installed C=
URRENT with memstick of May the 27th.
I tired first UEFI and all I got was a flashing - on screen
I then tried BIOS+ UEFI and I get a mountro=
ot prompt 
due to
zfs:zroot/ROOT/default failed with error 22=
  (wich is the same error I got from current a few days ago)reported in=
 a previous message.
Are there o=
ther setting I could try?
Sincer=
ely
Filippo
=

--Apple-Mail-7E7A14C1-056F-4EFD-B3D4-3118CAA565E4--

From nobody Sat Jun  4 07:54:08 2022
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 E38401B54E00
	for ; Sat,  4 Jun 2022 07:54:22 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LFX8D6F6zz3JXl
	for ; Sat,  4 Jun 2022 07:54:20 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50])
	(authenticated bits=0)
	by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 2547s9Qk067961
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
	Sat, 4 Jun 2022 09:54:10 +0200 (CEST)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl;
	s=plan-b-mailer; t=1654329250;
	bh=xbIzqxGi6ilT1wKbpze4cOmVmyGq2A6euR5w24s4cic=;
	h=Date:To:References:From:Subject:In-Reply-To;
	b=j1CuiKT1OaOUyquQJw6QhtrUObaU6Iw/9LypBs5eL2HtzDPQb/CTXZewAB6bpKXDf
	 SeOI6NDXzHgFWROSmLpTnXLCFI3P7/NUOCNbXRxeYzrp49pJd5YwuJ0uvjGgnhqZ0d
	 gR/Bba793OMR3AeQ5oLk2hOt/2EDB5kiZlbgnpmU17fHYa+64IAAQVxoHIb49SxwHS
	 qJ19sfYb/60zCe4l+XGitKOKfarRClxtkKtH42N329xwXS9EERNGIy6PVo6s77/ctJ
	 moRtScTnVs6a5xxAXKc6v96PYkoJ5MotyTdOoucAcrg4pCXETBqGn7Y8hGnz09caTU
	 XnVANTJzeQ3EQ==
X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70]
Message-ID: <7e0e0a93-62c4-1ecc-c227-d0501a920143@plan-b.pwste.edu.pl>
Date: Sat, 4 Jun 2022 09:54:08 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Content-Language: en-US
To: Rozhuk Ivan , freebsd-current@freebsd.org
References: <20220604023958.1044ac84@rimwks.local>
From: Marek Zarychta 
Subject: Re: exec(btxld) failed (No such file or directory) and obj via nullfs
In-Reply-To: <20220604023958.1044ac84@rimwks.local>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------uw3eSIoArbxiVeU7os0Vu3JG"
X-Rspamd-Queue-Id: 4LFX8D6F6zz3JXl
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=j1CuiKT1;
	dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl;
	spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl
X-Spamd-Result: default: False [-5.80 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 HAS_ATTACHMENT(0.00)[];
	 HAS_XAW(0.00)[];
	 DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+];
	 MIME_BASE64_TEXT(0.10)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none];
	 SIGNED_PGP(-2.00)[];
	 FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+,3:~];
	 ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 R_SPF_NA(0.00)[no SPF record];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------uw3eSIoArbxiVeU7os0Vu3JG
Content-Type: multipart/mixed; boundary="------------D0nmrTkiHIdFoBQvp3cnaHFq";
 protected-headers="v1"
From: Marek Zarychta 
To: Rozhuk Ivan , freebsd-current@freebsd.org
Message-ID: <7e0e0a93-62c4-1ecc-c227-d0501a920143@plan-b.pwste.edu.pl>
Subject: Re: exec(btxld) failed (No such file or directory) and obj via nullfs
References: <20220604023958.1044ac84@rimwks.local>
In-Reply-To: <20220604023958.1044ac84@rimwks.local>

--------------D0nmrTkiHIdFoBQvp3cnaHFq
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

VyBkbml1IDQuMDYuMjAyMiBvwqAwMTozOSwgUm96aHVrIEl2YW4gcGlzemU6DQo+IEhpIQ0K
Pg0KPg0KPiBJIGZvdW5kIGEgd2F5IHRvIGZpeCBlcnJvciBkdXJpbmcgaW5zdGFsbDogZXhl
YyhidHhsZCkgZmFpbGVkIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQ0KPiBpbiBjYXNl
IG9iaiBpcyBudWxsZnMgbW91bnRlZC4NCj4NCj4NCj4gVXNlIG9wdGlvbjogLW8gbm9jYWNo
ZQ0KPiBtb3VudF9udWxsZnMgLW8gcncgLW8gbm9jYWNoZSAtbyBub2F0aW1lICIke01BS0VP
QkpESVJQUkVGSVhfVE1QfSIgIiR7TUFLRU9CSkRJUlBSRUZJWH0iDQo+DQo+DQo+IFRoaXMg
aGVscHMgZm9yIG1lLCBob3BlIGl0IHdpbGwgYmUgdXNmdWxsIGZvciBjb21tdW5pdHkuDQo+
DQo+DQo+IFBTOiB0aGlzIHdvcmtzIGV2ZW4gd2l0aG91dCBodHRwczovL3Jldmlld3MuZnJl
ZWJzZC5vcmcvRDIzNDExIHBhdGNoLg0KPiBJIGRvIG5vdCBkaWcgaW5zaWRlIHRoaXMgYW5k
IGhhdmUgbm8gaWRlYSB3aHkgdGhpcyBvcHRpb24gdW5kb2N1bWVudGVkLg0KPiBQcm9iYWJs
eSB0aGlzIHNvbWUga2VybmVsL251bGxmcyBidWcgdGhhdCBtdXN0IGJlIGludmVzdGlnYXRl
ZCwgb3IganVzdA0KPiByZW1vdmUgb3B0aW9uIGFuZCBtYWtlIGl0IGFsd2F5cyBlbmFibGVk
Lg0KDQpUaGUgYnVpbGQgcmFjZSBoYXMgYmVlbiBmaXhlZFsxXS4NCg0KU2luZSB0aGVuIEkg
YW0gbm8gbW9yZSBlbmNvdW50ZXJpbmcgcHJvYmxlbXMgd2hpbGUgYnVpbGRpbmcgdG8gbnVs
bGZzIA0KbW91bnRlZCBPQkpESVIsIGF0IGxlYXN0IGluIENVUlJFTlQgYW5kIDEzLVNUQUJM
RS4NCg0KWzFdIA0KaHR0cHM6Ly9jZ2l0LmZyZWVic2Qub3JnL3NyYy9jb21taXQvc3lzL2Zz
L251bGxmcz9pZD00Mjg4MTUyNmQ0MDFlN2E5YzA5MjQxZTM5MmI3ZmZhMThjZmUxMWQ2DQoN
Ci0tIA0KTWFyZWsgWmFyeWNodGENCg0K

--------------D0nmrTkiHIdFoBQvp3cnaHFq--

--------------uw3eSIoArbxiVeU7os0Vu3JG
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmKbD6AFAwAAAAAACgkQHZW8vIFppoJI
Xwf/VohTXjtmg5xGuKLNzhZHaDRfjDlSQ3j0TAstSMgC3yfHE7LSnYHDIR3lfA2aLD3Ll3FDaRXU
uaG0VDHgG+JwNvy8MjRB2WBCBQLH20CELtLaqDwQ4NvQ0BzU2gAigLn9iDE7zIWiXVibQO2J9ZfJ
ylH72yGHEUDyGH1wfxE8GKWxANpuvr9J/3ZlaTx9ANDNJD94XY9uHnDBmoqTtpIWUze2VdYe9hLE
WpHD3rcf1H9jdVFNyplwXqWNH5UfqJj4K0EheLliLvskMDBvEEetCGcVQ09datZiZLNNAz44VN0n
cuuiaBPnHyWti4Dz9Kr3GesenwVRdc9rAfGspH39eA==
=KUXp
-----END PGP SIGNATURE-----

--------------uw3eSIoArbxiVeU7os0Vu3JG--

From nobody Sat Jun  4 12:25:12 2022
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 88A251BD6609
	for ; Sat,  4 Jun 2022 12:26:26 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LFfB93Zkjz4nqp;
	Sat,  4 Jun 2022 12:26:25 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1654345585;
	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=L7y3sIT3a/z3hofzsk9DhN3AoGpawU7Grq/xJ3T39rI=;
	b=cDo/rikJLQambz4jQuSs0M+0PXJX9RIMB21YhIT0e14tjBUW28zVkWdZkevZUfi0XA82a9
	pd9cclP15704vfeZV2bediHsll85ZnyQckuOBFfoEW5AFTJPQ6LrB/3RFtPIZZOZqdP1yI
	RJw+YpT6DPPqY6CpRuDG6ElJ2BD/ff0RnN27f3a3PkvnVDy1peSfTlF9+t51isMu4DPyNa
	BnNuZN411glq09eG7vTE2wP52onIfpSaF+ke1KAD4+iQsPQUvWBZLOytSl4Gqy2+Q637Pg
	7xNzsWDa4+NV6c2v8Q2ehfBcgYa6WIybubCjSdULYyY7hT20Z0BXmeNJgbD3gw==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:8cfc:5adf:8a34:e6c8])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 50E62E6BA;
	Sat,  4 Jun 2022 12:26:23 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Sat, 04 Jun 2022 21:25:12 +0900 (JST)
Message-Id: <20220604.212512.1183180807227243032.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Kernel crashed with "panic: VERIVY(e->lse-mscount != 0) failed"
From: Yasuhiro Kimura 
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654345585;
	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=L7y3sIT3a/z3hofzsk9DhN3AoGpawU7Grq/xJ3T39rI=;
	b=i5GSCFMB9HlcdKnQZviRZJpvyOuJ3h3lPzSfh3yH6UCrJghLVeo5GBwv9V1aAv0Bjnusoc
	GOmL14gbN51cIdAivGPcOp1pjOqCKZ9WZhFjlUBIo2LBje2NxsWQB6e8yofUizIKdtPwnA
	KA2h5/BoN3ZJ5c2QpnazkyeQpSiACUKkIYpjQiRdAExnpWOWyT7pLFubqZDX3abYaHEytl
	LiLHB9X4NMhJQl4knVCuprwfXkHUvt0qIn5nm3LuZwICd51EigTtL/g776BTFvYBvGM1VF
	tAaBnAhFGRnYxsAcCwZJlntCYpTYxQIOC7UpY9xt+xsK+zEh8LNCXdJCWT3hhQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654345585; a=rsa-sha256; cv=none;
	b=XYepVB/Kwt9x3fCr7XH1mD185NPxMP+3Wq81EQ1CzWiFJlVTKASz9LDs5bR/Az3D3FjNXi
	KGMFjCkgE5r2U6Ersj7IYbCvRemRwlYKdI1KGmC9slpgFH5Gz6Z5ooPW56iYXkQlMkb0LE
	7hS9lb/FPiqfEJK8mWJ8+WAkSrSgND4vhD8lIyKE2ArplJHN8jiaOwimirdMpLJ/cVeoAJ
	+h9hCWY0zLtXBnWgJ1lndvYLbbUDAXZjr7C3d8B4Qq2+rE94+e25sWFN4QRqOqr18jbaxp
	RsxXE28/QLRah6wJxAnOFpCId7pFsAaswCSuhF1ANEicDCQrJk7G3fyaiJIAdA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

Hello,

yasu@rolling-vm-freebsd1[1154]% uname -a
FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n255944-645886d028c: Sat Jun  4 01:44:38 JST 2022     rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

While building packages with poudriere kernel crashed with following
message.

panic: VERIVY(e->lse-mscount != 0) failed

Snapshot of console:
https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220604.png

Best Regards.

---
Yasuhiro Kimura

From nobody Sat Jun  4 14:14:12 2022
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 928D01BE304D
	for ; Sat,  4 Jun 2022 14:14:17 +0000 (UTC)
	(envelope-from yuri@aetern.org)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20])
	(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 4LFhZc2jJ4z3FSZ
	for ; Sat,  4 Jun 2022 14:14:16 +0000 (UTC)
	(envelope-from yuri@aetern.org)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
	by mailout.west.internal (Postfix) with ESMTP id 598923200312
	for ; Sat,  4 Jun 2022 10:14:15 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
  by compute5.internal (MEProxy); Sat, 04 Jun 2022 10:14:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc
	:content-transfer-encoding:content-type:date:date:from:from
	:in-reply-to:message-id:mime-version:reply-to:sender:subject
	:subject:to:to; s=fm3; t=1654352054; x=1654438454; bh=5ClgGAlSoB
	CVA9oq+z+o06Nv5259QElWGCWdmiX/f3U=; b=fre676LLU9Xf7PgYYxm9LJMSzo
	TwgOQ+4tWtBWFBqox4NUCKAfe3Z4cnzMoJniz2OLmDExpsCoE0suKCupP1v4jwli
	LIbimqE3AhF12kK/wr1G81lBBpQSp76vj16w749p1aQ9vSrCJKcW6pxcrJzbw72V
	j9JBV9osG/oLAwXd65wgUaTmwNzb3B1pSHsXrm7KPEYCd0Y2G0Lk1VXy9J5Ik5Ji
	T4nSJ0xq/rqEjvs2PnPTdLrM3+3wLeoPTd9hgCbGVCbZhzoae08OkA2/46xbO3Rn
	Bmxlk8lT5+rpe4PiLd3XGheyDbJqdf6mP/Wa+QUF7tl/6APZh/OK46i8+jSA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-transfer-encoding:content-type
	:date:date:feedback-id:feedback-id:from:from:in-reply-to
	:message-id:mime-version:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; t=1654352054; x=1654438454; bh=5ClgGAlSoBCVA9oq+z+o06Nv5259
	QElWGCWdmiX/f3U=; b=vISrmPCtyxbtS32D4f7Kxld+CosTQBVBeALqRYc4Gb0W
	oNteKo+yOzA4NojbXtTZoL+b0boTj4hONdV5l0yzb47NA+D5qUij+8irQ9lGE0AS
	c679F4RYSRjf9PcZn/1ZMUgfeNaPwYRL/3cAlfT9z+6sD+b80lq5JLxY0dNxByk2
	uoLwXV8J7oymwpdBBz/2d/N+pqsmQ+T/qiLWswQL7ba2yrKDxWw7tfs+DAz+PfKu
	3YBLu02Ny2Dez1UCFGnyqXi0c/BQk+ahyLvfWX9piH/yrJsWZYvX9pWeZhd4xnEf
	e7XQmHINJH9M2crRb17nWAjVP8kwZyArQmSrnP64FQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrleekgdejhecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfvffhufgtgfesthejredttd
    efjeenucfhrhhomhepjghurhhiuceohihurhhisegrvghtvghrnhdrohhrgheqnecuggft
    rfgrthhtvghrnhepffevffefgfetuedukefhfedvhfejtefgjeffffeitedvhfefjeffke
    elgeejffdtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho
    mhephihurhhisegrvghtvghrnhdrohhrgh
X-ME-Proxy: 
    
    
    
Feedback-ID: i0d79475b:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Sat, 4 Jun 2022 10:14:14 -0400 (EDT)
Message-ID: 
Date: Sat, 4 Jun 2022 17:14: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/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Content-Language: en-US
To: current@freebsd.org
From: Yuri 
Subject: panic: make_dev_alias_v: bad si_name
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LFhZc2jJ4z3FSZ
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=aetern.org header.s=fm3 header.b=fre676LL;
	dkim=pass header.d=messagingengine.com header.s=fm1 header.b=vISrmPCt;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 64.147.123.20 as permitted sender) smtp.mailfrom=yuri@aetern.org
X-Spamd-Result: default: False [-4.60 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20:c];
	 TO_DN_NONE(0.00)[];
	 RCVD_COUNT_THREE(0.00)[4];
	 DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[aetern.org:s=fm3,messagingengine.com:s=fm1];
	 FREEFALL_USER(0.00)[yuri];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.1:email,0.0.0.0:email];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 DMARC_NA(0.00)[aetern.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	 DBL_PROHIBIT(0.00)[0.0.0.1:email,0.0.0.0:email];
	 MLMMJ_DEST(0.00)[current]
X-ThisMailContainsUnwantedMimeParts: N

Getting the following panic on HPE system with HPE enclosure:

panic: make_dev_alias_v: bad si_name (error=22,
si_name=enc@n....../type@0/slot@1/elmdesc@{"Name":"DriveBay1"}/pass4)

db_trace_self_wrapper()
vpanic()
panic()
make_dev_alias_v()
make_dev_alias_p()
make_dev_physpath_alias()
pass_add_physpath()
taskqueue_run_locked()
taskqueue_thread_loop()
fork_exit()
fork_trampoline()

I have skipped typing all the frame information as the cause of panic
seems to be apparent -- enclosure replies with "Name":"DriveBay1" via
ses (it does the same weirdness for sensors and other elements), and
make_dev_alias_v() does not like the double quotes.  Probably we need to
sanitize the input somewhere?

From nobody Sat Jun  4 18:38:44 2022
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 5BED91BE9A62
	for ; Sat,  4 Jun 2022 18:38:57 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LFpS00b81z3w65
	for ; Sat,  4 Jun 2022 18:38:55 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe2a.google.com with SMTP id 68so10228017vse.11
        for ; Sat, 04 Jun 2022 11:38:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=+RAofBvF7PXUkOEwV8bOjl0vZgfzh3tQd0a74lClFHk=;
        b=toddpk7nbsBVUJ/SrOttsJf15Hy+zrn7p2ddj3gS+lMPMMQNoRwvJSOyZF89JDAkk4
         Sjek8SYmIgkYppOlN+5LQ1CHczixDt/bQjR/gn5a3TSQTXVTxf6DlTPau8iXLyZlTdlR
         leYBnli+LEL0P6vpwz4MH9o2lCfqBJUUaEeRSASf28I3W06D5QxaB3RKaI1Pk2fDPU1H
         e5QJ2CQgLVxPmHeGv/W1mJSV8mrYdvDv6T+IcDQdX/3tEIfkav+cgqiwm4ZiFIgNokZe
         yBUMbUGGc9x7RGriiPtWmqmXh3ffNy6MJqoLOHbClBvzuGM++QaAcBDVKMHvMpGLdmhS
         JfRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=+RAofBvF7PXUkOEwV8bOjl0vZgfzh3tQd0a74lClFHk=;
        b=QQc2fHk6pc0/0eLWFlGbCWisiZQa7xfl8NRUYv5DUjvsybFmjyEYBfy/To0addEvZp
         JM6Bsjvf1c2So1XRWT5/xmwZ4llhUT5RNjI50S5bdjhPGj/w7CpGrB+xLDQRObGiP2hh
         cSqq69Va8r2l2UPgeKhSgPlXFuOtG+q2dwucQRs79NWKWUyd7nIS/2Bn8z6SW38J35ht
         Z2fL714t1NRjw2Ceb4LFW6m36fEr3WSHSi9ij1LiGvCQe9H/Bd6JA2ZnxOvozckDxdJ5
         poQr8blHsGs8lGsbahqB6eDolHD0wfwC/4uIIh7rD5EIc5a4P8jaVwXHBs7ascY4hEZ7
         WAtA==
X-Gm-Message-State: AOAM530HBTYCq9WAK8Mam8Hf8EoQXAIzQhM8sjXw7z1MpScVhIVZd7RL
	yh485aMjpHw6NlEFw/xVcH47Fg60bSFeD7tHl06AU5R6YDE=
X-Google-Smtp-Source: ABdhPJxl24Qf+yEr/q+wd82F2bcMMDmPdxUsT0dtVAC0cAF1AHWYKses98J8bc3ltRf1kN9cC8mp7seL9Jd7rpdXAes=
X-Received: by 2002:a67:ec12:0:b0:349:e09e:da0c with SMTP id
 d18-20020a67ec12000000b00349e09eda0cmr10848035vso.27.1654367935264; Sat, 04
 Jun 2022 11:38: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: 
In-Reply-To: 
From: Warner Losh 
Date: Sat, 4 Jun 2022 12:38:44 -0600
Message-ID: 
Subject: Re: panic: make_dev_alias_v: bad si_name
To: Yuri 
Cc: FreeBSD Current 
Content-Type: multipart/alternative; boundary="0000000000001c0fe805e0a38d90"
X-Rspamd-Queue-Id: 4LFpS00b81z3w65
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=toddpk7n;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2a) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.98 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.983];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.1:email,0.0.0.0:email];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 DBL_PROHIBIT(0.00)[0.0.0.1:email,0.0.0.0:email];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2a:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000001c0fe805e0a38d90
Content-Type: text/plain; charset="UTF-8"

On Sat, Jun 4, 2022, 11:13 AM Yuri  wrote:

> Getting the following panic on HPE system with HPE enclosure:
>
> panic: make_dev_alias_v: bad si_name (error=22,
> si_name=enc@n....../type@0/slot@1/elmdesc@{"Name":"DriveBay1"}/pass4)
>
> db_trace_self_wrapper()
> vpanic()
> panic()
> make_dev_alias_v()
> make_dev_alias_p()
> make_dev_physpath_alias()
> pass_add_physpath()
> taskqueue_run_locked()
> taskqueue_thread_loop()
> fork_exit()
> fork_trampoline()
>
> I have skipped typing all the frame information as the cause of panic
> seems to be apparent -- enclosure replies with "Name":"DriveBay1" via
> ses (it does the same weirdness for sensors and other elements), and
> make_dev_alias_v() does not like the double quotes.  Probably we need to
> sanitize the input somewhere?
>


Likely.  I'll take a look. Can you file a bug, include CAM in the title and
cc imp@ please?

Warner

>

--0000000000001c0fe805e0a38d90
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sat, Jun 4, 2022, 11:13 AM Yuri <yuri@aetern.org> wrote:
Getting the following panic on HPE system with HPE enclosur=
e:



panic: make_dev_alias_v: bad si_name (error=3D22,

si_name=3Denc@n....../type@0/slot@1/elmdesc@{"Name":"DriveBa=
y1"}/pass4)



db_trace_self_wrapper()

vpanic()

panic()

make_dev_alias_v()

make_dev_alias_p()

make_dev_physpath_alias()

pass_add_physpath()

taskqueue_run_locked()

taskqueue_thread_loop()

fork_exit()

fork_trampoline()



I have skipped typing all the frame information as the cause of panic

seems to be apparent -- enclosure replies with "Name":"Drive=
Bay1" via

ses (it does the same weirdness for sensors and other elements), and

make_dev_alias_v() does not like the double quotes.=C2=A0 Probably we need =
to

sanitize the input somewhere?


Likely.=C2=A0 I=
9;ll take a look. Can you file a bug, include CAM in the title and cc imp@ =
please?

Warner=C2=A0




--0000000000001c0fe805e0a38d90--

From nobody Sat Jun  4 19:34:57 2022
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 EFFFF1BEF8ED
	for ; Sat,  4 Jun 2022 19:35:09 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LFqhr5qjSz4VwY
	for ; Sat,  4 Jun 2022 19:35:08 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: by mail-oi1-f171.google.com with SMTP id m82so14549309oif.13
        for ; Sat, 04 Jun 2022 12:35:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=QnSoRKO6M+xe8poparavlqpAVRCjWD6Ab5grtvJVC14=;
        b=jJTKd1Mn1xjHNXAKO/mom8l20+PLAS78QBKqgRTKhIOiLkX1/WODmp9aVq0mFyRyV1
         KFufedm05zFgLjVKCqkjhz0Ym2dTl1NvgCtdDJhScvEk0jKmaE7Ke5tz9VSnvOUPjJYu
         BPzdDVO+xPhcm0v4UUJXAZTAkydsd1j2pD3/JVIPrxxnL1jwJF+uu+p5zyb7IyqEjFA1
         pcOtK/1jy9Ugp6T/8Qp8J4/fjth3FoL7XvMXAVs3K3gc1xm6R3TiquUapNAVZLzJ1dYw
         j4yopQB+c9xZROG+vCgXkm9QM4k/f9lJQfHkcxmUJ2wROHyKLq22FtvgGshtzqO6OyWp
         YZmw==
X-Gm-Message-State: AOAM5322VLKO/ADPNR/9CPXZ5BTENpMyWnquBm0Hhmkopz19NSJYYIJO
	98AF/gpbcu9u8cEQMVwpcQCKngTuiwrm77E+7b87V6UH
X-Google-Smtp-Source: ABdhPJysY2t8gZv1zAYGu/lNBtx445p2yajEBu2Dj+ccqTjZ5moDhDjYEvg2oEwfBf4PUKUvOIas0tNzX5uLZNLPG4M=
X-Received: by 2002:a05:6808:13d0:b0:32b:d458:4979 with SMTP id
 d16-20020a05680813d000b0032bd4584979mr22866782oiw.72.1654371308127; Sat, 04
 Jun 2022 12:35: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: Alan Somers 
Date: Sat, 4 Jun 2022 13:34:57 -0600
Message-ID: 
Subject: Re: panic: make_dev_alias_v: bad si_name
To: Warner Losh 
Cc: Yuri , FreeBSD Current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4LFqhr5qjSz4VwY
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.171 as permitted sender) smtp.mailfrom=asomers@gmail.com
X-Spamd-Result: default: False [-2.92 / 15.00];
	 R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-0.99)[-0.987];
	 FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	 FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.94)[-0.936];
	 FREEFALL_USER(0.00)[asomers];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email,0.0.0.1:email];
	 NEURAL_HAM_LONG(-0.99)[-0.994];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 DMARC_NA(0.00)[freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DBL_PROHIBIT(0.00)[0.0.0.0:email,0.0.0.1:email];
	 RCVD_IN_DNSWL_NONE(0.00)[209.85.167.171:from];
	 MLMMJ_DEST(0.00)[current];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.171:from];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Jun 4, 2022 at 1:04 PM Warner Losh  wrote:
>
>
>
> On Sat, Jun 4, 2022, 11:13 AM Yuri  wrote:
>>
>> Getting the following panic on HPE system with HPE enclosure:
>>
>> panic: make_dev_alias_v: bad si_name (error=22,
>> si_name=enc@n....../type@0/slot@1/elmdesc@{"Name":"DriveBay1"}/pass4)
>>
>> db_trace_self_wrapper()
>> vpanic()
>> panic()
>> make_dev_alias_v()
>> make_dev_alias_p()
>> make_dev_physpath_alias()
>> pass_add_physpath()
>> taskqueue_run_locked()
>> taskqueue_thread_loop()
>> fork_exit()
>> fork_trampoline()
>>
>> I have skipped typing all the frame information as the cause of panic
>> seems to be apparent -- enclosure replies with "Name":"DriveBay1" via
>> ses (it does the same weirdness for sensors and other elements), and
>> make_dev_alias_v() does not like the double quotes.  Probably we need to
>> sanitize the input somewhere?
>
>
>
> Likely.  I'll take a look. Can you file a bug, include CAM in the title and cc imp@ please?
>
> Warner

Also, it would help to include the output of "sg_ses -p7 /dev/sesXXX",
where sg_ses comes from sysutils/sg3_utils.

From nobody Sat Jun  4 21:21:11 2022
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 A6DB01BDD3EC
	for ; Sat,  4 Jun 2022 21:21:24 +0000 (UTC)
	(envelope-from imb@protected-networks.net)
Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.protected-networks.net", Issuer "R3" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LFt3R0r6gz4gbX;
	Sat,  4 Jun 2022 21:21:22 +0000 (UTC)
	(envelope-from imb@protected-networks.net)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=
	protected-networks.net; h=content-transfer-encoding:content-type
	:content-type:subject:subject:from:from:content-language
	:user-agent:mime-version:date:date:message-id; s=201508; t=
	1654377671; bh=F2BGXZLjVrdW6IYkekzdMEPsYiWSMPz1qw2z9nI7vgs=; b=f
	L3WT6r/Fm5glibYVzDLhHBWhltoKzY0rwEOe1IMiZAXHMYhWPdo1f6BRpvcepmon
	aFsOsKUU0wxHb9btqWjBfMO1axlsA4Ey+zWiUIB2SVroWKpfqsb7x9Sfz7pJJ4fy
	Ogl5ZTtVsbzfkaxw+8W2hbUSsb5RxUYMJpuZKtFjuk=
Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(Client did not present a certificate)
	(Authenticated sender: imb@mail.protected-networks.net)
	by mail.protected-networks.net (Postfix) with ESMTPSA id B30C1640E9;
	Sat,  4 Jun 2022 17:21:11 -0400 (EDT)
Message-ID: <4cff718d-6f0f-bde8-2077-c83f4adc84df@protected-networks.net>
Date: Sat, 4 Jun 2022 17:21:11 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Content-Language: en-NZ
To: freebsd-current 
Cc: manu@freebsd.org
From: Michael Butler 
Subject: commit 99902b1 causes kernel panics
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LFt3R0r6gz4gbX
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protected-networks.net header.s=201508 header.b="f L3WT6r";
	dmarc=pass (policy=reject) header.from=protected-networks.net;
	spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net
X-Spamd-Result: default: False [-4.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[protected-networks.net:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On a Dell E6430 laptop with an i5-3340M CPU on-board but no additional 
video adapter, this commit causes a panic when i915kms is loaded :-( 
This adapter does not use any additional firmware.

Reverting only this change allows me to run way past it - up to commit 
00b0158d2ca, so far.

All modules were recompiled to match.

/var/crash/core.txt contains ..

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address   = 0x19
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff808abe54
stack pointer           = 0x0:0xfffffe011920e9b0
frame pointer           = 0x0:0xfffffe011920e9b0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 3
current process         = 1274 (Xorg)
trap number             = 12
panic: page fault
cpuid = 3
time = 1654274788
Uptime: 57s
Dumping 749 out of 16251 
MB:..3%..11%..22%..33%..41%..52%..62%..71%..82%..92%

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" 
(offsetof(struct pcpu,
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  dump_savectx () at /usr/src/sys/kern/kern_shutdown.c:401
#2  0xffffffff808b0e88 in dumpsys (di=0x0)
     at /usr/src/sys/x86/include/dump.h:87
#3  doadump (textdump=)
     at /usr/src/sys/kern/kern_shutdown.c:430
#4  kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:537
#5  0xffffffff808b12fc in vpanic (fmt=,
     ap=ap@entry=0xfffffe011920e810) at 
/usr/src/sys/kern/kern_shutdown.c:975
#6  0xffffffff808b1183 in panic (fmt=)
     at /usr/src/sys/kern/kern_shutdown.c:899
#7  0xffffffff80c8712c in trap_fatal (frame=frame@entry=0xfffffe011920e8f0,
     eva=25) at /usr/src/sys/amd64/amd64/trap.c:942
#8  0xffffffff80c874d6 in trap_pfault (frame=0xfffffe011920e8f0,
     usermode=false, signo=, ucode=)
     at /usr/src/sys/amd64/include/cpufunc.h:411
#9  
#10 _rw_wowned (c=0x19) at /usr/src/sys/kern/kern_rwlock.c:270
#11 0xffffffff80bf1a0a in vm_page_busy_acquire (m=0xfffffe0005affec8,
     allocflags=allocflags@entry=16) at /usr/src/sys/vm/vm_page.c:888
#12 0xffffffff8271b9a1 in lkpi_vmf_insert_pfn_prot_locked (
     vma=0xfffff8015c3bc300, addr=, pfn=,
     prot=24) at /usr/src/sys/compat/linuxkpi/common/src/linux_page.c:297
#13 0xffffffff8252d390 in remap_io_mapping () from /boot/modules/i915kms.ko
#14 0xffffffff826449c6 in vm_fault_gtt () from /boot/modules/i915kms.ko
#15 0xffffffff82714e56 in linux_cdev_pager_populate (
     vm_obj=0xfffff80154cd1b58, pidx=,
     fault_type=, max_prot=,
     first=0xfffffe011920ec20, last=0xfffffe011920ec38)
     at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:692
#16 0xffffffff80bdb732 in vm_pager_populate (object=0x19,
     object@entry=0xfffffe011920ebb0, pidx=16, fault_type=1024,
     first=0xfffffe011920ec20, last=0xfffffe011920ec38,
     max_prot=) at /usr/src/sys/vm/vm_pager.h:182
#17 vm_fault_populate (fs=0xfffffe011920ecc0)
     at /usr/src/sys/vm/vm_fault.c:469
#18 vm_fault_allocate (fs=fs@entry=0xfffffe011920ecc0)
     at /usr/src/sys/vm/vm_fault.c:1162
#19 0xffffffff80bda47f in vm_fault_object (fs=0xfffffe011920ecc0,
     behindp=0xfffffe011920ecb4, aheadp=0xfffffe011920ecbc)
     at /usr/src/sys/vm/vm_fault.c:1414
#20 vm_fault (map=map@entry=0xfffffe012b5233f0,
     vaddr=vaddr@entry=35550920704, fault_type=fault_type@entry=2 '\002',
     fault_flags=fault_flags@entry=0, m_hold=m_hold@entry=0x0)
     at /usr/src/sys/vm/vm_fault.c:1549
#21 0xffffffff80bda07d in vm_fault_trap (map=0xfffffe012b5233f0,
     vaddr=, fault_type=,
     fault_flags=fault_flags@entry=0, signo=0xfffffe011920ef00,
     ucode=0xfffffe011920ef04) at /usr/src/sys/vm/vm_fault.c:667
#22 0xffffffff80c87345 in trap_pfault 
(frame=frame@entry=0xfffffe011920ef40,
     usermode=true, signo=0xfffffe011a70b318, 
signo@entry=0xfffffe011920ef00,
     ucode=0x3004, ucode@entry=0xfffffe011920ef04)
     at /usr/src/sys/amd64/amd64/trap.c:846
#23 0xffffffff80c86a75 in trap (frame=0xfffffe011920ef40)
     at /usr/src/sys/amd64/amd64/trap.c:385
#24 
#25 0x0000000839618c9f in ?? ()
Backtrace stopped: Cannot access memory at address 0x820718370
(kgdb)


From nobody Sun Jun  5 11:17:59 2022
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 83C101BEA217
	for ; Sun,  5 Jun 2022 11:18:08 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LGDcv0z3Rz3PBp;
	Sun,  5 Jun 2022 11:18:07 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [176.74.213.87])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 2455C2616CB;
	Sun,  5 Jun 2022 13:18:04 +0200 (CEST)
Message-ID: 
Date: Sun, 5 Jun 2022 13:17:59 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: commit 99902b1 causes kernel panics
Content-Language: en-US
To: Michael Butler ,
 freebsd-current 
Cc: manu@freebsd.org
References: <4cff718d-6f0f-bde8-2077-c83f4adc84df@protected-networks.net>
From: Hans Petter Selasky 
In-Reply-To: <4cff718d-6f0f-bde8-2077-c83f4adc84df@protected-networks.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LGDcv0z3Rz3PBp
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.25 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 NEURAL_HAM_LONG(-0.95)[-0.946];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 6/4/22 23:21, Michael Butler wrote:
> On a Dell E6430 laptop with an i5-3340M CPU on-board but no additional 
> video adapter, this commit causes a panic when i915kms is loaded :-( 
> This adapter does not use any additional firmware.
> 
> Reverting only this change allows me to run way past it - up to commit 
> 00b0158d2ca, so far.
> 

https://reviews.freebsd.org/D35403

--HPS


From nobody Sun Jun  5 13:33:21 2022
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 01A891BDE0F0
	for ; Sun,  5 Jun 2022 13:33:32 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LGHd71trPz3s2f;
	Sun,  5 Jun 2022 13:33:31 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: by mail-qt1-x82c.google.com with SMTP id hf10so8816559qtb.7;
        Sun, 05 Jun 2022 06:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:message-id:date:mime-version:user-agent:subject
         :content-language:to:references:from:in-reply-to
         :content-transfer-encoding;
        bh=Mt2bcEVp4sfK+Jg7w+FLEK7GwsZVWDvVp2IA6kM7ZzA=;
        b=fSkHWFfKNna+g3yjjJQmSs9359O4XbVOP2CuxN9bU4Q94rt/0CzVbWdScCzBkfzNUQ
         v/rLk43Qucyg0vsrXZzWPddYYALLhv+u/BBhJjqhI4AmVxfF/whCdU942GRo+xiNygRE
         916O+MSoHg7mLoh3eIM4GAgOAJR4y6E54tzR6Psr8YWVRs34AOefbAume/LU22ie2U13
         mBODB3CqvLyygyMwjWlnlpnIMKAOjLNCXZcHnCmeug9Z6Xu4Twk/BA8u1dEj/AaSPsIa
         yN/jl5HzTmHUaAY6s+7FTkDWn1k3liLXwLK/aG1dmmiYlyF27ZDGwIZrCj3otP44Jmv8
         Hwbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:message-id:date:mime-version:user-agent
         :subject:content-language:to:references:from:in-reply-to
         :content-transfer-encoding;
        bh=Mt2bcEVp4sfK+Jg7w+FLEK7GwsZVWDvVp2IA6kM7ZzA=;
        b=bCxNdEB0l/rWGqsmZ2zFznYYPbd8Yg1T/bCBbp55D/TZTTuX4ysyoH+z5lF9ukjKYC
         ZVamAvIVW4Xdaz9Wdu9IxOMwTXnhkobUNGqHslJLyProCKXDSbGn1dsapCxOFcYlxQ2U
         RpZG+I0X3u4sPOzc1NQMt5jVYnOsUkwUHOBcPusD32F4I7hL3vmYo64TblCV+EpoxFOx
         9c095r6Y2jA+4Q20/DJmz6Q9aQronKdcJytuRoN6PaRKZh7mN88rO/dCMpCF+Mg1kQ+s
         b2lReIaDspy7BR6SPqMZEjnV7UktBq4AHLKnx1YaRjxlkQ4KdKhoOlLYr8QFgTg1zDrt
         3xUA==
X-Gm-Message-State: AOAM530imPsvsErPzCBsAd3WbMpeZo1dqtrH43IJ4AQaPzpEAkHS50W6
	3Kw6XcDpvuZB+tyhl76EcyRHP8EpHl8=
X-Google-Smtp-Source: ABdhPJwf3UXhFSTBHGxVcb+gDE+rEjAG/sI3LGOXQRr6hHJWHQSpMdtoOciYsxHFjzW+/o3z4Ms7WQ==
X-Received: by 2002:ac8:5d8d:0:b0:304:ea8b:1ca1 with SMTP id d13-20020ac85d8d000000b00304ea8b1ca1mr1907614qtx.529.1654436003299;
        Sun, 05 Jun 2022 06:33:23 -0700 (PDT)
Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234])
        by smtp.gmail.com with ESMTPSA id m15-20020a05620a13af00b006a603142d7fsm8682483qki.82.2022.06.05.06.33.22
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 05 Jun 2022 06:33:22 -0700 (PDT)
Message-ID: <94dcd569-94a8-58ae-f02e-a73a40505242@FreeBSD.org>
Date: Sun, 5 Jun 2022 09:33:21 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: Kernel crashed with "panic: VERIVY(e->lse-mscount != 0) failed"
Content-Language: en-US
To: Yasuhiro Kimura , freebsd-current@freebsd.org
References: <20220604.212512.1183180807227243032.yasu@FreeBSD.org>
From: Alexander Motin 
In-Reply-To: <20220604.212512.1183180807227243032.yasu@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LGHd71trPz3s2f
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=fSkHWFfK;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::82c as permitted sender) smtp.mailfrom=mavbsd@gmail.com
X-Spamd-Result: default: False [-2.43 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 SUBJECT_HAS_EXCLAIM(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_SHORT(-0.96)[-0.958];
	 FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.28)[-0.276];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[FreeBSD.org];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82c:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

Please update your system once more.  That wrong assertion was removed 
soon after your checkout at e3aa18ad717.

On 04.06.2022 08:25, Yasuhiro Kimura wrote:
> yasu@rolling-vm-freebsd1[1154]% uname -a
> FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n255944-645886d028c: Sat Jun  4 01:44:38 JST 2022     rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> 
> While building packages with poudriere kernel crashed with following
> message.
> 
> panic: VERIVY(e->lse-mscount != 0) failed
> 
> Snapshot of console:
> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220604.png

-- 
Alexander Motin

From nobody Sun Jun  5 15:18:51 2022
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 89A731BEEEB7
	for ; Sun,  5 Jun 2022 15:18:54 +0000 (UTC)
	(envelope-from imb@protected-networks.net)
Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.protected-networks.net", Issuer "R3" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LGKyj3dfBz4b9S;
	Sun,  5 Jun 2022 15:18:53 +0000 (UTC)
	(envelope-from imb@protected-networks.net)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=
	protected-networks.net; h=content-transfer-encoding:content-type
	:content-type:in-reply-to:from:from:references:content-language
	:subject:subject:user-agent:mime-version:date:date:message-id;
	 s=201508; t=1654442331; bh=cB2LjijFcpuFLVonBiBvvuwhVBp42x8FQcwf
	5buul8k=; b=X7AeR854mQvdkGFleqIm7iB0uPX33wtWJ6bLK80ABk61t2nPfdPa
	sc4eGG/FRoAbS4F8u7oRd9i/YIXmC83AuzPcl6ojUhlmm+ur/if/DxMGd1WHiSga
	gxfi7DyfLIk3e6xBNYv9bEdU7AeL2tdbMO7m7Kxlvx0kedMUQV966NA=
Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(Client did not present a certificate)
	(Authenticated sender: imb@mail.protected-networks.net)
	by mail.protected-networks.net (Postfix) with ESMTPSA id D61A8CD70;
	Sun,  5 Jun 2022 11:18:51 -0400 (EDT)
Message-ID: <98704176-952f-56ee-5d16-9a0ba75d58e3@protected-networks.net>
Date: Sun, 5 Jun 2022 11:18:51 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: commit 99902b1 causes kernel panics
Content-Language: en-NZ
To: Hans Petter Selasky ,
 freebsd-current 
Cc: manu@freebsd.org
References: <4cff718d-6f0f-bde8-2077-c83f4adc84df@protected-networks.net>
 <70f3adee-a0a4-3fca-8b12-3911782cf449@selasky.org>
From: Michael Butler 
In-Reply-To: <70f3adee-a0a4-3fca-8b12-3911782cf449@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LGKyj3dfBz4b9S
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protected-networks.net header.s=201508 header.b=X7AeR854;
	dmarc=pass (policy=reject) header.from=protected-networks.net;
	spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net
X-Spamd-Result: default: False [-4.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[protected-networks.net:+];
	 DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 6/5/22 02:09, Hans Petter Selasky wrote:
> On 6/4/22 23:21, Michael Butler wrote:
>> On a Dell E6430 laptop with an i5-3340M CPU on-board but no additional 
>> video adapter, this commit causes a panic when i915kms is loaded :-( 
>> This adapter does not use any additional firmware.
>>
> 
> Does the attached patch fix this problem?

It does - thanks!

	Michael


From nobody Mon Jun  6 09:46:21 2022
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 A2DF01BF2B8B
	for ; Mon,  6 Jun 2022 09:50:00 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic321-25.consmr.mail.ne1.yahoo.com (sonic321-25.consmr.mail.ne1.yahoo.com [66.163.185.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 4LGpcl2bfMz4g8Z
	for ; Mon,  6 Jun 2022 09:49:59 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654508992; bh=87n0Jn4UJ9XYtkQwafKHMV94bZ3m9K545Y/rrymhXfo=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=fvoFkibfbIFlQwv5CCCnYh7ZxUg3iH2hvdjOOtmf+KUYTyPU08bXy+P7x0TJzmNWr7EWfvSJMs0TjUvqLHwUoWT0aDN/gS8Ul1n3PN/RaqKPHF77Aa/SD6cToxLyQILkzVuCM5BTRQgFw5NLOvrHa4e8x3gWoFC63s0+GJFAIjPIR7q45N5eOg4aP77wK8wFNIiX8onyfXLT3FkgPPRPriSuX8KBjj4l0RfZbdUKqayULm774GeJAlvNxsiOs+lpL5BFjJZlOXb4+rYBHgluXCC6dlI6fjp3uqokBcHJdf9ICkluGoge00NpVyPPjKaRM9vDXCPxts1eVoZnpxEcTg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654508992; bh=ATIK4oLnISo6FcpeXONgHmrcHID6sbEpaMA9GdQwoMY=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=K0TQob/S/8NnKMQ27OmvOKaIKauQIkbQb4/QicQ2YmFjUYcSQ7odzxw9mgTc833E8IOkOBh7yp3ZpU4swxN1gCQOQmCCxBuah12SGW5q10A3+sE2AFLZ3xJMyrvUTwT0mL1hGhBJXbEx1fiMWs2Yn+wXFqlRNCMgoHG/I5abKiWxN4isWumPUdA34nZYH55IrrYa5L6Xh/18Xt+rCZ3FgRvjoTK9WTaBAoxLA6YRRg/f5Zzdyz2DfI7UtrAz9FKNkVONGSiq0lnwAnq2MXC1M0Fd71xYvgfLarPbASI0p+MFtpeCF3/8H96sZ+DTOyN3JXypd6hT8OYrv7GYL/Ls5g==
X-YMail-OSG: BjGFLNgVM1lvfIMgogeo4VexYqgrSkVCKt2NIPsA48LClvaafyvzIogNHop0eDF
 EGQMupxHv1q2EnMf4pZdPHjDCs3x_uhDSr2FICeid00wexDGTOXjoa3gVIIzTJFexQFM39ifxZui
 pCVj3.dRYWzgaDtMFYYRPz1jax2FRZeRH5IdbWLzs3hFfJK9_9rGs13.cEY2n4_4YQfKm9OfVxmh
 .qLCXlYfNQd80k8tTvCY11YcyifZvn9jIZNrqIHI7bYZNEg1ikjXLJPLMG3KW1Q8wMVLOLkV5rF9
 GvpKoKRejPTy1iLuGh7y2S1D0twdnjTtqq.2yXbI1JazXlvszSHOwAc7R4_H8elCihy3Iz5.W5sE
 VE8QC9GT4wX0M9tEfnAXoJie6_jFCLLIPDlYE5tB736kDzrV_RJTbDBTHL4DJNXXL39Eh8a84SYA
 5ntS413G_LHSy_ccLBWK8oKQCbacZ8RUsSo5YmkbYB4KGdiczCKo.iM7ZkfdtTcxmpD2SeQ9QRRR
 4Ia.wpXATiv9PZCgW.9ApcVS3cp2b9khL3ltzpo_8cKdoFw0m_RSVmSsdeP9H4SSFqRIyvvKT4xx
 M5.flKgKM2.dmcznZU4IVdp1t995leggGayf0lrttuXuy64PLpY5gZHcXmUbz9BOU3DLQQxBREh3
 S30cruscB1hz1MsEEQPEgT19akkpQBW875xYk6DocIbVlumYHYEU_RLuO9rknJYH98Xr.dNK4htN
 0iQfG_yn9vhp9F7gMp6UfM8ZQWENHGvdAFYm5LwN1n7oclqWmpdHSfg42UfklOffiYUcNVlRGZvJ
 DF7BKXUyGq6qSd1oNZkQJ4E.Jq9YF3eTxQ1IlN.ekQDICxoGSkYGyfe7RNkOLcObZWJXBh8X7wQ1
 dZivsfuaMRTYAz98Nr5XQMgJzH4404x.aigsYzMd7WMLoxmMoVCCLHoypU1_kQ.DlVp9plh9qHXx
 isH6ijz7yzoJzUo6zrj03MT75KuE91cO5Sq3d_lKbGJPoR_7K2FSdblsKSScMkkDZyLSku5nO1o1
 lAsPOKHH7wAQ3Kpz8E8g51tDqoHwt.Ua4EWW.X5kj4IXx2sgiJjfb34krWSj7say7.InO8PnuJvF
 5mKthZ2EoXyGIEsaVtwGKtbq.ANlPLlXA9HhXdbDeiPEj.4e_f9hxWYBKvXoF7.jgNyfmmPWX2iZ
 9Yb8m3cGmABXSbKVPXYrR0iEmCcLLD7jUhocOX9wX3hUer5RcFZSjRQeM41YCCUMBY.ZvTOllOS7
 JgGY0ZOxSCMSkliBjqdw7auQHh2dQxY9K1sq8.vN8o4PE2FNrZqeHS_5DOTL4cxWX3.9cV.7QhzU
 P9KD_.oCe.j2Zor9YWCtwMRsypI86guHXZE_Fq.fb_YalocO8c8o2xM1.fEU3zfNy2L9d.I8tRqN
 ecLXxuQpkBF0XtYp12O0QbXQeOAQNc7MCoiohOzoiTi24u_p69zz7.hwyoneiFdoWXr_xFQK2VL9
 MCWY1eCyffzi3wDodg82hItMbyzcCdq5igJ6K0H8brUnhjQluVrymdtZ4VCcImiB_d0R_SaOyy_G
 vFnxVsyvu4Ur4sQl3ER591YAS.SZmDZNwymVl0jE1Yauqg4Q.DBDbq8BrfgZeWSWKC494VCWpQ9K
 1njpwQdWHeBeEq3ecAE2bhTqbfe0khZI02DSqheVQcG5tvkRra.fTIu_z7vmmsWUo_Sf.EEYVGEl
 mNet_d4xcytJCO4eoONh1gYZQ8w378i8ojou4BfhZqVD.EaTSCdReE.Z102Jt98RpdkesXvu6kyv
 wEdpe2PQZ6U16Z4dXhgVRG6AYi79mB712NKDGbrGO8jWR.614.epLbp33P9_l__i39CxbxscOdMA
 NWAu7q0Zz_QOjKxe6s2gQuUvZcYnuACWhBdY_nf35NOlCtROcv8YuxQawV6ZifvPmqbqnxZ0Nd_Q
 crCruOF.266EkcgypbY0aJqpk81F3lHALXbIAqsJhcbROJw4TbWI7ZC_yLQNQfjbD6BzuSj5jTWL
 EIAo4Y3i_OHB6iWPyKnUXhDu6QJzRRh0GxQxjiz9.6U84Z5RDKqfUTCFYVhVrU7K4_yLYJh1ERro
 Y3f4MDHKIjTFck4qDBLaj9mKc47PQlmSPcS5Rot5YZzjd6mIS9utOBErrwQVMdVtH0ClpWkLqNRs
 V0rfc.BWJVgb7pF.XAzJrJW7RfemT9zwPGZvYoPZbpzJdfGhJBCF8PxgVtTgh634w
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic321.consmr.mail.ne1.yahoo.com with HTTP; Mon, 6 Jun 2022 09:49:52 +0000
Date: Mon, 6 Jun 2022 09:46:21 +0000 (UTC)
From: Filippo Moretti 
To: FreeBSD Current 
Message-ID: <842021085.7679468.1654508781175@mail.yahoo.com>
In-Reply-To: 
References:     <7BEE44CC-4D31-4CBC-BC12-9A327424299C@me.com>  <20220530223432.D91C518F@slippy.cwsent.com>  
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
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_7679467_261928603.1654508781173"
X-Mailer: WebService/1.1.20225 YMailNorrin
X-Rspamd-Queue-Id: 4LGpcl2bfMz4g8Z
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=fvoFkibf;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.185.206 as permitted sender) smtp.mailfrom=filippomore@yahoo.com
X-Spamd-Result: default: False [-2.38 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-0.90)[-0.901];
	 NEURAL_SPAM_MEDIUM(0.32)[0.316];
	 RCPT_COUNT_ONE(0.00)[1];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[66.163.185.206:from];
	 NEURAL_HAM_SHORT(-0.80)[-0.797];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_7679467_261928603.1654508781173
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=20
Is it now safe to attempt updating current with UFS?SincerelyFilippo
    On Wednesday, June 1, 2022 at 01:07:20 AM GMT+2, Warner Losh  wrote: =20
=20
=20

On Tue, May 31, 2022 at 3:55 PM Olivier Cochard-Labb=C3=A9  wrote:

Same problem here:- I'm building FreeBSD head on a builder machine, and NFS=
 mounting its /usr/src and /usr/obj to 4 others
Results:- 2 of them, UEFI+ZFS machines works great ((Thinkpad T420 and AMD =
Epyc with Tyan motherboard)- 2 of them, BIOS+UFS machines meet this "can't =
find /boot/ua/loader.lua" (HP microserver and PC Engines APU2)
I had to boot from an USB stick, mounting the system partition and "cp boot=
/loader_4th.old boot/loader".

Kirk found that the boot loader defines MAXPHYS to be 128k, which only is f=
or the BIOS loader since it's 32-bit. UEFIis 64-bits and just works because=
 it's define to 1MB. So the UEFI machines with ZFS are doubly safe. Kirk ha=
s a changethat relaxes the check and I think we should do this
diff --git a/sys/sys/param.h b/sys/sys/param.h
index 1f720ed31142..8cd9616e872e 100644
--- a/sys/sys/param.h
+++ b/sys/sys/param.h
@@ -176,7 +176,7 @@
=C2=A0#define DFLTPHYS =C2=A0 =C2=A0 =C2=A0 (64 * 1024) =C2=A0 =C2=A0 /* de=
fault max raw I/O transfer size */
=C2=A0#endif
=C2=A0#ifndef MAXPHYS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* max raw I/O t=
ransfer size */
-#ifdef __ILP32__
+#if defined(__ILP32__) && !defined(_STANDALONE) /* Always 1M for loader */
=C2=A0#define MAXPHYS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0(128 * 1024)
=C2=A0#else
=C2=A0#define MAXPHYS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0(1024 * 1024)

as well to ensure that the loader always assumes a larger MAXPHYS (though I=
'd kinda like the loader to notdefine it at all, but that is a longer conve=
rsation after reflection not a quick fix to get people back up andrunning).
Warner =20
------=_Part_7679467_261928603.1654508781173
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



        

Is it now saf=
e to attempt updating current with UFS?
Sincerely
Filippo

       =20
        

            

               =20
                

                    On Wednesday, June 1, 2022 at 01:07:20 AM GMT+2, Warner=
 Losh <imp@bsdimp.com> wrote:
                

                


                


                









            

        

------=_Part_7679467_261928603.1654508781173--

From nobody Mon Jun  6 09:59:36 2022
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 AC06D1BF429E
	for ; Mon,  6 Jun 2022 09:59:45 +0000 (UTC)
	(envelope-from SRS0=jgwc=WN=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 4LGpr05km9z4hc3
	for ; Mon,  6 Jun 2022 09:59:44 +0000 (UTC)
	(envelope-from SRS0=jgwc=WN=klop.ws=ronald-lists@realworks.nl)
Date: Mon, 6 Jun 2022 11:59:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1654509577;
	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=y6KSi6W/zX+xlw8jIJlBMCJKTZQ/yUH+1eQttnda2Mc=;
	b=aVofjmuB8zFn3mWhzrU0fiKZ16IQsjBXdrcAnCweUfkyvzkte3gs4XS5NqvMuUL/16Ha8s
	3KMsoZ5naeWdXs4J2XKDblcjtBaZ/JVXmDGBwHLEhrecLSKD9HkpMsIwKynCgdA62+o7ZC
	oZcc7sFmSu1Dj1LjvWPjyVB5Q2cVeHE6vSD/aXkdM31LVavMpL5z8pxAobY5gW784YxwFL
	w7zl2U6PpS28RS1P1qFNaxunGGw1G9MFzZWGN+xoNBc8m4CC299LzxrUYfndKjJQ2a1dF2
	jkWUzz8ON+fknJb8wg4XW010ubbKPJQstKdbIUdT3AojGezYTnkgYa3nWnWTsQ==
From: Ronald Klop 
To: freebsd-current@freebsd.org
Message-ID: <172777947.19.1654509576898@localhost>
Subject: buildworld fail: ld: error: undefined symbol: test_no_kevents
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_18_269112813.1654509576829"
X-Mailer: Realworks (609.137.522ccc0)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4LGpr05km9z4hc3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=aVofjmuB;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=jgwc=WN=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=jgwc=WN=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.19 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.990];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=jgwc=WN=klop.ws=ronald-lists@realworks.nl];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=jgwc=WN=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_18_269112813.1654509576829
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Building on aarch64/14-CURRENT fails with this error on my rpi4.
It failed on incremental build and tried a clean build today.

First failure was on "World build started on Sun May 29 00:25:17 UTC 2022".

This weekend it still fails (I'm building weekly in Jenkins).
10:04:44 ===> tests/sys/kqueue/libkqueue (all)
10:04:44 --- kqueue_test ---
10:04:44 (cd /usr/src/tests/sys/kqueue/libkqueue &&  DEPENDFILE=.depend.kqueue_test  NO_SUBDIR=1 /usr/bin/make -f /usr/src/tests/sys/kqueue/libkqueue/Makefile _RECURSING_PROGS=t  PROG=kqueue_test )
10:04:44 --- kqueue_test.full ---
10:04:44 cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -fPIE -g -gz=zlib -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments  -pie  -o kqueue_test.full main.o read.o timer.o vnode.o proc.o signal.o user.o  
10:04:44 ld: error: undefined symbol: test_no_kevents
10:04:45 >>> referenced by read.c:169 (/usr/src/tests/sys/kqueue/libkqueue/read.c:169)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:75 (/usr/src/tests/sys/kqueue/libkqueue/read.c:75)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:137 (/usr/src/tests/sys/kqueue/libkqueue/read.c:137)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced 31 more times
10:04:45 >>> did you mean: _test_no_kevents
10:04:45 >>> defined in: main.o
10:04:45 
10:04:45 ld: error: undefined symbol: kevent_cmp
10:04:45 >>> referenced by read.c:72 (/usr/src/tests/sys/kqueue/libkqueue/read.c:72)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:145 (/usr/src/tests/sys/kqueue/libkqueue/read.c:145)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:193 (/usr/src/tests/sys/kqueue/libkqueue/read.c:193)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced 14 more times
10:04:45 >>> did you mean: _kevent_cmp
10:04:45 >>> defined in: main.o
10:04:45 cc: error: linker command failed with exit code 1 (use -v to see invocation)
10:04:45       668.58 real       125.97 user        62.12 sys
10:04:45 
10:04:45 make[1]: stopped in /usr/src
10:04:45 
10:04:45 make: stopped in /usr/src
10:04:45 Build step 'Execute shell' marked build as failure
10:04:46 Skipped archiving because build is not successful
10:04:46 Sending e-mails to: xxxx@yyyy.zzz
10:04:47 Finished: FAILURE

Any thoughts? Similar experience?

Regards,
Ronald.

 
------=_Part_18_269112813.1654509576829
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,



Building on aarch64/14-CURRENT fails with this error on my rpi4.

It failed on incremental build and tried a clean build today.



First failure was on "World build started on Sun May 29 00:25:17 UTC 2022".



This weekend it still fails (I'm building weekly in Jenkins).





10:04:44 ===> tests/sys/kqueue/libkqueue (all)
10:04:44 --- kqueue_test ---
10:04:44 (cd /usr/src/tests/sys/kqueue/libkqueue &&  DEPENDFILE=.depend.kqueue_test  NO_SUBDIR=1 /usr/bin/make -f /usr/src/tests/sys/kqueue/libkqueue/Makefile _RECURSING_PROGS=t  PROG=kqueue_test )
10:04:44 --- kqueue_test.full ---
10:04:44 cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -fPIE -g -gz=zlib -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments  -pie  -o kqueue_test.full main.o read.o timer.o vnode.o proc.o signal.o user.o  
10:04:44 ld: error: undefined symbol: test_no_kevents
10:04:45 >>> referenced by read.c:169 (/usr/src/tests/sys/kqueue/libkqueue/read.c:169)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:75 (/usr/src/tests/sys/kqueue/libkqueue/read.c:75)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:137 (/usr/src/tests/sys/kqueue/libkqueue/read.c:137)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced 31 more times
10:04:45 >>> did you mean: _test_no_kevents
10:04:45 >>> defined in: main.o
10:04:45 
10:04:45 ld: error: undefined symbol: kevent_cmp
10:04:45 >>> referenced by read.c:72 (/usr/src/tests/sys/kqueue/libkqueue/read.c:72)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:145 (/usr/src/tests/sys/kqueue/libkqueue/read.c:145)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:193 (/usr/src/tests/sys/kqueue/libkqueue/read.c:193)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced 14 more times
10:04:45 >>> did you mean: _kevent_cmp
10:04:45 >>> defined in: main.o
10:04:45 cc: error: linker command failed with exit code 1 (use -v to see invocation)
10:04:45       668.58 real       125.97 user        62.12 sys
10:04:45 
10:04:45 make[1]: stopped in /usr/src
10:04:45 
10:04:45 make: stopped in /usr/src
10:04:45 Build step 'Execute shell' marked build as failure
10:04:46 Skipped archiving because build is not successful
10:04:46 Sending e-mails to: xxxx@yyyy.zzz
10:04:47 Finished: FAILURE








Any thoughts? Similar experience?



Regards,

Ronald.



 
------=_Part_18_269112813.1654509576829--

From nobody Mon Jun  6 10:16:44 2022
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 988971BF6977
	for ; Mon,  6 Jun 2022 10:16:52 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LGqCm0b4Xz4klJ;
	Mon,  6 Jun 2022 10:16:52 +0000 (UTC)
	(envelope-from dim@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1654510612;
	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=X3+UAPex0bxBMkbOgQER7n7KrL7e1SsEgDHJpriZhYg=;
	b=kvZUsllKOXc9wu6kwoi48A3MxblD9hbZjUxoxKfz6pZ++/LC+DMpth1g7O1EVEedhUPEsX
	VeOHFcRRpbSkKyTgZag7Fv1pQxPRZ5QA2XsQGUA0F1bQGJ2YNeSNSw/vBK4pcqDm0LMnkJ
	wfx6sltpL37mEgd/EkEsz2nGKdR0XUpTpBIwTKWAlJUP76s1Wsn0CC8Cjmk5QcKsxGaFC9
	0o1qxa4BgPj/QT9XbtCnfkkylptTiz90Y4x6QdumX5MJekhfvwncGHNIPuH43BOJymhSip
	OH2pTA6erhhuf5CUAG6PGnaIvvRcxxxcsVfWnJ8P6/aw976zsE6ds45cvvVcqg==
Received: from tensor.andric.com (tensor.andric.com [87.251.56.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "tensor.andric.com", Issuer "R3" (verified OK))
	(Authenticated sender: dim)
	by smtp.freebsd.org (Postfix) with ESMTPSA id A8E0775F9;
	Mon,  6 Jun 2022 10:16:51 +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 13B3842E9E;
	Mon,  6 Jun 2022 12:16:49 +0200 (CEST)
Content-Type: multipart/signed;
	boundary="Apple-Mail=_FC031E41-3ECE-4BFA-9A79-2135E56E7574";
	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 \(3696.100.31\))
Subject: Re: buildworld fail: ld: error: undefined symbol: test_no_kevents
From: Dimitry Andric 
X-Priority: 3 (Normal)
In-Reply-To: <172777947.19.1654509576898@localhost>
Date: Mon, 6 Jun 2022 12:16:44 +0200
Cc: freebsd-current ,
 Mark Johnston 
Message-Id: <15688335-6503-4120-985A-34A7BF3FBEA7@FreeBSD.org>
References: <172777947.19.1654509576898@localhost>
To: Ronald Klop 
X-Mailer: Apple Mail (2.3696.100.31)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654510612;
	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=X3+UAPex0bxBMkbOgQER7n7KrL7e1SsEgDHJpriZhYg=;
	b=aNHPsJVx+QOp04cAnj8gIm/Twm9NdM4k0UppIhnRWF9gVLHwBdhqeEjFuUX2/bZ9/DCteT
	VaZ+hDoaEEwEaBEO77CEVekr7aSudjNcVBXZcd1zibTxh+ShOOnFTLF7Sumo88zTowd+ji
	RTf7pUc8RR612JV8a9W+Uv0MFlK/8at+hq08h/7v2tjGC5++7iW4b0SQhuHw5Vej6DjZTx
	xwaRKLlK2shh7DHlxS5mk+2QD5uMESheRkMg74o/FnGIrCovkQkGxE/OBptH8NOlqeiaPL
	SZluZ4VHWBR9txcWkZuCBaX54mOs/XzfpmO03BlucgOSBPrvJt9BgcUXYY5SbQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654510612; a=rsa-sha256; cv=none;
	b=tkvbAHothRh28DO0zFbhAMZ96pSOfQePMIPBGZ1pTpjP8m/GTbUdRSMRvizvoM1YQGfXJR
	fIPY9BnH/PZS+78giYujMmAyThonI6EQztCJxHF179QfCg7YNolPOMEkomdBuKNTemMAhK
	g2sY5q8yfXhwBZgTrAX7maJgWmZkY5iW1jaL74aidZQvGE/qfiH1M4W9bitNgfu476orLE
	2zYfs+clLddbwLLpTA5wK/8J8EiEewYs8v+5EiXpXVC9Lh1XowCYOXo9OGUkCpHUsyweC4
	6pRNnEekSgfDh9L7CMLwwmkDgRXnhK/nP7j//J2LyIyf6+UX7Ant6/odlYUQDA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_FC031E41-3ECE-4BFA-9A79-2135E56E7574
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0C76B5A0-363E-4083-BBA8-EF5CDCA8C939"


--Apple-Mail=_0C76B5A0-363E-4083-BBA8-EF5CDCA8C939
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Looks like it might be using an old version of =
tests/sys/kqueue/libkqueue/common.h, after =
https://cgit.freebsd.org/src/commit/?id=3Dc728c56c870abe230e45cee5c477f0d8=
90ebacef ?

Without seeing how the .o files have been compiled, specifically with =
which -I flags, it is impossible to see what is going wrong, though.

-Dimitry

> On 6 Jun 2022, at 11:59, Ronald Klop  wrote:
>=20
> Hi,
>=20
> Building on aarch64/14-CURRENT fails with this error on my rpi4.
> It failed on incremental build and tried a clean build today.
>=20
> First failure was on "World build started on Sun May 29 00:25:17 UTC =
2022".
>=20
> This weekend it still fails (I'm building weekly in Jenkins).
> 10:04:44 =3D=3D=3D> tests/sys/kqueue/libkqueue (all)
> 10:04:44 --- kqueue_test ---
> 10:04:44 (cd /usr/src/tests/sys/kqueue/libkqueue &&  =
DEPENDFILE=3D.depend.kqueue_test  NO_SUBDIR=3D1 /usr/bin/make -f =
/usr/src/tests/sys/kqueue/libkqueue/Makefile _RECURSING_PROGS=3Dt  =
PROG=3Dkqueue_test )
> 10:04:44 --- kqueue_test.full ---
> 10:04:44 cc -target aarch64-unknown-freebsd14.0 =
--sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp =
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -fPIE =
-g -gz=3Dzlib -std=3Dgnu99 -Wno-format-zero-length =
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k =
-W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes =
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch =
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts =
-Wnested-externs -Wold-style-definition -Wno-pointer-sign =
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body =
-Wno-string-plus-int -Wno-unused-const-variable =
-Wno-error=3Dunused-but-set-variable -Qunused-arguments  -pie  -o =
kqueue_test.full main.o read.o timer.o vnode.o proc.o signal.o user.o
> 10:04:44 ld: error: undefined symbol: test_no_kevents
> 10:04:45 >>> referenced by read.c:169 =
(/usr/src/tests/sys/kqueue/libkqueue/read.c:169)
> 10:04:45 >>>               read.o:(test_evfilt_read)
> 10:04:45 >>> referenced by read.c:75 =
(/usr/src/tests/sys/kqueue/libkqueue/read.c:75)
> 10:04:45 >>>               read.o:(test_evfilt_read)
> 10:04:45 >>> referenced by read.c:137 =
(/usr/src/tests/sys/kqueue/libkqueue/read.c:137)
> 10:04:45 >>>               read.o:(test_evfilt_read)
> 10:04:45 >>> referenced 31 more times
> 10:04:45 >>> did you mean: _test_no_kevents
> 10:04:45 >>> defined in: main.o
> 10:04:45
> 10:04:45 ld: error: undefined symbol: kevent_cmp
> 10:04:45 >>> referenced by read.c:72 =
(/usr/src/tests/sys/kqueue/libkqueue/read.c:72)
> 10:04:45 >>>               read.o:(test_evfilt_read)
> 10:04:45 >>> referenced by read.c:145 =
(/usr/src/tests/sys/kqueue/libkqueue/read.c:145)
> 10:04:45 >>>               read.o:(test_evfilt_read)
> 10:04:45 >>> referenced by read.c:193 =
(/usr/src/tests/sys/kqueue/libkqueue/read.c:193)
> 10:04:45 >>>               read.o:(test_evfilt_read)
> 10:04:45 >>> referenced 14 more times
> 10:04:45 >>> did you mean: _kevent_cmp
> 10:04:45 >>> defined in: main.o
> 10:04:45 cc: error: linker command failed with exit code 1 (use -v to =
see invocation)
> 10:04:45       668.58 real       125.97 user        62.12 sys
> 10:04:45
> 10:04:45 make[1]: stopped in /usr/src
> 10:04:45
> 10:04:45 make: stopped in /usr/src
> 10:04:45 Build step 'Execute shell' marked build as failure
> 10:04:46 Skipped archiving because build is not successful
> 10:04:46 Sending e-mails to: xxxx@yyyy.zzz
> 10:04:47 Finished: FAILURE
>=20
> Any thoughts? Similar experience?
>=20
> Regards,
> Ronald.
>=20
>=20


--Apple-Mail=_0C76B5A0-363E-4083-BBA8-EF5CDCA8C939
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Looks like it might be using an old version of =
tests/sys/kqueue/libkqueue/common.h, after https://cgit.freebsd.org/src/commit/?id=3Dc728c56c870abe230e45c=
ee5c477f0d890ebacef ?

Without seeing how the .o files have been compiled, =
specifically with which -I flags, it is impossible to see what is going =
wrong, though.

-Dimitry

On 6 Jun 2022, at 11:59, Ronald Klop <ronald-lists@klop.ws> wrote:

Hi,


Building on aarch64/14-CURRENT fails with this error on my rpi4.

It failed on incremental build and tried a clean build today.



First failure was on "World build started on Sun May 29 00:25:17 UTC =
2022".



This weekend it still fails (I'm building weekly in Jenkins).





10:04:44 =3D=3D=3D> tests/sys/kqueue/libkqueue =
(all)
10:04:44 --- =
kqueue_test ---
10:04:44 (cd =
/usr/src/tests/sys/kqueue/libkqueue &&  =
DEPENDFILE=3D.depend.kqueue_test  NO_SUBDIR=3D1 /usr/bin/make -f =
/usr/src/tests/sys/kqueue/libkqueue/Makefile _RECURSING_PROGS=3Dt  =
PROG=3Dkqueue_test )
10:04:44 --- =
kqueue_test.full ---
10:04:44 cc -target =
aarch64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp=
 -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common =
-fPIE -g -gz=3Dzlib -std=3Dgnu99 -Wno-format-zero-length =
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k =
-W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes =
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch =
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts =
-Wnested-externs -Wold-style-definition -Wno-pointer-sign =
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body =
-Wno-string-plus-int -Wno-unused-const-variable =
-Wno-error=3Dunused-but-set-variable -Qunused-arguments  -pie  -o =
kqueue_test.full main.o read.o timer.o vnode.o proc.o signal.o user.o =20=

10:04:44 ld: error: =
undefined symbol: test_no_kevents
10:04:45 >>> =
referenced by read.c:169 =
(/usr/src/tests/sys/kqueue/libkqueue/read.c:169)
10:04:45 >>> =
              read.o:(test_evfilt_read)
10:04:45 >>> =
referenced by read.c:75 (/usr/src/tests/sys/kqueue/libkqueue/read.c:75)
10:04:45 >>> =
              read.o:(test_evfilt_read)
10:04:45 >>> =
referenced by read.c:137 =
(/usr/src/tests/sys/kqueue/libkqueue/read.c:137)
10:04:45 >>> =
              read.o:(test_evfilt_read)
10:04:45 >>> =
referenced 31 more times
10:04:45 >>> =
did you mean: _test_no_kevents
10:04:45 >>> =
defined in: main.o
10:04:45 
10:04:45 ld: error: =
undefined symbol: kevent_cmp
10:04:45 >>> =
referenced by read.c:72 (/usr/src/tests/sys/kqueue/libkqueue/read.c:72)
10:04:45 >>> =
              read.o:(test_evfilt_read)
10:04:45 >>> =
referenced by read.c:145 =
(/usr/src/tests/sys/kqueue/libkqueue/read.c:145)
10:04:45 >>> =
              read.o:(test_evfilt_read)
10:04:45 >>> =
referenced by read.c:193 =
(/usr/src/tests/sys/kqueue/libkqueue/read.c:193)
10:04:45 >>> =
              read.o:(test_evfilt_read)
10:04:45 >>> =
referenced 14 more times
10:04:45 >>> =
did you mean: _kevent_cmp
10:04:45 >>> =
defined in: main.o
10:04:45 cc: error: =
linker command failed with exit code 1 (use -v to see invocation)
10:04:45       668.58 =
real       125.97 user        62.12 sys
10:04:45 
10:04:45 make[1]: =
stopped in /usr/src
10:04:45 
10:04:45 make: =
stopped in /usr/src
10:04:45 Build step =
'Execute shell' marked build as failure
10:04:46 Skipped =
archiving because build is not successful
10:04:46 Sending =
e-mails to: xxxx@yyyy.zzz
10:04:47 Finished: =
FAILURE








Any thoughts? Similar experience?



Regards,

Ronald.



 

=

--Apple-Mail=_0C76B5A0-363E-4083-BBA8-EF5CDCA8C939--

--Apple-Mail=_FC031E41-3ECE-4BFA-9A79-2135E56E7574
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

iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYp3UDAAKCRCwXqMKLiCW
o1I2AJwJMW3SfAwL4GUN7oQO8/XNLyBf+QCfQwoMeDLapJBvjIkv1+BC+2NUseQ=
=U2JT
-----END PGP SIGNATURE-----

--Apple-Mail=_FC031E41-3ECE-4BFA-9A79-2135E56E7574--

From nobody Mon Jun  6 10:29:07 2022
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 84C571BD126F
	for ; Mon,  6 Jun 2022 10:29:15 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LGqV21xW6z4mRk
	for ; Mon,  6 Jun 2022 10:29:14 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 256AT7CK014186;
	Mon, 6 Jun 2022 10:29:07 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 256AT7G8014185;
	Mon, 6 Jun 2022 03:29:07 -0700 (PDT)
	(envelope-from david)
Date: Mon, 6 Jun 2022 03:29:07 -0700
From: David Wolfskill 
To: Filippo Moretti 
Cc: FreeBSD Current 
Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after
 main-n255828-18054d0220c
Message-ID: 
Mail-Followup-To: David Wolfskill ,
	Filippo Moretti ,
	FreeBSD Current 
References: 
 
 
 
 <7BEE44CC-4D31-4CBC-BC12-9A327424299C@me.com>
 
 <20220530223432.D91C518F@slippy.cwsent.com>
 
 
 <842021085.7679468.1654508781175@mail.yahoo.com>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="BEysWuJaLU817Uva"
Content-Disposition: inline
In-Reply-To: <842021085.7679468.1654508781175@mail.yahoo.com>
X-Rspamd-Queue-Id: 4LGqV21xW6z4mRk
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-5.33 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[david];
	 FROM_HAS_DN(0.00)[];
	 SIGNED_PGP(-2.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 DMARC_NA(0.00)[catwhisker.org];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-0.93)[-0.928];
	 RCPT_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


--BEysWuJaLU817Uva
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 06, 2022 at 09:46:21AM +0000, Filippo Moretti wrote:
> =20
> Is it now safe to attempt updating current with UFS?SincerelyFilippo
> ....

Yes.

Kirk committed a fix:

commit bc218d89200faa021def77732f3d9fde4f4dee13
Author: Kirk McKusick 
Date:   Tue May 31 19:55:54 2022 -0700

    Two bug fixes to UFS/FFS superblock integrity checks when reading a sup=
erblock.
   =20
    Two bugs have been reported with the UFS/FFS superblock integrity
    checks that were added in commit 076002f24d35.
=2E...

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshniko=
va

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--BEysWuJaLU817Uva
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYp3W8l8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1FohAQDgdMiWd9pYF/AU7OwdDA51NaHz5mZMYWmu4QYR0hQOUQEAmYnxkXd0Uqj1
WQNg6bNVsyEMcAbz7j7uLCKP1/cHMgo=
=8d0U
-----END PGP SIGNATURE-----

--BEysWuJaLU817Uva--

From nobody Mon Jun  6 11:37:39 2022
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 865851BDB15B
	for ; Mon,  6 Jun 2022 11:37:44 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LGs132nnXz4slv
	for ; Mon,  6 Jun 2022 11:37:43 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x529.google.com with SMTP id v25so18419392eda.6
        for ; Mon, 06 Jun 2022 04:37:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to;
        bh=8CDVfJmLZwMc+8NTljVETHQAWmRrA+15IAdGVIOjcYA=;
        b=mTOhNphARbq8iVEFdPVz6BBDNqlpybIxdaCbWXQTgAT27xRFMk7+RKaJDRp/MrovQ2
         /jvztUr7iMehtXWQHN9PW90KhqNgSlQ6ZxwXE96ElxxZUT82Vm5MDm8hvtryVYePqjYW
         a5rYnMgUBlzVMkOy/H8kXgfra1t6Dx6Nm8EfX5tb7aD/tOgw0PWRgoi6XXnKaZO5mEXA
         kdhSDzC/i8KwvfBFEvvhaulF7voBaA5+zN2cZog6/nBoWFcn2izFpuAE7GVpQrw7KLS+
         ljNRWAAoM84kdSfydfFbFpZfOZl4d5uJ94eMRHxYizbbBSnHlzXOSQxwfUNI2jgA1XSj
         Fzxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to;
        bh=8CDVfJmLZwMc+8NTljVETHQAWmRrA+15IAdGVIOjcYA=;
        b=boWXKEbVJ8tELl0mhVAYlVDhaTKPD9WeHRMxbcofltZK75CZckLMWKdE8hasnMel7t
         aPBJ+L0SQmarE8EcIkcZhjh7OJMjCqhTewz7THp76nxoTyP/05wkwhvZCQsGA7o+HppI
         iIr5CYhcUVAOn9JNFLxPCxnB4AX4uILHPTIRoLvBPThhOUKilr4A3CAS6711tIOD8yHG
         eWPpXMXw5Kv/y/NfGoJxe8C//Wx/RLU1uRMMF5OX3/rBG0VSH7u7xcMlOAD4zpX7CLgQ
         TGl2+9wKM53cHREJJX9pSJg88RglTNTYEI5pveB9td0eX94hmEBgPwrE13Co+LIh23Qn
         o7BQ==
X-Gm-Message-State: AOAM531dh7ipUI9KixklgQhM8WpPNAaGAkjYQkNvzU7f1EVOaC/tSWPk
	ceMp+n+F5mGsiw6XuO/hr7o=
X-Google-Smtp-Source: ABdhPJxwaW8sAC1w0q/MYylRUW9+Jplgk2dahhlzYVh0Unr0Na64XeF/+ovXShlcImG1ZXPF+AV+wg==
X-Received: by 2002:a05:6402:31fa:b0:42d:cd6d:c8fd with SMTP id dy26-20020a05640231fa00b0042dcd6dc8fdmr25876043edb.347.1654515462319;
        Mon, 06 Jun 2022 04:37:42 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-027-054.46.114.pool.telefonica.de. [46.114.27.54])
        by smtp.googlemail.com with ESMTPSA id lk24-20020a170906cb1800b006fa84a0af2asm6327943ejb.16.2022.06.06.04.37.41
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 06 Jun 2022 04:37:41 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: buildworld fail: ld: error: undefined symbol: test_no_kevents
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Priority: 3 (Normal)
In-Reply-To: <172777947.19.1654509576898@localhost>
Date: Mon, 6 Jun 2022 13:37:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <195E9EDB-61E1-4A84-ABA4-8667CA913DD8@googlemail.com>
References: <172777947.19.1654509576898@localhost>
To: Ronald Klop ,
 freebsd-current@freebsd.org
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4LGs132nnXz4slv
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=mTOhNphA;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.12 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[googlemail.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[googlemail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-1.00)[-0.998];
	 DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[googlemail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.67)[-0.673];
	 R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	 RECEIVED_SPAMHAUS_PBL(0.00)[46.114.27.54:received];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-0.95)[-0.951];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> Am 06.06.2022 um 11:59 schrieb Ronald Klop :
>=20
> on my rpi4=E2=80=A6..
> 10:04:45=20
> 10:04:45=20
> ld: error: undefined symbol: kevent_cmp
>=20
> Any thoughts? Similar experience?
>=20
> =20

Yes, similar experience(~1 week ago) , specially when using NO_CLEAN =
flag , as far as I remember..
`got around this issue by using the WITHOUT_TESTS flag .




From nobody Mon Jun  6 11:42:40 2022
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 ACA811BDC638
	for ; Mon,  6 Jun 2022 11:42:44 +0000 (UTC)
	(envelope-from SRS0=jgwc=WN=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 4LGs6q4hHLz4vW7;
	Mon,  6 Jun 2022 11:42:42 +0000 (UTC)
	(envelope-from SRS0=jgwc=WN=klop.ws=ronald-lists@realworks.nl)
Date: Mon, 6 Jun 2022 13:42:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1654515760;
	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=TCkKrAj0dldnduA74cM4jb/hApY/ptaN3gNq+YIzYrQ=;
	b=lt8/3K5LuNLCslxP2qEwHZLMgmZCbYPRBtD7Ij9Dt5d9rJ1dOzYos4h7YNpbyeeM+xOJqs
	SqFkFGAD7sqPsWqxvLos4TWgHYU+KeCxbKT9fz8EiWp49LzL10YHuLsD/f8eI1s0PuBk9H
	AkAtbKpLMesSzGpdn3QRIlJDYFwlM8tNhCoPssxKywZf4Gzxn7X+oD5owY4ns5pRHao4+w
	Dd+NsiPomfJWlUzgSFOSPICdJEzauCLpaC5XsWMrFeXyUcFHrg2mb8C+6TYNh8SXTYPvu/
	zw1dWF3QPj6osEvBBeGeQMt0aE56bhOMlYdYxfJCmDFhtYcQBrI1wN9ckdH4wA==
From: Ronald Klop 
To: Dimitry Andric 
Cc: Mark Johnston ,
	freebsd-current 
Message-ID: <1606971861.46.1654515760545@localhost>
In-Reply-To: <15688335-6503-4120-985A-34A7BF3FBEA7@FreeBSD.org>
References: <172777947.19.1654509576898@localhost>
 <15688335-6503-4120-985A-34A7BF3FBEA7@FreeBSD.org>
Subject: Re: buildworld fail: ld: error: undefined symbol: test_no_kevents
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_45_1775458143.1654515760488"
X-Mailer: Realworks (609.137.522ccc0)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4LGs6q4hHLz4vW7
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b="lt8/3K5L";
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=jgwc=WN=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=jgwc=WN=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-2.96 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.79)[-0.791];
	 R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-0.98)[-0.976];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[klop.ws:+];
	 DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-0.99)[-0.994];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=jgwc=WN=klop.ws=ronald-lists@realworks.nl];
	 RCVD_COUNT_ZERO(0.00)[0];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 MID_RHS_NOT_FQDN(0.50)[];
	 ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	 FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=jgwc=WN=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_45_1775458143.1654515760488
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Mmm, took another look. I doubt my clean build was clean as "wipe out workspace" did not work because the Jenkins agent was offline.

The problem might be PEBCAK[1]. :-)

Doing another build with a fresh Jenkins workspace now. Will take 10+ hours to compile clang for the millionth time.

Ronald.
[1] https://en.wiktionary.org/wiki/PEBCAK
 
Van: Dimitry Andric 
Datum: maandag, 6 juni 2022 12:16
Aan: Ronald Klop 
CC: freebsd-current , Mark Johnston 
Onderwerp: Re: buildworld fail: ld: error: undefined symbol: test_no_kevents
> 
> Looks like it might be using an old version of tests/sys/kqueue/libkqueue/common.h, after https://cgit.freebsd.org/src/commit/?id=c728c56c870abe230e45cee5c477f0d890ebacef ?
>  
> Without seeing how the .o files have been compiled, specifically with which -I flags, it is impossible to see what is going wrong, though.
>  
> -Dimitry
>  
>> 
>> On 6 Jun 2022, at 11:59, Ronald Klop  wrote:
>>  
>> Hi,
>> 
>> Building on aarch64/14-CURRENT fails with this error on my rpi4.
>> It failed on incremental build and tried a clean build today.
>> 
>> First failure was on "World build started on Sun May 29 00:25:17 UTC 2022".
>> 
>> This weekend it still fails (I'm building weekly in Jenkins).
>> 10:04:44 ===> tests/sys/kqueue/libkqueue (all)
>> 10:04:44 --- kqueue_test ---
>> 10:04:44 (cd /usr/src/tests/sys/kqueue/libkqueue &&  DEPENDFILE=.depend.kqueue_test  NO_SUBDIR=1 /usr/bin/make -f /usr/src/tests/sys/kqueue/libkqueue/Makefile _RECURSING_PROGS=t  PROG=kqueue_test )
>> 10:04:44 --- kqueue_test.full ---
>> 10:04:44 cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -fPIE -g -gz=zlib -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments  -pie  -o kqueue_test.full main.o read.o timer.o vnode.o proc.o signal.o user.o  
>> 10:04:44 ld: error: undefined symbol: test_no_kevents
>> 10:04:45 >>> referenced by read.c:169 (/usr/src/tests/sys/kqueue/libkqueue/read.c:169)
>> 10:04:45 >>>               read.o:(test_evfilt_read)
>> 10:04:45 >>> referenced by read.c:75 (/usr/src/tests/sys/kqueue/libkqueue/read.c:75)
>> 10:04:45 >>>               read.o:(test_evfilt_read)
>> 10:04:45 >>> referenced by read.c:137 (/usr/src/tests/sys/kqueue/libkqueue/read.c:137)
>> 10:04:45 >>>               read.o:(test_evfilt_read)
>> 10:04:45 >>> referenced 31 more times
>> 10:04:45 >>> did you mean: _test_no_kevents
>> 10:04:45 >>> defined in: main.o
>> 10:04:45 
>> 10:04:45 ld: error: undefined symbol: kevent_cmp
>> 10:04:45 >>> referenced by read.c:72 (/usr/src/tests/sys/kqueue/libkqueue/read.c:72)
>> 10:04:45 >>>               read.o:(test_evfilt_read)
>> 10:04:45 >>> referenced by read.c:145 (/usr/src/tests/sys/kqueue/libkqueue/read.c:145)
>> 10:04:45 >>>               read.o:(test_evfilt_read)
>> 10:04:45 >>> referenced by read.c:193 (/usr/src/tests/sys/kqueue/libkqueue/read.c:193)
>> 10:04:45 >>>               read.o:(test_evfilt_read)
>> 10:04:45 >>> referenced 14 more times
>> 10:04:45 >>> did you mean: _kevent_cmp
>> 10:04:45 >>> defined in: main.o
>> 10:04:45 cc: error: linker command failed with exit code 1 (use -v to see invocation)
>> 10:04:45       668.58 real       125.97 user        62.12 sys
>> 10:04:45 
>> 10:04:45 make[1]: stopped in /usr/src
>> 10:04:45 
>> 10:04:45 make: stopped in /usr/src
>> 10:04:45 Build step 'Execute shell' marked build as failure
>> 10:04:46 Skipped archiving because build is not successful
>> 10:04:46 Sending e-mails to: xxxx@yyyy.zzz
>> 10:04:47 Finished: FAILURE
>> 
>> Any thoughts? Similar experience?
>> 
>> Regards,
>> Ronald.
>> 
>>  
> 
>  

------=_Part_45_1775458143.1654515760488
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,



Mmm, took another look. I doubt my clean build was clean as "wipe out workspace" did not work because the Jenkins agent was offline.



The problem might be PEBCAK[1]. :-)



Doing another build with a fresh Jenkins workspace now. Will take 10+ hours to compile clang for the millionth time.



Ronald.

[1] https://en.wiktionary.org/wiki/PEBCAK

 

Van: Dimitry Andric <dim@FreeBSD.org>

Datum: maandag, 6 juni 2022 12:16

Aan: Ronald Klop <ronald-lists@klop.ws>

CC: freebsd-current <freebsd-current@freebsd.org>, Mark Johnston <markj@freebsd.org>

Onderwerp: Re: buildworld fail: ld: error: undefined symbol: test_no_kevents













Looks like it might be using an old version of tests/sys/kqueue/libkqueue/common.h, after https://cgit.freebsd.org/src/commit/?id=c728c56c870abe230e45cee5c477f0d890ebacef ?



 



Without seeing how the .o files have been compiled, specifically with which -I flags, it is impossible to see what is going wrong, though.



 



-Dimitry



 







On 6 Jun 2022, at 11:59, Ronald Klop <ronald-lists@klop.ws> wrote:

 




Hi,



Building on aarch64/14-CURRENT fails with this error on my rpi4.

It failed on incremental build and tried a clean build today.



First failure was on "World build started on Sun May 29 00:25:17 UTC 2022".



This weekend it still fails (I'm building weekly in Jenkins).





10:04:44 ===> tests/sys/kqueue/libkqueue (all)
10:04:44 --- kqueue_test ---
10:04:44 (cd /usr/src/tests/sys/kqueue/libkqueue &&  DEPENDFILE=.depend.kqueue_test  NO_SUBDIR=1 /usr/bin/make -f /usr/src/tests/sys/kqueue/libkqueue/Makefile _RECURSING_PROGS=t  PROG=kqueue_test )
10:04:44 --- kqueue_test.full ---
10:04:44 cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -fPIE -g -gz=zlib -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments  -pie  -o kqueue_test.full main.o read.o timer.o vnode.o proc.o signal.o user.o  
10:04:44 ld: error: undefined symbol: test_no_kevents
10:04:45 >>> referenced by read.c:169 (/usr/src/tests/sys/kqueue/libkqueue/read.c:169)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:75 (/usr/src/tests/sys/kqueue/libkqueue/read.c:75)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:137 (/usr/src/tests/sys/kqueue/libkqueue/read.c:137)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced 31 more times
10:04:45 >>> did you mean: _test_no_kevents
10:04:45 >>> defined in: main.o
10:04:45 
10:04:45 ld: error: undefined symbol: kevent_cmp
10:04:45 >>> referenced by read.c:72 (/usr/src/tests/sys/kqueue/libkqueue/read.c:72)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:145 (/usr/src/tests/sys/kqueue/libkqueue/read.c:145)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced by read.c:193 (/usr/src/tests/sys/kqueue/libkqueue/read.c:193)
10:04:45 >>>               read.o:(test_evfilt_read)
10:04:45 >>> referenced 14 more times
10:04:45 >>> did you mean: _kevent_cmp
10:04:45 >>> defined in: main.o
10:04:45 cc: error: linker command failed with exit code 1 (use -v to see invocation)
10:04:45       668.58 real       125.97 user        62.12 sys
10:04:45 
10:04:45 make[1]: stopped in /usr/src
10:04:45 
10:04:45 make: stopped in /usr/src
10:04:45 Build step 'Execute shell' marked build as failure
10:04:46 Skipped archiving because build is not successful
10:04:46 Sending e-mails to: xxxx@yyyy.zzz
10:04:47 Finished: FAILURE








Any thoughts? Similar experience?



Regards,

Ronald.



 













 







------=_Part_45_1775458143.1654515760488--

From nobody Mon Jun  6 12:18:22 2022
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 828961BE4172
	for ; Mon,  6 Jun 2022 12:18:27 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LGsw23J92z3KCn
	for ; Mon,  6 Jun 2022 12:18:26 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x52c.google.com with SMTP id h19so18609020edj.0
        for ; Mon, 06 Jun 2022 05:18:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to;
        bh=fulvr7w7Ihoz89pTluOiJps8+2P32ZmDF9EuRdcAv4c=;
        b=Dcj+s/t2keXimEsQRn9HdH99cV3e3SV82OMv1/GwbkAQb7xXV0FQUl/tXZAyFnwDub
         VXVW151d9uIxUx+YLIm23xaJYlOLT6lzskHkuV2tmOhLzeyg0OEiFOSH9n3GDehwaIOw
         sAAdGKRgk/2eqFNhjjGiDqTbHHH2hfEFlePypzJeksvkBgNUYjIHFDKC4mmgfQzojCw7
         mVtBZAWQU5MPAEodZxcxfU2Y+2pZr8tyWCNrjsQveSMjHwMdHJSrxhqMz/xALSC8TilQ
         aOVPevorYbfXyV/0MdCpdHCfmgvaaOLeWUmFKMHUEebLTEmY6HtSISKyzoIQyLJ8TuSr
         S/5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to;
        bh=fulvr7w7Ihoz89pTluOiJps8+2P32ZmDF9EuRdcAv4c=;
        b=0Z1vHxXWum23M6cqYf8EPJxE8EeZ6aP6orMYvumgI+uq5i15xvy3T1d4iXrQUF8Yi7
         //LidhDaTvsZJGOowy2Pd7X+sHtbYHPmuYpoe0+TJEugBpKhmlyavtScxORfg1ozInan
         7cyFAoIwr7Pct9mX/vJliNnWcl/aaABrUbl1ecGTEmEf69kvU6HHnsq/UBOrs3uCTAUN
         nYbPF2DDg58tVma4AbNz9G+j2yt7jjlziohRTNlFfFxrXBy7LFqcvXu+FU0IwdPrqN3z
         0tY1GNHqAOVSoyhNrCKMhmq/sEohVxH8S2X9I+biSR7dsolpth4Tfy6s3eSE9Q/swE9E
         xp6g==
X-Gm-Message-State: AOAM530dyXLzTOs+wGPS7Sjit8d+XzLWqqP3tpGWfS+rPBqvkIoMOcw/
	0V1sRSlz7mCVQuPKfcB1eVqwi3toH+c=
X-Google-Smtp-Source: ABdhPJxaJT7+WLaqN/2rmE1GKlZZYfeLqMCjxLxkuv9/s4XFCIYQjrNnQsNY6/RBd5QRiI4C6EgpfQ==
X-Received: by 2002:a05:6402:42c6:b0:42d:ed84:6fe0 with SMTP id i6-20020a05640242c600b0042ded846fe0mr26430141edc.58.1654517905360;
        Mon, 06 Jun 2022 05:18:25 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-027-054.46.114.pool.telefonica.de. [46.114.27.54])
        by smtp.googlemail.com with ESMTPSA id h4-20020a17090791c400b007109b15c109sm3081856ejz.66.2022.06.06.05.18.24
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 06 Jun 2022 05:18:24 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: buildworld fail: ld: error: undefined symbol: test_no_kevents
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Priority: 3 (Normal)
In-Reply-To: <1606971861.46.1654515760545@localhost>
Date: Mon, 6 Jun 2022 14:18:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <172777947.19.1654509576898@localhost>
 <15688335-6503-4120-985A-34A7BF3FBEA7@FreeBSD.org>
 <1606971861.46.1654515760545@localhost>
To: Ronald Klop ,
 freebsd-current@freebsd.org
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4LGsw23J92z3KCn
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b="Dcj+s/t2";
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-2.82 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[googlemail.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[googlemail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 HAS_X_PRIO_THREE(0.00)[3];
	 NEURAL_HAM_SHORT(-0.66)[-0.663];
	 DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[googlemail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.71)[-0.705];
	 R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	 RECEIVED_SPAMHAUS_PBL(0.00)[46.114.27.54:received];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-0.95)[-0.952];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> Am 06.06.2022 um 13:42 schrieb Ronald Klop :
>=20
>=20
> =E2=80=A6.. Will take 10+ hours to compile clang for the millionth =
time.
>=20
I also often prefer compiling on target hardware=E2=80=A6 but to be =
honest: cross compiling=20
on -j(fullspeed)-machines to PXE-boot one slow boards is the only =
=E2=80=9Epainless" workflow.
On the other hand e.g. / NO_OBJWALK / perhaps should work as expected  =
w/o ld-error and w/o using WITHOUT_TESTS(in this case),
so up to you filing a bug report if you think it=E2=80=99s worth..


From nobody Mon Jun  6 15:26:39 2022
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 1AA0E1BE20BC
	for ; Mon,  6 Jun 2022 15:28:50 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LGy7k0J9fz4SRM;
	Mon,  6 Jun 2022 15:28:50 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1654529330;
	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=Ho5RmWFaBgxHg6xnETW59Yvmzk4nOcnba0FcbpU5814=;
	b=DQanKikPH7z0FZDRSq41BeRp3fUnPfFYyYN3kinJWR+6Vp0veaBRoETno/r0zgSzzQjfOU
	NN/Y5s5PsF+7pcRC+un6jsRZAEdojcauPlWvxgOjVFwwvvpR+JO/zE95Gror8/acggGyhv
	PtWInFwZcwcxTcXrZhquXGIXajNRkqSxbVLnlULDqDlTnuAqsATd97+ylMOXxqhXb1bQ7Z
	0vxB0lxdNbU+uC/7u5TUqFZeS4b2XwQ7CAqpxmbivRs2z7WEkiNo3XgYtbkslsQ/tTfmP1
	GiKSaM+W79nADwlEdB/voA0saQ7eTWyGfMZPUAT5kZ8B/6p3ERWQSjhKfnMuBg==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:259a:12f2:1044:3ac7])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 57FA4A497;
	Mon,  6 Jun 2022 15:28:49 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Tue, 07 Jun 2022 00:26:39 +0900 (JST)
Message-Id: <20220607.002639.84721124176949243.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: Kernel crashed with "panic: VERIVY(e->lse-mscount != 0) failed"
From: Yasuhiro Kimura 
In-Reply-To: <94dcd569-94a8-58ae-f02e-a73a40505242@FreeBSD.org>
References: <20220604.212512.1183180807227243032.yasu@FreeBSD.org>
	<94dcd569-94a8-58ae-f02e-a73a40505242@FreeBSD.org>
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654529330;
	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=Ho5RmWFaBgxHg6xnETW59Yvmzk4nOcnba0FcbpU5814=;
	b=e5G5bXLrwCNI2EY23tQSGeBNHNilbWAEbXKCrZiASQrtE8fcNClWcP8g13B2pUcgXYm88c
	XERIYOsGNTKchtnT5x3Yk2QHLjuIwdVQ941z5b7c3XdVl1YHotwbvuj5u7Dogfex0u/gLf
	Z6ukoLyiOc4XTvy9w0T+aoqeWOZ6P+1qD9pS+IoAM0CorqeT+jym60vJJ9/94HPGIXFhJs
	6L6OGCUpvf6xy7/Fxj9zwVdOSEge+nUMaZ1UfP4JtAjeIq1VAhc1lTy5BISjv2yH0s7SFG
	wqHjZuFqqP/mcna/EENi/Gt/MXCpHIE12o9jJSuubTwmPKrAQDg5hI6ADgM/rg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654529330; a=rsa-sha256; cv=none;
	b=Oq7BCVwBB9J0qfqsp8ht4RfaE+MwjVcsfwdaKcPlEG+gIMD3AFLQGOiXX8DgcAUURkRE0A
	CdYdRFVfsOiof4NCnzM3xcLc+enfMQKdNnql32QEfPFbtkTNsyElYMoDXlegNnsYNH+HL7
	xnxnjNcM2igQlqmw5OGW9H5TlRVbwQ1Mh81ZCVQ4lpqm5EXVgYjqRhIjfMEkoVA5XfFjFL
	FHA4CWUSA+iZnMNkK7/8xBG0orqnPYiA+6fyW4Toamf3TG+L0MQ09BzjAz+n69N9NBaNQe
	Jpf0F8ahaefMRIo31JEAhH4O1yQdVIdAi4XZu/KMEpDWZWnUSCh9reua5G0D/w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

From: Alexander Motin 
Subject: Re: Kernel crashed with "panic: VERIVY(e->lse-mscount != 0) failed"
Date: Sun, 5 Jun 2022 09:33:21 -0400

> Hi,
> 
> Please update your system once more.  That wrong assertion was removed
> soon after your checkout at e3aa18ad717.

Thanks. After updating latest commit `poudriere bulk` completed
successfully.

---
Yasuhiro Kimura

From nobody Tue Jun  7 12:10:35 2022
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 78C4E12D311F
	for ; Tue,  7 Jun 2022 12:11:20 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic314-20.consmr.mail.ne1.yahoo.com (sonic314-20.consmr.mail.ne1.yahoo.com [66.163.189.146])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LHTjL1XHGz3FWp
	for ; Tue,  7 Jun 2022 12:11:18 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654603871; bh=BXxDnsaSW+CyC8nUAFVJ8ND020cQO92n9Q1N7FRZX8I=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=leEAf/w0pzQAXWMcwea5XxTfal6URkkZr29hWSo8iWrNomUwLyk39ii+2cwd7oe1F/ZaUOuAoalHSTJIZRgmC2Ojjf+V9q/PuEjboOFsYrAICqSDstfQ0jNSNMNe3rb4hZtTfCZ37QDvgqZWFlm/9HE1MYOW57RdSdVG7YQXGJC8DyYjTqS1FSXzxRt0SqUjzIPp20FdtOqjOdEozAqrqwxfQpHf730iOVAQD3R5CdKKX4SQLGmzB2xK/OCeRF0oiNA42NpEZnzdicbuJPPCeyOAtfRs6CcRi+VwZZENnkIQ/b/RsACHA8ZpWCsWjAD7Ow/m3HY+8zy4ZDKtAC2CeA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654603871; bh=gfHnGLRRIeX94/EQ8Yje0JtqBQkQ8kAHeX+DJ0PHSWT=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=JxSnUioqKwsrAyTlzVSCXxcEyiqkRKyN6NnRYcoGziOLJr8F7XMUZSWyZ0Gqas8Plkox4kAuPRonxa59n6A5a/kn+x/qKduw9hg3H6loyAnoRDC5eXbz/tnyZGnJ+RhKYUncbXMBe3DDztB+MwOouoqUujitL+FFHjFhqsz769RFiaFkuGIqrlsxW/8lqUFytYBTTxZ309reQxsfMxL9pElyN+meMBSPvuf6ubbNNYM+ShzVPMbuPUyMqXyA36gJfIf0EAt84u3HQ8fxJJ2as/d/FwwyC/ukUCkeZjwi9m4p9EfpxMg6Cuw7efdyL5qqKSLCNOM/v0Z6MCzpnxjJCQ==
X-YMail-OSG: lAkvQUIVM1l.XyrfIU9cCL3Cc.fW0kAOoACOOIhZ_OKZYohEt1Dc4.CbJwCBfIZ
 uqnk0KSusxQ8wVCvbjhPFLqnbeSQAgRkVli4w_M0cot.Lu.e1roPFr3xo_Xk9s79PDXHoGGdSa25
 WEjBgmmj4IfbhP5zyugnJlbQSmO63jZQLjhkNiMdqh68X48B1uN5aOmAgKoAr_nmOJQpLPL49DVl
 fwmAlTVl5yTPGKDrVzTvE405bpi24PkjOk6g_SUlNLjTQHrVFFJQoFskWH9iMaoT3KUZGEL5WGL.
 SFbqKgSI5lKFlo5SGZ.OHYOCP2tROdGdRN5tLgpPtgIJ7qRKyJy_MQqNIirKEKC44OLs_2v2BuDH
 z7cJ1nUVKhC.f2pHDqkyDPciCYNHgq1XzZnPt8WSIdEzGPMnkOTyUf8rP8cFClxJkjOZqySX3hIP
 Uu7LLo.mVDqrQEvXixvxu9xE19z5SWEzU1etJKZhy6fOBwPOrClYc8P.RljxnQkBjxQIOecaRYt8
 33a55y8tX7IM1fSJASx5O9Ehx9OaKXol5x_El7IRQrZmLzLwaKfXkb_3VxsMevf6A5DCcamsRMW8
 UcFndtz9gQq_rwPtDqZkk_KjXKr0cFDUW9XhWJiA7KdxxaAbJ2zJ8SCIDsTNnR0mFMgnAfQiAZ67
 U.IvnXwIsgXcEDJQYcgz2Wsg4PavJ77Gu7OTvXmGxcU5p2ufQM_cpfmBLG8zGEMFFYEVzKN8y52d
 7IbvTJcfGK93o2G70dt23ayCDVvMPuW7QhJxBMTx.zRC05H4rlHw7gvXnnBIopubjJgOWaIxHXlL
 QThODl1A2NL3UDxGl4YTwCa4kadTbm_VhJHZu78g4svB_cg9pBQXCml1CDA9q9gyJ_zn5PzXHoPQ
 Pin4_kdG5gMQtjMdWbAEMGn8vHopLGs9lsU79KDcC9Gregvaxob8VABsvuOE7y685Jk4i1LnM0Xv
 DPupPlfgeizEzWq67sakWHvSeYBn31.bEMBjdChohUmgmSAC1pylrRD1EYpMgEeugaAfv1YHynmo
 JwGHFmzWgaOFv4BnxOum2we.smlFHnCqzZnwErkpGqpogKqVcOVzdE0VNPAGnfJK37L1vtCWUxbx
 5wPVOgsFarCVpfBcmSSo21U8cGBIZmFnK5ak1qAsK01fKHno4U8Jfae0KgxSJOBf_CyIq8AGm3h8
 qTFpy_BuIZHyeJ7xDw95QdCl8PkzJgLbNP9QIrhYE7NHkdsv7GisWFr8QTFw9Y1eE7Ln6C06sjiF
 zZd_kn...EIGbWNBc25.JjOTeqORY4cllhL_4Nd5vE.oQQ4CDBWW._A5q1BFTvDCtZhH5vqm_F_8
 ikCkZB_QKowRZQZWmoARrSnYweRCEGd1QT0lkSV4Tn1jMCtKctVJaiu.ol74pG87fl5HjuSW0xU7
 QuI2Sw6nDQGTVoaCTk.Rl1JoruveLOuc1Tvh_s7a2TsXCSXaQXrqvC.Y_nQOeB3oGEU8UBDqNkEF
 J2UHAA3qs5Eu749MbAERoZpujbPrBoImN_VKohwWMv7axC9I2_99KnMYTcjevoYrpQTZEI8Bxowx
 8rAjDpNXv9d0LYJp8AEKIoCsA7VYjx4M.4FMsyK071WETheGc9Q_hvfcVQio.TcPJVN.0ixOqde3
 kx0wlaQXEvPb1K41wpGUOqI9WdpVqlG_CnGpcnBjXuF9Nvn_4RsjEQA4QPfugpiHZsSqbOhqOo3.
 QN6ZqPlkAZTX7mvbaShTTjkdJSGjAsmwqdSjvgLDAimZlDhkhnQ9O_PiKpM3bPMmKcNYjYHpxlIB
 l0Xd.NML9zdCgxLOTKwN9VjjW9Mf62mK2tJBoSfGClmAW_hoFejgG5tDgzGjmDlR.82dJ5kAbrpf
 GKvWLz1oGlu3onV_I6ELKpF4jzpxDoct2KUX.NB6PyPbUN0.IP0url97DvNIBC6EEHkTTfaEEi8W
 j5AYLxYSoGCt2SQXXnhwucMKp24CtXZB3IGefJBcdzKmw6VG1TSFsHqUPJARasvk6mu1WOCpP9AO
 awF9p1FVDNxdHzA9FOQmV.0sNtaB7eUJ4N8k9N46jt__hcXQZf9IAYDgYXNZMSegYJU2U1rSIdoc
 FETC9kxb.WGyKQcn_J0pLs2xSdgGUlrXkWy3B6MxV9GUuOazATT.CZmMGIFxDaf3l5sJrX2aQJkZ
 qjymNi_TTFJJ_OYhiVC8BRyh9
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Tue, 7 Jun 2022 12:11:11 +0000
Date: Tue, 7 Jun 2022 12:10:35 +0000 (UTC)
From: Filippo Moretti 
To: FreeBSD Current 
Message-ID: <1932797089.307285.1654603835293@mail.yahoo.com>
Subject: Problem with Radeon
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_307284_556835552.1654603835291"
References: <1932797089.307285.1654603835293.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.20280 YMailNorrin
X-Rspamd-Queue-Id: 4LHTjL1XHGz3FWp
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="leEAf/w0";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.189.146 as permitted sender) smtp.mailfrom=filippomore@yahoo.com
X-Spamd-Result: default: False [-3.98 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 NEURAL_HAM_LONG(-0.99)[-0.992];
	 RCPT_COUNT_ONE(0.00)[1];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[66.163.189.146:from];
	 NEURAL_HAM_SHORT(-0.99)[-0.993];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_307284_556835552.1654603835291
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I have reinstalled CURRENT and I get an error while trying to initialize ra=
deon:it was working fine before reinstalling CURRENT.

[drm] radeon kernel modesetting enabled.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
drmn0:  on vgapci0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
vgapci0: child drmn0 requested pci_enable_io=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
vgapci0: child drmn0 requested pci_enable_io=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
[drm] initializing kernel modesetting (REDWOOD 0x1002:0x68D8 0x1043:0x0356 =
0x00)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 .=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
[drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO fo=
r ATO=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 M IIO=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
ATOM BIOS: 68D8.12.17.0.4.AS06.U122
drmn0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
drmn0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
[drm] Detected VRAM RAM=3D1024M, BAR=3D256M
[drm] RAM width 128bits DDR
[TTM] Zone=C2=A0 kernel: Available graphics memory: 8373714 KiB
[TTM] Zone=C2=A0=C2=A0 dma32: Available graphics memory: 2097152 KiB
[TTM] Initializing pool allocator
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 1024M of GTT memory ready.
[drm] Loading REDWOOD Microcode
drmn0: could not load firmware image 'radeon/REDWOOD_pfp.bin'
r600_cp: Failed to load firmware "radeon/REDWOOD_pfp.bin"
[drm ERROR :evergreen_init] Failed to load firmware!
drmn0: Fatal error during GPU init
[drm] radeon: finishing device.
[TTM] Finalizing pool allocator
[TTM] Zone=C2=A0 kernel: Used memory at exit: 0 KiB
[TTM] Zone=C2=A0=C2=A0 dma32: Used memory at exit: 0 KiB
[drm] radeon: ttm finalized
Warning: can't remove non-dynamic nodes (dri)!
device_attach: drmn0 attach returned 2
acpi_wmi0:  on acpi0
These are the ports installed:drm-510-kmod-5.10.113_1=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 DRM drivers modules
drm-kmod-20220501=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 Metaport of DRM modules for the linuxkpi-based KMS co=
mponents
gpu-firmware-amd-kmod-banks-20220511 Firmware modules for banks AMD GPUs
gpu-firmware-kmod-20220511,1=C2=A0=C2=A0 Firmware modules for the drm-kmod =
drivers
gpu-firmware-radeon-kmod-aruba-20220511 Firmware modules for aruba Radeon G=
PUs

FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-85d7875d42: Mon Jun=
=C2=A0 6 13:40:11 CEST 2022=C2=A0=C2=A0=C2=A0=C2=A0 filippo@STING:/usr/obj/=
usr/src/amd64.amd64/sys/STING amd64

------=_Part_307284_556835552.1654603835291
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I have reinstalled CURRENT and I get an erro=
r while trying to initialize radeon:it was working fine before reinstalling=
 CURRENT.

[drm] radeon kernel modes=
etting enabled.          =
            &nb=
sp;            =
            &nb=
sp;            =
      
drmn0: <drmn> on vgapci0 &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     
vgapci0: child drmn0 requested pci_enable_io=
            &nb=
sp;            =
            &nb=
sp;            =
            
vgap=
ci0: child drmn0 requested pci_enable_io      =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      
sysctl_warn_reuse: can't re-use a leaf =
(hw.dri.debug)!          =
            &nb=
sp;            =
            &nb=
sp;    
[drm] initializing kernel modesetting (REDWOOD 0x=
1002:0x68D8 0x1043:0x0356 0x00)       &n=
bsp;            =
;      .       =
            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;             =
;
[drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MM=
IO for ATO           =
;            &n=
bsp;  M IIO          =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;          
ATOM BIOS: 68D8=
.12.17.0.4.AS06.U122
drmn0: VRAM: 1024M 0x0000000000000000 - 0x000000003=
FFFFFFF (1024M used)
drmn0: GTT: 1024M 0x0000000040000000 - 0x000000007F=
FFFFFF
[drm] Detected VRAM RAM=3D1024M, BAR=3D256M
[drm] RAM width 12=
8bits DDR
[TTM] Zone  kernel: Available graphics memory: 8373714 Ki=
B
[TTM] Zone   dma32: Available graphics memory: 2097152 KiB[TTM] Initializing pool allocator
[drm] radeon: 1024M of VRAM memory r=
eady
[drm] radeon: 1024M of GTT memory ready.
[drm] Loading REDWOOD M=
icrocode
drmn0: could not load firmware image 'radeon/REDWOOD_pfp.bin'r600_cp: Failed to load firmware "radeon/REDWOOD_pfp.bin"
[drm ERROR :=
evergreen_init] Failed to load firmware!
drmn0: Fatal error during GPU i=
nit
[drm] radeon: finishing device.
[TTM] Finalizing pool allocator[TTM] Zone  kernel: Used memory at exit: 0 KiB
[TTM] Zone &n=
bsp; dma32: Used memory at exit: 0 KiB
[drm] radeon: ttm finalized
Wa=
rning: can't remove non-dynamic nodes (dri)!
device_attach: drmn0 attach=
 returned 2
acpi_wmi0: <ACPI-WMI mapping> on acpi0
=

These are the ports =
installed:
drm-510-kmod-5.=
10.113_1        DRM drivers modules
d=
rm-kmod-20220501          =
;    Metaport of DRM modules for the linuxkpi-based KMS comp=
onents
gpu-firmware-amd-kmod-banks-20220511 Firmware modules for banks A=
MD GPUs
gpu-firmware-kmod-20220511,1   Firmware modules for th=
e drm-kmod drivers
gpu-firmware-radeon-kmod-aruba-20220511 Firmware modu=
les for aruba Radeon GPUs

FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-85d7875d42=
: Mon Jun  6 13:40:11 CEST 2022     filippo@STING:=
/usr/obj/usr/src/amd64.amd64/sys/STING amd64

------=_Part_307284_556835552.1654603835291--

From nobody Tue Jun  7 12:14:18 2022
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 846E012D459F
	for ; Tue,  7 Jun 2022 12:14:30 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
Received: from mx.blih.net (mx.blih.net [212.83.155.74])
	(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 "mx.blih.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LHTn14B0Zz3GXS
	for ; Tue,  7 Jun 2022 12:14:29 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com;
	s=mx; t=1654604061;
	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=e53idBeAs1ObRbmNI/L2T2xusH0iTaYmj2S3zokj2c4=;
	b=PI1UdukBOfsa3mSeSqKBf1h/Qa4AgVir7/MaK7Zh0qVpoKMp4x3Bv6kwSBLBivPc9qN31o
	sE2OgEScJYhc38mEmWnnQ4TxX3RE0qlhc5RGfiIt4kHb3Emr2sH98y2+cLAr+jQeiCLwji
	zTYpZj7zJ5pcjzOz2gU83mqrwvL62jI=
Received: from skull.home.blih.net (lfbn-idf2-1-1518-133.w92-169.abo.wanadoo.fr [92.169.82.133])
	by mx.blih.net (OpenSMTPD) with ESMTPSA id fcabb04a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Tue, 7 Jun 2022 12:14:21 +0000 (UTC)
Date: Tue, 7 Jun 2022 14:14:18 +0200
From: Emmanuel Vadot 
To: Filippo Moretti 
Cc: FreeBSD Current 
Subject: Re: Problem with Radeon
Message-Id: <20220607141418.3fd3e8b796c4cb6efb430409@bidouilliste.com>
In-Reply-To: <1932797089.307285.1654603835293@mail.yahoo.com>
References: <1932797089.307285.1654603835293.ref@mail.yahoo.com>
	<1932797089.307285.1654603835293@mail.yahoo.com>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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-Rspamd-Queue-Id: 4LHTn14B0Zz3GXS
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bidouilliste.com header.s=mx header.b=PI1UdukB;
	dmarc=pass (policy=none) header.from=bidouilliste.com;
	spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx];
	 FREEFALL_USER(0.00)[manu];
	 FROM_HAS_DN(0.00)[];
	 MV_CASE(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bidouilliste.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[yahoo.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 7 Jun 2022 12:10:35 +0000 (UTC)
Filippo Moretti  wrote:

> I have reinstalled CURRENT and I get an error while trying to initialize =
radeon:it was working fine before reinstalling CURRENT.
>=20
> [drm] radeon kernel modesetting enabled.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 =A0
> drmn0:  on vgapci0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0
> vgapci0: child drmn0 requested pci_enable_io=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 =A0
> vgapci0: child drmn0 requested pci_enable_io=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 =A0
> sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0
> [drm] initializing kernel modesetting (REDWOOD 0x1002:0x68D8 0x1043:0x035=
6 0x00)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 .=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0
> [drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO =
for ATO=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 M IIO=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0
> ATOM BIOS: 68D8.12.17.0.4.AS06.U122
> drmn0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
> drmn0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
> [drm] Detected VRAM RAM=3D1024M, BAR=3D256M
> [drm] RAM width 128bits DDR
> [TTM] Zone=A0 kernel: Available graphics memory: 8373714 KiB
> [TTM] Zone=A0=A0 dma32: Available graphics memory: 2097152 KiB
> [TTM] Initializing pool allocator
> [drm] radeon: 1024M of VRAM memory ready
> [drm] radeon: 1024M of GTT memory ready.
> [drm] Loading REDWOOD Microcode
> drmn0: could not load firmware image 'radeon/REDWOOD_pfp.bin'
> r600_cp: Failed to load firmware "radeon/REDWOOD_pfp.bin"
> [drm ERROR :evergreen_init] Failed to load firmware!
> drmn0: Fatal error during GPU init
> [drm] radeon: finishing device.
> [TTM] Finalizing pool allocator
> [TTM] Zone=A0 kernel: Used memory at exit: 0 KiB
> [TTM] Zone=A0=A0 dma32: Used memory at exit: 0 KiB
> [drm] radeon: ttm finalized
> Warning: can't remove non-dynamic nodes (dri)!
> device_attach: drmn0 attach returned 2
> acpi_wmi0:  on acpi0
> These are the ports installed:drm-510-kmod-5.10.113_1=A0=A0=A0=A0=A0=A0=
=A0 DRM drivers modules
> drm-kmod-20220501=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Metaport of DRM =
modules for the linuxkpi-based KMS components
> gpu-firmware-amd-kmod-banks-20220511 Firmware modules for banks AMD GPUs
> gpu-firmware-kmod-20220511,1=A0=A0 Firmware modules for the drm-kmod driv=
ers
> gpu-firmware-radeon-kmod-aruba-20220511 Firmware modules for aruba Radeon=
 GPUs

 "drmn0: could not load firmware image 'radeon/REDWOOD_pfp.bin'"
 You don't have the firmware installed for your card.
 How did you installed the packages ? because I see that you have
gpu-firmware-kmod so it should have installed all of them.
 Anyway, pkg install gpu-firmware-radeon-kmod-redwood should solve your
problems.

> FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-85d7875d42: Mon J=
un=A0 6 13:40:11 CEST 2022=A0=A0=A0=A0 filippo@STING:/usr/obj/usr/src/amd64=
.amd64/sys/STING amd64


--=20
Emmanuel Vadot  

From nobody Tue Jun  7 12:27:22 2022
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 47DB412D73CD
	for ; Tue,  7 Jun 2022 12:27:32 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic307-56.consmr.mail.ne1.yahoo.com (sonic307-56.consmr.mail.ne1.yahoo.com [66.163.190.31])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LHV4335bFz3KXh
	for ; Tue,  7 Jun 2022 12:27:31 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654604844; bh=xzBDLg60ptnThm8bXl2e2YB7UzvCVUxvZjcpLzQO1jQ=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=pMhwUo3/HXwlEmge3BULWPr2ATePM4JahhysWqChaTeBaV5JDSUvAgPA1AUpKAKLFsNOWsEzpb289xSsSYTfA8010Mv/IeIimU0UhxApcantI77PvTWrGHupCu/4zft+b/Fcxv3UjyKOeEl3jovltoKg5/S0y8ihXGE+a3uRimlGUv4ks/lQGda69GX5ju131JY/XFUEKFljzL1e9d5sdfvLEhb+9vjX7JtZuPmFD/Isxgni+rcj+yp+GpA5RRSy10p2PYIwCOXooFWPFWfNHoEOYqMBa3opq4ZLJAazK+2mdSMzQcsAv4sjiCD0vvdS7ivRU4r0BrbtHD9qfQAe7Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654604844; bh=Yr+9waGJiivFq6TXV2exjPnDR1WiFKcXQEgQ63SifOv=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=p9W7M4EF2pSMO1FPCMzfBCc/JhDDRPEc15C2tlm3KJbT09S/v09354CbaihKI1LzKTxOFqsPwWnWjzbRUELAzaLpV96WLsVmybUrCmndPjJ5qMf+J3zGBR8HN98iVWp7c+ySC5NLx2jSqiyNlr+y/FCYawn8H4vR27Hb4nks+Hn+5fW230itxAunSWtR9UxVAGzNujTemlVR6kRQyV4I0N7rwOxotcwTz5rgq/B2HMvqFpMSfddA2NHdCfO3QutvZvlzR0NQiDtvwmQDXqFWHlg3sz8LqEzU58Rl0i3MdWB9mj80B2GFzGTV4HkJw+u51qfQ3cdtHeEjPh9c20H2TQ==
X-YMail-OSG: zHqVGs4VM1mw6yh1l5cJ5jcAHgzciUxTfd0vCnrH2y2WDfKTUm2YGEVfXK3fho3
 8vYRUzBp3zEKG6YiHOM.FoQYzRgZqXknw4cFrUHZhTSgf9fJW90y6oOBKHsNTX9xZb0mOrPw9LQk
 2U8jYoZIY8zGdsI7g7IDJvpmnG4yMBKeWYIigJZBLSHGkRRrdo2ADF4cHnebQKNjHZNW5zpoUa0R
 LRYDWIBxM45ztz_GtdIU30vTs3x6BGeSBhDorhjQPTN9561LZy19IzsoG2_9cf3YaQlxygW.f6cr
 Lgrgb1Tzc4stnDWJUMs8zT0q0WwpI4BFKslYdWdKab3WAHVEHhF5yMeDfe5nuodgpjdvqGDLeEjf
 dmZlhXNQ.2tBWESGfPOH93.xxES_giqZnd1H3mg0E9D3KjJL52Zk1c.pAESmIhICCncajuGhbYMJ
 uw5pyxwWhhaMZ.H6N4TRfV_1sKGcb3esQY7RhB8zA8iFre1wUa7dR1ClwJEGQAoZGl.kmJM8AAtC
 O_zqBLgfhpH9hYTO2zUfX_cfJLTgiOA4D2787gN3w26aMKoK3rUw.W.rY_KBF7k.kEHwbbZeqv_n
 e.ZrzVmyXD94uKhzx3eStI4ZhxTXHzbvsun_XAZlyJtWjHxgQXZhiylhtU5r7IPa8VKf4v0ZDRfk
 FNPdhrERo8l4vhkKwblzDZYRYHC0VI._aKcThClN4c22.GUYI2ARZhmxnLX2tfiFY1kFCor0ufA1
 uhOZY.flh5r3XeU_a1C5lzp0ZvcLKbTfVMqH2bu1_GJx_0vYQ5xFNxaJenMFeUi_0Ktzq3xbHVNq
 FnL_vV6rzZqRW5WA4aADdOw4NRMIPhK3t3z2uAsCTdT4O5_jYsEF64xQUQGyunRbwxcoGCbYoFq0
 I1IfZ6dC0okCBGdc1AFGnQb1aPMU.mRufiHv3j5q76_BU3_hotODuRv8qeqwElDN56uN8nOweyV1
 _HhgOVElABt90HGtcptW5xLjytJIs2bfQwAP51i_pjCpehxDPnb7ge9KoGBr0NlUfocCgE0liezK
 Fo2lg7Vyzmdt9XWDnLqgu4Bh1hEXDJxjbHQXKNf__Kc3y04yPgEP.Ch369MpSxdTuCN72MLkNAnn
 OJqomZSPsAPn9jekNiI5KBaLA0wuvdsXMYMbnNppJ_Nq8glMTlmI3T8IjnJQIxTx5A7O.4VLhTb4
 UTl9mxcHOvBoXyE8P5HfjOB4bHIkQaHb84WLCdwjPTUlsTcVkfhgFd4KAKUeSi2zWSDXqDAD4fQA
 cTDb119Z.qg6raVNkOKU0D.00qw.vZc2aF_RmZa4oixBUmi77ajrCaWlPQe772xMHXrpG8ul.Dw3
 G8lKiwjDyL57fDrJdyFyKNKaxClVEuOgHpeq7ZJIfsmP7iuzBJEOn607F3d7F01hi.Ac_N7kxyWJ
 hG7TNZ44cVldIKuiuAjFx2Nd4qVwHDQhdDKfA7rdbZ2OzrER1Yc2h3lCCwXqdHjqikFuzHjjMtOi
 vMn7fZuveJ7ceUo2uVeSXYSSbhQcCfF.SnGXALMo.4lJ6g9Og3kO1MjGk8AE42p7ptqHs.NPME_r
 KRYPhBRXN85_A73R9i42obKJdpBlZoDq0xcHvvwew1TrnPPjqYpBsMUd7UzrfsPNcNVZKCjO.IAT
 ATXAw3k2Czl1pXvoIca6AhRwubSYc5Sg4CYwCtKyqEuM9TjFmHmpHiKN8ffiqt6ycaGOR_KHlIMF
 HFDIh2.afrosUIgQbmySTSsW7mFEXY3LtoveIxgKvpk1MEz9Iq7e_I4ruj_ouHmXa.7t3lchhxAV
 5WQij2NxVAZd1fE.Aavxhf7BVDJWBWCVKqBVzH2SEMcPh0a5KhGgbiZUlA5jmzw5_u4I1wbpEUYY
 flCsI5nWhGVptuEsaEeKQI1SvGLFn7O1oFqW6a7rcBAgxkwLSP9AthE89yU8tAyyaaGm.WkKyYqK
 gdPd1Mr3qSVcqjjiTDxl40Mh01Hw7PSm8B4jD9XhwKtUAkD9mwoINYMwNdDo.46fFltkSIXNeadp
 o.qbwH4VJbPdJqqIV8gEHJGUw0UNkBwtAFdeH3YyriAXVJB2ngV3qdgFbbey7WWkyXpdRCPwa6zB
 ut1kLcpO4fRz8N1zNkjNsu3Fy8SUxtqvXXrYJb01pHRx9R.f0TnJcBXtb7TFFq8kyUmeTAiY1O._
 iXB_lWs4Mrps5BNNwYaH2ddVWOEw_fjpgoqnjWShO3nBYilz0DDT__ui58zr08CEqQ1UDuU3nXw1
 jINkbJ2U-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Tue, 7 Jun 2022 12:27:24 +0000
Date: Tue, 7 Jun 2022 12:27:22 +0000 (UTC)
From: Filippo Moretti 
To: Emmanuel Vadot , 
	FreeBSD Current 
Message-ID: <115090891.315615.1654604842644@mail.yahoo.com>
In-Reply-To: <20220607141418.3fd3e8b796c4cb6efb430409@bidouilliste.com>
References: <1932797089.307285.1654603835293.ref@mail.yahoo.com> <1932797089.307285.1654603835293@mail.yahoo.com> <20220607141418.3fd3e8b796c4cb6efb430409@bidouilliste.com>
Subject: Re: Problem with Radeon
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_315614_971410298.1654604842641"
X-Mailer: WebService/1.1.20280 YMailNorrin
X-Rspamd-Queue-Id: 4LHV4335bFz3KXh
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="pMhwUo3/";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.190.31 as permitted sender) smtp.mailfrom=filippomore@yahoo.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 RCVD_IN_DNSWL_NONE(0.00)[66.163.190.31:from];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_315614_971410298.1654604842641
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=20
I did install the ports,thank youFilippo
    On Tuesday, June 7, 2022 at 02:15:50 PM GMT+2, Emmanuel Vadot  wrote: =20
=20
 On Tue, 7 Jun 2022 12:10:35 +0000 (UTC)
Filippo Moretti  wrote:

> I have reinstalled CURRENT and I get an error while trying to initialize =
radeon:it was working fine before reinstalling CURRENT.
>=20
> [drm] radeon kernel modesetting enabled.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
> drmn0:  on vgapci0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
> vgapci0: child drmn0 requested pci_enable_io=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
> vgapci0: child drmn0 requested pci_enable_io=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
> sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
> [drm] initializing kernel modesetting (REDWOOD 0x1002:0x68D8 0x1043:0x035=
6 0x00)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 .=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
> [drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO =
for ATO=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 M IIO=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0
> ATOM BIOS: 68D8.12.17.0.4.AS06.U122
> drmn0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
> drmn0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
> [drm] Detected VRAM RAM=3D1024M, BAR=3D256M
> [drm] RAM width 128bits DDR
> [TTM] Zone=C2=A0 kernel: Available graphics memory: 8373714 KiB
> [TTM] Zone=C2=A0=C2=A0 dma32: Available graphics memory: 2097152 KiB
> [TTM] Initializing pool allocator
> [drm] radeon: 1024M of VRAM memory ready
> [drm] radeon: 1024M of GTT memory ready.
> [drm] Loading REDWOOD Microcode
> drmn0: could not load firmware image 'radeon/REDWOOD_pfp.bin'
> r600_cp: Failed to load firmware "radeon/REDWOOD_pfp.bin"
> [drm ERROR :evergreen_init] Failed to load firmware!
> drmn0: Fatal error during GPU init
> [drm] radeon: finishing device.
> [TTM] Finalizing pool allocator
> [TTM] Zone=C2=A0 kernel: Used memory at exit: 0 KiB
> [TTM] Zone=C2=A0=C2=A0 dma32: Used memory at exit: 0 KiB
> [drm] radeon: ttm finalized
> Warning: can't remove non-dynamic nodes (dri)!
> device_attach: drmn0 attach returned 2
> acpi_wmi0:  on acpi0
> These are the ports installed:drm-510-kmod-5.10.113_1=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 DRM drivers modules
> drm-kmod-20220501=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 Metaport of DRM modules for the linuxkpi-based KMS=
 components
> gpu-firmware-amd-kmod-banks-20220511 Firmware modules for banks AMD GPUs
> gpu-firmware-kmod-20220511,1=C2=A0=C2=A0 Firmware modules for the drm-kmo=
d drivers
> gpu-firmware-radeon-kmod-aruba-20220511 Firmware modules for aruba Radeon=
 GPUs

 "drmn0: could not load firmware image 'radeon/REDWOOD_pfp.bin'"
 You don't have the firmware installed for your card.
 How did you installed the packages ? because I see that you have
gpu-firmware-kmod so it should have installed all of them.
 Anyway, pkg install gpu-firmware-radeon-kmod-redwood should solve your
problems.

> FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-85d7875d42: Mon J=
un=C2=A0 6 13:40:11 CEST 2022=C2=A0=C2=A0=C2=A0=C2=A0 filippo@STING:/usr/ob=
j/usr/src/amd64.amd64/sys/STING amd64


--=20
Emmanuel Vadot  

 =20
------=_Part_315614_971410298.1654604842641
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



        

I did install=
 the ports,thank you
Filippo

       =20
        

            

               =20
                

                    On Tuesday, June 7, 2022 at 02:15:50 PM GMT+2, Emmanuel=
 Vadot <manu@bidouilliste.com> wrote:
                

                


                


                
On Tue, 7 Jun 2022 12:10:35 +0000 (UT=
C)
Filippo Moretti <filippomore@=
yahoo.com> wrote:

> I have r=
einstalled CURRENT and I get an error while trying to initialize radeon:it =
was working fine before reinstalling CURRENT.
> 
> [drm] radeon kernel modesetting enabled.   =
;            &n=
bsp;            =
;            &n=
bsp;            =
;             <=
br clear=3D"none">> drmn0: <drmn> on vgapci0   &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;   
> vgapci0: child drmn0 requested pci_e=
nable_io           &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;             =

> vgapci0: child drmn0 requested pci_enable_io &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;          
> sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!  =
            &nb=
sp;            =
            &nb=
sp;            
> [drm] initializing kernel modesetting (REDWOOD 0x1002:0x=
68D8 0x1043:0x0356 0x00)        &nb=
sp;            =
     .        &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            
> [drm ERROR :radeon_atombios_init] Unable to find PCI I/O =
BAR; using MMIO for ATO        &nbs=
p;            &=
nbsp;    M IIO       &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            
> ATOM BIOS: 68D8.12.17.0.4.AS06.U122
>=
; drmn0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)> drmn0: GTT: 1024M 0x0000000040000000 - 0x000000007FFF=
FFFF
> [drm] Detected VRAM RAM=3D1024M, BAR=3D256M
> [drm] RAM width 128bits DDR
> [TTM=
] Zone  kernel: Available graphics memory: 8373714 KiB
> [TTM] Zone   dma32: Available graphics memory: 2097152 Ki=
B
> [TTM] Initializing pool allocator
> [drm] radeon: 1024M of VRAM memory ready
> [drm=
] radeon: 1024M of GTT memory ready.
> [drm] Loading R=
EDWOOD Microcode
> drmn0: could not load firmware imag=
e 'radeon/REDWOOD_pfp.bin'
> r600_cp: Failed to load f=
irmware "radeon/REDWOOD_pfp.bin"
> [drm ERROR :evergre=
en_init] Failed to load firmware!
> drmn0: Fatal error=
 during GPU init
> [drm] radeon: finishing device.
> [TTM] Finalizing pool allocator
> =
[TTM] Zone  kernel: Used memory at exit: 0 KiB
> =
[TTM] Zone   dma32: Used memory at exit: 0 KiB
=
> [drm] radeon: ttm finalized
> Warning: can't remo=
ve non-dynamic nodes (dri)!
> device_attach: drmn0 att=
ach returned 2
> acpi_wmi0: <ACPI-WMI mapping> o=
n acpi0
> These are the ports installed:drm-510-kmod-5=
.10.113_1        DRM drivers modules
> drm-kmod-20220501      &n=
bsp;       Metaport of DRM modules for the li=
nuxkpi-based KMS components
> gpu-firmware-amd-kmod-ba=
nks-20220511 Firmware modules for banks AMD GPUs
> gpu=
-firmware-kmod-20220511,1   Firmware modules for the drm-kmod dri=
vers
> gpu-firmware-radeon-kmod-aruba-20220511 Firmwar=
e modules for aruba Radeon GPUs

 "drmn=
0: could not load firmware image 'radeon/REDWOOD_pfp.bin'"
 You don't have the firmware installed for your card.
 =
How did you installed the packages ? because I see that you have
gpu-firmware-kmod so it should have installed all of them.
 Anyway, pkg install gpu-firmware-radeon-kmod-redwood should so=
lve your
problems.


> FreeBSD STING 14.0-CURRE=
NT FreeBSD 14.0-CURRENT #1 main-85d7875d42: Mon Jun  6 13:40:11 CEST 2=
022     filippo@STING:/usr/obj/usr/src/amd64.=
amd64/sys/STING amd64



-- 
Emmanuel Vadot <ma=
nu@bidouilliste.com> <manu@freebsd.org
>


            

        

------=_Part_315614_971410298.1654604842641--

From nobody Wed Jun  8 01:37:52 2022
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 23A9E851BE2
	for ; Wed,  8 Jun 2022 01:38:11 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LHqcL2Mmyz3CgY
	for ; Wed,  8 Jun 2022 01:38:10 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: by mail-vs1-xe31.google.com with SMTP id x187so18410573vsb.0
        for ; Tue, 07 Jun 2022 18:38:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=gKFkERUQkorTxj04p37eQjmINwERg0HhnFGR1GNpZwg=;
        b=pW8MvhvlS8nzbulaiooFYCbNsi2S71tg468EC6Bh14kYKsenmvy5FFjDqSWCtOpE16
         q6HUEGbCnXCFwVAqOXA+nFMA/2srdGVGGdE5OKLFOHkYrfIV6iO7awRoqKWs5/cDZk/S
         rMQsVKdO26yRHE1gCQ1wjEvf3q74or3TKyuF7kNIdDGSX7qLC9mNMmJTVoUQghzfjpRK
         aDCdUWUCRBmojVUcSpQdMg0COV2cZVUam2Pb0h+eyRZlrRCOP88idm3iAD9X25Xtuvze
         WSoCBor9LNwU+RcoPLXHeT0DpI3c4+P23YG1t81RfcJW1YiE7mpnNey/lxxn1UUglPL/
         lz9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=gKFkERUQkorTxj04p37eQjmINwERg0HhnFGR1GNpZwg=;
        b=54Sfh7l0myBYpI9Hn6VCWoqGjBb5TkWgmvTW5rYxwKhD1dp/Ev+J1EUAZT+QpTKiFA
         gFbVGkf25Uag90oHdnSENaHwRf4HY1KcN9A7zf7EUmIxWRxl7HXl43sTOkBM/gqjOnzW
         aGlrjrFStSL13q7bvf1fPWFSNxnzQNyvia8tUnlldLhl8V/fQEsUqfDcubZTf+YcO2Y1
         QakrKgj6VvCReSVbrY8WVOlPAwe5vu81aApInqG4b84ZfNm6gE/CLFCZvh859NlNe1Nh
         XscxncH2iX+sySKUq/AEgLMhoja927QMNOiL/PYYti01Ya9b7yFqj47q7V/P9wy/JTb+
         TtTQ==
X-Gm-Message-State: AOAM530JHP1MDgSOWE9fsYQwcbz1xQAnQecFJsBmhMPwxVCA6vTBue0p
	bOyK+vJp3/jESnhHQaNZXJjPd1SrbG86Y2+9tndLB7AMhbY=
X-Google-Smtp-Source: ABdhPJyS4y69Hk2n/N6j86jRtWICk9Z8vf0Fg+VC0qUF1PFbvZXx1acspr2VCoZO3vCOpjgCc7Jd8pzOkTuVzzGXoDs=
X-Received: by 2002:a05:6102:54ac:b0:34b:b502:f5e7 with SMTP id
 bk44-20020a05610254ac00b0034bb502f5e7mr7090610vsb.58.1654652284214; Tue, 07
 Jun 2022 18:38:04 -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: Oleg Lelchuk 
Date: Tue, 7 Jun 2022 21:37:52 -0400
Message-ID: 
Subject: A kernel crash after compiling a fresh kernel
To: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000a0a2b805e0e5c132"
X-Rspamd-Queue-Id: 4LHqcL2Mmyz3CgY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=pW8Mvhvl;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of oleglelchuk@gmail.com designates 2607:f8b0:4864:20::e31 as permitted sender) smtp.mailfrom=oleglelchuk@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000a0a2b805e0e5c132
Content-Type: text/plain; charset="UTF-8"

The 14-CURRENT running a fresh kernel crashes with these messages:

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55              __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
                                (kgdb) #0  __curthread () at
/usr/src/sys/amd64/include/pcpu_aux.h:55
#1  dump_savectx () at /usr/src/sys/kern/kern_shutdown.c:401
#2  0xffffffff80be8ba5 in dumpsys (di=0x0)
                                at /usr/src/sys/x86/include/dump.h:87
#3  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:430
#4  kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:537
#5  0xffffffff80be8fee in vpanic (fmt=,
        ap=ap@entry=0xfffffe01042395a0) at
/usr/src/sys/kern/kern_shutdown.c:975
#6  0xffffffff80be8d53 in panic (fmt=)
                                at /usr/src/sys/kern/kern_shutdown.c:899
#7  0xffffffff810c0877 in trap_fatal (frame=0xfffffe0104239690, eva=0)
                                at /usr/src/sys/amd64/amd64/trap.c:942
#8  0xffffffff810c092b in trap_pfault (frame=0xfffffe0104239690,
        usermode=false, signo=, ucode=)
                                at /usr/src/sys/amd64/amd64/trap.c:761
#9  
#10 tcp_sack_output (tp=tp@entry=0xfffffe0187312140,
        sack_bytes_rexmt=sack_bytes_rexmt@entry=0xfffffe010423983c)
                                at /usr/src/sys/netinet/tcp_sack.c:970
#11 0xffffffff80dd47a2 in tcp_default_output (tp=0xfffffe0187312140)
at /usr/src/sys/netinet/tcp_output.c:310
#12 0xffffffff80dcd240 in tcp_output (tp=tp@entry=0xfffffe0187312140)
at /usr/src/sys/netinet/tcp_var.h:407
#13 0xffffffff80dcc81a in tcp_do_segment (m=0xfffff80203467700,
                th=0xfffff8001f190022, so=0xfffff80015d0fb40,
tp=0xfffffe0187312140,
                drop_hdrlen=64, tlen=, iptos=0 '\000')
at /usr/src/sys/netinet/tcp_input.c:2788
#14 0xffffffff80dc8def in tcp_input_with_port (mp=,
                offp=, proto=, port=port@entry
=0)
at /usr/src/sys/netinet/tcp_input.c:1397
#15 0xffffffff80dc9c8b in tcp_input (mp=0xfffff8011c764010, offp=0x4,
                proto=-2128851986) at /usr/src/sys/netinet/tcp_input.c:1492
#16 0xffffffff80db8cd7 in ip_input (m=0x0)
at /usr/src/sys/netinet/ip_input.c:840
#17 0xffffffff80d3842f in netisr_dispatch_src (proto=1,
                source=source@entry=0, m=0xfffff80203467700)
at /usr/src/sys/net/netisr.c:1153
#18 0xffffffff80d3878f in netisr_dispatch (proto=477511696,
                m=0xffffffff811c4bee) at /usr/src/sys/net/netisr.c:1244
#19 0xffffffff80d1a7cc in ether_demux (ifp=ifp@entry=0xfffff80002873800,
m=0x4) at /usr/src/sys/net/if_ethersubr.c:925
#20 0xffffffff80d1be53 in ether_input_internal (ifp=0xfffff80002873800,
m=0x4)
at /usr/src/sys/net/if_ethersubr.c:711
#21 ether_nh_input (m=) at
/usr/src/sys/net/if_ethersubr.c:741
#22 0xffffffff80d3842f in netisr_dispatch_src (proto=proto@entry=5,
                source=source@entry=0, m=m@entry=0xfffff80203467700)
at /usr/src/sys/net/netisr.c:1153
#23 0xffffffff80d3878f in netisr_dispatch (proto=477511696, proto@entry=5,
                m=0xffffffff811c4bee, m@entry=0xfffff80203467700)
at /usr/src/sys/net/netisr.c:1244
#24 0xffffffff80d1ac89 in ether_input (ifp=0xfffff80002873800,
                m=0xfffff80203467700) at /usr/src/sys/net/if_ethersubr.c:832
#25 0xffffffff808f41f7 in re_rxeof (sc=sc@entry=0xfffffe00e1cce000,
                rx_npktsp=0x0) at /usr/src/sys/dev/re/if_re.c:2386
#26 0xffffffff808f1a16 in re_intr_msi (xsc=0xfffffe00e1cce000)
at /usr/src/sys/dev/re/if_re.c:2682
#27 0xffffffff80ba3d49 in intr_event_execute_handlers
(ie=0xfffff800020fde00,
                p=) at /usr/src/sys/kern/kern_intr.c:1205
#28 ithread_execute_handlers (ie=0xfffff800020fde00, p=)
at /usr/src/sys/kern/kern_intr.c:1218
#29 ithread_loop (arg=arg@entry=0xfffff800020fbf80)
at /usr/src/sys/kern/kern_intr.c:1306
#30 0xffffffff80ba03e0 in fork_exit (
                callout=0xffffffff80ba3ad0 ,
arg=0xfffff800020fbf80,
                frame=0xfffffe0104239f40) at
/usr/src/sys/kern/kern_fork.c:1102
#31 

--000000000000a0a2b805e0e5c132
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The 14-CURRENT runn=
ing a fresh kernel crashes with these messages:

__=
curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__asm("movq %%gs:%P1,%0" : =
"=3Dr" (td) : "n" (offsetof(struct pcpu,
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (kgdb) #0 =C2=A0__curthread () at /usr/src/sys/=
amd64/include/pcpu_aux.h:55
#1 =C2=A0dump_savectx () at /usr/src/sys/ker=
n/kern_shutdown.c:401
#2 =C2=A00xffffffff80be8ba5 in dumpsys (di=3D0x0)<=
br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 at /usr/src/sys/x86/include/dump.=
h:87
#3 =C2=A0doadump (textdump=3D1) at /usr/src/sys/kern/kern_shutdown.=
c:430
#4 =C2=A0kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutd=
own.c:537
#5 =C2=A00xffffffff80be8fee in vpanic (fmt=3D<optimized out=
>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ap=3Dap@entry=3D0xfffffe01042395a0) at=
 /usr/src/sys/kern/kern_shutdown.c:975
#6 =C2=A00xffffffff80be8d53 in pa=
nic (fmt=3D<unavailable>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a=
t /usr/src/sys/kern/kern_shutdown.c:899
#7 =C2=A00xffffffff810c0877 in t=
rap_fatal (frame=3D0xfffffe0104239690, eva=3D0)
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 at /usr/src/sys/amd64/amd64/trap.c:942
#8 =C2=A00xffffffff=
810c092b in trap_pfault (frame=3D0xfffffe0104239690,
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 usermode=3Dfalse, signo=3D<optimized out>, ucode=3D<opt=
imized out>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 at /usr/src/sys/amd=
64/amd64/trap.c:761
#9 =C2=A0<signal handler called>
#10 tcp_sa=
ck_output (tp=3Dtp@entry=3D0xfffffe0187312140,
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 sack_bytes_rexmt=3Dsack_bytes_rexmt@entry=3D0xfffffe010423983c)
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 at /usr/src/sys/netinet/tcp_sack.c:970#11 0xffffffff80dd47a2 in tcp_default_output (tp=3D0xfffffe0187312140)at /usr/src/sys/netinet/tcp_output.c:310
#12 0xffffffff80dcd240 in tcp_=
output (tp=3Dtp@entry=3D0xfffffe0187312140)
at /usr/src/sys/netinet/tcp_=
var.h:407
#13 0xffffffff80dcc81a in tcp_do_segment (m=3D0xfffff802034677=
00,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 th=3D0xfffff=
8001f190022, so=3D0xfffff80015d0fb40, tp=3D0xfffffe0187312140,
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 drop_hdrlen=3D64, tlen=3D&=
lt;optimized out>, iptos=3D0 '\000')
at /usr/src/sys/netinet/=
tcp_input.c:2788
#14 0xffffffff80dc8def in tcp_input_with_port (mp=3D<=
;optimized out>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 offp=3D<optimized out>, proto=3D<optimized out>, port=3Dpor=
t@entry=3D0)
at /usr/src/sys/netinet/tcp_input.c:1397
#15 0xffffffff8=
0dc9c8b in tcp_input (mp=3D0xfffff8011c764010, offp=3D0x4,
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 proto=3D-2128851986) at /usr/src=
/sys/netinet/tcp_input.c:1492
#16 0xffffffff80db8cd7 in ip_input (m=3D0x=
0)
at /usr/src/sys/netinet/ip_input.c:840
#17 0xffffffff80d3842f in n=
etisr_dispatch_src (proto=3D1,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 source=3Dsource@entry=3D0, m=3D0xfffff80203467700)
at /us=
r/src/sys/net/netisr.c:1153
#18 0xffffffff80d3878f in netisr_dispatch (p=
roto=3D477511696,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 m=3D0xffffffff811c4bee) at /usr/src/sys/net/netisr.c:1244
#19 0xffff=
ffff80d1a7cc in ether_demux (ifp=3Difp@entry=3D0xfffff80002873800,
m=3D0x4) at /usr/src/sys/net/if_ethersubr.c:925
#20 0xffffffff80d1be53=
 in ether_input_internal (ifp=3D0xfffff80002873800, m=3D0x4)
at /usr/src=
/sys/net/if_ethersubr.c:711
#21 ether_nh_input (m=3D<optimized out>=
;) at /usr/src/sys/net/if_ethersubr.c:741
#22 0xffffffff80d3842f in neti=
sr_dispatch_src (proto=3Dproto@entry=3D5,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 source=3Dsource@entry=3D0, m=3Dm@entry=3D0xffff=
f80203467700)
at /usr/src/sys/net/netisr.c:1153
#23 0xffffffff80d3878=
f in netisr_dispatch (proto=3D477511696, proto@entry=3D5,
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m=3D0xffffffff811c4bee, m@entry=
=3D0xfffff80203467700)
at /usr/src/sys/net/netisr.c:1244
#24 0xffffff=
ff80d1ac89 in ether_input (ifp=3D0xfffff80002873800,
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m=3D0xfffff80203467700) at /usr/src/=
sys/net/if_ethersubr.c:832
#25 0xffffffff808f41f7 in re_rxeof (sc=3Dsc@e=
ntry=3D0xfffffe00e1cce000,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 rx_npktsp=3D0x0) at /usr/src/sys/dev/re/if_re.c:2386
#26 0xff=
ffffff808f1a16 in re_intr_msi (xsc=3D0xfffffe00e1cce000)
at /usr/src/sys=
/dev/re/if_re.c:2682
#27 0xffffffff80ba3d49 in intr_event_execute_handle=
rs (ie=3D0xfffff800020fde00,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 p=3D<optimized out>) at /usr/src/sys/kern/kern_intr.c:1=
205
#28 ithread_execute_handlers (ie=3D0xfffff800020fde00, p=3D<optim=
ized out>)
at /usr/src/sys/kern/kern_intr.c:1218
#29 ithread_loop =
(arg=3Darg@entry=3D0xfffff800020fbf80)
at /usr/src/sys/kern/kern_intr.c:=
1306
#30 0xffffffff80ba03e0 in fork_exit (
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 callout=3D0xffffffff80ba3ad0 <ithread_lo=
op>, arg=3D0xfffff800020fbf80,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 frame=3D0xfffffe0104239f40) at /usr/src/sys/kern/kern_for=
k.c:1102
#31 <signal handler called>


--000000000000a0a2b805e0e5c132--

From nobody Wed Jun  8 03:06:03 2022
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 E46E1833CB4
	for ; Wed,  8 Jun 2022 03:06:12 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LHsYv6LFjz3Lly
	for ; Wed,  8 Jun 2022 03:06:11 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 258363S6038864;
	Wed, 8 Jun 2022 03:06:03 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 258363p8038863;
	Tue, 7 Jun 2022 20:06:03 -0700 (PDT)
	(envelope-from david)
Date: Tue, 7 Jun 2022 20:06:03 -0700
From: David Wolfskill 
To: Oleg Lelchuk 
Cc: freebsd-current@freebsd.org
Subject: Re: A kernel crash after compiling a fresh kernel
Message-ID: 
Mail-Followup-To: David Wolfskill ,
	Oleg Lelchuk , freebsd-current@freebsd.org
References: 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="CeSOY/sgAkQ6yCrH"
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4LHsYv6LFjz3Lly
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-3.41 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[david];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 DMARC_NA(0.00)[catwhisker.org];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 SIGNED_PGP(-2.00)[];
	 NEURAL_SPAM_SHORT(0.99)[0.991];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


--CeSOY/sgAkQ6yCrH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 07, 2022 at 09:37:52PM -0400, Oleg Lelchuk wrote:
> The 14-CURRENT running a fresh kernel crashes with these messages:
>=20
> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> 55              __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(st=
ruct
> pcpu,
>                                 (kgdb) #0  __curthread () at
> /usr/src/sys/amd64/include/pcpu_aux.h:55
> #1  dump_savectx () at /usr/src/sys/kern/kern_shutdown.c:401
> #2  0xffffffff80be8ba5 in dumpsys (di=3D0x0)
>                                 at /usr/src/sys/x86/include/dump.h:87
> #3  doadump (textdump=3D1) at /usr/src/sys/kern/kern_shutdown.c:430
> #4  kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:537
> #5  0xffffffff80be8fee in vpanic (fmt=3D,
>         ap=3Dap@entry=3D0xfffffe01042395a0) at
> /usr/src/sys/kern/kern_shutdown.c:975
> #6  0xffffffff80be8d53 in panic (fmt=3D)
>                                 at /usr/src/sys/kern/kern_shutdown.c:899
> #7  0xffffffff810c0877 in trap_fatal (frame=3D0xfffffe0104239690, eva=3D0)
>                                 at /usr/src/sys/amd64/amd64/trap.c:942
> #8  0xffffffff810c092b in trap_pfault (frame=3D0xfffffe0104239690,
>         usermode=3Dfalse, signo=3D, ucode=3D)
>                                 at /usr/src/sys/amd64/amd64/trap.c:761
> #9  
> #10 tcp_sack_output (tp=3Dtp@entry=3D0xfffffe0187312140,
>         sack_bytes_rexmt=3Dsack_bytes_rexmt@entry=3D0xfffffe010423983c)
>                                 at /usr/src/sys/netinet/tcp_sack.c:970
> #11 0xffffffff80dd47a2 in tcp_default_output (tp=3D0xfffffe0187312140)
> at /usr/src/sys/netinet/tcp_output.c:310
> #12 0xffffffff80dcd240 in tcp_output (tp=3Dtp@entry=3D0xfffffe0187312140)
> at /usr/src/sys/netinet/tcp_var.h:407
> #13 0xffffffff80dcc81a in tcp_do_segment (m=3D0xfffff80203467700,
>                 th=3D0xfffff8001f190022, so=3D0xfffff80015d0fb40,
> tp=3D0xfffffe0187312140,
>                 drop_hdrlen=3D64, tlen=3D, iptos=3D0 '\000=
')
> at /usr/src/sys/netinet/tcp_input.c:2788
> #14 0xffffffff80dc8def in tcp_input_with_port (mp=3D,
>                 offp=3D, proto=3D, port=3Dp=
ort@entry
> =3D0)
> at /usr/src/sys/netinet/tcp_input.c:1397
> #15 0xffffffff80dc9c8b in tcp_input (mp=3D0xfffff8011c764010, offp=3D0x4,
>                 proto=3D-2128851986) at /usr/src/sys/netinet/tcp_input.c:=
1492
> #16 0xffffffff80db8cd7 in ip_input (m=3D0x0)
> at /usr/src/sys/netinet/ip_input.c:840
> #17 0xffffffff80d3842f in netisr_dispatch_src (proto=3D1,
>                 source=3Dsource@entry=3D0, m=3D0xfffff80203467700)
> at /usr/src/sys/net/netisr.c:1153
> #18 0xffffffff80d3878f in netisr_dispatch (proto=3D477511696,
>                 m=3D0xffffffff811c4bee) at /usr/src/sys/net/netisr.c:1244
> #19 0xffffffff80d1a7cc in ether_demux (ifp=3Difp@entry=3D0xfffff800028738=
00,
> m=3D0x4) at /usr/src/sys/net/if_ethersubr.c:925
> #20 0xffffffff80d1be53 in ether_input_internal (ifp=3D0xfffff80002873800,
> m=3D0x4)
> at /usr/src/sys/net/if_ethersubr.c:711
> #21 ether_nh_input (m=3D) at
> /usr/src/sys/net/if_ethersubr.c:741
> #22 0xffffffff80d3842f in netisr_dispatch_src (proto=3Dproto@entry=3D5,
>                 source=3Dsource@entry=3D0, m=3Dm@entry=3D0xfffff802034677=
00)
> at /usr/src/sys/net/netisr.c:1153
> #23 0xffffffff80d3878f in netisr_dispatch (proto=3D477511696, proto@entry=
=3D5,
>                 m=3D0xffffffff811c4bee, m@entry=3D0xfffff80203467700)
> at /usr/src/sys/net/netisr.c:1244
> #24 0xffffffff80d1ac89 in ether_input (ifp=3D0xfffff80002873800,
>                 m=3D0xfffff80203467700) at /usr/src/sys/net/if_ethersubr.=
c:832
> #25 0xffffffff808f41f7 in re_rxeof (sc=3Dsc@entry=3D0xfffffe00e1cce000,
>                 rx_npktsp=3D0x0) at /usr/src/sys/dev/re/if_re.c:2386
> #26 0xffffffff808f1a16 in re_intr_msi (xsc=3D0xfffffe00e1cce000)
> at /usr/src/sys/dev/re/if_re.c:2682
> #27 0xffffffff80ba3d49 in intr_event_execute_handlers
> (ie=3D0xfffff800020fde00,
>                 p=3D) at /usr/src/sys/kern/kern_intr.c:1205
> #28 ithread_execute_handlers (ie=3D0xfffff800020fde00, p=3D)
> at /usr/src/sys/kern/kern_intr.c:1218
> #29 ithread_loop (arg=3Darg@entry=3D0xfffff800020fbf80)
> at /usr/src/sys/kern/kern_intr.c:1306
> #30 0xffffffff80ba03e0 in fork_exit (
>                 callout=3D0xffffffff80ba3ad0 ,
> arg=3D0xfffff800020fbf80,
>                 frame=3D0xfffffe0104239f40) at
> /usr/src/sys/kern/kern_fork.c:1102
> #31 

I had a ... vaguely-similar panic on one laptop, after updating sources
=66rom main-n256013-85d7875d4291 to main-n256025-91d6afe6e2a9.  I placed
a screenshot of the backtrace at
https://www.catwhisker.org/~david/FreeBSD/head/n256025/console.jpg

The files updated were:

Updating 85d7875d4291..91d6afe6e2a9
Fast-forward
 contrib/bsddialog/lib/lib_util.c        |  7 +--
 sys/arm64/arm64/identcpu.c              | 85 +++++++++++++++++++++++++++++=
++++
 sys/arm64/include/armreg.h              | 30 ++++++++++++
 sys/dev/alc/if_alc.c                    |  5 +-
 sys/dev/hwpmc/hwpmc_logging.c           | 21 ++++----
 sys/dev/hwpmc/hwpmc_mod.c               | 17 ++++---
 sys/dev/iommu/iommu_gas.c               | 13 ++++-
 sys/fs/fdescfs/fdesc_vnops.c            | 10 +++-
 sys/kern/subr_smp.c                     |  4 +-
 sys/kern/uipc_usrreq.c                  | 37 ++++++--------
 sys/netinet/tcp_sack.c                  | 12 +++++
 sys/sys/pmc.h                           |  4 ++
 tests/sys/kern/unix_passfd_test.c       | 37 ++++++++++----
 usr.bin/gcore/elfcore.c                 | 29 ++---------
 usr.sbin/bsdinstall/scripts/docsinstall |  3 +-
 15 files changed, 223 insertions(+), 91 deletions(-)

Command exit status: 0

I noted that there was a subsequent commit to sys/netinet/tcp_sack.c
(231e0dd5d1fb7778b1cb285e5ebee5502d5ad253, to avoid a NULL dereference);
while I don't believe I was using SACK, I went ahead and hand-applied
that small change & rebuilt; that did not seem to help (as I got a
similar-looking panic after the rebuild).

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshniko=
va

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--CeSOY/sgAkQ6yCrH
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYqASG18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1BtbAP9z0pXpNoQtkgEvrCjRt+wPq8yfGMkr6nnuTXOZ4D1tcgD/dgaywRX6Ya+a
rMe0+9g7mQA36MRgNSlDDeNJf4z2sw0=
=3yWH
-----END PGP SIGNATURE-----

--CeSOY/sgAkQ6yCrH--

From nobody Wed Jun  8 06:50:28 2022
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 7517A854DE4
	for ; Wed,  8 Jun 2022 06:50:42 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4LHyXx25f0z4S4J
	for ; Wed,  8 Jun 2022 06:50:41 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [176.74.213.87])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 6FF83260282;
	Wed,  8 Jun 2022 08:50:33 +0200 (CEST)
Content-Type: multipart/mixed; boundary="------------xtEXz0V90jqvwGtjf5D7g0w0"
Message-ID: <576eb80a-cfe8-651c-686b-1be2e82ec9c7@selasky.org>
Date: Wed, 8 Jun 2022 08:50:28 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: A kernel crash after compiling a fresh kernel
Content-Language: en-US
To: David Wolfskill ,
 Oleg Lelchuk , freebsd-current@freebsd.org
References: 
 
From: Hans Petter Selasky 
In-Reply-To: 
X-Rspamd-Queue-Id: 4LHyXx25f0z4S4J
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.54 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch];
	 HAS_ATTACHMENT(0.00)[];
	 DMARC_NA(0.00)[selasky.org];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.49)[-0.494];
	 MIME_BASE64_TEXT(0.10)[];
	 NEURAL_HAM_MEDIUM(-0.85)[-0.847];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[catwhisker.org,gmail.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+];
	 R_DKIM_NA(0.00)[];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------xtEXz0V90jqvwGtjf5D7g0w0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Does this patch fix your issue?

--HPS
--------------xtEXz0V90jqvwGtjf5D7g0w0
Content-Type: text/x-patch; charset=UTF-8; name="a.diff"
Content-Disposition: attachment; filename="a.diff"
Content-Transfer-Encoding: base64

Y29tbWl0IGNjN2EyMjRmYTk1NjM3MmNjNWM1YjRkMjlhYTY5MDZkNzliZDlmMjYKQXV0aG9y
OiBIYW5zIFBldHRlciBTZWxhc2t5IDxoc2VsYXNreUBGcmVlQlNELm9yZz4KRGF0ZTogICBX
ZWQgSnVuIDggMDg6NDk6NTUgMjAyMiArMDIwMAoKICAgIHRjcDogU2tpcCBzYWNraG9sZSBL
QVNTRVJUUygpIG9uIE5VTEwKICAgIAogICAgSW5hZHZlcnRlZGx5IGludHJvZHVjZWQgTlVM
TCBwb2ludGVyIGRlcmVmZXJlbmNlIGR1cmluZwogICAgc2Fja2hvbGUgc2FuaXR5IGNoZWNr
IGluIEQzNTM4Ny4KICAgIAogICAgTm8gZnVuY3Rpb25hbCBjaGFuZ2UgaW50ZW5kZWQuCiAg
ICAKICAgIE1GQyBhZnRlcjogICAgICAxIHdlZWsKICAgIERpZmZlcmVudGlhbCBSZXZpc2lv
bjogaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0QzNTQyMwogICAgU3BvbnNvcmVkIGJ5
OiAgIE5WSURJQSBOZXR3b3JraW5nCgpkaWZmIC0tZ2l0IGEvc3lzL25ldGluZXQvdGNwX3Nh
Y2suYyBiL3N5cy9uZXRpbmV0L3RjcF9zYWNrLmMKaW5kZXggMjczZDU2YzUxMGUyLi40ZWNj
MGUwNDUxMTggMTAwNjQ0Ci0tLSBhL3N5cy9uZXRpbmV0L3RjcF9zYWNrLmMKKysrIGIvc3lz
L25ldGluZXQvdGNwX3NhY2suYwpAQCAtOTYzLDkgKzk2MywxMCBAQCB0Y3Bfc2Fja19vdXRw
dXQoc3RydWN0IHRjcGNiICp0cCwgaW50ICpzYWNrX2J5dGVzX3JleG10KQogCXdoaWxlICgo
aG9sZSA9IFRBSUxRX05FWFQoaG9sZSwgc2NibGluaykpICE9IE5VTEwpIHsKIAkJaWYgKFNF
UV9MVChob2xlLT5yeG1pdCwgaG9sZS0+ZW5kKSkgewogCQkJdHAtPnNhY2toaW50Lm5leHRo
b2xlID0gaG9sZTsKLQkJCWJyZWFrOworCQkJZ290byBvdXQ7CiAJCX0KIAl9CisJcmV0dXJu
IChob2xlKTsKIG91dDoKIAlLQVNTRVJUKFNFUV9MVChob2xlLT5zdGFydCwgaG9sZS0+ZW5k
KSwgKCIlczogaG9sZS5zdGFydCA+PSBob2xlLmVuZCIsIF9fZnVuY19fKSk7CiAJS0FTU0VS
VChTRVFfTFQoaG9sZS0+c3RhcnQsIHRwLT5zbmRfZmFjayksICgiJXM6IGhvbGUuc3RhcnQg
Pj0gc25kLmZhY2siLCBfX2Z1bmNfXykpOwo=

--------------xtEXz0V90jqvwGtjf5D7g0w0--

From nobody Wed Jun  8 12:21:19 2022
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 74F1B838356
	for ; Wed,  8 Jun 2022 12:21:22 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LJ5tT3ys9z3hQL
	for ; Wed,  8 Jun 2022 12:21:21 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 258CLJB8045039;
	Wed, 8 Jun 2022 12:21:19 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 258CLJY8045038;
	Wed, 8 Jun 2022 05:21:19 -0700 (PDT)
	(envelope-from david)
Date: Wed, 8 Jun 2022 05:21:19 -0700
From: David Wolfskill 
To: Hans Petter Selasky 
Cc: Oleg Lelchuk , freebsd-current@freebsd.org
Subject: Re: A kernel crash after compiling a fresh kernel
Message-ID: 
Mail-Followup-To: David Wolfskill ,
	Hans Petter Selasky ,
	Oleg Lelchuk , freebsd-current@freebsd.org
References: 
 
 <576eb80a-cfe8-651c-686b-1be2e82ec9c7@selasky.org>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="l1PBoeOoOAhQVGkW"
Content-Disposition: inline
In-Reply-To: <576eb80a-cfe8-651c-686b-1be2e82ec9c7@selasky.org>
X-Rspamd-Queue-Id: 4LJ5tT3ys9z3hQL
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-4.94 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FREEFALL_USER(0.00)[david];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 DMARC_NA(0.00)[catwhisker.org];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-0.54)[-0.535];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 SIGNED_PGP(-2.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	 FREEMAIL_CC(0.00)[gmail.com,freebsd.org];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


--l1PBoeOoOAhQVGkW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 08, 2022 at 08:50:28AM +0200, Hans Petter Selasky wrote:
> Hi,
>=20
> Does this patch fix your issue?
>=20
> --HPS
> ....

(As you noted later, that patch had been committed to head by the time I
got around to checking, as:

commit ce2525c8108a830d08d75771621d1bc580edd82c (HEAD -> main, origin/main,=
 origin/HEAD)
Author: Richard Scheffenegger 
Date:   Wed Jun 8 09:14:16 2022 +0200

    tcp: remove goto and address another NULL deref in SACK
=2E..

)

In any case, after updating sources to main-n256043-ce2525c8108a &
rebuilding, each of the 3 machines passed that smoke test (including
my day-to-day laptop, which was the one that had provided evidence
of a problem earlier).

Thanks! :-)

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
"Putin is a paranoid dictator.  Putin must go. He started a senseless war
and is leading Russia into a ditch." - Egor Polyakov & Alexandra Miroshniko=
va

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--l1PBoeOoOAhQVGkW
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYqCUP18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1P02AQCHmj6ya4Ce3qTGPDrvII/4u8qKsIEu/bvvpsDbkmLuTwD/aXJLui8rGnQL
s6ZuCfi/ipu/n46KxPB0tzG/FGqjOAU=
=roxS
-----END PGP SIGNATURE-----

--l1PBoeOoOAhQVGkW--

From nobody Thu Jun  9 10:25:50 2022
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 0456785BF92
	for ; Thu,  9 Jun 2022 10:26:02 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LJgGx6fB0z4r0l
	for ; Thu,  9 Jun 2022 10:26:01 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1654770361;
	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=FFDaiWRL469d70UHflqvMRdT5TICz7rpPbtHiu0s8vE=;
	b=y1z7t93e0j5GEhTc7jVEyrEMYL/6KNUqRlQb8RU3ixgMdI8jLu2KaN7MhLt8eKgWHNVfNl
	tWokvlLl6eZB4HpqRA6NbsdlT58GdOov133/Wp4lF5BDtUQcdZPEVQG85wRd5a0jb22QxD
	9H8f2gRfIj5g+nkuBMhqUfCmzz6Nd1HNK2z9z/Hd3WGcD82h9FOIagEwyN6jZBnQ6bYhPL
	1a4SSlnnqFBar5Y0apidIYgQJMMJEVKhGmB5wXnbpp5zuwTkNeCiFaOOJPqlnRW5jRRQtn
	dY0ouLWjwGi9eEZZAqduBJ6FiBdIkDFFnQ411zFV7BPBfu2dPrN1hRHVFo4M9Q==
Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id C0651E15D
	for ; Thu,  9 Jun 2022 10:26:01 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-lj1-f175.google.com with SMTP id j20so1997479ljg.8
        for ; Thu, 09 Jun 2022 03:26:01 -0700 (PDT)
X-Gm-Message-State: AOAM533eTIiCe7kTzUL2XAr3twqt8bBpiWd6CerwPd5e3TF5fEWNR99U
	fsQsLf0Jp9pcT0d5djyIfscJH25JyVv+JLlgfBU=
X-Google-Smtp-Source: ABdhPJzI1YKi7bD04KsDDzB3IPVYh484jgcmwdUH9/85Jdtf3e3MDpB3Npmcf9NPk7n6B7/6MFkW8+/TTNQM9O5PFLY=
X-Received: by 2002:a2e:87d2:0:b0:255:6e60:bc7e with SMTP id
 v18-20020a2e87d2000000b002556e60bc7emr22226411ljj.368.1654770360370; Thu, 09
 Jun 2022 03:26:00 -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: Nuno Teixeira 
Date: Thu, 9 Jun 2022 11:25:50 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: dmesg: ACPI Warning: Firmware issue warning spaming
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="00000000000083cb5f05e1013fae"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654770361;
	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=FFDaiWRL469d70UHflqvMRdT5TICz7rpPbtHiu0s8vE=;
	b=POWBmFQSdCLclqENe1RhzlEHMmxqt8aXecT4T3YkCQbzMNwkD5+d8mPXZf3Gvi3e6CK4X2
	arFfxjRSW8BgStaXWNx6GVaFLM9vUlzbQBV7EiZDCPRbfe4H2Tq+9OzFd6lPVFsvNgR0La
	tj+rJUKhv0Sijbgu9pDryAMVUeA0kjSCbgw0py1Zg3JjihDuXxffJICCXEBlSo3P5I970F
	potdPuX0i47MbQEdyAjZUbnELcporYnhiJTwrI+P18/wkLH7vWVrzinhLqYiGQVuHYiQft
	deZ69N4PIvRmQhIpt29Rfzk55HiqqgB8+/9gMNNwSCjpu9XpGuy2MpXiaBID/Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654770361; a=rsa-sha256; cv=none;
	b=p3KfOSnYsRHkbIUxn6N4PuC3ptsXGf1OJcxRPiByEIxkO/va7PtRNXVlVeRR3yqy3IY+9i
	EUcpHGR2su82saZL9TWrd5fxgWypjQQAf9VQq2ZgOuxRVCy7zdmJOWw0UrcOghwb9cxbYX
	SEjSTU9pY3+lwVklyiaBTj+jQ+iEi7wABog/buezHnB1iic9FfBH+jSZ/iJfJuAUB5pfUJ
	lAO7jNA5w4Hy2c49xum2E5eO9YXr/uwweVvG4jEULjmiGk2Mhe6x930Xl4AclJcV5PlXGE
	PKyA55VOtHSBPeOck3Hqv8AQoZUQXzXu3AGGE8LvgM444MjU3/Fx1gzfkazNHw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--00000000000083cb5f05e1013fae
Content-Type: text/plain; charset="UTF-8"

Hello,

I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings:

---
ACPI Warning: Firmware issue: Excessive sleep time (0x0000000000000010 ms >
10 ms) in ACPI Control Method (20220331/exsystem-347)
---

Is there a way to silence it?

Thanks in advance,

Nuno Teixeira

--00000000000083cb5f05e1013fae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

I'm running CURRE=
NT 8d95f500521 and I'm receiving loads of dmesg warnings:
---
ACPI Warning: Firmware issue: Excessive sleep tim=
e (0x0000000000000010 ms > 10 ms) in ACPI Control Method (20220331/exsys=
tem-347)
---

Is there a way to silence i=
t?

Thanks in advance,

Nun=
o Teixeira


--00000000000083cb5f05e1013fae--

From nobody Thu Jun  9 19:30:47 2022
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 B648F839102
	for ; Thu,  9 Jun 2022 19:30:55 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2056.outbound.protection.outlook.com [40.107.115.56])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LJvMf3Crtz3Dv6;
	Thu,  9 Jun 2022 19:30:54 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=XUExd1LUaoxTIynPRTiE5XZbmfeE21nCs4E0/VRXqQgBxz47vRw6amKXgOua2pCalYa1Qmi9OgLqZ655NRq/hbs34rJbeRS66l+LVeWNaRrWw1XQRRihT+/T0jv32OAUNDXB5P5Q450D4R7VZYUN532KPbCANcVuGCj8AXJQ/Jv4V8w0L8Zp9oV+pbNrFbV8BHbPGdtY/U3wlfq289Duk/5wPHvibzuNedIpLG1xVW92bHkoaG16LzMRafVKE1heY8OTIa4rarCR5qib1TZ/kmaat9Fl4NhAEQwkapovGyCX4jQMCnAv9oatZTiNabSlnL2/iw2FU733zXSRwX297Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sk3qYs5NhG4Aw8zoFkWMT8cqoQlHJpfNlnisPHML09U=;
 b=DZosHf6jK+rEtj+QvCDgtqxQucU76TXX4MNe4/0kmE3DZfV3wcs02aUyCtKjEF4spESCSe5ofHFV0AZGB7NoUAeDjcuJ4U1JRRjXG9BGQUqOdCUz9pkIP0wzA4/hML7drgfi0ehE+lWSHGTwjs4EILKi3K6AQIUZ0Buw7V+0ZhGXTn9ZYmJO4aZDKM638Fze7KHz6pG3puaBaQe+0U1ANaoBqwD/NqrIKz+bdYWzIdpEbAudoNUFoICpN8bN5MqtoSUNAaPI49jc+AFtX9j79WU4U90m3G8WyPaOPpCGK1Z0fGhZvoTg8rfEzQsEAPRYnGT4pwWiKRpmTl8dpDAfCQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca;
 dkim=pass header.d=uoguelph.ca; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=sk3qYs5NhG4Aw8zoFkWMT8cqoQlHJpfNlnisPHML09U=;
 b=IZyrEUHsbmOQ0sqtoK3QHDB+ZjwdQUTEGt5Sw0b1FqwA0UhMEU5wFP8amzVRVbBi3g0NV6Zbgi+QmCioWWcBJ7V3ynapWcWCmjl7zsyIDH6MCTAEVOuCOTbAvtp/6SI8XY25hQmV8F4lJ8QpSvhcYaKMxujZoeTkZJD6vjzYzPdmGQtMZtCfrwkqpGIDquQHM2j0nWUJlfah5PcA1PL/YL07NROejKTEZhc6RKrP61NRk3NNby5v5Z1IQcIl5v1ytA5ic9J6MprOsW1Jh9za9eyiitBeaeWd2w5ng8R9mTkMvMGeBAvvS/T8jOv4ha8H9J29/25tF3O/aF1p/5Yn8Q==
Received: from YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:c01:81::14) by YT3PR01MB8881.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:b01:7a::11) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.12; Thu, 9 Jun
 2022 19:30:47 +0000
Received: from YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::b921:251e:4a0b:54fc]) by YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::b921:251e:4a0b:54fc%7]) with mapi id 15.20.5332.013; Thu, 9 Jun 2022
 19:30:47 +0000
From: Rick Macklem 
To: freebsd-current , "imp@FreeBSD.org"
	
Subject: git question: How do I push a cherry-pick of someone else's commit?
Thread-Topic: git question: How do I push a cherry-pick of someone else's
 commit?
Thread-Index: AQHYfDb9qAbdi6yD7UG+3VvmpnWyNA==
Date: Thu, 9 Jun 2022 19:30:47 +0000
Message-ID:
 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
suggested_attachment_session_id: 159dfdf9-137c-5323-6d64-cf3157e01cb4
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d69de792-387f-46b9-42e9-08da4a4e8e15
x-ms-traffictypediagnostic: YT3PR01MB8881:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 JcbsIBo3ofOOmubziTZ79OHkBFCFRIjLIYYQROwSnn+5pr3VzinTrGznKURXmW0EnLzwwsXJVZ/80VF8VY4iii1fxROphN0Z1JS333KULcOgaza5nxz3aG5LLDil2Gkt7OZfKM7HqFBluNcLqnnuq3o9FYJIMCGxPdzYOTqampcs2335gnPt9vXHnCbcw2/LOJarD7lePid+fOsAr/x32PHRK7Qt/CS5/fXHslthmOdYDygaLl92LAr0/yfjbtv/FhwPV+y/Y00/8nwvfjx8ArpprE1WdlNOfgKhZ1c2r+pVsgEjZXoQLnsY5GXyRetbTOGXJ0M3OTCoTp3EfOvJbsKYevP8tGU4hpA8feSL7Ul7QvbOG0C6IHRixUxp4YEJMuhjR8S1sJqYxk+2EBwp7XFx4tsF8h1EmpuhbOSyqteKpRJt2Z1hqTwo2NNvg6F08nODiAS6NulySrhmBLepbnTityRSgoL9Ow03WtbnT6qo669rXn/w91ahzKZYukzfFGwIdA3taZOSlkYNwCFr70jr2Owvdhs13UV+tQxpLi3hVWo3QC2/5iNPPGhEMOLsVJdpZE37pajP7CUP3fz68aVFTsitcOcWHViinOeAbeauO4a7Rf7IfbNEXDAVn4jfiddv8sfHnYQ6SKkmf957AKLv78Qa6mlGVT7+9A4ql0p1mMEg4kj0pZjNXorWYHKO4LOmXVuZF6LbTcvmWWzCwQ==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(450100002)(91956017)(38070700005)(64756008)(8676002)(66476007)(66556008)(66946007)(76116006)(2906002)(508600001)(5660300002)(55016003)(33656002)(122000001)(52536014)(66446008)(8936002)(4744005)(71200400001)(786003)(316002)(38100700002)(186003)(86362001)(9686003)(6506007)(7696005)(110136005);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?idGo4BelLW74Z0kntFY4UL0sHx8Y8T78lQrlDdGcNfhmtoF7jZOZ0gp/Si?=
 =?iso-8859-1?Q?CQCy/nU/TErSODznIqOLEZaOFKj+Tl2Y10COh7oSb5NK7A7+nmJTbXXHqf?=
 =?iso-8859-1?Q?rRJ/PBKk7wM0TUXx/VrhFRoVbhDxOBL5GXaoDqwOpO79AIHTXN6mgvq8y+?=
 =?iso-8859-1?Q?CM1bYr+pDMSip6gMBNb8nInkSs33bO3krQqiC7htlcoVFYxiqLZmSqV2+p?=
 =?iso-8859-1?Q?P4cAsmvCA3hHMAejqxfI+ZqAMurls4rJGkXFRTHEbuYe3Cmb5Mx7Pmv5/m?=
 =?iso-8859-1?Q?Ba7IeYZz+rkNFNRVdQcrxwHpbPbcXogfyzobMs8E1tP1QlTIYPMP1huA42?=
 =?iso-8859-1?Q?Eqk1jYanyu7vKVCGxTktOMvLfYbBZ1/QBi0LzxneO7kRALd9MdjVendovK?=
 =?iso-8859-1?Q?R03T3y6Z+XKKTfYdqmb3DpoFf5HJM/YuQXOwEXwnqR9uhy4Mp59nWU/IYx?=
 =?iso-8859-1?Q?lUa/9FS2Jc5i/E5+nW94EdLp2P5FaXWmV4r3C8FF2HKwCaLzd/3GLjlM8/?=
 =?iso-8859-1?Q?RwQ2YQuFNcIUixdTyj8QwJDlpHGaOlcki+D3qsAxj2+V0uo4Op/41qQsC3?=
 =?iso-8859-1?Q?SpfeRckFOq6zY6g02qW9P0bu/CwWbbU9gDjv2jPWlVAIaiA+OIovrzQJ8P?=
 =?iso-8859-1?Q?Sd5qMYtL54vaPVFh4PowNdv6uYCGqqankP8503aqPruKxbkXvcBo0B12fm?=
 =?iso-8859-1?Q?jBVm1H2mzF/56LQGO1S0oKgkzvAm+edoHg/ryXIV1Iv+5xgzqBM1k/Yjh8?=
 =?iso-8859-1?Q?FhDqR+XWNG3Cwki2Kod4rzZ+4PTW+thpSqWoLODc3Qq2VV75x/t8Zelp/I?=
 =?iso-8859-1?Q?p6eInINDF4cHH38U6wCWIpXX5MXG5J5eIB19nI38T37ngQhL/CUJ0Oh1im?=
 =?iso-8859-1?Q?LqBHsEWgyrZt3gNQkQaATrxCIhh4xgxq05Ktop8/PRBI0oTdVj5j4z7ehd?=
 =?iso-8859-1?Q?gjxpX61JdWxQs1SJozizNXrEJlSWSltAmwOHeB5KR9j3lWVWAWnGNCbaM2?=
 =?iso-8859-1?Q?jRGfHHDcR3Yi74cybw38UeZmYKzzOwIIzBFj3/qwjxrt20XZmSK2DvMn3r?=
 =?iso-8859-1?Q?R/rknt5gHtcODTdWKFtQ4ZvkkLoKl1TRToYZfNMMlzCq7Kdc2LGYJgB9Jl?=
 =?iso-8859-1?Q?Y8R2tquYMGEEbcpzyvvnevDz9GwoWETEPvQqISa+ixQdHVfYLFC/Smp1Lt?=
 =?iso-8859-1?Q?6Of7f5uial7Q0b4lw1SqiDjEKvBTFD9uhJNvnSuItBZkFprFLdfoypjJ6r?=
 =?iso-8859-1?Q?b+T7ZEXKF7JpHHexTquF03bioj2YOKKhfRW3wqHs7gPYxAE9JnoI+zahgp?=
 =?iso-8859-1?Q?K6icEiYiGx9S5b0ZI5wkcUuoeMkdXp/de0/5gdh8MknyWipWn8xNRcD7SI?=
 =?iso-8859-1?Q?f40QGe9lr4BIAD7LpR3PNInanMeSlSaGu+JMzFAe43vwc6e35y09MzRVv9?=
 =?iso-8859-1?Q?vzKtIoJ4rAEUKfmJhfvNNkGerO0VzwlInJ35SOCqDZ1nj59KOpUjy6D9Qz?=
 =?iso-8859-1?Q?bCkszOlPmnljBnC5irncQWOUGavtONN8f3NLkEOdJKnB1uDV7MKRnu9IaX?=
 =?iso-8859-1?Q?t2ESAJjdt8+5/zhKacDxjj5s5tfPUiSRaJWfxftCVeoOyDbectuakZuGAU?=
 =?iso-8859-1?Q?+C+d1tDhmcyeLCErhW3b2Jjtp2pywxkGaL2YMaff3Uulg/t++z71wybdFT?=
 =?iso-8859-1?Q?9M6CgBZ4JqqOP+uJ9BRhyrvt23405Lhca90MttvilKZ+x6y2oYWir7o6sj?=
 =?iso-8859-1?Q?Dvhp+ON+iyl0KvJ53v/N6dwFqbiS7mZPrChOSclU3yMDbqncmZlSCzdE/n?=
 =?iso-8859-1?Q?MgkyKJ76a3W1xYjLu9wP41JVoxtoy9kF5OONcM+Ql2LniOnwbn0L87my1O?=
 =?iso-8859-1?Q?Fd?=
x-ms-exchange-antispam-messagedata-1: Q7a5gtAb98hKeA==
Content-Type: text/plain; charset="iso-8859-1"
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
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: d69de792-387f-46b9-42e9-08da4a4e8e15
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2022 19:30:47.7852
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yI04WIx3LhS16/mBCPHNhqcXzsdkelm/Q1WPlhElm0aAJ9Ugj9h+S9uHV3WsG0xA0HQJ5kkKbJvINR2Uhdgrqg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT3PR01MB8881
X-Rspamd-Queue-Id: 4LJvMf3Crtz3Dv6
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=IZyrEUHs;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=uoguelph.ca;
	spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.115.56 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca
X-Spamd-Result: default: False [-5.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2];
	 FREEFALL_USER(0.00)[rmacklem];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[uoguelph.ca:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.115.56:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.115.56:from]
X-ThisMailContainsUnwantedMimeParts: N

I just tried to MFC a commit done to fix my commit by imp@=0A=
and it won't let be push the cherry-pick.=0A=
=0A=
What's the trick to doing this?=0A=
Or do I need to get Warner to do it?=0A=
If so, it's 393b7606f9c1 in main, that needs to go into stable/13.=0A=
=0A=
rick=0A=
ps: The stable/13 build will be broken until this gets resolved.=0A=
      I'll revert the MFC if it isn't fixed soon.=0A=

From nobody Thu Jun  9 19:36:05 2022
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 9E64E83AAFD
	for ; Thu,  9 Jun 2022 19:36:11 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LJvTk1dDMz3HKd;
	Thu,  9 Jun 2022 19:36:10 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id 756603e0;
	Thu, 9 Jun 2022 19:36:08 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id fc4647c4 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO);
	Thu, 9 Jun 2022 19:36:07 +0000 (UTC)
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 (1.0)
Subject: Re: git question: How do I push a cherry-pick of someone else's commit?
From: Michael Gmelin 
In-Reply-To: 
Date: Thu, 9 Jun 2022 21:36:05 +0200
Cc: freebsd-current , imp@freebsd.org
Message-Id: <1EB3B7BB-4249-4ADE-A643-E5DC2B197D82@freebsd.org>
References: 
To: Rick Macklem 
X-Mailer: iPhone Mail (19E258)
X-Rspamd-Queue-Id: 4LJvTk1dDMz3HKd
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-1.41 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[grembo];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 R_SPF_SOFTFAIL(0.00)[~all];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.84)[-0.836];
	 NEURAL_HAM_MEDIUM(-0.97)[-0.972];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

What is the error message?

Did you try =E2=80=9Cgit push -f=E2=80=9D

> On 9. Jun 2022, at 21:33, Rick Macklem  wrote:
>=20
> =EF=BB=BFI just tried to MFC a commit done to fix my commit by imp@
> and it won't let be push the cherry-pick.
>=20
> What's the trick to doing this?
> Or do I need to get Warner to do it?
> If so, it's 393b7606f9c1 in main, that needs to go into stable/13.
>=20
> rick
> ps: The stable/13 build will be broken until this gets resolved.
>      I'll revert the MFC if it isn't fixed soon.
>=20


From nobody Thu Jun  9 19:44:58 2022
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 15C9A83C96C
	for ; Thu,  9 Jun 2022 19:45:09 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LJvh42DKzz3Kl8;
	Thu,  9 Jun 2022 19:45:08 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-qk1-x732.google.com with SMTP id c144so15985889qkg.11;
        Thu, 09 Jun 2022 12:45:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=Q4Hi4gt+v5o/sMN9iGOUIg8i+cyw8yK3/PBXPP9d3Ec=;
        b=KpLXKkbcv+/NgQTnYXPib7n8gtC7jjUS+PTpOb8lOoMcV7Y4BExvshedN/BOt9RESy
         zM6/dmu94cPa5HmBgxMAwdmINxTUrt/EOYtcBflCCqBvoB0vRyM4iHfLWLknSM1FStyV
         fs5BJ+eF4Za1fFeNO5ZDa7ja70QTVHbXBR59s61HlZJe+eHqTLA/hmIP1sTcSw3pfvvF
         c40U2JhjzXKNa5cbnUKHFvm+RuiTzTCUYHPKaNdNLk6Cq4rfKHfL0YIyfylDyCVnYhVV
         khjC2kYqPrnkoTa02SKOl7gAHmMhQy1cs2x1wcCzNUJeWEqtajWvE9GBC2PMNY+jzgPL
         V83w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition:in-reply-to;
        bh=Q4Hi4gt+v5o/sMN9iGOUIg8i+cyw8yK3/PBXPP9d3Ec=;
        b=f7US5WBLBLYakQvTS6v6ChxqvOAhSwsKDlSRzLALnus+JaUHUpShUbDq7qIlc1BJR8
         udSEPAZj7DMdZ1wrwdVjaU9WdX46f+NoSYPnhWSECCF1JrmSuECzPic+WPdrPP86gA5P
         v/TcCU9Wzop8Euz1nbYcwVcYW6zwmCZDvOcEUCA2UUcyHeTKtfROKPqbw7kR7daspM18
         ZzYuATcF49STFzkHbI8Yq38RE9oy+OWv7f456IzO00QngoflV0Va3Oe0IEnmq36MTToR
         nD3GlmKiIijhd4NdttCab61b4H1DDVLbnD2OxaQxCORFXcqNAj94INNp44MxcQ538tvv
         f84g==
X-Gm-Message-State: AOAM5306wP1s3cgNIlvohg65tw2k8dhBXtWMA5r/2kVfQ3SvKz/yUMtP
	mD6T1V2SSCXCmNWQQYoPl7Y=
X-Google-Smtp-Source: ABdhPJwlKpEko1QY2+itzKnNhWqgR4Hov601hSlavujp/Pufji6ShcQbCftioEpzVCt3GVti9CPhZQ==
X-Received: by 2002:a05:620a:318b:b0:6a6:cb0b:bb3d with SMTP id bi11-20020a05620a318b00b006a6cb0bbb3dmr13425395qkb.480.1654803902141;
        Thu, 09 Jun 2022 12:45:02 -0700 (PDT)
Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58])
        by smtp.gmail.com with ESMTPSA id l2-20020a37bb02000000b006a2e2dde144sm19033167qkf.88.2022.06.09.12.45.01
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 09 Jun 2022 12:45:01 -0700 (PDT)
Date: Thu, 9 Jun 2022 15:44:58 -0400
From: Mark Johnston 
To: Rick Macklem 
Cc: freebsd-current ,
	"imp@FreeBSD.org" 
Subject: Re: git question: How do I push a cherry-pick of someone else's
 commit?
Message-ID: 
References: 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4LJvh42DKzz3Kl8
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=KpLXKkbc;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::732 as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-1.70 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::732:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 MID_RHS_NOT_FQDN(0.50)[];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jun 09, 2022 at 07:30:47PM +0000, Rick Macklem wrote:
> I just tried to MFC a commit done to fix my commit by imp@
> and it won't let be push the cherry-pick.
> 
> What's the trick to doing this?

You need to add --push-option=confirm-author to the git push invocation.

> Or do I need to get Warner to do it?
> If so, it's 393b7606f9c1 in main, that needs to go into stable/13.
> 
> rick
> ps: The stable/13 build will be broken until this gets resolved.
>       I'll revert the MFC if it isn't fixed soon.
> 

From nobody Thu Jun  9 19:49:53 2022
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 E231283E0A4
	for ; Thu,  9 Jun 2022 19:50:02 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on2040.outbound.protection.outlook.com [40.107.66.40])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LJvnj5wm0z3M3y;
	Thu,  9 Jun 2022 19:50:01 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=P/lOxY2Tpaqvt1oRvfCQEIzEGKZ6tg8TObpdQblRX7z4Dknx4yOSV2OWX6mxuohuV1tqs8JgWCvT/yjT2BdhYn+zZzCfy1GydVuoaNK4a5upmNe22jBDk0BGgPP6+6R9thaqBAprrLMxmnstIXRJd45TILyMWjNSTltm3yxyItuqRY8oEUHT4XV6K6JRUnHYdP6G1R49YtSuTcVJwJMHa8vbND3lAyJERwEU7/Wv3aZW5J/KTXhAxoQYKUIqBw9w6OMYQonH6MlaM/MTH3LtP01bFGKNYujztrO+oS3sK8njYE8RPa7Er9jRNmcGSwrG+a9Q8fyXZ7QIkQKFVXqbQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=TljoyToZmf/k31CyApRI0oSTwBe9LF+XLs7FFmcQhu8=;
 b=dQZ3+b/3UaU7IlXzAVShPu7Dwt6fG4kFVUYAj1H/TmtPWLnP56D9GGzIK0YyJbgYHgoM+ABTYKM0t3/wMDVjThDEkk1jk4vqQfGIgi8Mws0Y+H6t2Hu2uqN76FpvuMjGW6cgM7wwjNf4CCT7r5KV9sjtLCgFfzG66cbcco2H9CVPyBR9xKIYjejgyfsdZFiL4bBmUcqp21EBAA/67nx1gMdiGRXdyPYAW1qW6o9q2xNxraJUMTTiWIJTO7n5LT2YErxAotEta7PANZjMdcrqeMLkFYKFBoUXNxGrU9iikkTYo6D0177KDn/V0JXouPpa+zoo/ycoMfIliixW8JTV1A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca;
 dkim=pass header.d=uoguelph.ca; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=TljoyToZmf/k31CyApRI0oSTwBe9LF+XLs7FFmcQhu8=;
 b=pnUVk0GUMhdY1JfYyRRN3KV7o+aUHgQJZkoSffkSpSLyXBp03xfh7NUx8EttHFVhgGBcA8mH6BIzkJVAy20k0dsS90dApyBEGBX21mSippWBLIGIWhBFKboFS+4/ZLMv8beqPnaNv5t+lfp/rvdvwFHMlJFSnMsofeJet05oP9DfmMNEtKIGNdMIWK8B9MqtZKHLsSUFYH5zV9gSqesCyH0XnqUjNLZtG7u+BWScN8soScWUpN9x3oZC6DEg7Rb679ty6e6MONkU+BmHRF9AxfbpX0Mjnfk9u+CBh1bIcswOS/afFm7/JDhZ7Ot13rN11Sr92pYv42ratFaPs/GAWg==
Received: from YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:c01:81::14) by YT3PR01MB9594.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:b01:8a::18) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5293.17; Thu, 9 Jun
 2022 19:49:53 +0000
Received: from YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::b921:251e:4a0b:54fc]) by YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::b921:251e:4a0b:54fc%7]) with mapi id 15.20.5332.013; Thu, 9 Jun 2022
 19:49:53 +0000
From: Rick Macklem 
To: Mark Johnston 
CC: freebsd-current , "imp@FreeBSD.org"
	
Subject: Re: git question: How do I push a cherry-pick of someone else's
 commit?
Thread-Topic: git question: How do I push a cherry-pick of someone else's
 commit?
Thread-Index: AQHYfDb9qAbdi6yD7UG+3VvmpnWyNK1Hel4AgAAAauo=
Date: Thu, 9 Jun 2022 19:49:53 +0000
Message-ID:
 
References:
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
suggested_attachment_session_id: ef748541-4038-4b96-381c-a73968e64730
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7934a434-1c66-485d-ebc8-08da4a51392b
x-ms-traffictypediagnostic: YT3PR01MB9594:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 TLlIVUzj3nUPGYipIU7rPQY6aUxvTG/rErKVN+25jm4yrGSaBNER7QNK+cRC5kARoIvuxLn3VFOQw+ctCfqBSPC+SNa2lZoBq6OXO7PupdYYRJ+Sdtd/i/FfQxVtuGul5xnE05RZDoOzr5G5mVBCdXTKIHnBQ4m6bqnybH9o+14KZlU+MIu426RxEcaGQ7rBWHtBohw4Tiz9HWVQZmHPClJBcgndBrITUPevIF24hQe34sdw5v2F2JO7OOq6ST6dwwG+GkAprd2xBrym6EEgUi4aUOjcxSAGnazfmGE7e1UkaZAKlYXDgBSb7ZANLEMoBxvgsMcwKJLTU5ZwLASX6eGm0BG8qsF5sg2+y0outd+iSZZKXPGsgrYa6dPli0J38cykn/sYXX6QWoCXBl/TaQN742UyJvkAEI3D6wX2eCIi6mF4Cz1Lpy3gaDLM6c0mUk6Tfag3Ls0K7NW9TT5NszEpIgbMMX8QZJ6gL54yZlsHyMqo2YxxoISryspq0Q5Re5fKnXWvB4sfcW8JDEF65yljo4NaZWnqhg07tqrohdwOC3BTzTG7DJzyCDcOTCTWI1mIXjbxlTvOY7yrYS8tOBVJXjM80Ig6OMRYlopsuFRdFIBAFBxsG36mBa065CcfRc7Eejmwt2WA0yQdIrU9SQSY/VBQHnDg6X95T8wi7HaYQBPIRGGJQqMdSTk0ap9Edz2WpONgDntwqLOu5QOJeA==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(38100700002)(316002)(76116006)(122000001)(4326008)(66946007)(7696005)(8676002)(64756008)(450100002)(9686003)(2906002)(91956017)(66446008)(52536014)(86362001)(508600001)(38070700005)(8936002)(5660300002)(786003)(66556008)(6506007)(55016003)(33656002)(66476007)(71200400001)(4744005)(186003)(54906003)(83380400001)(6916009);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?J2pmd9xU4zHzcCuLQ5OD9zegouLBUNCqQ5gqKqS/6tjvoLMQRfmdlbF7Df?=
 =?iso-8859-1?Q?dAGmwAtClb6ydoXQL8dtRvjhyZeOrX+RGrBIv69MWVhRjh44dryvIKLq7c?=
 =?iso-8859-1?Q?M4nDXo9ueydjxAf6y565Awq0ZOljVpYiR90/g3U36bRv3YsMYi+0TgDirr?=
 =?iso-8859-1?Q?DRYlqE4W26NPD/w5sNIKu16YwdWjLJZ3W/htz0U9a7aYPyz7X3MdqmggCa?=
 =?iso-8859-1?Q?zMFsueQktsluCr3YXd+HGhnCyAneNH/Xh4SXWB4z5na39uWGEQEpCim26O?=
 =?iso-8859-1?Q?aYZg+fHqgmcuoBj3x940aixrYVgeOvaHJGr8CLh+6PmLgxKab6VFwfVEhK?=
 =?iso-8859-1?Q?yfszaxPXxOexq0Zb/t2YnjsRyKZMOUY4sx4GHGBtqeW+J2+ZURGK9sj0Nb?=
 =?iso-8859-1?Q?ligH58FXdhtUNIK8AG+pE+FKZGdbkoPpmKiVe1PGDb4Hmu3QDg5ubh7W4o?=
 =?iso-8859-1?Q?XVoHiWT1nP+zkPXmRZOiMkxvzIHjXXYx2PvzvWVyBz1MfsKyM755nRmu32?=
 =?iso-8859-1?Q?tQzQv6EMJ30XZbEjuJS3TIwqBw7WnJ1oGWCgwInx+V6mfn6jWheiKvkAb0?=
 =?iso-8859-1?Q?2sUGdnaXtdsFVu+s5oWaR68PjuP6R2pThjODAyPHEjODcBSzFbG6LC+QpV?=
 =?iso-8859-1?Q?ctwrKpyDz3PrDqBDseN9tTmpga/LeiBAlUXU+JJaaOZgbyKuxsJr+saeVE?=
 =?iso-8859-1?Q?FyWuBZfYSS5NbhO/6cMd80YG0IRJEvp3hYjb/DQ3z86dSAodsfQMO88xCv?=
 =?iso-8859-1?Q?k3LYCbStubAxCIeeUbagRZXAGx6Xq8I2RzNQLW+eQNyuGJQJCXEst9YMW7?=
 =?iso-8859-1?Q?1mrc0uXd7NlEd0++jAZ4vOcu4IrX2reVl40DVBBdunr5YOSSqZ7Sh1rO6W?=
 =?iso-8859-1?Q?dY7I/G0t0+MYJIcTtkiIrfcSFAzkWrhvkYdoDSwWqYMjsEzZuDP3GFbZWR?=
 =?iso-8859-1?Q?nBeE8a0n9WCT5gSP37as9CC0jNCOGnbre3X/bFZym1d6PW2G/jzVyPD8G1?=
 =?iso-8859-1?Q?6qyS9rQZyw03JdIPxQhq+ysn7bdWAVqXdodNkH14TTHtFrguyogphFtSCL?=
 =?iso-8859-1?Q?S/sG3c6IJWvv3wXiwV/jvLb9YQYYLwqcM6m2RoQEYrCj6HcUQNnR6MXkP5?=
 =?iso-8859-1?Q?GSZQPOVuEyvegr5YKKKGwVIiIHpPm/pf6nXl33XAsvda3dVm09JLkS7zn/?=
 =?iso-8859-1?Q?kiQd+B/L48X6I2p91/0Yd8Z3ki0CROhXI7Im/RgPl6m/VgUDcqdMhgrogz?=
 =?iso-8859-1?Q?nWll1PyYLenk2/akEjjiM2A6T6Nm7awe1+opRHsbX0SaCyY67U+iFcecvb?=
 =?iso-8859-1?Q?j0Z52f9lIYvecf0wOVQqOSyWJor65w6GPEqltvi0NCo9r14lizSYvhgOnN?=
 =?iso-8859-1?Q?Mw+i8phrlgQ5fxGIvRXzY3JASbqVZZ1t4I9Eh29rlCZQdaKWXpdOaEHswZ?=
 =?iso-8859-1?Q?oPGM2XsGBUnMWJ7i6YZXxWyYku7RQSZEBFm3Pd8Mo6TuejGM29cVyfLQ6Y?=
 =?iso-8859-1?Q?QfmspxidULFn0+dgcItiRB+wS4q1bSTsgfEuRJ7HaJkw0MIDqzfks5ie5d?=
 =?iso-8859-1?Q?GYMs/bZEBad2k70t+PNKAGPIytCsvbjCajDAu//MENCfbPpeOETUUP3agM?=
 =?iso-8859-1?Q?LqIZzj6uvo27Ifm0wiIPRk69H+HzLDLcByY/wXg3MyFCQsHxaeTKfc2ut6?=
 =?iso-8859-1?Q?ZajqGWP40Zpc/K6ysVfIcL/ICLWf0UeD+ur1sS5A+tjHLVCEEuWeRonB7M?=
 =?iso-8859-1?Q?3YoCJMyhS2iAh5aCrsbeFL4+j0BmyRipkPZ/mqgQ6Yvl1MeFKy9VfN9AjW?=
 =?iso-8859-1?Q?kmJfpGUUJcRjHJ57KsKaUyTZ5Rv4jbjYHyioJnGZF23TivKS5gq4zqq7WT?=
 =?iso-8859-1?Q?dP?=
x-ms-exchange-antispam-messagedata-1: k9hVarLeF6L/8g==
Content-Type: text/plain; charset="iso-8859-1"
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
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 7934a434-1c66-485d-ebc8-08da4a51392b
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2022 19:49:53.7863
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zAmhfwbFrRyGvAV+HzscHoqy5/P4B1MtJya8bN9l0iCm2rOwvq+vHMtUgjhibyDyDzS0/7uvIL846Pjui3QgbA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT3PR01MB9594
X-Rspamd-Queue-Id: 4LJvnj5wm0z3M3y
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=pnUVk0GU;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=uoguelph.ca;
	spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.40 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca
X-Spamd-Result: default: False [-5.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2];
	 FREEFALL_USER(0.00)[rmacklem];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[uoguelph.ca:+];
	 DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.66.40:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.40:from]
X-ThisMailContainsUnwantedMimeParts: N

Mark Johnston  wrote:=0A=
>=0A=
> On Thu, Jun 09, 2022 at 07:30:47PM +0000, Rick Macklem wrote:=0A=
> > I just tried to MFC a commit done to fix my commit by imp@=0A=
> > and it won't let be push the cherry-pick.=0A=
> >=0A=
> > What's the trick to doing this?=0A=
>=0A=
> You need to add --push-option=3Dconfirm-author to the git push invocation=
.=0A=
Ok, thanks.=0A=
=0A=
It did try it as the message suggested:=0A=
git push --push-option=3Dconfirm-author=0A=
and it failed because it couldn't push refs to gitrepo.=0A=
=0A=
However, since you suggested it, I did:=0A=
git push freebsd --push-option=3Dconfirm-author=0A=
and that seemed to work.=0A=
=0A=
Hopefully I haven't screwed anything on the git repo up,=0A=
=0A=
Thanks, rick=0A=
=0A=
> Or do I need to get Warner to do it?=0A=
> If so, it's 393b7606f9c1 in main, that needs to go into stable/13.=0A=
>=0A=
> rick=0A=
> ps: The stable/13 build will be broken until this gets resolved.=0A=
>       I'll revert the MFC if it isn't fixed soon.=0A=
>=0A=
=0A=

From nobody Thu Jun  9 20:06:09 2022
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 C3C72840820
	for ; Thu,  9 Jun 2022 20:06:14 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LJw8P4rRrz3PQ0;
	Thu,  9 Jun 2022 20:06:13 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-qv1-xf29.google.com with SMTP id a9so17295249qvt.6;
        Thu, 09 Jun 2022 13:06:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=H2Us7ePCtT/lcR3VApmu2b8i1DjRX1honvZSIlafIoA=;
        b=UPe1t7y3ByRlQqLz4zohT/upvFqF8PJuNkZGgVtDyC/uZEOALiRLbc7Ud7QYt5YwlM
         HqLAAaaaXURf9I60Fe4+riCT9DSFNGFj5IICsupu4jBKNi6eKenR7xBCqkTQSjKcFM50
         UbBoF8iI1PS19yMVAKG5wThSLBILGqZVkV0nem317d6ULGAqVX6xlhGM42mqjriu1eFD
         UEeK/WXkUJTvxmpzEpKDdYNLOsMMJEfCuYkxKIFaTvHKtM607k85omM6xoDyGkLntwvj
         xzd2H9MFlL29d7jU+vjEa/vyH/nH6zuhTq/yxEBka+S3nyh4uioR5mZ5QsDeDGqKW60V
         vABQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition:in-reply-to;
        bh=H2Us7ePCtT/lcR3VApmu2b8i1DjRX1honvZSIlafIoA=;
        b=LKoJc0888rmnJj1UCAyf3C6PVtzm55JtFf5U575Ejb5mX2essvUCOzMp645MvtJaCs
         oalDRcgsxcUxQz0yvkwUbTyBbJnibp0nkG+HV9tCos0u9KHHsCYkivtvn2Ixp6TtAgj8
         Gr8+yTFfOX0uJp6LIr3nf3bzWr/4hmqD5UWJSomEY9kFQxenYFgRMSD2BjU5ox19A5lb
         cKoYZ9O/fG01FMaZkz0KtprUw5HMEW8BIgQyExwp0rqvoi6LEDR0bPcVXNySe7OB8Ff2
         Q7UpRhn6S6PAg15z7r5siSNDoRxORVNx2I0nVro2JB3ninu3A5rVUcFpmmdius2osnsb
         c+Cw==
X-Gm-Message-State: AOAM532VangLjUgovjBmw+X2ZNHwXqywoPGjeXA4WGYt0ylUk0gOsTPC
	IWps8mbUzLI8aqE2r8r9Gds=
X-Google-Smtp-Source: ABdhPJyuJLaQ1sIcZi5HJeIkwYdUYHP73wzoknZYK6cTF8xcLNjsUOtBK4h00VW/mSIpgq9eP7ZAAQ==
X-Received: by 2002:ad4:584c:0:b0:464:5904:998d with SMTP id de12-20020ad4584c000000b004645904998dmr41869653qvb.33.1654805173031;
        Thu, 09 Jun 2022 13:06:13 -0700 (PDT)
Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58])
        by smtp.gmail.com with ESMTPSA id s3-20020a05620a0bc300b006a66f3d3708sm21829636qki.129.2022.06.09.13.06.11
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 09 Jun 2022 13:06:12 -0700 (PDT)
Date: Thu, 9 Jun 2022 16:06:09 -0400
From: Mark Johnston 
To: Rick Macklem 
Cc: freebsd-current ,
	"imp@FreeBSD.org" 
Subject: Re: git question: How do I push a cherry-pick of someone else's
 commit?
Message-ID: 
References: 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4LJw8P4rRrz3PQ0
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=UPe1t7y3;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f29 as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-1.69 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-0.996];
	 FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f29:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 MID_RHS_NOT_FQDN(0.50)[];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jun 09, 2022 at 07:49:53PM +0000, Rick Macklem wrote:
> Mark Johnston  wrote:
> >
> > On Thu, Jun 09, 2022 at 07:30:47PM +0000, Rick Macklem wrote:
> > > I just tried to MFC a commit done to fix my commit by imp@
> > > and it won't let be push the cherry-pick.
> > >
> > > What's the trick to doing this?
> >
> > You need to add --push-option=confirm-author to the git push invocation.
> Ok, thanks.
> 
> It did try it as the message suggested:
> git push --push-option=confirm-author
> and it failed because it couldn't push refs to gitrepo.
>
> However, since you suggested it, I did:
> git push freebsd --push-option=confirm-author
> and that seemed to work.

I'm not sure why you'd need to specify the remote if your first attempt
to push to gitrepo.freebsd.org failed, given that "freebsd" presumably
points to gitrepo anyway.

> Hopefully I haven't screwed anything on the git repo up,

Looks ok to me. :)

> Thanks, rick
> 
> > Or do I need to get Warner to do it?
> > If so, it's 393b7606f9c1 in main, that needs to go into stable/13.
> >
> > rick
> > ps: The stable/13 build will be broken until this gets resolved.
> >       I'll revert the MFC if it isn't fixed soon.
> >
> 

From nobody Thu Jun  9 20:16:33 2022
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 7EF0C84239E
	for ; Thu,  9 Jun 2022 20:16:42 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2070.outbound.protection.outlook.com [40.107.115.70])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LJwNT4TFXz3QxR;
	Thu,  9 Jun 2022 20:16:41 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=iVyYByXH5NGCUnE2DotGl9t7gsOmy2pkg73kXoTTcb0xr7w4d2XLrW4+t1puk3fTnlSszlTzb+08D8h6G4s1cuHdqiaYAgI5vfN+oArZjEwn79370To2Q4BbGrrgv+TrLbjOfXCrGsh3LhDXPGTDWAqlsM0613Ygx2JVnibQECT5J2klA8E1ERwMwreZmfxPvJHtVvMEMipCLDidOdEIDVHWltWf5gubsGigLwrdeKNytFOY3YFxqLqHTFEpxnrsqqIS0OEFugRVzu5fIsh78Q5omYqqUNNoNO3xR9GF6TV5ojvkZh61yJZ5HTp9TTlu9w3zt/TnR1y253lwNAO+RA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xPu756on9by4B1U/F18+VOEYHhHpmE46+qO22TxzEa4=;
 b=Rwzs67gXpHm3r0/WT1xmvhLTPXrsQ2jdhz6B10jeqmHCZILJeQi8UzfTuL8oRGykopnZVww2SaCQZxxhcpjDlQyTo71hE3PLUlLyj5SuU+lZnYJaJbr/9qK0NOPIOpzkNU6TPVAuum22/B+TOS53P5KjK+3x+sbUb5sOlZBuyXiKkR/Mpav99vDCGjY69kfKMl8NcGCldunNSUsP1vWbcZuFVHJWfWKAGb93EgK43ENbanqo+cCuJVSGvETB0OblW27QZJuCRUFuIDKhc5YLm+7wJfb33X+KH0jGKRVZU9ucqw5UN4Rf8+ZgObx4yrE5fEQi52Upc5z81/eLcNQyMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca;
 dkim=pass header.d=uoguelph.ca; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xPu756on9by4B1U/F18+VOEYHhHpmE46+qO22TxzEa4=;
 b=d3I9LRjb1GhXdEJqcHbcSk+qcPxuYPbTrFyPUEWr7D+etRttDoBb8JmvIg0jG9ToGH3QbqBgYWXxKfSRX6nlB8MoT0JkYx8+HsgSc2jKaWIut3AjuI8Emr3EHFdAe6HPkQBsHjHeyBp6qxF9BgleFI5rTy+vgjDq2UwMvHRZ82aJgOShi7saBKnVPKpvJw37Dw07K68O7B/qBTxqKqKuxTYeKx75FYjdWshamNj8tVSYOFnLKDiGvsyX92sQ2wnWG980JHqv8ZgW77rOwxDLnNiEEiy3mQdxstmDw3Yo0HNar2ds43M6bWGuQH4MviQuh4j+xw2MN4jHqpSs59sGzA==
Received: from YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:c01:81::14) by YT2PR01MB5917.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:b01:4f::6) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.12; Thu, 9 Jun
 2022 20:16:34 +0000
Received: from YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::b921:251e:4a0b:54fc]) by YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::b921:251e:4a0b:54fc%7]) with mapi id 15.20.5332.013; Thu, 9 Jun 2022
 20:16:33 +0000
From: Rick Macklem 
To: Mark Johnston 
CC: freebsd-current , "imp@FreeBSD.org"
	
Subject: Re: git question: How do I push a cherry-pick of someone else's
 commit?
Thread-Topic: git question: How do I push a cherry-pick of someone else's
 commit?
Thread-Index: AQHYfDb9qAbdi6yD7UG+3VvmpnWyNK1Hel4AgAAAauqAAAWBgIAAAf1q
Date: Thu, 9 Jun 2022 20:16:33 +0000
Message-ID:
 
References:
 
 
 
 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
suggested_attachment_session_id: 5f43e108-6512-40e9-31b0-1f645d7dd263
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7765d5b5-f192-4593-7d3a-08da4a54f2e0
x-ms-traffictypediagnostic: YT2PR01MB5917:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 ZosxI7uG6miAzPdfkiDPHNw9h+y8BmFqsIH7dxmCVV1sU5SGQGPfExYrDNGFnvTMxL9B02ubMYIUMOctynt9dsFxPDdzjLAjwcIT1ML3ac8bM6v/47SxS/lsK9qUXEG+Rv8LAHcQDJqvP7vQVTI5ZhE+9BrIMMfMb/JoRdJOaSGO6WdsHy4kxyNXBuBqnTFjQp0XeZYZ+kTOGgx3YLp9NFQx1u80qnCTv1UEyvU++gG45lztX+04p4yg+cXhdltcPrUqiKMoITKv+iJ/NbITNkTRZrPLF62GWj2FlEoL3sET6mbRpmyTmt1zS/MQTTfvyQZyHyv2SN/+ubJiMyv9zTrLKoV3MrqTcmDbJNL62iB7fAOMp9LZWCxOqbzbkm7ot0knO9yRBte25AjNCIuRd9gIC4VSLDh1YxAOdL9o9sA6/65MWyX/Hf20KCn8RZ3K6nz3F9bxPWCE3a9HR7ac7ZrqdLPZYgfuzmfrM/HLbWihS7zgdv/kz4Dxw98dObfDT0f570m3xxLQVqAxHdKlRUJmemQkcIDfjBDuI7VDzKG2MwsHEEjvxjVPO7GIXx5EDaLhUchE0b2ukLQD3J5RyAoAXN2pUPsmYSQuh8xA1rwodudgX33//dCuKG8U1oC3ZYHm1pU0X3eogRisHOie43Kdlow63m8RWGJzKgEi2RQLBrcMhVFr02S73NM/ysflcV1E0O7fk4ndJyvmNzoU5A==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(186003)(83380400001)(38100700002)(8676002)(71200400001)(8936002)(76116006)(55016003)(6916009)(86362001)(4326008)(316002)(54906003)(508600001)(122000001)(786003)(5660300002)(33656002)(52536014)(38070700005)(7696005)(91956017)(2906002)(450100002)(66946007)(64756008)(66446008)(66556008)(66476007)(9686003)(6506007);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?HSf7XLM698xzbo1m0VqhGfdHot0ESrV57Z/ZtotWaiQJ7BI5VVbWR6Ld0R?=
 =?iso-8859-1?Q?Iwbd9Yxwnzh3fAJydpo1UtSOXgRDhkE9xHFcKeKNthLi+lXcHjA569Ztsv?=
 =?iso-8859-1?Q?EzmElsNfHYSaC9aOzV6JFKc5Zl8YzAErQou3ArmWjUUzlXduRO1Ok56oD8?=
 =?iso-8859-1?Q?F8x3TkOPnx77uUrKBKRrA6YFUsBgUI+E4oJYExVY/GAunvtkWPe1SKan3N?=
 =?iso-8859-1?Q?1BhWuZlw3+Ycdwt5lxDHh9/7nz9lt1TxLLa19UO5FTCbhy+IZK850qIeOu?=
 =?iso-8859-1?Q?Q22YzNWoLXKoGGH0DjvxZtNI8onqJzlFUthpxNg3TcLAL6+uDU8ubAqHWW?=
 =?iso-8859-1?Q?DokSfSCkIFJbx+szqOsAxNWssdqn2doNnIgxM0z+XRtf9Nx5C6nRmyeJnP?=
 =?iso-8859-1?Q?3OGW9izENjz7NMqBBqPXEl1a+XVGL5oPGNMtVJdH6lacXNo8OItt+vRicd?=
 =?iso-8859-1?Q?fKObNlZUNfZvYZ2Am08JMChV8t/O0UKrwJ1+FTKL0zUp29dFJcUZF+hc9A?=
 =?iso-8859-1?Q?xRh6rQrwTBASP36Htii/BKwlOT0r+cG0Uy7xVwaaF/HKnHlW429k0eaF7T?=
 =?iso-8859-1?Q?eTzb8dU6hxsRNAo528edHRq8COtlBYII2SrAM2QRdR+XMYVOkzLTMnfH13?=
 =?iso-8859-1?Q?9xfZgZY+td256uu4NVNWT/vvajIf3J4zkxPtc+amhGFExrWH+J75/yLxNZ?=
 =?iso-8859-1?Q?bwDUyl8CLEZiER237iuR0rqNpe3CCReG/YBN80HY74/69W1LOBJF9SC+zc?=
 =?iso-8859-1?Q?Mq8nUOBkTW0cwbetYVoIkPehAj3OmzjDc2CjUTfqqtV8TaKPHJZCInw4QV?=
 =?iso-8859-1?Q?xoKtvHuLv7lKfh7sjWZzKb6hRHKqjSRptBMfc954UuxTh2Lz1SdTdnKBIg?=
 =?iso-8859-1?Q?51bo5rhHvvDCeUdfv9MttYeK6zkrG8+dmn7CNmc4EioqrvcgNwInFOWCh/?=
 =?iso-8859-1?Q?2vg7CsJdKyMEnQe12Rb6v3JNrosH0uXOltffKqtHmQgbGbDO6i5A5aS2ay?=
 =?iso-8859-1?Q?+RvEfbF4BAK9C9dfJHJt1+n3NKeZmuZPxCXY4SjR0AtVMqDnnmPACCRIsi?=
 =?iso-8859-1?Q?NnQBmPKDiL5c9SR7XVQOShi1RFts+F/mwOdgOZCadPIfI1QuFzKG0g0mXA?=
 =?iso-8859-1?Q?8LZruy8fMrNvIUJ2RFa+lDh4bkYciXkfSFYCX7gDIp8kxNlr7ltiBV3g96?=
 =?iso-8859-1?Q?0DmBA9dtl4+2os4xp0US78eQ33wopvL41ibKz/Rn1BX5p67Ae9d8Ao2nJf?=
 =?iso-8859-1?Q?mie1XKPqlGL+FD+VXY1gpfR3coPlk6HyVuU4PKAU7YLJY9XRpgwSIzzrw6?=
 =?iso-8859-1?Q?emnG2yVZjx4NK9hGnn7Ow0s5ioOyne9x/yGsqKBXZRhwANm0WfgE6sgDMI?=
 =?iso-8859-1?Q?cJBVm014UKRkHRlKdtSSSp6+1I9UhaQ9Ht4FhUIDKiIsU/fwB3/ef1llCR?=
 =?iso-8859-1?Q?+xCMpfr26k9dfB3mALsrlXBk9pLmzqKte16G85jh5tJ/9wNvZINRlSVQwa?=
 =?iso-8859-1?Q?hwhC34DHLIo4zUZW9fIhBcw6Dx6XusLK2oQ9BoOkoHV1taSIx53BaPgqZw?=
 =?iso-8859-1?Q?kNGgDrAGzlkVHPf9EEkKW57lsvdakZedF5ak7bfL7/UwKioeT0jnOfPYCJ?=
 =?iso-8859-1?Q?tO6G5eaex32BkWM7mvrLwmqJoFPaYpflRir+7q17f//VhM+N0RSGajy/ES?=
 =?iso-8859-1?Q?u7dSsivNfaBUNK3lV2/up5CjVmPs4I9v+d3meXM39AYHe01Kd1qO/QO5bc?=
 =?iso-8859-1?Q?0J927LV+VAu1vtuUgnIzssA+9+48Z0kdAsbgNaZTiDrZYRLtVW0gF+ZeYT?=
 =?iso-8859-1?Q?aVxIIvU34mRERnsULo1OX4NjZxAgI7lYnNrCL4SuxNWEAxb5HFias6MN8R?=
 =?iso-8859-1?Q?P1?=
x-ms-exchange-antispam-messagedata-1: JIZZP33f9WL17g==
Content-Type: text/plain; charset="iso-8859-1"
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
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 7765d5b5-f192-4593-7d3a-08da4a54f2e0
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2022 20:16:33.8228
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: knxuizo4LT8hR+bH0mPQkP8VRpj6AiP4zTsXNbacZ78IOhIaZ8dFDhtcQEfOBxe5xoPbkWyancv9JIA8H5O3Mg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT2PR01MB5917
X-Rspamd-Queue-Id: 4LJwNT4TFXz3QxR
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=d3I9LRjb;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=uoguelph.ca;
	spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.115.70 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca
X-Spamd-Result: default: False [-5.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2];
	 FREEFALL_USER(0.00)[rmacklem];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[uoguelph.ca:+];
	 DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.115.70:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.115.70:from]
X-ThisMailContainsUnwantedMimeParts: N

Mark Johnston  wrote:=0A=
> On Thu, Jun 09, 2022 at 07:49:53PM +0000, Rick Macklem wrote:=0A=
> > Mark Johnston  wrote:=0A=
> > >=0A=
> > > On Thu, Jun 09, 2022 at 07:30:47PM +0000, Rick Macklem wrote:=0A=
> > > > I just tried to MFC a commit done to fix my commit by imp@=0A=
> > > > and it won't let be push the cherry-pick.=0A=
> > > >=0A=
> > > > What's the trick to doing this?=0A=
> > >=0A=
> > > You need to add --push-option=3Dconfirm-author to the git push invoca=
tion.=0A=
> > Ok, thanks.=0A=
> >=0A=
> > It did try it as the message suggested:=0A=
> > git push --push-option=3Dconfirm-author=0A=
> > and it failed because it couldn't push refs to gitrepo.=0A=
> >=0A=
> > However, since you suggested it, I did:=0A=
> > git push freebsd --push-option=3Dconfirm-author=0A=
> > and that seemed to work.=0A=
>=0A=
> I'm not sure why you'd need to specify the remote if your first attempt=
=0A=
> to push to gitrepo.freebsd.org failed, given that "freebsd" presumably=0A=
> points to gitrepo anyway.=0A=
I looked and, without "freebsd", it uses "https:..." instead of "ssh:...", =
so it=0A=
is pretty obvious why it failed.=0A=
=0A=
Thanks for the help, rick=0A=
=0A=
> Hopefully I haven't screwed anything on the git repo up,=0A=
=0A=
Looks ok to me. :)=0A=
=0A=
> Thanks, rick=0A=
>=0A=
> > Or do I need to get Warner to do it?=0A=
> > If so, it's 393b7606f9c1 in main, that needs to go into stable/13.=0A=
> >=0A=
> > rick=0A=
> > ps: The stable/13 build will be broken until this gets resolved.=0A=
> >       I'll revert the MFC if it isn't fixed soon.=0A=
> >=0A=
>=0A=
=0A=

From nobody Fri Jun 10 02:48:39 2022
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 3B8C48348D8;
	Fri, 10 Jun 2022 02:48:47 +0000 (UTC)
	(envelope-from rozhuk.im@gmail.com)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LK54t1rSmz3k8X;
	Fri, 10 Jun 2022 02:48:46 +0000 (UTC)
	(envelope-from rozhuk.im@gmail.com)
Received: by mail-lf1-x12f.google.com with SMTP id t25so40732453lfg.7;
        Thu, 09 Jun 2022 19:48:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=from:date:to:subject:message-id:mime-version
         :content-transfer-encoding;
        bh=VIGW8Q1Ig0/BJxtpkGQabx3p5IjYUsynPFpEvJKiT/8=;
        b=mJqDLJB+36POwEC+WhR2oh0dm1Vqrk3wNa4zLGTyuMU6cCC2ogQz4RYl2UwNnUl9rG
         jMiAiuPwsvT6LbAiVWMYZxmYF0nP0hBfshRtDHFFDRhuLq/KNMudY0kIiib1c23P/JsT
         PuI4Ybq/faPcp8pcD4Hucdad32vulqgOqRwKni+YCuU+Oq/o0WBc+RZJOyUTlsBsrjTJ
         SjSZPzARUnL59xi7eDdmukvCpw5bMKeTzIN5qQafs2Uyz9V37/jTilgkBziqbuj8NrsT
         +AIojOE+JguiuCUTW5DwflGe55IknX2AwB5Pno5eqSdKZWRdIoJUzUupW22biys3U4+O
         kNBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:from:date:to:subject:message-id:mime-version
         :content-transfer-encoding;
        bh=VIGW8Q1Ig0/BJxtpkGQabx3p5IjYUsynPFpEvJKiT/8=;
        b=BucpiAkmJ/SbOJ95j9x0F4087WYHThcxGlxPIHZW5Qn9YkFd5gCYVDI3KJml2FCVHM
         ViEz4x2pvlF5/Ys0iESj91HmRcjxFu9teSaZs88MrEOcF7dvzz5G75DRB4vy7SSTL6Js
         n8aYWmAeJYRDY8RvB9QYVDryJXpMSe++NKQzhd7ZyU/oiq3/jyFltxnGWSFSI4+8p7+g
         WNYEf2Tl9OhZNm48dgX6uykJhcQJ89kinxjJT7D0OowTIJZW2nkWBkfCwHcZJJucO2Nf
         8YowFsPm9M9XWL/bATNt+0Ot5k9grgN5qdbeNWYdDkgN47vazCrdr92TCGfrif2WU/oy
         OOqg==
X-Gm-Message-State: AOAM530gh9u4bHMGfuPbWdi49jpK0liLgpdn+iJqAmrQZkwcil6Il7Pp
	w6LcmFfG6wtxxtnzvv/q2lGABVWWZic=
X-Google-Smtp-Source: ABdhPJyoRBySw3WU+BW9+2SnRRZlSmdJHPP4KcP6gHvgf/rNNRAUlVweJcu9WZt7+7ZoGbV1y4fFAQ==
X-Received: by 2002:ac2:5e76:0:b0:478:f72e:7531 with SMTP id a22-20020ac25e76000000b00478f72e7531mr32052774lfr.187.1654829322451;
        Thu, 09 Jun 2022 19:48:42 -0700 (PDT)
Received: from rimwks.local ([2001:470:1f15:3d8:9554:7133:29d0:f593])
        by smtp.gmail.com with ESMTPSA id j22-20020a056512109600b0047255d210e7sm4506747lfg.22.2022.06.09.19.48.41
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 09 Jun 2022 19:48:41 -0700 (PDT)
From: Rozhuk Ivan 
X-Google-Original-From: Rozhuk Ivan 
Date: Fri, 10 Jun 2022 05:48:39 +0300
To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, Rozhuk Ivan
 
Subject: exec(btxld) failed (No such file or directory) and obj via nullfs
Message-ID: <20220610025556.2896c5fc@rimwks.local>
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.1)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LK54t1rSmz3k8X
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=mJqDLJB+;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=rozhukim@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FREEMAIL_TO(0.00)[freebsd.org,gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12f:from];
	 MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi!


I found a way to fix error during install: exec(btxld) failed (No such file or directory)
in case obj is nullfs mounted.


Use option: -o nocache
mount_nullfs -o rw -o nocache -o noatime "${MAKEOBJDIRPREFIX_TMP}" "${MAKEOBJDIRPREFIX}"


This helps for me, hope it will be usfull for community.


PS: this works even without https://reviews.freebsd.org/D23411 patch.
I do not dig inside this and have no idea why this option undocumented.
Probably this some kernel/nullfs bug that must be investigated, or just
remove option and make it always enabled.

From nobody Fri Jun 10 03:34:47 2022
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 5C2EB83C0E4;
	Fri, 10 Jun 2022 03:34:51 +0000 (UTC)
	(envelope-from rozhuk.im@gmail.com)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LK66252tpz3s7g;
	Fri, 10 Jun 2022 03:34:50 +0000 (UTC)
	(envelope-from rozhuk.im@gmail.com)
Received: by mail-wm1-x335.google.com with SMTP id z17so8450377wmi.1;
        Thu, 09 Jun 2022 20:34:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=from:date:to:subject:message-id:mime-version;
        bh=maDiKSMR6Ns4OlvXx+ONmTL/nkRWb1DzTq+VV6jPmIM=;
        b=ieTqFmXF7hiZVJ/NycIdvLetvfXfsc52XaTdqer1EAYMw1S6e2w5x1CW5GwYOXEgdO
         Xs3+aKYzmwlAy2WNl80kstBzT62hkpWDb+ep5yVrFc1/ZlFw31VLAEBpsZktNWaD/3nr
         AK9cwI5w5dUaeOmHSU+4/PaIvmwzQa1FiAKWIyEDBJkYuL8Qn2rX1vW+91NxMVNUJrpU
         dq30oIuLO2EDzS1qEF5bVa1LS2w+RISh1w4WyafQHrurF1x36b7PA2+sDT7AjRwZh5DL
         /z2KMb8NQ3tVkqkMF/q3F4NSZWp7GUVFsjU+mTFSmoyJxYCrS4hsWRnPHxQSTYtvP4WI
         kQoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:from:date:to:subject:message-id:mime-version;
        bh=maDiKSMR6Ns4OlvXx+ONmTL/nkRWb1DzTq+VV6jPmIM=;
        b=8CO4rFhnWGTuoNpUbqJR8dfzoa/uUdRHducsfT3w0GqIsx7uMjtHj94vpRlcdtyTYU
         w9GerCFIb3+2Nb6DW6B7PpSxVLG1ziiskdwU3FWq3+qduLCubnnGH9WGZOhEPfBlS6BB
         6pvQnhEBR/jjI0rSSKNU+8Fw4NglUUMT9BjafyuhBwPeGuwj8j4VC9KNsuRSi4QXjKXh
         zT12BDAzf4qx1QDjAQ49lZQGM8ZqHMpOx/uDmePXjfNJ/DFigwzzMmk/vJ488ZKG1qHr
         M+m72SEu1QQEZI6/vtoDc3t9qvgnJf1E9Fu3KDIkN/pofH2d9dyZCqXbK6Hav0wnmkM7
         qtjw==
X-Gm-Message-State: AOAM5324N0kRAt/WQS1r7WaX1fc/1ke8CScZT760aKjsfuvZGSqSaj8s
	/TRzvfxASDj66ypgOCYRp7IFxFiuPA4=
X-Google-Smtp-Source: ABdhPJyU5q0D6+6n8vTO7/HrQyloRGB0H0ZMGMNsH1cW/TOrR1gUFkFhZs4a3Dqr9WqWwQcS3HGDJA==
X-Received: by 2002:a05:600c:3d18:b0:39c:474c:eb with SMTP id bh24-20020a05600c3d1800b0039c474c00ebmr6368824wmb.87.1654832089637;
        Thu, 09 Jun 2022 20:34:49 -0700 (PDT)
Received: from rimwks.local ([2001:470:1f15:3d8:9554:7133:29d0:f593])
        by smtp.gmail.com with ESMTPSA id v187-20020a1cacc4000000b0039749256d74sm1317452wme.2.2022.06.09.20.34.48
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 09 Jun 2022 20:34:49 -0700 (PDT)
From: Rozhuk Ivan 
X-Google-Original-From: Rozhuk Ivan 
Date: Fri, 10 Jun 2022 06:34:47 +0300
To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, Rozhuk Ivan
 
Subject: ccache during system build
Message-ID: <20220610063447.10ff8004@rimwks.local>
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.1)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="MP_/EaWb/ZuBLx5HcyfQ9sZFz/p"
X-Rspamd-Queue-Id: 4LK66252tpz3s7g
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=ieTqFmXF;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::335 as permitted sender) smtp.mailfrom=rozhukim@gmail.com
X-Spamd-Result: default: False [-2.29 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 HAS_ATTACHMENT(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.99)[-0.987];
	 FREEMAIL_TO(0.00)[freebsd.org,gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~,3:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 TAGGED_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 MIME_UNKNOWN(0.10)[application/x-shellscript];
	 RCPT_COUNT_THREE(0.00)[3];
	 TAGGED_RCPT(0.00)[];
	 MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_BAD_ATTACHMENT(1.60)[sh];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::335:from];
	 MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--MP_/EaWb/ZuBLx5HcyfQ9sZFz/p
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi!


Just few tips.


1. bsd.compiler.mk set COMPILERCHECK env var:
============================================================================
# Handle bootstrapped compiler changes properly by hashing their content
# rather than checking mtime.  For external compilers it should be safe
# to use the more optimal mtime check.
# XXX: CCACHE_COMPILERCHECK= string:
.if ${CC:N${CCACHE_BIN}:[1]:M/*} == ""
CCACHE_COMPILERCHECK?=	content
.else
CCACHE_COMPILERCHECK?=	mtime
.endif
============================================================================
this overrides ccache.conf setting and increase build time.
CCACHE_COMPILERCHECK='%compiler% -dumpversion'
makes first build and second system rebuild faster.


2. To allow ccache hit in case with different src and obj location
a) obj must be placed inside src
b) OBJTOP env var must be set to new obj location
without this obj path will contain src path and not hit to ccache.
c) CCACHE_BASEDIR must be set to src
d) CCACHE_NOHASHDIR=yes
e) CCACHE_COMPILERCHECK='%compiler% -dumpversion'
f) MAKEOBJDIRPREFIX=''
g) -o nocache must be used with mount_nullfs to avoid error during install:
exec(btxld) failed (No such file or directory) and obj via nullfs


As example, attached scripts build kernel and world using obj stored inside /tmp,
after build files from temp obj moved to /usr/obj dir.
Using simular technic for build FreeBSD inside other src and obj locations I got
ccache hit and reduce build time.

I got ccache miss only for kernel build in case different KERNCONF, because it is mapped
to obj dir path. Probably overwriting OBJROOT will fix it.



--MP_/EaWb/ZuBLx5HcyfQ9sZFz/p
Content-Type: application/x-shellscript
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=fbsd_build_kernel.sh

IyEvYmluL3NoCiMjIyBSb3podWsgSXZhbiAyMDE5LTIwMjIKIyMjIGZic2RfYnVpbGRfa2VybmVs
CiMjIyAKCgojIEV4aXQgb24gZXJyb3IuCnNldCAtZQoKCiMgSW5pdCBjb25zdGFucy4KOiAke1NS
Q19ESVI9L3Vzci9zcmN9CkFVVE9fVEhSRUFEUz1gZ2V0Y29uZiBOUFJPQ0VTU09SU19PTkxOIHwg
dHIgLWNkICdbOnByaW50Ol0nYApNQUtFT0JKRElSX09SSUc9YG1ha2UgLUMgJHtTUkNfRElSfSAt
ViBNQUtFT0JKRElSYApPQkpESVJfU1JDPSIke1NSQ19ESVJ9L29ial90bXAiCk9CSkRJUl9UTVA9
YG1rdGVtcCAtZCAtcSAvdG1wL29iai5YWFhYWFhYWGAKaWYgWyAkez99IC1uZSAwIF07IHRoZW4K
CWVjaG8gIiR7MH06IENhbid0IGNyZWF0ZSB0ZW1wIGRpciwgZXhpdGluZy4uLiIKCWV4aXQgMQpm
aQpleHBvcnQgQ0NBQ0hFX0JBU0VESVI9IiR7U1JDX0RJUn0iCmV4cG9ydCBDQ0FDSEVfTk9IQVNI
RElSPSd5ZXMnCmV4cG9ydCBDQ0FDSEVfQ09NUElMRVJDSEVDSz0nJWNvbXBpbGVyJSAtZHVtcHZl
cnNpb24nCmV4cG9ydCBNQUtFT0JKRElSUFJFRklYPScnCmV4cG9ydCBPQkpUT1A9IiR7T0JKRElS
X1NSQ30iCmlmIFsgISAtZCAiJHtPQkpESVJfU1JDfSIgXTsgdGhlbgoJcm0gLXJmICIke09CSkRJ
Ul9TUkN9IgoJbWtkaXIgLXAgIiR7T0JKRElSX1NSQ30iCmZpCgoKIyBDbGVhbiBhbGwgcHJldiBk
YXRhLgpmb3IgX19NTlRfUE9JTlQgaW4gYG1vdW50IHwgZ3JlcCAiIG9uICR7T0JKRElSX1NSQ30i
IHwgYXdrICd7cHJpbnQgJDE7fSdgIDsgZG8KCXJtIC1yZiAiJHtfX01OVF9QT0lOVH0iID4vZGV2
L251bGwgMj4mMQoJdW1vdW50IC1mICIke09CSkRJUl9TUkN9IiA+L2Rldi9udWxsIDI+JjEKZG9u
ZQoKCiMgLW8gbm9jYWNoZSB0byBmaXggZXJyb3I6IGV4ZWMoYnR4bGQpIGZhaWxlZCAoTm8gc3Vj
aCBmaWxlIG9yIGRpcmVjdG9yeSkKbW91bnRfbnVsbGZzIC1vIHJ3IC1vIG5vY2FjaGUgLW8gbm9h
dGltZSAtbyBub2V4ZWMgLW8gbm9zdWlkICIke09CSkRJUl9UTVB9IiAiJHtPQkpESVJfU1JDfSIK
CgojIEJ1aWxkLgovdXNyL2Jpbi9uaWNlIC1uIDE1IFwKCS91c3IvYmluL3RpbWUgLWggXAoJbWFr
ZQktaiIke0FVVE9fVEhSRUFEU30iIFwKCQktQyAiJHtTUkNfRElSfSIgXAoJCS1zIFwKCQktREFM
V0FZU19DSEVDS19NQUtFIFwKCQktRE5PX0NMRUFOIFwKCQlidWlsZGtlcm5lbAojIEZvcmNlIHNl
dCBmaWxlcyB0aW1lcy4KZmluZCAiJHtPQkpESVJfVE1QfSIgLXR5cGUgZiAtZXhlYyB0b3VjaCB7
fSArCgoKIyBDb3B5IGJhY2sgdG8gL3Vzci9vYmoKX19TUkNfRElSPSIke09CSkRJUl9UTVB9L3N5
cyIKX19EU1RfRElSPSIke01BS0VPQkpESVJfT1JJR30vc3lzIgplY2hvICJTYXZpbmc6ICR7X19T
UkNfRElSfSAtPiAke19fRFNUX0RJUn0iCnJtIC1yZiAiJHtfX0RTVF9ESVJ9Igpta2RpciAtcCAi
JHtfX0RTVF9ESVJ9IgpjaG1vZCBhK3JYICIke19fRFNUX0RJUn0iCmNobW9kIGErclggIiR7TUFL
RU9CSkRJUl9PUklHfSIKY2htb2QgLVIgYStyWCAiJHtfX1NSQ19ESVJ9IgpjcCAtYWYgIiR7X19T
UkNfRElSfS8iICIke19fRFNUX0RJUn0iCgoKIyBDbGVhbnVwLgp1bW91bnQgIiR7T0JKRElSX1NS
Q30iCnJtIC1yZiAiJHtPQkpESVJfVE1QfSIKc3luYwoKCmV4aXQgMAo=

--MP_/EaWb/ZuBLx5HcyfQ9sZFz/p
Content-Type: application/x-shellscript
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=fbsd_build_world.sh

IyEvYmluL3NoCiMjIyBSb3podWsgSXZhbiAyMDE5LTIwMjIKIyMjIGZic2RfYnVpbGRfd29ybGQK
IyMjIAoKCiMgRXhpdCBvbiBlcnJvci4Kc2V0IC1lCgoKIyBJbml0IGNvbnN0YW5zLgo6ICR7U1JD
X0RJUj0vdXNyL3NyY30KQVVUT19USFJFQURTPWBnZXRjb25mIE5QUk9DRVNTT1JTX09OTE4gfCB0
ciAtY2QgJ1s6cHJpbnQ6XSdgCk1BS0VPQkpESVJfT1JJRz1gbWFrZSAtQyAke1NSQ19ESVJ9IC1W
IE1BS0VPQkpESVJgCk9CSkRJUl9TUkM9IiR7U1JDX0RJUn0vb2JqX3RtcCIKT0JKRElSX1RNUD1g
bWt0ZW1wIC1kIC1xIC90bXAvb2JqLlhYWFhYWFhYYAppZiBbICR7P30gLW5lIDAgXTsgdGhlbgoJ
ZWNobyAiJHswfTogQ2FuJ3QgY3JlYXRlIHRlbXAgZGlyLCBleGl0aW5nLi4uIgoJZXhpdCAxCmZp
CmV4cG9ydCBDQ0FDSEVfQkFTRURJUj0iJHtTUkNfRElSfSIKZXhwb3J0IENDQUNIRV9OT0hBU0hE
SVI9J3llcycKZXhwb3J0IENDQUNIRV9DT01QSUxFUkNIRUNLPSclY29tcGlsZXIlIC1kdW1wdmVy
c2lvbicKZXhwb3J0IE1BS0VPQkpESVJQUkVGSVg9JycKZXhwb3J0IE9CSlRPUD0iJHtPQkpESVJf
U1JDfSIKaWYgWyAhIC1kICIke09CSkRJUl9TUkN9IiBdOyB0aGVuCglybSAtcmYgIiR7T0JKRElS
X1NSQ30iCglta2RpciAtcCAiJHtPQkpESVJfU1JDfSIKZmkKCgojIENsZWFuIGFsbCBwcmV2IGRh
dGEuCmZvciBfX01OVF9QT0lOVCBpbiBgbW91bnQgfCBncmVwICIgb24gJHtPQkpESVJfU1JDfSIg
fCBhd2sgJ3twcmludCAkMTt9J2AgOyBkbwoJcm0gLXJmICIke19fTU5UX1BPSU5UfSIgPi9kZXYv
bnVsbCAyPiYxCgl1bW91bnQgLWYgIiR7T0JKRElSX1NSQ30iID4vZGV2L251bGwgMj4mMQpkb25l
CgoKIyAtbyBub2NhY2hlIHRvIGZpeCBlcnJvcjogZXhlYyhidHhsZCkgZmFpbGVkIChObyBzdWNo
IGZpbGUgb3IgZGlyZWN0b3J5KQptb3VudF9udWxsZnMgLW8gcncgLW8gbm9jYWNoZSAtbyBub2F0
aW1lICIke09CSkRJUl9UTVB9IiAiJHtPQkpESVJfU1JDfSIKCgojIEJ1aWxkLgovdXNyL2Jpbi9u
aWNlIC1uIDE1IFwKCS91c3IvYmluL3RpbWUgLWggXAoJbWFrZQktaiIke0FVVE9fVEhSRUFEU30i
IFwKCQktQyAiJHtTUkNfRElSfSIgXAoJCS1zIFwKCQktREFMV0FZU19DSEVDS19NQUtFIFwKCQkt
RE5PX0NMRUFOIFwKCQlidWlsZHdvcmxkCiMgRm9yY2Ugc2V0IGZpbGVzIHRpbWVzLgpmaW5kICIk
e09CSkRJUl9UTVB9IiAtdHlwZSBmIC1leGVjIHRvdWNoIHt9ICsKCgojIENvcHkgYmFjayB0byAv
dXNyL29iagpfX1NSQ19ESVI9IiR7T0JKRElSX1RNUH0iCl9fRFNUX0RJUj0iJHtNQUtFT0JKRElS
X09SSUd9IgplY2hvICJTYXZpbmc6ICR7X19TUkNfRElSfSAtPiAke19fRFNUX0RJUn0iCm1rZGly
IC1wICIke19fRFNUX0RJUn0iCmNobW9kIGErclggIiR7X19EU1RfRElSfSIKY2htb2QgLVIgYSty
WCAiJHtfX1NSQ19ESVJ9IgpybSAtcmYgIiR7X19TUkNfRElSfS9zeXMiCmZvciBfX0RTVF9TVUJf
RElSIGluIGBmaW5kICIke19fRFNUX0RJUn0vIiAtbWF4ZGVwdGggMSAtbm90IC1uYW1lICcnYDsg
ZG8KCVsgIiR7X19EU1RfU1VCX0RJUn0iID09ICIke19fRFNUX0RJUn0vc3lzIiBdICYmIGNvbnRp
bnVlCglybSAtcmYgIiR7X19EU1RfU1VCX0RJUn0iCmRvbmUKY3AgLWFmICIke19fU1JDX0RJUn0v
IiAiJHtfX0RTVF9ESVJ9IgoKCiMgQ2xlYW51cC4KdW1vdW50ICIke09CSkRJUl9TUkN9IgpybSAt
cmYgIiR7T0JKRElSX1RNUH0iCnN5bmMKCgpleGl0IDAK

--MP_/EaWb/ZuBLx5HcyfQ9sZFz/p--

From nobody Fri Jun 10 13:26:32 2022
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 F1D6D8311DD
	for ; Fri, 10 Jun 2022 13:26:51 +0000 (UTC)
	(envelope-from lists@yamagi.org)
Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [IPv6:2a0c:5a00:149::26])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LKMF65t7Kz3JKC
	for ; Fri, 10 Jun 2022 13:26:50 +0000 (UTC)
	(envelope-from lists@yamagi.org)
Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com)
	by mailtransmit05.runbox.com with esmtps  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.93)
	(envelope-from )
	id 1nzeeu-004hIa-V2
	for freebsd-current@freebsd.org; Fri, 10 Jun 2022 15:26:40 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=yamagi.org;
	 s=selector1; h=Content-Transfer-Encoding:Content-Type:Subject:From:To:
	MIME-Version:Date:Message-ID; bh=SqVm8weMt+UPGBIl/CMws+a5kuGrD06SS4jxw/56myU=
	; b=N6gqYUjkE5gqKHQN/hOj2uUMLeLLrRFh0aZ2bvmZ0EbskkV6z7Z6F3RT3d7qiD9tRtkTB7lYZ
	2SviULWWLHjyXdCiS3Fh27sy2bcZ7BGT81a/XPEKKR9CZRChYSyzEO8cOC2EAU/m3p/kku804m92d
	N2nNBCRo2iDN5Q+gQO4UNAwsQwVt26/7syDyHE+iT6QOQ2CFaiJhtw/k4EvJDG9jsHJL/yroLUEvq
	yUQ9ZTCjiFMF9GIClMZpyJwpHbasot5+AmOhsH7Ffe/NJwM9O0wr/SY+uS/O9B4OEwrUBMy4AWYtW
	/G6ul7GjCAb97RWCNIZgO1CmiEXZQBdcRfKxXA==;
Received: from [10.9.9.72] (helo=submission01.runbox)
	by mailtransmit03.runbox with esmtp (Exim 4.86_2)
	(envelope-from )
	id 1nzeeu-0006Kc-HW
	for freebsd-current@freebsd.org; Fri, 10 Jun 2022 15:26:40 +0200
Received: by submission01.runbox with esmtpsa  [Authenticated ID (1103314)]  (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.90_1)
	id 1nzeen-00083r-DO
	for freebsd-current@freebsd.org; Fri, 10 Jun 2022 15:26:33 +0200
Message-ID: 
Date: Fri, 10 Jun 2022 15:26:32 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Content-Language: en-US
To: freebsd-current@freebsd.org
From: Yamagi 
Subject: Bug 264282 / Unable to boot from GELI encrypted UFS in 13.1 and
 -CURRENT
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LKMF65t7Kz3JKC
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yamagi.org header.s=selector1 header.b=N6gqYUjk;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of lists@yamagi.org designates 2a0c:5a00:149::26 as permitted sender) smtp.mailfrom=lists@yamagi.org
X-Spamd-Result: default: False [-3.20 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yamagi.org:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a0c:5a00:149::26];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 DMARC_NA(0.00)[yamagi.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[yamagi.org:+];
	 NEURAL_HAM_SHORT(-0.60)[-0.596];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:50304, ipnet:2a0c:5a00::/29, country:NO];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[2a0c:5a00:149::26:from]
X-ThisMailContainsUnwantedMimeParts: N

Hi,
can someone have a look at Bug 264282 [0]? Booting from GELI encrypted / 
on UFS has been broken since bc9154a208248 from August 2021. That very
annoying, especially when the system is unable to boot after an upgrade 
from 13.0 to 13.1.

The bug report contains an analysis of the problem, a possible patch and 
a prebuild loader binaries with the patch applied. The later can be used
to recover unbootable systems.

Regards
Yamagi

0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282 Booting

-- 
Homepage: https://www.yamagi.org
Github:   https://github.com/yamagi
GPG:      0xeb1472e71d502515

From nobody Sat Jun 11 18:01:17 2022
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 4D7A4844C80;
	Sat, 11 Jun 2022 18:01:18 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LL5HL1q5Gz4SbS;
	Sat, 11 Jun 2022 18:01:18 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1654970478;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=vS03l+AbRVT1Dq6P76jUioSN7ZcE6alq+/M5Ba4O0Z8=;
	b=DlPbK5uY4Vr2JLjRC/wJiI++Pop3DxmjjMkl2yG5RoCwfI7MaAg8eQEa/FjTXBUFp9ekL+
	3/HGKB0wzsnmQSRV9zyeiowkg/auFn1B1PeFj54MNlwP3F+4WfAwWPqzY1Pusk0kXjlcHR
	GkZJsArJisSA5BGu1BCK12oE6TEDfRcgawCaqzXykKUY25OOMdKEH4nSdoLfRg2RRjflwl
	ZwCtBfczNVt31cYzSAx8zvnIEqla5G5Y/hOuuiqYUyjMiKgluDShmoj3ipcp54tYovl2YM
	ZJjlrKAq+SJ8734Bh9mZQruAq7X/Y0QCO6PYzuhh+C1hOXR3egQMtdmFSk0sng==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id 05AC74C5E; Sat, 11 Jun 2022 18:01:17 +0000 (UTC)
Date: Sat, 11 Jun 2022 18:01:17 +0000
From: Lorenzo Salvadore 
To: freebsd-hackers@freebsd.org
Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org
Subject: FreeBSD Quarterly Status Report First Quarter 2022
Message-ID: 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1654970478;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=vS03l+AbRVT1Dq6P76jUioSN7ZcE6alq+/M5Ba4O0Z8=;
	b=HCRDGtoRlETa/lXhXCvny1/ke2zySoZY6rbWoV/wNE8+FSvvi7Hr6Glk7svV5FgMhfZIVA
	Tees65l2EgP/kDULsfXD4V44Dcpf+4quj3GlZqRuNYyu+Da8eSlKl+RANgaUJzsM9iDrrK
	gnB++SNZHMvBbMtcGBllPBOJt4oWVtLXQCY+D0ae0ySOWJrGCdTTEKPCwlfLBs8zXrYg21
	GjpFhsAeRjynUVHbTbOct3DyKomfa053tcivPGCZz6gp5oO42iS1XKLSMIu2nl4rH/jsVi
	00VCD5dkzegZk8PpWBnuW2ja7k/JZJ9XOmgLoY/HTKhbu6DIFJvF0335VQ4ySA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654970478; a=rsa-sha256; cv=none;
	b=hUbNFnVWW2iWXfNQXFaf9izIFs+cGOEZka1AJfCz22551+jftTH0spZwGBGaJHIw4llpgH
	G3BMCEXm5RwNOoiEgVO9+B46vqXQEugErLU7BjtQP/6gmxMqFTHpDeWZpYQirbNMBnTlWU
	MR0f773CR/w04uYiEbT2Te/HzuGgQ7qn7nwzbDYI7ntC0KUHFg7Fla7QtySMUrGbLvBvoW
	KDr0b698XH8XmEZPuwlwduLU9p45m6odLROv7rb0HYuOwluVpSY10Bsyi5ujqMUvs65tSH
	SGloN0rAgBuKOK0tgn1/biZ+pDetyDmwJZLQBb7v/OUEM4bnbJ0nqipkWLBvkw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

FreeBSD Quarterly Status Report First Quarter 2022

As things are yet again settling into a new normal, it’s once again time for a
status report for the FreeBSD Project.

You may have noticed that this report is also a little on the late side, and
it’s with regret that it’s taken this long to get to it - however, thanks to a
few kind souls who’ve stepped up to the plate, in addition to the folks on the
team who do things quietly in the background, future reports should hopefully
be more on time.

So let’s get some introductions in order, as yours truly is delighted to accept
a hand from Pau Amma who already has been helping with reviews for a while,
Lorenzo Salvadore who is stepping up to get some tooling in place to make it
less of a chore to make the reports, as well as Sergio Carlavilla who is
stepping up to help with all the work that can’t be easily automated.

This report covers a very diverse set of topics including but not limited to
accessibility, system boot speed-up, an implementation of GEOM union, changes
to the WiFi situation, and many other things.

We hope you’ll enjoy reading it!

Daniel Ebdrup Jensen, on behalf of the status report team.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

A rendered version of this report is available here:
https://www.freebsd.org/status/report-2022-01-2022-03/

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Table of Contents

  • FreeBSD Team Reports
      â–¡ FreeBSD Foundation
      â–¡ FreeBSD Release Engineering Team
      â–¡ Cluster Administration Team
      â–¡ Continuous Integration
      â–¡ Ports Collection
  • Projects
      â–¡ FreeBSD Accessibility
      â–¡ Boot Performance Improvements
  • Kernel
      â–¡ ENA FreeBSD Driver Update
      â–¡ A New GEOM Facility, gunion
      â–¡ Realtek Wireless driver support
      â–¡ Intel Wireless driver support and LinuxKPI 802.11 compatibility layer
      â–¡ Kernel Crypto changes to support WireGuard
  • Documentation
      â–¡ Documentation Engineering Team
  • Ports
      â–¡ KDE on FreeBSD
      â–¡ Elsewhere
      â–¡ FreeBSD Office Team
      â–¡ lang/gcc* ports need some love and attention
      â–¡ PortConfig
      â–¡ Wifibox: Use Linux to drive your wireless card on FreeBSD
  • Third Party Projects
      â–¡ helloSystem
      â–¡ Containers and FreeBSD: Pot, Potluck and Potman
      â–¡ Fpart and fpsync

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the
Administration Page.

FreeBSD Foundation

Links:
FreeBSD Foundation URL: https://www.FreeBSDFoundation.org
Technology Roadmap URL: https://FreeBSDFoundation.org/blog/technology-roadmap/
Donate URL: https://www.FreeBSDFoundation.org/donate/
Foundation Partnership Program URL: https://www.FreeBSDFoundation.org/
FreeBSD-foundation-partnership-program
FreeBSD Journal URL: https://www.FreeBSDFoundation.org/journal/
Foundation News and Events URL: https://www.FreeBSDFoundation.org/
news-and-events/

Contact: Deb Goodkin 

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to
supporting and promoting the FreeBSD Project and community worldwide. Donations
from individuals and corporations are used to fund and manage software
development projects, conferences, and developer summits. We also provide
travel grants to FreeBSD contributors, purchase and support hardware to improve
and maintain FreeBSD infrastructure, and provide resources to improve security,
quality assurance, and release engineering efforts. We publish marketing
material to promote, educate, and advocate for the FreeBSD Project, facilitate
collaboration between commercial vendors and FreeBSD developers, and finally,
represent the FreeBSD Project in executing contracts, license agreements, and
other legal arrangements that require a recognized legal entity.

Here are some highlights from the Foundation for the first quarter of 2022.

Fundraising Efforts

As promised, we updated our fundraising meter for 2022. So far, we’ve raised
over $84,000 towards our 2022 goal of $1,400,000. We’d like to thank our
individual and corporate donors for supporting our efforts this year. We’d also
like to give a big shout out to our Gold Sponsor, Facebook, Silver Sponsors,
VMware and Tarsnap, and the companies that provide free hosting for the
Project: Bytemark, 365 Data Centers, NYI, NextArray, Sentex Data
Communications, and the Computer Science Department at NCTU.

You can find out how we spent your donations by reading about what we supported
in Q1, in this report, and our Spring Newsletter.

If you haven’t made a donation this year, please consider making a donation now
at https://freebsdfoundation.org/donate/.

We also have a Partnership Program for larger commercial donors. You can find
out more at https://freebsdfoundation.org/our-donors/
freebsd-foundation-partnership-program/

OS Improvements

During the first quarter of 2022, 372 src, 41 ports, and 16 doc tree commits
were made that identified The FreeBSD Foundation as a sponsor. # This
represents 16, 0.4, and 5% of the total number of commits in each repository.

You can read about Foundation-sponsored projects in individual quarterly report
entries:

  • Crypto changes for WireGuard

  • Intel Wireless driver support

Here is a small sample of other base system improvements from Foundation
developers this quarter that do not have separate report entries.

riscv: Add support for enabling SV48 mode

SV48 is intended for systems for which a 39-bit virtual address space is
insufficient. This change increases the size of the user map from 256GB to
128TB. The kernel map is left unchanged for now.

For now SV48 mode is left disabled by default, but can be enabled with a
tunable. Note that extant hardware does not implement SV48, but QEMU does.

  • In pmap_bootstrap(), allocate a L0 page and attempt to enable SV48 mode. If
    the write to SATP doesn’t take, the kernel continues to run in SV39 mode.

  • Define VM_MAX_USER_ADDRESS to refer to the SV48 limit. In SV39 mode, the
    region [VM_MAX_USER_ADDRESS_SV39, VM_MAX_USER_ADDRESS_SV48] is not
    mappable.

Add v3 support to CTF tools

CTF, the Compact C Type Format, is a representation of type information most
often contained within ELF binaries. This type information is helpful for
probing tools like DTrace. Recent work by Mark Johnston allows different Dtrace
providers like the FBT (Function Boundary Tracing) provider to work with
version 3 of CTF.

FreeBSD on the Framework Laptop

Two Foundation staff members, Ed Maste and Mark Johnston, as well as a few
developers and community members now each have access to Framework laptops,
which are designed to make hardware upgrades, repairs, and customizations
straightforward for the average user. The goal of this work is to ensure that
the experience running FreeBSD on the laptops matches the stability that
FreeBSD users expect.

Recent improvements and fixes include:

  • Making audio switch appropriately between speakers and the headphone jack
    when headphones are plugged in or unplugged

  • Fixing bug 259230, which would cause a Framework laptop to reboot or power
    off when the touchpad was used.

  • Adding the Tempo Semiconductor 92HD95B HDA codec ID

  • Temporarily fixing stalled usb enumeration, bluetooth, and S3 resume. The
    temporary fix is to avoid attaching to several newer Intel controllers,
    which require firmware to be loaded, which is different from that
    implemented by ng_ubt_intel and iwmbtfw, so they are not usable yet.

  • Avoiding a 16 second boot delay, by probing the TSC frequency earlier. This
    lets us use the TSC to implement early DELAY, limiting the use of the
    sometimes-unreliable 8254 PIT.

You can follow news about FreeBSD work on the Framework laptop at: https://
wiki.freebsd.org/Laptops/Framework_Laptop.

Continuous Integration and Quality Assurance

The Foundation provides a full-time staff member and funds projects to improve
continuous integration, automated testing, and overall quality assurance
efforts for the FreeBSD project.

Supporting FreeBSD Infrastructure

The Foundation provides hardware and support for the Project. At the time of
writing, the server that will become the new Australian mirror has arrived in
Australia, has a fresh FreeBSD install and will shortly join the cluster.

FreeBSD Advocacy and Education

Much of our effort is dedicated to Project advocacy. This may involve
highlighting interesting FreeBSD work, producing literature, attending events,
or giving presentations. The goal of the literature we produce is to teach
people FreeBSD basics and help make their path to adoption or contribution
easier. Other than attending and presenting at events, we encourage and help
community members run their own FreeBSD events, give presentations, or staff
FreeBSD tables.

The FreeBSD Foundation sponsors many conferences, events, and summits around
the globe. These events can be BSD-related, open source, or technology events
geared towards underrepresented groups. We support the FreeBSD-focused events
to help provide a venue for sharing knowledge, working together on projects,
and facilitating collaboration between developers and commercial users. This
all helps provide a healthy ecosystem. We support the non-FreeBSD events to
promote and raise awareness of FreeBSD, to increase the use of FreeBSD in
different applications, and to recruit more contributors to the Project. We are
continuing to attend virtual events and began planning the June 2022 Developer
Summit.

Check out some of the advocacy and education work we did last quarter:

  • Committed to hosting a FreeBSD Workshop at SCALE 19x and serve as a Media
    Sponsor - July 28-31, 2022 in Los Angeles, CA

  • Participated in the FLOSS Weekly Podcast - January 5, 2022 https://twit.tv/
    shows/floss-weekly/episodes/662

  • Sent out the 2021 Impact Report showcasing how we supported the Project
    last year. https://freebsdfoundation.org/blog/
    2021-freebsd-foundation-impact-report/

  • Hosted a stand at FOSDEM 2022 - Videos from the stand can be found at:
    https://youtube.com/playlist?list=PLugwS7L7NMXxwqIRg1PlhgzhNRi1eVdRQ

  • Participated in the Open Source Voices Podcast - Episode to be aired in
    late April [note from status report team: the episode has indeed be aired
    and is now available at https://www.opensourcevoices.org/29; unfortunately,
    there is and will be no transcript.]

  • Began planning the June 2022 FreeBSD Developers Summit taking place
    virtually, June 16-17, 2022 https://wiki.freebsd.org/DevSummit/202206

  • Held a new FreeBSD Friday - How to Track FreeBSD Using Git Pt. 2 https://
    youtu.be/Fe-dJrDMK_0

  • Presented at the St. Louis Unix User Group on March 9, 2022 https://ow.ly/
    1QXn50Ivj75

  • Served as Admins and were accepted as a mentoring organization for the 2022
    Google Summer of Code

  • Held an Office Hours session on Google Summer of Code. https://youtu.be/
    x-4U1xurmBE

  • Hosted a booth at the virtual Open Source 101 conference on March 29, 2022

  • New blog posts:

      â–¡ RAID-Z Expansion Feature for ZFS In the Home Stretch

      □ What’s Ahead for FreeBSD and the Foundation in 2022

      â–¡ Work with FreeBSD in Google Summer of Code

  • New How-To Guide: An Introduction to FreeBSD Jails

  • New FreeBSD Journal Article: Contributing to FreeBSD ports with Git

We help educate the world about FreeBSD by publishing the professionally
produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is
now a free publication. Find out more and access the latest issues at https://
www.FreeBSDfoundation.org/journal/

You can find out more about events we attended and upcoming events at https://
www.FreeBSDfoundation.org/news-and-events/.

Legal/FreeBSD IP

The Foundation owns the FreeBSD trademarks, and it is our responsibility to
protect them. We also provide legal support for the core team to investigate
questions that arise.

Go to https://www.FreeBSDFoundation.org to find more about how we support
FreeBSD and how we can help you!

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

FreeBSD Release Engineering Team

Links:
FreeBSD 13.1-RELEASE schedule URL: https://www.freebsd.org/releases/13.1R/
schedule/
FreeBSD 13.1 Release Information URL: https://www.freebsd.org/releases/13.1R/
[link added by status report team as this quarterly status report is being
published after 13.1-RELEASE has been released]
FreeBSD releases URL: https://download.freebsd.org/ftp/releases/ISO-IMAGES/
FreeBSD development snapshots URL: https://download.freebsd.org/ftp/snapshots/
ISO-IMAGES/

Contact: FreeBSD Release Engineering Team, 

The FreeBSD Release Engineering Team is responsible for setting and publishing
release schedules for official project releases of FreeBSD, announcing code
freezes and maintaining the respective branches, among other things.

During the first quarter of 2022, the Release Engineering Team completed work
on, and submitted to the developers the 13.1-RELEASE schedule. This will be the
second point release from the stable/13 branch. As of this writing, three BETA
builds have been run, with at least two RC builds before the final release,
currently scheduled for April 21, 2022.

We look forward to another consistently stable release at the end of this
cycle, as well as many more to come for other branches moving forward.

Additionally throughout the quarter, several development snapshots builds were
released for the main, stable/13, and stable/12 branches.

Sponsor: Rubicon Communications, LLC ("Netgate") Sponsor: The FreeBSD
Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Cluster Administration Team

Links:
Cluster Administration Team members URL: https://www.freebsd.org/administration
/#t-clusteradm

Contact: Cluster Administration Team 

FreeBSD Cluster Administration Team members are responsible for managing the
machines the Project relies on to synchronise its distributed work and
communications. In this quarter, the team has worked on the following:

  • Improved web service performance and security

      â–¡ Moved some critical services to newer machines

      â–¡ Swept all services to ensure the support of TLS v1.2 and v1.3 and
        disable v1 and v1.1

      â–¡ Enabled dual-stack certificates for the primary FreeBSD web services.
        ECDSA and RSA certificates, preferring ECDSA, discussed with secteam@,
        benefit the project in favor of security and performance matter.

  • Infrastructure improvements at primary site

      â–¡ Evicted some very old hardware

      â–¡ Moved cluster internal services to newer hardware

          ☆ Build host

          ☆ Parts of LDAP, kerberos, DNS and NTP

  • Installed an additional aarch64 package builder

      â–¡ ampere3.nyi.freebsd.org

      â–¡ Identical specs to ampere[12].nyi.freebsd.org

  • Moved ftp0.nyi.freebsd.org to an aarch64 machine.

  • Main distributed mirror site, download.freebsd.org, enhancements

      â–¡ Updated offline documentation (PDF and HTML) in the mirrors.
        The old directory /doc is now on ftp-archive; it contains files prior
        to the Hugo/Asciidoctor migration.

      â–¡ Moved ports INDEX files to distributed mirror, download.freebsd.org

      â–¡ Removed /ftp from the canonical URLs of files on download.freebsd.org.
        Old URLs are still valid.

  • Cleanup of Handbook/Mirrors section
    Much stale information; now there is more info about the official mirrors
    and locations. Former official mirrors are now named 'Community mirrors'.

  • Ongoing day to day cluster administration

      â–¡ Cluster refresh

      â–¡ Replacing failed disks

      â–¡ Babysitting pkgsync

Work in progress:

  • Improve the package building infrastructure

  • Review the service jails and service administrators operation

  • Set up powerpc pkgbuilder/ref/universal machines

  • Search for more providers that can fit the requirements for a generic
    mirrored layout or a tiny mirror

  • Work with doceng@ to improve https://www.freebsd.org and https://
    docs.freebsd.org

  • Improve the web service architecture

  • Improve the cluster backup plan

  • Improve the log analysis system

  • Set up Australia mirror

  • Hardware refresh

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Continuous Integration

Links:
FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org
FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org
FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins
Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI
3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI
Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg
FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci
dev-ci Mailing List URL: https://lists.freebsd.org/subscription/dev-ci

Contact: Jenkins Admin 
Contact: Li-Wen Hsu 
Contact: freebsd-testing Mailing List
Contact: IRC #freebsd-ci channel on EFNet

The FreeBSD CI team maintains the continuous integration system of the FreeBSD
project. The CI system checks the committed changes can be successfully built,
then performs various tests and analysis over the newly built results. The
artifacts from those builds are archived in the artifact server for further
testing and debugging needs. The CI team members examine the failing builds and
unstable tests and work with the experts in that area to fix the code or adjust
test infrastructure.

During the first quarter of 2022, we continued working with the contributors
and developers in the project to fulfil their testing needs and also keep
collaborating with external projects and companies to improve their products
and FreeBSD.

Important changes:

  • DTrace tests are running with KASAN now.

  • Fixed and resumed the powerpc64le test jobs.

Retired jobs:

  • The jobs of main branch on mips* were removed.

Work in progress and open tasks:

  • Designing and implementing pre-commit CI building and testing (to support
    the workflow working group)

  • Designing and implementing use of CI cluster to build release artifacts as
    release engineering does

  • Collecting and sorting CI tasks and ideas here

  • Testing and merging pull requests in the FreeBSD-ci repo

  • Reducing the procedures of CI/test environment setting up for contributors
    and developers

  • Setting up the CI stage environment and putting the experimental jobs on it

  • Setting up public network access for the VM guest running tests

  • Implementing using bare metal hardware to run test suites

  • Adding drm ports building tests against -CURRENT

  • Planning to run ztest tests

  • Adding more external toolchain related jobs

  • Improving maturity of the hardware lab and adding more hardware under test

  • Helping more software get FreeBSD support in its CI pipeline (Wiki pages:
    3rdPartySoftwareCI, HostedCI)

  • Working with hosted CI providers to have better FreeBSD support

Please see freebsd-testing@ related tickets for more WIP information, and don’t
hesitate to join the effort!

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Ports Collection

Links:
About FreeBSD Ports URL:https://www.FreeBSD.org/ports/
Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#
ports-contributing
FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/
Ports Management Team URL: https://www.freebsd.org/portmgr/
Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/

Contact: René Ladan 
Contact: FreeBSD Ports Management Team 

The Ports Management Team is responsible for overseeing the overall direction
of the Ports Tree, building packages, and personnel matters. Below is what
happened in the last quarter.

Before we start with the usual statistics, portmgr is happy to announce it has
successfully restarted its lurker program. The first two lurkers are pizzamig@
and se@; they will learn about the inner workings of portmgr and bring in new
ideas.

Portmgr also started having bi-weekly meetings, some public results are: *
restarting the lurker program * fixes to ports going backwards in version *
dropping DragonFlyBSD version checks in bsd.port.mk * dropping deprecation
notes from ports transitively using Python 2.7

Currently we have over 46,800 ports in the Ports Tree. There are currently
2,700 open ports PRs of which 680 are unassigned. The last quarter saw 9,403
commits to the main branch by 157 committers and 683 commits to the 2022Q1
branch by 63 committers. Compared to last quarter, this means a slight drop in
activity to the main branch and a slight increase in the number of open PRs.

No new committers joined during the last quarter, portmgr took koobs@' commit
bit in for safekeeping because of a lack of recent commits.

The cluster administration team has provided portmgr with a third aarch64
builder; it is being used for package builds.

Things that happened in git: * Two new USES were introduced: elfctl to change
an ELF binary’s feature control note minizip to get the correct library
dependency on minizip * Two keywords got removed: fcfontsdir (now handled by
USES=fonts) glib-schemas, it has been replaced by a trigger * Default versions
that changed: Lazarus switched to 2.2.0 PHP switched to 8.0 * Some upgrades to
major ports: Chromium 100.0.4896.60 Electron 13.6.9 Firefox 99.0 Firefox ESR
91.8.0 Gnome 41 KDE Frameworks 5.92.0 ** KDE Plasma 5.24.4

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Projects

Projects that span multiple categories, from the kernel and userspace to the
Ports Collection or external projects.

FreeBSD Accessibility

Links:
Accessibility wiki page URL: https://wiki.freebsd.org/Accessibility
List introduction, goals, audience, and ground rules URL: link:https://
lists.freebsd.org/archives/freebsd-accessibility/2021-October/000000.html

Contact: Pau Amma 
Contact: FreeBSD accessibility discussions 

Over the past several months, I’ve started putting together tools and resources
to help make the FreeBSD ecosystem (more) accessible to people with
disabilities:

  • a mailing list

  • a set of wiki pages including resources and a categorized wish list

  • tooling including a searchable accessibility Bugzilla keyword and an
    accessibility Phabricator group

I need all the help I can get with:

  • specifying, designing, implementing, and testing the items on the wishlist

  • adding to the wishlist in areas were have little or no experience or for
    things I missed

  • moving beyond software and documentation to processes and culture

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Boot Performance Improvements

Links:
Wiki page URL: https://wiki.freebsd.org/BootTime
OS boot time comparison URL: https://www.daemonology.net/blog/
2021-08-12-EC2-boot-time-benchmarking.html

Contact: Colin Percival 

Colin Percival is coordinating an effort to speed up the FreeBSD boot process.
For benchmarking purposes, he is primarily using an EC2 c5.xlarge instance as a
reference platform and is measuring the time between when the virtual machine
enters the EC2 "running" state and when it is possible to SSH into the
instance.

This work started in 2017, and as of the end of December 2021 the FreeBSD boot
time was reduced from approximately 30 seconds to approximately 10 seconds.
During 2022Q1, further improvements have shaved more time off the boot process,
taking it down to roughly 8 seconds

Two major issues remain outstanding:

 1. The first time an EC2 instance boots, dhclient takes about 2 seconds longer
    than normal to get an IPv4 address. The cause of this is unknown and
    requires investigation.

 2. IPv6 configuration includes two one-second-long sleep(1) invocations, one
    from /etc/rc.d/netif and the other from /etc/rc.d/rtsold. It might be
    possible to simply remove these; but care is needed to avoid progressing
    too far in the boot process before IPv6 addresses are configured. Input
    from IPv6 experts is required here.

Issues are listed on the wiki page as they are identified; the wiki page also
has instructions for performing profiling. Users are encouraged to profile the
boot process on their own systems, in case they experience delays which don’t
show up on the system Colin is using for testing.

This work is supported by Colin’s FreeBSD/EC2 Patreon.

Sponsor: https://www.patreon.com/cperciva

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Kernel

Updates to kernel subsystems/features, driver support, filesystems, and more.

ENA FreeBSD Driver Update

Links:
ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/
ena/README

Contact: Michal Krawczyk 
Contact: Dawid Gorecki 
Contact: Marcin Wojtas 

ENA (Elastic Network Adapter) is the smart NIC available in the virtualized
environment of Amazon Web Services (AWS). The ENA driver supports multiple
transmit and receive queues and can handle up to 100 Gb/s of network traffic,
depending on the instance type on which it is used.

Completed since the last update:

  • Add IPv6 layer 4 checksum offload support to the driver

  • Add NUMA awareness to the driver when the RSS kernel option is enabled

  • Rework validation of the Tx request ID

  • Change lifetime of the driver’s timer service

  • Avoid reset triggering when the device is unresponsive

Work in progress:

  • Prototype the driver port to the iflib framework

  • Tests of the incoming ENA driver release (v2.5.0)

Sponsor: Amazon.com Inc

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

A New GEOM Facility, gunion

Contact: Marshall Kirk McKusick 

The gunion facility is used to track changes to a read-only disk on a writable
disk. Logically, a writable disk is placed over a read-only disk. Write
requests are intercepted and stored on the writable disk. Read requests are
first checked to see if they have been written on the top (writable disk) and
if found are returned. If they have not been written on the top disk, then they
are read from the lower disk.

The gunion facility can be especially useful if you have a large disk with a
corrupted filesystem that you are unsure of how to repair. You can use gunion
to place another disk over the corrupted disk and then attempt to repair the
filesystem. If the repair fails, you can revert all the changes in the upper
disk and be back to the unchanged state of the lower disk thus allowing you to
try another approach to repairing it. If the repair is successful you can
commit all the writes recorded on the top disk to the lower disk.

Another use of the gunion facility is to try out upgrades to your system. Place
the upper disk over the disk holding your filesystem that is to be upgraded and
then run the upgrade on it. If it works, commit it; if it fails, revert the
upgrade.

The gunion(8) utility is used to create and manage an instance of a gunion.
Further details and usage examples can be found in the gunion(8) manual page.
At this time, gunion(8) is available only in 14.0.

Sponsor: Netflix

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Realtek Wireless driver support

Links:
rtw88 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw88
rtw89 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw89

Contact: Bjoern A. Zeeb 

While the Intel Wireless driver update project is the main driver behind the
work to bring support for newer chipsets and eventually newer IEEE 802.11
standards support, there is also an ongoing effort to support more drivers. The
next two drivers in the (already longer) queue are Realtek’s rtw88 and rtw89.

While the initial driver porting efforts for rtw88 and rtw89 happened on
personal time, the LinuxKPI integration has to be done more and more along the
Intel wireless driver work and so thanks are also due to The FreeBSD
Foundation.

The rtw88 driver has started to work on some machines with less than 4GB of
main memory and was committed to the FreeBSD git repository for broader
testing. While our version of the driver is aware of these limitations, the
problem is currently assumed to be outside the driver in the interactions with
LinuxKPI and busdma.

The rtw89 driver has happily started to send packets and has problems receiving
frames at this point. Further investigation will happen as soon as rtw88 is
sorted out and it is expected that rtw89 will then also timely follow into
FreeBSD’s git repository.

The currently known requirements to compile both drivers have mostly gone into
stable/13 and releng/13.1 already.

For the latest state of the development, please check the referenced wiki pages
and follow the freebsd-wireless mailing list.

Sponsor: The FreeBSD Foundation (partly)

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Intel Wireless driver support and LinuxKPI 802.11 compatibility layer

Links:
iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Iwlwifi

Contact: Bjoern A. Zeeb 

The Intel Wireless driver update project aims to bring support for newer
chipsets along with mac80211 LinuxKPI compat code. The dual-licensed Intel
driver code was ported in the past for the iwm(4) native driver; using the
LinuxKPI compat framework allows us to use the driver directly and gives
support to all the latest chipsets, with only minor local modifications. Some
of the changes made while porting the driver to FreeBSD were kindly
incorporated into the upstream Linux driver already.

During the first quarter work continued with about 70 commits. Updating the
driver and firmware reduced differences to the Linux version and gave us
bugfixes and improvements. Changes to the LinuxKPI 802.11 compatibility layer
were made to avoid firmware crashes and possible panics for users along with
other improvements.

Auto-loading support for LinuxKPI PCI drivers was comitted. This means that
iwlwifi(4) will now load automatically during boot if a supported card is
detected without any user interactions. Considering the current state of the
driver and the next release a decision was made that iwm(4) supported chipsets
will continue to attach to iwm(4) for now and only newer and otherwise
unsupported chipsets will use the iwlwifi(4) driver. This is likely going to
change in CURRENT as soon as iwlwifi(4) provides better support than iwm(4).

The code was merged to the stable/13 branch and the current state will be
shipped with the upcoming 13.1-RELEASE.

In addition to The FreeBSD Foundation thanks need to go to all users who have
been testing and reporting back or are patiently waiting for the next update.
For the latest state of the development, please follow the freebsd-wireless
mailing list.

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Kernel Crypto changes to support WireGuard

Contact: John Baldwin 

During the last quarter, I continued my work to improve the FreeBSD WireGuard
driver. On the FreeBSD side, I added support for the XChaCha20-Poly1305 AEAD
cipher. I also added a dedicated API to support [X]ChaCha20-Poly1035 on small,
flat buffers. Finally, I added an API wrapper for the curve25519 implementation
from libsodium.

For the WireGuard driver, I wrote a series of patches which updates the driver
to use crypto APIs such as those mentioned above in place of internal cipher
implementations. The series also includes a fix to avoid scheduling excessive
crypto tasks as well as a few other small fixes. This series is pending review.

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Documentation

Noteworthy changes in the documentation tree, man-pages, or new external books/
documents.

Documentation Engineering Team

Link: FreeBSD Documentation Project
Link: FreeBSD Documentation Project Primer for New Contributors
Link: Documentation Engineering Team

Contact: FreeBSD Doceng Team 

The doceng@ team is a body to handle some of the meta-project issues associated
with the FreeBSD Documentation Project; for more information, see FreeBSD
Doceng Team Charter.

No new documentation commit bit was granted during the last quarter, and only
one commit bit was safe kept.

Several tasks were completed related to the doc tree during the last quarter:

  • Fix some issues in the translation workflow with PO files and Weblate
    related to the po4a program.

    More info here.

  • Update offline documentation (PDF and HTML).

    The old directory /doc is now on ftp-archive; it contains files prior to
    the Hugo/Asciidoctor migration.

  • Remove Google Analytics from documentation and website.

  • Add last modified information to the documentation and website pages.

  • Tag FreeBSD docset for 13.1-RELEASE.

  • Add the first Indonesian translation to the doc tree.

FreeBSD Translations on Weblate

Link: Translate FreeBSD on Weblate
Link: FreeBSD Weblate Instance

The translation workflow with Weblate is more mature at this point. Several
issues were fixed between PO files and po4a program.

We welcome everyone to try our Weblate instance to translate a few documents.

The first Indonesian translation was added to the FreeBSD project. We thank
Azrael JD for the contribution, and we are looking forward to seeing more
Indonesian translations.

Q1 2022 Status

  • 12 languages (1 new language)

  • 142 registered users

Languages

  • Chinese (Simplified) (zh-cn)

  • Chinese (Traditional) (zh-tw)

  • Dutch (nl)

  • French (fr)

  • German (de)

  • Indonesian (id) - Added

  • Italian (it)

  • Norwegian (nb-no)

  • Persian (fa-ir)

  • Portuguese (pt-br)

  • Spanish (es)

  • Turkish (tr)

We want to thank everyone that contributed, translating or reviewing documents.

And please, help promote this effort on your local user group, we always need
more volunteers.

FreeBSD Website Revamp - WebApps working group

Contact: Sergio Carlavilla 

Working group in charge of creating the new FreeBSD Documentation Portal and
redesigning the FreeBSD main website and its components. FreeBSD developers can
follow and join the working group on the FreeBSD Slack channel #wg-www21. The
work will be divided into four phases:

 1. Redesign of the Documentation Portal

    Create a new design, responsive and with global search. (Complete)

 2. Redesign of the Manual Pages on web

    Scripts to generate the HTML pages using mandoc. (Work in progress)

 3. Redesign of the Ports page on web

    Ports scripts to create an applications portal. (Work in progress)

 4. Redesign of the FreeBSD main website

    New design, responsive and dark theme. (Not started)

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Ports

Changes affecting the Ports Collection, whether sweeping changes that touch
most of the tree, or individual ports themselves.

KDE on FreeBSD

Links:
KDE FreeBSD URL: https://freebsd.kde.org/
KDE Community FreeBSD URL: https://community.kde.org/FreeBSD

Contact: Adriaan de Groot 

The KDE on FreeBSD project packages the software from the KDE Community, along
with dependencies and related software, for the FreeBSD ports tree. The
software includes a full desktop environment called KDE Plasma (for both X11
and Wayland) and hundreds of applications that can be used on any FreeBSD
machine.

The KDE team (kde@) is part of desktop@ and x11@ as well, building the software
stack to make FreeBSD beautiful and usable as a daily-driver graphics-based
desktop machine.

KDE Qt Patch Collection The Qt Company did not release Qt 5.15 updates under
Open Source licenses in 2021, leaving the Open Source 5.15 version lagging
behind the proprietary release. Qt 6 is released under an Open Source license,
but for the world of Open Source software that requires Qt 5, there is still a
need for updates. The KDE Community fills that need by maintaining a curated
set of patches — generally backported from Qt6 — to maintain the Open Source
version of Qt 5. FreeBSD ports now use this KDE Qt Patch Collection, rather
than the outdated last Qt 5.15.2 release from the Qt Company. This landed both
in main and the last quarterly branch for 2021, since it brings important
bugfixes.

KDE Stack

  • KDE Plasma Desktop (all the /plasma5- ports) was updated to 5.23.5 at the
    start of the year. Since this happened very shortly after quarterly was
    branched, this was MFH’ed. The long-term-support release 5.24 landed
    mid-february. The FreeBSD ports do not stick to LTS releases, and will
    follow the regular release schedule. 5.24.3 landed on schedule in March.

  • KDE Gear (the collection of KDE libraries and applicatious outside of the
    Frameworks and Plasma Desktop groups) was updated to 21.12.1 and MFH’ed.
    Monthy releases landed as well: 21.12.2 in February.

  • KDE Frameworks have a monthly release cadence, so 5.90 landed in January,
    5.91 in February and 5.92 in March.

  • KDE PIM currently does not support Contacts stored in a Google account
    because Google has changed the available REST API.

  • astro/kstars received its regularly scheduled updates.

  • deskutils/kalendar was updated. It has now reached the 1.0 stage.

  • deskutils/kodaskanna was added to the ports tree. It is a simple QR-code
    scanner for the desktop.

  • deskutils/latte-dock is an alternative launcher for use in KDE Plasma
    Desktop and other environments. It was updated to 0.10.7 as part of its
    monthly releases.

  • devel/okteta, an editor and viewer for binary data, was updated to 0.26.7,
    a regular bugfix release.

  • graphics/digikam, the digital photography manager, was updated to 7.6.0.
    (Thanks Dima Panov)

  • graphics/kf5-kimageformats has a new option enabling libheif and HEIC
    support.

  • graphics/kontrast was added to the 'accessibility' category. This is a tool
    for checking color-combinations (e.g. for a website) for sufficient
    contrast and readability.

  • graphics/krita was updated to the next big release, Krita 5. (Thanks Max
    Brazhnikov)

  • lang/kross-interpreters was fixed for Ruby 3. (Thanks Yasuhiro Kimura)

  • sysutils/plasma5-discover was updated to resolve some denial-of-service
    bugs in KDE infrastructure.

  • www/falkon was updated. After a two-year wait, a new release of the KDE web
    browser built on Qt WebEngine (itself a wrapper around Chromium internals)
    arrived upstream and in ports.

  • x11/plasma5-plasma-workspace now can properly edit login and account
    information.

Related Applications

  • devel/qtcreator was updated to version 6. A new versioning model has been
    introduced by upstream, so this will now jump by major release number
    regularly. (Thanks to Florian Walpen)

  • irc/quassel was updated. Quassel is a distributed IRC client (think of it
    as your own personal IRC bouncer).

  • misc/tellico was updated. Tellico is a "collection manager", for instance
    collections of books, music, stamps, or FreeBSD releases.

  • net-im/nheko was updated. This is one of a dozen Matrix clients available
    in the ports tree.

Elsewhere

  • archivers/7-zip is the preferred tool for dealing with 7zip files; this
    affacts KDE applications that work with archives (like archivers/ark). We
    would like to thank makc@ for stewarding that update.

  • devel/libphonenumber has bi-weekly updates to chase the exciting world of
    telephony details.

  • graphics/poppler was updated to version 22.01. This version requires C17,
    which pushes a number of consumers to the newer C standard as well. Most
    consumers were fixed in advance.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

FreeBSD Office Team

Links:
The FreeBSD Office project URL: https://wiki.freebsd.org/Office
The FreeBSD Office mailing list URL: https://lists.freebsd.org/subscription/
freebsd-office

Contact: FreeBSD Office team ML 
Contact: Dima Panov 
Contact: Li-Wen Hsu 

The FreeBSD Office team works on a number of office-related software suites and
tools such as OpenOffice and LibreOffice.

Work during this quarter was focused on providing the latest stable release of
LibreOffice suite and companion apps to all FreeBSD users.

During the 2022Q1 period we pushed maintenance patches for the LibreOffice 7.2
port to the quarterly branch and brought the latest, 7.3, releases and all
companion libraries such as MDDS, libIxion and more to the ports tree.

Also we are still working on the Boost WIP repository to bring the latest Boost
library to the ports.

We are looking for people to help with the open tasks:

  • The open bugs list contains all filed issues which need some attention

  • Upstream local patches in ports

Patches, comments and objections are always welcome in the mailing list and
Bugzilla.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

lang/gcc* ports need some love and attention

Links:
GCC Project URL: https://gcc.gnu.org
GCC 11 release series URL: https://gcc.gnu.org/gcc-11/

Contact: toolchain@FreeBSD.org
Contact: Gerald Pfeifer 

After about two decades of maintaining FreeBSD’s lang/gcc* ports, the time came
to hand over the baton and mostly step back. Alas the baton essentially dropped
to the floor, despite multiple calls for help.

Here are a few specific tasks looking for help:

  • Upgrade GCC_DEFAULT in Mk/bsd.default-versions.mk from 10 to 11, including
    fixing the (luckily minor) fall out of an -exp run: https://
    bugs.freebsd.org/bugzilla/show_bug.cgi?id=258378

  • Three changes to work through with upstream GCC (requires src expertise,
    not ports):

      â–¡ upstreaming lang/gcc11/patch-gets-no-more

      â–¡ upstreaming lang/gcc11/patch-arm-unwind-cxx-support

      â–¡ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256874

  • We have removed the unmaintained lang/gcc9-devel and lang/gcc10-devel
    ports, alas kept lang/gcc11-devel and lang/gcc12-devel which would be good
    to see if not weekly, then somewhat regular updates.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

PortConfig

Links:
Repository portconfig URL: https://gitlab.com/alfix/portconfig/

Contact: Alfonso Sabato Siciliano (upstream) 
Contact: Baptiste Daroussin (port) 

FreeBSD provides the Ports Collection to give users and administrators a simple
way to install applications. It is possible to configure a port before the
building and installation. PortConfig is an utility for setting the port
options via a Text User Interface.

As each terminal has different properties PortConfig can be customized via
environment variables to set up the User Interface, for example: menu size,
theme, borders, and so on; each feature is documented inside the manual.
Further, if a port has a specific 'pkg-help' file, PortConfig will show a Help
button to open a "popup" with help information.

FreeBSD provides thousands of ports therefore it is not feasible to test
PortConfig for each use; please report any problem.

Alfonso would like to thank Baptiste Daroussin for the port, suggestions, help,
and testing for this utility and its library.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Wifibox: Use Linux to drive your wireless card on FreeBSD

Links:
Project GitHub Page
net/wifibox port

Contact: PÃLI Gábor János 

Wifibox is an experimental project for exploring the ways of deploying a
virtualized Linux guest to drive wireless networking cards on the FreeBSD host
system. There have been guides on the Internet to suggest the use of such
techniques to improve the wireless networking experience, of which Wifibox aims
to implement as a single easy-to-use software package.

  • bhyve(8) is utilized to run the embedded Linux system. This helps to
    achieve low resource footprint. It requires an x64 CPU with I/O MMU
    (AMD-Vi, Intel VT-d), ~150 MB physical memory, and some disk space
    available for the guest virtual disk image, which can be even ~30 MB only
    in certain cases. It works with FreeBSD 12 and later, some cards may
    require a recent 13-STABLE though.

  • The guest is constructed using Alpine Linux, a security-oriented,
    lightweight distribution based on musl libc and BusyBox.

  • Configuration files are shared with the host system. The guest uses
    wpa_supplicant(8) so it is possible to import the host’s
    wpa_supplicant.conf(8) file without any changes.

  • When configured, wpa_supplicant(8) control sockets could be exposed by the
    guest, which enables use of related utilities directly from the host, such
    as wpa_cli(8) or wpa_gui(8) from the net/wpa_supplicant_gui port/package.

  • Everything is shipped in a single package that can be easily installed and
    removed. This comes with an rc(8) system service that automatically
    launches the guest on boot and stops it on shutdown.

  • A workaround is supplied for laptops to support suspend/resume.

Wifibox has been mainly tested with Intel chipsets so far, and it has shown
great performance and stability. Therefore it might serve as an interim
solution until the Intel Wireless support becomes mature enough. It was
confirmed that Wifibox works with Atheros chipsets too, and feedback is more
than welcome about others. Support for Broadcom chipsets is not yet complete,
that is currently a work in progress.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Third Party Projects

Many projects build upon FreeBSD or incorporate components of FreeBSD into
their project. As these projects may be of interest to the broader FreeBSD
community, we sometimes include brief updates submitted by these projects in
our quarterly report. The FreeBSD project makes no representation as to the
accuracy or veracity of any claims in these submissions.

helloSystem

Links:
Documentation URL: https://hellosystem.github.io/

Contact: Simon Peter 
Contact: #helloSystem on irc.libera.chat, mirrored to #helloSystem:matrix.org
on Matrix

What is helloSystem?

helloSystem is FreeBSD preconfigured as a desktop operating system with a focus
on simplicity, elegance, and usability. Its design follows the “Less, but
better†philosophy.

Q1 2022 Status

  • Version 0.8.0 of helloSystem is under development and test

      â–¡ helloSystem 0.8.0 will be based on FreeBSD 13.1-RELEASE

      â–¡ Experimental Live ISOs using FreeBSD 13.1-BETA3 are available

      â–¡ Initial support for running Linux AppImage files using an optional
        Debian runtime

      â–¡ Initial support for the AppImage format in the user interface

      â–¡ Improved reliability and performance of mounted archives by using
        fuse-archive

      â–¡ Various bugfixes

Installable experimental Live ISO images are available at https://github.com/
helloSystem/ISO/releases/tag/experimental-13.1.

Contributing

The project appreciates contributions in various areas.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Containers and FreeBSD: Pot, Potluck and Potman

Links:
Pot organization on github URL: https://github.com/bsdpot

Contact: Luca Pizzamiglio (Pot) 
Contact: Stephan Lichtenauer (Potluck) 
Contact: Michael Gmelin (Potman) 

Pot is a jail management tool that also supports orchestration through Nomad.

As a result of production testing in a real-world cluster deployment, pot and
related projects received stability improvements for controlling the pot
lifecycle (i.e., pot prepare/start/stop).
Various attributes and commands have been developed to improve support of nomad
orchestration and batch jobs (e.g., change dns config during clone, ability to
disable tmpfs, new last-run-stats command). A new pot release will follow soon.

Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: a
repository of pot flavours and complete container images for usage with pot and
in many cases nomad.

Many of the core images like Nomad, Consul and Vault that can be used to build
a private cloud and orchestration platform, but also e.g. Prometheus or
PostgreSQL Patroni, have reached a stable status over the last quarter and are
in production use now.

To make navigating the evolving pot ecosystem easier, most project resources
have been centralized in a dedicated github project: https://github.com/bsdpot

There, we plan to release ansible playbooks that allow easily creating a
FreeBSD based orchestration environment from scratch based on all these tools.

As always, feedback and patches are welcome.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Fpart and fpsync

Links:
Project site and documentation URL: https://www.fpart.org
Development URL: https://github.com/martymac/fpart
Port URL: https://www.freshports.org/sysutils/fpart

Contact: Ganael Laplanche 

What is fpart ?

Fpart is a filesystem partitioner. It helps you sort file trees and pack them
into bags ("partitions").

It uses FreeBSD’s fts(3) implementation (GNU/Linux builds can also use it as an
option), which makes it crawl filesystems very fast.

A hook facility is provided to trigger actions on the partitions produced.

What is fpsync ?

Fpsync is a companion script that uses fpart under the hood to parallelize
rsync(1) or cpio(1) jobs, making it a simple but powerful data migration tool.
Those jobs can be run either locally or remotely (using SSH). Fpsync is often
used by researchers and cloud providers where lots of data need to be moved and
clusters are available to speed up transfers.

Q1 2022 Status

Both tools continued to evolve and saw several bugs fixed; see the changelog.

Also, a user reported a major bug regarding our fts(3) implementation, which
ignores readdir(3) errors. I have reported the bug in our Bugzilla:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262038

It should be merged soon (hopefully).

Last but not least, fpart has been referenced in the French Government’s 'SILL'
.

Contributing

If you are interested in contributing, have a look at the TODO list.

Any contribution is welcome, more especially in the field of unit testing.

From nobody Sat Jun 11 19:04:24 2022
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 04D508596FA;
	Sat, 11 Jun 2022 19:04:35 +0000 (UTC)
	(envelope-from dsl@mcusim.org)
Received: from mcusim.org (mcusim.org [176.58.93.53])
	(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 4LL6hK2hY6z4gnJ;
	Sat, 11 Jun 2022 19:04:33 +0000 (UTC)
	(envelope-from dsl@mcusim.org)
Received: from peasant.tower.home (unknown [83.28.234.61])
	(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 mcusim.org (Postfix) with ESMTPSA id BA00E6B4F2;
	Sat, 11 Jun 2022 21:04:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mcusim.org;
	s=default; t=1654974266;
	bh=9nTEZf0OK1gz6kCpWor8hPqHE38da1stJli1E1v2JEQ=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To;
	b=bjJF1e47cJNir01yrW3ecxlcrBoGq3YM+ELT2TsT759lfqaTQkS0Hb5Me2ke9OU8e
	 D9q4bJap4MT2jnA1tquI09kA5JHMImNpEXsOHpiVtrIL9Xt7Y4Hz4kTLROx/VI8Lp6
	 +4DNX58bsX7el/j0Mt/EGlsjrnMIANDjU+CdzJ5s=
Date: Sat, 11 Jun 2022 21:04:24 +0200
From: Dmitry Salychev 
To: Lorenzo Salvadore 
Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org,
	freebsd-stable@freebsd.org
Subject: Re: FreeBSD Quarterly Status Report First Quarter 2022
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=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Rspamd-Queue-Id: 4LL6hK2hY6z4gnJ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=mcusim.org header.s=default header.b=bjJF1e47;
	dmarc=pass (policy=reject) header.from=mcusim.org;
	spf=pass (mx1.freebsd.org: domain of dsl@mcusim.org designates 176.58.93.53 as permitted sender) smtp.mailfrom=dsl@mcusim.org
X-Spamd-Result: default: False [-2.02 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[mcusim.org:s=default];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 R_SPF_ALLOW(-0.20)[+a];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_SPAM_SHORT(0.98)[0.980];
	 DKIM_TRACE(0.00)[mcusim.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[mcusim.org,reject];
	 MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers,freebsd-stable];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:36236, ipnet:176.58.93.0/24, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

So, you didn't like initial DPAA2 support :(

Regards,
Dmitry

On Sat, Jun 11, 2022 at 06:01:17PM +0000, Lorenzo Salvadore wrote:
> FreeBSD Quarterly Status Report First Quarter 2022
> 
> As things are yet again settling into a new normal, it’s once again time for a
> status report for the FreeBSD Project.
> 
> You may have noticed that this report is also a little on the late side, and
> it’s with regret that it’s taken this long to get to it - however, thanks to a
> few kind souls who’ve stepped up to the plate, in addition to the folks on the
> team who do things quietly in the background, future reports should hopefully
> be more on time.
> 
> So let’s get some introductions in order, as yours truly is delighted to accept
> a hand from Pau Amma who already has been helping with reviews for a while,
> Lorenzo Salvadore who is stepping up to get some tooling in place to make it
> less of a chore to make the reports, as well as Sergio Carlavilla who is
> stepping up to help with all the work that can’t be easily automated.
> 
> This report covers a very diverse set of topics including but not limited to
> accessibility, system boot speed-up, an implementation of GEOM union, changes
> to the WiFi situation, and many other things.
> 
> We hope you’ll enjoy reading it!
> 
> Daniel Ebdrup Jensen, on behalf of the status report team.
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> A rendered version of this report is available here:
> https://www.freebsd.org/status/report-2022-01-2022-03/
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Table of Contents
> 
>   • FreeBSD Team Reports
>       â–¡ FreeBSD Foundation
>       â–¡ FreeBSD Release Engineering Team
>       â–¡ Cluster Administration Team
>       â–¡ Continuous Integration
>       â–¡ Ports Collection
>   • Projects
>       â–¡ FreeBSD Accessibility
>       â–¡ Boot Performance Improvements
>   • Kernel
>       â–¡ ENA FreeBSD Driver Update
>       â–¡ A New GEOM Facility, gunion
>       â–¡ Realtek Wireless driver support
>       â–¡ Intel Wireless driver support and LinuxKPI 802.11 compatibility layer
>       â–¡ Kernel Crypto changes to support WireGuard
>   • Documentation
>       â–¡ Documentation Engineering Team
>   • Ports
>       â–¡ KDE on FreeBSD
>       â–¡ Elsewhere
>       â–¡ FreeBSD Office Team
>       â–¡ lang/gcc* ports need some love and attention
>       â–¡ PortConfig
>       â–¡ Wifibox: Use Linux to drive your wireless card on FreeBSD
>   • Third Party Projects
>       â–¡ helloSystem
>       â–¡ Containers and FreeBSD: Pot, Potluck and Potman
>       â–¡ Fpart and fpsync
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> FreeBSD Team Reports
> 
> Entries from the various official and semi-official teams, as found in the
> Administration Page.
> 
> FreeBSD Foundation
> 
> Links:
> FreeBSD Foundation URL: https://www.FreeBSDFoundation.org
> Technology Roadmap URL: https://FreeBSDFoundation.org/blog/technology-roadmap/
> Donate URL: https://www.FreeBSDFoundation.org/donate/
> Foundation Partnership Program URL: https://www.FreeBSDFoundation.org/
> FreeBSD-foundation-partnership-program
> FreeBSD Journal URL: https://www.FreeBSDFoundation.org/journal/
> Foundation News and Events URL: https://www.FreeBSDFoundation.org/
> news-and-events/
> 
> Contact: Deb Goodkin 
> 
> The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to
> supporting and promoting the FreeBSD Project and community worldwide. Donations
> from individuals and corporations are used to fund and manage software
> development projects, conferences, and developer summits. We also provide
> travel grants to FreeBSD contributors, purchase and support hardware to improve
> and maintain FreeBSD infrastructure, and provide resources to improve security,
> quality assurance, and release engineering efforts. We publish marketing
> material to promote, educate, and advocate for the FreeBSD Project, facilitate
> collaboration between commercial vendors and FreeBSD developers, and finally,
> represent the FreeBSD Project in executing contracts, license agreements, and
> other legal arrangements that require a recognized legal entity.
> 
> Here are some highlights from the Foundation for the first quarter of 2022.
> 
> Fundraising Efforts
> 
> As promised, we updated our fundraising meter for 2022. So far, we’ve raised
> over $84,000 towards our 2022 goal of $1,400,000. We’d like to thank our
> individual and corporate donors for supporting our efforts this year. We’d also
> like to give a big shout out to our Gold Sponsor, Facebook, Silver Sponsors,
> VMware and Tarsnap, and the companies that provide free hosting for the
> Project: Bytemark, 365 Data Centers, NYI, NextArray, Sentex Data
> Communications, and the Computer Science Department at NCTU.
> 
> You can find out how we spent your donations by reading about what we supported
> in Q1, in this report, and our Spring Newsletter.
> 
> If you haven’t made a donation this year, please consider making a donation now
> at https://freebsdfoundation.org/donate/.
> 
> We also have a Partnership Program for larger commercial donors. You can find
> out more at https://freebsdfoundation.org/our-donors/
> freebsd-foundation-partnership-program/
> 
> OS Improvements
> 
> During the first quarter of 2022, 372 src, 41 ports, and 16 doc tree commits
> were made that identified The FreeBSD Foundation as a sponsor. # This
> represents 16, 0.4, and 5% of the total number of commits in each repository.
> 
> You can read about Foundation-sponsored projects in individual quarterly report
> entries:
> 
>   • Crypto changes for WireGuard
> 
>   • Intel Wireless driver support
> 
> Here is a small sample of other base system improvements from Foundation
> developers this quarter that do not have separate report entries.
> 
> riscv: Add support for enabling SV48 mode
> 
> SV48 is intended for systems for which a 39-bit virtual address space is
> insufficient. This change increases the size of the user map from 256GB to
> 128TB. The kernel map is left unchanged for now.
> 
> For now SV48 mode is left disabled by default, but can be enabled with a
> tunable. Note that extant hardware does not implement SV48, but QEMU does.
> 
>   • In pmap_bootstrap(), allocate a L0 page and attempt to enable SV48 mode. If
>     the write to SATP doesn’t take, the kernel continues to run in SV39 mode.
> 
>   • Define VM_MAX_USER_ADDRESS to refer to the SV48 limit. In SV39 mode, the
>     region [VM_MAX_USER_ADDRESS_SV39, VM_MAX_USER_ADDRESS_SV48] is not
>     mappable.
> 
> Add v3 support to CTF tools
> 
> CTF, the Compact C Type Format, is a representation of type information most
> often contained within ELF binaries. This type information is helpful for
> probing tools like DTrace. Recent work by Mark Johnston allows different Dtrace
> providers like the FBT (Function Boundary Tracing) provider to work with
> version 3 of CTF.
> 
> FreeBSD on the Framework Laptop
> 
> Two Foundation staff members, Ed Maste and Mark Johnston, as well as a few
> developers and community members now each have access to Framework laptops,
> which are designed to make hardware upgrades, repairs, and customizations
> straightforward for the average user. The goal of this work is to ensure that
> the experience running FreeBSD on the laptops matches the stability that
> FreeBSD users expect.
> 
> Recent improvements and fixes include:
> 
>   • Making audio switch appropriately between speakers and the headphone jack
>     when headphones are plugged in or unplugged
> 
>   • Fixing bug 259230, which would cause a Framework laptop to reboot or power
>     off when the touchpad was used.
> 
>   • Adding the Tempo Semiconductor 92HD95B HDA codec ID
> 
>   • Temporarily fixing stalled usb enumeration, bluetooth, and S3 resume. The
>     temporary fix is to avoid attaching to several newer Intel controllers,
>     which require firmware to be loaded, which is different from that
>     implemented by ng_ubt_intel and iwmbtfw, so they are not usable yet.
> 
>   • Avoiding a 16 second boot delay, by probing the TSC frequency earlier. This
>     lets us use the TSC to implement early DELAY, limiting the use of the
>     sometimes-unreliable 8254 PIT.
> 
> You can follow news about FreeBSD work on the Framework laptop at: https://
> wiki.freebsd.org/Laptops/Framework_Laptop.
> 
> Continuous Integration and Quality Assurance
> 
> The Foundation provides a full-time staff member and funds projects to improve
> continuous integration, automated testing, and overall quality assurance
> efforts for the FreeBSD project.
> 
> Supporting FreeBSD Infrastructure
> 
> The Foundation provides hardware and support for the Project. At the time of
> writing, the server that will become the new Australian mirror has arrived in
> Australia, has a fresh FreeBSD install and will shortly join the cluster.
> 
> FreeBSD Advocacy and Education
> 
> Much of our effort is dedicated to Project advocacy. This may involve
> highlighting interesting FreeBSD work, producing literature, attending events,
> or giving presentations. The goal of the literature we produce is to teach
> people FreeBSD basics and help make their path to adoption or contribution
> easier. Other than attending and presenting at events, we encourage and help
> community members run their own FreeBSD events, give presentations, or staff
> FreeBSD tables.
> 
> The FreeBSD Foundation sponsors many conferences, events, and summits around
> the globe. These events can be BSD-related, open source, or technology events
> geared towards underrepresented groups. We support the FreeBSD-focused events
> to help provide a venue for sharing knowledge, working together on projects,
> and facilitating collaboration between developers and commercial users. This
> all helps provide a healthy ecosystem. We support the non-FreeBSD events to
> promote and raise awareness of FreeBSD, to increase the use of FreeBSD in
> different applications, and to recruit more contributors to the Project. We are
> continuing to attend virtual events and began planning the June 2022 Developer
> Summit.
> 
> Check out some of the advocacy and education work we did last quarter:
> 
>   • Committed to hosting a FreeBSD Workshop at SCALE 19x and serve as a Media
>     Sponsor - July 28-31, 2022 in Los Angeles, CA
> 
>   • Participated in the FLOSS Weekly Podcast - January 5, 2022 https://twit.tv/
>     shows/floss-weekly/episodes/662
> 
>   • Sent out the 2021 Impact Report showcasing how we supported the Project
>     last year. https://freebsdfoundation.org/blog/
>     2021-freebsd-foundation-impact-report/
> 
>   • Hosted a stand at FOSDEM 2022 - Videos from the stand can be found at:
>     https://youtube.com/playlist?list=PLugwS7L7NMXxwqIRg1PlhgzhNRi1eVdRQ
> 
>   • Participated in the Open Source Voices Podcast - Episode to be aired in
>     late April [note from status report team: the episode has indeed be aired
>     and is now available at https://www.opensourcevoices.org/29; unfortunately,
>     there is and will be no transcript.]
> 
>   • Began planning the June 2022 FreeBSD Developers Summit taking place
>     virtually, June 16-17, 2022 https://wiki.freebsd.org/DevSummit/202206
> 
>   • Held a new FreeBSD Friday - How to Track FreeBSD Using Git Pt. 2 https://
>     youtu.be/Fe-dJrDMK_0
> 
>   • Presented at the St. Louis Unix User Group on March 9, 2022 https://ow.ly/
>     1QXn50Ivj75
> 
>   • Served as Admins and were accepted as a mentoring organization for the 2022
>     Google Summer of Code
> 
>   • Held an Office Hours session on Google Summer of Code. https://youtu.be/
>     x-4U1xurmBE
> 
>   • Hosted a booth at the virtual Open Source 101 conference on March 29, 2022
> 
>   • New blog posts:
> 
>       â–¡ RAID-Z Expansion Feature for ZFS In the Home Stretch
> 
>       □ What’s Ahead for FreeBSD and the Foundation in 2022
> 
>       â–¡ Work with FreeBSD in Google Summer of Code
> 
>   • New How-To Guide: An Introduction to FreeBSD Jails
> 
>   • New FreeBSD Journal Article: Contributing to FreeBSD ports with Git
> 
> We help educate the world about FreeBSD by publishing the professionally
> produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is
> now a free publication. Find out more and access the latest issues at https://
> www.FreeBSDfoundation.org/journal/
> 
> You can find out more about events we attended and upcoming events at https://
> www.FreeBSDfoundation.org/news-and-events/.
> 
> Legal/FreeBSD IP
> 
> The Foundation owns the FreeBSD trademarks, and it is our responsibility to
> protect them. We also provide legal support for the core team to investigate
> questions that arise.
> 
> Go to https://www.FreeBSDFoundation.org to find more about how we support
> FreeBSD and how we can help you!
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> FreeBSD Release Engineering Team
> 
> Links:
> FreeBSD 13.1-RELEASE schedule URL: https://www.freebsd.org/releases/13.1R/
> schedule/
> FreeBSD 13.1 Release Information URL: https://www.freebsd.org/releases/13.1R/
> [link added by status report team as this quarterly status report is being
> published after 13.1-RELEASE has been released]
> FreeBSD releases URL: https://download.freebsd.org/ftp/releases/ISO-IMAGES/
> FreeBSD development snapshots URL: https://download.freebsd.org/ftp/snapshots/
> ISO-IMAGES/
> 
> Contact: FreeBSD Release Engineering Team, 
> 
> The FreeBSD Release Engineering Team is responsible for setting and publishing
> release schedules for official project releases of FreeBSD, announcing code
> freezes and maintaining the respective branches, among other things.
> 
> During the first quarter of 2022, the Release Engineering Team completed work
> on, and submitted to the developers the 13.1-RELEASE schedule. This will be the
> second point release from the stable/13 branch. As of this writing, three BETA
> builds have been run, with at least two RC builds before the final release,
> currently scheduled for April 21, 2022.
> 
> We look forward to another consistently stable release at the end of this
> cycle, as well as many more to come for other branches moving forward.
> 
> Additionally throughout the quarter, several development snapshots builds were
> released for the main, stable/13, and stable/12 branches.
> 
> Sponsor: Rubicon Communications, LLC ("Netgate") Sponsor: The FreeBSD
> Foundation
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Cluster Administration Team
> 
> Links:
> Cluster Administration Team members URL: https://www.freebsd.org/administration
> /#t-clusteradm
> 
> Contact: Cluster Administration Team 
> 
> FreeBSD Cluster Administration Team members are responsible for managing the
> machines the Project relies on to synchronise its distributed work and
> communications. In this quarter, the team has worked on the following:
> 
>   • Improved web service performance and security
> 
>       â–¡ Moved some critical services to newer machines
> 
>       â–¡ Swept all services to ensure the support of TLS v1.2 and v1.3 and
>         disable v1 and v1.1
> 
>       â–¡ Enabled dual-stack certificates for the primary FreeBSD web services.
>         ECDSA and RSA certificates, preferring ECDSA, discussed with secteam@,
>         benefit the project in favor of security and performance matter.
> 
>   • Infrastructure improvements at primary site
> 
>       â–¡ Evicted some very old hardware
> 
>       â–¡ Moved cluster internal services to newer hardware
> 
>           ☆ Build host
> 
>           ☆ Parts of LDAP, kerberos, DNS and NTP
> 
>   • Installed an additional aarch64 package builder
> 
>       â–¡ ampere3.nyi.freebsd.org
> 
>       â–¡ Identical specs to ampere[12].nyi.freebsd.org
> 
>   • Moved ftp0.nyi.freebsd.org to an aarch64 machine.
> 
>   • Main distributed mirror site, download.freebsd.org, enhancements
> 
>       â–¡ Updated offline documentation (PDF and HTML) in the mirrors.
>         The old directory /doc is now on ftp-archive; it contains files prior
>         to the Hugo/Asciidoctor migration.
> 
>       â–¡ Moved ports INDEX files to distributed mirror, download.freebsd.org
> 
>       â–¡ Removed /ftp from the canonical URLs of files on download.freebsd.org.
>         Old URLs are still valid.
> 
>   • Cleanup of Handbook/Mirrors section
>     Much stale information; now there is more info about the official mirrors
>     and locations. Former official mirrors are now named 'Community mirrors'.
> 
>   • Ongoing day to day cluster administration
> 
>       â–¡ Cluster refresh
> 
>       â–¡ Replacing failed disks
> 
>       â–¡ Babysitting pkgsync
> 
> Work in progress:
> 
>   • Improve the package building infrastructure
> 
>   • Review the service jails and service administrators operation
> 
>   • Set up powerpc pkgbuilder/ref/universal machines
> 
>   • Search for more providers that can fit the requirements for a generic
>     mirrored layout or a tiny mirror
> 
>   • Work with doceng@ to improve https://www.freebsd.org and https://
>     docs.freebsd.org
> 
>   • Improve the web service architecture
> 
>   • Improve the cluster backup plan
> 
>   • Improve the log analysis system
> 
>   • Set up Australia mirror
> 
>   • Hardware refresh
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Continuous Integration
> 
> Links:
> FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org
> FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org
> FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins
> Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI
> 3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI
> Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg
> FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci
> dev-ci Mailing List URL: https://lists.freebsd.org/subscription/dev-ci
> 
> Contact: Jenkins Admin 
> Contact: Li-Wen Hsu 
> Contact: freebsd-testing Mailing List
> Contact: IRC #freebsd-ci channel on EFNet
> 
> The FreeBSD CI team maintains the continuous integration system of the FreeBSD
> project. The CI system checks the committed changes can be successfully built,
> then performs various tests and analysis over the newly built results. The
> artifacts from those builds are archived in the artifact server for further
> testing and debugging needs. The CI team members examine the failing builds and
> unstable tests and work with the experts in that area to fix the code or adjust
> test infrastructure.
> 
> During the first quarter of 2022, we continued working with the contributors
> and developers in the project to fulfil their testing needs and also keep
> collaborating with external projects and companies to improve their products
> and FreeBSD.
> 
> Important changes:
> 
>   • DTrace tests are running with KASAN now.
> 
>   • Fixed and resumed the powerpc64le test jobs.
> 
> Retired jobs:
> 
>   • The jobs of main branch on mips* were removed.
> 
> Work in progress and open tasks:
> 
>   • Designing and implementing pre-commit CI building and testing (to support
>     the workflow working group)
> 
>   • Designing and implementing use of CI cluster to build release artifacts as
>     release engineering does
> 
>   • Collecting and sorting CI tasks and ideas here
> 
>   • Testing and merging pull requests in the FreeBSD-ci repo
> 
>   • Reducing the procedures of CI/test environment setting up for contributors
>     and developers
> 
>   • Setting up the CI stage environment and putting the experimental jobs on it
> 
>   • Setting up public network access for the VM guest running tests
> 
>   • Implementing using bare metal hardware to run test suites
> 
>   • Adding drm ports building tests against -CURRENT
> 
>   • Planning to run ztest tests
> 
>   • Adding more external toolchain related jobs
> 
>   • Improving maturity of the hardware lab and adding more hardware under test
> 
>   • Helping more software get FreeBSD support in its CI pipeline (Wiki pages:
>     3rdPartySoftwareCI, HostedCI)
> 
>   • Working with hosted CI providers to have better FreeBSD support
> 
> Please see freebsd-testing@ related tickets for more WIP information, and don’t
> hesitate to join the effort!
> 
> Sponsor: The FreeBSD Foundation
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Ports Collection
> 
> Links:
> About FreeBSD Ports URL:https://www.FreeBSD.org/ports/
> Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#
> ports-contributing
> FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/
> Ports Management Team URL: https://www.freebsd.org/portmgr/
> Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/
> 
> Contact: René Ladan 
> Contact: FreeBSD Ports Management Team 
> 
> The Ports Management Team is responsible for overseeing the overall direction
> of the Ports Tree, building packages, and personnel matters. Below is what
> happened in the last quarter.
> 
> Before we start with the usual statistics, portmgr is happy to announce it has
> successfully restarted its lurker program. The first two lurkers are pizzamig@
> and se@; they will learn about the inner workings of portmgr and bring in new
> ideas.
> 
> Portmgr also started having bi-weekly meetings, some public results are: *
> restarting the lurker program * fixes to ports going backwards in version *
> dropping DragonFlyBSD version checks in bsd.port.mk * dropping deprecation
> notes from ports transitively using Python 2.7
> 
> Currently we have over 46,800 ports in the Ports Tree. There are currently
> 2,700 open ports PRs of which 680 are unassigned. The last quarter saw 9,403
> commits to the main branch by 157 committers and 683 commits to the 2022Q1
> branch by 63 committers. Compared to last quarter, this means a slight drop in
> activity to the main branch and a slight increase in the number of open PRs.
> 
> No new committers joined during the last quarter, portmgr took koobs@' commit
> bit in for safekeeping because of a lack of recent commits.
> 
> The cluster administration team has provided portmgr with a third aarch64
> builder; it is being used for package builds.
> 
> Things that happened in git: * Two new USES were introduced: elfctl to change
> an ELF binary’s feature control note minizip to get the correct library
> dependency on minizip * Two keywords got removed: fcfontsdir (now handled by
> USES=fonts) glib-schemas, it has been replaced by a trigger * Default versions
> that changed: Lazarus switched to 2.2.0 PHP switched to 8.0 * Some upgrades to
> major ports: Chromium 100.0.4896.60 Electron 13.6.9 Firefox 99.0 Firefox ESR
> 91.8.0 Gnome 41 KDE Frameworks 5.92.0 ** KDE Plasma 5.24.4
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Projects
> 
> Projects that span multiple categories, from the kernel and userspace to the
> Ports Collection or external projects.
> 
> FreeBSD Accessibility
> 
> Links:
> Accessibility wiki page URL: https://wiki.freebsd.org/Accessibility
> List introduction, goals, audience, and ground rules URL: link:https://
> lists.freebsd.org/archives/freebsd-accessibility/2021-October/000000.html
> 
> Contact: Pau Amma 
> Contact: FreeBSD accessibility discussions 
> 
> Over the past several months, I’ve started putting together tools and resources
> to help make the FreeBSD ecosystem (more) accessible to people with
> disabilities:
> 
>   • a mailing list
> 
>   • a set of wiki pages including resources and a categorized wish list
> 
>   • tooling including a searchable accessibility Bugzilla keyword and an
>     accessibility Phabricator group
> 
> I need all the help I can get with:
> 
>   • specifying, designing, implementing, and testing the items on the wishlist
> 
>   • adding to the wishlist in areas were have little or no experience or for
>     things I missed
> 
>   • moving beyond software and documentation to processes and culture
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Boot Performance Improvements
> 
> Links:
> Wiki page URL: https://wiki.freebsd.org/BootTime
> OS boot time comparison URL: https://www.daemonology.net/blog/
> 2021-08-12-EC2-boot-time-benchmarking.html
> 
> Contact: Colin Percival 
> 
> Colin Percival is coordinating an effort to speed up the FreeBSD boot process.
> For benchmarking purposes, he is primarily using an EC2 c5.xlarge instance as a
> reference platform and is measuring the time between when the virtual machine
> enters the EC2 "running" state and when it is possible to SSH into the
> instance.
> 
> This work started in 2017, and as of the end of December 2021 the FreeBSD boot
> time was reduced from approximately 30 seconds to approximately 10 seconds.
> During 2022Q1, further improvements have shaved more time off the boot process,
> taking it down to roughly 8 seconds
> 
> Two major issues remain outstanding:
> 
>  1. The first time an EC2 instance boots, dhclient takes about 2 seconds longer
>     than normal to get an IPv4 address. The cause of this is unknown and
>     requires investigation.
> 
>  2. IPv6 configuration includes two one-second-long sleep(1) invocations, one
>     from /etc/rc.d/netif and the other from /etc/rc.d/rtsold. It might be
>     possible to simply remove these; but care is needed to avoid progressing
>     too far in the boot process before IPv6 addresses are configured. Input
>     from IPv6 experts is required here.
> 
> Issues are listed on the wiki page as they are identified; the wiki page also
> has instructions for performing profiling. Users are encouraged to profile the
> boot process on their own systems, in case they experience delays which don’t
> show up on the system Colin is using for testing.
> 
> This work is supported by Colin’s FreeBSD/EC2 Patreon.
> 
> Sponsor: https://www.patreon.com/cperciva
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Kernel
> 
> Updates to kernel subsystems/features, driver support, filesystems, and more.
> 
> ENA FreeBSD Driver Update
> 
> Links:
> ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/
> ena/README
> 
> Contact: Michal Krawczyk 
> Contact: Dawid Gorecki 
> Contact: Marcin Wojtas 
> 
> ENA (Elastic Network Adapter) is the smart NIC available in the virtualized
> environment of Amazon Web Services (AWS). The ENA driver supports multiple
> transmit and receive queues and can handle up to 100 Gb/s of network traffic,
> depending on the instance type on which it is used.
> 
> Completed since the last update:
> 
>   • Add IPv6 layer 4 checksum offload support to the driver
> 
>   • Add NUMA awareness to the driver when the RSS kernel option is enabled
> 
>   • Rework validation of the Tx request ID
> 
>   • Change lifetime of the driver’s timer service
> 
>   • Avoid reset triggering when the device is unresponsive
> 
> Work in progress:
> 
>   • Prototype the driver port to the iflib framework
> 
>   • Tests of the incoming ENA driver release (v2.5.0)
> 
> Sponsor: Amazon.com Inc
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> A New GEOM Facility, gunion
> 
> Contact: Marshall Kirk McKusick 
> 
> The gunion facility is used to track changes to a read-only disk on a writable
> disk. Logically, a writable disk is placed over a read-only disk. Write
> requests are intercepted and stored on the writable disk. Read requests are
> first checked to see if they have been written on the top (writable disk) and
> if found are returned. If they have not been written on the top disk, then they
> are read from the lower disk.
> 
> The gunion facility can be especially useful if you have a large disk with a
> corrupted filesystem that you are unsure of how to repair. You can use gunion
> to place another disk over the corrupted disk and then attempt to repair the
> filesystem. If the repair fails, you can revert all the changes in the upper
> disk and be back to the unchanged state of the lower disk thus allowing you to
> try another approach to repairing it. If the repair is successful you can
> commit all the writes recorded on the top disk to the lower disk.
> 
> Another use of the gunion facility is to try out upgrades to your system. Place
> the upper disk over the disk holding your filesystem that is to be upgraded and
> then run the upgrade on it. If it works, commit it; if it fails, revert the
> upgrade.
> 
> The gunion(8) utility is used to create and manage an instance of a gunion.
> Further details and usage examples can be found in the gunion(8) manual page.
> At this time, gunion(8) is available only in 14.0.
> 
> Sponsor: Netflix
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Realtek Wireless driver support
> 
> Links:
> rtw88 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw88
> rtw89 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw89
> 
> Contact: Bjoern A. Zeeb 
> 
> While the Intel Wireless driver update project is the main driver behind the
> work to bring support for newer chipsets and eventually newer IEEE 802.11
> standards support, there is also an ongoing effort to support more drivers. The
> next two drivers in the (already longer) queue are Realtek’s rtw88 and rtw89.
> 
> While the initial driver porting efforts for rtw88 and rtw89 happened on
> personal time, the LinuxKPI integration has to be done more and more along the
> Intel wireless driver work and so thanks are also due to The FreeBSD
> Foundation.
> 
> The rtw88 driver has started to work on some machines with less than 4GB of
> main memory and was committed to the FreeBSD git repository for broader
> testing. While our version of the driver is aware of these limitations, the
> problem is currently assumed to be outside the driver in the interactions with
> LinuxKPI and busdma.
> 
> The rtw89 driver has happily started to send packets and has problems receiving
> frames at this point. Further investigation will happen as soon as rtw88 is
> sorted out and it is expected that rtw89 will then also timely follow into
> FreeBSD’s git repository.
> 
> The currently known requirements to compile both drivers have mostly gone into
> stable/13 and releng/13.1 already.
> 
> For the latest state of the development, please check the referenced wiki pages
> and follow the freebsd-wireless mailing list.
> 
> Sponsor: The FreeBSD Foundation (partly)
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Intel Wireless driver support and LinuxKPI 802.11 compatibility layer
> 
> Links:
> iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Iwlwifi
> 
> Contact: Bjoern A. Zeeb 
> 
> The Intel Wireless driver update project aims to bring support for newer
> chipsets along with mac80211 LinuxKPI compat code. The dual-licensed Intel
> driver code was ported in the past for the iwm(4) native driver; using the
> LinuxKPI compat framework allows us to use the driver directly and gives
> support to all the latest chipsets, with only minor local modifications. Some
> of the changes made while porting the driver to FreeBSD were kindly
> incorporated into the upstream Linux driver already.
> 
> During the first quarter work continued with about 70 commits. Updating the
> driver and firmware reduced differences to the Linux version and gave us
> bugfixes and improvements. Changes to the LinuxKPI 802.11 compatibility layer
> were made to avoid firmware crashes and possible panics for users along with
> other improvements.
> 
> Auto-loading support for LinuxKPI PCI drivers was comitted. This means that
> iwlwifi(4) will now load automatically during boot if a supported card is
> detected without any user interactions. Considering the current state of the
> driver and the next release a decision was made that iwm(4) supported chipsets
> will continue to attach to iwm(4) for now and only newer and otherwise
> unsupported chipsets will use the iwlwifi(4) driver. This is likely going to
> change in CURRENT as soon as iwlwifi(4) provides better support than iwm(4).
> 
> The code was merged to the stable/13 branch and the current state will be
> shipped with the upcoming 13.1-RELEASE.
> 
> In addition to The FreeBSD Foundation thanks need to go to all users who have
> been testing and reporting back or are patiently waiting for the next update.
> For the latest state of the development, please follow the freebsd-wireless
> mailing list.
> 
> Sponsor: The FreeBSD Foundation
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Kernel Crypto changes to support WireGuard
> 
> Contact: John Baldwin 
> 
> During the last quarter, I continued my work to improve the FreeBSD WireGuard
> driver. On the FreeBSD side, I added support for the XChaCha20-Poly1305 AEAD
> cipher. I also added a dedicated API to support [X]ChaCha20-Poly1035 on small,
> flat buffers. Finally, I added an API wrapper for the curve25519 implementation
> from libsodium.
> 
> For the WireGuard driver, I wrote a series of patches which updates the driver
> to use crypto APIs such as those mentioned above in place of internal cipher
> implementations. The series also includes a fix to avoid scheduling excessive
> crypto tasks as well as a few other small fixes. This series is pending review.
> 
> Sponsor: The FreeBSD Foundation
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Documentation
> 
> Noteworthy changes in the documentation tree, man-pages, or new external books/
> documents.
> 
> Documentation Engineering Team
> 
> Link: FreeBSD Documentation Project
> Link: FreeBSD Documentation Project Primer for New Contributors
> Link: Documentation Engineering Team
> 
> Contact: FreeBSD Doceng Team 
> 
> The doceng@ team is a body to handle some of the meta-project issues associated
> with the FreeBSD Documentation Project; for more information, see FreeBSD
> Doceng Team Charter.
> 
> No new documentation commit bit was granted during the last quarter, and only
> one commit bit was safe kept.
> 
> Several tasks were completed related to the doc tree during the last quarter:
> 
>   • Fix some issues in the translation workflow with PO files and Weblate
>     related to the po4a program.
> 
>     More info here.
> 
>   • Update offline documentation (PDF and HTML).
> 
>     The old directory /doc is now on ftp-archive; it contains files prior to
>     the Hugo/Asciidoctor migration.
> 
>   • Remove Google Analytics from documentation and website.
> 
>   • Add last modified information to the documentation and website pages.
> 
>   • Tag FreeBSD docset for 13.1-RELEASE.
> 
>   • Add the first Indonesian translation to the doc tree.
> 
> FreeBSD Translations on Weblate
> 
> Link: Translate FreeBSD on Weblate
> Link: FreeBSD Weblate Instance
> 
> The translation workflow with Weblate is more mature at this point. Several
> issues were fixed between PO files and po4a program.
> 
> We welcome everyone to try our Weblate instance to translate a few documents.
> 
> The first Indonesian translation was added to the FreeBSD project. We thank
> Azrael JD for the contribution, and we are looking forward to seeing more
> Indonesian translations.
> 
> Q1 2022 Status
> 
>   • 12 languages (1 new language)
> 
>   • 142 registered users
> 
> Languages
> 
>   • Chinese (Simplified) (zh-cn)
> 
>   • Chinese (Traditional) (zh-tw)
> 
>   • Dutch (nl)
> 
>   • French (fr)
> 
>   • German (de)
> 
>   • Indonesian (id) - Added
> 
>   • Italian (it)
> 
>   • Norwegian (nb-no)
> 
>   • Persian (fa-ir)
> 
>   • Portuguese (pt-br)
> 
>   • Spanish (es)
> 
>   • Turkish (tr)
> 
> We want to thank everyone that contributed, translating or reviewing documents.
> 
> And please, help promote this effort on your local user group, we always need
> more volunteers.
> 
> FreeBSD Website Revamp - WebApps working group
> 
> Contact: Sergio Carlavilla 
> 
> Working group in charge of creating the new FreeBSD Documentation Portal and
> redesigning the FreeBSD main website and its components. FreeBSD developers can
> follow and join the working group on the FreeBSD Slack channel #wg-www21. The
> work will be divided into four phases:
> 
>  1. Redesign of the Documentation Portal
> 
>     Create a new design, responsive and with global search. (Complete)
> 
>  2. Redesign of the Manual Pages on web
> 
>     Scripts to generate the HTML pages using mandoc. (Work in progress)
> 
>  3. Redesign of the Ports page on web
> 
>     Ports scripts to create an applications portal. (Work in progress)
> 
>  4. Redesign of the FreeBSD main website
> 
>     New design, responsive and dark theme. (Not started)
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Ports
> 
> Changes affecting the Ports Collection, whether sweeping changes that touch
> most of the tree, or individual ports themselves.
> 
> KDE on FreeBSD
> 
> Links:
> KDE FreeBSD URL: https://freebsd.kde.org/
> KDE Community FreeBSD URL: https://community.kde.org/FreeBSD
> 
> Contact: Adriaan de Groot 
> 
> The KDE on FreeBSD project packages the software from the KDE Community, along
> with dependencies and related software, for the FreeBSD ports tree. The
> software includes a full desktop environment called KDE Plasma (for both X11
> and Wayland) and hundreds of applications that can be used on any FreeBSD
> machine.
> 
> The KDE team (kde@) is part of desktop@ and x11@ as well, building the software
> stack to make FreeBSD beautiful and usable as a daily-driver graphics-based
> desktop machine.
> 
> KDE Qt Patch Collection The Qt Company did not release Qt 5.15 updates under
> Open Source licenses in 2021, leaving the Open Source 5.15 version lagging
> behind the proprietary release. Qt 6 is released under an Open Source license,
> but for the world of Open Source software that requires Qt 5, there is still a
> need for updates. The KDE Community fills that need by maintaining a curated
> set of patches — generally backported from Qt6 — to maintain the Open Source
> version of Qt 5. FreeBSD ports now use this KDE Qt Patch Collection, rather
> than the outdated last Qt 5.15.2 release from the Qt Company. This landed both
> in main and the last quarterly branch for 2021, since it brings important
> bugfixes.
> 
> KDE Stack
> 
>   • KDE Plasma Desktop (all the /plasma5- ports) was updated to 5.23.5 at the
>     start of the year. Since this happened very shortly after quarterly was
>     branched, this was MFH’ed. The long-term-support release 5.24 landed
>     mid-february. The FreeBSD ports do not stick to LTS releases, and will
>     follow the regular release schedule. 5.24.3 landed on schedule in March.
> 
>   • KDE Gear (the collection of KDE libraries and applicatious outside of the
>     Frameworks and Plasma Desktop groups) was updated to 21.12.1 and MFH’ed.
>     Monthy releases landed as well: 21.12.2 in February.
> 
>   • KDE Frameworks have a monthly release cadence, so 5.90 landed in January,
>     5.91 in February and 5.92 in March.
> 
>   • KDE PIM currently does not support Contacts stored in a Google account
>     because Google has changed the available REST API.
> 
>   • astro/kstars received its regularly scheduled updates.
> 
>   • deskutils/kalendar was updated. It has now reached the 1.0 stage.
> 
>   • deskutils/kodaskanna was added to the ports tree. It is a simple QR-code
>     scanner for the desktop.
> 
>   • deskutils/latte-dock is an alternative launcher for use in KDE Plasma
>     Desktop and other environments. It was updated to 0.10.7 as part of its
>     monthly releases.
> 
>   • devel/okteta, an editor and viewer for binary data, was updated to 0.26.7,
>     a regular bugfix release.
> 
>   • graphics/digikam, the digital photography manager, was updated to 7.6.0.
>     (Thanks Dima Panov)
> 
>   • graphics/kf5-kimageformats has a new option enabling libheif and HEIC
>     support.
> 
>   • graphics/kontrast was added to the 'accessibility' category. This is a tool
>     for checking color-combinations (e.g. for a website) for sufficient
>     contrast and readability.
> 
>   • graphics/krita was updated to the next big release, Krita 5. (Thanks Max
>     Brazhnikov)
> 
>   • lang/kross-interpreters was fixed for Ruby 3. (Thanks Yasuhiro Kimura)
> 
>   • sysutils/plasma5-discover was updated to resolve some denial-of-service
>     bugs in KDE infrastructure.
> 
>   • www/falkon was updated. After a two-year wait, a new release of the KDE web
>     browser built on Qt WebEngine (itself a wrapper around Chromium internals)
>     arrived upstream and in ports.
> 
>   • x11/plasma5-plasma-workspace now can properly edit login and account
>     information.
> 
> Related Applications
> 
>   • devel/qtcreator was updated to version 6. A new versioning model has been
>     introduced by upstream, so this will now jump by major release number
>     regularly. (Thanks to Florian Walpen)
> 
>   • irc/quassel was updated. Quassel is a distributed IRC client (think of it
>     as your own personal IRC bouncer).
> 
>   • misc/tellico was updated. Tellico is a "collection manager", for instance
>     collections of books, music, stamps, or FreeBSD releases.
> 
>   • net-im/nheko was updated. This is one of a dozen Matrix clients available
>     in the ports tree.
> 
> Elsewhere
> 
>   • archivers/7-zip is the preferred tool for dealing with 7zip files; this
>     affacts KDE applications that work with archives (like archivers/ark). We
>     would like to thank makc@ for stewarding that update.
> 
>   • devel/libphonenumber has bi-weekly updates to chase the exciting world of
>     telephony details.
> 
>   • graphics/poppler was updated to version 22.01. This version requires C17,
>     which pushes a number of consumers to the newer C standard as well. Most
>     consumers were fixed in advance.
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> FreeBSD Office Team
> 
> Links:
> The FreeBSD Office project URL: https://wiki.freebsd.org/Office
> The FreeBSD Office mailing list URL: https://lists.freebsd.org/subscription/
> freebsd-office
> 
> Contact: FreeBSD Office team ML 
> Contact: Dima Panov 
> Contact: Li-Wen Hsu 
> 
> The FreeBSD Office team works on a number of office-related software suites and
> tools such as OpenOffice and LibreOffice.
> 
> Work during this quarter was focused on providing the latest stable release of
> LibreOffice suite and companion apps to all FreeBSD users.
> 
> During the 2022Q1 period we pushed maintenance patches for the LibreOffice 7.2
> port to the quarterly branch and brought the latest, 7.3, releases and all
> companion libraries such as MDDS, libIxion and more to the ports tree.
> 
> Also we are still working on the Boost WIP repository to bring the latest Boost
> library to the ports.
> 
> We are looking for people to help with the open tasks:
> 
>   • The open bugs list contains all filed issues which need some attention
> 
>   • Upstream local patches in ports
> 
> Patches, comments and objections are always welcome in the mailing list and
> Bugzilla.
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> lang/gcc* ports need some love and attention
> 
> Links:
> GCC Project URL: https://gcc.gnu.org
> GCC 11 release series URL: https://gcc.gnu.org/gcc-11/
> 
> Contact: toolchain@FreeBSD.org
> Contact: Gerald Pfeifer 
> 
> After about two decades of maintaining FreeBSD’s lang/gcc* ports, the time came
> to hand over the baton and mostly step back. Alas the baton essentially dropped
> to the floor, despite multiple calls for help.
> 
> Here are a few specific tasks looking for help:
> 
>   • Upgrade GCC_DEFAULT in Mk/bsd.default-versions.mk from 10 to 11, including
>     fixing the (luckily minor) fall out of an -exp run: https://
>     bugs.freebsd.org/bugzilla/show_bug.cgi?id=258378
> 
>   • Three changes to work through with upstream GCC (requires src expertise,
>     not ports):
> 
>       â–¡ upstreaming lang/gcc11/patch-gets-no-more
> 
>       â–¡ upstreaming lang/gcc11/patch-arm-unwind-cxx-support
> 
>       â–¡ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256874
> 
>   • We have removed the unmaintained lang/gcc9-devel and lang/gcc10-devel
>     ports, alas kept lang/gcc11-devel and lang/gcc12-devel which would be good
>     to see if not weekly, then somewhat regular updates.
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> PortConfig
> 
> Links:
> Repository portconfig URL: https://gitlab.com/alfix/portconfig/
> 
> Contact: Alfonso Sabato Siciliano (upstream) 
> Contact: Baptiste Daroussin (port) 
> 
> FreeBSD provides the Ports Collection to give users and administrators a simple
> way to install applications. It is possible to configure a port before the
> building and installation. PortConfig is an utility for setting the port
> options via a Text User Interface.
> 
> As each terminal has different properties PortConfig can be customized via
> environment variables to set up the User Interface, for example: menu size,
> theme, borders, and so on; each feature is documented inside the manual.
> Further, if a port has a specific 'pkg-help' file, PortConfig will show a Help
> button to open a "popup" with help information.
> 
> FreeBSD provides thousands of ports therefore it is not feasible to test
> PortConfig for each use; please report any problem.
> 
> Alfonso would like to thank Baptiste Daroussin for the port, suggestions, help,
> and testing for this utility and its library.
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Wifibox: Use Linux to drive your wireless card on FreeBSD
> 
> Links:
> Project GitHub Page
> net/wifibox port
> 
> Contact: PÃLI Gábor János 
> 
> Wifibox is an experimental project for exploring the ways of deploying a
> virtualized Linux guest to drive wireless networking cards on the FreeBSD host
> system. There have been guides on the Internet to suggest the use of such
> techniques to improve the wireless networking experience, of which Wifibox aims
> to implement as a single easy-to-use software package.
> 
>   • bhyve(8) is utilized to run the embedded Linux system. This helps to
>     achieve low resource footprint. It requires an x64 CPU with I/O MMU
>     (AMD-Vi, Intel VT-d), ~150 MB physical memory, and some disk space
>     available for the guest virtual disk image, which can be even ~30 MB only
>     in certain cases. It works with FreeBSD 12 and later, some cards may
>     require a recent 13-STABLE though.
> 
>   • The guest is constructed using Alpine Linux, a security-oriented,
>     lightweight distribution based on musl libc and BusyBox.
> 
>   • Configuration files are shared with the host system. The guest uses
>     wpa_supplicant(8) so it is possible to import the host’s
>     wpa_supplicant.conf(8) file without any changes.
> 
>   • When configured, wpa_supplicant(8) control sockets could be exposed by the
>     guest, which enables use of related utilities directly from the host, such
>     as wpa_cli(8) or wpa_gui(8) from the net/wpa_supplicant_gui port/package.
> 
>   • Everything is shipped in a single package that can be easily installed and
>     removed. This comes with an rc(8) system service that automatically
>     launches the guest on boot and stops it on shutdown.
> 
>   • A workaround is supplied for laptops to support suspend/resume.
> 
> Wifibox has been mainly tested with Intel chipsets so far, and it has shown
> great performance and stability. Therefore it might serve as an interim
> solution until the Intel Wireless support becomes mature enough. It was
> confirmed that Wifibox works with Atheros chipsets too, and feedback is more
> than welcome about others. Support for Broadcom chipsets is not yet complete,
> that is currently a work in progress.
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Third Party Projects
> 
> Many projects build upon FreeBSD or incorporate components of FreeBSD into
> their project. As these projects may be of interest to the broader FreeBSD
> community, we sometimes include brief updates submitted by these projects in
> our quarterly report. The FreeBSD project makes no representation as to the
> accuracy or veracity of any claims in these submissions.
> 
> helloSystem
> 
> Links:
> Documentation URL: https://hellosystem.github.io/
> 
> Contact: Simon Peter 
> Contact: #helloSystem on irc.libera.chat, mirrored to #helloSystem:matrix.org
> on Matrix
> 
> What is helloSystem?
> 
> helloSystem is FreeBSD preconfigured as a desktop operating system with a focus
> on simplicity, elegance, and usability. Its design follows the “Less, but
> better†philosophy.
> 
> Q1 2022 Status
> 
>   • Version 0.8.0 of helloSystem is under development and test
> 
>       â–¡ helloSystem 0.8.0 will be based on FreeBSD 13.1-RELEASE
> 
>       â–¡ Experimental Live ISOs using FreeBSD 13.1-BETA3 are available
> 
>       â–¡ Initial support for running Linux AppImage files using an optional
>         Debian runtime
> 
>       â–¡ Initial support for the AppImage format in the user interface
> 
>       â–¡ Improved reliability and performance of mounted archives by using
>         fuse-archive
> 
>       â–¡ Various bugfixes
> 
> Installable experimental Live ISO images are available at https://github.com/
> helloSystem/ISO/releases/tag/experimental-13.1.
> 
> Contributing
> 
> The project appreciates contributions in various areas.
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Containers and FreeBSD: Pot, Potluck and Potman
> 
> Links:
> Pot organization on github URL: https://github.com/bsdpot
> 
> Contact: Luca Pizzamiglio (Pot) 
> Contact: Stephan Lichtenauer (Potluck) 
> Contact: Michael Gmelin (Potman) 
> 
> Pot is a jail management tool that also supports orchestration through Nomad.
> 
> As a result of production testing in a real-world cluster deployment, pot and
> related projects received stability improvements for controlling the pot
> lifecycle (i.e., pot prepare/start/stop).
> Various attributes and commands have been developed to improve support of nomad
> orchestration and batch jobs (e.g., change dns config during clone, ability to
> disable tmpfs, new last-run-stats command). A new pot release will follow soon.
> 
> Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: a
> repository of pot flavours and complete container images for usage with pot and
> in many cases nomad.
> 
> Many of the core images like Nomad, Consul and Vault that can be used to build
> a private cloud and orchestration platform, but also e.g. Prometheus or
> PostgreSQL Patroni, have reached a stable status over the last quarter and are
> in production use now.
> 
> To make navigating the evolving pot ecosystem easier, most project resources
> have been centralized in a dedicated github project: https://github.com/bsdpot
> 
> There, we plan to release ansible playbooks that allow easily creating a
> FreeBSD based orchestration environment from scratch based on all these tools.
> 
> As always, feedback and patches are welcome.
> 
> â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
> 
> Fpart and fpsync
> 
> Links:
> Project site and documentation URL: https://www.fpart.org
> Development URL: https://github.com/martymac/fpart
> Port URL: https://www.freshports.org/sysutils/fpart
> 
> Contact: Ganael Laplanche 
> 
> What is fpart ?
> 
> Fpart is a filesystem partitioner. It helps you sort file trees and pack them
> into bags ("partitions").
> 
> It uses FreeBSD’s fts(3) implementation (GNU/Linux builds can also use it as an
> option), which makes it crawl filesystems very fast.
> 
> A hook facility is provided to trigger actions on the partitions produced.
> 
> What is fpsync ?
> 
> Fpsync is a companion script that uses fpart under the hood to parallelize
> rsync(1) or cpio(1) jobs, making it a simple but powerful data migration tool.
> Those jobs can be run either locally or remotely (using SSH). Fpsync is often
> used by researchers and cloud providers where lots of data need to be moved and
> clusters are available to speed up transfers.
> 
> Q1 2022 Status
> 
> Both tools continued to evolve and saw several bugs fixed; see the changelog.
> 
> Also, a user reported a major bug regarding our fts(3) implementation, which
> ignores readdir(3) errors. I have reported the bug in our Bugzilla:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262038
> 
> It should be merged soon (hopefully).
> 
> Last but not least, fpart has been referenced in the French Government’s 'SILL'
> .
> 
> Contributing
> 
> If you are interested in contributing, have a look at the TODO list.
> 
> Any contribution is welcome, more especially in the field of unit testing.
> 

From nobody Sat Jun 11 19:37:03 2022
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 D41B485EF93;
	Sat, 11 Jun 2022 19:37:21 +0000 (UTC)
	(envelope-from phascolarctos@protonmail.ch)
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits)
	 client-signature RSA-PSS (4096 bits))
	(Client CN "protonmail.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LL7Q90K0jz4lj9;
	Sat, 11 Jun 2022 19:37:21 +0000 (UTC)
	(envelope-from phascolarctos@protonmail.ch)
Date: Sat, 11 Jun 2022 19:37:03 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch;
	s=protonmail3; t=1654976233; x=1655235433;
	bh=TiAlbD/e9tmk3zY9lWJZCbi1UQxXEX+UQ+QP1gfi6Ug=;
	h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
	 References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
	 Feedback-ID:Message-ID;
	b=OPOB4PfPlqe27KlUSCckjVWGTMb2NsFIP+Z4aD3uvr3LhAo6W0A8UtpwA6bpRswd/
	 Zf6X2FbhrQQ+wQJFHCNN7KfUxJOSVuouunkHrGTchTJ8AEP+fwEn9Bc1rZkPaJMyd0
	 EDYNaKrGA8I3IrSQmBJR7B02vjvFL1qxJ0oZRnvuwWje/OM756gfTowgZu2MuMAeKy
	 LeAEs58TJOM9DjtzuYOa5r6sd7vqtrgflWdlGi5nCCz0Zh8cOZnhpk8ejFQkOLj/ic
	 pBsgwcf4St6p6lIKltjwWKPJMPFFN4VMTCg39W0ciCTrCnmK7TgiO/2xIwA1F/fHKT
	 WuhwWTct3dchw==
To: Dmitry Salychev 
From: Lorenzo Salvadore 
Cc: Lorenzo Salvadore , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org
Reply-To: Lorenzo Salvadore 
Subject: Re: FreeBSD Quarterly Status Report First Quarter 2022
Message-ID: 
In-Reply-To: 
References:  
Feedback-ID: 8540510:user:proton
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-Queue-Id: 4LL7Q90K0jz4lj9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protonmail.ch header.s=protonmail3 header.b=OPOB4PfP;
	dmarc=pass (policy=quarantine) header.from=protonmail.ch;
	spf=pass (mx1.freebsd.org: domain of phascolarctos@protonmail.ch designates 185.70.40.133 as permitted sender) smtp.mailfrom=phascolarctos@protonmail.ch
X-Spamd-Result: default: False [-3.25 / 15.00];
	 ARC_NA(0.00)[];
	 HAS_REPLYTO(0.00)[phascolarctos@protonmail.ch];
	 R_DKIM_ALLOW(-0.20)[protonmail.ch:s=protonmail3];
	 REPLYTO_EQ_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_MEDIUM(-0.29)[-0.289];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[protonmail.ch:+];
	 DMARC_POLICY_ALLOW(-0.50)[protonmail.ch,quarantine];
	 NEURAL_HAM_SHORT(-0.96)[-0.962];
	 MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

------- Original Message -------
On Saturday, June 11th, 2022 at 21:04, Dmitry Salychev  wro=
te:


>
>
> Hi,
>
> So, you didn't like initial DPAA2 support :(
>

Of course we like it, but unfortunately, this quarter has been very difficu=
lt for
the quarterly team and we had many errors. In that case, I made a typo in
the new automatic tools and the Architectures section disappeared. I counte=
d
reports, but another typo in another report made me count it twice so I did=
 not
notice that yours was missing.

I am fixing the issue and your report will soon appear on the website.

I am very sorry.

Lorenzo Salvadore

From nobody Sat Jun 11 20:30:39 2022
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 3627683ABF1;
	Sat, 11 Jun 2022 20:30:50 +0000 (UTC)
	(envelope-from phascolarctos@protonmail.ch)
Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131])
	(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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LL8bs4PRVz4yCn;
	Sat, 11 Jun 2022 20:30:49 +0000 (UTC)
	(envelope-from phascolarctos@protonmail.ch)
Date: Sat, 11 Jun 2022 20:30:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch;
	s=protonmail3; t=1654979447; x=1655238647;
	bh=ivPv3DcTASkmxOo/7fEWn+GVM/tuDu/uTdrloGYzYMg=;
	h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
	 References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
	 Feedback-ID:Message-ID;
	b=LeVyvD73FNkNlSz6KXxAvBuIxwQgOmRlrvgl/WNqsVO/PWr6WajyMBS/dPc4cHtY4
	 BEWIUG39ul8zPQFNXKk46h6Sdm0i3j1DTu9ax9girIU4wp/lLCWbx+paZTgUyduK33
	 kTRKiprqEFvT4uwTHpvvwPUh2HjsvQx2hwKLX5NMx4ekKcO/obG9H7w/GFvvE26Zuw
	 8g8xt4uf+jaiSBhIqHFmj/ZnFt/kBWR8RrMr/si1M3S3IgmFbUBYzsWyt1kU9k74LZ
	 nCr01SXOnLnHHLGwYCJITD9GDX6kauO57Itmf3MsEO8QSTy1zFoFChV5Tf+D4xHyKG
	 r+SzdoufAWZng==
To: Dmitry Salychev 
From: Lorenzo Salvadore 
Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org
Reply-To: Lorenzo Salvadore 
Subject: Re: FreeBSD Quarterly Status Report First Quarter 2022
Message-ID: 
In-Reply-To: 
References:   
Feedback-ID: 8540510:user:proton
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-Queue-Id: 4LL8bs4PRVz4yCn
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protonmail.ch header.s=protonmail3 header.b=LeVyvD73;
	dmarc=pass (policy=quarantine) header.from=protonmail.ch;
	spf=pass (mx1.freebsd.org: domain of phascolarctos@protonmail.ch designates 185.70.40.131 as permitted sender) smtp.mailfrom=phascolarctos@protonmail.ch
X-Spamd-Result: default: False [-3.48 / 15.00];
	 ARC_NA(0.00)[];
	 HAS_REPLYTO(0.00)[phascolarctos@protonmail.ch];
	 R_DKIM_ALLOW(-0.20)[protonmail.ch:s=protonmail3];
	 REPLYTO_EQ_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_MEDIUM(-0.49)[-0.491];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[protonmail.ch:+];
	 DMARC_POLICY_ALLOW(-0.50)[protonmail.ch,quarantine];
	 NEURAL_HAM_SHORT(-0.99)[-0.993];
	 MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers,freebsd-stable];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

------- Original Message -------
On Saturday, June 11th, 2022 at 21:37, Lorenzo Salvadore  wrote:


>
>
> ------- Original Message -------
> On Saturday, June 11th, 2022 at 21:04, Dmitry Salychev dsl@mcusim.org wro=
te:
>
>
>
> > Hi,
> >
> > So, you didn't like initial DPAA2 support :(
>
>
> Of course we like it, but unfortunately, this quarter has been very diffi=
cult for
> the quarterly team and we had many errors. In that case, I made a typo in
> the new automatic tools and the Architectures section disappeared. I coun=
ted
> reports, but another typo in another report made me count it twice so I d=
id not
> notice that yours was missing.
>
> I am fixing the issue and your report will soon appear on the website.
>
> I am very sorry.

Your report is now online:
https://www.freebsd.org/status/report-2022-01-2022-03/#_nxp_dpaa2_support

Sorry again for the mistake,

Lorenzo Salvadore

From nobody Sat Jun 11 20:45:38 2022
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 3F4BF83F355;
	Sat, 11 Jun 2022 20:45:42 +0000 (UTC)
	(envelope-from dsl@mcusim.org)
Received: from mcusim.org (mcusim.org [176.58.93.53])
	(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 4LL8x13z8qz53Vt;
	Sat, 11 Jun 2022 20:45:41 +0000 (UTC)
	(envelope-from dsl@mcusim.org)
Received: from peasant.tower.home (unknown [83.28.234.61])
	(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 mcusim.org (Postfix) with ESMTPSA id 229BA6B9DA;
	Sat, 11 Jun 2022 22:45:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mcusim.org;
	s=default; t=1654980340;
	bh=gy+pJkmiJ4sV4iMkCd1JkndQeifWsGOMPYp/Lwch2qE=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To;
	b=wbezLH9zrbEmh0uPHoMylvFk9MzaWhjnFTf5nFWHp5yDJuNQhMrEqk+rSMYXYrXx0
	 gOYCIL17KOo8oaHpGN11tJ7Vj2lFafGG0Ya1KDzWvs/aWCB/z4o/FMs80lOKpaZY8i
	 pb6YCH4YnMh+SNUlPdEfP6QmCi+1SheDgDfD/IiI=
Date: Sat, 11 Jun 2022 22:45:38 +0200
From: Dmitry Salychev 
To: Lorenzo Salvadore 
Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org,
	freebsd-stable@freebsd.org
Subject: Re: FreeBSD Quarterly Status Report First Quarter 2022
Message-ID: 
References: 
 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4LL8x13z8qz53Vt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=mcusim.org header.s=default header.b=wbezLH9z;
	dmarc=pass (policy=reject) header.from=mcusim.org;
	spf=pass (mx1.freebsd.org: domain of dsl@mcusim.org designates 176.58.93.53 as permitted sender) smtp.mailfrom=dsl@mcusim.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[mcusim.org:s=default];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[mcusim.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[mcusim.org,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers,freebsd-stable];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:36236, ipnet:176.58.93.0/24, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[83.28.234.61:received]
X-ThisMailContainsUnwantedMimeParts: N


No problem and thanks!

Regards,
Dmitry

On Sat, Jun 11, 2022 at 08:30:39PM +0000, Lorenzo Salvadore wrote:
> ------- Original Message -------
> On Saturday, June 11th, 2022 at 21:37, Lorenzo Salvadore  wrote:
> 
> 
> >
> >
> > ------- Original Message -------
> > On Saturday, June 11th, 2022 at 21:04, Dmitry Salychev dsl@mcusim.org wrote:
> >
> >
> >
> > > Hi,
> > >
> > > So, you didn't like initial DPAA2 support :(
> >
> >
> > Of course we like it, but unfortunately, this quarter has been very difficult for
> > the quarterly team and we had many errors. In that case, I made a typo in
> > the new automatic tools and the Architectures section disappeared. I counted
> > reports, but another typo in another report made me count it twice so I did not
> > notice that yours was missing.
> >
> > I am fixing the issue and your report will soon appear on the website.
> >
> > I am very sorry.
> 
> Your report is now online:
> https://www.freebsd.org/status/report-2022-01-2022-03/#_nxp_dpaa2_support
> 
> Sorry again for the mistake,
> 
> Lorenzo Salvadore

From nobody Sun Jun 12 08:02:03 2022
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 7886B850119
	for ; Sun, 12 Jun 2022 08:02:17 +0000 (UTC)
	(envelope-from ish@amail.plala.or.jp)
Received: from msc11.plala.or.jp (msc11.plala.or.jp [IPv6:2400:7800:0:502e::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 4LLRxg4jPVz4SYt
	for ; Sun, 12 Jun 2022 08:02:15 +0000 (UTC)
	(envelope-from ish@amail.plala.or.jp)
Received: from localhost ([2400:4050:9320:7a00::8]) by msc11.plala.or.jp
          with ESMTP
          id <20220612080205.RJNH31769.msc11.plala.or.jp@localhost>
          for ;
          Sun, 12 Jun 2022 17:02:05 +0900
Date: Sun, 12 Jun 2022 17:02:03 +0900 (JST)
Message-Id: <20220612.170203.1570364119618551543.ish@amail.plala.or.jp>
To: freebsd-current@freebsd.org
Subject: Re: dmesg: ACPI Warning: Firmware issue warning spaming
From: Masachika ISHIZUKA 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.8 on Emacs 28.1
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-VirusScan: Outbound; mvir-ac11; Sun, 12 Jun 2022 17:02:05 +0900
X-Rspamd-Queue-Id: 4LLRxg4jPVz4SYt
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of ish@amail.plala.or.jp designates 2400:7800:0:502e::21 as permitted sender) smtp.mailfrom=ish@amail.plala.or.jp
X-Spamd-Result: default: False [-1.39 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	 FROM_HAS_DN(0.00)[];
	 MV_CASE(0.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 DMARC_NA(0.00)[plala.or.jp];
	 R_SPF_ALLOW(-0.20)[+ip6:2400:7800:0:502e::/60];
	 NEURAL_HAM_SHORT(-0.70)[-0.695];
	 MID_CONTAINS_FROM(1.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:4713, ipnet:2400:7800::/32, country:JP];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

> I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings:
> ---
> ACPI Warning: Firmware issue: Excessive sleep time (0x0000000000000010 ms >
> 10 ms) in ACPI Control Method (20220331/exsystem-347)
> ---
> Is there a way to silence it?

  Hi.
  
  I think these messages are only informational and make them easier
to miss more important messages.
  My old machine's ACPI bios is worked at 20msec, so I did patch to
/usr/src/sys/contrib/dev/acpica/components/executer/exsystem.c like below.

% diff -ruN exsystem.c.orig exsystem.c
--- exsystem.c.orig     2022-04-03 07:18:33.339997000 +0900
+++ exsystem.c  2022-04-26 19:13:06.814856000 +0900
@@ -342,10 +342,10 @@
      * Warn users about excessive sleep times, so ASL code can be improved to
      * use polling or similar techniques.
      */
-    if (HowLongMs > 10)
+    if (HowLongMs > 20)
     {
        ACPI_WARNING ((AE_INFO,
-            "Firmware issue: Excessive sleep time (0x%8.8X%8.8X ms > 10 ms)"
+            "Firmware issue: Excessive sleep time (0x%8.8X%8.8X ms > 20 ms)"
             " in ACPI Control Method",
             ACPI_FORMAT_UINT64 (HowLongMs)));
     }
-- 
Masachika ISHIZUKA

From nobody Sun Jun 12 15:08:48 2022
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 EEBC483D9EF
	for ; Sun, 12 Jun 2022 15:08:56 +0000 (UTC)
	(envelope-from imb@protected-networks.net)
Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8])
	(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 "mail.protected-networks.net", Issuer "R3" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LLdPz5hK7z3pRx;
	Sun, 12 Jun 2022 15:08:55 +0000 (UTC)
	(envelope-from imb@protected-networks.net)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=
	protected-networks.net; h=content-transfer-encoding:content-type
	:content-type:subject:subject:from:from:content-language
	:user-agent:mime-version:date:date:message-id; s=201508; t=
	1655046528; bh=7u8Ldm/+zyA8AuUtDtMsSb8I6bmcoPEqP0REGlULYKY=; b=W
	dAauHuiPWfhisT2qJJhEwNXwo7lsP9UNrAMDUYqZI/jfMIrlKAeoPw6n+HSz3KXJ
	U/htJs8ZH292GjVOhyg12ydLIfemui/9FjRPzVjs98AZbijZ5R8gMOoVIwY2JbaL
	SQdyxLpwOJsPXuDG+c1fQxNxIKUt9aKLwhmWPu1OCc=
Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(Client did not present a certificate)
	(Authenticated sender: imb@mail.protected-networks.net)
	by mail.protected-networks.net (Postfix) with ESMTPSA id 8349D5B3EC;
	Sun, 12 Jun 2022 11:08:48 -0400 (EDT)
Message-ID: 
Date: Sun, 12 Jun 2022 11:08:48 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Content-Language: en-NZ
To: delphij@freebsd.org
From: Michael Butler 
Subject: commit 695052e is incomplete
Cc: freebsd-current 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LLdPz5hK7z3pRx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protected-networks.net header.s=201508 header.b="W dAauHu";
	dmarc=pass (policy=reject) header.from=protected-networks.net;
	spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 2001:470:8d59:1::8 as permitted sender) smtp.mailfrom=imb@protected-networks.net
X-Spamd-Result: default: False [-4.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[protected-networks.net:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

After 695052e, the directories compat, dtrace, engines, flua, i18n and 
libxo now get created under /usr. This is one level higher than they 
should be.

The fix appears to be something like ..

diff --git a/etc/mtree/BSD.usr.dist b/etc/mtree/BSD.usr.dist
index 9f934976b77..95a711a4418 100644
--- a/etc/mtree/BSD.usr.dist
+++ b/etc/mtree/BSD.usr.dist
@@ -59,7 +59,6 @@
                      ..
                  ..
                  share
-                    ..
                  ..
              ..
          ..


From nobody Sun Jun 12 15:13:18 2022
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 6AD9083F294
	for ; Sun, 12 Jun 2022 15:13:30 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LLdWF4QV2z3qqx
	for ; Sun, 12 Jun 2022 15:13:29 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vk1-xa32.google.com with SMTP id g15so1628600vkm.0
        for ; Sun, 12 Jun 2022 08:13:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=fxkKAEYPwepy+rzq35ozWqdUeTKAHY94+RKaXXnNi1g=;
        b=LuEebYp35RednWir0hTHC1hiTrBJJainNrqQx+Z/zVqhWuMzWMmatHX441VyHr053F
         qTr4diiCaHt2DHt9xIBXGJORu4YYCibE4Bnd6vAr8IW8pahxa/WCtLUV0kc0PmCDm53e
         agRi1lOkxXIKQVjxX16vfXDM9Vjxx7nWRvOi07D0cona12LxfKVlo0sTZt2p262282Ks
         1iD6j0dNwVVLqkiQB36pCUeLyrow/jBeODnd+tXuL4afNhFSGsg5q6GxozOsKUtIWyu6
         JLd0mYOCiJ0j9sDgQHiozUYdj0G/uO+96h/E1b1dNUJ8QR7mJj269VduG04XcFhnMj/9
         KlFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=fxkKAEYPwepy+rzq35ozWqdUeTKAHY94+RKaXXnNi1g=;
        b=Fj8Z1vETi0EUMRK/xvjb0vByEudx98OqBYiCgo54mtKqqDfKMokNH34kUgygECYTPm
         YaL9Umb4R2otYgIQBjXv4yqYe0+iUQcxH9eh2BhIPGUMoj3j+Alq0uu3wX5sZVFmudQR
         cxuclOe8sSGAsy+obCsDz2q4fZ9aZFUP9Fb7v0F9CIlBi8bC1ESdhbH6p7kxWiVrH5Ex
         AXc/gdOzTYMKR9g80o/schcD+Rt1PJpZqucpw1yCKITzvuuBRTv62/4HaQRDgLhuSX29
         47Y+n7ALsJ2UrRjO29fTlfb60wczLPtbG49J5q5zbr5zMv/HO/IJ3Bav0WAtqan2A9wQ
         Dt9Q==
X-Gm-Message-State: AOAM532tg2OiCVKuh/XGuTRLfQTtUOBlbepP2392NEAPAaOGzm8TIBEh
	12oKIol33wfF6z44+mG88NK6n+gfI54RCiS3p4KVuA==
X-Google-Smtp-Source: ABdhPJy1sk4c+Swm40MlsccBFPk9Zrt2jrAjbvp+jgKX7g+wfCaVJecQfUoKAGxgOYNvoA4s1/RmuYtRZ/ESpUxWR2E=
X-Received: by 2002:a1f:18d6:0:b0:35d:7d52:fbbe with SMTP id
 205-20020a1f18d6000000b0035d7d52fbbemr18238137vky.32.1655046809051; Sun, 12
 Jun 2022 08:13:29 -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: Sun, 12 Jun 2022 09:13:18 -0600
Message-ID: 
Subject: Re: commit 695052e is incomplete
To: Michael Butler 
Cc: Xin LI , freebsd-current 
Content-Type: multipart/alternative; boundary="00000000000024018005e1419d90"
X-Rspamd-Queue-Id: 4LLdWF4QV2z3qqx
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=LuEebYp3;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a32) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [1.44 / 15.00];
	 RCVD_TLS_ALL(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 NEURAL_SPAM_MEDIUM(1.00)[0.998];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_SPAM_LONG(1.00)[0.999];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a32:from];
	 NEURAL_HAM_SHORT(-0.56)[-0.556];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_COUNT_TWO(0.00)[2];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000024018005e1419d90
Content-Type: text/plain; charset="UTF-8"

This was just fixed minutes ago... please update and confirm the fix is
good.

Warner

On Sun, Jun 12, 2022, 9:09 AM Michael Butler 
wrote:

> After 695052e, the directories compat, dtrace, engines, flua, i18n and
> libxo now get created under /usr. This is one level higher than they
> should be.
>
> The fix appears to be something like ..
>
> diff --git a/etc/mtree/BSD.usr.dist b/etc/mtree/BSD.usr.dist
> index 9f934976b77..95a711a4418 100644
> --- a/etc/mtree/BSD.usr.dist
> +++ b/etc/mtree/BSD.usr.dist
> @@ -59,7 +59,6 @@
>                       ..
>                   ..
>                   share
> -                    ..
>                   ..
>               ..
>           ..
>
>
>

--00000000000024018005e1419d90
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This was just fixed minutes ago... please update and conf=
irm the fix is good.

Warner=C2=
=A0

On Sun, Jun 12, 2022, 9:09 AM Michael Butler <imb@protected-networks.net> wrote:
<=
/div>
After 695052e, the directories compat, =
dtrace, engines, flua, i18n and 

libxo now get created under /usr. This is one level higher than they 

should be.



The fix appears to be something like ..



diff --git a/etc/mtree/BSD.usr.dist b/etc/mtree/BSD.usr.dist

index 9f934976b77..95a711a4418 100644

--- a/etc/mtree/BSD.usr.dist

+++ b/etc/mtree/BSD.usr.dist

@@ -59,7 +59,6 @@

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 ..

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ..

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 share

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ..
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ..

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ..

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ..








--00000000000024018005e1419d90--

From nobody Sun Jun 12 15:18:21 2022
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 ED0938415AB
	for ; Sun, 12 Jun 2022 15:18:22 +0000 (UTC)
	(envelope-from matteo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LLdct68jvz3tJ8;
	Sun, 12 Jun 2022 15:18:22 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1655047102;
	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=F/slmwwIoG1KIo+OhJwAm+7CBWZfCGH1rb7GCnVQBPA=;
	b=tzn6YuWYgY8sby/YdtQ3FECNDyQLQKNe2nfDNkQRW7qlifs6K0+e201qPV2mIy4hpUBCsM
	DllelB3U7GR7i3vVLI2lXEgwGYezCIIQ/2T1VwLNwc22pbXhuXj5pSh+03Hgdnfwj9g6gq
	SRDqUnu3V1lpThWshOEm9OME8K5CfMBEaFX4eULQNEJeEaz0tfSYC2sed8rMBRJBM0HINZ
	yXEGCvaRg4NsX7FW84tPOvLd5k9ZHaVYIJqQjCYv3xilJ+n2ViqBszev37UAWq5sXOzO0f
	b/pJA+mra+A8APCpGfKZFG2dKGORRLTeoRdORhG7UQMAq0Q4aNVy7bWCTEFccQ==
Received: from ubertino.local (unknown [IPv6:2601:19b:4400:1779::1008])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: matteo/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 8AF5AF4F9;
	Sun, 12 Jun 2022 15:18:22 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Date: Sun, 12 Jun 2022 11:18:21 -0400
From: Matteo Riondato 
To: Warner Losh 
Cc: FreeBSD Current 
Subject: Re: nvme INVALID_FIELD in dmesg.boot
Message-ID: <20220612151821.3a2fkfsqlr7ro7gf@ubertino.local>
X-PGP-Key: http://rionda.to/files/matteogpg.asc
References: <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu>
 
 <20220526001715.4ffee96a@ws1.wobblyboot.net>
 
 <20220525153920.sxzi7fhsfzv6yidv@ubertino.local>
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="n3rvye4kcg25rgka"
Content-Disposition: inline
In-Reply-To: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655047102;
	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=F/slmwwIoG1KIo+OhJwAm+7CBWZfCGH1rb7GCnVQBPA=;
	b=LuAGVAt5AOrB7Ah9FjWoiK0RqtEwtpK6jvi85DrWHzvl7bPINhBn0PYzEorydpnO625bCi
	6OZwVCSomolHeQx2rnomVuWFD+8zuEYJEMaW6YFwOECNoXK+sU51X3PRvd1qHWXZ8qDkUY
	UZ/ME4VJUzfqeta7eCqYJ7g7wRUfRfdFkO3OrE8uz9uY1tWkoSsF4qDUmAwKbkNT9kwY/P
	Ml6avFcPq/RmRhFOZ7md1sIDtK+GGsJnmJ7CSZQkqUEMXQOw1eQyPozVKiJch/Es0x3j3s
	6NDq+adBasHWNTc29dD+KrMdsAY8c4i3lRHScc4xfX4yqOQP/F2NJ9aVN/EtRg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655047102; a=rsa-sha256; cv=none;
	b=mz4NL7LkIYod10EVkucwK2v8VRmiysGRBFir8Y3hRV8Eai7fKjDykAB1Qu9JyZOvgeVDtv
	pqsQlDzUJtWy5Z27pUWJLvHuFLLux/ApkPiT8bHNqCWzF9/03wBew5Nyu0JETuSCYC65N/
	37dt1isI5FwGTI8a4EWTg190RTlrqUTnd+5OUdhh5Xir0RcoxCFQFUNqEkfQWn9xxkrhrY
	PRrXzQfRklApp+57cCSUZqcnmv4nH2J9V3sJMi+8exctModKxbdnreSA1ESXHSCN/F4J04
	CaJmEAkFWDwEBUOnJLhbSwtvo/y+nuaZsOgZBbwza8pwqQMfnF2ciZn84iduLg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--n3rvye4kcg25rgka
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-05-25 at 11:49 EDT, Warner Losh  wrote:

>On Wed, May 25, 2022 at 9:39 AM Matteo Riondato  wrote:
>
>> On 2022-05-25 at 11:29 EDT, Warner Losh  wrote:=20
>> >=20
>> >SET FEATURES (opcode 9) feature 0xb is indeed async event=20
>> >configuration.=20
>> >0x31f is:=20
>> >SMART WARNING for available spares (0x1)=20
>> >SMART warning for temperature (0x2)=20
>> >SMART WARNING for device reliability (0x4)=20
>> >SMART WARNING for being read only (0x8)=20
>> >SMART WARNING for volatile memory backup (0x10)=20
>> >Namespace attribute change events (0x100)=20
>> >Firmware activation events (0x200)=20
>> >=20
>> >I wonder which one of those it doesn't like. My reading of the standard=
=20
>> >suggests that those should always be supported for a 1.2 and later=20
>> >drive... Thought maybe with the possible exception of the volatile=20
>> >memory backup, so let me do some digging here...=20
>> >=20
>> >We can get the last two items from OAES field of the controller=20
>> >identificaiton data. This is bytes 95:92, which if I'm counting right=
=20
>> >is the last word on the 040: line in the nvmecontrol identify -x nvmeX=
=20
>> >command:=20
>> >=20
>> >040: 4e474e4b 30303150 000cca07 00230000 00010200 005b8d80 0030d400=20
>> >00000100
>>
>> >-----------------------------------------------------------------------=
-----------------------------------^^^^^^^^^
>>
>> On my system:
>>
>> 040: 31564456 30373130 5cd2e400 00000500 00010200 001e8480 002dc6c0=20
>> 00000200
>>
>
>Yea, 0x200 and we send 0x300, so maybe that's the cause of the message....

With the patch you sent, the message is gone from dmesg. Thank you.
I didn't check (because I don't know how), but I assume that everything=20
else stayed the same.

If, as you said above, these features should be supported per ithe=20
standard, but aren't, perhaps it would be worth printing a warning=20
(maybe under verbose boot)? But maybe it is too much hassle.

Thanks anyway, and perhaps you may commit the patch you sent me.

Thanks,
Matteo

--n3rvye4kcg25rgka
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmKmA68TGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVATd6D/wMChf63H5IFXmib1M/bS8j9H6hBt/P
+/eW+dBLrOztbKJunCg8Ny3MgtnttGK+RyzmIYRCJPS+bFMWBjLsLczH19BDcBXw
OyJWdADZBtTPelnydC+Z3hYJnnl1WgklZRsHoJvkls+q2JdBKS0COMf7v3tIces1
nXPQkL0MJajYs9NE/t1VCa7y7IWP0sHnnzPZZAb+488ksdY9LZ5TwLMj1hhMwWtK
vciApaq4Tfgl+BLY3TuaJzA/rZPYujB2vaPQCC6s4w2WHGzYfdaRbvVUwlFjGGwV
QMTKiwsld6LjbFYkrpAodXCFwQO2ax0Sg8PnFSQwFDzSVO6fgFm31DFQK9rZLiRP
6fiCNa6wvE/dSf48BSmeZRgtYmyzS2BRByD/aOgw4dB9I+SKXYvlZBLCHLasmpmp
G54IQiAKsEZw1wm6vLdvkfk4Hqt7/lF5PKitOLTOKh2Qgp7E/7w6gzzKqJbTNoAM
Bj6xSKToLf4B0GyI7B1h1xpuu6stzx2E6kGYVQJDWx3x+IpYzY3ejT4NlY4IYGVL
FEgfFSibJ6uj+HRL9ljHSsQSeTZ/9LGMN9GB0S3HTA743WkL73ZPz/uJMQljxWbK
AQQD1b4/5PtAb3hyVOcklfxGuxHcrB3fvOMwDGmGpDGGR8w8/azw/SGd+0ZJLdrc
AocQp+r8ZhiDaQ==
=rGdl
-----END PGP SIGNATURE-----

--n3rvye4kcg25rgka--

From nobody Sun Jun 12 15:39:28 2022
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 750E38451A1
	for ; Sun, 12 Jun 2022 15:39:42 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LLf5V2fxBz4RnG
	for ; Sun, 12 Jun 2022 15:39:42 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1655048382;
	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=WGc3xSpLF6gHGjK9keU/4+wvuDtCZJhMfCZ6hl5Nkjo=;
	b=nHPeTJ+ST8zJe6bP4rbNyRyD28REZJ+TmmABf5HeYpn4iinj7zA+wXDYc5lNMNFi6yD0vv
	R67kqmX7ZS50pQYlwEmNdBYIdjcVS5aFfMWiQztCDf4oL5GchHmfu5fRzzP+3XRVurC6Aw
	hUgGXNB96BuqCMj0nenALqCguieaAWRfuPACFEws9NryJxqTggb+CyO5iw7Z4DkZTHsmUW
	GoGXIojzaC3rweQqZmUF2Ob0xrdnBwoyWwyPTB2iJKL6rKb7ty/swDX2ysWWEpeaM5Zn1X
	gXHHKrqfmXy2ZuYL411VDM7+Sb9QgZUlMV+EzHi8t2Dqui3LtC7MB9eaQQxc1A==
Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 34A48209A4
	for ; Sun, 12 Jun 2022 15:39:42 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-lf1-f45.google.com with SMTP id i29so5418332lfp.3
        for ; Sun, 12 Jun 2022 08:39:42 -0700 (PDT)
X-Gm-Message-State: AOAM532/STM0Yn3Mf6oByB7lTG2ArgTdjZPO7vBsytRfQeWOlwPh33Th
	hqLpXuUccUvWhu1jBoZYuXvH926n49Hhh0hUXBI=
X-Google-Smtp-Source: ABdhPJyg9z736AVHwhvnHih95331AtHex44kwh3TkXzkFks18x0U/pKuvZL1DlqTHPbIEiuTgvIFJvPw9JvI8W4ygZM=
X-Received: by 2002:a05:6512:33ca:b0:479:40e9:114 with SMTP id
 d10-20020a05651233ca00b0047940e90114mr22731727lfg.89.1655048380886; Sun, 12
 Jun 2022 08:39: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: 
 <20220612.170203.1570364119618551543.ish@amail.plala.or.jp>
In-Reply-To: <20220612.170203.1570364119618551543.ish@amail.plala.or.jp>
From: Nuno Teixeira 
Date: Sun, 12 Jun 2022 16:39:28 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: dmesg: ACPI Warning: Firmware issue warning spaming
To: Masachika ISHIZUKA 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000d436f105e141fa07"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655048382;
	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=WGc3xSpLF6gHGjK9keU/4+wvuDtCZJhMfCZ6hl5Nkjo=;
	b=Mwl19N/hCOJkAxAPlJd3CYqEBSg8SPfdePr/crpPIuxPWEXn5rfUzokAwjkrt88H4lQJiR
	ltHO+ysHJXDmez588+RcorUpsR4JJHWgxhFN5oGlw8yEgUKimdzNuW6T5aHoGPPyZ4ruP0
	HigKa61QvL0UBcivkU4Enl4wET4VhTNmGtAUbFzqEGGf1ZWIOhEjn2WnuHLDaX+vibgHNF
	UdHxLyYHHwj6xjPQv5ZlRzFWMx8rgNhl/XmChNnIUtmGYXNAfNb0z1b/jdSVpK4WvUjWhC
	Q9dlXFE4LisIQkWOJ3ZPxq/QIKX3tF4QE0KILtUSoVOHJHLu3EZ9hnSrZXZ5/g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655048382; a=rsa-sha256; cv=none;
	b=TisdHJD2tYloSjGGf3SRxjQDg6QT/QOtkL+psxXZhCmDXysrNbhdawTF5mMYaIhHvSUo3q
	oSEe1pU+COsQF8gCZMGXXc/ZsJGN1HvdstiBuY5jlBsx/hbdqKRHn9vGGsscHo3ORaxanO
	XTuDZK3KTrp1oCT2b+CEAB+5VwSD6LvVl+5VZ1+QoNuUafSgqIODJao6sC9caanzxINigS
	6n0M4bes67XUycS0V3gDP1o618NIACspvR7RNuZzETLJ14WW8GBuTN1Cu2krrHrQpmSysT
	WFDjwuC+0CwJU73gpgFHytOJVY+VgH2OlajoY9cjPD/zb8IryGzKWySAu+b57w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000d436f105e141fa07
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

What do you think opening a review about this fix/tweak to stop this
spamming that blinds dmesg?

Masachika ISHIZUKA  escreveu no dia domingo,
12/06/2022 =C3=A0(s) 09:03:

> > I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg
> warnings:
> > ---
> > ACPI Warning: Firmware issue: Excessive sleep time (0x0000000000000010
> ms >
> > 10 ms) in ACPI Control Method (20220331/exsystem-347)
> > ---
> > Is there a way to silence it?
>
>   Hi.
>
>   I think these messages are only informational and make them easier
> to miss more important messages.
>   My old machine's ACPI bios is worked at 20msec, so I did patch to
> /usr/src/sys/contrib/dev/acpica/components/executer/exsystem.c like below=
.
>
> % diff -ruN exsystem.c.orig exsystem.c
> --- exsystem.c.orig     2022-04-03 07:18:33.339997000 +0900
> +++ exsystem.c  2022-04-26 19:13:06.814856000 +0900
> @@ -342,10 +342,10 @@
>       * Warn users about excessive sleep times, so ASL code can be
> improved to
>       * use polling or similar techniques.
>       */
> -    if (HowLongMs > 10)
> +    if (HowLongMs > 20)
>      {
>         ACPI_WARNING ((AE_INFO,
> -            "Firmware issue: Excessive sleep time (0x%8.8X%8.8X ms > 10
> ms)"
> +            "Firmware issue: Excessive sleep time (0x%8.8X%8.8X ms > 20
> ms)"
>              " in ACPI Control Method",
>              ACPI_FORMAT_UINT64 (HowLongMs)));
>      }
> --
> Masachika ISHIZUKA
>
>

--000000000000d436f105e141fa07
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


What do you think opening a review about this fix/tweak to=
 stop this spamming that blinds dmesg?

Masachika ISHIZUKA <ish@amail.plala.or.jp> escreveu no di=
a domingo, 12/06/2022 =C3=A0(s) 09:03:
> I'm running CURRENT 8d95f500521 and I'm=
 receiving loads of dmesg warnings:

> ---

> ACPI Warning: Firmware issue: Excessive sleep time (0x0000000000000010=
 ms >

> 10 ms) in ACPI Control Method (20220331/exsystem-347)

> ---

> Is there a way to silence it?



=C2=A0 Hi.



=C2=A0 I think these messages are only informational and make them easier
to miss more important messages.

=C2=A0 My old machine's ACPI bios is worked at 20msec, so I did patch t=
o

/usr/src/sys/contrib/dev/acpica/components/executer/exsystem.c like below.<=
br>


% diff -ruN exsystem.c.orig exsystem.c

--- exsystem.c.orig=C2=A0 =C2=A0 =C2=A02022-04-03 07:18:33.339997000 +0900<=
br>
+++ exsystem.c=C2=A0 2022-04-26 19:13:06.814856000 +0900

@@ -342,10 +342,10 @@

=C2=A0 =C2=A0 =C2=A0 * Warn users about excessive sleep times, so ASL code =
can be improved to

=C2=A0 =C2=A0 =C2=A0 * use polling or similar techniques.

=C2=A0 =C2=A0 =C2=A0 */

-=C2=A0 =C2=A0 if (HowLongMs > 10)

+=C2=A0 =C2=A0 if (HowLongMs > 20)

=C2=A0 =C2=A0 =C2=A0{

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ACPI_WARNING ((AE_INFO,

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Firmware issue: Excessive =
sleep time (0x%8.8X%8.8X ms > 10 ms)"

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Firmware issue: Excessive =
sleep time (0x%8.8X%8.8X ms > 20 ms)"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0" in ACPI Control Meth=
od",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACPI_FORMAT_UINT64 (HowLong=
Ms)));

=C2=A0 =C2=A0 =C2=A0}

-- 

Masachika ISHIZUKA






--000000000000d436f105e141fa07--

From nobody Sun Jun 12 16:16:55 2022
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 2895D85310A
	for ; Sun, 12 Jun 2022 16:17:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LLfwf0XVRz4X3N
	for ; Sun, 12 Jun 2022 16:17:06 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655050618; bh=VvCi33kt9eAaWJ2vYDiktmBjm17lo2mDoIKM9h4hf4k=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=hUWs1ZHOs8h2b+FruMWgbDU0Op3A/5k2Kf7P9EaYbVU5kqhEN+i/8sCNHj1U8I/4yW1xaMCuy1VtJRWlzkAroeV6rTEHk0aYqXvQ1DzbH0bicdTpneO2O3fClmzKCUjNZEJh7wf9jIipAKTfZ1scz3+PBHAfW6u5AD0iKtJkbRf/tYCGgApyVFD9Lr/SagY5vig4Hzh07vHDJQqGOb90ZcIQBK3lnk0q/WhyJh+p5Wayfyb2kDImVg2GZfWV6ewarnQ4UdyOHtUIjYeyoS0DGqaZr2bIy8vqQ5Ak18PbYXw0wLSXXKG3XcVmGqk1zjCv3cv7hxd6aCVidHYxNOQS/w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655050618; bh=R2RHj3lGTWIJb6+PMaGKMjtW3mYejT+Lh5GF2lOCvEf=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=EFttIvsllsO76g+Q01lVA/R+fRPK1FFItzhXzljNHZhZcWKdpvGkTFDxY7KpJanT+XZOby5P7KjHnnVkuQuG+mDITEw15x6ZiGSEu1clz0PK+FoFqtAnHDASz1sl7JXwhxFOWEUQcC6uneAw5aWVckRks6jwygOs8N+/BZULJP8p6Q58PmM51GHf81r/TwPjIDBbVb/KP5uuMn6BMnJ+CI6NTHqBxFqZN38g7iwuFnzQt+o5c74ExvWF7P2fp9WIQ5dbOjtgbcI7ISqaIGARnQGoccTetcbX9MCfJHaE90dStvy0QtFjL7+8EC6HCy4RiaAMsIvnD0/n6avxOdEsTA==
X-YMail-OSG: BTqZ6mMVM1mToUlyH4U_mUaykD7lr6hk90v0HwHaygk4IwBksAa4fb_r0psKMRH
 9SGFH_ltScOjbCwMIqtIIGlZmPC3vgD7uLxGOooZW_wZ7qQYIeSII2BFPi8jFaE17YLnQrXCPu7C
 75kBMNXBzGSedaJT1GDLfFlvu1k2YKnKp1N46A3Ag2FdpMLlKX2NTsCtgQPvsanHUNnOX5xJrIRs
 4e0X7MzrEbvIvMB2v.iItxn6CTO14pR.LhBs8qvLnmhQi4w.s0gI2ml68wvVxtZdt5qBkNTB88J1
 7svs8DwLAyumvVM1UizAo6zEXCabWOPB07rI1OaScpDfSAtxpu4ri0qfTHifLOYpsuFCJW0RJGD.
 B1Fz1ZEQAjh85.ugsg4pdj4Vkuo7wOP3kbmtNU.DrMEZ3ONRYBmVAhM1U623DU.ZsM1iLpv3slD.
 ZUf5pfgwdrL_FiXkoAcvOb9Zp1FBCC.a8xj2Qvh3pzQ8GbUnosmKblpvZSiS.XpxWUcB7APVs3zg
 taN.9NQTsFPmLL7pexB5myKS5p753_atQZHpTBKsDMJA9opW59Z3xDuFi4x2lWiekhV7fAn0T4rj
 bNL32V1xYp_MYN1kKiaomO36ZGPRCaxVbF8zeuQx4EWuRkRmM9kqtF0fPrJN.c77taRjv1Lc4gnu
 mQSFj1Gr1O4Hg.2K2trjK2C7PKD7qL0IriSOCCw4HRBtWKfisVK064VEsv_oP4joE.qmmTvydXxt
 HFys.QSO3MPvRMNVAKozwCwiq1xgseHzvS9dBzKY1uIEVc6siWibXMW8aKfewa0GmBqZTL17AVhK
 i1xs3nGNpyb628aVb_SsIklR9aIYxgq7fhrSvEbt0qeOqSwV4oQKlLPwmGE9Yn4yGlheRwwurGzR
 l8qULjbxXYIqOndwR7bqi1kxuE.zDgqwwlpHbwKPw3AkrbOFh8vZqqlU9RL4hmVwg8j0XnCPM_D3
 A5WUSh54ykTBR9dXmM.Oc3LxPRUlAOZd_2bOFzFKJStkqPDiXPi8W7rUO_QYVDVzRtOv1CdrVB8.
 DBuLsqx9OkGoZ6jYbMdEfwOEsTRuJ2yoPdA1re1EaO4sgpPXD6UFgLeesSonFVccLiAPMxw8QVd7
 xVw2BLItQXA7lBqTrQ69YLAniOdE_dBZH1ORE7Jl_4j9PQJ1C0mLSkIJOcrb74PtcDOWrHOu9V5i
 anwq0MnpWt9nLKrBgXFGHTFNSaeWcgXS2WBG8qyv0G1VGI1fsvXzN8b98EH9CWlkTKpxA.otK4QE
 FpyS2MLaWTLYAjYbwzv6SKVs8pAKGbXCTB8MobUdoE_kdaLD8cLlxYtCBOFfZnMtfMk3aogbY_fj
 MFQxqkQcn5I.n1Mdhgf.HFu4s4qYlnVUbXzSerz3jYEE6806GCCApS0drxRZ2aHUlCwkAiEjk9MW
 U4SCyFGDAd_u7FnnMcsvyOg2.o7tGaD6MpG2w4g39QQFdeKpkXzrv.8fEKTw89XGbWhxB9YfBprk
 C1.ee8Ov9gG9dYCiZtYxsG.tpbo2Yio5wmezdwOpzIXndZivuSJOp6fo5.VpgDhkC1p563bfY5Sx
 uGsdZvYrSO9jb.QHGR0WOh1FXtjrlJ7tS97o.aRqTWK4pFfxixN5_V9xgN7llh7tfGUx5sadufwM
 ag8YV7ezKxBrGFi.1_1hpByz8rrBgozrVBTT9dXNlvEN._vL7wY3oVn9jQkwIX75LbdrXmzIaYXY
 ComxMXzG02pafskWjWnW_e9nh1pjJpbC7zfqn234yPfRY4.kuHRjtDxGTImAB5lXOUsemevm2XwY
 CLvRD3WefUwsnF_HsDw28ZC5uj6Z3CHoQ6oiMEZzGV08x5Bj9SVnLL7lhSdDIQSuv62SQm3rqDym
 g1rNg70PAFZhrnhNvkRDIBKJHgrH6vXTGxfVMOBtzA5OYgRJzuKzFeB56Wht5z2wy2T9H.D0eM3m
 yK1YxY9gzXyyaGiie4LLW_Uvwe7pVYluZwcQ_j8PIGDXAFaLvFGBMophrGfB2_WflMDpcyl7Cn.M
 tmS0tCnW3RZpKl97kvB2ZGD9TsjPw6kPgTQ.LeCgDV_pFootTjIs8ektH4aVMTGfFqE5DUSA.u_V
 ql6T4M7Fl2WX4ShB0poG8kk5YoI5_nZRerqFmD0FGh5izoTyBQmVTedy5ot_mpe7r8iu5vraK7TI
 DOgLIsmp7rZGvpUQujVz.Hecgp69ZQllIh2_WOv7OsoDdWxdz4AnqMA6SBJhKQkTlESV3owkTp4R
 p9LGrVGcuvI3FNbHM.53LewXfwXhF1xUrvzExA1_oKQ6jlE8cX_KyAgftgeS5aD9aO1wjJEhF3wU
 5TBtPk73jgevEyBEQOGGXQTv3uWkU.z6tdlGPyYRIPU5VPJvMiw--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Jun 2022 16:16:58 +0000
Received: by hermes--canary-production-ne1-799d7bd497-fwlq2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 34abaf3696d9c65f6c534196ac7eae1e;
          Sun, 12 Jun 2022 16:16:56 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: ampere3 activity is not showing up on
 https://pkg-status.freebsd.org/?all=1&type=package
Message-Id: 
Date: Sun, 12 Jun 2022 09:16:55 -0700
To: freebsd-current ,
 "clusteradm@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4LLfwf0XVRz4X3N
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=hUWs1ZHO;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.42 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-0.995];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 MID_RHS_MATCH_FROM(0.00)[];
	 SUBJECT_HAS_QUESTION(0.00)[];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 NEURAL_HAM_LONG(-0.93)[-0.929];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

Lorenzo Salvadore  wrote on
Date: Sat, 11 Jun 2022 18:01:17 UTC :


> FreeBSD Quarterly Status Report First Quarter 2022
>=20
> . . .
>=20
> Cluster Administration Team
>=20
> Links:
> Cluster Administration Team members URL: =
https://www.freebsd.org/administration
> /#t-clusteradm
>=20
> Contact: Cluster Administration Team 
>=20
> . . .
>=20
>   =E2=80=A2 Installed an additional aarch64 package builder
>=20
>       =E2=96=A1 ampere3.nyi.freebsd.org

ampere3's activity is not showing up on the page:

https://pkg-status.freebsd.org/?all=3D1&type=3Dpackage

but:

http://ampere3.nyi.freebsd.org/#latest_builds
and:
=
http://ampere3.nyi.freebsd.org/build.html?mastername=3D130arm64-default&bu=
ild=3Db44e82e7d313

shows a currently active build (but with only 2 ports remaining).

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


From nobody Mon Jun 13 11:59:43 2022
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 3DCDF844CDE
	for ; Mon, 13 Jun 2022 11:59:53 +0000 (UTC)
	(envelope-from mm@FreeBSD.org)
Received: from www541.your-server.de (www541.your-server.de [213.133.107.7])
	(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 4LM99M6Kcjz3JFD
	for ; Mon, 13 Jun 2022 11:59:51 +0000 (UTC)
	(envelope-from mm@FreeBSD.org)
Received: from sslproxy02.your-server.de ([78.47.166.47])
	by www541.your-server.de with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from )
	id 1o0ijQ-000FQX-8E
	for freebsd-current@freebsd.org; Mon, 13 Jun 2022 13:59:44 +0200
Received: from [188.167.171.2] (helo=[10.0.9.122])
	by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from )
	id 1o0ijQ-0008hK-4H
	for freebsd-current@freebsd.org; Mon, 13 Jun 2022 13:59:44 +0200
Message-ID: <33b2ed7b-b41d-9e24-77f2-9a8d232891fe@FreeBSD.org>
Date: Mon, 13 Jun 2022 13:59:43 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Content-Language: en-US
To: freebsd-current 
From: Martin Matuska 
Subject: Tachyum Prodigy processors
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: martin@matuska.de
X-Virus-Scanned: Clear (ClamAV 0.103.6/26571/Mon Jun 13 10:05:55 2022)
X-Rspamd-Queue-Id: 4LM99M6Kcjz3JFD
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.133.107.7 is neither permitted nor denied by domain of mm@FreeBSD.org) smtp.mailfrom=mm@FreeBSD.org
X-Spamd-Result: default: False [-1.07 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[mm];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[FreeBSD.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 R_SPF_SOFTFAIL(0.00)[~all];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_MEDIUM(-0.36)[-0.365];
	 TO_DN_ALL(0.00)[];
	 NEURAL_SPAM_SHORT(0.40)[0.397];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:213.133.96.0/19, country:DE];
	 RCVD_TLS_ALL(0.00)[];
	 HAS_X_AS(0.00)[];
	 TO_DOM_EQ_FROM_DOM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi everybody,

does anyone have any information regarding the new Tachyum Prodigy 
processors?

They have announced FreeBSD support as well as a porting kit of their 
instruction set architecture for FreeBSD:
https://www.tachyum.com/en-eu/media/press-releases/2022/04/05/tachyum-successfully-runs-freebsd-in-prodigy-ecosystem-expands-open-source-os-support/

They are also offering pre-orders for their evaluation platform:
https://www.tachyum.com/media/press-releases/2022/06/01/tachyum-begins-pre-orders-for-prodigy-evaluation-platform/

If their proclamations and statements about Prodigy's performance and 
features are right this might be the next game-changer in the server 
industry.

Cheers,
mm


From nobody Mon Jun 13 12:12:48 2022
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 C35AB8476DB
	for ; Mon, 13 Jun 2022 12:12:58 +0000 (UTC)
	(envelope-from pi@freebsd.org)
Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::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 4LM9SV1K1gz3LK1;
	Mon, 13 Jun 2022 12:12:58 +0000 (UTC)
	(envelope-from pi@freebsd.org)
Received: from pi by home.opsec.eu with local (Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o0iw4-000Mar-4q;
	Mon, 13 Jun 2022 14:12:48 +0200
Date: Mon, 13 Jun 2022 14:12:48 +0200
From: Kurt Jaeger 
To: Martin Matuska 
Cc: freebsd-current 
Subject: Re: Tachyum Prodigy processors
Message-ID: 
References: <33b2ed7b-b41d-9e24-77f2-9a8d232891fe@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: <33b2ed7b-b41d-9e24-77f2-9a8d232891fe@FreeBSD.org>
X-Rspamd-Queue-Id: 4LM9SV1K1gz3LK1
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 2001:14f8:200::1 is neither permitted nor denied by domain of pi@freebsd.org) smtp.mailfrom=pi@freebsd.org
X-Spamd-Result: default: False [0.67 / 15.00];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[pi];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 DMARC_NA(0.00)[freebsd.org];
	 R_SPF_SOFTFAIL(0.00)[~all:c];
	 NEURAL_SPAM_MEDIUM(0.92)[0.920];
	 TO_DN_ALL(0.00)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_SPAM_SHORT(0.85)[0.850];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

Hi!

> does anyone have any information regarding the new Tachyum Prodigy
> processors?

golem had an article 3 days ago (written in german), which was detailled
enough to trigger my interest.

https://www.golem.de/news/tachyum-prodigy-t16128-der-wunderkind-prozessor-2206-165307.html

-- 
pi@opsec.eu            +49 171 3101372                    Now what ?

From nobody Mon Jun 13 16:16:49 2022
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 C1E6D857F6C
	for ; Mon, 13 Jun 2022 16:17:01 +0000 (UTC)
	(envelope-from eric@vangyzen.net)
Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f])
	(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 4LMGt50cf4z4j7W
	for ; Mon, 13 Jun 2022 16:17:01 +0000 (UTC)
	(envelope-from eric@vangyzen.net)
Received: from [192.168.0.11] (174-20-79-21.mpls.qwest.net [174.20.79.21])
	by smtp.vangyzen.net (Postfix) with ESMTPSA id E3E1756485
	for ; Mon, 13 Jun 2022 11:16:53 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=vangyzen.net;
	s=default; t=1655137014;
	bh=QC+NLewAJcQkhMCj8tcRo+R3QBsNIBiR28e4Rs2GRJs=;
	h=Date:From:Subject:To;
	b=1ocRmNwp/vRYHklVuUBMsOo8YYgys9J+siMjX/0C7Ua8hycgsqCX2gJtEgfjFJvDj
	 WfiE6DI7+PiXWp9KnLFe4KZyDUg6uB+H3XxxQiMSkwhbjJwa05Tt3X+xDpbM6xj58m
	 puvMAm1XJdw+lj6ys9LsRBM70TjBdlbmtqnSxga7VKY0JRjCPxxh27A+aLVeG42tJB
	 TdAO9yTYLZqxVND4Ia8n5pwfGlyGMGB8DoMkDKp+2DP1rSvL1Jtesgf9K6xOCdEBVO
	 N601JF756KhaTj6+wquhEwSvdgk7cRzMskATPRoZ8SCo5gcXIDKl5pV9fT4h11JlU9
	 5SE+obrFIs3Tg==
Message-ID: <92e862d2-ed6a-19a6-85ed-9392cf89207f@vangyzen.net>
Date: Mon, 13 Jun 2022 11:16:49 -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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Content-Language: en-US
From: Eric van Gyzen 
Subject: review: kernel GDB: do not reboot the target
To: freebsd-current 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LMGt50cf4z4j7W
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=vangyzen.net header.s=default header.b=1ocRmNwp;
	dmarc=pass (policy=none) header.from=vangyzen.net;
	spf=pass (mx1.freebsd.org: domain of eric@vangyzen.net designates 2607:fc50:1000:7400:216:3eff:fe72:314f as permitted sender) smtp.mailfrom=eric@vangyzen.net
X-Spamd-Result: default: False [-4.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[vangyzen.net:s=default];
	 FREEFALL_USER(0.00)[eric];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[vangyzen.net:+];
	 DMARC_POLICY_ALLOW(-0.50)[vangyzen.net,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 R_SPF_ALLOW(-0.20)[+a];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:36236, ipnet:2607:fc50:1000::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[174.20.79.21:received]
X-ThisMailContainsUnwantedMimeParts: N

I would like to call attention to this change to prevent accidentally 
rebooting the target of remote kernel GDB.  The code is mundane, but the 
default could be controversial.

https://reviews.freebsd.org/D35473

Please comment on the review, not on this thread.  If you need an 
account on Phabricator, see:

https://wiki.freebsd.org/Phabricator

Cheers,

Eric

From nobody Tue Jun 14 00:52:00 2022
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 BBDAF83763F
	for ; Tue, 14 Jun 2022 00:52:18 +0000 (UTC)
	(envelope-from ish@amail.plala.or.jp)
Received: from msc11.plala.or.jp (msc11.plala.or.jp [IPv6:2400:7800:0:502e::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 4LMVJc67Ccz3JDh
	for ; Tue, 14 Jun 2022 00:52:16 +0000 (UTC)
	(envelope-from ish@amail.plala.or.jp)
Received: from localhost ([2400:4050:9320:7a00::8]) by msc11.plala.or.jp
          with ESMTP
          id <20220614005206.BKY31769.msc11.plala.or.jp@localhost>
          for ;
          Tue, 14 Jun 2022 09:52:06 +0900
Date: Tue, 14 Jun 2022 09:52:00 +0900 (JST)
Message-Id: <20220614.095200.1207794516539262137.ish@amail.plala.or.jp>
To: freebsd-current@freebsd.org
Subject: Re: dmesg: ACPI Warning: Firmware issue warning spaming
From: Masachika ISHIZUKA 
In-Reply-To: 
References: 
	<20220612.170203.1570364119618551543.ish@amail.plala.or.jp>
	
X-Mailer: Mew version 6.8 on Emacs 28.1
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-VirusScan: Outbound; mvir-ac11; Tue, 14 Jun 2022 09:52:06 +0900
X-Rspamd-Queue-Id: 4LMVJc67Ccz3JDh
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of ish@amail.plala.or.jp designates 2400:7800:0:502e::21 as permitted sender) smtp.mailfrom=ish@amail.plala.or.jp
X-Spamd-Result: default: False [-1.57 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.92)[-0.919];
	 FROM_HAS_DN(0.00)[];
	 MV_CASE(0.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DMARC_NA(0.00)[plala.or.jp];
	 R_SPF_ALLOW(-0.20)[+ip6:2400:7800:0:502e::/60];
	 NEURAL_HAM_SHORT(-0.95)[-0.953];
	 MID_CONTAINS_FROM(1.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:4713, ipnet:2400:7800::/32, country:JP];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

> What do you think opening a review about this fix/tweak to stop this
> spamming that blinds dmesg?
> 
>> > I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg
>> warnings:
>> > ---
>> > ACPI Warning: Firmware issue: Excessive sleep time (0x0000000000000010
>> ms >
>> > 10 ms) in ACPI Control Method (20220331/exsystem-347)
>> > ---
>> > Is there a way to silence it?

  I think this spam message is from linux.
  So, I think we should discuss on linux forum but I don't familier
to linux.
-- 
Masachika ISHIZUKA

From nobody Tue Jun 14 01:01:41 2022
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 A0846839261
	for ; Tue, 14 Jun 2022 01:01:58 +0000 (UTC)
	(envelope-from ish@amail.plala.or.jp)
Received: from msc11.plala.or.jp (msc11.plala.or.jp [60.36.166.21])
	by mx1.freebsd.org (Postfix) with ESMTP id 4LMVWm4Bwrz3Kmr
	for ; Tue, 14 Jun 2022 01:01:55 +0000 (UTC)
	(envelope-from ish@amail.plala.or.jp)
Received: from localhost ([2400:4050:9320:7a00::8]) by msc11.plala.or.jp
          with ESMTP
          id <20220614010147.FCD31769.msc11.plala.or.jp@localhost>
          for ;
          Tue, 14 Jun 2022 10:01:47 +0900
Date: Tue, 14 Jun 2022 10:01:41 +0900 (JST)
Message-Id: <20220614.100141.1363594437311677262.ish@amail.plala.or.jp>
To: freebsd-current@freebsd.org
Subject: How to supress prompt on bc 5.3.1
From: Masachika ISHIZUKA 
X-Mailer: Mew version 6.8 on Emacs 28.1
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-VirusScan: Outbound; mvir-ac11; Tue, 14 Jun 2022 10:01:47 +0900
X-Rspamd-Queue-Id: 4LMVWm4Bwrz3Kmr
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of ish@amail.plala.or.jp designates 60.36.166.21 as permitted sender) smtp.mailfrom=ish@amail.plala.or.jp
X-Spamd-Result: default: False [-1.67 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.92)[-0.918];
	 FROM_HAS_DN(0.00)[];
	 MV_CASE(0.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DMARC_NA(0.00)[plala.or.jp];
	 R_SPF_ALLOW(-0.20)[+ip4:60.36.166.0/24];
	 NEURAL_HAM_SHORT(-0.95)[-0.955];
	 MID_CONTAINS_FROM(1.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:4713, ipnet:60.32.0.0/12, country:JP];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_LOW(-0.10)[60.36.166.21:from]
X-ThisMailContainsUnwantedMimeParts: N

  I updated to master-n256084-5dd1f6f1441 (1400061) and this
leads to bc to 5.3.1.
  Previosly, 'BC-ENV-APRG=-P' or 'bc -P' were working but it
doesn't work on 5.3.1.  Is there any way to supress prompt ?
-- 
Masachika ISHIZUKA

From nobody Tue Jun 14 01:18:50 2022
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 20E5583CEA1
	for ; Tue, 14 Jun 2022 01:18:51 +0000 (UTC)
	(envelope-from jkim@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LMVvH0RH3z3NkT;
	Tue, 14 Jun 2022 01:18:51 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1655169531;
	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=8N+2SpHaP43iRnfWxVrfL6+G3j2tmm8JPhpj6niz+Bk=;
	b=Ga8gTKTorENKR00kflBNQW18XOzWtzBeT8T3KbaiO1tfOOvc5yeG1jciVDM7F7FP/sHAd9
	OCEF1EboI48SL1SdnexVyFapTWeBoz151HkVk7ATV2DlnP40L2M3SYAFXwvb6tmV7Ypcsr
	p3N5DFqphykqUqw1kGTyuSKGA4yJnHxPwo0t97KxocM+YZOIHrzd/kRlJYP2XpRrQjdwCq
	X5beE11wdidBK1EcgkX2rqybYQiTyEn9KuDbbG2jy0DJUIglTJJi4wnbzvwpxrQqLTaqy0
	q1HAprNYwksCBBK/VeBu7mPNUoCoVmE+EAnCE10B+cUxfJpzH8lO0adiEGFLRw==
Received: from freefall.freebsd.org (pool-100-8-53-238.nwrknj.fios.verizon.net [100.8.53.238])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: jkim/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id D2D102AE5;
	Tue, 14 Jun 2022 01:18:50 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
Message-ID: 
Date: Mon, 13 Jun 2022 21:18:50 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Content-Language: en-US
To: Masachika ISHIZUKA , freebsd-current@freebsd.org
References: 
 <20220612.170203.1570364119618551543.ish@amail.plala.or.jp>
 
 <20220614.095200.1207794516539262137.ish@amail.plala.or.jp>
From: Jung-uk Kim 
Organization: FreeBSD.org
Subject: Re: dmesg: ACPI Warning: Firmware issue warning spaming
In-Reply-To: <20220614.095200.1207794516539262137.ish@amail.plala.or.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655169531;
	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=8N+2SpHaP43iRnfWxVrfL6+G3j2tmm8JPhpj6niz+Bk=;
	b=r3TqenuosJEDz1ZdOXxZt9FVLw3gVCX6ashJxOt5zmYKNGpIXyOD4iNTSz6lkmK2qtgYHz
	wehB74Ni0J6iCbWyzZNUl+GSoyvY91n/FEiykkeLuYgEK/y8OdlUgP8hknnlabwtcHnFVm
	EqfeQtApjyux5bbOqXhP1ZjuO6Y+urjubAtciYTALds7rvpbOu3m9OBW757foBdFozYacq
	N6DYIagqQbjwqVl6wGDYd+NXETFoCRuY2OBnyRY57Fz3H18XMd0ThzlX2VrTR4sO/dAl4y
	RmRJ4gjCnv/30EPxQ0x/01Zf6Ep10SpKe99c52JrmTIcNM6l53JH165wzU68Zw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655169531; a=rsa-sha256; cv=none;
	b=dHwLQ1Iz2X4ZctGVYSIPeM9/zypaaaPgravJWlwaTcOzM2PGAAWbcuIDHTOCzAX71iQ212
	K4xlMht0EzVNmE9RtOmhbEGTjUWqGShXnl4YDlR+jUHEFMjzEGaLhpl99xffRwOcw7LLQM
	N4dn8owjQYmC8Hj7I6DGXtbBZHB2klEAIgiJaEeT/k/QOOcKxy/BhdKXw8ZkUsz3T0s7m0
	SGWSzVWV2siT9LwpVd3q985LAoDtOv+6yPS9+PhvhmT/oe08pQKxKXVuKHiKb/ZmA5OFVO
	9BjG/nCOcn83CyB43Z8YsIV0di3fsbGOpTVp75Zyi9Hrx1DaLJeDNnADggK51w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 22. 6. 13., Masachika ISHIZUKA wrote:
>> What do you think opening a review about this fix/tweak to stop this
>> spamming that blinds dmesg?
>>
>>>> I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg
>>> warnings:
>>>> ---
>>>> ACPI Warning: Firmware issue: Excessive sleep time (0x0000000000000010
>>> ms >
>>>> 10 ms) in ACPI Control Method (20220331/exsystem-347)
>>>> ---
>>>> Is there a way to silence it?
> 
>    I think this spam message is from linux.
>    So, I think we should discuss on linux forum but I don't familier
> to linux.

FYI, both FreeBSD and Linux use ACPICA to implement ACPI.

https://acpica.org

This message was added by this commit:

https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c

You can file your complaints here if it is really bothering you.

https://github.com/acpica/acpica/issues

Jung-uk Kim

From nobody Tue Jun 14 01:24:36 2022
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 D142083E733
	for ; Tue, 14 Jun 2022 01:24:36 +0000 (UTC)
	(envelope-from jkim@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LMW1w5NYKz3QYW;
	Tue, 14 Jun 2022 01:24:36 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1655169876;
	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=iB+5GjHR+hAg47JEyohy6bVl+JTnlPS3EgRkGym6OUE=;
	b=MV4fkIyGTo1ibtJmLrHdhRraSwcsSptyJTg2OeIPqkdeR1YCuyFBJ4wBqb1Yz3g8n2Fdia
	OORW+GlechzA/obZOtQkYGK3pfV/97pKZ7Wo1tDydvx/x2fV2izRxYgH2883zzyg+qdSzO
	8+ITFFYGWiv7I+rdM1azevIO0cNm+oL06y5F8uc8i560nF1Dr7W8pG13Ef//7t1LLhr+K8
	i/Jn+WBwX3oFXMdO9EGJhCiamAD+T8LGUOWhIjm3HdroJ0OfFQw5fmt8os31lktgg2UMG0
	ASS+xCyK+AGVML7pZvfMB7v4JOSPQK1lb8fSbDnb3fN/jW9JCd/YtoyGi7pIZA==
Received: from freefall.freebsd.org (pool-100-8-53-238.nwrknj.fios.verizon.net [100.8.53.238])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: jkim/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 8D20B2BC9;
	Tue, 14 Jun 2022 01:24:36 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
Message-ID: 
Date: Mon, 13 Jun 2022 21:24:36 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: dmesg: ACPI Warning: Firmware issue warning spaming
Content-Language: en-US
From: Jung-uk Kim 
To: Masachika ISHIZUKA , freebsd-current@freebsd.org
References: 
 <20220612.170203.1570364119618551543.ish@amail.plala.or.jp>
 
 <20220614.095200.1207794516539262137.ish@amail.plala.or.jp>
 
Organization: FreeBSD.org
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------y4eiZ0zZ6YKlSUvtHRIGl9eT"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655169876;
	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=iB+5GjHR+hAg47JEyohy6bVl+JTnlPS3EgRkGym6OUE=;
	b=qVvWzgKnYAslI57zExgpowYkyfPFU8f3TElbP5dcppZlxV/mabg9OgZWSHCvISbxJZdbXg
	stcdUCVvqAwyWEpFT7P0zDQrlQ4v7at189cFrcoFRr42nhXC4N91kIBG2lgSmau0DPWWzu
	hfJTVGNuC5VA6i7pkNevaRH2YxhMmqsOO0Onqnim/RMbIjhziOFln3N5kn+vUd1JmhL798
	Q0I3vEUcgV/jJcDUkk6vxUSR+wVwT5EHNLvOYIDSgEMcztO+6vhf3n76zZ8cYwORX3zAft
	b5F6uVvdVg0pb31dbzRWgGC6y5HUT961Pvk6ZPu1GbuxkWwpDFJEVuDaKEPddA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655169876; a=rsa-sha256; cv=none;
	b=xhwMOfQYFZHclVz/+OCgrpGf4qjGKMKHYdhbP2S0pSsv2AvEGqraykWHWnXkJ0QdSIgoPI
	G6hEUiQrRuyY0lP+Mkj5L0I4DwrTqW0OhguDCt0NFzs8VGYSXcEAywCr7J80vFFEx1ymAt
	5kT0rrBfJ9Cva6GJhVBdcazTUimsjm64NPJDs2wdcOzCrHu3PDlCpWvpMhwS5iUxiucx93
	yMFyEuvSk/WESgnWWQM8YBqIoEArnZdvkzj30qxeB9A3LViw7aNdB01OkEfgWf4bmsN+Zh
	3V/oiazlknsSCRWdzWchw+pQo5TRomBQ5kJjZfMCoCX7p2Z2NZD+Fd3axQFU4A==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------y4eiZ0zZ6YKlSUvtHRIGl9eT
Content-Type: multipart/mixed; boundary="------------o1StztWhpitI6OnudoHDwgOY";
 protected-headers="v1"
From: Jung-uk Kim 
To: Masachika ISHIZUKA , freebsd-current@freebsd.org
Message-ID: 
Subject: Re: dmesg: ACPI Warning: Firmware issue warning spaming
References: 
 <20220612.170203.1570364119618551543.ish@amail.plala.or.jp>
 
 <20220614.095200.1207794516539262137.ish@amail.plala.or.jp>
 
In-Reply-To: 

--------------o1StztWhpitI6OnudoHDwgOY
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjIuIDYuIDEzLiwgSnVuZy11ayBLaW0gd3JvdGU6DQo+IE9uIDIyLiA2LiAxMy4sIE1h
c2FjaGlrYSBJU0hJWlVLQSB3cm90ZToNCj4+PiBXaGF0IGRvIHlvdSB0aGluayBvcGVuaW5n
IGEgcmV2aWV3IGFib3V0IHRoaXMgZml4L3R3ZWFrIHRvIHN0b3AgdGhpcw0KPj4+IHNwYW1t
aW5nIHRoYXQgYmxpbmRzIGRtZXNnPw0KPj4+DQo+Pj4+PiBJJ20gcnVubmluZyBDVVJSRU5U
IDhkOTVmNTAwNTIxIGFuZCBJJ20gcmVjZWl2aW5nIGxvYWRzIG9mIGRtZXNnDQo+Pj4+IHdh
cm5pbmdzOg0KPj4+Pj4gLS0tDQo+Pj4+PiBBQ1BJIFdhcm5pbmc6IEZpcm13YXJlIGlzc3Vl
OiBFeGNlc3NpdmUgc2xlZXAgdGltZSAoMHgwMDAwMDAwMDAwMDAwMDEwDQo+Pj4+IG1zID4N
Cj4+Pj4+IDEwIG1zKSBpbiBBQ1BJIENvbnRyb2wgTWV0aG9kICgyMDIyMDMzMS9leHN5c3Rl
bS0zNDcpDQo+Pj4+PiAtLS0NCj4+Pj4+IElzIHRoZXJlIGEgd2F5IHRvIHNpbGVuY2UgaXQ/
DQo+Pg0KPj4gwqDCoCBJIHRoaW5rIHRoaXMgc3BhbSBtZXNzYWdlIGlzIGZyb20gbGludXgu
DQo+PiDCoMKgIFNvLCBJIHRoaW5rIHdlIHNob3VsZCBkaXNjdXNzIG9uIGxpbnV4IGZvcnVt
IGJ1dCBJIGRvbid0IGZhbWlsaWVyDQo+PiB0byBsaW51eC4NCj4gDQo+IEZZSSwgYm90aCBG
cmVlQlNEIGFuZCBMaW51eCB1c2UgQUNQSUNBIHRvIGltcGxlbWVudCBBQ1BJLg0KPiANCj4g
aHR0cHM6Ly9hY3BpY2Eub3JnDQo+IA0KPiBUaGlzIG1lc3NhZ2Ugd2FzIGFkZGVkIGJ5IHRo
aXMgY29tbWl0Og0KPiANCj4gaHR0cHM6Ly9naXRodWIuY29tL2FjcGljYS9hY3BpY2EvY29t
bWl0LzJhMGQxZDQ3NWU3ZWExYzgxNWJlZTFlMDY5MmQ4MWRiOWE3YzkwOWMgDQo+IA0KPiAN
Cj4gWW91IGNhbiBmaWxlIHlvdXIgY29tcGxhaW50cyBoZXJlIGlmIGl0IGlzIHJlYWxseSBi
b3RoZXJpbmcgeW91Lg0KPiANCj4gaHR0cHM6Ly9naXRodWIuY29tL2FjcGljYS9hY3BpY2Ev
aXNzdWVzDQoNCkJUVywgaXQgc2VlbXMgaXQgd2FzIGRpc2N1c3NlZCBvbiBMaW51eCBNTC4N
Cg0KaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcvbGttbC9DQUpaNXYwZ1dZWl9CU29uaExHVDdM
NHdQUXZYTFZ5b2JQcHRFMU54NlBvTlNHbjR5WGdAbWFpbC5nbWFpbC5jb20vVC8jbWFlNmE4
MTZiYmNlYmIwMWRlYTllNWMxOWM4MWU5YmU4NzJjYWQ1MjENCg0KSSBhbSBub3Qgc3VyZSB3
aGF0IGhhcHBlbmVkIGFmdGVyIHRoYXQuDQoNCkp1bmctdWsgS2ltDQo=

--------------o1StztWhpitI6OnudoHDwgOY--

--------------y4eiZ0zZ6YKlSUvtHRIGl9eT
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAmKn41QFAwAAAAAACgkQfJ+WJvzb8UaV
Awf+JADE6ya+PVru4pgLaG9ewLv881HnTX2uIJtz2Ld6TZbJpK+WNCxNpcqw5e6RYHL84vjWwYv3
vZcrmrBZgV9wZnKkgEjDw4VI9oHLUAWJDJSjxY2RgglDIwpKWv2AxIIoHyradg7m9vcS+ufTgD8P
4Gl+BUWNu8sK3A+rduacJ2ho0vcz9yz7NNuXnfOXtkLezfnmngb9Gmu5smj3UNLsMF+EsSCwC2no
oxfLwbeh4faCfdu6YSi+CKz7Xe/HMuyoG/8M6KD8KPk90UvLqtGTCv7k/fz2lw9xk+HHoVcJ/YdK
ZWfMiKYiPJhIf98lLDE6MlNYz5gKOIenuPFr66WKJA==
=NFwO
-----END PGP SIGNATURE-----

--------------y4eiZ0zZ6YKlSUvtHRIGl9eT--

From nobody Tue Jun 14 01:33:42 2022
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 19521841232
	for ; Tue, 14 Jun 2022 01:33:43 +0000 (UTC)
	(envelope-from jkim@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LMWDR03Gyz3jtf;
	Tue, 14 Jun 2022 01:33:43 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1655170423;
	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=0jRr7cBvKOH1sLeQqlC03QIlOwwPHDb3/91WV7ivChA=;
	b=SD4qMzwH5GwfWCY3Upn8ay/+ZEE3lE1kL3aQ5Sk+WUAh0hA57xfnROl34QmtvL9SYm6Igj
	ch14h6yWErVFHjCOQBI2ff1ZaWomNG5BYbt3+VfdUqDSEdryPoO7QlV0O6WhSeJXnrPI98
	0jtbjcdBaxUdORtdx08wLXad0hj/RlNidBs5QZVx6Lkv5JV+Jw/suI6q0r1VSmwgTK61m1
	6Z3OLApwPVmGCxrWosRfE8z8c97ATJJQgryZLmjKktFJarU+2DHKS1h1P+M9FS2dje9Z9h
	SawKLDYrpN42LyYTL81KlKxvpoRJb1v7MYoXqHdkFFR63z7h59fCg02lOyHpKA==
Received: from freefall.freebsd.org (pool-100-8-53-238.nwrknj.fios.verizon.net [100.8.53.238])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: jkim/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id CBDF62E95;
	Tue, 14 Jun 2022 01:33:42 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
Message-ID: <9a5ebf2a-3aa3-3034-8be2-cf4336e92578@FreeBSD.org>
Date: Mon, 13 Jun 2022 21:33:42 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: dmesg: ACPI Warning: Firmware issue warning spaming
Content-Language: en-US
From: Jung-uk Kim 
To: Masachika ISHIZUKA , freebsd-current@freebsd.org
References: 
 <20220612.170203.1570364119618551543.ish@amail.plala.or.jp>
 
 <20220614.095200.1207794516539262137.ish@amail.plala.or.jp>
 
 
Organization: FreeBSD.org
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------Yhdb7vOf1yFcsjr3rueSUiT8"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655170423;
	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=0jRr7cBvKOH1sLeQqlC03QIlOwwPHDb3/91WV7ivChA=;
	b=w+IV8r1AseJnnX4/QAd0WvyVfXvjRaJkyEUZwcrqZGpZ2RXj6CeKBgDqUzCNGNuqVIVNrL
	kKKL8Jvf02mgRcQmI6r+UV9W215XNPgpOAQ2ur+HpLdFNSKwK10r1M7eWomubM1e9aipLv
	M3FeT4GUggSjErFsJLY3LsnpKFu0wB8MSEjqmqL+R1/JEoOi4HkfonIdsB164dQoxVjUgR
	p0DVbPzf2w8HORe9EJBSSyd3BOX88glB4tvTMQ+kHQluiumJ57eb5S5acz53lPfFJoTiXx
	It1z7Y2Cdw866SWzKvVNqnrEfqTAYPSkKixgTLpT3bH83jhS1CxQ/UGIlX6ZUA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655170423; a=rsa-sha256; cv=none;
	b=GlKvlyIces7kkBZ7Ix5Fd5W5rrtpOxB8zQ8l8/FPKnQ7iabMCtUFdGFQr+4TsA2khEF8gK
	PSb3wp/leTIU05rlPcvaIPjuwcaY2QdqrU25vrO4qPeY0s5i3jOHicdyKbv7TdmM/ip26U
	l+WjQCDSxJsDvmMxJuBNOzDjWiADzeb7+0iRG2s3Aj2wRli9UV9U7ExjPQ6FN0NpdTCQyt
	YjZoUJGv7ID6ZIpQE2I4yq9rRujHf1p1WyPUKuERj+kk/e+es+ivYO0veibrvHyDTPHMnc
	yNKFkWjPlrxBMKid9TAkZ1TJmYSv12CFEc3KoegjNTBip7YP8nf5KAp+bUh8kg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------Yhdb7vOf1yFcsjr3rueSUiT8
Content-Type: multipart/mixed; boundary="------------51SX0JScoPe4WCCYZDLq0V0Z";
 protected-headers="v1"
From: Jung-uk Kim 
To: Masachika ISHIZUKA , freebsd-current@freebsd.org
Message-ID: <9a5ebf2a-3aa3-3034-8be2-cf4336e92578@FreeBSD.org>
Subject: Re: dmesg: ACPI Warning: Firmware issue warning spaming
References: 
 <20220612.170203.1570364119618551543.ish@amail.plala.or.jp>
 
 <20220614.095200.1207794516539262137.ish@amail.plala.or.jp>
 
 
In-Reply-To: 

--------------51SX0JScoPe4WCCYZDLq0V0Z
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjIuIDYuIDEzLiwgSnVuZy11ayBLaW0gd3JvdGU6DQo+IE9uIDIyLiA2LiAxMy4sIEp1
bmctdWsgS2ltIHdyb3RlOg0KPj4gT24gMjIuIDYuIDEzLiwgTWFzYWNoaWthIElTSElaVUtB
IHdyb3RlOg0KPj4+PiBXaGF0IGRvIHlvdSB0aGluayBvcGVuaW5nIGEgcmV2aWV3IGFib3V0
IHRoaXMgZml4L3R3ZWFrIHRvIHN0b3AgdGhpcw0KPj4+PiBzcGFtbWluZyB0aGF0IGJsaW5k
cyBkbWVzZz8NCj4+Pj4NCj4+Pj4+PiBJJ20gcnVubmluZyBDVVJSRU5UIDhkOTVmNTAwNTIx
IGFuZCBJJ20gcmVjZWl2aW5nIGxvYWRzIG9mIGRtZXNnDQo+Pj4+PiB3YXJuaW5nczoNCj4+
Pj4+PiAtLS0NCj4+Pj4+PiBBQ1BJIFdhcm5pbmc6IEZpcm13YXJlIGlzc3VlOiBFeGNlc3Np
dmUgc2xlZXAgdGltZSANCj4+Pj4+PiAoMHgwMDAwMDAwMDAwMDAwMDEwDQo+Pj4+PiBtcyA+
DQo+Pj4+Pj4gMTAgbXMpIGluIEFDUEkgQ29udHJvbCBNZXRob2QgKDIwMjIwMzMxL2V4c3lz
dGVtLTM0NykNCj4+Pj4+PiAtLS0NCj4+Pj4+PiBJcyB0aGVyZSBhIHdheSB0byBzaWxlbmNl
IGl0Pw0KPj4+DQo+Pj4gwqDCoCBJIHRoaW5rIHRoaXMgc3BhbSBtZXNzYWdlIGlzIGZyb20g
bGludXguDQo+Pj4gwqDCoCBTbywgSSB0aGluayB3ZSBzaG91bGQgZGlzY3VzcyBvbiBsaW51
eCBmb3J1bSBidXQgSSBkb24ndCBmYW1pbGllcg0KPj4+IHRvIGxpbnV4Lg0KPj4NCj4+IEZZ
SSwgYm90aCBGcmVlQlNEIGFuZCBMaW51eCB1c2UgQUNQSUNBIHRvIGltcGxlbWVudCBBQ1BJ
Lg0KPj4NCj4+IGh0dHBzOi8vYWNwaWNhLm9yZw0KPj4NCj4+IFRoaXMgbWVzc2FnZSB3YXMg
YWRkZWQgYnkgdGhpcyBjb21taXQ6DQo+Pg0KPj4gaHR0cHM6Ly9naXRodWIuY29tL2FjcGlj
YS9hY3BpY2EvY29tbWl0LzJhMGQxZDQ3NWU3ZWExYzgxNWJlZTFlMDY5MmQ4MWRiOWE3Yzkw
OWMgDQo+Pg0KPj4NCj4+IFlvdSBjYW4gZmlsZSB5b3VyIGNvbXBsYWludHMgaGVyZSBpZiBp
dCBpcyByZWFsbHkgYm90aGVyaW5nIHlvdS4NCj4+DQo+PiBodHRwczovL2dpdGh1Yi5jb20v
YWNwaWNhL2FjcGljYS9pc3N1ZXMNCj4gDQo+IEJUVywgaXQgc2VlbXMgaXQgd2FzIGRpc2N1
c3NlZCBvbiBMaW51eCBNTC4NCj4gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2xrbWwv
Q0FKWjV2MGdXWVpfQlNvbmhMR1Q3TDR3UFF2WExWeW9iUHB0RTFOeDZQb05TR240eVhnQG1h
aWwuZ21haWwuY29tL1QvI21hZTZhODE2YmJjZWJiMDFkZWE5ZTVjMTljODFlOWJlODcyY2Fk
NTIxIA0KPiANCj4gDQo+IEkgYW0gbm90IHN1cmUgd2hhdCBoYXBwZW5lZCBhZnRlciB0aGF0
Lg0KDQpJIGZvdW5kIHRoZSBhdXRob3IgYWN0dWFsbHkgZmlsZWQgYSBwdWxsIHJlcXVlc3Qg
dG8gcmV2ZXJ0IHRoZSBjb21taXQuDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9hY3BpY2EvYWNw
aWNhL3B1bGwvNzgwDQoNCkp1bmctdWsgS2ltDQo=

--------------51SX0JScoPe4WCCYZDLq0V0Z--

--------------Yhdb7vOf1yFcsjr3rueSUiT8
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAmKn5XYFAwAAAAAACgkQfJ+WJvzb8UZt
zggAiah0mMrtGxL6jfjxlr48Jco3rsd6fqONCLJxeCvLHz0lt3QrRP4SJMtPo4yXCIFPET9twNRj
RXhLK5k5KIy9iDXw1mnCYIX6f0R2CWN3sV1wYjRW9bjFdmBxMfyXCj/yhZiSsXogp+h4jAJYzzVH
Erm3+HR0E4Jx8XTkhCrtFUyym266KoKWro5r95QqhFNDKCfKg+JYXYE6IW2eINtPfqBHEPq7tGhK
wxbkedhuun1Dg0ElYj3P4JzdqJ+gsOBcG3zYrBxlfE8pOV2xHLAXrVj6qNnf5+1QALgcDFPIolxF
TbUEQawPaOguxutt8K/eMm5waqLv1IttCHYa/EJZXA==
=z7Xu
-----END PGP SIGNATURE-----

--------------Yhdb7vOf1yFcsjr3rueSUiT8--

From nobody Tue Jun 14 02:00:25 2022
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 949098469A1
	for ; Tue, 14 Jun 2022 02:00:25 +0000 (UTC)
	(envelope-from jkim@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LMWqF3jxMz3pQY;
	Tue, 14 Jun 2022 02:00:25 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1655172025;
	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=TNZolOPkwTeQKPmHuat/EKEgpGEvcx+fbYsOXQyUbB0=;
	b=ylyTYWmbyzhMUJMz4GXaLRdRla8J5a5zSF5kFRA/9Y6wOkIytPu50osS0bxLl4NlAe//Ko
	dfPZTshrSigeJD47o/tsVqW6i1NCc4BdMXEPy6jfnzc9//acIGtfOeJm3dbpxIMiK13vRV
	/lao8Nm8TZTMZr1x1ZQLpVACejZWVYd9NGw1RoroDnHr+bSVv0MnfMiEpCvqYFMJ2oHJ8z
	fEJTCQGwm0pqs0vMsmdIOsiZ6yf/+LONP/FvgdAURYzq+twTc4o74Nwoa0I2wZYZCXLFRo
	+hHJQ1V5YELnscEzF0RUot8IDAeIiZtYSM/bKeUpt9Y432aWyBuY1kP+R91MsQ==
Received: from freefall.freebsd.org (pool-100-8-53-238.nwrknj.fios.verizon.net [100.8.53.238])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: jkim/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 54FA52EA3;
	Tue, 14 Jun 2022 02:00:25 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
Message-ID: <716a962e-7c85-0d6b-ba75-0e10f2d55a8a@FreeBSD.org>
Date: Mon, 13 Jun 2022 22:00:25 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: dmesg: ACPI Warning: Firmware issue warning spaming
Content-Language: en-US
From: Jung-uk Kim 
To: Masachika ISHIZUKA , freebsd-current@freebsd.org
References: 
 <20220612.170203.1570364119618551543.ish@amail.plala.or.jp>
 
 <20220614.095200.1207794516539262137.ish@amail.plala.or.jp>
 
 
 <9a5ebf2a-3aa3-3034-8be2-cf4336e92578@FreeBSD.org>
Organization: FreeBSD.org
In-Reply-To: <9a5ebf2a-3aa3-3034-8be2-cf4336e92578@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655172025;
	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=TNZolOPkwTeQKPmHuat/EKEgpGEvcx+fbYsOXQyUbB0=;
	b=r6ac6SldqGmPrROGFgBoPsKP492CQBVR64u3IA3Kwz8khs2LNR44DnSK5qinw8YZCzYFoE
	KbO15KHUr2nD6GHZRLNMn6Uhy2fW/KjrNBi9r0GtywklTT3tbOt7QGNRJlC0GLscPYBdEC
	ENvLSasCX8QWKnDvQPJKaP8TsxZc4xg1Vfls8V2eimsmAgdqOoRnikoNXw/i6aHc4hpFMf
	+4WDf2UJ7wuzdAMHpBph/aZU2sLLuPYzMj7mrpUKVHEAaEyLMqNIsjkj78HpmiD4aXG/Qp
	4BPvDpdLRzdSHHs+omUWUNwkzPB6rb29zsdXDKtnpO/AFACUdXsCM9wcrwJC7w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655172025; a=rsa-sha256; cv=none;
	b=k5iYOB0oge2XuOy1gVlQ4QVFuJZa6/3lPi1EDEIlaJdPIHBBMzbz071CFDr3QTm0PGbzbP
	gItffZ+KcdaAXRtbwQHMQXktlh5vqB/NmMnv0RTRv4/nsFlVwRbH4jdd1AEKX/7Vu+4tx0
	8sFlC8As1YQKWci7kkNLrmRWZUMSgqjxdi4+cwTS8zGpPPNP8tOHSgCMYbVhkmcAEON1L3
	qmhAFsWYxddJej7rhBz9Ge3zBssa6gIyhZGU0VWHGedsXyCvw84PL+he1XMtoj+zh0BYCj
	FgQwxbgVnA5t1840JIZtPIjBV4yShAfzl3jNOZ4q/vf9hYShMIjPiz843gGQuA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 22. 6. 13., Jung-uk Kim wrote:
> On 22. 6. 13., Jung-uk Kim wrote:
>> On 22. 6. 13., Jung-uk Kim wrote:
>>> On 22. 6. 13., Masachika ISHIZUKA wrote:
>>>>> What do you think opening a review about this fix/tweak to stop this
>>>>> spamming that blinds dmesg?
>>>>>
>>>>>>> I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg
>>>>>> warnings:
>>>>>>> ---
>>>>>>> ACPI Warning: Firmware issue: Excessive sleep time 
>>>>>>> (0x0000000000000010
>>>>>> ms >
>>>>>>> 10 ms) in ACPI Control Method (20220331/exsystem-347)
>>>>>>> ---
>>>>>>> Is there a way to silence it?
>>>>
>>>>    I think this spam message is from linux.
>>>>    So, I think we should discuss on linux forum but I don't familier
>>>> to linux.
>>>
>>> FYI, both FreeBSD and Linux use ACPICA to implement ACPI.
>>>
>>> https://acpica.org
>>>
>>> This message was added by this commit:
>>>
>>> https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c 
>>>
>>>
>>> You can file your complaints here if it is really bothering you.
>>>
>>> https://github.com/acpica/acpica/issues
>>
>> BTW, it seems it was discussed on Linux ML.
>>
>> https://lore.kernel.org/lkml/CAJZ5v0gWYZ_BSonhLGT7L4wPQvXLVyobPptE1Nx6PoNSGn4yXg@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 
>>
>>
>> I am not sure what happened after that.
> 
> I found the author actually filed a pull request to revert the commit.
> 
> https://github.com/acpica/acpica/pull/780

FYI, I removed the message.

https://cgit.freebsd.org/src/commit/?id=c7f14adfda21dfacab1895015b4c78bf7c2febb6

Jung-uk Kim

From nobody Tue Jun 14 03:02:59 2022
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 8814C859796
	for ; Tue, 14 Jun 2022 03:03:33 +0000 (UTC)
	(envelope-from ish@amail.plala.or.jp)
Received: from msc14.plala.or.jp (msc14.plala.or.jp [IPv6:2400:7800:0:502e::24])
	by mx1.freebsd.org (Postfix) with ESMTP id 4LMYD36jrjz4TSV
	for ; Tue, 14 Jun 2022 03:03:31 +0000 (UTC)
	(envelope-from ish@amail.plala.or.jp)
Received: from localhost ([2400:4050:9320:7a00::8]) by msc14.plala.or.jp
          with ESMTP
          id <20220614030321.BORZ25291.msc14.plala.or.jp@localhost>
          for ;
          Tue, 14 Jun 2022 12:03:21 +0900
Date: Tue, 14 Jun 2022 12:02:59 +0900 (JST)
Message-Id: <20220614.120259.1566563343517471238.ish@amail.plala.or.jp>
To: freebsd-current@freebsd.org
Subject: Re: dmesg: ACPI Warning: Firmware issue warning spaming
From: Masachika ISHIZUKA 
In-Reply-To: <716a962e-7c85-0d6b-ba75-0e10f2d55a8a@FreeBSD.org>
References: 
	<9a5ebf2a-3aa3-3034-8be2-cf4336e92578@FreeBSD.org>
	<716a962e-7c85-0d6b-ba75-0e10f2d55a8a@FreeBSD.org>
X-Mailer: Mew version 6.8 on Emacs 28.1
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-VirusScan: Outbound; mvir-ac14; Tue, 14 Jun 2022 12:03:21 +0900
X-Rspamd-Queue-Id: 4LMYD36jrjz4TSV
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of ish@amail.plala.or.jp designates 2400:7800:0:502e::24 as permitted sender) smtp.mailfrom=ish@amail.plala.or.jp
X-Spamd-Result: default: False [-1.54 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.92)[-0.925];
	 FROM_HAS_DN(0.00)[];
	 MV_CASE(0.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DMARC_NA(0.00)[plala.or.jp];
	 R_SPF_ALLOW(-0.20)[+ip6:2400:7800:0:502e::/60];
	 NEURAL_HAM_SHORT(-0.92)[-0.916];
	 MID_CONTAINS_FROM(1.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:4713, ipnet:2400:7800::/32, country:JP];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

>>>>>> What do you think opening a review about this fix/tweak to stop this
>>>>>> spamming that blinds dmesg?
>>>>
     [snip]

>>>>
>>>> FYI, both FreeBSD and Linux use ACPICA to implement ACPI.
>>>>
>>>> https://acpica.org
>>>>
>>>> This message was added by this commit:
>>>>
>>>> https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c
>>>> You can file your complaints here if it is really bothering you.
>>>>
>>>> https://github.com/acpica/acpica/issues
>>>
>>> BTW, it seems it was discussed on Linux ML.
>>>
>>> https://lore.kernel.org/lkml/CAJZ5v0gWYZ_BSonhLGT7L4wPQvXLVyobPptE1Nx6PoNSGn4yXg@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521
>>> I am not sure what happened after that.
>> I found the author actually filed a pull request to revert the commit.
>> https://github.com/acpica/acpica/pull/780
> 
> FYI, I removed the message.
> 
> https://cgit.freebsd.org/src/commit/?id=c7f14adfda21dfacab1895015b4c78bf7c2febb6

  Thank you very much.
-- 
Masachika ISHIZUKA

From nobody Tue Jun 14 05:14:19 2022
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 972E483DFA3
	for ; Tue, 14 Jun 2022 05:14:25 +0000 (UTC)
	(envelope-from philip@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LMc753bd5z4lqP;
	Tue, 14 Jun 2022 05:14:25 +0000 (UTC)
	(envelope-from philip@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1655183665;
	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=D6MZM0ENl+SZf8KF/ZsHEYguamtUKi/3VyL+GYPKvYE=;
	b=WYkISgTHIUxyuT4Vw9WHBBV+lB1s6gj5v695QfrPF5sse7EGgkDlZY2DTjTAXG+MSmDpSC
	9sgor4+YoXUgeQUcGrtrfzJRQ/vIkSSxkuMvh8Md5laG8KulTKa6CW+xPqvkeh1FCN5y8Q
	beuIOOJLISfOQ03Z+uH58NL0jvWJt8spkxvsH5B1o5zOe4/nofAD+CpN13v9v/TlYGY3s8
	+Dt8xMC5oUqr3grjhccJ0CSaDSrNLrddxyqwbaLXvdWfZ1G9F2YmWaEvHvIS8Tf8AtKhdZ
	QMTNx4vMWzIXXDfY8N8kyBTFdOctfC7R5+aT3edwUDZ2pYNjCr1Ng1EbpLqQZg==
Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: philip/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 547B3505B;
	Tue, 14 Jun 2022 05:14:25 +0000 (UTC)
	(envelope-from philip@freebsd.org)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
	by mailauth.nyi.internal (Postfix) with ESMTP id 2E38927C0054;
	Tue, 14 Jun 2022 01:14:25 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
  by compute4.internal (MEProxy); Tue, 14 Jun 2022 01:14:25 -0400
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddukedgleduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhephffvvefufffokfgjfhggtgfgsehtqhhmtdertddtnecuhfhrohhmpefrhhhi
    lhhiphcurfgrvghpshcuoehphhhilhhiphesfhhrvggvsghsugdrohhrgheqnecuggftrf
    grthhtvghrnhepgeduvdehudekvdeggfdutdffkedtjeefvefgleeftedvjefhtedvvdff
    ffdthefhnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgpdhgihhthhhusgdrtghomh
    enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehphhhi
    lhhiphdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduieeivdeivdegke
    dqvdefhedukedttdekqdhphhhilhhipheppehfrhgvvggsshgurdhorhhgsehtrhhouhgs
    lhgvrdhish
X-ME-Proxy: 
    
    
    
Feedback-ID: ia691475d:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 14 Jun 2022 01:14:23 -0400 (EDT)
From: Philip Paeps 
To: Mark Millard 
Cc: freebsd-current , clusteradm@FreeBSD.org
Subject: Re: ampere3 activity is not showing up on
 https://pkg-status.freebsd.org/?all=1&type=package
Date: Tue, 14 Jun 2022 13:14:19 +0800
X-Mailer: MailMate (1.14r5898)
Message-ID: 
In-Reply-To: 
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; format=flowed
Content-Transfer-Encoding: quoted-printable
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655183665;
	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=D6MZM0ENl+SZf8KF/ZsHEYguamtUKi/3VyL+GYPKvYE=;
	b=W0cMQl48v/eMDMiMe0mQId5bD0XclJEscPS5e4L5wziLnXKHKhUEpkbIY5pzMIAfXbblg8
	AexEViNcjwGMTDfsGNFNmKvcSqgMUUsYPB6v3Bw6JZZh3bW7zPVLj7IvXtdQgH0AfwiqiJ
	22gM2XEwVL3DgJNaZ1knlMcbbkgWqDNuE8pojH1hePkkh9kZQtohpioLaQZyB3jIk/Me9W
	y8qxCYMpUbUcUivEV2a1+Ki0Lub2xCXsxcJQYXB7MCk+/fsXcuWvtIRLpuwUiG5e8do1o9
	n00stHeBQnTCCFJ34/d4XCaMpvYjTV/exwxPgExu4LoPljYxhSJS/7PiiwNx0g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655183665; a=rsa-sha256; cv=none;
	b=P4a6CvgMIvwoa9j+Wkmof4j8vI4ay1hKcg+BethSl/p1E1dHg5Nws0a7o+lVWh2rIN+PPq
	bkxEv4wlO8TYx/x0XbzF31C3amLXe5EooMIIlpuDzCQ+0s70Xk6ZJ67d1V/I/9e9aJFmeO
	aOgdz2LVIF6ICOSCJpRrsSBufpkP+R7skPbk8ooIZyl6/t00/tTWu+EsXEM/ZlPvIGDZ+K
	6f2cLi++BAUaTO3uc0HP8YxgOAFpv6TsMhyAi9CtQUAyBioLRTAPUVf9Ocsu9mcXlyI8Uk
	YkWd84SoY3/UuvnGPwy9aLKk5il+ujqfdAy9hPjqBBcxjI4TnW4ZY2aKp04kQg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 2022-06-13 00:16:55 (+0800), Mark Millard wrote:
> ampere3's activity is not showing up on the page:
> https://pkg-status.freebsd.org/?all=3D1&type=3Dpackage
>
> but:
>
> http://ampere3.nyi.freebsd.org/#latest_builds
> and:
> http://ampere3.nyi.freebsd.org/build.html?mastername=3D130arm64-default=
&build=3Db44e82e7d313
>
> shows a currently active build (but with only 2 ports remaining).

pkg-status.freebsd.org is maintained on GitHub, outside the clusteradm =

automation.  I sent in this patch a couple of months ago, when I set up =

ampere3:

https://github.com/bdrewery/pkg-status.freebsd.org/pull/12/files

This was merged last week but it doesn't look like there's any =

automation to keep the running infrastructure in sync with that =

repository.  There were some reassuring screams in a logfile after I =

chanted some incantations in a the jail running pkg-status.freebsd.org.

Let me know if that fixed it.

Philip

-- =

Philip Paeps
Senior Reality Engineer
Alternative Enterprises

From nobody Tue Jun 14 05:41:49 2022
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 2D8538421C1
	for ; Tue, 14 Jun 2022 05:42:01 +0000 (UTC)
	(envelope-from rhurlin@gwdg.de)
Received: from xmailer.gwdg.de (xmailer.gwdg.de [134.76.10.29])
	(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 4LMckw2Vkmz4pfH;
	Tue, 14 Jun 2022 05:42:00 +0000 (UTC)
	(envelope-from rhurlin@gwdg.de)
Received: from excmbx-03.um.gwdg.de ([134.76.9.218] helo=email.gwdg.de)
	by mailer.gwdg.de with esmtp (GWDG Mailer)
	(envelope-from )
	id 1o0zJJ-0002Sf-BA; Tue, 14 Jun 2022 07:41:53 +0200
Received: from [172.20.100.8] (10.250.9.199) by EXCMBX-03.um.gwdg.de
 (134.76.9.218) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.9; Tue, 14
 Jun 2022 07:41:53 +0200
Message-ID: 
Date: Tue, 14 Jun 2022 07:41:49 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: dmesg: ACPI Warning: Firmware issue warning spaming
Content-Language: en-US
To: Jung-uk Kim 
References: 
 <20220612.170203.1570364119618551543.ish@amail.plala.or.jp>
 
 <20220614.095200.1207794516539262137.ish@amail.plala.or.jp>
 
 
 <9a5ebf2a-3aa3-3034-8be2-cf4336e92578@FreeBSD.org>
 <716a962e-7c85-0d6b-ba75-0e10f2d55a8a@FreeBSD.org>
CC: 
From: Rainer Hurling 
Reply-To: "Hurling, Rainer" 
In-Reply-To: <716a962e-7c85-0d6b-ba75-0e10f2d55a8a@FreeBSD.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.250.9.199]
X-ClientProxiedBy: EXCMBX-19.um.gwdg.de (134.76.9.203) To EXCMBX-03.um.gwdg.de
 (134.76.9.218)
X-Virus-Scanned: (clean) by clamav
X-Rspamd-Queue-Id: 4LMckw2Vkmz4pfH
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of rhurlin@gwdg.de designates 134.76.10.29 as permitted sender) smtp.mailfrom=rhurlin@gwdg.de
X-Spamd-Result: default: False [-0.49 / 15.00];
	 HAS_REPLYTO(0.00)[rhurlin@FreeBSD.org];
	 ARC_NA(0.00)[];
	 HAS_XOIP(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEFALL_USER(0.00)[rhurlin];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
	 DMARC_NA(0.00)[gwdg.de];
	 NEURAL_SPAM_MEDIUM(0.11)[0.113];
	 R_SPF_ALLOW(-0.20)[+ip4:134.76.10.0/23];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(0.80)[0.797];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:680, ipnet:134.76.0.0/16, country:DE];
	 RCVD_TLS_LAST(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[134.76.10.29:from]
X-ThisMailContainsUnwantedMimeParts: N

Am 14.06.22 um 04:00 schrieb Jung-uk Kim:
> On 22. 6. 13., Jung-uk Kim wrote:
>> On 22. 6. 13., Jung-uk Kim wrote:
>>> On 22. 6. 13., Jung-uk Kim wrote:
>>>> On 22. 6. 13., Masachika ISHIZUKA wrote:
>>>>>> What do you think opening a review about this fix/tweak to stop this
>>>>>> spamming that blinds dmesg?
>>>>>>
>>>>>>>> I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg
>>>>>>> warnings:
>>>>>>>> ---
>>>>>>>> ACPI Warning: Firmware issue: Excessive sleep time 
>>>>>>>> (0x0000000000000010
>>>>>>> ms >
>>>>>>>> 10 ms) in ACPI Control Method (20220331/exsystem-347)
>>>>>>>> ---
>>>>>>>> Is there a way to silence it?
>>>>>
>>>>>    I think this spam message is from linux.
>>>>>    So, I think we should discuss on linux forum but I don't familier
>>>>> to linux.
>>>>
>>>> FYI, both FreeBSD and Linux use ACPICA to implement ACPI.
>>>>
>>>> https://acpica.org
>>>>
>>>> This message was added by this commit:
>>>>
>>>> https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c 
>>>>
>>>>
>>>> You can file your complaints here if it is really bothering you.
>>>>
>>>> https://github.com/acpica/acpica/issues
>>>
>>> BTW, it seems it was discussed on Linux ML.
>>>
>>> https://lore.kernel.org/lkml/CAJZ5v0gWYZ_BSonhLGT7L4wPQvXLVyobPptE1Nx6PoNSGn4yXg@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 
>>>
>>>
>>> I am not sure what happened after that.
>>
>> I found the author actually filed a pull request to revert the commit.
>>
>> https://github.com/acpica/acpica/pull/780
> 
> FYI, I removed the message.
> 
> https://cgit.freebsd.org/src/commit/?id=c7f14adfda21dfacab1895015b4c78bf7c2febb6 

Thank you! This message bothered me a lot on two notebooks, Dell 
Latitude 6520 and Dell Latitude 5521.

Greetings,
Rainer

> 
> 
> Jung-uk Kim
> 


From nobody Tue Jun 14 05:44:29 2022
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 16B0C8436C4
	for ; Tue, 14 Jun 2022 05:44:42 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.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 4LMcp05psLz4qht
	for ; Tue, 14 Jun 2022 05:44:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655185473; bh=jBvQ2tZNwHNQecjT5AXcIHSO03koT/Lh/o7LFYHLgFM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=otpW6i/jk9QcvwdCj4B6p6LAOYGK6RllNKooE4DHVLJaHs5C57tv/S7pMJrAbV+tGGIcECnbW/g9I+ZKYYqO6yi4V/rtm6QL30iLrXaEgTK9ujCAYUd4Unrj7nZjKPLvrT9SaZj9at2R7p3Ud52jd7fBzEIvcQr/Fe+iRw+PvJyaBkKE64UOe+L0bEgNH0sOhytlDod38GfnBweKnmXXlVlCjkySzkIDuSfoCvLw7gt8kYOBkeEa3SL7I5ZK5I0b7WodU6Fpcu9w3Z9RDm5Cqw6vEykXEJN+EAh9qDL0P4mWBprvDIEG+mEhecw6PwBKbeQ8GkcI4wg4lFOQG4Zx+w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655185473; bh=QGpeEiw6uzJCpDyyvkEZom+H6L2BO9XIHRX4JYR4HF4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=XN4PXyzQbpvyXUJW87xxf1SeIFg8DDOA1K7p5rhEkV5kzXWim4lrw+yV53FOBJ0Q9GL422nW28yhzHf/ArzDEwuZWYnsz2EX1JTfwUrxNX9OQkXGmY5a2ImUBQw6uaIU8db2PF1n99ZyVXCB0zZNb4G55RT7A4rlt7EtfFHTTFv4LYRxaFNGNT8camFpDVXPouBMIW3lVb5xDsb3iAaX0mY8EzHERHneij7TfC1nR9WZLholEO76Ltmt9Y9R+nM7x5KkhAEOTcIc2t4akBKtvrCkP6AHikht3K8CvPyickk+XQrAejd7Wz3qfsGUAkGMjTp1TFPj1jWp4AHPe41ztw==
X-YMail-OSG: 6_Mh9OIVM1narG2BChiXn0.DgxzUwYh.PV9s7NochZu50xzPOWWbw2s5MboijaT
 Q8X6M3DjtofXIqdNokn.c8PZq13DQc2JeTH4GVx.BYNY7DbMmYtoZXhCtgxiOThAJqNQhu3LncTJ
 H4TiUOkFt._CNr9vGp6nIE13zkBKPWP2iSGUyP5KPCpStSjPn.JDhx2shttLYhqtgjkmUFdEMIpE
 lO.KXjnDMxtHhtI47.WBcqcRfrYMqLg14730TKeYIdFIxHw_MY9bIkaYUoFoL75Igg4HqYr5YQ96
 qd.Efh6H.83L2VcqBVKgM16ZoDfEl8GT_juowR9o3HbjXPhZZfTF_jrE3RfNEaddI.87oTcotZoV
 ofgZOpIwu_GxvGJ.nejJjeeTndqhfSZ8ucz1QTltUXSIrvkmazJSNV2sdiDKLVwaFRHofAS1sjNF
 8iNrqC_zrYB.dO0_i5JYWO_n94KMfSogSgGo5Y6ZMo66ORNBPCY51qpskrTosujkbprABuEFDtY3
 rHTqCXiceRQRr1MTSDJC9e9aK5GD_mAML.EMH_.rhEv7SlId.g5aXfPLfI66vrFjjoXy3YhyKO3z
 VIXBwcIcETRcwo72b2KMqkbKNHWpo6JXSQgIeNt8OeVm9.PFlEsABuGPigP_VSaZSJ2H4Rz3AjdD
 Wq2WIGQ6AOyElrLRv4zdQe_UHPrt.7J0BwrBOPv4Lj.HkbGA9_X0Qji5.VC7Kjm32IDHdTQJrQuL
 Evcq4DeE57mFMbS1YjNFYBmdLo097DCuMEbYmKqMzvQNXczSnQurUCmGxzsGW7jvQXHV1p94arMi
 ChvXkvZR.T7rXH5EY09szbN7xWTDtqlzzyuC3V9Bvn.QPXnJb8lZbjzarH9aLM3taZWpO6eDePDi
 zqCmeJiFwgPYryiWBqjkXD42JCGmQ6NWkoEsvi.QDupgkz1vfoiQQj513oz98nzfNThLMFQqvX0J
 wKVEgPw5OEoOndl3lOygGaLcOpzWztt0V.CfB3NbHbohhUhr.8zyTheD.BvJZZtfOLnwiWHiMrtm
 fwdTyd5UPVVUCNWmVm2mvuaI.SHsqwWQuOrT_gkND9bvo5woBRHT19zeShFAvyG8CmK1znu5dltK
 vD0fF3LnAy5gKEvp5nCJ_vwP2XMVNqGBZXGgVY5g2PSk58oNp7NI.78XeqOjJIZe30XK6wZ_sO.p
 oJXeDvYOhQW2viyGF0u2CZoCGwWP6s35aXg77s98Hpk3ynn10EtGA2vGyLVGci.SrHAvx93OaQzr
 mHz4nDdqFpvLtXS5CbmvwCWjkwCKUCpxeYLa9NwTppGbTUeGzrh3LI1nspSE65Ekhngi0.UIYpV9
 d7CxUtJz3q1Orft51F3vojsW4lsJaWDPwIbEzsvYclyjYDA0G9TLp34gNSopzIT0i4nFLl2peG6F
 kzqq8aRrJObfcgYwlVbyrWMNH353c.VWPH3_0yyV5DCHxS3DignKlYkUcevzTdeWu3PYv3G9Wzgf
 lhEdpH8N1ZEDlvmyd6LgQJUZYgZNjxU8cH4cOknKZTSEdwlyBILlAD2nVFTG4U8Vx_0KDFDJ.Brd
 WcvVMPWKesEeu_Ci7EDWqc.BdLQcE4W30CIy1_x7Chqii23OnA1ThgqW7RJkkh2xvHPSpzHR9l4.
 9U1.U8rny9e4lrGvyzorFWKguox8eTXQy4skTX_zic3bm265n65LP39Z3OKKkZdlJT5l9b2WdOw2
 zLHU5H_uXPar7Va4jZMlXSPMAKkd9WTZHUejwfvMavrg0zO4xiVYd6uI2k56L8i6idvoqxH4DFTE
 w4hPDFBeOTSHqAn3S4BFiG7v6.JIvi2VuUk6x43OWLsUwdvQ5bwTEyeKfF0Nf8PnE177l0_jjzpY
 N2Ns2ESnsL_zMs40MWXkXbxEx6ssBO0I994V9C3m42xF2bKCsYj4npNTWv.JCZfKYCPbLpEt5rEI
 LRD6kWtsYDc5dCd1kCjXB2c8TNC9_VjA0usxPHpT2rH06PTSTw5CUUn1EAXzdDD_FNYdbtqYq6_7
 gT1rfr7fDUg6H4iEbi1GkCnnSI76.PJ_Ia4wRNZvc7Cf2wGEXgsxGOp5.QfsiJnwhR_6PhjhM0M8
 PLfn_I9l_VOCllShkmN7OaM6UB0YHD0XVG6tyUKYNGmPapFs_UB1A1kQOjHjSbymUswNCwLVgWy2
 7s3jnP6CG8siDdeQuB2jUa_epZ.32fI.a_jJnQTFJ2XoHFYwhtByq2EbtbfaXk3I86m5DTSFDgTV
 rnZq7BhonqUyCC_TOkjaWeq_SbXHPk0BE.rLGAq2C7pWBoJAq7kCiRq.UqwaOt2EFlLhQGXHxclI
 UDit0vUwdmLw7xggEetOz3Qry_IBlEejG1DJK9onSxp0hmfq4n5VMWQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 14 Jun 2022 05:44:33 +0000
Received: by hermes--canary-production-ne1-799d7bd497-px24v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4e58aee6fb796749a7f55be093e83e05;
          Tue, 14 Jun 2022 05:44:31 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: ampere3 activity is not showing up on
 https://pkg-status.freebsd.org/?all=1&type=package
From: Mark Millard 
In-Reply-To: 
Date: Mon, 13 Jun 2022 22:44:29 -0700
Cc: freebsd-current ,
 "clusteradm@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B511C8C-8E7F-465D-8B70-447EB34DD1EA@yahoo.com>
References: 
 
 
To: Philip Paeps 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LMcp05psLz4qht
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="otpW6i/j";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-0.997];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 MID_RHS_MATCH_FROM(0.00)[];
	 SUBJECT_HAS_QUESTION(0.00)[];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jun-13, at 22:14, Philip Paeps  wrote:

> On 2022-06-13 00:16:55 (+0800), Mark Millard wrote:
>> ampere3's activity is not showing up on the page:
>> https://pkg-status.freebsd.org/?all=3D1&type=3Dpackage
>>=20
>> but:
>>=20
>> http://ampere3.nyi.freebsd.org/#latest_builds
>> and:
>> =
http://ampere3.nyi.freebsd.org/build.html?mastername=3D130arm64-default&bu=
ild=3Db44e82e7d313
>>=20
>> shows a currently active build (but with only 2 ports remaining).
>=20
> pkg-status.freebsd.org is maintained on GitHub, outside the clusteradm =
automation.  I sent in this patch a couple of months ago, when I set up =
ampere3:
>=20
> https://github.com/bdrewery/pkg-status.freebsd.org/pull/12/files
>=20
> This was merged last week but it doesn't look like there's any =
automation to keep the running infrastructure in sync with that =
repository.  There were some reassuring screams in a logfile after I =
chanted some incantations in a the jail running pkg-status.freebsd.org.
>=20
> Let me know if that fixed it.
>=20

Well, I now see 34 builds that were via ampere3. This
was via use of:

https://pkg-status.freebsd.org/?all=3D1&type=3Dpackage

They go back to 2022-Feb-26, with the most recent still
in progress (371 remaining).

Thanks.


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


From nobody Tue Jun 14 09:09:22 2022
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 8F10583F6FF
	for ; Tue, 14 Jun 2022 09:09:30 +0000 (UTC)
	(envelope-from SRS0=m++4=WV=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 4LMjLL2xdQz59Kt;
	Tue, 14 Jun 2022 09:09:30 +0000 (UTC)
	(envelope-from SRS0=m++4=WV=klop.ws=ronald-lists@realworks.nl)
Date: Tue, 14 Jun 2022 11:09:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1655197763;
	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=t5wdpCHwykMOgt+vwqJZQIA5nHB9+fJu9lvvO5QQACQ=;
	b=xTXgpgCbrZD4frQb/C47bnWan+3dls8GCiY9tu9MAo4lLSKBBvJKtVL7Y6/O+qheWTZb9Y
	I6Xn57Muh5n8srRWxQA/acGiob1fE64KeicPgGWgV7fa/8eT99hPmFV3mN+oMe/NgLsoW3
	PpL0MXANpsewxTMv/15NWMwzOHJeFPRNm9ueDvfSZWlOmnPc2OqicXdp+9aAre/TNZLy91
	DazSUIoPbpAixg9FDWdlAWrTDdt44TB+cy1eL0isjDaujh3XEgZC5mZgagtKzjfu+lvrz4
	9OWIIKLMMkBYAgAjGL11HyqsIjt5vKpg6lk/XuMaath6OiDSbZWvEoyRhPiz8w==
From: Ronald Klop 
To: Mark Millard 
Cc: "clusteradm@freebsd.org" ,
	Philip Paeps ,
	freebsd-current 
Message-ID: <1092745607.88.1655197762892@localhost>
In-Reply-To: <8B511C8C-8E7F-465D-8B70-447EB34DD1EA@yahoo.com>
References: 
 
 
 <8B511C8C-8E7F-465D-8B70-447EB34DD1EA@yahoo.com>
Subject: Re: ampere3 activity is not showing up on
 https://pkg-status.freebsd.org/?all=1&type=package
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_87_548946499.1655197762825"
X-Mailer: Realworks (610.140.161947f)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4LMjLL2xdQz59Kt
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Spamd-Result: default: False [-4.00 / 15.00];
	 REPLY(-4.00)[];
	 TAGGED_FROM(0.00)[4=WV=klop.ws=ronald-lists]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_87_548946499.1655197762825
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Thanks.

I use this pkg-status a lot to check my ports on aarch64 and was also missi=
ng ampere3.

=F0=9F=91=8D

Regards,
Ronald.

=20
Van: Mark Millard 
Datum: dinsdag, 14 juni 2022 07:44
Aan: Philip Paeps 
CC: freebsd-current , "clusteradm@freebsd.org"=
 
Onderwerp: Re: ampere3 activity is not showing up on https://pkg-status.fre=
ebsd.org/?all=3D1&type=3Dpackage
>=20
> On 2022-Jun-13, at 22:14, Philip Paeps  wrote:
>=20
> > On 2022-06-13 00:16:55 (+0800), Mark Millard wrote:
> >> ampere3's activity is not showing up on the page:
> >> https://pkg-status.freebsd.org/?all=3D1&type=3Dpackage
> >>
> >> but:
> >>
> >> http://ampere3.nyi.freebsd.org/#latest_builds
> >> and:
> >> http://ampere3.nyi.freebsd.org/build.html?mastername=3D130arm64-defaul=
t&build=3Db44e82e7d313
> >>
> >> shows a currently active build (but with only 2 ports remaining).
> >
> > pkg-status.freebsd.org is maintained on GitHub, outside the clusteradm =
automation.  I sent in this patch a couple of months ago, when I set up amp=
ere3:
> >
> > https://github.com/bdrewery/pkg-status.freebsd.org/pull/12/files
> >
> > This was merged last week but it doesn't look like there's any automati=
on to keep the running infrastructure in sync with that repository.  There =
were some reassuring screams in a logfile after I chanted some incantations=
 in a the jail running pkg-status.freebsd.org.
> >
> > Let me know if that fixed it.
> >
>=20
> Well, I now see 34 builds that were via ampere3. This
> was via use of:
>=20
> https://pkg-status.freebsd.org/?all=3D1&type=3Dpackage
>=20
> They go back to 2022-Feb-26, with the most recent still
> in progress (371 remaining).
>=20
> Thanks.
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>=20
> =20
>=20
>=20
>=20
------=_Part_87_548946499.1655197762825
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thanks.



I use this pkg-status a lot to check my ports on aarch64 and was also missi=
ng ampere3.



=F0=9F=91=8D



Regards,

Ronald.



 

Van: Mark Millard <marklmi@yahoo.com>

Datum: dinsdag, 14 juni 2022 07:44

Aan: Philip Paeps <philip@freebsd.org>

CC: freebsd-current <freebsd-current@freebsd.org>, &=
quot;clusteradm@freebsd.org" <clusteradm@FreeBSD.org>

Onderwerp: Re: ampere3 activity is not showing up on https=
://pkg-status.freebsd.org/?all=3D1&type=3Dpackage







On 2022-Jun-13, at 22:14, Philip =
Paeps <philip@freebsd.org> wrote:



> On 2022-06-13 00:16:55 (+0800), Mark Millard wrote:

>> ampere3's activity is not showing up on the page:

>> https://pkg-status.freebsd.org/?all=3D1&type=3Dpackage

>>

>> but:

>>

>> http://a=
mpere3.nyi.freebsd.org/#latest_builds

>> and:

>> http://ampere3.nyi.freebsd.org/b=
uild.html?mastername=3D130arm64-default&build=3Db44e82e7d313

>>

>> shows a currently active build (but with only 2 ports remaining).<=
br />
>

> pkg-status.freebsd.org is maintained on GitHub, outside the clusteradm=
 automation.  I sent in this patch a couple of months ago, when I set =
up ampere3:

>

> https://github.com/bdrewery/pkg-status.freebsd.org/pull/12/files=


>

> This was merged last week but it doesn't look like there's any automat=
ion to keep the running infrastructure in sync with that repository.  =
There were some reassuring screams in a logfile after I chanted some incant=
ations in a the jail running pkg-status.freebsd.org.

>

> Let me know if that fixed it.

>



Well, I now see 34 builds that were via ampere3. This

was via use of:



http=
s://pkg-status.freebsd.org/?all=3D1&type=3Dpackage



They go back to 2022-Feb-26, with the most recent still

in progress (371 remaining).



Thanks.





=3D=3D=3D

Mark Millard

marklmi at yahoo.com



 






------=_Part_87_548946499.1655197762825--

From nobody Tue Jun 14 19:22:16 2022
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 BF6FE833A82
	for ; Tue, 14 Jun 2022 19:24:07 +0000 (UTC)
	(envelope-from herbert@gojira.at)
Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-384) client-digest SHA384)
	(Client CN "mail.bsd4all.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LMyzT6CVBz4RJj
	for ; Tue, 14 Jun 2022 19:24:05 +0000 (UTC)
	(envelope-from herbert@gojira.at)
Date: Tue, 14 Jun 2022 21:22:16 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at;
	s=mail202005; t=1655234638;
	bh=xWRtG4Pw78sPtFczGZXuK3Hp0GLhU6vGVbiPTMcwiLo=;
	h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type;
	b=H4/N/Ech0X7InIh32bmPKdoClMRgVPeeybiJ47i5aYmcrIrr/Zk+BsNGR0KXOKai6
	 beVwjpceyj1BDcDzl9Ezovzl35HqVtOPkjZsULXEGhnbk2qH2ASZun8FjEpk9FIX3W
	 JptfiPrNQpy0aYgmPZNfWvZ0flDE639aHw9z3NqGePRU9cLUIgNndzNO8TJNIrKs7y
	 x87TjgtcwWaMeAJf02SXGpzd2Oquh0Xw7FbO+oPsnUnihwXdeErw/KkIgzAPK3iEEP
	 CUNQixFwKYFTKWNhGc5TcZQzG7oS7kYv3zeu5xBQgVmi+X1JH/xnN8UQH8OBZEvEM2
	 XE9hu0dga4lNQ==
Message-ID: <87k09j82zb.wl-herbert@gojira.at>
From: "Herbert J. Skuhra" 
To: current@freebsd.org
Subject: Re: How to supress prompt on bc 5.3.1
In-Reply-To: <20220614.100141.1363594437311677262.ish@amail.plala.or.jp>
References: <20220614.100141.1363594437311677262.ish@amail.plala.or.jp>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/29.0 Mule/6.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 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Rspamd-Queue-Id: 4LMyzT6CVBz4RJj
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gojira.at header.s=mail202005 header.b="H4/N/Ech";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at
X-Spamd-Result: default: False [-2.50 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 DMARC_NA(0.00)[gojira.at];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[gojira.at:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MID_CONTAINS_FROM(1.00)[];
	 MLMMJ_DEST(0.00)[current];
	 RCVD_COUNT_ZERO(0.00)[0];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 14 Jun 2022 03:01:41 +0200, Masachika ISHIZUKA wrote:
> 
>   I updated to master-n256084-5dd1f6f1441 (1400061) and this
> leads to bc to 5.3.1.
>   Previosly, 'BC-ENV-APRG=-P' or 'bc -P' were working but it
> doesn't work on 5.3.1.  Is there any way to supress prompt ?

This is fixed in 5.3.2:

https://git.yzena.com/gavin/bc/commit/45df56dd2eee2947d80f627f2d6ecf2b05827194
https://git.yzena.com/gavin/bc/releases

--
Herbert

From nobody Tue Jun 14 21:17:04 2022
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 C1C37845F4D
	for ; Tue, 14 Jun 2022 21:17:06 +0000 (UTC)
	(envelope-from se@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LN1Tt52rHz4j7J;
	Tue, 14 Jun 2022 21:17:06 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1655241426;
	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=gIx+DANGVcnZdmOVzgbslt0eRJ/ZhKp24Bt/r9SlR/c=;
	b=deQumIn/StYw+BHVwUW1EFZm7BoLUsC6FAigZTDwCmzFXbiqfFgPTdrE4jchfiayAfB/kJ
	o1I+sVDicUnpBrkQBFdrCNGFJV3kB6Crpe5UTvK20f8Bsli+7pqYAZECpaq33ThYISyo6B
	rQZ7ng4Pw4TRghH1uYsGwREWgSgfQzHWVoMvLD0yXXfqd0YuxOewQQCicBs2UbuRIRbVVx
	+KVKF6KqmQN8Jfct3f0F4kjRBhgFcT7WajrBtv/dwfSpry9p1pItwkR2Wq5y/rKjYhgRb2
	8+88O480LCMfV9qHQ9bm1Or6Rz2sfV4KL2EqAUqiYRyE6yTv8o0P61ldpErPKg==
Received: from [IPV6:2003:cd:5f17:8800:6df7:b8ab:7217:7fe] (p200300cd5f1788006df7b8ab721707fe.dip0.t-ipconnect.de [IPv6:2003:cd:5f17:8800:6df7:b8ab:7217:7fe])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: se/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 0732DDBBF;
	Tue, 14 Jun 2022 21:17:05 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
Message-ID: <222ac8d4-3c57-745e-939d-bc0c325ede4f@FreeBSD.org>
Date: Tue, 14 Jun 2022 23:17:04 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.10.0
Subject: Re: How to supress prompt on bc 5.3.1
Content-Language: en-US
To: "Herbert J. Skuhra" , current@freebsd.org
References: <20220614.100141.1363594437311677262.ish@amail.plala.or.jp>
 <87k09j82zb.wl-herbert@gojira.at>
From: Stefan Esser 
In-Reply-To: <87k09j82zb.wl-herbert@gojira.at>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------A1g3JgIaC0jsOkJeTou8PlS3"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655241426;
	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=gIx+DANGVcnZdmOVzgbslt0eRJ/ZhKp24Bt/r9SlR/c=;
	b=bYJeyOVuTib2zKUDH6ogxfNf6kByZLMsc91EL3HvjXXEzAygZtzTQ1x8T6U+2xoXm2o/ie
	lLAGPewH/lU87TUtgiqK18le9nNq0uKYM+zlc802ixFiFA6syyGzxtqyl26fbAFG9Dup2E
	OedOCHdyhmY/VNzMoD8/Fb+uK1uhmmzpQLgfcREyLwvJ2ydafgSU5qxuVZKCogtgwmGB3h
	ankyZfyQ5M25MWmEZrDY06tz3PeNe1LIbsiH0XdXaKj3kTGJarCCl6bvtXgDvGH2RyD8SN
	9FZAEds136joHOM7N7v2JCjsm9eHXMklhk+M2VCvgbiwBjt0fp18hR2KfqS8Ew==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655241426; a=rsa-sha256; cv=none;
	b=Rr7QcQJ8PbGCQDBVFECIwpFjlm57Oq8mLgS7xwaDeulINjzDZoytL7rhC5sirOfaGs00xV
	WRUC2E4qt/TYWu1ccourBhmPSiiqh3uaeyZJcd9QQ3ekG2bBsMFM5goLdvlc5RfNF1txRe
	tp5vTB9M/yIGBzXSpb5kF+1+BOPTju5mcgS3PMdfZbJFFAgDy+RgWn/Wyxf1Pb+0oVLqfi
	R1qBmjRnl1+kMoyVl+82gFg9gqs3Hqk6m7TlqWL0qmWZtfEIljtIfjHdyEGXCiZgFpaH3r
	pU3B+SQm+5QsRzEMeP0c7N43XkTypmMBiBrW9CzvICvxieTz79x/Ecr0BXd7Cw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------A1g3JgIaC0jsOkJeTou8PlS3
Content-Type: multipart/mixed; boundary="------------yD4bpOiCSRw1SEKhcsED9w4j";
 protected-headers="v1"
From: Stefan Esser 
To: "Herbert J. Skuhra" , current@freebsd.org
Message-ID: <222ac8d4-3c57-745e-939d-bc0c325ede4f@FreeBSD.org>
Subject: Re: How to supress prompt on bc 5.3.1
References: <20220614.100141.1363594437311677262.ish@amail.plala.or.jp>
 <87k09j82zb.wl-herbert@gojira.at>
In-Reply-To: <87k09j82zb.wl-herbert@gojira.at>

--------------yD4bpOiCSRw1SEKhcsED9w4j
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Am 14.06.22 um 21:22 schrieb Herbert J. Skuhra:
> On Tue, 14 Jun 2022 03:01:41 +0200, Masachika ISHIZUKA wrote:
>>
>>   I updated to master-n256084-5dd1f6f1441 (1400061) and this
>> leads to bc to 5.3.1.
>>   Previosly, 'BC-ENV-APRG=3D-P' or 'bc -P' were working but it
>> doesn't work on 5.3.1.  Is there any way to supress prompt ?
>=20
> This is fixed in 5.3.2:

This version is already available as a port, but it cannot be
built in the base system at the default WARNS level.

I had suggested a different patch that was tested in base and
have re-submitted that patch after noticing the issue with the
current code.

Regards, STefan

--------------yD4bpOiCSRw1SEKhcsED9w4j--

--------------A1g3JgIaC0jsOkJeTou8PlS3
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmKo+tAFAwAAAAAACgkQR+u171r99URS
Vwf/YD0N+jjkOpLydggw7xfnXKvJ/R564e6t8Fyd0q1+O7BSR8WuFwtTNwwOAn4SXAX8PV613Uuv
PRQk/xd+kDwMtGbhMyOoJY+DoxpRxPgRuVbL/4BXyz469n7sYcbnC3RvYr15KRJ0uC0CqKlw7OqP
PHcvEUUgLRc2/L4kQILjoPyd0S5F95KsgCzWeoYU6yV9YqeEyv8SkABBbhdXWBuQzEyDduLRJpBh
n6QJD+lpAyRmGzLvp13V4XYCrR/95N7h1TUybEiX1+RJEf1caX3lm/K0a4P5YW+mPOyF6WxGGyxV
cYC24sIvcxIhz6qCtJEAjkVw70I2sZTV4Az/FxQOIg==
=oiOf
-----END PGP SIGNATURE-----

--------------A1g3JgIaC0jsOkJeTou8PlS3--

From nobody Wed Jun 15 00:00:00 2022
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 106BC8366A4;
	Wed, 15 Jun 2022 00:00:01 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LN55s02DMz3HpT;
	Wed, 15 Jun 2022 00:00:01 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1655251201;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=;
	b=ejO+weJS70fWeZfurX8uei/rMDQlMf6m9uDrBoVNnlOSzZujJkDkZKau39tDYmomZGQf7C
	pLoCHQ8hVEO9W1Dbdlzr0IwZjXmwqXgftgEdHZTmfRjBsWTxOyAf0xDIbF2Nfq2jIZGrUs
	CY6h9SzSoeC0f8nK6mHRInRFI0mNurNMZm/L29KfoPvhoUjCmnF6sF7BfGJuQRP3XjsuPj
	ysqc47K50zdIFPBFKmpgwa1BQtzksXKqSYiTcEZX4LXLxFVcMZdqRAzQpANcX2Bz0Wt7pu
	gkWO5KbJHz8tpYoxyu+EymhmbU9qEaNbCx15T8u0K7DyZgDiYPp1sGOeZEp7zg==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id D3097112F7; Wed, 15 Jun 2022 00:00:00 +0000 (UTC)
To: freebsd-quarterly-calls@FreeBSD.org
Subject: [2 WEEKS LEFT REMINDER] Call for 2022Q2 quarterly status reports
Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,info@bsdcan.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org
Message-Id: <20220615000000.D3097112F7@freefall.freebsd.org>
Date: Wed, 15 Jun 2022 00:00:00 +0000 (UTC)
From: Lorenzo Salvadore 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655251201;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=;
	b=LRgX6svqIssrrbjtXEGT4EaI5MYY6+HnWzEfhLag0K3Df9rgYPwfgN5Z+04QBBNqYnFhqW
	RvWoe/1i0G+LfONmnKMBtgmnFQ4qpVlaOlaCfnmyhp6p9zusxUVyM1nATVydMwQm8zhr4w
	Ns6p2McUu66NPoVtOfwLGy0Lqe2F4tTX5Qd0iPpNJT4MGfaYa/IeV3YHHq7o4To7fxBUPK
	+Y9AOyLGy9SRnZZVrXKS/bHSoelBsFEcBKkxcl1wMV2gyFTZRo4yWVYaAF6ExzuNeLbnb1
	EXHEx8XIiuhj+FwC8lOSAKSQIlkwwHVrbp1ZRR2Dcm/qPr8zx9c2Uo6De5J/RQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655251201; a=rsa-sha256; cv=none;
	b=sd/cK95pWT5oTFAi9z0jRRtrVRZrF8PuxcCibrAKLuEfQkU3Tx8kMp3Sv41IStHeYQu6k6
	+/FgQJCAm+AU3+vq546QiMswXTCR2atg9s+hYQ8C4oqdTcFI0GsdM40t9dyB1yU+Gmp6S1
	Do0EnL1/nSTpvzjzgizWNe/8dly0y2TnvSFuc2CjaAR8t47NJfPFgMdnH4LPz5kc6IiVch
	LTtfkc+MyC564oaYSYXZbJa19MYE7xssqKpxxQMIk6+FFkFpPQb2dmNDfVPNgRFJmEovC6
	MPdKVmfxlM93wFEnGFotXVsAmAeeoBIFhWFopIjRXlRDAK7oe+8+93576bKLPQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
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

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
June, 30th 2022 for work done since the last round of Quarterly Reports:
April 2022 - June 2022.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the AsciiDoctor template, fill it in, and
email it to quarterly-submissions@FreeBSD.org.
The new AsciiDoctor template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc

We look forward to seeing your 2022Q2 reports!

Thanks,

Lorenzo Salvadore (on behalf of quarterly@)

From nobody Wed Jun 15 22:47:13 2022
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 3A7DC841969
	for ; Wed, 15 Jun 2022 22:47:33 +0000 (UTC)
	(envelope-from ish@amail.plala.or.jp)
Received: from msc11.plala.or.jp (msc11.plala.or.jp [60.36.166.21])
	by mx1.freebsd.org (Postfix) with ESMTP id 4LNgRl36T4z4lbm
	for ; Wed, 15 Jun 2022 22:47:30 +0000 (UTC)
	(envelope-from ish@amail.plala.or.jp)
Received: from localhost ([2400:4050:9320:7a00::8]) by msc11.plala.or.jp
          with ESMTP
          id <20220615224722.LMHX31769.msc11.plala.or.jp@localhost>
          for ; Thu, 16 Jun 2022 07:47:22 +0900
Date: Thu, 16 Jun 2022 07:47:13 +0900 (JST)
Message-Id: <20220616.074713.228633784522673985.ish@amail.plala.or.jp>
To: current@freebsd.org
Subject: Re: How to supress prompt on bc 5.3.1,Re: How to supress prompt on
 bc 5.3.1
From: Masachika ISHIZUKA 
In-Reply-To: <222ac8d4-3c57-745e-939d-bc0c325ede4f@FreeBSD.org>
References: <20220614.100141.1363594437311677262.ish@amail.plala.or.jp>
	<87k09j82zb.wl-herbert@gojira.at>
	<222ac8d4-3c57-745e-939d-bc0c325ede4f@FreeBSD.org>
X-Mailer: Mew version 6.8 on Emacs 28.1
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-VirusScan: Outbound; mvir-ac11; Thu, 16 Jun 2022 07:47:22 +0900
X-Rspamd-Queue-Id: 4LNgRl36T4z4lbm
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of ish@amail.plala.or.jp designates 60.36.166.21 as permitted sender) smtp.mailfrom=ish@amail.plala.or.jp
X-Spamd-Result: default: False [-1.80 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 FROM_HAS_DN(0.00)[];
	 MV_CASE(0.50)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DMARC_NA(0.00)[plala.or.jp];
	 R_SPF_ALLOW(-0.20)[+ip4:60.36.166.0/24];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MID_CONTAINS_FROM(1.00)[];
	 MLMMJ_DEST(0.00)[current];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:4713, ipnet:60.32.0.0/12, country:JP];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_LOW(-0.10)[60.36.166.21:from]
X-ThisMailContainsUnwantedMimeParts: N

>>>   I updated to master-n256084-5dd1f6f1441 (1400061) and this
>>> leads to bc to 5.3.1.
>>>   Previosly, 'BC-ENV-APRG=-P' or 'bc -P' were working but it
>>> doesn't work on 5.3.1.  Is there any way to supress prompt ?
>> 
>> This is fixed in 5.3.2:
> 
> This version is already available as a port, but it cannot be
> built in the base system at the default WARNS level.
> 
> I had suggested a different patch that was tested in base and
> have re-submitted that patch after noticing the issue with the
> current code.

  Thank you for commit.

  'bc' 5.3.3 works fine on master-n256152-ce00b11940a.
-- 
Masachika ISHIZUKA

From nobody Thu Jun 16 01:22:13 2022
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 4AF7B83C304
	for ; Thu, 16 Jun 2022 01:22:22 +0000 (UTC)
	(envelope-from imb@protected-networks.net)
Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.protected-networks.net", Issuer "R3" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LNktP2QXSz3PtB
	for ; Thu, 16 Jun 2022 01:22:21 +0000 (UTC)
	(envelope-from imb@protected-networks.net)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=
	protected-networks.net; h=content-transfer-encoding:content-type
	:content-type:in-reply-to:from:from:references:content-language
	:subject:subject:user-agent:mime-version:date:date:message-id;
	 s=201508; t=1655342534; bh=g9IOf3H5xTTzNH2wUhnu8fqGnuYRZqojo7XO
	EC060i8=; b=VbYHC+ltvgXcqtHDgA9+1j+BTW7Q5wpIer38blxpAv6k4D/WMxL+
	kl/aIk1jNyroZPT/on1PfQm131wVBKQn0ONT5gcG75G2B47lNDWvdFMo9ECOdxIh
	uz30i/IjL5t3MNcIhZ3mDIL5kkBYhysndXk1XW1kK4etVVQjhKMO3sU=
Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(Client did not present a certificate)
	(Authenticated sender: imb@mail.protected-networks.net)
	by mail.protected-networks.net (Postfix) with ESMTPSA id 4B199EC4D
	for ; Wed, 15 Jun 2022 21:22:14 -0400 (EDT)
Message-ID: 
Date: Wed, 15 Jun 2022 21:22:13 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: How to supress prompt on bc 5.3.1,Re: How to supress prompt on bc
 5.3.1
Content-Language: en-NZ
To: freebsd-current@freebsd.org
References: <20220614.100141.1363594437311677262.ish@amail.plala.or.jp>
 <87k09j82zb.wl-herbert@gojira.at>
 <222ac8d4-3c57-745e-939d-bc0c325ede4f@FreeBSD.org>
 <20220616.074713.228633784522673985.ish@amail.plala.or.jp>
From: Michael Butler 
In-Reply-To: <20220616.074713.228633784522673985.ish@amail.plala.or.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LNktP2QXSz3PtB
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protected-networks.net header.s=201508 header.b=VbYHC+lt;
	dmarc=pass (policy=reject) header.from=protected-networks.net;
	spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net
X-Spamd-Result: default: False [-4.00 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 DKIM_TRACE(0.00)[protected-networks.net:+];
	 DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 6/15/22 18:47, Masachika ISHIZUKA wrote:
>>>>    I updated to master-n256084-5dd1f6f1441 (1400061) and this
>>>> leads to bc to 5.3.1.
>>>>    Previosly, 'BC-ENV-APRG=-P' or 'bc -P' were working but it
>>>> doesn't work on 5.3.1.  Is there any way to supress prompt ?
>>>
>>> This is fixed in 5.3.2:
>>
>> This version is already available as a port, but it cannot be
>> built in the base system at the default WARNS level.
>>
>> I had suggested a different patch that was tested in base and
>> have re-submitted that patch after noticing the issue with the
>> current code.
> 
>    Thank you for commit.
> 
>    'bc' 5.3.3 works fine on master-n256152-ce00b11940a.

There's still some remaining buildworld left-overs in /tmp from this 
series of updates ..

imb@toshi:/home/imb> ll /tmp/*tmp
-rw-r--r--  1 root  wheel  6768 Jun 15 12:18 /tmp/bc_help.txt.XBwzl9An2r.tmp
-rw-r--r--  1 root  wheel  6768 Jun 15 11:26 /tmp/bc_help.txt.zLR884lFpG.tmp
-rw-r--r--  1 root  wheel  5797 Jun 15 12:18 /tmp/dc_help.txt.RGfFwWi2Yh.tmp
-rw-r--r--  1 root  wheel  5797 Jun 15 11:26 /tmp/dc_help.txt.oltK8Dc7mR.tmp
-rw-r--r--  1 root  wheel  3416 Jun 15 12:18 /tmp/lib.bc.NuspIZHi5s.tmp
-rw-r--r--  1 root  wheel  3416 Jun 15 11:26 /tmp/lib.bc.wwZJr98NlN.tmp
-rw-r--r--  1 root  wheel  9069 Jun 15 11:26 /tmp/lib2.bc.5ywBAhZgwg.tmp
-rw-r--r--  1 root  wheel  9069 Jun 15 12:18 /tmp/lib2.bc.D4PYZlxfWk.tmp



From nobody Thu Jun 16 06:19:35 2022
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 D6E9084421B
	for ; Thu, 16 Jun 2022 06:19:47 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.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 4LNsTZ2mbzz4nRM
	for ; Thu, 16 Jun 2022 06:19:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655360379; bh=sYYENGJo2mvQDINFGGjWh9IHhiN3U7QeXQmo2Avgy/I=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=VFmAgIq1PxNixRBJGGZ4nDfUP8NOTn5FS2OIWYL91dzlJpiQt6/EixLCCa7LhG0yos71/E2Zm1mJpRGtCjvLMLtW3NDXrla1Uk+Gb1Zgvf0Wr3Mmukgv6Bl5gtUkeUtWXwf0UbnqqivjdL6Ac3Q+3RVfnWyQArMMRBDWk/Wz0twez2w8/KYiR3PTYpeZpNIGsGuzYOSK85G4UYj52NWYLkEXgxqjAL8bNcel5ow7WWrwZNzvZMg/Z2FRjE9lr4noPs1F43IOXvhqi7wj57JzfrHt8aHFLwrD6VknzPt67UGxKunHKTpr1TZZgy6Iffr4AaA6j9JDe71fsblJBfHb1A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1655360379; bh=NS0EdNkX9MsvLI0/feHvKwxcQb/GoJGj4hMFcEo0vc7=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=A+/ALwkm4uNSwx7UpsPa1pqLdZvUZtOrHYFO+zHOmXoDwnvbdfMvofMhRauY0sjQIVRxQxMDUG75Ha1mBuTWMRDc5HelSLDeqjn/ZIoqSsNj7SwCHYISHZnCtGpwoUtukUYh+tSBALM76ogthmuUZyr8QqkOrehEw159SxXhoEcS4GRr6ZcY9FH1C1zmsajFq0ZIs632ZPnZ2xx1iEKOO6AD0vDsxi+WC/pmlWiYroD++mBoHX2hgG6ejKbui1BfriCM9PrDI+YBT2x183GhwzWwfjZHT9+j/wz/Md103HEVVAx/SeOH+AWdbLp6P6r9EqhEsJPZXlbA1mwykg86EA==
X-YMail-OSG: u9gV1owVM1n9vUxqL4P257J_a.1hPXLp39uamxZUAUBIKO3S9HgO9Hdlu9_SQZq
 8JwAbmUcNeHt1tX.HUdsDhzARizpl_GuhqOH81OxkkQK.5sfyA4HKw.UqxVaGCtO2pfKLaPNBryA
 vol4BE4sOtsyu4W5PJKPWBqdjouy66AHdbQx4VfAOQUztI4PIDeDmymPzBhIb9xva6h.ZrQKolF5
 GYUaj25LzXEumgENl7yR03iNQfd7GQcQXgaKcZ8_UYY7JB3SbdsFvonOM5BDx_mkcMdqYUej7opN
 Vkar.DH1BGEd0GEvCadROaPiXVT.cByKBE6vj4vH_vxV23IyHSP_EjG6ZtwOkvHmRqor_UpKwpMu
 PWX7_zVllRE1vXoo.pITh6Zsv6hampL8lr9Y5qO0UT3CdCk_Z8PQGgqodnShtfkgURgp3ATO1lDJ
 Yy73X2rWHozZtipPrDLpeVL7zqXiPZbLi3RIjQuFabg0lY.zDaSSwnWqXj4Fe3KsQxZWxJJvtnXs
 pRwLPEceS_iwPZUwSNHhSF.0OCwSJ99NVYMQnwR2eAYzh7X.4Qt691gphlz_cCCxbfyye3_fejVG
 PyOs12Lhh1FVQOxF.7RXwjdDA6MIX71XgQZ0y90XrLxQqg063z2BiF3MwHOmLyRjlPHeTPJjD_3U
 ZUkBUE1dZZL.8EEKnocs9.bGdUOKrwLyiPc6841b31fcIYLuqTsgNvjhqJWnZVV4XqLdoT1IDyOA
 Q4UcCypcGyLqbFcEVFLfCfAwIAARcgTTjoyxWCLCn_NIfitHDFTr4RXZ13ndfGkLppN.y3m0RVJG
 dSNvzZ7aurRBU3wp3tell4kYkzG8h4O32hz_PIL5sXCG0X3424fyubIAOU9BGfAR5WpOaxMOJ4xN
 C0WNVUdW7mmDFuf4CBQ.pvqQhhY__PCrXv1BTMMY2XVfj_xG3Nth8PSns.FN.bWEf7oP.6hyJOG8
 ZHdzCvluPfrNHDzOPBeas_oWuiL0xEkAA9dcMT9ou65UrSe.lccMmH7E_ZzEKngqOX5D6jA8_Gkb
 DJZCGKpGDYdD3QylJjeZRjuEKq0KCnT7SyRQJCii1ppTE3AYhAh0G_YLGS7alc1eaN.JHuNciydX
 4AxWZLs7cv_bu2wJWXc_os2rKGOBLZ7Vt.xj5dXshRWvgxWSjV7jeY1tYt5KaURE2rfce6qysLiW
 KMyI7.lE3d6c4jGhdxICg5Fq.GoE7ITBU9Y2GN89_JncEliACWZZPCIjgveRq_S2CWUL002.H9Ex
 XdJ31FSWn_po2st1dwgHAxnKPCA.HjHe0ZuMByWu1VBZShcd5PKg7qpKz6UbTJY9qY687fZ.WIB2
 wmaSDt2jZ_m8_OaXcgBeN6G.ffdIjBQDobbMd4EQS5Qlbmnh6BZshmmShYk.MDepofSt.Y9lDPa0
 i_MEbk7FnYg8ApQEW.uyFSRkRPCY8U7IJI1Jydjm7Z_BKLsm1EkBmp9iLqqlCwie.iCDkaPAAbHh
 tJY9se1FbSNtk43GM5CAgucIfUe9MexciiBcQlUMEP3UxqXXfp88NNXYcsdPEynjUty2nL8xVLPh
 TWn.1RkiyL2RYGzEbLjq8u2lTNXxXXWG_yIdTw1_Kkxc.KRBnDu32NxxcYXaaVIP.PaaUBi34r0F
 Re8WQ7uCYXV9xvMoJnBy4pGOMXXt2JDFy.dOdl6SU2UdRNFD2N4sR3VV.aXu.Rx2yepCHfIbtA5R
 mXzY4YhRFYspoTsOW2XTi8XHddntbe2d8RRvk8yTC2_nYUqM13x4LkqV6zSzn7clO.htuedO6.oF
 f3NYDrhwqDb9LAohkMG7xFVoz447.d1vvnTDnzzcQuPoijZpr1c27kiUvIcma2G2C8b8fa1COC2X
 RHx_7nXZUo3fXW2HeunlitHL.Ar6OaudrJ7kjaAiCIE1vd_3S7cnRwFRc7dVPRZDWKF8KCAv4Edg
 VgUQpc9nIrYScOZOL6z8ZCER4IyFaQDzEqqgom1QBe47y08teLOGwA2GV4jMYgZwiolEiNv7_vhe
 pwmmo2j7t6ooBZgZG27iU5taexmZtOiJ4XEplZe0EXazvlbmdN0SCThcOs980I9vyLlg5n2SbvCy
 wBDEVRX8GTgdTgYZ6OI0Id4KrMYSNmTnDuKZ0UcYEoxjsB1XH9bl4HTCo.z0dt9GuenYI1WURqQB
 YDNfRml6Ed0psmZJkobBpu7k6s3.EHpZ4i3PXLzc7pTEnqcCqN8NVq6x6MPjrtTAWxIhXbHW7zPb
 RXl03hhYJGEAcoZ.C3LVqp.X1trghXQ1rTMGR5PAg7hubhWvfjTHsH5dmE9.fjqvei.CnFfdlxtz
 Zk7mZ4hdkwztGVocHAsqkVd6iY5wMiPr2EsqMlCQl
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Jun 2022 06:19:39 +0000
Received: by hermes--canary-production-ne1-6b56569f5b-6j7sf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5c8578a9316fd2380c4c4c987f8397b5;
          Thu, 16 Jun 2022 06:19:36 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: ampere3 activity is not showing up on
 https://pkg-status.freebsd.org/?all=1&type=package
Date: Wed, 15 Jun 2022 23:19:35 -0700
References: 
 
 
 <8B511C8C-8E7F-465D-8B70-447EB34DD1EA@yahoo.com>
To: freebsd-current 
In-Reply-To: <8B511C8C-8E7F-465D-8B70-447EB34DD1EA@yahoo.com>
Message-Id: <51AFDFDC-2649-4471-AF2A-45F71BAF56D0@yahoo.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4LNsTZ2mbzz4nRM
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=VFmAgIq1;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.23 / 15.00];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 SUBJECT_HAS_QUESTION(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.73)[-0.729];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jun-13, at 22:44, Mark Millard  wrote:

> On 2022-Jun-13, at 22:14, Philip Paeps  wrote:
>=20
>> On 2022-06-13 00:16:55 (+0800), Mark Millard wrote:
>>> ampere3's activity is not showing up on the page:
>>> https://pkg-status.freebsd.org/?all=3D1&type=3Dpackage
>>>=20
>>> but:
>>>=20
>>> http://ampere3.nyi.freebsd.org/#latest_builds
>>> and:
>>> =
http://ampere3.nyi.freebsd.org/build.html?mastername=3D130arm64-default&bu=
ild=3Db44e82e7d313
>>>=20
>>> shows a currently active build (but with only 2 ports remaining).
>>=20
>> pkg-status.freebsd.org is maintained on GitHub, outside the =
clusteradm automation.  I sent in this patch a couple of months ago, =
when I set up ampere3:
>>=20
>> https://github.com/bdrewery/pkg-status.freebsd.org/pull/12/files
>>=20
>> This was merged last week but it doesn't look like there's any =
automation to keep the running infrastructure in sync with that =
repository.  There were some reassuring screams in a logfile after I =
chanted some incantations in a the jail running pkg-status.freebsd.org.
>>=20
>> Let me know if that fixed it.
>>=20
>=20
> Well, I now see 34 builds that were via ampere3. This
> was via use of:
>=20
> https://pkg-status.freebsd.org/?all=3D1&type=3Dpackage
>=20
> They go back to 2022-Feb-26, with the most recent still
> in progress (371 remaining).

An interesting oddity is how long it has been since
ampere3 has had all 30000+ ports queued for one
130arm64 default "bulk -a -c" style run (start time):

Sat, 09 Apr 2022 01:03:01 GMT

The largest after that queued 16404 --and that was only
10 days later so or.


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


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


From nobody Thu Jun 16 09:45:53 2022
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 F2EB783FB6D
	for ; Thu, 16 Jun 2022 09:45:58 +0000 (UTC)
	(envelope-from se@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LNy3V4cgQz3pPJ;
	Thu, 16 Jun 2022 09:45:58 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1655372758;
	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=dTDvsrcGS3MH3joaFOd+kWlhrHfWo/6PlmWqtnikdmU=;
	b=mPzJyIggNWj3c4SzFaLAYCgpMR6LPUCyZeVw4pnO6V3JlDQOcbRSA93uIRid20hNZ1fbpX
	9AaUAY9vKnNC0ciuMvJCsXQDSoIpDoq0kjsJ/FkndnwYcawdpVLetawrFZhLI7Y4Gah9Hg
	r//O8kDnH96ROIDR0uoHH05Wso7GsS5zpg7xPqbkozHt1cHpE4DBrX32lR33AS3m0Aw0kf
	mljNr/R338SMitVU37eQUVxHUlYgURsIJS0/tP4zYRdRvOPyczWN931bKgjGQHzpnWiu18
	FlVYfJaJxfD/q3xm4h88EPMvYal+1p1+fO18k4n+Fl6KaSu3dMUR5KyPGS8ZkQ==
Received: from [IPV6:2003:cd:5f17:8800:bde9:2858:8dd2:3c3e] (p200300cd5f178800bde928588dd23c3e.dip0.t-ipconnect.de [IPv6:2003:cd:5f17:8800:bde9:2858:8dd2:3c3e])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: se/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 12C0B175D;
	Thu, 16 Jun 2022 09:45:57 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
Message-ID: <061a512b-d70e-782d-dba0-3860215522fa@FreeBSD.org>
Date: Thu, 16 Jun 2022 11:45:53 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.10.0
Subject: Re: How to supress prompt on bc 5.3.1,Re: How to supress prompt on bc
 5.3.1
Content-Language: en-US
To: Michael Butler 
References: <20220614.100141.1363594437311677262.ish@amail.plala.or.jp>
 <87k09j82zb.wl-herbert@gojira.at>
 <222ac8d4-3c57-745e-939d-bc0c325ede4f@FreeBSD.org>
 <20220616.074713.228633784522673985.ish@amail.plala.or.jp>
 
From: Stefan Esser 
Cc: freebsd-current@freebsd.org
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------KjDVSWkgs7W4QQLtgugBhl0e"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1655372758;
	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=dTDvsrcGS3MH3joaFOd+kWlhrHfWo/6PlmWqtnikdmU=;
	b=qRdchuz61FwRyzb4u0z38cEuhRfmeXo2LdTs02oXUlQgu7Oq01HMPgNzC7BdJAJWi4UHzX
	Fcj0WfvLekDyhVA7B15RpBIgjCYcQlznEhbZSe1RFulcFOGTO2PbHnlxxtMEbEKrxDpqW6
	OYFHENiHBt2oOCmJWWUTGX7r4AB3MLntAsX9dSkFkYse67VvxgG/OUgDPjnT5bE+IuaPwn
	18soEILKNrwFYpsFT/EeueVmTuurokwokRrtF/B9YJ/2Pocv0OOP37YgmV3kqqN7UzPml1
	FrFABwSUWw1C8cvM3HVa2/EJZwX39wdXNEEPwxAAABnQKUsYazwIE+pTeCK1hQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655372758; a=rsa-sha256; cv=none;
	b=nHkE/rQ/1f4kFAJVcM/sgPgq9zqhDPunypnQuIZA9bKmF5fP0WzMS6fnT1UgrAssd3r5Is
	8OkotzNAdN++I0wK1lVZDmeaaZSDhqyYw5CZc+62iSH1vUgZQDv3BrvJ4nauNojCNFYuO8
	wlTLiCllZpd9qsbfXAjpSCElmOsZsiGLrROiuyJFfe+yJ4rnfR5FgRf/o2aOIkKm3Lg7hn
	bZejRhyWAn+Ppt50iaCjapwVMYBBsRAbOgiT6gKsXnXQvq6dbpA4cZvIShxdZdjKYFAYHZ
	E5m0qLsmJQYSXqrWilWhR3zRCWxvsrCKJL+IHcnh1CXoWbvZA7tr2j61eAQBTA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------KjDVSWkgs7W4QQLtgugBhl0e
Content-Type: multipart/mixed; boundary="------------Mj7QZX6AHcZ0Kp9Gc1CcY3SV";
 protected-headers="v1"
From: Stefan Esser 
To: Michael Butler 
Cc: freebsd-current@freebsd.org
Message-ID: <061a512b-d70e-782d-dba0-3860215522fa@FreeBSD.org>
Subject: Re: How to supress prompt on bc 5.3.1,Re: How to supress prompt on bc
 5.3.1
References: <20220614.100141.1363594437311677262.ish@amail.plala.or.jp>
 <87k09j82zb.wl-herbert@gojira.at>
 <222ac8d4-3c57-745e-939d-bc0c325ede4f@FreeBSD.org>
 <20220616.074713.228633784522673985.ish@amail.plala.or.jp>
 
In-Reply-To: 

--------------Mj7QZX6AHcZ0Kp9Gc1CcY3SV
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Am 16.06.22 um 03:22 schrieb Michael Butler:
> On 6/15/22 18:47, Masachika ISHIZUKA wrote:
>>>>> =C2=A0=C2=A0 I updated to master-n256084-5dd1f6f1441 (1400061) and =
this
>>>>> leads to bc to 5.3.1.
>>>>> =C2=A0=C2=A0 Previosly, 'BC-ENV-APRG=3D-P' or 'bc -P' were working =
but it
>>>>> doesn't work on 5.3.1.=C2=A0 Is there any way to supress prompt ?
>>>>
>>>> This is fixed in 5.3.2:
>>>
>>> This version is already available as a port, but it cannot be
>>> built in the base system at the default WARNS level.
>>>
>>> I had suggested a different patch that was tested in base and
>>> have re-submitted that patch after noticing the issue with the
>>> current code.
>>
>> =C2=A0=C2=A0 Thank you for commit.
>>
>> =C2=A0=C2=A0 'bc' 5.3.3 works fine on master-n256152-ce00b11940a.
>=20
> There's still some remaining buildworld left-overs in /tmp from this se=
ries of
> updates ..
>=20
> imb@toshi:/home/imb> ll /tmp/*tmp
> -rw-r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 6768 Jun 15 12:18 /tmp/bc_hel=
p.txt.XBwzl9An2r.tmp
> -rw-r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 6768 Jun 15 11:26 /tmp/bc_hel=
p.txt.zLR884lFpG.tmp
> -rw-r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 5797 Jun 15 12:18 /tmp/dc_hel=
p.txt.RGfFwWi2Yh.tmp
> -rw-r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 5797 Jun 15 11:26 /tmp/dc_hel=
p.txt.oltK8Dc7mR.tmp
> -rw-r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 3416 Jun 15 12:18 /tmp/lib.bc=
=2ENuspIZHi5s.tmp
> -rw-r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 3416 Jun 15 11:26 /tmp/lib.bc=
=2EwwZJr98NlN.tmp
> -rw-r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 9069 Jun 15 11:26 /tmp/lib2.b=
c.5ywBAhZgwg.tmp
> -rw-r--r--=C2=A0 1 root=C2=A0 wheel=C2=A0 9069 Jun 15 12:18 /tmp/lib2.b=
c.D4PYZlxfWk.tmp

These left over files appear to be due to a commented-out "rm" at the
end of scripts/functions.sh, probably due to debugging of recent changes
in gen/genstr.sh:

	# Remove multiple blank lines.
	uniq "$_filter_text_temp" "$_filter_text_out"

	# Remove the temp file.
	#rm -rf "$_filter_text_temp"	<----

	# Reset IFS.
	IFS=3D"$_filter_text_ifs"
}

You can fix it locally by removing the "#" in front of that rm command.

I'll contact the author of this software to get this fixed in his reposit=
ory
and will then import that change. (The author wants downstream versions t=
o
not diverge from his repository and I respect this wish.)

Thank you for reporting this issue!

Best regards, STefan

--------------Mj7QZX6AHcZ0Kp9Gc1CcY3SV--

--------------KjDVSWkgs7W4QQLtgugBhl0e
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmKq+9EFAwAAAAAACgkQR+u171r99USu
LAf9Gx6ZxvQ8qs48+pbsKKS8j0ASMbse9N7fvLS+uJPTGzrGQs9qsAcHh21LRkPA3d/MxhjGeUyH
9G2TH5lVj6vYHbFiIT9tH7KY8RgYhBk1rHWC0kVVkoO3ZbaoDkcKTs5DHg+GQ+ETAwDm5SRfeaN9
lEDBY3A+3G7KdvWKqtYs/nUtNrOah43WGpg+awtOXEW6AdSUszhmNIMKTHiIIJvOlIro+IK+BCwz
yuxes/ip8a0CsgwQSZD56yAhvibXP2b0O6mDiusSTMmB+hj3WokFemeVHo/aT6CCqzvTkpF75u7w
SXKDnyJe83ge3uBSu6Mz/gta8quYgPJ36WTOISQm8Q==
=Pa5i
-----END PGP SIGNATURE-----

--------------KjDVSWkgs7W4QQLtgugBhl0e--

From nobody Thu Jun 16 12:21:31 2022
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 1D6908323F2
	for ; Thu, 16 Jun 2022 12:21:42 +0000 (UTC)
	(envelope-from SRS0=DddI=WX=quip.cz=000.fbsd@elsa.codelab.cz)
Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4])
	(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 4LP1W90VZvz4hMw;
	Thu, 16 Jun 2022 12:21:41 +0000 (UTC)
	(envelope-from SRS0=DddI=WX=quip.cz=000.fbsd@elsa.codelab.cz)
Received: from elsa.codelab.cz (localhost [127.0.0.1])
	by elsa.codelab.cz (Postfix) with ESMTP id 970EA2842F;
	Thu, 16 Jun 2022 14:21:33 +0200 (CEST)
Received: from [192.168.145.49] (ip-89-177-28-143.net.upcbroadband.cz [89.177.28.143])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by elsa.codelab.cz (Postfix) with ESMTPSA id DA81B2842E;
	Thu, 16 Jun 2022 14:21:31 +0200 (CEST)
Message-ID: <254a0b5e-72d9-f93e-0c49-82b50a35db41@quip.cz>
Date: Thu, 16 Jun 2022 14:21:31 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14
Content-Language: en-US
To: Rick Macklem , David Chisnall
 ,
 "freebsd-current@freebsd.org" 
References: 
 <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org>
 <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz>
 
 <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz>
 
 <54704b99-7b89-76a4-0368-79bee391926d@quip.cz>
 
 
 
 
 
 <489849ca-a404-fb54-81d1-d62ea18c5832@FreeBSD.org>
 
From: Miroslav Lachman <000.fbsd@quip.cz>
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LP1W90VZvz4hMw
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of "SRS0=DddI=WX=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=DddI=WX=quip.cz=000.fbsd@elsa.codelab.cz"
X-Spamd-Result: default: False [0.11 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 DMARC_NA(0.00)[quip.cz];
	 AUTH_NA(1.00)[];
	 NEURAL_SPAM_MEDIUM(0.85)[0.853];
	 NEURAL_HAM_LONG(-0.98)[-0.976];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.97)[-0.972];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=DddI=WX=quip.cz=000.fbsd@elsa.codelab.cz];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ];
	 FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=DddI=WX=quip.cz=000.fbsd@elsa.codelab.cz];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 24/01/2022 16:13, Rick Macklem wrote:

[...]

> So, I think Mark and Yuri are correct and looking at up to date
> Illumos sources is the next step.
> (As I mentioned, porting the Apple sources is beyond what I am
>   willing to attempt.)
> 
> rick

Hello Rick,
I would like to ask you I there is some progress with porting newer 
SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a 
possibility where to start porting?

We have more and more problems with current state of mount_smbfs. I 
would be really glad if "somebody" can do the heroic work of 
implementing SMBv2 in FreeBSD.
Maybe it's time to start some fundraising for sponsoring this work?

Kind regards
Miroslav Lachman


> ________________________________________
> From: owner-freebsd-current@freebsd.org  on behalf of David Chisnall 
> Sent: Monday, January 24, 2022 5:16 AM
> To: freebsd-current@freebsd.org
> Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14
> 
> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca
> 
> 
> On 22/01/2022 23:20, Rick Macklem wrote:
>> Mark Saad  wrote:
>> [stuff snipped]
>>> So I am looking at the Apple and Solaris code, provided by rick. I am not
>>> sure if the illumos code provides SMB2 support. They based the solaris
>>> code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure
>>> predates smb2 .
>>>
>>> https://github.com/apple-oss-distributions/smb/tree/smb-217.19
>>>
>>> If I am following this correctly we need to look at Apple's smb client
>>> from OSX 10.9  which is where I start to see bits about smb2
>>>
>>> https://github.com/apple-oss-distributions/smb/tree/smb-697.95.1/kernel/netsmb
>>>
>>> This is also where this stuff starts to look less and less like FreeBSD .
>>> Let me ask some of the illumos people I know to see if there is
>>> anything they can point to.
>> Yes. Please do so. I saw the "old" calls fo things like open and the
>> new ntcreate version, so I assumed that was the newer SMB.
>> If it is not, there is no reason to port it.
>>
>> The new Apple code is a monster. 10x the lines of C and a lot of
>> weird stuff that looks Apple specific.
>>
>> It might actually be easier to write SMBv2 from the spec than port
>> the Apple stuff.
>> --> I'll try and look at whatever Microsoft publishes w.r.t. SMBv2/3.
>>
>> Thanks for looking at this, rick
> 
> The docs are public:
> 
> https://docs.microsoft.com/en-gb/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962
> 
> 
> Note that the spec is 480 pages, it is not a trivial protocol to
> implement from scratch.
> 
> David
> 
> 


From nobody Thu Jun 16 13:56:19 2022
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 C9EE18442AE
	for ; Thu, 16 Jun 2022 13:56:28 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2068.outbound.protection.outlook.com [40.107.115.68])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LP3cX0DXxz3DCw;
	Thu, 16 Jun 2022 13:56:27 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=nM3YB10zxoQ093Z9GNPmRIT30DIP0PYKhik3RCXnIfo81ciosU2RGMLATwpZjYu0AhNCxjS0c4nTiMObX6hI40k6RmkBjm9uTxertmiB41Kxk//Zj8vGOhv87sMfzTl/PFCB0Wp3a9v/8MmxLQEzRx/zvfL3hKf5ioTQSUpa7Ox6c5fr8CuRyO6tYbu1FWkzKKIhHxCdv3yOWNNzcL6wk0fWRq3VYhWuhCZ0KONoVflaOz2nElHI7eL6NEphB6qgTXhuD3TyxeqAlfXAEvvJP1B4f4Z3RiZDqe0XSbroPxXZVkqIrNEakGLD65RW9Qa/V9Y5FMyMsxTaN4olyimB8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CI+fasb64CXQdKANJMB4fSVhDZtsEGZ8gkciSe8y5KI=;
 b=PAkZaesnDrPKhVeTghrt5y7kKQLlafIPBAt4dDZs+ZJmKmt1W9rX7V2jS5VGDwOJOX0BjEcFAeFl8IWEB+idTozHom9nX3AGlYiwYT1x0K+PfJIc6IyZuEWHB8IijFBg5tizgAMfHLB0KjqQpwTr5mAVfP5dd5Fyve21WyMDxxYTKWbnpkPBMEAUpypZF+OheCym3RM0OoH/eFyLo0WJlfDZGMOSS8xTlC9QOimcfL1FByZJZAeY2/LWA0lrykrce+NlulVH1qyLjUSBp73lpi0jLu1s88gHd/rQ0vkyJwglL706gASdvnisOFlmDmSPId0v5aYdefviSzGK9F/3gg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca;
 dkim=pass header.d=uoguelph.ca; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=CI+fasb64CXQdKANJMB4fSVhDZtsEGZ8gkciSe8y5KI=;
 b=ZpWmGFuf/6MVNQkCZAKeom+ZfPkPUyg3ob+ccUP7qLsbJ5PvsBs2gpW6MNs0fqIzfhpxcPEZ0SrJICjyCweJTh7ZnZEjdN4mpmgx3tsxzY6+SlWHAZKGGUe5PPVT1IQiwlJfNTQA7edJymHBnURusK487EB4W9z1eM6WgCb1aa6o9Q3l3pqouxFeE7WoCiwvVnY/aopcFfv3iwhTth0oM1LbC5WurJSIH7rRDPd7g1BG1/QV/KtqrG24YDYv8LC5L8RcEB2Hz++1DNl9RRvG4XxGsdtxzdQ7NiXb2Kf5IbHBQ9sAkMZqT5lLZ05hPocnnl3fGPlYQidYPuxKurBZ8g==
Received: from YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:c01:81::14) by YT1PR01MB4379.CANPRD01.PROD.OUTLOOK.COM
 (2603:10b6:b01:33::15) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.15; Thu, 16 Jun
 2022 13:56:20 +0000
Received: from YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::b921:251e:4a0b:54fc]) by YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::b921:251e:4a0b:54fc%6]) with mapi id 15.20.5353.014; Thu, 16 Jun 2022
 13:56:20 +0000
From: Rick Macklem 
To: Miroslav Lachman <000.fbsd@quip.cz>, David Chisnall
	, "freebsd-current@freebsd.org"
	
Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14
Thread-Topic: Deprecating smbfs(5) and removing it before FreeBSD 14
Thread-Index:
 AQHXzvvFA1WWxQSLW0uUJGavCusr2KvuZUQAgABpl4WAAGcwgIBr+tlBgAGeWQCADnip0IAAAWeAgAA5aNuABGp2gIAAPwEOgAJMtYCAAFF+6YDgjuGAgAAYK2c=
Date: Thu, 16 Jun 2022 13:56:19 +0000
Message-ID:
 
References:
 
 <6f99f9bc-8831-aefe-4f73-72f50f8f347b@aetern.org>
 <79402464-f9e6-5f56-645e-cfd49640032e@quip.cz>
 
 <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz>
 
 <54704b99-7b89-76a4-0368-79bee391926d@quip.cz>
 
 
 
 
 
 <489849ca-a404-fb54-81d1-d62ea18c5832@FreeBSD.org>
 
 <254a0b5e-72d9-f93e-0c49-82b50a35db41@quip.cz>
In-Reply-To: <254a0b5e-72d9-f93e-0c49-82b50a35db41@quip.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
suggested_attachment_session_id: cf932527-bc20-c825-efbe-7697167ff7ee
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e3ede530-e092-47ab-4944-08da4f9ffda2
x-ms-traffictypediagnostic: YT1PR01MB4379:EE_
x-microsoft-antispam-prvs:
 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 LpTvjILmVcREtqnmKOpG31/jy1SPE8yufVheKiKJVMYmqxCQ0COu+7pC54O+loo+Y2oecIRlvwUY3kA9X88a5c4GZF8Yu5JVBYL/CCChvEXyxkU234jaRO+wY+CgHEK56B6Jq/33//N+u1HHYbzgtknOfX8Eo1OoRQZO0e8+EkCi7d4j1M6DlQOvN0C91cge+Isb5W2xQuFu15e6bPpqSH+U+Te6HNU5XTMzDDL0dGsiyDZjW2ABsXv1czNyfoJDXynQt8vSPl9nwrKTVGEpuaEbhCKeI0cAaHb1vyITmmBfOyfx4BnLnVvja3h4X/P0gzSKW88Y8zPf+GNy/XNA9OpWf/yn4bb/Uk0Pi/FNjNAhxCTLqGzvUUXJt4h8iQT6z3VeqwV0aKuV4YC65NYuHx466uKD9dB9v31FK/KrzhaHN+WmyjcjU7GdT3HjrnFBGhN6SAZ09Egk04pbhCEQM36n5lM+7Q0YxFB99csfrNhxL4D4G2+5lu0NG3vxHt6TtC7BCXPHNCGLjcIUbg1ILEiKTG5dBYxFrlFMIgis/qkhXYdwBBEBNCjU/Ab8JVaDj+5h3fppZ9pR/hP1SpzeAn+jui6vd8jeAv0T66PUBhHt7Xx8bhgaKsoTT8Yw5kfCvup04+1O2AHYl2sFWsq4pwcf/j2PsiPEVEjnCLijL1Rz+HrgzKbPjWJ+n5C1rkdIteFACqRSsG1XMfQy3GEOKtnJzwHk5KObU0ewAIs8pQE6LOEnac0+4dqPHeFkqz+BYRmNAIGvxVuIYfYnscKOlkGCU2iTR44On40fafrr176pIgXcn118UddviZVcQNzWMcFblp+xLSz/fkW7cYECGw==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230016)(4636009)(366004)(786003)(55016003)(38070700005)(316002)(110136005)(71200400001)(53546011)(6506007)(38100700002)(9686003)(7696005)(45080400002)(5660300002)(66946007)(86362001)(64756008)(8676002)(966005)(91956017)(186003)(52536014)(83380400001)(8936002)(76116006)(122000001)(66476007)(66556008)(508600001)(33656002)(2906002)(66446008);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?9APomGOmxBh1mvuVCSqRp5zMQnlk4ugfLo9a9movQfC/vhZ3qMiA1SS+hk?=
 =?iso-8859-1?Q?nPBlV/S1cPtKRgZKYVF0YWbOFJjDYf6fVHsdEsfug/3gd6Gh7voKWdNsFf?=
 =?iso-8859-1?Q?XMwC+e5b9TtoPE1wsnmPKzvM2whetw5TqxwjFG2biuRLyAYJTMuqJq3oxt?=
 =?iso-8859-1?Q?fyoXZIJ4QFeNegAsEqISylo5tp2LOAOOr0rjdbG3mZXw/j6BgQ64lZYScF?=
 =?iso-8859-1?Q?7s7WDOt+MZPnn1YNWzrDJNbLlqtcqnl3/7odk2xRzuFbKo+YIMRDQGd/dI?=
 =?iso-8859-1?Q?ss4CR0vzCkFdWem+UftVFyFHunfWA5TwyUutLk04Iz5fx0PZY7e5bpDVRG?=
 =?iso-8859-1?Q?rZdyYSDyoFyMctseqWCjrxUJXZpRrfbZyYOrWFeIR4qzsRlzTXjO8Viqed?=
 =?iso-8859-1?Q?XPhuKccGPG8y+ymQr1QbNNKdS1CGqRk/P8riR0ZtlsnJNZm/5CPPtk/kan?=
 =?iso-8859-1?Q?5j7YnKEsUn2aeCvB8QXS9BYDv8TcacylYUKNsnC/UCqZQKh/EpgUaz4+gz?=
 =?iso-8859-1?Q?NEa3B1sKdwKytndJg0OQJMA4ocz4oA58DIaV/5dHpgRZrUMLodnwarZBXL?=
 =?iso-8859-1?Q?LfXJ47ieTPAyrcCStZnyXCN1KVfn2Wzb2w3P+XsXRv91z7nAxp5WDkpb6U?=
 =?iso-8859-1?Q?X2DAmXRLTeWWz2HOtJhuRhk+JtYTzS1Exq9bwtPfv2nKa4sorLHpnGKBUq?=
 =?iso-8859-1?Q?9f6R0beSyiW3FEAoJX/DuqW63p8+zZciTh/KD0YDb4hiwuRvcK+1gYWAw4?=
 =?iso-8859-1?Q?TStTLnWIiYuJRjl7+eNuR3T7/8mm6hSDlKuHemM132YiYroRC6JrIpM6V7?=
 =?iso-8859-1?Q?ZJiTV6LZzU1+co1dPbecMRW+OKK8ACpJuVFAn+f1ETuZ55BzHgAE+eMRrQ?=
 =?iso-8859-1?Q?BetPsi6X6vm2cdSNLkCaJ2ARFeM+/p9qln2JAIJri5Z8AccGjtlhvNUeoB?=
 =?iso-8859-1?Q?bsxOi5J72Vu/rL27+/OOLHj5I9MUmC23oe0LwrSvQv7OOAeizYOJbuge5w?=
 =?iso-8859-1?Q?p/mCESdqsIP+JVSnljnLxwQ4ysIp6TCXtYeFbGI7udPlesek0P8WxakS24?=
 =?iso-8859-1?Q?KGvXsd9cjbLxXKc3mG11PNi207h0M9dXA0cZjs9o90AP0dwSdN5Id33fm4?=
 =?iso-8859-1?Q?D4bEdMIdnuvB+zW9PS66pNEK3WEGgobMApLhTcDvVyqBfRNOmOAiUc7OtM?=
 =?iso-8859-1?Q?ihaI5Dt5bWM1kwiAX7J/s+SxupAFijn86Dj2imJipUJVg1e+PElQCVd2ia?=
 =?iso-8859-1?Q?QpaixP3WQIw5O3GrOcduftewXzOtj73HQLMdjNOLCC5TJHoi7OAfuILLAa?=
 =?iso-8859-1?Q?pptH2vqosMRafFD/s5vLTvrA+3aiKlxzfurP3rsMPRbi+kakfRAx387x49?=
 =?iso-8859-1?Q?wk8K4YJMKuQ22BMIuU+RVQz30hQ7UW4gn9KuCpiLG/4rUysR8TKn7ZsK2s?=
 =?iso-8859-1?Q?uRF6VwUu2FK0/i7UhHOyy0TZC40a0QHs9ZdbWN8yOJohPPCtLwA7uRboX5?=
 =?iso-8859-1?Q?JXSyeQHw0yZoiIJtnCeW6wY3uM7niCpyFg9Lq1qkg0/5vgOaXr+f45Wpxa?=
 =?iso-8859-1?Q?hI524Kk48tG/YfrK9TkUHPIMiDAY1t4fVeahm9PFYWsdzHJ5WigfAjlF2g?=
 =?iso-8859-1?Q?So7E1ZqWLjQEBbfXmNlDDFHPif7G7cYqB0WA0iqvF/6aWfPtgGyl7uyn8x?=
 =?iso-8859-1?Q?6KMA2H5k4wdkJB9RIrNMclFZ71flZuuDVcXfxyipUL1dnsjIktOT1HRGrj?=
 =?iso-8859-1?Q?GLefiXdymNIztTCLUBCUcglBtnRtmuuVKyfdHIfrmu0Jv4YyrWw2zvgkMS?=
 =?iso-8859-1?Q?KI7rTH/MOoguaBFTE4xx6sBeeobVwaiiR6cpjyeoEz/dLUOXs6uI5Y4Jz7?=
 =?iso-8859-1?Q?kH?=
x-ms-exchange-antispam-messagedata-1: JVSn45dRs6rIKQ==
Content-Type: text/plain; charset="iso-8859-1"
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
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: e3ede530-e092-47ab-4944-08da4f9ffda2
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2022 13:56:19.9699
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: UG7ZykbQOfkmbQgV2HCzfkhbEvuAAA5GZr+t/+QZHZ3BKIvljiCBpboCwMxu55Eizr2CUzBFERXEmAq6jSO7Gg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB4379
X-Rspamd-Queue-Id: 4LP3cX0DXxz3DCw
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=ZpWmGFuf;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=uoguelph.ca;
	spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.115.68 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca
X-Spamd-Result: default: False [-4.05 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2];
	 FREEFALL_USER(0.00)[rmacklem];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_SPAM_SHORT(0.95)[0.948];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[uoguelph.ca:+];
	 DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none];
	 RCVD_IN_DNSWL_NONE(0.00)[40.107.115.68:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.115.68:from]
X-ThisMailContainsUnwantedMimeParts: N

Miroslav Lachman <000.fbsd@quip.cz> wrote:=0A=
> On 24/01/2022 16:13, Rick Macklem wrote:=0A=
>=0A=
[...]=0A=
>=0A=
> > So, I think Mark and Yuri are correct and looking at up to date=0A=
> > Illumos sources is the next step.=0A=
> > (As I mentioned, porting the Apple sources is beyond what I am=0A=
> >   willing to attempt.)=0A=
> >=0A=
> > rick=0A=
>=0A=
> Hello Rick,=0A=
> I would like to ask you I there is some progress with porting newer=0A=
> SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a=0A=
> possibility where to start porting?=0A=
Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date=
=0A=
and I agree that it should be easier than the Apple stuff to port into=0A=
FreeBSD.  I don't think it is "straightforward" as someone involved=0A=
with Illumos said, due to the big differences in VFS/locking, but...=0A=
=0A=
Having said the above, I have not done much yet. I've been cleaning up=0A=
NFS stuff, although I am nearly done with that now.=0A=
I do plan on starting to work on it soon, but have no idea if/when I=0A=
will have something that might be useful for others.=0A=
=0A=
> We have more and more problems with current state of mount_smbfs. I=0A=
> would be really glad if "somebody" can do the heroic work of=0A=
> implementing SMBv2 in FreeBSD.=0A=
> Maybe it's time to start some fundraising for sponsoring this work?=0A=
Well, funding isn't an issue for me (I'm just a retired guy who does this=
=0A=
stuff as a hobby). However, if there is someone else who is capable of=0A=
doing it if they are funded, I have no problem with that.=0A=
I could either help them, or simply stick with working on NFS and leave=0A=
SMBv23 to them.=0A=
=0A=
Sorry, but I cannot report real progress on this as yet, rick=0A=
=0A=
Kind regards=0A=
Miroslav Lachman=0A=
=0A=
=0A=
> ________________________________________=0A=
> From: owner-freebsd-current@freebsd.org  on behalf of David Chisnall =0A=
> Sent: Monday, January 24, 2022 5:16 AM=0A=
> To: freebsd-current@freebsd.org=0A=
> Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14=0A=
>=0A=
> CAUTION: This email originated from outside of the University of Guelph. =
Do not click links or open attachments unless you recognize the sender and =
know the content is safe. If in doubt, forward suspicious emails to IThelp@=
uoguelph.ca=0A=
>=0A=
>=0A=
> On 22/01/2022 23:20, Rick Macklem wrote:=0A=
>> Mark Saad  wrote:=0A=
>> [stuff snipped]=0A=
>>> So I am looking at the Apple and Solaris code, provided by rick. I am n=
ot=0A=
>>> sure if the illumos code provides SMB2 support. They based the solaris=
=0A=
>>> code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure=0A=
>>> predates smb2 .=0A=
>>>=0A=
>>> https://github.com/apple-oss-distributions/smb/tree/smb-217.19=0A=
>>>=0A=
>>> If I am following this correctly we need to look at Apple's smb client=
=0A=
>>> from OSX 10.9  which is where I start to see bits about smb2=0A=
>>>=0A=
>>> https://github.com/apple-oss-distributions/smb/tree/smb-697.95.1/kernel=
/netsmb=0A=
>>>=0A=
>>> This is also where this stuff starts to look less and less like FreeBSD=
 .=0A=
>>> Let me ask some of the illumos people I know to see if there is=0A=
>>> anything they can point to.=0A=
>> Yes. Please do so. I saw the "old" calls fo things like open and the=0A=
>> new ntcreate version, so I assumed that was the newer SMB.=0A=
>> If it is not, there is no reason to port it.=0A=
>>=0A=
>> The new Apple code is a monster. 10x the lines of C and a lot of=0A=
>> weird stuff that looks Apple specific.=0A=
>>=0A=
>> It might actually be easier to write SMBv2 from the spec than port=0A=
>> the Apple stuff.=0A=
>> --> I'll try and look at whatever Microsoft publishes w.r.t. SMBv2/3.=0A=
>>=0A=
>> Thanks for looking at this, rick=0A=
>=0A=
> The docs are public:=0A=
>=0A=
> https://docs.microsoft.com/en-gb/openspecs/windows_protocols/ms-smb2/5606=
ad47-5ee0-437a-817e-70c366052962=0A=
>=0A=
>=0A=
> Note that the spec is 480 pages, it is not a trivial protocol to=0A=
> implement from scratch.=0A=
>=0A=
> David=0A=
>=0A=
>=0A=
=0A=

From nobody Fri Jun 17 15:59:46 2022
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 EA016840687
	for ; Fri, 17 Jun 2022 15:59:55 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LPkJW0Wkvz4RK9
	for ; Fri, 17 Jun 2022 15:59:54 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To:
	From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=lzSUenedx8JhrPEbSwlXvAH6QKR8E4wk/1HuNKstB4s=; b=ECJCoIql2dQCYYNKFZysOd7/oE
	H/BSHa7+ErjJhbgtc9Ws17uHqRdiiXclrKB/cDWDGF3OTwOirpsXaALIbYryTH+FUCHNnTWPX3XPJ
	FHwGsDcziUn0Uc9d1lcmEZQvPLDUxt3ZBM6aenGDgGV+wct1x7F5TKAi6fDfxcMd/CUVnrfiscWbQ
	YUoOgehx3oliRh0EuzhhnUn4f0a/afNDcmUMA0XfFe4rbhjr4UqLCY706S8SjHQ+PrzrNgn3Qc0nS
	Tcg6iTx7Dj4Sgofh9+T2jxK+U0Kfdu8VryiJlN9Uoovk0ajby/8h9CMFvkHXJbG9Qz4UtsfME++U7
	K24gUYVg==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:19235 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o2ENu-000M1j-8c
	for freebsd-current@freebsd.org;
	Fri, 17 Jun 2022 10:59:46 -0500
Received: from 2600:1700:210:b18f:a50f:a95f:95c7:2c5e
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 17 Jun 2022 10:59:46 -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
Date: Fri, 17 Jun 2022 10:59:46 -0500
From: Larry Rosenman 
To: Freebsd current 
Subject: SAS/SATA controllers: 8 port that support 8TB Drives
Message-ID: <96f9a47659ac052b8d806bb9b7ab2b51@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LPkJW0Wkvz4RK9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=ECJCoIql;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I'm looking to upgrade the controllers in my TrueNAS box to something 
that will
support 8TB drives because apparently my LSI 2108 controllers do not 
support 8TB drives.

What's the communities recommendation?
needs to support SFF connectors for a total of 4 SFF connectors, as I 
have 16 slots.


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Fri Jun 17 22:08:30 2022
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 5E74B83D60B
	for ; Fri, 17 Jun 2022 22:08:39 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LPtTy2Xmnz3HrQ
	for ; Fri, 17 Jun 2022 22:08:38 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: by mail-qk1-x735.google.com with SMTP id l192so4088966qke.13
        for ; Fri, 17 Jun 2022 15:08:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:message-id:date:mime-version:user-agent:content-language:to
         :references:from:subject:in-reply-to:content-transfer-encoding;
        bh=WVajnliKdUyaXkoLiIbsEgvhpfpXnsYwzk49XPmr9sA=;
        b=BQ2J2SXu7o33+XyeIUZCIxr0wutjjsMq1tte0ZbofvFqT+SnVzj+n2tuHKZESexzy6
         27twfLZPvdqHbIF9PS319AhXbqjjy3dE9U5Yr3sMr8VUZ/izg9U0IoXf5XZaeXx+nP9T
         ie54E503kS3J9zEf3W6Pmdnl8UQX/RyNJKTD1M814v0hbYLgmWXG8Hnvyjo2+EXuq6Y3
         OBuoqD5zX4roW7xl0+M8KZUTqfyOzGQeZJM+YrZcn9CxOs6sRktuGKdtRR61gsYIftQc
         BSWCbv8iKZ+H4u41PTh9uMnMvJ5pd6s4DvEpiL5tbtJXftUFxb5l8ctT4QehkeVhfu48
         kK5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:message-id:date:mime-version:user-agent
         :content-language:to:references:from:subject:in-reply-to
         :content-transfer-encoding;
        bh=WVajnliKdUyaXkoLiIbsEgvhpfpXnsYwzk49XPmr9sA=;
        b=ApAr1X/be9ttzqBcTeoDHcduqYesjrO94JKhi4wfpum86ssyTPDco3KRbmvsyle9V3
         9aYPX4SP/Ab2Y/MvygRGnNuTALeSyahEMyhy1IJk3dAPId4FuxQI1W1mHFzxqCEEtFdD
         fTKxwgltY8wDw38PFQ9jklj/H/eFbrGJxiaDNFJ8Qw7w1mn9F9kuELuwthudy+ADgiWV
         ey6kWx4y99K7MkrP47uMe5023lD6eEvESIoyX3uVLGS3XX0e2SYbOLmuaPff0IITA7o8
         DH20m9GUBvq3D/8JdlHs43YZqmiGxUGU4RbY98y8DX1KUNKe7jZnmB+juk/wnDEaVoBQ
         N1XQ==
X-Gm-Message-State: AJIora+gNeAz+dHLrkT2XtT8C7SRAi0ekCHfTuAi1IQphlhGsxZvYe87
	9pKdCD60R803DQQlxt247iN5JXjNFNs=
X-Google-Smtp-Source: AGRyM1sUof9xKIGVLrWqXzKYa8zR1VAYIWPI6tLKRNrxBxUmxQaDwAr9A7Oh9P876RMLBfN9KRpUIQ==
X-Received: by 2002:a05:620a:4590:b0:6a7:2543:2938 with SMTP id bp16-20020a05620a459000b006a725432938mr8718669qkb.590.1655503712546;
        Fri, 17 Jun 2022 15:08:32 -0700 (PDT)
Received: from [10.231.1.66] (075-130-069-034.biz.spectrum.com. [75.130.69.34])
        by smtp.gmail.com with ESMTPSA id i3-20020a05620a248300b0069fc13ce23dsm5672847qkn.110.2022.06.17.15.08.31
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 17 Jun 2022 15:08:31 -0700 (PDT)
Message-ID: <1a795a4e-2b1e-2cba-484b-52811546e277@FreeBSD.org>
Date: Fri, 17 Jun 2022 18:08:30 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Content-Language: en-US
To: Larry Rosenman ,
 Freebsd current 
References: <96f9a47659ac052b8d806bb9b7ab2b51@lerctr.org>
From: Alexander Motin 
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
In-Reply-To: <96f9a47659ac052b8d806bb9b7ab2b51@lerctr.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LPtTy2Xmnz3HrQ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=BQ2J2SXu;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::735 as permitted sender) smtp.mailfrom=mavbsd@gmail.com
X-Spamd-Result: default: False [-2.38 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_SHORT(-1.00)[-0.995];
	 FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.18)[-0.184];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[FreeBSD.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::735:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 17.06.2022 11:59, Larry Rosenman wrote:
> I'm looking to upgrade the controllers in my TrueNAS box to something 
> that will
> support 8TB drives because apparently my LSI 2108 controllers do not 
> support 8TB drives.
> 
> What's the communities recommendation?
> needs to support SFF connectors for a total of 4 SFF connectors, as I 
> have 16 slots.

We at iX are still using LSI/Broadcom HBAs, just moved from long 
discontinued mps(4) to newer mpr(4).  And I don't believe the problem is 
directly related to capacity.  According to my observations it may be 
Seagate HDDs of/above certain (8TB) generation.  We do not use Seagate 
HDDs in our products, so about that instability I only heard from forums 
and TrueNAS community user reports.

-- 
Alexander Motin

From nobody Fri Jun 17 22:16:51 2022
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 6C6B683F6AA
	for ; Fri, 17 Jun 2022 22:16:55 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LPtgV3HYGz3KpS;
	Fri, 17 Jun 2022 22:16:53 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=VyaouVOxhp5xckEOZglaD1GBKWFfPjG5pDiRoh+xlyg=; b=wyZHu56R1nISADwF/kmQotVLPu
	WRxIAwTz1jjicMWn2CDqfj5gC5gCNQ/vcbBqbQrU2jcp0hrCfb9MIyKbUiGCyjteFWaoCUUkoAduH
	gXq1957LNnG20Dh0HM7QmtRhcvbxGIp99pgF5XupI51opFXylG4EnVokTlJq+NzDMbQ1xJcPUERie
	Z2gFKC0Wz89FMwyQNvt1jJky/+jVg3KMdcPVvHki/TQGw+Npu58qUG1EGcPQcbfxBwZ+KCTqLzYTx
	DoX3wL1KlTATmklXwnfnmFc4PQeKUW1HRQWtmlAR0UfKNpJyz/g+dAf+UWshXReCy3mSNG4Y0V8db
	qzxcz+hA==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:43304 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o2KGp-0003aO-4v;
	Fri, 17 Jun 2022 17:16:51 -0500
Received: from 2600:1700:210:b18f:a50f:a95f:95c7:2c5e
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 17 Jun 2022 17:16:51 -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
Date: Fri, 17 Jun 2022 17:16:51 -0500
From: Larry Rosenman 
To: Alexander Motin 
Cc: Freebsd current 
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
In-Reply-To: <1a795a4e-2b1e-2cba-484b-52811546e277@FreeBSD.org>
References: <96f9a47659ac052b8d806bb9b7ab2b51@lerctr.org>
 <1a795a4e-2b1e-2cba-484b-52811546e277@FreeBSD.org>
Message-ID: <97624e2a4e0887ede029e71c47bb6060@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LPtgV3HYGz3KpS
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=wyZHu56R;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.99 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-0.99)[-0.995];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 06/17/2022 5:08 pm, Alexander Motin wrote:
> On 17.06.2022 11:59, Larry Rosenman wrote:
>> I'm looking to upgrade the controllers in my TrueNAS box to something 
>> that will
>> support 8TB drives because apparently my LSI 2108 controllers do not 
>> support 8TB drives.
>> 
>> What's the communities recommendation?
>> needs to support SFF connectors for a total of 4 SFF connectors, as I 
>> have 16 slots.
> 
> We at iX are still using LSI/Broadcom HBAs, just moved from long
> discontinued mps(4) to newer mpr(4).  And I don't believe the problem
> is directly related to capacity.  According to my observations it may
> be Seagate HDDs of/above certain (8TB) generation.  We do not use
> Seagate HDDs in our products, so about that instability I only heard
> from forums and TrueNAS community user reports.


This is a mfi(4) set of controllers, and a ST80000Nm0045 8TB (CMR) 
drive.

Is this a bad combo?


mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not supported
(probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
(probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
(probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
(probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
(probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
(probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
(probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
(probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
(probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
(probe0:mfi0:0:0:0): Error 5, Retries exhausted

mfi0 Physical Drives:
  0 (  932G) UNCONFIGURED GOOD  
SATA E1:S3
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106


From nobody Fri Jun 17 22:24:36 2022
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 AE4E1840BDB
	for ; Fri, 17 Jun 2022 22:24:43 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LPtrV3V2Bz3LyR
	for ; Fri, 17 Jun 2022 22:24:42 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: by mail-qv1-xf2b.google.com with SMTP id y14so3072075qvs.10
        for ; Fri, 17 Jun 2022 15:24:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:message-id:date:mime-version:user-agent:content-language:to
         :cc:references:from:subject:in-reply-to:content-transfer-encoding;
        bh=BdoUVIpfKVHUWDY6wftBqSi6NfIDpjNQJAheh23dg9M=;
        b=Z3D0uCwgN9KOKpcgTm1bjp2onlbl/KF5XvygeaKIoWZdgcEfgb7qipTsVC4Qmbv9lc
         d4MG9n84HdP/3jC0E0cOgiLyoVw3HFqOXEWCojGX+MmfprXdRd2a5QTNGHBBnn6jkXYq
         MhHYctWjog1sBQ8A6e2pLaCogkNpwkSBG58SJ7CmeAm47tKAimqfRLTzWBEpmbAMkRkF
         J0udaPA6i2Yh0395GxDDW85tAKdufExFTmdk92DOJ0/7w4aMXFzU5dOAPIOzVieAtR7s
         LYbaatutesAGjkvEEktwC/Ic2iKsKwrVSwoJqYpfDuI64n3JMEIMGsEqHYYq+e87Uu12
         tZRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:message-id:date:mime-version:user-agent
         :content-language:to:cc:references:from:subject:in-reply-to
         :content-transfer-encoding;
        bh=BdoUVIpfKVHUWDY6wftBqSi6NfIDpjNQJAheh23dg9M=;
        b=tmdPufK4Vrac3o2npeHfNGENVVG2vAPbiYdqo71L4eMCuJWLjJ/eH7Y7ufoNQ3CPh1
         PCwN1bIgZAT3PhOtg61aaGTaQC63Eqg0zwEfptuLbKq81kw5E0PYOJAUJ2obi8om2MX9
         onqJv/ULjIbwk1coxKLr6XUuQlNRHncVB0AaGGXjomRyNCBtCSrzTczSknNC+QvqJsNd
         uCSLWHdiOgOM2TKkpKps5osCphLu3lf/pQlBK/cjU8KhcOhw9tYVNOkz3vw4sKWA77Zs
         VKxYJkcccxZV1lVcQdureSCKN0olr9l3+0J/CfayA44+DmiU/hkpU9YGzaqDfDJZxOex
         5YJw==
X-Gm-Message-State: AJIora+je63rqGT7ORZR/UmUpt23Xv1uRoPk5pyk1glbfmBGau1ptNeh
	6RTE5UY/8qMnzR1GH4QgpkU=
X-Google-Smtp-Source: AGRyM1tAEv/V5cYAn12t3kf9Rzgiwx0JQvQiFyMNe3TVbCEGIdutVbYV1ch5oPh1nEyUzU5YkabywQ==
X-Received: by 2002:ac8:7d55:0:b0:305:732:680b with SMTP id h21-20020ac87d55000000b003050732680bmr10619212qtb.391.1655504681931;
        Fri, 17 Jun 2022 15:24:41 -0700 (PDT)
Received: from [10.231.1.66] (075-130-069-034.biz.spectrum.com. [75.130.69.34])
        by smtp.gmail.com with ESMTPSA id w15-20020a05620a424f00b006a76a939dbasm5932366qko.112.2022.06.17.15.24.40
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 17 Jun 2022 15:24:41 -0700 (PDT)
Message-ID: <9ad99f2c-3d63-ccab-f730-e355f0297d72@FreeBSD.org>
Date: Fri, 17 Jun 2022 18:24:36 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Content-Language: en-US
To: Larry Rosenman 
Cc: Freebsd current 
References: <96f9a47659ac052b8d806bb9b7ab2b51@lerctr.org>
 <1a795a4e-2b1e-2cba-484b-52811546e277@FreeBSD.org>
 <97624e2a4e0887ede029e71c47bb6060@lerctr.org>
From: Alexander Motin 
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
In-Reply-To: <97624e2a4e0887ede029e71c47bb6060@lerctr.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LPtrV3V2Bz3LyR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Z3D0uCwg;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::f2b as permitted sender) smtp.mailfrom=mavbsd@gmail.com
X-Spamd-Result: default: False [-3.12 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_SHORT(-1.00)[-0.995];
	 FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.93)[-0.928];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[FreeBSD.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2b:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 17.06.2022 18:16, Larry Rosenman wrote:
> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>> I'm looking to upgrade the controllers in my TrueNAS box to something 
>>> that will
>>> support 8TB drives because apparently my LSI 2108 controllers do not 
>>> support 8TB drives.
>>>
>>> What's the communities recommendation?
>>> needs to support SFF connectors for a total of 4 SFF connectors, as I 
>>> have 16 slots.
>>
>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>> discontinued mps(4) to newer mpr(4).  And I don't believe the problem
>> is directly related to capacity.  According to my observations it may
>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>> Seagate HDDs in our products, so about that instability I only heard
>> from forums and TrueNAS community user reports.
> 
> This is a mfi(4) set of controllers, and a ST80000Nm0045 8TB (CMR) drive.
> 
> Is this a bad combo?
> 
> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not supported
> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
> 
> mfi0 Physical Drives:
>   0 (  932G) UNCONFIGURED GOOD  
> SATA E1:S3

mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS due 
to problems with hot-plug, disk identification, etc. and so have limited 
experience with them.  But I know some of LSI RAIDs can be reflashed 
into equivalent HBAs, so if they share the hardware, I can speculate 
that they may share some issues.

-- 
Alexander Motin

From nobody Fri Jun 17 22:29:32 2022
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 3CA068427C9
	for ; Fri, 17 Jun 2022 22:29:41 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LPtyD1lfYz3NH3
	for ; Fri, 17 Jun 2022 22:29:40 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: by mail-qv1-xf29.google.com with SMTP id t16so3384617qvh.1
        for ; Fri, 17 Jun 2022 15:29:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:message-id:date:mime-version:user-agent:subject
         :content-language:from:to:cc:references:in-reply-to
         :content-transfer-encoding;
        bh=hj5PrRFHEL+z9fbJcec5aPX3QBV1Lorme9MUnI0xGy0=;
        b=SQGS2GK6E2KLQinc6BTUYkofHb4ffWr0brHiIf+ds75nyEQ4R4hy+MPEePXnKeBNcF
         evXgA44AW5ky32ucs6+M8MwMSY+CT0hcGAUBe5MMb6ybM0+v5h6jT2i9VyhQnkNPE+8s
         PFx8fwUGn/G19nhA8juQPmuGm2zWU2v+Y2baCIVDJwU4t1GR00qhtSjvFY3ZRTcwIQA1
         f5Dbt4IEmgelqcH9Ypgq8V+4eoILRlQyhtHSyUwMYQnC5x8vrJug6cq1/kcKYa9NPN7G
         PcNUPzNjfek1MlPJM03nMVrZcKbLHjmEoEiE93lCKPemCE/vYYfy39C1p+YQ8pZNZr4C
         3KiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:message-id:date:mime-version:user-agent
         :subject:content-language:from:to:cc:references:in-reply-to
         :content-transfer-encoding;
        bh=hj5PrRFHEL+z9fbJcec5aPX3QBV1Lorme9MUnI0xGy0=;
        b=V29lsuoHGgxV9fwtHPdyMRrP54ATR4bTycxt8eQukAaHgK7rCLqhDbJwk5Nr28s2NV
         sR5OIBN4EK1vhytY/7sYsJ91uRUZ32IEb6m2+4E0/uOsD7yw8RDd/Tc/bsEdmdF+1FvO
         OzWwlwD3I+xA+y41upqT1w+h+PsHx+5PYFBedWgrfoI05GMi+NrWuFiXyA8RiDFYdViI
         UWBoymuXfsb3hxBhR0XtL8maq9hBTO9xPxzN+m8kYYJMwSbbkdSweGqOEGYxzHC+J2Sw
         wsqpaCnsFRllJazlZVreZ3FswwuhORQLXxewYpZb/ZXY+8kWkQeQVF9HLx1j772sIiQ9
         EN0g==
X-Gm-Message-State: AJIora8tKCuMAf0W5YiNRdBRmUGATaY2V6hYwxv/h0936zcxhgJaGv6U
	zqCeCCu7SNYnfSqLO7B/VpX90ic6O90=
X-Google-Smtp-Source: AGRyM1tT7yeN7GmYMHwIv+1eF2AfCinUzkxZASzD/chH18m9TM8OlPxPFWu2r7RiOetDz8P1e2lN+w==
X-Received: by 2002:a0c:d606:0:b0:46e:7d91:15e2 with SMTP id c6-20020a0cd606000000b0046e7d9115e2mr7406945qvj.45.1655504973979;
        Fri, 17 Jun 2022 15:29:33 -0700 (PDT)
Received: from [10.231.1.66] (075-130-069-034.biz.spectrum.com. [75.130.69.34])
        by smtp.gmail.com with ESMTPSA id cj11-20020a05622a258b00b002f93ece0df3sm5175223qtb.71.2022.06.17.15.29.33
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 17 Jun 2022 15:29:33 -0700 (PDT)
Message-ID: 
Date: Fri, 17 Jun 2022 18:29:32 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
Content-Language: en-US
From: Alexander Motin 
To: Larry Rosenman 
Cc: Freebsd current 
References: <96f9a47659ac052b8d806bb9b7ab2b51@lerctr.org>
 <1a795a4e-2b1e-2cba-484b-52811546e277@FreeBSD.org>
 <97624e2a4e0887ede029e71c47bb6060@lerctr.org>
 <9ad99f2c-3d63-ccab-f730-e355f0297d72@FreeBSD.org>
In-Reply-To: <9ad99f2c-3d63-ccab-f730-e355f0297d72@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LPtyD1lfYz3NH3
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=SQGS2GK6;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::f29 as permitted sender) smtp.mailfrom=mavbsd@gmail.com
X-Spamd-Result: default: False [-2.46 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.26)[-0.265];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[FreeBSD.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f29:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On 17.06.2022 18:24, Alexander Motin wrote:
> On 17.06.2022 18:16, Larry Rosenman wrote:
>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>>> I'm looking to upgrade the controllers in my TrueNAS box to 
>>>> something that will
>>>> support 8TB drives because apparently my LSI 2108 controllers do not 
>>>> support 8TB drives.
>>>>
>>>> What's the communities recommendation?
>>>> needs to support SFF connectors for a total of 4 SFF connectors, as 
>>>> I have 16 slots.
>>>
>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>>> discontinued mps(4) to newer mpr(4).  And I don't believe the problem
>>> is directly related to capacity.  According to my observations it may
>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>>> Seagate HDDs in our products, so about that instability I only heard
>>> from forums and TrueNAS community user reports.
>>
>> This is a mfi(4) set of controllers, and a ST80000Nm0045 8TB (CMR) drive.
>>
>> Is this a bad combo?
>>
>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not supported
>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
>>
>> mfi0 Physical Drives:
>>   0 (  932G) UNCONFIGURED GOOD  
>> SATA E1:S3
> 
> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS due 
> to problems with hot-plug, disk identification, etc. and so have limited 
> experience with them.  But I know some of LSI RAIDs can be reflashed 
> into equivalent HBAs, so if they share the hardware, I can speculate 
> that they may share some issues.

I've just noticed "932G" instead of "8000G".  It is obviously a bigger 
problem than what we heard for HBAs.  It looks like a kind of problems 
that should not happen to HBAs, since they should not care about disk 
capacity.

-- 
Alexander Motin

From nobody Fri Jun 17 22:29:43 2022
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 2496E842647
	for ; Fri, 17 Jun 2022 22:29:45 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LPtyJ39fYz3NC1;
	Fri, 17 Jun 2022 22:29:44 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=pZwQuStsZjn25M4zuizagceVlAAwzjYTA17DTcdsEe8=; b=BwfNdM+fHketRcavcMM2NqYzRQ
	EqyxyhP1AGCDiUEh66TUgSOB+HVoY5W27HdNIfy1BWq7jr+0q4dWkCRalbsocHT74cWuoXS4G5It7
	YZ0PWi9pRhgQovfXzYmJUIDrWEYOPvjp32kqkfBoUX+1SYOaZLNmydoRbKZDDaspNzQYy8SMTed/S
	BN8IiLJaJE9uYgKaA9CV9pLQCUGUEl6UL8YYbdgv4Tsei+Y0f/6JUaNNN5douNCLinsKNDtXFBXVE
	8iYAXY+Fx3j8U6ROpDjmKZUXZzdZ/wWl+T92zCqXD+DIxV38BppM5a7CRyqtftiz4W5vbkiW3TgaR
	W1shusOA==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:13674 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o2KTH-0003kL-V1;
	Fri, 17 Jun 2022 17:29:43 -0500
Received: from 2600:1700:210:b18f:a50f:a95f:95c7:2c5e
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 17 Jun 2022 17:29:43 -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
Date: Fri, 17 Jun 2022 17:29:43 -0500
From: Larry Rosenman 
To: Alexander Motin 
Cc: Freebsd current 
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
In-Reply-To: <9ad99f2c-3d63-ccab-f730-e355f0297d72@FreeBSD.org>
References: <96f9a47659ac052b8d806bb9b7ab2b51@lerctr.org>
 <1a795a4e-2b1e-2cba-484b-52811546e277@FreeBSD.org>
 <97624e2a4e0887ede029e71c47bb6060@lerctr.org>
 <9ad99f2c-3d63-ccab-f730-e355f0297d72@FreeBSD.org>
Message-ID: <5366dceb38e43bc5bd1e84cb90ea31ac@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LPtyJ39fYz3NC1
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=BwfNdM+f;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-1.00)[-0.996];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 06/17/2022 5:24 pm, Alexander Motin wrote:
> On 17.06.2022 18:16, Larry Rosenman wrote:
>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>>> I'm looking to upgrade the controllers in my TrueNAS box to 
>>>> something that will
>>>> support 8TB drives because apparently my LSI 2108 controllers do not 
>>>> support 8TB drives.
>>>> 
>>>> What's the communities recommendation?
>>>> needs to support SFF connectors for a total of 4 SFF connectors, as 
>>>> I have 16 slots.
>>> 
>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>>> discontinued mps(4) to newer mpr(4).  And I don't believe the problem
>>> is directly related to capacity.  According to my observations it may
>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>>> Seagate HDDs in our products, so about that instability I only heard
>>> from forums and TrueNAS community user reports.
>> 
>> This is a mfi(4) set of controllers, and a ST80000Nm0045 8TB (CMR) 
>> drive.
>> 
>> Is this a bad combo?
>> 
>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not supported
>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
>> 
>> mfi0 Physical Drives:
>>   0 (  932G) UNCONFIGURED GOOD  
>> SATA E1:S3
> 
> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS
> due to problems with hot-plug, disk identification, etc. and so have
> limited experience with them.  But I know some of LSI RAIDs can be
> reflashed into equivalent HBAs, so if they share the hardware, I can
> speculate that they may share some issues.
I bought 2 of these:
https://www.ebay.com/itm/194910024856
to replace the 2 mfi(4)'s

Hopefully I can just move the controllers and TrueNAS 13.0-RELEASE will 
just notice them.
and pick up the new 8T disks.

let me know if I'm setting myself up for failure.

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Fri Jun 17 22:39:56 2022
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 72756845530
	for ; Fri, 17 Jun 2022 22:40:05 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LPvBD2NGHz3R3T
	for ; Fri, 17 Jun 2022 22:40:04 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: by mail-qk1-x736.google.com with SMTP id n197so4155186qke.1
        for ; Fri, 17 Jun 2022 15:40:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:message-id:date:mime-version:user-agent:content-language:to
         :cc:references:from:subject:in-reply-to:content-transfer-encoding;
        bh=Nj99oeDfRVqDnxgXS3ZQEUPwmwWFYRbnphX9Hh0utqg=;
        b=Qe4GDIH2WmA92IUBMuAg3B7HOOgbLd8r0Gkh+opiNuWbMJsRccGeCeskqRlHe/x++n
         SoRXYNiH3/DiYl54PjOkRlufEWSpB/dysM29JrERe+6IN2x8LDGwEwunrmGSLmnzgxUs
         NEfAlrXP+AEoXBdhoIMslkSuMm4NW5f0oyd8GZ0NOp2Q1LkoE7wCUiay2Ey6RwH54DYB
         YYCKnYDcdVb7OF8yX5eq0gDUkHE0z006B7C7T5nYG/D/t7S8n0DM1dMxVa8GwF5W7gtn
         xlp4Eti3dP1Qg/e//ejfOY+ICMt6Mx2BIAqLMOpsNhSI5Pwb8gE0Zc8OM0NnQl/nSKyv
         OFug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:message-id:date:mime-version:user-agent
         :content-language:to:cc:references:from:subject:in-reply-to
         :content-transfer-encoding;
        bh=Nj99oeDfRVqDnxgXS3ZQEUPwmwWFYRbnphX9Hh0utqg=;
        b=uzn8a8jlzgXilPp3+hFq8pUcssylEvqiY+NVJmVcRNZXTRiGYNHtJYx3WHrFEbLQ0+
         StXpi6/ClTpP8KU/FZGt5Lx/mglCSbKICBmT6T+sCWTpHB6aJcdIsdNQ/eLzrbLZuwK9
         czvpodM53ViHkmoBY2XNcIFjYVQeciiw4EF7B8PYDGt3d01EfaqR8GdLMOIP9QPH/Lm3
         FavsBO5oUc6nEU473gdGwS3yAtcVwwk2+DfA6e/9L8XjbUFo/0KD1fmxzxC1D0pKen0y
         QY16izoCmuqG7mz9o264smBbObuZ2l7/ck/9i0ePSLmeBIQZLRYg+F9t7EPSiTnvb7s8
         CxcA==
X-Gm-Message-State: AJIora+v0BwoziKJj3dMdDbLHtDbEu0+BviwCc0Bo8jbDG7f0myKDY/5
	8b5oOAmKuqKwrrbgEFMePPA=
X-Google-Smtp-Source: AGRyM1sjhGQhdLTxT4ES++RStTEOoattpB4s2TOl7chas0nX8AcBrzVrBfZ6XmXp6lCVQW0OP6Hf/w==
X-Received: by 2002:a37:b82:0:b0:6a6:cef8:85de with SMTP id 124-20020a370b82000000b006a6cef885demr8817067qkl.651.1655505597663;
        Fri, 17 Jun 2022 15:39:57 -0700 (PDT)
Received: from [10.231.1.66] (075-130-069-034.biz.spectrum.com. [75.130.69.34])
        by smtp.gmail.com with ESMTPSA id g1-20020ac87f41000000b002f9399ccefasm5722730qtk.34.2022.06.17.15.39.56
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 17 Jun 2022 15:39:57 -0700 (PDT)
Message-ID: <2bc77869-244e-e3bd-709d-f24bf96782bc@FreeBSD.org>
Date: Fri, 17 Jun 2022 18:39:56 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Content-Language: en-US
To: Larry Rosenman 
Cc: Freebsd current 
References: <96f9a47659ac052b8d806bb9b7ab2b51@lerctr.org>
 <1a795a4e-2b1e-2cba-484b-52811546e277@FreeBSD.org>
 <97624e2a4e0887ede029e71c47bb6060@lerctr.org>
 <9ad99f2c-3d63-ccab-f730-e355f0297d72@FreeBSD.org>
 <5366dceb38e43bc5bd1e84cb90ea31ac@lerctr.org>
From: Alexander Motin 
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
In-Reply-To: <5366dceb38e43bc5bd1e84cb90ea31ac@lerctr.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LPvBD2NGHz3R3T
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Qe4GDIH2;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::736 as permitted sender) smtp.mailfrom=mavbsd@gmail.com
X-Spamd-Result: default: False [-1.38 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_SHORT(-0.99)[-0.989];
	 FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[FreeBSD.org];
	 NEURAL_SPAM_MEDIUM(0.81)[0.807];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 17.06.2022 18:29, Larry Rosenman wrote:
> On 06/17/2022 5:24 pm, Alexander Motin wrote:
>> On 17.06.2022 18:16, Larry Rosenman wrote:
>>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>>>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>>>> I'm looking to upgrade the controllers in my TrueNAS box to 
>>>>> something that will
>>>>> support 8TB drives because apparently my LSI 2108 controllers do 
>>>>> not support 8TB drives.
>>>>>
>>>>> What's the communities recommendation?
>>>>> needs to support SFF connectors for a total of 4 SFF connectors, as 
>>>>> I have 16 slots.
>>>>
>>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>>>> discontinued mps(4) to newer mpr(4).  And I don't believe the problem
>>>> is directly related to capacity.  According to my observations it may
>>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>>>> Seagate HDDs in our products, so about that instability I only heard
>>>> from forums and TrueNAS community user reports.
>>>
>>> This is a mfi(4) set of controllers, and a ST80000Nm0045 8TB (CMR) 
>>> drive.
>>>
>>> Is this a bad combo?
>>>
>>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not supported
>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
>>>
>>> mfi0 Physical Drives:
>>>   0 (  932G) UNCONFIGURED GOOD >> serial=ZA1AC912> SATA E1:S3
>>
>> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS
>> due to problems with hot-plug, disk identification, etc. and so have
>> limited experience with them.  But I know some of LSI RAIDs can be
>> reflashed into equivalent HBAs, so if they share the hardware, I can
>> speculate that they may share some issues.
> I bought 2 of these:
> https://www.ebay.com/itm/194910024856
> to replace the 2 mfi(4)'s
> 
> Hopefully I can just move the controllers and TrueNAS 13.0-RELEASE will 
> just notice them.
> and pick up the new 8T disks.
> 
> let me know if I'm setting myself up for failure.

Not so obvious.  They should work at least on a short run.  But as I 
have told, I've heard number of rumors about mps(4) and 8TB Seagates. 
Though nothing confirmed, only some instability, that nobody is really 
motivated to debug now.  Next 93xx line of mpr(4) HBAs still seems cost 
few times more on EBay thogh, so there is a choice.

-- 
Alexander Motin

From nobody Fri Jun 17 22:55:50 2022
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 B92CB850070
	for ; Fri, 17 Jun 2022 22:55:51 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LPvXR1Gm8z3k4t;
	Fri, 17 Jun 2022 22:55:51 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=nvr5lt9k32EqqrBsWnUmayCwz3yadV7Ttv8lbEIuw/U=; b=fBp/ZbkfMgwtHo6d9mwkcQzxNU
	Ea7/ogymEz3cUtKIdkxN9kCaXcVzCDTqxgNjPyYFT98H22iNRVugOIN/ZsZtdaBLuWQOAdErFMOY6
	2rxZmOdGLBd8vWhiX9Ok6TP/h3f6tM4OCRLaXmis+47QOg9kv3Hp4sfBpJ/iPdD6/LDwXOdjXkzYI
	Ex0vRAqNqXRoP/LgNVLt+G/2jhZp1YSBU8PJylzRHaDbitdVwDA3jJv4/fYQ9sR3d2G5sDXnScHLt
	6L2NpSFdc4N01G7Ycbn1WRzzJKjGE7EbZKI4uYYsPMBDvHW8wkCAXUEPxAGpBXIxwPpd44rp23IqV
	ySOiW0yw==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:13437 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o2KsY-0004Fj-NX;
	Fri, 17 Jun 2022 17:55:50 -0500
Received: from 2600:1700:210:b18f:a50f:a95f:95c7:2c5e
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 17 Jun 2022 17:55:50 -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
Date: Fri, 17 Jun 2022 17:55:50 -0500
From: Larry Rosenman 
To: Michael Gmelin 
Cc: Alexander Motin , Freebsd current
 
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
In-Reply-To: <32B35839-84F9-4BDC-B8B5-AF576E21041C@freebsd.org>
References: 
 <32B35839-84F9-4BDC-B8B5-AF576E21041C@freebsd.org>
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LPvXR1Gm8z3k4t
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b="fBp/Zbkf";
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-2.63 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+mx:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_SPAM_SHORT(0.37)[0.367];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 06/17/2022 5:48 pm, Michael Gmelin wrote:
>> On 18. Jun 2022, at 00:31, Alexander Motin  wrote:
>> 
>> 
>> 
>>> On 17.06.2022 18:24, Alexander Motin wrote:
>>>> On 17.06.2022 18:16, Larry Rosenman wrote:
>>>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>>>>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>>>>> I'm looking to upgrade the controllers in my TrueNAS box to 
>>>>>> something that will
>>>>>> support 8TB drives because apparently my LSI 2108 controllers do 
>>>>>> not support 8TB drives.
>>>>>> 
>>>>>> What's the communities recommendation?
>>>>>> needs to support SFF connectors for a total of 4 SFF connectors, 
>>>>>> as I have 16 slots.
>>>>> 
>>>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>>>>> discontinued mps(4) to newer mpr(4).  And I don't believe the 
>>>>> problem
>>>>> is directly related to capacity.  According to my observations it 
>>>>> may
>>>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>>>>> Seagate HDDs in our products, so about that instability I only 
>>>>> heard
>>>>> from forums and TrueNAS community user reports.
>>>> 
>>>> This is a mfi(4) set of controllers, and a ST80000Nm0045 8TB (CMR) 
>>>> drive.
>>>> 
>>>> Is this a bad combo?
>>>> 
>>>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not 
>>>> supported
>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
>>>> 
>>>> mfi0 Physical Drives:
>>>>   0 (  932G) UNCONFIGURED GOOD >>> serial=ZA1AC912> SATA E1:S3
>>> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS 
>>> due to problems with hot-plug, disk identification, etc. and so have 
>>> limited experience with them.  But I know some of LSI RAIDs can be 
>>> reflashed into equivalent HBAs, so if they share the hardware, I can 
>>> speculate that they may share some issues.
>> 
>> I've just noticed "932G" instead of "8000G".  It is obviously a bigger 
>> problem than what we heard for HBAs.  It looks like a kind of problems 
>> that should not happen to HBAs, since they should not care about disk 
>> capacity.
>> 
> 
> What does `smartctl -a ` report (especially sector sizes)?
> 
> -m
> 
> 
>> --
>> Alexander Motin
>> 
It's not even making a mfid* node (it is a 4Kn disk)
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Fri Jun 17 23:20:09 2022
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 5F06F854EC8
	for ; Fri, 17 Jun 2022 23:20:13 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LPw4X3Tspz3nRM;
	Fri, 17 Jun 2022 23:20:12 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id 2db81cab;
	Fri, 17 Jun 2022 23:20:10 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 0ca30134 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Fri, 17 Jun 2022 23:20:10 +0000 (UTC)
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 (1.0)
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
From: Michael Gmelin 
In-Reply-To: 
Cc: Alexander Motin ,
 Freebsd current 
Date: Sat, 18 Jun 2022 01:20:09 +0200
Message-Id: <736314DA-354C-465C-8D8C-AF67AAD68F5D@freebsd.org>
References: 
To: Larry Rosenman 
X-Mailer: iPhone Mail (19E258)
X-Rspamd-Queue-Id: 4LPw4X3Tspz3nRM
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [1.88 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[grembo];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 R_SPF_SOFTFAIL(0.00)[~all];
	 NEURAL_SPAM_MEDIUM(1.00)[1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-0.51)[-0.514];
	 NEURAL_SPAM_LONG(0.99)[0.990];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 18. Jun 2022, at 00:57, Larry Rosenman  wrote:
> =EF=BB=BFOn 06/17/2022 5:48 pm, Michael Gmelin wrote:
>>> On 18. Jun 2022, at 00:31, Alexander Motin  wrote:
>>> =EF=BB=BF
>>>> On 17.06.2022 18:24, Alexander Motin wrote:
>>>>> On 17.06.2022 18:16, Larry Rosenman wrote:
>>>>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>>>>>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>>>>>> I'm looking to upgrade the controllers in my TrueNAS box to somethin=
g that will
>>>>>>> support 8TB drives because apparently my LSI 2108 controllers do not=
 support 8TB drives.
>>>>>>> What's the communities recommendation?
>>>>>>> needs to support SFF connectors for a total of 4 SFF connectors, as I=
 have 16 slots.
>>>>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>>>>>> discontinued mps(4) to newer mpr(4).  And I don't believe the problem=

>>>>>> is directly related to capacity.  According to my observations it may=

>>>>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>>>>>> Seagate HDDs in our products, so about that instability I only heard
>>>>>> from forums and TrueNAS community user reports.
>>>>> This is a mfi(4) set of controllers, and a ST80000Nm0045 8TB (CMR) dri=
ve.
>>>>> Is this a bad combo?
>>>>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not supported=

>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
>>>>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
>>>>> mfi0 Physical Drives:
>>>>>  0 (  932G) UNCONFIGURED GOOD  SATA E1:S3
>>>> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS due=
 to problems with hot-plug, disk identification, etc. and so have limited ex=
perience with them.  But I know some of LSI RAIDs can be reflashed into equi=
valent HBAs, so if they share the hardware, I can speculate that they may sh=
are some issues.
>>> I've just noticed "932G" instead of "8000G".  It is obviously a bigger p=
roblem than what we heard for HBAs.  It looks like a kind of problems that s=
hould not happen to HBAs, since they should not care about disk capacity.
>> What does `smartctl -a ` report (especially sector sizes)?
>> -m
>>> --
>>> Alexander Motin
> It's not even making a mfid* node (it is a 4Kn disk)

Ok, that=E2=80=99s sad (and explains the wrong size calculation as 4096/512=3D=
8).

Is this in HBA mode? (Like Alexander suggested, re-/crossflashing using an I=
T firmware might be an option). What controller / firmware image version is i=
t?

-m


> --=20
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106


From nobody Fri Jun 17 23:30:07 2022
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 98BFE856ECD
	for ; Fri, 17 Jun 2022 23:30:11 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LPwJ269HFz3pqw;
	Fri, 17 Jun 2022 23:30:10 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=aIXXUiwYKu8QvYNWUwbo/LOHytlVLYvi06JuRaPQVZU=; b=KNheknAKGe5Ppi9i/kKxg6lliC
	Wfr8yk3oKpsX5G+1aawuG3Jd60OKFoyDJkLWaQmYuw9oDB1lzJV3Pl/UoKfs+7j8IE8ff/7u7rUb6
	rqTsTWn48gZJqYDlsdBAEHIpWgW9dlNU+pnhreyJEzDFIGl31O2hWOLU9VFqGG2bBD4G3hgmn1ErJ
	ttYsg5vBBnrYEAxofgQraIWOqGgRB33CKjCmBX5lgtUeJsNz5XtRJxNMBWdLYyKNM0ouvG+cINbTG
	SDfAYeSjW0UoqxFPkEkvkDgj6aSoKmVZBL7RkkmcNOtHD39WH1o3ABhlRiZs5pgu4Dw6ATBW7Kytw
	4hbzMS7g==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:16591 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o2LPj-0004kF-Qh;
	Fri, 17 Jun 2022 18:30:07 -0500
Received: from 2600:1700:210:b18f:a50f:a95f:95c7:2c5e
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 17 Jun 2022 18:30:07 -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
Date: Fri, 17 Jun 2022 18:30:07 -0500
From: Larry Rosenman 
To: Michael Gmelin 
Cc: Alexander Motin , Freebsd current
 
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
In-Reply-To: <736314DA-354C-465C-8D8C-AF67AAD68F5D@freebsd.org>
References: 
 <736314DA-354C-465C-8D8C-AF67AAD68F5D@freebsd.org>
Message-ID: <5936c6368df3c7d762d4710d23e7c57c@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LPwJ269HFz3pqw
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=KNheknAK;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.99 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-0.99)[-0.990];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 06/17/2022 6:20 pm, Michael Gmelin wrote:
>> On 18. Jun 2022, at 00:57, Larry Rosenman  wrote:
>> On 06/17/2022 5:48 pm, Michael Gmelin wrote:
>>>> On 18. Jun 2022, at 00:31, Alexander Motin  wrote:
>>>> 
>>>>> On 17.06.2022 18:24, Alexander Motin wrote:
>>>>>> On 17.06.2022 18:16, Larry Rosenman wrote:
>>>>>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>>>>>>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>>>>>>> I'm looking to upgrade the controllers in my TrueNAS box to 
>>>>>>>> something that will
>>>>>>>> support 8TB drives because apparently my LSI 2108 controllers do 
>>>>>>>> not support 8TB drives.
>>>>>>>> What's the communities recommendation?
>>>>>>>> needs to support SFF connectors for a total of 4 SFF connectors, 
>>>>>>>> as I have 16 slots.
>>>>>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>>>>>>> discontinued mps(4) to newer mpr(4).  And I don't believe the 
>>>>>>> problem
>>>>>>> is directly related to capacity.  According to my observations it 
>>>>>>> may
>>>>>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>>>>>>> Seagate HDDs in our products, so about that instability I only 
>>>>>>> heard
>>>>>>> from forums and TrueNAS community user reports.
>>>>>> This is a mfi(4) set of controllers, and a ST80000Nm0045 8TB (CMR) 
>>>>>> drive.
>>>>>> Is this a bad combo?
>>>>>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not 
>>>>>> supported
>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an 
>>>>>> error
>>>>>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an 
>>>>>> error
>>>>>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an 
>>>>>> error
>>>>>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an 
>>>>>> error
>>>>>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an 
>>>>>> error
>>>>>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
>>>>>> mfi0 Physical Drives:
>>>>>>  0 (  932G) UNCONFIGURED GOOD >>>>> serial=ZA1AC912> SATA E1:S3
>>>>> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS 
>>>>> due to problems with hot-plug, disk identification, etc. and so 
>>>>> have limited experience with them.  But I know some of LSI RAIDs 
>>>>> can be reflashed into equivalent HBAs, so if they share the 
>>>>> hardware, I can speculate that they may share some issues.
>>>> I've just noticed "932G" instead of "8000G".  It is obviously a 
>>>> bigger problem than what we heard for HBAs.  It looks like a kind of 
>>>> problems that should not happen to HBAs, since they should not care 
>>>> about disk capacity.
>>> What does `smartctl -a ` report (especially sector sizes)?
>>> -m
>>>> --
>>>> Alexander Motin
>> It's not even making a mfid* node (it is a 4Kn disk)
> 
> Ok, that’s sad (and explains the wrong size calculation as 4096/512=8).
> 
> Is this in HBA mode? (Like Alexander suggested, re-/crossflashing
> using an IT firmware might be an option). What controller / firmware
> image version is it?
> 
> -m
> 
> 
>> --
>> Larry Rosenman                     http://www.lerctr.org/~ler
>> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
>> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106


mfi0@pci0:8:0:0:	class=0x010400 rev=0x05 hdr=0x00 vendor=0x1000 
device=0x0079 subvendor=0x1734 subdevice=0x1176
     vendor     = 'Broadcom / LSI'
     device     = 'MegaRAID SAS 2108 [Liberator]'
     class      = mass storage
     subclass   = RAID

mfi1@pci0:3:0:0:	class=0x010400 rev=0x05 hdr=0x00 vendor=0x1000 
device=0x0079 subvendor=0x1734 subdevice=0x1176
     vendor     = 'Broadcom / LSI'
     device     = 'MegaRAID SAS 2108 [Liberator]'
     class      = mass storage
     subclass   = RAID

mfi0:  port 0xd000-0xd0ff mem 
0xfbc9c000-0xfbc9ffff,0xfbcc0000
-0xfbcfffff irq 26 at device 0.0 on pci3
mfi0: Using MSI
mfi0: Megaraid SAS driver Ver 4.23
mfi0: FW MaxCmds = 1008, limiting to 128
mfip0:  on mfi0
mfi0: 10014 (708822708s/0x0020/info) - Shutdown command received from 
host
mfi0: 10015 (boot + 3s/0x0020/info) - Firmware initialization started 
(PCI ID 00
79/1000/1176/1734)
mfi0: 10016 (boot + 3s/0x0020/info) - Firmware version 2.130.353-2727
mfi0: 10017 (boot + 6s/0x0020/info) - Package version 12.12.0-0174
mfi0: 10018 (boot + 6s/0x0020/info) - Board Revision

mfi1:  port 0xc000-0xc0ff mem 
0xfba9c000-0xfba9ffff,0xfbac0000
-0xfbafffff irq 16 at device 0.0 on pci8
mfi1: Using MSI
mfi1: Megaraid SAS driver Ver 4.23
mfi1: FW MaxCmds = 1008, limiting to 128


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Sat Jun 18 08:54:12 2022
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 1026E85B199
	for ; Sat, 18 Jun 2022 08:54:18 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LQ8pw55T3z4XWS;
	Sat, 18 Jun 2022 08:54:16 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id c45b933d;
	Sat, 18 Jun 2022 08:54:14 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id ae051716 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Sat, 18 Jun 2022 08:54:14 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-A1E7CE4B-3070-4935-B3D7-D687F871FECC
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 (1.0)
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
From: Michael Gmelin 
In-Reply-To: <5936c6368df3c7d762d4710d23e7c57c@lerctr.org>
Cc: Alexander Motin ,
 Freebsd current 
Date: Sat, 18 Jun 2022 10:54:12 +0200
Message-Id: 
References: <5936c6368df3c7d762d4710d23e7c57c@lerctr.org>
To: Larry Rosenman 
X-Mailer: iPhone Mail (19E258)
X-Rspamd-Queue-Id: 4LQ8pw55T3z4XWS
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-0.04 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FREEFALL_USER(0.00)[grembo];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 NEURAL_HAM_LONG(-0.36)[-0.359];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 R_SPF_SOFTFAIL(0.00)[~all:c];
	 NEURAL_SPAM_MEDIUM(0.92)[0.916];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail-A1E7CE4B-3070-4935-B3D7-D687F871FECC
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On 18. Jun 2022, at 01:31, Larry Rosenman  wrote:
> =EF=BB=BFOn 06/17/2022 6:20 pm, Michael Gmelin wrote:
>>>> On 18. Jun 2022, at 00:57, Larry Rosenman  wrote:
>>> =EF=BB=BFOn 06/17/2022 5:48 pm, Michael Gmelin wrote:
>>>>> On 18. Jun 2022, at 00:31, Alexander Motin  wrote:
>>>>> =EF=BB=BF
>>>>>> On 17.06.2022 18:24, Alexander Motin wrote:
>>>>>>> On 17.06.2022 18:16, Larry Rosenman wrote:
>>>>>>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
>>>>>>>> On 17.06.2022 11:59, Larry Rosenman wrote:
>>>>>>>>> I'm looking to upgrade the controllers in my TrueNAS box to someth=
ing that will
>>>>>>>>> support 8TB drives because apparently my LSI 2108 controllers do n=
ot support 8TB drives.
>>>>>>>>> What's the communities recommendation?
>>>>>>>>> needs to support SFF connectors for a total of 4 SFF connectors, a=
s I have 16 slots.
>>>>>>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
>>>>>>>> discontinued mps(4) to newer mpr(4).  And I don't believe the probl=
em
>>>>>>>> is directly related to capacity.  According to my observations it m=
ay
>>>>>>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
>>>>>>>> Seagate HDDs in our products, so about that instability I only hear=
d
>>>>>>>> from forums and TrueNAS community user reports.
>>>>>>> This is a mfi(4) set of controllers, and a ST80000Nm0045 8TB (CMR) d=
rive.
>>>>>>> Is this a bad combo?
>>>>>>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not support=
ed
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error=

>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error=

>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error=

>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error=

>>>>>>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
>>>>>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
>>>>>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error=

>>>>>>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
>>>>>>> mfi0 Physical Drives:
>>>>>>> 0 (  932G) UNCONFIGURED GOOD  SATA E1:S3
>>>>>> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS d=
ue to problems with hot-plug, disk identification, etc. and so have limited e=
xperience with them.  But I know some of LSI RAIDs can be reflashed into equ=
ivalent HBAs, so if they share the hardware, I can speculate that they may s=
hare some issues.
>>>>> I've just noticed "932G" instead of "8000G".  It is obviously a bigger=
 problem than what we heard for HBAs.  It looks like a kind of problems that=
 should not happen to HBAs, since they should not care about disk capacity.
>>>> What does `smartctl -a ` report (especially sector sizes)?
>>>> -m
>>>>> --
>>>>> Alexander Motin
>>> It's not even making a mfid* node (it is a 4Kn disk)
>> Ok, that=E2=80=99s sad (and explains the wrong size calculation as 4096/5=
12=3D8).
>> Is this in HBA mode? (Like Alexander suggested, re-/crossflashing
>> using an IT firmware might be an option). What controller / firmware
>> image version is it?
>> -m
>>> --
>>> Larry Rosenman                     http://www.lerctr.org/~ler
>>> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
>>> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>=20
>=20
> mfi0@pci0:8:0:0:    class=3D0x010400 rev=3D0x05 hdr=3D0x00 vendor=3D0x1000=
 device=3D0x0079 subvendor=3D0x1734 subdevice=3D0x1176
>    vendor     =3D 'Broadcom / LSI'
>    device     =3D 'MegaRAID SAS 2108 [Liberator]'
>    class      =3D mass storage
>    subclass   =3D RAID
>=20
> mfi1@pci0:3:0:0:    class=3D0x010400 rev=3D0x05 hdr=3D0x00 vendor=3D0x1000=
 device=3D0x0079 subvendor=3D0x1734 subdevice=3D0x1176
>    vendor     =3D 'Broadcom / LSI'
>    device     =3D 'MegaRAID SAS 2108 [Liberator]'
>    class      =3D mass storage
>    subclass   =3D RAID
>=20
> mfi0:  port 0xd000-0xd0ff mem 0xfbc9c000-0xfbc9ffff,0xfb=
cc0000
> -0xfbcfffff irq 26 at device 0.0 on pci3
> mfi0: Using MSI
> mfi0: Megaraid SAS driver Ver 4.23
> mfi0: FW MaxCmds =3D 1008, limiting to 128
> mfip0:  on mfi0
> mfi0: 10014 (708822708s/0x0020/info) - Shutdown command received from host=

> mfi0: 10015 (boot + 3s/0x0020/info) - Firmware initialization started (PCI=
 ID 00
> 79/1000/1176/1734)
> mfi0: 10016 (boot + 3s/0x0020/info) - Firmware version 2.130.353-2727
> mfi0: 10017 (boot + 6s/0x0020/info) - Package version 12.12.0-0174
> mfi0: 10018 (boot + 6s/0x0020/info) - Board Revision
>=20
> mfi1:  port 0xc000-0xc0ff mem 0xfba9c000-0xfba9ffff,0xfb=
ac0000
> -0xfbafffff irq 16 at device 0.0 on pci8
> mfi1: Using MSI
> mfi1: Megaraid SAS driver Ver 4.23
> mfi1: FW MaxCmds =3D 1008, limiting to 128
>=20

Subvendor is Fujitsu Siemens - so I guess this is integrated into a system b=
y them.

Seems like flashing the 2108 to an IT firmware isn=E2=80=99t an option (base=
d on what I found online). You could check if there are firmware updates ava=
ilable though. How did you configure the drives in the megaraid utility (ctr=
l-h after boot)? Did you create a RAID-0 for each disk? And what capacity is=
 shown in there?

Based on [0], 2108 based controllers don=E2=80=99t support 4kn. IT mode woul=
d help (true passthrough), but as written above, I don=E2=80=99t think it=E2=
=80=99s an option for this model.

-m

[0] https://bitdeals.tech/blogs/news/4kn-lsi-compatibility-list

>=20
> --=20
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

--Apple-Mail-A1E7CE4B-3070-4935-B3D7-D687F871FECC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 18. Jun 2022, at 01:31, Larry Rosenman <ler=
@lerctr.org> wrote:

<=
div dir=3D"ltr">=EF=BB=BFOn 06/17/2022 6:20 pm, Michael Gmelin wrote:<=
/span>
On 18. J=
un 2022, at 00:57, Larry Rosenman <ler@lerctr.org> wrote:
=
=EF=BB=BFOn 06/17/2022 5:48 pm, Michael Gmelin wrote:
On 18. Jun 2022, at 00=
:31, Alexander Motin <mav@freebsd.org> wrote:
<=
/blockquote>
=EF=BB=
=BF
On 17.06.2022 18:24, Alexa=
nder Motin wrote:
On 17.06.2022 18:16, Larry Rosenman wrote:=

On 06/17/2022 5:08 pm, Alexander Motin wrote:
<=
blockquote type=3D"cite">On 17.06.2022 11:59, Larry Rosenman wrote:
<=
blockquote type=3D"cite">
I'm looking to upgrade the controllers in my TrueNAS box to somethi=
ng that will
<=
/blockquote>
support 8TB drives because apparently m=
y LSI 2108 controllers do not support 8TB drives.
<=
/blockquote>
Wha=
t's the communities recommendation?
=

needs to support=
 SFF connectors for a total of 4 SFF connectors, as I have 16 slots.<=
br>
We at iX ar=
e still using LSI/Broadcom HBAs, just moved from long
discontinued mps(4) to newer mpr(4). &=
nbsp;And I don't believe the problem
is directly related to capacity.  According to my o=
bservations it may
be Seagate HDDs of/above certain (8TB) generation.  We do not use
=

Seagate HDDs in o=
ur products, so about that instability I only heard
<=
/blockquote>
from forums and TrueNAS community user r=
eports.
This is a mfi(4) set of controllers, a=
nd a ST80000Nm0045 8TB (CMR) drive.
=

Is this a bad comb=
o?
mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s=
3) is not supported
(probe0:mfi0:0:0:0): INQUIRY. CDB: 12=
 00 00 00 24 00
(probe0:mfi0:0:0:0): CAM status: CCB r=
equest completed with an error
(probe0:mfi0:0:0:0): Re=
trying command, 3 more tries remain
=

(probe0:mfi0:0:0:0=
): INQUIRY. CDB: 12 00 00 00 24 00
<=
blockquote type=3D"cite">
(probe0:mfi0:0:0:0)=
: CAM status: CCB request completed with an error
(prob=
e0:mfi0:0:0:0): Retrying command, 2 more tries remain
=
(probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
=

(=
probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
(probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
(probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:mfi0:0:0:0): CAM status: CCB request completed with an e=
rror
(probe0:mfi0:0:0:0): Retrying command, 0 more tri=
es remain
=

(probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 0=
0 24 00
(probe0:mfi0:0:0:0): CAM status: CCB request c=
ompleted with an error
(probe0:mfi0:0:0:0): Error 5, R=
etries exhausted
mfi0 Physical Drives:
<=
blockquote type=3D"cite">
 0 (  932G) UNCONFIGURED GOOD <ST8000NM0045-1RL UG07 serial=3D=
ZA1AC912> SATA E1:S3
mfi(4) are RAIDs, not HBAs.  We do not recommend RAI=
Ds with TrueNAS due to problems with hot-plug, disk identification, etc. and=
 so have limited experience with them.  But I know some of LSI RAIDs ca=
n be reflashed into equivalent HBAs, so if they share the hardware, I can sp=
eculate that they may share some issues.
I'=
ve just noticed "932G" instead of "8000G".  It is obviously a bigger pr=
oblem than what we heard for HBAs.  It looks like a kind of problems th=
at should not happen to HBAs, since they should not care about disk capacity=
.
What d=
oes `smartctl -a <device>` report (especially sector sizes)?
-m
=

--
<=
span>Alexander Motin
It's not ev=
en making a mfid* node (it is a 4Kn disk)
Ok, that=E2=80=99s sad (and explains the w=
rong size calculation as 4096/512=3D8).
Is this in HBA mode? (Like Alexander suggested, re-/cross=
flashing
using an IT f=
irmware might be an option). What controller / firmware
image version is it?
-m
--
Larry Rosenm=
an             &=
nbsp;       http://www.lerctr.org/~ler
Phone: +1 214-642-9640       &=
nbsp;         E-Mail: ler@lerct=
r.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106


m=
fi0@pci0:8:0:0:    class=3D0x010400 rev=3D0x05 hdr=3D0x00 vendor=3D=
0x1000 device=3D0x0079 subvendor=3D0x1734 subdevice=3D0x1176
    vendor     =3D 'Broadcom / LSI'
    device     =3D 'MegaRAID S=
AS 2108 [Liberator]'
    class   &n=
bsp;  =3D mass storage
    subclass=
   =3D RAID

mfi1@pci0:3:0:0: &nbs=
p;  class=3D0x010400 rev=3D0x05 hdr=3D0x00 vendor=3D0x1000 device=3D0x0=
079 subvendor=3D0x1734 subdevice=3D0x1176
    =
;vendor     =3D 'Broadcom / LSI'
  =
  device     =3D 'MegaRAID SAS 2108 [Liberator=
]'
    class      =3D=
 mass storage
    subclass   =3D RA=
ID

mfi0: <LSI MegaSAS Gen2> port 0xd0=
00-0xd0ff mem 0xfbc9c000-0xfbc9ffff,0xfbcc0000
-0xfbcfffff i=
rq 26 at device 0.0 on pci3
mfi0: Using MSI
=
mfi0: Megaraid SAS driver Ver 4.23
mfi0: FW MaxCmds =3D 1008=
, limiting to 128
mfip0: <SCSI Passthrough Bus> on mfi=
0
mfi0: 10014 (708822708s/0x0020/info) - Shutdown command re=
ceived from host
mfi0: 10015 (boot + 3s/0x0020/info) - Firmw=
are initialization started (PCI ID 00
79/1000/1176/1734)
mfi0: 10016 (boot + 3s/0x0020/info) - Firmware version 2.130.35=
3-2727
mfi0: 10017 (boot + 6s/0x0020/info) - Package version=
 12.12.0-0174
mfi0: 10018 (boot + 6s/0x0020/info) - Board Re=
vision

mfi1: <LSI MegaSAS Gen2> port 0=
xc000-0xc0ff mem 0xfba9c000-0xfba9ffff,0xfbac0000
-0xfbaffff=
f irq 16 at device 0.0 on pci8
mfi1: Using MSI
mfi1: Megaraid SAS driver Ver 4.23
mfi1: FW MaxCmds =3D 1=
008, limiting to 128


=

Subvendor is Fujitsu Siemens - so I guess this is integrated into=
 a system by them.

Seems like flashing the 2108 to a=
n IT firmware isn=E2=80=99t an option (based on what I found online). You co=
uld check if there are firmware updates available though. How did you config=
ure the drives in the megaraid utility (ctrl-h after boot)? Did you create a=
 RAID-0 for each disk? And what capacity is shown in there?

Based on [0], 2108 based controllers don=E2=80=99t support 4kn. IT m=
ode would help (true passthrough), but as written above, I don=E2=80=99t thi=
nk it=E2=80=99s an option for this model.

-m
<=
div dir=3D"ltr">
[0] https://bitdeals.tech/blogs/news/4kn-lsi-comp=
atibility-list


-- 
Larry Rosenman  &=
nbsp;            =
;      http://www.lerctr.org/~ler
Phone: +1 214-642-9640         &=
nbsp;       E-Mail: ler@lerctr.org=

US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
=

--Apple-Mail-A1E7CE4B-3070-4935-B3D7-D687F871FECC--

From nobody Sat Jun 18 13:07:48 2022
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 94D6985CC43
	for ; Sat, 18 Jun 2022 13:07:52 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LQGRW4r3zz3Lyq;
	Sat, 18 Jun 2022 13:07:51 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=YdgNhAURZb9ql64hzVNyhQoYLdbqU1ORLDrWb0KQoa8=; b=qgwlEElccu0G2QFZu9sbNtbfiS
	jaF20397ogvCwW4Zh9YKNnj0ZfUCYhRwoVMeeqChQjSR06qIw0fjQA5IazjbMEQ7iAGOjpj2RKlpZ
	7eQ64G6co55Dd2fefuPACXI+uU/jfxCM8afo349dwv+B//nir9+sdzGB2acT5TybBVLEPLEpxSs6T
	yf+MSvtXR9dsSc6wY6qufOuwWqQVPw9kJ3prarTJJOF9O76TLGSXUgAtCYYACDb1dBy85vfTSmqCa
	1/5ytG3uGA2CX00yN06GFiXjFE6fuN6EDaV78rySvi8mW3xyrlIKDmCjqQi9Ev5BNhtZ1+3bMkxog
	XyX1sGQg==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:24018 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o2YB2-000HcF-Q2;
	Sat, 18 Jun 2022 08:07:48 -0500
Received: from 2600:1700:210:b18f:141b:75a0:6b17:ead3
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sat, 18 Jun 2022 08:07:48 -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
Date: Sat, 18 Jun 2022 08:07:48 -0500
From: Larry Rosenman 
To: Michael Gmelin 
Cc: Alexander Motin , Freebsd current
 
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
In-Reply-To: 
References: <5936c6368df3c7d762d4710d23e7c57c@lerctr.org>
 
Message-ID: <17529e76a2fd0a402a76d758c4f0afd2@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: multipart/alternative;
 boundary="=_3ad31caa63267658732ef3f476c4d2ab"
X-Rspamd-Queue-Id: 4LQGRW4r3zz3Lyq
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=qgwlEElc;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-2.01 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_SPAM_SHORT(0.99)[0.990];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=_3ad31caa63267658732ef3f476c4d2ab
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



On 06/18/2022 3:54 am, Michael Gmelin wrote:

[SNIP]

Subvendor is Fujitsu Siemens - so I guess this is integrated into a 
system by them.

Seems like flashing the 2108 to an IT firmware isn't an option (based on 
what I found online). You could check if there are firmware updates 
available though. How did you configure the drives in the megaraid 
utility (ctrl-h after boot)? Did you create a RAID-0 for each disk? And 
what capacity is shown in there?

Based on [0], 2108 based controllers don't support 4kn. IT mode would 
help (true passthrough), but as written above, I don't think it's an 
option for this model.

-m
   [0] https://bitdeals.tech/blogs/news/4kn-lsi-compatibility-list

as I said earlier in the thread, I've bought 2 of these:
https://www.ebay.com/itm/194910024856

which if I'm reading that chart right should work with the 4Kn drives.

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_3ad31caa63267658732ef3f476c4d2ab
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



On 06/18/2022 3:54 am, Michael Gmelin wrote:


[SNIP]












 


Subvendor is Fujitsu Siemens - so I guess this is integrated into a sy=
stem by them.


 


Seems like flashing the 2108 to an IT firmware isn't an option (based =
on what I found online). You could check if there are firmware updates avai=
lable though. How did you configure the drives in the megaraid utility (ctr=
l-h after boot)? Did you create a RAID-0 for each disk? And what capacity i=
s shown in there?


 


Based on [0], 2108 based controllers don't support 4kn. IT mode would =
help (true passthrough), but as written above, I don't think it's an option=
 for this model.


 


-m


 

[0] https://bitdeals.tech/b=
logs/news/4kn-lsi-compatibility-list







as I said earlier in the thread, =
I've bought 2 of these:
https://www.ebay.com/itm/=
194910024856


 


which if I'm reading that chart right should work with the=
 4Kn drives. 


 

















=
-- 
Larry Rosenman     &n=
bsp;            =
;   http://www.lerctr.org/~ler
Phone: +1 =
214-642-9640           &n=
bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=






--=_3ad31caa63267658732ef3f476c4d2ab--

From nobody Sat Jun 18 13:30:26 2022
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 76B8F86189F
	for ; Sat, 18 Jun 2022 13:30:31 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LQGxd6qnbz3QhR;
	Sat, 18 Jun 2022 13:30:29 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id 0f9712be;
	Sat, 18 Jun 2022 13:30:27 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 4b57baaf (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Sat, 18 Jun 2022 13:30:27 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-46DD323F-1FBD-447B-B54E-9D534D727FA0
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 (1.0)
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
From: Michael Gmelin 
In-Reply-To: <17529e76a2fd0a402a76d758c4f0afd2@lerctr.org>
Date: Sat, 18 Jun 2022 15:30:26 +0200
Cc: Alexander Motin ,
 Freebsd current 
Message-Id: 
References: <17529e76a2fd0a402a76d758c4f0afd2@lerctr.org>
To: Larry Rosenman 
X-Mailer: iPhone Mail (19E258)
X-Rspamd-Queue-Id: 4LQGxd6qnbz3QhR
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-1.86 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[grembo];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MV_CASE(0.50)[];
	 NEURAL_HAM_LONG(-0.27)[-0.268];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.990];
	 R_SPF_SOFTFAIL(0.00)[~all];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail-46DD323F-1FBD-447B-B54E-9D534D727FA0
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On 18. Jun 2022, at 15:10, Larry Rosenman  wrote:
>=20
> =EF=BB=BF
> On 06/18/2022 3:54 am, Michael Gmelin wrote:
>=20
> [SNIP]
>=20
> =20
> Subvendor is Fujitsu Siemens - so I guess this is integrated into a system=
 by them.
> =20
> Seems like flashing the 2108 to an IT firmware isn't an option (based on w=
hat I found online). You could check if there are firmware updates available=
 though. How did you configure the drives in the megaraid utility (ctrl-h af=
ter boot)? Did you create a RAID-0 for each disk? And what capacity is shown=
 in there?
> =20
> Based on [0], 2108 based controllers don't support 4kn. IT mode would help=
 (true passthrough), but as written above, I don't think it's an option for t=
his model.
> =20
> -m
> =20
> [0] https://bitdeals.tech/blogs/news/4kn-lsi-compatibility-list
>=20
>=20
>=20
> as I said earlier in the thread, I've bought 2 of these:
> https://www.ebay.com/itm/194910024856
> =20
> which if I'm reading that chart right should work with the 4Kn drives.=20
> =20

That certainly sounds promising.

Best
Michael
>=20
> --=20
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

--Apple-Mail-46DD323F-1FBD-447B-B54E-9D534D727FA0
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 18. Jun 2022, at 15=
:10, Larry Rosenman <ler@lerctr.org> wrote:

=

=EF=BB=BF

On 06/18/2022 3:54 am, Michael Gmelin wrote:


[SNIP]












 


Subvendor is Fujitsu Siemens - so I guess this is integrated into a sys=
tem by them.


 


Seems like flashing the 2108 to an IT firmware isn't an option (based o=
n what I found online). You could check if there are firmware updates availa=
ble though. How did you configure the drives in the megaraid utility (ctrl-h=
 after boot)? Did you create a RAID-0 for each disk? And what capacity is sh=
own in there?


 


Based on [0], 2108 based controllers don't support 4kn. IT mode would h=
elp (true passthrough), but as written above, I don't think it's an option f=
or this model.


 


-m


 

[0] https://bitdeals.tech/blo=
gs/news/4kn-lsi-compatibility-list







as I said earlier in the thread, I've b=
ought 2 of these:
https://www.ebay.com/itm/1949100248=
56


 


which if I'm reading that chart right should work with the 4=
Kn drives. 


 

That certainly sounds promising.

B=
est
Michael

















<=
span class=3D"sig">-- 
Larry Rosenman      =
            &nbs=
p;  http://www.lerctr.org/~ler
Phone: +1 214-642-96=
40             &=
nbsp;   E-Mail: ler@lerctr.=
org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106





=

--Apple-Mail-46DD323F-1FBD-447B-B54E-9D534D727FA0--

From nobody Sat Jun 18 13:45:50 2022
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 1C7B6864E8D
	for ; Sat, 18 Jun 2022 13:45:52 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LQHHM2ShCz3kwk;
	Sat, 18 Jun 2022 13:45:51 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=GzscihCY/pbvTxz9hVzWQpbQNm+6zjvyvjr64sZK/IQ=; b=tuvIQOLbtwcbY2hNG4o7xErrUT
	b3KA/x7NMle8ss59R2yOutXikBYGscCutstUmPrh/efadwKuXyM1OmK1BVaxPuLzEGemZ7NDZQPV+
	Ahysqs9512lrRhCV5tOrvGw2TxzESCgPHUkpYvsVLGBL0IWe90A9oRq5eqHb183l1oZulTW8MOlsQ
	KdnpoU4w78HU1mf5QN/CKBuS5Ae8huuaN1OJIzag5Qs18O9PGIdzZNKVdmW5q3+IYk+fDq+csUYKI
	5CCHCIl9ym0aC6dlhB46MAJvetev5FxcbQPbtTwEKJ6pIO7U7dQXE/UJv5APInhmmSlFE7ejTBkzW
	ZWVjigHw==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:46285 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o2Ylq-000IIV-Q4;
	Sat, 18 Jun 2022 08:45:50 -0500
Received: from 2600:1700:210:b18f:141b:75a0:6b17:ead3
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sat, 18 Jun 2022 08:45:50 -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
Date: Sat, 18 Jun 2022 08:45:50 -0500
From: Larry Rosenman 
To: Michael Gmelin 
Cc: Alexander Motin , Freebsd current
 
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
In-Reply-To: 
References: <17529e76a2fd0a402a76d758c4f0afd2@lerctr.org>
 
Message-ID: <7c70b29bd38a656420e141c64fbd43d2@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: multipart/alternative;
 boundary="=_1994837e4f04e794b4e32ea847baafbc"
X-Rspamd-Queue-Id: 4LQHHM2ShCz3kwk
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=tuvIQOLb;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.83 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+mx:c];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-0.83)[-0.833];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=_1994837e4f04e794b4e32ea847baafbc
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



On 06/18/2022 8:30 am, Michael Gmelin wrote:

>> On 18. Jun 2022, at 15:10, Larry Rosenman  wrote:
> 
>> On 06/18/2022 3:54 am, Michael Gmelin wrote:
>> 
>> [SNIP]
>> 
>> Subvendor is Fujitsu Siemens - so I guess this is integrated into a 
>> system by them.
>> 
>> Seems like flashing the 2108 to an IT firmware isn't an option (based 
>> on what I found online). You could check if there are firmware updates 
>> available though. How did you configure the drives in the megaraid 
>> utility (ctrl-h after boot)? Did you create a RAID-0 for each disk? 
>> And what capacity is shown in there?
>> 
>> Based on [0], 2108 based controllers don't support 4kn. IT mode would 
>> help (true passthrough), but as written above, I don't think it's an 
>> option for this model.
>> 
>> -m
>> [0] https://bitdeals.tech/blogs/news/4kn-lsi-compatibility-list
>> 
>> as I said earlier in the thread, I've bought 2 of these:
>> https://www.ebay.com/itm/194910024856
>> 
>> which if I'm reading that chart right should work with the 4Kn drives.
> 
> That certainly sounds promising.
> Best
> Michael
> 
>> --
>> Larry Rosenman                     http://www.lerctr.org/~ler
>> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
>> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

And I realized I didn't answer the question about how stuff was 
configured, each disk is Raid0.  the current

pool is 10x3T disks, and I'm adding 6x8T since the pool is 70% full 
(bacula backups, Time Machine Backups, random other stuff).

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_1994837e4f04e794b4e32ea847baafbc
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



On 06/18/2022 8:30 am, Michael Gmelin wrote:








 


 





On 18. Jun 2022, at 15:10, Larry Rosenman <ler@lerc=
tr.org> wrote:









On 06/18/2022 3:54 am, Michael Gmelin wrote:


[SNIP]












 


Subvendor is Fujitsu Siemens - so I guess this is integrated into a sy=
stem by them.


 


Seems like flashing the 2108 to an IT firmware isn't an option (based =
on what I found online). You could check if there are firmware updates avai=
lable though. How did you configure the drives in the megaraid utility (ctr=
l-h after boot)? Did you create a RAID-0 for each disk? And what capacity i=
s shown in there?


 


Based on [0], 2108 based controllers don't support 4kn. IT mode would =
help (true passthrough), but as written above, I don't think it's an option=
 for this model.


 


-m


 

[0] https://bitdeals.tech/b=
logs/news/4kn-lsi-compatibility-list







as I said earlier in the thread, =
I've bought 2 of these:
https://www.ebay.com/itm/=
194910024856


 


which if I'm reading that chart right should work with the=
 4Kn drives. 


 
















 


That certainly sounds promising.


 

Best

Michael














 















-- 
Larry Rosenman    &nb=
sp;            =
    http://www.lerctr.org/~ler
Phone=
: +1 214-642-9640          &nb=
sp;      E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr,=
 Round Rock, TX 78665-2106
















And I realized I didn't answer the question about how stuff was configur=
ed, each disk is Raid0.  the current


pool is 10x3T disks, and I'm adding 6x8T since the pool is 70% full (bac=
ula backups, Time Machine Backups, random other stuff).







=
-- 
Larry Rosenman     &n=
bsp;            =
;   http://www.lerctr.org/~ler
Phone: +1 =
214-642-9640           &n=
bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=






--=_1994837e4f04e794b4e32ea847baafbc--

From nobody Sun Jun 19 12:06:24 2022
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 0EE0485CCB4
	for ; Sun, 19 Jun 2022 12:06:38 +0000 (UTC)
	(envelope-from freebsd@grem.de)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LQs2N2P9rz4WkJ;
	Sun, 19 Jun 2022 12:06:36 +0000 (UTC)
	(envelope-from freebsd@grem.de)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id 6574094f;
	Sun, 19 Jun 2022 12:06:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=date:from:to:cc
	:subject:message-id:in-reply-to:references:mime-version
	:content-type:content-transfer-encoding; s=20180501; bh=4Qy+UfEh
	EX/CDfSgRP/mPsX57lM=; b=VgXZqT3HLc7yL1iLvpfwuuEL529J0CZH+nwCOVwH
	r+TO3JcoOwYbsyML9yHfVEk6gcJ2GnLsyzI/TF4GE8gAN+NH3qBxVT5Q9bTy8Zl1
	kqjlkQgahZHrdQc+4+yl1UNmmctwt4ItIEM36fRI0bDpYj+uNxK0XFBgdrlxy07N
	p6Lc9/X77Jg1nO8RCHqd6P1aoQ9XY4J8nBx9Q50LdTcIVKTqHsISgmj2IyzFSIXC
	7tKe+Othszam5QBCk88Fu6RnCCum51vbutj28IuHG85JpXLIfKbNz7kRcyYNXOz0
	ONw5xOR9IhUYOyCah7IIIX6sPUi1sNN2fjC8BcPrd0skTw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=date:from:to:cc
	:subject:message-id:in-reply-to:references:mime-version
	:content-type:content-transfer-encoding; q=dns; s=20180501; b=MF
	x9sYhfaYnSq+oUFzrY8J8ewF1sP0EOhgfT2/LWt6M3dQCLZ9QevK/9/Yc8iHnYvK
	elLp7ovWoYflWNo4WmA9s61ymt0dAhR+DT/ZGIWctOhcqjnyUdLtHFMUXPbYR94a
	MktJm92ADPwxs1ZF4Dtfv4E9nC2R2zK0KaBPGRAUMTLD5o2Wz58KQ7oUYI+xDQL4
	hTNNybsf46NRSo2Bq3APT082ZTsEuDUMmoZ3FccQ/0/ObBefiBr3EhTIxmzP3OTD
	XLY2r6QJjHtch4qM4EK8A0WeJ6i3sXclj23RY7ZcEfPdSRgpFSvdRMEDdQFJLtJV
	TGzY0F0ImZICmOzUgD/A==
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 33c04d0d (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Sun, 19 Jun 2022 12:06:34 +0000 (UTC)
Date: Sun, 19 Jun 2022 14:06:24 +0200
From: Michael Gmelin 
To: Warner Losh 
Cc: Ceri Davies , Conrad Meyer ,
 Michael Gmelin , "freebsd-current@freebsd.org"
 
Subject: Re: Reducing SIGINFO verbosity
Message-ID: <20220619140624.21263e46@bsd64.grem.de>
In-Reply-To: 
References: <20210520180155.3e23500e@bsd64.grem.de>
	<20210520185917.GL14975@funkthat.com>
	
	
	
X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}>
 +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl
 LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL
 EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl
 YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq
 AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY
 fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM
 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea
 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+
 xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA
 Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n
 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v
 f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT
 L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF
 CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc
 Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII=
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-Queue-Id: 4LQs2N2P9rz4WkJ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=grem.de header.s=20180501 header.b=VgXZqT3H;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd@grem.de designates 213.239.217.29 as permitted sender) smtp.mailfrom=freebsd@grem.de
X-Spamd-Result: default: False [-3.14 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[grem.de:s=20180501];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:213.239.217.29/32];
	 NEURAL_HAM_LONG(-0.91)[-0.906];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[grem.de];
	 NEURAL_HAM_MEDIUM(-0.93)[-0.925];
	 RCPT_COUNT_FIVE(0.00)[5];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[grem.de:+];
	 NEURAL_HAM_SHORT(-0.81)[-0.810];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On Fri, 21 May 2021 08:36:49 -0600
Warner Losh  wrote:

> On Fri, May 21, 2021 at 7:38 AM Ceri Davies 
> wrote:
>=20
> > On Thu, May 20, 2021 at 03:57:17PM -0700, Conrad Meyer wrote: =20
> > > No, I don=E2=80=99t think there=E2=80=99s any reason to default it di=
fferently on
> > > stable =20
> > vs =20
> > > current. I think it=E2=80=99s useful (and I prefer the more verbose f=
orm,
> > > which isn=E2=80=99t the default). =20
> >
> > I agree that there's no reason for the default to be different, but
> > I would say that it is much easier for someone who knows that there
> > is a default to be changed to change it, than it is for someone who
> > does not. Therefore, if the information is not useful to someone
> > who does not know how to get rid of it, then it should default to
> > not being displayed, IMHO.
> > =20
>=20
> I plan on changing the default for non-INVARIANT kernels back to
> the old behavior.
>=20
> INVARIANT kernels will keep this behavior because it's a debugging
> kernel and this is one more thing to help debugging problems.
>=20

Did this ever happen? I just installed a fresh 13.1-RELEASE production
system (non-INVARIANT kernel) and it seems like SIGINFO still outputs
kernel stack information.

Cheers
Michael

--=20
Michael Gmelin

From nobody Sun Jun 19 15:05:08 2022
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 D42CA874D4D
	for ; Sun, 19 Jun 2022 15:05:27 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LQx0k43qCz4sVT
	for ; Sun, 19 Jun 2022 15:05:26 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x92a.google.com with SMTP id n16so934341ual.12
        for ; Sun, 19 Jun 2022 08:05:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=V9r8Ugp+syp3qNHjKIb8pTg6lNxiJlS+RmBnW4+Af8g=;
        b=1ShhwtR+d/nq5jNn2rLUx2obmwkcyiw0RwdwPPzj1PNqqbd/AIEDhU/IE82xu44qNp
         IhdDgcwV7ev1D6lQjGzPGtJT8ATTRP6isFSeuJJQ7oSGAGQEfQUKmsSP3EmAWdxK3d6+
         grNu0sKw2i09b1ajfF2lgXyM9tjVkgrrfb4Cmx8aSJ7v8iBr0RRQZM1AlmLpq54LIhef
         cIkLQN+dcrbdglRb2X4RjU03ycRXvU7OH3tTGHKUMpO1iEfbH4mPe+Px/3I58i2w1/UN
         1ytCkofgrJrU+s2glz+Bw7ohx+Tgj63g+axsRQ6wGfqKQOVeZlNDfHrbrY4bJO7B2VIc
         Mr7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=V9r8Ugp+syp3qNHjKIb8pTg6lNxiJlS+RmBnW4+Af8g=;
        b=NYFbY06tsVkODFCz8cXvQbisePiXZ13NzSVa+1MX4UopL2IdKgCzilMmynWOiELOj8
         m+xK4PABs2jtbtYly/ZoHrI+UfkQs9ym73NXwQtrtLhtP9Jmu5ZIgyzHoSCXaKX/rUTJ
         i5ZyccwAZ4XVhKR1jvDPuC/EXatCae6w68qow2502BjH4fc+D59x4vjEigxvH8HZpWwq
         gLW1+zb4RTlx/1qXkuMyf93Zp9SXfZQE8kjyL9Y5lJk1396y/qyUErq/O5ANaE9AgTVF
         EH/ZtFJFOcbXBG0PeQnqgWnNZsEBGUmTE3J+biY50lnHVrfg/4k/t3jC+yFJxBQc9Woq
         IrIg==
X-Gm-Message-State: AJIora8t29hTJsE20CPgkIizbAn2tKW2T7oP7tTmbANWYEd5Tgt02hW3
	cMEFEDPm7fAt1/bO7YKjetND7+JY8QidH1b2fF7AuQ==
X-Google-Smtp-Source: AGRyM1v0B+wj6FmMBC6JshIbgvj+ZcY07gA9nSyeBZ+3VRYpop4hgCY4LgKzK3y5jUPWDJoBjsICBLJVBuhULo3g85E=
X-Received: by 2002:ab0:2a47:0:b0:37c:6868:2ec4 with SMTP id
 p7-20020ab02a47000000b0037c68682ec4mr6354707uar.48.1655651119314; Sun, 19 Jun
 2022 08:05:19 -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: <20210520180155.3e23500e@bsd64.grem.de> <20210520185917.GL14975@funkthat.com>
 
  
 <20220619140624.21263e46@bsd64.grem.de>
In-Reply-To: <20220619140624.21263e46@bsd64.grem.de>
From: Warner Losh 
Date: Sun, 19 Jun 2022 09:05:08 -0600
Message-ID: 
Subject: Re: Reducing SIGINFO verbosity
To: Michael Gmelin 
Cc: Ceri Davies , Conrad Meyer , 
	"freebsd-current@freebsd.org" 
Content-Type: multipart/alternative; boundary="000000000000d6c9d005e1ce5087"
X-Rspamd-Queue-Id: 4LQx0k43qCz4sVT
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=1ShhwtR+;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92a) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-0.84 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 NEURAL_HAM_MEDIUM(-0.32)[-0.325];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 NEURAL_SPAM_SHORT(0.48)[0.482];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92a:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000d6c9d005e1ce5087
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 19, 2022 at 6:06 AM Michael Gmelin  wrote:

>
>
> On Fri, 21 May 2021 08:36:49 -0600
> Warner Losh  wrote:
>
> > On Fri, May 21, 2021 at 7:38 AM Ceri Davies 
> > wrote:
> >
> > > On Thu, May 20, 2021 at 03:57:17PM -0700, Conrad Meyer wrote:
> > > > No, I don=E2=80=99t think there=E2=80=99s any reason to default it =
differently on
> > > > stable
> > > vs
> > > > current. I think it=E2=80=99s useful (and I prefer the more verbose=
 form,
> > > > which isn=E2=80=99t the default).
> > >
> > > I agree that there's no reason for the default to be different, but
> > > I would say that it is much easier for someone who knows that there
> > > is a default to be changed to change it, than it is for someone who
> > > does not. Therefore, if the information is not useful to someone
> > > who does not know how to get rid of it, then it should default to
> > > not being displayed, IMHO.
> > >
> >
> > I plan on changing the default for non-INVARIANT kernels back to
> > the old behavior.
> >
> > INVARIANT kernels will keep this behavior because it's a debugging
> > kernel and this is one more thing to help debugging problems.
> >
>
> Did this ever happen? I just installed a fresh 13.1-RELEASE production
> system (non-INVARIANT kernel) and it seems like SIGINFO still outputs
> kernel stack information.
>

I forgot before 13.1.

Warner

--000000000000d6c9d005e1ce5087
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Jun 19, 2022 at 6:06 AM Micha=
el Gmelin <freebsd@grem.de> wr=
ote:




On Fri, 21 May 2021 08:36:49 -0600

Warner Losh <imp@bsd=
imp.com> wrote:



> On Fri, May 21, 2021 at 7:38 AM Ceri Davies <ceri@submonkey.net>

> wrote:

> 

> > On Thu, May 20, 2021 at 03:57:17PM -0700, Conrad Meyer wrote:=C2=
=A0 

> > > No, I don=E2=80=99t think there=E2=80=99s any reason to defa=
ult it differently on

> > > stable=C2=A0 

> > vs=C2=A0 

> > > current. I think it=E2=80=99s useful (and I prefer the more =
verbose form,

> > > which isn=E2=80=99t the default).=C2=A0 

> >

> > I agree that there's no reason for the default to be differen=
t, but

> > I would say that it is much easier for someone who knows that the=
re

> > is a default to be changed to change it, than it is for someone w=
ho

> > does not. Therefore, if the information is not useful to someone<=
br>
> > who does not know how to get rid of it, then it should default to=


> > not being displayed, IMHO.

> >=C2=A0 

> 

> I plan on changing the default for non-INVARIANT kernels back to

> the old behavior.

> 

> INVARIANT kernels will keep this behavior because it's a debugging=


> kernel and this is one more thing to help debugging problems.

> 



Did this ever happen? I just installed a fresh 13.1-RELEASE production

system (non-INVARIANT kernel) and it seems like SIGINFO still outputs

kernel stack information.

I forgot befo=
re 13.1.

Warner


--000000000000d6c9d005e1ce5087--

From nobody Mon Jun 20 22:12:24 2022
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 07BE1858774
	for ; Mon, 20 Jun 2022 22:12:34 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LRkR46wVSz4ZDb
	for ; Mon, 20 Jun 2022 22:12:32 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To:
	From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=up1j6NOP4w94pMAIE5NX98ihuqMqGep4e1qLrfZtzJM=; b=GKq6QOmDIpqibqPWEGn/T6NP2e
	+jPNrtIzg80twacSnzPda04+86c+j15ezJdQsuF3OBpetN2BV9pso6OnkYbJTaZFNrICdvq9UTqUe
	AnxnQcy+HlBzHl0yaDb593A1WMU3V4bYN6beA2kRoV9vWLALhAa57ull0ZbVgHkCcLFdFy+jefU/2
	5jMBWo5dtXJphIyDEqJR4loRSX9DkIHee4iXhnje428H8CVFElNF4Qdcz4b3IbSCixvOWDP+T0A41
	H3GmLPNZnB8hZgumHyBuGoAySV9HBUqTv/6r9968nFtIo503TJZXEsf1zVIhpxUdHgkOblthsNJ7S
	VsoMd5yw==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:30849 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o3PdA-000LM0-VC
	for freebsd-current@freebsd.org;
	Mon, 20 Jun 2022 17:12:25 -0500
Received: from 2600:1700:210:b18f:4581:6159:f336:70db
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Mon, 20 Jun 2022 17:12:24 -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
Date: Mon, 20 Jun 2022 17:12:24 -0500
From: Larry Rosenman 
To: Freebsd current 
Subject: MCE: Does this look possibly like a slot issue?
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LRkR46wVSz4ZDb
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=GKq6QOmD;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-2.94 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 ARC_NA(0.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-0.94)[-0.938];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this 
DIMM a couple of times, and still the MCE's continue.
Is it possible it's Motherboard slot issue?

Hardware event. This is not a software error.
MCE 8
CPU 22 BANK 8 TSC 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6e800
TIME 1655762472 Mon Jun 20 17:01:12 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 46
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Tue Jun 21 00:19:05 2022
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 8252F86A818
	for ; Tue, 21 Jun 2022 00:19:19 +0000 (UTC)
	(envelope-from ultima1252@gmail.com)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LRnFL3Rtfz4ppq
	for ; Tue, 21 Jun 2022 00:19:18 +0000 (UTC)
	(envelope-from ultima1252@gmail.com)
Received: by mail-lf1-x133.google.com with SMTP id a29so19725678lfk.2
        for ; Mon, 20 Jun 2022 17:19:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=FrTsWolTM/3RpQlDexHAGOajxRrbTeq57sZK1C5Binc=;
        b=FJ+RJozHbYR/yA6KRau/H8KWyuI2AE2vpJ3wnAUS0yeP3+5hMWMVIn4l+5N9zVXyyL
         HnsjhLUW2tRccp64FviSEKeKHOpThrJwz7zFKNfzd/wQu/ld31UmZVl2GVO4ZwXWw9Jq
         2zrm4q7L5yr1DZjL6YjBQQAiF5HTmi+/6xWwHVjthB8pmhELQlIWbxSKtxTCZKO4Mbcy
         MPOBa1AbEVCM/OAJgkyKPCOGFVdN9k0NtIRBO7ni/v5kIx0LxUgPZwZEWmG21HoJwT2j
         oC0VwAdXAZ9CQjdDqwphZmsW0Y4n648uW4Wjb0S73Zfngxo6cpMIO56EfpBVKhFvmDj9
         OPXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=FrTsWolTM/3RpQlDexHAGOajxRrbTeq57sZK1C5Binc=;
        b=g8NiFXhkGXwJQo1hRoqeEkXk0LgULGXugrdOWxqFkOIxhr12AF9QV36k81/Hm9ov2s
         N6JLqhYMe3LAhfMGL52OcAt0l1/I8B6Px0nosUgr8Vowj4wbi6FzKTprXGQwXfwHdjhy
         d0U8Bu29mV+8bhfpGsae5egByeAxfWY/6Cp2qaHRTSksoT9oZ6LXyzXev2/Dk+hg/WbE
         C4OFf/7Q8qx9I7BaDDMr5vRNQa4+NgLG/f7AQ2KzA4dN66aLOcmfQaTlEKSqZFB0IcQ/
         GMWQO5VEihbMr8q7oiHeibZ2YyCRYpgrWgcSSP4VhNNChWJYgUPIh4trQzJVP7O/n0kc
         JcqQ==
X-Gm-Message-State: AJIora8HaV4Hq36rYGNRMbOiguzPsnTk9uAgPQhjlggUSW06izjLuyy7
	/zd4mZaiYru2nmOqyrcvAt5LyTUZS7wukqv4p0DmK99u
X-Google-Smtp-Source: AGRyM1uZe7C4TLcURn2zINySMgr0iOihohSwiVSayOdJq3vB7R73dpUGbDNcgR85oMb26sOHMIcSlH0DfdDRKtkdmrY=
X-Received: by 2002:a05:6512:2808:b0:47f:51c4:1dea with SMTP id
 cf8-20020a056512280800b0047f51c41deamr11104242lfb.390.1655770757059; Mon, 20
 Jun 2022 17:19:17 -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: Ultima 
Date: Mon, 20 Jun 2022 17:19:05 -0700
Message-ID: 
Subject: Re: MCE: Does this look possibly like a slot issue?
To: Larry Rosenman 
Cc: Freebsd current 
Content-Type: multipart/alternative; boundary="000000000000cdd90a05e1ea2b38"
X-Rspamd-Queue-Id: 4LRnFL3Rtfz4ppq
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=FJ+RJozH;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of ultima1252@gmail.com designates 2a00:1450:4864:20::133 as permitted sender) smtp.mailfrom=ultima1252@gmail.com
X-Spamd-Result: default: False [-2.98 / 15.00];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.98)[-0.981];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::133:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000cdd90a05e1ea2b38
Content-Type: text/plain; charset="UTF-8"

Hey Larry,

 It is possible it's the motherboard itself, but it's rare. The way I
would determine this is to swap the DIMM module with another
populated slot on the motherboard and see if the error migrated
to the new slot or not. Also, this error doesn't necessarily mean
there is a problem that needs to be addressed. If you have been
running the system for many months and you see ECC errors a
handful of times, it can probably be safely ignored.

Best regards,
Richard Gallamore

On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman  wrote:

> I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this
> DIMM a couple of times, and still the MCE's continue.
> Is it possible it's Motherboard slot issue?
>
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655762472 Mon Jun 20 17:01:12 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
>
>
>
> --
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>
>

--000000000000cdd90a05e1ea2b38
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey Larry,

=C2=A0It is possi=
ble it's the motherboard itself, but it's rare. The way I
would determine this is to swap the DIMM module with another
pop=
ulated slot on the motherboard and see if the error migrated
to t=
he new slot or not. Also, this error doesn't necessarily mean
there is a problem that needs to be addressed. If you have been
=
running the system for many months and you see ECC errors a
handf=
ul of times, it can probably be safely ignored.

Be=
st regards,
Richard Gallamore
 

On Mon, Jun 20, 2022 at 3=
:14 PM Larry Rosenman <ler@lerctr.org<=
/a>> wrote:
I=
've gotten a BUNCH of these on my TrueNAS server.=C2=A0 I've replac=
ed this 

DIMM a couple of times, and still the MCE's continue.

Is it possible it's Motherboard slot issue?



Hardware event. This is not a software error.

MCE 8

CPU 22 BANK 8 TSC 5aa4ecdd795a

MISC ac29890200046646 ADDR ee2f6e800

TIME 1655762472 Mon Jun 20 17:01:12 2022

MCG status:

Memory read ECC error

Memory corrected error count (CORE_ERR_CNT): 1

Memory transaction Tracker ID (RTId): 46

Memory DIMM ID of error: 0

Memory channel ID of error: 1

Memory ECC syndrome: ac298902

STATUS 8c0000400001009f MCGSTATUS 0

MCGCAP 1c09 APICID 34 SOCKETID 0

CPUID Vendor Intel Family 6 Model 44 Step 2

DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB

Device Locator: P2-DIMM2C

Bank Locator: BANK14

Manufacturer: Hyundai

Serial Number: 40F3C20F

Asset Tag:

Part Number: HMT151R7BFR4C-H9







-- 

Larry Rosenman=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0http://www.lerctr.org/~ler

Phone: +1 214-642-9640=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0E-Mail: ler@l=
erctr.org

US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106






--000000000000cdd90a05e1ea2b38--

From nobody Tue Jun 21 00:23:56 2022
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 A4AB786BBAE
	for ; Tue, 21 Jun 2022 00:23:59 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LRnLk6LVPz4rKW
	for ; Tue, 21 Jun 2022 00:23:58 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=ikx7BGB5j1a3883+hjEVbBPNu7diBV0kxjsoM7ogdDg=; b=IoG8+S98enc7ZcxILN8WtjoIrR
	Fl0k97CFcek5x18DPdHKW5oQpoxz0VT2oeas0008aIJKfdl0ILqPojavmVNJ859rvcbMpIDpIsaZ5
	nEW5bNJQfnVEFbWt6tqcVmUeOhunPFRbEn7P4KxOdKUO2yDE0lzSpgpYiVq7v3ULxZ27qLFYmB057
	ViI95c+Gei0v1NrzRT21tIeoLPDEoa+6nBaYqZMVVF0eoip3tOogQiB2I/htnnNSqStOnWOi1LY2J
	hAg0XB/VdMxyHhduzc2ZlO94N5KqLvVZLost/7kj4tbqkN7LimoqjppPMPTQJIAk0edoo0PGCeKn3
	+XkX6k9Q==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:59729 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o3RgS-000NYa-DI;
	Mon, 20 Jun 2022 19:23:56 -0500
Received: from 2600:1700:210:b18f:7139:7834:f65d:718c
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Mon, 20 Jun 2022 19:23:56 -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
Date: Mon, 20 Jun 2022 19:23:56 -0500
From: Larry Rosenman 
To: Ultima 
Cc: Freebsd current 
Subject: Re: MCE: Does this look possibly like a slot issue?
In-Reply-To: 
References: 
 
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: multipart/alternative;
 boundary="=_8fe087faf2cbfc1449967c53350e6d2c"
X-Rspamd-Queue-Id: 4LRnLk6LVPz4rKW
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=IoG8+S98;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-2.44 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 ARC_NA(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-0.44)[-0.442];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=_8fe087faf2cbfc1449967c53350e6d2c
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



I'm seeing them constantly:

root@freenas[~]# mcelog --dmi
Hardware event. This is not a software error.
MCE 0
CPU 22 BANK 8 TSC 20aab486464a
MISC ac29890200046444 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 44
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 1
CPU 22 BANK 8 TSC 296dfcc82582
MISC ac29890200041381 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 2
CPU 22 BANK 8 TSC 2a5604a6a070
MISC ac29890200044281
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory ECC error occurred during scrub
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 88000040000200cf MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 3
CPU 22 BANK 8 TSC 31e141418eb8
MISC ac29890200046a4a ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 4
CPU 22 BANK 8 TSC 3a014afee106
MISC ac29890200046646 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 46
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 5
CPU 22 BANK 8 TSC 41d1dbef1a6a
MISC ac29890200046141 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 41
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 6
CPU 22 BANK 8 TSC 4a1b1ecef446
MISC ac29890200046a4a ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 7
CPU 22 BANK 8 TSC 527bc27db776
MISC ac29890200040386 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 86
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE 8
CPU 22 BANK 8 TSC 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 46
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
root@freenas[~]#

and I replaced the DIMM yesterday :(

On 06/20/2022 7:19 pm, Ultima wrote:

> Hey Larry,
> 
> It is possible it's the motherboard itself, but it's rare. The way I
> would determine this is to swap the DIMM module with another
> populated slot on the motherboard and see if the error migrated
> to the new slot or not. Also, this error doesn't necessarily mean
> there is a problem that needs to be addressed. If you have been
> running the system for many months and you see ECC errors a
> handful of times, it can probably be safely ignored.
> 
> Best regards,
> Richard Gallamore
> 
> On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman  wrote:
> 
>> I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this
>> DIMM a couple of times, and still the MCE's continue.
>> Is it possible it's Motherboard slot issue?
>> 
>> Hardware event. This is not a software error.
>> MCE 8
>> CPU 22 BANK 8 TSC 5aa4ecdd795a
>> MISC ac29890200046646 ADDR ee2f6e800
>> TIME 1655762472 Mon Jun 20 17:01:12 2022
>> MCG status:
>> Memory read ECC error
>> Memory corrected error count (CORE_ERR_CNT): 1
>> Memory transaction Tracker ID (RTId): 46
>> Memory DIMM ID of error: 0
>> Memory channel ID of error: 1
>> Memory ECC syndrome: ac298902
>> STATUS 8c0000400001009f MCGSTATUS 0
>> MCGCAP 1c09 APICID 34 SOCKETID 0
>> CPUID Vendor Intel Family 6 Model 44 Step 2
>> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
>> Device Locator: P2-DIMM2C
>> Bank Locator: BANK14
>> Manufacturer: Hyundai
>> Serial Number: 40F3C20F
>> Asset Tag:
>> Part Number: HMT151R7BFR4C-H9
>> 
>> --
>> Larry Rosenman                     http://www.lerctr.org/~ler
>> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
>> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_8fe087faf2cbfc1449967c53350e6d2c
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



I'm seeing them constantly:


root@freenas[~]# mcelog --dmi
Hardware event. This is not a softwar=
e error.
MCE 0
CPU 22 BANK 8 TSC 20aab486464a
MISC ac2989020=
0046444 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
M=
CG status:
Memory read ECC error
Memory corrected error count (CO=
RE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 44
Memory DI=
MM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndro=
me: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APIC=
ID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
WARN=
ING: SMBIOS data is often unreliable. Take with a grain of salt!
DDR3 =
DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2=
-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Nu=
mber: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hard=
ware event. This is not a software error.
MCE 1
CPU 22 BANK 8 TSC=
 296dfcc82582
MISC ac29890200041381 ADDR ee2f6e800
TIME 165577098=
9 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tra=
cker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID o=
f error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f =
MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel F=
amily 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64=
 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Ma=
nufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part =
Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.=

MCE 2
CPU 22 BANK 8 TSC 2a5604a6a070
MISC ac29890200044281<=
br />TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory =
ECC error occurred during scrub
Memory corrected error count (CORE_ERR=
_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID =
of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac=
298902
STATUS 88000040000200cf MCGSTATUS 0
MCGCAP 1c09 APICID 34 =
SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware e=
vent. This is not a software error.
MCE 3
CPU 22 BANK 8 TSC 31e14=
1418eb8
MISC ac29890200046a4a ADDR ee2f6e800
TIME 1655770989 Mon =
Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memor=
y corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker I=
D (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of erro=
r: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTA=
TUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family =
6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size =
4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufact=
urer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number=
: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
=
MCE 4
CPU 22 BANK 8 TSC 3a014afee106
MISC ac29890200046646 ADDR e=
e2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1=

Memory transaction Tracker ID (RTId): 46
Memory DIMM ID of error=
: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID=
 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz =
Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
=
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20=
F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. T=
his is not a software error.
MCE 5
CPU 22 BANK 8 TSC 41d1dbef1a6a=

MISC ac29890200046141 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 =
19:23:09 2022
MCG status:
Memory read ECC error
Memory corre=
cted error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId=
): 41
Memory DIMM ID of error: 0
Memory channel ID of error: 1Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model=
 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GBDevice Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: H=
yundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT15=
1R7BFR4C-H9
Hardware event. This is not a software error.
MCE 6CPU 22 BANK 8 TSC 4a1b1ecef446
MISC ac29890200046a4a ADDR ee2f6e80=
0
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memor=
y read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
M=
emory transaction Tracker ID (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STA=
TUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other W=
idth 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Lo=
cator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
=
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is =
not a software error.
MCE 7
CPU 22 BANK 8 TSC 527bc27db776
M=
ISC ac29890200040386 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:0=
9 2022
MCG status:
Memory read ECC error
Memory corrected er=
ror count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 86Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memo=
ry ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCG=
CAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Ste=
p 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Devi=
ce Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai<=
br />Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4=
C-H9
Hardware event. This is not a software error.
MCE 8
CPU=
 22 BANK 8 TSC 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6e800
=
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read =
ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory t=
ransaction Tracker ID (RTId): 46
Memory DIMM ID of error: 0
Memor=
y channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0=
000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID =
Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72=
 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: =
BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset T=
ag:
Part Number: HMT151R7BFR4C-H9
root@freenas[~]#





and I replaced the DIMM yesterday :( 








On 06/20/2022 7:19 pm, Ultima wrote:








Hey Larry,


 


 It is possible it's the motherboard itself, but it's rare. The w=
ay I


would determine this is to swap the DIMM module with another


populated slot on the motherboard and see if the error migrated


to the new slot or not. Also, this error doesn't necessarily mean


there is a problem that needs to be addressed. If you have been


running the system for many months and you see ECC errors a


handful of times, it can probably be safely ignored.


 


Best regards,


Richard Gallamore








On Mon, Jun 20, 2022 at 3:14 PM Lar=
ry Rosenman <ler@le=
rctr.org> wrote:


I've gotten a BUNCH of the=
se on my TrueNAS server.  I've replaced this 
DIMM a couple of ti=
mes, and still the MCE's continue.
Is it possible it's Motherboard slo=
t issue?

Hardware event. This is not a software error.
MCE =
8
CPU 22 BANK 8 TSC 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6=
e800
TIME 1655762472 Mon Jun 20 17:01:12 2022
MCG status:
Me=
mory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 46
Memory DIMM ID of error: 0<=
br />Memory channel ID of error: 1
Memory ECC syndrome: ac298902
=
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Othe=
r Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank=
 Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20FAsset Tag:
Part Number: HMT151R7BFR4C-H9



-- =

Larry Rosenman               =
      http://www.lerctr.org/~ler
Phone: +=
1 214-642-9640                 =
;E-Mail: ler@lerctr.or=
g
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106














=
-- 
Larry Rosenman     &n=
bsp;            =
;   http://www.lerctr.org/~ler
Phone: +1 =
214-642-9640           &n=
bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=






--=_8fe087faf2cbfc1449967c53350e6d2c--

From nobody Tue Jun 21 00:37:43 2022
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 290F986D76D
	for ; Tue, 21 Jun 2022 00:37:57 +0000 (UTC)
	(envelope-from ultima1252@gmail.com)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LRnfr2tvLz4svW
	for ; Tue, 21 Jun 2022 00:37:56 +0000 (UTC)
	(envelope-from ultima1252@gmail.com)
Received: by mail-lj1-x22f.google.com with SMTP id b7so13662341ljr.6
        for ; Mon, 20 Jun 2022 17:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=328xgKLhbP3p0dlNo4+L9GxyK6CRxvqZSKOhvffqrf0=;
        b=Ifvk6pAF61zmbDtYEUHLgQFQdtfW8XJ8cpjuno+wvyXcnafna7yq48sER1vQ/Mranw
         59sn/VTcegKGgd7Xem7yhdMcRUuSHRf8WoXlwu0NOfbo0PLHFnC9nGzzZh0jJSQmPybU
         cgmTI3jY9D8yWjKhr/rEzUMkRLYAcwYeKvhxCio2wG3/8fgsa5+OW2U299NS5uKm4BUJ
         b0wj4ULIOuluqGvX5si0MedxbY/rEOb3RTD4a+m598wcMzAlwoB/lbKzqZQO+xdstk6m
         15ou4jwJxegXVElmltpyIZonIwzzGrPGt/8/huvXSn2DQpXvnbkuo0TWvV8a2MX3hGwA
         6Bpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=328xgKLhbP3p0dlNo4+L9GxyK6CRxvqZSKOhvffqrf0=;
        b=THEk1kCtgCNYHO/D1qR3szFqoIP6poRS/3Rx45KVWbExbrGsGsHpWczp0/nwmrf0Tb
         UNJVWYZyxuXe6M7sE5ysdhAcd2QjXOCENZlHmhhIsh45MvVixtrw01pw8zZMAWcMMaZA
         gwP+KkdAF2APNMuipm2OxUbVquienc1K0y2lJYCuaLBxJypxYSw/9j23S645zkGOsxO+
         rnqEF1DQHMXD/Iyt550P67NyCL4i5t9/NdPB+0c9Qq10AXDcLun08zHVqicvwKRcKb3f
         TWnMTsFSdbxeBs72P5JR/kZ0BNfvgoR3Y++6ryYsVU0MfzVHg5Leyfs1Hbpz3Kdrk82t
         a7Bg==
X-Gm-Message-State: AJIora9rOoOOxrYusRCqFtP0z26kERTDbMgzZtgkQhtOw6qb70EvVHXA
	dlTWhV+2bcajJOt/a2Jx3+KxE9yC4ULGG9p2oDMrHBoU
X-Google-Smtp-Source: AGRyM1tV97XPZ8OYrhGveyUNMVhbVPr1t4uQLcccYHoBtZoyss9wehuJyysMLbYFXfwX5sa/MFZXBKOxMjumlUgzfPE=
X-Received: by 2002:a2e:b4a8:0:b0:25a:672b:92a1 with SMTP id
 q8-20020a2eb4a8000000b0025a672b92a1mr5584001ljm.349.1655771874997; Mon, 20
 Jun 2022 17:37:54 -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: Ultima 
Date: Mon, 20 Jun 2022 17:37:43 -0700
Message-ID: 
Subject: Re: MCE: Does this look possibly like a slot issue?
To: Larry Rosenman 
Cc: Freebsd current 
Content-Type: multipart/alternative; boundary="000000000000703e3305e1ea6e47"
X-Rspamd-Queue-Id: 4LRnfr2tvLz4svW
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Ifvk6pAF;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of ultima1252@gmail.com designates 2a00:1450:4864:20::22f as permitted sender) smtp.mailfrom=ultima1252@gmail.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22f:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000703e3305e1ea6e47
Content-Type: text/plain; charset="UTF-8"

Are you sure that the module you replaced it with was good?
Are you sure you replaced the correct module?

Best regards,
Richard Gallamore

On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman  wrote:

> I'm seeing them constantly:
>
> root@freenas[~]# mcelog --dmi
> Hardware event. This is not a software error.
> MCE 0
> CPU 22 BANK 8 TSC 20aab486464a
> MISC ac29890200046444 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 44
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 1
> CPU 22 BANK 8 TSC 296dfcc82582
> MISC ac29890200041381 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 2
> CPU 22 BANK 8 TSC 2a5604a6a070
> MISC ac29890200044281
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory ECC error occurred during scrub
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 88000040000200cf MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> Hardware event. This is not a software error.
> MCE 3
> CPU 22 BANK 8 TSC 31e141418eb8
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 4
> CPU 22 BANK 8 TSC 3a014afee106
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 5
> CPU 22 BANK 8 TSC 41d1dbef1a6a
> MISC ac29890200046141 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 41
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 6
> CPU 22 BANK 8 TSC 4a1b1ecef446
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 7
> CPU 22 BANK 8 TSC 527bc27db776
> MISC ac29890200040386 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 86
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> root@freenas[~]#
>
>
> and I replaced the DIMM yesterday :(
>
>
>
> On 06/20/2022 7:19 pm, Ultima wrote:
>
> Hey Larry,
>
>  It is possible it's the motherboard itself, but it's rare. The way I
> would determine this is to swap the DIMM module with another
> populated slot on the motherboard and see if the error migrated
> to the new slot or not. Also, this error doesn't necessarily mean
> there is a problem that needs to be addressed. If you have been
> running the system for many months and you see ECC errors a
> handful of times, it can probably be safely ignored.
>
> Best regards,
> Richard Gallamore
>
> On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman  wrote:
>
> I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this
> DIMM a couple of times, and still the MCE's continue.
> Is it possible it's Motherboard slot issue?
>
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655762472 Mon Jun 20 17:01:12 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
>
>
>
> --
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>
>
> --
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>

--000000000000703e3305e1ea6e47
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Are you sure that the module you replaced it with was=
 good?
Are you sure you replaced the correct module?
Best regards,
Richard Gallamore

<=
div class=3D"gmail_quote">
On Mon, Jun=
 20, 2022 at 5:23 PM Larry Rosenman <l=
er@lerctr.org> wrote:


I'm seeing them constantly:


root@freenas[~]# mcelog --dmi
Hardware event. This is not a software =
error.
MCE 0
CPU 22 BANK 8 TSC 20aab486464a
MISC ac29890200046444 =
ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1Memory transaction Tracker ID (RTId): 44
Memory DIMM ID of error: 0Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8=
c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Ve=
ndor Intel Family 6 Model 44 Step 2
WARNING: SMBIOS data is often unreli=
able. Take with a grain of salt!
DDR3 DIMM 800 Mhz Other Width 72 Data W=
idth 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
M=
anufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Numbe=
r: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE=
 1
CPU 22 BANK 8 TSC 296dfcc82582
MISC ac29890200041381 ADDR ee2f6e80=
0
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read=
 ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory tran=
saction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory chann=
el ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c000040000100=
9f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Fa=
mily 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Si=
ze 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacture=
r: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R=
7BFR4C-H9
Hardware event. This is not a software error.
MCE 2
CPU =
22 BANK 8 TSC 2a5604a6a070
MISC ac29890200044281
TIME 1655770989 Mon =
Jun 20 19:23:09 2022
MCG status:
Memory ECC error occurred during scr=
ub
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction =
Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of=
 error: 1
Memory ECC syndrome: ac298902
STATUS 88000040000200cf MCGST=
ATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 M=
odel 44 Step 2
Hardware event. This is not a software error.
MCE 3CPU 22 BANK 8 TSC 31e141418eb8
MISC ac29890200046a4a ADDR ee2f6e800
=
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC =
error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transacti=
on Tracker ID (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID=
 of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MC=
GSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family =
6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 =
GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hy=
undai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4=
C-H9
Hardware event. This is not a software error.
MCE 4
CPU 22 BA=
NK 8 TSC 3a014afee106
MISC ac29890200046646 ADDR ee2f6e800
TIME 16557=
70989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
M=
emory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker=
 ID (RTId): 46
Memory DIMM ID of error: 0
Memory channel ID of error:=
 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0<=
br>MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44=
 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Devi=
ce Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
S=
erial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Ha=
rdware event. This is not a software error.
MCE 5
CPU 22 BANK 8 TSC 4=
1d1dbef1a6a
MISC ac29890200046141 ADDR ee2f6e800
TIME 1655770989 Mon =
Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corr=
ected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId)=
: 41
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memo=
ry ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP =
1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator=
: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Numb=
er: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware eve=
nt. This is not a software error.
MCE 6
CPU 22 BANK 8 TSC 4a1b1ecef44=
6
MISC ac29890200046a4a ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:=
23:09 2022
MCG status:
Memory read ECC error
Memory corrected erro=
r count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 4a
Me=
mory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syn=
drome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICI=
D 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM=
 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2=
C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C2=
0F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This i=
s not a software error.
MCE 7
CPU 22 BANK 8 TSC 527bc27db776
MISC =
ac29890200040386 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022=

MCG status:
Memory read ECC error
Memory corrected error count (C=
ORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 86
Memory DIMM =
ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac2=
98902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKE=
TID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz O=
ther Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank =
Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asse=
t Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a so=
ftware error.
MCE 8
CPU 22 BANK 8 TSC 5aa4ecdd795a
MISC ac29890200=
046646 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG st=
atus:
Memory read ECC error
Memory corrected error count (CORE_ERR_CN=
T): 1
Memory transaction Tracker ID (RTId): 46
Memory DIMM ID of erro=
r: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
S=
TATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
C=
PUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width=
 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: B=
ANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
=
Part Number: HMT151R7BFR4C-H9
root@freenas[~]#





and I replaced the DIMM yesterday :(=C2=A0








On 06/20/2022 7:19 pm, Ult=
ima wrote:








Hey Larry,


=C2=A0


=C2=A0It is possible it's the motherboard itself, but it's rar=
e. The way I


would determine this is to swap the DIMM module with another


populated slot on the motherboard and see if the error migrated


to the new slot or not. Also, this error doesn't necessarily mean<=
/div>

there is a problem that needs to be addressed. If you have been


running the system for many months and you see ECC errors a


handful of times, it can probably be safely ignored.


=C2=A0


Best regards,


Richard Gallamore








On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman <ler@lerctr.=
org> wrote:


I've gotten a BUNCH of these on my TrueNAS =
server.=C2=A0 I've replaced this 
DIMM a couple of times, and still =
the MCE's continue.
Is it possible it's Motherboard slot issue?<=
br>
Hardware event. This is not a software error.
MCE 8
CPU 22 BAN=
K 8 TSC 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6e800
TIME 165576=
2472 Mon Jun 20 17:01:12 2022
MCG status:
Memory read ECC error
Me=
mory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker =
ID (RTId): 46
Memory DIMM ID of error: 0
Memory channel ID of error: =
1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 =
Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Devic=
e Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Se=
rial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9


-- 
Larry Rosenman=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.lerctr.org/~lerPhone: +1 214-642-9640=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock,=
 TX 78665-2106














--=C2=A0<=
br>Larry Rosenman =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht=
tp://www.lerctr.org/~ler
Phone: +1 214-642-9640 =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0E-Mail: ler@lerctr.o=
rg
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106








--000000000000703e3305e1ea6e47--

From nobody Tue Jun 21 00:41:05 2022
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 8D5B486EE34
	for ; Tue, 21 Jun 2022 00:41:07 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LRnkV5jp8z4vh2
	for ; Tue, 21 Jun 2022 00:41:06 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=dpaUD8QE/4SPk1AY7Sq8MPfOXw86Z/VwJNBtCmX36aU=; b=XqeN/lSR+0RI8977Or8gDo1u0g
	wDoL3XeiNBeMj9MMm0DHeQEuRRkiyhkqbOvRD7e+zmnkEmZ0WynEx4aYqcZGjhyoMJBYWVmxBVm5b
	E1Y/9z7FhIoz2RMN5ON2+D0jXg/XFAxZzlZkMwnhyB7ykD9ylPd1JIhHBg6UHbSxX1jsLguM1fdo7
	p5fkrjbD/3AWnsUb+n+1LXnRkHrUQ7l5wMGiTwPo9eI1jMIpGE9/Wbkwmq9bM5LfY72n9g8owefAy
	i2AoXNiM6mM0ZR4erFXWx0Pi7GjRqfRzJU0Q/qO48Pa3evBDSwtT73nIRzle6UI8J1KDiYmUcb43v
	skU5aAIg==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:26782 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o3Rx4-000Nrk-18;
	Mon, 20 Jun 2022 19:41:06 -0500
Received: from 2600:1700:210:b18f:7139:7834:f65d:718c
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Mon, 20 Jun 2022 19:41:05 -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
Date: Mon, 20 Jun 2022 19:41:05 -0500
From: Larry Rosenman 
To: Ultima 
Cc: Freebsd current 
Subject: Re: MCE: Does this look possibly like a slot issue?
In-Reply-To: 
References: 
 
 
 
Message-ID: <49c1dfe9bbe9912282b0f0339a0c077b@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: multipart/alternative;
 boundary="=_fa2ecf87cc38bff7d7d65b9e0af1d590"
X-Rspamd-Queue-Id: 4LRnkV5jp8z4vh2
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b="XqeN/lSR";
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.00 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=_fa2ecf87cc38bff7d7d65b9e0af1d590
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



Yes and Yes.

On 06/20/2022 7:37 pm, Ultima wrote:

> Are you sure that the module you replaced it with was good?
> Are you sure you replaced the correct module?
> 
> Best regards,
> Richard Gallamore
> 
> On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman  wrote:
> 
> I'm seeing them constantly:
> 
> root@freenas[~]# mcelog --dmi
> Hardware event. This is not a software error.
> MCE 0
> CPU 22 BANK 8 TSC 20aab486464a
> MISC ac29890200046444 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 44
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 1
> CPU 22 BANK 8 TSC 296dfcc82582
> MISC ac29890200041381 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 2
> CPU 22 BANK 8 TSC 2a5604a6a070
> MISC ac29890200044281
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory ECC error occurred during scrub
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 88000040000200cf MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> Hardware event. This is not a software error.
> MCE 3
> CPU 22 BANK 8 TSC 31e141418eb8
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 4
> CPU 22 BANK 8 TSC 3a014afee106
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 5
> CPU 22 BANK 8 TSC 41d1dbef1a6a
> MISC ac29890200046141 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 41
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 6
> CPU 22 BANK 8 TSC 4a1b1ecef446
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 7
> CPU 22 BANK 8 TSC 527bc27db776
> MISC ac29890200040386 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 86
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> root@freenas[~]#
> 
> and I replaced the DIMM yesterday :(
> 
> On 06/20/2022 7:19 pm, Ultima wrote:
> 
> Hey Larry,
> 
> It is possible it's the motherboard itself, but it's rare. The way I
> would determine this is to swap the DIMM module with another
> populated slot on the motherboard and see if the error migrated
> to the new slot or not. Also, this error doesn't necessarily mean
> there is a problem that needs to be addressed. If you have been
> running the system for many months and you see ECC errors a
> handful of times, it can probably be safely ignored.
> 
> Best regards,
> Richard Gallamore
> 
> On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman  wrote: 
> I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this
> DIMM a couple of times, and still the MCE's continue.
> Is it possible it's Motherboard slot issue?
> 
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655762472 Mon Jun 20 17:01:12 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> 
> --
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_fa2ecf87cc38bff7d7d65b9e0af1d590
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



Yes and Yes.





On 06/20/2022 7:37 pm, Ultima wrote:








Are you sure that the module you replaced it with was good?


Are you sure you replaced the correct module?


 


Best regards,


Richard Gallamore








On Mon, Jun 20, 2022 at 5:23 PM Lar=
ry Rosenman <ler@le=
rctr.org> wrote:






I'm seeing them constantly:


root@freenas[~]# mcelog --dmi
Hardware event. This is not a softwar=
e error.
MCE 0
CPU 22 BANK 8 TSC 20aab486464a
MISC ac2989020=
0046444 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
M=
CG status:
Memory read ECC error
Memory corrected error count (CO=
RE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 44
Memory DI=
MM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndro=
me: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APIC=
ID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
WARN=
ING: SMBIOS data is often unreliable. Take with a grain of salt!
DDR3 =
DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2=
-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Nu=
mber: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hard=
ware event. This is not a software error.
MCE 1
CPU 22 BANK 8 TSC=
 296dfcc82582
MISC ac29890200041381 ADDR ee2f6e800
TIME 165577098=
9 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tra=
cker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID o=
f error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f =
MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel F=
amily 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64=
 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Ma=
nufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part =
Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.=

MCE 2
CPU 22 BANK 8 TSC 2a5604a6a070
MISC ac29890200044281<=
br />TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory =
ECC error occurred during scrub
Memory corrected error count (CORE_ERR=
_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID =
of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac=
298902
STATUS 88000040000200cf MCGSTATUS 0
MCGCAP 1c09 APICID 34 =
SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware e=
vent. This is not a software error.
MCE 3
CPU 22 BANK 8 TSC 31e14=
1418eb8
MISC ac29890200046a4a ADDR ee2f6e800
TIME 1655770989 Mon =
Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memor=
y corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker I=
D (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of erro=
r: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTA=
TUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family =
6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size =
4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufact=
urer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number=
: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
=
MCE 4
CPU 22 BANK 8 TSC 3a014afee106
MISC ac29890200046646 ADDR e=
e2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1=

Memory transaction Tracker ID (RTId): 46
Memory DIMM ID of error=
: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID=
 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz =
Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
=
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20=
F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. T=
his is not a software error.
MCE 5
CPU 22 BANK 8 TSC 41d1dbef1a6a=

MISC ac29890200046141 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 =
19:23:09 2022
MCG status:
Memory read ECC error
Memory corre=
cted error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId=
): 41
Memory DIMM ID of error: 0
Memory channel ID of error: 1Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model=
 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GBDevice Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: H=
yundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT15=
1R7BFR4C-H9
Hardware event. This is not a software error.
MCE 6CPU 22 BANK 8 TSC 4a1b1ecef446
MISC ac29890200046a4a ADDR ee2f6e80=
0
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memor=
y read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
M=
emory transaction Tracker ID (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STA=
TUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other W=
idth 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Lo=
cator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
=
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is =
not a software error.
MCE 7
CPU 22 BANK 8 TSC 527bc27db776
M=
ISC ac29890200040386 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:0=
9 2022
MCG status:
Memory read ECC error
Memory corrected er=
ror count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 86Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memo=
ry ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCG=
CAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Ste=
p 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Devi=
ce Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai<=
br />Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4=
C-H9
Hardware event. This is not a software error.
MCE 8
CPU=
 22 BANK 8 TSC 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6e800
=
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read =
ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory t=
ransaction Tracker ID (RTId): 46
Memory DIMM ID of error: 0
Memor=
y channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0=
000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID =
Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72=
 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: =
BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset T=
ag:
Part Number: HMT151R7BFR4C-H9
root@freenas[~=
]#





and I replaced the DIMM yesterday :( 








On 06/20/2022 7:19 pm, U=
ltima wrote:








Hey Larry,


 


 It is possible it's the motherboard itself, but it's rare. The w=
ay I


would determine this is to swap the DIMM module with another


populated slot on the motherboard and see if the error migrated


to the new slot or not. Also, this error doesn't necessarily mean


there is a problem that needs to be addressed. If you have been


running the system for many months and you see ECC errors a


handful of times, it can probably be safely ignored.


 


Best regards,


Richard Gallamore








On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman <ler@lerctr.org> wrote:=



I've gotten a BUNCH of these on my TrueNAS server.=
  I've replaced this 
DIMM a couple of times, and still the MCE's=
 continue.
Is it possible it's Motherboard slot issue?

Hard=
ware event. This is not a software error.
MCE 8
CPU 22 BANK 8 TSC=
 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6e800
TIME 165576247=
2 Mon Jun 20 17:01:12 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tra=
cker ID (RTId): 46
Memory DIMM ID of error: 0
Memory channel ID o=
f error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f =
MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel F=
amily 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64=
 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Ma=
nufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part =
Number: HMT151R7BFR4C-H9



-- 
Larry Rosenman&nbs=
p;                    http://www.lerctr.org/~ler
Phone: +1 214-642-9640  &nb=
sp;              E-Mail: ler@lerctr.org
US Mail: 5708=
 Sabbia Dr, Round Rock, TX 78665-2106














--&=
nbsp;
Larry Rosenman         &=
nbsp;           http://www.lerctr.org/~ler
Phone: +1 214-642-9640  &nbs=
p;            &=
nbsp; E-Mail: ler=
@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106



















=
-- 
Larry Rosenman     &n=
bsp;            =
;   http://www.lerctr.org/~ler
Phone: +1 =
214-642-9640           &n=
bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=






--=_fa2ecf87cc38bff7d7d65b9e0af1d590--

From nobody Tue Jun 21 00:57:05 2022
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 EB0D8871686
	for ; Tue, 21 Jun 2022 00:57:24 +0000 (UTC)
	(envelope-from ultima1252@gmail.com)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LRp5J0YK8z3DSw
	for ; Tue, 21 Jun 2022 00:57:24 +0000 (UTC)
	(envelope-from ultima1252@gmail.com)
Received: by mail-lj1-x230.google.com with SMTP id d19so13672939lji.10
        for ; Mon, 20 Jun 2022 17:57:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=nRRlkP+oml8dggbf2pUr8ybyDdg+5UseGbx4VYgZauk=;
        b=n2Vvpnvlw2EOm6k5Mt9gsUc5VpLWn/v5pYwcHgNkwfpot0ebl9XLVkprtcwC8IKdUB
         CJTlY4gXuRUMrrxVR6m5R8RgKxizjnxkEBdN8SvJ2Hz1DFhchUFxnAvmxQ9Nf8xAe23P
         IeGbIaXgzs5oWHZNA49rRIDQ2RZwH3vZPvz9H4FDtezv35euS/KTHxtdgx6tVeX6Kddb
         1Ue9+moUNH2cXw8UAdAlqP2sYFaROW+moeOckMGYPgz5qcHVWqXRab42JocE/Oni7ELw
         aF9DmzS5/rFMSXk/3dVYwd+0hwo9CBVG99bnoI36AB5xH3s0oqfLsJTf7ZJx5t0HjLFm
         vvQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=nRRlkP+oml8dggbf2pUr8ybyDdg+5UseGbx4VYgZauk=;
        b=NzetYI/kHeACjLR3dz2zfoIjtBZ5ThBVb4c/V0i+H048K2fxw6bDEBD6PO/OYfyQes
         x/JliERTWYDwr7+xxBj93jrp2wD4mLecfDFEEkQiEjYUghO75IcEyoutiXDb5d8nKGcF
         z5MFWD7XOKx0y+rqFzZ3+LNahq7Fys0cjy5JsvTZ7lVBszV7K69yNK82Yi2H87FAf+yn
         2OObCHtn+6sErACD7YGVh/mFh3QEKkpDQHCdfbkevXOaUJedxd+kDynLX6tDjlz28lxb
         xpuZo/9BEV3jq4U9vx4ApXTeYqRkLtIT/4cY80H3TN7BwDhH36P4j6cqCQSC3kCIWwGg
         aGKw==
X-Gm-Message-State: AJIora9m0vuIY7pjLAtaaCFWdrKs65OkHR7ZURTwprJCZ1kLUrqwBIYC
	9BRG+nvoYeWfhcB2JihLzmiaIGu/i5Sexs1HeaPffEDh
X-Google-Smtp-Source: AGRyM1u+1hy3o6J8uFyrBVgmJpQFNKxHmPEn/bb/IhCotZtXkulthwjHAhVr9yl4paVfFtUG5X/B+y0ekfuaV4vVGfg=
X-Received: by 2002:a2e:5743:0:b0:25a:7177:a2ab with SMTP id
 r3-20020a2e5743000000b0025a7177a2abmr2802863ljd.173.1655773036730; Mon, 20
 Jun 2022 17:57:16 -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:  
  
 <49c1dfe9bbe9912282b0f0339a0c077b@lerctr.org>
In-Reply-To: <49c1dfe9bbe9912282b0f0339a0c077b@lerctr.org>
From: Ultima 
Date: Mon, 20 Jun 2022 17:57:05 -0700
Message-ID: 
Subject: Re: MCE: Does this look possibly like a slot issue?
To: Larry Rosenman 
Cc: Freebsd current 
Content-Type: multipart/alternative; boundary="000000000000aedc2c05e1eab3a7"
X-Rspamd-Queue-Id: 4LRp5J0YK8z3DSw
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=n2Vvpnvl;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of ultima1252@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=ultima1252@gmail.com
X-Spamd-Result: default: False [-2.75 / 15.00];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.75)[-0.748];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::230:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000aedc2c05e1eab3a7
Content-Type: text/plain; charset="UTF-8"

Hey Larry,

One red flag I am seeing is that the error is being produced on
the same CPU/bank with each error you have provided so far.
Can you try and follow my original recommendation and swap
currently installed DIMM with the problem DIMM slot and see
if anything changes?

Can you also provide the motherboard model? Also, do you
have multiple CPUs installed in this system?

Best regards,
Richard Gallamore

On Mon, Jun 20, 2022 at 5:41 PM Larry Rosenman  wrote:

> Yes and Yes.
>
>
> On 06/20/2022 7:37 pm, Ultima wrote:
>
> Are you sure that the module you replaced it with was good?
> Are you sure you replaced the correct module?
>
> Best regards,
> Richard Gallamore
>
> On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman  wrote:
>
> I'm seeing them constantly:
>
> root@freenas[~]# mcelog --dmi
> Hardware event. This is not a software error.
> MCE 0
> CPU 22 BANK 8 TSC 20aab486464a
> MISC ac29890200046444 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 44
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 1
> CPU 22 BANK 8 TSC 296dfcc82582
> MISC ac29890200041381 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 2
> CPU 22 BANK 8 TSC 2a5604a6a070
> MISC ac29890200044281
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory ECC error occurred during scrub
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 88000040000200cf MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> Hardware event. This is not a software error.
> MCE 3
> CPU 22 BANK 8 TSC 31e141418eb8
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 4
> CPU 22 BANK 8 TSC 3a014afee106
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 5
> CPU 22 BANK 8 TSC 41d1dbef1a6a
> MISC ac29890200046141 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 41
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 6
> CPU 22 BANK 8 TSC 4a1b1ecef446
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 7
> CPU 22 BANK 8 TSC 527bc27db776
> MISC ac29890200040386 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 86
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> root@freenas[~]# <#m_3316908189451833722_NOP>
>
>
> and I replaced the DIMM yesterday :(
>
>
>
> On 06/20/2022 7:19 pm, Ultima wrote:
>
> Hey Larry,
>
>  It is possible it's the motherboard itself, but it's rare. The way I
> would determine this is to swap the DIMM module with another
> populated slot on the motherboard and see if the error migrated
> to the new slot or not. Also, this error doesn't necessarily mean
> there is a problem that needs to be addressed. If you have been
> running the system for many months and you see ECC errors a
> handful of times, it can probably be safely ignored.
>
> Best regards,
> Richard Gallamore
>
> On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman  wrote:
>
> I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this
> DIMM a couple of times, and still the MCE's continue.
> Is it possible it's Motherboard slot issue?
>
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655762472 Mon Jun 20 17:01:12 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
>
>
>
> --
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>
>
> --
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>
>
> --
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>

--000000000000aedc2c05e1eab3a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey Larry,

One red flag I am=
 seeing is that the error is being produced on
the same CPU/bank =
with each error you have provided so far.
Can you try =
and follow my original recommendation and swap
currently installe=
d DIMM with the problem DIMM slot and see
if anything changes?

Can you also provide the motherboard model? Also=
, do you
have multiple CPUs installed in this system?

Best regards,
Richard Gallamore
<=
div>

On Mon, Jun 20, 2022 at 5:41 PM Larry Rosenman <ler@lerctr.org> wrote:


Yes and Yes.





On 06/20/2022 7:37 pm, Ult=
ima wrote:








Are you sure that the module you replaced it with was good?


Are you sure you replaced the correct module?


=C2=A0


Best regards,


Richard Gallamore








On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman <ler@lerctr.=
org> wrote:






I'm seeing them constantly:


root@freenas[~]# mcelog --dmi
Hardware event. This is not a software =
error.
MCE 0
CPU 22 BANK 8 TSC 20aab486464a
MISC ac29890200046444 =
ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1Memory transaction Tracker ID (RTId): 44
Memory DIMM ID of error: 0Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8=
c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Ve=
ndor Intel Family 6 Model 44 Step 2
WARNING: SMBIOS data is often unreli=
able. Take with a grain of salt!
DDR3 DIMM 800 Mhz Other Width 72 Data W=
idth 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
M=
anufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Numbe=
r: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
MCE=
 1
CPU 22 BANK 8 TSC 296dfcc82582
MISC ac29890200041381 ADDR ee2f6e80=
0
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read=
 ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory tran=
saction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory chann=
el ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c000040000100=
9f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Fa=
mily 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Si=
ze 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacture=
r: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R=
7BFR4C-H9
Hardware event. This is not a software error.
MCE 2
CPU =
22 BANK 8 TSC 2a5604a6a070
MISC ac29890200044281
TIME 1655770989 Mon =
Jun 20 19:23:09 2022
MCG status:
Memory ECC error occurred during scr=
ub
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction =
Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of=
 error: 1
Memory ECC syndrome: ac298902
STATUS 88000040000200cf MCGST=
ATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 M=
odel 44 Step 2
Hardware event. This is not a software error.
MCE 3CPU 22 BANK 8 TSC 31e141418eb8
MISC ac29890200046a4a ADDR ee2f6e800
=
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC =
error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transacti=
on Tracker ID (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID=
 of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MC=
GSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family =
6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 =
GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hy=
undai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4=
C-H9
Hardware event. This is not a software error.
MCE 4
CPU 22 BA=
NK 8 TSC 3a014afee106
MISC ac29890200046646 ADDR ee2f6e800
TIME 16557=
70989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
M=
emory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker=
 ID (RTId): 46
Memory DIMM ID of error: 0
Memory channel ID of error:=
 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0<=
br>MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44=
 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Devi=
ce Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
S=
erial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Ha=
rdware event. This is not a software error.
MCE 5
CPU 22 BANK 8 TSC 4=
1d1dbef1a6a
MISC ac29890200046141 ADDR ee2f6e800
TIME 1655770989 Mon =
Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corr=
ected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId)=
: 41
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memo=
ry ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP =
1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator=
: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Numb=
er: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware eve=
nt. This is not a software error.
MCE 6
CPU 22 BANK 8 TSC 4a1b1ecef44=
6
MISC ac29890200046a4a ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:=
23:09 2022
MCG status:
Memory read ECC error
Memory corrected erro=
r count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 4a
Me=
mory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syn=
drome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICI=
D 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM=
 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2=
C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C2=
0F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This i=
s not a software error.
MCE 7
CPU 22 BANK 8 TSC 527bc27db776
MISC =
ac29890200040386 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022=

MCG status:
Memory read ECC error
Memory corrected error count (C=
ORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 86
Memory DIMM =
ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac2=
98902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKE=
TID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz O=
ther Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank =
Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asse=
t Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is not a so=
ftware error.
MCE 8
CPU 22 BANK 8 TSC 5aa4ecdd795a
MISC ac29890200=
046646 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG st=
atus:
Memory read ECC error
Memory corrected error count (CORE_ERR_CN=
T): 1
Memory transaction Tracker ID (RTId): 46
Memory DIMM ID of erro=
r: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
S=
TATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
C=
PUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width=
 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: B=
ANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
=
Part Number: HMT151R7BFR4C-H9
roo=
t@freenas[~]#





and I replaced the DIMM yesterday :(=C2=A0








On 06/20/2022 7:19 pm, Ultima wrote:








Hey Larry,


=C2=A0


=C2=A0It is possible it's the motherboard itself, but it's rar=
e. The way I


would determine this is to swap the DIMM module with another


populated slot on the motherboard and see if the error migrated


to the new slot or not. Also, this error doesn't necessarily mean<=
/div>

there is a problem that needs to be addressed. If you have been


running the system for many months and you see ECC errors a


handful of times, it can probably be safely ignored.


=C2=A0


Best regards,


Richard Gallamore








On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman <ler@lerctr.=
org> wrote:


I've gotten a BUNCH of these on my TrueNAS =
server.=C2=A0 I've replaced this 
DIMM a couple of times, and still =
the MCE's continue.
Is it possible it's Motherboard slot issue?<=
br>
Hardware event. This is not a software error.
MCE 8
CPU 22 BAN=
K 8 TSC 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6e800
TIME 165576=
2472 Mon Jun 20 17:01:12 2022
MCG status:
Memory read ECC error
Me=
mory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker =
ID (RTId): 46
Memory DIMM ID of error: 0
Memory channel ID of error: =
1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 =
Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Devic=
e Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Se=
rial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9


-- 
Larry Rosenman=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.lerctr.org/~lerPhone: +1 214-642-9640=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock,=
 TX 78665-2106














--=C2=A0<=
br>Larry Rosenman =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht=
tp://www.lerctr.org/~ler
Phone: +1 214-642-9640 =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-=
2106



















--=C2=A0<=
br>Larry Rosenman =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht=
tp://www.lerctr.org/~ler
Phone: +1 214-642-9640 =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0E-Mail: ler@lerctr.o=
rg
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106








--000000000000aedc2c05e1eab3a7--

From nobody Tue Jun 21 00:59:52 2022
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 A82DF872301
	for ; Tue, 21 Jun 2022 00:59:53 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LRp8907Z2z3Fgr
	for ; Tue, 21 Jun 2022 00:59:53 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=BB0xokFxo5StlDFhx7z3gZKwB7es1bhXWGiwn1vpNAU=; b=SQauofRAC4W3ldnwXEx9eO0YfJ
	cAqEeRS7P7jxgAwz6fu2/79G/Unchw+I57Gv8PghFplATeeNyXb5ue+HBiHiMtGfij3P3tPqNBF5l
	GnT2koCpEoncfzQK4/toLovxnWKRkgtfVIen7b73WYmKjLITIFKtJWOM+Xt1eGEC1oFkKHM41uhHU
	tVtNHU4pRqeorGKEsGzOwnEYY34Emy5LDDBT4C8Qt+S0xMUAHajHRW8xQVzxOBiQAX0fOa/EYrum0
	C0AGhF5GSXOpdpTqZqMmOM4+0nYaL+UPSIionbfr4BNkJv8XYnFvXuYqrhic1V69/7+8hzd6EsxW/
	8epgYObw==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:52523 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o3SFE-000OHb-9T;
	Mon, 20 Jun 2022 19:59:52 -0500
Received: from 2600:1700:210:b18f:7139:7834:f65d:718c
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Mon, 20 Jun 2022 19:59:52 -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
Date: Mon, 20 Jun 2022 19:59:52 -0500
From: Larry Rosenman 
To: Ultima 
Cc: Freebsd current 
Subject: Re: MCE: Does this look possibly like a slot issue?
In-Reply-To: 
References: 
 
 
 
 <49c1dfe9bbe9912282b0f0339a0c077b@lerctr.org>
 
Message-ID: <983660c80cc6717e3b49821f7957ee80@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: multipart/alternative;
 boundary="=_2a5f4419d9ada4d3f970c5ed9bd02eac"
X-Rspamd-Queue-Id: 4LRp8907Z2z3Fgr
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=SQauofRA;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-1.07 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 NEURAL_SPAM_SHORT(0.93)[0.932];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=_2a5f4419d9ada4d3f970c5ed9bd02eac
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



SuperMicro X8DTN+

2 Processors, 6-core/12-Thread. CPU: Intel(R) Xeon(R) CPU           
E5645  @ 2.40GHz (2400.20-MHz K8-class CPU)

I'll bring it down and swap DIMMS around

On 06/20/2022 7:57 pm, Ultima wrote:

> Hey Larry,
> 
> One red flag I am seeing is that the error is being produced on
> the same CPU/bank with each error you have provided so far.
> 
> Can you try and follow my original recommendation and swap
> currently installed DIMM with the problem DIMM slot and see
> if anything changes?
> 
> Can you also provide the motherboard model? Also, do you
> have multiple CPUs installed in this system?
> 
> Best regards,
> Richard Gallamore
> 
> On Mon, Jun 20, 2022 at 5:41 PM Larry Rosenman  wrote:
> 
> Yes and Yes.
> 
> On 06/20/2022 7:37 pm, Ultima wrote:
> 
> Are you sure that the module you replaced it with was good?
> Are you sure you replaced the correct module?
> 
> Best regards,
> Richard Gallamore
> 
> On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman  wrote:
> 
> I'm seeing them constantly:
> 
> root@freenas[~]# mcelog --dmi
> Hardware event. This is not a software error.
> MCE 0
> CPU 22 BANK 8 TSC 20aab486464a
> MISC ac29890200046444 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 44
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 1
> CPU 22 BANK 8 TSC 296dfcc82582
> MISC ac29890200041381 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 2
> CPU 22 BANK 8 TSC 2a5604a6a070
> MISC ac29890200044281
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory ECC error occurred during scrub
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 88000040000200cf MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> Hardware event. This is not a software error.
> MCE 3
> CPU 22 BANK 8 TSC 31e141418eb8
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 4
> CPU 22 BANK 8 TSC 3a014afee106
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 5
> CPU 22 BANK 8 TSC 41d1dbef1a6a
> MISC ac29890200046141 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 41
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 6
> CPU 22 BANK 8 TSC 4a1b1ecef446
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 7
> CPU 22 BANK 8 TSC 527bc27db776
> MISC ac29890200040386 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 86
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> root@freenas[~]#
> 
> and I replaced the DIMM yesterday :(
> 
> On 06/20/2022 7:19 pm, Ultima wrote:
> 
> Hey Larry,
> 
> It is possible it's the motherboard itself, but it's rare. The way I
> would determine this is to swap the DIMM module with another
> populated slot on the motherboard and see if the error migrated
> to the new slot or not. Also, this error doesn't necessarily mean
> there is a problem that needs to be addressed. If you have been
> running the system for many months and you see ECC errors a
> handful of times, it can probably be safely ignored.
> 
> Best regards,
> Richard Gallamore
> 
> On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman  wrote: 
> I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this
> DIMM a couple of times, and still the MCE's continue.
> Is it possible it's Motherboard slot issue?
> 
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655762472 Mon Jun 20 17:01:12 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> 
> --
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_2a5f4419d9ada4d3f970c5ed9bd02eac
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



SuperMicro X8DTN+


2 Processors, 6-core/12-Thread. CPU: Intel(R) Xeon(R) CPU     =
      E5645  @ 2.40GHz (2400.20-MHz K8-class CPU)





I'll bring it down and swap DIMMS around





On 06/20/2022 7:57 pm, Ultima wrote:








Hey Larry,


 


One red flag I am seeing is that the error is being produced on


the same CPU/bank with each error you have provided so far.


 


Can you try and follow my original recommendation and swap


currently installed DIMM with the problem DIMM slot and see


if anything changes?


 


Can you also provide the motherboard model? Also, do you


have multiple CPUs installed in this system?


 


Best regards,


Richard Gallamore




 










On Mon, Jun 20, 2022 at 5:41 PM Lar=
ry Rosenman <ler@le=
rctr.org> wrote:






Yes and Yes.





On 06/20/2022 7:37 pm, U=
ltima wrote:








Are you sure that the module you replaced it with was good?


Are you sure you replaced the correct module?


 


Best regards,


Richard Gallamore








On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman <ler@lerctr.org> wrote:=







I'm seeing them constantly:


root@freenas[~]# mcelog --dmi
Hardware event. This is not a softwar=
e error.
MCE 0
CPU 22 BANK 8 TSC 20aab486464a
MISC ac2989020=
0046444 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
M=
CG status:
Memory read ECC error
Memory corrected error count (CO=
RE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 44
Memory DI=
MM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndro=
me: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APIC=
ID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
WARN=
ING: SMBIOS data is often unreliable. Take with a grain of salt!
DDR3 =
DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2=
-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Nu=
mber: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hard=
ware event. This is not a software error.
MCE 1
CPU 22 BANK 8 TSC=
 296dfcc82582
MISC ac29890200041381 ADDR ee2f6e800
TIME 165577098=
9 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tra=
cker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID o=
f error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f =
MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel F=
amily 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64=
 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Ma=
nufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part =
Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.=

MCE 2
CPU 22 BANK 8 TSC 2a5604a6a070
MISC ac29890200044281<=
br />TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory =
ECC error occurred during scrub
Memory corrected error count (CORE_ERR=
_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID =
of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac=
298902
STATUS 88000040000200cf MCGSTATUS 0
MCGCAP 1c09 APICID 34 =
SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware e=
vent. This is not a software error.
MCE 3
CPU 22 BANK 8 TSC 31e14=
1418eb8
MISC ac29890200046a4a ADDR ee2f6e800
TIME 1655770989 Mon =
Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memor=
y corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker I=
D (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of erro=
r: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTA=
TUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family =
6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size =
4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufact=
urer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number=
: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
=
MCE 4
CPU 22 BANK 8 TSC 3a014afee106
MISC ac29890200046646 ADDR e=
e2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1=

Memory transaction Tracker ID (RTId): 46
Memory DIMM ID of error=
: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID=
 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz =
Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
=
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20=
F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. T=
his is not a software error.
MCE 5
CPU 22 BANK 8 TSC 41d1dbef1a6a=

MISC ac29890200046141 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 =
19:23:09 2022
MCG status:
Memory read ECC error
Memory corre=
cted error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId=
): 41
Memory DIMM ID of error: 0
Memory channel ID of error: 1Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model=
 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GBDevice Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: H=
yundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT15=
1R7BFR4C-H9
Hardware event. This is not a software error.
MCE 6CPU 22 BANK 8 TSC 4a1b1ecef446
MISC ac29890200046a4a ADDR ee2f6e80=
0
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memor=
y read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
M=
emory transaction Tracker ID (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STA=
TUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other W=
idth 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Lo=
cator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
=
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is =
not a software error.
MCE 7
CPU 22 BANK 8 TSC 527bc27db776
M=
ISC ac29890200040386 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:0=
9 2022
MCG status:
Memory read ECC error
Memory corrected er=
ror count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 86Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memo=
ry ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCG=
CAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Ste=
p 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Devi=
ce Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai<=
br />Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4=
C-H9
Hardware event. This is not a software error.
MCE 8
CPU=
 22 BANK 8 TSC 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6e800
=
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read =
ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory t=
ransaction Tracker ID (RTId): 46
Memory DIMM ID of error: 0
Memor=
y channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0=
000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID =
Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72=
 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: =
BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset T=
ag:
Part Number: HMT151R7BFR4C-H9
root@freenas[~]#





and I replaced the DIMM yesterday :( 








On 06/20/2022 7:19 pm, Ultima wrote:








Hey Larry,


 


 It is possible it's the motherboard itself, but it's rare. The w=
ay I


would determine this is to swap the DIMM module with another


populated slot on the motherboard and see if the error migrated


to the new slot or not. Also, this error doesn't necessarily mean


there is a problem that needs to be addressed. If you have been


running the system for many months and you see ECC errors a


handful of times, it can probably be safely ignored.


 


Best regards,


Richard Gallamore








On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman <ler@lerctr.org> wrote:=



I've gotten a BUNCH of these on my TrueNAS server.=
  I've replaced this 
DIMM a couple of times, and still the MCE's=
 continue.
Is it possible it's Motherboard slot issue?

Hard=
ware event. This is not a software error.
MCE 8
CPU 22 BANK 8 TSC=
 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6e800
TIME 165576247=
2 Mon Jun 20 17:01:12 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tra=
cker ID (RTId): 46
Memory DIMM ID of error: 0
Memory channel ID o=
f error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f =
MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel F=
amily 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64=
 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Ma=
nufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part =
Number: HMT151R7BFR4C-H9



-- 
Larry Rosenman&nbs=
p;                    http://www.lerctr.org/~ler
Phone: +1 214-642-9640  &nb=
sp;              E-Mail: ler@lerctr.org
US Mail: 5708=
 Sabbia Dr, Round Rock, TX 78665-2106














--&=
nbsp;
Larry Rosenman         &=
nbsp;           http://www.lerctr.org/~ler
Phone: +1 214-642-9640  &nbs=
p;            &=
nbsp; E-Mail: ler=
@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106



















--&=
nbsp;
Larry Rosenman         &=
nbsp;           http://www.lerctr.org/~ler
Phone: +1 214-642-9640  &nbs=
p;            &=
nbsp; E-Mail: ler=
@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106



















=
-- 
Larry Rosenman     &n=
bsp;            =
;   http://www.lerctr.org/~ler
Phone: +1 =
214-642-9640           &n=
bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=






--=_2a5f4419d9ada4d3f970c5ed9bd02eac--

From nobody Tue Jun 21 01:10:45 2022
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 5A1DC874157
	for ; Tue, 21 Jun 2022 01:10:48 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LRpNk5njvz3J5Y
	for ; Tue, 21 Jun 2022 01:10:46 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=TlYmZlLAE0Zu1ctw2w46zAzf9jK6AgZP6RKEDQQNsHA=; b=PACdehH408wZiYhvbi4m8G13Bl
	dl89MgLfW4YG2d/cnmjxieX8uslWWTvJkg0ZgrsUgqp9qEQdeeLJc4Fm9gnQ3ICVTtwKI+7hEnjt4
	lEJaKwiZzi0ClzIikbrz/s1adss6VmNTD2LjY+nSExJ82CG1W300itWbT57PaQUj0rr9QF67kCR8c
	IgSgpOMtozxCs2F7S8rCuhqV3IQYf4VgtbR8JqzXWe8qyF+Zyv95hZWXjpM1dDOnrLqfw444Sh3kq
	ux7iWqDiiulDQHrgEEAneawWkmO99zk3Rjx3ePYk2KE0H+2x1Js5v37AJxoVZze6W7hmXCOPEwQ7f
	zo/QiHFA==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:39487 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o3SPm-000ORt-3c;
	Mon, 20 Jun 2022 20:10:46 -0500
Received: from 2600:1700:210:b18f:7139:7834:f65d:718c
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Mon, 20 Jun 2022 20:10:45 -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
Date: Mon, 20 Jun 2022 20:10:45 -0500
From: Larry Rosenman 
To: Ultima 
Cc: Freebsd current 
Subject: Re: MCE: Does this look possibly like a slot issue?
In-Reply-To: <983660c80cc6717e3b49821f7957ee80@lerctr.org>
References: 
 
 
 
 <49c1dfe9bbe9912282b0f0339a0c077b@lerctr.org>
 
 <983660c80cc6717e3b49821f7957ee80@lerctr.org>
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: multipart/alternative;
 boundary="=_04265f17d8a0c218bffa27b90958ead8"
X-Rspamd-Queue-Id: 4LRpNk5njvz3J5Y
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=PACdehH4;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-2.91 / 15.00];
	 ARC_NA(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx:c];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-0.91)[-0.914];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=_04265f17d8a0c218bffa27b90958ead8
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



Swapped 2 DIMMS, now we wait for the ZFS ARC to fill and start using all 
the memory.

On 06/20/2022 7:59 pm, Larry Rosenman wrote:

> SuperMicro X8DTN+
> 
> 2 Processors, 6-core/12-Thread. CPU: Intel(R) Xeon(R) CPU           
> E5645  @ 2.40GHz (2400.20-MHz K8-class CPU)
> 
> I'll bring it down and swap DIMMS around
> 
> On 06/20/2022 7:57 pm, Ultima wrote:
> 
> Hey Larry,
> 
> One red flag I am seeing is that the error is being produced on
> the same CPU/bank with each error you have provided so far.
> 
> Can you try and follow my original recommendation and swap
> currently installed DIMM with the problem DIMM slot and see
> if anything changes?
> 
> Can you also provide the motherboard model? Also, do you
> have multiple CPUs installed in this system?
> 
> Best regards,
> Richard Gallamore
> 
> On Mon, Jun 20, 2022 at 5:41 PM Larry Rosenman  wrote:
> 
> Yes and Yes.
> 
> On 06/20/2022 7:37 pm, Ultima wrote:
> 
> Are you sure that the module you replaced it with was good?
> Are you sure you replaced the correct module?
> 
> Best regards,
> Richard Gallamore
> 
> On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman  wrote:
> 
> I'm seeing them constantly:
> 
> root@freenas[~]# mcelog --dmi
> Hardware event. This is not a software error.
> MCE 0
> CPU 22 BANK 8 TSC 20aab486464a
> MISC ac29890200046444 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 44
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 1
> CPU 22 BANK 8 TSC 296dfcc82582
> MISC ac29890200041381 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 2
> CPU 22 BANK 8 TSC 2a5604a6a070
> MISC ac29890200044281
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory ECC error occurred during scrub
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 88000040000200cf MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> Hardware event. This is not a software error.
> MCE 3
> CPU 22 BANK 8 TSC 31e141418eb8
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 4
> CPU 22 BANK 8 TSC 3a014afee106
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 5
> CPU 22 BANK 8 TSC 41d1dbef1a6a
> MISC ac29890200046141 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 41
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 6
> CPU 22 BANK 8 TSC 4a1b1ecef446
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 7
> CPU 22 BANK 8 TSC 527bc27db776
> MISC ac29890200040386 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 86
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> root@freenas[~]#
> 
> and I replaced the DIMM yesterday :(
> 
> On 06/20/2022 7:19 pm, Ultima wrote:
> 
> Hey Larry,
> 
> It is possible it's the motherboard itself, but it's rare. The way I
> would determine this is to swap the DIMM module with another
> populated slot on the motherboard and see if the error migrated
> to the new slot or not. Also, this error doesn't necessarily mean
> there is a problem that needs to be addressed. If you have been
> running the system for many months and you see ECC errors a
> handful of times, it can probably be safely ignored.
> 
> Best regards,
> Richard Gallamore
> 
> On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman  wrote: 
> I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this
> DIMM a couple of times, and still the MCE's continue.
> Is it possible it's Motherboard slot issue?
> 
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655762472 Mon Jun 20 17:01:12 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> 
> --
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_04265f17d8a0c218bffa27b90958ead8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



Swapped 2 DIMMS, now we wait for the ZFS ARC to fill and start using all=
 the memory.








On 06/20/2022 7:59 pm, Larry Rosenman wrote:








SuperMicro X8DTN+


2 Processors, 6-core/12-Thread. CPU: Intel(R) Xeon(R) CPU     =
      E5645  @ 2.40GHz (2400.20-MHz K8-class CPU)





I'll bring it down and swap DIMMS around





On 06/20/2022 7:57 pm, Ultima wrote:








Hey Larry,


 


One red flag I am seeing is that the error is being produced on


the same CPU/bank with each error you have provided so far.


 


Can you try and follow my original recommendation and swap


currently installed DIMM with the problem DIMM slot and see


if anything changes?


 


Can you also provide the motherboard model? Also, do you


have multiple CPUs installed in this system?


 


Best regards,


Richard Gallamore




 










On Mon, Jun 20, 2022 at 5:41 PM L=
arry Rosenman <ler@=
lerctr.org> wrote:






Yes and Yes.





On 06/20/2022 7:37 pm,=
 Ultima wrote:








Are you sure that the module you replaced it with was good?


Are you sure you replaced the correct module?


 


Best regards,


Richard Gallamore








On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman <ler@lerctr.org> wrote:=







I'm seeing them constantly:


root@freenas[~]# mcelog --dmi
Hardware event. This is not a softwar=
e error.
MCE 0
CPU 22 BANK 8 TSC 20aab486464a
MISC ac2989020=
0046444 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
M=
CG status:
Memory read ECC error
Memory corrected error count (CO=
RE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 44
Memory DI=
MM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndro=
me: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APIC=
ID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
WARN=
ING: SMBIOS data is often unreliable. Take with a grain of salt!
DDR3 =
DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2=
-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Nu=
mber: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hard=
ware event. This is not a software error.
MCE 1
CPU 22 BANK 8 TSC=
 296dfcc82582
MISC ac29890200041381 ADDR ee2f6e800
TIME 165577098=
9 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tra=
cker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID o=
f error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f =
MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel F=
amily 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64=
 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Ma=
nufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part =
Number: HMT151R7BFR4C-H9
Hardware event. This is not a software error.=

MCE 2
CPU 22 BANK 8 TSC 2a5604a6a070
MISC ac29890200044281<=
br />TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory =
ECC error occurred during scrub
Memory corrected error count (CORE_ERR=
_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID =
of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac=
298902
STATUS 88000040000200cf MCGSTATUS 0
MCGCAP 1c09 APICID 34 =
SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware e=
vent. This is not a software error.
MCE 3
CPU 22 BANK 8 TSC 31e14=
1418eb8
MISC ac29890200046a4a ADDR ee2f6e800
TIME 1655770989 Mon =
Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memor=
y corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker I=
D (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of erro=
r: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTA=
TUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family =
6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size =
4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufact=
urer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part Number=
: HMT151R7BFR4C-H9
Hardware event. This is not a software error.
=
MCE 4
CPU 22 BANK 8 TSC 3a014afee106
MISC ac29890200046646 ADDR e=
e2f6e800
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1=

Memory transaction Tracker ID (RTId): 46
Memory DIMM ID of error=
: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID=
 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz =
Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
=
Bank Locator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20=
F
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. T=
his is not a software error.
MCE 5
CPU 22 BANK 8 TSC 41d1dbef1a6a=

MISC ac29890200046141 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 =
19:23:09 2022
MCG status:
Memory read ECC error
Memory corre=
cted error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId=
): 41
Memory DIMM ID of error: 0
Memory channel ID of error: 1Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model=
 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GBDevice Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: H=
yundai
Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT15=
1R7BFR4C-H9
Hardware event. This is not a software error.
MCE 6CPU 22 BANK 8 TSC 4a1b1ecef446
MISC ac29890200046a4a ADDR ee2f6e80=
0
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memor=
y read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
M=
emory transaction Tracker ID (RTId): 4a
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STA=
TUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other W=
idth 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Lo=
cator: BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
=
Asset Tag:
Part Number: HMT151R7BFR4C-H9
Hardware event. This is =
not a software error.
MCE 7
CPU 22 BANK 8 TSC 527bc27db776
M=
ISC ac29890200040386 ADDR ee2f6e800
TIME 1655770989 Mon Jun 20 19:23:0=
9 2022
MCG status:
Memory read ECC error
Memory corrected er=
ror count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 86Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memo=
ry ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCG=
CAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Ste=
p 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Devi=
ce Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Hyundai<=
br />Serial Number: 40F3C20F
Asset Tag:
Part Number: HMT151R7BFR4=
C-H9
Hardware event. This is not a software error.
MCE 8
CPU=
 22 BANK 8 TSC 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6e800
=
TIME 1655770989 Mon Jun 20 19:23:09 2022
MCG status:
Memory read =
ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory t=
ransaction Tracker ID (RTId): 46
Memory DIMM ID of error: 0
Memor=
y channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0=
000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID =
Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72=
 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: =
BANK14
Manufacturer: Hyundai
Serial Number: 40F3C20F
Asset T=
ag:
Part Number: HMT151R7BFR4C-H9
root@freenas[~]#





and I replaced the DIMM yesterday :( 








On 06/20/2022 7:19 pm, Ultima wrote:








Hey Larry,


 


 It is possible it's the motherboard itself, but it's rare. The w=
ay I


would determine this is to swap the DIMM module with another


populated slot on the motherboard and see if the error migrated


to the new slot or not. Also, this error doesn't necessarily mean


there is a problem that needs to be addressed. If you have been


running the system for many months and you see ECC errors a


handful of times, it can probably be safely ignored.


 


Best regards,


Richard Gallamore








On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman <ler@lerctr.org> wrote:=



I've gotten a BUNCH of these on my TrueNAS server.=
  I've replaced this 
DIMM a couple of times, and still the MCE's=
 continue.
Is it possible it's Motherboard slot issue?

Hard=
ware event. This is not a software error.
MCE 8
CPU 22 BANK 8 TSC=
 5aa4ecdd795a
MISC ac29890200046646 ADDR ee2f6e800
TIME 165576247=
2 Mon Jun 20 17:01:12 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tra=
cker ID (RTId): 46
Memory DIMM ID of error: 0
Memory channel ID o=
f error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f =
MCGSTATUS 0
MCGCAP 1c09 APICID 34 SOCKETID 0
CPUID Vendor Intel F=
amily 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64=
 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Ma=
nufacturer: Hyundai
Serial Number: 40F3C20F
Asset Tag:
Part =
Number: HMT151R7BFR4C-H9



-- 
Larry Rosenman&nbs=
p;                    http://www.lerctr.org/~ler
Phone: +1 214-642-9640  &nb=
sp;              E-Mail: ler@lerctr.org
US Mail: 5708=
 Sabbia Dr, Round Rock, TX 78665-2106














--&=
nbsp;
Larry Rosenman         &=
nbsp;           http://www.lerctr.org/~ler
Phone: +1 214-642-9640  &nbs=
p;            &=
nbsp; E-Mail: ler=
@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106



















--&=
nbsp;
Larry Rosenman         &=
nbsp;           http://www.lerctr.org/~ler
Phone: +1 214-642-9640  &nbs=
p;            &=
nbsp; E-Mail: ler=
@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106



















-- 
Larry Rosenman    &nb=
sp;            =
    http://www.lerctr.org/~ler
Phone=
: +1 214-642-9640          &nb=
sp;      E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr,=
 Round Rock, TX 78665-2106















=
-- 
Larry Rosenman     &n=
bsp;            =
;   http://www.lerctr.org/~ler
Phone: +1 =
214-642-9640           &n=
bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=






--=_04265f17d8a0c218bffa27b90958ead8--

From nobody Tue Jun 21 16:06:24 2022
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 227B5872020
	for ; Tue, 21 Jun 2022 16:06:35 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSBGK6Jxhz4qXK
	for ; Tue, 21 Jun 2022 16:06:33 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1])
	by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 25LG6OFU053748;
	Tue, 21 Jun 2022 09:06:24 -0700 (PDT)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: (from freebsd-rwg@localhost)
	by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 25LG6Out053747;
	Tue, 21 Jun 2022 09:06:24 -0700 (PDT)
	(envelope-from freebsd-rwg)
From: "Rodney W. Grimes" 
Message-Id: <202206211606.25LG6Out053747@gndrsh.dnsmgr.net>
Subject: Re: MCE: Does this look possibly like a slot issue?
In-Reply-To: 
To: Larry Rosenman 
Date: Tue, 21 Jun 2022 09:06:24 -0700 (PDT)
CC: Ultima ,
        Freebsd current 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Rspamd-Queue-Id: 4LSBGK6Jxhz4qXK
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net
X-Spamd-Result: default: False [1.00 / 15.00];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.977];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 DMARC_NA(0.00)[dnsmgr.net];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 NEURAL_HAM_SHORT(-0.91)[-0.911];
	 NEURAL_SPAM_LONG(0.99)[0.992];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US];
	 FREEMAIL_CC(0.00)[gmail.com,FreeBSD.org];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

> 
> 
> Swapped 2 DIMMS, now we wait for the ZFS ARC to fill and start using all 
> the memory.

Depending on the results of that one thing that is often overlooked
when trying to trouble shoot memory systems in modern Intel systems
is the fact that the DIMM now talks directly to the CPU chip that
has the memory controller built into it.  THUS these "slot" related
ECC/Parity/blowup errors can actually be the CPU and/or the CPU
socket and/or the seating of the CPU in the socket.  

So if the error sticks with the DIMM slot and not the DIMM
module the next thing I would try would be a CPU chip reseat,
including a good inspection of the socket for for a damaged
pin.  Also look at the lands on the CPU chip itself, and you
can even try swaping CPU chips to see if it follows the
CPU or the socket, much as you do with a DIMM.


> 
> On 06/20/2022 7:59 pm, Larry Rosenman wrote:
> 
> > SuperMicro X8DTN+
> > 
> > 2 Processors, 6-core/12-Thread. CPU: Intel(R) Xeon(R) CPU           
> > E5645  @ 2.40GHz (2400.20-MHz K8-class CPU)
> > 
> > I'll bring it down and swap DIMMS around
> > 
> > On 06/20/2022 7:57 pm, Ultima wrote:
> > 
> > Hey Larry,
> > 
> > One red flag I am seeing is that the error is being produced on
> > the same CPU/bank with each error you have provided so far.
> > 
> > Can you try and follow my original recommendation and swap
> > currently installed DIMM with the problem DIMM slot and see
> > if anything changes?
> > 
> > Can you also provide the motherboard model? Also, do you
> > have multiple CPUs installed in this system?
> > 
> > Best regards,
> > Richard Gallamore
> > 
> > On Mon, Jun 20, 2022 at 5:41 PM Larry Rosenman  wrote:
> > 
> > Yes and Yes.
> > 
> > On 06/20/2022 7:37 pm, Ultima wrote:
> > 
> > Are you sure that the module you replaced it with was good?
> > Are you sure you replaced the correct module?
> > 
> > Best regards,
> > Richard Gallamore
> > 
> > On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman  wrote:
> > 
> > I'm seeing them constantly:
> > 
> > root@freenas[~]# mcelog --dmi
> > Hardware event. This is not a software error.
> > MCE 0
> > CPU 22 BANK 8 TSC 20aab486464a
> > MISC ac29890200046444 ADDR ee2f6e800
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 44
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c0000400001009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > Hardware event. This is not a software error.
> > MCE 1
> > CPU 22 BANK 8 TSC 296dfcc82582
> > MISC ac29890200041381 ADDR ee2f6e800
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 81
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c0000400001009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > Hardware event. This is not a software error.
> > MCE 2
> > CPU 22 BANK 8 TSC 2a5604a6a070
> > MISC ac29890200044281
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory ECC error occurred during scrub
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 81
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 88000040000200cf MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > Hardware event. This is not a software error.
> > MCE 3
> > CPU 22 BANK 8 TSC 31e141418eb8
> > MISC ac29890200046a4a ADDR ee2f6e800
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 4a
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c0000400001009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > Hardware event. This is not a software error.
> > MCE 4
> > CPU 22 BANK 8 TSC 3a014afee106
> > MISC ac29890200046646 ADDR ee2f6e800
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 46
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c0000400001009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > Hardware event. This is not a software error.
> > MCE 5
> > CPU 22 BANK 8 TSC 41d1dbef1a6a
> > MISC ac29890200046141 ADDR ee2f6e800
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 41
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c0000400001009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > Hardware event. This is not a software error.
> > MCE 6
> > CPU 22 BANK 8 TSC 4a1b1ecef446
> > MISC ac29890200046a4a ADDR ee2f6e800
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 4a
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c0000400001009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > Hardware event. This is not a software error.
> > MCE 7
> > CPU 22 BANK 8 TSC 527bc27db776
> > MISC ac29890200040386 ADDR ee2f6e800
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 86
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c0000400001009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > Hardware event. This is not a software error.
> > MCE 8
> > CPU 22 BANK 8 TSC 5aa4ecdd795a
> > MISC ac29890200046646 ADDR ee2f6e800
> > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 46
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c0000400001009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > root@freenas[~]#
> > 
> > and I replaced the DIMM yesterday :(
> > 
> > On 06/20/2022 7:19 pm, Ultima wrote:
> > 
> > Hey Larry,
> > 
> > It is possible it's the motherboard itself, but it's rare. The way I
> > would determine this is to swap the DIMM module with another
> > populated slot on the motherboard and see if the error migrated
> > to the new slot or not. Also, this error doesn't necessarily mean
> > there is a problem that needs to be addressed. If you have been
> > running the system for many months and you see ECC errors a
> > handful of times, it can probably be safely ignored.
> > 
> > Best regards,
> > Richard Gallamore
> > 
> > On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman  wrote: 
> > I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this
> > DIMM a couple of times, and still the MCE's continue.
> > Is it possible it's Motherboard slot issue?
> > 
> > Hardware event. This is not a software error.
> > MCE 8
> > CPU 22 BANK 8 TSC 5aa4ecdd795a
> > MISC ac29890200046646 ADDR ee2f6e800
> > TIME 1655762472 Mon Jun 20 17:01:12 2022
> > MCG status:
> > Memory read ECC error
> > Memory corrected error count (CORE_ERR_CNT): 1
> > Memory transaction Tracker ID (RTId): 46
> > Memory DIMM ID of error: 0
> > Memory channel ID of error: 1
> > Memory ECC syndrome: ac298902
> > STATUS 8c0000400001009f MCGSTATUS 0
> > MCGCAP 1c09 APICID 34 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44 Step 2
> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > Device Locator: P2-DIMM2C
> > Bank Locator: BANK14
> > Manufacturer: Hyundai
> > Serial Number: 40F3C20F
> > Asset Tag:
> > Part Number: HMT151R7BFR4C-H9
> > 
> > --
> > Larry Rosenman                     http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> 
> -- 
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> 
> -- 
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> 
> -- 
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> 
> -- 
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Rod Grimes                                                 rgrimes@freebsd.org

From nobody Tue Jun 21 16:13:28 2022
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 B35EF873B72
	for ; Tue, 21 Jun 2022 16:13:33 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSBQN5rV9z4skg
	for ; Tue, 21 Jun 2022 16:13:32 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=qBnj6O12NaONcK8PTADcHr3+70/M4LRT+vhNhkRaWlk=; b=h9QK2fp1/e3mUFpQNWZRJrlOsP
	IGMqAxkGDrOldtQEL+QIOWErnQ8/dO+e36DCar3T2UeS5muMOCxhYpip+oTWDfY4f+tNny2bcEWGP
	Bv1W97RfXz6y6j7wADBVDVhoC0OcQzXrb3KsCY1P4wpplqIHez1gZLOyKkKk/t8ro52ic8ea87k+Y
	lXV5eKhaD/ZXJ1LHWoKY3eyrCO9jxmJ4RwSTcRfU9g5MWQmnK6rfWhewhgzGmOxO70WtkHTwnlrAy
	lXDfqZX/0+2hN4iEaWOd+adknzTvKDmi7oxXK0SBpm0MuG9hkdrrwIhIb+k4tOg7+D59Z61Sqy+R2
	tH+nE2WQ==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:45605 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o3gVM-000EfP-Vf;
	Tue, 21 Jun 2022 11:13:29 -0500
Received: from 2600:1700:210:b18f:7139:7834:f65d:718c
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Tue, 21 Jun 2022 11:13:28 -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
Date: Tue, 21 Jun 2022 11:13:28 -0500
From: Larry Rosenman 
To: "Rodney W. Grimes" 
Cc: Ultima , Freebsd current
 
Subject: Re: MCE: Does this look possibly like a slot issue?
In-Reply-To: <202206211606.25LG6Out053747@gndrsh.dnsmgr.net>
References: <202206211606.25LG6Out053747@gndrsh.dnsmgr.net>
Message-ID: <56938c90ef717a0d29566f81353c1295@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LSBQN5rV9z4skg
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=h9QK2fp1;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.00 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+mx];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 ARC_NA(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 FREEMAIL_CC(0.00)[gmail.com,freebsd.org];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

Looks like it might be just that, Rodney:
root@freenas[~]# mcelog
Hardware event. This is not a software error.
MCE 0
CPU 14 BANK 8 TSC 525efc019bb6
MISC ac29890200040083 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 83
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 1
CPU 14 BANK 8 TSC 52a513d27f2c
MISC ac29890200041083 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 83
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 2
CPU 14 BANK 8 TSC 53d8cf2ceb4a
MISC ac29890200040582 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 82
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 3
CPU 14 BANK 8 TSC 5e4dae622cb6
MISC ac29890200041181 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 4
CPU 14 BANK 8 TSC 5eea68fdad4e
MISC ac29890200041784 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 84
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 5
CPU 14 BANK 8 TSC 5eea6e0bbce0
MISC ac29890200044000 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 0
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 6
CPU 12 BANK 8 TSC 5f6cbe9ef2bc
MISC ac29890200041181 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 20 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 7
CPU 14 BANK 8 TSC 64ba63c66e52
MISC ac29890200041181 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 8
CPU 14 BANK 8 TSC 659878c17622
MISC ac29890200040282 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 82
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 9
CPU 14 BANK 8 TSC 66b71c1dccf6
MISC ac29890200040183 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 83
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 10
CPU 14 BANK 8 TSC 6be0988610ce
MISC ac29890200040682 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 82
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
Hardware event. This is not a software error.
MCE 11
CPU 14 BANK 8 TSC 6be0995926f8
MISC ac29890200044000 ADDR ee2f6e800
TIME 1655827944 Tue Jun 21 11:12:24 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 0
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
root@freenas[~]# mcelog --dmi
Hardware event. This is not a software error.
MCE 0
CPU 14 BANK 8 TSC 525efc019bb6
MISC ac29890200040083 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 83
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
Hardware event. This is not a software error.
MCE 1
CPU 14 BANK 8 TSC 52a513d27f2c
MISC ac29890200041083 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 83
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
Hardware event. This is not a software error.
MCE 2
CPU 14 BANK 8 TSC 53d8cf2ceb4a
MISC ac29890200040582 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 82
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
Hardware event. This is not a software error.
MCE 3
CPU 14 BANK 8 TSC 5e4dae622cb6
MISC ac29890200041181 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
Hardware event. This is not a software error.
MCE 4
CPU 14 BANK 8 TSC 5eea68fdad4e
MISC ac29890200041784 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 84
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
Hardware event. This is not a software error.
MCE 5
CPU 14 BANK 8 TSC 5eea6e0bbce0
MISC ac29890200044000 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 0
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
Hardware event. This is not a software error.
MCE 6
CPU 12 BANK 8 TSC 5f6cbe9ef2bc
MISC ac29890200041181 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 20 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
Hardware event. This is not a software error.
MCE 7
CPU 14 BANK 8 TSC 64ba63c66e52
MISC ac29890200041181 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 81
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
Hardware event. This is not a software error.
MCE 8
CPU 14 BANK 8 TSC 659878c17622
MISC ac29890200040282 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 82
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
Hardware event. This is not a software error.
MCE 9
CPU 14 BANK 8 TSC 66b71c1dccf6
MISC ac29890200040183 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 83
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
Hardware event. This is not a software error.
MCE 10
CPU 14 BANK 8 TSC 6be0988610ce
MISC ac29890200040682 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 82
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
Hardware event. This is not a software error.
MCE 11
CPU 14 BANK 8 TSC 6be0995926f8
MISC ac29890200044000 ADDR ee2f6e800
TIME 1655827951 Tue Jun 21 11:12:31 2022
MCG status:
Memory read ECC error
Memory corrected error count (CORE_ERR_CNT): 1
Memory transaction Tracker ID (RTId): 0
Memory DIMM ID of error: 0
Memory channel ID of error: 1
Memory ECC syndrome: ac298902
STATUS 8c0000400001009f MCGSTATUS 0
MCGCAP 1c09 APICID 22 SOCKETID 0
CPUID Vendor Intel Family 6 Model 44 Step 2
DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
Device Locator: P2-DIMM2C
Bank Locator: BANK14
Manufacturer: Nanya
Serial Number: 642264CD
Asset Tag:
Part Number: NT4GC72B4NA1NL-BE
root@freenas[~]#

On 06/21/2022 11:06 am, Rodney W. Grimes wrote:
>> 
>> 
>> Swapped 2 DIMMS, now we wait for the ZFS ARC to fill and start using 
>> all
>> the memory.
> 
> Depending on the results of that one thing that is often overlooked
> when trying to trouble shoot memory systems in modern Intel systems
> is the fact that the DIMM now talks directly to the CPU chip that
> has the memory controller built into it.  THUS these "slot" related
> ECC/Parity/blowup errors can actually be the CPU and/or the CPU
> socket and/or the seating of the CPU in the socket.
> 
> So if the error sticks with the DIMM slot and not the DIMM
> module the next thing I would try would be a CPU chip reseat,
> including a good inspection of the socket for for a damaged
> pin.  Also look at the lands on the CPU chip itself, and you
> can even try swaping CPU chips to see if it follows the
> CPU or the socket, much as you do with a DIMM.
> 
> 
>> 
>> On 06/20/2022 7:59 pm, Larry Rosenman wrote:
>> 
>> > SuperMicro X8DTN+
>> >
>> > 2 Processors, 6-core/12-Thread. CPU: Intel(R) Xeon(R) CPU
>> > E5645  @ 2.40GHz (2400.20-MHz K8-class CPU)
>> >
>> > I'll bring it down and swap DIMMS around
>> >
>> > On 06/20/2022 7:57 pm, Ultima wrote:
>> >
>> > Hey Larry,
>> >
>> > One red flag I am seeing is that the error is being produced on
>> > the same CPU/bank with each error you have provided so far.
>> >
>> > Can you try and follow my original recommendation and swap
>> > currently installed DIMM with the problem DIMM slot and see
>> > if anything changes?
>> >
>> > Can you also provide the motherboard model? Also, do you
>> > have multiple CPUs installed in this system?
>> >
>> > Best regards,
>> > Richard Gallamore
>> >
>> > On Mon, Jun 20, 2022 at 5:41 PM Larry Rosenman  wrote:
>> >
>> > Yes and Yes.
>> >
>> > On 06/20/2022 7:37 pm, Ultima wrote:
>> >
>> > Are you sure that the module you replaced it with was good?
>> > Are you sure you replaced the correct module?
>> >
>> > Best regards,
>> > Richard Gallamore
>> >
>> > On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman  wrote:
>> >
>> > I'm seeing them constantly:
>> >
>> > root@freenas[~]# mcelog --dmi
>> > Hardware event. This is not a software error.
>> > MCE 0
>> > CPU 22 BANK 8 TSC 20aab486464a
>> > MISC ac29890200046444 ADDR ee2f6e800
>> > TIME 1655770989 Mon Jun 20 19:23:09 2022
>> > MCG status:
>> > Memory read ECC error
>> > Memory corrected error count (CORE_ERR_CNT): 1
>> > Memory transaction Tracker ID (RTId): 44
>> > Memory DIMM ID of error: 0
>> > Memory channel ID of error: 1
>> > Memory ECC syndrome: ac298902
>> > STATUS 8c0000400001009f MCGSTATUS 0
>> > MCGCAP 1c09 APICID 34 SOCKETID 0
>> > CPUID Vendor Intel Family 6 Model 44 Step 2
>> > WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
>> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
>> > Device Locator: P2-DIMM2C
>> > Bank Locator: BANK14
>> > Manufacturer: Hyundai
>> > Serial Number: 40F3C20F
>> > Asset Tag:
>> > Part Number: HMT151R7BFR4C-H9
>> > Hardware event. This is not a software error.
>> > MCE 1
>> > CPU 22 BANK 8 TSC 296dfcc82582
>> > MISC ac29890200041381 ADDR ee2f6e800
>> > TIME 1655770989 Mon Jun 20 19:23:09 2022
>> > MCG status:
>> > Memory read ECC error
>> > Memory corrected error count (CORE_ERR_CNT): 1
>> > Memory transaction Tracker ID (RTId): 81
>> > Memory DIMM ID of error: 0
>> > Memory channel ID of error: 1
>> > Memory ECC syndrome: ac298902
>> > STATUS 8c0000400001009f MCGSTATUS 0
>> > MCGCAP 1c09 APICID 34 SOCKETID 0
>> > CPUID Vendor Intel Family 6 Model 44 Step 2
>> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
>> > Device Locator: P2-DIMM2C
>> > Bank Locator: BANK14
>> > Manufacturer: Hyundai
>> > Serial Number: 40F3C20F
>> > Asset Tag:
>> > Part Number: HMT151R7BFR4C-H9
>> > Hardware event. This is not a software error.
>> > MCE 2
>> > CPU 22 BANK 8 TSC 2a5604a6a070
>> > MISC ac29890200044281
>> > TIME 1655770989 Mon Jun 20 19:23:09 2022
>> > MCG status:
>> > Memory ECC error occurred during scrub
>> > Memory corrected error count (CORE_ERR_CNT): 1
>> > Memory transaction Tracker ID (RTId): 81
>> > Memory DIMM ID of error: 0
>> > Memory channel ID of error: 1
>> > Memory ECC syndrome: ac298902
>> > STATUS 88000040000200cf MCGSTATUS 0
>> > MCGCAP 1c09 APICID 34 SOCKETID 0
>> > CPUID Vendor Intel Family 6 Model 44 Step 2
>> > Hardware event. This is not a software error.
>> > MCE 3
>> > CPU 22 BANK 8 TSC 31e141418eb8
>> > MISC ac29890200046a4a ADDR ee2f6e800
>> > TIME 1655770989 Mon Jun 20 19:23:09 2022
>> > MCG status:
>> > Memory read ECC error
>> > Memory corrected error count (CORE_ERR_CNT): 1
>> > Memory transaction Tracker ID (RTId): 4a
>> > Memory DIMM ID of error: 0
>> > Memory channel ID of error: 1
>> > Memory ECC syndrome: ac298902
>> > STATUS 8c0000400001009f MCGSTATUS 0
>> > MCGCAP 1c09 APICID 34 SOCKETID 0
>> > CPUID Vendor Intel Family 6 Model 44 Step 2
>> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
>> > Device Locator: P2-DIMM2C
>> > Bank Locator: BANK14
>> > Manufacturer: Hyundai
>> > Serial Number: 40F3C20F
>> > Asset Tag:
>> > Part Number: HMT151R7BFR4C-H9
>> > Hardware event. This is not a software error.
>> > MCE 4
>> > CPU 22 BANK 8 TSC 3a014afee106
>> > MISC ac29890200046646 ADDR ee2f6e800
>> > TIME 1655770989 Mon Jun 20 19:23:09 2022
>> > MCG status:
>> > Memory read ECC error
>> > Memory corrected error count (CORE_ERR_CNT): 1
>> > Memory transaction Tracker ID (RTId): 46
>> > Memory DIMM ID of error: 0
>> > Memory channel ID of error: 1
>> > Memory ECC syndrome: ac298902
>> > STATUS 8c0000400001009f MCGSTATUS 0
>> > MCGCAP 1c09 APICID 34 SOCKETID 0
>> > CPUID Vendor Intel Family 6 Model 44 Step 2
>> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
>> > Device Locator: P2-DIMM2C
>> > Bank Locator: BANK14
>> > Manufacturer: Hyundai
>> > Serial Number: 40F3C20F
>> > Asset Tag:
>> > Part Number: HMT151R7BFR4C-H9
>> > Hardware event. This is not a software error.
>> > MCE 5
>> > CPU 22 BANK 8 TSC 41d1dbef1a6a
>> > MISC ac29890200046141 ADDR ee2f6e800
>> > TIME 1655770989 Mon Jun 20 19:23:09 2022
>> > MCG status:
>> > Memory read ECC error
>> > Memory corrected error count (CORE_ERR_CNT): 1
>> > Memory transaction Tracker ID (RTId): 41
>> > Memory DIMM ID of error: 0
>> > Memory channel ID of error: 1
>> > Memory ECC syndrome: ac298902
>> > STATUS 8c0000400001009f MCGSTATUS 0
>> > MCGCAP 1c09 APICID 34 SOCKETID 0
>> > CPUID Vendor Intel Family 6 Model 44 Step 2
>> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
>> > Device Locator: P2-DIMM2C
>> > Bank Locator: BANK14
>> > Manufacturer: Hyundai
>> > Serial Number: 40F3C20F
>> > Asset Tag:
>> > Part Number: HMT151R7BFR4C-H9
>> > Hardware event. This is not a software error.
>> > MCE 6
>> > CPU 22 BANK 8 TSC 4a1b1ecef446
>> > MISC ac29890200046a4a ADDR ee2f6e800
>> > TIME 1655770989 Mon Jun 20 19:23:09 2022
>> > MCG status:
>> > Memory read ECC error
>> > Memory corrected error count (CORE_ERR_CNT): 1
>> > Memory transaction Tracker ID (RTId): 4a
>> > Memory DIMM ID of error: 0
>> > Memory channel ID of error: 1
>> > Memory ECC syndrome: ac298902
>> > STATUS 8c0000400001009f MCGSTATUS 0
>> > MCGCAP 1c09 APICID 34 SOCKETID 0
>> > CPUID Vendor Intel Family 6 Model 44 Step 2
>> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
>> > Device Locator: P2-DIMM2C
>> > Bank Locator: BANK14
>> > Manufacturer: Hyundai
>> > Serial Number: 40F3C20F
>> > Asset Tag:
>> > Part Number: HMT151R7BFR4C-H9
>> > Hardware event. This is not a software error.
>> > MCE 7
>> > CPU 22 BANK 8 TSC 527bc27db776
>> > MISC ac29890200040386 ADDR ee2f6e800
>> > TIME 1655770989 Mon Jun 20 19:23:09 2022
>> > MCG status:
>> > Memory read ECC error
>> > Memory corrected error count (CORE_ERR_CNT): 1
>> > Memory transaction Tracker ID (RTId): 86
>> > Memory DIMM ID of error: 0
>> > Memory channel ID of error: 1
>> > Memory ECC syndrome: ac298902
>> > STATUS 8c0000400001009f MCGSTATUS 0
>> > MCGCAP 1c09 APICID 34 SOCKETID 0
>> > CPUID Vendor Intel Family 6 Model 44 Step 2
>> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
>> > Device Locator: P2-DIMM2C
>> > Bank Locator: BANK14
>> > Manufacturer: Hyundai
>> > Serial Number: 40F3C20F
>> > Asset Tag:
>> > Part Number: HMT151R7BFR4C-H9
>> > Hardware event. This is not a software error.
>> > MCE 8
>> > CPU 22 BANK 8 TSC 5aa4ecdd795a
>> > MISC ac29890200046646 ADDR ee2f6e800
>> > TIME 1655770989 Mon Jun 20 19:23:09 2022
>> > MCG status:
>> > Memory read ECC error
>> > Memory corrected error count (CORE_ERR_CNT): 1
>> > Memory transaction Tracker ID (RTId): 46
>> > Memory DIMM ID of error: 0
>> > Memory channel ID of error: 1
>> > Memory ECC syndrome: ac298902
>> > STATUS 8c0000400001009f MCGSTATUS 0
>> > MCGCAP 1c09 APICID 34 SOCKETID 0
>> > CPUID Vendor Intel Family 6 Model 44 Step 2
>> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
>> > Device Locator: P2-DIMM2C
>> > Bank Locator: BANK14
>> > Manufacturer: Hyundai
>> > Serial Number: 40F3C20F
>> > Asset Tag:
>> > Part Number: HMT151R7BFR4C-H9
>> > root@freenas[~]#
>> >
>> > and I replaced the DIMM yesterday :(
>> >
>> > On 06/20/2022 7:19 pm, Ultima wrote:
>> >
>> > Hey Larry,
>> >
>> > It is possible it's the motherboard itself, but it's rare. The way I
>> > would determine this is to swap the DIMM module with another
>> > populated slot on the motherboard and see if the error migrated
>> > to the new slot or not. Also, this error doesn't necessarily mean
>> > there is a problem that needs to be addressed. If you have been
>> > running the system for many months and you see ECC errors a
>> > handful of times, it can probably be safely ignored.
>> >
>> > Best regards,
>> > Richard Gallamore
>> >
>> > On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman  wrote:
>> > I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this
>> > DIMM a couple of times, and still the MCE's continue.
>> > Is it possible it's Motherboard slot issue?
>> >
>> > Hardware event. This is not a software error.
>> > MCE 8
>> > CPU 22 BANK 8 TSC 5aa4ecdd795a
>> > MISC ac29890200046646 ADDR ee2f6e800
>> > TIME 1655762472 Mon Jun 20 17:01:12 2022
>> > MCG status:
>> > Memory read ECC error
>> > Memory corrected error count (CORE_ERR_CNT): 1
>> > Memory transaction Tracker ID (RTId): 46
>> > Memory DIMM ID of error: 0
>> > Memory channel ID of error: 1
>> > Memory ECC syndrome: ac298902
>> > STATUS 8c0000400001009f MCGSTATUS 0
>> > MCGCAP 1c09 APICID 34 SOCKETID 0
>> > CPUID Vendor Intel Family 6 Model 44 Step 2
>> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
>> > Device Locator: P2-DIMM2C
>> > Bank Locator: BANK14
>> > Manufacturer: Hyundai
>> > Serial Number: 40F3C20F
>> > Asset Tag:
>> > Part Number: HMT151R7BFR4C-H9
>> >
>> > --
>> > Larry Rosenman                     http://www.lerctr.org/~ler
>> > Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
>> > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>> 
>> --
>> Larry Rosenman                     http://www.lerctr.org/~ler
>> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
>> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>> 
>> --
>> Larry Rosenman                     http://www.lerctr.org/~ler
>> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
>> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>> 
>> --
>> Larry Rosenman                     http://www.lerctr.org/~ler
>> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
>> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>> 
>> --
>> Larry Rosenman                     http://www.lerctr.org/~ler
>> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
>> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Tue Jun 21 16:52:50 2022
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 9C31287EFE8
	for ; Tue, 21 Jun 2022 16:53:03 +0000 (UTC)
	(envelope-from ultima1252@gmail.com)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSCHz0891z3h3T
	for ; Tue, 21 Jun 2022 16:53:03 +0000 (UTC)
	(envelope-from ultima1252@gmail.com)
Received: by mail-lf1-x12e.google.com with SMTP id i18so9741884lfu.8
        for ; Tue, 21 Jun 2022 09:53:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=LQ31fJFN2OW+QsAz5Pwhe0Q40AuTBfCBMJH8ED6QozY=;
        b=VNqkYIpDfOzEbZ5SMw2OvVti92XWrpv+XfMGqM8E3Jxmd80aNWWPzg4/+0WtqV+aFn
         pkyAzMRliQNZGM5SQ2E1xPOdH0MDmDUQ44N1jRz7YSPquXIxNtpS3SbZ2wyDrNoGZFGU
         TD1uvhYOONrfAzwQIjEAbVJb2ZWetFCydFFVnDCIxKkA0xjtpmdUli5xx9voIcLFfnZL
         6RSUTxTGWLV1MmASEl2As592Jn0ndEgXEASM1KpXh5+xEaqXcSOMRpQ5lbPM/lr5PUVs
         YStrLKAvl+IlHmGZcYUBDGpqIWzMjUypu48YD4wBADvxDRHo+nRVmF6KWqAf7m7H1kSs
         mUCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=LQ31fJFN2OW+QsAz5Pwhe0Q40AuTBfCBMJH8ED6QozY=;
        b=zeWwXVAHZNfGTq9/nUj9TClt5UErttg1GntqVqRrnB8QTz/NCQha8igVQTK297rOxf
         YjZr+yJiA3eRbVKGPooEujJw07+agcNMWG13PheYc5ZEdywQ8BO+Q9Ny+Nc1+naxvDOW
         UOfqAQAdzRzeIAnUk9iSVJC+kvxeHCTvYpJaYU0W92N6RfxVlIcb/+5yyNDfqX5pBhmS
         0j7SeB4lCqu6HA3DuB12QXwVH7XJRXoAvPl1gNAc8Via+rve9zIPk5BcplIVA8paJ7W2
         UeiV4XnHEX7sknf8eaGUlAUo8ohNbciewyMZ9gPreRlSFd5mcqisn0fA2cw8VpdKpymy
         snJQ==
X-Gm-Message-State: AJIora+Bh+28UtAvr/EtAxyDi4ChLfm0uEJ1+5aVwuIwLjtAsMc9eC0H
	RADQBdfZXJXGfomHhnhKPPZWCP/sHoV2cy+68X4oOMgV3QE=
X-Google-Smtp-Source: AGRyM1tiHkHVL6GnGCkXGnHhe1sVftyEkKPVmbiC8pPf/ZT9TlChuMHQajengM1vN3lmN3yQEpazt5LgKrMLISxXLhw=
X-Received: by 2002:a05:6512:3a84:b0:479:209a:578a with SMTP id
 q4-20020a0565123a8400b00479209a578amr16751630lfu.292.1655830381607; Tue, 21
 Jun 2022 09:53: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:  <202206211606.25LG6Out053747@gndrsh.dnsmgr.net>
In-Reply-To: <202206211606.25LG6Out053747@gndrsh.dnsmgr.net>
From: Ultima 
Date: Tue, 21 Jun 2022 09:52:50 -0700
Message-ID: 
Subject: Re: MCE: Does this look possibly like a slot issue?
To: "Rodney W. Grimes" 
Cc: Larry Rosenman , Freebsd current 
Content-Type: multipart/alternative; boundary="000000000000b43f7505e1f80db6"
X-Rspamd-Queue-Id: 4LSCHz0891z3h3T
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=VNqkYIpD;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of ultima1252@gmail.com designates 2a00:1450:4864:20::12e as permitted sender) smtp.mailfrom=ultima1252@gmail.com
X-Spamd-Result: default: False [-0.42 / 15.00];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.40)[-0.401];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 NEURAL_SPAM_SHORT(0.98)[0.983];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12e:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000b43f7505e1f80db6
Content-Type: text/plain; charset="UTF-8"

Completely agree with you, Rodney. The LGA on the motherboard
can be bent very easy when moving so I wanted to recommend this
last.

Larry, as Rodney mentioned, it's more or less your last option. This
is likely the CPU and not the module itself. There is still a small chance
that is motherboard/slot related, a way you can determine this is
by swapping the CPU's slot 0 <----> slot 1 and seeing if the error moves.
As I mentioned though, be very cautious. I don't want you to be in a
worse-off
state.

I would reseat the problem CPU socket before swapping the CPUs.

Best regards,
Richard Gallamore

On Tue, Jun 21, 2022 at 9:06 AM Rodney W. Grimes <
freebsd-rwg@gndrsh.dnsmgr.net> wrote:

> >
> >
> > Swapped 2 DIMMS, now we wait for the ZFS ARC to fill and start using all
> > the memory.
>
> Depending on the results of that one thing that is often overlooked
> when trying to trouble shoot memory systems in modern Intel systems
> is the fact that the DIMM now talks directly to the CPU chip that
> has the memory controller built into it.  THUS these "slot" related
> ECC/Parity/blowup errors can actually be the CPU and/or the CPU
> socket and/or the seating of the CPU in the socket.
>
> So if the error sticks with the DIMM slot and not the DIMM
> module the next thing I would try would be a CPU chip reseat,
> including a good inspection of the socket for for a damaged
> pin.  Also look at the lands on the CPU chip itself, and you
> can even try swaping CPU chips to see if it follows the
> CPU or the socket, much as you do with a DIMM.
>
>
> >
> > On 06/20/2022 7:59 pm, Larry Rosenman wrote:
> >
> > > SuperMicro X8DTN+
> > >
> > > 2 Processors, 6-core/12-Thread. CPU: Intel(R) Xeon(R) CPU
> > > E5645  @ 2.40GHz (2400.20-MHz K8-class CPU)
> > >
> > > I'll bring it down and swap DIMMS around
> > >
> > > On 06/20/2022 7:57 pm, Ultima wrote:
> > >
> > > Hey Larry,
> > >
> > > One red flag I am seeing is that the error is being produced on
> > > the same CPU/bank with each error you have provided so far.
> > >
> > > Can you try and follow my original recommendation and swap
> > > currently installed DIMM with the problem DIMM slot and see
> > > if anything changes?
> > >
> > > Can you also provide the motherboard model? Also, do you
> > > have multiple CPUs installed in this system?
> > >
> > > Best regards,
> > > Richard Gallamore
> > >
> > > On Mon, Jun 20, 2022 at 5:41 PM Larry Rosenman  wrote:
> > >
> > > Yes and Yes.
> > >
> > > On 06/20/2022 7:37 pm, Ultima wrote:
> > >
> > > Are you sure that the module you replaced it with was good?
> > > Are you sure you replaced the correct module?
> > >
> > > Best regards,
> > > Richard Gallamore
> > >
> > > On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman  wrote:
> > >
> > > I'm seeing them constantly:
> > >
> > > root@freenas[~]# mcelog --dmi
> > > Hardware event. This is not a software error.
> > > MCE 0
> > > CPU 22 BANK 8 TSC 20aab486464a
> > > MISC ac29890200046444 ADDR ee2f6e800
> > > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > > MCG status:
> > > Memory read ECC error
> > > Memory corrected error count (CORE_ERR_CNT): 1
> > > Memory transaction Tracker ID (RTId): 44
> > > Memory DIMM ID of error: 0
> > > Memory channel ID of error: 1
> > > Memory ECC syndrome: ac298902
> > > STATUS 8c0000400001009f MCGSTATUS 0
> > > MCGCAP 1c09 APICID 34 SOCKETID 0
> > > CPUID Vendor Intel Family 6 Model 44 Step 2
> > > WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
> > > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > > Device Locator: P2-DIMM2C
> > > Bank Locator: BANK14
> > > Manufacturer: Hyundai
> > > Serial Number: 40F3C20F
> > > Asset Tag:
> > > Part Number: HMT151R7BFR4C-H9
> > > Hardware event. This is not a software error.
> > > MCE 1
> > > CPU 22 BANK 8 TSC 296dfcc82582
> > > MISC ac29890200041381 ADDR ee2f6e800
> > > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > > MCG status:
> > > Memory read ECC error
> > > Memory corrected error count (CORE_ERR_CNT): 1
> > > Memory transaction Tracker ID (RTId): 81
> > > Memory DIMM ID of error: 0
> > > Memory channel ID of error: 1
> > > Memory ECC syndrome: ac298902
> > > STATUS 8c0000400001009f MCGSTATUS 0
> > > MCGCAP 1c09 APICID 34 SOCKETID 0
> > > CPUID Vendor Intel Family 6 Model 44 Step 2
> > > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > > Device Locator: P2-DIMM2C
> > > Bank Locator: BANK14
> > > Manufacturer: Hyundai
> > > Serial Number: 40F3C20F
> > > Asset Tag:
> > > Part Number: HMT151R7BFR4C-H9
> > > Hardware event. This is not a software error.
> > > MCE 2
> > > CPU 22 BANK 8 TSC 2a5604a6a070
> > > MISC ac29890200044281
> > > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > > MCG status:
> > > Memory ECC error occurred during scrub
> > > Memory corrected error count (CORE_ERR_CNT): 1
> > > Memory transaction Tracker ID (RTId): 81
> > > Memory DIMM ID of error: 0
> > > Memory channel ID of error: 1
> > > Memory ECC syndrome: ac298902
> > > STATUS 88000040000200cf MCGSTATUS 0
> > > MCGCAP 1c09 APICID 34 SOCKETID 0
> > > CPUID Vendor Intel Family 6 Model 44 Step 2
> > > Hardware event. This is not a software error.
> > > MCE 3
> > > CPU 22 BANK 8 TSC 31e141418eb8
> > > MISC ac29890200046a4a ADDR ee2f6e800
> > > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > > MCG status:
> > > Memory read ECC error
> > > Memory corrected error count (CORE_ERR_CNT): 1
> > > Memory transaction Tracker ID (RTId): 4a
> > > Memory DIMM ID of error: 0
> > > Memory channel ID of error: 1
> > > Memory ECC syndrome: ac298902
> > > STATUS 8c0000400001009f MCGSTATUS 0
> > > MCGCAP 1c09 APICID 34 SOCKETID 0
> > > CPUID Vendor Intel Family 6 Model 44 Step 2
> > > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > > Device Locator: P2-DIMM2C
> > > Bank Locator: BANK14
> > > Manufacturer: Hyundai
> > > Serial Number: 40F3C20F
> > > Asset Tag:
> > > Part Number: HMT151R7BFR4C-H9
> > > Hardware event. This is not a software error.
> > > MCE 4
> > > CPU 22 BANK 8 TSC 3a014afee106
> > > MISC ac29890200046646 ADDR ee2f6e800
> > > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > > MCG status:
> > > Memory read ECC error
> > > Memory corrected error count (CORE_ERR_CNT): 1
> > > Memory transaction Tracker ID (RTId): 46
> > > Memory DIMM ID of error: 0
> > > Memory channel ID of error: 1
> > > Memory ECC syndrome: ac298902
> > > STATUS 8c0000400001009f MCGSTATUS 0
> > > MCGCAP 1c09 APICID 34 SOCKETID 0
> > > CPUID Vendor Intel Family 6 Model 44 Step 2
> > > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > > Device Locator: P2-DIMM2C
> > > Bank Locator: BANK14
> > > Manufacturer: Hyundai
> > > Serial Number: 40F3C20F
> > > Asset Tag:
> > > Part Number: HMT151R7BFR4C-H9
> > > Hardware event. This is not a software error.
> > > MCE 5
> > > CPU 22 BANK 8 TSC 41d1dbef1a6a
> > > MISC ac29890200046141 ADDR ee2f6e800
> > > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > > MCG status:
> > > Memory read ECC error
> > > Memory corrected error count (CORE_ERR_CNT): 1
> > > Memory transaction Tracker ID (RTId): 41
> > > Memory DIMM ID of error: 0
> > > Memory channel ID of error: 1
> > > Memory ECC syndrome: ac298902
> > > STATUS 8c0000400001009f MCGSTATUS 0
> > > MCGCAP 1c09 APICID 34 SOCKETID 0
> > > CPUID Vendor Intel Family 6 Model 44 Step 2
> > > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > > Device Locator: P2-DIMM2C
> > > Bank Locator: BANK14
> > > Manufacturer: Hyundai
> > > Serial Number: 40F3C20F
> > > Asset Tag:
> > > Part Number: HMT151R7BFR4C-H9
> > > Hardware event. This is not a software error.
> > > MCE 6
> > > CPU 22 BANK 8 TSC 4a1b1ecef446
> > > MISC ac29890200046a4a ADDR ee2f6e800
> > > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > > MCG status:
> > > Memory read ECC error
> > > Memory corrected error count (CORE_ERR_CNT): 1
> > > Memory transaction Tracker ID (RTId): 4a
> > > Memory DIMM ID of error: 0
> > > Memory channel ID of error: 1
> > > Memory ECC syndrome: ac298902
> > > STATUS 8c0000400001009f MCGSTATUS 0
> > > MCGCAP 1c09 APICID 34 SOCKETID 0
> > > CPUID Vendor Intel Family 6 Model 44 Step 2
> > > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > > Device Locator: P2-DIMM2C
> > > Bank Locator: BANK14
> > > Manufacturer: Hyundai
> > > Serial Number: 40F3C20F
> > > Asset Tag:
> > > Part Number: HMT151R7BFR4C-H9
> > > Hardware event. This is not a software error.
> > > MCE 7
> > > CPU 22 BANK 8 TSC 527bc27db776
> > > MISC ac29890200040386 ADDR ee2f6e800
> > > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > > MCG status:
> > > Memory read ECC error
> > > Memory corrected error count (CORE_ERR_CNT): 1
> > > Memory transaction Tracker ID (RTId): 86
> > > Memory DIMM ID of error: 0
> > > Memory channel ID of error: 1
> > > Memory ECC syndrome: ac298902
> > > STATUS 8c0000400001009f MCGSTATUS 0
> > > MCGCAP 1c09 APICID 34 SOCKETID 0
> > > CPUID Vendor Intel Family 6 Model 44 Step 2
> > > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > > Device Locator: P2-DIMM2C
> > > Bank Locator: BANK14
> > > Manufacturer: Hyundai
> > > Serial Number: 40F3C20F
> > > Asset Tag:
> > > Part Number: HMT151R7BFR4C-H9
> > > Hardware event. This is not a software error.
> > > MCE 8
> > > CPU 22 BANK 8 TSC 5aa4ecdd795a
> > > MISC ac29890200046646 ADDR ee2f6e800
> > > TIME 1655770989 Mon Jun 20 19:23:09 2022
> > > MCG status:
> > > Memory read ECC error
> > > Memory corrected error count (CORE_ERR_CNT): 1
> > > Memory transaction Tracker ID (RTId): 46
> > > Memory DIMM ID of error: 0
> > > Memory channel ID of error: 1
> > > Memory ECC syndrome: ac298902
> > > STATUS 8c0000400001009f MCGSTATUS 0
> > > MCGCAP 1c09 APICID 34 SOCKETID 0
> > > CPUID Vendor Intel Family 6 Model 44 Step 2
> > > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > > Device Locator: P2-DIMM2C
> > > Bank Locator: BANK14
> > > Manufacturer: Hyundai
> > > Serial Number: 40F3C20F
> > > Asset Tag:
> > > Part Number: HMT151R7BFR4C-H9
> > > root@freenas[~]#
> > >
> > > and I replaced the DIMM yesterday :(
> > >
> > > On 06/20/2022 7:19 pm, Ultima wrote:
> > >
> > > Hey Larry,
> > >
> > > It is possible it's the motherboard itself, but it's rare. The way I
> > > would determine this is to swap the DIMM module with another
> > > populated slot on the motherboard and see if the error migrated
> > > to the new slot or not. Also, this error doesn't necessarily mean
> > > there is a problem that needs to be addressed. If you have been
> > > running the system for many months and you see ECC errors a
> > > handful of times, it can probably be safely ignored.
> > >
> > > Best regards,
> > > Richard Gallamore
> > >
> > > On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman 
> wrote:
> > > I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this
> > > DIMM a couple of times, and still the MCE's continue.
> > > Is it possible it's Motherboard slot issue?
> > >
> > > Hardware event. This is not a software error.
> > > MCE 8
> > > CPU 22 BANK 8 TSC 5aa4ecdd795a
> > > MISC ac29890200046646 ADDR ee2f6e800
> > > TIME 1655762472 Mon Jun 20 17:01:12 2022
> > > MCG status:
> > > Memory read ECC error
> > > Memory corrected error count (CORE_ERR_CNT): 1
> > > Memory transaction Tracker ID (RTId): 46
> > > Memory DIMM ID of error: 0
> > > Memory channel ID of error: 1
> > > Memory ECC syndrome: ac298902
> > > STATUS 8c0000400001009f MCGSTATUS 0
> > > MCGCAP 1c09 APICID 34 SOCKETID 0
> > > CPUID Vendor Intel Family 6 Model 44 Step 2
> > > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> > > Device Locator: P2-DIMM2C
> > > Bank Locator: BANK14
> > > Manufacturer: Hyundai
> > > Serial Number: 40F3C20F
> > > Asset Tag:
> > > Part Number: HMT151R7BFR4C-H9
> > >
> > > --
> > > Larry Rosenman                     http://www.lerctr.org/~ler
> > > Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> > > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> >
> > --
> > Larry Rosenman                     http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> >
> > --
> > Larry Rosenman                     http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> >
> > --
> > Larry Rosenman                     http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> >
> > --
> > Larry Rosenman                     http://www.lerctr.org/~ler
> > Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>
> --
> Rod Grimes
> rgrimes@freebsd.org
>

--000000000000b43f7505e1f80db6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Completely agree with you, Rodney. The LGA on the mot=
herboard
can be bent very easy when moving so I wanted to recomme=
nd this
last.

Larry, as Rodney mentioned=
, it's more or less your last option. This
is likely the CPU =
and not the module itself. There is still a small chance
that is =
motherboard/slot related, a way you can determine this is
by swap=
ping the CPU's slot 0 <----> slot 1 and seeing if the error moves=
.
As I mentioned though, be very cautious. I don't want y=
ou to be in a worse-off
state.

I would r=
eseat the problem CPU socket before swapping the CPUs.

Best regards,
Richard Gallamore

On T=
ue, Jun 21, 2022 at 9:06 AM Rodney W. Grimes <freebsd-rwg@gndrsh.dnsmgr.net> wrote:
> 

> 

> Swapped 2 DIMMS, now we wait for the ZFS ARC to fill and start using a=
ll 

> the memory.



Depending on the results of that one thing that is often overlooked

when trying to trouble shoot memory systems in modern Intel systems

is the fact that the DIMM now talks directly to the CPU chip that

has the memory controller built into it.=C2=A0 THUS these "slot" =
related

ECC/Parity/blowup errors can actually be the CPU and/or the CPU

socket and/or the seating of the CPU in the socket.=C2=A0 



So if the error sticks with the DIMM slot and not the DIMM

module the next thing I would try would be a CPU chip reseat,

including a good inspection of the socket for for a damaged

pin.=C2=A0 Also look at the lands on the CPU chip itself, and you

can even try swaping CPU chips to see if it follows the

CPU or the socket, much as you do with a DIMM.





> 

> On 06/20/2022 7:59 pm, Larry Rosenman wrote:

> 

> > SuperMicro X8DTN+

> > 

> > 2 Processors, 6-core/12-Thread. CPU: Intel(R) Xeon(R) CPU=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

> > E5645=C2=A0 @ 2.40GHz (2400.20-MHz K8-class CPU)

> > 

> > I'll bring it down and swap DIMMS around

> > 

> > On 06/20/2022 7:57 pm, Ultima wrote:

> > 

> > Hey Larry,

> > 

> > One red flag I am seeing is that the error is being produced on
> > the same CPU/bank with each error you have provided so far.

> > 

> > Can you try and follow my original recommendation and swap

> > currently installed DIMM with the problem DIMM slot and see

> > if anything changes?

> > 

> > Can you also provide the motherboard model? Also, do you

> > have multiple CPUs installed in this system?

> > 

> > Best regards,

> > Richard Gallamore

> > 

> > On Mon, Jun 20, 2022 at 5:41 PM Larry Rosenman <ler@lerctr.org> wrote:

> > 

> > Yes and Yes.

> > 

> > On 06/20/2022 7:37 pm, Ultima wrote:

> > 

> > Are you sure that the module you replaced it with was good?

> > Are you sure you replaced the correct module?

> > 

> > Best regards,

> > Richard Gallamore

> > 

> > On Mon, Jun 20, 2022 at 5:23 PM Larry Rosenman <ler@lerctr.org> wrote:

> > 

> > I'm seeing them constantly:

> > 

> > root@freenas[~]# mcelog --dmi

> > Hardware event. This is not a software error.

> > MCE 0

> > CPU 22 BANK 8 TSC 20aab486464a

> > MISC ac29890200046444 ADDR ee2f6e800

> > TIME 1655770989 Mon Jun 20 19:23:09 2022

> > MCG status:

> > Memory read ECC error

> > Memory corrected error count (CORE_ERR_CNT): 1

> > Memory transaction Tracker ID (RTId): 44

> > Memory DIMM ID of error: 0

> > Memory channel ID of error: 1

> > Memory ECC syndrome: ac298902

> > STATUS 8c0000400001009f MCGSTATUS 0

> > MCGCAP 1c09 APICID 34 SOCKETID 0

> > CPUID Vendor Intel Family 6 Model 44 Step 2

> > WARNING: SMBIOS data is often unreliable. Take with a grain of sa=
lt!

> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB

> > Device Locator: P2-DIMM2C

> > Bank Locator: BANK14

> > Manufacturer: Hyundai

> > Serial Number: 40F3C20F

> > Asset Tag:

> > Part Number: HMT151R7BFR4C-H9

> > Hardware event. This is not a software error.

> > MCE 1

> > CPU 22 BANK 8 TSC 296dfcc82582

> > MISC ac29890200041381 ADDR ee2f6e800

> > TIME 1655770989 Mon Jun 20 19:23:09 2022

> > MCG status:

> > Memory read ECC error

> > Memory corrected error count (CORE_ERR_CNT): 1

> > Memory transaction Tracker ID (RTId): 81

> > Memory DIMM ID of error: 0

> > Memory channel ID of error: 1

> > Memory ECC syndrome: ac298902

> > STATUS 8c0000400001009f MCGSTATUS 0

> > MCGCAP 1c09 APICID 34 SOCKETID 0

> > CPUID Vendor Intel Family 6 Model 44 Step 2

> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB

> > Device Locator: P2-DIMM2C

> > Bank Locator: BANK14

> > Manufacturer: Hyundai

> > Serial Number: 40F3C20F

> > Asset Tag:

> > Part Number: HMT151R7BFR4C-H9

> > Hardware event. This is not a software error.

> > MCE 2

> > CPU 22 BANK 8 TSC 2a5604a6a070

> > MISC ac29890200044281

> > TIME 1655770989 Mon Jun 20 19:23:09 2022

> > MCG status:

> > Memory ECC error occurred during scrub

> > Memory corrected error count (CORE_ERR_CNT): 1

> > Memory transaction Tracker ID (RTId): 81

> > Memory DIMM ID of error: 0

> > Memory channel ID of error: 1

> > Memory ECC syndrome: ac298902

> > STATUS 88000040000200cf MCGSTATUS 0

> > MCGCAP 1c09 APICID 34 SOCKETID 0

> > CPUID Vendor Intel Family 6 Model 44 Step 2

> > Hardware event. This is not a software error.

> > MCE 3

> > CPU 22 BANK 8 TSC 31e141418eb8

> > MISC ac29890200046a4a ADDR ee2f6e800

> > TIME 1655770989 Mon Jun 20 19:23:09 2022

> > MCG status:

> > Memory read ECC error

> > Memory corrected error count (CORE_ERR_CNT): 1

> > Memory transaction Tracker ID (RTId): 4a

> > Memory DIMM ID of error: 0

> > Memory channel ID of error: 1

> > Memory ECC syndrome: ac298902

> > STATUS 8c0000400001009f MCGSTATUS 0

> > MCGCAP 1c09 APICID 34 SOCKETID 0

> > CPUID Vendor Intel Family 6 Model 44 Step 2

> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB

> > Device Locator: P2-DIMM2C

> > Bank Locator: BANK14

> > Manufacturer: Hyundai

> > Serial Number: 40F3C20F

> > Asset Tag:

> > Part Number: HMT151R7BFR4C-H9

> > Hardware event. This is not a software error.

> > MCE 4

> > CPU 22 BANK 8 TSC 3a014afee106

> > MISC ac29890200046646 ADDR ee2f6e800

> > TIME 1655770989 Mon Jun 20 19:23:09 2022

> > MCG status:

> > Memory read ECC error

> > Memory corrected error count (CORE_ERR_CNT): 1

> > Memory transaction Tracker ID (RTId): 46

> > Memory DIMM ID of error: 0

> > Memory channel ID of error: 1

> > Memory ECC syndrome: ac298902

> > STATUS 8c0000400001009f MCGSTATUS 0

> > MCGCAP 1c09 APICID 34 SOCKETID 0

> > CPUID Vendor Intel Family 6 Model 44 Step 2

> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB

> > Device Locator: P2-DIMM2C

> > Bank Locator: BANK14

> > Manufacturer: Hyundai

> > Serial Number: 40F3C20F

> > Asset Tag:

> > Part Number: HMT151R7BFR4C-H9

> > Hardware event. This is not a software error.

> > MCE 5

> > CPU 22 BANK 8 TSC 41d1dbef1a6a

> > MISC ac29890200046141 ADDR ee2f6e800

> > TIME 1655770989 Mon Jun 20 19:23:09 2022

> > MCG status:

> > Memory read ECC error

> > Memory corrected error count (CORE_ERR_CNT): 1

> > Memory transaction Tracker ID (RTId): 41

> > Memory DIMM ID of error: 0

> > Memory channel ID of error: 1

> > Memory ECC syndrome: ac298902

> > STATUS 8c0000400001009f MCGSTATUS 0

> > MCGCAP 1c09 APICID 34 SOCKETID 0

> > CPUID Vendor Intel Family 6 Model 44 Step 2

> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB

> > Device Locator: P2-DIMM2C

> > Bank Locator: BANK14

> > Manufacturer: Hyundai

> > Serial Number: 40F3C20F

> > Asset Tag:

> > Part Number: HMT151R7BFR4C-H9

> > Hardware event. This is not a software error.

> > MCE 6

> > CPU 22 BANK 8 TSC 4a1b1ecef446

> > MISC ac29890200046a4a ADDR ee2f6e800

> > TIME 1655770989 Mon Jun 20 19:23:09 2022

> > MCG status:

> > Memory read ECC error

> > Memory corrected error count (CORE_ERR_CNT): 1

> > Memory transaction Tracker ID (RTId): 4a

> > Memory DIMM ID of error: 0

> > Memory channel ID of error: 1

> > Memory ECC syndrome: ac298902

> > STATUS 8c0000400001009f MCGSTATUS 0

> > MCGCAP 1c09 APICID 34 SOCKETID 0

> > CPUID Vendor Intel Family 6 Model 44 Step 2

> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB

> > Device Locator: P2-DIMM2C

> > Bank Locator: BANK14

> > Manufacturer: Hyundai

> > Serial Number: 40F3C20F

> > Asset Tag:

> > Part Number: HMT151R7BFR4C-H9

> > Hardware event. This is not a software error.

> > MCE 7

> > CPU 22 BANK 8 TSC 527bc27db776

> > MISC ac29890200040386 ADDR ee2f6e800

> > TIME 1655770989 Mon Jun 20 19:23:09 2022

> > MCG status:

> > Memory read ECC error

> > Memory corrected error count (CORE_ERR_CNT): 1

> > Memory transaction Tracker ID (RTId): 86

> > Memory DIMM ID of error: 0

> > Memory channel ID of error: 1

> > Memory ECC syndrome: ac298902

> > STATUS 8c0000400001009f MCGSTATUS 0

> > MCGCAP 1c09 APICID 34 SOCKETID 0

> > CPUID Vendor Intel Family 6 Model 44 Step 2

> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB

> > Device Locator: P2-DIMM2C

> > Bank Locator: BANK14

> > Manufacturer: Hyundai

> > Serial Number: 40F3C20F

> > Asset Tag:

> > Part Number: HMT151R7BFR4C-H9

> > Hardware event. This is not a software error.

> > MCE 8

> > CPU 22 BANK 8 TSC 5aa4ecdd795a

> > MISC ac29890200046646 ADDR ee2f6e800

> > TIME 1655770989 Mon Jun 20 19:23:09 2022

> > MCG status:

> > Memory read ECC error

> > Memory corrected error count (CORE_ERR_CNT): 1

> > Memory transaction Tracker ID (RTId): 46

> > Memory DIMM ID of error: 0

> > Memory channel ID of error: 1

> > Memory ECC syndrome: ac298902

> > STATUS 8c0000400001009f MCGSTATUS 0

> > MCGCAP 1c09 APICID 34 SOCKETID 0

> > CPUID Vendor Intel Family 6 Model 44 Step 2

> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB

> > Device Locator: P2-DIMM2C

> > Bank Locator: BANK14

> > Manufacturer: Hyundai

> > Serial Number: 40F3C20F

> > Asset Tag:

> > Part Number: HMT151R7BFR4C-H9

> > root@freenas[~]#

> > 

> > and I replaced the DIMM yesterday :(

> > 

> > On 06/20/2022 7:19 pm, Ultima wrote:

> > 

> > Hey Larry,

> > 

> > It is possible it's the motherboard itself, but it's rare=
. The way I

> > would determine this is to swap the DIMM module with another

> > populated slot on the motherboard and see if the error migrated
> > to the new slot or not. Also, this error doesn't necessarily =
mean

> > there is a problem that needs to be addressed. If you have been
> > running the system for many months and you see ECC errors a

> > handful of times, it can probably be safely ignored.

> > 

> > Best regards,

> > Richard Gallamore

> > 

> > On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman <ler@lerctr.org> wrote: 

> > I've gotten a BUNCH of these on my TrueNAS server.=C2=A0 I=
9;ve replaced this

> > DIMM a couple of times, and still the MCE's continue.

> > Is it possible it's Motherboard slot issue?

> > 

> > Hardware event. This is not a software error.

> > MCE 8

> > CPU 22 BANK 8 TSC 5aa4ecdd795a

> > MISC ac29890200046646 ADDR ee2f6e800

> > TIME 1655762472 Mon Jun 20 17:01:12 2022

> > MCG status:

> > Memory read ECC error

> > Memory corrected error count (CORE_ERR_CNT): 1

> > Memory transaction Tracker ID (RTId): 46

> > Memory DIMM ID of error: 0

> > Memory channel ID of error: 1

> > Memory ECC syndrome: ac298902

> > STATUS 8c0000400001009f MCGSTATUS 0

> > MCGCAP 1c09 APICID 34 SOCKETID 0

> > CPUID Vendor Intel Family 6 Model 44 Step 2

> > DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB

> > Device Locator: P2-DIMM2C

> > Bank Locator: BANK14

> > Manufacturer: Hyundai

> > Serial Number: 40F3C20F

> > Asset Tag:

> > Part Number: HMT151R7BFR4C-H9

> > 

> > --

> > Larry Rosenman=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.lerctr.org/~ler

> > Phone: +1 214-642-9640=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0E-Mail: ler@lerctr.org

> > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

> 

> -- 

> Larry Rosenman=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0http://www.lerctr.org/~ler

> Phone: +1 214-642-9640=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0E-Mail: l=
er@lerctr.org

> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

> 

> -- 

> Larry Rosenman=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0http://www.lerctr.org/~ler

> Phone: +1 214-642-9640=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0E-Mail: l=
er@lerctr.org

> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

> 

> -- 

> Larry Rosenman=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0http://www.lerctr.org/~ler

> Phone: +1 214-642-9640=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0E-Mail: l=
er@lerctr.org

> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

> 

> -- 

> Larry Rosenman=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0http://www.lerctr.org/~ler

> Phone: +1 214-642-9640=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0E-Mail: l=
er@lerctr.org

> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106



-- 

Rod Grimes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgrimes@freebsd.org




--000000000000b43f7505e1f80db6--

From nobody Tue Jun 21 18:23:24 2022
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 E84E4866817
	for ; Tue, 21 Jun 2022 18:23: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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSFJT38wxz3vfn
	for ; Tue, 21 Jun 2022 18:23:37 +0000 (UTC)
	(envelope-from 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 25LINObn041981;
	Tue, 21 Jun 2022 11:23:30 -0700 (PDT)
	(envelope-from bsd-lists@bsdforge.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
Date: Tue, 21 Jun 2022 11:23:24 -0700
From: Chris 
To: Larry Rosenman 
Cc: Ultima ,
        Freebsd current
 
Subject: Re: MCE: Does this look possibly like a slot issue?
In-Reply-To: 
References: 
 
 
User-Agent: UDNSMS/17.0
Message-ID: <696947ca2bfea895d0062a88c06673f7@bsdforge.com>
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_9cc2793dafa4de5e14b797d4bbeb2c22"
X-Rspamd-Queue-Id: 4LSFJT38wxz3vfn
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Spamd-Result: default: False [0.00 / 15.00];
	 ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	 local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_9cc2793dafa4de5e14b797d4bbeb2c22
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-06-20 17:23, Larry Rosenman wrote:
> I'm seeing them constantly:
FWIW it looks like a sync(ing) problem between your
RAM && CPU cache. Are are your clocks set correctly
for your CPU && RAM? Is your CPU too hot? Is the CPU
cache ECC?
> 
> root@freenas[~]# mcelog --dmi
> Hardware event. This is not a software error.
> MCE 0
> CPU 22 BANK 8 TSC 20aab486464a
> MISC ac29890200046444 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 44
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> WARNING: SMBIOS data is often unreliable. Take with a grain of salt!
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 1
> CPU 22 BANK 8 TSC 296dfcc82582
> MISC ac29890200041381 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 2
> CPU 22 BANK 8 TSC 2a5604a6a070
> MISC ac29890200044281
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory ECC error occurred during scrub
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 81
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 88000040000200cf MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> Hardware event. This is not a software error.
> MCE 3
> CPU 22 BANK 8 TSC 31e141418eb8
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 4
> CPU 22 BANK 8 TSC 3a014afee106
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 5
> CPU 22 BANK 8 TSC 41d1dbef1a6a
> MISC ac29890200046141 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 41
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 6
> CPU 22 BANK 8 TSC 4a1b1ecef446
> MISC ac29890200046a4a ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 4a
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 7
> CPU 22 BANK 8 TSC 527bc27db776
> MISC ac29890200040386 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 86
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> Hardware event. This is not a software error.
> MCE 8
> CPU 22 BANK 8 TSC 5aa4ecdd795a
> MISC ac29890200046646 ADDR ee2f6e800
> TIME 1655770989 Mon Jun 20 19:23:09 2022
> MCG status:
> Memory read ECC error
> Memory corrected error count (CORE_ERR_CNT): 1
> Memory transaction Tracker ID (RTId): 46
> Memory DIMM ID of error: 0
> Memory channel ID of error: 1
> Memory ECC syndrome: ac298902
> STATUS 8c0000400001009f MCGSTATUS 0
> MCGCAP 1c09 APICID 34 SOCKETID 0
> CPUID Vendor Intel Family 6 Model 44 Step 2
> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
> Device Locator: P2-DIMM2C
> Bank Locator: BANK14
> Manufacturer: Hyundai
> Serial Number: 40F3C20F
> Asset Tag:
> Part Number: HMT151R7BFR4C-H9
> root@freenas[~]#
> 
> and I replaced the DIMM yesterday :(
> 
> On 06/20/2022 7:19 pm, Ultima wrote:
> 
>> Hey Larry,
>> 
>> It is possible it's the motherboard itself, but it's rare. The way I
>> would determine this is to swap the DIMM module with another
>> populated slot on the motherboard and see if the error migrated
>> to the new slot or not. Also, this error doesn't necessarily mean
>> there is a problem that needs to be addressed. If you have been
>> running the system for many months and you see ECC errors a
>> handful of times, it can probably be safely ignored.
>> 
>> Best regards,
>> Richard Gallamore
>> 
>> On Mon, Jun 20, 2022 at 3:14 PM Larry Rosenman  wrote:
>> 
>>> I've gotten a BUNCH of these on my TrueNAS server.  I've replaced this
>>> DIMM a couple of times, and still the MCE's continue.
>>> Is it possible it's Motherboard slot issue?
>>> 
>>> Hardware event. This is not a software error.
>>> MCE 8
>>> CPU 22 BANK 8 TSC 5aa4ecdd795a
>>> MISC ac29890200046646 ADDR ee2f6e800
>>> TIME 1655762472 Mon Jun 20 17:01:12 2022
>>> MCG status:
>>> Memory read ECC error
>>> Memory corrected error count (CORE_ERR_CNT): 1
>>> Memory transaction Tracker ID (RTId): 46
>>> Memory DIMM ID of error: 0
>>> Memory channel ID of error: 1
>>> Memory ECC syndrome: ac298902
>>> STATUS 8c0000400001009f MCGSTATUS 0
>>> MCGCAP 1c09 APICID 34 SOCKETID 0
>>> CPUID Vendor Intel Family 6 Model 44 Step 2
>>> DDR3 DIMM 800 Mhz Other Width 72 Data Width 64 Size 4 GB
>>> Device Locator: P2-DIMM2C
>>> Bank Locator: BANK14
>>> Manufacturer: Hyundai
>>> Serial Number: 40F3C20F
>>> Asset Tag:
>>> Part Number: HMT151R7BFR4C-H9
>>> 
>>> --
>>> Larry Rosenman                     http://www.lerctr.org/~ler
>>> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
>>> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

--=_9cc2793dafa4de5e14b797d4bbeb2c22
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_9cc2793dafa4de5e14b797d4bbeb2c22--

From nobody Tue Jun 21 19:23:11 2022
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 020F88725D2
	for ; Tue, 21 Jun 2022 19:23:16 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSGdH2QQrz4fXM
	for ; Tue, 21 Jun 2022 19:23:15 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=TuAuTlRr2PogCApqXfDPyolGLq3haby9Q5reHbMafa0=; b=XPpRC6Wanji14WukesN+C62s2D
	tMl1++yZSEkfglyWgK+xPcGgWiBxNX5ZePz3gukDWB8c+5LH545SYNNTUOw/ybw5YLDLfiYfI4cIN
	8FO8zsJAW69F0MvV0xtRtI/1Q7weytEfT7r3dR2THO40a2I6PYnva5OzP08N3PVJMbi+2x6szQG7V
	O6MlUc2cVEZx8jSg6SdWz0h74qBV0+tMfubFrw0tHZWW6HMDt3xA7hnOCfiAcdxMNNJQKzKh/SMYt
	Xwmze9TT/pchUGVfv10r0c1UFAfYTXfDXIOdoTTGRjFuh2JfIyRR/thCnqZ0EmqWRfUOTH0g1Te+r
	gTcs/P/g==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:13638 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o3jSx-0001KT-Sp;
	Tue, 21 Jun 2022 14:23:11 -0500
Received: from 2600:1700:210:b18f:7139:7834:f65d:718c
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Tue, 21 Jun 2022 14:23:11 -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
Date: Tue, 21 Jun 2022 14:23:11 -0500
From: Larry Rosenman 
To: Chris 
Cc: Ultima , Freebsd current
 
Subject: Re: MCE: Does this look possibly like a slot issue?
In-Reply-To: <696947ca2bfea895d0062a88c06673f7@bsdforge.com>
References: 
 
 
 <696947ca2bfea895d0062a88c06673f7@bsdforge.com>
Message-ID: <82787bd0e19b4ffa929d21c8515ea0c3@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LSGdH2QQrz4fXM
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=XPpRC6Wa;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.00 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+mx];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 ARC_NA(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 SUBJECT_ENDS_QUESTION(1.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 FREEMAIL_CC(0.00)[gmail.com,freebsd.org];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 06/21/2022 1:23 pm, Chris wrote:
> On 2022-06-20 17:23, Larry Rosenman wrote:
>> I'm seeing them constantly:
> FWIW it looks like a sync(ing) problem between your
> RAM && CPU cache. Are are your clocks set correctly
> for your CPU && RAM? Is your CPU too hot? Is the CPU
> cache ECC?
>> 
>> root@freenas[~]# mcelog --dmi

[snip]

Hrm.  IIRC all the BIOS parameters are default (I could be mistaken).  
It's a
SuperMicro X8DTN+ motherboard with:
CPU: Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz (2400.22-MHz 
K8-class CPU)
   Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c  Stepping=2
   
Features=0xbfebfbff
   
Features2=0x29ee3ff
   AMD Features=0x2c100800
   AMD Features2=0x1
   Structured Extended Features3=0x9c000000
   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
   TSC: P-state invariant, performance statistics
real memory  = 77309411328 (73728 MB)
avail memory = 75186962432 (71703 MB)
(2 packages, 6 core, 12-threads each) and 18 4GB sticks.
this ONE slot seems to be a problem.

How would you recommend looking for an issue modulo pulling the 2 cpu 
packages?

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Tue Jun 21 20:27:53 2022
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 35D7785D6F9
	for ; Tue, 21 Jun 2022 20:28:01 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSJ405wdPz4qk4
	for ; Tue, 21 Jun 2022 20:28:00 +0000 (UTC)
	(envelope-from 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 25LKRrHq034865;
	Tue, 21 Jun 2022 13:27:59 -0700 (PDT)
	(envelope-from bsd-lists@bsdforge.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
Date: Tue, 21 Jun 2022 13:27:53 -0700
From: Chris 
To: Larry Rosenman 
Cc: Ultima ,
        Freebsd current
 
Subject: Re: MCE: Does this look possibly like a slot issue?
In-Reply-To: <82787bd0e19b4ffa929d21c8515ea0c3@lerctr.org>
References: 
 
 
 <696947ca2bfea895d0062a88c06673f7@bsdforge.com>
 <82787bd0e19b4ffa929d21c8515ea0c3@lerctr.org>
User-Agent: UDNSMS/17.0
Message-ID: <4aee6dcd2e0942cc65183e38283d2411@bsdforge.com>
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_4723ad2c58da89832ebb706818ad6808"
X-Rspamd-Queue-Id: 4LSJ405wdPz4qk4
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Spamd-Result: default: False [0.00 / 15.00];
	 ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	 local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_4723ad2c58da89832ebb706818ad6808
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-06-21 12:23, Larry Rosenman wrote:
> On 06/21/2022 1:23 pm, Chris wrote:
>> On 2022-06-20 17:23, Larry Rosenman wrote:
>>> I'm seeing them constantly:
>> FWIW it looks like a sync(ing) problem between your
>> RAM && CPU cache. Are are your clocks set correctly
>> for your CPU && RAM? Is your CPU too hot? Is the CPU
>> cache ECC?
>>> 
>>> root@freenas[~]# mcelog --dmi
> 
> [snip]
> 
> Hrm.  IIRC all the BIOS parameters are default (I could be mistaken).  It's 
> a
> SuperMicro X8DTN+ motherboard with:
> CPU: Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz (2400.22-MHz K8-class 
> CPU)
>   Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c  Stepping=2
> 
> Features=0xbfebfbff
> 
> Features2=0x29ee3ff
>   AMD Features=0x2c100800
>   AMD Features2=0x1
>   Structured Extended Features3=0x9c000000
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 77309411328 (73728 MB)
> avail memory = 75186962432 (71703 MB)
> (2 packages, 6 core, 12-threads each) and 18 4GB sticks.
> this ONE slot seems to be a problem.
> 
> How would you recommend looking for an issue modulo pulling the 2 cpu 
> packages?
When I ran into these errors it turned out to be a hot CPU as I recall. While 
I'm familiar with
the hardware your using. I have no history with *your* equipment. The first 2 
things I'd do
given ECC is so sensitive, is replace/swap the PSU with a known good one. The 
CPU(s) should
be re-seated && re-greased. The fans operate as intended? At that point a 
long session with
sysutils/memtest86 or a buildworld session should tell you if everything is 
AOK. Frankly; as to
testing memory; working with a single stick at a time would be more 
conclusive resulting
in a shorter time to conclusion.

HTH

Chris

--=_4723ad2c58da89832ebb706818ad6808
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_4723ad2c58da89832ebb706818ad6808--

From nobody Wed Jun 22 12:53:01 2022
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 17F9885F65E
	for ; Wed, 22 Jun 2022 12:53:06 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1anam02olkn2074.outbound.protection.outlook.com [40.92.44.74])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSjwd0wGWz3P2j
	for ; Wed, 22 Jun 2022 12:53:05 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=BWeLHL+0q6vAZ8ZyogbdJJDCClw1MS5cxGnvdrFdK2xaBBpbxF7urQfq8g7dgdRbHQCmeF4GTdGO8467hSiH4xl4UdoODCA7qZ6yxUZ/e0VAhrsIz40TdPdQ8hUhDv29iIr/1ZX1ijSD60WRIqMGO61PrTOmZjdV4fFaqxNmS/zhDB+OnGfB8dQUcaB4/hDKMKhiC1cqgZDiRGLS2QjdP7a/qDcGGlN+SlKyi7pbaukDSj/NTCXixsSCj0pX8VScMczA2K+rvWdhIi/drJ9p1V2DtzgeedX2/77Q7jkiPbL9X3VN1ZqUqEvZac73cYRgHrPqZAYX2w1YuHFuxN3SRA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bLdCcW6zvcs00dYVeQRltit19kF2MfbBcgYpr6CwPbE=;
 b=j3eXzdl9hTKzEj7c6sSASYSOJk4YxRwZk8LKr9nOT78o8OHGTQPreThyHg+k7m8tMOGc+64jKXzv97TO7RzI8ZghyoDBSqlVOXh5umhvpodkMmxHk3yEVK3kuoX3zeD7oVwDBHYbd+HsBc92LwSJuSzH6cSAArQRnmEJKyb4GbsEqbS+xDPaXUMnaK2VRRtiVmnZTaDRLwWJA/qmFcFN3ghPsja9xynAAQ4iYCsF7anYYEj2MIGRCka5gdZFfAeNeLtKyyiv/sG7xOupvfoc+0Bp2LUnVk4es8pbT3oFIpiMFR76aoRfI6upl92S5DhwqvCmxzYsZB9O9EZou5Gj5A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=bLdCcW6zvcs00dYVeQRltit19kF2MfbBcgYpr6CwPbE=;
 b=PMp7y44w7dIPIi8DJYP5o02YC2TFInwvJnKszk5jvfdNnhiwtVOVym+YWWQjSuYazvDKXeWFLA0Qobx0UELBv4/Bqv+q9rf/ZsFAiIGf67vs5TMIjcSNC+y5GeF+WKyankaoZQjdOj5IM7n9zRsy0wGA/sf6Nzqliok7u+GHxg0oqUdRyHhbrtw0KJq0djei/6VqjyEKtNziAGnaHa+Fgeos8IiNhUAHPzOt/5eZ/jhEbkuHWUIE6vFd6Sud2LNcSoBtC2EFNyy2Dr9deNo748ufUekZS5m6bicILrrIKb20jIAsral98wJINFkgvgO/1HQOG2HbVUYsDTKsfSR8Aw==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by FRBP284MB0649.BRAP284.PROD.OUTLOOK.COM (2603:10d6:203:30::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.16; Wed, 22 Jun
 2022 12:53:03 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%7]) with mapi id 15.20.5353.022; Wed, 22 Jun 2022
 12:53:03 +0000
Date: Wed, 22 Jun 2022 09:53:01 -0300 (-03)
From: Ivan Quitschal 
To: freebsd-current@freebsd.org
Subject: vt newcons mouse paste issue FIXED
Message-ID:
 
Content-Type: multipart/mixed; boundary="3432851520-594251130-1655902382=:1623"
X-TMN: [wZQx5lCSHDBF6tlWoGBKI5A/4KqALRSP]
X-ClientProxiedBy: CP4P284CA0006.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:128::6) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <9d52fa3-2e2d-90fc-42a-1ab0e9baec@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 017ff130-27e0-466c-4a5b-08da544e24ae
X-MS-TrafficTypeDiagnostic: FRBP284MB0649:EE_
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	DbOOmyLsVI4BWr6KnUv25eAW0Sth8t1XXVKpoV2eSkciVq8Kk4CEo4k1rr1Lp4EoywO6pPe9CiThxg8g+zTYDptCT+NuVJPehqlXnF8AokAdMCTyYVL9hqdjKxxInTgXieDhuSVAHwadr1dURSkLLrLM+Lbh+Zm/G+om/ZH2YBL2V5ZBdt4aDs4JUC6Scim7viXXUfbKadb+uS5SZITd+WRqZ1CPHWzvLIcMYZwmCX4nTsENtCwrzANsBcWpt0YxKbeevKpdh8OzZqXL+Zgn7a7A9iyZgtOMuGimT8TQP2BoUnjdCj7lQFf9pH5kC1dV36l3Llpv+b08ixUY9azp/bOcQUjU6Kj4fE++X7Tq7jfAGF+fesusR5J2LJl9+sufGk8/jHj4pmWwP9pqoFZ/ZS1dOl4qi9qtP7yjoVX1W/T7NNyknkCS94dBruNj/wc8JkCyTiNtCkbCOiREeutFy0lM+3R1s2wTWmHWyOfjbdGSXaUcdIQMnN5lkyvj5vensEnHSbfOfMgLiPzXPXeFfItArvHu51V0oEcgP+IsAVs2JTBnGEA+q67oumH+2a3RUSA2NdL2Pd652ETvJJMMGXHHRSPoTvapJg6AA+/fLbtEf9vX86outv7BQwSKhhKD1qNcHHQ/EYhLD+h8Dg+zfA==
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?pG+XMhZPd8/Gxsw0WHIaLR7pFrzyW/pwDa0vegYrZyvlPvJYsb2jLFg4SVQF?=
 =?us-ascii?Q?Wg8x3NgEAWHyDR5vQB305xNU6KsCtzil3o98RLoj6q8zvTgw1Qu5amum4bzU?=
 =?us-ascii?Q?PLS8vfao4DS76J/s7vHIAzKwCHZ6TuGsHlGfL8wCTIunyguxNCH9PMlDDVGI?=
 =?us-ascii?Q?u534LkvpzAh/ZCKs/Tny+bv3TfbnTPaX+wqcb0IBUwP7pUgCC5do69QAHTjF?=
 =?us-ascii?Q?+eMI8Klbqr/jl6V6g9Sp/LYlxSYX6CEy+iuV6sFLJVzbk4jY5WiqBDTKwLDE?=
 =?us-ascii?Q?MhTR9gy1x23GALUVfOqshk6W3Bol48wZ2YcgD2r1pDpCKq8e+robAoDl1sSx?=
 =?us-ascii?Q?543pJKyXdqzwCW1qW9Qe2ch3oHqZw/qLg618dWW/4OoBmCFhWMRdlFsvms6t?=
 =?us-ascii?Q?F6b4C88C8b2Qrve5+Gui5IMnaKcUXshEQj2KLbeIsiv/mj21AHxFk0Xviqv/?=
 =?us-ascii?Q?RPIh2dTtcdTuv2VcvglZWZNIhTZfTDDWCpqzZssFhQ3J73CdjkIp58QIZPPt?=
 =?us-ascii?Q?gNVGE82wFrNLR8iRr/F9M16MRCJS9iaiFoAagH/bqNuhJ9Dk3yMJrClkoQu8?=
 =?us-ascii?Q?o70gTkwXYqV7lTq17/MN6rm9BuDQDJgyRaQ1vNz8uPhVbj3mJpQFT+bEUdtp?=
 =?us-ascii?Q?4Ph9izDqdJembcWVAMp1DZdHMOqE2YBr0mp+w3sI9XG5MqfChBySOsM50XRA?=
 =?us-ascii?Q?jgsUP9h3MsXyJKQ4yojn3L+PFjYDb8uX9XYHvhKURAnRrNYS5OXJCV1xLndE?=
 =?us-ascii?Q?CowjEK7i1Y52IgmLpmpPslAraSHeDs5qOJrrAFZJh5q0Ne8UX5Cb85On3a94?=
 =?us-ascii?Q?bKcCEcwyJpTAirA0ma+4IXf+RSyw4MUNf8O5nLzhH9I4EK991ah6elks8/Cv?=
 =?us-ascii?Q?Q7h4gVTPXaueHwq+X+0nnEOB0Ujb1Wzn7UfxZ41d+VcqV8HIaaXXCVYtcfpQ?=
 =?us-ascii?Q?3zn9gkE2y5+meXZ21HOHK43wo46hCbCjo7preZEWGmkh9N+62NotW+bIfpuC?=
 =?us-ascii?Q?4ozUQKxqSxZgGU9fNucjdR9TRJzepx5SAzgwVVppoAjHDF2Z5xUe6+omLwk2?=
 =?us-ascii?Q?o7CZOipflYEQpjSqh2K1WZgsfkJMfVf6QnqFbQ4ubrxhb2tP+5n8xUVIvzKd?=
 =?us-ascii?Q?6Q/daJ0Ncdw5ohjqqBXtydU0dtFYNVCnJ44SuaCBbfF03b3w4Bx3ZtKcgO8e?=
 =?us-ascii?Q?xnk+igvbgO3BwbsPAWFvI/UQJPVmgCWs33PV9s3N4rg1hbD+StzmVRghy83u?=
 =?us-ascii?Q?iPWLMuPUdIWxBwP0SJif8wFi8oALfKuk2yU5rkBJmtibUY1lsBx8PUMahCtg?=
 =?us-ascii?Q?3z+iv03xAmpxaMfLq+qLdbTDlLy5mI0flqy/Wsmc7ixHsllfk9MDYXEUKNja?=
 =?us-ascii?Q?s43AIxG1eS+Wy8EQIUBNO6sg+mI0ZvePg9Bi30WmPYSrOB3Q/8s66mQOhTb0?=
 =?us-ascii?Q?KrHMrkkSj10=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 017ff130-27e0-466c-4a5b-08da544e24ae
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2022 12:53:02.9992
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRBP284MB0649
X-Rspamd-Queue-Id: 4LSjwd0wGWz3P2j
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=PMp7y44w;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.44.74 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-2.85 / 15.00];
	 FREEMAIL_FROM(0.00)[hotmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	 HAS_ATTACHMENT(0.00)[];
	 TO_DN_NONE(0.00)[];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[hotmail.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 CTYPE_MIXED_BOGUS(1.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:+];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	 FREEMAIL_ENVFROM(0.00)[hotmail.com];
	 DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	 NEURAL_HAM_MEDIUM(-0.95)[-0.954];
	 R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	 RCPT_COUNT_ONE(0.00)[1];
	 RCVD_IN_DNSWL_NONE(0.00)[40.92.44.74:from];
	 MLMMJ_DEST(0.00)[freebsd-current]
X-ThisMailContainsUnwantedMimeParts: N

--3432851520-594251130-1655902382=:1623
Content-Type: text/plain; format=flowed; charset=US-ASCII


Hi All

About this anoying paste error we still have in vt console, I looked it up and couldnt find any fix regarding this, so i did it.

Please find attached the fixed version of /usr/src/sys/dev/vt/vt_buf.c with trim spaces and aligned to the console size.
I've tested with other fonts and looks fine in here.

I hope this can help other ppl which finds this 
terminal mouse paste issue a pain in the neck.

thanks

--tzk
--3432851520-594251130-1655902382=:1623
Content-Type: text/plain; charset=US-ASCII; name=vt_buf.c
Content-Transfer-Encoding: BASE64
Content-ID: 
Content-Description: vt_buf.c
Content-Disposition: attachment; filename=vt_buf.c

LyotDQogKiBTUERYLUxpY2Vuc2UtSWRlbnRpZmllcjogQlNELTItQ2xhdXNlLUZyZWVCU0QNCiAq
DQogKiBDb3B5cmlnaHQgKGMpIDIwMDksIDIwMTMgVGhlIEZyZWVCU0QgRm91bmRhdGlvbg0KICoN
CiAqIFRoaXMgc29mdHdhcmUgd2FzIGRldmVsb3BlZCBieSBFZCBTY2hvdXRlbiB1bmRlciBzcG9u
c29yc2hpcCBmcm9tIHRoZQ0KICogRnJlZUJTRCBGb3VuZGF0aW9uLg0KICoNCiAqIFBvcnRpb25z
IG9mIHRoaXMgc29mdHdhcmUgd2VyZSBkZXZlbG9wZWQgYnkgT2xla3NhbmRyIFJ5YmFsa28NCiAq
IHVuZGVyIHNwb25zb3JzaGlwIGZyb20gdGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCiAqDQogKiBS
ZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9y
IHdpdGhvdXQNCiAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRo
ZSBmb2xsb3dpbmcgY29uZGl0aW9ucw0KICogYXJlIG1ldDoNCiAqIDEuIFJlZGlzdHJpYnV0aW9u
cyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0DQogKiAgICBu
b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt
ZXIuDQogKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2Ug
dGhlIGFib3ZlIGNvcHlyaWdodA0KICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9u
cyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQ0KICogICAgZG9jdW1lbnRhdGlv
biBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4N
CiAqDQogKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRS
SUJVVE9SUyBgYEFTIElTJycgQU5EDQogKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJ
RVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUNCiAqIElNUExJRUQgV0FSUkFO
VElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFDQogKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1Ig
Q09OVFJJQlVUT1JTIEJFIExJQUJMRQ0KICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJ
REVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwNCiAqIERBTUFHRVMg
KElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRF
IEdPT0RTDQogKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9S
IEJVU0lORVNTIElOVEVSUlVQVElPTikNCiAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhF
T1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUDQogKiBMSUFCSUxJ
VFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJ
TiBBTlkgV0FZDQogKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFE
VklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GDQogKiBTVUNIIERBTUFHRS4NCiAqLw0KDQojaW5j
bHVkZSA8c3lzL2NkZWZzLmg+DQpfX0ZCU0RJRCgiJEZyZWVCU0QkIik7DQoNCiNpbmNsdWRlIDxz
eXMvcGFyYW0uaD4NCiNpbmNsdWRlIDxzeXMvc3lzdG0uaD4NCiNpbmNsdWRlIDxzeXMva2VybmVs
Lmg+DQojaW5jbHVkZSA8c3lzL2xvY2suaD4NCiNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+DQojaW5j
bHVkZSA8c3lzL211dGV4Lmg+DQojaW5jbHVkZSA8c3lzL3JlYm9vdC5oPg0KI2luY2x1ZGUgPHN5
cy9jdHlwZS5oPg0KDQojaW5jbHVkZSA8ZGV2L3Z0L3Z0Lmg+DQoNCnN0YXRpYyBNQUxMT0NfREVG
SU5FKE1fVlRCVUYsICJ2dGJ1ZiIsICJ2dCBidWZmZXIiKTsNCg0KI2RlZmluZQlWVEJVRl9MT0NL
KHZiKQkJbXR4X2xvY2tfc3BpbigmKHZiKS0+dmJfbG9jaykNCiNkZWZpbmUJVlRCVUZfVU5MT0NL
KHZiKQltdHhfdW5sb2NrX3NwaW4oJih2YiktPnZiX2xvY2spDQoNCiNkZWZpbmUgUE9TX0lOREVY
KGMsIHIpICgoKHIpIDw8IDEyKSArIChjKSkNCiNkZWZpbmUJUE9TX0NPUFkoZCwgcykJZG8gewlc
DQoJKGQpLnRwX2NvbCA9IChzKS50cF9jb2w7CVwNCgkoZCkudHBfcm93ID0gKHMpLnRwX3JvdzsJ
XA0KfSB3aGlsZSAoMCkNCg0KI2lmbmRlZiBTQ19OT19DVVRQQVNURQ0Kc3RhdGljIGludCB2dGJ1
Zl9odHcoY29uc3Qgc3RydWN0IHZ0X2J1ZiAqdmIsIGludCByb3cpOw0Kc3RhdGljIGludCB2dGJ1
Zl93dGgoY29uc3Qgc3RydWN0IHZ0X2J1ZiAqdmIsIGludCByb3cpOw0Kc3RhdGljIGludCB2dGJ1
Zl9pbl90aGlzX3JhbmdlKGludCBiZWdpbiwgaW50IHRlc3QsIGludCBlbmQsIGludCBzeik7DQoj
ZW5kaWYNCg0KLyoNCiAqIGxpbmU0DQogKiBsaW5lNSA8LS0tIGN1cnJvZmZzZXQgKHRlcm1pbmFs
IG91dHB1dCB0byB0aGF0IGxpbmUpDQogKiBsaW5lMA0KICogbGluZTEgICAgICAgICAgICAgICAg
ICA8LS0tIHJvZmZzZXQgKGhpc3RvcnkgZGlzcGxheSBmcm9tIHRoYXQgcG9pbnQpDQogKiBsaW5l
Mg0KICogbGluZTMNCiAqLw0KaW50DQp2dGhpc3Rvcnlfc2VlayhzdHJ1Y3QgdnRfYnVmICp2Yiwg
aW50IG9mZnNldCwgaW50IHdoZW5jZSkNCnsNCglpbnQgZGlmZiwgdG9wLCBib3R0b20sIHJvZmZz
ZXQ7DQoNCgkvKiBObyBzY3JvbGxpbmcgaWYgbm90IGVuYWJsZWQuICovDQoJaWYgKCh2Yi0+dmJf
ZmxhZ3MgJiBWQkZfU0NST0xMKSA9PSAwKSB7DQoJCWlmICh2Yi0+dmJfcm9mZnNldCAhPSB2Yi0+
dmJfY3Vycm9mZnNldCkgew0KCQkJdmItPnZiX3JvZmZzZXQgPSB2Yi0+dmJfY3Vycm9mZnNldDsN
CgkJCXJldHVybiAoMHhmZmZmKTsNCgkJfQ0KCQlyZXR1cm4gKDApOyAvKiBObyBjaGFuZ2VzICov
DQoJfQ0KDQoJLyogInRvcCIgbWF5IGJlIGEgbmVnYXRpdmUgaW50ZWdlci4gKi8NCglib3R0b20g
PSB2Yi0+dmJfY3Vycm9mZnNldDsNCgl0b3AgPSAodmItPnZiX2ZsYWdzICYgVkJGX0hJU1RPUllf
RlVMTCkgPw0KCSAgICBib3R0b20gKyB2Yi0+dmJfc2NyX3NpemUudHBfcm93IC0gdmItPnZiX2hp
c3Rvcnlfc2l6ZSA6DQoJICAgIDA7DQoNCglyb2Zmc2V0ID0gMDsgLyogTWFrZSBnY2MgaGFwcHku
ICovDQoJc3dpdGNoICh3aGVuY2UpIHsNCgljYXNlIFZIU19TRVQ6DQoJCWlmIChvZmZzZXQgPCAw
KQ0KCQkJb2Zmc2V0ID0gMDsNCgkJcm9mZnNldCA9IHRvcCArIG9mZnNldDsNCgkJYnJlYWs7DQoJ
Y2FzZSBWSFNfQ1VSOg0KCQkvKg0KCQkgKiBPcGVyYXRlIG9uIGNvcHkgb2Ygb2Zmc2V0IHZhbHVl
LCBzaW5jZSBpdCB0ZW1wb3JhcnkNCgkJICogY2FuIGJlIGJpZ2dlciB0aGFuIGFtb3VudCBvZiBy
b3dzIGluIGJ1ZmZlci4NCgkJICovDQoJCXJvZmZzZXQgPSB2Yi0+dmJfcm9mZnNldDsNCgkJaWYg
KHJvZmZzZXQgPj0gYm90dG9tICsgdmItPnZiX3Njcl9zaXplLnRwX3JvdykNCgkJCXJvZmZzZXQg
LT0gdmItPnZiX2hpc3Rvcnlfc2l6ZTsNCg0KCQlyb2Zmc2V0ICs9IG9mZnNldDsNCgkJcm9mZnNl
dCA9IE1BWChyb2Zmc2V0LCB0b3ApOw0KCQlyb2Zmc2V0ID0gTUlOKHJvZmZzZXQsIGJvdHRvbSk7
DQoNCgkJaWYgKHJvZmZzZXQgPCAwKQ0KCQkJcm9mZnNldCA9IHZiLT52Yl9oaXN0b3J5X3NpemUg
KyByb2Zmc2V0Ow0KDQoJCWJyZWFrOw0KCWNhc2UgVkhTX0VORDoNCgkJLyogR28gdG8gY3VycmVu
dCBvZmZzZXQuICovDQoJCXJvZmZzZXQgPSB2Yi0+dmJfY3Vycm9mZnNldDsNCgkJYnJlYWs7DQoJ
fQ0KDQoJZGlmZiA9IHZiLT52Yl9yb2Zmc2V0ICE9IHJvZmZzZXQ7DQoJdmItPnZiX3JvZmZzZXQg
PSByb2Zmc2V0Ow0KDQoJcmV0dXJuIChkaWZmKTsNCn0NCg0Kdm9pZA0KdnRoaXN0b3J5X2FkZGxp
bmVzKHN0cnVjdCB2dF9idWYgKnZiLCBpbnQgb2Zmc2V0KQ0Kew0KI2lmbmRlZiBTQ19OT19DVVRQ
QVNURQ0KCWludCBjdXIsIHN6Ow0KI2VuZGlmDQoNCgl2Yi0+dmJfY3Vycm9mZnNldCArPSBvZmZz
ZXQ7DQoJaWYgKHZiLT52Yl9jdXJyb2Zmc2V0ICsgdmItPnZiX3Njcl9zaXplLnRwX3JvdyA+PSB2
Yi0+dmJfaGlzdG9yeV9zaXplKSB7DQoJCXZiLT52Yl9mbGFncyB8PSBWQkZfSElTVE9SWV9GVUxM
Ow0KCQl2Yi0+dmJfY3Vycm9mZnNldCAlPSB2Yi0+dmJfaGlzdG9yeV9zaXplOw0KCX0NCglpZiAo
KHZiLT52Yl9mbGFncyAmIFZCRl9TQ1JPTEwpID09IDApIHsNCgkJdmItPnZiX3JvZmZzZXQgPSB2
Yi0+dmJfY3Vycm9mZnNldDsNCgl9DQoNCiNpZm5kZWYgU0NfTk9fQ1VUUEFTVEUNCglzeiA9IHZi
LT52Yl9oaXN0b3J5X3NpemU7DQoJY3VyID0gdmItPnZiX3JvZmZzZXQgKyB2Yi0+dmJfc2NyX3Np
emUudHBfcm93ICsgc3ogLSAxOw0KCWlmICh2dGJ1Zl9pbl90aGlzX3JhbmdlKGN1ciwgdmItPnZi
X21hcmtfc3RhcnQudHBfcm93LCBjdXIgKyBvZmZzZXQsIHN6KSB8fA0KCSAgICB2dGJ1Zl9pbl90
aGlzX3JhbmdlKGN1ciwgdmItPnZiX21hcmtfZW5kLnRwX3JvdywgY3VyICsgb2Zmc2V0LCBzeikp
IHsNCgkJLyogY2xlYXIgc2NyZWVuIHNlbGVjdGlvbiAqLw0KCQl2Yi0+dmJfbWFya19zdGFydC50
cF9yb3cgPSB2Yi0+dmJfbWFya19lbmQudHBfcm93Ow0KCQl2Yi0+dmJfbWFya19zdGFydC50cF9j
b2wgPSB2Yi0+dmJfbWFya19lbmQudHBfY29sOw0KCX0NCiNlbmRpZg0KfQ0KDQp2b2lkDQp2dGhp
c3RvcnlfZ2V0cG9zKGNvbnN0IHN0cnVjdCB2dF9idWYgKnZiLCB1bnNpZ25lZCBpbnQgKm9mZnNl
dCkNCnsNCg0KCSpvZmZzZXQgPSB2Yi0+dmJfcm9mZnNldDsNCn0NCg0KI2lmbmRlZiBTQ19OT19D
VVRQQVNURQkvKiBPbmx5IG1vdXNlIHN1cHBvcnQgdXNlIGl0IG5vdy4gKi8NCi8qIFRyYW5zbGF0
ZSBoaXN0b3J5IHJvdyB0byBjdXJyZW50IHZpZXcgcm93IG51bWJlci4gKi8NCnN0YXRpYyBpbnQN
CnZ0YnVmX2h0dyhjb25zdCBzdHJ1Y3QgdnRfYnVmICp2YiwgaW50IHJvdykNCnsNCg0KCS8qDQoJ
ICogdG90YWwgMTAwMCByb3dzLg0KCSAqIEhpc3Rvcnkgb2Zmc2V0CXJvZmZzZXQJd2lucm93DQoJ
ICoJMjA1CQkyMDAJKCgyMDUgLSAyMDAgKyAxMDAwKSAlIDEwMDApID0gNQ0KCSAqCTkwCQk5OTAJ
KCg5MCAtIDk5MCArIDEwMDApICUgMTAwMCkgPSAxMDANCgkgKi8NCglyZXR1cm4gKChyb3cgLSB2
Yi0+dmJfcm9mZnNldCArIHZiLT52Yl9oaXN0b3J5X3NpemUpICUNCgkgICAgdmItPnZiX2hpc3Rv
cnlfc2l6ZSk7DQp9DQoNCi8qIFRyYW5zbGF0ZSBjdXJyZW50IHZpZXcgcm93IG51bWJlciB0byBo
aXN0b3J5IHJvdy4gKi8NCnN0YXRpYyBpbnQNCnZ0YnVmX3d0aChjb25zdCBzdHJ1Y3QgdnRfYnVm
ICp2YiwgaW50IHJvdykNCnsNCg0KCXJldHVybiAoKHZiLT52Yl9yb2Zmc2V0ICsgcm93KSAlIHZi
LT52Yl9oaXN0b3J5X3NpemUpOw0KfQ0KDQovKg0KICogVGVzdCBpZiBhbiBpbmRleCBpbiBhIGNp
cmN1bGFyIGJ1ZmZlciBpcyB3aXRoaW4gYSByYW5nZS4NCiAqDQogKiBiZWdpbiAtIHN0YXJ0IGlu
ZGV4DQogKiBlbmQgLSBlbmQgaW5kZXgNCiAqIHRlc3QgLSB0ZXN0IGluZGV4DQogKiBzeiAtIHNp
emUgb2YgY2lyY3VsYXIgYnVmZmVyIHdoZW4gaXQgdHVybnMgb3Zlcg0KICovDQpzdGF0aWMgaW50
DQp2dGJ1Zl9pbl90aGlzX3JhbmdlKGludCBiZWdpbiwgaW50IHRlc3QsIGludCBlbmQsIGludCBz
eikNCnsNCg0KCWJlZ2luICU9IHN6Ow0KCWVuZCAlPSBzejsNCg0KCS8qIGNoZWNrIGZvciBpbnZl
cnNpb24gKi8NCglpZiAoYmVnaW4gPiBlbmQpDQoJCXJldHVybiAodGVzdCA+PSBiZWdpbiB8fCB0
ZXN0IDwgZW5kKTsNCgllbHNlDQoJCXJldHVybiAodGVzdCA+PSBiZWdpbiAmJiB0ZXN0IDwgZW5k
KTsNCn0NCiNlbmRpZg0KDQppbnQNCnZ0YnVmX2lzY3Vyc29yKGNvbnN0IHN0cnVjdCB2dF9idWYg
KnZiLCBpbnQgcm93LCBpbnQgY29sKQ0Kew0KI2lmbmRlZiBTQ19OT19DVVRQQVNURQ0KCWludCBz
Yywgc3IsIHN6LCBlYywgZXIsIHRtcDsNCiNlbmRpZg0KDQoJaWYgKCh2Yi0+dmJfZmxhZ3MgJiAo
VkJGX0NVUlNPUnxWQkZfU0NST0xMKSkgPT0gVkJGX0NVUlNPUiAmJg0KCSAgICAodmItPnZiX2N1
cnNvci50cF9yb3cgPT0gcm93KSAmJiAodmItPnZiX2N1cnNvci50cF9jb2wgPT0gY29sKSkNCgkJ
cmV0dXJuICgxKTsNCg0KI2lmbmRlZiBTQ19OT19DVVRQQVNURQ0KCS8qIE1hcmsgY3V0L3Bhc3Rl
IHJlZ2lvbi4gKi8NCglpZiAodmItPnZiX21hcmtfc3RhcnQudHBfY29sID09IHZiLT52Yl9tYXJr
X2VuZC50cF9jb2wgJiYNCgkgICAgdmItPnZiX21hcmtfc3RhcnQudHBfcm93ID09IHZiLT52Yl9t
YXJrX2VuZC50cF9yb3cpDQoJCXJldHVybiAoMCk7DQoNCglzYyA9IHZiLT52Yl9tYXJrX3N0YXJ0
LnRwX2NvbDsNCglzciA9IHZiLT52Yl9tYXJrX3N0YXJ0LnRwX3JvdzsNCgllYyA9IHZiLT52Yl9t
YXJrX2VuZC50cF9jb2w7DQoJZXIgPSB2Yi0+dmJfbWFya19lbmQudHBfcm93Ow0KDQoJLyoNCgkg
KiBJbmZvcm1hdGlvbiBhYm91dCBpZiB0aGUgc2VsZWN0aW9uIHdhcyBtYWRlIGJvdHRvbS10b3Ag
b3INCgkgKiB0b3AtYm90dG9tIGlzIGxvc3QgZHVlIHRvIG1vZHVsbyBhcml0aG1ldGljcyBhbmQg
bmVlZHMgdG8NCgkgKiBiZSByZWNvdmVyZWQ6DQoJICovDQoJc3ogPSB2Yi0+dmJfaGlzdG9yeV9z
aXplOw0KCXRtcCA9IChzeiArIGVyIC0gc3IpICUgc3o7DQoJcm93ID0gdnRidWZfd3RoKHZiLCBy
b3cpOw0KDQoJLyogU3dhcCBzdGFydCBhbmQgZW5kIGlmIHN0YXJ0ID4gZW5kICovDQoJaWYgKCgy
ICogdG1wKSA+IHN6IHx8ICh0bXAgPT0gMCAmJiBzYyA+IGVjKSkgew0KCQl0bXAgPSBzYzsgc2Mg
PSBlYzsgZWMgPSB0bXA7DQoJCXRtcCA9IHNyOyBzciA9IGVyOyBlciA9IHRtcDsNCgl9DQoNCglp
ZiAodnRidWZfaW5fdGhpc19yYW5nZShQT1NfSU5ERVgoc2MsIHNyKSwgUE9TX0lOREVYKGNvbCwg
cm93KSwNCgkgICAgUE9TX0lOREVYKGVjLCBlciksIFBPU19JTkRFWCgwLCBzeikpKQ0KCQlyZXR1
cm4gKDEpOw0KI2VuZGlmDQoNCglyZXR1cm4gKDApOw0KfQ0KDQp2b2lkDQp2dGJ1Zl9sb2NrKHN0
cnVjdCB2dF9idWYgKnZiKQ0Kew0KDQoJVlRCVUZfTE9DSyh2Yik7DQp9DQoNCnZvaWQNCnZ0YnVm
X3VubG9jayhzdHJ1Y3QgdnRfYnVmICp2YikNCnsNCg0KCVZUQlVGX1VOTE9DSyh2Yik7DQp9DQoN
CnZvaWQNCnZ0YnVmX2RpcnR5KHN0cnVjdCB2dF9idWYgKnZiLCBjb25zdCB0ZXJtX3JlY3RfdCAq
YXJlYSkNCnsNCg0KCWlmICh2Yi0+dmJfZGlydHlyZWN0LnRyX2JlZ2luLnRwX3JvdyA+IGFyZWEt
PnRyX2JlZ2luLnRwX3JvdykNCgkJdmItPnZiX2RpcnR5cmVjdC50cl9iZWdpbi50cF9yb3cgPSBh
cmVhLT50cl9iZWdpbi50cF9yb3c7DQoJaWYgKHZiLT52Yl9kaXJ0eXJlY3QudHJfYmVnaW4udHBf
Y29sID4gYXJlYS0+dHJfYmVnaW4udHBfY29sKQ0KCQl2Yi0+dmJfZGlydHlyZWN0LnRyX2JlZ2lu
LnRwX2NvbCA9IGFyZWEtPnRyX2JlZ2luLnRwX2NvbDsNCglpZiAodmItPnZiX2RpcnR5cmVjdC50
cl9lbmQudHBfcm93IDwgYXJlYS0+dHJfZW5kLnRwX3JvdykNCgkJdmItPnZiX2RpcnR5cmVjdC50
cl9lbmQudHBfcm93ID0gYXJlYS0+dHJfZW5kLnRwX3JvdzsNCglpZiAodmItPnZiX2RpcnR5cmVj
dC50cl9lbmQudHBfY29sIDwgYXJlYS0+dHJfZW5kLnRwX2NvbCkNCgkJdmItPnZiX2RpcnR5cmVj
dC50cl9lbmQudHBfY29sID0gYXJlYS0+dHJfZW5kLnRwX2NvbDsNCn0NCg0Kc3RhdGljIGlubGlu
ZSB2b2lkDQp2dGJ1Zl9kaXJ0eV9jZWxsKHN0cnVjdCB2dF9idWYgKnZiLCBjb25zdCB0ZXJtX3Bv
c190ICpwKQ0Kew0KCXRlcm1fcmVjdF90IGFyZWE7DQoNCglhcmVhLnRyX2JlZ2luID0gKnA7DQoJ
YXJlYS50cl9lbmQudHBfcm93ID0gcC0+dHBfcm93ICsgMTsNCglhcmVhLnRyX2VuZC50cF9jb2wg
PSBwLT50cF9jb2wgKyAxOw0KCXZ0YnVmX2RpcnR5KHZiLCAmYXJlYSk7DQp9DQoNCnN0YXRpYyB2
b2lkDQp2dGJ1Zl9tYWtlX3VuZGlydHkoc3RydWN0IHZ0X2J1ZiAqdmIpDQp7DQoNCgl2Yi0+dmJf
ZGlydHlyZWN0LnRyX2JlZ2luID0gdmItPnZiX3Njcl9zaXplOw0KCXZiLT52Yl9kaXJ0eXJlY3Qu
dHJfZW5kLnRwX3JvdyA9IHZiLT52Yl9kaXJ0eXJlY3QudHJfZW5kLnRwX2NvbCA9IDA7DQp9DQoN
CnZvaWQNCnZ0YnVmX3VuZGlydHkoc3RydWN0IHZ0X2J1ZiAqdmIsIHRlcm1fcmVjdF90ICpyKQ0K
ew0KDQoJKnIgPSB2Yi0+dmJfZGlydHlyZWN0Ow0KCXZ0YnVmX21ha2VfdW5kaXJ0eSh2Yik7DQp9
DQoNCnZvaWQNCnZ0YnVmX2NvcHkoc3RydWN0IHZ0X2J1ZiAqdmIsIGNvbnN0IHRlcm1fcmVjdF90
ICpyLCBjb25zdCB0ZXJtX3Bvc190ICpwMikNCnsNCgljb25zdCB0ZXJtX3Bvc190ICpwMSA9ICZy
LT50cl9iZWdpbjsNCgl0ZXJtX3JlY3RfdCBhcmVhOw0KCXVuc2lnbmVkIGludCByb3dzLCBjb2xz
Ow0KCWludCBwciwgcmRpZmY7DQoNCglLQVNTRVJUKHItPnRyX2JlZ2luLnRwX3JvdyA8IHZiLT52
Yl9zY3Jfc2l6ZS50cF9yb3csDQoJICAgICgidnRidWZfY29weSBiZWdpbi50cF9yb3cgJWQgbXVz
dCBiZSBsZXNzIHRoYW4gc2NyZWVuIHdpZHRoICVkIiwNCgkJci0+dHJfYmVnaW4udHBfcm93LCB2
Yi0+dmJfc2NyX3NpemUudHBfcm93KSk7DQoJS0FTU0VSVChyLT50cl9iZWdpbi50cF9jb2wgPCB2
Yi0+dmJfc2NyX3NpemUudHBfY29sLA0KCSAgICAoInZ0YnVmX2NvcHkgYmVnaW4udHBfY29sICVk
IG11c3QgYmUgbGVzcyB0aGFuIHNjcmVlbiBoZWlnaHQgJWQiLA0KCQlyLT50cl9iZWdpbi50cF9j
b2wsIHZiLT52Yl9zY3Jfc2l6ZS50cF9jb2wpKTsNCg0KCUtBU1NFUlQoci0+dHJfZW5kLnRwX3Jv
dyA8PSB2Yi0+dmJfc2NyX3NpemUudHBfcm93LA0KCSAgICAoInZ0YnVmX2NvcHkgZW5kLnRwX3Jv
dyAlZCBtdXN0IGJlIGxlc3MgdGhhbiBzY3JlZW4gd2lkdGggJWQiLA0KCQlyLT50cl9lbmQudHBf
cm93LCB2Yi0+dmJfc2NyX3NpemUudHBfcm93KSk7DQoJS0FTU0VSVChyLT50cl9lbmQudHBfY29s
IDw9IHZiLT52Yl9zY3Jfc2l6ZS50cF9jb2wsDQoJICAgICgidnRidWZfY29weSBlbmQudHBfY29s
ICVkIG11c3QgYmUgbGVzcyB0aGFuIHNjcmVlbiBoZWlnaHQgJWQiLA0KCQlyLT50cl9lbmQudHBf
Y29sLCB2Yi0+dmJfc2NyX3NpemUudHBfY29sKSk7DQoNCglLQVNTRVJUKHAyLT50cF9yb3cgPCB2
Yi0+dmJfc2NyX3NpemUudHBfcm93LA0KCSAgICAoInZ0YnVmX2NvcHkgdHBfcm93ICVkIG11c3Qg
YmUgbGVzcyB0aGFuIHNjcmVlbiB3aWR0aCAlZCIsDQoJCXAyLT50cF9yb3csIHZiLT52Yl9zY3Jf
c2l6ZS50cF9yb3cpKTsNCglLQVNTRVJUKHAyLT50cF9jb2wgPCB2Yi0+dmJfc2NyX3NpemUudHBf
Y29sLA0KCSAgICAoInZ0YnVmX2NvcHkgdHBfY29sICVkIG11c3QgYmUgbGVzcyB0aGFuIHNjcmVl
biBoZWlnaHQgJWQiLA0KCQlwMi0+dHBfY29sLCB2Yi0+dmJfc2NyX3NpemUudHBfY29sKSk7DQoN
Cglyb3dzID0gci0+dHJfZW5kLnRwX3JvdyAtIHItPnRyX2JlZ2luLnRwX3JvdzsNCglyZGlmZiA9
IHItPnRyX2JlZ2luLnRwX3JvdyAtIHAyLT50cF9yb3c7DQoJY29scyA9IHItPnRyX2VuZC50cF9j
b2wgLSByLT50cl9iZWdpbi50cF9jb2w7DQoJaWYgKHItPnRyX2JlZ2luLnRwX3JvdyA+IHAyLT50
cF9yb3cgJiYgci0+dHJfYmVnaW4udHBfY29sID09IDAgJiYNCgkgICAgci0+dHJfZW5kLnRwX2Nv
bCA9PSB2Yi0+dmJfc2NyX3NpemUudHBfY29sICYmIC8qIEZ1bGwgcm93LiAqLw0KCSAgICAocm93
cyArIHJkaWZmKSA9PSB2Yi0+dmJfc2NyX3NpemUudHBfcm93ICYmIC8qIFdob2xlIHNjcmVlbi4g
Ki8NCgkgICAgcmRpZmYgPiAwKSB7IC8qIE9ubHkgZm9yd2FyZCBkaXJlY3Rpb24uIERvIG5vdCBl
YXQgaGlzdG9yeS4gKi8NCgkJdnRoaXN0b3J5X2FkZGxpbmVzKHZiLCByZGlmZik7DQoJfSBlbHNl
IGlmIChwMi0+dHBfcm93IDwgcDEtPnRwX3Jvdykgew0KCQkvKiBIYW5kbGUgb3ZlcmxhcHBpbmcg
Y29waWVzIG9mIGxpbmUgc2VnbWVudHMuICovDQoJCS8qIE1vdmUgZGF0YSB1cC4gKi8NCgkJZm9y
IChwciA9IDA7IHByIDwgcm93czsgcHIrKykNCgkJCW1lbW1vdmUoDQoJCQkgICAgJlZUQlVGX0ZJ
RUxEKHZiLCBwMi0+dHBfcm93ICsgcHIsIHAyLT50cF9jb2wpLA0KCQkJICAgICZWVEJVRl9GSUVM
RCh2YiwgcDEtPnRwX3JvdyArIHByLCBwMS0+dHBfY29sKSwNCgkJCSAgICBjb2xzICogc2l6ZW9m
KHRlcm1fY2hhcl90KSk7DQoJfSBlbHNlIHsNCgkJLyogTW92ZSBkYXRhIGRvd24uICovDQoJCWZv
ciAocHIgPSByb3dzIC0gMTsgcHIgPj0gMDsgcHItLSkNCgkJCW1lbW1vdmUoDQoJCQkgICAgJlZU
QlVGX0ZJRUxEKHZiLCBwMi0+dHBfcm93ICsgcHIsIHAyLT50cF9jb2wpLA0KCQkJICAgICZWVEJV
Rl9GSUVMRCh2YiwgcDEtPnRwX3JvdyArIHByLCBwMS0+dHBfY29sKSwNCgkJCSAgICBjb2xzICog
c2l6ZW9mKHRlcm1fY2hhcl90KSk7DQoJfQ0KDQoJYXJlYS50cl9iZWdpbiA9ICpwMjsNCglhcmVh
LnRyX2VuZC50cF9yb3cgPSBNSU4ocDItPnRwX3JvdyArIHJvd3MsIHZiLT52Yl9zY3Jfc2l6ZS50
cF9yb3cpOw0KCWFyZWEudHJfZW5kLnRwX2NvbCA9IE1JTihwMi0+dHBfY29sICsgY29scywgdmIt
PnZiX3Njcl9zaXplLnRwX2NvbCk7DQoJdnRidWZfZGlydHkodmIsICZhcmVhKTsNCn0NCg0Kc3Rh
dGljIHZvaWQNCnZ0YnVmX2RvX2ZpbGwoc3RydWN0IHZ0X2J1ZiAqdmIsIGNvbnN0IHRlcm1fcmVj
dF90ICpyLCB0ZXJtX2NoYXJfdCBjKQ0Kew0KCXVuc2lnbmVkIGludCBwciwgcGM7DQoJdGVybV9j
aGFyX3QgKnJvdzsNCg0KCWZvciAocHIgPSByLT50cl9iZWdpbi50cF9yb3c7IHByIDwgci0+dHJf
ZW5kLnRwX3JvdzsgcHIrKykgew0KCQlyb3cgPSB2Yi0+dmJfcm93c1sodmItPnZiX2N1cnJvZmZz
ZXQgKyBwcikgJQ0KCQkgICAgVlRCVUZfTUFYX0hFSUdIVCh2YildOw0KCQlmb3IgKHBjID0gci0+
dHJfYmVnaW4udHBfY29sOyBwYyA8IHItPnRyX2VuZC50cF9jb2w7IHBjKyspIHsNCgkJCXJvd1tw
Y10gPSBjOw0KCQl9DQoJfQ0KfQ0KDQp2b2lkDQp2dGJ1Zl9maWxsKHN0cnVjdCB2dF9idWYgKnZi
LCBjb25zdCB0ZXJtX3JlY3RfdCAqciwgdGVybV9jaGFyX3QgYykNCnsNCg0KCUtBU1NFUlQoci0+
dHJfYmVnaW4udHBfcm93IDwgdmItPnZiX3Njcl9zaXplLnRwX3JvdywNCgkgICAgKCJ2dGJ1Zl9m
aWxsIGJlZ2luLnRwX3JvdyAlZCBtdXN0IGJlIDwgc2NyZWVuIGhlaWdodCAlZCIsDQoJCXItPnRy
X2JlZ2luLnRwX3JvdywgdmItPnZiX3Njcl9zaXplLnRwX3JvdykpOw0KCUtBU1NFUlQoci0+dHJf
YmVnaW4udHBfY29sIDwgdmItPnZiX3Njcl9zaXplLnRwX2NvbCwNCgkgICAgKCJ2dGJ1Zl9maWxs
IGJlZ2luLnRwX2NvbCAlZCBtdXN0IGJlIDwgc2NyZWVuIHdpZHRoICVkIiwNCgkJci0+dHJfYmVn
aW4udHBfY29sLCB2Yi0+dmJfc2NyX3NpemUudHBfY29sKSk7DQoNCglLQVNTRVJUKHItPnRyX2Vu
ZC50cF9yb3cgPD0gdmItPnZiX3Njcl9zaXplLnRwX3JvdywNCgkgICAgKCJ2dGJ1Zl9maWxsIGVu
ZC50cF9yb3cgJWQgbXVzdCBiZSA8PSBzY3JlZW4gaGVpZ2h0ICVkIiwNCgkJci0+dHJfZW5kLnRw
X3JvdywgdmItPnZiX3Njcl9zaXplLnRwX3JvdykpOw0KCUtBU1NFUlQoci0+dHJfZW5kLnRwX2Nv
bCA8PSB2Yi0+dmJfc2NyX3NpemUudHBfY29sLA0KCSAgICAoInZ0YnVmX2ZpbGwgZW5kLnRwX2Nv
bCAlZCBtdXN0IGJlIDw9IHNjcmVlbiB3aWR0aCAlZCIsDQoJCXItPnRyX2VuZC50cF9jb2wsIHZi
LT52Yl9zY3Jfc2l6ZS50cF9jb2wpKTsNCg0KCXZ0YnVmX2RvX2ZpbGwodmIsIHIsIGMpOw0KCXZ0
YnVmX2RpcnR5KHZiLCByKTsNCn0NCg0Kc3RhdGljIHZvaWQNCnZ0YnVmX2luaXRfcm93cyhzdHJ1
Y3QgdnRfYnVmICp2YikNCnsNCglpbnQgcjsNCg0KCXZiLT52Yl9oaXN0b3J5X3NpemUgPSBNQVgo
dmItPnZiX2hpc3Rvcnlfc2l6ZSwgdmItPnZiX3Njcl9zaXplLnRwX3Jvdyk7DQoNCglmb3IgKHIg
PSAwOyByIDwgdmItPnZiX2hpc3Rvcnlfc2l6ZTsgcisrKQ0KCQl2Yi0+dmJfcm93c1tyXSA9ICZ2
Yi0+dmJfYnVmZmVyW3IgKiB2Yi0+dmJfc2NyX3NpemUudHBfY29sXTsNCn0NCg0Kc3RhdGljIHZv
aWQNCnZ0YnVmX2RvX2NsZWFyaGlzdG9yeShzdHJ1Y3QgdnRfYnVmICp2YikNCnsNCgl0ZXJtX3Jl
Y3RfdCByZWN0Ow0KCWNvbnN0IHRla2VuX2F0dHJfdCAqYTsNCgl0ZXJtX2NoYXJfdCBjaDsNCg0K
CWEgPSB0ZWtlbl9nZXRfY3VyYXR0cigmdmItPnZiX3Rlcm1pbmFsLT50bV9lbXVsYXRvcik7DQoJ
Y2ggPSBUQ09MT1JfRkcoYS0+dGFfZmdjb2xvcikgfCBUQ09MT1JfQkcoYS0+dGFfYmdjb2xvcik7
DQoNCglyZWN0LnRyX2JlZ2luLnRwX3JvdyA9IHJlY3QudHJfYmVnaW4udHBfY29sID0gMDsNCgly
ZWN0LnRyX2VuZC50cF9jb2wgPSB2Yi0+dmJfc2NyX3NpemUudHBfY29sOw0KCXJlY3QudHJfZW5k
LnRwX3JvdyA9IHZiLT52Yl9oaXN0b3J5X3NpemU7DQoNCgl2dGJ1Zl9kb19maWxsKHZiLCAmcmVj
dCwgVlRCVUZfU1BBQ0VfQ0hBUihjaCkpOw0KfQ0KDQpzdGF0aWMgdm9pZA0KdnRidWZfcmVzZXRf
c2Nyb2xsYmFjayhzdHJ1Y3QgdnRfYnVmICp2YikNCnsNCgl2Yi0+dmJfcm9mZnNldCA9IDA7DQoJ
dmItPnZiX2N1cnJvZmZzZXQgPSAwOw0KCXZiLT52Yl9tYXJrX3N0YXJ0LnRwX3JvdyA9IDA7DQoJ
dmItPnZiX21hcmtfc3RhcnQudHBfY29sID0gMDsNCgl2Yi0+dmJfbWFya19lbmQudHBfcm93ID0g
MDsNCgl2Yi0+dmJfbWFya19lbmQudHBfY29sID0gMDsNCn0NCg0Kdm9pZA0KdnRidWZfaW5pdF9l
YXJseShzdHJ1Y3QgdnRfYnVmICp2YikNCnsNCgl2Yi0+dmJfZmxhZ3MgfD0gVkJGX0NVUlNPUjsN
Cgl2dGJ1Zl9yZXNldF9zY3JvbGxiYWNrKHZiKTsNCgl2dGJ1Zl9pbml0X3Jvd3ModmIpOw0KCXZ0
YnVmX2RvX2NsZWFyaGlzdG9yeSh2Yik7DQoJdnRidWZfbWFrZV91bmRpcnR5KHZiKTsNCglpZiAo
KHZiLT52Yl9mbGFncyAmIFZCRl9NVFhfSU5JVCkgPT0gMCkgew0KCQltdHhfaW5pdCgmdmItPnZi
X2xvY2ssICJ2dGJ1ZiIsIE5VTEwsIE1UWF9TUElOKTsNCgkJdmItPnZiX2ZsYWdzIHw9IFZCRl9N
VFhfSU5JVDsNCgl9DQp9DQoNCnZvaWQNCnZ0YnVmX2luaXQoc3RydWN0IHZ0X2J1ZiAqdmIsIGNv
bnN0IHRlcm1fcG9zX3QgKnApDQp7DQoJaW50IHN6Ow0KDQoJdmItPnZiX3Njcl9zaXplID0gKnA7
DQoJdmItPnZiX2hpc3Rvcnlfc2l6ZSA9IFZCRl9ERUZBVUxUX0hJU1RPUllfU0laRTsNCg0KCWlm
ICgodmItPnZiX2ZsYWdzICYgVkJGX1NUQVRJQykgPT0gMCkgew0KCQlzeiA9IHZiLT52Yl9oaXN0
b3J5X3NpemUgKiBwLT50cF9jb2wgKiBzaXplb2YodGVybV9jaGFyX3QpOw0KCQl2Yi0+dmJfYnVm
ZmVyID0gbWFsbG9jKHN6LCBNX1ZUQlVGLCBNX1dBSVRPSyB8IE1fWkVSTyk7DQoNCgkJc3ogPSB2
Yi0+dmJfaGlzdG9yeV9zaXplICogc2l6ZW9mKHRlcm1fY2hhcl90ICopOw0KCQl2Yi0+dmJfcm93
cyA9IG1hbGxvYyhzeiwgTV9WVEJVRiwgTV9XQUlUT0sgfCBNX1pFUk8pOw0KCX0NCg0KCXZ0YnVm
X2luaXRfZWFybHkodmIpOw0KfQ0KDQp2b2lkDQp2dGJ1Zl9jbGVhcmhpc3Rvcnkoc3RydWN0IHZ0
X2J1ZiAqdmIpDQp7DQoJVlRCVUZfTE9DSyh2Yik7DQoJdnRidWZfZG9fY2xlYXJoaXN0b3J5KHZi
KTsNCgl2dGJ1Zl9yZXNldF9zY3JvbGxiYWNrKHZiKTsNCgl2Yi0+dmJfZmxhZ3MgJj0gflZCRl9I
SVNUT1JZX0ZVTEw7DQoJVlRCVUZfVU5MT0NLKHZiKTsNCn0NCg0Kdm9pZA0KdnRidWZfc2V0aGlz
dG9yeV9zaXplKHN0cnVjdCB2dF9idWYgKnZiLCB1bnNpZ25lZCBpbnQgc2l6ZSkNCnsNCgl0ZXJt
X3Bvc190IHA7DQoNCgkvKiBXaXRoIHNhbWUgc2l6ZSAqLw0KCXAudHBfcm93ID0gdmItPnZiX3Nj
cl9zaXplLnRwX3JvdzsNCglwLnRwX2NvbCA9IHZiLT52Yl9zY3Jfc2l6ZS50cF9jb2w7DQoJdnRi
dWZfZ3Jvdyh2YiwgJnAsIHNpemUpOw0KfQ0KDQp2b2lkDQp2dGJ1Zl9ncm93KHN0cnVjdCB2dF9i
dWYgKnZiLCBjb25zdCB0ZXJtX3Bvc190ICpwLCB1bnNpZ25lZCBpbnQgaGlzdG9yeV9zaXplKQ0K
ew0KCXRlcm1fY2hhcl90ICpvbGQsICpuZXcsICoqcm93cywgKipvbGRyb3dzLCAqKmNvcHlyb3dz
LCAqcm93LCAqb2xkcm93Ow0KCXVuc2lnbmVkIGludCB3LCBoLCBjLCByLCBvbGRfaGlzdG9yeV9z
aXplOw0KCXNpemVfdCBidWZzaXplLCByb3dzc2l6ZTsNCglpbnQgaGlzdG9yeV9mdWxsOw0KCWNv
bnN0IHRla2VuX2F0dHJfdCAqYTsNCgl0ZXJtX2NoYXJfdCBjaDsNCg0KCWEgPSB0ZWtlbl9nZXRf
Y3VyYXR0cigmdmItPnZiX3Rlcm1pbmFsLT50bV9lbXVsYXRvcik7DQoJY2ggPSBUQ09MT1JfRkco
YS0+dGFfZmdjb2xvcikgfCBUQ09MT1JfQkcoYS0+dGFfYmdjb2xvcik7DQoNCgloaXN0b3J5X3Np
emUgPSBNQVgoaGlzdG9yeV9zaXplLCBwLT50cF9yb3cpOw0KDQoJLyogQWxsb2NhdGUgbmV3IGJ1
ZmZlci4gKi8NCglidWZzaXplID0gaGlzdG9yeV9zaXplICogcC0+dHBfY29sICogc2l6ZW9mKHRl
cm1fY2hhcl90KTsNCgluZXcgPSBtYWxsb2MoYnVmc2l6ZSwgTV9WVEJVRiwgTV9XQUlUT0sgfCBN
X1pFUk8pOw0KCXJvd3NzaXplID0gaGlzdG9yeV9zaXplICogc2l6ZW9mKHRlcm1fcG9zX3QgKik7
DQoJcm93cyA9IG1hbGxvYyhyb3dzc2l6ZSwgTV9WVEJVRiwgTV9XQUlUT0sgfCBNX1pFUk8pOw0K
DQoJLyogVG9nZ2xlIGl0LiAqLw0KCVZUQlVGX0xPQ0sodmIpOw0KCW9sZCA9IHZiLT52Yl9mbGFn
cyAmIFZCRl9TVEFUSUMgPyBOVUxMIDogdmItPnZiX2J1ZmZlcjsNCglvbGRyb3dzID0gdmItPnZi
X2ZsYWdzICYgVkJGX1NUQVRJQyA/IE5VTEwgOiB2Yi0+dmJfcm93czsNCgljb3B5cm93cyA9IHZi
LT52Yl9yb3dzOw0KDQoJdyA9IHZiLT52Yl9zY3Jfc2l6ZS50cF9jb2w7DQoJaCA9IHZiLT52Yl9z
Y3Jfc2l6ZS50cF9yb3c7DQoJb2xkX2hpc3Rvcnlfc2l6ZSA9IHZiLT52Yl9oaXN0b3J5X3NpemU7
DQoJaGlzdG9yeV9mdWxsID0gdmItPnZiX2ZsYWdzICYgVkJGX0hJU1RPUllfRlVMTCB8fA0KCSAg
ICB2Yi0+dmJfY3Vycm9mZnNldCArIGggPj0gaGlzdG9yeV9zaXplOw0KDQoJdmItPnZiX2hpc3Rv
cnlfc2l6ZSA9IGhpc3Rvcnlfc2l6ZTsNCgl2Yi0+dmJfYnVmZmVyID0gbmV3Ow0KCXZiLT52Yl9y
b3dzID0gcm93czsNCgl2Yi0+dmJfZmxhZ3MgJj0gflZCRl9TVEFUSUM7DQoJdmItPnZiX3Njcl9z
aXplID0gKnA7DQoJdnRidWZfaW5pdF9yb3dzKHZiKTsNCg0KCS8qDQoJICogQ29weSByb3dzIHRv
IHRoZSBuZXcgYnVmZmVyLiBUaGUgZmlyc3Qgcm93IGluIHRoZSBoaXN0b3J5DQoJICogaXMgYmFj
ayB0byBpbmRleCAwLCBpZS4gdGhlIG5ldyBidWZmZXIgZG9lc24ndCBjeWNsZS4NCgkgKi8NCglp
ZiAoaGlzdG9yeV9zaXplID4gb2xkX2hpc3Rvcnlfc2l6ZSkgew0KCQlmb3IgKHIgPSAwOyByIDwg
b2xkX2hpc3Rvcnlfc2l6ZTsgcisrKSB7DQoJCQlyb3cgPSByb3dzW3JdOw0KDQoJCQkvKiBDb21w
dXRlIHRoZSBjb3JyZXNwb25kaW5nIHJvdyBpbiB0aGUgb2xkIGJ1ZmZlci4gKi8NCgkJCWlmICho
aXN0b3J5X2Z1bGwpDQoJCQkJLyoNCgkJCQkgKiBUaGUgYnVmZmVyIGlzIGZ1bGwsIHRoZSAidG9w
IiByb3cgaXMNCgkJCQkgKiB0aGUgb25lIGp1c3QgYWZ0ZXIgdGhlIHZpZXdhYmxlIGFyZWENCgkJ
CQkgKiAoY3Vycm9mZnNldCArIHZpZXdhYmxlIGhlaWdodCkgaW4gdGhlDQoJCQkJICogY3ljbGlu
ZyBidWZmZXIuIFRoZSBjb3JyZXNwb25kaW5nIHJvdw0KCQkJCSAqIGlzIGNvbXB1dGVkIGZyb20g
dGhpcyB0b3Agcm93Lg0KCQkJCSAqLw0KCQkJCW9sZHJvdyA9IGNvcHlyb3dzWw0KCQkJCSAgICAo
dmItPnZiX2N1cnJvZmZzZXQgKyBoICsgcikgJQ0KCQkJCSAgICBvbGRfaGlzdG9yeV9zaXplXTsN
CgkJCWVsc2UNCgkJCQkvKg0KCQkJCSAqIFRoZSBidWZmZXIgaXMgbm90IGZ1bGwsIHRoZXJlZm9y
ZSwNCgkJCQkgKiB3ZSBkaWRuJ3QgY3ljbGUgYWxyZWFkeS4gVGhlDQoJCQkJICogY29ycmVzcG9u
ZGluZyByb3dzIGFyZSB0aGUgc2FtZSBpbg0KCQkJCSAqIGJvdGggYnVmZmVycy4NCgkJCQkgKi8N
CgkJCQlvbGRyb3cgPSBjb3B5cm93c1tyXTsNCg0KCQkJbWVtbW92ZShyb3csIG9sZHJvdywNCgkJ
CSAgICBNSU4ocC0+dHBfY29sLCB3KSAqIHNpemVvZih0ZXJtX2NoYXJfdCkpOw0KDQoJCQkvKg0K
CQkJICogWFhYIFZUQlVGX1NQQUNFX0NIQVIoVEVSTUlOQUxfTk9STV9BVFRSKSB3aWxsDQoJCQkg
KiBleHRlbmRlZCBsaW5lcyBvZiBrZXJuZWwgdGV4dCB1c2luZyB0aGUgd3JvbmcNCgkJCSAqIGJh
Y2tncm91bmQgY29sb3IuDQoJCQkgKi8NCgkJCWZvciAoYyA9IE1JTihwLT50cF9jb2wsIHcpOyBj
IDwgcC0+dHBfY29sOyBjKyspIHsNCgkJCQlyb3dbY10gPSBWVEJVRl9TUEFDRV9DSEFSKGNoKTsN
CgkJCX0NCgkJfQ0KDQoJCS8qIEZpbGwgcmVtYWluaW5nIHJvd3MuICovDQoJCWZvciAociA9IG9s
ZF9oaXN0b3J5X3NpemU7IHIgPCBoaXN0b3J5X3NpemU7IHIrKykgew0KCQkJcm93ID0gcm93c1ty
XTsNCgkJCWZvciAoYyA9IE1JTihwLT50cF9jb2wsIHcpOyBjIDwgcC0+dHBfY29sOyBjKyspIHsN
CgkJCQlyb3dbY10gPSBWVEJVRl9TUEFDRV9DSEFSKGNoKTsNCgkJCX0NCgkJfQ0KDQoJCXZiLT52
Yl9mbGFncyAmPSB+VkJGX0hJU1RPUllfRlVMTDsNCg0KCQkvKg0KCQkgKiBJZiB0aGUgc2NyZWVu
IGlzIGFscmVhZHkgZmlsbGVkICh0aGVyZSBhcmUgbm9uLXZpc2libGUgbGluZXMNCgkJICogYWJv
dmUgdGhlIGN1cnJlbnQgdmlld2FibGUgYXJlYSksIGFkanVzdCBjdXJyb2Zmc2V0IHRvIHRoZQ0K
CQkgKiBuZXcgdmlld2FibGUgYXJlYS4NCgkJICoNCgkJICogSWYgdGhlIG9sZCBidWZmZXIgd2Fz
IGZ1bGwsIHNldCBjdXJyb2Zmc2V0IHRvIHRoZQ0KCQkgKiA8aD50aCBtb3N0IHJlY2VudCBsaW5l
IG9mIGhpc3RvcnkgaW4gdGhlIG5ldywgbm9uLWN5Y2xlZA0KCQkgKiBidWZmZXIuIE90aGVyd2lz
ZSwgaXQgZGlkbid0IGN5Y2xlLCBzbyB0aGUgb2xkIGN1cnJvZmZzZXQNCgkJICogaXMgdGhlIHNh
bWUgaW4gdGhlIG5ldyBidWZmZXIuDQoJCSAqLw0KCQlpZiAoaGlzdG9yeV9mdWxsKQ0KCQkJdmIt
PnZiX2N1cnJvZmZzZXQgPSBvbGRfaGlzdG9yeV9zaXplIC0gaDsNCgl9IGVsc2Ugew0KCQkvKg0K
CQkgKiAob2xkX2hpc3Rvcnlfc2l6ZSAtIGhpc3Rvcnlfc2l6ZSkgbGluZXMgb2YgaGlzdG9yeSBh
cmUNCgkJICogZHJvcHBlZC4NCgkJICovDQoJCWZvciAociA9IDA7IHIgPCBoaXN0b3J5X3NpemU7
IHIrKykgew0KCQkJcm93ID0gcm93c1tyXTsNCg0KCQkJLyoNCgkJCSAqIENvbXB1dGUgdGhlIGNv
cnJlc3BvbmRpbmcgcm93IGluIHRoZSBvbGQgYnVmZmVyLg0KCQkJICoNCgkJCSAqIFNlZSB0aGUg
ZXF1aXZhbGVudCBpZnt9IGJsb2NrIGFib3ZlIGZvciBhbg0KCQkJICogZXhwbGFuYXRpb24uDQoJ
CQkgKi8NCgkJCWlmIChoaXN0b3J5X2Z1bGwpDQoJCQkJb2xkcm93ID0gY29weXJvd3NbDQoJCQkJ
ICAgICh2Yi0+dmJfY3Vycm9mZnNldCArIGggKyByICsNCgkJCQkgICAgIChvbGRfaGlzdG9yeV9z
aXplIC0gaGlzdG9yeV9zaXplKSkgJQ0KCQkJCSAgICBvbGRfaGlzdG9yeV9zaXplXTsNCgkJCWVs
c2UNCgkJCQlvbGRyb3cgPSBjb3B5cm93c1tyXTsNCg0KCQkJbWVtbW92ZShyb3csIG9sZHJvdywN
CgkJCSAgICBNSU4ocC0+dHBfY29sLCB3KSAqIHNpemVvZih0ZXJtX2NoYXJfdCkpOw0KDQoJCQkv
Kg0KCQkJICogWFhYIFZUQlVGX1NQQUNFX0NIQVIoVEVSTUlOQUxfTk9STV9BVFRSKSB3aWxsDQoJ
CQkgKiBleHRlbmRlZCBsaW5lcyBvZiBrZXJuZWwgdGV4dCB1c2luZyB0aGUgd3JvbmcNCgkJCSAq
IGJhY2tncm91bmQgY29sb3IuDQoJCQkgKi8NCgkJCWZvciAoYyA9IE1JTihwLT50cF9jb2wsIHcp
OyBjIDwgcC0+dHBfY29sOyBjKyspIHsNCgkJCQlyb3dbY10gPSBWVEJVRl9TUEFDRV9DSEFSKGNo
KTsNCgkJCX0NCgkJfQ0KDQoJCWlmIChoaXN0b3J5X2Z1bGwpIHsNCgkJCXZiLT52Yl9jdXJyb2Zm
c2V0ID0gaGlzdG9yeV9zaXplIC0gaDsNCgkJCXZiLT52Yl9mbGFncyB8PSBWQkZfSElTVE9SWV9G
VUxMOw0KCQl9DQoJfQ0KDQoJdmItPnZiX3JvZmZzZXQgPSB2Yi0+dmJfY3Vycm9mZnNldDsNCg0K
CS8qIEFkanVzdCBjdXJzb3IgcG9zaXRpb24uICovDQoJaWYgKHZiLT52Yl9jdXJzb3IudHBfY29s
ID4gcC0+dHBfY29sIC0gMSkNCgkJLyoNCgkJICogTW92ZSBjdXJzb3IgdG8gdGhlIGxhc3QgY29s
dW1uLCBpbiBjYXNlIGl0cyBwcmV2aW91cw0KCQkgKiBwb3NpdGlvbiBpcyBvdXRzaWRlIG9mIHRo
ZSBuZXcgc2NyZWVuIGFyZWEuDQoJCSAqLw0KCQl2Yi0+dmJfY3Vyc29yLnRwX2NvbCA9IHAtPnRw
X2NvbCAtIDE7DQoNCglpZiAodmItPnZiX2N1cnJvZmZzZXQgPiAwIHx8IHZiLT52Yl9jdXJzb3Iu
dHBfcm93ID4gcC0+dHBfcm93IC0gMSkNCgkJLyogTW92ZSBjdXJzb3IgdG8gdGhlIGxhc3QgbGlu
ZSBvbiB0aGUgc2NyZWVuLiAqLw0KCQl2Yi0+dmJfY3Vyc29yLnRwX3JvdyA9IHAtPnRwX3JvdyAt
IDE7DQoNCglWVEJVRl9VTkxPQ0sodmIpOw0KDQoJLyogRGVhbGxvY2F0ZSBvbGQgYnVmZmVyLiAq
Lw0KCWZyZWUob2xkLCBNX1ZUQlVGKTsNCglmcmVlKG9sZHJvd3MsIE1fVlRCVUYpOw0KfQ0KDQp2
b2lkDQp2dGJ1Zl9wdXRjaGFyKHN0cnVjdCB2dF9idWYgKnZiLCBjb25zdCB0ZXJtX3Bvc190ICpw
LCB0ZXJtX2NoYXJfdCBjKQ0Kew0KCXRlcm1fY2hhcl90ICpyb3c7DQoNCglLQVNTRVJUKHAtPnRw
X3JvdyA8IHZiLT52Yl9zY3Jfc2l6ZS50cF9yb3csDQoJICAgICgidnRidWZfcHV0Y2hhciB0cF9y
b3cgJWQgbXVzdCBiZSBsZXNzIHRoYW4gc2NyZWVuIHdpZHRoICVkIiwNCgkJcC0+dHBfcm93LCB2
Yi0+dmJfc2NyX3NpemUudHBfcm93KSk7DQoJS0FTU0VSVChwLT50cF9jb2wgPCB2Yi0+dmJfc2Ny
X3NpemUudHBfY29sLA0KCSAgICAoInZ0YnVmX3B1dGNoYXIgdHBfY29sICVkIG11c3QgYmUgbGVz
cyB0aGFuIHNjcmVlbiBoZWlnaHQgJWQiLA0KCQlwLT50cF9jb2wsIHZiLT52Yl9zY3Jfc2l6ZS50
cF9jb2wpKTsNCg0KCXJvdyA9IHZiLT52Yl9yb3dzWyh2Yi0+dmJfY3Vycm9mZnNldCArIHAtPnRw
X3JvdykgJQ0KCSAgICBWVEJVRl9NQVhfSEVJR0hUKHZiKV07DQoJaWYgKHJvd1twLT50cF9jb2xd
ICE9IGMpIHsNCgkJcm93W3AtPnRwX2NvbF0gPSBjOw0KCQl2dGJ1Zl9kaXJ0eV9jZWxsKHZiLCBw
KTsNCgl9DQp9DQoNCnZvaWQNCnZ0YnVmX2N1cnNvcl9wb3NpdGlvbihzdHJ1Y3QgdnRfYnVmICp2
YiwgY29uc3QgdGVybV9wb3NfdCAqcCkNCnsNCglpZiAodmItPnZiX2ZsYWdzICYgVkJGX0NVUlNP
Uikgew0KCQl2dGJ1Zl9kaXJ0eV9jZWxsKHZiLCAmdmItPnZiX2N1cnNvcik7DQoJCXZiLT52Yl9j
dXJzb3IgPSAqcDsNCgkJdnRidWZfZGlydHlfY2VsbCh2YiwgJnZiLT52Yl9jdXJzb3IpOw0KCX0g
ZWxzZSB7DQoJCXZiLT52Yl9jdXJzb3IgPSAqcDsNCgl9DQp9DQoNCiNpZm5kZWYgU0NfTk9fQ1VU
UEFTVEUNCnN0YXRpYyB2b2lkDQp2dGJ1Zl9mbHVzaF9tYXJrKHN0cnVjdCB2dF9idWYgKnZiKQ0K
ew0KCXRlcm1fcmVjdF90IGFyZWE7DQoJaW50IHMsIGU7DQoNCgkvKiBOb3RpZnkgcmVuZGVyZXIg
dG8gdXBkYXRlIG1hcmtlZCByZWdpb24uICovDQoJaWYgKCh2Yi0+dmJfbWFya19zdGFydC50cF9j
b2wgIT0gdmItPnZiX21hcmtfZW5kLnRwX2NvbCkgfHwNCgkgICAgKHZiLT52Yl9tYXJrX3N0YXJ0
LnRwX3JvdyAhPSB2Yi0+dmJfbWFya19lbmQudHBfcm93KSkgew0KCQlzID0gdnRidWZfaHR3KHZi
LCB2Yi0+dmJfbWFya19zdGFydC50cF9yb3cpOw0KCQllID0gdnRidWZfaHR3KHZiLCB2Yi0+dmJf
bWFya19lbmQudHBfcm93KTsNCg0KCQlhcmVhLnRyX2JlZ2luLnRwX2NvbCA9IDA7DQoJCWFyZWEu
dHJfYmVnaW4udHBfcm93ID0gTUlOKHMsIGUpOw0KDQoJCWFyZWEudHJfZW5kLnRwX2NvbCA9IHZi
LT52Yl9zY3Jfc2l6ZS50cF9jb2w7DQoJCWFyZWEudHJfZW5kLnRwX3JvdyA9IE1BWChzLCBlKSAr
IDE7DQoNCgkJVlRCVUZfTE9DSyh2Yik7DQoJCXZ0YnVmX2RpcnR5KHZiLCAmYXJlYSk7DQoJCVZU
QlVGX1VOTE9DSyh2Yik7DQoJfQ0KfQ0KDQppbnQNCnZ0YnVmX2dldF9tYXJrZWRfbGVuKHN0cnVj
dCB2dF9idWYgKnZiKQ0Kew0KCWludCBlaSwgc2ksIHN6Ow0KCXRlcm1fcG9zX3QgcywgZTsNCg0K
CS8qIFN3YXAgYWNjb3JkaW5nIHRvIHdpbmRvdyBjb29yZGluYXRlcy4gKi8NCglpZiAoUE9TX0lO
REVYKHZ0YnVmX2h0dyh2YiwgdmItPnZiX21hcmtfc3RhcnQudHBfcm93KSwNCgkgICAgdmItPnZi
X21hcmtfc3RhcnQudHBfY29sKSA+DQoJICAgIFBPU19JTkRFWCh2dGJ1Zl9odHcodmIsIHZiLT52
Yl9tYXJrX2VuZC50cF9yb3cpLA0KCSAgICB2Yi0+dmJfbWFya19lbmQudHBfY29sKSkgew0KCQlQ
T1NfQ09QWShlLCB2Yi0+dmJfbWFya19zdGFydCk7DQoJCVBPU19DT1BZKHMsIHZiLT52Yl9tYXJr
X2VuZCk7DQoJfSBlbHNlIHsNCgkJUE9TX0NPUFkocywgdmItPnZiX21hcmtfc3RhcnQpOw0KCQlQ
T1NfQ09QWShlLCB2Yi0+dmJfbWFya19lbmQpOw0KCX0NCg0KCXNpID0gcy50cF9yb3cgKiB2Yi0+
dmJfc2NyX3NpemUudHBfY29sICsgcy50cF9jb2w7DQoJZWkgPSBlLnRwX3JvdyAqIHZiLT52Yl9z
Y3Jfc2l6ZS50cF9jb2wgKyBlLnRwX2NvbDsNCg0KCS8qIE51bWJlciBzeW1ib2xzIGFuZCBudW1i
ZXIgb2Ygcm93cyB0byBpbmplY3QgXG4gKi8NCglzeiA9IGVpIC0gc2kgKyAoKGUudHBfcm93IC0g
cy50cF9yb3cpICogMik7DQoNCglyZXR1cm4gKHN6ICogc2l6ZW9mKHRlcm1fY2hhcl90KSk7DQp9
DQoNCnZvaWQNCnZ0YnVmX2V4dHJhY3RfbWFya2VkKHN0cnVjdCB2dF9idWYgKnZiLCB0ZXJtX2No
YXJfdCAqYnVmLCBpbnQgc3opDQp7DQoJaW50IGksIHIsIGMsIGNzLCBjZTsNCgl0ZXJtX3Bvc190
IHMsIGU7DQoJdGVybV9jaGFyX3QgKmVuZDsNCg0KCS8qIFN3YXAgYWNjb3JkaW5nIHRvIHdpbmRv
dyBjb29yZGluYXRlcy4gKi8NCglpZiAoUE9TX0lOREVYKHZ0YnVmX2h0dyh2YiwgdmItPnZiX21h
cmtfc3RhcnQudHBfcm93KSwNCgkgICAgdmItPnZiX21hcmtfc3RhcnQudHBfY29sKSA+DQoJICAg
IFBPU19JTkRFWCh2dGJ1Zl9odHcodmIsIHZiLT52Yl9tYXJrX2VuZC50cF9yb3cpLA0KCSAgICB2
Yi0+dmJfbWFya19lbmQudHBfY29sKSkgew0KCQlQT1NfQ09QWShlLCB2Yi0+dmJfbWFya19zdGFy
dCk7DQoJCVBPU19DT1BZKHMsIHZiLT52Yl9tYXJrX2VuZCk7DQoJfSBlbHNlIHsNCgkJUE9TX0NP
UFkocywgdmItPnZiX21hcmtfc3RhcnQpOw0KCQlQT1NfQ09QWShlLCB2Yi0+dmJfbWFya19lbmQp
Ow0KCX0NCg0KCWkgPSAwOw0KCWZvciAociA9IHMudHBfcm93OyByIDw9IGUudHBfcm93OyByKysp
IHsNCgkJY3MgPSAociA9PSBzLnRwX3Jvdyk/cy50cF9jb2w6MDsNCgkJY2UgPSAociA9PSBlLnRw
X3Jvdyk/ZS50cF9jb2w6dmItPnZiX3Njcl9zaXplLnRwX2NvbDsNCgkJZm9yIChjID0gY3M7IGMg
PCBjZTsgYysrKSB7DQoJCQlidWZbaSsrXSA9IHZiLT52Yl9yb3dzW3JdW2NdOw0KCQl9DQoJCWVu
ZCA9IGJ1ZiArIGkgLTE7DQoJCXdoaWxlIChlbmQgPiBidWYgJiYgaXNzcGFjZSgodW5zaWduZWQg
Y2hhcikqZW5kKSkNCgkJew0KCQkJKmVuZCA9ICdcMCc7DQoJCQllbmQtLTsNCgkJfQ0KDQoJCS8q
IEFkZCBuZXcgbGluZSBmb3IgYWxsIHJvd3MsIGJ1dCBub3QgZm9yIGxhc3Qgb25lLiAqLw0KCQlp
ZiAociAhPSBlLnRwX3Jvdykgew0KCQkJYnVmW2ldID0gJ1xyJzsNCgkJCWJ1ZltpKytdID0gJ1xu
JzsNCgkJCWJ1ZltpKytdID0gJ1wwJzsNCgkJfQ0KCX0NCn0NCg0KaW50DQp2dGJ1Zl9zZXRfbWFy
ayhzdHJ1Y3QgdnRfYnVmICp2YiwgaW50IHR5cGUsIGludCBjb2wsIGludCByb3cpDQp7DQoJdGVy
bV9jaGFyX3QgKnI7DQoJaW50IGk7DQoNCglzd2l0Y2ggKHR5cGUpIHsNCgljYXNlIFZUQl9NQVJL
X0VORDoJLyogQjEgVVAgKi8NCgkJaWYgKHZiLT52Yl9tYXJrX2xhc3QgIT0gVlRCX01BUktfTU9W
RSkNCgkJCXJldHVybiAoMCk7DQoJCS8qIEZBTExUSFJPVUdIICovDQoJY2FzZSBWVEJfTUFSS19N
T1ZFOg0KCWNhc2UgVlRCX01BUktfRVhURU5EOg0KCQl2dGJ1Zl9mbHVzaF9tYXJrKHZiKTsgLyog
Q2xlYW4gb2xkIG1hcmsuICovDQoJCXZiLT52Yl9tYXJrX2VuZC50cF9jb2wgPSBjb2w7DQoJCXZi
LT52Yl9tYXJrX2VuZC50cF9yb3cgPSB2dGJ1Zl93dGgodmIsIHJvdyk7DQoJCWJyZWFrOw0KCWNh
c2UgVlRCX01BUktfU1RBUlQ6DQoJCXZ0YnVmX2ZsdXNoX21hcmsodmIpOyAvKiBDbGVhbiBvbGQg
bWFyay4gKi8NCgkJdmItPnZiX21hcmtfc3RhcnQudHBfY29sID0gY29sOw0KCQl2Yi0+dmJfbWFy
a19zdGFydC50cF9yb3cgPSB2dGJ1Zl93dGgodmIsIHJvdyk7DQoJCS8qIFN0YXJ0IGFnYWluLCBz
byBjbGVhciBlbmQgcG9pbnQuICovDQoJCXZiLT52Yl9tYXJrX2VuZC50cF9jb2wgPSBjb2w7DQoJ
CXZiLT52Yl9tYXJrX2VuZC50cF9yb3cgPSB2dGJ1Zl93dGgodmIsIHJvdyk7DQoJCWJyZWFrOw0K
CWNhc2UgVlRCX01BUktfV09SRDoNCgkJdnRidWZfZmx1c2hfbWFyayh2Yik7IC8qIENsZWFuIG9s
ZCBtYXJrLiAqLw0KCQl2Yi0+dmJfbWFya19zdGFydC50cF9yb3cgPSB2Yi0+dmJfbWFya19lbmQu
dHBfcm93ID0NCgkJICAgIHZ0YnVmX3d0aCh2Yiwgcm93KTsNCgkJciA9IHZiLT52Yl9yb3dzW3Zi
LT52Yl9tYXJrX3N0YXJ0LnRwX3Jvd107DQoJCWZvciAoaSA9IGNvbDsgaSA+PSAwOyBpIC0tKSB7
DQoJCQlpZiAoVENIQVJfQ0hBUkFDVEVSKHJbaV0pID09ICcgJykgew0KCQkJCXZiLT52Yl9tYXJr
X3N0YXJ0LnRwX2NvbCA9IGkgKyAxOw0KCQkJCWJyZWFrOw0KCQkJfQ0KCQl9DQoJCS8qIE5vIHNw
YWNlIC0gd29yZCBleHRlbmRzIHRvIGJlZ2lubmluZyBvZiBsaW5lLiAqLw0KCQlpZiAoaSA9PSAt
MSkNCgkJCXZiLT52Yl9tYXJrX3N0YXJ0LnRwX2NvbCA9IDA7DQoJCWZvciAoaSA9IGNvbDsgaSA8
IHZiLT52Yl9zY3Jfc2l6ZS50cF9jb2w7IGkrKykgew0KCQkJaWYgKFRDSEFSX0NIQVJBQ1RFUihy
W2ldKSA9PSAnICcpIHsNCgkJCQl2Yi0+dmJfbWFya19lbmQudHBfY29sID0gaTsNCgkJCQlicmVh
azsNCgkJCX0NCgkJfQ0KCQkvKiBObyBzcGFjZSAtIHdvcmQgZXh0ZW5kcyB0byBlbmQgb2YgbGlu
ZS4gKi8NCgkJaWYgKGkgPT0gdmItPnZiX3Njcl9zaXplLnRwX2NvbCkNCgkJCXZiLT52Yl9tYXJr
X2VuZC50cF9jb2wgPSBpOw0KDQoJCWlmICh2Yi0+dmJfbWFya19zdGFydC50cF9jb2wgPiB2Yi0+
dmJfbWFya19lbmQudHBfY29sKQ0KCQkJdmItPnZiX21hcmtfc3RhcnQudHBfY29sID0gdmItPnZi
X21hcmtfZW5kLnRwX2NvbDsNCgkJYnJlYWs7DQoJY2FzZSBWVEJfTUFSS19ST1c6DQoJCXZ0YnVm
X2ZsdXNoX21hcmsodmIpOyAvKiBDbGVhbiBvbGQgbWFyay4gKi8NCgkJdmItPnZiX21hcmtfc3Rh
cnQudHBfY29sID0gMDsNCgkJdmItPnZiX21hcmtfZW5kLnRwX2NvbCA9IHZiLT52Yl9zY3Jfc2l6
ZS50cF9jb2w7DQoJCXZiLT52Yl9tYXJrX3N0YXJ0LnRwX3JvdyA9IHZiLT52Yl9tYXJrX2VuZC50
cF9yb3cgPQ0KCQkgICAgdnRidWZfd3RoKHZiLCByb3cpOw0KCQlicmVhazsNCgljYXNlIFZUQl9N
QVJLX05PTkU6DQoJCXZiLT52Yl9tYXJrX2xhc3QgPSB0eXBlOw0KCQkvKiBGQUxMVEhST1VHSCAq
Lw0KCWRlZmF1bHQ6DQoJCS8qIHBhbmljPyAqLw0KCQlyZXR1cm4gKDApOw0KCX0NCg0KCXZiLT52
Yl9tYXJrX2xhc3QgPSB0eXBlOw0KCS8qIERyYXcgbmV3IG1hcmtlZCByZWdpb24uICovDQoJdnRi
dWZfZmx1c2hfbWFyayh2Yik7DQoJcmV0dXJuICgxKTsNCn0NCiNlbmRpZg0KDQp2b2lkDQp2dGJ1
Zl9jdXJzb3JfdmlzaWJpbGl0eShzdHJ1Y3QgdnRfYnVmICp2YiwgaW50IHllcykNCnsNCglpbnQg
b2ZsYWdzLCBuZmxhZ3M7DQoNCglvZmxhZ3MgPSB2Yi0+dmJfZmxhZ3M7DQoJaWYgKHllcykNCgkJ
dmItPnZiX2ZsYWdzIHw9IFZCRl9DVVJTT1I7DQoJZWxzZQ0KCQl2Yi0+dmJfZmxhZ3MgJj0gflZC
Rl9DVVJTT1I7DQoJbmZsYWdzID0gdmItPnZiX2ZsYWdzOw0KDQoJaWYgKG9mbGFncyAhPSBuZmxh
Z3MpDQoJCXZ0YnVmX2RpcnR5X2NlbGwodmIsICZ2Yi0+dmJfY3Vyc29yKTsNCn0NCg0Kdm9pZA0K
dnRidWZfc2Nyb2xsX21vZGUoc3RydWN0IHZ0X2J1ZiAqdmIsIGludCB5ZXMpDQp7DQoJaW50IG9m
bGFncywgbmZsYWdzOw0KDQoJVlRCVUZfTE9DSyh2Yik7DQoJb2ZsYWdzID0gdmItPnZiX2ZsYWdz
Ow0KCWlmICh5ZXMpDQoJCXZiLT52Yl9mbGFncyB8PSBWQkZfU0NST0xMOw0KCWVsc2UNCgkJdmIt
PnZiX2ZsYWdzICY9IH5WQkZfU0NST0xMOw0KCW5mbGFncyA9IHZiLT52Yl9mbGFnczsNCg0KCWlm
IChvZmxhZ3MgIT0gbmZsYWdzKQ0KCQl2dGJ1Zl9kaXJ0eV9jZWxsKHZiLCAmdmItPnZiX2N1cnNv
cik7DQoJVlRCVUZfVU5MT0NLKHZiKTsNCn0NCg==

--3432851520-594251130-1655902382=:1623--

From nobody Wed Jun 22 13:13:56 2022
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 25FE386331C
	for ; Wed, 22 Jun 2022 13:14:06 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSkNs21xBz3hfy
	for ; Wed, 22 Jun 2022 13:14:05 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 20B14260728;
	Wed, 22 Jun 2022 15:14:03 +0200 (CEST)
Message-ID: 
Date: Wed, 22 Jun 2022 15:13:56 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: vt newcons mouse paste issue FIXED
Content-Language: en-US
To: Ivan Quitschal , freebsd-current@freebsd.org
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LSkNs21xBz3hfy
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-2.38 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 NEURAL_HAM_LONG(-0.30)[-0.302];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.983];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.80)[-0.799];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[hotmail.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received]
X-ThisMailContainsUnwantedMimeParts: N

On 6/22/22 14:53, Ivan Quitschal wrote:
> 
> Hi All
> 
> About this anoying paste error we still have in vt console, I looked it 
> up and couldnt find any fix regarding this, so i did it.
> 
> Please find attached the fixed version of /usr/src/sys/dev/vt/vt_buf.c 
> with trim spaces and aligned to the console size.
> I've tested with other fonts and looks fine in here.
> 
> I hope this can help other ppl which finds this terminal mouse paste 
> issue a pain in the neck.
> 
> thanks
> 
> --tzk

Can you provide the diff against the old, unmodified file?

--HPS

From nobody Wed Jun 22 13:36:22 2022
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 E3C688666F8
	for ; Wed, 22 Jun 2022 13:36:31 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2097.outbound.protection.outlook.com [40.92.96.97])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSktl19LZz3l8F
	for ; Wed, 22 Jun 2022 13:36:31 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=bO4ut6RjGUvkN8BnDsaCw2BdwykxejDWYMlyKCbhnMh+NagSs00VSotVoutFzEdtR1XFxl1+IJHvBXpYvJwRK01d7l5YeFRQ7pOb4Gl+aEdaMN8/Vzh/5pp3kB6XGBZSXo3wPMX5sW2dSrFVjg1R9bGUBb2NAFJc6atZJ4RAy7DSmXGRS8AnTd/ZjfNxOHM9UTw/tyKaCDnHvOjb3MxXcE0w17bbobfOV6F82v2eNhIHc3qa81aZuiY+H8JMCUd/inDZJuz7jLReZ0f1B4FvuyTHcytv7HG41iOysI6ml4qa1JDElLbJL/WXLzOVMDdF7tQxQT4NEF2wMkTCLz3OhA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XDNwwqCimDSi+b3QiI/2ZHAJ2Vy9d2clLSnwejX40Q8=;
 b=MlAzil+8Tq+lmSfvhF3hHUN3ftZi47uL1AtgtIkJh6FCQ9AtBNWvWF+vrAEOoYA1BfRodoP/Xl34wuR3h95PN1tDQlqp8O+DeaLieru9HMz6bA6phexQGmL7uzqbrDFKpmgd2VBc2QQXc5ZzA+qpgP9qWdq0Pw1MMEtb/xNHRsXKX8eJj5tu63xGJaggATvPqG8Sgq/AatI1q9Cimn2xeRlYZmv7C4+ShxkJmosvyc7ke+jfJVCdZSes/sz2Gz1EVIBEAztmkZcO2dJioOC14qxjKU3M+1CGXMb2SwK0F6LUZio2e+ssymoY3tiGgniKv9u4UBcT40XKYp5b6Irmeg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=XDNwwqCimDSi+b3QiI/2ZHAJ2Vy9d2clLSnwejX40Q8=;
 b=N82ORCkocro24xiF0DEbvEx7jNLObNdpdKrev0BHaopljH8BFjFWjeniItoqdwiPWlP8HX+B7641C56Or6GTGlrz/nrs5bjsU2nrvZG5dgNe/rplyIjrxz0yWMeCbSO1OJPXqLCL4l7RZ4X3Gbf+PcMPJS6nvB5rAr3lEAPlBEXHH97Z/hxUFJ3C42Zhj88SsN4De+xgkx/EL2BXiXK9qXgLIo/rXsetZR0IO4IVYpJ8UAuILDDehQ7DLZt+jU7X6oTRRAzcEBvqf10aRJeLlQd5YIzt6njMniiSlOrIG/0qBrfbWjqjzwAcElzkllsbmjQmDp/QOpMwruWpQFj24g==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by ROAP284MB0592.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:3e::13) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.15; Wed, 22 Jun
 2022 13:36:22 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%7]) with mapi id 15.20.5353.022; Wed, 22 Jun 2022
 13:36:22 +0000
From: Ivan Quitschal 
To: Hans Petter Selasky , "freebsd-current@freebsd.org"
	
Subject: RES: vt newcons mouse paste issue FIXED
Thread-Topic: vt newcons mouse paste issue FIXED
Thread-Index: AQHYhjcChIuK2z3T9ky9hQYmy4Xi761bZ2wAgAAFqsA=
Date: Wed, 22 Jun 2022 13:36:22 +0000
Message-ID:
 
References:
 
 
In-Reply-To: 
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [mi+p6KioOMMbEJxHbmD+JA8XL7UsKd3bUf6UxtP+g7UqGaGubexjt5iZIqqsS1FF]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4b308120-1121-427c-acca-08da54543245
x-ms-traffictypediagnostic: ROAP284MB0592:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 UJWwT4MtSS0TIW9g3Nxawt4WLw71y/BBNJJ4ZHJVd5qeUlIuafO9NcDvCF0oBZAntSPTq/23JqKQQmBaupL9FKHH6LrSWH3y0vkyG8eHowp97vaJJi+BW6BLMBvdlavR36/23cku4x4SgB84l/WddYchGLSnpDSi48RPP2IvMBisC245wB8wU1o647tsS46F20e82WH5eZEcOe+6mDEDyLOEThcHamV22w1bAFg2pxbYe268GAhcUqJT0z36GmEY40AOUBxoMSCtsco3p/tQGdiHlgoHJW8P6wGWKrXtogSLamyMIXWAtNUoH6y21V6NBYb+EVL/DAK2qdzodvPFzL0eifb1LELSH0Z/I+rh1LJzMxLpj17RM7bKSrevY7aQT/nhjGH/O507EkFmwbRT3z+bxrPTTBcPDT7b9yvDpIreQgYjCu029APvZwGWyzAk+z4J9lrk8A4jogOkFWhcpsIGwA7uQPJ81aBImnWAqm0GcU4xc+yHM1sDQecs5jzLaYGHbJdEaBeNTemki01NtMiD/zihWy/pF2GrmeEpTx/55F3bgE8Jm/Wd8rhJJF6YPRz2f6uVHETxuVsSOAC6/2RGsJPiBGUcV5RiaB6jIdr3u/th2N3R/XVj762BKPTHWpgKg5xsbhJiAISHK+4bEQ==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?RXhrZnpDWXpBeG8xNFBxRno5bXBzclA4N0pXSEp1MGxZUDlSS01pRm1jcEEw?=
 =?utf-8?B?Y1RodjRKTTdKVjJqQTVGL01Na2ZsWWgyMUJqeDVPU1V3WHBTd3R1aXcwV1N2?=
 =?utf-8?B?MFlJcXI3UTVXaXFuU2J5VFpmSjhudVByWjJWMmlhcW16cVpVa3k0Vjk3Vlk1?=
 =?utf-8?B?WlhTL0U5bndvcVVEMm9Pa0lEMGNRaGJSbzR3VVYzRnpXTUl5YTVxR2h0WWJH?=
 =?utf-8?B?M2hJeTFlekdwZklaNWs0bktvTmx0VUthODVPMjdVVVE2bnl6RExXdXdmWlp0?=
 =?utf-8?B?ZjBNZWlEK3VlRFVYaVRoUzlXUTVVL3d2NmduTDJnMjJzSjBtOHlCeXAxVTFM?=
 =?utf-8?B?MWJPT2hvQUJvSkt4REVHaWJ2RUxldDc5aVk3ay9aREpqNlVJVWhZZ0ZSK2x4?=
 =?utf-8?B?VUNaZGZxaUxLdFQ2S25CdzNKN3VsT2RXZ1p2YlNzL2pNYTNaQmhQeVZwSUYz?=
 =?utf-8?B?Lzd3b1NrZVJiWW1XWFNNK1FmQlI1R09EaE1aZ0xXU2h3LzZicEIzaTY4QUcy?=
 =?utf-8?B?dlYvakxyQnJXanlBdklGYWxVUUl3UXJpdEcrQ05FRHQvMlA0dkpxejdGV2dD?=
 =?utf-8?B?RE0raFVEVkV2MWUvWkZ1MllzSlE0L3YyOXFENlNzZTVIR0lodERzeW9McTA5?=
 =?utf-8?B?ZnNmK0lpOGhYcEVLZE01dTFGcGZkb2VRTkQ3Ymt1RTVBWmtXUCszY3lLQnJp?=
 =?utf-8?B?bmlHRFpXWi92RnJyWVgzOVlMUjVleHBMelVsS0h6VEpnQWhmVElybnVhUUw3?=
 =?utf-8?B?QWNvV2lTVnF4c2hvRmJsVHRnTDBxcGNaMm1PMlZtT0ppZ3pEalJrNHRUR2pJ?=
 =?utf-8?B?Sm5xQlpMN0tHUHhXS2NwT2lnMlRLcTArM0NqRmovMVhPcm1hcVgwcjZNdC95?=
 =?utf-8?B?cGVzeTY0ZGV2TVNLYTlLVTRBL3N1R3BRL3FjdGFSQ00wMDA2emM5K3hrSmF1?=
 =?utf-8?B?OGpRSlkvQmVWUW9KTVZrbzNMbDVVc0ZkTWZLVlhMRUVzUlhmN1dvQjZTd3Vl?=
 =?utf-8?B?R0hoL3lJcWNaYXRMeDYwR0JUTUFkQ3h0bTd6L3hyVW5zM1BGZ1ZFUmVJMThP?=
 =?utf-8?B?Q1p3dmxqUmwrUm1QOGhJZGZqajlySHpOVHNqRlhlSkkrVkNJUjFjT1FaaEto?=
 =?utf-8?B?SHU1WVNVRDg3MmVad05sUFVWWjVRcXBhL0k2S21QMUVOZFV4YUdTU2NFeXk2?=
 =?utf-8?B?ek5GM2RXSExKY3dSSjA1M2JjYmtFM2Rva0tlQlBBRjRJZWh6WlBrallnd0Nz?=
 =?utf-8?B?dnNUNGo5bHJDWisyNU5GOEI2dzhPY1FQZ3hWSGk3MEVYTm92dlBENUhsc3VU?=
 =?utf-8?B?bDhQeHkrV1VEdythSVVlWGdXL2Mvbno4QVZpdGZzT3lDczhYSXBLTHRhcGw3?=
 =?utf-8?B?TkpiV2RyZFZvOTc5dmFxZHhodXY1K1UrT0hjSVQxWFR4WjNIbXZ0azEzaG5I?=
 =?utf-8?B?YTFiTzhmR3J6ZTRLcmQ1RWs5N0pzUzYySjl3MlNLN0ZBb21zTFRRK205UFRJ?=
 =?utf-8?B?Z01GSEZpU0NJQUlWdTdjRm5NczNDMFVjbXRnY1BCdjNjTFcyTXBtOGo0WXNy?=
 =?utf-8?B?VGw2dTh3MEZvN25BNStYUkRvU0JrWEJ1ZjJGSFNVcDZKd25XblFpdHR4eHNO?=
 =?utf-8?B?MVV0dE9PUHd5MC9KbXdVN2NOWFlzV25QUlA4bTIySURCSHVXaysxRGo3MmVO?=
 =?utf-8?B?dTl1aWxnVDM5czRBM2JJNk5LcWdveFNXL25EelVidEdtZWJpaThieXRzWEth?=
 =?utf-8?B?alppWURFZGNXWXRkSE1qZFcwWTNOTU0wMllVWEhmbUNETU1qN09JUENXWktv?=
 =?utf-8?B?TytOc1pXM1o0cDE3UXVkTUlhRjl4bDhKVm5RZXQxcHMxQ0ZGSTlQbjI3ODBj?=
 =?utf-8?B?SXpsSG4zWVllN01Ka3FBWjRZRVZZdSs2ZnhRdysxVnpSYzkveGN2QkxVcjRk?=
 =?utf-8?B?YlJWYkoveDliK2ZtcFhmcmV5U1pxa3N0elV6NFhiZEszaFpsck1UOHM5ajl0?=
 =?utf-8?B?UGs3UEViWlFnPT0=?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b308120-1121-427c-acca-08da54543245
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2022 13:36:22.3291
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB0592
X-Rspamd-Queue-Id: 4LSktl19LZz3l8F
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=N82ORCko;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.97 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-3.84 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[hotmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	 MIME_BASE64_TEXT_BOGUS(1.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[hotmail.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_SHORT(-0.95)[-0.953];
	 DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	 FREEMAIL_ENVFROM(0.00)[hotmail.com];
	 DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.990];
	 R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[40.92.96.97:from];
	 MLMMJ_DEST(0.00)[freebsd-current]
X-ThisMailContainsUnwantedMimeParts: N

SGkgSGFucw0KDQpQbGVhc2UgZmluZCBiZWxvdy4gDQpJdCBjYW4ndCBwYXN0ZSB0aGUgZW50aXJl
IHNjcmVlbiAobWluZSBpcyAxOTIweDEwODApIHRobywgZHVlIHRvICJzeiIgc2l6ZSBJIGJlbGll
dmUuDQoNCjQzYTQ0DQo+ICNpbmNsdWRlIDxzeXMvY3R5cGUuaD4NCjc1NGE3NTYNCj4gICAgICAg
dGVybV9jaGFyX3QgKmVuZDsNCjc3NGE3NzcsNzgzDQo+ICAgICAgICAgICAgICAgZW5kID0gYnVm
ICsgaSAtMTsNCj4gICAgICAgICAgICAgICB3aGlsZSAoZW5kID4gYnVmICYmIGlzc3BhY2UoKHVu
c2lnbmVkIGNoYXIpKmVuZCkpDQo+ICAgICAgICAgICAgICAgew0KPiAgICAgICAgICAgICAgICAg
ICAgICAgKmVuZCA9ICdcMCc7DQo+ICAgICAgICAgICAgICAgICAgICAgICBlbmQtLTsNCj4gICAg
ICAgICAgICAgICB9DQo+IA0KNzc3Yzc4Ng0KPCAgICAgICAgICAgICAgICAgICAgICAgYnVmW2kr
K10gPSAnXHInOw0KLS0tDQo+ICAgICAgICAgICAgICAgICAgICAgICBidWZbaV0gPSAnXHInOw0K
Nzc4YTc4OA0KPiAgICAgICAgICAgICAgICAgICAgICAgYnVmW2krK10gPSAnXDAnOw0KDQoNCi0t
dHprDQoNCi0tLS0tTWVuc2FnZW0gb3JpZ2luYWwtLS0tLQ0KRGU6IEhhbnMgUGV0dGVyIFNlbGFz
a3kgPGhwc0BzZWxhc2t5Lm9yZz4gDQpFbnZpYWRhIGVtOiBxdWFydGEtZmVpcmEsIDIyIGRlIGp1
bmhvIGRlIDIwMjIgMTA6MTQNClBhcmE6IEl2YW4gUXVpdHNjaGFsIDx0ZXpla2FAaG90bWFpbC5j
b20+OyBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcNCkFzc3VudG86IFJlOiB2dCBuZXdjb25z
IG1vdXNlIHBhc3RlIGlzc3VlIEZJWEVEDQoNCk9uIDYvMjIvMjIgMTQ6NTMsIEl2YW4gUXVpdHNj
aGFsIHdyb3RlOg0KPiANCj4gSGkgQWxsDQo+IA0KPiBBYm91dCB0aGlzIGFub3lpbmcgcGFzdGUg
ZXJyb3Igd2Ugc3RpbGwgaGF2ZSBpbiB2dCBjb25zb2xlLCBJIGxvb2tlZCANCj4gaXQgdXAgYW5k
IGNvdWxkbnQgZmluZCBhbnkgZml4IHJlZ2FyZGluZyB0aGlzLCBzbyBpIGRpZCBpdC4NCj4gDQo+
IFBsZWFzZSBmaW5kIGF0dGFjaGVkIHRoZSBmaXhlZCB2ZXJzaW9uIG9mIC91c3Ivc3JjL3N5cy9k
ZXYvdnQvdnRfYnVmLmMgDQo+IHdpdGggdHJpbSBzcGFjZXMgYW5kIGFsaWduZWQgdG8gdGhlIGNv
bnNvbGUgc2l6ZS4NCj4gSSd2ZSB0ZXN0ZWQgd2l0aCBvdGhlciBmb250cyBhbmQgbG9va3MgZmlu
ZSBpbiBoZXJlLg0KPiANCj4gSSBob3BlIHRoaXMgY2FuIGhlbHAgb3RoZXIgcHBsIHdoaWNoIGZp
bmRzIHRoaXMgdGVybWluYWwgbW91c2UgcGFzdGUgDQo+IGlzc3VlIGEgcGFpbiBpbiB0aGUgbmVj
ay4NCj4gDQo+IHRoYW5rcw0KPiANCj4gLS10emsNCg0KQ2FuIHlvdSBwcm92aWRlIHRoZSBkaWZm
IGFnYWluc3QgdGhlIG9sZCwgdW5tb2RpZmllZCBmaWxlPw0KDQotLUhQUw0K

From nobody Wed Jun 22 14:01:54 2022
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 2620086B08F
	for ; Wed, 22 Jun 2022 14:02:08 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4LSlSH1knpz3prn
	for ; Wed, 22 Jun 2022 14:02:07 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 9637926021A;
	Wed, 22 Jun 2022 16:02:00 +0200 (CEST)
Message-ID: <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
Date: Wed, 22 Jun 2022 16:01:54 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: RES: vt newcons mouse paste issue FIXED
Content-Language: en-US
To: Ivan Quitschal ,
 "freebsd-current@freebsd.org" 
References: 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LSlSH1knpz3prn
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-0.66 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_MEDIUM(-0.97)[-0.969];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.21)[-0.213];
	 RCPT_COUNT_TWO(0.00)[2];
	 NEURAL_SPAM_LONG(0.82)[0.818];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[hotmail.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received]
X-ThisMailContainsUnwantedMimeParts: N

On 6/22/22 15:36, Ivan Quitschal wrote:
> Hi Hans
> 

Hi Ivan,

I think you should upload the diff at:

https://reviews.freebsd.org/differential/

Make the diff like this:

diff -u -C 999999 sys/dev/vt/vt_buf.c.orig sys/dev/vt/vt_buf.c > a.diff


I see two issues:

1) Pointer arithmetics is not so good!

>                 }
> +               end = buf + i - 1;
> +               while (end > buf && isspace((unsigned char)*end))
> +               {
> +                       *end = '\0';
> +                       end--;
> +               }
> +

I think this would be better and avoid the ">" with pointers!

for (end = buf + i; end-- != buf; ) {
    if (isspace((unsigned char)*end) == false)
	break;
    *end = '\0';
}

Can you explain this:

> -                       buf[i++] = '\r';
> +                       buf[i] = '\r';
>                         buf[i++] = '\n';

'\r' character is now overwritten by '\n' character.

--HPS

From nobody Wed Jun 22 15:01:36 2022
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 4EF83873EA5
	for ; Wed, 22 Jun 2022 15:01:46 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2035.outbound.protection.outlook.com [40.92.97.35])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSmn51pXtz4SNf;
	Wed, 22 Jun 2022 15:01:45 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=jc5i5teXlTxK6U5ESlBbE4kOWZFRUZxoS8pVlzCxhDf59rsOhXixyu+0MA1ROxQWBp2aI4Bfw3atOOAM2fVROj2qMsV5RKfWKk2AOmoan5T7fdRtsKZnmcShID98yh2kq0gTGofFsW2OWVgMfCTPgDTwauOpUGidRIGR/lhlG+Xf00l/G8AfZoHXliEcFCIcn72SxUly/TZu/GXRMWfuDA36z4ezzDEjeKUay9vrmLiFXFhPFl00YjvpBSkLSMTu0zNekk1EykNGG50lSta9Iq8OaY/FxRTXtm2z4BD6ohQCh66A3TRj3mGnimbaVleyn3d/k5KrDSaX1UHxT8AwcQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BOXpwamT8w8NVzXIH4e+ZGDltuD91IOYdNg3KIPE1kc=;
 b=DGW494bS9mCmrQDd//fX9lY519xbAJBR+aEqaUjlcQGBBnQZvr47BTZDIWw8XFRKRxCGfU6RsOq0E1N7HvpuUftPeeWn3Z+M9dvH9aKiMHKsjtClifSf8mKGbW2bnimnxxuoCMtFVBfLIAZ53X40Kd3R+aFyOILpbAqI1j+s3XSnADImUcDs28mCK+uY+/Rt7bhigYIeEiFrZfV7D9Fhknz3VTeGkdVQlM8WgnwEMDQdEzm2SS9l+vuo/y3JiGAIJ3c3nGpte/hScHg1DJXCXnPjYW5JvsQT2SjKxvKXn1e2d0QL/jsM2OoEnU31qj+Yd83UmOSTiv7gSEM8YHbLAg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BOXpwamT8w8NVzXIH4e+ZGDltuD91IOYdNg3KIPE1kc=;
 b=dAktZWdY01fSJC2FM/oG2huVWnJIcsYsdE7iTjG8EiyH6667QMgV+cVX/pe4OQ8V0D4oWNLiMVbGZx8HMA8qEV5A1o38gfZX7ZOKHvgBSmy1ZbOxRuPDkzdSHIdd64J75ylhU2NlT9QUiYcJN6GOjCS4qHji2f+8JBUudQVzaJgA9sJs96Wqo+ExNiHeK45cqhGiBhxWvKKeHkWEzfRqkyvs7rT62zktlGKVM5mzqoEbPBfpKoLCNu5JOOd70XzH9Y5wiOlkh7bhIviqkvOJH6BYj32XGifoXrChKDpOAP8GwtnjnxsGT4FZyqENCHCTqFyU4G0n409MfERJLz8cdg==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by ROAP284MB0463.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:37::7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5353.15; Wed, 22 Jun 2022 15:01:36 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%7]) with mapi id 15.20.5353.022; Wed, 22 Jun 2022
 15:01:36 +0000
From: Ivan Quitschal 
To: Hans Petter Selasky , "freebsd-current@freebsd.org"
	, Kurt Jaeger 
Subject: RES: RES: vt newcons mouse paste issue FIXED
Thread-Topic: RES: vt newcons mouse paste issue FIXED
Thread-Index: AQHYhjcChIuK2z3T9ky9hQYmy4Xi761bZ2wAgAAFqsCAAAe9AIAAD1ew
Date: Wed, 22 Jun 2022 15:01:36 +0000
Message-ID:
 
References:
 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
In-Reply-To: <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [uA6N6Cy+Z/d65A7N5jVFIpgs3K+s2wLGrt6G+RNYnh3nNGZEbkR86bS4J2UCAPp5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f22e57ce-8929-4049-d03a-08da54601a64
x-ms-traffictypediagnostic: ROAP284MB0463:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 p1Xqfbc7V/Th3bcdo9K0JgdtM18V3NpV9MxuAWbtm6wlJscSBzKjvRKZfsBhU6okR5DPze8IkFgo93vau1mjEAX7jum15bdMRXAJhO+EBoOMTdblUK967CuNy4Od+zcvBVXzulktlc9Z0kikDP4KzOE5rpBfq3MgGjjnRPrpe7qD/LBZa8vfQkfVwbWqNPsv9oo0baURJxfnxQqG8ReTy8foK/ATbg/V6sQruKY415S4kePwdJYW0du76Y0Kzx1Tj31MbUEZIod+Wg9gJxVVIUPA5zpPm2vGn/uNEQE+8/J3R+iXqL5Cy8Puh9TVRbKzwcbuF5ak6IXw1zIJa8EfA0vUmRJeqkpKf/1OAZjpilgOt7Z8E1XneQK3FIDrXV5CVK2Lysl3LyT8nYFnt7s9UyfPSmB/krCxYBr3xIrstVA5WDE3XXwFqdrr4gFvkIoyq8zuEYMPEeHxA9uvTWf/U5xc/Xm41Ohh+AQypgG/lOaWk1uP09UiKWTFhE0Drz59QtpY/poFJ33QaHi/p6hoCWF1Vx6yTqCQ1+JqU+GsaEfXS0bA0tEFfCrX7RRammJvEQXCPSru+ED1M1NhKFND3oDLLsyPj2SEGofNCB+LuQFRjP9dXnFFih1FIcyB/LL5
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?eXV0b1gxdjhwcVlOZkpISDFGVFg5RW9EdndMaDBMRkFzYnh3aENJaXR4WTFk?=
 =?utf-8?B?RUZ0VURKQTZXUlc2b2gyRXFQYWtQU2d6T1JQanIwUnJ0aGVXY2UrcXBZSkpm?=
 =?utf-8?B?ZXFuNUFmaitGV2p1ZHBPNkl3NVdxdEE2K3R1VUVGR3FMZkt6RHp4b2thUlJD?=
 =?utf-8?B?OTE5R2FvZXlLU2p5Z1lBR2IrTnFnSFdGSmIyRElQSkF2MW5kQUNnMndRSVIz?=
 =?utf-8?B?QVpvOXZYV3NhQ3ZXd01lL0VQSitKWW9IUVBPWFluQTh5RGNzMkMyUW1KVWc0?=
 =?utf-8?B?V2JySGJYUGFwdFRvcEw0MUpBUmhpQWI4SlFPQWNPQTNocjh4TVdUcGJZRGpr?=
 =?utf-8?B?cTlqOXplR0pRcVI4ZUFkUGFMbnNmaldFWTdJTUVjN3RvMEorOFRoS3dpekxF?=
 =?utf-8?B?a2pDaFhqKzdFeVJmUkY1TWtLYmtwdEdVMFAvZi9udG52UmlHRzI2RXdJK0hF?=
 =?utf-8?B?QjdEbFRWbElWbmhxbWR3em9la0s5azFrOTJCNjlHa1JlWXZidHhxbTNLQlJq?=
 =?utf-8?B?bXNHVDNDM20yT3pIUDBVRFgrOG1iSnRyZzBJMy8xalJLMU9qUWROYTdIdEN3?=
 =?utf-8?B?NXdvMnQ5cGUrcXRLSlBENzV0NHBqa0FIVnVqaWloQndQazBpSWQvc1RsRTVk?=
 =?utf-8?B?d1FldGtkYU1HK1VMWG5hQkhjUUJKRy9yTXY0T2xLMlBtS21JUDBVTTZ2RlFK?=
 =?utf-8?B?ZU0xL0h5K1U1elJpQUU1cjdXRmUvbUgraHhva0ZmT0RQTUFXV2tOaHNBRjkw?=
 =?utf-8?B?OXdVTWpLRzZ0aTdkVjBodFh4elhKS2s5S3BNTkpqeStWb1pkZ3pTZG04eFo3?=
 =?utf-8?B?b2ZhcDlEM3o3YjIyMVkvSGhWYng5R1ZaajRsa3B4NXVXNzRLQ1oxREV1dzh5?=
 =?utf-8?B?ZDBCRWZOUzU2TFI1UysvT09EOWtkR09FV2RZSld1Y1lnOWt5TmNvMWNwZENy?=
 =?utf-8?B?d0p1QUtCU3hWY0NHRXRKZG13NkNYcFNsMm5CVGNxNkJyaW13WXo4cHdsTDBJ?=
 =?utf-8?B?K1gyM256THZ6d3Q2NVlKaEtHY0ptbSt0R1BvVWVWZUZUYkd5UkxUVmQ1NVVy?=
 =?utf-8?B?RXdIZi9XUHpnZlNBWHprYlRiNE1PMFkzVk5RZldYS3RCbUNkeXgyN2llc3JC?=
 =?utf-8?B?SWQyclJTVytxaE5XdGVuTEdVaGtsSDJmVFpMOUMrMis2TEVlTHllUFZkZEJs?=
 =?utf-8?B?VEdtNE9tYUtPL2tqZU1ZL0FPUGdaLzBVUm12SjBoZEZsYW5WWWpDaE9SQnVW?=
 =?utf-8?B?U2ZhYUFteXZaRS81UmpxbWlMa2ZkMmE4cnpBSWVjNmVRMFdhQTIvMWlZaUJq?=
 =?utf-8?B?V29pQk91R1JCbVZGVlFOWjlGWC9MZTlYSmtlSTZTM2o3NVl0dFBJbXU0b3Bq?=
 =?utf-8?B?eC93QzlnZGJTNjRaY29NejB3OFVJTUc0azR2aWZ1bDMwMFY4NDJBOHd4Wlo2?=
 =?utf-8?B?QS9VVGVPTU1mYmE3NFVVYkxSbmVOQlQzRjgxbnh5UTBhMTl3QUxRUmxjeVIr?=
 =?utf-8?B?cWtSZCs0QW5IUlNUcjd6NUlxbHBXN3ptQVlpNHkxV3FIVGhBZ1Mxd1owL3Bx?=
 =?utf-8?B?REFDQ2lYTjV4elBLM3F6bUd6RkZuUng3UDBhODVGS3VPbUZha0FaQmRRVDhW?=
 =?utf-8?B?UVdta1BudVFaQWxHSEo0WXEzcEl6SFRJc0owczFvK0todTJ3K3dkc2xOUG5W?=
 =?utf-8?B?dXgydEFFNlNJZlViQmJsWGgvaGJQL3JZNCtMcE5scXV0dWkwVWVobHlNTEhr?=
 =?utf-8?B?QkUzZWpFTGRRdDk5L2RwZDFhNVNyUEUvekZyN2kzWTJ4Y3ZzdllsREFzYmcw?=
 =?utf-8?B?amErR3hjaTUyd1FWT2hnUDFFRHRVVW9JS3pJZ1p0TFdEdEQ4VjBJMk5LVU9I?=
 =?utf-8?B?Ky9zS3hYaS93VEc3UlNOQ291SGpjTDRFT2JPRDk3Zko1b0JUczVqbjNCVDF3?=
 =?utf-8?B?NU8zM3NwNzZ0TnZmclVCWFlRL2F6c2lIRGFLajd3SG9ReTBQRytBRk9OeEtO?=
 =?utf-8?B?bTRaV0ZYNmdBPT0=?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: f22e57ce-8929-4049-d03a-08da54601a64
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2022 15:01:36.2598
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB0463
X-Rspamd-Queue-Id: 4LSmn51pXtz4SNf
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=dAktZWdY;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.35 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.75 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.96)[-0.963];
	 R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[hotmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[hotmail.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[40.92.97.35:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 NEURAL_HAM_SHORT(-0.88)[-0.884];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[hotmail.com];
	 ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

SGkgSGFucw0KDQpBY3R1YWxseSBpIGNhbiAsIEkgc2hvdWxkJ3ZlIGN1dCBvZmYgdGhlICdccicg
8J+YiiAsICB0aGlzIGlzIHdoYXQgd2FzIGNhdXNpbmcgdGhlIHRlcm0gdG8gZ28gYmVuZA0KDQpU
aGlzIGlzIHRoZSBjb3JyZWN0IGRpZmYgKG9wdGlvbiAtQyA5OTk5IGRvZXNu4oCZdCB3b3JrZWQg
d2l0aCAtdSkNCkkgYWxzbyBpbmNsdWRlZCB5b3VyIGNvZGUgZm9yIHRoZSBwdHMgYW55d2F5DQoN
Cg0KDQotLS0gc3lzL2Rldi92dC92dF9idWYuYy5vcmlnICAgIDIwMjItMDYtMjIgMTE6NDg6Mzku
NzA1NTk3MDAwIC0wMzAwDQorKysgc3lzL2Rldi92dC92dF9idWYuYyAyMDIyLTA2LTIyIDExOjUx
OjA1LjUwMjQxNTAwMCAtMDMwMA0KQEAgLTQxLDYgKzQxLDcgQEANCiAjaW5jbHVkZSA8c3lzL21h
bGxvYy5oPg0KICNpbmNsdWRlIDxzeXMvbXV0ZXguaD4NCiAjaW5jbHVkZSA8c3lzL3JlYm9vdC5o
Pg0KKyNpbmNsdWRlIDxzeXMvY3R5cGUuaD4NCiANCiAjaW5jbHVkZSA8ZGV2L3Z0L3Z0Lmg+DQog
DQpAQCAtNzUyLDYgKzc1Myw3IEBADQogew0KICAgICAgICBpbnQgaSwgciwgYywgY3MsIGNlOw0K
ICAgICAgICB0ZXJtX3Bvc190IHMsIGU7DQorICAgICAgIHRlcm1fY2hhcl90ICplbmQ7DQogDQog
ICAgICAgIC8qIFN3YXAgYWNjb3JkaW5nIHRvIHdpbmRvdyBjb29yZGluYXRlcy4gKi8NCiAgICAg
ICAgaWYgKFBPU19JTkRFWCh2dGJ1Zl9odHcodmIsIHZiLT52Yl9tYXJrX3N0YXJ0LnRwX3Jvdyks
DQpAQCAtNzcyLDEwICs3NzQsMTUgQEANCiAgICAgICAgICAgICAgICBmb3IgKGMgPSBjczsgYyA8
IGNlOyBjKyspIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIGJ1ZltpKytdID0gdmItPnZiX3Jv
d3Nbcl1bY107DQogICAgICAgICAgICAgICAgfQ0KKyAgICAgICAgICAgICAgIGZvciAoZW5kID0g
YnVmICsgaTsgZW5kLS0gIT0gYnVmOyApIHsNCisgICAgICAgICAgICAgICBpZiAoaXNzcGFjZSgo
dW5zaWduZWQgY2hhcikqZW5kKSA9PSBmYWxzZSkNCisgICAgICAgICAgICAgICAgICAgICAgIGJy
ZWFrOw0KKyAgICAgICAgICAgICAgICplbmQgPSAnXDAnOw0KKyAgICAgICAgICAgICAgIH0NCiAg
ICAgICAgICAgICAgICAvKiBBZGQgbmV3IGxpbmUgZm9yIGFsbCByb3dzLCBidXQgbm90IGZvciBs
YXN0IG9uZS4gKi8NCiAgICAgICAgICAgICAgICBpZiAociAhPSBlLnRwX3Jvdykgew0KLSAgICAg
ICAgICAgICAgICAgICAgICAgYnVmW2krK10gPSAnXHInOw0KICAgICAgICAgICAgICAgICAgICAg
ICAgYnVmW2krK10gPSAnXG4nOw0KKyAgICAgICAgICAgICAgICAgICAgICAgYnVmW2krK10gPSAn
XDAnOw0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgfQ0KIH0NCg0KV29ya3MgZmluZSBoZXJl
DQoNClRoYW5rcw0KDQotLXR6aw0KDQotLS0tLU1lbnNhZ2VtIG9yaWdpbmFsLS0tLS0NCkRlOiBI
YW5zIFBldHRlciBTZWxhc2t5IDxocHNAc2VsYXNreS5vcmc+IA0KRW52aWFkYSBlbTogcXVhcnRh
LWZlaXJhLCAyMiBkZSBqdW5obyBkZSAyMDIyIDExOjAyDQpQYXJhOiBJdmFuIFF1aXRzY2hhbCA8
dGV6ZWthQGhvdG1haWwuY29tPjsgZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnDQpBc3N1bnRv
OiBSZTogUkVTOiB2dCBuZXdjb25zIG1vdXNlIHBhc3RlIGlzc3VlIEZJWEVEDQoNCk9uIDYvMjIv
MjIgMTU6MzYsIEl2YW4gUXVpdHNjaGFsIHdyb3RlOg0KPiBIaSBIYW5zDQo+IA0KDQpIaSBJdmFu
LA0KDQpJIHRoaW5rIHlvdSBzaG91bGQgdXBsb2FkIHRoZSBkaWZmIGF0Og0KDQpodHRwczovL25h
bTEyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZy
ZXZpZXdzLmZyZWVic2Qub3JnJTJGZGlmZmVyZW50aWFsJTJGJmFtcDtkYXRhPTA1JTdDMDElN0Ml
N0M4NWUzZjM5MWRmYzk0MWYyODUyOTA4ZGE1NDU3Yzc1ZiU3Qzg0ZGY5ZTdmZTlmNjQwYWZiNDM1
YWFhYWFhYWFhYWFhJTdDMSU3QzAlN0M2Mzc5MTUwMzMyNTI2NzU4MDElN0NVbmtub3duJTdDVFdG
cGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFo
YVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCU3QyU3QyU3QyZhbXA7c2RhdGE9NHN4WElSOU5oSWJ3
RDQyZ0lyUDRwWWNkblVpbnFhZTFTTlpBamNscjJBdyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQpNYWtl
IHRoZSBkaWZmIGxpa2UgdGhpczoNCg0KZGlmZiAtdSAtQyA5OTk5OTkgc3lzL2Rldi92dC92dF9i
dWYuYy5vcmlnIHN5cy9kZXYvdnQvdnRfYnVmLmMgPiBhLmRpZmYNCg0KDQpJIHNlZSB0d28gaXNz
dWVzOg0KDQoxKSBQb2ludGVyIGFyaXRobWV0aWNzIGlzIG5vdCBzbyBnb29kIQ0KDQo+ICAgICAg
ICAgICAgICAgICB9DQo+ICsgICAgICAgICAgICAgICBlbmQgPSBidWYgKyBpIC0gMTsNCj4gKyAg
ICAgICAgICAgICAgIHdoaWxlIChlbmQgPiBidWYgJiYgaXNzcGFjZSgodW5zaWduZWQgY2hhcikq
ZW5kKSkNCj4gKyAgICAgICAgICAgICAgIHsNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgKmVu
ZCA9ICdcMCc7DQo+ICsgICAgICAgICAgICAgICAgICAgICAgIGVuZC0tOw0KPiArICAgICAgICAg
ICAgICAgfQ0KPiArDQoNCkkgdGhpbmsgdGhpcyB3b3VsZCBiZSBiZXR0ZXIgYW5kIGF2b2lkIHRo
ZSAiPiIgd2l0aCBwb2ludGVycyENCg0KZm9yIChlbmQgPSBidWYgKyBpOyBlbmQtLSAhPSBidWY7
ICkgew0KICAgIGlmIChpc3NwYWNlKCh1bnNpZ25lZCBjaGFyKSplbmQpID09IGZhbHNlKQ0KCWJy
ZWFrOw0KICAgICplbmQgPSAnXDAnOw0KfQ0KDQpDYW4geW91IGV4cGxhaW4gdGhpczoNCg0KPiAt
ICAgICAgICAgICAgICAgICAgICAgICBidWZbaSsrXSA9ICdccic7DQo+ICsgICAgICAgICAgICAg
ICAgICAgICAgIGJ1ZltpXSA9ICdccic7DQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGJ1Zltp
KytdID0gJ1xuJzsNCg0KJ1xyJyBjaGFyYWN0ZXIgaXMgbm93IG92ZXJ3cml0dGVuIGJ5ICdcbicg
Y2hhcmFjdGVyLg0KDQotLUhQUw0K

From nobody Wed Jun 22 16:41:18 2022
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 4AB1C85DA32
	for ; Wed, 22 Jun 2022 16:41:27 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4LSq062M50z4m9m;
	Wed, 22 Jun 2022 16:41:26 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 882582604E3;
	Wed, 22 Jun 2022 18:41:24 +0200 (CEST)
Message-ID: <1b39ebbd-1029-18c1-e08f-61aac196d022@selasky.org>
Date: Wed, 22 Jun 2022 18:41:18 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: RES: RES: vt newcons mouse paste issue FIXED
Content-Language: en-US
To: Ivan Quitschal ,
 "freebsd-current@freebsd.org" ,
 Kurt Jaeger 
References: 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LSq062M50z4m9m
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.18 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-0.88)[-0.876];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[hotmail.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

I needed to update the patch a bit. Can you test this:

https://reviews.freebsd.org/D35552

Use the download raw patch link in there to get the patch.

Thank you!

--HPS

From nobody Wed Jun 22 16:48:47 2022
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 90D5F85FD36
	for ; Wed, 22 Jun 2022 16:48:53 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSq8g64RMz4nqw;
	Wed, 22 Jun 2022 16:48:51 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 25MGmlOu095719;
	Thu, 23 Jun 2022 01:48:47 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Thu, 23 Jun 2022 01:48:47 +0900
From: Tomoaki AOKI 
To: Ivan Quitschal 
Cc: Hans Petter Selasky ,
        "freebsd-current@freebsd.org"
 ,
        Kurt Jaeger 
Subject: Re: RES: RES: vt newcons mouse paste issue FIXED
Message-Id: <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
In-Reply-To: 
References: 
	
	
	<41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
	
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LSq8g64RMz4nqw
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [-1.57 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 HAS_ORG_HEADER(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 FREEMAIL_TO(0.00)[hotmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 R_DKIM_NA(0.00)[];
	 ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	 MIME_TRACE(0.00)[0:+];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[123.1.85.147:received];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.98)[-0.976];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[sakura.ne.jp];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

Hi.

Not actually tested, but this can cause breakage on non-ascii cases.
Maybe also (or instead) iswspace() test would be needed.
Possibly additional mbrtowc() in the argument of iswspace().

Please see `man 3 multibyte` and `man 3 iswspace`.
(Possibly more to see.)

Characters in buf can be multibyte or wide char depending on locale,
as vt can show at least UTF-8 characters.

Sorry, not looked into enough how UTF-8 characters outside ascii are
handled internally on vt.


On Wed, 22 Jun 2022 15:01:36 +0000
Ivan Quitschal  wrote:

> Hi Hans
> 
> Actually i can , I should've cut off the '\r' 😊 ,  this is what was causing the term to go bend
> 
> This is the correct diff (option -C 9999 doesn’t worked with -u)
> I also included your code for the pts anyway
> 
> 
> 
> --- sys/dev/vt/vt_buf.c.orig    2022-06-22 11:48:39.705597000 -0300
> +++ sys/dev/vt/vt_buf.c 2022-06-22 11:51:05.502415000 -0300
> @@ -41,6 +41,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -752,6 +753,7 @@
>  {
>         int i, r, c, cs, ce;
>         term_pos_t s, e;
> +       term_char_t *end;
>  
>         /* Swap according to window coordinates. */
>         if (POS_INDEX(vtbuf_htw(vb, vb->vb_mark_start.tp_row),
> @@ -772,10 +774,15 @@
>                 for (c = cs; c < ce; c++) {
>                         buf[i++] = vb->vb_rows[r][c];
>                 }
> +               for (end = buf + i; end-- != buf; ) {
> +               if (isspace((unsigned char)*end) == false)
> +                       break;
> +               *end = '\0';
> +               }
>                 /* Add new line for all rows, but not for last one. */
>                 if (r != e.tp_row) {
> -                       buf[i++] = '\r';
>                         buf[i++] = '\n';
> +                       buf[i++] = '\0';
>                 }
>         }
>  }
> 
> Works fine here
> 
> Thanks
> 
> --tzk
> 
> -----Mensagem original-----
> De: Hans Petter Selasky  
> Enviada em: quarta-feira, 22 de junho de 2022 11:02
> Para: Ivan Quitschal ; freebsd-current@freebsd.org
> Assunto: Re: RES: vt newcons mouse paste issue FIXED
> 
> On 6/22/22 15:36, Ivan Quitschal wrote:
> > Hi Hans
> > 
> 
> Hi Ivan,
> 
> I think you should upload the diff at:
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.freebsd.org%2Fdifferential%2F&data=05%7C01%7C%7C85e3f391dfc941f2852908da5457c75f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637915033252675801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4sxXIR9NhIbwD42gIrP4pYcdnUinqae1SNZAjclr2Aw%3D&reserved=0
> 
> Make the diff like this:
> 
> diff -u -C 999999 sys/dev/vt/vt_buf.c.orig sys/dev/vt/vt_buf.c > a.diff
> 
> 
> I see two issues:
> 
> 1) Pointer arithmetics is not so good!
> 
> >                 }
> > +               end = buf + i - 1;
> > +               while (end > buf && isspace((unsigned char)*end))
> > +               {
> > +                       *end = '\0';
> > +                       end--;
> > +               }
> > +
> 
> I think this would be better and avoid the ">" with pointers!
> 
> for (end = buf + i; end-- != buf; ) {
>     if (isspace((unsigned char)*end) == false)
> 	break;
>     *end = '\0';
> }
> 
> Can you explain this:
> 
> > -                       buf[i++] = '\r';
> > +                       buf[i] = '\r';
> >                         buf[i++] = '\n';
> 
> '\r' character is now overwritten by '\n' character.
> 
> --HPS
> 


-- 
Tomoaki AOKI    

From nobody Wed Jun 22 16:56:21 2022
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 CA7A586117C
	for ; Wed, 22 Jun 2022 16:56:30 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSqKT51Crz4qkM;
	Wed, 22 Jun 2022 16:56:29 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id D99642604E3;
	Wed, 22 Jun 2022 18:56:27 +0200 (CEST)
Message-ID: <7d3b812e-e4ca-4a8d-5492-3f4a1c8e2528@selasky.org>
Date: Wed, 22 Jun 2022 18:56:21 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: RES: RES: vt newcons mouse paste issue FIXED
Content-Language: en-US
From: Hans Petter Selasky 
To: Ivan Quitschal ,
 "freebsd-current@freebsd.org" ,
 Kurt Jaeger 
References: 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <1b39ebbd-1029-18c1-e08f-61aac196d022@selasky.org>
In-Reply-To: <1b39ebbd-1029-18c1-e08f-61aac196d022@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LSqKT51Crz4qkM
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.18 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-0.88)[-0.882];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[hotmail.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received]
X-ThisMailContainsUnwantedMimeParts: N

On 6/22/22 18:41, Hans Petter Selasky wrote:
> Hi,
> 
> I needed to update the patch a bit. Can you test this:
> 
> https://reviews.freebsd.org/D35552
> 
> Use the download raw patch link in there to get the patch.
> 
> Thank you!
> 
> --HPS
> 

One more update.

--HPS

From nobody Wed Jun 22 17:08:00 2022
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 C22C4864A29
	for ; Wed, 22 Jun 2022 17:08:07 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSqZv05pKz4v28;
	Wed, 22 Jun 2022 17:08:07 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id CF3D42604E3;
	Wed, 22 Jun 2022 19:08:05 +0200 (CEST)
Message-ID: 
Date: Wed, 22 Jun 2022 19:08:00 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: RES: RES: vt newcons mouse paste issue FIXED
Content-Language: en-US
To: Tomoaki AOKI ,
 Ivan Quitschal 
Cc: "freebsd-current@freebsd.org" ,
 Kurt Jaeger 
References: 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
From: Hans Petter Selasky 
In-Reply-To: <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LSqZv05pKz4v28
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-2.31 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.12)[-0.120];
	 NEURAL_HAM_MEDIUM(-0.89)[-0.891];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[dec.sakura.ne.jp,hotmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received]
X-ThisMailContainsUnwantedMimeParts: N

On 6/22/22 18:48, Tomoaki AOKI wrote:
> Hi.
> 
> Not actually tested, but this can cause breakage on non-ascii cases.
> Maybe also (or instead) iswspace() test would be needed.
> Possibly additional mbrtowc() in the argument of iswspace().
> 
> Please see `man 3 multibyte` and `man 3 iswspace`.
> (Possibly more to see.)
> 
> Characters in buf can be multibyte or wide char depending on locale,
> as vt can show at least UTF-8 characters.
> 
> Sorry, not looked into enough how UTF-8 characters outside ascii are
> handled internally on vt.
> 

Thanks for your feedback.

Now using the TCHAR_CHARACTER() macro, which is already used for space 
separation.

See:
https://reviews.freebsd.org/D35552

--HPS


From nobody Wed Jun 22 18:09:15 2022
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 48B1E86D961
	for ; Wed, 22 Jun 2022 18:09:25 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2079.outbound.protection.outlook.com [40.92.97.79])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSrxc2L05z3JLr;
	Wed, 22 Jun 2022 18:09:24 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=EHxSQBXiSFeQuQBY+7IO4St4CxVcYG0A8fcwooyor1bocsHwyGzoRlfeC3CjUh+JK5ag9JBQjwIbFEPg4Y+IFQdaCOuwbUcEsbXK+vJQ7QvrQz5KNtvA+cbqN6pDjc2g0tJjPoToouOadbVeJHL1t9hoLc5+8i+wtqkjRZ2dmTTxU5mutCxUxJ94XWFqp9LdSv9Kr0FBB++Epo3eIXQ+DMfhnRwILxVzz2NPUSXQw2yPnP0N/kP8r9nNw4h/CRPt1QBr2Vg1a8aJfO5CezpvmFz0aDpMp1ybwGu7hpCmUiLpIaQl1/v9eXDhl1JCUzph4mAd4Kc/XJ3PbT40m+cZJw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=UbrbKhBydKzgH+riM4RLm97lvKGNV1VLlFn1V57dIXo=;
 b=dNJOSi7samFD7MwmbDWPXAWVV0HhFg6g7kwksyLPViL28vTsfV13XAinfvL7oM4WtzTb5W5qxQ0+el0yVCKiKbHl0j3H0EVWQrCq460LJQUo9ISQe/IWLHds+JEimK4eWrXSY3PeSart0Q21IGNlFpzmnOqxNeJ+rQ31EilwxHJC0/FFZEf7NGGOuUuZjt2HkKIS9IJAXIeT33n9DDh+7xHORMSIc751XXGMS0GVbwT/4zhfEwaRQGTNwkjj9bYStgCAuGdxa6cqx2cL6cevI7gh8CjbZ54hPIkI1HqYQD5SRtfcARZP5jOK7Wj+g3bD4HoXEwCt9GqUlyVGQCHEmA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=UbrbKhBydKzgH+riM4RLm97lvKGNV1VLlFn1V57dIXo=;
 b=P83isKlUbtBootd3FnnuvyJsFmziPlIVP/wEyoJhSPaY/sXHkMNzHcfHb00MC9ppIZc1LP+6FWNlswG3YQeXVvtA7ICNcTZwL9zqz2V6Di+jrstXhscOZaL7EtyMuQt57phMbxCwS7nPAjehFweGlElhWneoZqFKbRWgaIn5KbsrL7pfV2u80XwQF7NvQoGRYAdpzLVgDnGsDPmsIzZit9JDnJvV4u1CNHeOL8JqlvTkkAfwGRTqEngCVmpHgJzUVd3GQdEKWI8+/drGal6pJuABOfDKDoqhvyhFWnZYs8vRd5uGIbo4uoW1NLiXB23OKK6PsmengNgnS4JK0Ycxvw==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CP4P284MB0947.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:88::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.15; Wed, 22 Jun
 2022 18:09:15 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%7]) with mapi id 15.20.5353.022; Wed, 22 Jun 2022
 18:09:15 +0000
From: Ivan Quitschal 
To: Hans Petter Selasky , Tomoaki AOKI
	
CC: "freebsd-current@freebsd.org" , Kurt Jaeger
	
Subject: RES: RES: RES: vt newcons mouse paste issue FIXED
Thread-Topic: RES: RES: vt newcons mouse paste issue FIXED
Thread-Index:
 AQHYhjcChIuK2z3T9ky9hQYmy4Xi761bZ2wAgAAFqsCAAAe9AIAAD1ewgAAfSYCAAAVfAIAAD1tw
Date: Wed, 22 Jun 2022 18:09:15 +0000
Message-ID:
 
References:
 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
In-Reply-To: 
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [gG+ESPSWp+9hHz+HTmtntC1OAAu+9rfMMxpnxzzTGRLyO+tAHprB/DzhDLKhP7pg]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0d1c5ad8-5c67-4557-d27f-08da547a5139
x-ms-traffictypediagnostic: CP4P284MB0947:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 XWt0YgbSDsPmUBg/jqKzvPRU/CFgHJGgnkYZnDG0JvFZmXNP3zOXUd/AuPsgzN76BTh0mIv9OZPGvU9Th+sYY1KAEWngpUv5gjDuAYizB91zh1eUJrJSb4x/HStubFUkOPXde/QTY7Fgw8BqFy7nWD6Kx7urqpSyUQS5FMU+SfY3/plOFiDnW+dXetpWsh+kpbiMtHUXE16cKZUsi34EWAmRBUYHjaKXdO46OEnro4uWVePk2FQWYMico+gkQAPBxDzzeYLfTclDwILshaRlUdBzKbYoF7VOJKNileQOdxxRFy2WSCqLIpysB++lk2todKzvHjUH8ckzwVvP6DPPqBmv/IFjTk2KlaZWx7tjBKBPgGOJMeUaWdKvGmeO+cg06CVp3H77ypSt+XH8qOymMSEpj4aknCmFIrTNlgNPPRVAmqKbS4+CoRzaGsNjxAkhSOesGp3jd2P/5p5U10qe+NjKcpglI/UMFsUuPtlox4wbdJGI4Gh873txx6pcu04G4rgqexCAYgxmBGX2jdtNcI4nDqlBOZ6aRRfQAfYOAPNb9Y+/fKl7gGoj3FvrcyzbbkpKzk4tI5J2emVBxfbGqB5W+rqg9lOv+N1EwRAAjpiCYd4gERQFrSUe6mmRWhc/
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?+VALz9VBTAZ/FPhgU63o8OIofA+9daiu90IwkW94hfm335N/0FRYH0voLHWP?=
 =?us-ascii?Q?79tEvS4z0+99FVsqooJLoEnn+Jc/h3vMnOlMunQj6UzW156fHfT0u1BFCX/5?=
 =?us-ascii?Q?YDKVpW8F4z1Cf1xJtUxkosWC/bpsQ+UqlJ4/AvYrM70RdFiE/k824QipGggU?=
 =?us-ascii?Q?rDWu0ZJ5hOu2/R0nKhWhCXgZcqafWeRm3Zf96XySui8By/iadlGiT0BQDHUI?=
 =?us-ascii?Q?4bJOuptzuptl7Dw/dgMWisqsM8w9pDgYVCgmOIXgT+xUPjZrVchbn8d97Mx/?=
 =?us-ascii?Q?t7pQxurf40NHVwlNUKrsJCoiY2o4shEeowBglRvdL3eCw38ZHpU7feRQewyP?=
 =?us-ascii?Q?dTJTa40vs+Z9EXSQuFSckb6MFVbQfUsbga41cf0y6EyvyCaG/ze7kbn/2viw?=
 =?us-ascii?Q?g27THWOB+WDhokUEw/rl7y9BFEe+UIVoi3qAsd2XQwnJp9e3WcXZatJsL/TA?=
 =?us-ascii?Q?pxyHGgaE3YYYFT5eLNGPQwnyQrQVFKpfDj7nhLrzcSjI+0Rxh4oH3C+lnvqt?=
 =?us-ascii?Q?WqiVzsXiJMuYzeUALd39YiWw66MoySihgXM2WSehVGHsKDBRyxwcFqcyFKoz?=
 =?us-ascii?Q?EO+WHUq5paxMGaCsH+GWpO0wFY0C/4nvKS+L63pj/zGQx+svEljeka7lSl9V?=
 =?us-ascii?Q?kvd4cprJwbTHg8FbwLiKw/GCJzqkd4y+maySVeNDo9gnmYo4DAHI4EnXaOZO?=
 =?us-ascii?Q?yVyccZoLfITpiDirE9QXVBscllGEeWWxUG6DNEmDd9+FsppfVSblZk4PYFLQ?=
 =?us-ascii?Q?Mn4ZnGrD4fif8Af6hnpCiva+upOoaHI8DgbfSHtGPReb5tegbwb3iCjeVFpj?=
 =?us-ascii?Q?Ho0z0aWe71mUS4Pj7V5L9DNc4iew2MhE91Qzspol2ux6oiIT38VjOMwxHXJa?=
 =?us-ascii?Q?UoN1rGBeJNbOjYb197x6A7TGdddeS0FRhc4iNFAkZxra0iKkaz0xZ911D6xL?=
 =?us-ascii?Q?VWTwpt0gFJNsk7zqCg/aE+HjvgadXiTJVTx5dlqRdbasYUKJRYa2f9PpmXW6?=
 =?us-ascii?Q?nyLjvuaBfFtQ++eTF8liTNYHrTyZXrG2gUuwetYkyrCOJnMxDZwtsZyZ2Q+c?=
 =?us-ascii?Q?swRjw5YDbYduGMfjki04MbJty+LZdJIyEmLacBukghHvf0Xsa19FiTftLEDy?=
 =?us-ascii?Q?w8Ta0eG9H/NEnXc9wGVgaN8ZbR1dMqRvTaAQv4xLPvrdcv2A0p7vFJrWCdE6?=
 =?us-ascii?Q?42pVP/f7ImWqu0tkJc9Xim67RzdmM0lS3QiY06COiR1QsWJKa+qD8V5U4hCF?=
 =?us-ascii?Q?FcbgIBreHhyQYaKthF1POWz1JybVA6G/bvSlN4VNwPS7CmRFHQfnLnok96KX?=
 =?us-ascii?Q?V42HCwgbTDOKgytyGszp8uaxnMXxXebYqeH8bfVwLXGmeKzup9kmGlVDRyCl?=
 =?us-ascii?Q?C2IwkfcJAkEf5vXgVUuJfucuGviMlpcSJ8HgQ5o3LdcThI2m5cNQ9R75JmF8?=
 =?us-ascii?Q?5taS4xd3yhNivZ8+eyiaLgxqYfoPFdCkh179n9QX3mKFNTM45jysxA=3D=3D?=
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
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 0d1c5ad8-5c67-4557-d27f-08da547a5139
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2022 18:09:15.1677
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP4P284MB0947
X-Rspamd-Queue-Id: 4LSrxc2L05z3JLr
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=P83isKlU;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.79 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.91 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.989];
	 R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 FREEMAIL_FROM(0.00)[hotmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	 MIME_GOOD(-0.10)[text/plain];
	 DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[hotmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[40.92.97.79:from];
	 NEURAL_HAM_SHORT(-0.92)[-0.920];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[hotmail.com];
	 ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]
X-ThisMailContainsUnwantedMimeParts: N

Hi=20

This change unfortunately didnt compile on my 13-stable . I just git cloned=
 the CURRENT code, applied the patch and the build was fine.
I'll test it as soon as I finish the upgrade from stable to current here

I'll get back here when its finished=20


Thank you=20


-----Mensagem original-----
De: Hans Petter Selasky =20
Enviada em: quarta-feira, 22 de junho de 2022 14:08
Para: Tomoaki AOKI ; Ivan Quitschal 
Cc: freebsd-current@freebsd.org; Kurt Jaeger 
Assunto: Re: RES: RES: vt newcons mouse paste issue FIXED

On 6/22/22 18:48, Tomoaki AOKI wrote:
> Hi.
>=20
> Not actually tested, but this can cause breakage on non-ascii cases.
> Maybe also (or instead) iswspace() test would be needed.
> Possibly additional mbrtowc() in the argument of iswspace().
>=20
> Please see `man 3 multibyte` and `man 3 iswspace`.
> (Possibly more to see.)
>=20
> Characters in buf can be multibyte or wide char depending on locale,=20
> as vt can show at least UTF-8 characters.
>=20
> Sorry, not looked into enough how UTF-8 characters outside ascii are=20
> handled internally on vt.
>=20

Thanks for your feedback.

Now using the TCHAR_CHARACTER() macro, which is already used for space sepa=
ration.

See:
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Freviews=
.freebsd.org%2FD35552&data=3D05%7C01%7C%7C179337d1a7a340b8a9eb08da5471c=
67e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637915144907733421%7CUnkno=
wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC=
I6Mn0%3D%7C3000%7C%7C%7C&sdata=3Db4hKmkmuXxZ%2BjtSv75bG8qLIXMwo9Fzt64Nf=
VSnuDUU%3D&reserved=3D0

--HPS


From nobody Wed Jun 22 19:41:39 2022
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 0429085AA70;
	Wed, 22 Jun 2022 19:41:42 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSv052hMmz3l7F;
	Wed, 22 Jun 2022 19:41:41 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: by mail-ej1-x62c.google.com with SMTP id g26so15055919ejb.5;
        Wed, 22 Jun 2022 12:41:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to:cc;
        bh=B2oCYiDSJEpQheucaNerv/2u9WVGkqHyyGFhUEXxrVk=;
        b=TipbSBLU6iIET14+4peLm8+KNbLWkQ8aYIi5g6+l/RhZ2Sp0uP/Srn+kuRXkBtgBo+
         A5HSkmUjKvIOSMot/Niefcq6XAgUx/htH0Z/MV7AtBvyEaAo37n8IzmMzXxZwLDi47n/
         IFUVBkZ3oLqq5TLrLNE61yij/0lmSJsbLkbjZa2i/myAGTNTON7xZ9uEU71Zl6hQULR5
         c32t9XoH7LuJNdLfXt/BrLAVKegE/PRIHV4sqRav1UK7g59ibiqPGlHtkLYYxYUkYtng
         3k+L+YZqK+TXLNsD7FsQ53VZF6iBDJpfsE/mrrFZKfHzn+q9LC+VM2PQD5+qJJTKxt1H
         sDhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc;
        bh=B2oCYiDSJEpQheucaNerv/2u9WVGkqHyyGFhUEXxrVk=;
        b=haDS+Rjp+4OmIjcVh9cNN1FOZkckbBl1v1lASlDAt3UHWRFhjCbNC3+DkIEfRtGnyu
         GceSFzQpKpnPvkOu1kgKWLtN+Bbz0hGgmlgswkS6OJMhWBWMfBj76/eLrf36XQeRC/jT
         aX5wx5OLWzdnOTxZvuoiKRzgip+sx4QI5i0q2sjIHUOpXHOfC5C1IWv4WzWe5RhMjx37
         6QIAP9S8DvdTmPzw5ciD1wmUNb8jLaFhxJPwnXwXzNIPtR/Nh2RUE9z4HyyI4ejoQmhB
         qOQKJYUY+KCVXb+P3nHRcSVDwj2w1cuoKtjMcK0QeO5F0Aytjl9mrULV1AFcjn+uI8K+
         OIMQ==
X-Gm-Message-State: AJIora8FvfjR91V2/KGPvoQq5L65fl2mmXDJvAi2mE+8jzort9GSDVzo
	LcfENFgGQMkglbVOqVCushyyIWPHxcXx0se5+udvrw+sXRFBFhYymsg=
X-Google-Smtp-Source: AGRyM1uzech7EJut/irD3UmlmjrB6w0GTR9kkyPbz7MwkPtczxuzh16mShmCtztE6rZZOp5R/cwS7xXVmYpUwVthRJI=
X-Received: by 2002:a17:907:2cc3:b0:722:e993:c420 with SMTP id
 hg3-20020a1709072cc300b00722e993c420mr4453514ejc.145.1655926899946; Wed, 22
 Jun 2022 12:41:39 -0700 (PDT)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Received: by 2002:ab4:a183:0:0:0:0:0 with HTTP; Wed, 22 Jun 2022 12:41:39
 -0700 (PDT)
From: grarpamp 
Date: Wed, 22 Jun 2022 15:41:39 -0400
Message-ID: 
Subject: Posting Netiquette [ref: Threads "look definitely like" unreadable
 mess. Handbook project.]
To: freebsd-doc@freebsd.org
Cc: postmaster@freebsd.org, freebsd-current@freebsd.org, 
	freebsd-questions@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4LSv052hMmz3l7F
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=TipbSBLU;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=grarpamp@gmail.com
X-Spamd-Result: default: False [-3.16 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from];
	 NEURAL_HAM_SHORT(-0.16)[-0.160];
	 MLMMJ_DEST(0.00)[freebsd-doc,freebsd-current,freebsd-questions];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

Around 6/2x/22, Many  rammed their horribly formed
msgs upon others to parse:
> [Subject: MCE: Does this look possibly like a slot issue?]
> [snip]


Attention all list users...
Stop top-posting and bulk-quoting.
Just stop.
Go search and learn about and use the email post formatting netiquette.
For decades agreed reasons, please, just go learn and use those rules.
Your comms peers, the efficiency of the hive, the utility of archives
and search engines, and more... all thank you in advance.


Emails looking rather messy lately, just look at the photos,
improve that by raising awareness and examples of better...

FreeBSD needs to add an entire section on the
email post formatting netiquette to the Handbook,
and link it on the List Subscription pages, and in the List Welcome
emails, and even in quarterly automated administrivia post to all lists.

Make Reading Easy Again :)


[Cc'd until postmaster makes Bcc on lists work, so that useful
inclusions for others awareness can occur while maintaining
threading and helping minimize braindead cross-repliers.]

From nobody Wed Jun 22 21:55:20 2022
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 8DA8E8735E2
	for ; Wed, 22 Jun 2022 21:55:30 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LSxyT20hfz4ZM1;
	Wed, 22 Jun 2022 21:55:29 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=V1q9T9tHR9Lg2jiDOiUE2oFbsQbpttLAIko57woIZoY=; b=KF3byZuYcRuGUOFd4dz22RAUNk
	q1W4ze78vZmR2fSmj5dlK3KfNkEdh5UzxEhFzhXPAtwUL4sH5p9yIVbmf+47CCO/1Hnhb7UZ+WJWK
	WSJ0dX9MJR3qCYOgsHhVjaS08UMYHdbSTU5zWbENgYQmRB38Sd3Wcq871WT3xJgdMqeieRvYCwxmr
	lC23QMVoGYnRJilQlQiVpb4yCCpohpkz0SgMAau7PJ7DF+zYUCXtwb1qZLNN+9GY2oEHiooeu5JlF
	TcaawmRiIiKgCIwsW38l7xBWVMwZ53+QNjX5AG8Z73dNavuyS5fCyM36I0d2RlhEWCuN37xIgiWPO
	x9T+25Dw==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:15436 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1o48Jk-000Mah-UM;
	Wed, 22 Jun 2022 16:55:20 -0500
Received: from 2600:1700:210:b18f:641f:a1a3:8098:9ab1
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Wed, 22 Jun 2022 16:55:20 -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
Date: Wed, 22 Jun 2022 16:55:20 -0500
From: Larry Rosenman 
To: Michael Gmelin 
Cc: Alexander Motin , Freebsd current
 
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
In-Reply-To: 
References: <17529e76a2fd0a402a76d758c4f0afd2@lerctr.org>
 
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: multipart/alternative;
 boundary="=_f9442f7317b7aa11547f4e3e9a7a09cb"
X-Rspamd-Queue-Id: 4LSxyT20hfz4ZM1
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=KF3byZuY;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	 FREEFALL_USER(0.00)[ler];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[lerctr.org:+];
	 DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=_f9442f7317b7aa11547f4e3e9a7a09cb
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



On 06/18/2022 8:30 am, Michael Gmelin wrote:

>> 
> 
> That certainly sounds promising.
> Best
> Michael
> 
>> 

got the new controllers, and no sweat -- saw all 8TB on the drives 
(modulo one bad drive -- seller is replacing).

thanks all.

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_f9442f7317b7aa11547f4e3e9a7a09cb
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



On 06/18/2022 8:30 am, Michael Gmelin wrote:






















 
















 


That certainly sounds promising.


 

Best

Michael














 












 
















got the new controllers, and no sweat -- saw all 8TB on the drives (modu=
lo one bad drive -- seller is replacing). 


thanks all.




=
-- 
Larry Rosenman     &n=
bsp;            =
;   http://www.lerctr.org/~ler
Phone: +1 =
214-642-9640           &n=
bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=






--=_f9442f7317b7aa11547f4e3e9a7a09cb--

From nobody Thu Jun 23 03:01:18 2022
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 C3D9787C4E4;
	Thu, 23 Jun 2022 03:02:00 +0000 (UTC)
	(envelope-from grog@lemis.com)
Received: from smtp03.aussiebb.com.au (smtp03.aussiebb.com.au [121.200.0.94])
	(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 4LT4m83Nzjz3NrG;
	Thu, 23 Jun 2022 03:02:00 +0000 (UTC)
	(envelope-from grog@lemis.com)
Received: from localhost (localhost [127.0.0.1])
	by smtp03.aussiebb.com.au (Postfix) with ESMTP id 7667B1A004D;
	Thu, 23 Jun 2022 13:01:23 +1000 (AEST)
X-Virus-Scanned: Debian amavisd-new at smtp03.aussiebb.com.au
Received: from smtp03.aussiebb.com.au ([127.0.0.1])
	by localhost (smtp03.aussiebb.com.au [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id NDW_Ur8mcglH; Thu, 23 Jun 2022 13:01:23 +1000 (AEST)
Received: by smtp03.aussiebb.com.au (Postfix, from userid 119)
	id 6660A1A002B; Thu, 23 Jun 2022 13:01:23 +1000 (AEST)
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
	smtp03.aussiebb.com.au
X-Spam-Level: *
X-Spam-Status: No, score=1.4 required=10.0 tests=KHOP_HELO_FCRDNS,RDNS_DYNAMIC,
	SPF_HELO_NONE autolearn=disabled version=3.4.4
Received: from eureka.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253])
	by smtp03.aussiebb.com.au (Postfix) with ESMTP id 1ACEB1A003E;
	Thu, 23 Jun 2022 13:01:19 +1000 (AEST)
Received: by eureka.lemis.com (Postfix, from userid 1004)
	id B4C452635BD; Thu, 23 Jun 2022 13:01:18 +1000 (AEST)
Date: Thu, 23 Jun 2022 13:01:18 +1000
From: Greg 'groggy' Lehey 
To: grarpamp 
Cc: freebsd-doc@freebsd.org, postmaster@freebsd.org,
	freebsd-current@freebsd.org, freebsd-questions@freebsd.org
Subject: Re: Posting Netiquette [ref: Threads "look definitely like"
 unreadable mess. Handbook project.]
Message-ID: <20220623030118.GA59423@eureka.lemis.com>
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-sha1;
	protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp"
Content-Disposition: inline
In-Reply-To: 
Organization: The FreeBSD Project
Phone: +61-3-5309-0418
Mobile: +61-490-494-038.  Use only as instructed.
WWW-Home-Page: https://www.FreeBSD
X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F  09AC 22E6 F290 507A 4223
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Rspamd-Queue-Id: 4LT4m83Nzjz3NrG
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Spamd-Result: default: False [-4.00 / 15.00];
	 REPLY(-4.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--17pEHd4RhPHOinZp
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wednesday, 22 June 2022 at 15:41:39 -0400, grarpamp wrote:
> Around 6/2x/22, Many  rammed their horribly formed
> msgs upon others to parse:
> ...
> FreeBSD needs to add an entire section on the
> email post formatting netiquette to the Handbook,
> and link it on the List Subscription pages, and in the List Welcome
> emails, and even in quarterly automated administrivia post to all lists.

In fact we have guidelines, just not exactly where you might expect.
"How to get Best Results from the FreeBSD-questions Mailing List"
(https://docs.freebsd.org/en/articles/freebsd-questions/) contains:

  Unless there is a good reason to do otherwise, reply to the sender
  and to FreeBSD-questions.

  Include relevant text from the original message. Trim it to the
  minimum, but do not overdo it. It should still be possible for
  somebody who did not read the original message to understand what
  you are talking about.

  Use some technique to identify which text came from the original
  message, and which text you add. I personally find that prepending
  =E2=80=9C>=E2=80=9D to the original message works best. Leaving white spa=
ce after
  the =E2=80=9C> ;=E2=80=9D and leave empty lines between your text and the=
 original
  text both make the result more readable.

  Put your response in the correct place (after the text to which it
  replies). It is very difficult to read a thread of responses where
  each reply comes before the text to which it replies.

  Most mailers change the subject line on a reply by prepending a text
  such as "Re: ". If your mailer does not do it automatically, you
  should do it manually.

  If the submitter did not abide by format conventions (lines too
  long, inappropriate subject line) please fix it. In the case of an
  incorrect subject line (such as "HELP!!??"), change the subject line
  to (say) "Re: Difficulties with sync PPP (was: HELP!!??)". That way
  other people trying to follow the thread will have less difficulty
  following it.

  In such cases, it is appropriate to say what you did and why you did
  it, but try not to be rude. If you find you can not answer without
  being rude, do not answer.

Arguably these recommendations should be separated out into their own
page.  Re-reading them, I see that there is no explicit line length
recommendation.  That should be included.

And yes, I agree entirely with your concerns, though without my core
hat.

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

--17pEHd4RhPHOinZp
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAmKz134ACgkQIubykFB6QiOK1gCghWwLqEXUMbKR8WI5abC7wR0Q
NdYAn2+u90RsgdBRD4ukeQsyiI+qNKWo
=i2Fs
-----END PGP SIGNATURE-----

--17pEHd4RhPHOinZp--

From nobody Thu Jun 23 06:33:04 2022
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 03C1C86C923;
	Thu, 23 Jun 2022 06:33:15 +0000 (UTC)
	(envelope-from grog@lemis.com)
Received: from smtp03.aussiebb.com.au (smtp03.aussiebb.com.au [121.200.0.94])
	(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 4LT9Rt0ZRzz4Yk6;
	Thu, 23 Jun 2022 06:33:13 +0000 (UTC)
	(envelope-from grog@lemis.com)
Received: from localhost (localhost [127.0.0.1])
	by smtp03.aussiebb.com.au (Postfix) with ESMTP id B74661A0015;
	Thu, 23 Jun 2022 16:33:07 +1000 (AEST)
X-Virus-Scanned: Debian amavisd-new at smtp03.aussiebb.com.au
Received: from smtp03.aussiebb.com.au ([127.0.0.1])
	by localhost (smtp03.aussiebb.com.au [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id cQTNrwBcGz8N; Thu, 23 Jun 2022 16:33:07 +1000 (AEST)
Received: by smtp03.aussiebb.com.au (Postfix, from userid 119)
	id A7F251A0010; Thu, 23 Jun 2022 16:33:07 +1000 (AEST)
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
	smtp03.aussiebb.com.au
X-Spam-Level: *
X-Spam-Status: No, score=1.4 required=10.0 tests=KHOP_HELO_FCRDNS,RDNS_DYNAMIC,
	SPF_HELO_NONE autolearn=disabled version=3.4.4
Received: from eureka.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253])
	by smtp03.aussiebb.com.au (Postfix) with ESMTP id 5B8CD1A0003;
	Thu, 23 Jun 2022 16:33:05 +1000 (AEST)
Received: by eureka.lemis.com (Postfix, from userid 1004)
	id F21082635BD; Thu, 23 Jun 2022 16:33:04 +1000 (AEST)
Date: Thu, 23 Jun 2022 16:33:04 +1000
From: Greg 'groggy' Lehey 
To: Polytropon 
Cc: grarpamp , freebsd-doc@FreeBSD.org,
	postmaster@FreeBSD.org, freebsd-current@FreeBSD.org,
	freebsd-questions@FreeBSD.org
Subject: Re: Posting Netiquette [ref: Threads "look definitely like"
 unreadable mess. Handbook project.]
Message-ID: <20220623063304.GB59423@eureka.lemis.com>
References: 
 <20220623030118.GA59423@eureka.lemis.com>
 <20220623060320.aad6a631.freebsd@edvax.de>
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-sha1;
	protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h"
Content-Disposition: inline
In-Reply-To: <20220623060320.aad6a631.freebsd@edvax.de>
Organization: The FreeBSD Project
Phone: +61-3-5309-0418
Mobile: +61-490-494-038.  Use only as instructed.
WWW-Home-Page: https://www.FreeBSD
X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F  09AC 22E6 F290 507A 4223
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Rspamd-Queue-Id: 4LT9Rt0ZRzz4Yk6
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of grog@lemis.com has no SPF policy when checking 121.200.0.94) smtp.mailfrom=grog@lemis.com
X-Spamd-Result: default: False [0.89 / 15.00];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[grog];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 DMARC_NA(0.00)[FreeBSD.org];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 RCPT_COUNT_FIVE(0.00)[6];
	 HAS_ORG_HEADER(0.00)[];
	 RCVD_COUNT_THREE(0.00)[4];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_SPAM_MEDIUM(1.00)[0.999];
	 NEURAL_SPAM_LONG(1.00)[0.999];
	 NEURAL_HAM_SHORT(-0.21)[-0.212];
	 MLMMJ_DEST(0.00)[freebsd-current,freebsd-doc,freebsd-questions];
	 FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com];
	 SIGNED_PGP(-2.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:4764, ipnet:121.200.0.0/24, country:AU];
	 FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com];
	 FREEMAIL_CC(0.00)[gmail.com,FreeBSD.org]
X-ThisMailContainsUnwantedMimeParts: N


--K8nIJk4ghYZn606h
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thursday, 23 June 2022 at  6:03:20 +0200, Polytropon wrote:
> On Thu, 23 Jun 2022 13:01:18 +1000, Greg 'groggy' Lehey wrote:
>>   [...] I personally find that prepending
>>   ">" to the original message works best. Leaving white space after
>>   the "> " and leave empty lines between your text and the original
>>   text both make the result more readable.
>
> Prepending what? After the what? Seems there is a charset mismatch.

Ugh.  Yes, you're right.

> Or is it just my MUA displaying nonsense (which would be new to me).
> Oh the joy of UTF-8... ;-)

What happened here was that I copied the text from the (UTF-8) web
page into a text that was (I think) implicitly ISO 8859.  My copy of
the message also shows this mutilation.  But strangely, replying to
this message, I find that the text has been automatically recovered.
It doesn't stay that way: in the editor it looks correct, but the MUA
displays it incorrectly.  The issue was with the quotation marks, and
it should look correct above now.

> Otherwise, I completely agree to the concept that form and content
> should match, and that form can help a lot to improve readability
> and accessibility of information in general.

And people shouldn't make the kind of mess that I managed to make :-(

Does anybody have an opinion on character set recommendations?  I
think we should ask for UTF-8 if at all possible.

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

--K8nIJk4ghYZn606h
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAmK0CSAACgkQIubykFB6QiODDACfVJqzU9JuginmRhxAPW8X9wiX
BZgAnAiCJmD3EXEykp7IDy06Rq0JR4NY
=yNKB
-----END PGP SIGNATURE-----

--K8nIJk4ghYZn606h--

From nobody Thu Jun 23 08:14:40 2022
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 06F4085E0D2;
	Thu, 23 Jun 2022 08:14:45 +0000 (UTC)
	(envelope-from grarpamp@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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LTChz3X64z4r0C;
	Thu, 23 Jun 2022 08:14:43 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: by mail-ed1-x533.google.com with SMTP id eo8so27425273edb.0;
        Thu, 23 Jun 2022 01:14:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-transfer-encoding;
        bh=K6xNzL0t1HmM3DCVYAA37mlpatRKNBDFMhseepUsbaM=;
        b=mhSYAsodirw0qiaDct2t3S2NASnFv0dLZGQ/Smcf2nxHXgCRxAq3JGgvXEXxgqg3w3
         26eolkrgvFH3OpW8k77driN9AlHlihK9LM7BJldSyf3KZNnDT3oYWRijwsPLs7MBPFwS
         WuxGLZsw/XAAAc2sCHIJpMJub9is33ufmHtFYvwPbkIjcjwKm1O3uh7OfkchM/VBZOpj
         gzuzmWbV3q5yD8J48NAQ/ZDtVByOimb8Dx3zA1H9tvTSyjajMmpjAfy54huH7hG8aLS7
         XfQh3WmAjjp1Ehp+TYWZr4D8SRO+8Rr8+nlzkqlrx9+AeevmGxZj2GWwe+l6QNrq/0uO
         lJAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc:content-transfer-encoding;
        bh=K6xNzL0t1HmM3DCVYAA37mlpatRKNBDFMhseepUsbaM=;
        b=kRgdoSN/b1aM21c7fjqCaL/Jys3SJpoqXe4UExFJn0aKERiGcTU6saGQK7r6PRvBwC
         EA0ZaOTjQDotC5oIEeqk3jgdINt8cZ6zYzL/lWfWU8wylmJxE+pnXfNE22TWBoIKdz9p
         XkqbwmqZxD0B75eRhu/NPwQ719eWPwQAdgV1T2GePMqyoe3NiMMkQs/q0+57EjN5VttN
         Wd+RRkJUaJqiVwE55GkXtOuSt+qpupRYPbAqs43NQGuwJyx1wRrquUPmeMREXBBFT4lG
         yIDtD7+8cWAarl2njaDqbijOB2mJXrtDd/qxx4/8/hKZFHKyft/slM+pRQ5MdSdiNSJW
         IRTQ==
X-Gm-Message-State: AJIora9VtlPLNDZ257gY6ODQcoKcT+Rk+TxNUKNmTrDIM4w6XDzZbWQs
	kk3tG/j30DkJAmnURlQ0TXQPE/Gb4TlB6v01SO+s5XwgPQ0h0St9X8M=
X-Google-Smtp-Source: AGRyM1slxuMSCQSYptUZOr4FovOyFY/TOnW3ZySO2RjA0fnXyFZp/EeOZChlTMcOPSHtqLef97BYiHTSylqK0d1iCJg=
X-Received: by 2002:a05:6402:249e:b0:42d:bb88:865b with SMTP id
 q30-20020a056402249e00b0042dbb88865bmr8903818eda.141.1655972081375; Thu, 23
 Jun 2022 01:14:41 -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
Received: by 2002:ab4:a183:0:0:0:0:0 with HTTP; Thu, 23 Jun 2022 01:14:40
 -0700 (PDT)
In-Reply-To: <20220623060320.aad6a631.freebsd@edvax.de>
References: 
 <20220623030118.GA59423@eureka.lemis.com> <20220623060320.aad6a631.freebsd@edvax.de>
From: grarpamp 
Date: Thu, 23 Jun 2022 04:14:40 -0400
Message-ID: 
Subject: Re: Posting Netiquette [ref: Threads "look definitely like"
 unreadable mess. Handbook project.]
To: freebsd-doc@freebsd.org
Cc: postmaster@freebsd.org, freebsd-questions@freebsd.org, 
	freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4LTChz3X64z4r0C
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=mhSYAsod;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=grarpamp@gmail.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[1.000];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from];
	 MLMMJ_DEST(0.00)[freebsd-doc,freebsd-questions,freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

>> the =C3=A2=E2=82=AC=C5=93> ;=C3=A2=E2=82=AC  and leave empty lines betwe=
en your text and the original

> Seems there is a charset mismatch.
> MUA displaying nonsense
> Oh the joy of UTF-8... ;-)

https://unicode-table.com/en/sets/quotation-marks/

The pages ...

https://docs.freebsd.org/en/books/handbook/eresources/#eresources-mail
https://docs.freebsd.org/en/articles/freebsd-questions/
https://docs.freebsd.org/en/articles/mailing-list-faq/

... are intermixing standard ASCII double quotes with questionably
gratuitous choice of using left and right double quotes via UTF-8,
which then may get slaughtered by non UTF-8 enabled cut-paste,
systems, lists, gui's, desktops, apps, and MUAs along the way.

Perhaps smack the typeset within all pages back down to ASCII,
except where no standard ASCII convention is available to
substitute for symbols, ie: (c) is the fine sub for =C2=A9,
and ASCII still fits within UTF-8 meta declarations, which may
be needed for =E2=82=BF which has no ASCII substitute, and of
course for presenting non ASCII languages.

And perhaps systems can consider enabling UTF-8 if needed
to render and handle things like =E2=82=BF, say for whenever foundation
gets to accepting those easy donations and crowdfunding.

No idea what the ';' in the '=E2=80=9C> ;=E2=80=9D' is doing there for.

A proper page would need to add a number of the missing
email formatting netiquettes (such as no HTML), and actual
photo examples of former bad chaos and new good result, etc...
to be considered a good format, subject, and addressing
netiquette guide rule page.

Consider if "FreeBSD Articles" is best hier for a page that
may becoming more often directly linked or included into
prospective list user's signup clickstream, quarterly admin,
friendly cluebat hints, etc.

And it's mostly written to apply only to -questions
when it should be completely agnostic.

So the pages may be currently serving lesser preventive
or curative use as far as lists could go.


> Unless there is a good reason to do otherwise, reply to the sender
> and to FreeBSD-questions.

Well for subscription-required-to-post lists, only list-reply
is needed... which also follows address line bloat minimization,
reduces personal reply issues, reduces "Stop copying me
direct when I'm on list", etc.


> Arguably these recommendations should be separated out into their own pag=
e.

Such soley dedicated content would make the page easier
for people to link to wherever such reference is needed.
The current pages don't, and they're bleeding [partially] duplicated
and differing guidance content across each other.

If the page was good enough, it would get picked up
by search engines and other projects.


[-current, and even -questions, could probably be dropped
now, for -doc, or wherever else is best.]

From nobody Thu Jun 23 17:15:55 2022
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 41D2186C00D
	for ; Thu, 23 Jun 2022 17:16:08 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LTRjg3kSbz3CPS
	for ; Thu, 23 Jun 2022 17:16:07 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe29.google.com with SMTP id j1so11192368vsj.12
        for ; Thu, 23 Jun 2022 10:16:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=Ie7zC05vlqwgQSXWE+vtDFnw9TA9QsJXS/uEpOOx3B8=;
        b=Kw/Kgu9xizSNvUArgVq7zMQAWBiA2eN8dO4Mu46uakLGF/9kd2ZmIdeZ/Z4lA82teE
         8CLf4ZUmW9lKn6jgFeEx6jtVzYzaVyTlOA/FPx3WyEmniMp5LlKJ3WHWZsyvw2VLfZql
         4wrbyBp6AtbT/UyE3xo/NTY6O7lWajHsclidfR+MBBex3RBPm32HtEmT7g7BroxkBOhA
         iLtQ+EIegRsl1LDM49fw2nQQHf0X9jHzDkyHjOgYhJPsxzHxuVWj9uf9XX+VHiGc+e1I
         f0JK1D2jsptMlEAj7tsSpRJB1zebEfVLzJ8NNacIQLXWLJSqwqwUTccjvPS+v3q5ep1y
         H0JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=Ie7zC05vlqwgQSXWE+vtDFnw9TA9QsJXS/uEpOOx3B8=;
        b=12lXxPPjLPfeGEF+pAlNdaV8FZBkHz1C4DxbYXY8+v+Mlcbibdvafer/pxNsWs4JlB
         fcd6zjq8SR1H1fMrMLz0hNUjrGqmChtKyInDcOBzskaYQeFe3g/uUGDXIjYwhtF9tlgN
         KCGfya5jL/v4T8t5cmzVF7t5z8xCpupzQnDx8FaOYOQPO617sOwS1q6HKrUUXFtbWvLu
         aLrIanfvRnrY3vzzcIGlebAhWtCgWsG0e9V82+lCmIEvaAZ8YmTPWKLfkypF4q0pnNrk
         73nIM2WuL0A6W7x55jWk01Wq1Wv0I+ChjU+2QhQuOb7hIjUAdUoSwfEtQ6U0lyAcnghF
         7oFg==
X-Gm-Message-State: AJIora919exMLuquocvWa25E9Gb/GchPPXANfCgnsuidd5JpA9rFNTqy
	xtrq4cO5q4xWJMrtlOftV/OxQxK6l/uKf/q1E+Mf36e1pc6XQQ==
X-Google-Smtp-Source: AGRyM1tco8fs3BZV0Xk1ti2EKvr7KnRUe+lwdO9xGV9MJ7linBoQ5XR9g4FFoPOUZ/w2jviJYZ4PVnG/kT94h2xAw+k=
X-Received: by 2002:a67:fbd3:0:b0:354:2f5b:6477 with SMTP id
 o19-20020a67fbd3000000b003542f5b6477mr11173113vsr.76.1656004566808; Thu, 23
 Jun 2022 10:16:06 -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: <20210520180155.3e23500e@bsd64.grem.de> <20210520185917.GL14975@funkthat.com>
 
  
 <20220619140624.21263e46@bsd64.grem.de>
In-Reply-To: <20220619140624.21263e46@bsd64.grem.de>
From: Warner Losh 
Date: Thu, 23 Jun 2022 11:15:55 -0600
Message-ID: 
Subject: Re: Reducing SIGINFO verbosity
To: Michael Gmelin 
Cc: Ceri Davies , Conrad Meyer , 
	"freebsd-current@freebsd.org" 
Content-Type: multipart/alternative; boundary="000000000000f3b27405e2209bed"
X-Rspamd-Queue-Id: 4LTRjg3kSbz3CPS
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="Kw/Kgu9x";
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e29) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e29:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000f3b27405e2209bed
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 19, 2022 at 6:06 AM Michael Gmelin  wrote:

>
>
> On Fri, 21 May 2021 08:36:49 -0600
> Warner Losh  wrote:
>
> > On Fri, May 21, 2021 at 7:38 AM Ceri Davies 
> > wrote:
> >
> > > On Thu, May 20, 2021 at 03:57:17PM -0700, Conrad Meyer wrote:
> > > > No, I don=E2=80=99t think there=E2=80=99s any reason to default it =
differently on
> > > > stable
> > > vs
> > > > current. I think it=E2=80=99s useful (and I prefer the more verbose=
 form,
> > > > which isn=E2=80=99t the default).
> > >
> > > I agree that there's no reason for the default to be different, but
> > > I would say that it is much easier for someone who knows that there
> > > is a default to be changed to change it, than it is for someone who
> > > does not. Therefore, if the information is not useful to someone
> > > who does not know how to get rid of it, then it should default to
> > > not being displayed, IMHO.
> > >
> >
> > I plan on changing the default for non-INVARIANT kernels back to
> > the old behavior.
> >
> > INVARIANT kernels will keep this behavior because it's a debugging
> > kernel and this is one more thing to help debugging problems.
> >
>
> Did this ever happen? I just installed a fresh 13.1-RELEASE production
> system (non-INVARIANT kernel) and it seems like SIGINFO still outputs
> kernel stack information.
>

https://reviews.freebsd.org/D35576 for those who wish to weigh in.

Warner


> Cheers
> Michael
>
> --
> Michael Gmelin
>

--000000000000f3b27405e2209bed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Jun 19, 2022 at 6:06 AM Micha=
el Gmelin <freebsd@grem.de> wr=
ote:




On Fri, 21 May 2021 08:36:49 -0600

Warner Losh <imp@bsd=
imp.com> wrote:



> On Fri, May 21, 2021 at 7:38 AM Ceri Davies <ceri@submonkey.net>

> wrote:

> 

> > On Thu, May 20, 2021 at 03:57:17PM -0700, Conrad Meyer wrote:=C2=
=A0 

> > > No, I don=E2=80=99t think there=E2=80=99s any reason to defa=
ult it differently on

> > > stable=C2=A0 

> > vs=C2=A0 

> > > current. I think it=E2=80=99s useful (and I prefer the more =
verbose form,

> > > which isn=E2=80=99t the default).=C2=A0 

> >

> > I agree that there's no reason for the default to be differen=
t, but

> > I would say that it is much easier for someone who knows that the=
re

> > is a default to be changed to change it, than it is for someone w=
ho

> > does not. Therefore, if the information is not useful to someone<=
br>
> > who does not know how to get rid of it, then it should default to=


> > not being displayed, IMHO.

> >=C2=A0 

> 

> I plan on changing the default for non-INVARIANT kernels back to

> the old behavior.

> 

> INVARIANT kernels will keep this behavior because it's a debugging=


> kernel and this is one more thing to help debugging problems.

> 



Did this ever happen? I just installed a fresh 13.1-RELEASE production

system (non-INVARIANT kernel) and it seems like SIGINFO still outputs

kernel stack information.

https://reviews.freebsd.org/D35576 fo=
r those who wish to weigh in.

Warner
=C2=A0

Cheers

Michael



-- 

Michael Gmelin




--000000000000f3b27405e2209bed--

From nobody Thu Jun 23 19:10:02 2022
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 7CA9E864CB8
	for ; Thu, 23 Jun 2022 19:10:18 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4LTVFP32pjz3wDB;
	Thu, 23 Jun 2022 19:10:17 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 12F76260100;
	Thu, 23 Jun 2022 21:10:10 +0200 (CEST)
Message-ID: 
Date: Thu, 23 Jun 2022 21:10:02 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: RES: RES: RES: vt newcons mouse paste issue FIXED
Content-Language: en-US
To: Ivan Quitschal ,
 Tomoaki AOKI 
Cc: "freebsd-current@freebsd.org" ,
 Kurt Jaeger 
References: 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LTVFP32pjz3wDB
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.35 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 ARC_NA(0.00)[];
	 NEURAL_SPAM_SHORT(0.95)[0.946];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[hotmail.com,dec.sakura.ne.jp];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

Please test this latest version:
https://reviews.freebsd.org/D35552

--HPS

From nobody Thu Jun 23 19:32:25 2022
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 73EBE8689DD
	for ; Thu, 23 Jun 2022 19:32:35 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2083.outbound.protection.outlook.com [40.92.97.83])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LTVl60z94z4Txt;
	Thu, 23 Jun 2022 19:32:34 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=awshz+D317EGODbmY2JspyRvS72g1N4tYKTNGle9PRtSA++fmxG1ktjnDCn0nie+/8xefyi5d84GbhLVl9jyjM1zwUu0rYgHHzcR8nolBkEet12H8CpMOYxAzj/AaQG9EpEQE5QY+M4BZlAtY9gfXmXLOwnQ1XfC3bICqrxzAVZRb8Y85cGzRVEqQdX1K2D/+btrIocv8LCLd3Vx9dINrw3K5VR6HsIRaRieXqgDNYNtmo/w4voZjb8oMw7mznMw9w7/fOP5sD4j+PKiIgk3YIu89DG0xW1MgSKvfwAf48wk3nqKUkc0iuanMGDMQ9z7G89JHqscowVEo3oNBJuU6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=muNAkLiug1/i5j4E96g5M5U4zkQxvnsdqEd9ZOkEgSk=;
 b=B9Wgy2zSdeuiBUDZQxRWPksgCsW35p/xtYDY2RlFksiF5Yyg/eHDlM3GI/OR/HrcoaSFDVDyxLIUKwO7pvTMt5Sv690MXU34o6oyJbMxSOV9ktkcrMZ45YD9SHWR3EPqHqUi0qbvMBdFzwFD0JsswSIoNLZm80nGKwC9K1N2Yo7UtjRbE7q+JPef3NiQ9EaRH+KBJEGS6DScKGjbpLH8ukuCdDUKQIqOyMVs615njni+FW4h9JofvRYHbn7SQtnV37+IsofvOqKHhs/aoKTz9zQoe6r2EEdULLjszkpGEYjbAEE7cOH0FtRkW+xJuCvLxiJ7jgwjk0J8Pa1BxNl0hg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=muNAkLiug1/i5j4E96g5M5U4zkQxvnsdqEd9ZOkEgSk=;
 b=APqq3BaAs0QA64+uqEANYtMzFmmd8NVFMYOAi79V+vA49ED9MnAF8FdLJIjeanDBb5hh109ENgU3KOGNGKwkapTk2LoGOnDd/qv0g7FYQLQcX1J7CXrmbDN7eMlMauIRwwvE/VqRTQf3r1X5/3/gbhBRPaDK5uMFJMmTZg/6NeAmImdSkzfiD31fCe8yQNGhY551BEEvNSFX2+GDUueRiAeyb/Go5fxzqPEICQZfLFi/Vw/LDJSBNdfsS/m9wRdAWj2dDsGKSb1oQJMwmd0T7avGjVVPuMwB4H8LHb+Ur3ps9oX1q+3AWDV8azNKanbvquUCAw/sdUmvW+H6sI3pKA==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CPYP284MB0145.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:72::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.15; Thu, 23 Jun
 2022 19:32:25 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%7]) with mapi id 15.20.5353.022; Thu, 23 Jun 2022
 19:32:25 +0000
From: Ivan Quitschal 
To: Hans Petter Selasky , Tomoaki AOKI
	
CC: "freebsd-current@freebsd.org" , Kurt Jaeger
	
Subject: RES: RES: RES: RES: vt newcons mouse paste issue FIXED
Thread-Topic: RES: RES: RES: vt newcons mouse paste issue FIXED
Thread-Index:
 AQHYhjcChIuK2z3T9ky9hQYmy4Xi761bZ2wAgAAFqsCAAAe9AIAAD1ewgAAfSYCAAAVfAIAAD1twgAGlEgCAAAOCoA==
Date: Thu, 23 Jun 2022 19:32:25 +0000
Message-ID:
 
References:
 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
 
In-Reply-To: 
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [BxBqtpavTDnGVKi2ng6lQHFF2UO/AjeGX/k1Lmm9o0eKJ/0ZgYNDGPJuBjkhcusc]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 08f86a04-a4c6-4088-cb95-08da554f19ec
x-ms-traffictypediagnostic: CPYP284MB0145:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 tkup0asX79eBh525YIJ+29W/8Lno1NJKyKpyY7wVnwJkbhX/FoObs0SJW10dVhfSjAR1H1J9WFyWNvBdgtOrfntWsxGBXMJNGqDsQf01F0mVeOqUYNz5JsBQ83trIE4It+dUT87WnL85805oWagrzONzGMyD1IEBgyuI+H5Zs3ITKOcO4gJ9X2tKqSPmSJXR8yuoP9PChY4Oewd8Jl9vlLkVxoyqzcHInINTmbA94LEBeIloJiTgqC/qOKApk9d9IQ1xrzA4QodeoUshHp7q8w1m4JqIA1YsnNRbt/BR7WyA3brSjIU4DQLQ6mh6kd2rwH6Fzm8JnxkjuHAtAi0f5WqlLQZrHulDtCBGM8etT3NOPpsYTE2UTslZNHBBQ/530ILh4DvIJPAXn3ErsFTodDvb9rGIOh7ztFxg5jGwx3WICgl+TXUv1CCYbYjD2eT1xTUFZPOHNfPJO6VpSYlBWDlJTfA8ztuUcSqtWLV8YG209puNAZhdQvbT950ni3QQ6lnkYuQvLxrQeZf0O9PVRmKGcts7+X5BI7/8YAj1IDHiLMm1R7hpiEfc2NeOvbneSHUfwi/KmqFnpapkZwj80PZhCcaoO18YiuH2auZ9oOEC//LzkNBrBPFtMoRxQ/mt
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?3fTrSFgdzw0cAfu2YFX1bxcAt+hh7YePunxIKJT9+ScS/oFo+P5c4WK3RzK8?=
 =?us-ascii?Q?/P4GEyYTafDRps+er4VqFSnxiqzJc62SPWzrEKkWEXNpp6AR2EH0GDZ7BLHZ?=
 =?us-ascii?Q?vecP545U4+75NgFaIMOb3LLRMvxnqqSeG2AC6U7+xNb3p+NRedcqpYo7ehK/?=
 =?us-ascii?Q?4DXN90lBp2s++82bFnMVw+7ThsCxPSQxt6aU6FcdIdDpxFSBQndvtjW91Jz4?=
 =?us-ascii?Q?Su5BBURjfl/bg3NpIE/bvQ89EmNoca1A72f60BkO+E9RXljb4Xg0+TycxoKR?=
 =?us-ascii?Q?y05jUWX+kvD7CwwhqHEMfWe/Kyitp8LNulfvGuoQASwWkmAPYUcXOW+N9mdW?=
 =?us-ascii?Q?pA0KLmwMweWJ0eAq2puNj1zdlqpKMeyf7G68rXTC3wVmFOYRdcuuI+5KKoc6?=
 =?us-ascii?Q?ONm8T4p9VfOEnZfn0A6CalZNcRhL7R3+/r7tnKqLYCeQ2himN0ikkst2IXBk?=
 =?us-ascii?Q?lIEuGevpWs31ZNtowt40vPE2rFy47BcMbVZm/+mK7kkATGV3aQSnqq5NGiBh?=
 =?us-ascii?Q?AkAMpo/snuVPBZlbg6v3xnRe19nB/zM7aHPtEvaDHggxIcKdNxp2gLYRlq++?=
 =?us-ascii?Q?L8anMiJhxphk0d3EoSifesr02i81LKaUP4zZDXv13ILy58MCKcDjni1L5m2/?=
 =?us-ascii?Q?Yiu05ADJwuEGvw4PVC07DV32eH0U6y0sjC4ykUXMjWYtokxa8j6NmqKal8lB?=
 =?us-ascii?Q?q6UW9a2tHrBRqyD5r2JFpZWAZDKtb2DPfVK9fPq9puS4MonuY61J1VFiycZ+?=
 =?us-ascii?Q?FKGLU86xaNqxYX8OA89y8Fyvf0YHWrilKaqg4y4WXBqEBp+E3BPk/uOP8YW8?=
 =?us-ascii?Q?2k7HCiXKgwwIJdB7dpX5VVs1cj9TULe4RBkW8ifpmkEKWMIXDhyqNTXVirfM?=
 =?us-ascii?Q?RGZzoaRGeml/LOvfgAgna8y58nLH2NKfJuL/r0+uVXePl4Xkmy9NfxCQt2WS?=
 =?us-ascii?Q?gtN/1qmTE+wLMQFzHlyJv3vDaGNy52eg+avn5O7FhsFbdlhbh8+OVRRTkXET?=
 =?us-ascii?Q?5fceogd/mngCZ2PMSxZ8w5j6OBKmlUjzzwrnkxmM1IGJe5JX+hIyhEjn9ASY?=
 =?us-ascii?Q?FMWiUReC9I19bDXxoJT25tzUaylsqvCmzE4HZFALALUwDvGKU0ME9X6DuLbK?=
 =?us-ascii?Q?oYPiWHuJrI3WEzZIxBnTdJWRhrzqFR/iPkeG0M9viABKJnOEZcCdj20zQqTH?=
 =?us-ascii?Q?ZBiAIviblE7wU5M67HTCkcvjobqQ88KLTB/6eeVTrN+uI6kp3TDYBlOqWUZx?=
 =?us-ascii?Q?TLpAT/f3sOFeHFS4bkqKBJmhxGmJHiM91UioxQaO5iAskHArvF4sYPXgNmoD?=
 =?us-ascii?Q?qbDoiqIMDkmmjXIggr6A8+OO?=
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
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 08f86a04-a4c6-4088-cb95-08da554f19ec
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2022 19:32:25.1761
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPYP284MB0145
X-Rspamd-Queue-Id: 4LTVl60z94z4Txt
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=APqq3BaA;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.83 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.995];
	 R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 FREEMAIL_FROM(0.00)[hotmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	 MIME_GOOD(-0.10)[text/plain];
	 DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(0.99)[0.995];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[hotmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[40.92.97.83:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[hotmail.com];
	 ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]
X-ThisMailContainsUnwantedMimeParts: N


>Hi,
>
>Please test this latest version:
>https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Freview=
s.freebsd.org%2FD35552&data=3D05%7C01%7C%7C8a105d5de0164d4b2eac08da554b=
feb2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637916082154929613%7CUnkn=
own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV=
CI6Mn0%3D%7C3000%7C%7C%7C&sdata=3D0qxyXDZSJ3lElK7HGgK200mwrV3%2Bn%2Ftj5=
%2B5VbxFLxOA%3D&reserved=3D0

>--HPS

Hi Hans

The version before worked just fine. I will test this one and let you know
But I have a suggestion to make:

Today the trim is being done on every line , even on the last one . for exa=
mple, if you mark the mouse:

|from here        |to here
|                          |=20
"Blablabla            "(you can see there are 10 spaces )
_____________

It will only copy the Blablabla (im talking about the *last* line only, or =
when it's just one line)

What if you do something like this?

Moving this part of code into the "non last line block"

		/* Add new line for all rows, but not for last one. */
		if (r !=3D e.tp_row)
		{
			/* Trim trailing whitespace from each line, if any. */
			for (; i !=3D j; i--) {
				if (TCHAR_CHARACTER(buf[i - 1]) =3D=3D ' ')
					buf[i - 1] =3D '\0';
				else
					break;
			}
			buf[i++] =3D '\r';
		}

This way you would trim all the lines but the last one.
Just an idea , what do you think?

Thanks
--tzk

From nobody Thu Jun 23 19:33:57 2022
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 05B50869C05
	for ; Thu, 23 Jun 2022 19:34:08 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LTVmt1fWpz4VgH;
	Thu, 23 Jun 2022 19:34:06 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id B0D5A260100;
	Thu, 23 Jun 2022 21:34:03 +0200 (CEST)
Message-ID: <3b66a26a-d170-860b-6b58-7514b49a2c79@selasky.org>
Date: Thu, 23 Jun 2022 21:33:57 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: RES: RES: RES: RES: vt newcons mouse paste issue FIXED
Content-Language: en-US
To: Ivan Quitschal ,
 Tomoaki AOKI 
Cc: "freebsd-current@freebsd.org" ,
 Kurt Jaeger 
References: 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LTVmt1fWpz4VgH
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.06 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 NEURAL_SPAM_SHORT(0.58)[0.577];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.34)[-0.339];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[hotmail.com,dec.sakura.ne.jp];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received]
X-ThisMailContainsUnwantedMimeParts: N

On 6/23/22 21:32, Ivan Quitschal wrote:
> 
>> Hi,
>>
>> Please test this latest version:
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.freebsd.org%2FD35552&data=05%7C01%7C%7C8a105d5de0164d4b2eac08da554bfeb2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637916082154929613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0qxyXDZSJ3lElK7HGgK200mwrV3%2Bn%2Ftj5%2B5VbxFLxOA%3D&reserved=0
> 
>> --HPS
> 
> Hi Hans
> 
> The version before worked just fine. I will test this one and let you know
> But I have a suggestion to make:
> 
> Today the trim is being done on every line , even on the last one . for example, if you mark the mouse:
> 
> |from here        |to here
> |                          |
> "Blablabla            "(you can see there are 10 spaces )
> _____________
> 
> It will only copy the Blablabla (im talking about the *last* line only, or when it's just one line)
> 
> What if you do something like this?
> 
> Moving this part of code into the "non last line block"
> 
> 		/* Add new line for all rows, but not for last one. */
> 		if (r != e.tp_row)
> 		{
> 			/* Trim trailing whitespace from each line, if any. */
> 			for (; i != j; i--) {
> 				if (TCHAR_CHARACTER(buf[i - 1]) == ' ')
> 					buf[i - 1] = '\0';
> 				else
> 					break;
> 			}
> 			buf[i++] = '\r';
> 		}
> 
> This way you would trim all the lines but the last one.
> Just an idea , what do you think?

Sounds reasonable. Let me update the patch.

--HPS


From nobody Thu Jun 23 19:41:38 2022
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 14B6086B8B4
	for ; Thu, 23 Jun 2022 19:41:47 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4LTVxk3bC5z4YHX;
	Thu, 23 Jun 2022 19:41:46 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 48450260100;
	Thu, 23 Jun 2022 21:41:45 +0200 (CEST)
Message-ID: <790bd76d-890f-cf09-a30d-c2e5fba91ec5@selasky.org>
Date: Thu, 23 Jun 2022 21:41:38 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: vt newcons mouse paste issue FIXED
Content-Language: en-US
To: Ivan Quitschal ,
 Tomoaki AOKI 
Cc: "freebsd-current@freebsd.org" ,
 Kurt Jaeger 
References: 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LTVxk3bC5z4YHX
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.56 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 NEURAL_SPAM_MEDIUM(0.74)[0.744];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[hotmail.com,dec.sakura.ne.jp];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

https://reviews.freebsd.org/D35552

Updated! Please test!

--HPS

From nobody Thu Jun 23 21:02:58 2022
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 C7E6287615C
	for ; Thu, 23 Jun 2022 21:03:08 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2057.outbound.protection.outlook.com [40.92.97.57])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LTXlb6dhTz4hZd;
	Thu, 23 Jun 2022 21:03:07 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=c6Oc0T07qHfs1FR/K3WqekpJYuruKJgZO4IW/87e1A94HXnm3HR3030MW8CyIlGn+xjPRs6wI41FhNxhx+fEtpj3tuYFgFSB1sG52RWGsEmaVyV+rON2HHqib5RjV3xquEbR4kYD+bkkGvWy+l9CpeVvTgJTMdhfDK5tFL3ooH5/w5X2mkM2338LjfiGqs3bkAPxFnccfJUgQzEJIWDP5WO5jSnrnfrs2s51fOkbO/g22Aur3w2Pq439XlNFzX0/1lGEBSOxUwarRPwcv9ZnuPL2jCFDgAZ5JFSRY6Tzg7nnlG51aMkNHzxRTj7cERgnFamuUdZWTnkE9we8eRm+Fw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=WaigXlJCLVoJyd2fz4CIi1v2vqYkNb1T2eQ5oBuWSDs=;
 b=OHV0tIssr+/s2mnxxZ5ciEF4VhsFn2OdSDYHGmcrC4bvO4rMzgSedglF1xdFkj6qdyjQdsSmEycVwCmyr7hna5QzY9j6pc3S/+awOBGvg/riuDPLaYLXZTeIyXgUpXbdgpJqOriUxVBsvJOajsgm5u+qvtjB1bRDlRHMK6tCmlDiL8s3ur6nsCjtgdwwhMSTrH/9G+qfGuYNf8ZWV67X3kONZqB7M8WFTfNWVCAlH9iWaznMMJVhqI8les+Bjs+bKb0GQ1sq45grnLT5EnpFY1JvSjo9AvMelDjiPi9h7FIrKXPBkiP+ZdSdax9I3XNn19dXvkYhoDrYtXz9DwXgfA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=WaigXlJCLVoJyd2fz4CIi1v2vqYkNb1T2eQ5oBuWSDs=;
 b=EcCSEhsWDouWubudJTgDp3RNLU9nBzLmhPh329e0LP1FRBuhQwkx1lARvonHKeT5MR3bDLMdAnQbm+/Pbg7ordVY1WAdGOQxbNqR8S95y4kouxg0ytj5JVhfB88d8zeQGYsSEAG7AakvYEIRaKTpx6PyoFQ4A5pnvZv4rG3joepmjh5rH0mBYRewe1lm/Qatqjq6OK8uVVn89ZaYa6nS7NS/Pxj3H4cmkpWnEmgUOehbRijH+Okgz3KWeIOUL8uSY1Z91/TdXlNFB0S/TGGa1Aoa9zZyK3vaWBkQ67xxW9EsInMBnoMAD99h2wZlfrNTi46AR+rhHu6KzGuAOznbZw==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by ROAP284MB0094.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:3b::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.15; Thu, 23 Jun
 2022 21:02:58 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%7]) with mapi id 15.20.5353.022; Thu, 23 Jun 2022
 21:02:58 +0000
From: Ivan Quitschal 
To: Hans Petter Selasky , Tomoaki AOKI
	
CC: "freebsd-current@freebsd.org" , Kurt Jaeger
	
Subject: RES: vt newcons mouse paste issue FIXED
Thread-Topic: vt newcons mouse paste issue FIXED
Thread-Index: AQHYhzlHrdrJWzhCvUOR2bz9NNv1e61deCFA
Date: Thu, 23 Jun 2022 21:02:58 +0000
Message-ID:
 
References:
 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
 
 
 <790bd76d-890f-cf09-a30d-c2e5fba91ec5@selasky.org>
In-Reply-To: <790bd76d-890f-cf09-a30d-c2e5fba91ec5@selasky.org>
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [MRMURURnCovCO2TXY2tqGovxC1rY0lZzmqsqCSw+YActYUnfLMjltnDKGxMJ3YBP]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7335ad35-87ca-42cb-1d2b-08da555bc03a
x-ms-traffictypediagnostic: ROAP284MB0094:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 8RMrpOT5oTndIz6Tvy1KNHI8HXc6NlhJ5z4MmG9dz7rbGSba0sVN34r6PuZ6zMZNHvyo6rtGyrvvHyXghv2Y+NYb0w554lKm9UAQTZmfNa+7Yo0ZVOV2sDNfa/HRpxgYo2HrWUWBF5Y1qNUzseE8lHgMZc7uxcgWZfiGXwJBhgS9NhZYrpLAqevZ72PnWCdewg51wYjFYnClChfKfcSH4dwkz0Ql8VKlQKjY9caDrZCWrrIktN/hXr2E2kGTpuqL7E7+THSx9B3pM8VMmg5LirV4qMZvDgluwxXC/hSJA30VmB1zEBz2gi3Y6SeAgoZR/6cep2E+U1XV52SYkaL0eFUxRnfgX6yAd+0ght4O3YziYdOHYHvdf0RpDO+D4imbz8or+/wkcKO11mG/cdbCC+VMp1nzwTodM5BpI60GTC5LWdLTUDmgrc13LK6PVck0S2ZS9dLVlV+KGRjUWeaCl+DO3pmPG8evp+TNuwB1l24U5/0KHaSWBdmZWpv94hqdH0rpRhTRGuZDljySY0DhUgP6zgfwYlaJ7/TJ72gsdjYAFbnVGRGwNDqYg4QZthphrP2Zx8q2pVTvsXVG2dtji+1tvqPLSFK1uAfRUy3oUHEQaay2H6v6/pdnxQXYw0/P
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?lhJOLBj8r3LbImqhi7+ny66L/1e6puxjPG62atEqrrQfyKp4BhXwJZxmp+EC?=
 =?us-ascii?Q?IeEvs2jVcoWhVJEfeWMT5l9JlRBpx5YJb0uwLQr3dQHsg+l6jCLhkEDd2luR?=
 =?us-ascii?Q?IJtyIOMQE+njCSftUxdl9gMHwyRhKRFa18fTghrJe8abFREI3kXG+K0ev/50?=
 =?us-ascii?Q?8lH0c3TBZ/9Bvv02FQpdi51iAp/svQlm9CAaLwCc+zYNkPDubZd1BXaMnbuo?=
 =?us-ascii?Q?joybEqEzo2w6JXOR5L1tW9h+HgUgsYph9+JDdkrFGWEliuZeBrxgJB1s9aKk?=
 =?us-ascii?Q?JDsm20KylT2VgHeeRQHGd5o4klTvoqpUWkY8n43GNB7KZp8yOa1td8lr/N+p?=
 =?us-ascii?Q?mjXilxPbColzyy8gV4RBlIrRLOJRRWU4ctICTlvIfVHd4cNsxsuaevc3+gtF?=
 =?us-ascii?Q?Y44Gily3warlGlk1t9mOWZmPPCiSl6Z8sDFJY/gASgb9TvDyfdhSIHHlvpSw?=
 =?us-ascii?Q?HPLPbPTwL20BEVGnGOx1njtU1+1UF1s155NoOzPuZn4nO3OGLIsfjniaPGSD?=
 =?us-ascii?Q?2+CeJonA4dRosFxMLq0Inbu5bimQRdTWsd0bWPuGdRxhoFMGit9sjET8UJdG?=
 =?us-ascii?Q?iz/qCO+siy/gzGMEfYG/aSyBGY1EwDtewFuzBm0aifIC//P0tCV5kr4GDbTi?=
 =?us-ascii?Q?Toce5DXDmT2G3ektlly/hg5siskoWXKBQR2mB8FkZpBLdr0UmIg64oKF1LYO?=
 =?us-ascii?Q?y0bixOLobhgzoq5ARq/kQO5NvzDuVe2oPlRQSHfZP11nE387kKdEZCx0Kd+P?=
 =?us-ascii?Q?07w56+V/vbQA5DXFBNkRBjQWDPuxgdDilJRp2Sr0SenATvUMiYEcE7zo2wNV?=
 =?us-ascii?Q?8RWjIxUEW+8+rkprVNlSIGNcv8Kdy4FORTHBu6QqSjSMkS3laouY0Rkh+JZH?=
 =?us-ascii?Q?nqyGV+NZ3ui0VE8UEJOM3wiXQxy+SKK56IncyKTIFGv81NrqyIR646IosW2h?=
 =?us-ascii?Q?7sT5peTuVpxWa7sHBgWB4w9MrgCZclwrd5XbwgbeNLjzjEG1uGIUcT+8NWAW?=
 =?us-ascii?Q?9V2WHRMfUXk3K2VmJgi790MaxMjmJuWqYyUrCJEKkD0K8ZarbsMmwoA/zvX2?=
 =?us-ascii?Q?rNw7HDIMiaXbXuEAXnHCIMUdGWqNBGIgadgFPrxznvm+CDlOSQkaFfdNTkdO?=
 =?us-ascii?Q?NeGgVQ4p/rCusFEsAFK2iSFWJRUCh0YUmRBdrXEjhK5EtNlggvWD7fp9U8bA?=
 =?us-ascii?Q?vc+R9QOO7VcOfGK04FT0CD232ILecUY9lvUF3BUmR+5+LxZHEEo0S9u9wGy9?=
 =?us-ascii?Q?IIlj/4dYYivHg+j08IrpF9xVPx4UASq57cmjIxKBuYSjmBLgzATLBsCZDaKO?=
 =?us-ascii?Q?Y7k2at+IwfXiurlyM/ey+Ey3?=
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
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 7335ad35-87ca-42cb-1d2b-08da555bc03a
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2022 21:02:58.1296
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB0094
X-Rspamd-Queue-Id: 4LTXlb6dhTz4hZd
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=EcCSEhsW;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.57 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.99 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.995];
	 R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 FREEMAIL_FROM(0.00)[hotmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	 MIME_GOOD(-0.10)[text/plain];
	 DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[hotmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[40.92.97.57:from];
	 NEURAL_HAM_SHORT(-1.00)[-0.996];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[hotmail.com];
	 ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]
X-ThisMailContainsUnwantedMimeParts: N

>Hi,
>
>https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Freview=
s.freebsd.org%2FD35552&data=3D05%7C01%7C%7C1e7987d282f44dbb06d508da5550=
6810%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637916101088006624%7CUnkn=
own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV=
CI6Mn0%3D%7C3000%7C%7C%7C&sdata=3D01V%2FDWju9Jm8L6ttwodYTAZdV%2F8PEUdJx=
ipeoR3l12Q%3D&reserved=3D0
>
>Updated! Please test!
>
>--HPS


Hi Hans,

Working perfect over here. Thank you=20

Now the only thing missing from SC that I can remember is when we used to c=
lick 3 times in the same line to copy,=20
the paste used to come with an  in the end of line , good for pastin=
g command-lines and such.

And the paste size buf is limited to around half of a FHD screen I see .
But that's no big deal , vt console mouse is totally badass now.

Thanks again=20

--Ivan




From nobody Fri Jun 24 00:00:04 2022
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 84218867495;
	Fri, 24 Jun 2022 00:00:04 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LTcgm33Q7z3KZV;
	Fri, 24 Jun 2022 00:00:04 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1656028804;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=;
	b=nKWiAIfwqbrJsPYkTEWdPpstLUtmPm7mDsxyKGUUCTdX6Yphge4OWD0dm+u7apfGc8XoMw
	FCyB8qBk5+8dMdgCcaRvaY1r4qbB1g083TcUklsyBGX9aawXoS7PJQAhxv7e+Ox/9fQ3Wv
	4XA6YNOM51vdrklc2uj5A4CvZCITog0/B4zIyAmiyJpVI2C0Wuj05oVLSXFbmmpp668h19
	XgnSuvm1w4zGP01A7QYjj0mIfSaY7ejgRniroDvopR8qM0aIdaBqd8qzllbQaQK0luX6sq
	iNs33LJJTsUBM4M8g9q6d49DtepixVnlRLLDOewoSwcXmLZRVNPdpFLDZmPTaQ==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id 29E751D7F3; Fri, 24 Jun 2022 00:00:04 +0000 (UTC)
To: freebsd-quarterly-calls@FreeBSD.org
Subject: [LAST OFFICIAL REMINDER] Call for 2022Q2 quarterly status reports
Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,info@bsdcan.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org
Message-Id: <20220624000004.29E751D7F3@freefall.freebsd.org>
Date: Fri, 24 Jun 2022 00:00:04 +0000 (UTC)
From: Lorenzo Salvadore 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1656028804;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=;
	b=XpXvaTczxaUg4UKV8eBg/b2UrXxDWN+FjYPuCdpDuqJ25zk0CKVh4+CDIGn7eYVkbzaS8c
	jAQlTDxUKiDSVuKVNEdWWYtbbvx4ZxZDCEC/fS0T7M4pZDp4dIUGuQKuk1Ckrsqg5KLCB4
	ThKiQb3eq8fQCma+k+oNWFlXjZ9Yn/DrGI0s8xEQATsC+A1z3sT0BtGH07VPJOFcM1eLmJ
	dNDxU3X4k8f8vqtWXKmZ2JZCtGVDtL24g02DvcWyzkh+f+fqlYdDjOq6BENhvv/QMfAZNr
	qC1Cp4YCey8I3A6LiepMK5OQtYCwoxn9oHFiUWVISq05TEUJQMPKPVMr3UMa8A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1656028804; a=rsa-sha256; cv=none;
	b=VbLDKjBzS3huT1u1W1YmuTsj1eD8w57D5v4iFJujysRRrQt73suFR/rl8xxMgUsxu6NTJ8
	JBd8cy+ZJ9atVTYzqyNvZdXeoJhxxtIF6y8GPH1XvOB2rfDhPDn1cScgz1Pvi+mRChfxLj
	X36Lg3mtBWktjW1OhVmMkjMCJmZyHQo5hNrqtZG5NEQH8upUukdpyjP+1c7enPfdt3LexV
	rRcGS46mkg2+J4Fhd+QpeNIWfz65XGnhdpmAfI61cBD3lF2KQVYiOUlhfQEElMzjfjcZhD
	3hvK39pOXEmtHhoh3wh81VFGYYPHuEUX0WikvumfOQOQwVQOdztdyOxUHIUHxA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
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

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
June, 30th 2022 for work done since the last round of Quarterly Reports:
April 2022 - June 2022.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the AsciiDoctor template, fill it in, and
email it to quarterly-submissions@FreeBSD.org.
The new AsciiDoctor template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc

We look forward to seeing your 2022Q2 reports!

Thanks,

Lorenzo Salvadore (on behalf of quarterly@)

From nobody Fri Jun 24 14:02:15 2022
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 D322B871735
	for ; Fri, 24 Jun 2022 14:02:22 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LTzMc4w3Rz4j27;
	Fri, 24 Jun 2022 14:02:20 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 25OE2FXm046252;
	Fri, 24 Jun 2022 23:02:15 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Fri, 24 Jun 2022 23:02:15 +0900
From: Tomoaki AOKI 
To: Hans Petter Selasky 
Cc: Ivan Quitschal ,
        "freebsd-current@freebsd.org"
 ,
        Kurt Jaeger 
Subject: Re: vt newcons mouse paste issue FIXED
Message-Id: <20220624230215.82e02ac661cd7594624a1845@dec.sakura.ne.jp>
In-Reply-To: <790bd76d-890f-cf09-a30d-c2e5fba91ec5@selasky.org>
References: 
	
	
	<41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
	
	<20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
	
	
	
	
	<790bd76d-890f-cf09-a30d-c2e5fba91ec5@selasky.org>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LTzMc4w3Rz4j27
X-Spamd-Bar: +
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [1.70 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 HAS_ORG_HEADER(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[123.1.85.147:received];
	 RCVD_TLS_LAST(0.00)[];
	 R_DKIM_NA(0.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_SPAM_SHORT(0.96)[0.962];
	 NEURAL_HAM_LONG(-0.92)[-0.917];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[sakura.ne.jp];
	 AUTH_NA(1.00)[];
	 NEURAL_SPAM_MEDIUM(0.25)[0.255];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 R_SPF_NA(0.00)[no SPF record];
	 FREEMAIL_CC(0.00)[hotmail.com,freebsd.org];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 23 Jun 2022 21:41:38 +0200
Hans Petter Selasky  wrote:

> Hi,
> 
> https://reviews.freebsd.org/D35552
> 
> Updated! Please test!
> 
> --HPS

As I've commented on Phabricator, works perfect except one CJK-related
mis-behaviour.

IDEOGRAPHIC (Full-width) SPACE (E38080, U+3000) seems to be treated
as regular character, not as space.

Possibly, any other space characters in code points other than CJK
could have problem, but not at all tested. Sorry.

Anyway, thanks in great advance!

-- 
Tomoaki AOKI    

From nobody Fri Jun 24 14:48:11 2022
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 498568790D7
	for ; Fri, 24 Jun 2022 14:48:27 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LV0Nn6GBYz4qMK;
	Fri, 24 Jun 2022 14:48:25 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 43DB7260657;
	Fri, 24 Jun 2022 16:48:17 +0200 (CEST)
Message-ID: <5bd74766-f2f0-3df2-0e8c-adabd110f913@selasky.org>
Date: Fri, 24 Jun 2022 16:48:11 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: vt newcons mouse paste issue FIXED
Content-Language: en-US
To: Tomoaki AOKI 
Cc: Ivan Quitschal ,
 "freebsd-current@freebsd.org" ,
 Kurt Jaeger 
References: 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
 
 
 <790bd76d-890f-cf09-a30d-c2e5fba91ec5@selasky.org>
 <20220624230215.82e02ac661cd7594624a1845@dec.sakura.ne.jp>
From: Hans Petter Selasky 
In-Reply-To: <20220624230215.82e02ac661cd7594624a1845@dec.sakura.ne.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LV0Nn6GBYz4qMK
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-2.68 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 FROM_HAS_DN(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-0.38)[-0.377];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 FREEMAIL_CC(0.00)[hotmail.com,freebsd.org];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 6/24/22 16:02, Tomoaki AOKI wrote:
> On Thu, 23 Jun 2022 21:41:38 +0200
> Hans Petter Selasky  wrote:
> 
>> Hi,
>>
>> https://reviews.freebsd.org/D35552
>>
>> Updated! Please test!
>>
>> --HPS
> 
> As I've commented on Phabricator, works perfect except one CJK-related
> mis-behaviour.
> 
> IDEOGRAPHIC (Full-width) SPACE (E38080, U+3000) seems to be treated
> as regular character, not as space.
> 
> Possibly, any other space characters in code points other than CJK
> could have problem, but not at all tested. Sorry.
> 
> Anyway, thanks in great advance!
> 

Hi Tomoaki,

Should IDEOGRAPHIC (Full-width) SPACE (E38080, U+3000) also be checked 
when selection single words?

--HPS

From nobody Fri Jun 24 15:29:26 2022
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 9F9EF87FC46
	for ; Fri, 24 Jun 2022 15:29:35 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4LV1JG63tlz3DZt;
	Fri, 24 Jun 2022 15:29:34 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 54626260282;
	Fri, 24 Jun 2022 17:29:33 +0200 (CEST)
Message-ID: <5196d98c-7b3a-55b4-3ef7-227b19b66721@selasky.org>
Date: Fri, 24 Jun 2022 17:29:26 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: vt newcons mouse paste issue FIXED
Content-Language: en-US
From: Hans Petter Selasky 
To: Tomoaki AOKI 
Cc: Ivan Quitschal ,
 "freebsd-current@freebsd.org" ,
 Kurt Jaeger 
References: 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
 
 
 <790bd76d-890f-cf09-a30d-c2e5fba91ec5@selasky.org>
 <20220624230215.82e02ac661cd7594624a1845@dec.sakura.ne.jp>
 <5bd74766-f2f0-3df2-0e8c-adabd110f913@selasky.org>
In-Reply-To: <5bd74766-f2f0-3df2-0e8c-adabd110f913@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LV1JG63tlz3DZt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	 MID_RHS_MATCH_FROM(0.00)[];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_LONG(-1.00)[-0.999];
	 TO_DN_SOME(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 FREEMAIL_CC(0.00)[hotmail.com,freebsd.org];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

Hi Tomoaki,

On 6/24/22 16:48, Hans Petter Selasky wrote:
> IDEOGRAPHIC (Full-width) SPACE

According to this page:

https://jkorpela.fi/chars/spaces.html

There are multiple uni-code characters which are spaces. Should we 
support them all?

--HPS

From nobody Fri Jun 24 16:19:49 2022
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 24C6C869FA4;
	Fri, 24 Jun 2022 16:19:57 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LV2QN6dlkz3QPJ;
	Fri, 24 Jun 2022 16:19:56 +0000 (UTC)
	(envelope-from 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 25OGJooi071370;
	Fri, 24 Jun 2022 09:19:56 -0700 (PDT)
	(envelope-from bsd-lists@bsdforge.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
Date: Fri, 24 Jun 2022 09:19:49 -0700
From: Chris 
To: grarpamp 
Cc: freebsd-doc@freebsd.org, postmaster@freebsd.org,
        freebsd-questions@freebsd.org, freebsd-current@freebsd.org
Subject: Re: Posting Netiquette [ref: Threads "look definitely like"
 unreadable mess. Handbook project.]
In-Reply-To: 
References: 
 <20220623030118.GA59423@eureka.lemis.com>
 <20220623060320.aad6a631.freebsd@edvax.de>
 
User-Agent: UDNSMS/17.0
Message-ID: <4de546f68061f774e53553fb542bed7a@bsdforge.com>
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_6f97bcf9a38a183be41a336faf38c43f"
X-Rspamd-Queue-Id: 4LV2QN6dlkz3QPJ
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Spamd-Result: default: False [0.00 / 15.00];
	 ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	 local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_6f97bcf9a38a183be41a336faf38c43f
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed

On 2022-06-23 01:14, grarpamp wrote:
>>> the “> ;† and leave empty lines between your text and the original
> 
>> Seems there is a charset mismatch.
>> MUA displaying nonsense
>> Oh the joy of UTF-8... ;-)
> 
> https://unicode-table.com/en/sets/quotation-marks/
> 
> The pages ...
> 
> https://docs.freebsd.org/en/books/handbook/eresources/#eresources-mail
> https://docs.freebsd.org/en/articles/freebsd-questions/
> https://docs.freebsd.org/en/articles/mailing-list-faq/
> 
> ... are intermixing standard ASCII double quotes with questionably
> gratuitous choice of using left and right double quotes via UTF-8,
> which then may get slaughtered by non UTF-8 enabled cut-paste,
> systems, lists, gui's, desktops, apps, and MUAs along the way.
> 
...
> A proper page would need to add a number of the missing
> email formatting netiquettes (such as no HTML), and actual
> photo examples of former bad chaos and new good result, etc...
> to be considered a good format, subject, and addressing
> netiquette guide rule page.
> 
> Consider if "FreeBSD Articles" is best hier for a page that
> may becoming more often directly linked or included into
> prospective list user's signup clickstream, quarterly admin,
> friendly cluebat hints, etc.
> 
What is the possibility of getting the/a "netiquette" link in
the FreeBSD Mailinglist footer that is already appended to all
the messages? This would only be a small addition, with a quick/
easy reference to the subject at hand.

Just my .2¢

Chris

--=_6f97bcf9a38a183be41a336faf38c43f
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_6f97bcf9a38a183be41a336faf38c43f--

From nobody Fri Jun 24 16:51:50 2022
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 9A4EA86DFFE
	for ; Fri, 24 Jun 2022 16:52:01 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LV37M6p36z3kWK;
	Fri, 24 Jun 2022 16:51:59 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 25OGpoJr066689;
	Sat, 25 Jun 2022 01:51:50 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Sat, 25 Jun 2022 01:51:50 +0900
From: Tomoaki AOKI 
To: Hans Petter Selasky 
Cc: Ivan Quitschal ,
        "freebsd-current@freebsd.org"
 ,
        Kurt Jaeger 
Subject: Re: vt newcons mouse paste issue FIXED
Message-Id: <20220625015150.4f57017e7098ea591f57bd2a@dec.sakura.ne.jp>
In-Reply-To: <5196d98c-7b3a-55b4-3ef7-227b19b66721@selasky.org>
References: 
	
	
	<41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
	
	<20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
	
	
	
	
	<790bd76d-890f-cf09-a30d-c2e5fba91ec5@selasky.org>
	<20220624230215.82e02ac661cd7594624a1845@dec.sakura.ne.jp>
	<5bd74766-f2f0-3df2-0e8c-adabd110f913@selasky.org>
	<5196d98c-7b3a-55b4-3ef7-227b19b66721@selasky.org>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LV37M6p36z3kWK
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [0.53 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 HAS_ORG_HEADER(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[123.1.85.147:received];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	 MIME_TRACE(0.00)[0:+];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.92)[-0.925];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_SPAM_SHORT(1.00)[1.000];
	 NEURAL_HAM_LONG(-0.94)[-0.941];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[sakura.ne.jp];
	 AUTH_NA(1.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 R_SPF_NA(0.00)[no SPF record];
	 FREEMAIL_CC(0.00)[hotmail.com,freebsd.org];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, 24 Jun 2022 17:29:26 +0200
Hans Petter Selasky  wrote:

> Hi Tomoaki,
> 
> On 6/24/22 16:48, Hans Petter Selasky wrote:
> > IDEOGRAPHIC (Full-width) SPACE
> 
> According to this page:
> 
> https://jkorpela.fi/chars/spaces.html
> 
> There are multiple uni-code characters which are spaces. Should we 
> support them all?
> 
> --HPS

Nice page!

Maybe not all. My guess based on "Sample" and "Width of the character"
fields are as below. At the first column,

'Y': Should be treated as space / word separator
'N': Should NOT be treated as space / word separator
'U': Unknown for me. Need native speaker to determine. 

Maybe someone have objections, but basically I've considered breakable
spaces as space characters. See also URL [1] below.

  Special cases:
    *Looking sample, U+1680 is shown as dash so considered 'N'.
    *Treated "QUAD" as just a graphical (non-semantic) use so
     considered as 'N'.
    *Considered U+205F as 'N', as I thought, for mathematical usage,
     unintended line break could cause fatal confusion.


  Code   Name of the character
Y U+0020 SPACE
N U+00A0 NO-BREAK SPACE
N U+1680 OGHAM SPACE MARK
Y U+180E MONGOLIAN VOWEL SEPARATOR
N U+2000 EN QUAD
N U+2001 EM QUAD
Y U+2002 EN SPACE (nut)
Y U+2003 EM SPACE (mutton)
Y U+2004 THREE-PER-EM SPACE (thick space)
Y U+2005 FOUR-PER-EM SPACE (mid space)
Y U+2006 SIX-PER-EM SPACE
N U+2007 FIGURE SPACE
Y U+2008 PUNCTUATION SPACE
Y U+2009 THIN SPACE
Y U+200A HAIR SPACE
Y U+200B ZERO WIDTH SPACE
N U+202F NARROW NO-BREAK SPACE
N U+205F MEDIUM MATHEMATICAL SPACE
Y U+3000 IDEOGRAPHIC SPACE
N U+FEFF ZERO WIDTH NO-BREAK SPACE

Maybe, the best would be looking into how unicode normalization treat
them. But we Japanese would want U+3000 treated as space.


[1] https://en.wikipedia.org/wiki/Non-breaking_space

-- 
Tomoaki AOKI    

From nobody Sat Jun 25 09:29:43 2022
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 8A17387F081
	for ; Sat, 25 Jun 2022 09:30:00 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4LVTGt6dnlz3GNj;
	Sat, 25 Jun 2022 09:29:58 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id CE35C260282;
	Sat, 25 Jun 2022 11:29:50 +0200 (CEST)
Message-ID: <9ad847b7-859f-9e58-f424-1e2ef6546439@selasky.org>
Date: Sat, 25 Jun 2022 11:29:43 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: vt newcons mouse paste issue FIXED
Content-Language: en-US
To: Tomoaki AOKI 
Cc: Ivan Quitschal ,
 "freebsd-current@freebsd.org" ,
 Kurt Jaeger 
References: 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
 
 
 <790bd76d-890f-cf09-a30d-c2e5fba91ec5@selasky.org>
 <20220624230215.82e02ac661cd7594624a1845@dec.sakura.ne.jp>
 <5bd74766-f2f0-3df2-0e8c-adabd110f913@selasky.org>
 <5196d98c-7b3a-55b4-3ef7-227b19b66721@selasky.org>
 <20220625015150.4f57017e7098ea591f57bd2a@dec.sakura.ne.jp>
From: Hans Petter Selasky 
In-Reply-To: <20220625015150.4f57017e7098ea591f57bd2a@dec.sakura.ne.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LVTGt6dnlz3GNj
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.43 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 ARC_NA(0.00)[];
	 NEURAL_SPAM_MEDIUM(0.69)[0.687];
	 NEURAL_HAM_LONG(-1.00)[-0.997];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.82)[-0.816];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 FREEMAIL_CC(0.00)[hotmail.com,freebsd.org];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 6/24/22 18:51, Tomoaki AOKI wrote:
> On Fri, 24 Jun 2022 17:29:26 +0200
> Hans Petter Selasky  wrote:
> 

Hi Tomoaki,

Please retest:
https://reviews.freebsd.org/D35552

Pushing this after some local tests.

--HPS

From nobody Sat Jun 25 16:01:44 2022
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 EAD9A87306B;
	Sat, 25 Jun 2022 16:04:35 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LVf2B5Zj6z4jZh;
	Sat, 25 Jun 2022 16:04:34 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: by mail-wr1-x435.google.com with SMTP id w17so7060263wrg.7;
        Sat, 25 Jun 2022 09:04:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=message-id:date:mime-version:user-agent:content-language:to
         :references:from:subject:in-reply-to;
        bh=vzByXcnJRExWM9TsBo/CWUBXu+ju5v4JaOpdAPo8GTY=;
        b=C3MBtRWwA5LglbLeMpUhXGmpl+9Wl+I7nZuktY71n/AeQ8TzFjAvff0j9WAMVX3SJj
         rxeZ/90xXxWT9MQ4v3pMcKkSk7bW2rtEjQB95Tq/FS3S2BvhMpxsQEGVQJi3m4TC+mC2
         nBuM2zdBx7d94zhmv1dL1zhs/KK6QC1emk965TOD5GbGEUz2aM3Ea7R+M4UengqxAhy6
         CWjp9Io6qFNFJM//QkWcnGbO/pgWlqSs5wagW8vQgpKJso/rgpL9tq/ArTIHpc7uaFKk
         pl1nneqzYwtRPaAHwTQzzHZmNyg8sYBEZ+QzPBVBYgrYICKR/x7Kulrr1DNgXnF9kgeJ
         4p0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:message-id:date:mime-version:user-agent
         :content-language:to:references:from:subject:in-reply-to;
        bh=vzByXcnJRExWM9TsBo/CWUBXu+ju5v4JaOpdAPo8GTY=;
        b=icJ0SvF74av5vC/UP5Lx37pWDu4JNQZyFFpzsFTGKuLWSFjrqvER4mNr5MrCQygmFI
         lWwV05D5Iz2lkcIRvo1I/D2xaGB6G5xcb17kwHpN0WgypibxPe5ZocKbZimBcD2NNYuk
         jp2w6gMOx0j1IVMuPLQfjMLqZJrFPZPxG7pfbzwxmRQ3RIjx28MGyEYPOR8TBlvfBRwS
         hOrGofiYS2acWePL4G52a8TJABefjEftxt0Qt778nU4E8KJu9Aiy+V/2ZfSuyrBB0Tpe
         oCz70SQpIlZ2XLaghlwTLaCcHN87cnNJrTvDypzvmboCjWoSgjVB99MY1w+d7Vy5clpm
         A1yQ==
X-Gm-Message-State: AJIora8e8VbnIgjmWJOiP/qcKBJbuFLl6s7mk6yGaESzrrq1szv2IbqE
	V9XjikU2o2Ljq6l77Ypw7sp9D+Qil/qxVQ==
X-Google-Smtp-Source: AGRyM1t2HC/HjbZ3xBvs0Siif1oSSRiFGGP3m7ZuEdeRSNLZV4XixYUdYWQC/cj04C5Djt2Cl7r8Xw==
X-Received: by 2002:a5d:64c7:0:b0:21b:9661:6aac with SMTP id f7-20020a5d64c7000000b0021b96616aacmr4355134wri.496.1656173073097;
        Sat, 25 Jun 2022 09:04:33 -0700 (PDT)
Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2])
        by smtp.gmail.com with ESMTPSA id a7-20020adffb87000000b0021b89181863sm5542548wrr.41.2022.06.25.09.04.32
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 25 Jun 2022 09:04:32 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------Wk5CuLxpjpIf4RbkGjDnqe3o"
Message-ID: 
Date: Sat, 25 Jun 2022 17:01:44 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Content-Language: en-GB
To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org,
 freebsd-doc@freebsd.org
References: 
 <20220623030118.GA59423@eureka.lemis.com>
 <20220623060320.aad6a631.freebsd@edvax.de>
 
From: Graham Perrin 
Subject: Posting netiquette: HTML, attachments etc.
In-Reply-To: 
X-Rspamd-Queue-Id: 4LVf2B5Zj6z4jZh
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=C3MBtRWw;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::435 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 TO_DN_NONE(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.991];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FREEFALL_USER(0.00)[grahamperrin];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::435:from];
	 MLMMJ_DEST(0.00)[freebsd-questions,freebsd-current,freebsd-doc];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------Wk5CuLxpjpIf4RbkGjDnqe3o
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 23/06/2022 09:14, grarpamp wrote:
> …
>
> The pages ...
>
> https://docs.freebsd.org/en/books/handbook/eresources/#eresources-mail …

FreeBSD bug 264754 – FreeBSD Handbook: Appendix C: updates and 
corrections 

I'm glad that HTML is supported.

Also, I want support for things such as PNG.

/If we don't ask, we don't get/ :-)

--------------Wk5CuLxpjpIf4RbkGjDnqe3o
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 23/06/2022 09:14, grarpamp wrote:

    

    

      
…

The pages ...

https://docs.freebsd.org/en/books/handbook/eresources/#eresources-mail
…


    

    
FreeBSD bug 264754
        – FreeBSD Handbook: Appendix C: updates and corrections

    
I'm glad that HTML is supported. 

    

    
Also, I want support for things such as PNG. 

    
If we don't ask, we don't get :-) 

    

  
  


--------------Wk5CuLxpjpIf4RbkGjDnqe3o--

From nobody Sat Jun 25 22:46:54 2022
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 1A131864711
	for ; Sat, 25 Jun 2022 22:47:05 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LVpyc03d9z4ZhC;
	Sat, 25 Jun 2022 22:47:03 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 25PMksFc086345;
	Sun, 26 Jun 2022 07:46:55 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Sun, 26 Jun 2022 07:46:54 +0900
From: Tomoaki AOKI 
To: Hans Petter Selasky 
Cc: Ivan Quitschal ,
        "freebsd-current@freebsd.org"
 ,
        Kurt Jaeger 
Subject: Re: vt newcons mouse paste issue FIXED
Message-Id: <20220626074654.f06d70e582b82ff089c425f9@dec.sakura.ne.jp>
In-Reply-To: <9ad847b7-859f-9e58-f424-1e2ef6546439@selasky.org>
References: 
	
	<41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
	
	<20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
	
	
	
	
	<790bd76d-890f-cf09-a30d-c2e5fba91ec5@selasky.org>
	<20220624230215.82e02ac661cd7594624a1845@dec.sakura.ne.jp>
	<5bd74766-f2f0-3df2-0e8c-adabd110f913@selasky.org>
	<5196d98c-7b3a-55b4-3ef7-227b19b66721@selasky.org>
	<20220625015150.4f57017e7098ea591f57bd2a@dec.sakura.ne.jp>
	<9ad847b7-859f-9e58-f424-1e2ef6546439@selasky.org>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LVpyc03d9z4ZhC
X-Spamd-Bar: ++
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [2.62 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 TO_DN_SOME(0.00)[];
	 MV_CASE(0.50)[];
	 HAS_ORG_HEADER(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[123.1.85.147:received];
	 RCVD_TLS_LAST(0.00)[];
	 R_DKIM_NA(0.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_SPAM_SHORT(0.99)[0.995];
	 NEURAL_HAM_LONG(-0.78)[-0.780];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[sakura.ne.jp];
	 AUTH_NA(1.00)[];
	 NEURAL_SPAM_MEDIUM(1.00)[1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 R_SPF_NA(0.00)[no SPF record];
	 FREEMAIL_CC(0.00)[hotmail.com,freebsd.org];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, 25 Jun 2022 11:29:43 +0200
Hans Petter Selasky  wrote:

> On 6/24/22 18:51, Tomoaki AOKI wrote:
> > On Fri, 24 Jun 2022 17:29:26 +0200
> > Hans Petter Selasky  wrote:
> > 
> 
> Hi Tomoaki,
> 
> Please retest:
> https://reviews.freebsd.org/D35552
> 
> Pushing this after some local tests.
> 
> --HPS

Thanks! As I already commented on Phabricator, worked just as intended.
  *Trailing spaces only listed in switch() of tchar_is_word_separator()
   are deleted on non-last lines.
  *Space (tried U+3000 only, though) before U+2007, which is not listed
   and untouched, on non-last line is sanely kept.
  *Spaces at the end of last line are sanely kept.


Some additional info not wrote in Phablicator:
I've entered test texts using editors/leafpad and entered various space
characters with character_pallette of japanese/mozc-tools.
Then, switch to console and view the text with misc/lv and copy from
there, close, open /ust/bin/ee, paste the buffer and save it.
After all, switch back to Mate desktop and open the saved text with
editors/leafpad to see the result.

  *ee has some problem handling non-ascii chars. Maybe on character
   counting. So not fit to check the result.

Some, usually old, Japanese uses U+0020 and u+3000 to make tables and
want u+3000 as non-breakable.
But the needs are basically only on "within a line". Almost all of us
wouldn't care about u+3000 at the end of line.
Moreover, we Japanese are educated to insert single u+3000 between
u+3002 (IDEOGRAPHIC FULL STOP) and next character at the same line,
when in elementary school. (Many people forgets this, though.)
This rule should be enough to handle u+3000 as breakable for this
particular case.

Thanks again in advance! Now I should say "Go for it!".

-- 
Tomoaki AOKI    

From nobody Sun Jun 26 07:35:29 2022
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 D79268681EF;
	Sun, 26 Jun 2022 07:35:37 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LW2hT0QHCz4ZBy;
	Sun, 26 Jun 2022 07:35:37 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: by mail-ed1-x52a.google.com with SMTP id e40so8988269eda.2;
        Sun, 26 Jun 2022 00:35:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc;
        bh=ZQUp25dhvJ0yDHpusFk+QFLhfdH1mvqjceedloNaoyQ=;
        b=R8DGgR/M6JBMjmdltFAFWvhPKcC2RJ19o7f/pF0C1BxSiiGWE8+XtN7KznHPXzAu4S
         S6pmi2OD6GAEkbRbx/20HaiVFWcOBSdGpQ2gKjAuVxxoXFS3Nj8yFzxNFBL9yp8H2FRP
         imsDpGHCvmlFzfEECDRMHutYfaY2bWTE336QiRH/1j4DFl1EUhOkXEstnFPic9d00nWG
         PBghMgD0LvMv8L+KVT7FG5lhb9frv+B1hqd6OhLBNae32MLRY/TroWwrG0VU9ylvbZ77
         EY/PWhxRDGvS4WE4Gl8onSzXBlx/FbpJCQDH0XD9YcPs73hgxgE1Y9oMplw1eOX6R2qJ
         lE9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc;
        bh=ZQUp25dhvJ0yDHpusFk+QFLhfdH1mvqjceedloNaoyQ=;
        b=yIXpELTfT7C+5obd7QwC3ebn285h1mokrnWdJiKV4LsfJ15nN5Ty6g7zr+otVZIn3c
         ab9nE3c13O7clWq+8DqmvionqoP8YLeP115S/gYHgPL64tyswD1+g5TqBD1lVhCzMqfb
         Ru5t4yJichYwsz2gIWdC09iin4DQpzEUP1fu2vbgh1lkiYTAULMAYtdvpR3g91EbcBCl
         laZRXZcEo4POhZ+vbv3DMJvra3z1e4Zv4oXGXFB8q6lQc+vnsKlK5hZSD92BVHbJ0aeF
         C+e19kIcE5FxDtggawLnlUD3ROmHa9TK8jDbOISo61TNxB5LeWT3yfpgRvAlRkP7MuUR
         VtCw==
X-Gm-Message-State: AJIora+MlkCdFWpV3YtwVf8Vs2C+VWcgtubZFi/mjG6XS1uSZvWgKLAH
	bTM9zvDHFXx2AWE/mx/zLcHjslskG4GdDmPkQNYYNLvel1JhJbl8
X-Google-Smtp-Source: AGRyM1sslxIbZkIsYYJe/woUHZretFHFO7MtV5R+LoPCTh2Zr8bzJ4Si9/+xCYAciig6/oaApQ+C1SI6AeEZPBjKBYw=
X-Received: by 2002:aa7:dac2:0:b0:435:76a2:4ebe with SMTP id
 x2-20020aa7dac2000000b0043576a24ebemr9494833eds.196.1656228930179; Sun, 26
 Jun 2022 00:35:30 -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
Received: by 2002:ab4:a183:0:0:0:0:0 with HTTP; Sun, 26 Jun 2022 00:35:29
 -0700 (PDT)
In-Reply-To: 
References: 
 <20220623030118.GA59423@eureka.lemis.com> <20220623060320.aad6a631.freebsd@edvax.de>
  
From: grarpamp 
Date: Sun, 26 Jun 2022 03:35:29 -0400
Message-ID: 
Subject: Re: Posting netiquette: HTML, attachments etc.
To: freebsd-doc@freebsd.org
Cc: freebsd-questions@freebsd.org, freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4LW2hT0QHCz4ZBy
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="R8DGgR/M";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=grarpamp@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-doc,freebsd-questions,freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

> https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/eresources/_index.adoc
>
> FreeBSD Handbook: Appendix C: updates and corrections
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264754
>
> I'm glad that HTML is supported.

No, people should not be sending HTML emails to lists.
Consult history of email netiquettes to discover the many why's.

> Also, I want support for things such as PNG.

Attachments are not necessarily against such netiquettes,
but rightly tend to be administratively size limited.

> What is the possibility of getting the/a "netiquette" link in
> the FreeBSD Mailinglist footer that is already appended to all
> the messages?

There is no such footer appended to the lists, because they're bloat.
Their aims usually better done at first via signup, in quarterly, and
via the occaisional involuntary and accepted friendly cluebat.


> we are dealing with real people working with the email
> clients available to them in 2022

Same arguments was made in 1982 1992 2002 etc, and the netiquette
won validity for good reasons and is still taught trained and disciplined.
September and 2022 are no reason to abandon oneself
from those responsibilities rites and rituals of computing.


Incapable and misconfigured email list software and archives
and search are separate issues from the sending netiquette.


Yes all mail since inception of FreeBSD is supposed
to be integrated and available in raw form here...

rsync -nHaxi bit0.us-west.freebsd.org::FreeBSD-mailarchive/

...for all the good reasons mentioned previously on the lists.
Though it needs maintenance work, and also more published
on the list info webpages / handbook that were noted earlier.

From nobody Sun Jun 26 09:55:26 2022
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 992A187DDEF;
	Sun, 26 Jun 2022 09:55:35 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LW5nz0ldqz4rMW;
	Sun, 26 Jun 2022 09:55:35 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id 0d0ede10;
	Sun, 26 Jun 2022 09:55:27 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id caa4df6d (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Sun, 26 Jun 2022 09:55:27 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-E01B37ED-F1B1-43C0-BDCD-7999E94A0C67
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 (1.0)
Subject: Re: Posting netiquette: HTML, attachments etc.
From: Michael Gmelin 
In-Reply-To: 
Date: Sun, 26 Jun 2022 11:55:26 +0200
Cc: freebsd-doc@freebsd.org, freebsd-questions@freebsd.org,
 freebsd-current@freebsd.org
Message-Id: <753A27F9-9CEA-4592-A44F-91164917358B@freebsd.org>
References: 
To: grarpamp 
X-Mailer: iPhone Mail (19E258)
X-Rspamd-Queue-Id: 4LW5nz0ldqz4rMW
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Spamd-Result: default: False [-4.00 / 15.00];
	 REPLY(-4.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail-E01B37ED-F1B1-43C0-BDCD-7999E94A0C67
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On 26. Jun 2022, at 09:37, grarpamp  wrote:
>=20
> =EF=BB=BF
>>=20
>> https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en=
/books/handbook/eresources/_index.adoc
>>=20
>> FreeBSD Handbook: Appendix C: updates and corrections
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264754
>>=20
>> I'm glad that HTML is supported.
>=20
> No, people should not be sending HTML emails to lists.
> Consult history of email netiquettes to discover the many why's.
>=20
>> Also, I want support for things such as PNG.
>=20
> Attachments are not necessarily against such netiquettes,
> but rightly tend to be administratively size limited.
>=20
>> What is the possibility of getting the/a "netiquette" link in
>> the FreeBSD Mailinglist footer that is already appended to all
>> the messages?
>=20
> There is no such footer appended to the lists, because they're bloat.
> Their aims usually better done at first via signup, in quarterly, and
> via the occaisional involuntary and accepted friendly cluebat.
>=20
>=20
>> we are dealing with real people working with the email
>> clients available to them in 2022
>=20
> Same arguments was made in 1982 1992 2002 etc, and the netiquette
> won validity for good reasons and is still taught trained and disciplined.=


Trying to stop people from using UTF-8 is futile. Also, quoting various argu=
ments from different people without context is bad style - I gave very speci=
fic examples, including the fact that a lot of email is written on mobile de=
vices where people don=E2=80=99t have control over many aspects of how thing=
s are sent and I argued which parts of netiquette could/should still be foll=
owed given the realities of today and where we need to relax if we want to h=
ave communication happen on our mailing lists.

My answer here is an example of that - there is no reasonable way to follow a=
ny line length limits on a phone and it also automatically chooses the typog=
raphically correct UTF-8 characters, even though I would prefer to use ASCII=
 - but there is no way I=E2=80=99ll change every single "=E2=80=98" to "'" m=
anually or disable the features that make typing on such a device an accepta=
ble experience. Just won=E2=80=99t happen.

If your email client and/or your desktop can=E2=80=99t handle UTF-8, it=E2=80=
=99s time to fix your setup.

-m

p.s. Is it really necessary to have this discussion on multiple lists?


--Apple-Mail-E01B37ED-F1B1-43C0-BDCD-7999E94A0C67
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 26. Jun 2022, at 09=
:37, grarpamp <grarpamp@gmail.com> wrote:

=EF=BB=BF
=
https://github.com/freebsd/freebsd-doc/blob/main/documentation/content=
/en/books/handbook/eresources/_index.adoc

FreeBSD Handbook: Appendix C: updates and corrections
https://bugs.freebsd.org/bugzilla/show_bug=
.cgi?id=3D264754

I'm glad that HTML is su=
pported.

No, people should not=
 be sending HTML emails to lists.
Consult history of email n=
etiquettes to discover the many why's.

Also, I want support for things such as PNG.

Attachments are not necessarily against=
 such netiquettes,
but rightly tend to be administratively s=
ize limited.

What=
 is the possibility of getting the/a "netiquette" link in
the FreeBSD Mailinglist footer that is a=
lready appended to all
the messages?

There is no su=
ch footer appended to the lists, because they're bloat.
Thei=
r aims usually better done at first via signup, in quarterly, and
=
via the occaisional involuntary and accepted friendly cluebat.<=
br>

we are d=
ealing with real people working with the email
clients available to them in 2022

Same arguments was made in 1982 1992 2002 etc,=
 and the netiquette
won validity for good reasons and is sti=
ll taught trained and disciplined.

Tryi=
ng to stop people from using UTF-8 is futile. Also, quoting various argument=
s from different people without context is bad style - I gave very specific e=
xamples, including the fact that a lot of email is written on mobile devices=
 where people don=E2=80=99t have control over many aspects of how things are=
 sent and I argued which parts of netiquette could/should still be followed g=
iven the realities of today and where we need to relax if we want to have co=
mmunication happen on our mailing lists.

My answer here i=
s an example of that - there is no reasonable way to follow any line length l=
imits on a phone and it also automatically chooses the typographically corre=
ct UTF-8 characters, even though I would prefer to use ASCII - but there is n=
o way I=E2=80=99ll change every single "=E2=80=98" to "'" manually or disabl=
e the features that make typing on such a device an acceptable experience. J=
ust won=E2=80=99t happen.

If your email client and/or your=
 desktop can=E2=80=99t handle UTF-8, it=E2=80=99s time to fix your setup.

-m

p.s. Is it r=
eally necessary to have this discussion on multiple lists?

=

--Apple-Mail-E01B37ED-F1B1-43C0-BDCD-7999E94A0C67--

From nobody Sun Jun 26 14:41:19 2022
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 EE9B787E098;
	Sun, 26 Jun 2022 14:41:22 +0000 (UTC)
	(envelope-from bapt@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWD7k69p9z3Kt0;
	Sun, 26 Jun 2022 14:41:22 +0000 (UTC)
	(envelope-from bapt@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1656254482;
	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=hlKWeiZ+HgmKdYYjUsdqz5m4Ft9V99lwfCHt5F4K9L8=;
	b=ZjsEToiwemV9/R3u5S6WKVZf7ea6NFv1/k1ubUqIkvHOx/9/3bIOsyH06dEftgPcf8pxcK
	DA8Wk6+fssaXG/CdusEv2Qg6jes2KxBbg2GKKV9/Q9oy+vaLgUbQpeux0uxPavorMosRoH
	pUHzl81fwOaAWTe9jjfq1EsbnnWzQc5nb6jTJI8MPNMbJwDb+JsToA1TRM+JiOV+WqU6ME
	vMIqbSUGuijGqh++61XT8ogEbAbgRDtLj+coVdFw4bqqGMCQEkDR9BxVsQFUCXIAfoRWym
	jjdzaWVFnqYSoHKmyLQw8RsZDQuI4wubXuDK6RMv1h3ew49aRflCWeBLIzYECw==
Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: bapt)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 9BA026281;
	Sun, 26 Jun 2022 14:41:22 +0000 (UTC)
	(envelope-from bapt@FreeBSD.org)
Received: from [IPv6:::1] (unknown [IPv6:2a01:e0a:242:70a0:328f:f95d:fe65:4ee8])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by aniel.nours.eu (Postfix) with ESMTPSA id EB20E147E81;
	Sun, 26 Jun 2022 16:41:19 +0200 (CEST)
Date: Sun, 26 Jun 2022 16:41:19 +0200
From: Baptiste Daroussin 
To: Chris , grarpamp 
CC: freebsd-doc@freebsd.org, postmaster@freebsd.org,
 freebsd-questions@freebsd.org, freebsd-current@freebsd.org
Subject: =?US-ASCII?Q?Re=3A_Posting_Netiquette_=5Bref=3A_Threads_=22look_defi?= =?US-ASCII?Q?nitely_like=22_unreadable_mess=2E_Handbook_project=2E=5D?=
User-Agent: K-9 Mail for Android
In-Reply-To: <4de546f68061f774e53553fb542bed7a@bsdforge.com>
References:  <20220623030118.GA59423@eureka.lemis.com> <20220623060320.aad6a631.freebsd@edvax.de>  <4de546f68061f774e53553fb542bed7a@bsdforge.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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1656254482;
	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=hlKWeiZ+HgmKdYYjUsdqz5m4Ft9V99lwfCHt5F4K9L8=;
	b=hjg576YlSHoj3KEVJBaon3dq4x7ZUL0hNWa9Jf/GUxitzCveL6Xfaq6qwbBD1VYIP+Sl+i
	lRw7PVnW/QuBjn9YIvhulO6zSBDCAUO+kLReKS8dJFiu8zp9yEYR4s/aLrZ3oXcia58ziC
	Be/qbOriQXAs5LLWQb5oPqZPTFANoesdi4jEEQJDHwLahMNUSGqki3lT1c3w/W9BTk3duv
	jG/Mr6JvM9BjL7U1JXLyXexJ6Uy7t/paWXLwnbMYdt4Baf09dMsK6PgbVjK+IKxmcBkPLf
	AG+IGJvawGSHUHEggb1SkmR31FM17KOFinNmvFvCHMkVYfG4f1BoDFSbLIg59A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1656254482; a=rsa-sha256; cv=none;
	b=jOZtCc1wEjZvY6WGf1sZD+qML7wdEFLpRlaJInpInfeU7EFwWaxPP6LUbWPdZ/U14c0bm6
	8BBEO47z2cMUPFoXD9mSCsXpQ5g3pnNM1bHvrVh1AaSN4BsfzmAeR+kPTxpp7+CjHx9jXN
	nojsuYDAqvXZdu/LhTHsNkRiQCz0y6gV881Clform/vJVOqwgRplrGqwdVTNYo2XbO3yUi
	mlvonsOBsL8HUd7OuYgGEcT1zL5hrIz3sF65gQVl2on0G9bAh/yXKd1VjlKepYtPDkSH4O
	kgXTtY4DeTA8Ck58GonxenTzpTM1BzESWo7Y3gti1MAIliIZrT0IZsNaOzkjfQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N



Le 24 juin 2022 18:19:49 GMT+02:00, Chris  a =C3=
=A9crit=C2=A0:
>On 2022-06-23 01:14, grarpamp wrote:
>>>> the =C3=A2=E2=82=AC=C5=93> ;=C3=A2=E2=82=AC  and leave empty lines be=
tween your text and the original
>>=20
>>> Seems there is a charset mismatch=2E
>>> MUA displaying nonsense
>>> Oh the joy of UTF-8=2E=2E=2E ;-)
>>=20
>> https://unicode-table=2Ecom/en/sets/quotation-marks/
>>=20
>> The pages =2E=2E=2E
>>=20
>> https://docs=2Efreebsd=2Eorg/en/books/handbook/eresources/#eresources-m=
ail
>> https://docs=2Efreebsd=2Eorg/en/articles/freebsd-questions/
>> https://docs=2Efreebsd=2Eorg/en/articles/mailing-list-faq/
>>=20
>> =2E=2E=2E are intermixing standard ASCII double quotes with questionabl=
y
>> gratuitous choice of using left and right double quotes via UTF-8,
>> which then may get slaughtered by non UTF-8 enabled cut-paste,
>> systems, lists, gui's, desktops, apps, and MUAs along the way=2E
>>=20
>=2E=2E=2E
>> A proper page would need to add a number of the missing
>> email formatting netiquettes (such as no HTML), and actual
>> photo examples of former bad chaos and new good result, etc=2E=2E=2E
>> to be considered a good format, subject, and addressing
>> netiquette guide rule page=2E
>>=20
>> Consider if "FreeBSD Articles" is best hier for a page that
>> may becoming more often directly linked or included into
>> prospective list user's signup clickstream, quarterly admin,
>> friendly cluebat hints, etc=2E
>>=20
>What is the possibility of getting the/a "netiquette" link in
>the FreeBSD Mailinglist footer that is already appended to all
>the messages? This would only be a small addition, with a quick/
>easy reference to the subject at hand=2E
>
>Just my =2E2=C2=A2
>
>Chris

Resending with my address which is subscribed to the lists ;)

The possibility is none it will break dkim signature, we should not alter =
emails beside their headers=2E

Best regards,
Bapt

From nobody Sun Jun 26 18:18:49 2022
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 04C81878095;
	Sun, 26 Jun 2022 18:19:02 +0000 (UTC)
	(envelope-from walterp@gmail.com)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWJys1sm1z4VWh;
	Sun, 26 Jun 2022 18:19:01 +0000 (UTC)
	(envelope-from walterp@gmail.com)
Received: by mail-oi1-x22e.google.com with SMTP id r82so1518636oig.2;
        Sun, 26 Jun 2022 11:19:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=2+kBeSUEtM6IrENb3gzq+EuBlsxYaUatQEQ0vqaRL0U=;
        b=O92mn9nOClA10n1nOsqLIAyKfAyQ5MVj0pAKLO7e5/TzO5p+76sB56r+laqWLav8u9
         a9pTISxrdNL5CnaVOr5lsh7jsLCGa3GzQa6oJPEjipmD43RHSI5DGEOecZ9TcCzjokz+
         BFqnYqmShg2zDinLeMC0soCmT3bzvukvczKqY+TfOGNLrCQ3zJ5hRjec9U6eYBoxAI9s
         gXQ2JCo5nfOnwqbpmlf/FGxLe1W4AarNKNLsXiSzLLKV5fvaWMbqAOrg8flipoZjZs81
         n2qvnqnBqWVdFUNER8rWuv/Wojb6GatJljx3x0W253wjnsv8s2fmgPP6+xKMOUAl/a/S
         7e2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=2+kBeSUEtM6IrENb3gzq+EuBlsxYaUatQEQ0vqaRL0U=;
        b=kyUIQ/MlAAk7BvEeDaHgGdYpZp21zI/CTc9hnQqsk0NTFJssUxb1wP9pDMhuLqUzK0
         CQpem/104BCky/sRA3ox+EbBHty0jJ+u4Hr10RM+EiNGO3Lwc4t+Txux7r4vAdJrNsbx
         b2CTywIhMmdhTNlvMWwVe7X/qwDatV2LnKuauzw5bcg8WCIDzjumrp2LBhrzzo/GQM91
         ZwRVFvn+vcehB3wtzHQt22eGwzNch0isPbNNjNB35q3M+RjcqjMxzWN4E7zA5KFZeacJ
         q2cqeIi+VIBEDRLuYJJlgRwfH+peeklARPhQOVl2wDA1/DLlai5d+KOwx54XYcPbf1+r
         BPGw==
X-Gm-Message-State: AJIora+h2TgVtXnqcHXjdoyrPqXYw1PwCekDjkVZVGhXZdQFtUUtWd5D
	+WNJwvkhUkqPNxim9lPRg4+VzxFYFASbh/djvsE4KsXYrU4=
X-Google-Smtp-Source: AGRyM1uYbMLrVDVsOfr2KKDso7qSTP+2EJBdRBMXIQK+XMI3jbLqOTmtZji+b5M4Dz6yJvZ787LDyP+/7lsPDTXRWIE=
X-Received: by 2002:a05:6808:3089:b0:32e:f7fd:627d with SMTP id
 bl9-20020a056808308900b0032ef7fd627dmr5745098oib.181.1656267540275; Sun, 26
 Jun 2022 11:19:00 -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: 
 <753A27F9-9CEA-4592-A44F-91164917358B@freebsd.org>
In-Reply-To: <753A27F9-9CEA-4592-A44F-91164917358B@freebsd.org>
From: Walter Parker 
Date: Sun, 26 Jun 2022 11:18:49 -0700
Message-ID: 
Subject: Re: Posting netiquette: HTML, attachments etc.
To: Michael Gmelin 
Cc: freebsd-doc@freebsd.org, freebsd-questions@freebsd.org, 
	freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000064276005e25dd60f"
X-Rspamd-Queue-Id: 4LWJys1sm1z4VWh
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=O92mn9nO;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of walterp@gmail.com designates 2607:f8b0:4864:20::22e as permitted sender) smtp.mailfrom=walterp@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22e:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-doc,freebsd-questions,freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000064276005e25dd60f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

So, utf-8 is good, posting to multiple lists is bad (but ok when you do
it), what about the original post? He was asking about HTML. UTF-8 !=3D HTM=
L.
UTF is a character encoding format. It is supported by most email clients
and does not require HTML for support.


Walter

On Sun, Jun 26, 2022 at 2:56 AM Michael Gmelin  wrote:

>
>
> On 26. Jun 2022, at 09:37, grarpamp  wrote:
>
> =EF=BB=BF
>
>
> https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en=
/books/handbook/eresources/_index.adoc
>
>
> FreeBSD Handbook: Appendix C: updates and corrections
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264754
>
>
> I'm glad that HTML is supported.
>
>
> No, people should not be sending HTML emails to lists.
> Consult history of email netiquettes to discover the many why's.
>
> Also, I want support for things such as PNG.
>
>
> Attachments are not necessarily against such netiquettes,
> but rightly tend to be administratively size limited.
>
> What is the possibility of getting the/a "netiquette" link in
>
> the FreeBSD Mailinglist footer that is already appended to all
>
> the messages?
>
>
> There is no such footer appended to the lists, because they're bloat.
> Their aims usually better done at first via signup, in quarterly, and
> via the occaisional involuntary and accepted friendly cluebat.
>
>
> we are dealing with real people working with the email
>
> clients available to them in 2022
>
>
> Same arguments was made in 1982 1992 2002 etc, and the netiquette
> won validity for good reasons and is still taught trained and disciplined=
.
>
>
> Trying to stop people from using UTF-8 is futile. Also, quoting various
> arguments from different people without context is bad style - I gave ver=
y
> specific examples, including the fact that a lot of email is written on
> mobile devices where people don=E2=80=99t have control over many aspects =
of how
> things are sent and I argued which parts of netiquette could/should still
> be followed given the realities of today and where we need to relax if we
> want to have communication happen on our mailing lists.
>
> My answer here is an example of that - there is no reasonable way to
> follow any line length limits on a phone and it also automatically choose=
s
> the typographically correct UTF-8 characters, even though I would prefer =
to
> use ASCII - but there is no way I=E2=80=99ll change every single "=E2=80=
=98" to "'"
> manually or disable the features that make typing on such a device an
> acceptable experience. Just won=E2=80=99t happen.
>
> If your email client and/or your desktop can=E2=80=99t handle UTF-8, it=
=E2=80=99s time to
> fix your setup.
>
> -m
>
> p.s. Is it really necessary to have this discussion on multiple lists?
>
>

--=20
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandei=
s

--00000000000064276005e25dd60f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


So, utf-8 is good, posting to multiple lists is bad (=
but ok when you do it), what about the original post? He was asking about H=
TML. UTF-8 !=3D HTML. UTF is a character encoding format. It is supported b=
y most email clients and does not require HTML for support.

<=
/div>

Walter

On Sun, Jun 26, 2022 at 2:56 AM Michael =
Gmelin <grembo@freebsd.org>=
 wrote:


On 26. Jun 2022, at 09:37, grarpamp <grarpamp@gmail.com=
> wrote:

=EF=BB=BF
https://github.com/freebsd/freebsd-d=
oc/blob/main/documentation/content/en/books/handbook/eresources/_index.adoc=


FreeBSD Handbook: Appendix C: upda=
tes and corrections
=
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264754

I'm glad that HTML is supported.<=
/span>

No, people should not be send=
ing HTML emails to lists.
Consult history of email netiquet=
tes to discover the many why's.

Also, I want support for things such as PNG.
=


Attachments are not necessarily against=
 such netiquettes,
but rightly tend to be administratively =
size limited.

Wh=
at is the possibility of getting the/a "netiquette" link in
the FreeBSD Mailinglist f=
ooter that is already appended to all
the messages?

There is no such footer appended to the lists, because they're bloat=
.
Their aims usually better done at first via signup, in qu=
arterly, and
via the occaisional involuntary and accepted f=
riendly cluebat.


we are dealing with real people working with the email
clients available to t=
hem in 2022

Same arguments wa=
s made in 1982 1992 2002 etc, and the netiquette
won validi=
ty for good reasons and is still taught trained and disciplined.
=



-- 
The greatest dangers to liberty lurk in insidious encroachment by=
 men=C2=A0of zeal, well-meaning but without understanding. =C2=A0 -- Justic=
e Louis D.=C2=A0Brandeis


--00000000000064276005e25dd60f--

From nobody Sun Jun 26 18:32:41 2022
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 4A18987B78B
	for ; Sun, 26 Jun 2022 18:33:00 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWKGz2m3vz4ZJp
	for ; Sun, 26 Jun 2022 18:32:59 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe2f.google.com with SMTP id z66so7064791vsb.3
        for ; Sun, 26 Jun 2022 11:32:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=OGbMNiD6R/GvcUCYbbVXTpDtj7qOyn2eoSzoh0B8CmE=;
        b=KU2sl1C2wY4Yzpalw1H4Hcc1oIV0o+2GQJnjzNHTt46VpY2Ydq1sVc9W2hlN7Z8fRW
         pzAP2BGs/qcHi5GblipUU35L1wKC13MyVnZp1Q/O17gaSG+Y8O9dKQHEe/1QN/CaUdaY
         cVwGi+R48FgxJDk5piQsqqTefPZ8CKHpYuxp9ECNtArpiqrjV0wAIC8kwK5Yova1liY7
         u1bKaPHW4UnjH8qbAKPDMYupr3EC1IFyCylVmqJL1RC/lnICOcPq833pZ1+R+K4mrAV0
         Z4JAxubGhReMji7YbUGUOv6q4Ffu8TyncZU5DZWczEYk18fqSKzXqsyuMde+M0GxFR4N
         LU6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=OGbMNiD6R/GvcUCYbbVXTpDtj7qOyn2eoSzoh0B8CmE=;
        b=w2DaKuLcVEWze4TAwDHN2yfIEoko3pJdNUZ9wtm2CQIYpGT7Lv6fTIdru0fnlKQbf1
         zGJf+d9x1h269GrGicFuEAyetmdUp9xvH03Vlc4HUNv7lx3pho/i4NBaWkAr/BFCuZ1m
         uDKtqPLSQIMeXuL8/CXkFJ8mOa8Tjl81BjfVVIE/T1AHVnNFIhNEweXhcsjCPHJFhhOQ
         ZWksoI00l6iScwtPiOhbSBMxTjjjd+22XGty6TzxdJwj4KzKEgRuIuf9RMV+A5cIUkwD
         yAdayjUA7FgNdF6QqL85YMDDc3zLEcMUX1TAD3B4x7/8T+bzsmF5buFvvYZaFfGc2yju
         QcHQ==
X-Gm-Message-State: AJIora+KgcgPZKN39Mr+qRRdBcDsOLNPb4No+Nbq0JS1+8TQ/+1hSEhD
	UV8cC1NNOC/FHkPW4BGhxUL172hteXjQE9mZuJrXsQ==
X-Google-Smtp-Source: AGRyM1vjyBakEQesb5lK2BcncAmFybBiTKUNdVJajGIRuHWcZF6mVQqPYgA993VkANDfs/7OotJY55bmhm3K4s2ulQc=
X-Received: by 2002:a67:fbd3:0:b0:354:2f5b:6477 with SMTP id
 o19-20020a67fbd3000000b003542f5b6477mr3285536vsr.76.1656268372933; Sun, 26
 Jun 2022 11:32:52 -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: 
 <753A27F9-9CEA-4592-A44F-91164917358B@freebsd.org> 
In-Reply-To: 
From: Warner Losh 
Date: Sun, 26 Jun 2022 12:32:41 -0600
Message-ID: 
Subject: Re: Posting netiquette: HTML, attachments etc.
To: Walter Parker 
Cc: Michael Gmelin , freebsd-doc@freebsd.org, 
	FreeBSD questions , 
	FreeBSD Current 
Content-Type: multipart/alternative; boundary="0000000000000599cd05e25e084f"
X-Rspamd-Queue-Id: 4LWKGz2m3vz4ZJp
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=KU2sl1C2;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2f) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 RCPT_COUNT_FIVE(0.00)[5];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2f:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000000599cd05e25e084f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 26, 2022, 12:20 PM Walter Parker  wrote:

> So, utf-8 is good, posting to multiple lists is bad (but ok when you do
> it), what about the original post? He was asking about HTML. UTF-8 !=3D H=
TML.
> UTF is a character encoding format. It is supported by most email clients
> and does not require HTML for support.
>

Html is fine as well. Most modern mail platforms generate it for you,
whether you want them too or not. Most of the advice in appendix c is dated
and doesn't really match what people do on the lists. Phones and web based
Gmail are to large a presence to ignore or have policies against. I stopped
listening to complaints about how Gmail or my phone formatted posts 5 years
ago... and I'm definitely an old school straggler...

Warner


> Walter
>
> On Sun, Jun 26, 2022 at 2:56 AM Michael Gmelin  wrote=
:
>
>>
>>
>> On 26. Jun 2022, at 09:37, grarpamp  wrote:
>>
>> =EF=BB=BF
>>
>>
>> https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/e=
n/books/handbook/eresources/_index.adoc
>>
>>
>> FreeBSD Handbook: Appendix C: updates and corrections
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264754
>>
>>
>> I'm glad that HTML is supported.
>>
>>
>> No, people should not be sending HTML emails to lists.
>> Consult history of email netiquettes to discover the many why's.
>>
>> Also, I want support for things such as PNG.
>>
>>
>> Attachments are not necessarily against such netiquettes,
>> but rightly tend to be administratively size limited.
>>
>> What is the possibility of getting the/a "netiquette" link in
>>
>> the FreeBSD Mailinglist footer that is already appended to all
>>
>> the messages?
>>
>>
>> There is no such footer appended to the lists, because they're bloat.
>> Their aims usually better done at first via signup, in quarterly, and
>> via the occaisional involuntary and accepted friendly cluebat.
>>
>>
>> we are dealing with real people working with the email
>>
>> clients available to them in 2022
>>
>>
>> Same arguments was made in 1982 1992 2002 etc, and the netiquette
>> won validity for good reasons and is still taught trained and discipline=
d.
>>
>>
>> Trying to stop people from using UTF-8 is futile. Also, quoting various
>> arguments from different people without context is bad style - I gave ve=
ry
>> specific examples, including the fact that a lot of email is written on
>> mobile devices where people don=E2=80=99t have control over many aspects=
 of how
>> things are sent and I argued which parts of netiquette could/should stil=
l
>> be followed given the realities of today and where we need to relax if w=
e
>> want to have communication happen on our mailing lists.
>>
>> My answer here is an example of that - there is no reasonable way to
>> follow any line length limits on a phone and it also automatically choos=
es
>> the typographically correct UTF-8 characters, even though I would prefer=
 to
>> use ASCII - but there is no way I=E2=80=99ll change every single "=E2=80=
=98" to "'"
>> manually or disable the features that make typing on such a device an
>> acceptable experience. Just won=E2=80=99t happen.
>>
>> If your email client and/or your desktop can=E2=80=99t handle UTF-8, it=
=E2=80=99s time to
>> fix your setup.
>>
>> -m
>>
>> p.s. Is it really necessary to have this discussion on multiple lists?
>>
>>
>
> --
> The greatest dangers to liberty lurk in insidious encroachment by men of
> zeal, well-meaning but without understanding.   -- Justice Louis D. Brand=
eis
>

--0000000000000599cd05e25e084f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sun, Jun 26, 2022, 12:20 PM Walter Parker <walterp@gmail.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
So, utf-8 is good, post=
ing to multiple lists is bad (but ok when you do it), what about the origin=
al post? He was asking about HTML. UTF-8 !=3D HTML. UTF is a character enco=
ding format. It is supported by most email clients and does not require HTM=
L for support.

Html is fine as well. Most modern mail platforms gene=
rate it for you, whether you want them too or not. Most of the advice in ap=
pendix c is dated and doesn't really match what people do on the lists.=
 Phones and web based Gmail are to large a presence to ignore or have polic=
ies against. I stopped listening to complaints about how Gmail or my phone =
formatted posts 5 years ago... and I'm definitely an old school straggl=
er...

Warner=C2=A0
=



Walter

On Sun, Jun 26, 2022 at 2:56 AM Michael Gmelin <grembo@freebsd.org&=
gt; wrote:


On 26. Jun 2022, at 09:37, grarpamp <=
=
grarpamp@gmail.com> wrote:

FreeBSD Handbook: Appendix C: updates and corrections
h=
ttps://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264754

I'm glad that HTML is supported.

No, people should not be sending HTML emails=
 to lists.
Consult history of email netiquettes to discover=
 the many why's.

<=
span>Also, I want support for things such as PNG.

Attachments are not necessarily against such netiquett=
es,
but rightly tend to be administratively size limited.

What is the possi=
bility of getting the/a "netiquette" link in
the FreeBSD Mailinglist footer that is a=
lready appended to all
the messages?

There is no =
such footer appended to the lists, because they're bloat.
Their aims usually better done at first via signup, in quarterly, and
via the occaisional involuntary and accepted friendly cluebat=
.


we are dealing with real people working with the email
clients available to them in 2022

Same arguments was made in 1982 =
1992 2002 etc, and the netiquette
won validity for good rea=
sons and is still taught trained and disciplined.

Trying to stop peo=
ple from using UTF-8 is futile. Also, quoting various arguments from differ=
ent people without context is bad style - I gave very specific examples, in=
cluding the fact that a lot of email is written on mobile devices where peo=
ple don=E2=80=99t have control over many aspects of how things are sent and=
 I argued which parts of netiquette could/should still be followed given th=
e realities of today and where we need to relax if we want to have communic=
ation happen on our mailing lists.

My answer here is an example of that - there is no=
 reasonable way to follow any line length limits on a phone and it also aut=
omatically chooses the typographically correct UTF-8 characters, even thoug=
h I would prefer to use ASCII - but there is no way I=E2=80=99ll change eve=
ry single "=E2=80=98" to "'" manually or disable th=
e features that make typing on such a device an acceptable experience. Just=
 won=E2=80=99t happen.
If your email client and/=
or your desktop can=E2=80=99t handle UTF-8, it=E2=80=99s time to fix your s=
etup.

-m

p.=
s. Is it really necessary to have this discussion on multiple lists?
<=
div>


-- 
The greatest dangers to liberty =
lurk in insidious encroachment by men=C2=A0of zeal, well-meaning but withou=
t understanding. =C2=A0 -- Justice Louis D.=C2=A0Brandeis




--0000000000000599cd05e25e084f--

From nobody Sun Jun 26 18:53:14 2022
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 C417887FBAF;
	Sun, 26 Jun 2022 18:53:18 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWKkP49xzz4fWf;
	Sun, 26 Jun 2022 18:53:17 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id 825c635a;
	Sun, 26 Jun 2022 18:53:15 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 00c76c20 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Sun, 26 Jun 2022 18:53:15 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-1847D58B-9A02-4D3C-A5B8-EEED72944327
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 (1.0)
Subject: Re: Posting netiquette: HTML, attachments etc.
From: Michael Gmelin 
In-Reply-To: 
Date: Sun, 26 Jun 2022 20:53:14 +0200
Cc: freebsd-doc@freebsd.org, freebsd-questions@freebsd.org,
 freebsd-current@freebsd.org
Message-Id: <5BCE171C-8D95-47E9-AD8E-8F2B75F5E8B5@freebsd.org>
References: 
To: Walter Parker 
X-Mailer: iPhone Mail (19E258)
X-Rspamd-Queue-Id: 4LWKkP49xzz4fWf
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-1.61 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[grembo];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 MV_CASE(0.50)[];
	 NEURAL_HAM_LONG(-0.97)[-0.971];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 NEURAL_HAM_MEDIUM(-0.54)[-0.539];
	 TO_DN_SOME(0.00)[];
	 R_SPF_SOFTFAIL(0.00)[~all];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-0.50)[-0.500];
	 MLMMJ_DEST(0.00)[freebsd-current,freebsd-doc,freebsd-questions];
	 FREEMAIL_TO(0.00)[gmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	 RCVD_TLS_ALL(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail-1847D58B-9A02-4D3C-A5B8-EEED72944327
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On 26. Jun 2022, at 20:19, Walter Parker  wrote:
>=20
> =EF=BB=BF
> So, utf-8 is good, posting to multiple lists is bad (but ok when you do it=
),

I didn=E2=80=99t insinuate that it=E2=80=99s good for me to post to three li=
sts at a time either, but how would you decide which one to leave out when r=
esponding to a post you received on multiple lists? My original response red=
uced the number of lists involved, but I was quoted on all three lists again=
, so I also responded on all of them.

> what about the original post? He was asking about HTML. UTF-8 !=3D HTML. U=
TF is a character encoding format. It is supported by most email clients and=
 does not require HTML for support.
>=20

At some point in this email exchange he was suggesting to remove any kind of=
 special characters from email and documentation and my original response (h=
e quoted) was partially about this.

If it=E2=80=99s just about HTML: I would love to eliminate HTML email, but m=
ost email clients create it without the user having a chance to intervene. A=
n example is iOS Mail, which creates html as soon as you copy and paste almo=
st anything into it. AFAIK it still manages to create a useful plain text al=
ternative (unlike BBOS 10, if anyone remembers), which makes it better than o=
ther email clients - so filtering away html in this case would be fine. But t=
here is no option that says =E2=80=9Csend plaintext email=E2=80=9D.

I also agree that the original exchange that sparked this debate was quite t=
errible in terms of email formatting (it looked like outlook, no quoting, to=
p posting like exchanging written letters, using various font types and size=
s). So if we could eliminate these kind of emails, I would be happy.

Cheers
Michael=20

p.s. I=E2=80=99m pretty sure top posting is also against netiquette - unless=
 *you* do it of course ;)

>=20
> Walter
>=20
>> On Sun, Jun 26, 2022 at 2:56 AM Michael Gmelin  wrote=
:
>>=20
>>=20
>>>> On 26. Jun 2022, at 09:37, grarpamp  wrote:
>>>>=20
>>> =EF=BB=BF
>>>>=20
>>>> https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/=
en/books/handbook/eresources/_index.adoc
>>>>=20
>>>> FreeBSD Handbook: Appendix C: updates and corrections
>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264754
>>>>=20
>>>> I'm glad that HTML is supported.
>>>=20
>>> No, people should not be sending HTML emails to lists.
>>> Consult history of email netiquettes to discover the many why's.
>>>=20
>>>> Also, I want support for things such as PNG.
>>>=20
>>> Attachments are not necessarily against such netiquettes,
>>> but rightly tend to be administratively size limited.
>>>=20
>>>> What is the possibility of getting the/a "netiquette" link in
>>>> the FreeBSD Mailinglist footer that is already appended to all
>>>> the messages?
>>>=20
>>> There is no such footer appended to the lists, because they're bloat.
>>> Their aims usually better done at first via signup, in quarterly, and
>>> via the occaisional involuntary and accepted friendly cluebat.
>>>=20
>>>=20
>>>> we are dealing with real people working with the email
>>>> clients available to them in 2022
>>>=20
>>> Same arguments was made in 1982 1992 2002 etc, and the netiquette
>>> won validity for good reasons and is still taught trained and discipline=
d.
>>=20
>> Trying to stop people from using UTF-8 is futile. Also, quoting various a=
rguments from different people without context is bad style - I gave very sp=
ecific examples, including the fact that a lot of email is written on mobile=
 devices where people don=E2=80=99t have control over many aspects of how th=
ings are sent and I argued which parts of netiquette could/should still be f=
ollowed given the realities of today and where we need to relax if we want t=
o have communication happen on our mailing lists.
>>=20
>> My answer here is an example of that - there is no reasonable way to foll=
ow any line length limits on a phone and it also automatically chooses the t=
ypographically correct UTF-8 characters, even though I would prefer to use A=
SCII - but there is no way I=E2=80=99ll change every single "=E2=80=98" to "=
'" manually or disable the features that make typing on such a device an acc=
eptable experience. Just won=E2=80=99t happen.
>>=20
>> If your email client and/or your desktop can=E2=80=99t handle UTF-8, it=E2=
=80=99s time to fix your setup.
>>=20
>> -m
>>=20
>> p.s. Is it really necessary to have this discussion on multiple lists?
>>=20
>=20
>=20
> --=20
> The greatest dangers to liberty lurk in insidious encroachment by men of z=
eal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

--Apple-Mail-1847D58B-9A02-4D3C-A5B8-EEED72944327
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 26. Jun 2022, at 20=
:19, Walter Parker <walterp@gmail.com> wrote:

=EF=BB=BF
=
So, utf-8 is good, posting to multiple lists is bad (but ok when you do it),=


I didn=E2=80=99t insinuat=
e that it=E2=80=99s good for me to post to three lists at a time either, but=
 how would you decide which one to leave out when responding to a post you r=
eceived on multiple lists? My original response reduced the number of lists i=
nvolved, but I was quoted on all three lists again, so I also responded on a=
ll of them.

what about the original post? He was asking about HTML. UTF-8 !=3D=
 HTML. UTF is a character encoding format. It is supported by most email cli=
ents and does not require HTML for support.

=


At some point in this email exchange he was=
 suggesting to remove any kind of special characters from email and document=
ation and my original response (he quoted) was partially about this.

If it=E2=80=99s just about HTML: I would love to eliminate=
 HTML email, but most email clients create it without the user having a chan=
ce to intervene. An example is iOS Mail, which creates html as soon as you c=
opy and paste almost anything into it. AFAIK it still manages to create a us=
eful plain text alternative (unlike BBOS 10, if anyone remembers), which mak=
es it better than other email clients - so filtering away html in this case w=
ould be fine. But there is no option that says =E2=80=9Csend plaintext email=
=E2=80=9D.

I also agree that the original exchange t=
hat sparked this debate was quite terrible in terms of email formatting (it l=
ooked like outlook, no quoting, top posting like exchanging written letters,=
 using various font types and sizes). So if we could eliminate these kind of=
 emails, I would be happy.

Cheers
Michael=
 

p.s. I=E2=80=99m pretty sure top posting is also a=
gainst netiquette - unless *you* do it of course ;)


Walter

On S=
un, Jun 26, 2022 at 2:56 AM Michael Gmelin <grembo@freebsd.org> wrote:


On 26. Jun 20=
22, at 09:37, grarpamp <grarpamp@gmail.com> wrote:

=EF=BB=BF
<=
a href=3D"https://github.com/freebsd/freebsd-doc/blob/main/documentation/con=
tent/en/books/handbook/eresources/_index.adoc" target=3D"_blank">https://git=
hub.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handboo=
k/eresources/_index.adoc

FreeBSD Hand=
book: Appendix C: updates and corrections
https://bugs.freebsd.org/bugzilla/show_bug=
.cgi?id=3D264754
=

I'm glad that HTML i=
s supported.

No, people should=
 not be sending HTML emails to lists.
Consult history of ema=
il netiquettes to discover the many why's.

Also, I want support for things such as PNG.

Attachments are not necessarily aga=
inst such netiquettes,
but rightly tend to be administrative=
ly size limited.

=
What is the possibility of getting the/a "netiquette" link in
the FreeBSD Mailinglist footer that=
 is already appended to all
the messages?

There is n=
o such footer appended to the lists, because they're bloat.
=
Their aims usually better done at first via signup, in quarterly, and=

via the occaisional involuntary and accepted friendly cluebat.


we a=
re dealing with real people working with the email
clients available to them in 2022

Same arguments was made in 1982 1992 2002 e=
tc, and the netiquette
won validity for good reasons and is s=
till taught trained and disciplined.

<=
/div>
Trying to stop people from using U=
TF-8 is futile. Also, quoting various arguments from different people withou=
t context is bad style - I gave very specific examples, including the fact t=
hat a lot of email is written on mobile devices where people don=E2=80=99t h=
ave control over many aspects of how things are sent and I argued which part=
s of netiquette could/should still be followed given the realities of today a=
nd where we need to relax if we want to have communication happen on our mai=
ling lists.

My answer here is an example of that - there is no reasonable way to follow=
 any line length limits on a phone and it also automatically chooses the typ=
ographically correct UTF-8 characters, even though I would prefer to use ASC=
II - but there is no way I=E2=80=99ll change every single "=E2=80=98" to "'"=
 manually or disable the features that make typing on such a device an accep=
table experience. Just won=E2=80=99t happen.

If yo=
ur email client and/or your desktop can=E2=80=99t handle UTF-8, it=E2=80=99s=
 time to fix your setup.

-m

p.s. Is it really necessary to have this discussion on multi=
ple lists?


-- 
The greatest dangers to liberty lurk in insidious encroachment by me=
n of zeal, well-meaning but without understanding.   -- Justice Lo=
uis D. Brandeis


=

--Apple-Mail-1847D58B-9A02-4D3C-A5B8-EEED72944327--

From nobody Sun Jun 26 18:59:04 2022
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 9BBF9862240;
	Sun, 26 Jun 2022 18:59:06 +0000 (UTC)
	(envelope-from bapt@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWKs63snXz4jB0;
	Sun, 26 Jun 2022 18:59:06 +0000 (UTC)
	(envelope-from bapt@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1656269946;
	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=nZ2+yj7amM6DHnr48U2h+Y0OGyg+fP1P9Jq4odkty+Q=;
	b=AtkquNXoImPoiBRyj3NU6RhRZYoaWn0yMDkTrhOHiKIRS6zxJohHsLqOE6WWRs99qFzCiu
	jJuQaFLwVZnN6S+tb0msw1po+H5qNVhpQ76OCUUjBAawNTajx/P6nosAsQNLQR+4GFnKBb
	GX3+0R19E1BqvXBEoe6Ra4FwUJQP697FotaZxGd0InC8YPp2eUatlZ8ylxu4AbmSUSlnEF
	8DAxrsgMLeddFOefsfEMiCE3kUWq/ZfdHq7WPYva1VXtHDkLdiNDKHx85PCTYv5qKApPU9
	GGhHUh6/sUbJjPOhaKk3zLHVyhivmFwBrmspqFmyo1OHTREoPHXk5Sy9nP0Lag==
Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: bapt)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4EB3485C9;
	Sun, 26 Jun 2022 18:59:06 +0000 (UTC)
	(envelope-from bapt@FreeBSD.org)
Received: by aniel.nours.eu (Postfix, from userid 1001)
	id B0ED41605A9; Sun, 26 Jun 2022 20:59:04 +0200 (CEST)
Date: Sun, 26 Jun 2022 20:59:04 +0200
From: Baptiste Daroussin 
To: Warner Losh 
Cc: Walter Parker , Michael Gmelin ,
	freebsd-doc@freebsd.org,
	FreeBSD questions ,
	FreeBSD Current 
Subject: Re: Posting netiquette: HTML, attachments etc.
Message-ID: <20220626185904.mqetrczfcubslxzp@aniel.nours.eu>
References: 
 <753A27F9-9CEA-4592-A44F-91164917358B@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: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1656269946;
	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=nZ2+yj7amM6DHnr48U2h+Y0OGyg+fP1P9Jq4odkty+Q=;
	b=MN/DXONP6r2BMVEx0nQCWY7wxb98zV/GVHU7NfeGU/Dgvm8nZRZwCU/aZ8a/28sY2vYnOa
	QRfbu82ofJPTS1l2HT2IuNXeo9oda1eGPVxU1jS7kNAyFTWIddorPW8BQ9L/zA9iNkhXs1
	+yn+u4/zV3pkidaUn2htTBzHnRBppv95mIWAswaa/UNdLynIjlsQbKqnmsdjBExKSOdndn
	TF31JMjM8OsTrsmpLQItQ7cofojOlpDXiUaSv/EOKBgSnrOG8lbNodWXsb90irfIx1kSMq
	9LsELEn+zbul9QNc/C43eMxKtlqTvEfZ3MZwfS0QZYpMJVKt3gu/svuqkqM+JQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1656269946; a=rsa-sha256; cv=none;
	b=qyEWHi8+ccgzdDuG7GD/2yb8/i6MgMH2DIuGcvn5h7CYaJnguHH1dkcidx//XCIyWEMzFa
	9Ajrv/AWxBtUpB9YS9GzmdrwRTVRd1DElDnDlAwn2FPmwYFMmOIRwTKzKSjDIHMgUn3227
	VAGYGdTvUcJ98aW18nXCU0mZmPjS65r1yPaa4YVJNQiG01/Uh/XiRyv2nZZxlZABY+1ugZ
	l09XvOXWEsRmAYpe53GBoZE1ZwC0H5KgdS1jMXGiZ477LMbe4h7rMQvsYIgjjqTODDwhtV
	pTDgiDRa5bIuuO45yBJlVW+zLtBL+e94zEd79sXu5ISjwzsGWSeI0oFnUQksHg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Jun 26, 2022 at 12:32:41PM -0600, Warner Losh wrote:
> On Sun, Jun 26, 2022, 12:20 PM Walter Parker  wrote:
> 
> > So, utf-8 is good, posting to multiple lists is bad (but ok when you do
> > it), what about the original post? He was asking about HTML. UTF-8 != HTML.
> > UTF is a character encoding format. It is supported by most email clients
> > and does not require HTML for support.
> >
> 
> Html is fine as well. Most modern mail platforms generate it for you,
> whether you want them too or not. Most of the advice in appendix c is dated
> and doesn't really match what people do on the lists. Phones and web based
> Gmail are to large a presence to ignore or have policies against. I stopped
> listening to complaints about how Gmail or my phone formatted posts 5 years
> ago... and I'm definitely an old school straggler...
> 
> Warner
> 

Note that the mailing list engine will reject html only email, html is fine as
long at it is created with text/plain alternative.

Note that only the text/plain alternative will be used to construct the archive,
and I will not ever work on trying to render properly an html only formatted
thing via the archiver, it will require too many escaping and madness to be done
safely, I will simply drop the ball to someone else here ;)

bapt

From nobody Mon Jun 27 13:27:54 2022
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 15B35877E8E
	for ; Mon, 27 Jun 2022 13:28:05 +0000 (UTC)
	(envelope-from SRS0=7KDL=XC=quip.cz=000.fbsd@elsa.codelab.cz)
Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4])
	(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 4LWpSh0tnHz3mlM;
	Mon, 27 Jun 2022 13:28:04 +0000 (UTC)
	(envelope-from SRS0=7KDL=XC=quip.cz=000.fbsd@elsa.codelab.cz)
Received: from elsa.codelab.cz (localhost [127.0.0.1])
	by elsa.codelab.cz (Postfix) with ESMTP id CF3742842E;
	Mon, 27 Jun 2022 15:27:55 +0200 (CEST)
Received: from [192.168.145.49] (ip-89-177-28-143.net.upcbroadband.cz [89.177.28.143])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by elsa.codelab.cz (Postfix) with ESMTPSA id B4DBF28411;
	Mon, 27 Jun 2022 15:27:54 +0200 (CEST)
Message-ID: <3bbacbac-9238-f29d-653c-86d13085afe0@quip.cz>
Date: Mon, 27 Jun 2022 15:27:54 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14
Content-Language: cs
To: Rick Macklem , David Chisnall
 ,
 "freebsd-current@freebsd.org" 
References: 
 
 <7db04ed9-39eb-7163-ce92-9a52c5f7d302@quip.cz>
 
 <54704b99-7b89-76a4-0368-79bee391926d@quip.cz>
 
 
 
 
 
 <489849ca-a404-fb54-81d1-d62ea18c5832@FreeBSD.org>
 
 <254a0b5e-72d9-f93e-0c49-82b50a35db41@quip.cz>
 
From: Miroslav Lachman <000.fbsd@quip.cz>
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LWpSh0tnHz3mlM
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of "SRS0=7KDL=XC=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=7KDL=XC=quip.cz=000.fbsd@elsa.codelab.cz"
X-Spamd-Result: default: False [0.02 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 DMARC_NA(0.00)[quip.cz];
	 AUTH_NA(1.00)[];
	 NEURAL_SPAM_SHORT(0.81)[0.814];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=7KDL=XC=quip.cz=000.fbsd@elsa.codelab.cz];
	 R_SPF_NA(0.00)[no SPF record];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ];
	 FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=7KDL=XC=quip.cz=000.fbsd@elsa.codelab.cz];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 16/06/2022 15:56, Rick Macklem wrote:
> Miroslav Lachman <000.fbsd@quip.cz> wrote:
>> On 24/01/2022 16:13, Rick Macklem wrote:
>>
> [...]
>>
>>> So, I think Mark and Yuri are correct and looking at up to date
>>> Illumos sources is the next step.
>>> (As I mentioned, porting the Apple sources is beyond what I am
>>>    willing to attempt.)
>>>
>>> rick
>>
>> Hello Rick,
>> I would like to ask you I there is some progress with porting newer
>> SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a
>> possibility where to start porting?
> Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date
> and I agree that it should be easier than the Apple stuff to port into
> FreeBSD.  I don't think it is "straightforward" as someone involved
> with Illumos said, due to the big differences in VFS/locking, but...
> 
> Having said the above, I have not done much yet. I've been cleaning up
> NFS stuff, although I am nearly done with that now.
> I do plan on starting to work on it soon, but have no idea if/when I
> will have something that might be useful for others.

I'm glad to hear that.

>> We have more and more problems with current state of mount_smbfs. I
>> would be really glad if "somebody" can do the heroic work of
>> implementing SMBv2 in FreeBSD.
>> Maybe it's time to start some fundraising for sponsoring this work?
> Well, funding isn't an issue for me (I'm just a retired guy who does this
> stuff as a hobby). However, if there is someone else who is capable of
> doing it if they are funded, I have no problem with that.
> I could either help them, or simply stick with working on NFS and leave
> SMBv23 to them.
> 
> Sorry, but I cannot report real progress on this as yet, rick

No need to sorry. I really appreciate your endless work on NFS and that 
you still have kind of interest to try porting SMBv2/3.
Unfortunately I don't know anybody else trying to do this tremendous work.

Kind regards
Miroslav Lachman

From nobody Mon Jun 27 15:19:28 2022
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 3FF5F86832D
	for ; Mon, 27 Jun 2022 15:19:38 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2072.outbound.protection.outlook.com [40.92.97.72])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWrxP1H9gz4VfF;
	Mon, 27 Jun 2022 15:19:37 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ILTVft2OVQCOsJCvgCiz+yVJ0IIqYpo1h5Ym4JbSlcYQwCi7ULp6LrVKA0tokd4cSs+ftl/HRAhIf55WobXwNKtbEbHNVcYtRsvXZG+iVgXtuBNUL53HvJFxQJqAdYvWD/Kd/iLh7iWu8zABKymh0jJH5mEXLgZN65kjVJpBcm26NLkOcNigkwrIcmPbUQwebEpRfODu6OGyjm8ZOdIXuouf3SULnxADocnlpvHeUtjoYbQhKq17n9piSO57nSkGybySW7FKtjsvF1W6//HCCZ7o8eaJ9lmddC2EvEZFf6uIPXLqVhUcaE60f7u2otwkm/yoshqvg9baFoi+imxlqw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=VLDfzxv2GZs9Ne0xJAZ94AllWLfn8V25xOBdjTlBXGc=;
 b=FR/J4e7Ew3WpwEXZI2JGpZvjHYWOQYwG26+ag6SuhQdELYZVcdGD+jiocAxI1p4Uf5el6LefWSkJPT8xv4HnGAPKFSqxGtNA9oSf0LotLhxi8GyRFNyI8esYjlCshRLdstnFvNPIrP3DskPU0yszr2vg915COUKn5+AN4j5mUqu/6xQ1JjpteeIgEOfy5dhvZgCYsjS7EnpVB0iLUq9lYiXUn4UkhgHCwayM3X98bWQuCa8J1W1Jkdn9W2ApDQeBsJfcWaLKzgusM1m64IjgHZqJaSd5yNzjCp25QvKI+Xj1lwIEM8a3VDIGEjGqoyD7GT07zt2FYh1BOPUUfBAcFg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=VLDfzxv2GZs9Ne0xJAZ94AllWLfn8V25xOBdjTlBXGc=;
 b=qDxXJjWtelxJY7KS1TjrDDDPJjY8Wyx3pbASW0JYc9SM9s22t9dnAiVDuV/WFzD7ZhuARR7QwAByoSX/kpTxi5QJSqbx0sGBdtQpNQ0A+5AETsl6HcrdDimdHmRnsk3xMtxQFYY9bNLuy/sFeviz0k9jVc945jX2XdeowqYaoV5CuTJLlQFH5WKBBurtHNkBM3HAhoVCZfGvi0Ov2pOOL30WdneO1O7KRWguAZ7OSirDPibI8rou3D9TrKVa6lUkDrciC50jLR9OMNwXCoqLkF9Xx59ZRbxayLFDAiSXqjYR3Mcy/t96CrSX9PjMLwUu7x2pi25dxIyOjctXS3VZ8A==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CP4P284MB0803.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:91::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.16; Mon, 27 Jun
 2022 15:19:28 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%8]) with mapi id 15.20.5373.018; Mon, 27 Jun 2022
 15:19:28 +0000
From: Ivan Quitschal 
To: "freebsd-current@freebsd.org" ,
	"wulf@freebsd.org" 
Subject: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Thread-Topic: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Thread-Index: AdiKNwIPD56grc49TwS+3NUAqhONSQ==
Date: Mon, 27 Jun 2022 15:19:28 +0000
Message-ID:
 
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [m9Csef/k7e6vhYlDA4PPpj+uMF75Txo167zHPxpwgVmDaKzq0+/pDpJMRC5h1HVi]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7528f534-9528-433c-d399-08da58506d81
x-ms-traffictypediagnostic: CP4P284MB0803:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 PMugmpAE+W6QU42IUwHuH/2Vn+m4Iru6ue/wAXuKpjgSWxT5ClQEFPYN4D0x72f3/muOp7+Puyq8pleB/z12HTMYBixQXWUmA9YC5OXQd1Kr129HWP2+cPvNyrFt69UJoy7YrHNCDa7XXo6d0oT8tmGvFVJGwFGRDx0dwIFcnzDk7h2KyaPyMzV1AGYxK8SX3noa8uCuN1JZWjqN4XY0Hy0gsEFpf/ourK1DIoCh2f15lr429mZIHo943ZUp3R7tzhGg+x/nME1+f0ULLTOqxcUZnJ3/BslOvYLI0JD/pSmRHa4XEE+qS3IaADajrgN1JYJuNBleinvt+3jSKQesNcHjsWKGjUKhehR2ogrJmn+OZyQv6mNI+QGBxcUxmRMAVxv2xr50qni9upeDsHMYGO3eXeinZ0FnoV1WmPrRwuQIDgY8mA3iloH75Ti7ArGpfSLQVaJr54SHbqMgyNRHzrOfAcBokNVxhYzCHxFWSDHLdJeRB2UvdPm5u9WSAXfHBamKAzx+YbckYB/nZPE1NKLPg+xOWxI4p3qgAsrxjze1x8Rm+/MhWMkhG/oXZ64a5LVKq6SacX1c6WfSRhI+JWieoiCAg1s+iZB8IyEuVVJQFVfEYJW97tRkMQ5XcTh2
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?Jwf+vjlSHfMgPQfdcjXObCNXPXCvjfgGJhCRFubZSY8JfIeAUrQBld2cCi+9?=
 =?us-ascii?Q?xYFcfNBMPaYwwvZCsQriPnnHi664cdD0cQ9D3b158GiSibj/ZJvBdnRwQ7DP?=
 =?us-ascii?Q?as4pOCMPBvp+eK3Gx2Q/XUnAYvrlvMwBDPSJknv/8l1dV/r/baa4sZydMo83?=
 =?us-ascii?Q?cvjb74Figmydws1aSvfN724si2ivvdIZR6U2IEbGh3LrvJRdDgvcHnkcOElv?=
 =?us-ascii?Q?2o3caLNYWLELBMGAzUQosxkBvstN84L+CU9mCAgOljiJSwhmLlUYnnQKSSJK?=
 =?us-ascii?Q?iFrdEMxs/N9xZbIg8x6pba1J6msvLyAx0MdcIDAsQGRLxkHQae+Bben47l1H?=
 =?us-ascii?Q?Oc2id6+XA7NRHg56lMaINwbdxJlGkb/8uvSjDLQQ+6WT6flkWIQwseL0/V9s?=
 =?us-ascii?Q?TaeCx0kgPhpH0fqvFWbP5Mw9+Kxj1y3EDuYLdiHKhv0aq4cvG29Ombz3XHuV?=
 =?us-ascii?Q?RN69JzYVoCSBv9upuULFTBJypYdaQwLS2r8j2Md4r4ttnQ3GEuQrO2JXN4yj?=
 =?us-ascii?Q?0Q0DHQy/BUyAuXHhjBVCPH4P095wYogqiXvEwdHCNfuqSDXHk8bwyiqIM2Yn?=
 =?us-ascii?Q?w07hCWTWu9gJSCezGEOILoU5KGGerwdUgIXi+LfWRF5eiYSzGV7k+MatC/ZZ?=
 =?us-ascii?Q?k11jhEAy4dtSzcYehFUKL6YgyGMBUVfv6xFePFacJHzWiJAZikAnsB24kCk4?=
 =?us-ascii?Q?i2iP0tABNP0OHYg1ONGIzQsRr5YzaRgO+wsv60ufkruljE8eSJcl/3+kgMfd?=
 =?us-ascii?Q?jo25ZpNw6JKfCzSTTHcHsRzyGRpgUoV75wzDSZHJeYPPYY5zLu2e7sp8xC1H?=
 =?us-ascii?Q?xZrjLG0xghfuYgtHcqeoz0MXABAK5w1uF0qlWVJdEeyyinq4p3NkhR6g8AMN?=
 =?us-ascii?Q?0XMG/f5O1tvsHsJRclnwOsjKM2mfkvmleqzwt2p2P+jFx3iDeSuZGpt0oCAU?=
 =?us-ascii?Q?5vFO70ml3I/+xi2/d7HlXYc7AlHi5AzyxugOe+UgY5lFFUKTlUDSM2UupulD?=
 =?us-ascii?Q?j1H2+C9aRYXAbMXy6CwamEehdW5jZ56f6imVMS1ZbZXPESNayQ/s1j/nCZez?=
 =?us-ascii?Q?5nX8xLUpUJPgmcxvUs9mkPEDTpx0dTOoANcwUBd+R5Jj0OdIfc6MkgId1bAO?=
 =?us-ascii?Q?h9q9Si2jHTCYuDKJvOc7S2+1fKAaOOaoBbfXMjFU5dTIlgnQbsykKNcO4Gju?=
 =?us-ascii?Q?TmQNtczUvHY5yanxVCgTMwhUku98Y579t5TyPhzo9tXaAoOZEhDsfTYHK/Fz?=
 =?us-ascii?Q?gmwtMumysZ+IJ58Icbg1UpsUNenuFcivGpna9pkq9EDRAlY5YpjybV+sY9u3?=
 =?us-ascii?Q?1WZU4KohNLSJQ2eqA7fPj0lC?=
Content-Type: multipart/alternative;
	boundary="_000_CP6P284MB1900818F505F78F68EC4C6BECBB99CP6P284MB1900BRAP_"
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-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 7528f534-9528-433c-d399-08da58506d81
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2022 15:19:28.3886
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP4P284MB0803
X-Rspamd-Queue-Id: 4LWrxP1H9gz4VfF
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=qDxXJjWt;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.72 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-2.55 / 15.00];
	 DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	 NEURAL_HAM_MEDIUM(-0.55)[-0.547];
	 R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 FREEMAIL_FROM(0.00)[hotmail.com];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_SPAM_SHORT(1.00)[0.997];
	 RCVD_COUNT_THREE(0.00)[3];
	 DKIM_TRACE(0.00)[hotmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[40.92.97.72:from];
	 TO_DN_EQ_ADDR_ALL(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 FREEMAIL_ENVFROM(0.00)[hotmail.com];
	 ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]
X-ThisMailContainsUnwantedMimeParts: N

--_000_CP6P284MB1900818F505F78F68EC4C6BECBB99CP6P284MB1900BRAP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all

Not sure if I found a problem here but here we go.

Since I have a KVM usb switch here for keyboard/mouse sometimes I toggle it=
 between my windows and freebsd.
I am using iichid here to have my multimedia keys working on keyboard and a=
ll

hw.usb.usbhid.enable=3D"1"

Im also using Wulf's moused
https://github.com/wulf7/moused
so far so good. Problem is:

when I switch to windows , everything is detached correctly (hms, hkbd etc)=
, but when I switch back, sometimes
the keyboard and mouse are wrongly attached to "ums" device , not hms. (som=
etimes it goes to the correct one).
Shouldn't ums/uhid modules be deactivated once hw.usb.usbhid.enable is set =
to 1 ?

The workaround I did here was to manually kldunload both uhid.ko and ums.ko=
 within rc.local during boot.
This way I can detache attach the kbd/mouse back as much as I want and it a=
lways end up in hms/hkbd devices

Is this how its supposed to function? Randomly choosing between ums or hms?

Thanks

--tzk


--_000_CP6P284MB1900818F505F78F68EC4C6BECBB99CP6P284MB1900BRAP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all


 


Not sure if I found a problem h=
ere but here we go.


 


Since I have a KVM usb switch h=
ere for keyboard/mouse sometimes I toggle it between my windows and freebsd=
.


I am using iichid here to have =
my multimedia keys working on keyboard and all


 


hw.usb.usbhid.enable=3D"1&=
quot;


 


Im also using Wulf’s mous=
ed 


https://github.com/wulf7/moused




so far so good. Problem is:


 


when I switch to windows , ever=
ything is detached correctly (hms, hkbd etc), but when I switch back, somet=
imes



the keyboard and mouse are wron=
gly attached to “ums” device , not hms. (sometimes it goes to t=
he correct one).


Shouldn’t ums/uhid module=
s be deactivated once hw.usb.usbhid.enable is set to 1 ?<=
/p>

 


The workaround I did here was t=
o manually kldunload both uhid.ko and ums.ko within rc.local during boot.


This way I can detache attach t=
he kbd/mouse back as much as I want and it always end up in hms/hkbd device=
s


 


Is this how its supposed to fun=
ction? Randomly choosing between ums or hms?



 


Thanks


 


--tzk


 






--_000_CP6P284MB1900818F505F78F68EC4C6BECBB99CP6P284MB1900BRAP_--

From nobody Mon Jun 27 15:26:55 2022
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 A8AA786A5D3
	for ; Mon, 27 Jun 2022 15:27:11 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4LWs665Hxtz4XrJ;
	Mon, 27 Jun 2022 15:27:10 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 9BB6C260102;
	Mon, 27 Jun 2022 17:27:02 +0200 (CEST)
Message-ID: <420b1f58-09c4-6876-b1ad-91751c60e83c@selasky.org>
Date: Mon, 27 Jun 2022 17:26:55 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Content-Language: en-US
To: Ivan Quitschal ,
 "freebsd-current@freebsd.org" ,
 "wulf@freebsd.org" 
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LWs665Hxtz4XrJ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.89 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 ARC_NA(0.00)[];
	 NEURAL_SPAM_SHORT(0.24)[0.243];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.84)[-0.836];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[hotmail.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received]
X-ThisMailContainsUnwantedMimeParts: N

On 6/27/22 17:19, Ivan Quitschal wrote:
> Hi all
> 
> Not sure if I found a problem here but here we go.
> 
> Since I have a KVM usb switch here for keyboard/mouse sometimes I toggle it between my windows and freebsd.
> I am using iichid here to have my multimedia keys working on keyboard and all
> 
> hw.usb.usbhid.enable="1"
> 
> Im also using Wulf's moused
> https://github.com/wulf7/moused
> so far so good. Problem is:
> 
> when I switch to windows , everything is detached correctly (hms, hkbd etc), but when I switch back, sometimes
> the keyboard and mouse are wrongly attached to "ums" device , not hms. (sometimes it goes to the correct one).
> Shouldn't ums/uhid modules be deactivated once hw.usb.usbhid.enable is set to 1 ?
> 
> The workaround I did here was to manually kldunload both uhid.ko and ums.ko within rc.local during boot.
> This way I can detache attach the kbd/mouse back as much as I want and it always end up in hms/hkbd devices
> 
> Is this how its supposed to function? Randomly choosing between ums or hms?
> 

Hi,

Can you dump "kldstat" at the different times?

I guess it may be just be that the wrong module is loaded first, so it 
grabs the device, because there are no other drivers loaded, even though 
ums is a generic driver.

Try loading all relevant drivers in /boot/loader.conf . Then the attach 
order shouldn't matter.

--HPS

From nobody Mon Jun 27 15:37:02 2022
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 DACCF86C53A
	for ; Mon, 27 Jun 2022 15:37:14 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWsKk2X5bz4ZQf
	for ; Mon, 27 Jun 2022 15:37:14 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x931.google.com with SMTP id o21so3574234uat.6
        for ; Mon, 27 Jun 2022 08:37:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=ocA72TYs9gaVLFziT5UEE9Lcac8YJNqH00yJFB2xjOw=;
        b=sAqsWPF5BsSbdCEFvzhwBGgmWrmxv7pxzAH6r8qRxC5WbNBjRcxE7jvWtiapXNfSl+
         /CZBQwPcLwmDUGgEntWnT8beTGzDk/NXOmXFUFoJGJ2UoeqTiNY8p1ZvsNzsg0zDzrQ0
         YXAywtIWA3pEyOV0e3m8UTPGJ2vn1pmLqcRrTRx1pC4+wY5+aw3StZaTRk8hxx+olL9z
         cBS6WyfUpNNxMEs9mShZQ01ZY/gpiMHTaAMOEwwVZ1ahr/5rxZtJ74ktCk+s4Y0xzyft
         P2J5YC+hTIn1tu5+w+zCBdBi6Xt5Er9Q5oq4EARl7fKjEFfa2xcMXxxeOoPDxD0QFflw
         SYrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=ocA72TYs9gaVLFziT5UEE9Lcac8YJNqH00yJFB2xjOw=;
        b=AT2s85jAgN8ldJ/qqUZwOVFL49XPowjPZ+Hsk5A4tNOY1sEZ40Zo0UY5O5L9kikqcg
         a23dQx4MnIU1tR+VM4XEXQ0/cBI/aklnZUrASeaQVKkjRCr6X9JgvQBOFMm/dr0GKw3P
         o+JYEKqdiwlV15BsrHFF0IH3ijsIvOGXczLthU9aP6orLgwlQqMQVrCA4xYB6W8J9keT
         a553LOmAlblHh6GcJb2kQLvxjq6vgSKXI6MLqQU63FMwF4MOnTteTXtq6CfbLGEiZHH+
         VRkUDSe559LuuGz+eyyy3PEpdj+rWkhIrHT5pp7AWNYTzfEoXVdP54yA2nQ7cvD7FZY6
         /0Pw==
X-Gm-Message-State: AJIora/LnnUIogH0NoxVw6srwFy9QAdlQT9Zr1ZhGyAafTXQWu/6zL1E
	xl3ynnnMaE5qzmZMYRa8Krl4yEsnbNeXA8677WURYCnPpQM=
X-Google-Smtp-Source: AGRyM1vJG6WEc6P4R5+tEtHPdZvwXPwE/8CdLn0g9r7MVrdR992Q9t8jdvJt45GL5OSr5oCenJUPsvk2ccGmW8o0BW8=
X-Received: by 2002:ab0:764c:0:b0:37e:ff9f:4d27 with SMTP id
 s12-20020ab0764c000000b0037eff9f4d27mr4799596uaq.24.1656344233752; Mon, 27
 Jun 2022 08:37:13 -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: 
 <420b1f58-09c4-6876-b1ad-91751c60e83c@selasky.org>
In-Reply-To: <420b1f58-09c4-6876-b1ad-91751c60e83c@selasky.org>
From: Warner Losh 
Date: Mon, 27 Jun 2022 09:37:02 -0600
Message-ID: 
Subject: Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
To: Hans Petter Selasky 
Cc: Ivan Quitschal , 
	"freebsd-current@freebsd.org" , "wulf@freebsd.org" 
Content-Type: multipart/alternative; boundary="000000000000add41b05e26fb199"
X-Rspamd-Queue-Id: 4LWsKk2X5bz4ZQf
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=sAqsWPF5;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::931) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 RCVD_COUNT_TWO(0.00)[2];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[bsdimp.com];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::931:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	 R_SPF_NA(0.00)[no SPF record];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	 RCVD_TLS_ALL(0.00)[];
	 FREEMAIL_CC(0.00)[hotmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000add41b05e26fb199
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 27, 2022 at 9:27 AM Hans Petter Selasky  wrote:

> On 6/27/22 17:19, Ivan Quitschal wrote:
> > Hi all
> >
> > Not sure if I found a problem here but here we go.
> >
> > Since I have a KVM usb switch here for keyboard/mouse sometimes I toggle
> it between my windows and freebsd.
> > I am using iichid here to have my multimedia keys working on keyboard
> and all
> >
> > hw.usb.usbhid.enable="1"
> >
> > Im also using Wulf's moused
> > https://github.com/wulf7/moused
> > so far so good. Problem is:
> >
> > when I switch to windows , everything is detached correctly (hms, hkbd
> etc), but when I switch back, sometimes
> > the keyboard and mouse are wrongly attached to "ums" device , not hms.
> (sometimes it goes to the correct one).
> > Shouldn't ums/uhid modules be deactivated once hw.usb.usbhid.enable is
> set to 1 ?
> >
> > The workaround I did here was to manually kldunload both uhid.ko and
> ums.ko within rc.local during boot.
> > This way I can detache attach the kbd/mouse back as much as I want and
> it always end up in hms/hkbd devices
> >
> > Is this how its supposed to function? Randomly choosing between ums or
> hms?
> >
>
> Hi,
>
> Can you dump "kldstat" at the different times?
>
> I guess it may be just be that the wrong module is loaded first, so it
> grabs the device, because there are no other drivers loaded, even though
> ums is a generic driver.
>
> Try loading all relevant drivers in /boot/loader.conf . Then the attach
> order shouldn't matter.
>

We should fix the priority of the two drivers if the order matters...

Another possibility is that the ums is loaded and hms isn't so ums wins. If
any device wins, devmatch isn't invoked to load possible drivers..

Warner

--000000000000add41b05e26fb199
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Jun 27, 2022 at 9:27 AM Hans =
Petter Selasky <hps@selasky.org&g=
t; wrote:
On 6/2=
7/22 17:19, Ivan Quitschal wrote:

> Hi all

> 

> Not sure if I found a problem here but here we go.

> 

> Since I have a KVM usb switch here for keyboard/mouse sometimes I togg=
le it between my windows and freebsd.

> I am using iichid here to have my multimedia keys working on keyboard =
and all

> 

> hw.usb.usbhid.enable=3D"1"

> 

> Im also using Wulf's moused

> https://github.com/wulf7/moused

> so far so good. Problem is:

> 

> when I switch to windows , everything is detached correctly (hms, hkbd=
 etc), but when I switch back, sometimes

> the keyboard and mouse are wrongly attached to "ums" device =
, not hms. (sometimes it goes to the correct one).

> Shouldn't ums/uhid modules be deactivated once hw.usb.usbhid.enabl=
e is set to 1 ?

> 

> The workaround I did here was to manually kldunload both uhid.ko and u=
ms.ko within rc.local during boot.

> This way I can detache attach the kbd/mouse back as much as I want and=
 it always end up in hms/hkbd devices

> 

> Is this how its supposed to function? Randomly choosing between ums or=
 hms?

> 



Hi,



Can you dump "kldstat" at the different times?



I guess it may be just be that the wrong module is loaded first, so it 

grabs the device, because there are no other drivers loaded, even though 
ums is a generic driver.



Try loading all relevant drivers in /boot/loader.conf . Then the attach 
order shouldn't matter.

We should f=
ix the priority of the two drivers if the order matters...

Another possibility is that the ums is loaded and hms isn't so=
 ums wins. If any device wins, devmatch isn't invoked to load possible =
drivers..

Warner


--000000000000add41b05e26fb199--

From nobody Mon Jun 27 15:42:10 2022
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 D1AF186D75C
	for ; Mon, 27 Jun 2022 15:42:51 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWsSB5Y1gz4byn;
	Mon, 27 Jun 2022 15:42:50 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id 3c1321f3;
	Mon, 27 Jun 2022 15:42:43 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id a70033c5 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Mon, 27 Jun 2022 15:42:43 +0000 (UTC)
Date: Mon, 27 Jun 2022 17:42:10 +0200
From: Michael Gmelin 
To: Ivan Quitschal 
Cc: "freebsd-current@freebsd.org" ,
 "wulf@freebsd.org" 
Subject: Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Message-ID: <20220627174210.28f5598a.grembo@freebsd.org>
In-Reply-To: 
References: 
X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}>
 +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl
 LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL
 EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl
 YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq
 AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY
 fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM
 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea
 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+
 xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA
 Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n
 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v
 f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT
 L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF
 CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc
 Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII=
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LWsSB5Y1gz4byn
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [0.57 / 15.00];
	 ARC_NA(0.00)[];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 FREEFALL_USER(0.00)[grembo];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_SOFTFAIL(0.00)[~all:c];
	 NEURAL_SPAM_SHORT(0.93)[0.928];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 MID_CONTAINS_FROM(1.00)[];
	 NEURAL_HAM_MEDIUM(-0.26)[-0.259];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[hotmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On Mon, 27 Jun 2022 15:19:28 +0000
Ivan Quitschal  wrote:

> Hi all
> 
> Not sure if I found a problem here but here we go.
> 
> Since I have a KVM usb switch here for keyboard/mouse sometimes I
> toggle it between my windows and freebsd. I am using iichid here to
> have my multimedia keys working on keyboard and all
> 
> hw.usb.usbhid.enable="1"
> 
> Im also using Wulf's moused
> https://github.com/wulf7/moused
> so far so good. Problem is:
> 
> when I switch to windows , everything is detached correctly (hms,
> hkbd etc), but when I switch back, sometimes the keyboard and mouse
> are wrongly attached to "ums" device , not hms. (sometimes it goes to
> the correct one). Shouldn't ums/uhid modules be deactivated once
> hw.usb.usbhid.enable is set to 1 ?
> 
> The workaround I did here was to manually kldunload both uhid.ko and
> ums.ko within rc.local during boot. This way I can detache attach the
> kbd/mouse back as much as I want and it always end up in hms/hkbd
> devices
> 
> Is this how its supposed to function? Randomly choosing between ums
> or hms?

Did you set hw.usb.usbhid.enable="1" in /boot/loader.conf, or by using
the sysctl? If you don't do it yet, I'd recommend the former.

Cheers
Michael

> 
> Thanks
> 
> --tzk
> 



-- 
Michael Gmelin

From nobody Mon Jun 27 16:18:58 2022
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 49B30873AF2
	for ; Mon, 27 Jun 2022 16:19:08 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2014.outbound.protection.outlook.com [40.92.96.14])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWtG31B1hz4hS2;
	Mon, 27 Jun 2022 16:19:07 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=K7Z1xUQrxrcE9YF8C/S1X+xxUF7DIcSdD7/Xu15YwInmwslJ9Use11E0B5sLGc/ZIpnV/55HvvepOHkV5tB6sNlVUsPeh1L61KBv5FyCmyRGJWhP1z8OCDGrLw3m/6BqERhLZF74LcS5nYX/2xI3D7uxcnvgOC5DvXUvDop2dxE4Tw9d8vMTOZQxYpWjRb9LkhYgx8qGe5M78zKQZoJFcmj1FWkky7wJ5F8lm0RjWqbqh12wLEMWjyQqMqlMJjX/bVVkz8VK4A95Jsp5uK3dzC6yW2FAsuiNffq8Rf4j1X5LagaBffwtT+aYrORArstvtE0FOqeDfrX0pQ5SNcAuRg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=ob3oyPXV9VUhlIcgk6k5o90wWsH7jWSj1Ei9inNS280=;
 b=BqOEKrPbdFAAfa7ne59p+QNaRMXMwR7BUoaGPVzqGEN7spycozYOxxfRH5854cgLXKKLpUpDFhAAkk2n8LpjK+odxOBSfBVxBRMef9aR7g4HkqNGA12WG0jVUp835p7QvMfkSbaQEOQgc0tAZ6G+i4QPMYJlcNQV59yXCFFWPQ5Y90iCycaM7qcfPicUUDMfJnoHIbe0C/GHSqMtqtQF2ndjzha2W1+VbhpiAZX2qh1vreFhppawfPXqAnkAPKLo9ovUSEms9XOdBwkA4dcPugeaSoS44ebWW0m4GQ6y+Hpz2EmVUBsE5yx8J6gOL1PfI5aPFE8rUB+gbQubpyGD6g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ob3oyPXV9VUhlIcgk6k5o90wWsH7jWSj1Ei9inNS280=;
 b=d/Po/Tk6W3ZSzRX/4jCupegBJVn0RdzISnmEuCIHqyGFALSKZoz34i2mowyJtxvZ3OGRiJZaCJoquaFE0MnTYbhYzYXqJwU4r825IpyZHYa11Ksm4692o2Dey6cm+qV1P19M3bBR0ojUmDLHPIRRQtP7KLgdOCE6+xSi90xlSdVnw65smHlDerFRDHma+mFSNT8peI3XMtEFe+aP8UpohPmRd/e8TCwtt8dVFCiZbD1sI45MCKQ2S97JNgduDdWwNItmEpA04ugel1mwMRLxfmCQaIgxYgi9OmAidiWfjyN4QUO49xL9CDsk+GlWj9Yuw6J0rAlMP2IIOGNKW0EQNQ==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by FRBP284MB0636.BRAP284.PROD.OUTLOOK.COM (2603:10d6:203:3e::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.17; Mon, 27 Jun
 2022 16:18:58 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%8]) with mapi id 15.20.5373.018; Mon, 27 Jun 2022
 16:18:58 +0000
From: Ivan Quitschal 
To: Hans Petter Selasky , "freebsd-current@freebsd.org"
	, "wulf@freebsd.org" ,
	"grembo@freebsd.org" , "imp@bsdimp.com" 
Subject: RES: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Thread-Topic: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Thread-Index: AdiKNwIPD56grc49TwS+3NUAqhONSQAA1MqAAAFxcZA=
Date: Mon, 27 Jun 2022 16:18:58 +0000
Message-ID:
 
References:
 
 <420b1f58-09c4-6876-b1ad-91751c60e83c@selasky.org>
In-Reply-To: <420b1f58-09c4-6876-b1ad-91751c60e83c@selasky.org>
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [2phxqrrZqMsh3v7i5P944QftuRBmglzB4BGLW6Ww6gJ+lqpIgPjYmTigLp5QOYbM]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7af4f1cc-d6f6-4d76-cd1a-08da5858bd82
x-ms-traffictypediagnostic: FRBP284MB0636:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 T0EJmXMo+DlCtGhDOWxk0+HJZxOeOCvIqV2nml3EnM2ke7DcbmWuS7jhzAL2d8DRyWw66ARGDyFDPQdnvQIa3qeJK6PfgABAXqRtp3SzQiamH1cnLOpTa6EUMVfIMbWy5BycSIlkbwgjZgfJEZ/cS9OPt+N1DIsdIMWay+OwHQIihzqekHaSW5gWEXrWw0hfzg91MkcSa/NlEze/bR8mrYFwoD65rhppk/JgxjD98fzjW62GDy68ogyWEFUOWf+5UZXtt/uFcnX3SjDi5CtSsnGuZMilcLd/0dv0LqIexyj3hU+a+l6gGrxFUhAAWvoJ5iq4IDOgNh6h4Zo0OAxXoMSOTVbYhqpU0FbZMv0/BcScu+B4F/B5aZN1u5oF8HpCsABa32Y0taxcr5S6FY1pJUNjLpI9+aThfLT6unCW+7qcvrJVpvCeyKcVWIt1Kqhq2NbkDop2fdKiFlAGCgo3OlX5IB4yJ6J3bXeEl2VRDpxZM1ttCDfuxLhlqx1FHX4fk7pADnNU5Yiu2f6QXQsrVaeToE8dAAijC8w4oaPFZbgfcRmIYYQ+KYELPBplfD5BBeAl48ZxevKpxGKD+a4tt5Ka6ypa8aZuY59qWiFrSDRzWsbry1NBac7l/p0ulTwm+w+yYTxoia5vluXVDqCiDQ==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?HCMh7XDNk8x0D8c8/WqacCtO/ewL2766z8FkAx6tlJiqGxOzyDaK4MawMpCK?=
 =?us-ascii?Q?rP2ObF0podYBYT6vvT92Vy6hsNifIk6pjj4SBL0bFqD7ROZGBiFqydYZIgHh?=
 =?us-ascii?Q?JmDiLmbLy1GpN37xYSNh3arCyd4+xVwhLWFF/E0wDIq48cqWTZGKi3vtdL9y?=
 =?us-ascii?Q?ZUl1/EIhy4PaliXCSS5y7JapFTenvbCkwz9IMkwgdjcJ8ycckBz6AjvNb1+T?=
 =?us-ascii?Q?U2d9tQtp92VOvBb/+QrhWxmQoG3fLYfElRHE1GdzMZvDvCcRoeSx/yiXmFyj?=
 =?us-ascii?Q?lRzxt5ejTL/iF5jm0RJgv92a72rMaAukDOh7HPQwdn/BoYHDQIdfNGxmk5rL?=
 =?us-ascii?Q?7UyCtYRZPJCiJHabDMsHbEdTTIAyfs9bmwRYuqNJap1u7KFBuEwLKQsu/FiN?=
 =?us-ascii?Q?GygkWUM92uRg+2pO8lGDUnkBjEw0+6PRY4ktpfWtLjNNGFo9Xs0qyplM1ubo?=
 =?us-ascii?Q?XJiYJ8RIbiPxyaWCNDJCLOyHjW65TsIB362h4jK1otcEsAPJ4fHKDZYV+QFv?=
 =?us-ascii?Q?cHwBr2RR+dF0+vXHqX6d09J0nX8R6hQtMY7pVfqU8T8N7QBwJEETyXx8/pZK?=
 =?us-ascii?Q?hNOIIJ5XaF2ABE4dVgMlz/0g7OVSjJmW0S4XVe5r/6ySUWf0FzfywHycbU3e?=
 =?us-ascii?Q?qz0TY80+Mf61wJY3gMWD9zFbnSu5tlu8kdqRzi+D3WYn+xTYipYHqbk7GG/z?=
 =?us-ascii?Q?K/9Lh/kwdHmEF8hvrjAVh2C70b2m8O4E4b8SOAnviRYYim/00wGcV5gOiao+?=
 =?us-ascii?Q?Y7ubcrAdj4Wxpl0zq4YfcXd95XXqDsUjr3Zq3cHQn9MJRrt+GgAddwPlaYwN?=
 =?us-ascii?Q?EuMhN4Fo3WmCK2VZsooy0JuTThT2bm3SmcsP3J1MeYbM7pEkpiKVqVT/RjFr?=
 =?us-ascii?Q?78TP4NJW/xFqfNVTfkJNrGaDl0mjf26WrZJ/IAg7xfFY3h/Tp/QeanpjLJnc?=
 =?us-ascii?Q?TFZB+cO11LpQZMl+Q1rsqsJtvrVheuLyst5nPUbN9XwLiTlV9YapeZQR34H4?=
 =?us-ascii?Q?YdX6ZtUN0rG0Plja8nbo79P+ePK81kqK8PHn57s7eHSlA9LwUlGAiEUIBNdO?=
 =?us-ascii?Q?RV5BOdH/co5i6oQcp8p7KNd7xTZ8iosXB9YKECp31bq1XvPGhZT1eqn1/swy?=
 =?us-ascii?Q?m/Bi89dobmDiSARa2z4hMwf879Qtyq4u6Kx4DfDzaBboIIo1VYkBYUBvLkWO?=
 =?us-ascii?Q?YzN4XK4la8m9hHHAjJuRaq1R1V1DxdH9tNillpv4bIcOzAsm3BeclE88FAM1?=
 =?us-ascii?Q?a72Cxdj8KoarNm17xNq5i8bbFUtWdOF2EbwpzZHq3ro1XT7iwHYsEfzRx/vj?=
 =?us-ascii?Q?p5qgxMWrfmtKufTE/GRLPbgG?=
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
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 7af4f1cc-d6f6-4d76-cd1a-08da5858bd82
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2022 16:18:58.6022
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRBP284MB0636
X-Rspamd-Queue-Id: 4LWtG31B1hz4hS2
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b="d/Po/Tk6";
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.14 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-2.27 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.26)[-0.265];
	 R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[hotmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_SPAM_SHORT(0.99)[0.994];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	 RCPT_COUNT_FIVE(0.00)[5];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[hotmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[40.92.96.14:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[hotmail.com];
	 ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N


> Hi,
>
>Can you dump "kldstat" at the different times?

>I guess it may be just be that the wrong module is loaded first, so it gra=
bs the device, because there are no other drivers loaded, even though ums i=
s a generic driver.

>Try loading all relevant drivers in /boot/loader.conf . Then the attach or=
der shouldn't matter.

>--HPS


Hi Michael=20

Yes , hw.usb.usbhid.enable=3D"1" is in loader.conf , not sysctl=20

Hi Warner

When ums.ko is up, the second attach is always taken by "ums" first no matt=
er what. First time you boot tho, it takes the correct one (hms)

Hi Hans

Looks like this below is the only order I could make it work even tho  uhid=
 and usbhid get loaded regardless what I put on loader.conf

usbhid_load=3D"NO" <-- still loaded anyway
uhid_load=3D"NO" <-- still loaded anyway
ums_load=3D"NO" <- this one is not loaded
ic_load=3D"YES"
iichid_load=3D"YES"
hidbus_load=3D"YES"
hsctrl_load=3D"YES"
hidmap_load=3D"YES"
hcons_load=3D"YES"
hkbd_load=3D"YES"
hms_load=3D"YES"
hmt_load=3D"YES"
hconf_load=3D"YES"

hw.usb.usbhid.enable=3D"1"

with the order below , after 5 reboots and lots of kvm switches , it always=
 ended up on the right iichid device. Seems to be working now

but like I said, its random, let see after some more reboots if this rule i=
s still valid

thanks

Ivan

From nobody Mon Jun 27 16:27:07 2022
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 11E5C875EF1
	for ; Mon, 27 Jun 2022 16:27:43 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWtRy1TXyz4lMJ;
	Mon, 27 Jun 2022 16:27:42 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id 9fabc163;
	Mon, 27 Jun 2022 16:27:40 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id dd537fa4 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Mon, 27 Jun 2022 16:27:40 +0000 (UTC)
Date: Mon, 27 Jun 2022 18:27:07 +0200
From: Michael Gmelin 
To: Ivan Quitschal 
Cc: Hans Petter Selasky , "freebsd-current@freebsd.org"
 , "wulf@freebsd.org" ,
 "grembo@freebsd.org" , "imp@bsdimp.com"
 
Subject: Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Message-ID: <20220627182707.5b7ed9cd.grembo@freebsd.org>
In-Reply-To: 
References: 
	<420b1f58-09c4-6876-b1ad-91751c60e83c@selasky.org>
	
X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}>
 +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl
 LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL
 EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl
 YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq
 AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY
 fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM
 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea
 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+
 xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA
 Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n
 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v
 f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT
 L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF
 CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc
 Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII=
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LWtRy1TXyz4lMJ
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-0.48 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 FREEFALL_USER(0.00)[grembo];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[freebsd.org];
	 R_SPF_SOFTFAIL(0.00)[~all];
	 RCPT_COUNT_FIVE(0.00)[6];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_SPAM_MEDIUM(0.60)[0.600];
	 NEURAL_HAM_SHORT(-0.98)[-0.976];
	 MID_CONTAINS_FROM(1.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[hotmail.com];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On Mon, 27 Jun 2022 16:18:58 +0000
Ivan Quitschal  wrote:

> > Hi,
> >
> >Can you dump "kldstat" at the different times?  
> 
> >I guess it may be just be that the wrong module is loaded first, so
> >it grabs the device, because there are no other drivers loaded, even
> >though ums is a generic driver.  
> 
> >Try loading all relevant drivers in /boot/loader.conf . Then the
> >attach order shouldn't matter.  
> 
> >--HPS  
> 
> 
> Hi Michael 
> 
> Yes , hw.usb.usbhid.enable="1" is in loader.conf , not sysctl 
> 
> Hi Warner
> 
> When ums.ko is up, the second attach is always taken by "ums" first
> no matter what. First time you boot tho, it takes the correct one
> (hms)
> 
> Hi Hans
> 
> Looks like this below is the only order I could make it work even tho
>  uhid and usbhid get loaded regardless what I put on loader.conf
> 
> usbhid_load="NO" <-- still loaded anyway
> uhid_load="NO" <-- still loaded anyway
> ums_load="NO" <- this one is not loaded
> ic_load="YES"
> iichid_load="YES"
> hidbus_load="YES"
> hsctrl_load="YES"
> hidmap_load="YES"
> hcons_load="YES"
> hkbd_load="YES"
> hms_load="YES"
> hmt_load="YES"
> hconf_load="YES"
> 
> hw.usb.usbhid.enable="1"
> 
> with the order below , after 5 reboots and lots of kvm switches , it
> always ended up on the right iichid device. Seems to be working now
> 
> but like I said, its random, let see after some more reboots if this
> rule is still valid

I don't know if it makes any difference in your case, but I had best
results loading these drivers through rc.conf, e.g.:

  sysrc kld_list+="hidraw hkbd"

Cheers
Michael

-- 
Michael Gmelin

From nobody Mon Jun 27 16:27:49 2022
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 D084E877853;
	Mon, 27 Jun 2022 16:30:52 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWtWb71TVz4mcq;
	Mon, 27 Jun 2022 16:30:51 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: by mail-wm1-x32f.google.com with SMTP id g39-20020a05600c4ca700b003a03ac7d540so5171405wmp.3;
        Mon, 27 Jun 2022 09:30:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=message-id:date:mime-version:user-agent:subject:content-language:to
         :cc:references:from:in-reply-to:content-transfer-encoding;
        bh=15Djp25W1RhM8IUab62NIr7HQj8RsxXgLPiJ2euiLg8=;
        b=o6lLspedXyjPdgyhnnW9YIq8AMTUi14RpBlHbxPwOWkw1fYyuW0MGYFwOD0SaiJfly
         Bb7g82AcHEbcZThzTPjZroYmP41DBSYiFIaJKqG/KT+ebpOGcypu6VKM+jV+0hfCYqHR
         xdKUsZCamymAgZLeNdu9bQSsKQxxiuKUXmZDXfOy7ZgMskN+nAyyP5HTfFaK6Uz2JwBd
         boxHpdka1t2vRtMcksBHk2KOMxF92zfDvbDe2W62bicX+OvZwaQMDvHBUmQTzc3XngU6
         +YmAvswQmyktYrBVhGNayrqySEJAK7MJnDMq7pqYIZyKtvNmPT94WkugK/pFKTmakc9q
         BfiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
         :content-language:to:cc:references:from:in-reply-to
         :content-transfer-encoding;
        bh=15Djp25W1RhM8IUab62NIr7HQj8RsxXgLPiJ2euiLg8=;
        b=pLihBYd0ar81ag4sBQKY1IQ1luQuUfyficlq69sc72kKysh0cqN3G+lV2WmhzkcRcw
         VWbtCj87G4C6gvFt7PONSEA/2Q8cgpW/4zURB9bIAIzpdtxUJOmAlc1/X/isou/pRcTv
         yPsCD/6gad3PnXfHeTP96sPvCXIi7Mq9mE7F2GjAoryTMo95UUTWU0d5EPaJFslkJb5m
         AfXPwhARkh0M6Je3ML9gOlwaNc5+EFatcoc5r5dekyEBK0gIobZVPxwpezQ5uIew43HK
         817Sf9wd33abuXYMAZu+OwDRDmOcco2QqJYSKMb4CvaRmF34yWsYEKyXrht/1wn/m0Iu
         S5jg==
X-Gm-Message-State: AJIora/wgTGEPw9noHTTpQwTjqz9FUlI3S865GADgr4oHtSyJhhQVFDg
	oTreRweeFrbJQa25eoGw5EzqRZUI4uLxJ39O
X-Google-Smtp-Source: AGRyM1sEFX2p2j9piqOIs34zjrrw0lnXyUnQKz0beq9KnW7R3w48R6PqmWSgrxM16Iy0AmfI+1EzGQ==
X-Received: by 2002:a05:600c:1991:b0:39c:88ba:2869 with SMTP id t17-20020a05600c199100b0039c88ba2869mr15513632wmq.14.1656347444892;
        Mon, 27 Jun 2022 09:30:44 -0700 (PDT)
Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2])
        by smtp.gmail.com with ESMTPSA id g16-20020a1c4e10000000b0039c5a765388sm14013433wmh.28.2022.06.27.09.30.43
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 27 Jun 2022 09:30:43 -0700 (PDT)
Message-ID: <9b61fe48-681c-90db-8663-5a4397a94523@gmail.com>
Date: Mon, 27 Jun 2022 17:27:49 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Support for images such as JPEG and PNG (was: Posting netiquette:
 HTML, attachments etc.)
Content-Language: en-GB
To: FreeBSD CURRENT 
Cc: FreeBSD questions 
References: 
 <753A27F9-9CEA-4592-A44F-91164917358B@freebsd.org>
 
 
 <20220626185904.mqetrczfcubslxzp@aniel.nours.eu>
 <20220627130035.04de0876.freebsd@edvax.de>
From: Graham Perrin 
In-Reply-To: <20220627130035.04de0876.freebsd@edvax.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LWtWb71TVz4mcq
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=o6lLsped;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32f as permitted sender) smtp.mailfrom=grahamperrin@gmail.com
X-Spamd-Result: default: False [-1.52 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-0.00)[-0.004];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FREEFALL_USER(0.00)[grahamperrin];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 NEURAL_SPAM_MEDIUM(0.48)[0.483];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32f:from];
	 MLMMJ_DEST(0.00)[freebsd-current,freebsd-questions];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 27/06/2022 12:00, Polytropon wrote:
> … support for JPG or PNG …

I posted a PNG image to freebsd-questions yesterday.

Archived: 

I assume that freebsd-current has the same allowance, or similar.



From nobody Mon Jun 27 16:58:14 2022
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 25C0287C21F
	for ; Mon, 27 Jun 2022 16:59:39 +0000 (UTC)
	(envelope-from vladimir@kondratyev.su)
Received: from corp.infotel.ru (corp.infotel.ru [195.170.219.3])
	by mx1.freebsd.org (Postfix) with ESMTP id 4LWv8p0tvRz4rYr
	for ; Mon, 27 Jun 2022 16:59:37 +0000 (UTC)
	(envelope-from vladimir@kondratyev.su)
Received: from corp (corp.infotel.ru [195.170.219.3])
	by corp.infotel.ru (Postfix) with ESMTP id ADEEC35E5CE;
	Mon, 27 Jun 2022 19:59:29 +0300 (MSK)
X-Virus-Scanned: amavisd-new at corp.infotel.ru
Received: from corp.infotel.ru ([195.170.219.3])
	by corp (corp.infotel.ru [195.170.219.3]) (amavisd-new, port 10024)
	with ESMTP id P_uXXs_9TLxb; Mon, 27 Jun 2022 19:58:49 +0300 (MSK)
Received: from mail.cicgroup.ru (unknown [195.170.219.74])
	by corp.infotel.ru (Postfix) with ESMTP id 3713235E5CD;
	Mon, 27 Jun 2022 19:58:49 +0300 (MSK)
Received: from mail.cicgroup.ru (localhost [127.0.0.1])
	by mail.cicgroup.ru (Postfix) with ESMTP id 399C242211F;
	Mon, 27 Jun 2022 19:58:48 +0300 (MSK)
Received: from mail.cicgroup.ru ([127.0.0.1])
	by mail.cicgroup.ru (mail.cicgroup.ru [127.0.0.1]) (amavisd-new, port 10024)
	with SMTP id F3EsMHq_BMVg; Mon, 27 Jun 2022 19:58:41 +0300 (MSK)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by mail.cicgroup.ru (Postfix) with ESMTPA id 257F742211C;
	Mon, 27 Jun 2022 19:58:41 +0300 (MSK)
Message-ID: <8674be8f-b4fb-008d-9318-2184285b46a8@kondratyev.su>
Date: Mon, 27 Jun 2022 19:58:14 +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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Content-Language: en-US
To: Ivan Quitschal ,
 "freebsd-current@freebsd.org" 
References: 
From: Vladimir Kondratyev 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4LWv8p0tvRz4rYr
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of vladimir@kondratyev.su has no SPF policy when checking 195.170.219.3) smtp.mailfrom=vladimir@kondratyev.su
X-Spamd-Result: default: False [-1.76 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 RCVD_COUNT_FIVE(0.00)[6];
	 ARC_NA(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.76)[-0.760];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[kondratyev.su];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 RCPT_COUNT_TWO(0.00)[2];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[hotmail.com,freebsd.org];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:8299, ipnet:195.170.192.0/19, country:RU];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 27.06.2022 18:19, Ivan Quitschal wrote:
> Hi all
>=20
> Not sure if I found a problem here but here we go.
>=20
> Since I have a KVM usb switch here for keyboard/mouse sometimes I toggl=
e it=20
> between my windows and freebsd.
>=20
> I am using iichid here to have my multimedia keys working on keyboard a=
nd all
>=20
> hw.usb.usbhid.enable=3D"1"
>=20
> Im also using Wulf=E2=80=99s moused
>=20
> https://github.com/wulf7/moused 
>=20
> so far so good. Problem is:
>=20
> when I switch to windows , everything is detached correctly (hms, hkbd =
etc), but=20
> when I switch back, sometimes
>=20
> the keyboard and mouse are wrongly attached to =E2=80=9Cums=E2=80=9D de=
vice , not hms.=20
> (sometimes it goes to the correct one).
>=20
> Shouldn=E2=80=99t ums/uhid modules be deactivated once hw.usb.usbhid.en=
able is set to 1 ?
>=20
> The workaround I did here was to manually kldunload both uhid.ko and um=
s.ko=20
> within rc.local during boot.
>=20
> This way I can detache attach the kbd/mouse back as much as I want and =
it always=20
> end up in hms/hkbd devices
>=20
> Is this how its supposed to function? Randomly choosing between ums or =
hms?
>=20
> Thanks
>=20
> --tzk

It seems that usbhid's bus probe priority must be increased from
BUS_PROBE_GENERIC + 1 to BUS_PROBE_DEFAULT + 1

Test this patch:

diff --git a/sys/dev/usb/input/usbhid.c b/sys/dev/usb/input/usbhid.c
index fe53f11b8f4..174e1c28ae9 100644
--- a/sys/dev/usb/input/usbhid.c
+++ b/sys/dev/usb/input/usbhid.c
@@ -802,7 +802,7 @@ usbhid_probe(device_t dev)
  	if (hid_test_quirk(&sc->sc_hw, HQ_HID_IGNORE))
  		return (ENXIO);

-	return (BUS_PROBE_GENERIC + 1);
+	return (BUS_PROBE_DEFAULT + 1);
  }

  static int



--=20
WBR
Vladimir Kondratyev

From nobody Mon Jun 27 17:48:10 2022
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 856ED8A5ADD
	for ; Mon, 27 Jun 2022 17:48:25 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2041.outbound.protection.outlook.com [40.92.97.41])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LWwF42Wt4z3GwT
	for ; Mon, 27 Jun 2022 17:48:24 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=kjmV5rquxFyKA/0x4sRbuXNaJdW47T3A2IUjcDshBtcrZreJ2qZ887uMz7GjPugiUmhr2Joh+1jMKWcu61q0bdMqN2wypmGuYfnBvL4JdlOvbBVIgVdHZ6O1/7F1UdkQlA8X3S7aLiz2h49L3TOFpFOn7WfPptDrovBrrdYLh6KExUZ5AElH4fnASAUFNaI4xg84u7YNI/Fc3RaHmpO03/Tonyp/7WQHAwT/42Jys++mPTXig3AYzw/3NV5jvh3YGVzVb7FzprTchzo2UodMpqRds9hAHf8kOQN9Xm807h/HC5tDu+1c3rvXTH5D9kcvmX+O40SArM8jSDW7KHr9gA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mjbHgB6Vr8l/6TVutuakKu+AkZKOmNgtwmySpwFz6bE=;
 b=TyaqDrk2XuIVOn6k04vCN/s6HaV2+lwzOPa7caCoNB1i9BCrJPgCCeHdHOIe4rm8izpHXXE/GAwnpN7pzqK6b7aLWgomIO1mpCKTvLrQmm9ek644E7ETbzibHl2ZKeqBisjAVAKt04Z/lC/oC0yHA5Yn48CYvKOoXCdLC857qlWO9c6/t72DZOAuH3tJ2ykNxlfWz6PNjlW+J85Amx7CTp6nksazXYQQoK1U+MqsYvRcn0Sf8xnmDfgP2w1T2uUOOdyCmkXg/56kp+NElcmR78RQRavqywWSfTP05X91o0NoqdJiyppw3W7WeOI2dR+efMc8hz5ikXih+3T84tjWIQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=mjbHgB6Vr8l/6TVutuakKu+AkZKOmNgtwmySpwFz6bE=;
 b=IspEkny/LrTr8Roepy7lIu8H/7urk5N3uk0OHI1qRgwSZBsYSAfXjCYwzXmjExRg4OlpyFNqyMPekOlZ/jW84i1rjTcOHOlfK4JxDDN6yr1SmMGOSN0rU7fuNhfztOW/G22UFfEOKiBPIngLrDyQig7GvqP55FqaM4PzxpaAeJpI/Tlb1kbd+XAlIvF67BGhld4BUphLGOu0h+ZM96MKVWPpsqqdbb6ifbTIndpyQMLtumNqbZLoxdLugQPNM8N+VgPNX79DEwygK7/hrfgL+yiDKZTynSFUygRWQ2OMiw6MoGbzHC8as1vvF0FofMEvudDt1WXtNiDm/1QVAYwyaQ==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CPYP284MB0068.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:77::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.15; Mon, 27 Jun
 2022 17:48:15 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%8]) with mapi id 15.20.5373.018; Mon, 27 Jun 2022
 17:48:15 +0000
Date: Mon, 27 Jun 2022 14:48:10 -0300 (-03)
From: Ivan Quitschal 
To: Vladimir Kondratyev 
cc: Ivan Quitschal , 
    "freebsd-current@freebsd.org" 
Subject: Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
In-Reply-To: <8674be8f-b4fb-008d-9318-2184285b46a8@kondratyev.su>
Message-ID:
 
References:  <8674be8f-b4fb-008d-9318-2184285b46a8@kondratyev.su>
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-TMN: [Pn0ZqckOPxsfw3ZodRRN3fbXXKdp15Kt]
X-ClientProxiedBy: CP6P284CA0103.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:1a8::9) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5952985c-0d57-4b22-d6f9-08da5865362f
X-MS-Exchange-SLBlob-MailProps:
	H+eYzHeSLUuGsiT63N+R5VojDbr3XZTYCrwIPTu0NihDkUDKZyHoDhh4Wa1mZ+JYhiuOjeCKatKpRsqHz6DVOENHOUKmVE2FED1dDcEoZX8vgCYyHYvpFUpQZap91IQhaCv64fsYXsd4ow57vAUAf0KC+C5iXBUjNb/aGIiyvAqS8u5cc3Ra4fOTwTcbc42yM5O+ek75LKLhHq73tLUTc4jAEQhFv6x6aHoZWQKMYQ6jCrF8RJgePxDGPsS/2t7OTzpuIBdLf6Emb7iV1XxYqslvJ4tK/ZHpn/J0bZxzEYtWyptEW4AlrzAkwgKLfeAweJwsJltNioF34lgEwCyA1kLFxgF9HMMUnGZ9huH7QlznM0Lw3e26Yteq9+XQ1ZyTiuGHxBofD3jwZScG3BgdPoDsC5QODOeOPBlVcjZi73LFtmHd9r1HuQtUxebO3CFPU6MkRrExprmXOt7LtC2tvIh2l1FUZ2QVcc2+hAlb6sWPCl7uHdVgNrhzUCB0XOVvPvWrU5fByCKGvm0EwxqBwLwgtwwWJ+GeUa1RVFj9FJwghwTgFIv5hC0PxSV7lnZXCzvzaqizj7pPwUW7CN88d6dp3bCKuoumkM5KYd09QzxMTjbnjS3jgvn+txxQDly5yw5lC2+YefvgU/Ib9iaHxPHctk04A5mLq3myOrpBCcx/7c34tSkknrRvHREPXczNeQzuCY9ejYzErAL3sh/8VRpdgHIfWjcWikLCLokVMpiCb6m2LWIWdw==
X-MS-TrafficTypeDiagnostic: CPYP284MB0068:EE_
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	GSfKXxqh5DQfw02CSKmyj9Tq/NY9HxFexwnFDDlTxkw1BRQh/s27INBbNMxJkY/Auh+ge0nvaeImlUMQyw5TzDzqyhjb0x+qjKzopNr8iAxrvztpAnSOU6QiP5DK/CIBwsHGK9UNPOvMPq2Anb7g283Xzw8PPTuGf7eZ83sZc1AWeYM0SmsgUf+Q0p7BVHIhzgMT/vsTpaFh/lE0cYxULupLFO8hDmBmGDEHetlyIAFrIEaliX0f8Nt57NQaahRTj9qKgpWtT9pDRThleOBI0tIQXgQSlI2oJrESTLHqmS5o6x0ztvvFrweLvh/ZyF4OYZthgNaX37n86NBOMefdOOfRZshDFuKw17m5/EEuiTGXh20gTDAj8+XRdqri9qqBHgHS2y934Fqbw/4xvYbWGLp1zDstw4aNAaP1Ez6Q6iJV0cQtZun+1nb5iTUhXM430qrzMGYen5GMkchAsa1KADhFKcutJ1j2c4vceDKEX2Sqs+e6U/MoLzjw3oqF+Z66k8bVxhP/iI6vIz/3sOOrOGSf1rcAh1IOJEbiOKRN8W3zPbeVGt9pRWpbbEOKiWDSfpbT0r1siXUqdAHuQ3tKkJhSN0vFz3O1zRvKvQ95ORF8oJ8r7aNVOC9KQcvfvGAE
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?6E4PxHBqNpZ+2m+JHrGUch6Kfk6dBBOW58W7hEt46A2i8sLhAWeMcUKewkdy?=
 =?us-ascii?Q?zaOgx0TynOifdbVA4VslF3EeSMOnlzw9L/YKqM8aCBmBOjUubjb2tl8swfvm?=
 =?us-ascii?Q?SCLZRFHZBK+VHmSGGEp0xrGzotS8WzqdTpzT1YiKdrXsTvjyLtPKmkb5V70b?=
 =?us-ascii?Q?EwhQgCUlmh0B1r2wnYJLB2DbEb+LF9fntvFfNa7CwZFeX88dQ9SbTyKQNdOV?=
 =?us-ascii?Q?WBHxRU0+mUMTII5uKNCbFcjEn28m49Ih8bCEwiwwX2ggejQMiDI9zrGQe15J?=
 =?us-ascii?Q?tzvIYe0SMjaxPwKzbVki+QNAQOakict+agb05e30G3T9CbfiU46+YHN8b/4P?=
 =?us-ascii?Q?PNJmlvpOJmJAisjkXizM5X4axGgdl6TpwV8O6rPonIsFkOjW6QeYW1i6SyGf?=
 =?us-ascii?Q?k7Ydd1nZ+Yw/zPs61dCpUHgQ/zY4hXP/SQGuBphhtH0oyJpOHMsTgVR88osG?=
 =?us-ascii?Q?U0bFOP1H7Fh/rzsua0ADiKwRja5zPhRpAk7jwAEhnrdF77RDVjZoKXQ644vB?=
 =?us-ascii?Q?3PqS2dVBdu/oRtbibaOr7y0TP7rdOmSb0cBYyOIrJov0KFRFuaMbINRalrLa?=
 =?us-ascii?Q?8jKh6csaiNd96/ZAuTDxfzgrbcQYnxbdjANLfrDQzFVTWHoi36bzeE3i8oa3?=
 =?us-ascii?Q?nHjD83cjGx5Auxai7iuifnZYrnQNjvY8SrI/Bv9mObXiyyfl4afzx7T924CM?=
 =?us-ascii?Q?3f/o1Ukn2+dMwxSiEt/MZvbrEqrvcj0J0plX83jmIsmjp04iewGl2YZSed5P?=
 =?us-ascii?Q?RTfFhnDwFVu4X8XWIS6OlBqeUEVpimAkWVq25ArNVJdfvadtHATW8cRVS1B0?=
 =?us-ascii?Q?czGTEpiuuHPHCo0jVJP3ZPvUIymoOyW5bEOl8abd8gLHo8n2xYcG2yKpFLOh?=
 =?us-ascii?Q?bdChzxO30dr8o9lObhipukQ0BtvnrFH/Ryksv/ZrFA8ufiko7m1hcDtfX/LB?=
 =?us-ascii?Q?1GGCT5t/oBZHqrPGFSfkT6ePVOHa82umghEG7vrCGAoyY3QWT9yNejWz1DJI?=
 =?us-ascii?Q?8MEyhAocu6JkC9fThFPybbzg9qblg+hOEacWhNDiZaNWpkV9hT2+5bgvLIgB?=
 =?us-ascii?Q?AcbPhhhd7lS+Vw6dB0YTpf3fEhfhAl4Q7JaKupWm3BXEZH7aXdLNazO+hw6f?=
 =?us-ascii?Q?L0mZNcVnx0S3nkmYzaz8/d0VaYAqy30moYpyqY2FQXvVXMElVbmt1zHHl9XL?=
 =?us-ascii?Q?ZAXt2b/m0Claawkp96JLKszCPWlTdAfpgrZbX90+lHWi+oLDfFK18uCyT3ZB?=
 =?us-ascii?Q?sjwkBXpVpg+jtW7gSj8MtEUXocrP+5jpgtlx3bAg1w=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 5952985c-0d57-4b22-d6f9-08da5865362f
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2022 17:48:15.4623
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPYP284MB0068
X-Rspamd-Queue-Id: 4LWwF42Wt4z3GwT
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b="IspEkny/";
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.41 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.98 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 FREEMAIL_FROM(0.00)[hotmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	 MIME_GOOD(-0.10)[text/plain];
	 RCVD_TLS_LAST(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 TO_DN_SOME(0.00)[];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[hotmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	 RCVD_IN_DNSWL_NONE(0.00)[40.92.97.41:from];
	 DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 NEURAL_HAM_SHORT(-0.98)[-0.976];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[hotmail.com];
	 ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	 FREEMAIL_CC(0.00)[hotmail.com,freebsd.org];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]
X-ThisMailContainsUnwantedMimeParts: N



On Mon, 27 Jun 2022, Vladimir Kondratyev wrote:
>
> It seems that usbhid's bus probe priority must be increased from
> BUS_PROBE_GENERIC + 1 to BUS_PROBE_DEFAULT + 1
>
> Test this patch:
>
> diff --git a/sys/dev/usb/input/usbhid.c b/sys/dev/usb/input/usbhid.c
> index fe53f11b8f4..174e1c28ae9 100644
> --- a/sys/dev/usb/input/usbhid.c
> +++ b/sys/dev/usb/input/usbhid.c
> @@ -802,7 +802,7 @@ usbhid_probe(device_t dev)
>  	if (hid_test_quirk(&sc->sc_hw, HQ_HID_IGNORE))
>  		return (ENXIO);
>
> -	return (BUS_PROBE_GENERIC + 1);
> +	return (BUS_PROBE_DEFAULT + 1);
>  }
>
>  static int
>
>
>
> -- 
> WBR
> Vladimir Kondratyev
>


Hi Vladimir,

Looks like the patch did the job. After 5 reboots with 3 detachs each , no 
problem occurred.

looks like its fixed now, in case it happens again ill send another email.

thank you / all

--tzk

PS: i removed all module_loads from loader.conf in order to perform the test

From nobody Tue Jun 28 06:59:15 2022
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 AB5F387F015
	for ; Tue, 28 Jun 2022 06:59:26 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2030.outbound.protection.outlook.com [40.92.97.30])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LXFnn2m8Yz4YTq
	for ; Tue, 28 Jun 2022 06:59:25 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=g7sWtL4q3Qp6V+3402uiIiSvfD7k46ykRBgu9qkGJZ3fFZYEGO01MoOTeUIOPCYD3gGOQNGngryyk4uC7LQol546azxo0Jf/ywDYeUQBGEJprK97OhuzUFWM0mcRA80LVRX8nnmA9pmHGiyPUtwViZkYWY/5l1xmd0CDwCpKD/eT/8Dz/qjvLwhvUoC5YQbn1PlaAVdcykMw2jk4ZcKcbhhJxTBxHUXoXrI5Y7ql1keUzF/fbdPJotQEKRcJCnHmQ48Cf/ZZqFFJwmwvThfxkHpe/VniEhc8WthbukoDQz2nbEZf6SxROYvr6bavGaVNPirt5aZavpnULMCAIn2Tgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=OrxbYzGc/IeuNDFrQfBk5ieKy65IQ7vFKHk5uSWN8v4=;
 b=dlhJt2HT3IMwDl10DFFSVqiOxkOqmJ/DSmJtlH2PaH80CRVFzVHqQU3wE/Fiqb22PtslfTg8F488FP5dRFgBwxcyuFzaJp5lHBo2JSSCmoidhdbLEO5wVsibE2FkOjjNtwYqx1FDazux47ldnIJjcTzrfA0fhXoksIg0GR18jXfaeNEpE5A7E5naw48mZOXnE9p7NwBhFkJkGwEpmA7S0kUruVFVEZQ+35ruxfdGWmKIcsdX1fK7XHtEUBc/fsMTWiI1DWdaSAk8kOmCQ+mc5J5lRcF8rBcViYHgBJZUyDrJR0VFj2oG+SPAc0VWGpWm6yIRmgFp5lTUbp8Fl9karQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OrxbYzGc/IeuNDFrQfBk5ieKy65IQ7vFKHk5uSWN8v4=;
 b=p8evS1qrlXuceGkbgJsQempI8Ug4SZIEDPcuYj8+CrGDHXTaJumyyOBCQL8MD057LP65fL/NrWtx/jwlfqCeD4xwXva8iBEeXeeicbyhIH/Or1YnSlYkC7Vt5SIHjpXVoXVHvFVMYlXEcJpEcitx1bTcyjk/ub88C+QtuxcHBng94mIkZO1+RfUTpqZRbcu+35lsvantJqjpMRe2nYXV/9M6e2jU5RBL8udSpSqrug1qx66PqCd+cf8uRLtUuqkx12CSq18I5C1nSq5SdUf91jTEMabvie8D7tsII5N1ZniM2sRkf2W3KkS7zKr19uba4w20cKkJzZsIpDWdv5wDJg==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by ROAP284MB0413.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:3e::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.16; Tue, 28 Jun
 2022 06:59:15 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%8]) with mapi id 15.20.5373.018; Tue, 28 Jun 2022
 06:59:15 +0000
From: Ivan Quitschal 
To: Vladimir Kondratyev 
CC: "freebsd-current@freebsd.org" 
Subject: RES: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Thread-Topic: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Thread-Index: AdiKNwIPD56grc49TwS+3NUAqhONSQAEBTkAAAG+cQAAG2bNYA==
Date: Tue, 28 Jun 2022 06:59:15 +0000
Message-ID:
 
References:
 
 <8674be8f-b4fb-008d-9318-2184285b46a8@kondratyev.su>
 
In-Reply-To:
 
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [aMgjuWPUnX/ockWBi/Ozc8QiS+qtHDta8inM+RjZyM2lSAS/O17szOClqXBqP3l2]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0c74dcd0-ad20-4500-c308-08da58d3b6dd
x-ms-traffictypediagnostic: ROAP284MB0413:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 yUGp/oF0hjevjAUaDUPDzXZznX4RTm8Ty2ga+GaD7hygGjDgNepp1TxEZXtTV/k41u8/7WJsuZN8F9z09Kg2btPichE7wgWw1Y2vlErpJocwcf/9W3Kd/zROzrYXZ+HJJv9p7JJpxHDhqiUHo+BcjvdFvatzO4ECv/Jbi/pD7lSnI4LEm0RudO3tNqJfALGC8N9R03Hxwhkf1de/v7ksjK0MWhu91iULS0ZXrluOWyis6sWo6cFCrXduZoHUPRPPAa1YWCglt7BgysPu/b0AsmBBpfbhlW3ntruLbA1eP/+ZS6+pNEMyLCWQlYIsZbh/rIu28aZlOXAVx6pB9RYhUKVJ6MakLuiIt2UhkirkaZFcuunc+B04uz1c9SQMch42Tp1dGY35Way62SbxqgLizOKdPX/T/aDBfOPdWduXE7ZvMxBnITv1XVOcoQd/48HKMy/oSDTusvG3lBgmK3RCYtUXb/MM9yyW6GBIaU9JWkId80HXj92/GRgtH29InF5JAfayhc1AsJy64czkn6/0ZSkobLD83X2qsUoAcEgUfZHOUEMG9te6I1Gx38/iV1md34ndP1ibIMspluInPbz2nh5RpNDowtUxP4N9vJU5amz1Emro3HxgSt25LsxKTnpN
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?G3e2Ra50kNlnN+eoA/TJG0uVElH1K8TccNThVA3bM7ZXxtd8ehGNL7XTRMb5?=
 =?us-ascii?Q?jQ0TG53mDzD3fmuMls2zsta+5OgvVdfHPJv272o2P3S3be5VS0191SOT5p/2?=
 =?us-ascii?Q?ryHxT8S+6hOUVO5ilJcr2nuT9SG3zt7R6mEEv9ueRtG3sjPf1SVjBZeP2HVe?=
 =?us-ascii?Q?1tQuG0aiJme2a4OqGxVxIYdzckSZMOkz7+p6GMubc8RrLpNr8dw4M3rWp07p?=
 =?us-ascii?Q?flA2JbEg4qRSHMt0LjsJ9d1ktyNELtkPFzrT5js5H0T6oL4VzMDO4lREbMRr?=
 =?us-ascii?Q?A7MjEg1kY7pYdG2BFloYWcyMIAxJ/CuzN6ZcRYbhJKT52V6E1/5FX8g/ObrF?=
 =?us-ascii?Q?aZVD73xC92UX1Y0enbFLdZzNeva5corumMGT2UEtptBlEKYDAXiW9fWHjjqu?=
 =?us-ascii?Q?15bLUJxIziptAxc80ouQcQcYemCTtMIVbfjOJwBfpe2zGmyxH4UB3gQL1DI1?=
 =?us-ascii?Q?Tl80fFVM8QkMDuuVHSzU9D5QOnkzIsBrQqwlQRQmLXoBjyzny+yK1pPwFpjx?=
 =?us-ascii?Q?r5rHudxRW5jEwJ6FgwijKjuj5HYgSLSdtLHLTbzB78Z3wOwdc86wKoLkjPdq?=
 =?us-ascii?Q?0idGUIE7xideXJer1P8XFP/5uK32z/FOCujune8gFIIhORCIJ2mqhkMSWLcy?=
 =?us-ascii?Q?qaIz1PaXYenDZvnDn/5xGx+GL3jbQvKcIWBwBBWhDDdcCd0cy5jJwryxqQcU?=
 =?us-ascii?Q?6i2Nw28/Wz7BHAeHmnPWXlH1xlpmCGgeXjZGU42KAjFsKeagZR/PcAKY/omH?=
 =?us-ascii?Q?/9gLYt5EkAST2m76sX8YiUYTwd2GjUG0gumOGvKtROCRoyhLfxXm0TVRsl8m?=
 =?us-ascii?Q?8WYCZeILNWgt4qmsvCTyEHd2PgJro8iE7Z6ImZfDla5+wkiUHQeRmMhHLfg4?=
 =?us-ascii?Q?hCSzZ5XVr6gaTzJAVlkqwqhiYdjLUXzuGCxIVxpa8LEhlIUB/3jXHFI+UJe4?=
 =?us-ascii?Q?cXGyYtzU91Fiae+yYdXDxUXPPpiipUGxs2d7B2yFgpl+0rq5uE2gN7r2hK6W?=
 =?us-ascii?Q?oN7lgukRg4MT5OHUrfkH4owLiJFgTi/PcXKB9q89n3SlUWyHPgJj+YHs/ydh?=
 =?us-ascii?Q?jbLEeS2Eh3iH8GHLZesdEAF7pkVAoIrLRoQnMR9svZyCe9DZPlLrObjMFsyy?=
 =?us-ascii?Q?J3Ut2s+3Ws9pjwopsZBbHCl3ZTX37vSqGovJWiZMfUQjRTD67lHMWD1/YKdr?=
 =?us-ascii?Q?l0bSG+EjfaarWYasU12Zjkk+we0ZfG2pHKVElgcmh+lsgxMROXMelTQDDBVT?=
 =?us-ascii?Q?odFZdxlMbX/I7MdJPIcMkIElwaIoIHLHeM58eJyyhIXy/9QcJDBwJsvpRkL8?=
 =?us-ascii?Q?oBUWrtsBWu3BcS2gC7oDkRc/?=
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
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 0c74dcd0-ad20-4500-c308-08da58d3b6dd
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2022 06:59:15.5520
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB0413
X-Rspamd-Queue-Id: 4LXFnn2m8Yz4YTq
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=p8evS1qr;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.30 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.99 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.992];
	 R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[hotmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	 MIME_GOOD(-0.10)[text/plain];
	 DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[hotmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[40.92.97.30:from];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[hotmail.com];
	 ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]
X-ThisMailContainsUnwantedMimeParts: N



On Mon, 27 Jun 2022, Vladimir Kondratyev wrote:
>
> It seems that usbhid's bus probe priority must be increased from=20
> BUS_PROBE_GENERIC + 1 to BUS_PROBE_DEFAULT + 1
>
> Test this patch:
>
> diff --git a/sys/dev/usb/input/usbhid.c b/sys/dev/usb/input/usbhid.c=20
> index fe53f11b8f4..174e1c28ae9 100644
> --- a/sys/dev/usb/input/usbhid.c
> +++ b/sys/dev/usb/input/usbhid.c
> @@ -802,7 +802,7 @@ usbhid_probe(device_t dev)
>  	if (hid_test_quirk(&sc->sc_hw, HQ_HID_IGNORE))
>  		return (ENXIO);
>
> -	return (BUS_PROBE_GENERIC + 1);
> +	return (BUS_PROBE_DEFAULT + 1);
>  }
>
>  static int
>
>
>
> --
> WBR
> Vladimir Kondratyev
>

Hi Vladimir / All,

Just a question in case you guys know how.=20
Problem is fixed , nothing about that, but after the keyboard is detached a=
nd reattached , I=20
always have to do another "kbdcontrol -r fast" myself for it to get back to=
 the speed I use.
I've tried to call this command from within devd.conf alongside moused, but=
 no success.
Any ideas ?

Thanks again for fixing the attach priority

Thanks

--tzk

From nobody Tue Jun 28 10:00:10 2022
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 6839D87A6D6
	for ; Tue, 28 Jun 2022 10:01:22 +0000 (UTC)
	(envelope-from vladimir@kondratyev.su)
Received: from corp.infotel.ru (corp.infotel.ru [195.170.219.3])
	by mx1.freebsd.org (Postfix) with ESMTP id 4LXKqj308zz3CKR
	for ; Tue, 28 Jun 2022 10:01:21 +0000 (UTC)
	(envelope-from vladimir@kondratyev.su)
Received: from corp (corp.infotel.ru [195.170.219.3])
	by corp.infotel.ru (Postfix) with ESMTP id 3957A360224
	for ; Tue, 28 Jun 2022 13:01:19 +0300 (MSK)
X-Virus-Scanned: amavisd-new at corp.infotel.ru
Received: from corp.infotel.ru ([195.170.219.3])
	by corp (corp.infotel.ru [195.170.219.3]) (amavisd-new, port 10024)
	with ESMTP id sd-tEzpO_3B1 for ;
	Tue, 28 Jun 2022 13:00:42 +0300 (MSK)
Received: from mail.cicgroup.ru (unknown [195.170.219.74])
	by corp.infotel.ru (Postfix) with ESMTP id 901DF35F8FD
	for ; Tue, 28 Jun 2022 13:00:42 +0300 (MSK)
Received: from mail.cicgroup.ru (localhost [127.0.0.1])
	by mail.cicgroup.ru (Postfix) with ESMTP id 568B842211F
	for ; Tue, 28 Jun 2022 13:00:41 +0300 (MSK)
Received: from mail.cicgroup.ru ([127.0.0.1])
	by mail.cicgroup.ru (mail.cicgroup.ru [127.0.0.1]) (amavisd-new, port 10024)
	with SMTP id 4g32ybQbk35A for ;
	Tue, 28 Jun 2022 13:00:38 +0300 (MSK)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by mail.cicgroup.ru (Postfix) with ESMTPA id D83B142211C
	for ; Tue, 28 Jun 2022 13:00:38 +0300 (MSK)
Message-ID: <468d9dad-bd67-f6c7-8b2a-e9e4fa738f64@kondratyev.su>
Date: Tue, 28 Jun 2022 13:00:10 +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/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: RES: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Content-Language: en-US
To: freebsd-current@freebsd.org
References: 
 <8674be8f-b4fb-008d-9318-2184285b46a8@kondratyev.su>
 
 
From: Vladimir Kondratyev 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LXKqj308zz3CKR
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of vladimir@kondratyev.su has no SPF policy when checking 195.170.219.3) smtp.mailfrom=vladimir@kondratyev.su
X-Spamd-Result: default: False [-1.35 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 RCVD_COUNT_FIVE(0.00)[6];
	 NEURAL_HAM_MEDIUM(-0.35)[-0.347];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 AUTH_NA(1.00)[];
	 RCPT_COUNT_ONE(0.00)[1];
	 DMARC_NA(0.00)[kondratyev.su];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 R_SPF_NA(0.00)[no SPF record];
	 RCVD_NO_TLS_LAST(0.10)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:8299, ipnet:195.170.192.0/19, country:RU];
	 MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 28.06.2022 09:59, Ivan Quitschal wrote:
> 

> Hi Vladimir / All,
> 
> Just a question in case you guys know how.
> Problem is fixed , nothing about that, but after the keyboard is detached and reattached , I
> always have to do another "kbdcontrol -r fast" myself for it to get back to the speed I use.
> I've tried to call this command from within devd.conf alongside moused, but no success.
> Any ideas ?
> 

May be DE overrides repeat rate for you?

Anyway, it is possible to change repeat rate through evdev interface.
Following snippet of code illustrates a way to do that:


#include 
#include 

#include 
#include 
#include 
#include 

void
usage(void)
{
	printf("usage: eviocresp /dev/input/event0\n");
}

int
main(int argc, char** argv)
{
	int fd = 0;
	int rep[2] = {0, 0};

	if (argc < 2) {
		usage();
		exit(0);
	}

	if ((fd = open(argv[1], O_RDWR)) < 0) {
		perror("unable to access file, exiting");
		exit(1);
	}

	/* get current auto-repeat args. */
	if (ioctl(fd, EVIOCGREP, rep)) {
		perror("unable to set delay and repeat rate for input devices");
		exit(1);
	}

	/* set auto-repeat rate as 0. */
	rep[1] = 0;

	if (ioctl(fd, EVIOCSREP, rep)) {
		perror("unable to set delay and repeat rate for input devices");
		exit(1);
	}

	printf("rep[0]:%d;rep[1]:%d\n", rep[0], rep[1]);
	close(fd);
}



-- 
WBR
Vladimir Kondratyev

From nobody Tue Jun 28 13:15:26 2022
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 9F14D870DCB
	for ; Tue, 28 Jun 2022 13:15:36 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2021.outbound.protection.outlook.com [40.92.96.21])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LXQ7q0Rz9z3tNH
	for ; Tue, 28 Jun 2022 13:15:35 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=S0YMJ21raThjYY4rv0RG5htik+fSSq3nF91wbBFCVxexRA1wOpLI/1IyDy3Um38I7xTKs0QzQBdH1k6zRQPz7nbKcmGssPcN6yA2MmiIlGKHBZl1WlaFvCEOJzHirxq8ETx4iVQXno+4nzes3+9Wir5cxJEG26HzZqfLO4srhPs66rWQAG80gl/9HrLOsNL7jCoAqjzi5MQv8Ucu4WYOYD2er5iXs8r7uhZGlmDGMHGlSmXGChVSGMlhk3da48XJRBlhNHVKo3vbAYWUQH+FRX0ofokcvcDoungzUGSSxKAqPFkGs7HjDi6wwPp7Az5qRmmsOhwF+h5yT3Q/y8mqyQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MeBEgBusXEMLICbNpsKRXowDH9xd1k196D7qZrVXGTg=;
 b=M7cVdNfMLF2XGuFQCrwDwhECtuhwQfs66nJV/pAyBlF2ZQBF752mgsDCTdDkk1960Ep9Ih6KqEl7huMqr/WI4gSGAUBq0uz2lJttGouT1euLtLv0TA46eQwdJRvJHMrEBg3zVPIN413u9rLNw72Xz4VEIKjRuVwE/Tm/MjY+tM1MMR1qLflY4HHCNckDuxkrQyoZ67DCuFSXVM0sGLRQTsMCh+oSlS+9CEVDso5eOpvDiTC05bC/oyAi7hhudqqE2vxzMCUrBoWNLbigibc2egeoIkGED8IcdTOmrSGrMb+UqThT3AnZXhcX6FCCyTFgt2Lv+ggJKJZNUN3Vh0gK6w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=MeBEgBusXEMLICbNpsKRXowDH9xd1k196D7qZrVXGTg=;
 b=Huu4KsmXTyW42MQGIGh4EFiKAF4znUUKF+e4tSaaTdcC/uB5KH/Nj96BDTiA+A9XhGHB8Y4Bf7KsNi++1jRYSTsHne8ujdJs3v+tJ6RqxjZsc7tfa2Kd1Bsd6sYy/0/i0Sk1EFh++PaDroljt1fss8D0Wmt/j/Rk3Mee2LrwCJtkUdNyij4C0vQB3FRmbt+5rnkay0Bm+iUCPlEc/m0/sMarOGaYFmoHLKhWTby/xkd6VoyDxfJgL6inZUTMPSTA/0C0oIqgKCSaILM0Y44eR5GeJy86tU+J+2UeJJPVdtlDc4NoFJqeIpq7tOKY83YYbgCiOXBiMgn3wgyzxDEl7Q==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CPYP284MB0563.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:66::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.16; Tue, 28 Jun
 2022 13:15:26 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%8]) with mapi id 15.20.5373.018; Tue, 28 Jun 2022
 13:15:26 +0000
From: Ivan Quitschal 
To: Vladimir Kondratyev ,
	"freebsd-current@freebsd.org" 
Subject: RES: RES: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Thread-Topic: RES: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
Thread-Index: AdiKNwIPD56grc49TwS+3NUAqhONSQAEBTkAAAG+cQAAG2bNYAAGi44AAAYwz1A=
Date: Tue, 28 Jun 2022 13:15:26 +0000
Message-ID:
 
References:
 
 <8674be8f-b4fb-008d-9318-2184285b46a8@kondratyev.su>
 
 
 <468d9dad-bd67-f6c7-8b2a-e9e4fa738f64@kondratyev.su>
In-Reply-To: <468d9dad-bd67-f6c7-8b2a-e9e4fa738f64@kondratyev.su>
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [yzPq6hk46EslwmvxiNBTMmKAykRfQyFrIJDXoElcrZXs2xVSMLe3zXQ2nR2swYFj]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ec09c6b8-309f-4890-68bf-08da5908443e
x-ms-traffictypediagnostic: CPYP284MB0563:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 tZ0yFX5HRwtm9A23yOdNOyBsdSjrl9AYg56uq6nWCCNf2OfkDp1Whz3XnVkYKEDmgv84StYsI3y7Y814szEhGif77DvrP7iwMcZm9uaUX34cKs0puvSA69NztmabcUEXBAZkVin7kEzmRuKbyaKfHTbAxZ2c76VK7gyyge0SKcQBKhOWc5bNC4JW4WNtCzmxHvjqs099lPqA08jnKRJxe1BbFk/Q677BfD2/NDUjpNKNyE7PJE7qfGY0ViuC96+kWhO4bPHsFE57I1qZ18rUyZJGfHvpiOVSys1htwhI5Cn70zX16RhSa/VTNGzYTwu3K2Nx7TnlacP8f0I/vJOKOmGL/rtu8xkyAasMptvmVgnWt+gc21itqUhv4PYr+abqdD9tSKbCAKEQucGh/6OYea6aX34nF4h06+L1FSLdLeIpgSGcj2MlbZsJEwzSWba3/VX5NbIQEKivtEegZUjGMQT964L9HY8h1kbbQxu2w1/yUk1qZfrvTD8o8IR3dw2rCIeA7hSa69rrnqRF7Saf8DUvLOFWW8v18G4KI36125Ipz1N6km6m2KGmgg2iXaxtxRa8/gaipr/ggSiRNKYZPbRjHhOhdeY/mgeSQb2QwNg1dGN+P43UQxSrRyrhta3tgiOMBkvMua5WDqqZyw0trw==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?WXE1eHlsQ0RjS203cW54SGRSWTdUVzZIaDdHZ0VleVQ4VWxlYmtTbTlHTXlO?=
 =?utf-8?B?NmEvWVlUUS84OUFmekFsN3JGdFI2ZG1xc0dwbnNYYXhlUk9ncGVUSVUwMGJ2?=
 =?utf-8?B?cm5adTliUlZONTFTSy9LUis3N1ozcjNwdjRVZi84MDVxUjFvaHZQTTRTVVpp?=
 =?utf-8?B?ZGQyRDN0K0lmSEpPN1Q0bHJpczJUZFVVM1d3b0F0ejM2MnE0RVRpL1JHR2Y5?=
 =?utf-8?B?K1dEdGVNTWMvUVBRWW5XZTlrQ3BDWlRMY1h3U25Xa3hyMGdhL05uV0ZBYWdo?=
 =?utf-8?B?blhEZmljZkJCRkVMMFhsRHlvMnVhbGtGYkNlTDBNaVpPd2F4bmZVZkYwOVpy?=
 =?utf-8?B?VjhheGxPVnVjcjR1YmxJSEZHRzU2NTliSTJaRkNUaytTZTVORVRQbVVnTm9L?=
 =?utf-8?B?aldudDd2YUoyQXdMZ0lqWjZPTmlTV1NXSEFRUVN5blNLVi9id25aV2dlcWxB?=
 =?utf-8?B?S1paWWxQYVhxbVUxWnVCSUorYmJheGRtUkJ1cGk4VC9ub2NTbThjcHNobjlt?=
 =?utf-8?B?YzFXeksrOUF1czBBT1hxZDBBMlYvZ0FLUmNMZ2JaVzhuSldHVWNBeGRUNjBJ?=
 =?utf-8?B?anJSdExoeWxxNDRZU3FmU2VFQmtSUURSOWNEd3dJblNHVlI4UmJCMG9oN0hu?=
 =?utf-8?B?czhHSHUzOHFXOGZPOGhZL2xiTnd4TENDRkxsbzNheCtyMzVLT2xSMWtlWURC?=
 =?utf-8?B?MC9aZlJsbGhtN0o1OTNWbTE0TFFJbXNST3hRSEVxWFNWWlpJc0dYcDhVNmZr?=
 =?utf-8?B?L0JRRk04R0xYazY3TXZuU2JxQy9hQzJUT2N0bGFWZE81SHhJb3VqTGhJa1Q3?=
 =?utf-8?B?bVVzUkxMb2ZLaklBNGJKWkRFWlBlN3VTdlFRS0N4M1pKMUVlZUNyT2pyRnVE?=
 =?utf-8?B?S2I2Nm82YjFpbUkvZHFISFpHa2c1anowSHF0TGU5bGFQaGwwOGc2S1BLMmIw?=
 =?utf-8?B?QTlWRFJNVGdFcXdBNlJ5VDljalYyRWo1SXVubTVyOU1LcjZPUWtrOGZOK25p?=
 =?utf-8?B?ZVpBQVdwSk5LOHorV1JmRWF1cEEwd1VERUM2RU5hL3NDSFF3SVcyL0hIRGZK?=
 =?utf-8?B?OXJmMnhMWVRGNWVJNUlKVlFNdzJVc3ZsK0JPTE9lNWFDN0IzTU1BTjdzdWta?=
 =?utf-8?B?cnIrTjZ2YjJzUDJHS0IwQnAwbE43aWQ2d0pjeTh0dGtLR1JHNDBNTW1YZlVn?=
 =?utf-8?B?dm00b3cvdi85WUF0Vlh3eUY1UG04ZUxVMW1mcEhPMURJTXRCTGhLNVJmVEY0?=
 =?utf-8?B?cVRTbzhYR3YrYVF3MVVKK0JrT3FzZ3hxVlVYMVFqNWVkeUU5SEtXampoRE9B?=
 =?utf-8?B?eFFhWDJ0N2xlUFppcWh0c3JwK2dMeURCQzkvNTZKMGFGT0o0ZVVJM0hzcm1Q?=
 =?utf-8?B?OWU5Q3hRdUtDY0wxSXNIaUFvRVpJT2VaSlZzakp2MjNtQ0plcCtOQkZiZFZN?=
 =?utf-8?B?RXZIdWpyU1g4MEZwVnZnZFdwWkd3aHUrQk9SRXhGN0c0bE9UclNXQkUwNXJt?=
 =?utf-8?B?U2N5MHUvMXBWTmxQOWVVZDR5OUcrdU13S25Yc2UrSlhHaCtRN2tWS3lqMzhX?=
 =?utf-8?B?VVJwbmFObFphQklEaVV0akwxd0VPbFViR1pDRDZLekljS2R5SUhlelJwRDN6?=
 =?utf-8?B?OHE4M2d4Rk4zNDFLaVFlWUhTNzRNTjY3MGg2MUEwbzJmN0lLSlgxb3pyNEk1?=
 =?utf-8?B?eUIxMkdnS3RvSmtWSnVqUHVYdFI3c1NCaWd3aHgxdnBFTmVDTGY5cHVVcHdX?=
 =?utf-8?Q?nf5Z6Pq3qjahyZlt3XWEDdRXHxgkJHHERiyj66T?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: ec09c6b8-309f-4890-68bf-08da5908443e
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2022 13:15:26.5741
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPYP284MB0563
X-Rspamd-Queue-Id: 4LXQ7q0Rz9z3tNH
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=Huu4KsmX;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.21 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-2.95 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 NEURAL_HAM_MEDIUM(-0.99)[-0.994];
	 R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	 FROM_HAS_DN(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[hotmail.com];
	 R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	 MIME_GOOD(-0.10)[text/plain];
	 DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_SPAM_SHORT(0.95)[0.949];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 DKIM_TRACE(0.00)[hotmail.com:+];
	 MIME_BASE64_TEXT(0.10)[];
	 RCPT_COUNT_TWO(0.00)[2];
	 RCVD_IN_DNSWL_NONE(0.00)[40.92.96.21:from];
	 DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[hotmail.com];
	 ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	 RCVD_TLS_LAST(0.00)[];
	 ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]
X-ThisMailContainsUnwantedMimeParts: N

PiBNYXkgYmUgREUgb3ZlcnJpZGVzIHJlcGVhdCByYXRlIGZvciB5b3U/DQo+IA0KPiBBbnl3YXks
IGl0IGlzIHBvc3NpYmxlIHRvIGNoYW5nZSByZXBlYXQgcmF0ZSB0aHJvdWdoIGV2ZGV2IGludGVy
ZmFjZS4NCj4gRm9sbG93aW5nIHNuaXBwZXQgb2YgY29kZSBpbGx1c3RyYXRlcyBhIHdheSB0byBk
byB0aGF0Og0KPiANCj4gDQo+ICNpbmNsdWRlIDxzeXMvaW9jdGwuaD4NCj4gI2luY2x1ZGUgPGRl
di9ldmRldi9pbnB1dC5oPg0KPiANCj4gI2luY2x1ZGUgPGZjbnRsLmg+DQo+ICNpbmNsdWRlIDxz
dGRpby5oPg0KPiAjaW5jbHVkZSA8c3RkbGliLmg+DQo+ICNpbmNsdWRlIDx1bmlzdGQuaD4NCj4g
DQo+IHZvaWQNCj4gdXNhZ2Uodm9pZCkNCj4gew0KPiAJcHJpbnRmKCJ1c2FnZTogZXZpb2NyZXNw
IC9kZXYvaW5wdXQvZXZlbnQwXG4iKTsgfQ0KPiANCj4gaW50DQo+IG1haW4oaW50IGFyZ2MsIGNo
YXIqKiBhcmd2KQ0KPiB7DQo+IAlpbnQgZmQgPSAwOw0KPiAJaW50IHJlcFsyXSA9IHswLCAwfTsN
Cj4gDQo+IAlpZiAoYXJnYyA8IDIpIHsNCj4gCQl1c2FnZSgpOw0KPiAJCWV4aXQoMCk7DQo+IAl9
DQo+IA0KPiAJaWYgKChmZCA9IG9wZW4oYXJndlsxXSwgT19SRFdSKSkgPCAwKSB7DQo+IAkJcGVy
cm9yKCJ1bmFibGUgdG8gYWNjZXNzIGZpbGUsIGV4aXRpbmciKTsNCj4gCQlleGl0KDEpOw0KPiAJ
fQ0KPiANCj4gCS8qIGdldCBjdXJyZW50IGF1dG8tcmVwZWF0IGFyZ3MuICovDQo+IAlpZiAoaW9j
dGwoZmQsIEVWSU9DR1JFUCwgcmVwKSkgew0KPiAJCXBlcnJvcigidW5hYmxlIHRvIHNldCBkZWxh
eSBhbmQgcmVwZWF0IHJhdGUgZm9yIGlucHV0IGRldmljZXMiKTsNCj4gCQlleGl0KDEpOw0KPiAJ
fQ0KPiANCj4gCS8qIHNldCBhdXRvLXJlcGVhdCByYXRlIGFzIDAuICovDQo+IAlyZXBbMV0gPSAw
Ow0KPiANCj4gCWlmIChpb2N0bChmZCwgRVZJT0NTUkVQLCByZXApKSB7DQo+IAkJcGVycm9yKCJ1
bmFibGUgdG8gc2V0IGRlbGF5IGFuZCByZXBlYXQgcmF0ZSBmb3IgaW5wdXQgZGV2aWNlcyIpOw0K
PiAJCWV4aXQoMSk7DQo+IAl9DQo+IA0KPiAJcHJpbnRmKCJyZXBbMF06JWQ7cmVwWzFdOiVkXG4i
LCByZXBbMF0sIHJlcFsxXSk7DQo+IAljbG9zZShmZCk7DQo+IH0NCj4gDQo+IA0KPiANCj4gLS0N
Cj4gV0JSDQo+IFZsYWRpbWlyIEtvbmRyYXR5ZXYNCg0KSGkgVmxhZGltaXIsDQoNCldvcmtlZCAs
IGkgdGhpbmsgaSB3aWxsIHRyeSB0byBpbXBsZW1lbnQgaXQgd2l0aGluIC91c3Ivc3JjL3N5cy9k
ZXYvdXNiL2lucHV0Lw0KYXMgc29vbiBhcyBJIGZpbmQgb3V0IHdoZXJlIGV4YWN0bHkgOiApDQoN
CmZvciBub3cgSSBtYWRlIHRoaXMgYW5kIGl0cyB3b3JraW5nIGdyZWF0IG5vdzoNCkkgY29tcGls
ZWQgeW91ciBjb2RlIGFuZCBjb3BpZWQgdG86IA0KL3Vzci9sb2NhbC9iaW4vZXZpb2NyZXNwDQoN
CkluIC9ldGMvZGV2ZC5jb25mIA0KDQpub3RpZnkgMTAwIHsNCiAgICBtYXRjaCAic3lzdGVtIiAi
REVWRlMiOw0KICAgIG1hdGNoICJzdWJzeXN0ZW0iICJDREVWIjsNCiAgICBtYXRjaCAidHlwZSIg
IkNSRUFURSI7DQogICAgbWF0Y2ggImNkZXYiICJpbnB1dC9ldmVudFswLTldKyI7DQoNCiAgICBh
Y3Rpb24gIi91c3IvbG9jYWwvc2Jpbi9tb3VzZWQgLW0gMj0zIC1wIC9kZXYvJGNkZXYgLUkgL3Zh
ci9ydW4vbW91c2VkLmBlY2hvICRjZGV2IHwgY3V0IC1jIDctYC5waWQiOw0KICAgIGFjdGlvbiAi
L3Vzci9sb2NhbC9iaW4vZXZpb2NyZXNwIC9kZXYvJGNkZXYiOw0KfTsNCg0KZGV0YWNoIDEwMCB7
DQogICAgZGV2aWNlLW5hbWUgImhtc1swLTldKyI7DQogICAgYWN0aW9uICIvYmluL3BraWxsIG1v
dXNlZCI7ICAgPC0tIHRoaXMgcGFydCBpcyBuZWVkIGZvciB0aGUgcmVhc29uIGV4cGxhaW5lZCBi
ZWxvdw0KfTsNCg0KQlVHOiANCkkgaGFkIHRvIHB1dCB0aGUgZm9sbG93aW5nIGluIHJjLmxvY2Fs
IHNpbmNlIHRoZSBmaXJzdCBtb3VzZWQgbG9hZGVkIGFsd2F5cyBoYXZlIHRoZSBjdXJzb3IgDQoi
c2hha2luZyIgaW4gdGhlIHNjcmVlbiwgZXZlbiB3aXRoIHRoZSBhY3R1YWwgbW91c2UgdG90YWxs
eSBzdG9wcGVkLiANCg0KcmMubG9jYWw6DQoNCnBraWxsIG1vdXNlZA0KZm9yIGZpbGUgaW4gL2Rl
di9pbnB1dC9ldmVudFswLTldKjsgZG8NCiAgICAgICAgL3Vzci9sb2NhbC9zYmluL21vdXNlZCAt
bSAyPTMgLXAgJGZpbGUgLUkgL3Zhci9ydW4vbW91c2VkLmBlY2hvICRmaWxlIHwgY3V0IC1jIDEy
LWAucGlkDQpEb25lDQoNCkkgZG9u4oCZdCBrbm93IHdoeSwgYnV0IG1vdXNlZCBvbmx5IGdldHMg
aXRzIGN1cnNvciBwb2ludGVyIG9uIHNjcmVlbiAibm90IHNoYWtpbmciIChJIG1lYW4gbm90IG1v
dmluZykgb24gdGhlIHNlY29uZCANCm1vdXNlZCBleGVjdXRpb24sIHlvdSBuZWVkIHRvIHBraWxs
IGFuZCBydW4gaXQgYWdhaW4gaW4gb3JkZXIgdG8gd29yayBwcm9wZXJseS4gTWF5YmUgaXQncyBn
ZXR0aW5nIGF0dGFjaGVkIHRvDQp0aGUgIHdyb25nIC9kZXYvZXZlbnQqIG9uIHRoZSBmaXJzdCBy
dW4uIE9uIHRoZSBmaXJzdCBydW4gLCBJIGFsd2F5cyBoYXZlIDQgbW91c2VkIHByb2Nlc3NlcyAs
IGFmdGVyIEkgcGtpbGwgYW5kIHJlLXJ1biBpdA0KSSBvbmx5IGdldCAyICh0aGF04oCZcyB3aGVu
IGl0IHdvcmtzIHByb3Blcmx5KQ0KDQpUaGF0IEknbSBwcmV0dHkgc3VyZSBpdOKAmXMgYSBidWcs
IHJpZ2h0Pw0KDQpXZWxsLCBub3cgSSBjYW4gYXR0YWNoIGFuZCBkZXRhY2ggdGhlIG1vdXNlIGFu
ZCBrZXlib2FyZCBhcyBtdWNoIGFzIEkgd2FudCBhbmQgZXZlcnl0aGluZyByZW1haW5zIHRoZSBz
YW1lIA0KVGhhbmsgeW91IGFnYWluIA0KDQotLXR6aw0KDQo=

From nobody Thu Jun 30 05:17:16 2022
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 27C6E8676B8
	for ; Thu, 30 Jun 2022 05:20:21 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LYRVX2mRGz4rWB
	for ; Thu, 30 Jun 2022 05:20:20 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: by mail-wr1-x431.google.com with SMTP id i1so20990353wrb.11
        for ; Wed, 29 Jun 2022 22:20:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=message-id:date:mime-version:user-agent:to:content-language:from
         :subject:content-transfer-encoding;
        bh=AoIMQyKxTM3NLs5GRlOS5ZU5Efgf0cGDWVUl4yumUJc=;
        b=iwxOy6TEJQ5+eZwynqhdIWvY8Il60dZL64zeQYd18VqmPnlAfv+ZF3QE/3qUMFNXIa
         Zl1W9FPRK9t0ezNqhjPki7w4PnGRTBfn6Xi7cESXHhmRfrohjGOE1YKAG2Fq8/rwsPjC
         G/wJGuo7Tc3t+M1mPy4yQUp9vFGOIn1jx2xxLnTp5gvizUKER0jY6uy+Chhhl8eSzxYJ
         298s/SWI6daY7aYczjNwixhfuccbz2a0yrR1ACVXM4QFFaKcRE4C9uaXMcUbZnoQoaiM
         KyL1GP/S9GSJMp+qXz8stYQ2JYvGrrSubVpXktQokTPYEQaZvlRtXpGI18rasimUX0nf
         jGZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:message-id:date:mime-version:user-agent:to
         :content-language:from:subject:content-transfer-encoding;
        bh=AoIMQyKxTM3NLs5GRlOS5ZU5Efgf0cGDWVUl4yumUJc=;
        b=HfBSkS7MLOYydD8EhbwdwzX5wq4fZqWSxK6k2OppcCu73IbVF/5vmbCwQREWsRFDgh
         JkFPvlUog8q9noNqdWtywA/Co93Y1Bc+Ca58e47EmSDOIQ8IBgR23HKnHG0zZzY6tC3b
         /Y/92kVvB7LrT6RkZU2YFmaZCDTrXz8rMc4/AGfd+/TRe2ZmeateL6svMwsj4i4Uaa+y
         xJ+fWhmesM+ZVjKt0yunfNQLungCVi90JvUGOZyyFoHZ4cDmIFBAX2Fv5bQBy3AX3haN
         NhGX+QWeXUY1urF5BT/jN/kfOBvbLtosYRxwE9q4JRG56GP1lskJqanuTqtiEJTZlxYa
         errg==
X-Gm-Message-State: AJIora/fNqIL62pB3uC1wV+Ljh43GU2oaC6/wMKludfyXM8DZ4XPRdlc
	UhO//85BkXEVpn480nKM2JFr/k68WRFtgBkg
X-Google-Smtp-Source: AGRyM1uHP3Q+FDR2nZNU7SIEBq2IuQhthT87xTVeS5z9kiTdAMj0VkCD8eQ8gF8mALoz4OELv74//Q==
X-Received: by 2002:a5d:6c63:0:b0:21d:2a53:c7a9 with SMTP id r3-20020a5d6c63000000b0021d2a53c7a9mr6402399wrz.34.1656566419190;
        Wed, 29 Jun 2022 22:20:19 -0700 (PDT)
Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2])
        by smtp.gmail.com with ESMTPSA id h4-20020a5d4304000000b0021b829d111csm18748388wrq.112.2022.06.29.22.20.18
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 29 Jun 2022 22:20:18 -0700 (PDT)
Message-ID: 
Date: Thu, 30 Jun 2022 06:17:16 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
To: FreeBSD-CURRENT 
Content-Language: en-GB
From: Graham Perrin 
Subject: usb_load="YES"
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LYRVX2mRGz4rWB
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=iwxOy6TE;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::431 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com
X-Spamd-Result: default: False [-2.03 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 RCVD_COUNT_THREE(0.00)[3];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FREEFALL_USER(0.00)[grahamperrin];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_SPAM_SHORT(0.97)[0.974];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

usb(4)



As an example: in what type of situation might it be desirable, or 
necessary, to load the driver as a module at boot time?


From nobody Thu Jun 30 05:38:56 2022
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 UTF8SMTP id CB87A86C44F
	for ; Thu, 30 Jun 2022 05:38:46 +0000 (UTC)
	(envelope-from freebsd-current@dino.sk)
Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72])
	(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 UTF8SMTPS id 4LYRvn4jTyz3CFd
	for ; Thu, 30 Jun 2022 05:38:45 +0000 (UTC)
	(envelope-from freebsd-current@dino.sk)
Received: from zeta.dino.sk ([84.245.95.254])
  (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384)
  by cm0.netlabit.sk with ESMTPSA
  id 0000000000681BDA.0000000062BD36DD.0000E010; Thu, 30 Jun 2022 07:38:37 +0200
Date: Thu, 30 Jun 2022 07:38:56 +0200
From: Milan Obuch 
To: freebsd-current@freebsd.org
Subject: Re: usb_load="YES"
Message-ID: <20220630073856.2025d972@zeta.dino.sk>
In-Reply-To: 
References: 
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.1)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4LYRvn4jTyz3CFd
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-current@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-current@dino.sk
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 DMARC_NA(0.00)[dino.sk];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 30 Jun 2022 06:17:16 +0100
Graham Perrin  wrote:

> usb(4)
>=20
> 
>=20
> As an example: in what type of situation might it be desirable, or=20
> necessary, to load the driver as a module at boot time?
>=20

=46rom my experience - when you have USB keyboard, it is necessary to
load both ohci/uhci/ehci and ukbd module for keyboard to be accessible
in loader. Server with some remote console capability like iLO (HP) or
iDRAC (DELL) use USB keyboard emulation for this.

Regards,
Milan

From nobody Thu Jun 30 05:50:43 2022
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 UTF8SMTP id 2651D86FA8E
	for ; Thu, 30 Jun 2022 05:50:27 +0000 (UTC)
	(envelope-from freebsd-current@dino.sk)
Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72])
	(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 UTF8SMTPS id 4LYS9G0L4zz3GTt
	for ; Thu, 30 Jun 2022 05:50:25 +0000 (UTC)
	(envelope-from freebsd-current@dino.sk)
Received: from zeta.dino.sk ([84.245.95.254])
  (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384)
  by cm0.netlabit.sk with ESMTPSA
  id 0000000000681BFF.0000000062BD39A0.0000E673; Thu, 30 Jun 2022 07:50:23 +0200
Date: Thu, 30 Jun 2022 07:50:43 +0200
From: Milan Obuch 
To: freebsd-current@freebsd.org
Subject: Re: usb_load="YES"
Message-ID: <20220630075043.156a06a8@zeta.dino.sk>
In-Reply-To: <20220630073856.2025d972@zeta.dino.sk>
References: 
	<20220630073856.2025d972@zeta.dino.sk>
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.1)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LYS9G0L4zz3GTt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-current@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-current@dino.sk
X-Spamd-Result: default: False [-3.30 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+mx];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_DN_NONE(0.00)[];
	 DMARC_NA(0.00)[dino.sk];
	 RCPT_COUNT_ONE(0.00)[1];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 30 Jun 2022 07:38:56 +0200
Milan Obuch  wrote:

> On Thu, 30 Jun 2022 06:17:16 +0100
> Graham Perrin  wrote:
> 
> > usb(4)
> > 
> > 
> > 
> > As an example: in what type of situation might it be desirable, or 
> > necessary, to load the driver as a module at boot time?
> >   
> 
> From my experience - when you have USB keyboard, it is necessary to
> load both ohci/uhci/ehci and ukbd module for keyboard to be accessible
> in loader. Server with some remote console capability like iLO (HP) or

Correction: in single user mode, loader should work without this

> iDRAC (DELL) use USB keyboard emulation for this.

Regards,
Milan

From nobody Fri Jul  1 09:35:18 2022
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 648BB87F634;
	Fri,  1 Jul 2022 09:35:21 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "gate2.funkthat.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LZ96J2nMHz3Gmr;
	Fri,  1 Jul 2022 09:35:20 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (localhost [127.0.0.1])
	by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 2619ZIBF016515
	(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Fri, 1 Jul 2022 02:35:18 -0700 (PDT)
	(envelope-from jmg@gold.funkthat.com)
Received: (from jmg@localhost)
	by gold.funkthat.com (8.15.2/8.15.2/Submit) id 2619ZITw016513;
	Fri, 1 Jul 2022 02:35:18 -0700 (PDT)
	(envelope-from jmg)
Date: Fri, 1 Jul 2022 02:35:18 -0700
From: John-Mark Gurney 
To: "Greg 'groggy' Lehey" 
Cc: freebsd-doc@FreeBSD.org, freebsd-current@FreeBSD.org,
        freebsd-questions@FreeBSD.org
Subject: Re: Posting Netiquette [ref: Threads "look definitely like"
 unreadable mess. Handbook project.]
Message-ID: <20220701093518.GD88842@funkthat.com>
Mail-Followup-To: Greg 'groggy' Lehey ,
	freebsd-doc@FreeBSD.org, freebsd-current@FreeBSD.org,
	freebsd-questions@FreeBSD.org
References: 
 <20220623030118.GA59423@eureka.lemis.com>
 <20220623060320.aad6a631.freebsd@edvax.de>
 <20220623063304.GB59423@eureka.lemis.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: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="kbCYTQG2MZjuOjyn"
Content-Disposition: inline
In-Reply-To: <20220623063304.GB59423@eureka.lemis.com>
X-Operating-System: FreeBSD 11.3-STABLE amd64
X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7  ED9B D5FF 5A51 C0AC 3D65
X-Files: The truth is out there
X-URL: https://www.funkthat.com/
X-Resume: https://www.funkthat.com/~jmg/resume.html
X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE
X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger?
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Fri, 01 Jul 2022 02:35:18 -0700 (PDT)
X-Rspamd-Queue-Id: 4LZ96J2nMHz3Gmr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 2001:470:800b::2) smtp.mailfrom=jmg@gold.funkthat.com
X-Spamd-Result: default: False [-3.67 / 15.00];
	 MID_RHS_MATCH_FROM(0.00)[];
	 ARC_NA(0.00)[];
	 FREEFALL_USER(0.00)[jmg];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 TO_DN_SOME(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 MIME_GOOD(-0.20)[multipart/signed,text/plain];
	 DMARC_NA(0.00)[funkthat.com];
	 AUTH_NA(1.00)[];
	 R_SPF_NA(0.00)[no SPF record];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-0.97)[-0.969];
	 NEURAL_HAM_SHORT(-0.80)[-0.797];
	 MLMMJ_DEST(0.00)[freebsd-doc,freebsd-current,freebsd-questions];
	 FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com];
	 SIGNED_PGP(-2.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+,1:+,2:~];
	 ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	 FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


--kbCYTQG2MZjuOjyn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greg 'groggy' Lehey wrote this message on Thu, Jun 23, 2022 at 16:33 +1000:
> Does anybody have an opinion on character set recommendations?  I
> think we should ask for UTF-8 if at all possible.

I don't think there's any need for a recommendation.  All [modern] MUA
should tag the post appropriately and each MUA be able to convert as
needed between them.

--=20
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

--kbCYTQG2MZjuOjyn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJivr/TXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MEI1RTRGMTNDNzYyMDZDNjEyMDBCNjAy
MDVGMEIzM0REMDA2QURBAAoJECBfCzPdAGrahvEP/3P9Hj1OXO9ihzwOiK+4CX7x
INcarfPqNr0d0G8P7LYAiXzMtRQwFxkmFGzd3Y3ckhKIQRLRRusTLgrQMmXdwkWO
FoGOJHkQl9lmRsFJtyAukboa/R5XU0mKTLYveB/utkwjg8kivRuqem8i/kNySPTM
4s0/kKpYfRJgYyhDutw4iwMoVj8RiYm7r0+hRlu0ZgYho19fWJB65lQlMD5rjId1
M5LXDkdoBTNaNDOnaDI0JeF9xj1PkcoVvRxsqM1ck+Ocju+okPX1m+ZYE0Lph3N+
6oCzFDtEdnoW4Uzk81VRretjQdQEN5XYYC07MzWPlrUfsDvVHzS6TGT44uytSzBA
jApobKnSr9mNQg4AdpFAMNh25R/GPvBDV04qDzYXs9Y9N4HnPjnUBtqp4n7FgVl5
fqT/EbNxk7HQKUZyo1tMF8dNOKg2w2BWAXt5di1m/v2f01HyT2LMAmhMU6YxMPKM
QBOszGLqE7mE9MXcopQ4b7o9JDJPp+2RYDc2E3KTewuTwIlOCexCa4H525vXZoaY
Z90G+w+WrxgJj+Z4HPBVOcw4RrxDF+4V21ThdMocEh85aRAX3bdQDnpu8k9oHCiY
PQFYa5DNTNCU+UtKSfBYB/HZXkxS32hw7yX/tqJ7y/J3pyxa/KEYXEzNfbKWQldX
cjtMlAuN9HocVMqgDbma
=VThE
-----END PGP SIGNATURE-----

--kbCYTQG2MZjuOjyn--

From nobody Sun Jul  3 08:39:46 2022
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 7E8B787E784
	for ; Sun,  3 Jul 2022 08:39:58 +0000 (UTC)
	(envelope-from yuri@aetern.org)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.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 4LbMnT3Z2Pz4jpn
	for ; Sun,  3 Jul 2022 08:39:57 +0000 (UTC)
	(envelope-from yuri@aetern.org)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
	by mailout.west.internal (Postfix) with ESMTP id 33CD432005D8
	for ; Sun,  3 Jul 2022 04:39:49 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
  by compute2.internal (MEProxy); Sun, 03 Jul 2022 04:39:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc
	:content-transfer-encoding:content-type:date:date:from:from
	:in-reply-to:message-id:mime-version:reply-to:sender:subject
	:subject:to:to; s=fm1; t=1656837588; x=1656923988; bh=uJC0Rfqxd5
	oY+VHHLdUlbKobEqjlM27PX+x1aVsXwmw=; b=GcWdmZxKj2x5YEj8OB7jeDJvDi
	oGf1jE0ilSFSKKABR6wGL+qskyQip+BcG4ZpZAx7dVAwA8grCKfOG5HEpSQIRIOF
	b8lcnVKG+vL664OmyqVS/mfHzEAAazhFmj29tFsUVRmQOn7nXSmRnL4ihnqRhntB
	W4MhGxuljC8w1HvqMphZYcnXHaTcCl2NS0+1XxaRumvNHMfOVcavEzse13b+pE9Z
	r9FeIVVD/Xs1mQw7INy5HLNw9QMJ4zoNfWrxsCjNvCEfpaerbzVGdOUSTP409oPc
	mTH/Wv3fPGpdCwVh+WOWmxgJAeRlI2Vb+ylcrtugZeS8fg+RVWgIXEwFqkTA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-transfer-encoding:content-type
	:date:date:feedback-id:feedback-id:from:from:in-reply-to
	:message-id:mime-version:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1656837588; x=1656923988; bh=uJC0Rfqxd5oY+VHHLdUlbKobEqjl
	M27PX+x1aVsXwmw=; b=noDfRWLjBP/ukwFVtENfUDWX6c3fkJhZs4khAhasET3u
	z9Bi2gR7NzwwrUStolZJBiXdnjBLAYisS+ygSIYgRq8V/3nToje42qMzVuqcU1aI
	jcfHb6IoG9T8yCtpaQdPQ2/SKRlTZ9nxw5S/JEj6kNUWh4r3c0i6Cq1ZZI7IJl3r
	NWacgrgifnw0dXysVTyFAvWjZzFjqPHnQ89HHTFaqvveU9JUcwVDQmqZ3GiSlBU9
	n6swx9aF3+T5bdPJmIFFAtAl1e9R66yDim3xi+z90s6WMySLmLGiXpRE88o5niup
	3Fii4ps8pWzDbG/gu/7TJoOVnS4y9Qdai/eLszwhDA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudehjedgtdekucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfvhffutgfgsehtjeertd
    dtfeejnecuhfhrohhmpegjuhhrihcuoeihuhhrihesrggvthgvrhhnrdhorhhgqeenucgg
    tffrrghtthgvrhhnpeffvefffefgteeuudekhfefvdfhjeetgfejffffieetvdfhfeejff
    ekleegjefftdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr
    ohhmpeihuhhrihesrggvthgvrhhnrdhorhhg
X-ME-Proxy: 
    
    
    
Feedback-ID: i0d79475b:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Sun, 3 Jul 2022 04:39:48 -0400 (EDT)
Message-ID: <262c9b6c-cfc9-090d-3cd9-2727e977fa3c@aetern.org>
Date: Sun, 3 Jul 2022 11:39:46 +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/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Content-Language: en-US
To: current@freebsd.org
From: Yuri 
Subject: emulated nvme on vmware workstation whines
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LbMnT3Z2Pz4jpn
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=aetern.org header.s=fm1 header.b=GcWdmZxK;
	dkim=pass header.d=messagingengine.com header.s=fm2 header.b=noDfRWLj;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 64.147.123.24 as permitted sender) smtp.mailfrom=yuri@aetern.org
X-Spamd-Result: default: False [-4.60 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[aetern.org:s=fm1,messagingengine.com:s=fm2];
	 FREEFALL_USER(0.00)[yuri];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 RCPT_COUNT_ONE(0.00)[1];
	 DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	 RCVD_COUNT_THREE(0.00)[4];
	 DMARC_NA(0.00)[aetern.org];
	 DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[current];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 RCVD_TLS_LAST(0.00)[];
	 ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from]
X-ThisMailContainsUnwantedMimeParts: N

I started seeing the following whines from emulated nvme on vmware
workstation some time ago, and it seems to happen almost exclusively
during the nightly periodic run:

Jul  3 03:01:47 titan kernel: nvme0: RECOVERY_START 48053105730250 vs
48051555254036
Jul  3 03:01:47 titan kernel: nvme0: timeout with nothing complete,
resetting
Jul  3 03:01:47 titan kernel: nvme0: Resetting controller due to a timeout.
Jul  3 03:01:47 titan kernel: nvme0: RECOVERY_WAITING
Jul  3 03:01:47 titan kernel: nvme0: resetting controller
Jul  3 03:01:47 titan kernel: nvme0: temperature threshold not supported
Jul  3 03:01:47 titan kernel: nvme0: resubmitting queued i/o
Jul  3 03:01:47 titan kernel: nvme0: READ sqid:10 cid:0 nsid:1
lba:8931648 len:8
Jul  3 03:01:47 titan kernel: nvme0: aborting outstanding i/o
Jul  3 03:02:23 titan kernel: nvme0: RECOVERY_START 48207341204759 vs
48207032791553
Jul  3 03:02:23 titan kernel: nvme0: RECOVERY_START 48207722834338 vs
48207032791553
Jul  3 03:02:23 titan kernel: nvme0: timeout with nothing complete,
resetting
Jul  3 03:02:23 titan kernel: nvme0: Resetting controller due to a timeout.
Jul  3 03:02:23 titan kernel: nvme0: RECOVERY_WAITING
Jul  3 03:02:23 titan kernel: nvme0: resetting controller
Jul  3 03:02:23 titan kernel: nvme0: temperature threshold not supported
Jul  3 03:02:23 titan kernel: nvme0: aborting outstanding i/o
Jul  3 03:02:23 titan kernel: nvme0: resubmitting queued i/o
Jul  3 03:02:23 titan kernel: nvme0: WRITE sqid:1 cid:0 nsid:1
lba:27806528 len:8
Jul  3 03:02:23 titan kernel: nvme0: aborting outstanding i/o

It does not seem to break anything, i.e. no errors from periodic, zpool
status and zpool scrub do not show any issues as well, so I'm just
wondering if there is some obvious reason for this.

I am staying current with, well, -CURRENT and VMware Workstation
versions (now at 16.2.3), and do not remember when exactly this started.
 There are no other VMs doing anything at that time, host system is
pretty idle as well.

From nobody Sun Jul  3 09:57:33 2022
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 DFAF38A95B3
	for ; Sun,  3 Jul 2022 09:58:11 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LbPWk5W5Yz4rSM
	for ; Sun,  3 Jul 2022 09:58:10 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by smtp6.goneo.de (Postfix) with ESMTPS id 9DA4710A330B
	for ; Sun,  3 Jul 2022 11:58:03 +0200 (CEST)
Received: from hub2.goneo.de (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPS id B156810A3308
	for ; Sun,  3 Jul 2022 11:58:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
	s=DKIM001; t=1656842281;
	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=nnfPPIgM56ydXTpLcH2k/OZ6xZHBJJ8mJt+NamzRW/o=;
	b=DHmB5nIQCYDLoN5jWakfBt1BjCG5FmMdSgp6w1NyPHz/IHH5L/+7k4rKLAGn6NAQHyAOi6
	LQnp/Vlx0AhaEg0KFlbk2Op0TTFtwRdnZPrXF+X/1L9ICL6o88L2QOfVvyQ4IUPaVEIezy
	JSoN/7ahRL6223mzdJaRIh2eNyfhU+IzD21yXAgiv05D9cI13Va1G2NYzZujIlpf/6G4Gm
	0GR5GGZwrvLl3KcFhNNb90VvoiNgSDYlwCM8DSKecoIfYIbv19vaIael4a/pJt67/IY2cO
	iJLn417CK+g4FrExuJPOWkeJqwOCO/RVCZC9fhNwatIG+r6zJneIfwHa600uGg==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-011-054-133.77.11.pool.telefonica.de [77.11.54.133])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPSA id 7C32F10A3306
	for ; Sun,  3 Jul 2022 11:58:01 +0200 (CEST)
Date: Sun, 3 Jul 2022 11:57:33 +0200
From: FreeBSD User 
To: FreeBSD CURRENT 
Subject: NFSv4: Invalid fstype: Invalid argument
Message-ID: <20220703115800.5e150d95@thor.intern.walstatt.dynvpn.de>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-UID: e980c4
X-Rspamd-UID: 69b4f7
X-Rspamd-Queue-Id: 4LbPWk5W5Yz4rSM
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=DHmB5nIQ;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.31) smtp.mailfrom=freebsd@walstatt-de.de
X-Spamd-Result: default: False [0.14 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
	 RECEIVED_SPAMHAUS_PBL(0.00)[77.11.54.133:received];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[walstatt-de.de];
	 RCPT_COUNT_ONE(0.00)[1];
	 HAS_ORG_HEADER(0.00)[];
	 RCVD_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_MEDIUM(-0.90)[-0.896];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[walstatt-de.de:+];
	 NEURAL_SPAM_LONG(0.43)[0.433];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE];
	 RCVD_TLS_ALL(0.00)[];
	 RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from]
X-ThisMailContainsUnwantedMimeParts: N

Hello folks,


Trying to mount a NFS filesystem offered by a FreeBSD 12.3-p5 (XigmaNAS) from a recent CURRENT
(FreeBSD 14.0-CURRENT #19 main-n256512-ef86876b846: Sat Jul  2 23:31:53 CEST 2022 amd64) via

:/etc # mount -t nfs -o vers=4 192.168.0.11:/mnt/NAS00/home /tmp/mnt

results in

mount_nfs: nmount: /tmp/mnt, Invalid fstype: Invalid argument

and checking whether I can mount NFSv3 (I have explicitely set NFSv4 only on the server side,
see below) via

:/etc # mount -t nfs -o vers=3,mntudp 192.168.0.11:/mnt/NAS00/home /tmp/mnt
[udp] 192.168.0.11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered
or
:/etc # mount -t nfs -o vers=3,mntudp [fd01:a37::11]:/mnt/NAS00/home /tmp/mnt
[udp6] fd01:a37::11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered

Womdering about the TCP conenction attempts, I checked the configurations on both, the CURRENT
and XigmaNAS (server) side.

[... server side ...]
nas01: ~# ps -waux|grep mountd
root       4332   0.0  0.0  11684  2652  -  Is   23:13      0:00.01 /usr/sbin/mountd -l -r -S
-R /etc/exports /etc/zfs/exports

rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  rpcbind
    100000    3   tcp    111  rpcbind
    100000    2   tcp    111  rpcbind
    100000    4   udp    111  rpcbind
    100000    3   udp    111  rpcbind
    100000    2   udp    111  rpcbind
    100000    4 local    111  rpcbind
    100000    3 local    111  rpcbind
    100000    2 local    111  rpcbind
    100024    1   udp    671  status
    100024    1   tcp    671  status
    100021    0   udp   1003  nlockmgr
    100021    0   tcp    603  nlockmgr
    100021    1   udp   1003  nlockmgr
    100021    1   tcp    603  nlockmgr
    100021    3   udp   1003  nlockmgr
    100021    3   tcp    603  nlockmgr
    100021    4   udp   1003  nlockmgr
    100021    4   tcp    603  nlockmgr

I do not see mountd nor nfsd being registered, hope this is all right within a NFSv4-only
environment.

Well, on the CURRENT server that provides without flaws NFSv4 for the CURRENT client I try to
access the XigmaNAS NFSv4 fs from, rpcinfo looks like:

(current server):
root@walhall:/usr/src # rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  rpcbind
    100000    3   tcp    111  rpcbind
    100000    2   tcp    111  rpcbind
    100000    4   udp    111  rpcbind
    100000    3   udp    111  rpcbind
    100000    2   udp    111  rpcbind
    100000    4 local    111  rpcbind
    100000    3 local    111  rpcbind
    100000    2 local    111  rpcbind
    100024    1   udp    774  status
    100024    1   tcp    774  status
    100021    0   udp    746  nlockmgr
    100021    0   tcp    661  nlockmgr
    100021    1   udp    746  nlockmgr
    100021    1   tcp    661  nlockmgr
    100021    3   udp    746  nlockmgr
    100021    3   tcp    661  nlockmgr
    100021    4   udp    746  nlockmgr
    100021    4   tcp    661  nlockmgr

Well, I also checked from client to current server and client to XigmaNAS server via rpcinfo
-p and I get always the very same result.

Checking the accessibility of the server host on the net via nmap gives this result (please be
aware we use a dual stack network and need both IPv6 and IPv4 access so this attempt shows
IPv4 access, but IPv6 access is also granted and assured):

UDP:
:/etc # nmap -sU 192.168.0.11
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:05 CEST
Nmap scan report for nas01.intern (192.168.0.11)
Host is up (0.00094s latency).
Not shown: 996 closed ports
PORT     STATE         SERVICE
111/udp  open          rpcbind
514/udp  open|filtered syslog
2049/udp open          nfs
5353/udp open          zeroconf

and TCP (since port 2049/NFSv4 is tcp):
:/etc # nmap -sS 192.168.0.11
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:34 CEST
Nmap scan report for nas01.intern (192.168.0.11)
Host is up (0.00074s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
111/tcp  open  rpcbind
443/tcp  open  https
2049/tcp open  nfs

I'm out of ideas here. What does 

mount_nfs: nmount: /tmp/mnt, Invalid fstype: Invalid argument

mean? Is it the server reporting that it doesn't serve the requested fstyp or is there an
issue with the local filesystem/mountpoint (located on UFS/FFS, the backend NFS fs are all
located on ZFS)?

I'm drifting like a dead man in the water here and I did not find aome answeres to the error
reported here in the net applicable to the problem seen.

Some hints are highly appreciated.

Tahnks in advance and kind regards,

oh





-- 
O. Hartmann

From nobody Sun Jul  3 10:58:55 2022
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 D5DA38B2585
	for ; Sun,  3 Jul 2022 10:59:33 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LbQtX55Ntz3GYJ
	for ; Sun,  3 Jul 2022 10:59:32 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by smtp5.goneo.de (Postfix) with ESMTPS id 275A410A1E8D
	for ; Sun,  3 Jul 2022 12:59:25 +0200 (CEST)
Received: from hub1.goneo.de (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by hub1.goneo.de (Postfix) with ESMTPS id 5691B10A1E87
	for ; Sun,  3 Jul 2022 12:59:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
	s=DKIM001; t=1656845963;
	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=b0nE/0aY7V32G2JZXUQmWJXP6l++NjXZzpIj9ZG9d5o=;
	b=gattDYV/45dY8A/WYUN10khr6tty6qOTu2ztadx7OSOoiFJjSAyGnIQGkk6WK7zLb69e2h
	OO96sHh9msEgbmhhjlmcc4iikTthl0z/w2D68LwV+kxbx1XLBoLiKtq7/NeBzSJKKeWjZI
	pdGbrJ/hX9TiSBi1TZAtxniQdyhPZJdvEF8lhN/pXAYcYCqBuXIZHmJaXpUk1rriFFAWq+
	/MQcFsRX4k7l3MyiBs5ZY8J/TIcGM/D7xA5cdVjYlBysiGZX859jymeKM7w1K2n+0FMocO
	C5c2HCGWq8Bp927RO5a+CXJZRGHyk8KsuuxpiqMuDSQzvexB0MmLftahEyQo/w==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-011-054-133.77.11.pool.telefonica.de [77.11.54.133])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by hub1.goneo.de (Postfix) with ESMTPSA id 2CF2710A32F4
	for ; Sun,  3 Jul 2022 12:59:23 +0200 (CEST)
Date: Sun, 3 Jul 2022 12:58:55 +0200
From: FreeBSD User 
To: FreeBSD CURRENT 
Subject: Re: NFSv4: Invalid fstype: Invalid argument
Message-ID: <20220703125922.2d9b2b34@thor.intern.walstatt.dynvpn.de>
In-Reply-To: <20220703115800.5e150d95@thor.intern.walstatt.dynvpn.de>
References: <20220703115800.5e150d95@thor.intern.walstatt.dynvpn.de>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-UID: 3db506
X-Rspamd-UID: 92eaef
X-Rspamd-Queue-Id: 4LbQtX55Ntz3GYJ
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b="gattDYV/";
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.60) smtp.mailfrom=freebsd@walstatt-de.de
X-Spamd-Result: default: False [-0.15 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
	 NEURAL_HAM_MEDIUM(-0.88)[-0.876];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_SPAM_SHORT(1.00)[0.999];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 DMARC_NA(0.00)[walstatt-de.de];
	 RCPT_COUNT_ONE(0.00)[1];
	 HAS_ORG_HEADER(0.00)[];
	 RCVD_COUNT_THREE(0.00)[4];
	 TO_DN_ALL(0.00)[];
	 DKIM_TRACE(0.00)[walstatt-de.de:+];
	 NEURAL_SPAM_LONG(0.02)[0.023];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[77.11.54.133:received]
X-ThisMailContainsUnwantedMimeParts: N

Am Sun, 3 Jul 2022 11:57:33 +0200
FreeBSD User  schrieb:

Sorry for the noise, the learning process is still in progress and I learned about the
until-now-not-fully-understood V4: entry in /etc/exports.

Thanks for reading and patience.

regards,

oh

> Hello folks,
> 
> 
> Trying to mount a NFS filesystem offered by a FreeBSD 12.3-p5 (XigmaNAS) from a recent
> CURRENT (FreeBSD 14.0-CURRENT #19 main-n256512-ef86876b846: Sat Jul  2 23:31:53 CEST 2022
> amd64) via
> 
> :/etc # mount -t nfs -o vers=4 192.168.0.11:/mnt/NAS00/home /tmp/mnt
> 
> results in
> 
> mount_nfs: nmount: /tmp/mnt, Invalid fstype: Invalid argument
> 
> and checking whether I can mount NFSv3 (I have explicitely set NFSv4 only on the server side,
> see below) via
> 
> :/etc # mount -t nfs -o vers=3,mntudp 192.168.0.11:/mnt/NAS00/home /tmp/mnt
> [udp] 192.168.0.11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered
> or
> :/etc # mount -t nfs -o vers=3,mntudp [fd01:a37::11]:/mnt/NAS00/home /tmp/mnt
> [udp6] fd01:a37::11:/mnt/NAS00/home: RPCPROG_NFS: RPC: Program not registered
> 
> Womdering about the TCP conenction attempts, I checked the configurations on both, the
> CURRENT and XigmaNAS (server) side.
> 
> [... server side ...]
> nas01: ~# ps -waux|grep mountd
> root       4332   0.0  0.0  11684  2652  -  Is   23:13      0:00.01 /usr/sbin/mountd -l -r -S
> -R /etc/exports /etc/zfs/exports
> 
> rpcinfo -p
>    program vers proto   port  service
>     100000    4   tcp    111  rpcbind
>     100000    3   tcp    111  rpcbind
>     100000    2   tcp    111  rpcbind
>     100000    4   udp    111  rpcbind
>     100000    3   udp    111  rpcbind
>     100000    2   udp    111  rpcbind
>     100000    4 local    111  rpcbind
>     100000    3 local    111  rpcbind
>     100000    2 local    111  rpcbind
>     100024    1   udp    671  status
>     100024    1   tcp    671  status
>     100021    0   udp   1003  nlockmgr
>     100021    0   tcp    603  nlockmgr
>     100021    1   udp   1003  nlockmgr
>     100021    1   tcp    603  nlockmgr
>     100021    3   udp   1003  nlockmgr
>     100021    3   tcp    603  nlockmgr
>     100021    4   udp   1003  nlockmgr
>     100021    4   tcp    603  nlockmgr
> 
> I do not see mountd nor nfsd being registered, hope this is all right within a NFSv4-only
> environment.
> 
> Well, on the CURRENT server that provides without flaws NFSv4 for the CURRENT client I try to
> access the XigmaNAS NFSv4 fs from, rpcinfo looks like:
> 
> (current server):
> root@walhall:/usr/src # rpcinfo -p
>    program vers proto   port  service
>     100000    4   tcp    111  rpcbind
>     100000    3   tcp    111  rpcbind
>     100000    2   tcp    111  rpcbind
>     100000    4   udp    111  rpcbind
>     100000    3   udp    111  rpcbind
>     100000    2   udp    111  rpcbind
>     100000    4 local    111  rpcbind
>     100000    3 local    111  rpcbind
>     100000    2 local    111  rpcbind
>     100024    1   udp    774  status
>     100024    1   tcp    774  status
>     100021    0   udp    746  nlockmgr
>     100021    0   tcp    661  nlockmgr
>     100021    1   udp    746  nlockmgr
>     100021    1   tcp    661  nlockmgr
>     100021    3   udp    746  nlockmgr
>     100021    3   tcp    661  nlockmgr
>     100021    4   udp    746  nlockmgr
>     100021    4   tcp    661  nlockmgr
> 
> Well, I also checked from client to current server and client to XigmaNAS server via rpcinfo
> -p and I get always the very same result.
> 
> Checking the accessibility of the server host on the net via nmap gives this result (please
> be aware we use a dual stack network and need both IPv6 and IPv4 access so this attempt shows
> IPv4 access, but IPv6 access is also granted and assured):
> 
> UDP:
> :/etc # nmap -sU 192.168.0.11
> Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:05 CEST
> Nmap scan report for nas01.intern (192.168.0.11)
> Host is up (0.00094s latency).
> Not shown: 996 closed ports
> PORT     STATE         SERVICE
> 111/udp  open          rpcbind
> 514/udp  open|filtered syslog
> 2049/udp open          nfs
> 5353/udp open          zeroconf
> 
> and TCP (since port 2049/NFSv4 is tcp):
> :/etc # nmap -sS 192.168.0.11
> Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-03 11:34 CEST
> Nmap scan report for nas01.intern (192.168.0.11)
> Host is up (0.00074s latency).
> Not shown: 996 closed ports
> PORT     STATE SERVICE
> 22/tcp   open  ssh
> 111/tcp  open  rpcbind
> 443/tcp  open  https
> 2049/tcp open  nfs
> 
> I'm out of ideas here. What does 
> 
> mount_nfs: nmount: /tmp/mnt, Invalid fstype: Invalid argument
> 
> mean? Is it the server reporting that it doesn't serve the requested fstyp or is there an
> issue with the local filesystem/mountpoint (located on UFS/FFS, the backend NFS fs are all
> located on ZFS)?
> 
> I'm drifting like a dead man in the water here and I did not find aome answeres to the error
> reported here in the net applicable to the problem seen.
> 
> Some hints are highly appreciated.
> 
> Tahnks in advance and kind regards,
> 
> oh
> 
> 
> 
> 
> 



-- 
O. Hartmann

From nobody Tue Jul  5 22:59:52 2022
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 48E951CFEA3B
	for ; Tue,  5 Jul 2022 23:00:02 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.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 4Lcymw2lG6z4bmb
	for ; Tue,  5 Jul 2022 23:00:00 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657061999; bh=lHGjhA2wLkIqadr0SggV6g5XLLMr0Z+wdQdOcNI9BrY=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=aN29icKCjWKNSCE0R7tVPFB7CU6KF/oW9d7sGiSDkQDq0S8fHtgi3RiEijCAFhbr53/OjuKE/uFpMeCaPg+YDqZ+NQXH85UY5OENs4didbTRBI5l/gz4e6f2YvCdVjwuQtQixnN0OoWVMv84ATsCBi1ZO/KP8RJ3V+wDEPdlQdE96Oh1wdrjNF6VDzLNF876ZXe4cwqHyHVDUWSzZa4vMZHuFcHDPxv9qwHIMpMsINpdGoZ868kAP2qXI9WWoM14vkEM0N4AekBRjOhN7QWa3zW0qWOFNCJU3JAYdBXjNKxcqEKq7uWeUdfCOor3SqIXlxxZidLzw592EVgsGzPNgg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657061999; bh=cqUL3fXft8/vE4blKBnRFLeCjRqi3FZv6YlLhQRzcCD=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=G0t6T/LEj7xumZfQiR0NzXsaCNUTOGfHEQGnwLporlQvZvUvJ+ELEKJY+xxeGerlHd3oO8XtMhua80Az8AGavzeBm75hs2cBHO8KFQ/RjwRjE+b28gm1BZxFXBodfNr3nGFDT4bbdvEbyORtT3XyNa02Vd41BrdPzcnNZi7c17fx7qK/z2kO9uDVM/0Bp7I0vNy5hkiRGnawT+LMCHe0+GwIgnXtPQPkSaCsx/wbDkWgQDjrR4cNIweLhI69Yqbs8m0RvhuPmJDpRsVR5yifRsaoZveuIXaRzY1XOBFCSX8V2jiS70jBtm6LOC2S2s7T6V8YUXnbhNnl2lGErL+aNA==
X-YMail-OSG: lSdJMvEVM1lKw925GOKFoRYjnm0z1MntdLsTbqE1tqTTK5oNGhOVQJZ5OXbFV2i
 GaHw8NeM136aEijhoaBza7HFAz8l5f3AFmx0B.Dr3DOHnLkzdGrzjt8_Eo.D592Ua0kwqafGa98d
 6CMG7JbBlG.gvzC4sUUG5CflHohW42EBcMhr789VNv80DzfUqNK16EQPvO8OMJ5OxaeFTj3Q0Efe
 d5HiQ3KaeWB5gMSbX_CG.vty5nYkvcRqGW1PH5IZ76ppfFWNfeaSRcp44HB.nXfE5676PXuT08v2
 1h5b21zbru8685T3UfWqOpgrsRUPOj.6Hxd0kxlFCX3Tn5UmMYij4PhavSnqtp8gIq.LAvf958c5
 H0w1ch6K3JZQTitjHNFyfNK5VW3w3S1hHAlU7S5FujQjUK_CkvwRDcWR3ettQuH8JHUi0RLRCu24
 AJqtRjK.t1FcZwJDC2uwF4pCUyv23Wq5WXlAW1UIKPv1s4AvhA3Yxb1uAdtpXsifPlOX9H8SzR1X
 2wcEoDSQaC0P9vm0LSfLxFpaYHeUT_CRVBmxm_mNRojZQW4_wMKMtktkvBdxPrSUwx1sLGW7ywto
 tuuB_7MMa9sBIaShU5Qpd4G1BBCLvWCRtM5I.BmHnqnIH2OuPjm2ceN6N4B1h0FJCKy0z4bsjrUG
 Inq5_NUwJA9UpbduiYfPM_wVq_Irrh6T4C2Igty4D8h1TJ4P46X6jLKXojUbT04FaSHZhkfGvgWR
 kCKbnd_0vV83Ksup_.739wFxy4moj2iPZ8x_fz46jejQ7XzGAbQ0.mQi5BbUxFHpC9syORkeJ7Y8
 9.6zh3ZmbarKATZJl91cPxoSuGroIW6aDOlfYaKwpgpbGSX.8Zrtwuo9eQY0fvTQvyiB0WkktH5b
 cTJmapqGMpZRSqGggOjdODfsX.mwDG2.bewEt7oShtkxT_G7Mt.4VTpAem8FbZ8Uj0VD.ZK9vU5v
 D2gl4GMn_kLnkH1ts6tLW3h1ukrkFgfq_izNiAOHHmTF4K_gOVe8ENKtz0AZ59bqBDY.gi34PJ5G
 vwJV5JGF6eurDukKM8Zy7Wk.eB1ncgkNWUxuX.ZIi_DS3kgRPszDij3_VShT3Db5x1T2qftMT25W
 RoVptnhcE7HvK9Xx6tb8gr1d5GziHBZzOwyQkwwm7miv7XQvqVOq56zxoDfMUuh_cm9KiHwpabjz
 TtamXzu7C3j2oipzkFZxJQ_claHd5pzEMUFVVZ1LMtRS63Or1eqqB7LwpEuVsgWthVsqeTXiimyt
 o8TfCQzV.cRM0TfA46Owx9FpAxrhiIeM9zz1fgStIjwncC858n1p2cEquPSIYVfY4ZEVpuE7LjrK
 rsn4i8WeWHGBq0ZR.JjSe8TDYZTM3UBvb25gP3MCCHmdiLyDejinhlhLM6Th9NKUHTWrKWsL1WVp
 cAzCs3AvZbUYNYts4Nh_6sjijGtLxvmt7HhPavvHdwxo60B7jPTTMCMT9UBHpav1WrshsNOPkVRI
 RlomqiSTdKfkzZ3dMumSD2QSoIP1p2R.7UgMVcCt25q15MNy2rvwmhMbHwRvLmxql6SgKhZOny8z
 f4k_21IBbs_8omFwOZRYNmDvr59nuo9oElEouSdaNuBwFGDuDmYCytaF_gHT6D.3xNf9TAeihluE
 77dBq0snEbUWPW.P9Ciado8yD53NowGYcqK2q4Uin.uDI6Z1u7w1ggIZ7A1p5CYQcqXNcsND5T_b
 BVQ8U1a7R4NuMzpT3qDSkvr5C3tUF3Xid3mIpmsH1Ke2jKvMlwu4rY8cYSKnqK3twsozKDkJ_FaS
 5k9TIovJttALDNJeP5oetamq1SsRyGou9ceQxBXw5fh5zpTkRCk4EUqlvMTepHTcpIJjJvqmkfmI
 HMr8qSsVKfuwsHTyFYt3g4if6flr2vwBrSUaPWwFJKN.nZbTbtzW_tVE4u6VCRE_Y4...3GTFirC
 YCx6Go9cxXAiBfCJ1hn4RdUBs78GzEXsnclV2VeXt.FQ03t8yo10n23cjNiUckZB_sWOgE4kjrnT
 TbbE.n818elce1lQCFG_V0ColqqvhQP9OMIfUB68cL1PooEOmWTTC2XOc7JV1jD3DMFVsna0fviU
 b9XURP1eMhQaRVXw4UVisFQfTcjZYm02I.sKfzLTQqPRHyGbbGty52Y0MzUMaQDAU20wwSpL3PIz
 bnYb4adHyo6YjQsB0OD4bNuy0lxGT2uyr_dkQOQ584sWKLFsYy4RHx3LOSfHx1416.1HagJ6HIhv
 oE3UduorWzpsA69.f9H4l9Y6RbjF5TtnH8vp4FcENGas3BBAtc9.vr62zf4potBncN6beWztl7Ev
 6fb6rhQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 Jul 2022 22:59:59 +0000
Received: by hermes--production-bf1-58957fb66f-dvwt8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7f5ea83d09f41389f45dce58d4883a25;
          Tue, 05 Jul 2022 22:59:55 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: I replicated "UFS2 superblock failed: fs->fs_csaddr (805328) !=
 cgdmin(fs, 0) (5048)" style failure via main 9aa02d5120a (June 30, via
 snapshot)
Message-Id: <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8@yahoo.com>
Date: Tue, 5 Jul 2022 15:59:52 -0700
To: bob prohaska ,
 "freebsd-arm@freebsd.org" ,
 "mckusick@freebsd.org" ,
 freebsd-current 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8.ref@yahoo.com>
X-Rspamd-Queue-Id: 4Lcymw2lG6z4bmb
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=aN29icKC;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.39 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 SUBJECT_HAS_EXCLAIM(0.00)[];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-0.89)[-0.889];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

I did a:

# dd =
if=3DFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.im=
g of=3D/dev/da0 bs=3D1m conv=3Dsync status=3Dprogress
  3113222144 bytes (3113 MB, 2969 MiB) transferred 13.064s, 238 MB/s
3072+0 records in
3072+0 records out

to an around 1 TiByte USB3 NVMe based drive:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
Samsung PSSD T7 Touch (0x04e8:0x4001)
ugen1.5:  at usbus1
umass0 on uhub4
umass0:  on =
usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:6:0: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REDACTED
da0: 400.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors)
da0: quirks=3D0x2

On booting via the media the growfs happened but at its end was:

. . .
 1947561600, 1948842048, 1950122496, 1951402944, 1952683392
UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) (5048)
UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) (5048)
Mounting local filesystems:.
. . .

Unfortunately,

Thu, 30 Jun 2022
	=E2=80=A2 git: 9aa02d5120ab - main - vmm: Fix snapshots for AMD =
CPUs John Baldwin

is from after:

Tue, 28 Jun 2022
	=E2=80=A2 git: 2049cc321815 - main - Correctly update fs_dsize =
in growfs(8) Kirk McKusick

so there still is some form of error in the growfs
activity.

At least there is now a known, specific way to produce the
problem

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


From nobody Wed Jul  6 01:19:16 2022
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 E319A1D12B60
	for ; Wed,  6 Jul 2022 01:19:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ld1sq3skTz3DdD
	for ; Wed,  6 Jul 2022 01:19:27 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657070360; bh=DKsTNeMxoBwjiGuDLquLjnX9Xqk2JVoOpCc2swYbMQY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=krnhcNftMm6HUcYfZxO+lH1Wtu339dDebMuu7SgCtAOg875oRMjqgJYLLuRjtTJvmYAMkPvrKQ3fyqdcfwTzAqH+DW5g2wgmtUyIW2WLT/5jFA4gDph+P6sOp4+oJGpqrQQDtZzQ0Th4bXpoXp2OBK7xaDhNkOeNOsrV8fA+e0NyYElI2vj70da2mJtWxo1ki6oqyY6JWrGHCKzNJ3oc358BTVmncofpfOY3AtDm0+4TavzEiv1Nca9gYOaLvyZrbuYoziU2QSFhROYYnKDveCwYYVdZgceOIDXebeFCswt4anUkpbjuLZ7QarlAPSkhYksJU8SYfghEoXnxc/kEEg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657070360; bh=vQ+PvQTdb1yvK9G+35AuCZdVzCXBrjmCVh7vu0asvkh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZaK4mPgDCOK9vNDqJgMu6L5u5znXRLkIVcW3+0ukUHcAm5h20IQP+d4mc5cvyX3rRB/aUD9R4sedjlXqDLlC/XvOk0XgxJpT7Ejn4LUzcBSzyAl8JrXOAK0FYPOQntFwhSu0lUIHKUVuJot8Kyq0MS9zkoXg7kMVED4Tpa4rsAvGzIivy1+M6MakoQ7ts2QEfzTtqIKdn+7cDx/Zgn5bjnGKMYl7+bAUQg7mPTl+uAV9VC2UUnt8o6mdF+KiRIti0qH9fup+xEWck/VMIKHYxX/v/mJQqrQXK/tUBJjggfMkNEZmbuBQbs87i1E4X8v0QcOM4XuYHRerxGwiTDsFMA==
X-YMail-OSG: Ba8qBysVM1nGa9PvxNssFJ0C8zv0qDzG2jABOgpTI0nveVkNTkdpfH3sFKk0qo6
 t4.CFOBtw8j.PKiBnlSSDNKZMMI3ZSDCzcKFvA6WLK7LXQDZKAP3yMsBdZbE5mN51hcQkLhgr3_8
 G3oni5Jqe7VunGznghx9x.rt4fPO51RN_m1LEVaEHglhMIwABAWM11tBHl0onc3ku26IkV0nY_wq
 U1Qebs6SnykFyyqjInUFKSHIM_C0l4ZQ4ra8KpCyfQgbrOFmSJNXfXiy9xRAZssbpse92KxR28oz
 .vJ4UtlID0RbGrevvuZeiSxK5eD6FQ5YvE2ZBGiRDxBkdvuQ280tefp32vW0Eyun5Ah0..uegxor
 l0uiy6bYaeRwzUq3lb3.GsqjQoH0qUt7okjvfzthXAmAmDb4HnIi7yJGgA.eFNr2mEqsTrHD1oVx
 8RZUe3oUxFSTRzkm0v60xffcy6.WviKYoOZ8xA3P3XoKbrc9X2lzrx0vFqaqNe97BppLGUunVn.3
 LHmEQvE9NY3tlDQNOe7m3WJ1x1NATXeHog_QhpLheO.7f98Z6vF334TQvkkLK5vjkoGZHcPszYzu
 j.gdXk5eMZFPEFGn4R8EPXpf6q9zHg8cSsZsa16VgANPWcLbi_2UKnbM6EnqhSMAhh1Nm.WIpbvh
 wE8kGncDY2kqP43_97.iPJ8DgQStOADT9lguSZk5XRId_Q..lHE9JMqTJE9wR2nIFDh6vQI05Tza
 PY0_8u8MoQ7t21adTPM.1f5aOs3zxSG.A1jmgsyKOVcOrAfUecTZ_5A.bVwFw6_0stSQ2sqfCVa3
 QQ5Je0zAcLB.CVdIBMz1dpCUdep_KTPnqkDV4.r8e7WUTpObTmTW.5tzHBEIBgwxDsf79AMLAlc2
 FnXPeTOE43pGjy93WvUlzzicyVb_E2vaM25Z7.4kSwrwCGvVk78lbhBMI1c.4asXTJiC.2pvHhEF
 ReKkyX8YGt2vQgp0MN40bRfIv5TDCopSp_HihH9aBpiFPLnpAK5A6T_7SoGuzClz3G_hp_OaCNCp
 tU8wPssxgCUMgo2hh2L0GgFxaoQzqD8VHznoBZNujkyxJe8auF59KLt.xsW98jwyZcqx86fl6aQW
 j17HcNkeHf7J9AGKGjAFZoNasVrqSTNBKyaZRoBlde1QbUmFOYzI9zQeuwnoGlKhnHtribNbIAkD
 uLHnwDd9pSnchJhmmGTa5WrKRgFl3h4gihEB16tOfzN_EkF7lIvLt7m.jO95TU8ecXDWgEMFoCom
 NZME9X.n6gTBURTEMOqkAOhZD6S2JjrMvgVrYn53FUGJyAi90odOa6kxQ1e.ZeZgext0oYiSCc.J
 52bE6cmJtw3OWvsteGc2UOwMEZc8DOIM6lW5X4iwM9nKkzkwVqy0LPWQRxJFya2MJjgE2Ed.dYyf
 ATMhLu75Z9kMA3m7DW5pwZKy0ZvthyJvSiQM4136UBqKU8nHiVmdD5baaLYMRUSUF2StUs54IKQi
 YfI4UuiSd83mTmXFg361z9sONfMNkCatxgV_tnCSvz4ZjrlCiNzlg1TjezjfXHfK8for8cq2hPcB
 NnwUaP6minbUGAKsTf4tz98KQ.MMhSuXtzaLd4xT6k1oFpOUJV9Hw0eUy4z1rCG2wFzhvaG4rD65
 qQG7grOXzpgRlXcsJmIeb1ftgSki_zXhyV8MRm9C_DL8jdoOUqueYAQ4fRwQp1Pyf71Ll44Ah.qO
 WfoYB4WAyzGtZ9EqvuKzlRKNwuGDVz3PFSKeiug8T0IHi6yuh2IPUXht4QpawzL61zVQ4xPVMXBK
 A.9aD2s5PSp_5VKwTftyyvQgBjxXHXycFmcyMb4IqSmaLIAeXh7_8QSsT4DnIQ93_CTnsW8CgxHE
 8bGHsVxE7gCb.MTPh4G3rUD8YKsbsW30j47QbPjPG1VmqMIRcBFI.nHBpeGfROtfSSHOMjWLBPJ_
 wHnMOKKX1ckylaeWhZWjRKrVfNsfVSWh.Krr38ZZtfnSCSX9s8dwXQDjyBi_rB4mGJfVuD0UQHGx
 EqdxrZdiyGWSDJFovD2LOqvo.5fBU2X7FcWrp46BprgOFnuJdZUxbCRBkqy5OpukegGs5a2NAwC7
 hT1mAM9yYXYkhu4Y5.zf1ihWnfFJJWAQtrHT_qExugeKEmJ2eLxUJWjTsyK7I1qL5rSwNi64esbl
 .weGtTclWq_nQKy2MKT2DX.lXgD5YVzyrrCc27x.lRtn3cD1Xu8CX5EMZmBMFjUSqjXqMJQIyMyB
 G6eVoeqRqaJMQRHdzxRsCceVWbHdbCXqrHYJ_NP6Dqq6eelJbUvY7kX7pF2JNoTnWmMRS6TBdB.d
 DYHvgllCv1gYh
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Jul 2022 01:19:20 +0000
Received: by hermes--production-gq1-56bb98dbc7-jzpzw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 12d949a1d99732ec86d2cb049a8fe351;
          Wed, 06 Jul 2022 01:19:17 +0000 (UTC)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: I replicated "UFS2 superblock failed: fs->fs_csaddr (805328) !=
 cgdmin(fs, 0) (5048)" style failure via main 9aa02d5120a (June 30, via
 snapshot)
From: Mark Millard 
In-Reply-To: <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8@yahoo.com>
Date: Tue, 5 Jul 2022 18:19:16 -0700
Cc: bob prohaska ,
 "freebsd-arm@freebsd.org" ,
 freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: <562119CC-B142-493F-A7DF-F756A43F5358@yahoo.com>
References: <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8.ref@yahoo.com>
 <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8@yahoo.com>
To: "mckusick@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Ld1sq3skTz3DdD
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=krnhcNft;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 SUBJECT_HAS_EXCLAIM(0.00)[];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-5, at 15:59, Mark Millard  wrote:

> I did a:
>=20
> # dd =
if=3DFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.im=
g of=3D/dev/da0 bs=3D1m conv=3Dsync status=3Dprogress
>  3113222144 bytes (3113 MB, 2969 MiB) transferred 13.064s, 238 MB/s
> 3072+0 records in
> 3072+0 records out
>=20
> to an around 1 TiByte USB3 NVMe based drive:
>=20
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device Samsung PSSD T7 Touch (0x04e8:0x4001)
> ugen1.5:  at usbus1
> umass0 on uhub4
> umass0:  on =
usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:6:0: Attached to scbus6
> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number REDACTED
> da0: 400.000MB/s transfers
> da0: 953869MB (1953525168 512 byte sectors)
> da0: quirks=3D0x2
>=20
> On booting via the media the growfs happened but at its end was:
>=20
> . . .
> 1947561600, 1948842048, 1950122496, 1951402944, 1952683392
> UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) =
(5048)
> UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) =
(5048)
> Mounting local filesystems:.
> . . .
>=20
> Unfortunately,
>=20
> Thu, 30 Jun 2022
> 	=E2=80=A2 git: 9aa02d5120ab - main - vmm: Fix snapshots for AMD =
CPUs John Baldwin
>=20
> is from after:
>=20
> Tue, 28 Jun 2022
> 	=E2=80=A2 git: 2049cc321815 - main - Correctly update fs_dsize =
in growfs(8) Kirk McKusick
>=20
> so there still is some form of error in the growfs
> activity.
>=20
> At least there is now a known, specific way to produce the
> problem
>=20

I tried different, smaller media:

usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device =
OWC Envoy Pro mini (0x1e91:0xa2a5)
ugen1.5:  at usbus1
umass0 on uhub4
umass0:  on =
usbus1
umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
umass0:6:0: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REDACTED
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=3D0x2

I still got the problem.


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


From nobody Wed Jul  6 01:24:12 2022
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 6F3211D14075
	for ; Wed,  6 Jul 2022 01:24:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ld1zY1krWz3GFL
	for ; Wed,  6 Jul 2022 01:24:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657070658; bh=yP3FYcOH1jlQ4yDIuSfbj/vXLiMAF3Z1Rdyo7zJgDRs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZYnfo1mkzeQcKNjpiZ5Ne/hK0Br4hgPwB6FtJEVZo0UwwKrQwMFBxGorkxh0yMJB6kIpqprvsIIBEHAU6HmyZcbMuCe7ssb8TX8SCR1bF1cUJ69xVUlzV6iTo1d7L8Y9/v6id5zMk8SBolj+NjnH8CjlsdVgUR3SwMOZp0AGeT+z+BWBOoD/TMTLByFoZpImWXUvQ+VqcE+LuuZ+DncwoCfiyvUCHwHiIOUcRDwjoEUj2gDvfStlM871YqSlmoSwBRZq7IhRIM9XpoTs7JqJEWPtTUyY/Wz0TFSr0c6Qwr7MwkdRxwsC00HQ4IsLUZlwISWU5mb5q3fddmB0rztN9w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657070658; bh=cmUsYM0VB6WUVs/MorW7eNiM8jlKiGB5jaMf1gfmpci=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jpXOkUOoI+b5tHveaZpefH7fc7TWD16+UK2ovATfOXgKA0OyLjrkpqmcRQdmgmJkf1c21cHKzatueNm6JJLTVrUFx0nWnxFXBdw8DpUneehEbypyrKfiO6K4kxowKcm5Xx/yM9NtRxJ82EVbtY7L0NydRDM7O4YRPUhgOJ0HDl0pMwLpnLrHWEatIta6VfliJiwxqgY2q9OzlGorzd1WcB4NDlMFqtewbeARkFeK6JubjsPS2L518yxf9d8u+iX/Y9Sx0hLvnehcE6etpVVeza1mXVHn+R0CRfpNPkjZW53It4Ad+gVaX6r7aTH10Yn/Sri/jsvCKeMbjJMlSZtw0A==
X-YMail-OSG: 4S9eR20VM1mrgpygW8NmaQI5iMyHtwmOsIuAaWhjT2n9jpkYUOcDvjViEkZ0XLV
 Zpgp5U3kKClW_.NruBtUJYaa02l29rAPugAdLfDQ7ld_F6kADQr2vrzBohFQioBCMxOZxZWKeFwb
 veIPuIOxhHf1rco.neR1Gbef1kj0nrOBlLRaVTOZ8ggKK_XYFmlw8cWZg6yktEzlfgygRyj9_CHl
 uGXvUwSsjVvZYO8CUfma4XlSo6EhRXGpiMYW1ePre6S8GvBg6Rb81uz4krpLqLD6RdNpZHpekon2
 dp.LlJPfd1ouoiUUxIM7TEhtNTZ.BcDC5qnrloc9kJhkQvKWJMyekMRDHUCluLmFv5TvNx0UqbKM
 yhAh.RBQ9vlPJh0DOjoDyy5Sw1l.lX4uY937vqmFLZkcx3Glx4sokRNiCIwM1_K7HH9D3qPFHvDS
 u_6tXXbtU7SUDKs8dmKpwkO5pyaS4Z9JunRhZhGn1J_Y0N1HXVq5q4WcMB_AccLEgfHOHTIxknko
 sfgYwjYElZZyAHZwdKI4qfyQi_P7AH6cFf5CfI00TILSadEOo4Fj7os_M6y.Wil9vCWdaJSfy._0
 9pEP78.9a921EVLnmfHoCaQpjT4M.Vb_MawBsDk_QOoFVjUewTyHyEKarf0O07YPlgBP9pAu_.P5
 YeIDXme8apHDd.zCADhFI2w2JhCwmh9k2fIlMWOhR2Z3OkWTnGZgZvD7l91CEpWHj3KOZ234.SZk
 QG_aegFkUyLgp6H6YwH41MOz.5twuL8au60AsrLG4xb4c_5RLet7hEBtUcH1XDg5UJfyTNG1vwV5
 9rT2R24m.nw6uaVFXyX7eqxK1Ot9tx.ncuibOAmXmE.0871ge5w8E6ixTrLpjJQWDpxgUVUfX765
 kIn1yMxh3dqMhrMpCRbsMKEG2NqvwZBnQz32xw0Reva.oq3pIOogjgKkBZqtvafy2gzEe2ve3d_B
 3ZNEuZXm1FrTSbA.Cn6OPlwZIJHd0NNMyZdECWlet4WrFWmO6BUp1h5siTZyLzG5zKXZZvNJrZ9A
 3u6oTzCoQz2hNG.ECbjAj3Brnb9deJy1EKjo0ulopJsc25rTbDlHy1bvG9zGwkpiWrp18Yp72eZv
 axlxxI1iYcSTrdjcit9U.zue4XadKde_ezvngDiplA.pWQZL0kuyy5wkCbeXnqXx.zCNdxk_lvX.
 KX0F2Lr4xuzdDGPrbOb0X1V.Qb2fN7sLR_CSTn1Y431eBjvlZivep3qQhP.ugDJaFvMLCFiY5JcK
 JJBH6wTZJ2b3Wo7oCycX7YJljdT9Q9lU0qsPEapeutc88owoD4Zhu16ekJqRd7AJxQhPv.JS5lcp
 L_w9T38PxQ0R8Q7FyyYcP3XQQMUiRSUojBLdovHYS7leQyrpPOKmiv6gNwX22c26TZVJ9BJo9pVR
 iBAslLk.YKC.U5Nf18nHzCDe06jXqUrsj3FGF8qi9QetKxkdYKlc.If_rofBRW6xf3KVzXCe8YQm
 4_fkTMleh3axxDsWh23WBBnOyYI.T337sypy.IzVkCY_Z3dU5i43MCX6I7kGNa1h8Vj3t2YvP8XB
 JOdHxk2bQMRp.2FIwE9y.N28YNEWk5Sx_.Fbv20AyxGjZjFC0wPopWR.p3noT9BfhEZJfOsQXI3P
 VBRFomHj95UpGvFPOq5lYbBK4HN8LWkWa.stPNxnpjBUwt8Nff9Af.Ui4ynGsciAim.KxHPXr93E
 w3dLapVY08ByeIYEe_JM2M96UQLRRxv7CmKz4_rw62EvmlVddirSBLz8Jh9yXbqbWUqZ7FziqD0i
 kDKTXPVebg_GBYTU7rgQnQOan5XmxBxjoEjEVCRy8fFGUP3QSsGbOqW9tgqGxVgYQUa7rjSALCB3
 zHNOKIJRmzCo5c6ZTMSWVNE2sSzKbq6aXWUl.u.83gCATboZPLdhDed4LOU_gmT.0ayxzyGqTpdt
 _x0FBN4zI.3KtiKSNdjXprDfQzJoo8vbo18vNAdD67MisvrS3TgL8ZiyFnIy1JiDc
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 Jul 2022 01:24:18 +0000
Received: by hermes--production-gq1-56bb98dbc7-fn7k9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bd34fcce776c3ed5f64025b88287399b;
          Wed, 06 Jul 2022 01:24:13 +0000 (UTC)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: I replicated "UFS2 superblock failed: fs->fs_csaddr (805328) !=
 cgdmin(fs, 0) (5048)" style failure via main 9aa02d5120a (June 30, via
 snapshot)
From: Mark Millard 
In-Reply-To: <562119CC-B142-493F-A7DF-F756A43F5358@yahoo.com>
Date: Tue, 5 Jul 2022 18:24:12 -0700
Cc: bob prohaska ,
 "freebsd-arm@freebsd.org" ,
 freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8.ref@yahoo.com>
 <859EFD2F-61CD-4A9D-8798-78FEAC7AAEF8@yahoo.com>
 <562119CC-B142-493F-A7DF-F756A43F5358@yahoo.com>
To: "mckusick@freebsd.org" 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4Ld1zY1krWz3GFL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=ZYnfo1mk;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	 TO_DN_EQ_ADDR_SOME(0.00)[];
	 TO_DN_SOME(0.00)[];
	 FREEMAIL_FROM(0.00)[yahoo.com];
	 MV_CASE(0.50)[];
	 R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	 DKIM_TRACE(0.00)[yahoo.com:+];
	 SUBJECT_HAS_EXCLAIM(0.00)[];
	 DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 FROM_EQ_ENVFROM(0.00)[];
	 RCVD_TLS_LAST(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[yahoo.com];
	 ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	 MID_RHS_MATCH_FROM(0.00)[];
	 DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[4];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from];
	 RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Jul-5, at 18:19, Mark Millard  wrote:

> On 2022-Jul-5, at 15:59, Mark Millard  wrote:
>=20
>> I did a:
>>=20
>> # dd =
if=3DFreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.im=
g of=3D/dev/da0 bs=3D1m conv=3Dsync status=3Dprogress
>> 3113222144 bytes (3113 MB, 2969 MiB) transferred 13.064s, 238 MB/s
>> 3072+0 records in
>> 3072+0 records out
>>=20
>> to an around 1 TiByte USB3 NVMe based drive:
>>=20
>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device Samsung PSSD T7 Touch (0x04e8:0x4001)
>> ugen1.5:  at usbus1
>> umass0 on uhub4
>> umass0:  on =
usbus1
>> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
>> umass0:6:0: Attached to scbus6
>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
>> da0:  Fixed Direct Access SPC-4 SCSI device
>> da0: Serial Number REDACTED
>> da0: 400.000MB/s transfers
>> da0: 953869MB (1953525168 512 byte sectors)
>> da0: quirks=3D0x2
>>=20
>> On booting via the media the growfs happened but at its end was:
>>=20
>> . . .
>> 1947561600, 1948842048, 1950122496, 1951402944, 1952683392
>> UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) =
(5048)
>> UFS2 superblock failed: fs->fs_csaddr (805328) !=3D cgdmin(fs, 0) =
(5048)
>> Mounting local filesystems:.
>> . . .
>>=20
>> Unfortunately,
>>=20
>> Thu, 30 Jun 2022
>> 	=E2=80=A2 git: 9aa02d5120ab - main - vmm: Fix snapshots for AMD =
CPUs John Baldwin
>>=20
>> is from after:
>>=20
>> Tue, 28 Jun 2022
>> 	=E2=80=A2 git: 2049cc321815 - main - Correctly update fs_dsize =
in growfs(8) Kirk McKusick
>>=20
>> so there still is some form of error in the growfs
>> activity.
>>=20
>> At least there is now a known, specific way to produce the
>> problem
>>=20
>=20
> I tried different, smaller media:
>=20
> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage =
device OWC Envoy Pro mini (0x1e91:0xa2a5)
> ugen1.5:  at usbus1
> umass0 on uhub4
> umass0:  on =
usbus1
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:6:0: Attached to scbus6
> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number REDACTED
> da0: 400.000MB/s transfers
> da0: 228936MB (468862128 512 byte sectors)
> da0: quirks=3D0x2
>=20
> I still got the problem.
>=20

But the context was 13.1-RELEASE for this smaller media,
instead of main, so the context predates the growfs change
recently made in main [so: 14].

Thus, the details matter for if this newer failure was
expected or not. I do not know.

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


From nobody Wed Jul  6 08:07:57 2022
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 C35FA1CFCC39
	for ; Wed,  6 Jul 2022 08:08:10 +0000 (UTC)
	(envelope-from tdtemccna@gmail.com)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LdBxQ1lPpz4g1b
	for ; Wed,  6 Jul 2022 08:08:10 +0000 (UTC)
	(envelope-from tdtemccna@gmail.com)
Received: by mail-lj1-x229.google.com with SMTP id a11so17447539ljb.5
        for ; Wed, 06 Jul 2022 01:08:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to:cc;
        bh=qNJS8bXJjIJEOjJk4e4xeTOXLNTgbklFiRogoFnIe/0=;
        b=hxP2frQdKKnCFOp+cF5WIgFhcr7YgxHUOU2uZMLNW40yMcmOn33a2fDVMfr/sJDPou
         RPZFXfIOt9zXXhseKxB5ZWya/IyCGwwS9vcmC/bNlHzCP5+hErC9fQHctfvARXcmaSja
         juCCAudvYDrJ0GHYK1PqSbS8jfekJmahPmPCsdY11kmRqVf5SJUXz7rRx0+sNMaBuRVA
         HrQYlGFJpPWbGE/uIizRWC2WAe23ufYOBQDcjkbkYGC7q3f4xUuDLBKYDybXzrl4eqIk
         wP4+Rb7OyQ+UhcdphxXepkBhm4bwA9z3Yha6pilU7h+80mVXd0HGAWf++1k40LtUpTMa
         C1FQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc;
        bh=qNJS8bXJjIJEOjJk4e4xeTOXLNTgbklFiRogoFnIe/0=;
        b=dK+u7uFuU8KCNUbyHRI9mzdf0U3c0GC2X+AXrAiM8ymfMsxkxFV+2IvQ8MvexMMVE1
         vbRRmclNWrrBAz7+ou1ALexJwBcH5KvLEwBP/1NVNdSxUl+ld/yJ2HATA/T1UufzfL/0
         WcGtueFKY8lD5+jL8s7oFvzKOpn1dCbkk/p1dFQdeE0atuEy5tQwECj6mwGfZYGkI15F
         CsRDJM0V6L10KgKCbXUl2jshV0uwVyTXarLBikf7UIsX1poc1Xnd/tGjXi5T9FtiVCJ2
         q/5i6nrIBgJ1FgwOUgnE8jSbsdFOcIcqBmPxcFtF74c65l2YoRH3G0wJu9pHCg6LY1G3
         bWHg==
X-Gm-Message-State: AJIora9TwI6/ihrWQnxmcLiA/37MBJvLRbKpZK4XgENqR26rw6tswtBC
	DeVltle7k905wg+98hRT4jkN6p3CfuTOQRByfFsDkQUJ9m8Eqw==
X-Google-Smtp-Source: AGRyM1txZp87gvVHBb3y2isB+aob1hQsj4SpIzs6+2tJ9MUrP1Ub3ng7kSyL0I53j3CNj3l3ymY1d/lTjrmXm9neI6Q=
X-Received: by 2002:a2e:b8d6:0:b0:25a:99ce:5c32 with SMTP id
 s22-20020a2eb8d6000000b0025a99ce5c32mr21532576ljp.95.1657094888742; Wed, 06
 Jul 2022 01:08: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
From: Turritopsis Dohrnii Teo En Ming 
Date: Wed, 6 Jul 2022 16:07:57 +0800
Message-ID: 
Subject: FreeBSD is a great operating system!
To: freebsd-current@freebsd.org
Cc: ceo@teo-en-ming-corp.com
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4LdBxQ1lPpz4g1b
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=hxP2frQd;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of tdtemccna@gmail.com designates 2a00:1450:4864:20::229 as permitted sender) smtp.mailfrom=tdtemccna@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	 R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	 FREEMAIL_FROM(0.00)[gmail.com];
	 TO_DN_NONE(0.00)[];
	 MID_RHS_MATCH_FROMTLD(0.00)[];
	 DKIM_TRACE(0.00)[gmail.com:+];
	 RCPT_COUNT_TWO(0.00)[2];
	 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	 NEURAL_HAM_SHORT(-1.00)[-1.000];
	 SUBJECT_ENDS_EXCLAIM(0.00)[];
	 FROM_EQ_ENVFROM(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 FREEMAIL_ENVFROM(0.00)[gmail.com];
	 ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	 DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	 ARC_NA(0.00)[];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	 FROM_HAS_DN(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 MIME_GOOD(-0.10)[text/plain];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::229:from];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Subject: FreeBSD is a great operating system!

Good day from Singapore,

I think FreeBSD is a great operating system! I support FreeBSD because
the most popular pfSense firewall, the extremely popular OPNsense
firewall and the BSD Router Project are all powered by FreeBSD! macOS
is also based on FreeBSD!

I use pfSense community edition firewall in my home. I am planning to
try out OPNsense firewall next.

I will continue to support FreeBSD! It is a great operating system!
FreeBSD is a very good network operating system.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore
6 July 2022 Wed
Blogs:
https://tdtemcerts.blogspot.com
https://tdtemcerts.wordpress.com

From nobody Wed Jul  6 08:13:22 2022
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 AA9641CFE47E
	for ; Wed,  6 Jul 2022 08:13:39 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LdC3k5f4tz4hWD
	for ; Wed,  6 Jul 2022 08:13:38 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 5A9F0260337;
	Wed,  6 Jul 2022 10:13:29 +0200 (CEST)
Message-ID: <30f3012d-818b-d828-da02-554b19e01fab@selasky.org>
Date: Wed, 6 Jul 2022 10:13:22 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: FreeBSD is a great operating system!
Content-Language: en-US
To: Turritopsis Dohrnii Teo En Ming ,
 freebsd-current@freebsd.org
Cc: ceo@teo-en-ming-corp.com
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LdC3k5f4tz4hWD
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-2.94 / 15.00];
	 RCVD_VIA_SMTP_AUTH(0.00)[];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 RCPT_COUNT_THREE(0.00)[3];
	 TO_DN_SOME(0.00)[];
	 R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	 MIME_GOOD(-0.10)[text/plain];
	 DMARC_NA(0.00)[selasky.org];
	 NEURAL_HAM_LONG(-1.00)[-1.000];
	 NEURAL_HAM_MEDIUM(-0.64)[-0.643];
	 TO_MATCH_ENVRCPT_SOME(0.00)[];
	 NEURAL_HAM_SHORT(-1.00)[-0.999];
	 SUBJECT_ENDS_EXCLAIM(0.00)[];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 RECEIVED_SPAMHAUS_PBL(0.00)[178.232.223.95:received]
X-ThisMailContainsUnwantedMimeParts: N

On 7/6/22 10:07, Turritopsis Dohrnii Teo En Ming wrote:
> Subject: FreeBSD is a great operating system!
> 
> Good day from Singapore,
> 
> I think FreeBSD is a great operating system! I support FreeBSD because
> the most popular pfSense firewall, the extremely popular OPNsense
> firewall and the BSD Router Project are all powered by FreeBSD! macOS
> is also based on FreeBSD!
> 
> I use pfSense community edition firewall in my home. I am planning to
> try out OPNsense firewall next.
> 
> I will continue to support FreeBSD! It is a great operating system!
> FreeBSD is a very good network operating system.
> 
> Regards,
> 
> Mr. Turritopsis Dohrnii Teo En Ming
> Targeted Individual in Singapore
> 6 July 2022 Wed
> Blogs:
> https://tdtemcerts.blogspot.com
> https://tdtemcerts.wordpress.com

...

And its license is a killer!

--HPS


From nobody Thu Jul  7 05:05:56 2022
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 DAD4D1CFCE87
	for ; Thu,  7 Jul 2022 05:06:04 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ldkrq3tbJz3G3c
	for ; Thu,  7 Jul 2022 05:06:03 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 26755uAn078683
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Wed, 6 Jul 2022 22:05:56 -0700 (PDT)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 26755uTF078680
	for freebsd-current@freebsd.org; Wed, 6 Jul 2022 22:05:56 -0700 (PDT)
	(envelope-from sgk)
Date: Wed, 6 Jul 2022 22:05:56 -0700
From: Steve Kargl 
To: freebsd-current@freebsd.org
Subject: buildkernel is broken
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Rspamd-Queue-Id: 4Ldkrq3tbJz3G3c
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu
X-Spamd-Result: default: False [-2.97 / 15.00];
	 HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu];
	 ARC_NA(0.00)[];
	 MID_RHS_MATCH_FROM(0.00)[];
	 FROM_HAS_DN(0.00)[];
	 TO_MATCH_ENVRCPT_ALL(0.00)[];
	 NEURAL_HAM_LONG(-1.00)[-0.998];
	 MIME_GOOD(-0.10)[text/plain];
	 REPLYTO_ADDR_EQ_FROM(0.00)[];
	 PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	 RCPT_COUNT_ONE(0.00)[1];
	 TO_DN_NONE(0.00)[];
	 NEURAL_HAM_SHORT(-0.97)[-0.974];
	 NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	 MLMMJ_DEST(0.00)[freebsd-current];
	 R_SPF_NA(0.00)[no SPF record];
	 FROM_EQ_ENVFROM(0.00)[];
	 R_DKIM_NA(0.00)[];
	 MIME_TRACE(0.00)[0:+];
	 ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US];
	 RCVD_COUNT_TWO(0.00)[2];
	 RCVD_TLS_ALL(0.00)[];
	 DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]
X-ThisMailContainsUnwantedMimeParts: N

-std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_input.c
--- modules-all ---
/usr/src/sys/netpfil/ipfw/ip_dn_io.c:674:4: error: 'continue' statement not in loop statement
                        continue;
                        ^
1 error generated.
*** [ip_dn_io.o] Error code 1

make[4]: stopped in /usr/src/sys/modules/dummynet
1 error
*** [modules-all] Error code 6

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/SPEW
1 error

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/SPEW
        5.75 real        20.45 user         2.30 sys

make[1]: stopped in /usr/src


Please fix.

-- 
Steve

From nobody Thu Jul  7 12:24:47 2022
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 812DD10FA7FF
	for ; Thu,  7 Jul 2022 12:25:01 +0000 (UTC)
	(envelope-from rysto32@gmail.com)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LdwbJ4ntNz3cTR
	for ; Thu,  7 Jul 2022 12:25:00 +0000 (UTC)
	(envelope-from rysto32@gmail.com)
Received: by mail-ej1-x635.google.com with SMTP id r21so3327781eju.0
        for ; Thu, 07 Jul 2022 05:25:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=mkRja9PnHuegPsdEojSw40LmlV9fyG+rD6B/Kc6IYEE=;
        b=I9ruB1dk6WHI8RuMOFLGcoTYKZxOGB5y4U9JQX9pFXd9Ki2R15Be+VHA1fpszChckG
         c3ZgAobRPqPaNQr0meixGlp2GWKb4DxWDvPydY82PzV3MgWJ30p8b9cyAjMH8oAGXmHp
         OgUGbA41cvEd7d02SBo6AzzeCbHui92HfznNNI60xL0dmmzIYIctTxI7V6WIyjogctk8
         XrKFfYs9IIDmHmc8Trkrn0s+uRLAEahKidClGyQ58jT95Nl8ygaAEMs09XeX03Yadm5l
         mBnxmnq8WhtkrSu9h6f/kmqr1zj0xiDdVxHIRXPIwuL2UkNkouEvW2W3/1qsGYqNXZUI
         MOXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=mkRja9PnHuegPsdEojSw40LmlV9fyG+rD6B/Kc6IYEE=;
        b=EHucT9UEjb7zgXdrJJ0rqffAF4Gc/DpUsQnoBcAGBamxP1UwUAdSp1TIcUpLgCmPTu
         udOIzOnpLxvFDUeIqBQTMCm9AU8vi3zvU28sfNk3/EL5h9gjPIYBIY4p3e+xSbpa2dBz
         v6o/q4VH52a8EZVgDtJ0sn9mRPTQfKOJAxgaDo0fo6QSe2+8PGvQqanG0Q8PM6qD9xMe
         IPsXGOsDzju3htQTEE+JVUe3q7MZMfGDtxmbJkmpyMLYMBPN8MRycaUY2/Kw6uNTqIRv
         spk0ifu7eIeUR8+PW4fXBbnm3E11OWPHnKAEyU7eJNqzoLler0WSAvOxBYdJQ9QHg6Rn
         PQlA==
X-Gm-Message-State: AJIora/GiHfVXNvXVovvw6mW5ErYOK1bhm6PMU+K1fjcD7YCS4ODWobM
	AdCBm1yer1VtPwgJI2JMRVGDRHWvYADZvKqx4mzQCtV9xJw=
X-Google-Smtp-Source: AGRyM1tm4CFTLFqABjNu2IWgKcz+ZZUKu67WT3NJM0UL4I9ZwaQdEgAesAjOOPXcSjnLGDOVmFlHrl9l6mkMqALRsxE=
X-Received: by 2002:a17:907:9693:b0:726:372c:2c02 with SMTP id
 hd19-20020a170907969300b00726372c2c02mr45629828ejc.483.1657196699232; Thu, 07
 Jul 2022 05:24:59 -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: Ryan Stone 
Date: Thu, 7 Jul 2022 08:24:47 -0400
Message-ID: 
Subject: Re: buildkernel is broken
To: Steve Kargl 
Cc: FreeBSD Current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4LdwbJ4ntNz3cTR
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=I9ruB1dk;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2a00:1450:4864:20::635 as permitted sender) smtp.mailfrom=rysto32@gmail.com
X-Spamd-Result: default: False [-1.11 / 15.00];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	NEURAL_HAM_SHORT(-0.11)[-0.113];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::635:from];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

Do you have VNET disabled in your kernel config?  I believe that this
was fixed by 37f604b49d4a.

On Thu, Jul 7, 2022 at 1:07 AM Steve Kargl
 wrote:
>
> -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_input.c
> --- modules-all ---
> /usr/src/sys/netpfil/ipfw/ip_dn_io.c:674:4: error: 'continue' statement not in loop statement
>                         continue;
>                         ^
> 1 error generated.
> *** [ip_dn_io.o] Error code 1
>
> make[4]: stopped in /usr/src/sys/modules/dummynet
> 1 error
> *** [modules-all] Error code 6
>
> make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/SPEW
> 1 error
>
> make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/SPEW
>         5.75 real        20.45 user         2.30 sys
>
> make[1]: stopped in /usr/src
>
>
> Please fix.
>
> --
> Steve
>

From nobody Thu Jul  7 12:29:04 2022
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 AC8A110FBEA9;
	Thu,  7 Jul 2022 12:29:18 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::229])
	(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 4LdwhF31wjz3dxV;
	Thu,  7 Jul 2022 12:29:17 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Received: (Authenticated sender: andriy.gapon@uabsd.com)
	by mail.gandi.net (Postfix) with ESMTPSA id 70A05FF805;
	Thu,  7 Jul 2022 12:29:06 +0000 (UTC)
Message-ID: 
Date: Thu, 7 Jul 2022 15:29:04 +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/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.11.0
Content-Language: en-US
To: current@freebsd.org, virtualization@freebsd.org
From: Andriy Gapon 
Subject: problem with bhyve, ryzen 5800x, freebsd guest
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LdwhF31wjz3dxV
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 2001:4b98:dc4:8::229 is neither permitted nor denied by domain of avg@FreeBSD.org) smtp.mailfrom=avg@FreeBSD.org
X-Spamd-Result: default: False [-1.20 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::229:from];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[current,virtualization];
	ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR];
	RCVD_COUNT_TWO(0.00)[2];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	DMARC_NA(0.00)[freebsd.org];
	FREEFALL_USER(0.00)[avg];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


I have a strange issue with running an 'appliance' image based on 
FreeBSD 12 in bhyve on a machine with Ryzen 5800x processor.

The problem is that the guest would run for a while and then the host 
would suddenly reset itself.  It appears like a triple fault or 
something with similar consequences.

The time may be from a few dozens of minutes to many hours.

Just to be clear, no such thing occurs if I do not run the guest.
Also, I have an older AMD system (pre-Zen), the problem does not happen 
there.
A vanilla FreeBSD 12.3 installation that just sits idle also does not 
cause the problem.

Does anyone have an idea what the problem could be?
What workaround or diagnostics to try?
Anybody else seen something like this?

Since it's the host that resets it would be hard to capture any traces.
Thank you.
-- 
Andriy Gapon


https://standforukraine.com
https://razomforukraine.org

From nobody Thu Jul  7 12:51:53 2022
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 B524012ADB3B;
	Thu,  7 Jul 2022 12:51:57 +0000 (UTC)
	(envelope-from gusev.vitaliy@gmail.com)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LdxBN74zjz3rtV;
	Thu,  7 Jul 2022 12:51:56 +0000 (UTC)
	(envelope-from gusev.vitaliy@gmail.com)
Received: by mail-lj1-x22d.google.com with SMTP id w2so5771573ljj.7;
        Thu, 07 Jul 2022 05:51:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:subject:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to;
        bh=YOFCgAapD/0ugnZUHW100BRWWWMYqCGTCw/IIB5+Loc=;
        b=opxhYIsyE6IBC2IxT7bbcHauQtAwXZ1tE6gR128vi9491aylOUcokCEcWpM0g0Ic6Y
         CHX4423FqjKmEfoxZ0LPsaV2H5qdP1lqSpAeLzImiqUPsEuuyuDYOBrGPyZu1CKkzcIo
         Iu15rnkXYboeVnxuaDxNovlLEJ1fx62PTzj0KAgpw3x03UkRa6wBOyySTVTyexsL7WKW
         +jwGXTZVb/yt++VLVlKhkCPd2QbuSPYTmL6X34UGXrAJUExoePN88jG33sgx8ukPxbXH
         oErUF2tgx/g3KaNnXTIbaXCBFtcoOENI2JEPb/58FMoGUPoqZCdUpBJ4bBhMr/pbIscl
         3XpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to;
        bh=YOFCgAapD/0ugnZUHW100BRWWWMYqCGTCw/IIB5+Loc=;
        b=V2RfMAHY8bdycfJDsEFgDIMURdYD6oT/hh8Yn+usL94S4QsEMC8hqzq6OLV7G7RP2G
         sxK9w87E2/tvNkTRtgN7jVXWJyj/NbtEdmsUT13kvrDULVJ4U9yGSYlLYL2T+0k0P3xT
         GvwvQug2OYSgz4TVAniYPAq9qGq0VLg/1EkPTxrjUr7R2FmS5E+ceNeV4pbYF5+QGYEg
         j1P9Li5q2h4+v2ih4B+S6jkD17F517o/g+cj16ryfTEvwmy4hyt1VF5sXekVQrecD5sg
         jNlAocri8PsfNgZ90RA2Ry0TOmAF7Ac7u1kz4A+2PBB1qlXgKcrZhlLOyTp2SSeXYOiv
         C/Ww==
X-Gm-Message-State: AJIora8u2DoB4nvqruXBsVDaLSwoHjtgsVDZbtK56FpCKW9D/ULORVO1
	wQVUGL+Z9zNK+0I5l55t2U5QbkgtEVQ=
X-Google-Smtp-Source: AGRyM1t9qAbfbjhSvQ4I28ftKP10TAnXHX+zm3FZ49VNY3I7ddZvgJxXfiLy1GGMsFBiS3cH2//LbQ==
X-Received: by 2002:a2e:b8c7:0:b0:25d:30d3:2ad4 with SMTP id s7-20020a2eb8c7000000b0025d30d32ad4mr9054220ljp.317.1657198314927;
        Thu, 07 Jul 2022 05:51:54 -0700 (PDT)
Received: from [10.42.0.5] ([188.187.60.230])
        by smtp.gmail.com with ESMTPSA id p10-20020ac24eca000000b0048160c5e625sm3467388lfr.12.2022.07.07.05.51.53
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 07 Jul 2022 05:51:54 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: problem with bhyve, ryzen 5800x, freebsd guest
From: Vitaliy Gusev 
In-Reply-To: 
Date: Thu, 7 Jul 2022 15:51:53 +0300
Cc: current@freebsd.org,
 virtualization@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <78730F62-51D1-4FE0-A68D-ABE80DA38F85@gmail.com>
References: 
To: Andriy Gapon 
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-Rspamd-Queue-Id: 4LdxBN74zjz3rtV
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=opxhYIsy;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of gusev.vitaliy@gmail.com designates 2a00:1450:4864:20::22d as permitted sender) smtp.mailfrom=gusev.vitaliy@gmail.com
X-Spamd-Result: default: False [-1.50 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TAGGED_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22d:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	DKIM_TRACE(0.00)[gmail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RECEIVED_SPAMHAUS_PBL(0.00)[188.187.60.230:received];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[current,virtualization]
X-ThisMailContainsUnwantedMimeParts: N

You probably should set up a dump device to get crash info, stack, etc.

=E2=80=94=E2=80=94
Vitaliy Gusev

> On 7 Jul 2022, at 15:29, Andriy Gapon  wrote:
>=20
>=20
> I have a strange issue with running an 'appliance' image based on =
FreeBSD 12 in bhyve on a machine with Ryzen 5800x processor.
>=20
> The problem is that the guest would run for a while and then the host =
would suddenly reset itself.  It appears like a triple fault or =
something with similar consequences.
>=20
> The time may be from a few dozens of minutes to many hours.
>=20
> Just to be clear, no such thing occurs if I do not run the guest.
> Also, I have an older AMD system (pre-Zen), the problem does not =
happen there.
> A vanilla FreeBSD 12.3 installation that just sits idle also does not =
cause the problem.
>=20
> Does anyone have an idea what the problem could be?
> What workaround or diagnostics to try?
> Anybody else seen something like this?
>=20
> Since it's the host that resets it would be hard to capture any =
traces.
> Thank you.
> --=20
> Andriy Gapon
>=20
>=20
> https://standforukraine.com
> https://razomforukraine.org
>=20


From nobody Thu Jul  7 14:26:13 2022
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 ABC793E39FB
	for ; Thu,  7 Jul 2022 14:26:21 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LdzHJ33Wdz41d1
	for ; Thu,  7 Jul 2022 14:26:20 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 267EQDwY018848
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 7 Jul 2022 07:26:13 -0700 (PDT)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 267EQD0P018847;
	Thu, 7 Jul 2022 07:26:13 -0700 (PDT)
	(envelope-from sgk)
Date: Thu, 7 Jul 2022 07:26:13 -0700
From: Steve Kargl 
To: Ryan Stone 
Cc: FreeBSD Current 
Subject: Re: buildkernel is broken
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
References: 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4LdzHJ33Wdz41d1
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu
X-Spamd-Result: default: False [-0.99 / 15.00];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none];
	R_SPF_NA(0.00)[no SPF record];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US];
	FROM_HAS_DN(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current];
	MID_RHS_MATCH_FROM(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]
X-ThisMailContainsUnwantedMimeParts: N

Yes, I do.

Deleting the line allows to code to compile.

-- 
steve

On Thu, Jul 07, 2022 at 08:24:47AM -0400, Ryan Stone wrote:
> Do you have VNET disabled in your kernel config?  I believe that this
> was fixed by 37f604b49d4a.
> 
> On Thu, Jul 7, 2022 at 1:07 AM Steve Kargl
>  wrote:
> >
> > -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_input.c
> > --- modules-all ---
> > /usr/src/sys/netpfil/ipfw/ip_dn_io.c:674:4: error: 'continue' statement not in loop statement
> >                         continue;
> >                         ^
> > 1 error generated.
> > *** [ip_dn_io.o] Error code 1
> >
> > make[4]: stopped in /usr/src/sys/modules/dummynet
> > 1 error
> > *** [modules-all] Error code 6
> >
> > make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/SPEW
> > 1 error
> >
> > make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/SPEW
> >         5.75 real        20.45 user         2.30 sys
> >
> > make[1]: stopped in /usr/src
> >
> >
> > Please fix.
> >
> > --
> > Steve
> >

-- 
Steve

From nobody Thu Jul  7 14:38:43 2022
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 160AC3E6684
	for ; Thu,  7 Jul 2022 14:38:57 +0000 (UTC)
	(envelope-from rysto32@gmail.com)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LdzYr3ZRgz43sc
	for ; Thu,  7 Jul 2022 14:38:56 +0000 (UTC)
	(envelope-from rysto32@gmail.com)
Received: by mail-ej1-x62a.google.com with SMTP id ez10so2641125ejc.13
        for ; Thu, 07 Jul 2022 07:38:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=kymUhk+iV5a1Rz6L4PNDJ4ziL9BGrEeKYkcVkvP3GkI=;
        b=DSdnGLl1C5wHYcYgkWO1jWGbhX4+eOjTqz7dzVB8TQqVQiLvMrzhesfKZrpyIYUNyL
         1fxItLgH4D0bOnnipoEvNYMsROg1t2PPYQ5NlU0yNqBT4hengdJNuRIFj+/oTHY6q7S0
         zbbV6hU8fTQRXefP/QW5Ys0SbYEkGkRdx4IyDjrkjed8M38XaZqGlo93gOdQcpCr9rhu
         LDXhsNj3fKpwO12OaqB/1nsf/NsFdFabkz/l4Liy91eWd1aCJcOnVTN+5roGZdWI38fp
         65wForlrTwEVF7CDZPEKtjAQImkHf6QZXf4gMeQC1ziodhps+hZuFEHmlnqQKPPsyESC
         DqHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=kymUhk+iV5a1Rz6L4PNDJ4ziL9BGrEeKYkcVkvP3GkI=;
        b=sspxEWYE4oywvAaf0Oh/6UXYOnbHjRn3qBO2k7tySjAMZcyMNk0VIO9rhRIuKCTXUE
         711cu5rymR+bU0KvC8FAbJi7EvNwGlkhSKQ+4ysDzd05iRm8eS7Qgt/ZVre4bzX8nC4W
         fXhPAmiyLIENV0pA/XdYAmGKWNLanCl3D2bznIHTOJadwTxpwqkR9SILBgYofquPUMA9
         Ly/kzOWhEj+SWG3dnH5lqL+uPu1tOOk1F1NvmIFJZp12JTOZJEtxhlblF7ltE2qJw0fA
         2qoe4RCMr9zhc8nuvNmzb/XtucTQgVK5RQtYPOUBTgWIzzuaL1iJMEeUEovdh9Asc8jM
         2lDQ==
X-Gm-Message-State: AJIora+ouscTerFN4NHbt4jgBSKJcfRcF6YvWRhueeG77DvtEqqI6e5z
	fAac8Ncdbv1FPQtyRL3Qp4/8r2w7FFwirMFfBxZlT2mD
X-Google-Smtp-Source: AGRyM1vZujy6ft7kzD23G5sQU8PlgeEBwUOlIJT6e0QNF5Qr6TceAPaJSytZySV1vOeNAr4rE6kXJsjs1KDA8jv8fVc=
X-Received: by 2002:a17:906:6a14:b0:72a:fcd7:57b0 with SMTP id
 qw20-20020a1709066a1400b0072afcd757b0mr7436312ejc.607.1657204735288; Thu, 07
 Jul 2022 07:38: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: 
  
In-Reply-To: 
From: Ryan Stone 
Date: Thu, 7 Jul 2022 10:38:43 -0400
Message-ID: 
Subject: Re: buildkernel is broken
To: Steve Kargl 
Cc: FreeBSD Current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4LdzYr3ZRgz43sc
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=DSdnGLl1;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=rysto32@gmail.com
X-Spamd-Result: default: False [-1.66 / 15.00];
	NEURAL_HAM_SHORT(-0.66)[-0.660];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

Okay, update your tree and it should be fixed then.

From nobody Thu Jul  7 14:49:59 2022
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 4FBF98D0F46
	for ; Thu,  7 Jul 2022 14:50:02 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ldzpd51ldz45Z9
	for ; Thu,  7 Jul 2022 14:50:01 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 267Enxlr018978
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 7 Jul 2022 07:49:59 -0700 (PDT)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 267Enxdw018977;
	Thu, 7 Jul 2022 07:49:59 -0700 (PDT)
	(envelope-from sgk)
Date: Thu, 7 Jul 2022 07:49:59 -0700
From: Steve Kargl 
To: Ryan Stone 
Cc: FreeBSD Current 
Subject: Re: buildkernel is broken
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
References: 
 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4Ldzpd51ldz45Z9
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu
X-Spamd-Result: default: False [-0.99 / 15.00];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none];
	R_SPF_NA(0.00)[no SPF record];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US];
	FROM_HAS_DN(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current];
	MID_RHS_MATCH_FROM(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jul 07, 2022 at 10:38:43AM -0400, Ryan Stone wrote:
> Okay, update your tree and it should be fixed then.

Is it possible to pull just that fix?  I spent part of
yesterday building world, and contrary to popular belief,
not all hardware contain a 32-core uber-fast ryzen cpu.

Can people please test their simple changes prior to
committing?

-- 
Steve

From nobody Thu Jul  7 15:24:47 2022
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 B161C8D6E43
	for ; Thu,  7 Jul 2022 15:25:00 +0000 (UTC)
	(envelope-from rysto32@gmail.com)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf0b00JWwz3CSL
	for ; Thu,  7 Jul 2022 15:25:00 +0000 (UTC)
	(envelope-from rysto32@gmail.com)
Received: by mail-ej1-x631.google.com with SMTP id ez10so2880559ejc.13
        for ; Thu, 07 Jul 2022 08:25:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=Vj98pCW1skXsNr8XUlYjgnrpK40TxXYgXiaUPUYyBXI=;
        b=TvGTz7/OWLFv9oT7fpfj8N4EpSMxfHtI+G6UXdOD92dVji3ykxqVQS8DqHmH4kBMm4
         hs3fSz60lUCh3HLvbZsaz5rzdcpPFZbDIS9f0bLUyzqVNT6biBu89RJLSto5Bw+Gacx4
         jkYF8HikhADupCGWKjNM8kZNBbpvkdAmkXCnnYVVV6mE77mk9afkHdjAgN8nRlMujCRX
         ECeyCqBitiypJt41Mlic+emdIMzGWYWqWWFjiK4Drye1fcazXtcsyCAEKk0rIaHSb5u6
         DtcU0anyXO64ey4phcO8bRgkcux1oE2eduvkwGF4tlILwtRHZWghh6IjOugLAluskStV
         GDHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=Vj98pCW1skXsNr8XUlYjgnrpK40TxXYgXiaUPUYyBXI=;
        b=UzlGV8ej4QNvWmKJe/UHUlrrEfmmRWbg9itF8k/aMEB6mX1OB4kfCGDDcRHHVt/IsE
         J9hY1F+mWcDCHAefPUiOnOp90mjaolY6O1sp51MuTgq1KrvNZIkhBATp01dHf0a00wqC
         aXHQVSHcJ+mRDslktGCD0l95N4B4a/r6BL1r1NE3b2ACNBLWGU049BmhV21ZwhhHp7CI
         6gHW88zXDczH173jcDFPI3XUE1N7FPNKDHiOc96rpUgd54mF54xpxatbjicbOrZMfb9q
         4FxIkk04UfJUQ8nfwDE7pnstFa0LKbLoX55YrMOUsqJi+dHJGuqCIMdM/lfed+kDmZVb
         r6gg==
X-Gm-Message-State: AJIora+Zzk9CyM/i2wp+1frmAWJj/hD8f+ic/ZrrAqmP4O8B5w+AXrFM
	o0wIamUdaEPD1gVECE72IEVGPtfyFQXYHqHeWU+U8AuweT0=
X-Google-Smtp-Source: AGRyM1vFWMxA5XVWa29QhpYdU5ZmIRw/s4xm2hq9w5XFCcixVqerux09eqOeK11vcnqWgE6xtue5Zr+haHPOOyf4/DI=
X-Received: by 2002:a17:907:2081:b0:726:b8d2:fba2 with SMTP id
 pv1-20020a170907208100b00726b8d2fba2mr43683608ejb.686.1657207498941; Thu, 07
 Jul 2022 08:24: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: 
 
  
 
In-Reply-To: 
From: Ryan Stone 
Date: Thu, 7 Jul 2022 11:24:47 -0400
Message-ID: 
Subject: Re: buildkernel is broken
To: Steve Kargl 
Cc: FreeBSD Current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4Lf0b00JWwz3CSL
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="TvGTz7/O";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=rysto32@gmail.com
X-Spamd-Result: default: False [-1.11 / 15.00];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	NEURAL_HAM_SHORT(-0.11)[-0.107];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

You could "git cherry-pick -n 37f604b49d4a; git restore --unstaged
sys/net/vnet.h" to apply the fix to your local tree without committing
it or leaving it staged for commit.

On Thu, Jul 7, 2022 at 10:50 AM Steve Kargl
 wrote:
>
> On Thu, Jul 07, 2022 at 10:38:43AM -0400, Ryan Stone wrote:
> > Okay, update your tree and it should be fixed then.
>
> Is it possible to pull just that fix?  I spent part of
> yesterday building world, and contrary to popular belief,
> not all hardware contain a 32-core uber-fast ryzen cpu.
>
> Can people please test their simple changes prior to
> committing?
>
> --
> Steve

From nobody Thu Jul  7 15:30:05 2022
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 6A1C512AD219
	for ; Thu,  7 Jul 2022 15:30:18 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf0j52N5Rz3LN6
	for ; Thu,  7 Jul 2022 15:30:17 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe29.google.com with SMTP id f68so3782626vsc.11
        for ; Thu, 07 Jul 2022 08:30:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=QNw8XdfPtKXkNE8+qNrTeVGa4QZ2HVL4Bc2M2JQhv7s=;
        b=sTUHHE/SmheKmDxrwVMyrjER3lJMl90LRO/hGMg6hiUMaoypc8uoXyPbcAgrlWAETl
         PcSa2XSHFngfr5pNUXn7Mrs3Q8bIS/wQ/x6DBdsEO03LG5Nhx0Q4kGMCXKJkeehDzRtQ
         svVNWjcdvdpuXRhTr+WMnp8Behfr9FDgimuNM9aD1R3ReYECWvHzVbip/20F2GYoJ8nd
         h1Wz77L/cRRY6bV62c/pw/2s0/23rgRScunRtvyJDDl67z7xAPOy5x3SM40Hfy7jgweA
         Vmox+QRrWzidOiWrIufbQyRWH/tfmMroLbF3kIjT1iEdfl/lXSrcVB5pY+ShFQ0Wco9w
         +tEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=QNw8XdfPtKXkNE8+qNrTeVGa4QZ2HVL4Bc2M2JQhv7s=;
        b=hO9Xem8GO20VrahGZffd9hFkFUV+xZFE6Xjotga81tSSDmgTD4PxtJI+pHctHxfUuG
         1/kdUzsseF8n+iVPzZuNjQqC533uskfQcLgbd3aOLZYWR+uQhSWBEX5mzpoNd5k2Wc5r
         4Lve7tap4/0Ac9rjE4GJuRT4/1kWVKA9UvvmnHUbMxMFsZ9NRwFEV75FrFwxuCA34c4q
         64tzvir/oV2385LXcbTeUfsBXNYMq191eyokBt2hd7jZviZWmHBmlzTe2jWWc5da4Wld
         FXOtBEDsQghrrXhzi7wYp/4sjHQkOy+OWYKIKrEQBURH7Zs5H8sQwJZ0iSaVn5EvdxNf
         lANg==
X-Gm-Message-State: AJIora/cO71gQ0wbD2I+uhtLgQK7Gzy/JrblZA1lKHliQmnIxwdEEHvV
	6b8sTC3IJ1PSBZJPQr4r1glOS6sH/G34RtTascyQE7UoCn0=
X-Google-Smtp-Source: AGRyM1sZ8OjvHlCZ1UmFxt89P/XA1IOvUavYWiBpSpd3ZY/US0weyhii71dpoxGnRgZ99ywjs2qpJ4JQr7R2KVAaMfs=
X-Received: by 2002:a67:ec88:0:b0:357:83f:e0f3 with SMTP id
 h8-20020a67ec88000000b00357083fe0f3mr7008024vsp.76.1657207816216; Thu, 07 Jul
 2022 08:30:16 -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: Thu, 7 Jul 2022 09:30:05 -0600
Message-ID: 
Subject: Re: buildkernel is broken
To: Ryan Stone 
Cc: Steve Kargl , 
	FreeBSD Current 
Content-Type: multipart/alternative; boundary="00000000000034780505e338c3b2"
X-Rspamd-Queue-Id: 4Lf0j52N5Rz3LN6
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="sTUHHE/S";
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e29) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-0.97 / 15.00];
	NEURAL_HAM_SHORT(-0.97)[-0.971];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e29:from];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000034780505e338c3b2
Content-Type: text/plain; charset="UTF-8"

Or you could cherry-pick the fix. When you update git pull --rebase will
automatically
drop it when you rebase past that spot. Or if you have a branch, you can do
the same
to the branch and when you rebase past the fix, it will automatically drop.

Warner

On Thu, Jul 7, 2022 at 9:25 AM Ryan Stone  wrote:

> You could "git cherry-pick -n 37f604b49d4a; git restore --unstaged
> sys/net/vnet.h" to apply the fix to your local tree without committing
> it or leaving it staged for commit.
>
> On Thu, Jul 7, 2022 at 10:50 AM Steve Kargl
>  wrote:
> >
> > On Thu, Jul 07, 2022 at 10:38:43AM -0400, Ryan Stone wrote:
> > > Okay, update your tree and it should be fixed then.
> >
> > Is it possible to pull just that fix?  I spent part of
> > yesterday building world, and contrary to popular belief,
> > not all hardware contain a 32-core uber-fast ryzen cpu.
> >
> > Can people please test their simple changes prior to
> > committing?
> >
> > --
> > Steve
>
>

--00000000000034780505e338c3b2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Or you could cherry-pick the fix. When you update git=
 pull --rebase will automatically
drop it when you rebase past th=
at spot. Or if you have a branch, you can do the same
to the bran=
ch and when you rebase past the fix, it will automatically drop.
=

Warner

On Thu, Jul 7, 2022 at 9:25 AM Ryan Stone <rysto32@gmail.com> wrote:
You could "git cherry-p=
ick -n 37f604b49d4a; git restore --unstaged

sys/net/vnet.h" to apply the fix to your local tree without committing=


it or leaving it staged for commit.



On Thu, Jul 7, 2022 at 10:50 AM Steve Kargl

<s=
gk@troutmask.apl.washington.edu> wrote:

>

> On Thu, Jul 07, 2022 at 10:38:43AM -0400, Ryan Stone wrote:

> > Okay, update your tree and it should be fixed then.

>

> Is it possible to pull just that fix?=C2=A0 I spent part of

> yesterday building world, and contrary to popular belief,

> not all hardware contain a 32-core uber-fast ryzen cpu.

>

> Can people please test their simple changes prior to

> committing?

>

> --

> Steve






--00000000000034780505e338c3b2--

From nobody Thu Jul  7 16:36:18 2022
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 960FC12D7DA8
	for ; Thu,  7 Jul 2022 16:36:21 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf29J4WTlz3Tj0
	for ; Thu,  7 Jul 2022 16:36:20 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 267GaI6c019772
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 7 Jul 2022 09:36:18 -0700 (PDT)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 267GaIlU019771;
	Thu, 7 Jul 2022 09:36:18 -0700 (PDT)
	(envelope-from sgk)
Date: Thu, 7 Jul 2022 09:36:18 -0700
From: Steve Kargl 
To: Ryan Stone 
Cc: FreeBSD Current 
Subject: Re: buildkernel is broken
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
References: 
 
 
 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4Lf29J4WTlz3Tj0
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu
X-Spamd-Result: default: False [-1.00 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none];
	R_SPF_NA(0.00)[no SPF record];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US];
	FROM_HAS_DN(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current];
	MID_RHS_MATCH_FROM(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]
X-ThisMailContainsUnwantedMimeParts: N

Thanks, but

root[216] git cherry-pick -n 37f604b49d4a
fatal: bad revision '37f604b49d4a'
root[217] pwd
/usr/src

-- 
steve

On Thu, Jul 07, 2022 at 11:24:47AM -0400, Ryan Stone wrote:
> You could "git cherry-pick -n 37f604b49d4a; git restore --unstaged
> sys/net/vnet.h" to apply the fix to your local tree without committing
> it or leaving it staged for commit.
> 
> On Thu, Jul 7, 2022 at 10:50 AM Steve Kargl
>  wrote:
> >
> > On Thu, Jul 07, 2022 at 10:38:43AM -0400, Ryan Stone wrote:
> > > Okay, update your tree and it should be fixed then.
> >
> > Is it possible to pull just that fix?  I spent part of
> > yesterday building world, and contrary to popular belief,
> > not all hardware contain a 32-core uber-fast ryzen cpu.
> >
> > Can people please test their simple changes prior to
> > committing?
> >
> > --
> > Steve

-- 
Steve

From nobody Thu Jul  7 16:37:40 2022
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 B2FDF12D8D09
	for ; Thu,  7 Jul 2022 16:37:52 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf2C371T6z3Vw6
	for ; Thu,  7 Jul 2022 16:37:51 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe31.google.com with SMTP id 185so7679640vse.6
        for ; Thu, 07 Jul 2022 09:37:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=GpV4GEede4R8KdGf6t2GR7rU7AvPQ4AxcyYQ0++ZWms=;
        b=hyOG+4TmhxfhCYorsH63TEwNkWt0Wamm+z/tKHyQ95boVFufc2qHPi1weR91Kiy9qW
         eLJ8QKFyNAX8kbOc0COJziERH5P4ZSqersvYuCtijYPCt7RM7/jekc/6IztNcXNNALoa
         Dm8E4H69PVzC1QShG0SwK5s2ueqZYE0BHkIk6CmZlCowiFg/18o/qfqEhFYvjimLRIqp
         P0OmFuUdDDc9uHQUyZ5eQ/rBunAGTSoS4D/KAxwD+2l92AACoP+UyVvi4IaW+jktX0Ji
         ph84xU4TF88EtRdoEgCdUcFiFKCKy1hV2TaSo73hDUXReK3xAaWXUq6N3M60ZZ9tU//o
         iDEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=GpV4GEede4R8KdGf6t2GR7rU7AvPQ4AxcyYQ0++ZWms=;
        b=zwS+NAumMcpUgIy7JlwUs2z7wq5GNuyljOxCnv/rinxkNYWn7pJgb7hLjNQI7UIwsm
         bPnPH36/9keut6RixBfvdyYRVCIeM4UOV79ug0ZwTkAKHzwk6MZiJvy3vJAyPolFl5RW
         QeFxx4D+xK7lMZrQl1bv4k6fkPrqlv0c4bWeC8f9BqFdgZ/1GVZzeqyqRXVUGuapwn0E
         7RQbCWSPM5Y174ecO1bjVBpxsDg13D596sOAQyCw9YCDtNBx0sP23guWusdVjMBOK8qo
         X1VD4Y1P0G0FTQB6xKySdZwtMXnq/WidEWh3hLSAW4l7620uP5RJd0kwHJkrNbLLZ10F
         z9cQ==
X-Gm-Message-State: AJIora94L3RpGlZXyZMmbKN8VmvjJBBuvtFU3kItNNh0PY/vj6Tx2hpw
	aNiffId5YojMx6fvFk0fEcUublIA2vNaPfi/B9jvAQ==
X-Google-Smtp-Source: AGRyM1t2+uyivPzlwWY+rH8y8R/60JTa7CrjacDA2K+XKnWrzqIsRUA+g+9+RPhRzFfI4905YSkvNUBmsaTxuTaWIkY=
X-Received: by 2002:a67:ec88:0:b0:357:83f:e0f3 with SMTP id
 h8-20020a67ec88000000b00357083fe0f3mr7294807vsp.76.1657211871218; Thu, 07 Jul
 2022 09:37:51 -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: Thu, 7 Jul 2022 10:37:40 -0600
Message-ID: 
Subject: Re: buildkernel is broken
To: Steve Kargl 
Cc: Ryan Stone , FreeBSD Current 
Content-Type: multipart/alternative; boundary="000000000000e6e43f05e339b41a"
X-Rspamd-Queue-Id: 4Lf2C371T6z3Vw6
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=hyOG+4Tm;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e31) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-1.00 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-current];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e6e43f05e339b41a
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 7, 2022 at 10:37 AM Steve Kargl <
sgk@troutmask.apl.washington.edu> wrote:

> Thanks, but
>
> root[216] git cherry-pick -n 37f604b49d4a
> fatal: bad revision '37f604b49d4a'
> root[217] pwd
> /usr/src


git fetch maybe?

Warner


>

-- 
> steve
>
> On Thu, Jul 07, 2022 at 11:24:47AM -0400, Ryan Stone wrote:
> > You could "git cherry-pick -n 37f604b49d4a; git restore --unstaged
> > sys/net/vnet.h" to apply the fix to your local tree without committing
> > it or leaving it staged for commit.
> >
> > On Thu, Jul 7, 2022 at 10:50 AM Steve Kargl
> >  wrote:
> > >
> > > On Thu, Jul 07, 2022 at 10:38:43AM -0400, Ryan Stone wrote:
> > > > Okay, update your tree and it should be fixed then.
> > >
> > > Is it possible to pull just that fix?  I spent part of
> > > yesterday building world, and contrary to popular belief,
> > > not all hardware contain a 32-core uber-fast ryzen cpu.
> > >
> > > Can people please test their simple changes prior to
> > > committing?
> > >
> > > --
> > > Steve
>
> --
> Steve
>
>

--000000000000e6e43f05e339b41a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Jul 7, 2022 at 10:37 AM Steve=
 Kargl <sgk@troutmas=
k.apl.washington.edu> wrote:
Thanks, but



root[216] git cherry-pick -n 37f604b49d4a

fatal: bad revision '37f604b49d4a'

root[217] pwd

/usr/src

git fetch maybe?

Warner
=C2=A0
=C2=A0

-- 

steve



On Thu, Jul 07, 2022 at 11:24:47AM -0400, Ryan Stone wrote:

> You could "git cherry-pick -n 37f604b49d4a; git restore --unstage=
d

> sys/net/vnet.h" to apply the fix to your local tree without commi=
tting

> it or leaving it staged for commit.

> 

> On Thu, Jul 7, 2022 at 10:50 AM Steve Kargl

> <sgk@troutmask.apl.washington.edu> wrote:

> >

> > On Thu, Jul 07, 2022 at 10:38:43AM -0400, Ryan Stone wrote:

> > > Okay, update your tree and it should be fixed then.

> >

> > Is it possible to pull just that fix?=C2=A0 I spent part of

> > yesterday building world, and contrary to popular belief,

> > not all hardware contain a 32-core uber-fast ryzen cpu.

> >

> > Can people please test their simple changes prior to

> > committing?

> >

> > --

> > Steve



-- 

Steve






--000000000000e6e43f05e339b41a--

From nobody Thu Jul  7 17:00:28 2022
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 0289712DD139
	for ; Thu,  7 Jul 2022 17:00:32 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf2jB4b5Fz3ZcF
	for ; Thu,  7 Jul 2022 17:00:30 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 267H0SOm020029
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 7 Jul 2022 10:00:28 -0700 (PDT)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 267H0SFb020028;
	Thu, 7 Jul 2022 10:00:28 -0700 (PDT)
	(envelope-from sgk)
Date: Thu, 7 Jul 2022 10:00:28 -0700
From: Steve Kargl 
To: Warner Losh 
Cc: Ryan Stone ,
        FreeBSD Current 
Subject: Re: buildkernel is broken
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
References: 
 
 
 
 
 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4Lf2jB4b5Fz3ZcF
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu
X-Spamd-Result: default: False [-1.00 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org];
	R_DKIM_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_COUNT_THREE(0.00)[3];
	HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jul 07, 2022 at 10:37:40AM -0600, Warner Losh wrote:
> On Thu, Jul 7, 2022 at 10:37 AM Steve Kargl <
> sgk@troutmask.apl.washington.edu> wrote:
> 
> > Thanks, but
> >
> > root[216] git cherry-pick -n 37f604b49d4a
> > fatal: bad revision '37f604b49d4a'
> > root[217] pwd
> > /usr/src
> 
> 
> git fetch maybe?
> 

A cursory google search suggests that 'git fetch' 
works on repositories not single files.

I did look at the diff associated with 37f604b49d4a.
I am surprised that the commit that broke buildkernel
for me was allowed to be committed.  The fix in
37f604b49d4a seems rather questionable especially given
that there is no comment about why the macro is expanded
to a zero-trip loop.

Thanks for the help.  I'll just do a 'git pull'
and start over with a buildworld.
 
-- 
Steve

From nobody Thu Jul  7 17:21:43 2022
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 F0CB93E1EA4
	for ; Thu,  7 Jul 2022 17:21:21 +0000 (UTC)
	(envelope-from kevans@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf39F6b1Fz3f5r
	for ; Thu,  7 Jul 2022 17:21:21 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657214481;
	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=tnhLJaQ/429xRrxxXY7KM9IoShXOwK7ariTSuon4OwQ=;
	b=MSc9Zn1bfHju7hQIwTsCM+KZelc31X4qg72bFQsSlHH3QeRjoK0LtgkzqXHmTr4dwXXvFZ
	qCkS/ZPLxd5OL4FeVJj5muNI6/awVM24R1Owi7UhqlDMXm8zMaoQBVRs5Lvb1acC2LqhqP
	tua4GEe5VOJP7ffiR8Cw9w3j9MSba95gnCMwj+9sP6mkwujZCQCKC9I0f0W+yBXrxnfLnz
	SUReVVP8f3FFZ96gZHif5TuJ6NaC4zR05zUlhWyKhJD/K5VA5JTAEmv0CVBUCvhmdWl6Uv
	aNYaAItt4dUNQz2yw3IzmMv2rUDWd9Zhz5yKmQpR2G7sxM90N3CG9BigwETLrQ==
Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: kevans)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Lf39F5YmhzYfT
	for ; Thu,  7 Jul 2022 17:21:21 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
Received: by mail-ed1-f49.google.com with SMTP id x10so16655069edd.13
        for ; Thu, 07 Jul 2022 10:21:21 -0700 (PDT)
X-Gm-Message-State: AJIora+1QzelvToLHRsSQ12k+JTlzDPRE+2KnH3nZlX/vtQvFyrARxXl
	vIT35Biy3k5jHkVhBo7FKZUAISmkhiPi1mPHhWE=
X-Google-Smtp-Source: AGRyM1tb657JJAHdt2Fe2znaGq2qxsA/FKLCSIRcXwlBSIZLk5El1mgxHbRVxN58OtJAILye8HTm2m8Ppe8D2cTmKAk=
X-Received: by 2002:a05:6402:4490:b0:43a:8f5a:d273 with SMTP id
 er16-20020a056402449000b0043a8f5ad273mr12098189edb.6.1657214480766; Thu, 07
 Jul 2022 10:21:20 -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: Kyle Evans 
Date: Thu, 7 Jul 2022 10:21:43 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: buildkernel is broken
To: sgk@troutmask.apl.washington.edu
Cc: Warner Losh , Ryan Stone , 
	FreeBSD Current 
Content-Type: text/plain; charset="UTF-8"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657214481;
	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=tnhLJaQ/429xRrxxXY7KM9IoShXOwK7ariTSuon4OwQ=;
	b=kNvkOZh8IbW4fARMML9T2X/Kuh3U9qdTVg7OopHoj2kUbGtB44E6/d7NEITDreNpstZ3ce
	L8xTjQTL2wApFlggYecLqB9UcDECAXcjlsryYsMedkIkH0eNktttwgOfX3me1Z8C7/S+JW
	5KolyWfdyiqfv6ZPDJminqx01qXL8Odx52bbuzb0WGbdItMSGdQy49gQqLmX4/ZWZnXP1a
	RDDanSX4dXYa6eypU6AdHfLpHngG+cWjUsR/3GHLqoC1H4q8KpEHfzEiyMx5Aqaodi1wNL
	2W+pXlevSTMhDEBF+QAlqOcPTy5bbP9wv8sn17iitnTOIFqx3o/rXMvOtYQPuw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657214481; a=rsa-sha256; cv=none;
	b=qweTvFmydcKzCdmjB9j0cu97Qx4cnzHSVkKHwaTIEuxAx/mjDzrJ22pJa738U3hCvJSqk6
	NG+j17by7rrVMuIKEblejfC5ZYL3s6/LChaitEg6CI+fhSHKAhvdp1TXK2/qnzlg/10OmF
	l+D8vLob3CgLKwUx8F7qHrqCLYXxsaWmQXSbZY1l4/mGXbyCOG8PXRU/l4GX+ss79zCwFP
	697NpYcG4D2IVJo8dtUSuUhsERbNWffoLXuNQh6mR+Gi+O2SEw0Ha/Uzx/xy3lfQpczKf8
	PJDkyVNPcH+/eCSQxqkpXDrfFOs+l2NB2EaRhIoSGqtscZpOaFnbAcdlG7VU6A==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jul 7, 2022 at 10:01 AM Steve Kargl
 wrote:
>
> On Thu, Jul 07, 2022 at 10:37:40AM -0600, Warner Losh wrote:
> > On Thu, Jul 7, 2022 at 10:37 AM Steve Kargl <
> > sgk@troutmask.apl.washington.edu> wrote:
> >
> > > Thanks, but
> > >
> > > root[216] git cherry-pick -n 37f604b49d4a
> > > fatal: bad revision '37f604b49d4a'
> > > root[217] pwd
> > > /usr/src
> >
> >
> > git fetch maybe?
> >
>
> A cursory google search suggests that 'git fetch'
> works on repositories not single files.
>

Right, the idea is that you `git fetch origin main` (or whatever your
remote is called rather than 'origin') then you can cherry-pick the
revision. fetch will grab the revision without merging it into the
current branch.

> I did look at the diff associated with 37f604b49d4a.
> I am surprised that the commit that broke buildkernel
> for me was allowed to be committed.  The fix in
> 37f604b49d4a seems rather questionable especially given
> that there is no comment about why the macro is expanded
> to a zero-trip loop.
>
> Thanks for the help.  I'll just do a 'git pull'
> and start over with a buildworld.
>
> --
> Steve
>

From nobody Thu Jul  7 17:32:32 2022
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 8734E3E3AF0
	for ; Thu,  7 Jul 2022 17:32:51 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4Lf3QS05Gzz3gq4
	for ; Thu,  7 Jul 2022 17:32:47 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 72992260691;
	Thu,  7 Jul 2022 19:32:39 +0200 (CEST)
Message-ID: 
Date: Thu, 7 Jul 2022 19:32:32 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
To: FreeBSD Current 
Content-Language: en-US
From: Hans Petter Selasky 
Subject: Accessibility in the FreeBSD installer and console
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Lf3QS05Gzz3gq4
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.30 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[selasky.org];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

The only argument I've heard from some non-sighted friends about not 
using FreeBSD natively is that ooh, MacOSX is so cool. It starts 
speaking from the start if I press this and this key. Is anyone here 
working on or wanting such a feature? I mean it should be so much easier 
to text to speech our text based unicode console, than what MacOSX is 
doing, by tracking screen changes intelligently inside newcons in the 
kernel, and feeding that into a character device, that to espeak or 
whatever can read it.

--HPS

From nobody Thu Jul  7 17:46:11 2022
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 22D6E3E6AA7
	for ; Thu,  7 Jul 2022 17:46:27 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf3k70Yqzz3k4p
	for ; Thu,  7 Jul 2022 17:46:23 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vk1-xa32.google.com with SMTP id j26so9229390vki.12
        for ; Thu, 07 Jul 2022 10:46:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=jN03Ow2Ac4ka0R10ltuiSNoZKPescc7/MHysDqFdzBg=;
        b=SqPLEqFDo2X8CA1zY8UH3rLGdgMx62ra77zDYbAlp2oNzmXV/1UmruC6dAobHRNim5
         FJD/Li+GkLRPQrSQtSSZXhsGzqkSThrqmejI7VmvSozPjKmJcNXWLli4fI2h9Hbh+314
         Nr8TLPL6fB6KguIj7qRlprPlafjgU6+cbdvdcGubDFs7YcsLPZlXW5f87LhUpXAbjdVZ
         cXZYaKF+MdZRi1GqXP0zKqZ88i4y8Ey2w1uecRTPb2PABLQ6wGMEXeGnkNipx761iGbZ
         g5214Prm1SE8eUuWUp0fPA560V05v5TzsBn7v0XY4PbhopNCxf5VCwlY84hHVivq6g5V
         ktYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=jN03Ow2Ac4ka0R10ltuiSNoZKPescc7/MHysDqFdzBg=;
        b=Lf2BUw5uMNj5fBrHD81NpARsyiJouHIhsh+ZT6cuNPVq76XUnVxuESr14egRAlbMLK
         feehbtoNSALO6L0AYfsOZhV1/iERHPiOY1oOLuy0CFei+KWMPOf1KJE43eQAMeHoBSk6
         eOXxrW+Gkk6tUehR7KtFyDC0PgpHeRe7iU4SKkC44tP9lJkALCSwv7pdfghdzK5NAfsm
         Tn6uN8XgCsrdcTri7xw1hR+nPl5mdOdb7Lr4AecpgGzLNkfJghQingVfPvdE9mGSoAkP
         el/8n29mssY6ACPAQAgQ8vMSOe4hM82AgidZceSrpe+I8Z8tj4OjlCiJqVFlZx9flLzt
         //qw==
X-Gm-Message-State: AJIora9kTHjxw/aM6/wyF1aWTS5Mv85tSxqQHhUpPRCIFL8CWCZtkhOy
	RqHGotdta0vfuzxpIJBHUQ4Eo9hTdOk+OJA7+ZbfGBDX6ks=
X-Google-Smtp-Source: AGRyM1u0eHQCWF8vcaRGsMyTrLwqiYbq9BxKPQipGNfjtYaRoOLD8r+2AS7a/s30eJwA/wSGwzB5fqJF1pLzuINUybo=
X-Received: by 2002:a1f:b451:0:b0:374:1253:af96 with SMTP id
 d78-20020a1fb451000000b003741253af96mr9329453vkf.21.1657215982216; Thu, 07
 Jul 2022 10:46:22 -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: Thu, 7 Jul 2022 11:46:11 -0600
Message-ID: 
Subject: Re: buildkernel is broken
To: Kyle Evans 
Cc: Steve Kargl , Ryan Stone , 
	FreeBSD Current 
Content-Type: multipart/alternative; boundary="000000000000efcac805e33aa952"
X-Rspamd-Queue-Id: 4Lf3k70Yqzz3k4p
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=SqPLEqFD;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a32) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-1.00 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a32:from];
	BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::a32:server fail];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	FREEMAIL_CC(0.00)[troutmask.apl.washington.edu,gmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000efcac805e33aa952
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 7, 2022 at 11:21 AM Kyle Evans  wrote:

> On Thu, Jul 7, 2022 at 10:01 AM Steve Kargl
>  wrote:
> >
> > On Thu, Jul 07, 2022 at 10:37:40AM -0600, Warner Losh wrote:
> > > On Thu, Jul 7, 2022 at 10:37 AM Steve Kargl <
> > > sgk@troutmask.apl.washington.edu> wrote:
> > >
> > > > Thanks, but
> > > >
> > > > root[216] git cherry-pick -n 37f604b49d4a
> > > > fatal: bad revision '37f604b49d4a'
> > > > root[217] pwd
> > > > /usr/src
> > >
> > >
> > > git fetch maybe?
> > >
> >
> > A cursory google search suggests that 'git fetch'
> > works on repositories not single files.
> >
>
> Right, the idea is that you `git fetch origin main` (or whatever your
> remote is called rather than 'origin') then you can cherry-pick the
> revision. fetch will grab the revision without merging it into the
> current branch.
>

Indeed. a git fetch command will only update the remote/origin/upstream
tags and such as well as fetching new revisions there. It won't affect any
local branches as all until you explicitly merge them with 'git merge' or
implicitly with a 'git pull'.

Warner


> > I did look at the diff associated with 37f604b49d4a.
> > I am surprised that the commit that broke buildkernel
> > for me was allowed to be committed.  The fix in
> > 37f604b49d4a seems rather questionable especially given
> > that there is no comment about why the macro is expanded
> > to a zero-trip loop.
> >
> > Thanks for the help.  I'll just do a 'git pull'
> > and start over with a buildworld.
> >
> > --
> > Steve
> >
>

--000000000000efcac805e33aa952
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Jul 7, 2022 at 11:21 AM Kyle =
Evans <kevans@freebsd.org> =
wrote:
On Thu, J=
ul 7, 2022 at 10:01 AM Steve Kargl

<s=
gk@troutmask.apl.washington.edu> wrote:

>

> On Thu, Jul 07, 2022 at 10:37:40AM -0600, Warner Losh wrote:

> > On Thu, Jul 7, 2022 at 10:37 AM Steve Kargl <

> > sgk@troutmask.apl.washington.edu> wrote:

> >

> > > Thanks, but

> > >

> > > root[216] git cherry-pick -n 37f604b49d4a

> > > fatal: bad revision '37f604b49d4a'

> > > root[217] pwd

> > > /usr/src

> >

> >

> > git fetch maybe?

> >

>

> A cursory google search suggests that 'git fetch'

> works on repositories not single files.

>



Right, the idea is that you `git fetch origin main` (or whatever your

remote is called rather than 'origin') then you can cherry-pick the=


revision. fetch will grab the revision without merging it into the

current branch.

Indeed. a git fetch com=
mand will only update the remote/origin/upstream
tags and such as=
 well as fetching new revisions=C2=A0there. It won't affect any
local branches as all until you explicitly merge them with 'git merg=
e' or
implicitly with a 'git pull'.

Warner
=C2=A0

> I did look at the diff associated with 37f604b49d4a.

> I am surprised that the commit that broke buildkernel

> for me was allowed to be committed.=C2=A0 The fix in

> 37f604b49d4a seems rather questionable especially given

> that there is no comment about why the macro is expanded

> to a zero-trip loop.

>

> Thanks for the help.=C2=A0 I'll just do a 'git pull'

> and start over with a buildworld.

>

> --

> Steve

>




--000000000000efcac805e33aa952--

From nobody Thu Jul  7 17:59:29 2022
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 646A68D1A5C
	for ; Thu,  7 Jul 2022 17:59:32 +0000 (UTC)
	(envelope-from kp@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf41J2MtMz3m1Q;
	Thu,  7 Jul 2022 17:59:32 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657216772;
	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=2vdfWiX6TNpZAUZEdupNt0tSsSUOFuDAPl5Yduf7YlM=;
	b=F2RMkkOvTReir/VLHlmocX5sEW1uUx3SQ0gsCbDXPCrbcx0JaE5DJ8/o3D9VA4xzk7jalQ
	vDYaOhirkAsMEOecnvxDKQnn0EXC1KvqhzpisSPPMY2r6NagkeW3LkSpis3wT/Bl2kZdUK
	8KMj4VycRnJohYfGV63G4DCP/9n5ddGrOSBT1bkHk7kHNk6yPgrUHMdo7FA23JQNgVAel5
	oB7hMaeC03tC34SEeULD6fEaDsaVahkVdH2HiHhf0e6dS7kRpWiymMb0M8We1HdCtahsjB
	65nH2tpwMMUIylFsQLyJB8ymrwlHLp2IN+47gAPC5xR8mywfXeFnuQ6A6sTTQw==
Received: from venus.codepro.be (venus.codepro.be [5.9.86.228])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mx1.codepro.be", Issuer "R3" (verified OK))
	(Authenticated sender: kp)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Lf41H6x73zXfC;
	Thu,  7 Jul 2022 17:59:31 +0000 (UTC)
	(envelope-from kp@FreeBSD.org)
Received: by venus.codepro.be (Postfix, authenticated sender kp)
 id 4E5A62E530;
	Thu,  7 Jul 2022 19:59:30 +0200 (CEST)
From: Kristof Provost 
To: Steve Kargl 
Cc: Warner Losh , Ryan Stone ,
 FreeBSD Current 
Subject: Re: buildkernel is broken
Date: Thu, 07 Jul 2022 19:59:29 +0200
X-Mailer: MailMate (1.14r5852)
Message-ID: <4FE3FF3B-9F2C-41BF-9F96-B8036055A9F6@FreeBSD.org>
In-Reply-To: 
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/alternative;
 boundary="=_MailMate_6C495EB7-3B28-49EA-B95E-C3A9699F2CFD_="
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657216772;
	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=2vdfWiX6TNpZAUZEdupNt0tSsSUOFuDAPl5Yduf7YlM=;
	b=Fmm2PmmjqS8o+9mqtlm/kMjW6aWPoH+OBDFkAX9gJczyMT3dQm2igSwk4Elby0/17CrfWY
	+TPtbbPKyfIBnnCvG2vGH9dw9lSrC/0ztEaAiqRJhuZYvA2rOIMUCPFV96zc072UfJeBcR
	ETqTfoefPWJ6rHJIwndsIUyKaCy3EZmK6Y1I+ryACFDhtlxJ5VCAMIxaw08WedFUJqG1ap
	iIOYoFW47F3L3WNIx4D0o2fxfI/D94oA9DbYYDB2MeZwybsh+yHEwGEcBZyEK7kTCy8hZX
	+Gqd9iHIYgQUlJLmUOaRP8JqDk2qiwhLHgpdwudN1cDDLGFUxdjdHNis8WPi0w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657216772; a=rsa-sha256; cv=none;
	b=yADRP5AVMmLKtA57TTpeA7eDptJNR1tkjP3Dt5YqXBTEXvhsgJigWRYPTbGG4I9lwCBVUp
	jevWrcJq/3OiMBEE4dMf4igxKa5fzGOFpHKWcSke4Fmjqc1mgYY4sN4piW6U1+qtPq4Ph4
	Q1B6DsdG5qkTJ6N6heUIzMWeSuxzp3YNRLpdaXjKWCj2qQ8KuuYi06CeUjRra0y5EEVUrR
	3/9t3Y1NyII7BbdI6MxpgEBpTJt6zk76WYm3KqeEyH0o390gffGQxqSpnn6d5QFIxi8xMf
	AFbPJaKiOnAX+rfr0uZMnTSRWa/1dgaF1BbGXNB68cCPBZXOsZv75aviA/HKvQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--=_MailMate_6C495EB7-3B28-49EA-B95E-C3A9699F2CFD_=
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 7 Jul 2022, at 19:00, Steve Kargl wrote:
> On Thu, Jul 07, 2022 at 10:37:40AM -0600, Warner Losh wrote:
>> On Thu, Jul 7, 2022 at 10:37 AM Steve Kargl <
>> sgk@troutmask.apl.washington.edu> wrote:
>>
>>> Thanks, but
>>>
>>> root[216] git cherry-pick -n 37f604b49d4a
>>> fatal: bad revision '37f604b49d4a'
>>> root[217] pwd
>>> /usr/src
>>
>>
>> git fetch maybe?
>>
>
> A cursory google search suggests that 'git fetch'
> works on repositories not single files.
>
> I did look at the diff associated with 37f604b49d4a.
> I am surprised that the commit that broke buildkernel
> for me was allowed to be committed.

It was posted for review in https://reviews.freebsd.org/D35716

I’ll also point out that this commit works just fine in nearly all of 
our kernel configs, because there are very few (only one powerpc config, 
as far as I can tell) that do not have VIMAGE.
Arguably we should have a non-VIMAGE kernel config around (probably for 
amd64) so it’s more likely we spot these issues prior to commit.
Arbitrary non-default kernel configs are more likely to see issues like 
this one. I don’t think that can be avoided.

> The fix in
> 37f604b49d4a seems rather questionable especially given
> that there is no comment about why the macro is expanded
> to a zero-trip loop.
>
I’m not sure how I could have been much more clear than this:

     VNET_FOREACH() is a LIST_FOREACH if VIMAGE is set, but empty if 
it's
     not. This means that users of the macro couldn't use 'continue' or
     'break' as one would expect of a loop.

I welcome suggestions on how to improve my future commit messages.

To rephrase it a bit: VNET_FOREACH() used to be very misleading, in that 
it was only a loop with options VIMAGE, and empty (so any code within 
would be its own block, and be executed exactly once, for the only vnet 
that exists without VIMAGE). That’s fine, unless you want to 
‘continue’ or ‘break’ the loop. That worked with VIMAGE (so the 
issue in the dummynet fix was not seen) but not without it.

Kristof
--=_MailMate_6C495EB7-3B28-49EA-B95E-C3A9699F2CFD_=
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable









On 7 Jul 2022, at 19:00, Steve Kargl wrote:


On Thu, Jul 07, 2022 at 10:37:40AM =
-0600, Warner Losh wrote:


On Thu, Jul 7, 2022 at 10:37 AM Steve Kargl <


sgk@troutmask.apl.washington.edu> wrote:


Thanks, but


root[216] git cherry-pick -n 37f604b49d4a


fatal: bad revision '37f604b49d4a'


root[217] pwd


/usr/src


git fetch maybe?


A cursory google search suggests that 'git f=
etch'


works on repositories not single files.


I did look at the diff associated with 37f604b49d4a.


I am surprised that the commit that broke buildkernel


for me was allowed to be committed.






It was posted for review in https://reviews.freebsd.org/D35716


I=E2=80=99ll also point out that this commit works just f=
ine in nearly all of our kernel configs, because there are very few (only=
 one powerpc config, as far as I can tell) that do not have VIMAGE.

Arguably we should have a non-VIMAGE kernel config around (probably for a=
md64) so it=E2=80=99s more likely we spot these issues prior to commit.
Arbitrary non-default kernel configs are more likely to see issues like t=
his one. I don=E2=80=99t think that can be avoided.


The fix in


37f604b49d4a seems rather questionable especially given


that there is no comment about why the macro is expanded


to a zero-trip loop.






I=E2=80=99m not sure how I could have been much more clea=
r than this:


VNET_FOREACH() is a LIST_FOREACH if VIMAGE is set, but emp=
ty if it's
not. This means that users of the macro couldn't use 'continue' or
'break' as one would expect of a loop.



I welcome suggestions on how to improve my future commit =
messages.


To rephrase it a bit: VNET_FOREACH() used to be very misl=
eading, in that it was only a loop with options VIMAGE, and empty (so any=
 code within would be its own block, and be executed exactly once, for th=
e only vnet that exists without VIMAGE). That=E2=80=99s fine, unless you =
want to =E2=80=98continue=E2=80=99 or =E2=80=98break=E2=80=99 the loop. T=
hat worked with VIMAGE (so the issue in the dummynet fix was not seen) bu=
t not without it.


Kristof







--=_MailMate_6C495EB7-3B28-49EA-B95E-C3A9699F2CFD_=--

From nobody Thu Jul  7 18:07:02 2022
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 BD1528D33D6
	for ; Thu,  7 Jul 2022 18:07:10 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf4B12ZwKz3ncc;
	Thu,  7 Jul 2022 18:07:05 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 267I73Gt092554
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 7 Jul 2022 11:07:03 -0700 (PDT)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 267I73Ej092549;
	Thu, 7 Jul 2022 11:07:03 -0700 (PDT)
	(envelope-from sgk)
Date: Thu, 7 Jul 2022 11:07:02 -0700
From: Steve Kargl 
To: Kristof Provost 
Cc: Warner Losh , Ryan Stone ,
        FreeBSD Current 
Subject: Re: buildkernel is broken
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
References: 
 
 
 
 
 
 
 
 
 <4FE3FF3B-9F2C-41BF-9F96-B8036055A9F6@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=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4FE3FF3B-9F2C-41BF-9F96-B8036055A9F6@FreeBSD.org>
X-Rspamd-Queue-Id: 4Lf4B12ZwKz3ncc
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu
X-Spamd-Result: default: False [-1.00 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-current];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	FREEMAIL_CC(0.00)[bsdimp.com,gmail.com,freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	BLOCKLISTDE_FAIL(0.00)[128.95.76.21:query timed out];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_COUNT_THREE(0.00)[3];
	HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jul 07, 2022 at 07:59:29PM +0200, Kristof Provost wrote:
> On 7 Jul 2022, at 19:00, Steve Kargl wrote:
>
> > The fix in
> > 37f604b49d4a seems rather questionable especially given
> > that there is no comment about why the macro is expanded
> > to a zero-trip loop.
> > 
> I’m not sure how I could have been much more clear than this:
> 
>     VNET_FOREACH() is a LIST_FOREACH if VIMAGE is set, but empty if it's
>     not. This means that users of the macro couldn't use 'continue' or
>     'break' as one would expect of a loop.

Comments belong in the code.

/* Kludge to prevent non-vimage kernels from choking to death. */
#define VNET_FOREACH(arg)       for (int _vn = 0; _vn == 0; _vn++)


-- 
Steve

From nobody Thu Jul  7 20:11:52 2022
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 5494E12AFC30
	for ; Thu,  7 Jul 2022 20:11:57 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf6y44Ntvz43t1
	for ; Thu,  7 Jul 2022 20:11:56 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x52e.google.com with SMTP id z41so24545905ede.1
        for ; Thu, 07 Jul 2022 13:11:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=from:content-transfer-encoding:mime-version:subject:date:references
         :to:in-reply-to:message-id;
        bh=z4qEyDyAcQ5MmzB3Yr4Y7AUWVrHjnO0bLdRYspvBOPE=;
        b=ngqzEpIZrG7hzYjW7w3xu5es+2a43ldEUo3P4KMp8BEAmsD9JFhutBMk06xoLmrvQG
         hi2KPwJJQMijM0FUndMv4zD9LWInJ/K3WUFnD0OsL4qGyyM6tlRZyklV7Ry0r0BIw0Au
         9HqQyYAsqlImm8zGOs2LjYJWD79Oy7cOSkmehB3xB10SO5c4Lxfrot4tqM1Rle/as2vV
         WUBbr3Xmykc7cQbM2CfThR81tc9OjDkxxS0Fc97cq4FiFTcAZwujfRbQEWMYkrCDmUOP
         orYSNuSA+0zwQUk1bPUa7jOVCOE/Uk10XTbp+AS7VP7UQE5sNwR/lDRVK8fKsWNRrwh7
         VUSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:from:content-transfer-encoding:mime-version
         :subject:date:references:to:in-reply-to:message-id;
        bh=z4qEyDyAcQ5MmzB3Yr4Y7AUWVrHjnO0bLdRYspvBOPE=;
        b=mf/972NBLE6Azz9J74LQrmKMJyF8iUpccOxYQLQKYLwDT3P9FpDOWJu0xakwgAHiS+
         7LXLrlWHEIE+u2dRFLpLX4w9SNP6BTGoLbBEZ7XrQnxJnrPTBf7MGgV0XXfGOd5bXPtR
         2Qg1DcaYiMjGH6mO0GR/Ieuptlb6erFBOcmzb88kwckl/hAmJI+xvR6c6KiBl7Cs5Y33
         jbckqEz9fgi942Qw0RVcn7R226+GswGPy7aUdHzPsiWAEC8pFkCHJ8uejEqG9nEGUzwU
         rSLTl6tDt+xahlcGRyVeqBxAtgfxv1s8+vs8ALyuUtt+zDWg5XAhc3bZmbuMIuwE5bXd
         SBsw==
X-Gm-Message-State: AJIora/a3z5Q78xbfQWRjjLjQ8vGbz6cFWgDOhoW7Fj+2Qfnc6pgyIoB
	KxusEoCDXFtJasxjo9K1O9/uCCthx0i7iw==
X-Google-Smtp-Source: AGRyM1uYEoaJERvpdr0VETRrFUxp3EkT/na2CsOqeATnxsYhBTG5UumwW9lMMJRjJkvZeJmLxZJ6nA==
X-Received: by 2002:a05:6402:3884:b0:43a:68bf:4039 with SMTP id fd4-20020a056402388400b0043a68bf4039mr30369131edb.306.1657224715043;
        Thu, 07 Jul 2022 13:11:55 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-025-242.46.114.pool.telefonica.de. [46.114.25.242])
        by smtp.googlemail.com with ESMTPSA id r18-20020a17090609d200b0072af37a7220sm3329327eje.192.2022.07.07.13.11.54
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 07 Jul 2022 13:11:54 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.100.31\))
Subject: Re: Accessibility in the FreeBSD installer and console
Date: Thu, 7 Jul 2022 22:11:52 +0200
References: 
To: Hans Petter Selasky ,
 freebsd-current@freebsd.org
In-Reply-To: 
Message-Id: <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4Lf6y44Ntvz43t1
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=ngqzEpIZ;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::52e as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-1.48 / 15.00];
	NEURAL_HAM_SHORT(-0.98)[-0.980];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52e:from];
	DKIM_TRACE(0.00)[googlemail.com:+];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[googlemail.com];
	RCVD_COUNT_THREE(0.00)[3];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N


> Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
>=20
> Hi,
>=20
> The only argument I've heard from some non-sighted friends about not =
using FreeBSD natively is that ooh, MacOSX is so cool. It starts =
speaking from the start if I press this and this key. Is anyone here =
working on or wanting such a feature?

Possibly they didn=E2=80=99t want to  be rude and your friends didn't =
tell you the other argument  :-)  : according to the corresponding wiki =
page FreeBSD doesn't natively support any audio output at all on your =
friends current M1 Mac hardware.
 since quite nothing is currently supported you probably will first take =
over working on the Audio driver =E2=80=A6..and of course USB  :-)

> I mean it should be so much easier to text to speech our text based =
unicode console, than what MacOSX is doing, by tracking screen changes =
intelligently inside newcons in the kernel, and feeding that into a =
character device, that to espeak or whatever can read it.

nowadays called MacOS ( w/o the X)=E2=80=A6 as far as I remember even =
System7 Mac of 1984 had text to speech features =20
so it might be hard to convince a Mac users with such a brand new voice =
over killer app in native  FreeBSD ;-)-
but I would ask your friends who can judge that.

>=20
> --HPS
>=20


K.=

From nobody Thu Jul  7 21:26:18 2022
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 BA8AD3E3A98
	for ; Thu,  7 Jul 2022 21:27:54 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf8dj52Xzz3Dhb
	for ; Thu,  7 Jul 2022 21:27:53 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 267LQIK4093802
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 7 Jul 2022 14:26:18 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 267LQImf093801;
	Thu, 7 Jul 2022 14:26:18 -0700 (PDT)
	(envelope-from warlock)
Date: Thu, 7 Jul 2022 14:26:18 -0700
From: John Kennedy 
To: Klaus =?iso-8859-1?Q?K=FCchemann?= 
Cc: Hans Petter Selasky , freebsd-current@freebsd.org
Subject: Re: Accessibility in the FreeBSD installer and console
Message-ID: 
References: 
 <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.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: <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
X-Rspamd-Queue-Id: 4Lf8dj52Xzz3Dhb
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [0.21 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current];
	FREEMAIL_TO(0.00)[googlemail.com];
	RCVD_TLS_LAST(0.00)[];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[phouka.net];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jul 07, 2022 at 10:11:52PM +0200, Klaus Küchemann wrote:
> > Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
> > The only argument I've heard from some non-sighted friends about not using FreeBSD natively is that ooh, MacOSX is so cool. It starts speaking from the start if I press this and this key. Is anyone here working on or wanting such a feature?
> 
> Possibly they didn’t want to  be rude and your friends didn't tell you the other argument  :-)  : according to the corresponding wiki page FreeBSD doesn't natively support any audio output at all on your friends current M1 Mac hardware.
>  since quite nothing is currently supported you probably will first take over working on the Audio driver …..and of course USB  :-)

  I think a huge benefit that Apple would have is that they might be
able to guarantee some sort of audio speaker, period, since they
control the hardware that the software runs on.  That might be a big ask
on FreeBSD, but maybe if there was some relatively ubiqitous 

From nobody Thu Jul  7 21:41:59 2022
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 D92BD3E6A80
	for ; Thu,  7 Jul 2022 21:43:30 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116])
	(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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf8zk01VNz3GnK
	for ; Thu,  7 Jul 2022 21:43:29 +0000 (UTC)
	(envelope-from warlock@phouka1.phouka.net)
Received: from phouka1.phouka.net (localhost [127.0.0.1])
	by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 267Lg04O094185
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 7 Jul 2022 14:42:00 -0700 (PDT)
	(envelope-from warlock@phouka1.phouka.net)
Received: (from warlock@localhost)
	by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 267LfxUc094184;
	Thu, 7 Jul 2022 14:41:59 -0700 (PDT)
	(envelope-from warlock)
Date: Thu, 7 Jul 2022 14:41:59 -0700
From: John Kennedy 
To: Klaus =?iso-8859-1?Q?K=FCchemann?= 
Cc: Hans Petter Selasky , freebsd-current@freebsd.org
Subject: Re: Accessibility in the FreeBSD installer and console
Message-ID: 
References: 
 <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.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: <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
X-Rspamd-Queue-Id: 4Lf8zk01VNz3GnK
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net
X-Spamd-Result: default: False [0.20 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current];
	FREEMAIL_TO(0.00)[googlemail.com];
	RCVD_TLS_LAST(0.00)[];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[phouka.net];
	TO_DN_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jul 07, 2022 at 10:11:52PM +0200, Klaus Küchemann wrote:
> > Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
> > The only argument I've heard from some non-sighted friends about not using FreeBSD natively is that ooh, MacOSX is so cool. It starts speaking from the start if I press this and this key. Is anyone here working on or wanting such a feature?
> 
> Possibly they didn’t want to  be rude and your friends didn't tell you the other argument  :-)  : according to the corresponding wiki page FreeBSD doesn't natively support any audio output at all on your friends current M1 Mac hardware.
>  since quite nothing is currently supported you probably will first take over working on the Audio driver …..and of course USB  :-)

  I think a huge benefit that Apple would have is that they might be
able to guarantee some sort of audio speaker, period, since they
control the hardware that the software runs on.  That might be a big ask
on FreeBSD, but maybe if there was some relatively ubiquitous assistance
hardware, maybe doable.  But text-to-speech (and then WHAT language's
speech) is a big software chunk, audio layers seems large, and then
having to worry about the potential driver issues (while not being able
to see-to-hear any potential setup issues) seems huge.

  Everybody seems happy farming that out to the internet, except on
system setup you're not connected to the internet yet.

  Plus Apple has some deep hooks into the app-stack since you're
basically using their toolkit to make a graphical app, so they can
guarantee some potential for GUI-textbox-speech, where FreeBSD has a
hodgepodge of graphical toolkits (KDE, GTK, Gnome, etc).

From nobody Thu Jul  7 21:48:12 2022
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 3CC1B12A876C
	for ; Thu,  7 Jul 2022 21:48:29 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf95R68lyz3W9F
	for ; Thu,  7 Jul 2022 21:48:27 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id B10892623C7;
	Thu,  7 Jul 2022 23:48:19 +0200 (CEST)
Message-ID: 
Date: Thu, 7 Jul 2022 23:48:12 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: Accessibility in the FreeBSD installer and console
Content-Language: en-US
To: John Kennedy ,
 =?UTF-8?Q?Klaus_K=c3=bcchemann?= 
Cc: freebsd-current@freebsd.org
References: 
 <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Lf95R68lyz3W9F
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.29 / 15.00];
	NEURAL_HAM_SHORT(-0.99)[-0.988];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[phouka.net,googlemail.com];
	MLMMJ_DEST(0.00)[freebsd-current];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 7/7/22 23:26, John Kennedy wrote:
> On Thu, Jul 07, 2022 at 10:11:52PM +0200, Klaus Küchemann wrote:
>>> Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
>>> The only argument I've heard from some non-sighted friends about not using FreeBSD natively is that ooh, MacOSX is so cool. It starts speaking from the start if I press this and this key. Is anyone here working on or wanting such a feature?
>>
>> Possibly they didn’t want to  be rude and your friends didn't tell you the other argument  :-)  : according to the corresponding wiki page FreeBSD doesn't natively support any audio output at all on your friends current M1 Mac hardware.
>>   since quite nothing is currently supported you probably will first take over working on the Audio driver …..and of course USB  :-)
> 
>    I think a huge benefit that Apple would have is that they might be
> able to guarantee some sort of audio speaker, period, since they
> control the hardware that the software runs on.  That might be a big ask
> on FreeBSD, but maybe if there was some relatively ubiqitous

Hi,

Does Apple support voice-over in its bootloaders too? I think not, so at 
some point of technical breakage you will be stuck anyway - right?

--HPS

From nobody Thu Jul  7 21:49:10 2022
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 B81FD12A8F42
	for ; Thu,  7 Jul 2022 21:49:14 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf96K5c93z3WVv
	for ; Thu,  7 Jul 2022 21:49:13 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x636.google.com with SMTP id o25so34691023ejm.3
        for ; Thu, 07 Jul 2022 14:49:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=from:content-transfer-encoding:mime-version:subject:date:references
         :to:in-reply-to:message-id;
        bh=cntqu6nG36VUOaNfCYPnQC5z2w4+yHy5alxGtDEVkAg=;
        b=gtC/M/XuOdPUiN4U2kE6EwOdjGBBS1OpY+QV5XI7Arr5/6XVBcKeXUUfp3sxoKTWvr
         iLb0+FN7y+p8CBPY7YTo3tEfckx24HCGdUESh3dcpyvUfgzECSYwuXXyVudOVTmH9cii
         f19qK6nSsJrxR0O13fr1F3eWESNr5L8mI+eUZh0ZO4dM8sSCkzeBz7nJSuPHAVMMrL84
         xyAUGbqwQlqyLc1nCcpNuZNTJsIoB5+FZyay6zjTgtsla0SRPD4OVyXWSSokBjHEHsLx
         UJyMbIorRSHB+5qjK4QzgmnLYNZUQxoSmAvfELCjGCXS5Dj0RTropuYV5gESCGmk5h62
         bDAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:from:content-transfer-encoding:mime-version
         :subject:date:references:to:in-reply-to:message-id;
        bh=cntqu6nG36VUOaNfCYPnQC5z2w4+yHy5alxGtDEVkAg=;
        b=Z0uK70m8vd7Ou+GkO1GuYAhI1WEv9qVTyIvTWAytsW0NsH7zEbnOrVMOJuY+fkI2pS
         tFPuQxwekQau6mdihf0dd243cCIefNAjBAGZzXgAyubvb2XyFyMtjA/rWJlgP81XELcH
         PkWyuKWFf0yEIYUJr3IxcyKsix0KGRmQrIAGbLETbZxACtmy/+jihysaOOyDCU0pz4EO
         16hlsVEMlga4AVyPvg0alydZpUvYDbB5oZdcBlEJL8f8m+y9hE1SUebtTtwgT9mXyCu1
         rISrmr2ZOXEB6hoWkxVhZg9+v+q2OqK7CcbnWFvPURlIspTpnClLx5Li+J4tyTLs2jU0
         rAVA==
X-Gm-Message-State: AJIora81yrDMf5EaujgeeRFJPPnQx8pR9UvQvY4UFOqY89mtuU7c2jQx
	q7zUqgAIWSgaoGVl8XbFAsvuiszNGtx6cQ==
X-Google-Smtp-Source: AGRyM1u03rqSEfBMsae7c3eRarjrbm+r4pEc0ANWnk9ILCnCAMUx1qGy5lHWRNL8GWiKqQ195jp8+g==
X-Received: by 2002:a17:906:cc52:b0:72b:114e:c56c with SMTP id mm18-20020a170906cc5200b0072b114ec56cmr240470ejb.144.1657230552551;
        Thu, 07 Jul 2022 14:49:12 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-025-242.46.114.pool.telefonica.de. [46.114.25.242])
        by smtp.googlemail.com with ESMTPSA id k11-20020a1709062a4b00b00726abf9a32bsm15216848eje.138.2022.07.07.14.49.11
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 07 Jul 2022 14:49:12 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.100.31\))
Subject: Re: Accessibility in the FreeBSD installer and console
Date: Thu, 7 Jul 2022 23:49:10 +0200
References: 
 <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
 
To: John Kennedy ,
 Hans Petter Selasky ,
 freebsd-current@freebsd.org
In-Reply-To: 
Message-Id: <08A452AA-E8C1-4C7B-AD25-A2930EB03556@googlemail.com>
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4Lf96K5c93z3WVv
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b="gtC/M/Xu";
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-1.50 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N



> Am 07.07.2022 um 23:26 schrieb John Kennedy :
>=20
> On Thu, Jul 07, 2022 at 10:11:52PM +0200, Klaus K=C3=BCchemann wrote:
>>> Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
>>> The only argument I've heard from some non-sighted friends about not =
using FreeBSD natively is that ooh, MacOSX is so cool. It starts =
speaking from the start if I press this and this key. Is anyone here =
working on or wanting such a feature?
>>=20
>> Possibly they didn=E2=80=99t want to  be rude and your friends didn't =
tell you the other argument  :-)  : according to the corresponding wiki =
page FreeBSD doesn't natively support any audio output at all on your =
friends current M1 Mac hardware.
>> since quite nothing is currently supported you probably will first =
take over working on the Audio driver =E2=80=A6..and of course USB  :-)
>=20
>  I think a huge benefit that Apple would have is that they might be
> able to guarantee some sort of audio speaker, period, since they
> control the hardware that the software runs on.  That might be a big =
ask
> on FreeBSD, but maybe if there was some relatively ubiqitous=20
>=20
`found=20
< =E2=80=A2  Introduced tascodec(4), a driver for the TI TAS2770/TAS5770 =
digital audio amplifier codec found on Apple M1 Macs.
=09
=E2=80=A2 Introduced aplnco(4), a driver for the Numerically-controlled =
oscillator (NCO) clock which drives the audio clocks on Apple silicon.
>
in
https://www.openbsd.org/plus71.html

and for some stunning fun :

https://www.youtube.com/watch?v=3D2B-XwPjn9YY#t=3D03m17s =20
(start minute 3:17 )=20
:-)






From nobody Thu Jul  7 23:00:09 2022
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 3616812DE17D
	for ; Thu,  7 Jul 2022 23:00:14 +0000 (UTC)
	(envelope-from maciphone2@googlemail.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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LfBhF2v5jz3jCj
	for ; Thu,  7 Jul 2022 23:00:13 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ed1-x52d.google.com with SMTP id z41so24952720ede.1
        for ; Thu, 07 Jul 2022 16:00:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=from:content-transfer-encoding:mime-version:subject:date:references
         :to:in-reply-to:message-id;
        bh=wg2yRMNMDfXKzIpaNWehUzuDg/2UpSzTwMda8uQYgPE=;
        b=f+4JChN8PGuRWlSpXSWMRa7RoXOpN6FteR99ReogbXYsPsfXdWvyO+EdiYV5quMtNd
         s39m5Dtjds34q4FtHUBUyuxA3N3DE+qTOZSzI1wORdLdznKoERs9bfE0TfoZN36VA0K2
         yrDpToQNio02bgBJN1v2kV2DFB4Y/bnsLJO9ghHRNXREKOK/uR/Ls15+ITGWihSzR+Nn
         C2xveGmWUfhR5scfgY4LWE57E6s1aVS7vWxAiejkSv7EQg6lCd1b2J9qsZPdw40pKui2
         eEFsg3Mj95mypi5Ja4KCnd4z2mCvSGckDJo5uklwZBZlwuttsPZTNPCGtKPT6BzU0wEm
         A9Ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:from:content-transfer-encoding:mime-version
         :subject:date:references:to:in-reply-to:message-id;
        bh=wg2yRMNMDfXKzIpaNWehUzuDg/2UpSzTwMda8uQYgPE=;
        b=KPws07ci2Jt1Tk47QkNv5Wehkr0ies9e1XKCfoX1yHNsG29sPXakRfRWdrNoPreRni
         k6WmCa+0qBKcA7v2xE8tuI3uaeEbaKPswOV8bkB/9ckVPA2z9Bj8x/yTjSvWaPyRYDUS
         X4HGHVZS3Wa96Rr/2EZbPL81zOLrHd+2U0eGhG5N6AnpFin99L3x2A5u/B2fWQmxEuK1
         H54Driv1Voty9YyofsZRHvx3xJX07LN/2x9hLnDoxu0/ocQg/a3g8pErPVjNPKv1+QNq
         3rEr2L3azNevsmOhMSgcNXiFfRXTALlB8HMJIb4bhIdDbiqLK4BjTxn8bcj3h6tNedB3
         whDQ==
X-Gm-Message-State: AJIora8b0czfYWIzC51TswyRrw1COJ5++OUqDPgVqYoNYTRyGlMulZ5b
	+jYcwGJ25eA6v5X6CsK/u+r+vQ6IVWS5EQ==
X-Google-Smtp-Source: AGRyM1vAK8Mae9ihZuHSONTvdvnFLZd9AoMEJJ4IYPAS8z4b5jxHlwyrDaQ0qkCYHzVYz/azYS+lDA==
X-Received: by 2002:aa7:db09:0:b0:43a:7353:94a6 with SMTP id t9-20020aa7db09000000b0043a735394a6mr629069eds.191.1657234811297;
        Thu, 07 Jul 2022 16:00:11 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-025-242.46.114.pool.telefonica.de. [46.114.25.242])
        by smtp.googlemail.com with ESMTPSA id u1-20020a1709061da100b0072b1e27888asm572799ejh.50.2022.07.07.16.00.10
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 07 Jul 2022 16:00:10 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.100.31\))
Subject: Re: Accessibility in the FreeBSD installer and console
Date: Fri, 8 Jul 2022 01:00:09 +0200
References: 
 <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
 
 
To: Hans Petter Selasky ,
 John Kennedy ,
 freebsd-current@freebsd.org
In-Reply-To: 
Message-Id: <011CA96A-75B1-4077-A0AB-AFB7F4F851AA@googlemail.com>
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4LfBhF2v5jz3jCj
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=f+4JChN8;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-1.48 / 15.00];
	NEURAL_HAM_SHORT(-0.98)[-0.975];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52d:from];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N



> Am 07.07.2022 um 23:48 schrieb Hans Petter Selasky :
>=20
> On 7/7/22 23:26, John Kennedy wrote:
>> On Thu, Jul 07, 2022 at 10:11:52PM +0200, Klaus K=C3=BCchemann wrote:
>>>> Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
>>>> The only argument I've heard from some non-sighted friends about =
not using FreeBSD natively is that ooh, MacOSX is so cool. It starts =
speaking from the start if I press this and this key. Is anyone here =
working on or wanting such a feature?
>>>=20
>>> Possibly they didn=E2=80=99t want to  be rude and your friends =
didn't tell you the other argument  :-)  : according to the =
corresponding wiki page FreeBSD doesn't natively support any audio =
output at all on your friends current M1 Mac hardware.
>>>  since quite nothing is currently supported you probably will first =
take over working on the Audio driver =E2=80=A6..and of course USB  :-)
>>   I think a huge benefit that Apple would have is that they might be
>> able to guarantee some sort of audio speaker, period, since they
>> control the hardware that the software runs on.  That might be a big =
ask
>> on FreeBSD, but maybe if there was some relatively ubiqitous
>=20
> Hi,
>=20
> Does Apple support voice-over in its bootloaders too? I think not, so =
at some point of technical breakage you will be stuck anyway - right?
>=20
> =E2=80=94HPS

 good point =E2=80=A6 ( I think you mean feature textToSpeech when e.g. =
keyboard-interrupting into the fbsd-boot prompt in native Mac boot)

But implementing text to speech in native u-boot/uefi & FreeBSD =
bootloader on a Mac?=20
..sounds like a huge project after having FreeBSD natively ported to =
Apple M1/M2..
But if that=E2=80=99s on your list I would not underestimate you :-)

...of course you would have VoiceOver/TextToSpeech e.g. in a uart- shell =
console when booting FreeBSD native on another board/machine=E2=80=A6and =
that seems to be the easiest way  for non-sighted FreeBSD =
users/developers using the Mac platform  for VoiceOver who want to use =
fbsd-current native( those who are interested in  bootloader issues;-)

If you meant VoiceOver in MacOS bootloader : Macusers expect their Macs =
problem-free, a special world, unknown in FreeBSD:-)
There are exceptions, e.g. if you use a new MacOS on an older =
unsupported Mac - but VoiceOver wouldn=E2=80=99t help much there ;-)

K.





From nobody Fri Jul  8 03:40:35 2022
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 0EECE17F9A75
	for ; Fri,  8 Jul 2022 03:40:50 +0000 (UTC)
	(envelope-from tdtemccna@gmail.com)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LfJw05l3Xz3HMx
	for ; Fri,  8 Jul 2022 03:40:48 +0000 (UTC)
	(envelope-from tdtemccna@gmail.com)
Received: by mail-lf1-x132.google.com with SMTP id t24so34333142lfr.4
        for ; Thu, 07 Jul 2022 20:40:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=8xJ8IcBBIT3JeoHeCw8Y859jfJFsHVHRzFFy4dkP5lE=;
        b=oWZRSCKOUJaMdeQfjmvgbxDvvWraNvyVfAOFC/1gILj9oeoWepmOtYJfkO5boHa/3y
         m5WUergMbXJ7fDw8qXpNzWpZwgmBlQXMCP8nkBCdrkYs/OQqpt+dbmRBfhp6KBgNF8vb
         QsziIrixifk6YnlkdF/z87Vy8hE4QK7S9E3qDb+0Ecco/XbDjCZ0pR7a4P0fns53QsWl
         +eGXqdTN4Syp/t1tdG2aiKGrkLr78marpeDjor1AmOPUqkL5AzzXtda+FRzbooLQYdch
         yUSk8QU412zsYtKEQmZkSjPnAKhGcS9swev1wYaoAmZedA1f1TiqdNE+SWcpCT4EJK4i
         PKVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=8xJ8IcBBIT3JeoHeCw8Y859jfJFsHVHRzFFy4dkP5lE=;
        b=zwSt8Tvnhkunw56nyPdcIS/IpvnmhDSzIAZ7dRSt9xjAjYWmm3uH9tszWjarnNYhk4
         DASycb+84cP4NQjxr5M7g651KMU5W5CB+xb7+T3FGqUoaqi5MXhaFpGK8DgjXgvGn6uU
         mADGfBJ6W08Q+A7V7LZpHpU188HV2/RX5Tfb1S4BjJwtvdyX7QWEGaAbPuES0S0rSWgg
         kCejZUt5ig+cOLvmv1/xA1OSGcxsv717b7Cyoo26h1U4Vc+2Y/RRALL1JaB/RWV9lLMB
         28vndVA+kuaZyhJwM4/nycuHsA3+0Eq79VCmNzcATcX0cwqvnaD1C2tczYIGsAm2+Pv6
         8EBA==
X-Gm-Message-State: AJIora98gbPvjjuSEpYiYoaWQ8gAcanXK1/99llSBadILDYBKEFi1nRy
	dYVLZQsuT9acKW4s5AdeYgADxvoNfM6fIgV8hmsIN4KVyoU=
X-Google-Smtp-Source: AGRyM1v5rH24jQsjtGhYpGvuJHrjdjJxtk8/CKcTBA0YlMM9X1zem5BSXArSrQlriW5vYNUW7Qet4y+tuD/eb9mHb6U=
X-Received: by 2002:a05:6512:3f12:b0:47f:51de:d067 with SMTP id
 y18-20020a0565123f1200b0047f51ded067mr935573lfa.146.1657251647127; Thu, 07
 Jul 2022 20:40:47 -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: 
 <30f3012d-818b-d828-da02-554b19e01fab@selasky.org>
In-Reply-To: <30f3012d-818b-d828-da02-554b19e01fab@selasky.org>
From: Turritopsis Dohrnii Teo En Ming 
Date: Fri, 8 Jul 2022 11:40:35 +0800
Message-ID: 
Subject: Re: FreeBSD is a great operating system!
To: Hans Petter Selasky 
Cc: freebsd-current@freebsd.org, ceo@teo-en-ming-corp.com
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4LfJw05l3Xz3HMx
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=oWZRSCKO;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of tdtemccna@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) smtp.mailfrom=tdtemccna@gmail.com
X-Spamd-Result: default: False [-0.22 / 15.00];
	NEURAL_SPAM_SHORT(0.78)[0.777];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_TLS_LAST(0.00)[];
	SUBJECT_ENDS_EXCLAIM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::132:from];
	MLMMJ_DEST(0.00)[freebsd-current];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

Dear Hans Petter Selasky,

Why do you say FreeBSD license is a killer?

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

On Wed, 6 Jul 2022 at 16:13, Hans Petter Selasky  wrote:
>
> On 7/6/22 10:07, Turritopsis Dohrnii Teo En Ming wrote:
> > Subject: FreeBSD is a great operating system!
> >
> > Good day from Singapore,
> >
> > I think FreeBSD is a great operating system! I support FreeBSD because
> > the most popular pfSense firewall, the extremely popular OPNsense
> > firewall and the BSD Router Project are all powered by FreeBSD! macOS
> > is also based on FreeBSD!
> >
> > I use pfSense community edition firewall in my home. I am planning to
> > try out OPNsense firewall next.
> >
> > I will continue to support FreeBSD! It is a great operating system!
> > FreeBSD is a very good network operating system.
> >
> > Regards,
> >
> > Mr. Turritopsis Dohrnii Teo En Ming
> > Targeted Individual in Singapore
> > 6 July 2022 Wed
> > Blogs:
> > https://tdtemcerts.blogspot.com
> > https://tdtemcerts.wordpress.com
>
> ...
>
> And its license is a killer!
>
> --HPS
>

From nobody Fri Jul  8 10:53:44 2022
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 6D59317D3531
	for ; Fri,  8 Jul 2022 10:53:55 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LfVWk4j2mz3Fj7
	for ; Fri,  8 Jul 2022 10:53:54 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 09CE426029F;
	Fri,  8 Jul 2022 12:53:51 +0200 (CEST)
Message-ID: <187490b5-fa8a-eb70-edfc-4e5c190db03d@selasky.org>
Date: Fri, 8 Jul 2022 12:53:44 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: Accessibility in the FreeBSD installer and console
Content-Language: en-US
To: =?UTF-8?Q?Klaus_K=c3=bcchemann?= ,
 John Kennedy , freebsd-current@freebsd.org,
 Peter Laursen 
References: 
 <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
 
 
 <011CA96A-75B1-4077-A0AB-AFB7F4F851AA@googlemail.com>
From: Hans Petter Selasky 
In-Reply-To: <011CA96A-75B1-4077-A0AB-AFB7F4F851AA@googlemail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LfVWk4j2mz3Fj7
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.80 / 15.00];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current];
	FREEMAIL_TO(0.00)[googlemail.com,phouka.net,freebsd.org,gmail.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	TAGGED_RCPT(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

Here is the complete patch for Voice-Over in the FreeBSD console:

https://reviews.freebsd.org/D35754

You need to install espeak from pkg and then install the 
/etc/devd/accessibility.conf file and then run sysctl 
kern.vt.accessibility.enable=1 after booting the new kernel.

It is freaking awesome!

There might be some bugs, but it worked fine for me!

--HPS

From nobody Fri Jul  8 10:56:59 2022
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 8446F17D4275
	for ; Fri,  8 Jul 2022 10:57:09 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4LfVbS2bjZz3Gkf
	for ; Fri,  8 Jul 2022 10:57:08 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 96FE726029F;
	Fri,  8 Jul 2022 12:57:06 +0200 (CEST)
Message-ID: 
Date: Fri, 8 Jul 2022 12:56:59 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: FreeBSD is a great operating system!
Content-Language: en-US
To: Turritopsis Dohrnii Teo En Ming 
Cc: freebsd-current@freebsd.org, ceo@teo-en-ming-corp.com
References: 
 <30f3012d-818b-d828-da02-554b19e01fab@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LfVbS2bjZz3Gkf
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.995];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	MLMMJ_DEST(0.00)[freebsd-current];
	FREEMAIL_TO(0.00)[gmail.com];
	R_DKIM_NA(0.00)[];
	SUBJECT_ENDS_EXCLAIM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 7/8/22 05:40, Turritopsis Dohrnii Teo En Ming wrote:
> Dear Hans Petter Selasky,
> 
> Why do you say FreeBSD license is a killer?

Because you can do anything you want with the operating system :-)

--HPS

From nobody Fri Jul  8 12:18:59 2022
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 502583E1AD3
	for ; Fri,  8 Jul 2022 12:19:05 +0000 (UTC)
	(envelope-from se@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LfXQ11llQz3Rqp;
	Fri,  8 Jul 2022 12:19:05 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657282745;
	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=fljR+PL2boQE+dnl9q20O8bpnlV1Mq9ocNdx0eyyZgs=;
	b=f5P4wGMBs5k23uQsegrQFyKb6YT+owAl3qTfh4nIfniAoP34HqdSMbnq9oflG6kV/+2ZXW
	30N60SEvIZ3JWLlYMKZsiwXj/52JYRuCFw0uwkMcjKjOHVHw7gsGXzUGd0Gujx8w5EHroK
	+m/XS8JdMACv6u1NTVCg6DVW4TUJT7P0rHKT7GVx+IhdqU3r4aNhsAcM9KpocWva5tS8/H
	2ZnpbOHg9z2bhLKKZtlgB1tSoemB6nnwQu6/e1BhfjLuJdPNRomxPvJ47/IgK5pv6H5DuS
	FgjbaPceWKkiDqgeQkjOIbunub4XfpkmWfGxwX1RwuTYB43EpLhhBJrqCS/F1Q==
Received: from [IPV6:2003:cd:5f17:a800:b4df:6ad0:77d8:8c18] (p200300cd5f17a800b4df6ad077d88c18.dip0.t-ipconnect.de [IPv6:2003:cd:5f17:a800:b4df:6ad0:77d8:8c18])
	(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: se/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LfXQ02LZFzt8R;
	Fri,  8 Jul 2022 12:19:04 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
Message-ID: 
Date: Fri, 8 Jul 2022 14:18:59 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.0.1
From: Stefan Esser 
Subject: Re: Accessibility in the FreeBSD installer and console
Content-Language: de-DE, en-US
To: Hans Petter Selasky ,
 =?UTF-8?Q?Klaus_K=c3=bcchemann?= ,
 John Kennedy , Peter Laursen 
References: 
 <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
 
 
 <011CA96A-75B1-4077-A0AB-AFB7F4F851AA@googlemail.com>
 <187490b5-fa8a-eb70-edfc-4e5c190db03d@selasky.org>
Cc: FreeBSD CURRENT 
In-Reply-To: <187490b5-fa8a-eb70-edfc-4e5c190db03d@selasky.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------tXfwM0MzlbBMt7zGMHILHfKA"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657282745;
	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=fljR+PL2boQE+dnl9q20O8bpnlV1Mq9ocNdx0eyyZgs=;
	b=QKncXfLRsJVhxHcvqnDCvpTD3ays9xeSAam8ngFjBjiAtBjt9K9q9Utfi3x+n3mUO5zkLK
	0LhTfDu3UrqjYI3982D0qQbXhWJlGNhDb38E8eVA8cMLbpgfg9hQtpNTn4oknYZpFpK5ag
	XxYI2N/v5mtOvQgCspmBf2KhzAdqPi479H0vpzeRQ4V/BIymY/tPgvWcJYD9mn0f9+jMoS
	YvMi2lhFfehbIxykDId1cyeGCRB5SWj0BzXaj1O7i11HM9wyFBQqsVF9x12TVcJDgkCABC
	v5D2GaUfs4vYywG5Dz+EV39rRD4cJ2Q8Lndwy+Se5aRi22WVqljZEuE51caanA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657282745; a=rsa-sha256; cv=none;
	b=F/xzhy5ENFhqm9cIMumeNndxVsczWWd7on8eLktdk5hIj2cx5pXlsIF0ZqPa8nCFMnK+Qq
	Sra+nd3Razq+XavWgQO0g/FP+MylkKiBNBVK+1ElvVYbOFqizQoxAzHe/3HoGUbIPaw2mo
	yb16mIYhsAtl+Qwa188lasSvpMzl/TdYimEE4y9jy2oV8GM37Ha2xLqCdDUGVpfIu6bKL0
	ksI5q+egAxRrp3Pcvsc0cxIXn0oLAOIzXqJMx1+frU/ysy3HElzN4g/trZY085tnStJK4i
	cNZT+vF5SJ9KX2qz7miF182GlpsVv8XZP/iMdaX3qnkFkHDQPmCc5OMNB6RtoQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------tXfwM0MzlbBMt7zGMHILHfKA
Content-Type: multipart/mixed; boundary="------------sK0pFbq0cQSNqAR82BWUbvSW";
 protected-headers="v1"
From: Stefan Esser 
To: Hans Petter Selasky ,
 =?UTF-8?Q?Klaus_K=c3=bcchemann?= ,
 John Kennedy , Peter Laursen 
Cc: FreeBSD CURRENT 
Message-ID: 
Subject: Re: Accessibility in the FreeBSD installer and console
References: 
 <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
 
 
 <011CA96A-75B1-4077-A0AB-AFB7F4F851AA@googlemail.com>
 <187490b5-fa8a-eb70-edfc-4e5c190db03d@selasky.org>
In-Reply-To: <187490b5-fa8a-eb70-edfc-4e5c190db03d@selasky.org>

--------------sK0pFbq0cQSNqAR82BWUbvSW
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

QW0gMDguMDcuMjIgdW0gMTI6NTMgc2NocmllYiBIYW5zIFBldHRlciBTZWxhc2t5Og0KPiBI
aSwNCj4gDQo+IEhlcmUgaXMgdGhlIGNvbXBsZXRlIHBhdGNoIGZvciBWb2ljZS1PdmVyIGlu
IHRoZSBGcmVlQlNEIGNvbnNvbGU6DQo+IA0KPiBodHRwczovL3Jldmlld3MuZnJlZWJzZC5v
cmcvRDM1NzU0DQo+IA0KPiBZb3UgbmVlZCB0byBpbnN0YWxsIGVzcGVhayBmcm9tIHBrZyBh
bmQgdGhlbiBpbnN0YWxsIHRoZSANCj4gL2V0Yy9kZXZkL2FjY2Vzc2liaWxpdHkuY29uZiBm
aWxlIGFuZCB0aGVuIHJ1biBzeXNjdGwgDQo+IGtlcm4udnQuYWNjZXNzaWJpbGl0eS5lbmFi
bGU9MSBhZnRlciBib290aW5nIHRoZSBuZXcga2VybmVsLg0KPiANCj4gSXQgaXMgZnJlYWtp
bmcgYXdlc29tZSENCj4gDQo+IFRoZXJlIG1pZ2h0IGJlIHNvbWUgYnVncywgYnV0IGl0IHdv
cmtlZCBmaW5lIGZvciBtZSENCg0KVGhlIGVzcGVhayBwb3J0IGlzIG1hcmtlZCBmb3IgZGVs
ZXRpb24gb24gMjAyMi0wNi0zMCAoYnV0IGhhcw0Kbm90IGJlZW4gZGVsZXRlZCwgeWV0KToN
Cg0KREVQUkVDQVRFRD0gICAgIExhc3QgcmVsZWFzZSBpbiAyMDE0IGFuZCBkZXByZWNhdGVk
IHVwc3RyZWFtDQpFWFBJUkFUSU9OX0RBVEU9MjAyMi0wNi0zMA0KDQpUaGVyZSBpcyBlc3Bl
YWstbmcsIHdoaWNoIHRvb2sgb3ZlciB0aGUgc291cmNlcywgYW5kIEkgaGF2ZQ0KcHJlcGFy
ZWQgYSBwb3J0IHVwZGF0ZS4NCg0KSSBoYWQgYXNrZWQgYSBtZW1iZXIgb2YgdGhlIHBvcnRt
Z3IgdGVhbSB3aGV0aGVyIGl0IHdvdWxkIGJlDQpwcmVmZXJyZWQgaWYgdGhlIGVzcGVhayBw
b3J0IHdhcyB1cGRhdGVkIHRvIHVzZSBzb3VyY2VzIGZyb20NCnRoZSBlc3BlYWstbmcgcmVw
b3NpdG9yeSAodGhlIHZlcnNpb24gbnVtYmVycyBjb250aW51ZSBmcm9tDQp0aGUgbGFzdCBl
c3BlYWsgcmVsZWFzZSksIG9yIHdoZXRoZXIgaWYgSSBzaG91bGQgY3JlYXRlIGEgbmV3DQpw
b3J0IGZvciBlc3BlYWstbmcuDQoNCkJ1dCBJIGhhdmUgbm90IGdvdCBhbnkgcmVzcG9uc2Ug
b24gdGhhdCBxdWVzdGlvbiAuLi4NCg0KVGhlIGN1cnJlbnQgc3RhdHVzIG9mIHRoZSBlc3Bl
YWstbmcgcG9ydCBpcyB0aGF0IGl0IGdlbmVyYXRlcw0KV0FWIG91dHB1dCwgYnV0IGl0IGRv
ZXMgbm90IHdvcmsgd2l0aCB0aGUgc291bmQgc3lzdGVtIGluDQpGcmVlQlNELCBhbnltb3Jl
Lg0KDQpUaGUgMiBzb3VuZCBvcHRpb25zIGF2YWlsYWJsZSBpbiB0aGUgZXNwZWFrIHBvcnQg
c2VlbSB0byBubw0KbG9uZ2VyIGJlIHN1cHBvcnRlZC4NCg0KSSBkaWQgbm90IGhhdmUgdGlt
ZSB0byBsb29rIGludG8gdGhpcyBpc3N1ZSwgYnV0IEkgZG8gYXNzdW1lDQp0aGF0IHRoZSBz
b3VuZCBvdXRwdXQgZnJvbSB0aGUgb2xkIGVzcGVhayBjb2RlIGNvdWxkIGVhc2lseQ0KYmUg
cmVzdG9yZWQgaW4gZXNwZWFrLW5nLg0KDQpSZWdhcmRzLCBTVGVmYW4NCg0KUFM6IEEgY29t
cHJlc3NlZCB0YXIgb2YgdGhlIFdJUCBlc3BlYWstbmcgcG9ydCBpcyBhdHRhY2hlZCwNCiAg
ICAgaW4gY2FzZSB5b3UgYXJlIGludGVyZXN0ZWQuIEkgZXhwZWN0IGl0IHRvIGJlIHN0cmlw
cGVkDQogICAgIG9mZiBpbiB0aGUgbWFpbCBsaXN0IC4uLg0K

--------------sK0pFbq0cQSNqAR82BWUbvSW--

--------------tXfwM0MzlbBMt7zGMHILHfKA
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmLIILMFAwAAAAAACgkQR+u171r99USQ
sQgAy1Bm/JB3FsbvH0QDt2GDihKvJxVjzxbfm/j2ZIX9gB49a5a7eSCG0Gz1KQisFGo4TnRbOTx7
1QDbAL0/gDA4V7ihOX9TFScWbM/KU52/fhRu9bIPA1Pyg+pMlWjPS6m9X7QP0oB+A4Mzc+DZG3hA
/EMkQNCSkMn5O7c5YZyPHaZSrr0mNIyXhBBY1Xm0AMDoMfNBcaQD89YeRpgkgbQcNN28HkNRcDPt
E1RUTAKHMcaI9l3wul9wUiw2rRVDJukLw5KbWdhzyOX3KfRmeTTr1uvko8XfNdcUBVcZYAGMsJyj
VW2fTmAOIXc/2Crqmt/KCfPCPa0n61cLhI0tPuIoBA==
=yUfR
-----END PGP SIGNATURE-----

--------------tXfwM0MzlbBMt7zGMHILHfKA--

From nobody Fri Jul  8 12:32:37 2022
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 D9BB73E49C2
	for ; Fri,  8 Jul 2022 12:32:49 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LfXjr36l0z3V58
	for ; Fri,  8 Jul 2022 12:32:48 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 268CWbiY007116;
	Fri, 8 Jul 2022 21:32:38 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Fri, 8 Jul 2022 21:32:37 +0900
From: Tomoaki AOKI 
To: Hans Petter Selasky 
Cc: Turritopsis Dohrnii Teo En Ming ,
        freebsd-current@freebsd.org, ceo@teo-en-ming-corp.com
Subject: Re: FreeBSD is a great operating system!
Message-Id: <20220708213237.e4b2bbcec506e9549996a12f@dec.sakura.ne.jp>
In-Reply-To: 
References: 
	<30f3012d-818b-d828-da02-554b19e01fab@selasky.org>
	
	
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LfXjr36l0z3V58
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [-1.35 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.75)[-0.751];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org,teo-en-ming-corp.com];
	FROM_EQ_ENVFROM(0.00)[];
	SUBJECT_ENDS_EXCLAIM(0.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	R_DKIM_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[sakura.ne.jp];
	RCPT_COUNT_THREE(0.00)[4];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, 8 Jul 2022 12:56:59 +0200
Hans Petter Selasky  wrote:

> On 7/8/22 05:40, Turritopsis Dohrnii Teo En Ming wrote:
> > Dear Hans Petter Selasky,
> > 
> > Why do you say FreeBSD license is a killer?
> 
> Because you can do anything you want with the operating system :-)
> 
> --HPS

Plus, unlike GPL, you don't need to make open-source what you modified.

This should be a killer who uses NDA'ed codes in conjunction with
BSD-licensed codes.
In these cases, you SHALL make open-source under GPL whole NDA'ed code
if you use GPL'ed codes. BSD-licensed codes does nothing harmful.

-- 
Tomoaki AOKI    

From nobody Fri Jul  8 12:34:46 2022
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 1E2693E565F
	for ; Fri,  8 Jul 2022 12:34:50 +0000 (UTC)
	(envelope-from theraven@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LfXmB0N6fz3W56
	for ; Fri,  8 Jul 2022 12:34:50 +0000 (UTC)
	(envelope-from theraven@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657283690;
	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=R1JJw9+XDnBsLZExURZNgDbwp2RoSwjd3bWMVdtF5bs=;
	b=Go9RSlwgXvsss1vk5IegnBxIuySz2dR0oYtxhubzSIDkmhRqDU4ky1c9oEWZyZUTAVHi7k
	CcwLNVPx2EFOB9WHigN6zgV0mZpk8+gcCNNPq5Iy6v5VHOtxR1aX2SNAIjAxN0whAdOr/m
	dIBfeWCNs2sJtLdW+TRtARgMy6R5M+t/6659GNVietBPX/KdoUTLtZAYlrQnvQcOVX6C+2
	P5h+cW4qzBaHM+39cQrwaFajw/IJWu3YfB7G+LrkbsC0s1ohaCvgwY4KwRmtp84PmQEjgb
	9XJ4n31noj0W1XJ82v+MrWvltnX1vv94fkHyaDeJPiq3DoHKbbkMCKnqXPUG7g==
Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195])
	(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: theraven)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LfXm96MzSzt9k
	for ; Fri,  8 Jul 2022 12:34:49 +0000 (UTC)
	(envelope-from theraven@FreeBSD.org)
Received: from [192.168.1.212] (host86-136-0-178.range86-136.btcentralplus.com [86.136.0.178])
	by smtp.theravensnest.org (Postfix) with ESMTPSA id DE0C931C91
	for ; Fri,  8 Jul 2022 13:34:48 +0100 (BST)
Message-ID: <5df6bdb3-20f3-094f-8fc2-a20368535a09@FreeBSD.org>
Date: Fri, 8 Jul 2022 13:34:46 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: Accessibility in the FreeBSD installer and console
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: 
 <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
 
 
 <011CA96A-75B1-4077-A0AB-AFB7F4F851AA@googlemail.com>
 <187490b5-fa8a-eb70-edfc-4e5c190db03d@selasky.org>
 
From: David Chisnall 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657283690;
	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=R1JJw9+XDnBsLZExURZNgDbwp2RoSwjd3bWMVdtF5bs=;
	b=LwJX06NZvxBW3DtmkBG4VWx8ZcSMb4/oEKa3osHWZSNnwn8sHYUXqmKAb+PX7fIKp/zppi
	HFjtSFBlgfgcjFHpv/9hiVeVaQHs6YpW7Iumr6iTqxohhZtVlPJhY3n7ng2ofUp04YfOnu
	9QS4+odBrbe/3u1qzr9Y26FROzomOFNdbYTAm55B0/xokqoFS8dzeLY+xFcbj/e9hvMo2/
	M0VT65COsVdJ4NufJiB+4DQSXaeA0EJOrja7oGgFVTkULZt4JXxQIpSzqa6srbZ3/0izxT
	xCaL0pNDRRSYPc0ybj2HLze8aHKH1VVgjdM0AY1HRQ36ZnjVxA2tBJlgA4A8Zw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657283690; a=rsa-sha256; cv=none;
	b=oxUukdIF1jwbFcMY+VbtLtPs6elyUSc+cf/pP88vJlf256nXo5jdpBvl6sIb59ZLjuNdXX
	8WxozJIcTGW3VxbZSAtqA1z1ZrD0VA7VD95unYPVk3VsMvZFmMR2bvkJF5UXTRsO2UqjFE
	108uTTp85SggRcE/32RI26CS/lApg1l7gNLl7ctnKwZFun0PBnFjOIe1vgqTxyw/2L1tM/
	1DP3kTxtqaSFOinGSMuEg874eZAyn/RLxqXfiEiC+UKBrJJby4yi4ch1vmJX+BmE5IY9ZM
	BHd6pzM5T3DecQOMABMhbgMO216hpJWwKAzImrXw5N4hwWb3cSJVGJvHHGdpLw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 08/07/2022 13:18, Stefan Esser wrote:
> Am 08.07.22 um 12:53 schrieb Hans Petter Selasky:
>> Hi,
>>
>> Here is the complete patch for Voice-Over in the FreeBSD console:
>>
>> https://reviews.freebsd.org/D35754
>>
>> You need to install espeak from pkg and then install the 
>> /etc/devd/accessibility.conf file and then run sysctl 
>> kern.vt.accessibility.enable=1 after booting the new kernel.
>>
>> It is freaking awesome!
>>
>> There might be some bugs, but it worked fine for me!
> 
> The espeak port is marked for deletion on 2022-06-30 (but has
> not been deleted, yet):
> 
> DEPRECATED=     Last release in 2014 and deprecated upstream
> EXPIRATION_DATE=2022-06-30
> 
> There is espeak-ng, which took over the sources, and I have
> prepared a port update.

Many years ago, I added the speech synthesis APIs from OS X to GNUstep 
using flite:

https://www.freshports.org/audio/flite/

flite it small (the port contains separate .so and .a files for each 
voice, a minimal version needs only one), has no dependencies outside of 
the base system, and is permissively licensed.  I haven't used it for a 
while (apparently it's had a new major release since I last did), but I 
was happily using it for text-to-speech on FreeBSD 10-15 years ago and 
it is still in ports.

David

From nobody Fri Jul  8 12:41:00 2022
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 BB4913E6DA4
	for ; Fri,  8 Jul 2022 12:41:11 +0000 (UTC)
	(envelope-from jamie@catflap.org)
Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1])
	by mx1.freebsd.org (Postfix) with ESMTP id 4LfXvV6Yzpz3XMY
	for ; Fri,  8 Jul 2022 12:41:10 +0000 (UTC)
	(envelope-from jamie@catflap.org)
X-Catflap-Envelope-From: 
X-Catflap-Envelope-To: freebsd-current@FreeBSD.org
Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49])
	by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 268Cf3SG053226;
	Fri, 8 Jul 2022 13:41:03 +0100 (BST)
	(envelope-from jamie@donotpassgo.dyslexicfish.net)
Received: (from jamie@localhost)
	by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 268Cf00N053209;
	Fri, 8 Jul 2022 13:41:00 +0100 (BST)
	(envelope-from jamie)
From: Jamie Landeg-Jones 
Message-Id: <202207081241.268Cf00N053209@donotpassgo.dyslexicfish.net>
Date: Fri, 08 Jul 2022 13:41:00 +0100
Organization: Dyslexic Fish
To: tdtemccna@gmail.com, hps@selasky.org
Cc: freebsd-current@FreeBSD.org, ceo@teo-en-ming-corp.com
Subject: Re: FreeBSD is a great operating system!
References: 
 <30f3012d-818b-d828-da02-554b19e01fab@selasky.org>
 
 
In-Reply-To: 
User-Agent: Heirloom mailx 12.4 7/29/08
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Fri, 08 Jul 2022 13:41:03 +0100 (BST)
X-Rspamd-Queue-Id: 4LfXvV6Yzpz3XMY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=catflap.org;
	spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org
X-Spamd-Result: default: False [-3.70 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[catflap.org,none];
	R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_NO_TLS_LAST(0.10)[];
	SUBJECT_ENDS_EXCLAIM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com,selasky.org];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MIME_TRACE(0.00)[0:+];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[jamie];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	HAS_ORG_HEADER(0.00)[];
	TO_DN_NONE(0.00)[];
	ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]
X-ThisMailContainsUnwantedMimeParts: N

Hans Petter Selasky  wrote:

> On 7/8/22 05:40, Turritopsis Dohrnii Teo En Ming wrote:
> > Dear Hans Petter Selasky,
> > 
> > Why do you say FreeBSD license is a killer?
>
> Because you can do anything you want with the operating system :-)

"is a killer" could easily have been taken as a negative!

Gotta love our English language!

From nobody Fri Jul  8 12:46:58 2022
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 6C06312A8E55
	for ; Fri,  8 Jul 2022 12:47:07 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4LfY2L6TVGz3Z9t;
	Fri,  8 Jul 2022 12:47:06 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 757AD26007D;
	Fri,  8 Jul 2022 14:47:05 +0200 (CEST)
Message-ID: <6be49060-6e16-275a-f2b3-89dcb0590472@selasky.org>
Date: Fri, 8 Jul 2022 14:46:58 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: Accessibility in the FreeBSD installer and console
Content-Language: en-US
To: David Chisnall , freebsd-current@freebsd.org
References: 
 <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
 
 
 <011CA96A-75B1-4077-A0AB-AFB7F4F851AA@googlemail.com>
 <187490b5-fa8a-eb70-edfc-4e5c190db03d@selasky.org>
 
 <5df6bdb3-20f3-094f-8fc2-a20368535a09@FreeBSD.org>
From: Hans Petter Selasky 
In-Reply-To: <5df6bdb3-20f3-094f-8fc2-a20368535a09@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LfY2L6TVGz3Z9t
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	MLMMJ_DEST(0.00)[freebsd-current];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 7/8/22 14:34, David Chisnall wrote:
> On 08/07/2022 13:18, Stefan Esser wrote:
>> Am 08.07.22 um 12:53 schrieb Hans Petter Selasky:
>>> Hi,
>>>
>>> Here is the complete patch for Voice-Over in the FreeBSD console:
>>>
>>> https://reviews.freebsd.org/D35754
>>>
>>> You need to install espeak from pkg and then install the 
>>> /etc/devd/accessibility.conf file and then run sysctl 
>>> kern.vt.accessibility.enable=1 after booting the new kernel.
>>>
>>> It is freaking awesome!
>>>
>>> There might be some bugs, but it worked fine for me!
>>
>> The espeak port is marked for deletion on 2022-06-30 (but has
>> not been deleted, yet):
>>
>> DEPRECATED=     Last release in 2014 and deprecated upstream
>> EXPIRATION_DATE=2022-06-30
>>
>> There is espeak-ng, which took over the sources, and I have
>> prepared a port update.
> 
> Many years ago, I added the speech synthesis APIs from OS X to GNUstep 
> using flite:
> 
> https://www.freshports.org/audio/flite/
> 
> flite it small (the port contains separate .so and .a files for each 
> voice, a minimal version needs only one), has no dependencies outside of 
> the base system, and is permissively licensed.  I haven't used it for a 
> while (apparently it's had a new major release since I last did), but I 
> was happily using it for text-to-speech on FreeBSD 10-15 years ago and 
> it is still in ports.
> 
> David
> 

Hi,

I've updated my patch a little bit, so please re-fetch it.

I tried:

action                  "echo -- $text | rtprio 8 
/usr/local/bin/flite_cmu_us_slt"

And it doesn't sound as good as espeak :-(

Do we have more of these in ports which are know to be good?

--HPS

From nobody Fri Jul  8 13:18:35 2022
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 5E81C12AE2C6
	for ; Fri,  8 Jul 2022 13:18:45 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LfYkr2H8Nz3dL8;
	Fri,  8 Jul 2022 13:18:44 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id c7abcdc2;
	Fri, 8 Jul 2022 13:18:37 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 75f04ef5 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Fri, 8 Jul 2022 13:18:37 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-FA8024B4-5ABA-409C-AF37-BBDA7F681065
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 (1.0)
Subject: Re: Accessibility in the FreeBSD installer and console
From: Michael Gmelin 
In-Reply-To: <6be49060-6e16-275a-f2b3-89dcb0590472@selasky.org>
Date: Fri, 8 Jul 2022 15:18:35 +0200
Cc: David Chisnall , freebsd-current@freebsd.org
Message-Id: <19E56D75-196B-4C16-A770-52038A6F8916@freebsd.org>
References: <6be49060-6e16-275a-f2b3-89dcb0590472@selasky.org>
To: Hans Petter Selasky 
X-Mailer: iPhone Mail (19E258)
X-Rspamd-Queue-Id: 4LfYkr2H8Nz3dL8
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-2.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[grembo];
	ARC_NA(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCPT_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail-FA8024B4-5ABA-409C-AF37-BBDA7F681065
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On 8. Jul 2022, at 14:48, Hans Petter Selasky  wrote:
>=20
> =EF=BB=BFOn 7/8/22 14:34, David Chisnall wrote:
> Snipsnap
> Hi,
>=20
> I've updated my patch a little bit, so please re-fetch it.
>=20
> I tried:
>=20
> action                  "echo -- $text | rtprio 8 /usr/local/bin/flite_cmu=
_us_slt"
>=20
> And it doesn't sound as good as espeak :-(
>=20
> Do we have more of these in ports which are know to be good?
>=20

A very long time ago I used festival, which seems to exist as a package (pkg=
 install festival festvox-voiceyouneed).

It=E2=80=99s quite old though (I assume that "flite" is the light version of=
 it), back then it sounded ok, but we were easy to impress ;)

Cheers


--Apple-Mail-FA8024B4-5ABA-409C-AF37-BBDA7F681065
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 8. Jul 2022, at 14:=
48, Hans Petter Selasky <hps@selasky.org> wrote:

<=
/div>
=EF=BB=BFOn 7/8/22 14:=
34, David Chisnall wrote:
Snipsnap
Hi,
I've updated my patch a little bit, so please re-fet=
ch it.

I tried:

=
action           &nb=
sp;      "echo -- $text | rtprio 8 /usr/local/=
bin/flite_cmu_us_slt"

And it doesn't sound a=
s good as espeak :-(

Do we have more of the=
se in ports which are know to be good?


A very long time ago I used festival, which see=
ms to exist as a package (pkg install festival festvox-voiceyouneed).
<=
div>
It=E2=80=99s quite old though (I assume that "flite" is t=
he light version of it), back then it sounded ok, but we were easy to impres=
s ;)

Cheers

=

--Apple-Mail-FA8024B4-5ABA-409C-AF37-BBDA7F681065--

From nobody Sat Jul  9 01:21:27 2022
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 56C9512AC537
	for ; Sat,  9 Jul 2022 01:21:33 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lfsmr2BQgz4Cpr
	for ; Sat,  9 Jul 2022 01:21:32 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-ej1-x632.google.com with SMTP id o25so370198ejm.3
        for ; Fri, 08 Jul 2022 18:21:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=from:content-transfer-encoding:mime-version:subject:date:references
         :to:in-reply-to:message-id;
        bh=680I9sFES2T00jSz19POECwr+YG109ZyAqM8LfsdMSo=;
        b=EF6ZHaAdEEJPfvbHuRXiK02Ni4kQ88N1uGdTuPst+j3EzrRmd4ZVyAE8gVbOM7JsXa
         Qd65ZD0Kr0cHd9S20i9UDdS7Y0Kz1BAMEOAHf7u56pxHbCZTZCL7AOfmJP1wyApLsCoS
         E2eWLhovpghv9zMmLwgYDoFMicOWIavAb2hPI5qxxmmCW4lsYDWyq+a0lpsQmXxh3cFW
         0rb40L382NUlqKofG3e5iRlrbjqAIg/HprIlo2jfchiaJwE9Txi99/ChUMjmGa/I7Uda
         NORMJQryZFyjwufkuCQi/YE9WsQMEIIdEonoq2b4udoCH4JqG4Xh9gGUTkDg5+eQJwAi
         yTyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:from:content-transfer-encoding:mime-version
         :subject:date:references:to:in-reply-to:message-id;
        bh=680I9sFES2T00jSz19POECwr+YG109ZyAqM8LfsdMSo=;
        b=JjHxQEI1929uDZehMXqiAZkZxaz3892sQU37mNB5iGPL5V6CB2w+SSZbfovJNttlSl
         1jR/VU3/58jNHi4oDcCAeFL1r0O5bf6wsSzvZzZTPLAtQGYZW9vi/o/fEd6Nrs8oYvkn
         9G7KhaW0Xk69ePv+Pb4l69n5k0sSE6FN+vgXThF+vdpfR06lYZeumBRU4HE9uweCEIH8
         6KI3ESFkE+3Fx4YemqQpUipzehcZX7KgsaBNP5fDiK5o8cyj5f0jWZR2WwVwOhtYETIE
         HiFpr1gMoYmEeyLXFxIYreur72bUj4zjMj+DCPsZpiPdzqlD9zuPyZJrsEvaNU+KsgCV
         Kf8g==
X-Gm-Message-State: AJIora8t8q5TXrEUgBEgUJvJLrvGi724G4IuVAV+gcBugdLr+6/FFwri
	Vl2E01uqFmr61PeNdlNe7EsHGMMOWseRjw==
X-Google-Smtp-Source: AGRyM1u5/LOpoIzh0pH8c2Em3v0TuxJPjBBdD/c5Qu7tobx0BGowSyzMw5Kysk25W7C2raArTVPBWw==
X-Received: by 2002:a17:907:a05c:b0:72b:347b:4f59 with SMTP id gz28-20020a170907a05c00b0072b347b4f59mr958998ejc.764.1657329690167;
        Fri, 08 Jul 2022 18:21:30 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-024-114.46.114.pool.telefonica.de. [46.114.24.114])
        by smtp.googlemail.com with ESMTPSA id h5-20020a0564020e8500b0043a7404314csm140096eda.8.2022.07.08.18.21.29
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 08 Jul 2022 18:21:29 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.100.31\))
Subject: Re: Accessibility in the FreeBSD installer and console
Date: Sat, 9 Jul 2022 03:21:27 +0200
References: 
 <45ACA785-05BF-496B-8D0A-AD2A4A2293D1@googlemail.com>
 
 
 <011CA96A-75B1-4077-A0AB-AFB7F4F851AA@googlemail.com>
 <187490b5-fa8a-eb70-edfc-4e5c190db03d@selasky.org>
To: Hans Petter Selasky ,
 freebsd-current@freebsd.org
In-Reply-To: <187490b5-fa8a-eb70-edfc-4e5c190db03d@selasky.org>
Message-Id: <080B179E-359E-4796-BFC8-0AAC65089100@googlemail.com>
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4Lfsmr2BQgz4Cpr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=EF6ZHaAd;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::632:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current]
X-ThisMailContainsUnwantedMimeParts: N


> Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
>=20
> Hi,
>=20
> The only argument I've heard from some non-sighted friends about not =
using FreeBSD natively is that ooh, MacOSX is so cool. It starts =
speaking from the start if I press this and this key. =E2=80=A6=E2=80=A6.

Hi,

I would like to shortly introduce myself.
I am indispensable  for all your friends and everybody else
and yes, I can speak (and I can even hear)-
I am the de facto standard for everything audio for Apple users and I =
even can=20
make users of other OSes very very happy.
=20
>=20
> Am 08.07.2022 um 12:53 schrieb Hans Petter Selasky :
> Hi,
> Here is the complete patch for Voice-Over in the FreeBSD console:
>=20
> https://reviews.freebsd.org/D35754
>=20
> You need to install espeak from pkg and then install the =
/etc/devd/accessibility.conf file and then run sysctl =
kern.vt.accessibility.enable=3D1 after booting the new kernel.
>=20
> It is freaking awesome!
>=20
> There might be some bugs, but it worked fine for me!
>=20
> =E2=80=94HPS

Congratulations !=20

But while reading the docs of your system`s bluetooth drivers I became a =
bit afraid=20
that I won=E2=80=99t be fully supported , I hope this is unfounded.

It=E2=80=99s not only that I=E2=80=99m a shiny white culty thing ..
your friends can leave me in their ears and can simultaneously hear the =
surroundings AND the Audio output.
That=E2=80=99s why I=E2=80=99m indispensable=E2=80=A6

Will you ensure that at least one bt-chip will support me in your system =
and will you=20
care for the corresponding drivers?

If yes I would be happy to meet you in your VT-console ,

And when you later even support vice versa:=20
-SpeechToText- ,
It=E2=80=99s possible that we become friends for life .


Best Regards,
yours=20

AirPodsPro  :-)=20





From nobody Sat Jul  9 15:07:52 2022
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 918AE17D4642
	for ; Sat,  9 Jul 2022 15:07:59 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2049.outbound.protection.outlook.com [40.107.115.49])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LgD6Q5FSbz3STY
	for ; Sat,  9 Jul 2022 15:07:58 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Ehgb4XObFaAgH5tYWNCb616E4eA8VgyNupSiN1fS30FxXQv1zceslzPWkTQqNkzlD842RFo12lTxb5S4VeZ7qBvJph7doRYHiCE5oGMmLzKi4HcjTaRCtrMtVYxXhvvGm5qcTSGOdPsqvybxYBYxvEvk+KhK+KlaMSc+wyn23xaqnQiwdPXgkyEjR7er8C+JC/DK64MKPaWhIatMkfGA+YlQw3xycZBTepIxbNnkAwxRJ1EIwpihdqpHfAVZP3CSbezansSV37tAtigMw37TwmlTd49K/tqJrgCPssPfJXD/GRpdqdG62OPKWc8KBubfJMYGESxhBSCZtHJkkFObqA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XWV+Q85cBQ9aYplX6+floZqi+/wRV6QDG8yZafpgGIc=;
 b=BMkOVKPVM2OMjNgLP/Dy2MagpQ/72QaGHBpHJYeQ7cJXsfzcx58J1zCvlr2jduC1rGtMeBvyBpkc+a9ZLZPB8AsqqtkVGqlmCv+YnQHPWYZ1TwAN2B+/cfGObiZGgbDnBG6H8Q8bdo0GmHbVu4p054LZPGiylO6yEuv1tQCzJrPuQLadILrTczpiMGq66iVsgw0GSq/Z3JWp8+wBhelD1lluHUpW1h3QO+JNVATogvQmsRony6WoOQchXwbU88CMzbcb3UodPplBMqVNH0iG2PCxj+syzF2cmGjzUrkY1ky7BO7S75gdykJEVwVgYsI/8L3sHGq6TOAVwMGN1PN3Ng==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca;
 dkim=pass header.d=uoguelph.ca; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=XWV+Q85cBQ9aYplX6+floZqi+/wRV6QDG8yZafpgGIc=;
 b=HqRsGSsLqz7IsmfHKxvb7gRhSyIl8Io3Q3hY5r6LDK9s5Bxj+Nttzm4YoDoQJ84ZK7JJur5WbDXQn7rAre5qm+X1/2C21qFUWzcLtKB3X15UqeOsq9dKlgxxY+twumy84KvFQFAa78OX/YMy5f5AXZvlga83x5cT6LDvpDiwHcK+ZYnAnDcFEX7dGvG05vYUsHA67vOmWIjITskENkO4gZO+GK+MyTlWB8B7p8jq7OoKYp5LwZ4tILMHZeR3uqphQ+SMucXXfRsiJ1nD9Z382rbqpvnX2P0C9kG2zQcVTPJOLo2G6xj2GMuwhkzIrBeTPtZ52IprUPvH24wcXqGrEQ==
Received: from YT2PR01MB9729.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:df::22)
 by YTBPR01MB2541.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:17::18) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.16; Sat, 9 Jul
 2022 15:07:57 +0000
Received: from YT2PR01MB9729.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::4d41:286b:31e:99c4]) by YT2PR01MB9729.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::4d41:286b:31e:99c4%7]) with mapi id 15.20.5417.024; Sat, 9 Jul 2022
 15:07:52 +0000
From: Rick Macklem 
To: freebsd-current 
Subject: Heads up: you need to rebuild all nfs modules from sources
Thread-Topic: Heads up: you need to rebuild all nfs modules from sources
Thread-Index: AQHYk6VM6FgbBpNAj0ynY8ZpdjyxVQ==
Date: Sat, 9 Jul 2022 15:07:52 +0000
Message-ID:
 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
suggested_attachment_session_id: 154d217e-a6b4-8d46-7ec1-036cbfc87637
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: daa7b0e6-a518-4e7d-7550-08da61bccb75
x-ms-traffictypediagnostic: YTBPR01MB2541:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 uOGEvS/I79G5fErSZii53wxj8wa5VG5/gcrXe5ForipDG82KlEyKj5Hoo2rTubSB7p2XK0/JqlLlP9DRCd/Whvr3rIMMxyRjq6TcRKqocl3rRGWVT7HjX/paTDHpZTvwmVWMBjHtHgdzYUsL/8Lmg4luYzdBGlteekaBy3GL2iTDq1pvcULU2gYV+K1KucF0TjFIE+znHr7KsfP8hDebvQ/pvPImZmLPekQZWAhobIm7I92AY16/d7IoH2T0BtCeJjmBDX3ubPmkM1lMXiX6QnzMQZcqIQ8uWDYu+Dx0RcG20ZpVy/gDupAgM9wfqTw/D56Qzxu9COOFJts7rKRAkmAaxl5ovUQNy4g+QFJ4W1BLx4B/Heg6i/zpmNLQNGJU2i+jlmk6v/wZSyPKrgpknsyvKb1CGfi2dZPg3CkF1rLIN5cEuQ5opIINmn5rzfiYYoebrCruoeQaJ87DfzN08O/wYr6fkS/gJz72LE47K7nzj3RDxM7AqTm6jQ1NmVjfsInJVQ6HfaAihHOEsspgBkYFpmDpkRpL944RZAplC4XoZIEHgOidjCjKMUU5YYVbzV+fw0rw4NYm+aIU4rYu0YYgTGZY3cDBBKMoWkiQv+sdugeswF2528NpUTC40y94xP+FVk/LrpYaH+J4GbZsMU5vuUfpAyRPLG1LcZpfKnVsTPYpd7mZDFWcd/SZ4zVJU8o2obcjIfundkpPlux5RY1sQOae6/Jy+ShP7HDbs2RCfT2GSIfFBHKtf/zvZH3aKIokFJ2kWWdSrXjQPefKNzLxj7JACD6WyVArTVex42UXMRzwNacQUOUn2eB7ig6T
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9729.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230016)(4636009)(366004)(396003)(346002)(39860400002)(376002)(136003)(71200400001)(5660300002)(4744005)(2906002)(33656002)(8936002)(122000001)(52536014)(66556008)(316002)(64756008)(6916009)(8676002)(66946007)(786003)(91956017)(66476007)(66446008)(55016003)(86362001)(41320700001)(186003)(7696005)(6506007)(38100700002)(76116006)(41300700001)(9686003)(38070700005)(478600001);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?EjPFXpcE8zZqo7nlDjG0TbNL+qUedqp0BhxK796hI8/rz4irpUrdGmehC0?=
 =?iso-8859-1?Q?MB5HUQ4VVk29YmA6lx4lzrh5a7PIeyxPNPpzvPPuMCUU0svae8cv901L2j?=
 =?iso-8859-1?Q?uN5be7F5pK7mfXJF2ea0HJW4+vue2Aq+ASJtDtevWdC0+c8vxKVq2igB+u?=
 =?iso-8859-1?Q?5rPmgBU+NvajlTRao9e1BLMuR4arTFzvzIEND/stkREK1bMX/Sq4dYwUQI?=
 =?iso-8859-1?Q?CbGu78wPGgpQrDA77tMPVLSkIcnIveFjYdudxsKbU4Agd8yQpP6CkAl+GX?=
 =?iso-8859-1?Q?1Ucv0NHZpu1zcP7WpSQEulnXSZ7SMJKik27VYYrUyrXEprAj438BsggGIl?=
 =?iso-8859-1?Q?BPqF9PltKUFH0Z/x3Ps1yr7/FPl/8nk2IqhxtYUlNTz/+weWHNVkhQ7DxC?=
 =?iso-8859-1?Q?LrO47hu6Ye8lpJOw57YN73Kwccfnw61nzGNomdgtbmIpvgYmdzys8LuA51?=
 =?iso-8859-1?Q?jSKVRKVBJuTCSEN+Obit8xJCgON1AX/DMGLIWqMWsBwLwNjBkcUM2mcKeT?=
 =?iso-8859-1?Q?02Nmtet2UHnLXALWlGFS/T/HehwC8ZylifTdcJIIfNvRBwvfQJMdUePWhc?=
 =?iso-8859-1?Q?kjd0kWbc4HkgIPZzq2IVikPEx9fy234878Xpyw5Oy1w1RjU/fN5fOFekhI?=
 =?iso-8859-1?Q?JPQj5FOlP6UCZqtlpYq29Bbe6HY2TX+DjTmrThUA6vT3ATHsJzwuKtgEux?=
 =?iso-8859-1?Q?jVyjo7beqdqV9gmeb1gaNrYvXx3bgcUAteHLf5q0pJBGNFsu9dYxjI54o2?=
 =?iso-8859-1?Q?iPJh/s+sr0bnsyiWI86U7pXYq8Tsfd9U/6sxcknAsZdx9CDNGudDaTifDw?=
 =?iso-8859-1?Q?5fVX+UU4l2va3DBQXqrRww6LDLVg6sTnPaSgeufF8xqBmq8tO+2BHjGAij?=
 =?iso-8859-1?Q?nbQGZ5mYPlLky42K2l+pQGWMlSQMtqrZq1FIgH/vNY3OWxaW882z0DjqWL?=
 =?iso-8859-1?Q?c43DaQV47Ml8klhuUJ2DLiQe4HSHnPxLjOkb39WHWgkxXlirLjm/sochOu?=
 =?iso-8859-1?Q?VqApCuhoAGZrPQutukXcyXHLxevOSQ7BodvDPwRtEKw4QcRFBnkZ154DVn?=
 =?iso-8859-1?Q?DPT5917Lz2Um/AZSu5hFC/O+oEuUeKbki5by08hciRQtFSEz7LaA4uth9r?=
 =?iso-8859-1?Q?Pj9rlRMQTJ3I3RsCtoWVYMquHnP6qfacdzoYRVqra4Dsuv2DsyBpcKzSB9?=
 =?iso-8859-1?Q?RxhubbNwErwtgW4ASXuuPq1lK0U8bbB643vgpzhQDIu7NCxmQqEZL6imZD?=
 =?iso-8859-1?Q?nnxbe/U5JMy1vCfAWykOJCvJT4bGnVkbovMY70VVtl9BiNWiD3SUujf2zX?=
 =?iso-8859-1?Q?uqnn2BpgJNlk23VmfDOHsvZlSqdk2hDeN8+McIm3pMISY+Mz1nQ1uFPUmQ?=
 =?iso-8859-1?Q?LCqOrw0Oyqg+pxAdBIsBOuyTOS2JL9UPh83051F9f+iANHym9EMaZqTlON?=
 =?iso-8859-1?Q?fOxNFep2VqmwxhuO4RJP+7ltqgwdekv8rSTot2JvqNEkXYwl+rHc4xplv+?=
 =?iso-8859-1?Q?J2wxNHP5wjJ3IBPzia+u5b2+GCCLrWykI7NdChN+lCM4L/xthnOrJlnRKW?=
 =?iso-8859-1?Q?w8uhTyfR4ptnz1vJ4gf13qnItRbaByMb+ndKy+CFhHhespsHJvu+Ivj1NT?=
 =?iso-8859-1?Q?VXMmiXew/z8cRm+L7rUim+597D8xQhdAlXj57sHL9PzZvNIKZyI6vgfPZA?=
 =?iso-8859-1?Q?Q/WzdI8ICRaWrZGTGXA=3D?=
Content-Type: text/plain; charset="iso-8859-1"
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
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9729.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: daa7b0e6-a518-4e7d-7550-08da61bccb75
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2022 15:07:52.1095
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wBZ3St24F4KkeaMoHlMDGJ0S+vpeWeR3FzrONFTbkiNbCZwD4hY8Su5WW5Nfn3rvgpba8HVs11VWWrgvQKm4Pw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB2541
X-Rspamd-Queue-Id: 4LgD6Q5FSbz3STY
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=HqRsGSsL;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=uoguelph.ca;
	spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.115.49 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca
X-Spamd-Result: default: False [-6.00 / 15.00];
	DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none];
	R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2];
	R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current];
	ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.107.115.49:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEFALL_USER(0.00)[rmacklem];
	DKIM_TRACE(0.00)[uoguelph.ca:+];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.115.49:from]
X-ThisMailContainsUnwantedMimeParts: N

Hi,=0A=
=0A=
Commits over the last couple of days and ones happening=0A=
over the next few days change the internal KPI between=0A=
the nfs modules (nfscommon.ko, nfscl.ko and nfsserver.ko).=0A=
=0A=
As such, after pulling an up to date main from the git repo=0A=
you need to build all nfs modules from the new sources.=0A=
=0A=
I am not doing a version bump, since mav@ indicated it=0A=
was not necessary and there will be several changes over=0A=
multiple commits.=0A=
=0A=
rick=

From nobody Sat Jul  9 16:26:40 2022
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 61A7F1808E8A
	for ; Sat,  9 Jul 2022 16:27:06 +0000 (UTC)
	(envelope-from evgeniy@khramtsov.org)
Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f])
	(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 4LgFsj13NTz3cbX
	for ; Sat,  9 Jul 2022 16:27:01 +0000 (UTC)
	(envelope-from evgeniy@khramtsov.org)
Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f])
	by mxa.khramtsov.org (Postfix) with ESMTP id 0488E125EB7
	for ; Sat,  9 Jul 2022 16:19:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khramtsov.org;
	s=rsa; t=1657383583;
	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=/RA+XCzv44hNw+tM0oznTCUOaBLJbUzW0gSb+WVOkQ4=;
	b=RQ5h2+ACMAP7qfIgF094A/M3tJqtf+gFAR0DGbRuJK6eUzMo08CXjyRLg7rkD4ghJJFt3V
	mbPETYD9heYXTg6/dARnV4Lmwua/jLXZ2mtXtjo+s0IMuXRtmaElwykwF08C3b1IKMODKi
	ZWpM3GFRvphK+7mEaThW0ODsneUrds1eNpFP9H9GQYU0MLct8K1LwFGdG2zb4QzqiVdxdv
	gl46eAdGXwue8dYcQavtTjgzAMns/pSBujfzkps4kpiinhYRBs7F1OCbiLI/jzbyKTb+DE
	jyWZvOXmncvOv9Sb2Y10ofaIJ3UMtelI9uV6zyMwJk8HSiA03i9q3iFndOyzuA==
Date: Sat, 9 Jul 2022 16:26:40 +0000
From: Evgeniy Khramtsov 
To: FreeBSD -CURRENT 
Subject: BLAKE3 unstability?
Message-ID: <20220709162640.7my2bq6rax5npdhf@vax.khramtsov.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
X-Rspamd-Queue-Id: 4LgFsj13NTz3cbX
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=khramtsov.org header.s=rsa header.b=RQ5h2+AC;
	dmarc=pass (policy=reject) header.from=khramtsov.org;
	spf=pass (mx1.freebsd.org: domain of evgeniy@khramtsov.org designates 2a0a:e5c0:2:10f::f as permitted sender) smtp.mailfrom=evgeniy@khramtsov.org
X-Spamd-Result: default: False [-2.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[khramtsov.org,reject];
	R_SPF_ALLOW(-0.20)[+ip6:2a0a:e5c0:2:10f::f];
	R_DKIM_ALLOW(-0.20)[khramtsov.org:s=rsa];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	ONCE_RECEIVED(0.10)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[FreeBSD-CURRENT];
	RCVD_COUNT_ONE(0.00)[1];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	ASN(0.00)[asn:207996, ipnet:2a0a:e5c0:2::/48, country:CH];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[khramtsov.org:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

-CURRENT as of:

commit eec3290266bc09b4c4b4d875d2269d611adc0016 (main)
Author: Ganbold Tsagaankhuu 
Date:   Sat Jul 9 13:06:52 2022 +0000

    Add RK3568 SoC support to pinctrl driver.
        
    Submitted by:   sos
    Reviewed by:    manu
    Differential Revision:
    https://reviews.freebsd.org/D31330

New boot environment created via bectl, zfs set checksum=blake3 new_be,
pkg -r /tmp/be_N upgrade, reboot into new BE, login failed after
sysutils/pam_xdg failed integrity check.

Rebooted into previous BE, did zpool scrub and got 32 checksum errors
without files specified before getting panic (no trace due to drm-kmod?).

bectl destroy / zfs destroy of new env with blake3 restored pool back to
0 checksum error state.

No out-of-tree base modifications present, only a custom kernel config.

From nobody Sat Jul  9 16:31:50 2022
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 B32F4180AAE2
	for ; Sat,  9 Jul 2022 16:32:05 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LgFzT06vkz3ftM
	for ; Sat,  9 Jul 2022 16:32:01 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe30.google.com with SMTP id k2so1345561vsc.5
        for ; Sat, 09 Jul 2022 09:32:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=I4SdaTd9fPhp5ZCYoXIHdsL6SJ71if/+i28HdS+vCso=;
        b=lEgHmmVtQTLAw187vDXoFq/Evpa14bKHubt/Jtk/9Jdl/z+xYcAk2tM0sw5rK7K/EF
         Pw836YhTmkz2TC2ejY6UYTQ6mCgJB6Yjdb0LWcATnTqhhRDXZlkCM4c5wIfhZacWTho0
         QSCqgclYB6VoIlunWr4vbu2FDWiaSCRXAIuXZWln89QUuNqxknptGJLpLF17DdZW9KEr
         LfsLdzCwhUZKQsAAqHHDUPICV2vsJlAzu4cC/WzvX4Is2K9MQIZwbHprhqU+cf7cnBnf
         ECxbSQ6dGbZ2Li5MR/ywEsz8oE6D81xQ7gE6Dvk4U6YYt9MkhIHYWuc0w49CqeWUGyXk
         zbLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=I4SdaTd9fPhp5ZCYoXIHdsL6SJ71if/+i28HdS+vCso=;
        b=lQbzkLSQDNl8I3HL+jrRBgZBQMDyjdKwldhKRVbkxNLQtj+IU5NUiPZUhREdf1cJcY
         QTYlIzDddRZPL2dg8F82yuVyxLAEckTpK8tYR58L6WASS27y7PSif4sNWqpnVNVloKuN
         fIQNYeTvXX9WRBd2APPeP1I7e/dDzDXFcFuUymmK0xsy0LgNHX5iQ8DaamkPHJGnbiJT
         8gV0DqBiQ0Uyf0gIgXUWUyeJGFf9FbzdMAQig/85DThXseysUGbGQMqP38+/WxlEh0P5
         6noSRsRxt4dNz6a9K6tBotU7nvZOgr708lk610Q/o9BmHigOoT4ahZ/PUEFDHeCZJ6id
         /l+A==
X-Gm-Message-State: AJIora/8LiInLntmY9ODdPOiEX/E95baMxOvKScfPHq4hDfrq6uaxlbH
	4k60/wKk6W2ow9XXm1tVgaOgbL2AO6gxVbAHGBHisjIBx10=
X-Google-Smtp-Source: AGRyM1t+pANvCD3lkAtcR1f5rjH/CeZykoura6khARJr9t0CisvT4gfnkdPeds5717TKAculkEoJXOHcwtEbKuaxkbc=
X-Received: by 2002:a67:ab02:0:b0:356:51a5:993e with SMTP id
 u2-20020a67ab02000000b0035651a5993emr3354195vse.12.1657384320804; Sat, 09 Jul
 2022 09:32:00 -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: <20220709162640.7my2bq6rax5npdhf@vax.khramtsov.org>
In-Reply-To: <20220709162640.7my2bq6rax5npdhf@vax.khramtsov.org>
From: Warner Losh 
Date: Sat, 9 Jul 2022 10:31:50 -0600
Message-ID: 
Subject: Re: BLAKE3 unstability?
To: Evgeniy Khramtsov 
Cc: FreeBSD -CURRENT 
Content-Type: multipart/alternative; boundary="000000000000b2bdac05e361db79"
X-Rspamd-Queue-Id: 4LgFzT06vkz3ftM
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=lEgHmmVt;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e30) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[FreeBSD-CURRENT];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e30:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000b2bdac05e361db79
Content-Type: text/plain; charset="UTF-8"

Be advised that blake3 went into the bootloader yesterday and has been only
lightly tested.

Don't think this would cause your checksum errors since the boot loader is
read only.

Warner

On Sat, Jul 9, 2022, 10:27 AM Evgeniy Khramtsov 
wrote:

> -CURRENT as of:
>
> commit eec3290266bc09b4c4b4d875d2269d611adc0016 (main)
> Author: Ganbold Tsagaankhuu 
> Date:   Sat Jul 9 13:06:52 2022 +0000
>
>     Add RK3568 SoC support to pinctrl driver.
>
>     Submitted by:   sos
>     Reviewed by:    manu
>     Differential Revision:
>     https://reviews.freebsd.org/D31330
>
> New boot environment created via bectl, zfs set checksum=blake3 new_be,
> pkg -r /tmp/be_N upgrade, reboot into new BE, login failed after
> sysutils/pam_xdg failed integrity check.
>
> Rebooted into previous BE, did zpool scrub and got 32 checksum errors
> without files specified before getting panic (no trace due to drm-kmod?).
>
> bectl destroy / zfs destroy of new env with blake3 restored pool back to
> 0 checksum error state.
>
> No out-of-tree base modifications present, only a custom kernel config.
>
>

--000000000000b2bdac05e361db79
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Be advised that blake3 went into the bootloader yesterday=
 and has been only lightly tested.

Don't think this would cause your checksum errors since the boot l=
oader is read only.

Warn=
er

On Sat, Jul 9, 2022, 10:27 AM Evgeniy Khramtsov <evgeniy@khramtsov.org> wrote:
-CURRENT as of:



commit eec3290266bc09b4c4b4d875d2269d611adc0016 (main)

Author: Ganbold Tsagaankhuu <ganbold@FreeBSD.org>

Date:=C2=A0 =C2=A0Sat Jul 9 13:06:52 2022 +0000



=C2=A0 =C2=A0 Add RK3568 SoC support to pinctrl driver.



=C2=A0 =C2=A0 Submitted by:=C2=A0 =C2=A0sos

=C2=A0 =C2=A0 Reviewed by:=C2=A0 =C2=A0 manu

=C2=A0 =C2=A0 Differential Revision:

=C2=A0 =C2=A0 https://reviews.freebsd.org/D31330


New boot environment created via bectl, zfs set checksum=3Dblake3 new_be,
pkg -r /tmp/be_N upgrade, reboot into new BE, login failed after

sysutils/pam_xdg failed integrity check.



Rebooted into previous BE, did zpool scrub and got 32 checksum errors

without files specified before getting panic (no trace due to drm-kmod?).


bectl destroy / zfs destroy of new env with blake3 restored pool back to
0 checksum error state.



No out-of-tree base modifications present, only a custom kernel config.






--000000000000b2bdac05e361db79--

From nobody Sat Jul  9 17:56:05 2022
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 C39CF1CFF861
	for ; Sat,  9 Jul 2022 17:56:32 +0000 (UTC)
	(envelope-from evgeniy@khramtsov.org)
Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f])
	(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 4LgHrw0D7nz3qbl
	for ; Sat,  9 Jul 2022 17:56:32 +0000 (UTC)
	(envelope-from evgeniy@khramtsov.org)
Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f])
	by mxa.khramtsov.org (Postfix) with ESMTP id 042EC125EB7
	for ; Sat,  9 Jul 2022 17:49:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khramtsov.org;
	s=rsa; t=1657388957;
	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=rQI31l96s8549wcheoJu38zwDpFu9YAI4MJDKi+sa7o=;
	b=k4uSTA04t3Hyatp6sY+JIQuT9rqZARaZ/n7SXzWKGqT96G9DC95OC8VZhnLWsIUsanO/LO
	K8FW7lGvC5wIQpdHWq6tRUtvCifQMi9q9AfXuRgRolEhgRXyGeqbq0eIniSnkSFw1v//25
	s8wNJJh2jRd7jNMLypwj5/akTLUtR5YAZGlveiAcrmkcWHngCTpQes4WoDO1FxrVYiQN0s
	ePVKX+uT36BqMaZKJBhsZVy4Tg6FeUxsgiLYRxzQ6Kr8O0h59LHm5W+xQ6lxc3ZObnUBIG
	aNuhqiF/H/ExewzmMjORFMDXAnkdQyF5p7xz296RyzHxaEmcSOVzXdIUcDUNMg==
Date: Sat, 9 Jul 2022 17:56:05 +0000
From: Evgeniy Khramtsov 
To: FreeBSD -CURRENT 
Subject: Re: BLAKE3 unstability?
Message-ID: <20220709175605.ofkoft2mglrkaqpf@vax.khramtsov.org>
References: <20220709162640.7my2bq6rax5npdhf@vax.khramtsov.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: <20220709162640.7my2bq6rax5npdhf@vax.khramtsov.org>
X-Rspamd-Queue-Id: 4LgHrw0D7nz3qbl
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=khramtsov.org header.s=rsa header.b=k4uSTA04;
	dmarc=pass (policy=reject) header.from=khramtsov.org;
	spf=pass (mx1.freebsd.org: domain of evgeniy@khramtsov.org designates 2a0a:e5c0:2:10f::f as permitted sender) smtp.mailfrom=evgeniy@khramtsov.org
X-Spamd-Result: default: False [-2.80 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[khramtsov.org,reject];
	R_SPF_ALLOW(-0.20)[+ip6:2a0a:e5c0:2:10f::f:c];
	R_DKIM_ALLOW(-0.20)[khramtsov.org:s=rsa];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	ONCE_RECEIVED(0.10)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[FreeBSD-CURRENT];
	RCVD_COUNT_ONE(0.00)[1];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	ASN(0.00)[asn:207996, ipnet:2a0a:e5c0:2::/48, country:CH];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[khramtsov.org:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I can reproduce via:

$ truncate -s 10G /tmp/test
$ mdconfig -f /tmp/test -S 4096
$ zpool create test /dev/md1
$ zfs create -o checksum=blake3 test/b
$ dd if=/dev/random of=/test/b/noise bs=1M count=4096
$ sync
$ zpool scrub test
$ zpool status

From nobody Sat Jul  9 18:04:47 2022
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 F1B613E1AC7
	for ; Sat,  9 Jul 2022 18:04:59 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LgJ2g0BHSz3s1Q
	for ; Sat,  9 Jul 2022 18:04:59 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vk1-xa36.google.com with SMTP id c185so450861vkh.12
        for ; Sat, 09 Jul 2022 11:04:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=gtsIYI2b6/6gVT/uEzbZQyswVP7ff7iyhtWWS478SSw=;
        b=rc9dWcXwFGnDuEdpVeI3F6/Vmqno/u3H+MpUZwJ8tx/RW0VjaaAo3HaCEuA+RlceIV
         HSQNy+YpkSPOU6Ucw+t8kAn5thS90zib4ByBfX/nUM6zNS2Lec8Dui0YXGYou3DVQjEz
         9jZjNXmNIGksRqwAlhvGSAwH3hucwQn5M7CEV9B6N8Lc2gC2JnfTgH1o7eeOWQ4j1moA
         ui2Eun9op+k420VqlOquXaUoZCmlzbUjqdLaJUGvwidZjW29vulkL83jFk96tt4rKmdT
         ZKTFrtpjnHWN4Rs+kczLEsVj58NHe///XPJvqObR+TnHPm5SZHz8V5+GgnXTuCiVrI9i
         hVPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=gtsIYI2b6/6gVT/uEzbZQyswVP7ff7iyhtWWS478SSw=;
        b=MsiYjXJ76QO/9poGXOyNVn64mJnkTVbw5tFPrx6eTo25dfYSxqPM4JCzt3RgFM0spn
         CBxiqQR/xV5YqwF+VF8Yyc8/KsiV1+BFqERT/57jNXF0VIsRcZXsV6MZJgfjUsxFb89R
         xRBQeQj96oFDycRDtArkbCA273u1ikqvV+vmxF4tLdr96dlHdnbhN+lwLzkJNSBTVS/x
         q++oSSo8aF5fGoqSPjhN7jr/xA+33C2Li7N73P3GmLTNx/8vj6JQwqyD+lYRQsO/6QdH
         3smCf5Hy2yM9Nn8uJ8+QEIQKhUrIRzTTfO5u6122nhV6nfqQ+7LvOuCVJz5KF+LQaZUg
         tUkw==
X-Gm-Message-State: AJIora/Y94Gr1irVhm7ub3yrfpoYTuQ0mURVLCtdlS/8gpCprvCm92qs
	wAEGn8U9cZFRxGKD/7JeGI347I+HXwH51Oanb52Gca46TKk=
X-Google-Smtp-Source: AGRyM1vi4+KFAIPnCKm09mOJRS/AN5kI6msRlHfRZyhBjeUs8jWbv4zHmkJKXgleHM7YGb+11nhlcCQ7Nj02owXPitg=
X-Received: by 2002:a1f:9d8d:0:b0:36c:99e3:9c34 with SMTP id
 g135-20020a1f9d8d000000b0036c99e39c34mr3937532vke.10.1657389898135; Sat, 09
 Jul 2022 11:04: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: <20220709162640.7my2bq6rax5npdhf@vax.khramtsov.org> <20220709175605.ofkoft2mglrkaqpf@vax.khramtsov.org>
In-Reply-To: <20220709175605.ofkoft2mglrkaqpf@vax.khramtsov.org>
From: Warner Losh 
Date: Sat, 9 Jul 2022 12:04:47 -0600
Message-ID: 
Subject: Re: BLAKE3 unstability?
To: Evgeniy Khramtsov , Martin Matuska 
Cc: FreeBSD -CURRENT 
Content-Type: multipart/alternative; boundary="000000000000220fa705e36328fb"
X-Rspamd-Queue-Id: 4LgJ2g0BHSz3s1Q
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=rc9dWcXw;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a36) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[FreeBSD-CURRENT];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a36:from];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000220fa705e36328fb
Content-Type: text/plain; charset="UTF-8"

On Sat, Jul 9, 2022 at 11:57 AM Evgeniy Khramtsov 
wrote:

> I can reproduce via:
>
> $ truncate -s 10G /tmp/test
> $ mdconfig -f /tmp/test -S 4096
> $ zpool create test /dev/md1
> $ zfs create -o checksum=blake3 test/b
> $ dd if=/dev/random of=/test/b/noise bs=1M count=4096
> $ sync
> $ zpool scrub test
> $ zpool status
>


OK. I'll leave it to the OpenZFS folks then. The boot path isn't involved
in this at all :) Thanks for the reproducer.

Warner

--000000000000220fa705e36328fb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Jul 9, 2022 at 11:57 AM Evgen=
iy Khramtsov <evgeniy@khramtsov=
.org> wrote:
I can reproduce via:



$ truncate -s 10G /tmp/test

$ mdconfig -f /tmp/test -S 4096

$ zpool create test /dev/md1

$ zfs create -o checksum=3Dblake3 test/b

$ dd if=3D/dev/random of=3D/test/b/noise bs=3D1M count=3D4096

$ sync

$ zpool scrub test

$ zpool status


OK. I'=
;ll leave it to the OpenZFS folks then. The boot path isn't involved in=
 this at all :) Thanks for the reproducer.

Warner<=
/div>


--000000000000220fa705e36328fb--

From nobody Sat Jul  9 23:59:27 2022
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 782621CF8152
	for ; Sat,  9 Jul 2022 23:59:37 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LgRvr3bDcz3Ymx;
	Sat,  9 Jul 2022 23:59:36 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id b650321d;
	Sat, 9 Jul 2022 23:59:29 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id f5b3f175 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Sat, 9 Jul 2022 23:59:29 +0000 (UTC)
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 (1.0)
Subject: Re: Accessibility in the FreeBSD installer and console
From: Michael Gmelin 
In-Reply-To: <080B179E-359E-4796-BFC8-0AAC65089100@googlemail.com>
Date: Sun, 10 Jul 2022 01:59:27 +0200
Cc: Hans Petter Selasky , freebsd-current@freebsd.org
Message-Id: <788EF362-E06B-4BA9-BDDB-E550D35E21CB@freebsd.org>
References: <080B179E-359E-4796-BFC8-0AAC65089100@googlemail.com>
To: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
X-Mailer: iPhone Mail (19E258)
X-Rspamd-Queue-Id: 4LgRvr3bDcz3Ymx
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-2.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current];
	FREEMAIL_TO(0.00)[googlemail.com];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[grembo];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCPT_COUNT_THREE(0.00)[3];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 9. Jul 2022, at 03:22, Klaus K=C3=BCchemann =
 wrote:
>=20
> =EF=BB=BF
>> Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
>>=20
>> Hi,
>>=20
>> The only argument I've heard from some non-sighted friends about not usin=
g FreeBSD natively is that ooh, MacOSX is so cool. It starts speaking from t=
he start if I press this and this key. =E2=80=A6=E2=80=A6.
>=20
> Hi,
>=20
> I would like to shortly introduce myself.
> I am indispensable  for all your friends and everybody else
> and yes, I can speak (and I can even hear)-
> I am the de facto standard for everything audio for Apple users and I even=
 can=20
> make users of other OSes very very happy.
>=20
>>=20
>> Am 08.07.2022 um 12:53 schrieb Hans Petter Selasky :
>> Hi,
>> Here is the complete patch for Voice-Over in the FreeBSD console:
>>=20
>> https://reviews.freebsd.org/D35754
>>=20
>> You need to install espeak from pkg and then install the /etc/devd/access=
ibility.conf file and then run sysctl kern.vt.accessibility.enable=3D1 after=
 booting the new kernel.
>>=20
>> It is freaking awesome!
>>=20
>> There might be some bugs, but it worked fine for me!
>>=20
>> =E2=80=94HPS
>=20
> Congratulations !=20
>=20
> But while reading the docs of your system`s bluetooth drivers I became a b=
it afraid=20
> that I won=E2=80=99t be fully supported , I hope this is unfounded.
>=20
> It=E2=80=99s not only that I=E2=80=99m a shiny white culty thing ..
> your friends can leave me in their ears and can simultaneously hear the su=
rroundings AND the Audio output.
> That=E2=80=99s why I=E2=80=99m indispensable=E2=80=A6
>=20
> Will you ensure that at least one bt-chip will support me in your system a=
nd will you=20
> care for the corresponding drivers?
>=20
> If yes I would be happy to meet you in your VT-console ,
>=20
> And when you later even support vice versa:=20
> -SpeechToText- ,
> It=E2=80=99s possible that we become friends for life .
>=20
>=20
> Best Regards,
> yours=20
>=20
> AirPodsPro  :-)=20

But why would you ever leave your family that was designed from the ground u=
p to match you and any need you could potentially have? And why would you no=
t share any word your "owner" (the person who spent money on you, so they co=
uld use you) says with your creator and all its connected systems and entiti=
es, so that they could be fully analyzed and monetized?

-m

p.s. seriously, if you want the full Apple experience, you really should sta=
y within their ecosystem. Trying to compete with that (with all its question=
able implications in terms of digital sovereignty) is pointless, especially i=
f you are neither broke nor care too much about privacy. If these things mea=
n nothing to you, just buy the off the shelf solution and save the time that=
 tinkering with free alternatives (that will never be as smooth as "the real=
 thing") would require and spend it on things that mean something to you (fr=
iends, family, charity).=


From nobody Sun Jul 10 07:22:10 2022
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 5330217FB51E
	for ; Sun, 10 Jul 2022 07:22:16 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LgdkZ5T0Lz3LVv;
	Sun, 10 Jul 2022 07:22:14 +0000 (UTC)
	(envelope-from maciphone2@googlemail.com)
Received: by mail-wm1-x32f.google.com with SMTP id o8so1434561wms.2;
        Sun, 10 Jul 2022 00:22:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20210112;
        h=from:content-transfer-encoding:mime-version:subject:date:references
         :to:in-reply-to:message-id;
        bh=iE0MMPmFonze6mUZlzorXzwCZIH/TqhGTKoo0E9jtgg=;
        b=WzXv9OnW1uzpzyKsr3haWtz4DDEkfPpCNj2HIdTxeboo6N7uaCgse97sNeLgJk/HOS
         04fUhTKZSZPybpsb9j1/p/YdBd48fGt8iHQc6P80g2i11oW1dmxgL/KuAu9K0ZyhZ9W3
         idU3J/gSboNB1YHThauSlDkmMshyg99H14COhmaJPYiyNOqvzT2o+jIXfw/LQN3BVVpj
         mAUBKNM1ZuSbMqmQGpmp+O81PqCL6yqTEuAdaMsTsAIeCvAB+zxA0FGuKxQI8BP6OWmt
         k0dIalUS5BOboKHqtxx1R/cB0jJlIJj+x3zs2cpoKUf9zHI8gT+NiS97P24RPcQeiGba
         Qz8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:from:content-transfer-encoding:mime-version
         :subject:date:references:to:in-reply-to:message-id;
        bh=iE0MMPmFonze6mUZlzorXzwCZIH/TqhGTKoo0E9jtgg=;
        b=AVyjduEDgEcOClaNgswugBODaBoMVXGPx/s0hk+3oeMDHphXYX1Tc2uBM79AoDrJ8n
         Q+x6iVHsj0RMihVyjN4G365ArOyaTj/ioglkk7Xjh//y/OCOVXKA/JRZDcRFPtQcw2y/
         w/Yg0ahFrj2penlkvWKnkD0rjbjJWgYI4Zo3F4dxn3L5f0NYogNPaNAZ6HN0/Z/0W9Pb
         0jamcvM/anmLK9vmc5OLvB1HrYtyL/xMnuDt3uC7h359Ws9aNZ7CvpiKOoHRSRFasO+O
         ORm4bJYtas/cm5H8afWp5/p6dQyTbkGmZRyzK6n475XOn4GBt802+rDbogdd+toTB3zF
         /f9w==
X-Gm-Message-State: AJIora9Ncbt08YMjxmW//j7xF89LlTEBQ7AHEPz1GLZz8O5VRnP9GVcA
	c+hPllozdlgFwISSkcvIBAWNrSI1mZRURg==
X-Google-Smtp-Source: AGRyM1vubiStcAvQ++B1Lkv55VoWzGRd7EUh0Yu6iW7qZyAoVfjhPiUCaoY0aG+7zYkmc/KKr1wylg==
X-Received: by 2002:a1c:7903:0:b0:3a0:3936:b71f with SMTP id l3-20020a1c7903000000b003a03936b71fmr9187905wme.168.1657437733392;
        Sun, 10 Jul 2022 00:22:13 -0700 (PDT)
Received: from smtpclient.apple (dynamic-046-114-184-036.46.114.pool.telefonica.de. [46.114.184.36])
        by smtp.googlemail.com with ESMTPSA id o20-20020a05600c511400b003a2d3ed9297sm13473686wms.1.2022.07.10.00.22.12
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 10 Jul 2022 00:22:12 -0700 (PDT)
From: =?utf-8?Q?Klaus_K=C3=BCchemann?= 
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 \(3696.100.31\))
Subject: Re: Accessibility in the FreeBSD installer and console
Date: Sun, 10 Jul 2022 09:22:10 +0200
References: <080B179E-359E-4796-BFC8-0AAC65089100@googlemail.com>
 <788EF362-E06B-4BA9-BDDB-E550D35E21CB@freebsd.org>
To: Michael Gmelin ,
 freebsd-current@freebsd.org
In-Reply-To: <788EF362-E06B-4BA9-BDDB-E550D35E21CB@freebsd.org>
Message-Id: <4B9142D0-626B-43B0-A8EF-A71CB655E080@googlemail.com>
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4LgdkZ5T0Lz3LVv
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=googlemail.com header.s=20210112 header.b=WzXv9OnW;
	dmarc=pass (policy=quarantine) header.from=googlemail.com;
	spf=pass (mx1.freebsd.org: domain of maciphone2@googlemail.com designates 2a00:1450:4864:20::32f as permitted sender) smtp.mailfrom=maciphone2@googlemail.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[googlemail.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[googlemail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32f:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[googlemail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	DKIM_TRACE(0.00)[googlemail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current]
X-ThisMailContainsUnwantedMimeParts: N



> Am 10.07.2022 um 01:59 schrieb Michael Gmelin :
>=20
>=20
>=20
>> On 9. Jul 2022, at 03:22, Klaus K=C3=BCchemann =
 wrote:
>>=20
>> =EF=BB=BF
>>> Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
>>>=20
>>> Hi,
>>>=20
>>> The only argument I've heard from some non-sighted friends about not =
using FreeBSD natively is that ooh, MacOSX is so cool. It starts =
speaking from the start if I press this and this key. =E2=80=A6=E2=80=A6.
>>=20
>> Hi,
>>=20
>> I would like to shortly introduce myself.
>> I am indispensable  for all your friends and everybody else
>> and yes, I can speak (and I can even hear)-
>> I am the de facto standard for everything audio for Apple users and I =
even can=20
>> make users of other OSes very very happy.
>>=20
>>>=20
>>> Am 08.07.2022 um 12:53 schrieb Hans Petter Selasky :
>>> Hi,
>>> Here is the complete patch for Voice-Over in the FreeBSD console:
>>>=20
>>> https://reviews.freebsd.org/D35754
>>>=20
>>> You need to install espeak from pkg and then install the =
/etc/devd/accessibility.conf file and then run sysctl =
kern.vt.accessibility.enable=3D1 after booting the new kernel.
>>>=20
>>> It is freaking awesome!
>>>=20
>>> There might be some bugs, but it worked fine for me!
>>>=20
>>> =E2=80=94HPS
>>=20
>> Congratulations !=20
>>=20
>> But while reading the docs of your system`s bluetooth drivers I =
became a bit afraid=20
>> that I won=E2=80=99t be fully supported , I hope this is unfounded.
>>=20
>> It=E2=80=99s not only that I=E2=80=99m a shiny white culty thing ..
>> your friends can leave me in their ears and can simultaneously hear =
the surroundings AND the Audio output.
>> That=E2=80=99s why I=E2=80=99m indispensable=E2=80=A6
>>=20
>> Will you ensure that at least one bt-chip will support me in your =
system and will you=20
>> care for the corresponding drivers?
>>=20
>> If yes I would be happy to meet you in your VT-console ,
>>=20
>> And when you later even support vice versa:=20
>> -SpeechToText- ,
>> It=E2=80=99s possible that we become friends for life .
>>=20
>>=20
>> Best Regards,
>> yours=20
>>=20
>> AirPodsPro  :-)=20
>=20

Hi,


> But why would you ever leave your family that was designed from the =
ground up to match you and any need you could potentially have?

Of course : home sweet home.. but after these pandemic times, you're =
always happy to receive invitations from other families.
I=E2=80=99m nearly sure that HPS voiceOver invitation to his =
Macuser-friends will be a successful event if e.g. me, the AirPods Pro=20=

Would have been supported by a boot-script or similar by default, just a =
suggestion , and I am supported by many OSes, not only that from my =
creator.

> And why would you not share any word your "owner" (the person who =
spent money on you, so they could use you) says with your creator and =
all its connected systems and entities, so that they could be fully =
analyzed and monetized?

my current owner doesn't like being reminded that he doesn=E2=80=99t own =
much which could be monetized :-)

>=20
> -m

yours AirPods Pro
>=20
> p.s. seriously, if you want the full Apple experience, you really =
should stay within their ecosystem. Trying to compete with that (with =
all its questionable implications in terms of digital sovereignty) is =
pointless, especially if you are neither broke nor care too much about =
privacy. If these things mean nothing to you, just buy the off the shelf =
solution and save the time that tinkering with free alternatives (that =
will never be as smooth as "the real thing") would require and spend it =
on things that mean something to you (friends, family, charity).

p.s. (not everything strictly seriously;-).  ,  what you say about the =
full Apple experience applies to many (Desktop) Macusers but,  well, =
some years ago Apple cut out every integrated OpenSource web services =
and other services  from MacOS Server (for good reasons) and left Mac =
administrators alone with these always buggy OpenSource Operating =
Systems, then you get used to these free tinker alternatives. and after =
a while you even feel comfortably  at the vfs_ mount root-prompt, just =
to type in a question mark short before panic :-) =E2=80=A6=20
I assume that HPS` VoiceOver port to FreeBSD is  dedicated to Mac =
addicts=20
And because of that :  Isn=E2=80=99t it more =E2=80=9Eprivacy" with the =
AirPods Pro for this usecase  than with e.g. USB-speakers where =
everybody around can hear what comes out ;-)
=20
K.

..thanks for writing and of course I leave this thread now because I =
know this is a technical mailing list, and not suitable for =
philosophizing, but nevertheless very  interesting and thumbs up for HPS =
VoiceOver project


From nobody Sun Jul 10 17:28:05 2022
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 CF84117F843E;
	Sun, 10 Jul 2022 17:28:07 +0000 (UTC)
	(envelope-from glebius@freebsd.org)
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-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lgv9g0RL2z3WPZ;
	Sun, 10 Jul 2022 17:28:06 +0000 (UTC)
	(envelope-from glebius@freebsd.org)
Received: from cell.glebi.us (localhost [127.0.0.1])
	by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 26AHS5Vn034274
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 10 Jul 2022 10:28:05 -0700 (PDT)
	(envelope-from glebius@freebsd.org)
Received: (from glebius@localhost)
	by cell.glebi.us (8.16.1/8.16.1/Submit) id 26AHS55l034273;
	Sun, 10 Jul 2022 10:28:05 -0700 (PDT)
	(envelope-from glebius@freebsd.org)
X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f
Date: Sun, 10 Jul 2022 10:28:05 -0700
From: Gleb Smirnoff 
To: Andriy Gapon 
Cc: current@freebsd.org, virtualization@freebsd.org
Subject: Re: problem with bhyve, ryzen 5800x, freebsd guest
Message-ID: 
References: 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4Lgv9g0RL2z3WPZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org
X-Spamd-Result: default: False [-3.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[current,virtualization];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US];
	ARC_NA(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	DMARC_NA(0.00)[freebsd.org];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[glebius];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	HAS_XAW(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Jul 07, 2022 at 03:29:04PM +0300, Andriy Gapon wrote:
A> I have a strange issue with running an 'appliance' image based on 
A> FreeBSD 12 in bhyve on a machine with Ryzen 5800x processor.
A> 
A> The problem is that the guest would run for a while and then the host 
A> would suddenly reset itself.  It appears like a triple fault or 
A> something with similar consequences.
A> 
A> The time may be from a few dozens of minutes to many hours.
A> 
A> Just to be clear, no such thing occurs if I do not run the guest.
A> Also, I have an older AMD system (pre-Zen), the problem does not happen 
A> there.
A> A vanilla FreeBSD 12.3 installation that just sits idle also does not 
A> cause the problem.
A> 
A> Does anyone have an idea what the problem could be?
A> What workaround or diagnostics to try?
A> Anybody else seen something like this?
A> 
A> Since it's the host that resets it would be hard to capture any traces.

I also run bhyve on Ryzen since late 2021 and never had such an issue.
But not FreeBSD 12, I run the head.

-- 
Gleb Smirnoff

From nobody Sun Jul 10 21:54:49 2022
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 252B41D0160B
	for ; Sun, 10 Jul 2022 21:55:08 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lh15k3nppz46MM;
	Sun, 10 Jul 2022 21:55:06 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 611D62603FA;
	Sun, 10 Jul 2022 23:54:57 +0200 (CEST)
Message-ID: 
Date: Sun, 10 Jul 2022 23:54:49 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: Accessibility in the FreeBSD installer and console
Content-Language: en-US
To: =?UTF-8?Q?Klaus_K=c3=bcchemann?= ,
 Michael Gmelin , freebsd-current@freebsd.org
References: <080B179E-359E-4796-BFC8-0AAC65089100@googlemail.com>
 <788EF362-E06B-4BA9-BDDB-E550D35E21CB@freebsd.org>
 <4B9142D0-626B-43B0-A8EF-A71CB655E080@googlemail.com>
From: Hans Petter Selasky 
In-Reply-To: <4B9142D0-626B-43B0-A8EF-A71CB655E080@googlemail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Lh15k3nppz46MM
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current];
	FREEMAIL_TO(0.00)[googlemail.com,freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi Klaus and Michael,

I've tried to make some graphical QT v6.x cross platform so-called 
accessible applications. It is really hard to get it right. If you use 
one QT widget, everything is read perfectly in MacOS and if you use 
another QT widget, or a custom one, it is just not working. Or if you 
have a text editor you need to make sure you can tab out of it.

Then a friend of mine said he started to use mac-ports and asked if I 
can port my applications from AppStore to there, because it is so much 
easier for him to use --- sigh, why could he not just re-install his Mac 
M1 with FreeBSD. pkg has just about everything he needs! Only that he 
needs to learn a few things the FreeBSD way.

FreeBSD could beep all sound cards from 0 to 9 during single user mode 
for example, to indicate something is wrong. Some kind of espeak daemon 
could also be started from single user-mode.

FreeBSD could technically support USB audio from the USB loader. We do 
have a USB stack which can be built as a single-threaded blob into the 
loader, but probably using the bell character via the BIOS is simpler.

Many times when I see people use FreeBSD it is through Windows or MacOS. 
There is nothing wrong about that. I personally however prefer Windows 
through FreeBSD. Now if you would listen to me for a bit you will get 
why FreeBSD may be your only bet. Both Apple and Microsoft are totally 
tied up companies. I claim they can't do anything about computer 
programs that violates copyright law. You will be completely banned from 
their stores. But who would need to break "the law" to do something 
which most other people can do by not breaking the law?

I've personally had a dream about being able to play the piano, but my 
brain simply won't do it. So I made a computer program to fill the gaps. 
The problem is that many so-called TAB sites are full of "stupid" 
copyright protections, obfuscating all the simple plain-text everyone 
else can see with their plain eyes, I just need it for my program, with 
tons JavaScript parsing, to make the text non-machine readable:

Go here first and look at the CPU-usage and HTML source:
https://www.ultimate-guitar.com/

Then go here and compare:
https://nortabs.net

And nobody wants to use a program that can only play a 100 Norwegian 
songs, when UG has 1.4 million multi-national songs available, in 
exactly right format I need. You will find people tried to talk to UG, 
but with no success.

Is it legal to download movies using the Pirate bay if you are blind? 
Say you want all sub-titles on a braille device and need 
machine-readable subtitles?

What if you have some kind of other disability and really need 
machine-readable formats to do your job?

It's like being allowed to remove the copyright protection from that 
PDF, because you are not blind or deaf, but something else, which in the 
future will be mitigated by a machine.

The only option for Apple, Google and Microsoft products, is so-called 
jail-breaking and cracks, which often gets your device infected by viruses.

Apple says that all browsers on iOS must use the WebKit layout engine. 
That is so clever and I see another reason why. They don't want anyone 
to have access to machine readable formats, because then someone could 
remove all the ADs or someone could clone all the TABs on UG or blah 
blah blah.

What prevents you from feeding audio of an e-book back into Google 
translate and selling the resulting text?

What prevents you from OCR-ing ultimate-guitar?

It's getting late here now and I think I've shared enough thoughts for 
today. Hope you find something meaningful in what I've written.

--HPS

From nobody Sun Jul 10 22:25:59 2022
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 8CF0B1D06938
	for ; Sun, 10 Jul 2022 22:26:13 +0000 (UTC)
	(envelope-from christer.edwards@gmail.com)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lh1nb6WjKz3D4p
	for ; Sun, 10 Jul 2022 22:26:11 +0000 (UTC)
	(envelope-from christer.edwards@gmail.com)
Received: by mail-ej1-x631.google.com with SMTP id j22so6004695ejs.2
        for ; Sun, 10 Jul 2022 15:26:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=9yXUxK4LNs5p+BuSv/8I4OPOh9yvGF8jz8ozRlnnq2A=;
        b=kyAxW/Y1lut0F3bYKyTp24kjGxODvyBBSwU4BhIabUMusTroOhDMZEIRKrv38zfS1f
         H/nPYcAojx5SiEaeylgXPQmFpIlquVNMVDlq+wqX7Y/eWHWAtAK+AaxCoGyzYVO0SzTs
         N/BRf6N86yPDQy2botbqnqqWlCFQHL7hwdrFpDz5YVYu8Zn7ygF4TivzO+ExJ4MU//Xj
         xJGYIBoVqc7FpjiivqcbdtAn3169O5HMn2APqdTSt/7IH5SYdjMt0KeESzFsOx2N25n/
         TVFz1OcfNEWzBy10l3MbWeFaQgxKsQasNAkqlvMgZUdD2YoYgmlEH1X1WTwThq6i2IjD
         PNeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=9yXUxK4LNs5p+BuSv/8I4OPOh9yvGF8jz8ozRlnnq2A=;
        b=nKAM5mcjPixCsHfT2arEbyh5lMvww4mW7gVyqmop1voT81Vru+Ny0gUHqwGxT6l2WP
         h8/n2YXRf5iv8zUhnDJVBu0yv92d35+i7LAgZ9I7lwl4BIB1cMjo44eopnVjpO2AnosM
         Vg4v4Yay0fhiVznC3z3n7G3PcofQR0A2nJ+Qt9KMF7sE6aBTKK6cOTXPrQ3AAZwo2GmS
         2/t6LXLaqvdJBOv7Jl9yBIcZwW++rcPOCkn9esqhariZ7GiUB3NGftk3ipeo9jXg5twL
         KS9N8VnPavxb7pRR+T4XFFY1ebnWGpRGNK4llBP8D8lbRrp5wX0znjplNQf5eJkreLYC
         E9IA==
X-Gm-Message-State: AJIora8hgaazIwFkwXLnZJ8ULq55ULS96YCAD0MFlYpcXJ9kgNnLDHS9
	tMdbdWVYDzP2pkePgmWvSyQTDEgM02ig7ZgL5GiCGKU3clA=
X-Google-Smtp-Source: AGRyM1vtD/KVwYW4SnFclfADkN97cKB0AiJeKNfT6kv6Alhvdmt+D4V8zv0+jCnoIkLk0/26TDWCdUDgDrb0f9TPrPs=
X-Received: by 2002:a17:907:760d:b0:72b:5201:3f62 with SMTP id
 jx13-20020a170907760d00b0072b52013f62mr2730406ejc.454.1657491970280; Sun, 10
 Jul 2022 15:26:10 -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: <080B179E-359E-4796-BFC8-0AAC65089100@googlemail.com>
 <788EF362-E06B-4BA9-BDDB-E550D35E21CB@freebsd.org> <4B9142D0-626B-43B0-A8EF-A71CB655E080@googlemail.com>
 
In-Reply-To: 
From: Christer Edwards 
Date: Sun, 10 Jul 2022 16:25:59 -0600
Message-ID: 
Subject: Re: Accessibility in the FreeBSD installer and console
To: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000001b525d05e37aec31"
X-Rspamd-Queue-Id: 4Lh1nb6WjKz3D4p
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="kyAxW/Y1";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of christer.edwards@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=christer.edwards@gmail.com
X-Spamd-Result: default: False [-3.98 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.995];
	NEURAL_HAM_LONG(-0.99)[-0.986];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from];
	ARC_NA(0.00)[];
	TAGGED_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_NONE(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000001b525d05e37aec31
Content-Type: text/plain; charset="UTF-8"

unsubscribe

On Sun, Jul 10, 2022 at 3:55 PM Hans Petter Selasky  wrote:

> Hi Klaus and Michael,
>
> I've tried to make some graphical QT v6.x cross platform so-called
> accessible applications. It is really hard to get it right. If you use
> one QT widget, everything is read perfectly in MacOS and if you use
> another QT widget, or a custom one, it is just not working. Or if you
> have a text editor you need to make sure you can tab out of it.
>
> Then a friend of mine said he started to use mac-ports and asked if I
> can port my applications from AppStore to there, because it is so much
> easier for him to use --- sigh, why could he not just re-install his Mac
> M1 with FreeBSD. pkg has just about everything he needs! Only that he
> needs to learn a few things the FreeBSD way.
>
> FreeBSD could beep all sound cards from 0 to 9 during single user mode
> for example, to indicate something is wrong. Some kind of espeak daemon
> could also be started from single user-mode.
>
> FreeBSD could technically support USB audio from the USB loader. We do
> have a USB stack which can be built as a single-threaded blob into the
> loader, but probably using the bell character via the BIOS is simpler.
>
> Many times when I see people use FreeBSD it is through Windows or MacOS.
> There is nothing wrong about that. I personally however prefer Windows
> through FreeBSD. Now if you would listen to me for a bit you will get
> why FreeBSD may be your only bet. Both Apple and Microsoft are totally
> tied up companies. I claim they can't do anything about computer
> programs that violates copyright law. You will be completely banned from
> their stores. But who would need to break "the law" to do something
> which most other people can do by not breaking the law?
>
> I've personally had a dream about being able to play the piano, but my
> brain simply won't do it. So I made a computer program to fill the gaps.
> The problem is that many so-called TAB sites are full of "stupid"
> copyright protections, obfuscating all the simple plain-text everyone
> else can see with their plain eyes, I just need it for my program, with
> tons JavaScript parsing, to make the text non-machine readable:
>
> Go here first and look at the CPU-usage and HTML source:
> https://www.ultimate-guitar.com/
>
> Then go here and compare:
> https://nortabs.net
>
> And nobody wants to use a program that can only play a 100 Norwegian
> songs, when UG has 1.4 million multi-national songs available, in
> exactly right format I need. You will find people tried to talk to UG,
> but with no success.
>
> Is it legal to download movies using the Pirate bay if you are blind?
> Say you want all sub-titles on a braille device and need
> machine-readable subtitles?
>
> What if you have some kind of other disability and really need
> machine-readable formats to do your job?
>
> It's like being allowed to remove the copyright protection from that
> PDF, because you are not blind or deaf, but something else, which in the
> future will be mitigated by a machine.
>
> The only option for Apple, Google and Microsoft products, is so-called
> jail-breaking and cracks, which often gets your device infected by viruses.
>
> Apple says that all browsers on iOS must use the WebKit layout engine.
> That is so clever and I see another reason why. They don't want anyone
> to have access to machine readable formats, because then someone could
> remove all the ADs or someone could clone all the TABs on UG or blah
> blah blah.
>
> What prevents you from feeding audio of an e-book back into Google
> translate and selling the resulting text?
>
> What prevents you from OCR-ing ultimate-guitar?
>
> It's getting late here now and I think I've shared enough thoughts for
> today. Hope you find something meaningful in what I've written.
>
> --HPS
>
>

--0000000000001b525d05e37aec31
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


unsubscribe

On Sun, Jul 10, 2022 at 3:55 =
PM Hans Petter Selasky <hps@selasky.o=
rg> wrote:
https://www.ultimate-guitar.com/



Then go here and compare:

https:=
//nortabs.net



And nobody wants to use a program that can only play a 100 Norwegian 

songs, when UG has 1.4 million multi-national songs available, in 

exactly right format I need. You will find people tried to talk to UG, 

but with no success.



Is it legal to download movies using the Pirate bay if you are blind? 

Say you want all sub-titles on a braille device and need 

machine-readable subtitles?



What if you have some kind of other disability and really need 

machine-readable formats to do your job?



It's like being allowed to remove the copyright protection from that 
PDF, because you are not blind or deaf, but something else, which in the 
future will be mitigated by a machine.



The only option for Apple, Google and Microsoft products, is so-called 

jail-breaking and cracks, which often gets your device infected by viruses.=




Apple says that all browsers on iOS must use the WebKit layout engine. 

That is so clever and I see another reason why. They don't want anyone =


to have access to machine readable formats, because then someone could 

remove all the ADs or someone could clone all the TABs on UG or blah 

blah blah.



What prevents you from feeding audio of an e-book back into Google 

translate and selling the resulting text?



What prevents you from OCR-ing ultimate-guitar?



It's getting late here now and I think I've shared enough thoughts =
for 

today. Hope you find something meaningful in what I've written.



--HPS






--0000000000001b525d05e37aec31--

From nobody Mon Jul 11 15:43:03 2022
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 1F3AB17F8F08
	for ; Mon, 11 Jul 2022 15:43:05 +0000 (UTC)
	(envelope-from freqlabs@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LhSp10VMkz3CVv
	for ; Mon, 11 Jul 2022 15:43:05 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657554185;
	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=SutY1N9oAcjJ5CnZOdulcRmJIdk6nHIGWYCK69/dyrw=;
	b=ijev7v6ckXeKXqWaooZN9pj5C4ov4ZzRM2Lq2nePWNjHqoz/hLOZXPPEG+VmuvA7wI7J3d
	OTbLdNZ37TOZMRABQk0bnY3x8CZMnt1oZppX157MJEn2CdZHI5J1q1qy6f6kE8zZXZJtjD
	p6jBUi0h68f215c3pIstg1Mqbxk9rCWPw45Vl48lReQMbU9ZCx/thkoTSnIcwyp69C1Ikt
	0JcC62AWx0ED9CJlyYtKITV+HU9Q34ptZRO7lsjeZVDkKsGItoyrUgZp0wOdzVE2kR9RDk
	5MmzGvFpeMG1XsMddVRxpoTNI/dvnGftephXz91Zj2E9p+WOhB4dloCFhUkGpg==
Received: from [192.168.1.119] (69-228-200-148.lightspeed.knvltn.sbcglobal.net [69.228.200.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)
	(Authenticated sender: freqlabs/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LhSp06F6Rz1dp3
	for ; Mon, 11 Jul 2022 15:43:04 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
Message-ID: 
Date: Mon, 11 Jul 2022 11:43:03 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.11.0
Subject: Re: BLAKE3 unstability?
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <20220709162640.7my2bq6rax5npdhf@vax.khramtsov.org>
 <20220709175605.ofkoft2mglrkaqpf@vax.khramtsov.org>
From: Ryan Moeller 
In-Reply-To: <20220709175605.ofkoft2mglrkaqpf@vax.khramtsov.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657554185;
	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=SutY1N9oAcjJ5CnZOdulcRmJIdk6nHIGWYCK69/dyrw=;
	b=Sb/sb92Mrk/X2u+RrDBMAYAv7Gn8hiGxayJ4OBd7C8v1y4sgYchyk0i3kIdQ5ut1moUrEO
	ugNXlcvDw/j2OCD57XomGhsMPm3+7++7uCo47L4CQ1UJ+vidZp1h1fPflMo5P8RUOIHj4y
	dvpa0FiPwAnwIoAvdCLcofyFEzbfWGnEw2qZm90E+n2OPo47FSnJs/21sDTiIDD6I3SU0v
	RKT52ibKym5KUwDZRLuneYRp5yR+uo4nizGgQX+aS0ph79GNt+xesGG45+r2abmOCiL7As
	9DiJ4/wrySPPDDsH0NXDo/2yprT9EYwCa/cUb2BfwgPNHXpPEc39w9nD3ajRLw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657554185; a=rsa-sha256; cv=none;
	b=CEyiCOkIjiBLZwqu5C57cEpjyk8MUN3vnwcNEgchtC9tNWkkg4jeERJKcl3JODtaFHtSPO
	/Xg2KdGAH18hF47BwYG5/aHcrczX9+NAymzbdPWGtZ05+JmHaInFFFbjxrSHpeNRZD0QWl
	eoGz6aInGddWiGH0ikwQOoRx+qCm6r/rcL/ZtTtgUmgf1rrb9VP7QJaclRD0FSLa9SVtzo
	yfRHyi3dc8IsufqzLXXk2ri4Q94wK5fDOYYDxTBRnzMP9cJIMgKshSdxPYIDQP4l4TfNI5
	iDC6UnPSpq9/+qzBcBDjW56IJ0o9Jb6RGIQ6FmTy2n1aT9xCXeqt/joLUTRhGQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


On 7/9/22 1:56 PM, Evgeniy Khramtsov wrote:
> I can reproduce via:
>
> $ truncate -s 10G /tmp/test
> $ mdconfig -f /tmp/test -S 4096
> $ zpool create test /dev/md1
> $ zfs create -o checksum=blake3 test/b
> $ dd if=/dev/random of=/test/b/noise bs=1M count=4096
> $ sync
> $ zpool scrub test
> $ zpool status

I cannot reproduce this on openzfs/zfs@cb01da68057 (the commit that was 
most recently merged) built out of tree on either stable/13 70fd40edb86 
or main 9aa02d5120a.

I'll update a system and see if I can reproduce it with the in-tree ZFS.

- Ryan


From nobody Mon Jul 11 18:37:15 2022
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 E7C3A1D0A66F
	for ; Mon, 11 Jul 2022 18:37:16 +0000 (UTC)
	(envelope-from freqlabs@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LhXg06Frmz3Y4q
	for ; Mon, 11 Jul 2022 18:37:16 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657564636;
	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=1E4YA4IewhJs5eSsDIHm8nmr/MSOlSNgj+P05AnXsII=;
	b=cxXXgDOo4fUVrk/KtsM9YgB5b9g1CBz5y9I0EbCYXUsb40g1eCe7M1qidIswC/SojW4IOs
	9HFImiqO4VV8PpiJa8S8yWXvVOzMdjqgxXWY1T/fQU0KlOfTXr+//u++znQAek8+GHvJGr
	yLMRX5t8HW3U61tM+i3uq9rr1upNZjNih2eSZvt0qlUkJOBODayKI+ZkbZSJcvav72QxoQ
	kXyjPiSnR92rmiH6UOpVEoBZlJY1fI8QEHKVfqWpjIxCtLyTeOVnRF4QP1+KARSpDwhgGn
	72eQ0sIsoGLD60/HaDFgrEJGapQzZ/lfG7ucevK1qvJZ4pAj4Bpb68eG4aCfsg==
Received: from [192.168.1.119] (69-228-200-148.lightspeed.knvltn.sbcglobal.net [69.228.200.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)
	(Authenticated sender: freqlabs/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LhXg04h56zTKB
	for ; Mon, 11 Jul 2022 18:37:16 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
Content-Type: multipart/alternative;
 boundary="------------f316Ma4kSIBCsfrFj4xvK95l"
Message-ID: 
Date: Mon, 11 Jul 2022 14:37:15 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.11.0
Subject: Re: BLAKE3 unstability?
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <20220709162640.7my2bq6rax5npdhf@vax.khramtsov.org>
 <20220709175605.ofkoft2mglrkaqpf@vax.khramtsov.org>
 
From: Ryan Moeller 
In-Reply-To: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657564636;
	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=1E4YA4IewhJs5eSsDIHm8nmr/MSOlSNgj+P05AnXsII=;
	b=TZx3YfDL+33hwWjdm8Ea1mDoDv/Cac45bVaV9Bxagk8AcmswrJ6kOYTA32ge58P+iKs1t6
	2kc5pvQ8TYyXjRn5DQHqYsuNA1eIkireq7eXLlhR74e+DEX5opCZgqHVzwUDzgYU3tfFqH
	rt9Svml7qSRSVmYijtQSGH3wQR2Jfdn9jT6Ms7b5oHhBhpnZcDiR/qxYn3NvMXr/kOXndH
	M2zklgV41mV/Y21rSfZsbsQQl062FnI2CeR0o0wQuWILcwhcAMoeJiPoaUldMu/TgZLEzT
	8fw/YXftwG3+b0MT0fOcHhCYoUx0jrhvznx5Bov0jft+gc+Cip74sKmRiD9Q6Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657564636; a=rsa-sha256; cv=none;
	b=LnJRURvCewSMoZps898cQmJduauCuYOT0MVrSJJGc6kygpIsj4j0CBMyhkVUvsbnwLyQWZ
	eknHMHLmmugiYwhhyvVqNvB9mqCeZD0ee3jK+hPrDrsCM5ARpVVCPGVE5TZr/5u0WixhnI
	LHqpWTawgy3sNl6CMWnO/5VR4yu4aims1hUhBoagNM/aFQUHRDCNdGuPXesp1h9pu5jqbT
	OHm8lkg7hjhz90FzzOliFnXx51jovyN2duyNKc3s87NHCL+hcA1v5feRxa1HHAhtRgC1k9
	ba/Sr5IfpKFyIJGJzxn5OwSOqfUTU77IifgPxdxZBGn59IB4KGHVYwRHh24n/Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------f316Ma4kSIBCsfrFj4xvK95l
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 7/11/22 11:43 AM, Ryan Moeller wrote:
>
> On 7/9/22 1:56 PM, Evgeniy Khramtsov wrote:
>> I can reproduce via:
>>
>> $ truncate -s 10G /tmp/test
>> $ mdconfig -f /tmp/test -S 4096
>> $ zpool create test /dev/md1
>> $ zfs create -o checksum=blake3 test/b
>> $ dd if=/dev/random of=/test/b/noise bs=1M count=4096
>> $ sync
>> $ zpool scrub test
>> $ zpool status
>
> I cannot reproduce this on openzfs/zfs@cb01da68057 (the commit that 
> was most recently merged) built out of tree on either stable/13 
> 70fd40edb86 or main 9aa02d5120a.
>
> I'll update a system and see if I can reproduce it with the in-tree ZFS.
>
> - Ryan
>
It did not reproduce for me with in-tree ZFS on main@3c9ad9398fcd either.

Could you share sysctl kstat.zfs.misc.chksum_bench, maybe we are using 
different implementations?
I do see that blake3 went in with only a Linux module parameter for the 
implementation selection, so I'll have to fix that. For now we can at 
least see which was fastest, which should be the one selected. You just 
won't be able to manually change it to see if that helps.

- Ryan
--------------f316Ma4kSIBCsfrFj4xvK95l
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 7/11/22 11:43 AM, Ryan Moeller wrote:
    

    

      

      On 7/9/22 1:56 PM, Evgeniy Khramtsov wrote:
      

      
I can reproduce
        via:
        

        

        $ truncate -s 10G /tmp/test
        

        $ mdconfig -f /tmp/test -S 4096
        

        $ zpool create test /dev/md1
        

        $ zfs create -o checksum=blake3 test/b
        

        $ dd if=/dev/random of=/test/b/noise bs=1M count=4096
        

        $ sync
        

        $ zpool scrub test
        

        $ zpool status
        

      

      

      I cannot reproduce this on openzfs/zfs@cb01da68057 (the commit
      that was most recently merged) built out of tree on either
      stable/13 70fd40edb86 or main 9aa02d5120a.
      

      

      I'll update a system and see if I can reproduce it with the
      in-tree ZFS.
      

      

      - Ryan
      

      

    

    It did not reproduce for me with in-tree ZFS on main@3c9ad9398fcd
    either.
    

    

    Could you share sysctl kstat.zfs.misc.chksum_bench, maybe we are
    using different implementations?
    

    I do see that blake3 went in with only a Linux module parameter for
    the implementation selection, so I'll have to fix that. For now we
    can at least see which was fastest, which should be the one
    selected. You just won't be able to manually change it to see if
    that helps.
    

    

    - Ryan
  


--------------f316Ma4kSIBCsfrFj4xvK95l--

From nobody Mon Jul 11 20:04:38 2022
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 2BB0B17FA2F4
	for ; Mon, 11 Jul 2022 20:04:44 +0000 (UTC)
	(envelope-from evgeniy@khramtsov.org)
Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f])
	(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 4LhZbv2PPnz3mGV
	for ; Mon, 11 Jul 2022 20:04:43 +0000 (UTC)
	(envelope-from evgeniy@khramtsov.org)
Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f])
	by mxa.khramtsov.org (Postfix) with ESMTP id 23745125EB7
	for ; Mon, 11 Jul 2022 19:57:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khramtsov.org;
	s=rsa; t=1657569445;
	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=lCQ7wPSV3XT9BeMG9SQS0rxBOwnqdJx7CVBiUQmhRMc=;
	b=nfbJVJ/stiYltXT8N7XOn8JeqGXFMZKtxPOx9PJ+aO3gP5MdIbHzAIY+fnCMTtHPWfIdHK
	ywfztlXbWol6Hp4ZDWe+azOakZoXUUz787heKWo2zAHuo1pbeNKyKx1tZTZRjDFxOqVm6t
	C78gvel64kaB3uFUDz6q5GpCKpErZ1rsnCKglKWo9vthD+NYAY40DVMBZ0MnTR9ckGbzBt
	54iUOq2uXcIQ3UCUS1guAEigAh3KDlmF2o3G1CVx5Cm7ZGZ5h3KP/qhKl6cH7scIOaMwWb
	P/iTBLiJjIQiJUeD4fRxa61BcWmVIcAFxlmh4ReN1DKpe2VgYkC5lZ4xiaZDhQ==
Date: Mon, 11 Jul 2022 20:04:38 +0000
From: Evgeniy Khramtsov 
To: FreeBSD -CURRENT 
Subject: Re: BLAKE3 unstability?
Message-ID: <20220711200438.qsmpfcs2bi23ng7z@vax.khramtsov.org>
References: <20220709162640.7my2bq6rax5npdhf@vax.khramtsov.org>
 <20220709175605.ofkoft2mglrkaqpf@vax.khramtsov.org>
 
 
 <20220711200212.h74fo2bmkb22olkj@vax.khramtsov.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: <20220711200212.h74fo2bmkb22olkj@vax.khramtsov.org>
X-Rspamd-Queue-Id: 4LhZbv2PPnz3mGV
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=khramtsov.org header.s=rsa header.b="nfbJVJ/s";
	dmarc=pass (policy=reject) header.from=khramtsov.org;
	spf=pass (mx1.freebsd.org: domain of evgeniy@khramtsov.org designates 2a0a:e5c0:2:10f::f as permitted sender) smtp.mailfrom=evgeniy@khramtsov.org
X-Spamd-Result: default: False [-2.80 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[khramtsov.org,reject];
	R_DKIM_ALLOW(-0.20)[khramtsov.org:s=rsa];
	R_SPF_ALLOW(-0.20)[+ip6:2a0a:e5c0:2:10f::f:c];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	ONCE_RECEIVED(0.10)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[FreeBSD-CURRENT];
	RCVD_COUNT_ONE(0.00)[1];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	ASN(0.00)[asn:207996, ipnet:2a0a:e5c0:2::/48, country:CH];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[khramtsov.org:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

(forgot to CC -CURRENT, so replying to the list)

> It did not reproduce for me with in-tree ZFS on main@3c9ad9398fcd either.
> 
> Could you share sysctl kstat.zfs.misc.chksum_bench, maybe we are using
> different implementations?
> I do see that blake3 went in with only a Linux module parameter for the
> implementation selection, so I'll have to fix that. For now we can at least
> see which was fastest, which should be the one selected. You just won't be
> able to manually change it to see if that helps.
> 
> - Ryan
 
$ sysctl kstat.zfs.misc.chksum_bench
kstat.zfs.misc.chksum_bench:
implementation     1k      4k     16k     64k    256k      1m      4m
edonr-generic    1358    1580    1642    1642    1621    1560    1525
skein-generic     238     252     256     256     256     256     254
sha256-generic    242     263     269     271     271     271     271
sha512-generic    373     416     428     430     431     431     431
blake3-generic    482     478     477     474     473     473     473
blake3-sse2       338    1403    1505    1526    1519    1504    1503
blake3-sse41      350    1602    1725    1758    1753    1747    1747
blake3-avx2       350    1874    3336    3550    3527    3492    3485
 
Could it be due to SIMD? I can try a patch. I can also try with GENERIC
kernel tomorrow as it is the only local modification left. I thought it
also could be damaged hardware, but AVX2 torture tests and memtest runs
fine.
 
Thanks for investigating this issue.

From nobody Tue Jul 12 08:41:01 2022
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 3C4B11CFBE0B
	for ; Tue, 12 Jul 2022 08:41:18 +0000 (UTC)
	(envelope-from evgeniy@khramtsov.org)
Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f])
	(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 4LhvNs3Rl4z3PK9;
	Tue, 12 Jul 2022 08:41:17 +0000 (UTC)
	(envelope-from evgeniy@khramtsov.org)
Received: from mxa.khramtsov.org (mxa.khramtsov.org [IPv6:2a0a:e5c0:2:10f::f])
	by mxa.khramtsov.org (Postfix) with ESMTP id 8CE13125EB7;
	Tue, 12 Jul 2022 08:33:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khramtsov.org;
	s=rsa; t=1657614834;
	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=E4k1aw7i8YfVHDV+FyOOZaOM9oWQjr1oLunib2XJs0Y=;
	b=gcPvBdebb8lHnlUq9HCjFdTiRGkHiIYadP8RHOCAAjlu7dhDvddxIiLDyz8SGSeWo3Igvk
	MrP8pdJM4drSyFPjAEGxURhr0KGJ1hMdTNVv7/vzi+goR1QLHbHUY892/WxHfL0sWj3Gxt
	Brohz+2In0is+8S8qtWAPY32ORyJ7JUXTuERS2RHCEBWBg5lzLDbN4HSbtFUtmrOXUXVXi
	0s/A7HP6mXwmzQ+bfkYmxKNocBTJQSUvX1kHSFvImU7N3RB7L+/afVds6LNhSmfddjtpB1
	VZSotoMJ/K3JPTPyyHMPvOS0iDpV3m0FImz+BAvfxeQYxRPtKTDmyE5+m2OTEg==
Date: Tue, 12 Jul 2022 08:41:01 +0000
From: Evgeniy Khramtsov 
To: Ryan Moeller 
Cc: FreeBSD-CURRENT@FreeBSD.org
Subject: Re: BLAKE3 unstability?
Message-ID: <20220712084101.iqvwyfuhge6myteq@vax.khramtsov.org>
References: <20220709162640.7my2bq6rax5npdhf@vax.khramtsov.org>
 <20220709175605.ofkoft2mglrkaqpf@vax.khramtsov.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-Rspamd-Queue-Id: 4LhvNs3Rl4z3PK9
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=khramtsov.org header.s=rsa header.b=gcPvBdeb;
	dmarc=pass (policy=reject) header.from=khramtsov.org;
	spf=pass (mx1.freebsd.org: domain of evgeniy@khramtsov.org designates 2a0a:e5c0:2:10f::f as permitted sender) smtp.mailfrom=evgeniy@khramtsov.org
X-Spamd-Result: default: False [-2.80 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[khramtsov.org,reject];
	R_DKIM_ALLOW(-0.20)[khramtsov.org:s=rsa];
	R_SPF_ALLOW(-0.20)[+ip6:2a0a:e5c0:2:10f::f:c];
	RCVD_NO_TLS_LAST(0.10)[];
	ONCE_RECEIVED(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[FreeBSD-CURRENT];
	RCVD_COUNT_ONE(0.00)[1];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[khramtsov.org:+];
	ASN(0.00)[asn:207996, ipnet:2a0a:e5c0:2::/48, country:CH];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> > > I can reproduce via:
> > > 
> > > $ truncate -s 10G /tmp/test
> > > $ mdconfig -f /tmp/test -S 4096
> > > $ zpool create test /dev/md1
> > > $ zfs create -o checksum=blake3 test/b
> > > $ dd if=/dev/random of=/test/b/noise bs=1M count=4096
> > > $ sync
> > > $ zpool scrub test
> > > $ zpool status
> > 
> > I cannot reproduce this on openzfs/zfs@cb01da68057 (the commit that was
> > most recently merged) built out of tree on either stable/13 70fd40edb86
> > or main 9aa02d5120a.
> > 
> > I'll update a system and see if I can reproduce it with the in-tree ZFS.
> > 
> > - Ryan
> > 
> It did not reproduce for me with in-tree ZFS on main@3c9ad9398fcd either.
> 
> Could you share sysctl kstat.zfs.misc.chksum_bench, maybe we are using
> different implementations?
> I do see that blake3 went in with only a Linux module parameter for the
> implementation selection, so I'll have to fix that. For now we can at least
> see which was fastest, which should be the one selected. You just won't be
> able to manually change it to see if that helps.
> 
> - Ryan

I found the culprit (kernel and base from download.FreeBSD.org
kernel.txz and base.txz respectively) (I forgot about local sysctl.conf...):

kern.sched.steal_thresh=1
kern.sched.preempt_thresh=121

Then

#!/bin/sh

truncate -s 10G /tmp/test
mdconfig -f /tmp/test -S 4096
zpool create test /dev/md0
zfs create -o checksum=blake3 test/b
dd if=/dev/random of=/test/b/noise bs=1M count=4096
sync
zpool scrub test
sleep 3
zpool status

zpool destroy test
mdconfig -d -u 0
rm /tmp/test

As for ULE "tuning", these values give me fine desktop interactivity
when building lang/rust when nice and idprio did not help, so I left
them in sysctl.conf. Not sure if scheduling parameters are worthy of
a ZFS PR, maybe something essential is preempted.

From nobody Tue Jul 12 18:33:47 2022
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 C488D1D048F0
	for ; Tue, 12 Jul 2022 18:33:49 +0000 (UTC)
	(envelope-from jhb@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lj8XY5CvPz3nGJ;
	Tue, 12 Jul 2022 18:33:49 +0000 (UTC)
	(envelope-from jhb@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657650829;
	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=JDpgxYoZpK5G41rZ43rfjBAnDpNfbM6xrWD03iNQtts=;
	b=ONsD2GMG+soIv3irJ/e6serSm0bq6RH02+wOB1mbUIpsIFYUBSQTiz4yPYJKnkyEQSFzT/
	1XM2kH33V8BOeBYGe9veFzt88b+wjHWPP9f/Ds+KXS+UN9DcBgaZhZHMZxPN9AAfo4Ii4O
	DPuAI6ezClJlgvIICMJ+21MV+zx1GeRW7cq1wm8PKrhxvCCg5FKqToA+IFxXtox2WbiCWr
	I5UcN07m+jsiAKAYUk43dU7DElz43gZ7NXhY+xpOjYGyIRPYdHq5CJe/joKcRoAdxUbYPi
	F5z+29O0fr3NRqrVpieOO0iSWhZSMx0OOAEP5R3p5S8kUJZBtNYBRVHZUfi1fg==
Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215])
	(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: jhb)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Lj8XY1MPwzrbk;
	Tue, 12 Jul 2022 18:33:49 +0000 (UTC)
	(envelope-from jhb@FreeBSD.org)
Message-ID: <653d1a91-1468-ba15-5365-87a63ed0e2d1@FreeBSD.org>
Date: Tue, 12 Jul 2022 11:33:47 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.10.0
Subject: Re: BLAKE3 unstability?
Content-Language: en-US
To: Evgeniy Khramtsov ,
 Ryan Moeller 
Cc: FreeBSD-CURRENT@FreeBSD.org
References: <20220709162640.7my2bq6rax5npdhf@vax.khramtsov.org>
 <20220709175605.ofkoft2mglrkaqpf@vax.khramtsov.org>
 
 
 <20220712084101.iqvwyfuhge6myteq@vax.khramtsov.org>
From: John Baldwin 
In-Reply-To: <20220712084101.iqvwyfuhge6myteq@vax.khramtsov.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657650829;
	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=JDpgxYoZpK5G41rZ43rfjBAnDpNfbM6xrWD03iNQtts=;
	b=w0h5KHC3DJ3iGCZ3lgTh/nw46fWoQ4x++sUnRwKexboLkibjprP9/VZ03K0pCfa0b6nJEr
	o9YM/M85oUgwjjkcVtkq1mw/MvBi02+daRgQ+75m9aGJ7scNjuaKBDOb4V+z25jtKZyAAb
	U02Wr09uHvHMpnUgeSYYgUi3etrm3wEmOuej2iUypZPSjsP8CnPLyYWrrU0qz81g62akob
	N0ygQZrKe7JkYDecT0CPUs8Cls462YjHoLk0S3mwxM4TGd5TofqdSxO68ZI/0nkqEc3BL3
	mQED5uVeNigK+YzjFY2/R/5Hqs96CGJxaJ0x4j4AtCgxzJJPS8EAmcERQ/tnag==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657650829; a=rsa-sha256; cv=none;
	b=a0FSDlKh5z68lXcUe6WVQi3ZHfSYtCFKclPAVouLHOhBQsa52tEuwPz7MTF0JUwUPKTmdm
	1/RNdUgGbBb/hytuVXBauHp9GcQZndgEbQPEC2DNQ0kScfIP1hqKjwn8rqfpUHGy7uBiZx
	AdEzftqpWCnjQXkpEs6quu/K+IWrV5hjnIg8JtZezht4svVciQfdZ8xwqcHDP+Olt2sUpf
	yvJ6E+K9tkYcRoKoKfD4BOiZBlNNvAU951G5lGmjjSOdv07nKm9m5q6GKmSdieyftq7Ihk
	RcDl0N+LkoShXUCsWVlUoiA3OTcuBXBamSe9g04h8wxpEVVW1aZTnEVqjNSexg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 7/12/22 1:41 AM, Evgeniy Khramtsov wrote:
>>>> I can reproduce via:
>>>>
>>>> $ truncate -s 10G /tmp/test
>>>> $ mdconfig -f /tmp/test -S 4096
>>>> $ zpool create test /dev/md1
>>>> $ zfs create -o checksum=blake3 test/b
>>>> $ dd if=/dev/random of=/test/b/noise bs=1M count=4096
>>>> $ sync
>>>> $ zpool scrub test
>>>> $ zpool status
>>>
>>> I cannot reproduce this on openzfs/zfs@cb01da68057 (the commit that was
>>> most recently merged) built out of tree on either stable/13 70fd40edb86
>>> or main 9aa02d5120a.
>>>
>>> I'll update a system and see if I can reproduce it with the in-tree ZFS.
>>>
>>> - Ryan
>>>
>> It did not reproduce for me with in-tree ZFS on main@3c9ad9398fcd either.
>>
>> Could you share sysctl kstat.zfs.misc.chksum_bench, maybe we are using
>> different implementations?
>> I do see that blake3 went in with only a Linux module parameter for the
>> implementation selection, so I'll have to fix that. For now we can at least
>> see which was fastest, which should be the one selected. You just won't be
>> able to manually change it to see if that helps.
>>
>> - Ryan
> 
> I found the culprit (kernel and base from download.FreeBSD.org
> kernel.txz and base.txz respectively) (I forgot about local sysctl.conf...):
> 
> kern.sched.steal_thresh=1
> kern.sched.preempt_thresh=121
> 
> Then
> 
> #!/bin/sh
> 
> truncate -s 10G /tmp/test
> mdconfig -f /tmp/test -S 4096
> zpool create test /dev/md0
> zfs create -o checksum=blake3 test/b
> dd if=/dev/random of=/test/b/noise bs=1M count=4096
> sync
> zpool scrub test
> sleep 3
> zpool status
> 
> zpool destroy test
> mdconfig -d -u 0
> rm /tmp/test
> 
> As for ULE "tuning", these values give me fine desktop interactivity
> when building lang/rust when nice and idprio did not help, so I left
> them in sysctl.conf. Not sure if scheduling parameters are worthy of
> a ZFS PR, maybe something essential is preempted.

It could be missing fpu_kern_enter/leave that lack of preemption would
cover over.  I thought that missing that would give a panic in the
kernel though due to FPU instructions being disabled (including vector
instructions).  Maybe ZFS isn't using fpu_kern_enter(FPU_NOCTX) and is
instead trying to juggle contexts and it has a bug in how it manages
saved FPU contexts and reuses a context?  If so, I would just suggest
that ZFS switch to using FPU_KERN_NOCTX instead which runs all SSE
type code in a critical section to disable preemption but avoids
having to allocate and manage FPU contexts.

-- 
John Baldwin

From nobody Wed Jul 13 07:29:06 2022
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 714461D21DAF
	for ; Wed, 13 Jul 2022 07:29:11 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197])
	(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 4LjTlB3HPRz3HfV
	for ; Wed, 13 Jul 2022 07:29:10 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Received: (Authenticated sender: andriy.gapon@uabsd.com)
	by mail.gandi.net (Postfix) with ESMTPSA id 71ABC1C0006
	for ; Wed, 13 Jul 2022 07:29:08 +0000 (UTC)
Message-ID: <81814ba9-5040-c102-dad4-0a69f3c46121@FreeBSD.org>
Date: Wed, 13 Jul 2022 10:29:06 +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/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.11.0
Content-Language: en-US
To: current@freebsd.org
From: Andriy Gapon 
Subject: pkg: Newer FreeBSD version for package... but why?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LjTlB3HPRz3HfV
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 217.70.183.197 is neither permitted nor denied by domain of avg@FreeBSD.org) smtp.mailfrom=avg@FreeBSD.org
X-Spamd-Result: default: False [-2.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.197:from];
	DMARC_NA(0.00)[freebsd.org];
	MLMMJ_DEST(0.00)[current];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	FREEFALL_USER(0.00)[avg];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	TO_DOM_EQ_FROM_DOM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


# uname -U
1400063

# uname -K
1400063

# pkg upgrade
Updating FreeBSD repository catalogue...
Fetching packagesite.pkg: 100%    5 MiB   4.8MB/s    00:01
Processing entries:   0%
Newer FreeBSD version for package zyre:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1400063
- running kernel: 1400051
Ignore the mismatch and continue? [y/N]:

Does anyone know why this would happen?
Where does pkg get its notion of the running kernel version?

-- 
Andriy Gapon


https://standforukraine.com
https://razomforukraine.org

From nobody Wed Jul 13 10:09:00 2022
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 E1D131D01D59
	for ; Wed, 13 Jul 2022 10:09:29 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LjYJ871Dhz3fDh;
	Wed, 13 Jul 2022 10:09:28 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id 2920f9b7;
	Wed, 13 Jul 2022 10:09:21 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 4f29a341 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Wed, 13 Jul 2022 10:09:21 +0000 (UTC)
Date: Wed, 13 Jul 2022 12:09:00 +0200
From: Michael Gmelin 
To: Andriy Gapon 
Cc: current@freebsd.org
Subject: Re: pkg: Newer FreeBSD version for package... but why?
Message-ID: <20220713120900.63cd5639.grembo@freebsd.org>
In-Reply-To: <81814ba9-5040-c102-dad4-0a69f3c46121@FreeBSD.org>
References: <81814ba9-5040-c102-dad4-0a69f3c46121@FreeBSD.org>
X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}>
 +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl
 LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL
 EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl
 YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq
 AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY
 fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM
 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea
 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+
 xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA
 Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n
 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v
 f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT
 L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF
 CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc
 Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII=
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LjYJ871Dhz3fDh
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-1.10 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[current];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	R_SPF_SOFTFAIL(0.00)[~all];
	ARC_NA(0.00)[];
	FREEFALL_USER(0.00)[grembo];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On Wed, 13 Jul 2022 10:29:06 +0300
Andriy Gapon  wrote:

> # uname -U
> 1400063
> 
> # uname -K
> 1400063
> 
> # pkg upgrade
> Updating FreeBSD repository catalogue...
> Fetching packagesite.pkg: 100%    5 MiB   4.8MB/s    00:01
> Processing entries:   0%
> Newer FreeBSD version for package zyre:
> To ignore this error set IGNORE_OSVERSION=yes
> - package: 1400063
> - running kernel: 1400051
> Ignore the mismatch and continue? [y/N]:
> 
> Does anyone know why this would happen?
> Where does pkg get its notion of the running kernel version?
> 

If I'm reading the sources correctly, it's determining the OS version
by looking at the elf headers of various files in this order:

    getenv("ABI_FILE")
    /usr/bin/uname
    /bin/sh

So I would assume that `file /usr/bin/uname` shows 1400051 on your
system.

You can point it to checking another file by setting ABI_FILE[0] in the
environment or ignore the check by setting IGNORE_OSVERSION (like
advised). The "running kernel:" label seems a bit misleading.

Cheers
Michael

-- 
Michael Gmelin

From nobody Wed Jul 13 10:17:50 2022
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 044001D038A4
	for ; Wed, 13 Jul 2022 10:17:55 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230])
	(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 4LjYTt1MGVz3h06;
	Wed, 13 Jul 2022 10:17:54 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Received: (Authenticated sender: andriy.gapon@uabsd.com)
	by mail.gandi.net (Postfix) with ESMTPSA id E97A224000D;
	Wed, 13 Jul 2022 10:17:51 +0000 (UTC)
Message-ID: 
Date: Wed, 13 Jul 2022 13:17:50 +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/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.11.0
Subject: Re: pkg: Newer FreeBSD version for package... but why?
Content-Language: en-US
To: Michael Gmelin 
Cc: current@freebsd.org
References: <81814ba9-5040-c102-dad4-0a69f3c46121@FreeBSD.org>
 <20220713120900.63cd5639.grembo@freebsd.org>
From: Andriy Gapon 
In-Reply-To: <20220713120900.63cd5639.grembo@freebsd.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LjYTt1MGVz3h06
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 217.70.178.230 is neither permitted nor denied by domain of avg@FreeBSD.org) smtp.mailfrom=avg@FreeBSD.org
X-Spamd-Result: default: False [-2.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[217.70.178.230:from];
	MLMMJ_DEST(0.00)[current];
	ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[avg];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-07-13 13:09, Michael Gmelin wrote:
> 
> 
> On Wed, 13 Jul 2022 10:29:06 +0300
> Andriy Gapon  wrote:
> 
>> # uname -U
>> 1400063
>>
>> # uname -K
>> 1400063
>>
>> # pkg upgrade
>> Updating FreeBSD repository catalogue...
>> Fetching packagesite.pkg: 100%    5 MiB   4.8MB/s    00:01
>> Processing entries:   0%
>> Newer FreeBSD version for package zyre:
>> To ignore this error set IGNORE_OSVERSION=yes
>> - package: 1400063
>> - running kernel: 1400051
>> Ignore the mismatch and continue? [y/N]:
>>
>> Does anyone know why this would happen?
>> Where does pkg get its notion of the running kernel version?
>>
> 
> If I'm reading the sources correctly, it's determining the OS version
> by looking at the elf headers of various files in this order:
> 
>      getenv("ABI_FILE")
>      /usr/bin/uname
>      /bin/sh
> 
> So I would assume that `file /usr/bin/uname` shows 1400051 on your
> system.

Thank you very much!  That's it:
# file /usr/bin/uname
/usr/bin/uname: ELF 32-bit LSB executable, ARM, EABI5 version 1 
(FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, 
FreeBSD-style, for FreeBSD 14.0 (1400051), stripped

> You can point it to checking another file by setting ABI_FILE[0] in the
> environment or ignore the check by setting IGNORE_OSVERSION (like
> advised). The "running kernel:" label seems a bit misleading.

Indeed.

Now the next thing (for me) to research is why the binaries were built 
"for FreeBSD 14.0 (1400051)" when the source tree has 1400063 and uname 
-U also reports 1400063.
FWIW, this was a cross-build, maybe that played a role too.


-- 
Andriy Gapon


https://standforukraine.com
https://razomforukraine.org

From nobody Wed Jul 13 18:33:10 2022
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 D89B31D0A1B3
	for ; Wed, 13 Jul 2022 18:33:12 +0000 (UTC)
	(envelope-from jhb@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LjmTN5mfGz3wQL;
	Wed, 13 Jul 2022 18:33:12 +0000 (UTC)
	(envelope-from jhb@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657737192;
	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=6JkoSYOUkhjqxdG6UkbO3y3DeW+7fSpGwmghDKHpuYs=;
	b=LlQuTo+d5R+PfI4KuxzlGgwzKpwMNkrysBZI4+qyvb68UyxjGT/On9t4y34lJOT+S/wLBV
	1Kd9XDSksEHdI99AFefEoWujgtSEF+RDSiSItRbKFLp4r8B02Y25FAqqtYeX0Vmr//W81u
	zV4ruG3ilKYpQfhgLPpL876N504TOVNExVlFjmukLSHuCYTTjK01VN9d1ZNi3/SNixvB7v
	R2PC8UqG3tpDTPF9p5FRJoiOSnhSGPVIaJ0jKpWj5D4Cl3I17k/3uJl05bnzwtbtat3jSQ
	t7NKwkYH0R0pkWParuuqd6lTt9Zs2CGnF6YpJ2rzZzdTC54lNORml10Wq29dxw==
Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215])
	(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: jhb)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LjmTN20Lcz1Hjk;
	Wed, 13 Jul 2022 18:33:12 +0000 (UTC)
	(envelope-from jhb@FreeBSD.org)
Message-ID: <402cf119-b07e-76fd-48b6-50eeb9b4508f@FreeBSD.org>
Date: Wed, 13 Jul 2022 11:33:10 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.11.0
Subject: Re: pkg: Newer FreeBSD version for package... but why?
Content-Language: en-US
To: Andriy Gapon , Michael Gmelin 
Cc: current@freebsd.org
References: <81814ba9-5040-c102-dad4-0a69f3c46121@FreeBSD.org>
 <20220713120900.63cd5639.grembo@freebsd.org>
 
From: John Baldwin 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657737192;
	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=6JkoSYOUkhjqxdG6UkbO3y3DeW+7fSpGwmghDKHpuYs=;
	b=n16oF//XKIyEfarXV1lfscL+dfD2NwSKg87MGFTi88nBu5i6ilQHpRMhPH+Wcqz65bDErv
	L3EeCYFmjYZXJtpoQ805Uc73xOohGPbOe9O3+KdltlKF6L7DITZkosLkXc0PudKMt2CEki
	bo/YUfMZPossdLCeEBG/3mCciDCW2dKSfYxporhrxy8RHBc8fOObyDuBWjFI0SE323JCHT
	Fkj9vTqQOcKoQmd+jLk++gHEfXDjcBaPy3iX0oXUQrP7yBHSC473z7ESEi7UOLskFuo3TM
	sbhpHncou/OktD1U47u0BMqlNFyB3cDn9HOhQWcsy6QwCgIBhH6WdWLOhePM3w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657737192; a=rsa-sha256; cv=none;
	b=CQKJIeoV2ZfXZdc2VCWjCxbFjIK2bkVNT8hQE5zX+ZtP3ArPVMS1eI9keGutfePUOVioHM
	ZaasG85IoI4on4ozZZSh6L1C6HpxbbgJ5PjgwZoxbdwW0UVPvw2lnm5QHpKsMVzkc5C3An
	NcbEhQd0F2W93xQ1Tx+7CaoxB/0c0InPsjckWxVtNmDb2gn1EsUwRnjJmdhsurBJ1Bndoi
	8v4rTyfPczKunJ+YF55mBEPaw18e3bb56C5nv0pTMrrHTxoURCtPRIMg7xwoaM2CuUEGjP
	zDXCHhPMVCR5EBW2Su0qZ4uhvlQYfAoTSKYs8BtDHLiXUoDrIdaum+roqFDY7A==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 7/13/22 3:17 AM, Andriy Gapon wrote:
> On 2022-07-13 13:09, Michael Gmelin wrote:
>>
>>
>> On Wed, 13 Jul 2022 10:29:06 +0300
>> Andriy Gapon  wrote:
>>
>>> # uname -U
>>> 1400063
>>>
>>> # uname -K
>>> 1400063
>>>
>>> # pkg upgrade
>>> Updating FreeBSD repository catalogue...
>>> Fetching packagesite.pkg: 100%    5 MiB   4.8MB/s    00:01
>>> Processing entries:   0%
>>> Newer FreeBSD version for package zyre:
>>> To ignore this error set IGNORE_OSVERSION=yes
>>> - package: 1400063
>>> - running kernel: 1400051
>>> Ignore the mismatch and continue? [y/N]:
>>>
>>> Does anyone know why this would happen?
>>> Where does pkg get its notion of the running kernel version?
>>>
>>
>> If I'm reading the sources correctly, it's determining the OS version
>> by looking at the elf headers of various files in this order:
>>
>>       getenv("ABI_FILE")
>>       /usr/bin/uname
>>       /bin/sh
>>
>> So I would assume that `file /usr/bin/uname` shows 1400051 on your
>> system.
> 
> Thank you very much!  That's it:
> # file /usr/bin/uname
> /usr/bin/uname: ELF 32-bit LSB executable, ARM, EABI5 version 1
> (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1,
> FreeBSD-style, for FreeBSD 14.0 (1400051), stripped
> 
>> You can point it to checking another file by setting ABI_FILE[0] in the
>> environment or ignore the check by setting IGNORE_OSVERSION (like
>> advised). The "running kernel:" label seems a bit misleading.
> 
> Indeed.
> 
> Now the next thing (for me) to research is why the binaries were built
> "for FreeBSD 14.0 (1400051)" when the source tree has 1400063 and uname
> -U also reports 1400063.
> FWIW, this was a cross-build, maybe that played a role too.

If you do a NO_CLEAN=yes build, we don't relink binaries just because
crt*.o changed (where the note is stored).

-- 
John Baldwin

From nobody Wed Jul 13 19:13:24 2022
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 8DE151D0F3D7
	for ; Wed, 13 Jul 2022 19:13:37 +0000 (UTC)
	(envelope-from christer.edwards@gmail.com)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LjnN068fDz43Jj
	for ; Wed, 13 Jul 2022 19:13:36 +0000 (UTC)
	(envelope-from christer.edwards@gmail.com)
Received: by mail-ej1-x632.google.com with SMTP id oy13so16678939ejb.1
        for ; Wed, 13 Jul 2022 12:13:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=x3KLgSNu/0xLA9WH3S4vHw0CA/dA1L3puLCMdqdfEYQ=;
        b=UUc36ggh/lFkKI2jBEoVWtfzy/2x2wIkyN8sDPkwnVbqDswXZahO9KMx7gGiJVxu4Y
         ItQ891qVsq2V/hmwaaPx073wJ47nAbOUX5J1/LDOP1szNhpZtx1BKOKqEKzn9mDHgMHs
         dbJGspxCLCTEei7nUH5a/eH95RlXilRp0michPH5hDpviR7S+I04kbUp+eNhsRwgjQoV
         1Ksnq1UelLRY75EPpE+086OcLDbpcbIqCjW5EegTAyZ4IOzN0OI3C4h40N/9bKxNvzTX
         KcTCxMYE3Yvclw2cN0fv0O3z+zLqNqtRNMh2gGL9aVXMZw++4PyDhUdsToV9yOhtFjKC
         3hgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=x3KLgSNu/0xLA9WH3S4vHw0CA/dA1L3puLCMdqdfEYQ=;
        b=FHS/gaRb8hvSAYnTtUyc0IVIR66udX86qeCFk7DDJgWF43diex7FBTjdZ/hc0w9fAv
         7YLhknJ7EL1l0YvLzwuPh11qv9c9kQblnXi7x3GzZTXINCSFHOlUioCIPJrfJ8WHWM1o
         RWta5DdTKbmN16D2RpQYPL2JIXM4n9dmAJlEWWAML3CVQtBrWzMKJbG91j1A+063SguX
         tEawEDelttI+1ogie9FVo121Co2z6fhCTf+hMKIs81nLvhWx1qReErUcI32++D/98Qg8
         R11Udp6Uf+6UzZ0yikpo0LrZxBa8p2fEHokVLriIaqGcOoJcJSJGAfBs5t9BoxQCqCT+
         wXaw==
X-Gm-Message-State: AJIora98BzN4FPePaJo7ojESpjoy/iI7++OZANOSOONXBbwQ6I9HBmWg
	r0P+5Wt7vytJBfDnAU7gIRwfvZSmyt9lXlD1VGjsat6cEVE=
X-Google-Smtp-Source: AGRyM1sBJYqt95Urs1i74yfM3xl4kzACo0GNOz5aoeCoYtCnwU9H201r6W32JmWTXASceL3QnhaglbZ4jKkvyZrqdFs=
X-Received: by 2002:a17:907:3f29:b0:72b:91df:2c4b with SMTP id
 hq41-20020a1709073f2900b0072b91df2c4bmr4980956ejc.206.1657739615195; Wed, 13
 Jul 2022 12:13:35 -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: <81814ba9-5040-c102-dad4-0a69f3c46121@FreeBSD.org>
 <20220713120900.63cd5639.grembo@freebsd.org> 
 <402cf119-b07e-76fd-48b6-50eeb9b4508f@FreeBSD.org>
In-Reply-To: <402cf119-b07e-76fd-48b6-50eeb9b4508f@FreeBSD.org>
From: Christer Edwards 
Date: Wed, 13 Jul 2022 13:13:24 -0600
Message-ID: 
Subject: Re: pkg: Newer FreeBSD version for package... but why?
To: current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000e4d6f405e3b494d5"
X-Rspamd-Queue-Id: 4LjnN068fDz43Jj
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=UUc36ggh;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of christer.edwards@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=christer.edwards@gmail.com
X-Spamd-Result: default: False [-2.94 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.94)[-0.944];
	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=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::632:from];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	MLMMJ_DEST(0.00)[current];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_NONE(0.00)[];
	TAGGED_FROM(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e4d6f405e3b494d5
Content-Type: text/plain; charset="UTF-8"

unsubscribe

On Wed, Jul 13, 2022 at 12:33 PM John Baldwin  wrote:

> On 7/13/22 3:17 AM, Andriy Gapon wrote:
> > On 2022-07-13 13:09, Michael Gmelin wrote:
> >>
> >>
> >> On Wed, 13 Jul 2022 10:29:06 +0300
> >> Andriy Gapon  wrote:
> >>
> >>> # uname -U
> >>> 1400063
> >>>
> >>> # uname -K
> >>> 1400063
> >>>
> >>> # pkg upgrade
> >>> Updating FreeBSD repository catalogue...
> >>> Fetching packagesite.pkg: 100%    5 MiB   4.8MB/s    00:01
> >>> Processing entries:   0%
> >>> Newer FreeBSD version for package zyre:
> >>> To ignore this error set IGNORE_OSVERSION=yes
> >>> - package: 1400063
> >>> - running kernel: 1400051
> >>> Ignore the mismatch and continue? [y/N]:
> >>>
> >>> Does anyone know why this would happen?
> >>> Where does pkg get its notion of the running kernel version?
> >>>
> >>
> >> If I'm reading the sources correctly, it's determining the OS version
> >> by looking at the elf headers of various files in this order:
> >>
> >>       getenv("ABI_FILE")
> >>       /usr/bin/uname
> >>       /bin/sh
> >>
> >> So I would assume that `file /usr/bin/uname` shows 1400051 on your
> >> system.
> >
> > Thank you very much!  That's it:
> > # file /usr/bin/uname
> > /usr/bin/uname: ELF 32-bit LSB executable, ARM, EABI5 version 1
> > (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1,
> > FreeBSD-style, for FreeBSD 14.0 (1400051), stripped
> >
> >> You can point it to checking another file by setting ABI_FILE[0] in the
> >> environment or ignore the check by setting IGNORE_OSVERSION (like
> >> advised). The "running kernel:" label seems a bit misleading.
> >
> > Indeed.
> >
> > Now the next thing (for me) to research is why the binaries were built
> > "for FreeBSD 14.0 (1400051)" when the source tree has 1400063 and uname
> > -U also reports 1400063.
> > FWIW, this was a cross-build, maybe that played a role too.
>
> If you do a NO_CLEAN=yes build, we don't relink binaries just because
> crt*.o changed (where the note is stored).
>
> --
> John Baldwin
>
>

--000000000000e4d6f405e3b494d5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


unsubscribe

On Wed, Jul 13, 2022 at 12:33=
 PM John Baldwin <jhb@freebsd.org=
> wrote:
On 7=
/13/22 3:17 AM, Andriy Gapon wrote:

> On 2022-07-13 13:09, Michael Gmelin wrote:

>>

>>

>> On Wed, 13 Jul 2022 10:29:06 +0300

>> Andriy Gapon <avg@FreeBSD.org> wrote:

>>

>>> # uname -U

>>> 1400063

>>>

>>> # uname -K

>>> 1400063

>>>

>>> # pkg upgrade

>>> Updating FreeBSD repository catalogue...

>>> Fetching packagesite.pkg: 100%=C2=A0 =C2=A0 5 MiB=C2=A0 =C2=A0=
4.8MB/s=C2=A0 =C2=A0 00:01

>>> Processing entries:=C2=A0 =C2=A00%

>>> Newer FreeBSD version for package zyre:

>>> To ignore this error set IGNORE_OSVERSION=3Dyes

>>> - package: 1400063

>>> - running kernel: 1400051

>>> Ignore the mismatch and continue? [y/N]:

>>>

>>> Does anyone know why this would happen?

>>> Where does pkg get its notion of the running kernel version?
>>>

>>

>> If I'm reading the sources correctly, it's determining the=
 OS version

>> by looking at the elf headers of various files in this order:

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0getenv("ABI_FILE")

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/bin/uname

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0/bin/sh

>>

>> So I would assume that `file /usr/bin/uname` shows 1400051 on your=


>> system.

> 

> Thank you very much!=C2=A0 That's it:

> # file /usr/bin/uname

> /usr/bin/uname: ELF 32-bit LSB executable, ARM, EABI5 version 1

> (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1,

> FreeBSD-style, for FreeBSD 14.0 (1400051), stripped

> 

>> You can point it to checking another file by setting ABI_FILE[0] i=
n the

>> environment or ignore the check by setting IGNORE_OSVERSION (like<=
br>
>> advised). The "running kernel:" label seems a bit mislea=
ding.

> 

> Indeed.

> 

> Now the next thing (for me) to research is why the binaries were built=


> "for FreeBSD 14.0 (1400051)" when the source tree has 140006=
3 and uname

> -U also reports 1400063.

> FWIW, this was a cross-build, maybe that played a role too.



If you do a NO_CLEAN=3Dyes build, we don't relink binaries just because=


crt*.o changed (where the note is stored).



-- 

John Baldwin






--000000000000e4d6f405e3b494d5--

From nobody Fri Jul 15 19:51:06 2022
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 4Ll26V3Y61z4WTZk
	for ; Fri, 15 Jul 2022 19:51:14 +0000 (UTC)
	(envelope-from ambrisko@ambrisko.com)
Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91])
	by mx1.freebsd.org (Postfix) with ESMTP id 4Ll26T30GRz3lP1;
	Fri, 15 Jul 2022 19:51:13 +0000 (UTC)
	(envelope-from ambrisko@ambrisko.com)
IronPort-SDR: uGf1gHeIJw03Qs5wlZGc6SMQGo16Ttmf5VbI44yXjxp9Sr12aX1aqrKYSoRNiyb/p86TQanedy
 z+4nRnh4dTgN7WXmNQPLs4CaEYAAYj0UU=
X-Ambrisko-Me: Yes
IronPort-Data: A9a23:4859X63roG6XXOTRS/bD5cxxkn2cJEfYwER7XKvMYLTBsI5bp2BSn
 zcYCGrTPqveNGvyL9twYYS/9xkPvpCBn4BnHAZq+CA2RRqmiyZl6fd1j6vUF3nPRiH7oc4OA
 /w2MrEsFuhtJpPhjkzF3obJ/CAUOZ6gFuKU5N7sYkiddCc8IMsToUsLd90R3uaEteOE7zal4
 rselSF/1GiNgFaYOkpMg06KRYgGUP7a4Fv0tXRmDRxHUcO3e9D40fsiya+Nw3vQGuG4H8a7Q
 frO1rew+iXQ+h03C8imlfDwdUhirrz6ZFnUzCMIC+77xEIqSi8ais7XMNIVbE1Nii6KmPh4z
 d9XtIezTkEiOaikdOE1DkUAQn4jVUFB0PqdSZSliuSXwlfud3b2yOl0SkYsMuUw9fx6BGtJ3
 fICJT0HdRzFgPi5qJq+Q/dEiN4uIcPwMMUYoH4I5T/DAPssWpyGSLjQ/9JewB8+nM1DF+3SI
 c0DZlJSgL7oC/FUEkwaEowzhr3uj3z1aTxDq1XTrq0yi1U/BTdZiNDFWOc5sPTTLSmMtkrH9
 G/A4UrjBRQWaI6WxTafqCv+j+rFhyLgW4U6Hbiy7P9xg1rVzWsWUUVEWVy+qPi/q0i/R9MPd
 hRNq3Z29fA/pB6xU93wfxyku3rY7BQSbMVdTr8h4waXx6uKvwvAXjoYTiRMYcANvdMtQWB4z
 UeAmt7kXGQ9sLCcRX+H2K2TqDe+ZXocIWMYP3ZWRA4P+dj4o4YbhxfFVNd4E6nzhdrwQGmiz
 zePpSk4prMSkc9biv3irAyf22qh/8GbQBQ06wPbWnOewjl4PIP1NZa17VX77OpbKNrLRFe2o
 3VZydOV6/oDDM/RmXXVEvkNBryg+92MLCbY3Qx0B5Ak+jmgpyyjcIRX7G0sLUtlKJxdKz7vf
 ELJvwpVopZWNmGrdqxwJYm2Dp1yn6TnEN3kUNHSb8ZPMsUpLV7bpHk2aB7CxX3pnWgtjbo7a
 MWSfsubBHoHDbhqkWitTOAH3L53ni0zmTHJSZbgw0j12LaSfiTNG6wIKkWDdLp/5aaOugTO8
 NEZPMyPkk0NXOr7ayjR0IgSMVFacCBiVMyu85RaJryZPw5rOGA9EPuAk7oudrtsk7lRiuqVr
 Gq2XVVVyQaniHDKQelQhquPtF87sU5DkE8G
IronPort-HdrOrdr: A9a23:N7Idj6l63C0Lkt+xFpDyjn9A9LPpDfIq3DAbv31ZSRFFG/FwWf
 rOoB0+726StN93YgBHpTngAtjlfZqyz/JICOUqUotKGTOWwVdAT7sSiLcKoQeQeBEWn9Q1vc
 wMT0E9MqyTMbEQt6bHCWeDferJ8LO8mpyVuQ==
Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2])
  by ironport2.ambrisko.com with ESMTP; 15 Jul 2022 11:42:53 -0700
Received: from ambrisko.com (localhost [127.0.0.1])
	by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 26FJp6Bh074103
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 15 Jul 2022 12:51:06 -0700 (PDT)
	(envelope-from ambrisko@ambrisko.com)
X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com
Received: (from ambrisko@localhost)
	by ambrisko.com (8.17.1/8.17.1/Submit) id 26FJp6qu074102;
	Fri, 15 Jul 2022 12:51:06 -0700 (PDT)
	(envelope-from ambrisko)
Date: Fri, 15 Jul 2022 12:51:06 -0700
From: Doug Ambrisko 
To: Larry Rosenman 
Cc: Michael Gmelin , Alexander Motin ,
        Freebsd current 
Subject: Re: SAS/SATA controllers: 8 port that support 8TB Drives
Message-ID: 
References: 
 <32B35839-84F9-4BDC-B8B5-AF576E21041C@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=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Rspamd-Queue-Id: 4Ll26T30GRz3lP1
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_NO_TLS_LAST(0.10)[];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-current];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[ambrisko];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[ambrisko.com];
	HAS_XAW(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Jun 17, 2022 at 05:55:50PM -0500, Larry Rosenman wrote:
| On 06/17/2022 5:48 pm, Michael Gmelin wrote:
| >> On 18. Jun 2022, at 00:31, Alexander Motin  wrote:
| >> 
| >> 
| >> 
| >>> On 17.06.2022 18:24, Alexander Motin wrote:
| >>>> On 17.06.2022 18:16, Larry Rosenman wrote:
| >>>> On 06/17/2022 5:08 pm, Alexander Motin wrote:
| >>>>> On 17.06.2022 11:59, Larry Rosenman wrote:
| >>>>>> I'm looking to upgrade the controllers in my TrueNAS box to 
| >>>>>> something that will
| >>>>>> support 8TB drives because apparently my LSI 2108 controllers do 
| >>>>>> not support 8TB drives.
| >>>>>> 
| >>>>>> What's the communities recommendation?
| >>>>>> needs to support SFF connectors for a total of 4 SFF connectors, 
| >>>>>> as I have 16 slots.
| >>>>> 
| >>>>> We at iX are still using LSI/Broadcom HBAs, just moved from long
| >>>>> discontinued mps(4) to newer mpr(4).  And I don't believe the 
| >>>>> problem
| >>>>> is directly related to capacity.  According to my observations it 
| >>>>> may
| >>>>> be Seagate HDDs of/above certain (8TB) generation.  We do not use
| >>>>> Seagate HDDs in our products, so about that instability I only 
| >>>>> heard
| >>>>> from forums and TrueNAS community user reports.
| >>>> 
| >>>> This is a mfi(4) set of controllers, and a ST80000Nm0045 8TB (CMR) 
| >>>> drive.
| >>>> 
| >>>> Is this a bad combo?
| >>>> 
| >>>> mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not 
| >>>> supported
| >>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
| >>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
| >>>> (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain
| >>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
| >>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
| >>>> (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain
| >>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
| >>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
| >>>> (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain
| >>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
| >>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
| >>>> (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain
| >>>> (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
| >>>> (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error
| >>>> (probe0:mfi0:0:0:0): Error 5, Retries exhausted
| >>>> 
| >>>> mfi0 Physical Drives:
| >>>>   0 (  932G) UNCONFIGURED GOOD >>> serial=ZA1AC912> SATA E1:S3
| >>> mfi(4) are RAIDs, not HBAs.  We do not recommend RAIDs with TrueNAS 
| >>> due to problems with hot-plug, disk identification, etc. and so have 
| >>> limited experience with them.  But I know some of LSI RAIDs can be 
| >>> reflashed into equivalent HBAs, so if they share the hardware, I can 
| >>> speculate that they may share some issues.
| >> 
| >> I've just noticed "932G" instead of "8000G".  It is obviously a bigger 
| >> problem than what we heard for HBAs.  It looks like a kind of problems 
| >> that should not happen to HBAs, since they should not care about disk 
| >> capacity.
| >> 
| > 
| > What does `smartctl -a ` report (especially sector sizes)?
| > 
| > -m
| > 
| > 
| >> --
| >> Alexander Motin
| >> 
| It's not even making a mfid* node (it is a 4Kn disk)

FYI, mfi never got support for 4Kn drives and is hard coded to 512.  mrsas
does have support so that is better to use for 4Kn and newer controllers.
My day job isn't in that area anymore.  I looked a bit as what it would
take to support 4Kn in mfi and that required a bunch of things and structures
to figure it out.

Doug A.

From nobody Fri Jul 15 22:04:18 2022
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 4Ll54C3ydKz4WlVj
	for ; Fri, 15 Jul 2022 22:04:27 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ll54B3RyZz3yF9
	for ; Fri, 15 Jul 2022 22:04:26 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To:
	From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=9OU9TPDMFbzJKGeCu4f6bJjT4Wf3lT7tuOrITgWItb8=; b=kgRfMkyU3vKr++kGyASDHNyz7f
	JqSmYMXbOHw0L/9lSpQatzDMyPFJVTYxEKgs0UDuTJwvm4MX5bA04mP+92xdJAbsMJ0iJ7I7n4ECj
	qIuTH53fBKHLsdclaSAobm9jljJEE6vIbP4v3Wur873w4rA42jMt0uzU9brwQhrJGIQ6f+anxDRBt
	JXAZK6nOIeWqjDKinjwwjyQf/CCpm3LGxDItcWToDukdHuAYi2ZTx+ChQ/fdaFPKfGzN0IhxrdVQP
	VUxlmVq2pyx6jJtvB+fyYzBrY5Fs3tCul4DqH/V8zbkYeMmYCFw8ST3AjpLqedlNL9t/UsMGeJr6s
	/xvzsDKA==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:17550 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oCTQ2-000NtJ-CZ
	for freebsd-current@freebsd.org;
	Fri, 15 Jul 2022 17:04:18 -0500
Received: from 2600:1700:210:b18f:e02a:1b76:e378:2466
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 15 Jul 2022 17:04: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
Date: Fri, 15 Jul 2022 17:04:18 -0500
From: Larry Rosenman 
To: Freebsd current 
Subject: limits.conf/stacksize doesn't seem to work?
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Ll54B3RyZz3yF9
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=kgRfMkyU;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-2.99 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.988];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current];
	DKIM_TRACE(0.00)[lerctr.org:+];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I'm using the following kernel config:
⯠cat LER-MINIMAL
# LER-MINIMAL  -- kernel config based on MINIMAL

include		MINIMAL
ident		LER-MINIMAL

nooptions 	WITNESS			# Enable checks to detect deadlocks and cycles
nooptions 	WITNESS_SKIPSPIN	# Don't run witness on spinlocks for speed
options		KDB_UNATTENDED
#options		DEBUG_MEMGUARD
#options		DEBUG_REDZONE
makeoptions 	WITH_EXTRA_TCP_STACKS=1
options 	TCPHPTS
device		mfi
options		TCP_RFC7413
# Kernel dump features.
options         EKCD                    # Support for encrypted kernel 
dumps
options         GZIO                    # gzip-compressed kernel and 
user dumps
options         ZSTDIO                  # zstd-compressed kernel and 
user dumps
options         NETDUMP                 # netdump(4) client support
# ipsec support
options		IPSEC_SUPPORT
device		crypto

#netgraph debug
options		NETGRAPH_DEBUG

#tcp ratelimit
options		RATELIMIT

## INVARIANTS
options		INVARIANT_SUPPORT
options		INVARIANTS

ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on 
â˜ï¸  (us-east-1)
â¯

and the following login.conf:
⯠cat /etc/login.conf
# login.conf - login class capabilities database.
#
# Remember to rebuild the database after each change to this file:
#
#	cap_mkdb /etc/login.conf
#
# This file controls resource limits, accounting limits and
# default user environment settings.
#
# $FreeBSD$
#

# Default settings effectively disable resource limits, see the
# examples below for a starting point to enable them.

# defaults
# These settings are used by login(1) by default for classless users
# Note that entries like "cputime" set both "cputime-cur" and 
"cputime-max"
#
# Note that since a colon ':' is used to separate capability entries,
# a \c escape sequence must be used to embed a literal colon in the
# value or name of a capability (see the ``CGETNUM AND CGETSTR SYNTAX
# AND SEMANTICS'' section of getcap(3) for more escape sequences).

default:\
	:passwd_format=sha512:\
	:copyright=/etc/COPYRIGHT:\
	:welcome=/var/run/motd:\
	:setenv=BLOCKSIZE=K:\
	:mail=/var/mail/$:\
	:path=/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin 
~/bin:\
	:nologin=/var/run/nologin:\
	:cputime=unlimited:\
	:datasize=unlimited:\
	:stacksize=unlimited:\
	:memorylocked=64K:\
	:memoryuse=unlimited:\
	:filesize=unlimited:\
	:coredumpsize=unlimited:\
	:openfiles=unlimited:\
	:maxproc=unlimited:\
	:sbsize=unlimited:\
	:vmemoryuse=unlimited:\
	:swapuse=unlimited:\
	:pseudoterminals=unlimited:\
	:kqueues=unlimited:\
	:umtxp=unlimited:\
	:priority=0:\
	:ignoretime@:\
	:umask=022:\
	:charset=UTF-8:\
	:lang=C.UTF-8:

#
# A collection of common class names - forward them all to 'default'
# (login would normally do this anyway, but having a class name
#  here suppresses the diagnostic)
#
standard:\
	:tc=default:
xuser:\
	:tc=default:
staff:\
	:tc=default:

# This PATH may be clobbered by individual applications.  Notably, by 
default,
# rc(8), service(8), and cron(8) will all override it with a default 
PATH that
# may not include /usr/local/sbin and /usr/local/bin when starting 
services or
# jobs.
daemon:\
	:path=/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin:\
	:mail@:\
	:memorylocked=128M:\
	:tc=default:
news:\
	:tc=default:
dialer:\
	:tc=default:

#
# Root can always login
#
# N.B.  login_getpwclass(3) will use this entry for the root account,
#       in preference to 'default'.
root:\
	:ignorenologin:\
	:memorylocked=unlimited:\
	:tc=default:

#
# Russian Users Accounts. Setup proper environment variables.
#
russian|Russian Users Accounts:\
	:charset=UTF-8:\
	:lang=ru_RU.UTF-8:\
	:tc=default:

bacula_dir:\
	:stacksize-max=68719476736:\
	:stacksize-cur=68719476736:\
	:tc=daemon:
######################################################################
######################################################################
##
## Example entries
##
######################################################################
######################################################################

## Example defaults
## These settings are used by login(1) by default for classless users
## Note that entries like "cputime" set both "cputime-cur" and 
"cputime-max"
#
#default:\
#	:cputime=infinity:\
#	:datasize-cur=22M:\
#	:stacksize-cur=8M:\
#	:memorylocked-cur=10M:\
#	:memoryuse-cur=30M:\
#	:filesize=infinity:\
#	:coredumpsize=infinity:\
#	:maxproc-cur=64:\
#	:openfiles-cur=64:\
#	:priority=0:\
#	:requirehome@:\
#	:umask=022:\
#	:tc=auth-defaults:
#
#
##
## standard - standard user defaults
##
#standard:\
#	:copyright=/etc/COPYRIGHT:\
#	:welcome=/var/run/motd:\
#	:setenv=BLOCKSIZE=K:\
#	:mail=/var/mail/$:\
#	:path=~/bin /bin /usr/bin /usr/local/bin:\
#	:manpath=/usr/share/man /usr/local/man:\
#	:nologin=/var/run/nologin:\
#	:cputime=1h30m:\
#	:datasize=8M:\
#	:vmemoryuse=100M:\
#	:stacksize=2M:\
#	:memorylocked=4M:\
#	:memoryuse=8M:\
#	:filesize=8M:\
#	:coredumpsize=8M:\
#	:openfiles=24:\
#	:maxproc=32:\
#	:priority=0:\
#	:requirehome:\
#	:passwordtime=90d:\
#	:umask=002:\
#	:ignoretime@:\
#	:tc=default:
#
#
##
## users of X (needs more resources!)
##
#xuser:\
#	:manpath=/usr/share/man /usr/local/man:\
#	:cputime=4h:\
#	:datasize=12M:\
#	:vmemoryuse=infinity:\
#	:stacksize=4M:\
#	:filesize=8M:\
#	:memoryuse=16M:\
#	:openfiles=32:\
#	:maxproc=48:\
#	:tc=standard:
#
#
##
## Staff users - few restrictions and allow login anytime
##
#staff:\
#	:ignorenologin:\
#	:ignoretime:\
#	:requirehome@:\
#	:accounted@:\
#	:path=~/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin 
/usr/local/sbin:\
#	:umask=022:\
#	:tc=standard:
#
#
##
## root - fallback for root logins
##
#root:\
#	:path=~/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin 
/usr/local/sbin:\
#	:cputime=infinity:\
#	:datasize=infinity:\
#	:stacksize=infinity:\
#	:memorylocked=infinity:\
#	:memoryuse=infinity:\
#	:filesize=infinity:\
#	:coredumpsize=infinity:\
#	:openfiles=infinity:\
#	:maxproc=infinity:\
#	:memoryuse-cur=32M:\
#	:maxproc-cur=64:\
#	:openfiles-cur=1024:\
#	:priority=0:\
#	:requirehome@:\
#	:umask=022:\
#	:tc=auth-root-defaults:
#
#
##
## Settings used by /etc/rc
##
#daemon:\
#	:coredumpsize@:\
#	:coredumpsize-cur=0:\
#	:datasize=infinity:\
#	:datasize-cur@:\
#	:maxproc=512:\
#	:maxproc-cur@:\
#	:memoryuse-cur=64M:\
#	:memorylocked-cur=64M:\
#	:openfiles=1024:\
#	:openfiles-cur@:\
#	:stacksize=16M:\
#	:stacksize-cur@:\
#	:tc=default:
#
#
##
## Settings used by news subsystem
##
#news:\
#	:path=/usr/local/news/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin 
/usr/local/sbin:\
#	:cputime=infinity:\
#	:filesize=128M:\
#	:datasize-cur=64M:\
#	:stacksize-cur=32M:\
#	:coredumpsize-cur=0:\
#	:maxmemorysize-cur=128M:\
#	:memorylocked=32M:\
#	:maxproc=128:\
#	:openfiles=256:\
#	:tc=default:
#
#
##
## The dialer class should be used for a dialup PPP account
## Welcome messages/news suppressed
##
#dialer:\
#	:hushlogin:\
#	:requirehome@:\
#	:cputime=unlimited:\
#	:filesize=2M:\
#	:datasize=2M:\
#	:stacksize=4M:\
#	:coredumpsize=0:\
#	:memoryuse=4M:\
#	:memorylocked=1M:\
#	:maxproc=16:\
#	:openfiles=32:\
#	:tc=standard:
#
#
##
## Site full-time 24/7 PPP connection
## - no time accounting, restricted to access via dialin lines
##
#site:\
#	:ignoretime:\
#	:passwordtime@:\
#	:refreshtime@:\
#	:refreshperiod@:\
#	:sessionlimit@:\
#	:autodelete@:\
#	:expireperiod@:\
#	:graceexpire@:\
#	:gracetime@:\
#	:warnexpire@:\
#	:warnpassword@:\
#	:idletime@:\
#	:sessiontime@:\
#	:daytime@:\
#	:weektime@:\
#	:monthtime@:\
#	:warntime@:\
#	:accounted@:\
#	:tc=dialer:\
#	:tc=staff:
#
#
##
## Example standard accounting entries for subscriber levels
##
#
#subscriber|Subscribers:\
#	:accounted:\
#	:refreshtime=180d:\
#	:refreshperiod@:\
#	:sessionlimit@:\
#	:autodelete=30d:\
#	:expireperiod=180d:\
#	:graceexpire=7d:\
#	:gracetime=10m:\
#	:warnexpire=7d:\
#	:warnpassword=7d:\
#	:idletime=30m:\
#	:sessiontime=4h:\
#	:daytime=6h:\
#	:weektime=40h:\
#	:monthtime=120h:\
#	:warntime=4h:\
#	:tc=standard:
#
#
##
## Subscriber accounts. These accounts have their login times
## accounted and have access limits applied.
##
#subppp|PPP Subscriber Accounts:\
#	:tc=dialer:\
#	:tc=subscriber:
#
#
#subshell|Shell Subscriber Accounts:\
#	:tc=subscriber:
#
##
## If you want some of the accounts to use traditional UNIX DES based
## password hashes.
##
#des_users:\
#	:passwd_format=des:\
#	:tc=default:

ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on 
â˜ï¸  (us-east-1)
â¯

I've updated my (ler) password entry to reference bacula_dir:
ler::1001:1001:bacula_dir:0:0:Larry 
Rosenman:/home/ler:/usr/local/bin/zsh


when I ssh in, the stacklimit is still:
⯠ulimit -H -s
2097152

ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on 
â˜ï¸  (us-east-1)
⯠ulimit -S -s
2097152

ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on 
â˜ï¸  (us-east-1)
â¯

Where does this number come from?  What am I missing here?


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Fri Jul 15 22:18:24 2022
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 4Ll5NQ2F6Nz4Wmr2
	for ; Fri, 15 Jul 2022 22:18:30 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ll5NP2MDRz43Tx
	for ; Fri, 15 Jul 2022 22:18:29 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-qv1-xf32.google.com with SMTP id m10so766106qvu.4
        for ; Fri, 15 Jul 2022 15:18:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:content-transfer-encoding:in-reply-to;
        bh=cnrAawEN6DeN9E4qRqJHrqFefUUesx6sDedvsRrcWZg=;
        b=klHLrApNDFflkkZDv/tUpOt2j028PS2miMuPQov2Y87Z94r6uvYbPHjgTxJ9EUocDE
         PXXEnWX0jlfX4HGKmeYkZCEt05REyU946MD4FF6UJAXXa1iTdddQisZBpQtl20J/Mn0z
         6FNEo9uEttGgr6eLF3Ldq2WffiEJ9cg99Qt5iYmroL6L+uNpGpV0XlZ3r7smkGCuX2cl
         xne/vPcm8uKr7Tu9puQslvyx6MfJnGB0TMSsW0DLwa3eYZqejITYFgDfryqHnoCsvHYc
         xSLbUciS8S78EedKnlZoc8BKwwqnMseWh9k9CxF3Bfg+GftgNQtXDYYp+8tjPtlLDTdl
         PXyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition
         :content-transfer-encoding:in-reply-to;
        bh=cnrAawEN6DeN9E4qRqJHrqFefUUesx6sDedvsRrcWZg=;
        b=Ru3yqEHA2mUgt+5tmNupE0c3YgMX7Ki0aPPsXqUETq9QuI7aCXR7iuY+aWZi/eNWtb
         TM6S1pMKG3ml9P6b4MTF/2Fn3YANnPCx/0EdbAHHIcRdMz5VP4I7KPwU4ksn4a5wHKbi
         pKFO3mJMNofmgMgEcbskl5NSLB18FgbqjjBoSik7vRbVQRGpQQgrG1Ii1nQx5LFAb1Cl
         Iw5Co4brKMNRi7tGRusX8mvJukS6RbuwUrdoxvOqLOpo7rjDC8HKkYTRZaBO4u00QsW4
         +a5LlJM+Ben0dFIbEGp8X3cuqmJbcbZ2Ls5BOR09ukEk05FWFfqRPjKvrhVWhkGCIjGn
         l/KA==
X-Gm-Message-State: AJIora/pwayC4eTG8boS7FxTJ8QJfDWhrrle+VcNllBAF51YtJQiIzMw
	+2hIV4d2FFCdO3umEkvDLnR67biExc0=
X-Google-Smtp-Source: AGRyM1t1AZVW47ihQTDcwJawsb/THBL7qp7eiVDeiAs8dIu5Os1hkp4kwTh/GF1hK9NIA6J0vYyuGA==
X-Received: by 2002:a05:6214:29ef:b0:473:7504:52cd with SMTP id jv15-20020a05621429ef00b00473750452cdmr13766203qvb.82.1657923507886;
        Fri, 15 Jul 2022 15:18:27 -0700 (PDT)
Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237])
        by smtp.gmail.com with ESMTPSA id q9-20020ac84509000000b0031eb3af3ffesm4383566qtn.52.2022.07.15.15.18.26
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 15 Jul 2022 15:18:27 -0700 (PDT)
Date: Fri, 15 Jul 2022 18:18:24 -0400
From: Mark Johnston 
To: Larry Rosenman 
Cc: Freebsd current 
Subject: Re: limits.conf/stacksize doesn't seem to work?
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=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Rspamd-Queue-Id: 4Ll5NP2MDRz43Tx
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=klHLrApN;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f32 as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-1.69 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.990];
	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:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f32:from];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	MLMMJ_DEST(0.00)[freebsd-current];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote:
> I'm using the following kernel config:
> [...]
> and the following login.conf:
> [...]
> bacula_dir:\
> 	:stacksize-max=68719476736:\
> 	:stacksize-cur=68719476736:\
> 	:tc=daemon:
> [...]
> I've updated my (ler) password entry to reference bacula_dir:
> ler::1001:1001:bacula_dir:0:0:Larry 
> Rosenman:/home/ler:/usr/local/bin/zsh
> 
> 
> when I ssh in, the stacklimit is still:
> ⯠ulimit -H -s
> 2097152

What is the value of the kern.maxssiz sysctl on this system?

> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on 
> â˜ï¸  (us-east-1)
> ⯠ulimit -S -s
> 2097152
> 
> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on 
> â˜ï¸  (us-east-1)
> â¯
> 
> Where does this number come from?  What am I missing here?

The stack limit cannot be set to an arbitrarily large number.  It will
silently be clamped to maxssiz.

From nobody Fri Jul 15 22:21:27 2022
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 4Ll5Rs1Krnz4WnXX
	for ; Fri, 15 Jul 2022 22:21:29 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ll5Rr1L8Hz44Wr;
	Fri, 15 Jul 2022 22:21:28 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=VUF+BzF3XwSyZadmmrjrWm4I66DcFwP1R2cIoxcOf9s=; b=PXEW39jVeRWrnDYllz+XAeb3S5
	8GJOYUhQ31+bCrUdAzo5Vwcq+gwbYJXtBA0HwzTQBuOScyobQFguYBEsG+aYqJNjeAQEk8kp7r1Ew
	QzNouiMME6qNKcAUHWCNnkDndLWCs1B9s0BOdltaLI0NW8rN8dlf2rbFc6M6m8+HrLdlNZ/kDsv2K
	LiKH3M3O4Ls3SRfN2P929/5U7CvUrQ89VQ8ODsswDG5iOQfR3iyGy4FHOscXIbvkJdpswCBZSdoVd
	Y7ADtChiPELUf3hvb+Tg8a3ZxTGVAwQU96eKD6Eis5rFKJ2VqpEtOjwqosgkf+sUJEuqTH/dNI6H9
	dq7xh6TQ==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:38979 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oCTgd-000OAz-Hw;
	Fri, 15 Jul 2022 17:21:27 -0500
Received: from 2600:1700:210:b18f:e02a:1b76:e378:2466
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 15 Jul 2022 17:21:27 -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
Date: Fri, 15 Jul 2022 17:21:27 -0500
From: Larry Rosenman 
To: Mark Johnston 
Cc: Freebsd current 
Subject: Re: limits.conf/stacksize doesn't seem to work?
In-Reply-To: 
References: 
 
Message-ID: <32dc6f5b56a749f9b8e26330f9f2e8e0@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Ll5Rr1L8Hz44Wr
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=PXEW39jV;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.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)[lerctr.org,none];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	R_SPF_ALLOW(-0.20)[+mx:c];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 07/15/2022 5:18 pm, Mark Johnston wrote:
> On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote:
>> I'm using the following kernel config:
>> [...]
>> and the following login.conf:
>> [...]
>> bacula_dir:\
>> 	:stacksize-max=68719476736:\
>> 	:stacksize-cur=68719476736:\
>> 	:tc=daemon:
>> [...]
>> I've updated my (ler) password entry to reference bacula_dir:
>> ler::1001:1001:bacula_dir:0:0:Larry
>> Rosenman:/home/ler:/usr/local/bin/zsh
>> 
>> 
>> when I ssh in, the stacklimit is still:
>> ⯠ulimit -H -s
>> 2097152
> 
> What is the value of the kern.maxssiz sysctl on this system?
> 
>> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on
>> â˜ï¸  (us-east-1)
>> ⯠ulimit -S -s
>> 2097152
>> 
>> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on
>> â˜ï¸  (us-east-1)
>> â¯
>> 
>> Where does this number come from?  What am I missing here?
> 
> The stack limit cannot be set to an arbitrarily large number.  It will
> silently be clamped to maxssiz.

⯠sysctl kern.maxssiz
kern.maxssiz: 2147483648


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Fri Jul 15 22:24:36 2022
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 4Ll5WY2MgZz4WnWZ
	for ; Fri, 15 Jul 2022 22:24:41 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ll5WW5RWPz45wj
	for ; Fri, 15 Jul 2022 22:24:39 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-qk1-x730.google.com with SMTP id c17so4677064qkl.4
        for ; Fri, 15 Jul 2022 15:24:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:content-transfer-encoding:in-reply-to;
        bh=fpRHTFSJGaHvAh3GXsaWTmLiWn4pfbEkLB/2AlvXGEk=;
        b=d37E+pYPQZVMlOV74593f+V/8YS4cOdSl2IYqKDy3Eih/T6tkK88XdJNV9wfXaiwOK
         eWHvjGPJ3AkTRa9Iwsch3ZrbcW+IHh2iQYc4roZg56ODdhbYMYlGK/KK02rxbigVnHjg
         LM/rdOP0MRo8idQkE++btpRnmtQ8omxEmuoJili4jse7/fS8xAkL8RGP0Lm0UyARhowC
         HShUMwYwFUhbWFV2ZNynOp0HI9dMcQVKnUTIxcbYPTCkimSSL9q5bnE/Q5JCaCq76Nya
         oap7aQRvgjOTOS1iXGdC1rg7teMa+2zVdnBqGrqoLtY50Y4T3+EFA9wVLxcF9FvVreOD
         gvsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition
         :content-transfer-encoding:in-reply-to;
        bh=fpRHTFSJGaHvAh3GXsaWTmLiWn4pfbEkLB/2AlvXGEk=;
        b=LPHuBrL5ia3BQgqSer9YIxS+Vh/MebcmwYCxEGoAL5FO9s32fGKlZr/RiAslkmCmII
         vXP7ebSTPVXISMNmQrFtNbPuF0buWbg+nMYkKmOYncgStBTY5gnzwNeaofB4ZjC2xB+T
         ADBqDuyETbcRxHpo39CsUbe7NOVj9K1l8Oh7/n1WPpaeRbQC1I3zcuLB1cbkmEMC2uN9
         vK0L0LnEhN6l97YP1wzy6MXVkcPzn4Loesatk7sJ2DABrYsputvr9oiU8RIXHBv1j78d
         dxUBmEKTKUB2ErgA9UHcxRpK0Liz7GvJpcw15qx6enGYSpQksYYlMXuf6lNso6wl3tse
         EhFg==
X-Gm-Message-State: AJIora+dMLD06CAGGjzVcJnW7KQBq2UdIIzeIJdObYkqLcM+yF2Yhnzg
	i8fPi73a6tlxTapeySRA/QsSBlWpWUs=
X-Google-Smtp-Source: AGRyM1u4H1eexk3xlXRzkku+Bd4NSY1bkxWpx19FvwBgm2v+1V5FeepFNUcDdu+6Q7RP68MqBB8skw==
X-Received: by 2002:a05:620a:4706:b0:6af:482e:b9eb with SMTP id bs6-20020a05620a470600b006af482eb9ebmr11149806qkb.46.1657923878982;
        Fri, 15 Jul 2022 15:24:38 -0700 (PDT)
Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237])
        by smtp.gmail.com with ESMTPSA id r10-20020ac85e8a000000b0031eb51dd72csm4156426qtx.85.2022.07.15.15.24.38
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 15 Jul 2022 15:24:38 -0700 (PDT)
Date: Fri, 15 Jul 2022 18:24:36 -0400
From: Mark Johnston 
To: Larry Rosenman 
Cc: Freebsd current 
Subject: Re: limits.conf/stacksize doesn't seem to work?
Message-ID: 
References: 
 
 <32dc6f5b56a749f9b8e26330f9f2e8e0@lerctr.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=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <32dc6f5b56a749f9b8e26330f9f2e8e0@lerctr.org>
X-Rspamd-Queue-Id: 4Ll5WW5RWPz45wj
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=d37E+pYP;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::730 as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-1.65 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.95)[-0.947];
	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:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::730:from];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	MLMMJ_DEST(0.00)[freebsd-current];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Jul 15, 2022 at 05:21:27PM -0500, Larry Rosenman wrote:
> On 07/15/2022 5:18 pm, Mark Johnston wrote:
> > On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote:
> >> I'm using the following kernel config:
> >> [...]
> >> and the following login.conf:
> >> [...]
> >> bacula_dir:\
> >> 	:stacksize-max=68719476736:\
> >> 	:stacksize-cur=68719476736:\
> >> 	:tc=daemon:
> >> [...]
> >> I've updated my (ler) password entry to reference bacula_dir:
> >> ler::1001:1001:bacula_dir:0:0:Larry
> >> Rosenman:/home/ler:/usr/local/bin/zsh
> >> 
> >> 
> >> when I ssh in, the stacklimit is still:
> >> ⯠ulimit -H -s
> >> 2097152
> > 
> > What is the value of the kern.maxssiz sysctl on this system?
> > 
> >> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on
> >> â˜ï¸  (us-east-1)
> >> ⯠ulimit -S -s
> >> 2097152
> >> 
> >> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on
> >> â˜ï¸  (us-east-1)
> >> â¯
> >> 
> >> Where does this number come from?  What am I missing here?
> > 
> > The stack limit cannot be set to an arbitrarily large number.  It will
> > silently be clamped to maxssiz.
> 
> ⯠sysctl kern.maxssiz
> kern.maxssiz: 2147483648

Then what you're seeing is expected.  The kernel is clamping the stack
segment limit to 2GB.

From nobody Fri Jul 15 22:26:09 2022
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 4Ll5YH5GnPz4Wp8N
	for ; Fri, 15 Jul 2022 22:26:11 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ll5YG5gHWz46rH;
	Fri, 15 Jul 2022 22:26:10 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=LqCA7QgbBkuJmaKqsVzi7AA2FXZJGrSE1JVPrXjRgMM=; b=qVXBIAOQJLVZANHDL8PWqaLsdK
	lQ6AkfrKxFCkFK14NJ1+bg6PTuj4G50Ksn4NbI67xuYvf7w7WvqyKp2kamFcXhed9oS6MzPWwcjqf
	PNv1ZH7zNpQKJ5SR5FD1L5Yg+kSSHcA6IKKbfwN9yIzawU6uSNDd6k4D8fWOHvwlrUX1rwTkWfe85
	NUtZ1kDCzPgilevmA+ekVBicuZWzhk576K34o70gpvUJVgYeV/osruAqd9S/Cg9OFJQrWx2zqFp67
	h/5xdMBKkCVMCbWzTx0Dvb61SxWTsu35HekaykSpGaQY3bBgMstYvqnrvnB/Dve+/2V90gRB0PP1c
	mSSaeydQ==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:57208 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oCTlC-000OIs-3q;
	Fri, 15 Jul 2022 17:26:10 -0500
Received: from 2600:1700:210:b18f:e02a:1b76:e378:2466
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 15 Jul 2022 17:26:09 -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
Date: Fri, 15 Jul 2022 17:26:09 -0500
From: Larry Rosenman 
To: Mark Johnston 
Cc: Freebsd current 
Subject: Re: limits.conf/stacksize doesn't seem to work?
In-Reply-To: 
References: 
  <32dc6f5b56a749f9b8e26330f9f2e8e0@lerctr.org>
 
Message-ID: <51ef4fe0c8c5bbe251d3e75084847a6e@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Ll5YG5gHWz46rH
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=qVXBIAOQ;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	R_SPF_ALLOW(-0.20)[+mx:c];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 07/15/2022 5:24 pm, Mark Johnston wrote:
> On Fri, Jul 15, 2022 at 05:21:27PM -0500, Larry Rosenman wrote:
>> On 07/15/2022 5:18 pm, Mark Johnston wrote:
>> > On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote:
>> >> I'm using the following kernel config:
>> >> [...]
>> >> and the following login.conf:
>> >> [...]
>> >> bacula_dir:\
>> >> 	:stacksize-max=68719476736:\
>> >> 	:stacksize-cur=68719476736:\
>> >> 	:tc=daemon:
>> >> [...]
>> >> I've updated my (ler) password entry to reference bacula_dir:
>> >> ler::1001:1001:bacula_dir:0:0:Larry
>> >> Rosenman:/home/ler:/usr/local/bin/zsh
>> >>
>> >>
>> >> when I ssh in, the stacklimit is still:
>> >> ⯠ulimit -H -s
>> >> 2097152
>> >
>> > What is the value of the kern.maxssiz sysctl on this system?
>> >
>> >> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on
>> >> â˜ï¸  (us-east-1)
>> >> ⯠ulimit -S -s
>> >> 2097152
>> >>
>> >> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on
>> >> â˜ï¸  (us-east-1)
>> >> â¯
>> >>
>> >> Where does this number come from?  What am I missing here?
>> >
>> > The stack limit cannot be set to an arbitrarily large number.  It will
>> > silently be clamped to maxssiz.
>> 
>> ⯠sysctl kern.maxssiz
>> kern.maxssiz: 2147483648
> 
> Then what you're seeing is expected.  The kernel is clamping the stack
> segment limit to 2GB.

I assume this is the default for MAXSSIZ?  and if I change that in the 
kernel config, it will
allow bigger?  Where is this default defined?

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Fri Jul 15 22:32:21 2022
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 4Ll5hT6WKRz4WpMV
	for ; Fri, 15 Jul 2022 22:32:25 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ll5hT2RXlz49fj
	for ; Fri, 15 Jul 2022 22:32:25 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-qv1-xf35.google.com with SMTP id g9so4692965qvq.7
        for ; Fri, 15 Jul 2022 15:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:content-transfer-encoding:in-reply-to;
        bh=O0xH74SrkYc7Wd08R1hd1WUHfdCbmQF5t3szbIlXlxU=;
        b=FLwXs0PR9QsbGUBXsl7DwUQZGHnNUMg4zqqebpnNL4K3dHupXgxWiwFhkUzYatzXIP
         akGVZvC52ukWZFG8WCE+6O8F8V3WlemyjF77YmWpaRAuczXkRmclS2dESGZeHQQL6Zow
         HplnTFRsWbRexmlQUPtv0uMNF1Aex/OT3YQZ4fEJ9/boITcj6GCeXT/r/PLurIo7DjdK
         c8I8humANPRtJR/9+TeioJPm6O10a+c3olFgvHuY+P8qtLV6Xtuvl473BS+ahzaBVRvE
         KGa1c061fUoMidDvIutgJiBb8hS62kCByp4sqWEN9MWiV8i0IBGt+uG4htGQtFc0cRtg
         gQdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition
         :content-transfer-encoding:in-reply-to;
        bh=O0xH74SrkYc7Wd08R1hd1WUHfdCbmQF5t3szbIlXlxU=;
        b=HjfXeGlt+AzEwRJxUvQxwQ1d/CDtaKYInxV/91tgQrZ+lWd4GWXJOlGP6JNTJ1+zJ7
         7p1A5t4N0U1q9CZ/iwPzwuCodoWkkEtDXdsxWdug7QvolTbf5covjV06JQyeF5X1KkoQ
         xA6FnnYjBf6Q3Vu6AznfswJ8jBBzWoE2yViomR5q1UjsX/aGBw1hkJ9GBEza7ZJuJPCG
         ZPYPSlpMNkmUO77fmczY18s6x1kJyxe9skUAHPBBSSQZPnKTmhuzpoSwoc16S4usMSkU
         g+/JXFCPgEvvFFTpvx1v70c9n3SuRhNg/XWMi9JKjBA7zNTlxlqrTnEa7QeZOGmXEXyy
         fLlg==
X-Gm-Message-State: AJIora9aK/QF56f5howNIhB2XQ+tKoaa8XOvvWiMjDzORz+mG5r5wU74
	cIu3WPdDon+E3+EXYMpRmpO3RBxc1bE=
X-Google-Smtp-Source: AGRyM1tDii4BHPf5wwDpWM2D0Qx4gVg7+k+iBTktUpkvVuL1/SDf8MfWmfN+GjRcTzRbe8s7vamPIg==
X-Received: by 2002:a05:6214:2268:b0:473:1196:c599 with SMTP id gs8-20020a056214226800b004731196c599mr13579795qvb.14.1657924344731;
        Fri, 15 Jul 2022 15:32:24 -0700 (PDT)
Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237])
        by smtp.gmail.com with ESMTPSA id w3-20020a05620a444300b006b58aa4e0e0sm3584149qkp.24.2022.07.15.15.32.23
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 15 Jul 2022 15:32:24 -0700 (PDT)
Date: Fri, 15 Jul 2022 18:32:21 -0400
From: Mark Johnston 
To: Larry Rosenman 
Cc: Freebsd current 
Subject: Re: limits.conf/stacksize doesn't seem to work?
Message-ID: 
References: 
 
 <32dc6f5b56a749f9b8e26330f9f2e8e0@lerctr.org>
 
 <51ef4fe0c8c5bbe251d3e75084847a6e@lerctr.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=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <51ef4fe0c8c5bbe251d3e75084847a6e@lerctr.org>
X-Rspamd-Queue-Id: 4Ll5hT2RXlz49fj
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=FLwXs0PR;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f35 as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-1.70 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	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:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f35:from];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	MLMMJ_DEST(0.00)[freebsd-current];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Jul 15, 2022 at 05:26:09PM -0500, Larry Rosenman wrote:
> On 07/15/2022 5:24 pm, Mark Johnston wrote:
> > On Fri, Jul 15, 2022 at 05:21:27PM -0500, Larry Rosenman wrote:
> >> On 07/15/2022 5:18 pm, Mark Johnston wrote:
> >> > On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote:
> >> >> I'm using the following kernel config:
> >> >> [...]
> >> >> and the following login.conf:
> >> >> [...]
> >> >> bacula_dir:\
> >> >> 	:stacksize-max=68719476736:\
> >> >> 	:stacksize-cur=68719476736:\
> >> >> 	:tc=daemon:
> >> >> [...]
> >> >> I've updated my (ler) password entry to reference bacula_dir:
> >> >> ler::1001:1001:bacula_dir:0:0:Larry
> >> >> Rosenman:/home/ler:/usr/local/bin/zsh
> >> >>
> >> >>
> >> >> when I ssh in, the stacklimit is still:
> >> >> ⯠ulimit -H -s
> >> >> 2097152
> >> >
> >> > What is the value of the kern.maxssiz sysctl on this system?
> >> >
> >> >> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on
> >> >> â˜ï¸  (us-east-1)
> >> >> ⯠ulimit -S -s
> >> >> 2097152
> >> >>
> >> >> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on
> >> >> â˜ï¸  (us-east-1)
> >> >> â¯
> >> >>
> >> >> Where does this number come from?  What am I missing here?
> >> >
> >> > The stack limit cannot be set to an arbitrarily large number.  It will
> >> > silently be clamped to maxssiz.
> >> 
> >> ⯠sysctl kern.maxssiz
> >> kern.maxssiz: 2147483648
> > 
> > Then what you're seeing is expected.  The kernel is clamping the stack
> > segment limit to 2GB.
> 
> I assume this is the default for MAXSSIZ?  and if I change that in the 
> kernel config, it will
> allow bigger?  Where is this default defined?

The default value is platform dependent.  On amd64 it's 512MB, so I'm
not sure where your value is coming from.  It's defined in a header.
You can set it in the kernel configuration, or as a tunable or sysctl.

From nobody Fri Jul 15 22:34:38 2022
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 4Ll5l403Qpz4Wpl1
	for ; Fri, 15 Jul 2022 22:34:39 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ll5l31n62z3CPP;
	Fri, 15 Jul 2022 22:34:39 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=uRflfbrairXzJNcqLBGY3mvKuEoKNz1pRM7+PYdbHPg=; b=lceAdncLBqcRQ9FTS5Ojdlphag
	uEn4YN3puiodX8gRhemrz8e8XqdhDgsmNFpF08y17U1TpwCov1gTnQhVQvkQdhSiMOy3ukhUydXwF
	kOGUJ+EGykR0iDSMaqOSDJfAuclzZZ+nzLQWKPHRNgkJo5n4fviMtjsp1VlKSr1IDOZMVSHYEsL00
	+FAuyT9eRSpYCjf8X03kWM1bk9bNORSROu/hA47e4/KBGOJAp/ZThFHrNc6IMixakzw8gZwEuQHl/
	NH4w+iltVrKLhvCQsKm9C4M3qH+o53Xmi2LptFRrdXlgV5jtp5Jhxn0NwksE1ZRw9Nu5LaUBDLHCO
	Xf3ytHaw==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:15778 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oCTtO-000OSs-FV;
	Fri, 15 Jul 2022 17:34:38 -0500
Received: from 2600:1700:210:b18f:e02a:1b76:e378:2466
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 15 Jul 2022 17:34:38 -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
Date: Fri, 15 Jul 2022 17:34:38 -0500
From: Larry Rosenman 
To: Mark Johnston 
Cc: Freebsd current 
Subject: Re: limits.conf/stacksize doesn't seem to work?
In-Reply-To: 
References: 
  <32dc6f5b56a749f9b8e26330f9f2e8e0@lerctr.org>
  <51ef4fe0c8c5bbe251d3e75084847a6e@lerctr.org>
 
Message-ID: <6ed4c3a6d3e0e9e569549618409c83fa@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Ll5l31n62z3CPP
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=lceAdncL;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 07/15/2022 5:32 pm, Mark Johnston wrote:
> On Fri, Jul 15, 2022 at 05:26:09PM -0500, Larry Rosenman wrote:
>> On 07/15/2022 5:24 pm, Mark Johnston wrote:
>> > On Fri, Jul 15, 2022 at 05:21:27PM -0500, Larry Rosenman wrote:
>> >> On 07/15/2022 5:18 pm, Mark Johnston wrote:
>> >> > On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote:
>> >> >> I'm using the following kernel config:
>> >> >> [...]
>> >> >> and the following login.conf:
>> >> >> [...]
>> >> >> bacula_dir:\
>> >> >> 	:stacksize-max=68719476736:\
>> >> >> 	:stacksize-cur=68719476736:\
>> >> >> 	:tc=daemon:
>> >> >> [...]
>> >> >> I've updated my (ler) password entry to reference bacula_dir:
>> >> >> ler::1001:1001:bacula_dir:0:0:Larry
>> >> >> Rosenman:/home/ler:/usr/local/bin/zsh
>> >> >>
>> >> >>
>> >> >> when I ssh in, the stacklimit is still:
>> >> >> ⯠ulimit -H -s
>> >> >> 2097152
>> >> >
>> >> > What is the value of the kern.maxssiz sysctl on this system?
>> >> >
>> >> >> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on
>> >> >> â˜ï¸  (us-east-1)
>> >> >> ⯠ulimit -S -s
>> >> >> 2097152
>> >> >>
>> >> >> ler in 🌠borg in sys/amd64/conf🔒 on  ler/freebsd-main-changes:main on
>> >> >> â˜ï¸  (us-east-1)
>> >> >> â¯
>> >> >>
>> >> >> Where does this number come from?  What am I missing here?
>> >> >
>> >> > The stack limit cannot be set to an arbitrarily large number.  It will
>> >> > silently be clamped to maxssiz.
>> >>
>> >> ⯠sysctl kern.maxssiz
>> >> kern.maxssiz: 2147483648
>> >
>> > Then what you're seeing is expected.  The kernel is clamping the stack
>> > segment limit to 2GB.
>> 
>> I assume this is the default for MAXSSIZ?  and if I change that in the
>> kernel config, it will
>> allow bigger?  Where is this default defined?
> 
> The default value is platform dependent.  On amd64 it's 512MB, so I'm
> not sure where your value is coming from.  It's defined in a header.
> You can set it in the kernel configuration, or as a tunable or sysctl.

ok, so I had (back when, heaven only knows) set it in /boot/loader.conf:
kern.maxssiz="2147483648"

thank you.

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Sat Jul 16 00:18:06 2022
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 4Ll8383zydz4X20l
	for ; Sat, 16 Jul 2022 00:18:44 +0000 (UTC)
	(envelope-from m.e.sanliturk@gmail.com)
Received: from mail-oa1-x2d.google.com (mail-oa1-x2d.google.com [IPv6:2001:4860:4864:20::2d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ll8376hCPz3Mww;
	Sat, 16 Jul 2022 00:18:43 +0000 (UTC)
	(envelope-from m.e.sanliturk@gmail.com)
Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-10c8e8d973eso9732726fac.5;
        Fri, 15 Jul 2022 17:18:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=U4JFrkrVHvp8aYamENGgl5bqVUJUysiGglA8u7rz5uQ=;
        b=F2UQakeHZw487LTs1uqEr6MvJVIBj2aH4D6whweqEYYFN1hEoU+DjK2V9T1lRraIWz
         nsTMYruY+cJTa8x0AVCPRb6rEUcaCPDn7AEIR9ddpUv2okkL3kiofaFLGcAfWWHFGr8n
         eKp1VdeqQuQmPa2RCURoO8F9jwZNNT2pZcdYTPPr/RpqcFyx/DANsJc/puiXquykJUF/
         FgWUXBKQFdut1XDF+nbrpjGP4Z24p19ez84r0GZnba5MOIUju9rFA/GXDjkMcMjRDiX6
         8iu7u0m75Por6ss53CCs4cSbcmaFjpmuobVJbKky6EudE4TvlFKCeIiHhFcOvmBabBuk
         quKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=U4JFrkrVHvp8aYamENGgl5bqVUJUysiGglA8u7rz5uQ=;
        b=5DApkdU3JQEB97Mmf9V+wETiExl2nTk2FwADoD96zY7DKauJxBTemqjguw683bTFPN
         4l9qgirMFnj5s2ESS1ebfJrKrabko6P/U2J7DXK0o/zMtL2NYrDuJOJujnsFEvHj6+tM
         dxRGGRQ8nZlAEyr2YKLvH8bCsVz7pIQEqdI3FJGMd5kHAvuVxrItyGQ89+ucR2Byhk9C
         Afnwl9hJS+HzQVICa02zZ32GIkF/CnxnZaLBrqO07h0yqS2AOmIi8uFLhOMUnvSdifh1
         9AP+LHCC7KGXWiAudI/9JBlEPkGq7As/LsH7dVhBC3de3ATOLn0QVoTG2GATUj2UyblV
         ENrw==
X-Gm-Message-State: AJIora8fiH3j5wwT3qvvH0skIMU8qggn+Iri50h+SXWsS4jzL9gFG9iG
	iQe2YUXg9VS2AVtlod9m7wQdirlKgBm5OcCzzNOcOku9WsRyOQ==
X-Google-Smtp-Source: AGRyM1vWRjI7oNaCAuW/+7+rNcsM2E/uT4LqDwPzpdSrbZzbTYxyBtLhRUnOItqwTQQ8inktCXyKF4Ylqk3KHABggXQ=
X-Received: by 2002:a05:6870:b254:b0:ec:6ca4:c89f with SMTP id
 b20-20020a056870b25400b000ec6ca4c89fmr11967926oam.272.1657930722990; Fri, 15
 Jul 2022 17:18:42 -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:  
 <32dc6f5b56a749f9b8e26330f9f2e8e0@lerctr.org> 
 <51ef4fe0c8c5bbe251d3e75084847a6e@lerctr.org> 
In-Reply-To: 
From: Mehmet Erol Sanliturk 
Date: Sat, 16 Jul 2022 03:18:06 +0300
Message-ID: 
Subject: Re: limits.conf/stacksize doesn't seem to work?
To: Mark Johnston 
Cc: Larry Rosenman , Freebsd current 
Content-Type: multipart/alternative; boundary="000000000000ce5f9305e3e1137c"
X-Rspamd-Queue-Id: 4Ll8376hCPz3Mww
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=F2UQakeH;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of m.e.sanliturk@gmail.com designates 2001:4860:4864:20::2d as permitted sender) smtp.mailfrom=m.e.sanliturk@gmail.com
X-Spamd-Result: default: False [-1.23 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.92)[-0.923];
	NEURAL_SPAM_SHORT(0.69)[0.693];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::2d:from];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TAGGED_FROM(0.00)[];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000ce5f9305e3e1137c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 16, 2022 at 1:32 AM Mark Johnston  wrote:

> On Fri, Jul 15, 2022 at 05:26:09PM -0500, Larry Rosenman wrote:
> > On 07/15/2022 5:24 pm, Mark Johnston wrote:
> > > On Fri, Jul 15, 2022 at 05:21:27PM -0500, Larry Rosenman wrote:
> > >> On 07/15/2022 5:18 pm, Mark Johnston wrote:
> > >> > On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman wrote:
> > >> >> I'm using the following kernel config:
> > >> >> [...]
> > >> >> and the following login.conf:
> > >> >> [...]
> > >> >> bacula_dir:\
> > >> >>         :stacksize-max=3D68719476736:\
> > >> >>         :stacksize-cur=3D68719476736:\
> > >> >>         :tc=3Ddaemon:
> > >> >> [...]
> > >> >> I've updated my (ler) password entry to reference bacula_dir:
> > >> >> ler::1001:1001:bacula_dir:0:0:Larry
> > >> >> Rosenman:/home/ler:/usr/local/bin/zsh
> > >> >>
> > >> >>
> > >> >> when I ssh in, the stacklimit is still:
> > >> >> =E2=9D=AF ulimit -H -s
> > >> >> 2097152
> > >> >
> > >> > What is the value of the kern.maxssiz sysctl on this system?
> > >> >
> > >> >> ler in =F0=9F=8C=90 borg in sys/amd64/conf=F0=9F=94=92 on =EE=82=
=A0
> ler/freebsd-main-changes:main on
> > >> >> =E2=98=81=EF=B8=8F  (us-east-1)
> > >> >> =E2=9D=AF ulimit -S -s
> > >> >> 2097152
> > >> >>
> > >> >> ler in =F0=9F=8C=90 borg in sys/amd64/conf=F0=9F=94=92 on =EE=82=
=A0
> ler/freebsd-main-changes:main on
> > >> >> =E2=98=81=EF=B8=8F  (us-east-1)
> > >> >> =E2=9D=AF
> > >> >>
> > >> >> Where does this number come from?  What am I missing here?
> > >> >
> > >> > The stack limit cannot be set to an arbitrarily large number.  It
> will
> > >> > silently be clamped to maxssiz.
> > >>
> > >> =E2=9D=AF sysctl kern.maxssiz
> > >> kern.maxssiz: 2147483648
> > >
> > > Then what you're seeing is expected.  The kernel is clamping the stac=
k
> > > segment limit to 2GB.
> >
> > I assume this is the default for MAXSSIZ?  and if I change that in the
> > kernel config, it will
> > allow bigger?  Where is this default defined?
>
> The default value is platform dependent.  On amd64 it's 512MB, so I'm
> not sure where your value is coming from.



-------------------------------------------------------



> It's defined in a header.
> You can set it in the kernel configuration, or as a tunable or sysctl.
>
>
-------------------------------------------------------


My opinion is that , there is some one ( or more ) constant(s)
defined elsewhere , because

setting  MAXSSIZ  is  NOT WORKING when it is larger than

the "unknown" default value ...


With my best wishes for all ,

Mehmet Erol Sanliturk

--000000000000ce5f9305e3e1137c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sat, Jul 16, 2022=
 at 1:32 AM Mark Johnston <markj@fr=
eebsd.org> wrote:
On Fri, Jul 15, 2022 at 05:26:09PM -0500, Larry Rosenman wrote:<=
br>
> On 07/15/2022 5:24 pm, Mark Johnston wrote:

> > On Fri, Jul 15, 2022 at 05:21:27PM -0500, Larry Rosenman wrote:
> >> On 07/15/2022 5:18 pm, Mark Johnston wrote:

> >> > On Fri, Jul 15, 2022 at 05:04:18PM -0500, Larry Rosenman=
 wrote:

> >> >> I'm using the following kernel config:

> >> >> [...]

> >> >> and the following login.conf:

> >> >> [...]

> >> >> bacula_dir:\

> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:stacksize-max=3D68=
719476736:\

> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:stacksize-cur=3D68=
719476736:\

> >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:tc=3Ddaemon:

> >> >> [...]

> >> >> I've updated my (ler) password entry to referenc=
e bacula_dir:

> >> >> ler:<elided>:1001:1001:bacula_dir:0:0:Larry
> >> >> Rosenman:/home/ler:/usr/local/bin/zsh

> >> >>

> >> >>

> >> >> when I ssh in, the stacklimit is still:

> >> >> =E2=9D=AF ulimit -H -s

> >> >> 2097152

> >> >

> >> > What is the value of the kern.maxssiz sysctl on this sys=
tem?

> >> >

> >> >> ler in =F0=9F=8C=90 borg in sys/amd64/conf=F0=9F=94=
=92 on =EE=82=A0 ler/freebsd-main-changes:main on

> >> >> =E2=98=81=EF=B8=8F=C2=A0 (us-east-1)

> >> >> =E2=9D=AF ulimit -S -s

> >> >> 2097152

> >> >>

> >> >> ler in =F0=9F=8C=90 borg in sys/amd64/conf=F0=9F=94=
=92 on =EE=82=A0 ler/freebsd-main-changes:main on

> >> >> =E2=98=81=EF=B8=8F=C2=A0 (us-east-1)

> >> >> =E2=9D=AF

> >> >>

> >> >> Where does this number come from?=C2=A0 What am I mi=
ssing here?

> >> >

> >> > The stack limit cannot be set to an arbitrarily large nu=
mber.=C2=A0 It will

> >> > silently be clamped to maxssiz.

> >> 

> >> =E2=9D=AF sysctl kern.maxssiz

> >> kern.maxssiz: 2147483648

> > 

> > Then what you're seeing is expected.=C2=A0 The kernel is clam=
ping the stack

> > segment limit to 2GB.

> 

> I assume this is the default for MAXSSIZ?=C2=A0 and if I change that i=
n the 

> kernel config, it will

> allow bigger?=C2=A0 Where is this default defined?



The default value is platform dependent.=C2=A0 On amd64 it's 512MB, so =
I'm

not sure where your value is coming from.=C2=A0

=


---------------------------------------------=
----------

=C2=A0
 It's defined in a header.

You can set it in the kernel configuration, or as a tunable or sysctl.



-----------------------=
--------------------------------


<=
div style=3D"font-family:tahoma,sans-serif;font-size:large" class=3D"gmail_=
default">My opinion is that , there is some one ( or more ) constant(s) 
defined elsewhere , because 

setting=C2=A0 MAXSSIZ=C2=A0 is=C2=A0 NOT WORKING when it is lar=
ger than

the "unknown" default=
 value ...


With my b=
est wishes for all ,

Mehmet Erol Sanlitu=
rk 






=C2=A0


--000000000000ce5f9305e3e1137c--

From nobody Sat Jul 16 16:09:23 2022
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 4LlY8H2KmSz4Wtg1
	for ; Sat, 16 Jul 2022 16:09:35 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LlY8H1r0cz3gQt
	for ; Sat, 16 Jul 2022 16:09:35 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657987775;
	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=XobhANGvZ2XIW0fpkv22AptCFftVJ1TnpLwxX5512zg=;
	b=nrU9U3o/9N+afJhs+X6MnSapW/cb8CTEAiFgbO33c1l8GMqb+nMJ+esl2qEnU4jKHSnZtM
	TDV3WJcYOdneupYvmvVQHx7ASx8j3NWtN+FGAXOLah99jtTA4OhfZHB3LWzjC5R/D4BafB
	i4MrqpdFF7TW3txNKWIuWxN2GoJQRPyfAeFivWF/6GGa6enqdfM1xchPoWzxxnKLKNUZxg
	BLXn8Fon0zs5YWMsc+73G0c7Ec4pGoiGemDFfm9CaBTTh95ifUnsaxBXjw34cg3FldS9dO
	DeAw5qiwHCqZ+JqHnThaAul+/VD5qn8H/eU52NlSZ+hQFMDrC17tbGXDVA4H1g==
Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com [209.85.160.45])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LlY8H0p2PzTvH
	for ; Sat, 16 Jul 2022 16:09:35 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-10c0e6dd55eso13044059fac.7
        for ; Sat, 16 Jul 2022 09:09:35 -0700 (PDT)
X-Gm-Message-State: AJIora99saBqfXU5b+uMoyBYcfXz/EefmkSmRjFqUihRCnqT/Pe+F9kd
	3BsaxLhm1m9i6pY/FnZx63lfxNf144sKJd9G4w4=
X-Google-Smtp-Source: AGRyM1s+Qtl0ybGME2qVEiwFgblrkPPwEt7g3jHds74rModKEz/ozkEeozq+BV1HaoqZ4eEtLsM2g7Pvcvt07Z2XioQ=
X-Received: by 2002:a05:6870:972c:b0:10c:151d:4df8 with SMTP id
 n44-20020a056870972c00b0010c151d4df8mr12801510oaq.210.1657987774244; Sat, 16
 Jul 2022 09:09:34 -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: Nuno Teixeira 
Date: Sat, 16 Jul 2022 17:09:23 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: About zfs upgrade
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000536d4805e3ee5c5b"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657987775;
	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=XobhANGvZ2XIW0fpkv22AptCFftVJ1TnpLwxX5512zg=;
	b=CfHTabOTmGL6aHNwY3ehxLACZidazG7WlgOYdbHp2GQfdg/4hns+oRwe+Kdtauc7FSc3zM
	VuCPLqDdM/bYzGkHykMFfV/N59GilbhS9AwUcOBQGLj0B04nqG61hIzJXC/K9G8pMHPL+y
	hZA3j/wHmCEE0KeXFIy6nxG9rCfZLe9Wi5RqBylL29jd/d817TjNGfIPV2I2ani9iC/1/w
	YXipow59da3CygLkaxlSojewXJkZ8//w59lvZBW0hdfU9PZHmNGeARby3GHo/PV9tHor5j
	0wzyBI+7LWwe8FTmy8c2HnCG2BGdUgrSTVNG9bBXeNz2t4VII/TqF2gnPIB7qQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657987775; a=rsa-sha256; cv=none;
	b=gCQQVq/yALl2Q8v87qzcB09aJ47kz8Mq3qkNLgpv34JPXFE4X7lbZ7aqAj+Veze/WBC8dS
	VIxqpC0+LML1+1uEiq+DKG+EcbcvoLx67vlVU1fqA5i2+aTYaGeyeUbohodtZVodw+5t8r
	GjXG5vrfMMYDoozhaEqnL6J6ViHkma66HSFavV8gH2SFVnE72rBySMUzpy+Rz2FTOrPmsU
	Aqi1DpOn/QB0laBG2Zg1HwQvr5OGmGpQdQkZzIhByxskYQF8swro4nANqN8R6JLXmd6fop
	cHw8vdGVa2Yiv9QZDzu38N3VDYccoV5Q6mZ5/nPOPrrNvIXKai5CbsJUiBxhog==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000536d4805e3ee5c5b
Content-Type: text/plain; charset="UTF-8"

Hello,

I'm about to upgrade zfs pool and I need to know the command to update boot
code on my efi config:
---
 gpart show
=>        40  2000409184  nvd0  GPT  (954G)
          40      532480     1  efi  (260M)
      532520        2008        - free -  (1.0M)
      534528     8388608     2  freebsd-swap  (4.0G)
     8923136  1991485440     3  freebsd-zfs  (950G)
  2000408576         648        - free -  (324K)
---
Handbook says:
gpart bootcode -p /boot/boot1.efifat -i 1 ada1

Should I use:
gpart bootcode -p /boot/boot1.efifat -i 1 nvd0p1 ?

Thanks,

Nuno Teixeira

--000000000000536d4805e3ee5c5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

I'm about to u=
pgrade zfs pool and I need to know the command to update boot code on my ef=
i config:
---
=C2=A0gpart show
=3D> =C2=A0 =C2=A0=
 =C2=A0 =C2=A040 =C2=A02000409184 =C2=A0nvd0 =C2=A0GPT =C2=A0(954G)
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 40 =C2=A0 =C2=A0 =C2=A0532480 =C2=A0 =C2=A0=
 1 =C2=A0efi =C2=A0(260M)
=C2=A0 =C2=A0 =C2=A0 532520 =C2=A0 =C2=A0 =C2=
=A0 =C2=A02008 =C2=A0 =C2=A0 =C2=A0 =C2=A0- free - =C2=A0(1.0M)
=C2=A0 =
=C2=A0 =C2=A0 534528 =C2=A0 =C2=A0 8388608 =C2=A0 =C2=A0 2 =C2=A0freebsd-sw=
ap =C2=A0(4.0G)
=C2=A0 =C2=A0 =C2=A08923136 =C2=A01991485440 =C2=A0 =C2=
=A0 3 =C2=A0freebsd-zfs =C2=A0(950G)
=C2=A0 2000408576 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 648 =C2=A0 =C2=A0 =C2=A0 =C2=A0- free - =C2=A0(324K)
-=
--
Handbook says:
gpart bootcode -p /boot/boot1.efifat =
-i 1 ada1

Should I use:
gpart bootcode -p /bo=
ot/boot1.efifat -i 1 nvd0p1 ?

Thanks,

Nuno Teixei=
ra


--000000000000536d4805e3ee5c5b--

From nobody Sat Jul 16 16:17:48 2022
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 4LlYKw5yHLz4Wvdy
	for ; Sat, 16 Jul 2022 16:17: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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LlYKw5M7Nz3hTb;
	Sat, 16 Jul 2022 16:17:56 +0000 (UTC)
	(envelope-from dim@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657988276;
	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=9563fNWwHTGZmARCkMgYPZWOZSH82hgLNmW+dVfQMgI=;
	b=RET/scalpk952hrTCqT5zlN1JAHzmArvoRp8DpmxImBcW5TgnN8U7Bee+dF2n7bfSnxy88
	gSPKoFXyQ0Xw2O/wW7CStCJuXGnfb65j/YJta9Kk3Aymw8ZJgnwj5VG94KYIY2qLDSgQh5
	tn5BUuEGEEkjMXKrVfFsRpV1hNq31NHqnLUZKKu2qJTiME1bvO0acsItXmv+FsIytzQvia
	6Ilx/Daixmek42iX+RGVFBHYm+2v7YvndG4Gm+cHqbpD4jUj2IskVoUNMlZStSmpof5dAM
	tzwYBCrBKVlyO9ysAWZu0fpxxt42NYM7glEVs9gqvkaz/0W2d7FZXKusYGb4Nw==
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 "R3" (verified OK))
	(Authenticated sender: dim)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LlYKw3fJqzV4h;
	Sat, 16 Jul 2022 16:17: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 E5E51503F2;
	Sat, 16 Jul 2022 18:17:54 +0200 (CEST)
Content-Type: multipart/signed;
	boundary="Apple-Mail=_7D4187C9-4688-4E1D-B057-F9E07D0901E9";
	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 \(3696.100.31\))
Subject: Re: About zfs upgrade
From: Dimitry Andric 
In-Reply-To: 
Date: Sat, 16 Jul 2022 18:17:48 +0200
Cc: FreeBSD CURRENT 
Message-Id: 
References: 
To: Nuno Teixeira 
X-Mailer: Apple Mail (2.3696.100.31)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657988276;
	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=9563fNWwHTGZmARCkMgYPZWOZSH82hgLNmW+dVfQMgI=;
	b=WHZT4E2aWZAcSFUyGNVNRL0W3jUWh2dRJzrFUNUoqg1ATKCiYyc6PDzd/Vmwxwid3I38HZ
	D8GPZbEdl5N0PFkr2Soclth7Q0RN+w8QjCgYTevXdIMQlKlI7UDt4mbxBfqs8B0Ous24Fc
	ZfB2uqhrFtUHZrXTQIuJbmGrbHg4y+ELN5nttlKKXd/Q0itQRjQuH94pVUOqPBd8xOTUg2
	UG7ez9tUjQ2V6KMGeEB0wZJATxm5xkfMY7szDOhE1ZtiliW0iLj712SwYZBYU57KJGqFqe
	d5BUW/ecg9FrZDWPw6itnWO7Ll1vmWabl8QAh8+1Smmq/4/mfYAcRShKc+oiOg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657988276; a=rsa-sha256; cv=none;
	b=CEZ8hwHbk5bI7ddI1ORDk2QCpL9jDlZBhaAC6tTtu7vcqrkI51EYycrKv0trPL7AUgVnf9
	0WHXMekoMH60ocyv/7yS0G3sTR7MxqnbqqouAovXkDOOk0rLEh4Rcf1P6zyFHInOsBeXv3
	D31Kc74fk/vmBCNVrYRs06hyGt7I63m0snECtXZkn6QHxk/xeKqXtEIHT0DDFp1fYUArNQ
	+gDnkQpxSEKsD5dM/UFCGU4HgyvYSpoFauicYQets01Eke8SZRwGYq0bxDCWBG3e43y8HX
	+S5SpxcVhCBW3hvCuESh1q9YOLeM+GzEZJ2EUiG6I19rM8+m+wqd6aSgL9yolg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_7D4187C9-4688-4E1D-B057-F9E07D0901E9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 16 Jul 2022, at 18:09, Nuno Teixeira  wrote:
> I'm about to upgrade zfs pool and I need to know the command to update =
boot code on my efi config:
> ---
>  gpart show
> =3D>        40  2000409184  nvd0  GPT  (954G)
>           40      532480     1  efi  (260M)
>       532520        2008        - free -  (1.0M)
>       534528     8388608     2  freebsd-swap  (4.0G)
>      8923136  1991485440     3  freebsd-zfs  (950G)
>   2000408576         648        - free -  (324K)
> ---
> Handbook says:
> gpart bootcode -p /boot/boot1.efifat -i 1 ada1
>=20
> Should I use:
> gpart bootcode -p /boot/boot1.efifat -i 1 nvd0p1 ?

For gpart, you should specify the base device, i.e. nvd0. The "-i 1" =
option indicates the partition.

In any case, assuming FreeBSD 13 or later, you can just mount the EFI =
partition and copy loader.efi over:

mount -t msdosfs /dev/nvd0p1 /mnt
cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
cp /boot/loader.efi /mnt/efi/boot/bootx64.efi

That way you could also revert to bootx64.old if things go wrong.

-Dimitry


--Apple-Mail=_7D4187C9-4688-4E1D-B057-F9E07D0901E9
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

iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYtLkrQAKCRCwXqMKLiCW
o32cAKCxPFRZPdq3d5wWwphp317Az3xQEwCgh8ScImrq+0405UZXWg8ckIdOT2M=
=1dlt
-----END PGP SIGNATURE-----

--Apple-Mail=_7D4187C9-4688-4E1D-B057-F9E07D0901E9--

From nobody Sat Jul 16 16:57:55 2022
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 4LlZDH3hZBz4X0RR
	for ; Sat, 16 Jul 2022 16:58:07 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LlZDH36jFz3lt9;
	Sat, 16 Jul 2022 16:58:07 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1657990687;
	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=MpzNCcMNegNak/GHTOu1+0ub5ivl0Yt56D8Ik7mhuHc=;
	b=aefgwMeiy1zOxYPfPV9Z7v+9D/qgkRLpDT7x43IgvmKx+92X+fBpNagT+IoNxu++T+uBC/
	HXIRt9HKB0kz2cuAMS9GrX3KH6P3vvTBk5oOUFG2k85xAUUo3VqT2FC1/pNGBoQ8xKjtly
	V1L+FnkCgZ/DnUum3hjKh6srE2L8v9/vxXNa5+2mciyj1B5KQvNFnhJ7Btaa1IPWrvlrir
	3NDOPlRJp2+c0NtqMUp+PXk/4YHVQCM+17ORGzKQTfMUjx6Qnp1qmUDp6HoubuKjsGEEYA
	HDWfq0jYCyBs7hEwTCCBWUcs4pv4aZqHDA6GWwXffmdkgbFQ+imWrLgUg7lEdA==
Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LlZDH22CJzV4y;
	Sat, 16 Jul 2022 16:58:07 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-10c0430e27dso13301154fac.4;
        Sat, 16 Jul 2022 09:58:07 -0700 (PDT)
X-Gm-Message-State: AJIora8hrK05F36rpKGpTxULMHDoxBCEBh/YITz/KiIJ9OQ5DSD639IS
	wbSFQvGTUx3IOrPjBynnQ1+siFEXeSOTbW4z6Ac=
X-Google-Smtp-Source: AGRyM1vj/2sXPMdC8YdclXVJw+1JRwEBZM/87XNnKvc57l12s/H9oQx476kXSH/nw7SVw3lsWnTI3jDX3LujrGkT4lY=
X-Received: by 2002:a05:6870:972c:b0:10c:151d:4df8 with SMTP id
 n44-20020a056870972c00b0010c151d4df8mr12888175oaq.210.1657990686560; Sat, 16
 Jul 2022 09:58:06 -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: Nuno Teixeira 
Date: Sat, 16 Jul 2022 17:57:55 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: About zfs upgrade
To: Dimitry Andric 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000e9d97305e3ef09b4"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1657990687;
	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=MpzNCcMNegNak/GHTOu1+0ub5ivl0Yt56D8Ik7mhuHc=;
	b=S2Ixhz7QkGOXpwz2X1iMGepP/W26ty+9MZi6s3PIe2XAKquaiq+NAyCFBcu5JTE8gCKzJk
	e2a5u4VbYLpbBdr/ziKjOCHZ6WHiRT+zj+B0GLZZ+a0N96e5ySuqX8xYn2sElEFPHPFD6B
	ky7HFpDBEjV5wK9SUxyshnGi8JISswB52M9/3Wy881qdOL0tqAqZHV6Qla8oinx7F43vGw
	ZdHIisV4Sek3aKl8ALK7cqyysdHIj+q1Xi7RO7wNjpMv4NTINuW1ZdE0OvA63OpJu+OV5c
	TljPD5y0QneEeuC8+H2rjc6tpoIzAHvMUmIUAAGSePfKYSB1ur1vdz99gcQkDQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657990687; a=rsa-sha256; cv=none;
	b=JeqPZ8uk5yDiq/pHDsb3OEF94f0JKFSpcvTdl1JYIbOj8VGUPCO4V/wdvaDFqJRljvDnr9
	vnOIAjI0uOd/5AbLIAAYzPtokPGCZGiLNVkO/qEKs5aFlwNtw+3BADt6Ko9tmVG4EcQhYM
	uWnk9vfZsygwU+Hx/duetdzsnTNUw5T23W/cdsA4WtS3ubphU9z+ve8aPxzarjGSo6x98N
	fkJP1vMOzZZIfe9Icx9P6wFThTu5RgfhLhngWjVDJfNYZOouQnAHbnVCczBulcA5UaLiCG
	AWaQldhOnH/dzD29yCGrLLlnfBr6/9vx58wEpKoq2Gx1PWAoX2Y+/vh0/DPreA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e9d97305e3ef09b4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Dimitry!

Thanks for the tips. zfs upgraded, bootcode updated and system working fine=
.

Cheers,

Nuno Teixeira

Dimitry Andric  escreveu no dia s=C3=A1bado, 16/07/2022 =
=C3=A0(s)
17:17:

> On 16 Jul 2022, at 18:09, Nuno Teixeira  wrote:
> > I'm about to upgrade zfs pool and I need to know the command to update
> boot code on my efi config:
> > ---
> >  gpart show
> > =3D>        40  2000409184  nvd0  GPT  (954G)
> >           40      532480     1  efi  (260M)
> >       532520        2008        - free -  (1.0M)
> >       534528     8388608     2  freebsd-swap  (4.0G)
> >      8923136  1991485440     3  freebsd-zfs  (950G)
> >   2000408576         648        - free -  (324K)
> > ---
> > Handbook says:
> > gpart bootcode -p /boot/boot1.efifat -i 1 ada1
> >
> > Should I use:
> > gpart bootcode -p /boot/boot1.efifat -i 1 nvd0p1 ?
>
> For gpart, you should specify the base device, i.e. nvd0. The "-i 1"
> option indicates the partition.
>
> In any case, assuming FreeBSD 13 or later, you can just mount the EFI
> partition and copy loader.efi over:
>
> mount -t msdosfs /dev/nvd0p1 /mnt
> cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
> cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
>
> That way you could also revert to bootx64.old if things go wrong.
>
> -Dimitry
>
>

--000000000000e9d97305e3ef09b4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Dimitry!

Thanks for the =
tips. zfs upgraded, bootcode updated and system working fine.

=
Cheers,

Nuno Teixeira

=

Dimitry Andric <dim@freebsd.org> escreveu no dia s=C3=A1bado, 16/07=
/2022 =C3=A0(s) 17:17:
On 16 Jul 2022, at 18:09, Nuno Teixeira <eduardo@freebsd.org> wrote:

> I'm about to upgrade zfs pool and I need to know the command to up=
date boot code on my efi config:

> ---

>=C2=A0 gpart show

> =3D>=C2=A0 =C2=A0 =C2=A0 =C2=A0 40=C2=A0 2000409184=C2=A0 nvd0=C2=
=A0 GPT=C2=A0 (954G)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A040=C2=A0 =C2=A0 =C2=A0 532480=
=C2=A0 =C2=A0 =C2=A01=C2=A0 efi=C2=A0 (260M)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0532520=C2=A0 =C2=A0 =C2=A0 =C2=A0 2008=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 - free -=C2=A0 (1.0M)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0534528=C2=A0 =C2=A0 =C2=A08388608=C2=A0 =C2=
=A0 =C2=A02=C2=A0 freebsd-swap=C2=A0 (4.0G)

>=C2=A0 =C2=A0 =C2=A0 8923136=C2=A0 1991485440=C2=A0 =C2=A0 =C2=A03=C2=
=A0 freebsd-zfs=C2=A0 (950G)

>=C2=A0 =C2=A02000408576=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0648=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 - free -=C2=A0 (324K)

> ---

> Handbook says:

> gpart bootcode -p /boot/boot1.efifat -i 1 ada1

> 

> Should I use:

> gpart bootcode -p /boot/boot1.efifat -i 1 nvd0p1 ?



For gpart, you should specify the base device, i.e. nvd0. The "-i 1&qu=
ot; option indicates the partition.



In any case, assuming FreeBSD 13 or later, you can just mount the EFI parti=
tion and copy loader.efi over:



mount -t msdosfs /dev/nvd0p1 /mnt

cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old

cp /boot/loader.efi /mnt/efi/boot/bootx64.efi



That way you could also revert to bootx64.old if things go wrong.



-Dimitry






--000000000000e9d97305e3ef09b4--

From nobody Sat Jul 16 16:57:53 2022
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 4LlZJJ5RCwz4X14v
	for ; Sat, 16 Jul 2022 17:01:36 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LlZJJ1VHjz3nR3
	for ; Sat, 16 Jul 2022 17:01:36 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: by mail-wm1-x32c.google.com with SMTP id ay25so4552917wmb.1
        for ; Sat, 16 Jul 2022 10:01:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=message-id:date:mime-version:user-agent:subject:content-language:to
         :references:from:in-reply-to:content-transfer-encoding;
        bh=PxjwT7HDgAAOiRy+xAHFkqWUGl1cu/Ej/+P4AuIoO5k=;
        b=CS6L5acknnIvhCqLLI7ICRZfq5Q8V4SxjZSqE87vtm9lju8EGF5yzZyJbR3rkIZHCG
         8JScuBPcmvY2HYNjz/5xM/rPk3E/JBK7amF3YMzAxvWHE0tnhCBiiy1S1vHMRuD6e/Rh
         qr4ss2xCsdQdT3v5kKBQhgyQ+5xYbCFOIkVgyTHc9OZC2kx+/GW/szF5YOhGZNftubkV
         zS08hkKPLiShlGkg1cCV80VkR/GTLHZjoPuc0DZiVBzO/5IllAWEoFSXpDze8dmJiqkk
         NMy6cStMUDGFUMe0VRTal6nO2qiY3Q++MVwBvAjWRBNZNmAVdUFCMvDdNmyLEfu2wDPf
         E3Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
         :content-language:to:references:from:in-reply-to
         :content-transfer-encoding;
        bh=PxjwT7HDgAAOiRy+xAHFkqWUGl1cu/Ej/+P4AuIoO5k=;
        b=zwsa43xjHOu0sepnfavPED65N5Vk6vRVCEq7o+nHHPOqZLqFMTp/8lX0oX1TeDQcWL
         2WcvQcg7S8g5/B5tLvau71iMTEO9HNAfcGCx19R61yJIvPr510yq1opwwiV05vwTzkjZ
         +Rb4OdLvsscRYvHFppd5+Nuv4mWz3oIJKw7kcb0GgbugdJV2bGv0YJDFOP//k8KZD5kq
         3OMo0imY598rWqr2HDI/Z0VwTZcWSW3/9xKABoLrNtSyxK8ImPCTu8S/7k/Z3YUpqmK2
         rUq3IaR1WZI+3h5/El/X9yXl8bmvv0Lx5+4ImWggBIavcDe5Y11Zkyfatj5OPdnu575Z
         YvHA==
X-Gm-Message-State: AJIora/5YHvupmz4HO+47C9/QpRV1tk3/5rSNrg077ZXKZm2uvARQC2a
	rjKL95nR6a6FpU0g6xv5TweCf+QtZ6sTsw==
X-Google-Smtp-Source: AGRyM1uJK1J3D/8lE9ZY0jBVj/yvMBMTvL9gFgkS4yo4vE5ZGobQhsSixbXWe3E8tuT3EvaP5kjsdQ==
X-Received: by 2002:a7b:c7cd:0:b0:3a3:8f1:8aeb with SMTP id z13-20020a7bc7cd000000b003a308f18aebmr9863294wmk.90.1657990895003;
        Sat, 16 Jul 2022 10:01:35 -0700 (PDT)
Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2])
        by smtp.gmail.com with ESMTPSA id w12-20020adfd4cc000000b0021d905477dfsm6419089wrk.86.2022.07.16.10.01.34
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 16 Jul 2022 10:01:34 -0700 (PDT)
Message-ID: 
Date: Sat, 16 Jul 2022 17:57:53 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: About zfs upgrade
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: 
From: Graham Perrin 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LlZJJ1VHjz3nR3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=CS6L5ack;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32c as permitted sender) smtp.mailfrom=grahamperrin@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.99)[-0.990];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	FREEFALL_USER(0.00)[grahamperrin];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32c:from];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 16/07/2022 17:09, Nuno Teixeira wrote:
> … efi config: …

> … Should I use:gpart bootcode …


 "… To update old 
ESP partitions, users should stop using the gpart(8) 
 
utility. …" – frequently overlooked :-)


From nobody Mon Jul 18 12:46:43 2022
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 4LmhYb6YYbz4T43C
	for ; Mon, 18 Jul 2022 12:46:59 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4LmhYZ5v4Lz3lbm
	for ; Mon, 18 Jul 2022 12:46:58 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 271FB260CC1
	for ; Mon, 18 Jul 2022 14:46:51 +0200 (CEST)
Message-ID: <97b63c7e-0d34-f92f-19da-09cacfd02ef4@selasky.org>
Date: Mon, 18 Jul 2022 14:46:43 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: Accessibility in the FreeBSD installer and console
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <080B179E-359E-4796-BFC8-0AAC65089100@googlemail.com>
 <788EF362-E06B-4BA9-BDDB-E550D35E21CB@freebsd.org>
 <4B9142D0-626B-43B0-A8EF-A71CB655E080@googlemail.com>
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LmhYZ5v4Lz3lbm
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

There are three work in progress patches pending:

1) Updates for kernel
https://reviews.freebsd.org/D35754

2) Updates for beep
https://reviews.freebsd.org/D35772

3) New vtspeakd daemon
https://reviews.freebsd.org/D35776

Please test if you can!

Feedback is welcome.

--HPS

From nobody Thu Jul 21 15:31:38 2022
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 4Lpc4R4LvHz4WtDP
	for ; Thu, 21 Jul 2022 15:31:51 +0000 (UTC)
	(envelope-from ctuffli@gmail.com)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lpc4R0987z4FCt
	for ; Thu, 21 Jul 2022 15:31:51 +0000 (UTC)
	(envelope-from ctuffli@gmail.com)
Received: by mail-ed1-x535.google.com with SMTP id t3so2673542edd.0
        for ; Thu, 21 Jul 2022 08:31:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=TGGGHsWrtYhxbjhIhTUfKgCII098u+xtS1Ii6kZJblI=;
        b=P9BHwHF5/O9cC0iNqKFTZRE4fydjOPMe9TAf0TpfSgmsIwiin9ExVWxSUlea5Rj0mk
         AHPTtHqVj2qUvYHY1btP4Y8K8Y9Zxp1ctya9gatQvwI3QDcMNRKqellIf+UtIjRLSDqj
         GhqCEJQLM7LkvZ/f7JSDRYlPQ///bk1gMA/abl6KL8lFZnQ8ec58xlWVK0Ff7N02f0aZ
         4NYHQdyS3DwHPdvTiHo8Q9pADTvoMWFMQinHZ0n/NgWJBoW6/vc7IF/AEHjcqM0BxPoz
         ZNDLjKPz8t26FZIz8yiIRfHtDVh+d9aoR+0ZU/+jJo5nHXr5G/JvvUdN9CE83Widb4HO
         Jkog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=TGGGHsWrtYhxbjhIhTUfKgCII098u+xtS1Ii6kZJblI=;
        b=OdPyRq8QI3a0TxdentnA6rn2BAy6MKyQfz5XckoKwq5OmTX45u0cKmFOS2XcZvD1VN
         RC/chIPLBX778Jb59GD4IWjYeguuQJmkt6222sm8Fz1OPxW3MAEXT8p8uPvagfOgD+X9
         RWloXc2w43KrK550nrHLgVjN+KRgTcBgZSt0GHMm7dpfJHBiSQ4jVWkFNJC2JHFBzi7s
         UvzK4vctjSOs3kbmeSh826N3skT97L5KtjFo/AunbAH+A8ROadKBQZDqusLGQ1GBl1ID
         SjuGV4UEt6O1qQ05rtMerNNSL1IZJVsWHs0upKAcgw42b/jWpefPQir1D0+zgpNXmBxQ
         PiCA==
X-Gm-Message-State: AJIora8oG3nLEgRS01Sc1BRhRH/mMJ61B86vD0HRWWHxdAccvT/Dwg9a
	GZMIY8q9aa5YXmCrPzk9Qu7nmXC9bsqlb0j2n+OsM0SUI9sp3Q==
X-Google-Smtp-Source: AGRyM1ty1hWhWQQZHHNZvSJWZXNFMA88hx7sMUwhqttJTXf0S42ahDh97sIm1zHH4DadipEuRhdp1jURuwdFebqhGGY=
X-Received: by 2002:a05:6402:3807:b0:435:20fb:318d with SMTP id
 es7-20020a056402380700b0043520fb318dmr55863071edb.272.1658417509616; Thu, 21
 Jul 2022 08:31: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
From: Chuck Tuffli 
Date: Thu, 21 Jul 2022 08:31:38 -0700
Message-ID: 
Subject: bhyve core dump related to llvm 14
To: FreeBSD-Current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4Lpc4R0987z4FCt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=P9BHwHF5;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of ctuffli@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=ctuffli@gmail.com
X-Spamd-Result: default: False [-3.94 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	NEURAL_HAM_MEDIUM(-0.94)[-0.944];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

I have a virtual machine used to test the NVMe emulation in bhyve. All
of the tests in the VM pass running under FreeBSD 13.1-R, but the same
VM running under -current causes bhyve(8) to dump core because of a
segmentation fault.

git bisect identified the last "good" commit on main as
    cb2ae6163174 sysvsem: Fix a typo
After this commit, there are a half-dozen commits related to merging
the llvm project release/14.x

The core dump is repeatable and consistent. Back traces under lldb
look similar to this:

* thread #22, name = 'vcpu 2', stop reason = signal SIGSEGV: invalid
address (fault address: 0xb8)
  * frame #0: 0x0000383eb9fc916b
                     bhyve`pci_nvme_read(ctx=0x000038483ad2d700, vcpu=0,
                     pi=0x0000000000000000, baridx=-188391150,
offset=0, size=0) at
                     pci_nvme.c:3035:34
    frame #1: 0x0000384834616280
    frame #2: 0x0000383eb9fc1f7a
                     bhyve`pci_emul_mem_handler(ctx=,
vcpu=,
                     dir=, addr=, size=,
                     val=, arg1=0x00003846e5b71600, arg2=0) at
                     pci_emul.c:498:4

In frame 0, pi being NULL causes the core dump, but most of the
arguments are invalid / garbage. Looking earlier in the stack, the
vcpu value should be 2, the ctx pointer doesn't match, and the value
passed to pi isn't NULL.

Poking around in frame 2, I can see that the "direction" is a memory
write (dir == MEM_F_WRITE) and the statement being executed is this:
    (*pe->pe_barwrite)(ctx, vcpu, pdi, bidx, offset, size, *val);

Confusingly, the function pointer pe_barwrite is pci_nvme_write() and
not pci_nvme_read() where the crash occurs. I've confirmed the fault
is in pci_nvme_read() by adding an assert for pi != NULL. This is
especially odd because pci_emul_mem_handler() directly calls
pci_nvme_read() and pci_nvme_write(). So why does frame 1 exist at
all?

Using gdb, the back traces either don't decode at all or look similar to this:
(gdb) bt
#0  pci_nvme_read (ctx=0x944c1168700, vcpu=0, pi=0x0,
baridx=-1835053270, offset=0, size=0)
    at /poudriere/jails/14-current-amd64/usr/src/usr.sbin/bhyve/pci_nvme.c:3035
#1  0x000009436891d8e8 in _CurrentRuneLocale () from /lib/libc.so.7
#2  0x000009436a73ca28 in ?? ()
#3  0x000009436a73e1c0 in ?? ()
...
#34 0x000009436a747600 in ?? ()
#35 0x0000093b3e76b088 in pci_de_lpc ()
#36 0x000009436a716500 in ?? ()
#37 0x00000944c3196d10 in ?? ()
#38 0x0000093b3e74501a in pci_emul_mem_handler (ctx=0x9436a7bd670, vcpu=0,
    dir=, addr=, size=0,
val=0x646165725f657469, arg1=0x1,
    arg2=10185153275136)
    at /poudriere/jails/14-current-amd64/usr/src/usr.sbin/bhyve/pci_emul.c:498

Other random tidbits:
 - disabling compiler optimization (i.e. -O0) for the two files in
question (pci_nvme.c and pci_emul.c) makes the core dump go away
 - using the default optimization level but generously sprinkling
debug printf everywhere makes the core dump go away.

I'm not sure where to go from here and could use some help.

--chuck

From nobody Thu Jul 21 22:52:32 2022
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 4LpnxR6wc4z4WVht;
	Thu, 21 Jul 2022 22:56:27 +0000 (UTC)
	(envelope-from jhs@berklix.com)
Received: from land.berklix.org (land.berklix.org [144.76.10.75])
	(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 "land.berklix.org", Issuer "land.berklix.org" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LpnxQ4yqBz400P;
	Thu, 21 Jul 2022 22:56:26 +0000 (UTC)
	(envelope-from jhs@berklix.com)
Received: from lapr.no.berklix.net (p508db428.dip0.t-ipconnect.de [80.141.180.40])
	(authenticated bits=128)
	by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 26LMuINf084445
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL);
	Thu, 21 Jul 2022 22:56:18 GMT
	(envelope-from jhs@berklix.com)
Received: from lapr.no.berklix.net (localhost [127.0.0.1])
	by lapr.no.berklix.net (8.16.1/8.16.1) with ESMTPS id 26LMqWCM058438
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 21 Jul 2022 22:52:32 GMT
	(envelope-from jhs@lapr.no.berklix.net)
Received: (from jhs@localhost)
	by lapr.no.berklix.net (8.16.1/8.16.1/Submit) id 26LMqWmr058437;
	Fri, 22 Jul 2022 00:52:32 +0200 (CEST)
	(envelope-from jhs)
Message-Id: <202207212252.26LMqWmr058437@lapr.no.berklix.net>
To: current@freebsd.org
cc: ctm-users@freebsd.org, Andre Albsmeier 
Subject: where are the git to svn export script(s) please ?
From: "Julian H. Stacey" 
Organization: http://berklix.com/jhs/
User-agent: EXMH on FreeBSD http://www.berklix.eu/free/
X-From: http://www.berklix.eu/~jhs/
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-ID: <58435.1658443952.1@lapr.no.berklix.net>
Date: Fri, 22 Jul 2022 00:52:32 +0200
X-Rspamd-Queue-Id: 4LpnxQ4yqBz400P
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com
X-Spamd-Result: default: False [-1.10 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[ctm-users@freebsd.org,current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_COUNT_THREE(0.00)[4];
	HAS_ORG_HEADER(0.00)[];
	ARC_NA(0.00)[];
	FREEFALL_USER(0.00)[jhs];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[berklix.com];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi current@freebsd.org
cc ctm-users@freebsd.org

Has git to svn exporter stopped for src-12 ?
	https://svnweb.freebsd.org/base/stable/12/
Closure of ports from svn was mentioned long ago for ports@ at:
	https://www.freebsd.org/developers/cvs/
But no mention of src-12, src-cur & svn tree itself.

Reason for asking:
The CTM (src[*], ports & svn patches for freebsd.org sent by mail) generator
runs on host http://ctm.berklix.org, using a lot of inherited opaque
scripts that use svn. 

Rather than lose more time trying to understand those scripts &
convert them to call git, it might be quicker for me to copy the
git to svn export script(s) & run export from git to svn on host
ctm.berklix.org ?

Where are the git to svn export scripts & crontab sample invocations please ?

Cheers,
-- 
Julian Stacey  http://berklix.com/jhs/ http://stolenVotes.uk
Arm Ukraine, Zap killer Putin, grain & fuel loss hits poorest.

From nobody Thu Jul 21 23:21:03 2022
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 4LppV459ZLz4WXw7
	for ; Thu, 21 Jul 2022 23:21:16 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LppV44dtLz42Rc
	for ; Thu, 21 Jul 2022 23:21:16 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe35.google.com with SMTP id k129so2956161vsk.2
        for ; Thu, 21 Jul 2022 16:21:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=29UJK4ox8ckOsL0ck8F39byu5psZBIV0I4HWTStMJPk=;
        b=gdNpXHsCof8Tjmoz3OlckqbscXjlYQDGYnZxhXdziHPhfkmpy1yx0t+6kjk07coO7V
         fvXCdECdukVo9zJ0Ftp8+tXVPsMhA3pubifX9yb9JN/MaW1Ppn2QS4CUeXG1Vqg7QDjN
         WOktGD/lOalPr8CaS2gffB+A7nSrpCXz6RDpdDhzNc7kL1BEKsOnh625GeP8E8rGUevu
         /fMVj1OphI6wL+Svk7NRzuwtQIUMShCPRUsjjtGri9HGRJ6t4dVshnjZaNsaAXg2aXxV
         iFSSLzuv22VdhpRYT0bFCHJeofopGp3hedRpjPTp80NrSnvOP8sNrY9gRy+FgngIqOHU
         leJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=29UJK4ox8ckOsL0ck8F39byu5psZBIV0I4HWTStMJPk=;
        b=COAo3yL3FEJkXi2RMPilCwXQLDZpkwdWlP/nEcUJRC0b0dKsE0g6XbkF/+I375X7cW
         CFGHr4M2Dj7rDfFSI0Sf7286XwDj6oPeUmPUsys61j7vJLTLHj52DEtmrHsG3YOGrr9s
         3C30vb3YBpmzBS8NhBtDIocwsX9E2F1W/rk4Wc4y2vcpKuGznzR6dhSYQrZdgeKlHOtP
         5Wl4bNAEgoT6XWD8oX6wQxHPE1bQdCpSgH/B9Nd2JlMkAuopWIjOB4oan3mXMzP1pZro
         QkgMZvuHK0KBUaP5p2YX7nsDXMR01GbAjtrvcjb5Y1UOFSQ47uIG1/crhCavy5BfTR6I
         AW3g==
X-Gm-Message-State: AJIora/g86fSn1d0MV1tB5yg5bYYz2IxkHqiLH5tU72LiENwrtvkkdZq
	vNEUfrHNp0nUFgzDxxGZiCB3yV7tLAEyknX1FskWMw==
X-Google-Smtp-Source: AGRyM1szDHjVydc8bpgOXjvKpESWrJpPac3ogzYUd+3J+Cg76l75hb+AuHUVGfbm58Wn1jKAQVCRHlpYzCUcml6aFqg=
X-Received: by 2002:a05:6102:1352:b0:358:39dd:9034 with SMTP id
 j18-20020a056102135200b0035839dd9034mr216276vsl.41.1658445675685; Thu, 21 Jul
 2022 16:21:15 -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: <202207212252.26LMqWmr058437@lapr.no.berklix.net>
In-Reply-To: <202207212252.26LMqWmr058437@lapr.no.berklix.net>
From: Warner Losh 
Date: Thu, 21 Jul 2022 17:21:03 -0600
Message-ID: 
Subject: Re: where are the git to svn export script(s) please ?
To: "Julian H. Stacey" 
Cc: FreeBSD Current , ctm-users@freebsd.org, 
	Andre Albsmeier 
Content-Type: multipart/alternative; boundary="00000000000060fd5605e458f96e"
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4LppV44dtLz42Rc
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-ThisMailContainsUnwantedMimeParts: N

--00000000000060fd5605e458f96e
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 21, 2022, 4:56 PM Julian H. Stacey  wrote:

> Hi current@freebsd.org
> cc ctm-users@freebsd.org
>
> Has git to svn exporter stopped for src-12 ?
>         https://svnweb.freebsd.org/base/stable/12/
> Closure of ports from svn was mentioned long ago for ports@ at:
>         https://www.freebsd.org/developers/cvs/
> But no mention of src-12, src-cur & svn tree itself.
>
> Reason for asking:
> The CTM (src[*], ports & svn patches for freebsd.org sent by mail)
> generator
> runs on host http://ctm.berklix.org, using a lot of inherited opaque
> scripts that use svn.
>
> Rather than lose more time trying to understand those scripts &
> convert them to call git, it might be quicker for me to copy the
> git to svn export script(s) & run export from git to svn on host
> ctm.berklix.org ?
>
> Where are the git to svn export scripts & crontab sample invocations
> please ?
>

I plan to fix it when I get back from vacation. I'll get you a copy when u
return.

Warner

Cheers,
> --
> Julian Stacey  http://berklix.com/jhs/ http://stolenVotes.uk
> Arm Ukraine, Zap killer Putin, grain & fuel loss hits poorest.
>
>

--00000000000060fd5605e458f96e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Jul 21, 2022, 4:56 PM Julian H. Stacey <jhs@berklix.com> wrote:
Hi current@freebsd.org

cc ctm-users@freebsd.org



Has git to svn exporter stopped for src-12 ?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://svnweb.free=
bsd.org/base/stable/12/

Closure of ports from svn was mentioned long ago for ports@ at:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.freebsd.or=
g/developers/cvs/

But no mention of src-12, src-cur & svn tree itself.



Reason for asking:

The CTM (src[*], ports & svn patches for freebsd.org sent by ma=
il) generator

runs on host http://ctm.berklix.org, using a lot of inherited o=
paque

scripts that use svn. 



Rather than lose more time trying to understand those scripts &

convert them to call git, it might be quicker for me to copy the

git to svn export script(s) & run export from git to svn on host

ctm.berklix.org ?



Where are the git to svn export scripts & crontab sample invocations pl=
ease ?

I plan to fix it when I get back from vacation. I'll get you a co=
py when u return.

Warner=



Cheers,

-- 

Julian Stacey=C2=A0 http://berklix.com/jhs/ http://stol=
enVotes.uk

Arm Ukraine, Zap killer Putin, grain & fuel loss hits poorest.






--00000000000060fd5605e458f96e--

From nobody Thu Jul 21 23:38:33 2022
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 4LppyQ2hm6z4Wb7t;
	Thu, 21 Jul 2022 23:42:22 +0000 (UTC)
	(envelope-from jhs@berklix.com)
Received: from land.berklix.org (land.berklix.org [144.76.10.75])
	(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 "land.berklix.org", Issuer "land.berklix.org" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LppyP4Clpz44KG;
	Thu, 21 Jul 2022 23:42:21 +0000 (UTC)
	(envelope-from jhs@berklix.com)
Received: from lapr.no.berklix.net (p508db428.dip0.t-ipconnect.de [80.141.180.40])
	(authenticated bits=128)
	by land.berklix.org (8.16.1/8.16.1) with ESMTPSA id 26LNgJP5085614
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL);
	Thu, 21 Jul 2022 23:42:19 GMT
	(envelope-from jhs@berklix.com)
Received: from lapr.no.berklix.net (localhost [127.0.0.1])
	by lapr.no.berklix.net (8.16.1/8.16.1) with ESMTPS id 26LNcXBi059583
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 21 Jul 2022 23:38:33 GMT
	(envelope-from jhs@lapr.no.berklix.net)
Received: (from jhs@localhost)
	by lapr.no.berklix.net (8.16.1/8.16.1/Submit) id 26LNcXC6059582;
	Fri, 22 Jul 2022 01:38:33 +0200 (CEST)
	(envelope-from jhs)
Message-Id: <202207212338.26LNcXC6059582@lapr.no.berklix.net>
To: Warner Losh 
cc: FreeBSD Current , ctm-users@freebsd.org,
        Andre Albsmeier 
Subject: Re: where are the git to svn export script(s) please ?
From: "Julian H. Stacey" 
Organization: http://berklix.com/jhs/
User-agent: EXMH on FreeBSD http://berklix.com/free/
X-From: http://www.berklix.org/~jhs/
In-reply-to: Your message "Thu, 21 Jul 2022 17:21:03 -0600."
		
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <59580.1658446713.1@lapr.no.berklix.net>
Date: Fri, 22 Jul 2022 01:38:33 +0200
X-Rspamd-Queue-Id: 4LppyP4Clpz44KG
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com
X-Spamd-Result: default: False [-1.10 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[current@freebsd.org,ctm-users@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_COUNT_THREE(0.00)[4];
	HAS_ORG_HEADER(0.00)[];
	ARC_NA(0.00)[];
	FREEFALL_USER(0.00)[jhs];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[berklix.com];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Warner Losh wrote:
> --00000000000060fd5605e458f96e
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, Jul 21, 2022, 4:56 PM Julian H. Stacey  wrote:
>
> > Hi current@freebsd.org
> > cc ctm-users@freebsd.org
> >
> > Has git to svn exporter stopped for src-12 ?
> >         https://svnweb.freebsd.org/base/stable/12/
> > Closure of ports from svn was mentioned long ago for ports@ at:
> >         https://www.freebsd.org/developers/cvs/
> > But no mention of src-12, src-cur & svn tree itself.
> >
> > Reason for asking:
> > The CTM (src[*], ports & svn patches for freebsd.org sent by mail)
> > generator
> > runs on host http://ctm.berklix.org, using a lot of inherited opaque
> > scripts that use svn.
> >
> > Rather than lose more time trying to understand those scripts &
> > convert them to call git, it might be quicker for me to copy the
> > git to svn export script(s) & run export from git to svn on host
> > ctm.berklix.org ?
> >
> > Where are the git to svn export scripts & crontab sample invocations
> > please ?
> >
>
> I plan to fix it when I get back from vacation. I'll get you a copy when u
> return.
>
> Warner

Thanks Warner.

Cheers,
-- 
Julian Stacey  http://berklix.com/jhs/ http://stolenVotes.uk
Arm Ukraine, Zap killer Putin, grain & fuel loss hits poorest.

From nobody Fri Jul 22 15:27:43 2022
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 4LqCxS32KHz4XSCk
	for ; Fri, 22 Jul 2022 15:27:56 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2075.outbound.protection.outlook.com [40.92.96.75])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LqCxQ6Bpmz3QFk
	for ; Fri, 22 Jul 2022 15:27:54 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ABkS3TiYWbFqZX8MHD6AVxchLDAojYZ6u/bDbn7deq96r/kqQWdUksFPegPC5bI/1j5WN8ViqwJGCUeqfFCmnlPWezRr0ONOtsWJlZexj5F9/llv90Yrj1Wt147VkBWRim8ls+sW+G6+DhOIeE/LCgUyNv68FlZOGvi+8oGiHB1/SPdjikrZ+laL+JvNuZnis8TsH7ljlan8Dx1GSmB5R1FEltm/TG8GD9fkECLCKRMBTgxqQB/JFOTBUnXRDzkHQwsJbLoPEktK03mRlv4XrjkG/F/MNdST2Rpu/i/4xHKr4ORLQGnKfssa8WGW7ISypCkle6IoKVXdpR4Xw70/Dg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=x+YLeRzGK8sBiTBM1EsaRmPLD0gIe+kQntEZBA/ZEeY=;
 b=j9+/4p2A+t2unoBMm6G7ixWNolRPdiT/SwFT5Uw1LXPG3QvpLA090pHf32XWEtdJrgHedq9g+HlAH2+nVG0FIJ1tIffb190wfprWSwUhFe3nOo40Kd1Chn6XZozaMzR1/cGkjcKuC5v44o+TMddTCYvmcUYKXtQGG1o4HHfNC14Qdh4eisHGEu5eVgqHT1aqcG4AxvVC2ggCX73VsM6HFDSfvl0Yb9n6djRZ+P6Vr2PazQVKoYx7IN1mzEVxty1J9dcu8uCoeC2t7ZFwlmoj+4bT1lmrxpN0U0xDAaQac2bXX8cDFcibXOTStkJYjRgFc6v+6a863EmRBCL8m3QFtw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=x+YLeRzGK8sBiTBM1EsaRmPLD0gIe+kQntEZBA/ZEeY=;
 b=KOuC0yTDN82iRcqvrgXNUiPQTf1o64z5S0ysCjRe7nrYo9w+wrXG9ckWxARJN4izKsnX+dHg4BUsI8tdlyeST001I2L1fKurKOGaM8FGEe0McNaU1Z1KEZ3OnXQYbvRVP5C8UIdiqOkF6e9XUHe5fMI/3LkIdkokYKAsGIlrL1JJCFly398hFQaB2PZT+zMLyfKoRRotCnh3O2npg9tMUekzOaQH2WPP/WzqxnXQyX/v0o2tRsjiJMteUebuI3KWS680Ya24Ht1OQS5F7TZd5FL7ERSmtTvxDZMCBqAaobIrN5dfL1WURX8VMUBgN8VrLDzeRXWPaGySWkh52YJuzA==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CPZP284MB0198.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:34::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.19; Fri, 22 Jul
 2022 15:27:51 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%7]) with mapi id 15.20.5458.019; Fri, 22 Jul 2022
 15:27:51 +0000
Date: Fri, 22 Jul 2022 12:27:43 -0300 (-03)
From: Ivan Quitschal 
To: freebsd-current@freebsd.org
Subject: from X to terminal needs an fflush
Message-ID:
 
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-TMN: [UBo9zjNaEuVeLLu0GuGzQonHPtYPDoOn]
X-ClientProxiedBy: CP3P284CA0091.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:6f::6) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 005e5fff-33aa-4177-4603-08da6bf6bce0
X-MS-TrafficTypeDiagnostic: CPZP284MB0198:EE_
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	z6RkPci6RpbtoEvU92klfJ00L5swb+p3XcSvMMNtuF94BqZnJocue3v5ytnIe0GiLfFucLd1f1AoUa1Islkc+jUWmq4uDEttP1C7h0xWFNuuEQArrVMEUByAMqPOiyVODozKX7ZAdHa2rJ6DuapDLw9ALVmzSIyEKlHrloODlVSLNF8wBdhMNu3R1cVb+a+X4BsbU++KZuhO0v3bRUfbbvIaxgXYVPu2ZANu3Nzl5MPLjoF/IHhjE6E75HmAWGUdbQvjBv9TZx4rGS86waBfCxIt1B2zrgIIIgYxE6vZu9kjmgUckqw3oG+O8bWO1olIo3plfjLhouKPAmtxojwO/AB1UBHDjZmAD3cNxWv+RlORyuAdtVmddqcVUZq+ol0Wzi82F3g02QTCv+yjYPsgSd/3m0mRdWs9n4Ars9EovVnc6Vp5MVcUXsoHa+E2feboukwu4tcRPjgxGYh8E0c8DF90foy8PJLMAcHiibEYsnYL8HlVou4MAZzCXfakODc5smPYvwhReaEv3p1+u6FW3OKDkZbiVRk0Cw/I1hOdpDEfW0JwV0FOlSqMNM18Xqds6/TEJZ6AK+Wa+S8G9drIDpAJAuwLUbGoeu7OdH2IhFJxSU/GKbxlpq44J5L4DmIvTm/1zgerQDDnwXj75ukF7A==
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?2d/VHk0WQGvB39kZBspzZCTeR5FkOsRH7KRrrb/4M73LNKDfbDmcOZWWv1Ln?=
 =?us-ascii?Q?NY/3KUkVkf/Bk1syt4aR0cOhTanMLVB4K+xYfGJG/wagbDOmAk7wTjqXjb0o?=
 =?us-ascii?Q?WC7qzy+fg2+QS2NJFCf3/iRDYoJYeGyd+VZFLjhWwBZmRLhRK01eIBsDD1J2?=
 =?us-ascii?Q?+3900fcbGOr7vM9G/XRCxSla6aR4nUGfG3giK61TdToxxeBMTZrGw5wFOQq8?=
 =?us-ascii?Q?HT29bgvZwoIKgU7oCrOptU7WGdmn/ViQkFUxKyv4tey0oupcZRzYSVwcN3LM?=
 =?us-ascii?Q?tXYlf0JWbR5t2FyVUh3bocvm9/dKmY5R0PkzzZuzK50CVDH+WGzev71to2Tq?=
 =?us-ascii?Q?Nwbbs0oNXiJG0+5oX5wD5Jt+Ns07exRW7m/1V3FVIK28qfgiHVTIxfTryuZp?=
 =?us-ascii?Q?lpncAhF+x7GUdjV87GfHxJ9Kso6u5iMiUP8ME2UWe2vzjW10RwwwU6r31i1t?=
 =?us-ascii?Q?feia8CrKXIu26P8jBVjTjLYAXZg9XAxICvM4E5oDYFJww/LNtEIeiYZFLSHQ?=
 =?us-ascii?Q?jPs0Lc3ojUH+4aYJg+czWMuyQCFs1B5JdkLhRgODwYdQXH62mz2ohEEg8Jti?=
 =?us-ascii?Q?YcDTb/kBObn+oxqfAbXz5gwVpxtWHqCL10AXocId4bQud0b4RqL3k0IDDgEa?=
 =?us-ascii?Q?hs3nwhe/H005TrgZX+7NLs7E31BIFO0jmx+pR6gaTA6RlfTKtkqY/O4DZQOC?=
 =?us-ascii?Q?01kPdtE+Q6iAKC/XIB0PVB/PHHkz/bc2/sKmhon7ZZdx2TN1kQuSFx8oBPmx?=
 =?us-ascii?Q?IzHoov5ANjEbE+LR103T7oWaF0EaX9UGakRz4I+cd7h6iB8N7DkvHEYiDbFi?=
 =?us-ascii?Q?Uup8xfsBQYSFWbUBbuEljwEZ7uzNeAMm/m23uAbOFegThbBqXYp04PfSQq3E?=
 =?us-ascii?Q?2raZFqEGZQVkNE4uGnlT7IWFzRwgDSAZJx10Y92wYaLuZu3s0hcxK974Cs6r?=
 =?us-ascii?Q?UmSd7/lc+4ziB/a8V0VoCpyJnbQzEPP2MHaL41J2ZCrx4/58iFi2kPix5oXV?=
 =?us-ascii?Q?PEed8dycCIzc4rie7Ls4Tt054sIRCVxekXPmiEst4oukJu1q0JJTcGgLJ3gF?=
 =?us-ascii?Q?rivVxWpA/J/GAbmpumuuoUQWmm7FT7Q7uxq9onzBFQ5pviyzSvPZk4/CtKSg?=
 =?us-ascii?Q?80wAPCb/MhImCDOnLdzvZ6y04oGC+TVlHXz3vxAw4BaqgIip/xnXYtSR6ylt?=
 =?us-ascii?Q?dfbMxNhLA8mVs4TSAGtociWt1Ux2qh8ItJbP5VddYfza9QXB/pPfxBUM3r6V?=
 =?us-ascii?Q?5b+xprpPra6kOiqMHcZewtDHMxX+AS/JImydQcKstQ=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 005e5fff-33aa-4177-4603-08da6bf6bce0
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2022 15:27:51.2864
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPZP284MB0198
X-Rspamd-Queue-Id: 4LqCxQ6Bpmz3QFk
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=KOuC0yTD;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.75 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.38 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-0.99)[-0.993];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	NEURAL_HAM_MEDIUM(-0.41)[-0.406];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	FREEMAIL_FROM(0.00)[hotmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.96.75:from];
	DKIM_TRACE(0.00)[hotmail.com:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N


hi all

Ive been trying to solve a problem which is happening to me but so far no 
success.
problem is this:

sometimes happens, sometimes doesnt, but once im on X and do a "F2", "F3" 
whatever in order to get back to terminal, it *does* get back to terminal but 
the screen still shows like i was on X, therefore i have to do a F* twice in 
order to see the console , like an fflush was missing somewhere.

im using the drm-devel-kmod git for i915kms.ko btw

any ideas what could it be?

thank you guys

--tzk


From nobody Sat Jul 23 03:52:23 2022
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 4LqXSV5Z8vz4WSss
	for ; Sat, 23 Jul 2022 03:52:26 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LqXST4yjrz3FRT
	for ; Sat, 23 Jul 2022 03:52:25 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183])
	by cmsmtp with ESMTP
	id Etx5oLk7cSp39F6BlogZFm; Sat, 23 Jul 2022 03:52:25 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id F6Bjot5csvn7BF6BkoWjC0; Sat, 23 Jul 2022 03:52:25 +0000
X-Authority-Analysis: v=2.4 cv=a/cjSGeF c=1 sm=1 tr=0 ts=62db7079
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=RgO8CyIxsXoA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8
 a=EkcXrb_YAAAA:8 a=nLR6W5veI4Z9Moj_SpkA:9 a=CjuIK1q_8ugA:10
 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id 6D871731
	for ; Fri, 22 Jul 2022 20:52:23 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id 57CDBD7; Fri, 22 Jul 2022 20:52:23 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: freebsd-current@freebsd.org
Subject: DTrace Error
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
Date: Fri, 22 Jul 2022 20:52:23 -0700
Message-Id: <20220723035223.57CDBD7@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfGsaS7bFxSl7Sq6z4gh86lslbHAiG9IafH4cPoUjLLB2ENgUZgsPctBRr9BCdWZp4e+PUidn3S+1FmQJxeSGP+0Qpq63n+oTZ347i+B0So+lie4mmjiu
 /Tvu2vGyr1x7AOK3KX2S/pB/PVURdAMxZvN5JVYI3wlT6HfjiVQlmbR9KxOEuX1nGC2fmmjkOjt2MJqRwZJUbCogN7DqI/kKw8E=
X-Rspamd-Queue-Id: 4LqXST4yjrz3FRT
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ARC_NA(0.00)[];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	RCPT_COUNT_ONE(0.00)[1];
	REPLYTO_EQ_FROM(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I'm not sure if this is because my obj tree needs a fresh rebuild and 
reinstall or if this is a legitimate problem. Regardless of the dtrace 
command entered, whether it be a fbt or sdt, the following error occurs:

slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { printf("entering 
ieee80211_vap_setup\n"); }'
dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry { 
printf("entering ieee80211_vap_setup\n"); }: "/usr/lib/dtrace/psinfo.d", 
line 1: failed to copy type of 'pr_gid': Conflicting type is already defined
slippy# 

Old DTrace scripts I've used months or even years ago also fail with the 
same error. It's not this one probe. All probes result in the pr_gid error.

I'm currently rebuilding my "prod" tree from scratch with the hope that 
it's simply something out of sync. But, should it not be, has anyone else 
encountered this lately?


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e**(i*pi)+1=0



From nobody Sat Jul 23 14:14:44 2022
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 4LqpGb4twPz4Wr1r
	for ; Sat, 23 Jul 2022 14:14:47 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LqpGb0T1Rz49CQ
	for ; Sat, 23 Jul 2022 14:14:47 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142])
	by cmsmtp with ESMTP
	id FFGEou95qS8WrFFu2offzX; Sat, 23 Jul 2022 14:14:46 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id FFu1of82uuJwwFFu1oGvFJ; Sat, 23 Jul 2022 14:14:46 +0000
X-Authority-Analysis: v=2.4 cv=F+BEy4tN c=1 sm=1 tr=0 ts=62dc0256
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=RgO8CyIxsXoA:10 a=VxmjJ2MpAAAA:8 a=YxBL1-UpAAAA:8
 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=BxFSrs4d4KeuQtnTsM8A:9 a=CjuIK1q_8ugA:10
 a=7gXAzLPJhVmCkEl4_tsf:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22
 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id C421E65;
	Sat, 23 Jul 2022 07:14:44 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id 85620189; Sat, 23 Jul 2022 07:14:44 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Cy Schubert 
cc: freebsd-current@freebsd.org
Subject: Re: DTrace Error
In-reply-to: <20220723035223.57CDBD7@slippy.cwsent.com>
References: <20220723035223.57CDBD7@slippy.cwsent.com>
Comments: In-reply-to Cy Schubert 
   message dated "Fri, 22 Jul 2022 20:52:23 -0700."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 23 Jul 2022 07:14:44 -0700
Message-Id: <20220723141444.85620189@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfMYepcBKU9JLiJUpTBwRsQ6m3nWXSf9uiADMBEV5CyZCslaf03g4W19bigfCzV2cUpQjtEGbY1JT0FkvN+alL446vWJHbn7V3+l9LWMq+dZ3AGOJWkf7
 J1o9XbVTDaDnWjVBxL9FeZv0ioyKH+dl7u0oEvM2WJwCkoQEsdf0QqkJK/67U7qfj5ZLxMHC7s1PhLECHvlLjtuey6r9glBeMjg=
X-Rspamd-Queue-Id: 4LqpGb0T1Rz49CQ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	REPLYTO_EQ_FROM(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message <20220723035223.57CDBD7@slippy.cwsent.com>, Cy Schubert writes:
> I'm not sure if this is because my obj tree needs a fresh rebuild and 
> reinstall or if this is a legitimate problem. Regardless of the dtrace 
> command entered, whether it be a fbt or sdt, the following error occurs:
>
> slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { printf("entering 
> ieee80211_vap_setup\n"); }'
> dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry { 
> printf("entering ieee80211_vap_setup\n"); }: "/usr/lib/dtrace/psinfo.d", 
> line 1: failed to copy type of 'pr_gid': Conflicting type is already defined
> slippy# 
>
> Old DTrace scripts I've used months or even years ago also fail with the 
> same error. It's not this one probe. All probes result in the pr_gid error.
>
> I'm currently rebuilding my "prod" tree from scratch with the hope that 
> it's simply something out of sync. But, should it not be, has anyone else 
> encountered this lately?

A full clean rebuild and installworld/kernel did not change the result. 
This is a new problem.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e**(i*pi)+1=0



From nobody Sat Jul 23 18:39:42 2022
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 4Lqw8N0xlXz4XQLk
	for ; Sat, 23 Jul 2022 18:39:48 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lqw8M1x1sz3K8p
	for ; Sat, 23 Jul 2022 18:39:47 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-io1-xd2f.google.com with SMTP id e69so5831137iof.5
        for ; Sat, 23 Jul 2022 11:39:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=ZTp2XqxJU76BPYQtCWOhn3YX5xMHqSG3tzXUlOalOQ4=;
        b=puvWu85Kz6gaB+3wB+3Yk1QlvW9LxiE+0PUEXiBUsn1GiMAznx89e4RoZzoyCS+Ti/
         IxDfQTc7yVARENpmC7fOLUDiqWsi0FHtXpZhVnK7239nVv9+fXNDIar/5RQ6FDhFFNqL
         ggqL2Tl+0JPGLv7WF39fTtECL+BHDckQtTD8sYVGzjLE+bSqjyQmhok1TJYj0JglVRrA
         9l1z24h4JpCcKf5cZzY9XWXNNiXukjXxYW8nsNWXcBqemw2EBV4z5Ddj9J2C41nlABlt
         4iJ+X4wot6I9Srlgr5eWkUnjaFbqXQE5rQsDFnVdu3QLlbm8AaCvGEt2/MfgGY8OZvpC
         jsKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition:in-reply-to;
        bh=ZTp2XqxJU76BPYQtCWOhn3YX5xMHqSG3tzXUlOalOQ4=;
        b=UleGHrZOo5rCBu0QJhJfwY3T06EDktjAKy5hUilMzQPfwuPMxFVr0OYNwRtRCsg1/B
         JRoKyj1EIv63bL1Y0tx1y0qZr4+pzOxcFUwKwHTgl71M7yq4k/MHDatfsjYsiKFrZjKO
         kciISkYNy8HwH2tDd+N8LgYz35nYFqKDJthQoYZyK4KiVx14QT04Imxd9nbgF+GIcdkA
         s3Qc24uZvDUIsCGXi4fQ/p+BWl7MzYmA6Yl19B1eeUu/ddrffwdGfVLJ5erq5Fd0OUoM
         pC/bv9NfP6nk1b7sIcUpZ8vxr6qJGmiA5w+7Mkgfr3iXTk7g4xwMLyIQHjaVkehZ8JHJ
         6o/A==
X-Gm-Message-State: AJIora9bYiH+NAxVAWdoD04DwPXybdTlIK5ZI6tkSpsXwCk7Rz9X04eb
	SQ4CBmYXxzfvIyX2uSpdH9W74TbEe8I=
X-Google-Smtp-Source: AGRyM1u5aXOm1ccG9PaA2nOBrtJvh7ID0PZam8rhk+BBq9q78gk7mVytDpQyC7ySRa/ywH6HuoGlQQ==
X-Received: by 2002:a05:6638:13d0:b0:33f:8aa8:194b with SMTP id i16-20020a05663813d000b0033f8aa8194bmr2249057jaj.268.1658601586316;
        Sat, 23 Jul 2022 11:39:46 -0700 (PDT)
Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237])
        by smtp.gmail.com with ESMTPSA id 141-20020a6b1493000000b0067bef5b497asm3842456iou.33.2022.07.23.11.39.44
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 23 Jul 2022 11:39:45 -0700 (PDT)
Date: Sat, 23 Jul 2022 14:39:42 -0400
From: Mark Johnston 
To: Cy Schubert 
Cc: freebsd-current@freebsd.org
Subject: Re: DTrace Error
Message-ID: 
References: <20220723035223.57CDBD7@slippy.cwsent.com>
 <20220723141444.85620189@slippy.cwsent.com>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220723141444.85620189@slippy.cwsent.com>
X-Rspamd-Queue-Id: 4Lqw8M1x1sz3K8p
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=puvWu85K;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d2f as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-2.69 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.99)[-0.991];
	MID_RHS_NOT_FQDN(0.50)[];
	FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2f:from];
	DMARC_NA(0.00)[freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote:
> In message <20220723035223.57CDBD7@slippy.cwsent.com>, Cy Schubert writes:
> > I'm not sure if this is because my obj tree needs a fresh rebuild and 
> > reinstall or if this is a legitimate problem. Regardless of the dtrace 
> > command entered, whether it be a fbt or sdt, the following error occurs:
> >
> > slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { printf("entering 
> > ieee80211_vap_setup\n"); }'
> > dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry { 
> > printf("entering ieee80211_vap_setup\n"); }: "/usr/lib/dtrace/psinfo.d", 
> > line 1: failed to copy type of 'pr_gid': Conflicting type is already defined
> > slippy# 
> >
> > Old DTrace scripts I've used months or even years ago also fail with the 
> > same error. It's not this one probe. All probes result in the pr_gid error.
> >
> > I'm currently rebuilding my "prod" tree from scratch with the hope that 
> > it's simply something out of sync. But, should it not be, has anyone else 
> > encountered this lately?
> 
> A full clean rebuild and installworld/kernel did not change the result. 
> This is a new problem.

I don't see any such problem on a system built from commit 151abc80cde,
using GENERIC.  Are you using a custom kernel config?  Which kernel
modules do you have loaded?

It might be useful to see a ctfdump -S of your kernel, to confirm that
you're using CTFv3.

From nobody Sat Jul 23 18:55:33 2022
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 4LqwVd143Jz4XSTb
	for ; Sat, 23 Jul 2022 18:55:37 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LqwVc3dPvz3MF0;
	Sat, 23 Jul 2022 18:55:36 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227])
	by cmsmtp with ESMTP
	id FCUBoMXWbSp39FKHnohnCv; Sat, 23 Jul 2022 18:55:35 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id FKHmof69lGRNlFKHnoX96E; Sat, 23 Jul 2022 18:55:35 +0000
X-Authority-Analysis: v=2.4 cv=Sfrky9du c=1 sm=1 tr=0 ts=62dc4427
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=RgO8CyIxsXoA:10 a=VxmjJ2MpAAAA:8 a=YxBL1-UpAAAA:8
 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=HEZS_BTrTuiojYxi3B8A:9 a=CjuIK1q_8ugA:10
 a=7gXAzLPJhVmCkEl4_tsf:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22
 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id C1C185B4;
	Sat, 23 Jul 2022 11:55:33 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id 9EA7D11E; Sat, 23 Jul 2022 11:55:33 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Mark Johnston 
cc: Cy Schubert , freebsd-current@freebsd.org
Subject: Re: DTrace Error
In-reply-to: 
References: <20220723035223.57CDBD7@slippy.cwsent.com> 
 <20220723141444.85620189@slippy.cwsent.com> 
Comments: In-reply-to Mark Johnston 
   message dated "Sat, 23 Jul 2022 14:39:42 -0400."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 23 Jul 2022 11:55:33 -0700
Message-Id: <20220723185533.9EA7D11E@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfHGj21OnG4kgMYAUu6D0UQVKeUm0lcL178zu+T9W/T1CCoukGvCyLkPbZiL7tPr8PLm6fJY2cQBM+xhBygup5JR3VEHOZAhqbFErInEpdG3++aTD9cpc
 0jc5nU8IOXY1j4w7p7XTQpV5noov83G/IS3FSusauHeGwsbGouvurSxYW7O1jnzGM8YkEk9+OaabOKUvbsLsmgRSXnqDBHtgf9a7S4i6T1c21l56r/0Rt73y
 DCQIdkXnbcpDqWNXVkQH5g==
X-Rspamd-Queue-Id: 4LqwVc3dPvz3MF0
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from];
	MIME_GOOD(-0.10)[text/plain];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	REPLYTO_EQ_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message , Mark Johnston writes:
> On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote:
> > In message <20220723035223.57CDBD7@slippy.cwsent.com>, Cy Schubert writes:
> > > I'm not sure if this is because my obj tree needs a fresh rebuild and 
> > > reinstall or if this is a legitimate problem. Regardless of the dtrace 
> > > command entered, whether it be a fbt or sdt, the following error occurs:
> > >
> > > slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { printf("entering 
> > > ieee80211_vap_setup\n"); }'
> > > dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry { 
> > > printf("entering ieee80211_vap_setup\n"); }: "/usr/lib/dtrace/psinfo.d", 
> > > line 1: failed to copy type of 'pr_gid': Conflicting type is already defi
> ned
> > > slippy# 
> > >
> > > Old DTrace scripts I've used months or even years ago also fail with the 
> > > same error. It's not this one probe. All probes result in the pr_gid erro
> r.
> > >
> > > I'm currently rebuilding my "prod" tree from scratch with the hope that 
> > > it's simply something out of sync. But, should it not be, has anyone else
>  
> > > encountered this lately?
> > 
> > A full clean rebuild and installworld/kernel did not change the result. 
> > This is a new problem.
>
> I don't see any such problem on a system built from commit 151abc80cde,
> using GENERIC.  Are you using a custom kernel config?  Which kernel
> modules do you have loaded?

The kernel config is custom. Here is what is reported by the kernel through 
strings:

options	CONFIG_AUTOGENERATED
makeoptions	WITH_CTF=1
makeoptions	DEBUG=-g
options	BREAK_TO_DEBUGGER
options	SW_WATCHDOG
options	DIRECTIO
options	KDB_UNATTENDED
options	IICHID_SAMPLING
options	HID_DEBUG
options	EVDEV_SUPPORT
options	USB_DEBUG
options	ATH_ENABLE_11N
options	AH_AR5416_INTERRUPT_MITIGATION
options	IEEE80211_SUPPORT_MESH
options	IEEE80211_DEBUG
options	SC_PIXEL_MODE
options	PPS_SYNC
options	COMPAT_LINUXKPI
options	PCI_IOV
options	PCI_HP
options	IOMMU
options	EARLY_AP_STARTUP
options	SMP
options	NETGDB
options	NETDUMP
options	DEBUGNET
options	ZSTDIO
options	GZIO
options	EKCD
options	VERBOSE_SYSINIT=0
options	MALLOC_DEBUG_MAXZONES=8
options	QUEUE_MACRO_DEBUG_TRASH
options	DEADLKRES
options	GDB
options	FULL_BUF_TRACKING
options	DDB
options	BUF_TRACKING
options	KDB_TRACE
options	KDB
options	RCTL
options	RACCT_DEFAULT_TO_DISABLED
options	RACCT
options	INCLUDE_CONFIG_FILE
options	DDB_CTF
options	KDTRACE_HOOKS
options	KDTRACE_FRAME
options	MAC
options	CAPABILITIES
options	CAPABILITY_MODE
options	AUDIT
options	HWPMC_HOOKS
options	KBD_INSTALL_CDEV
options	PRINTF_BUFR_SIZE=128
options	_KPOSIX_PRIORITY_SCHEDULING
options	SYSVSEM
options	SYSVMSG
options	SYSVSHM
options	STACK
options	KTRACE
options	SCSI_DELAY=5000
options	COMPAT_FREEBSD13
options	COMPAT_FREEBSD12
options	COMPAT_FREEBSD11
options	COMPAT_FREEBSD10
options	COMPAT_FREEBSD9
options	COMPAT_FREEBSD7
options	COMPAT_FREEBSD6
options	COMPAT_FREEBSD5
options	COMPAT_FREEBSD4
options	COMPAT_FREEBSD32
options	EFIRT
options	GEOM_LABEL
options	GEOM_RAID
options	TMPFS
options	PSEUDOFS
options	PROCFS
options	CD9660
options	MSDOSFS
options	NFS_ROOT
options	NFSLOCKD
options	NFSD
options	NFSCL
options	MD_ROOT
options	QUOTA
options	UFS_GJOURNAL
options	UFS_DIRHASH
options	UFS_ACL
options	SOFTUPDATES
options	FFS
options	KERN_TLS
options	SCTP_SUPPORT
options	TCP_RFC7413
options	TCP_HHOOK
options	TCP_BLACKBOX
options	TCP_OFFLOAD
options	FIB_ALGO
options	ROUTE_MPATH
options	IPSEC_SUPPORT
options	INET6
options	INET
options	VIMAGE
options	PREEMPTION
options	NUMA
options	SCHED_ULE
options	NEW_PCIB
options	CC_NEWRENO
options	GEOM_PART_GPT
options	GEOM_PART_MBR
options	GEOM_PART_EBR
options	GEOM_PART_BSD
options	KDB_TRACE
device	isa
device	mem
device	io
device	uart_ns8250
device	acpi
device	pci
device	fdc
device	ahci
device	ata
device	siis
device	ahc
device	scbus
device	ch
device	da
device	sa
device	cd
device	pass
device	ses
device	atkbdc
device	atkbd
device	psm
device	vga
device	splash
device	sc
device	vt
device	vt_vga
device	vt_efifb
device	vt_vbefb
device	uart
device	puc
device	iflib
device	igc
device	axp
device	miibus
device	crypto
device	aesni
device	loop
device	padlock_rng
device	rdrand_rng
device	ether
device	md
device	firmware
device	xz
device	bpf
device	uhci
device	ohci
device	ehci
device	xhci
device	usb
device	ukbd
device	umass
device	virtio
device	virtio_pci
device	vtnet
device	virtio_blk
device	virtio_scsi
device	virtio_balloon
device	kvm_clock
device	xentimer
device	evdev
device	uinput
device	hid

Kernel modules are:

slippy# kldstat
Id Refs Address                Size Name
 1  185 0xffffffff80200000  10290a8 kernel
 2    1 0xffffffff8122a000     36c0 coretemp.ko
 3    1 0xffffffff8122e000    12e88 cpufreq.ko
 4    1 0xffffffff81241000     6320 ichsmb.ko
 5    3 0xffffffff81248000     3c60 smbus.ko
 6    7 0xffffffff8124d000    a35e0 wlan.ko
 7    1 0xffffffff812f1000     e6f8 if_tuntap.ko
 8    1 0xffffffff81300000    a8968 iwn6000g2bfw.ko
 9    1 0xffffffff813a9000     34a0 dtraceall.ko
10    2 0xffffffff813ad000     4190 profile.ko
11   10 0xffffffff813b2000     aab0 opensolaris.ko
12   10 0xffffffff813bd000    56800 dtrace.ko
13    2 0xffffffff81414000    190a0 systrace_freebsd32.ko
14    2 0xffffffff8142e000    191c0 systrace.ko
15    2 0xffffffff81448000     3e48 sdt.ko
16    2 0xffffffff8144c000    5fcf8 fasttrap.ko
17    2 0xffffffff814ac000     5da8 fbt.ko
18    2 0xffffffff814b2000     6298 dtnfscl.ko
19    2 0xffffffff814b9000     3500 dtmalloc.ko
20    1 0xffffffff814bd000    1fe30 if_iwn.ko
21    1 0xffffffff814dd000     3da0 smb.ko
22    1 0xffffffff814e1000    20ce8 if_bge.ko
23    1 0xffffffff81502000     3418 wlan_wep.ko
24    1 0xffffffff81506000   5f0588 zfs.ko
25    2 0xffffffff81af7000     4268 iic.ko
26    1 0xffffffff81afc000     7750 sem.ko
27    1 0xffffffff81b04000     37b0 wlan_amrr.ko
28    1 0xffffffff81b08000    fb1f0 ipl.ko
29    1 0xffffffff81c04000     66a0 sdhci_pci.ko
30    3 0xffffffff81c0b000     f920 mmc.ko
31    2 0xffffffff81c1b000     fa50 sdhci.ko
32    1 0xffffffff81c2b000    164b8 if_lagg.ko
33    2 0xffffffff81c42000     3580 if_infiniband.ko
34    1 0xffffffff81c46000     7e08 ums.ko
35    1 0xffffffff81c4e000     9bb0 mmcsd.ko
36    2 0xffffffff81c58000     3520 geom_flashmap.ko
38    1 0xffffffff81c70000     9ec0 kbdmux.ko
39    1 0xffffffff81c7a000     4948 wlan_tkip.ko
40    1 0xffffffff81c7f000     86f8 wlan_ccmp.ko
41    1 0xffffffff81c88000     3440 wlan_rssadapt.ko
42    1 0xffffffff81c8c000    4a260 snd_hda.ko
43    2 0xffffffff81cd7000    7e360 sound.ko
44    1 0xffffffff82318000     9ed8 tmpfs.ko
45    1 0xffffffff82322000     3540 fdescfs.ko
46    1 0xffffffff82326000     4710 nullfs.ko
47    1 0xffffffff8232b000     3370 acpi_wmi.ko
48    1 0xffffffff8232f000     2220 cpuctl.ko
49    1 0xffffffff82332000     7638 if_bridge.ko
50    1 0xffffffff8233a000     60d8 bridgestp.ko
51    1 0xffffffff82341000     3340 uhid.ko
52    1 0xffffffff82345000     3380 usbhid.ko
53    1 0xffffffff82349000     31f0 hidbus.ko
54    1 0xffffffff8234d000     3320 wmt.ko
55    1 0xffffffff82351000     9810 unionfs.ko
56    1 0xffffffff8235b000     2a20 mac_ntpd.ko
57    1 0xffffffff8235e000     20f0 blank_saver.ko
58    1 0xffffffff82361000   183870 i915kms.ko
59    1 0xffffffff824e5000    73bd8 drm.ko
60    2 0xffffffff82559000     30fc linuxkpi_gplv2.ko
61    3 0xffffffff8255d000     72e0 dmabuf.ko
62    1 0xffffffff82565000     c730 agp.ko
slippy# 

>
> It might be useful to see a ctfdump -S of your kernel, to confirm that
> you're using CTFv3.


I'm not sure what "unexpected kind" means.

slippy# ctfdump -S /boot/kernel/kernel 
  [1] unexpected kind -- 1

- CTF Statistics -----------------------------------------------------------
--

  total number of data objects        = 23503

  total number of functions           = 1
  total number of function arguments  = 2
  maximum argument list length        = 2
  average argument list length        = 2.00

  total number of types               = 17657
  total number of integers            = 54
  total number of floats              = 0
  total number of pointers            = 5156
  total number of arrays              = 1394
  total number of func types          = 1477
  total number of structs             = 5486
  total number of unions              = 287
  total number of enums               = 401
  total number of forward tags        = 37
  total number of typedefs            = 2745
  total number of volatile types      = 35
  total number of const types         = 437
  total number of restrict types      = 6
  total number of unknowns (holes)    = 142

  total number of struct members      = 35339
  maximum number of struct members    = 251
  total size of all structs           = 5057035
  maximum size of a struct            = 1593440
  average number of struct members    = 6.44
  average size of a struct            = 921.81

  total number of union members       = 1002
  maximum number of union members     = 37
  total size of all unions            = 30852
  maximum size of a union             = 4101
  average number of union members     = 3.49
  average size of a union             = 107.50

  total number of enum members        = 4088
  maximum number of enum members      = 1273
  average number of enum members      = 10.19

  total number of unique strings      = 32427
  bytes of string data                = 434638
  maximum string length               = 69
  average string length               = 13.40

slippy# 


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e**(i*pi)+1=0



From nobody Sun Jul 24 03:08:57 2022
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 4Lr7Rx0vtJz4XHnv
	for ; Sun, 24 Jul 2022 03:09:01 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lr7Rw0tMkz42Rv;
	Sun, 24 Jul 2022 03:09:00 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142])
	by cmsmtp with ESMTP
	id FDSkou4HmS8WrFRzHoh6cn; Sun, 24 Jul 2022 03:08:59 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id FRzFoi7x2uJwwFRzGoHvxo; Sun, 24 Jul 2022 03:08:59 +0000
X-Authority-Analysis: v=2.4 cv=F+BEy4tN c=1 sm=1 tr=0 ts=62dcb7cb
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=RgO8CyIxsXoA:10 a=VxmjJ2MpAAAA:8 a=YxBL1-UpAAAA:8
 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=AChwrQsQVhJ-UjDOGQEA:9 a=CjuIK1q_8ugA:10
 a=7gXAzLPJhVmCkEl4_tsf:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22
 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id B7520DCC;
	Sat, 23 Jul 2022 20:08:57 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id B57FAFC; Sat, 23 Jul 2022 20:08:57 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Cy Schubert 
cc: Mark Johnston , freebsd-current@freebsd.org,
    chuck@freebsd.org
Subject: Re: DTrace Error
In-reply-to: <20220723185533.9EA7D11E@slippy.cwsent.com>
References: <20220723035223.57CDBD7@slippy.cwsent.com> 
 <20220723141444.85620189@slippy.cwsent.com>  
 <20220723185533.9EA7D11E@slippy.cwsent.com>
Comments: In-reply-to Cy Schubert 
   message dated "Sat, 23 Jul 2022 11:55:33 -0700."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 23 Jul 2022 20:08:57 -0700
Message-Id: <20220724030857.B57FAFC@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfEDBCnx9/DCuPlRfoOulv7j3dwghrwVoQyTHBiY2cZ42dOnxVMHao+rWfdhBWIGzQuoSI01yt3t3KNmgYqXQLSA/zs4JxtggMea8524QOJNcdr5efu3Y
 rMln2mMZeEa5UYZefgIC8RDAtvjqtsxgd6tzl9P9RO2yCAYbxK/VsxDdFkxdguggP3ROCTGU1i9vPj78qqXd4lMAUveHXzZudCdDL9bEe3XVHYRCxjjKBoxW
 7AiAWjYHQ99jP5bU5vuDTiEeOk7LJzMwV+lZq91N9r8=
X-Rspamd-Queue-Id: 4Lr7Rw0tMkz42Rv
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from];
	MIME_GOOD(-0.10)[text/plain];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	REPLYTO_EQ_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message <20220723185533.9EA7D11E@slippy.cwsent.com>, Cy Schubert writes:
> In message , Mark Johnston writes:
> > On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote:
> > > In message <20220723035223.57CDBD7@slippy.cwsent.com>, Cy Schubert writes
> :
> > > > I'm not sure if this is because my obj tree needs a fresh rebuild and 
> > > > reinstall or if this is a legitimate problem. Regardless of the dtrace 
> > > > command entered, whether it be a fbt or sdt, the following error occurs
> :
> > > >
> > > > slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { printf("entering 
> > > > ieee80211_vap_setup\n"); }'
> > > > dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry { 
> > > > printf("entering ieee80211_vap_setup\n"); }: "/usr/lib/dtrace/psinfo.d"
> , 
> > > > line 1: failed to copy type of 'pr_gid': Conflicting type is already de
> fi
> > ned
> > > > slippy# 
> > > >
> > > > Old DTrace scripts I've used months or even years ago also fail with th
> e 
> > > > same error. It's not this one probe. All probes result in the pr_gid er
> ro
> > r.
> > > >
> > > > I'm currently rebuilding my "prod" tree from scratch with the hope that
>  
> > > > it's simply something out of sync. But, should it not be, has anyone el
> se
> >  
> > > > encountered this lately?
> > > 
> > > A full clean rebuild and installworld/kernel did not change the result. 
> > > This is a new problem.
> >
> > I don't see any such problem on a system built from commit 151abc80cde,
> > using GENERIC.  Are you using a custom kernel config?  Which kernel
> > modules do you have loaded?
>
> [...]

chuck@ emailed me privately suggesting a roll back to cb2ae6163174. The 
problem is fixed. I'm creating a special branch that reverts only the llvm 
commits since then.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e**(i*pi)+1=0




From nobody Sun Jul 24 17:07:19 2022
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 4LrV3G6NJxz4X3dM
	for ; Sun, 24 Jul 2022 17:07:22 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LrV3F73srz3HH7;
	Sun, 24 Jul 2022 17:07:21 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183])
	by cmsmtp with ESMTP
	id FZcDoNDxUSp39Ff4bojWA0; Sun, 24 Jul 2022 17:07:21 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id Ff4Zo0VM7vn7BFf4aoYwoL; Sun, 24 Jul 2022 17:07:21 +0000
X-Authority-Analysis: v=2.4 cv=a/cjSGeF c=1 sm=1 tr=0 ts=62dd7c49
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=RgO8CyIxsXoA:10 a=VxmjJ2MpAAAA:8 a=YxBL1-UpAAAA:8
 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=rphify_iNot1qVat9F4A:9 a=CjuIK1q_8ugA:10
 a=tuWILHVPEjkA:10 a=7gXAzLPJhVmCkEl4_tsf:22 a=Ia-lj3WSrqcvXOmTRaiG:22
 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id 27D1E13FA;
	Sun, 24 Jul 2022 10:07:19 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id 139BB40F; Sun, 24 Jul 2022 10:07:19 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Mark Johnston , freebsd-current@freebsd.org,
    chuck@freebsd.org
Subject: Re: DTrace Error
In-reply-to: <20220724030857.B57FAFC@slippy.cwsent.com>
References: <20220723035223.57CDBD7@slippy.cwsent.com> 
 <20220723141444.85620189@slippy.cwsent.com>  
 <20220723185533.9EA7D11E@slippy.cwsent.com> <20220724030857.B57FAFC@slippy.cwsent.com>
Comments: In-reply-to Cy Schubert 
   message dated "Sat, 23 Jul 2022 20:08:57 -0700."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 24 Jul 2022 10:07:19 -0700
Message-Id: <20220724170719.139BB40F@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfKf/kGgt3+exrNjm2yVQYgJTgMirjVFMLR/F+t/qCExSlbZ+rMw2+k/FnwfhaHwpw/4epyvVDKLxnHnKa0sHrMiKDa6LIG820gSowYBUNZHw3/7gnICP
 jL2mZiX/z3+CPdfOLIx+o1M8+JNrTMBwUSFuR9lOOUYkDdRF6wkS05KFJn64926mgYwNF7wnf9bOwhPdPtPmn2ClzOioV0pqC6cBoVZB9tBenP40dPwT9FwF
 Q9NUt1a81JFRgPttIA6mj0IpVzXdH/Tr3F5FWIiDJKI=
X-Rspamd-Queue-Id: 4LrV3F73srz3HH7
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	REPLYTO_EQ_FROM(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message <20220724030857.B57FAFC@slippy.cwsent.com>, Cy Schubert writes:
> In message <20220723185533.9EA7D11E@slippy.cwsent.com>, Cy Schubert writes:
> > In message , Mark Johnston writes:
> > > On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote:
> > > > In message <20220723035223.57CDBD7@slippy.cwsent.com>, Cy Schubert writ
> es
> > :
> > > > > I'm not sure if this is because my obj tree needs a fresh rebuild and
>  
> > > > > reinstall or if this is a legitimate problem. Regardless of the dtrac
> e 
> > > > > command entered, whether it be a fbt or sdt, the following error occu
> rs
> > :
> > > > >
> > > > > slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { printf("entering 
> > > > > ieee80211_vap_setup\n"); }'
> > > > > dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry { 
> > > > > printf("entering ieee80211_vap_setup\n"); }: "/usr/lib/dtrace/psinfo.
> d"
> > , 
> > > > > line 1: failed to copy type of 'pr_gid': Conflicting type is already 
> de
> > fi
> > > ned
> > > > > slippy# 
> > > > >
> > > > > Old DTrace scripts I've used months or even years ago also fail with 
> th
> > e 
> > > > > same error. It's not this one probe. All probes result in the pr_gid 
> er
> > ro
> > > r.
> > > > >
> > > > > I'm currently rebuilding my "prod" tree from scratch with the hope th
> at
> >  
> > > > > it's simply something out of sync. But, should it not be, has anyone 
> el
> > se
> > >  
> > > > > encountered this lately?
> > > > 
> > > > A full clean rebuild and installworld/kernel did not change the result.
>  
> > > > This is a new problem.
> > >
> > > I don't see any such problem on a system built from commit 151abc80cde,
> > > using GENERIC.  Are you using a custom kernel config?  Which kernel
> > > modules do you have loaded?
> >
> > [...]
>
> chuck@ emailed me privately suggesting a roll back to cb2ae6163174. The 
> problem is fixed. I'm creating a special branch that reverts only the llvm 
> commits since then.

llvm 14 is not the problem. There must be something else after cb2ae6163174 
that is causing the regression.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e**(i*pi)+1=0



From nobody Mon Jul 25 00:43:34 2022
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 4LrhGS0Qnrz4Wqkx
	for ; Mon, 25 Jul 2022 00:47:44 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LrhGR70jnz3H6T
	for ; Mon, 25 Jul 2022 00:47:43 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1658710064;
	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=vVU6Q79wdjl6b/bb5dZl4TTXrPKSdwqa3NIp3qP4ws0=;
	b=SrhSslJNJ6ERpyhA8ctfmI4whGuUG2VXGBHmBitDdocu8xkeu13cygbSqUhs+C6KGHwQUP
	WniAYCLu4Yn3k2DS0+WkIP7RSt1KIqB5w6H6D+6oH2OAcoxRTfI6wk84fWQFlOvj1Jdlh5
	v4C4rgUmC9GSgsFxrZ9XX2sE8PLw8myiQhWfP3Tx+WluqxK/KmH9lVoyDEPsOzInWxMcYk
	sT2H8IVqnuYtEsSFfU2O/YmSBMVcBl1SIb0FgfbNSBN3AKXtcizqpp8D65x8W5Hx0CBSd4
	Vx8qk2aZkQ0xeAegIE4PNn7riFIAH5UOjpe6XdF7hga+YN8vbfgf9tL2BXwx9A==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LrhGR3ySbzw48
	for ; Mon, 25 Jul 2022 00:47:43 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: <265ca3ee-6dd7-2a6d-d8e3-9f5afc3d3900@freebsd.org>
Date: Mon, 25 Jul 2022 01:43:34 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
To: freebsd-current@freebsd.org
Content-Language: en-GB
From: Graham Perrin 
Subject: orbbw (logo) default?
Organization: FreeBSD
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1658710064;
	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=vVU6Q79wdjl6b/bb5dZl4TTXrPKSdwqa3NIp3qP4ws0=;
	b=J5Nr7Wk1T11vODbBiUka4Ozdm4nn7wVRb6We58Tufl5Pl54G/Xy0ZJRHSJEqY8cJcw2/9k
	1GUgerWbvJ8e4LeW56JUgBVRnfxshZslVjBhX+8TLjV6p1IG6bCV/I98um5CnVY1No/kGe
	5RZG/dBAJzxLsK35vf5G0vXhb8eHN5Iag+L3UyGySTCQJfaKbnPsorf+b5pwItuCwF/4Jp
	rvv3hsrV5OFO8+47IWcJVAXRg4Xe5+7iYoYYxZHy8dZDMBqVYDRODTcL8EGhTOpeUiB4HO
	nkBDgVHTbioEg1XTQPhh9deHnc0gvXZiWbCf1xrEQ+FQiW9BQEOsWNjqOyogtw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658710064; a=rsa-sha256; cv=none;
	b=J2i3rd+eESKT1C1BK2CdLi0Lz8gQpNsdOncUML3Yph/hQyv0A6N5faOitOtGS6NYA9p1Mx
	fF58O2C5S5m38jIpiZYl5tXKqXLXNb5mL9oaadmUOjYvrJFvC9d+JwUbSHA+rfAbnu7sO6
	AvUsKfkOMxvg5ymnIE6eu4qxgKFfGcI3tmai164ERP8mx7MQmgWB8Vi47PNoEzJaIRX6/y
	sXGzbXKaFTrz/L1Pqcj/2q7wC1QwjhaD7PQ1uvCxt82Tu6XsPp5RLdihTXy320Cu+1XlFJ
	xP5M/vUayhsXW7t7E8HTcNLBWsKctMu/38tNQs1w+W8lB+YBCxnzkUnrScTayw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

orbbw as the default was documented eleven years ago.

Is this still true? I never saw a black-and-white version of the logo.








From nobody Mon Jul 25 00:53:18 2022
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 4LrhP405z3z4Wrqg
	for ; Mon, 25 Jul 2022 00:53:28 +0000 (UTC)
	(envelope-from jon@xyinn.org)
Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136])
	(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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LrhP211Qxz3KSD
	for ; Mon, 25 Jul 2022 00:53:26 +0000 (UTC)
	(envelope-from jon@xyinn.org)
Date: Mon, 25 Jul 2022 00:53:18 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xyinn.org;
	s=protonmail3; t=1658710403; x=1658969603;
	bh=Bwmvq1oQyB9ChLNxkv8I2ikuebrCb3W1CL6ec4h28DY=;
	h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
	 References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
	 Feedback-ID:Message-ID;
	b=J/p0DMNubNVG05OmQoUipdEZX5rBkajpLajRWA+RHRQdwRMPFjURPhIaXeAducAZ/
	 SUoFtYyqYOeIlYye8NegAwgSrwQmwcgBaUL8GNC1CTusHrVff+fanWBA5Q8tUtGpc5
	 uIaWU0mHi5uneA0DOon+75KE16jO0mnFTSUV/hXCp9ETWA5wp41Oyk2p+QwSLR4w4V
	 B/87pkYIfWh3zQlAQYr7j/yNL+LJ5bHI4x8Jrxt3nLdEBNr8cQY6GnFyxaTfpqMeuD
	 5fQHIgZyed1AuN1WPyh6KwPySM0b9ETaQBr9HSRu+PCuw7moSqIDMnW33ztEDjn1VR
	 UjNDQwicmMhYA==
To: Graham Perrin 
From: Jonathan Vasquez 
Cc: freebsd-current@freebsd.org
Reply-To: Jonathan Vasquez 
Subject: Re: orbbw (logo) default?
Message-ID: 
In-Reply-To: <265ca3ee-6dd7-2a6d-d8e3-9f5afc3d3900@freebsd.org>
References: <265ca3ee-6dd7-2a6d-d8e3-9f5afc3d3900@freebsd.org>
Feedback-ID: 12351801:user:proton
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-Queue-Id: 4LrhP211Qxz3KSD
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=xyinn.org header.s=protonmail3 header.b="J/p0DMNu";
	dmarc=pass (policy=none) header.from=xyinn.org;
	spf=pass (mx1.freebsd.org: domain of jon@xyinn.org designates 185.70.40.136 as permitted sender) smtp.mailfrom=jon@xyinn.org
X-Spamd-Result: default: False [-3.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[xyinn.org,none];
	R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24];
	R_DKIM_ALLOW(-0.20)[xyinn.org:s=protonmail3];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_ZERO(0.00)[0];
	MIME_TRACE(0.00)[0:+];
	HAS_REPLYTO(0.00)[jon@xyinn.org];
	DKIM_TRACE(0.00)[xyinn.org:+];
	ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH];
	REPLYTO_EQ_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[jon];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I'm not sure. However, looking at that commit, the beastie logo looks exact=
ly like the one Neofetch generates. I'm guessing Neofetch probably got it f=
rom there?



Jonathan Vasquez
PGP: 34DA 858C 1447 509E C77A D49F FB85 90B7 C4CA 5279
Sent with ProtonMail Secure Email



------- Original Message -------
On Sunday, July 24th, 2022 at 20:43, Graham Perrin  wrote:


> orbbw as the default was documented eleven years ago.
>
> Is this still true? I never saw a black-and-white version of the logo.
>
> https://www.freebsd.org/cgi/man.cgi?query=3Dbeastie.4th&sektion=3D8&manpa=
th=3DFreeBSD#DESCRIPTION
>
>
> https://www.freebsd.org/cgi/man.cgi?query=3Dloader.conf&sektion=3D5&manpa=
th=3DFreeBSD#DEFAULTSETTINGS
>
>
> https://cgit.freebsd.org/src/commit/?id=3D802e09ac9ee9473983514693e46d8f2=
2012e7f1d
>
>

From nobody Mon Jul 25 06:46:05 2022
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 4LrrD55yRNz4Xbjv
	for ; Mon, 25 Jul 2022 06:46:13 +0000 (UTC)
	(envelope-from flo@snakeoilproductions.net)
Received: from resurgam.purplekraken.com (resurgam.purplekraken.com [92.60.39.37])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LrrD50ZRpz3hxF
	for ; Mon, 25 Jul 2022 06:46:13 +0000 (UTC)
	(envelope-from flo@snakeoilproductions.net)
Received: from [10.100.50.117] (unknown [80.86.165.212])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by resurgam.purplekraken.com (Postfix) with ESMTPSA id 281E231C9C
	for ; Mon, 25 Jul 2022 08:46:06 +0200 (CEST)
Message-ID: 
Date: Mon, 25 Jul 2022 08:46:05 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: orbbw (logo) default?
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <265ca3ee-6dd7-2a6d-d8e3-9f5afc3d3900@freebsd.org>
From: Florian Limberger 
In-Reply-To: <265ca3ee-6dd7-2a6d-d8e3-9f5afc3d3900@freebsd.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LrrD50ZRpz3hxF
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of flo@snakeoilproductions.net designates 92.60.39.37 as permitted sender) smtp.mailfrom=flo@snakeoilproductions.net
X-Spamd-Result: default: False [-2.30 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:197540, ipnet:92.60.36.0/22, country:DE];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DMARC_NA(0.00)[snakeoilproductions.net];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[flo];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

tl;dr: doesn't look like that's still the case

I recently went through the lua loader and looked at how things work.
The drawer uses the colored orb by default if color is available and the
black and white orb when it isn't:

 > https://cgit.freebsd.org/src/tree/stand/lua/drawer.lua#n470

For the colored logo, a png images is provided in /boot/images, and for
non-framebuffer consoles an ascii fallback is provided, e.g. here:

 > https://cgit.freebsd.org/src/tree/stand/lua/gfx-orb.lua

The bw version contains only an ascii version:

 > https://cgit.freebsd.org/src/tree/stand/lua/gfx-orbbw.lua

On 25/07/2022 02:43, Graham Perrin wrote:
> orbbw as the default was documented eleven years ago.
> 
> Is this still true? I never saw a black-and-white version of the logo.
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
> 


From nobody Mon Jul 25 11:13:27 2022
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 4Lry8h1s4yz4XCZC
	for ; Mon, 25 Jul 2022 11:13:40 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2082.outbound.protection.outlook.com [40.92.97.82])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lry8f3Fn0z44wB
	for ; Mon, 25 Jul 2022 11:13:38 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=l/dyFIXSeU1KpoEIKiHQGyv8IQYSL12KO3jq431HyrVIiUnLPaTVFKSdzeN2V21bO/+kUwVZKDeMGPaaytAzBM/qqYr3xmSNbziOa+8mUEy5vNG+Y7kM26yEUg69h9x7Bd6hz63E108BySG8FtpESrLvpPbslY/jM/2tKw1Ca+l5JWx5srmDBIgu7YmLRHef4ZJkkFdeCuHRxrVwd08mbC9sAJftqWTMOu8wLkMVoMsJhV3x+9u4BR9MlH311GnzQpCd2NOkCAZpqeNRAkMU2fMYQX3QugIwnISrvP8HGzazrYgIWIyNaYN9/RbjuQxUmsQkkqNyiWx+duw83D1gxw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tKY1LcEfBIfBPWbwQsCd1lgKQfvWK6xY6doVRqmHeuo=;
 b=WIiTMU+NL6UjZHD3SxwGg1fMxH8guf8oE+vyye6yzfsgq24wu5PX9Z16v4NEaCiUtu9JTtEcxAbfnUoNGygljlvz/+pn6dPYdi80V6hiktfPey9SGyfWoIeeTr2kxMdlALpzjA8nZBx7BmIOpkBitTOSvUMqfQi+TEu2xBUCHE5dBluFHWYIKfeex/pEwimu8buuqMNFaTjhID2CPQG2GzDj+JgsHBHlhuyNd1ldcvRqR/mGknZRVQ8kWvkOaPOaoVHe/aPU7eU7W9nHdPzIoxXa+8QbQcuZP6Gw44+RB57x9QPKc/YleM6R3fv3HQQgi2+kfRmYACybp2Hp9TqNFw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tKY1LcEfBIfBPWbwQsCd1lgKQfvWK6xY6doVRqmHeuo=;
 b=oWFs4BEcwAMBLqx9/Q1EE6WHEUqYFXdjidl5UdSAWgDeILZr5EK7Iqx+IPpPSrpYOgK87Nb3GwOFnNhr6DScs4JdRiZsL4Tx4MCI+kRgAo5ArTyjMiIAUD3Rgr+Q6iXE4xBjU1hiWAS2tXKx9pabzkygZlbN8uiK95pY7ed079MyTQTK4PkHvlHfEe9BLB9QE8YkkBtLf4KvBya7sXFHHuswsmsf9ZFGfQEFH59ar86H78cNs06R47vy+N/HlPtqDVCb1aGcaGm0zEUoe5z6FBczUOU/Xzi0SzhEf3TCDYrxeLvvDKpeKQ7+r21vlXlsOYlCeezkHx9XxbyXGmWLwQ==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CPZP284MB0551.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:30::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.19; Mon, 25 Jul
 2022 11:13:34 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%7]) with mapi id 15.20.5458.024; Mon, 25 Jul 2022
 11:13:34 +0000
Date: Mon, 25 Jul 2022 08:13:27 -0300 (-03)
From: Ivan Quitschal 
To: freebsd-current@freebsd.org
Subject: Re: from X to terminal needs an fflush
In-Reply-To: 
Message-ID:
 
References: 
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-TMN: [d35lCzGEKNmeN+UD9txB1+o89By9IZLh]
X-ClientProxiedBy: CP2PR80CA0254.lamprd80.prod.outlook.com
 (2603:10d6:102:42::26) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b38ddd56-588e-4706-77f7-08da6e2eb702
X-MS-TrafficTypeDiagnostic: CPZP284MB0551:EE_
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	cVFbbFpcJzi3nLrz0Xhv8G768rWsafKIJwWVeZWSCjB0fiv9E7AbP+gW2lr8BcO3fBmV+0dUs8gPL/irQM9blXpR+KM7x9Kx3/eV4O9PSNpHPPdvoXIPNadyfiQHkSPw/r+lD1X35lIPxCGIM8K5BkppVdXwloSIMIhag9iQlACtEA93dDin1mzej8vIlwUeAk5OOMeIEGu40LfLdHQE6h7twQVfo/d/u0BFzLfYlBlwZ1Dbakk8Bbittl7NMYUikVNZRNfwK46U8pCIqFKu2xXVP99rVXlWldl3CgMX8mgQQ8raqrBnViaBmn6flpMf0/UZfyoUp6W9GBEULJapvrt9SA4SjUdlXcHZXRjfVEBqP+9CbcyQruvlAlqOqZPcgygMbpzmXZ7A+ZpTD8RblQSpgrwTzVs10KG8MQPaigrYTfPMmHLCzebg0U0Y7MkwMPnACMwWoGTrOGdO/0nQ4LT/kT8/iiKeS/3CirfFwMPFgmgt3BThkHcOVwy6b4cq07gQBvgcO60JPn9KNz1lNC8cJI6OMt2iqaLvDY9UHkYXt9xgXqaS/f+YAmmIH6EasPMl6bAT/QFsYPL4V8I9CvRRb0aNXZGOk9Udz9qhaX/UVwjwBRwDmY+6yt9Q45kZx/OEwxAvl9O6WNLrOwAtfqiHITN0MA7aTWGrXfs34epdeG9/C2SUXP4m36fb1Y3r
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?XCoJ7qt6tGtf9ZUACOp+SeIVhiISfHH4DXG9Uuy32Ys2afJWn+W8vJYjewBo?=
 =?us-ascii?Q?7p0OXOg/MYPvGgholnthfBYzb+O8FHCQITRLxYK+7YHD38DRnJbxYK594wRc?=
 =?us-ascii?Q?NRjIV0KZqu9vZ7kX8LCEnKn8hIghZg2/IMWv9OW0U8ORwcdWl37GfaXEyDHH?=
 =?us-ascii?Q?XcvwDUlnt9AVQmVPy6QnXpgXvF2RUWMhDaxIzLx/3NtaYNoZar4RHs72vNy6?=
 =?us-ascii?Q?YmRaa4NcQNqA/FyyxFU9N3S7Wz+ZA5EmPYvxIqV7bp/m72O212PoVzXdm6Gq?=
 =?us-ascii?Q?MmxyVJ7DBKizfs2MyXO+8+1A4NIrC0fEt+0rm82GWSPkMWyOWrkUaPcuaZQL?=
 =?us-ascii?Q?Ag7yE9vCWgHF9bJFNZwJXd709lLeWzoZYwjNsuxWbW1zUzzFsi+4fK/4WVCG?=
 =?us-ascii?Q?8kmxdjYaWIM0E1klStdTqceU1C5yalYTbCRCqGBFuVEZoxbv1Mr0lF8k2b9A?=
 =?us-ascii?Q?fPIbxrJfO54LqD7jHT7W8PWLyEMSe5EpgpywuGl2U7tgT4hk7sQV+LZoL0ei?=
 =?us-ascii?Q?jXOywIaE99Lg14RfexYez1IqHqu7UZGmmKHnjO9iROjcWnPacKg5DY+ne7pO?=
 =?us-ascii?Q?kwxnL2sPx1x0DpXY6bVuUDL7SAArBb+dKUpCLZ7A3uUhsakl2ZKaxxHzeeMd?=
 =?us-ascii?Q?zE/pGLfgFF8hICrwdFeTz9EE4sFnFMNiGWJjBKZmwYpLf03KYLS0/rIvQf1u?=
 =?us-ascii?Q?JTJwi1lowqDTn6gwrhwATdJrlzXM1aa6LNjz+1CFlwfDe2wXv+bi1DrD4GWC?=
 =?us-ascii?Q?sWKJCNEk2eScU3Ezrpt5B8lxoZDgdfhpgvVal+l3wFZ8m6xJzXiUvm+RQk+d?=
 =?us-ascii?Q?sg+ZiI/fk5/MZcK/8Xd9aRdcJhzSvL/I8SQqS5h1pkmGP5g1Px4zYEJSkCtR?=
 =?us-ascii?Q?DwBktDdfKbwOL0lJZJzB9f08Ctt3Zi9e0keve3D4RltD1DuMOfvqicLmm+UU?=
 =?us-ascii?Q?KGbXu4Yz3uyiQ8S2BFjTOLQBVYqf+S7z69FJTPB1aqa0AF0+Scv5YC+V1SxW?=
 =?us-ascii?Q?Diu0THWhPgAM9yCEKKhNKcr1gKuFMszfRE99VLcYblTT4j1tWiQWPJm/T1r5?=
 =?us-ascii?Q?KlIf7o7HevnJR9jIjGeg9yELJdp8z0Db8zehuXjM5x3tJ6LDlgVskm3gyf0p?=
 =?us-ascii?Q?Q0Rw2l/StD1TahcnPkdXwsKF+1MRAGoSRsJiTGCy+uxTklror9XmM4gIsgdw?=
 =?us-ascii?Q?VVz9dw2OZIBh2GE28Bom/d2jH9wyoJ8NIpx4cdCe9CB7sbdiUoNsNNYPo9G1?=
 =?us-ascii?Q?M1lPnibJ/QUqL2wsF8NUgvSn8r4mi/vEKbl/pD62ig=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: b38ddd56-588e-4706-77f7-08da6e2eb702
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jul 2022 11:13:34.8195
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPZP284MB0551
X-Rspamd-Queue-Id: 4Lry8f3Fn0z44wB
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=oWFs4BEc;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.82 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.39 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-0.99)[-0.994];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	NEURAL_HAM_MEDIUM(-0.41)[-0.411];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	FREEMAIL_FROM(0.00)[hotmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.82:from];
	DKIM_TRACE(0.00)[hotmail.com:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N



On Fri, 22 Jul 2022, Ivan Quitschal wrote:

>
> hi all
>
> Ive been trying to solve a problem which is happening to me but so far no 
> success.
> problem is this:
>
> sometimes happens, sometimes doesnt, but once im on X and do a "F2", "F3" 
> whatever in order to get back to terminal, it *does* get back to terminal but 
> the screen still shows like i was on X, therefore i have to do a F* twice in 
> order to see the console , like an fflush was missing somewhere.
>
> im using the drm-devel-kmod git for i915kms.ko btw
>
> any ideas what could it be?
>
> thank you guys
>
> --tzk
>
>

Hi All,

Please disregard , the driver is fine. this is a problem with Enlightenment, or 
at least some Ee themes.

Depending on the theme , the problem happens (you need to do more than one F* in 
order to the terminal shows up). something is holding AIGLX from being suspended 
right away

just in case someone has the same problem.

thank you

--tzk

From nobody Mon Jul 25 15:26:57 2022
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 4Ls3n23Br8z4Xl2M
	for ; Mon, 25 Jul 2022 15:27:02 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ls3n15L9Jz3LJD;
	Mon, 25 Jul 2022 15:27:01 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-io1-xd36.google.com with SMTP id x64so9056006iof.1;
        Mon, 25 Jul 2022 08:27:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=ulqQpwrOkVy2HV4xPoCnG3RAwJ04gsTu4kHE6xeaAI0=;
        b=MsSNSCCZjlvUdKKJX9WukxSmCSLL8Lzu/AuQ+FmeX1fln7bpEy/dnkmUy+d+svabUS
         +xvOXmgkpU4cNO9tHTZWB23EBAwlIDsEZLcTasVy5tGf81X5zGA+QrgT9qk1dvvMLxtd
         5rThmRhLR/TGNzHMbs6buVFJkUaKOsONXlAVyzrme43ZyTMrUAXUTIQcuzLN2gaxyXJa
         vNFh4JoUMP3ul3pv1D1UQswzEz66QuG24/ZAttg7/fMBCi62dU/FcxVMDRQGyGnHqR2b
         VlBUgrTkuvMT6r9QYirI1KFDsQ2l9JQFCbRBMv+11LthncZTMxHUdcfzjE7mdIvGMKgv
         ShvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
         :references:mime-version:content-disposition:in-reply-to;
        bh=ulqQpwrOkVy2HV4xPoCnG3RAwJ04gsTu4kHE6xeaAI0=;
        b=NeycLCGKWXfdkJYcldhkS7+w66v9eHAWrlQDodj+Z7iyrx/P/56KbyZCvk9TChCQa2
         7X/UXvA1HsyU3CizKel+Jvkvn9FwBEOakjpDZXagbW0OSM6SUFg/jBgavkPXnsBDZqh0
         r1xYT/oqGCJy3Moo3qbNF4tjRHjyFHEGUcGhCmUg1PDDVMhgPQzCiqSBpK2QVo5TWxHu
         bK/JITqw+T7MwHovcODum++vGAOGjlDLo/Geh2znvNMq9A0rzzf1Zffe+4hAfX6tNQDX
         jFHFXYp5kS2Ap7n8dR0dQpKCdzKJJxcBtsvo3DivsUB33XKBTtNveAtxzRSJYPVbkgRD
         MFuA==
X-Gm-Message-State: AJIora9FKZeAIbaEXOgWNlijatfxAczXE/lCKvA2OLgyDgODRx0yeFxX
	TDwckwCux0beuLgeips3/xgnpzAKnDE=
X-Google-Smtp-Source: AGRyM1twxMQgKp9t9odI7JemaF2HiQLIo8n6BqQAZaJ7TcusT/mjO8LUtoerDSbYKWpf8pV830j4WQ==
X-Received: by 2002:a05:6602:340f:b0:67c:44d0:b1b0 with SMTP id n15-20020a056602340f00b0067c44d0b1b0mr4092314ioz.98.1658762820858;
        Mon, 25 Jul 2022 08:27:00 -0700 (PDT)
Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237])
        by smtp.gmail.com with ESMTPSA id t10-20020a02b18a000000b0032e2996cadesm5551163jah.66.2022.07.25.08.26.59
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 25 Jul 2022 08:27:00 -0700 (PDT)
Date: Mon, 25 Jul 2022 11:26:57 -0400
From: Mark Johnston 
To: Cy Schubert 
Cc: freebsd-current@freebsd.org, chuck@freebsd.org
Subject: Re: DTrace Error
Message-ID: 
References: <20220723035223.57CDBD7@slippy.cwsent.com>
 <20220723141444.85620189@slippy.cwsent.com>
 
 <20220723185533.9EA7D11E@slippy.cwsent.com>
 <20220724030857.B57FAFC@slippy.cwsent.com>
 <20220724170719.139BB40F@slippy.cwsent.com>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220724170719.139BB40F@slippy.cwsent.com>
X-Rspamd-Queue-Id: 4Ls3n15L9Jz3LJD
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=MsSNSCCZ;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d36 as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-2.64 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	NEURAL_HAM_MEDIUM(-0.94)[-0.941];
	MID_RHS_NOT_FQDN(0.50)[];
	FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d36:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Jul 24, 2022 at 10:07:19AM -0700, Cy Schubert wrote:
> In message <20220724030857.B57FAFC@slippy.cwsent.com>, Cy Schubert writes:
> > In message <20220723185533.9EA7D11E@slippy.cwsent.com>, Cy Schubert writes:
> > > In message , Mark Johnston writes:
> > > > On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote:
> > > > > In message <20220723035223.57CDBD7@slippy.cwsent.com>, Cy Schubert writ
> > es
> > > :
> > > > > > I'm not sure if this is because my obj tree needs a fresh rebuild and
> >  
> > > > > > reinstall or if this is a legitimate problem. Regardless of the dtrac
> > e 
> > > > > > command entered, whether it be a fbt or sdt, the following error occu
> > rs
> > > :
> > > > > >
> > > > > > slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { printf("entering 
> > > > > > ieee80211_vap_setup\n"); }'
> > > > > > dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry { 
> > > > > > printf("entering ieee80211_vap_setup\n"); }: "/usr/lib/dtrace/psinfo.
> > d"
> > > , 
> > > > > > line 1: failed to copy type of 'pr_gid': Conflicting type is already 
> > de
> > > fi
> > > > ned
> > > > > > slippy# 
> > > > > >
> > > > > > Old DTrace scripts I've used months or even years ago also fail with 
> > th
> > > e 
> > > > > > same error. It's not this one probe. All probes result in the pr_gid 
> > er
> > > ro
> > > > r.
> > > > > >
> > > > > > I'm currently rebuilding my "prod" tree from scratch with the hope th
> > at
> > >  
> > > > > > it's simply something out of sync. But, should it not be, has anyone 
> > el
> > > se
> > > >  
> > > > > > encountered this lately?
> > > > > 
> > > > > A full clean rebuild and installworld/kernel did not change the result.
> >  
> > > > > This is a new problem.
> > > >
> > > > I don't see any such problem on a system built from commit 151abc80cde,
> > > > using GENERIC.  Are you using a custom kernel config?  Which kernel
> > > > modules do you have loaded?
> > >
> > > [...]
> >
> > chuck@ emailed me privately suggesting a roll back to cb2ae6163174. The 
> > problem is fixed. I'm creating a special branch that reverts only the llvm 
> > commits since then.
> 
> llvm 14 is not the problem. There must be something else after cb2ae6163174 
> that is causing the regression.

Are you able to bisect?  I spent a bit of time trying to replicate the
problem based on your kernel config, without any luck yet.

From nobody Mon Jul 25 15:37:06 2022
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 4Ls40k54XFz4Xm8C
	for ; Mon, 25 Jul 2022 15:37:10 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ls40j73X1z3Mc1;
	Mon, 25 Jul 2022 15:37:09 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227])
	by cmsmtp with ESMTP
	id FzKMow6TrS8WrG08qokDL5; Mon, 25 Jul 2022 15:37:08 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id G08pooHtwGRNlG08qoa0r0; Mon, 25 Jul 2022 15:37:08 +0000
X-Authority-Analysis: v=2.4 cv=Sfrky9du c=1 sm=1 tr=0 ts=62deb8a4
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=RgO8CyIxsXoA:10 a=VxmjJ2MpAAAA:8 a=YxBL1-UpAAAA:8
 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=hk3Yo9kxTOJDQFvJsrMA:9 a=CjuIK1q_8ugA:10
 a=tuWILHVPEjkA:10 a=7gXAzLPJhVmCkEl4_tsf:22 a=Ia-lj3WSrqcvXOmTRaiG:22
 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id DB6A915B;
	Mon, 25 Jul 2022 08:37:06 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id A2BB3A6; Mon, 25 Jul 2022 08:37:06 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Mark Johnston 
cc: Cy Schubert , freebsd-current@freebsd.org,
    chuck@freebsd.org
Subject: Re: DTrace Error
In-reply-to: 
References: <20220723035223.57CDBD7@slippy.cwsent.com> 
 <20220723141444.85620189@slippy.cwsent.com>  
 <20220723185533.9EA7D11E@slippy.cwsent.com> <20220724030857.B57FAFC@slippy.cwsent.com> <20220724170719.139BB40F@slippy.cwsent.com> 
Comments: In-reply-to Mark Johnston 
   message dated "Mon, 25 Jul 2022 11:26:57 -0400."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 25 Jul 2022 08:37:06 -0700
Message-Id: <20220725153706.A2BB3A6@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfBKxQBoMWrp1CNdVHbh5j5GK5Bgepl2N2ivGbT2cPd7STymFeJafjA2wuCoO7hnVXKpjzXoRr34ZB91tx5+65+7HHmO5ZuFXVjSc4zlPCHI0TZqZ9xPU
 uB78RbIxiFudXAuiCrZq/Xv2EQZhjqMMtFVFeXm1gYpztdhB5hV8yvjK9L9Rh4Mv1+if9JZZAIgH0+d9OhBRwmFIWAkjX7nicjuEwBYrNIfAuS6PnCGQ4Yir
 YD1z5JGqE28n+USqGoYD/Wg6uKKy288C419zFWhov6I=
X-Rspamd-Queue-Id: 4Ls40j73X1z3Mc1
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from];
	MIME_GOOD(-0.10)[text/plain];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	REPLYTO_EQ_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message , Mark Johnston writes:
> On Sun, Jul 24, 2022 at 10:07:19AM -0700, Cy Schubert wrote:
> > In message <20220724030857.B57FAFC@slippy.cwsent.com>, Cy Schubert writes:
> > > In message <20220723185533.9EA7D11E@slippy.cwsent.com>, Cy Schubert write
> s:
> > > > In message , Mark Johnston writes:
> > > > > On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote:
> > > > > > In message <20220723035223.57CDBD7@slippy.cwsent.com>, Cy Schubert 
> writ
> > > es
> > > > :
> > > > > > > I'm not sure if this is because my obj tree needs a fresh rebuild
>  and
> > >  
> > > > > > > reinstall or if this is a legitimate problem. Regardless of the d
> trac
> > > e 
> > > > > > > command entered, whether it be a fbt or sdt, the following error 
> occu
> > > rs
> > > > :
> > > > > > >
> > > > > > > slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { printf("enter
> ing 
> > > > > > > ieee80211_vap_setup\n"); }'
> > > > > > > dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry { 
> > > > > > > printf("entering ieee80211_vap_setup\n"); }: "/usr/lib/dtrace/psi
> nfo.
> > > d"
> > > > , 
> > > > > > > line 1: failed to copy type of 'pr_gid': Conflicting type is alre
> ady 
> > > de
> > > > fi
> > > > > ned
> > > > > > > slippy# 
> > > > > > >
> > > > > > > Old DTrace scripts I've used months or even years ago also fail w
> ith 
> > > th
> > > > e 
> > > > > > > same error. It's not this one probe. All probes result in the pr_
> gid 
> > > er
> > > > ro
> > > > > r.
> > > > > > >
> > > > > > > I'm currently rebuilding my "prod" tree from scratch with the hop
> e th
> > > at
> > > >  
> > > > > > > it's simply something out of sync. But, should it not be, has any
> one 
> > > el
> > > > se
> > > > >  
> > > > > > > encountered this lately?
> > > > > > 
> > > > > > A full clean rebuild and installworld/kernel did not change the res
> ult.
> > >  
> > > > > > This is a new problem.
> > > > >
> > > > > I don't see any such problem on a system built from commit 151abc80cd
> e,
> > > > > using GENERIC.  Are you using a custom kernel config?  Which kernel
> > > > > modules do you have loaded?
> > > >
> > > > [...]
> > >
> > > chuck@ emailed me privately suggesting a roll back to cb2ae6163174. The 
> > > problem is fixed. I'm creating a special branch that reverts only the llv
> m 
> > > commits since then.
> > 
> > llvm 14 is not the problem. There must be something else after cb2ae6163174
>  
> > that is causing the regression.
>
> Are you able to bisect?  I spent a bit of time trying to replicate the
> problem based on your kernel config, without any luck yet.

How fortuitous is this email. I just rebooted my sandbox again and 
discovered this is related to non-INVARIANT kernels. Enabling INVARIANTS 
"fixes" dtrace. There must be some commit since cb2ae6163174 that affected 
non-INVARIANT kernels. As to which one, I'm not sure yet.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e**(i*pi)+1=0



From nobody Tue Jul 26 17:29:02 2022
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 4LskRW0FT2z4XbMm
	for ; Tue, 26 Jul 2022 17:29:11 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LskRV5WYNz3dr6
	for ; Tue, 26 Jul 2022 17:29:10 +0000 (UTC)
	(envelope-from 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 26QHT3wk055468;
	Tue, 26 Jul 2022 10:29:09 -0700 (PDT)
	(envelope-from bsd-lists@bsdforge.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
Date: Tue, 26 Jul 2022 10:29:02 -0700
From: Chris 
To: Ivan Quitschal 
Cc: freebsd-current@freebsd.org
Subject: Re: from X to terminal needs an fflush
In-Reply-To: 
References: 
User-Agent: UDNSMS/17.0
Message-ID: 
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_f6dec8d23cb06732c72b4d00418f62b0"
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4LskRV5WYNz3dr6
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-Spamd-Result: default: False [0.00 / 15.00];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_f6dec8d23cb06732c72b4d00418f62b0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-07-22 08:27, Ivan Quitschal wrote:
> hi all
> 
> Ive been trying to solve a problem which is happening to me but so far no 
> success.
> problem is this:
> 
> sometimes happens, sometimes doesnt, but once im on X and do a "F2", "F3" 
> whatever
> in order to get back to terminal, it *does* get back to terminal but the 
> screen
> still shows like i was on X, therefore i have to do a F* twice in order to 
> see the
> console , like an fflush was missing somewhere.
If I'm following you correctly; you should be performing a Ctrl+Atl+F<1-8> to
accomplish your goal. Does doing it that way fix it for you?

HTH

--Chris
> 
> im using the drm-devel-kmod git for i915kms.ko btw
> 
> any ideas what could it be?
> 
> thank you guys
> 
> --tzk

--=_f6dec8d23cb06732c72b4d00418f62b0
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_f6dec8d23cb06732c72b4d00418f62b0--

From nobody Tue Jul 26 17:30:25 2022
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 4LskT54D5dz4Xbgn
	for ; Tue, 26 Jul 2022 17:30:33 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LskT52lQDz3fZH
	for ; Tue, 26 Jul 2022 17:30:33 +0000 (UTC)
	(envelope-from 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 26QHUQHG054947;
	Tue, 26 Jul 2022 10:30:32 -0700 (PDT)
	(envelope-from bsd-lists@bsdforge.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
Date: Tue, 26 Jul 2022 10:30:25 -0700
From: Chris 
To: Ivan Quitschal 
Cc: freebsd-current@freebsd.org
Subject: Re: from X to terminal needs an fflush
In-Reply-To: 
References: 
 
User-Agent: UDNSMS/17.0
Message-ID: 
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_e1d7aedd54f1a1574b686ceec9c43592"
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4LskT52lQDz3fZH
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-Spamd-Result: default: False [0.00 / 15.00];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_e1d7aedd54f1a1574b686ceec9c43592
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-07-26 10:29, Chris wrote:
> On 2022-07-22 08:27, Ivan Quitschal wrote:
>> hi all
>> 
>> Ive been trying to solve a problem which is happening to me but so far no 
>> success.
>> problem is this:
>> 
>> sometimes happens, sometimes doesnt, but once im on X and do a "F2", "F3" 
>> whatever
>> in order to get back to terminal, it *does* get back to terminal but the 
>> screen
>> still shows like i was on X, therefore i have to do a F* twice in order to 
>> see the
>> console , like an fflush was missing somewhere.
> If I'm following you correctly; you should be performing a Ctrl+Atl+F<1-8> 
> to
TYPO sorry. That *should* have read: Ctrl+Alt+F<1-8>

Sorry.
> accomplish your goal. Does doing it that way fix it for you?
> 
> HTH
> 
> --Chris
>> 
>> im using the drm-devel-kmod git for i915kms.ko btw
>> 
>> any ideas what could it be?
>> 
>> thank you guys
>> 
>> --tzk

--=_e1d7aedd54f1a1574b686ceec9c43592
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_e1d7aedd54f1a1574b686ceec9c43592--

From nobody Tue Jul 26 22:27:37 2022
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 4Lss4N0mHDz4XQDn
	for ; Tue, 26 Jul 2022 22:28:04 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lss4L5gtxz3YBw
	for ; Tue, 26 Jul 2022 22:28:02 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 26QMRc3Q050152;
	Wed, 27 Jul 2022 07:27:38 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Wed, 27 Jul 2022 07:27:37 +0900
From: Tomoaki AOKI 
To: Chris 
Cc: Ivan Quitschal , freebsd-current@freebsd.org
Subject: Re: from X to terminal needs an fflush
Message-Id: <20220727072737.53528f96e08c7a3390e49170@dec.sakura.ne.jp>
In-Reply-To: 
References: 
	
	
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Lss4L5gtxz3YBw
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [-1.60 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	R_SPF_NA(0.00)[no SPF record];
	RCPT_COUNT_THREE(0.00)[3];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DMARC_NA(0.00)[sakura.ne.jp];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	TO_DN_SOME(0.00)[];
	FREEMAIL_CC(0.00)[hotmail.com,freebsd.org];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 26 Jul 2022 10:30:25 -0700
Chris  wrote:

> On 2022-07-26 10:29, Chris wrote:
> > On 2022-07-22 08:27, Ivan Quitschal wrote:
> >> hi all
> >> 
> >> Ive been trying to solve a problem which is happening to me but so far no 
> >> success.
> >> problem is this:
> >> 
> >> sometimes happens, sometimes doesnt, but once im on X and do a "F2", "F3" 
> >> whatever
> >> in order to get back to terminal, it *does* get back to terminal but the 
> >> screen
> >> still shows like i was on X, therefore i have to do a F* twice in order to 
> >> see the
> >> console , like an fflush was missing somewhere.
> > If I'm following you correctly; you should be performing a Ctrl+Atl+F<1-8> 
> > to
> TYPO sorry. That *should* have read: Ctrl+Alt+F<1-8>

...and Alt+F<1-8> to switch vtys afterwards.
To get back to X, Alt+F9.

You need Ctrl+ only on X, and does not work with Ctrl+ on vty<1-8>.


> 
> Sorry.
> > accomplish your goal. Does doing it that way fix it for you?
> > 
> > HTH
> > 
> > --Chris
> >> 
> >> im using the drm-devel-kmod git for i915kms.ko btw
> >> 
> >> any ideas what could it be?
> >> 
> >> thank you guys
> >> 
> >> --tzk


-- 
Tomoaki AOKI    

From nobody Wed Jul 27 11:20:38 2022
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 4LtBDh1sLmz4XC8K
	for ; Wed, 27 Jul 2022 11:21:24 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2068.outbound.protection.outlook.com [40.92.96.68])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LtBDf536Vz3Klc
	for ; Wed, 27 Jul 2022 11:21:22 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=brfE7XbTU/eKwPWeIdfPUESGulFjmttL7zq9GVHP6YvQE/UROhSWCLMIYXowNejgePU9nm6AxGp9W8124d0kdq0kMKSFIDqIYUmatcH0lkow6ifORjDlUn6sT0JwlRJmUyNKI6inZsAhWLwnKeA9/c4/2dnUEsXuRtC+Dq+5AdVBq10cLyn2unrnYRDsgJ7A5u+DJQ4GrZ04pDF+JmdEvF1QIdi3BRTiaAKYSrHix+fpytx+BW7mEX1aeYllB2sH74LteIulgDqUcNIzm97FksBmQk4M6HryWcC1BgiCItkohbWLN8Ft99nTxCicskn1CADrND1P0hOavLbz2fchMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Ey12nofaH2yrC2YtabS9H0zpxJrzYemqyhp47soVE8s=;
 b=XeMGRqcbUYPg/ltTTZyBtmdPRhCl8V6M2BlYQOt3X6X0+yD7fWv5w/8ga9dDw0fGEjLNY/kncggWkgQjhxXptxNg/4eJgSJRmuuLsqiR9svKIUZ3ff9fljLqUYes3D7x0UiEHcATEbOWzVhcQCRK7oYdVJOMnNk7ToLfJ1xLcftD/G3cHOeDJsPaH96ur/FOANrlVmZ4C5fWIgKCCUxVReUn92Il05Ink6mihfubBZTd/mb/rYVaDDyOY8KAWplocGeCJWsF+MHDL7iXoDZK5q+Tk7rHiVf6gu0mYWTnwXCiqO7M+XrtZe2MbMo/e6jX28auZj9NoFXTnmOp/4BkuQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Ey12nofaH2yrC2YtabS9H0zpxJrzYemqyhp47soVE8s=;
 b=ASusE6m32sN0glPaN638NMjTY8DD0OdjEC8+j9zGzXl2trlb0nBGNyIvEGYYeMjpMWEstlAv58GzucO7HBOxPrDMiMKg6euyBPzicvoJDiC+ldgyetixtRBni4r/azZQX5gOjVlrNqfZCi3b9B9evxeihaldHxTExx8sk4RFv41XUKc0PkirLc8OfhnIUi6aGyTAWFMP9grjXWcdsC2nN2tDbQ9xEGXm8cyfzsberbKsgEP/SJq3wBNkSMiEWKFN2Z3NCY7lTY9TR+eeXMD1cT7/B58jz9ITYijiS+P5Jd9+SZkigCCuUdl+bAvWyALqgEjEvPtAc2h5JrftTpBcDA==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CP4P284MB0819.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:90::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5482.6; Wed, 27 Jul
 2022 11:21:19 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%7]) with mapi id 15.20.5458.025; Wed, 27 Jul 2022
 11:21:18 +0000
Date: Wed, 27 Jul 2022 08:20:38 -0300 (-03)
From: Ivan Quitschal 
To: Tomoaki AOKI 
cc: Chris , Ivan Quitschal , 
    freebsd-current@freebsd.org
Subject: Re: from X to terminal needs an fflush
In-Reply-To: <20220727072737.53528f96e08c7a3390e49170@dec.sakura.ne.jp>
Message-ID:
 
References:    <20220727072737.53528f96e08c7a3390e49170@dec.sakura.ne.jp>
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-TMN: [Rch3OGEJLz/autEtMCJ+x5/M2H5Fpd7b]
X-ClientProxiedBy: CP2PR80CA0254.lamprd80.prod.outlook.com
 (2603:10d6:102:42::26) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 23fd7805-e145-4d01-e086-08da6fc2203a
X-MS-Exchange-SLBlob-MailProps:
	f36zkjAOy3WneZsFOunqNzh8tTd0g8BeYovgMl0D/CuRJMlLQyMsNkVLHpn2YGY1QUllOgCsa4f/0emgKYUYLEgt59jZJWNyFWEJWI0sC8yer6AIZDB/HoLuMBHhklpVwHUZgJYyt+M2k8lndDf8GQWYGG54M86qvWSzqcsRQARkuUdPmJ9uMG7ob7Ults1tOVnhpXeI8JYp+38jVBR3ZxYl+4SZxcpRs2cCPUwKhVtM3jF1aUXEKcDWptOpZgBcPH30n2IqnUscb1QrsROCE6gf8QWGOJ43OGtL3PkMecVGQav2+mbjXFNfASvJGtJitJUPkLWOAZuO7LXyPjl+AOTpJBKHCdoXkrKhP8ZNUXHd3WQ1qgMv8s6vsnX66yeQmRiFPyhXwrejH9XUwm/S2CDrhv1zkrBA4kAr/4a9x/xO0W6kLqyQ+6KyI10lCXfvVC/booiWb9CnelYzq+yZ1/JhXmrX29jqJLd2C5EsewjYFmlVUNwusI8gr4+tSoQqYGTLapRnpESaX2QRqY6h1mWwVIWhTt/GCHEjL2Jdhnth4CtfVjHhUlryTNWxaFimXJfqwjyfcQykl/i27JXsC3W2idhY6MqcVgg8pJ7UT57JYfd68vZOguw1kyWsodL2IkCHlKJ6kaF9gHtvzLowSlG952z8UTDmocHOcw384z89tVUU3SLWiaa/WOTW0FWZtzkS5jVurzRGq3X8v2Y4ppVijGJQ3JAFcML2NsbhqBs=
X-MS-TrafficTypeDiagnostic: CP4P284MB0819:EE_
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	BGkE1lU4ZnvwJcy5d0xgc89RJqkhJ2AY39gk6kmLJg2NCkf6DuXj0RheyXZaZ85QPVO5rjL5Y8m5A4Q2xzkjO2B76WxOTfohiKGURYcMEV8vMh4BsL6rwmbpPExqfM6GWbvtGOJZcJpgvvIPenDwUvO9YsXN9hjUo9heWC98r/Utmo30BdQe+zKSPJJFJhL86RETYMpbMiTFGDxNueCM6WehTmF/U4YvvzNXfKFActvcQ6ahf0hys3pwINQ8dGmWn52Z8qYwdSHSlhACJgNZcfwa7JlFMaYF6O0qqiDQ2KAao1scVvYgLhi0wfie/vk/U+13HTBHDEek8nZDdeMraDH0MZ0Ayf7a5rEFY01aAFXzhWZiJDA0NJXrTGJ9rdqH4Ddv9TWjGOxkBN+mlHoEYmADC9sx4+ZNo1OFwbAMbIbguyKSfuCwG1oNwLUqbHKYqSZXpIwLtO5L8sBSBf7qzTvquUMjkYdNZO7wiWRJIyBVe2xIB4VVmYdp0XN2GVDxgwSyK/8zBBiaHhi7hHqdBSoLdg1+8iTdDGgxN7tk3Y9aAUW0YcIc4XrZ7Psu6N5Jx8QyX3fd8NnJUGcy/qoljtHhre9uLcRaMvNo/SCTtNKUmkZpq4Ec7UOAXYAr7S6rmiF7/7K2NYtmAMiMFBaPVOfECJszRvZ84q9fzArkxUdJRdthA+BqhRMzk5M2lYWN
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?4FmNV7+IDdBP8MoBi+YEAukIG+Z9SzzfVjOvM/48zZ2JPMaigc7KimrIy6tV?=
 =?us-ascii?Q?2hNpfZN9xZczNaYkYdmNRvEflirsbH8ft7G3psNUGJ7+dMBJdNPjAVgJzurQ?=
 =?us-ascii?Q?QAOAWE9Bk5nAPXVl1mPF4dxoTIKkazbb7UOlpSxge4jt+DhMAezoFOohyqcL?=
 =?us-ascii?Q?HBNnItmSz4y81kp+IPEDNPlaMMWq+u1GYvW4mZIfReRYuy0uldwCg/qHYdCd?=
 =?us-ascii?Q?tzt2FXzQxrLDimCn7J9zPaxQ6128sh3O8ksgZ8flqT1gvWThu9u97Fz7lR8Q?=
 =?us-ascii?Q?ligA/GV7NJzBhbKVwoZb/k7bowrbLVLVqLU2pQOcFDpQmH1o/J32FLiFANzF?=
 =?us-ascii?Q?+4IVbaIsCL1ypDNZ0YmdReS7p9XxrVW4F7HY5KtHgj157fYnzO3NxIkU5uQQ?=
 =?us-ascii?Q?3szCYoIZfGq+7//ovolnFnCJAmIz0PpW6+BHcD8P8QebLpg5voHd4NcpOh05?=
 =?us-ascii?Q?bxhhpQ53neqem7VNYh/+VlvcqdBU9paoVTltYWA9aRF3xPjL4xOuIRxbpXHH?=
 =?us-ascii?Q?DMxQ2GqdCteo4g/tHuyaeIMdAkG5FbJCN0yLJCsYdej5J3KE2LKBz4bRnlc0?=
 =?us-ascii?Q?ggvShoRbuvow3WQRzTfSdFhrK3JKurPu12gFSfpPak1YQWydZpgr8pqyOts+?=
 =?us-ascii?Q?k1AJfpGbuyNDvPf/gjub9IpYdRmjaAhtpKc6XsNoHsZaRVUvApAP0/EcNqB/?=
 =?us-ascii?Q?2o9MFs2XLJQ7bPdTw03739oCLHmTUCr6H6BRsUxryhv2dvskZX5FLZKsyJOP?=
 =?us-ascii?Q?AKXs1HBgdoE/rQyqJaIYuGdXNvNxnL8AvJB6sydE05rCksJTPUomY3AgYGgf?=
 =?us-ascii?Q?LMCda2BRBeF8ZEiaXgXFyb07d4uw756CTFqbfTCctnz0k/lEtSW283d3V5sf?=
 =?us-ascii?Q?yZJyFguqkhY+1oElYSMsjuOUloEAx2YSHy8AhEcXsVYp3t5nW5LJNozSVKgw?=
 =?us-ascii?Q?rx3ZL7bNsJ/w2qnse4MZrnunF/MVcbz/JnEXp3uoohuGgHaqnQ6rFlavrPgg?=
 =?us-ascii?Q?gZCnLCQ+V18exBecQRud29lmJYYXn7W2ALD/Z+V3xq0OADWAXA/+98th+XF3?=
 =?us-ascii?Q?De4JeYSL8RcqhcJsJjHznb15Yka/U33FBGdaruxQZ8C+Ne6QzULGeiekimnh?=
 =?us-ascii?Q?LorjYeDOGaFxNM9Vmhyd3A+PYVMXEvUuKP1thz1MurfDtMOKs69XGzT79iqE?=
 =?us-ascii?Q?5kgc4xRihec4zjXX32owStDcx+Cpe85+GrctN8tkmnJEu1dKs/hD2dcw+d65?=
 =?us-ascii?Q?Kr4y8zC+QL09lCMI1QLk2sAzCEsddFUXlK6jZv6B3w=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 23fd7805-e145-4d01-e086-08da6fc2203a
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2022 11:21:18.8913
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP4P284MB0819
X-Rspamd-Queue-Id: 4LtBDf536Vz3Klc
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=ASusE6m3;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.68 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.38 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	NEURAL_HAM_MEDIUM(-0.39)[-0.394];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.96.68:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[bsdforge.com,hotmail.com,freebsd.org];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	RCVD_COUNT_THREE(0.00)[3];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.96.68:from]
X-ThisMailContainsUnwantedMimeParts: N



On Tue, 26 Jul 2022, Tomoaki AOKI wrote:

> On Tue, 26 Jul 2022 10:30:25 -0700
> Chris  wrote:
>
>> On 2022-07-26 10:29, Chris wrote:
>>> On 2022-07-22 08:27, Ivan Quitschal wrote:
>>>> hi all
>>>>
>>>> Ive been trying to solve a problem which is happening to me but so far no
>>>> success.
>>>> problem is this:
>>>>
>>>> sometimes happens, sometimes doesnt, but once im on X and do a "F2", "F3"
>>>> whatever
>>>> in order to get back to terminal, it *does* get back to terminal but the
>>>> screen
>>>> still shows like i was on X, therefore i have to do a F* twice in order to
>>>> see the
>>>> console , like an fflush was missing somewhere.
>>> If I'm following you correctly; you should be performing a Ctrl+Atl+F<1-8>
>>> to
>> TYPO sorry. That *should* have read: Ctrl+Alt+F<1-8>
>
> ...and Alt+F<1-8> to switch vtys afterwards.
> To get back to X, Alt+F9.
>
> You need Ctrl+ only on X, and does not work with Ctrl+ on vty<1-8>.
>
>
>>
>> Sorry.
>>> accomplish your goal. Does doing it that way fix it for you?
>>>
>>> HTH
>>>
>>> --Chris
>>>>
>>>> im using the drm-devel-kmod git for i915kms.ko btw
>>>>
>>>> any ideas what could it be?
>>>>
>>>> thank you guys
>>>>
>>>> --tzk
>
>
> -- 
> Tomoaki AOKI    
>

hi

no gyuys, i know how to go back from X to terminal, what i was saying is that by 
doing CTRL + ALT + F* it wasnt working until i did *another* 
CTRL+ALT+F.

example:
im getting off from X , so i do an CTRL+ALT+F2

nothing happens, until you do *another* CTRL+ALT+F3 . so you gotta do a 
CTRL+ALT+F* twice in order to get back to terminal

but i found out the problem lies within enlightenment themes, not anything else 
.
at least the problem is  solved by changing EE theme, this way i can get back 
instantly to terminal with just ONE CTRL+ALT+F2

thanks

Ivan

From nobody Wed Jul 27 20:45:53 2022
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 4LtQm96lyzz4Xgc6
	for ; Wed, 27 Jul 2022 20:46:01 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2045.outbound.protection.outlook.com [40.92.97.45])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LtQm85Ctlz3Wld
	for ; Wed, 27 Jul 2022 20:46:00 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=i6AdZ4hSmudYmvcnzRhgrPXKPuYDKm4b5mQGSXuGW1ahbj/aE3Aznf0d+tZVaNU9zG/qB8vPGP9Fvs37ng9Qzujuq38/Db18uIeIDiB6oDNFE3baEfod4ndA3vO71vH4Zm5Ruv3WA6reRkWOA1rqPpACcnt0uT0DfN4c+6WR0t9aP5n1YFXKvw5kVUc3ZY5oHR3PqWzLZnj7G6n103Ho4aYflxgykFXaRR//vMNm/OCy25KQ2F4Bqzrs51jW9pYHEz8SJRrsJv5txUXecR6Zy/icnk4VtGet0e/fozNEnoL0go2CxjZypy/IxqW20ywCwnEJZaFivkJDZLPqONaENw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=mfoejcOA4kcm1QrABEV6HriBoh/Q7LlbqtGOUBmd5Is=;
 b=Nl/SGEzP1JVNla2ai5TZjEoPLzvA1txGsoDD2H+EPNYVV2LJIbB/7IxhfoBxBcDaMp04pKBXUHzuCfXvD05GNHaOh2qy51gl7VM4vXW7Pxrkxti6QmM51g9QtTJIERcJDIjBmuC3+Rj4q0frulWiS4o2KmuCjFxBDMBkUFofUvv2/FRW7HeubBmCFnBf5pSr98cUZvbMJok8kUbE/9/h9eHtiZfIL+3kfXlrgaz12fJTuTatPVD78ldYoAf/e1m+9zPMSXkow3D7OqdyNGo4kD4F/NMFycC0SW80uxaTLhO6vcdqPim9V5i4QGp182zkNqU6muZpXUpxq9t2UqMc3A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=mfoejcOA4kcm1QrABEV6HriBoh/Q7LlbqtGOUBmd5Is=;
 b=ZAnHwcEDYChd0IM+9J+skBAPyKwLukMRj+E8voxPmEkl9J2C8QsKWA+Fxn/GEZ0yDBQfq0PPtTAFmjuJY9XWZoZrbLMNO/5vxu9K2ezdL2DqSiiIsbUqfd88aSkYWFZPxKQ/VSTVOKcF6OAqgRjcDTQ1hjTRioNIziquSFRdBkjpHMozeqJGJnnX2tZH69ezbolnuQyeAXMwtvZlonD9ml3Ksyo+4FdldtlUMwc5XqaBfuB6Cs1sAAM63tMvSho/pcIwJCBOyKRqIUTzo3hd+3U75KbgA5+YRCnJ3//Cy0JrJWKzPqr5dKZHPW2tr8do97tfbEHZLnfmVpV5LTp/4w==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CPYP284MB0690.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:78::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.19; Wed, 27 Jul
 2022 20:45:56 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::9d3d:d0fe:1196:ff34%7]) with mapi id 15.20.5458.025; Wed, 27 Jul 2022
 20:45:56 +0000
Date: Wed, 27 Jul 2022 17:45:53 -0300 (-03)
From: Ivan Quitschal 
To: Ivan Quitschal 
cc: Tomoaki AOKI , Chris , 
    freebsd-current@freebsd.org
Subject: Re: from X to terminal needs an fflush
In-Reply-To: 
Message-ID:
 
References:    <20220727072737.53528f96e08c7a3390e49170@dec.sakura.ne.jp>
 
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-TMN: [TtahQsbDvhqrQEWHS26Y12SKuclCy6ac]
X-ClientProxiedBy: CP5P284CA0020.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:94::7) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <8be01920-43f3-be90-c0e9-87b61aa67ffc@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 010bc86f-5386-4a6f-60be-08da70110105
X-MS-Exchange-SLBlob-MailProps:
	f36zkjAOy3WneZsFOunqN77mv+NU54jOwtGPifDGVaY/jsTrOKCPPikcV8DUqxAxtWpdnm88WSm/fRTNw26T1PfVXMFPoIV8nqQFP6fuekfLHr1Umqev7oTqi/E723ai18r+B2YDEURi1jSX/TbyQau6NUKmefnmWt1BopAj6c/zch09ZEQKaItExjlU28wCD2UjuPoM4fByjiP1nQtScgoy3vg591fqgWQxmE4GDJ4evVTvnD9YLyIPQCa+h9GevpyX3B/dwLvEL6EAhCQstuU2eIcu8HX2UqoT5+kmxGOLzkworQ2Pmeqm5dAH4jxQUYScYBt6P8K1ppBBi4c1rg/UtHUMz3h/tVNtWkFblelHJJgujr0CCnElUzC0m9c0dfB+wi8493U6O3xXsvFRtucKy0O0Vm+Y7+wPAJPKfP8D11KOLBd/HgnbrdZqGhmAI1PGjQOlWN2d0zqm5B7ikROQkqyKFr2uGLw0NFYPVkCJp1vZQVlF3ti3/0BXavAT2tR2j4yLVM8rltdBeANVmxl7SjyD5conxoa1JKayaHUCb+3RzZN8auotz2j4AjyGXGBQKJ4RLYjhnfRYr6gRhfl9juYnI459jTN0fnRrRR1VCbyJWnHjGwQTRbprAlsTxkiy1tlnmqkLU8H0p0/+i6V0lBmvgJD7gs0KLEuOhPobKGxF9CyEJ2Mg8YcLlU6cp/D8ndohr+QacFuavARkF9CDX6gzkCR7+zr3wMe8+3E=
X-MS-TrafficTypeDiagnostic: CPYP284MB0690:EE_
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	PsVSO4cj87QBaMqspJ2OSB/4wEugOEG0kiWUtXtXCnlzfLaHtuPSwHSbH+B20v8Bb+xUc5qNHk/VU0cq85iIAchy08R0Y0Ea60I/QlS6zaBH1uTcBO5QFpJ80ASf2xIVV5dj5f0tmS7A9hHoHfV5Yy6ecIVJYeJutVrcH3+8Xe4958j1rP6xjA6sAsr6ASsF4jP+jp6VKl8gRd+RnM55fudAN3muvxrlZUECaimdoRAU5NcxLrsLE5yYHLlM7aul+sS75I+rX6Ngs2Jze/Lm3Q2zg5bOebo4HAhQ8ckUo0TNob4iGEATxhr4AB9fxJztdK/FAlKJZqxA3NJ2ODcRhv8TgFv4wHL4bdXGsJT7S08437rm921SEyp7QAqgSBCmIfLxCH966InDo5XuGjkwwq/md3s2uFuJEKNXD//gla3bU3LJ1jxV/zdmsUosvfpfRrGW/zF115Ty3ZlbfRnJH5xOTAvs+InMT1qBSNDEyKGihuT1c303gi9ONpCRvRrMc4Vv/vZAUNm91RlRvzwoHxb4KL2/urg9WUzE+a1uO3ZEcvKWAwpOqiQeU8yUE1xUHtBoN5bjkbLi4w/P+SizeWW9ST0kLSngj9GGBH2SGmN+w5jgP8T01FcayO3Pp8ttHnnFAtVzOlQe8lCRc3pwfLQigh+7pV9Q8h2gSOqDsbDvC42GAO2qNgd8DSValVmb
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?oMnC0JR27ETI2um0Dqer56Ny+YyzAj3oLwsGlu9ZsAGisNYHtpuFJYDriMb1?=
 =?us-ascii?Q?0JRh6jfDDLYl2JJWJV4Nyc/v5IRw8gEda68ITCkY3fJH6zy0HjSgQ6qxmdJL?=
 =?us-ascii?Q?d4y0ilncc0oLFKtQh/Ey93n50SnObAUDgyZF9tB3WX4g9w1d9R2yNFwMwnZL?=
 =?us-ascii?Q?iDEoge4rsAtAhAyQwHszdaVqtK99Zx9g96AOQ1KNAp04yvX2HHWxMzfXPvnf?=
 =?us-ascii?Q?2wOxx9igdPJ9w8vzxu5d/etfmgQGNsQ9/onGue7rJubhAEcaRDxVjsYr7Qil?=
 =?us-ascii?Q?vRCd1iLyhaJwQKOjZjkg5nYKx1YwoUe4wy4UNDsjusvpYPZlLeaCRbxAVawB?=
 =?us-ascii?Q?Ja3o0mJV9df98uRDQoHqm8XWs4Th4sOP4ZDWHwifh7LIZWe5WCRHeU0Y2DuK?=
 =?us-ascii?Q?CTG0OunY7nB9rWu456X0pQzKo5u1IR6MMFfoxb9vjHmIrewAqkSKaM5/8fRy?=
 =?us-ascii?Q?j0AGuq5/be9KUSLs5nrYjtDOJSU4uiy+HMtUAreGUKTTmF5RpB4ILZ1nY/DX?=
 =?us-ascii?Q?1fey4S40r1l80Ed5r2o3mTDPaLLfbaqu2ssGLaBWSS02wTXUUhtfCA5kLdEQ?=
 =?us-ascii?Q?l0Zfc0zw0fDtuhpLyqMWe+gzPLl6rAYTkmPwMWqac2gVJlQVf/+KFMb8enSu?=
 =?us-ascii?Q?sFB8zXwM+Vd2rA3f8xUz5znvAvLhfdguA+huhXMtjRNtHu0EuRw3Y5XaOODF?=
 =?us-ascii?Q?7T4YGzCFbWeuVHhMAzZ5Z1roQZzKYgQ1eo7TqAUzaSd4E52MuQ8faD9rVgfr?=
 =?us-ascii?Q?ycTf1jBXfRmDEmiIdRYCJ5zuXUXceygvR1chJDeZ6wMExnQtJ/ASO5yMaGkg?=
 =?us-ascii?Q?4Ll4jn6XQ3k9pJ05v8nQalgxiRnZz1AmSXyaTpay0buYbnCjfPtNBqgbL/lf?=
 =?us-ascii?Q?X3bIPToUfgAZ62OlGETWgkgi1rhmqXlKO1WJ5Pi1sAeG7jN4r02yfYLXznB3?=
 =?us-ascii?Q?X7plA1qkoKVRw5dFgwJYKI9Cakx04nVlAeYiZNq0w6bYc3vp5dCUDASLPZ7D?=
 =?us-ascii?Q?reYwcY8nkMkdapIes+V2+lSyzERSHtU66h+zsXaff9ZDJdtP1LXgoX93KbEH?=
 =?us-ascii?Q?1/HWi9Ih1phSzZTC9ZHQ602Cs91fEx1eSA4gylRarXPT+J8p2W0I3SZLzvx9?=
 =?us-ascii?Q?qFBGSubLRK4gTx5lyBDjAeE1xQchfJTMsY6cXhh9+u3cawsXK4Hq1rpFoEvr?=
 =?us-ascii?Q?x6rwRsjPs4Y2bjKt3fQT0WhT1bJX4mOq5uGL17wxJyhe4PYcyetEDNDQrH5n?=
 =?us-ascii?Q?QKPuQCYGvczzQXlTb14bqRHGXWfxL3skDpbqnqf+7w=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 010bc86f-5386-4a6f-60be-08da70110105
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2022 20:45:56.6181
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPYP284MB0690
X-Rspamd-Queue-Id: 4LtQm85Ctlz3Wld
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=ZAnHwcED;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.45 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.65 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_SHORT(-0.99)[-0.989];
	NEURAL_HAM_LONG(-0.90)[-0.899];
	NEURAL_HAM_MEDIUM(-0.76)[-0.765];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[hotmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.45:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FREEMAIL_FROM(0.00)[hotmail.com];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N



On Wed, 27 Jul 2022, Ivan Quitschal wrote:

>
>
> On Tue, 26 Jul 2022, Tomoaki AOKI wrote:
>
>> On Tue, 26 Jul 2022 10:30:25 -0700
>> Chris  wrote:
>> 
>>> On 2022-07-26 10:29, Chris wrote:
>>>> On 2022-07-22 08:27, Ivan Quitschal wrote:
>>>>> hi all
>>>>> 
>>>>> Ive been trying to solve a problem which is happening to me but so far 
>>>>> no
>>>>> success.
>>>>> problem is this:
>>>>> 
>>>>> sometimes happens, sometimes doesnt, but once im on X and do a "F2", 
>>>>> "F3"
>>>>> whatever
>>>>> in order to get back to terminal, it *does* get back to terminal but the
>>>>> screen
>>>>> still shows like i was on X, therefore i have to do a F* twice in order 
>>>>> to
>>>>> see the
>>>>> console , like an fflush was missing somewhere.
>>>> If I'm following you correctly; you should be performing a 
>>>> Ctrl+Atl+F<1-8>
>>>> to
>>> TYPO sorry. That *should* have read: Ctrl+Alt+F<1-8>
>> 
>> ...and Alt+F<1-8> to switch vtys afterwards.
>> To get back to X, Alt+F9.
>> 
>> You need Ctrl+ only on X, and does not work with Ctrl+ on vty<1-8>.
>> 
>> 
>>> 
>>> Sorry.
>>>> accomplish your goal. Does doing it that way fix it for you?
>>>> 
>>>> HTH
>>>> 
>>>> --Chris
>>>>> 
>>>>> im using the drm-devel-kmod git for i915kms.ko btw
>>>>> 
>>>>> any ideas what could it be?
>>>>> 
>>>>> thank you guys
>>>>> 
>>>>> --tzk
>> 
>> 
>> -- 
>> Tomoaki AOKI    
>> 
>
> hi
>
> no gyuys, i know how to go back from X to terminal, what i was saying is that 
> by doing CTRL + ALT + F* it wasnt working until i did *another* 
> CTRL+ALT+F.
>
> example:
> im getting off from X , so i do an CTRL+ALT+F2
>
> nothing happens, until you do *another* CTRL+ALT+F3 . so you gotta do a 
> CTRL+ALT+F* twice in order to get back to terminal
>
> but i found out the problem lies within enlightenment themes, not anything 
> else .
> at least the problem is  solved by changing EE theme, this way i can get back 
> instantly to terminal with just ONE CTRL+ALT+F2
>
> thanks
>
> Ivan
>


btw, there is something i always wanted to ask, why do we have just 9 terminals?
im really asking , never understood that

in my case here , im using all F* keys

my /etc/ttys

ttyv0   "/usr/libexec/getty Pc"         xterm   onifexists secure
# Virtual terminals
ttyv1   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv2   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv3   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv4   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv5   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv6   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv7   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv8   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv9   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyva   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyvb   "/usr/local/bin/xdm -nodaemon"  xterm   off secure


my F-key dedicated to get back to X is F12 , as it should be IMO. question is , 
why isnt it yet?

im sure there is a reason, just curious because honestly i got no idea 
whatsoever

--tzk

From nobody Wed Jul 27 21:54:06 2022
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 4LtSH46xRcz4XqKY
	for ; Wed, 27 Jul 2022 21:54:24 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LtSH40kf3z3cTY
	for ; Wed, 27 Jul 2022 21:54:24 +0000 (UTC)
	(envelope-from 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 26RLs7EE081132;
	Wed, 27 Jul 2022 14:54:13 -0700 (PDT)
	(envelope-from bsd-lists@bsdforge.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
Date: Wed, 27 Jul 2022 14:54:06 -0700
From: Chris 
To: Ivan Quitschal 
Cc: Tomoaki AOKI , freebsd-current@freebsd.org
Subject: Re: from X to terminal needs an fflush
In-Reply-To: 
References: 
 
 
 <20220727072737.53528f96e08c7a3390e49170@dec.sakura.ne.jp>
 
 
User-Agent: UDNSMS/17.0
Message-ID: 
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_e799aa71d906235d15886bf6cd29efea"
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4LtSH40kf3z3cTY
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-Spamd-Result: default: False [0.00 / 15.00];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_e799aa71d906235d15886bf6cd29efea
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-07-27 13:45, Ivan Quitschal wrote:
> On Wed, 27 Jul 2022, Ivan Quitschal wrote:
> 
>> 
>> 
>> On Tue, 26 Jul 2022, Tomoaki AOKI wrote:
>> 
>>> On Tue, 26 Jul 2022 10:30:25 -0700
>>> Chris  wrote:
>>> 
>>>> On 2022-07-26 10:29, Chris wrote:
>>>>> On 2022-07-22 08:27, Ivan Quitschal wrote:
>>>>>> hi all
>>>>>> 
>>>>>> Ive been trying to solve a problem which is happening to me but so far 
>>>>>> no
>>>>>> success.
>>>>>> problem is this:
>>>>>> 
>>>>>> sometimes happens, sometimes doesnt, but once im on X and do a "F2", 
>>>>>> "F3"
>>>>>> whatever
>>>>>> in order to get back to terminal, it *does* get back to terminal but 
>>>>>> the
>>>>>> screen
>>>>>> still shows like i was on X, therefore i have to do a F* twice in order 
>>>>>> to
>>>>>> see the
>>>>>> console , like an fflush was missing somewhere.
>>>>> If I'm following you correctly; you should be performing a 
>>>>> Ctrl+Atl+F<1-8>
>>>>> to
>>>> TYPO sorry. That *should* have read: Ctrl+Alt+F<1-8>
>>> 
>>> ...and Alt+F<1-8> to switch vtys afterwards.
>>> To get back to X, Alt+F9.
>>> 
>>> You need Ctrl+ only on X, and does not work with Ctrl+ on vty<1-8>.
>>> 
>>> 
>>>> 
>>>> Sorry.
>>>>> accomplish your goal. Does doing it that way fix it for you?
>>>>> 
>>>>> HTH
>>>>> 
>>>>> --Chris
>>>>>> 
>>>>>> im using the drm-devel-kmod git for i915kms.ko btw
>>>>>> 
>>>>>> any ideas what could it be?
>>>>>> 
>>>>>> thank you guys
>>>>>> 
>>>>>> --tzk
>>> 
>>> 
>>> -- Tomoaki AOKI    
>>> 
>> 
>> hi
>> 
>> no gyuys, i know how to go back from X to terminal, what i was saying is 
>> that by doing CTRL + ALT + F* it wasnt working until i did *another* 
>> CTRL+ALT+F.
>> 
>> example:
>> im getting off from X , so i do an CTRL+ALT+F2
>> 
>> nothing happens, until you do *another* CTRL+ALT+F3 . so you gotta do a 
>> CTRL+ALT+F* twice in order to get back to terminal
>> 
>> but i found out the problem lies within enlightenment themes, not anything 
>> else .
>> at least the problem is  solved by changing EE theme, this way i can get 
>> back instantly to terminal with just ONE CTRL+ALT+F2
>> 
>> thanks
>> 
>> Ivan
>> 
> 
> 
> btw, there is something i always wanted to ask, why do we have just 9 
> terminals?
> im really asking , never understood that
> 
> in my case here , im using all F* keys
> 
> my /etc/ttys
> 
> ttyv0   "/usr/libexec/getty Pc"         xterm   onifexists secure
> # Virtual terminals
> ttyv1   "/usr/libexec/getty Pc"         xterm   onifexists secure
> ttyv2   "/usr/libexec/getty Pc"         xterm   onifexists secure
> ttyv3   "/usr/libexec/getty Pc"         xterm   onifexists secure
> ttyv4   "/usr/libexec/getty Pc"         xterm   onifexists secure
> ttyv5   "/usr/libexec/getty Pc"         xterm   onifexists secure
> ttyv6   "/usr/libexec/getty Pc"         xterm   onifexists secure
> ttyv7   "/usr/libexec/getty Pc"         xterm   onifexists secure
> ttyv8   "/usr/libexec/getty Pc"         xterm   onifexists secure
> ttyv9   "/usr/libexec/getty Pc"         xterm   onifexists secure
> ttyva   "/usr/libexec/getty Pc"         xterm   onifexists secure
> ttyvb   "/usr/local/bin/xdm -nodaemon"  xterm   off secure
> 
> 
> my F-key dedicated to get back to X is F12 , as it should be IMO. question 
> is ,
> why isnt it yet?
> 
> im sure there is a reason, just curious because honestly i got no idea 
> whatsoever
ttys(5) is fairly informative and less /etc/ttys has some info. But I can't 
remember
the history on why 9 was the default. The SUN || terminal keyboard mapping, 
maybe?

--Chris
> 
> --tzk

--=_e799aa71d906235d15886bf6cd29efea
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_e799aa71d906235d15886bf6cd29efea--

From nobody Wed Jul 27 22:09:56 2022
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 4LtSdF33d1z4XsSW
	for ; Wed, 27 Jul 2022 22:10:09 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LtSdD2X54z3dyX
	for ; Wed, 27 Jul 2022 22:10:08 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe30.google.com with SMTP id b67so27285vsc.1
        for ; Wed, 27 Jul 2022 15:10:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=uYwOumUJXKLFGELiin/IGHns/IJlYXel+qqQAnYrVkA=;
        b=Az1AD+XFlNvFztfcydmlEoCjU33uSId5NO6XS7ZZxTOqhgZe2BQBtFC2O2FFFlNbcu
         RSScTkK1TJy9GnlMU24MjtE6yHMImpgs2yybAVLkwVYxbWcPZd+jk4/IixYAH5kI9u81
         Cx45T1hnGh+Chr7GeQdHfLra1jhS/IuMTzHHwLahlEuN6AbLW7zNBwcCpFagv8nuLw2v
         jFN6IOZ2jm3nP/eWCkEksQp2XVNruG3g8/QmK/4Y49CzgaztU48CyVo8JMG1VnxtmuqY
         cpdQ9lQ3XqJoZwJoVhCuZc50YkK7x4/vNEFlYiS7hIOxmm0VKQRqibcLUWqzxWQo0okS
         5ecQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=uYwOumUJXKLFGELiin/IGHns/IJlYXel+qqQAnYrVkA=;
        b=s2k8I6z4SOTOSdqlvMMiZpJeusiIDe+uZ9JbtX/3rAGgrkERhx6R6WoxYql2VCTkGZ
         TF/uSxrKXAtrjE0ipfYYYZ9wEskdiJEBVAOy5kP90aBe/yeJSyyYnvKzL+KiBh+TNZSQ
         KBgZCP0UU+Hw9tFtlNKOOAALRv4zIP/T+3lZkmtxbDOicLA3aZl2WI8O2o21cgMpfKU2
         cbNqtkQFPLOKcv7EToFs8WU8wLEve7TmEovpmAj2qrE5NatfHTUEoF8+zNNENXD7OEA0
         uWyCxX69HB1R+37TXGFc4+xKfvbyqIJAN2KilcONIX3vEJ2xbkWYj52VZv3UeRV0xA4Q
         29wg==
X-Gm-Message-State: AJIora+EQqOBGRqd1mCYEfAtU4ARZQ1urRGQXnvwZ5r629nn92ZkpNEF
	9q/h0/YhsxxiHjHenuw7jIZt2MyhqJCbPjSY90GA5A==
X-Google-Smtp-Source: AGRyM1vbNPZ50QSnBDws+qPf1PKVHGVQTlEKxna62OBumfDw1LN9YDN9L4GEffeZ3QPJQ24HHz8WPOQeLKne6Z7PQ6g=
X-Received: by 2002:a67:ab02:0:b0:356:51a5:993e with SMTP id
 u2-20020a67ab02000000b0035651a5993emr7654659vse.12.1658959807296; Wed, 27 Jul
 2022 15:10: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
References: 
  
 <20220727072737.53528f96e08c7a3390e49170@dec.sakura.ne.jp>
 
 
 
In-Reply-To: 
From: Warner Losh 
Date: Wed, 27 Jul 2022 16:09:56 -0600
Message-ID: 
Subject: Re: from X to terminal needs an fflush
To: Chris 
Cc: Ivan Quitschal , Tomoaki AOKI , 
	FreeBSD Current 
Content-Type: multipart/alternative; boundary="00000000000002d52505e4d0aea5"
X-Rspamd-Queue-Id: 4LtSdD2X54z3dyX
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Az1AD+XF;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e30) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e30:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[hotmail.com,dec.sakura.ne.jp,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000002d52505e4d0aea5
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 27, 2022 at 3:54 PM Chris  wrote:

> On 2022-07-27 13:45, Ivan Quitschal wrote:
> > On Wed, 27 Jul 2022, Ivan Quitschal wrote:
> >
> >>
> >>
> >> On Tue, 26 Jul 2022, Tomoaki AOKI wrote:
> >>
> >>> On Tue, 26 Jul 2022 10:30:25 -0700
> >>> Chris  wrote:
> >>>
> >>>> On 2022-07-26 10:29, Chris wrote:
> >>>>> On 2022-07-22 08:27, Ivan Quitschal wrote:
> >>>>>> hi all
> >>>>>>
> >>>>>> Ive been trying to solve a problem which is happening to me but so
> far
> >>>>>> no
> >>>>>> success.
> >>>>>> problem is this:
> >>>>>>
> >>>>>> sometimes happens, sometimes doesnt, but once im on X and do a
> "F2",
> >>>>>> "F3"
> >>>>>> whatever
> >>>>>> in order to get back to terminal, it *does* get back to terminal
> but
> >>>>>> the
> >>>>>> screen
> >>>>>> still shows like i was on X, therefore i have to do a F* twice in
> order
> >>>>>> to
> >>>>>> see the
> >>>>>> console , like an fflush was missing somewhere.
> >>>>> If I'm following you correctly; you should be performing a
> >>>>> Ctrl+Atl+F<1-8>
> >>>>> to
> >>>> TYPO sorry. That *should* have read: Ctrl+Alt+F<1-8>
> >>>
> >>> ...and Alt+F<1-8> to switch vtys afterwards.
> >>> To get back to X, Alt+F9.
> >>>
> >>> You need Ctrl+ only on X, and does not work with Ctrl+ on vty<1-8>.
> >>>
> >>>
> >>>>
> >>>> Sorry.
> >>>>> accomplish your goal. Does doing it that way fix it for you?
> >>>>>
> >>>>> HTH
> >>>>>
> >>>>> --Chris
> >>>>>>
> >>>>>> im using the drm-devel-kmod git for i915kms.ko btw
> >>>>>>
> >>>>>> any ideas what could it be?
> >>>>>>
> >>>>>> thank you guys
> >>>>>>
> >>>>>> --tzk
> >>>
> >>>
> >>> -- Tomoaki AOKI    
> >>>
> >>
> >> hi
> >>
> >> no gyuys, i know how to go back from X to terminal, what i was saying
> is
> >> that by doing CTRL + ALT + F* it wasnt working until i did *another*
> >> CTRL+ALT+F.
> >>
> >> example:
> >> im getting off from X , so i do an CTRL+ALT+F2
> >>
> >> nothing happens, until you do *another* CTRL+ALT+F3 . so you gotta do a
> >> CTRL+ALT+F* twice in order to get back to terminal
> >>
> >> but i found out the problem lies within enlightenment themes, not
> anything
> >> else .
> >> at least the problem is  solved by changing EE theme, this way i can
> get
> >> back instantly to terminal with just ONE CTRL+ALT+F2
> >>
> >> thanks
> >>
> >> Ivan
> >>
> >
> >
> > btw, there is something i always wanted to ask, why do we have just 9
> > terminals?
> > im really asking , never understood that
> >
> > in my case here , im using all F* keys
> >
> > my /etc/ttys
> >
> > ttyv0   "/usr/libexec/getty Pc"         xterm   onifexists secure
> > # Virtual terminals
> > ttyv1   "/usr/libexec/getty Pc"         xterm   onifexists secure
> > ttyv2   "/usr/libexec/getty Pc"         xterm   onifexists secure
> > ttyv3   "/usr/libexec/getty Pc"         xterm   onifexists secure
> > ttyv4   "/usr/libexec/getty Pc"         xterm   onifexists secure
> > ttyv5   "/usr/libexec/getty Pc"         xterm   onifexists secure
> > ttyv6   "/usr/libexec/getty Pc"         xterm   onifexists secure
> > ttyv7   "/usr/libexec/getty Pc"         xterm   onifexists secure
> > ttyv8   "/usr/libexec/getty Pc"         xterm   onifexists secure
> > ttyv9   "/usr/libexec/getty Pc"         xterm   onifexists secure
> > ttyva   "/usr/libexec/getty Pc"         xterm   onifexists secure
> > ttyvb   "/usr/local/bin/xdm -nodaemon"  xterm   off secure
> >
> >
> > my F-key dedicated to get back to X is F12 , as it should be IMO.
> question
> > is ,
> > why isnt it yet?
> >
> > im sure there is a reason, just curious because honestly i got no idea
> > whatsoever
> ttys(5) is fairly informative and less /etc/ttys has some info. But I
> can't
> remember
> the history on why 9 was the default. The SUN || terminal keyboard
> mapping,
> maybe?
>

The default has 8 terminals (v0 - v7) with xdm running on v8. The great
syscons
rewrite of 1999 set MAXCONS to 16, but it was 16 before the rewrite.
Digging further
we see it was 3 in 1998 when ttys was moved to etc/etc.i386, but later
expanded to 8
in July of 1999 by des with the explanation "Feed the vty monster".

tl;dr: Meh, 8 seems good, since 3 was too few.

Warner

--00000000000002d52505e4d0aea5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Jul 27, 2022 at 3:54 PM Chris=
 <bsd-lists@bsdforge.com&g=
t; wrote:
On 202=
2-07-27 13:45, Ivan Quitschal wrote:

> On Wed, 27 Jul 2022, Ivan Quitschal wrote:

> 

>> 

>> 

>> On Tue, 26 Jul 2022, Tomoaki AOKI wrote:

>> 

>>> On Tue, 26 Jul 2022 10:30:25 -0700

>>> Chris <bsd-lists@bsdforge.com> wrote:

>>> 

>>>> On 2022-07-26 10:29, Chris wrote:

>>>>> On 2022-07-22 08:27, Ivan Quitschal wrote:

>>>>>> hi all

>>>>>> 

>>>>>> Ive been trying to solve a problem which is happen=
ing to me but so far 

>>>>>> no

>>>>>> success.

>>>>>> problem is this:

>>>>>> 

>>>>>> sometimes happens, sometimes doesnt, but once im o=
n X and do a "F2", 

>>>>>> "F3"

>>>>>> whatever

>>>>>> in order to get back to terminal, it *does* get ba=
ck to terminal but 

>>>>>> the

>>>>>> screen

>>>>>> still shows like i was on X, therefore i have to d=
o a F* twice in order 

>>>>>> to

>>>>>> see the

>>>>>> console , like an fflush was missing somewhere.
>>>>> If I'm following you correctly; you should be perf=
orming a 

>>>>> Ctrl+Atl+F<1-8>

>>>>> to

>>>> TYPO sorry. That *should* have read: Ctrl+Alt+F<1-8>=


>>> 

>>> ...and Alt+F<1-8> to switch vtys afterwards.

>>> To get back to X, Alt+F9.

>>> 

>>> You need Ctrl+ only on X, and does not work with Ctrl+ on vty&=
lt;1-8>.

>>> 

>>> 

>>>> 

>>>> Sorry.

>>>>> accomplish your goal. Does doing it that way fix it fo=
r you?

>>>>> 

>>>>> HTH

>>>>> 

>>>>> --Chris

>>>>>> 

>>>>>> im using the drm-devel-kmod git for i915kms.ko btw=


>>>>>> 

>>>>>> any ideas what could it be?

>>>>>> 

>>>>>> thank you guys

>>>>>> 

>>>>>> --tzk

>>> 

>>> 

>>> -- Tomoaki AOKI=C2=A0 =C2=A0 <junchoon@dec.sakura.ne.jp>

>>> 

>> 

>> hi

>> 

>> no gyuys, i know how to go back from X to terminal, what i was say=
ing is 

>> that by doing CTRL + ALT + F* it wasnt working until i did *anothe=
r* 

>> CTRL+ALT+F<something>.

>> 

>> example:

>> im getting off from X , so i do an CTRL+ALT+F2

>> 

>> nothing happens, until you do *another* CTRL+ALT+F3 . so you gotta=
 do a 

>> CTRL+ALT+F* twice in order to get back to terminal

>> 

>> but i found out the problem lies within enlightenment themes, not =
anything 

>> else .

>> at least the problem is=C2=A0 solved by changing EE theme, this wa=
y i can get 

>> back instantly to terminal with just ONE CTRL+ALT+F2

>> 

>> thanks

>> 

>> Ivan

>> 

> 

> 

> btw, there is something i always wanted to ask, why do we have just 9 =


> terminals?

> im really asking , never understood that

> 

> in my case here , im using all F* keys

> 

> my /etc/ttys

> 

> ttyv0=C2=A0 =C2=A0"/usr/libexec/getty Pc"=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0xterm=C2=A0 =C2=A0onifexists secure

> # Virtual terminals

> ttyv1=C2=A0 =C2=A0"/usr/libexec/getty Pc"=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0xterm=C2=A0 =C2=A0onifexists secure

> ttyv2=C2=A0 =C2=A0"/usr/libexec/getty Pc"=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0xterm=C2=A0 =C2=A0onifexists secure

> ttyv3=C2=A0 =C2=A0"/usr/libexec/getty Pc"=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0xterm=C2=A0 =C2=A0onifexists secure

> ttyv4=C2=A0 =C2=A0"/usr/libexec/getty Pc"=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0xterm=C2=A0 =C2=A0onifexists secure

> ttyv5=C2=A0 =C2=A0"/usr/libexec/getty Pc"=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0xterm=C2=A0 =C2=A0onifexists secure

> ttyv6=C2=A0 =C2=A0"/usr/libexec/getty Pc"=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0xterm=C2=A0 =C2=A0onifexists secure

> ttyv7=C2=A0 =C2=A0"/usr/libexec/getty Pc"=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0xterm=C2=A0 =C2=A0onifexists secure

> ttyv8=C2=A0 =C2=A0"/usr/libexec/getty Pc"=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0xterm=C2=A0 =C2=A0onifexists secure

> ttyv9=C2=A0 =C2=A0"/usr/libexec/getty Pc"=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0xterm=C2=A0 =C2=A0onifexists secure

> ttyva=C2=A0 =C2=A0"/usr/libexec/getty Pc"=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0xterm=C2=A0 =C2=A0onifexists secure

> ttyvb=C2=A0 =C2=A0"/usr/local/bin/xdm -nodaemon"=C2=A0 xterm=
=C2=A0 =C2=A0off secure

> 

> 

> my F-key dedicated to get back to X is F12 , as it should be IMO. ques=
tion 

> is ,

> why isnt it yet?

> 

> im sure there is a reason, just curious because honestly i got no idea=
 

> whatsoever

ttys(5) is fairly informative and less /etc/ttys has some info. But I can&#=
39;t 

remember

the history on why 9 was the default. The SUN || terminal keyboard mapping,=
 

maybe?

The default has 8 terminals (v0 =
- v7) with xdm running on v8. The great syscons
rewrite of 1999 s=
et MAXCONS to 16, but it was 16 before the rewrite. Digging further
we see it was 3 in 1998 when ttys was moved to etc/etc.i386, but later e=
xpanded to 8
in July of 1999 by des with the explanation "Fe=
ed the vty monster".

tl;dr: Meh, 8 seems good=
, since 3 was too few.

Warner


--00000000000002d52505e4d0aea5--

From nobody Thu Jul 28 15:23:43 2022
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 4LtvYp3Lb7z4X2x5
	for ; Thu, 28 Jul 2022 15:23:42 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88])
	(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 4LtvYm5XXGz488V;
	Thu, 28 Jul 2022 15:23:40 +0000 (UTC)
	(envelope-from ronald-lists@klop.ws)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=klop.ws;
	s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:
	Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=HSOKp4Ex7kUP6Mk03zJR3Uw6YsdNzhlgrd2b72vnU9Q=; b=CrcvojbNvLsjaWXOqlXqec2zWl
	rox3IP4AEhUJSzQHVC/AvCZsEcyx1lFPuJggaNVDO2IlbxS4SsJtTf9og7D8JTbvlYYSOmiLhSOBz
	dK9yvof8Va28VkKwImOKl8Poal95bFWy0uuV8H7S4Moahw9aJ2d52U9gTrULwzklEXVc=;
Message-ID: 
Date: Thu, 28 Jul 2022 17:23:43 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: pkg: Newer FreeBSD version for package... but why?
Content-Language: en-US
To: John Baldwin , Andriy Gapon ,
 Michael Gmelin 
Cc: current@freebsd.org
References: <81814ba9-5040-c102-dad4-0a69f3c46121@FreeBSD.org>
 <20220713120900.63cd5639.grembo@freebsd.org>
 
 <402cf119-b07e-76fd-48b6-50eeb9b4508f@FreeBSD.org>
From: Ronald Klop 
In-Reply-To: <402cf119-b07e-76fd-48b6-50eeb9b4508f@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Spam-Level: /
X-Spam-Score: -0.4
X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A autolearn=disabled version=3.4.2
X-Scan-Signature: 4b8baa00aa45d625c6ee6c23f4cb0de1
X-Rspamd-Queue-Id: 4LtvYm5XXGz488V
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=mail header.b=CrcvojbN;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws
X-Spamd-Result: default: False [-2.94 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	NEURAL_HAM_LONG(-0.95)[-0.945];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=mail];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	RCVD_COUNT_ZERO(0.00)[0];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[195.190.28.88:from];
	RCPT_COUNT_THREE(0.00)[4];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 7/13/22 20:33, John Baldwin wrote:
> On 7/13/22 3:17 AM, Andriy Gapon wrote:
>> On 2022-07-13 13:09, Michael Gmelin wrote:
>>>
>>>
>>> On Wed, 13 Jul 2022 10:29:06 +0300
>>> Andriy Gapon  wrote:
>>>
>>>> # uname -U
>>>> 1400063
>>>>
>>>> # uname -K
>>>> 1400063
>>>>
>>>> # pkg upgrade
>>>> Updating FreeBSD repository catalogue...
>>>> Fetching packagesite.pkg: 100%    5 MiB   4.8MB/s    00:01
>>>> Processing entries:   0%
>>>> Newer FreeBSD version for package zyre:
>>>> To ignore this error set IGNORE_OSVERSION=yes
>>>> - package: 1400063
>>>> - running kernel: 1400051
>>>> Ignore the mismatch and continue? [y/N]:
>>>>
>>>> Does anyone know why this would happen?
>>>> Where does pkg get its notion of the running kernel version?
>>>>
>>>
>>> If I'm reading the sources correctly, it's determining the OS version
>>> by looking at the elf headers of various files in this order:
>>>
>>>       getenv("ABI_FILE")
>>>       /usr/bin/uname
>>>       /bin/sh
>>>
>>> So I would assume that `file /usr/bin/uname` shows 1400051 on your
>>> system.
>>
>> Thank you very much!  That's it:
>> # file /usr/bin/uname
>> /usr/bin/uname: ELF 32-bit LSB executable, ARM, EABI5 version 1
>> (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1,
>> FreeBSD-style, for FreeBSD 14.0 (1400051), stripped
>>
>>> You can point it to checking another file by setting ABI_FILE[0] in the
>>> environment or ignore the check by setting IGNORE_OSVERSION (like
>>> advised). The "running kernel:" label seems a bit misleading.
>>
>> Indeed.
>>
>> Now the next thing (for me) to research is why the binaries were built
>> "for FreeBSD 14.0 (1400051)" when the source tree has 1400063 and uname
>> -U also reports 1400063.
>> FWIW, this was a cross-build, maybe that played a role too.
> 
> If you do a NO_CLEAN=yes build, we don't relink binaries just because
> crt*.o changed (where the note is stored).
> 


Why does pkg not look at the same thing as "uname -U" looks at?

Regards,
Ronald.

From nobody Thu Jul 28 19:09:17 2022
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 4Lv0Z95Y56z4Xd2s
	for ; Thu, 28 Jul 2022 19:09:21 +0000 (UTC)
	(envelope-from markshank@aol.com)
Received: from sonic315-21.consmr.mail.ne1.yahoo.com (sonic315-21.consmr.mail.ne1.yahoo.com [66.163.190.147])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lv0Z858czz3cHK
	for ; Thu, 28 Jul 2022 19:09:20 +0000 (UTC)
	(envelope-from markshank@aol.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1659035359; bh=8RWkT/xxlmyB2Nb6UZVqmLe7rlb4RDtylmIJsvKqq/4=; h=Date:From:Reply-To:To:Subject:References:From:Subject:Reply-To; b=YTvSLBqywh+h/lVJUMkF25AZCAEgI9NPV2zm+2qGS5LTaVWvE2kU28pXTKQmbFjZZkpbB7gNgpmQ6uCOrSIBygCqpy+uv+K8CUW2w5pU8Zp5d5Z6fmcV/vxfPaggFOCblaX/VVHr1LCOiVU/y5cEazNpQc61VkQ+DUCpEQjEUTm9G5ltt0gTb6aceCUdRjKjl1LVCLzYd+YQBm044ECTSBgdgsD6htKfbBTV3Amkkt2khw/69b5S/fFBYlCnkau/IZhUloWxq0czPjg3H+eTmwFla8QnUEt+gkbK/AEdOy73og5EL3RCTNEMPwzICIPY+rfwWwlVVneKaPRWNKYOUQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659035359; bh=2ybjq3lA9fFssTNd3hCKX7YW3ze+HZ5HRxJhd08avuf=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=ARgv6PmQXNkZBw95xyvDFcr1AcQHSfuoS2eoIwVif/yklVfVL+gVdlSnQjnHBI1i6pF6lvm0uOI4JZAx4Pl37rLPCOp0xeL6M4yEKz4o+9Y6RMcVCGV2oH9iU520Zr+vjtjj9MVT1NmKhYynE78fBCr7kyxi7w+0wQdmQbeVZpm5sRQSTn7WG7cGSI+NilUPzLM6WuJ0g9qM9MKe5TKFajq+4eDRr4QoII0jCpEj+ksJsfBzVstoZA4eEUWVMWGM1ovckRS5YezZlH5nJ0L2mEcpaJM270pm6nuAprxqllgvYjC9En/IZVwX0/efXkRT8YVf6xqn9zksfdAykmIHjg==
X-YMail-OSG: Br5hh3YVM1kI7b1iKCmE2GrK264Ak8osMFM2l6JWQ3zNKi64R.0LxPVZtaHY_W.
 KBydAe__C7MG2po9MLTsShGgc1ITrvwIZxfhW17q8gFV0jmmKJrd7Kz7vbRwRFWGauMe26IPABk_
 KzGHWZVZ7SHrForveY.POjTJZrDr4mi1uP65llvUo2REUkGayesNdicsHQyCOcgsxiRHnOKllnZ0
 PWyPM.3pG.2_vnQIRAhyLXBxWzObu9_NqFz4W..HQ8VkmXbUkDcmY25XgCKvhDjcs7Ijf2VKufFD
 bZQu7.PHCG2qS_AOf_AUeuUFQTmu2lj6A0__LCE4zOTyW_Szq3wkUmoA1LW6bGIVLwHGhGzP5Bq4
 d705SlYqHLEo8wjw5GvO4U4_6UhpoHzJki9dMT3mxo5.d_Suz3M1yBOg39f4hXyYNjTSHEgh6Swl
 PI1gxIbsfwvsx_GS.B6l0JC3xIucgb71f0iiZ7skp4YuOxkw_BSNkFLY2vmS99vVN83oQeMkVxYS
 pkZZibtvbO23hI9Aq.FTBbQtKiiJ7kkCwAw.CoIybcyya3KlCqdbCYa.qAiRArDHo7qecEVwJsZI
 FsjakLq6TWYZ8kH8tW3CvVY7O3l4bVnToJGi022HV3w4NHJQuQkXuGdEEeeJVkLg8xTblBXse83x
 qL0n.0X2JFl1p13WN.naqi1RnaZDLTC27rPyHb0FAt1L03xAGy_du6c5VGHPUSxO_VetIYERxcKS
 5iYigSAWH1tyJVIW6OvU7qnAgNZDA4JWZZIFUMlMPFYQvSZGOfC2iq.ZbsjkVXwxHzilFsQ983Dv
 s610ihdBRi4xmu0gI6sgy70hbQIc2r22WhvjlxrzSWMC2FOUmMYtrWT.vSE381dlTwU8O21yvaFV
 1eqN3A4.QepSXeq4whtV9U3PHh6.eeGRKQpfY24kOLlsE0gNLLYZVxc_b6z1QX7nKCPczwn30oLj
 TI8rktchYPCrifz9RYXU7pFVWtf2i7eMOI8urns8HDSLl1n_1w260AspOs0y0fU5njmXsI36cJJN
 _1Z1A8BjKVK7pJwQd7JxuRrmAJBPy31_NiiENrYEOSvN4EwAkCND4Jg2.KyEkJMIwnccwQLXRkh7
 lWQqvThXH0Uxf.dzcBHJrAsGjm2nTT7I5U.6T6C0meJn7X_cGuzVahZBdSVZ6UpkI.aRwO2onkM8
 cIY4Xb13IwPkZI033Wm61Lo0LrTaU1cahL.NEpvJfx2pUuImIC9o0KTFGzRsaPPXrC8QdW0RANfd
 m10a1JyUCPEG9bIKJrzUFLDV6.XpokAwBAznzBLxXuqLdhJ0mHNbrlq3DmrNnhrtUmgKu2OeDPXT
 ntll_mUzLo09GbCHR7nfxdGEYvKUlkTm7qKfYV3WKSGRXTsC5PXoQEeXvyb7Un0mt1p_f5fJdwgR
 d_6GU5DOpgIw1Vbu6Tb4Mb3WcoWg.qLRXZeNWtiJGbKed8107K3ZH5BUxpCoSgY0gzB15rCWmUm9
 LikqWGAmJJIyj5XKXMMZQSmN.CWA8MZ.hsMowxGSQ7LU6DmR_dfioKm_jhUfWHQjJ5JQfvtswDTp
 vlrptDdfRf9OLOszsQxVeAHRbntPP33VT4HxavX8sX3qiDyGiOubKU8VGCtlZtyVWZ871sYlWI44
 77guAz81o3k9QxAn6xX4QcLepSGMG4HUcl1coG88hKTR0zW6EuVwygIOmja2RgsZhSpGvRz19D2E
 k1GiyfdBBTv3M4pVBXVpMmfanmV8ThNKehsB3Xkn.bebl9bp0.h3pQ_DAlI9ZssXtQJ2eyjBpV3H
 rKsW1duB.4cqfC4B0o9.4Vv5MBbKiYCb2HigpqnWQixMgkq4kLkbUPFdwJlhcKP7eE6oiQuzadPT
 wJFeqJV_XrZULW4KN83hmfhuICAQ1NHwQKZ6IX523IAZ5WOzg4fU4PJtCdzKD79CNo.qmyrGH0Ob
 VxB5TyXYJ1gO8Iovw2gx_AlnnNr9h.Oqh8iLxuT62DEyTRE0Y2GFjrAzSXzzs2QsiOnsBXiIczcc
 hbM9lwGEprzg8M.Ei1BUwQAfLD6MDl_Jb2HNgu9e5ssdgeKX0jfKB73W2JTF8JcnxIgJaL0hp8HZ
 WqrJ5SnO.Hf59eEV183AafgIe3FtlzaaXQr3bM4pn3eJSKeqCnm6e1e8hV9ckMi6kd_ZaqZS9SE4
 S7Iw7HcslmJ0fi0K0ysFEUAIy07K8kSgxBst44bGZKcjHv86xMAhhtORoQEjSyKMjKUZ9WZMUrgU
 _b3n8Ollk
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Thu, 28 Jul 2022 19:09:19 +0000
Date: Thu, 28 Jul 2022 19:09:17 +0000 (UTC)
From: markshank@aol.com
Reply-To: markshank@aol.com
To: "freebsd-current@FreeBSD.org" 
Message-ID: <1977670882.3537201.1659035357936@mail.yahoo.com>
Subject: Intel GVT-g virtual machine guest with FreeBSD-14.0-CURRENT fails
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_3537200_1169446424.1659035357928"
References: <1977670882.3537201.1659035357936.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.20447 aolwebmail
X-Rspamd-Queue-Id: 4Lv0Z858czz3cHK
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=aol.com header.s=a2048 header.b=YTvSLBqy;
	dmarc=pass (policy=reject) header.from=aol.com;
	spf=pass (mx1.freebsd.org: domain of markshank@aol.com designates 66.163.190.147 as permitted sender) smtp.mailfrom=markshank@aol.com
X-Spamd-Result: default: False [-1.63 / 15.00];
	NEURAL_HAM_SHORT(-0.95)[-0.953];
	NEURAL_SPAM_MEDIUM(0.70)[0.701];
	DMARC_POLICY_ALLOW(-0.50)[aol.com,reject];
	NEURAL_HAM_LONG(-0.38)[-0.382];
	R_DKIM_ALLOW(-0.20)[aol.com:s=a2048];
	R_SPF_ALLOW(-0.20)[+ip4:66.163.184.0/21];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_REPLYTO(0.00)[aol.com];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_IN_DNSWL_NONE(0.00)[66.163.190.147:from];
	TO_DN_EQ_ADDR_ALL(0.00)[];
	FROM_NO_DN(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	HAS_REPLYTO(0.00)[markshank@aol.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.190.147:from];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[aol.com:+];
	FREEMAIL_FROM(0.00)[aol.com];
	REPLYTO_EQ_FROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[aol.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_3537200_1169446424.1659035357928
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Created a libvirt virtual machine on an=C2=A0ubuntu-22.04-desktop-amd64 hos=
t=C2=A0following this tutorial:https://blog.tmm.cx/2020/05/15/passing-an-in=
tel-gpu-to-a-linux-kvm-virtual-machine/

With the exception that it was UEFI instead of SeaBIOS by using the workaro=
und described here:https://wiki.archlinux.org/title/Intel_GVT-g#Using_DMA-B=
UF_with_UEFI/OVMF

Tested it with ubuntu-22.04-desktop-amd64.iso Live CD to verify that it wor=
ked.
Installed=C2=A0FreeBSD-14.0-CURRENT-amd64-20220722-8f733dabcc3-256882-disc1=
.iso guest on same virtual machine.
Installed a desktop environment following these instructions:https://freebs=
dfoundation.org/freebsd-project/resources/installing-a-desktop-environment-=
on-freebsd/

Does not display desktop.
Is there a newer version of any of the components that I could test?
mds@freebsd14:~ $ dmesg | grep drmdrmn0:  on vgapci0vgapci0: child dr=
mn0 requested pci_enable_iovgapci0: child drmn0 requested pci_enable_io[drm=
] Unable to create a private tmpfs mount, hugepage support will be disabled=
(-19).[drm] Got stolen memory base 0x0, size 0x0drmn drmn0: drm_WARN_ON(!ti=
meout_expected)drmn drmn0: drm_WARN_ON(!timeout_expected)drmn drmn0: drm_WA=
RN_ON(!timeout_expected)drmn0: could not load firmware image 'i915/kbl_dmc_=
ver1_04.bin'drmn0: [drm] Failed to load DMC firmware i915/kbl_dmc_ver1_04.b=
in. Disabling runtime power management.drmn0: [drm] DMC firmware homepage: =
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git=
/tree/i915i915kms: drmn drmn0: Interrupt register 0x44308 is not zero: 0xff=
ffffffi915kms: drmn drmn0: Interrupt register 0x44318 is not zero: 0xffffff=
ffi915kms: drmn drmn0: Interrupt register 0x44328 is not zero: 0xffffffffi9=
15kms: drmn drmn0: Interrupt register 0x44338 is not zero: 0xffffffffi915km=
s: drmn drmn0: Interrupt register 0x64838 is not zero: 0xffffffffi915kms: d=
rmn drmn0: Interrupt register 0x44408 is not zero: 0xffffffffi915kms: drmn =
drmn0: Interrupt register 0x44418 is not zero: 0xffffffffi915kms: drmn drmn=
0: Interrupt register 0x44428 is not zero: 0xffffffffi915kms: drmn drmn0: I=
nterrupt register 0x44448 is not zero: 0xffffffffi915kms: drmn drmn0: Inter=
rupt register 0x44468 is not zero: 0xffffffffi915kms: drmn drmn0: Interrupt=
 register 0xc4008 is not zero: 0xffffffffdrmn0: [drm] *ERROR* SKL Mailbox r=
ead error =3D -60lkpi_iic0:  on drmn0lkpi_iic1:  on drmn0lkpi_iic2:  on drmn0[drm ERROR :fw_domain_wait_ack_=
clear] render: timed out waiting for forcewake ack to clear.drmn0: [drm:0xf=
fffffff831866c9s] 0xfffffe00d2b26658V[drm ERROR :fw_domain_wait_ack_clear] =
blitter: timed out waiting for forcewake ack to clear.drmn0: [drm:0xfffffff=
f831866c9s] 0xfffffe00d2b26658V[drm ERROR :fw_domain_wait_ack_clear] media:=
 timed out waiting for forcewake ack to clear.drmn0: [drm:0xffffffff831866c=
9s] 0xfffffe00d2b26658Vdrmn0: [drm] *ERROR* rcs'0 reset request timed out: =
{request: 00000001, RESET_CTL: 00010001}drmn0: [drm] *ERROR* rcs'0 reset re=
quest timed out: {request: 00000001, RESET_CTL: 00010001}drmn0: [drm] *ERRO=
R* bcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}d=
rmn0: [drm] *ERROR* vcs'0 reset request timed out: {request: 00000001, RESE=
T_CTL: 00010001}drmn0: [drm] *ERROR* vecs'0 reset request timed out: {reque=
st: 00000001, RESET_CTL: 00010001}drmn0: [drm] *ERROR* rcs'0 reset request =
timed out: {request: 00000001, RESET_CTL: 00010001}drmn0: [drm] *ERROR* bcs=
'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}drmn0: =
[drm] *ERROR* vcs'0 reset request timed out: {request: 00000001, RESET_CTL:=
 00010001}drmn0: [drm] *ERROR* vecs'0 reset request timed out: {request: 00=
000001, RESET_CTL: 00010001}drmn0: [drm:0xffffffff831ee432s] 0xfffffe00d2b2=
6648Vdrmn0: [drm] *ERROR* rcs'0 reset request timed out: {request: 00000001=
, RESET_CTL: 00010001}drmn0: [drm] *ERROR* rcs'0 reset request timed out: {=
request: 00000001, RESET_CTL: 00010001}drmn0: [drm] *ERROR* bcs'0 reset req=
uest timed out: {request: 00000001, RESET_CTL: 00010001}drmn0: [drm] *ERROR=
* vcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}dr=
mn0: [drm] *ERROR* vecs'0 reset request timed out: {request: 00000001, RESE=
T_CTL: 00010001}drmn0: [drm] *ERROR* rcs'0 reset request timed out: {reques=
t: 00000001, RESET_CTL: 00010001}drmn0: [drm] *ERROR* bcs'0 reset request t=
imed out: {request: 00000001, RESET_CTL: 00010001}drmn0: [drm] *ERROR* vcs'=
0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}drmn0: [=
drm] *ERROR* vecs'0 reset request timed out: {request: 00000001, RESET_CTL:=
 00010001}drmn0: [drm] *ERROR* rcs'0 reset request timed out: {request: 000=
00001, RESET_CTL: 00010001}drmn0: [drm] *ERROR* rcs'0 reset request timed o=
ut: {request: 00000001, RESET_CTL: 00010001}drmn0: [drm] *ERROR* bcs'0 rese=
t request timed out: {request: 00000001, RESET_CTL: 00010001}drmn0: [drm] *=
ERROR* vcs'0 reset request timed out: {request: 00000001, RESET_CTL: 000100=
01}drmn0: [drm] *ERROR* vecs'0 reset request timed out: {request: 00000001,=
 RESET_CTL: 00010001}drmn0: [drm] *ERROR* rcs'0 reset request timed out: {r=
equest: 00000001, RESET_CTL: 00010001}drmn0: [drm] *ERROR* bcs'0 reset requ=
est timed out: {request: 00000001, RESET_CTL: 00010001}drmn0: [drm] *ERROR*=
 vcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}drm=
n0: [drm] *ERROR* vecs'0 reset request timed out: {request: 00000001, RESET=
_CTL: 00010001}drmn0: [drm:0xffffffff831df9e9s] 0xfffffe00d2b26728Vdrmn0: [=
drm] *ERROR* rcs'0 TLB invalidation did not complete in 4ms!drmn drmn0: pip=
e_off wait timed outdrmn0: [drm] *ERROR* Timeout waiting for DDI BUF D to g=
et idledrmn0: [drm] *ERROR* Failed to inform PCU about cdclk change (-35)dr=
mn drmn0: cdclk state doesn't match!drmn0: [drm] *ERROR* DPLL 1 not lockedd=
rmn0: [drm] *ERROR* AUX D/port D: did not complete or timeout within 10ms (=
status 0xfe6003ff)drmn0: [drm] *ERROR* AUX D/port D: did not complete or ti=
meout within 10ms (status 0xfe6003ff)drmn0: [drm] *ERROR* AUX D/port D: did=
 not complete or timeout within 10ms (status 0xfe6003ff)drmn0: [drm] *ERROR=
* AUX D/port D: did not complete or timeout within 10ms (status 0xfe6003ff)=
drmn0: [drm] *ERROR* AUX D/port D: did not complete or timeout within 10ms =
(status 0xfe6003ff)drmn0: [drm] *ERROR* AUX D/port D: receive error (status=
 0xfe6003ff)drmn drmn0: AUX D/port D: not started (status 0xfe6003ff)drmn0:=
 [drm] *ERROR* failed to enable link trainingdrmn0: [drm] *ERROR* Link Trai=
ning Unsuccessful[drm ERROR :drm_atomic_helper_wait_for_flip_done] [CRTC:51=
:pipe A] flip_done timed outdrmn0: [drm] *ERROR* [CRTC:51:pipe A] mismatch =
in infoframes.enable 0xfffffe00d2b26530Vdrmn0: [drm] *ERROR* mismatch in av=
i infoframedrmn0: [drm] *ERROR* expected:drmn0: HDMI infoframe: Auxiliary V=
ideo Information (AVI), version 2, length 13drmn0:=C2=A0 =C2=A0 =C2=A0color=
space: RGBdrmn0:=C2=A0 =C2=A0 =C2=A0scan mode: No Datadrmn0:=C2=A0 =C2=A0 =
=C2=A0colorimetry: No Datadrmn0:=C2=A0 =C2=A0 =C2=A0picture aspect: No Data=
drmn0:=C2=A0 =C2=A0 =C2=A0active aspect: 14:9 Topdrmn0:=C2=A0 =C2=A0 =C2=A0=
itc: No Datadrmn0:=C2=A0 =C2=A0 =C2=A0extended colorimetry: xvYCC 601drmn0:=
=C2=A0 =C2=A0 =C2=A0quantization range: Defaultdrmn0:=C2=A0 =C2=A0 =C2=A0nu=
ps: Unknown Non-uniform Scalingdrmn0:=C2=A0 =C2=A0 =C2=A0video code: 0drmn0=
:=C2=A0 =C2=A0 =C2=A0ycc quantization range: Limiteddrmn0:=C2=A0 =C2=A0 =C2=
=A0hdmi content type: Graphicsdrmn0:=C2=A0 =C2=A0 =C2=A0pixel repeat: 0drmn=
0:=C2=A0 =C2=A0 =C2=A0bar top 0, bottom 0, left 0, right 0drmn0: [drm] *ERR=
OR* found:drmn0: [drm] *ERROR* Failed to enable SAGVdrmn drmn0: Unclaimed r=
ead from register 0xc4004lkpi_iic3:  on drm1lkpi_iic4:  on drm2lkpi_iic5:  on drm3lkpi_iic6:  =
on drm4[drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0drmn0: [dr=
m] Cannot find any crtc or sizes[drm ERROR :drm_atomic_helper_wait_for_depe=
ndencies] [CRTC:51:pipe A] flip_done timed out[drm ERROR :drm_atomic_helper=
_wait_for_dependencies] [CONNECTOR:116:DP-4] flip_done timed outdrmn0: [drm=
] *ERROR* Timeout waiting for DDI BUF D to get idledrmn0: [drm] *ERROR* Fai=
led to enable SAGVdrmn0: [drm] Cannot find any crtc or sizesmds@freebsd14:~=
 $

root@freebsd14:/var/log # cat Xorg.0.log[=C2=A0 4349.263]=C2=A0X.Org X Serv=
er 1.20.14X Protocol Version 11, Revision 0[=C2=A0 4349.263] Build Operatin=
g System: FreeBSD 14.0-CURRENT amd64=C2=A0[=C2=A0 4349.263] Current Operati=
ng System: FreeBSD freebsd14 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n256=
882-8f733dabcc3: Fri Jul 22 08:31:37 UTC 2022=C2=A0 =C2=A0 =C2=A0root@relen=
g1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64[=C2=A0 43=
49.263] Build Date: 26 July 2022=C2=A0 09:04:55AM[=C2=A0 4349.263]=C2=A0=C2=
=A0[=C2=A0 4349.263] Current version of pixman: 0.40.0[=C2=A0 4349.263]=C2=
=A0 =C2=A0 Before reporting problems, check http://wiki.x.org=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 to make sure that you have the latest version.[=C2=A0 4349.26=
3] Markers: (--) probed, (**) from config file, (=3D=3D) default setting,=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (++) from command line, (!!) notice, (II) infor=
mational,=C2=A0 =C2=A0 =C2=A0 =C2=A0 (WW) warning, (EE) error, (NI) not imp=
lemented, (??) unknown.[=C2=A0 4349.263] (=3D=3D) Log file: "/var/log/Xorg.=
0.log", Time: Thu Jul 28 09:45:52 2022[=C2=A0 4349.263] (=3D=3D) Using syst=
em config directory "/usr/local/share/X11/xorg.conf.d"[=C2=A0 4349.263] (=
=3D=3D) No Layout section.=C2=A0 Using the first Screen section.[=C2=A0 434=
9.263] (=3D=3D) No screen section available. Using defaults.[=C2=A0 4349.26=
3] (**) |-->Screen "Default Screen Section" (0)[=C2=A0 4349.263] (**) |=C2=
=A0 =C2=A0|-->Monitor ""[=C2=A0 4349.263] (=3D=3D) No moni=
tor specified for screen "Default Screen Section".=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 Using a default monitor configuration.[=C2=A0 4349.263] (=3D=3D) Automa=
tically adding devices[=C2=A0 4349.263] (=3D=3D) Automatically enabling dev=
ices[=C2=A0 4349.263] (=3D=3D) Not automatically adding GPU devices[=C2=A0 =
4349.263] (=3D=3D) Max clients allowed: 256, resource mask: 0x1fffff[=C2=A0=
 4349.263] (=3D=3D) FontPath set to:=C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/local/=
share/fonts/misc/,=C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/local/share/fonts/TTF/,=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/local/share/fonts/OTF/,=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 /usr/local/share/fonts/Type1/,=C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/l=
ocal/share/fonts/100dpi/,=C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/local/share/fonts=
/75dpi/,=C2=A0 =C2=A0 =C2=A0 =C2=A0 catalogue:/usr/local/etc/X11/fontpath.d=
[=C2=A0 4349.263] (=3D=3D) ModulePath set to "/usr/local/lib/xorg/modules"[=
=C2=A0 4349.263] (II) The server relies on udev to provide the list of inpu=
t devices.=C2=A0 =C2=A0 =C2=A0 =C2=A0 If no devices become available, recon=
figure udev or disable AutoAddDevices.[=C2=A0 4349.263] (II) Loader magic: =
0x42ed00[=C2=A0 4349.263] (II) Module ABI versions:[=C2=A0 4349.263]=C2=A0 =
=C2=A0 X.Org ANSI C Emulation: 0.4[=C2=A0 4349.263]=C2=A0 =C2=A0 X.Org Vide=
o Driver: 24.1[=C2=A0 4349.263]=C2=A0 =C2=A0 X.Org XInput driver : 24.1[=C2=
=A0 4349.263]=C2=A0 =C2=A0 X.Org Server Extension : 10.0[=C2=A0 4349.263] (=
--) PCI:*(6@0:0:0) 8086:5912:1028:07a3 rev 4, Mem @ 0xc0000000/16777216, 0x=
800000000/268435456, BIOS @ 0x????????/65536[=C2=A0 4349.263] (II) LoadModu=
le: "glx"[=C2=A0 4349.263] (II) Loading /usr/local/lib/xorg/modules/extensi=
ons/libglx.so[=C2=A0 4349.263] (II) Module glx: vendor=3D"X.Org Foundation"=
[=C2=A0 4349.263]=C2=A0 =C2=A0 compiled for 1.20.14, module version =3D 1.0=
.0[=C2=A0 4349.263]=C2=A0 =C2=A0 ABI class: X.Org Server Extension, version=
 10.0[=C2=A0 4349.263] (=3D=3D) Matched intel as autoconfigured driver 0[=
=C2=A0 4349.263] (=3D=3D) Matched modesetting as autoconfigured driver 1[=
=C2=A0 4349.263] (=3D=3D) Matched scfb as autoconfigured driver 2[=C2=A0 43=
49.263] (=3D=3D) Matched vesa as autoconfigured driver 3[=C2=A0 4349.263] (=
=3D=3D) Assigned the driver to the xf86ConfigLayout[=C2=A0 4349.263] (II) L=
oadModule: "intel"[=C2=A0 4349.263] (WW) Warning, couldn't open module inte=
l[=C2=A0 4349.263] (EE) Failed to load module "intel" (module does not exis=
t, 0)[=C2=A0 4349.263] (II) LoadModule: "modesetting"[=C2=A0 4349.263] (II)=
 Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so[=C2=A0 4349=
.263] (II) Module modesetting: vendor=3D"X.Org Foundation"[=C2=A0 4349.263]=
=C2=A0 =C2=A0 compiled for 1.20.14, module version =3D 1.20.14[=C2=A0 4349.=
263]=C2=A0 =C2=A0 Module class: X.Org Video Driver[=C2=A0 4349.263]=C2=A0 =
=C2=A0 ABI class: X.Org Video Driver, version 24.1[=C2=A0 4349.263] (II) Lo=
adModule: "scfb"[=C2=A0 4349.263] (II) Loading /usr/local/lib/xorg/modules/=
drivers/scfb_drv.so[=C2=A0 4349.263] (II) Module scfb: vendor=3D"X.Org Foun=
dation"[=C2=A0 4349.263]=C2=A0 =C2=A0 compiled for 1.20.14, module version =
=3D 0.0.5[=C2=A0 4349.263]=C2=A0 =C2=A0 ABI class: X.Org Video Driver, vers=
ion 24.1[=C2=A0 4349.263] (II) LoadModule: "vesa"[=C2=A0 4349.263] (II) Loa=
ding /usr/local/lib/xorg/modules/drivers/vesa_drv.so[=C2=A0 4349.263] (II) =
Module vesa: vendor=3D"X.Org Foundation"[=C2=A0 4349.263]=C2=A0 =C2=A0 comp=
iled for 1.20.14, module version =3D 2.5.0[=C2=A0 4349.263]=C2=A0 =C2=A0 Mo=
dule class: X.Org Video Driver[=C2=A0 4349.263]=C2=A0 =C2=A0 ABI class: X.O=
rg Video Driver, version 24.1[=C2=A0 4349.263] (II) modesetting: Driver for=
 Modesetting Kernel Drivers: kms[=C2=A0 4349.263] (II) scfb: driver for wsd=
isplay framebuffer: scfb[=C2=A0 4349.263] (II) VESA: driver for VESA chipse=
ts: vesa[=C2=A0 4349.263] (--) Using syscons driver with X support (version=
 2.0)[=C2=A0 4349.263] (--) using VT number 9
[=C2=A0 4349.263] (EE) open /dev/dri/card0: No such file or directory[=C2=
=A0 4349.263] (WW) Falling back to old probe method for modesetting[=C2=A0 =
4349.263] (EE) open /dev/dri/card0: No such file or directory[=C2=A0 4349.2=
63] (WW) Falling back to old probe method for scfb[=C2=A0 4349.263] scfb tr=
ace: probe start[=C2=A0 4349.263] (II) scfb(1): using default device[=C2=A0=
 4349.263] scfb trace: probe done[=C2=A0 4349.263] (WW) VGA arbiter: cannot=
 open kernel arbiter, no multi-card support[=C2=A0 4349.263] (EE) Screen 0 =
deleted because of no matching config section.[=C2=A0 4349.263] (II) Unload=
Module: "modesetting"[=C2=A0 4349.263] (EE)=C2=A0Fatal server error:[=C2=A0=
 4349.263] (EE) Cannot run in framebuffer mode. Please specify busIDs=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 for all framebuffer devices[=C2=A0 4349.263] (EE)=C2=
=A0[=C2=A0 4349.263] (EE)=C2=A0Please consult the The X.Org Foundation supp=
ort=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at http://wiki.x.org=C2=A0for he=
lp.=C2=A0[=C2=A0 4349.263] (EE) Please also check the log file at "/var/log=
/Xorg.0.log" for additional information.[=C2=A0 4349.263] (EE)=C2=A0[=C2=A0=
 4349.263] (EE) Server terminated with error (1). Closing log file.root@fre=
ebsd14:/var/log #
------=_Part_3537200_1169446424.1659035357928
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit



Created a libvirt virtual machine on an ubuntu-22.04-desktop-amd64 host following this tutorial:

https://blog.tmm.cx/2020/05/15/passing-an-intel-gpu-to-a-linux-kvm-virtual-machine/











With the exception that it was UEFI instead of SeaBIOS by using the workaround described here:



https://wiki.archlinux.org/title/Intel_GVT-g#Using_DMA-BUF_with_UEFI/OVMF











Tested it with ubuntu-22.04-desktop-amd64.iso Live CD to verify that it worked.









Installed FreeBSD-14.0-CURRENT-amd64-20220722-8f733dabcc3-256882-disc1.iso guest on same virtual machine.









Installed a desktop environment following these instructions:



https://freebsdfoundation.org/freebsd-project/resources/installing-a-desktop-environment-on-freebsd/











Does not display desktop.









Is there a newer version of any of the components that I could test?











mds@freebsd14:~ $ dmesg | grep drm



drmn0: <drmn> on vgapci0



vgapci0: child drmn0 requested pci_enable_io



vgapci0: child drmn0 requested pci_enable_io



[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).



[drm] Got stolen memory base 0x0, size 0x0



drmn drmn0: drm_WARN_ON(!timeout_expected)drmn drmn0: drm_WARN_ON(!timeout_expected)drmn drmn0: drm_WARN_ON(!timeout_expected)



drmn0: could not load firmware image 'i915/kbl_dmc_ver1_04.bin'



drmn0: [drm] Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management.



drmn0: [drm] DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915



i915kms: drmn drmn0: Interrupt register 0x44308 is not zero: 0xffffffff



i915kms: drmn drmn0: Interrupt register 0x44318 is not zero: 0xffffffff



i915kms: drmn drmn0: Interrupt register 0x44328 is not zero: 0xffffffff



i915kms: drmn drmn0: Interrupt register 0x44338 is not zero: 0xffffffff



i915kms: drmn drmn0: Interrupt register 0x64838 is not zero: 0xffffffff



i915kms: drmn drmn0: Interrupt register 0x44408 is not zero: 0xffffffff



i915kms: drmn drmn0: Interrupt register 0x44418 is not zero: 0xffffffff



i915kms: drmn drmn0: Interrupt register 0x44428 is not zero: 0xffffffff



i915kms: drmn drmn0: Interrupt register 0x44448 is not zero: 0xffffffff



i915kms: drmn drmn0: Interrupt register 0x44468 is not zero: 0xffffffff



i915kms: drmn drmn0: Interrupt register 0xc4008 is not zero: 0xffffffff



drmn0: [drm] *ERROR* SKL Mailbox read error = -60



lkpi_iic0: <LinuxKPI I2C> on drmn0



lkpi_iic1: <LinuxKPI I2C> on drmn0



lkpi_iic2: <LinuxKPI I2C> on drmn0



[drm ERROR :fw_domain_wait_ack_clear] render: timed out waiting for forcewake ack to clear.



drmn0: [drm:0xffffffff831866c9s] 0xfffffe00d2b26658V[drm ERROR :fw_domain_wait_ack_clear] blitter: timed out waiting for forcewake ack to clear.



drmn0: [drm:0xffffffff831866c9s] 0xfffffe00d2b26658V[drm ERROR :fw_domain_wait_ack_clear] media: timed out waiting for forcewake ack to clear.



drmn0: [drm:0xffffffff831866c9s] 0xfffffe00d2b26658Vdrmn0: [drm] *ERROR* rcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* rcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* bcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vecs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* rcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* bcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vecs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm:0xffffffff831ee432s] 0xfffffe00d2b26648Vdrmn0: [drm] *ERROR* rcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* rcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* bcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vecs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* rcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* bcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vecs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* rcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* rcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* bcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vecs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* rcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* bcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vcs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm] *ERROR* vecs'0 reset request timed out: {request: 00000001, RESET_CTL: 00010001}



drmn0: [drm:0xffffffff831df9e9s] 0xfffffe00d2b26728Vdrmn0: [drm] *ERROR* rcs'0 TLB invalidation did not complete in 4ms!



drmn drmn0: pipe_off wait timed out



drmn0: [drm] *ERROR* Timeout waiting for DDI BUF D to get idle



drmn0: [drm] *ERROR* Failed to inform PCU about cdclk change (-35)



drmn drmn0: cdclk state doesn't match!



drmn0: [drm] *ERROR* DPLL 1 not locked



drmn0: [drm] *ERROR* AUX D/port D: did not complete or timeout within 10ms (status 0xfe6003ff)



drmn0: [drm] *ERROR* AUX D/port D: did not complete or timeout within 10ms (status 0xfe6003ff)



drmn0: [drm] *ERROR* AUX D/port D: did not complete or timeout within 10ms (status 0xfe6003ff)



drmn0: [drm] *ERROR* AUX D/port D: did not complete or timeout within 10ms (status 0xfe6003ff)



drmn0: [drm] *ERROR* AUX D/port D: did not complete or timeout within 10ms (status 0xfe6003ff)



drmn0: [drm] *ERROR* AUX D/port D: receive error (status 0xfe6003ff)



drmn drmn0: AUX D/port D: not started (status 0xfe6003ff)



drmn0: [drm] *ERROR* failed to enable link training



drmn0: [drm] *ERROR* Link Training Unsuccessful



[drm ERROR :drm_atomic_helper_wait_for_flip_done] [CRTC:51:pipe A] flip_done timed out



drmn0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in infoframes.enable 0xfffffe00d2b26530V



drmn0: [drm] *ERROR* mismatch in avi infoframe



drmn0: [drm] *ERROR* expected:



drmn0: HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13



drmn0:     colorspace: RGB



drmn0:     scan mode: No Data



drmn0:     colorimetry: No Data



drmn0:     picture aspect: No Data



drmn0:     active aspect: 14:9 Top



drmn0:     itc: No Data



drmn0:     extended colorimetry: xvYCC 601



drmn0:     quantization range: Default



drmn0:     nups: Unknown Non-uniform Scaling



drmn0:     video code: 0



drmn0:     ycc quantization range: Limited



drmn0:     hdmi content type: Graphics



drmn0:     pixel repeat: 0



drmn0:     bar top 0, bottom 0, left 0, right 0



drmn0: [drm] *ERROR* found:



drmn0: [drm] *ERROR* Failed to enable SAGV



drmn drmn0: Unclaimed read from register 0xc4004



lkpi_iic3: <LinuxKPI I2C> on drm1



lkpi_iic4: <LinuxKPI I2C> on drm2



lkpi_iic5: <LinuxKPI I2C> on drm3



lkpi_iic6: <LinuxKPI I2C> on drm4



[drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0



drmn0: [drm] Cannot find any crtc or sizes



[drm ERROR :drm_atomic_helper_wait_for_dependencies] [CRTC:51:pipe A] flip_done timed out



[drm ERROR :drm_atomic_helper_wait_for_dependencies] [CONNECTOR:116:DP-4] flip_done timed out



drmn0: [drm] *ERROR* Timeout waiting for DDI BUF D to get idle



drmn0: [drm] *ERROR* Failed to enable SAGV



drmn0: [drm] Cannot find any crtc or sizes



mds@freebsd14:~ $



















root@freebsd14:/var/log # cat Xorg.0.log



[  4349.263] 



X.Org X Server 1.20.14



X Protocol Version 11, Revision 0



[  4349.263] Build Operating System: FreeBSD 14.0-CURRENT amd64 



[  4349.263] Current Operating System: FreeBSD freebsd14 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n256882-8f733dabcc3: Fri Jul 22 08:31:37 UTC 2022     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64



[  4349.263] Build Date: 26 July 2022  09:04:55AM



[  4349.263]  



[  4349.263] Current version of pixman: 0.40.0



[  4349.263]    Before reporting problems, check http://wiki.x.org



        to make sure that you have the latest version.



[  4349.263] Markers: (--) probed, (**) from config file, (==) default setting,



        (++) from command line, (!!) notice, (II) informational,



        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.



[  4349.263] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jul 28 09:45:52 2022



[  4349.263] (==) Using system config directory "/usr/local/share/X11/xorg.conf.d"



[  4349.263] (==) No Layout section.  Using the first Screen section.



[  4349.263] (==) No screen section available. Using defaults.



[  4349.263] (**) |-->Screen "Default Screen Section" (0)



[  4349.263] (**) |   |-->Monitor "<default monitor>"



[  4349.263] (==) No monitor specified for screen "Default Screen Section".



        Using a default monitor configuration.



[  4349.263] (==) Automatically adding devices



[  4349.263] (==) Automatically enabling devices



[  4349.263] (==) Not automatically adding GPU devices



[  4349.263] (==) Max clients allowed: 256, resource mask: 0x1fffff



[  4349.263] (==) FontPath set to:



        /usr/local/share/fonts/misc/,



        /usr/local/share/fonts/TTF/,



        /usr/local/share/fonts/OTF/,



        /usr/local/share/fonts/Type1/,



        /usr/local/share/fonts/100dpi/,



        /usr/local/share/fonts/75dpi/,



        catalogue:/usr/local/etc/X11/fontpath.d



[  4349.263] (==) ModulePath set to "/usr/local/lib/xorg/modules"



[  4349.263] (II) The server relies on udev to provide the list of input devices.



        If no devices become available, reconfigure udev or disable AutoAddDevices.



[  4349.263] (II) Loader magic: 0x42ed00



[  4349.263] (II) Module ABI versions:



[  4349.263]    X.Org ANSI C Emulation: 0.4



[  4349.263]    X.Org Video Driver: 24.1



[  4349.263]    X.Org XInput driver : 24.1



[  4349.263]    X.Org Server Extension : 10.0



[  4349.263] (--) PCI:*(6@0:0:0) 8086:5912:1028:07a3 rev 4, Mem @ 0xc0000000/16777216, 0x800000000/268435456, BIOS @ 0x????????/65536



[  4349.263] (II) LoadModule: "glx"



[  4349.263] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so



[  4349.263] (II) Module glx: vendor="X.Org Foundation"



[  4349.263]    compiled for 1.20.14, module version = 1.0.0



[  4349.263]    ABI class: X.Org Server Extension, version 10.0



[  4349.263] (==) Matched intel as autoconfigured driver 0



[  4349.263] (==) Matched modesetting as autoconfigured driver 1



[  4349.263] (==) Matched scfb as autoconfigured driver 2



[  4349.263] (==) Matched vesa as autoconfigured driver 3



[  4349.263] (==) Assigned the driver to the xf86ConfigLayout



[  4349.263] (II) LoadModule: "intel"



[  4349.263] (WW) Warning, couldn't open module intel



[  4349.263] (EE) Failed to load module "intel" (module does not exist, 0)



[  4349.263] (II) LoadModule: "modesetting"



[  4349.263] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so



[  4349.263] (II) Module modesetting: vendor="X.Org Foundation"



[  4349.263]    compiled for 1.20.14, module version = 1.20.14



[  4349.263]    Module class: X.Org Video Driver



[  4349.263]    ABI class: X.Org Video Driver, version 24.1



[  4349.263] (II) LoadModule: "scfb"



[  4349.263] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so



[  4349.263] (II) Module scfb: vendor="X.Org Foundation"



[  4349.263]    compiled for 1.20.14, module version = 0.0.5



[  4349.263]    ABI class: X.Org Video Driver, version 24.1



[  4349.263] (II) LoadModule: "vesa"



[  4349.263] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so



[  4349.263] (II) Module vesa: vendor="X.Org Foundation"



[  4349.263]    compiled for 1.20.14, module version = 2.5.0



[  4349.263]    Module class: X.Org Video Driver



[  4349.263]    ABI class: X.Org Video Driver, version 24.1



[  4349.263] (II) modesetting: Driver for Modesetting Kernel Drivers: kms



[  4349.263] (II) scfb: driver for wsdisplay framebuffer: scfb



[  4349.263] (II) VESA: driver for VESA chipsets: vesa



[  4349.263] (--) Using syscons driver with X support (version 2.0)



[  4349.263] (--) using VT number 9









[  4349.263] (EE) open /dev/dri/card0: No such file or directory



[  4349.263] (WW) Falling back to old probe method for modesetting



[  4349.263] (EE) open /dev/dri/card0: No such file or directory



[  4349.263] (WW) Falling back to old probe method for scfb



[  4349.263] scfb trace: probe start



[  4349.263] (II) scfb(1): using default device



[  4349.263] scfb trace: probe done



[  4349.263] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support



[  4349.263] (EE) Screen 0 deleted because of no matching config section.



[  4349.263] (II) UnloadModule: "modesetting"



[  4349.263] (EE) 



Fatal server error:



[  4349.263] (EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices



[  4349.263] (EE) 



[  4349.263] (EE) 



Please consult the The X.Org Foundation support 



         at http://wiki.x.org



 for help. 



[  4349.263] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.



[  4349.263] (EE) 



[  4349.263] (EE) Server terminated with error (1). Closing log file.



root@freebsd14:/var/log #






------=_Part_3537200_1169446424.1659035357928--

From nobody Fri Jul 29 06:12:36 2022
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 4LvHHf11qVz4X2QT;
	Fri, 29 Jul 2022 06:12:46 +0000 (UTC)
	(envelope-from delphij@delphij.net)
Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212])
	(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 "anubis.delphij.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LvHHd1g5kz3QlL;
	Fri, 29 Jul 2022 06:12:45 +0000 (UTC)
	(envelope-from delphij@delphij.net)
Received: from [10.0.0.2] (c-141-193-140-252.rev.sailinternet.net [141.193.140.252])
	by anubis.delphij.net (Postfix) with ESMTPSA id 0B8E855D18;
	Thu, 28 Jul 2022 23:12:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=m7e2;
	t=1659075158; x=1659089558;
	bh=sQyCpMSQHJiYvNoXiUg4FCzBVkHHW1fAxJeVxFPBI+c=;
	h=Date:Reply-To:To:From:Subject;
	b=qxVeal2d6Xzl4ikqyJ7QXhwtnAufNhhLfXG0XAYQF9Ps6yXH1y/MZYED8b+6MBqRH
	 Rky8GM9l6Jg0Zj0MpTZaxr7VsU0xGygN3ILqGtty/QtaRKQApGF/DF6WFrH6C/T0p6
	 aMEYgynKf/ncuJi8d9vueqC2wAkg8twRAfsiLHP0fA4TS0nGQLwE5JJ2pjibV6wLZ+
	 Az0Iu/uLzsssYuKPMlPycPGJEpqEMOuF2q5lwQBfsI00q8W0yWpF68pGpvvBT0HhAH
	 igxevRPSOdn0XFNwcw6kKMrLlDXyaWvvX8KuX8iuE/LO+DlzF3mt8TaoI2SuJOulGF
	 UM9zKKe8wHBtQ==
Message-ID: <0d8e1b38-bcd2-0875-1864-3385c502646d@delphij.net>
Date: Thu, 28 Jul 2022 23:12:36 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Reply-To: d@delphij.net
Content-Language: en-US
To: freebsd-current , freebsd-hackers@freebsd.org
From: Xin Li 
Organization: The FreeBSD Project
Subject: Proposal: remove /usr/bin/minigzip
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LvHHd1g5kz3QlL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=delphij.net header.s=m7e2 header.b=qxVeal2d;
	dmarc=pass (policy=reject) header.from=delphij.net;
	spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 64.62.153.212 as permitted sender) smtp.mailfrom=delphij@delphij.net
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org];
	ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US];
	DKIM_TRACE(0.00)[delphij.net:+];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	HAS_REPLYTO(0.00)[d@delphij.net];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[delphij];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	REPLYTO_DOM_EQ_FROM_DOM(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

I'd like to remove /usr/bin/minigzip , a patch is available at:

	https://reviews.freebsd.org/D35979

The minigzip is originally an example application shipped with zlib to 
demonstrate how to use it to implement basic functionality of gzip.  It 
was connected to the base system in 1997, mainly because there wasn't a 
GPL-free implementation of gzip(1):

	https://cgit.freebsd.org/src/commit/usr.bin/minigzip?id=85e55f7ab8473307fb16c5bce8c2e933a317215b

Now we already have a GPL-free gzip(1) implementation in base system for 
quite a while, so it seems that there isn't much value of keeping 
minigzip around.  A quick grep suggests that it's not being used by the 
base system anywhere, nor in the ports tree.

Any objections?

Cheers,

From nobody Fri Jul 29 07:52:36 2022
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 4LvKVw058Cz4XJY3;
	Fri, 29 Jul 2022 07:52:40 +0000 (UTC)
	(envelope-from delphij@delphij.net)
Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212])
	(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 "anubis.delphij.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LvKVt6nCVz3dDR;
	Fri, 29 Jul 2022 07:52:38 +0000 (UTC)
	(envelope-from delphij@delphij.net)
Received: from [10.0.0.2] (c-141-193-140-252.rev.sailinternet.net [141.193.140.252])
	by anubis.delphij.net (Postfix) with ESMTPSA id 86D5055C60;
	Fri, 29 Jul 2022 00:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=m7e2;
	t=1659081157; x=1659095557;
	bh=WakUH30bnNZ+djJWkGrfhCv8Pq6Zy3WUi1kNbeOWwCM=;
	h=Date:Reply-To:To:References:From:Subject:In-Reply-To;
	b=hZuQPHAhYvHK0TCjmtpJs1cYtvDBJP8sL/uNhK7CB9YB82m+aVpi0gYmjHKYHrhPi
	 gDMambQGLsVDIrPP+bpW4VHr4EpVUzwgnwPLSgruwq+2enETSbuYidNkMgyvtwxxdG
	 wmbmaICPheKj0V9b9FlQLQ7mqb/J0eBEYw9O4HxN0R1CAcAF36xOvBBg47Lp7y4v2E
	 NcyyZVkFwTM9JHeVKevLMDoOp5oAcqWp9yHdTBfToBJnrp44Hb9y6zqVKMZ31fxg5U
	 BmyW7h1+z9PX/fIlz65HfJOhDEfus09PbHmum8xCCpZma+jdvscDU2qiFawsya88BP
	 G72fO6kQ4fuSg==
Message-ID: 
Date: Fri, 29 Jul 2022 00:52:36 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Reply-To: d@delphij.net
Content-Language: en-US
To: Eugene Grosbein , d@delphij.net,
 freebsd-current , freebsd-hackers@freebsd.org
References: <0d8e1b38-bcd2-0875-1864-3385c502646d@delphij.net>
 
From: Xin Li 
Organization: The FreeBSD Project
Subject: Re: Proposal: remove /usr/bin/minigzip
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LvKVt6nCVz3dDR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=delphij.net header.s=m7e2 header.b=hZuQPHAh;
	dmarc=pass (policy=reject) header.from=delphij.net;
	spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 64.62.153.212 as permitted sender) smtp.mailfrom=delphij@delphij.net
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2];
	MIME_GOOD(-0.10)[text/plain];
	DKIM_TRACE(0.00)[delphij.net:+];
	ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MIME_TRACE(0.00)[0:+];
	HAS_ORG_HEADER(0.00)[];
	HAS_REPLYTO(0.00)[d@delphij.net];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[delphij];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCPT_COUNT_THREE(0.00)[4];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	REPLYTO_DOM_EQ_FROM_DOM(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On 7/28/22 23:24, Eugene Grosbein wrote:
> 29.07.2022 13:12, Xin Li пишет:
>> Hi,
>>
>> I'd like to remove /usr/bin/minigzip , a patch is available at:
>>
>>      https://reviews.freebsd.org/D35979
>>
>> The minigzip is originally an example application shipped with zlib to demonstrate how to use it to implement basic functionality of gzip.  It was connected to the base system in 1997, mainly because there wasn't a GPL-free implementation of gzip(1):
>>
>>      https://cgit.freebsd.org/src/commit/usr.bin/minigzip?id=85e55f7ab8473307fb16c5bce8c2e933a317215b
>>
>> Now we already have a GPL-free gzip(1) implementation in base system for quite a while, so it seems that there isn't much value of keeping minigzip around.  A quick grep suggests that it's not being used by the base system anywhere, nor in the ports tree.
>>
>> Any objections?
> 
> Have you considered embedded applications (crunchgen etc.)?

Yes, but I don't think it's being used in real life anywhere, base 
system crunchgen examples, including rescue and tools/bsdbox, are all 
using the real gzip.

> In 13.1/amd64, /usr/bin/minigzip binary is about 11KB and links with libc and libz only.
> 
> OTOH, /usr/bin/gzip is about six times larger (64KB) and additionally needs libbz2, liblzma, libmd and libthr.

It's a little bit unfair to compare the sizes of the executables 
directly :-)  After all, the C library accounted for 94.4% and 75.4% of 
space for minigzip and gzip respectively:

$ F=/usr/bin/minigzip; du -Akc $(echo ${F} $(ldd -f '%p\n' ${F} | grep 
^/ | sort))
12	/usr/bin/minigzip
1939	/lib/libc.so.7
104	/lib/libz.so.6
2054	total

$ F=/usr/bin/gzip; du -Akc $(echo ${F} $(ldd -f '%p\n' ${F} | grep ^/ | 
sort))
63	/usr/bin/gzip
1939	/lib/libc.so.7
107	/lib/libmd.so.6
122	/lib/libthr.so.3
104	/lib/libz.so.6
77	/usr/lib/libbz2.so.4
163	/usr/lib/liblzma.so.5
2573	total

So yes, gzip is bigger, but arguably it's just about 0.5MiB, or 25% 
larger, and among that 2573KB, 2510KB or 97.6% was shared library.

But for applications that really want to have smaller footprint, bzip2 
might be a better alternative -- the binary is bigger than minigzip, but 
library was smaller than zlib so the total size is actually a little bit 
smaller:

$ F=/usr/bin/bzip2; du -Akc $(echo ${F} $(ldd -f '%p\n' ${F} | grep ^/ | 
sort))
34	/usr/bin/bzip2
1939	/lib/libc.so.7
77	/usr/lib/libbz2.so.4
2050	total

(It's true that zlib is a much more popular library and is used in more 
scenarios, like ppp, etc., so in reality this might actually added 99kb 
(=34+77-12), I just wanted to say that there are other options, and if 
minigzip is not really being used, building it on every FreeBSD machines 
doesn't seem to be a good use of resources).

Cheers,

From nobody Fri Jul 29 15:34:58 2022
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 4LvWmc2Yytz4XXCj
	for ; Fri, 29 Jul 2022 15:35:12 +0000 (UTC)
	(envelope-from ctuffli@gmail.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LvWmb3l8Tz3RpK
	for ; Fri, 29 Jul 2022 15:35:11 +0000 (UTC)
	(envelope-from ctuffli@gmail.com)
Received: by mail-ej1-x62c.google.com with SMTP id fy29so9113665ejc.12
        for ; Fri, 29 Jul 2022 08:35:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:from:date:message-id:subject:to;
        bh=nBXBSwyRkXGv96MSo9Q8h6R/LgcTLSDaNhPo1Hz5YDU=;
        b=MXH4PQrMwkjHQHg01diN9Tn1Hy7/cg2GVlR4emoaC/5hiuqOF7AX2Ase37OlP0KSwI
         OVTcLGGS1Qgjrs5x/ReEqGWcOFOQjfvPydz3rp/ae/J8a0mYnMMCgwx+xZ9MqEciG2Tc
         m0Jm1wL2E9OuPDbaRgpWz/fslOt47wgYeyu5I3vNZ1LdOEt0576p2VEr6LYYmmjKYF4L
         EJLyLsAF7EGusA1VmVKmRL8ljMqhNX5lsX4HiSF+Gje9HP0t792U+OhWkLZXvAI5OvoF
         W3Ns+zry2aRKNVdx3RPtbzAHUsS+kELPzPyI13qut1Sm4M2kT4VAKnQK/rE/H0KKZDIw
         LOyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=nBXBSwyRkXGv96MSo9Q8h6R/LgcTLSDaNhPo1Hz5YDU=;
        b=h7SgBu6paOEmXIRxXnvqIkGQyMdf8vTJEl0MeWKFhXq8PkL1xHLPk4nngQxvBcqENI
         Tw8HxBdWqDQZmPnEVPcPoY7eMQIiq0VZMrY3lXLPrPgIwgk0RK80P0t15hTkuLUcncec
         FfbnCAcsu48CJUQIe/4hRdncvCpicF2DSYNoycAHVn0Dz6IkSCInSDwe9QfaRjUBxaXx
         POVhhaaZEtb5HN3W0wCRFdOKdk5zPRrCfzQxztzoFPtzgZa0GubeeDauXjlUIwfFc1eA
         3cOCsPgILMybmw/yBvGdTVnNCmRShhfkYPq4KmYQDGTIA2xRz7ZxRKvqQ9e5ORBXugZV
         eHRg==
X-Gm-Message-State: AJIora8RPiKuNU3uugCyls246Fh6NcmM4JeiklmHH0jj4AmlM7YXeIKK
	Yw1qBrZjXXyzWf/JsqB0gUnMv/NclJHeeUPYu0SDl+C/worY5Q==
X-Google-Smtp-Source: AGRyM1tC9Vs0SCNQckN553OX0keO9SUogCOO0el7YLh0itNhqFBK5ygM0jAgt9N21rhFHRARDd6P8P1x/n0OzE7QwjA=
X-Received: by 2002:a17:907:8686:b0:72f:90:f80c with SMTP id
 qa6-20020a170907868600b0072f0090f80cmr3288447ejc.409.1659108909912; Fri, 29
 Jul 2022 08:35:09 -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: Chuck Tuffli 
Date: Fri, 29 Jul 2022 08:34:58 -0700
Message-ID: 
Subject: build failure WITH_ASAN
To: FreeBSD-Current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4LvWmb3l8Tz3RpK
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=MXH4PQrM;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of ctuffli@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=ctuffli@gmail.com
X-Spamd-Result: default: False [-3.92 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	NEURAL_HAM_MEDIUM(-0.93)[-0.932];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

make buildworld -DWITH_UBSAN -DWITH_ASAN is failing for me with the error:

building shared library libc.so.7
ld: error: cannot open
/usr/home/ctuffli/dev/freebsd/obj/usr/home/ctuffli/dev/freebsd/src.git/amd64.amd64/tmp/usr/lib/clang/14.0.5/lib/freebsd/libclang_rt.asan_static-x86_64.a:
No such file or directory
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

This does use meta mode but still occurs after running cleanworld.
greping through the sources, I see a references to
libclang_rt.asan_static-x86_64.a in
tools/build/mk/OptionalObsoleteFiles.inc in the MK_CLANG == no
section. What other information can I provide to help figure this out?
Thanks!

--chuck

From nobody Fri Jul 29 16:06:43 2022
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 4LvXTF3ts8z4Xc8g;
	Fri, 29 Jul 2022 16:06:57 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LvXTD5zl8z3W0x;
	Fri, 29 Jul 2022 16:06:56 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: by mail-ej1-f45.google.com with SMTP id l23so9315616ejr.5;
        Fri, 29 Jul 2022 09:06:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=HhHmeZVnHdEP3jMZmwH3e9iT7m/m8JQo8+L1Fx5akRM=;
        b=6a0caFE0dihIipls4FwAZQYFDdK1WONFZZymP7MhMC2OBLaM2HRGKoAzZpA27599c0
         e2S9T8e0eGwTLjygPz75mKWmyr5KXsAX4xl+KK0u+yYJEOl9eUcIBZCTHE59/twMfXjK
         bV/LMR+Omj9I/hdgd+QyOyx8fA9OxZmW/GPpsYyrCogbLjAGbtFs+WjDGB3ZgOkedmXz
         9Q7IpLcG451fEBVKx6/QMlU9VTgklsTSguueStGm9/y2uJSY54IB7TjzZiTppbp9FK9A
         s+Jo9woa22Z9y1u1Sak8vpcTWmxaU3ACz9EFnJRapi7S8j5JpvUuRBj4BwKE31dUOd3a
         ps6w==
X-Gm-Message-State: AJIora+b0yYEml3bg+3sW46yzdnQp6N+f5Yn9LxRJl/8cZX3Vc+HKA45
	In+HusD3MnaPUmQDXN6tUdz/yyKhDhzxNoACZu1cvN7Dje8=
X-Google-Smtp-Source: AGRyM1v9Cw2QkDPqsUtdR0UtVh7RVxbf/2H3FPtXnC81pgOJjLcfkUsKsp/XsEgg4yoeqzobLKMiBudh6yVX2de16YA=
X-Received: by 2002:a17:906:8478:b0:72b:4f81:29d8 with SMTP id
 hx24-20020a170906847800b0072b4f8129d8mr3352860ejc.179.1659110814830; Fri, 29
 Jul 2022 09:06:54 -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: <0d8e1b38-bcd2-0875-1864-3385c502646d@delphij.net>
  
In-Reply-To: 
From: Ed Maste 
Date: Fri, 29 Jul 2022 12:06:43 -0400
Message-ID: 
Subject: Re: Proposal: remove /usr/bin/minigzip
To: d@delphij.net
Cc: Eugene Grosbein , freebsd-current , 
	freebsd-hackers@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4LvXTD5zl8z3W0x
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com
X-Spamd-Result: default: False [-3.10 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[text/plain];
	RWL_MAILSPIKE_GOOD(-0.10)[209.85.218.45:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org];
	R_DKIM_NA(0.00)[];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	MIME_TRACE(0.00)[0:+];
	FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.218.45:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[carpeddiem];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, 29 Jul 2022 at 03:52, Xin Li  wrote:
> But for applications that really want to have smaller footprint, bzip2
> might be a better alternative -- the binary is bigger than minigzip, but
> library was smaller than zlib so the total size is actually a little bit
> smaller: ...

For applications where tens of kilobytes is a real concern, something
like Rob Landley's "toybox" is probably a better bet.

I configured it to include only gzip and get:
$ ls -l toybox
-r-xr-xr-x  1 emaste  emaste  36880 Jul 29 11:59 toybox
$ ./toybox
gzip
$
$ ldd ./toybox
./toybox:
        libc.so.7 => /lib/libc.so.7 (0x822a42000)

so it's about 25K larger than minigzip, but doesn't depend on libz and
could result in a rather smaller image.

Toybox is at https://landley.net/toybox/

From nobody Fri Jul 29 20:35:51 2022
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 4LvfRl2gFjz4CGZK
	for ; Fri, 29 Jul 2022 20:36:03 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LvfRl2Bn3z3FgR
	for ; Fri, 29 Jul 2022 20:36:03 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659126963;
	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=IPzDQ7qZg8/utx0dFwUBK18wYLYtK6fRHgbPIquD3+4=;
	b=FCMHsGmoXuph0WTC1cid2vgYBhE4Jj44R4Sv8IkCfR5OFPJOt2jRGPNgTeUjjEtH0/n/Ai
	z4wIji+xPZe7jNWdRZxOxiFJsMUmffcW6pCFsZxphI3BWed10ES5PPu2GFBn592NoQFmQS
	cDFF757gWWUJrx/5E6EtHV2U+43V3ev7/H6KUts5Hr7Mw/YU+bxLoGZAPq/SkPm4DoMATi
	PpOQYFm5NG3dZwwcqBQQzlpWxe4SpGQq4AvCyiwhNnk8VFqjRZSwSHn2TdutaLZOXfFlHK
	i8HgV29t8+9A1FYacvG5bIfIXi42eqWnmgGuHit1ngWjvYKKJAAzjLWPM2/zNA==
Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LvfRl16kTzsLG
	for ; Fri, 29 Jul 2022 20:36:03 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f48.google.com with SMTP id k3so5699086vsr.9
        for ; Fri, 29 Jul 2022 13:36:03 -0700 (PDT)
X-Gm-Message-State: AJIora8BTwFdgBlgWp4b5C8mS6ti2oVdNSiT+2SAqm70ltprZI3erpt/
	CLF/uK9SVlETQZjcgPn0e9ZmQVISh/N8GlUdCWY=
X-Google-Smtp-Source: AGRyM1sUg916XSkZLyTPB2cQXKu0tpumyveXObKjbA2fTpG41OlSvA5cOw3j019JTF0GZNmwpOyTqsFFW/MM3AsZd4c=
X-Received: by 2002:a67:f7d3:0:b0:35a:2a5c:488d with SMTP id
 a19-20020a67f7d3000000b0035a2a5c488dmr2205851vsp.51.1659126962602; Fri, 29
 Jul 2022 13:36:02 -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: Nuno Teixeira 
Date: Fri, 29 Jul 2022 21:35:51 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: iwlwifi fails to load @b07a48d4f3a1
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000003e495605e4f799d1"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659126963;
	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=IPzDQ7qZg8/utx0dFwUBK18wYLYtK6fRHgbPIquD3+4=;
	b=g+OaWZxf2Zuc1g+A2w+iDnnRqzBCH97KKY/pfXwB2Rw9QlZZPr5Ok0cSoq5PrMr1NIUYgp
	Zu1BC530MpE0wGKakGLrNx/9YLWxSATLhDBTF4f5LMGuAyMBI7HllzACXZcAdAe4dEUoV6
	MT0m5o0+yCmtUAAdJig84iEQ2CMdWSi9uJiwIZc/lvWd0y7Thqje9EI/S+b53yLKg2N2BQ
	SPYXFfLNWChbsoEa5DkFdgeZoKed6Cxk+G+sClsHovIaBntWon8wjU3x6T1SEhuyAA1mW7
	+rgJ9DeGpwdtTa00A7bunk187bK4IM5oW1fcDJNYkTlmwy7RWIZ7mMBY2kUJ/w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659126963; a=rsa-sha256; cv=none;
	b=IH+h0Vr4pk1YiU6qRPmrSQbqiSAl+ebx5ohokhx34eVAV9NVUTs4mnV0fkEbCfVGuIubp1
	pFMwMXgvydbW+FV8OWoMinBOnmKTWaGtcNhsVY3W7ipmUj3DTbIRAIo8Vnp1JZybli+CGr
	TjgR1j3X72X0JoDpSaHyEus5TfVTDYLXNFCaj7E1xpx31DvEB3IO/FjFcSyUCrjktXv5fO
	ixHpA2B5slo90hfyY4nf5LzcpRs3z+ySjvCZDOuDcQgnXJffvEJjV+/skKA4I6nLhaay0A
	tF6CcRG9yCVk5lZr3GWwvTDdIEOKigCtgFy2kE1jUiJjwZ50VUGjzphGngfm3Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000003e495605e4f799d1
Content-Type: text/plain; charset="UTF-8"

Hello,

current b07a48d4f3a1:
---
link_elf_obj: symbol linuxkpi_cfg80211_bss_flush undefined
linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type

iwlwifi0:  mem 0xb4498000-0xb449bfff at device 20.3 on pci0
iwlwifi0: could not load firmware image 'iwlwifi-QuZ-a0-hr-b0-72.ucode'
iwlwifi0: File size way too small!
iwlwifi0: successfully loaded firmware image 'iwlwifi-QuZ-a0-hr-b0-71.ucode'
iwlwifi0: api flags index 2 larger than supported by driver
iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37
iwlwifi0: loaded firmware version 71.058653f6.0 QuZ-a0-hr-b0-71.ucode
op_mode iwlmvm
iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x351
iwlwifi0: Detected RF HR B3, rfid=0x10a100
iwlwifi0: base HW address: 6c:6a:77:df:09:21
linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type
---

Cheers,

Nuno Teixeira

--0000000000003e495605e4f799d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

current b07a48d4f3a1:=

---
link_elf_obj: symbol linuxkpi_cfg80211_bss_flush u=
ndefined
linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file=
 type

iwlwifi0: <iwlwifi> mem 0xb4498000-0xb449bfff at device =
20.3 on pci0
iwlwifi0: could not load firmware image 'iwlwifi-QuZ-a0=
-hr-b0-72.ucode'
iwlwifi0: File size way too small!
iwlwifi0: suc=
cessfully loaded firmware image 'iwlwifi-QuZ-a0-hr-b0-71.ucode'
=
iwlwifi0: api flags index 2 larger than supported by driver
iwlwifi0: TL=
V_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37
iwlwifi0: loaded firmware ve=
rsion 71.058653f6.0 QuZ-a0-hr-b0-71.ucode op_mode iwlmvm
iwlwifi0: Detec=
ted Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x351
iwlwifi0: Detected RF HR =
B3, rfid=3D0x10a100
iwlwifi0: base HW address: 6c:6a:77:df:09:21
link=
er_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type
=
---

Cheers,

Nuno Teixeira


--0000000000003e495605e4f799d1--

From nobody Fri Jul 29 20:41:15 2022
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 4LvfYz4PbRz4CHTY;
	Fri, 29 Jul 2022 20:41:27 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LvfYz32Lmz3H1p;
	Fri, 29 Jul 2022 20:41:27 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659127287;
	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=KjQFveYa5oi5gHd6M25P7unxhDa+3CHoMEI59UP0tgI=;
	b=XHUrHa7E9E2h4D+YjmxjSzxkRuHnv4Wex3fi76c/DXDWMNyrRekjR7IQjBXgfj9Ol9pOdK
	5Hox27woK7eWnyE6jiDYpDnbo3bhJwKqZbh3qDkHzIhkYMLQ2Ie7KT9SVajqfo/nKrlwyR
	2N7Oun+yJNlxvBAvH6OP1Z3gDIAEohaa8+gn/7Y1dlMUEl4UO8c9KW/WvnzQITc3l9mFnq
	xrGiH02591srEDxJ5RLmCEzdMY2OBGz9gI7mgZuRwLNwCG2h9a2y6To2hvs9OyJXaWCrvT
	8asqRLyVfQKyXq7G2hvV4jlOy4EA3Pey9oxaR0HMMtkW3JZH6Dfz/64g5sVgZg==
Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LvfYz1zxPzvFX;
	Fri, 29 Jul 2022 20:41:27 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f43.google.com with SMTP id k129so5735037vsk.2;
        Fri, 29 Jul 2022 13:41:27 -0700 (PDT)
X-Gm-Message-State: AJIora8ldIsaKlUVASJwr6dYIqeWvjfKF17uoi8/oW8VplhOiY9epn/R
	3IeNdzEFLtj6e4PmGx18cnzdq9R+YCv80AwLixE=
X-Google-Smtp-Source: AGRyM1v0YNFZOiFL4NsBuJ3XJN1y/bCB9Am0P3l86xrHxGmbhUP1oFbdn1LBllrsxDC9Ixh0a/T9LlaJe85ZGasJAFE=
X-Received: by 2002:a67:f7d3:0:b0:35a:2a5c:488d with SMTP id
 a19-20020a67f7d3000000b0035a2a5c488dmr2215439vsp.51.1659127286946; Fri, 29
 Jul 2022 13:41:26 -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: Nuno Teixeira 
Date: Fri, 29 Jul 2022 21:41:15 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: iwlwifi fails to load @b07a48d4f3a1
To: freebsd-wireless@freebsd.org, 
	FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="00000000000093687a05e4f7ac24"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659127287;
	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=KjQFveYa5oi5gHd6M25P7unxhDa+3CHoMEI59UP0tgI=;
	b=knZWqifsKHCfLj6jYzBYDDx/lLgYro5OOpfhIBTfzV+30DevUwzmhL4n+/NpGI7yscsBLh
	cb32fUdtepPLFANlQ6ClGzpruT2IaP8VHG+Lff/C2wq3mPMizZeERWWFaqNmmT38sOu3ue
	nJLn1Z2baJfOEOWvP6aB/1Ii+e1CclNBY3VdGxMMQgvFpPvm2f2Yo+qd2W7tllw7mSMgqU
	clh9pp0/DtwdAmCV+KIWNBL5fShv6dCc6VH57tMGd8wmscW27DvZoNONIVi3BEqXgQwwzM
	C9RyNoi74yUeJ6z+C3OETicTF6owj+stKzgVt0+LKuqFk6EP2+IPdb41APOmzA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659127287; a=rsa-sha256; cv=none;
	b=xQwwUgze3zsxlFApLpvtQS6oaKDbufksgXXYsNByTcVKzsZZPzHXv6m4i+zInV8wZZAJj2
	udv5dm3WxIoiT+5G+jSDFsG2gWHLvbfRAhwycHsJTSvsgnVg/GrqaYLG1gBFhhmmEWheF+
	ur4//ir/8hSaP8X9XyZxAovLaA02mZC+IENVSUOCUzajOpBNr4Hf9uWuYdPv9MBbNaCY7l
	sj6JHDSeUn5fHkBehiORD8jW0VnES9hNTCZTqzvg/stYi5A76Y8ooCAvkSTC9n14M5sD5H
	51HBW1CcGtpqkisVh8HUQCXOjmtfSDT29a8ztVBpYut3s/oy8mk/rF5qcTHLXg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--00000000000093687a05e4f7ac24
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Correction, it include old dmesg messages:

link_elf_obj: symbol linuxkpi_cfg80211_bss_flush undefined
linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type

Cheers

Nuno Teixeira  escreveu no dia sexta, 29/07/2022 =C3=
=A0(s)
21:36:

>
>
> ---------- Forwarded message ---------
> De: Nuno Teixeira 
> Date: sexta, 29/07/2022 =C3=A0(s) 21:35
> Subject: iwlwifi fails to load @b07a48d4f3a1
> To: FreeBSD CURRENT 
>
>
> Hello,
>
> current b07a48d4f3a1:
> ---
> link_elf_obj: symbol linuxkpi_cfg80211_bss_flush undefined
> linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type
>
> iwlwifi0:  mem 0xb4498000-0xb449bfff at device 20.3 on pci0
> iwlwifi0: could not load firmware image 'iwlwifi-QuZ-a0-hr-b0-72.ucode'
> iwlwifi0: File size way too small!
> iwlwifi0: successfully loaded firmware image
> 'iwlwifi-QuZ-a0-hr-b0-71.ucode'
> iwlwifi0: api flags index 2 larger than supported by driver
> iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37
> iwlwifi0: loaded firmware version 71.058653f6.0 QuZ-a0-hr-b0-71.ucode
> op_mode iwlmvm
> iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x351
> iwlwifi0: Detected RF HR B3, rfid=3D0x10a100
> iwlwifi0: base HW address: 6c:6a:77:df:09:21
> linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type
> ---
>
> Cheers,
>
> Nuno Teixeira
>

--00000000000093687a05e4f7ac24
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Correction, it include old dmesg messages:
=

link_elf_obj: symbol linuxkpi_cfg80211_bss_flush undefinedlinker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type

Cheers

<=
div dir=3D"ltr" class=3D"gmail_attr">Nuno Teixeira <eduardo@freebsd.org> escreveu no dia sexta, 29/07=
/2022 =C3=A0(s) 21:36:


---------- Forwarded message ---------
De: Nuno Teixeira &l=
t;eduardo@freebsd.=
org>
Date: sexta, 29/07/2022 =C3=A0(s) 21:35
Subject: i=
wlwifi fails to load @b07a48d4f3a1
To: FreeBSD CURRENT <freebsd-current@freebsd=
.org>


Hello,

current b07a48d4f3a1:
---
link_elf_obj: symbol=
 linuxkpi_cfg80211_bss_flush undefined
linker_load_file: /boot/kernel/if=
_iwlwifi.ko - unsupported file type

iwlwifi0: <iwlwifi> mem 0x=
b4498000-0xb449bfff at device 20.3 on pci0
iwlwifi0: could not load firm=
ware image 'iwlwifi-QuZ-a0-hr-b0-72.ucode'
iwlwifi0: File size w=
ay too small!
iwlwifi0: successfully loaded firmware image 'iwlwifi-=
QuZ-a0-hr-b0-71.ucode'
iwlwifi0: api flags index 2 larger than suppo=
rted by driver
iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37iwlwifi0: loaded firmware version 71.058653f6.0 QuZ-a0-hr-b0-71.ucode op_=
mode iwlmvm
iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x35=
1
iwlwifi0: Detected RF HR B3, rfid=3D0x10a100
iwlwifi0: base HW addr=
ess: 6c:6a:77:df:09:21
linker_load_file: /boot/kernel/if_iwlwifi.ko - un=
supported file type
---

Cheers,

<=
/div>
Nuno Teixeira






--00000000000093687a05e4f7ac24--

From nobody Fri Jul 29 21:00:38 2022
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 4Lvg0s5F9Bz4CLmq;
	Fri, 29 Jul 2022 21:01:17 +0000 (UTC)
	(envelope-from ricera10@gmail.com)
Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lvg0s0TRyz3Lh6;
	Fri, 29 Jul 2022 21:01:17 +0000 (UTC)
	(envelope-from ricera10@gmail.com)
Received: by mail-pj1-f51.google.com with SMTP id q7-20020a17090a7a8700b001f300db8677so6336523pjf.5;
        Fri, 29 Jul 2022 14:01:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc;
        bh=iwVZUAEJDr08IeoM1hh37hkBe0zn/OrciGAUlJ0j788=;
        b=73FR198IdSvBK71z1NSbBUf8UAY1r+g4kbMNS37Y37RR+wt0AbntQ45ZYwCcxXLAnC
         F5ESgmMWvkdDHY+ga+hBmqyOBvysjUXfSVF+CiZuyXVOHsnbb3pTcekz2mO4RBKQ1jHN
         yh10SU6Ci+GnTm97yHp3pisehS2f2LqAAM+DIRPExVgwBXndcT+x83XrzzePax6XgkHa
         7rLjVfwUgrKL5tgw63yQq4ZUkLOGC4GJcbjfd1634hF5gDUicEL8aC4N1/HF3g+daMen
         XFg3xkR413ssxPu8OKzF9KjQCAG7WRJuC0qzNsMD62b7D7jicnSXc/iSWf3R546EVBoo
         0uKg==
X-Gm-Message-State: ACgBeo0uj2VeovGSNmbe39eC8WOWuy7UAgV17EyjR5HGg5kaLtUIZY1c
	SxzYWasPSSmzsOhOabDaA1MQWHMR8NE=
X-Google-Smtp-Source: AA6agR6pHvXIzUfLeuSeFi0JwihRG5cMLk3dbxr1HL//Mj4sGeZPpBMNAJEA8km/6Jon/3Xh63+FDA==
X-Received: by 2002:a17:90b:4f4e:b0:1ef:ab40:b345 with SMTP id pj14-20020a17090b4f4e00b001efab40b345mr6148215pjb.226.1659128474965;
        Fri, 29 Jul 2022 14:01:14 -0700 (PDT)
Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com. [209.85.214.172])
        by smtp.gmail.com with ESMTPSA id u10-20020a17090a6a8a00b001eafa265869sm6267996pjj.56.2022.07.29.14.01.14
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 29 Jul 2022 14:01:14 -0700 (PDT)
Received: by mail-pl1-f172.google.com with SMTP id y15so5603922plp.10;
        Fri, 29 Jul 2022 14:01:14 -0700 (PDT)
X-Received: by 2002:a17:90b:4d05:b0:1e2:bf91:8af2 with SMTP id
 mw5-20020a17090b4d0500b001e2bf918af2mr6175566pjb.210.1659128474142; Fri, 29
 Jul 2022 14:01:14 -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: Eric Joyner 
Date: Fri, 29 Jul 2022 14:00:38 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Looking for feedback on change to iflib and transmit queuing
To: freebsd-net , FreeBSD Current 
Content-Type: multipart/alternative; boundary="000000000000568da205e4f7f300"
X-Rspamd-Queue-Id: 4Lvg0s0TRyz3Lh6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of ricera10@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=ricera10@gmail.com
X-Spamd-Result: default: False [-3.03 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.99)[-0.995];
	NEURAL_HAM_LONG(-0.94)[-0.941];
	FORGED_SENDER(0.30)[erj@freebsd.org,ricera10@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RWL_MAILSPIKE_GOOD(-0.10)[209.85.216.51:from];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.216.51:from,209.85.214.172:received];
	MLMMJ_DEST(0.00)[freebsd-net@freebsd.org,freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCPT_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	FROM_NEQ_ENVFROM(0.00)[erj@freebsd.org,ricera10@gmail.com];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000568da205e4f7f300
Content-Type: text/plain; charset="UTF-8"

Hi, I have a Phabricator review here that I was hoping to get some feedback
on: https://reviews.freebsd.org/D34742

In short, there's already some functionality in current and 13.1-RELEASE
that allows a driver to pick a TX queue for a packet, but this extends that
support to have iflib do some limited parsing in order to give the driver
function extra information in order to make a decision. Performance-wise
this doesn't seem to affect much; I looked at it in VTune across different
types of netperf runs with small packets that want L4 checksums.

In fact, that made me find out that iflib_parse_header() does tons of
unnecessary m_pullups() on small UDP packets; as much as 10% of the CPU
time can be spent just doing that. It should maybe get modified to not
pull-up to the TCP header length for UDP packets.

- Eric

--000000000000568da205e4f7f300
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi, I have a Phabricator review here that I was hoping to =
get some feedback on:=C2=A0h=
ttps://reviews.freebsd.org/D34742

In short, there=
9;s already some functionality in current and 13.1-RELEASE that allows a dr=
iver to pick a TX queue for a packet, but this extends that support to have=
 iflib do some limited parsing in order to give the driver function extra i=
nformation in order to make a decision. Performance-wise this doesn't s=
eem to affect much; I looked at it in VTune across different types of netpe=
rf runs with small packets that want L4 checksums.

In fact, that made me find out that iflib_parse_header() does tons of unne=
cessary m_pullups() on small UDP packets; as much as 10% of the CPU time ca=
n be spent just doing that. It should maybe get modified to not pull-up to =
the TCP header length for UDP packets.

- Eric


--000000000000568da205e4f7f300--

From nobody Sat Jul 30 14:20:34 2022
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 4Lw6471s3Hz4XnFR;
	Sat, 30 Jul 2022 14:20:39 +0000 (UTC)
	(envelope-from bz@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lw6471Lwrz4D3j;
	Sat, 30 Jul 2022 14:20:39 +0000 (UTC)
	(envelope-from bz@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659190839;
	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=kaEF2NLu6oc9/mWUNdslWu86MUtM6so3dMeMT5XDsMk=;
	b=WtV75w9DwPJWEI6fG/vDJ0bExoB07oMN8s5f3jzHWc6SCs1JFRbdPz1e2AVdEhiN+T78hz
	RI3DV6mVMTqf8Mvxbew0mzBkQUuYZC9KN2uY/2ZSwIRQklbyPHRH4PaMj0PMR8tPOG6spz
	90vv2FkIgLuXEEoJoEWA4JiHXBkpsBLJG8atU+NjZVtDEWG/SE+O3Hf+u9L0AKIHwSynfm
	V0b2gXN2DL1CL9W19IZdJ2lmwr2oW+pCyXbeWY37A02GzL939Do6hnxFV05dWkznfLE67D
	wYvjmULvR95gk4IY3sJYOkS9Pd/6czAGsY6yCG3fctBD8ZL5fyS/tHQRXGo2LQ==
Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified))
	(Authenticated sender: bz/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Lw6466ms2z1BQP;
	Sat, 30 Jul 2022 14:20:38 +0000 (UTC)
	(envelope-from bz@FreeBSD.org)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587])
	(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.sbone.de (Postfix) with ESMTPS id 72D8F8D4A214;
	Sat, 30 Jul 2022 14:20:37 +0000 (UTC)
Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPS id 87EC8BD42CE;
	Sat, 30 Jul 2022 14:20:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587])
	by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024)
	with ESMTP id EKqKiZ1A_bKF; Sat, 30 Jul 2022 14:20:35 +0000 (UTC)
Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPSA id EBF7CBD3C10;
	Sat, 30 Jul 2022 14:20:34 +0000 (UTC)
Date: Sat, 30 Jul 2022 14:20:34 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: Nuno Teixeira 
cc: freebsd-wireless@freebsd.org, 
    FreeBSD CURRENT 
Subject: Re: iwlwifi fails to load @b07a48d4f3a1
In-Reply-To: 
Message-ID: 
References:   
X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-729671337-1659190835=:68830"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659190839;
	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=kaEF2NLu6oc9/mWUNdslWu86MUtM6so3dMeMT5XDsMk=;
	b=ckM56Rd1r/Ie750+Y3Bab+BxYnIHpZw2KgLF4OsvMw0otohIyPfHh5WY2x/OlF8kdV/siP
	94hN4lw00JBwuuY108O3qFKPerl14YAArjJ8WnD4K3edELBv9ws/j9OxvFG5LYC9lwXFFT
	iLNFr38nF2ifi0X2ZZAQkSRYBWfVPSEQSxB3XNh7MIZ+8lsM4ZLr/MkQ6w937DIRXZ6/Fr
	5hOzWSNHsnjM+qFEHEsGO6U24A63R555kTtnFeuRGKsSMCu/+9HIzbcvJyzMvkj+S2fUgr
	BMjZTDNPSXNZRpM/Cb96tdvpWbjEm0zfoONLTIb7V4NpOmotNRYoLgrvIiWtnw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659190839; a=rsa-sha256; cv=none;
	b=F7+6eROmHNrhub5CHq4Adi29Q2IXUmB79Jl9DzkU4Km64fl5d+vNtnp1P+lM3lHsfx6a6h
	mW8waqvcl90cJPowuCF45xm02zQpnRqRJCmvGXRvmZMfOT+/0IzqhWInmsKv2e/EmXyI/H
	PHcRTMJJTjR/sMi/PsMnX8zdd+GR1QNmfnEDCjNLR8T0ez4ZhMPKK6eaqOTpLOYa4blAgp
	RmETkQJ47/6TFi0E6ercBDufEvFbIp55T+hq5KaVEqf4a8g76yGzfnT2TiaV1HHSSrz+ta
	0Vr0FQUe4N81gR8EhT7iJTUX5Rw47UiQIkm9FQOGXMhAFwv/ih0UpxnU7g5MFw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-729671337-1659190835=:68830
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Fri, 29 Jul 2022, Nuno Teixeira wrote:

> Correction, it include old dmesg messages:
>
> link_elf_obj: symbol linuxkpi_cfg80211_bss_flush undefined
> linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type

Whooops.  Sorry.  I'll fix that in a few minutes.



> Cheers
>
> Nuno Teixeira  escreveu no dia sexta, 29/07/2022 à(s)
> 21:36:
>
>>
>>
>> ---------- Forwarded message ---------
>> De: Nuno Teixeira 
>> Date: sexta, 29/07/2022 à(s) 21:35
>> Subject: iwlwifi fails to load @b07a48d4f3a1
>> To: FreeBSD CURRENT 
>>
>>
>> Hello,
>>
>> current b07a48d4f3a1:
>> ---
>> link_elf_obj: symbol linuxkpi_cfg80211_bss_flush undefined
>> linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type
>>
>> iwlwifi0:  mem 0xb4498000-0xb449bfff at device 20.3 on pci0
>> iwlwifi0: could not load firmware image 'iwlwifi-QuZ-a0-hr-b0-72.ucode'
>> iwlwifi0: File size way too small!
>> iwlwifi0: successfully loaded firmware image
>> 'iwlwifi-QuZ-a0-hr-b0-71.ucode'
>> iwlwifi0: api flags index 2 larger than supported by driver
>> iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37
>> iwlwifi0: loaded firmware version 71.058653f6.0 QuZ-a0-hr-b0-71.ucode
>> op_mode iwlmvm
>> iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x351
>> iwlwifi0: Detected RF HR B3, rfid=0x10a100
>> iwlwifi0: base HW address: 6c:6a:77:df:09:21
>> linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type
>> ---
>>
>> Cheers,
>>
>> Nuno Teixeira
>>
>

-- 
Bjoern A. Zeeb                                                     r15:7
--0-729671337-1659190835=:68830--

From nobody Sat Jul 30 14:32:58 2022
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 4Lw6LR0HlQz4XphZ;
	Sat, 30 Jul 2022 14:33:03 +0000 (UTC)
	(envelope-from bz@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lw6LQ6s7lz4Gb1;
	Sat, 30 Jul 2022 14:33:02 +0000 (UTC)
	(envelope-from bz@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659191583;
	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=9OiijiDbPzg4PvfJEQpLi28sllxDjV0WyLrnWtYVw4g=;
	b=cTeQk4uwYb3vSSNUqtZHFCz+aBIJGFbsNTgrXOpNKqEnY0bC2wtuwwxYVxOvRQjiwx2zVb
	fvtwsWafgLS8Law2T7WjXFVzimbQ+Qq/Jo8tPkdtbhj85NX5Z+rbNRVzaUrBbK7xUiU9To
	ZurD2lNg8ju9Wb+/Gbw4zepitn75opL5rqPrzaSdBkI4fW7TUa4/c2UvTte9/9mYvhr/9X
	VVD6TNQxvrqHXEPvHqrAOKB4AzdMRkkdQXH8cTpzxxM/nfo6JqrZr8uI/TPBq4dE5qqprw
	NDEfdF9dZ1AGEXTwWcmP2cT4ucCgJVdYgVi0BlFBotu8s9/IfFi9nR9JnL1UpA==
Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified))
	(Authenticated sender: bz/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Lw6LQ5HXhz1CKn;
	Sat, 30 Jul 2022 14:33:02 +0000 (UTC)
	(envelope-from bz@FreeBSD.org)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587])
	(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.sbone.de (Postfix) with ESMTPS id 890438D4A214;
	Sat, 30 Jul 2022 14:33:01 +0000 (UTC)
Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPS id E6A06BD42D4;
	Sat, 30 Jul 2022 14:33:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587])
	by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024)
	with ESMTP id TQizydHl3fqE; Sat, 30 Jul 2022 14:32:59 +0000 (UTC)
Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPSA id AAD10BD421D;
	Sat, 30 Jul 2022 14:32:59 +0000 (UTC)
Date: Sat, 30 Jul 2022 14:32:58 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: Nuno Teixeira 
cc: freebsd-wireless@freebsd.org, 
    FreeBSD CURRENT 
Subject: Re: iwlwifi fails to load @b07a48d4f3a1
In-Reply-To: 
Message-ID: 
References:   
 
X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659191583;
	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=9OiijiDbPzg4PvfJEQpLi28sllxDjV0WyLrnWtYVw4g=;
	b=n9HAm0y1A4ZZwBH4QccaXpCmlzLbyr+H1svrlKG/Z0SCMe8ADFtalDoDuFgWm2ex/ZWhpa
	2zrhXR1X9IV5qPvSDosYuhndjshyZb3IJBDDQNK6MorwoVD0v8Hh3d8krUngeXU34WHySM
	x3kZKJKk1Ru0yLAo5dnmL5sLsSPylzlnygdUBH2SYP73fylGoLDnbIIYeq8UqTZrYZkd3H
	F+g9jqyyE7HQe0J3r8ETjOJGpkY/bp3ygbI913YxO6sretwSM9gos0kXXywQ2XYE98MvRG
	9kl8iI8H39EtTKCw/gX9oxDC6fBh7OcBbiirPCAdq4MUmad+HV7wH+j+fhpg3g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659191583; a=rsa-sha256; cv=none;
	b=D3ooVphTEelssTqXxBaXxiYB+W5jjMAkJiIQU5uKmeJ/WadOo089jaX608PAORe1YCd56J
	nwE7UW66ahSJY2cT5OZttWpdMb6zaheHr8uY2WRuHd6O/FJvkXshvRt5/fIOLBSCuH+ElP
	YFDKZUKTA5vl7o4aNSpyW3+Q89KNfGy65bFCuXH8BbY1g3dw3MqWRHZFjPuO/oOWsxONGF
	Ovu9Lszf8D3pfeph2a0cKW0ij6UG8g9t6sE3ea4lyYEsBFYAiX9MxnVbHBQwO49S/eyXQx
	qgQMNdyYSNlSvGwDbgsOXFPMAclRbMfKoEGrYwVQa4vBwxkqYqmC3xrcbBzPYQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On Sat, 30 Jul 2022, Bjoern A. Zeeb wrote:

> On Fri, 29 Jul 2022, Nuno Teixeira wrote:
>
>> Correction, it include old dmesg messages:
>> 
>> link_elf_obj: symbol linuxkpi_cfg80211_bss_flush undefined
>> linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type
>
> Whooops.  Sorry.  I'll fix that in a few minutes.

Hopefully done in
https://cgit.FreeBSD.org/src/commit/?id=d8dd6b329e4653a2aca308102187797d44afc2c4

Otherwise please reply so I can see it when I am back home tomorrow.
/bz

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Sat Jul 30 19:38:31 2022
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 4LwF7766mRz4XRXQ;
	Sat, 30 Jul 2022 19:38:43 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LwF775ZPrz3mWL;
	Sat, 30 Jul 2022 19:38:43 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659209923;
	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=pwLoydrOQ8r1DaU7IoIygoTNAj2ExJ17wrAUpm4kSU8=;
	b=CgxdRvwGoqjAmYB6P5GZOye/oxVg2Isg43UpNaLgWfqzQhLfJs8Zu9C+TGKFPH8kQHmZsy
	7ZBPX14NeulsASNbC9LU3XetPx2WwqYd+6ZlXDCfB0uo9/DOfKIRiNKWOUS9LAhjd1Hd8Q
	+wJWYsmTtYpC2l1h3ddq4I1njNi/+wJG2XcSqZvQBppakpEa65dhJiG7UPbpYq/Y8L9Epe
	IOQzyxspl+HskPVfpqQL1NJXp87maZIAIMk1dizJyfOD9/I1YMdWntGruCQgqHVDcXyzqH
	Rg9QbvYwsNsn17pkvmoDnWk2L6iTypNQTGLx+Gt7UG7g+ZV6A/DYxxOTwLcpvw==
Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LwF774Lj2z1Hjn;
	Sat, 30 Jul 2022 19:38:43 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f48.google.com with SMTP id d187so7629974vsd.10;
        Sat, 30 Jul 2022 12:38:43 -0700 (PDT)
X-Gm-Message-State: AJIora+osmUzoYIyH7KAMICuHPG92zqRUX1+Cd9eMy7Q/DIKrv1op3gA
	wKGuTixsQDTsYorjcXCmPdhmaeAqMK19p9FVkEc=
X-Google-Smtp-Source: AGRyM1viL6LtOTK+U14q8IVuw3xcek59jUt264Z7FXiduIB1Hwlvf1xtUWChV09TTx8aMpMSSl2uo/11rDQXDVSKHhM=
X-Received: by 2002:a05:6102:3e0d:b0:358:5c4f:5253 with SMTP id
 j13-20020a0561023e0d00b003585c4f5253mr3316806vsv.58.1659209923167; Sat, 30
 Jul 2022 12:38:43 -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: Nuno Teixeira 
Date: Sat, 30 Jul 2022 20:38:31 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: iwlwifi fails to load @b07a48d4f3a1
To: "Bjoern A. Zeeb" 
Cc: freebsd-wireless@freebsd.org, 
	FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000140aba05e50aea55"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659209923;
	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=pwLoydrOQ8r1DaU7IoIygoTNAj2ExJ17wrAUpm4kSU8=;
	b=QB0p1QtT2wjNvct4XHKZdr/QkrkNV57vwMml1JOEpsp3+Sxpy05HSogFGEyyWxtDw6H8/y
	cKuIah4YmEfJiUrV3jRAGIBaOH8vdNhJmQ7BIfQ07GvBymqPEvSMrFIkIU8KmtDIgU6v2m
	b/VxxLCQd3BECeIUEsiool6T84c9Jj5CwSn+FiUNLgQKCAzxXB3HVpD9iGEijZC1r1nexm
	oK4AaP/crX0IJaSC9M7xJ6txu4u9aDr5XiLsayOiilmb9USZkymnDdedBVZ2O5W/9KVGe4
	GHK4AFfwpqjKQweiqL0NITLA7QjPnzJM1rdzrRg/V6W1opW1KVf1A3JnwW9DmQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659209923; a=rsa-sha256; cv=none;
	b=TxvJcutcqxqRJWi2zH84am5IvPMD/bQXkJ0bSyvHpZpgOhshdCI1zuAhzfWzg7kb1o1PjD
	KY2s7tO5UnodMHUyUWOQ3JUUfXJ5h2O6hjUZHZmcLRg/MGBkBzgEFgt7/4STJGb+oh5WUX
	dkx4gYkasFXDaj3uaM5Dc29en1zv0sooy0am5m/CY9CWm9j7Skq+VF9YPfCbeyNjr/Itbm
	XFuYtZqVEVHYn+b9vrcuAmcIASpXDDiZtYNMF83JdXFJWpKC6weAa8tVDVM0n3VIZWlle6
	nhOaVeFEsGZ5BQXIWKlyqpwZTm3f1u7qUAK8rygwQMeXw+ZSAKnS3OFP6AHYkw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000140aba05e50aea55
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Bjoern!

Thanks a lot for ultra fast fix! It's working ok.

Cheers

Bjoern A. Zeeb  escreveu no dia s=C3=A1bado, 30/07/2022 =C3=
=A0(s)
15:33:

> On Sat, 30 Jul 2022, Bjoern A. Zeeb wrote:
>
> > On Fri, 29 Jul 2022, Nuno Teixeira wrote:
> >
> >> Correction, it include old dmesg messages:
> >>
> >> link_elf_obj: symbol linuxkpi_cfg80211_bss_flush undefined
> >> linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file type
> >
> > Whooops.  Sorry.  I'll fix that in a few minutes.
>
> Hopefully done in
>
> https://cgit.FreeBSD.org/src/commit/?id=3Dd8dd6b329e4653a2aca308102187797=
d44afc2c4
>
> Otherwise please reply so I can see it when I am back home tomorrow.
> /bz
>
> --
> Bjoern A. Zeeb                                                     r15:7
>

--000000000000140aba05e50aea55
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Bjoern!

Thanks a lot f=
or ultra fast fix! It's working ok.

Cheers
=


Bjoern A. Zeeb <bz@freebsd.org> escreveu no dia s=C3=A1bado, 30/07/2022 =C3=A0(s) 15:33:
On Sat, 30 Jul 2022, Bjoern=
 A. Zeeb wrote:



> On Fri, 29 Jul 2022, Nuno Teixeira wrote:

>

>> Correction, it include old dmesg messages:

>> 

>> link_elf_obj: symbol linuxkpi_cfg80211_bss_flush undefined

>> linker_load_file: /boot/kernel/if_iwlwifi.ko - unsupported file ty=
pe

>

> Whooops.=C2=A0 Sorry.=C2=A0 I'll fix that in a few minutes.



Hopefully done in

https://cgit.FreeB=
SD.org/src/commit/?id=3Dd8dd6b329e4653a2aca308102187797d44afc2c4



Otherwise please reply so I can see it when I am back home tomorrow.

/bz



-- 

Bjoern A. Zeeb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r15:7




--000000000000140aba05e50aea55--

From nobody Sun Jul 31 18:40:21 2022
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 4LwqnY3dYpz4Y1Lr;
	Sun, 31 Jul 2022 18:40:33 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LwqnY39g6z3DrF;
	Sun, 31 Jul 2022 18:40:33 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659292833;
	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;
	bh=JVWTotYcuXkn2l0bEKE1E7b5YOz7BSWOxieqJppAMb8=;
	b=Lb6yaAhlTJxsVs/ZVXatPcU+x7N9xH6GG+UlTUY0wViYZIv99eXBriKhjXCkOxT64Kw05M
	qpJj9DjKfwlaUtj1sPhVIvjdBK/Gfj2HZ7ZgG2N9OdFyMVI9MZj66qiH8qb55Tv4+qhd74
	YUXasCqj8rYE8pSA1+W3aXufRvbFIGOb6RVaILv1v+Q/Sz2ThR2iPr8kDtEc5bchePbcrf
	QIn58jrHwQk1GQLa9oPMBLA3Rl1Vic29Tp1/GzSByJMP9wFreKq39A2nk+Jgl0tKct+jj2
	V/miYhmbUoky6/T6SXjkNcSN6WutwggbcGTiRG5OI3f8ibKXlaRQWvuJ8qsmzA==
Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LwqnY25g7zhM8;
	Sun, 31 Jul 2022 18:40:33 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f176.google.com with SMTP id e3so2496681vkg.4;
        Sun, 31 Jul 2022 11:40:33 -0700 (PDT)
X-Gm-Message-State: ACgBeo0KqvCpoeWGx6+BiZKTrt7+ZX+y0phvC5RMYwld/NpUOAQIOudp
	gjE3+DIAV1Uml6omXm84MWNde80PgJ401fJB4N0=
X-Google-Smtp-Source: AA6agR7ZdEAg8KmCIzLwSeNTX3EkFaXJcLpGM7ZmQPYK5TjmBbDR6ZvG+9I2DUiUPyDf/Ae4DDKEC/P6ckLoqvJ+mSQ=
X-Received: by 2002:a05:6122:ce:b0:377:4e0f:a037 with SMTP id
 h14-20020a05612200ce00b003774e0fa037mr1565660vkc.5.1659292832816; Sun, 31 Jul
 2022 11:40:32 -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: Nuno Teixeira 
Date: Sun, 31 Jul 2022 19:40:21 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Lenovo Legion 5i speakers support
To: freebsd-hardware@freebsd.org
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000e0e30d05e51e3775"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659292833;
	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;
	bh=JVWTotYcuXkn2l0bEKE1E7b5YOz7BSWOxieqJppAMb8=;
	b=gwIqW2FVWJLNirViUOMUMsDA3kn0tu9+cvusPd8mp0vLmCuqWUR+g4coxPshjUOeQ0XNrf
	zlb6BaVmRJpD2kP+7tTSqdwsVU2ZX/7d9hixLw9Gf/Qvx4ZuP3ZNEySF8ELYdiK9405Bbz
	sa8t+iRtIFMHqshTF/CyFDBS5e5rljI+SDKh7G+ubiERPUBSg3VmG+5NFT+sYCcNgXfT8I
	T4McCZ0xyKCkOGeowNgEcCG5ATJ6zlVUFdc92WcWTNVpiuhJkao2P+MdUS6Bec+PAsvMDt
	nZtfcnMx+Dy9gZqLEzvQJ5OZLR16IrEiI7rP9wyWzNEbTHaIvgVjCJEKn1aXJA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659292833; a=rsa-sha256; cv=none;
	b=J/taWOthOetjpF3dfHM4N0R3gDhZdYsoqtuX61hlKQprvWfQaYSu5Bl6C2FIcXXWR5DddL
	AUdKcfZv4J3DxZiXBrz/2za7brrlYwhmE18zNyfP2g/atntd4uslBGftqso4qd4X/tVvzQ
	MkI3/cI07QgkdBsoVrVdVckNF+rhLfnTJDuHSWjv75w6HAylEOjRU3c9K1+bO+ZWkHGOgK
	htEl7PraQ0N/jl8iR4sqxAPDLdT/8p5jXR6IfPhiz2YWYwubmVerCCVQCMMYq4BN6kPRDd
	6+aoVJ+5TwF4h8+iTabxq55dKe+GB82OTcSVxnQCYJ+9s1QL6cehqTCEi/0iCQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e0e30d05e51e3775
Content-Type: text/plain; charset="UTF-8"

Hello,

Review D30333  added support for Lenovo
Legion 5 AMD speakers.

I'm trying to add/test support for same laptop INTEL version that could be
share same hardware setup.

Any tips to hack sys/dev/sound/pci/hda/hdaa_patches.c so I can test it?
Legion 5i system logs 

this is part of code included for ENOVO_L5AMD
---
else if (id == HDA_CODEC_ALC257 &&
            (subid == LENOVO_L5AMD_SUBVENDOR)) {
                switch (nid) {
                case 20:
                        patch_str = "as=1 seq=0";
                        break;
                case 33:
                        patch_str = "as=1 seq=15";
                        break;
                }
---

Cheers,

Nuno Teixeira

--000000000000e0e30d05e51e3775
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

Review D30333 added support for Lenovo Legion =
5 AMD speakers.

I'm trying to add/test support for same laptop INTEL version that co=
uld be share same hardware setup.

Any tips to hack sys/dev/sound/pci/hda/hdaa_patches.c so I can test it?<=
br>
Legion 5i system logs

this is =
part of code included for ENOVO_L5AMD
---
else if (id =
=3D=3D HDA_CODEC_ALC257 &&
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 (subid =3D=3D LENOVO_L5AMD_SUBVENDOR)) {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 switch (nid) {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case 20:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 patch_str =3D "as=
=3D1 seq=3D0";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 case 33:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 patch_str =3D "as=3D1 se=
q=3D15";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 }
---

Cheers,
=


Nuno Teixeira


--000000000000e0e30d05e51e3775--

From nobody Mon Aug  1 00:05:07 2022
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 4Lwz0J19l2z4XyTl
	for ; Mon,  1 Aug 2022 00:05:20 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lwz0J0dvWz3tDK
	for ; Mon,  1 Aug 2022 00:05:20 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659312320;
	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=gvNOBNrcD1pGrYeVWwzs+9KtetP9gOixVbF2TzpuWfs=;
	b=o9lep/GrH4bPg6e3Of0QsQFnidUz+JLxjyinm/Ax5jVE/XamPSSqc/WeE41J0UpvzfHmE9
	Vc8qGZ/YnpGxOIQ+K5YD13w3z1zsm8KqlpSsrQKCbSJGeJ5Brf7KIIU7hNDzcDnpAPtH7y
	mMbFE/mfpcWb5GMQScckEJnKR5gGIhcnMzekGqGr4IAXaw7K6oLZ7FJ9oir/2vx2fhwpS8
	FU7BpfQttbt9d0eCBi/oBS2mSMRsy3Tka6lenH00wqSV/IenpdU+40UFHM+nOMpWlyniKE
	Y8hWmRDrBvDPpHmwqnxNIWVLrKVmE8miIu3AJuR4eFEulDbs7SodJp45aN3LHw==
Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Lwz0H6YZFzmrH
	for ; Mon,  1 Aug 2022 00:05:19 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f45.google.com with SMTP id m67so2121447vsc.12
        for ; Sun, 31 Jul 2022 17:05:19 -0700 (PDT)
X-Gm-Message-State: ACgBeo1aTSngpZQX86M026y0Rb8UgzWRTbd+Vfn3OgpR4GErZmyvbpZo
	y0av63Rm5w/VozQt/NWuGaXzD79ZCN3wN5S2kSY=
X-Google-Smtp-Source: AA6agR59vdcjiqVRaVp4l2gOFvrzOFri52rrZ6nMYAdjGMbMDXeJQfzQfKjHDuGuczLbh4p71gJltZpNbqp364iXVVI=
X-Received: by 2002:a05:6102:4186:b0:383:e6ee:43ba with SMTP id
 cd6-20020a056102418600b00383e6ee43bamr933478vsb.19.1659312318959; Sun, 31 Jul
 2022 17:05:18 -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: Nuno Teixeira 
Date: Mon, 1 Aug 2022 01:05:07 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Failover Mode between ether/wlan panics
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="00000000000057d5ed05e522c101"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659312320;
	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=gvNOBNrcD1pGrYeVWwzs+9KtetP9gOixVbF2TzpuWfs=;
	b=XGxGj2Dga/8Sq/0qrkBZzzIWg/Thyl+ssUSUELgmL9ZBvIXZg3usvallpgn1MzpxDl7KR8
	80wsm7RlpFypcSVh9n/ypX9kTlFEHzAxOeFht2kV/2xwJe/Cw+BUEBkhC0Q3vT9tLotSZ5
	DODf8lmHsMS+KUrnc+NCilLP8bxpCRC0IdCVlwCWfetPI7PjyLhUUKdEbxNEwHrPn8wyeD
	2u1QEd337hehpqdPymhiJsY8niO0olpEtlHmXwfnublkvFaDSCQVxNwoNoOPihmN/X+BLs
	c8ZkJbwsLp8A+Wleh0q1XvJmCJY29C7CEGekIlRP302A4bwtuF8fIyi6iI8M9Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659312320; a=rsa-sha256; cv=none;
	b=MkBwYavcMAyh11mAFflvHUEAipUkuOTVexwGnU8oLkl0ZOG6yMrULmhjE45NR6df6c+V3g
	vx2PoXhC4VPMf+OYl8ZSDTh3WDtzZ0KhwJg8uAO8j7s/fLz39pFtIc32BqSQrCTrX6ab4P
	VfSjpIgubCZszq67bQ7cfZKnf/4XEMQy7KHCHjXFCevtFZoNyMVhBzAWbkgUELHvceI1sZ
	yXybHXyqqG7EC1p3mXlpDvzgqSAVQpUidT7oiDqXWJCH1HzxSp8j9Qeb5veCUSFVOT/dU1
	Q995JkvyuevRYrpbto0kYJ45WJs8Y/0llz09cpI5EKD+lq6RGUATn13VynktXg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--00000000000057d5ed05e522c101
Content-Type: text/plain; charset="UTF-8"

Hello,

I'm trying to setup a failover mode ethernet/wireless as shown in
https://docs.freebsd.org/en/books/handbook/book/#networking-lagg-wired-and-wireless
and I got a panic.

/etc/rc.conf:
---
ifconfig_re0="ether "
wlans_iwlwifi0="wlan0"
ifconfig_wlan0="WPA"
create_args_wlan0="country PT"
cloned_interfaces="lagg0"
ifconfig_lagg0="up laggproto failover laggport re0 laggport wlan0 DHCP"
---

Any ideas of what's wrong?
BTW, no kernel dump and I have dumpdev="AUTO" in /etc/rc.conf...

Thanks in advance,
Nuno Teixeira

--00000000000057d5ed05e522c101
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

I'm trying to set=
up a failover mode ethernet/wireless as shown in https://docs.freebsd.org/en/books/handbook/book/#networking-la=
gg-wired-and-wireless and I got a panic.

/=
etc/rc.conf:
---
ifconfig_re0=3D"ether <wlan0 m=
ac address>"
wlans_iwlwifi0=3D"wlan0"
ifconfig_wlan=
0=3D"WPA"
create_args_wlan0=3D"country PT"
cloned=
_interfaces=3D"lagg0"
ifconfig_lagg0=3D"up laggproto fail=
over laggport re0 laggport wlan0 DHCP"
---

Any ideas of what's wrong?
BTW, no kernel dump and I =
have dumpdev=3D"AUTO" in /etc/rc.conf...

Thanks=
 in advance,
Nuno Teixeira


--00000000000057d5ed05e522c101--

From nobody Mon Aug  1 05:42:23 2022
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 4Lx6TG46Dkz4XTlk
	for ; Mon,  1 Aug 2022 05:42:26 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lx6TF4Trqz3Bw5;
	Mon,  1 Aug 2022 05:42:25 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227])
	by cmsmtp with ESMTP
	id IBoeo2K2mS8WrIOC9o4h6v; Mon, 01 Aug 2022 05:42:25 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id IOC8oOuxbGRNlIOC8onvLd; Mon, 01 Aug 2022 05:42:25 +0000
X-Authority-Analysis: v=2.4 cv=Sfrky9du c=1 sm=1 tr=0 ts=62e767c1
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=RgO8CyIxsXoA:10 a=VxmjJ2MpAAAA:8 a=YxBL1-UpAAAA:8
 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=qJ9zPOUSs3Md8CwgmmYA:9 a=CjuIK1q_8ugA:10
 a=tuWILHVPEjkA:10 a=7gXAzLPJhVmCkEl4_tsf:22 a=Ia-lj3WSrqcvXOmTRaiG:22
 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id C304810D;
	Sun, 31 Jul 2022 22:42:23 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id 9624010C; Sun, 31 Jul 2022 22:42:23 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Mark Johnston , freebsd-current@freebsd.org,
    chuck@freebsd.org, mhorne@FreeBSD.org, allanjude@FreeBSD.org
Subject: Re: DTrace Error
In-reply-to: <20220725153706.A2BB3A6@slippy.cwsent.com>
References: <20220723035223.57CDBD7@slippy.cwsent.com> 
 <20220723141444.85620189@slippy.cwsent.com>  
 <20220723185533.9EA7D11E@slippy.cwsent.com> <20220724030857.B57FAFC@slippy.cwsent.com> <20220724170719.139BB40F@slippy.cwsent.com>  <20220725153706.A2BB3A6@slippy.cwsent.com>
Comments: In-reply-to Cy Schubert 
   message dated "Mon, 25 Jul 2022 08:37:06 -0700."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 31 Jul 2022 22:42:23 -0700
Message-Id: <20220801054223.9624010C@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfA9NRc5I+4uErD+95H8QGX9PvAOvBSUYKo1lUUT2aaUsc6KFhCittO228i++3krLrzZQG4/EWWuipnYxeeNzFVy5ETF/2fdfAZdPzHpqNaeHOhG5Kljn
 iaUssq1BUCCUgBqUM3r1OBg/vhjWOtq1dPdB8TL7fhhA9XJsq51OfEf0W7wR4tj0VsPe8SSOLQ36VpMxwo5lw8SH+MaKw55FWlPTEFrqoiXyR4QliyeV7WJ0
 7zsGxW5AcVvLMwnkGgav8VsMQX1UZW7YWgDIkxG7B0sAfWS69FO5HRkwvW25G9hHCE4XYMGQ9deHQG6ahkTqO66a6iSW9II9pxD1ciRp+Wg=
X-Rspamd-Queue-Id: 4Lx6TF4Trqz3Bw5
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	ARC_NA(0.00)[];
	REPLYTO_EQ_FROM(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message <20220725153706.A2BB3A6@slippy.cwsent.com>, Cy Schubert writes:
> In message , Mark Johnston writes:
> > On Sun, Jul 24, 2022 at 10:07:19AM -0700, Cy Schubert wrote:
> > > In message <20220724030857.B57FAFC@slippy.cwsent.com>, Cy Schubert writes
> :
> > > > In message <20220723185533.9EA7D11E@slippy.cwsent.com>, Cy Schubert wri
> te
> > s:
> > > > > In message , Mark Johnston writes:
> > > > > > On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote:
> > > > > > > In message <20220723035223.57CDBD7@slippy.cwsent.com>, Cy Schuber
> t 
> > writ
> > > > es
> > > > > :
> > > > > > > > I'm not sure if this is because my obj tree needs a fresh rebui
> ld
> >  and
> > > >  
> > > > > > > > reinstall or if this is a legitimate problem. Regardless of the
>  d
> > trac
> > > > e 
> > > > > > > > command entered, whether it be a fbt or sdt, the following erro
> r 
> > occu
> > > > rs
> > > > > :
> > > > > > > >
> > > > > > > > slippy# dtrace -n 'fbt::ieee80211_vap_setup:entry { printf("ent
> er
> > ing 
> > > > > > > > ieee80211_vap_setup\n"); }'
> > > > > > > > dtrace: invalid probe specifier fbt::ieee80211_vap_setup:entry 
> { 
> > > > > > > > printf("entering ieee80211_vap_setup\n"); }: "/usr/lib/dtrace/p
> si
> > nfo.
> > > > d"
> > > > > , 
> > > > > > > > line 1: failed to copy type of 'pr_gid': Conflicting type is al
> re
> > ady 
> > > > de
> > > > > fi
> > > > > > ned
> > > > > > > > slippy# 
> > > > > > > >
> > > > > > > > Old DTrace scripts I've used months or even years ago also fail
>  w
> > ith 
> > > > th
> > > > > e 
> > > > > > > > same error. It's not this one probe. All probes result in the p
> r_
> > gid 
> > > > er
> > > > > ro
> > > > > > r.
> > > > > > > >
> > > > > > > > I'm currently rebuilding my "prod" tree from scratch with the h
> op
> > e th
> > > > at
> > > > >  
> > > > > > > > it's simply something out of sync. But, should it not be, has a
> ny
> > one 
> > > > el
> > > > > se
> > > > > >  
> > > > > > > > encountered this lately?
> > > > > > > 
> > > > > > > A full clean rebuild and installworld/kernel did not change the r
> es
> > ult.
> > > >  
> > > > > > > This is a new problem.
> > > > > >
> > > > > > I don't see any such problem on a system built from commit 151abc80
> cd
> > e,
> > > > > > using GENERIC.  Are you using a custom kernel config?  Which kernel
> > > > > > modules do you have loaded?
> > > > >
> > > > > [...]
> > > >
> > > > chuck@ emailed me privately suggesting a roll back to cb2ae6163174. The
>  
> > > > problem is fixed. I'm creating a special branch that reverts only the l
> lv
> > m 
> > > > commits since then.
> > > 
> > > llvm 14 is not the problem. There must be something else after cb2ae61631
> 74
> >  
> > > that is causing the regression.
> >
> > Are you able to bisect?  I spent a bit of time trying to replicate the
> > problem based on your kernel config, without any luck yet.
>
> How fortuitous is this email. I just rebooted my sandbox again and 
> discovered this is related to non-INVARIANT kernels. Enabling INVARIANTS 
> "fixes" dtrace. There must be some commit since cb2ae6163174 that affected 
> non-INVARIANT kernels. As to which one, I'm not sure yet.

The commit that introduced the regression to non-INVARIANT kernels is 
2449b9e5fe565be757a4b29093fd1c9c6ffcf3c9. Looking at the diff I don't
see how it caused the problem but reverting it locally addresses the
regression. (Of course one needs to disable building the mac_ddb module
in order to have the build succeed.)

Without looking at it closer, I suspect that dtrace could be sensitive to 
one of the struct changes.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e**(i*pi)+1=0



From nobody Mon Aug  1 12:16:13 2022
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 4LxHBY3M1gz4XYfH
	for ; Mon,  1 Aug 2022 12:15:17 +0000 (UTC)
	(envelope-from lobo@bsd.com.br)
Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LxHBW6qkjz3r0g
	for ; Mon,  1 Aug 2022 12:15:15 +0000 (UTC)
	(envelope-from lobo@bsd.com.br)
Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-10e6bdbe218so13393660fac.10
        for ; Mon, 01 Aug 2022 05:15:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsd.com.br; s=capeta;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=SBbU+YCjJI6OpCzeOEC+XurSHHX+1HZPMkwT0cbYbsQ=;
        b=QaR+wNW/7tleIjot6QqE4SFquhjmHafx3Wi+Q+LMNRDpRNdU22ukLGQk/pTtoQoTKr
         lpQ57uyTceryQ74QmmLotPKAp3sfan3TjCNpHYS74/4qJc1cjiHK6FBsV4luykr3LtDU
         u0CZCPeiDPwrlVfbSdd3qeBy7y8+ACy8eXS2c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=SBbU+YCjJI6OpCzeOEC+XurSHHX+1HZPMkwT0cbYbsQ=;
        b=Q9UEsYPfC2877us8fcZBjOiTh0NbuIRnVfbvRJBArUDiC1T9xK6DqCKqQohCIC3QWC
         ATtZSr76sQkWw5BnovLcgSwxudMaERMpRRZiyFfOFppIbGlYUMJimmhojebHvf4pmfPg
         +GAE2OLwzjkRlqyQls10v0ILvdMAo0wDhpRvBfD2T8YvH8tz4E3gQFMCxLRDF+xvzIBF
         2dq7LotjMrxX3r/6PEivL99lL7M+Lh++jKI8tb7PjnFybmB1NtHnS7ydN1JU09PQCwrd
         ePOiVaxpl6nsOgSm1wwYCPMPa4J5UR0wTx8lNaCjROY7K9ktIEQUAM9feyAe40F8N46N
         pYpA==
X-Gm-Message-State: AJIora8rh8LJKGx9lKS0q3OIZdurBrh+ZnH5AC3svG7XnssrywoC/JJ7
	kmrle5NgR+2p5bbkmNfDvXFrzfnbYeEeKmKx+ZlQew==
X-Google-Smtp-Source: AGRyM1vgYg76dU9IdYzQBM2+iwH8ezOQrul3+yFFwxLC5kMdF0XCNviUXAuJ17tZ4drOW9BuqwRxUa5wV8X/9ZsvKs8=
X-Received: by 2002:a05:6870:e390:b0:10e:893b:f1d9 with SMTP id
 x16-20020a056870e39000b0010e893bf1d9mr6778074oad.88.1659356112398; Mon, 01
 Aug 2022 05:15: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: Mario Lobo 
Date: Mon, 1 Aug 2022 09:16:13 -0300
Message-ID: 
Subject: Re: Failover Mode between ether/wlan panics
To: Nuno Teixeira 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000a2bf5905e52cf359"
X-Rspamd-Queue-Id: 4LxHBW6qkjz3r0g
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsd.com.br header.s=capeta header.b="QaR+wNW/";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of lobo@bsd.com.br designates 2001:4860:4864:20::33 as permitted sender) smtp.mailfrom=lobo@bsd.com.br
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta];
	R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::33:from];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[bsd.com.br:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsd.com.br];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000a2bf5905e52cf359
Content-Type: text/plain; charset="UTF-8"

On Sun, Jul 31, 2022, 21:05 Nuno Teixeira  wrote:

> Hello,
>
> I'm trying to setup a failover mode ethernet/wireless as shown in
> https://docs.freebsd.org/en/books/handbook/book/#networking-lagg-wired-and-wireless
> and I got a panic.
>
> /etc/rc.conf:
> ---
> ifconfig_re0="ether "
> wlans_iwlwifi0="wlan0"
> ifconfig_wlan0="WPA"
> create_args_wlan0="country PT"
> cloned_interfaces="lagg0"
> ifconfig_lagg0="up laggproto failover laggport re0 laggport wlan0 DHCP"
> ---
>
> Any ideas of what's wrong?
> BTW, no kernel dump and I have dumpdev="AUTO" in /etc/rc.conf...
>
> Thanks in advance,
> Nuno Teixeira
>

Hi.

For this to work, you'll have to clone your wifi MAC to your eth MAC.

>

--000000000000a2bf5905e52cf359
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sun, Jul 31, 2022, 21:05 Nuno Teixeira <eduardo@freebsd.org> wrote:
Hello,

I'm trying to setup a failover mode ethernet/wireless as shown in=
 https://docs.fre=
ebsd.org/en/books/handbook/book/#networking-lagg-wired-and-wireless and=
 I got a panic.

/etc/rc.conf:
---
ifconfig_re0=3D"ether <wlan0 mac address>"
wlans=
_iwlwifi0=3D"wlan0"
ifconfig_wlan0=3D"WPA"
create=
_args_wlan0=3D"country PT"
cloned_interfaces=3D"lagg0&quo=
t;
ifconfig_lagg0=3D"up laggproto failover laggport re0 laggport wl=
an0 DHCP"
---

Any ideas of what'=
;s wrong?
BTW, no kernel dump and I have dumpdev=3D"AUTO&quo=
t; in /etc/rc.conf...

Thanks in advance,
Nuno T=
eixeira

Hi.

F=
or this to work, you'll have to clone your wifi MAC to your eth MAC.




--000000000000a2bf5905e52cf359--

From nobody Mon Aug  1 14:01:10 2022
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 4LxKXy23Wfz4Xr7H
	for ; Mon,  1 Aug 2022 14:01:22 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LxKXy1YTkz46Yj
	for ; Mon,  1 Aug 2022 14:01:22 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659362482;
	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=YTOe/Bb79Q/NQqqoMwXoi5kMmF3r31vsZUvJi34llOQ=;
	b=MYbz4tJeYnDNgSn5VYa86kwXtylt8bP6v5gRjxiWDAbdEuNtYc2ZZfVR6baXZhZFJvYu3+
	+IAzHefoQ2cBctWv3jj1hqI1UMmnCiFBr14yqZZuSF5CsHWe3kM8VWrr/JXe3ExDt6wb0z
	l8kBJUtjGqMLlQE6bxwwF+Ug1QYiW9tSQ9gM0sN59WiHRTZGO9O8zs63iWAMcLR8iO6E1C
	jAerHCn6ON87wtRqZ+lUXUUjflUuBFoceCGbDPb+HWOkcSH9G7xQmGGfnX3JUpMkUcBx6o
	kjbdVZ4xUcP0nChphNgqYHdGxxF+52gsP8BotMy8T9jOKdgaa5HSzvfTut6u1A==
Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LxKXy0f6Vz11Gx
	for ; Mon,  1 Aug 2022 14:01:22 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f42.google.com with SMTP id j2so4828291vsp.1
        for ; Mon, 01 Aug 2022 07:01:22 -0700 (PDT)
X-Gm-Message-State: AJIora9Lh5J7dFluR4MqWJhw/Mww+ZYKbGIZC2FBRd5eUnYdad+H3+vp
	+JtXye4J4Gtjqze69jBfs97o/wFQwPk30+ipBO4=
X-Google-Smtp-Source: AGRyM1sv3zSLlBZmyPMhqsSLipLfwf83CYZ7FarfnoIaUWZhO81U33JbDk2EUNDhku2bcYuEaD7AZZeNME/4qE+4P6Y=
X-Received: by 2002:a67:fe90:0:b0:358:412a:39b1 with SMTP id
 b16-20020a67fe90000000b00358412a39b1mr5588439vsr.11.1659362481392; Mon, 01
 Aug 2022 07:01:21 -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: Nuno Teixeira 
Date: Mon, 1 Aug 2022 15:01:10 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Failover Mode between ether/wlan panics
To: Mario Lobo 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="00000000000041d0b705e52e6f2a"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659362482;
	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=YTOe/Bb79Q/NQqqoMwXoi5kMmF3r31vsZUvJi34llOQ=;
	b=QNyhCpY/IKN/VkREZeIhEb4l1E4EG5pT5Oq/yF8e4oTFQkzLHnU1TGZZK/qS/bBJH3eiGj
	sr9AXZZQqh3Gohe5IcD0lol7eIUSZppw++gZlyUeJ/4NpRNFKsTXDXN7bKpxqazRzvNjXQ
	ymzNmotwoAvBNNIryIJ6CPbJ8UHSV8qulzp7UwToAcGLdKeG4IfAN5UknCZuzpLRhyNpO2
	2G3PmTY/Xo+fKqHUWJJ1+xj4o/WVF6dkPQM4N65InDXvLhfUjjHC2BbGqDy3uU/GMyZpVx
	818c4Lz2ZKrnhz/lQNHi0z1T/2rOVA6Y03Z+N9FtjCGCIrIUD9xlJ+WAoWTRDw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659362482; a=rsa-sha256; cv=none;
	b=LYosKFGuy+kaDmYAz7/S2/VyUvZkZX8mAwSUM+yZvlcuOlbvQJpgKLx9JycFmMln3hzbu9
	M7+SpCyoyXJHgkgeHT86ClQ6nmMYimYUV8YsVG5vgFtJGdV4D8jdiPL2g3TK+kcK/2GZsC
	te7F9lA32fDz3+ffl9JJ92uXj1cvudmNzT5+hghiv+Qa4o7yBk6QGnhfzykrhhDAijuYFF
	i4ZWCXtGnMPz+k3sSuSlghiuSKnlzaqWtISPaKpaH5Cy4htm1OUY3CE1qAv6RIuUTP2hYY
	rzcrueE2FmhcXxJzpjlPvMSfT4k3U5fU/yaFGT0oLA6aSgKE20C0heRBa1aHxA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--00000000000041d0b705e52e6f2a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Something is wrong about getting ether and wlan mac adresses.
dmesg shows the same address:
---
iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x351
iwlwifi0: base HW address: 6c:6a:77:df:09:21
(...)
re0:  port
0x3000-0x30ff mem 0xb4204000-0xb4204fff,0xb4200000-0xb4203fff at device 0.0
on pci3
re0: Ethernet address: 6c:6a:77:df:09:21
---
and ifconfig shows:
---
re0: flags=3D8802 metric 0 mtu 1500

options=3D8209b
        ether 6c:6a:77:df:09:21
        media: Ethernet autoselect (100baseTX )
        status: active
        nd6 options=3D29
lo0: flags=3D8049 metric 0 mtu 16384
        options=3D680003
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=3D21
wlan0: flags=3D8843 metric 0 mtu 15=
00
        ether 6c:6a:77:df:09:21
        inet 192.168.1.74 netmask 0xffffff00 broadcast 192.168.1.255
        groups: wlan
        ssid MEO-3637C0 channel 1 (2412 MHz 11g) bssid 00:06:91:36:37:c0
        regdomain ETSI country PT authmode WPA2/802.11i privacy ON
        deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60
        protmode CTS wme roaming MANUAL
        parent interface: iwlwifi0
        media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11g
        status: associated
        nd6 options=3D29
---

I disabled wireless at bios and same mac address for ethernet.
I don't see a possibility of both cards sharing same mac address...

Cheers

Mario Lobo  escreveu no dia segunda, 1/08/2022 =C3=A0(s) 1=
3:15:

>
> On Sun, Jul 31, 2022, 21:05 Nuno Teixeira  wrote:
>
>> Hello,
>>
>> I'm trying to setup a failover mode ethernet/wireless as shown in
>> https://docs.freebsd.org/en/books/handbook/book/#networking-lagg-wired-a=
nd-wireless
>> and I got a panic.
>>
>> /etc/rc.conf:
>> ---
>> ifconfig_re0=3D"ether "
>> wlans_iwlwifi0=3D"wlan0"
>> ifconfig_wlan0=3D"WPA"
>> create_args_wlan0=3D"country PT"
>> cloned_interfaces=3D"lagg0"
>> ifconfig_lagg0=3D"up laggproto failover laggport re0 laggport wlan0 DHCP=
"
>> ---
>>
>> Any ideas of what's wrong?
>> BTW, no kernel dump and I have dumpdev=3D"AUTO" in /etc/rc.conf...
>>
>> Thanks in advance,
>> Nuno Teixeira
>>
>
> Hi.
>
> For this to work, you'll have to clone your wifi MAC to your eth MAC.
>
>>

--00000000000041d0b705e52e6f2a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

Something is wrong about=
 getting ether and wlan mac adresses.
dmesg shows the same addres=
s:
---
iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz=
, REV=3D0x351
iwlwifi0: base HW address: 6c:6a:77:df:09:21
(..=
.)
re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethe=
rnet> port 0x3000-0x30ff mem 0xb4204000-0xb4204fff,0xb4200000-0xb4203fff=
 at device 0.0 on pci3
re0: Ethernet address: 6c:6a:77:df:09:21
---
and ifconfig shows:
---
re0: flags=3D88=
02<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 options=3D8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN=
_HWCSUM,WOL_MAGIC,LINKSTATE>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 6c:6a:=
77:df:09:21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect (100b=
aseTX <full-duplex>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: active=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO=
_LINKLOCAL>
lo0: flags=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> me=
tric 0 mtu 16384
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D680003<RXCSUM,=
TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 inet6 ::1 prefixlen 128
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 fe80::1%lo0 p=
refixlen 64 scopeid 0x2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet 127.0.0.1 netma=
sk 0xff000000
=C2=A0 =C2=A0 =C2=A0 =C2=A0 groups: lo
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL>
wlan0: f=
lags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 6c:6a:77:df:09:21
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 inet 192.168.1.74 netmask 0xffffff00 broadcast 192.168.1.255<=
br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 groups: wlan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
ssid MEO-3637C0 channel 1 (2412 MHz 11g) bssid 00:06:91:36:37:c0
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 regdomain ETSI country PT authmode WPA2/802.11i privac=
y ON
=C2=A0 =C2=A0 =C2=A0 =C2=A0 deftxkey UNDEF AES-CCM 2:128-bit txpowe=
r 30 bmiss 7 scanvalid 60
=C2=A0 =C2=A0 =C2=A0 =C2=A0 protmode CTS wme r=
oaming MANUAL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 parent interface: iwlwifi0
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: IEEE 802.11 Wireless Ethernet OFDM/24Mbp=
s mode 11g
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: associated
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL&=
gt;
---

I disabled wireless at bios and =
same mac address for ethernet.
I don't see a possibility of b=
oth cards sharing same mac address...

Cheers

Mario Lobo <lobo@bsd.com.br> escreveu no dia segunda, 1/08/2022 =C3=A0(s) 13:15=
:

On Sun, Jul 31, 2022, 21:05 Nuno Teixeira <eduardo@freebsd.org> wrote:
=

Hel=
lo,

I'm trying to setup a failover mode ethern=
et/wireless as shown in https://docs.freebsd.org/en/books/handbook/book/#networking-lagg-wir=
ed-and-wireless and I got a panic.

/etc/rc=
.conf:
---
ifconfig_re0=3D"ether <wlan0 mac add=
ress>"
wlans_iwlwifi0=3D"wlan0"
ifconfig_wlan0=3D&q=
uot;WPA"
create_args_wlan0=3D"country PT"
cloned_inter=
faces=3D"lagg0"
ifconfig_lagg0=3D"up laggproto failover l=
aggport re0 laggport wlan0 DHCP"
---

Any ideas of what's wrong?
BTW, no kernel dump and I have d=
umpdev=3D"AUTO" in /etc/rc.conf...

Thanks in ad=
vance,
Nuno Teixeira

Hi.

For this to work, you'll have to clone your wifi =
MAC to your eth MAC.
<=
/div>





--00000000000041d0b705e52e6f2a--

From nobody Mon Aug  1 14:39:17 2022
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 4LxLNs12CTz4Xwys;
	Mon,  1 Aug 2022 14:39:25 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::222])
	(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 4LxLNq5v1Zz3GBZ;
	Mon,  1 Aug 2022 14:39:23 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Received: (Authenticated sender: andriy.gapon@uabsd.com)
	by mail.gandi.net (Postfix) with ESMTPSA id A7F8740005;
	Mon,  1 Aug 2022 14:39:19 +0000 (UTC)
Message-ID: <70b44a39-1df2-0f4e-42ac-9710ab82d028@FreeBSD.org>
Date: Mon, 1 Aug 2022 17:39:17 +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/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.11.0
Subject: Re: problem with bhyve, ryzen 5800x, freebsd guest
Content-Language: en-US
To: current@freebsd.org, virtualization@freebsd.org
References: 
 
From: Andriy Gapon 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4LxLNq5v1Zz3GBZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 2001:4b98:dc4:8::222 is neither permitted nor denied by domain of avg@FreeBSD.org) smtp.mailfrom=avg@FreeBSD.org
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::222:from];
	MID_RHS_MATCH_FROM(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[current@freebsd.org,virtualization@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[avg];
	TO_DN_NONE(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_TLS_ALL(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-07-10 20:28, Gleb Smirnoff wrote:
> On Thu, Jul 07, 2022 at 03:29:04PM +0300, Andriy Gapon wrote:
> A> I have a strange issue with running an 'appliance' image based on
> A> FreeBSD 12 in bhyve on a machine with Ryzen 5800x processor.
> A>
> A> The problem is that the guest would run for a while and then the host
> A> would suddenly reset itself.  It appears like a triple fault or
> A> something with similar consequences.
> A>
> A> The time may be from a few dozens of minutes to many hours.
> A>
> A> Just to be clear, no such thing occurs if I do not run the guest.
> A> Also, I have an older AMD system (pre-Zen), the problem does not happen
> A> there.
> A> A vanilla FreeBSD 12.3 installation that just sits idle also does not
> A> cause the problem.
> A>
> A> Does anyone have an idea what the problem could be?
> A> What workaround or diagnostics to try?
> A> Anybody else seen something like this?
> A>
> A> Since it's the host that resets it would be hard to capture any traces.
> 
> I also run bhyve on Ryzen since late 2021 and never had such an issue.
> But not FreeBSD 12, I run the head.


Thank you everyone who responded.  It seems that the problem was with 
some BIOS configuration changes, probably related to the power settings.
Once I reset everything to factory defaults (plus some minimum "safe" 
and well-understood changes) the problem went away.
It's really surprising that I saw it only with bhyve and only with the 
particular kind of VMs.  Perhaps there was a workload pattern that 
triggered a hardware bug or overloaded some specific module.

Anyways, sorry for the noise and thank you for the help.

-- 
Andriy Gapon


https://standforukraine.com
https://razomforukraine.org

From nobody Mon Aug  1 16:00:02 2022
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 4LxNB223Gwz4Y7vY
	for ; Mon,  1 Aug 2022 16:00:10 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::224])
	(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 4LxNB12C8dz3RVS;
	Mon,  1 Aug 2022 16:00:09 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Received: (Authenticated sender: andriy.gapon@uabsd.com)
	by mail.gandi.net (Postfix) with ESMTPSA id 95B40E0002;
	Mon,  1 Aug 2022 16:00:03 +0000 (UTC)
Message-ID: <8ccb243e-55e5-e600-fe6a-9f40fc606ec3@FreeBSD.org>
Date: Mon, 1 Aug 2022 19:00:02 +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/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.11.0
Subject: Re: pkg: Newer FreeBSD version for package... but why?
Content-Language: en-US
To: John Baldwin , Michael Gmelin 
Cc: current@freebsd.org
References: <81814ba9-5040-c102-dad4-0a69f3c46121@FreeBSD.org>
 <20220713120900.63cd5639.grembo@freebsd.org>
 
 <402cf119-b07e-76fd-48b6-50eeb9b4508f@FreeBSD.org>
From: Andriy Gapon 
In-Reply-To: <402cf119-b07e-76fd-48b6-50eeb9b4508f@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4LxNB12C8dz3RVS
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 2001:4b98:dc4:8::224 is neither permitted nor denied by domain of avg@FreeBSD.org) smtp.mailfrom=avg@FreeBSD.org
X-Spamd-Result: default: False [-2.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::224:from];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[avg];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-07-13 21:33, John Baldwin wrote:
> On 7/13/22 3:17 AM, Andriy Gapon wrote:
>> On 2022-07-13 13:09, Michael Gmelin wrote:
>>>
>>>
>>> On Wed, 13 Jul 2022 10:29:06 +0300
>>> Andriy Gapon  wrote:
>>>
>>>> # uname -U
>>>> 1400063
>>>>
>>>> # uname -K
>>>> 1400063
>>>>
>>>> # pkg upgrade
>>>> Updating FreeBSD repository catalogue...
>>>> Fetching packagesite.pkg: 100%    5 MiB   4.8MB/s    00:01
>>>> Processing entries:   0%
>>>> Newer FreeBSD version for package zyre:
>>>> To ignore this error set IGNORE_OSVERSION=yes
>>>> - package: 1400063
>>>> - running kernel: 1400051
>>>> Ignore the mismatch and continue? [y/N]:
>>>>
>>>> Does anyone know why this would happen?
>>>> Where does pkg get its notion of the running kernel version?
>>>>
>>>
>>> If I'm reading the sources correctly, it's determining the OS version
>>> by looking at the elf headers of various files in this order:
>>>
>>>       getenv("ABI_FILE")
>>>       /usr/bin/uname
>>>       /bin/sh
>>>
>>> So I would assume that `file /usr/bin/uname` shows 1400051 on your
>>> system.
>>
>> Thank you very much!  That's it:
>> # file /usr/bin/uname
>> /usr/bin/uname: ELF 32-bit LSB executable, ARM, EABI5 version 1
>> (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1,
>> FreeBSD-style, for FreeBSD 14.0 (1400051), stripped
>>
>>> You can point it to checking another file by setting ABI_FILE[0] in the
>>> environment or ignore the check by setting IGNORE_OSVERSION (like
>>> advised). The "running kernel:" label seems a bit misleading.
>>
>> Indeed.
>>
>> Now the next thing (for me) to research is why the binaries were built
>> "for FreeBSD 14.0 (1400051)" when the source tree has 1400063 and uname
>> -U also reports 1400063.
>> FWIW, this was a cross-build, maybe that played a role too.
> 
> If you do a NO_CLEAN=yes build, we don't relink binaries just because
> crt*.o changed (where the note is stored).
> 

I see.  It was a NO_CLEAN build indeed.
Thanks.

-- 
Andriy Gapon


https://standforukraine.com
https://razomforukraine.org

From nobody Mon Aug  1 16:30:51 2022
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 4LxNrK098vz4Wych
	for ; Mon,  1 Aug 2022 16:29:53 +0000 (UTC)
	(envelope-from lobo@bsd.com.br)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LxNrH4kZbz3Vnt
	for ; Mon,  1 Aug 2022 16:29:51 +0000 (UTC)
	(envelope-from lobo@bsd.com.br)
Received: by mail-oi1-x22d.google.com with SMTP id h125so13608702oif.8
        for ; Mon, 01 Aug 2022 09:29:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsd.com.br; s=capeta;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=iEchmNctKDDzeEVFbrq+qTpTX9a2SF9oeoTyPHI7Iec=;
        b=AtxoITL1wgYBwnjUcm7juV7PF7CeLLMrUXGhBZH/6kkCZsDYNxY1o+uYNXOqTXfrXp
         DzvlawrYE6xIfbmDND6Ttpzy2CgsaYwXxHp+wjca/GnnD2ygtKL0LWZPxvT1EpqtlV2h
         rKeYYKf8XpJckxshv/1kEHWeJoRTGsD+RLQLU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=iEchmNctKDDzeEVFbrq+qTpTX9a2SF9oeoTyPHI7Iec=;
        b=WJ8kKHSxjrCEPDZ0B/xFgzGrTEORWB1JK3iP9c2aYqZPSOeJPcQ7Um9iY893HpulsW
         RBFDiI95iKoV8Yh9pGAl75DccFagx19fwigkLH7Py8UrT/gnnKpYCJBwYtoetXwxT0J4
         Ucz9JcV1/HV3zp7Opna6+ede7IOeEe2AgDfbbf3ovk+NCFhyfhljJLyPLfldFkmhItAn
         ixys5payWrRE7vwfykg5ummiH5TRjsF95WZF/0x8jx0VMn6uDlE05XWhUfQlCHKaG6RP
         UkJajgD0yRS49rl9lMoPJp42zfiiLCjdEwYWN5vWchuqj/JA3VUK0qlJi4Jj4EjqHpiM
         mP3Q==
X-Gm-Message-State: AJIora9UYQZkTQ3sTxcDZh0ktatIwpF5ahRjnL+C+BDj+zkTSnFPRfqi
	krEYBRTisNun435PuxRxp8VnwjJHIjXU/D+7gYcxLhGcbqQ=
X-Google-Smtp-Source: AGRyM1vqxx+hzpbsrQ+ub6r0Kpys4yluFpG2ajSxNET7l2veXyPwIay7PP3IFRR2fz6poLYcofukZ5QxNBONeSdF9Qw=
X-Received: by 2002:a05:6808:220c:b0:33a:37f0:602e with SMTP id
 bd12-20020a056808220c00b0033a37f0602emr6296042oib.88.1659371390509; Mon, 01
 Aug 2022 09:29:50 -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: Mario Lobo 
Date: Mon, 1 Aug 2022 13:30:51 -0300
Message-ID: 
Subject: Re: Failover Mode between ether/wlan panics
To: Nuno Teixeira 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000483b1d05e5308285"
X-Rspamd-Queue-Id: 4LxNrH4kZbz3Vnt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsd.com.br header.s=capeta header.b=AtxoITL1;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of lobo@bsd.com.br designates 2607:f8b0:4864:20::22d as permitted sender) smtp.mailfrom=lobo@bsd.com.br
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22d:from];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[bsd.com.br:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsd.com.br];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000483b1d05e5308285
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 1, 2022, 11:01 Nuno Teixeira  wrote:

> Hi,
>
> Something is wrong about getting ether and wlan mac adresses.
> dmesg shows the same address:
> ---
> iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x351
> iwlwifi0: base HW address: 6c:6a:77:df:09:21
> (...)
> re0:  port
> 0x3000-0x30ff mem 0xb4204000-0xb4204fff,0xb4200000-0xb4203fff at device 0=
.0
> on pci3
> re0: Ethernet address: 6c:6a:77:df:09:21
> ---
> and ifconfig shows:
> ---
> re0: flags=3D8802 metric 0 mtu 1500
>
> options=3D8209b
>         ether 6c:6a:77:df:09:21
>         media: Ethernet autoselect (100baseTX )
>         status: active
>         nd6 options=3D29
> lo0: flags=3D8049 metric 0 mtu 16384
>         options=3D680003
>         inet6 ::1 prefixlen 128
>         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
>         inet 127.0.0.1 netmask 0xff000000
>         groups: lo
>         nd6 options=3D21
> wlan0: flags=3D8843 metric 0 mtu =
1500
>         ether 6c:6a:77:df:09:21
>         inet 192.168.1.74 netmask 0xffffff00 broadcast 192.168.1.255
>         groups: wlan
>         ssid MEO-3637C0 channel 1 (2412 MHz 11g) bssid 00:06:91:36:37:c0
>         regdomain ETSI country PT authmode WPA2/802.11i privacy ON
>         deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60
>         protmode CTS wme roaming MANUAL
>         parent interface: iwlwifi0
>         media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11g
>         status: associated
>         nd6 options=3D29
> ---
>
> I disabled wireless at bios and same mac address for ethernet.
> I don't see a possibility of both cards sharing same mac address...
>
> Cheers
>
> Mario Lobo  escreveu no dia segunda, 1/08/2022 =C3=A0(s)
> 13:15:
>
>>
>> On Sun, Jul 31, 2022, 21:05 Nuno Teixeira  wrote:
>>
>>> Hello,
>>>
>>> I'm trying to setup a failover mode ethernet/wireless as shown in
>>> https://docs.freebsd.org/en/books/handbook/book/#networking-lagg-wired-=
and-wireless
>>> and I got a panic.
>>>
>>> /etc/rc.conf:
>>> ---
>>> ifconfig_re0=3D"ether "
>>> wlans_iwlwifi0=3D"wlan0"
>>> ifconfig_wlan0=3D"WPA"
>>> create_args_wlan0=3D"country PT"
>>> cloned_interfaces=3D"lagg0"
>>> ifconfig_lagg0=3D"up laggproto failover laggport re0 laggport wlan0 DHC=
P"
>>> ---
>>>
>>> Any ideas of what's wrong?
>>> BTW, no kernel dump and I have dumpdev=3D"AUTO" in /etc/rc.conf...
>>>
>>> Thanks in advance,
>>> Nuno Teixeira
>>>
>>
>> Hi.
>>
>> For this to work, you'll have to clone your wifi MAC to your eth MAC.
>>
>
Your lagg0 interface is missing.

>

--000000000000483b1d05e5308285
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Aug 1, 2022, 11:01 Nuno Teixeira <eduardo@freebsd.org> wrote:
Hi,

Something is wrong about getting ether and wlan mac adresses.
=

dmesg shows the same address:
---
iwlwifi0: Detect=
ed Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x351
iwlwifi0: base HW address:=
 6c:6a:77:df:09:21
(...)
re0: <RealTek 8168/8111 B/C=
/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0x3000-0x30ff mem 0xb4204000-=
0xb4204fff,0xb4200000-0xb4203fff at device 0.0 on pci3
re0: Ethernet add=
ress: 6c:6a:77:df:09:21
---
and ifconfig shows:
---
re0: flags=3D8802<BROADCAST,SIMPLEX,MULTICAST> metri=
c 0 mtu 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D8209b<RXCSUM,TXCSU=
M,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ether 6c:6a:77:df:09:21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 me=
dia: Ethernet autoselect (100baseTX <full-duplex>)
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 status: active
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D2=
9<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=3D8049<UP,LO=
OPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 options=3D680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 ::1 prefixlen 128
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 inet 127.0.0.1 netmask 0xff000000
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 groups: lo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D21<PERFORMNU=
D,AUTO_LINKLOCAL>
wlan0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX=
,MULTICAST> metric 0 mtu 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 6c:6a=
:77:df:09:21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet 192.168.1.74 netmask 0xfff=
fff00 broadcast 192.168.1.255
=C2=A0 =C2=A0 =C2=A0 =C2=A0 groups: wlan=C2=A0 =C2=A0 =C2=A0 =C2=A0 ssid MEO-3637C0 channel 1 (2412 MHz 11g) bssi=
d 00:06:91:36:37:c0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 regdomain ETSI country P=
T authmode WPA2/802.11i privacy ON
=C2=A0 =C2=A0 =C2=A0 =C2=A0 deftxkey =
UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 protmode CTS wme roaming MANUAL
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 parent interface: iwlwifi0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: IEEE 8=
02.11 Wireless Ethernet OFDM/24Mbps mode 11g
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 status: associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D29<PERF=
ORMNUD,IFDISABLED,AUTO_LINKLOCAL>
---

I disabled wireless at bios and same mac address for ethernet.
I=
 don't see a possibility of both cards sharing same mac address...
<=
/div>

Cheers

Mario Lobo <lobo@bsd.com.br>=
; escreveu no dia segunda, 1/08/2022 =C3=A0(s) 13:15:

On Sun, Jul 31, 2022=
, 21:05 Nuno Teixeira <eduardo@freebsd.org> wrote:
Hello,<=
/div>

I'm trying to setup a failover mode ethernet/w=
ireless as shown in https://docs.freebsd.org/en/books/handbook/book/#networking-l=
agg-wired-and-wireless and I got a panic.

=
/etc/rc.conf:
---
ifconfig_re0=3D"ether <wlan0 =
mac address>"
wlans_iwlwifi0=3D"wlan0"
ifconfig_wla=
n0=3D"WPA"
create_args_wlan0=3D"country PT"
clone=
d_interfaces=3D"lagg0"
ifconfig_lagg0=3D"up laggproto fai=
lover laggport re0 laggport wlan0 DHCP"
---

Any ideas of what's wrong?
BTW, no kernel dump and I=
 have dumpdev=3D"AUTO" in /etc/rc.conf...

Thank=
s in advance,
Nuno Teixeira

Hi.

For this to work, you'll have to clone you=
r wifi MAC to your eth MAC.

Your lagg0 interface =
is missing.
=









--000000000000483b1d05e5308285--

From nobody Mon Aug  1 16:55:49 2022
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 4LxPQW53kqz4X39Z
	for ; Mon,  1 Aug 2022 16:56:03 +0000 (UTC)
	(envelope-from lobo@bsd.com.br)
Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LxPQV4nyDz3YMj
	for ; Mon,  1 Aug 2022 16:56:02 +0000 (UTC)
	(envelope-from lobo@bsd.com.br)
Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-10ea30a098bso9482678fac.8
        for ; Mon, 01 Aug 2022 09:56:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsd.com.br; s=capeta;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=JwtuIoTySEuhnjk2rcmBJZBMIAZevuLTp+ZEW/kZ/Oc=;
        b=fc6Vv0IgFYGytTEb4/JPiNpTYG0VmZcGqIHxiOs0aYn+eB57+q9Z5DWzCktWWE9hBY
         uWIA8T4vSh/HFhLn1WYtQUYi7TFsI82gh9kWOD40WRVvhLTI7gWiu4/jDU0zuANQ7qj0
         RmevUAbnS0QGHcpNYuQkisD/o8qUJmBTE3EoI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=JwtuIoTySEuhnjk2rcmBJZBMIAZevuLTp+ZEW/kZ/Oc=;
        b=Atu9OWibs71x6t4T94LLoATrmw8RrBQ6ppuvix7juuuf9dt2Dp7NEJ7/Gm2qAk2c6Y
         mvCCi7XpXlai2R2MILkl2tjYEGiqKXzzCaAR4E0b2/K3W7UVJKbLiriC8PGcuDGHuGiW
         juJMpE2dgwlWFxQNMoWiYTxd9gMe/hNrdDUwQG+sqAjjPWyn7YRCgUi3xx5HBdDm+5Vz
         9YR3Lg3YmKJGmT7C5ymKHMyN0hhevL0NFf6LQlAqpjo2ycEvxklPhC2peaHy07gB52Sp
         gDpPqs6hBCcVmDWChmzcGc/hCt3wZ6y4F2Q6Q19l7MJfa4FqAEhnuGDP9O2fHMLEoBGX
         S8Yw==
X-Gm-Message-State: AJIora+NatYKnP8VEpNC7Erm0X0B4nUJditblzs4v/LjR50hhqJp8YwX
	jZpoIMoAe96nm+N0B08irHB+nOE5OG87tqZUu8gkZlBcJLz/zg==
X-Google-Smtp-Source: AGRyM1tAngfGaIsYy1s9yBZar7SsIoTvhFQfpsGJxoDMfleyhkHg1Be4E+JlcsK2n2eVFykqaV6B2ddhjHON3oflaOM=
X-Received: by 2002:a05:6870:e390:b0:10e:893b:f1d9 with SMTP id
 x16-20020a056870e39000b0010e893bf1d9mr7350068oad.88.1659372961493; Mon, 01
 Aug 2022 09:56: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: 
 
  
In-Reply-To: 
From: Mario Lobo 
Date: Mon, 1 Aug 2022 13:55:49 -0300
Message-ID: 
Subject: Re: Failover Mode between ether/wlan panics
To: Nuno Teixeira 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000eb89ef05e530dfe3"
X-Rspamd-Queue-Id: 4LxPQV4nyDz3YMj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsd.com.br header.s=capeta header.b=fc6Vv0Ig;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of lobo@bsd.com.br designates 2001:4860:4864:20::34 as permitted sender) smtp.mailfrom=lobo@bsd.com.br
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta];
	R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::34:from];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[bsd.com.br:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsd.com.br];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000eb89ef05e530dfe3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 1, 2022 at 1:30 PM Mario Lobo  wrote:

>
>
> On Mon, Aug 1, 2022, 11:01 Nuno Teixeira  wrote:
>
>> Hi,
>>
>> Something is wrong about getting ether and wlan mac adresses.
>> dmesg shows the same address:
>> ---
>> iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x351
>> iwlwifi0: base HW address: 6c:6a:77:df:09:21
>> (...)
>> re0:  port
>> 0x3000-0x30ff mem 0xb4204000-0xb4204fff,0xb4200000-0xb4203fff at device =
0.0
>> on pci3
>> re0: Ethernet address: 6c:6a:77:df:09:21
>> ---
>> and ifconfig shows:
>> ---
>> re0: flags=3D8802 metric 0 mtu 1500
>>
>> options=3D8209b
>>         ether 6c:6a:77:df:09:21
>>         media: Ethernet autoselect (100baseTX )
>>         status: active
>>         nd6 options=3D29
>> lo0: flags=3D8049 metric 0 mtu 16384
>>         options=3D680003
>>         inet6 ::1 prefixlen 128
>>         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
>>         inet 127.0.0.1 netmask 0xff000000
>>         groups: lo
>>         nd6 options=3D21
>> wlan0: flags=3D8843 metric 0 mtu
>> 1500
>>         ether 6c:6a:77:df:09:21
>>         inet 192.168.1.74 netmask 0xffffff00 broadcast 192.168.1.255
>>         groups: wlan
>>         ssid MEO-3637C0 channel 1 (2412 MHz 11g) bssid 00:06:91:36:37:c0
>>         regdomain ETSI country PT authmode WPA2/802.11i privacy ON
>>         deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60
>>         protmode CTS wme roaming MANUAL
>>         parent interface: iwlwifi0
>>         media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11g
>>         status: associated
>>         nd6 options=3D29
>> ---
>>
>> I disabled wireless at bios and same mac address for ethernet.
>> I don't see a possibility of both cards sharing same mac address...
>>
>> Cheers
>>
>> Mario Lobo  escreveu no dia segunda, 1/08/2022 =C3=A0(s=
)
>> 13:15:
>>
>>>
>>> On Sun, Jul 31, 2022, 21:05 Nuno Teixeira  wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm trying to setup a failover mode ethernet/wireless as shown in
>>>> https://docs.freebsd.org/en/books/handbook/book/#networking-lagg-wired=
-and-wireless
>>>> and I got a panic.
>>>>
>>>> /etc/rc.conf:
>>>> ---
>>>> ifconfig_re0=3D"ether "
>>>> wlans_iwlwifi0=3D"wlan0"
>>>> ifconfig_wlan0=3D"WPA"
>>>> create_args_wlan0=3D"country PT"
>>>> cloned_interfaces=3D"lagg0"
>>>> ifconfig_lagg0=3D"up laggproto failover laggport re0 laggport wlan0 DH=
CP"
>>>> ---
>>>>
>>>> Any ideas of what's wrong?
>>>> BTW, no kernel dump and I have dumpdev=3D"AUTO" in /etc/rc.conf...
>>>>
>>>> Thanks in advance,
>>>> Nuno Teixeira
>>>>
>>>
>>> Hi.
>>>
>>> For this to work, you'll have to clone your wifi MAC to your eth MAC.
>>>
>>
> Your lagg0 interface is missing.
>
>>
Here is my ifconfig:

[~]>ifconfig
re0: flags=3D8843 metric 0 mtu 1500
        options=3D80088
        ether f8:94:c2:26:f3:54
        hwaddr fc:45:96:fb:3d:82
        media: Ethernet autoselect (1000baseT )
        status: active
        nd6 options=3D21
lo0: flags=3D8049 metric 0 mtu 16384
        options=3D680003
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=3D21
vboxnet0: flags=3D8802 metric 0 mtu 1500
        ether 0a:00:27:00:00:00
        media: Ethernet autoselect
        status: active
        nd6 options=3D21
wlan0: flags=3D8c43 metric =
0
mtu 1500
        ether f8:94:c2:26:f3:54
        groups: wlan
        ssid "" channel 1 (2412 MHz 11g)
        regdomain FCC country US authmode WPA1+WPA2/802.11i privacy MIXED
        deftxkey UNDEF powersavemode CAM powersavesleep 100 txpower 30
        bmiss 10 scanvalid 60 protmode CTS wme roaming MANUAL
        parent interface: iwm0
        media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
        status: no carrier
        nd6 options=3D21
lagg0: flags=3D8843 metric 0 mtu 15=
00
        ether f8:94:c2:26:f3:54
        inet6 fe80::fa94:c2ff:fe26:f354%lagg0 prefixlen 64 scopeid 0x5
        inet 10.17.12.215 netmask 0xffffff00 broadcast 10.17.12.255
        laggproto failover lagghash l2,l3,l4
        laggport: re0 flags=3D5
        laggport: wlan0 flags=3D0<>
        groups: lagg
        media: Ethernet autoselect
        status: active
        nd6 options=3D21

And here is my rc.conf:

ifconfig_wlan0=3D"mode autoselect WPA powersave up"
wlans_iwm0=3D"wlan0"
wpa_supplicant_enable=3D"YES"
wpa_supplicant_program=3D"/usr/local/sbin/wpa_supplicant"
wpa_supplicant_flags=3D"-dd"
ifconfig_re0=3D"media 1000baseTX mediaopt full-duplex up"
ifconfig_re0=3D"ether f8:94:c2:26:f3:54"
ifconfig_lagg0=3D"up laggproto failover laggport re0 laggport wlan0 DHCP"
cloned_interfaces=3D"lagg0"
--=20
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!]

--000000000000eb89ef05e530dfe3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Mon, Aug 1, 2022 at 1:30 PM Mario Lobo <lobo@bsd.com.br> wrote:


On Mon, Aug 1, 20=
22, 11:01 Nuno Teixeira <eduardo@freebsd.org> wrote:
Hi,

Something is wrong about getting ether and wlan mac adresses.
dmesg shows the same address:
---
iwlwifi0: Detec=
ted Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x351
iwlwifi0: base HW address=
: 6c:6a:77:df:09:21
(...)
re0: <RealTek 8168/8111 B/=
C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0x3000-0x30ff mem 0xb4204000=
-0xb4204fff,0xb4200000-0xb4203fff at device 0.0 on pci3
re0: Ethernet ad=
dress: 6c:6a:77:df:09:21
---
and ifconfig shows:
<=
div>---
re0: flags=3D8802<BROADCAST,SIMPLEX,MULTICAST> metr=
ic 0 mtu 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D8209b<RXCSUM,TXCS=
UM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 ether 6c:6a:77:df:09:21
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 media: Ethernet autoselect (100baseTX <full-duplex>)
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 status: active
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=
=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=3D8049<U=
P,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 options=3D680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6=
>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 ::1 prefixlen 128
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 inet 127.0.0.1 netmask 0xff000000
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 groups: lo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D21<PERFO=
RMNUD,AUTO_LINKLOCAL>
wlan0: flags=3D8843<UP,BROADCAST,RUNNING,SIM=
PLEX,MULTICAST> metric 0 mtu 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 6=
c:6a:77:df:09:21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet 192.168.1.74 netmask 0=
xffffff00 broadcast 192.168.1.255
=C2=A0 =C2=A0 =C2=A0 =C2=A0 groups: wl=
an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ssid MEO-3637C0 channel 1 (2412 MHz 11g) =
bssid 00:06:91:36:37:c0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 regdomain ETSI count=
ry PT authmode WPA2/802.11i privacy ON
=C2=A0 =C2=A0 =C2=A0 =C2=A0 deftx=
key UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 protmode CTS wme roaming MANUAL
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 parent interface: iwlwifi0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: IEE=
E 802.11 Wireless Ethernet OFDM/24Mbps mode 11g
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 status: associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D29<P=
ERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
---

<=
div>I disabled wireless at bios and same mac address for ethernet.
I don't see a possibility of both cards sharing same mac address...

Cheers

Mario Lobo <lobo@bsd.com.br=
> escreveu no dia segunda, 1/08/2022 =C3=A0(s) 13:15:

On Sun, Jul 31, 2=
022, 21:05 Nuno Teixeira <eduardo@freebsd.org> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
Hell=
o,

I'm trying to setup a failover mode etherne=
t/wireless as shown in https://docs.freebsd.org/en/books/handbook/book/#networkin=
g-lagg-wired-and-wireless and I got a panic.

/etc/rc.conf:
---
ifconfig_re0=3D"ether <wla=
n0 mac address>"
wlans_iwlwifi0=3D"wlan0"
ifconfig_=
wlan0=3D"WPA"
create_args_wlan0=3D"country PT"
cl=
oned_interfaces=3D"lagg0"
ifconfig_lagg0=3D"up laggproto =
failover laggport re0 laggport wlan0 DHCP"
---
Any ideas of what's wrong?
BTW, no kernel dump an=
d I have dumpdev=3D"AUTO" in /etc/rc.conf...

Th=
anks in advance,
Nuno Teixeira
=


Hi.

For this to work, you'll have to clone =
your wifi MAC to your eth MAC.
<=
/div>

Your lagg0 interfa=
ce is missing.









Here is my ifconfig:
<=
div>
[~]>ifconfig 
re0: flags=3D8843<UP,BROADCAST,RU=
NNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 options=3D80088<VLAN_MTU,VLAN_HWCSUM,LINKSTATE>
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 ether f8:94:c2:26:f3:54
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hwaddr=
 fc:45:96:fb:3d:82
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselec=
t (1000baseT <full-duplex>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: ac=
tive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D21<PERFORMNUD,AUTO_LIN=
KLOCAL>
lo0: flags=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> metric=
 0 mtu 16384
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D680003<RXCSUM,TXCS=
UM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ine=
t6 ::1 prefixlen 128
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 fe80::1%lo0 prefi=
xlen 64 scopeid 0x2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet 127.0.0.1 netmask 0=
xff000000
=C2=A0 =C2=A0 =C2=A0 =C2=A0 groups: lo
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL>
vboxnet0: flag=
s=3D8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ether 0a:00:27:00:00:00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 me=
dia: Ethernet autoselect
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: active
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL&g=
t;
wlan0: flags=3D8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST=
> metric 0 mtu 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether f8:94:c2:26:f3:=
54
=C2=A0 =C2=A0 =C2=A0 =C2=A0 groups: wlan
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 ssid "" channel 1 (2412 MHz 11g)
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 regdomain FCC country US authmode WPA1+WPA2/802.11i privacy MIXED
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 deftxkey UNDEF powersavemode CAM powersavesleep=
 100 txpower 30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bmiss 10 scanvalid 60 protmo=
de CTS wme roaming MANUAL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 parent interface: =
iwm0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 media: IEEE 802.11 Wireless Ethernet au=
toselect (autoselect)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: no carrier
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL&g=
t;
lagg0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> met=
ric 0 mtu 1500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether f8:94:c2:26:f3:54
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 fe80::fa94:c2ff:fe26:f354%lagg0 prefixlen=
 64 scopeid 0x5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inet 10.17.12.215 netmask 0x=
ffffff00 broadcast 10.17.12.255
=C2=A0 =C2=A0 =C2=A0 =C2=A0 laggproto fa=
ilover lagghash l2,l3,l4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 laggport: re0 flags=
=3D5<MASTER,ACTIVE>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 laggport: wlan0 fl=
ags=3D0<>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 groups: lagg
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 media: Ethernet autoselect
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 status: active
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D21<PERFORMN=
UD,AUTO_LINKLOCAL>

And here is my rc.conf:
<=
/div>

ifconfig_wlan0=3D"mode autoselect WPA powersa=
ve up"
wlans_iwm0=3D"wlan0"
wpa_supplicant_enable=3D&q=
uot;YES"
wpa_supplicant_program=3D"/usr/local/sbin/wpa_supplic=
ant"
wpa_supplicant_flags=3D"-dd"
ifconfig_re0=3D"=
;media 1000baseTX mediaopt full-duplex up"
ifconfig_re0=3D"eth=
er f8:94:c2:26:f3:54"
ifconfig_lagg0=3D"up laggproto failover =
laggport re0 laggport wlan0 DHCP"
cloned_interfaces=3D"lagg0&q=
uot;
-- 
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2=
.2.8 [not Pro-Audio.... YET!!]


--000000000000eb89ef05e530dfe3--

From nobody Mon Aug  1 17:08:51 2022
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 4LxPkg1bp9z4X5bK
	for ; Mon,  1 Aug 2022 17:10:03 +0000 (UTC)
	(envelope-from shawn.webb@hardenedbsd.org)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LxPkf3ZYMz3b0w
	for ; Mon,  1 Aug 2022 17:10:02 +0000 (UTC)
	(envelope-from shawn.webb@hardenedbsd.org)
Received: by mail-qv1-xf35.google.com with SMTP id h8so7860442qvs.6
        for ; Mon, 01 Aug 2022 10:10:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=hardenedbsd.org; s=google;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc;
        bh=W3wVKt0fI6FrUn/4UKdhZz6xgnyRO4Z34HOay8oFy/k=;
        b=MzC/4wdWGrAZ1/ShRd0E6WsS4fGDSZu70hVXSACgj85OZVEKU0SihGk+1lCU6Z2ZO+
         ByPpklVolO4wDZizuwu8DOgkf8GzYFZjh1UgJw8bwJjeLNz0XJSODagRLX0teZ7/rG7b
         y9Ei8rRI8r8zMTqenGWXvRTZqQmefsnSzMGjIZGqMnqGFs99zXQsmCkgW55hhsn/m9On
         08YbGnAjeykZkjRIwumYZTqlXoYk/dz1B9LV347Xo32t0QfBGmzKkpc8w8g2wFLw3rXY
         4g/UMN2dfM9OmGhqKzVuZ9RHL5YzwUEE6xZyD2gRNnAu8qpdDIn3+MZ/O+CJC74EH44v
         +AsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc;
        bh=W3wVKt0fI6FrUn/4UKdhZz6xgnyRO4Z34HOay8oFy/k=;
        b=mqVRH4bnStMOjsYACUo67oJ+TunCrpQ/H0yEynKMne3KiT7Y32cCVdaID2Qryby9ig
         6sb1tiJHjxUeFcWTkb5Su+mJqX3p3jwu2tazOsA0kMfSOA9+LItPUA9bAXSN+4ukUD4R
         eT5ZSmflfM1SYShLtWlkeFjSoNRQxH5hrmDiL97sUs2JCyScgZQS1p4oq1K5EA9OilxC
         oui1yRYG+jdb34sHHW9lvCuV3gkKyJUNPMETuiKDHRaR13vOQOm6KDBDLHOJ7I2gzGAj
         w8WmiljNhlD6u9yUKqoX9ehxAhlyLB33xULXdHWLrI35uDxp7IfP/SVq1KsY0KoCgXe1
         BCDQ==
X-Gm-Message-State: ACgBeo2jm+6aPW2TlquhgT3LzzXIxCt19soHsXyLgB9OUILgA9siSz8U
	DU2UlWLHkBUjVmAAd1Elbeiq8KidH0+kiXZ6
X-Google-Smtp-Source: AA6agR7bvRX5D+WJ7ynCtSNna2fYL2nqYbsL+cU8QoSCMleXw27idjttBJwa2RFYoucyHVCtYzGltg==
X-Received: by 2002:a05:6214:621:b0:432:5e0d:cb64 with SMTP id a1-20020a056214062100b004325e0dcb64mr14886473qvx.65.1659373801643;
        Mon, 01 Aug 2022 10:10:01 -0700 (PDT)
Received: from mutt-hbsd (pool-100-16-219-215.bltmmd.fios.verizon.net. [100.16.219.215])
        by smtp.gmail.com with ESMTPSA id l21-20020ac87255000000b0031ef21aec36sm7309797qtp.32.2022.08.01.10.10.00
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 01 Aug 2022 10:10:00 -0700 (PDT)
Date: Mon, 1 Aug 2022 13:08:51 -0400
From: Shawn Webb 
To: Nuno Teixeira 
Cc: FreeBSD CURRENT 
Subject: Re: Failover Mode between ether/wlan panics
Message-ID: <20220801170851.orw36t2whb7rrqcj@mutt-hbsd>
X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD
 14.0-CURRENT-HBSD 
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="z2kpyo3n2s45wvfa"
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4LxPkf3ZYMz3b0w
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hardenedbsd.org header.s=google header.b="MzC/4wdW";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::f35 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org
X-Spamd-Result: default: False [-5.10 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	MID_RHS_NOT_FQDN(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f35:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[hardenedbsd.org:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[hardenedbsd.org];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--z2kpyo3n2s45wvfa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 01, 2022 at 01:05:07AM +0100, Nuno Teixeira wrote:
> Hello,
>=20
> I'm trying to setup a failover mode ethernet/wireless as shown in
> https://docs.freebsd.org/en/books/handbook/book/#networking-lagg-wired-an=
d-wireless
> and I got a panic.
>=20
> /etc/rc.conf:
> ---
> ifconfig_re0=3D"ether "
> wlans_iwlwifi0=3D"wlan0"
> ifconfig_wlan0=3D"WPA"
> create_args_wlan0=3D"country PT"
> cloned_interfaces=3D"lagg0"
> ifconfig_lagg0=3D"up laggproto failover laggport re0 laggport wlan0 DHCP"
> ---
>=20
> Any ideas of what's wrong?
> BTW, no kernel dump and I have dumpdev=3D"AUTO" in /etc/rc.conf...

When I last talked to bz@, the combination of iwlwifi and lagg was
reported as not supported. bz@ might need/want some help in that area.

Thanks,

--=20
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A=
4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

--z2kpyo3n2s45wvfa
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmLoCKAACgkQ/y5nonf4
4fqgzhAApBXjy+qTAVMJyplSiFGYTp0q0o0FLIC2EBkgEO14RjBnK+DDzqllrBh1
llIcNeMA4FsTyOgDIGdlWhZh74Rnnyr00jj2Z5JADl0N1TP/pp3stt3Ecmxr3I7h
MNOrMR24KFsJRnWLtN8RYrdlAOb2JTWq9TWeHOhpJDEFm4YhFvi2nKQvi1VYz4Cv
x+DeG4twugj2ZHQd0pF1t74aK8LL7NkhBQ1JS2bAFKwkBGcWhFznfz8udPQ3udi4
qGOWU9peHvquEI5+pkzh/YdbOnECkMd+c6wZ0SF/VgG/ktF3X0gG4IzS7un+/LgS
/m2mYuPwDktldAkhMi2vmjaJry5hH3l6prm1+h8GLXSkNxZftY9jb/k44bCUe5kx
ShNBgSN18tMHnt0DoHSqA/EYIiK7OlVXTunDJoM0VuYZ8ySXZJnZygkMsNICPgsO
NkXIMEQEp0CcWWB7icYhsQhrI+80+HkhX4Qmc8c8Rf4xAOVhChcfeZQtBB8uO9oJ
9P4FsNOvscO297mPPpFwe5r5vyyQ1KqDJVMoOEJ7lw6oyYxMVXFMx+ML/zKMqFW3
xpSYo0h1/XugHl5KVAzralsT81UVhcTceWT9KlHi3kZ85PQZtcw728oYuX4fDr6g
uh2O/qRTUDtLUKIYFEglPtUw/5DoyP7ODO5OgGFPUUGZdY40N9A=
=7Q6W
-----END PGP SIGNATURE-----

--z2kpyo3n2s45wvfa--

From nobody Mon Aug  1 17:24:44 2022
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 4LxQ3h4Bztz4X7gK;
	Mon,  1 Aug 2022 17:24:48 +0000 (UTC)
	(envelope-from gusev.vitaliy@gmail.com)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LxQ3g5f6wz3d2P;
	Mon,  1 Aug 2022 17:24:47 +0000 (UTC)
	(envelope-from gusev.vitaliy@gmail.com)
Received: by mail-lf1-x136.google.com with SMTP id w15so18332009lft.11;
        Mon, 01 Aug 2022 10:24:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
         :from:from:to:cc;
        bh=m1c/OzKZuNkJ0EbEGrpQm7MHgNhmFqH8J++vfx/GsPM=;
        b=jgsG+7VohWKsmUtXoHK9hSBIUDooLKdXok2wo6yPgbc8G7+LW0ia6B9adM3OM4+lsZ
         9oxa7tWmqhlV6ywzCsW5wFYBCLDdCOMPs0AKYnLL0BkneudnN4/jySyKuQVlUyuaaiyJ
         vMEixnujK6JDK84BmDgtvaTeg+nzqebs0+1ZPmQQRO/6I2Pul5yIr6Q5sM/Th+EaZCXz
         VMSo1SzvF4uJS1NDsGaRtbZs/IDCn4l98HGCkFXyG/oQAcSeik+uG4ZeUYGZxs0RUl63
         Ox88CSZKHlSF5vi8yUPNwaqGGAYQVa7GwEJEIRbZkE1iuAbGhiVPPSVjRGmVSCdkLZOA
         Bmuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
         :from:x-gm-message-state:from:to:cc;
        bh=m1c/OzKZuNkJ0EbEGrpQm7MHgNhmFqH8J++vfx/GsPM=;
        b=1pX6i9zZhr0T8Ispj5ALpHCP+WD7uCFfdhhdTa4nMsUoqUvn+VPKtWRNcjuizG24kc
         7oQznoOa3QJji3ab9/7T9b6PNxKybCbWUGk07TLvFdbtjuHa12gPPbqBH8kOaZ42J+RI
         UkJ4apU/FARAtKOZima1wG9SaYEPeZNpNhXnfAgG+L7rD7awVMWmk5hw4XEX+lnbwgQ/
         +teRGOsL4f/sNYTt2ordpD2CNMr/w6uPAOjWKWpfuJ2/SU7XXxF6zwMwvp6hxiLhIzlp
         a5GzJdnM+JNr1R1z6r0vQ9l6Qt/xIvKByHwq0JrQRDE/nfs+z0nybJgo9CwyOKCU1HYX
         iPrg==
X-Gm-Message-State: AJIora/qOSFE44KwZqhkSEQbleuXKwHSeJS41L95eRyq4xkfHJ6qFPFb
	Z4WtiQsOdh6QImWiAI1aNH3wIt0rWaaVZg==
X-Google-Smtp-Source: AGRyM1t43HyNsfMGqjZk3Wfgc9ZF3olNw1wHyEdO3cEiG78CjvejKWy/zwp1dYb9d3Yw7ql48u4EJQ==
X-Received: by 2002:a19:8c04:0:b0:47f:65b7:bf11 with SMTP id o4-20020a198c04000000b0047f65b7bf11mr6537348lfd.630.1659374685594;
        Mon, 01 Aug 2022 10:24:45 -0700 (PDT)
Received: from smtpclient.apple ([188.187.60.230])
        by smtp.gmail.com with ESMTPSA id o1-20020a056512052100b0048a98b7bad3sm931852lfc.197.2022.08.01.10.24.44
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 01 Aug 2022 10:24:44 -0700 (PDT)
From: Vitaliy Gusev 
Message-Id: 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FA2EEDB9-6782-4E0D-9AFD-58F553637AE0"
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: problem with bhyve, ryzen 5800x, freebsd guest
Date: Mon, 1 Aug 2022 20:24:44 +0300
In-Reply-To: <70b44a39-1df2-0f4e-42ac-9710ab82d028@FreeBSD.org>
Cc: current@freebsd.org,
 virtualization@freebsd.org
To: Andriy Gapon 
References: 
 
 <70b44a39-1df2-0f4e-42ac-9710ab82d028@FreeBSD.org>
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Queue-Id: 4LxQ3g5f6wz3d2P
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=jgsG+7Vo;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of gusev.vitaliy@gmail.com designates 2a00:1450:4864:20::136 as permitted sender) smtp.mailfrom=gusev.vitaliy@gmail.com
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	NEURAL_HAM_MEDIUM(-0.82)[-0.818];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::136:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	TAGGED_FROM(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[current@freebsd.org,virtualization@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_FA2EEDB9-6782-4E0D-9AFD-58F553637AE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Interesting enough. It would be nice if you find out what exactly =
triggered your VM to reset.

=E2=80=94
Vitaliy

> On 1 Aug 2022, at 17:39, Andriy Gapon  wrote:
>=20
> On 2022-07-10 20:28, Gleb Smirnoff wrote:
>> On Thu, Jul 07, 2022 at 03:29:04PM +0300, Andriy Gapon wrote:
>> A> I have a strange issue with running an 'appliance' image based on
>> A> FreeBSD 12 in bhyve on a machine with Ryzen 5800x processor.
>> A>
>> A> The problem is that the guest would run for a while and then the =
host
>> A> would suddenly reset itself. It appears like a triple fault or
>> A> something with similar consequences.
>> A>
>> A> The time may be from a few dozens of minutes to many hours.
>> A>
>> A> Just to be clear, no such thing occurs if I do not run the guest.
>> A> Also, I have an older AMD system (pre-Zen), the problem does not =
happen
>> A> there.
>> A> A vanilla FreeBSD 12.3 installation that just sits idle also does =
not
>> A> cause the problem.
>> A>
>> A> Does anyone have an idea what the problem could be?
>> A> What workaround or diagnostics to try?
>> A> Anybody else seen something like this?
>> A>
>> A> Since it's the host that resets it would be hard to capture any =
traces.
>> I also run bhyve on Ryzen since late 2021 and never had such an =
issue.
>> But not FreeBSD 12, I run the head.
>=20
>=20
> Thank you everyone who responded. It seems that the problem was with =
some BIOS configuration changes, probably related to the power settings.
> Once I reset everything to factory defaults (plus some minimum "safe" =
and well-understood changes) the problem went away.
> It's really surprising that I saw it only with bhyve and only with the =
particular kind of VMs. Perhaps there was a workload pattern that =
triggered a hardware bug or overloaded some specific module.
>=20
> Anyways, sorry for the noise and thank you for the help.
>=20
> --=20
> Andriy Gapon
>=20
>=20
> https://standforukraine.com 
> https://razomforukraine.org 

--Apple-Mail=_FA2EEDB9-6782-4E0D-9AFD-58F553637AE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Interesting enough. It would be nice if you find out what =
exactly triggered your VM to reset.

=E2=80=94
Vitaliy

On 1 Aug 2022, at 17:39, Andriy Gapon <avg@FreeBSD.org> =
wrote:

On 2022-07-10 20:28, Gleb Smirnoff wrote:
On =
Thu, Jul 07, 2022 at 03:29:04PM +0300, Andriy Gapon wrote:
A> I have a strange issue with running an 'appliance' =
image based on
A> FreeBSD 12 in bhyve on a machine with =
Ryzen 5800x processor.
A>
A> The =
problem is that the guest would run for a while and then the host
A> would suddenly reset itself. It appears like a triple =
fault or
A> something with similar consequences.
A>
A> The time may be from a few dozens =
of minutes to many hours.
A>
A> Just =
to be clear, no such thing occurs if I do not run the guest.
A> Also, I have an older AMD system (pre-Zen), the problem =
does not happen
A> there.
A> A vanilla =
FreeBSD 12.3 installation that just sits idle also does not
A> cause the problem.
A>
A> Does anyone have an idea what the problem could be?
A> What workaround or diagnostics to try?
A> Anybody else seen something like this?
A>
A> Since it's the host that resets it =
would be hard to capture any traces.
I also run bhyve on =
Ryzen since late 2021 and never had such an issue.
But not =
FreeBSD 12, I run the head.


Thank you everyone who =
responded. It seems that the problem was with some BIOS configuration =
changes, probably related to the power settings.
Once I reset everything to =
factory defaults (plus some minimum "safe" and well-understood changes) =
the problem went away.
It's really surprising that I saw it only with bhyve and only =
with the particular kind of VMs. Perhaps there was a workload pattern =
that triggered a hardware bug or overloaded some specific =
module.

Anyways, =
sorry for the noise and thank you for the help.

-- 
Andriy Gapon


https://standforukraine.com
https://razomforukraine.org

=

--Apple-Mail=_FA2EEDB9-6782-4E0D-9AFD-58F553637AE0--

From nobody Mon Aug  1 22:17:34 2022
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 4LxXYk71nJz4Y6bw
	for ; Mon,  1 Aug 2022 22:17:46 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LxXYk6Rfwz48BP
	for ; Mon,  1 Aug 2022 22:17:46 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659392266;
	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=9VuOwnGwldvEOaE00BuIYNjg+VMDZqv6VSjgVzOm12I=;
	b=I0lFbQYoX3lsHkxzsxklGFzKQujGeBYKkSSyLIqHMIBOJTZqkRdehMMBCsSBwYoWUpq4Gu
	/eyxlNQ7QyzWXu9txW+cYcxPrzs0Tm6/MAB9DXsw0nCxKNGjWLcjsqcjxTgdmj7TXaKVQe
	cHuEl5yHht9nLrPxIZDmSs3iBf55+/RZ2GEgBGT6Y9K4zdluP7L/yUrr8YzYPqPkxjcJGL
	1kt5UTBsEhs2/8sHutNif0ahJI6qXR4ed60mLv3SiSFiWzwj9yxLyh9/S7UWBDzTKae2+a
	Q8/bj5Nb2bruOR+4cjG71C7ISpxRGf/U87BM/j0OOYz7SLkusH0SVE4AlUt6dA==
Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4LxXYk5Nxfz187H
	for ; Mon,  1 Aug 2022 22:17:46 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f49.google.com with SMTP id 125so12771059vsx.7
        for ; Mon, 01 Aug 2022 15:17:46 -0700 (PDT)
X-Gm-Message-State: AJIora8sV7H9D8pnWj1Vz9dSu8oC9ClNc2kBGRA8OERAYLD9GI///dz1
	GRVUQRHSvMrvhIdHJaexpJgoVBHcnwgbWJaJHxs=
X-Google-Smtp-Source: AGRyM1uOf4tqogKKMVS+zE7+J9wheOVkMrHP6C+t5TWN/B49znOdJ1g732glK2Rq/V3amrD/9NNXc8W4/Jx82qpau9M=
X-Received: by 2002:a05:6102:3e0d:b0:358:5c4f:5253 with SMTP id
 j13-20020a0561023e0d00b003585c4f5253mr6207952vsv.58.1659392266211; Mon, 01
 Aug 2022 15:17:46 -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: 
 <20220801170851.orw36t2whb7rrqcj@mutt-hbsd>
In-Reply-To: <20220801170851.orw36t2whb7rrqcj@mutt-hbsd>
From: Nuno Teixeira 
Date: Mon, 1 Aug 2022 23:17:34 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Failover Mode between ether/wlan panics
To: Shawn Webb 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="00000000000092176405e5355e0c"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659392266;
	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=9VuOwnGwldvEOaE00BuIYNjg+VMDZqv6VSjgVzOm12I=;
	b=itjHvuU6fQVed+OLVZMlX4xgi8HYM0IxvdB8RS/EASTqBIatnx0OmK2R/THnovS0KunPrm
	NCUiL+C6ZKk340hpQbgvetHrVMgzpDHFeyPDwziUAPWZHzxNk1BnkhEG26PvKrTl7S6a4/
	Vnt/mdnc2gRc3UqRUCDK6oDwQQOnlaen9x3XwuT5YYQw2Vq5hW9V6uUzIM3GwKtYNmusiL
	6IjjU2GD54ZWflLk76t2crYkKr1PVLCtibnTRrAyulosI8VL4P43VJrkdB98uavq9VncUX
	CjwhXlOT0pj7r8cuKmiq8n9ijjxNbqdvmm7tjRyusW/BFvHNlqrD7eCCJmQjqw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659392266; a=rsa-sha256; cv=none;
	b=tS9r5lVh5HZv7vs/P7C8WygNItAH38hw0dc5EMUeFjEs0EdXL2bWIgYovIXOt1WQgedsf5
	oT1lOsjGeGnQra4TZbipTmPlPhkZ/gVp5xW+98AyiRXFmGwEih07bHXoeEJPmXbeJqsaPM
	y7utWDWY6rdsZccmV1rmqkY0c79BgG7mD05zuhX0v+i1YGOcksXkAeAaZ3kMl4MRjwz79/
	i3oAzLRTI+8gppwrBUR14WIAuq1xeeQN4uhxtmxeE1r46kQPeWVYwStWyzSnRCBqQ+3T8d
	SEe9Fe7gNpNKF2JLxrYm/DHYRkyqxdwmdipC5FI4KQQsUceEM/WFe38FwBcVeA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--00000000000092176405e5355e0c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Shawn,

Thanks for let me know about iwlwifi driver status.
I will post at freebsd-wireless mailing soon about it.

Cheers,
Nuno Teixeira

Shawn Webb  escreveu no dia segunda, 1/08/2022
=C3=A0(s) 18:10:

> On Mon, Aug 01, 2022 at 01:05:07AM +0100, Nuno Teixeira wrote:
> > Hello,
> >
> > I'm trying to setup a failover mode ethernet/wireless as shown in
> >
> https://docs.freebsd.org/en/books/handbook/book/#networking-lagg-wired-an=
d-wireless
> > and I got a panic.
> >
> > /etc/rc.conf:
> > ---
> > ifconfig_re0=3D"ether "
> > wlans_iwlwifi0=3D"wlan0"
> > ifconfig_wlan0=3D"WPA"
> > create_args_wlan0=3D"country PT"
> > cloned_interfaces=3D"lagg0"
> > ifconfig_lagg0=3D"up laggproto failover laggport re0 laggport wlan0 DHC=
P"
> > ---
> >
> > Any ideas of what's wrong?
> > BTW, no kernel dump and I have dumpdev=3D"AUTO" in /etc/rc.conf...
>
> When I last talked to bz@, the combination of iwlwifi and lagg was
> reported as not supported. bz@ might need/want some help in that area.
>
> Thanks,
>
> --
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
>
>
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0=
3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
>

--00000000000092176405e5355e0c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Shawn,

Thanks for let me =
know about iwlwifi driver status.
I will post at freebsd-wireless mailin=
g soon about it.

Cheers,
Nuno Teixeira
<=
/div>

Shawn Webb <shawn.web=
b@hardenedbsd.org> escreveu no dia segunda, 1/08/2022 =C3=A0(s) 18:1=
0:
On Mon, Aug 0=
1, 2022 at 01:05:07AM +0100, Nuno Teixeira wrote:

> Hello,

> 

> I'm trying to setup a failover mode ethernet/wireless as shown in<=
br>
> https://docs=
.freebsd.org/en/books/handbook/book/#networking-lagg-wired-and-wireless=


> and I got a panic.

> 

> /etc/rc.conf:

> ---

> ifconfig_re0=3D"ether <wlan0 mac address>"

> wlans_iwlwifi0=3D"wlan0"

> ifconfig_wlan0=3D"WPA"

> create_args_wlan0=3D"country PT"

> cloned_interfaces=3D"lagg0"

> ifconfig_lagg0=3D"up laggproto failover laggport re0 laggport wla=
n0 DHCP"

> ---

> 

> Any ideas of what's wrong?

> BTW, no kernel dump and I have dumpdev=3D"AUTO" in /etc/rc.c=
onf...



When I last talked to bz@, the combination of iwlwifi and lagg was

reported as not supported. bz@ might need/want some help in that area.



Thanks,



-- 

Shawn Webb

Cofounder / Security Engineer

HardenedBSD



https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/m=
aster/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc




--00000000000092176405e5355e0c--

From nobody Tue Aug  2 12:34:22 2022
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 4LxvZM6Sy3z4Xyc5
	for ; Tue,  2 Aug 2022 12:34:35 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2035.outbound.protection.outlook.com [40.92.97.35])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LxvZL5T3xz3LNF;
	Tue,  2 Aug 2022 12:34:34 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=nm9UaZ6qinqb8+wPZjGg29bpYMqLTqF1cwP7fD3MZDWH9a5l1Pg4yCmjuIqVCl4hVHLqYGEltndXYRQbtiCVb/DlMg41Px9paIsjup+68l5CwHh7c4bGMzlNtPJJyPm8Qdpd8YzdTTQ8H1d3rcE3l8DWi25RR3G4pLvjNgNnUISG0+NymEf7DoDamlNv5Sikb3jU44392xLMhW5ifndJHu/NkzdU8jCJxCmdcUaw5l1v/Ls3Xt+MoCZbiBaW9cj3NQAlPA1ZXl95VoQFx40dQH3HYk/7GVTvbxWtCQs8W8NSnJB9kZFngHB40aGs7W64+OmW9ifGV2bO0NSfNU8T3A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IwNBUs/BKAgHANLuH6D8IRhIdThd8meKWxy/EZLOlhg=;
 b=PO6kdMbYPxIA2xHLXaZ7rKLMxw35224eH+0Ez1SNk6FKYX08+AEw+RYPr+84NYxOI+cyMSDmK4wC35XiX4gqRZtMt6AfPDQP+YCzK1GdKu1MAon/b8ZbnepPiChXbfYmMddfta0jbi395oTikx7C+87KMqTZKnUvnnhNvCKUn00lVC0YxjJM3BBusR7JivSZ7JuVcGx68LZlos51CY3wET/fvUOoKWEAzn8D4rzGsGAuC82qDwNFguahVC+mLFERUxDPnVvGG7AoLUv9PvOByKjEC6KH/exNwC0PUepItOGgqgNGpfSdyf1z2Cq7PsSzfc3RcSlL1tbkk4galKzWxA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=IwNBUs/BKAgHANLuH6D8IRhIdThd8meKWxy/EZLOlhg=;
 b=GguMDXjhBRGXwtkaJMhnuf9qDFuoEZvjLgaiwvJt62ZT+Uvbk3NDy0Z2y9mtYxxMc1MwmZ8LfAM921/eTj8joIvZ+i3pUN+Qnv2puHZ/Vmh3s4nzclU0ppMxb/RyyzNPodlQIZmEflIFpSc0YnuxYdB2IY9ra1RV0Jk5iq3aADF8ZYuYAyIGwIvP4WCqDBSHZMQIvcYG5XW/zqU1FA+WHOUftdm7oib245AMj9kuKAHiR/dwuSuFbHUQ6YZQxmfF/BCIaH1U5jniVmM8UNUDn6y8Q/wBix9KYv1+QWkCajl4R/m8e3hrq/6Sfh3aRFXccNY0bRkuqEUVlZbXIv0Q/Q==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CP4P284MB1204.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:a6::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.14; Tue, 2 Aug
 2022 12:34:29 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2%7]) with mapi id 15.20.5482.016; Tue, 2 Aug 2022
 12:34:29 +0000
Date: Tue, 2 Aug 2022 09:34:22 -0300 (-03)
From: Ivan Quitschal 
To: Hans Petter Selasky 
cc: Tomoaki AOKI , 
    Ivan Quitschal , 
    "freebsd-current@freebsd.org" , 
    Kurt Jaeger 
Subject: vt newcons 3 clicks mouse paste issue FIXED
In-Reply-To: 
Message-ID:
 
References:    <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
  <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp> 
Content-Type: multipart/mixed; boundary="3432851520-1375550816-1659443668=:1751"
X-TMN: [4yBITuyH0ppNeyb0E7rc6QLDuA4rVkGR]
X-ClientProxiedBy: CP3P284CA0001.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:6c::6) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <6e8cf454-95b9-13b9-13d7-f1f4a01213ca@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5ec89446-5396-4d94-0780-08da74835797
X-MS-Exchange-SLBlob-MailProps:
	gjx25WM8ZNUlUbzXBDZtlGaJGoKYbgLQjeJlurQCVEXNSEH5QIG8ERDpvj5vOj1G1vyrSL2gfzPtXBUFkvQQr2QC7S/0/QZSgn6Z92AlMCrA7tEByOjSeb4LeY8xag9tmpYuxcCPBSdhQH8aKiwekwidA/FPzV8Q5ZmjUVdCFEEPWYyRj445zaEIcd8lxhOJ3aoWZIdup4A20rwJPb9F9KeV82sA2bYNkZ514OuzkBDkh9y/s2Mr3A5R/2IHQdYpk9fda2JSTRWjlSCGbONklxLXttNxb2/iQBARwfTFClsbF1X4KfpcEVkioymGN/wMsnFKpDeUZH3hFZoy7RSDCVew9htg0DA7s8mEXFIf3qwHIhkyDrUNv/nuDeKgUB3W0w8gajA0UePtvt38z3JUqzt+vL6JrnndajJ7XPALLoZuT9M7887sN5j4WjBk31eO75x92ZR4sAZ2BZblQM/X8lgADvTf95XB1EZ7wEaqgj7lcvebsdN/pTURCoEq8zCtXZCNzGLsh3mA3+gCYEjhxFkW4jRxuP53QDLFFaMWz/9U5Qy7ZST8rV0LREMlOF08TZrLPXmUQTbnlJfsG6/FzMt4xgIcVUBhU7V5KudWWcKJxwZlX1KzNZXFiAWqGt/6u5Ag4ALJEJ72jV234F9m9WBBF1HW42jbttrMCtImA14q6JfIqrBNGLVl0L2KjBbQ4elru3j//3sC/UdvizrEfljofSusYCnbUUE7aDpaRIE=
X-MS-TrafficTypeDiagnostic: CP4P284MB1204:EE_
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	Mma/144TUdCaBM/wECVnc+4CGGnvCZqPFYyRypxs1Q30xb2bcP+RZ5xyMDFRZQKxq585MwlgOoZf6s97pgvR2rxuAhIxShD/Is7rH2QPGrNJrW/bComRCyvZPljSj5DE7pj3+NKRTrwzmJ9yonLwk+ADYzN4fuV3pAnUJpD90tRkRakS6toN7SzgiEYNj2uoD4kP3pElMNAMPBl2CibGMU5l6IAX8hAz9bO4FodhiGnmWv6itsaR6gqfNOzYePm2SQlMOX4ZYAiCwoySjKlGdlUMZhzyq108jQiRZO4hBzLVO/1NaV0wfAjl35VQofBjge8wD7ZZqryEOXSVL0sAvQzFg46bax4K5xpFDDjrukQDGvl5ae27bjQ0GNvEY+cSBo7q4gu+QKwktPQt8k1rDx7akuPeCLR2N9AqnT+0II4NDjM65ktAcLAqgs+PTQD6sLa/JJOBk8M+oUohvi43pbfxUlRKvZgjcBg+5iB6FNxNd7vWZ3iuoB/ZUcqNhqXMqBc2PBkWFb5iSTtocBXLi1TNA6xzfHVSGNTRYBfr9ZVcR7MZnkHeNKuEdo8vaGr3SFgnjQdbyvgsGNcmSUbS5MkauTFjePSlLw8y+hjw0hVC0YC5Fnq/cDGTiUCrxbgg3yF9+hxJ87PdjNLCtO8BDA==
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?ucjFXCaqUKTNMPsahFqiZ888wwKv2u/t0toqjmY+yFczzFEQnWeReNL69fJP?=
 =?us-ascii?Q?IUXXUkpd8+qo0vgKPdi6odTXdc+GRZlGLIEkMA6ohtHBTPUkzcHIbf/XkKH7?=
 =?us-ascii?Q?3o/oX2smUMsB5F4oZFuDdOJHAMi7I0nYB9wERtvllM84QB4SI0RaSwJnKQIZ?=
 =?us-ascii?Q?tr0xtcOHTPtFh5Ib8kDSVCLtMDWGwypfqdH5ufltvOI9MqIJukNVrqMYH8eu?=
 =?us-ascii?Q?VhJ7QsRMacxf6WbSflFUjz3ctI72A/so4cARwe2sCWB+vIO/3yNygt+aEMoN?=
 =?us-ascii?Q?RWnV5uEKpdRtxKZaGyLJDn3KhvGJpbyL1BqkkzjhUY+3nH+vncuVjmtYEE+J?=
 =?us-ascii?Q?0nJYHOcOU6sIh+Z0hozVayJTQ1q0fmCvjtx5w4c+ddu/6TUhNBX97Bm9tF+j?=
 =?us-ascii?Q?nz3igHCI/2FOpAB/wGir0WcAgPgmKPge59QBL6jgJLFEzzgdThsJ44QE/Oxd?=
 =?us-ascii?Q?eIY4J6PySQngjZN4sGeHvabbuuYNFctog6TSyWOxMUwNlhKdLSoVdN0fTivt?=
 =?us-ascii?Q?uucnOrDAlZM+xj3BWDrM5/SaWiwiWYNMHzWG5MI0qEOk6oQosLnTwge2rPSK?=
 =?us-ascii?Q?60NV4RPjO03F7qaLq0nhsJo7oMqKCs9KsHi6c9uE/cXgHUAPyv9KbeYQgqO7?=
 =?us-ascii?Q?lpArkjP1MLpaVIrhxeSsg9YYa0bO9huq3ZRgyDyP3nTzLmOnARIbjzjyIi8x?=
 =?us-ascii?Q?76CqyTrPvb3u9+8ifhDOjdTwhfbh6NEaFfFjyQwMpsRBZ7nQ2fxwuTYaJoOI?=
 =?us-ascii?Q?eoHFBF77Ek5egwnASW10Oqmq8annzq04hHO7DC2UK7GEB18uOAvbhI1prU/g?=
 =?us-ascii?Q?sfFNKQtWcnvNrAtAqnLCjtU6+T4tQeR/qJQbafHsN5Zac9mtPpbBsbyAAaB0?=
 =?us-ascii?Q?8HtSb/evORSKi3kT4XJdU8f1TlgZFox5d6Y6Rkv60lL+JEhp/Szm2rubyMBV?=
 =?us-ascii?Q?C8YSZMvIUNhx+GdOhhwOzuU3gP/K28w9DVJk1QXJFhuq6BZDazaxLGhUIvnN?=
 =?us-ascii?Q?Y0mawjD4dalj09qhaU1kqOIeogBrpkNUU4Z6R944U05tr5HbSklNSVjZEKYm?=
 =?us-ascii?Q?ZgBi5/++5Dp0dK/JnugS8HEfb0UBvXtT4RCltgyMB32BJnBZ4OpkP3Dts32d?=
 =?us-ascii?Q?aX2bjpqlwsWb/inHXBpUF3Lt6AFU4q/dSUGEK6xp4VXrYbTwFOImhGJYwNRN?=
 =?us-ascii?Q?NT35uwe6Tf7a4QSYt8Tbu+wzLkbIsgZuT1FBdOyV2mt3upJ43qiUYi+b7tdf?=
 =?us-ascii?Q?s3z9bPImEHd2Fuo8OwzomTXhPJNB2FXYB0iSL2RqKg=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ec89446-5396-4d94-0780-08da74835797
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2022 12:34:29.4476
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP4P284MB1204
X-Rspamd-Queue-Id: 4LxvZL5T3xz3LNF
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=GguMDXjh;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.35 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-1.91 / 15.00];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.97)[-0.965];
	NEURAL_SPAM_MEDIUM(0.95)[0.954];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	MIME_BASE64_TEXT(0.10)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.35:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.97.35:from];
	HAS_ATTACHMENT(0.00)[];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RCPT_COUNT_FIVE(0.00)[5];
	DKIM_TRACE(0.00)[hotmail.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_CC(0.00)[dec.sakura.ne.jp,hotmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--3432851520-1375550816-1659443668=:1751
Content-Type: text/plain; format=flowed; charset=US-ASCII


Hi guys

Currently , if you click 3 times in order to select the entire row, its just not 
working as it should.
i fixed that please find below and attached the patches

With this change now we can do a 3 clicks and paste , i dont know, in some 
command, and it will be executed just fine, like it was in syscons, and still is 
in xterm/ linux etc

now if the event is a 3 mouse clickss select, the space trim is made on the 
right and an  is included

thanks

--tzk


--------------------
--- sys/dev/vt/vt_buf.c.orig    2022-08-02 08:44:27.229782000 -0300
+++ sys/dev/vt/vt_buf.c 2022-08-02 08:45:02.703697000 -0300
@@ -771,7 +771,7 @@
  }

  void
-vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz)
+vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz, int mark)
  {
         int i, j, r, c, cs, ce;
         term_pos_t s, e;
@@ -799,7 +799,7 @@
                         buf[i++] = vb->vb_rows[r][c];

                 /* For all rows, but the last one. */
-               if (r != e.tp_row) {
+               if (r != e.tp_row || mark == VTB_MARK_ROW) {
                         /* Trim trailing word separators, if any. */
                         for (; i != j; i--) {
                                 if (!tchar_is_word_separator(buf[i - 1]))
--------------------

--- sys/dev/vt/vt_core.c.orig   2022-08-02 08:43:15.436415000 -0300
+++ sys/dev/vt/vt_core.c        2022-08-02 08:43:49.120096000 -0300
@@ -2287,7 +2287,7 @@
                         VD_PASTEBUFSZ(vd) = len;
                 }
                 /* Request copy/paste buffer data, no more than `len' */
-               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len);
+               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len, mark);

                 VD_PASTEBUFLEN(vd) = len;

---------------------

--- sys/dev/vt/vt.h.orig        2022-08-02 08:41:23.888584000 -0300
+++ sys/dev/vt/vt.h     2022-08-02 08:41:54.504309000 -0300
@@ -238,7 +238,7 @@
  #ifndef SC_NO_CUTPASTE
  int vtbuf_set_mark(struct vt_buf *vb, int type, int col, int row);
  int vtbuf_get_marked_len(struct vt_buf *vb);
-void vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz);
+void vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz, int 
mark);
  #endif

  #define        VTB_MARK_NONE           0
--------------------------

--3432851520-1375550816-1659443668=:1751
Content-Type: text/plain; charset=US-ASCII; name=vt.h.diff
Content-Transfer-Encoding: BASE64
Content-ID: 
Content-Description:
Content-Disposition: attachment; filename=vt.h.diff

LS0tIHN5cy9kZXYvdnQvdnQuaC5vcmlnCTIwMjItMDgtMDIgMDg6NDE6MjMuODg4NTg0MDAwIC0w
MzAwDQorKysgc3lzL2Rldi92dC92dC5oCTIwMjItMDgtMDIgMDg6NDE6NTQuNTA0MzA5MDAwIC0w
MzAwDQpAQCAtMjM4LDcgKzIzOCw3IEBADQogI2lmbmRlZiBTQ19OT19DVVRQQVNURQ0KIGludCB2
dGJ1Zl9zZXRfbWFyayhzdHJ1Y3QgdnRfYnVmICp2YiwgaW50IHR5cGUsIGludCBjb2wsIGludCBy
b3cpOw0KIGludCB2dGJ1Zl9nZXRfbWFya2VkX2xlbihzdHJ1Y3QgdnRfYnVmICp2Yik7DQotdm9p
ZCB2dGJ1Zl9leHRyYWN0X21hcmtlZChzdHJ1Y3QgdnRfYnVmICp2YiwgdGVybV9jaGFyX3QgKmJ1
ZiwgaW50IHN6KTsNCit2b2lkIHZ0YnVmX2V4dHJhY3RfbWFya2VkKHN0cnVjdCB2dF9idWYgKnZi
LCB0ZXJtX2NoYXJfdCAqYnVmLCBpbnQgc3osIGludCBtYXJrKTsNCiAjZW5kaWYNCiANCiAjZGVm
aW5lCVZUQl9NQVJLX05PTkUJCTANCg==

--3432851520-1375550816-1659443668=:1751
Content-Type: text/plain; charset=US-ASCII; name=vt_buf.diff
Content-Transfer-Encoding: BASE64
Content-ID: 
Content-Description:
Content-Disposition: attachment; filename=vt_buf.diff

LS0tIHN5cy9kZXYvdnQvdnRfYnVmLmMub3JpZwkyMDIyLTA4LTAyIDA4OjQ0OjI3LjIyOTc4MjAw
MCAtMDMwMA0KKysrIHN5cy9kZXYvdnQvdnRfYnVmLmMJMjAyMi0wOC0wMiAwODo0NTowMi43MDM2
OTcwMDAgLTAzMDANCkBAIC03NzEsNyArNzcxLDcgQEANCiB9DQogDQogdm9pZA0KLXZ0YnVmX2V4
dHJhY3RfbWFya2VkKHN0cnVjdCB2dF9idWYgKnZiLCB0ZXJtX2NoYXJfdCAqYnVmLCBpbnQgc3op
DQordnRidWZfZXh0cmFjdF9tYXJrZWQoc3RydWN0IHZ0X2J1ZiAqdmIsIHRlcm1fY2hhcl90ICpi
dWYsIGludCBzeiwgaW50IG1hcmspDQogew0KIAlpbnQgaSwgaiwgciwgYywgY3MsIGNlOw0KIAl0
ZXJtX3Bvc190IHMsIGU7DQpAQCAtNzk5LDcgKzc5OSw3IEBADQogCQkJYnVmW2krK10gPSB2Yi0+
dmJfcm93c1tyXVtjXTsNCiANCiAJCS8qIEZvciBhbGwgcm93cywgYnV0IHRoZSBsYXN0IG9uZS4g
Ki8NCi0JCWlmIChyICE9IGUudHBfcm93KSB7DQorCQlpZiAociAhPSBlLnRwX3JvdyB8fCBtYXJr
ID09IFZUQl9NQVJLX1JPVykgew0KIAkJCS8qIFRyaW0gdHJhaWxpbmcgd29yZCBzZXBhcmF0b3Jz
LCBpZiBhbnkuICovDQogCQkJZm9yICg7IGkgIT0gajsgaS0tKSB7DQogCQkJCWlmICghdGNoYXJf
aXNfd29yZF9zZXBhcmF0b3IoYnVmW2kgLSAxXSkpDQo=

--3432851520-1375550816-1659443668=:1751
Content-Type: text/plain; charset=US-ASCII; name=vt_core.diff
Content-Transfer-Encoding: BASE64
Content-ID: 
Content-Description:
Content-Disposition: attachment; filename=vt_core.diff

LS0tIHN5cy9kZXYvdnQvdnRfY29yZS5jLm9yaWcJMjAyMi0wOC0wMiAwODo0MzoxNS40MzY0MTUw
MDAgLTAzMDANCisrKyBzeXMvZGV2L3Z0L3Z0X2NvcmUuYwkyMDIyLTA4LTAyIDA4OjQzOjQ5LjEy
MDA5NjAwMCAtMDMwMA0KQEAgLTIyODcsNyArMjI4Nyw3IEBADQogCQkJVkRfUEFTVEVCVUZTWih2
ZCkgPSBsZW47DQogCQl9DQogCQkvKiBSZXF1ZXN0IGNvcHkvcGFzdGUgYnVmZmVyIGRhdGEsIG5v
IG1vcmUgdGhhbiBgbGVuJyAqLw0KLQkJdnRidWZfZXh0cmFjdF9tYXJrZWQoJnZ3LT52d19idWYs
IFZEX1BBU1RFQlVGKHZkKSwgbGVuKTsNCisJCXZ0YnVmX2V4dHJhY3RfbWFya2VkKCZ2dy0+dndf
YnVmLCBWRF9QQVNURUJVRih2ZCksIGxlbiwgbWFyayk7DQogDQogCQlWRF9QQVNURUJVRkxFTih2
ZCkgPSBsZW47DQogDQo=

--3432851520-1375550816-1659443668=:1751--

From nobody Wed Aug  3 17:37:09 2022
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 4LyfFG34Fnz4YFT4
	for ; Wed,  3 Aug 2022 17:37:22 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2012.outbound.protection.outlook.com [40.92.97.12])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LyfFD3LFwz42Ym;
	Wed,  3 Aug 2022 17:37:20 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=CZxZiOdIl7gS64Jbp526giaJ/eqvovhtFXlAn38GeAY6QDrW+LNmnM4K4m7U2Sx/xpuVRwpRKqPUmbBfWIqzT8cpnEm4rUU4zj6HVGveBpKqpp2I2KqCGJQUi3hjTYs+hhK6oUVA1A2wsaPiBLa9XOAt+rpgQj2HW6sK0FXoRbihoiXM4XENq/6crYBksGffvgc3WB+5RbeA+WVQMPXLQoaXAT8lxjA5G5Pyig5F8IBsGRmC/mb46azvhpLFolSiu9btVKEGJU9DosEd/De3Uy83b7YGnpaA+hKLFyTUXIKFRCurfGu2WhWYmMaLWxV2ATpmp5+T0nUIZuR8Bfq5kg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bzh9IuZiWPxYvQRN3lGDTvl9YlFppokeK/tNTKZ6+jg=;
 b=VPb+DbvbXBLT+BUaSu3I/eBb1CCfZ3HtceJE1ySD77jlBZHd3hI3ESKw800zq35Tp7kyS/HFjJx++kuYleSvw6TtRCA7Hn2WyuaJ13rIea3sYaEg86xUaMLfG9FrHb8+nXxj3gZaM0wBl8PNarK3vV9DWDScJOgYLuehiY5maXHN/HFhMDAv0zvrXid0tbGi4YkEwFm3xR4bNVaXGGkh5IDLMO3S1ltYPlfb1ZMEizsac1pj0Q59QR9a+NLVXfu7gVHzSHh0jVxl7+8d/60lBMgKugTFU+bP8l1KzmMs1PzMGvkmRcV7CWHqm5aznohWj0+B3QH3jwoeqKzO5p/0VQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=bzh9IuZiWPxYvQRN3lGDTvl9YlFppokeK/tNTKZ6+jg=;
 b=MqGzRn5xXo/aYohHhxEhuw1/cz30rH4JRDNoeOzbHJy3S1kIOtrrWeo7SXHJ4YWGYZ0PNT3R7/2pxsWV6s9U6Gh8vMsZwGwwRKMV6Phd7ucWTKfCNNKM6R7cN5A7xoLSfdhTmmxJK8AzXmJFIjsbepXHM/n2q+kkBRFmpIuFHxUcNY2RqeJZzktEYB4ET0t3J7ofsvu2qQb5hUIXRDwZb9+tiFRZaDZn6CnJ3c4K5VIJlZAYrNQAj/2yORHiJ0y5C2F5ZopyzoTr8yt+dnzL0owYaq8yUX6TROX8wKXjZRe7EnOU2g+MJk9IiDN+G2biXu552uS12YVMs2gZZJgQwA==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CP4P284MB1585.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:108::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5482.12; Wed, 3 Aug
 2022 17:37:16 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2%7]) with mapi id 15.20.5482.016; Wed, 3 Aug 2022
 17:37:16 +0000
Date: Wed, 3 Aug 2022 14:37:09 -0300 (-03)
From: Ivan Quitschal 
To: Ivan Quitschal 
cc: Hans Petter Selasky , 
    Tomoaki AOKI , 
    "freebsd-current@freebsd.org" , 
    Kurt Jaeger 
Subject: Re: vt newcons 3 clicks mouse paste issue FIXED
In-Reply-To: 
Message-ID:
 
References:    <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
  <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp> 
 
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-TMN: [DpeVdVblSVSbNcyiLI1Lh/7vsMB8XKNS]
X-ClientProxiedBy: CP6P284CA0005.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:1aa::15) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 999bdf05-9bf3-483d-d259-08da7576ceae
X-MS-Exchange-SLBlob-MailProps:
	gjx25WM8ZNUisu3qrbEAqaAOdVId8I0rBzIkimuUt/e0VCpKwAweWdEO+F9130pLnL/xP9nHL+jx8WG6lH/LiInckpR2BuCH/HC4YE27x5g1KHD0giTS37G6gAKp3g2LZYQk+JKhhBEkwSf/++NUTdnyWKuutmng9ylfO2O0vKH5dQdhB+9WFllGvQWe8OE1nMlDmeh13qrP5/J3g0j/c/7dN1oi18SpLKLGwVjmf+0IEwVluvVJA+ovHn9KMa8JZGQTHPfHMtXQ0Dow5FpTIqdcAW1as3Rmep8fpNEzxfBRR5LbJRcTKXjq8YNmY77Yx4U7RGsjDdOR3z6tFnG128OShSCDYf3Tr7JqRymhvBZAj6FsRIdUl5b/amZcf8MC8Eyyfkdw0bu42TezS54uifjwAQRkllqoanmTHcIWoYApY2F+Qj+2IX+P4nP3hMufK4otlubdQjBCxSlVbnSD7+AAhrXvbVdQ0LdAxZid2oyj/WTqTP5RFKmAiBqFysR3afIyRVDFdOlR9moG08qspBu6JPSt/SQdlZJD31gHa2PIcEfR4w4Rr0rNqM2af5XdwnUWfh4tOHCGYUr07g1+2U3+m1gxQ/hlkQrc95byhG04BNdyf2KZ3ODYgVHsqQ/ns56kkt7n6Z+fzXYHbqKrAqfDDOTYrxJCrNC4QQyvJjMreevEkIjS4iOIC4Vy/zaWlKu+hZY6J2+GNKLxZ6wUs3khC8jhOL77S5tYBE8zZTA=
X-MS-TrafficTypeDiagnostic: CP4P284MB1585:EE_
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	VZGclJ3XzHRZd0gOrdqTFsGLhp5kvwBvpXAYlNtaMr5dQoP68RK6qMzuv/OXH7+aUBFjGOGC/dFBa8/oXi9+miVIX1x5ThegoInCCXH/HGKiFgJuksdCipFrmpuYD0Puxtse+6UdrXVMyVuhBg6gnzUUaZV+fXafULwAop/qdhzkeMY+cpa9mVA9zBsjlHGZMllcH2fBp8XZNQsv1Msl6pDMEzDIJzuIYkUo/nAurxahoS4us/CyRMrcROklYKDUvz8jt94yQND0fZhqI9EhVKjcxVqw/gC99z0Cr0LdXhiLXHVV8yU8Ugn/uFt4p/JBaqXPg6zGrvMX1WnN7pSpBnmQouM7CEHCCuHICPjT2dBaY4JCJ/IcsjwY0vL5aPI1vYHYnGmugAsICHpWv0d5RXofV+Tj5T2QsI/T4bvfPXRzLzKknYFFLezZiz98TLOWP5XAf6QdUINxd4+ZjetfIuY87v1VEwZNMZUbuGkWFF3bCfBttS+MWKV8xZUfIjE2vGJYZF+OgOV7tQ49Sn0IIDGysTiWA1DansjnJ7sSKlTWjeSKSXXl5aUIyD7AeZjvqsKqQNlOem6Ti46L8cnKb764gKoJFm1LVmCNet3JZV0Nx7vLgxr4vsAetIdpWZr8g4000wqjWXp+FhceRoAfeKhKCnoE3wCS5iuSRs2uPtcAbrS2nqJQirBtxtGubY2b
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?KQwAXET4QbB98HTF011COugLH5YwxvpLuA2adOYaoxNa3jvorg6zMlQEZXxr?=
 =?us-ascii?Q?4dSJgvgA4b0ZO71hXwCGC/73sDNS629I9xG38iiyj6KfaDwf++dLR2JA9+dm?=
 =?us-ascii?Q?QByMnSCUnU+/R7MPQpQMuLvWSKWPOy/x/PxSVCHZj3/bfG3OV+Xnre5omdXF?=
 =?us-ascii?Q?mRCt4Eo6QtllxFXgCTUTIQuTk91dif1443Va1zLGNZ/igWUPBLECkrR1vrfM?=
 =?us-ascii?Q?2KdVkEuKWN/vsBQfWt/JgH+2BYD+ivQL1IgTgh6yVcftv6ZGwoEQV2IIM5Fw?=
 =?us-ascii?Q?xbc1X8349aItRUEQmnoVPX7sm+tk8FIksV0cSUqRWEyt++yZ2Pf9mnlq8X1Y?=
 =?us-ascii?Q?JAyXonllIPkpsWEKJ1IOqcMr/FnFTy1BPFJa6LcDpiIMjnkjIXfJAUyIz0Rl?=
 =?us-ascii?Q?GFhpDvYI7QtRBhpHDHtRFkAKEIV/4ip/grPdOjVxV890WCQ47Cs8Tdy34ZBM?=
 =?us-ascii?Q?nGeh1PA2vugs8EoXFZUeJTXBhkiYfHVb6Dfl5TiOP58AOW5tHJe2vVTHF9xv?=
 =?us-ascii?Q?FJD2DT99+wCAp4oLk9AYLAE6CCh0i9DP7ENZmxp5ZIC7jxGpC4ZSMVU3aV+0?=
 =?us-ascii?Q?too3QEaqqry8bSoqtUifOWE0wQNS36vHOPAlI6W8/FnCvUyh21GgdpGuhkHi?=
 =?us-ascii?Q?kw/EXnV6qghgyLODXIQ/wGzhz81Rj7gFHoiirlp1EuClUPzxkCDoS1YZReYk?=
 =?us-ascii?Q?pWWOdJBa3UMnocQdNzbuwwVqMJsbU0IjmpEPB4w3wmwJoi2Ems6B6tci4E57?=
 =?us-ascii?Q?s2rFw1+gTgFdEOb8eJHbEjNBUrh0DpmyD8W4nizEPyZ1BbNIpFDwmoBrjtvr?=
 =?us-ascii?Q?QyoXUC3B477vE/G2cb467Vr5OgTd7JLRxTD9xRgGN5Bm2OxXn3a2vdW9GXcG?=
 =?us-ascii?Q?CbBOcacWhs2/16vGseDPgMFJ+7xU3J+g2LFNL/sUvX4xVRnoaWBwJLqiMlmW?=
 =?us-ascii?Q?esponKfTWspEmNbl4FKCclqrkDmFYiHXYId54Lt4EdRpm09ks6IYaE3lfiUh?=
 =?us-ascii?Q?PXMGgpS9QfBirUpoz/YPMfF6ackcDp2Uuavp8OHaAzwfLPBWCn+YMW/9liq5?=
 =?us-ascii?Q?q4/nL375wUV9NdGVOUxE5t9LEVDkbN9N67sy5CfxUF1m744SvbVM/Ea6OJRu?=
 =?us-ascii?Q?cOfyXI4WJsVxa6C2wWh8HnmZ4chwapH4dbWYxVM89Cs3EUhgQ90/EEK3+ubZ?=
 =?us-ascii?Q?sgiW01ZrDVClBp44I/n0brEfW19EMXY9bTMudYqfceSPdUgJwIYbsOfduq1K?=
 =?us-ascii?Q?vzzJbqu6HBo52Rdkuds8w9BAAd1qco8eTOiWde5DJg=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 999bdf05-9bf3-483d-d259-08da7576ceae
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2022 17:37:16.4250
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP4P284MB1585
X-Rspamd-Queue-Id: 4LyfFD3LFwz42Ym
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=MqGzRn5x;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.12 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.46 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_SHORT(-0.97)[-0.969];
	NEURAL_HAM_LONG(-0.97)[-0.967];
	NEURAL_HAM_MEDIUM(-0.53)[-0.526];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[hotmail.com];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.12:from];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FREEMAIL_FROM(0.00)[hotmail.com];
	RCPT_COUNT_FIVE(0.00)[5];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_EQ_ADDR_SOME(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On Tue, 2 Aug 2022, Ivan Quitschal wrote:

>
> Hi guys
>
> Currently , if you click 3 times in order to select the entire row, its just 
> not working as it should.
> i fixed that please find below and attached the patches
>
> With this change now we can do a 3 clicks and paste , i dont know, in some 
> command, and it will be executed just fine, like it was in syscons, and still 
> is in xterm/ linux etc
>
> now if the event is a 3 mouse clickss select, the space trim is made on the 
> right and an  is included
>
> thanks
>
> --tzk
>
>
> --------------------
> --- sys/dev/vt/vt_buf.c.orig    2022-08-02 08:44:27.229782000 -0300
> +++ sys/dev/vt/vt_buf.c 2022-08-02 08:45:02.703697000 -0300
> @@ -771,7 +771,7 @@
> }
>
> void
> -vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz)
> +vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz, int mark)
> {
>        int i, j, r, c, cs, ce;
>        term_pos_t s, e;
> @@ -799,7 +799,7 @@
>                        buf[i++] = vb->vb_rows[r][c];
>
>                /* For all rows, but the last one. */
> -               if (r != e.tp_row) {
> +               if (r != e.tp_row || mark == VTB_MARK_ROW) {
>                        /* Trim trailing word separators, if any. */
>                        for (; i != j; i--) {
>                                if (!tchar_is_word_separator(buf[i - 1]))
> --------------------
>
> --- sys/dev/vt/vt_core.c.orig   2022-08-02 08:43:15.436415000 -0300
> +++ sys/dev/vt/vt_core.c        2022-08-02 08:43:49.120096000 -0300
> @@ -2287,7 +2287,7 @@
>                        VD_PASTEBUFSZ(vd) = len;
>                }
>                /* Request copy/paste buffer data, no more than `len' */
> -               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len);
> +               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len, 
> mark);
>
>                VD_PASTEBUFLEN(vd) = len;
>
> ---------------------
>
> --- sys/dev/vt/vt.h.orig        2022-08-02 08:41:23.888584000 -0300
> +++ sys/dev/vt/vt.h     2022-08-02 08:41:54.504309000 -0300
> @@ -238,7 +238,7 @@
> #ifndef SC_NO_CUTPASTE
> int vtbuf_set_mark(struct vt_buf *vb, int type, int col, int row);
> int vtbuf_get_marked_len(struct vt_buf *vb);
> -void vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz);
> +void vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz, int 
> mark);
> #endif
>
> #define        VTB_MARK_NONE           0
> --------------------------
>


hi All

this is the solution i found to fix the PASTE MARK  issue. today when you 
select and paste something , the highlight mark stays on screen forever, until 
you do a mouse 1 button click.

this is the way i found to correct that. with this change the highlight mark 
disappears after you right click to paste.


in mouse event, for either
     case VT_MOUSE_PASTEBUTTON:
or
     case VT_MOUSE_EXTENDBUTTON:

i just set "mark" to VTB_MARK_START (i dont use this EXTENDBUTTON feature

i didnt find a better way to do that tho, in case any commiter wants to apply 
that too

personally this problem is being bugging me for quite some time now. im sure im 
not the only one.

thanks

--tzk


PS: below patch includes the previous change on this email chain as well

--- sys/dev/vt/vt_core.c.orig   2022-08-02 08:43:15.436415000 -0300
+++ sys/dev/vt/vt_core.c        2022-08-03 12:18:40.216670000 -0300
@@ -2228,23 +2228,28 @@
                 case 0: /* up */
                         break;
                 default:
+                       mark = VTB_MARK_START;
                         vt_mouse_paste();
                         break;
                 }
-               return; /* Done */
+//             return; /* Done */
+
         case VT_MOUSE_EXTENDBUTTON:
                 switch (cnt) {
-               case 0: /* up */
+               case 0:
                         if (!(vd->vd_mstate & MOUSE_BUTTON1DOWN))
-                               mark = VTB_MARK_EXTEND;
+                               mark = VTB_MARK_START;
+//                             mark = VTB_MARK_EXTEND;
                         else
                                 mark = 0;
                         break;
                 default:
-                       mark = VTB_MARK_EXTEND;
+//                     mark = VTB_MARK_EXTEND;
+                       mark = VTB_MARK_START;
                         break;
                 }
                 break;
+
         default:
                 return; /* Done */
         }
@@ -2287,7 +2292,7 @@
                         VD_PASTEBUFSZ(vd) = len;
                 }
                 /* Request copy/paste buffer data, no more than `len' */
-               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len);
+               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len, mark);

                 VD_PASTEBUFLEN(vd) = len;



From nobody Thu Aug  4 13:15:06 2022
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 4Lz8Nb0kJ9z4Xp2D
	for ; Thu,  4 Aug 2022 13:15:27 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lz8NZ2dH6z4HYt;
	Thu,  4 Aug 2022 13:15:26 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.3.0.5] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 240A026038B;
	Thu,  4 Aug 2022 15:15:15 +0200 (CEST)
Message-ID: <68e5f1f2-4255-be24-6da7-dc43d0fc98e6@selasky.org>
Date: Thu, 4 Aug 2022 15:15:06 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: vt newcons 3 clicks mouse paste issue FIXED
Content-Language: en-US
To: Ivan Quitschal 
Cc: Tomoaki AOKI ,
 "freebsd-current@freebsd.org" ,
 Kurt Jaeger 
References: 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Lz8NZ2dH6z4HYt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[hotmail.com];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[selasky.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi Ivan,

Can you upload your patch to differential revision at freebsd.org ?

https://reviews.freebsd.org/differential/

Then maybe someone else or me can approve and commit it!

--HPS

From nobody Thu Aug  4 14:04:27 2022
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 4Lz9TD65btz4Xw2L
	for ; Thu,  4 Aug 2022 14:04:32 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2077.outbound.protection.outlook.com [40.92.96.77])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lz9TD04Kcz4PgF
	for ; Thu,  4 Aug 2022 14:04:32 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=gH3jUKXEvXsnhgT73zPHIIQfWYHfWH+zEatTUSrZMnADpYJPy0Tc4Vhaysnqo1Agtbjbjuj5+/LgLPIIFOsTgsCUW2u0O7BHH1wxGNmdvFuy8behEm51tsc1iXhKo6vmN8FGMkT5fkfky8oo6hTsjv8uUxWt9H7gXnApqaAfqSkfiFTkqn6nXDdL62VOdbEp2An2jylpno3E3UUnkkJ54mwRqF6LCgXGCrqCMM41OVRjEWcfiduEi9Gm9VWRTUVqMnznCT29RqgzTL+rT+Ae0SDybqV0Dk6WhVJXNgOnJYl4I5XU2Sx3CX0ASw47jOGiHDHA63s+Q8sG/764y7dJNw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=SPMTOSOeUw8En2uo+MAtzNKXQaAA12H+fV3DiQJdGgA=;
 b=B9zkixVEfnqxXIG+t86cB7VP6Ux3uhCE+T0aoBftRSOtCoGe5f5il3QRMzFEl7qjkmlnEkNx0l1/cQh/vFJB05XkpKlSeDHvUKnrQlxRLf5PaSsC/vlwPt1d2OQrf0wQGiIzgg9As2nLq4hwiD7NqoM7foz6DV4VeFShpZiK2GXxw9blSCUgILlg2O7IxEIzBR0Y9pa6W1EdkK8L0SbZnHSuFfw9kcOucIbGjMc20RvHNJ8rMClVe5ttluJDuStIjGQBX3x0qfcA+P+OBGFYo1pnckvZjOfZKtUSpTPVyMJkxXqJ0CjjjpmsRd23Us7NoJAnwizi2qSTe9UYRpjkew==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SPMTOSOeUw8En2uo+MAtzNKXQaAA12H+fV3DiQJdGgA=;
 b=kh7oYRQvP45sYnJnSq5cadZl4CYI2vvW86kwoKt1GtcnjnS7Zxk10OOx4yKLdPLhuVktP+gGM2dWBSROSihYdPzvYdaFHopFyKheifUTdhNRC1uh0OZjLKVTQcQnbfpKvUAGG2Vv3OuKAgDFa7R2mxy+81EswLJUDAxN1k8u9M/eDUcUsCVgmQYVH3iRkm2NjM9UTW/HBWKGC2GIOJrR+aNvADrkhhZb18267nw58AIyJuDBPTn2rRRYa+QHrZwBu3/GDHlp1+5bJ3k5YS8XsiZBPiNAx4onIxto8CCFTrhUFb79Un2W6CzssgfN7iEUHO1cexB0KdWcJrs1r2sw+w==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by ROAP284MB1215.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:7f::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.14; Thu, 4 Aug
 2022 14:04:27 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2%7]) with mapi id 15.20.5482.016; Thu, 4 Aug 2022
 14:04:27 +0000
From: Ivan Quitschal 
To: Hans Petter Selasky 
CC: "freebsd-current@freebsd.org" 
Subject: RES: vt newcons 3 clicks mouse paste issue FIXED
Thread-Topic: vt newcons 3 clicks mouse paste issue FIXED
Thread-Index: AQHYpmw1CB+cesrdUEGiwPuu2IoeEK2eyDAA
Date: Thu, 4 Aug 2022 14:04:27 +0000
Message-ID:
 
References:
 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
In-Reply-To:
 
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-tmn: [zo2Kcl8ftlr2KsZSc1JjdFW2U08pPQ3IuC4t0M3HoN1XCOsLlj20DUwbEDjSK579]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1fa83ebd-fd63-487c-1053-08da76223ea6
x-ms-traffictypediagnostic: ROAP284MB1215:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 u9MtQUQFQx7S28+U075ddNd8236vwkBDZeVb86Zamea9uPRWrI0eRO77YHSFZvWgEpP1yYJmqjWR1XuuHAla+48uN4ZduKig+m8rQo8LGXReSBsKEI5ySn6lwf5RV4P1Zq4H/kKtx6pwa1SVdfRIyF0IrFKOdE6qHt8mA8pwKNOLGla06dv41082C1ObBL0mh41N7ILjYtI1pRwq9HWj6YP1ByvMND+34IX/aUrxBg2iNLH7SPz9Ntebz4ar+cBaWEWai7PPIpt2YE6AeezSnbU3LqIOvZpgtaG9hapICWZbAEWSxl4yfefce4jtpJOZBWnrHWhIfU0grlaiKVtwpjnGILo/+mfxDB/b+Nis/DO2W/dUdsDrc1wAF/+SeLsCl9j8AZoVjJs7tJjshBUFbWYMW//P1ItlH6+otJ9nAL+GEevWz/1R7/qBoi9cnCE6QYzVLRWkQxzAJlSRz2aLRHotP0BFGtGvGUPXxAiCDjhp1i+hxr7n9RBAe9tl7p5F1hxRDbe5tc+wO6uo6YICc3fKkbd7Dscf2f0bffiytFziaUacg9exbXY+ONfAks5v0s+gYuenlYr/97o8gPQO1R2ORaSxkvmQHoXnLvGwbtp+2upqRsrPvqZj2LspiPHl
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?3VflwatLQyhe1N6AMxYB99eDdhzDky5QMrmIH92dk4dKOeLArz6GRJjr4+?=
 =?iso-8859-1?Q?6cQHhxxrnpNTw5dTZNQtn9gOaFllZrKTNMNc1lAw2ygkLeCApiJdd9D2Ca?=
 =?iso-8859-1?Q?D4+4wn1g3rhpPqqWGLrrxtjiTsgsnal7VwHOlG/kpWx8ZwBOnwmuOHfG21?=
 =?iso-8859-1?Q?ubXkFwFCq2o87G6ftqeNHjiD5m7WOA5KPJqzXgmLcqvwY/zEfTFr/u5JJy?=
 =?iso-8859-1?Q?PBeYuf/qFYbEM5TgzplomZSKehGaeh69YCCAz9FkSqp/mc3r3370uFF7Uh?=
 =?iso-8859-1?Q?jsXmi0NS/3sntFnGJ98yfNgEE2Jl7QbuKLfMljcWwdMbp+7f91F0RNNUCa?=
 =?iso-8859-1?Q?9fvaIGVh5DkvjUl1jI1PpH4yb4fSGEHzhcOrAkcMbUhAP4jG008tsrvf4O?=
 =?iso-8859-1?Q?LKldOJfJ408WlAR+GPLqYr0XQedl3/tuDqMehr8xDyR586TZ0oAMz3vG7F?=
 =?iso-8859-1?Q?WdWymPF+EBgwP8GQzL5EpTCja8GUhXPdVHUnHbeLChs2bjj3avk50BkVZN?=
 =?iso-8859-1?Q?CM3DYm/6IKoEpiLfDHGUAHdvXnURfBvNu99v/wIx3TCG5i7HAR4IV28LiC?=
 =?iso-8859-1?Q?xxFmY2U1R2466XcBdW6rJMS/15BtcKDRQfuXwyLuPcfBtpD6OeAWxveIR8?=
 =?iso-8859-1?Q?j2teLIlvy6KTDQhFKV6kzMGWbkx6GKHMcma4MfAC92fMOK+axdqIry9RpC?=
 =?iso-8859-1?Q?pPBE7c1TzfWnvasJvKu/xVh5o2SCZ+02fgOzBMTsmAKs2YpLUmvsHYPSlf?=
 =?iso-8859-1?Q?4spFT6zGNar0XOgjAipCpgb5tFEVsCVfdNHOisr3zv5VRyM1K8DgJcj2L7?=
 =?iso-8859-1?Q?anxsi0W2qyypsPwlrg7p/6OzryP/Jon9FkDVk5mqc9UpqVmQNcGW8Yc68b?=
 =?iso-8859-1?Q?VqiCT1Ptv9xkVUYqmdyxKN28qqn9+nOjeEkNQNtg4/0ottSRyEPK4wQ+aE?=
 =?iso-8859-1?Q?OM7RwcQCykNo5k4AlWRKcy1F2uJ6YzpMwcwqy9vpLzj0d1B5REckbHQdgn?=
 =?iso-8859-1?Q?l30ZSLXqg84Cf0YiLD3uW6O+OZASzAzHhNgqAYOzd82rWhcKs830sySXw6?=
 =?iso-8859-1?Q?UrI7oPksShOrazNRCEBCj8TUu+wQMha/2uwdF/RZEymgLYGG494YScPL89?=
 =?iso-8859-1?Q?mJ07ebLZVgJHEOHPLM/dqGXVltxjL4lxnzfg8iJ6IbWB2YE7WmtSXnaa3K?=
 =?iso-8859-1?Q?y8sQlnu6DXSgBAl7+XQHJsXyAXBs9yRgZbR7ooVPcecvtPJZbVJLTgRBEK?=
 =?iso-8859-1?Q?MtyqRChCfzYa588n071P7I+IUFvCKcFxRKjWI3j3/UtNnApzIxgvVdKmjv?=
 =?iso-8859-1?Q?3RmyyyMSzArsO4ekUaero/JrDbYNc39AB1r79oDLxmnOASLg76pDmDeH3G?=
 =?iso-8859-1?Q?ChE+dTTDem?=
Content-Type: multipart/mixed;
	boundary="_003_CP6P284MB190086D2AD26A14E0C5DA002CB9F9CP6P284MB1900BRAP_"
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-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 1fa83ebd-fd63-487c-1053-08da76223ea6
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2022 14:04:27.7757
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB1215
X-Rspamd-Queue-Id: 4Lz9TD04Kcz4PgF
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=kh7oYRQv;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.77 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-3.05 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.98)[-0.981];
	NEURAL_SPAM_MEDIUM(0.93)[0.928];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~,3:~];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.96.77:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[hotmail.com];
	RCVD_COUNT_THREE(0.00)[3];
	HAS_ATTACHMENT(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

--_003_CP6P284MB190086D2AD26A14E0C5DA002CB9F9CP6P284MB1900BRAP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Hans

D36042 created
How can I include more patch files in the same defect number? D36042
https://reviews.freebsd.org/D36042

Its missing the vt.h.diff and vt_core.diff
Both attached

Should i have put all three in the raw patch creation combo box when I was =
creating the defect?
Sorry my dumbness  , never used that phabricator=20

--tzk





> -----Mensagem original-----
> De: Ivan Quitschal 
> Enviada em: ter=E7a-feira, 2 de agosto de 2022 09:34
> Para: Hans Petter Selasky 
> Cc: Tomoaki AOKI ; Ivan Quitschal
> ; freebsd-current@freebsd.org; Kurt Jaeger
> 
> Assunto: vt newcons 3 clicks mouse paste issue FIXED
>=20
>=20
> Hi guys
>=20
> Currently , if you click 3 times in order to select the entire row, its j=
ust not
> working as it should.
> i fixed that please find below and attached the patches
>=20
> With this change now we can do a 3 clicks and paste , i dont know, in som=
e
> command, and it will be executed just fine, like it was in syscons, and s=
till is in
> xterm/ linux etc
>=20
> now if the event is a 3 mouse clickss select, the space trim is made on t=
he right
> and an  is included
>=20
> thanks
>=20
> --tzk
>=20
>=20
> --------------------
> --- sys/dev/vt/vt_buf.c.orig    2022-08-02 08:44:27.229782000 -0300
> +++ sys/dev/vt/vt_buf.c 2022-08-02 08:45:02.703697000 -0300
> @@ -771,7 +771,7 @@
>   }
>=20
>   void
> -vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz)
> +vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz, int
> +mark)
>   {
>          int i, j, r, c, cs, ce;
>          term_pos_t s, e;
> @@ -799,7 +799,7 @@
>                          buf[i++] =3D vb->vb_rows[r][c];
>=20
>                  /* For all rows, but the last one. */
> -               if (r !=3D e.tp_row) {
> +               if (r !=3D e.tp_row || mark =3D=3D VTB_MARK_ROW) {
>                          /* Trim trailing word separators, if any. */
>                          for (; i !=3D j; i--) {
>                                  if (!tchar_is_word_separator(buf[i - 1])=
)
> --------------------
>=20
> --- sys/dev/vt/vt_core.c.orig   2022-08-02 08:43:15.436415000 -0300
> +++ sys/dev/vt/vt_core.c        2022-08-02 08:43:49.120096000 -0300
> @@ -2287,7 +2287,7 @@
>                          VD_PASTEBUFSZ(vd) =3D len;
>                  }
>                  /* Request copy/paste buffer data, no more than `len' */
> -               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len);
> +               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len,
> + mark);
>=20
>                  VD_PASTEBUFLEN(vd) =3D len;
>=20
> ---------------------
>=20
> --- sys/dev/vt/vt.h.orig        2022-08-02 08:41:23.888584000 -0300
> +++ sys/dev/vt/vt.h     2022-08-02 08:41:54.504309000 -0300
> @@ -238,7 +238,7 @@
>   #ifndef SC_NO_CUTPASTE
>   int vtbuf_set_mark(struct vt_buf *vb, int type, int col, int row);
>   int vtbuf_get_marked_len(struct vt_buf *vb); -void
> vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz);
> +void vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz,
> +int
> mark);
>   #endif
>=20
>   #define        VTB_MARK_NONE           0
> --------------------------

--_003_CP6P284MB190086D2AD26A14E0C5DA002CB9F9CP6P284MB1900BRAP_
Content-Type: application/octet-stream; name="vt.h.diff"
Content-Description: vt.h.diff
Content-Disposition: attachment; filename="vt.h.diff"; size=478;
	creation-date="Thu, 04 Aug 2022 14:02:00 GMT";
	modification-date="Thu, 04 Aug 2022 14:04:26 GMT"
Content-Transfer-Encoding: base64

LS0tIHN5cy9kZXYvdnQvdnQuaC5vcmlnCTIwMjItMDgtMDIgMDg6NDE6MjMuODg4NTg0MDAwIC0w
MzAwDQorKysgc3lzL2Rldi92dC92dC5oCTIwMjItMDgtMDIgMDg6NDE6NTQuNTA0MzA5MDAwIC0w
MzAwDQpAQCAtMjM4LDcgKzIzOCw3IEBADQogI2lmbmRlZiBTQ19OT19DVVRQQVNURQ0KIGludCB2
dGJ1Zl9zZXRfbWFyayhzdHJ1Y3QgdnRfYnVmICp2YiwgaW50IHR5cGUsIGludCBjb2wsIGludCBy
b3cpOw0KIGludCB2dGJ1Zl9nZXRfbWFya2VkX2xlbihzdHJ1Y3QgdnRfYnVmICp2Yik7DQotdm9p
ZCB2dGJ1Zl9leHRyYWN0X21hcmtlZChzdHJ1Y3QgdnRfYnVmICp2YiwgdGVybV9jaGFyX3QgKmJ1
ZiwgaW50IHN6KTsNCit2b2lkIHZ0YnVmX2V4dHJhY3RfbWFya2VkKHN0cnVjdCB2dF9idWYgKnZi
LCB0ZXJtX2NoYXJfdCAqYnVmLCBpbnQgc3osIGludCBtYXJrKTsNCiAjZW5kaWYNCiANCiAjZGVm
aW5lCVZUQl9NQVJLX05PTkUJCTANCg==

--_003_CP6P284MB190086D2AD26A14E0C5DA002CB9F9CP6P284MB1900BRAP_
Content-Type: application/octet-stream; name="vt_core.diff"
Content-Description: vt_core.diff
Content-Disposition: attachment; filename="vt_core.diff"; size=413;
	creation-date="Thu, 04 Aug 2022 14:02:00 GMT";
	modification-date="Thu, 04 Aug 2022 14:04:26 GMT"
Content-Transfer-Encoding: base64

LS0tIHN5cy9kZXYvdnQvdnRfY29yZS5jLm9yaWcJMjAyMi0wOC0wMiAwODo0MzoxNS40MzY0MTUw
MDAgLTAzMDANCisrKyBzeXMvZGV2L3Z0L3Z0X2NvcmUuYwkyMDIyLTA4LTAyIDA4OjQzOjQ5LjEy
MDA5NjAwMCAtMDMwMA0KQEAgLTIyODcsNyArMjI4Nyw3IEBADQogCQkJVkRfUEFTVEVCVUZTWih2
ZCkgPSBsZW47DQogCQl9DQogCQkvKiBSZXF1ZXN0IGNvcHkvcGFzdGUgYnVmZmVyIGRhdGEsIG5v
IG1vcmUgdGhhbiBgbGVuJyAqLw0KLQkJdnRidWZfZXh0cmFjdF9tYXJrZWQoJnZ3LT52d19idWYs
IFZEX1BBU1RFQlVGKHZkKSwgbGVuKTsNCisJCXZ0YnVmX2V4dHJhY3RfbWFya2VkKCZ2dy0+dndf
YnVmLCBWRF9QQVNURUJVRih2ZCksIGxlbiwgbWFyayk7DQogDQogCQlWRF9QQVNURUJVRkxFTih2
ZCkgPSBsZW47DQogDQo=

--_003_CP6P284MB190086D2AD26A14E0C5DA002CB9F9CP6P284MB1900BRAP_--

From nobody Thu Aug  4 14:12:28 2022
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 4Lz9fd30fMz4Xx1l
	for ; Thu,  4 Aug 2022 14:12:41 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Lz9fc4vKMz3CNP
	for ; Thu,  4 Aug 2022 14:12:40 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x929.google.com with SMTP id z5so4331988uav.0
        for ; Thu, 04 Aug 2022 07:12:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=/ao4SX/JZprj1fyiTz0RI+wL0oJ75ElAnKcDj49PjNg=;
        b=0lOBIzHMiUlz2Utx5ThZiKqJAaTpgFQN3If4DGVTRhmH9Hx2Umdk0ndr0LxXUBrhiX
         R9+ju0QNWAIeqZKYY7ASAoknHd7A8AYXG1UNtX+be0QcPSXDCm/q7aeQA9iMh9rqQ/Gx
         u2dsbFoYo1UrJKmXOHQsR5LUQEkpjmV7MM4hWnOPNEvVerFcY79hLXTomBqPiJfp04Kg
         0VbaRuQ+bpJiFpmXIbx1iVo/QT4dEFTTYXx0y3SB1f734QZCmxRrJPGhGZRAf/QXKNU0
         1CWEUHdJ40kyhDs9BxpHJ59FnjyREFxFuXAUBVOY5OCiiFYhf/3l/DRo5fYVLi4us85g
         aT5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=/ao4SX/JZprj1fyiTz0RI+wL0oJ75ElAnKcDj49PjNg=;
        b=ruMC/PQiJGfdP55davshqaRCFy2jvM0clFf+CRebpFldbe+Qr0W8tFM/39+JiTyb9S
         nTjUeMwj3aSql68YpCll7RHcChkTzNSTfcjEJ0cfThNh54PZk8dAXLKlG8KHAMJuQX8r
         93fPGohj+5zPUufifGC7fHoTYqe0LZ+9bTUQ/HuOD74LurB9Ax8JkZ4AGRUywWWDaFwR
         ssEihES26mJoqsJBmR3DAKoX2HZOP1qIokmwLsxPTNybI6DGRISekVYv8tVfU+mb6dEC
         cfebcRMMd7X+Uy/S4hbxdT1LCjknhzHytmORQlzbY2+yYsvSbVDPsb8W/4cUO11mGsHp
         fDNQ==
X-Gm-Message-State: ACgBeo1mLMF/n6x1gWjeu5Mrg8kUr9ejnmc24GsaWpXRYwa/m4T4iAU4
	1VH5Fe7UnyAuVe6SEPc0yvI0rbYQX/iFaFlEk51P/g==
X-Google-Smtp-Source: AA6agR6GO+Qp/orCNetvJWE6efAgDpQGec0EISkKUO+V92QY2JgTMVbEfAXDhPt3aRKdhx3ZglKg2kAF3Y1NATUNDvE=
X-Received: by 2002:ab0:7341:0:b0:382:30b9:be20 with SMTP id
 k1-20020ab07341000000b0038230b9be20mr940679uap.95.1659622359785; Thu, 04 Aug
 2022 07:12:39 -0700 (PDT)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
  
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org> 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
  
 
In-Reply-To: 
From: Warner Losh 
Date: Thu, 4 Aug 2022 08:12:28 -0600
Message-ID: 
Subject: Re: vt newcons 3 clicks mouse paste issue FIXED
To: Ivan Quitschal 
Cc: Hans Petter Selasky , 
	"freebsd-current@freebsd.org" 
Content-Type: multipart/alternative; boundary="00000000000037742205e56af1ac"
X-Rspamd-Queue-Id: 4Lz9fc4vKMz3CNP
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=0lOBIzHM;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::929) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[hotmail.com];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::929:from];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	RCPT_COUNT_THREE(0.00)[3];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000037742205e56af1ac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 4, 2022 at 8:04 AM Ivan Quitschal  wrote:

> Hi Hans
>
> D36042 created
> How can I include more patch files in the same defect number? D36042
> https://reviews.freebsd.org/D36042
>
> Its missing the vt.h.diff and vt_core.diff
> Both attached
>
> Should i have put all three in the raw patch creation combo box when I wa=
s
> creating the defect?
> Sorry my dumbness  , never used that phabricator
>

Generate the diff with 'git diff -U99999' to pick up all the changes at
once and to give reviewers
enough context. Either don't specify any files, or specify all the ones in
the change (depending
on the state of your tree). Upload that diff. you can use the web interface
to 'update' the diff to
include everything, no need to make a new one.

Warner


> --tzk
>
>
>
>
>
> > -----Mensagem original-----
> > De: Ivan Quitschal 
> > Enviada em: ter=C3=A7a-feira, 2 de agosto de 2022 09:34
> > Para: Hans Petter Selasky 
> > Cc: Tomoaki AOKI ; Ivan Quitschal
> > ; freebsd-current@freebsd.org; Kurt Jaeger
> > 
> > Assunto: vt newcons 3 clicks mouse paste issue FIXED
> >
> >
> > Hi guys
> >
> > Currently , if you click 3 times in order to select the entire row, its
> just not
> > working as it should.
> > i fixed that please find below and attached the patches
> >
> > With this change now we can do a 3 clicks and paste , i dont know, in
> some
> > command, and it will be executed just fine, like it was in syscons, and
> still is in
> > xterm/ linux etc
> >
> > now if the event is a 3 mouse clickss select, the space trim is made on
> the right
> > and an  is included
> >
> > thanks
> >
> > --tzk
> >
> >
> > --------------------
> > --- sys/dev/vt/vt_buf.c.orig    2022-08-02 08:44:27.229782000 -0300
> > +++ sys/dev/vt/vt_buf.c 2022-08-02 08:45:02.703697000 -0300
> > @@ -771,7 +771,7 @@
> >   }
> >
> >   void
> > -vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz)
> > +vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz, int
> > +mark)
> >   {
> >          int i, j, r, c, cs, ce;
> >          term_pos_t s, e;
> > @@ -799,7 +799,7 @@
> >                          buf[i++] =3D vb->vb_rows[r][c];
> >
> >                  /* For all rows, but the last one. */
> > -               if (r !=3D e.tp_row) {
> > +               if (r !=3D e.tp_row || mark =3D=3D VTB_MARK_ROW) {
> >                          /* Trim trailing word separators, if any. */
> >                          for (; i !=3D j; i--) {
> >                                  if (!tchar_is_word_separator(buf[i -
> 1]))
> > --------------------
> >
> > --- sys/dev/vt/vt_core.c.orig   2022-08-02 08:43:15.436415000 -0300
> > +++ sys/dev/vt/vt_core.c        2022-08-02 08:43:49.120096000 -0300
> > @@ -2287,7 +2287,7 @@
> >                          VD_PASTEBUFSZ(vd) =3D len;
> >                  }
> >                  /* Request copy/paste buffer data, no more than `len' =
*/
> > -               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len)=
;
> > +               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len,
> > + mark);
> >
> >                  VD_PASTEBUFLEN(vd) =3D len;
> >
> > ---------------------
> >
> > --- sys/dev/vt/vt.h.orig        2022-08-02 08:41:23.888584000 -0300
> > +++ sys/dev/vt/vt.h     2022-08-02 08:41:54.504309000 -0300
> > @@ -238,7 +238,7 @@
> >   #ifndef SC_NO_CUTPASTE
> >   int vtbuf_set_mark(struct vt_buf *vb, int type, int col, int row);
> >   int vtbuf_get_marked_len(struct vt_buf *vb); -void
> > vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz);
> > +void vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz,
> > +int
> > mark);
> >   #endif
> >
> >   #define        VTB_MARK_NONE           0
> > --------------------------
>

--00000000000037742205e56af1ac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Aug 4, 2022 at 8:04 AM Ivan Q=
uitschal <tezeka@hotmail.com&g=
t; wrote:
Hi Han=
s



D36042 created

How can I include more patch files in the same defect number? D36042

https://reviews.freebsd.org/D36042



Its missing the vt.h.diff and vt_core.diff

Both attached



Should i have put all three in the raw patch creation combo box when I was =
creating the defect?

Sorry my dumbness=C2=A0 , never used that phabricator
=

Generate the diff with 'git diff -U99999' to pick up=
 all the changes at once and to give reviewers
enough context. Ei=
ther don't specify any files, or specify all the ones in the change (de=
pending
on the state of your tree). Upload that diff. you can use=
 the web interface to 'update' the diff to
include everyt=
hing, no need to make a new one.

Warner
=
=C2=A0

--tzk











> -----Mensagem original-----

> De: Ivan Quitschal <tezeka@hotmail.com>

> Enviada em: ter=C3=A7a-feira, 2 de agosto de 2022 09:34

> Para: Hans Petter Selasky <hps@selasky.org>

> Cc: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>; Ivan Quitschal

> <tezeka@hot=
mail.com>; freebsd-current@freebsd.org; Kurt Jaeger

> <pi@freebsd.org=
>

> Assunto: vt newcons 3 clicks mouse paste issue FIXED

> 

> 

> Hi guys

> 

> Currently , if you click 3 times in order to select the entire row, it=
s just not

> working as it should.

> i fixed that please find below and attached the patches

> 

> With this change now we can do a 3 clicks and paste , i dont know, in =
some

> command, and it will be executed just fine, like it was in syscons, an=
d still is in

> xterm/ linux etc

> 

> now if the event is a 3 mouse clickss select, the space trim is made o=
n the right

> and an <enter> is included

> 

> thanks

> 

> --tzk

> 

> 

> --------------------

> --- sys/dev/vt/vt_buf.c.orig=C2=A0 =C2=A0 2022-08-02 08:44:27.22978200=
0 -0300

> +++ sys/dev/vt/vt_buf.c 2022-08-02 08:45:02.703697000 -0300

> @@ -771,7 +771,7 @@

>=C2=A0 =C2=A0}

> 

>=C2=A0 =C2=A0void

> -vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz)

> +vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz, int=


> +mark)

>=C2=A0 =C2=A0{

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int i, j, r, c, cs, ce;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 term_pos_t s, e;

> @@ -799,7 +799,7 @@

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 buf[i++] =3D vb->vb_rows[r][c];

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* For a=
ll rows, but the last one. */

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (r !=3D e.t=
p_row) {

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (r !=3D e.t=
p_row || mark =3D=3D VTB_MARK_ROW) {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 /* Trim trailing word separators, if any. */

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 for (; i !=3D j; i--) {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!tchar_is_word_separat=
or(buf[i - 1]))

> --------------------

> 

> --- sys/dev/vt/vt_core.c.orig=C2=A0 =C2=A02022-08-02 08:43:15.43641500=
0 -0300

> +++ sys/dev/vt/vt_core.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 2022-08-02 08:43:4=
9.120096000 -0300

> @@ -2287,7 +2287,7 @@

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 VD_PASTEBUFSZ(vd) =3D len;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Reque=
st copy/paste buffer data, no more than `len' */

> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vtbuf_extract_=
marked(&vw->vw_buf, VD_PASTEBUF(vd), len);

> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vtbuf_extract_=
marked(&vw->vw_buf, VD_PASTEBUF(vd), len,

> + mark);

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VD_PASTE=
BUFLEN(vd) =3D len;

> 

> ---------------------

> 

> --- sys/dev/vt/vt.h.orig=C2=A0 =C2=A0 =C2=A0 =C2=A0 2022-08-02 08:41:2=
3.888584000 -0300

> +++ sys/dev/vt/vt.h=C2=A0 =C2=A0 =C2=A02022-08-02 08:41:54.504309000 -=
0300

> @@ -238,7 +238,7 @@

>=C2=A0 =C2=A0#ifndef SC_NO_CUTPASTE

>=C2=A0 =C2=A0int vtbuf_set_mark(struct vt_buf *vb, int type, int col, i=
nt row);

>=C2=A0 =C2=A0int vtbuf_get_marked_len(struct vt_buf *vb); -void

> vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz);

> +void vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz=
,

> +int

> mark);

>=C2=A0 =C2=A0#endif

> 

>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 VTB_MARK_NONE=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00

> --------------------------




--00000000000037742205e56af1ac--

From nobody Thu Aug  4 14:32:07 2022
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 4LzB575cB1z4Y06F
	for ; Thu,  4 Aug 2022 14:32:11 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2067.outbound.protection.outlook.com [40.92.97.67])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LzB566Pcyz3GSc
	for ; Thu,  4 Aug 2022 14:32:10 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=NUjiEdvRJooiNpEhOB1qce+snD7tmshStLTE8mEr7Yk8p6iODQjlQSzp/67WRiV7CcykBqcSAGZ9GMeIV5XjmqQdbJeCB+lqSP+1vteworv2PhZARaCWfWvV3kW4icfH71M+A2NhcFeM8iI7z4oEk9SnMlpvubtEsBxAngCmSloCNXRRdCyihlmEoFm1YxiRgK1ngktx0BuSAmfzWBIStymdabHkDPI2VAxTik1JKKj3iyCNeyQe2/inOXXrQ06WVwNQQlpQt04iHIYWgBmhNYVNLQxD8+xIrJdIV1XVWV7AcZDvmR1v5ZROjFic6Eekj7g3ICc55QGRYWOy/dnCUQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=GlAU4YTnqEMkvB8ME0y6HkWMq5bnqa2gG8czjhPeZfI=;
 b=NZFKEYqmgNchHeBITP07T9kL1llXs9neTYIYXC5b39qEEaDbK/wnSv0+rO4liZP9XMKkVdlXa+JME/R5ODh9KO+r8H6XkeVIofeuLvs7U3U1wmqZgCuOvhvvDJp84ZdrmjgDvelptrtCl0sMiG5hJHvMG0eEIsJ1OwEtcz9KIgJBt+KU8k2eoila5LnVNOL9dKYglWkkDoCmI4IcEU+UKI4eyJknIwO+tSiDWfZK1uw7WS2IqhMUoYd62Mcl+qDaudYc54LJhIuIm5SR3glEJDsp4TM/BitzR6uweiwiE9wyyR8E37CwPXDB7YIfGt9rgAoIEA3MGjVkAhRril7Ylg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=GlAU4YTnqEMkvB8ME0y6HkWMq5bnqa2gG8czjhPeZfI=;
 b=pXto6hKM0YkYyNdhYNqcdC9e+alfEV4BkksZM68negrpOwSXwwG9B/R593/BZkbQacrlvqgH++sHgAR0HM9cNxN4XSUByFlWEusD7VwJc0T/VmzPxzlJHrwiLyKrgGPM/eHDtttPpR8UUT0zfUpYxNU+FPtHYarnCojXUFHMn6XYlLLa8Zdb2SOGMxT1DbCPwEWb5UAaNIEfA/03UldMGloIPDhiXRcqOyRfeLXIHajyw4EnTvk1UvDPmHeAiTtyf1HEFGWmnoAs/wh4YYmhBEySewj++6b3GhdYxMcCp+mISFb3YR2ION2GAN1lqHvzpE+QqDtLYZtzxB9kHL2pIA==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by RIZP284MB0987.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:57::8) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5504.14; Thu, 4 Aug 2022 14:32:07 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2%7]) with mapi id 15.20.5482.016; Thu, 4 Aug 2022
 14:32:07 +0000
From: Ivan Quitschal 
To: Warner Losh , Hans Petter Selasky 
CC: "freebsd-current@freebsd.org" 
Subject: RES: vt newcons 3 clicks mouse paste issue FIXED
Thread-Topic: vt newcons 3 clicks mouse paste issue FIXED
Thread-Index: AQHYpmw1CB+cesrdUEGiwPuu2IoeEK2eyDAAgAADbACAAAOCAA==
Date: Thu, 4 Aug 2022 14:32:07 +0000
Message-ID:
 
References:
 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
 
 
In-Reply-To:
 
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [+JCB7teG9cozTYlu1VC1x/OxuuzE1cCEURNuG5A1GvEp9usOC3ydsvXf5uOVtBLF]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f15c40ae-6545-4c14-6434-08da76261bb9
x-ms-traffictypediagnostic: RIZP284MB0987:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 6LmboRYZEIquwi5jAmcHpj+3SU9/UT+pucExJ9o0awaU+LaBSVGEb0ZOwKMuqnSIdIeRo9AhhYbRNVs7HMEEwphj2Mam4XWHDtML3odmcw9cKQFtpIJipJxtX2PX1MID/fnOh2wEXpJWdpvgyKhMgwujd4+vSK+Mmdp9fj3gEfgS0R1liK7pyqTNAgyQXPm7qkMxLP1kaYmEq38a482xsrPE0Ke9yA13ZLRQZiQUqEeWuYpihXvDYo5nbY+6JP34Y1yL0FxNWhA3KNx6kD3LOhEV4HXFymTfJk5UGcP+XujoOd2lzGg+3VjilAXhlyemjIKQIuama7ESZCf5MkeZ1ITukCy0houOLT9uAieyk97Qj9T0NyLIoQ4o29k04ZMsz/2RiMi3K3FbapCNLNCKmO2r00AN1ESF/5/0qVKn+vFfMOkv7iz6XhEACVkCJqw/a4Gv2j29qB4gGe03Qp1DL22JL2JOc5VV/BkvGxqrQ8AVerXYZ595g8OsnxC16ouhEohGivQyEibsVubkrXbW51eDomee6xTnyIeTwMrVq0HlVv77xINf2evyWL0Zvfy7Fq2V7M/YJxBYOJzIPvT1EKiSYo7JeGoo8jrC1BZDSDfwDEp+WD/VjWLts527vGrl
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?j3qAyFAa2K6kKp14vrVqinfs/b1HDELFzsluOCG7IWX9py9LNaf1tOy315?=
 =?iso-8859-1?Q?OeyCNIo8yAS0FUR0AaA7ntMQqMOM+dq1KQt9ELtmOh/1xGbUK4G4Y/vwnH?=
 =?iso-8859-1?Q?VCY/dhavp6fcBt1EvRczXP86zj0IYMwubtHcZYjhbdsjDdURZ5rcHf/URw?=
 =?iso-8859-1?Q?LrxtPirBP6yfWkFTymMC3WTh36DX5e015DHxwq0aEndx1Tp9CBQpjOj6v/?=
 =?iso-8859-1?Q?x0nPh9pAl38TcUTa+o37OZ7CBKoO2KZTDlyq4yKTG4DmewDtWdlV3lvVe6?=
 =?iso-8859-1?Q?1LTVsFhFmWEA+daNeytbp3OgxLRbFu1tV0NPJVcUtOMeQOR/8E0cKmBFPk?=
 =?iso-8859-1?Q?VHPZGAhaB69TR7u3310H6ozzxFiKUmmF/VJ9u9xJU0Xq4sOhu5rFaZ66j1?=
 =?iso-8859-1?Q?7IR0IeyU13/4QrxSdp6YQ1RfTJI3T9y1sTrXOSTWGeIZ2lKNuE6UXTOdjC?=
 =?iso-8859-1?Q?ExO4oMqazPx5T1Qo9+U0VHd5L0nsupS0QC+ojL5bk9OH37w6kfRuiUzz0P?=
 =?iso-8859-1?Q?jv+jlUuTSEHo/vgx43WiCutoB98XOejuhi0kwj86iEXqbdlOU5SXzvN1rT?=
 =?iso-8859-1?Q?8JZWMXAFPM5VEvXuxtHgdyimycWjeIvT5Uz3PpTAoXuOIliA0fqkXAvI4F?=
 =?iso-8859-1?Q?jhMIIFWFz4tPW9dZxITJ7CcYbyxB9oV9kFegqmlUYLtR0PYdxqu+/+eqmF?=
 =?iso-8859-1?Q?99kstiv+1IbhcjkZ6M93oQoQxII/G9YuMWVrtFLPbB7etVlIo60hFDQ9nE?=
 =?iso-8859-1?Q?drQMRwlKsW54dZZySTON2kIx0kNwNYvLyL1YmkKpR7RYt9vZPPEyld+xMe?=
 =?iso-8859-1?Q?NegJZlXh/G1pvhvP6c9UqNnLyGRRsc9yiC7zRV4KLGjLZYx3u5mduiaw0S?=
 =?iso-8859-1?Q?5DRHmNs7NoW6K97ciPvaja5BRj08GkOWnXNIwMKOiIntYCLh+RNAqgoaDI?=
 =?iso-8859-1?Q?5KTCvx5p5A5Ct8wmVOrgeEYo4AxdiTTrOplUuPg9PUP+CP5QTpGhWWX5hx?=
 =?iso-8859-1?Q?jeBRBv/RO1/E6YeHO5rgWKcfL6OLJf38IpH9QOMk0YASXPxmcFP7uzHvs1?=
 =?iso-8859-1?Q?sC28yng2QcKVSswYYRuA01LhAKnHhbZWO6gxR1s0HNv4fUVLg3gy8yJRki?=
 =?iso-8859-1?Q?j5qNulqjMneSTD4oPMm2KrAgaXPxLniCmnA1RJ/nRCrvGzO71wiJbHj8or?=
 =?iso-8859-1?Q?lVNVNvY0pnKJF44MdpXRsUQJeQ3ua6KDbqKH55S5l6x7mpjQOcCWSG24JW?=
 =?iso-8859-1?Q?n2qS1J+nBZUbecL4Ap4n07PFQtQ5xNtrrELDNt8OjAKUeOdCWVw8UfK5Tc?=
 =?iso-8859-1?Q?oQPFcHdwuZwc7K29Qu3k9Mp6Di81KXzSWBKXH4sIqSqQ8CKGfqAHFPDlAn?=
 =?iso-8859-1?Q?04x/UChJtD?=
Content-Type: multipart/alternative;
	boundary="_000_CP6P284MB1900CDE6A053535D5CB6C4F8CB9F9CP6P284MB1900BRAP_"
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-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: f15c40ae-6545-4c14-6434-08da76261bb9
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2022 14:32:07.2003
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: RIZP284MB0987
X-Rspamd-Queue-Id: 4LzB566Pcyz3GSc
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=pXto6hKM;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.67 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-2.21 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	URI_COUNT_ODD(1.00)[9];
	NEURAL_HAM_SHORT(-0.98)[-0.976];
	NEURAL_HAM_LONG(-0.92)[-0.918];
	NEURAL_SPAM_MEDIUM(0.68)[0.684];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.67:from];
	PHISHED_WHITELISTED(0.00)[freebsd.org->nam12.safelinks.protection.outlook.com];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--_000_CP6P284MB1900CDE6A053535D5CB6C4F8CB9F9CP6P284MB1900BRAP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thank you Warner

Done

https://reviews.freebsd.org/D36042
D36042

Just to make clear. I'll put here what I wrote in the comments


we have two changes in this patch.

first one is regarding the 3 clicks paste.
vtbuf_extract_marked() gains a new arg
int mark

the second change is not much of a change because i had to mess up the
"case VT_MOUSE_EXTENDBUTTON:"

this change is regarding the highlight mark that doesn't go away from the s=
creen after you paste it. the highlight mark stays forever
the below solves the problem

I've replaced
mark =3D VTB_MARK_EXTEND;
with
mark =3D VTB_MARK_START

also included  "mark =3D VTB_MARK_START" and removed the return from
               case VT_MOUSE_PASTEBUTTON:

first change is 100% ok (the 3click pasting)
second one needs an overlook on where to put this "VTB_MARK_START" without =
messing up the switch option "VT_MOUSE_EXTENDBUTTON"

thanks

--tzk


De: Warner Losh 
Enviada em: quinta-feira, 4 de agosto de 2022 11:12
Para: Ivan Quitschal 
Cc: Hans Petter Selasky ; freebsd-current@freebsd.org
Assunto: Re: vt newcons 3 clicks mouse paste issue FIXED



On Thu, Aug 4, 2022 at 8:04 AM Ivan Quitschal > wrote:
Hi Hans

D36042 created
How can I include more patch files in the same defect number? D36042
https://reviews.freebsd.org/D36042

Its missing the vt.h.diff and vt_core.diff
Both attached

Should i have put all three in the raw patch creation combo box when I was =
creating the defect?
Sorry my dumbness  , never used that phabricator

Generate the diff with 'git diff -U99999' to pick up all the changes at onc=
e and to give reviewers
enough context. Either don't specify any files, or specify all the ones in =
the change (depending
on the state of your tree). Upload that diff. you can use the web interface=
 to 'update' the diff to
include everything, no need to make a new one.

Warner

--tzk





> -----Mensagem original-----
> De: Ivan Quitschal >
> Enviada em: ter=E7a-feira, 2 de agosto de 2022 09:34
> Para: Hans Petter Selasky >
> Cc: Tomoaki AOKI >; Ivan Quitschal
> >; freebsd-current@freebsd.=
org; Kurt Jaeger
> >
> Assunto: vt newcons 3 clicks mouse paste issue FIXED
>
>
> Hi guys
>
> Currently , if you click 3 times in order to select the entire row, its j=
ust not
> working as it should.
> i fixed that please find below and attached the patches
>
> With this change now we can do a 3 clicks and paste , i dont know, in som=
e
> command, and it will be executed just fine, like it was in syscons, and s=
till is in
> xterm/ linux etc
>
> now if the event is a 3 mouse clickss select, the space trim is made on t=
he right
> and an  is included
>
> thanks
>
> --tzk
>
>
> --------------------
> --- sys/dev/vt/vt_buf.c.orig    2022-08-02 08:44:27.229782000 -0300
> +++ sys/dev/vt/vt_buf.c 2022-08-02 08:45:02.703697000 -0300
> @@ -771,7 +771,7 @@
>   }
>
>   void
> -vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz)
> +vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz, int
> +mark)
>   {
>          int i, j, r, c, cs, ce;
>          term_pos_t s, e;
> @@ -799,7 +799,7 @@
>                          buf[i++] =3D vb->vb_rows[r][c];
>
>                  /* For all rows, but the last one. */
> -               if (r !=3D e.tp_row) {
> +               if (r !=3D e.tp_row || mark =3D=3D VTB_MARK_ROW) {
>                          /* Trim trailing word separators, if any. */
>                          for (; i !=3D j; i--) {
>                                  if (!tchar_is_word_separator(buf[i - 1])=
)
> --------------------
>
> --- sys/dev/vt/vt_core.c.orig   2022-08-02 08:43:15.436415000 -0300
> +++ sys/dev/vt/vt_core.c        2022-08-02 08:43:49.120096000 -0300
> @@ -2287,7 +2287,7 @@
>                          VD_PASTEBUFSZ(vd) =3D len;
>                  }
>                  /* Request copy/paste buffer data, no more than `len' */
> -               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len);
> +               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), len,
> + mark);
>
>                  VD_PASTEBUFLEN(vd) =3D len;
>
> ---------------------
>
> --- sys/dev/vt/vt.h.orig        2022-08-02 08:41:23.888584000 -0300
> +++ sys/dev/vt/vt.h     2022-08-02 08:41:54.504309000 -0300
> @@ -238,7 +238,7 @@
>   #ifndef SC_NO_CUTPASTE
>   int vtbuf_set_mark(struct vt_buf *vb, int type, int col, int row);
>   int vtbuf_get_marked_len(struct vt_buf *vb); -void
> vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz);
> +void vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz,
> +int
> mark);
>   #endif
>
>   #define        VTB_MARK_NONE           0
> --------------------------

--_000_CP6P284MB1900CDE6A053535D5CB6C4F8CB9F9CP6P284MB1900BRAP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Thank you=
 Warner


&nbs=
p;


Done=



&nbs=
p;


https://reviews.freebsd.org/D36042<=
/a>


D36042


 


Just to make clear. I’ll =
put here what I wrote in the comments


 



we have two changes in this patch.<=
/span>



first one is regarding the 3 clicks paste.

vtbuf_extract_marked() gains a new arg

int mark



the second change is not much of a change beca=
use i had to mess up the

“case VT_MOUSE_EXTENDBUTTON:”



this change is regarding the highlight mark th=
at doesn’t go away from the screen after you paste it. the highlight =
mark stays forever

the below solves the problem



I’ve replaced

mark =3D VTB_MARK_EXTEND;

with

mark =3D VTB_MARK_START


 


also included  “mark =3D VTB_MARK_START”
and removed the return from 


     &=
nbsp;         case VT_MOUSE_PASTEBU=
TTON:


 


first change is 100% ok (the 3click pasting)


second one needs an overlook on where to put this “VTB_MARK_START” without messing up
 the switch option “VT_MOUSE_EXTENDBUTTON”

 


thanks


 


--tzk=



 


 








De: Warner Losh <imp@bsdimp.com> 

Enviada em: quinta-feira, 4 de agosto de 2022 11:12

Para: Ivan Quitschal <tezeka@hotmail.com>

Cc: Hans Petter Selasky <hps@selasky.org>; freebsd-current@fre=
ebsd.org

Assunto: Re: vt newcons 3 clicks mouse paste issue FIXED<=
/p>





 






 




 







Hi Hans



D36042 created

How can I include more patch files in the same defect number? D36042

https://reviews.fre=
ebsd.org/D36042



Its missing the vt.h.diff and vt_core.diff

Both attached



Should i have put all three in the raw patch creation combo box when I was =
creating the defect?

Sorry my dumbness  , never used that phabricator






 






Generate the diff with 'git diff -U99999' to pick up=
 all the changes at once and to give reviewers






enough context. Either don't specify any files, or s=
pecify all the ones in the change (depending






on the state of your tree). Upload that diff. you ca=
n use the web interface to 'update' the diff to






include everything, no need to make a new one.<=
/o:p>






 






Warner






 






--tzk











> -----Mensagem original-----

> De: Ivan Quitschal <tezeka@hotmail.com>

> Enviada em: ter=E7a-feira, 2 de agosto de 2022 09:34

> Para: Hans Petter Selasky <hps@selasky.org>

> Cc: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>; Ivan Quitschal

> <tezeka@hot=
mail.com>; 
freebsd-current@freebsd.org; Kurt Jaeger

> <pi@freebsd.org=
>

> Assunto: vt newcons 3 clicks mouse paste issue FIXED

> 

> 

> Hi guys

> 

> Currently , if you click 3 times in order to select the entire row, it=
s just not

> working as it should.

> i fixed that please find below and attached the patches

> 

> With this change now we can do a 3 clicks and paste , i dont know, in =
some

> command, and it will be executed just fine, like it was in syscons, an=
d still is in

> xterm/ linux etc

> 

> now if the event is a 3 mouse clickss select, the space trim is made o=
n the right

> and an <enter> is included

> 

> thanks

> 

> --tzk

> 

> 

> --------------------

> --- sys/dev/vt/vt_buf.c.orig    2022-08-02 08:44:27.22978200=
0 -0300

> +++ sys/dev/vt/vt_buf.c 2022-08-02 08:45:02.703697000 -0300

> @@ -771,7 +771,7 @@

>   }

> 

>   void

> -vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz)

> +vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz, int=


> +mark)

>   {

>          int i, j, r, c, cs, ce;

>          term_pos_t s, e;

> @@ -799,7 +799,7 @@

>                    &=
nbsp;     buf[i++] =3D vb->vb_rows[r][c];

> 

>                  /* For a=
ll rows, but the last one. */

> -               if (r !=3D e.t=
p_row) {

> +               if (r !=3D e.t=
p_row || mark =3D=3D VTB_MARK_ROW) {

>                    &=
nbsp;     /* Trim trailing word separators, if any. */

>                    &=
nbsp;     for (; i !=3D j; i--) {

>                    &=
nbsp;             if (!tchar_is_word_separato=
r(buf[i - 1]))

> --------------------

> 

> --- sys/dev/vt/vt_core.c.orig   2022-08-02 08:43:15.43641500=
0 -0300

> +++ sys/dev/vt/vt_core.c        2022-08-02 08:43:4=
9.120096000 -0300

> @@ -2287,7 +2287,7 @@

>                    &=
nbsp;     VD_PASTEBUFSZ(vd) =3D len;

>                  }

>                  /* Reque=
st copy/paste buffer data, no more than `len' */

> -               vtbuf_extract_=
marked(&vw->vw_buf, VD_PASTEBUF(vd), len);

> +               vtbuf_extract_=
marked(&vw->vw_buf, VD_PASTEBUF(vd), len,

> + mark);

> 

>                  VD_PASTE=
BUFLEN(vd) =3D len;

> 

> ---------------------

> 

> --- sys/dev/vt/vt.h.orig        2022-08-02 08:41:2=
3.888584000 -0300

> +++ sys/dev/vt/vt.h     2022-08-02 08:41:54.504309000 -=
0300

> @@ -238,7 +238,7 @@

>   #ifndef SC_NO_CUTPASTE

>   int vtbuf_set_mark(struct vt_buf *vb, int type, int col, i=
nt row);

>   int vtbuf_get_marked_len(struct vt_buf *vb); -void

> vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz);

> +void vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz=
,

> +int

> mark);

>   #endif

> 

>   #define        VTB_MARK_NONE  &nb=
sp;        0

> --------------------------














--_000_CP6P284MB1900CDE6A053535D5CB6C4F8CB9F9CP6P284MB1900BRAP_--

From nobody Thu Aug  4 14:33:05 2022
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 4LzB6J2rFjz4Y0c2
	for ; Thu,  4 Aug 2022 14:33:12 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from pv50p00im-ztdg10021201.me.com (pv50p00im-ztdg10021201.me.com [17.58.6.45])
	(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 4LzB6H4rHlz3HXf
	for ; Thu,  4 Aug 2022 14:33:11 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1659623590; bh=Tqj+VS6gSswcA5kzQ/8r2L76U6TghnOaV3rCUahL650=;
	h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To;
	b=lxRBuhlS6BiUX0ysU4pAMq03oxrUoB93tV21JBs9RdVy5IOLvObrULpw7EThEI1zI
	 1grPGw6M6IC4Oxi9i0iCeySvN/3jC09CYadpX8XVLABFX7KocFval6p4rlM1DQdBf3
	 dYnG5cejgMjo3h+BvKSDyq8wsQytjrXiVTfAEf6vSfilNr7smwIqMQ9alKz30CYXG+
	 67+sHzyl0kZFm8Hh1z2lv2lnbHu5lClvEwbPHtAoR0NXO0rzdVq84Dt4pOX8ClMGEB
	 Wh+5XTlgGV55MVtQSsuBTY/OfqHT2QaMnUrdGAQMYQuq8+Hg28XhjGT9usONKWBLXI
	 TTv4DfpK5k1kA==
Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10])
	by pv50p00im-ztdg10021201.me.com (Postfix) with ESMTPSA id 6989D680664;
	Thu,  4 Aug 2022 14:33:08 +0000 (UTC)
From: Toomas Soome 
Message-Id: 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_45F67029-A3A2-41BC-9F27-53F8BB6CE4C3"
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: RES: vt newcons 3 clicks mouse paste issue FIXED
Date: Thu, 4 Aug 2022 17:33:05 +0300
In-Reply-To: 
Cc: Hans Petter Selasky ,
 "freebsd-current@freebsd.org" 
To: Ivan Quitschal 
References: 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Proofpoint-ORIG-GUID: LCBqtHL3-0vy4dMls2M-dXwUk_-Jt7j3
X-Proofpoint-GUID: LCBqtHL3-0vy4dMls2M-dXwUk_-Jt7j3
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.517,18.0.883,17.11.64.514.0000000_definitions?=
 =?UTF-8?Q?=3D2022-06-21=5F08:2022-06-21=5F01,2022-06-21=5F08,2022-02-23?=
 =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0
 suspectscore=0 mlxscore=0 clxscore=1011 phishscore=0 mlxlogscore=999
 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2206140000 definitions=main-2208040064
X-Rspamd-Queue-Id: 4LzB6H4rHlz3HXf
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=lxRBuhlS;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.45 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-1.32 / 15.00];
	URI_COUNT_ODD(1.00)[9];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine];
	NEURAL_SPAM_MEDIUM(0.28)[0.276];
	R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.45:from];
	FREEFALL_USER(0.00)[tsoome];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[me.com:dkim];
	RWL_MAILSPIKE_POSSIBLE(0.00)[17.58.6.45:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[me.com];
	HAS_WP_URI(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[me.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[hotmail.com];
	FREEMAIL_ENVFROM(0.00)[me.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_45F67029-A3A2-41BC-9F27-53F8BB6CE4C3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 4. Aug 2022, at 17:04, Ivan Quitschal  wrote:
>=20
> Hi Hans
>=20
> D36042 created
> How can I include more patch files in the same defect number? D36042
> https://reviews.freebsd.org/D36042
>=20
> Its missing the vt.h.diff and vt_core.diff
> Both attached
>=20
> Should i have put all three in the raw patch creation combo box when I =
was creating the defect?
> Sorry my dumbness  , never used that phabricator=20
>=20
> --tzk

You may want to check =E2=80=98git arc=E2=80=99 =
(https://freebsdfoundation.org/wp-content/uploads/2021/11/FreeBSD-Code-Rev=
iew-with-git-arc.pdf =
)

rgds,
toomas

>=20
>=20
>=20
>=20
>=20
>> -----Mensagem original-----
>> De: Ivan Quitschal 
>> Enviada em: ter=C3=A7a-feira, 2 de agosto de 2022 09:34
>> Para: Hans Petter Selasky 
>> Cc: Tomoaki AOKI ; Ivan Quitschal
>> ; freebsd-current@freebsd.org; Kurt Jaeger
>> 
>> Assunto: vt newcons 3 clicks mouse paste issue FIXED
>>=20
>>=20
>> Hi guys
>>=20
>> Currently , if you click 3 times in order to select the entire row, =
its just not
>> working as it should.
>> i fixed that please find below and attached the patches
>>=20
>> With this change now we can do a 3 clicks and paste , i dont know, in =
some
>> command, and it will be executed just fine, like it was in syscons, =
and still is in
>> xterm/ linux etc
>>=20
>> now if the event is a 3 mouse clickss select, the space trim is made =
on the right
>> and an  is included
>>=20
>> thanks
>>=20
>> --tzk
>>=20
>>=20
>> --------------------
>> --- sys/dev/vt/vt_buf.c.orig    2022-08-02 08:44:27.229782000 -0300
>> +++ sys/dev/vt/vt_buf.c 2022-08-02 08:45:02.703697000 -0300
>> @@ -771,7 +771,7 @@
>>  }
>>=20
>>  void
>> -vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz)
>> +vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz, =
int
>> +mark)
>>  {
>>         int i, j, r, c, cs, ce;
>>         term_pos_t s, e;
>> @@ -799,7 +799,7 @@
>>                         buf[i++] =3D vb->vb_rows[r][c];
>>=20
>>                 /* For all rows, but the last one. */
>> -               if (r !=3D e.tp_row) {
>> +               if (r !=3D e.tp_row || mark =3D=3D VTB_MARK_ROW) {
>>                         /* Trim trailing word separators, if any. */
>>                         for (; i !=3D j; i--) {
>>                                 if (!tchar_is_word_separator(buf[i - =
1]))
>> --------------------
>>=20
>> --- sys/dev/vt/vt_core.c.orig   2022-08-02 08:43:15.436415000 -0300
>> +++ sys/dev/vt/vt_core.c        2022-08-02 08:43:49.120096000 -0300
>> @@ -2287,7 +2287,7 @@
>>                         VD_PASTEBUFSZ(vd) =3D len;
>>                 }
>>                 /* Request copy/paste buffer data, no more than `len' =
*/
>> -               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), =
len);
>> +               vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), =
len,
>> + mark);
>>=20
>>                 VD_PASTEBUFLEN(vd) =3D len;
>>=20
>> ---------------------
>>=20
>> --- sys/dev/vt/vt.h.orig        2022-08-02 08:41:23.888584000 -0300
>> +++ sys/dev/vt/vt.h     2022-08-02 08:41:54.504309000 -0300
>> @@ -238,7 +238,7 @@
>>  #ifndef SC_NO_CUTPASTE
>>  int vtbuf_set_mark(struct vt_buf *vb, int type, int col, int row);
>>  int vtbuf_get_marked_len(struct vt_buf *vb); -void
>> vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int sz);
>> +void vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int =
sz,
>> +int
>> mark);
>>  #endif
>>=20
>>  #define        VTB_MARK_NONE           0
>> --------------------------
> 


--Apple-Mail=_45F67029-A3A2-41BC-9F27-53F8BB6CE4C3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 4. Aug 2022, at 17:04, Ivan Quitschal <tezeka@hotmail.com> =
wrote:

Hi Hans

D36042 created
How can I include more patch files in the same defect number? =
D36042
https://reviews.freebsd.org/D36042

Its missing the vt.h.diff and vt_core.diff
Both =
attached

Should i have put all three in the =
raw patch creation combo box when I was creating the defect?
Sorry my dumbness  , never used that phabricator 

--tzk


rgds,
toomas





-----Mensagem =
original-----
De: Ivan Quitschal <tezeka@hotmail.com>
Enviada em: =
ter=C3=A7a-feira, 2 de agosto de 2022 09:34
Para: Hans =
Petter Selasky <hps@selasky.org>
Cc: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>; Ivan Quitschal
<tezeka@hotmail.com>; freebsd-current@freebsd.org; Kurt Jaeger
<pi@freebsd.org>
Assunto: vt newcons 3 =
clicks mouse paste issue FIXED


Hi guys

Currently , if you click =
3 times in order to select the entire row, its just not
working as it should.
i fixed that please find =
below and attached the patches

With this =
change now we can do a 3 clicks and paste , i dont know, in some
command, and it will be executed just fine, like it was in =
syscons, and still is in
xterm/ linux etc

now if the event is a 3 mouse clickss select, the space trim =
is made on the right
and an <enter> is included

thanks

--tzk


--------------------
--- sys/dev/vt/vt_buf.c.orig    2022-08-02 =
08:44:27.229782000 -0300
+++ sys/dev/vt/vt_buf.c =
2022-08-02 08:45:02.703697000 -0300
@@ -771,7 +771,7 @@
  }

  void
-vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, =
int sz)
+vtbuf_extract_marked(struct vt_buf *vb, =
term_char_t *buf, int sz, int
+mark)
 =
 {
 =
        int i, j, r, c, cs, =
ce;
 =
        term_pos_t s, e;
@@ -799,7 +799,7 @@
 =
            &n=
bsp;           buf[=
i++] =3D vb->vb_rows[r][c];

 =
            &n=
bsp;   /* For all rows, but the last one. */
- =
            &n=
bsp; if (r !=3D e.tp_row) {
+ =
            &n=
bsp; if (r !=3D e.tp_row || mark =3D=3D VTB_MARK_ROW) {
 =
            &n=
bsp;           /* =
Trim trailing word separators, if any. */
 =
            &n=
bsp;           for =
(; i !=3D j; i--) {
 =
            &n=
bsp;           &nbs=
p;       if =
(!tchar_is_word_separator(buf[i - 1]))
--------------------

--- =
sys/dev/vt/vt_core.c.orig   2022-08-02 08:43:15.436415000 =
-0300
+++ sys/dev/vt/vt_core.c =
       2022-08-02 08:43:49.120096000 =
-0300
@@ -2287,7 +2287,7 @@
 =
            &n=
bsp;           VD_P=
ASTEBUFSZ(vd) =3D len;
 =
            &n=
bsp;   }
 =
            &n=
bsp;   /* Request copy/paste buffer data, no more than =
`len' */
- =
            &n=
bsp; vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), =
len);
+ =
            &n=
bsp; vtbuf_extract_marked(&vw->vw_buf, VD_PASTEBUF(vd), =
len,
+ mark);

 =
            &n=
bsp;   VD_PASTEBUFLEN(vd) =3D len;

---------------------

--- =
sys/dev/vt/vt.h.orig =
       2022-08-02 08:41:23.888584000 =
-0300
+++ sys/dev/vt/vt.h =
    2022-08-02 08:41:54.504309000 -0300
@@ -238,7 +238,7 @@
  #ifndef =
SC_NO_CUTPASTE
  int vtbuf_set_mark(struct vt_buf =
*vb, int type, int col, int row);
  int =
vtbuf_get_marked_len(struct vt_buf *vb); -void
vtbuf_extract_marked(struct vt_buf *vb, term_char_t *buf, int =
sz);
+void vtbuf_extract_marked(struct vt_buf *vb, =
term_char_t *buf, int sz,
+int
mark);
  #endif

  #define =
       VTB_MARK_NONE =
          0
--------------------------
<vt.h.diff><vt_core.diff>

=

--Apple-Mail=_45F67029-A3A2-41BC-9F27-53F8BB6CE4C3--

From nobody Thu Aug  4 14:52:06 2022
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 4LzBXC3vGNz4Y30d
	for ; Thu,  4 Aug 2022 14:52:11 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2056.outbound.protection.outlook.com [40.92.96.56])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4LzBXB27wkz3L9r
	for ; Thu,  4 Aug 2022 14:52:10 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=NIzvKZ73lTiegT7lOpSULJq6kYnLqWDFmmpa3VwwruPEts33APzQgOsv7cbxFhnqTVo2WmMi+YW8rTEZlEiP3PdqbDgzWdhq7O7yMDKoM6PD0nRn3yat/iCYP3tKu4t2sQoJOHKRsTFlGd0e5M5BLqdGUAxr/X1SbQJzXHOHQ/HBpMay4bPhWPm1AxRMDo0Ug3/LEgYAWQVOJTlb/uUOaC2TmSfmg/gXC2clQQKQQj8E5U/+4ETvUxU6TRrH7wOJsbpkEbl51iElYJ87Ekqo5kwkXVcVtuqMVvzoDQXdeQUyXumq7IV54OBW8a+VxWEzt3OgGEPvMWmH2vI5YCkbkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=jVQUMn/BRODwOHx4ijhN6tc7tZ6nOzVxUWBRGSJovJk=;
 b=ii/DOa9EzqIRctz6kjaFWrFytcjMzB7/HSrDq7juPwRbwzXccE4myS3dro9bi6O3kXyGD/bbhFmOShO6zuwe1onomu0gQwVGhceVaVSKgE2e9Cc2kuAfJhDWD94PRnOaXEHZlfh2orJZAXJQ4rCAkWtp9hkJ4fNL26k07fGv5xNjPOnqiO7ULucis+3yyqP3tSk+N9SoO4irMtFz4FVaELRVt4JTZGUpGdhQzEik7M8VU3SmmKDowzc42JOEBmeFgxSJ4gsCPdULCu7bANlKdEgc4KX9kNlFKmHnR3wvKQG9rS3XGkPa2h8X2ZKvRQo+ZfpUPOUq+gJ4v8cxx9cUcg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=jVQUMn/BRODwOHx4ijhN6tc7tZ6nOzVxUWBRGSJovJk=;
 b=CE6W3a+hD1i7iB0rANDs74s6rXt+1GK0yIwXNBXokpG2f8nWPEerxF/j7uvFzbyKzXsV3TkFyZII2RhCTjseYBhKSdvAeb7Lx5jGQQL9Qa6hxJWltLq9O5tFxszouWooi/rF55As/qR/cXZ81ejRkPPWhUMufVwsCmjwSKE2ZR40qlsHj6fLO4T3taVqM6fCzDe9zfiGxWlXpNwgkbKSJkqeQM0yJtjkyGHHa/gu5zTINOVl6AXCbr796pAeN4LBUyOBUG1WpTnqutVkToKkUVvZ4YuCdQpEsvSe8QN4Ogd/JIcFxNjaETdegfOOSbh4NVqreksfUse+anK600MmEA==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CPYP284MB0419.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:7e::5) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.14; Thu, 4 Aug
 2022 14:52:06 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2%7]) with mapi id 15.20.5482.016; Thu, 4 Aug 2022
 14:52:06 +0000
From: Ivan Quitschal 
To: Warner Losh , Hans Petter Selasky 
CC: "freebsd-current@freebsd.org" 
Subject: RES: vt newcons 3 clicks mouse paste issue FIXED
Thread-Topic: vt newcons 3 clicks mouse paste issue FIXED
Thread-Index: AQHYpmw1CB+cesrdUEGiwPuu2IoeEK2eyDAAgAADbACAAAOCAIAABylA
Date: Thu, 4 Aug 2022 14:52:06 +0000
Message-ID:
 
References:
 
 
 
 <41ef5c38-515f-739a-cb47-7cab0e609526@selasky.org>
 
 <20220623014847.067b18a5ba388639cf6009ce@dec.sakura.ne.jp>
 
 
 
 
 
In-Reply-To:
 
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [ykR0WaqZy6fd7UsCyJw6faTIeQbpNbm+OD+KzUwc678OKwntkttG5fVzDjvebgUw]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2e1791dd-4716-41ff-24c3-08da7628e64d
x-ms-traffictypediagnostic: CPYP284MB0419:EE_
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 wPkzhETBVRmlUb7c/W36cIPPPU0gTuHwbepT03oTnBREjMHQnbbN6n1LAZtG3UVC8eXTuqr0cAfqoAiLZ1PXbD/oL4zH8NXFghDDaeKrcysedEbAPKjwG/beCoX9p80v+O+WvB8F08Hp5BcVekAMIZ9jOtV5c9zZaecoTvqeanweUoZKgSQNgTmbDgB9jSmUlE94W0gvwy9/oapGAkNMVBTl1H7pWOB5jfnj3KQxEu+n8X2xYmmxJDtcHjzM9G/QjeBDUKRH4r2tH4RORKeJjpRPmFR+mg6mGVT7VTNW//iRiWwpSvcYXBfsgWxlnv1LrioBrheBGyOOAzfGqpv9HKLso5q3ju+mRDQnd9gtnYVqNSt/Kf19p9zKziIzq883tEKJcvl5ff8Htq3huvX62vVMzkS4XZfPL0y5DN91AtdgSnwL/8P8wQueic53UmxTHxg6yHe4aCjHOi+0hd871Wopro+lFH7fMbl30+Z7RPE9auro+y16gj4/4ueWErcmhiKcBwaphFenr5DWhUz1R97C5GSzzsJJwk+epG5No3zWWo0nwEWlomGccoUa01yM4l7ied64CU9xoHPEt09MpHIrIfcCe1rSKApyXFpO1KjN6dS5v8wQgmK8EQPSbSzH
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?MkJKNU1lSHhHbzNUWFo3bXYrZWdLRUJ6RGNxenIxMU5Bak5CbzRtV0dDSk5r?=
 =?utf-8?B?QXRGZ0MyNEE2RDNGTHV1eG1MRDNoSUEvOHR6MHIxdWZmRUF2citBOVZJZk9s?=
 =?utf-8?B?OWlDeFEwVEsvN1NwYm1kOGJpeDN3Ty8yQ1FDZk1tZUk1Skt4bVU1R1FrNnNp?=
 =?utf-8?B?Qm1RZk9RbVFsMXgxTU9IT2wzK2tzd0xOdll0NlFScnd5TTRKYk5DMEJBcy9u?=
 =?utf-8?B?OWFqVHBQTmhtT3IrRW54ZW9LSlppZmQ1ZWxNdktVMEVTUllHYW9qNUJLdjEy?=
 =?utf-8?B?V3RiVUp1RWJIRS83TzdubWdoQkoyMThNN0RtTm5MOXlyNmRmckI3b2pFbFBi?=
 =?utf-8?B?enIzdnFNMk1ZQXZYT0VFcDM0M0dydFoxYnpVUUVzc0E2WnhZZlFzS3JidVBh?=
 =?utf-8?B?SjYveU9XWkVsc0VFNkVWVnh6UjNsL0ZNcVhvZnJqaElPajR4cjlubzNxNFMr?=
 =?utf-8?B?MlZDTmptdlAvUDVSamxSUG1UWWZHUnNpQkVxRFRaYnMrNmlTbmxidXBGMk1Y?=
 =?utf-8?B?aFRkbm9GUUpZOE1XU3BSY1Nna0N6ZUllTVNybGhnYmYwOWJYaXFBNGU5RGxm?=
 =?utf-8?B?cXdPNHFITWpDVjE0NHpKN0tmWlk4SzMzQVhreEZ2aEVqWlQrb3NMUFFjWXNC?=
 =?utf-8?B?by9VcmcrS0dXL09zdVpVNVllQmZBeWpWeFlHNmVpYTlOVjhLTzV3b1grK0Jt?=
 =?utf-8?B?KzNmUU12a0l0NE5UYTRKNkNnRU9TWmk1Z2JtdFNvdTVacGpacXZGKzdoRkhH?=
 =?utf-8?B?SzJvWkxQWjYwQ28zS3ppczRTSDNSS3AvRTgxUzNtUHFyZk05ZStVSFRvSWtW?=
 =?utf-8?B?Y2VUckZMUXZTcXB1Y0VobjQ5dXlHckZBNUxuU1hKV3dvRmltNktjYzZ1VXFW?=
 =?utf-8?B?SXBveEUrODVsWUJVYWtleWdnTUJjNFRNNUxYNnB1d0phNWxySjh6a2dGb0JR?=
 =?utf-8?B?cXk1dGJCNmcvVHRkdjVDUWZ5d0t4QlIrL0N6N3RFMkkyUlpPeUYvbmZQNEo0?=
 =?utf-8?B?YUk0UWhFOWtVdnMzd240bGdwNkErbXUrUEphSjZXc29IWlhhd2FuYWdZd1A4?=
 =?utf-8?B?NGZ0dGl0dGJSNDQ0TVpNZk16QlQ2Q1FKb0ZraEpnY0drZC9XelRvUXNyYW9v?=
 =?utf-8?B?cXhtNldqQlZsaGxQdWhiUVNGYnFCM0xQQUp0S0dRelI1a3I3a0ZVeGh5M3Q5?=
 =?utf-8?B?djBmdTgzeENFSDlnSktYREZBdFlFVXZnTjFmRFoydkFxUHRwL3BoUFRQWVI4?=
 =?utf-8?B?Tjk1N2ljN1g5UkZnV0xRcENsMXdmaTZyL2czRnFGRFhFTVRKaDErQ1Y4enc1?=
 =?utf-8?B?YW1nVU9NbEUwdE04dHNYbzEwVG9HZFhEUTd1SGtSbEliZFNhenhsblBQL3hE?=
 =?utf-8?B?WmVLVVJGdjBPRURhTC9teXFjeS9pRmRtVTcyV0lmOURuQUM5aWNNRXBsYjRP?=
 =?utf-8?B?bjE4czI2ZzJiWWR6QWRYUys5ZkZFS0dJYklDUGU1bzY0azdjOE5weVZuMHdO?=
 =?utf-8?B?K296TW9JemM5cjRoTzN6czhXQXdYYW9SblVTTXg2YmluVDNwODZLcnhrYnBC?=
 =?utf-8?B?c2xsY0FoN2tDQWl1ZElJdGtwVGFKVzVsY1JHR0dneDkwdWgxenF1RVI4R1dv?=
 =?utf-8?B?MDZwNFlLL3czaGRFN3Z1aTh6YTNlVnlmTlBpY3JiM0g4SHNhalY0SzhieTZV?=
 =?utf-8?B?TnhScFNIaGQxV213RzBFcjY4OHoyMmduanlPZVU1QUtFM2l5RUc1MHludDI4?=
 =?utf-8?Q?RoR+L56PAcuOgeXf+FGLnOdCI+ts5gzas+cmm0K?=
Content-Type: multipart/alternative;
	boundary="_000_CP6P284MB19004BFCF923F0FA279BBC61CB9F9CP6P284MB1900BRAP_"
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-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e1791dd-4716-41ff-24c3-08da7628e64d
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2022 14:52:06.0307
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPYP284MB0419
X-Rspamd-Queue-Id: 4LzBXB27wkz3L9r
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=CE6W3a+h;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.56 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-2.76 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_SHORT(-0.97)[-0.975];
	NEURAL_SPAM_MEDIUM(0.81)[0.812];
	NEURAL_HAM_LONG(-0.70)[-0.695];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_BASE64_TEXT(0.10)[];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	FROM_HAS_DN(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.96.56:from];
	PHISHED_WHITELISTED(0.00)[freebsd.org->nam12.safelinks.protection.outlook.com];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--_000_CP6P284MB19004BFCF923F0FA279BBC61CB9F9CP6P284MB1900BRAP_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSGFucw0KDQpSZW1vdmVkIHRoZSAvL+KAmXMgb2xkIGNvZGUgY29tbWVudHMgYXMgeW91IHJl
cXVlc3RlZCAoc29ycnkgLCBpbSBzdGlsbCBnZXR0aW5nIHRoZSBwcm9jZXNzIGZsb3cg8J+YiiAp
DQoNCg0KVGhhbmtzDQoNCi0tdHprDQoNCkRlOiBvd25lci1mcmVlYnNkLWN1cnJlbnRAZnJlZWJz
ZC5vcmcgPG93bmVyLWZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZz4gRW0gbm9tZSBkZSBJdmFu
IFF1aXRzY2hhbA0KRW52aWFkYSBlbTogcXVpbnRhLWZlaXJhLCA0IGRlIGFnb3N0byBkZSAyMDIy
IDExOjMyDQpQYXJhOiBXYXJuZXIgTG9zaCA8aW1wQGJzZGltcC5jb20+OyBIYW5zIFBldHRlciBT
ZWxhc2t5IDxocHNAc2VsYXNreS5vcmc+DQpDYzogZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3Jn
DQpBc3N1bnRvOiBSRVM6IHZ0IG5ld2NvbnMgMyBjbGlja3MgbW91c2UgcGFzdGUgaXNzdWUgRklY
RUQNCg0KVGhhbmsgeW91IFdhcm5lcg0KDQpEb25lDQoNCmh0dHBzOi8vcmV2aWV3cy5mcmVlYnNk
Lm9yZy9EMzYwNDI8aHR0cHM6Ly9uYW0xMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv
bS8/dXJsPWh0dHBzJTNBJTJGJTJGcmV2aWV3cy5mcmVlYnNkLm9yZyUyRkQzNjA0MiZkYXRhPTA1
JTdDMDElN0MlN0MxYjg5ZjcwNjdiYmQ0OWUyZmIwYTA4ZGE3NjI2MjBlMSU3Qzg0ZGY5ZTdmZTlm
NjQwYWZiNDM1YWFhYWFhYWFhYWFhJTdDMSU3QzAlN0M2Mzc5NTIyMDMzOTAyMDc3MzQlN0NVbmtu
b3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENK
QlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCU3QyU3QyU3QyZzZGF0YT03Z2liZXZt
Vnh2eWlQSnZxeEZJQXIxRHM1ZW9pYmh3c3clMkZrWjFYQyUyQndxQSUzRCZyZXNlcnZlZD0wPg0K
RDM2MDQyDQoNCkp1c3QgdG8gbWFrZSBjbGVhci4gSeKAmWxsIHB1dCBoZXJlIHdoYXQgSSB3cm90
ZSBpbiB0aGUgY29tbWVudHMNCg0KDQp3ZSBoYXZlIHR3byBjaGFuZ2VzIGluIHRoaXMgcGF0Y2gu
DQoNCmZpcnN0IG9uZSBpcyByZWdhcmRpbmcgdGhlIDMgY2xpY2tzIHBhc3RlLg0KdnRidWZfZXh0
cmFjdF9tYXJrZWQoKSBnYWlucyBhIG5ldyBhcmcNCmludCBtYXJrDQoNCnRoZSBzZWNvbmQgY2hh
bmdlIGlzIG5vdCBtdWNoIG9mIGEgY2hhbmdlIGJlY2F1c2UgaSBoYWQgdG8gbWVzcyB1cCB0aGUN
CuKAnGNhc2UgVlRfTU9VU0VfRVhURU5EQlVUVE9OOuKAnQ0KDQp0aGlzIGNoYW5nZSBpcyByZWdh
cmRpbmcgdGhlIGhpZ2hsaWdodCBtYXJrIHRoYXQgZG9lc27igJl0IGdvIGF3YXkgZnJvbSB0aGUg
c2NyZWVuIGFmdGVyIHlvdSBwYXN0ZSBpdC4gdGhlIGhpZ2hsaWdodCBtYXJrIHN0YXlzIGZvcmV2
ZXINCnRoZSBiZWxvdyBzb2x2ZXMgdGhlIHByb2JsZW0NCg0KSeKAmXZlIHJlcGxhY2VkDQptYXJr
ID0gVlRCX01BUktfRVhURU5EOw0Kd2l0aA0KbWFyayA9IFZUQl9NQVJLX1NUQVJUDQoNCmFsc28g
aW5jbHVkZWQgIOKAnG1hcmsgPSBWVEJfTUFSS19TVEFSVOKAnSBhbmQgcmVtb3ZlZCB0aGUgcmV0
dXJuIGZyb20NCiAgICAgICAgICAgICAgIGNhc2UgVlRfTU9VU0VfUEFTVEVCVVRUT046DQoNCmZp
cnN0IGNoYW5nZSBpcyAxMDAlIG9rICh0aGUgM2NsaWNrIHBhc3RpbmcpDQpzZWNvbmQgb25lIG5l
ZWRzIGFuIG92ZXJsb29rIG9uIHdoZXJlIHRvIHB1dCB0aGlzIOKAnFZUQl9NQVJLX1NUQVJU4oCd
IHdpdGhvdXQgbWVzc2luZyB1cCB0aGUgc3dpdGNoIG9wdGlvbiDigJxWVF9NT1VTRV9FWFRFTkRC
VVRUT07igJ0NCg0KdGhhbmtzDQoNCi0tdHprDQoNCg0KRGU6IFdhcm5lciBMb3NoIDxpbXBAYnNk
aW1wLmNvbTxtYWlsdG86aW1wQGJzZGltcC5jb20+Pg0KRW52aWFkYSBlbTogcXVpbnRhLWZlaXJh
LCA0IGRlIGFnb3N0byBkZSAyMDIyIDExOjEyDQpQYXJhOiBJdmFuIFF1aXRzY2hhbCA8dGV6ZWth
QGhvdG1haWwuY29tPG1haWx0bzp0ZXpla2FAaG90bWFpbC5jb20+Pg0KQ2M6IEhhbnMgUGV0dGVy
IFNlbGFza3kgPGhwc0BzZWxhc2t5Lm9yZzxtYWlsdG86aHBzQHNlbGFza3kub3JnPj47IGZyZWVi
c2QtY3VycmVudEBmcmVlYnNkLm9yZzxtYWlsdG86ZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3Jn
Pg0KQXNzdW50bzogUmU6IHZ0IG5ld2NvbnMgMyBjbGlja3MgbW91c2UgcGFzdGUgaXNzdWUgRklY
RUQNCg0KDQoNCk9uIFRodSwgQXVnIDQsIDIwMjIgYXQgODowNCBBTSBJdmFuIFF1aXRzY2hhbCA8
dGV6ZWthQGhvdG1haWwuY29tPG1haWx0bzp0ZXpla2FAaG90bWFpbC5jb20+PiB3cm90ZToNCkhp
IEhhbnMNCg0KRDM2MDQyIGNyZWF0ZWQNCkhvdyBjYW4gSSBpbmNsdWRlIG1vcmUgcGF0Y2ggZmls
ZXMgaW4gdGhlIHNhbWUgZGVmZWN0IG51bWJlcj8gRDM2MDQyDQpodHRwczovL3Jldmlld3MuZnJl
ZWJzZC5vcmcvRDM2MDQyPGh0dHBzOi8vbmFtMTIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v
ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnJldmlld3MuZnJlZWJzZC5vcmclMkZEMzYwNDImZGF0
YT0wNSU3QzAxJTdDJTdDMWI4OWY3MDY3YmJkNDllMmZiMGEwOGRhNzYyNjIwZTElN0M4NGRmOWU3
ZmU5ZjY0MGFmYjQzNWFhYWFhYWFhYWFhYSU3QzElN0MwJTdDNjM3OTUyMjAzMzkwMjA3NzM0JTdD
VW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJ
aUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAlN0MlN0MlN0Mmc2RhdGE9N2dp
YmV2bVZ4dnlpUEp2cXhGSUFyMURzNWVvaWJod3N3JTJGa1oxWEMlMkJ3cUElM0QmcmVzZXJ2ZWQ9
MD4NCg0KSXRzIG1pc3NpbmcgdGhlIHZ0LmguZGlmZiBhbmQgdnRfY29yZS5kaWZmDQpCb3RoIGF0
dGFjaGVkDQoNClNob3VsZCBpIGhhdmUgcHV0IGFsbCB0aHJlZSBpbiB0aGUgcmF3IHBhdGNoIGNy
ZWF0aW9uIGNvbWJvIGJveCB3aGVuIEkgd2FzIGNyZWF0aW5nIHRoZSBkZWZlY3Q/DQpTb3JyeSBt
eSBkdW1ibmVzcyAgLCBuZXZlciB1c2VkIHRoYXQgcGhhYnJpY2F0b3INCg0KR2VuZXJhdGUgdGhl
IGRpZmYgd2l0aCAnZ2l0IGRpZmYgLVU5OTk5OScgdG8gcGljayB1cCBhbGwgdGhlIGNoYW5nZXMg
YXQgb25jZSBhbmQgdG8gZ2l2ZSByZXZpZXdlcnMNCmVub3VnaCBjb250ZXh0LiBFaXRoZXIgZG9u
J3Qgc3BlY2lmeSBhbnkgZmlsZXMsIG9yIHNwZWNpZnkgYWxsIHRoZSBvbmVzIGluIHRoZSBjaGFu
Z2UgKGRlcGVuZGluZw0Kb24gdGhlIHN0YXRlIG9mIHlvdXIgdHJlZSkuIFVwbG9hZCB0aGF0IGRp
ZmYuIHlvdSBjYW4gdXNlIHRoZSB3ZWIgaW50ZXJmYWNlIHRvICd1cGRhdGUnIHRoZSBkaWZmIHRv
DQppbmNsdWRlIGV2ZXJ5dGhpbmcsIG5vIG5lZWQgdG8gbWFrZSBhIG5ldyBvbmUuDQoNCldhcm5l
cg0KDQotLXR6aw0KDQoNCg0KDQoNCj4gLS0tLS1NZW5zYWdlbSBvcmlnaW5hbC0tLS0tDQo+IERl
OiBJdmFuIFF1aXRzY2hhbCA8dGV6ZWthQGhvdG1haWwuY29tPG1haWx0bzp0ZXpla2FAaG90bWFp
bC5jb20+Pg0KPiBFbnZpYWRhIGVtOiB0ZXLDp2EtZmVpcmEsIDIgZGUgYWdvc3RvIGRlIDIwMjIg
MDk6MzQNCj4gUGFyYTogSGFucyBQZXR0ZXIgU2VsYXNreSA8aHBzQHNlbGFza3kub3JnPG1haWx0
bzpocHNAc2VsYXNreS5vcmc+Pg0KPiBDYzogVG9tb2FraSBBT0tJIDxqdW5jaG9vbkBkZWMuc2Fr
dXJhLm5lLmpwPG1haWx0bzpqdW5jaG9vbkBkZWMuc2FrdXJhLm5lLmpwPj47IEl2YW4gUXVpdHNj
aGFsDQo+IDx0ZXpla2FAaG90bWFpbC5jb208bWFpbHRvOnRlemVrYUBob3RtYWlsLmNvbT4+OyBm
cmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmc8bWFpbHRvOmZyZWVic2QtY3VycmVudEBmcmVlYnNk
Lm9yZz47IEt1cnQgSmFlZ2VyDQo+IDxwaUBmcmVlYnNkLm9yZzxtYWlsdG86cGlAZnJlZWJzZC5v
cmc+Pg0KPiBBc3N1bnRvOiB2dCBuZXdjb25zIDMgY2xpY2tzIG1vdXNlIHBhc3RlIGlzc3VlIEZJ
WEVEDQo+DQo+DQo+IEhpIGd1eXMNCj4NCj4gQ3VycmVudGx5ICwgaWYgeW91IGNsaWNrIDMgdGlt
ZXMgaW4gb3JkZXIgdG8gc2VsZWN0IHRoZSBlbnRpcmUgcm93LCBpdHMganVzdCBub3QNCj4gd29y
a2luZyBhcyBpdCBzaG91bGQuDQo+IGkgZml4ZWQgdGhhdCBwbGVhc2UgZmluZCBiZWxvdyBhbmQg
YXR0YWNoZWQgdGhlIHBhdGNoZXMNCj4NCj4gV2l0aCB0aGlzIGNoYW5nZSBub3cgd2UgY2FuIGRv
IGEgMyBjbGlja3MgYW5kIHBhc3RlICwgaSBkb250IGtub3csIGluIHNvbWUNCj4gY29tbWFuZCwg
YW5kIGl0IHdpbGwgYmUgZXhlY3V0ZWQganVzdCBmaW5lLCBsaWtlIGl0IHdhcyBpbiBzeXNjb25z
LCBhbmQgc3RpbGwgaXMgaW4NCj4geHRlcm0vIGxpbnV4IGV0Yw0KPg0KPiBub3cgaWYgdGhlIGV2
ZW50IGlzIGEgMyBtb3VzZSBjbGlja3NzIHNlbGVjdCwgdGhlIHNwYWNlIHRyaW0gaXMgbWFkZSBv
biB0aGUgcmlnaHQNCj4gYW5kIGFuIDxlbnRlcj4gaXMgaW5jbHVkZWQNCj4NCj4gdGhhbmtzDQo+
DQo+IC0tdHprDQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLSBzeXMvZGV2L3Z0
L3Z0X2J1Zi5jLm9yaWcgICAgMjAyMi0wOC0wMiAwODo0NDoyNy4yMjk3ODIwMDAgLTAzMDANCj4g
KysrIHN5cy9kZXYvdnQvdnRfYnVmLmMgMjAyMi0wOC0wMiAwODo0NTowMi43MDM2OTcwMDAgLTAz
MDANCj4gQEAgLTc3MSw3ICs3NzEsNyBAQA0KPiAgIH0NCj4NCj4gICB2b2lkDQo+IC12dGJ1Zl9l
eHRyYWN0X21hcmtlZChzdHJ1Y3QgdnRfYnVmICp2YiwgdGVybV9jaGFyX3QgKmJ1ZiwgaW50IHN6
KQ0KPiArdnRidWZfZXh0cmFjdF9tYXJrZWQoc3RydWN0IHZ0X2J1ZiAqdmIsIHRlcm1fY2hhcl90
ICpidWYsIGludCBzeiwgaW50DQo+ICttYXJrKQ0KPiAgIHsNCj4gICAgICAgICAgaW50IGksIGos
IHIsIGMsIGNzLCBjZTsNCj4gICAgICAgICAgdGVybV9wb3NfdCBzLCBlOw0KPiBAQCAtNzk5LDcg
Kzc5OSw3IEBADQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBidWZbaSsrXSA9IHZiLT52Yl9y
b3dzW3JdW2NdOw0KPg0KPiAgICAgICAgICAgICAgICAgIC8qIEZvciBhbGwgcm93cywgYnV0IHRo
ZSBsYXN0IG9uZS4gKi8NCj4gLSAgICAgICAgICAgICAgIGlmIChyICE9IGUudHBfcm93KSB7DQo+
ICsgICAgICAgICAgICAgICBpZiAociAhPSBlLnRwX3JvdyB8fCBtYXJrID09IFZUQl9NQVJLX1JP
Vykgew0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgLyogVHJpbSB0cmFpbGluZyB3b3JkIHNl
cGFyYXRvcnMsIGlmIGFueS4gKi8NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIGZvciAoOyBp
ICE9IGo7IGktLSkgew0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZiAoIXRj
aGFyX2lzX3dvcmRfc2VwYXJhdG9yKGJ1ZltpIC0gMV0pKQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KPg0KPiAtLS0gc3lzL2Rldi92dC92dF9jb3JlLmMub3JpZyAgIDIwMjItMDgtMDIgMDg6NDM6
MTUuNDM2NDE1MDAwIC0wMzAwDQo+ICsrKyBzeXMvZGV2L3Z0L3Z0X2NvcmUuYyAgICAgICAgMjAy
Mi0wOC0wMiAwODo0Mzo0OS4xMjAwOTYwMDAgLTAzMDANCj4gQEAgLTIyODcsNyArMjI4Nyw3IEBA
DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBWRF9QQVNURUJVRlNaKHZkKSA9IGxlbjsNCj4g
ICAgICAgICAgICAgICAgICB9DQo+ICAgICAgICAgICAgICAgICAgLyogUmVxdWVzdCBjb3B5L3Bh
c3RlIGJ1ZmZlciBkYXRhLCBubyBtb3JlIHRoYW4gYGxlbicgKi8NCj4gLSAgICAgICAgICAgICAg
IHZ0YnVmX2V4dHJhY3RfbWFya2VkKCZ2dy0+dndfYnVmLCBWRF9QQVNURUJVRih2ZCksIGxlbik7
DQo+ICsgICAgICAgICAgICAgICB2dGJ1Zl9leHRyYWN0X21hcmtlZCgmdnctPnZ3X2J1ZiwgVkRf
UEFTVEVCVUYodmQpLCBsZW4sDQo+ICsgbWFyayk7DQo+DQo+ICAgICAgICAgICAgICAgICAgVkRf
UEFTVEVCVUZMRU4odmQpID0gbGVuOw0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4g
LS0tIHN5cy9kZXYvdnQvdnQuaC5vcmlnICAgICAgICAyMDIyLTA4LTAyIDA4OjQxOjIzLjg4ODU4
NDAwMCAtMDMwMA0KPiArKysgc3lzL2Rldi92dC92dC5oICAgICAyMDIyLTA4LTAyIDA4OjQxOjU0
LjUwNDMwOTAwMCAtMDMwMA0KPiBAQCAtMjM4LDcgKzIzOCw3IEBADQo+ICAgI2lmbmRlZiBTQ19O
T19DVVRQQVNURQ0KPiAgIGludCB2dGJ1Zl9zZXRfbWFyayhzdHJ1Y3QgdnRfYnVmICp2YiwgaW50
IHR5cGUsIGludCBjb2wsIGludCByb3cpOw0KPiAgIGludCB2dGJ1Zl9nZXRfbWFya2VkX2xlbihz
dHJ1Y3QgdnRfYnVmICp2Yik7IC12b2lkDQo+IHZ0YnVmX2V4dHJhY3RfbWFya2VkKHN0cnVjdCB2
dF9idWYgKnZiLCB0ZXJtX2NoYXJfdCAqYnVmLCBpbnQgc3opOw0KPiArdm9pZCB2dGJ1Zl9leHRy
YWN0X21hcmtlZChzdHJ1Y3QgdnRfYnVmICp2YiwgdGVybV9jaGFyX3QgKmJ1ZiwgaW50IHN6LA0K
PiAraW50DQo+IG1hcmspOw0KPiAgICNlbmRpZg0KPg0KPiAgICNkZWZpbmUgICAgICAgIFZUQl9N
QVJLX05PTkUgICAgICAgICAgIDANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg==

--_000_CP6P284MB19004BFCF923F0FA279BBC61CB9F9CP6P284MB1900BRAP_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg
MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h
bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9udC1zaXpl
OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw
YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5Fc3RpbG9EZUVtYWlsMjENCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt
dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAzLjBjbSA3MC44NXB0
IDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk
aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl
ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o
ZWFkPg0KPGJvZHkgbGFuZz0iUFQtQlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxl
PSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij5IaSBIYW5zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZW1vdmVkIHRoZSAvL+KAmXMgb2xkIGNvZGUg
Y29tbWVudHMgYXMgeW91IHJlcXVlc3RlZCAoc29ycnkgLCBpbSBzdGlsbCBnZXR0aW5nIHRoZSBw
cm9jZXNzIGZsb3cNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6RU4tVVMiPiYjMTI4NTIyOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m
YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4gKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rczxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0tdHprPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj
bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj5EZTo8L2I+IG93bmVyLWZyZWVic2QtY3VycmVudEBmcmVlYnNk
Lm9yZyAmbHQ7b3duZXItZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnJmd0Ow0KPGI+RW0gbm9t
ZSBkZSA8L2I+SXZhbiBRdWl0c2NoYWw8YnI+DQo8Yj5FbnZpYWRhIGVtOjwvYj4gcXVpbnRhLWZl
aXJhLCA0IGRlIGFnb3N0byBkZSAyMDIyIDExOjMyPGJyPg0KPGI+UGFyYTo8L2I+IFdhcm5lciBM
b3NoICZsdDtpbXBAYnNkaW1wLmNvbSZndDs7IEhhbnMgUGV0dGVyIFNlbGFza3kgJmx0O2hwc0Bz
ZWxhc2t5Lm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9y
Zzxicj4NCjxiPkFzc3VudG86PC9iPiBSRVM6IHZ0IG5ld2NvbnMgMyBjbGlja3MgbW91c2UgcGFz
dGUgaXNzdWUgRklYRUQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmsgeW91IFdhcm5lcjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt
c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO
LVVTIj5Eb25lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt
bGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vbmFtMTIuc2FmZWxpbmtzLnByb3RlY3Rp
b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnJldmlld3MuZnJlZWJzZC5vcmclMkZE
MzYwNDImYW1wO2RhdGE9MDUlN0MwMSU3QyU3QzFiODlmNzA2N2JiZDQ5ZTJmYjBhMDhkYTc2MjYy
MGUxJTdDODRkZjllN2ZlOWY2NDBhZmI0MzVhYWFhYWFhYWFhYWElN0MxJTdDMCU3QzYzNzk1MjIw
MzM5MDIwNzczNCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxD
SlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJTdDJTdD
JTdDJmFtcDtzZGF0YT03Z2liZXZtVnh2eWlQSnZxeEZJQXIxRHM1ZW9pYmh3c3clMkZrWjFYQyUy
QndxQSUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0QzNjA0
MjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EMzYwNDI8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkp1c3QgdG8gbWFrZSBj
bGVhci4gSeKAmWxsIHB1dCBoZXJlIHdoYXQgSSB3cm90ZSBpbiB0aGUgY29tbWVudHM8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjkuMHB0O21hcmdpbi1sZWZ0OjBj
bTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OmJsYWNrIj53ZSBoYXZlIHR3byBjaGFuZ2VzIGluIHRoaXMgcGF0Y2guPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBj
bTttYXJnaW4tYm90dG9tOjkuMHB0O21hcmdpbi1sZWZ0OjBjbTtiYWNrZ3JvdW5kOndoaXRlO2Zv
bnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29y
cGhhbnM6IDI7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt0ZXh0LWRl
Y29yYXRpb24tdGhpY2tuZXNzOiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlh
bDt0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Zmlyc3Qgb25lIGlzIHJlZ2Fy
ZGluZyB0aGUgMyBjbGlja3MgcGFzdGUuPGJyPg0KdnRidWZfZXh0cmFjdF9tYXJrZWQoKSBnYWlu
cyBhIG5ldyBhcmc8YnI+DQppbnQgbWFyazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo5
LjBwdDttYXJnaW4tbGVmdDowY207YmFja2dyb3VuZDp3aGl0ZTtmb250LXZhcmlhbnQtbGlnYXR1
cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3dpZG93czog
Mjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXRoaWNrbmVz
czogaW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7dGV4dC1kZWNvcmF0aW9u
LWNvbG9yOiBpbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6YmxhY2siPnRoZSBzZWNvbmQgY2hhbmdlIGlzIG5vdCBtdWNoIG9mIGEg
Y2hhbmdlIGJlY2F1c2UgaSBoYWQgdG8gbWVzcyB1cCB0aGU8YnI+DQrigJxjYXNlIFZUX01PVVNF
X0VYVEVOREJVVFRPTjrigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206OS4wcHQ7bWFy
Z2luLWxlZnQ6MGNtO2JhY2tncm91bmQ6d2hpdGU7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9y
bWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt3aWRvd3M6IDI7LXdlYmtp
dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3RleHQtZGVjb3JhdGlvbi10aGlja25lc3M6IGluaXRp
YWw7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjog
aW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOmJsYWNrIj50aGlzIGNoYW5nZSBpcyByZWdhcmRpbmcgdGhlIGhpZ2hsaWdodCBtYXJr
IHRoYXQgZG9lc27igJl0IGdvIGF3YXkgZnJvbSB0aGUgc2NyZWVuIGFmdGVyIHlvdSBwYXN0ZSBp
dC4gdGhlIGhpZ2hsaWdodCBtYXJrIHN0YXlzIGZvcmV2ZXI8YnI+DQp0aGUgYmVsb3cgc29sdmVz
IHRoZSBwcm9ibGVtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207
YmFja2dyb3VuZDp3aGl0ZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXRoaWNrbmVzczogaW5pdGlhbDt0ZXh0LWRlY29y
YXRpb24tc3R5bGU6IGluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsO3dvcmQt
c3BhY2luZzowcHgiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si
PknigJl2ZSByZXBsYWNlZDxicj4NCm1hcmsgPSBWVEJfTUFSS19FWFRFTkQ7PGJyPg0Kd2l0aDxi
cj4NCm1hcmsgPSBWVEJfTUFSS19TVEFSVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YWxzbyBpbmNsdWRl
ZCAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si
PuKAnG1hcmsgPSBWVEJfTUFSS19TVEFSVOKAnQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5h
bmQgcmVtb3ZlZCB0aGUgcmV0dXJuIGZyb20gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNh
c2UgVlRfTU9VU0VfUEFTVEVCVVRUT046PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
Zmlyc3QgY2hhbmdlIGlzIDEwMCUgb2sgKHRoZSAzY2xpY2sgcGFzdGluZyk8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5zZWNvbmQgb25lIG5lZWRzIGFuIG92ZXJsb29r
IG9uIHdoZXJlIHRvIHB1dCB0aGlzIOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjpibGFjayI+VlRCX01BUktfU1RBUlTigJ0gd2l0aG91dCBtZXNzaW5nIHVwDQog
dGhlIHN3aXRjaCBvcHRpb24g4oCcVlRfTU9VU0VfRVhURU5EQlVUVE9O4oCdPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj50
aGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vn
b2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6YmxhY2siPi0tdHprPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5EZTo8
L2I+IFdhcm5lciBMb3NoICZsdDs8YSBocmVmPSJtYWlsdG86aW1wQGJzZGltcC5jb20iPmltcEBi
c2RpbXAuY29tPC9hPiZndDsNCjxicj4NCjxiPkVudmlhZGEgZW06PC9iPiBxdWludGEtZmVpcmEs
IDQgZGUgYWdvc3RvIGRlIDIwMjIgMTE6MTI8YnI+DQo8Yj5QYXJhOjwvYj4gSXZhbiBRdWl0c2No
YWwgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZXpla2FAaG90bWFpbC5jb20iPnRlemVrYUBob3RtYWls
LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBIYW5zIFBldHRlciBTZWxhc2t5ICZsdDs8YSBo
cmVmPSJtYWlsdG86aHBzQHNlbGFza3kub3JnIj5ocHNAc2VsYXNreS5vcmc8L2E+Jmd0OzsNCjxh
IGhyZWY9Im1haWx0bzpmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmciPmZyZWVic2QtY3VycmVu
dEBmcmVlYnNkLm9yZzwvYT48YnI+DQo8Yj5Bc3N1bnRvOjwvYj4gUmU6IHZ0IG5ld2NvbnMgMyBj
bGlja3MgbW91c2UgcGFzdGUgaXNzdWUgRklYRUQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyA0LCAyMDIyIGF0IDg6MDQgQU0gSXZh
biBRdWl0c2NoYWwgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZXpla2FAaG90bWFpbC5jb20iPnRlemVr
YUBob3RtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkhpIEhhbnM8YnI+DQo8YnI+DQpEMzYwNDIgY3JlYXRlZDxicj4NCkhvdyBjYW4g
SSBpbmNsdWRlIG1vcmUgcGF0Y2ggZmlsZXMgaW4gdGhlIHNhbWUgZGVmZWN0IG51bWJlcj8gRDM2
MDQyPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYW0xMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGcmV2aWV3cy5mcmVlYnNkLm9yZyUyRkQzNjA0MiZh
bXA7ZGF0YT0wNSU3QzAxJTdDJTdDMWI4OWY3MDY3YmJkNDllMmZiMGEwOGRhNzYyNjIwZTElN0M4
NGRmOWU3ZmU5ZjY0MGFmYjQzNWFhYWFhYWFhYWFhYSU3QzElN0MwJTdDNjM3OTUyMjAzMzkwMjA3
NzM0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lW
Mmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAlN0MlN0MlN0MmYW1w
O3NkYXRhPTdnaWJldm1WeHZ5aVBKdnF4RklBcjFEczVlb2liaHdzdyUyRmtaMVhDJTJCd3FBJTNE
JmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qu
b3JnL0QzNjA0MjwvYT48YnI+DQo8YnI+DQpJdHMgbWlzc2luZyB0aGUgdnQuaC5kaWZmIGFuZCB2
dF9jb3JlLmRpZmY8YnI+DQpCb3RoIGF0dGFjaGVkPGJyPg0KPGJyPg0KU2hvdWxkIGkgaGF2ZSBw
dXQgYWxsIHRocmVlIGluIHRoZSByYXcgcGF0Y2ggY3JlYXRpb24gY29tYm8gYm94IHdoZW4gSSB3
YXMgY3JlYXRpbmcgdGhlIGRlZmVjdD88YnI+DQpTb3JyeSBteSBkdW1ibmVzcyZuYnNwOyAsIG5l
dmVyIHVzZWQgdGhhdCBwaGFicmljYXRvcjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2VuZXJhdGUgdGhlIGRpZmYgd2l0aCAnZ2l0
IGRpZmYgLVU5OTk5OScgdG8gcGljayB1cCBhbGwgdGhlIGNoYW5nZXMgYXQgb25jZSBhbmQgdG8g
Z2l2ZSByZXZpZXdlcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPmVub3VnaCBjb250ZXh0LiBFaXRoZXIgZG9uJ3Qgc3BlY2lmeSBhbnkgZmlsZXMs
IG9yIHNwZWNpZnkgYWxsIHRoZSBvbmVzIGluIHRoZSBjaGFuZ2UgKGRlcGVuZGluZzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b24gdGhlIHN0YXRl
IG9mIHlvdXIgdHJlZSkuIFVwbG9hZCB0aGF0IGRpZmYuIHlvdSBjYW4gdXNlIHRoZSB3ZWIgaW50
ZXJmYWNlIHRvICd1cGRhdGUnIHRoZSBkaWZmIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbmNsdWRlIGV2ZXJ5dGhpbmcsIG5vIG5lZWQgdG8g
bWFrZSBhIG5ldyBvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPldhcm5lcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+LS10ems8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tTWVu
c2FnZW0gb3JpZ2luYWwtLS0tLTxicj4NCiZndDsgRGU6IEl2YW4gUXVpdHNjaGFsICZsdDs8YSBo
cmVmPSJtYWlsdG86dGV6ZWthQGhvdG1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGV6ZWthQGhv
dG1haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7IEVudmlhZGEgZW06IHRlcsOnYS1mZWlyYSwgMiBk
ZSBhZ29zdG8gZGUgMjAyMiAwOTozNDxicj4NCiZndDsgUGFyYTogSGFucyBQZXR0ZXIgU2VsYXNr
eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhwc0BzZWxhc2t5Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmhw
c0BzZWxhc2t5Lm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogVG9tb2FraSBBT0tJICZsdDs8YSBo
cmVmPSJtYWlsdG86anVuY2hvb25AZGVjLnNha3VyYS5uZS5qcCIgdGFyZ2V0PSJfYmxhbmsiPmp1
bmNob29uQGRlYy5zYWt1cmEubmUuanA8L2E+Jmd0OzsgSXZhbiBRdWl0c2NoYWw8YnI+DQomZ3Q7
ICZsdDs8YSBocmVmPSJtYWlsdG86dGV6ZWthQGhvdG1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+
dGV6ZWthQGhvdG1haWwuY29tPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzpmcmVlYnNkLWN1cnJl
bnRAZnJlZWJzZC5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmZyZWVic2QtY3VycmVudEBmcmVlYnNk
Lm9yZzwvYT47IEt1cnQgSmFlZ2VyPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBpQGZy
ZWVic2Qub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGlAZnJlZWJzZC5vcmc8L2E+Jmd0Ozxicj4NCiZn
dDsgQXNzdW50bzogdnQgbmV3Y29ucyAzIGNsaWNrcyBtb3VzZSBwYXN0ZSBpc3N1ZSBGSVhFRDxi
cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIGd1eXM8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgQ3VycmVudGx5ICwgaWYgeW91IGNsaWNrIDMgdGltZXMgaW4gb3JkZXIgdG8gc2VsZWN0IHRo
ZSBlbnRpcmUgcm93LCBpdHMganVzdCBub3Q8YnI+DQomZ3Q7IHdvcmtpbmcgYXMgaXQgc2hvdWxk
Ljxicj4NCiZndDsgaSBmaXhlZCB0aGF0IHBsZWFzZSBmaW5kIGJlbG93IGFuZCBhdHRhY2hlZCB0
aGUgcGF0Y2hlczxicj4NCiZndDsgPGJyPg0KJmd0OyBXaXRoIHRoaXMgY2hhbmdlIG5vdyB3ZSBj
YW4gZG8gYSAzIGNsaWNrcyBhbmQgcGFzdGUgLCBpIGRvbnQga25vdywgaW4gc29tZTxicj4NCiZn
dDsgY29tbWFuZCwgYW5kIGl0IHdpbGwgYmUgZXhlY3V0ZWQganVzdCBmaW5lLCBsaWtlIGl0IHdh
cyBpbiBzeXNjb25zLCBhbmQgc3RpbGwgaXMgaW48YnI+DQomZ3Q7IHh0ZXJtLyBsaW51eCBldGM8
YnI+DQomZ3Q7IDxicj4NCiZndDsgbm93IGlmIHRoZSBldmVudCBpcyBhIDMgbW91c2UgY2xpY2tz
cyBzZWxlY3QsIHRoZSBzcGFjZSB0cmltIGlzIG1hZGUgb24gdGhlIHJpZ2h0PGJyPg0KJmd0OyBh
bmQgYW4gJmx0O2VudGVyJmd0OyBpcyBpbmNsdWRlZDxicj4NCiZndDsgPGJyPg0KJmd0OyB0aGFu
a3M8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS10ems8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K
Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgLS0tIHN5cy9kZXYvdnQvdnRfYnVm
LmMub3JpZyZuYnNwOyAmbmJzcDsgMjAyMi0wOC0wMiAwODo0NDoyNy4yMjk3ODIwMDAgLTAzMDA8
YnI+DQomZ3Q7ICsrKyBzeXMvZGV2L3Z0L3Z0X2J1Zi5jIDIwMjItMDgtMDIgMDg6NDU6MDIuNzAz
Njk3MDAwIC0wMzAwPGJyPg0KJmd0OyBAQCAtNzcxLDcgKzc3MSw3IEBAPGJyPg0KJmd0OyZuYnNw
OyAmbmJzcDt9PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3ZvaWQ8YnI+DQomZ3Q7
IC12dGJ1Zl9leHRyYWN0X21hcmtlZChzdHJ1Y3QgdnRfYnVmICp2YiwgdGVybV9jaGFyX3QgKmJ1
ZiwgaW50IHN6KTxicj4NCiZndDsgK3Z0YnVmX2V4dHJhY3RfbWFya2VkKHN0cnVjdCB2dF9idWYg
KnZiLCB0ZXJtX2NoYXJfdCAqYnVmLCBpbnQgc3osIGludDxicj4NCiZndDsgK21hcmspPGJyPg0K
Jmd0OyZuYnNwOyAmbmJzcDt7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgaW50IGksIGosIHIsIGMsIGNzLCBjZTs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyB0ZXJtX3Bvc190IHMsIGU7PGJyPg0KJmd0OyBAQCAtNzk5LDcgKzc5
OSw3IEBAPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBidWZbaSsr
XSA9IHZiLSZndDt2Yl9yb3dzW3JdW2NdOzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8qIEZv
ciBhbGwgcm93cywgYnV0IHRoZSBsYXN0IG9uZS4gKi88YnI+DQomZ3Q7IC0mbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aWYgKHIgIT0gZS50cF9y
b3cpIHs8YnI+DQomZ3Q7ICsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7aWYgKHIgIT0gZS50cF9yb3cgfHwgbWFyayA9PSBWVEJfTUFSS19ST1cp
IHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8qIFRyaW0gdHJh
aWxpbmcgd29yZCBzZXBhcmF0b3JzLCBpZiBhbnkuICovPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyBmb3IgKDsgaSAhPSBqOyBpLS0pIHs8YnI+DQomZ3Q7Jm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBp
ZiAoIXRjaGFyX2lzX3dvcmRfc2VwYXJhdG9yKGJ1ZltpIC0gMV0pKTxicj4NCiZndDsgLS0tLS0t
LS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tIHN5cy9kZXYvdnQvdnRfY29y
ZS5jLm9yaWcmbmJzcDsgJm5ic3A7MjAyMi0wOC0wMiAwODo0MzoxNS40MzY0MTUwMDAgLTAzMDA8
YnI+DQomZ3Q7ICsrKyBzeXMvZGV2L3Z0L3Z0X2NvcmUuYyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAyMDIyLTA4LTAyIDA4OjQzOjQ5LjEyMDA5NjAwMCAtMDMwMDxicj4NCiZndDsgQEAgLTIy
ODcsNyArMjI4Nyw3IEBAPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyBWRF9QQVNURUJVRlNaKHZkKSA9IGxlbjs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZndDsmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAvKiBSZXF1ZXN0IGNvcHkvcGFzdGUgYnVmZmVyIGRhdGEsIG5vIG1vcmUgdGhhbiBgbGVuJyAq
Lzxicj4NCiZndDsgLSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDt2dGJ1Zl9leHRyYWN0X21hcmtlZCgmYW1wO3Z3LSZndDt2d19idWYsIFZEX1BB
U1RFQlVGKHZkKSwgbGVuKTs8YnI+DQomZ3Q7ICsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dnRidWZfZXh0cmFjdF9tYXJrZWQoJmFtcDt2dy0m
Z3Q7dndfYnVmLCBWRF9QQVNURUJVRih2ZCksIGxlbiw8YnI+DQomZ3Q7ICsgbWFyayk7PGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVkRfUEFTVEVCVUZMRU4odmQpID0gbGVuOzxicj4NCiZndDsg
PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0t
IHN5cy9kZXYvdnQvdnQuaC5vcmlnJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIwMjItMDgt
MDIgMDg6NDE6MjMuODg4NTg0MDAwIC0wMzAwPGJyPg0KJmd0OyArKysgc3lzL2Rldi92dC92dC5o
Jm5ic3A7ICZuYnNwOyAmbmJzcDsyMDIyLTA4LTAyIDA4OjQxOjU0LjUwNDMwOTAwMCAtMDMwMDxi
cj4NCiZndDsgQEAgLTIzOCw3ICsyMzgsNyBAQDxicj4NCiZndDsmbmJzcDsgJm5ic3A7I2lmbmRl
ZiBTQ19OT19DVVRQQVNURTxicj4NCiZndDsmbmJzcDsgJm5ic3A7aW50IHZ0YnVmX3NldF9tYXJr
KHN0cnVjdCB2dF9idWYgKnZiLCBpbnQgdHlwZSwgaW50IGNvbCwgaW50IHJvdyk7PGJyPg0KJmd0
OyZuYnNwOyAmbmJzcDtpbnQgdnRidWZfZ2V0X21hcmtlZF9sZW4oc3RydWN0IHZ0X2J1ZiAqdmIp
OyAtdm9pZDxicj4NCiZndDsgdnRidWZfZXh0cmFjdF9tYXJrZWQoc3RydWN0IHZ0X2J1ZiAqdmIs
IHRlcm1fY2hhcl90ICpidWYsIGludCBzeik7PGJyPg0KJmd0OyArdm9pZCB2dGJ1Zl9leHRyYWN0
X21hcmtlZChzdHJ1Y3QgdnRfYnVmICp2YiwgdGVybV9jaGFyX3QgKmJ1ZiwgaW50IHN6LDxicj4N
CiZndDsgK2ludDxicj4NCiZndDsgbWFyayk7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsjZW5kaWY8
YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7I2RlZmluZSZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyBWVEJfTUFSS19OT05FJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDswPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+
PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_CP6P284MB19004BFCF923F0FA279BBC61CB9F9CP6P284MB1900BRAP_--

From nobody Sun Aug  7 17:16:20 2022
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 4M15bN1zMCz4YT42;
	Sun,  7 Aug 2022 17:16:32 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M15bN1BYwz3qc2;
	Sun,  7 Aug 2022 17:16:32 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659892592;
	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=icqawPut9IRZ5eqJcR2m1lhuWlgFQ42VI7CJmpoSz3U=;
	b=Z0CIZ20TZuVN0Rg9Qch9BKczk7shlqj8N5IZArdqiy3lnDdIx4pwa8TQzGhvPcnjHyhAPq
	0UNwqRXNH6w0dTbY0U5rXYZuYJ3MnnhLoMkGbiYhkDWsWeaVmucec40m4kYlKLF/T1UNYh
	02ll+WOJvLz/ROrEi5HX7QpjxuS8NMZ4/ypmCy/6+1WKego9ztX+TyRp3RouMNEQlDDnh8
	evZGYwZjnvy7BkZGJj7j/23hjae+zSw+EKHm06hsD8uIvUczX1kvHV74t/RUAEjTwiRtCY
	DA/YavNLdlXEmTAtgHPRAOt46T4XCsHhFIFwVUuNbZ7SAy5ksCJcN+5HWEwK4Q==
Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M15bM74LjzX74;
	Sun,  7 Aug 2022 17:16:31 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f174.google.com with SMTP id q14so3415223vke.9;
        Sun, 07 Aug 2022 10:16:31 -0700 (PDT)
X-Gm-Message-State: ACgBeo2ou4krkHef9JoRxBb0nbQ6GGBWF/n0vHtCz8+P/g/voI3Z/5JN
	72Ogor71amY1Mc0MVIuCchTUJrfaOXqiMn7kuDs=
X-Google-Smtp-Source: AA6agR6/J1RisTVeNxVbqLGxIPxsRQM7Wi6+uXJv+IEl0VedOM3ZvsDzSjnCrlWirWwvtn2FfprQL0/UM08rKiu3M2Y=
X-Received: by 2002:a05:6122:ce:b0:377:4e0f:a037 with SMTP id
 h14-20020a05612200ce00b003774e0fa037mr6097070vkc.5.1659892591323; Sun, 07 Aug
 2022 10:16:31 -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: Nuno Teixeira 
Date: Sun, 7 Aug 2022 18:16:20 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: [iwlwifi] ipv6 connection problem
To: freebsd-wireless@freebsd.org, 
	FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000004572b305e5a9dc6f"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659892592;
	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=icqawPut9IRZ5eqJcR2m1lhuWlgFQ42VI7CJmpoSz3U=;
	b=VdGuY6ZN+CbPIL+VW0v4aWwv3Z1DzwWY7n7BwkNO0nhC8cG9GJUq5/rwE0Y9nDM1mSqAmv
	GbZiCTx3W6EVMwDmA3bie1mynNNclOi6bbApLtPc8wAfzOrfmC4v5MqIXtnax3/FOICczb
	fvN8KvPF/F3KOMtu5x+Bl9rGeN4e+0Mct7ZSjQUznes8sLjJS8W2h0MB2cJ6yvyScqFrCj
	z1VhetMTKWkC0AG0GTbsB+zwzrtPoonjosXTsvIuaP/xhr3kSQINEMEdTls2MA/kx9iPxA
	oAEt36uYvJlaEsNeRhTDcn6wEu77nN9DdLFTAXdvCzCC7c3GHFhbW9dwkjLnWA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659892592; a=rsa-sha256; cv=none;
	b=BT+2M5WIApquNnPectH+IyFE1ATbT7PEGDvsbiSYReKLJiVzcB0O6a2QkXtGEqmJwjQLWM
	9Zc3qltVeGxD9+zAXKvHSrKuzTqDshUoFNwEZAnE4Rji4iz42C5H+4+hyoARysZ3G1Ma9P
	YMv2YXVTqzCpR5sEtLuH+ins1SCZXCKs7sWPvcci3XQfn3ciAOnKsDfd8q3KKNU0Cww4Ev
	CewC/bWZ5yt5WcGHL/pdok60Qofr2DdzsjrCUkPtMxdIo8Ja9jtH07y//P+1m+8Fz0EjZv
	tFO43zhEzVnADdiXE9Zr+l7cgQgcsbhb7S5ZZr5veH2mUPnKI9jKmMJ981pQjw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000004572b305e5a9dc6f
Content-Type: text/plain; charset="UTF-8"

Hello,

Due to ISP changes I was forced to use ipv6 on my re0 ethernet so I can
have a funcional internet.

Now I'm trying to get ipv6 on iwlwifi (AX201) with /etc/rc.conf:
---
wlans_iwlwifi0="wlan0"
create_args_wlan0="wlanmode sta regdomain ETSI country PT"
ifconfig_wlan0_ipv6="inet6 accept_rtadv"
ifconfig_wlan0="WPA SYNCDHCP"
rtsold_enable="YES"
---
but wpa_supplicant doesn't connect after trying for some seconds.

How do I obtain more details to help showing my problem?
I've tried "wpa_supplicant_flags="-f /var/log/wpa.log" without success.

Thanks,
-- 
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000004572b305e5a9dc6f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

Due to ISP changes I =
was forced to use ipv6 on my re0 ethernet so I can have a funcional interne=
t.

Now I'm trying to get ipv6 on iwlwifi (AX20=
1) with /etc/rc.conf:
---
wlans_iwlwifi0=3D"wlan0&=
quot;
create_args_wlan0=3D"wlanmode sta regdomain ETSI country PT&q=
uot;
ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"
ifconfig_wl=
an0=3D"WPA SYNCDHCP"
rtsold_enable=3D"YES"
---
but wpa_supplicant doesn't connect after trying for =
some seconds.

How do I obtain more details to help=
 showing my problem?
I've tried "wpa_supplicant_flags=3D=
"-f /var/log/wpa.log" without success.

Thanks,<=
br>
-- 
Nuno Teixeira
FreeBSD Committer (ports)


--0000000000004572b305e5a9dc6f--

From nobody Sun Aug  7 21:27:51 2022
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 4M1C9d2Y8Cz4Xq2f;
	Sun,  7 Aug 2022 21:28:05 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M1C9c17lmz3TgZ;
	Sun,  7 Aug 2022 21:28:03 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587])
	(using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.sbone.de (Postfix) with ESMTPS id 62F4E8D4A142;
	Sun,  7 Aug 2022 21:27:55 +0000 (UTC)
Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPS id 5BE37BD487B;
	Sun,  7 Aug 2022 21:27:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587])
	by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024)
	with ESMTP id L7-7IUTtvC8I; Sun,  7 Aug 2022 21:27:52 +0000 (UTC)
Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPSA id 87330BD3C10;
	Sun,  7 Aug 2022 21:27:52 +0000 (UTC)
Date: Sun, 7 Aug 2022 21:27:51 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: Nuno Teixeira 
cc: freebsd-wireless@freebsd.org, 
    FreeBSD CURRENT 
Subject: Re: [iwlwifi] ipv6 connection problem
In-Reply-To: 
Message-ID: 
References: 
X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Rspamd-Queue-Id: 4M1C9c17lmz3TgZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25];
	MIME_GOOD(-0.10)[text/plain];
	TO_DN_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-wireless@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DMARC_NA(0.00)[zabbadoz.net];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	RCVD_COUNT_FIVE(0.00)[5];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, 7 Aug 2022, Nuno Teixeira wrote:

Hi,

> Due to ISP changes I was forced to use ipv6 on my re0 ethernet so I can
> have a funcional internet.
>
> Now I'm trying to get ipv6 on iwlwifi (AX201) with /etc/rc.conf:
> ---
> wlans_iwlwifi0="wlan0"
> create_args_wlan0="wlanmode sta regdomain ETSI country PT"
> ifconfig_wlan0_ipv6="inet6 accept_rtadv"
> ifconfig_wlan0="WPA SYNCDHCP"
> rtsold_enable="YES"
> ---
> but wpa_supplicant doesn't connect after trying for some seconds.
>
> How do I obtain more details to help showing my problem?
> I've tried "wpa_supplicant_flags="-f /var/log/wpa.log" without success.

Let's get some more information on this..

(a) this is unlikely related to IPv6?  The only thing that would do
is pass down more multicast addresses than with just IPv4 (and that's
after assoc normally).  I run some on IPv6-only.
Let me ask you anyway, so we can be sure.  If you remove the IPv6 config,
does wpa_supplicant associate fine?  (could also be a different
tooling issue).

(b) does `ifconfig wlan0 list scan` show your AP when it doesn't?
If it doesn't that is more likely the problem.  And that remains a problem
for some conditions I am also facing.  More on 11a than 11g.

(c) Then the question is if wpa_supplicant blacklists the network;
`wpa_cli blacklist` would show.  If it does try the following sequence
to make it try more often:
CMD=wpa_cli
SSID=
${CMD} blacklist clear
${CMD} disable ${SSID}
${CMD} enable ${SSID}
${CMD} list_networks

(d) given you didn't say, what does `freebsd-version -r -u`
say, just to rule out you are missing the latest wpa fixes.

(e) what you can do is enable more wpa_supplicant logging; I often use
wpa_supplicant_flags="-sdd"  in /etc/rc.conf which will log to syslog instead
of the debug file but it'll increase debugging a lot (and warning, it
may also log keying material).

Bjoern

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Mon Aug  8 21:33:31 2022
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 4M1qFR3gG1z4YDRS;
	Mon,  8 Aug 2022 21:33:31 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M1qFR3FMtz3xn7;
	Mon,  8 Aug 2022 21:33:31 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1659994411;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=gXWe/CxpRoBpbu6t8DEMSob1zm2H86CyCB29WkrdZcY=;
	b=ApjfObVZwF0m58HvXMStRtakmI1rx9ZegfX4jaomPt0RSaj17p3tsTuTlKtv1QOrxW/M1w
	djic/MZbUhH6jn+TNaCw8lRn1vtkruE5zm/0nkdg3RtDGSJ0yMPKxrhQTD8xWtJpBu81FZ
	ny1WXoJ1sCiFQ3M1dsxauJKciVPXFIbMkE1Oaw8VYoh8X827selS+3BIUuRALxwCUuODbZ
	7CWCb+KFaUJBG+/9PvYdelPPe/AufuMfhKWASydbIMLpiHlyyfKU19S8Vof8iPbTYfADF/
	8f7VZrhMo6jlRTDqHhYkipJaCzliMQgdtLSKtpYbvdKPK+gCbrdVpvAY+lQCSA==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id 5D4AC13A44; Mon,  8 Aug 2022 21:33:31 +0000 (UTC)
Date: Mon, 8 Aug 2022 21:33:31 +0000
From: Lorenzo Salvadore 
To: freebsd-hackers@freebsd.org
Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org
Subject: FreeBSD Quarterly Status Report - Second Quarter 2022
Message-ID: 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline; filename="report.txt"
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1659994411;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=gXWe/CxpRoBpbu6t8DEMSob1zm2H86CyCB29WkrdZcY=;
	b=MLS4Zl+g/F2bikcHUsN2ggNZDUOEBE99himJeHJGQ3tZOUdiVDm1gnvx6zMQ9DCK+rZzkh
	G0+6O4OXKrg61Ij2msUopN3EwxsuK7rG7m3/MVICXneJBeb8SfIbiCdncB1YjNFVb2oNWl
	UL4Ghwz7X0jmiTlJSg3z0f6aDd07Z+NAq3ITXidpOxdcRlcRNgtHfq6q+Cx6l0PUlpx5TS
	x5Ff8mCehTIHbTgM9rNnR5w3+5zyK85ieFVAJllAoEoZ9E+8VgKiTqoL+8bLFSD4rrjkQU
	dSDNViWWXHZxwxc7d/uu3p7GhSVWDc+ggnojpv2EQ5ejUEHIRU7eR0jnrOLd+w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659994411; a=rsa-sha256; cv=none;
	b=aSLcxrkFLcHLrVzZ63kZq0VdVPyYvUbew1R0gnNNZbk5KZb9Z3YzM/JmFAtrgFGquvopvZ
	DE90Mox0r45Qjsyt85+1aA660RMG4lMzI/Srkrp0+eHlO8uViOogcmSrKjoy5553McLuFS
	v8f66xZRrjQI+WkbwpAK6v4A+cVdm9dVzdJAWIi/H0W3mEVAbvGutOpdxQ8S7mEdvBhRAu
	mpqnWRT7w86194Aa/3RHK3/bG2VPzD3aE/G4tm+UhHrzC/lQxzAz1/0AqXirghQmJh7EJp
	rp+f4X3KJjR/hjBRarmW7FhhHjIyjpfXwnpTUf6kRkVqf2tVxdF1vat141zdRg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

FreeBSD Quarterly Status Report Second Quarter 2022

Here is the second quarterly report of 2022, with 26 reports included.

This quarter the quarterly team managed to publish the report much faster and,
hopefully, with much fewer mistakes. If however you notice some errors, please
report them so that we can correct them and also add some automatic checks in
our tools to prevent them in the future and stay as efficient as possible in
the pubblication process.

We would also like to remind you that if for any reason you need more time to
submit a quarterly report, the team will wait for you, but please warn us so
that we are aware that some report is still missing.

Many thanks to all those that have chosen to share their work with the FreeBSD
community through the quarterly reports.

Lorenzo Salvadore, on behalf of the status report team.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

A rendered version of this report is available here:
https://www.freebsd.org/status/report-2022-04-2022-06/

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Table of Contents

  • FreeBSD Team Reports
      â–¡ FreeBSD Core Team
      â–¡ FreeBSD Foundation
      â–¡ FreeBSD Release Engineering Team
      â–¡ Cluster Administration Team
      â–¡ Continuous Integration
      â–¡ Ports Collection
  • Projects
      â–¡ Linux compatibility layer update
      â–¡ go on FreeBSD riscv64
      â–¡ FreeBSD on Microsoft HyperV and Azure
  • Userland
      â–¡ Ongoing work on LLDB multiprocess debugging support
      â–¡ ZFS support in makefs(8)
      â–¡ Base System OpenSSH Update
      â–¡ pf status update
  • Kernel
      â–¡ ENA FreeBSD Driver Update
      □ New Bluetooth® configuration daemon: blued
      â–¡ OpenVPN DCO
      â–¡ Wireless updates
      â–¡ Shared page address randomization
  • Architectures
      â–¡ NXP DPAA2 support
      â–¡ Medium-sized superpages on arm64 and beyond
  • Documentation
      â–¡ Documentation Engineering Team
  • Ports
      â–¡ KDE on FreeBSD
      â–¡ Elsewhere
      â–¡ GCC: updating GCC_DEFAULT and other improvements
      â–¡ Valgrind - Numerous bugfixes and updates for 13.1 / 14.0
      â–¡ Pantheon desktop on FreeBSD
      □ Feature Complete Port of Intel’s igt-gpu-tools

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the
Administration Page.

FreeBSD Core Team

Contact: FreeBSD Core Team 

The FreeBSD Core Team is the governing body of FreeBSD.

The twelfth FreeBSD Core Team was elected by active developers. The core.12
members are:

  • Baptiste Daroussin (bapt, incumbent)

  • Benedict Reuschling (bcr)

  • Ed Maste (emaste, incumbent)

  • Greg Lehey (grog)

  • John Baldwin (jhb)

  • Li-Wen Hsu (lwhsu)

  • Emmanuel Vadot (manu)

  • Tobias C. Berner (tcberner)

  • Mateusz Piotrowski (0mp)

On June 10th the outgoing core.11 and incoming core.12 teams held a handover
meeting, and the new Core Team was announced on Jun 18.

The current Core Team secretary, Muhammad Moinur Rahman (bofh), will step down
after the appointment of a new Core Team secretary and handover tasks
completes.

In this quarter, src commit bits of Kornel Dulęba (kd) and Dmitry Salychev
(dsl) have been approved.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

FreeBSD Foundation

Links:
FreeBSD Foundation URL: https://www.FreeBSDFoundation.org
Technology Roadmap URL: https://FreeBSDFoundation.org/blog/technology-roadmap/
Donate URL: https://www.FreeBSDFoundation.org/donate/
Foundation Partnership Program URL: https://www.FreeBSDFoundation.org/
FreeBSD-foundation-partnership-program
FreeBSD Journal URL: https://www.FreeBSDFoundation.org/journal/
Foundation News and Events URL: https://www.FreeBSDFoundation.org/
news-and-events/

Contact: Deb Goodkin 

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to
supporting and promoting the FreeBSD Project and community worldwide. Donations
from individuals and corporations are used to fund and manage software
development projects, conferences, and developer summits. We also provide
travel grants to FreeBSD contributors, purchase and support hardware to improve
and maintain FreeBSD infrastructure, and provide resources to improve security,
quality assurance, and release engineering efforts. We publish marketing
material to promote, educate, and advocate for the FreeBSD Project, facilitate
collaboration between commercial vendors and FreeBSD developers, and finally,
represent the FreeBSD Project in executing contracts, license agreements, and
other legal arrangements that require a recognized legal entity.

Fundraising Efforts

First, I’d like to send a big thank you to everyone who gave a financial
contribution to our efforts. We are 100% funded by your donations, so every
contribution helps us continue to support FreeBSD in many ways, including some
of the work funded and published in this status report.

Our goal this year is to raise at a minimum $1,400,000 towards a spending
budget of around $2,000,000. As I write this report, we’ve brought in under
$200,000 towards that goal. So, we obviously need to step up our effort of
fundraising. It’s by far the hardest part of my job. I’d much prefer talking to
folks in our community on how we can help you, help create content to recruit
more users and contributors to the Project, and understand challenges and
painpoints that individuals and organizations have in using FreeBSD, so we can
help improve those areas. Asking for money is not on that list.

We support FreeBSD in five main areas. Software development is the largest area
we fund with six software developers on staff who step in to implement new
features, support tier 1 platforms, review patches, and fix issues. You can
find out some of the work we did under OS Improvements in this report. FreeBSD
Advocacy is another area that we support to spread the word about FreeBSD at
conferences, in presentations online and in-person, tutorials and how-to
guides. We purchase and support hardware for the FreeBSD infrastructure that
supports the work going on in the Project. Virtual and in-person events are
organized by the Foundation to help connect and engage community members to
share their knowledge and collaborate on projects. Finally, we provide legal
support to the Project when needed and protect the FreeBSD trademarks.

If you haven’t made a donation this year, please consider making one at https:/
/freebsdfoundation.org/donate/.

We also have a Partnership Program for larger commercial donors. You can find
out more at https://freebsdfoundation.org/our-donors/
freebsd-foundation-partnership-program/

OS Improvements

During the second quarter of 2022, 243 src, 62 ports, and 12 doc tree commits
were made that identified The FreeBSD Foundation as a sponsor. This represents
10.6, 0.7, and 4.5% of the total number of commits to each repository.

Sponsored Work

You can read about some of the Foundation-sponsored work in individual
quarterly report entries.

  • Base System OpenSSH Update

  • Ongoing work on LLDB multiprocess debugging support

  • Wireless Status

  • ZFS support in makefs

Other ongoing sponsored work is described here.

  • FreeBSD Wireguard Improvements

    The aim of the Wireguard project is to improve support for the FreeBSD Wirguard kernel module.
    The work by John Baldwin involved adapting the module to use FreeBSD's OCF rather than Wireguard's internal implementations.
    It also involved adding new ciphers and API support.
    The latest upstream release incorporates this work.

  • Openstack on FreeBSD

    OpenStack is a cloud system for different types of resources like virtual machines.
    However, OpenStack only unofficially supports FreeBSD as a guest system.
    That means users can spawn FreeBSD instances on the open cloud platform, but it is not currently possible run OpenStack on FreeBSD hosts.
    The goal of this project is port OpenStack components so that FreeBSD can function as an OpenStack host.

  • Bhyve Issue Support

    The Foundation recently signed a new contract for Byhve support.
    This contract will allow John Baldwin to dedicate time to Bhyve as issues arise, especially security issues.

  • Handbook Improvement Exploration

    Under sponsorship from the Foundation, Pau Amma wrapped up a mini-project to explore how the Handbook can be improved.
    A survey was sent out and the results will be shared soon.

Continuous Integration and Quality Assurance

The Foundation provides a full-time staff member and funds projects to improve
continuous integration, automated testing, and overall quality assurance
efforts for the FreeBSD project.

Supporting FreeBSD Infrastructure

The Foundation provides hardware and support for the Project. A new Australian
mirror was brought online by the Cluster Administration team. If you are a
FreeBSD user in Oceania or southeast Asia, please let us know if download
speeds for installer images and packages has improved.

With your donations, the Foundation purchased new hardware to repair two
PowerPC package builders, one for little endian packages (powerpc64le) and the
second for big endian packages (powerpc64, powerpc). The new hardware just
arrived at the data center and will be installed soon. Expect lots of PowerPC
packages in the near future.

FreeBSD Advocacy and Education

Much of our effort is dedicated to Project advocacy. This may involve
highlighting interesting FreeBSD work, producing literature and video
tutorials, attending events, or giving presentations. The goal of the
literature we produce is to teach people FreeBSD basics and help make their
path to adoption or contribution easier. Other than attending and presenting at
events, we encourage and help community members run their own FreeBSD events,
give presentations, or staff FreeBSD tables.

The FreeBSD Foundation sponsors many conferences, events, and summits around
the globe. These events can be BSD-related, open source, or technology events
geared towards underrepresented groups. We support the FreeBSD-focused events
to help provide a venue for sharing knowledge, working together on projects,
and facilitating collaboration between developers and commercial users. This
all helps provide a healthy ecosystem. We support the non-FreeBSD events to
promote and raise awareness of FreeBSD, to increase the use of FreeBSD in
different applications, and to recruit more contributors to the Project. We are
continuing to attend virtual events and planning the June 2022 Developer
Summit. In addition to attending and planning virtual events, we are
continually working on new training initiatives and updating our selection of
how-to guides to facilitate getting more folks to try out FreeBSD.

Check out some of the advocacy and education work we did last quarter:

  • Secured our booth and nonprofit sponsor status for All Things Open, October
    30-November 2, 2022, Raleigh, NC.

  • Finalized our booth and workshop at Scale 19x in Los Angeles, CA on July
    28-30. The FreeBSD workshop will be held Friday,Jul 29, 2022 and you can
    visit the Foundation at booth 502.

  • Confirmed our Silver Sponsorship of EuroBSDcon 2022, September 15-18,
    Vienna, Austria

  • Sponsored and helped organize the June 2022 FreeBSD Developer Summit, June
    16-17, 2022. Videos are available on the FreeBSD Project YouTube channel.

  • Celebrated FreeBSD Day June 19, 2022 and throughout the following week.

  • Secured our Friends level sponsorship of COSCUP, July30-31, Taiwan

  • Published the FreeBSD Foundation Spring 2022 Update

  • New Blog Posts

      □ Let’s Talk About Foundation Funding

      â–¡ New Board Member Interview: Cat Allman

      â–¡ Welcome FreeBSD Google Summer of Code Participants

      â–¡ FreeBSD Foundation Work in the 13.1 Release

      â–¡ Foundation Elects New Officers, Interviews Outgoing Board Members

      â–¡ Help Us Celebrate FreeBSD Day All Week Long

  • New and Updated How-To and Quick Guides:

      â–¡ Networking Basics: WiFi and Bluetooth

      â–¡ Audio on FreeBSD

      â–¡ Installing FreeBSD with VirtualBox (Mac/Windows) - Video Guide

      â–¡ An Introduction to the FreeBSD Operating System - Video Guide

      â–¡ Installing a Desktop Environment on FreeBSD - Video Guide

      â–¡ Installing a Port on FreeBSD - Video Guide

We help educate the world about FreeBSD by publishing the professionally
produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is
now a free publication. Find out more and access the latest issues at https://
www.FreeBSDfoundation.org/journal/.

You can find out more about events we attended and upcoming events at https://
www.FreeBSDfoundation.org/news-and-events/.

Legal/FreeBSD IP

The Foundation owns the FreeBSD trademarks, and it is our responsibility to
protect them. We also provide legal support for the core team to investigate
questions that arise.

Go to https://www.FreeBSDFoundation.org to find more about how we support
FreeBSD and how we can help you!

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

FreeBSD Release Engineering Team

Links:
FreeBSD 13.1-RELEASE schedule URL: https://www.freebsd.org/releases/13.1R/
schedule/
FreeBSD 13.1-RELEASE announcement URL: https://www.freebsd.org/releases/13.1R/
announce/
FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/
FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/
ISO-IMAGES/

Contact: FreeBSD Release Engineering Team, 

The FreeBSD Release Engineering Team is responsible for setting and publishing
release schedules for official project releases of FreeBSD, announcing code
freezes and maintaining the respective branches, among other things.

During the second quarter of 2022, the Release Engineering Team completed work
on the 13.1-RELEASE cycle. This is the second release from the stable/13
branch. Throughout the release cycle, three BETA builds and six RC (release
candidate) builds have occurred, moving the final release date from April 21,
2022 to May 16, 2022, as some last-minute issues were identified.

We thank all FreeBSD developers and contributors for testing the 13.1-RELEASE,
reporting problems, and being diligent with proprosed changes as the cycle
progressed.

Additionally throughout the quarter, several development snapshots builds were
released for the main, stable/13, and stable/12 branches.

Sponsor: Rubicon Communications, LLC ("Netgate") Sponsor: The FreeBSD
Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Cluster Administration Team

Links:
Cluster Administration Team members URL: https://www.freebsd.org/administration
/#t-clusteradm

Contact: Cluster Administration Team 

FreeBSD Cluster Administration Team members are responsible for managing the
machines the Project relies on to synchronise its distributed work and
communications. In this quarter, the team has worked on the following:

  • Installed a new mirror in Sydney, Australia hosted by IX Australia

  • Fixed CI cluster hardware failure

  • Set up a new internal monitoring system

  • Regular cluster-wide software upgrades

  • Regular support for FreeBSD.org user accounts

Work in progress:

  • Work with the PowerPC team to improve the package builders, universal, and
    reference machines.

  • Plan Hardware refresh, and fixing misc failures in each sites

  • Improve the package building infrastructure

  • Review the service jails and service administrators operation

  • Working with doceng@ to improve deployment of https://www.freebsd.org and
    https://docs.freebsd.org

  • Improve the web service architecture

  • Improve the cluster backup plan

  • Improve the log analysis system

We are looking for an additional full mirror site (five servers) in Europe. See
generic mirrored layout for our needs. Offers of additional single-server
mirrors (see tiny mirror) are always welcome too, especially in Europe.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Continuous Integration

Links:
FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org
FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org
FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins
Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI
3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI
Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg
FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci
dev-ci Mailing List URL: https://lists.freebsd.org/subscription/dev-ci

Contact: Jenkins Admin 
Contact: Li-Wen Hsu 
Contact: freebsd-testing Mailing List
Contact: IRC #freebsd-ci channel on EFNet

The FreeBSD CI team maintains the continuous integration system of the FreeBSD
project. The CI system checks the committed changes can be successfully built,
then performs various tests and analysis over the newly built results. The
artifacts from those builds are archived in the artifact server for further
testing and debugging needs. The CI team members examine the failing builds and
unstable tests and work with the experts in that area to fix the code or adjust
test infrastructure.

During the second quarter of 2022, we continued working with the contributors
and developers in the project to fulfill their testing needs and also keep
collaborating with external projects and companies to improve their products
and FreeBSD.

Important completed tasks:

  • Fixed the hardware failure issue of the CI cluster

Work in progress tasks:

  • Designing and implementing pre-commit CI building and testing (to support
    the workflow working group)

  • Designing and implementing use of CI cluster to build release artifacts as
    release engineering does

  • Testing and merging pull requests in the FreeBSD-ci repo

  • Simplifying CI/test environment setting up for contributors and developers

  • Setting up the CI stage environment and putting the experimental jobs on it

  • Organizing the scripts in freebsd-ci repository to prepare for merging to
    src repository

  • Updating documents on wiki

Open or queued tasks:

  • Collecting and sorting CI tasks and ideas

  • Setting up public network access for the VM guest running tests

  • Implementing use of bare-metal hardware to run test suites

  • Adding drm ports building tests against -CURRENT

  • Planning to run ztest tests

  • Adding more external toolchain related jobs

  • Improving maturity of the hardware lab and adding more hardware for testing

  • Helping more software get FreeBSD support in its CI pipeline (Wiki pages:
    3rdPartySoftwareCI, HostedCI)

  • Working with hosted CI providers to have better FreeBSD support

Please see freebsd-testing@ related tickets for more WIP information, and don’t
hesitate to join the effort!

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Ports Collection

Links:
About FreeBSD Ports URL:https://www.FreeBSD.org/ports/
Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#
ports-contributing
FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/
Ports Management Team URL: https://www.freebsd.org/portmgr/
Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/

Contact: René Ladan 
Contact: FreeBSD Ports Management Team 

The Ports Management Team is responsible for overseeing the overall direction
of the Ports Tree, building packages, and personnel matters. Below is what
happened in the last quarter.

The number of ports is slightly above 30,000. The last quarter saw 9,137
commits by 151 committers on the "main" and 589 commits by 61 committers on the
"2022Q2" branch. At the time of writing, there are 2,700 open ports PRs of
which 682 are unassigned. Compared to the previous quarter, there was a slight
decrease in commit activity and a constant number of PRs. Note: Freshports
appears to overcount substantially. This quarter’s ports count was derived
differently and is not comparable with the previous quarter’s.

During the last quarter, portmgr welcomed back salvadore@ but also said goodbye
to seven ports committers due to lack of activity.

In its bi-weekly meetings, portmgr discussed the following topics: * the future
of ca_root_nss * feasibility of the base system providing certain .pc files *
ways to deal with incompatibilities in kernel module ports on minor version
upgrades of the base system

Following a discussion among developers, portmgr decided to grant all
documentation and source committers approval to fix any documentation-related
error in the Ports Tree which does not affect its functionality.

The following changes were made to the Ports Tree during 2022q2: * pkg got
updated to version 1.18.3, Firefox to version 102.0 and Chromium to version
103.0.50060.53 * Default versions of GCC, Lazarus, Python and Ruby got updated
to respectively 11 (powerpcspe keeps version 8), 2.2.2, 3.9, and 3.0. * Two new
USES were added, gstreamer to support ports based on GStreamer plugins and
pytest to help testing with pytest.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Projects

Projects that span multiple categories, from the kernel and userspace to the
Ports Collection or external projects.

Linux compatibility layer update

Contact: Dmitry Chagin  Contact: Edward Tomasz Napierala <
trasz@FreeBSD.org>

The goal of this project is to improve FreeBSD’s ability to execute unmodified
Linux binaries. Current support status of specific Linux applications is being
tracked at the Linux app status Wiki page.

Implementation of the Y2k38 Linux project is mostly finished; all '*_time64()'
system calls are committed.

The state of the arm64 Linux emulation layer was brought to the state of the
amd64 Linux emulation layer: i.e., implemented the vDSO, machine dependend
futexes, signals delivery.

The thread affinity system calls were modified to implement Linux semantics.

In total, over 50 bugs were fixed; glibc-2.35 tests suite reports less than 80
failed tests.

All changes in the Linux emulation layer are merged to the stable/13 branch.

Initial support for fancy Linux system call tracing has been added to
libsysdecode and kdump. There is ongoing work to make tracing more syscalls
work.

Sponsor: EPSRC (Edward’s work)

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

go on FreeBSD riscv64

Links:
golang Home Page URL: https://github.com/golang/go
FreeBSD riscv64 github repo URL: https://github.com/MikaelUrankar/go/tree/
freebsd_riscv64
FreeBSD riscv64 golang issue URL: https://github.com/golang/go/issues/53466

Contact: Mikaël Urankar 
Contact: Dmitri Goutnik 

Work has been done to port go on FreeBSD riscv64 which builds and passes all
run.bash tests, including cgo (tested under QEMU and on Unmatched). A pull
request is created upstream and the proposal has been added to the active
column of the proposals project and will be reviewed at the weekly proposal
review meetings.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

FreeBSD on Microsoft HyperV and Azure

Links:
Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/
MicrosoftAzure
Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV

Contact: Microsoft FreeBSD Integration Services Team 
Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team 
Contact: Wei Hu 
Contact: Li-Wen Hsu 

The 13.1-RELEASE image on Azure Marketplace has been published.

Work in progress tasks:

  • Automating the image building and publishing process

  • Building and publishing ZFS-based images to Azure Marketplace

      â–¡ The taks will be benefited by merging of ZFS support of makefs(8) and
        release(7)

          ☆ https://reviews.freebsd.org/D23334

          ☆ https://reviews.freebsd.org/D34426

          ☆ https://reviews.freebsd.org/D35248

  • Building and publishing Hyper-V gen2 VM images to Azure Marketplace

      â–¡ Blocked by https://bugs.freebsd.org/264267

The above tasks are sponsored by The FreeBSD Foundation, with resources
provided by Microsoft.

Wei Hu and his colleagues in Microsoft are working on several tasks sponsored
by Microsoft:

  • Fixing booting issue on Hyper-V gen2 VM in Azure

      â–¡ https://bugs.freebsd.org/264267

  • Porting Hyper-V guest support to aarch64

Open tasks:

  • Update FreeBSD related doc at https://docs.microsoft.com

  • Support FreeBSD in Azure Pipelines

  • Update Azure agent port to the latest version

  • Upstream local modifications of Azure agent

Sponsor: Microsoft for work by Wei Hu and others in Microsoft, and for
resources for the rest Sponsor: The FreeBSD Foundation for everything else

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Userland

Changes affecting the base system and programs in it.

Ongoing work on LLDB multiprocess debugging support

Links:
Moritz Systems Project Description URL: https://www.moritz.systems/blog/
multiprocess-support-for-lldb/
Progress Report 1 URL: https://www.moritz.systems/blog/
implementing-non-stop-protocol-compatibility-in-lldb/

Contact: Kamil Rytarowski 
Contact: Michał Górny 

According to the upstream description, "LLDB is a next generation,
high-performance debugger. It is built as a set of reusable components which
highly leverage existing libraries in the larger LLVM Project, such as the
Clang expression parser and LLVM disassembler."

FreeBSD includes LLDB in the base system. The previous sponsored projects
improved LLDB, to make it a credible debugger for the base system, although it
still has a few limitations compared to the contemporary versions of GNU GDB.
This project started in April 2022. It aims to implement full support for
debugging multiple processes simultaneously.

At the start of the project, LLDB featured very limited support for
multiprocess debugging. The client featured support for debugging multiple
independent processes simultaneously via maintaining multiple connections to
different server instances. Thanks to our earlier work, the server was able to
process fork(2) and vfork(2) calls and either detach the newly forked child and
continue tracing the parent process, or detach the parent and follow the child
(equivalent to GDB’s follow-fork-mode setting).

Once the project is finished, LLDB will be able to trace an arbitrary number of
forked processes simultaneously (equivalent to GDB’s detach-on-fork off). Full
support for the multiprocess extension to the GDB Remote Serial Protocol will
be implemented, as well as partial support for the non-stop extension that will
enable multiple processes to be resumed and stopped independently.

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

ZFS support in makefs(8)

Links:
Mailing list post URL: https://lists.freebsd.org/archives/freebsd-hackers/
2022-May/001128.html
makefs(8) code review URL: link:https://reviews.freebsd.org/D35248 release(7)
code review URL: link:https://reviews.freebsd.org/D34426

Contact: Mark Johnston 

makefs(8) is a utility, originating in NetBSD, that creates file system images
entirely in userspace. It is a useful component of a toolchain to build virtual
machine (VM) images since it does not require any special privileges, unlike
the approach of formatting a character device, mounting the fresh file system,
and copying files onto it. Moreover, makefs can create reproducible images and
aims to minimize resource consumption. Currently, FreeBSD’s makefs can build
UFS, cd9660, and msdos (FAT) file system images.

Recent work enables the creation of ZFS images by makefs. This makes it easier
to build ZFS-based VM images. makefs' ZFS support includes the ability to
create multiple datasets, with each mapped to a directory in the input file
hierarchy. Many ZFS features are not supported however, as the implementation
provides only what is needed to get reproducible root pools.

Follow-up work enables the creation of ZFS-based VM and cloud images by the
release(7) framework, using this new makefs extension.

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Base System OpenSSH Update

Links:
OpenSSH URL: https://www.openssh.com/
OpenSSH 8.9 release notes URL:https://www.openssh.com/txt/release-8.9[https://
www.openssh.com/txt/release-8.9]
OpenSSH 9.0 release notes URL:https://www.openssh.com/txt/release-9.0[https://
www.openssh.com/txt/release-9.0]

Contact: Ed Maste 

OpenSSH, a suite of remote login and file transfer tools, was updated from
version 8.8p1 to 9.0p1 in the FreeBSD base system.

It has not yet been merged to the stable/13 and stable/12 branches. I
anticipate doing so in July.

NOTE: OpenSSH 9.0p1 switches scp(1) from using the legacy scp/rcp protocol to
using the SFTP protocol by default. The -O flag is available to use the
previous protocol instead.

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

pf status update

Contact: Kristof Provost  Contact: Reid Linnemann <
rlinnemann@netgate.com>

Ethernet

pf recently grew support for filtering on Ethernet layer. See the 2021q2
pf_ethernet report.

Since then the Ethernet layer filtering has been extended with:

  • anchor support

  • ability to look into the layer 3 header, for matching with source/
    destination IP(v4/v6) addresses

  • table support for IP address matching

  • direct dispatch to dummynet

  • pass Ethernet layer packets directly to dummynet, rather than tagging the
    packets and relying on layer 3 to handle dummynet

Dummynet

pf recently started being able to use dummynet for packet scheduling. This
support has been extended and improved, and is now believed to be ready for
production.

One notable fix is that reply-to/route-to’d traffic is now subject to dummynet
scheduling as well.

Last match timestamp

pf now tracks when a rule was last matched. Similar to ipfw rule timestamps,
these timestamps internally are uint32_t snaps of the system "wall time" clock
in seconds. (See time(9).) The timestamp is CPU local and updated each time a
rule or a state is matched.

Sponsor: Rubicon Communications, LLC ("Netgate")

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Kernel

Updates to kernel subsystems/features, driver support, filesystems, and more.

ENA FreeBSD Driver Update

Links:
ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/
ena/README.rst

Contact: Michal Krawczyk 
Contact: Dawid Gorecki 
Contact: Marcin Wojtas 

ENA (Elastic Network Adapter) is the smart NIC available in the virtualized
environment of Amazon Web Services (AWS). The ENA driver supports multiple
transmit and receive queues and can handle up to 100 Gb/s of network traffic,
depending on the instance type on which it is used.

Completed since the last update:

  • Upstream of the ENA driver v2.5.0, which included:

  • Improvement to the reset routine handling,

  • Extension of the timer service lifetime in order to be able to detect more
    hardware failures,

  • Fix logic for verifying the Tx request ID,

  • Fix IPv6 L4 checksum offload handling for the Tx,

  • Add NUMA awareness to the driver.

  • Internal review of the upcoming ENA driver release (v2.6.0), including:

  • Further reset handling improvements,

  • Code cleanup and style fixes,

  • Logging improvements,

  • Fix to the retrieval of the ENI metrics.

Work in progress:

  • Testing of the upcoming ENA driver release (v2.6.0).

Sponsor: Amazon.com Inc

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

New Bluetooth® configuration daemon: blued

Links:
blued git URL: https://git.lysator.liu.se/kempe/blued

Contact:
Mail: kempe@lysator.liu.se
IRC: kempe@libera.chat

Introduction

The blued utility provides an IPC interface that lets an unprivileged user
connect to and use Bluetooth devices in a user-friendly way and supports secure
simple pairing (public-key cryptography and if the device allows it
man-in-the-middle protection).

What is blued?

There are three parts to blued: a library, a daemon and a command line utility.
The library abstracts away bluetooth details, the daemon manages Bluetooth
devices and the command line utility lets users list or scan for Bluetooth
devices, pair with a device, or unpair from one. The command line utility
communicates with the daemon via a UNIX socket.

Unlike bthidd and hcsecd, blued supports secure simple pairing and provides an
IPC. To get a HID device to work, bthidd is still needed. A script is provided
to pair a Bluetooth device and appropriately configure bthidd so it just works
and reconnects without user intervention.

Once pairing has proven stable and bugs have been ironed out, the plan is to
integrate bthidd with/into blued in some way to have HID devices automatically
start functioning when paired without the use of an external script. A
long-term goal is to provide a graphical user interface that can list devices
and provide a simple one-click setup to connect them.

Installing and using blued v0.1

You need the optional src component installed in /etc/src.

First, make sure you have working Bluetooth drivers loaded as explained in the
FreeBSD handbook.

To test blued, fetch the blued v0.1 source code. Then compile it, patch your
FreeBSD kernel with the patches in kernel_patches, and recompile the hci module
as explained in README.

I have primarily tested blued on FreeBSD 12.3, but my patches applied cleanly
on 13.1 when I tested. I am not supplying a port at the moment, but it is
possible to run the software straight from the build directory or run "make
install" that will install all needed files. Both blued and bluecontrol use
capsicum and blued can be configured to drop its root privileges.

For more information, refer to the Running blued section of README.

Helping out

Testing

I have only tried this software with my own mouse and realise that a sample
size of one single bluetooth device is pretty small. I’m expecting issues and
am greatly looking forward to feedback from others!

In case of trouble, output from /var/log/debug.log and /var/log/messages as
well as a traffic dump from "hcidump -x" while trying to pair will help with
troubleshooting.

Contributing

If you want to get involved with the code and submit patches, you’re welcome to
visit the repository on Lysator’s Git.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

OpenVPN DCO

Links:
D34340 URL: D34340
OpenVPN wiki URL: OpenVPN wiki

Contact: Kristof Provost 

OpenVPN DCO (or Data Channel Offload) moves OpenVPN data packet processing into
the kernel.

Traditionally OpenVPN uses a tun(4) interface to transmit and receive packets.
In this setup received packets are received by the kernel, passed to the
OpenVPN application for decryption, then passed back into the kernel for
network stack processing. This requires several transitions between kernel- and
userspace, and naturally imposes a performance cost.

The new if_ovpn OpenVPN DCO offload driver performs the encryption/decryption
entirely within the kernel, improving performance.

Initial performance testing shows throughput improved from around 660Mbit/s to
around 2Gbit/s.

The userspace OpenVPN code also requires modification to use the new if_ovpn
offload driver. This is expected to be part of a future 2.6.0 OpenVPN release.

Sponsor: Rubicon Communications, LLC ("Netgate")

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Wireless updates

Links:
Intel iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/
Iwlwifi Realtek rtw88 status FreeBSD wiki page URL: https://wiki.freebsd.org/
WiFi/Rtw88 Realtek rtw89 status FreeBSD wiki page URL: https://wiki.freebsd.org
/WiFi/Rtw89

Contact: Bjoern A. Zeeb 

The overall project aims to bring support for newer chipsets to FreeBSD
currently using LinuxKPI compat code backed by native net80211 and kernel code.
In addition the aim is to continue work towards supporting newer wireless
standards. During the second quarter 40 commits went into FreeBSD CURRENT. With
more users trying multiple drivers support time has also gone up.

An earlier version of the Intel iwlwifi-derived wireless driver shipped in
13.1-RELEASE bringing this work into a first FreeBSD release. The iwlwifi
driver and firmware were since updated in CURRENT and stable/13 again as part
of ongoing development. Changes in files shared with the upstream Intel Linux
version of the driver are now less than 400 lines. Lately a longer-standing
problem for older chipsets was (hopefully) solved allowing iwm(4)-supported
cards to work with iwlwifi(4) again after almost three months. The main focus
for the project until the end of the year will most exclusively be getting us
to contemporary speeds.

On April 1st, using the same LinuxKPI infrastructure built mostly with the
iwlwifi work, Realtek’s rtw88(4) driver got comitted into CURRENT. Due to an
issue with DMA the next weeks a workaround was developed and put into the tree
so users no longer have to patch the kernel. The driver still needs a tunable
set in loader.conf for machines with more than 4GB of physical memory. This
tunable allowed the driver to be merged to stable/13 in June followed by
further updates in CURRENT and stable/13. As the USB parts for rtw88 based
chipsets are prepared to be included in Linux, work has started (needing more
time) to prepare FreeBSD to be able to support the USB parts as well.

During the last months Realtek’s rtw89 has already been compiling and remains a
work in progress to run stably and associate before it can be enabled in
CURRENT.

Thanks to all the users for testing and reporting back, patiently waiting for
the next update, bugfix, or just a reply from me. It is a great pleasure to
work with you! Keep sending the bug reports to me, but remember that your
thanks should go to the FreeBSD Foundation for making most of this possible.

For the latest state of the development, please follow the freebsd-wireless
mailing list and check the wiki pages.

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Shared page address randomization

Links:
D35392 D35393 D35349

Contact: Kornel Duleba 
Contact: Marcin Wojtas 

The shared page is an R/X page that is mapped into each process by the image
activator. It stores the signal trampoline, as well as other metadata e.g.
information needed to implement user space timecounters. Previously it was
mapped at the top of the process virtual address space. With the described
changes its address will be randomized. We plan to turn the feature on by
default for 64bit binaries, across all architectures. Currently the patches are
under review and await approval.

Sponsor: Stormshield

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Architectures

Updating platform-specific features and bringing in support for the new
hardware platform.

NXP DPAA2 support

Links
Change history
Tree

Contact: Dmitry Salychev 
Contact: Bjoern A. Zeeb 

Some of the NXP SoCs (LX2160A, LS1088A) are shipped with DPAA2, the second
generation of the data path acceleration architecture. It allows to dynamically
configure and wire packet processing "objects" (DPNI for a network interface,
DPMAC for media access controller, etc.) together to form a network-on-a-chip.

During the last quarter the driver started working well enough to be used on
SolidRun' Honeycomb LX2 (ACPI test platform) and Traverse Technologies has
produced a FreeBSD preview for (their) Ten64 (used as FDT test platform).

The driver is still work-in-progress, but is getting close for a review to get
the first version into the tree for everyone to benefit from it.

WIP:

  • FDT MDIO support. FreeBSD currently lacks support for the SPF parts.

  • Driver resources de-allocation to unload dpaa2.ko properly.

  • Bug fixes and improvements.

TODO:

  • CPU affinity for DPIOs and DPNIs.

  • Cached memory-backed software portals.

  • Bottlenecks mitigation.

  • Further parts (DPSW, DCE, etc.) supported by the hardware.

Sponsor: Bare Enthusiasm :)
Sponsor: Traverse Technologies (providing Ten64 HW for testing)

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Medium-sized superpages on arm64 and beyond

Contact: Eliot H. Solomon 
Contact: Alan L. Cox 

The 64-bit ARM architecture’s page table descriptor format contains a flag
called the Contiguous bit. This tells the MMU that it can cache an aligned,
physically contiguous group of 16 page table entries which have identical
permissions and attributes using only 1 TLB entry.

The Contiguous bit, as well as the conceptually similar Svnapot extension to
the RISC-V architecture, allows for the use of 64 KiB superpages. These
medium-sized superpages can bring to smaller memory objects the
address-translation speedup typically associated with more traditional 2 MiB
superpages.

This project focuses on bringing support for medium-sized superpages to
FreeBSD. So far, we have modified the arm64 pmap code to automatically utilize
64 KiB superpages by detecting physically contiguous page table entries and
promoting them using the Contiguous bit. Now, we are working to adapt the
kernel’s superpage reservation module to support 64 KiB reservations in
addition to the current 2 MiB ones. Adding medium-sized reservations will allow
the virtual memory system to explicitly allocate pieces of memory which fit the
requirements for superpage promotion, rather than just hoping that they occur
by chance.

Our goal is to accomplish this in a general way that makes it possible to
specify multiple arbitrary power-of-two reservation sizes, making it easier to
take advantage of hardware features on other architectures like Ryzen’s PTE
Coalescing, which transparently merges groups of 4 KiB page table entries into
medium-sized superpages.

Sponsor: Department of Computer Science, Rice University

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Documentation

Noteworthy changes in the documentation tree, manual pages, or new external
books/documents.

Documentation Engineering Team

Link: FreeBSD Documentation Project
Link: FreeBSD Documentation Project Primer for New Contributors
Link: Documentation Engineering Team

Contact: FreeBSD Doceng Team 

The doceng@ team is a body to handle some of the meta-project issues associated
with the FreeBSD Documentation Project; for more information, see FreeBSD
Doceng Team Charter.

During the last quarter, Graham Perrin (grahamperrin@) and Pau Amma (pauamma@),
were granted documentation commit bits.

Several items are pending and in discussion:

  • Mirroring the Website and Documentation portal with the GeoDNS
    infrastructure of the project.

  • How to handle Trademarks in the documentation.

  • Remove outdated translations from the Website and Documentation portal.

FreeBSD Translations on Weblate

Link: Translate FreeBSD on Weblate
Link: FreeBSD Weblate Instance

Q2 2022 Status

  • 12 languages

  • 152 registered users (9 new users)

Languages

  • Chinese (Simplified) (zh-cn)

  • Chinese (Traditional) (zh-tw)

  • Dutch (nl)

  • French (fr)

  • German (de)

  • Indonesian (id)

  • Italian (it)

  • Norwegian (nb-no)

  • Persian (fa-ir)

  • Portuguese (pt-br)

  • Spanish (es)

  • Turkish (tr)

We want to thank everyone that contributed, translating or reviewing documents.

And please, help promote this effort on your local user group, we always need
more volunteers.

FreeBSD Website Revamp - WebApps working group

Contact: Sergio Carlavilla 

Working group in charge of creating the new FreeBSD Documentation Portal and
redesigning the FreeBSD main website and its components. FreeBSD developers can
follow and join the working group on the FreeBSD Slack channel #wg-www21. The
work will be divided into four phases:

 1. Redesign of the Documentation Portal

    Create a new design, responsive and with global search. (Complete)

 2. Redesign of the Manual Pages on web

    Scripts to generate the HTML pages using mandoc. (Work in progress)

 3. Redesign of the Ports page on web

    Ports scripts to create an applications portal. (Work in progress)

 4. Redesign of the FreeBSD main website

    New design, responsive and dark theme. (Not started)

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Ports

Changes affecting the Ports Collection, whether sweeping changes that touch
most of the tree, or individual ports themselves.

KDE on FreeBSD

Links:
KDE FreeBSD URL: https://freebsd.kde.org/
KDE Community FreeBSD URL: https://community.kde.org/FreeBSD

Contact: Adriaan de Groot 

The KDE on FreeBSD project packages the software from the KDE Community, along
with dependencies and related software, for the FreeBSD ports tree. The
software includes a full desktop environment called KDE Plasma (for both X11
and Wayland) and hundreds of applications that can be used on any FreeBSD
machine.

The KDE team (kde@) is part of desktop@ and x11@ as well, building the software
stack to make FreeBSD beautiful and usable as a daily-driver graphics-based
desktop machine. The notes below describe mostly ports for KDE, but also
include items of import to the entire desktop stack.

KDE Stack

KDE Gear releases happen each quarter, KDE Plasma updates once a month, and KDE
Frameworks have a new release each month as well. These (large) updates land
shortly after their upstream release and are not listed separately.

  • astro/kstars latest release 3.5.9.

  • deskutils/grantleetheme got an entry in UPDATING because of some unusual
    changes to the installed structure of the port.

  • deskutils/kalendar joined the KDE Gear releases.

  • devel/okteta updates to the binary (and octal and hexadecimal) data viewer
    and editor.

  • finance/kraft needed specific build-fixes for newer KDE Frameworks.

  • games/gcompris-qt expanded, new releases, and now supports more image
    formats (needed for some activities).

  • graphics/digikam no longer needs a SQL server during the build.

  • graphics/krita was updated to 5.0.5, likely the last 5.0 version.

  • math/labplot has a huge number of new features in recent releases, well
    worth looking at if you need any kind of data-plotting.

  • net-im/ruqola was updated. This is a Qt-styled Rocket chat application.

  • www/falkon joined the KDE Gear releases.

Related Applications

  • archivers/quazip was updated.

  • deskutils/semantik updated.

  • devel/py-qt5-pyqt updated so that the port now pulls in DBus as well. DBus
    is needed by nearly all desktop Qt applications, including those written in
    Python.

  • devel/qcoro had build issues on certain FreeBSD versions, resolved.

  • devel/qtcreator updated with each new release.

  • devel/qt5 had its infrastructure updated in ports so it does not produce
    strange error messages during de-installation.

  • graphics/ksnip and related libraries updated to recent releases.

  • Matrix clients Nheko (net-im/nheko) and Neochat (net-im/neochat) were
    updated following releases and library bumps.

  • x11/rsibreak updated; helps prevent injury while writing long quarterly
    reports.

Elsewhere

  • devel/appstream update supports more application-information.

  • devel/cmake prefers generic python3 over versioned-python3, if users have
    multiple python3 ports and lang/python3 installed.

  • devel/dbus updated.

  • graphics/poppler updated several times.

  • graphics/ImageMagick (both 6 and 7) updated several times.

  • multimedia/gstreamer updated.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

GCC: updating GCC_DEFAULT and other improvements

Links:
GCC Project URL: https://gcc.gnu.org
GCC 11 release series URL: https://gcc.gnu.org/gcc-11/

Contact: 
Contact: Gerald Pfeifer 
Contact: Lorenzo Salvadore 
Contact: Piotr Kubaj 

  • salvadore@ worked on the upgrade of GCC_DEFAULT in Mk/
    bsd.default-versions.mk from 10 to 11, opening bug reports based on
    antoine@'s exp-runs and fixing some: many thanks to all those that helped
    with this task. The GCC_DEFAULT update from GCC 10 to GCC 11 has now been
    committed by gerald@ and happened in time for the next quarterly branch.
    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258378

  • pkubaj@ switched GCC bootstrapping to use Link Time Optimization for GCC
    itself for GCC 11 and newer by introducing a new option enabled by default.
    Building with LTO_BOOTSTRAP enabled requires significant amounts of memory
    and time. How much resources are actually needed depends on your
    configuration (e.g. are you building from ports or with poudriere? What is
    your architecture?). To give an idea, a user reported needing 5 GiB of
    tmpfs, while in PR 265254 a need of about 130 GB of memory is estimated due
    to an excessive amount of processes spawning (see also https://gcc.gnu.org/
    bugzilla/show_bug.cgi?id=106328). Consider disabling LTO_BOOTSTRAP in favor
    of STANDARD_BOOTSTRAP (or disabling BOOTSTRAP altogether) in case that is a
    problem.

  • pkubaj@ also added lang/gcc12 and lang/gcc13-devel ports and updated lang/
    gcc9 to 9.5.

  • Help is still needed with these three changes to work through with upstream
    GCC (requires src expertise, not ports):

      â–¡ upstreaming lang/gcc11/patch-gets-no-more

      â–¡ upstreaming lang/gcc11/patch-arm-unwind-cxx-support

      â–¡ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256874

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Valgrind - Numerous bugfixes and updates for 13.1 / 14.0

Links
Valgrind Home Page URL: https://www.valgrind.org/
Valgrind News URL: https://www.valgrind.org/docs/manual/dist.news.html

Contact: Paul Floyd 

A quite significant number of bug fixes have been made to Valgrind on FreeBSD
over the past few months. In particular, the i386 version has largely 'caught
up' with its bigger brother amd64.

The devel/valgrind-devel port has been bumped up to 3.20.0.g20220612,1 which
includes all of the following changes. If you use Valgrind regularly please
swtch to valgrind-devel.

Here is a list of changes since the release of Valgrind 3.19.0 (which is the
version available with the devel/valgrind port).

  • incorrect signal resumption if a signal arrives when Valgrind is saving the
    carry flag for a syscall

  • fixed reading DWARF debuginfo from PT_LOADs generated by lld post version
    9, which splits the RW segment into two parts, this affects mainly shared
    libraries (.so files)

  • on i386 implement correctly the management of thread GDTs which was
    limiting applications to only ever creating 8192 threads

  • make the first page of the 'brk' invalid for addressing

  • analysis and cleanup of the regression test suite and in particular tweak
    the i386 leak tests to not detect possible leaks due to left over pointers
    in ECX.

  • make coredumps readable by lldb

  • improve the setting of errno by C allocating functions

  • fix building of Valgrind with llvm-devel (15.0.0)

For FreeBSD 13.1 / 14.0 there are

  • syscall wrappers for funlinkat, copy_file_range, swapoff, shm_open2

  • add K_INFO handling to fcntl

  • add handling for new auxv entries

  • added some default suppressions for DRD and Helgrind

There is now an initial version of vgdb invoker support - this allows vgdb to
use ptrace to force valgrind to poll for gdb commands. This is not yet
available in the ports versions.

That does not leave much in the way of outstanding issues. I expect that 14.0
and newer versions of llvm will keep on requiring support. Apart from that
there is

  • some small problems with error messages getting the correct source
    information

  • better core dumps (low priority)

  • TLS (thread local storage) handling for Helgrind (difficult if not
    impossible)

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Pantheon desktop on FreeBSD

Links:
elementary OS URL: https://elementary.io
Development repository URL: https://codeberg.org/olivierd/
freebsd-ports-elementary

Contact: Olivier Duchateau 

The Pantheon desktop environment is designed for elementary OS. It builds on
GNOME technologies (such as Mutter, GNOME Shell, GTK 3 and 4) and it is written
in Vala.

The goal is to have a new desktop for users. Some features are not well
supported, but we can have full session.

The repository contains Mk/Uses framework elementary.mk, official applications,
and curated ports which depend of x11-toolkits/granite (total of 56 new ports).

I have submitted several patches, especially:

  • x11-toolkits/granite7

  • devel/libgee update to 0.20.5 bug #262893

  • sysutils/bamf update to 0.5.6 bug #264203

Open tasks

  • Add support of user settings (it is very Ubuntu-centric)

  • Finish porting wingpanel-indicator-power (power management)

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Feature Complete Port of Intel’s igt-gpu-tools

Links:
FreeBSD Wiki Project Page URL: https://wiki.freebsd.org/
SummerOfCode2022Projects/
ImprovingTheLinuxKPICompatibilityLayerForTheFreeBSDGraphicsStack
Status Reports URL: https://cdaemon.com/tags/gsoc2022

Contact: Jake Freeland 

Intel’s igt-gpu-tools serves as a generic testing suite for drm drivers on
Linux. The igt-gpu-tools suite is separated into tests and tools that target
kms, memory management, and command submission. The utility provides low-level
reporting for transparent tracking of kernel changes and efficient debugging of
modern drm drivers.

Porting the project to FreeBSD could introduce greater stability in future
releases of FreeBSD’s LinuxKPI-driven drm drivers. A proper kms-driven testing
suite could also increase code output and bring the FreeBSD desktop experience
up to speed with the Linux codebase.

The project officially started under FreeBSD’s Google Summer of Code program on
June 13, 2022. My adapted code can compile with non-FreeBSD compatible snippets
removed. The plan is to reimplement these stripped components in a POSIX
compliant fashion.

Notable incompatible code includes: debugfs, libkmod, libprocps, Linux
performance events, and Linux userfaultfd. If you would like to assist in the
porting of libkmod or libprocps into the ports tree, don’t hesitate to contact
me.

When the FreeBSD compatible code is complete, I will run the modified igt tests
using a host of graphics processors on FreeBSD 14.0-CURRENT. If all is well,
the project’s diff will be submitted into the ports tree.

Sponsor: FreeBSD Google Summer of Code

From nobody Wed Aug 10 04:24:59 2022
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 4M2cKp75bbz4Y4l5
	for ; Wed, 10 Aug 2022 04:25:02 +0000 (UTC)
	(envelope-from editor@callfortesting.org)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M2cKp2bYvz3PBr
	for ; Wed, 10 Aug 2022 04:25:02 +0000 (UTC)
	(envelope-from editor@callfortesting.org)
Received: by mail-pj1-x102c.google.com with SMTP id o5-20020a17090a3d4500b001ef76490983so935293pjf.2
        for ; Tue, 09 Aug 2022 21:25:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=callfortesting-org.20210112.gappssmtp.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc;
        bh=DZdz6lwvDqWNJNhI92tXi3RuKQ+hosvpz6nuVLIz+hQ=;
        b=2G9LBulM5cmvSXQYX/5NGr2seEFlmQ8Wzp70sTfLfmurT15hz9hpdBQSUr0pUylZV6
         tLEMMrCIYqFu35x+v/rJR7X9lFoLv49rLpM+JlZCWwnn/R7V2/RCG4AU17qR1Vl4cHJ3
         E/+tjbf8Sb2UTOanBR7Jy+HVRlDd4Dzx2AjPjPq/XwOlzYgul5LnBXuTy2uFBsqU3B2K
         Xiqg/fY8hyvOYuETMIYGnsisfpsTaIy9lBZejGE064/dVZkAtMwKsRySla2fKfPWuh1v
         pUzGGwAt1gXIDpWwsNZBjAOEC/nQryYj8vQOgPs8zBBhf21aO+pzjW2Xd1SVSEAjl5Tf
         ThSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc;
        bh=DZdz6lwvDqWNJNhI92tXi3RuKQ+hosvpz6nuVLIz+hQ=;
        b=jkMMZTf92DMORG7KoU5gJtlA+l8Aj6FptFdMQt21uPFkprs/e5XrzkdHUFE820uN1s
         2oJCWVdpxG8cBWNL47Zkjl7E7fu4AlF31qkOjhpQPy3RP/6rGou3wEB0+nm3PVTMCLon
         b4HIEl0e6Bhgf6z3b2SH8VXUiCg1wJfoUyWwKE7k0mqncnoJ9h5+UiP6rjDG0lREsyQ/
         lI/cHZhDYfk+1DUHFQ1LwB2JEqymL3U1Nvn7mNnircB9MhqLxoMaoPe9VS7IVtmyDU14
         c+F6NFkae2+i5UMMP4Ab5XI4/5AMXxvfSzJ4+Nzc7+YN1zBAq1s8S41GhEmYW7oxSh2z
         PLRQ==
X-Gm-Message-State: ACgBeo3DClx7Wug33WyI4tHDMCCZ9ljSSjh4EVZBah7pMsDAIKxdOSZE
	c2w4O8l3Q9j4yJcVJFw+eQuskEUdw1+Jlkgu
X-Google-Smtp-Source: AA6agR5Yo6OgYVnPqonk2cGa2YXi9lxxlNSEVc1DMXcQ8jZNsUylK8Qel6qFt4l8HEzytq4lEA2AUw==
X-Received: by 2002:a17:902:e749:b0:171:2480:4320 with SMTP id p9-20020a170902e74900b0017124804320mr5686280plf.153.1660105500627;
        Tue, 09 Aug 2022 21:25:00 -0700 (PDT)
Received: from [10.0.0.236] (c-73-157-223-253.hsd1.or.comcast.net. [73.157.223.253])
        by smtp.gmail.com with ESMTPSA id iz4-20020a170902ef8400b0016d9b101413sm11578565plb.200.2022.08.09.21.25.00
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 09 Aug 2022 21:25:00 -0700 (PDT)
Message-ID: <519824ef-9096-e544-e2e0-3326e70e2853@callfortesting.org>
Date: Tue, 9 Aug 2022 21:24:59 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:91.0)
 Gecko/20100101 Thunderbird/91.10.0
Subject: Re: bhyve core dump related to llvm 14
Content-Language: en-US
To: freebsd-current@freebsd.org
References: 
From: Michael Dexter 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4M2cKp2bYvz3PBr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=callfortesting-org.20210112.gappssmtp.com header.s=20210112 header.b=2G9LBulM;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of editor@callfortesting.org has no SPF policy when checking 2607:f8b0:4864:20::102c) smtp.mailfrom=editor@callfortesting.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[callfortesting-org.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102c:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[callfortesting-org.20210112.gappssmtp.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DMARC_NA(0.00)[callfortesting.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 7/21/22 8:31 AM, Chuck Tuffli wrote:
> I have a virtual machine used to test the NVMe emulation in bhyve. All
> of the tests in the VM pass running under FreeBSD 13.1-R, but the same
> VM running under -current causes bhyve(8) to dump core because of a
> segmentation fault.
> 
> git bisect identified the last "good" commit on main as
>      cb2ae6163174 sysvsem: Fix a typo
> After this commit, there are a half-dozen commits related to merging
> the llvm project release/14.x


Chuck and I put our heads together to find a way to reproduce this issue 
and came up with this:

Attache a 1gb disk image as emulation type "nvme" to a VM of any recent 
version, and run this command:

nvmecontrol io-passthru -o 0x2 -l 4096 -4 0x2ffff0 -r nvme0ns1

This fails gracefully on 13.0R and 13.1R, but panics the bhyve process 
with a 14-CURRENT host after the LLVM 14 import.

I have detailed reproduction steps and the debug output in this bug report:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265749

Michael

From nobody Thu Aug 11 15:53:16 2022
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 4M3WYh6Gkwz4Yhsb;
	Thu, 11 Aug 2022 15:53:28 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M3WYh5YfXz3grp;
	Thu, 11 Aug 2022 15:53:28 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660233208;
	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=BcI0wKAEYqZ6scpopzV8NrhpxlOaa4/urmXZVtureco=;
	b=JiRfqVf0RHXEnRYfucohsFYXRJRVMC3jl9C2dJfGHmq+xNTtz3iFYwiXg2r5aKI1ss25bo
	Eekfhk3FC0SJb5q09ek7wzCD7eZP6K5jbq1ePg1QjdsDaHWLiKZyBiBTVEjcQp+qtKZ0W+
	ov3yYnI+aBYfOtHG9F9en50tKSC56dGRoSjQNORSN8aO6zGW+5+gzh9vkdIXSCkacH114y
	ylIpedsRwF/NOY5lL7r/ACKPH7FTKJ2ufBNUmPHB6dv/6X+zvLuJVaPBgcbU7C2tVmJbWl
	2FbEV3MObtmO0q3h7Jl0vlcOuQsFpUOJ7HuKAsST9b+fJ/aqEEu3pwxV+8q1bw==
Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M3WYh4NdmzxNd;
	Thu, 11 Aug 2022 15:53:28 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f51.google.com with SMTP id d126so14393135vsd.13;
        Thu, 11 Aug 2022 08:53:28 -0700 (PDT)
X-Gm-Message-State: ACgBeo3rLbXuS9Tmfh1ll3VNg7G3Yn42DLtDPsCkB/wThIh4lCWNrIOo
	rB14L/t1gnlCs1yAIg4XE5TsQ7neqsOdyK9ug4A=
X-Google-Smtp-Source: AA6agR7axSopX94RUV9ZFvnbfe4dhZ98u5LGZIvZ+KaGvb33MJ4VgHh+W8J6vDtFSLYN8ZJLla5m+hnF5cZBDdas10A=
X-Received: by 2002:a05:6102:3e02:b0:388:984b:e082 with SMTP id
 j2-20020a0561023e0200b00388984be082mr10861919vsv.58.1660233208183; Thu, 11
 Aug 2022 08:53:28 -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: Nuno Teixeira 
Date: Thu, 11 Aug 2022 16:53:16 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: [iwlwifi] ipv6 connection problem
To: "Bjoern A. Zeeb" 
Cc: freebsd-wireless@freebsd.org, 
	FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000009e42d805e5f92aa4"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660233208;
	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=BcI0wKAEYqZ6scpopzV8NrhpxlOaa4/urmXZVtureco=;
	b=GrbUmYTmga6TsKAqYNo/XTP7W9foeR865Oz4HRzPz26DaDbvHHnc7UV6sQ0nw3dFpvGSSy
	X/bRaHfiG/WTJJHKhHhb/4CRli0sbSqw5dsWz0Go1Ypx+1xvcPids2ScnymcrF5oPHQlra
	0fMScz1qbBquF8AjqmgRNorg4MxfIBSkIk+3riMPs4+9YPtefDqOFOJGN21G3KIre/44Mn
	3t6sdF0/csQbavGIGaMCFjpY05j6v23NChOLcOlFIxeQzcerhB7gDLXQTXF/7iOH0PeSGe
	m+fQ/3LuwdVj1Z18zs3JJ3o4Y5iNJKwjuLZTSxbb8DIbn/5CcmycLyXttkCd+g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660233208; a=rsa-sha256; cv=none;
	b=tt2icue70SJ7kTp63EU2c2pYkkReP+5/6uuOz+BXJ0weE9+DMfS6uOGI/+NYeS5Sx8NT9D
	UjxrYvRK+GA8XNvKg4Q2GJjwUzcZ2DAxhAeCbw7yXk4+S1iqyyVOCuzmupUhbFwi+0Ncn0
	IGzDx+BzL93+Z1vrsh07t0vphwAB/7SgI0rdlY/j/C6zPiWvzzKhJGLXkcDVE2FlabqAcp
	+3cclRKM0IMtLcvsMJwQc01pZvBxmsw/E7MmEJCugyvMmlP+UGIQCKVZIfXot+zN3WFhSW
	FAVusc2nuAchMhyWWHM8mVJRU/APjGGfbd+qIQ7dXf7aI7YDVEON2TY9dB7TQg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000009e42d805e5f92aa4
Content-Type: text/plain; charset="UTF-8"

Hello Bjoern!

/etc/rc.conf:
---
wlans_iwlwifi0="wlan0"
create_args_wlan0="wlanmode sta regdomain ETSI country PT"
ifconfig_wlan0_ipv6="inet6 accept_rtadv"
ifconfig_wlan0="WPA SYNCDHCP"
rtsold_enable="YES"
---

`ifconfig wlan0`:
---
wlan0: flags=8c43 metric 0
mtu 1500
        ether 6c:6a:77:df:09:21
        inet6 fe80::6e6a:77ff:fedf:921%wlan0 prefixlen 64 scopeid 0x3
        groups: wlan
        ssid "" channel 6 (2437 MHz 11g)
        regdomain ETSI country PT authmode WPA1+WPA2/802.11i privacy MIXED
        deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 protmode CTS wme
        roaming MANUAL bintval 0
        parent interface: iwlwifi0
        media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
        status: no carrier
        nd6 options=23
---

(a) this is unlikely related to IPv6?  The only thing that would do
> is pass down more multicast addresses than with just IPv4 (and that's
> after assoc normally).  I run some on IPv6-only.
> Let me ask you anyway, so we can be sure.  If you remove the IPv6 config,
> does wpa_supplicant associate fine?  (could also be a different
> tooling issue).


With ipv4 wireless work ok and wpa_supplicant associate ok.


> (b) does `ifconfig wlan0 list scan` show your AP when it doesn't?
> If it doesn't that is more likely the problem.  And that remains a problem
> for some conditions I am also facing.  More on 11a than 11g.


`ifconfig wlan0 list scan`:
---
SSID/MESH ID                      BSSID              CHAN RATE    S:N
INT CAPS
MEO-3637C0                        00:06:91:36:37:c0   11   54M  -53:-96
100 EP   RSN BSSLOAD HTCAP WPS WME
MEO-WiFi                          00:06:91:36:37:c2   11   54M  -53:-96
100 E    BSSLOAD HTCAP WME
MEO-3637C0                        00:06:91:36:37:c1   60   54M  -61:-96
100 EP   RSN BSSLOAD HTCAP VHTCAP VHTOPMODE VHTPWRENV WPS WME
MEO-WiFi                          00:06:91:36:37:c6   60   54M  -60:-96
100 E    BSSLOAD HTCAP VHTCAP VHTOPMODE VHTPWRENV WME
---

(c) Then the question is if wpa_supplicant blacklists the network;
> `wpa_cli blacklist` would show.  If it does try the following sequence
> to make it try more often:
> CMD=wpa_cli
> SSID=
> ${CMD} blacklist clear
> ${CMD} disable ${SSID}
> ${CMD} enable ${SSID}
> ${CMD} list_networks
>

`wpa_cli blacklist`:
---
Failed to connect to non-global ctrl_ifname: (nil)  error: Inappropriate
ioctl for device
---


> (d) given you didn't say, what does `freebsd-version -r -u`
> say, just to rule out you are missing the latest wpa fixes.
>

 `freebsd-version -r -u`:
---
14.0-CURRENT
14.0-CURRENT
---
@1ffd352bc25b

(e) what you can do is enable more wpa_supplicant logging; I often use
> wpa_supplicant_flags="-sdd"  in /etc/rc.conf which will log to syslog
> instead
> of the debug file but it'll increase debugging a lot (and warning, it
> may also log keying material).
>

Ok.

Cheers,
-- 
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000009e42d805e5f92aa4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Bjoern!

/etc/rc.c=
onf:
---
wlans_iwlwifi0=3D"wlan0"
create_a=
rgs_wlan0=3D"wlanmode sta regdomain ETSI country PT"
ifconfig_=
wlan0_ipv6=3D"inet6 accept_rtadv"
ifconfig_wlan0=3D"WPA S=
YNCDHCP"
rtsold_enable=3D"YES"
---

`ifconfig wlan0`:
---
wlan0: flags=3D8=
c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ether 6c:6a:77:df:09:21
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 inet6 fe80::6e6a:77ff:fedf:921%wlan0 prefixlen 64 scopeid 0x3=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 groups: wlan
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 ssid "" channel 6 (2437 MHz 11g)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
regdomain ETSI country PT authmode WPA1+WPA2/802.11i privacy MIXED
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 pro=
tmode CTS wme
=C2=A0 =C2=A0 =C2=A0 =C2=A0 roaming MANUAL bintval 0
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 parent interface: iwlwifi0
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 status: no carrier
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 nd6 options=3D23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
---


(a) this is unlikely related to IPv6?=C2=A0 The only thing that would do
is pass down more multicast addresses than with just IPv4 (and that's
after assoc normally).=C2=A0 I run some on IPv6-only.

Let me ask you anyway, so we can be sure.=C2=A0 If you remove the IPv6 conf=
ig,

does wpa_supplicant associate fine?=C2=A0 (could also be a different

tooling issue).

With ipv4 wireless work ok =
and wpa_supplicant associate ok.
=C2=A0

(b) does `ifconfig wlan0 list scan` show your AP when it doesn't?

If it doesn't that is more likely the problem.=C2=A0 And that remains a=
 problem

for some conditions I am also facing.=C2=A0 More on 11a than 11g.
=C2=A0
`ifconfig wlan0 list scan`:
---
SSID/MESH ID =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0BSSID =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CHAN=
 RATE =C2=A0 =C2=A0S:N =C2=A0 =C2=A0 INT CAPS
MEO-3637C0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A000:06:=
91:36:37:c0 =C2=A0 11 =C2=A0 54M =C2=A0-53:-96 =C2=A0 100 EP =C2=A0 RSN BSS=
LOAD HTCAP WPS WME
MEO-WiFi =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A000:06:91:36:37:c2 =C2=A0 11=
 =C2=A0 54M =C2=A0-53:-96 =C2=A0 100 E =C2=A0 =C2=A0BSSLOAD HTCAP WME
ME=
O-3637C0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A000:06:91:36:37:c1 =C2=A0 60 =C2=A0 54M =C2=A0-61:-96 =C2=
=A0 100 EP =C2=A0 RSN BSSLOAD HTCAP VHTCAP VHTOPMODE VHTPWRENV WPS WME
M=
EO-WiFi =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A000:06:91:36:37:c6 =C2=A0 60 =C2=A0 54M =C2=A0-60:-9=
6 =C2=A0 100 E =C2=A0 =C2=A0BSSLOAD HTCAP VHTCAP VHTOPMODE VHTPWRENV WME
---


(c) Then the question is if wpa_supplicant blacklists the network;

`wpa_cli blacklist` would show.=C2=A0 If it does try the following sequence=


to make it try more often:

CMD=3Dwpa_cli

SSID=3D<your ssid>

${CMD} blacklist clear

${CMD} disable ${SSID}

${CMD} enable ${SSID}

${CMD} list_networks

`wpa_cli blacklist=
`:
---
Failed to connect to non-global ctrl_ifname: (ni=
l) =C2=A0error: Inappropriate ioctl for device
---
=
=C2=A0

(d) given you didn't say, what does `freebsd-version -r -u`

say, just to rule out you are missing the latest wpa fixes.

=C2=A0`freebsd-version -r -u`:
---
14.0-CURRENT
14.0-CURRENT
---
@1ffd352bc25b
=



(e) what you can do is enable more wpa_supplicant logging; I often use

wpa_supplicant_flags=3D"-sdd"=C2=A0 in /etc/rc.conf which will lo=
g to syslog instead

of the debug file but it'll increase debugging a lot (and warning, it
may also log keying material).

Ok.

Cheers,
-- 
Nuno Teixeira
FreeBSD Committer (ports)


--0000000000009e42d805e5f92aa4--

From nobody Fri Aug 12 09:50:37 2022
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 4M3zSr4fF8z4Y10s
	for ; Fri, 12 Aug 2022 09:50:52 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M3zSq2pmmz44dp
	for ; Fri, 12 Aug 2022 09:50:51 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from [IPV6:2a02:22e0:cf00:1ff:612a:46a0:21f9:184b] (mzar@[IPv6:2a02:22e0:cf00:1ff:612a:46a0:21f9:184b])
	(authenticated bits=0)
	by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 27C9odNw005170
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO)
	for ; Fri, 12 Aug 2022 11:50:40 +0200 (CEST)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl;
	s=plan-b-mailer; t=1660297840;
	bh=TldkrY/Grj8zcaEdRR//o8fCwy2eGUx2K+ryk0M2SFM=;
	h=Date:To:References:From:Subject:In-Reply-To;
	b=XGNJCYz3PXi/hpMSnQNRoxZcy0y+oOdqbfogVkn7V/oX83NlzJ4y7c7iRx5Dq0XO0
	 OVTMqNGCV7ar2paSFWHc9ARdogmM//QG54vXHoot4bvWgOzCnq8WBAZN1xT3ZZJ+Wl
	 alEEt+btgRBVR8NXdF2jA0Eooc4rQOLkommDOhN0dapvJj74v8Nvk4ZT2mFv4pd164
	 yamPOF1ADyeVnEhry4NmpqGzDM4PHT046H9988Z6EbACZSpR5USdtMZoH4MG8cRPQ5
	 voCNQ75TaTorcYjN4MNq1nN6dHF8XYTbeiI9tGIyNfNJ9WW+gqbJWMVJ9WtNAI/Hei
	 PP//ECcm0/W1w==
Message-ID: <4f79dfa8-b8bd-3222-d4de-18714c1f9b6a@plan-b.pwste.edu.pl>
Date: Fri, 12 Aug 2022 11:50:37 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Content-Language: pl
To: freebsd-current@freebsd.org
References: 
 
 
From: Marek Zarychta 
Subject: Re: [iwlwifi] ipv6 connection problem
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------X10eZ1jIiBycKKlR10zLZhM2"
X-Rspamd-Queue-Id: 4M3zSq2pmmz44dp
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=XGNJCYz3;
	dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl;
	spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl
X-Spamd-Result: default: False [-5.77 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.97)[-0.974];
	DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer];
	MIME_BASE64_TEXT(0.10)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+];
	ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	HAS_ATTACHMENT(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_SPF_NA(0.00)[no SPF record];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------X10eZ1jIiBycKKlR10zLZhM2
Content-Type: multipart/mixed; boundary="------------JXQjcaJHyInLlDOCLQOm80Lz";
 protected-headers="v1"
From: Marek Zarychta 
To: freebsd-current@freebsd.org
Message-ID: <4f79dfa8-b8bd-3222-d4de-18714c1f9b6a@plan-b.pwste.edu.pl>
Subject: Re: [iwlwifi] ipv6 connection problem
References: 
 
 
In-Reply-To: 

--------------JXQjcaJHyInLlDOCLQOm80Lz
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

VyBkbml1IDExLjA4LjIwMjIgb8KgMTc6NTMsIE51bm8gVGVpeGVpcmEgcGlzemU6DQo+IEhl
bGxvIEJqb2VybiENCj4gDQo+IC9ldGMvcmMuY29uZjoNCj4gLS0tDQo+IHdsYW5zX2l3bHdp
ZmkwPSJ3bGFuMCINCj4gY3JlYXRlX2FyZ3Nfd2xhbjA9IndsYW5tb2RlIHN0YSByZWdkb21h
aW4gRVRTSSBjb3VudHJ5IFBUIg0KPiBpZmNvbmZpZ193bGFuMF9pcHY2PSJpbmV0NiBhY2Nl
cHRfcnRhZHYiDQo+IGlmY29uZmlnX3dsYW4wPSJXUEEgU1lOQ0RIQ1AiDQo+IHJ0c29sZF9l
bmFibGU9IllFUyINCj4gLS0tDQo+IA0KSWYgeW91IGFyZSBjb25uZWN0aW5nIHRvIElQdjYg
b25seSBXTEFOIHRoYW4geW91IGNhbiBwcm9iYWJseSBlaXRoZXIgDQpkaXNhYmxlIERIQ1Ag
KGlmIHRoZSBSRE5TUyBpcyBwcm92aWRlZCBmb3IgdGhpcyBuZXR3b3JrKToNCmlmY29uZmln
X3dsYW4wPSJXUEEgdXAiDQpvciBpbnN0YWxsIGRoY3AgY2xpZW50IGNhcGFibGUgb2YgYWNx
dWlyaW5nIERIQ1B2NiBsZWFzZSBhbmQgdXNlIGl0IA0KaW5zdGVhZCBvZiBzdGFuZGFyZCBk
aGNsaWVudCg4KSBmcm9tIHRoZSBiYXNlIHdoaWNoIGRvZXNuJ3Qgc3VwcG9ydCBESENQdjYu
DQoNCj4gYGlmY29uZmlnIHdsYW4wYDoNCj4gLS0tDQo+IHdsYW4wOiBmbGFncz04YzQzPFVQ
LEJST0FEQ0FTVCxSVU5OSU5HLE9BQ1RJVkUsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAN
Cj4gMCBtdHUgMTUwMA0KPiAgwqAgwqAgwqAgwqAgZXRoZXIgNmM6NmE6Nzc6ZGY6MDk6MjEN
Cj4gIMKgIMKgIMKgIMKgIGluZXQ2IGZlODA6OjZlNmE6NzdmZjpmZWRmOjkyMSV3bGFuMCBw
cmVmaXhsZW4gNjQgc2NvcGVpZCAweDMNCj4gIMKgIMKgIMKgIMKgIGdyb3Vwczogd2xhbg0K
PiAgwqAgwqAgwqAgwqAgc3NpZCAiIiBjaGFubmVsIDYgKDI0MzcgTUh6IDExZykNCj4gIMKg
IMKgIMKgIMKgIHJlZ2RvbWFpbiBFVFNJIGNvdW50cnkgUFQgYXV0aG1vZGUgV1BBMStXUEEy
LzgwMi4xMWkgcHJpdmFjeSBNSVhFRA0KPiAgwqAgwqAgwqAgwqAgZGVmdHhrZXkgVU5ERUYg
dHhwb3dlciAzMCBibWlzcyA3IHNjYW52YWxpZCA2MCBwcm90bW9kZSBDVFMgd21lDQo+ICDC
oCDCoCDCoCDCoCByb2FtaW5nIE1BTlVBTCBiaW50dmFsIDANCj4gIMKgIMKgIMKgIMKgIHBh
cmVudCBpbnRlcmZhY2U6IGl3bHdpZmkwDQo+ICDCoCDCoCDCoCDCoCBtZWRpYTogSUVFRSA4
MDIuMTEgV2lyZWxlc3MgRXRoZXJuZXQgYXV0b3NlbGVjdCAoYXV0b3NlbGVjdCkNCj4gIMKg
IMKgIMKgIMKgIHN0YXR1czogbm8gY2Fycmllcg0KPiAgwqAgwqAgwqAgwqAgbmQ2IG9wdGlv
bnM9MjM8UEVSRk9STU5VRCxBQ0NFUFRfUlRBRFYsQVVUT19MSU5LTE9DQUw+DQo+IC0tLQ0K
PiANCj4gICAgIChhKSB0aGlzIGlzIHVubGlrZWx5IHJlbGF0ZWQgdG8gSVB2Nj/CoCBUaGUg
b25seSB0aGluZyB0aGF0IHdvdWxkIGRvDQo+ICAgICBpcyBwYXNzIGRvd24gbW9yZSBtdWx0
aWNhc3QgYWRkcmVzc2VzIHRoYW4gd2l0aCBqdXN0IElQdjQgKGFuZCB0aGF0J3MNCj4gICAg
IGFmdGVyIGFzc29jIG5vcm1hbGx5KS7CoCBJIHJ1biBzb21lIG9uIElQdjYtb25seS4NCj4g
ICAgIExldCBtZSBhc2sgeW91IGFueXdheSwgc28gd2UgY2FuIGJlIHN1cmUuwqAgSWYgeW91
IHJlbW92ZSB0aGUgSVB2Ng0KPiAgICAgY29uZmlnLA0KPiAgICAgZG9lcyB3cGFfc3VwcGxp
Y2FudCBhc3NvY2lhdGUgZmluZT/CoCAoY291bGQgYWxzbyBiZSBhIGRpZmZlcmVudA0KPiAg
ICAgdG9vbGluZyBpc3N1ZSkuDQo+IA0KPiANCj4gV2l0aCBpcHY0IHdpcmVsZXNzIHdvcmsg
b2sgYW5kIHdwYV9zdXBwbGljYW50IGFzc29jaWF0ZSBvay4NCj4gDQo+ICAgICAoYikgZG9l
cyBgaWZjb25maWcgd2xhbjAgbGlzdCBzY2FuYCBzaG93IHlvdXIgQVAgd2hlbiBpdCBkb2Vz
bid0Pw0KPiAgICAgSWYgaXQgZG9lc24ndCB0aGF0IGlzIG1vcmUgbGlrZWx5IHRoZSBwcm9i
bGVtLsKgIEFuZCB0aGF0IHJlbWFpbnMgYQ0KPiAgICAgcHJvYmxlbQ0KPiAgICAgZm9yIHNv
bWUgY29uZGl0aW9ucyBJIGFtIGFsc28gZmFjaW5nLsKgIE1vcmUgb24gMTFhIHRoYW4gMTFn
Lg0KPiANCj4gYGlmY29uZmlnIHdsYW4wIGxpc3Qgc2NhbmA6DQo+IC0tLQ0KPiBTU0lEL01F
U0ggSUQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBCU1NJRCDCoCDCoCDCoCDC
oCDCoCDCoCDCoENIQU4gUkFURSDCoCDCoFM6TiAgIA0KPiAgwqAgSU5UIENBUFMNCj4gTUVP
LTM2MzdDMCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDAwOjA2OjkxOjM2
OjM3OmMwIMKgIDExIMKgIDU0TSDCoC01MzotOTYgDQo+ICDCoCAxMDAgRVAgwqAgUlNOIEJT
U0xPQUQgSFRDQVAgV1BTIFdNRQ0KPiBNRU8tV2lGaSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoDAwOjA2OjkxOjM2OjM3OmMyIMKgIDExIMKgIDU0TSDCoC01Mzot
OTYgDQo+ICDCoCAxMDAgRSDCoCDCoEJTU0xPQUQgSFRDQVAgV01FDQo+IE1FTy0zNjM3QzAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAwMDowNjo5MTozNjozNzpjMSDC
oCA2MCDCoCA1NE0gwqAtNjE6LTk2IA0KPiAgwqAgMTAwIEVQIMKgIFJTTiBCU1NMT0FEIEhU
Q0FQIFZIVENBUCBWSFRPUE1PREUgVkhUUFdSRU5WIFdQUyBXTUUNCj4gTUVPLVdpRmkgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAwMDowNjo5MTozNjozNzpjNiDC
oCA2MCDCoCA1NE0gwqAtNjA6LTk2IA0KPiAgwqAgMTAwIEUgwqAgwqBCU1NMT0FEIEhUQ0FQ
IFZIVENBUCBWSFRPUE1PREUgVkhUUFdSRU5WIFdNRQ0KPiAtLS0NCj4gDQo+ICAgICAoYykg
VGhlbiB0aGUgcXVlc3Rpb24gaXMgaWYgd3BhX3N1cHBsaWNhbnQgYmxhY2tsaXN0cyB0aGUg
bmV0d29yazsNCj4gICAgIGB3cGFfY2xpIGJsYWNrbGlzdGAgd291bGQgc2hvdy7CoCBJZiBp
dCBkb2VzIHRyeSB0aGUgZm9sbG93aW5nIHNlcXVlbmNlDQo+ICAgICB0byBtYWtlIGl0IHRy
eSBtb3JlIG9mdGVuOg0KPiAgICAgQ01EPXdwYV9jbGkNCj4gICAgIFNTSUQ9PHlvdXIgc3Np
ZD4NCj4gICAgICR7Q01EfSBibGFja2xpc3QgY2xlYXINCj4gICAgICR7Q01EfSBkaXNhYmxl
ICR7U1NJRH0NCj4gICAgICR7Q01EfSBlbmFibGUgJHtTU0lEfQ0KPiAgICAgJHtDTUR9IGxp
c3RfbmV0d29ya3MNCj4gDQo+IA0KPiBgd3BhX2NsaSBibGFja2xpc3RgOg0KPiAtLS0NCj4g
RmFpbGVkIHRvIGNvbm5lY3QgdG8gbm9uLWdsb2JhbCBjdHJsX2lmbmFtZTogKG5pbCkgwqBl
cnJvcjogSW5hcHByb3ByaWF0ZSANCj4gaW9jdGwgZm9yIGRldmljZQ0KPiAtLS0NCj4gDQo+
ICAgICAoZCkgZ2l2ZW4geW91IGRpZG4ndCBzYXksIHdoYXQgZG9lcyBgZnJlZWJzZC12ZXJz
aW9uIC1yIC11YA0KPiAgICAgc2F5LCBqdXN0IHRvIHJ1bGUgb3V0IHlvdSBhcmUgbWlzc2lu
ZyB0aGUgbGF0ZXN0IHdwYSBmaXhlcy4NCj4gDQo+IA0KPiAgwqBgZnJlZWJzZC12ZXJzaW9u
IC1yIC11YDoNCj4gLS0tDQo+IDE0LjAtQ1VSUkVOVA0KPiAxNC4wLUNVUlJFTlQNCj4gLS0t
DQo+IEAxZmZkMzUyYmMyNWINCj4gDQo+ICAgICAoZSkgd2hhdCB5b3UgY2FuIGRvIGlzIGVu
YWJsZSBtb3JlIHdwYV9zdXBwbGljYW50IGxvZ2dpbmc7IEkgb2Z0ZW4gdXNlDQo+ICAgICB3
cGFfc3VwcGxpY2FudF9mbGFncz0iLXNkZCLCoCBpbiAvZXRjL3JjLmNvbmYgd2hpY2ggd2ls
bCBsb2cgdG8NCj4gICAgIHN5c2xvZyBpbnN0ZWFkDQo+ICAgICBvZiB0aGUgZGVidWcgZmls
ZSBidXQgaXQnbGwgaW5jcmVhc2UgZGVidWdnaW5nIGEgbG90IChhbmQgd2FybmluZywgaXQN
Cj4gICAgIG1heSBhbHNvIGxvZyBrZXlpbmcgbWF0ZXJpYWwpLg0KPiANCj4gDQo+IE9rLg0K
PiANCj4gQ2hlZXJzLA0KPiAtLSANCj4gTnVubyBUZWl4ZWlyYQ0KPiBGcmVlQlNEIENvbW1p
dHRlciAocG9ydHMpDQoNCg0KLS0gDQpNYXJlayBaYXJ5Y2h0YQ0K

--------------JXQjcaJHyInLlDOCLQOm80Lz--

--------------X10eZ1jIiBycKKlR10zLZhM2
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmL2Im0FAwAAAAAACgkQHZW8vIFppoIV
PQf9HTeSZFrkZLXs0Ij2q4XntJRhzT2nqeU2VZ56NYhwmlJ4QRz6YgQALz1KxU5hQgDdMvN2q/D9
nVpx7uJRl2y2CPRSuuuNM2yCVFVX3SdAnW+i0nHFvVIzQ+2XXURP36ogPzRayGPhWOv/h87BgbbG
1ariEIzxv6l64+e366u7vlOnwE1rHBMTLeOMsGZYp13rBAcpb7p4kH7fhW2RSUFFzRyqGzYDW+L+
4mi5fACsz2i0leh/M/QnlITKicTGzNxlDDMqJsxTEovMIqnyrtr91SOb3z8UKaDOVBysTjdD/yrr
6sje7GoLVL/JW6AcgxjDYjFPiiroy0IqrsD2z2aq0Q==
=da6h
-----END PGP SIGNATURE-----

--------------X10eZ1jIiBycKKlR10zLZhM2--

From nobody Fri Aug 12 12:00:33 2022
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 4M42Lj304kz4Yv45;
	Fri, 12 Aug 2022 12:00:45 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M42Lj2XnPz3Rj6;
	Fri, 12 Aug 2022 12:00:45 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660305645;
	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=StErj0q0iMc7Nzm4oRsShusvC/sb9InUEKvGISrwdU8=;
	b=loCWPa43Tu3daRYJOxzyGHhg8+EDdOPjlzzAWzv47/Be7ZTGftzXhVX2memdRVyqadlzaf
	A410fWRFo9xaeB8PJY0Ufs5jma1//qM0jqbXghWBeYB/YD08HXC+WIMxd9RCRK7asF6SFz
	wfLd6D4qQt+UQqro+TOe82c8NXmTwtj2kKoX4U9opoMvnm0Q1oO+CV66r3YiHcvAven/FU
	q/yjt67aNVBrr8tdOTpVUhilefXvqvK3EHLW99ZG88tcA8Mz5ip5NV7YYZH9qC4Iq6bgcJ
	iYygkdOwh7ZsWX++n9LNh0PVSwjYdCwG4XkLGmSPINdxAO6k1v5N8UIJ7mgZhQ==
Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M42Lj1V6Nz1Hmr;
	Fri, 12 Aug 2022 12:00:45 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f42.google.com with SMTP id j2so577604vsp.1;
        Fri, 12 Aug 2022 05:00:45 -0700 (PDT)
X-Gm-Message-State: ACgBeo3rRsjOln8tDe2kAmwYhoTKFqBs+E9mKKPDUdbU5EcE/5lIn0Fb
	wtgmCRxQLhonL28he3aZ3BZwSzEI0g5cQ24mFhU=
X-Google-Smtp-Source: AA6agR4Zb2iccw1/ra9T4Fy8RaRofewt3Zg6TQj2m7nxdL1TEjH4UCzJHk+aAyuMaDYMApx5Pa9nBU90Y+WYAEbtGfQ=
X-Received: by 2002:a05:6102:2836:b0:386:91a5:a241 with SMTP id
 ba22-20020a056102283600b0038691a5a241mr1500403vsb.51.1660305644673; Fri, 12
 Aug 2022 05:00:44 -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: 
  
 <4f79dfa8-b8bd-3222-d4de-18714c1f9b6a@plan-b.pwste.edu.pl>
In-Reply-To: <4f79dfa8-b8bd-3222-d4de-18714c1f9b6a@plan-b.pwste.edu.pl>
From: Nuno Teixeira 
Date: Fri, 12 Aug 2022 13:00:33 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: [iwlwifi] ipv6 connection problem
To: FreeBSD CURRENT 
Cc: freebsd-wireless@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000002b616005e60a08bf"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660305645;
	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=StErj0q0iMc7Nzm4oRsShusvC/sb9InUEKvGISrwdU8=;
	b=axBptoawWyCmDClJTmsL0iwuBYrCjjfTV6uxNwBtKUwmuWb66r7SiDDiYHXsLTdYTR/seh
	tzHKAKwnz2se1hu1+VSN00yepoxOi1Sf5UGgjieKujBPKOjl80OUliqvaqFNfQBNjQE36I
	KuYQD8E0WJg4tYMuSs2/NScZT8MlPzFVR8bSrZay/lk0pOIVr4cHjPqrkWmdoGvf/96Vav
	RY2STPMd/FE+i1tp7LPHxPWckp4h3Ju7cpmNyFfw0r+reClgLIB84R0owWF+42za0aU+u2
	wcAvkwyrVZBFhW+PIjbFL/RLJi+UcJKi+5JREJconW5LMJSl0DphLppO46SplQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660305645; a=rsa-sha256; cv=none;
	b=ILU5bewpzcZQjucIH2fCMb/2KfIxnprgAP5jMnGBJobg2Xh9Kpk89FxB0FBlQhd/DdjoOh
	L9C+z7xEdmRugwzUcM+2NjYXkZeNgAVS8elyFeOwA33xCtNG2fBQBdJSbgy3YeckXsZKpd
	egkxqJqr7CxuXuztU8muw0me4Kb6dUYqmWdd9QTk2cu0LDoUbuf2PlOH0so5TBM8d7lOap
	u5hlPuRsvUiymzWGcPVClwSWVlxAyUYiIAQ2NqvgbO9oaa2rRHgkBNjRzWaV+A98GHjLFg
	G0AzIgzQ4NQvyhT+x4AxdS//O/eab6yxGRjumQfr00KDHTS/N2mKSZHlg0PBRw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000002b616005e60a08bf
Content-Type: text/plain; charset="UTF-8"

Hi Merek,

If you are connecting to IPv6 only WLAN than you can probably either
> disable DHCP (if the RDNSS is provided for this network):
> ifconfig_wlan0="WPA up"
> or install dhcp client capable of acquiring DHCPv6 lease and use it
> instead of standard dhclient(8) from the base which doesn't support DHCPv6.


I've tried ifconfig_wlan0="WPA up" and it crashes os.

You saying that base dhcp doesn't support ipv6 but it works fine with
ehternet:
---
ifconfig_re0="DHCP"
ifconfig_re0_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"
---

Any clues?

Thanks

--0000000000002b616005e60a08bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Merek,


If you are connecting to IPv6 only WLAN than you can probably either 

disable DHCP (if the RDNSS is provided for this network):

ifconfig_wlan0=3D"WPA up"

or install dhcp client capable of acquiring DHCPv6 lease and use it 

instead of standard dhclient(8) from the base which doesn't support DHC=
Pv6.

I've tried ifconfig_wlan0=3D"=
WPA up" and it crashes os.

You saying that ba=
se dhcp doesn't support ipv6 but it works fine with ehternet:
---
ifconfig_re0=3D"DHCP"
ifconfig_re0_ipv6=3D"=
;inet6 accept_rtadv"
rtsold_enable=3D"YES"
---<=
/div>

Any clues?

Thanks


--0000000000002b616005e60a08bf--

From nobody Fri Aug 12 16:54:26 2022
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 4M48vQ1s3Qz4Z4H6
	for ; Fri, 12 Aug 2022 16:56:02 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M48vQ1Qf3z3F3Z;
	Fri, 12 Aug 2022 16:56:02 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660323362;
	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=7gx3TYIG4W8LQNFHPVRFFa0BLlxV/f5sbSvHs6I6p1A=;
	b=Mt2zVvtmK6fdx+Ovy7i+S7jX2E2krHO/DK1tcnSOwbOGcwigie8Ve+yg7GCTWtH5IuwChl
	Us+/cLaeSyKZXFzFgrFfm/h99FPwp+05YpUOzOu4lStg2LQskfPb0mA8nlyL7bLKdW/0FS
	Nj84k0Sfpm1sd2FvoPMo452WI6ZA/dNt6/AjKg3/TdjGtmmUcOtHjWn/KMyQCX5GWlOY2G
	DDmoPBzFpw322ImNYlMrK7fqsNh22OxdIGpDkTUQq+v/bhtnOR0a7bcU5M527Q+jyQhRHc
	lP7062qOY9Ai1RgPW+6z7f3mfe/nhXFV1avY3veIY0GLCA02lPj3Am7b96ys7A==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:9807:42d3:d4e2:989b])
	(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: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M48vP3l57z1LXp;
	Fri, 12 Aug 2022 16:56:01 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)
Message-Id: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura 
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660323362;
	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=7gx3TYIG4W8LQNFHPVRFFa0BLlxV/f5sbSvHs6I6p1A=;
	b=HX7M9/wOn7jr31VkWLdkQpyXQX7qf2aMWkb++Qi6vknnvCCrsFBHnjlrv91d34jDfNivLc
	bvKxXmDOU4BiH5e/aH2Yih7BgGrCdPxKK04QEVIXSC0OE+T/9gUUrAzsfTSMZJW4zdwwzY
	F09AyA+eKW+GW0ztWd9yu+JZ1vXWJbrGWSayvByg2k5kumhvUkf9++MEmP9kHn1POMjiuH
	qUrphF90ytuS1errsYbXjNHZ/3C/6Rl+h5y/g9l7HNEQfyzZR4C0vKgZDM0Sm4cuUYWWwq
	5I3+OMD4ttHMD5mlFYttd06Jv317BJqD1OUItUvD0kgQbtAUs2T6S8BB6XWZoQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660323362; a=rsa-sha256; cv=none;
	b=WcvhU7PKg+3DM+FouRb4Xnyyrs1ArPctyphUqNBQze8xrOfxMojHLozk2wmmQ8LoxJ7/gr
	ox0R987vnAb0L5bYpkmH5VaGQJFYtJ7uTcV6uWUwxdLVnLXkgWyfLORJ2TIGOGRU0FXH+H
	0C449yq35bYOM1foVxZr312G2nEnxZSU/P89mZongdkgkJvFaLh1HuF1lDPsOyRlELRSNC
	inurX2sLmQLG4QS1H2Q+jlB0ZJldanITeMMQq75WyNTjC2TqnK4nqdghmxP1jqk5TfowNk
	227a+ehvxxPYjiFDGl9JfHxiOBm15+ZFxxcVfAt52/eOpLWvOzpyQXVn7N8rSg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

Hello,

I made regular update of my 14-CURRENT amd64 system from
main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
boot hangup as following.

https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png

If I restore previous loader file (that is, loader.efi of
main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
system boots successfully.

Best Regards.

---
Yasuhiro Kimura

From nobody Fri Aug 12 17:26:11 2022
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 4M49ZP60y3z4Y04c
	for ; Fri, 12 Aug 2022 17:26:21 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M49ZP5TkXz3MF3;
	Fri, 12 Aug 2022 17:26:21 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660325181;
	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=AXw8z0Un6DbgYelpyNiHPctabrjY3d/AHt/k4qjx/TI=;
	b=WdG5XY3XsedNuuOyn3Y6p3iTbLDLVVQY+5Xv65znHyW0Z4dBLn1pz1JxFME1bIr4Ql3PUz
	iv/MMF9qrl+/S3Sk30qg+H62s/5gtAFiFg3gNm036x0vQwOPZ9WTU6aFiB9VFnrBpgKRoN
	jH+M9J2saCBa19lwBVejDZIAYToQaVRn0oXKdidm3cdKje0TFus9mQCAvCl3ZNiOcQOfoi
	A9E269j5LnDVdl2Z3PrIq1Gdgd5ighkDnwcsO5R1XH/ybkbPJTWbcJlvbRTYiHqSXDRLT4
	G5xEOKtEtd+AUHldPw3yTs7Ua+paR+biur1H6krQ6PzyLd2C5zH117JMNvlMOQ==
Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M49ZP4Kg0z1N8Q;
	Fri, 12 Aug 2022 17:26:21 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f49.google.com with SMTP id o123so1461015vsc.3;
        Fri, 12 Aug 2022 10:26:21 -0700 (PDT)
X-Gm-Message-State: ACgBeo2u7IDSPO30AtLFMakatbr/KgDxZQiyNWJfHedJoaFQq3EKtZRP
	HlbEv8ik0NkvIA/akq+tWag6WMgaqDh2Z/Kfv5w=
X-Google-Smtp-Source: AA6agR48nvUvwUbRSg28WHI5ptEbnlcHfC/OA/sZbEdD9BK1b7M7UoDLb4fm7hlAOylVLlBZdZg8eyHLLpDEx1+/7+c=
X-Received: by 2002:a05:6102:2836:b0:386:91a5:a241 with SMTP id
 ba22-20020a056102283600b0038691a5a241mr2291094vsb.51.1660325181138; Fri, 12
 Aug 2022 10:26:21 -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: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
In-Reply-To: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
From: Nuno Teixeira 
Date: Fri, 12 Aug 2022 18:26:11 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Yasuhiro Kimura 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000a22d2a05e60e94bb"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660325181;
	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=AXw8z0Un6DbgYelpyNiHPctabrjY3d/AHt/k4qjx/TI=;
	b=fhQb+Q4ZYrB8JuQvwVkTZnOUMcgWNE/Z7qWyo6UUhnACgkfW1uvCTsZTLyZBTP2Es9NNFA
	84k87HQrjA0Iec1QPZjS7B1yg9lyLlWkqmvQOaB9z6kmuQVcrCJlP8FuybrkGJPEjRwydu
	ehY/zgsEuKET+Dij3v7N9xoQkxi7wdwGivkrMdOfO0nTfhMqgT57dBtw/FxhSKbfCFUzyt
	iO3ExoOaHACRc9Y8prlBRzhmaItjLuibADjMOtLq33UF1OcWNZ2qfGc2sPkhDXXGTWW2uf
	8PBAK/buKu6U2eNRFGvEE+NUoXJiwZ+V/3LSWaZyJYrDbmVacOKAMCvX5Z5vLQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660325181; a=rsa-sha256; cv=none;
	b=W/ElLb4w0XoAvr2IIjH9FagRPu6G8B7067udMaF4TwZtQfeO95JG4Tnrl8CvfWp4s9E27/
	mAnp+fxKLBVev32YDCauziWrl4twGYJicPnwGQleypa4HbEh39FNgx/rHFfTxFia6bRdan
	5Ooc18xiXqG+poD9zxMlOL2fPggilDIjiJIXSAn2Riox+BlIDJRy16YOzWo8pwOUUkz6Mx
	JjA4zKMg33CYwSA08/sk4+sTIg35Mo+4gb2TTQbC72+6DQESU1aVe2B+svicRVLaPtb/k6
	EOfvD9L375oAFTOrWRNt8cgu5ATMQ5OJgfKaRt6hF6tjBslHb9u2N1hUO5382g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000a22d2a05e60e94bb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Yasu,

Does it needes to update boot loader everytime that we upgrade current?

The only time that I updated was a month ago because of zfs upgrade and I
need to practice how to boot loader bkp file :)

Cheers,

Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 =C3=A0=
(s)
17:56:

> Hello,
>
> I made regular update of my 14-CURRENT amd64 system from
> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
> boot hangup as following.
>
>
> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-h=
angup.png
>
> If I restore previous loader file (that is, loader.efi of
> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
> system boots successfully.
>
> Best Regards.
>
> ---
> Yasuhiro Kimura
>
>

--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000a22d2a05e60e94bb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Yasu,

Does it needes t=
o update boot loader everytime that we upgrade current?

The only time that I updated was a month ago because of zfs upgrade a=
nd I need to practice how to boot loader bkp file :)

Cheers,

Yasuhiro Kimura <yasu@freebsd.org> escreveu no dia sexta, 12/08/2022 =C3=A0(s) 17:56=
:
Hello,



I made regular update of my 14-CURRENT amd64 system from

main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated

EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in

boot hangup as following.



https://people.fre=
ebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png



If I restore previous loader file (that is, loader.efi of

main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then

system boots successfully.



Best Regards.



---

Yasuhiro Kimura






-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--000000000000a22d2a05e60e94bb--

From nobody Fri Aug 12 17:44:35 2022
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 4M4B0G1Fsdz4Y5SH
	for ; Fri, 12 Aug 2022 17:45:18 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4B0G0jpxz3R2B;
	Fri, 12 Aug 2022 17:45:18 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660326318;
	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=AEYAS+rRH0T5/9aeZLmIKDCp6bJN8JyDOzzuWnZglIU=;
	b=igkVj/hJekGa70y9HEjOJiT6jFY8BPFMp7s2HjE3UZNKxX435CyYY1AXWuw59h6pKlkwM2
	XkO0dddMVJJ3wvHXhORAR45PdBLMkKdbL2QIjUhxI0o0IpHUdn4Ac40mn2aXLrY+50LJ3E
	UdpENkUX70v2t/gj+xvLcKogGk9nHCj14UbhMH1Q0paaiblqM2SPfkAyTEu62Oh9fubNEO
	htWJWT7fVovZJXYz7DBwGNysyj4U8yHL1vUgIj5uCo6K7XV4/lZohZVQla4DnXPKMfxRf9
	wpQojCxFSXZV8A+6+cizqE+/jY+k0lXmEq1HAGh4MmwVlt/PrpNKfW31uGGrtg==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:6851:7020:dc58:25c6])
	(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: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4B0F319jz1Mh0;
	Fri, 12 Aug 2022 17:45:17 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Sat, 13 Aug 2022 02:44:35 +0900 (JST)
Message-Id: <20220813.024435.741655799390389695.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura 
In-Reply-To: 
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
	
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660326318;
	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=AEYAS+rRH0T5/9aeZLmIKDCp6bJN8JyDOzzuWnZglIU=;
	b=VB5knLRQooVAxu/hFo+lQxJUmKz4bwB+XFLS5n26NwR02wObO2bvz8xtUgKlVRzPlRCDz6
	dHmjYMVVWpJGA9JSfMoPHhXCgkUfkKnM2KOf/5npfzuZM43fLzDegoDFDTmo7WUzWc9UEc
	+YLjr2qCciDEIo6r0/fqxi6kjqm0+JPcv4eBQfYwNjN4E0YzWTaA34hcuTzmhF1ySO04eT
	q2rBnIddxGeg708+d42+nS52WN0HcFn3WdpGtk2NfB6lK+tZFv1vruwPmOl2truVy3WBRx
	HYV6qOB4tqpph81SpHG/O4oAX4o7rfcaDN9f4N+TuMtJLeUj9wRGX/VrBsHKew==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660326318; a=rsa-sha256; cv=none;
	b=vSCkdN2Ez9G19GZRnAxzzbypdkqx8QJcGdUMTmCuk1eSeyucU5vM/B148fvtkbfVu5Tl3e
	MXdwubtOIHC3eaHJWF+ya9FU8HAG0/5WQT58ilHKl4Vnq9zEiXEuPeSjZ5gFaHmmc/izlD
	I/MyxWOPRQ4ceh1BSGq73OjSPOr/WC2sTSx4j5V9mPZS2wBqBqaK/KzsgVqh/FFAFuD/59
	PXb9JOVnZiPrR+aek9av2NEAyqrfL6m74f0dbdaxqiRXWcMnvZHMGOWY6YZdgasuaMOz8r
	mtxTPuUAFd6+Om0yOu5CoPhnO2FT/u9N7UApeYHShiC8QDYi0VV8GLJ8cq/Exg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

From: Nuno Teixeira 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Fri, 12 Aug 2022 18:26:11 +0100

> Hello Yasu,
> 
> Does it needes to update boot loader everytime that we upgrade current?
 
No, you need not.

> The only time that I updated was a month ago because of zfs upgrade and I need to practice how to boot
> loader bkp file :)

I update boot loader everytime because I'd like to do it :-).
And sometimes problem hits upon me like this time and I contribute to
debugging base system :-):-).

---
Yasuhiro Kimura

From nobody Fri Aug 12 20:03:02 2022
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 4M4F3Q599Fz4Z1tp
	for ; Fri, 12 Aug 2022 20:03:14 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4F3Q4bq8z3mMZ;
	Fri, 12 Aug 2022 20:03:14 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660334594;
	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=rdT5kXefbRNDQ6IXI0pAwP+q2UwofpNy1iogUcRpYvI=;
	b=Ei4SaKKJkqMl3ogng4Ywb8Lg/Rx3I5nSOZ+0DqDUOa9jid9SPZfmQax6A4fhyN9FeSKr0K
	jE+0TNI/8h/SJ6AMtxjLjble0+TZ2slxeZPO+hd0pIhfgkV1BhptmWrLZWWLzyGzGwElqU
	vy+OFSeliRn8jfpFirTEt2WARPYUhMYXIzhUPaiJaqXAzzA/BeqpWKjjTCKZnVJQJUDGsf
	0B+01YXifzMCNsyB/gxWgk+yNfoO6Ko1Liq8C+vsFp240BP02woZ2TyqubtabjmlgT0VMH
	XJ4kkTf9rEirEKeRdYypW5FannWa/MBDQYGCY8ZW/TuYjVq4Wl3R573d5/fJ+g==
Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4F3Q3dj8z1Qbp;
	Fri, 12 Aug 2022 20:03:14 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f41.google.com with SMTP id d126so1819653vsd.13;
        Fri, 12 Aug 2022 13:03:14 -0700 (PDT)
X-Gm-Message-State: ACgBeo2FCwDSKzMkvzRgK1KBaAJvvQ4S0bzueuotnQxSuJLkJNuXVrxI
	9ddaBDA4ZSrUqoqH5uycfut99BTozAPzAOY9ad4=
X-Google-Smtp-Source: AA6agR4REmaTMBl0hyXC87xbXZ61zeagiY8Xzo3LK6nlPbJzchOPgjsIHXEmsSd8RIuX82fSDPcuGg4vp3fTnMfxLtU=
X-Received: by 2002:a05:6102:374:b0:388:9bd4:5639 with SMTP id
 f20-20020a056102037400b003889bd45639mr2710738vsa.53.1660334594075; Fri, 12
 Aug 2022 13:03:14 -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: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
  <20220813.024435.741655799390389695.yasu@FreeBSD.org>
In-Reply-To: <20220813.024435.741655799390389695.yasu@FreeBSD.org>
From: Nuno Teixeira 
Date: Fri, 12 Aug 2022 21:03:02 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Yasuhiro Kimura 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000b035be05e610c5fa"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660334594;
	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=rdT5kXefbRNDQ6IXI0pAwP+q2UwofpNy1iogUcRpYvI=;
	b=BeBd2oNItz9WzAZyHgI/bI1Ix9AlHDT5bi/RlIbazuDBpvnnh2i+QrTKxOGO5b4WDFl34k
	nBkwB/4zOg8UYN5IP7LiIP7G9BtqSgvbhu9DNrGP7vh7xicdnbbeiSezipO2FBckHJsEHK
	8ZoIgbuTB1H9+94Rp6CAPC4MuY5YpmiEbiOxOa0rP7+LFbWje9RqfBswJ7pAWTidqL7+kW
	7CUOGBd+AlyNNp86pZmVF3GifeH4R9tpGMlO1CEzaBcmyDsa0sp84sm8ePxlsz/DmjLSQW
	BYvxqfJMhJs26EECRCBEVnwj/j+myppmUDMkd0E4WseKcItSBkoUD8efKBoRXA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660334594; a=rsa-sha256; cv=none;
	b=rgdYDjHcsc12EXsjBTTfF0KzQmzGm4745dikoGQST1vqbZ+gU8DZtiP6/MEvosZqoxAqor
	VREw0M6bCzAWLrXw5jd/IbtO0W3Z8XJ9PImah7c1DREXqQoyX2TECyf52we/yX4nxIIRpJ
	nxXaiNNcGIU0Xb17SkTDx8lJ3YXUYzTza9vomTJoj96ALioQfTBV1u7pjhtflpKfuA8muH
	k299QLS1B5eIQKmTJOa/oNMoWxBtjEU1z6AaZdNkc3Y5Lk8FNgcOVf0Tv/uDG9dY5vriP4
	JjwsDRz9EX9ZKKG0fZXPWYV9HG1DZJBPtzZkHNErdXgrSY+AivK27Do1xQ7Qfw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000b035be05e610c5fa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm searching without success to load a bkp loader in case of boot failure.

Upgrade process willl be like:
---
mount -t msdosfs /dev/nvd0p1 /mnt
cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
---

I can't find the right docs to load bootx64.old.
Could you tell me what you did to solve your boot?

Thanks

Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 =C3=A0=
(s)
18:45:

> From: Nuno Teixeira 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Fri, 12 Aug 2022 18:26:11 +0100
>
> > Hello Yasu,
> >
> > Does it needes to update boot loader everytime that we upgrade current?
>
> No, you need not.
>
> > The only time that I updated was a month ago because of zfs upgrade and
> I need to practice how to boot
> > loader bkp file :)
>
> I update boot loader everytime because I'd like to do it :-).
> And sometimes problem hits upon me like this time and I contribute to
> debugging base system :-):-).
>
> ---
> Yasuhiro Kimura
>
>

--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000b035be05e610c5fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'm searching without success to load a bkp loade=
r in case of boot failure.

Upgrade process willl b=
e like:
---
mount -t msdosfs /dev/nvd0p1 /mnt
cp /mnt/efi/b=
oot/bootx64.efi /mnt/efi/boot/bootx64.old
cp /boot/loader.efi /mnt/efi/b=
oot/bootx64.efi
---

I can't find the right =
docs to load bootx64.old.
Could you tell me what you did to solve=
 your boot?

Thanks

Yasuhiro Kimura <=
yasu@freebsd.org> escreveu no di=
a sexta, 12/08/2022 =C3=A0(s) 18:45:
From: Nuno Teixeira <eduardo@freebsd.org>

Subject: Re: Updating EFI boot loader results in boot hangup

Date: Fri, 12 Aug 2022 18:26:11 +0100



> Hello Yasu,

> 

> Does it needes to update boot loader everytime that we upgrade current=
?



No, you need not.



> The only time that I updated was a month ago because of zfs upgrade an=
d I need to practice how to boot

> loader bkp file :)



I update boot loader everytime because I'd like to do it :-).

And sometimes problem hits upon me like this time and I contribute to

debugging base system :-):-).



---

Yasuhiro Kimura






-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--000000000000b035be05e610c5fa--

From nobody Fri Aug 12 20:09:23 2022
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 4M4FBh70Jkz4Z39W
	for ; Fri, 12 Aug 2022 20:09:32 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4FBh08PRz3ny4;
	Fri, 12 Aug 2022 20:09:32 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=Kl1y49iBDE+UhQWR3CV4dVaLyU4IFxJVOU3vcYaDAlI=; b=HhLo3Yv6KP9LWoBnghTlq2mVu8
	BxHkbb5/n/bMvMZrbn9ucwCcjlKueJZ5Irtv53EHiUIxAtlcj9pioF1fSockO+FtUwyrOMINTw/1W
	v5NJPOpFXwbuaIhf47mio9LH6LsvvDNB84iqlJNa1mzVdIft9sFlhEQuhK/gryAAd6CbqOIQr6ggU
	MJeGu6VixciGoHfyHA8uL9+ZVxvP8VgBAwfxZZuDYVH8NABMXakNqdnv9slm0adtBIn0eMLnH/s1j
	CR1jOkvH1sAy7FI1H7XWgPNYeTPXrqDEOnfRYVYYulYkbcdHTUdQMp4RAedAzs9Epdm6r+6QLcTdN
	cwHFv8RQ==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:59616 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oMayB-0003zP-97;
	Fri, 12 Aug 2022 15:09:23 -0500
Received: from 2600:1700:210:b18f:b9c7:5d38:a0f5:985a
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 12 Aug 2022 15:09:23 -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
Date: Fri, 12 Aug 2022 15:09:23 -0500
From: Larry Rosenman 
To: Nuno Teixeira 
Cc: Yasuhiro Kimura , FreeBSD CURRENT
 
Subject: Re: Updating EFI boot loader results in boot hangup
In-Reply-To: 
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
 
 <20220813.024435.741655799390389695.yasu@FreeBSD.org>
 
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: multipart/alternative;
 boundary="=_49eb67faa3b190b6f5709d9ed53a4a6f"
X-Rspamd-Queue-Id: 4M4FBh08PRz3ny4
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=HhLo3Yv6;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=_49eb67faa3b190b6f5709d9ed53a4a6f
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed



I would assume just rename the bootx64.old to bootx64.efi

and/or put it in a different directory that EFI can see

On 08/12/2022 3:03 pm, Nuno Teixeira wrote:

> I'm searching without success to load a bkp loader in case of boot 
> failure.
> 
> Upgrade process willl be like:
> ---
> mount -t msdosfs /dev/nvd0p1 /mnt
> cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
> cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
> ---
> 
> I can't find the right docs to load bootx64.old.
> Could you tell me what you did to solve your boot?
> 
> Thanks
> 
> Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 
> à(s) 18:45:
> 
>> From: Nuno Teixeira 
>> Subject: Re: Updating EFI boot loader results in boot hangup
>> Date: Fri, 12 Aug 2022 18:26:11 +0100
>> 
>>> Hello Yasu,
>>> 
>>> Does it needes to update boot loader everytime that we upgrade 
>>> current?
>> 
>> No, you need not.
>> 
>>> The only time that I updated was a month ago because of zfs upgrade 
>>> and I need to practice how to boot
>>> loader bkp file :)
>> 
>> I update boot loader everytime because I'd like to do it :-).
>> And sometimes problem hits upon me like this time and I contribute to
>> debugging base system :-):-).
>> 
>> ---
>> Yasuhiro Kimura
> 
> --
> 
> Nuno Teixeira
> FreeBSD Committer (ports)

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_49eb67faa3b190b6f5709d9ed53a4a6f
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



I would assume just rename the bootx64.old to bootx64.efi


and/or put it in a different directory that EFI can see 





On 08/12/2022 3:03 pm, Nuno Teixeira wrote:








I'm searching without success to load a bkp loader in case of boot fai=
lure.


 


Upgrade process willl be like:


---
mount -t msdosfs /dev/nvd0p1 /mnt
cp /mnt/efi/boot/bootx=
64.efi /mnt/efi/boot/bootx64.old
cp /boot/loader.efi /mnt/efi/boot/boo=
tx64.efi
---


 


I can't find the right docs to load bootx64.old.


Could you tell me what you did to solve your boot?


 


Thanks








Yasuhiro Kimura <yasu@freebsd.org> escreveu n=
o dia sexta, 12/08/2022 à(s) 18:45:


From: Nuno Teixeira <eduardo@freebsd.org=
>
Subject: Re: Updating EFI boot loader results in boot hangup<=
br />Date: Fri, 12 Aug 2022 18:26:11 +0100

> Hello Yasu,
> 
> Does it needes to update boot loader everytime that we upg=
rade current?

No, you need not.

> The only time th=
at I updated was a month ago because of zfs upgrade and I need to practice =
how to boot
> loader bkp file :)

I update boot loader ev=
erytime because I'd like to do it :-).
And sometimes problem hits upon=
 me like this time and I contribute to
debugging base system :-):-).
---
Yasuhiro Kimura






-- 




Nuno Teixeira
FreeBSD=
 Committer (ports)













=
-- 
Larry Rosenman     &n=
bsp;            =
;   http://www.lerctr.org/~ler
Phone: +1 =
214-642-9640           &n=
bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=






--=_49eb67faa3b190b6f5709d9ed53a4a6f--

From nobody Fri Aug 12 20:25:15 2022
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 4M4FXz73qNz4Z6Tg
	for ; Fri, 12 Aug 2022 20:25:23 +0000 (UTC)
	(envelope-from andreas@naund.org)
Received: from son.naund.org (son.naund.org [66.79.136.47])
	(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 4M4FXy32QCz3rYH
	for ; Fri, 12 Aug 2022 20:25:22 +0000 (UTC)
	(envelope-from andreas@naund.org)
Received: by son.naund.org (Postfix, from userid 1000)
	id 2563840909ED; Fri, 12 Aug 2022 20:25:15 +0000 (UTC)
Date: Fri, 12 Aug 2022 20:25:15 +0000
From: Andreas Ott 
To: freebsd-current@freebsd.org
Subject: updating of prebuilt packages with pkg
Message-ID: <20220812202515.GC1876@naund.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
User-Agent: Mutt/1.5.21-29
X-Rspamd-Queue-Id: 4M4FXy32QCz3rYH
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of andreas@naund.org designates 66.79.136.47 as permitted sender) smtp.mailfrom=andreas@naund.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:66.79.136.47];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:22211, ipnet:66.79.136.0/24, country:US];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[naund.org];
	FREEFALL_USER(0.00)[andreas];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I am not sure if this issue is more for -stable or -ports, so I start
here. The visible problem was that after 'pkg upgrade' certbot stopped
working.

I am running systems that after initial install do binary-only upgrades
for both core and ports with freebsd-update(8) and pkg(8). I do not have
the /usr/src/ or /usr/ports/ trees installed in order to save space. For 
policy reasons these use pre-built packages and I will never compile 
anything from source on these systems. This one is on 12.3-RELEASE .

Recently I encountered that the usual cadence of

pkg update
pkg upgraade
pkg autoremove
pkg clean

left me with several packages in state "?". 

$ pkg version |grep \?  
[...]
py38-acme-1.22.0,1                 ?
py38-certbot-1.22.0,1              ?
[...]
ruby27-bdb-0.6.6_8                 ?

which tells me that these have been superseded by something else.

Tracking this down on a system that does have /usr/ports installed I
could find in /usr/ports/UPDATING that in my example the default version
of python had been upgraded, see entry
20220626:
  AFFECTS: users of python
[...]
  For users of pre-build packages:
  # sh
  # for i in $(pkg query -g %n 'py38-*'); do pkg set -yn ${i}:py39-${i#py38-}; done
  # pkg upgrade
[...]

How would a user of pre-built packages find out about the need to run the
'pkg set' command? The dependency and integrity solver in pkg did not show 
any notices about it. An example would be p7zip.

I believe a similar issue exists if a port gets removed entirely, in which
case a previously installed package shows in state "?". No notification
is given by pkg about the fact that is was deprecated.

Using the instructions above I was able to get back to a working certbot.

In the case of ruby27 the pkg commands above handled this gracefully
on its own, see /usr/ports/UPDATING entry from 20220421 
"ruby: 2.7.x -> 3.0.4_2,1".


Thanks, andreas
-- 
andreas@naund.org

From nobody Fri Aug 12 20:25:33 2022
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 4M4FYP1F17z4Z6pg
	for ; Fri, 12 Aug 2022 20:25:45 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4FYN6r3Cz3sjC;
	Fri, 12 Aug 2022 20:25:44 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660335945;
	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=MGJRZMFHsjgPu8PliGF5OdK5wEy2iS8xOqSP/ot0yBI=;
	b=io16mv26EAimJMN0vtXcQ3MFBjzZWTFA5o1mWARvp0lOlNH4ZhUR04KxHzC7nkOvwQy+CM
	17df4RJvOGgbT8IvPkIK9YUNUQJXgcZWTchU59/RcsLnaLRo/xpa35H0tV+7UOTlwUhSQi
	JdFP6fA5K0VG7Eic7cKBixz7JadvVAInRtx8wH4UC584aFi7nvVNQ/yrUcB7ExdIv7Ov16
	i0SiFZQaXmXBCSlnxZalDdSZOo5AxtXeMnJbE97EJ26Tbq1mkprlbC9HnKGWSMtTmEuH1+
	ZmCAMOWw3jk1VBhDwfKuxUJuf7FTYeAr5pO086roG4KR9QlcRFkEpz7EoH4DaQ==
Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4FYN5RPsz1Qmk;
	Fri, 12 Aug 2022 20:25:44 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f49.google.com with SMTP id 125so1888066vsd.5;
        Fri, 12 Aug 2022 13:25:44 -0700 (PDT)
X-Gm-Message-State: ACgBeo1lDIEeVLDm+qgDpoO4cndQYEOOrvsWaNngM0EpF7p+oESH+GgP
	HMQR6ll3rPn7sMUlgfQ8XyMWsxcGxzvBKbwJ1tg=
X-Google-Smtp-Source: AA6agR4kyOHtLR815+IMzdbfKnpgCSXozNBuDYMyGodIEzHYml/PBzBNOLMRsh7LMdBynn2XzZkFi7Od2NJp9QuM6VQ=
X-Received: by 2002:a05:6102:2836:b0:386:91a5:a241 with SMTP id
 ba22-20020a056102283600b0038691a5a241mr2567477vsb.51.1660335944369; Fri, 12
 Aug 2022 13:25:44 -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: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
 
 <20220813.024435.741655799390389695.yasu@FreeBSD.org> 
 
In-Reply-To: 
From: Nuno Teixeira 
Date: Fri, 12 Aug 2022 21:25:33 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Larry Rosenman 
Cc: Yasuhiro Kimura , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000002c0b6d05e6111699"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660335945;
	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=MGJRZMFHsjgPu8PliGF5OdK5wEy2iS8xOqSP/ot0yBI=;
	b=msE0hFPRwPeGe/Mw8qwYB4TjfScAc0UplCSMsNsyg09oj4o2WLbXjVrIAqmhTLurma8S2p
	IJvEOVaRNEz9vGgvANZTmKY46cjYL/MdBaDoHsvrGspaH3SSLgHld+KrEbdYM06XtzMhEg
	XUhitvobvSSDx+DDUl3j5tM/o0Y/ErNh4vi7fB+fP4QNovBIVB40C61t8EPqw1NHsK8uRL
	ftoYol0KXg4sKnv5GhEf8+Oi+f8AYynguvoM638bIJPiIgipwOKxIwGb9UtYnfjoZBE9U+
	mt+E+cwUsKi7dISb18HAhvrmx6hfLkZ4Pyajxqp783AvLzHFDH7H9vbcTy8Kvg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660335945; a=rsa-sha256; cv=none;
	b=fvFiM7Uokl7pESoxawhtjvSV1sX3Egz/+aZ5+09Z4CV/Fo4GRmuvl5T1M0HcyD+/o+jOKF
	GPCs8mXev1iiaeTPvSc8cMcgnRldpDducRXU/SU6yBpTxda7w0sfreg4J17nRp7u3lYtCe
	3Jj4LlA4DuJ+2K0H7UOB1lXAhyLGnTXBnPs7vd4uGCkvjTFCOjdmVxLBPnjcZrWIUN2AJW
	7ygyfzKzSKop+XYbybvAomZo3rvnj6fYzNsscBvoEEi6zNuMcyyZE3ftcpGpvoRbai32TQ
	ZpicFHAipjEaT6lU1ga1BNnSpTLficS73ATz0WuXoF3wv9+cwLiBQljFA/TgKg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000002c0b6d05e6111699
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The problem is if boot is failing, how to mount and rename it?

I'm looking for a way, if possible, to boot directly bkp boot64x in case of
failure.
I was hoping to find it in loader(8) or uefi(8)...

Larry Rosenman  escreveu no dia sexta, 12/08/2022 =C3=A0(s)
21:09:

> I would assume just rename the bootx64.old to bootx64.efi
>
> and/or put it in a different directory that EFI can see
>
>
> On 08/12/2022 3:03 pm, Nuno Teixeira wrote:
>
> I'm searching without success to load a bkp loader in case of boot failur=
e.
>
> Upgrade process willl be like:
> ---
> mount -t msdosfs /dev/nvd0p1 /mnt
> cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
> cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
> ---
>
> I can't find the right docs to load bootx64.old.
> Could you tell me what you did to solve your boot?
>
> Thanks
>
> Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 =C3=
=A0(s)
> 18:45:
>
> From: Nuno Teixeira 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Fri, 12 Aug 2022 18:26:11 +0100
>
> > Hello Yasu,
> >
> > Does it needes to update boot loader everytime that we upgrade current?
>
> No, you need not.
>
> > The only time that I updated was a month ago because of zfs upgrade and
> I need to practice how to boot
> > loader bkp file :)
>
> I update boot loader everytime because I'd like to do it :-).
> And sometimes problem hits upon me like this time and I contribute to
> debugging base system :-):-).
>
> ---
> Yasuhiro Kimura
>
>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>
>
> --
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000002c0b6d05e6111699
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The problem is if boot is failing, how to mount and r=
ename it?

I'm looking for a way, if possible, to boot=
 directly bkp boot64x in case of failure.
I was hoping to find it=
 in loader(8) or uefi(8)...

<=
div dir=3D"ltr" class=3D"gmail_attr">Larry Rosenman <ler@lerctr.org> escreveu no dia sexta, 12/08/2022 =C3=
=A0(s) 21:09:


I would assume just rename the bootx64.old to bootx64.efi


and/or put it in a different directory that EFI can see=C2=A0





On 08/12/2022 3:03 pm, Nu=
no Teixeira wrote:








I'm searching without success to load a bkp loader in case of boot=
 failure.


=C2=A0


Upgrade process willl be like:


---
mount -t msdosfs /dev/nvd0p1 /mnt
cp /mnt/efi/boot/bootx64.e=
fi /mnt/efi/boot/bootx64.old
cp /boot/loader.efi /mnt/efi/boot/bootx64.e=
fi
---


=C2=A0


I can't find the right docs to load bootx64.old.


Could you tell me what you did to solve your boot?


=C2=A0


Thanks








-- 




Nuno Teixeira
Fr=
eeBSD Committer (ports)













--=C2=A0<=
br>Larry Rosenman =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht=
tp://www.lerctr.org/~ler
Phone: +1 214-642-9640 =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0E-Mail: ler@lerctr.o=
rg
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106








-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--0000000000002c0b6d05e6111699--

From nobody Fri Aug 12 20:26:08 2022
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 4M4FYt1h6jz4Z6tp
	for ; Fri, 12 Aug 2022 20:26:10 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4FYs4tyWz3tfN;
	Fri, 12 Aug 2022 20:26:09 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=wZONfrlYoso0KkqAbZk2zUNi05V98fyaLUa78IAHyc0=; b=Xitg5jSgys1+QQAEk7Dk8GpXyY
	YeyGGmL9GxoOViy5rxldWRrF7nTh/ndPyApgIadUrFYMuHXbZg6TXZ7jzkykdVxVfgx2LTLC/YvKy
	Rqbs6iB+ipPfUhdHyxeWhtLRUgf2D0xTWMVCJ5VQLrbXMJzdKDxpUCAJ1Q6llYnQSSjYMoQf0YQwf
	KznBO5/G+XWmNHhkz8nxbZ633ZXdgp9gb1DW51+ALwG5FtScmeq8YaARGG7wc4BSCnUROqHJt3sBp
	vtb3Gm5gvRhH5I5T9b9L8UCol7irNmu5ZPUxZ/+E3qMFIyuG23/rIQ+8g5hN2qrrosxKoRfI/J8F2
	hegCkIBA==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:15798 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oMbEP-0004HR-4E;
	Fri, 12 Aug 2022 15:26:09 -0500
Received: from 2600:1700:210:b18f:b9c7:5d38:a0f5:985a
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 12 Aug 2022 15:26:08 -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
Date: Fri, 12 Aug 2022 15:26:08 -0500
From: Larry Rosenman 
To: Nuno Teixeira 
Cc: Yasuhiro Kimura , FreeBSD CURRENT
 
Subject: Re: Updating EFI boot loader results in boot hangup
In-Reply-To: 
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
 
 <20220813.024435.741655799390389695.yasu@FreeBSD.org>
 
 
 
Message-ID: <78c22181179d9c7f9fcea829002095eb@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: multipart/alternative;
 boundary="=_90ff7f40576326d8e776db908fd72d51"
X-Rspamd-Queue-Id: 4M4FYs4tyWz3tfN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=Xitg5jSg;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_SPF_ALLOW(-0.20)[+mx:c];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[lerctr.org:+];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=_90ff7f40576326d8e776db908fd72d51
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed



boot off a memstick?

On 08/12/2022 3:25 pm, Nuno Teixeira wrote:

> The problem is if boot is failing, how to mount and rename it?
> 
> I'm looking for a way, if possible, to boot directly bkp boot64x in 
> case of failure.
> I was hoping to find it in loader(8) or uefi(8)...
> 
> Larry Rosenman  escreveu no dia sexta, 12/08/2022 à(s) 
> 21:09:
> 
> I would assume just rename the bootx64.old to bootx64.efi
> 
> and/or put it in a different directory that EFI can see
> 
> On 08/12/2022 3:03 pm, Nuno Teixeira wrote:
> 
> I'm searching without success to load a bkp loader in case of boot 
> failure.
> 
> Upgrade process willl be like:
> ---
> mount -t msdosfs /dev/nvd0p1 /mnt
> cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
> cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
> ---
> 
> I can't find the right docs to load bootx64.old.
> Could you tell me what you did to solve your boot?
> 
> Thanks
> 
> Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 
> à(s) 18:45: From: Nuno Teixeira 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Fri, 12 Aug 2022 18:26:11 +0100
> 
>> Hello Yasu,
>> 
>> Does it needes to update boot loader everytime that we upgrade 
>> current?
> 
> No, you need not.
> 
>> The only time that I updated was a month ago because of zfs upgrade 
>> and I need to practice how to boot
>> loader bkp file :)
> 
> I update boot loader everytime because I'd like to do it :-).
> And sometimes problem hits upon me like this time and I contribute to
> debugging base system :-):-).
> 
> ---
> Yasuhiro Kimura
> 
> --
> 
> Nuno Teixeira
> FreeBSD Committer (ports)

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 

Nuno Teixeira
FreeBSD Committer (ports)

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_90ff7f40576326d8e776db908fd72d51
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



boot off a memstick?





On 08/12/2022 3:25 pm, Nuno Teixeira wrote:








The problem is if boot is failing, how to mount and rename it?


I'm looking for a way, if possible, to boot directly bkp boot64x in ca=
se of failure.


I was hoping to find it in loader(8) or uefi(8)...








Larry Rosenman <ler@lerctr.org> escreveu no dia=
 sexta, 12/08/2022 à(s) 21:09:






I would assume just rename the bootx64.old to bootx64.efi


and/or put it in a different directory that EFI can see 





On 08/12/2022 3:03 pm, =
Nuno Teixeira wrote:








I'm searching without success to load a bkp loader in case of boot fai=
lure.


 


Upgrade process willl be like:


---
mount -t msdosfs /dev/nvd0p1 /mnt
cp /mnt/efi/boot/bootx=
64.efi /mnt/efi/boot/bootx64.old
cp /boot/loader.efi /mnt/efi/boot/boo=
tx64.efi
---


 


I can't find the right docs to load bootx64.old.


Could you tell me what you did to solve your boot?


 


Thanks








Yasuhiro Kimura <yasu@freebsd.org> escreveu no dia sexta, 12/08/2022=
 à(s) 18:45:


From: Nuno Teixeira <eduardo@freebsd.org>
Subject: R=
e: Updating EFI boot loader results in boot hangup
Date: Fri, 12 Aug 2=
022 18:26:11 +0100

> Hello Yasu,
> 
> Does it=
 needes to update boot loader everytime that we upgrade current?

No, you need not.

> The only time that I updated was a month=
 ago because of zfs upgrade and I need to practice how to boot
> lo=
ader bkp file :)

I update boot loader everytime because I'd like=
 to do it :-).
And sometimes problem hits upon me like this time and I=
 contribute to
debugging base system :-):-).

---
Yasuh=
iro Kimura






-- 




Nuno Teixeira
FreeBSD=
 Committer (ports)













--&=
nbsp;
Larry Rosenman         &=
nbsp;           http://www.lerctr.org/~ler
Phone: +1 214-642-9640  &nbs=
p;            &=
nbsp; E-Mail: ler=
@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106











-- 




Nuno Teixeira
FreeBSD=
 Committer (ports)













=
-- 
Larry Rosenman     &n=
bsp;            =
;   http://www.lerctr.org/~ler
Phone: +1 =
214-642-9640           &n=
bsp;     E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106=






--=_90ff7f40576326d8e776db908fd72d51--

From nobody Fri Aug 12 20:48:41 2022
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 4M4G5L60g7z4ZDTW
	for ; Fri, 12 Aug 2022 20:49:58 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4G5L5Q10z40gC;
	Fri, 12 Aug 2022 20:49:58 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660337398;
	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=hZ1Goe2Mjz1LWv00FCuIIpvOLixZS9OM1211x8iF9us=;
	b=jQDpkeCOW+/77qY8cCUBj0Ke6ztWCgGe1jvAGuf7SzeZQaVaJ3x3uf/iEgCzuw7aQ1Mseh
	kI9kyjvl7eSXnL+Zr8gVDPL+bs7piYtlydt/UY228ByAwGPNIkCDetHCQUrCcppR7R/vMJ
	xv2JFV6wHpVHrXDZvl3zuZBY8ckazJsYFrs3b4l/vx6QiIGHOikqev1rlTkumy13Oyws1K
	gZkSuup4qX+UUU+9VxdPd90f4xyE7kp41hpBWl8qkPCUXeoLipHgX69fOeedUnNns00BFV
	nTY3bUQmCxpf8iIfrC3NnQ4DMAoZycZLPGjqzSdBgeZxHaFExg+X9xSzxp/0gg==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:6851:7020:dc58:25c6])
	(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: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4G5L0Sjvz1QRs;
	Fri, 12 Aug 2022 20:49:57 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Sat, 13 Aug 2022 05:48:41 +0900 (JST)
Message-Id: <20220813.054841.1081731685466016992.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura 
In-Reply-To: 
References: 
	<20220813.024435.741655799390389695.yasu@FreeBSD.org>
	
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660337398;
	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=hZ1Goe2Mjz1LWv00FCuIIpvOLixZS9OM1211x8iF9us=;
	b=QuUm6p+aRC9oJZr5LL7yH/LHHmPVeHT4r8V18mpkJA2g5zUppxeKYOPVDiLEupKK1ZXiCT
	gCyBvMFG7x4XpNswJgZXOauN1eaH/2ZlgUwCnQbLQIhBcSKPOjrLAzLNF3FO6i/8pWbYKm
	anrJQIEEVMyxfrCIBClDek4C0RYPuZ4cptEkDJhRTnwTTABF5LhsKa2Wig7oEfz5MSMq2W
	506/4lV13pPmKoLl8c0Hw+tal063y9EVNw1DCS+k45yURZPK34/Tx9HTwXCkX07FXwBcPu
	fFf3j4RMLInmQsUJoqt1m7AmBCCjZhiUiKS7ebn86p8o7yX7RAdpOxljdx8v5A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660337398; a=rsa-sha256; cv=none;
	b=v5ozhCb1S4Vb24pKF94RfwUifEGYM8Js1+EXcyeShQgFWCJWfMmTN4olJd0QzGC40VtGGQ
	tC+rD4fAs3ybzzxzgPVGzOu0CPX7TPBBmkiZByYjB9S0l40AShTEqDoZUZfZIkLCZMGNEQ
	izuef6flq/DXGlcS7ARBAuENU+sW8N+ltdkCDse1TO/Hs0pa1BdU7ghHHiN535h7BEEUs6
	KG5KLy26RzYzVROhFhjDG+8eRvx6QIUzMw4DSZFFCQkINh8H45/+ADqreghnTGawZtNty9
	p2ON+UES7JExyDJ69wRL9RS7CEI3bKAFRMYyYzOVLI7WwFvxscwDx0lvBVIWlg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

From: Nuno Teixeira 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Fri, 12 Aug 2022 21:03:02 +0100

> I'm searching without success to load a bkp loader in case of boot failure.
> 
> Upgrade process willl be like:
> ---
> mount -t msdosfs /dev/nvd0p1 /mnt
> cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
> cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
> ---
> 
> I can't find the right docs to load bootx64.old.
> Could you tell me what you did to solve your boot?
> 
> Thanks

I use VirturalBox to run 14-CURRENT system. UEFI BIOS of VirtualBox
provides a way to select loader file and boot from it. So I take
following steps when updating loader file.

1. cd /boot/efi/efi/freebsd
2. mv loader.efi loader.backup.efi
3. cp -a /boot/loader.efi .

And when boot from new loader file fails, I enter UEFI BIOS, select
loader.backup.efi and boot from it.

As you can see, above way depends on the feature of VirturalBox. So
it depends on your hardware whether or not you can adopt it. As Larry
pointed out, surest way is to boot from install media such as memstick
or cdrom.

---
Yasuhiro Kimura

From nobody Sat Aug 13 07:24:07 2022
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 4M4X9H5FcFz4Z3LC
	for ; Sat, 13 Aug 2022 07:24:19 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4X9G2tHKz47XT;
	Sat, 13 Aug 2022 07:24:17 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 27D7O7MC064705;
	Sat, 13 Aug 2022 16:24:08 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Sat, 13 Aug 2022 16:24:07 +0900
From: Tomoaki AOKI 
To: Larry Rosenman 
Cc: Nuno Teixeira , Yasuhiro Kimura ,
        FreeBSD CURRENT 
Subject: Re: Updating EFI boot loader results in boot hangup
Message-Id: <20220813162407.82d8bf7adf51da52cba13e4d@dec.sakura.ne.jp>
In-Reply-To: <78c22181179d9c7f9fcea829002095eb@lerctr.org>
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
	
	<20220813.024435.741655799390389695.yasu@FreeBSD.org>
	
	
	
	<78c22181179d9c7f9fcea829002095eb@lerctr.org>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4M4X9G2tHKz47XT
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[sakura.ne.jp];
	RCPT_COUNT_THREE(0.00)[4];
	HAS_ORG_HEADER(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Or multiple installation in the same computer.

For me, main and stable/13 are installed in different drive.

So I can boot into healthy installation, mount problematic ESP,
and alter broken bootx64.efi with known-to-work one.

Usually, to boot into healthy installation, choose boot drive on UEFI
menu.


On Fri, 12 Aug 2022 15:26:08 -0500
Larry Rosenman  wrote:

> 
> 
> boot off a memstick?
> 
> On 08/12/2022 3:25 pm, Nuno Teixeira wrote:
> 
> > The problem is if boot is failing, how to mount and rename it?
> > 
> > I'm looking for a way, if possible, to boot directly bkp boot64x in 
> > case of failure.
> > I was hoping to find it in loader(8) or uefi(8)...
> > 
> > Larry Rosenman  escreveu no dia sexta, 12/08/2022 à(s) 
> > 21:09:
> > 
> > I would assume just rename the bootx64.old to bootx64.efi
> > 
> > and/or put it in a different directory that EFI can see
> > 
> > On 08/12/2022 3:03 pm, Nuno Teixeira wrote:
> > 
> > I'm searching without success to load a bkp loader in case of boot 
> > failure.
> > 
> > Upgrade process willl be like:
> > ---
> > mount -t msdosfs /dev/nvd0p1 /mnt
> > cp /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.old
> > cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
> > ---
> > 
> > I can't find the right docs to load bootx64.old.
> > Could you tell me what you did to solve your boot?
> > 
> > Thanks
> > 
> > Yasuhiro Kimura  escreveu no dia sexta, 12/08/2022 
> > à(s) 18:45: From: Nuno Teixeira 
> > Subject: Re: Updating EFI boot loader results in boot hangup
> > Date: Fri, 12 Aug 2022 18:26:11 +0100
> > 
> >> Hello Yasu,
> >> 
> >> Does it needes to update boot loader everytime that we upgrade 
> >> current?
> > 
> > No, you need not.
> > 
> >> The only time that I updated was a month ago because of zfs upgrade 
> >> and I need to practice how to boot
> >> loader bkp file :)
> > 
> > I update boot loader everytime because I'd like to do it :-).
> > And sometimes problem hits upon me like this time and I contribute to
> > debugging base system :-):-).
> > 
> > ---
> > Yasuhiro Kimura
> > 
> > --
> > 
> > Nuno Teixeira
> > FreeBSD Committer (ports)
> 
> -- 
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> 
> -- 
> 
> Nuno Teixeira
> FreeBSD Committer (ports)
> 
> -- 
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106


-- 
Tomoaki AOKI    

From nobody Sat Aug 13 15:37:15 2022
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 4M4l6H3gyHz4Z6r6
	for ; Sat, 13 Aug 2022 15:37:27 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4l6H39l7z3CxP;
	Sat, 13 Aug 2022 15:37:27 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660405047;
	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=PG2+3/PtYat3GJHK/LJAb7wECzANlLQU0a58R/0qz9k=;
	b=hD92wQf4S4/tuUYFXAnoP/b9VJ2VAMT/qMrsR476fm8DAK1VGkni8zY9IsBjefa1jrHpO/
	XsBCIODVgYiZmLzQsfPrkjoAkv5qQ7HmhFWiJhnk8y862r//IZ7W2kgA82UCthM8nQDkKI
	khTLM4Tl1vOSd3MAgvQiyifbT7Qd9uiMn80G/QmcIETa++Y6QvppErHokvclVq+NgvAhxk
	rBlGvIEdfVwr1QS4uld6tbS5eBCrCjWPexVK1O1lzC/cDMnuWuGlnYZiNME1xNFvNGPkxY
	XiETKK/CjkG0jLtTIVi6jvogeFzPMrrUJmbx56vqJbas2/wGDfxXIkQnyt+1jg==
Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4l6H23Kzzlk8;
	Sat, 13 Aug 2022 15:37:27 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f50.google.com with SMTP id 67so3486723vsv.2;
        Sat, 13 Aug 2022 08:37:27 -0700 (PDT)
X-Gm-Message-State: ACgBeo1k6NuIk2RAODMPRw+5GFnZYLY43p9LuMLo45EFQr2h9wjnK5QL
	3XQ9MFUPRegw0SFW8VC0Ci2dzWTcovXVjy7oajU=
X-Google-Smtp-Source: AA6agR5pGNKAh0DMhEEbKRna3bvCk9aoVz5Oz9LcN9XKhrf1UOIWubnAzfZbdxuN4N3h5U3dXQuVku6qchOFspDP4Tk=
X-Received: by 2002:a05:6102:3642:b0:388:56ff:ab6a with SMTP id
 s2-20020a056102364200b0038856ffab6amr3454962vsu.11.1660405046568; Sat, 13 Aug
 2022 08:37:26 -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: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
 
 <20220813.024435.741655799390389695.yasu@FreeBSD.org> 
  
 <78c22181179d9c7f9fcea829002095eb@lerctr.org>
In-Reply-To: <78c22181179d9c7f9fcea829002095eb@lerctr.org>
From: Nuno Teixeira 
Date: Sat, 13 Aug 2022 16:37:15 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Larry Rosenman 
Cc: Yasuhiro Kimura , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000fbf07205e6212ca2"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660405047;
	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=PG2+3/PtYat3GJHK/LJAb7wECzANlLQU0a58R/0qz9k=;
	b=sY4Ek+MqqsedIXCYqMqH7lxweN4AuVIlcSgaBQVTDCK5kS22+iPMhtWElq5RqwXu4PZb/0
	S8R08KE1R7P5DFE/MaUr9f3YW9OoMqdj+4di7hKmt/OjBIypEIpHhUk+uj7fq+B4gxfG/l
	nURq0gxlD9n1RYkukWMGWmon65cenNw6dA//B7nLr36oOvN01n/YiEea8f1JKtUEby29+q
	enoWCjICk74kn6xFQOIqa7ynCB4tprsv0kwFjpMBp0+MHvF7fddlpn2NsPhFyQ9ExW9AKO
	ZZ+SLJ9cXWf/TyUfRlHiWzHkibC8vGsDm5p/d3mhiWA68mLwziBn9XzGrEHT6A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660405047; a=rsa-sha256; cv=none;
	b=fQEWl0vp5PJ2RCorqjz4gOsjs/oK4venFCs1iXjmB2+iMAk2vs1Akcg/YXt9HN+ggOfMiW
	PZSpBSClquoEmVqIVNVH7+wRE+DRuTh0RMN4SjrJsIjmi4ROCaVBHiG+DSCv9UViZ829qm
	PN3eELAgYmqPLuSfdAEtKOKH6bFQhcrZ+nquvhfZc3AYtUWvJJmAdUTOd3s/A2WWoRVLNj
	5ZFYBj0cF10P5bYaRj28k/bvd5wPP9l20A4WrkEmC+XPycAiTJkY9lqqlYJZuVvc4EIECW
	X4U6acTCJRI5t5+b4qPv0xYCvIlwwJE4aVr0E6TTHPPFrWJBUCF7ng93HHbrJw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000fbf07205e6212ca2
Content-Type: text/plain; charset="UTF-8"

Hi Larry,

boot off a memstick?
>
Yes, that's it.
With it we can mount efi partition and use bkp efi file by renaming it.

I forgot that efi boot is restricted to use bootx64.efi (amd64) and my
though was looking for a command to load bootx64.efi.old avoiding use of a
memstick (e.g.).
I've tested it, and from now on I will update efi boot more often along
with current tracking.

Thanks

--000000000000fbf07205e6212ca2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Larry,



boot off a memstick?
Yes, that's it.
<=
/div>
With it we can mount efi partition and use bkp efi file by renami=
ng it.

I forgot that efi boot is restricted to=
 use bootx64.efi (amd64) and my though was looking for a command to load bo=
otx64.efi.old avoiding use of a memstick (e.g.).
I've tested =
it, and from now on I will update efi boot more often along with current tr=
acking.

Thanks


--000000000000fbf07205e6212ca2--

From nobody Sat Aug 13 15:47:31 2022
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 4M4lL767y8z4Z9Jh
	for ; Sat, 13 Aug 2022 15:47:43 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4lL66NNxz3Grd
	for ; Sat, 13 Aug 2022 15:47:42 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x92d.google.com with SMTP id b4so1361255uaw.11
        for ; Sat, 13 Aug 2022 08:47:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=ci+9VUw4Nn98nstHNVZW90eobejU3FgJ+OTSGgzmaLI=;
        b=fe1mr7pGL96xc/ognBgJZdLvtr/jzhj8mdhBNuoJXryRaThvkrLxn1rhkb0I+A0fRq
         F/XnyVhBnkF1Il96msZNtp+l9tdRc06pSXRlje/FSb/m7ozXDuWdyaIoHIW3TNEgYA+R
         pi1VMHsl7ugmsbcudUf44HxGi/SLqcHNCFFhnTpnC55FpVYQX74R3QSCyv6BP08HRFLU
         O0tAx5jxCQQPXLsHWlVuQD7iDe0Qd4JNypyHgKN4Dybm3/UVkE8LAiLltBv/sDur+leX
         lccSfHP3llK2d9+BhieKDII+iEU7SGo+ZBPvuOnZnwhsJLFW0VIw8IcBUdrcPNS1oCG/
         6hWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=ci+9VUw4Nn98nstHNVZW90eobejU3FgJ+OTSGgzmaLI=;
        b=0YOsTe2PdNY7b7fuMq25n3t4kxokYgUqYmtmck1Tnqzu3y0uD2t+LstJa9l1F3nE5a
         30Y4Bv8UQOG5X2Cnkbec1FgTZ3Hy5kfVcOIYq/PJvhLBi50Hbjc/ovaF74vUPFOVu4kE
         DDajOKuwGvtz1vWiw/k+nli4mmY4R/sowdC5cuYUwbQZWFVsg40uCMi5gKtlWbZKNebw
         YK0VwOGGAnpB/wxukaV/2L8hEDdYaw7QL7XfXZQxL5eGxqd568X/QHPpiG59jhmwZn5/
         KOcxxRMw6yiOJbSIGKOE2HbUHnpAPmZBvTetFOi0RxnkXIV5Gc3NWsG5bumaofshzD3N
         kQOA==
X-Gm-Message-State: ACgBeo1/YrlVKbsbQ5VfVknTZ3WgUJG3rgAC7ne7+lct645t4xXnsGE9
	X1TiTVqniGuk573M3K5Ga0fHGUVV4vtRs29i3eaGOA==
X-Google-Smtp-Source: AA6agR7VHDQ3XbB1xDLCBd2ln/4hewUsO5kSD282YvPArwFg1ve2iHOHs9M5fseLfNFR8Fhwzbvg1ITIBlObVefU+Oc=
X-Received: by 2002:ab0:3bc6:0:b0:381:c4db:ef5 with SMTP id
 q6-20020ab03bc6000000b00381c4db0ef5mr3890464uaw.81.1660405662190; Sat, 13 Aug
 2022 08:47:42 -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: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
 
 <20220813.024435.741655799390389695.yasu@FreeBSD.org> 
  
 <78c22181179d9c7f9fcea829002095eb@lerctr.org> 
In-Reply-To: 
From: Warner Losh 
Date: Sat, 13 Aug 2022 09:47:31 -0600
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Nuno Teixeira 
Cc: Larry Rosenman , Yasuhiro Kimura , 
	FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000ada38a05e621512c"
X-Rspamd-Queue-Id: 4M4lL66NNxz3Grd
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=fe1mr7pG;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92d) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92d:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000ada38a05e621512c
Content-Type: text/plain; charset="UTF-8"

On Sat, Aug 13, 2022 at 9:37 AM Nuno Teixeira  wrote:

> Hi Larry,
>
> boot off a memstick?
>>
> Yes, that's it.
> With it we can mount efi partition and use bkp efi file by renaming it.
>

Yup.


> I forgot that efi boot is restricted to use bootx64.efi (amd64) and my
> though was looking for a command to load bootx64.efi.old avoiding use of a
> memstick (e.g.).
>
I've tested it, and from now on I will update efi boot more often along
> with current tracking.
>

Kinda. You can create a new UEFI (not ZFS) boot environment that uses
something else. In addition, if you are fortunate enough to have EFI SHELL
in your BIOS and/or in your ESP, you can run any XXX.efi program in the
ESP, or any DOS partition...

I have a known good loader.efi that I use a special BootXXXX variable so
that if I AFU my loader.efi in testing, it's easier to get back online,
though I also have shell.efi that I downloaded from the edk2 folks that
also helps me fix things... But I know I'm a bit of a special case....

Warmer

--000000000000ada38a05e621512c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Aug 13, 2022 at 9:37 AM Nuno =
Teixeira <eduardo@freebsd.org=
> wrote:
Hi Larry,

=



boot off a memstick?
Yes, that's it.
<=
/div>
With it we can mount efi partition and use bkp efi file by renami=
ng it.

Yup.
=C2=
=A0
I forgot that efi boot is restricted to us=
e bootx64.efi (amd64) and my though was looking for a command to load bootx=
64.efi.old avoiding use of a memstick (e.g.).
I've tested it, and from now on I will update =
efi boot more often along with current tracking.

Kinda. You can create a new UEFI (not ZFS) boot=
 environment that uses something else. In addition, if you are fortunate en=
ough to have EFI SHELL in your BIOS and/or in your ESP, you can run any XXX=
.efi program in the ESP, or any DOS partition...

I=
 have a known good loader.efi that I use a special BootXXXX variable so tha=
t if I AFU my loader.efi in testing, it's easier to get back online, th=
ough I also have shell.efi that I downloaded from the edk2 folks that also =
helps me fix things... But I know I'm a bit of a special case....
=

=C2=A0
Warmer


--000000000000ada38a05e621512c--

From nobody Sat Aug 13 17:50:24 2022
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 4M4p3q6kKgz4XxpD;
	Sat, 13 Aug 2022 17:50:31 +0000 (UTC)
	(envelope-from rb@gid.co.uk)
Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250])
	by mx1.freebsd.org (Postfix) with ESMTP id 4M4p3p5wq3z3b7P;
	Sat, 13 Aug 2022 17:50:30 +0000 (UTC)
	(envelope-from rb@gid.co.uk)
Received: from smtpclient.apple (moriarty.gid.co.uk [194.32.164.17])
	by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 27DHoO7a028661;
	Sat, 13 Aug 2022 18:50:24 +0100 (BST)
	(envelope-from rb@gid.co.uk)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: [iwlwifi] ipv6 connection problem
From: Bob Bishop 
In-Reply-To: 
Date: Sat, 13 Aug 2022 18:50:24 +0100
Cc: FreeBSD CURRENT ,
        "freebsd-wireless@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <36354E43-2904-42F8-935B-FF1B83B34A60@gid.co.uk>
References: 
 
 
 <4f79dfa8-b8bd-3222-d4de-18714c1f9b6a@plan-b.pwste.edu.pl>
 
To: Nuno Teixeira 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4M4p3p5wq3z3b7P
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk
X-Spamd-Result: default: False [-2.70 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+mx];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-wireless@FreeBSD.org,freebsd-current@FreeBSD.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[gid.co.uk];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> On 12 Aug 2022, at 13:00, Nuno Teixeira  wrote:
>=20
> Hi Merek,
>=20
>> If you are connecting to IPv6 only WLAN than you can probably either=20=

>> disable DHCP (if the RDNSS is provided for this network):
>> ifconfig_wlan0=3D"WPA up"
>> or install dhcp client capable of acquiring DHCPv6 lease and use it=20=

>> instead of standard dhclient(8) from the base which doesn't support =
DHCPv6.
>>=20
> I've tried ifconfig_wlan0=3D"WPA up" and it crashes os.
>=20
> You saying that base dhcp doesn't support ipv6 but it works fine with =
ehternet:
> ---
> ifconfig_re0=3D"DHCP"
> ifconfig_re0_ipv6=3D"inet6 accept_rtadv"
> rtsold_enable=3D"YES"
> ---

Above is kind of mixed up. I think the `ifconfig_re0=3D=E2=80=9CDHCP=E2=80=
=9D=E2=80=99 is superfluous, your interface will be getting assigned its =
address by the router using stateless autoconfiguration not DHCP.

Perhaps trying to configure both stateless autoconfiguration and DHCP is =
upsetting your wireless interface.

DHCP is almost never required with IPv6.

>=20
> Any clues?
>=20
> Thanks

--
Bob Bishop
rb@gid.co.uk





From nobody Sat Aug 13 19:54:14 2022
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 4M4rpq1wHGz4Yrgk;
	Sat, 13 Aug 2022 19:54:27 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4rpq1Rd8z3wPj;
	Sat, 13 Aug 2022 19:54:27 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660420467;
	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=h/iopukbHnEm0yhdh677qmgpyOZbd7O5AMMXZJnnxB8=;
	b=sUWPxXzD681/6i3nOXvF3Mu+ljMO5biKdIpef1vl3bXGWH8Y52VhASzcfU0YkCvM7ptpit
	itPm3Fv5SEdSCu4VLvN4ycbIjxlKBt3KurtCcuIwA9uTx1yNZ4fskEMdF4BCPF/SgEAgmX
	fiGMO/UIPfXMAgLVJ/Cam6In7Yf/f4epVBl2ZTImJX7eRxmPG4fYu3Rx9TKjzI6fQCoSCx
	qU/P3Eqm5p83ZWVqQmKZR8GmfAvj8ZJ+KtGXnWCg6cU7kSAhWRN1gcGjlFSPMVetZmz1EP
	WlxEmzx4BYM4k3EL3zKNJJZxgCr9wiM+D//wIuz/DHl0tra0knpkgC3TZUX+ng==
Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4rpq0MXBzr3T;
	Sat, 13 Aug 2022 19:54:27 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f50.google.com with SMTP id s129so3834128vsb.11;
        Sat, 13 Aug 2022 12:54:27 -0700 (PDT)
X-Gm-Message-State: ACgBeo03zg8lKnEi7eS0pvhB3GSWkSPLs1nlnVRWzBH+vndxNVdPeATt
	IfsWMSFjHft4EcsORF0UiXQtH8MdMKZeD1pq1/w=
X-Google-Smtp-Source: AA6agR5xxGFISNDicivB5yJkN9/2sWigZDOm0EtBLySN7sBZOFYWHSFnkxdHNv1Q6y76w1FqUx3BFmnvnYTN+O//mP0=
X-Received: by 2002:a05:6102:2836:b0:386:91a5:a241 with SMTP id
 ba22-20020a056102283600b0038691a5a241mr3742402vsb.51.1660420466660; Sat, 13
 Aug 2022 12:54:26 -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: 
  
 <4f79dfa8-b8bd-3222-d4de-18714c1f9b6a@plan-b.pwste.edu.pl>
  <36354E43-2904-42F8-935B-FF1B83B34A60@gid.co.uk>
In-Reply-To: <36354E43-2904-42F8-935B-FF1B83B34A60@gid.co.uk>
From: Nuno Teixeira 
Date: Sat, 13 Aug 2022 20:54:14 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: [iwlwifi] ipv6 connection problem
To: Bob Bishop 
Cc: FreeBSD CURRENT , 
	"freebsd-wireless@freebsd.org" 
Content-Type: multipart/alternative; boundary="00000000000017dc4105e624c4e4"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660420467;
	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=h/iopukbHnEm0yhdh677qmgpyOZbd7O5AMMXZJnnxB8=;
	b=hIeKq5aTqVSEvf+4254bafn8tiRGlGB5i29TrhZ3XUvCesGh/hG+69/UowY0PR5mwx4t/E
	j1NN9xfoNVh78TnwYGMGb+rB9JtyAeaGd6mU8Zzx0YYZc2AeJmq+CrVi7GjVHqyVw7lANx
	ByvJT0HXMoQeexVx2qPx7Higa8Tnm7NcBNhMwSH9CBp+WpM721rxJXoJ2178qiXc+6haxJ
	nDGf+MGGgGf+3F18bfspGV/wMyYZrZJ1SiaqZYbSZCqd5n87Df+lWeW1F5gify+oOSuDzY
	VjhQv7fdr6uVDyY6Tffrj5guJTO9SA8e5+05dsm4/dG48aVHR8e/90WL6qGitQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660420467; a=rsa-sha256; cv=none;
	b=q2mcSMX5e41P7vbuqVyZyiUsWJWKXFeNirbDqHbplze/UIx0V4gJEH+FSdqq7WFZHgM5B7
	2jvC1aWBq440dtKFQHATtmvPys9xz01g+fBJkMZLG4Okw3ofFznsYmrFZ3uwUrx4cV/lbx
	7wvu0jXhYnibiKIh8gXLMA2+f7ODyJ/Xsg4QwC36fwbUC9ufFVVXmQ60vq9msISgHK/Z1b
	V0g03ARTmtC2W5uFQZQQEnA1OhKO+8zcVUZ9c6rr4+ZF202fqovUQW4TCuaHa8jgAeA3x6
	oTopIJztZqwNmJEAWXGgtxCa6XcQ2w2eAfFCcqsEK+m4/KdaSagtNm/UZYyIcg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--00000000000017dc4105e624c4e4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Without "ifconfig_re0=3D=E2=80=9CDHCP" re0 assumes only an ipv6 address and=
 looses
internal 192.168.1.xxx ipv4 address.
No connection to internet.

I've used ifconfig_wlan0=3D"WPA" instead of ifconfig_wlan0=3D"WPA SYNCDHCP"=
 and
no carrier.

Bob Bishop  escreveu no dia s=C3=A1bado, 13/08/2022 =C3=A0(s)=
 18:50:

> Hi,
>
> > On 12 Aug 2022, at 13:00, Nuno Teixeira  wrote:
> >
> > Hi Merek,
> >
> >> If you are connecting to IPv6 only WLAN than you can probably either
> >> disable DHCP (if the RDNSS is provided for this network):
> >> ifconfig_wlan0=3D"WPA up"
> >> or install dhcp client capable of acquiring DHCPv6 lease and use it
> >> instead of standard dhclient(8) from the base which doesn't support
> DHCPv6.
> >>
> > I've tried ifconfig_wlan0=3D"WPA up" and it crashes os.
> >
> > You saying that base dhcp doesn't support ipv6 but it works fine with
> ehternet:
> > ---
> > ifconfig_re0=3D"DHCP"
> > ifconfig_re0_ipv6=3D"inet6 accept_rtadv"
> > rtsold_enable=3D"YES"
> > ---
>
> Above is kind of mixed up. I think the `ifconfig_re0=3D=E2=80=9CDHCP=E2=
=80=9D=E2=80=99 is
> superfluous, your interface will be getting assigned its address by the
> router using stateless autoconfiguration not DHCP.
>
> Perhaps trying to configure both stateless autoconfiguration and DHCP is
> upsetting your wireless interface.
>
> DHCP is almost never required with IPv6.
>
> >
> > Any clues?
> >
> > Thanks
>
> --
> Bob Bishop
> rb@gid.co.uk
>
>
>
>
>

--=20
Nuno Teixeira
FreeBSD Committer (ports)

--00000000000017dc4105e624c4e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

Without "ifconfig_r=
e0=3D=E2=80=9CDHCP" re0 assumes only an ipv6 address and looses intern=
al 192.168.1.xxx ipv4 address.
No connection to internet.

I've used ifconfig_wlan0=3D"WPA" instead of=
 ifconfig_wlan0=3D"WPA SYNCDHCP" and no carrier.
<=
br>
Bob Bis=
hop <rb@gid.co.uk> escreveu no di=
a s=C3=A1bado, 13/08/2022 =C3=A0(s) 18:50:
Hi,



> On 12 Aug 2022, at 13:00, Nuno Teixeira <eduardo@FreeBSD.org> wr=
ote:

> 

> Hi Merek,

> 

>> If you are connecting to IPv6 only WLAN than you can probably eith=
er 

>> disable DHCP (if the RDNSS is provided for this network):

>> ifconfig_wlan0=3D"WPA up"

>> or install dhcp client capable of acquiring DHCPv6 lease and use i=
t 

>> instead of standard dhclient(8) from the base which doesn't su=
pport DHCPv6.

>> 

> I've tried ifconfig_wlan0=3D"WPA up" and it crashes os.<=
br>
> 

> You saying that base dhcp doesn't support ipv6 but it works fine w=
ith ehternet:

> ---

> ifconfig_re0=3D"DHCP"

> ifconfig_re0_ipv6=3D"inet6 accept_rtadv"

> rtsold_enable=3D"YES"

> ---



Above is kind of mixed up. I think the `ifconfig_re0=3D=E2=80=9CDHCP=E2=80=
=9D=E2=80=99 is superfluous, your interface will be getting assigned its ad=
dress by the router using stateless autoconfiguration not DHCP.



Perhaps trying to configure both stateless autoconfiguration and DHCP is up=
setting your wireless interface.



DHCP is almost never required with IPv6.



> 

> Any clues?

> 

> Thanks



--

Bob Bishop

rb@gid.co.uk












-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--00000000000017dc4105e624c4e4--

From nobody Sat Aug 13 20:20:27 2022
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 4M4sQV1DzGz4Z0K9
	for ; Sat, 13 Aug 2022 20:21:54 +0000 (UTC)
	(envelope-from shawn.webb@hardenedbsd.org)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4sQT11Sxz41LM
	for ; Sat, 13 Aug 2022 20:21:52 +0000 (UTC)
	(envelope-from shawn.webb@hardenedbsd.org)
Received: by mail-qk1-x736.google.com with SMTP id c28so3107252qko.9
        for ; Sat, 13 Aug 2022 13:21:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=hardenedbsd.org; s=google;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc;
        bh=oWrR/nRPYGjpuFoz4lzv7T4EbhDEOwWXZZkx0BjjOos=;
        b=OjXT4wBJc3b3/Zf6Qi75RKkbLqfJWZ3uS911GcZYkV7ERgltIJoIP7DWCDnf4enDyC
         ne/6h2Wx1vpbRvMQ43yIy5rbaGAkfraKRYCJRFX8DtXLDZxOs9MoMv99nWRcho5JPa2T
         RgnYfHj3VQ88Cg4SP/FF7cCeoCnjOYi16zDNNIsApizHPB1mYmaJsu+w95lpVIkR/pWK
         qV+PG711+f8dwq2m3GJaGqZThdGgIIJzTS979yRto75zDfQthX0deX2HSwBvABl/IDYg
         5pxDiZ9RbiLe3GAQsy52yzERu9uZgkvY+1MmIDXoCxMeHiZjWjUWvOO6oYlFQlDdvFkH
         oxng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc;
        bh=oWrR/nRPYGjpuFoz4lzv7T4EbhDEOwWXZZkx0BjjOos=;
        b=sAkOsH5oUngIlLmpFOuRZUUbm+dqvG74YL3xkf2tzYfQQuMaY01cqu5qF+jziYU3lf
         2oJkU94dqA0ZSMRYrW5S7qFvYUp4ozDnOzRkhUfO13wuydSrvYu1FKf/FkptjjGvl9L1
         g5CJnrzNpk8FgsD07xK1fiz9K1maTjGoE+R4hbYF5mRfil3YPhnKK3bLifWxnILMVnYD
         DQ+S950IfPgFd79mSxHCVN+f9YJHr5mbfU1MqymlvvjSWMM8VsxpdTSPZCJD3RuKbWDh
         cm4oUTKWdcM4Od/OSabRmO0X6EEBnOdWJysvZYGcych1THocIj+2/l9LH0cG0w+ZGezn
         uHuA==
X-Gm-Message-State: ACgBeo1rpiGvqCbUtE14e4XM6ljsxkXetT6BjukACXd1/gjAuuqdPQwL
	MrdubMRGBC9/1eYguxrt8b0bUangJAqwVUWf
X-Google-Smtp-Source: AA6agR4Jw27Gyt67sFcHPf2EfN+nxTcV3pX8RcPVo90ZEWwfGM0daVMEqO5nESUZMl1wad++wju/dQ==
X-Received: by 2002:a05:620a:2988:b0:6b5:e5a6:864f with SMTP id r8-20020a05620a298800b006b5e5a6864fmr6893693qkp.476.1660422112069;
        Sat, 13 Aug 2022 13:21:52 -0700 (PDT)
Received: from mutt-hbsd (pool-100-16-219-215.bltmmd.fios.verizon.net. [100.16.219.215])
        by smtp.gmail.com with ESMTPSA id r2-20020a05620a298200b006b555509398sm4515042qkp.136.2022.08.13.13.21.51
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 13 Aug 2022 13:21:51 -0700 (PDT)
Date: Sat, 13 Aug 2022 16:20:27 -0400
From: Shawn Webb 
To: Nuno Teixeira 
Cc: freebsd-wireless@freebsd.org,
	FreeBSD CURRENT 
Subject: Re: [iwlwifi] ipv6 connection problem
Message-ID: <20220813202027.2mhq7cyuqpntk6h5@mutt-hbsd>
X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD
 14.0-CURRENT-HBSD 
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="frdhh74yj5ix73y2"
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4M4sQT11Sxz41LM
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hardenedbsd.org header.s=google header.b=OjXT4wBJ;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::736 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org
X-Spamd-Result: default: False [-5.10 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	MID_RHS_NOT_FQDN(0.50)[];
	R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from];
	RCPT_COUNT_THREE(0.00)[3];
	DKIM_TRACE(0.00)[hardenedbsd.org:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[hardenedbsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--frdhh74yj5ix73y2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 07, 2022 at 06:16:20PM +0100, Nuno Teixeira wrote:
> Hello,
>=20
> Due to ISP changes I was forced to use ipv6 on my re0 ethernet so I can
> have a funcional internet.
>=20
> Now I'm trying to get ipv6 on iwlwifi (AX201) with /etc/rc.conf:
> ---
> wlans_iwlwifi0=3D"wlan0"
> create_args_wlan0=3D"wlanmode sta regdomain ETSI country PT"
> ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"
> ifconfig_wlan0=3D"WPA SYNCDHCP"
> rtsold_enable=3D"YES"
> ---
> but wpa_supplicant doesn't connect after trying for some seconds.
>=20
> How do I obtain more details to help showing my problem?
> I've tried "wpa_supplicant_flags=3D"-f /var/log/wpa.log" without success.

Caveat: the last time I used the iwlwifi driver was somewhere between
one and two months ago, during which time there have been several
changes in src related to wifi/linuxkpi stuff.

Hardware: Dell Precision 7550, BIOS revision 1.13.0

Dual stack IPv4+IPv6 worked for me that last time I used iwlwifi.
Here's my relevant configs:

=3D=3D=3D=3D begin rc.conf =3D=3D=3D=3D
ifconfig_em0_ipv6=3D"inet6 accept_rtadv"
ifconfig_em0=3D"DHCP"

#wlans_iwlwifi0=3D"wlan0"
create_args_wlan0=3D"wlanmode sta"
wlandebug_wlan0=3D"+state +crypto +node +auth +assoc +dot1xsm +wpa"
ifconfig_wlan0=3D"WPA DHCP"
ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"
=3D=3D=3D=3D end rc.conf =3D=3D=3D=3D

=3D=3D=3D=3D begin `pciconf -lv` =3D=3D=3D=3D
iwlwifi0@pci0:0:20:3:   class=3D0x028000 rev=3D0x00 hdr=3D0x00 vendor=3D0x8=
086 device=3D0x06f0 subvendor=3D0x8086 subdevice=3D0x4070
    vendor     =3D 'Intel Corporation'
    device     =3D 'Comet Lake PCH CNVi WiFi'
=3D=3D=3D=3D end `pciconf -lv` =3D=3D=3D=3D

=3D=3D=3D=3D begin dmesg.boot =3D=3D=3D=3D
27] iwlwifi0: successfully loaded firmware image 'iwlwifi-QuZ-a0-hr-b0-71.u=
code'
[27] iwlwifi0: api flags index 2 larger than supported by driver
[27] iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37
[27] iwlwifi0: loaded firmware version 71.058653f6.0 QuZ-a0-hr-b0-71.ucode =
op_mode iwlmvm
[27] iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x351
[28] iwlwifi0: Detected RF HR B3, rfid=3D0x10a100
[28] iwlwifi0: base HW address: [redacted]
=3D=3D=3D=3D end dmesg.boot =3D=3D=3D=3D

Hopefully this helps. But this is all the info I've got. Please let me
know if you have any questions or comments.

Thanks,

--=20
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A=
4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

--frdhh74yj5ix73y2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmL4B4IACgkQ/y5nonf4
4fqEIBAAkcH5ZqJLWrlzIuVuvvC/oiNr3V1pmq3FygVxw3VDmXrh/PZQIQjhqFni
2uElRWVF/3c5L9Xk/K3Vx9c3CMQioeFTpNM1KpNC8Rtli3KmM/yCp1bj/vXh6iQ2
UxjFt8EIKdpeTkmz/Oaxu/Arq/eie2A9e0zDcYhSZe+PiID/Z3GVsHeqa+109qsy
Q9cdmpcEc6kCeIT+PvLsXCDVGI/tvEOVhCUERnQydjnP/HF813Ln0V+Frm+X1gTt
mtxoSN/nOb+3y/UG8OP8m0y2s3ddyW1HbLpXKZoKHYcA9ejb24qZlRPitDXI8I3/
6EYfSJde/8W2bFhd+QYXEdkbZdMxNsgxLjda+trl/TVOLGepCXazcylk6F4TpD3c
t/9qp7WVyEbOCr6HFTLQbgo/H8Z98bpL82eZpNP7yV+JPvea9ie/48gd7Uu3dlbG
CNRSSBIi0j1b/N8hT4n57bvkxqO5H+MDGl7hWiSmMPjqLYQi94NgoBYzhENE7xsT
ldcIcn2n4tps5XBbnruFXBXOZcyNEZ/LReD7Q3MnzDuSXkl1Dgba7GUko0YfUpqv
QC9SWMDDoD4XrdWJVg3Nekq56NevWQmTtMHqCitQr/hfPPL39VmkMSNDEkLlYjFU
7oUjJP9xaDo6nkSJZ0R/yreLCBixk+2Hz1LXqNQEId+2Z+mpdW8=
=nWpZ
-----END PGP SIGNATURE-----

--frdhh74yj5ix73y2--

From nobody Sat Aug 13 20:49:34 2022
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 4M4t2g1ffqz4Z7Zw;
	Sat, 13 Aug 2022 20:49:47 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4t2g1Cd1z46v7;
	Sat, 13 Aug 2022 20:49:47 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660423787;
	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=UYAigjqGBtOkle41NHDyaTxXc0aWOLu+MW8ZLFJaRI0=;
	b=GFdRxkKI7suLnoi0fg4eYBCDJ4cMQtGYUYyWDLNNqszD5CzLVooYBNuoZJhFqhjkMl75mF
	iCI/Bhx91eXMjlAXY1AZbCF2gi3+vtrW2EwaHbGOV/iuW3FzO2N0KYk/j9heweXjSPqMiX
	p4dZaBN9DBGo01dcMh1XkOOzdTIaxr76m5p5vAqh5PWOqJ7SfGiZExIZQtsY7slIcAN7TS
	Alw7lYLT91dDl5agYz/MLLMU/MRa5qTUyAHlEwcvkLLP1WyaWrR3rBjCl9b6j+DnyYz9Mj
	O5b18oTfNslMZ9LzZ7q5dyRIPneLU3JiQ93yoND1Gnqs6Stf6ZTcV/DGGtiydw==
Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4t2g09LBzrdy;
	Sat, 13 Aug 2022 20:49:47 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-ua1-f43.google.com with SMTP id b22so531256uap.0;
        Sat, 13 Aug 2022 13:49:47 -0700 (PDT)
X-Gm-Message-State: ACgBeo1H4hK2eB03C399DL2Mj8RHp1p0gemcmNh0FFVDoZ1bB3CVF8Y3
	dENMqrhOWrEO07dPBx9nXkhHAc0IhgTmbj8WR2s=
X-Google-Smtp-Source: AA6agR40ZC4gjMJ3iqkb9yNWYKqllQW1hYWiueDOCHSDNJZ9eHEUb9ZvnBDAjpwVAoIDl9TZ4wtxCRftOuQcdi+P4g0=
X-Received: by 2002:ab0:785a:0:b0:386:d33c:d636 with SMTP id
 y26-20020ab0785a000000b00386d33cd636mr4092675uaq.87.1660423786476; Sat, 13
 Aug 2022 13:49:46 -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: 
 <20220813202027.2mhq7cyuqpntk6h5@mutt-hbsd>
In-Reply-To: <20220813202027.2mhq7cyuqpntk6h5@mutt-hbsd>
From: Nuno Teixeira 
Date: Sat, 13 Aug 2022 21:49:34 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: [iwlwifi] ipv6 connection problem
To: Shawn Webb 
Cc: freebsd-wireless@freebsd.org, 
	FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000f83bf405e62589c3"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660423787;
	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=UYAigjqGBtOkle41NHDyaTxXc0aWOLu+MW8ZLFJaRI0=;
	b=Ut1rNAWJTpTRq85mzoZVht78u3YLYdQarAtu3LPUea+YJh+n58RksHnHG7n23/2E+5YpFe
	8lFjNCXRIa1aaB2UhqUIy9T5si4UxnaSAc5AuOtwsNXRuqyHFf5EfCieeCoLqemrReuy9b
	ohijR5fWq0KY38VNqr25ujHOp6GLXZi479d9cgJOM49aipn0Py1IKNXK5OgvNi05efn+cW
	Px8vlCf00T/h+GPYLbzZcvU6dyZ/M4z1Ru5oabqPKIHnEnAs0JrIYf3HVdD066vLny01mh
	7x4IOovxtz+pHUI19zbipmd5s0oDZ3TcAKyaXsJ+YSrqVG3QUFF1RGVzidOJ3Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660423787; a=rsa-sha256; cv=none;
	b=gXUXkSbwJgFVLfIWs5WVHXy+jecUpM567F5jZSts6P45400CQdR8mXQ5SJcfiakG5c/6o1
	Gk+i5T2lA+Cr7/0nypIcTr64sFkG23ZzJFoQ1bt6Z59Al5y66AZ0hdxLtWcLvyCnBu1qUu
	7kRMcGmD4yuHVVoIsFxBf1cDHwEksWb9+AMbBLVCIpYWp3hW6w6nhCY3E9ZWZ0f9tIrt6V
	J53BXBhJd6g4RrGS1SHDI4AOKHUcbArojY0b9jti1X/Q1EbP4aOhyKb1ufA+PI88UR8F7k
	cPDR9apdUC/3QvSkQEYY9QTmdRAdHvWPna5/Xg3sHEzT3qf/cn5XL73FeEgSgw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000f83bf405e62589c3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Shawn!

I've tested your config:
---
wlans_iwlwifi0=3D"wlan0"
create_args_wlan0=3D"wlanmode sta regdomain ETSI country PT"
ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"
ifconfig_wlan0=3D"WPA DHCP"
rtsold_enable=3D"YES"
---
and no carrier.

Think we have to wait a little more and see if people that use ifwwifi
driver do some tests on ipv6.

Thanks,

Shawn Webb  escreveu no dia s=C3=A1bado, 13/08/=
2022
=C3=A0(s) 21:21:

> On Sun, Aug 07, 2022 at 06:16:20PM +0100, Nuno Teixeira wrote:
> > Hello,
> >
> > Due to ISP changes I was forced to use ipv6 on my re0 ethernet so I can
> > have a funcional internet.
> >
> > Now I'm trying to get ipv6 on iwlwifi (AX201) with /etc/rc.conf:
> > ---
> > wlans_iwlwifi0=3D"wlan0"
> > create_args_wlan0=3D"wlanmode sta regdomain ETSI country PT"
> > ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"
> > ifconfig_wlan0=3D"WPA SYNCDHCP"
> > rtsold_enable=3D"YES"
> > ---
> > but wpa_supplicant doesn't connect after trying for some seconds.
> >
> > How do I obtain more details to help showing my problem?
> > I've tried "wpa_supplicant_flags=3D"-f /var/log/wpa.log" without succes=
s.
>
> Caveat: the last time I used the iwlwifi driver was somewhere between
> one and two months ago, during which time there have been several
> changes in src related to wifi/linuxkpi stuff.
>
> Hardware: Dell Precision 7550, BIOS revision 1.13.0
>
> Dual stack IPv4+IPv6 worked for me that last time I used iwlwifi.
> Here's my relevant configs:
>
> =3D=3D=3D=3D begin rc.conf =3D=3D=3D=3D
> ifconfig_em0_ipv6=3D"inet6 accept_rtadv"
> ifconfig_em0=3D"DHCP"
>
> #wlans_iwlwifi0=3D"wlan0"
> create_args_wlan0=3D"wlanmode sta"
> wlandebug_wlan0=3D"+state +crypto +node +auth +assoc +dot1xsm +wpa"
> ifconfig_wlan0=3D"WPA DHCP"
> ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"
> =3D=3D=3D=3D end rc.conf =3D=3D=3D=3D
>
> =3D=3D=3D=3D begin `pciconf -lv` =3D=3D=3D=3D
> iwlwifi0@pci0:0:20:3:   class=3D0x028000 rev=3D0x00 hdr=3D0x00 vendor=3D0=
x8086
> device=3D0x06f0 subvendor=3D0x8086 subdevice=3D0x4070
>     vendor     =3D 'Intel Corporation'
>     device     =3D 'Comet Lake PCH CNVi WiFi'
> =3D=3D=3D=3D end `pciconf -lv` =3D=3D=3D=3D
>
> =3D=3D=3D=3D begin dmesg.boot =3D=3D=3D=3D
> 27] iwlwifi0: successfully loaded firmware image
> 'iwlwifi-QuZ-a0-hr-b0-71.ucode'
> [27] iwlwifi0: api flags index 2 larger than supported by driver
> [27] iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37
> [27] iwlwifi0: loaded firmware version 71.058653f6.0 QuZ-a0-hr-b0-71.ucod=
e
> op_mode iwlmvm
> [27] iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x351
> [28] iwlwifi0: Detected RF HR B3, rfid=3D0x10a100
> [28] iwlwifi0: base HW address: [redacted]
> =3D=3D=3D=3D end dmesg.boot =3D=3D=3D=3D
>
> Hopefully this helps. But this is all the info I've got. Please let me
> know if you have any questions or comments.
>
> Thanks,
>
> --
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
>
>
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0=
3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000f83bf405e62589c3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Shawn!

I've tested=
 your config:
---
wlans_iwlwifi0=3D"wlan0"create_args_wlan0=3D"wlanmode sta regdomain ETSI country PT"
=
ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"
ifconfig_wlan0=3D&q=
uot;WPA DHCP"
rtsold_enable=3D"YES"
---
and no carrier.

Think we have to wait a little =
more and see if people that use ifwwifi driver do some tests on ipv6.
=


Thanks,

<=
div dir=3D"ltr" class=3D"gmail_attr">Shawn Webb <shawn.webb@hardenedbsd.org> escreveu no dia s=
=C3=A1bado, 13/08/2022 =C3=A0(s) 21:21:
On Sun, Aug 07, 2022 at 06:16:20PM +0100, Nuno Teix=
eira wrote:

> Hello,

> 

> Due to ISP changes I was forced to use ipv6 on my re0 ethernet so I ca=
n

> have a funcional internet.

> 

> Now I'm trying to get ipv6 on iwlwifi (AX201) with /etc/rc.conf:
> ---

> wlans_iwlwifi0=3D"wlan0"

> create_args_wlan0=3D"wlanmode sta regdomain ETSI country PT"=


> ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"

> ifconfig_wlan0=3D"WPA SYNCDHCP"

> rtsold_enable=3D"YES"

> ---

> but wpa_supplicant doesn't connect after trying for some seconds.<=
br>
> 

> How do I obtain more details to help showing my problem?

> I've tried "wpa_supplicant_flags=3D"-f /var/log/wpa.log&=
quot; without success.



Caveat: the last time I used the iwlwifi driver was somewhere between

one and two months ago, during which time there have been several

changes in src related to wifi/linuxkpi stuff.



Hardware: Dell Precision 7550, BIOS revision 1.13.0



Dual stack IPv4+IPv6 worked for me that last time I used iwlwifi.

Here's my relevant configs:



=3D=3D=3D=3D begin rc.conf =3D=3D=3D=3D

ifconfig_em0_ipv6=3D"inet6 accept_rtadv"

ifconfig_em0=3D"DHCP"



#wlans_iwlwifi0=3D"wlan0"

create_args_wlan0=3D"wlanmode sta"

wlandebug_wlan0=3D"+state +crypto +node +auth +assoc +dot1xsm +wpa&quo=
t;

ifconfig_wlan0=3D"WPA DHCP"

ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"

=3D=3D=3D=3D end rc.conf =3D=3D=3D=3D



=3D=3D=3D=3D begin `pciconf -lv` =3D=3D=3D=3D

iwlwifi0@pci0:0:20:3:=C2=A0 =C2=A0class=3D0x028000 rev=3D0x00 hdr=3D0x00 ve=
ndor=3D0x8086 device=3D0x06f0 subvendor=3D0x8086 subdevice=3D0x4070

=C2=A0 =C2=A0 vendor=C2=A0 =C2=A0 =C2=A0=3D 'Intel Corporation'

=C2=A0 =C2=A0 device=C2=A0 =C2=A0 =C2=A0=3D 'Comet Lake PCH CNVi WiFi&#=
39;

=3D=3D=3D=3D end `pciconf -lv` =3D=3D=3D=3D



=3D=3D=3D=3D begin dmesg.boot =3D=3D=3D=3D

27] iwlwifi0: successfully loaded firmware image 'iwlwifi-QuZ-a0-hr-b0-=
71.ucode'

[27] iwlwifi0: api flags index 2 larger than supported by driver

[27] iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37

[27] iwlwifi0: loaded firmware version 71.058653f6.0 QuZ-a0-hr-b0-71.ucode =
op_mode iwlmvm

[27] iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x351

[28] iwlwifi0: Detected RF HR B3, rfid=3D0x10a100

[28] iwlwifi0: base HW address: [redacted]

=3D=3D=3D=3D end dmesg.boot =3D=3D=3D=3D



Hopefully this helps. But this is all the info I've got. Please let me<=
br>
know if you have any questions or comments.



Thanks,



-- 

Shawn Webb

Cofounder / Security Engineer

HardenedBSD



https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/m=
aster/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc




-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--000000000000f83bf405e62589c3--

From nobody Sat Aug 13 20:54:06 2022
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 4M4t9H4DVVz4Z8nD
	for ; Sat, 13 Aug 2022 20:55:31 +0000 (UTC)
	(envelope-from shawn.webb@hardenedbsd.org)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4t9G73BMz49bw
	for ; Sat, 13 Aug 2022 20:55:30 +0000 (UTC)
	(envelope-from shawn.webb@hardenedbsd.org)
Received: by mail-qt1-x833.google.com with SMTP id s11so3120413qtx.6
        for ; Sat, 13 Aug 2022 13:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=hardenedbsd.org; s=google;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc;
        bh=RUtM/Se7+BEvrHY3HMso/2I54ow2rVpfU7YpimB/CU8=;
        b=AJTKxhcqKMMFez33dX6UULDST+5oyoDOCY8MjXBUgqRQZ/4hV5qQZxbbJw6Lu4T8Bo
         5VZ292GK6uA8OAGTKCp3vUrrSS2G5RfHj8fpk7834v3ZiF+M1eafiX/ZTLwlAVOKAg7/
         OA20uMKwsmxjMcIgbMeEUtOQhp2mVoqT5V3Dai3bXVFuINAyUoidsbmU9G5Ypmz0WTRG
         084yIB48d6AhbT21KS7jHPRWOHiRKpfAks1TakYEVHUMHJVPm2HWz6/t5FZEy3b144Jd
         ppK3tmUAIOIeKVP3njS5kVdSpTlau+NgugCAOlLHg4QRNBeDiawN3rCvOBysozF1QTWY
         CJMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc;
        bh=RUtM/Se7+BEvrHY3HMso/2I54ow2rVpfU7YpimB/CU8=;
        b=z/7Np797WsggV0Y9fIXhvHf3jT1CAI6i3p8fSWuHTWaYSVpFRegJJ0LKwaMaoczC9j
         lEktm5p7Ql60vPa4iEs9ABJyZyiTrFfz6yxglg7f32OiTlOZO25XvD3Whsi+JFL+2/rC
         vFUh32IntnKF4PqtLMsDHkrI5DGw2IenDiCikHJgs1NSkaIjDK6IgT1QIaQrRXIGDQ0t
         XZYIpaFpakT8+1sKgSliTlrtZLsGblAObAEFrvjxZ1Z0DDQnr47zcDHIkppWxHUZ3yfA
         f0g+s37GP+e7zeU1SmjwOm+kC9CTotg1J4vSVJitcG0CyeQMOF97d7HD7p+kqHwxHUqD
         un/A==
X-Gm-Message-State: ACgBeo1+v92m43JDKBBVQsJAmlT0v41+0ZstigpeHE8eOg1Z/UPr5Nf7
	eUSu5KYYSjSVZQhZMaTVHQyWlA==
X-Google-Smtp-Source: AA6agR77PYL23KNc1M1g/srQhzM4INIbAUtdJhs4YY098eD6P/onVXCnHYbmjzat37uiLSs+0uXOIQ==
X-Received: by 2002:ac8:5c50:0:b0:344:559b:961a with SMTP id j16-20020ac85c50000000b00344559b961amr1784628qtj.665.1660424130238;
        Sat, 13 Aug 2022 13:55:30 -0700 (PDT)
Received: from mutt-hbsd (pool-100-16-219-215.bltmmd.fios.verizon.net. [100.16.219.215])
        by smtp.gmail.com with ESMTPSA id bt14-20020ac8690e000000b00342f6c31da7sm4422148qtb.94.2022.08.13.13.55.29
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 13 Aug 2022 13:55:29 -0700 (PDT)
Date: Sat, 13 Aug 2022 16:54:06 -0400
From: Shawn Webb 
To: Nuno Teixeira 
Cc: freebsd-wireless@freebsd.org,
	FreeBSD CURRENT 
Subject: Re: [iwlwifi] ipv6 connection problem
Message-ID: <20220813205406.lat5e6aryzliw3op@mutt-hbsd>
X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD
 14.0-CURRENT-HBSD 
X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
References: 
 <20220813202027.2mhq7cyuqpntk6h5@mutt-hbsd>
 
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="2vvghu3rdz6mxytt"
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4M4t9G73BMz49bw
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hardenedbsd.org header.s=google header.b=AJTKxhcq;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::833 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org
X-Spamd-Result: default: False [-5.10 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	MID_RHS_NOT_FQDN(0.50)[];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::833:from];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[hardenedbsd.org:+];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[hardenedbsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--2vvghu3rdz6mxytt
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I should have mentioned that my wireless AP isn't your typical AP.
It's running HardenedBSD 13-STABLE on a PC-Engines APU2 with an
Atheros WNIC.

Here's the relevant configs on the WAP:

=3D=3D=3D=3D begin rc.conf =3D=3D=3D=3D
ifconfig_igb0=3D"DHCP"
ifconfig_igb0_ipv6=3D"inet6 accept_rtadv"

wlans_ath0=3D"wlan0"
create_args_wlan0=3D"wlanmode hostap mode 11a up"
ifconfig_wlan0=3D"HOSTAP"

cloned_interfaces=3D"bridge0"
ifconfig_bridge0=3D"addm igb0 addm wlan0 span igb1 up"
=3D=3D=3D=3D end rc.conf =3D=3D=3D=3D

=3D=3D=3D=3D begin hostapd-wlan0.conf =3D=3D=3D=3D
interface=3Dwlan0
ctrl_interface=3D/var/run/hostapd-wlan0
ctrl_interface_group=3Dwheel
ssid=3D[redacted]
wpa=3D2
wpa_passphrase=3D[redacted]
wpa_key_mgmt=3DWPA-PSK
wpa_pairwise=3DCCMP
=3D=3D=3D=3D end hostapd-wlan0.conf =3D=3D=3D=3D

On Sat, Aug 13, 2022 at 09:49:34PM +0100, Nuno Teixeira wrote:
> Hello Shawn!
>=20
> I've tested your config:
> ---
> wlans_iwlwifi0=3D"wlan0"
> create_args_wlan0=3D"wlanmode sta regdomain ETSI country PT"
> ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"
> ifconfig_wlan0=3D"WPA DHCP"
> rtsold_enable=3D"YES"
> ---
> and no carrier.
>=20
> Think we have to wait a little more and see if people that use ifwwifi
> driver do some tests on ipv6.
>=20
> Thanks,
>=20
> Shawn Webb  escreveu no dia s=E1bado, 13/08/2=
022
> =E0(s) 21:21:
>=20
> > On Sun, Aug 07, 2022 at 06:16:20PM +0100, Nuno Teixeira wrote:
> > > Hello,
> > >
> > > Due to ISP changes I was forced to use ipv6 on my re0 ethernet so I c=
an
> > > have a funcional internet.
> > >
> > > Now I'm trying to get ipv6 on iwlwifi (AX201) with /etc/rc.conf:
> > > ---
> > > wlans_iwlwifi0=3D"wlan0"
> > > create_args_wlan0=3D"wlanmode sta regdomain ETSI country PT"
> > > ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"
> > > ifconfig_wlan0=3D"WPA SYNCDHCP"
> > > rtsold_enable=3D"YES"
> > > ---
> > > but wpa_supplicant doesn't connect after trying for some seconds.
> > >
> > > How do I obtain more details to help showing my problem?
> > > I've tried "wpa_supplicant_flags=3D"-f /var/log/wpa.log" without succ=
ess.
> >
> > Caveat: the last time I used the iwlwifi driver was somewhere between
> > one and two months ago, during which time there have been several
> > changes in src related to wifi/linuxkpi stuff.
> >
> > Hardware: Dell Precision 7550, BIOS revision 1.13.0
> >
> > Dual stack IPv4+IPv6 worked for me that last time I used iwlwifi.
> > Here's my relevant configs:
> >
> > =3D=3D=3D=3D begin rc.conf =3D=3D=3D=3D
> > ifconfig_em0_ipv6=3D"inet6 accept_rtadv"
> > ifconfig_em0=3D"DHCP"
> >
> > #wlans_iwlwifi0=3D"wlan0"
> > create_args_wlan0=3D"wlanmode sta"
> > wlandebug_wlan0=3D"+state +crypto +node +auth +assoc +dot1xsm +wpa"
> > ifconfig_wlan0=3D"WPA DHCP"
> > ifconfig_wlan0_ipv6=3D"inet6 accept_rtadv"
> > =3D=3D=3D=3D end rc.conf =3D=3D=3D=3D
> >
> > =3D=3D=3D=3D begin `pciconf -lv` =3D=3D=3D=3D
> > iwlwifi0@pci0:0:20:3:   class=3D0x028000 rev=3D0x00 hdr=3D0x00 vendor=
=3D0x8086
> > device=3D0x06f0 subvendor=3D0x8086 subdevice=3D0x4070
> >     vendor     =3D 'Intel Corporation'
> >     device     =3D 'Comet Lake PCH CNVi WiFi'
> > =3D=3D=3D=3D end `pciconf -lv` =3D=3D=3D=3D
> >
> > =3D=3D=3D=3D begin dmesg.boot =3D=3D=3D=3D
> > 27] iwlwifi0: successfully loaded firmware image
> > 'iwlwifi-QuZ-a0-hr-b0-71.ucode'
> > [27] iwlwifi0: api flags index 2 larger than supported by driver
> > [27] iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37
> > [27] iwlwifi0: loaded firmware version 71.058653f6.0 QuZ-a0-hr-b0-71.uc=
ode
> > op_mode iwlmvm
> > [27] iwlwifi0: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=3D0x351
> > [28] iwlwifi0: Detected RF HR B3, rfid=3D0x10a100
> > [28] iwlwifi0: base HW address: [redacted]
> > =3D=3D=3D=3D end dmesg.boot =3D=3D=3D=3D
> >
> > Hopefully this helps. But this is all the info I've got. Please let me
> > know if you have any questions or comments.
> >
> > Thanks,
> >
> > --
> > Shawn Webb
> > Cofounder / Security Engineer
> > HardenedBSD
> >
> >
> > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb=
/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
> >
>=20
>=20
> --=20
> Nuno Teixeira
> FreeBSD Committer (ports)

--=20
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A=
4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

--2vvghu3rdz6mxytt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmL4D2cACgkQ/y5nonf4
4foPjxAApuN4hbWxjWlYLn5PdR5qrJmNKa/cFxlk/8DmcLaiAE3l2BQMwI7zjriR
9PubY8M5GbDpZp0eKOtNo53DitGtTr3pppSl+Gp5bJAmUTJk+hspVwMx15uVgZHo
58Cm0rYXZbE/xyP1TipWjX6X9jKF6xZ1ABqbxVS7D/hPaSDYSpa7VdvR6fCfPsCO
yCmtdU08zkLpFkRfaNiL7eWo5BNgAsnJEgBHw8mWEe08KL4glPeb4DjYRYpXANeN
kmVhtFdPfzUNU3ebMzHgDEhEAzEwa5i64vi+dJhahpxKJeT0NLZhhVA/vRatOoHZ
XuU16dIGQwjknip+9QTPcaZyU5pXNHvu8ZI+zxwq9s4CQ4nwBjmOWT2aremlk9xc
YctINF1cMFkQrJo9wL4o+x91n3Q5lpLspoAM9LDwHbU720/170L+qbTIJ8kbulVq
/Um+ZCL8UBHbtNmA3BescTi88q7ds1toZ1M/8gy0hSuZ6UzsLCb4bdWTo6FSaoMT
cxXzfBfEdfu24tEKcP59Z5FPFuBqL1L2fd4pee8alL7CqY19GOvG0zDK23jq6EoO
J5jafnoiJ42uaaPhU5nnyIIDsFWg6KCESyBZ1XlrOsVyCiBOvbTeLKM3bCX2eoli
BAtTo7MEGTRn3mOjctCnORweiA9nsAIam4Gq93o7NQQlcFpz3k8=
=itkQ
-----END PGP SIGNATURE-----

--2vvghu3rdz6mxytt--

From nobody Sat Aug 13 21:34:40 2022
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 4M4v4M24B5z4YcmL
	for ; Sat, 13 Aug 2022 21:36:19 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4v4M1VBHz4KCv;
	Sat, 13 Aug 2022 21:36:19 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660426579;
	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=N3OqzXgE8ItGUElTnr/iwT8gYPEQlWiqUqqz+ObsFwM=;
	b=webQeZkrlizyLrNThfp1eqjf9g07MJUaaTUKLhoj1MWyj4lD7HMhqYzKz5Po4zXcYt6gJZ
	8zXYmN5tk0RoYky1lq/gTNKMWIQLHp/Am4dScypyGxibFjOly6aD9Vq4apEUiIzpdTMAK+
	bta1LhdC1NnqkQKSWGSAQ8HMJByEjYGPRNsfWuxRjvP9MdClfd/A9O7QEh+NHFkCPwolxS
	7d9CPxfazqMXk0tS+yjIX4HVzKKrcfHoYhkS3hcG/SDWAW8fqLuaph+KPysUL4qMEzH6/l
	f7x9Vrx0bwz7hC/hoVXF2EjqhhxuLrRK197luLpedaKL39cCRfK11GmP0YskJw==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:60c0:516d:769d:a3d2])
	(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: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4v4L3SsJzs8c;
	Sat, 13 Aug 2022 21:36:18 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST)
Message-Id: <20220814.063440.1883565953618972371.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura 
In-Reply-To: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660426579;
	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=N3OqzXgE8ItGUElTnr/iwT8gYPEQlWiqUqqz+ObsFwM=;
	b=Jgt5M4McP2ECTLAoyJbM1uCxCTyE9tNrX249aN3ULzvrpYvbHc1y2M7w7pY/IPp81d9Rdj
	3X/tE6FCf7I2uIbsnVPnK9goYu/mUbc/5ongUX/mNE+CeDhdHEUVLORrzqmuRWeCgaFFQc
	iNfSJNoaOC6O5m/q0l53Kad4nK0jEdlp14pMUJXXhhafhxqlE/avpLsYD6IVvt56xy6aVk
	Gc2CJ0iFoM6K0v5o6ZqDFt3Ogt4vG6MQiLsJmkkbdgyOIHMMJKSab2Z0Vu9YNePPuAkP4R
	/7Og+T0xkidLrhy2FIhZLjcw6AqkoMcfadMbOio9hS9w5YIWhBl4uR8LEgpxcg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660426579; a=rsa-sha256; cv=none;
	b=Kqe/he+O/ELPmZCwNDijKzqrlaTbieMRRjtCZ4ykqlll/yPxGunMrqVxOfK6M23ZCemV8t
	jTuDKk0Sr45JY4K1wNnSalcJpbDrtyCvb7xWWTAYF6at/iijZhbepvVfLXsud8rCmPzLKR
	MX9boXwD4W6cVWBZBXZpzfFL4POULh2RVEaYKkQ/TSRz4RLMRiGCguoPT5lo52iwfmuu1X
	CihVii40mIvnvg4F2IyielyRARXv60phY+SObuGCKndxbc2hzJQid0XkZu2bTsmorkPZTG
	DoKXaJD9zd/ss0uT7b5VpmuBMs3qYEIqgBFcuABDZqvv8ORFFYbDQ52JpBuoIA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

From: Yasuhiro Kimura 
Subject: Updating EFI boot loader results in boot hangup
Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)

> I made regular update of my 14-CURRENT amd64 system from
> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
> boot hangup as following.
> 
> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
> 
> If I restore previous loader file (that is, loader.efi of
> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
> system boots successfully.

I submitted the problem to FreeBSD Bugzilla.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825

Best Regards.

---
Yasuhiro Kimura

From nobody Sat Aug 13 22:49:21 2022
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 4M4whm6K8kz4Z0J3
	for ; Sat, 13 Aug 2022 22:49:28 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4whl6XNRz3H1g;
	Sat, 13 Aug 2022 22:49:27 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: by mail-yb1-xb33.google.com with SMTP id h81so2302736ybh.3;
        Sat, 13 Aug 2022 15:49:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=Y04HQtYoo7b/mWUakKXdokRHZPh5JaFDSYPYvqWfvQA=;
        b=n+yw/78qC3JN2ZnEilzWF9bWHPVII2uTq3+Umc1aBTVb8Qm3P2CEFE/0m5F/QzyJ0L
         rH6B4GSauR93+8xYxsZryiaGG/qyluYrjj6tWMRCxiAp/9dOYLOVkg8t0OIVz2S8FRww
         jhsfajdP5l7fgmhiC9C2bKJV+K0Tz1RQrIrk7BDlgnNdRr5me60DiwsXgFYcBzZzrGbO
         loUJ5G28fZoGPFKrarYwDP8b0gltiT9paqk+Bkzumxlsp71Rf2FGHqRfHwDPQAQUNE2q
         Jyq+p3nS2NyeaEAg5j4bwg4idskghhYQODaYe4EEfHdaQ0pzF6ygkPO8wstbSZ+n/ngo
         KZJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=Y04HQtYoo7b/mWUakKXdokRHZPh5JaFDSYPYvqWfvQA=;
        b=omEPlZfVQ+Inj25KSuUxco+wfw1waRLUkQRP3L1e9OmyoQdhyNaZ/d3qtDXRWFXlKT
         WMIW0Zfrq0ay/uBylPFV5JsYqQ5gm9DUnPuSmszSxc43eCS7+IPZknd2X+9gaeJdcm6w
         +yOd6d8AdbFJ2TuFGTh1auHy4/O6t8nnAQpsiIYv4PEwq7WcqvLzB90hYGFqtq9kOoyP
         FcfdsAATaHtoN9hFhh7cl1S5OUNdeSHj5VqAmm39aNolQwynt0bguViQi6e+O6u8kgz9
         hw5bj2LRuaBWCLply+USIolmqJxgujGWlg5aZiKJ/xQSyPod4FCdoFLqeIf7VHxRI4P/
         bqFg==
X-Gm-Message-State: ACgBeo121nMw05HFfTTIoKUuVO9RF5iMaq7MEP1k9SQdkeoGEH3Hx/HD
	r14LgPr7kNaCP/w9p5ycb0BHGM2mPmn12q8qi9z5K9GhrhNYAQ==
X-Google-Smtp-Source: AA6agR4529K1yZlwlUWUz2nIiCrGsd7clsVnBzdZY+hQ2Se3P84rZqXEhRKelpbOWOtLRHPtddGFdqwCCYmt5E7HbEY=
X-Received: by 2002:a25:790d:0:b0:670:6032:b1df with SMTP id
 u13-20020a25790d000000b006706032b1dfmr7164612ybc.629.1660430967009; Sat, 13
 Aug 2022 15:49:27 -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: <20220813.015426.809710797578801280.yasu@FreeBSD.org> <20220814.063440.1883565953618972371.yasu@FreeBSD.org>
In-Reply-To: <20220814.063440.1883565953618972371.yasu@FreeBSD.org>
From: Oleg Lelchuk 
Date: Sat, 13 Aug 2022 18:49:21 -0400
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Yasuhiro Kimura 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000f673cc05e6273526"
X-Rspamd-Queue-Id: 4M4whl6XNRz3H1g
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="n+yw/78q";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of oleglelchuk@gmail.com designates 2607:f8b0:4864:20::b33 as permitted sender) smtp.mailfrom=oleglelchuk@gmail.com
X-Spamd-Result: default: False [-3.82 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.98)[-0.983];
	NEURAL_HAM_MEDIUM(-0.84)[-0.843];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b33:from];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000f673cc05e6273526
Content-Type: text/plain; charset="UTF-8"

I experienced the same problem. I hope this bug will be fixed soon.

On Sat, Aug 13, 2022 at 5:36 PM Yasuhiro Kimura  wrote:

> From: Yasuhiro Kimura 
> Subject: Updating EFI boot loader results in boot hangup
> Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)
>
> > I made regular update of my 14-CURRENT amd64 system from
> > main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
> > EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
> > boot hangup as following.
> >
> >
> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
> >
> > If I restore previous loader file (that is, loader.efi of
> > main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
> > system boots successfully.
>
> I submitted the problem to FreeBSD Bugzilla.
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825
>
> Best Regards.
>
> ---
> Yasuhiro Kimura
>
>

--000000000000f673cc05e6273526
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I experienced the same problem. I hope this bug will be fi=
xed soon.

On Sat, Aug 13, 2022 at 5:36 PM Yasuhiro Kimura <yasu@freebsd.org> wrote:
From: Yasuhiro Kimura <yasu@FreeBS=
D.org>

Subject: Updating EFI boot loader results in boot hangup

Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)



> I made regular update of my 14-CURRENT amd64 system from

> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
> boot hangup as following.

> 

> https://peopl=
e.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
> 

> If I restore previous loader file (that is, loader.efi of

> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then=


> system boots successfully.



I submitted the problem to FreeBSD Bugzilla.



https://bugs.freebsd.org/bugzilla/show_bu=
g.cgi?id=3D265825



Best Regards.



---

Yasuhiro Kimura






--000000000000f673cc05e6273526--

From nobody Sat Aug 13 22:59:55 2022
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 4M4wx40B0kz4Z3CQ
	for ; Sat, 13 Aug 2022 23:00:08 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4wx31wbcz3KyQ
	for ; Sat, 13 Aug 2022 23:00:07 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe2f.google.com with SMTP id 66so4087470vse.4
        for ; Sat, 13 Aug 2022 16:00:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=w2Z9CWNhPl4z82w1uFqNZruvRyO3oNByJRcmRgfIAes=;
        b=R1eLFB2wAJo87Kl5iw2QDBQQRk5si5AmlJNJCWiE1q4Hccf7PZNZyNvZM/4xq7Wzz9
         JB1evxuo6JCNxaZ7PJ2JEPyKtWX2HpCqQPjNufHrriAmgopOQtNOw112nO0a9FggjDQj
         7nY8bjhBdY+KsjOAkMKUGdD0pV6HEkjY2NTZQ5VpCFRJ+x8bt/zDJwEL8kXnOlxWmXce
         loogNTPwav2hWhP70QyWp30F6ddTs9+MKK4+4aqDJXG5Gctx5nfVBl7nsXxw+BWVOgJb
         7+uqKe5333mSMTvLjAMh8N/sPR+aEj8YgxXptz92Ew1HdCiBo0y9Oq/XOO4Q9bR0cG15
         H3pA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=w2Z9CWNhPl4z82w1uFqNZruvRyO3oNByJRcmRgfIAes=;
        b=Uk/mnejCtgf/T9n5TdlMasPtMw4ZCvf0vu8EiLqfAFLK/0swz/uwLAbCJNjUkKkayq
         NwHy5F6rN9BEgKi4mlVEPQHf5dwVcNTWJ1mRioPXz6F1BuL2ssEct8hA2HOzAfsZfjWU
         6ereBF/Q7jgKC6dGcE61hfysqKfLdbsA+TC2h7GoqIZx3uFi/t0nTuuKOfaGu1LqSGio
         /qgEeRef50ZEM4rsnHYDcnuqp2UwRUK+GiTM5UzZ9EIGyrEB4nXqzrhUntTUpJSKKq7v
         aK8/K6MNbaKpqHHUju3KJgdumeZ7YrFjw2/rYfX+BbyYY196RMiJm+QshxL33V+bIr2p
         aaPg==
X-Gm-Message-State: ACgBeo1IWLLnkCCGShwu0VVdMA2BPd/pOPMA3SCWF8ju+vkPuYse4RTo
	s56cNoYzFNfOQwBCQrKAIndFhrNCk0b+rrfMzgnHmA==
X-Google-Smtp-Source: AA6agR6/Md11n9e+w4OlJ6lpQ70glZIyjf1I9hNvEeWCYWDS6flK8ALeEYPllnIyF9Mk1tgba1pUV+hDz+v5M/OyQ8k=
X-Received: by 2002:a67:d50c:0:b0:38a:c107:25e0 with SMTP id
 l12-20020a67d50c000000b0038ac10725e0mr754744vsj.11.1660431606477; Sat, 13 Aug
 2022 16:00:06 -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: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
 <20220814.063440.1883565953618972371.yasu@FreeBSD.org> 
In-Reply-To: 
From: Warner Losh 
Date: Sat, 13 Aug 2022 16:59:55 -0600
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Oleg Lelchuk 
Cc: Yasuhiro Kimura , FreeBSD Current 
Content-Type: multipart/alternative; boundary="00000000000014097805e6275c96"
X-Rspamd-Queue-Id: 4M4wx31wbcz3KyQ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=R1eLFB2w;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2f) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2f:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000014097805e6275c96
Content-Type: text/plain; charset="UTF-8"

Any chance of a bisect of which revision starts to fail?

Warner

On Sat, Aug 13, 2022 at 4:49 PM Oleg Lelchuk  wrote:

> I experienced the same problem. I hope this bug will be fixed soon.
>
> On Sat, Aug 13, 2022 at 5:36 PM Yasuhiro Kimura  wrote:
>
>> From: Yasuhiro Kimura 
>> Subject: Updating EFI boot loader results in boot hangup
>> Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)
>>
>> > I made regular update of my 14-CURRENT amd64 system from
>> > main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
>> > EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
>> > boot hangup as following.
>> >
>> >
>> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
>> >
>> > If I restore previous loader file (that is, loader.efi of
>> > main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
>> > system boots successfully.
>>
>> I submitted the problem to FreeBSD Bugzilla.
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825
>>
>> Best Regards.
>>
>> ---
>> Yasuhiro Kimura
>>
>>

--00000000000014097805e6275c96
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Any chance=C2=A0of a bisect of which revision starts to fa=
il?

Warner

On Sat, Aug 13, 2022 at 4:49 PM Oleg Lel=
chuk <oleglelchuk@gmail.com=
> wrote:
I experienced the same problem. I hope this bug will be fixed =
soon.
On Sat, Aug 13, 2022 at 5:36 PM Yasuhiro Kimura <yasu@freebsd.org> wrote:
From: Yasuhiro Kimura &=
lt;yasu@FreeBSD.org>

Subject: Updating EFI boot loader results in boot hangup

Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)



> I made regular update of my 14-CURRENT amd64 system from

> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
> boot hangup as following.

> 

> https://peopl=
e.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
> 

> If I restore previous loader file (that is, loader.efi of

> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then=


> system boots successfully.



I submitted the problem to FreeBSD Bugzilla.



https://bugs.freebsd.org/bugzilla/show_bu=
g.cgi?id=3D265825



Best Regards.



---

Yasuhiro Kimura








--00000000000014097805e6275c96--

From nobody Sat Aug 13 23:29:29 2022
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 4M4xcZ43dVz4Z9wQ
	for ; Sat, 13 Aug 2022 23:30:54 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4xcZ3DjJz3Px7;
	Sat, 13 Aug 2022 23:30:54 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660433454;
	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=9YewjOolF9LQ+ypFo7wwqDlOd7rk9sa+qyEVJywtkNk=;
	b=O6qwfYGhMzBs6KNxK40DqWgxprJyw6nuu1uwqZ7R6Mk2Rpioe2aF42zCCRi42zDHxEn9iW
	83DTKRujEyJumyIeuIh+26krNN6/PKF2q4PVRMsqBHTHP3nYBdYgbQwFqFCuNVQ66YqdzW
	jga3WOxbdpTvHvDen3tZvCHtKZPtAAQEN4qUUebr6W7j7ET4X18D60LeaAdX3yyqHh3Rqk
	63W2exAketK8SoTYHeyg8eRQwqMOnvt4OHv/Ckzt2SIw4ly2e8JvL2h4Y+eCLbSrkAviHx
	Q8BsWBcYFLaCjllSlBGWnKLIqJQbTrqggARDt97jLWshUR7K27hP8P+vMbPu3g==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:60c0:516d:769d:a3d2])
	(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: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4xcY5VtZztcs;
	Sat, 13 Aug 2022 23:30:53 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Sun, 14 Aug 2022 08:29:29 +0900 (JST)
Message-Id: <20220814.082929.62024764169408152.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura 
In-Reply-To: 
References: <20220814.063440.1883565953618972371.yasu@FreeBSD.org>
	
	
X-Mailer: Mew version 6.8 on Emacs 29.0.50
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: base64
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660433454;
	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=9YewjOolF9LQ+ypFo7wwqDlOd7rk9sa+qyEVJywtkNk=;
	b=oOZ5s87TV/Yx5ClvaWe+/6M5p9ePnhKf8RXsJHNLouqScMZBB/MAvahoeBe5BXR37prE83
	2byNjUNHM839n/i0tnsf7ngOxGPdX46Aibow/TRUYqt47Vo62rMLQyq0Sh2hBJB+YdLPBY
	7Ik+p4PVrcuEd4wdeAYC+ehq87xWvOZlw2O3OxN12QcJjCNqBnvk72zWV3tznfd5oxs/ZV
	9EuFNW2rJSpk3oHV0aotBUauzwcHekP4QqAkCOq1WV//ubPamNXNmXspTg6plosS5FlkL1
	s0luvYkW3G9vhAWAduoRqSf8wjM39hJ6qs+3Juy7O+4FwakoU089KsAXCywzYQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660433454; a=rsa-sha256; cv=none;
	b=WASAEo40cPJ6HASBoseQsuFx6JD5eZTffAzymjiRXKv/QtRXm9K38+NRam1iTd4bTXvvUG
	KQsgSCKtpV6XnA8ewCElYbE5w1mzfkVAJZdt0Y3wGFqzpAGzCyzPOKJzDDUBVdTzAJ7iBS
	18ym836XVvdaUDHjh9HETSozqcQcw1SGZkI83/EprXQqkfHs5WuLZ3poPuAiNvJfPyLHwn
	i1KNJoLC5cb16Wey7xxpx6TgNtA/0+0IO6TQEz399uYyRJDWIbBI+IV17xhOwZ0DX71NRb
	Y4sI4Lg83Vjua1Kug6qRVXE2fnNXg8W6kyhanmUP4dfEa4/NxkaV/FBVaroNRg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

RnJvbTogV2FybmVyIExvc2ggPGltcEBic2RpbXAuY29tPg0KU3ViamVjdDogUmU6IFVwZGF0aW5n
IEVGSSBib290IGxvYWRlciByZXN1bHRzIGluIGJvb3QgaGFuZ3VwDQpEYXRlOiBTYXQsIDEzIEF1
ZyAyMDIyIDE2OjU5OjU1IC0wNjAwDQoNCj4gQW55IGNoYW5jZcKgb2YgYSBiaXNlY3Qgb2Ygd2hp
Y2ggcmV2aXNpb24gc3RhcnRzIHRvIGZhaWw/DQo+IA0KPiBXYXJuZXINCg0KSSdsbCB0cnkgaXQu
DQoNCklzIGl0IHBvc3NiaWxlIHRvIGJ1aWxkIG9ubHkgbG9hZGVyLmVmaSB3aXRob3V0IGRvaW5n
IGJ1aWxkd29ybGQ/DQpJJ2QgbGlrZSB0byBzaG9ydGVuIHRoZSB0aW1lIHRvIHRha2UgZm9yIHNp
bmdsZSBzdGVwIG9mIGJpc2VjdC4NCg0KLS0tDQpZYXN1aGlybyBLaW11cmENCg==

From nobody Sat Aug 13 23:32:16 2022
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 4M4xfH3Q4Jz4ZBs1
	for ; Sat, 13 Aug 2022 23:32:23 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4xfG4fw6z3RSR;
	Sat, 13 Aug 2022 23:32:22 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: by mail-yb1-xb30.google.com with SMTP id 7so6822530ybw.0;
        Sat, 13 Aug 2022 16:32:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=u+U5cPHx8qYQUmDvjroBoHGoZEOaCO08BhHNzpeZyxU=;
        b=KTO3NM5tlRa+fqoWKk5JCokNimM1svu8IDSzvYczJsAcqcgTQqAcPB3RXdNvfVD2S7
         GWO+LxfD7SfrD42EayLQEyHCs0cI4DbU3vA44fsAun28tzB58MZm5/t98OD+pwJxM5Zo
         TbT7JpPewJxljvi3dOvcu13OW+tIwWDJaAs0Si8Gi8aUtF48S1bl5QlO3n9S7Q4zKD87
         X9XRxm1tHr7FSY622xdU26XpeCT3Wyeum+HPdZPNfO7XU/c7q6nszcDhTEG3M+OnGaU1
         nwCypedO4bwte2O8Zd9rxxD6hd8NMWeJmWcSVDeOcF4J7pyjbAgsRgt0gDNuV5d2QmO4
         knIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=u+U5cPHx8qYQUmDvjroBoHGoZEOaCO08BhHNzpeZyxU=;
        b=Xo1PMtDxTRkYSX9PMvJS5JHD+EyoZniE9FOwhiS+0tCLRd4f/XtewYDnY8Fk9MdNQ0
         6X015SBCc9g7bJExIaeKqhBYpTwJEuRfgNeGdbzIIBh1h9uBwC4WTVahQgnZ8MsxHiWH
         eERA4i6UD8udLSFeZq6I9824IFN8kF5bu1zgAT+JKLvyhbtGt4C6Y1rNuDkyqGx/FirF
         5o5yk3eQtZEhZUBow2fUUXxbtxaqLOlSxw16OhPigV5ZpoqXMfL2MIHp7ofduf+VZ+O3
         /hdZOWAKtd7S3w2Q0gW3fLYKIKKPVo/bW/eIqGkTJROI6Ai/4mbJsXR+TWHLl89TFGy4
         v1BQ==
X-Gm-Message-State: ACgBeo2iX099ENfgqJeRNlWjisxB/SoEp4c1PbjZukwYjD8AAZPnL9Ph
	MNtqZ35Yh+s29fD9NaIFG5EOWQYv6WlhNmGQwPxduh4ACBzuLg==
X-Google-Smtp-Source: AA6agR5wQLkSMFq2sVfFw1d8stKwZPpSAm1fjTsaMT4zb6TlhrwLCIGdtQVFVOiiVDwP7I3N52OJdU/pAL/1UGOWJA8=
X-Received: by 2002:a25:ba91:0:b0:683:ebc2:7114 with SMTP id
 s17-20020a25ba91000000b00683ebc27114mr5644379ybg.319.1660433541675; Sat, 13
 Aug 2022 16:32:21 -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: <20220814.063440.1883565953618972371.yasu@FreeBSD.org>
 
  <20220814.082929.62024764169408152.yasu@FreeBSD.org>
In-Reply-To: <20220814.082929.62024764169408152.yasu@FreeBSD.org>
From: Oleg Lelchuk 
Date: Sat, 13 Aug 2022 19:32:16 -0400
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Yasuhiro Kimura 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000006cbf9205e627cf1d"
X-Rspamd-Queue-Id: 4M4xfG4fw6z3RSR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=KTO3NM5t;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of oleglelchuk@gmail.com designates 2607:f8b0:4864:20::b30 as permitted sender) smtp.mailfrom=oleglelchuk@gmail.com
X-Spamd-Result: default: False [-3.86 / 15.00];
	NEURAL_HAM_LONG(-0.99)[-0.994];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	NEURAL_HAM_MEDIUM(-0.88)[-0.883];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b30:from];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000006cbf9205e627cf1d
Content-Type: text/plain; charset="UTF-8"

You can do make and make install in /usr/src/stand

On Sat, Aug 13, 2022 at 7:31 PM Yasuhiro Kimura  wrote:

> From: Warner Losh 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Sat, 13 Aug 2022 16:59:55 -0600
>
> > Any chance of a bisect of which revision starts to fail?
> >
> > Warner
>
> I'll try it.
>
> Is it possbile to build only loader.efi without doing buildworld?
> I'd like to shorten the time to take for single step of bisect.
>
> ---
> Yasuhiro Kimura
>

--0000000000006cbf9205e627cf1d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


You can do make and make install in /usr/src/stand
On Sat, =
Aug 13, 2022 at 7:31 PM Yasuhiro Kimura <yasu@freebsd.org> wrote:
From: Warner Losh <imp@bsdimp.com>

Subject: Re: Updating EFI boot loader results in boot hangup

Date: Sat, 13 Aug 2022 16:59:55 -0600



> Any chance=C2=A0of a bisect of which revision starts to fail?

> 

> Warner



I'll try it.



Is it possbile to build only loader.efi without doing buildworld?

I'd like to shorten the time to take for single step of bisect.



---

Yasuhiro Kimura




--0000000000006cbf9205e627cf1d--

From nobody Sat Aug 13 23:40:37 2022
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 4M4xqz6xTsz4ZDPx
	for ; Sat, 13 Aug 2022 23:40:47 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4xqz6SFLz3SnV;
	Sat, 13 Aug 2022 23:40:47 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660434047;
	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=zOuAqB+8ZTG3izMH7H4qPKfJHdD+C2TYhBJFUA/zbLM=;
	b=oWhkKACYgbkelcY++i/gF73crG+W68DBz//6oXO5nybDyBHJaqSMQOPcUDFLKgKLBJ4085
	buFonJL3gfktFOEWp/e+o8tzhQ2n8xF4SYue8U8YrtM3PJXDqrIw4GPeP1lKfJISlucS99
	NxAvc0A8XZq/VpnetxH01r9it/vaXBcVAzNqD4tfeiwYi/no7FnzBWJr2JQm6eEd1FoDoq
	ZJQB2Sd3fRWgCQa2yl7T6Fvzu2blVMpX8RQttK8Fo2rJsQfbQc26lo/tIoVI6l1F2CrxC5
	YzSHaoDT+COLO7Cr7/S8UCuTWWIeG9vuPv4Z7nYe20pkizHrrnsPiLxnyy/rCg==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:60c0:516d:769d:a3d2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4xqz00zTzv2C;
	Sat, 13 Aug 2022 23:40:46 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Sun, 14 Aug 2022 08:40:37 +0900 (JST)
Message-Id: <20220814.084037.1953883684410810254.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura 
In-Reply-To: 
References: 
	<20220814.082929.62024764169408152.yasu@FreeBSD.org>
	
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660434047;
	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=zOuAqB+8ZTG3izMH7H4qPKfJHdD+C2TYhBJFUA/zbLM=;
	b=S7FImARf2S+iBoTrs/zBKG/clGkA/7S10fXk4J3Z5Zpfl1YYRY7Sjejz8X7tdriAlLsE04
	Yw8P+Z47ttNQe5xZ8yPauY6MEJqo3piMkprg7Qht+Wk05lRPrCfHVsRJVpY7TaWesV9YVQ
	5XicJDvb1lBcrRFgIdcUSde6d0FPiB3DfDEWOHSCojysMjQnCbwTjTTQbMj0oeOs51RXnp
	i9PEUJOtxMsR+mSJoU7xGflBylJfA7UFeLyDyfIbwb3SX8THU1jSIClQpKqb4EsGYrKDdd
	lcJBN1WgaYiabNu036qfFC6MEzriobY9wGQA5DcilqxPNFDPux+wOrgBnR4wBQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660434047; a=rsa-sha256; cv=none;
	b=Gec3xPwdOlrqfb5DobBcxtQ24Lp/uOhWtTy1XJmQPDjwnd1OjnENBbYi+8YFq3Q5yYg1AY
	PJNtd9Sc/1+Q2RZJ2i38W/7iSG2FReBuOfJt70xsNMPZ1hgKNZB2BwVR0hYSNTxZj5h72d
	NDtGrHFCWjHcIMOh9Y80Nynpg9/1/Y0MMyY2qr3hsAwyqiCFpIEKdmsZ87DS+7CXC46umZ
	HHa4I7USVwtu6lkGw6T1uQVXsyiJon39827hbM8nXYT1yALu24arXyfc4V73t6/3ypKFhV
	1v2sKUHj03mxBsdFnPoMaTyMhjDBSXinGe1SE7sB8r2Uf4vjWLrq5FPecoAtBw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

From: Oleg Lelchuk 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Sat, 13 Aug 2022 19:32:16 -0400

> You can do make and make install in /usr/src/stand

Thanks for letting me know. I'll try it.

---
Yasuhiro Kimura

From nobody Sun Aug 14 00:28:09 2022
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 4M4ytm3HXyz4ZQt9
	for ; Sun, 14 Aug 2022 00:28:16 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4ytl65C1z3YhK;
	Sun, 14 Aug 2022 00:28:15 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-32868f43dd6so39960167b3.8;
        Sat, 13 Aug 2022 17:28:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=6XZ8TPXu2i1Qjz4QYZwbxQA3DY+5xrKYWDUXVKGhE+M=;
        b=CJoZIfkyJLvN2nxVtI1RBO0XhPx+hdBW0MGDs/3RxsFcCk1oD5CM7zMlfVq6E6oHwB
         upaR3gvC+8H3NDWaBWcrOH46Fzs26VPmpA9Wr0pya8u411QBlUHvN8Aq2x/BuTGtbzop
         hmx/96fN+Hbe+TyGxi2Lhq0ShoLXAMGPKqnNENkQJewOsmBATS1OAyP34dzvtE/89s/q
         FUZXMBh3wtjCW8i/plsVtRBMYBD3UKCf1ghhIvbzNDJS7aVFSI6JoiO2fAbYWMydXBKz
         FWn7pMJY2efP08OC5+kMt5ix0uB046w2doROQOVXA/avGruMe61rFMuAaZwOXF/2DDeS
         NfuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=6XZ8TPXu2i1Qjz4QYZwbxQA3DY+5xrKYWDUXVKGhE+M=;
        b=OFHyCW0EeGfYOjtsKpTrvMMmdsGqYjkejAHlZWV2FKv/6K9m8hmkbqDaLkDXnmfQ67
         BOz1sIT0uHJx6otj9a677CXEHqWiVyfbtsG54+7WkKxUqhz23CkeXAWM90cVtm5wRgy8
         2BlJbvhclz8cjczDMAHOwc6I2zHp+AnmVNd4duaYYLyeSFFwjQiUltOpYQLLFqQbhiqX
         uF7iE35apZE6qHd8/P3mLsFKpGmLf1SrgjzyuxNuidl2sbfaNUCa+HuPXkpOX0yXJsSQ
         LB4NKNgiVgSpNYjZ7S4Bk0O2k5iheqNca2pTebgZtjDoozpfF2tsQ1dpIQZxFed8KHi0
         zKzw==
X-Gm-Message-State: ACgBeo2bxyYkeHt6SKHo8XZG3i126FDeqgpZV4pX1rW0imHxIyzLyoYw
	7nXU1gnD90esyojkj1JTiF2LP3yJAnJEX742hXqCz6zxUXArsBC2
X-Google-Smtp-Source: AA6agR5F2QHGPh5OgMa+9O4IvrF/MQEFpQWXU9TFaUAmtOjAW1phybMVrfff/EAxnmlYt8WjLUhDfXqwDWDdUBJdQSc=
X-Received: by 2002:a81:10c5:0:b0:31f:5a88:15c1 with SMTP id
 188-20020a8110c5000000b0031f5a8815c1mr8263304ywq.254.1660436895028; Sat, 13
 Aug 2022 17:28:15 -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: 
 <20220814.082929.62024764169408152.yasu@FreeBSD.org> 
 <20220814.084037.1953883684410810254.yasu@FreeBSD.org>
In-Reply-To: <20220814.084037.1953883684410810254.yasu@FreeBSD.org>
From: Oleg Lelchuk 
Date: Sat, 13 Aug 2022 20:28:09 -0400
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Yasuhiro Kimura 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000004cda9e05e6289761"
X-Rspamd-Queue-Id: 4M4ytl65C1z3YhK
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=CJoZIfky;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of oleglelchuk@gmail.com designates 2607:f8b0:4864:20::1135 as permitted sender) smtp.mailfrom=oleglelchuk@gmail.com
X-Spamd-Result: default: False [-3.79 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	NEURAL_HAM_MEDIUM(-0.81)[-0.812];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1135:from];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000004cda9e05e6289761
Content-Type: text/plain; charset="UTF-8"

I can already see that commit
c32dde3166922f55927764464d13f1bc9640f5f6

causes
breakage, but the commit that precedes it

f197c0bf3e075286ccea32cd12023f3317474c5a

doesn't
cause breakage and the system boots just fine with it. But the error that
the c32dd commit causes is different from the error that we see now, so
maybe there is a possibility that one of the commits that follow it fixed
the breakage, but then yet another commit caused a different kind of
breakage again.

On Sat, Aug 13, 2022 at 7:41 PM Yasuhiro Kimura  wrote:

> From: Oleg Lelchuk 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Sat, 13 Aug 2022 19:32:16 -0400
>
> > You can do make and make install in /usr/src/stand
>
> Thanks for letting me know. I'll try it.
>
> ---
> Yasuhiro Kimura
>
>

--0000000000004cda9e05e6289761
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I can already see that commit=C2=A0
=

c32dde3166922f55927764464d13f1bc9=
640f5f6=C2=A0causes breakage, but the commit that precedes it=C2=A0

f197c0bf3e075286ccea32cd12023f3317474c=
5a=C2=A0doesn't cause breakage and the system boots just fine with =
it. But the error that the c32dd commit causes is different from the error =
that we see now, so maybe there is a possibility that one of the commits th=
at follow it fixed the breakage, but then yet another commit caused a diffe=
rent kind of breakage again.=C2=A0

On Sat, Aug 13,=
 2022 at 7:41 PM Yasuhiro Kimura <ya=
su@freebsd.org> wrote:
From: Oleg Lelchuk <oleglelchuk@gmail.com>

Subject: Re: Updating EFI boot loader results in boot hangup

Date: Sat, 13 Aug 2022 19:32:16 -0400



> You can do make and make install in /usr/src/stand



Thanks for letting me know. I'll try it.



---

Yasuhiro Kimura






--0000000000004cda9e05e6289761--

From nobody Sun Aug 14 00:57:21 2022
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 4M4zY733wSz4ZYBG
	for ; Sun, 14 Aug 2022 00:58:03 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M4zY72YSxz3dMB;
	Sun, 14 Aug 2022 00:58:03 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660438683;
	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=x7S8QLFPkngk44SQrOP8JwPhUBfA6u45Y7f2rLAGPFE=;
	b=cBKcb/w+bPjs1GJqWH2kkhNisV9I1PX3ujtbi7cvEJXpPwy9Eo2C6V4Zf35VhBzDqWZ7eV
	qjtYiQJX1UxHzHT5+2MPwJC2sycbVYeFRxYcvUPEgUpYWOQlnxrR8r7LKh/nFVTEa1WtcY
	qJEohO6mbmdw133dkAE/E0twa61ZYgjOVySXzDj8CK57AwRKXE1BuqFL5VLVGRE68GnnYW
	1RliIaQ+SlWcuw+Q3MpPICt3Yq5RMFWQ/2JPPcQrj11irfi50/Q17od3u+F1PQHGcYtJDI
	OapoPWcnSTPlo4QsUHRy9fuSzqwHqyTY0vZHAfqaLZLepH1ModSlYGDKx3gYCw==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:60c0:516d:769d:a3d2])
	(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: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4zY64hjNzwPF;
	Sun, 14 Aug 2022 00:58:02 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Sun, 14 Aug 2022 09:57:21 +0900 (JST)
Message-Id: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura 
In-Reply-To: 
References: 
	<20220814.084037.1953883684410810254.yasu@FreeBSD.org>
	
X-Mailer: Mew version 6.8 on Emacs 29.0.50
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: base64
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660438683;
	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=x7S8QLFPkngk44SQrOP8JwPhUBfA6u45Y7f2rLAGPFE=;
	b=a6/IPn7jtdiyTpzjjDBwIqOY3GIpCfniEzfFB/1H1XLAIMlEy6EEE1IpjDqLr08Dv/HCM6
	hVRdOwCpVnAf/o0NfsRFlfyrHwOWcOm1q46QKug4TFRbWS0qpUcVilGY2B4qcF3iGg6Ffb
	O1EaTYA7ME8NXa+Uv2e/bsxJ+5XI/+TEFcECjt71zET7vp7xbnlROjzk84qW/wE49ti3z+
	jOnVP4LqDqPeAbc0u9yA/URTW/pJKBQ4Ynr3SVdXzZFUM6oksMRK0J29PUfgBMWbGBckuN
	oVnf6P2fBwE9nAyDeYNRB+fH8CeqUMfoDHOetUB3mSXU/R6Ubye2aedJVtU2OQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660438683; a=rsa-sha256; cv=none;
	b=MU5S2CHvUYYty6RRJGsy8JEljzwQUotkpYakbmYo9TqQbPqYBq7UwLeG6QuOskB9WC2Nlf
	Q7AqzoIW7oSz9Rq9eVpuLQIP4S2x8v+yuhegi//FTMixk9PBBcIspnsHX20V/un7ijjm+9
	AjsGpbREGGl7qb/tttV8ypg8X+IdzCFTQRxxOPRjLJjrBLpjszNO2c/0pmaPuOMwBwda2G
	jRTAYdferlTRes3fuSnugQIsj+rVPS5GSy6QdoT5im7q/r9XqH7u37fnKEcE4VJrxXGYNV
	MRucOJBfnYnAIUdcTQKXu7yBmfGxs4x8ZLkojtmOejElYGPfcDlcPQcxCb3llQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

RnJvbTogT2xlZyBMZWxjaHVrIDxvbGVnbGVsY2h1a0BnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTog
VXBkYXRpbmcgRUZJIGJvb3QgbG9hZGVyIHJlc3VsdHMgaW4gYm9vdCBoYW5ndXANCkRhdGU6IFNh
dCwgMTMgQXVnIDIwMjIgMjA6Mjg6MDkgLTA0MDANCg0KPiBJIGNhbiBhbHJlYWR5IHNlZSB0aGF0
IGNvbW1pdA0KPiANCj4gYzMyZGRlMzE2NjkyMmY1NTkyNzc2NDQ2NGQxM2YxYmM5NjQwZjVmNsKg
Y2F1c2VzIGJyZWFrYWdlLCBidXQgdGhlIGNvbW1pdCB0aGF0IHByZWNlZGVzIGl0DQo+IA0KPiBm
MTk3YzBiZjNlMDc1Mjg2Y2NlYTMyY2QxMjAyM2YzMzE3NDc0YzVhwqBkb2Vzbid0IGNhdXNlIGJy
ZWFrYWdlIGFuZCB0aGUgc3lzdGVtIGJvb3RzIGp1c3QgZmluZSB3aXRoIGl0LiBCdXQNCj4gdGhl
IGVycm9yIHRoYXQgdGhlIGMzMmRkIGNvbW1pdCBjYXVzZXMgaXMgZGlmZmVyZW50IGZyb20gdGhl
IGVycm9yIHRoYXQgd2Ugc2VlIG5vdywgc28gbWF5YmUgdGhlcmUgaXMgYQ0KPiBwb3NzaWJpbGl0
eSB0aGF0IG9uZSBvZiB0aGUgY29tbWl0cyB0aGF0IGZvbGxvdyBpdCBmaXhlZCB0aGUgYnJlYWth
Z2UsIGJ1dCB0aGVuIHlldCBhbm90aGVyIGNvbW1pdCBjYXVzZWQgYQ0KPiBkaWZmZXJlbnQga2lu
ZCBvZiBicmVha2FnZSBhZ2Fpbi4NCg0KV2l0aCB0aGUgY29tbWFuZCBgZ2l0IGJpc2VjdCBzdGFy
dCAtLWZpcnN0LXBhcmVudCA5ZDE2Mjc1YzY1YiBhNjljMDk2NDYyNSAtLSBzdGFuZGANCkkgZ290
IGp1c3Qgc2FtZSByZXN1bHQuDQoNCi0tLQ0KWWFzdWhpcm8gS2ltdXJhDQo=

From nobody Sun Aug 14 01:31:31 2022
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 4M50Ht2pzmz4Xk8B
	for ; Sun, 14 Aug 2022 01:31:38 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M50Hs5g0Hz3jMP;
	Sun, 14 Aug 2022 01:31:37 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-31f445bd486so40430797b3.13;
        Sat, 13 Aug 2022 18:31:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=60JwWIETWl9Cwe8RGbJpikkr1Nygoq6fb1YvXNqVLlE=;
        b=QVDifFYMDp9qq/ewpUZ7/1+rtNUbbjo9LBnFNLD6QQif0Uio3fjzo78J8U1IyWw5oq
         Ro2UlHcM/0BJqvFJlswOKF8GA0LHo0IW2ECbxYviwfZR+CRlNnSWj0P1Sf+H2y6NaYFt
         N6gws5CSywzZFwoK+B8SlHMZH+2hHHz3/pTgtebamiqNMNBeYL2+jDWB1kwmY7sKyd5x
         uP68XTKPkhZBAirWyHjItIoJYZ/qcVdXzp51XuG8TKEN5UKKkqXerM8kwjyp0S55gwdv
         e6R5129WmZoENu+O6Odz/FP4z+b9+gM4Ht+SHXARkoo1KnnNFXlRp97o0SlrYYzP0pGd
         ioQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=60JwWIETWl9Cwe8RGbJpikkr1Nygoq6fb1YvXNqVLlE=;
        b=fBygvKzMZI+shEunyKcUsQAY9//6P13XV8LDytlblwMch4y4tETbqtevNNwNTKFOK/
         uanNN2cNRZWrpYsTlkAJgF1AtYQP5DT2NSfdMRwq2sBYDfOJgNdOfnw77q/C78jG3ceg
         Bvg+XdsRtpFf8OpJ6sJeoWHOsWHJ46hAzyDipB0D3ssrpJs/C88C8BF/Ol7jOaepLQDC
         mkpeSqoAUlfkx8ImBbaSwS9Xd1f3gz+eHCIK8j5wj+gdE/DKbEJKIkva6dFlG4NA3jeb
         wV6KIQ/pKc1ALpndoxodZ63qwWCDjQOBgmoNqxDosB80iu2+Oz/85Gt5S8vGMVhA5vSI
         QbJg==
X-Gm-Message-State: ACgBeo3H9z+ieQSc1GR12rz9o4jfSpfXfNqxPDvB7agSIgM8lodtNadI
	nvdaErRS2eGLjH+mvzdWoxobZhn/+h7MrmZGc/KV3Lw60wZ38Ap5
X-Google-Smtp-Source: AA6agR4A8OgVmGfNTrjqsYbbSXnkTKU1IWjf29e8+opHKcHkFfWB99mRKMxHVlhyv+lGMr+wuaXzlfaQStzi0PTcRD4=
X-Received: by 2002:a81:10c5:0:b0:31f:5a88:15c1 with SMTP id
 188-20020a8110c5000000b0031f5a8815c1mr8369271ywq.254.1660440696844; Sat, 13
 Aug 2022 18:31:36 -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: 
 <20220814.084037.1953883684410810254.yasu@FreeBSD.org> 
 <20220814.095721.849461222067829352.yasu@FreeBSD.org>
In-Reply-To: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
From: Oleg Lelchuk 
Date: Sat, 13 Aug 2022 21:31:31 -0400
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Yasuhiro Kimura 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000e7f52d05e62979a9"
X-Rspamd-Queue-Id: 4M50Hs5g0Hz3jMP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=QVDifFYM;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of oleglelchuk@gmail.com designates 2607:f8b0:4864:20::1136 as permitted sender) smtp.mailfrom=oleglelchuk@gmail.com
X-Spamd-Result: default: False [-3.79 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	NEURAL_HAM_MEDIUM(-0.81)[-0.814];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1136:from];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e7f52d05e62979a9
Content-Type: text/plain; charset="UTF-8"

I don't understand what your command does. All I can see is that
https://cgit.freebsd.org/src/commit/?id=ec9f3e776f39286ccec9915f38cca9729e6f9241
causes the error that we currently see, and the commit that precedes it
https://cgit.freebsd.org/src/commit/?id=ad759c73522efb606135e2891ac03864926b80a3
causes a different kind of error.

On Sat, Aug 13, 2022 at 8:58 PM Yasuhiro Kimura  wrote:

> From: Oleg Lelchuk 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Sat, 13 Aug 2022 20:28:09 -0400
>
> > I can already see that commit
> >
> > c32dde3166922f55927764464d13f1bc9640f5f6 causes breakage, but the commit
> that precedes it
> >
> > f197c0bf3e075286ccea32cd12023f3317474c5a doesn't cause breakage and the
> system boots just fine with it. But
> > the error that the c32dd commit causes is different from the error that
> we see now, so maybe there is a
> > possibility that one of the commits that follow it fixed the breakage,
> but then yet another commit caused a
> > different kind of breakage again.
>
> With the command `git bisect start --first-parent 9d16275c65b a69c0964625
> -- stand`
> I got just same result.
>
> ---
> Yasuhiro Kimura
>

--000000000000e7f52d05e62979a9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I don't understand what your command does. All I can s=
ee is that=C2=A0https://cgit.freebsd.org/src/commit/?id=
=3Dec9f3e776f39286ccec9915f38cca9729e6f9241 causes the error that we cu=
rrently see, and the commit that precedes it https://cg=
it.freebsd.org/src/commit/?id=3Dad759c73522efb606135e2891ac03864926b80a3 causes a different kind of error.

On Sat, Aug 13, 2022 at 8:58 PM Yasuhiro=
 Kimura <yasu@freebsd.org> wr=
ote:
From: Oleg =
Lelchuk <oleg=
lelchuk@gmail.com>

Subject: Re: Updating EFI boot loader results in boot hangup

Date: Sat, 13 Aug 2022 20:28:09 -0400



> I can already see that commit

> 

> c32dde3166922f55927764464d13f1bc9640f5f6=C2=A0causes breakage, but the=
 commit that precedes it

> 

> f197c0bf3e075286ccea32cd12023f3317474c5a=C2=A0doesn't cause breaka=
ge and the system boots just fine with it. But

> the error that the c32dd commit causes is different from the error tha=
t we see now, so maybe there is a

> possibility that one of the commits that follow it fixed the breakage,=
 but then yet another commit caused a

> different kind of breakage again.



With the command `git bisect start --first-parent 9d16275c65b a69c0964625 -=
- stand`

I got just same result.



---

Yasuhiro Kimura




--000000000000e7f52d05e62979a9--

From nobody Sun Aug 14 02:01:03 2022
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 4M50y44FJ7z4XttN
	for ; Sun, 14 Aug 2022 02:01:16 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M50y35D0Tz3nKw
	for ; Sun, 14 Aug 2022 02:01:15 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe36.google.com with SMTP id q15so4318206vsr.0
        for ; Sat, 13 Aug 2022 19:01:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=KSlmCQmwWv2oUh+2MIKGmXNpD+z/sdq3Ka5JJ3u29fg=;
        b=dVdnrPxo00dB2nYwsOPLLhLvusIE3F/Fdrjq/z/JOavEq+YSU5jTHVFaNdDrlqo99y
         Ll1xl8meUJxg6XqBaeJnFQ8aVkhRUaXJK4wlvI3vVBQfvRBY/H1KtYdB0fkg/m3IBysC
         majdfYSD6eVmVmjalrqntz6AksZiaXpD0i041JWplSsFgmjOf2G+9U936cw1FRZ30SO8
         CeK7qoP9nrH5J0P9RBAdcwjiohrPgkqALFcQYpAxGhNLU4Urkk4AjGkkbwuYUer5WZkX
         9+EzIyhlfVtk1N1rOsCRcErjqD3YEYvR8TJhRXFsI2O7n1ngX3LkBTWs2U1q1WOp6KzG
         vsHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=KSlmCQmwWv2oUh+2MIKGmXNpD+z/sdq3Ka5JJ3u29fg=;
        b=7tYIH2j6F2N2JugMph6Qa7OhdswPeeesQM3cvkRmLHc9TpFnmCux63x9LwFsHHRXxw
         yY9Z94AWxD/j4/dBxfGQtE2rjRHbmjGyVoeAy61vadnhMdcAZ1y5VohJxv7sWBUpAzR0
         ldPzPmULrJyY6KFuQcZWd+SQ3CLfNk3wXSOQm6zDtR/pkHvQoiwcsasWIsK6o3YTJBXY
         5pa5rOvIIGOqsuASOWPNzWIwcqBVrkU4Ebj3r5OTfZX2gVnN7W8mSXnReq5OuW4POVd4
         jsvPeZJbXy+87+h1iqranMfxxCF8hTkhWPRkLW6yybnKmSb8mWsNbTxHQFTh2dlM5gVW
         INeQ==
X-Gm-Message-State: ACgBeo0qeB4EbU121JPvhJT1yWY/VIVew8tCjtaav7hkfyH83tHPaBky
	jV33CZKZzs4rZy3554G1pXqaQM79Q3V0koTRzRaS0g==
X-Google-Smtp-Source: AA6agR5bIHxgsB1GC1s6ixQOnCLSDTnZHhJ1Ja33XG17XvIQ9l9GuAZVOSOETGI9HpFBfElEyxKPWet5hK30A5M4wtI=
X-Received: by 2002:a67:fdce:0:b0:388:485c:889c with SMTP id
 l14-20020a67fdce000000b00388485c889cmr3932716vsq.38.1660442474707; Sat, 13
 Aug 2022 19:01:14 -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: 
 <20220814.084037.1953883684410810254.yasu@FreeBSD.org> 
 <20220814.095721.849461222067829352.yasu@FreeBSD.org> 
In-Reply-To: 
From: Warner Losh 
Date: Sat, 13 Aug 2022 20:01:03 -0600
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Oleg Lelchuk 
Cc: Yasuhiro Kimura , FreeBSD Current 
Content-Type: multipart/alternative; boundary="000000000000e013d705e629e315"
X-Rspamd-Queue-Id: 4M50y35D0Tz3nKw
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=dVdnrPxo;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e36) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e36:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e013d705e629e315
Content-Type: text/plain; charset="UTF-8"

UFS or ZFS?

Warner

On Sat, Aug 13, 2022 at 7:31 PM Oleg Lelchuk  wrote:

> I don't understand what your command does. All I can see is that
> https://cgit.freebsd.org/src/commit/?id=ec9f3e776f39286ccec9915f38cca9729e6f9241
> causes the error that we currently see, and the commit that precedes it
> https://cgit.freebsd.org/src/commit/?id=ad759c73522efb606135e2891ac03864926b80a3
> causes a different kind of error.
>
> On Sat, Aug 13, 2022 at 8:58 PM Yasuhiro Kimura  wrote:
>
>> From: Oleg Lelchuk 
>> Subject: Re: Updating EFI boot loader results in boot hangup
>> Date: Sat, 13 Aug 2022 20:28:09 -0400
>>
>> > I can already see that commit
>> >
>> > c32dde3166922f55927764464d13f1bc9640f5f6 causes breakage, but the
>> commit that precedes it
>> >
>> > f197c0bf3e075286ccea32cd12023f3317474c5a doesn't cause breakage and the
>> system boots just fine with it. But
>> > the error that the c32dd commit causes is different from the error that
>> we see now, so maybe there is a
>> > possibility that one of the commits that follow it fixed the breakage,
>> but then yet another commit caused a
>> > different kind of breakage again.
>>
>> With the command `git bisect start --first-parent 9d16275c65b a69c0964625
>> -- stand`
>> I got just same result.
>>
>> ---
>> Yasuhiro Kimura
>>
>

--000000000000e013d705e629e315
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


UFS or ZFS?

Warner

On Sat, Aug 13,=
 2022 at 7:31 PM Oleg Lelchuk <=
oleglelchuk@gmail.com> wrote:
I don't understand what your comm=
and does. All I can see is that=C2=A0=
https://cgit.freebsd.org/src/commit/?id=3Dec9f3e776f39286ccec9915f38cca9729=
e6f9241 causes the error that we currently see, and the commit that pre=
cedes it https://cgit.freebsd.org/src=
/commit/?id=3Dad759c73522efb606135e2891ac03864926b80a3 causes a differe=
nt kind of error.

On Sat, Aug 13, 2022 at 8:58 PM Yasuhiro Kimura <yasu@freebsd.org> wr=
ote:
From: Oleg =
Lelchuk <oleg=
lelchuk@gmail.com>

Subject: Re: Updating EFI boot loader results in boot hangup

Date: Sat, 13 Aug 2022 20:28:09 -0400



> I can already see that commit

> 

> c32dde3166922f55927764464d13f1bc9640f5f6=C2=A0causes breakage, but the=
 commit that precedes it

> 

> f197c0bf3e075286ccea32cd12023f3317474c5a=C2=A0doesn't cause breaka=
ge and the system boots just fine with it. But

> the error that the c32dd commit causes is different from the error tha=
t we see now, so maybe there is a

> possibility that one of the commits that follow it fixed the breakage,=
 but then yet another commit caused a

> different kind of breakage again.



With the command `git bisect start --first-parent 9d16275c65b a69c0964625 -=
- stand`

I got just same result.



---

Yasuhiro Kimura






--000000000000e013d705e629e315--

From nobody Sun Aug 14 02:08:50 2022
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 4M51746DDgz4YRMY
	for ; Sun, 14 Aug 2022 02:09:04 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M51745glVz3qBg;
	Sun, 14 Aug 2022 02:09:04 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660442944;
	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=qhpLqAnh2GeQyy4+G8dGLRNDFv4d1gOntczFgNkUsl4=;
	b=V7SLfc6yMYxf4cM3xJSkE6VWqNvaei3AHRTnvVoHzeXxI9PHExvhx3W7ny1VzmYNsRtynN
	wFODnhydqa/7dbc256njNrTOedSQDbXmGbHAubnQVckNVjRgtvyyiv0jwR1OQWnUQARtqb
	cU4HNly2Eow9cMXjZ1hn8MCThsz0aqoKGbGv7oAf2ja6qfT5rQEOkI76epCEeCa0F437tc
	/dVApVTT9rqbnS3FVrDsa8EkhzftiSiwrdX//0gTZc0OvA3bOGoxOs6UX/aDSUm5a5+2St
	VdUaqY5UTqNhG3l/RudMCyjcmgOW0sxCsvCdigWIqaVsy0996kNMbK2zm8Nb4Q==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:60c0:516d:769d:a3d2])
	(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: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M51740mWPzxYG;
	Sun, 14 Aug 2022 02:09:03 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Sun, 14 Aug 2022 11:08:50 +0900 (JST)
Message-Id: <20220814.110850.1703361053728529792.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura 
In-Reply-To: 
References: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
	
	
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660442944;
	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=qhpLqAnh2GeQyy4+G8dGLRNDFv4d1gOntczFgNkUsl4=;
	b=cCbB4fpeOh7AIIKxRusLsKPAmRmgApE7B+TqPOj4jsPNJlNFNIQQu8bpXV0F+ATWPKxOh3
	UuY8fyr7tQVHvWDS/4zZ8mr/OWNQLAkqjo275JySyf2eyMwZthEEZYrHGXp9fbZhSuh3Ks
	fw0oxkREdmJgGKY2GA4YFFmb2cVfE3q9UWtF9funSqK2sddZpW5d17PL01slUPvjOWuvJd
	TzVOjjjpXGt4u0GIx37tV5EDwsiU510SoDokdWuHCiJYKga9qy29DY1tb6S5csU5vEhwpe
	Wp8eJF6pd6/IgBh+auyRtAv6HlLWLmG5eJNWG6s/ofXfPsYvIm9xQDU8EE5QBw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660442944; a=rsa-sha256; cv=none;
	b=wK66VIeCCJKXPee5z3lvoYTbUqGG9FK5sw0h7H0oHN8eoxKvSfM3eq/1COzHJo2AH6lU0G
	eZNkf+h+vs52skEtZXZgOS1ueYLRpO23g7QmmN6l4EALSwyA3XLI/CtNkISkptyu9UO8fJ
	UhkU8uIdmvNJju+lRF/o9gMpn+Tum7osvWLJ3XVt+uEnKkRQ9js932Cw6DNGOSaMnGafiI
	u8JJjOON3GuA3KeYimoyJmsypB2qc1Oo9pqeuyuPGdfpUoujkw9spFvHRY73jMAxry4dLN
	Zftde8WqtB/OdLzxMeTVEaBQWbp/2C2ExGsiHX9xBE5StIQ3MZPxMLdTK3s8TA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

From: Warner Losh 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Sat, 13 Aug 2022 20:01:03 -0600

> UFS or ZFS?
> 
> Warner

ZFS in my case.

---
Yasuhiro Kimura

From nobody Sun Aug 14 02:20:15 2022
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 4M51ND5mHyz4YVRN
	for ; Sun, 14 Aug 2022 02:20:28 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M51ND0vBfz3sST;
	Sun, 14 Aug 2022 02:20:28 +0000 (UTC)
	(envelope-from oleglelchuk@gmail.com)
Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-328303afa6eso40913067b3.10;
        Sat, 13 Aug 2022 19:20:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=gm7vojB4kNbdSeNybolZ7goJIax9WMjAxh6KvAvFiXI=;
        b=gsP+cHuOe1WI42/JnVhNmTandOOb5lCTmYe2bxhMjwT+kDZZiJoe0iuGvruX2OiKUp
         tCTleDQp/obD05j8yGY+DZP+uX8q5czEpov74ylNFOf2FEDXRnVacQMXMsu8b2lW7TjF
         YUj1xx4TGvD1Aa+v2tMedKS7Kw6kY2zlbfYgm87TxbExP6lBaCXEBSqJdtFmDuMqvayw
         66k850uYd4dm3u+KQxUByGB4BnilGlsQ2UVPtolU22sY4nr1QPFHf/KfHfNgB6TMgrf+
         SYooZIHVFGrS3ipVx7EQz7qEWilX82bJJPpY4kNUGDoWJ787JKmiFoy+ZaD2/fwyLy2M
         Cfxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=gm7vojB4kNbdSeNybolZ7goJIax9WMjAxh6KvAvFiXI=;
        b=pP7cXGAyRHoBEyFMifhpzVBZX+Vq2hpLwsUzwnNjSibwYiUtiE/rtn+lgEPNgqhcDf
         1N+ASZs8G1ESaDDfOtexTkIvIl5j4Yk8Tj02P0G9g7oO8wbTb5tfw2uSmZ5OX2Dv5uGV
         WrE47ctrfIwzwcXFoMQlwV+JbmT2BKlFbltfs14Zf6nvxXlc3a/Gr4Wv43uN/i14Sc3O
         XYOLGSOldFTRbExiyFbI4gWynzxVjDTinV2AzgNpRUn/st1GU31hPanWOYgynbs3P/Wa
         sZJ/+I9IkND04lI2Q2rWvG9C+f8hvGyH1DaINoPWAng3+A5GWvEsWOPdoCD+Vx0emX/J
         5ihw==
X-Gm-Message-State: ACgBeo3aiisX++YnIVCJqfxjY6g/tG6b6mQ80ePIm0xLaDqFiwYH8f2c
	vK8+XDDDMCg+TUaX7Cs3Fhc10hVZaqpQa0TxXhasFUiIJjkDxA==
X-Google-Smtp-Source: AA6agR6fq7+op4hJgxuwFCq/dDG5S2XkSIQRn9GjXeHco7ntbNHbtZUKFWsECAXBNLvy8iclHMJxjWOJrhY07U78kgA=
X-Received: by 2002:a81:4989:0:b0:330:5a74:5565 with SMTP id
 w131-20020a814989000000b003305a745565mr995489ywa.33.1660443627270; Sat, 13
 Aug 2022 19:20:27 -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: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
 
  <20220814.110850.1703361053728529792.yasu@FreeBSD.org>
In-Reply-To: <20220814.110850.1703361053728529792.yasu@FreeBSD.org>
From: Oleg Lelchuk 
Date: Sat, 13 Aug 2022 22:20:15 -0400
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Yasuhiro Kimura 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000092b67605e62a28ce"
X-Rspamd-Queue-Id: 4M51ND0vBfz3sST
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=gsP+cHuO;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of oleglelchuk@gmail.com designates 2607:f8b0:4864:20::1136 as permitted sender) smtp.mailfrom=oleglelchuk@gmail.com
X-Spamd-Result: default: False [-3.86 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.995];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	NEURAL_HAM_MEDIUM(-0.88)[-0.878];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1136:from];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000092b67605e62a28ce
Content-Type: text/plain; charset="UTF-8"

Yes, Yasuhiro and I have the same error.

On Sat, Aug 13, 2022, 10:09 PM Yasuhiro Kimura  wrote:

> From: Warner Losh 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Sat, 13 Aug 2022 20:01:03 -0600
>
> > UFS or ZFS?
> >
> > Warner
>
> ZFS in my case.
>
> ---
> Yasuhiro Kimura
>
>

--00000000000092b67605e62a28ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yes, Yasuhiro and I have the same error.

On Sat, Aug 13, 2=
022, 10:09 PM Yasuhiro Kimura <yasu@=
freebsd.org> wrote:
From: Wa=
rner Losh <imp@bsdimp.com>

Subject: Re: Updating EFI boot loader results in boot hangup

Date: Sat, 13 Aug 2022 20:01:03 -0600



> UFS or ZFS?

> 

> Warner



ZFS in my case.



---

Yasuhiro Kimura






--00000000000092b67605e62a28ce--

From nobody Sun Aug 14 08:26:32 2022
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 4M59Vj1Gk6z4Zh6s
	for ; Sun, 14 Aug 2022 08:26:37 +0000 (UTC)
	(envelope-from se@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M59Vj0j85z3fhx;
	Sun, 14 Aug 2022 08:26:37 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660465597;
	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=KvADRUfdB6AFmXdwJsHX2qzbSaxfRIJwGuN2kzeNvhQ=;
	b=QWXxUoJ4nEE97DudABNpeIBrN5UKpRicMo263nGVxmSAvI9tfSuLqd3udrNeNXD3/xMPKY
	cyrp3zz3cTFDFWww/ZcYx0JzVVwONfJiAmQh6tfEeo5QH3l4SJLvdZabPsQxpLGPqPxJbh
	/ztFAniQVyYWuiycFpmDzgzR26Nf+SoJCy7q6DzQxfRoCltwXZASoJvFGjN4MS7sh22kxk
	8m2K+Tn2jL3pjbcVwIiaDwl9V6OhsrLBLe2S5JwhObatWRLtGJciwstZ7b6/6Tk/smvZSs
	iosTKcrtsEHTnihg4C2a1YWsJT8NpqCM8erqj2rmf+IuWbCIxDudCHDCS4vX+A==
Received: from [IPV6:2003:cd:5f1a:d200:7068:f43e:bfea:e34e] (p200300cd5f1ad2007068f43ebfeae34e.dip0.t-ipconnect.de [IPv6:2003:cd:5f1a:d200:7068:f43e:bfea:e34e])
	(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: se/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M59Vh2DD7z13v9;
	Sun, 14 Aug 2022 08:26:36 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
Message-ID: <45007308-136a-8938-33d0-bb2509ee6ae7@FreeBSD.org>
Date: Sun, 14 Aug 2022 10:26:32 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.1.2
Subject: Re: Updating EFI boot loader results in boot hangup
Content-Language: de-DE, en-US
To: freebsd-current@freebsd.org
Cc: Yasuhiro Kimura , Oleg Lelchuk 
References: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
 
 
 <20220814.110850.1703361053728529792.yasu@FreeBSD.org>
 
From: Stefan Esser 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660465597;
	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=KvADRUfdB6AFmXdwJsHX2qzbSaxfRIJwGuN2kzeNvhQ=;
	b=XE/bYd8dDM7APdW18pDMAvhh/bizs+qYB4wBpXE5l/pB3Iv9ZvPvk5DR2Lyq1BoC0XtSmM
	T8KGHChhCODn6vTVEAHwaYgVI3Dsk9psEwnIdyv1m9KIAf8NB6ONbSnlcjHyigSJeAtjUi
	Jx50CVoASkkTVY7G/oD5a5FYK0bYeh8EmXYZi6q3LPbhc2yxrmkb+hKfvXp5gFaCtB3poo
	oSI5nU4BzXCGcicfzLdkafAiFdcoYNaa5PUoVDyDhwzgaXgpObrUwDbFgWi1GGFjc+q1NC
	KxPmrph4Ev0At2VtnwzmQEeSc889Jg6GYgDMghaP4n7yUR/ulMU6WkLrgfc/fg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660465597; a=rsa-sha256; cv=none;
	b=QEhK/MCeq5+v8X3UlOIe6Ehv4SgBfPVZntltOZimvWt0ygrDTgErkZttoKwZwatmBXi/xY
	4WzuPonq34piwwy1b2tX7Axo9lS/gWQj4ziR5r7Zo7BGJtPOGGfNjrdqttsImfsPj225Xu
	oJ4hr6ghlw7/ToNVw2V38QE5NSovp0QbIN/kcnyRUNIf1xF1cyaGAxbS2yxHBiduK+K+nT
	kMDdrRt5wHm+F35/GFXXwfqFXb75ifKdFUXfDVqqcR5Rpy9eA7OCUEAmHFDagN7E5i6p7z
	FtZ/URya+wFpyVNQeoM2yfLmZUaDpEtYPBJnO9Q+KkTSTcAeOYU17yBbknSYPg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

Am 14.08.22 um 04:20 schrieb Oleg Lelchuk:
> Yes, Yasuhiro and I have the same error.

Just a "me too", also on ZFS, on a Ryzen 3 based system.

Booting the latest USB snapshot image worked, but not when I copy
the whole of /boot from that USB stick to my ZFS boot partition.

The system is usable if I boot from USB and manually mount the ZFS
file systems over the USB boot image.

Failed boot log:

	https://people.freebsd.org/~se/ZFS-Boot-Failure.jpg

But I doubt that it adds any new information ...

From nobody Sun Aug 14 08:49:22 2022
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 4M5B151TRdz4Zmds
	for ; Sun, 14 Aug 2022 08:49:29 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from pv50p00im-tydg10021701.me.com (pv50p00im-tydg10021701.me.com [17.58.6.54])
	(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 4M5B143fhfz3jh4
	for ; Sun, 14 Aug 2022 08:49:28 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1660466967; bh=+ceuctjUjpamZs4iWSex83L1US8xX0z1nYERsjDdENA=;
	h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To;
	b=l8MkHVq8iUMw4GVDZ6cGCZE2fvU68bI1X5ILAKsUIANopbsqsmtsEvJyEPcEfmgtz
	 vbHmW4JFuzeQqsgC0FETHQSoUG9uEljNJ4XYFUaFUK9+Xnlipo5eomqAx0v1fGbTRP
	 WS48sCHoluHsq/MVfpeMGNA9YS5s8N8/ZUNFljMMXuTZiv/Fbx/nEJzojVDAg1RwmQ
	 gVloNNh9+bavCkWGLzxhlGNCHqPP6nFD1TSU4fHReHH9o512FN502cU5pa9Qqpvtt/
	 cusKYocAXziiwADlVD1iWqQ7VZW6kIGdrqY+3r4cJjQy7+24hNxbNXcP3vo+mIZXvU
	 /qSmU9iVvbBMQ==
Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10])
	by pv50p00im-tydg10021701.me.com (Postfix) with ESMTPSA id 6DCDE3A1000;
	Sun, 14 Aug 2022 08:49:25 +0000 (UTC)
From: Toomas Soome 
Message-Id: <43B9F422-A4F1-42F0-A013-D914D9F5B6A7@me.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4648FA1D-D759-4FA4-83BA-113EF9BE9FF6"
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Sun, 14 Aug 2022 11:49:22 +0300
In-Reply-To: <45007308-136a-8938-33d0-bb2509ee6ae7@FreeBSD.org>
Cc: freebsd-current@freebsd.org,
 Yasuhiro Kimura ,
 Oleg Lelchuk 
To: Stefan Esser 
References: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
 
 
 <20220814.110850.1703361053728529792.yasu@FreeBSD.org>
 
 <45007308-136a-8938-33d0-bb2509ee6ae7@FreeBSD.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Proofpoint-GUID: DLbaDf59bwxgddaQkamRy9wlHn9D1kdH
X-Proofpoint-ORIG-GUID: DLbaDf59bwxgddaQkamRy9wlHn9D1kdH
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.517,18.0.883,17.11.64.514.0000000_definitions?=
 =?UTF-8?Q?=3D2022-06-21=5F08:2022-06-21=5F01,2022-06-21=5F08,2022-02-23?=
 =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 mlxscore=0
 malwarescore=0 adultscore=0 suspectscore=0 mlxlogscore=999 bulkscore=0
 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2206140000 definitions=main-2208140039
X-Rspamd-Queue-Id: 4M5B143fhfz3jh4
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=l8MkHVq8;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.54 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-2.60 / 15.00];
	URI_COUNT_ODD(1.00)[9];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16];
	R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.54:from];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEFALL_USER(0.00)[tsoome];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_CC(0.00)[freebsd.org,gmail.com];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DWL_DNSWL_NONE(0.00)[me.com:dkim];
	DKIM_TRACE(0.00)[me.com:+];
	FREEMAIL_FROM(0.00)[me.com];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[me.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_ALL(0.00)[];
	ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_4648FA1D-D759-4FA4-83BA-113EF9BE9FF6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

ok, yes, there is something bad happening:

=
https://paste.ec/paste/4p6Tf7Bl#yD6QIahJs1U1SRryaKUCqOHDdf5YDUfvB-wBvwAmhV=
4 =


second pointer is supposed to be pointer to device specific format =
function and on last visible line, it is clearly bad value there (BIOS =
loader code is below 1MB line).

will see how long it will take to find the root cause:D

rgds,
toomas

> On 14. Aug 2022, at 11:26, Stefan Esser  wrote:
>=20
> Am 14.08.22 um 04:20 schrieb Oleg Lelchuk:
>> Yes, Yasuhiro and I have the same error.
>=20
> Just a "me too", also on ZFS, on a Ryzen 3 based system.
>=20
> Booting the latest USB snapshot image worked, but not when I copy
> the whole of /boot from that USB stick to my ZFS boot partition.
>=20
> The system is usable if I boot from USB and manually mount the ZFS
> file systems over the USB boot image.
>=20
> Failed boot log:
>=20
> 	https://people.freebsd.org/~se/ZFS-Boot-Failure.jpg
>=20
> But I doubt that it adds any new information ...
>=20


--Apple-Mail=_4648FA1D-D759-4FA4-83BA-113EF9BE9FF6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

ok, =
yes, there is something bad happening:

https://paste.ec/paste/4p6Tf7Bl#yD6QIahJs1U1SRryaKUCqOHDdf5YDUf=
vB-wBvwAmhV4

second pointer is supposed to be pointer to device specific =
format function and on last visible line, it is clearly bad value there =
(BIOS loader code is below 1MB line).

will see how long it will take to find =
the root cause:D

rgds,
toomas

On 14. =
Aug 2022, at 11:26, Stefan Esser <se@FreeBSD.org> wrote:

Am =
14.08.22 um 04:20 schrieb Oleg Lelchuk:
Yes, Yasuhiro and I have the same error.

Just a "me too", also on ZFS, on =
a Ryzen 3 based system.

Booting the latest =
USB snapshot image worked, but not when I copy
the whole =
of /boot from that USB stick to my ZFS boot partition.

The system is usable if I boot from USB and manually mount =
the ZFS
file systems over the USB boot image.

Failed boot log:

	=
https://people.freebsd.org/~se/ZFS-Boot-Failure.jpg

But I doubt that it adds any new information =
...


=

--Apple-Mail=_4648FA1D-D759-4FA4-83BA-113EF9BE9FF6--

From nobody Sun Aug 14 13:47:43 2022
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 4M5Jl20w6sz4Z23M
	for ; Sun, 14 Aug 2022 13:52:46 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M5Jl20N53z3RQF
	for ; Sun, 14 Aug 2022 13:52:46 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660485166;
	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=qQ0Jwd5Z6haDb6AW59NVkJ82vSyTB5TQu7DYuaWk730=;
	b=VASFYrX3iLYGqkCrOYkOZgaKy4IoLriBmoZbg7R9Sllr7qvdeQH/cb9/WoHk22miUcG21K
	UbxQvJbT78WtnsNmXER14tP6vGjrXW62WeOnF/1s4m/qOpYk6MkqNsDIbzXJ1rr/8kwsGM
	iFLM0YTc36C1DFoYH3hbsDa+saFlUOO53h014kAs6kw1CBiwkYewUkm5XpVv9689x2lIUp
	ExbtvJiyM1uDaZEYnT7jHiPtSo90wLOOli3CPxKSboUwVJVYK0qZgbmpdXmIxGOyEOmbuO
	XVpnRzQX8tuPVHGesHY4dnrB7K9SqahHd8XuBZVZ6e/86R8gP9uCGzaKu2axfg==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M5Jl15Lblz18Bw
	for ; Sun, 14 Aug 2022 13:52:45 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Content-Type: multipart/alternative;
 boundary="------------3vjqSjgbTV4NgX322ToOFpHj"
Message-ID: <029d861e-7a30-296b-669d-5496eb120110@freebsd.org>
Date: Sun, 14 Aug 2022 14:47:43 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
From: Graham Perrin 
Subject: bootx64.efi; and loader.efi in the FreeBSD reserved area (was:
 Updating EFI boot loader results in boot hangup)
Organization: FreeBSD
In-Reply-To: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660485166;
	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=qQ0Jwd5Z6haDb6AW59NVkJ82vSyTB5TQu7DYuaWk730=;
	b=uLWorIcJcNMTW2o/KkBIMrjgTe3Fa34XwMnatI128NR5efBC9F4NDeKDi/PNjbT9Pjo97s
	QGq6O2TYKdazZhTx0MekxRyXKQgYhVrK6AuC7D9huF1IxWqi/SwTvN2qrt3qSV8uoGD91a
	rjFQCw/Ycsauxw1LTOoqGbgIgA0D4OZ3jzFBBy1c3SDJ5j9/rsC5BO0qZQBM/X4uSlRWWT
	NmtByPiTI9JRkWkcgqy0x6B5gyuIF+RtLp6bPEPjd5vFKZDuE5SLAAhXmeVqoS7lLrc+Jz
	bHHhnwtrU17y2XklLlCDYrktJ6+EBGy5EYhm3pClFuJoh3IeVTJroS81aSEx5Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660485166; a=rsa-sha256; cv=none;
	b=k8WEDHaoELL5aKUjLX2q15XblCF9oqC0NYhY0NZhVkmrDm9KVaOqsyq0+lljdBxJg/+37L
	OcK2mA7xSDpCDzs8U3JgA46lBitzx2laGs0m7wvv5+ECpH0bzDRmwUOE2EfKbRDAH1NqMH
	cUJVaT+WaD/EhsFSC1Lxfp7QmviTjkLVP3EFOtF+CHsC8SGJYMxZsa2ouj1fVyCSEqMqCz
	QDXwfUr9JmHg5lpIwmHu15ZULkPLU5rIFzOZNIIG8tflqfX2vdoIp+gMrDEh9e27k7Zfpw
	7ecSMC7F/IgQl8PgURKhK17WXl1Un5hL2qd7oRnsFgUjsbjJHVfoZ37NgKTDcg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------3vjqSjgbTV4NgX322ToOFpHj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 12/08/2022 17:54, Yasuhiro Kimura wrote:

> … amd64 … (/boot/efi/efi/freebsd/loader.efi) …

Side note: please, why the FreeBSD reserved area?

I'm more familiar with /efi/boot/bootx64.efi for amd64.



--------------3vjqSjgbTV4NgX322ToOFpHj
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 12/08/2022 17:54, Yasuhiro Kimura wrote:

    

    

      
… amd64 … (/boot/efi/efi/freebsd/loader.efi) …

    

    
Side note: please, why the FreeBSD reserved area? 

    

    
I'm more familiar with /efi/boot/bootx64.efi for amd64. 

    
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255318#c11>

    

  
  


--------------3vjqSjgbTV4NgX322ToOFpHj--

From nobody Sun Aug 14 19:26:09 2022
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 4M5S7w3QTpz4Yv5v
	for ; Sun, 14 Aug 2022 19:26:20 +0000 (UTC)
	(envelope-from pete@nomadlogic.org)
Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226])
	(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 "mail.nomadlogic.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M5S7v3Kc8z3KQx;
	Sun, 14 Aug 2022 19:26:19 +0000 (UTC)
	(envelope-from pete@nomadlogic.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org;
	s=04242021; t=1660505171;
	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=6ZOnDNrEFK1esAAI2D/EVWLIvmX3NQktvR1ln53ft00=;
	b=1mfEb+4V+w1slIQKOFrQyaGZzy13mIAl6oLza+xph/JIxMmp9D4nMLLmZhhSvDiezRzckv
	uaHKB2s/E7WC4sG7Zs8BSrFS/7roSYJDXZqqNQgUF/WqMp/w6uUe1SBuzMi9h6I9T10GTf
	IEw2OtjXYni73dElxeEcu9IZ+fmLLSU=
Received: from colony.nomadlogic.org (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214])
	by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id aebf944c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Sun, 14 Aug 2022 19:26:10 +0000 (UTC)
Date: Sun, 14 Aug 2022 12:26:09 -0700
From: Pete Wright 
To: Stefan Esser 
Cc: freebsd-current@freebsd.org, Yasuhiro Kimura ,
	Oleg Lelchuk 
Subject: Re: Updating EFI boot loader results in boot hangup
Message-ID: <20220814192609.wyfcogl3dwzteuva@colony.nomadlogic.org>
References: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
 
 
 <20220814.110850.1703361053728529792.yasu@FreeBSD.org>
 
 <45007308-136a-8938-33d0-bb2509ee6ae7@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: <45007308-136a-8938-33d0-bb2509ee6ae7@FreeBSD.org>
X-Rspamd-Queue-Id: 4M5S7v3Kc8z3KQx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=1mfEb+4V;
	dmarc=pass (policy=quarantine) header.from=nomadlogic.org;
	spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_CC(0.00)[freebsd.org,gmail.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[nomadlogic.org:+];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Aug 14, 2022 at 10:26:32AM +0200, Stefan Esser wrote:
> Am 14.08.22 um 04:20 schrieb Oleg Lelchuk:
> > Yes, Yasuhiro and I have the same error.
> 
> Just a "me too", also on ZFS, on a Ryzen 3 based system.
> 
> Booting the latest USB snapshot image worked, but not when I copy
> the whole of /boot from that USB stick to my ZFS boot partition.
> 
> The system is usable if I boot from USB and manually mount the ZFS
> file systems over the USB boot image.
>

adding my voice to the chorus here of "me too". ryzen5/uefi/zfs setup.

has anyone else who has been impacted by this been able to recover?  i
can boot into a memstick image, and access my uefi shell via the bios -
but i've never had to hack on btx like this before.

any links or pointers would be appreciated!

-pete

-- 
Pete Wright
pete@nomadlogic.org

From nobody Sun Aug 14 19:57:05 2022
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 4M5Sqf0jmlz4Z2r9
	for ; Sun, 14 Aug 2022 19:57:18 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M5Sqd2pR0z3V7f
	for ; Sun, 14 Aug 2022 19:57:17 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x933.google.com with SMTP id 5so2224787uay.5
        for ; Sun, 14 Aug 2022 12:57:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=0HWI2hp9h+SI1P4zL43ImzK1/E+eKMJbSd1aqXOxYeY=;
        b=Rjcbb9QQGOKP/SdU74fybNH/2PXUi/N52Gg69j0eZbj+uoofX3WG7iFudRkzFhZAzc
         b0nP246S3KB/zDkxidFyHZNQETZEtd0XJTXoLGXe7TD2YV5nmF0l3BSAFITfEj2apimL
         3DqXQ3frA0vjxPrG1hbAB/fgmDVy6hgFqVLzA6r9j7I94qn9iJH0fbJmmn8e9y4xf1/I
         phG9NEwHLUMg4Nh/P7iwK7pF3S39me3guj4O4Q+EtkalO9lWgisELVaI7LHb7/94VqoH
         PCVN095zKCXIqOXksyq6kWA2RLYZE6uLAa8HGX4KRYq+PiorUpdxc33Jqj2elnk4RiL9
         SYWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=0HWI2hp9h+SI1P4zL43ImzK1/E+eKMJbSd1aqXOxYeY=;
        b=DW3JT3fGiXM99csOVBIw6SOrxx263+sWyPfkI9sZ3T7SmqgRUOo+zjUoZREWPvljzG
         p/d6Q90Zaf4GnoMD8CseTVH8dJeZ1Bpi+LEBTdo8RsjXiXmOyD7I+iJQbTFAR2q6jN29
         UM4xdXv7fixapRyOEwcYHBe8ITVCfyJxk3aN4IgkXMejCiQJCj7I8w3wONq76dYbOEVo
         Ph3vIO9CEw16qTXuJvo/dqCJa/vaW7OB4r42x7w2CQpS+6vCcBvosFuonkjPv9CABEB/
         VJi7McyWw42zXSVLiskMMTihYqcBBOGi4s5+4q7bHzJM98aoawii5k9vPaz5IqOVzEHg
         iIUQ==
X-Gm-Message-State: ACgBeo0Z6wybjgBhjvGMA00EcmFBcA8rCgvUewbEXJp+ebPOE9ydJsn9
	sWTGIB2KwQz4JHxQXkTqTu1SLZXts6ZBhTNrT3bhvg==
X-Google-Smtp-Source: AA6agR6+dki/wYMP06q5eyagyYtzmFzkmu3G00xWxeIK2cif8qVUo/qDMDbNeZjI/XieUurdHbRh3lMDZec3nzzLmvQ=
X-Received: by 2002:a9f:2067:0:b0:387:984d:4a8e with SMTP id
 94-20020a9f2067000000b00387984d4a8emr5176562uam.60.1660507036564; Sun, 14 Aug
 2022 12:57:16 -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: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
 
 
 <20220814.110850.1703361053728529792.yasu@FreeBSD.org> 
 <45007308-136a-8938-33d0-bb2509ee6ae7@FreeBSD.org> <20220814192609.wyfcogl3dwzteuva@colony.nomadlogic.org>
In-Reply-To: <20220814192609.wyfcogl3dwzteuva@colony.nomadlogic.org>
From: Warner Losh 
Date: Sun, 14 Aug 2022 13:57:05 -0600
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Pete Wright 
Cc: Stefan Esser , FreeBSD Current , 
	Yasuhiro Kimura , Oleg Lelchuk 
Content-Type: multipart/alternative; boundary="0000000000000fd23405e638ec97"
X-Rspamd-Queue-Id: 4M5Sqd2pR0z3V7f
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Rjcbb9QQ;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::933) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::933:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_FIVE(0.00)[5];
	DMARC_NA(0.00)[bsdimp.com];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[freebsd.org,gmail.com]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000000fd23405e638ec97
Content-Type: text/plain; charset="UTF-8"

On Sun, Aug 14, 2022 at 1:26 PM Pete Wright  wrote:

> On Sun, Aug 14, 2022 at 10:26:32AM +0200, Stefan Esser wrote:
> > Am 14.08.22 um 04:20 schrieb Oleg Lelchuk:
> > > Yes, Yasuhiro and I have the same error.
> >
> > Just a "me too", also on ZFS, on a Ryzen 3 based system.
> >
> > Booting the latest USB snapshot image worked, but not when I copy
> > the whole of /boot from that USB stick to my ZFS boot partition.
> >
> > The system is usable if I boot from USB and manually mount the ZFS
> > file systems over the USB boot image.
> >
>
> adding my voice to the chorus here of "me too". ryzen5/uefi/zfs setup.
>
> has anyone else who has been impacted by this been able to recover?  i
> can boot into a memstick image, and access my uefi shell via the bios -
> but i've never had to hack on btx like this before.
>
> any links or pointers would be appreciated!
>

I think I broke it with my latest updates. I don't have a good ZFS testing
setup
so I'm spending a little time enhancing the bootable image generator to have
one that I can easily test boot with qemu.

Warner

--0000000000000fd23405e638ec97
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Aug 14, 2022 at 1:26 PM Pete =
Wright <pete@nomadlogic.org&g=
t; wrote:
On Sun=
, Aug 14, 2022 at 10:26:32AM +0200, Stefan Esser wrote:

> Am 14.08.22 um 04:20 schrieb Oleg Lelchuk:

> > Yes, Yasuhiro and I have the same error.

> 

> Just a "me too", also on ZFS, on a Ryzen 3 based system.

> 

> Booting the latest USB snapshot image worked, but not when I copy

> the whole of /boot from that USB stick to my ZFS boot partition.

> 

> The system is usable if I boot from USB and manually mount the ZFS

> file systems over the USB boot image.

>



adding my voice to the chorus here of "me too". ryzen5/uefi/zfs s=
etup.



has anyone else who has been impacted by this been able to recover?=C2=A0 i=


can boot into a memstick image, and access my uefi shell via the bios -

but i've never had to hack on btx like this before.



any links or pointers would be appreciated!

=

I think I broke it with my latest updates. I don't have a good ZFS=
 testing setup
so I'm spending a little time enhancing the bo=
otable image generator to have
one that I can easily test boot wi=
th qemu.

Warner=C2=A0


--0000000000000fd23405e638ec97--

From nobody Sun Aug 14 20:08:36 2022
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 4M5T4m0yxCz4Z5Lh
	for ; Sun, 14 Aug 2022 20:08:40 +0000 (UTC)
	(envelope-from schweikh@schweikhardt.net)
Received: from ikarus.efm.de (ikarus.efm.de [195.190.148.243])
	(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 4M5T4l3FmQz3WyN
	for ; Sun, 14 Aug 2022 20:08:39 +0000 (UTC)
	(envelope-from schweikh@schweikhardt.net)
Received: from ikarus.efm.de (localhost [127.0.0.1])
	by ikarus.efm.de (Postfix) with ESMTPS id F1EB029C0FDC
	for ; Sun, 14 Aug 2022 22:08:36 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by ikarus.efm.de (Postfix) with ESMTP id E34F029C0FF9
	for ; Sun, 14 Aug 2022 22:08:36 +0200 (CEST)
Received: from ikarus.efm.de ([127.0.0.1])
	by localhost (ikarus.efm.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id pNcNFH5ychFO for ;
	Sun, 14 Aug 2022 22:08:36 +0200 (CEST)
Received: from ikarus.efm.de (ikarus.efm.de [195.190.148.243])
	by ikarus.efm.de (Postfix) with ESMTP id B291A29C0FDC
	for ; Sun, 14 Aug 2022 22:08:36 +0200 (CEST)
Date: Sun, 14 Aug 2022 22:08:36 +0200 (CEST)
From: Jens Schweikhardt 
To: freebsd-current 
Message-ID: <1051887847.9072652.1660507716695.JavaMail.zimbra@schweikhardt.net>
Subject: bootstrap loader crashes, BTX halted
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: 7bit
X-Mailer: Zimbra 8.8.15_GA_4272 (ZimbraWebClient - FF102 (Win)/8.8.15_GA_4257)
Thread-Index: NRBy5W6Ikn8x4IzVgywU8dELslw6XQ==
Thread-Topic: bootstrap loader crashes, BTX halted
X-Rspamd-Queue-Id: 4M5T4l3FmQz3WyN
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of schweikh@schweikhardt.net has no SPF policy when checking 195.190.148.243) smtp.mailfrom=schweikh@schweikhardt.net
X-Spamd-Result: default: False [-2.50 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	RCVD_IN_DNSWL_MED(-0.40)[195.190.148.243:received,195.190.148.243:from];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:25411, ipnet:195.190.148.0/24, country:DE];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[schweikh];
	RCVD_COUNT_FIVE(0.00)[5];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[schweikhardt.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I just installed the latest current on a gpt zfs system and it crashes early
with (manually transferred from photo taken):

Consoles: internal video/keyboard
BIOS drive C: is disk0
BIOS 634kB/3090148kB available memory

FreeBSD/x86 bootstrap loader, Revision 1.1
int=0000000d  err=0000b844  efl=00010286  eip=b1448214.net)
eax=fd0fbd59  ebx=000761b4  ecx=bad40cf0  edx=6f6f7230
esi=bad40880  edi=00000002  ebp=0009332b  esp=00092ec8
cs=002b  ds=0033  es=0033    fs=0033  gs=0033  ss=0033
cs:eip=07 03 03 03 00 00 00 00-00 00 00 00 00 00 00 00
       00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
ss:esp=45 b8 03 00 f0 0c d4 bs-00 00 00 00 00 00 00 00
       00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
BTX halted


Is that related to recent loader crash reports?
How can I recover?

Regards,

        Jens
-- 
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

From nobody Sun Aug 14 20:12:44 2022
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 4M5T9Z0sDYz4Z6YM
	for ; Sun, 14 Aug 2022 20:12:50 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from pv50p00im-zteg10021301.me.com (pv50p00im-zteg10021301.me.com [17.58.6.46])
	(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 4M5T9Y2SPZz3YFm
	for ; Sun, 14 Aug 2022 20:12:49 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1660507968; bh=w4QvY74bnczWXCSG9XDeiqL+emEPxS3quqIrwru3Sg4=;
	h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To;
	b=D92NmZzqvuYUaRFbAjZXNypyuGYG4TaFXqFdq2D9yGqbwlgMP5olX+Qf08OChLS1y
	 0GFvzYbY3o9IGv2RIaSmomGXFEWQNDWg+Djc1PjK5jXEa3Nf+v9ST+A3Fj9DEtkndT
	 rmcwpqApNotWHDjQw1INw4d1V1p3LKWn4ffsk2sOEAS+8FyFe+THmQy7BtR9EEVnHI
	 dRkHUrFyj8voqFeENQYVM2XVRZot4nTtu4/W15hgEg7F3k/Rbpq4BUboxJbMDhn+iX
	 6WlWiL4dg33sNmYWjaNYiLrF4WRs8PGb9w2Hd3UyqHX4Y2e3dX8wriOZGKNVTFXjCq
	 yyq/1tu51JZLg==
Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10])
	by pv50p00im-zteg10021301.me.com (Postfix) with ESMTPSA id 8E4EC5001DE;
	Sun, 14 Aug 2022 20:12:46 +0000 (UTC)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: bootstrap loader crashes, BTX halted
From: Toomas Soome 
In-Reply-To: <1051887847.9072652.1660507716695.JavaMail.zimbra@schweikhardt.net>
Date: Sun, 14 Aug 2022 23:12:44 +0300
Cc: freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: <81C3E3A6-8024-449B-8567-0D21677BE155@me.com>
References: <1051887847.9072652.1660507716695.JavaMail.zimbra@schweikhardt.net>
To: Jens Schweikhardt 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Proofpoint-ORIG-GUID: GJqt6B-QPEmeBtQYv30GhgTbIriy_0Yv
X-Proofpoint-GUID: GJqt6B-QPEmeBtQYv30GhgTbIriy_0Yv
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.572,17.11.64.514.0000000_definitions?=
 =?UTF-8?Q?=3D2020-02-14=5F11:2020-02-14=5F02,2020-02-14=5F11,2022-02-23?=
 =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=848 spamscore=0 bulkscore=0
 mlxscore=0 phishscore=0 suspectscore=0 malwarescore=0 adultscore=0
 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2206140000 definitions=main-2208140089
X-Rspamd-Queue-Id: 4M5T9Y2SPZz3YFm
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=D92NmZzq;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.46 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-3.60 / 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)[me.com,quarantine];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16];
	R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.46:from];
	MIME_GOOD(-0.10)[text/plain];
	FREEFALL_USER(0.00)[tsoome];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[17.58.6.46:from];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[me.com:+];
	TO_DN_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[me.com];
	DWL_DNSWL_NONE(0.00)[me.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[me.com];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 14. Aug 2022, at 23:08, Jens Schweikhardt =
 wrote:
>=20
> I just installed the latest current on a gpt zfs system and it crashes =
early
> with (manually transferred from photo taken):
>=20
> Consoles: internal video/keyboard
> BIOS drive C: is disk0
> BIOS 634kB/3090148kB available memory
>=20
> FreeBSD/x86 bootstrap loader, Revision 1.1
> int=3D0000000d  err=3D0000b844  efl=3D00010286  eip=3Db1448214.net)
> eax=3Dfd0fbd59  ebx=3D000761b4  ecx=3Dbad40cf0  edx=3D6f6f7230
> esi=3Dbad40880  edi=3D00000002  ebp=3D0009332b  esp=3D00092ec8
> cs=3D002b  ds=3D0033  es=3D0033    fs=3D0033  gs=3D0033  ss=3D0033
> cs:eip=3D07 03 03 03 00 00 00 00-00 00 00 00 00 00 00 00
>       00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
> ss:esp=3D45 b8 03 00 f0 0c d4 bs-00 00 00 00 00 00 00 00
>       00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
> BTX halted
>=20
>=20
> Is that related to recent loader crash reports?

Yes.

> How can I recover?
>=20

If you have older BE, press space on first spinner to get boot: prompt =
and enter zfs:zroot/=E2=80=A6/bename:

Or use a bit older boot stick/cd and copy /boot/loader from there.


PS: working on a fix atm.

rgds,
toomas

> Regards,
>=20
>        Jens
> --=20
> Jens Schweikhardt http://www.schweikhardt.net/
> SIGSIG -- signature too long (core dumped)
>=20


From nobody Sun Aug 14 20:26:33 2022
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 4M5TbG4ZGrz4Z9sQ
	for ; Sun, 14 Aug 2022 20:31:38 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M5TbG1k2bz3bxw
	for ; Sun, 14 Aug 2022 20:31:38 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: by mail-ed1-x52e.google.com with SMTP id b96so7439328edf.0
        for ; Sun, 14 Aug 2022 13:31:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=in-reply-to:from:references:to:content-language:subject:user-agent
         :mime-version:date:message-id:from:to:cc;
        bh=QgUsm2OnZDhXPO35x6rYRGOLJnscLzJlzm61yFAWATc=;
        b=ZDxZCfhnM6zQPZ1L/I/QGkjDRt+S+j2C6BAlhmKErX1/YsqAUajoUh4xgdURzawgWZ
         xTjhEi2eJ76m+/clErbjwu+LUbdZys3puOYzNP9NjKWTAGYsVplvI3/L9cyhBNSeGDmn
         Hwb3HT5wJN9zs2jTkYZB1WJOPMoFGzhISHcNh17NNE4OH0/M5k4xQ5OwIUXlJsbP9S3r
         wjYjikS8TJGtessPAOQ6Sfk0c/ucX8MeqIoCdYirIcE0YDq3ob2yg/5hmg+taZFO0wlB
         P0BB84cR5VDWRIRBp47287VNl0iODmrXlUsG5fxxVS3Ciz2gDY2bH2/jjoyPKOUNDW2t
         zcFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=in-reply-to:from:references:to:content-language:subject:user-agent
         :mime-version:date:message-id:x-gm-message-state:from:to:cc;
        bh=QgUsm2OnZDhXPO35x6rYRGOLJnscLzJlzm61yFAWATc=;
        b=S3bFiCR/9ZrC5Z7H0i0VdmGqNWiJ5iyjx7oB9FCJUfMAN5z2JrM6v3SK4dk1b0Cihu
         QNhlX1yJEd7JK/FJ97bTXeGv8dXLoQprqeZuwFv+MTDW3waaQ6HA7h1u80DnM/7VKc/V
         otDrITiAsb/S1GU9qIzZV8rRzM0iCaMy4htH4rHtBf6iLSd67xdPUTTa+tRQwNhFuTDy
         UMUkmgNnvs/cMVhjg842ePRGPS491V6QouDDRae5qHXhORE+p9FYx2a+lUdx+EwuiI65
         OTk1X+9Ox6c617ZFys17sKyjGrN0YqGi2+r5HH9jbic3PE5Wt6SKf85wijh0epXuo1Ds
         fgBQ==
X-Gm-Message-State: ACgBeo1J+yG1Oo59L8kOqUi+qeFARrzHfauLUoQPWcZfKbISuY7WWKQH
	ewb7Pxlix1VWbvhfxzREUjkmXRZd1F07pA==
X-Google-Smtp-Source: AA6agR6oeQvGo4nNXkDYzAoxVVtMhqMu1Azhv0OhH9hMrQp7Xw+w0oIkFEhc3H2/5a1xjpq08GRyAg==
X-Received: by 2002:a05:6402:100e:b0:440:785c:20c9 with SMTP id c14-20020a056402100e00b00440785c20c9mr11674228edu.184.1660509097000;
        Sun, 14 Aug 2022 13:31:37 -0700 (PDT)
Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2])
        by smtp.gmail.com with ESMTPSA id p3-20020a170906a00300b00732e3d94f4fsm3237256ejy.124.2022.08.14.13.31.35
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 14 Aug 2022 13:31:35 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------yUS6vA22a0xzFF2Ey8Ui00DR"
Message-ID: <77a7f41c-b060-8582-f19f-345c33043750@gmail.com>
Date: Sun, 14 Aug 2022 21:26:33 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: Updating EFI boot loader results in boot hangup
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
 
 
 <20220814.110850.1703361053728529792.yasu@FreeBSD.org>
 
 <45007308-136a-8938-33d0-bb2509ee6ae7@FreeBSD.org>
 <20220814192609.wyfcogl3dwzteuva@colony.nomadlogic.org>
From: Graham Perrin 
In-Reply-To: <20220814192609.wyfcogl3dwzteuva@colony.nomadlogic.org>
X-Rspamd-Queue-Id: 4M5TbG1k2bz3bxw
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=ZDxZCfhn;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::52e as permitted sender) smtp.mailfrom=grahamperrin@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.99)[-0.987];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEFALL_USER(0.00)[grahamperrin];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52e:from];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------yUS6vA22a0xzFF2Ey8Ui00DR
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 14/08/2022 20:26, Pete Wright wrote:
> … has anyone else who has been impacted by this been able to recover? …
If you have multiple boot environments: do you have a non-affected BE 
(prior to c32dde3166922f55927764464d13f1bc9640f5f6)?
--------------yUS6vA22a0xzFF2Ey8Ui00DR
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 14/08/2022 20:26, Pete Wright wrote:

    

    

      
… has anyone else who has been impacted by this been able to recover? …

    

    If you have multiple boot environments: do you have a non-affected
    BE (prior to c32dde3166922f55927764464d13f1bc9640f5f6)?

  
  


--------------yUS6vA22a0xzFF2Ey8Ui00DR--

From nobody Sun Aug 14 21:16:36 2022
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 4M5VbP4HRJz4ZMkY
	for ; Sun, 14 Aug 2022 21:16:49 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M5VbN46ssz3nJs
	for ; Sun, 14 Aug 2022 21:16:48 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe2e.google.com with SMTP id q190so5662376vsb.7
        for ; Sun, 14 Aug 2022 14:16:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=/vJt1SjRBQnELa+xwkLE8SdDxp0dn1i2DzPMrcu6bBU=;
        b=AZSEIqTZzYyaKzj0HSZ+F43wQDPcSPhO0stbKwORqaTh9WamSW87vk9ABM9xkL9p9o
         tCBo2OurM4pkBS70/S3jX2OFRkEwa+AnLiQbtX4AQYCFB0jqdOsejphVG49wbZvFXkHn
         vOoxL5Ig1V3GsIw/kec77bjkqO9K71JPXKXZKDaP5mMXufrMA0xOUJTQxQQljUAjORka
         sQ1HF+RWXEsH51bbLE/JQThNj3SVrDS2LEuN5F3/lSOsD3RFCW42Q6oGNn31Jqdv3Jz1
         DFiTmWgBADO/5+DTQ61YoVXOQxknR+UsfgxKEE+IKr1HgM7357YCYpVuYfPVtpsVAVpJ
         O3jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=/vJt1SjRBQnELa+xwkLE8SdDxp0dn1i2DzPMrcu6bBU=;
        b=Lbb9culRPN0aTA785URfGvr1wR1h/W7I/kKMfCBvT5NvPk22NBEHsujsvLfAwf9mXo
         A1ZNtcO819LCooN+/FBSJGtD+5BLhkTolSdhrM4WK0nsPTlZZ27rYOeBoMxsfokhJ4m2
         IwpdbWBT2pJqHm1FEW8OfKAX+RXcVCpbsL6UcBR3Js+GQe7JubTWaFCrUJ/Y7DCcCnWR
         amJXmMmaqj+zHA8cr0jfZ8t8JB6X+wEfelKwuRURxQOooELg3pJaoDYSz8GnaTKkAOBW
         mW8ClitnsR0PxuG6wxPrICRM6tZL0Yiqgx7veXt80DvwJVmwjqlc6miUfxxP0r877Q+i
         WDEw==
X-Gm-Message-State: ACgBeo0CqSvOTc+h5Q1Qy8D5mAtasjwt3dEqANnR86ndugfqyDY9Mt78
	5V4QPJnemFO8jo1Ly0xrVh32angBsa58q6wyuaF+0Q==
X-Google-Smtp-Source: AA6agR5U5jjGldCwyd9LbzQftO0NH/JMVTPuhU7197mf81GEUT/YZ+SSLAUcy7eefn6hB2DUSPPKHsxIyw19tk0w50w=
X-Received: by 2002:a67:b208:0:b0:357:e999:441c with SMTP id
 b8-20020a67b208000000b00357e999441cmr4909591vsf.67.1660511807753; Sun, 14 Aug
 2022 14:16:47 -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: <1051887847.9072652.1660507716695.JavaMail.zimbra@schweikhardt.net>
 <81C3E3A6-8024-449B-8567-0D21677BE155@me.com>
In-Reply-To: <81C3E3A6-8024-449B-8567-0D21677BE155@me.com>
From: Warner Losh 
Date: Sun, 14 Aug 2022 15:16:36 -0600
Message-ID: 
Subject: Re: bootstrap loader crashes, BTX halted
To: Toomas Soome 
Cc: Jens Schweikhardt , 
	freebsd-current 
Content-Type: multipart/alternative; boundary="00000000000072676505e63a08fd"
X-Rspamd-Queue-Id: 4M5VbN46ssz3nJs
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=AZSEIqTZ;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2e) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[me.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2e:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000072676505e63a08fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 14, 2022, 2:12 PM Toomas Soome  wrote:

>
>
> > On 14. Aug 2022, at 23:08, Jens Schweikhardt 
> wrote:
> >
> > I just installed the latest current on a gpt zfs system and it crashes
> early
> > with (manually transferred from photo taken):
> >
> > Consoles: internal video/keyboard
> > BIOS drive C: is disk0
> > BIOS 634kB/3090148kB available memory
> >
> > FreeBSD/x86 bootstrap loader, Revision 1.1
> > int=3D0000000d  err=3D0000b844  efl=3D00010286  eip=3Db1448214.net)
> > eax=3Dfd0fbd59  ebx=3D000761b4  ecx=3Dbad40cf0  edx=3D6f6f7230
> > esi=3Dbad40880  edi=3D00000002  ebp=3D0009332b  esp=3D00092ec8
> > cs=3D002b  ds=3D0033  es=3D0033    fs=3D0033  gs=3D0033  ss=3D0033
> > cs:eip=3D07 03 03 03 00 00 00 00-00 00 00 00 00 00 00 00
> >       00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
> > ss:esp=3D45 b8 03 00 f0 0c d4 bs-00 00 00 00 00 00 00 00
> >       00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
> > BTX halted
> >
> >
> > Is that related to recent loader crash reports?
>
> Yes.
>
> > How can I recover?
> >
>
> If you have older BE, press space on first spinner to get boot: prompt an=
d
> enter zfs:zroot/=E2=80=A6/bename:
>
> Or use a bit older boot stick/cd and copy /boot/loader from there.
>
>
> PS: working on a fix atm.
>

Me too... I think I know what caused this...

Warner

rgds,
> toomas
>
> > Regards,
> >
> >        Jens
> > --
> > Jens Schweikhardt http://www.schweikhardt.net/
> > SIGSIG -- signature too long (core dumped)
> >
>
>
>

--00000000000072676505e63a08fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sun, Aug 14, 2022, 2:12 PM Toomas Soome <tsoome@me.com> wrote:




> On 14. Aug 2022, at 23:08, Jens Schweikhardt <schweikh@schwe=
ikhardt.net> wrote:

> 

> I just installed the latest current on a gpt zfs system and it crashes=
 early

> with (manually transferred from photo taken):

> 

> Consoles: internal video/keyboard

> BIOS drive C: is disk0

> BIOS 634kB/3090148kB available memory

> 

> FreeBSD/x86 bootstrap loader, Revision 1.1

> int=3D0000000d=C2=A0 err=3D0000b844=C2=A0 efl=3D00010286=C2=A0 eip=3D<=
a href=3D"http://b1448214.net" rel=3D"noreferrer noreferrer" target=3D"_bla=
nk">b1448214.net)

> eax=3Dfd0fbd59=C2=A0 ebx=3D000761b4=C2=A0 ecx=3Dbad40cf0=C2=A0 edx=3D6=
f6f7230

> esi=3Dbad40880=C2=A0 edi=3D00000002=C2=A0 ebp=3D0009332b=C2=A0 esp=3D0=
0092ec8

> cs=3D002b=C2=A0 ds=3D0033=C2=A0 es=3D0033=C2=A0 =C2=A0 fs=3D0033=C2=A0=
 gs=3D0033=C2=A0 ss=3D0033

> cs:eip=3D07 03 03 03 00 00 00 00-00 00 00 00 00 00 00 00

>=C2=A0 =C2=A0 =C2=A0 =C2=A000 00 00 00 00 00 00 00-00 00 00 00 00 00 00=
 00

> ss:esp=3D45 b8 03 00 f0 0c d4 bs-00 00 00 00 00 00 00 00

>=C2=A0 =C2=A0 =C2=A0 =C2=A000 00 00 00 00 00 00 00-00 00 00 00 00 00 00=
 00

> BTX halted

> 

> 

> Is that related to recent loader crash reports?



Yes.



> How can I recover?

> 



If you have older BE, press space on first spinner to get boot: prompt and =
enter zfs:zroot/=E2=80=A6/bename:



Or use a bit older boot stick/cd and copy /boot/loader from there.





PS: working on a fix atm.
Me too... I think I know what caused this...
=


Warner=C2=A0


rgds,

toomas



> Regards,

> 

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jens

> -- 

> Jens Schweikhardt http://www.schweikhardt.net/

> SIGSIG -- signature too long (core dumped)

> 








--00000000000072676505e63a08fd--

From nobody Sun Aug 14 21:58:10 2022
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 4M5WW91VqQz4YZCw
	for ; Sun, 14 Aug 2022 21:58:13 +0000 (UTC)
	(envelope-from pete@nomadlogic.org)
Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226])
	(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 "mail.nomadlogic.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M5WW81JHDz3tdx
	for ; Sun, 14 Aug 2022 21:58:12 +0000 (UTC)
	(envelope-from pete@nomadlogic.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org;
	s=04242021; t=1660514290;
	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=RH9C0m/4+63KLrozD8KgEcmWKpZ97jQOBGOf0pgkx98=;
	b=5MOU74AvQOYzf+Re/n7xmt4RI0N5THsNASetR6XQBvJyws33DkDuvX2U3Y1Of3J3L/DbHb
	cHl5B5lOKV3XIpKHpygUA6iXSaZgHl8Lkc9L+XmijxU9NnFT+GvvyLTDl0nVWq4NviYZhu
	IHHXT6Rkx53bkZFIjSbDJQWdYqkTnXM=
Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214])
	by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 152fcc64 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO)
	for ;
	Sun, 14 Aug 2022 21:58:10 +0000 (UTC)
Content-Type: multipart/alternative;
 boundary="------------KHuzLWsoYeS6OttuMoe8Oi9M"
Message-ID: <9c63a5cd-cd3e-dba4-e436-10f2187ec6f5@nomadlogic.org>
Date: Sun, 14 Aug 2022 14:58:10 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: Updating EFI boot loader results in boot hangup
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
 
 
 <20220814.110850.1703361053728529792.yasu@FreeBSD.org>
 
 <45007308-136a-8938-33d0-bb2509ee6ae7@FreeBSD.org>
 <20220814192609.wyfcogl3dwzteuva@colony.nomadlogic.org>
 <77a7f41c-b060-8582-f19f-345c33043750@gmail.com>
From: Pete Wright 
In-Reply-To: <77a7f41c-b060-8582-f19f-345c33043750@gmail.com>
X-Rspamd-Queue-Id: 4M5WW81JHDz3tdx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=5MOU74Av;
	dmarc=pass (policy=quarantine) header.from=nomadlogic.org;
	spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	DKIM_TRACE(0.00)[nomadlogic.org:+];
	ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------KHuzLWsoYeS6OttuMoe8Oi9M
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 8/14/22 13:26, Graham Perrin wrote:
> On 14/08/2022 20:26, Pete Wright wrote:
>> … has anyone else who has been impacted by this been able to recover? …
> If you have multiple boot environments: do you have a non-affected BE 
> (prior to c32dde3166922f55927764464d13f1bc9640f5f6)?

So unfortunately i didn't have a recent BE, but I was able to do the 
following to get back up:

1. download latest CURRENT snapshot memdisk from ftp.freebsd.org and put 
it on a usb drive
2. boot via usb drive and enter live shell
3. load zfs kmod:
     kldload zfs
4. import zroot:
     zpool import -R /mnt/ zroot
5. mount ROOT filesystem:
     zfs mount zroot/ROOT/default
6. copy usb loader to zroot:
     cp /boot/loader /mnt/boot/loader


i'd recommend just using boot environments, it's much easier and is 
specifically what they are for :)

-pete

-- 
Pete Wright
pete@nomadlogic.org
@nomadlogicLA

--------------KHuzLWsoYeS6OttuMoe8Oi9M
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    

    
On 8/14/22 13:26, Graham Perrin wrote:

    

    

      
      
On 14/08/2022 20:26, Pete Wright
        wrote:

      

      

        
… has anyone else who has been impacted by this been able to recover? …

      

      If you have multiple boot environments: do you have a non-affected
      BE (prior to c32dde3166922f55927764464d13f1bc9640f5f6)?

      
    

    

    So unfortunately i didn't have a recent BE, but I was able to do the
    following to get back up:

    

    1. download latest CURRENT snapshot memdisk from ftp.freebsd.org and
    put it on a usb drive

    2. boot via usb drive and enter live shell

    3. load zfs kmod:

        kldload zfs

    4. import zroot:

        zpool import -R /mnt/ zroot

    5. mount ROOT filesystem:

        zfs mount zroot/ROOT/default

    6. copy usb loader to zroot:

        cp /boot/loader /mnt/boot/loader

    

    

    i'd recommend just using boot environments, it's much easier and is
    specifically what they are for :)

    

    -pete

    
-- 
Pete Wright
pete@nomadlogic.org
@nomadlogicLA

  


--------------KHuzLWsoYeS6OttuMoe8Oi9M--

From nobody Sun Aug 14 23:09:48 2022
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 4M5Y602pzBz4YvBr
	for ; Sun, 14 Aug 2022 23:10:00 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M5Y602GCgz42xn
	for ; Sun, 14 Aug 2022 23:10:00 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660518600;
	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=WIzbRvCxiezD2kfpdCOuAFkvMOUyYbiOcngO6UhSIAc=;
	b=EeXSeA9Smllb2igvFnFoHFPQY1CUrEaovlEhIxtSXLLMuPVRmK/FJ4OGAlJnmvZ14a5mGO
	5ak7hm6A8y7B7T/nJ0C2tJNxUXuAc/EjNbMH3B1oacRgyp6G6GoCfFEKy+D6/tTZl1vvGf
	ZQTU4O0KdNv+y0+EBKWTQdH/5aHF0yjFi+2j9exoC3gjQPBam7vd+svmDFrYHrixO0+pXF
	f2K0vPRDelfqdLB8kF2GrOu/bLJ4lPPyX0EDDtukxE2wjHxoB5Op575xYpNkb/Uo3K7mb8
	o2Aylg7nbzdQhzUG9EyJ2eSPQ2kVAvV8Rgt91m29ZulHn3vQ84Rp06i6RoGnRg==
Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M5Y601C9wz1JGW
	for ; Sun, 14 Aug 2022 23:10:00 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f47.google.com with SMTP id j2so5832563vsp.1
        for ; Sun, 14 Aug 2022 16:10:00 -0700 (PDT)
X-Gm-Message-State: ACgBeo0vM+c0muCJUD+i4dM2zyg9wrz9OJfu4zT8+5W8TSQIg3XWv6XD
	T3md1m+R0pZI7eNcCKcbMFlCChv6kadhC9H/p1U=
X-Google-Smtp-Source: AA6agR4Y6CtwJQCZNpP+/hj2pkbSOROwXLz4nlnF5vVChNPfnmy2yeZ0Qv0+KeZ1JWRDDrnGO/L5HoyBXb9taEsYAqs=
X-Received: by 2002:a05:6102:374:b0:388:9bd4:5639 with SMTP id
 f20-20020a056102037400b003889bd45639mr5394747vsa.53.1660518599537; Sun, 14
 Aug 2022 16:09:59 -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: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
 
 
 <20220814.110850.1703361053728529792.yasu@FreeBSD.org> 
 <45007308-136a-8938-33d0-bb2509ee6ae7@FreeBSD.org> <20220814192609.wyfcogl3dwzteuva@colony.nomadlogic.org>
 <77a7f41c-b060-8582-f19f-345c33043750@gmail.com> <9c63a5cd-cd3e-dba4-e436-10f2187ec6f5@nomadlogic.org>
In-Reply-To: <9c63a5cd-cd3e-dba4-e436-10f2187ec6f5@nomadlogic.org>
From: Nuno Teixeira 
Date: Mon, 15 Aug 2022 00:09:48 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Pete Wright 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="00000000000044bc7905e63b9d5a"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660518600;
	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=WIzbRvCxiezD2kfpdCOuAFkvMOUyYbiOcngO6UhSIAc=;
	b=jC6i8nenfzZDG5GbAur5OGT0BCc7YsppvDTnOgi+/5qiNbBHBfqOgCQ9heF0n+6E/G5WHx
	ECELTJOh2tpwNCJcB+3G2MiMrQi5wx8+ehjvcjNzgef+vzDM6n0GwxLfFKLziID8HoS7No
	lj3J6CGrGWCuzrs3GKmNYybr2nGLW4TB3Qe2d+AxCOIRkM97LHzLTxQSc+eW/XiPVw7qNX
	K+Cu89HyZc2cafmPUvD7nOpD6puKh1B2uNpE9on0mxlS9TqyvVP6KWhHG7hK6aeIxMCre8
	WpiJnQk8tJ2mpzMdZb90AEfY1SUAFBj+RGJ07djM2pRmCkWBGdruGcW7NkQLeQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660518600; a=rsa-sha256; cv=none;
	b=hW78BUGyvH2KR8Ze/mSviZuzgXptirenliYbog21MUQJC9X2mnwId8WWcf3xsfma7aotkZ
	0pNgoziBdlCFLjcd4mWyZd4pSvWKEZc9K/1dSLRm/LDYGc65CBMdY1+g04BJRCP87R50jc
	xnpSpxediWhnilHmPK7+uLspHnDuRV6kCfnjsIy0iYRmT7pnnVNwAHIskb2n8bhigfcdgV
	0U5BgBKO+/M3OEmZ4/Ial/bnY3V0MtEOFzqRphcU2loY77bBGYqgpjXrxJSXpAL3utYHL/
	FXGHP+ypyL+/OP3c6+VlQkvG9BinhfQ7MNqunXLkl/Cn3pz9BNvkq4HXB2ahUQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--00000000000044bc7905e63b9d5a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Isn't better just to mount -t msdos /dev/xxxpn /mnt and cp /boot/loader.efi
/mnt/efi/boot/bootx64.efi?

Pete Wright  escreveu no dia domingo, 14/08/2022 =C3=
=A0(s)
22:58:

>
>
> On 8/14/22 13:26, Graham Perrin wrote:
>
> On 14/08/2022 20:26, Pete Wright wrote:
>
> =E2=80=A6 has anyone else who has been impacted by this been able to reco=
ver? =E2=80=A6
>
> If you have multiple boot environments: do you have a non-affected BE
> (prior to c32dde3166922f55927764464d13f1bc9640f5f6)?
>
>
> So unfortunately i didn't have a recent BE, but I was able to do the
> following to get back up:
>
> 1. download latest CURRENT snapshot memdisk from ftp.freebsd.org and put
> it on a usb drive
> 2. boot via usb drive and enter live shell
> 3. load zfs kmod:
>     kldload zfs
> 4. import zroot:
>     zpool import -R /mnt/ zroot
> 5. mount ROOT filesystem:
>     zfs mount zroot/ROOT/default
> 6. copy usb loader to zroot:
>     cp /boot/loader /mnt/boot/loader
>
>
> i'd recommend just using boot environments, it's much easier and is
> specifically what they are for :)
>
> -pete
>
> --
> Pete Wrightpete@nomadlogic.org
> @nomadlogicLA
>
>

--=20
Nuno Teixeira
FreeBSD Committer (ports)

--00000000000044bc7905e63b9d5a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Isn't better just to mount -t msdos /dev/xxxpn /mnt an=
d cp /boot/loader.efi /mnt/efi/boot/bootx64.efi?

Pete Wright <pete@nomadlogic.org> escreveu no dia=
 domingo, 14/08/2022 =C3=A0(s) 22:58:

 =20
   =20
 =20
  

    

    

    
On 8/14/22 13:26, Graham Perrin wrote:

    

    

     =20
      
On 14/08/2022 20:26, Pete Wright
        wrote:

      

      

        
=E2=80=A6 has anyone else who has been impacted by this been a=
ble to recover? =E2=80=A6

      

      If you have multiple boot environments: do you have a non-affected
      BE (prior to c32dde3166922f55927764464d13f1bc9640f5f6)?

      
    

    

    So unfortunately i didn't have a recent BE, but I was able to do th=
e
    following to get back up:

    

    1. download latest CURRENT snapshot memdisk from ftp.freebsd.org and
    put it on a usb drive

    2. boot via usb drive and enter live shell

    3. load zfs kmod:

    =C2=A0=C2=A0=C2=A0 kldload zfs

    4. import zroot:

    =C2=A0=C2=A0=C2=A0 zpool import -R /mnt/ zroot

    5. mount ROOT filesystem:

    =C2=A0=C2=A0=C2=A0 zfs mount zroot/ROOT/default

    6. copy usb loader to zroot:

    =C2=A0=C2=A0=C2=A0 cp /boot/loader /mnt/boot/loader

    

    

    i'd recommend just using boot environments, it's much easier an=
d is
    specifically what they are for :)

    

    -pete

    
--=20
Pete Wright
pete@nomadlogic.or=
g
@nomadlogicLA

  





-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--00000000000044bc7905e63b9d5a--

From nobody Mon Aug 15 12:23:38 2022
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 4M5tjy5b4Xz4YmPr
	for ; Mon, 15 Aug 2022 12:23:50 +0000 (UTC)
	(envelope-from wjw@digiware.nl)
Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M5tjx5xsKz3PrN
	for ; Mon, 15 Aug 2022 12:23:49 +0000 (UTC)
	(envelope-from wjw@digiware.nl)
Received: from router10g.digiware.nl (localhost.digiware.nl [127.0.0.1])
	by smtp.digiware.nl (Postfix) with ESMTP id 37AC0329D8;
	Mon, 15 Aug 2022 14:23:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl;
	s=medusa-2017; t=1660566220;
	bh=KN1ALFmu1fatkbvM+HnJAMjRNW9tiBjDS3hdMZqcHYQ=;
	h=Date:To:From:Subject;
	b=hoRWCCy+y8oJhDMpALw5ue9IxpSNlAAAgohnKWMjxP2ay7m3zVVrwLbt8yxXkryqh
	 N4KLQMyLz66vubsWxUj0FSJzBQmKdjbZ6McWDSAaSgQbUQ6FbucVs7Njz/kWJuZnpO
	 QG/NRRVkzbN3ZN6zpkAkSeJhPayENQP7V1/mqdQOzb6N0ESnKihLf6QCMPTpO43+yb
	 FYRjiCIFHPkYlzTEmxC4ibhrzx4vqN0RLBHZNhAv0uWBaSFMh0XqU7fjqwun75a+gj
	 2DxbuFNRdWNVDU1bgnXjKfkOsOmt+21zgCIlUD2GxaJV7ysea4Qcd55pVz065zFx14
	 vEwJOrmV/eJhQ==
X-Virus-Scanned: amavisd-new at digiware.nl
Received: from smtp.digiware.nl ([127.0.0.1])
	by router10g.digiware.nl (router10g.digiware.nl [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id LAhboEnz4Qqc; Mon, 15 Aug 2022 14:23:39 +0200 (CEST)
Received: from [192.168.10.67] (wjw [192.168.10.67])
	(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 smtp.digiware.nl (Postfix) with ESMTPSA id D92A3329D4
	for ; Mon, 15 Aug 2022 14:23:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl;
	s=medusa-2017; t=1660566219;
	bh=KN1ALFmu1fatkbvM+HnJAMjRNW9tiBjDS3hdMZqcHYQ=;
	h=Date:To:From:Subject;
	b=YQZojtig2cEsyHG6NyrVF1ejcPHcmkIfxNvcIgj4IXOomx1jmBvfE7cGvRgqwXrAz
	 NfTy++Gfy4BOQGkrFXn+HZxoCU8AnUSZfSp3JoMG5C57UW8jh5DfnRCep3gV+tNpfe
	 ETBi4dC+H9Ty2DDk1UeNmIFjsEy1Qt+Stth3SGeVXwn7GRZQZDZm9i/rnl/pohGcvS
	 Zv2ItpCWZt61sBOgqYZXRYLIhxm+V/GBmMECtsfFO+gfB/w75ppKDmUO1OCZdfmyhw
	 zcSon7k6Yy0SVzUNrzxDfAKk2RyiJy8u1BywFucn9+16picaCxkXhYLxr+pGnnEr+e
	 Cqa6KyplKFpQQ==
Message-ID: <5d898904-e58a-d205-dd67-0716628d1fd0@digiware.nl>
Date: Mon, 15 Aug 2022 14:23:38 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.12.0
Content-Language: nl
To: freebsd current 
From: Willem Jan Withagen 
Subject: Recent 14.0-CURRENT(s) crash in BTX whilest booting
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4M5tjx5xsKz3PrN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=digiware.nl header.s=medusa-2017 header.b=hoRWCCy+;
	dkim=pass header.d=digiware.nl header.s=medusa-2017 header.b=YQZojtig;
	dmarc=pass (policy=quarantine) header.from=digiware.nl;
	spf=pass (mx1.freebsd.org: domain of wjw@digiware.nl designates 2001:4cb8:90:ffff::3 as permitted sender) smtp.mailfrom=wjw@digiware.nl
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	DMARC_POLICY_ALLOW(-0.50)[digiware.nl,quarantine];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[digiware.nl:s=medusa-2017];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[digiware.nl:+];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ASN(0.00)[asn:28878, ipnet:2001:4cb8::/29, country:NL];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

I tried upgrading a 14.0-CURRENT system from somewhere Dec 2021, to the 
most recent state.
So I build everything and installed the things...

Reboot and I end up in BTX....
Oke, so I perhaps should also update pmbr and gptzfsboot.
Booted from stick, and update...

Still I end up in BTX.

So get out the guns:
Downloaded the latest snapshot, and even there I do end up in BTX
once I have installed the system.
The Stick does boot the mem-stcik into EFI, and lets me install the
system. But upon reboot I again endup in BTX.

So i anybody out there willing to help me figure out what is wrong here.
I can sent you a foto of the BTX screen.

System specs:
     ASUS M5A97 PLUS
     AMD FX-8370 Eight-Core Processor
     24Gbyte Ram
     1 HD (rust) seagate ST3250318AS 250G
         met auto-install ZFS stripe, 8G swap, BIOS+UEFI

Thanx,
--WjW

BTW: I now installed 13.1-RELASE on another disk, and that (just) works


From nobody Mon Aug 15 15:01:32 2022
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 4M5yDY63kZz4ZByX
	for ; Mon, 15 Aug 2022 15:02:05 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M5yDX3cvQz3kHk
	for ; Mon, 15 Aug 2022 15:02:04 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by smtp6.goneo.de (Postfix) with ESMTPS id B3BB610A32EB
	for ; Mon, 15 Aug 2022 17:02:02 +0200 (CEST)
Received: from hub2.goneo.de (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPS id E025410A1E8B
	for ; Mon, 15 Aug 2022 17:02:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
	s=DKIM001; t=1660575720;
	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=sF50SOtCsjuehwYGdDeuMoLaWiAWM/SV5FTbOZNyoi4=;
	b=m59xjTeROAtYql3yXC1/6VJlK3zpE3kOkbmudY3qAXhgk6lnlazpJ4BGlLh+jXLO/MGA+u
	b4i7eErLtEPRNm3znUlXTpsO4+Qn1wKgbrf0B7CxHj8/68yWTt2xEoeXf0sxE8vRZ9DH5V
	wR3oed9b6AjLjyudOU0epF7n1Ng2XSCAy7kcxL/L4bAWkLGiTPZ46OkpjuyW48OEsC749U
	foRLK0UliRDQ6WXR3hkEtC/wK+VTHwvbydfy+XPIPyTbh7/VtqvHg+E8aBm54DYJaZNq/D
	mCumv77OszWJ6n2nBGfFxlEbr1ot1SzeCbsvv66bPbR5glMeonYa7rGtEs7CHw==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-089-014-046-021.89.14.pool.telefonica.de [89.14.46.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPSA id 21DE410A1E8A
	for ; Mon, 15 Aug 2022 17:02:00 +0200 (CEST)
Date: Mon, 15 Aug 2022 17:01:32 +0200
From: FreeBSD User 
To: FreeBSD CURRENT 
Subject: ZFS: cannot import zroot: I/O error
Message-ID: <20220815170159.2394b5dd@thor.intern.walstatt.dynvpn.de>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-UID: 059d9b
X-Rspamd-UID: 9263ee
X-Rspamd-Queue-Id: 4M5yDX3cvQz3kHk
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=m59xjTeR;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.31) smtp.mailfrom=freebsd@walstatt-de.de
X-Spamd-Result: default: False [-3.40 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from];
	DKIM_TRACE(0.00)[walstatt-de.de:+];
	ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	TO_DN_ALL(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[walstatt-de.de];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hello,

I'm running a FreeBSD 13.1-RELENG-p1 zroot-based guest in a VirtualBox 4.1.24/26 (do not know
exactly). The host is a special system based on Linux und VirtualBox and I have no chances to
configure the VBox.

Somehow the VBox crashed and hung up the complete computer, so I had to cold start it after
approx. 30 minutes of waiting. After that, rhe virtual drive and its ZFS filesystem was
wrecked, shwing a stream of 

zio_read error: 5
ZFS: i/o error - all block copies unavailable

After a quick search I found some advices howto try fixing, last an longest one was 

zpool import -fFX -N -R /alternate/path zroot

which took approx 20 minutes - with no success.

There are some valuable data on the partition, which are all backed up, but it would take its
time to restore everything, so I'd like to ask whether there is any cance to "repair" the
mysterious damage.

I'm able to boot off from an USB flash drive ...

Kind regards

oh



-- 
O. Hartmann

From nobody Mon Aug 15 16:22:30 2022
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 4M601T5QVbz4ZPK8
	for ; Mon, 15 Aug 2022 16:22:37 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from pv50p00im-ztdg10012001.me.com (pv50p00im-ztdg10012001.me.com [17.58.6.51])
	(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 4M601T0XdCz3s2W
	for ; Mon, 15 Aug 2022 16:22:37 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1660580554; bh=+BO1isPZme0INyxX4tMYHYGLozxHhM8XVqdxxS5ncT4=;
	h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To;
	b=yOQaK5ivWZe5TTkK8P5yI8MFU2pWJDFX+bqJV/6NghLx28/R9JECDy/oftVrHNxzW
	 Tct5OIArxWJj1ubChVcDhPrcTZCiBXv+RO18+qBIqaRjWzncaP+rDDgCkmpdl0Gd4d
	 +iXyOkHQifH/PwhxrnvjAVDFD3iWrhq2qikzUMgA1VkweVSemy+pqHHztXauwcfUH6
	 rCJF0+Lwp1RtzNLogzZHWUco+HzNmZN4/KsoB6QxrSa1EGflO9V9o+cBuXq/7/tMBJ
	 Pj+ESUo2NUZusEs/EfA6vo7y2BMJH9VGfE7P1lvz4beRRX/ODB/gBZMbtK87+PU6WT
	 mObwEMNKBSySQ==
Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10])
	by pv50p00im-ztdg10012001.me.com (Postfix) with ESMTPSA id 56431A00C8;
	Mon, 15 Aug 2022 16:22:33 +0000 (UTC)
From: Toomas Soome 
Message-Id: <7B040730-5115-4BC9-A45A-53FA2145810C@me.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4EBF50BE-5D7B-448D-A57C-5AF069043DE1"
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: ZFS: cannot import zroot: I/O error
Date: Mon, 15 Aug 2022 19:22:30 +0300
In-Reply-To: <20220815170159.2394b5dd@thor.intern.walstatt.dynvpn.de>
Cc: FreeBSD CURRENT 
To: FreeBSD User 
References: <20220815170159.2394b5dd@thor.intern.walstatt.dynvpn.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Proofpoint-GUID: FyXvmTpDcGEDqxFCZwgjTbBaHXkUUw4N
X-Proofpoint-ORIG-GUID: FyXvmTpDcGEDqxFCZwgjTbBaHXkUUw4N
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.517,18.0.883,17.0.605.474.0000000_definitions?=
 =?UTF-8?Q?=3D2022-06-21=5F08:2022-06-21=5F01,2022-06-21=5F08,2020-01-23?=
 =?UTF-8?Q?=5F02_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 spamscore=0
 phishscore=0 clxscore=1015 adultscore=0 bulkscore=0 suspectscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2206140000 definitions=main-2208150063
X-Rspamd-Queue-Id: 4M601T0XdCz3s2W
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=yOQaK5iv;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.51 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-2.59 / 15.00];
	URI_COUNT_ODD(1.00)[5];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.99)[-0.994];
	DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16];
	RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.51:from];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEFALL_USER(0.00)[tsoome];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	FREEMAIL_ENVFROM(0.00)[me.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[me.com:+];
	TO_DN_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[me.com];
	DWL_DNSWL_NONE(0.00)[me.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_4EBF50BE-5D7B-448D-A57C-5AF069043DE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 15. Aug 2022, at 18:01, FreeBSD User  =
wrote:
>=20
> Hello,
>=20
> I'm running a FreeBSD 13.1-RELENG-p1 zroot-based guest in a VirtualBox =
4.1.24/26 (do not know
> exactly). The host is a special system based on Linux und VirtualBox =
and I have no chances to
> configure the VBox.
>=20
> Somehow the VBox crashed and hung up the complete computer, so I had =
to cold start it after
> approx. 30 minutes of waiting. After that, rhe virtual drive and its =
ZFS filesystem was
> wrecked, shwing a stream of=20
>=20
> zio_read error: 5
> ZFS: i/o error - all block copies unavailable
>=20
> After a quick search I found some advices howto try fixing, last an =
longest one was=20
>=20
> zpool import -fFX -N -R /alternate/path zroot
>=20
> which took approx 20 minutes - with no success.
>=20
> There are some valuable data on the partition, which are all backed =
up, but it would take its
> time to restore everything, so I'd like to ask whether there is any =
cance to "repair" the
> mysterious damage.
>=20
> I'm able to boot off from an USB flash drive =E2=80=A6
>=20

This happens when vbox is telling zfs that data is written on disk, but =
is actually still in caches=E2=80=A6 So yea, the standard answer could =
be =E2=80=9Crestore from backup=E2=80=9D, but it also may help to use =
ability to revert TXG (it does drop data!).  See also =
https://gist.github.com/mkhon/34d979c78077a20648456272d7f2cc15 =


rgds,
toomas





--Apple-Mail=_4EBF50BE-5D7B-448D-A57C-5AF069043DE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 15. Aug 2022, at 18:01, FreeBSD User <freebsd@walstatt-de.de> wrote:

Hello,

I'm running a FreeBSD =
13.1-RELENG-p1 zroot-based guest in a VirtualBox 4.1.24/26 (do not =
know
exactly). The host is a special system based on Linux =
und VirtualBox and I have no chances to
configure the =
VBox.

Somehow the VBox crashed and hung up =
the complete computer, so I had to cold start it after
approx. 30 minutes of waiting. After that, rhe virtual drive =
and its ZFS filesystem was
wrecked, shwing a stream of 

zio_read error: 5
ZFS: i/o error =
- all block copies unavailable

After a =
quick search I found some advices howto try fixing, last an longest one =
was 

zpool import -fFX -N -R =
/alternate/path zroot

which took approx 20 =
minutes - with no success.

There are some =
valuable data on the partition, which are all backed up, but it would =
take its
time to restore everything, so I'd like to ask =
whether there is any cance to "repair" the
mysterious =
damage.

I'm able to boot off from an USB =
flash drive =E2=80=A6


This =
happens when vbox is telling zfs that data is written on disk, but is =
actually still in caches=E2=80=A6 So yea, the standard answer could be =
=E2=80=9Crestore from backup=E2=80=9D, but it also may help to use =
ability to revert TXG (it does drop data!).  See also https://gist.github.com/mkhon/34d979c78077a20648456272d7f2cc15<=
/a>





=

--Apple-Mail=_4EBF50BE-5D7B-448D-A57C-5AF069043DE1--

From nobody Mon Aug 15 16:55:46 2022
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 4M60lp6rfrz4ZTB3
	for ; Mon, 15 Aug 2022 16:55:50 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M60lp02DZz3wYW;
	Mon, 15 Aug 2022 16:55:49 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id a51536c5;
	Mon, 15 Aug 2022 16:55:47 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 5e5bfb83 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Mon, 15 Aug 2022 16:55:47 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-E6C51BB4-32DC-4764-977E-79E905C6B41A
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 (1.0)
Subject: Re: ZFS: cannot import zroot: I/O error
From: Michael Gmelin 
In-Reply-To: <7B040730-5115-4BC9-A45A-53FA2145810C@me.com>
Date: Mon, 15 Aug 2022 18:55:46 +0200
Cc: FreeBSD User ,
 FreeBSD CURRENT 
Message-Id: <59A72011-3EEC-4A16-B328-977C7C27CB18@freebsd.org>
References: <7B040730-5115-4BC9-A45A-53FA2145810C@me.com>
To: Toomas Soome 
X-Mailer: iPhone Mail (19G71)
X-Rspamd-Queue-Id: 4M60lp02DZz3wYW
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-2.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[me.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[grembo];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCPT_COUNT_THREE(0.00)[3];
	R_SPF_SOFTFAIL(0.00)[~all];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail-E6C51BB4-32DC-4764-977E-79E905C6B41A
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On 15. Aug 2022, at 18:22, Toomas Soome  wrote:
>=20
> =EF=BB=BF
>=20
>> On 15. Aug 2022, at 18:01, FreeBSD User  wrote:
>>=20
>> Hello,
>>=20
>> I'm running a FreeBSD 13.1-RELENG-p1 zroot-based guest in a VirtualBox 4.=
1.24/26 (do not know
>> exactly). The host is a special system based on Linux und VirtualBox and I=
 have no chances to
>> configure the VBox.
>>=20
>> Somehow the VBox crashed and hung up the complete computer, so I had to c=
old start it after
>> approx. 30 minutes of waiting. After that, rhe virtual drive and its ZFS f=
ilesystem was
>> wrecked, shwing a stream of=20
>>=20
>> zio_read error: 5
>> ZFS: i/o error - all block copies unavailable
>>=20
>> After a quick search I found some advices howto try fixing, last an longe=
st one was=20
>>=20
>> zpool import -fFX -N -R /alternate/path zroot
>>=20
>> which took approx 20 minutes - with no success.
>>=20
>> There are some valuable data on the partition, which are all backed up, b=
ut it would take its
>> time to restore everything, so I'd like to ask whether there is any cance=
 to "repair" the
>> mysterious damage.
>>=20
>> I'm able to boot off from an USB flash drive =E2=80=A6
>>=20
>=20
> This happens when vbox is telling zfs that data is written on disk, but is=
 actually still in caches=E2=80=A6 So yea, the standard answer could be =E2=80=
=9Crestore from backup=E2=80=9D, but it also may help to use ability to reve=
rt TXG (it does drop data!).  See also https://gist.github.com/mkhon/34d979c=
78077a20648456272d7f2cc15
>=20

While it might not help the requester with the problem at hand, this situati=
on can be prevented (or at least made less likely) by disabling "IgnoreFlush=
" - depending on the virtual device emulated this could be something like:

    VBoxManage setextradata VM-name   "VBoxInternal/Devices/ahci/0/LUN#[0]/C=
onfig/IgnoreFlush" 0

or

    VBoxManage setextradata VM-name "VBoxInternal/Devices/piix3ide/0/LUN#[x]=
/Config/IgnoreFlush" 0

See also: https://www.virtualbox.org/manual/ch12.html#ts_ide-sata-flush

It=E2=80=99s highly recommended for ZFS in case your VM isn=E2=80=99t a thro=
waway CI thing.

Best
Michael



--Apple-Mail-E6C51BB4-32DC-4764-977E-79E905C6B41A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 15. Aug 2022, at 18=
:22, Toomas Soome <tsoome@me.com> wrote:

=EF=BB=BF

On 15. Aug 2022, at 1=
8:01, FreeBSD User <=
freebsd@walstatt-de.de> wrote:

Hello,

I=
'm running a FreeBSD 13.1-RELENG-p1 zroot-based guest in a VirtualBox 4.1.24=
/26 (do not know
exactly). The host is a special system based o=
n Linux und VirtualBox and I have no chances to
configure the V=
Box.

Somehow the VBox crashed and hung up the c=
omplete computer, so I had to cold start it after
approx. 30 m=
inutes of waiting. After that, rhe virtual drive and its ZFS filesystem was<=
br class=3D"">wrecked, shwing a stream of 

zio_=
read error: 5
ZFS: i/o error - all block copies unavailable
After a quick search I found some advices howto t=
ry fixing, last an longest one was 

zpool impor=
t -fFX -N -R /alternate/path zroot

which took a=
pprox 20 minutes - with no success.

There are s=
ome valuable data on the partition, which are all backed up, but it would ta=
ke its
time to restore everything, so I'd like to ask whether t=
here is any cance to "repair" the
mysterious damage.

I'm able to boot off from an USB flash drive =E2=80=A6


=

This happens when vbox is telling zfs that data is written on disk, but=
 is actually still in caches=E2=80=A6 So yea, the standard answer could be =E2=
=80=9Crestore from backup=E2=80=9D, but it also may help to use ability to r=
evert TXG (it does drop data!).  See also https://gist.g=
ithub.com/mkhon/34d979c78077a20648456272d7f2cc15


While it might not help the requester with th=
e problem at hand, this situation can be prevented (or at least made less li=
kely) by disabling "IgnoreFlush" - depending on the virtual device emulated t=
his could be something like:

    VBoxManage setextrad=
ata VM-name   "VBoxInternal/Devices/ahci/0/LUN#[0]/Config/Ignore=
Flush" 0

or

    V=
BoxManage setextradata VM-name "VBoxInternal/Devices/piix3ide/0/LUN#[x]/Conf=
ig/IgnoreFlush" 0


It=E2=
=80=99s highly recommended for ZFS in case your VM isn=E2=80=99t a throwaway=
 CI thing.

Best
Michael


=

--Apple-Mail-E6C51BB4-32DC-4764-977E-79E905C6B41A--

From nobody Mon Aug 15 19:46:18 2022
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 4M64Xk5PLDz4YjWn
	for ; Mon, 15 Aug 2022 19:46:30 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M64Xk0FSmz3MB7
	for ; Mon, 15 Aug 2022 19:46:29 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vk1-xa34.google.com with SMTP id j11so4170491vkk.11
        for ; Mon, 15 Aug 2022 12:46:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=jQfK397STIWjkg4HBymnVGdPkYCkbrsT0OvLq97hclg=;
        b=sr71HsVxTqEtZEue5DzOwMZngMIDSQKssJma5l7rraOZVand4RU3v2GqYvk67DwfYK
         b5gUr6Bqi/U9agtDyH/P4M8gmISvEYK9uo77UDk2/RHTUmQ9FRSvRfaTMT4swLliVP8Y
         AwAuEsCRlksPCfDBRVM12ufmrQ5ushmm41r2btwpcr0fhVqLwdIqTCNIE2mm27DTZBr0
         EZTofrYTYyemhq0c/5ZQwHbgiTraX6dn4wU/xd/1vvOXKq2AZyr0lqfWDdnlAnNITZaz
         zRZ9hZYxMFiwAdYHw9WkC/Tkjfyt66MD63/NG81IGVZLD3iFjk7EDX9U6ajXaeW4Tp9c
         nClw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=jQfK397STIWjkg4HBymnVGdPkYCkbrsT0OvLq97hclg=;
        b=3vE8PTPJpiVidbil3DymxIMjsjy6sCKLBzsUoQCNceCuWm7N4CeBEiWSRxZSqive/g
         FItc7+SEeoyTJO/ZGVoDg8zul5NzH9QIaQSL7k8wWLpKP0tXM6Jw6OpoYAIsCsxO0LBS
         NUCqfq1iFYPHbTJ85kin8Rq39TB8N1Tq03zMGN0uVUW7H9Cf4jKshcFupBBkxFUQh8+G
         P4lMvb50CPjp2GhlvbQuByasl+yc98DBzYAj2YGWo654WtwslmNErJxkfs+/LvJ5Jcds
         TP7wPmR83KsLTEkAT0WB394TnlW7N8En3MYQZEG1Vl+HRAfGUC92UHbEJcQLoGkElQlf
         qWgg==
X-Gm-Message-State: ACgBeo3I7DwifQ3o3SfLcxq60d0FRMQNZ/jmECWkPck45SsXzwEj6LcN
	NXMsWnof0Hfia9x2rYkjZ6KmR9C9GI7/TT/Yfvb5AfVqBIY=
X-Google-Smtp-Source: AA6agR5Ib2oNFtDbPg1Ovy0hUV2vZbWSnqrH0jeTF33g/zctPoV4jKxhIDz8A6q6f0d51dYLIqwnn79oZ6T5NTejrRM=
X-Received: by 2002:a1f:3803:0:b0:378:bd6f:249d with SMTP id
 f3-20020a1f3803000000b00378bd6f249dmr7168153vka.13.1660592789109; Mon, 15 Aug
 2022 12:46:29 -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: <20220813.015426.809710797578801280.yasu@FreeBSD.org> <029d861e-7a30-296b-669d-5496eb120110@freebsd.org>
In-Reply-To: <029d861e-7a30-296b-669d-5496eb120110@freebsd.org>
From: Warner Losh 
Date: Mon, 15 Aug 2022 13:46:18 -0600
Message-ID: 
Subject: Re: bootx64.efi; and loader.efi in the FreeBSD reserved area (was:
 Updating EFI boot loader results in boot hangup)
To: Graham Perrin 
Cc: FreeBSD Current 
Content-Type: multipart/alternative; boundary="0000000000004fd2dd05e64ce38e"
X-Rspamd-Queue-Id: 4M64Xk0FSmz3MB7
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=sr71HsVx;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a34) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a34:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000004fd2dd05e64ce38e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 14, 2022 at 7:52 AM Graham Perrin 
wrote:

> On 12/08/2022 17:54, Yasuhiro Kimura wrote:
>
> =E2=80=A6 amd64 =E2=80=A6 (/boot/efi/efi/freebsd/loader.efi) =E2=80=A6
>
> Side note: please, why the FreeBSD reserved area?
>

When you create a boot variable using efibootmgr, it's better to specify
something that's not the default
binary. It's what Windows, Linux, etc do when they are installed and it
facilitates better multiboot when
the target OSes depend on the first stage efi boot loader (like FreeBSD and
Windows certainly do).

Warner

>
> I'm more familiar with /efi/boot/bootx64.efi for amd64.
>
> 
> 
>

--0000000000004fd2dd05e64ce38e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Aug 14, 2022 at 7:52 AM Graha=
m Perrin <grahamperrin@freeb=
sd.org> wrote:

 =20
   =20
 =20
  

    
On 12/08/2022 17:54, Yasuhiro Kimura wrote:

    

    

      
=E2=80=A6 amd64 =E2=80=A6 (/boot/efi/efi/freebsd/loader.efi) =E2=
=80=A6

    

    
Side note: please, why the FreeBSD reserved area?

When you create a boot variable using efibootmgr, i=
t's better to specify something that's not the default
bi=
nary. It's what Windows, Linux, etc do when they are installed and it f=
acilitates better multiboot when
the target OSes depend on the fi=
rst stage efi boot loader (like FreeBSD and Windows certainly do).

Warner=C2=A0
 

    

    
I'm more familiar with /efi/boot/bootx64.efi for amd64.=C2=A0
    
<https://bugs.freebsd.org/bugzilla/show_bug.cgi=
?id=3D255318#c11>

    

  

  




--0000000000004fd2dd05e64ce38e--

From nobody Mon Aug 15 20:11:59 2022
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 4M656M3C8gz4Ymh8
	for ; Mon, 15 Aug 2022 20:12:11 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M656M0Fs4z3PZJ
	for ; Mon, 15 Aug 2022 20:12:11 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe30.google.com with SMTP id o123so8242181vsc.3
        for ; Mon, 15 Aug 2022 13:12:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=BEVmpgYezNatFqaXFRuExdmiOvOu+BMXo/+FYXItqBY=;
        b=bLdy93X3U9v7rSq6b3CwOgprFPv7iJx3B18QZNkJcZxD3METNM7AnSnKOihDZkx8w/
         K1GY9VOkaZwSDm5iQXc0BRQDDH3qS8uVDzroeoWiqLGgRR/TnUz2+oGmcmXN48ZuakW7
         jwViuhAnJ5HB4xjytnxESDoyCRzGn3tKPf1r4/kGv8L2zso9mspYMuZWG2JsWNhDecJ7
         KZIGwrtYtHeuMYeHBkr9Q36OaOrkILi/KwIoEslfakV2daoT2+kXhzCKzcAspm8fLO+c
         CzhckY+n66wAK+kTYEuu2pAz77Qm8Ki9iXG59t8VQtxTaUoIwC9kFsQKzW1d654u0YGN
         L6rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=BEVmpgYezNatFqaXFRuExdmiOvOu+BMXo/+FYXItqBY=;
        b=3xRmIAbM7GiuM16RpHxIo3uy0Mj5o5EId7QXNMwdgt4S7RImV/Bk+XZ4ALTcywkyi/
         N+B77ROr1Y4fo/XQhiHzZgdR5FBw1q+vxr36B+SRQysAjUcjIgM/QjEGMNvpa0aJcwe6
         o3sq5qj9A5hOZlqviuEjFsW1SswemUEsfIrayNm96UvUNG/Twm72gi9aU7aU2bhjCmV9
         HFIhaWIyU6zftdcK5QWccUbi2tbVNnN9WFAjN1yk8tAdzqCjmW9Qbv+Z3RzhPjh9xHxR
         Wy8F2Q+NHStYCvD55x6ABytUHB2D+EbIAfpbMiHj77yvd+bUb7P3+ohFGXB+PWD8Ml4x
         SAiw==
X-Gm-Message-State: ACgBeo0oZFhu9Z6J8dyvM/JPVLmzA8uaM4FzpuEiOQL7u0ahzWwdOjB8
	BKqrfN+ZB3rqB3n45h/8lUhUG17E13cMsfB85di1LIeMVrjlOw==
X-Google-Smtp-Source: AA6agR6ohV6dPDlqqtwvW7H4YtoVsmJLoS9A6U1RCjQG8JAjsvdiQ9N7nBLqtnBfYOlUinbRDpB3ShUTgBlIBn0U/IQ=
X-Received: by 2002:a67:d50c:0:b0:38a:c107:25e0 with SMTP id
 l12-20020a67d50c000000b0038ac10725e0mr3621346vsj.11.1660594330491; Mon, 15
 Aug 2022 13:12:10 -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: <5d898904-e58a-d205-dd67-0716628d1fd0@digiware.nl>
In-Reply-To: <5d898904-e58a-d205-dd67-0716628d1fd0@digiware.nl>
From: Warner Losh 
Date: Mon, 15 Aug 2022 14:11:59 -0600
Message-ID: 
Subject: Re: Recent 14.0-CURRENT(s) crash in BTX whilest booting
To: Willem Jan Withagen 
Cc: freebsd current 
Content-Type: multipart/alternative; boundary="0000000000002f714805e64d3f44"
X-Rspamd-Queue-Id: 4M656M0Fs4z3PZJ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=bLdy93X3;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e30) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e30:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000002f714805e64d3f44
Content-Type: text/plain; charset="UTF-8"

This should be fixed now.

commit d98de7440507aea1648c8f4bc302bf88c0eb9458
Author: Toomas Soome 
Date:   Mon Aug 15 00:49:50 2022 +0300

    loader: zfs reader should only store devdesc in f_devdata

    Use d_opendata for device specific data.

    PR:             265825
    Reviewed by:    imp
    Differential Revision:  https://reviews.freebsd.org/D36202

is the commit you want to have in your tree.

Warner

On Mon, Aug 15, 2022 at 6:23 AM Willem Jan Withagen  wrote:

> Hi,
>
> I tried upgrading a 14.0-CURRENT system from somewhere Dec 2021, to the
> most recent state.
> So I build everything and installed the things...
>
> Reboot and I end up in BTX....
> Oke, so I perhaps should also update pmbr and gptzfsboot.
> Booted from stick, and update...
>
> Still I end up in BTX.
>
> So get out the guns:
> Downloaded the latest snapshot, and even there I do end up in BTX
> once I have installed the system.
> The Stick does boot the mem-stcik into EFI, and lets me install the
> system. But upon reboot I again endup in BTX.
>
> So i anybody out there willing to help me figure out what is wrong here.
> I can sent you a foto of the BTX screen.
>
> System specs:
>      ASUS M5A97 PLUS
>      AMD FX-8370 Eight-Core Processor
>      24Gbyte Ram
>      1 HD (rust) seagate ST3250318AS 250G
>          met auto-install ZFS stripe, 8G swap, BIOS+UEFI
>
> Thanx,
> --WjW
>
> BTW: I now installed 13.1-RELASE on another disk, and that (just) works
>
>
>

--0000000000002f714805e64d3f44
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This should be fixed now.=C2=A0

commit =
d98de7440507aea1648c8f4bc302bf88c0eb9458
Author: Toomas Soome <tsoome=
@FreeBSD.org>
Date: =C2=A0 Mon Aug 15 00:49:50 2022 +0300

=C2=
=A0 =C2=A0 loader: zfs reader should only store devdesc in f_devdata
=C2=A0 =C2=A0 Use d_opendata for device specific data.

=C2=A0 =C2=
=A0 PR: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 265825
=C2=A0 =C2=A0 R=
eviewed by: =C2=A0 =C2=A0imp
=C2=A0 =C2=A0 Differential Revision: =C2=A0=
https://reviews.freebsd.org/=
D36202

is the commit you want to have in y=
our tree.

Warner

On Mon, Aug 15, 2022 at 6:23=
 AM Willem Jan Withagen <wjw@digiware=
.nl> wrote:
Hi,



I tried upgrading a 14.0-CURRENT system from somewhere Dec 2021, to the 
most recent state.

So I build everything and installed the things...



Reboot and I end up in BTX....

Oke, so I perhaps should also update pmbr and gptzfsboot.

Booted from stick, and update...



Still I end up in BTX.



So get out the guns:

Downloaded the latest snapshot, and even there I do end up in BTX

once I have installed the system.

The Stick does boot the mem-stcik into EFI, and lets me install the

system. But upon reboot I again endup in BTX.



So i anybody out there willing to help me figure out what is wrong here.
I can sent you a foto of the BTX screen.



System specs:

=C2=A0=C2=A0=C2=A0=C2=A0 ASUS M5A97 PLUS

=C2=A0=C2=A0=C2=A0=C2=A0 AMD FX-8370 Eight-Core Processor

=C2=A0=C2=A0=C2=A0=C2=A0 24Gbyte Ram

=C2=A0=C2=A0=C2=A0=C2=A0 1 HD (rust) seagate ST3250318AS 250G

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 met auto-install ZFS stripe, 8G=
 swap, BIOS+UEFI



Thanx,

--WjW



BTW: I now installed 13.1-RELASE on another disk, and that (just) works








--0000000000002f714805e64d3f44--

From nobody Mon Aug 15 20:22:57 2022
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 4M65Lw27thz4Ypj7
	for ; Mon, 15 Aug 2022 20:23:04 +0000 (UTC)
	(envelope-from wjw@digiware.nl)
Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M65Lv0SFPz3SWW
	for ; Mon, 15 Aug 2022 20:23:02 +0000 (UTC)
	(envelope-from wjw@digiware.nl)
Received: from router10g.digiware.nl (localhost.digiware.nl [127.0.0.1])
	by smtp.digiware.nl (Postfix) with ESMTP id 19B9C32A7A;
	Mon, 15 Aug 2022 22:22:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl;
	s=medusa-2017; t=1660594975;
	bh=Z4RuJ3u+FXVfH5uVD/jZ0wBvPMBY1ijs40dPttX9bUY=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To;
	b=YYYoZsYVhPLwO9Vl/YQrIIbQzENckVd31peH2sBzDK7x8PL6tKnmHK7e67+Qvtll/
	 H4Nzd/3jIMvCZ85oqG+5JwY/bDGf7GvyTaGSmWvqRWjpjAOhPhhXxxflXPltxiJdty
	 WxeMq/1aoluzMfgcPAQqjo8sodO3tX1Yb08fzOEe+2nXuvEplCBRCojKv5IE7oAxGI
	 o6CzuGJvCHRCPYY/B7qLUabQbUWMF29FHh7ZVesysHLEbDrubTEhw+u5VBjDRr598k
	 +W1DT0nVESicooURN4QXiwY29c/vaBgd75k/X1p+N6VwWCuX0boZzAn+VPiQjVvHyM
	 7ZZUaslarFXVQ==
X-Virus-Scanned: amavisd-new at digiware.nl
Received: from smtp.digiware.nl ([127.0.0.1])
	by router10g.digiware.nl (router10g.digiware.nl [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id wKc0LQ5cHc1H; Mon, 15 Aug 2022 22:22:54 +0200 (CEST)
Received: from [192.168.10.10] (asus [192.168.10.10])
	(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 smtp.digiware.nl (Postfix) with ESMTPSA id 87DAE32A5A;
	Mon, 15 Aug 2022 22:22:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl;
	s=medusa-2017; t=1660594974;
	bh=Z4RuJ3u+FXVfH5uVD/jZ0wBvPMBY1ijs40dPttX9bUY=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To;
	b=VLeIE8Muxci+hCxbce/mxNsslzgvlvPmxPmzUgNwCbnilr9GOZmlJplSaazEhI/KC
	 9e1MBbAwZh6t7cZlwlVdtXW2ychumVIylgn5Kny0YOeAEzh+xB7lRIm0rLYJUkjA5T
	 JP4tM4ZlY3pM09X+K6no/eagu5LtYgQuKSN6CMbvEF0HhKh49sE3bfItVl+WFrx7E3
	 SSv5EimqglbojHR7OydTCJe4eebvhVbS+3lkayW+iaXfey2NWMubJjWfKiHtxvTD+R
	 SiA97tHfEPXLD4apegf92TBjF0W/MthV45ifPPYVmsBEsNz1QA3LZoL49SSdslNCZH
	 fYP5X7STEcptg==
Content-Type: multipart/alternative;
 boundary="------------h0NSuhHrea0OgaNv0LHnpMUr"
Message-ID: 
Date: Mon, 15 Aug 2022 22:22:57 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.12.0
Subject: Re: Recent 14.0-CURRENT(s) crash in BTX whilest booting
Content-Language: nl
To: Warner Losh 
Cc: freebsd current 
References: <5d898904-e58a-d205-dd67-0716628d1fd0@digiware.nl>
 
From: Willem Jan Withagen 
In-Reply-To: 
X-Rspamd-Queue-Id: 4M65Lv0SFPz3SWW
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=digiware.nl header.s=medusa-2017 header.b=YYYoZsYV;
	dkim=pass header.d=digiware.nl header.s=medusa-2017 header.b=VLeIE8Mu;
	dmarc=pass (policy=quarantine) header.from=digiware.nl;
	spf=pass (mx1.freebsd.org: domain of wjw@digiware.nl designates 176.74.240.9 as permitted sender) smtp.mailfrom=wjw@digiware.nl
X-Spamd-Result: default: False [-3.99 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.99)[-0.993];
	DMARC_POLICY_ALLOW(-0.50)[digiware.nl,quarantine];
	R_DKIM_ALLOW(-0.20)[digiware.nl:s=medusa-2017];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	ASN(0.00)[asn:28878, ipnet:176.74.224.0/19, country:NL];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[digiware.nl:+];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------h0NSuhHrea0OgaNv0LHnpMUr
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 15-8-2022 22:11, Warner Losh wrote:
> This should be fixed now.
>
> commit d98de7440507aea1648c8f4bc302bf88c0eb9458
> Author: Toomas Soome 
> Date:   Mon Aug 15 00:49:50 2022 +0300
>
>     loader: zfs reader should only store devdesc in f_devdata
>
>     Use d_opendata for device specific data.
>
>     PR:             265825
>     Reviewed by:    imp
>     Differential Revision: https://reviews.freebsd.org/D36202
>
> is the commit you want to have in your tree.
>
I needed the system back, since it ran some critical applications.
But I split the zfs-mirror and only reused one disk.
Now see if I can find the time to verify Toomas's fix.

Problem is also that the system itself does no longer boot.
But "Idwer Vollering " suggested ripping the
/boot/loader from 5th of Aug. So I can atleast boot into multi user,
and rebuild.

Probably next weekend.

Thanx,
--WjW
> Warner
>
> On Mon, Aug 15, 2022 at 6:23 AM Willem Jan Withagen  
> wrote:
>
>     Hi,
>
>     I tried upgrading a 14.0-CURRENT system from somewhere Dec 2021,
>     to the
>     most recent state.
>     So I build everything and installed the things...
>
>     Reboot and I end up in BTX....
>     Oke, so I perhaps should also update pmbr and gptzfsboot.
>     Booted from stick, and update...
>
>     Still I end up in BTX.
>
>     So get out the guns:
>     Downloaded the latest snapshot, and even there I do end up in BTX
>     once I have installed the system.
>     The Stick does boot the mem-stcik into EFI, and lets me install the
>     system. But upon reboot I again endup in BTX.
>
>     So i anybody out there willing to help me figure out what is wrong
>     here.
>     I can sent you a foto of the BTX screen.
>
>     System specs:
>          ASUS M5A97 PLUS
>          AMD FX-8370 Eight-Core Processor
>          24Gbyte Ram
>          1 HD (rust) seagate ST3250318AS 250G
>              met auto-install ZFS stripe, 8G swap, BIOS+UEFI
>
>     Thanx,
>     --WjW
>
>     BTW: I now installed 13.1-RELASE on another disk, and that (just)
>     works
>
>

--------------h0NSuhHrea0OgaNv0LHnpMUr
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 15-8-2022 22:11, Warner Losh wrote:

    

    

      
      
This should be fixed now. 
        


        

        
commit d98de7440507aea1648c8f4bc302bf88c0eb9458

          Author: Toomas Soome <tsoome@FreeBSD.org>

          Date:   Mon Aug 15 00:49:50 2022 +0300

          

              loader: zfs reader should only store devdesc in f_devdata

          

              Use d_opendata for device specific data.

          

              PR:             265825

              Reviewed by:    imp

              Differential Revision:  https://reviews.freebsd.org/D36202

        

        


        

        
is the commit you want to have in your tree.

        


        

      

    

    I needed the system back, since it ran some critical applications.

    But I split the zfs-mirror and only reused one disk.

    Now see if I can find the time to verify Toomas's fix.

    

    Problem is also that the system itself does no longer boot.

    But "Idwer Vollering <vidwer@gmail.com>" suggested ripping the
    

    /boot/loader from 5th of Aug. So I can atleast boot into multi user,

    and rebuild.

    

    Probably next weekend.

    

    Thanx,

    --WjW

    

      

        
Warner

      

      

      

        
On Mon, Aug 15, 2022 at 6:23
          AM Willem Jan Withagen <wjw@digiware.nl>
          wrote:

        

        
Hi,

          

          I tried upgrading a 14.0-CURRENT system from somewhere Dec
          2021, to the 

          most recent state.

          So I build everything and installed the things...

          

          Reboot and I end up in BTX....

          Oke, so I perhaps should also update pmbr and gptzfsboot.

          Booted from stick, and update...

          

          Still I end up in BTX.

          

          So get out the guns:

          Downloaded the latest snapshot, and even there I do end up in
          BTX

          once I have installed the system.

          The Stick does boot the mem-stcik into EFI, and lets me
          install the

          system. But upon reboot I again endup in BTX.

          

          So i anybody out there willing to help me figure out what is
          wrong here.

          I can sent you a foto of the BTX screen.

          

          System specs:

               ASUS M5A97 PLUS

               AMD FX-8370 Eight-Core Processor

               24Gbyte Ram

               1 HD (rust) seagate ST3250318AS 250G

                   met auto-install ZFS stripe, 8G swap, BIOS+UEFI

          

          Thanx,

          --WjW

          

          BTW: I now installed 13.1-RELASE on another disk, and that
          (just) works

          

          

        

      

    

    

  


--------------h0NSuhHrea0OgaNv0LHnpMUr--

From nobody Mon Aug 15 21:10:39 2022
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 4M66Q15w1rz4YxM5
	for ; Mon, 15 Aug 2022 21:10:49 +0000 (UTC)
	(envelope-from herbert@gojira.at)
Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-384) client-digest SHA384)
	(Client CN "mail.bsd4all.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M66Q03pXDz3bPK
	for ; Mon, 15 Aug 2022 21:10:48 +0000 (UTC)
	(envelope-from herbert@gojira.at)
Date: Mon, 15 Aug 2022 23:10:39 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at;
	s=mail202005; t=1660597840;
	bh=xBADlVygtXM0E1+pegs8PFVwlZZI4VRm9V5wwQrMps8=;
	h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type;
	b=bw825h1wKbLCbV3/BJ3PrlPbXN9tcVBEyBXpcts64SIMM1z3IiZUb7eimqP32+eSy
	 Alq5JgqJ2Bp7sEBu6HVo9jUw6i3287hUw2IqZ6fge3yJUcHgdWCRceCoUX5XpvPCNI
	 EScM/rRvXD4Kzg+/eOu3makndPZY40fV66Y+4VOOhVkRtBxjdKGtCDf7JVrVzTL1xB
	 /t1cDUQMlJBSbUE2Odw1o0RYrHp82LVN3Hfrcu319uye4hrgBQC8NP+yOGPqLE9bSu
	 bDM+fGTZcChxpJD0TE3+Ew6eBEgh8s75ACEyO7Fh+DlEeTU030R2rCXpH4hCdO70nI
	 F6pA2otqjhF6Q==
Message-ID: <87o7wlqkkw.wl-herbert@gojira.at>
From: "Herbert J. Skuhra" 
To: current@freebsd.org
Subject: Re: Recent 14.0-CURRENT(s) crash in BTX whilest booting
In-Reply-To: 
References: <5d898904-e58a-d205-dd67-0716628d1fd0@digiware.nl>
	
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/29.0 Mule/6.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 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Rspamd-Queue-Id: 4M66Q03pXDz3bPK
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gojira.at header.s=mail202005 header.b=bw825h1w;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at
X-Spamd-Result: default: False [-2.50 / 15.00];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20];
	R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_ZERO(0.00)[0];
	DKIM_TRACE(0.00)[gojira.at:+];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[gojira.at];
	FROM_HAS_DN(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 15 Aug 2022 22:11:59 +0200, Warner Losh wrote:
> 
> This should be fixed now.
> 
> commit d98de7440507aea1648c8f4bc302bf88c0eb9458
> Author: Toomas Soome 
> Date:   Mon Aug 15 00:49:50 2022 +0300
> 
>     loader: zfs reader should only store devdesc in f_devdata
> 
>     Use d_opendata for device specific data.
> 
>     PR:             265825
>     Reviewed by:    imp
>     Differential Revision:  https://reviews.freebsd.org/D36202
> 
> is the commit you want to have in your tree.
> 
> Warner

My 14.0-CURRENT BE boots again!

Thanks.

--
Herbert

From nobody Tue Aug 16 00:02:19 2022
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 4M6BD562LGz4ZN8J
	for ; Tue, 16 Aug 2022 00:02:29 +0000 (UTC)
	(envelope-from ambrisko@ambrisko.com)
Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91])
	by mx1.freebsd.org (Postfix) with ESMTP id 4M6BD44wMTz3tpk;
	Tue, 16 Aug 2022 00:02:28 +0000 (UTC)
	(envelope-from ambrisko@ambrisko.com)
IronPort-SDR: 3onHuv6eUry9zBNV3hd1Lkp5OqwhMosgtijUlaQXQsuZNooOIR6pFOY7DOWFOgSfP6/bCJrnuG
 1GKP6JrLXHaL0s7/yqZhRiLZlvKfdYfbc=
X-Ambrisko-Me: Yes
IronPort-Data: A9a23:ThZtyKmnt+uuWuQPaclbLoXo5gyaJkRdPkR7XQ2eYbSJt1+Wr1Gzt
 xJLWWvQOqncZGCnfdxyady+9RkA7ZCBx981T1NtrS00QX8b8sCt6fZ1jqvT04J+CuWZESqL1
 yiSAzX5BJhcokX0/39BD5C6xZVC/fDRLlbDIL6cUsxBbVcMpBYJ0XqPqcZg6mJbqYTR7ze2h
 D/Hi5a31GlJe9JDGjl8B6qr8HuDtRlp0d8SlgRWiftj5Dcym5SJZX62yHzYEpf2fmVUNrbSq
 +frzbel83nf9hNrA9aviLfgcUpMSbnXVeSMoiMHAe773EgE/2pouko4HKJ0hUN/gjCDhdFqy
 9JlvJm6UwYyPaqKk+MYO/VdO3wibPIWoNcrJlD666R/1XbufWHhzv91AGk5IJYY+6BwG24m3
 eYdAD4XYx2JnO7wx6i0IsF3j8EtKMDtP44Fkn5lxDDdS/0hRPjrTb/H6NVD0HI7m9pUEPDCT
 8QDZDdldxiGZAdAUmr7orpWcPyAnXTlbTBC8hScoKAt4nPQy0p6172FDTYcQfTSLe09o6pSj
 juuE73RDk5IOdqB5yCC937w1ObDkTmhAdAbEbei9+Vph3Waw2YJCQYVUh2wpvzg0hyyXNdWK
 ko1/CsyrPhvrBX6EoGlBxDo8mSZuhM8WsZLF7Fo4g+61aeJsR2SAXIJT2AdZYV+5tM2XzEjy
 nSAg8jtWW50qLSQRH/EruWUoDq+NDI7N2gHYSNYHwIJ78O5+dM6ixjVT81gF4a8i9fvGCrzx
 HaBqy1n3+cfissC1qOa+1HbgmLx/sGYElZtvgiOBzCr9AJ0YoKhdreE01mD4KYSNpudQ3mAo
 GMAx5qU4tcRAMzfjyeKWugMQu2kvq7XLD3GjFdzNJA97DDxqWW7dIVd7TwidkdkNsEIJW3gb
 EPJ41oD5ZlPMWGsZKsxaoe7EcUxzq+mHtPgD6iGYt1La5l3VQmG4CA+OBbJjjy1yBAhwfMlJ
 JOWUcewFnJLW61owQ2/S/oZzbJ2lDs1wnneRMyjwhn7g6CSYmWZFeUMPFeUNLhr966evgjPq
 ZBWMsGQyg5cV6v1ZSyOqdwfKlUDLH4aA5HqqpwKLrfSflI+QGxxWeXMxb4BepB+m/UHn+jFy
 XixR0tExQetnnbAMwiLNihuZb6HsUyTdp7n0fjA5WqV5kU=
IronPort-HdrOrdr: A9a23:wM5jP65u8l+ynnjueAPXwMjXdLJyesId70hD6qm+c31om+ij5q
 eTdZUgpHvJYVkqNE3I9eruBEDEewK7yXcX2/h1AV7BZniEhILAFugLhubfKn/bak/DH4VmtZ
 uIHZIRNDXBZ2IRsfrH
Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2])
  by ironport2.ambrisko.com with ESMTP; 15 Aug 2022 15:52:22 -0700
Received: from ambrisko.com (localhost [127.0.0.1])
	by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 27G02Jc1023580
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 15 Aug 2022 17:02:20 -0700 (PDT)
	(envelope-from ambrisko@ambrisko.com)
X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com
Received: (from ambrisko@localhost)
	by ambrisko.com (8.17.1/8.17.1/Submit) id 27G02JJt023579;
	Mon, 15 Aug 2022 17:02:19 -0700 (PDT)
	(envelope-from ambrisko)
Date: Mon, 15 Aug 2022 17:02:19 -0700
From: Doug Ambrisko 
To: Dan Mahoney 
Cc: Ruslan Makhmatkhanov ,
        "samflanker@gmail.com" ,
        freebsd-current@freebsd.org
Subject: Re: MegaCLI port is ports-only -- how would you deploy it?
Message-ID: 
References: <1615CF76-EE45-4D11-8102-EA441E845E65@gushi.org>
 <635211659622624@mail.yandex.ru>
 
 <493ED6A6-A38F-47B1-B534-9F5CB14DB087@gushi.org>
 
 <1578B277-8FB1-4EAB-ACDB-8ACE6E999857@gushi.org>
 
 <9EC7D5D4-0DD2-4946-9C5F-ADB2B39B73F1@gushi.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-Rspamd-Queue-Id: 4M6BD44wMTz3tpk
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com
X-Spamd-Result: default: False [-1.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_NO_TLS_LAST(0.10)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US];
	R_DKIM_NA(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[ambrisko];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	HAS_XAW(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[ambrisko.com];
	FREEMAIL_CC(0.00)[freebsd.org,gmail.com]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Aug 13, 2022 at 10:41:33PM -0400, Dan Mahoney wrote:
| 
| 
| > On Aug 12, 2022, at 12:35, Doug Ambrisko  wrote:
| > 
| > On Fri, Aug 12, 2022 at 12:32:56PM -0400, Dan Mahoney wrote:
| > | 
| > | 
| > | > On Aug 12, 2022, at 12:31, Doug Ambrisko  wrote:
| > | > 
| > | > On Fri, Aug 12, 2022 at 12:21:36PM -0400, Dan Mahoney wrote:
| > | > | 
| > | > | > On Aug 8, 2022, at 16:45, Doug Ambrisko  wrote:
| > | > | > 
| > | > | > On Mon, Aug 08, 2022 at 04:10:10PM -0400, Dan Mahoney wrote:
| > | > | > | 
| > | > | > | 
| > | > | > | > On Aug 8, 2022, at 15:57, Doug Ambrisko  wrote:
| > | > | > | > 
| > | > | > | > On Thu, Aug 04, 2022 at 05:22:29PM +0300, Ruslan Makhmatkhanov wrote:
| > | > | > | > |    03.08.2022, 02:07, "Dan Mahoney" :
| > | > | > | > |      Hey there all,
| > | > | > | > |      At the dayjob we have a fleet of Dell Poweredge servers that can use
| > | > | > | > |      either mptsas or mrsas -- if you use mptsas, you use mptutil (in
| > | > | > | > |      base) to check the state of the card.
| > | > | > | > |      If you use mrsas, you need megacli, which is only in ports, and the
| > | > | > | > |      port hasn't translated to pkg probably because of license
| > | > | > | > |      restrictions. ( _LICENSE_RESTRICTED = delete-package
| > | > | > | > |      delete-distfiles), but the license listed is just "megacli".
| > | > | > | > |      * We want to deploy a cron job to periodically check the raid status
| > | > | > | > |      (we're writing a wrapper, also having it check mfiutil, zpool, etc).
| > | > | > | > |      * We do not want to install and manage a whole ports tree on every
| > | > | > | > |      machine in our fleet, just to install a raid utlity.
| > | > | > | > |      Option A:
| > | > | > | > |      Make a local package somehow.
| > | > | > | > |      The port just downloads a static binary, there's nothing to build
| > | > | > | > |      here, but we want to do this the "right" way. Is there some way to
| > | > | > | > |      have pkg deploy a single local package for this that will, for
| > | > | > | > |      example, report the right package ownership, without moving every
| > | > | > | > |      other package to our poudriere install (we're just using base
| > | > | > | > |      packages, we keep poudriere around for testing in case we need to
| > | > | > | > |      hot-patch something).
| > | > | > | > |      For what it's worth, we use puppet for config management, so pushing
| > | > | > | > |      out the static binary is not the worst answer, but it also feels
| > | > | > | > |      "dirty".
| > | > | > | > |      Option B:
| > | > | > | > |      Figure out how to fix the license. I have no idea what this would
| > | > | > | > |      involve.
| > | > | > | > |      Option C:
| > | > | > | > |      Also, apparently MegaCLI is no longer maintained (replaced by
| > | > | > | > |      StorCLI), but there's no port for StorCLI, and...there are multiple
| > | > | > | > |      raid-card specific versions? Jeez.
| > | > | > | > |      Feels even more dirty.
| > | > | > | > |      [1]https://support.siliconmechanics.com/portal/en/kb/articles/storcl
| > | > | > | > |      i-for-freebsd-and-other-operating-systems
| > | > | > | > |      Ideas welcome?
| > | > | > | > |      -Dan Mahoney
| > | > | > | > 
| > | > | > | > Although the path to get to StorCli goes through various cards the
| > | > | > | > latest greatest seem to work on all earlier cards.  It works on
| > | > | > | > HBAs and not just RAID cards.  At work I did a Linux/FreeBSD
| > | > | > | > POC for FW management and found the FreeBSD version could flash the HBA
| > | > | > | > and drive FW.  I've moved to StorCli from MegaCli.  I would suggest
| > | > | > | > we drop the MegaCli port and move to StorCli.
| > | > | > | > 
| > | > | > | > I have code to make mfiutil into mrsasutil and added the MFI ioctl
| > | > | > | > handler to mrsas.  I'm not sure how much value that has.  I don't
| > | > | > | > deal with supporting FreeBSD and RAID much anymore.  If interested
| > | > | > | > I could send patches.
| > | > | > | 
| > | > | > | This feels like it should be in base, regardless.  Just *something* to 
| > | > | > | query the raid status and health, even if it doesn't ring all the bells 
| > | > | > | of StorCLI.
| > | > | > | 
| > | > | > | Right now, you can do this with the older mfi, but not the newer mrsas, 
| > | > | > | which performs better in some cases, which leaves an admin with a 
| > | > | > | dilemma: better reliability, or better manageability.
| > | > | > | 
| > | > | > | I also feel like this could be added to a minor release (i.e. a 
| > | > | > | 12.3 --> 12.4 or a 13.0 --> 13.1), but obviously that decision is above me.
| > | > | > 
| > | > | > This is based of -current.  I haven't tested it recently:
| > | > | > 	https://people.freebsd.org/~ambrisko/git.mrsas_support_in_mfiutil.patch
| > | > | > 
| > | > | > Please give it a try.  You will need a new kernel built and booted to
| > | > | > provide the needed ioctl support.  It should be close to committable.
| > | > | 
| > | > | Doug,
| > | > | 
| > | > | I'm trying this out on 12.x and 13.x just for funsies, but given the 
| > | > | release schedule, it's unlikely that there'll be a 12.4 or a 13.2 that 
| > | > | this would make it into.  Regardless, I've opened a bug report to get 
| > | > | this added *somewhere* which may cause other people to try it out and test.
| > | > 
| > | > I'd have to put in -current first then look at MFC later on.  If looks
| > | > good for you then I'll put it up for review.  I just don't use this
| > | > stuff day to day anymore.
| > | 
| > | Yeah, most of our dayjob work is running critical DNS infrastructure, so 
| > | there's not a lot of -current there, but I can get permission to play 
| > | with it on a spare system.
| > 
| > It should apply to earlier releases, since there hasn't been a lot of
| > changes in this area.  So you can try that if that is easier.  I did
| > this code a long time ago probably in 10.X and have been moving it
| > forward.
| 
| I've confirmed that it shows drive status and array status on my R430 
| running FreeBSD 14.0-CURRENT #0 main-n257330-88951aaaee7-dirty in mrsas mode.
 
Along the way, I dropped:
diff --git a/usr.sbin/mfiutil/Makefile b/usr.sbin/mfiutil/Makefile
index dc6f3e48159..139e31d6c41 100644
--- a/usr.sbin/mfiutil/Makefile
+++ b/usr.sbin/mfiutil/Makefile
@@ -1,10 +1,12 @@
 # $FreeBSD$
 PROG=	mfiutil
+LINKS=	${BINDIR}/mfiutil ${BINDIR}/mrsasutil
 
 SRCS=	mfiutil.c mfi_bbu.c mfi_cmd.c mfi_config.c mfi_drive.c mfi_evt.c \
 	mfi_flash.c mfi_patrol.c mfi_show.c mfi_volume.c mfi_foreign.c \
 	mfi_properties.c
 MAN8=	mfiutil.8
+MLINKS=	mfiutil.8 mrsasutil.8
 
 CFLAGS.gcc+= -fno-builtin-strftime

That should make the links for mrsasutil.
 
| As currently built, the kernel makefiles do not install it as mrsasutil, 
| and this is a manual copy.  I think that would need to be fixed to make it 
| mergeable, but I think it should happen.
| 
| I've opened this PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265794
| 
| At this point, the ports- list is probably off-topic for this, but this 
| conversation should definitely continue.

Switched to -current.

Doug A.

From nobody Tue Aug 16 03:01:42 2022
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 4M6GFR6pzCz4Z6rR
	for ; Tue, 16 Aug 2022 03:03:55 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M6GFR6L3Qz3G9S;
	Tue, 16 Aug 2022 03:03:55 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660619035;
	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=OYCgBaENYnnvAG3U7a0kieuAkcNSFqKDza4GwPi9+4c=;
	b=eWvPSH9WtMQgsyJ51YsYiUTYaXBHRfkJdoXs4ZwfWRdbM+Z70OdhXWzAbYWISioP81OlkD
	sb2WihBto9xrSRtwyZ4VH4SxdWEoO3+7X4n2EoJyex2+USqRKWoykoLjIGg94DG9VL22lH
	23u3lxU/lxSfKqDQ6jz/GFK85pjmvIJkepedQSar8Y722+15F9MUJGYTroKm0dKdV+sP3b
	NHgxaMi8YWqdZA+t9ZQ6TeqkW6cJWkk7OhzR6WvqigBpmIIVNezZzeSZLUltMqZ2P+u9Ge
	6HtxhNQBV08kuBKfxw8tPn1E1daPH8qwJkUyTOEqkNjOFj7ckWPLRiOgnpWOug==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:9836:f14e:7ef3:8577])
	(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: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M6GFR1TGSzmjm;
	Tue, 16 Aug 2022 03:03:54 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Tue, 16 Aug 2022 12:01:42 +0900 (JST)
Message-Id: <20220816.120142.317069615425604393.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura 
In-Reply-To: <20220814.063440.1883565953618972371.yasu@FreeBSD.org>
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
	<20220814.063440.1883565953618972371.yasu@FreeBSD.org>
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660619035;
	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=OYCgBaENYnnvAG3U7a0kieuAkcNSFqKDza4GwPi9+4c=;
	b=lfHID20c5oc95bcCV1W3omll6fxz54FNu4JrZERRCeBfHlwUKRHPrswJ6lCW4tObQC78zt
	I1xAhm7cloFs12V93ubhAoHIDfEOSP67ExjR6Pp3MP+XJtCXOqE+BByXzpUVGpSfhqXQyR
	BQU+vzliben/QrOSAjpmIUMjO05RHEcz/i2pkjF6Pbd8oXSPS2jXAhj+jYf3e3l3uZyON+
	cxN56PwKZ0syoa1y/qmT+wCWq+0OkQK543umnbWRol3G46uvgzV9G4oYtdf+QlHsVDLL41
	4DCFgWqviACeVZ1rvLT3sDrlTuuaySq1pg+wc2RWvQafWrHme3+4fcNU/bMl4w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660619035; a=rsa-sha256; cv=none;
	b=Dds2I10vgP0YXUKaAN+7GQFr70F0EHGqLnfWLYvLcRCwAaXtR9qAxJLIrKorpi8yJJXkrm
	yjSm6L8kBiQIYU5spGF0ViAPMBTkxIV04J5mJjvb7m0ovYoLJt+9qLbJakX7OManKnCFeB
	6U8B79pwKbIJVttOu21DPhSMNJMw0lMc6IsNCU8dRX1qYPj2tCw6pA4ncYqPhvkSAZTAyv
	IzPSJu60LYXIB/A9ltZnvLqodc6QVZX3gJz4oK4lagF3rUDaRxyz769TGvt5aJ92kGQJVm
	PSr8gaUiSHz4b/Cn+JpUMZX7JemWZwGSA2u0dHXSogqJ7IZkR5iDyi7A/87P+g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

From: Yasuhiro Kimura 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST)

> From: Yasuhiro Kimura 
> Subject: Updating EFI boot loader results in boot hangup
> Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)
> 
>> I made regular update of my 14-CURRENT amd64 system from
>> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
>> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
>> boot hangup as following.
>> 
>> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
>> 
>> If I restore previous loader file (that is, loader.efi of
>> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
>> system boots successfully.
> 
> I submitted the problem to FreeBSD Bugzilla.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825
> 
> Best Regards.

d98de744050 is committed. So I tested it with following steps.

1. Check out the commit.
2. cd /usr/src/stand
3. make
4. make install
5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd
6. shutdown -r now

And system boots successfully. But while efi loader is workding a lot
of messages are displayed as following.

https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png

---
Yasuhiro Kimura

From nobody Tue Aug 16 03:35:52 2022
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 4M6GyY0hzgz4ZBkJ
	for ; Tue, 16 Aug 2022 03:36:05 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M6GyX3Lydz3LW7
	for ; Tue, 16 Aug 2022 03:36:04 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe29.google.com with SMTP id q190so9000160vsb.7
        for ; Mon, 15 Aug 2022 20:36:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=n+oNGLO62xoBow10ODNwApg15ZmngD2IF7TnAB0HsUA=;
        b=PfwjW9G3gvjz8xwCo067TKzCex/rK9mm6nu37Ri9zgimaq40dhSCWrgrZgPsoqj2E7
         1KQQWbhmqJAd08JWXAr37ogxFJGyKWlRFiKAivnHncGfBff477dq+VD360AXeOJookpZ
         vT6ci4pXwyEmV6VxqyljtOHPgXJPsRJk9QFfZ2txBa57sUqmJkZT+hi51/IO1Q4S3Xzv
         CRbaBmnwnmBDGSnEslVS1ZZ8oBjljEZVlwLdTzkL0WgUjx1XmXVeuwrvteT/pQY0ou3h
         ukfanOeQ9Lv5pFKylVu9EVJ3ESknmp570xrPU02BflVKj60U+paxKMfkpjespW5u5s+y
         DDEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=n+oNGLO62xoBow10ODNwApg15ZmngD2IF7TnAB0HsUA=;
        b=MjBPtKG5yK6ilu/iBMYiuSXP5TKhWC9pXPj7O8k1pmwBLO7Vr8htKq5dyIUiE/6PUY
         ROJx7AwgvPrpHtF+B5W9v1MlRa3SXOH2YD8pvZUxSPbze4ksrKdvxz5OQQVpqlFCBasn
         ACBK7WfcY30WGv/P/N5la/zI3YbSBaN7KA29a6ThW8PTC7yj4I//FTycovdvEDIowLtj
         jcym+7MFwAFi4cm3tnjFxWrmlAvQdaHbfDHyUKKmNtO48OxXLB8Id+DTVZjXgjqNY4KA
         2szvqwffrz39XbWEwA37g4TvzvNyWHMcQINrH/WlIC7KzGWFU3F8Cxa+lSDBIEp00HyK
         sYTg==
X-Gm-Message-State: ACgBeo00qomBP8ueUSFpfQcfQAv1Gylkr5kJLPiplIGPI4JHwbJRbKUa
	PXM4LGhlmpOm6I0efs3KGwNz7B3R7cbTJCa7cvMHN2elNnI=
X-Google-Smtp-Source: AA6agR4KaEjgJLCg9cauwHeq7/qjr0V2Z6uqXYwBwJye2ASABcsJzU2+ElUKIL6nTTyk5mi2953fouHvrUfvKHOYv2s=
X-Received: by 2002:a67:ac45:0:b0:388:a1ff:7e89 with SMTP id
 n5-20020a67ac45000000b00388a1ff7e89mr8039050vsh.42.1660620963635; Mon, 15 Aug
 2022 20:36:03 -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: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
 <20220814.063440.1883565953618972371.yasu@FreeBSD.org> <20220816.120142.317069615425604393.yasu@FreeBSD.org>
In-Reply-To: <20220816.120142.317069615425604393.yasu@FreeBSD.org>
From: Warner Losh 
Date: Mon, 15 Aug 2022 21:35:52 -0600
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Yasuhiro Kimura 
Cc: FreeBSD Current 
Content-Type: multipart/alternative; boundary="000000000000a4f89805e6537251"
X-Rspamd-Queue-Id: 4M6GyX3Lydz3LW7
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=PfwjW9G3;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e29) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e29:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000a4f89805e6537251
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 15, 2022, 9:04 PM Yasuhiro Kimura  wrote:

> From: Yasuhiro Kimura 
> Subject: Re: Updating EFI boot loader results in boot hangup
> Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST)
>
> > From: Yasuhiro Kimura 
> > Subject: Updating EFI boot loader results in boot hangup
> > Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)
> >
> >> I made regular update of my 14-CURRENT amd64 system from
> >> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
> >> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
> >> boot hangup as following.
> >>
> >>
> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
> >>
> >> If I restore previous loader file (that is, loader.efi of
> >> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
> >> system boots successfully.
> >
> > I submitted the problem to FreeBSD Bugzilla.
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825
> >
> > Best Regards.
>
> d98de744050 is committed. So I tested it with following steps.
>
> 1. Check out the commit.
> 2. cd /usr/src/stand
> 3. make
> 4. make install
> 5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd
> 6. shutdown -r now
>
> And system boots successfully. But while efi loader is workding a lot
> of messages are displayed as following.
>
>
> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png


Would you be able to share camcontrol devlist output? Privately if need be.
And have any of these disks ever held ufs filesystems??

Warner


> ---
> Yasuhiro Kimura
>
>

--000000000000a4f89805e6537251
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Aug 15, 2022, 9:04 PM Yasuhiro Kimura <yasu@freebsd.org> wrote:
From: Yasuhiro Kimura <yasu@FreeBSD.org>=


Subject: Re: Updating EFI boot loader results in boot hangup

Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST)



> From: Yasuhiro Kimura <yasu@FreeBSD.org>

> Subject: Updating EFI boot loader results in boot hangup

> Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)

> 

>> I made regular update of my 14-CURRENT amd64 system from

>> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updat=
ed

>> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results =
in

>> boot hangup as following.

>> 

>> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-h=
angup.png

>> 

>> If I restore previous loader file (that is, loader.efi of

>> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), =
then

>> system boots successfully.

> 

> I submitted the problem to FreeBSD Bugzilla.

> 

> https://bugs.freebsd.org/b=
ugzilla/show_bug.cgi?id=3D265825

> 

> Best Regards.



d98de744050 is committed. So I tested it with following steps.



1. Check out the commit.

2. cd /usr/src/stand

3. make

4. make install

5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd

6. shutdown -r now



And system boots successfully. But while efi loader is workding a lot

of messages are displayed as following.



=
https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-load=
er-message.png

Would you be able to share camcontrol devlist output? Private=
ly if need be. And have any of these disks ever held ufs filesystems??

Warner=C2=A0



---

Yasuhiro Kimura






--000000000000a4f89805e6537251--

From nobody Tue Aug 16 03:53:20 2022
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 4M6HNV2zCfz4ZFHm
	for ; Tue, 16 Aug 2022 03:55:06 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M6HNT6dqvz3PqN;
	Tue, 16 Aug 2022 03:55:05 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660622105;
	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=LRxauszSmnXFJS2P+1zLO+40YhM6p4U3OsB9wZCjgVE=;
	b=COUWXFdiqkiaFAOVrn2DYSamaWby8O31emeTKtzS9enftG2zBz7ivAfRhDuhc44X32TCKp
	63H6KPX/rxw+iuKcHtQEZ7WLcoyUTdPmz27EFaFp5ny6ZYMNR2lTMLUEkcKqqSBd9265Gz
	OmYxWhDshwSGPAaGKt9c1CB2GyMhEJVd1QCTRJ42JO2kcir1FSNybuJ6oAU8HnHDCLN/LX
	snIn4h/VRrQWVRCzxPnPC3slkQAwNePkpoRNwEf/HztpJEnuYcpkCTrFYYW7dEbTTF47uJ
	bSjN6TcMitXy5EZPMe9El+lLYWZCJzT2IrBMaI7iWR1TpLU1L9T5AMIXD6jBIQ==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:9836:f14e:7ef3:8577])
	(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: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M6HNT1f8nzp4T;
	Tue, 16 Aug 2022 03:55:04 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Tue, 16 Aug 2022 12:53:20 +0900 (JST)
Message-Id: <20220816.125320.680364591806556157.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura 
In-Reply-To: 
References: <20220814.063440.1883565953618972371.yasu@FreeBSD.org>
	<20220816.120142.317069615425604393.yasu@FreeBSD.org>
	
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660622105;
	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=LRxauszSmnXFJS2P+1zLO+40YhM6p4U3OsB9wZCjgVE=;
	b=iOAhXmCSXN+P+8ev6FDaPDULMcYdmx8LL0CM9xR11lJRdkqQsKFFYZbO62QaqwqllI9tQw
	Izide2RO6bFYHDU2l88yETvBBRCB8ERNyGMV4KGdxpMdgtXCHmFJ5H0OlB7c+Yu7KYUmGY
	ju87rsj7QEm09rNe6J3HM9lrmTkw1sMTPfmV4HNiNT4jcdMw4+xKo+DYcScjvyv2rj/C+J
	cFJRtcfJSSW8GW0gyyUUh2XCYzqkM0Gzpg9B2SHf5Kx0MTqnyd7muoe+ueFPrOyOKB/W+X
	nr1yllQhKcJdgTCqS99IlrJ3DJCBuERvsWyTxwCELACMgigyRF8JgfilCJPNiQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660622105; a=rsa-sha256; cv=none;
	b=ebPK+dXSTJQsbbwDA5Ysi3xdpWojqTYKKT9voVKLRJFW27DuYzxo+QW97Htq2wgWfC1wPz
	LmH7u169QNtus1MXXe+M0MPjMMEmTzQSFyIntSMeUL5XzllMiG8EbhQ4ZHAFKD81EfrbMx
	6UXrnheqVVYCe7uIfYi6vIG9HVO0vsFbnldzcybvx3fNA5g1maf+oGKn761N46w7EUtKPD
	EsRPC9342v4/kBU1nL6voSCd0qh6IIPh59NOIl0jPmtlfcdUax6zbHdD6YkX3HOhk7YTkA
	DhOYOka95t0chJfTdKf6QHYHJgY5CagfjhxKTfm87vHrcKmEsr5z/JXEPhZVHw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

From: Warner Losh 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Mon, 15 Aug 2022 21:35:52 -0600

> Would you be able to share camcontrol devlist output? Privately if
> need be.

root@rolling-vm-freebsd1[1001]# camcontrol devlist
                at scbus0 target 0 lun 0 (pass0,ada0)
                  at scbus1 target 0 lun 0 (cd0,pass1)
root@rolling-vm-freebsd1[1002]# 

> And have any of these disks ever held ufs filesystems??

No. ada0 consists of ESP, swap and ZFS.

root@rolling-vm-freebsd1[1002]# gpart show ada0
=>       40  209715120  ada0  GPT  (100G)
         40     532480     1  efi  (260M)
     532520       2008        - free -  (1.0M)
     534528   67108864     2  freebsd-swap  (32G)
   67643392  142069760     3  freebsd-zfs  (68G)
  209713152       2008        - free -  (1.0M)

root@rolling-vm-freebsd1[1003]#

---
Yasuhiro Kimura

From nobody Tue Aug 16 09:49:18 2022
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 4M6RFQ5pM6z4YbF8
	for ; Tue, 16 Aug 2022 09:49:30 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M6RFQ5FrQz3wcQ
	for ; Tue, 16 Aug 2022 09:49:30 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660643370;
	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=ZW0NYASlTsVdTll/fOkyksKbjWoT0YCrimFpBo2fEI0=;
	b=MtMGs+FnTPIdreRQBLpKDr4V0rQsHeJUdJwIr4GbNJAS8Ea9YJr8bX3WYSk/OD25RqFP3n
	nfnRUC58QxlLOtw9YOsGw/9LPtWsvTo4Xb9kbV8In0YkXWrYe6x1CImtjeYPawQH+uCfKz
	0z8JytBHsqGyNFCcdTcSwhymP9F5lA+9HGY3W06dS6B5jnqD0qJ+4AMMwB7ulvqJvtj5og
	ojZBpexxBAIsEkCPdPgKsEsSDn4ClTAL3tVL5MWVSXVIR3sC83Vy2+ZY++x5iFaDvaDmeP
	V3YVrpH/08C5faHYmvXFdd4fe/3QvMVYDo+QnCyjKM6vk0glpwM84Ah+6fRuww==
Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M6RFQ4272zvPv
	for ; Tue, 16 Aug 2022 09:49:30 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f178.google.com with SMTP id t64so4888150vkb.12
        for ; Tue, 16 Aug 2022 02:49:30 -0700 (PDT)
X-Gm-Message-State: ACgBeo2+su4BXHCaUYhG8BwX29JLAAfmj9wtex/RB23BsakO+XxtlMmo
	4DvNN0Sft2DIFny95Y564UyuWn4J6s+NLRIxzv4=
X-Google-Smtp-Source: AA6agR6Lhd3gVNp6BM7LhBpwda06bC7BrzoCjW3GU7R6dZVhd2zOnnsF2Ky/jjyb4hKfywm+x5GsrV24X9yQ9EUVYvE=
X-Received: by 2002:a1f:188a:0:b0:377:226b:7cd6 with SMTP id
 132-20020a1f188a000000b00377226b7cd6mr8177328vky.24.1660643369904; Tue, 16
 Aug 2022 02:49:29 -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: Nuno Teixeira 
Date: Tue, 16 Aug 2022 10:49:18 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: 24.3. Updating Bootcode
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000002970cb05e658aa03"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660643370;
	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=ZW0NYASlTsVdTll/fOkyksKbjWoT0YCrimFpBo2fEI0=;
	b=u2Xxwgc1eiJkyjUYa4oYzJ5yqMHIQ0oauPPTGoZJsSpESziRP6qHpGyCUVNTaDCKGgWUrE
	9hE/SN+V+PaXaHoOBtwggSS0qNhLUDOHoFVqgXuBNDFENQonQEpcmzdMz4a3SAAkcHTjZR
	HYhH5Zot0VSoBrch1PISwBnloulBxDfBznU7fb8gYXaMefjVA+uBuX4XfaWuyDcvQ6iy6W
	KkvGxsaW77D9pnvRfH/KuaB5wmlaDW+MwemuruRK7j9lDmWEtjo8YfZmJjE6JqMFjI3S6L
	PQC5RtOWMl6sk++rBWvnivfD1wt23EQ7aynIebO1Cs7rAYHCakOzsRdDwVKQPA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660643370; a=rsa-sha256; cv=none;
	b=WQNavKmqCRR2u/4DYqbnfuKt7ilMeXrnw2iSI5AH1n0xmNzNkzy7XjlpnjbcI16BDEdv8/
	h77b7d1jMewPR/QN0qwzRktRdgIW9EHn0le0vItZzPEs0TvoYomF0CVJxMx0y6fChb8LN8
	yDitMleq9nGMEuHBO/HaElmMpFD6Cw+mhlOWGSIjGfTC+bKDiXo2stVKhD9ef3aD3Pdrde
	rxZakm62/XLEYCuPfktkdiB3vjrfIwdLfqUrWoa67XKKx1LRTnOiYoVGh2X6cw1CLUT5DY
	rkfOzY1gdWiX/OVGpXKXW/kXHm0zV2u+pU35QhfSc/Ns5eu4COworfCzoFuVig==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000002970cb05e658aa03
Content-Type: text/plain; charset="UTF-8"

Hello all,

With so much discussion about updating boot, I feel confused about the
correct procedure of doing it.

Like being said there are a "24.3. Updating Bootcode" in Handbook (WIP)
that points to some important manuals.

There are 3 places where boot loader are:

 ESP (EFI System Partition):
1 - (/boot/efi)/efi/boot/bootXXX.efi (default location)
2 - (/boot/efi)/efi/freebsd/loader.efi (FreeBSD reserved area)
Operating System:
3 - /boot/loader.efi

For what I've read we should:
 - backup: `cp /boot/efi/efi/boot/bootXXX.efi
/boot/efi/efi/boot/bootXXX.efi.bkp`
 - update: `cp /boot/loader.efi /boot/efi/efi/boot/bootXXX.efi`

In this example we have a /boot/efi mount by the system, "/dev/XXXpN on
/boot/efi (msdosfs, local)".

What about (/boot/efi)/efi/freebsd/loader.efi (reserved area)? Is necessary
to backup and update it too?

Thanks,

-- 
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000002970cb05e658aa03
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello all,

With so much disc=
ussion about updating boot, I feel confused about the correct procedure of =
doing it.

Like being said there are a "24.3. =
Updating Bootcode" in Handbook (WIP) that points to some important man=
uals.

There are 3 places where boot loader are=
:

=C2=A0ESP (EFI System Partition):
1 - (/boot/efi)=
/efi/boot/bootXXX.efi (default location)
2 - (/boot/efi)/efi/free=
bsd/loader.efi (FreeBSD reserved area)
Operating System:
3 - /boot/loader.efi

For what I've read =
we should:
=C2=A0- backup: `cp /boot/efi/efi/boot/bootXXX.efi /bo=
ot/efi/efi/boot/bootXXX.efi.bkp`
=C2=A0- update: `cp /boot/loader=
.efi /boot/efi/efi/boot/bootXXX.efi`

	
In this =
example we have a /boot/efi mount by the system, "/dev/XXXpN on /boot/=
efi (msdosfs, local)".

What about (/boot/efi)=
/efi/freebsd/loader.efi (reserved area)? Is necessary to backup and update =
it too?

Thanks,

-- 
Nuno Teixeira
FreeBSD=
 Committer (ports)


--0000000000002970cb05e658aa03--

From nobody Tue Aug 16 11:10:15 2022
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 4M6T2k05lxz4YnNV
	for ; Tue, 16 Aug 2022 11:10:22 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from pv50p00im-ztbu10021601.me.com (pv50p00im-ztbu10021601.me.com [17.58.6.57])
	(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 4M6T2j1VvMz45BV
	for ; Tue, 16 Aug 2022 11:10:21 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1660648219; bh=DAp+LtXepJVNt5H3QiGqjUdpoGZm/RgVVOAKH9bsTyQ=;
	h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To;
	b=RsgUgZyVuFpcWOKiSeyV8vInaUl9b2kA1CQF/cMwTvoO4cvjSvpZlzRd4SWVIO98m
	 cZm57XCRFnp+h0AgoDi3/s4leHAl07JaS1YTKW8eSpgKDwzd2xW5Qx4q+8UlIiFgrc
	 HUmgnKYukvgmU+2vf33oRy3tTpGBY//TDvx+kpIOm/ZPVVbeX3QvKKJWFxhdh0g49v
	 WBgMsEtxInJwFgS/QnCIHgluzTD9JoQjgPbOXoOnzIwPLFtCKh3N/TTdzE1tYp8tLZ
	 CbudTuibniwyudkGrr6qR/JljfMQPWGCgYNM7HetJ5TiIYMyhaTqvKTL+ryQLX3TCN
	 FoEDNz4Gb6JBg==
Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10])
	by pv50p00im-ztbu10021601.me.com (Postfix) with ESMTPSA id 52FC1804FA;
	Tue, 16 Aug 2022 11:10:18 +0000 (UTC)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: 24.3. Updating Bootcode
From: Toomas Soome 
In-Reply-To: 
Date: Tue, 16 Aug 2022 14:10:15 +0300
Cc: FreeBSD CURRENT 
Content-Transfer-Encoding: quoted-printable
Message-Id: <62B26DE1-0E26-40BA-8647-E591E9ACEB7A@me.com>
References: 
To: Nuno Teixeira 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Proofpoint-ORIG-GUID: KNOySkxaJhx1RJOJDDa2mHq2Yf8-kZdj
X-Proofpoint-GUID: KNOySkxaJhx1RJOJDDa2mHq2Yf8-kZdj
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.572,17.11.64.514.0000000_definitions?=
 =?UTF-8?Q?=3D2020-02-14=5F11:2020-02-14=5F02,2020-02-14=5F11,2022-02-23?=
 =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 spamscore=0 bulkscore=0
 mlxscore=0 phishscore=0 suspectscore=0 malwarescore=0 adultscore=0
 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2206140000 definitions=main-2208160042
X-Rspamd-Queue-Id: 4M6T2j1VvMz45BV
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=RsgUgZyV;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.57 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-3.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16];
	R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.57:from];
	MIME_GOOD(-0.10)[text/plain];
	FREEFALL_USER(0.00)[tsoome];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[17.58.6.57:from];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[me.com:+];
	TO_DN_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[me.com];
	DWL_DNSWL_NONE(0.00)[me.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[me.com];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 16. Aug 2022, at 12:49, Nuno Teixeira  wrote:
>=20
> Hello all,
>=20
> With so much discussion about updating boot, I feel confused about the =
correct procedure of doing it.
>=20
> Like being said there are a "24.3. Updating Bootcode" in Handbook =
(WIP) that points to some important manuals.
>=20
> There are 3 places where boot loader are:
>=20
>  ESP (EFI System Partition):
> 1 - (/boot/efi)/efi/boot/bootXXX.efi (default location)
> 2 - (/boot/efi)/efi/freebsd/loader.efi (FreeBSD reserved area)
> Operating System:
> 3 - /boot/loader.efi
>=20
> For what I've read we should:
>  - backup: `cp /boot/efi/efi/boot/bootXXX.efi =
/boot/efi/efi/boot/bootXXX.efi.bkp`
>  - update: `cp /boot/loader.efi /boot/efi/efi/boot/bootXXX.efi`
>=20
> In this example we have a /boot/efi mount by the system, "/dev/XXXpN =
on /boot/efi (msdosfs, local)".
>=20
> What about (/boot/efi)/efi/freebsd/loader.efi (reserved area)? Is =
necessary to backup and update it too?
>=20

Hi!

I guess we need to expain a bit. EFI System Partition (ESP from now on, =
 for mountpoint), can store both EFI boot programs and EFI =
applications (diagnostics, firmware update etc). This is the reason, the =
ESP size is not specified in UEFI specification.

EFI Boot program may be stored on default path =
/efi/boot/bootx64.efi (amd64), /efi/boot/bootia32.efi (i386 =
32-bit), /efi/boot/bootaarch64.efi for AARCH64 etc. It is default =
for case there is no UEFI Boot Manager set up for this media (like =
installation media on usb stick or cdrom, but also most systems support =
it with hdd).

Default path obviously does not cope with multi boot setups.

For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page =
499) is suggesting to use structure like:

/efi//=E2=80=A6

And to use this suggestion, it means the UEFI Boot Manager needs to be =
configured (see efibootmgr(8)).

Therefore, once you have set up OS specific setup, there is no use for =
default (/efi/boot/=E2=80=A6) and you need to update one or =
another, but not both.

hope this helps,
toomas


From nobody Tue Aug 16 12:01:40 2022
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 4M6VB86pLTz4YvpR
	for ; Tue, 16 Aug 2022 12:01:52 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M6VB8652Rz4CYL
	for ; Tue, 16 Aug 2022 12:01:52 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660651312;
	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=S9A2Bx1EBYIJAFb7qhHJrNSvh1XHM/SSazoHlC3TKvM=;
	b=J6A6AOpwg7A7diLgBUwzCag7pWKnN7LoB5o8w6m0Fl9DxWCebuNXYuNfIO/uGAyEtDBR9r
	qjMHzTCQyYLxUlgYQNpHP0T9vayW/6etmYH0+i8jfcxheMuA5986oBfNjHHnVB0IRJSixP
	olFLRMU+smXrLrOaRPdFEtHr7DmnSQ+IZyrXRJReR84JgMaaYpKXf/tFoI4ps4aM///1R4
	RufQ5MU6E9q7qpuKX5eOf4KkuLr0tOW6Ckv5mkTqhlL+bPW7ur73JGmm71eXmzoIrOdzeu
	qbz5fH3KzM+XXdENSqJg+LPZEilEyKJDt5Iv16+S4l3tvQiYwB8cs/FpH/XOGw==
Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M6VB850pFzxhj
	for ; Tue, 16 Aug 2022 12:01:52 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f169.google.com with SMTP id bj43so5037985vkb.4
        for ; Tue, 16 Aug 2022 05:01:52 -0700 (PDT)
X-Gm-Message-State: ACgBeo3/oGW+GuxichLBSGV/LkMnP94KQsBlfTTdxVA8lCzi9+2s4ZcY
	HNaq0ZHB0WDzS5m+P06ueoyoW3n3T9cJShlCae0=
X-Google-Smtp-Source: AA6agR6dfO6aOeW9+Rw+cpDCRCvkoTF57c4TNuOe/Us22MEADRcE9c63PwPnw2YZTtTtMuRThox3/bKbi9FR4Ilx1Bo=
X-Received: by 2002:a1f:41c8:0:b0:377:1352:8f9d with SMTP id
 o191-20020a1f41c8000000b0037713528f9dmr8405762vka.25.1660651312137; Tue, 16
 Aug 2022 05:01:52 -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: 
 <62B26DE1-0E26-40BA-8647-E591E9ACEB7A@me.com>
In-Reply-To: <62B26DE1-0E26-40BA-8647-E591E9ACEB7A@me.com>
From: Nuno Teixeira 
Date: Tue, 16 Aug 2022 13:01:40 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: 24.3. Updating Bootcode
To: Toomas Soome 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000008e4b9c05e65a83ae"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660651312;
	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=S9A2Bx1EBYIJAFb7qhHJrNSvh1XHM/SSazoHlC3TKvM=;
	b=kDrfLNQ8YvyyChfHgYGcnn6sQkYbuKssdEsXT4A8DMxhiO9q4mm4z4VuORpjG35Hkc9vcD
	72p6SkH60QJ/3IvhuYlniTHjtno3heZe4ktJCJvF4Uu5P/1cL91jpr+T7V2C3b09TtOT0y
	OrA3TK0zyU3bPvtpG+0nSzuxRCrhwYlJMzms0no5hrPjA2V6o0xmPPubEx0NsfxXfKbyj7
	HQfbnNDayPiGvLag7SgGPtOn0GI+p58sINu0FX705kItNDBLC22XYey+LHbPZ3szxizqpV
	wO9r2ByCu9VcZPir4hcuiEdbiZeNK/kyx996bDgNveMYvrBLhYtemEHPWlZg0A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660651312; a=rsa-sha256; cv=none;
	b=sHjCwWTV+O2isdotDxjDuu02PVZk/1Rebw/otU3obPu6KtqTubun+K2xw4Np5MV9Ros21+
	afW0dsuqhdyy/mMJy2R0C38GQ8QIc+HJwBTHy+Kase7XqWPdNx0ydZ6FG8HRd+IdoHlnyu
	UKTHxVkibcNGqlM9a9SKK067+gv8xjVAdZI8xChD7/lt0ymSYSFzo3je6kJvi3UHWVJf1Q
	ukHyB3lpTIrTSyYQI0n03JsXVXWXQmdTFzznWH+vMsp787EP/NdqAJhz5hIbk8bI4iyUnx
	7CnwjeYsU2E9uIrysueoK7BNJr+nqbNm7ncTYsLaaTAGTmIyoW8I7peug37vGg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000008e4b9c05e65a83ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Toomas,

For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page 499)
> is suggesting to use structure like:
>
> /efi//=E2=80=A6
>
> And to use this suggestion, it means the UEFI Boot Manager needs to be
> configured (see efibootmgr(8)).
>
> Therefore, once you have set up OS specific setup, there is no use for
> default (/efi/boot/=E2=80=A6) and you need to update one or another,=
 but not
> both.
>

FreeBSD have /efi/freebsd/... but it's not configured in efibootmgr:

efibootmgr -v:
---
BootOrder  : 0004, 0000, 2002, 2003, 2001
Boot0004* Windows Boot Manager
HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Micr=
osoft\Boot\bootmgfw.efi)
                                   da0p1:/EFI/Microsoft/Boot/bootmgfw.efi
(null)
+Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/H=
D(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
 Boot2002* EFI DVD/CDROM
 Boot2003* EFI Network
 Boot2001* EFI USB Device
---
so boot is definitely using /efi/boot/bootx64.efi @Boot0000

I think I can create a new boot:
---
efibootmgr -a -c -l /boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
(and make it active)
efibootmgr -a -b NNNN
---
and create other for loader.efi.old in case of problems.

In this case I will need only update /efi/freebsd/loader.efi.

Q: for what has been said in mailing, boot is compiled in /usr/src/stand,
isn't a good idea that when it install new boot it backup old boot like
/boot/kernel -> /boot/kernel.old?

Thanks,

--=20
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000008e4b9c05e65a83ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Toomas,

<=
/div>

For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page 499) =
is suggesting to use structure like:



<ESP>/efi/<OS>/=E2=80=A6



And to use this suggestion, it means the UEFI Boot Manager needs to be conf=
igured (see efibootmgr(8)).



Therefore, once you have set up OS specific setup, there is no use for defa=
ult (<ESP>/efi/boot/=E2=80=A6) and you need to update one or another,=
 but not both.

FreeBSD have <E=
SP>/efi/freebsd/... but it's not configured in efibootmgr:

efibootmgr -v:
---
BootOrder =C2=A0: 00=
04, 0000, 2002, 2003, 2001
Boot0004* Windows Boot Manager HD(1,GP=
T,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Microsoft\B=
oot\bootmgfw.efi)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0da=
0p1:/EFI/Microsoft/Boot/bootmgfw.efi (null)
+Boot0000* EFI Hard Drive (S=
AMSUNG MZVLB1T0HBLR-000L2) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1=
,39-f9-b8-01-81-38-25-00)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x2=
8,0x82000)
=C2=A0Boot2002* EFI DVD/CDROM
=C2=A0Boot2003* EFI N=
etwork
=C2=A0Boot2001* EFI USB Device
---
so boot is=
 definitely using <ESP>/efi/boot/bootx64.efi @Boot0000

I th=
ink I can create a new boot:
---
efibootmgr -a -c -l /b=
oot/efi/efi/freebsd/loader.efi -L FreeBSD-14
(and make it active)=

efibootmgr -a -b NNNN
---
and create other f=
or loader.efi.old in case of problems.

In this cas=
e I will need only update <ESP>/efi/freebsd/loader.efi.

Q: for what has been said in mailing, boot is compiled in /=
usr/src/stand, isn't a good idea that when it install new boot it backu=
p old boot like /boot/kernel -> /boot/kernel.old?

Thanks,

-- 
Nu=
no Teixeira
FreeBSD Committer (ports)


--0000000000008e4b9c05e65a83ae--

From nobody Tue Aug 16 12:15:16 2022
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 4M6VTk08rMz4YxQh
	for ; Tue, 16 Aug 2022 12:15:22 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from ci74p00im-qukt09082101.me.com (ci74p00im-qukt09082101.me.com [17.57.156.10])
	(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 4M6VTj2ndPz4FBW
	for ; Tue, 16 Aug 2022 12:15:21 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1660652120; bh=rxVghl1y5JylAB7bJdVgfP7YT4inshOfUEAfwV9DFaw=;
	h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To;
	b=1K4oJaq7TL8A4Tgwk3dFxe9HtvL/PHzu3Q7nRFV3wNDjbqRpJUsuOUiLyHSKJbAo9
	 CfLTLeGb2s2Ha/QCRLk6GW0GIcmidmDbQ7LoLoCoCujcdUGIoFHSClUYyN8YkTpXcd
	 dO71SocNirUs6AECiGN+Tlagz+X+5A6EeshByrqn/1S2DdZiV5ubMTd70tjusVnLRF
	 C+AjDq1gfbLd6xp6YCnHg0fUDJoJ/dQ2ylV5cFk6Oy9sj2v+BQ1cLcJZ3iQHEKkGM0
	 nbqoKnsuUOO0YXBHfGKrEd9JvJx51Pj33BkCLzVhd+07Kkzlf698KYf5qbtKZ3z8jm
	 XSNG8N5w5hYGA==
Received: from smtpclient.apple (ci77p00im-dlb-asmtp-mailmevip.me.com [17.57.156.26])
	by ci74p00im-qukt09082101.me.com (Postfix) with ESMTPSA id 378225600480;
	Tue, 16 Aug 2022 12:15:18 +0000 (UTC)
From: Toomas Soome 
Message-Id: <6C8EFCAC-52EF-4037-A6A6-BB9DF76AD905@me.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_BBF3FCEA-2E07-4D64-BF71-626A44949F83"
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: 24.3. Updating Bootcode
Date: Tue, 16 Aug 2022 15:15:16 +0300
In-Reply-To: 
Cc: FreeBSD CURRENT 
To: Nuno Teixeira 
References: 
 <62B26DE1-0E26-40BA-8647-E591E9ACEB7A@me.com>
 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Proofpoint-GUID: TESewU1tIQchtx7-hRkl4VuZCNsnAdzb
X-Proofpoint-ORIG-GUID: TESewU1tIQchtx7-hRkl4VuZCNsnAdzb
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.572,17.0.605.474.0000000_definitions?=
 =?UTF-8?Q?=3D2020-02-14=5F11:2020-02-14=5F02,2020-02-14=5F11,2020-01-23?=
 =?UTF-8?Q?=5F02_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=958 malwarescore=0
 suspectscore=0 spamscore=0 mlxscore=0 bulkscore=0 phishscore=0
 clxscore=1015 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2206140000 definitions=main-2208160046
X-Rspamd-Queue-Id: 4M6VTj2ndPz4FBW
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=1K4oJaq7;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.57.156.10 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-3.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:17.57.156.0/24];
	R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	RCVD_IN_DNSWL_LOW(-0.10)[17.57.156.10:from];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEFALL_USER(0.00)[tsoome];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[17.57.156.10:from];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:714, ipnet:17.57.156.0/24, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[me.com:+];
	TO_DN_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[me.com];
	DWL_DNSWL_NONE(0.00)[me.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[me.com];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_BBF3FCEA-2E07-4D64-BF71-626A44949F83
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 16. Aug 2022, at 15:01, Nuno Teixeira  wrote:
>=20
> Hi Toomas,
>=20
> For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page =
499) is suggesting to use structure like:
>=20
> /efi//=E2=80=A6
>=20
> And to use this suggestion, it means the UEFI Boot Manager needs to be =
configured (see efibootmgr(8)).
>=20
> Therefore, once you have set up OS specific setup, there is no use for =
default (/efi/boot/=E2=80=A6) and you need to update one or =
another, but not both.
>=20
> FreeBSD have /efi/freebsd/... but it's not configured in =
efibootmgr:
>=20
> efibootmgr -v:
> ---
> BootOrder  : 0004, 0000, 2002, 2003, 2001
> Boot0004* Windows Boot Manager =
HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Mic=
rosoft\Boot\bootmgfw.efi)
>                                    =
da0p1:/EFI/Microsoft/Boot/bootmgfw.efi (null)
> +Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2) =
PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/=
HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
>  Boot2002* EFI DVD/CDROM
>  Boot2003* EFI Network
>  Boot2001* EFI USB Device
> ---
> so boot is definitely using /efi/boot/bootx64.efi @Boot0000 <>

Yes, Boot0000 does not specify file name, so it is using default path =
there.

>=20
> I think I can create a new boot:
> ---
> efibootmgr -a -c -l /boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
> (and make it active)
> efibootmgr -a -b NNNN
> ---
> and create other for loader.efi.old in case of problems.
>=20
> In this case I will need only update /efi/freebsd/loader.efi.
>=20
> Q: for what has been said in mailing, boot is compiled in =
/usr/src/stand, isn't a good idea that when it install new boot it =
backup old boot like /boot/kernel -> /boot/kernel.old?
>=20

Boot loader update does not touch kernel, but when you do installkernel, =
that one will create backup copy for you. And, if you are using zfs =
root, you really should use boot environments.

rgds,
toomas


--Apple-Mail=_BBF3FCEA-2E07-4D64-BF71-626A44949F83
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 16. Aug 2022, at 15:01, Nuno Teixeira <eduardo@freebsd.org>=
 wrote:

Hi =
Toomas,


For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page =
499) is suggesting to use structure like:



<ESP>/efi/<OS>/=E2=80=A6



And to use this suggestion, it means the UEFI Boot Manager needs to be =
configured (see efibootmgr(8)).



Therefore, once you have set up OS specific setup, there is no use for =
default (<ESP>/efi/boot/=E2=80=A6) and you need to update one or =
another, but not both.

FreeBSD have =
<ESP>/efi/freebsd/... but it's not configured in =
efibootmgr:

efibootmgr -v:
---
BootOrder  : 0004, 0000, 2002, 2003, 2001
Boot0004* Windows Boot Manager =
HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Mic=
rosoft\Boot\bootmgfw.efi)
        =
                    =
       da0p1:/EFI/Microsoft/Boot/bootmgfw.efi =
(null)
+Boot0000* EFI Hard Drive (SAMSUNG =
MZVLB1T0HBLR-000L2) =
PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/=
HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
 Boot2002* EFI DVD/CDROM
 Boot2003* =
EFI Network
 Boot2001* EFI USB Device
---
so boot is definitely using =
<ESP>/efi/boot/bootx64.efi @Boot0000

Yes, Boot0000 does not specify file name, so it is =
using default path there.

I think I can create a new =
boot:
---
efibootmgr -a -c -l =
/boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
(and =
make it active)
efibootmgr -a -b NNNN
---
and create other for loader.efi.old =
in case of problems.

In this case I will need only update =
<ESP>/efi/freebsd/loader.efi.

Q: for what has been =
said in mailing, boot is compiled in /usr/src/stand, isn't a good idea =
that when it install new boot it backup old boot like /boot/kernel -> =
/boot/kernel.old?


Boot =
loader update does not touch kernel, but when you do installkernel, that =
one will create backup copy for you. And, if you are using zfs root, you =
really should use boot environments.

rgds,
toomas

=

--Apple-Mail=_BBF3FCEA-2E07-4D64-BF71-626A44949F83--

From nobody Tue Aug 16 17:15:19 2022
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 4M6d834yqLz4Yw4p
	for ; Tue, 16 Aug 2022 17:15:31 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M6d824Lh3z3nPC
	for ; Tue, 16 Aug 2022 17:15:30 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe36.google.com with SMTP id c3so10763177vsc.6
        for ; Tue, 16 Aug 2022 10:15:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=EdnSJoiz73QOgfUpshAInckcxUq0DdAbXJSJu4WG+2k=;
        b=SX2FOqzVLrfG5Wpogwu6/FWcCJOKZSmdG/Ll7HBSZFCIYnhQ3eh4ksYScaK9+z1TqE
         SR3wgm26S205QgJDQy0S7wV1Qb+x5cdiLokddGowK3TnkbD1aW04e7LgqNVf7WzD3HT6
         Ft5jniu8V4+1u4aehpMuNGqObUqB12wJmJFnJTFL2gdkNOGTXpfFGoS19KVFtWuOf4rQ
         3txLbCWy4UPIsZfZrG7Ap6pwTj06EqtP/EpS3H+zk+GbP88YWR3h0t0sPDLSTgMGdO39
         LtGhMilQ5QTxB26PpTPMyy1Hr3JZNNqhK+5uFP+7l+FUbzG1pe9TBQLPEoX7O1PpiHHc
         txrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=EdnSJoiz73QOgfUpshAInckcxUq0DdAbXJSJu4WG+2k=;
        b=F2G/IiuJpz+XOgdLJ5dFgxpHxAFCIBZqv+diBMFSQERu/CbZFkXsFgcf27+dE0P9rO
         MQ+ziN7d/G2gqyo0G3+tPg18NMkvTpK/kbKSX1NkiZmClCVeZ1IKh40GsJS+tjmk9bNF
         F10TQjDMPep01YbmXZkL47HQ7eYHZaGM2KBYSKsbo6BgbF9jOKBPT9PyPlNak+0lyiaO
         MJdtFkCM424ONb5v8DKN4n0lJqzpiCDZU7K7ZDcj2axtsI2k57aTGZQsODg5R6E2npdu
         CXytDahuQLHwrG3KQ+OjYF/iheOHgw7ClL7XBD+hZZik5S+tezcHqUbWhwWdcTZFcJBM
         pk5Q==
X-Gm-Message-State: ACgBeo15dvLgumMas1XRlp3FTPyWcVpVITb+3joHBVL4g4sbebX6yBwa
	5vTXQrsId5eZMCCmdck14Co2SBmlr92FqEpLr39YMV1MGk4=
X-Google-Smtp-Source: AA6agR5vuMyQVdwlSb8yNl14VKxEDroHM92iOVVV3NlQi2sqnpy369387fkXMKs2N2ULmJmqofodPztRHCaFuir5G6M=
X-Received: by 2002:a67:b208:0:b0:357:e999:441c with SMTP id
 b8-20020a67b208000000b00357e999441cmr8419430vsf.67.1660670129831; Tue, 16 Aug
 2022 10:15:29 -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: Tue, 16 Aug 2022 11:15:19 -0600
Message-ID: 
Subject: Re: 24.3. Updating Bootcode
To: Nuno Teixeira 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000002da73d05e65ee574"
X-Rspamd-Queue-Id: 4M6d824Lh3z3nPC
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=SX2FOqzV;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e36) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e36:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000002da73d05e65ee574
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 16, 2022 at 3:49 AM Nuno Teixeira  wrote:

> Hello all,
>
> With so much discussion about updating boot, I feel confused about the
> correct procedure of doing it.
>
> Like being said there are a "24.3. Updating Bootcode" in Handbook (WIP)
> that points to some important manuals.
>
> There are 3 places where boot loader are:
>
>  ESP (EFI System Partition):
> 1 - (/boot/efi)/efi/boot/bootXXX.efi (default location)
>

Default for the boot loader, that is. By default we don't install here
anymore (though as a workaround
for broken BIOSes or those that don't properly save EFI env vars or that
change help to be helpful,
we'll park a copy here, this usually isn't updated).


> 2 - (/boot/efi)/efi/freebsd/loader.efi (FreeBSD reserved area)
>

This is what the boot usually uses on working systems.


> Operating System:
> 3 - /boot/loader.efi
>

This is only used when chain loaded from a legacy system that installed
boot1.efi, or in some cases
from a 'special needs' system that loads it from gptboot.efi.


> For what I've read we should:
>  - backup: `cp /boot/efi/efi/boot/bootXXX.efi
> /boot/efi/efi/boot/bootXXX.efi.bkp`
>

I'd recommend bootXXX-old.efi (or bootXXX-bkp.efi) since you'll be able to
run it from the EFI shell
if you are lucky enough to have one. The shell won't run the .bkp file.


>  - update: `cp /boot/loader.efi /boot/efi/efi/boot/bootXXX.efi`
>

Yes and no. You should likely update both this one and the one in
efi/freebsd as well since the latter
is more typically used (though your system may be one of the
sadly-too-sizable number of systems
that ignore the env vars and use the default removable media file).


> In this example we have a /boot/efi mount by the system, "/dev/XXXpN on
> /boot/efi (msdosfs, local)".
>

Yes.


> What about (/boot/efi)/efi/freebsd/loader.efi (reserved area)? Is
> necessary to backup and update it too?
>

It's the primary thing that gets used most of the time. I'd certainly back
it up and update it.

Warner

--0000000000002da73d05e65ee574
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Aug 16, 2022 at 3:49 AM Nuno =
Teixeira <eduardo@freebsd.org=
> wrote:
Hello all,

With so much discussi=
on about updating boot, I feel confused about the correct procedure of doin=
g it.

Like being said there are a "24.3. Upda=
ting Bootcode" in Handbook (WIP) that points to some important manuals=
.

There are 3 places where boot loader are:
=C2=A0ESP (EFI System Partition):
1 - (/boot/efi)/efi=
/boot/bootXXX.efi (default location)

Default=C2=A0for the boot loader, that is. By default we don't in=
stall here anymore (though as a workaround
for broken BIOSes or t=
hose that don't properly save EFI env vars or that change help to be he=
lpful,
we'll park a copy here, this usually isn't updated=
).
=C2=A0
=

2 - (/boot/efi)/efi/freebsd/loader.efi (FreeBSD reser=
ved area)

This is what the boot=
 usually uses on working systems.
=C2=A0
Operating System:
3 - /boot/loader.efi

This is only used when chain loaded from a legacy system that installed b=
oot1.efi, or in some cases
from a 'special needs' system =
that loads it from gptboot.efi.
=C2=A0
For what I've read w=
e should:
=C2=A0- backup: `cp /boot/efi/efi/boot/bootXXX.efi /boo=
t/efi/efi/boot/bootXXX.efi.bkp`

I'd recommend bootXXX-old.efi (or bootXXX-bkp.efi) since you'll be=
 able to run it from the EFI shell
if you are lucky enough=C2=A0t=
o have one. The shell won't run the .bkp file.
=C2=A0
=C2=
=A0- update: `cp /boot/loader.efi /boot/efi/efi/boot/bootXXX.efi`

Yes and no. You should likely update bot=
h this one and the one in efi/freebsd as well since the latter
is=
 more typically used (though your system may be one of the sadly-too-sizabl=
e number of systems
that ignore the env vars and use the default =
removable media file).
=C2=A0
In this example we have a /boot/e=
fi mount by the system, "/dev/XXXpN on /boot/efi (msdosfs, local)"=
;.

Yes.
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
What=
 about (/boot/efi)/efi/freebsd/loader.efi (reserved area)? Is necessary to =
backup and update it too?

It=
9;s the primary thing that gets used most of the time. I'd certainly ba=
ck it up and update it.

Warner=C2=A0


--0000000000002da73d05e65ee574--

From nobody Tue Aug 16 17:18:52 2022
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 4M6dD90bxcz4YwX1
	for ; Tue, 16 Aug 2022 17:19:05 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M6dD83Rvhz3pFY
	for ; Tue, 16 Aug 2022 17:19:04 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe34.google.com with SMTP id q190so10787958vsb.7
        for ; Tue, 16 Aug 2022 10:19:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=py2lewyLOzuL8nqYpLUAp7No2N65hEP1IdPUCKOsix0=;
        b=a8Gcn9M6yPODCfyxKtzcCHMwrp4Apch/mNS3hcSYBulQLQkzEN0i9D0uBV1WV5MQqb
         fBYgk5ESLS4G8y3PymPD+R7FxzQ0NqmWag0dY8g4PABfFve3Y7O3rppNcsMOas9v9IZH
         YdfQaDlZxoCHlg8sSB+MoNatHbeTHvSxzeexL0vFVHI4BNjqHnMqM6wKa6uIziBKjiFh
         ww4syW+mL6HAfqZ97YZNowS0LRC0INjxxMk/BBPFxG4lJJF1wdEMu1gAM6/gjRCILjFi
         5Aws8acohTt9ixlSve2WLfG4QbQLV/wrNEsyvnF13JRn6Em89WsF4c5FLXHtVLKW9gFZ
         HCUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=py2lewyLOzuL8nqYpLUAp7No2N65hEP1IdPUCKOsix0=;
        b=XdYNpqsYx6ZjkKXg2QUDFm9Gw0oyETxYOwj0BcK5ZeO3OzFH6Q5maifIAA0fLM5Wi6
         1IcHQbSKKwltGPvt0a+TcceCbQPuo7HwYMAo8El45cMEZefgIBin/rAEWHPji+97qxeI
         +mfnJadi3ghZ1FKfSK4kk0Ihs7ZFf2p4q8BUnCwpUFt2b93iOfnL3RqDGG+VqC+SPDMR
         +XbD+tIsm84vqaxQRIyTqetURcU5VB7WDk28dybR9jlwL3QX4zHlskArKof1jhKV7DeZ
         YWum0i8Y6OXwFhGrhMhhLox1eKWcwCDC82UrcyTa7zuftb5uWHXk4OSMVNbDDXvnNARj
         OGAQ==
X-Gm-Message-State: ACgBeo1Z77e9tHaLWkq0VVWLFPGPa28Ht2PE2LPxtOm+5ynzD1mgAdqo
	I/nsOZ8vwHPz/0BA44dTKuVSbNDkZC1yBakoLQSqqwhifDA=
X-Google-Smtp-Source: AA6agR5A519u0q9VSlrbyv1W1aTSwQ8FQTUD7n3D2uzAmgGj8QvlFGI1cSI3u4W3h00nTHunZ/k9H84okq4cSIWoYRk=
X-Received: by 2002:a67:fdce:0:b0:388:485c:889c with SMTP id
 l14-20020a67fdce000000b00388485c889cmr8463950vsq.38.1660670343681; Tue, 16
 Aug 2022 10:19:03 -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: 
 <62B26DE1-0E26-40BA-8647-E591E9ACEB7A@me.com> 
In-Reply-To: 
From: Warner Losh 
Date: Tue, 16 Aug 2022 11:18:52 -0600
Message-ID: 
Subject: Re: 24.3. Updating Bootcode
To: Nuno Teixeira 
Cc: Toomas Soome , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000ecad7905e65ef160"
X-Rspamd-Queue-Id: 4M6dD83Rvhz3pFY
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=a8Gcn9M6;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e34) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e34:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	FREEMAIL_CC(0.00)[me.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000ecad7905e65ef160
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 16, 2022 at 6:01 AM Nuno Teixeira  wrote:

> Hi Toomas,
>
> For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page 499=
)
>> is suggesting to use structure like:
>>
>> /efi//=E2=80=A6
>>
>> And to use this suggestion, it means the UEFI Boot Manager needs to be
>> configured (see efibootmgr(8)).
>>
>> Therefore, once you have set up OS specific setup, there is no use for
>> default (/efi/boot/=E2=80=A6) and you need to update one or another=
, but not
>> both.
>>
>
> FreeBSD have /efi/freebsd/... but it's not configured in efibootmgr:
>

The current default installer will do this, but older upgraded systems
don't do this by default. Likely you are looking at an older
system and/or one of the 'bad actors' that reset this stuff between boots.


> efibootmgr -v:
> ---
> BootOrder  : 0004, 0000, 2002, 2003, 2001
> Boot0004* Windows Boot Manager
> HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Mi=
crosoft\Boot\bootmgfw.efi)
>                                    da0p1:/EFI/Microsoft/Boot/bootmgfw.efi
> (null)
> +Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
> PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)=
/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
>  Boot2002* EFI DVD/CDROM
>  Boot2003* EFI Network
>  Boot2001* EFI USB Device
> ---
> so boot is definitely using /efi/boot/bootx64.efi @Boot0000
>

In your case, that's true. The "EFI Hard Drive" is a default entry the UEFI
BIOS created for you.


> I think I can create a new boot:
> ---
> efibootmgr -a -c -l /boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
> (and make it active)
> efibootmgr -a -b NNNN
> ---
> and create other for loader.efi.old in case of problems.
>

Yes.


> In this case I will need only update /efi/freebsd/loader.efi.
>
> Q: for what has been said in mailing, boot is compiled in /usr/src/stand,
> isn't a good idea that when it install new boot it backup old boot like
> /boot/kernel -> /boot/kernel.old?
>

Yes. In fact that's what's done, but only for the BIOS version. We should
do the same for efi but don't seem to do so currently. But that's likely
tied up behind issues of installing things automatically into the ESP on
'installworld'.

Warner

--000000000000ecad7905e65ef160
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Aug 16, 2022 at 6:01 AM Nuno =
Teixeira <eduardo@freebsd.org=
> wrote:
Hi Toomas,


For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page 499) =
is suggesting to use structure like:



<ESP>/efi/<OS>/=E2=80=A6



And to use this suggestion, it means the UEFI Boot Manager needs to be conf=
igured (see efibootmgr(8)).



Therefore, once you have set up OS specific setup, there is no use for defa=
ult (<ESP>/efi/boot/=E2=80=A6) and you need to update one or another,=
 but not both.

FreeBSD have <E=
SP>/efi/freebsd/... but it's not configured in efibootmgr:

The current default installer will do th=
is, but older upgraded systems don't do this by default. Likely you are=
 looking at an older
system and/or one of the 'bad actors'=
; that reset this stuff between boots.
=C2=A0
efibootmgr -v:
---
BootOrder =C2=A0: 0004, 0000, 2002, 2003, 2001
<=
div>Boot0004* Windows Boot Manager HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0b=
b7283,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0da0p1:/EFI/Microsoft/Boot/bootmgfw=
.efi (null)
+Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2) PciRo=
ot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/HD(1,G=
PT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
=C2=A0Boot2=
002* EFI DVD/CDROM
=C2=A0Boot2003* EFI Network
=C2=A0Boot2001* EFI US=
B Device
---
so boot is definitely using <ESP>/ef=
i/boot/bootx64.efi @Boot0000

In your case, that's true. The "EFI Hard Drive" is a de=
fault entry the UEFI BIOS created for you.
=C2=A0
I =
think I can create a new boot:
---
efibootmgr -a -c -l =
/boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
(and make it activ=
e)
efibootmgr -a -b NNNN
---
and create other=
 for loader.efi.old in case of problems.

<=
/div>
Yes.
=C2=A0
In this case I will need only update <=
ESP>/efi/freebsd/loader.efi.

Q: for what ha=
s been said in mailing, boot is compiled in /usr/src/stand, isn't a goo=
d idea that when it install new boot it backup old boot like /boot/kernel -=
> /boot/kernel.old?

Yes. In =
fact that's what's done, but only for the BIOS version. We should d=
o the same for efi but don't seem to do so currently. But that's li=
kely tied up behind issues of installing things automatically into the ESP =
on 'installworld'.

Warner=C2=A0


--000000000000ecad7905e65ef160--

From nobody Tue Aug 16 17:39:48 2022
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 4M6dhK4rJ0z4Yyr1
	for ; Tue, 16 Aug 2022 17:40:01 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M6dhK0KXxz3sPy;
	Tue, 16 Aug 2022 17:40:01 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: by mail-ej1-f45.google.com with SMTP id y13so20194687ejp.13;
        Tue, 16 Aug 2022 10:40:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=92S5b0+5GAyje3B9xglOeoaiMZ/CSJ2Xm0JRb2b0Vow=;
        b=nOfzUQmYzIHEs3R3D+fmSj7RhUmyqF5o9/jUn5GUjGl8uAPnrgwUpm5SvQAc+a+wul
         UYqIbqGyXEZ+RQXp7XyEWlqj+lADBa6d2DgBZ46WLsD6yZha6htzcKGxVtxf6BS8rB2q
         jX5LXO0mQSraHQ+M5h7jVbiDz/AdzOfJSOHeekdeaiM2l50eHbzohBi+6UL3LRmjCnK+
         7YhzxP0DyKcEZf/ECGsaE/gxcgYENmg3p3ACOlqBzFBs15sYBIaxRuaEICSmkSyLCQN5
         oZpfGZTsB/wrmtAsdgtRXGcPXcppkyYgMniNtsTehNg+MlcPYQw9hpECJa0vIgrnLOlS
         fD4w==
X-Gm-Message-State: ACgBeo1DE7Z8oOQSZA0ss8Deg6ciSPWZqt+qvR1o7U9UkwYA8ZYjq1WN
	41bXie3BjjS7aT6O25soW94/T8J7oyHhsDo/aJ0=
X-Google-Smtp-Source: AA6agR5UdRypmerId28Z75RQDIJcH0BeEVrLyBGSduXUYOtXv/IZxjF4CJrNl5hJ7MP9FOojpeFTkSabrh//qhXGR+g=
X-Received: by 2002:a17:906:9f2a:b0:730:bc30:da30 with SMTP id
 fy42-20020a1709069f2a00b00730bc30da30mr14328816ejc.763.1660671599831; Tue, 16
 Aug 2022 10:39:59 -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: <1615CF76-EE45-4D11-8102-EA441E845E65@gushi.org>
 <635211659622624@mail.yandex.ru> 
 <493ED6A6-A38F-47B1-B534-9F5CB14DB087@gushi.org> 
 <1578B277-8FB1-4EAB-ACDB-8ACE6E999857@gushi.org> 
 <9EC7D5D4-0DD2-4946-9C5F-ADB2B39B73F1@gushi.org> 
  
In-Reply-To: 
From: Ed Maste 
Date: Tue, 16 Aug 2022 13:39:48 -0400
Message-ID: 
Subject: Re: MegaCLI port is ports-only -- how would you deploy it?
To: Doug Ambrisko 
Cc: Dan Mahoney , Ruslan Makhmatkhanov , 
	"samflanker@gmail.com" , freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4M6dhK0KXxz3sPy
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com
X-Spamd-Result: default: False [-2.10 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	RWL_MAILSPIKE_GOOD(-0.10)[209.85.218.45:from];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEFALL_USER(0.00)[carpeddiem];
	DMARC_NA(0.00)[freebsd.org];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.218.45:from];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com];
	FREEMAIL_CC(0.00)[gushi.org,freebsd.org,gmail.com]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 15 Aug 2022 at 20:03, Doug Ambrisko  wrote:
> | > | > I'd have to put in -current first then look at MFC later on.  If looks
> | > | > good for you then I'll put it up for review.  I just don't use this
> | > | > stuff day to day anymore.

I think it would be good to put this into review, perhaps separate
ones for the kernel and userland parts. Feel free to put me on as a
reviewer or subscriber.

From nobody Tue Aug 16 17:58:40 2022
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 4M6f646qVCz4Z2Bd
	for ; Tue, 16 Aug 2022 17:58:52 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M6f6427Vjz3ygl
	for ; Tue, 16 Aug 2022 17:58:52 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe31.google.com with SMTP id d126so10888161vsd.13
        for ; Tue, 16 Aug 2022 10:58:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=f+xjIFUx6T5jp+3Fxp6tdjiwhXg0WtBkwlwTyhClzJY=;
        b=OxxAuugMCXohJ9qb1V3oRNSZnXAgz1YuBF/6dy/dQHshAeYIqWUtWl7QpNPHc7OOzC
         AAH8nrIfFIqI7+wNfnogYTUbfuJnMGGljRa8T7h3IhFPKw9rUzGg2eJxWQLp8spWjLyL
         nQqhXfaIaZ5tgcVtfpNX53jqerQsUACKNL8b5zx0RNlpKOQ4KyVBA/SgzwmKu0FsWTkh
         WYDjoJWuedlg/4suz3jNiwouwQaCv1T9SWCOr6Dg5L6qsFeoj3YOZCg3dPI3zU+6fYWp
         sNKNW3JJGUmJdJfnFKonp+4a80imzGTHdg8eRpR1tmRUblqUR8vs5amlYjOO2SLcRNNa
         oNOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=f+xjIFUx6T5jp+3Fxp6tdjiwhXg0WtBkwlwTyhClzJY=;
        b=Q+4Qna21vbNl3ZTXG8o07DAhbPFTgO9YYjjzqp/do2eG4nCi3ao8ncSnvTNLoS9i1n
         +E3lY3cSKlykyiTP5BAfFU3EBxZ6u2lq6C5ZUH8w1kPHW4i8JEzneRBScXVH3Tkx1aL9
         jMITAjpmx0dMeEZQ86c+YUYbtQX2/fyOlxkFxL6W3H2rVUmSZgOsN0FQhaUGE3ouo/aT
         umGUZU2mJ/Jj4kfpli7PRUK0qM4EQJMTCkq8wdCSXHO+6kbtvgqxm+q5I6Lr9q4Efo3S
         12eWSdbA1Nna2avD9DSrTAgpH8eVmoRfpNF0AnnbYC6rPpkPgAhMENf31F3LJ+1nJxof
         flnw==
X-Gm-Message-State: ACgBeo1Yyq49Ny9rJHvEA4TqpZBHOTW329L8UWTdKtUohkCpGz8dY2M3
	RsWOw5/OG8cH600S/JInIhpRtJxn17lJIARa7F5oiMqxyTE=
X-Google-Smtp-Source: AA6agR56rm4e9yE/r9ltvh0fsa7Ax2VlpOIEmj9yJwST42sxnmcGzGInBW7PjvKWeA7al87N5+ToaR+PpA/pgHNl9Bc=
X-Received: by 2002:a67:b208:0:b0:357:e999:441c with SMTP id
 b8-20020a67b208000000b00357e999441cmr8484850vsf.67.1660672731528; Tue, 16 Aug
 2022 10:58:51 -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: <1615CF76-EE45-4D11-8102-EA441E845E65@gushi.org>
 <635211659622624@mail.yandex.ru> 
 <493ED6A6-A38F-47B1-B534-9F5CB14DB087@gushi.org> 
 <1578B277-8FB1-4EAB-ACDB-8ACE6E999857@gushi.org> 
 <9EC7D5D4-0DD2-4946-9C5F-ADB2B39B73F1@gushi.org> 
  
 
In-Reply-To: 
From: Warner Losh 
Date: Tue, 16 Aug 2022 11:58:40 -0600
Message-ID: 
Subject: Re: MegaCLI port is ports-only -- how would you deploy it?
To: Ed Maste 
Cc: Doug Ambrisko , Dan Mahoney , 
	Ruslan Makhmatkhanov , "samflanker@gmail.com" , 
	FreeBSD Current 
Content-Type: multipart/alternative; boundary="00000000000040517905e65f8093"
X-Rspamd-Queue-Id: 4M6f6427Vjz3ygl
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=OxxAuugM;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e31) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_FIVE(0.00)[6];
	FREEMAIL_CC(0.00)[ambrisko.com,gushi.org,freebsd.org,gmail.com]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000040517905e65f8093
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 16, 2022 at 11:40 AM Ed Maste  wrote:

> On Mon, 15 Aug 2022 at 20:03, Doug Ambrisko  wrote:
> > | > | > I'd have to put in -current first then look at MFC later on.  If
> looks
> > | > | > good for you then I'll put it up for review.  I just don't use
> this
> > | > | > stuff day to day anymore.
>
> I think it would be good to put this into review, perhaps separate
> ones for the kernel and userland parts. Feel free to put me on as a
> reviewer or subscriber.
>

I can review as well. I like this plan.

Warner

--00000000000040517905e65f8093
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Aug 16, 2022 at 11:40 AM Ed M=
aste <emaste@freebsd.org> w=
rote:
On Mon, 15=
 Aug 2022 at 20:03, Doug Ambrisko <ambrisko@ambrisko.com> wrote:

> | > | > I'd have to put in -current first then look at MFC l=
ater on.=C2=A0 If looks

> | > | > good for you then I'll put it up for review.=C2=A0 I=
 just don't use this

> | > | > stuff day to day anymore.



I think it would be good to put this into review, perhaps separate

ones for the kernel and userland parts. Feel free to put me on as a

reviewer or subscriber.

I can review as=
 well. I like this plan.

Warner=C2=A0
<=
/div>

--00000000000040517905e65f8093--

From nobody Tue Aug 16 18:04:34 2022
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 4M6fDh4hppz4Z3DZ
	for ; Tue, 16 Aug 2022 18:04:36 +0000 (UTC)
	(envelope-from ambrisko@ambrisko.com)
Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91])
	by mx1.freebsd.org (Postfix) with ESMTP id 4M6fDg5YhXz42vh;
	Tue, 16 Aug 2022 18:04:35 +0000 (UTC)
	(envelope-from ambrisko@ambrisko.com)
IronPort-SDR: 7P4VpluUXl51ZnVLxiYxKRTIauiQH2qXdBhq8k5BG9OJEEPSik19uuHBUO23Fc/b9LAOQg8YCB
 xvKn/N7haRgM82z4gBIseR36ifOog2MIY=
X-Ambrisko-Me: Yes
IronPort-Data: A9a23:+490ba6KeiXpAJf/+gcPXwxRtP/HchMFZxGqfqrLsTDasY5as4F+v
 moYWz3Saf3eYDOjLYgiPt6+80NQ75SHnYJnHVBppC83QiMRo6IpJzg5wmQcns+2BpeeJK5fA
 kl3huDodKjYdFeFzvuQGuOJQUdUhPjgqoXUWLas1hBZHWeIeQ954f5Rs7dRbr1A3bBVNziwV
 eba+KUzDrMFNwlcaQr444rbwP9mUW+bVDkw5jTSbtgT1LPSeuV84Dvy+MiMw3XErol8RoZWR
 s7Cyq205GXQ+1EkD9m/k634dQsBRbu60Qqm0ysMHfH80l4b4HZaPqUTbJLwbW9ejj+Tnstyz
 /1EsJaqSBwqOevHn+F1vxxwTnwmZfYdkFPACT3l2SCJ9GXHdmPEye5iDUQue4Yf/45fDGRH7
 uAVAD4XYx2JnO7wx6i0IsFinMkuJtLnFIwCoXFhizbDAp4OW5XrTb/H6NVD0HE3nM8mNe3XY
 sQdYDxsYQ7obBhGO1NRA5U79M+mnHTyeSZU7VmIv7A65XT7whZ83bL2PJzSYNPieCn/ti50v
 Urd8n7nDwtActWawyCE6XGrwOTImEvGtEspPOXQ3pZXbJe7nwT/0TUaCgm2p+eXkEm7V44NI
 kAY4HB3/6E3/laqVdr6dxS9qmSFpR0bHdFXFrRiug2Kz6PV5SefB3QFHmMZMY167JduSGx4z
 EKNkvPoGSdr7O+fR0WC++rGtji1IyUUczMPPHdWUQsf7tD/i4gvlRaTHM17Gau4g4StSzH9y
 jyHtgYkgLAXgZJZ3qm35wqe0TuprILIVQ0yzgzSVHik9QB+IoWiYtXwu1Tc6P9BKqefT0WA7
 CVcwpnCtLhWAMjUxiKXQegLELW43Nq/MWXR0Qx1Ap0s1zWx4Hr/L4pe1y5zeRVyOcEedD63P
 EKK4VFN5IVeNWeBZLNsZ97jENwjyKXtGIi3Vv3QadYSMJF9eBXdpXNvY1KdxWbklA4llKslO
 IyYdoCnCnNDUfZryz+/RuE81743x3BjnTqCGcijlxn3g6CDYHO1SKseNArcZ+8026qIvQHJ/
 osNLMCN0RheDLXzb3WF64IVNlxWf3E3CYqs855Me/SdLxA8XmgkAeXQ2rAmPYdimv0NxOvP+
 3i8XG5eyUb+1SCfcFTWMig7ZeO9R4t7oFI6ITcobASh1HUUaIqy6LsSKsksdr49+e0/lfN5Q
 pHpoSlb7iijntgfxwkgUA==
IronPort-HdrOrdr: A9a23:CRY/O6txkzqFwcf3iVoxL77+7skDdtV00zEX/kB9WHVpmwKj9v
 xGuM5rsiMc6QxhPE3I9urtBEDtexzhHNtOkO8s1NSZLWzbUQmTXeJfBOLZqlWKdhEWtNQtt5
 uIGJIfNDSfNzZHZfaR2mOFL+o=
Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2])
  by ironport2.ambrisko.com with ESMTP; 16 Aug 2022 09:54:34 -0700
Received: from ambrisko.com (localhost [127.0.0.1])
	by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 27GI4Yox097416
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 16 Aug 2022 11:04:34 -0700 (PDT)
	(envelope-from ambrisko@ambrisko.com)
X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com
Received: (from ambrisko@localhost)
	by ambrisko.com (8.17.1/8.17.1/Submit) id 27GI4YhX097415;
	Tue, 16 Aug 2022 11:04:34 -0700 (PDT)
	(envelope-from ambrisko)
Date: Tue, 16 Aug 2022 11:04:34 -0700
From: Doug Ambrisko 
To: Warner Losh 
Cc: Ed Maste , Dan Mahoney ,
        Ruslan Makhmatkhanov ,
        "samflanker@gmail.com" ,
        FreeBSD Current 
Subject: Re: MegaCLI port is ports-only -- how would you deploy it?
Message-ID: 
References: <493ED6A6-A38F-47B1-B534-9F5CB14DB087@gushi.org>
 
 <1578B277-8FB1-4EAB-ACDB-8ACE6E999857@gushi.org>
 
 <9EC7D5D4-0DD2-4946-9C5F-ADB2B39B73F1@gushi.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-Rspamd-Queue-Id: 4M6fDg5YhXz42vh
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com
X-Spamd-Result: default: False [-1.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	RCPT_COUNT_FIVE(0.00)[6];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[ambrisko];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FREEMAIL_CC(0.00)[freebsd.org,gushi.org,gmail.com];
	TO_DN_SOME(0.00)[];
	HAS_XAW(0.00)[];
	ARC_NA(0.00)[];
	DMARC_NA(0.00)[ambrisko.com];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Aug 16, 2022 at 11:58:40AM -0600, Warner Losh wrote:
|    On Tue, Aug 16, 2022 at 11:40 AM Ed Maste <[1]emaste@freebsd.org>
|    wrote:
| 
|      On Mon, 15 Aug 2022 at 20:03, Doug Ambrisko
|      <[2]ambrisko@ambrisko.com> wrote:
|      > | > | > I'd have to put in -current first then look at MFC later
|      on.  If looks
|      > | > | > good for you then I'll put it up for review.  I just don't
|      use this
|      > | > | > stuff day to day anymore.
|      I think it would be good to put this into review, perhaps separate
|      ones for the kernel and userland parts. Feel free to put me on as a
|      reviewer or subscriber.
| 
|    I can review as well. I like this plan.

I'll add John as well since I think he wrote mfiutil originally.

Thanks,

Doug A.

From nobody Tue Aug 16 20:02:54 2022
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 4M6hsF5nbJz4ZK6n
	for ; Tue, 16 Aug 2022 20:02:57 +0000 (UTC)
	(envelope-from ambrisko@ambrisko.com)
Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91])
	by mx1.freebsd.org (Postfix) with ESMTP id 4M6hsD3p9nz3Z2h;
	Tue, 16 Aug 2022 20:02:56 +0000 (UTC)
	(envelope-from ambrisko@ambrisko.com)
IronPort-SDR: ltB+hs4lE8a7VsVIVjGyYbzv3iqAU0fvgxxz4jwhvK2N1g6cSU1z/6NN+nCfN6VtRVnGDzSvzA
 uwr2O+CnC9zXGMnXCzjsc8TmtVgN1lDwQ=
X-Ambrisko-Me: Yes
IronPort-Data: A9a23:Fsh4eKMoHK8dXgrvrR1il8FynXyQoLVcMsEvi/4bfWQNrUoig2NRz
 TcWCD+DaPbeMzbwLox2bN/j/EwBvZWDytJjTFdlrnsFo1CmCSbm6XV1Cm+qYkt+FiBPJa5ex
 512huPodajYc1eHzvuTGum4xZVD/fHQLlbMILas1hFZHWeIeg944f5Qs7JRbrpTvDSMK1jlV
 eUeAyHoEATNNzZcagr44k8Ywf9llKyaVDgw5jTSaR3X1bN3eqR8MX4RGU2xByOQroh8H+imS
 vzFxbX/92bT5RY2CdTjmbH+GqEIaueDZ07X1CoQAu746vRBjnRaPqITPf8Wc0ZMiDKhltV70
 tRWtpv2QgAsVkHJsLlAC0EHTEmSOoUDotcrO0OXv9aewkfdf1Pj3u5uDQcxJ4Jw0udyGUlE7
 vAZLShLZReG78q7xbugVuREiN4uIcPwMMUYoH4I5SvcJfg8TJ3JWKmM4sVXtB8rj8VAGf/YZ
 McDQTVqZRXEJRZIPz8/Bogzke2zijz0bidCpVSJjaQt7mXZ1wA316LiWOc50PTiqd59hUuCu
 G/cpSLwBxsANcecznyO9XfEuwMGpgujMKp6KVFy3qcCbIS7yjNBBRsIe0G8pPXl2EeyV8gFc
 h4d/yA0rLMx82SiS9PnXga7pziPuRtFA4hcFOgz6QeszKvI4lbEXjFVEmYZMNF25tUrQTEK1
 0OSm4+7DzJYr7DIG2mW8a2ZrG3uNHFNf3MCfyINUSAM/8Ln/NMolhvKQ9s6SPy1g9T5FCve2
 TePqCRi1bwfgdRRjvey+FrdgimvobDASwQv5x7UWSSu6QYgPNypYImh6F766/dcLdbEFgDQ4
 CBcw8XHtbIAF5CAkiCJUd4hJrDx6qbXKiDYjH5uA4Ilq2an9Um8cN0C+zp5PkpobJoJIGe7f
 E/JtApNz5ZPJ3/2P7Rvaoe8Bsl2n6jtEdPpCqLdYtZUOMEjdQmb8TtobErW1mXnikk3kqZ5M
 pCeKJ7+AXEfAKVh7Ty3W+ZNjOdyl3xmnTveFcLh0hCq8buCf3rEG74KPWyHYv098K7Z8h7e9
 MxSNpfSxhgDAvfyZDLbrdwaIVwQdyBpHp3stcFNLKiKJwB8GXoiDLnaxrZ4I95pmKFcl+Hp+
 HChWx8FkAOu2SWfcQjaOGp+bL7PXIpkqSNpNCMhCl+kxnw/bNv996wYbZY2IeEq+eELISSYl
 BXZlxFs2shydwk=
IronPort-HdrOrdr: A9a23:HStsfa2jY/29ZqWFXCHlQAqjBLIkLtp133Aq2lEZdPWaSK2lfu
 SV7ZMmPH7P+VIssR4b9exoVJPufZqYz+8S3WBzB8bGYOCFghrKEGgK1+KLqFDd8m/Fh4xgPM
 xbE5SWZuefMbBL5/yR3DWF
Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2])
  by ironport2.ambrisko.com with ESMTP; 16 Aug 2022 11:52:54 -0700
Received: from ambrisko.com (localhost [127.0.0.1])
	by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 27GK2s3d005912
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 16 Aug 2022 13:02:54 -0700 (PDT)
	(envelope-from ambrisko@ambrisko.com)
X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com
Received: (from ambrisko@localhost)
	by ambrisko.com (8.17.1/8.17.1/Submit) id 27GK2sH6005911;
	Tue, 16 Aug 2022 13:02:54 -0700 (PDT)
	(envelope-from ambrisko)
Date: Tue, 16 Aug 2022 13:02:54 -0700
From: Doug Ambrisko 
To: Dan Mahoney 
Cc: Warner Losh , Ed Maste ,
        Ruslan Makhmatkhanov ,
        "samflanker@gmail.com" ,
        FreeBSD Current 
Subject: Re: MegaCLI port is ports-only -- how would you deploy it?
Message-ID: 
References: <1578B277-8FB1-4EAB-ACDB-8ACE6E999857@gushi.org>
 
 <9EC7D5D4-0DD2-4946-9C5F-ADB2B39B73F1@gushi.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-Rspamd-Queue-Id: 4M6hsD3p9nz3Z2h
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com
X-Spamd-Result: default: False [-1.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[ambrisko];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[ambrisko.com];
	HAS_XAW(0.00)[];
	RCPT_COUNT_FIVE(0.00)[6];
	FREEMAIL_CC(0.00)[bsdimp.com,freebsd.org,gmail.com]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Aug 16, 2022 at 03:33:57PM -0400, Dan Mahoney wrote:
| > On Aug 16, 2022, at 14:04, Doug Ambrisko  wrote:
| > 
| > On Tue, Aug 16, 2022 at 11:58:40AM -0600, Warner Losh wrote:
| > |    On Tue, Aug 16, 2022 at 11:40 AM Ed Maste <[1]emaste@freebsd.org>
| > |    wrote:
| > | 
| > |      On Mon, 15 Aug 2022 at 20:03, Doug Ambrisko
| > |      <[2]ambrisko@ambrisko.com> wrote:
| > |      > | > | > I'd have to put in -current first then look at MFC later
| > |      on.  If looks
| > |      > | > | > good for you then I'll put it up for review.  I just don't
| > |      use this
| > |      > | > | > stuff day to day anymore.
| > |      I think it would be good to put this into review, perhaps separate
| > |      ones for the kernel and userland parts. Feel free to put me on as a
| > |      reviewer or subscriber.
| > | 
| > |    I can review as well. I like this plan.
| > 
| > I'll add John as well since I think he wrote mfiutil originally.
| 
| I haven't attached the makefile patch to the bug I opened yet.  (And the
| existing patch is a link, not an attach).

That isn't critical since I'm the one that made it and plan to be
the committer to deal with it.  I grabbed ownership of the bug.
I updated my personal branch with the fix so I shouldn't drop it
again.  I had factored out some other local changes I had in the
driver.  It had issue with various things that the team I used be
part of would hit since that SW sent lots of concurrent I/O to the
card.  It was made worse on the low end system without cache.
Broadcom didn't seem interested in addressing it when I used to work
with them more closely.  I had patches in that teams driver.
 
| If further diagnostics are needed (I'm not going to like, try to use it
| to blow away and re-create an array, sorry), I can provide SOME of that.
| Just tell me how I can help.

That shouldn't really be needed since the MFI commands are consistent
being MegaRAID SAS controllers.  The main thing that has changed is
the driver.  I've heard they are changing for their next controller that
would require new tools and driver.  In a few months I might have
a machine with one to play with.
 
| In the mean time, since the system that I'm testing this on is one of
| the dayjob's console servers, and we still want to be able to run puppet
| on it periodically, y'all have motivated me to get puppet to fix their
| "ports" package provider, which still depends on pkg-classic binaries
| being present.  Not relevant to this problem, other than noting the cool
| ripple effect.

Thanks,

Doug A.

From nobody Tue Aug 16 22:55:32 2022
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 4M6mhY33gcz4ZgKT
	for ; Tue, 16 Aug 2022 22:55:41 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M6mhW6m6rz3s5y;
	Tue, 16 Aug 2022 22:55:39 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 27GMtWVX025698;
	Wed, 17 Aug 2022 07:55:33 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Wed, 17 Aug 2022 07:55:32 +0900
From: Tomoaki AOKI 
To: Warner Losh 
Cc: Yasuhiro Kimura ,
        FreeBSD Current
 
Subject: Re: Updating EFI boot loader results in boot hangup
Message-Id: <20220817075532.56e144f2857ed45b298a6b1c@dec.sakura.ne.jp>
In-Reply-To: 
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
	<20220814.063440.1883565953618972371.yasu@FreeBSD.org>
	<20220816.120142.317069615425604393.yasu@FreeBSD.org>
	
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4M6mhW6m6rz3s5y
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[sakura.ne.jp];
	RCPT_COUNT_THREE(0.00)[3];
	HAS_ORG_HEADER(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 15 Aug 2022 21:35:52 -0600
Warner Losh  wrote:

> On Mon, Aug 15, 2022, 9:04 PM Yasuhiro Kimura  wrote:
> 
> > From: Yasuhiro Kimura 
> > Subject: Re: Updating EFI boot loader results in boot hangup
> > Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST)
> >
> > > From: Yasuhiro Kimura 
> > > Subject: Updating EFI boot loader results in boot hangup
> > > Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)
> > >
> > >> I made regular update of my 14-CURRENT amd64 system from
> > >> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
> > >> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
> > >> boot hangup as following.
> > >>
> > >>
> > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
> > >>
> > >> If I restore previous loader file (that is, loader.efi of
> > >> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
> > >> system boots successfully.
> > >
> > > I submitted the problem to FreeBSD Bugzilla.
> > >
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825
> > >
> > > Best Regards.
> >
> > d98de744050 is committed. So I tested it with following steps.
> >
> > 1. Check out the commit.
> > 2. cd /usr/src/stand
> > 3. make
> > 4. make install
> > 5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd
> > 6. shutdown -r now
> >
> > And system boots successfully. But while efi loader is workding a lot
> > of messages are displayed as following.
> >
> >
> > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png
> 
> 
> Would you be able to share camcontrol devlist output? Privately if need be.
> And have any of these disks ever held ufs filesystems??
> 
> Warner
> 
> 
> > ---
> > Yasuhiro Kimura

Just a "me too" info. I have (usually not mounted for test) UFS on ada0.
(Now the UFS contains outdated [SVN era] root partition of main.)

% camcontrol devlist
          at scbus0 target 0 lun 0 (pass0,ada0)
   at scbus1 target 0 lun 0 (ses0,pass1)
  at scbus2 target 0 lun 1
(pass2,nda0)

% gpart show nda0
=>        40  3907029088  nda0  GPT  (1.8T)
          40        2008        - free -  (1.0M)
        2048     1126400     1  efi  (550M)
     1128448        2048     2  freebsd-boot  (1.0M)
     1130496  3770679296     3  freebsd-zfs  (1.8T)
  3771809792   135219200     4  freebsd-swap  (64G)
  3907028992         136        - free -  (68K)


% gpart show ada0
=>        40  3907029088  ada0  GPT  (1.8T)
          40        2008        - free -  (1.0M)
        2048     1126400     1  efi  (550M)
     1128448        2048     2  freebsd-boot  (1.0M)
     1130496  3749707776     3  freebsd-zfs  (1.7T)
  3750838272    20971520     4  freebsd-ufs  (10G)
  3771809792   135219200     5  freebsd-swap  (64G)
  3907028992         136        - free -  (68K)


-- 
Tomoaki AOKI    

From nobody Wed Aug 17 00:19:52 2022
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 4M6pYm6mcMz4ZrLM
	for ; Wed, 17 Aug 2022 00:19:56 +0000 (UTC)
	(envelope-from jbtakk@iherebuywisely.com)
Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [IPv6:2a0c:5a00:149::26])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M6pYm0d2nz43jj
	for ; Wed, 17 Aug 2022 00:19:56 +0000 (UTC)
	(envelope-from jbtakk@iherebuywisely.com)
Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com)
	by mailtransmit05.runbox.com with esmtps  (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.93)
	(envelope-from )
	id 1oO6mn-00DjxX-5y; Wed, 17 Aug 2022 02:19:53 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=iherebuywisely.com; s=selector2; h=Message-Id:In-Reply-To:Date:Subject:CC:
	To:From:MIME-Version:Content-Transfer-Encoding:Content-Type;
	bh=SURiXmbA5zZxoFArnoT3pQRj//V4JKa3Dq0zCYcWrpA=; b=VBFsSZP1U3cSL61mLxG3sqNH5r
	hs7Jl/r3aVdq8AGou0oauPN41ccHpqY2GwtkODjDM+E5zXQmRE/z7z1zlkFQvllvhLw/LC6Kelr0u
	RrOQIbc7CuvWQKbanNbv7OUuI4pS4yAsZNmBkQUjjUbiNIafv1uJtaxmQhTdOlwPltNgNsoWH8rf8
	wt2g73uZ7lenaaHJgE2NZfksZLlj0F0v8Xh68ggSf9UUo5y2DWfbDa39CnRrWio+QYHgOzanD+BkP
	mA11iCCb1FiDXQQA0cJ1HuwqY+xMa85vZixlSiJs4M2ecwVaxlrYSI9VYcz1wQi5blpnLTrjRHw2S
	RLYRhyqQ==;
Received: from [10.9.9.128] (helo=rmmprod06.runbox)
	by mailtransmit02.runbox with esmtp (Exim 4.86_2)
	(envelope-from )
	id 1oO6mm-0007dP-3P; Wed, 17 Aug 2022 02:19:52 +0200
Received: from mail by rmmprod06.runbox with local (Exim 4.86_2)
	(envelope-from )
	id 1oO6mm-0000HZ-2P; Wed, 17 Aug 2022 02:19:52 +0200
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
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
Received: from [Authenticated alias (650894)] by runbox.com with http
 (RMM6); Wed, 17 Aug 2022 00:19:52 GMT
From: "Jeffrey Bouquet" 
To: "Tomoaki AOKI" 
CC: "Warner Losh" ,
 "Yasuhiro Kimura" ,
 "FreeBSD Current" 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Tue, 16 Aug 2022 17:19:52 -0700 (PDT)
X-RMM-Aliasid: 650894
X-Mailer: RMM6
In-Reply-To: <20220817075532.56e144f2857ed45b298a6b1c@dec.sakura.ne.jp>
Message-Id: 
X-Rspamd-Queue-Id: 4M6pYm0d2nz43jj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none ("invalid DKIM record") header.d=iherebuywisely.com header.s=selector2 header.b=VBFsSZP1;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of jbtakk@iherebuywisely.com designates 2a0c:5a00:149::26 as permitted sender) smtp.mailfrom=jbtakk@iherebuywisely.com
X-Spamd-Result: default: False [-3.38 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.98)[-0.977];
	R_SPF_ALLOW(-0.20)[+ip6:2a0c:5a00:149::26];
	RCVD_IN_DNSWL_LOW(-0.10)[2a0c:5a00:149::26:from];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_PERMFAIL(0.00)[iherebuywisely.com:s=selector2];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[iherebuywisely.com:~];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:50304, ipnet:2a0c:5a00::/29, country:NO];
	RCVD_COUNT_FIVE(0.00)[5];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[iherebuywisely.com];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On Wed, 17 Aug 2022 07:55:32 +0900, Tomoaki AOKI  wrote:

> On Mon, 15 Aug 2022 21:35:52 -0600
> Warner Losh  wrote:
>=20
> > On Mon, Aug 15, 2022, 9:04 PM Yasuhiro Kimura  wrote:
> >=20
> > > From: Yasuhiro Kimura 
> > > Subject: Re: Updating EFI boot loader results in boot hangup
> > > Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST)
> > >
> > > > From: Yasuhiro Kimura 
> > > > Subject: Updating EFI boot loader results in boot hangup
> > > > Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)
> > > >
> > > >> I made regular update of my 14-CURRENT amd64 system from
> > > >> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updat=
ed
> > > >> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results =
in
> > > >> boot hangup as following.
> > > >>
> > > >>
> > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-bo=
ot-hangup.png
> > > >>
> > > >> If I restore previous loader file (that is, loader.efi of
> > > >> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), =
then
> > > >> system boots successfully.
> > > >
> > > > I submitted the problem to FreeBSD Bugzilla.
> > > >
> > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265825
> > > >
> > > > Best Regards.
> > >
> > > d98de744050 is committed. So I tested it with following steps.
> > >
> > > 1. Check out the commit.
> > > 2. cd /usr/src/stand
> > > 3. make
> > > 4. make install
> > > 5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd
> > > 6. shutdown -r now
> > >
> > > And system boots successfully. But while efi loader is workding a lot
> > > of messages are displayed as following.
> > >
> > >
> > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.ef=
i-loader-message.png
> >=20
> >=20
> > Would you be able to share camcontrol devlist output? Privately if need=
 be.
> > And have any of these disks ever held ufs filesystems??
> >=20
> > Warner
> >=20
> >=20
> > > ---
> > > Yasuhiro Kimura
>=20
> Just a "me too" info. I have (usually not mounted for test) UFS on ada0.
> (Now the UFS contains outdated [SVN era] root partition of main.)
>=20
> % camcontrol devlist
>           at scbus0 target 0 lun 0 (pass0,ada0)
>    at scbus1 target 0 lun 0 (ses0,pass1)
>   at scbus2 target 0 lun 1
> (pass2,nda0)
>=20
> % gpart show nda0
> =3D>        40  3907029088  nda0  GPT  (1.8T)
>           40        2008        - free -  (1.0M)
>         2048     1126400     1  efi  (550M)
>      1128448        2048     2  freebsd-boot  (1.0M)
>      1130496  3770679296     3  freebsd-zfs  (1.8T)
>   3771809792   135219200     4  freebsd-swap  (64G)
>   3907028992         136        - free -  (68K)
>=20
>=20
> % gpart show ada0
> =3D>        40  3907029088  ada0  GPT  (1.8T)
>           40        2008        - free -  (1.0M)
>         2048     1126400     1  efi  (550M)
>      1128448        2048     2  freebsd-boot  (1.0M)
>      1130496  3749707776     3  freebsd-zfs  (1.7T)
>   3750838272    20971520     4  freebsd-ufs  (10G)
>   3771809792   135219200     5  freebsd-swap  (64G)
>   3907028992         136        - free -  (68K)
>=20
>=20
> --=20
> Tomoaki AOKI    


Not following the thread closely, but should the CLI above be put in UPDATI=
NG for those, for example,
upgrading in-place from v13 to v14, with an explanation of why or what for?=
=20=

From nobody Wed Aug 17 11:48:33 2022
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 4M75rd2jnkz4ZF00
	for ; Wed, 17 Aug 2022 11:48:49 +0000 (UTC)
	(envelope-from vidwer@gmail.com)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M75rc09h8z43jk;
	Wed, 17 Aug 2022 11:48:48 +0000 (UTC)
	(envelope-from vidwer@gmail.com)
Received: by mail-ej1-x62d.google.com with SMTP id i14so24040172ejg.6;
        Wed, 17 Aug 2022 04:48:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=ygCEEux3h0ftIRNZ1gBceiCAhkUXg39LsquGLmJy/FM=;
        b=ABEUe+Id8ZvglR4T4tRXv482ye4RwUjjU03vzupADNBa8SmJc8KSyNU2EmYbayefw+
         j6soIQPkrj3PQFUtQTD2Pw+Gm8uc0Xduc4CDLKuPwxpQgzBKSiBWf3+0Bfc2Tb144dnM
         NacUk2pQ0uteqbhNsRCyBrkBoR4qQoe4jPLxy6q05gHTO2kCCdBbgLBM4O/3wL2K5P+a
         Ij3rOeyDJ49HPev6FJ/F7UuIjT9LJH260Y2UsjwGH1le47VdjTNa3FfphQzYq+9bW6O1
         Vw2BfTkXSmhZu7GDvTTEmIPnJjck5v9TsgjZzP6DBfR5WX1MKu2fyLL6GyJsaw/c7Y75
         +stg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=ygCEEux3h0ftIRNZ1gBceiCAhkUXg39LsquGLmJy/FM=;
        b=NFerele4XMyAbT/ioxmYs5tIkZ3Ii6dRB6kqoyeq3HGSEdGginoQCrCPYQpFSU+SDc
         D0hPxR9ZhdIk/aYQDQ20Y/Hko8X1dFaNEApaVn6dpWvsIRCgEJEfLHJS3iioBQrmfIN1
         z+7gP4jzJpVcxnsamMh+DtOYaTKl+QPwCksfsIE3stJuqetDHAaY2lDnXmPsQoAhnAAO
         c3eH2SrAmdfX6pp8dij8FMoqe+lu/+HrgEtAWtyAvU8dfW2FSuiXk5ehdQUaZUtoZBEA
         8aOvE4LoCZeYwYfbiZwLKpVZY+P1SyJT7gKsXV1ja+NPzeqUdpURW1b5/h5ExWC5dd1Z
         dlpQ==
X-Gm-Message-State: ACgBeo0g9Aw873feYHcq6PK4JbHtpqFxYCdaRB/Deu06slqJwKC3h4Vs
	iJb8fmbBGQBxvFiNHL49dDGoUrNFlXTGMET0HuD1rY2PQ/Teug==
X-Google-Smtp-Source: AA6agR4otYhQWKUjwBQGHwCgugrsnbdG9bHpUH8yfl+nwA98rkUH6J8N5NPNo4/Oo02nynG9TCFPjAkoMZfSbXu4m/Y=
X-Received: by 2002:a17:906:6a0f:b0:730:df34:6ec4 with SMTP id
 qw15-20020a1709066a0f00b00730df346ec4mr17155533ejc.659.1660736927049; Wed, 17
 Aug 2022 04:48:47 -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: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
 <20220814.063440.1883565953618972371.yasu@FreeBSD.org> <20220816.120142.317069615425604393.yasu@FreeBSD.org>
  <20220817075532.56e144f2857ed45b298a6b1c@dec.sakura.ne.jp>
In-Reply-To: <20220817075532.56e144f2857ed45b298a6b1c@dec.sakura.ne.jp>
From: Idwer Vollering 
Date: Wed, 17 Aug 2022 13:48:33 +0200
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: Tomoaki AOKI 
Cc: Warner Losh , Yasuhiro Kimura , 
	FreeBSD Current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4M75rc09h8z43jk
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=ABEUe+Id;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of vidwer@gmail.com designates 2a00:1450:4864:20::62d as permitted sender) smtp.mailfrom=vidwer@gmail.com
X-Spamd-Result: default: False [-3.76 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.97)[-0.974];
	NEURAL_HAM_MEDIUM(-0.79)[-0.790];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62d:from];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

$ sudo camcontrol devlist
          at scbus0 target 0 lun 0 (pass0,ada0)
          at scbus1 target 0 lun 0 (pass1,ada1)

$ gpart show ada0 ada1
=>        40  1953525088  ada0  GPT  (932G)
          40        1024     1  freebsd-boot  (512K)
        1064         984        - free -  (492K)
        2048     4194304     2  freebsd-swap  (2.0G)
     4196352  1949327360     3  freebsd-zfs  (930G)
  1953523712        1416        - free -  (708K)

=>        40  1953525088  ada1  GPT  (932G)
          40        1024     1  freebsd-boot  (512K)
        1064         984        - free -  (492K)
        2048     4194304     2  freebsd-swap  (2.0G)
     4196352  1949327360     3  freebsd-zfs  (930G)
  1953523712        1416        - free -  (708K)

Op wo 17 aug. 2022 om 00:56 schreef Tomoaki AOKI :
>
> On Mon, 15 Aug 2022 21:35:52 -0600
> Warner Losh  wrote:
>
> > On Mon, Aug 15, 2022, 9:04 PM Yasuhiro Kimura  wrote:
> >
> > > From: Yasuhiro Kimura 
> > > Subject: Re: Updating EFI boot loader results in boot hangup
> > > Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST)
> > >
> > > > From: Yasuhiro Kimura 
> > > > Subject: Updating EFI boot loader results in boot hangup
> > > > Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)
> > > >
> > > >> I made regular update of my 14-CURRENT amd64 system from
> > > >> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
> > > >> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
> > > >> boot hangup as following.
> > > >>
> > > >>
> > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
> > > >>
> > > >> If I restore previous loader file (that is, loader.efi of
> > > >> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
> > > >> system boots successfully.
> > > >
> > > > I submitted the problem to FreeBSD Bugzilla.
> > > >
> > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825
> > > >
> > > > Best Regards.
> > >
> > > d98de744050 is committed. So I tested it with following steps.
> > >
> > > 1. Check out the commit.
> > > 2. cd /usr/src/stand
> > > 3. make
> > > 4. make install
> > > 5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd
> > > 6. shutdown -r now
> > >
> > > And system boots successfully. But while efi loader is workding a lot
> > > of messages are displayed as following.
> > >
> > >
> > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png
> >
> >
> > Would you be able to share camcontrol devlist output? Privately if need be.
> > And have any of these disks ever held ufs filesystems??
> >
> > Warner
> >
> >
> > > ---
> > > Yasuhiro Kimura
>
> Just a "me too" info. I have (usually not mounted for test) UFS on ada0.
> (Now the UFS contains outdated [SVN era] root partition of main.)
>
> % camcontrol devlist
>           at scbus0 target 0 lun 0 (pass0,ada0)
>    at scbus1 target 0 lun 0 (ses0,pass1)
>   at scbus2 target 0 lun 1
> (pass2,nda0)
>
> % gpart show nda0
> =>        40  3907029088  nda0  GPT  (1.8T)
>           40        2008        - free -  (1.0M)
>         2048     1126400     1  efi  (550M)
>      1128448        2048     2  freebsd-boot  (1.0M)
>      1130496  3770679296     3  freebsd-zfs  (1.8T)
>   3771809792   135219200     4  freebsd-swap  (64G)
>   3907028992         136        - free -  (68K)
>
>
> % gpart show ada0
> =>        40  3907029088  ada0  GPT  (1.8T)
>           40        2008        - free -  (1.0M)
>         2048     1126400     1  efi  (550M)
>      1128448        2048     2  freebsd-boot  (1.0M)
>      1130496  3749707776     3  freebsd-zfs  (1.7T)
>   3750838272    20971520     4  freebsd-ufs  (10G)
>   3771809792   135219200     5  freebsd-swap  (64G)
>   3907028992         136        - free -  (68K)
>
>
> --
> Tomoaki AOKI    
>

From nobody Wed Aug 17 13:48:22 2022
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 4M78Vp0PfJz4ZVfM
	for ; Wed, 17 Aug 2022 13:48:34 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M78Vn73vsz3GDD
	for ; Wed, 17 Aug 2022 13:48:33 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660744114;
	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=iA4ebTekdzug4ttNHHrRe9LITs7VXn7qir+lGsDhmew=;
	b=AteS+aLYzTnHxK2F7hInCZuePpHKS+Q+Yh6n52AbRuZQls6ZWWyqjLPu0J1WsSO6aSlQuT
	oubdhXuEJlo9ji28V7Q1E/2FFzJWdRWbefilDjDa1ZHWoc7VmeZMgLousZKJ2VI5T1oZLL
	Al9quFttuWe4PNbcr4rFDumu7BLLjo0WXcK7iOcn14mHZ0dI2ENjLHjmaex6B97VWr/Z48
	CuPfSMyMsI791yWoY3Ch04yOWzwVzMP2XthgQPmY1Nsbhr5kAUFSyURJx5kgFB1iIamcZP
	5mMFKm4f4tGDENTQXH9bDcGrAiAishrVOqna37um5nfibOPa0swJ4DYt9WUOHQ==
Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M78Vn61hBz1NjD
	for ; Wed, 17 Aug 2022 13:48:33 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f53.google.com with SMTP id z185so3646230vsb.4
        for ; Wed, 17 Aug 2022 06:48:33 -0700 (PDT)
X-Gm-Message-State: ACgBeo3oh9t8EIFovIPWvnb1iUDgJYfAiiwJaxy3yzL2hl6+AtPg7AJk
	FeaaojrUvwsHUwEkQrUHo1+LNj7oIpsxdufLicM=
X-Google-Smtp-Source: AA6agR5lcPNvdhnZIMqp/jgY92uVuKXqOPkJnFDfulpiRNExWCZsbGsqJ83R28tjpxcWDZ09eP0igP1UNSZz6+2EtYA=
X-Received: by 2002:a67:bc13:0:b0:38c:b24f:2ee3 with SMTP id
 t19-20020a67bc13000000b0038cb24f2ee3mr3543vsn.11.1660744113385; Wed, 17 Aug
 2022 06:48:33 -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: Nuno Teixeira 
Date: Wed, 17 Aug 2022 14:48:22 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Windows Subsystem for FreeBSD?
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000f0f6aa05e6701e8e"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660744114;
	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=iA4ebTekdzug4ttNHHrRe9LITs7VXn7qir+lGsDhmew=;
	b=qhyAccorvTOSkvCf3mrOqimW1PBzVjr2qi7O75WhyfTO0a+T6OPd26SY0SOEU6KWRaik73
	hnq20zyeAhOn4gvRrrPXxShdRbKuzWMD5wR8mqD58MQdH/KbG6M5k9NcHk3YxhSx1ek4+f
	5FASiDZ4cAoqJtLHWqfnukA7oVj9QT+8UxE/Urjz9C3erGJEZkr1POC/oIXN3fdjJsNLB4
	SHvlqCV1VvoDGdJxdWEI8/yuD9ihrpTjmxz5vXGRc4xKJzaBPFgTPkz5wo0OQJMvkxAzNf
	eJm831Dsb/IQfhyKvM3wvshesqZjiDU3PsNAZ4uexCT+aya9Xi2XHknk7dpd2g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660744114; a=rsa-sha256; cv=none;
	b=e7lA98bykpeWjqMOIaUHiGL2CF0NLYB5CyXBgqBugYLvsIzZpb8wCB+qD7jrjIpGFiJgog
	mKApJdP4GsdbwpyWvT11QERsexbOorM/uPQNEl0+yoy6deNvrcmr5C383VVvPd8TuOCI43
	OpYUkfEQv8XcnNB4vtCc/SDyo8rxrgzyvQjuCcD9/cE1eE5j5fJ0lF+CCCHL+m3d2+/flt
	2XvmCfDqe9KVPZaIJLsYE3j3id7ou6kMA08j2BmzlvTxtL1r3tvZvlWfhG2Q/zPf1YVEti
	MiXNsKBQRRZCvAB1GUVHnUBcfRj8vZSdIjbGJechMikQ+3ZtPRLrIy3+xlxj3Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000f0f6aa05e6701e8e
Content-Type: text/plain; charset="UTF-8"

Hello to all!

Today I found a new thing that might be interesting:
Windows Subsystem for Linux or WSL (url here
)

I've didn't tried it yet but it makes me think if there are some advantages
if WS were available to FreeBSD.

Cheers,
-- 
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000f0f6aa05e6701e8e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello to all!

Today I found =
a new thing that might be interesting:
Windows Subsystem for Linu=
x or WSL (url her=
e)

I've didn't tried it yet but it=
 makes me think if there are some advantages if WS were available to FreeBS=
D.

Cheers,
-- 
Nuno Teixeira
FreeBSD Committer=
 (ports)


--000000000000f0f6aa05e6701e8e--

From nobody Wed Aug 17 14:01:50 2022
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 4M78pJ2fFNz4ZWwW
	for ; Wed, 17 Aug 2022 14:02:00 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4M78pH3mNBz3KmP;
	Wed, 17 Aug 2022 14:01:59 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 06E100;
 Wed, 17 Aug 2022 16:01:51 +0200
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 \(3696.120.41.1.1\))
Subject: Re: Windows Subsystem for FreeBSD?
From: "Patrick M. Hausen" 
In-Reply-To:
 
Date: Wed, 17 Aug 2022 16:01:50 +0200
Cc: FreeBSD CURRENT 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7301446A-A844-4A8A-B00B-1C0167D8C2F2@hausen.com>
References:
 
To: Nuno Teixeira 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4M78pH3mNBz3KmP
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of pmh@hausen.com has no SPF policy when checking 217.29.33.228) smtp.mailfrom=pmh@hausen.com
X-Spamd-Result: default: False [-0.60 / 15.00];
	AUTH_NA(1.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[hausen.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

Hi all,

> Am 17.08.2022 um 15:48 schrieb Nuno Teixeira :
> Today I found a new thing that might be interesting:
> Windows Subsystem for Linux or WSL (url here)
>=20
> I've didn't tried it yet but it makes me think if there are some =
advantages if WS were available to FreeBSD.

You understood this means running Linux applications
unmodified on Windows, not the other way round?

Kind regards,
Patrick=

From nobody Wed Aug 17 14:02:44 2022
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 4M78qB117Jz4ZXDD
	for ; Wed, 17 Aug 2022 14:02:46 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4M78q94bQNz3M7c;
	Wed, 17 Aug 2022 14:02:45 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 38578A;
 Wed, 17 Aug 2022 16:02:44 +0200
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 \(3696.120.41.1.1\))
Subject: Re: Updating EFI boot loader results in boot hangup
From: "Patrick M. Hausen" 
In-Reply-To:
 
Date: Wed, 17 Aug 2022 16:02:44 +0200
Cc: Tomoaki AOKI , Warner Losh ,
 Yasuhiro Kimura , FreeBSD Current
 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
 <20220814.063440.1883565953618972371.yasu@FreeBSD.org>
 <20220816.120142.317069615425604393.yasu@FreeBSD.org>
 
 <20220817075532.56e144f2857ed45b298a6b1c@dec.sakura.ne.jp>
 
To: Idwer Vollering 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4M78q94bQNz3M7c
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of pmh@hausen.com has no SPF policy when checking 217.29.33.228) smtp.mailfrom=pmh@hausen.com
X-Spamd-Result: default: False [-1.60 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE];
	FREEMAIL_TO(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[hausen.com];
	R_SPF_NA(0.00)[no SPF record];
	RCPT_COUNT_FIVE(0.00)[5];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi all,

> Am 17.08.2022 um 13:48 schrieb Idwer Vollering :
> 
> $ sudo camcontrol devlist
>           at scbus0 target 0 lun 0 (pass0,ada0)
>           at scbus1 target 0 lun 0 (pass1,ada1)
> 
> $ gpart show ada0 ada1
> =>        40  1953525088  ada0  GPT  (932G)
>          40        1024     1  freebsd-boot  (512K)
>        1064         984        - free -  (492K)
>        2048     4194304     2  freebsd-swap  (2.0G)
>     4196352  1949327360     3  freebsd-zfs  (930G)
>  1953523712        1416        - free -  (708K)
> 
> =>        40  1953525088  ada1  GPT  (932G)
>          40        1024     1  freebsd-boot  (512K)
>        1064         984        - free -  (492K)
>        2048     4194304     2  freebsd-swap  (2.0G)
>     4196352  1949327360     3  freebsd-zfs  (930G)
>  1953523712        1416        - free -  (708K)

This system uses legacy boot, not EFI.

Kind regards,
Patrick

From nobody Wed Aug 17 14:24:46 2022
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 4M79KJ33J1z4ZZhk
	for ; Wed, 17 Aug 2022 14:25:24 +0000 (UTC)
	(envelope-from miguelmclara@gmail.com)
Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [IPv6:2001:4860:4864:20::2a])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M79KH5grPz3QPL;
	Wed, 17 Aug 2022 14:25:23 +0000 (UTC)
	(envelope-from miguelmclara@gmail.com)
Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-11c4d7d4683so2137572fac.8;
        Wed, 17 Aug 2022 07:25:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=Ste+UwE3/Khmeiq2DYm8TQKa3ezL6gQCOuIyHKduykg=;
        b=A9SOYZ6jKvCqqecnZ8RD7+pDhQVigGo556sB3ggkOie1VcaySS4K2h40l+781Ehi0o
         /mUKwdK8ydYzDPS5ynZjD/f1GBgHX4/QQheLwuOwlCskaC8FG+Cg4tFl9/ul181u1hfM
         fQxlgwu3YW2MdzmksXLe+CCVnX4sCCeRd8a01cEFrPB5WjAjf0RsPB7ZEv1WEMXMLIBV
         +USThhqyOEVKLX42vMPWJDVykzl1ZcGJfwzH1hcqOC9bRK0hfiqQhRVsf7eAoXU4JybU
         tggHzK+0TpyI8UdExNIp07CFUVlumQYA+65GDvaRTTV7xtBJIPVcLqUCnm7ZG9ZxHug3
         PvGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=Ste+UwE3/Khmeiq2DYm8TQKa3ezL6gQCOuIyHKduykg=;
        b=IgmkaNE1SRaK/ymoBjv+OaZPPdhf4FgZ96HQO6bQ36oPnMf2qK+DKNA0mSIAnTqtux
         OxClIu7SLG6JnupIEgcWYYSaklUJu8JQJVdGFzb9h3LiIYvH9mtkhuRuLFxx8ihnOQP1
         EO0j35Zg8yGgtaWIfpjAq7CYwmmF4kl/aogDZsdg/E8M02SxlckULuywz5O2E6PbBvqk
         KYAECQcRK+PW8TNF5uzYSmIhgU/xirno3uD5b7QJKdxa11MclHnEg0866eZ+pxKZJqh8
         aJb3wIZJZnNhL4N8thvmgMbG70aikX/JCzgsY6wGupyQLgrNkSP73faJ5qWm7ucx+ifj
         oX+Q==
X-Gm-Message-State: ACgBeo3R7yaXwUf9NFQT1B58DInv8EOnapk5nzVWGNHjRYN8JiGX/vN+
	+s2DinQxTzA/mkpuPvWP9rlMFXrRh4LgHWMCDIhDwx/PXcY=
X-Google-Smtp-Source: AA6agR6Q4BmyXJ6Kw1g2bDPGuwb5hycHIuMzSEIRJRX9nAcSfF1QLyliR6kmZ5JL+CsbS47tIt3CF87Exj0aENsp8k8=
X-Received: by 2002:a05:6870:d38c:b0:10e:daa7:da69 with SMTP id
 k12-20020a056870d38c00b0010edaa7da69mr1741706oag.61.1660746322495; Wed, 17
 Aug 2022 07:25:22 -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: Miguel C 
Date: Wed, 17 Aug 2022 15:24:46 +0100
Message-ID: 
Subject: Re: Windows Subsystem for FreeBSD?
To: Nuno Teixeira 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000009d4e9205e670a2f2"
X-Rspamd-Queue-Id: 4M79KH5grPz3QPL
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=A9SOYZ6j;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of miguelmclara@gmail.com designates 2001:4860:4864:20::2a as permitted sender) smtp.mailfrom=miguelmclara@gmail.com
X-Spamd-Result: default: False [-2.76 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-0.99)[-0.994];
	NEURAL_HAM_SHORT(-0.99)[-0.986];
	NEURAL_HAM_MEDIUM(-0.78)[-0.779];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCPT_COUNT_TWO(0.00)[2];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::2a:from];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000009d4e9205e670a2f2
Content-Type: text/plain; charset="UTF-8"

I've used it quite a bit on Windows since the early days.

In WSL v1 it was pretty much what linuxolator is in FreeBSD, it was just
emulation and translation of syscalls from linux to windows and it was
mostly limited in the same way linux emulation is on FreeBSD in fact GUI
wise I'de say it was much more limited since i.e one could not run GUI
Linux apps on Windows or call Windows GUI apps on WSL, you couldn't even
run services that require a network layer, like nginx mysql etc.

However, it has evolved since and with WSL2 all of the above is possible,
this is because they are using an approach similar to how docker runs on
macOS, it's a lightweith Linux VM running the linux kernel, no need for
syscall translation.

I'm not sure if you mean bring this to FreeBSD as in Linux Subsystem as
implemented here to FreeBSD or have WSL also run FreeBSD not just Linux.

But the latter makes no sense, this would need to be done by Microsoft and
I'm not quite sure if there's any advantage to them.

However, if you mean to achieve the same level of linux compatibility, that
would be quite interesting, I think linux emulation was always a great
thing on FreeBSD but it was always limited in the same ways as WSL1.


One of the advantage of having something like this might be finally getting
docker on a FreeBSD host. This is after all how it works on macOS, and on
recent versions its actually using apple's lightweight hypervisor aka
"hypervisor.framework". And of course it would allow FreeBSD desktop users
to run some software that only works on Linux but without the limitations
of not being able to handle all miscalls.

--0000000000009d4e9205e670a2f2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I've used it quite a bit on Windows since the ear=
ly days.

In WSL v1 it was pretty much what linuxol=
ator is in FreeBSD, it was just emulation and translation of syscalls from =
linux to windows and it was mostly limited in the same way linux emulation =
is on FreeBSD in fact GUI wise I'de say it was much more limited since =
i.e one could not run GUI Linux apps on Windows or call Windows GUI apps on=
 WSL, you couldn't even run services that require a network layer, like=
 nginx mysql etc.

However, it has evolved sinc=
e and with WSL2 all of the above is possible, this is because they are usin=
g an approach similar to how docker runs on macOS, it's a lightweith Li=
nux VM running the linux kernel, no need for syscall translation.

I'm not sure if you mean bring this to FreeBSD as in Li=
nux Subsystem as implemented here to FreeBSD or have WSL also run FreeBSD n=
ot just Linux.

But the latter makes no sense, this=
 would need to be done by Microsoft and I'm not quite sure if there'=
;s any advantage to them.

However, if you mean to =
achieve the same level of linux compatibility, that would be quite interest=
ing, I think linux emulation was always a great thing on FreeBSD but it was=
 always limited in the same ways as WSL1.


One =
of the advantage of having something like this might be finally getting doc=
ker on a FreeBSD host. This is after all how it works on macOS, and on rece=
nt versions its actually using apple's  lightweight hypervisor aka &quo=
t;hypervisor.framework". And of course it would allow FreeBSD desktop =
users to run some software that only works on Linux but without the limitat=
ions of not being able to handle all miscalls.





--0000000000009d4e9205e670a2f2--

From nobody Wed Aug 17 14:35:58 2022
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 4M79YW5JQrz4Zbn2
	for ; Wed, 17 Aug 2022 14:35:59 +0000 (UTC)
	(envelope-from 01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@amazonses.com)
Received: from a8-86.smtp-out.amazonses.com (a8-86.smtp-out.amazonses.com [54.240.8.86])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M79YW0TF3z3Rq2
	for ; Wed, 17 Aug 2022 14:35:59 +0000 (UTC)
	(envelope-from 01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@amazonses.com)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1660746958;
	h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type:Content-Transfer-Encoding:Feedback-ID;
	bh=YUbRO++jGMMUFTsuZrkY+WukA7LKZZjogIVGvzFoogM=;
	b=YArWuxjhDXiBkJDCaByEaGLn0C0ZILvPMG27bdMIMrDgrRUns/luKP8oGdoUjUJD
	kX4bpbuiXtGrJ/OWqxBRCTf1uW+9l4biiDeHyta7mCmOOLdNQ7pZ4R5OIlQThPdD1k9
	37p1GdvrtOk89ghMr5XtU9tehPLYQhLl9F+NcPMg=
Message-ID: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
Date: Wed, 17 Aug 2022 14:35:58 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
To: Current FreeBSD 
From: Thomas Laus 
Subject: Beadm can't create snapshot
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES
X-SES-Outgoing: 2022.08.17-54.240.8.86
X-Rspamd-Queue-Id: 4M79YW0TF3z3Rq2
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=YArWuxjh;
	dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=acm.org (policy=none);
	spf=pass (mx1.freebsd.org: domain of 01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@amazonses.com designates 54.240.8.86 as permitted sender) smtp.mailfrom=01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@amazonses.com
X-Spamd-Result: default: False [-0.60 / 15.00];
	FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	FORGED_SENDER(0.30)[lausts@acm.org,01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@amazonses.com];
	R_DKIM_ALLOW(-0.20)[amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw];
	R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[acm.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none];
	FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@amazonses.com];
	RCVD_COUNT_ZERO(0.00)[0];
	ASN(0.00)[asn:14618, ipnet:54.240.8.0/21, country:US];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[54.240.8.86:from];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[amazonses.com:+];
	RCVD_IN_DNSWL_NONE(0.00)[54.240.8.86:from];
	FROM_HAS_DN(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[amazonses.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

I attempted to create a ZFS snapshot after upgrading this morning and 
received this error

# beadm create n257443
cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly
#

My version info:

14.0-CURRENT FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed Aug 
17 08:15:27 EDT 2022

There was not any information in UPDATING about any required ZFS 
configuration changes required nor any ZFS flags that listed 
'snapshots_changed' as something that needed a new value.  There is 
actually a new snapshot created, but 'beadm list' does not show it and 
the boot menu does not have it listed.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

From nobody Wed Aug 17 15:10:04 2022
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 4M7BJt6l4rz4ZgLp
	for ; Wed, 17 Aug 2022 15:10:06 +0000 (UTC)
	(envelope-from 01000182ac5ac00f-938914eb-d1ee-44cb-bc22-8090b7f9a877-000000@amazonses.com)
Received: from a48-102.smtp-out.amazonses.com (a48-102.smtp-out.amazonses.com [54.240.48.102])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7BJs6vmyz3WLJ
	for ; Wed, 17 Aug 2022 15:10:05 +0000 (UTC)
	(envelope-from 01000182ac5ac00f-938914eb-d1ee-44cb-bc22-8090b7f9a877-000000@amazonses.com)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1660749004;
	h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type:Content-Transfer-Encoding:Feedback-ID;
	bh=9mXgx8zv8T/QwzHoM9JWqYIKsmFpCZJHVchsIIS6XHE=;
	b=PzPAxBUC6RWe/f5mNbk1kJfKlqoG8iPaiJNwn8NyNmtwCnpEmG/TV0VB+zFDwU3S
	xem6+HWZgUY9P6lY9AucLzRJZ57ekFvJ8CQu/oEUdf834uoUE77gt1HN7FvRWwRV6K/
	XkUw4+Y6l6TfsmBV8nGD3xq0Ev54x7QMXBbGAFnY=
Message-ID: <01000182ac5ac00f-938914eb-d1ee-44cb-bc22-8090b7f9a877-000000@email.amazonses.com>
Date: Wed, 17 Aug 2022 15:10:04 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
To: Current FreeBSD 
From: Thomas Laus 
Subject: Non EFI boot issue
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES
X-SES-Outgoing: 2022.08.17-54.240.48.102
X-Rspamd-Queue-Id: 4M7BJs6vmyz3WLJ
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=PzPAxBUC;
	dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=acm.org (policy=none);
	spf=pass (mx1.freebsd.org: domain of 01000182ac5ac00f-938914eb-d1ee-44cb-bc22-8090b7f9a877-000000@amazonses.com designates 54.240.48.102 as permitted sender) smtp.mailfrom=01000182ac5ac00f-938914eb-d1ee-44cb-bc22-8090b7f9a877-000000@amazonses.com
X-Spamd-Result: default: False [-0.60 / 15.00];
	FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	FORGED_SENDER(0.30)[lausts@acm.org,01000182ac5ac00f-938914eb-d1ee-44cb-bc22-8090b7f9a877-000000@amazonses.com];
	R_DKIM_ALLOW(-0.20)[amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw];
	R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[acm.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none];
	FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,01000182ac5ac00f-938914eb-d1ee-44cb-bc22-8090b7f9a877-000000@amazonses.com];
	RCVD_COUNT_ZERO(0.00)[0];
	ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[54.240.48.102:from];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[amazonses.com:+];
	RCVD_IN_DNSWL_NONE(0.00)[54.240.48.102:from];
	FROM_HAS_DN(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[amazonses.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

Another issue with the update today.  This update went well on all of my 
PC's that use EFI but spews a lot of disturbing messages on my only 
laptop without an EFI BIOS:

Attempted recovery for standard superblock: failed
Attempt to find boot zone recovery data: failed

It jumps to what is normally Menu item 6 and then successfully boots.

My update version information:

FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed Aug 17 08:15:27 
EDT 2022

All of my gpart utilities list, show and status have no errors.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

From nobody Wed Aug 17 16:05:09 2022
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 4M7CXQ4FHvz4ZnPb
	for ; Wed, 17 Aug 2022 16:05:10 +0000 (UTC)
	(envelope-from freqlabs@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7CXQ3gJyz3ftN
	for ; Wed, 17 Aug 2022 16:05:10 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660752310;
	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=96bCpVZCV/7ge2wXiiVIews0njkLjL1jRTTbJjj1890=;
	b=pAwlRLquGmQf9eYdJo6ci6v+5g8nZPOPzpL39kmvuUEAE8VvCHrHuCmTX4Akadq+8emof1
	w6dlrM/3FoI0MHGcCRjN9jow8UnPQS5uN3ab0lN0i2fFfPukUCdwd/7NdaJcew9oWzjABT
	xyQ5tpPwsg6YaUOCIfJ313PmhrhMohKb/299ZvJjzc1+p0fHgtFkMhyX9eSRcVBz4u4h+M
	sq0ryNG75WDnqMEIqIBFfu/aXXH5XGKQWmNZdv/BWXAgrfZVfggO6zi9oGFXkwGPqQYRvO
	QAfBkKnr3w7olNok0RgDTwTndU/sH9qCbNFVe5I8Pn/KSJomolzomcMKicWWGQ==
Received: from [IPV6:2600:1700:358a:c660:c42c:7b9a:d43a:a950] (unknown [IPv6:2600:1700:358a:c660:c42c:7b9a:d43a:a950])
	(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: freqlabs/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M7CXQ2GTdz1QMq
	for ; Wed, 17 Aug 2022 16:05:10 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
Message-ID: <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
Date: Wed, 17 Aug 2022 12:05:09 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.12.0
Subject: Re: Beadm can't create snapshot
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
From: Ryan Moeller 
In-Reply-To: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660752310;
	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=96bCpVZCV/7ge2wXiiVIews0njkLjL1jRTTbJjj1890=;
	b=avqWZZTgTOk8dHIpjfRxF9oK6by69oGyC6+MIZgg8oy+j2Qu9Y8S+N35aSEakeB/MGiafk
	Z/yHevZUNuPHYUaR/OiZrA42i1BfNhn+b9FLpOJTh9v4PsHmgNPkLH43AUXVXTqBN9e79K
	EB8xEKAahl3kywjZWLKcjuWqMcBV52KMiV/1mk1sUnXwV/iUGt/gUNI26et1fyu02NXXi2
	Wx6s6SiCEV452Qug+hHBr7MbO8zTOEfqSK8uoVrLUTKIsFSTtts93FgDDehcrTWWXy1yjC
	jwep1+7LOm8MYTlu9vP9x00An5mSpvB+VVOjgsLl3/KKeYMnskSlDWzOB0dk3g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660752310; a=rsa-sha256; cv=none;
	b=Mx+ruJtqJxZApUJwBG0HchrMiHQ+6nj3Yd3Ssqnijg8pCJeow/EWbTE5Qwyol7BWKBrVYk
	IScD6+A3gdU6VVIA+18qukY6lBc6Mxe59ZKf0vdxrHgqRTLrzBLmqI5sxDGwwSSK+7gCVa
	XIVj83OxSyfivkB91Edu49HLnmbLZYH949UlFF91OINJJCRzC7NA2TDx3fHlyDAmMSmogG
	9pgfXD9DonVz7ZI/TCe9/s8DIvnF0ekXZ5ESdemQslCIhuc7tfZylvpzr+T/ps4VeIHacC
	o2gtnpj8RsnitclFSBo5nxvdRXTpF7lZwrXE1/gHT+s6FbVAVBvAvJ0gYxckVw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


On 8/17/22 10:35 AM, Thomas Laus wrote:
> I attempted to create a ZFS snapshot after upgrading this morning and 
> received this error
>
> # beadm create n257443
> cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly
> #


This looks like a bug in beadm. It must be trying to set the 
snapshots_changed property when cloning the snapshot for the BE, but the 
property is of course readonly.

-Ryan


>
> My version info:
>
> 14.0-CURRENT FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed Aug 
> 17 08:15:27 EDT 2022
>
> There was not any information in UPDATING about any required ZFS 
> configuration changes required nor any ZFS flags that listed 
> 'snapshots_changed' as something that needed a new value.  There is 
> actually a new snapshot created, but 'beadm list' does not show it and 
> the boot menu does not have it listed.
>
> Tom
>

From nobody Wed Aug 17 16:07:20 2022
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 4M7Cb01njMz4ZnZC
	for ; Wed, 17 Aug 2022 16:07:24 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4M7CZz2zG7z3gyk
	for ; Wed, 17 Aug 2022 16:07:23 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 3FF3E8;
 Wed, 17 Aug 2022 18:07:21 +0200
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 \(3696.120.41.1.1\))
Subject: Re: Beadm can't create snapshot
From: "Patrick M. Hausen" 
In-Reply-To: <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
Date: Wed, 17 Aug 2022 18:07:20 +0200
Cc: freebsd-current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:
 <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
To: Ryan Moeller 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4M7CZz2zG7z3gyk
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of pmh@hausen.com has no SPF policy when checking 217.29.33.228) smtp.mailfrom=pmh@hausen.com
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE];
	R_SPF_NA(0.00)[no SPF record];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[hausen.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi all,

> Am 17.08.2022 um 18:05 schrieb Ryan Moeller :
>=20
>=20
> On 8/17/22 10:35 AM, Thomas Laus wrote:
>> I attempted to create a ZFS snapshot after upgrading this morning and =
received this error
>>=20
>> # beadm create n257443
>> cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly
>> #
>=20
>=20
> This looks like a bug in beadm.

Isn't beadm retired in favour of bectl?

Kind regards,
Patrick=

From nobody Wed Aug 17 16:16:49 2022
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 4M7Cnt5YVNz4ZpbL
	for ; Wed, 17 Aug 2022 16:16:50 +0000 (UTC)
	(envelope-from freqlabs@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7Cnt4BJ8z3k5K
	for ; Wed, 17 Aug 2022 16:16:50 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660753010;
	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=CiCRvPnEhTpAuKfTsl/ayTTv00MrVElPAubAaD5COE0=;
	b=hj7lRSfX4ZHMZ8Wrv7Ufdo2DknRlyufN4HXlnVerfRw4jvzz2BlC60V1XLp7DbVnHv7g4Q
	YBVB0czrq/eUwm3txBjaSrkMrFdt1DbXaW99z9dIZNEEflSAO0xyiAf/IiXJkJWvInj79W
	7XlRTC7ZwfkMEK0gz9AtA7/2IJa/l/rpeZex3uO3+Ra82/3iCeoxQNJEWrxEQWWno0UjWy
	o8+xCnAF4Ch2+eeXNca74qJ4ektSFvxcItEchJSTF4wWKT8kVWXrgxXeZdpIeJZIRIZ5SA
	+mhJxVaxRWg/NX2eaV26NRXMsSJh8eAbFUFnqLZl/gU0WhSN2d/51ZCV5jcIYQ==
Received: from [IPV6:2600:1700:358a:c660:c42c:7b9a:d43a:a950] (unknown [IPv6:2600:1700:358a:c660:c42c:7b9a:d43a:a950])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: freqlabs/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M7Cnt2gGHz1QtK
	for ; Wed, 17 Aug 2022 16:16:50 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
Message-ID: 
Date: Wed, 17 Aug 2022 12:16:49 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.12.0
Subject: Re: Beadm can't create snapshot
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
From: Ryan Moeller 
In-Reply-To: <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660753010;
	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=CiCRvPnEhTpAuKfTsl/ayTTv00MrVElPAubAaD5COE0=;
	b=MmMZw9scbd37sHXTsjHVH2oOOMukJBFg0bByJf/xfYAQO2APJSMHdnZz/qsUkGDcSaxyGH
	aqwZEIXTW8IIdw8J1xRrM3yss7ExGzO4Mgm/SwyPE/3jlpDYC+7VYhXBkXX7PMwHs9o7Yz
	LJ9Dg+7HPzZ90fhzSOnNb51GVLVJXWKzD6G7VGIqzEjabdmCxa+43INgjnpsqcl3CSgOZE
	4GBWR/nJExeeil6DOEV+vGpsmZ/G8j8Qn+D66fkT7hxkvUOvGSqPEWNwCwoptNSeCaG40A
	ecNtWYNWKNzAw0v57uvoBlJyz8b2kUqIOMgv5fy51qpIXjcEmwyYASigKKuPIg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660753010; a=rsa-sha256; cv=none;
	b=RSvbi3RxBduNcShPJ1tHuVq/6kJ2IgmZ3BM9010PAw9M5kvPZvxfWVUv9la7Fy0xs1lp0O
	AXAn4JyFtE3q2hZEMr78SF1XGxNIXhRCDt8rBhZHUyzrzRKmp7+2cvkMVyrO+j5plIOHMM
	y9gpHDSYSJcKFaeJz8+jVtZVWVFBwTjBfW6yxLTQhLToxZ3bXu58+cbPlAMSbX9RjHpTdy
	f626c34O2viRxUB92woOg8AHHyRj1a5R1gDzlLBfnq3jQpPtQD9Gt0OK14UgLffHKuAV8t
	XG8Ua8nTVwmPWc386SPMT8FbUeJigwcOFdrSGXlkTFcegqyajNRNt3SRQdmkvg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


On 8/17/22 12:05 PM, Ryan Moeller wrote:
>
> On 8/17/22 10:35 AM, Thomas Laus wrote:
>> I attempted to create a ZFS snapshot after upgrading this morning and 
>> received this error
>>
>> # beadm create n257443
>> cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly
>> #
>
>
> This looks like a bug in beadm. It must be trying to set the 
> snapshots_changed property when cloning the snapshot for the BE, but 
> the property is of course readonly.
>
> -Ryan
>

I took a closer look at what beadm is doing and this appears to be a bug 
in the property after all. beadm filters by source "local" or "received" 
and for "snapshots_changed" the source is "local" when it should be "-" 
like other readonly properties. We'll get this fixed ASAP.

-Ryan


>
>>
>> My version info:
>>
>> 14.0-CURRENT FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed 
>> Aug 17 08:15:27 EDT 2022
>>
>> There was not any information in UPDATING about any required ZFS 
>> configuration changes required nor any ZFS flags that listed 
>> 'snapshots_changed' as something that needed a new value.  There is 
>> actually a new snapshot created, but 'beadm list' does not show it 
>> and the boot menu does not have it listed.
>>
>> Tom
>>
>

From nobody Wed Aug 17 18:14:38 2022
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 4M7GQ32ZTTz4Ys5x
	for ; Wed, 17 Aug 2022 18:14:51 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7GQ327cfz449L
	for ; Wed, 17 Aug 2022 18:14:51 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660760091;
	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=ME2r25cGse3I7TJhMtBDDPqKB66INlvk1tnbvDThoow=;
	b=SiQU/NllOqEFH62KSsDOcE40XDrDPOy6z2rL55+jSXBj+yuF2rYA0iIepHpks1puhFQYxV
	fdTyEUk2Z4XnJz2Fcz45HNWLubHgn9InNUQjEk4vIxL9Rb+Pm0X1XD7MB4NoMXgyicyUKO
	se+kXNlO0HItqhYgWSAOYqBzhYtFV+agI4vGf8p+E+jg9lKxLCAGTnVwjsHx4UUEi9nqQX
	fqHUEBV7xKiZv8HLjhG2WYPgw1IZ6p9vG7DMnaosNcBIs/Ggi4IjBYHdgZitoiHJOkHJ5P
	F2ulWAxckTTGkrQ/jiHIB4Y5DvlPGjw9urjtW08lBZ7vuThsbao4LSH8Hq3r/Q==
Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M7GQ315GZz1Rv3
	for ; Wed, 17 Aug 2022 18:14:51 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f48.google.com with SMTP id n125so7685186vsc.5
        for ; Wed, 17 Aug 2022 11:14:51 -0700 (PDT)
X-Gm-Message-State: ACgBeo0G6/mRTfX43GGjuUo31LnqP6iU3MejhrHnji3DCfvofqFZsBSX
	kDWLdcnriOC34i2ieLxIbPjGUP8TcYvLilnv7Gc=
X-Google-Smtp-Source: AA6agR4C42z0ehMwWU7migLLreqYwysxNZ+RA5JsRr5c7I1dK5Y2ZNiNjDGi1vM1LbIa+dL9YGg9bUrlsBSYZnqRsss=
X-Received: by 2002:a05:6102:2836:b0:386:91a5:a241 with SMTP id
 ba22-20020a056102283600b0038691a5a241mr10780239vsb.51.1660760090599; Wed, 17
 Aug 2022 11:14:50 -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: 
 <62B26DE1-0E26-40BA-8647-E591E9ACEB7A@me.com> 
 
In-Reply-To: 
From: Nuno Teixeira 
Date: Wed, 17 Aug 2022 19:14:38 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: 24.3. Updating Bootcode
To: Warner Losh 
Cc: Toomas Soome , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="00000000000041e90905e673d76f"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660760091;
	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=ME2r25cGse3I7TJhMtBDDPqKB66INlvk1tnbvDThoow=;
	b=ZGzv8oWbWVH7aVD1dRyFhAqoLgJLr4i5Q6tOULAMkkTyIL0XW4BsalLgahEE68DD1HOTu1
	QqgjFjGUNKfFzH4pCgt+bCXDS+9OwycGqSvZNvkhrhXg+m9lW51zuji96ca1gMmaqlZvdV
	SZUvhKrA71trf59wb1Cojm61/9do6rUCoQwGrRGWszEg0IWsLzYfeRpiBeedlEp8/XaeXA
	pBT0DF+wvnmMOwLWYBFx7fyXqB/x2IkbeMYQNlGOMrG8nTiejz5fBulZ0yPi56kGSCdAQC
	b5CLL5Kkow3EIZ+jj1+Hi4Dvw42jKXvSgKgeion5GAaRKUjERD4aEJmO1QxllQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660760091; a=rsa-sha256; cv=none;
	b=MaxSaEmasH39U6afTKEbi1ZV8QQwxm8dlPtOqK6oNxX01CZYbd3WT0pNvPROEx9V1CNdA7
	7Fug+FMimGOuE1Kk/cl0xSdR3R9RI3baboKbmkNbvWC3diAvE3nUCaUAuBdSgpwFZKwX61
	/7k3FwPOXIYPVznmX7n8754QIzpgnKRT3JqLaGhcLLKO2PEbCKX7j7rfw7eW8Rpk51SM0u
	P9ZvPKFoR00Mt+CzHJBhm/SwrtNfKfCNfkE8bLd5CuRV5WFf34V41zjNqg4r32Wl44lrJA
	KYRG3oMXb714jnLXuXs/nYtjgE1Bb0SOmBadxLf3F795l6OiFCGtXwQZY2RD9g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--00000000000041e90905e673d76f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

And it's done:
---
 Boot0007* FreeBSD-14
HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\freeb=
sd\loader.efi)
                         nvd0p1:/efi/freebsd/loader.efi
/boot/efi//efi/freebsd/loader.efi
+Boot0006* FreeBSD-14_old
HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\freeb=
sd\loader-old.efi)
                             nvd0p1:/efi/freebsd/loader-old.efi
/boot/efi//efi/freebsd/loader-old.efi
 Boot0004* Windows Boot Manager
HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Micr=
osoft\Boot\bootmgfw.efi)
                                   da1p1:/EFI/Microsoft/Boot/bootmgfw.efi
(null)
 Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/H=
D(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
---
and I can choose "FreeBSD-14"(/efi/freebsd/loader.efi),
"FreeBSD-14_old"(/efi/freebsd/loader-old.efi) and "EFI Hard
Drive"(legacy /efi/bootx64.efi) from BIOS.

NOTE: efibootmgr(8) example is:
---
efibootmgr -a -c -l /boot/efi/EFI/freebsd/loader.efi -L FreeBSD-11
                                          ^^^
---
But I choosed "efi" instead of "EFI"...

Thanks all for helping me understand it!

Cheers,


Warner Losh  escreveu no dia ter=C3=A7a, 16/08/2022 =C3=A0(=
s) 18:19:

>
>
> On Tue, Aug 16, 2022 at 6:01 AM Nuno Teixeira  wrote=
:
>
>> Hi Toomas,
>>
>> For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page
>>> 499) is suggesting to use structure like:
>>>
>>> /efi//=E2=80=A6
>>>
>>> And to use this suggestion, it means the UEFI Boot Manager needs to be
>>> configured (see efibootmgr(8)).
>>>
>>> Therefore, once you have set up OS specific setup, there is no use for
>>> default (/efi/boot/=E2=80=A6) and you need to update one or anothe=
r, but not
>>> both.
>>>
>>
>> FreeBSD have /efi/freebsd/... but it's not configured in efibootmgr=
:
>>
>
> The current default installer will do this, but older upgraded systems
> don't do this by default. Likely you are looking at an older
> system and/or one of the 'bad actors' that reset this stuff between boots=
.
>
>
>> efibootmgr -v:
>> ---
>> BootOrder  : 0004, 0000, 2002, 2003, 2001
>> Boot0004* Windows Boot Manager
>> HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\M=
icrosoft\Boot\bootmgfw.efi)
>>                                    da0p1:/EFI/Microsoft/Boot/bootmgfw.ef=
i
>> (null)
>> +Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
>> PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00=
)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
>>  Boot2002* EFI DVD/CDROM
>>  Boot2003* EFI Network
>>  Boot2001* EFI USB Device
>> ---
>> so boot is definitely using /efi/boot/bootx64.efi @Boot0000
>>
>
> In your case, that's true. The "EFI Hard Drive" is a default entry the
> UEFI BIOS created for you.
>
>
>> I think I can create a new boot:
>> ---
>> efibootmgr -a -c -l /boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
>> (and make it active)
>> efibootmgr -a -b NNNN
>> ---
>> and create other for loader.efi.old in case of problems.
>>
>
> Yes.
>
>
>> In this case I will need only update /efi/freebsd/loader.efi.
>>
>> Q: for what has been said in mailing, boot is compiled in /usr/src/stand=
,
>> isn't a good idea that when it install new boot it backup old boot like
>> /boot/kernel -> /boot/kernel.old?
>>
>
> Yes. In fact that's what's done, but only for the BIOS version. We should
> do the same for efi but don't seem to do so currently. But that's likely
> tied up behind issues of installing things automatically into the ESP on
> 'installworld'.
>
> Warner
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--00000000000041e90905e673d76f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

And it's done:
=

---
=C2=A0Boot0007* FreeBSD-14 HD(1,GPT,73acd1b2-de41-11eb-8=
156-002b67dfc673,0x28,0x82000)/File(\efi\freebsd\loader.efi)
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0nvd0p1:/efi/freebsd/loader.efi /boot/efi//efi/freebsd/loader.efi
+=
Boot0006* FreeBSD-14_old HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28=
,0x82000)/File(\efi\freebsd\loader-old.efi)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0nvd0p1:/efi/freebsd/loader-old.efi /boot/efi//efi/freebsd/loader-old.efi=

=C2=A0Boot0004* Windows Boot Manager HD(1,GPT,8c497825-1db2-41f8-8924-8=
5dfd0bb7283,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0da1p1:/EFI/Microsoft/Boot/boot=
mgfw.efi (null)
=C2=A0Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000=
L2) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-0=
0)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
--=
-
and I can choose "FreeBSD-14"(<ESP>/efi/freebsd=
/loader.efi), "FreeBSD-14_old"(<ESP>/efi/freebsd/loader-old=
.efi) and "EFI Hard Drive"(legacy <ESP>/efi/bootx64.efi) fr=
om BIOS.

NOTE: efibootmgr(8) example is:
---
efibootmgr -a -c -l /boot/efi/EFI/freebsd/loader.efi -L Free=
BSD-11
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^^^
---
But=
 I choosed "efi" instead of "EFI"...

=

Thanks all for helping me understand it!

Cheers,


Warner Losh <imp@bsdimp.com> escreveu no dia ter=C3=A7a, 16/08/2022 =C3=
=A0(s) 18:19:


On Tue, Aug 16, 2022 at 6:01 AM Nuno Te=
ixeira <eduardo=
@freebsd.org> wrote:
Hi Toomas,


For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page 499) =
is suggesting to use structure like:



<ESP>/efi/<OS>/=E2=80=A6



And to use this suggestion, it means the UEFI Boot Manager needs to be conf=
igured (see efibootmgr(8)).



Therefore, once you have set up OS specific setup, there is no use for defa=
ult (<ESP>/efi/boot/=E2=80=A6) and you need to update one or another,=
 but not both.

FreeBSD have <E=
SP>/efi/freebsd/... but it's not configured in efibootmgr:

The current default installer will do th=
is, but older upgraded systems don't do this by default. Likely you are=
 looking at an older
system and/or one of the 'bad actors'=
; that reset this stuff between boots.
=C2=A0
efibootmgr -v:
---
BootOrder =C2=A0: 0004, 0000, 2002, 2003, 2001
<=
div>Boot0004* Windows Boot Manager HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0b=
b7283,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0da0p1:/EFI/Microsoft/Boot/bootmgfw=
.efi (null)
+Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2) PciRo=
ot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/HD(1,G=
PT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
=C2=A0Boot2=
002* EFI DVD/CDROM
=C2=A0Boot2003* EFI Network
=C2=A0Boot2001* EFI US=
B Device
---
so boot is definitely using <ESP>/ef=
i/boot/bootx64.efi @Boot0000

In your case, that's true. The "=
EFI Hard Drive" is a default entry the UEFI BIOS created for you.
=C2=A0
I think I can create a new boot:
---
efibootmgr -a -c -l /boot/efi/efi/freebsd/loader.efi -L FreeBSD-14<=
/div>
(and make it active)
efibootmgr -a -b NNNN
--=
-
and create other for loader.efi.old in case of problems.
<=
/div>

Yes.
=C2=A0
In this case =
I will need only update <ESP>/efi/freebsd/loader.efi.
<=
br>
Q: for what has been said in mailing, boot is compiled in /us=
r/src/stand, isn't a good idea that when it install new boot it backup =
old boot like /boot/kernel -> /boot/kernel.old?
=


Yes. In fact that's what's done, but only for t=
he BIOS version. We should do the same for efi but don't seem to do so =
currently. But that's likely tied up behind issues of installing things=
 automatically into the ESP on 'installworld'.

=

Warner=C2=A0



-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--00000000000041e90905e673d76f--

From nobody Wed Aug 17 18:18:01 2022
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 4M7GTy3nK3z4YsPN
	for ; Wed, 17 Aug 2022 18:18:14 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7GTy3JYBz45Ln
	for ; Wed, 17 Aug 2022 18:18:14 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660760294;
	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=UX/UXYT80XGtnIr7SfnKED1diQ71NWQTBwrIx60dwCI=;
	b=ZRK8F1ifZr6xL3El6rLmmn4RnFP+RirxXOLHOoFgwcz8wAm9FRoUQcxUlit01HneisFetX
	UQQBXcfqCeurzt/FBcbhGwguB0hH59Pe/KvXtnAGfyoGnmn7+NbrEiBQixzrfAc51Ubdw1
	3hypj+hbjNwNbQ+C/+n6MNy5QrHzoHMMB8ZYn7uVFHDmwkvQX4kwHgnbKItMNIxUVNRoRV
	AddSDdWs0INJ6aeV84/AlfobLP/201Nam794L2YzfG4sKm1iwF7N7BbqwCSOgHpNNjHz1g
	iTDnZjghJOhf7+tdDXUvJAiSmjO4eutcpYCvfSpADxLZos/yuN3EeX938WlzMQ==
Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M7GTy2B6TzTHH
	for ; Wed, 17 Aug 2022 18:18:14 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-ua1-f50.google.com with SMTP id s5so4585998uar.1
        for ; Wed, 17 Aug 2022 11:18:14 -0700 (PDT)
X-Gm-Message-State: ACgBeo12hc2KqMHuo7CGuXVVM/9CqU39oyZQCdrN5disYbBK6iqstuT5
	45dT7aMzYD7YaPsLQDqqj3MYcaQkF62wuFbrBJg=
X-Google-Smtp-Source: AA6agR4kNMyeS2p7DNhPS2c/XPvx+2phZQ1/8wj/PRYchkqwghqgs1gNttbx0RLhft//yQXKgyf04UmOAVdhgoAwia4=
X-Received: by 2002:a9f:358c:0:b0:387:9de3:6c8a with SMTP id
 t12-20020a9f358c000000b003879de36c8amr11248819uad.94.1660760293772; Wed, 17
 Aug 2022 11:18:13 -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: 
 <62B26DE1-0E26-40BA-8647-E591E9ACEB7A@me.com> 
  
In-Reply-To: 
From: Nuno Teixeira 
Date: Wed, 17 Aug 2022 19:18:01 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: 24.3. Updating Bootcode
To: Warner Losh 
Cc: Toomas Soome , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000005e16a705e673e39a"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660760294;
	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=UX/UXYT80XGtnIr7SfnKED1diQ71NWQTBwrIx60dwCI=;
	b=JSveQZyY/LiHu01+0a196qjIMAwd30QZ6rV5vIDyQ+rBNx7M/MbcIG1LJc57NaY3XHckzp
	TNciJCYfXreBn7G7SqsiHjpryn57onUq/deaz98m0yavGqE2+3o8Sq6HHtlScmVQpVFB/y
	w739GDxRoGTp22aSJda7iiqdmPHqgdYLpOI8dKIBsxPJYbzZrmMIAxqLTU3R3jl/V4cdkX
	XTFDGyMv2xo1kwAqffEVDAe4JmR9Em4J/SA5TtQ1XeK8gOeqJMDX1HQxS+KYOgxqY+NhxD
	E+BBiwrzN9nd7B2kF76d95pnxOeYYGVuUGN617/pXBH1k1Ckj0gGRD+6sLx9HA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660760294; a=rsa-sha256; cv=none;
	b=eQ+xcuT48im96IKIZn8NTsbpaHw2/br4dNm2OL42nqGldsxhRnfIsu/V2RThPhQICrsIb+
	tgZpTkgTvFIvGZOEXSl5wy+x8w99ar46XKTeFFimYC1agjPpLR0v9PENTdBy4MciOWO1y2
	WWUh4aDnglcdRq/UnF3t10faUjHVNXlawgqfXq42//toz1Ub1qinoO0IExEnumCWZQRHIK
	KhTgT8r+fxLaeEP8v5KjoC1m3yKvig59rQfmGWCmjULkG4HGfMlYdw5DPXcZbY0MZ0VdRQ
	hPD+d/4/yzVsz9SJpfXbbQxA4DkAJQXfoWEv0poU50mxqo/JtP0O0ujtXKurSw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000005e16a705e673e39a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

*** and "EFI Hard Drive"(legacy /efi/boot/bootx64.efi) from BIOS.
                                                                   ^^^^

Nuno Teixeira  escreveu no dia quarta, 17/08/2022 =C3=
=A0(s)
19:14:

> Hi,
>
> And it's done:
> ---
>  Boot0007* FreeBSD-14
> HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\fre=
ebsd\loader.efi)
>                          nvd0p1:/efi/freebsd/loader.efi
> /boot/efi//efi/freebsd/loader.efi
> +Boot0006* FreeBSD-14_old
> HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\fre=
ebsd\loader-old.efi)
>                              nvd0p1:/efi/freebsd/loader-old.efi
> /boot/efi//efi/freebsd/loader-old.efi
>  Boot0004* Windows Boot Manager
> HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Mi=
crosoft\Boot\bootmgfw.efi)
>                                    da1p1:/EFI/Microsoft/Boot/bootmgfw.efi
> (null)
>  Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
> PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)=
/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
> ---
> and I can choose "FreeBSD-14"(/efi/freebsd/loader.efi),
> "FreeBSD-14_old"(/efi/freebsd/loader-old.efi) and "EFI Hard
> Drive"(legacy /efi/bootx64.efi) from BIOS.
>
> NOTE: efibootmgr(8) example is:
> ---
> efibootmgr -a -c -l /boot/efi/EFI/freebsd/loader.efi -L FreeBSD-11
>                                           ^^^
> ---
> But I choosed "efi" instead of "EFI"...
>
> Thanks all for helping me understand it!
>
> Cheers,
>
>
> Warner Losh  escreveu no dia ter=C3=A7a, 16/08/2022 =C3=
=A0(s) 18:19:
>
>>
>>
>> On Tue, Aug 16, 2022 at 6:01 AM Nuno Teixeira 
>> wrote:
>>
>>> Hi Toomas,
>>>
>>> For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page
>>>> 499) is suggesting to use structure like:
>>>>
>>>> /efi//=E2=80=A6
>>>>
>>>> And to use this suggestion, it means the UEFI Boot Manager needs to be
>>>> configured (see efibootmgr(8)).
>>>>
>>>> Therefore, once you have set up OS specific setup, there is no use for
>>>> default (/efi/boot/=E2=80=A6) and you need to update one or anoth=
er, but not
>>>> both.
>>>>
>>>
>>> FreeBSD have /efi/freebsd/... but it's not configured in efibootmg=
r:
>>>
>>
>> The current default installer will do this, but older upgraded systems
>> don't do this by default. Likely you are looking at an older
>> system and/or one of the 'bad actors' that reset this stuff between boot=
s.
>>
>>
>>> efibootmgr -v:
>>> ---
>>> BootOrder  : 0004, 0000, 2002, 2003, 2001
>>> Boot0004* Windows Boot Manager
>>> HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\=
Microsoft\Boot\bootmgfw.efi)
>>>
>>>  da0p1:/EFI/Microsoft/Boot/bootmgfw.efi (null)
>>> +Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
>>> PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-0=
0)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
>>>  Boot2002* EFI DVD/CDROM
>>>  Boot2003* EFI Network
>>>  Boot2001* EFI USB Device
>>> ---
>>> so boot is definitely using /efi/boot/bootx64.efi @Boot0000
>>>
>>
>> In your case, that's true. The "EFI Hard Drive" is a default entry the
>> UEFI BIOS created for you.
>>
>>
>>> I think I can create a new boot:
>>> ---
>>> efibootmgr -a -c -l /boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
>>> (and make it active)
>>> efibootmgr -a -b NNNN
>>> ---
>>> and create other for loader.efi.old in case of problems.
>>>
>>
>> Yes.
>>
>>
>>> In this case I will need only update /efi/freebsd/loader.efi.
>>>
>>> Q: for what has been said in mailing, boot is compiled in
>>> /usr/src/stand, isn't a good idea that when it install new boot it back=
up
>>> old boot like /boot/kernel -> /boot/kernel.old?
>>>
>>
>> Yes. In fact that's what's done, but only for the BIOS version. We shoul=
d
>> do the same for efi but don't seem to do so currently. But that's likely
>> tied up behind issues of installing things automatically into the ESP on
>> 'installworld'.
>>
>> Warner
>>
>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000005e16a705e673e39a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


*** and "EFI Hard Drive"(legacy <ESP>=
/efi/boot/bootx64.efi) from BIOS.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^^^^
=


Nuno Teixeira <eduardo@free=
bsd.org> escreveu no dia quarta, 17/08/2022 =C3=A0(s) 19:14:
H=
i,

And it's done:
---
=C2=
=A0Boot0007* FreeBSD-14 HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,=
0x82000)/File(\efi\freebsd\loader.efi)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nvd0p1:/efi/free=
bsd/loader.efi /boot/efi//efi/freebsd/loader.efi
+Boot0006* FreeBSD-14_o=
ld HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\fr=
eebsd\loader-old.efi)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nvd0p1:/efi/freebsd/=
loader-old.efi /boot/efi//efi/freebsd/loader-old.efi
=C2=A0Boot0004* Win=
dows Boot Manager HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x820=
00)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0da1p1:/EFI/Microsoft/Boot/bootmgfw.efi (null)
=
=C2=A0Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2) PciRoot(0x0)/Pc=
i(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/HD(1,GPT,73acd1b=
2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
---
and I c=
an choose "FreeBSD-14"(<ESP>/efi/freebsd/loader.efi), "=
;FreeBSD-14_old"(<ESP>/efi/freebsd/loader-old.efi) and "EFI=
 Hard Drive"(legacy <ESP>/efi/bootx64.efi) from BIOS.
=

NOTE: efibootmgr(8) example is:
---
efib=
ootmgr -a -c -l /boot/efi/EFI/freebsd/loader.efi -L FreeBSD-11
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 ^^^
---
But I choosed "e=
fi" instead of "EFI"...

Thanks =
all for helping me understand it!

Cheers,


Warner Losh <imp@bsdimp.com> escreveu no dia ter=C3=A7a, 16/08/2022 =C3=
=A0(s) 18:19:


On Tue, Aug 16, 2022 at 6:01 AM Nuno Te=
ixeira <eduardo=
@freebsd.org> wrote:
Hi Toomas,


For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page 499) =
is suggesting to use structure like:



<ESP>/efi/<OS>/=E2=80=A6



And to use this suggestion, it means the UEFI Boot Manager needs to be conf=
igured (see efibootmgr(8)).



Therefore, once you have set up OS specific setup, there is no use for defa=
ult (<ESP>/efi/boot/=E2=80=A6) and you need to update one or another,=
 but not both.

FreeBSD have <E=
SP>/efi/freebsd/... but it's not configured in efibootmgr:

The current default installer will do th=
is, but older upgraded systems don't do this by default. Likely you are=
 looking at an older
system and/or one of the 'bad actors'=
; that reset this stuff between boots.
=C2=A0
efibootmgr -v:
---
BootOrder =C2=A0: 0004, 0000, 2002, 2003, 2001
<=
div>Boot0004* Windows Boot Manager HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0b=
b7283,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0da0p1:/EFI/Microsoft/Boot/bootmgfw=
.efi (null)
+Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2) PciRo=
ot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/HD(1,G=
PT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
=C2=A0Boot2=
002* EFI DVD/CDROM
=C2=A0Boot2003* EFI Network
=C2=A0Boot2001* EFI US=
B Device
---
so boot is definitely using <ESP>/ef=
i/boot/bootx64.efi @Boot0000

In your case,=
 that's true. The "EFI Hard Drive" is a default entry the UEF=
I BIOS created for you.
=C2=A0
I think I can create =
a new boot:
---
efibootmgr -a -c -l /boot/efi/efi/freeb=
sd/loader.efi -L FreeBSD-14
(and make it active)
efiboo=
tmgr -a -b NNNN
---
and create other for loader.efi.old=
 in case of problems.

Yes.
=C2=A0
In this case I will need only update <ESP>/efi/freebsd=
/loader.efi.

Q: for what has been said in mail=
ing, boot is compiled in /usr/src/stand, isn't a good idea that when it=
 install new boot it backup old boot like /boot/kernel -> /boot/kernel.o=
ld?

Yes. In fact that's wha=
t's done, but only for the BIOS version. We should do the same for efi =
but don't seem to do so currently. But that's likely tied up behind=
 issues of installing things automatically into the ESP on 'installworl=
d'.

Warner=C2=A0




-- 
Nuno Teixeira
FreeBSD Co=
mmitter (ports)




-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--0000000000005e16a705e673e39a--

From nobody Thu Aug 18 04:20:30 2022
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 4M7Ws71B0lz4ZGHX
	for ; Thu, 18 Aug 2022 04:20:43 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7Ws62BT7z3xjf
	for ; Thu, 18 Aug 2022 04:20:42 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x92b.google.com with SMTP id s5so254850uar.1
        for ; Wed, 17 Aug 2022 21:20:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=P/Hirpa250iWn0IlHUie2PgLjJ9oMVxyNX2rCtgApfI=;
        b=ACsRVBh0CTPqtay1SwFX+pKmzCOjWdnmR3NB4/376Vw26pEYMTmyJOKZwGjm2FJtEb
         xDViuEh6RWAkbGUJb6xCxToFadbXfl0Pn/l8ljxyVmDCMpOo3PCfo2o7BbFZR4hrkbf9
         Gvb1apzsxS5K2Y8HnPPTNd74luKICyIHgDqJSDhcHkhRTPrtrsqMySfdIyYN/skEo2DD
         SfyhdZSuEmHSoIINDwJ7Gp3Dr4TNrhBC7ax3bdtLi40HXEau+SQl+oK2YdkuAyuabP79
         n3cUFFTszRDTQ5GG05ztbMe9Yqnpko04K7nFFGzGanLuKzzJVl7KGA1TIknTiqwZy1eh
         OHSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=P/Hirpa250iWn0IlHUie2PgLjJ9oMVxyNX2rCtgApfI=;
        b=THFP4yTWqW/EGjwEFLMXAyGtZd790ffew0knp/0z5Gj6kCIBaFkygH1gVKaKYIAGY8
         zY0ksHiBx2QqEfkjuWPH4DDPgqynXBNErGYCV+z6Jwl5D/jH7sRpSREe/+T0vKTK3GRo
         yGo7/b519w9h7TwiInfnW1Haa8A6mvcTzC210eWZT7diYpViKHYlMqwUqhPhHPRjOLTY
         3rZ2Ub04l1NiFNq3Tidq/6MFgrkDXeVjPq/RR8nNCjRblc9KDQo2d6aChVxsYKwNlK5R
         Q19RkJ1bCrBByLPescn8hB/N08l3XZMxWevmksy5vkSC6tgkUe2E9yYW32Tym07Oq4qW
         gHIw==
X-Gm-Message-State: ACgBeo0oxRLQkwxS4hQ6kHSYm71qQuN6DosDDpOTpCcwtEU1hI3imIaU
	n2nSOBj7NXRdiFL2N1Px7s9DiAGIp2/M1jN5Ifp+1w==
X-Google-Smtp-Source: AA6agR5NO8nFpnY8sgi+LdyLptsn4wpWsrLiDW+/eBtC3C8XgULPEh4wAh4WJoKFrno4N6FbcTqEMePHz37qqV+Z3yw=
X-Received: by 2002:ab0:538a:0:b0:394:fb49:22dd with SMTP id
 k10-20020ab0538a000000b00394fb4922ddmr459961uaa.20.1660796441520; Wed, 17 Aug
 2022 21:20:41 -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: <01000182ac5ac00f-938914eb-d1ee-44cb-bc22-8090b7f9a877-000000@email.amazonses.com>
In-Reply-To: <01000182ac5ac00f-938914eb-d1ee-44cb-bc22-8090b7f9a877-000000@email.amazonses.com>
From: Warner Losh 
Date: Wed, 17 Aug 2022 22:20:30 -0600
Message-ID: 
Subject: Re: Non EFI boot issue
To: Thomas Laus 
Cc: Current FreeBSD 
Content-Type: multipart/alternative; boundary="000000000000f0feff05e67c4d14"
X-Rspamd-Queue-Id: 4M7Ws62BT7z3xjf
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=ACsRVBh0;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92b) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92b:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000f0feff05e67c4d14
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 17, 2022 at 9:10 AM Thomas Laus  wrote:

> Another issue with the update today.  This update went well on all of my
> PC's that use EFI but spews a lot of disturbing messages on my only
> laptop without an EFI BIOS:
>
> Attempted recovery for standard superblock: failed
> Attempt to find boot zone recovery data: failed
>

Took me a while to find a way to reproducer for this... I have have

https://reviews.freebsd.org/D36253

which should fix the issue.

Warner

It jumps to what is normally Menu item 6 and then successfully boots.
>
> My update version information:
>
> FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed Aug 17 08:15:27
> EDT 2022
>
> All of my gpart utilities list, show and status have no errors.
>
> Tom
>
> --
> Public Keys:
> PGP KeyID = 0x5F22FDC1
> GnuPG KeyID = 0x620836CF
>
>

--000000000000f0feff05e67c4d14
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Aug 17, 2022 at 9:10 AM Thoma=
s Laus <lausts@acm.org> wrote:<=
br>
Another issue wi=
th the update today.=C2=A0 This update went well on all of my 

PC's that use EFI but spews a lot of disturbing messages on my only 
laptop without an EFI BIOS:



Attempted recovery for standard superblock: failed

Attempt to find boot zone recovery data: failed

Took me a while to find a way to reproducer for this... I have hav=
e


which sh=
ould fix the issue.

Warner


It jumps to what is normally Menu item 6 and then successfully boots.



My update version information:



FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed Aug 17 08:15:27 

EDT 2022



All of my gpart utilities list, show and status have no errors.



Tom



-- 

Public Keys:

PGP KeyID =3D 0x5F22FDC1

GnuPG KeyID =3D 0x620836CF






--000000000000f0feff05e67c4d14--

From nobody Thu Aug 18 06:18:57 2022
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 4M7ZTl2TFfz4ZWDv
	for ; Thu, 18 Aug 2022 06:19:07 +0000 (UTC)
	(envelope-from sjg@juniper.net)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7ZTj14PKz46hn;
	Thu, 18 Aug 2022 06:19:04 +0000 (UTC)
	(envelope-from sjg@juniper.net)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1])
	by mx0a-00273201.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27I1FKY1010443;
	Wed, 17 Aug 2022 23:19:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject :
 in-reply-to : references : from : mime-version : content-type : content-id
 : content-transfer-encoding : date : message-id; s=PPS1017;
 bh=6LjEMEmfEIHypI2qV0n9e6cfYg/y/lb2jTmJUn3z/IM=;
 b=fKbRMqq0aHXI1VZohW3i+l7DxKu7Iuy+O7pn4Jm9TOgGYFgemdXHtk/zjMng93mJG/Ri
 ovkGRAY6kUoVzbcCsNxWQzH8+Jp4hnzmUlTNwEvYjygYF3BXcFLFbaTYMkKzYCAIQ6M4
 ZinQO3onzhPxDDykK70vepEesIfoVU3+dUveq82aIFycDemjYqpkKkEorwMDMuG3eNHf
 rYbpQ1WEwLDYVv979R4jIbbkCCwZhIMNRsr4tUizMsMCPkOiXmwU2pR26aBQw2a3Orwc
 czVjtpbkA7DDF38saYb8Oz0XGwiDHcv2Ze/Q+BtvWDTrkoYeiRF7RcQ3GVNPXqhoU/cw yA== 
Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2106.outbound.protection.outlook.com [104.47.55.106])
	by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3j0yk4sqae-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
	Wed, 17 Aug 2022 23:19:02 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=iSA7XGwOE2hoPxtAKf1lR9JDTOQv1qeSSROJrLbvGccietkwaDeQvZ6BFBop5sTBS6kit4M4h26a3B1hDXPxyWTbNMKmcrwSjuYzvlQOIll1C/vr01BwS9MzoNrEGLYzL+y3DghsaZd2yc3KOkFfOKQRZ1TX6CspbNQaD/xZSJ3FTfcO7gXbn1KgBmEnVchGy0MpGZIIzkgetno9hjo1BpB/eGPWP5w3BFmC49YIE6ow6Vo4ibnwWrEifziy0hLlw886hqiXN60XLjW99tcTcX2ABhr/hEyJYNJMT/bsB/IIEhPPOqRFSsbszzOZOFdqNxI2zQZhIXykvB3hYSLcDQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6LjEMEmfEIHypI2qV0n9e6cfYg/y/lb2jTmJUn3z/IM=;
 b=SCB7YqXpda4XwSPKbAD0iGz4IQuYZMKpVfHOvHIqo8rasPs+PWIixt/AyLGUQkuGMLSdUvnlfSTR1Ix9/W5Zv+CIlV04DK1tvXpS1Ui/ds8BTSENvg0st+xQR55gp2QWzy5GLCDoe7TLTlYXxmL1NN4gWfh0ZeNnb7++pq+4IpRJyAxpybgVl8ZBvCgdOyiXIwiG07ihZkW9Wn9zwHczy9lzsaKekstws/7xDgwagiCGHSltoZzAxv4Ce4NXMFJ3C26O+fdgRFskitpWdC/aN06Z1HLEBOoTi43tAfV4Jm+M8iuA2G0/4fgx74dB/7PnVHm/MiVi52wKxGg6sDk0IQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip
 is 66.129.239.15) smtp.rcpttodomain=nomadlogic.org smtp.mailfrom=juniper.net;
 dmarc=fail (p=reject sp=reject pct=100) action=oreject
 header.from=juniper.net; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6LjEMEmfEIHypI2qV0n9e6cfYg/y/lb2jTmJUn3z/IM=;
 b=SulDWVMt7tDP7SrGwp5wHGZdmSaiBHRvNnKZdokurFFZDT2Hv0tNFMhhTjusWbSC8tdZowve7Tq6aLFAO5QLi7FzxA9kDKjd8461UU+32OddcETEwtvfTmSSXCeYJW4pRqUmCFU/MaG9FFbjjQerZ76K+8dZl4Y+I4feWO5J73Q=
Received: from DM6PR08CA0025.namprd08.prod.outlook.com (2603:10b6:5:80::38) by
 SA0PR05MB7259.namprd05.prod.outlook.com (2603:10b6:806:bf::7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5546.14; Thu, 18 Aug 2022 06:18:59 +0000
Received: from DM6NAM12FT061.eop-nam12.prod.protection.outlook.com
 (2603:10b6:5:80:cafe::3d) by DM6PR08CA0025.outlook.office365.com
 (2603:10b6:5:80::38) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5438.23 via Frontend
 Transport; Thu, 18 Aug 2022 06:18:59 +0000
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is
 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed)
 header.d=none;dmarc=fail action=oreject header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
 juniper.net discourages use of 66.129.239.15 as permitted sender)
Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by
 DM6NAM12FT061.mail.protection.outlook.com (10.13.179.123) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5566.4 via Frontend Transport; Thu, 18 Aug 2022 06:18:58 +0000
Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by
 p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.5;
 Thu, 18 Aug 2022 01:18:58 -0500
Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by
 p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.5;
 Thu, 18 Aug 2022 01:18:58 -0500
Received: from p-mailhub01.juniper.net (10.104.20.6) by
 p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.5
 via Frontend Transport; Thu, 18 Aug 2022 01:18:57 -0500
Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201])
	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 27I6IvNR027598;
	Wed, 17 Aug 2022 23:18:57 -0700
	(envelope-from sjg@juniper.net)
Received: by kaos.jnpr.net (Postfix, from userid 1377)
	id 6E475A0002; Wed, 17 Aug 2022 23:18:57 -0700 (PDT)
Received: from kaos.jnpr.net (localhost [127.0.0.1])
	by kaos.jnpr.net (Postfix) with ESMTP id 6B7F09FF9C;
	Wed, 17 Aug 2022 23:18:57 -0700 (PDT)
To: Warner Losh 
CC: Pete Wright , Stefan Esser ,
        "FreeBSD
 Current" ,
        Yasuhiro Kimura ,
        Oleg Lelchuk , 
Subject: Re: Updating EFI boot loader results in boot hangup
In-Reply-To: 
References: <20220814.095721.849461222067829352.yasu@FreeBSD.org>   <20220814.110850.1703361053728529792.yasu@FreeBSD.org>  <45007308-136a-8938-33d0-bb2509ee6ae7@FreeBSD.org> <20220814192609.wyfcogl3dwzteuva@colony.nomadlogic.org> 
Comments: In-reply-to: Warner Losh 
   message dated "Sun, 14 Aug 2022 13:57:05 -0600."
From: "Simon J. Gerraty" 
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.2
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15140.1660803537.1@kaos.jnpr.net>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 17 Aug 2022 23:18:57 -0700
Message-ID: <16144.1660803537@kaos.jnpr.net>
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d5435f64-1fea-4ae4-97a8-08da80e1896a
X-MS-TrafficTypeDiagnostic: SA0PR05MB7259:EE_
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 
	qeHFo4GdNrPtObxg6QOlO8MvteqxN5GWzgqf1gHyh3kEVabOdVyDqgCKPbIBbQWKHl7TgI5jDioGiF0dZc9e0FaR1B+/BnxlvsL/dGLrl3FS8i4juL0FUsoisjF+TEbT2fVRiqgoZHTOVnX72Heqw+HsE8HVmC+v2U/KNjE9twORlPMVk9+lBovWPOS7nlphb1HqfiZZCvBgTOwlCrCe28q/HHR3cT3nJtm2adTt1El5/I8tdHFuY/BCMNZptY3kv28li7fDpa1pfLKJ6rbhs52/1dRK6/GlohxWiV6JNwc/BAgVIMBD8aBlZOqW8aFa5vcRb4IASb1F+cIsV1tsgxBRBrl6K2inZB9ErwqmTXVy+ODbDiCW38INc+vV6wqEPjugukiui9dlX4bQ+ychNGNdUz8BnrkbgIMPQJ4DxSdfhirp1rgX6sM+5IpYQ/mmEY7MHX7aHsAb1zhOJOQURRY52YW7PGsKzMEUPH20mDINFyfJwb78GNpfaWKVj9XYqVZKj1InwR74YTBZCf6MQixRkvDKE1h1rtmlERvf0gQKPYCwslvqyMkMD36tBVyrcg1y+n8xsSGkjX1pTe1loDtetiNRgeMiIsx5VkVqkNFNDqMMXMBU/z57GlyOCsNDryZEildJ1s/GntaCmn79xOHnDnlVBWSxCMPjSV/zutONn3MTvJpWci1TnVvMUECZvVhIL+N+8wB32Ny313GrqCWkLl+82iFrRSSe0Xrf81YsEYDai3sMWFKlO+JAy4RmCAHXNhyg2Q5BQjE5s42kcX5sl0EL75HeYpPMrAhuVBLwTGaky541OCwz6da8oPbKc1R79k7znOol4xkJMdCy2t7/1IG89q4DkoUy63n9dE0=
X-Forefront-Antispam-Report: 
	CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230016)(4636009)(39860400002)(396003)(346002)(136003)(376002)(36840700001)(46966006)(40470700004)(55016003)(82310400005)(86362001)(2906002)(40480700001)(8936002)(82740400003)(356005)(81166007)(4744005)(9686003)(83380400001)(47076005)(186003)(26005)(7126003)(7696005)(6266002)(107886003)(36860700001)(336012)(41300700001)(478600001)(4326008)(70586007)(6916009)(70206006)(316002)(8676002)(5660300002)(40460700003)(54906003)(36900700001);DIR:OUT;SFP:1102;
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2022 06:18:58.6870
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d5435f64-1fea-4ae4-97a8-08da80e1896a
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net]
X-MS-Exchange-CrossTenant-AuthSource: 
	DM6NAM12FT061.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR05MB7259
X-Proofpoint-GUID: YEFFH-IfMvhr0viUm4bYcRt9xlETil_C
X-Proofpoint-ORIG-GUID: YEFFH-IfMvhr0viUm4bYcRt9xlETil_C
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1
 definitions=2022-08-18_02,2022-08-16_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0
 priorityscore=1501 bulkscore=0 malwarescore=0 mlxlogscore=632
 suspectscore=0 adultscore=0 clxscore=1011 mlxscore=0 spamscore=0
 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-2207270000 definitions=main-2208180018
X-Rspamd-Queue-Id: 4M7ZTj14PKz46hn
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=juniper.net header.s=PPS1017 header.b=fKbRMqq0;
	dkim=pass header.d=juniper.net header.s=selector1 header.b=SulDWVMt;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=reject) header.from=juniper.net;
	spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 208.84.65.16 as permitted sender) smtp.mailfrom=sjg@juniper.net
X-Spamd-Result: default: False [-5.10 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject];
	R_SPF_ALLOW(-0.20)[+ip4:208.84.65.16];
	R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[208.84.65.16:from];
	TO_DN_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEFALL_USER(0.00)[sjg];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:26211, ipnet:208.84.65.0/24, country:US];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWELVE(0.00)[12];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_SEVEN(0.00)[7];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[104.47.55.106:received];
	FREEMAIL_CC(0.00)[nomadlogic.org,freebsd.org,gmail.com,juniper.net];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[juniper.net:+]
X-ThisMailContainsUnwantedMimeParts: N

Warner Losh  wrote:
> I think I broke it with my latest updates. I don't have a good ZFS testi=
ng setup
> so I'm spending a little time enhancing the bootable image generator to =
have
> one that I can easily test boot with qemu.

FWIW bhyve is *excellent* for mucking about with EFI and loader in general=
.

I did all the UEFI support for Junos using bhyve (initially so I could
test LOADER_VERIEXEC), and I regurlarly use it to test various install
processes - pxe boot and net install, usb install, etc.

I build loader.efi from a branch off main, everyting else is from
stable/12 at present.

The combination of makefs, mkimg and bhyve - make hacking the low level
boot bits much safer.

Byhve is quick too - my Junos VM's take about 40-50s from start to login
prompt.

--sjg

From nobody Thu Aug 18 11:04:46 2022
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 4M7hqZ42nWz4ZC6F
	for ; Thu, 18 Aug 2022 11:04:58 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7hqZ3b4zz3gvy
	for ; Thu, 18 Aug 2022 11:04:58 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660820698;
	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=QvQ9nAx0LeWoXuW1VoLdVvUZ5l9f5TkDVz2vAPleCE0=;
	b=DaO2U/ksdRdTjYpA5HYiu2cbmmlfOYNs+6HXTWZUlicSIThxfQxNDMKUR7vUfN4Bpg4fVm
	x6e81DDbqXNuJtFTIZhC/lDbwTSL1TTHrvrBosleogJuD/51dVKRTTVMeLf3T4tvTGvWkp
	uha/gcEp1oQfJqBeltCLLPSzOXjdU2SYUW0H0VFqHe1PO//Yy8iEK7+oRqdLLhd1Qb3qI+
	0stZ/p4s77AeL60jKsXqnPinOgCMXm+JMOdgWDCC6IOqzr7C36goLc6gkhS4rvDT48Obca
	SrPmpKJfMnGjCh+n/wcjHkCQEV6cyPW2RzXt5o2bHDjgMOlR2DYt+jsUAveJUg==
Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M7hqZ2RMHzm3B
	for ; Thu, 18 Aug 2022 11:04:58 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f180.google.com with SMTP id t64so578860vkb.12
        for ; Thu, 18 Aug 2022 04:04:58 -0700 (PDT)
X-Gm-Message-State: ACgBeo2ZNDLm5gQ5hRErYOlTvvHK0k32Vjuuf7er/JZrAUgETk+BEE1J
	r5tBDHAU60be/1+2hqABVUw4n9u77oArBkZeT80=
X-Google-Smtp-Source: AA6agR6Bsng6mScbeXJ4nl9iQNsfBJV3uA47gqt87J+zTBaAkY781hW4krILBSfVvEZG7uenE31Cd5IKjRNmx+7eQn8=
X-Received: by 2002:a1f:acd2:0:b0:37b:531:9988 with SMTP id
 v201-20020a1facd2000000b0037b05319988mr859412vke.19.1660820697842; Thu, 18
 Aug 2022 04:04:57 -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: 
 <62B26DE1-0E26-40BA-8647-E591E9ACEB7A@me.com> 
 
  
In-Reply-To: 
From: Nuno Teixeira 
Date: Thu, 18 Aug 2022 12:04:46 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: 24.3. Updating Bootcode
To: Warner Losh 
Cc: Toomas Soome , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000bb0aa305e681f311"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660820698;
	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=QvQ9nAx0LeWoXuW1VoLdVvUZ5l9f5TkDVz2vAPleCE0=;
	b=Mh9/Nz0lZxE7LvMbeqMqDztoz4CC5VRriO3LaNQ15FT5QunH/P0mmpYcdYRkCX57YByRsN
	Y++Uq+3SE7KBK4EU+cPwlAjOACc0TRovcSRQru5s3QWyJ5Dtr6yevq3bWrEDzW4i9FAxQ1
	QwTFMLjgUGjeSOXUBUr5shPYxEnT7IQUOKxNTIxAxF2iE3TgyVNTiymkgsRSGvRKG/CMkz
	sqlxicRYd2fypXPnV8fB9s1o7Dy4+v09cibzWWowMr6yJa8mjLtOEpBovuf7IGafh7buBH
	1zporJLtNXMEWImeXuPXaWm5CCYSGKW28f+bWGto6QmvmBtMcrqliluNw1NIBg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660820698; a=rsa-sha256; cv=none;
	b=oGwmayLMxITlCIm+JStCbrmn3Ew7AlPUAQOumgCGV9kqPNNOvyvyI9azBxb68gf/FDHpem
	bgKfLZPuTEl19yYfUT8PEKjxNB5/IvJuAndX1vTaBBJ7aB7KMHSh+L9dRUPgn5psxMBDWs
	RbDGkzl+mhFDK7itegi59rBi5DGzHzREXjoRwgXWKnHGtY72s94wVhKNKzemyEpectWanj
	JtCzjY8TrD55il9aehqOsxlWIpqEhLiYyQ3qSVsEIt00vwt6hasS5ZPUXWZoc7fOC+ny2u
	aiiTNZ1Z7RReL7Oa6UightdhXu3VgiNzfh3KOl11EL3zLt5tDW47928MYFkk8w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000bb0aa305e681f311
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Forgot to send a screenshot
 for
loader.efi @ main-n257458-ef8b872301c5
( +Boot0007* FreeBSD-14
HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\freeb=
sd\loader.efi)
                         nvd0p1:/efi/freebsd/loader.efi
/boot/efi//efi/freebsd/loader.efi )

Someone talked about this warnings earlier:
---
Attempted extraction of recovery data from stadard superblock: failed
Attempt to find boot zone recovery data: failed
(...)
---
But it boots ok.

Cheers,

Nuno Teixeira  escreveu no dia quarta, 17/08/2022 =C3=
=A0(s)
19:18:

> *** and "EFI Hard Drive"(legacy /efi/boot/bootx64.efi) from BIOS.
>                                                                    ^^^^
>
> Nuno Teixeira  escreveu no dia quarta, 17/08/2022
> =C3=A0(s) 19:14:
>
>> Hi,
>>
>> And it's done:
>> ---
>>  Boot0007* FreeBSD-14
>> HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\fr=
eebsd\loader.efi)
>>                          nvd0p1:/efi/freebsd/loader.efi
>> /boot/efi//efi/freebsd/loader.efi
>> +Boot0006* FreeBSD-14_old
>> HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\fr=
eebsd\loader-old.efi)
>>                              nvd0p1:/efi/freebsd/loader-old.efi
>> /boot/efi//efi/freebsd/loader-old.efi
>>  Boot0004* Windows Boot Manager
>> HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\M=
icrosoft\Boot\bootmgfw.efi)
>>                                    da1p1:/EFI/Microsoft/Boot/bootmgfw.ef=
i
>> (null)
>>  Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
>> PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00=
)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
>> ---
>> and I can choose "FreeBSD-14"(/efi/freebsd/loader.efi),
>> "FreeBSD-14_old"(/efi/freebsd/loader-old.efi) and "EFI Hard
>> Drive"(legacy /efi/bootx64.efi) from BIOS.
>>
>> NOTE: efibootmgr(8) example is:
>> ---
>> efibootmgr -a -c -l /boot/efi/EFI/freebsd/loader.efi -L FreeBSD-11
>>                                           ^^^
>> ---
>> But I choosed "efi" instead of "EFI"...
>>
>> Thanks all for helping me understand it!
>>
>> Cheers,
>>
>>
>> Warner Losh  escreveu no dia ter=C3=A7a, 16/08/2022 =C3=
=A0(s)
>> 18:19:
>>
>>>
>>>
>>> On Tue, Aug 16, 2022 at 6:01 AM Nuno Teixeira 
>>> wrote:
>>>
>>>> Hi Toomas,
>>>>
>>>> For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page
>>>>> 499) is suggesting to use structure like:
>>>>>
>>>>> /efi//=E2=80=A6
>>>>>
>>>>> And to use this suggestion, it means the UEFI Boot Manager needs to b=
e
>>>>> configured (see efibootmgr(8)).
>>>>>
>>>>> Therefore, once you have set up OS specific setup, there is no use fo=
r
>>>>> default (/efi/boot/=E2=80=A6) and you need to update one or anot=
her, but not
>>>>> both.
>>>>>
>>>>
>>>> FreeBSD have /efi/freebsd/... but it's not configured in
>>>> efibootmgr:
>>>>
>>>
>>> The current default installer will do this, but older upgraded systems
>>> don't do this by default. Likely you are looking at an older
>>> system and/or one of the 'bad actors' that reset this stuff between
>>> boots.
>>>
>>>
>>>> efibootmgr -v:
>>>> ---
>>>> BootOrder  : 0004, 0000, 2002, 2003, 2001
>>>> Boot0004* Windows Boot Manager
>>>> HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI=
\Microsoft\Boot\bootmgfw.efi)
>>>>
>>>>  da0p1:/EFI/Microsoft/Boot/bootmgfw.efi (null)
>>>> +Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
>>>> PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-=
00)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
>>>>  Boot2002* EFI DVD/CDROM
>>>>  Boot2003* EFI Network
>>>>  Boot2001* EFI USB Device
>>>> ---
>>>> so boot is definitely using /efi/boot/bootx64.efi @Boot0000
>>>>
>>>
>>> In your case, that's true. The "EFI Hard Drive" is a default entry the
>>> UEFI BIOS created for you.
>>>
>>>
>>>> I think I can create a new boot:
>>>> ---
>>>> efibootmgr -a -c -l /boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
>>>> (and make it active)
>>>> efibootmgr -a -b NNNN
>>>> ---
>>>> and create other for loader.efi.old in case of problems.
>>>>
>>>
>>> Yes.
>>>
>>>
>>>> In this case I will need only update /efi/freebsd/loader.efi.
>>>>
>>>> Q: for what has been said in mailing, boot is compiled in
>>>> /usr/src/stand, isn't a good idea that when it install new boot it bac=
kup
>>>> old boot like /boot/kernel -> /boot/kernel.old?
>>>>
>>>
>>> Yes. In fact that's what's done, but only for the BIOS version. We
>>> should do the same for efi but don't seem to do so currently. But that'=
s
>>> likely tied up behind issues of installing things automatically into th=
e
>>> ESP on 'installworld'.
>>>
>>> Warner
>>>
>>
>>
>> --
>> Nuno Teixeira
>> FreeBSD Committer (ports)
>>
>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000bb0aa305e681f311
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Forgot to send a screenshot for loader.efi @ main-n=
257458-ef8b872301c5
( +Boot0007* FreeBSD-14 HD(1,GPT,73acd1b2-de4=
1-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\freebsd\loader.efi)
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0nvd0p1:/efi/freebsd/loader.efi /boot/efi//efi/freebsd/loader.e=
fi )

Someone talked about this warnings earlier:
---
Attempted extraction of recovery data from stadard s=
uperblock: failed
Attempt to find boot zone recovery data: failed=

(...)
---
But it boots ok.

Cheers,

Nuno Teixeira <=
eduardo@freebsd.org> escreveu no dia quarta, 17/08/2022 =C3=A0(s) 19=
:18:
*** and "EFI Hard Drive"(legacy <ESP>/efi/boot/b=
ootx64.efi) from BIOS.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^^^^
=

Nuno T=
eixeira <eduard=
o@freebsd.org> escreveu no dia quarta, 17/08/2022 =C3=A0(s) 19:14:
=

Hi,

And it's done:
---
=C2=A0Boot0007* FreeBSD-14 HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,=
0x28,0x82000)/File(\efi\freebsd\loader.efi)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nvd0p1:/efi/f=
reebsd/loader.efi /boot/efi//efi/freebsd/loader.efi
+Boot0006* FreeBSD-1=
4_old HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi=
\freebsd\loader-old.efi)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nvd0p1:/efi/free=
bsd/loader-old.efi /boot/efi//efi/freebsd/loader-old.efi
=C2=A0Boot0004*=
 Windows Boot Manager HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0=
x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0da1p1:/EFI/Microsoft/Boot/bootmgfw.efi (null)=C2=A0Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2) PciRoot(0x0)/P=
ci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/HD(1,GPT,73acd1=
b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
---
and I =
can choose "FreeBSD-14"(<ESP>/efi/freebsd/loader.efi), &quo=
t;FreeBSD-14_old"(<ESP>/efi/freebsd/loader-old.efi) and "EF=
I Hard Drive"(legacy <ESP>/efi/bootx64.efi) from BIOS.

NOTE: efibootmgr(8) example is:
---
efi=
bootmgr -a -c -l /boot/efi/EFI/freebsd/loader.efi -L FreeBSD-11
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 ^^^
---
But I choosed "e=
fi" instead of "EFI"...

Thanks =
all for helping me understand it!

Cheers,


Warner Losh <imp@bsdimp.com> escreveu no dia ter=C3=A7a, 16/08/2022 =C3=
=A0(s) 18:19:


On Tue, Aug 16, 2022 at 6:01 AM Nuno Te=
ixeira <eduardo=
@freebsd.org> wrote:
Hi Toomas,


For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page 499) =
is suggesting to use structure like:



<ESP>/efi/<OS>/=E2=80=A6



And to use this suggestion, it means the UEFI Boot Manager needs to be conf=
igured (see efibootmgr(8)).



Therefore, once you have set up OS specific setup, there is no use for defa=
ult (<ESP>/efi/boot/=E2=80=A6) and you need to update one or another,=
 but not both.

FreeBSD have <E=
SP>/efi/freebsd/... but it's not configured in efibootmgr:

The current default installer will do th=
is, but older upgraded systems don't do this by default. Likely you are=
 looking at an older
system and/or one of the 'bad actors'=
; that reset this stuff between boots.
=C2=A0
efibootmgr -v:
---
BootOrder =C2=A0: 0004, 0000, 2002, 2003, 2001
<=
div>Boot0004* Windows Boot Manager HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0b=
b7283,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0da0p1:/EFI/Microsoft/Boot/bootmgfw=
.efi (null)
+Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2) PciRo=
ot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/HD(1,G=
PT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
=C2=A0Boot2=
002* EFI DVD/CDROM
=C2=A0Boot2003* EFI Network
=C2=A0Boot2001* EFI US=
B Device
---
so boot is definitely using <ESP>/ef=
i/boot/bootx64.efi @Boot0000
<=
br>
In your case, that's true. The "EFI Hard Drive"=
 is a default entry the UEFI BIOS created for you.
=C2=A0
I think I can create a new boot:
---
efibootmgr -=
a -c -l /boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
(and make =
it active)
efibootmgr -a -b NNNN
---
and crea=
te other for loader.efi.old in case of problems.

Yes.
=C2=A0
In this case I will need only upd=
ate <ESP>/efi/freebsd/loader.efi.

Q: for=
 what has been said in mailing, boot is compiled in /usr/src/stand, isn'=
;t a good idea that when it install new boot it backup old boot like /boot/=
kernel -> /boot/kernel.old?

=
Yes. In fact that's what's done, but only for the BIOS version. We =
should do the same for efi but don't seem to do so currently. But that&=
#39;s likely tied up behind issues of installing things automatically into =
the ESP on 'installworld'.

Warner=C2=A0




-- 
Nuno Teixeira
FreeBSD Co=
mmitter (ports)



-- 
Nuno Teixeira
FreeBSD Co=
mmitter (ports)



-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--000000000000bb0aa305e681f311--

From nobody Thu Aug 18 13:02:23 2022
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 4M7lRK2yYSz4ZRm3
	for ; Thu, 18 Aug 2022 13:02:37 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7lRJ5mwHz3sGl
	for ; Thu, 18 Aug 2022 13:02:36 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x930.google.com with SMTP id e3so626898uax.4
        for ; Thu, 18 Aug 2022 06:02:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=5jI83qT5OTUEh9VidoSGwYssytMuJbgnw34bXkoGECs=;
        b=fCN/HPOssRSZ/BoemkxbzgoKCULCnJl/oxakhW3hTPCejLJl/sSsYsCx5VFgMLpHPc
         1RSLsUBL5IHh69d9btVbXKMWPlvz4u+OMNpjl9cfAy4Fx8LQ2Kk1tadJ4D0pG89Oan/n
         DbYdcW0rLmcNgwKpwxXrGk0XRPycJVcxiUclvc3pv4BOgQrZ5PcnWRxxaYW3VVik7+JN
         T+eeVcHWK1prK8f9SkS1lO8XVPO1nmfvadDBSPTCpsV806goShpt2K3zxm8PProV8KFF
         8emneXOQXw/sKpYfIxekJ2P7lvtf4SmgSHq5QR/AvVg/EoSJ0Gs25nW1JgTaw8m7HPUk
         P3Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=5jI83qT5OTUEh9VidoSGwYssytMuJbgnw34bXkoGECs=;
        b=BfsAScWpbETaSMz59VX5VLzxQOAzSq2l+lNd1E6haqBZaA2MDs1uq2sdtMui+Yo7O6
         mKFMOw+ZpehZnyLDZW7MmaqjGOuV5tvl0tXbjPv0kUzWe/xL6+gYMqyeDvwso3q9VyOl
         xYYqQsncGZ0UOKBd8W8xYK+Nzb1O3VDj1+a2vOqmQX1sWl0yVWCLRvVj+j7/c7KiddAz
         FJ9YYAw8meXbnTGXncsJcSD0MrRiZE1C594RQQRtvR+5iBy1gedPzcixvjY4ps0KMrAq
         2LMRBnPH5RxNjCUXb+PJNdG1ZBjjwxU7m8i7EWXAWV+pfjl271JjWQDkiqypZDTvsyOo
         1jWA==
X-Gm-Message-State: ACgBeo3V+g8/gnMNnWbNseSchOYwg6upJVlVpzxO+yE6w4Ao8HCzxHE7
	ZVR6T7ypVOI2R14oGnUeWk6uajQl637DEyQaPCPGcg==
X-Google-Smtp-Source: AA6agR5gfuc7wlPRqhUtRKxMPKjyYVS6GcFFcVuMk0sDekgCeDDWkbJ3RagPC7esu8b0cfXQJonb7xQLyo/Or2/hxhs=
X-Received: by 2002:a05:6130:112:b0:38c:4226:62f2 with SMTP id
 h18-20020a056130011200b0038c422662f2mr1058286uag.82.1660827755433; Thu, 18
 Aug 2022 06:02:35 -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: <20220814.095721.849461222067829352.yasu@FreeBSD.org>
 
 
 <20220814.110850.1703361053728529792.yasu@FreeBSD.org> 
 <45007308-136a-8938-33d0-bb2509ee6ae7@FreeBSD.org> <20220814192609.wyfcogl3dwzteuva@colony.nomadlogic.org>
  <16144.1660803537@kaos.jnpr.net>
In-Reply-To: <16144.1660803537@kaos.jnpr.net>
From: Warner Losh 
Date: Thu, 18 Aug 2022 07:02:23 -0600
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: "Simon J. Gerraty" 
Cc: Pete Wright , Stefan Esser , 
	FreeBSD Current , Yasuhiro Kimura , 
	Oleg Lelchuk 
Content-Type: multipart/alternative; boundary="00000000000065659305e683982b"
X-Rspamd-Queue-Id: 4M7lRJ5mwHz3sGl
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="fCN/HPOs";
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::930) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::930:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	DMARC_NA(0.00)[bsdimp.com];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_FIVE(0.00)[6];
	FREEMAIL_CC(0.00)[nomadlogic.org,freebsd.org,gmail.com]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000065659305e683982b
Content-Type: text/plain; charset="UTF-8"

On Thu, Aug 18, 2022, 12:19 AM Simon J. Gerraty  wrote:

> Warner Losh  wrote:
> > I think I broke it with my latest updates. I don't have a good ZFS
> testing setup
> > so I'm spending a little time enhancing the bootable image generator to
> have
> > one that I can easily test boot with qemu.
>
> FWIW bhyve is *excellent* for mucking about with EFI and loader in general.
>
> I did all the UEFI support for Junos using bhyve (initially so I could
> test LOADER_VERIEXEC), and I regurlarly use it to test various install
> processes - pxe boot and net install, usb install, etc.
>
> I build loader.efi from a branch off main, everyting else is from
> stable/12 at present.
>
> The combination of makefs, mkimg and bhyve - make hacking the low level
> boot bits much safer.
>
> Byhve is quick too - my Junos VM's take about 40-50s from start to login
> prompt.
>

Yup. Use all that stuff. My issue was tooling (creating the bookable ZFS
images) as well as not being able to create an image that recreates the
problem. I've fixed the tooling issue, but used qemu so I could capture
stout to see if the tests pass/fail easily in a script. Bhyve, as far as I
know, can't do that without delving into separate expect scripts. And it
can't run arm binaries on x86...

I also use bhyve when I want to attach a debugger or need to test longer
running things.

But in this case it took a while to find how to reproduce... but I found
one and just pushed a fix.

Warner

>

--00000000000065659305e683982b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Aug 18, 2022, 12:19 AM Simon J. Gerraty <sjg@juniper.net> wrote:
Warner Losh <imp@bsdimp.com> wrote:

> I think I broke it with my latest updates. I don't have a good ZFS=
 testing setup

> so I'm spending a little time enhancing the bootable image generat=
or to have

> one that I can easily test boot with qemu.



FWIW bhyve is *excellent* for mucking about with EFI and loader in general.=




I did all the UEFI support for Junos using bhyve (initially so I could

test LOADER_VERIEXEC), and I regurlarly use it to test various install

processes - pxe boot and net install, usb install, etc.



I build loader.efi from a branch off main, everyting else is from

stable/12 at present.



The combination of makefs, mkimg and bhyve - make hacking the low level

boot bits much safer.



Byhve is quick too - my Junos VM's take about 40-50s from start to logi=
n

prompt.

Yup. Use all that stuff. My issue was tooling (creating the bookable=
 ZFS images) as well as not being able to create an image that recreates th=
e problem. I've fixed the tooling issue, but used qemu so I could captu=
re stout to see if the tests pass/fail easily in a script. Bhyve, as far as=
 I know, can't do that without delving into separate expect scripts. An=
d it can't run arm binaries on x86...

=

I also use bhyve when I want to attach a debugger or need=
 to test longer running things.

But in this case it took a while to find how to reproduce... but =
I found one and just pushed a fix.

Warner=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">



--00000000000065659305e683982b--

From nobody Thu Aug 18 14:49:54 2022
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 4M7nqH16T9z4Zgjf
	for ; Thu, 18 Aug 2022 14:50:03 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7nqG3BXZz40P5;
	Thu, 18 Aug 2022 14:50:02 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To:
	From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=Y0O6oLaNl/uMSIVCvUV9PsMmtzeQF69MtgmHb5MmawM=; b=btekUu8zs8Mb775ufe/zxlhpys
	D/H6kDG+TXWcwobsw8tFmN08yGMFPlIIWq6CJSIv/jUGb0gtb8y6D+qqIJBX7ymCKq/C2rSlV4ghY
	4Zduk1e5akWo7YvenmsAExVlLdl0910PWy944IaGOM/606z1TwXEOr69wiXmxYkccffaza9EH9R1F
	xk7CXABR1q1k4IJUGaTmI/vCN+gm6lijkF8XpCmgzZnDR+9lsUBVKANjYMFtdAMLGSVPMAvWdN9sX
	33PHC08+2rD9ZqEb678arsK9Ac4RxP3bHIF47kU78d/NvP/wFnl0ud//JOMG0wsygbOmEn5xGklG0
	va+2HXUw==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:55337 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oOgqI-000G6m-8N;
	Thu, 18 Aug 2022 09:49:54 -0500
Received: from 76-250-255-117.lightspeed.austtx.sbcglobal.net
 ([76.250.255.117])
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Thu, 18 Aug 2022 09:49:54 -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
Date: Thu, 18 Aug 2022 09:49:54 -0500
From: Larry Rosenman 
To: Freebsd current , Mark Johnston
 
Subject: Hangs in bacula / NFS? on recent Current
Message-ID: <405b3873b709d42feb438b5b954ecdc2@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4M7nqG3BXZz40P5
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=btekUu8z;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I didn't get all my mail on my bacula backups today (they backup to NFS 
mounted TrueNAS).
Also a df hangs.

Here are procstat -kk's for all:
ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
⯠ps auxxxwww|grep bacula
bacula       2067    0.0  0.0  63188  13652  -  Is   11:30       0:17.49 
/usr/local/sbin/bacula-sd -u bacula -g bacula -v -c 
/usr/local/etc/bacula/bacula-sd.conf
root         2072    0.0  0.0  59280  31276  -  Is   11:30       0:00.31 
/usr/local/sbin/bacula-fd -u root -g wheel -v -c 
/usr/local/etc/bacula/bacula-fd.conf
bacula       2075    0.0  0.0  86992  19352  -  Is   11:30       0:56.95 
/usr/local/sbin/bacula-dir -u bacula -g bacula -v -c 
/usr/local/etc/bacula/bacula-dir.conf
postgres    50241    0.0  0.1 285764 160244  -  Is   23:05       0:00.38 
postgres: bacula bacula [local]  (postgres)
postgres    50244    0.0  0.1 298784  74448  -  Ds   23:05       0:00.67 
postgres: bacula bacula [local]  (postgres)
ler         66595    0.0  0.0  12888   2600  3  S+   09:46       0:00.00 
grep --color=auto bacula

ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
⯠sudo procstat -kk 2067
   PID    TID COMM                TDNAME              KSTACK
  2067 100742 bacula-sd           -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9 
_cv_wait_sig+0x137 kern_select+0x9fe sys_select+0x56 amd64_syscall+0x12e 
fast_syscall_common+0xf8
  2067 101036 bacula-sd           -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b 
__umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e 
fast_syscall_common+0xf8
  2067 101038 bacula-sd           -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b 
__umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e 
fast_syscall_common+0xf8
  2067 124485 bacula-sd           -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_cv_timedwait_sig_sbt+0x15c kern_poll_kfds+0x457 kern_poll+0x9f 
sys_poll+0x50 amd64_syscall+0x12e fast_syscall_common+0xf8

ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
⯠sudo procstat -kk 2072
   PID    TID COMM                TDNAME              KSTACK
  2072 100677 bacula-fd           -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9 
_cv_wait_sig+0x137 kern_select+0x9fe sys_select+0x56 amd64_syscall+0x12e 
fast_syscall_common+0xf8
  2072 101039 bacula-fd           -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b 
__umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e 
fast_syscall_common+0xf8
  2072 101040 bacula-fd           -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b 
__umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e 
fast_syscall_common+0xf8
  2072 124490 bacula-fd           -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_cv_timedwait_sig_sbt+0x15c kern_poll_kfds+0x457 kern_poll+0x9f 
sys_poll+0x50 amd64_syscall+0x12e fast_syscall_common+0xf8

ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
⯠sudo procstat -kk 2075
   PID    TID COMM                TDNAME              KSTACK
  2075 101007 bacula-dir          -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9 
_sleep+0x29b umtxq_sleep+0x242 do_wait+0x26b __umtx_op_wait+0x53 
sys__umtx_op+0x7e amd64_syscall+0x12e fast_syscall_common+0xf8
  2075 101041 bacula-dir          -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b 
__umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e 
fast_syscall_common+0xf8
  2075 101045 bacula-dir          -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9 
_cv_wait_sig+0x137 kern_select+0x9fe sys_select+0x56 amd64_syscall+0x12e 
fast_syscall_common+0xf8
  2075 101046 bacula-dir          -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b 
__umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e 
fast_syscall_common+0xf8
  2075 101047 bacula-dir          -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_sleep+0x27d kern_clock_nanosleep+0x1d1 sys_nanosleep+0x3b 
amd64_syscall+0x12e fast_syscall_common+0xf8
  2075 124479 bacula-dir          -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9 
_cv_wait_sig+0x137 kern_poll_kfds+0x48c kern_poll+0x9f sys_poll+0x50 
amd64_syscall+0x12e fast_syscall_common+0xf8
  2075 124480 bacula-dir          -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_sleep+0x27d kern_clock_nanosleep+0x1d1 sys_nanosleep+0x3b 
amd64_syscall+0x12e fast_syscall_common+0xf8
  2075 124481 bacula-dir          -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_sleep+0x27d kern_clock_nanosleep+0x1d1 sys_nanosleep+0x3b 
amd64_syscall+0x12e fast_syscall_common+0xf8
  2075 124489 bacula-dir          -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_cv_timedwait_sig_sbt+0x15c kern_poll_kfds+0x457 kern_poll+0x9f 
sys_poll+0x50 amd64_syscall+0x12e fast_syscall_common+0xf8
  2075 124506 bacula-dir          -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_timedwait_sig+0x12 
_sleep+0x27d kern_clock_nanosleep+0x1d1 sys_nanosleep+0x3b 
amd64_syscall+0x12e fast_syscall_common+0xf8

ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
⯠sudo procstat -kk 66390
   PID    TID COMM                TDNAME              KSTACK
66390 101514 df                  -                   mi_switch+0x157 
sleepq_switch+0x107 sleepq_timedwait+0x4b _sleep+0x28e 
clnt_reconnect_call+0x809 newnfs_request+0xa95 nfscl_request+0x5a 
nfsrpc_statfs+0x19d nfs_statfs+0x148 vfs_statfs_sigdefer+0x2e 
kern_getfsstat+0x1f1 sys_getfsstat+0x22 amd64_syscall+0x12e 
fast_syscall_common+0xf8

ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
â¯

this was built yesterday:
⯠uname -a
FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #142 
ler/freebsd-main-changes-n257453-175a127a72f: Wed Aug 17 09:23:32 CDT 
2022     
root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL amd64

ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
â¯

What else do we need?

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Thu Aug 18 14:57:00 2022
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 4M7nzL4Pjzz4ZhVh
	for ; Thu, 18 Aug 2022 14:57:02 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7nzK6hQXz41gw;
	Thu, 18 Aug 2022 14:57:01 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:To:From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=N/PXMXSV40QcdVqUxkwQkBAFUOIyWN1RIj+3eCqsw9E=; b=xTWvtSuVmsFIkUbi7d/N1usRHP
	NrgICkwUiObxk/odcemN3mx2/WNkmutTIN44XklBZCJFd/vnN9EJcgi1irqXT4jFxtAl2bvcF6WHv
	pQSqbGcJw4eIePINecVODipUY1z0jtbGSDz099BNLeZhxQGG+LwWGZt+RaNXWBO14576xeIsNOTFQ
	hMB2012Y7jhc+WA63dFk+PABW0vgX6fdaWsCs9zGYAfLXAYHfepyjlJyRFaXgkVKw8DbTY0ViBjHL
	2LAbLl4wopP3IZDtIXAkSpgm+rTCBONgJJh8P1OPMUEYc/+47cQy3hI6PBZyk6kYQaO9sdzvnUByp
	J+3uPqfQ==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:41063 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oOgxB-000GOT-01;
	Thu, 18 Aug 2022 09:57:01 -0500
Received: from 76-250-255-117.lightspeed.austtx.sbcglobal.net
 ([76.250.255.117])
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Thu, 18 Aug 2022 09:57:00 -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
Date: Thu, 18 Aug 2022 09:57:00 -0500
From: Larry Rosenman 
To: Freebsd current , Mark Johnston
 
Subject: Re: Hangs in bacula / NFS? on recent Current
In-Reply-To: <405b3873b709d42feb438b5b954ecdc2@lerctr.org>
References: <405b3873b709d42feb438b5b954ecdc2@lerctr.org>
Message-ID: <9e63f40233fc29c9fbc3fac0cb82acd5@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4M7nzK6hQXz41gw
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=xTWvtSuV;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.99 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.99)[-0.994];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	R_SPF_ALLOW(-0.20)[+mx:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 08/18/2022 9:49 am, Larry Rosenman wrote:
> I didn't get all my mail on my bacula backups today (they backup to
> NFS mounted TrueNAS).
> Also a df hangs.
> 
> Here are procstat -kk's for all:
> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
> ⯠ps auxxxwww|grep bacula
> bacula       2067    0.0  0.0  63188  13652  -  Is   11:30
> 0:17.49 /usr/local/sbin/bacula-sd -u bacula -g bacula -v -c
> /usr/local/etc/bacula/bacula-sd.conf
> root         2072    0.0  0.0  59280  31276  -  Is   11:30
> 0:00.31 /usr/local/sbin/bacula-fd -u root -g wheel -v -c
> /usr/local/etc/bacula/bacula-fd.conf
> bacula       2075    0.0  0.0  86992  19352  -  Is   11:30
> 0:56.95 /usr/local/sbin/bacula-dir -u bacula -g bacula -v -c
> /usr/local/etc/bacula/bacula-dir.conf
> postgres    50241    0.0  0.1 285764 160244  -  Is   23:05
> 0:00.38 postgres: bacula bacula [local]  (postgres)
> postgres    50244    0.0  0.1 298784  74448  -  Ds   23:05
> 0:00.67 postgres: bacula bacula [local]  (postgres)
> ler         66595    0.0  0.0  12888   2600  3  S+   09:46
> 0:00.00 grep --color=auto bacula
> 
> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
> ⯠sudo procstat -kk 2067
>   PID    TID COMM                TDNAME              KSTACK
>  2067 100742 bacula-sd           -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9
> _cv_wait_sig+0x137 kern_select+0x9fe sys_select+0x56
> amd64_syscall+0x12e fast_syscall_common+0xf8
>  2067 101036 bacula-sd           -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
> fast_syscall_common+0xf8
>  2067 101038 bacula-sd           -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
> fast_syscall_common+0xf8
>  2067 124485 bacula-sd           -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _cv_timedwait_sig_sbt+0x15c
> kern_poll_kfds+0x457 kern_poll+0x9f sys_poll+0x50 amd64_syscall+0x12e
> fast_syscall_common+0xf8
> 
> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
> ⯠sudo procstat -kk 2072
>   PID    TID COMM                TDNAME              KSTACK
>  2072 100677 bacula-fd           -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9
> _cv_wait_sig+0x137 kern_select+0x9fe sys_select+0x56
> amd64_syscall+0x12e fast_syscall_common+0xf8
>  2072 101039 bacula-fd           -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
> fast_syscall_common+0xf8
>  2072 101040 bacula-fd           -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
> fast_syscall_common+0xf8
>  2072 124490 bacula-fd           -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _cv_timedwait_sig_sbt+0x15c
> kern_poll_kfds+0x457 kern_poll+0x9f sys_poll+0x50 amd64_syscall+0x12e
> fast_syscall_common+0xf8
> 
> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
> ⯠sudo procstat -kk 2075
>   PID    TID COMM                TDNAME              KSTACK
>  2075 101007 bacula-dir          -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9
> _sleep+0x29b umtxq_sleep+0x242 do_wait+0x26b __umtx_op_wait+0x53
> sys__umtx_op+0x7e amd64_syscall+0x12e fast_syscall_common+0xf8
>  2075 101041 bacula-dir          -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
> fast_syscall_common+0xf8
>  2075 101045 bacula-dir          -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9
> _cv_wait_sig+0x137 kern_select+0x9fe sys_select+0x56
> amd64_syscall+0x12e fast_syscall_common+0xf8
>  2075 101046 bacula-dir          -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
> fast_syscall_common+0xf8
>  2075 101047 bacula-dir          -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _sleep+0x27d kern_clock_nanosleep+0x1d1
> sys_nanosleep+0x3b amd64_syscall+0x12e fast_syscall_common+0xf8
>  2075 124479 bacula-dir          -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9
> _cv_wait_sig+0x137 kern_poll_kfds+0x48c kern_poll+0x9f sys_poll+0x50
> amd64_syscall+0x12e fast_syscall_common+0xf8
>  2075 124480 bacula-dir          -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _sleep+0x27d kern_clock_nanosleep+0x1d1
> sys_nanosleep+0x3b amd64_syscall+0x12e fast_syscall_common+0xf8
>  2075 124481 bacula-dir          -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _sleep+0x27d kern_clock_nanosleep+0x1d1
> sys_nanosleep+0x3b amd64_syscall+0x12e fast_syscall_common+0xf8
>  2075 124489 bacula-dir          -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _cv_timedwait_sig_sbt+0x15c
> kern_poll_kfds+0x457 kern_poll+0x9f sys_poll+0x50 amd64_syscall+0x12e
> fast_syscall_common+0xf8
>  2075 124506 bacula-dir          -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_catch_signals+0x266
> sleepq_timedwait_sig+0x12 _sleep+0x27d kern_clock_nanosleep+0x1d1
> sys_nanosleep+0x3b amd64_syscall+0x12e fast_syscall_common+0xf8
> 
> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
> ⯠sudo procstat -kk 66390
>   PID    TID COMM                TDNAME              KSTACK
> 66390 101514 df                  -                   mi_switch+0x157
> sleepq_switch+0x107 sleepq_timedwait+0x4b _sleep+0x28e
> clnt_reconnect_call+0x809 newnfs_request+0xa95 nfscl_request+0x5a
> nfsrpc_statfs+0x19d nfs_statfs+0x148 vfs_statfs_sigdefer+0x2e
> kern_getfsstat+0x1f1 sys_getfsstat+0x22 amd64_syscall+0x12e
> fast_syscall_common+0xf8
> 
> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
> â¯
> 
> this was built yesterday:
> ⯠uname -a
> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #142
> ler/freebsd-main-changes-n257453-175a127a72f: Wed Aug 17 09:23:32 CDT
> 2022
> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
> amd64
> 
> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
> â¯
> 
> What else do we need?

It looks like a BUNCH of processes are hung, including poudriere, and my 
PostgreSQL buildfarm animal.

I can keep it in this state for a bit and give access to  that 
wants to look.


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Thu Aug 18 15:46:13 2022
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 4M7q4H1rVLz4ZnYx
	for ; Thu, 18 Aug 2022 15:46:23 +0000 (UTC)
	(envelope-from SRS0=2WHf0g=YW=codenetworks.net=sm@eigbox.net)
Received: from bosmailout04.eigbox.net (bosmailout04.eigbox.net [66.96.184.4])
	(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 4M7q4G3C4Kz45YC
	for ; Thu, 18 Aug 2022 15:46:22 +0000 (UTC)
	(envelope-from SRS0=2WHf0g=YW=codenetworks.net=sm@eigbox.net)
Received: from bosmailscan09.eigbox.net ([10.20.15.9])
	by bosmailout04.eigbox.net with esmtp (Exim)
	id 1oOhit-000126-5g
	for freebsd-current@freebsd.org; Thu, 18 Aug 2022 11:46:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=codenetworks.net; s=dkim; h=Sender:Content-Transfer-Encoding:Content-Type:
	Subject:From:To:MIME-Version:Date:Message-ID:Reply-To:Cc:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
	List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=PpZjJ9ZNwu/pe6zkJgVhosISY7njaYumK1//K799lZI=; b=Hb0MsO2CPamux8H8oq8ps9N5xq
	j7rBnt6GUQP1VI+sZZGKCWxG4t/iGOi2QPFl9XYkgsWfdwfuqdsX3UQ+pTZK2rjjo2VUps0vmUMKi
	C673D5dwyt+pEqGywkSKiKodQwqpioqzXi9nSYl5mqwwDaLo6OmDNtO2rQRTcokRsqecQkS0vo+qg
	+VstEjWbsnOExwk6kuk0fvEj1UJLtdN6amEBCaIpIy5fRrIEXOIebbzDFGfJ8MkVnxMtNDAutKKhg
	eW2E+1A74Dde+8LHyEY+Rjh7nugQJBMi6f5non3I9Higpx/6b1d2GaBu0wSeFWtVcVkzq8DwfEtw6
	/bgcGNwg==;
Received: from [10.115.3.32] (helo=bosimpout12)
	by bosmailscan09.eigbox.net with esmtp (Exim)
	id 1oOhis-0000N5-L4
	for freebsd-current@freebsd.org; Thu, 18 Aug 2022 11:46:18 -0400
Received: from bosauthsmtp05.yourhostingaccount.com ([10.20.18.5])
	by bosimpout12 with 
	id 93mF2800T06Zqne013mJ2S; Thu, 18 Aug 2022 11:46:18 -0400
X-Authority-Analysis: v=2.3 cv=d4VuNSrE c=1 sm=1 tr=0
 a=eBvjjtMVdWwtQGedh7GyLg==:117 a=Ek/qOh1uPkKSHvd30yk7rg==:17
 a=IkcTkHD0fZMA:10 a=biHskzXt2R4A:10 a=-Yl_685HdVUA:10
 a=-cxPwPxGPXHJAhikaesA:9 a=QEXdDO2ut3YA:10
Received: from cm-81-9-194-73.telecable.es ([81.9.194.73]:26448 helo=[192.168.3.100])
	by bosauthsmtp05.eigbox.net with esmtpa (Exim)
	id 1oOhip-0002b8-Bs
	for freebsd-current@freebsd.org; Thu, 18 Aug 2022 11:46:15 -0400
Message-ID: 
Date: Thu, 18 Aug 2022 17:46:13 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-US
To: freebsd-current 
From: Santiago Martinez 
Subject: kernel panic during zfs pool import
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-EN-UserInfo: d3bdfab0736480cedf04ed92aaea2ef5:931c98230c6409dcc37fa7e93b490c27
X-EN-AuthUser: sm@codenetworks.net
X-EN-OrigIP: 81.9.194.73
X-EN-OrigHost: cm-81-9-194-73.telecable.es
X-Rspamd-Queue-Id: 4M7q4G3C4Kz45YC
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none ("invalid DKIM record") header.d=codenetworks.net header.s=dkim header.b=Hb0MsO2C;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of "SRS0=2WHf0g=YW=codenetworks.net=sm@eigbox.net" designates 66.96.184.4 as permitted sender) smtp.mailfrom="SRS0=2WHf0g=YW=codenetworks.net=sm@eigbox.net"
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	FORGED_SENDER(0.30)[sm@codenetworks.net,SRS0=2WHf0g=YW=codenetworks.net=sm@eigbox.net];
	R_SPF_ALLOW(-0.20)[+ip4:66.96.128.0/18];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_TLS_LAST(0.00)[];
	R_DKIM_PERMFAIL(0.00)[codenetworks.net:s=dkim];
	ASN(0.00)[asn:29873, ipnet:66.96.128.0/18, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[66.96.184.4:from];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[sm@codenetworks.net,SRS0=2WHf0g=YW=codenetworks.net=sm@eigbox.net];
	RCVD_COUNT_FIVE(0.00)[5];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[codenetworks.net:~];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[codenetworks.net: no valid DMARC record];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi everyone,

I have a server running 13.1-stable that was powered off (gracefully) 
and now is been powered on again and we have the following problem.

The server boots almost properly, kernel load and when zfs import other 
pools it panic with the following message.

"panic : Solaris (panic) zfs: adding existent segment to range tree 
(offset=4af2ca9000 size=a0000)".

if i boot into single user and the pools (most specifically pool01 ) is 
not imported then there is no panic. but as soon as we try to import 
pool01 we get that panic error. it worth mentioning that the pool 
imported/online before.

Have two question:

*    How i can tell to not import the pool automatically during boot so 
sever is not stuck in a boot/panic/reboot infinite loop?

*    Anybody know what this panic means?

Thanks in advance!

Santi



From nobody Thu Aug 18 19:45:10 2022
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 4M7wMs3yjjz4Z7Sq
	for ; Thu, 18 Aug 2022 19:45:13 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7wMr4x2yz3Vcb
	for ; Thu, 18 Aug 2022 19:45:12 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To:
	From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=GU83pEA2Nuh/oybjUh7fyuu0J9OmUkjJiYBIrFTrNoU=; b=fDzTLXLfCOui0IylgrpMxPe5Tu
	kFM6ECj5wfjmo0tNd+caLygjoAwMWIqCkKGZ7gONYDZTGK69hcDP5n1+nm+YScDam1XdH8dESpEYp
	pCGjpioz/LgO4STk4ArgnHn5timoA3WjCdxnjoxPrnCXT1zbyXV6m0IXVoeYiSUbBgsJdca7Wd12L
	sGWNd9OFb7MW8EMBpIi4oN6owcoxYS5iihoEFVTYhMPvaLPm3vTNJGSWeois3Lpd0e4e/E8MbHl5/
	5rO/C+SO8iqzLa8bCWsP10ikSAF69cpX1VmTFIbHvTPqYc8UVxxYmO9qovUU3YWPfbemhqiZy1SpU
	l80LBdCw==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:65271 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oOlS2-000MBm-Js
	for freebsd-current@freebsd.org;
	Thu, 18 Aug 2022 14:45:10 -0500
Received: from 2600:1700:210:b18f:e5e3:a238:1fa4:1f20
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Thu, 18 Aug 2022 14:45:10 -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
Date: Thu, 18 Aug 2022 14:45:10 -0500
From: Larry Rosenman 
To: Freebsd current 
Subject: Lots of port failures today?
Message-ID: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4M7wMr4x2yz3Vcb
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=fDzTLXLf;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[lerctr.org:+];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

https://home.lerctr.org:8888/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s

circa 97ecdc00ac5 on main
Ideas?

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Thu Aug 18 19:45:48 2022
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 4M7wNf0HzYz4Z7l9
	for ; Thu, 18 Aug 2022 19:45:54 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from pv50p00im-ztbu10021601.me.com (pv50p00im-ztbu10021601.me.com [17.58.6.57])
	(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 4M7wNd15Fmz3Wjx
	for ; Thu, 18 Aug 2022 19:45:53 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1660851951; bh=VzMD9x7/SpVzMJk3gF+2SJDwEye/cUdbm+RqpB9D31Q=;
	h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To;
	b=Nm+62uEEXaQYIYFOpeJr8WCttD877lKtU0H8sXsC/mV09k71EVu9ljlNLoVf0VbDn
	 SGYwqFBXT/zp6hJQwygoBzGgIBt+3YKiqs5N9FTgaTZiC/XUIA+puUap46gBrnlfDi
	 nh/aseVaJ9wgB/dJMqCvbHcK7HjrEbA3ttjJ1EOalHn5detc+fXpN7sz2kTWfOshgT
	 Pay2n8o4xQYE+O2K3gIbAwiT1raD1Dd5+3hgydCktZ7gDJE2jbCr0A6lfq9AoxKvfp
	 5GicT0rmLGva3ehkcpn2+i6vQqhSbERl+8EcVzIRQ1/AgqRE6U1fDO2BWkuyvHOgST
	 g5Rw0NvrojlRA==
Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10])
	by pv50p00im-ztbu10021601.me.com (Postfix) with ESMTPSA id 6E9DB8073B;
	Thu, 18 Aug 2022 19:45:50 +0000 (UTC)
From: Toomas Soome 
Message-Id: <5F75D096-F28C-436E-B5C0-4A0EFA7A5F3C@me.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6C9EECB5-362C-43DB-90AF-9D3DE614A4BE"
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: kernel panic during zfs pool import
Date: Thu, 18 Aug 2022 22:45:48 +0300
In-Reply-To: 
Cc: freebsd-current 
To: Santiago Martinez 
References: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Proofpoint-GUID: FW-DBBxOPuJemPChQKwEVfFM4Ta_bb2J
X-Proofpoint-ORIG-GUID: FW-DBBxOPuJemPChQKwEVfFM4Ta_bb2J
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.883,17.0.605.474.0000000_definitions?=
 =?UTF-8?Q?=3D2022-06-21=5F08:2020-02-14=5F02,2022-06-21=5F08,2020-01-23?=
 =?UTF-8?Q?=5F02_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 clxscore=1011
 adultscore=0 mlxscore=0 phishscore=0 mlxlogscore=999 suspectscore=0
 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2206140000 definitions=main-2208180071
X-Rspamd-Queue-Id: 4M7wNd15Fmz3Wjx
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=Nm+62uEE;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.6.57 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-3.60 / 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)[me.com,quarantine];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16];
	R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.57:from];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEFALL_USER(0.00)[tsoome];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[17.58.6.57:from];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[me.com:+];
	TO_DN_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[me.com];
	DWL_DNSWL_NONE(0.00)[me.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[me.com];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_6C9EECB5-362C-43DB-90AF-9D3DE614A4BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 18. Aug 2022, at 18:46, Santiago Martinez  =
wrote:
>=20
> Hi everyone,
>=20
> I have a server running 13.1-stable that was powered off (gracefully) =
and now is been powered on again and we have the following problem.
>=20
> The server boots almost properly, kernel load and when zfs import =
other pools it panic with the following message.
>=20
> "panic : Solaris (panic) zfs: adding existent segment to range tree =
(offset=3D4af2ca9000 size=3Da0000)".
>=20
> if i boot into single user and the pools (most specifically pool01 ) =
is not imported then there is no panic. but as soon as we try to import =
pool01 we get that panic error. it worth mentioning that the pool =
imported/online before.
>=20
> Have two question:
>=20
> *    How i can tell to not import the pool automatically during boot =
so sever is not stuck in a boot/panic/reboot infinite loop?

removing zpool.cache should do. unfortunately, you would need to boot =
alternate root (usb/cd/net) for that.

>=20
> *    Anybody know what this panic means?
>=20

in short - bug. I=E2=80=99d try to boot current and import pool there - =
maybe the issue is fixed in current=E2=80=A6

rgds,
toomas

> Thanks in advance!
>=20
> Santi
>=20
>=20
>=20


--Apple-Mail=_6C9EECB5-362C-43DB-90AF-9D3DE614A4BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 18. Aug 2022, at 18:46, Santiago Martinez <sm@codenetworks.net>=
 wrote:

Hi everyone,

I have a server =
running 13.1-stable that was powered off (gracefully) and now is been =
powered on again and we have the following problem.

The server boots almost properly, kernel load and when zfs =
import other pools it panic with the following message.

"panic : Solaris (panic) zfs: adding existent segment to =
range tree (offset=3D4af2ca9000 size=3Da0000)".

if i boot into single user and the pools (most specifically =
pool01 ) is not imported then there is no panic. but as soon as we try =
to import pool01 we get that panic error. it worth mentioning that the =
pool imported/online before.

Have two =
question:

*    How i can =
tell to not import the pool automatically during boot so sever is not =
stuck in a boot/panic/reboot infinite loop?

removing zpool.cache should do. =
unfortunately, you would need to boot alternate root (usb/cd/net) for =
that.


*    Anybody =
know what this panic means?


in =
short - bug. I=E2=80=99d try to boot current and import pool there - =
maybe the issue is fixed in current=E2=80=A6

rgds,
toomas

Thanks in advance!

Santi




=

--Apple-Mail=_6C9EECB5-362C-43DB-90AF-9D3DE614A4BE--

From nobody Thu Aug 18 20:03:37 2022
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 4M7wn90Bqqz4ZBBn
	for ; Thu, 18 Aug 2022 20:03:41 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7wn81LY8z3Yvq
	for ; Thu, 18 Aug 2022 20:03:40 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: by mail-lj1-x235.google.com with SMTP id q18so1691934ljg.12
        for ; Thu, 18 Aug 2022 13:03:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc;
        bh=LHoCT5uT3t/AzTG8RS34NO9orRL2RyUgBlSoG3ZW4wk=;
        b=DQJCcULTMabdL6pvLcDgo4lZb5xYL8FnJLRQCV7FrHYT8bcye+rgZuk2zQy/qGSP2D
         I6yNmS8uV5SOF5EoPSyjEHkNMxPrBn1ChpyNgxq1WiVqrBoO1NUS0+ry1RNQhF9GeDxM
         bCmmihbOA1+L353dnQqbrfJ2rWjfHHnv1r4L667S+OfQtwUyCxhIX7ALj8+joXPMY+F3
         eU5ef0b9+QrZASIbXRhIPHc66+VSY+3jhEZVcH0l57xI0+zmRh6+mpzHwMhsy+b3PQnK
         56zicUl0DhApnspqSZPLjxlyv9H3DHKEyOMdG4oD7yIDeDJbwjvxKHOTytin0MPYHFp6
         aGIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc;
        bh=LHoCT5uT3t/AzTG8RS34NO9orRL2RyUgBlSoG3ZW4wk=;
        b=YZ2XqlDWGPaC4jleGeci7ayrB5rwOjiHHWExp0I1f6kqmORTuhTota8dWmHIWKQODs
         wVNG7+obyP1J2l1H2yhaJHhKXC1pUjnQ8w7K87WyxEGLfKPAH1rWXmkvLSnyGQo4fG+o
         8ZOqfSZbZLtmG+301Y68svAkcp2+CDQeWYBFXsMNqRnagi0NXOOkP6bZjb7EhIFfshYB
         0BT2fJvUq3qoUh6nH8Fn0J0vkRiDrpCcEaoWUdBDtbNBtTzpCR+3PqgZjNYDYOPDHh5F
         Pb98Dj506Hh1/z3d0pq58znSzFs4JLca/PJZJg/1weiETVZQkWDSG6mDxB3NwS12pzNf
         xPZw==
X-Gm-Message-State: ACgBeo3QjJlGMbehbCoYF7BA98IaqsTQ1O6i+OnRzmjjOSY/oLPlwfbD
	7Th4lc3d1iT16D5t3NsDOJBz9RkHb628XKVppmolwsrX
X-Google-Smtp-Source: AA6agR40pTPgHu3jEuxqrB7kKsQC8dO3b8w3n2LazkXY+5ZlwNI4isM/8TdUM3NFolkYGGDh+FETrKbqYlSai4KXqUc=
X-Received: by 2002:a2e:804c:0:b0:261:806b:b86d with SMTP id
 p12-20020a2e804c000000b00261806bb86dmr1234191ljg.460.1660853018244; Thu, 18
 Aug 2022 13:03:38 -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
Received: by 2002:a05:6520:2b8a:b0:1fe:cc4c:a235 with HTTP; Thu, 18 Aug 2022
 13:03:37 -0700 (PDT)
In-Reply-To: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org>
References: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org>
From: Mateusz Guzik 
Date: Thu, 18 Aug 2022 22:03:37 +0200
Message-ID: 
Subject: Re: Lots of port failures today?
To: Larry Rosenman 
Cc: Freebsd current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4M7wn81LY8z3Yvq
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=DQJCcULT;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::235 as permitted sender) smtp.mailfrom=mjguzik@gmail.com
X-Spamd-Result: default: False [-2.13 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	NEURAL_HAM_LONG(-0.84)[-0.836];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	NEURAL_HAM_MEDIUM(-0.30)[-0.296];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::235:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 8/18/22, Larry Rosenman  wrote:
> https://home.lerctr.org:8888/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s
>
> circa 97ecdc00ac5 on main
> Ideas?
>

try with 9ac6eda6c6a36db6bffa01be7faea24f8bb92a0f reverted

-- 
Mateusz Guzik 

From nobody Thu Aug 18 20:11:30 2022
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 4M7wyR4rD6z4ZC7M
	for ; Thu, 18 Aug 2022 20:11:43 +0000 (UTC)
	(envelope-from phascolarctos@protonmail.ch)
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
	(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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7wyQ45sXz3bRf
	for ; Thu, 18 Aug 2022 20:11:42 +0000 (UTC)
	(envelope-from phascolarctos@protonmail.ch)
Date: Thu, 18 Aug 2022 20:11:30 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch;
	s=protonmail3; t=1660853500; x=1661112700;
	bh=+KJm4x4RFwyozTAPsrHSXeMXvoNCrQ6ssibJwVWFuuU=;
	h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
	 References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
	 Feedback-ID:Message-ID;
	b=TC2EY90J2Ye7hNbDhb8nc9Avx6RJu+dhckxhktWrszpdLBOQzkiSW9IQnSg8pml/n
	 qKDunVI8nMI1tO+PoMkD6QW1T1AYqnUBaaWWajhYq12qNvEwOzTzNidEjMe1J5GcJQ
	 ZJSvlOxMA57gTSP9dOmbEiDwhh4CSY6RC9ntVRHk20WpQQNtZvsWF3GD5vvb06N3Mh
	 gze0KANNqsW9ayTTRUVU4lZblalcCzmgzfiIAVHZtp0DuquBKTR7VNtqWLjY5DjqHh
	 ngvvvIeJqdsPmJixH9iOK5CbY+F4Ox+3ssMHE7keYfk+q9wS3w10m82BTIeOywRcKS
	 urW9g30MlNENQ==
To: Larry Rosenman 
From: Lorenzo Salvadore 
Cc: Freebsd current 
Reply-To: Lorenzo Salvadore 
Subject: Re: Lots of port failures today?
Message-ID: 
In-Reply-To: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org>
References: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org>
Feedback-ID: 8540510:user:proton
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-Queue-Id: 4M7wyQ45sXz3bRf
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protonmail.ch header.s=protonmail3 header.b=TC2EY90J;
	dmarc=pass (policy=quarantine) header.from=protonmail.ch;
	spf=pass (mx1.freebsd.org: domain of phascolarctos@protonmail.ch designates 185.70.43.16 as permitted sender) smtp.mailfrom=phascolarctos@protonmail.ch
X-Spamd-Result: default: False [-2.99 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.99)[-0.993];
	DMARC_POLICY_ALLOW(-0.50)[protonmail.ch,quarantine];
	R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24];
	R_DKIM_ALLOW(-0.20)[protonmail.ch:s=protonmail3];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_COUNT_ZERO(0.00)[0];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH];
	MIME_TRACE(0.00)[0:+];
	HAS_REPLYTO(0.00)[phascolarctos@protonmail.ch];
	DKIM_TRACE(0.00)[protonmail.ch:+];
	MID_RHS_MATCH_FROM(0.00)[];
	REPLYTO_EQ_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.43.16:from]
X-ThisMailContainsUnwantedMimeParts: N

------- Original Message -------
On Thursday, August 18th, 2022 at 21:45, Larry Rosenman  wr=
ote:


>=20
>=20
> https://home.lerctr.org:8888/build.html?mastername=3Dlive-host_ports&buil=
d=3D2022-08-18_13h12m51s
>=20
> circa 97ecdc00ac5 on main
> Ideas?

I don't know, but I can tell that I received two pkg-fallout mails today: o=
ne for gcc12 and
the other one for gcc13-devel and none of them has been updated recently. S=
o I guess something
changed in one of their dependencies, which might have affected some other =
ports.

Cheers,

Lorenzo Salvadore

From nobody Thu Aug 18 21:25:17 2022
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 4M7ybN1QXxz4ZMY2
	for ; Thu, 18 Aug 2022 21:25:20 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7ybM4FWcz3l5J
	for ; Thu, 18 Aug 2022 21:25:19 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: by mail-lj1-x232.google.com with SMTP id q18so1856753ljg.12
        for ; Thu, 18 Aug 2022 14:25:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc;
        bh=T85Ta3SNK15lg6nejkJRy/RYgcQFORzRhMyxpjri/sA=;
        b=GcwTeDAizmRL/TVM0cfCxgfsw7WxP6QhpAqnbZH576d2lrIB//2uRA4mvVZlJAB+tL
         wowicz+eQTrFA0ebs772Y5/rkXdDcSplMoB+rhH+je1em70RFEGUDEUENQ//ycDGAb0Z
         +BFo0KaYdZuO3Z0SVEic5otoYQTlIh0VOSDEPDTmnvgYEPyon8PD2tgfqxF8SdpL21Dc
         WteyxEWRSZ5vQIuRQCQkdeowUH6ktqmTR3ya51Lr1JMonPaOU5AMvwm0HMHHTB4XDBqW
         ReGgVoj5wNgwtbpVbUhZbM9R0714CM53kV/0aSFSaHeIeMM91pJbS9e8qLqJFoFYjAF0
         cw3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc;
        bh=T85Ta3SNK15lg6nejkJRy/RYgcQFORzRhMyxpjri/sA=;
        b=WYYsOTlbilRxk+j9NfPeu5mWl+RL/nC5QDK9eFete+LxSGQDT6nr0BzDHIW4+UJcxb
         TLY2djd2CgGAL0dejHQumdweC4D7amwiDPlg2alaLTn5p6qLzqimFThtcvAq8BJ4nJqt
         ekpgKJk1FF6jfPwpmieqOKWbzwtjbajHebGCBYTe/QL5oWeQOt/wqT7RZxVjE4wHhkc1
         i1NbtQc0iJ7uVIxrrMZop7QNl8h4oQq3mkIo3hg2h9j1v4bbMh5aAZ6yeUWN7X08LP8K
         nlmgQNMKDCJrJhTaKc8+a5f8wstfRyr16GVg2boE/6K3KK2dKbqTwsUW3k1+8uErXrJQ
         4wdA==
X-Gm-Message-State: ACgBeo3MVfRvTc/wM8mqkwe4ZRohfblsMVXcXlAqlROi0cCnuiaJrKMv
	7lqPEufio8bJ+ZDLzr+wMY1Z5bj7RuAnz5L7SoIKkFTT
X-Google-Smtp-Source: AA6agR4H1i+YrmVXujCJguxW/MM+n3tREOlb3eJWtOhR02HCaW0AIqWu/KaiycJmGL6pKe50nBFp8iSm7NP2uayZIq4=
X-Received: by 2002:a2e:a22f:0:b0:261:ba8f:4f79 with SMTP id
 i15-20020a2ea22f000000b00261ba8f4f79mr445631ljm.490.1660857917903; Thu, 18
 Aug 2022 14:25:17 -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
Received: by 2002:a05:6520:2b8a:b0:1fe:cc4c:a235 with HTTP; Thu, 18 Aug 2022
 14:25:17 -0700 (PDT)
In-Reply-To: 
References: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org> 
From: Mateusz Guzik 
Date: Thu, 18 Aug 2022 23:25:17 +0200
Message-ID: 
Subject: Re: Lots of port failures today?
To: Larry Rosenman 
Cc: Freebsd current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4M7ybM4FWcz3l5J
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=GcwTeDAi;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::232 as permitted sender) smtp.mailfrom=mjguzik@gmail.com
X-Spamd-Result: default: False [-1.79 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	NEURAL_HAM_LONG(-0.95)[-0.951];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	NEURAL_SPAM_MEDIUM(0.15)[0.150];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::232:from];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 8/18/22, Mateusz Guzik  wrote:
> On 8/18/22, Larry Rosenman  wrote:
>> https://home.lerctr.org:8888/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s
>>
>> circa 97ecdc00ac5 on main
>> Ideas?
>>
>
> try with 9ac6eda6c6a36db6bffa01be7faea24f8bb92a0f reverted
>

I'm pretty sure it will be fixed with  URL:
https://cgit.FreeBSD.org/src/commit/?id=545db925c3d5408e71e21432895770cd49fd2cf3

-- 
Mateusz Guzik 

From nobody Thu Aug 18 21:27:25 2022
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 4M7ydr6tnQz4ZMx3
	for ; Thu, 18 Aug 2022 21:27:28 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7ydr1BCFz3mJH
	for ; Thu, 18 Aug 2022 21:27:28 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=0BmrhFofHajL+adH2ma8h2fEEG6RiLLZDr7/yV5ugk8=; b=SaHYY0T3UJpFyWeXIpZL5w8/k+
	mBeAmQOM0eOiwTmf4VyTeOWuNy16/vyZiivE1ufxditio7kMonifgx+R/shOicnGAXMbJuzulvhce
	FxVGPdUy9o54CW3LqLbm2JR/Fpt9yAn3HiKUTx1qnuWjuDSL9TAvBXR9wt6KAis8UDyLTlDtsH1OE
	osrL9hPXX0SdQw3FnE2ngm8c1dAv8UqCNR8CdSYZtjIRr/CAqWMaFJos9dcVhGE8QRSdmiT0hkfHw
	SbcaGj8qVmntgpDWc99zqM/RI05+fP3UIzHHLPAcRqesjR2TzEInO2lnBfc2e6y431racCth5r6KT
	N34m7s6A==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:65275 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oOn2z-000Nv1-Qc;
	Thu, 18 Aug 2022 16:27:25 -0500
Received: from 2600:1700:210:b18f:e5e3:a238:1fa4:1f20
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Thu, 18 Aug 2022 16:27:25 -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
Date: Thu, 18 Aug 2022 16:27:25 -0500
From: Larry Rosenman 
To: Mateusz Guzik 
Cc: Freebsd current 
Subject: Re: Lots of port failures today?
In-Reply-To: 
References: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org>
 
 
Message-ID: <7897de33237e37215d4c7c1f87062fd9@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4M7ydr1BCFz3mJH
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=SaHYY0T3;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[gmail.com];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 08/18/2022 4:25 pm, Mateusz Guzik wrote:
> On 8/18/22, Mateusz Guzik  wrote:
>> On 8/18/22, Larry Rosenman  wrote:
>>> https://home.lerctr.org:8888/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s
>>> 
>>> circa 97ecdc00ac5 on main
>>> Ideas?
>>> 
>> 
>> try with 9ac6eda6c6a36db6bffa01be7faea24f8bb92a0f reverted
>> 
> 
> I'm pretty sure it will be fixed with  URL:
> https://cgit.FreeBSD.org/src/commit/?id=545db925c3d5408e71e21432895770cd49fd2cf3
should I un-revert 9ac6eda6c6a36db6bffa01be7faea24f8bb92a0f and pick up 
a new pull?
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Thu Aug 18 21:28:58 2022
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 4M7ygm1CN0z4ZMmn
	for ; Thu, 18 Aug 2022 21:29:08 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7ygl11bfz3nQk
	for ; Thu, 18 Aug 2022 21:29:07 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660858145; bh=CqPTmo+AKqhK5BTQYCZcIsW6hMJakazU0HYKy99Dd8U=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=plA+/FMEeKlvmOymM5yP1d6Rnf05pu3KtZOo6iAj2aIlff6D3qaK1xJfqcrpj4tsPokRP4FbfIkmMv4Gd+AexHmMw4wl74EooyU2LbrczE1ZnimQkanUctHGN9xyV3q62UGzGVckypqA216ZTtgXfxmatcQPML3qhovQEkVSmy6BqWucHFLH1aRRBOrejK7jRuIgh1onJYCSI0zid61CxDclV3N0+OdSrBrPMf2NanGEdmoIhQS/V4PMqhG/kEK6A1m/VT5cgZ7aY5nWm2VT4ny97GjFJxD2eS+Rl+uhvnKAZzdIsSJ5NaxM+MWFBtzu9F7pYlJNv+gMUmOudqz08Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660858145; bh=1bS2RKJaNxRL11MyGz4lodY0KQMYBgX3FTe2R5la0Th=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=iUGO5RX/yZpoWhnCmXeYVsI811ijKE21t2IiIPG6gQUhHxjgCSVCBT3PO14icdkJyYCMpZVDRWU8aVF3RI3y/k3NQjI+PKXVvFY3saphhQhGz57ZDFxY9RdgFgWVbWpVkVVjJw40vaFSwdnUOcs7C11daJZ7X1lVZEMRSa3IJFzCiQtFUnInYCa6BScUIo5BKwvx6RjtvgH0097wNj2UX786niK75+43sU4CAyy3OOVto+F3uL9fIeYpEO0JMrIMaDBDN+SDMp2ujFtUlOAD+GWdHspdoKc/J4KG3NtRVihhJG0Hsr74tPKSppov6NIxUUU14cNwvziMAWr61LYJpg==
X-YMail-OSG: TPCNCDwVM1kRpyGKBttNhNMUI_aIHUEXjoSW1mjMItuveIPXLbPlMmBEHd9PxX6
 KpCq5ROaUq1GcmzBvcRAopjbazC9EFF8JVR1bpwQOGLZGdXPf.byFTUqkKfYQsNC9HmLcT8xg5yu
 Wfzx7R7vvNg9JhcQbY9IeuQ9rbRA9hImalI0CgQxFS_95mOLC.SaqPK3Md7PAYJibqr5GHACY5Xd
 yHbK2AZ7pX9Rx0vW75_ocnZE6lkBxem6TJdxBx0czuprK_KebZahHhBp5sE5sQ_1uRIFXvG7OcC9
 o1UvUs9LSAOptovOSsccD1_4bOxYNY1dnIwGpLyHuxT0FjaYPRtDJy_JFGqrLFbSjt4.IE.YDTzG
 RFSebv_1ZgzDGf17bNdQPQFZ8RwXIVwOlMtDT8hDvFuYA16r3FX2Gx_IJr4YAeKcNuttC.cpbz9b
 Zyf_7ydHMWCo0jwP_cj7XEo3vHXVWO1NuYdtH70uTYXeGYd6pybi0j7Ol5eAP9L8LPWeImK2helD
 RiM6dAn3TKgHfiFAPFJRIyAm.LtqYC0dkYKub4ZBu.GHaIsZUUffij7mURe3J2qmoUWXEKTt5JnN
 QnIEBBivqMka3npB30lO6EwU_4dLgx3cg1VdLTFO2wzF3mQnsXnyTDuEYG6qFwvYMRcCb64FlE3T
 rjrcjFyB2fFKOfhwhh7hVh7YE3XK2TZf8j3Dv4PC3xjqY9IxqqglQqmtsfc5stweKdLovYm_gBNo
 elVqy.le_ItCZoV5t6OEcqJDyAgmDxuUCPawqUrZTVTcjFMNPfuKZqM.FuYUdTlYKZFy5uRUVFK6
 Ddy2X91.mNmFYe5PEUnogfdMfpDcSTb3Huyiq8o6VfffACJnY6V12iXfnzo9Vd9z2m8Ysw5nAIqF
 dsd7i9dyktdzpvP.wkxgYlCb6Rn1ApKxPbNp8fGhk.bGH6RvhcRjpqBbd9gRzkWFgl9aPBs9dgA1
 ov3P9DsgavrfJP7LtsuDRT_bzf_vXm07XI8vV1Djs5NUQyFbhPOoLq.VVuH1lFMRxE0lw2x6CxOH
 35yB7u8D1ROWCTKMjH4pjt1R1IXgzY41Wjbzn45RuW5Enp.eflYvxUi7Cil0Zb5rXMb9.xwndXAE
 fiFb1tJonGebad0Ycl2Q_YgPUpsDOHo6FSFd2RpUvYUvHuxfegYOviT.ImZ27uHNCqFArVvBDa5O
 aIjClEOfmg2NJTL769HtN1Bxt.qH5eZEIs0KYp_U45IbrM6DmpclOsSQwLSJhtHWLvlD8ZKRx4ei
 6JBauh6jxxQzDITejQ7OWpRyibFdqzd0YNU_w7tL0k7NultwVa70JkOdgvPaeFt1b5p055.hT_Hn
 OEEIyX.Uh_sNzqV7WSdU0P7p9iQwQNkck0aEqwQMXJfM6QsVO5cL5dVvUno2DEWiwHKTKTyS5Vzg
 oMX6KRXQWFzEvLAksaSb1_rxp_OYTYRdt7FcMG9MEjRLgM57TDERV0P5FtdMRqyG2Sm__k0dsJrF
 UbnY2x3AQkcFHGMVRi8oDsIp_TiRtoYWba4vcQoIiQ5xfhlt9QKrNrRtkjUB98_3D9wNOWj4J4B0
 4zDPnuiJdug1dLnnZAv2IWxiwMgJSUkH9XqUaqZ4yj3A8g0M1aPkn5DD4uediPMpWcsVX5J8ImYa
 AeqbMfT02yggVLZbCSLRx7r51cJSPW9NBylEjQOm638RRvrfFYyS00GjzceN4m9U7OEh.gtFugv8
 Khhjuudj6mOUHE229emVmEzupbV0hxLr8NvgIy_q2s8Fukr0R9P6N3FVkMHc05dCB6MM_AExmV6z
 exk0QS7qDr9Kwik2GQeeOJSC1W.TAI9ly3YI1ozqjZ3TSi2wfBCyZMYJVcMCSrvvSmSA55OdhbA4
 m5AD8mJ9aioeuxu9h7XZbG77iR_0ZDO.WvZDx_uqxzyN_Wmq_gpjMz5w9QYWPYHKYrnI2edSDs0j
 gM6XJzAkvDNa8ZgJayEkC6tH5tGMLoLAXWL06wDXrjx97jfAniacrCpaqMJRhj65Z2uUvYMJFN4u
 v5aur2AduYMrCjrNVN1syDh2Ey7eHDVIttcA2AFWSG4b_1UYmj9pgl21DykwzQdHchtp0YtovKro
 HESAr4gPruAKtthTiieZ_5Zaz2QCu0noFWTgcLKzgncRo_s9GososWnI7HFDbeCpw6T1a6vxTRQx
 jedx3yavhxXtpopVehRKjqEFxQaiJotYQNCrYRZvTrX0k3xwItlElhB2RLUzL6eMzSsoM2gEuAYH
 db6MwfrRNLFn3M59EwOZ5GvfCXCpi8xnF35plQW26M.5w38z_fOI.EHKHbL9LzpCM.y0HfZCW8Db
 _
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 Aug 2022 21:29:05 +0000
Received: by hermes--production-bf1-7586675c46-6jlzf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d6c21c676c5efceedf37385f60ee776b;
          Thu, 18 Aug 2022 21:29: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 14.0 \(3654.120.0.1.13\))
Subject: RE: Lots of port failures today?
Message-Id: 
Date: Thu, 18 Aug 2022 14:28:58 -0700
To: ler@lerctr.org,
 freebsd-current 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
References: 
X-Rspamd-Queue-Id: 4M7ygl11bfz3nQk
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="plA+/FME";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-2.42 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	NEURAL_HAM_MEDIUM(-0.92)[-0.925];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Larry Rosenman  wrote on
Date: Thu, 18 Aug 2022 19:45:10 UTC :

> =
https://home.lerctr.org:8888/build.html?mastername=3Dlive-host_ports&build=
=3D2022-08-18_13h12m51s
>=20
> circa 97ecdc00ac5 on main
> Ideas?

Unsure but . . .

A bunch of your errors start with text looking like:

QUOTE
CMake Error:
  The detected version of Ninja () is less than the version of Ninja =
required
  by CMake (1.3).
END QUOTE

After that is some variety across such examples, for example:

CMake Error at =
/usr/local/share/cmake/Modules/CMakeDetermineCompilerABI.cmake:49 =
(try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/CMakeTestCCompiler.cmake:26 =
(CMAKE_DETERMINE_COMPILER_ABI)
  CMakeLists.txt:5 (project)

vs.

CMake Error at =
/usr/local/share/cmake/Modules/CheckFunctionExists.cmake:92 =
(try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
  CMakeLists.txt:90 (check_function_exists)

vs.

CMake Error at =
/usr/local/share/cmake/Modules/CheckSymbolExists.cmake:148 =
(try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/CheckSymbolExists.cmake:71 =
(__CHECK_SYMBOL_EXISTS_IMPL)
  src/CMakeLists.txt:44 (check_symbol_exists)

vs.

CMake Error at /usr/local/share/cmake/Modules/CheckIncludeFile.cmake:95 =
(try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
  cmake/config-ix.cmake:60 (check_include_file)
  CMakeLists.txt:732 (include)

and so on.

But those are after the Ninja report and might be consequences
of whatever is going on for the Ninja reports.

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


From nobody Thu Aug 18 21:38:54 2022
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 4M7yv45wsNz4ZP8N
	for ; Thu, 18 Aug 2022 21:38:56 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7yv42ybvz3qdp
	for ; Thu, 18 Aug 2022 21:38:56 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: by mail-lf1-x135.google.com with SMTP id x19so3755344lfq.7
        for ; Thu, 18 Aug 2022 14:38:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc;
        bh=hdZ3SoGXnHcsR7W8NmY8PNyki3L3tdVFxFnKCV25C50=;
        b=h+YtRYL9Y7saTdDBYv9xtxOIjOHohIl0hBlVR9vwIUiLA2DabwQTrkQoNYsLVian/L
         pMiEat1ER8xV20LrRpt9yBEqeOfCvPvX/mB0CJgXD/iwPz8wz7nfemwWfAh/KmyjqDkv
         sOYxAVqL/szVsvPBtKyARHopmAiQfEAStpujeIp2ATTOSQFoJ+3pDtpPMg60yOmQCDfZ
         NPAPYCUKCqWrxiheORzHAI8J8XiLA5Iz2ryp2eE/GTkGLrXvNeh16ZKxS+RfHdfpCUmg
         21yFT8im66X/d/zT0WLK0yO7tvb7x0Lphh9HaFEqEdEdTXCjW9nOXLsmxW9cKc1qDnKO
         Pqew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc;
        bh=hdZ3SoGXnHcsR7W8NmY8PNyki3L3tdVFxFnKCV25C50=;
        b=mZLoLb5HV2kHlFN4VImyAADYtE4ci/Q7KeKndtnbV2PTofjsQgBj63tT07r1Nzl5GW
         wnjSgzL0+k7nkdBUmbCF9gRjcYacMzdSDlGjHVBRvDeJxAX+sAld12bJSMyIv6TwuUxY
         TzqArvR+IS9mWXFcLcMdeFo4JOO3Ckp1pBZezjpG4KJnF5/Tch2AH00IvjkBnMhYa4b9
         NzklBrvRd9cn/NMVTH1XIOfst2h1pfls3HUVKg6vkRo1qwMup51seOuudOTNqzHH7stw
         bFi0U8NtDztxgayfVuHr1IKAn+B+OurQbRz2eLhb75PWVWTu30rGrEPzo/3wXiyn1Yd7
         Q01w==
X-Gm-Message-State: ACgBeo3O/7RU4iOueVwtozyFVN0UQjShfggqO9sLsBinWfwI/nJU4tSZ
	U649S60gpjjSnspN2eDt4glOD8fahh+y6kM7Vr4=
X-Google-Smtp-Source: AA6agR6kxZmo5OWpUbYcNFN61Q9w3SmOJXKvk6U1M6cv4aQf9yO7traY3FVoyrN/esR1e5IgatQb7l70s9bEWQeg5Qw=
X-Received: by 2002:a05:6512:12c7:b0:48b:3bc4:10f4 with SMTP id
 p7-20020a05651212c700b0048b3bc410f4mr1435466lfg.411.1660858734832; Thu, 18
 Aug 2022 14:38:54 -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
Received: by 2002:a05:6520:2b8a:b0:1fe:cc4c:a235 with HTTP; Thu, 18 Aug 2022
 14:38:54 -0700 (PDT)
In-Reply-To: <7897de33237e37215d4c7c1f87062fd9@lerctr.org>
References: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org> 
  <7897de33237e37215d4c7c1f87062fd9@lerctr.org>
From: Mateusz Guzik 
Date: Thu, 18 Aug 2022 23:38:54 +0200
Message-ID: 
Subject: Re: Lots of port failures today?
To: Larry Rosenman 
Cc: Freebsd current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4M7yv42ybvz3qdp
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=h+YtRYL9;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::135 as permitted sender) smtp.mailfrom=mjguzik@gmail.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	NEURAL_HAM_LONG(-0.96)[-0.956];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	NEURAL_SPAM_MEDIUM(0.15)[0.149];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::135:from];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

ye just get stock top of the tree

On 8/18/22, Larry Rosenman  wrote:
> On 08/18/2022 4:25 pm, Mateusz Guzik wrote:
>> On 8/18/22, Mateusz Guzik  wrote:
>>> On 8/18/22, Larry Rosenman  wrote:
>>>> https://home.lerctr.org:8888/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s
>>>>
>>>> circa 97ecdc00ac5 on main
>>>> Ideas?
>>>>
>>>
>>> try with 9ac6eda6c6a36db6bffa01be7faea24f8bb92a0f reverted
>>>
>>
>> I'm pretty sure it will be fixed with  URL:
>> https://cgit.FreeBSD.org/src/commit/?id=545db925c3d5408e71e21432895770cd49fd2cf3
> should I un-revert 9ac6eda6c6a36db6bffa01be7faea24f8bb92a0f and pick up
> a new pull?
> --
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>


-- 
Mateusz Guzik 

From nobody Thu Aug 18 22:08:05 2022
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 4M7zZM3TClz4ZSsB
	for ; Thu, 18 Aug 2022 22:09:31 +0000 (UTC)
	(envelope-from shawn.webb@hardenedbsd.org)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7zZL45vdz3tRJ
	for ; Thu, 18 Aug 2022 22:09:30 +0000 (UTC)
	(envelope-from shawn.webb@hardenedbsd.org)
Received: by mail-qt1-x82e.google.com with SMTP id cr9so2168240qtb.13
        for ; Thu, 18 Aug 2022 15:09:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=hardenedbsd.org; s=google;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc;
        bh=kPLOc2HBKX7eixRFNWSjvqzEBS1j56Fkh/95n+yh3qU=;
        b=OPWLYffBbGiG+t+Bftd7y6T3m+UkRxUdlfFTl8GT64ERisZQ7+E+tsml9n1A90+YOw
         T5DgozODZWt0OUFrjYDsfKN+CcQmHhu9koF8AXawCtXLzfJllij/tE6v/nKk7r2wTL6X
         jKunopY7Y6JMeytblISfTuPl8E4871QHlRWLb8bdkLDterWjlOvX+jI15TgqlP1bwKry
         N/aNq1+EfeUGRWdoFHIguhL4uglB+UJWaCkkrDkmRasSEE7syHcaAkeUW6c1sJgLJNyi
         qPRGJFkkPiv1GjOwufuZgVG7W/mfJnxG96iG9CXJpMcDpjdj5uyuXySUhzc0J8F8lVGM
         mt7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc;
        bh=kPLOc2HBKX7eixRFNWSjvqzEBS1j56Fkh/95n+yh3qU=;
        b=qC6WwNR/1WFbTrbLl4cG6OKSIgs4Nb4tWtIQBa9pUndpv/BTDnc+mjwF/5hjnj0ASy
         2ZKOp/IOpyeTFf6uI357kwbt2d5rLHewBybKbxWbyMmzO84Jy11RE58SXghiBt9UfDH0
         x8Mc/71fAjK34do//abCn8ChqG3vYcQp+/Ch0vV8V2X4tIjIMeO1pSbjRvm9M/76dXIA
         vN75hNkfxOP1XU4/RPvdEW4Z8sefUHdrH/kBKlMQkuHsUcKhrLXWI/P2yAsr3bOH2F2y
         nxnmS6id+PgasQpKCSBeD1RiR2JVKtEod3HBgAHAELrkOz9o4yAo3WSVPa9IFWIrPxXv
         EdGw==
X-Gm-Message-State: ACgBeo05KCMLeha9wIo3NCK5+vNFmNACHvJufQCrOaZw/nhDMMqVxGVE
	8tkgDs5oNQ+7au72PppNbZtNpg==
X-Google-Smtp-Source: AA6agR7cBLJMEdU8G1UBeDIZmpX0fi3VNQo/042/XSrDnt1VyGTKUHPDpk1Xxd7/pATL+jEeHkvSEA==
X-Received: by 2002:ac8:5c82:0:b0:343:5983:a25b with SMTP id r2-20020ac85c82000000b003435983a25bmr4571287qta.552.1660860569813;
        Thu, 18 Aug 2022 15:09:29 -0700 (PDT)
Received: from mutt-hbsd (pool-100-16-219-215.bltmmd.fios.verizon.net. [100.16.219.215])
        by smtp.gmail.com with ESMTPSA id 22-20020ac85956000000b00343057845f7sm1954657qtz.20.2022.08.18.15.09.28
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 18 Aug 2022 15:09:28 -0700 (PDT)
Date: Thu, 18 Aug 2022 18:08:05 -0400
From: Shawn Webb 
To: Mark Millard 
Cc: ler@lerctr.org, freebsd-current 
Subject: Re: Lots of port failures today?
Message-ID: <20220818220805.bvassxn56f2olnob@mutt-hbsd>
X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD
 14.0-CURRENT-HBSD 
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="owjryreg4l5f6jdf"
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4M7zZL45vdz3tRJ
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hardenedbsd.org header.s=google header.b=OPWLYffB;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::82e as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org
X-Spamd-Result: default: False [-4.10 / 15.00];
	SIGNED_PGP(-2.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	MID_RHS_NOT_FQDN(0.50)[];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82e:from];
	DMARC_NA(0.00)[hardenedbsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[hardenedbsd.org:+];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--owjryreg4l5f6jdf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 18, 2022 at 02:28:58PM -0700, Mark Millard wrote:
> Larry Rosenman  wrote on
> Date: Thu, 18 Aug 2022 19:45:10 UTC :
>=20
> > https://home.lerctr.org:8888/build.html?mastername=3Dlive-host_ports&bu=
ild=3D2022-08-18_13h12m51s
> >=20
> > circa 97ecdc00ac5 on main
> > Ideas?
>=20
> Unsure but . . .
>=20
> A bunch of your errors start with text looking like:
>=20
> QUOTE
> CMake Error:
>   The detected version of Ninja () is less than the version of Ninja requ=
ired
>   by CMake (1.3).
> END QUOTE
>=20

The 14-CURRENT/amd64 package build I kicked off yesterday for
HardenedBSD is experiencing the same exact failure. Nearly 12,000
ports skipped:

http://ci-08.md.hardenedbsd.org/build.html?mastername=3Dhardenedbsd-current=
_amd64-local&build=3D2022-08-17_20h01m01s

Thanks,

--=20
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A=
4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

--owjryreg4l5f6jdf
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmL+uD4ACgkQ/y5nonf4
4fq6mA/8CmLr8hsViG+A1xKQGZEl48XnM3AM4tmBcHdoiAOM4Z9cNr/CNdA2jKS7
F4git9hz52Wn50fSOcuFpcFG5hNYbkBnLmo3qfEnKzOf0Iz8og48GvWkzINlmEW5
4SStWXKpsYYYh5kxFgHUbmtDQ+mR6jxFiIOJYreVP/zQlVBeKehHod6h2Bgs0PBr
iFd0QWZpPXWVvdtY4qQUG0DBa2YhAqg/wBtbZ96wnqwZNQXFCDTMhWHhej57cSAY
qoBKoobo6fS6aAzP7fdvkQf6IJ4ZSKqUVOsWlGyd0LYFtFDE+RgOhFZaw7qzdv8j
IHz9UFs4nWutzrEzXep3wGC4Iyr2vp24gwC56PxV4ZmE+e70Tp8zI3k4DbQ/2aYm
8Zcj4L1G5cSmZoyW1omscEKsRZBBeHD7T+uGUKyjIqJq8FDiQmGujaHK0dletw36
8EO+bCGV+ayYN5c9ysIea/Fw851iirBB+Nt125w4IcIPwcP/VZTzB9JXZimqt1nT
D9QLZH0ogoo1FMpGDyudPnSaAz7WiBSxDnaye/+xD2h1nnX/OghexLkDsutfbsum
L6z9omFlhf4l+uq6RNYIop/FsT0nxhEc+CrHj60+Qota6BctRjRhfwjwLoQA762A
Lvsjoa0LdGJ9lKtwHSS3IMuNpM+Li4AxfdW2hgCPCqhBulQoIyQ=
=fwth
-----END PGP SIGNATURE-----

--owjryreg4l5f6jdf--

From nobody Thu Aug 18 22:10:45 2022
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 4M7zbr2PYQz4ZSqH
	for ; Thu, 18 Aug 2022 22:10:48 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M7zbq3srPz3vNv
	for ; Thu, 18 Aug 2022 22:10:47 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: by mail-lf1-x134.google.com with SMTP id o2so3879620lfb.1
        for ; Thu, 18 Aug 2022 15:10:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc;
        bh=/oBYo+iRk2Y8QC8m/H6cjkSNBK1oo/hAnx26hC2+4V0=;
        b=X7Ke82gxdL1zGgI3yoiB46W7dP34GympslOWCiAJcufX0y7l/o2yRhzdWIjeAiiCt7
         itHrGweQcr0tqAxB4MlUAkxOTfO/mc1S2r29l8Kn43fVBcuJlKtMWUQp3jN5GLaMR7qX
         ywZ6AHACrT2KLm368vaDjd8pFwO9zWOF5G13vgk/sYn/Y5yJGM+0sjzu5HpykZ60X+AQ
         JmyXB5TMGbpVOLQ30SPnhYsXmX+Rr4hqtS20i84WUZiEKZ0V5TCGMzwQrt4RvEXAnexN
         yKWKF7wPXL3ZdFwlJtWB7EJzIlzm8C6kb4e+u07d7t6cwg1v1Z+4uVC09ZGpMG0s3U0y
         j/zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc;
        bh=/oBYo+iRk2Y8QC8m/H6cjkSNBK1oo/hAnx26hC2+4V0=;
        b=uFLcI0qIgBZ21A/cg4fgnrS3S4+kwORU6t9fr75yZ+mMs88gq/hIUkaYjNQFHymPAG
         fIY+okl1hNeIP6RtbXBgPaOSP/m6JG1G15GxjrhAMVMG4isI+OeI5KnJJ4VUSjgUcr70
         qDFGyoregAbpIOzD3zsbDBQVw5btxF9epdgW4fGjkjUqSnqtFg1UMT2zKlUIM29KD6Wb
         5T8T4VTLgRpyAffj1PDJGF39SDgU5/anCoCPRIKKc0uMtO3aAs8h25Z5+oB+IHIGom9A
         w5IKnwV589TgLR2ZyoQRNWfP0+AjPRd9fatovDnJRjWw3gVks4zNMHOEK2sCvtp1vr4l
         catw==
X-Gm-Message-State: ACgBeo0B1VclsH936G7xWP29JMm/ZmslUCOrYkFc+rjCijR0fS9eA/93
	kD7L2LSUy6jqqbq4pF6J2vFMlXCM9d4JHUIjj1Y=
X-Google-Smtp-Source: AA6agR4tOjngvmN8s7BerP8oq18D4abj1WC2v2DOZxbKGFbXRSUAcQJwpJe9RxzoFEHYqD68K54tX6ui9a8CKPO6Gcs=
X-Received: by 2002:a05:6512:3050:b0:48c:e580:4421 with SMTP id
 b16-20020a056512305000b0048ce5804421mr1621798lfb.34.1660860645820; Thu, 18
 Aug 2022 15:10:45 -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
Received: by 2002:a05:6520:2b8a:b0:1fe:cc4c:a235 with HTTP; Thu, 18 Aug 2022
 15:10:45 -0700 (PDT)
In-Reply-To: <20220818220805.bvassxn56f2olnob@mutt-hbsd>
References: 
  <20220818220805.bvassxn56f2olnob@mutt-hbsd>
From: Mateusz Guzik 
Date: Fri, 19 Aug 2022 00:10:45 +0200
Message-ID: 
Subject: Re: Lots of port failures today?
To: Shawn Webb 
Cc: Mark Millard , ler@lerctr.org, 
	freebsd-current 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4M7zbq3srPz3vNv
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=X7Ke82gx;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::134 as permitted sender) smtp.mailfrom=mjguzik@gmail.com
X-Spamd-Result: default: False [-2.66 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-0.99)[-0.992];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	NEURAL_HAM_MEDIUM(-0.67)[-0.674];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::134:from];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FREEMAIL_CC(0.00)[yahoo.com,lerctr.org,freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

this should do it:
https://cgit.FreeBSD.org/src/commit/?id=545db925c3d5408e71e21432895770cd49fd2cf3

On 8/19/22, Shawn Webb  wrote:
> On Thu, Aug 18, 2022 at 02:28:58PM -0700, Mark Millard wrote:
>> Larry Rosenman  wrote on
>> Date: Thu, 18 Aug 2022 19:45:10 UTC :
>>
>> > https://home.lerctr.org:8888/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s
>> >
>> > circa 97ecdc00ac5 on main
>> > Ideas?
>>
>> Unsure but . . .
>>
>> A bunch of your errors start with text looking like:
>>
>> QUOTE
>> CMake Error:
>>   The detected version of Ninja () is less than the version of Ninja
>> required
>>   by CMake (1.3).
>> END QUOTE
>>
>
> The 14-CURRENT/amd64 package build I kicked off yesterday for
> HardenedBSD is experiencing the same exact failure. Nearly 12,000
> ports skipped:
>
> http://ci-08.md.hardenedbsd.org/build.html?mastername=hardenedbsd-current_amd64-local&build=2022-08-17_20h01m01s
>
> Thanks,
>
> --
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
>
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
>


-- 
Mateusz Guzik 

From nobody Fri Aug 19 13:06:11 2022
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 4M8MT16Rrzz4Z4xx
	for ; Fri, 19 Aug 2022 13:06:13 +0000 (UTC)
	(envelope-from vishwin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M8MT15wsMz440b;
	Fri, 19 Aug 2022 13:06:13 +0000 (UTC)
	(envelope-from vishwin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660914373;
	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=SyqUGXKd25YOmwdJDtzGyROvzCsj8K+9T5NlXtg5hHs=;
	b=fAf8SWUp6qT2Hj+Gnqn0loC7QZm0XFXUeGvM8EBcsAJnZ0B2hot/T99hCQDVcfGb5MDVwy
	KexIMXeKV32YYcXDOCQ4uMq7Ctod6rxofYg6rmuqcLmqcmjASDwzMyTYl1HVIeph3p+YDl
	tumn4l+S6jVYMt7BtrCqRPhtcCq1hZk+3SYMV1GEm13oM7kTOANxiYnhCprFTuKPh+gpdd
	vPfqMQuJ0Q1bW0c9Jc+lx7Z9iBOeY5NYOXJLIAir5j/iapI+NGwWSy9/FuVVegq+LIip1v
	1O7xQv00Cl74OA4ZskyHse37kV8GVkAAQPzaDquF93IYGQD/QEf//I36/dS3GQ==
Received: from [192.168.0.3] (c-174-55-7-241.hsd1.pa.comcast.net [174.55.7.241])
	(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: vishwin/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M8MT13l40z1CmY;
	Fri, 19 Aug 2022 13:06:13 +0000 (UTC)
	(envelope-from vishwin@freebsd.org)
Message-ID: <0b601ee4-611b-9621-e010-fc2d3f4c9ac5@freebsd.org>
Date: Fri, 19 Aug 2022 09:06:11 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: Lots of port failures today?
Content-Language: en-GB
To: Mateusz Guzik , Larry Rosenman 
Cc: Freebsd current 
References: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org>
 
 
From: Charlie Li 
Organization: FreeBSD Project
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------hX4B6Y2ClKkqIzGc58hB9lsO"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660914373;
	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=SyqUGXKd25YOmwdJDtzGyROvzCsj8K+9T5NlXtg5hHs=;
	b=OWcuoJJZOPFpw37lY+1yStEvyAhc2Bs6xAjt39RvytaMRXKvVe1jp6q+YHddvehvGEgwQ7
	pQd/HLzAEF97jG0yANHJ3SfkPL6IIxV90SSg8heVhrCS23PNXDnZDmN0tjo4C4VR2IKalP
	yQ0eqNGd4rMXD+KZ5i7W4iNM500/qdmKXswYdGOLe6JbsFWrFELm1UxUWJ/fHf9xqL/EaH
	0gGTOwgSm+Ij+x7NGE/64kyeAOwwO2NrXTRsqr5HfoQu4EX8PDYduKE/DoEiPR70VUS0ag
	F81rywmsYAYu9YrPXBQmDChEckdnczOB91rMID/aaSffHyesH+w8icYqXBaUTg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660914373; a=rsa-sha256; cv=none;
	b=Zt4r5lYZ/t3ynysM7SxtUCY9139KMDDHUlA709jmSGcvr2s377GxElL2t4NxY5aV05Z+b5
	vqHN2291bfuVcDNpgKAnxmihFPaot1mCQMpwcGHQdbaYdj2VvYy44P+7AQC1uZz5ePBFuw
	v9BZ+GQntJ85BRT0ofUZkedHl+0WU65a0RnWf+8NoPFFogaDjrM7YP8HBRPqMmV/5Lr7Ed
	F3iCe2Gv7GJZe551T0p2FD3QzE4pTBk7AB1qeNH4P9IPh2OQuhaxIlvw7Nj9dR4Lx69QOl
	GE7DcKGnpfUmsujD/zxW/SNHpUxQWnPD+VExYl3bfdDG8koCaHuESxVdfjRGUw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------hX4B6Y2ClKkqIzGc58hB9lsO
Content-Type: multipart/mixed; boundary="------------KZHhcZQABrIaLW3bHTdPIMlL";
 protected-headers="v1"
From: Charlie Li 
To: Mateusz Guzik , Larry Rosenman 
Cc: Freebsd current 
Message-ID: <0b601ee4-611b-9621-e010-fc2d3f4c9ac5@freebsd.org>
Subject: Re: Lots of port failures today?
References: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org>
 
 
In-Reply-To: 

--------------KZHhcZQABrIaLW3bHTdPIMlL
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

TWF0ZXVzeiBHdXppayB3cm90ZToNCj4gT24gOC8xOC8yMiwgTWF0ZXVzeiBHdXppayA8bWpn
dXppa0BnbWFpbC5jb20+IHdyb3RlOg0KPj4gT24gOC8xOC8yMiwgTGFycnkgUm9zZW5tYW4g
PGxlckBsZXJjdHIub3JnPiB3cm90ZToNCj4+PiBodHRwczovL2hvbWUubGVyY3RyLm9yZzo4
ODg4L2J1aWxkLmh0bWw/bWFzdGVybmFtZT1saXZlLWhvc3RfcG9ydHMmYnVpbGQ9MjAyMi0w
OC0xOF8xM2gxMm01MXMNCj4+Pg0KPj4+IGNpcmNhIDk3ZWNkYzAwYWM1IG9uIG1haW4NCj4+
PiBJZGVhcz8NCj4+Pg0KPj4NCj4+IHRyeSB3aXRoIDlhYzZlZGE2YzZhMzZkYjZiZmZhMDFi
ZTdmYWVhMjRmOGJiOTJhMGYgcmV2ZXJ0ZWQNCj4+DQo+IA0KPiBJJ20gcHJldHR5IHN1cmUg
aXQgd2lsbCBiZSBmaXhlZCB3aXRoICBVUkw6DQo+IGh0dHBzOi8vY2dpdC5GcmVlQlNELm9y
Zy9zcmMvY29tbWl0Lz9pZD01NDVkYjkyNWMzZDU0MDhlNzFlMjE0MzI4OTU3NzBjZDQ5ZmQy
Y2YzDQo+IA0KU2VlbXMgdG8gYmUgZml4ZWQgd2l0aCB0aGlzIGNvbW1pdCwgYXQgbGVhc3Qg
Zm9yIGdyYXBoaWNzL2pwZWctdHVyYm8sIA0Kd2hvc2UgY29uZmlndXJlIGZhaWxlZCB3aXRo
IHNvbWV0aGluZyBhYm91dCBwbGF0Zm9ybSBub3Qgc3VwcG9ydGluZyBTSU1ELg0KDQotLSAN
CkNoYXJsaWUgTGkNCuKApm5vcGUsIHN0aWxsIGRvbid0IGhhdmUgYW4gZXhpdCBsaW5lLg0K


--------------KZHhcZQABrIaLW3bHTdPIMlL--

--------------hX4B6Y2ClKkqIzGc58hB9lsO
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmL/isMFAwAAAAAACgkQ/reFK+KbPocV
/Q//Zu7eoSyQooZiL7e0n9Ha64TwfznN3KU8MWWCFBX0eH19YhmMBYhqVkrZ3yyakVHfrP9x/PLK
b8j7o/q4I+/1wX5OOBF3oOgmPixTLmfNYX6BoKEIvIWwcRt5R4CpOmw4JDXFZKgKRxheyS1cAia6
j2+3KwpDThrrYO04nSUxYM9HpmPmSrP83BrtyMizC6/YcObVhGGueRZH/zE/WVkPvGBBg9o+M/Q/
LIWFdUTHpCEWWBsZxi3Kb7YgGJcmLUcfrH+ZI0BcuMH+9kJqtkjKRn/hXLd4bfWqeZWwcUgN+WIq
w3uzfekGX+7agET23xw88sl8+k/wAdReHflO8PDHcUXfDjvhcJn6kgoHX2CQataKfsTzrhbOTiEx
KYsVjMrGHhYcOBeTIqgcl54dqopjYvlLE+ctPkjhAAJ1naI4e/lmFQz5n/5eiftJhIoGAqMX0dO+
FQmWqsi52LykzopcCY6KFtAtSmRA/oObR+De4hw5pisO00jptqIdViUdi1cdhVwSSkI89HVaFrdw
EJPYQjPDdzHMwb+mz3xN/JO9SifJCIa9M3SZ7EsxS+sg1frCC0+IVrnoUkYAwZEhf60KgqKk658W
WnAJ3r3bGgwjQqsK9Td/aIPPWkkyo2SEOHKNxiCk756IBqSmtrvW5vmnBtfOsbhTl5rWBKFqH2BQ
FZ8=
=MAKq
-----END PGP SIGNATURE-----

--------------hX4B6Y2ClKkqIzGc58hB9lsO--

From nobody Fri Aug 19 15:03:22 2022
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 4M8Q4P6k3Nz4ZLRy
	for ; Fri, 19 Aug 2022 15:03:33 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M8Q4N1rbYz4KF7;
	Fri, 19 Aug 2022 15:03:32 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 27JF3Nfi061009;
	Sat, 20 Aug 2022 00:03:23 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Sat, 20 Aug 2022 00:03:22 +0900
From: Tomoaki AOKI 
To: Charlie Li 
Cc: Mateusz Guzik , Larry Rosenman ,
        Freebsd current 
Subject: Re: Lots of port failures today?
Message-Id: <20220820000322.d813bb9951f798fb2a534e87@dec.sakura.ne.jp>
In-Reply-To: <0b601ee4-611b-9621-e010-fc2d3f4c9ac5@freebsd.org>
References: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org>
	
	
	<0b601ee4-611b-9621-e010-fc2d3f4c9ac5@freebsd.org>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4M8Q4N1rbYz4KF7
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [-0.60 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_CC(0.00)[gmail.com,lerctr.org,freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[sakura.ne.jp];
	RCVD_TLS_LAST(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, 19 Aug 2022 09:06:11 -0400
Charlie Li  wrote:

> Mateusz Guzik wrote:
> > On 8/18/22, Mateusz Guzik  wrote:
> >> On 8/18/22, Larry Rosenman  wrote:
> >>> https://home.lerctr.org:8888/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s
> >>>
> >>> circa 97ecdc00ac5 on main
> >>> Ideas?
> >>>
> >>
> >> try with 9ac6eda6c6a36db6bffa01be7faea24f8bb92a0f reverted
> >>
> > 
> > I'm pretty sure it will be fixed with  URL:
> > https://cgit.FreeBSD.org/src/commit/?id=545db925c3d5408e71e21432895770cd49fd2cf3
> > 
> Seems to be fixed with this commit, at least for graphics/jpeg-turbo, 
> whose configure failed with something about platform not supporting SIMD.
> 
> -- 
> Charlie Li
> …nope, still don't have an exit line.

And so as base /usr/bin/xz (through pipe) and ports lang/ruby30.

The former caused x11/linux-nvidia-libs to fail on extract,
and the latter caused ports-mgmt/portupgrade (including portsclean) to
fail on start.

Both are fixed at the commit.
Thanks!

-- 
Tomoaki AOKI    

From nobody Fri Aug 19 15:14:08 2022
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 4M8QJn1hFYz4ZMT2
	for ; Fri, 19 Aug 2022 15:14:17 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M8QJl6pbhz4MWG;
	Fri, 19 Aug 2022 15:14:15 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=rhJsYGrUlNn2EjE7D5l/3JVfsT3L6nloEAefmxnYDY4=; b=Z8CrdOhBd+n4LIcVMpU/VKz4M+
	mWmGeGNDpom585fTRQiJFjhgFH0gJBl6Qzj6gl4TQgP19z71h7mmCcX3E+PBacpdhqp3EI94U8+kv
	fp79c3B8yJ23Z8UXOv+afQCQwq6rUM25FHyU7JZ1pzELWRSOj0Knd0wpGBYideOT/NUFHQlSG1vza
	+n22az+FjMVsAmhqwl/StBeYJgudf2FKRKxjdIQpTB9pCKJ1LkH07r1kZjNbLLYhCIVy1k8NKFOCa
	91KULrMGLMgYQZIDmjOOGEfNcn29CmP0b3iUU88Il3jQtqdVjXCr6vjulSQ7cX2CpciEDUhdMH8uQ
	nqlEp3Ug==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:36956 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oP3hI-000F8l-7J;
	Fri, 19 Aug 2022 10:14:08 -0500
Received: from 2600:1700:210:b18f:e5e3:a238:1fa4:1f20
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 19 Aug 2022 10:14:08 -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
Date: Fri, 19 Aug 2022 10:14:08 -0500
From: Larry Rosenman 
To: Tomoaki AOKI 
Cc: Charlie Li , Mateusz Guzik ,
 Freebsd current 
Subject: Re: Lots of port failures today?
In-Reply-To: <20220820000322.d813bb9951f798fb2a534e87@dec.sakura.ne.jp>
References: <8ceeb8126c480ea8617f6c774bb79ae2@lerctr.org>
 
 
 <0b601ee4-611b-9621-e010-fc2d3f4c9ac5@freebsd.org>
 <20220820000322.d813bb9951f798fb2a534e87@dec.sakura.ne.jp>
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4M8QJl6pbhz4MWG
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=Z8CrdOhB;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_CC(0.00)[freebsd.org,gmail.com];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEFALL_USER(0.00)[ler];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 08/19/2022 10:03 am, Tomoaki AOKI wrote:
> On Fri, 19 Aug 2022 09:06:11 -0400
> Charlie Li  wrote:
> 
>> Mateusz Guzik wrote:
>> > On 8/18/22, Mateusz Guzik  wrote:
>> >> On 8/18/22, Larry Rosenman  wrote:
>> >>> https://home.lerctr.org:8888/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s
>> >>>
>> >>> circa 97ecdc00ac5 on main
>> >>> Ideas?
>> >>>
>> >>
>> >> try with 9ac6eda6c6a36db6bffa01be7faea24f8bb92a0f reverted
>> >>
>> >
>> > I'm pretty sure it will be fixed with  URL:
>> > https://cgit.FreeBSD.org/src/commit/?id=545db925c3d5408e71e21432895770cd49fd2cf3
>> >
>> Seems to be fixed with this commit, at least for graphics/jpeg-turbo,
>> whose configure failed with something about platform not supporting 
>> SIMD.
>> 
>> --
>> Charlie Li
>> …nope, still don't have an exit line.
> 
> And so as base /usr/bin/xz (through pipe) and ports lang/ruby30.
> 
> The former caused x11/linux-nvidia-libs to fail on extract,
> and the latter caused ports-mgmt/portupgrade (including portsclean) to
> fail on start.
> 
> Both are fixed at the commit.
> Thanks!

and all my unexplained failures are fixed as well.

Thanks, Mateusz!
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Fri Aug 19 15:36:38 2022
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 4M8Qpf4CQYz4ZQ3h
	for ; Fri, 19 Aug 2022 15:36:42 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
Received: from CAN01-YQB-obe.outbound.protection.outlook.com (mail-yqbcan01on2073.outbound.protection.outlook.com [40.107.116.73])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M8Qpd3fGNz4PJw;
	Fri, 19 Aug 2022 15:36:41 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=lvg644Lda6nUsKtQPEs9PjseM1SKJM9kRQRAD5EH2aEjW1V1O9qDWbmMdTnx//Dsra6+yej7LPBSW9lDMtyy6lIz/J0+PN3cSUVWmeygMpgxUGRNObQd0ph+oJ9TTLbJez1Ws3TQGZxhUzQHm6VYE6dHgn1Z6SgXu6Tw7AyuItF5vF/atQ6R6r6oGlcFaSIkctNKRI86aoLW3Zm5rXgWqi3Vpol9dw55rSTrzmQhLjw+w41yhftvlcILOIICu2BP8xkQWyLCRJ772NIeFmMO/TNXmxd8mOXALSHwhPeQWGa1a1HO4V6AIVstG0laD6cmg/aT6baZKp1OkdBYZLd9eA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vwnjKnAz8Jtf1t5CrAsowEzqVinhFT2cAP/Sl9arAuw=;
 b=gCR1AaZx3Lsc1sh8C3L0u2S5fsFwCC0uW0ZsRA/dnMlu16CGaEfspJwJjXGmdpyKJx0tSvNf4id1uYMru0/myLXF3IXKHh/kHhYWVL+RB+J7VsUXgXSv80eDCDHYJ7PHnUd8fJ2iIp8JPUSSdSzRbpCHHIPOwQZax4oUwnl8jB08qrVOt8UtRMhVyqTzj6muEcrChm2z0LF1W58LIunti/FDePNb5VyFL/R1QzFgCKWIytHthuTtxZd/JIidYmCd12747OLyRW9aYnJlpwx1YXdH4dRkhECjvx1XXcaiYWPRQU5Faz8NlUnnf0agwgo8OvudaP2kAG3jVypjHhXCBg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca;
 dkim=pass header.d=uoguelph.ca; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vwnjKnAz8Jtf1t5CrAsowEzqVinhFT2cAP/Sl9arAuw=;
 b=qQ7maf9MGBWCYaom65zg68sfRgrKHG4BycPnUDF6IHr8mG57w4FFqhpBcJN2Ea63EPIIKW+k6t9K3AuLM7OsUNzr00bbLkJOIyvljrS93pvMM0mrk/NM7Dq6QBtsBOLIE51r6h8eojXMrOjJ7q63nCgBXPJMLPGOnvHoV9PzP4l5mpkRcKD4tanP444yM3zxuyd5UT+vctGibz2YCFxXzZVQx+eiYNfQQGjjpsR4sycBNfMAozv17z38x73JtV8XKXCsMb1FDWPC0jqXoxw8Jfof1Z6VXvC+V+d4cED3C/jwzjknl9b7hYsDNHGCx37wCMGGgBMDShZVd6pnxe3zpQ==
Received: from YT2PR01MB9729.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:df::22)
 by YQXPR01MB5961.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:3e::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5546.18; Fri, 19 Aug
 2022 15:36:38 +0000
Received: from YT2PR01MB9729.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::3865:f8eb:5111:8be7]) by YT2PR01MB9729.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::3865:f8eb:5111:8be7%5]) with mapi id 15.20.5525.011; Fri, 19 Aug 2022
 15:36:38 +0000
From: Rick Macklem 
To: Larry Rosenman , Freebsd current
	, Mark Johnston 
Subject: Re: Hangs in bacula / NFS? on recent Current
Thread-Topic: Hangs in bacula / NFS? on recent Current
Thread-Index: AQHYsxHW3iA9vauD+0uImi9puyyeoq20v2UAgAGYISA=
Date: Fri, 19 Aug 2022 15:36:38 +0000
Message-ID:
 
References: <405b3873b709d42feb438b5b954ecdc2@lerctr.org>
 <9e63f40233fc29c9fbc3fac0cb82acd5@lerctr.org>
In-Reply-To: <9e63f40233fc29c9fbc3fac0cb82acd5@lerctr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3ee69b6a-21d2-47f6-fe50-08da81f89b36
x-ms-traffictypediagnostic: YQXPR01MB5961:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 3K01RiGoa07HO5miUPadedi6V0NwH72cZMDL6EjwNHHEP3apvwyW8l1OQVBO52XohCq3UBMGPyWXE421na7AZKXDRccqp6H62hm3D8lw7SMk6ADn4sPSngqBTeGDs/6g0jjwPjiqb/aOaZVoPm20krhlQb/jOehvQPxmvbhlsTyIqfiH/vHCwYuuKwH3mWvG6obeaeyc5PSTOdz3Xc7ThI4BVVXzHysh8O4ajA429T6tH90+ehkPIwIUvG1hgApEmqa2Qk4arT7JJA0UxBEKOMTtNEaLijpftktXaX5+Pzon7+He6pltXIypvbA+SLg0jnX/oqDjleGz3MFDcY4oxiYNMJu4qVC083oRfSrEOb1mOC5xR9fs1+DoY4i796O96LI7I+W80+ihRuOevq8JULm/NqXRpiHhsN4Afn7qBs07LWU65vL3Dt84rzoiAwtWJvJBQeY0AA+WxXc7Wv9/idMwsfHeo1yCEW+9EfkEE3TXbo8t8Z5c1RZV08CwSLBCMZHY1rqrZRXC3YnCl9zBA1XzRfYm0BBF9RBPTRXTPqgk1yOA/6jkT9YmO3cEYsp5mf20gvjosGT6lhOa7wsY1zupVPkjT+OvI1pmlvDVso487qI2Tyc017eUlMhDO3GhkavoqqNfvV91J8OfJqHgSXArEonh0PjPnf6slT7vbBcNHZBVeWnnCZuz1HfzfQh0siEU8s0TEePyUATZTP/dLItTdT5LuamCuK9fVJAmvqYhqSJruRLEZ9ZUD3RnSdH6otQw5gjLIhefLhCEUiNYtistUEBcR1szWjsW58LAIHg=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9729.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230016)(4636009)(39860400002)(346002)(366004)(396003)(376002)(136003)(86362001)(38070700005)(122000001)(186003)(83380400001)(38100700002)(76116006)(91956017)(66476007)(41320700001)(316002)(786003)(5660300002)(33656002)(52536014)(110136005)(8936002)(66946007)(66446008)(64756008)(8676002)(2906002)(41300700001)(6506007)(7696005)(55016003)(53546011)(9686003)(66556008)(478600001)(966005)(71200400001);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?Y0hRalBDVCt2NTlHU3BFK1ArZ0NzMUtSNTFwUXdydmpzK1FSYmZGbHJSRER0?=
 =?utf-8?B?VHhjOUhjQUh6WTJMcGIra3BaWXpIb3JDOXJlenJiMTA5WEkzQmduRFV2SWh1?=
 =?utf-8?B?anFMbGxPcTVSWnJFWTlYU3QvUlpkaC9YLy85bXhub2c3cVdXa29CTUd0RUJP?=
 =?utf-8?B?MmVqV1cxUVdrYnZiSlIvVitKZnByYmUzcG92R0x4dmY3ampvYXNPK1dtK1g2?=
 =?utf-8?B?OVc4L1ZVcUVXMlVnZmwwR3NnU2RkU2RpVXVsWVdsaEJiRDltSkRmbnlPZXY3?=
 =?utf-8?B?SjdPQTlseHM5MVlSb0J0bng1OEVJbFZHNGdTSlJGcGpkRWsxNEU2TTJRUllr?=
 =?utf-8?B?TloxdkVTUGJ6aHRnN1FKMjA5bDZNQVpIaEEvb1IrQWVJVnRnbmZyeXphRXZJ?=
 =?utf-8?B?RThKTUMrT2NTZVRScU5IcHF0czA5QUkzdlByUjV6akRBaEN3a09ONUIwc2U1?=
 =?utf-8?B?UEY2eFJkc3htcHZSU1VwN3AzTTVyeEREMjk1djMydkprYkpxNnNFbzF4cjg0?=
 =?utf-8?B?R2pHMEtuR29Lb0Fma0crSU8vcG9TOGZvQWpjbm9uOHRwTkdVMjZXQUttbld5?=
 =?utf-8?B?elhuRzJxczZuOUpsQjRKL1YycGREcXUzcTN3STVYVmVoMjRjSzhJT1g1NzFn?=
 =?utf-8?B?c3VLajNEcnFJanhoQmNMdE5DZDJucXhQTWhDNDdMYXhocWs2R2VUbVIwWW05?=
 =?utf-8?B?b25hZERzTFp0NWY2dTNHakJMSWlnaWhsSXhpbFRHK1NHMXM5QkdBV1dpb1Ix?=
 =?utf-8?B?UkhLRUtKY0VjcDR5RFUxQUt4ZTNGVVRUNFhsUDhuTzcrZ2dOeVNsNXdNWnpB?=
 =?utf-8?B?NWFDOURVcE1oS3VGWHZLWmFjc1pDckJ5bzhHeStmN01lZ3lCK0F2Nm81dnMr?=
 =?utf-8?B?d0xjcTEyTzNCSjlweUFkbndhK3c4VWwxMDJBTTJPMC9HU2JLTDk4dGhEamJm?=
 =?utf-8?B?Y1UwckN0emZpNjQ1NWlLaHp4SlRoVWI2S0FmWkVYQXRuUHVaVFlQUTU4S1Nu?=
 =?utf-8?B?cG11UWR0M3pveHFZQ0x4SzNmbUFYQitqUzMyTlJheWZpZTNrSVc5emc4Z3U0?=
 =?utf-8?B?eitHM0huSEc1T3ZENlFBT2g1dENvNkxxMGtyM3BpeUtaRkhJZ0FRb3R4K1Vv?=
 =?utf-8?B?TEU2WEZOVFVjNThOcWFnSDJydGp2Skh3KzBneGo0MnBITTRERVVvQkdtYmRm?=
 =?utf-8?B?NU5KczAyZnZUWGlhVjVxQWVraVJxU0VCRTEwSWxtTE4rOVNDdyt0ajhXYUZ5?=
 =?utf-8?B?UENaN0dmR3o2L2tqYnMwcWIrdHJRTHVteHFWOE5JcTQ0d0MrYUtXL3dDdm5W?=
 =?utf-8?B?YjNtd3lUanNjMGg2S1FNTmxuUmV0b0hmS3lzdHFjMTlPSll2ajJOb0dINXRw?=
 =?utf-8?B?Z3I3SmxMQldmaS9YTENKU0V1V3FQaDZvY2EyUllCZTFIb05ZV2ZMQldnTERV?=
 =?utf-8?B?MXhGYllCY2RIQmlPTGJmdWpqY1JOd3ZXdk1Pc1VhVkhVZUErSzU0dFdacG9v?=
 =?utf-8?B?a1BlTzJRRmljVVhvRTZPa2ErUGhqS2ROekJMWUl0dXNCdlZsVzBTS09ONTJm?=
 =?utf-8?B?aGdLVXV4QWk4cGNTMyszeWhEclBHdFdwbDU1c1lYWExKb3FXY3lwR1M1S3hP?=
 =?utf-8?B?bXhUVExxRXhVYklHQnR0YlZGNjdSaGJSQWFLaUppNE80d1BhM1lUZFFWTml2?=
 =?utf-8?B?c1pvcklac1NBM2hwdC9BQXJhbno2K2xJcWpIYitNajFIbTRBU2lWWGpyMjBi?=
 =?utf-8?B?ME8wUkR2SWcrVkZNWEVDYndZZ205dXdSNTgra3NjZnAzQzlWbzlRd2dZTE5H?=
 =?utf-8?B?d25yZ0tEcU84QVQyTDVpdWllWEwwME9wcGJ2UE5CTDFDSmRaSTdzWVBBbEJa?=
 =?utf-8?B?eXZZQktLN0VlLzVLSFg5Wm5zT2FhVXdnbVVSZGZBVUdtSWpOUVp1OFpFbVlh?=
 =?utf-8?B?UVpRcWsycXZlemozMkV6cndacS9ZSE10S3FnT3JjcVJ3aTRpaDU0NXdjeHd3?=
 =?utf-8?B?TXNDZ3E0U1dMVGxHNHU4WkZIY0xMb1FlTXVRdWJveUdGM0UyMkVtUXJobm9T?=
 =?utf-8?B?TlJwaWlGMjIzdjVwRWtaYjdiTUFXYXVYVm5qSnlIc3d5SmM3b01RSS90MmJM?=
 =?utf-8?B?SlRlbVVxVjFuV2VPVHhJLzZmQ1lvckVtWnY3dWhrMzdaV3hPYzF2R3ZzMyt6?=
 =?utf-8?Q?vfANVP77E1Zefu0KnAGpb3vjTYozeYdGS0KfNoCv1n87?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9729.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ee69b6a-21d2-47f6-fe50-08da81f89b36
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2022 15:36:38.2135
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jJWweXoUmifA9MKDWCXB6rW6WVN8b2oMLkpRyUXmOPQOIm1/6l4dvFaJtbskQQDO0g2kRH+aihaSaX/q2dinPg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB5961
X-Rspamd-Queue-Id: 4M8Qpd3fGNz4PJw
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=qQ7maf9M;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=uoguelph.ca;
	spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.116.73 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca
X-Spamd-Result: default: False [-5.88 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.99)[-0.986];
	DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none];
	R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2];
	MIME_GOOD(-0.10)[text/plain];
	MIME_BASE64_TEXT(0.10)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_ALL(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[rmacklem];
	DKIM_TRACE(0.00)[uoguelph.ca:+];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.116.73:from]
X-ThisMailContainsUnwantedMimeParts: N

T24gMDgvMTgvMjAyMiA5OjQ5IGFtLCBMYXJyeSBSb3Nlbm1hbiB3cm90ZToKPiBJIGRpZG4ndCBn
ZXQgYWxsIG15IG1haWwgb24gbXkgYmFjdWxhIGJhY2t1cHMgdG9kYXkgKHRoZXkgYmFja3VwIHRv
Cj4gTkZTIG1vdW50ZWQgVHJ1ZU5BUykuCj4gQWxzbyBhIGRmIGhhbmdzLgo+Cj4gSGVyZSBhcmUg
cHJvY3N0YXQgLWtrJ3MgZm9yIGFsbDoKPiBsZXIgaW4g8J+MkCBib3JnIGluIH4gdmlhIEMgdjE0
LjAuNS1jbGFuZyBvbiDimIHvuI8gICh1cy1lYXN0LTEpCj4g4p2vIHBzIGF1eHh4d3d3fGdyZXAg
YmFjdWxhCj4gYmFjdWxhICAgICAgIDIwNjcgICAgMC4wICAwLjAgIDYzMTg4ICAxMzY1MiAgLSAg
SXMgICAxMTozMAo+IDA6MTcuNDkgL3Vzci9sb2NhbC9zYmluL2JhY3VsYS1zZCAtdSBiYWN1bGEg
LWcgYmFjdWxhIC12IC1jCj4gL3Vzci9sb2NhbC9ldGMvYmFjdWxhL2JhY3VsYS1zZC5jb25mCj4g
cm9vdCAgICAgICAgIDIwNzIgICAgMC4wICAwLjAgIDU5MjgwICAzMTI3NiAgLSAgSXMgICAxMToz
MAo+IDA6MDAuMzEgL3Vzci9sb2NhbC9zYmluL2JhY3VsYS1mZCAtdSByb290IC1nIHdoZWVsIC12
IC1jCj4gL3Vzci9sb2NhbC9ldGMvYmFjdWxhL2JhY3VsYS1mZC5jb25mCj4gYmFjdWxhICAgICAg
IDIwNzUgICAgMC4wICAwLjAgIDg2OTkyICAxOTM1MiAgLSAgSXMgICAxMTozMAo+IDA6NTYuOTUg
L3Vzci9sb2NhbC9zYmluL2JhY3VsYS1kaXIgLXUgYmFjdWxhIC1nIGJhY3VsYSAtdiAtYwo+IC91
c3IvbG9jYWwvZXRjL2JhY3VsYS9iYWN1bGEtZGlyLmNvbmYKPiBwb3N0Z3JlcyAgICA1MDI0MSAg
ICAwLjAgIDAuMSAyODU3NjQgMTYwMjQ0ICAtICBJcyAgIDIzOjA1Cj4gMDowMC4zOCBwb3N0Z3Jl
czogYmFjdWxhIGJhY3VsYSBbbG9jYWxdICAocG9zdGdyZXMpCj4gcG9zdGdyZXMgICAgNTAyNDQg
ICAgMC4wICAwLjEgMjk4Nzg0ICA3NDQ0OCAgLSAgRHMgICAyMzowNQo+IDA6MDAuNjcgcG9zdGdy
ZXM6IGJhY3VsYSBiYWN1bGEgW2xvY2FsXSAgKHBvc3RncmVzKQo+IGxlciAgICAgICAgIDY2NTk1
ICAgIDAuMCAgMC4wICAxMjg4OCAgIDI2MDAgIDMgIFMrICAgMDk6NDYKPiAwOjAwLjAwIGdyZXAg
LS1jb2xvcj1hdXRvIGJhY3VsYQo+CkF0IHRoZSBlbmQsIEknbGwgbGlzdCB3aGF0IG9wdGlvbnMg
YXJlIG5lZWRlZCBmb3IgcHMgYW5kIGFsbCBvZiBpdHMKb3V0cHV0IGlzIG5lZWRlZC4gU2VlIHRo
ZSBlbmQgb2YgdGhlIGVtYWlsLi4KCj4gbGVyIGluIPCfjJAgYm9yZyBpbiB+IHZpYSBDIHYxNC4w
LjUtY2xhbmcgb24g4piB77iPICAodXMtZWFzdC0xKQo+IOKdryBzdWRvIHByb2NzdGF0IC1rayAy
MDY3Cj4gICBQSUQgICAgVElEIENPTU0gICAgICAgICAgICAgICAgVEROQU1FICAgICAgICAgICAg
ICBLU1RBQ0sKPiAgMjA2NyAxMDA3NDIgYmFjdWxhLXNkICAgICAgICAgICAtICAgICAgICAgICAg
ICAgICAgIG1pX3N3aXRjaCsweDE1Nwo+IHNsZWVwcV9zd2l0Y2grMHgxMDcgc2xlZXBxX2NhdGNo
X3NpZ25hbHMrMHgyNjYgc2xlZXBxX3dhaXRfc2lnKzB4OQo+IF9jdl93YWl0X3NpZysweDEzNyBr
ZXJuX3NlbGVjdCsweDlmZSBzeXNfc2VsZWN0KzB4NTYKPiBhbWQ2NF9zeXNjYWxsKzB4MTJlIGZh
c3Rfc3lzY2FsbF9jb21tb24rMHhmOAo+ICAyMDY3IDEwMTAzNiBiYWN1bGEtc2QgICAgICAgICAg
IC0gICAgICAgICAgICAgICAgICAgbWlfc3dpdGNoKzB4MTU3Cj4gc2xlZXBxX3N3aXRjaCsweDEw
NyBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDI2Ngo+IHNsZWVwcV90aW1lZHdhaXRfc2lnKzB4MTIg
X3NsZWVwKzB4MjdkIHVtdHhxX3NsZWVwKzB4MjQyIGRvX3dhaXQrMHgyNmIKPiBfX3VtdHhfb3Bf
d2FpdF91aW50X3ByaXZhdGUrMHg1NCBzeXNfX3VtdHhfb3ArMHg3ZSBhbWQ2NF9zeXNjYWxsKzB4
MTJlCj4gZmFzdF9zeXNjYWxsX2NvbW1vbisweGY4Cj4gIDIwNjcgMTAxMDM4IGJhY3VsYS1zZCAg
ICAgICAgICAgLSAgICAgICAgICAgICAgICAgICBtaV9zd2l0Y2grMHgxNTcKPiBzbGVlcHFfc3dp
dGNoKzB4MTA3IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MjY2Cj4gc2xlZXBxX3RpbWVkd2FpdF9z
aWcrMHgxMiBfc2xlZXArMHgyN2QgdW10eHFfc2xlZXArMHgyNDIgZG9fd2FpdCsweDI2Ygo+IF9f
dW10eF9vcF93YWl0X3VpbnRfcHJpdmF0ZSsweDU0IHN5c19fdW10eF9vcCsweDdlIGFtZDY0X3N5
c2NhbGwrMHgxMmUKPiBmYXN0X3N5c2NhbGxfY29tbW9uKzB4ZjgKPiAgMjA2NyAxMjQ0ODUgYmFj
dWxhLXNkICAgICAgICAgICAtICAgICAgICAgICAgICAgICAgIG1pX3N3aXRjaCsweDE1Nwo+IHNs
ZWVwcV9zd2l0Y2grMHgxMDcgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgyNjYKPiBzbGVlcHFfdGlt
ZWR3YWl0X3NpZysweDEyIF9jdl90aW1lZHdhaXRfc2lnX3NidCsweDE1Ywo+IGtlcm5fcG9sbF9r
ZmRzKzB4NDU3IGtlcm5fcG9sbCsweDlmIHN5c19wb2xsKzB4NTAgYW1kNjRfc3lzY2FsbCsweDEy
ZQo+IGZhc3Rfc3lzY2FsbF9jb21tb24rMHhmOAo+Cj4gbGVyIGluIPCfjJAgYm9yZyBpbiB+IHZp
YSBDIHYxNC4wLjUtY2xhbmcgb24g4piB77iPICAodXMtZWFzdC0xKQo+IOKdryBzdWRvIHByb2Nz
dGF0IC1rayAyMDcyCj4gICBQSUQgICAgVElEIENPTU0gICAgICAgICAgICAgICAgVEROQU1FICAg
ICAgICAgICAgICBLU1RBQ0sKPiAgMjA3MiAxMDA2NzcgYmFjdWxhLWZkICAgICAgICAgICAtICAg
ICAgICAgICAgICAgICAgIG1pX3N3aXRjaCsweDE1Nwo+IHNsZWVwcV9zd2l0Y2grMHgxMDcgc2xl
ZXBxX2NhdGNoX3NpZ25hbHMrMHgyNjYgc2xlZXBxX3dhaXRfc2lnKzB4OQo+IF9jdl93YWl0X3Np
ZysweDEzNyBrZXJuX3NlbGVjdCsweDlmZSBzeXNfc2VsZWN0KzB4NTYKPiBhbWQ2NF9zeXNjYWxs
KzB4MTJlIGZhc3Rfc3lzY2FsbF9jb21tb24rMHhmOAo+ICAyMDcyIDEwMTAzOSBiYWN1bGEtZmQg
ICAgICAgICAgIC0gICAgICAgICAgICAgICAgICAgbWlfc3dpdGNoKzB4MTU3Cj4gc2xlZXBxX3N3
aXRjaCsweDEwNyBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDI2Ngo+IHNsZWVwcV90aW1lZHdhaXRf
c2lnKzB4MTIgX3NsZWVwKzB4MjdkIHVtdHhxX3NsZWVwKzB4MjQyIGRvX3dhaXQrMHgyNmIKPiBf
X3VtdHhfb3Bfd2FpdF91aW50X3ByaXZhdGUrMHg1NCBzeXNfX3VtdHhfb3ArMHg3ZSBhbWQ2NF9z
eXNjYWxsKzB4MTJlCj4gZmFzdF9zeXNjYWxsX2NvbW1vbisweGY4Cj4gIDIwNzIgMTAxMDQwIGJh
Y3VsYS1mZCAgICAgICAgICAgLSAgICAgICAgICAgICAgICAgICBtaV9zd2l0Y2grMHgxNTcKPiBz
bGVlcHFfc3dpdGNoKzB4MTA3IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MjY2Cj4gc2xlZXBxX3Rp
bWVkd2FpdF9zaWcrMHgxMiBfc2xlZXArMHgyN2QgdW10eHFfc2xlZXArMHgyNDIgZG9fd2FpdCsw
eDI2Ygo+IF9fdW10eF9vcF93YWl0X3VpbnRfcHJpdmF0ZSsweDU0IHN5c19fdW10eF9vcCsweDdl
IGFtZDY0X3N5c2NhbGwrMHgxMmUKPiBmYXN0X3N5c2NhbGxfY29tbW9uKzB4ZjgKPiAgMjA3MiAx
MjQ0OTAgYmFjdWxhLWZkICAgICAgICAgICAtICAgICAgICAgICAgICAgICAgIG1pX3N3aXRjaCsw
eDE1Nwo+IHNsZWVwcV9zd2l0Y2grMHgxMDcgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgyNjYKPiBz
bGVlcHFfdGltZWR3YWl0X3NpZysweDEyIF9jdl90aW1lZHdhaXRfc2lnX3NidCsweDE1Ywo+IGtl
cm5fcG9sbF9rZmRzKzB4NDU3IGtlcm5fcG9sbCsweDlmIHN5c19wb2xsKzB4NTAgYW1kNjRfc3lz
Y2FsbCsweDEyZQo+IGZhc3Rfc3lzY2FsbF9jb21tb24rMHhmOAo+Cj4gbGVyIGluIPCfjJAgYm9y
ZyBpbiB+IHZpYSBDIHYxNC4wLjUtY2xhbmcgb24g4piB77iPICAodXMtZWFzdC0xKQo+IOKdryBz
dWRvIHByb2NzdGF0IC1rayAyMDc1Cj4gICBQSUQgICAgVElEIENPTU0gICAgICAgICAgICAgICAg
VEROQU1FICAgICAgICAgICAgICBLU1RBQ0sKPiAgMjA3NSAxMDEwMDcgYmFjdWxhLWRpciAgICAg
ICAgICAtICAgICAgICAgICAgICAgICAgIG1pX3N3aXRjaCsweDE1Nwo+IHNsZWVwcV9zd2l0Y2gr
MHgxMDcgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgyNjYgc2xlZXBxX3dhaXRfc2lnKzB4OQo+IF9z
bGVlcCsweDI5YiB1bXR4cV9zbGVlcCsweDI0MiBkb193YWl0KzB4MjZiIF9fdW10eF9vcF93YWl0
KzB4NTMKPiBzeXNfX3VtdHhfb3ArMHg3ZSBhbWQ2NF9zeXNjYWxsKzB4MTJlIGZhc3Rfc3lzY2Fs
bF9jb21tb24rMHhmOAo+ICAyMDc1IDEwMTA0MSBiYWN1bGEtZGlyICAgICAgICAgIC0gICAgICAg
ICAgICAgICAgICAgbWlfc3dpdGNoKzB4MTU3Cj4gc2xlZXBxX3N3aXRjaCsweDEwNyBzbGVlcHFf
Y2F0Y2hfc2lnbmFscysweDI2Ngo+IHNsZWVwcV90aW1lZHdhaXRfc2lnKzB4MTIgX3NsZWVwKzB4
MjdkIHVtdHhxX3NsZWVwKzB4MjQyIGRvX3dhaXQrMHgyNmIKPiBfX3VtdHhfb3Bfd2FpdF91aW50
X3ByaXZhdGUrMHg1NCBzeXNfX3VtdHhfb3ArMHg3ZSBhbWQ2NF9zeXNjYWxsKzB4MTJlCj4gZmFz
dF9zeXNjYWxsX2NvbW1vbisweGY4Cj4gIDIwNzUgMTAxMDQ1IGJhY3VsYS1kaXIgICAgICAgICAg
LSAgICAgICAgICAgICAgICAgICBtaV9zd2l0Y2grMHgxNTcKPiBzbGVlcHFfc3dpdGNoKzB4MTA3
IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MjY2IHNsZWVwcV93YWl0X3NpZysweDkKPiBfY3Zfd2Fp
dF9zaWcrMHgxMzcga2Vybl9zZWxlY3QrMHg5ZmUgc3lzX3NlbGVjdCsweDU2Cj4gYW1kNjRfc3lz
Y2FsbCsweDEyZSBmYXN0X3N5c2NhbGxfY29tbW9uKzB4ZjgKPiAgMjA3NSAxMDEwNDYgYmFjdWxh
LWRpciAgICAgICAgICAtICAgICAgICAgICAgICAgICAgIG1pX3N3aXRjaCsweDE1Nwo+IHNsZWVw
cV9zd2l0Y2grMHgxMDcgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgyNjYKPiBzbGVlcHFfdGltZWR3
YWl0X3NpZysweDEyIF9zbGVlcCsweDI3ZCB1bXR4cV9zbGVlcCsweDI0MiBkb193YWl0KzB4MjZi
Cj4gX191bXR4X29wX3dhaXRfdWludF9wcml2YXRlKzB4NTQgc3lzX191bXR4X29wKzB4N2UgYW1k
NjRfc3lzY2FsbCsweDEyZQo+IGZhc3Rfc3lzY2FsbF9jb21tb24rMHhmOAo+ICAyMDc1IDEwMTA0
NyBiYWN1bGEtZGlyICAgICAgICAgIC0gICAgICAgICAgICAgICAgICAgbWlfc3dpdGNoKzB4MTU3
Cj4gc2xlZXBxX3N3aXRjaCsweDEwNyBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDI2Ngo+IHNsZWVw
cV90aW1lZHdhaXRfc2lnKzB4MTIgX3NsZWVwKzB4MjdkIGtlcm5fY2xvY2tfbmFub3NsZWVwKzB4
MWQxCj4gc3lzX25hbm9zbGVlcCsweDNiIGFtZDY0X3N5c2NhbGwrMHgxMmUgZmFzdF9zeXNjYWxs
X2NvbW1vbisweGY4Cj4gIDIwNzUgMTI0NDc5IGJhY3VsYS1kaXIgICAgICAgICAgLSAgICAgICAg
ICAgICAgICAgICBtaV9zd2l0Y2grMHgxNTcKPiBzbGVlcHFfc3dpdGNoKzB4MTA3IHNsZWVwcV9j
YXRjaF9zaWduYWxzKzB4MjY2IHNsZWVwcV93YWl0X3NpZysweDkKPiBfY3Zfd2FpdF9zaWcrMHgx
Mzcga2Vybl9wb2xsX2tmZHMrMHg0OGMga2Vybl9wb2xsKzB4OWYgc3lzX3BvbGwrMHg1MAo+IGFt
ZDY0X3N5c2NhbGwrMHgxMmUgZmFzdF9zeXNjYWxsX2NvbW1vbisweGY4Cj4gIDIwNzUgMTI0NDgw
IGJhY3VsYS1kaXIgICAgICAgICAgLSAgICAgICAgICAgICAgICAgICBtaV9zd2l0Y2grMHgxNTcK
PiBzbGVlcHFfc3dpdGNoKzB4MTA3IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MjY2Cj4gc2xlZXBx
X3RpbWVkd2FpdF9zaWcrMHgxMiBfc2xlZXArMHgyN2Qga2Vybl9jbG9ja19uYW5vc2xlZXArMHgx
ZDEKPiBzeXNfbmFub3NsZWVwKzB4M2IgYW1kNjRfc3lzY2FsbCsweDEyZSBmYXN0X3N5c2NhbGxf
Y29tbW9uKzB4ZjgKPiAgMjA3NSAxMjQ0ODEgYmFjdWxhLWRpciAgICAgICAgICAtICAgICAgICAg
ICAgICAgICAgIG1pX3N3aXRjaCsweDE1Nwo+IHNsZWVwcV9zd2l0Y2grMHgxMDcgc2xlZXBxX2Nh
dGNoX3NpZ25hbHMrMHgyNjYKPiBzbGVlcHFfdGltZWR3YWl0X3NpZysweDEyIF9zbGVlcCsweDI3
ZCBrZXJuX2Nsb2NrX25hbm9zbGVlcCsweDFkMQo+IHN5c19uYW5vc2xlZXArMHgzYiBhbWQ2NF9z
eXNjYWxsKzB4MTJlIGZhc3Rfc3lzY2FsbF9jb21tb24rMHhmOAo+ICAyMDc1IDEyNDQ4OSBiYWN1
bGEtZGlyICAgICAgICAgIC0gICAgICAgICAgICAgICAgICAgbWlfc3dpdGNoKzB4MTU3Cj4gc2xl
ZXBxX3N3aXRjaCsweDEwNyBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDI2Ngo+IHNsZWVwcV90aW1l
ZHdhaXRfc2lnKzB4MTIgX2N2X3RpbWVkd2FpdF9zaWdfc2J0KzB4MTVjCj4ga2Vybl9wb2xsX2tm
ZHMrMHg0NTcga2Vybl9wb2xsKzB4OWYgc3lzX3BvbGwrMHg1MCBhbWQ2NF9zeXNjYWxsKzB4MTJl
Cj4gZmFzdF9zeXNjYWxsX2NvbW1vbisweGY4Cj4gIDIwNzUgMTI0NTA2IGJhY3VsYS1kaXIgICAg
ICAgICAgLSAgICAgICAgICAgICAgICAgICBtaV9zd2l0Y2grMHgxNTcKPiBzbGVlcHFfc3dpdGNo
KzB4MTA3IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MjY2Cj4gc2xlZXBxX3RpbWVkd2FpdF9zaWcr
MHgxMiBfc2xlZXArMHgyN2Qga2Vybl9jbG9ja19uYW5vc2xlZXArMHgxZDEKPiBzeXNfbmFub3Ns
ZWVwKzB4M2IgYW1kNjRfc3lzY2FsbCsweDEyZSBmYXN0X3N5c2NhbGxfY29tbW9uKzB4ZjgKPgo+
IGxlciBpbiDwn4yQIGJvcmcgaW4gfiB2aWEgQyB2MTQuMC41LWNsYW5nIG9uIOKYge+4jyAgKHVz
LWVhc3QtMSkKPiDina8gc3VkbyBwcm9jc3RhdCAta2sgNjYzOTAKPiAgIFBJRCAgICBUSUQgQ09N
TSAgICAgICAgICAgICAgICBURE5BTUUgICAgICAgICAgICAgIEtTVEFDSwo+IDY2MzkwIDEwMTUx
NCBkZiAgICAgICAgICAgICAgICAgIC0gICAgICAgICAgICAgICAgICAgbWlfc3dpdGNoKzB4MTU3
Cj4gc2xlZXBxX3N3aXRjaCsweDEwNyBzbGVlcHFfdGltZWR3YWl0KzB4NGIgX3NsZWVwKzB4Mjhl
Cj4gY2xudF9yZWNvbm5lY3RfY2FsbCsweDgwOSBuZXduZnNfcmVxdWVzdCsweGE5NSBuZnNjbF9y
ZXF1ZXN0KzB4NWEKPiBuZnNycGNfc3RhdGZzKzB4MTlkIG5mc19zdGF0ZnMrMHgxNDggdmZzX3N0
YXRmc19zaWdkZWZlcisweDJlCj4ga2Vybl9nZXRmc3N0YXQrMHgxZjEgc3lzX2dldGZzc3RhdCsw
eDIyIGFtZDY0X3N5c2NhbGwrMHgxMmUKPiBmYXN0X3N5c2NhbGxfY29tbW9uKzB4ZjgKPgpUaGlz
IHNheXMgdGhhdCB0aGUga2VybmVsIFJQQyBpcyB0cnlpbmcgdG8gZXN0YWJsaXNoIGEgbmV3IFRD
UCBjb25uZWN0aW9uCnRvIHRoZSBzZXJ2ZXIuIE5vdyB3aHkgdGhlIG9sZCBjb25uZWN0aW9uIHN0
b3BwZWQgd29ya2luZwood2hpY2ggc2hvdWxkIG9ubHkgaGFwcGVuIGlmIHRoZXJlIGlzIGEgbmV0
d29yayBwYXJ0aXRpb25pbmcgb3IKY2xpZW50L3NlcnZlciBjcmFzaCksIHdlIGRvIG5vdCBrbm93
LCBmcm9tIHRoZSBsaW1pdGVkIGluZm8uCgo+IGxlciBpbiDwn4yQIGJvcmcgaW4gfiB2aWEgQyB2
MTQuMC41LWNsYW5nIG9uIOKYge+4jyAgKHVzLWVhc3QtMSkKPiDina8KPgo+IHRoaXMgd2FzIGJ1
aWx0IHllc3RlcmRheToKPiDina8gdW5hbWUgLWEKPiBGcmVlQlNEIGJvcmcubGVyY3RyLm9yZyAx
NC4wLUNVUlJFTlQgRnJlZUJTRCAxNC4wLUNVUlJFTlQgIzE0Mgo+IGxlci9mcmVlYnNkLW1haW4t
Y2hhbmdlcy1uMjU3NDUzLTE3NWExMjdhNzJmOiBXZWQgQXVnIDE3IDA5OjIzOjMyIENEVAo+IDIw
MjIKPiByb290QGJvcmcubGVyY3RyLm9yZzovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3N5
cy9MRVItTUlOSU1BTAo+IGFtZDY0Cj4KPiBsZXIgaW4g8J+MkCBib3JnIGluIH4gdmlhIEMgdjE0
LjAuNS1jbGFuZyBvbiDimIHvuI8gICh1cy1lYXN0LTEpCj4g4p2vCj4KPiBXaGF0IGVsc2UgZG8g
d2UgbmVlZD8KVHlwaWNhbGx5LCB0aGUgb3V0cHV0IG9mIHRoZSBmb2xsb3dpbmcgY29tbWFuZHMg
KGFsbCBvZiBpdCwgbm90IGp1c3Qgc29tZQpwcm9jZXNzZXMvdGhyZWFkcykgY2FuIGJlIHVzZWZ1
bDoKCnBzIGF4SGx3Ci0gVGhlIE1XQ0hBTiBmaWVsZCBpcyBieSBmYXIgdGhlIG1vc3QgdXNlZnVs
LCBzaW5jZSBpdCBpbmRpY2F0ZXMgd2hlcmUKICAgdGhlIHByb2Nlc3MvdGhyZWFkIGlzIHNsZWVw
aW5nLiAiSCIgbWF0dGVycyBzaW5jZSB0aGVyZSBhcmUgbmZzaW9kIHRocmVhZHMKICAgdGhhdCBk
byBhc3luY2hyb25vdXMgSS9PIGZvciByZWFkYWhlYWRzL3dyaXRlYmVoaW5kcyBhbmQga25vd2lu
ZyB3aGF0CiAgIHRoZXkgYXJlIHVwIHRvIGNhbiBiZSB1c2VmdWwuCgpuZXRzdGF0IC1hCi0gVG8g
c2VlIHdoYXQgc3RhdGUgdGhlIFRDUCBjb25uZWN0aW9uKHMpIGJlaW5nIHVzZWQgYnkgdGhlIG1v
dW50IGFyZSB1cCB0by4KICAgKFNpbmNlIGl0IHdhcyB0cnlpbmcgdG8gZG8gYSBuZXcgY29ubmVj
dGlvbiwgdGhpcyBvbmUgbWlnaHQgaGF2ZSBiZWVuIHVzZWZ1bC4pCgpuZnNzdGF0IC1tCi0gVG8g
c2hvdyBleGFjdGx5IHdoYXQgTkZTIG1vdW50IG9wdGlvbnMgYXJlIGJlaW5nIHVzZWQuCi0tPiBG
b3IgZXhhbXBsZSwgdXNlIG9mICJpbnRyIiBhbmQvb3IgInNvZnQiIGZvciBhbiBORlN2NCBtb3Vu
dCBpcwogICAgICBndWFyYW50ZWVkIHRvIGJyZWFrIGl0LiAoU2VlIEJVR1Mgc2VjdGlvbiBvZiAi
bWFuIG1vdW50X25mcyIuKQoKdm1zdGF0IC1tCnZtc3RhdCAtegotIFRvIHNlZSB3aGF0IGtlcm5l
bCBtZW1vcnkgYWxsb2NhdGlvbnMgbG9vayBsaWtlLiAoQmFzaWNhbGx5IGxvb2tpbmcgZm9yCiAg
YSB2ZXJ5IGxhcmdlIGFsbG9jYXRpb24gdGhhdCBtaWdodCBpbmRpY2F0ZSBhIGxlYWsgb3IgcmVz
b3VyY2UgZXhoYXVzdGlvbi4pCgpwcm9jc3RhdCAta2sKLSBUbyBiZSBob25lc3QsIGZvciBtZSwg
dGhpcyBkb2VzIG5vdCB1c3VhbGx5IGdpdmUgbWUgYW55IHVzZWZ1bCBpbmZvcm1hdGlvbgogICBj
b21wYXJlZCB3aXRoICJwcyIsIGJ1dCBpdCBtaWdodCBiZSB1c2VmdWwuCgpUaGUgcmVzdCByZXF1
aXJlIGdvaW5nIGludG8gdGhlIGRlYnVnZ2VyIChpZiBjb21waWxlZCBpbnRvIHlvdXIga2VybmVs
KS4Kc3lzY3RsIGRlYnVnLmtkYi5lbnRlcj0xCi0gdHlwZSA8Y3RybD48YWx0Pjxlc2NhcGU+CnRo
ZW4gaW4gdGhlIGRlYnVnZ2VyLCBkbyAic2hvdyBhbGxsb2NrcyIgYW5kIHRoZSBvdGhlciBjb21t
YW5kcwpsaXN0ZWQgaGVyZToKaHR0cHM6Ly9kb2NzLmZyZWVic2Qub3JnL2RvYy82LjQtUkVMRUFT
RS91c3Ivc2hhcmUvZG9jL2VuL2Jvb2tzL2RldmVsb3BlcnMtaGFuZGJvb2sva2VybmVsZGVidWct
ZGVhZGxvY2tzLmh0bWwKCllvdSBjYW4gdHlwZSAiY29udGludWUiIHRvIGdldCBvdXQgb2YgdGhl
IGRlYnVnZ2VyLgoKU2luY2UgaXQgd2FzIHRyeWluZyB0byBlc3RhYmxpc2ggYSBuZXcgVENQIGNv
bm5lY3Rpb24sIGFsbCBJIGNhbiBzYXkgaXMgdGhhdApzb21ldGhpbmcgYnJva2UgdGhlIG9sZCBU
Q1AgY29ubmVjdGlvbiBhbmQgdGhhdCBjb3VsZCBzdWdnZXN0IGEKcHJvYmxlbSB3aXRoIHlvdXIg
bmV0d29yayBmYWJyaWMsIHN1Y2ggYXMgYSBicm9rZW4gVFNPIGltcGxlbWVudGF0aW9uLgooTkZT
IHRyYWZmaWMgaXMgcmVhbGx5IGdvb2QgYXQgZ2VuZXJhdGluZyB3ZWlyZCBzaXplcyBvZiBUU08g
c2VnbWVudHMgdGhhdCwKIGluIHR1cm4sIGFyZSB2ZXJ5IGdvb2QgYXQgZmluZGluZyBmbGF3cyBp
biBUU08gaW1wbGVtZW50YXRpb25zIHRoYXQgb3RoZXIKIFRDUCB0cmFmZmljIG5ldmVyIGZpbmRz
LikKCnJpY2sKCgo=

From nobody Fri Aug 19 15:38:48 2022
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 4M8Qs56JZCz4ZQV1
	for ; Fri, 19 Aug 2022 15:38:49 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M8Qs50rt8z4QZY;
	Fri, 19 Aug 2022 15:38:49 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=WM5EO4PrJHRAJwJzOEBl/KxZeka6xiy+op2jkB2Up44=; b=PTmWMEYomkOp0IYLo0IQDIUMlN
	K6Cvy4VScEEANsGpQh7wtr1JUtdzMauDiDkmBEmJ/uBeUKIg10V5crT+fYro+rQ0DGudRwyXQDAo4
	7bC5BD37VWOPXXgaKp7E8vYl7MfV1fq6hQSce2l1Spa35Geh274CB5ZIBRNwqGh/v0pWHkaY8/8td
	eYkApU8uzxZ0Ksi/ExCe1lAeIUkCs+qvwkHJbHBlnkeSxX0ezXqPuVLWEDZa2XimPNqoIbWoXVKWm
	M/nYROzOVOg2Fa3eU6bsVEjTgbW7KD0+ChV3ODVpphGe7ex2Q72H7EvsggOfUHKusHB0ay3y/PMb7
	8eivwuiw==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:36696 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oP45A-000Fda-ET;
	Fri, 19 Aug 2022 10:38:48 -0500
Received: from 2600:1700:210:b18f:55e0:4474:655b:795
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Fri, 19 Aug 2022 10:38:48 -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
Date: Fri, 19 Aug 2022 10:38:48 -0500
From: Larry Rosenman 
To: Rick Macklem 
Cc: Freebsd current , Mark Johnston
 
Subject: Re: Hangs in bacula / NFS? on recent Current
In-Reply-To: 
References: <405b3873b709d42feb438b5b954ecdc2@lerctr.org>
 <9e63f40233fc29c9fbc3fac0cb82acd5@lerctr.org>
 
Message-ID: <3325241f6237fe70129bac18c0938f66@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4M8Qs50rt8z4QZY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=PTmWMEYo;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_SPF_ALLOW(-0.20)[+mx:c];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On 08/19/2022 10:36 am, Rick Macklem wrote:
> On 08/18/2022 9:49 am, Larry Rosenman wrote:
>> I didn't get all my mail on my bacula backups today (they backup to
>> NFS mounted TrueNAS).
>> Also a df hangs.
>> 
>> Here are procstat -kk's for all:
>> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
>> ⯠ps auxxxwww|grep bacula
>> bacula       2067    0.0  0.0  63188  13652  -  Is   11:30
>> 0:17.49 /usr/local/sbin/bacula-sd -u bacula -g bacula -v -c
>> /usr/local/etc/bacula/bacula-sd.conf
>> root         2072    0.0  0.0  59280  31276  -  Is   11:30
>> 0:00.31 /usr/local/sbin/bacula-fd -u root -g wheel -v -c
>> /usr/local/etc/bacula/bacula-fd.conf
>> bacula       2075    0.0  0.0  86992  19352  -  Is   11:30
>> 0:56.95 /usr/local/sbin/bacula-dir -u bacula -g bacula -v -c
>> /usr/local/etc/bacula/bacula-dir.conf
>> postgres    50241    0.0  0.1 285764 160244  -  Is   23:05
>> 0:00.38 postgres: bacula bacula [local]  (postgres)
>> postgres    50244    0.0  0.1 298784  74448  -  Ds   23:05
>> 0:00.67 postgres: bacula bacula [local]  (postgres)
>> ler         66595    0.0  0.0  12888   2600  3  S+   09:46
>> 0:00.00 grep --color=auto bacula
>> 
> At the end, I'll list what options are needed for ps and all of its
> output is needed. See the end of the email..
> 
>> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
>> ⯠sudo procstat -kk 2067
>>   PID    TID COMM                TDNAME              KSTACK
>>  2067 100742 bacula-sd           -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9
>> _cv_wait_sig+0x137 kern_select+0x9fe sys_select+0x56
>> amd64_syscall+0x12e fast_syscall_common+0xf8
>>  2067 101036 bacula-sd           -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
>> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
>> fast_syscall_common+0xf8
>>  2067 101038 bacula-sd           -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
>> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
>> fast_syscall_common+0xf8
>>  2067 124485 bacula-sd           -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _cv_timedwait_sig_sbt+0x15c
>> kern_poll_kfds+0x457 kern_poll+0x9f sys_poll+0x50 amd64_syscall+0x12e
>> fast_syscall_common+0xf8
>> 
>> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
>> ⯠sudo procstat -kk 2072
>>   PID    TID COMM                TDNAME              KSTACK
>>  2072 100677 bacula-fd           -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9
>> _cv_wait_sig+0x137 kern_select+0x9fe sys_select+0x56
>> amd64_syscall+0x12e fast_syscall_common+0xf8
>>  2072 101039 bacula-fd           -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
>> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
>> fast_syscall_common+0xf8
>>  2072 101040 bacula-fd           -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
>> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
>> fast_syscall_common+0xf8
>>  2072 124490 bacula-fd           -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _cv_timedwait_sig_sbt+0x15c
>> kern_poll_kfds+0x457 kern_poll+0x9f sys_poll+0x50 amd64_syscall+0x12e
>> fast_syscall_common+0xf8
>> 
>> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
>> ⯠sudo procstat -kk 2075
>>   PID    TID COMM                TDNAME              KSTACK
>>  2075 101007 bacula-dir          -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9
>> _sleep+0x29b umtxq_sleep+0x242 do_wait+0x26b __umtx_op_wait+0x53
>> sys__umtx_op+0x7e amd64_syscall+0x12e fast_syscall_common+0xf8
>>  2075 101041 bacula-dir          -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
>> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
>> fast_syscall_common+0xf8
>>  2075 101045 bacula-dir          -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9
>> _cv_wait_sig+0x137 kern_select+0x9fe sys_select+0x56
>> amd64_syscall+0x12e fast_syscall_common+0xf8
>>  2075 101046 bacula-dir          -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _sleep+0x27d umtxq_sleep+0x242 do_wait+0x26b
>> __umtx_op_wait_uint_private+0x54 sys__umtx_op+0x7e amd64_syscall+0x12e
>> fast_syscall_common+0xf8
>>  2075 101047 bacula-dir          -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _sleep+0x27d kern_clock_nanosleep+0x1d1
>> sys_nanosleep+0x3b amd64_syscall+0x12e fast_syscall_common+0xf8
>>  2075 124479 bacula-dir          -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9
>> _cv_wait_sig+0x137 kern_poll_kfds+0x48c kern_poll+0x9f sys_poll+0x50
>> amd64_syscall+0x12e fast_syscall_common+0xf8
>>  2075 124480 bacula-dir          -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _sleep+0x27d kern_clock_nanosleep+0x1d1
>> sys_nanosleep+0x3b amd64_syscall+0x12e fast_syscall_common+0xf8
>>  2075 124481 bacula-dir          -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _sleep+0x27d kern_clock_nanosleep+0x1d1
>> sys_nanosleep+0x3b amd64_syscall+0x12e fast_syscall_common+0xf8
>>  2075 124489 bacula-dir          -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _cv_timedwait_sig_sbt+0x15c
>> kern_poll_kfds+0x457 kern_poll+0x9f sys_poll+0x50 amd64_syscall+0x12e
>> fast_syscall_common+0xf8
>>  2075 124506 bacula-dir          -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_catch_signals+0x266
>> sleepq_timedwait_sig+0x12 _sleep+0x27d kern_clock_nanosleep+0x1d1
>> sys_nanosleep+0x3b amd64_syscall+0x12e fast_syscall_common+0xf8
>> 
>> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
>> ⯠sudo procstat -kk 66390
>>   PID    TID COMM                TDNAME              KSTACK
>> 66390 101514 df                  -                   mi_switch+0x157
>> sleepq_switch+0x107 sleepq_timedwait+0x4b _sleep+0x28e
>> clnt_reconnect_call+0x809 newnfs_request+0xa95 nfscl_request+0x5a
>> nfsrpc_statfs+0x19d nfs_statfs+0x148 vfs_statfs_sigdefer+0x2e
>> kern_getfsstat+0x1f1 sys_getfsstat+0x22 amd64_syscall+0x12e
>> fast_syscall_common+0xf8
>> 
> This says that the kernel RPC is trying to establish a new TCP 
> connection
> to the server. Now why the old connection stopped working
> (which should only happen if there is a network partitioning or
> client/server crash), we do not know, from the limited info.
> 
>> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
>> â¯
>> 
>> this was built yesterday:
>> ⯠uname -a
>> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #142
>> ler/freebsd-main-changes-n257453-175a127a72f: Wed Aug 17 09:23:32 CDT
>> 2022
>> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
>> amd64
>> 
>> ler in 🌠borg in ~ via C v14.0.5-clang on â˜ï¸  (us-east-1)
>> â¯
>> 
>> What else do we need?
> Typically, the output of the following commands (all of it, not just 
> some
> processes/threads) can be useful:
> 
> ps axHlw
> - The MWCHAN field is by far the most useful, since it indicates where
>    the process/thread is sleeping. "H" matters since there are nfsiod 
> threads
>    that do asynchronous I/O for readaheads/writebehinds and knowing 
> what
>    they are up to can be useful.
> 
> netstat -a
> - To see what state the TCP connection(s) being used by the mount are 
> up to.
>    (Since it was trying to do a new connection, this one might have
> been useful.)
> 
> nfsstat -m
> - To show exactly what NFS mount options are being used.
> --> For example, use of "intr" and/or "soft" for an NFSv4 mount is
>       guaranteed to break it. (See BUGS section of "man mount_nfs".)
> 
> vmstat -m
> vmstat -z
> - To see what kernel memory allocations look like. (Basically looking 
> for
>   a very large allocation that might indicate a leak or resource 
> exhaustion.)
> 
> procstat -kk
> - To be honest, for me, this does not usually give me any useful 
> information
>    compared with "ps", but it might be useful.
> 
> The rest require going into the debugger (if compiled into your 
> kernel).
> sysctl debug.kdb.enter=1
> - type 
> then in the debugger, do "show alllocks" and the other commands
> listed here:
> https://docs.freebsd.org/doc/6.4-RELEASE/usr/share/doc/en/books/developers-handbook/kerneldebug-deadlocks.html
> 
> You can type "continue" to get out of the debugger.
> 
> Since it was trying to establish a new TCP connection, all I can say is 
> that
> something broke the old TCP connection and that could suggest a
> problem with your network fabric, such as a broken TSO implementation.
> (NFS traffic is really good at generating weird sizes of TSO segments 
> that,
>  in turn, are very good at finding flaws in TSO implementations that 
> other
>  TCP traffic never finds.)
> 
> rick


MarkJ pointed out there was a kernel bug that I was probably hitting, 
upgrading past that point fixed it.

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Fri Aug 19 18:42:36 2022
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 4M8VxN2PL2z4YqNf
	for ; Fri, 19 Aug 2022 18:42:48 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M8VxN2Dcrz3TKT
	for ; Fri, 19 Aug 2022 18:42:48 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660934568;
	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=LbP3uWf4FMKipOWXh2YpyvHBTsLRGDpaBQ+B3akju+I=;
	b=h3oCeM/U+CjFWq6E1GxDuaKPMTDAUPx2wx+yjvca1T88xIX/fMrHGnF25hV2N4Jq+B+Lb9
	/YkSf0d2wn/SfUVjTB4YgGNa/9gWaQQpY9c/uozRfphhhCPKDBKxD51EYUC0ZmDXGnF6uV
	D+/xzr3S9vmDe9O9O83/5CZ039qKGffYxTCRdWNfDyulmPIi1R02UE2fOy48D/McmU0UMW
	tf2GtMdoQdSgrNNOtRnUqYR2Fvhr/frEu2ZVip3scohYmCDI8EP8CV8EyoO+IJBf/WryCt
	f35/g76cZ7eO9tl+wzOBDVhC7jlDRFWqhWLsCTustF0Ot9A0ChEZjvackdYQ4Q==
Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M8VxN17mpz1J9s
	for ; Fri, 19 Aug 2022 18:42:48 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-ua1-f45.google.com with SMTP id s5so2109362uar.1
        for ; Fri, 19 Aug 2022 11:42:48 -0700 (PDT)
X-Gm-Message-State: ACgBeo18nqUXijw1mJI71MdGM5LCxg3TlDArJ+i/SLn9ZIlNuyinT87J
	tPDtWzki+hBrLh1O4FrvBP8BHEjBjhZqxG1RSlk=
X-Google-Smtp-Source: AA6agR7CLJKZ1OYPlRh45OzexEU8zA2XwRUylFyTzbprR3VjmrZUZ2aLSyhxSYtDTctL2rj8AuFsmJf1GK0JvxIWzqQ=
X-Received: by 2002:a9f:358c:0:b0:387:9de3:6c8a with SMTP id
 t12-20020a9f358c000000b003879de36c8amr3457830uad.94.1660934567579; Fri, 19
 Aug 2022 11:42:47 -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: 
 <62B26DE1-0E26-40BA-8647-E591E9ACEB7A@me.com> 
 
 
  
In-Reply-To: 
From: Nuno Teixeira 
Date: Fri, 19 Aug 2022 19:42:36 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: 24.3. Updating Bootcode
To: Warner Losh 
Cc: Toomas Soome , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000e5586605e69c7634"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660934568;
	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=LbP3uWf4FMKipOWXh2YpyvHBTsLRGDpaBQ+B3akju+I=;
	b=Qg7tZYIjgtT+i+xC65DtBsaQe42pTMOMSdwxm495MWC9ar4am+0vKUKN+7/f8ilMQVKq70
	1yG1Q6ufWovTlN/V7rDZ49n7bEHqbA94BJiSGVt7SBC8UIVJzcq8oxZOcPIwUXWHKvHgAK
	Azwbd8KLLhhp8KjVgJR9+2fDoo6KFF3xBevVPwm2Fet6CCaAyxnuvYzROS2kOmMIshPtTf
	TE6cjujPs7/svH6nA+uZRHGrOEA5RkPHazON6XmtRzSyIGTKHRwgUE8rTpRfjdYEnu9wYR
	wItMGp7BmnDVE2u46YoBOHYNY4xmAXM4NWmbrC09pMlU/RKSwJN5AJwhX28FuA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660934568; a=rsa-sha256; cv=none;
	b=Q/pNhCNoYTvkANo83ov3w6KWc24I2IVE3jav00stWWlIXL2QocJopO93hkBoFqhhw71f3U
	B66osyW/R2wtrxLT8YL+XbdqPQ244NG9g7BzHnw3GJiMArQEIiXXXoDGTX2IPvnCmogo7Q
	t1budafvppdft39W0+yt+2fbPsr2efST7iaJMRZtTcC88oDDn0J3/cfHaBqr2ZslZM6F8m
	WcFLSlc3lG8BAWOnBdvfrSFBjhyHh+L1rCS7H7wgF2Xe4e4mkGuAMGyi15xHh6vweynN1U
	FkcQrD7x7waRPIPt/gzno65ziEhgNu7dhi3q4cBtYpniRjPV1qrfUSvKqdnPAg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e5586605e69c7634
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@ main-n257521-97be6fced7db

Clean boot without warnings.
OK.

Thanks,

Nuno Teixeira  escreveu no dia quinta, 18/08/2022 =C3=
=A0(s)
12:04:

> Forgot to send a screenshot
>  for
> loader.efi @ main-n257458-ef8b872301c5
> ( +Boot0007* FreeBSD-14
> HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\fre=
ebsd\loader.efi)
>                          nvd0p1:/efi/freebsd/loader.efi
> /boot/efi//efi/freebsd/loader.efi )
>
> Someone talked about this warnings earlier:
> ---
> Attempted extraction of recovery data from stadard superblock: failed
> Attempt to find boot zone recovery data: failed
> (...)
> ---
> But it boots ok.
>
> Cheers,
>
> Nuno Teixeira  escreveu no dia quarta, 17/08/2022
> =C3=A0(s) 19:18:
>
>> *** and "EFI Hard Drive"(legacy /efi/boot/bootx64.efi) from BIOS.
>>                                                                    ^^^^
>>
>> Nuno Teixeira  escreveu no dia quarta, 17/08/2022
>> =C3=A0(s) 19:14:
>>
>>> Hi,
>>>
>>> And it's done:
>>> ---
>>>  Boot0007* FreeBSD-14
>>> HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\f=
reebsd\loader.efi)
>>>                          nvd0p1:/efi/freebsd/loader.efi
>>> /boot/efi//efi/freebsd/loader.efi
>>> +Boot0006* FreeBSD-14_old
>>> HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\f=
reebsd\loader-old.efi)
>>>                              nvd0p1:/efi/freebsd/loader-old.efi
>>> /boot/efi//efi/freebsd/loader-old.efi
>>>  Boot0004* Windows Boot Manager
>>> HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\=
Microsoft\Boot\bootmgfw.efi)
>>>
>>>  da1p1:/EFI/Microsoft/Boot/bootmgfw.efi (null)
>>>  Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
>>> PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-0=
0)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
>>> ---
>>> and I can choose "FreeBSD-14"(/efi/freebsd/loader.efi),
>>> "FreeBSD-14_old"(/efi/freebsd/loader-old.efi) and "EFI Hard
>>> Drive"(legacy /efi/bootx64.efi) from BIOS.
>>>
>>> NOTE: efibootmgr(8) example is:
>>> ---
>>> efibootmgr -a -c -l /boot/efi/EFI/freebsd/loader.efi -L FreeBSD-11
>>>                                           ^^^
>>> ---
>>> But I choosed "efi" instead of "EFI"...
>>>
>>> Thanks all for helping me understand it!
>>>
>>> Cheers,
>>>
>>>
>>> Warner Losh  escreveu no dia ter=C3=A7a, 16/08/2022 =C3=
=A0(s)
>>> 18:19:
>>>
>>>>
>>>>
>>>> On Tue, Aug 16, 2022 at 6:01 AM Nuno Teixeira 
>>>> wrote:
>>>>
>>>>> Hi Toomas,
>>>>>
>>>>> For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page
>>>>>> 499) is suggesting to use structure like:
>>>>>>
>>>>>> /efi//=E2=80=A6
>>>>>>
>>>>>> And to use this suggestion, it means the UEFI Boot Manager needs to
>>>>>> be configured (see efibootmgr(8)).
>>>>>>
>>>>>> Therefore, once you have set up OS specific setup, there is no use
>>>>>> for default (/efi/boot/=E2=80=A6) and you need to update one or=
 another, but
>>>>>> not both.
>>>>>>
>>>>>
>>>>> FreeBSD have /efi/freebsd/... but it's not configured in
>>>>> efibootmgr:
>>>>>
>>>>
>>>> The current default installer will do this, but older upgraded systems
>>>> don't do this by default. Likely you are looking at an older
>>>> system and/or one of the 'bad actors' that reset this stuff between
>>>> boots.
>>>>
>>>>
>>>>> efibootmgr -v:
>>>>> ---
>>>>> BootOrder  : 0004, 0000, 2002, 2003, 2001
>>>>> Boot0004* Windows Boot Manager
>>>>> HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0bb7283,0x800,0x82000)/File(\EF=
I\Microsoft\Boot\bootmgfw.efi)
>>>>>
>>>>>  da0p1:/EFI/Microsoft/Boot/bootmgfw.efi (null)
>>>>> +Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2)
>>>>> PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25=
-00)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
>>>>>  Boot2002* EFI DVD/CDROM
>>>>>  Boot2003* EFI Network
>>>>>  Boot2001* EFI USB Device
>>>>> ---
>>>>> so boot is definitely using /efi/boot/bootx64.efi @Boot0000
>>>>>
>>>>
>>>> In your case, that's true. The "EFI Hard Drive" is a default entry the
>>>> UEFI BIOS created for you.
>>>>
>>>>
>>>>> I think I can create a new boot:
>>>>> ---
>>>>> efibootmgr -a -c -l /boot/efi/efi/freebsd/loader.efi -L FreeBSD-14
>>>>> (and make it active)
>>>>> efibootmgr -a -b NNNN
>>>>> ---
>>>>> and create other for loader.efi.old in case of problems.
>>>>>
>>>>
>>>> Yes.
>>>>
>>>>
>>>>> In this case I will need only update /efi/freebsd/loader.efi.
>>>>>
>>>>> Q: for what has been said in mailing, boot is compiled in
>>>>> /usr/src/stand, isn't a good idea that when it install new boot it ba=
ckup
>>>>> old boot like /boot/kernel -> /boot/kernel.old?
>>>>>
>>>>
>>>> Yes. In fact that's what's done, but only for the BIOS version. We
>>>> should do the same for efi but don't seem to do so currently. But that=
's
>>>> likely tied up behind issues of installing things automatically into t=
he
>>>> ESP on 'installworld'.
>>>>
>>>> Warner
>>>>
>>>
>>>
>>> --
>>> Nuno Teixeira
>>> FreeBSD Committer (ports)
>>>
>>
>>
>> --
>> Nuno Teixeira
>> FreeBSD Committer (ports)
>>
>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000e5586605e69c7634
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


@ main-n257521-97be6fced7db

=
Clean boot without warnings.
OK.

Tha=
nks,

Nuno Teixeira <ed=
uardo@freebsd.org> escreveu no dia quinta, 18/08/2022 =C3=A0(s) 12:0=
4:
Forgot to send a screenshot for loader.efi @ m=
ain-n257458-ef8b872301c5
( +Boot0007* FreeBSD-14 HD(1,GPT,73acd1b=
2-de41-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\freebsd\loader.efi)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0nvd0p1:/efi/freebsd/loader.efi /boot/efi//efi/freebsd/load=
er.efi )

Someone talked about this warnings earlie=
r:
---
Attempted extraction of recovery data from stada=
rd superblock: failed
Attempt to find boot zone recovery data: fa=
iled
(...)
---
But it boots ok.

=

Cheers,

Nuno Teixeira <eduardo@freebsd.org> escreveu no dia quarta, 1=
7/08/2022 =C3=A0(s) 19:18:
*** and "EFI Hard Drive"(legacy =
<ESP>/efi/boot/bootx64.efi) from BIOS.
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 ^^^^

Nuno Teixeira <eduardo@freebsd.org> escreveu no dia quarta, 17/08=
/2022 =C3=A0(s) 19:14:
Hi,

And it's done=
:
---
=C2=A0Boot0007* FreeBSD-14 HD(1,GPT,73acd1b2-de41=
-11eb-8156-002b67dfc673,0x28,0x82000)/File(\efi\freebsd\loader.efi)
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0nvd0p1:/efi/freebsd/loader.efi /boot/efi//efi/freebsd/loader.e=
fi
+Boot0006* FreeBSD-14_old HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc6=
73,0x28,0x82000)/File(\efi\freebsd\loader-old.efi)
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0nvd0p1:/efi/freebsd/loader-old.efi /boot/efi//efi/freebsd/loader-=
old.efi
=C2=A0Boot0004* Windows Boot Manager HD(1,GPT,8c497825-1db2-41f8=
-8924-85dfd0bb7283,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0da1p1:/EFI/Microsoft/Bo=
ot/bootmgfw.efi (null)
=C2=A0Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0H=
BLR-000L2) PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-=
38-25-00)/HD(1,GPT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
=

---
and I can choose "FreeBSD-14"(<ESP>/efi/=
freebsd/loader.efi), "FreeBSD-14_old"(<ESP>/efi/freebsd/loa=
der-old.efi) and "EFI Hard Drive"(legacy <ESP>/efi/bootx64.=
efi) from BIOS.

NOTE: efibootmgr(8) example is:
---
efibootmgr -a -c -l /boot/efi/EFI/freebsd/loader.efi =
-L FreeBSD-11
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^^^
---
But I choosed "efi" instead of "EFI"...

Thanks all for helping me understand it!

Cheers,


Warner Losh <imp@bsdimp.com> escreveu no dia ter=
=C3=A7a, 16/08/2022 =C3=A0(s) 18:19:


On Tue, Aug 16, =
2022 at 6:01 AM Nuno Teixeira <eduardo@freebsd.org> wrote:
Hi Toomas,


For better OS support, the UEFI specification (UEFI 2.8A Feb 14, page 499) =
is suggesting to use structure like:



<ESP>/efi/<OS>/=E2=80=A6



And to use this suggestion, it means the UEFI Boot Manager needs to be conf=
igured (see efibootmgr(8)).



Therefore, once you have set up OS specific setup, there is no use for defa=
ult (<ESP>/efi/boot/=E2=80=A6) and you need to update one or another,=
 but not both.

FreeBSD have <E=
SP>/efi/freebsd/... but it's not configured in efibootmgr:

The current default installer will do th=
is, but older upgraded systems don't do this by default. Likely you are=
 looking at an older
system and/or one of the 'bad actors'=
; that reset this stuff between boots.
=C2=A0
efibootmgr -v:
---
BootOrder =C2=A0: 0004, 0000, 2002, 2003, 2001
<=
div>Boot0004* Windows Boot Manager HD(1,GPT,8c497825-1db2-41f8-8924-85dfd0b=
b7283,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0da0p1:/EFI/Microsoft/Boot/bootmgfw=
.efi (null)
+Boot0000* EFI Hard Drive (SAMSUNG MZVLB1T0HBLR-000L2) PciRo=
ot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,39-f9-b8-01-81-38-25-00)/HD(1,G=
PT,73acd1b2-de41-11eb-8156-002b67dfc673,0x28,0x82000)
=C2=A0Boot2=
002* EFI DVD/CDROM
=C2=A0Boot2003* EFI Network
=C2=A0Boot2001* EFI US=
B Device
---
so boot is definitely using <ESP>/ef=
i/boot/bootx64.efi @Boot0000

In your case, that's true. The=
 "EFI Hard Drive" is a default entry the UEFI BIOS created for yo=
u.
=C2=A0
=

I think I can create a new boot:
---
efibootmgr -a -c -l /boot/efi/efi/freebsd/loader.efi -L Free=
BSD-14
(and make it active)
efibootmgr -a -b NNNN
=

---
and create other for loader.efi.old in case of problems.=


Yes.
=C2=A0
In thi=
s case I will need only update <ESP>/efi/freebsd/loader.efi.

Q: for what has been said in mailing, boot is compiled=
 in /usr/src/stand, isn't a good idea that when it install new boot it =
backup old boot like /boot/kernel -> /boot/kernel.old?

Yes. In fact that's what's done, but onl=
y for the BIOS version. We should do the same for efi but don't seem to=
 do so currently. But that's likely tied up behind issues of installing=
 things automatically into the ESP on 'installworld'.
Warner=C2=A0




-- 
Nuno Teixeira
FreeBSD Co=
mmitter (ports)




-- 
Nuno Teixeira
FreeBSD Co=
mmitter (ports)




-- 
Nuno Teixeira
FreeBSD Co=
mmitter (ports)



-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--000000000000e5586605e69c7634--

From nobody Sat Aug 20 00:50:38 2022
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 4M8g6h4Wj6z4YgG3
	for ; Sat, 20 Aug 2022 00:51:24 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M8g6g5RWCz43q3
	for ; Sat, 20 Aug 2022 00:51:23 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Received: by mail-io1-xd2a.google.com with SMTP id 62so4493720iov.5
        for ; Fri, 19 Aug 2022 17:51:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc;
        bh=pcOLU7+SIGtQ0tGUYYyPN4cJtbgT1q3VTM+9dJ3M75g=;
        b=KwlGJtp6JkJq2CyIbyPJ9UqRwCEfi3VNGdp4d1Tit9cBJy1HFlpqvZ5Jy0HQQciVVU
         8uNBeQ2axqVZLFccPlYzSnJsMZbM+bZ5f1xoTzO9IqjBVNOWFHCNJjL6HzQy4+Xa8sYD
         UnJWimJ8SfC7CrI6qvaH8A5CmlCtU321MT01mpwGz/uNOTXNncZKZiMey3WZd26/zaP8
         r68D8Ps5Y75AzewGLSgus0/OCt0NGl+NtSC1yPf/OIhQUxNS+9US40K/dmO5+dhjHq7h
         1uRzIJI8Sst/ZkiS/33hWvQnjbKq7ie7cAz+0b0X03ZwMrqoVDsJ5E4yaNHJcJpnxdPr
         dzzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc;
        bh=pcOLU7+SIGtQ0tGUYYyPN4cJtbgT1q3VTM+9dJ3M75g=;
        b=DH2dHG1I8vCy1Hgi9zJNGbuT6DYJ+FANik7LFUhoJSMRpYGYPEsXw+widYF5zOfaUJ
         BcJUhPR21HgadF3JF1KilxZlakbTXTyoAN2TdvYfuzaPof88/ycuHHF8sKxUi5p3oMVB
         aaETp+oLvHlEdTHWtE++ld2EmZfSRdI9T5g1S9yd0t9v8KUC5zI1F8ImV7uVq5colm88
         QE0+31QcJYDhp9yKKhL8HzPB/WK/WD0j9+tMG2qTaORxcdg/d9dk5Qk4ptv8bfNmLGA5
         rxniaTrdS0ibxKeSLJs/qHee5ovXbVtVINJ0Y4yxd9S1k2Laga2SffTrp/cELZ2WvyGo
         VpGQ==
X-Gm-Message-State: ACgBeo0BG0N8HAQLKONR6ncKBdSVto56Rutg/CilzxDhMS2XlCKLW5D9
	WTi6VdMOpzupaw/jz32LDINyjYVz/+vC6dnR9eoW78oQ
X-Google-Smtp-Source: AA6agR4eVbk+YIb6lsxUtEj0BI7n6xGD/MPFEq1InnaxTR7ICk0DyX2xMP61qGTPydkbMJHmRmCa6LlVAim6v55QsqM=
X-Received: by 2002:a05:6638:440b:b0:344:c317:82e6 with SMTP id
 bp11-20020a056638440b00b00344c31782e6mr4476073jab.21.1660956682744; Fri, 19
 Aug 2022 17:51:22 -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: Kevin Oberman 
Date: Fri, 19 Aug 2022 17:50:38 -0700
Message-ID: 
Subject: Status of Alder Lake support
To: current 
Content-Type: multipart/alternative; boundary="0000000000000ffa6e05e6a19df4"
X-Rspamd-Queue-Id: 4M8g6g5RWCz43q3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=KwlGJtp6;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::d2a as permitted sender) smtp.mailfrom=kob6558@gmail.com
X-Spamd-Result: default: False [-3.66 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.99)[-0.992];
	NEURAL_HAM_LONG(-0.97)[-0.970];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2a:from];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000000ffa6e05e6a19df4
Content-Type: text/plain; charset="UTF-8"

What is the current state of support for Alder Lake CPUs with a mix of
"performance" and "Efficiency"  cores. I just received my first system with
such a processor and will be installing FreeBSD as soon as my SSD arrives.
I have no idea what issues I might run into. (Will it even work?)
-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

--0000000000000ffa6e05e6a19df4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


What is the current state of support for Alder L=
ake CPUs with a mix of "performance" and "Efficiency"=
=C2=A0 cores. I just received my first system with such a processor and wil=
l be installing FreeBSD as soon as my SSD arrives. I have no idea what issu=
es I might run into. (Will it even work?)
-- 
=

Kevin Oberman, Part time kid herder and retired Network EngineerE-mail: rkoberma=
n@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB=
39EF1B055683


--0000000000000ffa6e05e6a19df4--

From nobody Sat Aug 20 01:43:32 2022
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 4M8hGw68rzz4YnrM
	for ; Sat, 20 Aug 2022 01:43:36 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M8hGv1jZ5z3DnY
	for ; Sat, 20 Aug 2022 01:43:35 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: by mail-qk1-x735.google.com with SMTP id g16so4442647qkl.11
        for ; Fri, 19 Aug 2022 18:43:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:from:to:cc;
        bh=YKlezQ9pl+VItjkmoQALnmgMP7SiucaY3fv5uHDJ9Xo=;
        b=LsLSBMDRe2LKZQgysRiXuhfwBprS4HbsJVET2V409xSU+KQGEZgChbNijKyzQw9gHm
         jkec3eZ8motpyvxPOkKGynWJF2QkghUoa4EmBJCEApHI+t7fylB/dqs+r62fJD18/vG0
         Y/cMd6dkJgrA3VihEjgZbO5hZzZSWJ9LrdVBqIYkMXY1PiNdNEXJVqhkWpl2BOu1w5am
         Rb+NQPERu6R1gneJT6kpQ9lCAity8cW6pzMlu+hEn5Qkj/Wub0b7JgKlf558X3N3GG71
         3AKn8ZLfdTZFCGQSOx+H6xxe9I5+XZW1YKMI4O76c0qrO6q0KRKMb3spI+HxQ4dtHEp3
         MZvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:x-gm-message-state:from:to:cc;
        bh=YKlezQ9pl+VItjkmoQALnmgMP7SiucaY3fv5uHDJ9Xo=;
        b=GtO/iw1aisL5rKbrwVCxZoOfVvYx8fDHuwq7EZVdSz72Se++TC4IN6tp4mE/mK/cZ/
         FpI3OnfzSc2yTrnJLXMBqkYdecT9Z+40HcJzq6HlFh5cDFo2js4IJgJW/xFLgjqTr7Fa
         bpJSdWhJdiRqel7kVgUe4KGXVtJnMNRIfLy/KcbkoKy9FmKIraCKhC6uxNXSXTigpbjl
         yB7+iQE30FR3p130WEDoSS3EmHOhNsu1kiXJOHi0+VhJNptvRlBL6D6pOY/Nst07SKmd
         QAazeXlva+8rk/Oy7ZSZlkeErEVCMKzd1tU2ZCMWZuzLnZnyOR9m0cs9Lix8OkPvk4Ay
         fYUQ==
X-Gm-Message-State: ACgBeo0KHq1U9dZIcp1souW2/RNQMSCcgYY/VhJbkFIJjMcTK88wwnEo
	6mfYC+ra36K7tzyDCxCNS59sBOIvMNY=
X-Google-Smtp-Source: AA6agR6vxqPHcHPmquDA98nwk+XbZJb02gDgK3TMnOzR/JErDVCrtLdypnS39IiBC9ZvhQtupcZJUQ==
X-Received: by 2002:ae9:e010:0:b0:6bb:f9b:896a with SMTP id m16-20020ae9e010000000b006bb0f9b896amr6807032qkk.133.1660959814416;
        Fri, 19 Aug 2022 18:43:34 -0700 (PDT)
Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234])
        by smtp.gmail.com with ESMTPSA id t201-20020a37aad2000000b006b9264191b5sm5357675qke.32.2022.08.19.18.43.33
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 19 Aug 2022 18:43:33 -0700 (PDT)
Message-ID: <2ba3e191-64c1-b854-3eb3-080345b56839@FreeBSD.org>
Date: Fri, 19 Aug 2022 21:43:32 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: Status of Alder Lake support
Content-Language: en-US
To: Kevin Oberman , current 
References: 
From: Alexander Motin 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4M8hGv1jZ5z3DnY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=LsLSBMDR;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::735 as permitted sender) smtp.mailfrom=mavbsd@gmail.com
X-Spamd-Result: default: False [-3.19 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	NEURAL_HAM_LONG(-0.99)[-0.993];
	FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::735:from];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Hi Kevin,

On 19.08.2022 20:50, Kevin Oberman wrote:
> What is the current state of support for Alder Lake CPUs with a mix of 
> "performance" and "Efficiency"  cores. I just received my first system 
> with such a processor and will be installing FreeBSD as soon as my SSD 
> arrives. I have no idea what issues I might run into. (Will it even work?)

Generally they work.  I have one in my lab since they appeared, and its 
biggest problem is UEFI console screwed by ASUS, which I partially 
fixed.  At some BIOS versions they also broke PXE booting, but then 
fixed it in later update.

The FreeBSD scheduler still has no idea about P and E cores, just trying 
to balance load equally based on cache topology (which is not symmetric 
there), but it is not too bad, since cores performance is not so 
dramatically different.

hwpmc(4) also does not differentiate P and E cores, and since they have 
different counters, it means that only few universal architectural 
counters are usable, which are sufficient for basic profiling though.

There were some stability issues reported, but were solved by either 
FreeBSD or BIOS update, so still not really diagnosed AFAIK.

-- 
Alexander Motin

From nobody Sat Aug 20 02:56:14 2022
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 4M8jtx57bbz4Z0Cx
	for ; Sat, 20 Aug 2022 02:56:25 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M8jtw0q6Tz3Pxw;
	Sat, 20 Aug 2022 02:56:23 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 27K2uFZv048109;
	Sat, 20 Aug 2022 11:56:16 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Sat, 20 Aug 2022 11:56:14 +0900
From: Tomoaki AOKI 
To: Warner Losh 
Cc: Yasuhiro Kimura ,
        FreeBSD Current
 
Subject: Re: Updating EFI boot loader results in boot hangup
Message-Id: <20220820115614.e3e7a344e017c8531c3850e7@dec.sakura.ne.jp>
In-Reply-To: <20220817075532.56e144f2857ed45b298a6b1c@dec.sakura.ne.jp>
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
	<20220814.063440.1883565953618972371.yasu@FreeBSD.org>
	<20220816.120142.317069615425604393.yasu@FreeBSD.org>
	
	<20220817075532.56e144f2857ed45b298a6b1c@dec.sakura.ne.jp>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4M8jtw0q6Tz3Pxw
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[sakura.ne.jp];
	RCPT_COUNT_THREE(0.00)[3];
	HAS_ORG_HEADER(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, 17 Aug 2022 07:55:32 +0900
Tomoaki AOKI  wrote:

> On Mon, 15 Aug 2022 21:35:52 -0600
> Warner Losh  wrote:
> 
> > On Mon, Aug 15, 2022, 9:04 PM Yasuhiro Kimura  wrote:
> > 
> > > From: Yasuhiro Kimura 
> > > Subject: Re: Updating EFI boot loader results in boot hangup
> > > Date: Sun, 14 Aug 2022 06:34:40 +0900 (JST)
> > >
> > > > From: Yasuhiro Kimura 
> > > > Subject: Updating EFI boot loader results in boot hangup
> > > > Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST)
> > > >
> > > >> I made regular update of my 14-CURRENT amd64 system from
> > > >> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
> > > >> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
> > > >> boot hangup as following.
> > > >>
> > > >>
> > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
> > > >>
> > > >> If I restore previous loader file (that is, loader.efi of
> > > >> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
> > > >> system boots successfully.
> > > >
> > > > I submitted the problem to FreeBSD Bugzilla.
> > > >
> > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825
> > > >
> > > > Best Regards.
> > >
> > > d98de744050 is committed. So I tested it with following steps.
> > >
> > > 1. Check out the commit.
> > > 2. cd /usr/src/stand
> > > 3. make
> > > 4. make install
> > > 5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd
> > > 6. shutdown -r now
> > >
> > > And system boots successfully. But while efi loader is workding a lot
> > > of messages are displayed as following.
> > >
> > >
> > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png
> > 
> > 
> > Would you be able to share camcontrol devlist output? Privately if need be.
> > And have any of these disks ever held ufs filesystems??
> > 
> > Warner
> > 
> > 
> > > ---
> > > Yasuhiro Kimura
> 
> Just a "me too" info. I have (usually not mounted for test) UFS on ada0.
> (Now the UFS contains outdated [SVN era] root partition of main.)
> 
> % camcontrol devlist
>           at scbus0 target 0 lun 0 (pass0,ada0)
>    at scbus1 target 0 lun 0 (ses0,pass1)
>   at scbus2 target 0 lun 1
> (pass2,nda0)
> 
> % gpart show nda0
> =>        40  3907029088  nda0  GPT  (1.8T)
>           40        2008        - free -  (1.0M)
>         2048     1126400     1  efi  (550M)
>      1128448        2048     2  freebsd-boot  (1.0M)
>      1130496  3770679296     3  freebsd-zfs  (1.8T)
>   3771809792   135219200     4  freebsd-swap  (64G)
>   3907028992         136        - free -  (68K)
> 
> 
> % gpart show ada0
> =>        40  3907029088  ada0  GPT  (1.8T)
>           40        2008        - free -  (1.0M)
>         2048     1126400     1  efi  (550M)
>      1128448        2048     2  freebsd-boot  (1.0M)
>      1130496  3749707776     3  freebsd-zfs  (1.7T)
>   3750838272    20971520     4  freebsd-ufs  (10G)
>   3771809792   135219200     5  freebsd-swap  (64G)
>   3907028992         136        - free -  (68K)
> 
> 
> -- 
> Tomoaki AOKI    
> 

Confirmed fixed at commit 6d645da0d49decc0352f27b8b5ff1983c611659d.
Thanks!

Sorry for the late report. I had been facing another, unrelated problem,
fixed at commit 545db925c3d5408e71e21432895770cd49fd2cf3.


-- 
Tomoaki AOKI    

From nobody Sat Aug 20 06:24:00 2022
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 4M8pVt2VsDz4ZQWx
	for ; Sat, 20 Aug 2022 06:24:22 +0000 (UTC)
	(envelope-from yasu@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M8pVt21kpz3hbr;
	Sat, 20 Aug 2022 06:24:22 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1660976662;
	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=EVsFfnTmYZ/JqlEOcJLOkj9n8JMebus7qU8/1MQGLtU=;
	b=JNXHhbXD+9ToPCA7KLNWs37dzbgs8XWzDt6R4H6mRShaLvybNIZypDrf8LigJ8Dym2LTnK
	IplD1C0Ys2mq5Szl2NyzreG/L34pT5UcbVw6uHrNE/vovT+mGCSscRfg3cQPTcd67BbYsb
	oHXhTq/WnZC176xyil2mGnSk7ogooE0nDccLLs76HAZzWFDbZvu6OWV5REHJ0GpW3aq+sg
	ZOr95GooBDYzfQwqrdaAzjwxusCgu0ZotZN8xseviWP3yeTuYE+eX+7Me9TSnT4OVPuurf
	yT0Qreq3UiZTaxAKR18bfDR0dIXeeHlZYu6hmGpuzIOgRJypvzrolkqSSY/ecA==
Received: from localhost (unknown [IPv6:240b:11:220:fe00:3477:1c25:dd95:22c])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: yasu/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4M8pVs4KTKzVDf;
	Sat, 20 Aug 2022 06:24:21 +0000 (UTC)
	(envelope-from yasu@FreeBSD.org)
Date: Sat, 20 Aug 2022 15:24:00 +0900 (JST)
Message-Id: <20220820.152400.952574300074260194.yasu@FreeBSD.org>
To: freebsd-current@freebsd.org
Subject: Re: Updating EFI boot loader results in boot hangup
From: Yasuhiro Kimura 
In-Reply-To: <20220816.120142.317069615425604393.yasu@FreeBSD.org>
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
	<20220814.063440.1883565953618972371.yasu@FreeBSD.org>
	<20220816.120142.317069615425604393.yasu@FreeBSD.org>
X-Mailer: Mew version 6.8 on Emacs 29.0.50
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1660976662;
	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=EVsFfnTmYZ/JqlEOcJLOkj9n8JMebus7qU8/1MQGLtU=;
	b=YaCQ3XKmRyIus46vNwcolDeLP95Kn75w0dHnEivgDLmszhb+USaEzAKalAD8TL7xjmjV2q
	xbnENX932ehDJhGPS3QeF0qaVyrkJCGjuM3l2UiVWOdsFT5W+hhcwzdvjpzfSgNT+jOvYG
	ASILRUS84ifwNw4k96Ydp/YSPkH7JYNKcxSvBa4ec4rZxGPOUL+S2Ps34odV0OFsuz9fUI
	lfbI04tlZNtSLKw3QeSADZsdfuUxxQpOhHO2CBqn+nkXFtcTzHcutkrtEtP3yyvHaYNcig
	tf4PwzPQtcfM46n3Hw38OUqezAT97grIfXbKiIOMdPcx9IJdt0FRuy0QWenm7w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660976662; a=rsa-sha256; cv=none;
	b=wvuEZv1qeW8HuSD5AaPcl/BpNnqWZbGPWShs6xzjQan/r3tEZ4aR8Hm9B3gPJFAk9t42Nf
	FL6x5+D4ji/IPCXDCoz20alxuWaec2c4oTeCJKsHSpdf4CgxVBmEeup+0jFTKXAL4V/rwF
	QCUNXiFXIUgjrirApJ/tPs6vIqUegk/S2YgenO+WSzmq9CikRSKIeLCzUWIsMFWCWXV1Uf
	WgiEzU9l57d99tiwQXD2S9XPKFDL4DYblofDW/XvVudYU3aLQuuZIsz16gZD+9Wb/Po4T0
	pjgb+PTSe8s0kBoKUrA2M/r+FOZ8vP6Gt2eigKvoqUWXEm9isxwEzjR10N2peg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

From: Yasuhiro Kimura 
Subject: Re: Updating EFI boot loader results in boot hangup
Date: Tue, 16 Aug 2022 12:01:42 +0900 (JST)

>>> I made regular update of my 14-CURRENT amd64 system from
>>> main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated
>>> EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in
>>> boot hangup as following.
>>> 
>>> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png
>>> 
>>> If I restore previous loader file (that is, loader.efi of
>>> main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then
>>> system boots successfully.
>> 
>> I submitted the problem to FreeBSD Bugzilla.
>> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825
>> 
>> Best Regards.
> 
> d98de744050 is committed. So I tested it with following steps.
> 
> 1. Check out the commit.
> 2. cd /usr/src/stand
> 3. make
> 4. make install
> 5. install -m 755 -p /boot/loader.efi /boot/efi/efi/freebsd
> 6. shutdown -r now
> 
> And system boots successfully. But while efi loader is workding a lot
> of messages are displayed as following.
> 
> https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png

Today I made regular weekly update to main-n257521-97be6fced7d and now
loader.efi works fine without extra messages.

---
Yasuhiro Kimura

From nobody Sat Aug 20 06:39:34 2022
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 4M8prg6d24z4ZS7T
	for ; Sat, 20 Aug 2022 06:39:47 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M8prg1Xnpz3k1Y;
	Sat, 20 Aug 2022 06:39:47 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Received: by mail-il1-x12e.google.com with SMTP id a13so3291008ild.3;
        Fri, 19 Aug 2022 23:39:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=4am89rNSnXQ6GrzzukZnCFY5hvolSYlIVlCV4HXtwYA=;
        b=T+WDNPia4n8lfl58JLuE/5Qp4epOa5imOrkT6enH9sn/avnRrqdYrpJs7a+wG68jYr
         AD24O2uRGZGbBUtuLVjSLb2/p632Bz4FMdX2cd4N6/kGFHPo8lsxeJ5m/xVV2HbMOdC2
         tDLUOx4iaLyan+4WhW9JEKW224ZR+E/Z6+elRUM2TJW+oE2VrrBKzv3PYtF6+Ywy/FpK
         F7vtTurd+NcSAD5DaAegELJHtCzUHfRx95xgGLf7n59l2/0PIKYGqD7GVMu68H/ZwunF
         lQqgXNScA3/v/2hM7nJlZ3t8MSVrxImDDV+30Xs98YUJhiEgs21Wz2tINEM34lT3mc4K
         bccw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=4am89rNSnXQ6GrzzukZnCFY5hvolSYlIVlCV4HXtwYA=;
        b=hNL1bPd+xgI4s6oNjf9GmBPul6eYZL9ptooWNLJT1320o+1nFEGNkoClwdYqWOIkyF
         7qw+b4hzgRNbsTGC4cw/e5XHAbFNS8rguq6ZStw1kyCl1Y6odYPPfEZs4cugIRYpUFSV
         M4NRn3NIAhKstKm0qjK22roFujdcVY7/IEF6LvsWW8njwWboQ2QCeG0LaOXrxtv5TxNz
         HolhFqTNLMoqdinrPbrVZ7CRIWIeTMJCfjRgevjANSa8SJ6Ew0saW8vjYyv2I7kDix2I
         odgBXWV8Q9l+QrA/S4hh4+zl5YpOHN5vbKHcY4/P9aG57Xo3o6o1B1bTXdY9iP/U4JFQ
         HWdQ==
X-Gm-Message-State: ACgBeo0BS5fIOblD7uJCMgdtjqaQ6JqiD8dT7n4MsEirlsLtYBlljhiU
	xZcAzS8bSY+V5a976ewACp4RftZeKyEVvNEMfLpZyUwr
X-Google-Smtp-Source: AA6agR5RDiypu+cwRQRQIqBNBN+i4fxRLtIfoG+L0hJXz3E4vEA5p+MHGZWcIzL/AaelVde8+7CKDky1ELxRSLWrk58=
X-Received: by 2002:a05:6e02:1489:b0:2df:a555:be93 with SMTP id
 n9-20020a056e02148900b002dfa555be93mr5287896ilk.290.1660977586041; Fri, 19
 Aug 2022 23:39:46 -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: 
 <2ba3e191-64c1-b854-3eb3-080345b56839@FreeBSD.org>
In-Reply-To: <2ba3e191-64c1-b854-3eb3-080345b56839@FreeBSD.org>
From: Kevin Oberman 
Date: Fri, 19 Aug 2022 23:39:34 -0700
Message-ID: 
Subject: Re: Status of Alder Lake support
To: Alexander Motin 
Cc: current 
Content-Type: multipart/alternative; boundary="000000000000fefa8f05e6a67aed"
X-Rspamd-Queue-Id: 4M8prg1Xnpz3k1Y
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=T+WDNPia;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::12e as permitted sender) smtp.mailfrom=kob6558@gmail.com
X-Spamd-Result: default: False [-3.62 / 15.00];
	NEURAL_HAM_SHORT(-0.99)[-0.986];
	NEURAL_HAM_LONG(-0.97)[-0.973];
	NEURAL_HAM_MEDIUM(-0.96)[-0.958];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12e:from];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000fefa8f05e6a67aed
Content-Type: text/plain; charset="UTF-8"

Thanks for the info, Alexander. I really appreciate it. I'll find out for
myself next week when my SSD gets here, though I might try booting from a
thumb drive and see what happens.

On Fri, Aug 19, 2022, 18:43 Alexander Motin  wrote:

> Hi Kevin,
>
> On 19.08.2022 20:50, Kevin Oberman wrote:
> > What is the current state of support for Alder Lake CPUs with a mix of
> > "performance" and "Efficiency"  cores. I just received my first system
> > with such a processor and will be installing FreeBSD as soon as my SSD
> > arrives. I have no idea what issues I might run into. (Will it even
> work?)
>
> Generally they work.  I have one in my lab since they appeared, and its
> biggest problem is UEFI console screwed by ASUS, which I partially
> fixed.  At some BIOS versions they also broke PXE booting, but then
> fixed it in later update.
>
> The FreeBSD scheduler still has no idea about P and E cores, just trying
> to balance load equally based on cache topology (which is not symmetric
> there), but it is not too bad, since cores performance is not so
> dramatically different.
>
> hwpmc(4) also does not differentiate P and E cores, and since they have
> different counters, it means that only few universal architectural
> counters are usable, which are sufficient for basic profiling though.
>
> There were some stability issues reported, but were solved by either
> FreeBSD or BIOS update, so still not really diagnosed AFAIK.
>
> --
> Alexander Motin
>

--000000000000fefa8f05e6a67aed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the info, Alexander. I really appreciate it. I=
'll find out for myself next week when my SSD gets here, though I might=
 try booting from a thumb drive and see what happens.

On Fri, Aug 19, 2022=
, 18:43 Alexander Motin <mav@freebsd.=
org> wrote:
Hi Kevin,



On 19.08.2022 20:50, Kevin Oberman wrote:

> What is the current state of support for Alder Lake CPUs with a mix of=
 

> "performance" and "Efficiency"=C2=A0 cores. I just=
 received my first system 

> with such a processor and will be installing FreeBSD as soon as my SSD=
 

> arrives. I have no idea what issues I might run into. (Will it even wo=
rk?)



Generally they work.=C2=A0 I have one in my lab since they appeared, and it=
s 

biggest problem is UEFI console screwed by ASUS, which I partially 

fixed.=C2=A0 At some BIOS versions they also broke PXE booting, but then 
fixed it in later update.



The FreeBSD scheduler still has no idea about P and E cores, just trying 
to balance load equally based on cache topology (which is not symmetric 
there), but it is not too bad, since cores performance is not so 

dramatically different.



hwpmc(4) also does not differentiate P and E cores, and since they have 
different counters, it means that only few universal architectural 

counters are usable, which are sufficient for basic profiling though.



There were some stability issues reported, but were solved by either 

FreeBSD or BIOS update, so still not really diagnosed AFAIK.



-- 

Alexander Motin




--000000000000fefa8f05e6a67aed--

From nobody Sat Aug 20 18:13:57 2022
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 4M96Fp2y5Zz4Ztcy
	for ; Sat, 20 Aug 2022 18:14:06 +0000 (UTC)
	(envelope-from verm@darkbeer.org)
Received: from mx.coeval.ca (mx.coeval.ca [184.75.211.21])
	(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 4M96Fn4WHgz3gp7
	for ; Sat, 20 Aug 2022 18:14:05 +0000 (UTC)
	(envelope-from verm@darkbeer.org)
Received: from mx.darkbeer.org (unknown [192.168.211.20])
	by mx.coeval.ca (Postfix) with ESMTP id EBD3743605D
	for ; Sat, 20 Aug 2022 18:13:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbeer.org; s=mail;
	t=1661019237; bh=Cq3p5Ks4Tp0VcMhkYBe7VVvTqhQwtmsligK3Utv5XgA=;
	h=Date:From:To:Subject:References:In-Reply-To;
	b=aDBZx0nvvh4cDaprON/+nj/VPqncDfUDh1BU0u50+i0qZvR7Sp43Gr9WGiZBEQtry
	 45PynukCB3zZAV/fqfwuUnaTn5ODkOb0BzR/O6c0IueAVsdUX5MDow9UNgnxe3wsnb
	 UJqYm5wXJ46YFn/eFAPwEAlm6A8sckOkbi0CEmbs=
Received: by mx.darkbeer.org (Postfix, from userid 1001)
	id E9D90470BFE; Sat, 20 Aug 2022 18:13:57 +0000 (UTC)
Date: Sat, 20 Aug 2022 18:13:57 +0000
From: Amar Takhar 
To: freebsd-current@freebsd.org
Subject: Re: Status of Alder Lake support
Message-ID: <20220820181357.GA5624@darkbeer.org>
Mail-Followup-To: freebsd-current@freebsd.org
References: 
 <2ba3e191-64c1-b854-3eb3-080345b56839@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: <2ba3e191-64c1-b854-3eb3-080345b56839@FreeBSD.org>
X-Rspamd-Queue-Id: 4M96Fn4WHgz3gp7
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=darkbeer.org header.s=mail header.b=aDBZx0nv;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of verm@darkbeer.org designates 184.75.211.21 as permitted sender) smtp.mailfrom=verm@darkbeer.org
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	R_SPF_ALLOW(-0.20)[+ip4:184.75.211.21];
	R_DKIM_ALLOW(-0.20)[darkbeer.org:s=mail];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[darkbeer.org:+];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[darkbeer.org];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:32489, ipnet:184.75.211.0/24, country:CA];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-08-19 21:43 -0400, Alexander Motin wrote:
> Hi Kevin,
> 
> On 19.08.2022 20:50, Kevin Oberman wrote:
> > What is the current state of support for Alder Lake CPUs with a mix of 
> > "performance" and "Efficiency"?? cores. I just received my first system 
> > with such a processor and will be installing FreeBSD as soon as my SSD 
> > arrives. I have no idea what issues I might run into. (Will it even work?)
> 
> Generally they work.  I have one in my lab since they appeared, and its 
> biggest problem is UEFI console screwed by ASUS, which I partially 
> fixed.  At some BIOS versions they also broke PXE booting, but then 
> fixed it in later update.

I have an ASUS Prime Z690-P and had this issue with 13.1 and CURRENT.


> The FreeBSD scheduler still has no idea about P and E cores, just trying 
> to balance load equally based on cache topology (which is not symmetric 
> there), but it is not too bad, since cores performance is not so 
> dramatically different.

Right now I'm running 13.1 if I enable any of my E cores I get UFS corruption 
everywhere so I've had to have these disabled.  There is a ticket 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261169 which 
I just updated as I'm still having issues.


> hwpmc(4) also does not differentiate P and E cores, and since they have 
> different counters, it means that only few universal architectural 
> counters are usable, which are sufficient for basic profiling though.
> 
> There were some stability issues reported, but were solved by either 
> FreeBSD or BIOS update, so still not really diagnosed AFAIK.

I've run into this in my situation some BIOs updates cause constant reboots 
especially when playing video.  I also have serious audio issues with continous 
popping that I've been unable to solve there is a ticket for that as well:

  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263385#add_comment

I'll give CURRENT A shot again in the next day or two to see if this is all 
fixed thanks for the update!


Amar.

From nobody Sat Aug 20 18:36:15 2022
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 4M96lc58nbz4Yy9R
	for ; Sat, 20 Aug 2022 18:36:28 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M96lb5gNLz3jrq
	for ; Sat, 20 Aug 2022 18:36:27 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Received: by mail-io1-xd30.google.com with SMTP id c4so4704645iof.3
        for ; Sat, 20 Aug 2022 11:36:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :from:to:cc;
        bh=pA+SrDgZX3WLYuTlhkN63AWG5eZlNZ/K+42BsVrioSg=;
        b=itwKbVvjwJ7tQjxEGGTHokjXAPh1+nWE5mrjRzRs0ibQF8nj3H5IhY8FEWXCMbPjEF
         pNb/hAJFelwXGTxuv3/sYluDy7Np8Vw/IC/r7551rOwJH2TfUSuiH1qV+IbEvqDNPjZN
         RbOERIjZz2SLXR7z+X3QQnrUtCM6h8nXkZjT3wHP3h7lSpu7SVcVhFHqR1iq5+wyovl9
         EKN9LbD9DW0GRw2dLSMNuL8c7WtKTfcuWUsFlE+5GjeIG5x6pHkDmvK/zUf0KKD7eXa3
         aByfC6X3PS8Do0yp8oMOrCTRDXWM1yCo1Bfg/3+txQ1R9i4XJzYBcLYFIyObzh+q2/zo
         Cc0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :x-gm-message-state:from:to:cc;
        bh=pA+SrDgZX3WLYuTlhkN63AWG5eZlNZ/K+42BsVrioSg=;
        b=k076dzAlrnEnF2Wd+ScuyVjIW4L6zlGwqeqwbCyoNf9C62fh91ZrUHaNCRzLITVuDw
         IppQ7alOMmkQeVPyWgkmyYPLSQWGoHZVnPf5otvVkkCWPmlvvgNTPNPGKakvU19bmq04
         8ciPy92g1F32lRDsTjyDt9G6BA3eGueBrEYb9VP3Fq6xM1tkfmWdp7GbjrxkKLdYDgL3
         Z+lDlhWE47qD8K177WeTej4kk+I5jqtv9MD51U4IXK1ORT8O0MLJhWp0a0U8G3OVZhHU
         04s8kEcVkmJA9nDvuVB27uudxRGmK2wZAmDpAzqk1nS/JeruHVyULEXDRCea3btoLryZ
         G2dw==
X-Gm-Message-State: ACgBeo2vjhuEcUUYU8oNnD8aD5e/F8v67Ynu6D0fsiFTVwu8CynfTfK8
	qh4VIPDCiBUefAIfwcXf6IJKo+DnH0Q2lwO23xebnufN
X-Google-Smtp-Source: AA6agR6DRz9yw3czmVjcy/MpIO7dxfNTtqIIYyiFDxLzkMincwErpRTVHdyUxF+s9Bf4Iii2DsLcOTemSxrPMpKIFJg=
X-Received: by 2002:a05:6638:440b:b0:344:c317:82e6 with SMTP id
 bp11-20020a056638440b00b00344c31782e6mr5849776jab.21.1661020586439; Sat, 20
 Aug 2022 11:36:26 -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: 
 <2ba3e191-64c1-b854-3eb3-080345b56839@FreeBSD.org> <20220820181357.GA5624@darkbeer.org>
In-Reply-To: <20220820181357.GA5624@darkbeer.org>
From: Kevin Oberman 
Date: Sat, 20 Aug 2022 11:36:15 -0700
Message-ID: 
Subject: Re: Status of Alder Lake support
To: FreeBSD Current 
Content-Type: multipart/alternative; boundary="00000000000005048505e6b07eaf"
X-Rspamd-Queue-Id: 4M96lb5gNLz3jrq
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=itwKbVvj;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::d30 as permitted sender) smtp.mailfrom=kob6558@gmail.com
X-Spamd-Result: default: False [-3.66 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	NEURAL_HAM_LONG(-0.99)[-0.988];
	NEURAL_HAM_MEDIUM(-0.98)[-0.979];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d30:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000005048505e6b07eaf
Content-Type: text/plain; charset="UTF-8"

On Sat, Aug 20, 2022, 11:14 Amar Takhar  wrote:

> I've run into this in my situation some BIOs updates cause constant
> reboots
> especially when playing video.  I also have serious audio issues with
> continous
> popping that I've been unable to solve there is a ticket for that as well:
>
>   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263385#add_comment
>
> I'll give CURRENT A shot again in the next day or two to see if this is
> all
> fixed thanks for the update!
>
>
> Amar.
>

Wow! That's a little more disturbing.

As to the audio issue, I've been having a similar issue for some time,
especially with Firefox using any of the available audio systems. Works
best with OSS.

What I hear is not popping, but brief dropouts which I perceived as pops.
It sounds a lot like data rate mismatch where the audio is output at a
slightly faster rate than it is input.  As a result, the buffers empty
periodically and you hear a fraction of a second of silence.

This is not an Alder Lake issue as it's been hitting me on my Comet Lake
processor.

>
>

--00000000000005048505e6b07eaf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sat, Aug 20, 2022, 11:14 Amar Takhar <verm@darkbeer.org> wrote:
I've run into this in my situation some BIOs u=
pdates cause constant reboots 

especially when playing video.=C2=A0 I also have serious audio issues with =
continous 

popping that I've been unable to solve there is a ticket for that as we=
ll:



=C2=A0 https://bugs=
.freebsd.org/bugzilla/show_bug.cgi?id=3D263385#add_comment



I'll give CURRENT A shot again in the next day or two to see if this is=
 all 

fixed thanks for the update!





Amar.

Wow! That's a little more disturbing.=C2=A0

As to the audio issue, I've been having a =
similar issue for some time, especially with Firefox using any of the avail=
able audio systems. Works best with OSS.

<=
div dir=3D"auto">What I hear is not popping, but brief dropouts which I per=
ceived as pops. It sounds a lot like data rate mismatch where the audio is =
output at a slightly faster rate than it is input.=C2=A0 As a result, the b=
uffers empty periodically and you hear a fraction of a second of silence.

This is not an Alder Lake=
 issue as it's been hitting me on my Comet Lake processor.=C2=A0
<=
div dir=3D"auto">






--00000000000005048505e6b07eaf--

From nobody Sat Aug 20 18:45:31 2022
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 4M96y41nbGz4Z0Fv
	for ; Sat, 20 Aug 2022 18:45:32 +0000 (UTC)
	(envelope-from verm@darkbeer.org)
Received: from mx.coeval.ca (mx.coeval.ca [184.75.211.21])
	(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 4M96y35Btsz3l8Z
	for ; Sat, 20 Aug 2022 18:45:31 +0000 (UTC)
	(envelope-from verm@darkbeer.org)
Received: from mx.darkbeer.org (unknown [192.168.211.20])
	by mx.coeval.ca (Postfix) with ESMTP id 1B87343605C
	for ; Sat, 20 Aug 2022 18:45:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbeer.org; s=mail;
	t=1661021131; bh=NZvJrBN93UYE8trFv3Dxc0uNi15/Lx8zOQbiCX2Cp0Q=;
	h=Date:From:To:Subject:References:In-Reply-To;
	b=rc5M/BbxeJe2SZGTQ35HDlW/0FkWIa33hvj2LxjVUbRV5RvndSX6WrJPk4+rHs6rn
	 KLz+e2RqL6GV8tULq8j2SivfKGssuUxAdtWPOZ+RbW7U1f5NBLqKGfxmaH/r1A2abY
	 MAWU5QbkL8+4m90al2dUjd6OgkQd5w/KMa1pn3Ms=
Received: by mx.darkbeer.org (Postfix, from userid 1001)
	id 17C50470BFD; Sat, 20 Aug 2022 18:45:31 +0000 (UTC)
Date: Sat, 20 Aug 2022 18:45:31 +0000
From: Amar Takhar 
To: freebsd-current@freebsd.org
Subject: Re: Status of Alder Lake support
Message-ID: <20220820184531.GA6367@darkbeer.org>
Mail-Followup-To: freebsd-current@freebsd.org
References: 
 <2ba3e191-64c1-b854-3eb3-080345b56839@FreeBSD.org>
 <20220820181357.GA5624@darkbeer.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=unknown-8bit
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Rspamd-Queue-Id: 4M96y35Btsz3l8Z
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=darkbeer.org header.s=mail header.b="rc5M/Bbx";
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of verm@darkbeer.org designates 184.75.211.21 as permitted sender) smtp.mailfrom=verm@darkbeer.org
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	R_DKIM_ALLOW(-0.20)[darkbeer.org:s=mail];
	R_SPF_ALLOW(-0.20)[+ip4:184.75.211.21:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[darkbeer.org:+];
	DMARC_NA(0.00)[darkbeer.org];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:32489, ipnet:184.75.211.0/24, country:CA];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-08-20 11:36 -0700, Kevin Oberman wrote:

> Wow! That's a little more disturbing. 

Especially since it's a i9-12900KF so I have a whole 8 cores disabled!


> As to the audio issue, I've been having a similar issue for some time,
> especially with Firefox using any of the available audio systems. Works best
> with OSS.
> 
> What I hear is not popping, but brief dropouts which I perceived as pops. It
> sounds a lot like data rate mismatch where the audio is output at a slightly
> faster rate than it is input.  As a result, the buffers empty periodically and
> you hear a fraction of a second of silence.

Yes exactly.  Sorry it's better described as clipping and that is exactly what I 
thought was happening too.  There were some suggestions in that ticket I tried 
to no avail.  It's almost like something is blocking the buffer from being 
filled.  The same issue happens when I use an external USB audio card but it's 
nowhere near as bad.

After this many months I'd like to say I've gotten used to it but some videos 
are particularly bad so there is some correlation to what audio is being played.


> This is not an Alder Lake issue as it's been hitting me on my Comet Lake
> processor. 

Oh well that's good to know you should update that ticket (#263385) as I've only 
known Alder Lake to be an issue up to this point.

Is this happening on CURRENT?  I'll upgrade for sure if I can use my E cores and 
avoid UFS corruption.


Amar.

From nobody Sun Aug 21 23:42:29 2022
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 4M9sVJ48JXz4Z7Xr
	for ; Sun, 21 Aug 2022 23:42:32 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4M9sVH67Llz3t4V
	for ; Sun, 21 Aug 2022 23:42:31 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: by mail-pl1-x633.google.com with SMTP id 20so8461108plo.10
        for ; Sun, 21 Aug 2022 16:42:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:references:in-reply-to:mime-version
         :from:to:cc;
        bh=6h/VnHochP2sZkRmjGFVtPCcI4GwuWDiPBatme8wCg4=;
        b=UgpE+9+zKvI2EP3rDtCVRDeXrn5v3yrVxRVu7OiE6/7Z7B5KLXKYZZyDfsKdZNAl+u
         ZjySFWg4oKYk6+p+5HGL2EAceXYFkcqWaUX0jF4fJDBr4bHFZoAdae43zueVorKW8LoY
         gudFfzYuuD6JmRFLx8LUeLo9/g1dw3v6OuBe2ARrov3BXq6xfd3Yigyf6FsU0kWi0WQg
         sZGZKRjHC4HTo46mwUMZfotIV1Lml8NIy7DMLVFMMWHFA7Bvl9tDlOuTtI+30wBvdRs4
         LZFbvrXIVOI9RsX7ZhMxF6giGLY23od8OvENzLdv4caUsYLKYCh6PArIKzYaPSPeqox4
         n96w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:references:in-reply-to:mime-version
         :x-gm-message-state:from:to:cc;
        bh=6h/VnHochP2sZkRmjGFVtPCcI4GwuWDiPBatme8wCg4=;
        b=cVeFNZe8gbM28fMkcJ86dlqqzq0UV5JQLYDdxmBFix476W83m5GfNsyuP4uvZlWzdB
         nRdVuH4bUFuuqk9p4qDYCiXj01iM8walezAqF4+R/r6RWM4BHYel6a34ZOWJ9nnWALST
         DtZXbQThEiCSzkLc4IkIdObTSkva2O043BnAr0DZpmNe1xfHDFNIoaoYE4fP6AojqW1F
         vQtIvzUghPxPj93PuszdjIpuDbtI/OmJeKUs7ITJ+RNvghY3nIo7rxR/X3ANTJey69ur
         g/kDK1SIMwRoxK9/V/9Pz3lBcv8CUXdj9C0w82WCmv8MJDbNYmGptIDn7TvlbVL8Hg8L
         D+SA==
X-Gm-Message-State: ACgBeo38wllOlIDPn0sSsF8tiiGrUUGwnPACJIpwDWRD36saX9J2dF0n
	flG3W2O6T5m2jL4uJQbgljHmSxueCC2q70Otnp12WwpE7nP4kogc
X-Google-Smtp-Source: AA6agR7flGQ5trDDJbR3f4PLqBgzBesenzWMeEh8U1npMKM+4/bbMcNj89uG/A505FQIqc0Fy6tAXvH+0AvS0YXeE2c=
X-Received: by 2002:a17:902:f612:b0:172:cbb0:9b4f with SMTP id
 n18-20020a170902f61200b00172cbb09b4fmr9927487plg.142.1661125350445; Sun, 21
 Aug 2022 16:42:30 -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
Received: by 2002:a17:903:1c5:b0:16e:e892:fa24 with HTTP; Sun, 21 Aug 2022
 16:42:29 -0700 (PDT)
In-Reply-To: 
References: <20220813.015426.809710797578801280.yasu@FreeBSD.org>
 <20220814.063440.1883565953618972371.yasu@FreeBSD.org> 
 
From: grarpamp 
Date: Sun, 21 Aug 2022 19:42:29 -0400
Message-ID: 
Subject: Re: Updating EFI boot loader results in boot hangup
To: freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4M9sVH67Llz3t4V
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=UgpE+9+z;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::633 as permitted sender) smtp.mailfrom=grarpamp@gmail.com
X-Spamd-Result: default: False [-2.96 / 15.00];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	NEURAL_HAM_LONG(-0.92)[-0.924];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	NEURAL_HAM_MEDIUM(-0.04)[-0.042];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::633:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 8/nn/22, yet  top-posted:
> [snip]

https://www.idallen.com/topposting.html

From nobody Mon Aug 22 08:43:59 2022
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 4MB5WD3kMSz4Z1jT
	for ; Mon, 22 Aug 2022 08:44:08 +0000 (UTC)
	(envelope-from SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net)
Received: from bosmailout05.eigbox.net (bosmailout05.eigbox.net [66.96.185.5])
	(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 4MB5WC3z6fz3Xp4
	for ; Mon, 22 Aug 2022 08:44:07 +0000 (UTC)
	(envelope-from SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net)
Received: from bosmailscan06.eigbox.net ([10.20.15.6])
	by bosmailout05.eigbox.net with esmtp (Exim)
	id 1oQ32U-000263-Fr
	for freebsd-current@freebsd.org; Mon, 22 Aug 2022 04:44:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=codenetworks.net; s=dkim; h=Sender:In-Reply-To:From:References:Cc:To:
	Subject:MIME-Version:Date:Message-ID:Content-Type:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
	Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
	List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
	 bh=W6Aic4GvYKFMsr4pJGOy0QjTteql0BouLD592HUYkTY=; b=fzVUVlR1ebRIEiUDAf8YKAT+Z
	xVLWIap7xEL+naYiY0qkXKVY06elTg1Rako3f4EmmU5Sky42wLGO7ABhh5OjAHXjnabCDQZOPLYVa
	MA+H/GqcegrutJbXeGQ1gk1n7/piSrvpJEVn0kzqb72+7cKHhBlKtREEBWQyrtMflkKMzaJn6A3Qv
	hvjKyexUrr6GHGYchvn8N7DXgWAcAOMxZlJvejfOX3elSH+QbuyBdiHjlVWLG/jb+58vx1pzTGKwy
	bYjceR7WVPUzYACTicYHjdJ1gcbnSNlTvfeBp4y5Cb2Z0J1irznjc/qNJolwLPZ4GLzoKUQ8DHkfh
	838BcfUuA==;
Received: from [10.115.3.33] (helo=bosimpout13)
	by bosmailscan06.eigbox.net with esmtp (Exim)
	id 1oQ32U-0002CF-3O
	for freebsd-current@freebsd.org; Mon, 22 Aug 2022 04:44:06 -0400
Received: from bosauthsmtp09.yourhostingaccount.com ([10.20.18.9])
	by bosimpout13 with 
	id AYk22800Q0BkY8i01Yk5t3; Mon, 22 Aug 2022 04:44:06 -0400
X-Authority-Analysis: v=2.3 cv=H7JAP9Qi c=1 sm=1 tr=0
 a=+tcVrJynzLVJ9yqDAOBWjQ==:117 a=Ek/qOh1uPkKSHvd30yk7rg==:17
 a=biHskzXt2R4A:10 a=-Yl_685HdVUA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=jlvWEfeLAAAA:8
 a=yCIJeDggwMLYmKDxbfcA:9 a=QEXdDO2ut3YA:10 a=HHGDD-5mAAAA:8
 a=DCBS5t1p8mdworQ48m0A:9 a=fOcAzg-fn6CHv5IW:21 a=_W_S_7VecoQA:10
 a=BUduvz6nQKmfCEOu4uBS:22
Received: from cm-81-9-194-73.telecable.es ([81.9.194.73]:26417 helo=[192.168.3.100])
	by bosauthsmtp09.eigbox.net with esmtpa (Exim)
	id 1oQ32Q-00071j-LQ; Mon, 22 Aug 2022 04:44:02 -0400
Content-Type: multipart/alternative;
 boundary="------------u4P5qvTcSpoYU1RwBQfrzMVM"
Message-ID: 
Date: Mon, 22 Aug 2022 10:43:59 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: kernel panic during zfs pool import
Content-Language: en-US
To: Toomas Soome 
Cc: freebsd-current 
References: 
 <5F75D096-F28C-436E-B5C0-4A0EFA7A5F3C@me.com>
From: Santiago Martinez 
In-Reply-To: <5F75D096-F28C-436E-B5C0-4A0EFA7A5F3C@me.com>
X-EN-UserInfo: d3bdfab0736480cedf04ed92aaea2ef5:931c98230c6409dcc37fa7e93b490c27
X-EN-AuthUser: sm@codenetworks.net
X-EN-OrigIP: 81.9.194.73
X-EN-OrigHost: cm-81-9-194-73.telecable.es
X-Rspamd-Queue-Id: 4MB5WC3z6fz3Xp4
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none ("invalid DKIM record") header.d=codenetworks.net header.s=dkim header.b=fzVUVlR1;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of "SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net" designates 66.96.185.5 as permitted sender) smtp.mailfrom="SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net"
X-Spamd-Result: default: False [-2.99 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.992];
	FORGED_SENDER(0.30)[sm@codenetworks.net,SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net];
	R_SPF_ALLOW(-0.20)[+ip4:66.96.128.0/18];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_PERMFAIL(0.00)[codenetworks.net:s=dkim];
	FREEMAIL_TO(0.00)[me.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:29873, ipnet:66.96.128.0/18, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[66.96.185.5:from];
	DKIM_TRACE(0.00)[codenetworks.net:~];
	FROM_NEQ_ENVFROM(0.00)[sm@codenetworks.net,SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net];
	RCVD_COUNT_FIVE(0.00)[5];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[codenetworks.net: no valid DMARC record];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------u4P5qvTcSpoYU1RwBQfrzMVM
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks Toommas,
I compiling current right now and will give it a try, hopefully, will be 
able to mount and recover the machine.
Will also open a PR as even if the is any corruption/pool damage it 
should not panic the machine.

Santi


On 8/18/22 21:45, Toomas Soome wrote:
>
>
>> On 18. Aug 2022, at 18:46, Santiago Martinez  wrote:
>>
>> Hi everyone,
>>
>> I have a server running 13.1-stable that was powered off (gracefully) 
>> and now is been powered on again and we have the following problem.
>>
>> The server boots almost properly, kernel load and when zfs import 
>> other pools it panic with the following message.
>>
>> "panic : Solaris (panic) zfs: adding existent segment to range tree 
>> (offset=4af2ca9000 size=a0000)".
>>
>> if i boot into single user and the pools (most specifically pool01 ) 
>> is not imported then there is no panic. but as soon as we try to 
>> import pool01 we get that panic error. it worth mentioning that the 
>> pool imported/online before.
>>
>> Have two question:
>>
>> *    How i can tell to not import the pool automatically during boot 
>> so sever is not stuck in a boot/panic/reboot infinite loop?
>
> removing zpool.cache should do. unfortunately, you would need to boot 
> alternate root (usb/cd/net) for that.
>
>>
>> *    Anybody know what this panic means?
>>
>
> in short - bug. I’d try to boot current and import pool there - maybe 
> the issue is fixed in current…
>
> rgds,
> toomas
>
>> Thanks in advance!
>>
>> Santi
>>
>>
>>
>
--------------u4P5qvTcSpoYU1RwBQfrzMVM
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Thanks Toommas, 

    I compiling current right now and will give it a try, hopefully,
    will be able to mount and recover the machine. 

    Will also open a PR as even if the is any corruption/pool damage it
    should not panic the machine.

    
Santi

    


    

    
On 8/18/22 21:45, Toomas Soome wrote:

    

    

      
      

      


        

          
On 18. Aug 2022, at 18:46, Santiago Martinez
            <sm@codenetworks.net>
            wrote:

          

          

            
Hi everyone,

              

              I have a server running 13.1-stable that was powered off
              (gracefully) and now is been powered on again and we have
              the following problem.

              

              The server boots almost properly, kernel load and when zfs
              import other pools it panic with the following message.

              

              "panic : Solaris (panic) zfs: adding existent segment to
              range tree (offset=4af2ca9000 size=a0000)".

              

              if i boot into single user and the pools (most
              specifically pool01 ) is not imported then there is no
              panic. but as soon as we try to import pool01 we get that
              panic error. it worth mentioning that the pool
              imported/online before.

              

              Have two question:

              

              *    How i can tell to not import the pool automatically
              during boot so sever is not stuck in a boot/panic/reboot
              infinite loop?

            

          

        

        


        

        
removing zpool.cache should do.
            unfortunately, you would need to boot alternate root
            (usb/cd/net) for that.

        

        

          

            


              *    Anybody know what this panic means?

              

            

          

        

        


        

        
in short - bug. I’d try to boot current and import pool
          there - maybe the issue is fixed in current…

        


        

        
rgds,

        
toomas

        

        

          

            
Thanks in advance!

              

              Santi

              

              

              

            

          

        

      

      

    

  


--------------u4P5qvTcSpoYU1RwBQfrzMVM--

From nobody Mon Aug 22 08:45:53 2022
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 4MB5YN545mz4Z217
	for ; Mon, 22 Aug 2022 08:46:00 +0000 (UTC)
	(envelope-from peterj@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MB5YN4Wx0z3ZCX;
	Mon, 22 Aug 2022 08:46:00 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661157960;
	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=UDiyivHzctTaps7dMJP9+rHQQru1zUEefe/LHPhl6Po=;
	b=HhQqOfkh6XPWE9w5+2LDlJwwnJG4KajwOsgchVSWxlxX2XoWUDpiKuERqnNDXJ4tpMBEEW
	o8HCITbqVihJ3y5/oFaCkydc0XZl2Rd73XmMXuez8kNp8VXr4Wq0H9FQs5HNv8HM9neuDU
	nrJa6SHxhMD2tqqSBjyByd+q/wQWYuEU+wukdfntoxvhCQbwYABW2LsC8C3iabbMzsSBcH
	bcmCCZ9yqhYk00aftgYOLnE106aS+ZxbObs2EnSI6ywh0fwbyXKoz6amZ4eE6h0fv2B0wL
	qbVua2Y3WOJRJmBEZXdpldVKWHW0YmvvIK+2bXSvRQFLuUwBxVrQV71/dWZS/g==
Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512)
	(Client did not present a certificate)
	(Authenticated sender: peterj)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MB5YM2cpkz1MsS;
	Mon, 22 Aug 2022 08:45:59 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
Date: Mon, 22 Aug 2022 18:45:53 +1000
From: Peter Jeremy 
To: "Patrick M. Hausen" 
Cc: Ryan Moeller , freebsd-current@freebsd.org
Subject: Re: Beadm can't create snapshot
Message-ID: 
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="dCfOtzdXXjm1uBtn"
Content-Disposition: inline
In-Reply-To: 
X-PGP-Key: http://www.rulingia.com/keys/peter.pgp
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661157960;
	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=UDiyivHzctTaps7dMJP9+rHQQru1zUEefe/LHPhl6Po=;
	b=f9h+A28EQ92PCBSWlejGc+MuOYOG5GCyYocli29PSf8oniB9ivsfn4i5ULX/bd/pYFvLhn
	aNqt/6pOLNuYcYDtR7jR6hupL2kAezZOASs5K+NbwnutHQ0pw5z/gQJdTSMofs+9hAHFBr
	nIaqkrOfQo/2MCby6m4TC6VW8V6FteI/7WpN254y4xNAQKzVZp7rvrcjV7K+s/v6JtxsQA
	ouME+IijpJzOdLSgw6PyeFkxEPdzFetTbMAke41O+fu4Z6pVNZGxnyWu98fZ4/oFNRpL3O
	YGbZiVFTSyA49uGNvGhgjXk3veE2Dbbs8B426+RTy271nUQyFX0UN7taZn1DtA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661157960; a=rsa-sha256; cv=none;
	b=h+MPqjDlfvLMSqDgvj/0tFMLD/IOKEBP0dPJNue0B3baaZIsn9uI4v8WU0vmHTbtDWtEUI
	dVAOZ+0Hi7vdnRpmB2qsqtLdfCyTNRLGWqKIx9tDKeL57NsG1zIUkiyFkTnOMkv5imUqnJ
	cWtGkVttNGDbz0DxpKXMKEWXettzRmK5FzEhHXhYYzl+fkPEONCSo407q4Wj/BIheDNxlj
	4cAb2HyyP1ivEaOVviVOEOjuOEo0GNX0S8VgE4rZqEfVDWkOQShhn1scs4YdXdGes5TTzY
	E4H0/cf3CiL8iqGnhqIhB3zFa41ghJ4BsHCmbVx2FtR30WD/wM7QMyvG7ptgZQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--dCfOtzdXXjm1uBtn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"  wrote:
>Isn't beadm retired in favour of bectl?

bectl still has a number of bugs:
1) The output from "bectl list" is in filesystem/bename order rather
   than creation date order.  This is an issue if you use (eg) git
   commit hashes as the name.
2) "bectl activate" doesn't update /boot/loader.conf so the wrong
   root filesystem is mounted.

That said "bectl create" appears to be a workable replacement for
"beadm create" and avoids the current "'snapshots_changed' is
readonly" bugs.

--=20
Peter Jeremy

--dCfOtzdXXjm1uBtn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmMDQjxfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF
QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi
CzT9xw//XbqCkqzDo2YnmnlY5dEnRwGsqPmzjaTM4vk3DLItVA9OnHIZqC5gnw1f
NNRbs28qQxw/W48xYlqRWhERLCnKeJw16UcNVEkX2SEFAecytkKEPuGdbvmz6XZx
bU1PXbyLa6t3w1K/LxPrkrky6nIOKfBu8wrboesBisl8s2yMBDGZpVkETxHfDVMJ
skZ720PPyyn5Me07e/tdYrQrHRX1biKdirJ5nWO7DIi/1HT9YC5GNlomIX+2xuTF
3KGPbuAEltwmw0SPImJO6Bv+2SShlsWX5IYhHqa2GPBNv8NqEA2TrK+nM/vPNehA
zQQ6WWJ91RuHPmoV4tJCTuvd/B9y3jJ356uSDedZkJfNXQDvR0W9eQyhp/fLOtcj
7WQ/YAIP30dlamfMw8N1N65M8gnrkUNhct/cIdRD0ZpZE0jUZ+YipXPgtQkdUaYA
CV71Ay+q+iExNP97dPiZO0FBEdInSj+JQbWpqphtxA8QUS8gfHk40a8nDXw5ouAy
93Ure+S9OlcBjrl3ltTAqecuNVV8+8uhuEcQzBbAvv2LCvpDtivbQQxL1Ea9qqYB
mIUne221IYaMaq8lYlf/kEMbBmBH0OL2EMLufy0EuZPx/ePiirFqP1LzjPn53J6r
AIPRXNXRio7R5SDnudNhn+oV6h1OQxG2ku6TurvLlK5u3Feemhs=
=qYqx
-----END PGP SIGNATURE-----

--dCfOtzdXXjm1uBtn--

From nobody Mon Aug 22 08:56:51 2022
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 4MB5p52Zltz4Z37x
	for ; Mon, 22 Aug 2022 08:57:01 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4MB5p44MS3z3bxl;
	Mon, 22 Aug 2022 08:57:00 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from smtpclient.apple (217.29.33.131)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 2C3197;
 Mon, 22 Aug 2022 10:56:52 +0200
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 \(3696.120.41.1.1\))
Subject: Re: Beadm can't create snapshot
From: "Patrick M. Hausen" 
In-Reply-To: 
Date: Mon, 22 Aug 2022 10:56:51 +0200
Cc: Ryan Moeller , freebsd-current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E09DD0A-9F26-4BAD-9CA4-B3593B2DE836@hausen.com>
References:
 <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
 
 
To: Peter Jeremy 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MB5p44MS3z3bxl
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of pmh@hausen.com has no SPF policy when checking 217.29.33.228) smtp.mailfrom=pmh@hausen.com
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[hausen.com];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> Am 22.08.2022 um 10:45 schrieb Peter Jeremy :
>=20
> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"  =
wrote:
>> Isn't beadm retired in favour of bectl?
>=20
> bectl still has a number of bugs:
> 1) The output from "bectl list" is in filesystem/bename order rather
>   than creation date order.  This is an issue if you use (eg) git
>   commit hashes as the name.
> 2) "bectl activate" doesn't update /boot/loader.conf so the wrong
>   root filesystem is mounted.

You mean the vfs.root.mountfrom option? I thought that, too, was =
deprecated and
replaced by the bootfs property of the zpool.

I don't have vfs.root.mountfrom anywhere and bectl sets the active BE =
just as expected.
The bootfs property changes accordingly.

Kind regards,
Patrick=

From nobody Mon Aug 22 09:29:27 2022
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 4MB6Wc6QWSz4Z7Lk
	for ; Mon, 22 Aug 2022 09:29:32 +0000 (UTC)
	(envelope-from peterj@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MB6Wc5qm7z3hlm;
	Mon, 22 Aug 2022 09:29:32 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661160572;
	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=XB8k5ylvhz9X8VZw8EJxY3vUpujmMTTQxURNAOpZ/Mo=;
	b=O+/Tx6N+DwXFK7clQcYZz31mDMX1KtFmrpPoCtFSICeAHpgFX4uWGwhkzAAEu/qV3FN7OZ
	OHM0CtFRx88ttQ93JGyDoESBRVXYS+JWpCQjMElN/gXwKFdSrSwDkTq3kgWmmmsmjNUo4H
	7uCXGk9q5N9RxGw9Y2gYfPcaEstAkH0GruBc7l5drcVprcWrpS6fxhqSG48AxwA69LBISt
	o9agolePHZHrhtgAwkwIq3emNykw6qMnC3hzwPqLLqwv3EMPuAIyoWRRPGpNI3YnuQugBv
	lJWgwnfYsNqLVI1IoIcCID3PqWO8JYSIqPla3awoscd13oiYmtfL6tZ/E4KFcA==
Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512)
	(Client did not present a certificate)
	(Authenticated sender: peterj)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MB6Wb3xK7z1NRd;
	Mon, 22 Aug 2022 09:29:31 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
Date: Mon, 22 Aug 2022 19:29:27 +1000
From: Peter Jeremy 
To: "Patrick M. Hausen" 
Cc: Ryan Moeller , freebsd-current@freebsd.org
Subject: Re: Beadm can't create snapshot
Message-ID: 
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
 
 
 <1E09DD0A-9F26-4BAD-9CA4-B3593B2DE836@hausen.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: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="jBDau+QjQ3rcRJml"
Content-Disposition: inline
In-Reply-To: <1E09DD0A-9F26-4BAD-9CA4-B3593B2DE836@hausen.com>
X-PGP-Key: http://www.rulingia.com/keys/peter.pgp
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661160572;
	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=XB8k5ylvhz9X8VZw8EJxY3vUpujmMTTQxURNAOpZ/Mo=;
	b=Wejj55kXSX7m5Z2NPsG6Yyb1wBp368DG9WDXfST7PZ7sGdZZy6xMMpStP2oOMedI0M6lzy
	UtAeYVF2cRvk1bCoFAzKPliyiKSOHVlSuCN37viCMKP6IHtspbJC519nk4ZQTVOXzrgfD7
	+d4PG0YLwj2LFauEVlqhV94XmQmaQXigzKzSZqOdRAFMjRTdWTgqzJ5n4GKnkWOOVO2E5E
	A4RbZlPlmm5KcXOD01GmEojDluge7xioIJ2eLKBuL1HnZnyvR9aoqim3E33LAeHYQMHxIg
	/sFYksPtN5asnBR3heJh/bGbZiI0w/yZ4xR4qKLwxUg3NIpRwHHUGlrU1IXhwA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661160572; a=rsa-sha256; cv=none;
	b=B4ovALIpyKbGqvxC1uLABkW+YiFi6iB7cEPlmRUL1nLHzZdVD78/PgIXVKRwqtRjT4wQWO
	q4qfqOZNlG02ueJeBoy1xT0xSwLKa/StU5e6brUIfn86nz5hAm64n7UP4314P8DMtT1V0L
	wBSO0SmEJ2DKb6kMRoe9Zhqwg0r8pyPdlIDu/gcYB/QTFd2oIDjHttEvoO87wR2V2gCX9y
	+hp1bJRLlyzW4ja3yMX1drZZPsfWXeQtQgr6TGg5OKm0SLmIcSaV/HYZg+38wGppivkjud
	QCEDCfy10YTvIi4ZlX2/JiLRBeG52pQo+Od2Gyd1iFMbpZ/jlGAit6hAoXXBKQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--jBDau+QjQ3rcRJml
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-Aug-22 10:56:51 +0200, "Patrick M. Hausen"  wrote:
>> Am 22.08.2022 um 10:45 schrieb Peter Jeremy :
>> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"  wrot=
e:
>>> Isn't beadm retired in favour of bectl?
>>=20
>> 2) "bectl activate" doesn't update /boot/loader.conf so the wrong
>>   root filesystem is mounted.
>
>You mean the vfs.root.mountfrom option? I thought that, too, was deprecate=
d and
>replaced by the bootfs property of the zpool.

I've looking through mailing list archives and searched the 'net and
haven't found anything saying vfs.root.mountfrom is deprecated.
loader(8) mentions that it will fallback to using "currdev" if there's
no root entry in /etc/fstab and vfs.root.mountfrom isn't set.

At the very least, it's an undocumented incompatibility between beadm
and bectl: I can't take an existing system that's using beadm and just
switch to using bectl.

--=20
Peter Jeremy

--jBDau+QjQ3rcRJml
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmMDTHBfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF
QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi
CzTl1w/+Og3WK/JuSZKQtrjB3nAPvBcUbIBsBr34SOiQ9DBkPX5OpZbI1UpbOapb
JUuXQq4H2Q5kETsvSBZAiHXBf1MQXNBCOh/TQu7PtDmZtml9aYaXYzIhiiK5QYVC
dIS1QyoeRb2+rVa10zo3U24hmh0WfCx9QL7HK1lWVfcnl88CjX2NK93rvFnAgHpZ
xRM91hhzf483/rhXVpio7P+7Sh/dN6uxMBmHdWvg+gk8F20r+WunBgZk6HPE6vtg
wBbmORPAQCkhZWIX3yibGa6DjRb92S1Uo8CnOh3RX6Hy+DLMgTyZXGbWRTYxUUGV
+sKaonBTo4UBxq+3tb5e32kcW9S3+5cNiPrBnnyZ1JaIsPD8GAbAEAmjqfG7JsjA
e/cx07PPvP+ECMTdgb68BarbMO2r8fH69kUsGr3vvUrwyPhetplNoQvYul0tMhMa
Cz4nNFG1bLdiHuoRE8BYILfvhXXBU96HZMYxK/Uv936WEmjtGvs6N8AENFEl5sAN
cRiXic2S505z+caDoJtGZ+CYs/FVvROY+ZzqXQBH7Oqt6BLUNt1kUJf7WCJnhw3E
gWcTDcyOYIUUk4+0d5WVLi7gfj+w5Ptj2qTSb0AP5BdzBb+W5eU1TobB2aB7sOk/
/p3H+ZHHVPIMg3YnzCWM9n0WLhQtTGjwjCAXH704pSfB5cBolsg=
=Jhk2
-----END PGP SIGNATURE-----

--jBDau+QjQ3rcRJml--

From nobody Mon Aug 22 10:50:28 2022
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 4MB8K85bNsz4ZJD2
	for ; Mon, 22 Aug 2022 10:50:36 +0000 (UTC)
	(envelope-from SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net)
Received: from bosmailout05.eigbox.net (bosmailout05.eigbox.net [66.96.185.5])
	(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 4MB8K76rMnz3nZy
	for ; Mon, 22 Aug 2022 10:50:35 +0000 (UTC)
	(envelope-from SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net)
Received: from bosmailscan08.eigbox.net ([10.20.15.8])
	by bosmailout05.eigbox.net with esmtp (Exim)
	id 1oQ50t-0005dN-6v
	for freebsd-current@freebsd.org; Mon, 22 Aug 2022 06:50:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=codenetworks.net; s=dkim; h=Sender:In-Reply-To:References:Cc:To:From:
	Subject:MIME-Version:Date:Message-ID:Content-Type:Reply-To:
	Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
	Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
	List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
	 bh=wGLpMd75IAQy4fhMUE9rgkmQR/H8NbWsTGwb2iRRwik=; b=q6JwDtS7dSUzYOYUjtpnrVEzL
	vb79R5jV5KhZGR02Wscl3dpxoSR4KJeMxOZdDlBdpUk4B9HfiLWTgPD9otZQLit2Q6jmFMGXlKLou
	IZ8/bvUA28kct1ZijtVZTYYk/gCT+gL6Xg2tDzEnYp6MdkcOxfyyYWltFuw99HDtMk/SlOYGzPakI
	HvPa/fyb4gHxDm/AxqSR8E8WpqtGBtXvoO56zDO8dLFL5UoFO46OPgU7JCNuOL3MfVSANEfUmyHjz
	D1wtEaOUROYPitzblEKlaiOktkTdKH7xpklSsDSkSa5X4bRuG25/Ei+ebY4Zl7bVqV5kB3rSUBNEX
	1efaqPaoQ==;
Received: from [10.115.3.32] (helo=bosimpout12)
	by bosmailscan08.eigbox.net with esmtp (Exim)
	id 1oQ50s-0005an-Rv
	for freebsd-current@freebsd.org; Mon, 22 Aug 2022 06:50:34 -0400
Received: from bosauthsmtp09.yourhostingaccount.com ([10.20.18.9])
	by bosimpout12 with 
	id AaqX2800G0BkY8i01aqa8R; Mon, 22 Aug 2022 06:50:34 -0400
X-Authority-Analysis: v=2.3 cv=d4VuNSrE c=1 sm=1 tr=0
 a=+tcVrJynzLVJ9yqDAOBWjQ==:117 a=Ek/qOh1uPkKSHvd30yk7rg==:17
 a=biHskzXt2R4A:10 a=-Yl_685HdVUA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=jlvWEfeLAAAA:8
 a=1sOzua4LxArwMXIwefsA:9 a=QEXdDO2ut3YA:10 a=HHGDD-5mAAAA:8
 a=qgVo0UedtaV3ZnT0keEA:9 a=uRggxL1llCQGpSMS:21 a=_W_S_7VecoQA:10
 a=BUduvz6nQKmfCEOu4uBS:22
Received: from cm-81-9-194-73.telecable.es ([81.9.194.73]:27004 helo=[192.168.3.100])
	by bosauthsmtp09.eigbox.net with esmtpa (Exim)
	id 1oQ50p-0001Eb-Hn; Mon, 22 Aug 2022 06:50:31 -0400
Content-Type: multipart/alternative;
 boundary="------------jQz2ee25Zbbc8jL0zN4gkdIG"
Message-ID: <9b89b67a-567d-12e8-ac17-4bb529b9d0e3@codenetworks.net>
Date: Mon, 22 Aug 2022 12:50:28 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Subject: Re: kernel panic during zfs pool import
Content-Language: en-US
From: Santiago Martinez 
To: Toomas Soome 
Cc: freebsd-current 
References: 
 <5F75D096-F28C-436E-B5C0-4A0EFA7A5F3C@me.com>
 
In-Reply-To: 
X-EN-UserInfo: d3bdfab0736480cedf04ed92aaea2ef5:931c98230c6409dcc37fa7e93b490c27
X-EN-AuthUser: sm@codenetworks.net
X-EN-OrigIP: 81.9.194.73
X-EN-OrigHost: cm-81-9-194-73.telecable.es
X-Rspamd-Queue-Id: 4MB8K76rMnz3nZy
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none ("invalid DKIM record") header.d=codenetworks.net header.s=dkim header.b=q6JwDtS7;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of "SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net" designates 66.96.185.5 as permitted sender) smtp.mailfrom="SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net"
X-Spamd-Result: default: False [-2.99 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.993];
	FORGED_SENDER(0.30)[sm@codenetworks.net,SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net];
	R_SPF_ALLOW(-0.20)[+ip4:66.96.128.0/18];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_PERMFAIL(0.00)[codenetworks.net:s=dkim];
	FREEMAIL_TO(0.00)[me.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:29873, ipnet:66.96.128.0/18, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[66.96.185.5:from];
	DKIM_TRACE(0.00)[codenetworks.net:~];
	FROM_NEQ_ENVFROM(0.00)[sm@codenetworks.net,SRS0=flrwfZ=Y2=codenetworks.net=sm@eigbox.net];
	RCVD_COUNT_FIVE(0.00)[5];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[codenetworks.net: no valid DMARC record];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------jQz2ee25Zbbc8jL0zN4gkdIG
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Still the same with current.....(from today).

Opening a PR for it..

Santi


On 8/22/22 10:43, Santiago Martinez wrote:
> Thanks Toommas,
> I compiling current right now and will give it a try, hopefully, will 
> be able to mount and recover the machine.
> Will also open a PR as even if the is any corruption/pool damage it 
> should not panic the machine.
>
> Santi
>
>
> On 8/18/22 21:45, Toomas Soome wrote:
>>
>>
>>> On 18. Aug 2022, at 18:46, Santiago Martinez  
>>> wrote:
>>>
>>> Hi everyone,
>>>
>>> I have a server running 13.1-stable that was powered off 
>>> (gracefully) and now is been powered on again and we have the 
>>> following problem.
>>>
>>> The server boots almost properly, kernel load and when zfs import 
>>> other pools it panic with the following message.
>>>
>>> "panic : Solaris (panic) zfs: adding existent segment to range tree 
>>> (offset=4af2ca9000 size=a0000)".
>>>
>>> if i boot into single user and the pools (most specifically pool01 ) 
>>> is not imported then there is no panic. but as soon as we try to 
>>> import pool01 we get that panic error. it worth mentioning that the 
>>> pool imported/online before.
>>>
>>> Have two question:
>>>
>>> *    How i can tell to not import the pool automatically during boot 
>>> so sever is not stuck in a boot/panic/reboot infinite loop?
>>
>> removing zpool.cache should do. unfortunately, you would need to boot 
>> alternate root (usb/cd/net) for that.
>>
>>>
>>> *    Anybody know what this panic means?
>>>
>>
>> in short - bug. I’d try to boot current and import pool there - maybe 
>> the issue is fixed in current…
>>
>> rgds,
>> toomas
>>
>>> Thanks in advance!
>>>
>>> Santi
>>>
>>>
>>>
>>
--------------jQz2ee25Zbbc8jL0zN4gkdIG
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Still the same with current.....(from today).

    
Opening a PR for it.. 

    

    
Santi

    


    

    
On 8/22/22 10:43, Santiago Martinez
      wrote:

    

    

      
      Thanks Toommas, 

      I compiling current right now and will give it a try, hopefully,
      will be able to mount and recover the machine. 

      Will also open a PR as even if the is any corruption/pool damage
      it should not panic the machine.

      
Santi

      


      

      
On 8/18/22 21:45, Toomas Soome wrote:

      

      

        
        

        


          

            
On 18. Aug 2022, at 18:46, Santiago Martinez
              <sm@codenetworks.net>
              wrote:

            

            

              
Hi everyone,

                

                I have a server running 13.1-stable that was powered off
                (gracefully) and now is been powered on again and we
                have the following problem.

                

                The server boots almost properly, kernel load and when
                zfs import other pools it panic with the following
                message.

                

                "panic : Solaris (panic) zfs: adding existent segment to
                range tree (offset=4af2ca9000 size=a0000)".

                

                if i boot into single user and the pools (most
                specifically pool01 ) is not imported then there is no
                panic. but as soon as we try to import pool01 we get
                that panic error. it worth mentioning that the pool
                imported/online before.

                

                Have two question:

                

                *    How i can tell to not import the pool automatically
                during boot so sever is not stuck in a boot/panic/reboot
                infinite loop?

              

            

          

          


          

          
removing zpool.cache
              should do. unfortunately, you would need to boot alternate
              root (usb/cd/net) for that.

          

          

            

              


                *    Anybody know what this panic means?

                

              

            

          

          


          

          
in short - bug. I’d try to boot current and import pool
            there - maybe the issue is fixed in current…

          


          

          
rgds,

          
toomas

          

          

            

              
Thanks in advance!

                

                Santi

                

                

                

              

            

          

        

        

      

    

  


--------------jQz2ee25Zbbc8jL0zN4gkdIG--

From nobody Mon Aug 22 11:24:48 2022
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 4MB95516Kbz4ZNKs
	for ; Mon, 22 Aug 2022 11:25:13 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2018.outbound.protection.outlook.com [40.92.96.18])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MB9533WdFz3r27
	for ; Mon, 22 Aug 2022 11:25:11 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=H55ZR+GHCd2y71+Y+MgpgSP52JGQSQl9K3j3lDBgt0QHX6PlJjKBNBCxFph/cp+fpsR+ekvbkjw6jys4zsCTYjqau28w4a6Bg5xCosgBNun4HCuEj2Rncd2jLQvvfca9J6JpF4cso/tUKMb1zten/2THEmXH5jOJDBVZohuVCMO01YnPUo9hDK5VOJ0cLysmO9j32ute0spBgYq3MsXhCy/XT+7TcOGHFRjN7VkDzvZzEIzL2ZWeJJFBjztd4VDYFNHjn5IDEPCqffgdkSggE+tPBrUIhc6HQrqDVoJVCWa9GzrLUfMOFkJK00twx+Ha5iqzfBqKX3Fao9HgWTgd6w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=BCCZjAlsdHrXqBeht8ZyZR+sZZ1r9VcoVUnKVVnt9BE=;
 b=n1aCLoaVt6ZhQ9ZqvexB+MbpPpEKd7UkhlS7z9Pvd/S3QC4FEGyNvOCuvzLi22armUVIZP1o/OWzZg0YPou43iPa0DxXeNZEqVGXWzswsXwdkS+AGJZAqB0nyIIJzMr4C9Jh+sOPcns5LaiJNKzJix5Gbgx8Sdj0/gdB2eHXPqGjZzQs0E8a+idJmHhyLtVluDAuNaHlqr6v5HdqkKgxsC0vE4ldymAvEeoTLXcvuhAm0qmK84g8LrdR8pXcoKCc1MpQH9kujyR7hpZAbVw9KAiIrdcK1UsQC0W6zaoPcLCktCW4OR8536q/F+4IM/SiPwR2YMDBH7Tr8iaOd/vi/w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=BCCZjAlsdHrXqBeht8ZyZR+sZZ1r9VcoVUnKVVnt9BE=;
 b=g9+v5PMtWQbgZpDDiRyQch7WRIH7go5KjDF6apQ5QBmtMZnT/KsKef0llwmr3qbHnSuEyvdn2WKwEcDET+PRPceIBpQ6f8iLT4szWXtHZH3EQv70OtXpMTn6A4gHzQT5w8GEE9jijAB1uQ+A0rLPOSaBGBbcXxdiQEriNdVYXmWLIsGkKzjiJCft8OGlFl7YYWTJwKWLlOHQ/fj0Hc9zvfjg+n7gh7wTcLkNEBoAYeNeVln8l9SPsd7RLyuvwve3bTNsaza1rqEJ+wZRxz3ydp6GEqoVsKOn8MoJjgvA0A2GaEoP/NONtefWgYxXIE//UMhjdrPUXZi56KlEyxG1bw==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by ROAP284MB0334.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:3c::6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5546.19; Mon, 22 Aug 2022 11:25:07 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2%8]) with mapi id 15.20.5546.022; Mon, 22 Aug 2022
 11:25:07 +0000
Date: Mon, 22 Aug 2022 08:24:48 -0300 (-03)
From: Ivan Quitschal 
To: freebsd-current@freebsd.org
Subject: BitchX segfault in libc.so.7
Message-ID:
 
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-TMN: [AWjJt/B0rQetEskWZJb31MPgcE02sptb]
X-ClientProxiedBy: CP5P284CA0002.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:95::7) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <7cb355c-9a8b-d995-beb6-b8c35fdb944@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 236e9f21-75d0-4d82-36fa-08da8430f79b
X-MS-TrafficTypeDiagnostic: ROAP284MB0334:EE_
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	s9AvxTI1qAjdGnC6JD2SPTHKShbOCW9D8Cg7KYRBP+ubFXAUzZ2g4SK36MRVXcQ20gBy0hqVv7JAKhs9c/eC+pEQ08I8qcA+jTp7dKA6uZzTtHXaCeIdYVGSFIob1osqq4XMuYYeiLF/2qppRiatq7WkYraV8gs3+TEQP6/4ZdiVMzoosvzuxfqgIPVO9ZZ2ENXh9Q1fdGm7cVcvLv/4LtjuvqcEgrLnzDJfSeyk/tJVTNrJ2EQoTVYyJy5K3EkO1XUIiikeMRvZWW9sj0MuHmYF2fkgU/3ueYmc1q4INVSpEJsd54ngFycQDv8WFmTG105Sj4RRf6ijPrE+DQnCNSYURloPtRAtLMlmhSn0445dNjNUwweHgLK9HfZsjO7yczxRFWVLzSYbqDN+Af7ntZxqj5a8ctnzcCc24vA0PKyycm9HwOch3c6Li53/r5qqZIbFd4Aguz+QdV98fLsNGRMGGYGgbI6lUosiBYE3K27jZhI1di7lYeOjTKpGre01uvTjUwjLcwhXQ6kSgX7r48jBG4riffZtF64udDeYaOvM+aow49UABoSSO2d3P4HZEtpIEC4h8xe5tqDeFBxbvpTSwQv4ucgzquRvZQzvamZAAzyE8KRLMUSpFs1wTRf35y/Nq+PL9oZ/wlqmUNzC8w==
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?swg2T2YpfRly7CywBVCEadK3Q5VsBzJGfB4oJEQEnDgWq+7Qu7T1laxW43FG?=
 =?us-ascii?Q?+Ry6o+ADimE7YNmyNdNPhXAYyIJf8idIwMfyrGZqqIh3RkR+mg3lCosDU12Q?=
 =?us-ascii?Q?9eB0xMzLIlS3kN8c3+QcgF1TIOcQcwXBg8+q0KtKjOs0FVlmPWFSaXdz0OEQ?=
 =?us-ascii?Q?Rfc9Ii5e7/Bf7tB9tfP19K+7E5bHTX27bCEwPytnY1gd6y3DY2YN5DxFHEUo?=
 =?us-ascii?Q?pbI1lZHZrD4v89EKbqgCw5Bc6A4eijNJ5CbyOs68oP7LFH/o3muK/oJZYg3O?=
 =?us-ascii?Q?uhoI+eXKM2SlgFkeZaDRSMAsdlRSFzgZfL/dO+DeQlr1xgcbvk5iV6pCBY6p?=
 =?us-ascii?Q?Wgcb+IxvUtoeWKsdFR5lDhcUit919pGEMiAff2if+87wCxmQpYy5aOt8Dth+?=
 =?us-ascii?Q?43c4xRqWEG+59iqDDcfIHlh8vRqKnPsFmmg4Zta0sZuJPb2h/fjAom4T9lLc?=
 =?us-ascii?Q?QXQNCMdHOXex4LuvYEgBz2QYX2Obtsym5u3yDa9Tl+8BQOO5PKK7mkCFZVwI?=
 =?us-ascii?Q?tsV0XrrH568WP3ZQQCDa384KRu5yM/wvkSIbWRjZYasWBRyhYLAkByu2PWtN?=
 =?us-ascii?Q?aKBtUUwaGQauGyht9673FEmP0golw0Ss0S4KWot6g0wWifbmsR5/fhP0BmSk?=
 =?us-ascii?Q?BwwHf78lg7hq/YpPLB6XArwqiIdfVEpoJ0GxesWGaBmJC2TMlwF6H+sHPviO?=
 =?us-ascii?Q?PQGYKmoNsn7aSY7LyCR1jCXkoCm9IpnCy6Mfy/WT+lsmvq2y1RaKCYjg+pM2?=
 =?us-ascii?Q?1Vljk6jlebCf/MjIazxOzoFTe5AENE/d+PLWrsDtTdF8JEWccbc1tHbOgRYs?=
 =?us-ascii?Q?4uT3rFrtXHdFBOmrG1COf423UnRJ1LkET8ZzoXg+lq6qZoU1SjRoDIAVN4T6?=
 =?us-ascii?Q?i1e0p0uFaMkBA7e7YSroM4tCaabHWol9LdThsGThaTI5Wx2XpRuG4vha4IV5?=
 =?us-ascii?Q?v9uEJJya/ioxHlrWEBPq3AassV7d6uJYRrRLMnAuyyVA9OB+dXA2a7aGG/mf?=
 =?us-ascii?Q?GQgR3gnmghrdEDpCQ4b1YougMICqn0Oltvlui1FL0UtyrCDCr/OegYrzt8Fy?=
 =?us-ascii?Q?YfZZECKwk4+wv9lkBbCFPcY/wxAcJIxu+H/3IDwLY/AF07OurEc7MWyy/E8v?=
 =?us-ascii?Q?idjqu41Vc14/Zh2qTiYykJgTdiP5mbnhHD5jmvLnaI9a3S1FFBcfdcW6JFd4?=
 =?us-ascii?Q?XD8LWUIdc75F1Ki+Cf9l1F8x5M2rWmri2nN1FuTcgbIPkz1issVw1WNp3SQy?=
 =?us-ascii?Q?T8a0HKEsRkRN8i3QeRtn8J2qS7VoeAgBFdXjMoRJAg=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 236e9f21-75d0-4d82-36fa-08da8430f79b
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Aug 2022 11:25:07.8317
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB0334
X-Rspamd-Queue-Id: 4MB9533WdFz3r27
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=g9+v5PMt;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.18 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.40 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-0.99)[-0.994];
	NEURAL_HAM_SHORT(-0.98)[-0.983];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	NEURAL_HAM_MEDIUM(-0.42)[-0.424];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	TO_DN_NONE(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.96.18:from];
	DKIM_TRACE(0.00)[hotmail.com:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[hotmail.com];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

hi All

I know this is not the ports list , but the problem only happens in CURRENT 
anyway

BitchX from ports (at least for me and i've installed freebsd current several 
times here with the same result) uses CC to compile and in freebsd CURRENT its 
getting segfault as soon as BitchX  connects to any network.

I tracked the core on debugger and the fault always happens on libc7

Now using the same source code downloaded in work/ dir in ports, if you use GCC 
then it works just fine, which is what i did here with my own BitchX

just a heads up for the ports guys

thanks

--tzk


From nobody Mon Aug 22 12:10:00 2022
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 4MBB4y0tCnz4ZT6p
	for ; Mon, 22 Aug 2022 12:10:10 +0000 (UTC)
	(envelope-from SRS0=7PgN=Y2=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 4MBB4w5Gz1z3w6b;
	Mon, 22 Aug 2022 12:10:08 +0000 (UTC)
	(envelope-from SRS0=7PgN=Y2=klop.ws=ronald-lists@realworks.nl)
Date: Mon, 22 Aug 2022 14:10:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1661170201;
	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=uvIpA5dZSZvyw3oYbmuE8M0bsBxdviwdgQqjbkothWw=;
	b=oUoRFbPHzYGy+fSGLgUHyEmm5tnBJhrNSpaiaUtt4D8OdHKZvqlGeqVGrQaTw8TcQ+0G6r
	/UklSlrHtUR+pXfOy7nWxgWSIUjzO4rk+4UfpWsoggaF0wvZRWJ2AS0vYlr5e/XSL5mi47
	wRzvLR1KkaLv+0BNnah9djR+dULXK5kGNq4ImSHyv/+rR+bjmXxYEkecWA5yEsM1OOj040
	TJAWEyJ4QFEZ42TMEJ3zBmRG59kjTUyIG4qjGSRVPKEEVIKoEuOdSnvjyL/SlgUgBEm6/N
	VacOVAuM6cEm0sOA1X/rZgbwn7zC3NgFw4YeZOShWPUqq/aTs2Y+fQb4gk1oEA==
From: Ronald Klop 
To: Peter Jeremy 
Cc: freebsd-current@freebsd.org, Ryan Moeller ,
	"Patrick M. Hausen" 
Message-ID: <623263165.219.1661170200563@localhost>
In-Reply-To: 
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
 
 
Subject: Re: Beadm can't create snapshot
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_218_843763257.1661170200558"
X-Mailer: Realworks (620.114)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4MBB4w5Gz1z3w6b
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=oUoRFbPH;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=7PgN=Y2=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=7PgN=Y2=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.19 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-0.99)[-0.995];
	MID_RHS_NOT_FQDN(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=7PgN=Y2=klop.ws=ronald-lists@realworks.nl];
	R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_COUNT_ZERO(0.00)[0];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	FROM_HAS_DN(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=7PgN=Y2=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_218_843763257.1661170200558
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 
Van: Peter Jeremy 
Datum: maandag, 22 augustus 2022 10:45
Aan: "Patrick M. Hausen" 
CC: Ryan Moeller , freebsd-current@freebsd.org
Onderwerp: Re: Beadm can't create snapshot
> 
> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"  wrote:
> >Isn't beadm retired in favour of bectl?
> 
> bectl still has a number of bugs:
> 1) The output from "bectl list" is in filesystem/bename order rather
>    than creation date order.  This is an issue if you use (eg) git
>    commit hashes as the name.
> 2) "bectl activate" doesn't update /boot/loader.conf so the wrong
>    root filesystem is mounted.
> 
> That said "bectl create" appears to be a workable replacement for
> "beadm create" and avoids the current "'snapshots_changed' is
> readonly" bugs.
> 
> -- 
> Peter Jeremy
> 
> 
> 
>  


Hi,

>From man bectl:
     activate [-t | -T] beName
               Activate the given beName as the default boot filesystem.  If
               the -t flag is given, this takes effect only for the next boot.
               Flag -T removes temporary boot once configuration.  Without
               temporary configuration, the next boot will use zfs dataset
               specified in boot pool bootfs property.

So it uses the bootfs property instead of loader.conf. If beadm used a different mechaniscm it would by nice to mention that in the HISTORY section of the bectl man page.

Regards,
Ronald.
 
------=_Part_218_843763257.1661170200558
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

 

Van: Peter Jeremy <peterj@freebsd.org>

Datum: maandag, 22 augustus 2022 10:45

Aan: "Patrick M. Hausen" <pmh@hausen.com>

CC: Ryan Moeller <freqlabs@freebsd.org>, freebsd-current@freebsd.org

Onderwerp: Re: Beadm can't create snapshot









On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen" <pmh@hausen.com> wrote:

>Isn't beadm retired in favour of bectl?



bectl still has a number of bugs:

1) The output from "bectl list" is in filesystem/bename order rather

   than creation date order.  This is an issue if you use (eg) git

   commit hashes as the name.

2) "bectl activate" doesn't update /boot/loader.conf so the wrong

   root filesystem is mounted.



That said "bectl create" appears to be a workable replacement for

"beadm create" and avoids the current "'snapshots_changed' is

readonly" bugs.



-- 

Peter Jeremy





 











Hi,



>From man bectl:

     activate [-t | -T] beName

               Activate the given beName as the default boot filesystem.  If

               the -t flag is given, this takes effect only for the next boot.

               Flag -T removes temporary boot once configuration.  Without

               temporary configuration, the next boot will use zfs dataset

               specified in boot pool bootfs property.



So it uses the bootfs property instead of loader.conf. If beadm used a different mechaniscm it would by nice to mention that in the HISTORY section of the bectl man page.



Regards,

Ronald.

 
------=_Part_218_843763257.1661170200558--

From nobody Mon Aug 22 14:56:47 2022
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 4MBFnR4Vg9z4Zqxr
	for ; Mon, 22 Aug 2022 14:56:59 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MBFnQ43T9z3Bqs
	for ; Mon, 22 Aug 2022 14:56:58 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mx1.sbone.de (Postfix) with ESMTPS id A42998D4A178
	for ; Mon, 22 Aug 2022 14:56:50 +0000 (UTC)
Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPS id B15875C3A831
	for ; Mon, 22 Aug 2022 14:56:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024)
	with ESMTP id 1Ht0CAiEWFBW for ;
	Mon, 22 Aug 2022 14:56:48 +0000 (UTC)
Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPSA id 562D95C3A82F
	for ; Mon, 22 Aug 2022 14:56:48 +0000 (UTC)
Date: Mon, 22 Aug 2022 14:56:47 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: current@freebsd.org
Subject: init (/rescue/sh) died
Message-ID: 
X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-Rspamd-Queue-Id: 4MBFnQ43T9z3Bqs
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_NA(0.00)[zabbadoz.net];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_NONE(0.00)[];
	ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE];
	RCVD_COUNT_FIVE(0.00)[5];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

I am trying to get some arm64 up and running a bit but cannot use
loader. I have an MD_ROOT embedded in the kernel with /rescue on it.
I set INIT_PATH=/rescue/sh .

However that doesn't seem to work:

start_init: trying /rescue/sh
init died (signal 0, exit 0)
panic: Going nowhere without my init!

Anyone any ideas?

/bz

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Mon Aug 22 15:11:43 2022
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 4MBG5l5Xgdz4Zs4C
	for ; Mon, 22 Aug 2022 15:11:07 +0000 (UTC)
	(envelope-from kevans@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MBG5l56Jqz3Dnr;
	Mon, 22 Aug 2022 15:11:07 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661181067;
	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/WTkUZWX67xuoPtQJTdCun5P9dNXfgp25kOa/aa+M4=;
	b=kSOk9l5vfS6NSWEL1qZYJ4E3eoK8HkYPSS3Dbc8qsIasyZelxpwxvgLMnzDIgfnkayel3q
	tjYWZlxMwz+cM1gig0RfUN7YamGdAxbXGse7ay8vMZYNrGj5EgKO2QAdmAcWyMeck3VC6X
	NBuAkwZp3+X8IgBMWM0ICGfqPTkY4HyuaYX7e/6vAlrAMycBq6PXysV/MZdywQlxR+Vw6p
	ZPgA5+paTynhT86QxB71TQx2rFtjRR2bjUjJG9KaWgU3DGYMfx6E/DkEioUxRF+8H4U4P+
	m4EBEt4nW7gY0fLh6FMAd1rQxfcDBrSWUv7j+9P6VDZGlbjdpdeYZnuaDBuSUw==
Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: kevans)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MBG5l3wPHz1SDG;
	Mon, 22 Aug 2022 15:11:07 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
Received: by mail-qt1-f178.google.com with SMTP id h21so8092014qta.3;
        Mon, 22 Aug 2022 08:11:07 -0700 (PDT)
X-Gm-Message-State: ACgBeo1offAPyYvSXsbUx8LlvU5jD9u+1LJp+AuLGDAed3rknMMwDcaY
	Q3rPrWStZ0uKITAEBXaexgkEm5iX/EeT0ZPkclc=
X-Google-Smtp-Source: AA6agR7SrptfLst14op+nKfdBdcrDRcNRJXdaCgv3h2GT8qJqv4NXaR8sFIRCmY3LR57zt6tu354NIlt8jB5CBVBv0Y=
X-Received: by 2002:a05:622a:11d6:b0:343:5e19:7488 with SMTP id
 n22-20020a05622a11d600b003435e197488mr15829489qtk.476.1661181067128; Mon, 22
 Aug 2022 08:11: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
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org> 
  <623263165.219.1661170200563@localhost>
In-Reply-To: <623263165.219.1661170200563@localhost>
From: Kyle Evans 
Date: Mon, 22 Aug 2022 08:11:43 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Beadm can't create snapshot
To: Ronald Klop 
Cc: Peter Jeremy , freebsd-current@freebsd.org, 
	Ryan Moeller , "Patrick M. Hausen" 
Content-Type: text/plain; charset="UTF-8"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661181067;
	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/WTkUZWX67xuoPtQJTdCun5P9dNXfgp25kOa/aa+M4=;
	b=urjXj+DsyLWNPH828TNnFTc0mZpFolvsyvwbFYWkKEyKoqvB8yH2kN5QaWd6vvxwPp1+xn
	SJ7SPErO15Yzlq6RUPGRnGckoPcONAN4zMQtFyE0e9iW+NXf0gt2haHEJ+uK+NIFFGmr7B
	uW6YJ7CnDMDt71JBYGrq9UDGL2yNC1DcMa1U7vGs8KF8jpB1PnVRuZr3fOUWyQ3FzMUbE2
	Cf77Ghnd8LZ048SwPVLt2uZEYJeSpazHeapblltgU4uUfJNZllQIgpJTtCisG5YBwXJ1hq
	Dp65LVQjDDgnPqTXXgCs4LCmm0zv1ZMJhdYusgPVAR3EAeK644M6aYP2hc9Ghw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661181067; a=rsa-sha256; cv=none;
	b=C/eKt/M29a3NDcEK3XucP3qRjlnt36JmBZAGHhu3fQJhZK1rvCYBrSR2P62Iu6szSAeujM
	bnm3MCPGK5SjO30KpTCbRnYPjAujaLQNMsIPfzTt5m1U9mt9HCA9/Fn3dCkcK6K6LzFmFa
	lLn0NhOiBF738XXZg1YJuJgwuGji+u7YLuzbXaTpzRu0I2+AbUZSorR8+Ufp8U+dWV5WOk
	N0mecEhBdLTh0zt/aQzyW1MdvnSbqMyXLMt33TU/QBRNKq6kEATlpnkuKgF8BFpjSyOlU0
	DFL1CmGOhZNwH9p+on9MbEmgZ553OZCpRtSS3nAgwSx/dNChilmFKMY/M5Hdcg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Aug 22, 2022 at 5:10 AM Ronald Klop  wrote:
>
>
>
> Van: Peter Jeremy 
> Datum: maandag, 22 augustus 2022 10:45
> Aan: "Patrick M. Hausen" 
> CC: Ryan Moeller , freebsd-current@freebsd.org
> Onderwerp: Re: Beadm can't create snapshot
>
> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"  wrote:
> >Isn't beadm retired in favour of bectl?
>
> bectl still has a number of bugs:
> 1) The output from "bectl list" is in filesystem/bename order rather
>    than creation date order.  This is an issue if you use (eg) git
>    commit hashes as the name.
> 2) "bectl activate" doesn't update /boot/loader.conf so the wrong
>    root filesystem is mounted.
>
> That said "bectl create" appears to be a workable replacement for
> "beadm create" and avoids the current "'snapshots_changed' is
> readonly" bugs.
>
> --
> Peter Jeremy
> ________________________________
>
>
>
>
> Hi,
>
> From man bectl:
>      activate [-t | -T] beName
>                Activate the given beName as the default boot filesystem.  If
>                the -t flag is given, this takes effect only for the next boot.
>                Flag -T removes temporary boot once configuration.  Without
>                temporary configuration, the next boot will use zfs dataset
>                specified in boot pool bootfs property.
>
> So it uses the bootfs property instead of loader.conf. If beadm used a different mechaniscm it would by nice to mention that in the HISTORY section of the bectl man page.
>

I was not aware that beadm touches loader.conf, but I find that
slightly horrifying. I won't personally make bectl do that, but I
guess I could at least document that it doesn't...

From nobody Mon Aug 22 15:16:52 2022
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 4MBGDW6Tqkz4ZstT
	for ; Mon, 22 Aug 2022 15:16:59 +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 4MBGDW1KBVz3GDn
	for ; Mon, 22 Aug 2022 15:16:59 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 27MFGqcK009574
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 22 Aug 2022 18:16:55 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 27MFGqRl009573;
	Mon, 22 Aug 2022 18:16:52 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Mon, 22 Aug 2022 18:16:52 +0300
From: Konstantin Belousov 
To: "Bjoern A. Zeeb" 
Cc: current@freebsd.org
Subject: Re: init (/rescue/sh) died
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=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home
X-Rspamd-Queue-Id: 4MBGDW1KBVz3GDn
X-Spamd-Bar: -
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
X-Spamd-Result: default: False [-1.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	NEURAL_SPAM_MEDIUM(0.20)[0.196];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	R_SPF_SOFTFAIL(0.00)[~all];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	HAS_XAW(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Aug 22, 2022 at 02:56:47PM +0000, Bjoern A. Zeeb wrote:
> Hi,
> 
> I am trying to get some arm64 up and running a bit but cannot use
> loader. I have an MD_ROOT embedded in the kernel with /rescue on it.
> I set INIT_PATH=/rescue/sh .
> 
> However that doesn't seem to work:
> 
> start_init: trying /rescue/sh
> init died (signal 0, exit 0)
> panic: Going nowhere without my init!
> 
> Anyone any ideas?

Kernel does not set up the standard file descriptors for stdin/out/err
for init.  When you try to directly exec /rescue/sh (or /bin/sh), it cannot
perform any io.

From nobody Mon Aug 22 15:56:05 2022
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 4MBH5t0FY5z4Z0V9
	for ; Mon, 22 Aug 2022 15:56:18 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MBH5s3BLvz3LgY
	for ; Mon, 22 Aug 2022 15:56:17 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe35.google.com with SMTP id 190so3380050vsz.7
        for ; Mon, 22 Aug 2022 08:56:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=1Q4kixV3PmPKjE7w30iG7pUNC86hWYrUEXJnd3fOaPU=;
        b=YSho0awrrHZ7kekupn6WPzoM1y8KqQ27VGoGPOXFA/OqOrxIXbK3tNBzpqyDQGZf8E
         85BHzDvNvND1w93z8Zzhtu39aa3FI3FG1w3ztBG0brVmGKg81D//pnQVzweqHDkYSNsE
         9wcrcBTuAnE4uL/8Z5PMXZo7qz8eqAwLUI6q52O62wfFCG3mGgiL9mOuS4KwIuXVxyrF
         skndV/1+Fg4uGCjWK/9Pq9Jx+Vhg+JsSHN/DHm7insTeewJcV9uxR4y0Kt08efQcU0i7
         i5XQ5J64xTVeaKIy/VMhrd/VEYC/aI3VCOf2Qe5Pn+cLdPqw4YxaJf2JtR7E0g5PoHTJ
         /k9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=1Q4kixV3PmPKjE7w30iG7pUNC86hWYrUEXJnd3fOaPU=;
        b=2svrkwVzZJ9/mxEXhWOxkZTdRuyRXltLWxXq6hb7GnqOPjsE0uhPNNEy65PFYHqnhJ
         aXNpNr/wJHNbz+JQ1rpRP72ct4iQFaAc3J4CTtH706Dqq1tmtlF7o03rVcbVlg1aVpkr
         yD8Mb6wXFv1oun8tTnol/1Ae2ALulIWpyYVMF2PUS1we/nZbmhLyeHIE70POgZwo7ISu
         vjfsFGOFsIEfIEpwqSIwIIxDR1FtQln73zEqYZa7WcKm2sN7TJbwUtkfBNErpa42uPQz
         Non5GB0hpvRGYZgCtRrXdQEsIr0Q8otkGktZdZsqW8Mhtz6+uecncLwiAR+BDQBZr88B
         NfWQ==
X-Gm-Message-State: ACgBeo3WQj773n+aclWlgFLuoDyQamqE7EUh2ludrFDyvNTV8xTMhwge
	mi7Q+U1NeT+x4zfCWShm5XpMiuLNQhxFf98UN2aa0w==
X-Google-Smtp-Source: AA6agR7vpbPfAoNRodH2KjjdmrYnPudWo0MG8VM4UypcoOhknMEWohf60susjZzOF7931lvpr6sPYUN39yx2NwcZfH0=
X-Received: by 2002:a67:ac45:0:b0:388:a1ff:7e89 with SMTP id
 n5-20020a67ac45000000b00388a1ff7e89mr7804936vsh.42.1661183776488; Mon, 22 Aug
 2022 08:56:16 -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, 22 Aug 2022 09:56:05 -0600
Message-ID: 
Subject: Re: init (/rescue/sh) died
To: Konstantin Belousov 
Cc: "Bjoern A. Zeeb" , FreeBSD Current 
Content-Type: multipart/alternative; boundary="000000000000e791b205e6d67c50"
X-Rspamd-Queue-Id: 4MBH5s3BLvz3LgY
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=YSho0awr;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e35) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.99 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.990];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e35:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e791b205e6d67c50
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 22, 2022 at 9:17 AM Konstantin Belousov 
wrote:

> On Mon, Aug 22, 2022 at 02:56:47PM +0000, Bjoern A. Zeeb wrote:
> > Hi,
> >
> > I am trying to get some arm64 up and running a bit but cannot use
> > loader. I have an MD_ROOT embedded in the kernel with /rescue on it.
> > I set INIT_PATH=/rescue/sh .
> >
> > However that doesn't seem to work:
> >
> > start_init: trying /rescue/sh
> > init died (signal 0, exit 0)
> > panic: Going nowhere without my init!
> >
> > Anyone any ideas?
>
> Kernel does not set up the standard file descriptors for stdin/out/err
> for init.  When you try to directly exec /rescue/sh (or /bin/sh), it cannot
> perform any io.
>

Agreed. init does lots of magic, in addition to setting up stdin/out/err
(like
deal with process groups, etc). /bin/sh doesn't do any of that magic, so it
can't possibly work as init (PID 1).

Your best bet is to boot -s (RB_SINGLE in the kernel boot_single=yes in the
boot loader). You'd think you'd be able to symbolically link /etc/rc to
/rescue/sh,
but that will result in sh trying to execute /rescue/sh as a shell script
and no good
can come from it. I've had luck with "echo sh > $DESTDIR/etc/rc;
chmod +x $DESTDIR/etc/rc" in the past, but I haven't tried that trick in
ages...
The simple equivalent to a tmp file does work.

Warner

--000000000000e791b205e6d67c50
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Aug 22, 2022 at 9:17 AM Konst=
antin Belousov <kostikbel@gmail.c=
om> wrote:

Cc: Ryan Moeller , freebsd-current@freebsd.org
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
 
 
 <1E09DD0A-9F26-4BAD-9CA4-B3593B2DE836@hausen.com>
 
From: Andriy Gapon 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MBHHb2pQ8z3N7h
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 217.70.183.199 is neither permitted nor denied by domain of avg@FreeBSD.org) smtp.mailfrom=avg@FreeBSD.org
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.199:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[217.70.183.199:from];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[avg];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-08-22 12:29, Peter Jeremy wrote:
> On 2022-Aug-22 10:56:51 +0200, "Patrick M. Hausen"  wrote:
>>> Am 22.08.2022 um 10:45 schrieb Peter Jeremy :
>>> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"  wrote:
>>>> Isn't beadm retired in favour of bectl?
>>>
>>> 2) "bectl activate" doesn't update /boot/loader.conf so the wrong
>>>    root filesystem is mounted.
>>
>> You mean the vfs.root.mountfrom option? I thought that, too, was deprecated and
>> replaced by the bootfs property of the zpool.
> 
> I've looking through mailing list archives and searched the 'net and
> haven't found anything saying vfs.root.mountfrom is deprecated.
> loader(8) mentions that it will fallback to using "currdev" if there's
> no root entry in /etc/fstab and vfs.root.mountfrom isn't set.

It's not deprecated, but it's a manual override of a _normal_ ZFS boot flow.
If you mount root via fstab or you override it via vfs.root.mountfrom, 
then you should know what you do and why.

> At the very least, it's an undocumented incompatibility between beadm
> and bectl: I can't take an existing system that's using beadm and just
> switch to using bectl.

Yeah, but I would blame beadm for doing things in a backwards fashion.

-- 
Andriy Gapon


https://standforukraine.com
https://razomforukraine.org


From nobody Mon Aug 22 18:29:04 2022
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 4MBLVH1Z32z4ZLDK
	for ; Mon, 22 Aug 2022 18:29:11 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MBLVG2cp4z3bJ7
	for ; Mon, 22 Aug 2022 18:29:10 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mx1.sbone.de (Postfix) with ESMTPS id E31778D4A178;
	Mon, 22 Aug 2022 18:29:07 +0000 (UTC)
Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPS id 281E65C3A831;
	Mon, 22 Aug 2022 18:29:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024)
	with ESMTP id vpt_O9N9PYj6; Mon, 22 Aug 2022 18:29:05 +0000 (UTC)
Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPSA id 5CCD15C3A82F;
	Mon, 22 Aug 2022 18:29:05 +0000 (UTC)
Date: Mon, 22 Aug 2022 18:29:04 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: Warner Losh 
cc: Konstantin Belousov , 
    FreeBSD Current 
Subject: Re: init (/rescue/sh) died
In-Reply-To: 
Message-ID: 
References:   
X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Rspamd-Queue-Id: 4MBLVG2cp4z3bJ7
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131];
	MIME_GOOD(-0.10)[text/plain];
	TO_DN_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[zabbadoz.net];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE];
	RCVD_COUNT_FIVE(0.00)[5];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 22 Aug 2022, Warner Losh wrote:

Hi,

> On Mon, Aug 22, 2022 at 9:17 AM Konstantin Belousov 
> wrote:
>
>> On Mon, Aug 22, 2022 at 02:56:47PM +0000, Bjoern A. Zeeb wrote:
>>> Hi,
>>>
>>> I am trying to get some arm64 up and running a bit but cannot use
>>> loader. I have an MD_ROOT embedded in the kernel with /rescue on it.
>>> I set INIT_PATH=/rescue/sh .
>>>
>>> However that doesn't seem to work:
>>>
>>> start_init: trying /rescue/sh
>>> init died (signal 0, exit 0)
>>> panic: Going nowhere without my init!
>>>
>>> Anyone any ideas?
>>
>> Kernel does not set up the standard file descriptors for stdin/out/err
>> for init.  When you try to directly exec /rescue/sh (or /bin/sh), it cannot
>> perform any io.
>>
>
> Agreed. init does lots of magic, in addition to setting up stdin/out/err
> (like
> deal with process groups, etc). /bin/sh doesn't do any of that magic, so it
> can't possibly work as init (PID 1).
>
> Your best bet is to boot -s (RB_SINGLE in the kernel boot_single=yes in the
> boot loader). You'd think you'd be able to symbolically link /etc/rc to
> /rescue/sh,
> but that will result in sh trying to execute /rescue/sh as a shell script
> and no good
> can come from it. I've had luck with "echo sh > $DESTDIR/etc/rc;
> chmod +x $DESTDIR/etc/rc" in the past, but I haven't tried that trick in
> ages...
> The simple equivalent to a tmp file does work.

/rescue/init was simply "hanging" on earlier boots which is why I
had initially switche dto sh.

Here's a few things I did overall:
- disable GDB in kernel config (it gave 2 lines of jitterish on
   initial kernel printf lines before Copyrights.
- Added bootargs = FreeBSD:-vs to the chosen section in FDT
   given I cannot have loader (no EFI); the guard trick is nice if you
   know about it ;)
- Removed my previous env file I had added to the kernel to set
   tunables.
- linked /bin/sh to /rescue/sh
- put a printf "hello world\n"; exit 1 in the top of /etc/rc just in
   case -s wouldn't work
- changed INIT_PATH=/rescue/init

Got a sh and can run sysctl and dmesg and type echo * in /rescue :)
Even reboot works :)

Now that basic netbooting and user space work I can start adding SoC
drivers bit by bit over the next weeks/months :)  That'll be a lot
more unfun.

Thanks you two!  Along with help from Andy earlier this made my day!

Lots of joy!
/bz

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Mon Aug 22 21:51:03 2022
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 4MBQzS5mn5z4ZmHJ
	for ; Mon, 22 Aug 2022 21:51:16 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MBQzR4xY0z3stm
	for ; Mon, 22 Aug 2022 21:51:15 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe29.google.com with SMTP id o123so12668886vsc.3
        for ; Mon, 22 Aug 2022 14:51:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc;
        bh=vGHNRj0LdpEPhvooX5pk+3ll+Xcy0K8YW5C30tGCAA8=;
        b=GaWN8yB34ArZ7mAZuW3r5gYqCH1F8N/IF4s6Ou9H0zCPXwmwnlXxXX9YGFSxO71cyR
         0LAOOns+jGGtIuiCQ2Fy6ceOrIWOz42I/DkKg2w+iwAQeNXGWCRBYzG104HSv0nubq6O
         ud2d+O6m8mD3+lN2amhY3SY4v/qFajGRaga23Xb2RGlW3vX2gu8Zw6DRRQal/M6xzMlV
         OX/5HLca1Ga91PCmxT83i6xEqf1iP4RggNEUktBW5RVPdDtknfdWz84Bg5M459FFG9Rn
         aN59nxtN5mGJRWD5pY/IfxiJDIkx4kU16LJVN53F7g9V6AHTc7v2hK5JEbMXRy4SLAk1
         4Epg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc;
        bh=vGHNRj0LdpEPhvooX5pk+3ll+Xcy0K8YW5C30tGCAA8=;
        b=Jv4x7Xy2k2drgGw9dgvTRGa9ZGguEVkc2FsScKa88tnSaLcy0wW6fAD4J/B/uxSxBz
         IPaR5ydK3ob210PVwwvN7VnQKsgqXYvwYBAPcfPUmw6sEkCfRFUd0kIILx2er/LXmq4Y
         5IbXO5dWJEVpfOY/QSBnZuxQ4CK0qJx3ZFdZ6t2Am3oE8zF0FcrCvaOXE+e+2164wbCz
         ia191GsO6pGrF7+GQpV2ccsR2/KvUq2A7ovg0eTFJ7FnrtyBpjnUn2EYUEe79bi3k3MY
         HukeNnZSuw2XrHUbQPckQ3mkVl0na/ncOxtHoOfltIhsdhXzfem7H8dd7yS4oUo7WZxU
         RtUQ==
X-Gm-Message-State: ACgBeo2MguPVWt+XJ0lBlK+M+MeKv/2EU4mXJ+JKJsTHi22vsyRlEj3d
	V2pHVsvw2yMLSN4Zt/DPBkx9Cg3nZOZGSSwKi+E2AQ==
X-Google-Smtp-Source: AA6agR4bsmUjNXiXntTekx4KcZ2AUvsXRBSo1XftsjsQhT9/qmHXeGoYCMLiwFV7cWJ9ZoCxCTYV1mczlWEs4myLuS4=
X-Received: by 2002:a67:b205:0:b0:390:793f:9fd3 with SMTP id
 b5-20020a67b205000000b00390793f9fd3mr1260127vsf.67.1661205074900; Mon, 22 Aug
 2022 14:51:14 -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, 22 Aug 2022 15:51:03 -0600
Message-ID: 
Subject: Re: init (/rescue/sh) died
To: "Bjoern A. Zeeb" 
Cc: Konstantin Belousov , FreeBSD Current 
Content-Type: multipart/alternative; boundary="0000000000006390d905e6db72cb"
X-Rspamd-Queue-Id: 4MBQzR4xY0z3stm
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=GaWN8yB3;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e29) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e29:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000006390d905e6db72cb
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 22, 2022 at 12:29 PM Bjoern A. Zeeb <
bzeeb-lists@lists.zabbadoz.net> wrote:

> On Mon, 22 Aug 2022, Warner Losh wrote:
>
> Hi,
>
> > On Mon, Aug 22, 2022 at 9:17 AM Konstantin Belousov  >
> > wrote:
> >
> >> On Mon, Aug 22, 2022 at 02:56:47PM +0000, Bjoern A. Zeeb wrote:
> >>> Hi,
> >>>
> >>> I am trying to get some arm64 up and running a bit but cannot use
> >>> loader. I have an MD_ROOT embedded in the kernel with /rescue on it.
> >>> I set INIT_PATH=/rescue/sh .
> >>>
> >>> However that doesn't seem to work:
> >>>
> >>> start_init: trying /rescue/sh
> >>> init died (signal 0, exit 0)
> >>> panic: Going nowhere without my init!
> >>>
> >>> Anyone any ideas?
> >>
> >> Kernel does not set up the standard file descriptors for stdin/out/err
> >> for init.  When you try to directly exec /rescue/sh (or /bin/sh), it
> cannot
> >> perform any io.
> >>
> >
> > Agreed. init does lots of magic, in addition to setting up stdin/out/err
> > (like
> > deal with process groups, etc). /bin/sh doesn't do any of that magic, so
> it
> > can't possibly work as init (PID 1).
> >
> > Your best bet is to boot -s (RB_SINGLE in the kernel boot_single=yes in
> the
> > boot loader). You'd think you'd be able to symbolically link /etc/rc to
> > /rescue/sh,
> > but that will result in sh trying to execute /rescue/sh as a shell script
> > and no good
> > can come from it. I've had luck with "echo sh > $DESTDIR/etc/rc;
> > chmod +x $DESTDIR/etc/rc" in the past, but I haven't tried that trick in
> > ages...
> > The simple equivalent to a tmp file does work.
>
> /rescue/init was simply "hanging" on earlier boots which is why I
> had initially switche dto sh.
>
> Here's a few things I did overall:
> - disable GDB in kernel config (it gave 2 lines of jitterish on
>    initial kernel printf lines before Copyrights.
> - Added bootargs = FreeBSD:-vs to the chosen section in FDT
>    given I cannot have loader (no EFI); the guard trick is nice if you
>    know about it ;)
>

No EFI doesn't mean you can't have a loader :). What environment are you
booting in? Seems interesting...


> - Removed my previous env file I had added to the kernel to set
>    tunables.
> - linked /bin/sh to /rescue/sh
> - put a printf "hello world\n"; exit 1 in the top of /etc/rc just in
>    case -s wouldn't work
> - changed INIT_PATH=/rescue/init
>
> Got a sh and can run sysctl and dmesg and type echo * in /rescue :)
> Even reboot works :)
>
> Now that basic netbooting and user space work I can start adding SoC
> drivers bit by bit over the next weeks/months :)  That'll be a lot
> more unfun.
>
> Thanks you two!  Along with help from Andy earlier this made my day!
>

Glad I could help...

Warner

--0000000000006390d905e6db72cb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Aug 22, 2022 at 12:29 PM Bjoe=
rn A. Zeeb <bzeeb-list=
s@lists.zabbadoz.net> wrote:
On Mon, 22 Aug 2022, Warner Losh wrote:



Hi,



> On Mon, Aug 22, 2022 at 9:17 AM Konstantin Belousov <kostikbel@gmail.com>

> wrote:

>

>> On Mon, Aug 22, 2022 at 02:56:47PM +0000, Bjoern A. Zeeb wrote:
>>> Hi,

>>>

>>> I am trying to get some arm64 up and running a bit but cannot =
use

>>> loader. I have an MD_ROOT embedded in the kernel with /rescue =
on it.

>>> I set INIT_PATH=3D/rescue/sh .

>>>

>>> However that doesn't seem to work:

>>>

>>> start_init: trying /rescue/sh

>>> init died (signal 0, exit 0)

>>> panic: Going nowhere without my init!

>>>

>>> Anyone any ideas?

>>

>> Kernel does not set up the standard file descriptors for stdin/out=
/err

>> for init.=C2=A0 When you try to directly exec /rescue/sh (or /bin/=
sh), it cannot

>> perform any io.

>>

>

> Agreed. init does lots of magic, in addition to setting up stdin/out/e=
rr

> (like

> deal with process groups, etc). /bin/sh doesn't do any of that mag=
ic, so it

> can't possibly work as init (PID 1).

>

> Your best bet is to boot -s (RB_SINGLE in the kernel boot_single=3Dyes=
 in the

> boot loader). You'd think you'd be able to symbolically link /=
etc/rc to

> /rescue/sh,

> but that will result in sh trying to execute /rescue/sh as a shell scr=
ipt

> and no good

> can come from it. I've had luck with "echo sh > $DESTDIR/e=
tc/rc;

> chmod +x $DESTDIR/etc/rc" in the past, but I haven't tried th=
at trick in

> ages...

> The simple equivalent to a tmp file does work.



/rescue/init was simply "hanging" on earlier boots which is why I=


had initially switche dto sh.



Here's a few things I did overall:

- disable GDB in kernel config (it gave 2 lines of jitterish on

=C2=A0 =C2=A0initial kernel printf lines before Copyrights.

- Added bootargs =3D FreeBSD:-vs to the chosen section in FDT

=C2=A0 =C2=A0given I cannot have loader (no EFI); the guard trick is nice i=
f you

=C2=A0 =C2=A0know about it ;)

No EFI do=
esn't mean you can't have a loader :). What environment are you
booting in? Seems interesting...
=C2=A0

- Removed my previous env file I had added to the kernel to set

=C2=A0 =C2=A0tunables.

- linked /bin/sh to /rescue/sh

- put a printf "hello world\n"; exit 1 in the top of /etc/rc just=
 in

=C2=A0 =C2=A0case -s wouldn't work

- changed INIT_PATH=3D/rescue/init



Got a sh and can run sysctl and dmesg and type echo * in /rescue :)

Even reboot works :)



Now that basic netbooting and user space work I can start adding SoC

drivers bit by bit over the next weeks/months :)=C2=A0 That'll be a lot=


more unfun.



Thanks you two!=C2=A0 Along with help from Andy earlier this made my day!

Glad I could help...

Warner=C2=A0


--0000000000006390d905e6db72cb--

From nobody Tue Aug 23 13:19:34 2022
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 4MBqZk3VLRz4ZfRx
	for ; Tue, 23 Aug 2022 13:19:42 +0000 (UTC)
	(envelope-from SRS0=3JBn=Y3=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 4MBqZj2gSnz46Hy;
	Tue, 23 Aug 2022 13:19:41 +0000 (UTC)
	(envelope-from SRS0=3JBn=Y3=klop.ws=ronald-lists@realworks.nl)
Date: Tue, 23 Aug 2022 15:19:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1661260774;
	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=yoMFyMx26peBaYQDcyugeY2/Zpkqnqb/wac5gVoqnYA=;
	b=CRnE3MDwjOIW0DR3Vx8cKGnSbVEpLQlj+oihxiB1NdD7GBajkDniyCdJfXrfpQstaw/ctU
	qqQp1jMt3bWjQI92iawOQq1zj6qBXIYjWzCotYUgdsv0UbI2m4Ehpb1Qc9AOncQ2n6Tavd
	TEyAnKaL/16M6DMWzxcTt06ihGCCjPVu7F8i/eYlTAg20Habwnd8Qxfuo4EH62dOV+gAVr
	czvqJN+GrxXIfY/w7MIvzYN74Qz3L+ORnGnYxHgxBCGM9/CGDAjM1ZfRh8ysYpwiTjWB9w
	iSy+lYQP7kir3TQHWrKT3HeNq2wboXCiXteaaIJ1gOxG4KQ9gl4WM/XZDQUKKA==
From: Ronald Klop 
To: Kyle Evans 
Cc: freebsd-current@freebsd.org, Ryan Moeller ,
	"Patrick M. Hausen" ,
	Peter Jeremy 
Message-ID: <2078216761.314.1661260774009@localhost>
In-Reply-To: 
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
 
 
 <623263165.219.1661170200563@localhost>
 
Subject: Re: Beadm can't create snapshot
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_313_1242291649.1661260773941"
X-Mailer: Realworks (620.114)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4MBqZj2gSnz46Hy
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=klop.ws header.s=rw2 header.b=CRnE3MDw;
	dmarc=pass (policy=quarantine) header.from=klop.ws;
	spf=pass (mx1.freebsd.org: domain of "SRS0=3JBn=Y3=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=3JBn=Y3=klop.ws=ronald-lists@realworks.nl"
X-Spamd-Result: default: False [-3.19 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	MID_RHS_NOT_FQDN(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine];
	FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=3JBn=Y3=klop.ws=ronald-lists@realworks.nl];
	R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24];
	R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_ZERO(0.00)[0];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[klop.ws:+];
	ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL];
	FROM_HAS_DN(0.00)[];
	HAS_X_PRIO_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=3JBn=Y3=klop.ws=ronald-lists@realworks.nl]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_313_1242291649.1661260773941
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 
Van: Kyle Evans 
Datum: maandag, 22 augustus 2022 17:11
Aan: Ronald Klop 
CC: Peter Jeremy , freebsd-current@freebsd.org, Ryan Moeller , "Patrick M. Hausen" 
Onderwerp: Re: Beadm can't create snapshot
> 
> On Mon, Aug 22, 2022 at 5:10 AM Ronald Klop  wrote:
> >
> >
> >
> > Van: Peter Jeremy 
> > Datum: maandag, 22 augustus 2022 10:45
> > Aan: "Patrick M. Hausen" 
> > CC: Ryan Moeller , freebsd-current@freebsd.org
> > Onderwerp: Re: Beadm can't create snapshot
> >
> > On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"  wrote:
> > >Isn't beadm retired in favour of bectl?
> >
> > bectl still has a number of bugs:
> > 1) The output from "bectl list" is in filesystem/bename order rather
> >    than creation date order.  This is an issue if you use (eg) git
> >    commit hashes as the name.
> > 2) "bectl activate" doesn't update /boot/loader.conf so the wrong
> >    root filesystem is mounted.
> >
> > That said "bectl create" appears to be a workable replacement for
> > "beadm create" and avoids the current "'snapshots_changed' is
> > readonly" bugs.
> >
> > --
> > Peter Jeremy
> > ________________________________
> >
> >
> >
> >
> > Hi,
> >
> > From man bectl:
> >      activate [-t | -T] beName
> >                Activate the given beName as the default boot filesystem.  If
> >                the -t flag is given, this takes effect only for the next boot.
> >                Flag -T removes temporary boot once configuration.  Without
> >                temporary configuration, the next boot will use zfs dataset
> >                specified in boot pool bootfs property.
> >
> > So it uses the bootfs property instead of loader.conf. If beadm used a different mechaniscm it would by nice to mention that in the HISTORY section of the bectl man page.
> >
> 
> I was not aware that beadm touches loader.conf, but I find that
> slightly horrifying. I won't personally make bectl do that, but I
> guess I could at least document that it doesn't...
> 
> 
> 


Hi,

Today I looked up something for boot environments myself and read this: https://wiki.freebsd.org/BootEnvironments#Setting_Boot_Dataset

"In order for boot environments to be effective, you must let the bootfs zpool property control which dataset gets mounted as the root. Particularly, /etc/fstab must be purged of any / mount, and /boot/loader.conf must not be setting vfs.root.mountfrom directly. "

So it is documented somewhere at least.

Regards,

Ronald.

 
------=_Part_313_1242291649.1661260773941
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

 

Van: Kyle Evans <kevans@freebsd.org>

Datum: maandag, 22 augustus 2022 17:11

Aan: Ronald Klop <ronald-lists@klop.ws>

CC: Peter Jeremy <peterj@freebsd.org>, freebsd-current@freebsd.org, Ryan Moeller <freqlabs@freebsd.org>, "Patrick M. Hausen" <pmh@hausen.com>

Onderwerp: Re: Beadm can't create snapshot







On Mon, Aug 22, 2022 at 5:10 AM Ronald Klop <ronald-lists@klop.ws> wrote:

>

>

>

> Van: Peter Jeremy <peterj@freebsd.org>

> Datum: maandag, 22 augustus 2022 10:45

> Aan: "Patrick M. Hausen" <pmh@hausen.com>

> CC: Ryan Moeller <freqlabs@freebsd.org>, freebsd-current@freebsd.org

> Onderwerp: Re: Beadm can't create snapshot

>

> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen" <pmh@hausen.com> wrote:

> >Isn't beadm retired in favour of bectl?

>

> bectl still has a number of bugs:

> 1) The output from "bectl list" is in filesystem/bename order rather

>    than creation date order.  This is an issue if you use (eg) git

>    commit hashes as the name.

> 2) "bectl activate" doesn't update /boot/loader.conf so the wrong

>    root filesystem is mounted.

>

> That said "bectl create" appears to be a workable replacement for

> "beadm create" and avoids the current "'snapshots_changed' is

> readonly" bugs.

>

> --

> Peter Jeremy

> ________________________________

>

>

>

>

> Hi,

>

> From man bectl:

>      activate [-t | -T] beName

>                Activate the given beName as the default boot filesystem.  If

>                the -t flag is given, this takes effect only for the next boot.

>                Flag -T removes temporary boot once configuration.  Without

>                temporary configuration, the next boot will use zfs dataset

>                specified in boot pool bootfs property.

>

> So it uses the bootfs property instead of loader.conf. If beadm used a different mechaniscm it would by nice to mention that in the HISTORY section of the bectl man page.

>



I was not aware that beadm touches loader.conf, but I find that

slightly horrifying. I won't personally make bectl do that, but I

guess I could at least document that it doesn't...










Hi,



Today I looked up something for boot environments myself and read this: https://wiki.freebsd.org/BootEnvironments#Setting_Boot_Dataset



"In order for boot environments to be effective, you must let the bootfs zpool property control which dataset gets mounted as the root. Particularly, /etc/fstab must be purged of any / mount, and /boot/loader.conf must not be setting vfs.root.mountfrom directly. "



So it is documented somewhere at least.



Regards,



Ronald.



 
------=_Part_313_1242291649.1661260773941--

From nobody Tue Aug 23 21:43:51 2022
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 4MC2mc1YSvz4ZMgY
	for ; Tue, 23 Aug 2022 21:44:00 +0000 (UTC)
	(envelope-from peterj@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MC2mc166Fz3h05;
	Tue, 23 Aug 2022 21:44:00 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661291040;
	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=6lgeqQQRfU61u87vVcDD6TSjEtHYULp6Gwf4BXagkF4=;
	b=AH3CZloPCDv83zE+Miw0xGtk4Aoj/yAESQ2i27nmT6pfmPRuRCMs5HTv3IueVA9tSt6k0y
	R6E5l2jocB7sKbVQyN313jc4sSBaZL1Hht5yJlGHI5vDgxLm83+ATHwkKsDAAmqpGhBKl7
	09GEgAYrG3IRoyrF4KV4oeENDonCn/QrDpscpq5eANp3M8lOCXvdohMF3hwnvFGymHTeTd
	v3Jut+57I7a/uYdvj4p4ctxTOnghAc/4AWWVJCSM2wzM2kG+KL9s32HbwHFRwTQJH5Mcgk
	4cqM7KLRjORoIKjDCmb1PN5HFfxLsT90CGkRlxoVQ7AwPoxb5BVbEIt3SIxcEw==
Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512)
	(Client did not present a certificate)
	(Authenticated sender: peterj)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MC2mZ1hwsz124F;
	Tue, 23 Aug 2022 21:43:57 +0000 (UTC)
	(envelope-from peterj@freebsd.org)
Date: Wed, 24 Aug 2022 07:43:51 +1000
From: Peter Jeremy 
To: Ronald Klop 
Cc: Kyle Evans , freebsd-current@freebsd.org,
	Ryan Moeller ,
	"Patrick M. Hausen" 
Subject: Re: Beadm can't create snapshot
Message-ID: 
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
 
 
 <623263165.219.1661170200563@localhost>
 
 <2078216761.314.1661260774009@localhost>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="2pfGHGZUe9Hv8Yqe"
Content-Disposition: inline
In-Reply-To: <2078216761.314.1661260774009@localhost>
X-PGP-Key: http://www.rulingia.com/keys/peter.pgp
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661291040;
	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=6lgeqQQRfU61u87vVcDD6TSjEtHYULp6Gwf4BXagkF4=;
	b=IsjF8DGZB9dCMOk5Qy6m66VcIcD63sK+6msJKt6sAFqnR2OzQRK8JNi1a/smD7FUMuYvpp
	S8+oM2fHYkPmEO3bEORH/OZIIb4Wto9KDNZPtv3JQlQAvAAM/rrL85K4Wb/aKNNsJyxtHi
	CXFrGOFgymJPkkbs3Ceu0WhzX+HNXcaHenCf9JXaR1YJ3b0kQ39TO/sg4+Q/2hbltw1vLZ
	NLL6h4MZXWcugUV6vAh0Awv+UEo3UamTM0ZQa7jRYk9H7PFZSA4A4sspn4Ey3viMOdVL1R
	vvSETCO8ki+UntL8tb0aHsgn2nYsaDKyG8WyDf+4tXe4bxYt5e8M1Gdp8YZ4qQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661291040; a=rsa-sha256; cv=none;
	b=aEAlPIarKN0T8bFsVwc6j1oVR1zoqQUjxV0aCD5syw+g5yJU8+My/iYZhL0TbWaLyGau+Y
	wQMEViMe7V57eO/jwZXHlMAM1OzYnB8sQKGFxDZqYvOkNagvlAG1fZed1fJlYlialbsuns
	+/uXoiBdKHGX6/hYQO5gF+anmybFYxLYGL5mMUlXMSiicGeSQMPelVQJMRB1VnhyhfhBva
	aVMP7xWVRuwQTSz+jORGmmyV47WuPeTsgWOlLHwzysvdfwyUQwUYxjxDfi2QP45QlCFJ+J
	zk7+w7TGaNeh0G0ADDW47rQFCWkPURjdPoN8g/j0pt6mJfhjbzmtbkgoXBUDsw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--2pfGHGZUe9Hv8Yqe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-Aug-23 15:19:34 +0200, Ronald Klop  wrote:
>Van: Kyle Evans 
>> I was not aware that beadm touches loader.conf, but I find that
>> slightly horrifying. I won't personally make bectl do that, but I
>> guess I could at least document that it doesn't...
>
>Today I looked up something for boot environments myself and read this: ht=
tps://wiki.freebsd.org/BootEnvironments#Setting_Boot_Dataset
>
>"In order for boot environments to be effective, you must let the bootfs z=
pool property control which dataset gets mounted as the root. Particularly,=
 /etc/fstab must be purged of any / mount, and /boot/loader.conf must not b=
e setting vfs.root.mountfrom directly. "
>
>So it is documented somewhere at least.

Looking at the wiki history, Kyle wrote that in January 2020.  I
wonder if he recalls where that requirement came from.

I've gone rummaging through the mailing list history and other wiki
pages.  It seems that vfs.root.mountfrom used to be required - e.g.
 https://lists.freebsd.org/pipermail/freebsd-fs/2011-September/012482.html
 https://lists.freebsd.org/pipermail/svn-src-head/2011-October/030641.html
and people wanted to change that - e.g.
 https://lists.freebsd.org/pipermail/freebsd-current/2009-October/012933.ht=
ml
 https://lists.freebsd.org/pipermail/freebsd-fs/2010-March/008010.html
resulting in it becoming optional in May 2012:
 https://lists.freebsd.org/pipermail/svn-src-head/2012-May/036902.html

Based on the quoted wiki entry, it seems that sometime between May
2012 and January 2020, vfs.root.mountfrom went from "must be set" to
"must not be set" and I can't find anywhere where that is publicised.
This is a serious problem because we now have the situation where
some documentation still says to set vfs.root.mountfrom - e.g.
 https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror step 2.6
and people are still using it without being warned that it shouldn't
be used - e.g. the thread starting
 https://lists.freebsd.org/pipermail/freebsd-fs/2020-July/028351.html

I've had a look at the beadm source and it preserves/updates
vfs.root.mountfrom if it's present in loader.conf but doesn't add it
if it's not present.

IMO, if bectl isn't going to update loader.conf, it needs to warn and
fail if loader.conf contains a vfs.root.mountfrom that points to a
BE that's different to bootfs.  (And ideally, a similar check of
/etc/fstab, though beadm doesn't touch that).

--=20
Peter Jeremy

--2pfGHGZUe9Hv8Yqe
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmMFShJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF
QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi
CzTSTQ//RmmVRpfUgm5oPvt21GLAACEXwdNcH/c2iL0RPJxPRaAl2PMghd06wT6t
xk3G2b2hHguPWfAsNGnUkF7/zaQrqpTJMUEIAu/gvGtgNpwwNRyzBV2mM3Cy+IF7
VNmo6mpUqk5HfU70ne3wcmbU0KIuBjrghN7yQjVdie5pCeAanp8mDW66auMPgyyE
0Yc59P4S/Xts65+ywKOmt5UUi9Q4XJtBGU9sCG5var+pvRjrup1xweKP9Qb9SsC5
aBNsreV0or3/xZSQc7oijckmu5STWju+w8sbuceRRXRSeNsWGPyA1nF14yCtmiLs
qYOTnlN4wPvYQ1BVCty0Bpxxbw3hX5VihWVowT2ilCyOOqaqTjXBw2V1v3N3ncin
aM4HE8Y5EF6zxHz7XBD51x/GTDppk0yXNrsdzq+rUZrSEiGFjaSw42ka/gz9bJC1
sE5Aubcb/IAkXc4KUaaVJD7vcAR4SZGsykImW5Voj3uvGWs7hQOJgJEyzri6daSP
iPHSMHk0+loeoOzxG146jh8DMosmcHB9koLvmSmCXlBDQWixQSvdh+NtMgF3kDkY
dfdpL8v2QUNmN5yfK24VVbv0pf9eZWk+7WbFxNoBPKpq0TBXMPy9JN0uD4P/6InT
Yue4RXB4P1vGFXzp3zzEupj9Hmx7ZvjRv3kKMcscxTqThdKuNKA=
=6lli
-----END PGP SIGNATURE-----

--2pfGHGZUe9Hv8Yqe--

From nobody Thu Aug 25 18:59:50 2022
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 4MDC2V6rYSz4ZFMj
	for ; Thu, 25 Aug 2022 19:00:02 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MDC2V6Q63z3Xtp
	for ; Thu, 25 Aug 2022 19:00:02 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661454002;
	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=v3m2l3F4PBmREBCkT11Rb4GWSPvM9GiKkF1s4d1xfQ4=;
	b=Dj+TWtar73NKVak/2mxNUPcyqs5zwZxh5ZM7O3s21LTHpVV1Eaa9hyJRegFCtkABgSVJTU
	pk6Hltw2Bmimdxwg2xvM4EPa7ffNYapVtiMgZDRrfke/v0DYmJaGwhiLh10++Ys+zAC6oJ
	KCXkL8IEGeYNpps2lCwBhPPVYVf3h5PLM919PBwUvPDn1l/fsSNwF2eWMlguX2JN4x9EOh
	wDpUoZuu4KckV2rWDDXySy6QPIjJEjg/javlrjp5ERiCPy7gRQf3R0xYzHWnmuwM0I7bHs
	5r9M8TFJrpAu60OHW9tf6RHic0p+xpIYmRzOPePtkWgfHMQphzJ+O83JyNywtw==
Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MDC2V5M1Qzp1R
	for ; Thu, 25 Aug 2022 19:00:02 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f44.google.com with SMTP id c3so21821795vsc.6
        for ; Thu, 25 Aug 2022 12:00:02 -0700 (PDT)
X-Gm-Message-State: ACgBeo10Mgw0QS/me1zhxZ/dNJu4JmZ5iJIUjVKYY/8p2da+RFXYiSie
	ptorWZAm8dKAgu9cXi/bdaVdsqcUoFAylqJMbJI=
X-Google-Smtp-Source: AA6agR5HTXdD1SisWBqalY1UdBl9A58lyF62AKGj6/63GVqTC3cOVpXUq4H1Z7nSoWTQzVUspopbaYWmgKZ2tnSmZC8=
X-Received: by 2002:a67:f3cb:0:b0:390:8bbd:adce with SMTP id
 j11-20020a67f3cb000000b003908bbdadcemr2233627vsn.11.1661454002114; Thu, 25
 Aug 2022 12:00:02 -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: Nuno Teixeira 
Date: Thu, 25 Aug 2022 19:59:50 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Lenovo Legion 5 Intel speakers working ok!
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000009b554305e71567bb"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661454002;
	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=v3m2l3F4PBmREBCkT11Rb4GWSPvM9GiKkF1s4d1xfQ4=;
	b=e88AxCXJR1+NaduK4MUaryUkT/OVnxpHZ3Xys/5zvND3miuA4O1EQHfzJ7HvukCYXkZKW9
	VIelZg881PB+TcyQ/0N/e3t+OUhSzdY3iAMd9yUEXA4I7bT0Iwdeiyqph/rQ9gQvJrQ5fo
	iYRoPl9sZJTfVaCb2BxJQ98uv4Fe7jrtcqpJ2ZmNGt6+WuFx7xypbVbnChKEGyobP8UcxB
	Xo51wKo34r4ExMt3yr7lOZN/8xpPw7OfPSc28iporc3sfB+XAa/odgJpkWmdXEqb1K9Toz
	rAXG3/4H/M5S6KJq75AB7W/8XhkSaC1CMF6202Wk7gb+6WFs2/g+lfhjsHprAw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661454002; a=rsa-sha256; cv=none;
	b=NaREhUEI5MuWsCG8a/7bdXkZo/HQGVj/9dCnOvd6bTTHS668KNOzL3PqHcv28JyEnm3Phu
	Dne8hOYG8NVvzoLkCbDMpjFIfS4DLNxmrX3b+KfYsB2js5cexpROVJ7W7K7STEkFtWiw/q
	PLJ1exjx91g3ywkF8tUad3486FUpAhlN+zzspxg4bdAYkVsZjo8wLbUzQhrriAJrEh/Qq3
	ylv7ynJ5/bdaYCtzOz9TQLHCNjGBIAEbXu6K51IhOLPGG/Rbw4HOaF6sraqOZGGvytHbQ/
	DucLSKxUfiRxdjZuJnsi0YlHKa0ZYaiSrU2oluN7AIngDSbzmFseYu1vxxvavQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000009b554305e71567bb
Content-Type: text/plain; charset="UTF-8"

Hello,

I have Lenovo Legion 5 Intel speakers working ok with device.hints:
---
hint.hdaa.1.nid20.config="as=1 seq=0"
hint.hdaa.1.nid33.config="as=1 seq=15"
---

Same config were imported from D30333 
and PR 265632 
for Legion 5 AMD:
(sys/dev/sound/pci/hda/hdac.h)
---
#define LENOVO_L5AMD_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x381b)
---
How do I found id for Intel version so I can submit a patch?

Thanks,
-- 
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000009b554305e71567bb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

I have Lenovo Legion =
5 Intel speakers working ok with device.hints:
---
hint=
.hdaa.1.nid20.config=3D"as=3D1 seq=3D0"
hint.hdaa.1.nid33.conf=
ig=3D"as=3D1 seq=3D15"
---

Sam=
e config were imported from =
D30333 and PR 265632 for Legion 5 AMD:
(sys/dev/=
sound/pci/hda/hdac.h)
---
#define	LENOVO_L5AMD_SUBVENDOR	HDA_MODEL_CONSTRUCT(LENOVO, 0x=
381b)
---
<=
/span>
How do I found id for Intel version so I can submit a patc=
h?

Thanks,
-- 
Nuno Teixeira
FreeBSD Commi=
tter (ports)


--0000000000009b554305e71567bb--

From nobody Thu Aug 25 19:11:03 2022
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 4MDCHS4DbJz4ZGpW
	for ; Thu, 25 Aug 2022 19:11:16 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MDCHS3Qt6z3Zgh
	for ; Thu, 25 Aug 2022 19:11:16 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661454676;
	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=RWETrXhYidkMpNbcJVsKtYkr1IDd6o1SKON6/D0grVQ=;
	b=aEj2iHFaAv53x1WhXxo4ZYrPAwcVJIawKFfjPjVvqDtNp1SqrkFl9qC58rg0B9OCl8U7YX
	y4o4miTlIun3IfmayH7dAXvmzfpC6K69tWoPcyCzbwK+hTJwD82tw7nzccxJdGdtEiSIUH
	wDAkoH0tuq47F3OPWF0Bkw3gHa2r+1tdIN4lUMKwBd4VPhUtGIsokAM2uj7N97LjslB5pH
	dRv89KYEWrgD4nx/kZO7Ca/izt3CSxy8ia0v6rvO+c0J3ThkkVK8x0d8Sy+slh5QjY5B15
	GdGkQX8QQrvBj+c0ZK2JqihAy+iAoF2QfSkb1zWIGjqW8bPK60KHGn3vqqArGg==
Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MDCHS2M3vznqq
	for ; Thu, 25 Aug 2022 19:11:16 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f46.google.com with SMTP id h67so20878441vsc.11
        for ; Thu, 25 Aug 2022 12:11:16 -0700 (PDT)
X-Gm-Message-State: ACgBeo2nFvqM1jY/RXy/SJrTHsR0hOjKMOLWOShB2xGfJ4LUIgVcyAVb
	hYlOpOTvOJmwvzcJYEUZqCo2eV6Baz66UM7i+3s=
X-Google-Smtp-Source: AA6agR4yURIWkXN/QFeTKzwuLcardJ9pfS1/5/QEuYQHBRvpkL87FXY8Rdxo5m3ojoY/fYpJ3X1U0LPtWHqKI/NEJfY=
X-Received: by 2002:a67:f993:0:b0:390:3c69:4801 with SMTP id
 b19-20020a67f993000000b003903c694801mr2297795vsq.19.1661454675446; Thu, 25
 Aug 2022 12:11:15 -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: Nuno Teixeira 
Date: Thu, 25 Aug 2022 20:11:03 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Lenovo Legion 5 Intel speakers working ok!
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000bd94e305e7158f4a"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661454676;
	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=RWETrXhYidkMpNbcJVsKtYkr1IDd6o1SKON6/D0grVQ=;
	b=RqJQ5AUSwI/2uZdstVI+aFVuTAn3yJYbLJnrisaXZFs55U1iY61sPDydhr4YF/UGQAJSuX
	juxUb/e1FsY6cNklEtY3zbsBmc4tHDaUTm012lhafD5muC+6dv9TBgSMcN20CqjLMKZIah
	H63tY7kT8PgEiAPYr4+94O9toKNW/ueawU/LRTUGyEZTRicEDOsCV2Px34eyyDpfXQP+oW
	s7/jFtNd7Ah8foRFdZWrAobs5E1/XBDjHr+0keLXK6OifMXb+7m/ETZLT/cIYBSTi9HLKU
	oL2Du1qB9tDgACN2/4E/D1CjlQvAhGfRAwWHf7O7MxcLP3Gd22FIPTIpjMbBRw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661454676; a=rsa-sha256; cv=none;
	b=myX2z18w00/rjodgAOgXZX8ARQimHgAu4wQgiFcMyArxk0p8qBXPT8OINsuczm7UibsCuL
	lPZHnxQcqHhaTBqMAnUur4FmnHPq0w4L9mDsiI4QjIwpEk7MA+Gn7xZWAHmX0z34W1Qel4
	aQSdFb8+DgZR968fKq2BrGd0M3yHtIPouO9c2NKe3Pl/wiZv3hWswZZIuaInY54wa07dEW
	FNLsy6AFxqKfOwzxZQIRCSv1SSiFuaSk1LMEemN5dOlZBbTVLjb3Z/b5cMcbTCKROQ++EI
	04Mf3upg2lsBkL+u2S3DqRNVBTaHZcV9OCE84xDx1PFhu0qi2kkxSAkHSTiq9A==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000bd94e305e7158f4a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

** Same config were imported from D30333
 for Legion 5 AMD, PR 265632
for Intel versi=
on

Nuno Teixeira  escreveu no dia quinta, 25/08/2022 =C3=
=A0(s)
19:59:

> Hello,
>
> I have Lenovo Legion 5 Intel speakers working ok with device.hints:
> ---
> hint.hdaa.1.nid20.config=3D"as=3D1 seq=3D0"
> hint.hdaa.1.nid33.config=3D"as=3D1 seq=3D15"
> ---
>
> Same config were imported from D30333 
> and PR 265632 
> for Legion 5 AMD:
> (sys/dev/sound/pci/hda/hdac.h)
> ---
> #define LENOVO_L5AMD_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x381b)
> ---
> How do I found id for Intel version so I can submit a patch?
>
> Thanks,
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000bd94e305e7158f4a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


** Same config were imported from D30333 for Legion 5 AMD, PR 265632for=
 Intel version

Nuno Teixeira <eduardo@freebsd.org> escreveu no dia qui=
nta, 25/08/2022 =C3=A0(s) 19:59:
Hello,

I ha=
ve Lenovo Legion 5 Intel speakers working ok with device.hints:
-=
--
hint.hdaa.1.nid20.config=3D"as=3D1 seq=3D0"
hint.=
hdaa.1.nid33.config=3D"as=3D1 seq=3D15"
---
<=
br>
Same config were imported from D30333 and PR 265632 for Legion 5 AMD:
(sys/dev/sound/pci/hda/hdac.h)
=
---
#define	LENOVO_L5AMD_SU=
BVENDOR	HDA_MODEL_CONSTRUCT(LENOVO, 0x381b)
<=
span>---
How do I found id for Intel version so=
 I can submit a patch?

Thanks,
-=
- 
Nuno Teixeira
FreeBSD Committer (ports)




-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--000000000000bd94e305e7158f4a--

From nobody Thu Aug 25 19:35:16 2022
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 4MDCqP5w6Lz4ZKnf
	for ; Thu, 25 Aug 2022 19:35:29 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MDCqP59HZz3dyl;
	Thu, 25 Aug 2022 19:35:29 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661456129;
	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=5zbPNgzEDCplDgjldGZ3CQNW0xE5gFePHlQuWeOyJMc=;
	b=nOTGxlBfer6pcEjpps9WjYvihOdVzIFmYYFiEpyJ2ayxfLcrBIUc40nln0lz7SB5Y7z/N+
	BpcCBa/cuiYo3taGFLt6NLqanuRHKlhUQ/iDc2eyA1IabTKnJ8jUk4zlwrLt/0CV6pZj2K
	+0oApPMKhcFKjGk5CRvB8fgtI1Xvl4xFcR67KwIbUGFcx6b8YX86d9qQu12rt7QZ3NdiXv
	Gz3LYfYwBRGIQYh77Vn+7yARhvP9U49k44pvQXZVvNJxFpn1V4xjv4r6Rw/9Fk3di1XXM3
	yUqCU2N5uBDTtelWQhRn7O+JOw2gwp3Oj2/sekhIsxN4ZFckwz8V1kQOR9vVqw==
Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MDCqP40m4zpQB;
	Thu, 25 Aug 2022 19:35:29 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f47.google.com with SMTP id d126so21910200vsd.13;
        Thu, 25 Aug 2022 12:35:29 -0700 (PDT)
X-Gm-Message-State: ACgBeo1bhRlUrjfXMj3XFPHaQuJHz0NLomi1kXxvH9qonS0Ke3WSDq0j
	SHDL8EmKW3rjaL+QSrUj7nzBtTubO+GAIg+lA5Q=
X-Google-Smtp-Source: AA6agR7IVENJM3M+L52VNZJhtgTeVX1DR6uVKqMdO1Aft+4vjjTUxsAoOqi7G2Se4tUYW90Uow0O6agZklpTcIlNF2Y=
X-Received: by 2002:a05:6102:34ed:b0:390:abb1:60ba with SMTP id
 bi13-20020a05610234ed00b00390abb160bamr29801vsb.51.1661456129103; Thu, 25 Aug
 2022 12:35:29 -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: 
  <94e271b7-3019-a377-bb8b-e681c78b0d82@FreeBSD.org>
In-Reply-To: <94e271b7-3019-a377-bb8b-e681c78b0d82@FreeBSD.org>
From: Nuno Teixeira 
Date: Thu, 25 Aug 2022 20:35:16 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Lenovo Legion 5 Intel speakers working ok!
To: Jung-uk Kim 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000629c7105e715e606"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661456129;
	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=5zbPNgzEDCplDgjldGZ3CQNW0xE5gFePHlQuWeOyJMc=;
	b=tXzR4kpxkoiShm27xmTOdUeU5Xr9nThwCwteNV8i5vtu/C/AVPcpmC0TVeSsEsL/yA2BSW
	lcUZ4icVf8aDOijVw1o0Bt13oQS9tk3TJGDpiMZLTBdzmwJNsBFdBC/snkbQJZmNK9HUNT
	MCHtT9bGnxqd3bJ0+zOKAuFqO8C2nNomPLMxewgmBLZgRnPHoIvmLjyng8FpTnObAPBiYa
	XZ1IXbdlmJYWotWmgFkXfaIj986w+ewSUq66mRRAJmNusb6/fdmKIP5i8nqjL4sKqDA4LX
	1yPjyXdWF6lGYmCMpxQcjb8SEYeDWjwIH9IxaEn9c+tjV9DdsWiZltDHAJIy/Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661456129; a=rsa-sha256; cv=none;
	b=evyBfhRKbTM2i3z92Mf3VU2NDcKaZYpMFxTCK2ile+0iXmiHsg6zKsAg1oT4SEhzsbuHdp
	SqOI4gwKErNSzxV6xqgjuiS7kxbJRZ4V7du+uTsAOWzudY1cTvtnHbtqIDP1juVVSm1O/Z
	mmyOjD09xwRuKAZWDHHBnqtxmj9pCbtqoV+ysK769q9HWDfHHhvzYAI1ivPFs6PDPb518c
	gopgCnqdct2eBwaFDpUwYRs1+IWkGK0KBlKfdWbnT7Z9TB65P0xy3pPQ3ESglEO054VWzA
	gq+q6VbV7iripGCOOICihHhZp9I825FWVXLN+wk+QOBN0vRHCL/I0BdIqCDI6g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000629c7105e715e606
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi!

`pciconf -l | grep ^hdac`:
---
hdac1@pci0:0:31:3:      class=3D0x040380 rev=3D0x00 hdr=3D0x00 vendor=3D0x8=
086
device=3D0x06c8 subvendor=3D0x17aa subdevice=3D0x380f
^^^^
^^^^^                  ^^^^
hdac0@pci0:1:0:1:       class=3D0x040300 rev=3D0xa1 hdr=3D0x00 vendor=3D0x1=
0de
device=3D0x10fa subvendor=3D0x17aa subdevice=3D0x3ffb
---

I think hdac1 is what I'm looking for:
---
hdac1@pci0:0:31:3:      class=3D0x040380 rev=3D0x00 hdr=3D0x00 vendor=3D0x8=
086
device=3D0x06c8 subvendor=3D0x17aa subdevice=3D0x380f
    vendor     =3D 'Intel Corporation'
    device     =3D 'Comet Lake PCH cAVS'
    class      =3D multimedia
    subclass   =3D HDA
---

(LENOVO_VENDORID         0x17aa)

maybe:
#define LENOVO_L5INTEL_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x380f) ?

^^^^
^^^^




Jung-uk Kim  escreveu no dia quinta, 25/08/2022 =C3=A0(s)
20:15:

> On 22. 8. 25., Nuno Teixeira wrote:
> > ** Same config were imported from D30333
> > for Legion 5 AMD, PR 265632
> > for Intel
> version
> >
> > Nuno Teixeira >
> > escreveu no dia quinta, 25/08/2022 =C3=A0(s) 19:59:
> >
> >     Hello,
> >
> >     I have Lenovo Legion 5 Intel speakers working ok with device.hints:
> >     ---
> >     hint.hdaa.1.nid20.config=3D"as=3D1 seq=3D0"
> >     hint.hdaa.1.nid33.config=3D"as=3D1 seq=3D15"
> >     ---
> >
> >     Same config were imported from D30333
> >     and PR 265632
> >      for
> >     Legion 5 AMD:
> >     (sys/dev/sound/pci/hda/hdac.h)
> >     ---
> >     #define LENOVO_L5AMD_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x381b)
> >     ---
> >     How do I found id for Intel version so I can submit a patch?
>
> Try "pciconf -l | grep ^hdac".  You'll see subvendor and subdevice.
>
> JK
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000629c7105e715e606
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGRpdiBkaXI9Imx0ciI+PGRpdj5IaSE8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmBwY2ljb25m
IC1sIHwgZ3JlcCBeaGRhY2A6PC9kaXY+PGRpdj4tLS08L2Rpdj48ZGl2PmhkYWMxQHBjaTA6MDoz
MTozOiDCoCDCoCDCoGNsYXNzPTB4MDQwMzgwIHJldj0weDAwIGhkcj0weDAwIHZlbmRvcj0weDgw
ODYgZGV2aWNlPTB4MDZjOCBzdWJ2ZW5kb3I9MHgxN2FhIHN1YmRldmljZT0weDM4MGY8L2Rpdj48
ZGl2Pl5eXl7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIF5eXl5ewqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBeXl5ePGJyPjwvZGl2PjxkaXY+aGRhYzBAcGNpMDoxOjA6
MTogwqAgwqAgwqAgY2xhc3M9MHgwNDAzMDAgcmV2PTB4YTEgaGRyPTB4MDAgdmVuZG9yPTB4MTBk
ZSBkZXZpY2U9MHgxMGZhIHN1YnZlbmRvcj0weDE3YWEgc3ViZGV2aWNlPTB4M2ZmYjwvZGl2Pjxk
aXY+LS0tPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIHRoaW5rIGhkYWMxIGlzIHdoYXQgSSYj
Mzk7bSBsb29raW5nIGZvcjo8L2Rpdj48ZGl2Pi0tLTwvZGl2PjxkaXY+aGRhYzFAcGNpMDowOjMx
OjM6IMKgIMKgIMKgY2xhc3M9MHgwNDAzODAgcmV2PTB4MDAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4
NiBkZXZpY2U9MHgwNmM4IHN1YnZlbmRvcj0weDE3YWEgc3ViZGV2aWNlPTB4MzgwZjxicj7CoCDC
oCB2ZW5kb3IgwqAgwqAgPSAmIzM5O0ludGVsIENvcnBvcmF0aW9uJiMzOTs8YnI+wqAgwqAgZGV2
aWNlIMKgIMKgID0gJiMzOTtDb21ldCBMYWtlIFBDSCBjQVZTJiMzOTs8YnI+wqAgwqAgY2xhc3Mg
wqAgwqAgwqA9IG11bHRpbWVkaWE8YnI+wqAgwqAgc3ViY2xhc3MgwqAgPSBIREE8L2Rpdj48ZGl2
Pi0tLTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+KExFTk9WT19WRU5ET1JJRCDCoCDCoCDCoCDC
oCAweDE3YWEpPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5tYXliZTo8L2Rpdj48ZGl2PjxzcGFu
IGNsYXNzPSJnbWFpbC1pbSI+I2RlZmluZSBMRU5PVk9fTDVJTlRFTF9TVUJWRU5ET1IgSERBX01P
REVMX0NPTlNUUlVDVChMRU5PVk8sIDB4MzgwZikgPzxicj48L3NwYW4+PC9kaXY+PGRpdj48c3Bh
biBjbGFzcz0iZ21haWwtaW0iPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBeXl5ewqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgXl5eXjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBjbGFzcz0iZ21h
aWwtaW0iPjxicj48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PC9k
aXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21h
aWxfYXR0ciI+SnVuZy11ayBLaW0gJmx0OzxhIGhyZWY9Im1haWx0bzpqa2ltQGZyZWVic2Qub3Jn
Ij5qa2ltQGZyZWVic2Qub3JnPC9hPiZndDsgZXNjcmV2ZXUgbm8gZGlhIHF1aW50YSwgMjUvMDgv
MjAyMiDDoChzKSAyMDoxNTo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl
IiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCBy
Z2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPk9uIDIyLiA4LiAyNS4sIE51bm8gVGVp
eGVpcmEgd3JvdGU6PGJyPg0KJmd0OyAqKiBTYW1lIGNvbmZpZyB3ZXJlIGltcG9ydGVkIGZyb20g
RDMwMzMzIDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9y
Zy9EMzAzMzMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vcmV2aWV3
cy5mcmVlYnNkLm9yZy9EMzAzMzM8L2E+Jmd0O2ZvciBMZWdpb24gNSBBTUQsIFBSIDI2NTYzMiA8
YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEv
c2hvd19idWcuY2dpP2lkPTI2NTYzMiIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly9idWdzLmZyZWVic2Qub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0yNjU2MzI8
L2E+Jmd0O2ZvciBJbnRlbCB2ZXJzaW9uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE51bm8gVGVpeGVp
cmEgJmx0OzxhIGhyZWY9Im1haWx0bzplZHVhcmRvQGZyZWVic2Qub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+ZWR1YXJkb0BmcmVlYnNkLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZWR1
YXJkb0BmcmVlYnNkLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmVkdWFyZG9AZnJlZWJzZC5vcmc8L2E+
Jmd0OyZndDsgPGJyPg0KJmd0OyBlc2NyZXZldSBubyBkaWEgcXVpbnRhLCAyNS8wOC8yMDIyIMOg
KHMpIDE5OjU5Ojxicj4NCiZndDsgPGJyPg0KJmd0O8KgIMKgIMKgSGVsbG8sPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7wqAgwqAgwqBJIGhhdmUgTGVub3ZvIExlZ2lvbiA1IEludGVsIHNwZWFrZXJzIHdv
cmtpbmcgb2sgd2l0aCBkZXZpY2UuaGludHM6PGJyPg0KJmd0O8KgIMKgIMKgLS0tPGJyPg0KJmd0
O8KgIMKgIMKgaGludC5oZGFhLjEubmlkMjAuY29uZmlnPSZxdW90O2FzPTEgc2VxPTAmcXVvdDs8
YnI+DQomZ3Q7wqAgwqAgwqBoaW50LmhkYWEuMS5uaWQzMy5jb25maWc9JnF1b3Q7YXM9MSBzZXE9
MTUmcXVvdDs8YnI+DQomZ3Q7wqAgwqAgwqAtLS08YnI+DQomZ3Q7IDxicj4NCiZndDvCoCDCoCDC
oFNhbWUgY29uZmlnIHdlcmUgaW1wb3J0ZWQgZnJvbSBEMzAzMzM8YnI+DQomZ3Q7wqAgwqAgwqAm
bHQ7PGEgaHJlZj0iaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0QzMDMzMyIgcmVsPSJub3Jl
ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0QzMDMz
MzwvYT4mZ3Q7YW5kIFBSIDI2NTYzMjxicj4NCiZndDvCoCDCoCDCoCZsdDs8YSBocmVmPSJodHRw
czovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTI2NTYzMiIgcmVs
PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9idWdzLmZyZWVic2Qub3JnL2J1
Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0yNjU2MzI8L2E+Jmd0OyBmb3I8YnI+DQomZ3Q7wqAgwqAg
wqBMZWdpb24gNSBBTUQ6PGJyPg0KJmd0O8KgIMKgIMKgKHN5cy9kZXYvc291bmQvcGNpL2hkYS9o
ZGFjLmgpPGJyPg0KJmd0O8KgIMKgIMKgLS0tPGJyPg0KJmd0O8KgIMKgIMKgI2RlZmluZSBMRU5P
Vk9fTDVBTURfU1VCVkVORE9SIEhEQV9NT0RFTF9DT05TVFJVQ1QoTEVOT1ZPLCAweDM4MWIpPGJy
Pg0KJmd0O8KgIMKgIMKgLS0tPGJyPg0KJmd0O8KgIMKgIMKgSG93IGRvIEkgZm91bmQgaWQgZm9y
IEludGVsIHZlcnNpb24gc28gSSBjYW4gc3VibWl0IGEgcGF0Y2g/PGJyPg0KPGJyPg0KVHJ5ICZx
dW90O3BjaWNvbmYgLWwgfCBncmVwIF5oZGFjJnF1b3Q7LsKgIFlvdSYjMzk7bGwgc2VlIHN1YnZl
bmRvciBhbmQgc3ViZGV2aWNlLjxicj4NCjxicj4NCkpLPGJyPg0KPC9ibG9ja3F1b3RlPjwvZGl2
PjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9z
aWduYXR1cmUiPjxkaXYgZGlyPSJsdHIiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMTAyLDEwMiwx
MDIpIj5OdW5vIFRlaXhlaXJhPGJyPkZyZWVCU0QgQ29tbWl0dGVyIChwb3J0cyk8L3NwYW4+PC9k
aXY+PC9kaXY+DQo=
--000000000000629c7105e715e606--

From nobody Thu Aug 25 20:24:44 2022
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 4MDDwF1TsYz4ZR7B
	for ; Thu, 25 Aug 2022 20:24:45 +0000 (UTC)
	(envelope-from jkim@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MDDwF109zz3lKD;
	Thu, 25 Aug 2022 20:24:45 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661459085;
	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=JAg2vQj+xWK2LvuC6v7/J2ZR/eSvrdbopgOkrjMwna0=;
	b=xe4QkOiR3WL6NUzdI8bUXM2Y2nKWYxxdjRmFlx4k62R4oSkuiw1KXORCqVs/he2wQETh/a
	AU2lZjvJ7tgiJpzKLUHX9YYZ8i5FHPcmnXj5ExU+2LcqSclV05qCRaInnKf5igiR2itvAC
	bvza+OXeF6hkDZuI/aixEv5bNZtQJb4IZyvTsKwEUJmnuZ5Q2mgFx4JBQcUVy8IAKaNRci
	Go9YG0rmwglW/KvW7y2qkYCRBvymYwz2/DvgxlpZe2p1O227l1OVv+ilvfoLPD2TsqVC2U
	b2BElSXzR2cxbTA66KR4pXpVXbxutarALEueEWsUaQ3rCFHqO7cFY/f35RzAWw==
Received: from freefall.freebsd.org (unknown [IPv6:2600:4040:a6cb:8100:199e:97d:f8a6:b434])
	(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: jkim/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MDDwD6bZFzq8g;
	Thu, 25 Aug 2022 20:24:44 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
Message-ID: <385387e0-9dae-d797-1af0-05cd44b4300c@FreeBSD.org>
Date: Thu, 25 Aug 2022 16:24:44 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: Lenovo Legion 5 Intel speakers working ok!
Content-Language: en-US
To: Nuno Teixeira 
Cc: FreeBSD CURRENT 
References: 
 
 <94e271b7-3019-a377-bb8b-e681c78b0d82@FreeBSD.org>
 
From: Jung-uk Kim 
Organization: FreeBSD.org
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------ssnj95LrMDAtFzl8ZNfTpzhp"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661459085;
	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=JAg2vQj+xWK2LvuC6v7/J2ZR/eSvrdbopgOkrjMwna0=;
	b=B/KwO5PKYLrmP0l5toYiKdpNzvR0ud3b33OPbAWWYKYK1u5xji6DYD9vZPYzxrrLC9AdHz
	5sLp/2YIWVyTsmlv9zFAG4lwukEHi23ccOg+I4On/Zrf7cnF5PJgYtq0y/90F6C3IUF3M7
	R8F3W39yBbT4E+eK3PdM3ANAyD9hB1SR+lBHUDdmtGqjVseoBaxCetQ8nm0mUAvlrgrdua
	siacyYIMm+3APZyqD95WjtHPJcmWGGQOEKUMo288cim8ihpqL+huIw9jWLO2Jyp1+NRmwi
	QRJpGjEkzK4PmYUMMMsQIq1dgKWDfQsu3JMG85spMcftktU3RLgx+VkxP/SnUg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661459085; a=rsa-sha256; cv=none;
	b=w108uaNrP1nzhd62+pbN8VIj7neTTWQjHp5O0jIYAz8i1EQnqjYq2tEikMJjNSlybHJuSc
	zPVdTTgsKrKb8uroQxWQQx4FvMH6Kpzbn+6JtR5L+CJj0cClH5PDw+5+Rg5eo++xyhxOQ2
	31JAS6qYcDYWGQK2sa4GRsxKZZ5p+l6qp5AyzuR+xHm/GmXBRpd/PLzZPZR3jcHUTgeMC6
	iKj4yDZV6t9IraIo76YwqHHayMYMkw/qxH7uOfRqbcmW4YTlFTHfdeYWZ6JOJP2tKszc8w
	MBX8m/mOb4nt0BolzyC9sAOGkDr0PzOjMV4NU3NX2UgBFUD9AN01VBz3Q+ddPg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------ssnj95LrMDAtFzl8ZNfTpzhp
Content-Type: multipart/mixed; boundary="------------CA6a20WazsJNy0AHaC5XewM2";
 protected-headers="v1"
From: Jung-uk Kim 
To: Nuno Teixeira 
Cc: FreeBSD CURRENT 
Message-ID: <385387e0-9dae-d797-1af0-05cd44b4300c@FreeBSD.org>
Subject: Re: Lenovo Legion 5 Intel speakers working ok!
References: 
 
 <94e271b7-3019-a377-bb8b-e681c78b0d82@FreeBSD.org>
 
In-Reply-To: 

--------------CA6a20WazsJNy0AHaC5XewM2
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjIuIDguIDI1LiwgTnVubyBUZWl4ZWlyYSB3cm90ZToNCj4gSGkhDQo+IA0KPiBgcGNp
Y29uZiAtbCB8IGdyZXAgXmhkYWNgOg0KPiAtLS0NCj4gaGRhYzFAcGNpMDowOjMxOjM6IMKg
IMKgIMKgY2xhc3M9MHgwNDAzODAgcmV2PTB4MDAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiAN
Cj4gZGV2aWNlPTB4MDZjOCBzdWJ2ZW5kb3I9MHgxN2FhIHN1YmRldmljZT0weDM4MGYNCj4g
Xl5eXiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IA0KPiBeXl5eXsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgXl5eXg0KPiBo
ZGFjMEBwY2kwOjE6MDoxOiDCoCDCoCDCoCBjbGFzcz0weDA0MDMwMCByZXY9MHhhMSBoZHI9
MHgwMCB2ZW5kb3I9MHgxMGRlIA0KPiBkZXZpY2U9MHgxMGZhIHN1YnZlbmRvcj0weDE3YWEg
c3ViZGV2aWNlPTB4M2ZmYg0KPiAtLS0NCj4gDQo+IEkgdGhpbmsgaGRhYzEgaXMgd2hhdCBJ
J20gbG9va2luZyBmb3I6DQo+IC0tLQ0KPiBoZGFjMUBwY2kwOjA6MzE6MzogwqAgwqAgwqBj
bGFzcz0weDA0MDM4MCByZXY9MHgwMCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IA0KPiBkZXZp
Y2U9MHgwNmM4IHN1YnZlbmRvcj0weDE3YWEgc3ViZGV2aWNlPTB4MzgwZg0KPiAgwqAgwqAg
dmVuZG9yIMKgIMKgID0gJ0ludGVsIENvcnBvcmF0aW9uJw0KPiAgwqAgwqAgZGV2aWNlIMKg
IMKgID0gJ0NvbWV0IExha2UgUENIIGNBVlMnDQo+ICDCoCDCoCBjbGFzcyDCoCDCoCDCoD0g
bXVsdGltZWRpYQ0KPiAgwqAgwqAgc3ViY2xhc3MgwqAgPSBIREENCj4gLS0tDQo+IA0KPiAo
TEVOT1ZPX1ZFTkRPUklEIMKgIMKgIMKgIMKgIDB4MTdhYSkNCj4gDQo+IG1heWJlOg0KPiAj
ZGVmaW5lIExFTk9WT19MNUlOVEVMX1NVQlZFTkRPUiBIREFfTU9ERUxfQ09OU1RSVUNUKExF
Tk9WTywgMHgzODBmKSA/DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+
IF5eXl4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiBeXl5eDQoNCkkgZ3Vlc3MuIDot
KQ0KDQpKSw0KDQo+IEp1bmctdWsgS2ltIDxqa2ltQGZyZWVic2Qub3JnIDxtYWlsdG86amtp
bUBmcmVlYnNkLm9yZz4+IGVzY3JldmV1IG5vIGRpYSANCj4gcXVpbnRhLCAyNS8wOC8yMDIy
IMOgKHMpIDIwOjE1Og0KPiANCj4gICAgIE9uIDIyLiA4LiAyNS4sIE51bm8gVGVpeGVpcmEg
d3JvdGU6DQo+ICAgICAgPiAqKiBTYW1lIGNvbmZpZyB3ZXJlIGltcG9ydGVkIGZyb20gRDMw
MzMzDQo+ICAgICAgPiA8aHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0QzMDMzMw0KPiAg
ICAgPGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EMzAzMzM+PmZvciBMZWdpb24gNSBB
TUQsIFBSIDI2NTYzMg0KPiAgICAgID4gPGh0dHBzOi8vYnVncy5mcmVlYnNkLm9yZy9idWd6
aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MjY1NjMyDQo+ICAgICA8aHR0cHM6Ly9idWdzLmZyZWVi
c2Qub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0yNjU2MzI+PmZvciBJbnRlbA0KPiAg
ICAgdmVyc2lvbg0KPiAgICAgID4NCj4gICAgICA+IE51bm8gVGVpeGVpcmEgPGVkdWFyZG9A
ZnJlZWJzZC5vcmcgPG1haWx0bzplZHVhcmRvQGZyZWVic2Qub3JnPg0KPiAgICAgPG1haWx0
bzplZHVhcmRvQGZyZWVic2Qub3JnIDxtYWlsdG86ZWR1YXJkb0BmcmVlYnNkLm9yZz4+Pg0K
PiAgICAgID4gZXNjcmV2ZXUgbm8gZGlhIHF1aW50YSwgMjUvMDgvMjAyMiDDoChzKSAxOTo1
OToNCj4gICAgICA+DQo+ICAgICAgPsKgIMKgIMKgSGVsbG8sDQo+ICAgICAgPg0KPiAgICAg
ID7CoCDCoCDCoEkgaGF2ZSBMZW5vdm8gTGVnaW9uIDUgSW50ZWwgc3BlYWtlcnMgd29ya2lu
ZyBvayB3aXRoDQo+ICAgICBkZXZpY2UuaGludHM6DQo+ICAgICAgPsKgIMKgIMKgLS0tDQo+
ICAgICAgPsKgIMKgIMKgaGludC5oZGFhLjEubmlkMjAuY29uZmlnPSJhcz0xIHNlcT0wIg0K
PiAgICAgID7CoCDCoCDCoGhpbnQuaGRhYS4xLm5pZDMzLmNvbmZpZz0iYXM9MSBzZXE9MTUi
DQo+ICAgICAgPsKgIMKgIMKgLS0tDQo+ICAgICAgPg0KPiAgICAgID7CoCDCoCDCoFNhbWUg
Y29uZmlnIHdlcmUgaW1wb3J0ZWQgZnJvbSBEMzAzMzMNCj4gICAgICA+wqAgwqAgwqA8aHR0
cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0QzMDMzMw0KPiAgICAgPGh0dHBzOi8vcmV2aWV3
cy5mcmVlYnNkLm9yZy9EMzAzMzM+PmFuZCBQUiAyNjU2MzINCj4gICAgICA+wqAgwqAgwqA8
aHR0cHM6Ly9idWdzLmZyZWVic2Qub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0yNjU2
MzINCj4gICAgIDxodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvc2hvd19idWcu
Y2dpP2lkPTI2NTYzMj4+IGZvcg0KPiAgICAgID7CoCDCoCDCoExlZ2lvbiA1IEFNRDoNCj4g
ICAgICA+wqAgwqAgwqAoc3lzL2Rldi9zb3VuZC9wY2kvaGRhL2hkYWMuaCkNCj4gICAgICA+
wqAgwqAgwqAtLS0NCj4gICAgICA+wqAgwqAgwqAjZGVmaW5lIExFTk9WT19MNUFNRF9TVUJW
RU5ET1IgSERBX01PREVMX0NPTlNUUlVDVChMRU5PVk8sDQo+ICAgICAweDM4MWIpDQo+ICAg
ICAgPsKgIMKgIMKgLS0tDQo+ICAgICAgPsKgIMKgIMKgSG93IGRvIEkgZm91bmQgaWQgZm9y
IEludGVsIHZlcnNpb24gc28gSSBjYW4gc3VibWl0IGEgcGF0Y2g/DQo+IA0KPiAgICAgVHJ5
ICJwY2ljb25mIC1sIHwgZ3JlcCBeaGRhYyIuwqAgWW91J2xsIHNlZSBzdWJ2ZW5kb3IgYW5k
IHN1YmRldmljZS4NCg==

--------------CA6a20WazsJNy0AHaC5XewM2--

--------------ssnj95LrMDAtFzl8ZNfTpzhp
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAmMH2owFAwAAAAAACgkQfJ+WJvzb8Ubn
sAgAhzLcXjG3B72XHfXh7olkH1nADaktsAXWEqgCOsnolUS5Yjm8ZbclJoaSpEhtt1HqNHU7GM3+
/z7yeGlTYCFIpp+uEr/MLaJqhCoKFi9LGtS1IzoUWjyyRKPSSVqoNKfMRg7R+OgJO50KFaheLvOP
Ibxa2v6MdCssm+gp7ucr4oXGB6V/K9x4+ETexaaD/peRc62qHZ9TnRACrIOdOBdf+ro+QMBiF+fl
3lfxAh14zHgVhAuXN7I8WtoSNTB3C3q8JhKPFrfSZb6VuuodiZX5mT7ANliQNGPZhr7xzm46MuRG
Xe5CMSpwdAVN4hfgNFWl7dw9UVFbz+KzgSq9AVz6Ug==
=tdkO
-----END PGP SIGNATURE-----

--------------ssnj95LrMDAtFzl8ZNfTpzhp--

From nobody Fri Aug 26 16:51:07 2022
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 4MDm7W3k0qz4ZTT1
	for ; Fri, 26 Aug 2022 16:51:19 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MDm7W398Dz3MGV;
	Fri, 26 Aug 2022 16:51:19 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661532679;
	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=15SedzRPsWX4oon7MOTj08JusjpYd9C1uEKeWEallN0=;
	b=V2JJll5Eb3wntvgkuAYcMN0FmeHXwFarjaY0lp0+fShtvld70lwPgkOqa96KUNfP9sp4Di
	Q4yWvYDT1Pt09PyoNT5OBPcFb7DeZsQH/602wP/sZ/ObyL4IMIpLiFz3iocw3o6sc4TNUs
	OQBZZeB1dWLumFmJIU9e62hh2peVhpBeEjMLRr84JfLo6WKVh6gPzBmePCzuEWR9m/Mwh/
	/22Yli3Rv2K62A1chlKyTLbOmfueaZ/qxTSSEx6geyh0YY9xqhMQjPSSGljClawYtVMbhE
	58L0TPXPqw5w8Om5BzXkm8bBhqxs0Kb//spLaCkMy4dSebE6rulqKoSO9AOqlw==
Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MDm7W25VFz13bP;
	Fri, 26 Aug 2022 16:51:19 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-ua1-f43.google.com with SMTP id x15so377069uat.2;
        Fri, 26 Aug 2022 09:51:19 -0700 (PDT)
X-Gm-Message-State: ACgBeo3E6d5sYJYqZL7YRqz2BZUY70roV+xwRAyrjJ7MrYDp2OaROfBW
	ghcAYGRjtgQwaBuacCRGfqOz2g+AL6T+Xcia6cI=
X-Google-Smtp-Source: AA6agR5npwbB1qcZYglZZM+JOvciz8lwdem2aigo1aWU/UT36t7smwTZgcOAMUBur1iLb9dP2hx3S2S62XSbvv/bmUM=
X-Received: by 2002:ab0:20d2:0:b0:391:6cdb:bb with SMTP id z18-20020ab020d2000000b003916cdb00bbmr228492ual.13.1661532678833;
 Fri, 26 Aug 2022 09:51:18 -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: 
 
 <94e271b7-3019-a377-bb8b-e681c78b0d82@FreeBSD.org> 
 <385387e0-9dae-d797-1af0-05cd44b4300c@FreeBSD.org>
In-Reply-To: <385387e0-9dae-d797-1af0-05cd44b4300c@FreeBSD.org>
From: Nuno Teixeira 
Date: Fri, 26 Aug 2022 17:51:07 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Lenovo Legion 5 Intel speakers working ok!
To: Jung-uk Kim 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000001acb2e05e727b9d9"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661532679;
	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=15SedzRPsWX4oon7MOTj08JusjpYd9C1uEKeWEallN0=;
	b=goYcd+lu8GjsO6Omd2OajZO2/ErnThZ9KWIXWJcSIkJ3uVrD5C/i29nflm9zmb4mCVbfkI
	fTrhTp0nQoe8cl9Q9z9YjYM9R1RNy2xc9/qfKDhw0eIKMsGOJtGXKNZnFRCHqGTxXPyFEx
	AtcIZAuQo6k0X67LQEiIvkkP0ybAosEhB3NSQmBTEu5vcy632Ff+6dgrOQoAd+WRgs6sCh
	Qp3ENZTgtj/H9WPVkburOFytfEgPXwC7vdB9klY4CUX44e9rWPQYOfmOtLPDh4EOWtFt8+
	vDTpOAgtb4A6z6Q4pu5/f7vGBsT9DZuVS6zdwY2IlVjWPgwp1aTUKVFDNlLjmg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661532679; a=rsa-sha256; cv=none;
	b=a4P1MedXJgcHfJuXv0hE7se9RjruoRzkNKSDd5MEkAzosz9OrYldStwjwq+a/wsqb54qBq
	WZ9JqyUAe+qe4u/fH9aL9dQ+KgYNfdNjScBupNnllVaAVbf6jKW+IETDQTjvZjhODj89gy
	te2aGqNgdTGSUeMNsKRNKAzl6IP86RMJYbWVYK1Ss2rN+8EnXks1YT8xI2ylnAWVXYnEOO
	0dGxse4hQ02KR3kkMTjWBWHKvlzafI8TxREAUnrun/8V4WTkveLhzhVU1IJ6ivj4kqoFlz
	F3qkhK1cxu1ICKWRpMec4jvJFqbwJXk2N0F1R7FoAwWlC8K25+WcTR47FeOG4w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000001acb2e05e727b9d9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all!

patch ready and tested at PR 265632


Cheers,

Jung-uk Kim  escreveu no dia quinta, 25/08/2022 =C3=A0(s)
21:24:

> On 22. 8. 25., Nuno Teixeira wrote:
> > Hi!
> >
> > `pciconf -l | grep ^hdac`:
> > ---
> > hdac1@pci0:0:31:3:      class=3D0x040380 rev=3D0x00 hdr=3D0x00 vendor=
=3D0x8086
> > device=3D0x06c8 subvendor=3D0x17aa subdevice=3D0x380f
> > ^^^^
>
>
> > ^^^^^                  ^^^^
> > hdac0@pci0:1:0:1:       class=3D0x040300 rev=3D0xa1 hdr=3D0x00 vendor=
=3D0x10de
> > device=3D0x10fa subvendor=3D0x17aa subdevice=3D0x3ffb
> > ---
> >
> > I think hdac1 is what I'm looking for:
> > ---
> > hdac1@pci0:0:31:3:      class=3D0x040380 rev=3D0x00 hdr=3D0x00 vendor=
=3D0x8086
> > device=3D0x06c8 subvendor=3D0x17aa subdevice=3D0x380f
> >      vendor     =3D 'Intel Corporation'
> >      device     =3D 'Comet Lake PCH cAVS'
> >      class      =3D multimedia
> >      subclass   =3D HDA
> > ---
> >
> > (LENOVO_VENDORID         0x17aa)
> >
> > maybe:
> > #define LENOVO_L5INTEL_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x380f) ?
> >
> > ^^^^
>
> > ^^^^
>
> I guess. :-)
>
> JK
>
> > Jung-uk Kim > escreveu no
> dia
> > quinta, 25/08/2022 =C3=A0(s) 20:15:
> >
> >     On 22. 8. 25., Nuno Teixeira wrote:
> >      > ** Same config were imported from D30333
> >      >  >     >for Legion 5 AMD, PR 265632
> >      >  >     >for In=
tel
> >     version
> >      >
> >      > Nuno Teixeira 
> >     >>
> >      > escreveu no dia quinta, 25/08/2022 =C3=A0(s) 19:59:
> >      >
> >      >     Hello,
> >      >
> >      >     I have Lenovo Legion 5 Intel speakers working ok with
> >     device.hints:
> >      >     ---
> >      >     hint.hdaa.1.nid20.config=3D"as=3D1 seq=3D0"
> >      >     hint.hdaa.1.nid33.config=3D"as=3D1 seq=3D15"
> >      >     ---
> >      >
> >      >     Same config were imported from D30333
> >      >      >     >and PR 265632
> >      >      >     > for
> >      >     Legion 5 AMD:
> >      >     (sys/dev/sound/pci/hda/hdac.h)
> >      >     ---
> >      >     #define LENOVO_L5AMD_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO,
> >     0x381b)
> >      >     ---
> >      >     How do I found id for Intel version so I can submit a patch?
> >
> >     Try "pciconf -l | grep ^hdac".  You'll see subvendor and subdevice.
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000001acb2e05e727b9d9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi all!

patch ready and test=
ed at PR 265632

Cheers,

Jung-uk Kim <<=
a href=3D"mailto:jkim@freebsd.org">jkim@freebsd.org> escreveu no dia=
 quinta, 25/08/2022 =C3=A0(s) 21:24:
On 22. 8. 25., Nuno Teixeira wrote:

> Hi!

> 

> `pciconf -l | grep ^hdac`:

> ---

> hdac1@pci0:0:31:3: =C2=A0 =C2=A0 =C2=A0class=3D0x040380 rev=3D0x00 hdr=
=3D0x00 vendor=3D0x8086 

> device=3D0x06c8 subvendor=3D0x17aa subdevice=3D0x380f

> ^^^^=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

> ^^^^^=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^^^^

> hdac0@pci0:1:0:1: =C2=A0 =C2=A0 =C2=A0 class=3D0x040300 rev=3D0xa1 hdr=
=3D0x00 vendor=3D0x10de 

> device=3D0x10fa subvendor=3D0x17aa subdevice=3D0x3ffb

> ---

> 

> I think hdac1 is what I'm looking for:

> ---

> hdac1@pci0:0:31:3: =C2=A0 =C2=A0 =C2=A0class=3D0x040380 rev=3D0x00 hdr=
=3D0x00 vendor=3D0x8086 

> device=3D0x06c8 subvendor=3D0x17aa subdevice=3D0x380f

>=C2=A0 =C2=A0 =C2=A0 vendor =C2=A0 =C2=A0 =3D 'Intel Corporation=
9;

>=C2=A0 =C2=A0 =C2=A0 device =C2=A0 =C2=A0 =3D 'Comet Lake PCH cAVS&=
#39;

>=C2=A0 =C2=A0 =C2=A0 class =C2=A0 =C2=A0 =C2=A0=3D multimedia

>=C2=A0 =C2=A0 =C2=A0 subclass =C2=A0 =3D HDA

> ---

> 

> (LENOVO_VENDORID =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x17aa)

> 

> maybe:

> #define LENOVO_L5INTEL_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x380f) ?=


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

> ^^^^=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 

> ^^^^



I guess. :-)



JK



> Jung-uk Kim <=
jkim@freebsd.org <mailto:jkim@freebsd.org>> escreveu no dia 

> quinta, 25/08/2022 =C3=A0(s) 20:15:

> 

>=C2=A0 =C2=A0 =C2=A0On 22. 8. 25., Nuno Teixeira wrote:

>=C2=A0 =C2=A0 =C2=A0 > ** Same config were imported from D30333

>=C2=A0 =C2=A0 =C2=A0 > <https://reviews.freebsd.org/D303=
33

>=C2=A0 =C2=A0 =C2=A0<https://reviews.freebsd.org/D30333=
>>for Legion 5 AMD, PR 265632

>=C2=A0 =C2=A0 =C2=A0 > <https://=
bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265632

>=C2=A0 =C2=A0 =C2=A0<https://bugs.f=
reebsd.org/bugzilla/show_bug.cgi?id=3D265632>>for Intel

>=C2=A0 =C2=A0 =C2=A0version

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 > Nuno Teixeira <eduardo@freebsd.org <mailto:eduardo@freebsd.org><=
br>
>=C2=A0 =C2=A0 =C2=A0<mailto:eduardo@freebsd.org <mailto:eduardo@freebsd.org>>>

>=C2=A0 =C2=A0 =C2=A0 > escreveu no dia quinta, 25/08/2022 =C3=A0(s) =
19:59:

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Hello,

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I have Lenovo Legion 5 Int=
el speakers working ok with

>=C2=A0 =C2=A0 =C2=A0device.hints:

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0---

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0hint.hdaa.1.nid20.config=
=3D"as=3D1 seq=3D0"

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0hint.hdaa.1.nid33.config=
=3D"as=3D1 seq=3D15"

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0---

>=C2=A0 =C2=A0 =C2=A0 >

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Same config were imported =
from D30333

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<https://revie=
ws.freebsd.org/D30333

>=C2=A0 =C2=A0 =C2=A0<https://reviews.freebsd.org/D30333=
>>and PR 265632

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265632<=
br>
>=C2=A0 =C2=A0 =C2=A0<https://bugs.f=
reebsd.org/bugzilla/show_bug.cgi?id=3D265632>> for

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Legion 5 AMD:

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0(sys/dev/sound/pci/hda/hda=
c.h)

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0---

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0#define LENOVO_L5AMD_SUBVE=
NDOR HDA_MODEL_CONSTRUCT(LENOVO,

>=C2=A0 =C2=A0 =C2=A00x381b)

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0---

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0How do I found id for Inte=
l version so I can submit a patch?

> 

>=C2=A0 =C2=A0 =C2=A0Try "pciconf -l | grep ^hdac".=C2=A0 You&=
#39;ll see subvendor and subdevice.




-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--0000000000001acb2e05e727b9d9--

From nobody Fri Aug 26 16:55:36 2022
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 4MDmDh6QWrz4ZTsp
	for ; Fri, 26 Aug 2022 16:55:48 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MDmDh5cn3z3Nf7
	for ; Fri, 26 Aug 2022 16:55:48 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661532948;
	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=JoGdgGo0pDLjyYN0/dNipmtrjTQRN4tAtB1JcACQFr8=;
	b=F4EVGvlnF8dz6DPAxqk9D8TXKZTjSimu1rwvBYG5NIkOEOcT2qsrQYflTq6ByXvyQzS9rc
	KLuvEHF9bh+Fuj1HiK0QBWyv/9hpvGfbq8Vu/dNZjUym266PfFLXeYmr5vQ9VZu3wiBY3y
	tzhjQX0RWBlOxxJUJwvy+tjFNnbVtJlxaAWe6uwydspd479747Nspi/4bzpuHV1OFmtQxL
	h0IiXK4nO5tTyD8B9j3LztpovQ36eN2KJIWXYJ92OPHLht2sHRHi8T9ne0mg3/Dt2qfmKT
	jb4auRFH+Vapjg0S6nVBrUvmoAt5UfI1RlUMizhu/Y/r7zNKx9YZCGDCoLSqTA==
Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MDmDh4Q2jz13MH
	for ; Fri, 26 Aug 2022 16:55:48 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f181.google.com with SMTP id o198so929587vko.4
        for ; Fri, 26 Aug 2022 09:55:48 -0700 (PDT)
X-Gm-Message-State: ACgBeo3lmk/B/OzBLAv7KJCG1vRMDPTypke+MZxl1FX6aQrCGe3Ygk+r
	FzbUCYd8zPHU0YsxqJR+tDtSK7IeJpfWM2JCGfs=
X-Google-Smtp-Source: AA6agR6Q1Xz8Nj5k0GjLIcAZNqe4sBDtfszqZGZxDzRipANg3nd/SeWNNiHKMdWiloqWq9Z24sxrdM5xqdXVhiTQ900=
X-Received: by 2002:a05:6122:12a3:b0:38c:4d0b:f5bd with SMTP id
 j3-20020a05612212a300b0038c4d0bf5bdmr246700vkp.25.1661532947913; Fri, 26 Aug
 2022 09:55:47 -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: Nuno Teixeira 
Date: Fri, 26 Aug 2022 17:55:36 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: main-n257625-587649902329-dirty?
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="00000000000024a21805e727c920"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661532948;
	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=JoGdgGo0pDLjyYN0/dNipmtrjTQRN4tAtB1JcACQFr8=;
	b=A+ry26TV9kRh9LYmQgGeIcqi79bveLM+v0lSduspxgRF0qQ0ytXE4nkzpMYAzxwwxo9DQL
	oLf3hPX8YCrwE3gboZhzi5jR/BeGe3Nd1mZnCznYn7ocsYo3rKCPhmS2cbylDLJwgRqSJd
	a9kXiDp3rqI0p1m50UHPFAKt1hrGjSvNu3ZV0iUZ1McuWGlCwVHliWmEaHyPDcXs7TnyDg
	ZnWTye/8HTq3lM2bFRHgBbGrSfqlNzL3DbmrwG86qztoyX5l56EDbDCBrxnbcDofFOg7zr
	IiEgwRiG6SlAqDK26Ey6lVeQMcSBGy8dmFnPsITfKHn3xEFPM4SQD0uLPCDNEg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661532948; a=rsa-sha256; cv=none;
	b=NZZvorit5VFmn1GrlHnMKwCEXR0ztqpvD+rnL91LwYEZ5OSO5mW8rptNx5qKIqlyES6XqY
	npWgN7PNv/A/5ZmaT51HGUi0Udd3XWhJco2Ow0prssVn+NzlqfzmYL9J7lYqOM4BXKfTOe
	maOnQmbta4E2PmyfhzRSvOeWH/HJFSI/zNrCOUfDqBj32Mfmxm53fbR7ezk0lrnuFDeIZX
	l0wjPw6kED6/ZvDjL3zLd2YiwVhOBpTUy7eYcwUYIS8WwQRbK82pK/70RkAmuCYuPHk8W1
	66E0lIhN50pMn7LUvyn1cPOf1rn5GGyNdixx05Utp0XZX7cfmGzqfCysW1+SqQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--00000000000024a21805e727c920
Content-Type: text/plain; charset="UTF-8"

Hello to all,

Today I updated and uname -a shows main-n257625-587649902329-dirty.
Why is showing -dirty?

Cheers,
-- 
Nuno Teixeira
FreeBSD Committer (ports)

--00000000000024a21805e727c920
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello to all,

Today I update=
d and uname -a shows main-n257625-587649902329-dirty.
Why is show=
ing -dirty?

Cheers,
-- 
=
Nuno Teixeira
FreeBSD Committer (=
ports)


--00000000000024a21805e727c920--

From nobody Fri Aug 26 17:02:52 2022
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 4MDmP3030Yz4ZVXw
	for ; Fri, 26 Aug 2022 17:03:03 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MDmP156Zxz3QMG;
	Fri, 26 Aug 2022 17:03:01 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id 6f9becd8;
	Fri, 26 Aug 2022 17:02:54 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 4648eccb (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Fri, 26 Aug 2022 17:02:54 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-823F6A4A-96FD-4D78-8266-3A1548AD089E
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 (1.0)
Subject: Re: main-n257625-587649902329-dirty?
From: Michael Gmelin 
In-Reply-To: 
Date: Fri, 26 Aug 2022 19:02:52 +0200
Cc: FreeBSD CURRENT 
Message-Id: 
References: 
To: Nuno Teixeira 
X-Mailer: iPhone Mail (19G82)
X-Rspamd-Queue-Id: 4MDmP156Zxz3QMG
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[freebsd.org];
	FREEFALL_USER(0.00)[grembo];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail-823F6A4A-96FD-4D78-8266-3A1548AD089E
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On 26. Aug 2022, at 18:55, Nuno Teixeira  wrote:
>=20
> =EF=BB=BF
> Hello to all,
>=20
> Today I updated and uname -a shows main-n257625-587649902329-dirty.
> Why is showing -dirty?
>=20

This means that the git workdir it was built on was dirty, see https://remar=
kablemark.org/blog/2017/10/12/check-git-dirty/

Cheers
Michael


--Apple-Mail-823F6A4A-96FD-4D78-8266-3A1548AD089E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 26. Aug 2022, at 18=
:55, Nuno Teixeira <eduardo@freebsd.org> wrote:

=EF=BB=BF
Hello to all,

Today I updated and uname -a shows m=
ain-n257625-587649902329-dirty.
Why is showing -dirty?
<=
br>

This means that the gi=
t workdir it was built on was dirty, see https://remarkablemark.org/blog/20=
17/10/12/check-git-dirty/

Cheers
Mich=
ael

=

--Apple-Mail-823F6A4A-96FD-4D78-8266-3A1548AD089E--

From nobody Fri Aug 26 17:07:52 2022
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 4MDmVr2PbRz4ZW6K
	for ; Fri, 26 Aug 2022 17:08:04 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MDmVr1dt6z3SQ2;
	Fri, 26 Aug 2022 17:08:04 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661533684;
	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=RL+YSxe9h+YxxXlUw9Y9boNZdM27W/IYhQFFoCjPyfs=;
	b=aqicn2mX4kt+N0uKc4XoroJ31P15uQ8RMNdhRJ1vTDXKDZS3H6vxEHOnwyBaH5+F1KfumS
	ROTAhiQk1hg4RNAA74kPLcJvFN5C4TBh0boi/UnsLVPZXX3sIYSf7CeRSKhnf1EE7qDdRS
	naml1aZjVOJhz+K6F1S1Ip/IYRcpYx7+gUSWxrIW/RqqLtnf2sCisbbBgLdNwxg88sJ4Oi
	sLaetC67Z5V7wFpOUJwTnqnHbx+R0jvODLXIAKQDGnnZ1rhApZFoU8xaA3TNQbtvwozphM
	/nFHQUcFAYbAntLq3n80PAEkklzCnC2azrhwnhLhkvLDNAIgI+OffBalT+e+8g==
Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MDmVr0Vz1z13dN;
	Fri, 26 Aug 2022 17:08:04 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f50.google.com with SMTP id k2so2218054vsk.8;
        Fri, 26 Aug 2022 10:08:04 -0700 (PDT)
X-Gm-Message-State: ACgBeo1HQz8g35X/qFGG8AGEzrwyUF3z7knZTdPCLloh4IHDNU+JKdPJ
	E3nlD0K8UNwJN8s7uy8guVpbAAntG997I96iqU8=
X-Google-Smtp-Source: AA6agR6DIz9/EW+TGYJzX0mZu5JXhYb2+Bwex2qKuAtkuSeT3QKWOtL3kptHSRjZtvs3jdSIjfz39sclopLWQ+R11nA=
X-Received: by 2002:a67:f3cb:0:b0:390:8bbd:adce with SMTP id
 j11-20020a67f3cb000000b003908bbdadcemr288894vsn.11.1661533683663; Fri, 26 Aug
 2022 10:08:03 -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: Nuno Teixeira 
Date: Fri, 26 Aug 2022 18:07:52 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: main-n257625-587649902329-dirty?
To: Michael Gmelin 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000ff49bd05e727f466"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661533684;
	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=RL+YSxe9h+YxxXlUw9Y9boNZdM27W/IYhQFFoCjPyfs=;
	b=MHHkS8DEwKNTPmBNZNLUGW3E8drLql5QQreHs6PPu6cLRG5bxBTEYAec0cr+jQaus6HfwS
	ZA1IhPAaJcJQ2mJaf2Uh1x2T3WTAPfAhRO2zHdunsRGgXLOCyMWSqpOFP4PN2oOnEma5t3
	0y6PRDXguyXGG2HEs9Absau26cRh8EHWhQL25cVjhwNhyolOLr+vzTTlxY4OM4/ntTX71T
	Jg+C/YpNLbFK5c2VyQYALhYyYNbr8kRJF+K7Tz8L+4vbdMTOgUEy8QumnVfznpSSgaxISF
	s6nGlRfRdH962CbkqzBfp8CYnRFByvhY2YV8YbDETo1sZsRl+pQk65u3gFO+lg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661533684; a=rsa-sha256; cv=none;
	b=YuPdQ2cj7chQDY7JVzkyZ/vVm+pF1yMUqiL+t4iBXOTLCQsdMN4CjEDysTROlaMjgxVJnp
	rFf9W2U0xAQsymNAXJi221xiKVEk3x5dToF4YEsGrxDiX49uHCiTr+SszcZp22xNsgK1qK
	TqXtQtNOg1FcnUD17uzDvnjxurQK4NIuZGEGvM1y6VVsh0UE8yw+tlkiVmWZ9zNgyrJFxg
	L3ZiFuxHI1oAjsI1BoNc7FXl7QUA7hv2ge3LdReqppWvmjyCWAaZnXf1iD3KeE+ckFsA3x
	1NnNu1QQ3aaHsGfj2YiDvkFvhGOZCzPZcbhpJflDuLht5y48c22QkK4IAFkkGg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000ff49bd05e727f466
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Yes I understand it now! It's because I patched kernel for PR 265632


Thanks and sorry for the noise,

Michael Gmelin  escreveu no dia sexta, 26/08/2022 =C3=
=A0(s)
18:03:

>
>
> On 26. Aug 2022, at 18:55, Nuno Teixeira  wrote:
>
> =EF=BB=BF
> Hello to all,
>
> Today I updated and uname -a shows main-n257625-587649902329-dirty.
> Why is showing -dirty?
>
>
> This means that the git workdir it was built on was dirty, see
> https://remarkablemark.org/blog/2017/10/12/check-git-dirty/
>
> Cheers
> Michael
>
>

--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000ff49bd05e727f466
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

Yes I understand it now!=
 It's because I patched kernel for PR 265=
632

=

Thanks and sorr=
y for the noise,

Michael Gmelin <grembo@freebsd.org> escreveu no dia sexta, 26/08/2022=
 =C3=A0(s) 18:03:


On 26. Aug 2022, at 18:55, Nuno T=
eixeira <eduard=
o@freebsd.org> wrote:

=EF=BB=BF
Hello to all,

Today I updated and uname -a shows main-n257625-587649902=
329-dirty.
Why is showing -dirty?


This means that the git workdir it was bu=
ilt on was dirty, see=C2=A0https://remarkablemark.org/blog/2=
017/10/12/check-git-dirty/

Cheers
Mi=
chael



--=
 
Nuno Teixeira
FreeBSD Committer (ports)


--000000000000ff49bd05e727f466--

From nobody Fri Aug 26 18:37:19 2022
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 4MDpTv5T4nz4Zfyg
	for ; Fri, 26 Aug 2022 18:37:23 +0000 (UTC)
	(envelope-from se@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MDpTv505Gz3cbM;
	Fri, 26 Aug 2022 18:37:23 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661539043;
	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=gnNc5PrKUdauxF6VDorD6C5h+tbjgbxg7NDiAGcKJPY=;
	b=rUC6350HZsXpOKGNylfAK1lWnuqToOsQ6GLOxxr8CtzSGA4WoPhK9KN5x+XUIuYZOD+xAu
	CLSLc7ToI7+I5x57b7yoScMyDBsnYUagw+OH2nhfhkfb0/GgCTeXdvv+QJFV4zNo4Rg+ch
	9YodZrdA3EHsBiA2mAfFyX7/SOse/d5r1p0WFIxFMqa59vtq5kqgiJ1I+IKV9/Kpk15R4E
	TrEg5ZKtHERSMR41kSRD5UVY8iV6vpskanBSE+LCL6zrzwP2TEWEJDNw16+XSOmMCGaP7A
	UQHxeCnbln+NjjlJLkDBmpL65EGRLtIrkGujAqgZM2tluT+oEVWpLkSU4h38Uw==
Received: from [IPV6:2003:cd:5f1a:d200:d49f:44f5:7ca1:a2ef] (p200300cd5f1ad200d49f44f57ca1a2ef.dip0.t-ipconnect.de [IPv6:2003:cd:5f1a:d200:d49f:44f5:7ca1:a2ef])
	(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: se/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MDpTt74Qqz13w5;
	Fri, 26 Aug 2022 18:37:22 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
Message-ID: <047d1b0a-ce9f-1cf3-b85e-dc9a0f72b47a@FreeBSD.org>
Date: Fri, 26 Aug 2022 20:37:19 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.0
Subject: Re: main-n257625-587649902329-dirty?
Content-Language: de-DE, en-US
To: Nuno Teixeira 
References: 
From: Stefan Esser 
Cc: FreeBSD CURRENT 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661539043;
	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=gnNc5PrKUdauxF6VDorD6C5h+tbjgbxg7NDiAGcKJPY=;
	b=QSYKuEJUfaWNhTMQHkZmny/PsSLumu0Sh7FebsM7H1I34txR/kzQoZ2LWsgTH3nWrkYun4
	mdEEZk1vvgGK0s+9pboxs6WDhhp/Qpeex7mJrM0is7iwsT34uo3cp6tafyul5nSi7Eye0t
	xtlEEVMLJlKoSx5zrYgXejM2NF+Ycjyp8wrNbznU8p3rl2hqMmCBtgNHcnPUckqcHTDAGu
	QaCFMiwTw7Qz+khcY7N9GIJ5StCAonuFQWvGc8HSfqwaLMg0QZxQOvzKj8nucNDr1mf7Vb
	zqdkGG2YxKS8deFMgutwlTGrfG+GJ/beG1BBm/HiRFgDiQYhAuXX8iuA6jq6ww==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661539043; a=rsa-sha256; cv=none;
	b=waeJXdHA9P6npUkyb4jTAPqXnaKKNH2kENMy2J5zlGIuXq+JwlAKbsPR0sZmAFyfistrkL
	rDEr3bfXuNtj+MwftalAD2TW4KeVcM3sHvq6fA9oMr10qapXBEbqhaS6hfAnysGQOsh9FW
	nCVHzq/X5du4po8IP9zLIqed999hsSFb51EaLlWaBiCAr6SZGghBP4HNtkxbck4ooHclRi
	LTc1+n8pwYXOTb6qhA5XxaKWfKMLmqsWZGqxhSVXUju1aBJCWorUgY5ac8N7QeK1E9+uDC
	rFjxv5Ps5rWRR4SWuNZlGBC6Zisycf/ViFRuUvK2MiP3iWmRDo4Y2VYdUdU+yw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

Am 26.08.22 um 18:55 schrieb Nuno Teixeira:
> Hello to all,
> 
> Today I updated and uname -a shows main-n257625-587649902329-dirty.
> Why is showing -dirty?

The -dirty tag is appended to the commit if there are local changes,
i.e., your system has been built using Git commit 587649902329 with
uncommitted changes.

Regards, STefan

From nobody Sat Aug 27 06:30:15 2022
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 4MF6KB46ylz4ZfRl;
	Sat, 27 Aug 2022 06:30:54 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MF6K93zYVz3XHC;
	Sat, 27 Aug 2022 06:30:53 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by smtp5.goneo.de (Postfix) with ESMTPS id 9441010A1E8F;
	Sat, 27 Aug 2022 08:30:45 +0200 (CEST)
Received: from hub2.goneo.de (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPS id BA5D010A32C0;
	Sat, 27 Aug 2022 08:30:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
	s=DKIM001; t=1661581843;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=JQomZghXe77ojZTg1tCuNYX27Raoi4/1oYHJWoQAWHE=;
	b=aCnGW9OGaNR52VMDD72lEF3glQqPtN/CWuvl8+nSTgzvXCMeBVSojyVn1KXBuvlVJLwESJ
	TW2y98bUQM0fRXspff2gmSavnC751Ze0AgJfzxcnzOziKPWGxIAC8CHP1Jin0896iy455d
	kP00AZ1mzDZpzzOSKBIKVxda52Sm8WLBch5woZPPFBJRNflxIai6WjNeiR0f4e81nBOEgx
	vGvMX2uVPnL4cR2XzBbqyPm4hOH64051VG1efjHvxsey4kIbl0nQPD0fqYBmj6d6Erp5qx
	oMEvqPDq/bnJI/jbvcXIaYyMlkQqmtEjNjLue9ANRwrfxFvfKbMyfi3yFEuSfA==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-183-115-239.77.183.pool.telefonica.de [77.183.115.239])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPSA id 74FFB10A333C;
	Sat, 27 Aug 2022 08:30:43 +0200 (CEST)
Date: Sat, 27 Aug 2022 08:30:15 +0200
From: FreeBSD User 
To: FreeBSD CURRENT , FreeBSD Ports
 
Cc: yasu@freebsd.org
Subject: security/clamav: /ar/run on TMPFS renders the port broken by design
Message-ID: <20220827083042.73e7f439@thor.intern.walstatt.dynvpn.de>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-UID: 8d63a0
X-Rspamd-UID: 293425
X-Rspamd-Queue-Id: 4MF6K93zYVz3XHC
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=aCnGW9OG;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.60) smtp.mailfrom=freebsd@walstatt-de.de
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[walstatt-de.de:+];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[walstatt-de.de];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hello,

I'm referencing to Bug 259699 [2] and Bug 259585 [1].

Port security/clamav is without doubt for many of FreeBSD users an important piece of security
software so I assume a widespread usage.

It is also a not uncommon use case to use NanoBSD or any kind of low-memory-footprint
installation schemes in which /var/run - amongst other system folders - are created at boot
time as TMPFS and highly volatile.

In our case, the boxes running a small security appliance based upon FreeBSD is rebooted every
24 hours and so /var/run is vanishing.

To make the long story short:

The solution for this problem would be a check for existence and take action addendum in
precmd() routine of the rc-script as sketched in Bug 259699.
The maintainer rejects such a workaround by arguing this would violate POLA (see comment 4 in
PR 259699 [2]. The maintainer's argument regaring to mtree's files are sound to me.

The question is: how can this issue be solved?

It is really hard to always chenge our local repository and patch whenever clamav has been
patched and modified for what reason ever.

Tahanks for reading,

kind regards

O. Hartmann

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259585
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259699


-- 
O. Hartmann

From nobody Sat Aug 27 07:18:31 2022
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 4MF7NG13nSz4Zkcy
	for ; Sat, 27 Aug 2022 07:18:38 +0000 (UTC)
	(envelope-from chris@cretaforce.gr)
Received: from relay1.cretaforce.gr (relay1.cretaforce.gr [195.201.253.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-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "*.cretaforce.gr", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MF7ND4jtMz3dBk
	for ; Sat, 27 Aug 2022 07:18:36 +0000 (UTC)
	(envelope-from chris@cretaforce.gr)
Received: from server1.cretaforce.gr (server1.cretaforce.gr [94.130.217.104])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "*.cretaforce.gr", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK))
	by smtp1.cretaforce.gr (Postfix) with ESMTPS id 8435220197
	for ; Sat, 27 Aug 2022 10:18:34 +0300 (EEST)
Received: from smtpclient.apple (5-203-220-16.pat.nym.cosmote.net [5.203.220.16])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: chris@cretaforce.gr)
	by server1.cretaforce.gr (Postfix) with ESMTPSA id 490631BA1C;
	Sat, 27 Aug 2022 10:18:33 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cretaforce.gr;
	s=cretaforce; t=1661584714;
	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=MRv3N9z4l6jzT2N3xhklHjJiNScTOZs+qK5lmOGZC+0=;
	b=Cgmj78K4twdwfpXVGrp1fhB93jh2bimchPi/w38P908gg9IB28LMQNb5wVV9gy+2UsztTp
	7GiTB6l6Xn9/Nd/8IBOyR52CTNbwaWqYmcCcfEO0I/Em3UcVRx7z4MMJ9QERxpjj/coTiR
	yoso/cVRezcajLBJiWbg5wiuq+j1MBM=
From: Christos Chatzaras 
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 \(3696.120.41.1.1\))
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by
 design
Date: Sat, 27 Aug 2022 10:18:31 +0300
References: <20220827083042.73e7f439@thor.intern.walstatt.dynvpn.de>
To: FreeBSD User ,
 FreeBSD CURRENT ,
 FreeBSD Ports ,
 yasu@freebsd.org
In-Reply-To: <20220827083042.73e7f439@thor.intern.walstatt.dynvpn.de>
Message-Id: 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MF7ND4jtMz3dBk
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=cretaforce.gr header.s=cretaforce header.b=Cgmj78K4;
	dmarc=pass (policy=none) header.from=cretaforce.gr;
	spf=pass (mx1.freebsd.org: domain of chris@cretaforce.gr designates 195.201.253.145 as permitted sender) smtp.mailfrom=chris@cretaforce.gr
X-Spamd-Result: default: False [-3.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[cretaforce.gr,none];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[cretaforce.gr:s=cretaforce];
	R_SPF_ALLOW(-0.20)[+ip4:195.201.253.145];
	RCVD_IN_DNSWL_LOW(-0.10)[195.201.253.145:from];
	MIME_GOOD(-0.10)[text/plain];
	FREEFALL_USER(0.00)[chris];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DWL_DNSWL_NONE(0.00)[cretaforce.gr:dkim];
	DKIM_TRACE(0.00)[cretaforce.gr:+];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hello,

Maybe you can use a shell script that creates the directory with @reboot =
at cron. If this doesn't work (not sure if clamav starts before cron), =
then maybe you can use monit to create the directory and start clamav.

Kind regards,
Christos Chatzaras

> On 27 Aug 2022, at 09:30, FreeBSD User  wrote:
>=20
> Hello,
>=20
> I'm referencing to Bug 259699 [2] and Bug 259585 [1].
>=20
> Port security/clamav is without doubt for many of FreeBSD users an =
important piece of security
> software so I assume a widespread usage.
>=20
> It is also a not uncommon use case to use NanoBSD or any kind of =
low-memory-footprint
> installation schemes in which /var/run - amongst other system folders =
- are created at boot
> time as TMPFS and highly volatile.
>=20
> In our case, the boxes running a small security appliance based upon =
FreeBSD is rebooted every
> 24 hours and so /var/run is vanishing.
>=20
> To make the long story short:
>=20
> The solution for this problem would be a check for existence and take =
action addendum in
> precmd() routine of the rc-script as sketched in Bug 259699.
> The maintainer rejects such a workaround by arguing this would violate =
POLA (see comment 4 in
> PR 259699 [2]. The maintainer's argument regaring to mtree's files are =
sound to me.
>=20
> The question is: how can this issue be solved?
>=20
> It is really hard to always chenge our local repository and patch =
whenever clamav has been
> patched and modified for what reason ever.
>=20
> Tahanks for reading,
>=20
> kind regards
>=20
> O. Hartmann
>=20
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259585
> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259699
>=20
>=20
> --=20
> O. Hartmann
>=20


From nobody Sat Aug 27 09:21:40 2022
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 4MFB6K2Zf4z4ZxdP;
	Sat, 27 Aug 2022 09:21:45 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFB6J0H40z3nCw;
	Sat, 27 Aug 2022 09:21:43 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id fa52ef24;
	Sat, 27 Aug 2022 09:21:41 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 5384820e (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Sat, 27 Aug 2022 09:21:41 +0000 (UTC)
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 (1.0)
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by design
From: Michael Gmelin 
In-Reply-To: <20220827083042.73e7f439@thor.intern.walstatt.dynvpn.de>
Date: Sat, 27 Aug 2022 11:21:40 +0200
Cc: FreeBSD CURRENT ,
 FreeBSD Ports , yasu@freebsd.org
Message-Id: 
References: <20220827083042.73e7f439@thor.intern.walstatt.dynvpn.de>
To: FreeBSD User 
X-Mailer: iPhone Mail (19G82)
X-Rspamd-Queue-Id: 4MFB6J0H40z3nCw
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-2.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[grembo];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCPT_COUNT_THREE(0.00)[4];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 27. Aug 2022, at 08:31, FreeBSD User  wrote:
>=20
> =EF=BB=BFHello,
>=20
> I'm referencing to Bug 259699 [2] and Bug 259585 [1].
>=20
> Port security/clamav is without doubt for many of FreeBSD users an importa=
nt piece of security
> software so I assume a widespread usage.
>=20
> It is also a not uncommon use case to use NanoBSD or any kind of low-memor=
y-footprint
> installation schemes in which /var/run - amongst other system folders - ar=
e created at boot
> time as TMPFS and highly volatile.
>=20
> In our case, the boxes running a small security appliance based upon FreeB=
SD is rebooted every
> 24 hours and so /var/run is vanishing.
>=20
> To make the long story short:
>=20
> The solution for this problem would be a check for existence and take acti=
on addendum in
> precmd() routine of the rc-script as sketched in Bug 259699.
> The maintainer rejects such a workaround by arguing this would violate POL=
A (see comment 4 in
> PR 259699 [2]. The maintainer's argument regaring to mtree's files are sou=
nd to me.
>=20
> The question is: how can this issue be solved?
>=20
> It is really hard to always chenge our local repository and patch whenever=
 clamav has been
> patched and modified for what reason ever.
>=20
> Tahanks for reading,
>=20

Why don=E2=80=99t you simply add an rc script to your appliance that creates=
 the missing directory/directories on boot before clamav is started?

Best
Michael



From nobody Sat Aug 27 10:53:38 2022
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 4MFD910j3qz4b7pg;
	Sat, 27 Aug 2022 10:54:13 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFD8z6DWDz4Khh;
	Sat, 27 Aug 2022 10:54:11 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by smtp5.goneo.de (Postfix) with ESMTPS id 70ADF10A32E0;
	Sat, 27 Aug 2022 12:54:08 +0200 (CEST)
Received: from hub1.goneo.de (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by hub1.goneo.de (Postfix) with ESMTPS id D6D0010A32F4;
	Sat, 27 Aug 2022 12:54:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
	s=DKIM001; t=1661597646;
	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=FAmNI8Ra2D229ERAFrHRnp1ehRdJWiRH5YQ7s0G3ikg=;
	b=hY+FeiLg3ETvxNwgoQK8pcVLE+Kv4YbgAVwr/MyT6QJWcWTIzSKjc0zmmba4UnBc2z4X7B
	wdM18/C+ZBnI3YOzIc2S6pUdkSdXoFHhVqkgfgJNz1Mtsxfq77xlRJ60HNVYZF/H+/fB4t
	29+cj/K3dhVljGlhNAFOho9OK99N2sVFHRFtnvT/1VR6QwcON0d7olq7IYOsbANEIlD+yl
	PVLZugWAj7B2fn5iRkq8y8PmAK167Fdd0dqZh5+AEH+0juHhODu2Oadv1yaBfvEn/FZB8K
	qostU2ZAP8TZvL6RNkdERt/KDC4cvThPLRz1kleBxQ35kiUD1whqMJg2VBQpMw==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-183-115-239.77.183.pool.telefonica.de [77.183.115.239])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by hub1.goneo.de (Postfix) with ESMTPSA id 9B3A810A333F;
	Sat, 27 Aug 2022 12:54:06 +0200 (CEST)
Date: Sat, 27 Aug 2022 12:53:38 +0200
From: FreeBSD User 
To: Michael Gmelin 
Cc: FreeBSD CURRENT , FreeBSD Ports
 , yasu@freebsd.org
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by
 design
Message-ID: <20220827125405.10194d30@thor.intern.walstatt.dynvpn.de>
In-Reply-To: 
References: <20220827083042.73e7f439@thor.intern.walstatt.dynvpn.de>
	
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Rspamd-UID: 1309d6
X-Rspamd-UID: 17fbd0
X-Rspamd-Queue-Id: 4MFD8z6DWDz4Khh
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=hY+FeiLg;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.60) smtp.mailfrom=freebsd@walstatt-de.de
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
	MIME_GOOD(-0.10)[text/plain];
	DKIM_TRACE(0.00)[walstatt-de.de:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	MIME_TRACE(0.00)[0:+];
	HAS_ORG_HEADER(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DMARC_NA(0.00)[walstatt-de.de];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Am Sat, 27 Aug 2022 11:21:40 +0200
Michael Gmelin  schrieb:

> > On 27. Aug 2022, at 08:31, FreeBSD User  wrote:
> >=20
> > =EF=BB=BFHello,
> >=20
> > I'm referencing to Bug 259699 [2] and Bug 259585 [1].
> >=20
> > Port security/clamav is without doubt for many of FreeBSD users an impo=
rtant piece of
> > security software so I assume a widespread usage.
> >=20
> > It is also a not uncommon use case to use NanoBSD or any kind of low-me=
mory-footprint
> > installation schemes in which /var/run - amongst other system folders -=
 are created at boot
> > time as TMPFS and highly volatile.
> >=20
> > In our case, the boxes running a small security appliance based upon Fr=
eeBSD is rebooted
> > every 24 hours and so /var/run is vanishing.
> >=20
> > To make the long story short:
> >=20
> > The solution for this problem would be a check for existence and take a=
ction addendum in
> > precmd() routine of the rc-script as sketched in Bug 259699.
> > The maintainer rejects such a workaround by arguing this would violate =
POLA (see comment 4
> > in PR 259699 [2]. The maintainer's argument regaring to mtree's files a=
re sound to me.
> >=20
> > The question is: how can this issue be solved?
> >=20
> > It is really hard to always chenge our local repository and patch whene=
ver clamav has been
> > patched and modified for what reason ever.
> >=20
> > Tahanks for reading,
> >  =20
>=20
> Why don=E2=80=99t you simply add an rc script to your appliance that crea=
tes the missing
> directory/directories on boot before clamav is started?
>=20
> Best
> Michael
>=20
>=20
>=20

Why not fixing this on a more general basis?

Best regards,

oh

--=20
O. Hartmann

From nobody Sat Aug 27 11:16:43 2022
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 4MFDgG6ZLyz4ZBbK;
	Sat, 27 Aug 2022 11:16:58 +0000 (UTC)
	(envelope-from tuexen@freebsd.org)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFDgF6pgWz4Mjj;
	Sat, 27 Aug 2022 11:16:57 +0000 (UTC)
	(envelope-from tuexen@freebsd.org)
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:a98f:221e:fa2d:16b5])
	(Authenticated sender: macmic)
	by drew.franken.de (Postfix) with ESMTPSA id 273C77220BFAF;
	Sat, 27 Aug 2022 13:16:45 +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 \(3696.120.41.1.1\))
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by
 design
From: tuexen@freebsd.org
In-Reply-To: <20220827083042.73e7f439@thor.intern.walstatt.dynvpn.de>
Date: Sat, 27 Aug 2022 13:16:43 +0200
Cc: FreeBSD CURRENT ,
 FreeBSD Ports ,
 yasu@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20220827083042.73e7f439@thor.intern.walstatt.dynvpn.de>
To: FreeBSD User 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de
X-Rspamd-Queue-Id: 4MFDgF6pgWz4Mjj
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 2001:638:a02:a001:20e:cff:fe4a:feaa is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org
X-Spamd-Result: default: False [-2.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NO_DN(0.00)[];
	FREEFALL_USER(0.00)[tuexen];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> On 27. Aug 2022, at 08:30, FreeBSD User  =
wrote:
>=20
> Hello,
>=20
> I'm referencing to Bug 259699 [2] and Bug 259585 [1].
>=20
> Port security/clamav is without doubt for many of FreeBSD users an =
important piece of security
> software so I assume a widespread usage.
>=20
> It is also a not uncommon use case to use NanoBSD or any kind of =
low-memory-footprint
> installation schemes in which /var/run - amongst other system folders =
- are created at boot
> time as TMPFS and highly volatile.
>=20
> In our case, the boxes running a small security appliance based upon =
FreeBSD is rebooted every
> 24 hours and so /var/run is vanishing.
Why are you rebooting every 24 hours?

Best regards
Michael
>=20
> To make the long story short:
>=20
> The solution for this problem would be a check for existence and take =
action addendum in
> precmd() routine of the rc-script as sketched in Bug 259699.
> The maintainer rejects such a workaround by arguing this would violate =
POLA (see comment 4 in
> PR 259699 [2]. The maintainer's argument regaring to mtree's files are =
sound to me.
>=20
> The question is: how can this issue be solved?
>=20
> It is really hard to always chenge our local repository and patch =
whenever clamav has been
> patched and modified for what reason ever.
>=20
> Tahanks for reading,
>=20
> kind regards
>=20
> O. Hartmann
>=20
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259585
> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259699
>=20
>=20
> --=20
> O. Hartmann
>=20


From nobody Sat Aug 27 13:02:04 2022
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 4MFH0f00nbz4ZNNd;
	Sat, 27 Aug 2022 13:02:10 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFH0c5Gwyz3H4M;
	Sat, 27 Aug 2022 13:02:08 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id cfa47121;
	Sat, 27 Aug 2022 13:02:06 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 92b474c0 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Sat, 27 Aug 2022 13:02:06 +0000 (UTC)
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 (1.0)
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by design
From: Michael Gmelin 
In-Reply-To: <20220827125405.10194d30@thor.intern.walstatt.dynvpn.de>
Date: Sat, 27 Aug 2022 15:02:04 +0200
Cc: FreeBSD CURRENT ,
 FreeBSD Ports , yasu@freebsd.org
Message-Id: 
References: <20220827125405.10194d30@thor.intern.walstatt.dynvpn.de>
To: FreeBSD User 
X-Mailer: iPhone Mail (19G82)
X-Rspamd-Queue-Id: 4MFH0c5Gwyz3H4M
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-2.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	MIME_TRACE(0.00)[0:+];
	TO_DN_SOME(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[grembo];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCPT_COUNT_THREE(0.00)[4];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 27. Aug 2022, at 12:54, FreeBSD User  wrote:
>=20
> =EF=BB=BFAm Sat, 27 Aug 2022 11:21:40 +0200
> Michael Gmelin  schrieb:
>=20
>>>> On 27. Aug 2022, at 08:31, FreeBSD User  wrote:=

>>>=20
>>> =EF=BB=BFHello,
>>>=20
>>> I'm referencing to Bug 259699 [2] and Bug 259585 [1].
>>>=20
>>> Port security/clamav is without doubt for many of FreeBSD users an impor=
tant piece of
>>> security software so I assume a widespread usage.
>>>=20
>>> It is also a not uncommon use case to use NanoBSD or any kind of low-mem=
ory-footprint
>>> installation schemes in which /var/run - amongst other system folders - a=
re created at boot
>>> time as TMPFS and highly volatile.
>>>=20
>>> In our case, the boxes running a small security appliance based upon Fre=
eBSD is rebooted
>>> every 24 hours and so /var/run is vanishing.
>>>=20
>>> To make the long story short:
>>>=20
>>> The solution for this problem would be a check for existence and take ac=
tion addendum in
>>> precmd() routine of the rc-script as sketched in Bug 259699.
>>> The maintainer rejects such a workaround by arguing this would violate P=
OLA (see comment 4
>>> in PR 259699 [2]. The maintainer's argument regaring to mtree's files ar=
e sound to me.
>>>=20
>>> The question is: how can this issue be solved?
>>>=20
>>> It is really hard to always chenge our local repository and patch whenev=
er clamav has been
>>> patched and modified for what reason ever.
>>>=20
>>> Tahanks for reading,
>>>=20
>>=20
>> Why don=E2=80=99t you simply add an rc script to your appliance that crea=
tes the missing
>> directory/directories on boot before clamav is started?
>>=20
>> Best
>> Michael
>>=20
>>=20
>>=20
>=20
> Why not fixing this on a more general basis?

It=E2=80=98s a reasonable way forward, given the limitations you described (=
you=E2=80=99re removing /var/run, which shouldn=E2=80=99t be removed and the=
 port maintainer not willing to add code to compensate for this). This would=
 fix it for you for your specific needs in a reliable way, you would never h=
ave to patch the port again and also won=E2=80=99t use other people=E2=80=98=
s time to find a general solution to your very specific problem. It=E2=80=99=
s a sustainable quick fix to your problem at hand. You can always come up wi=
th something grand later, but this would actually work right away.

Cheers




From nobody Sat Aug 27 13:21:38 2022
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 4MFHRp6PQKz4ZQCQ
	for ; Sat, 27 Aug 2022 13:22:14 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFHRn4FGVz3Ldd
	for ; Sat, 27 Aug 2022 13:22:13 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by smtp6.goneo.de (Postfix) with ESMTPS id 48CB010A32EB
	for ; Sat, 27 Aug 2022 15:22:10 +0200 (CEST)
Received: from hub2.goneo.de (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPS id 4101210A3308
	for ; Sat, 27 Aug 2022 15:22:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
	s=DKIM001; t=1661606526;
	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=AOWYwzdcEfO8K+vUwuIvYl09qzOyh2Ka+qfJLHf5KGU=;
	b=DaEVmDQqLV5/RIgf1YgwXtAHVRm0acz8Ce04KSkRvGHDgsMAdXlw0jO+gpZcQMmnCEsS9Q
	L3SClijD9+0+f/VJ1A2yKJDaqTPeTd/AeNBnEJZBymquNe6HYhEhnC87u1kgcSpNr+X4Gj
	wAqdT6qx+USGhDQcCN4n6WDC7Kyco19+drH9winKRasL2T1bS479d3xWMzlzup17Ec6FSU
	hsPD0NNyNgdBTozP6dE0SoeEfczZskkTc97i03Dj5hIx1duTrSdL74GTdLYZCh6eFJflfv
	9vt162VZHPDmVcDLI5tMo7dPAXejpZ+W4DGzgak12uaNB4958opfZkNrAEHZfg==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-183-115-239.77.183.pool.telefonica.de [77.183.115.239])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPSA id 1A29E10A32E7
	for ; Sat, 27 Aug 2022 15:22:06 +0200 (CEST)
Date: Sat, 27 Aug 2022 15:21:38 +0200
From: FreeBSD User 
To: freebsd-current@freebsd.org
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by
 design
Message-ID: <20220827152205.76d9df57@thor.intern.walstatt.dynvpn.de>
In-Reply-To: 
References: <20220827083042.73e7f439@thor.intern.walstatt.dynvpn.de>
	
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-UID: 364e76
X-Rspamd-UID: 298816
X-Rspamd-Queue-Id: 4MFHRn4FGVz3Ldd
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=DaEVmDQq;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.31) smtp.mailfrom=freebsd@walstatt-de.de
X-Spamd-Result: default: False [-3.40 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from];
	DKIM_TRACE(0.00)[walstatt-de.de:+];
	ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	DMARC_NA(0.00)[walstatt-de.de];
	HAS_ORG_HEADER(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_DN_NONE(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Am Sat, 27 Aug 2022 13:16:43 +0200
tuexen@freebsd.org schrieb:

> > On 27. Aug 2022, at 08:30, FreeBSD User  wrote:
> > 
> > Hello,
> > 
> > I'm referencing to Bug 259699 [2] and Bug 259585 [1].
> > 
> > Port security/clamav is without doubt for many of FreeBSD users an important piece of
> > security software so I assume a widespread usage.
> > 
> > It is also a not uncommon use case to use NanoBSD or any kind of low-memory-footprint
> > installation schemes in which /var/run - amongst other system folders - are created at boot
> > time as TMPFS and highly volatile.
> > 
> > In our case, the boxes running a small security appliance based upon FreeBSD is rebooted
> > every 24 hours and so /var/run is vanishing.  
> Why are you rebooting every 24 hours?

The appliance has to be on a non-writable medium and is to be rebooted every 24 hours to
cleanse temporary memory. This is given in the specs and by the department(s) the appliance
is for. 

Kind regards
> 
> Best regards
> Michael
> > 
> > To make the long story short:
> > 
> > The solution for this problem would be a check for existence and take action addendum in
> > precmd() routine of the rc-script as sketched in Bug 259699.
> > The maintainer rejects such a workaround by arguing this would violate POLA (see comment 4
> > in PR 259699 [2]. The maintainer's argument regaring to mtree's files are sound to me.
> > 
> > The question is: how can this issue be solved?
> > 
> > It is really hard to always chenge our local repository and patch whenever clamav has been
> > patched and modified for what reason ever.
> > 
> > Tahanks for reading,
> > 
> > kind regards
> > 
> > O. Hartmann
> > 
> > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259585
> > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259699
> > 
> > 
> > -- 
> > O. Hartmann
> >   
> 
> 



-- 
O. Hartmann

From nobody Sat Aug 27 13:27:25 2022
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 4MFHYs2wN3z4ZQdY;
	Sat, 27 Aug 2022 13:27:29 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFHYr1BPVz3MQB;
	Sat, 27 Aug 2022 13:27:28 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id ea77a3c5;
	Sat, 27 Aug 2022 13:27:26 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 0736ceab (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Sat, 27 Aug 2022 13:27:26 +0000 (UTC)
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 (1.0)
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by design
From: Michael Gmelin 
In-Reply-To: <202208271318.27RDI9Jd044045@nuc.oldach.net>
Date: Sat, 27 Aug 2022 15:27:25 +0200
Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org, yasu@freebsd.org,
 freebsd@walstatt-de.de
Message-Id: 
References: <202208271318.27RDI9Jd044045@nuc.oldach.net>
To: freebsd@oldach.net
X-Mailer: iPhone Mail (19G82)
X-Rspamd-Queue-Id: 4MFHYr1BPVz3MQB
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-2.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[grembo];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	TO_DN_NONE(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 27. Aug 2022, at 15:18, freebsd@oldach.net wrote:
>=20
> =EF=BB=BFMichael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST):
>> (you're removing /var/run, which shouldn't be removed
>=20
> Not quite. It's actually not uncommon to boot with an empty /var. Please s=
ee /etc/rc.d/var and related.

That=E2=80=99s a good point.

> The request that ports/packages should consider this case is not exactly u=
nreasonable IMO.
>=20

If I was the maintainer, I would simply add the code to create the directory=
 for robustness sake (I for one deleted subdirs in /var/run more than once a=
nd would expect a port to fix this on restart, also to make sure correct per=
missions are applied). But since it doesn=E2=80=99t seem like this is going t=
o happen, adding a custom rc file would be a viable short term workaround fo=
r the requester.

I like the idea of having something like tmpfiles.d, it would also help port=
 maintainers (could also be done as a port).

Cheers



From nobody Sat Aug 27 13:38:44 2022
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 4MFHpv0P5mz4ZRps;
	Sat, 27 Aug 2022 13:38:47 +0000 (UTC)
	(envelope-from otis@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFHpt6tGhz3QV3;
	Sat, 27 Aug 2022 13:38:46 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661607527;
	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=VTC3eEx2et/1Lqhhi/kWquSQ746mnxKZNpdRQXt4pQ8=;
	b=BmCNdasGRA6b2QqnUqKe1BfZ6bmhjP1+EODDetX4c/MXnv7K5S9aatyBwGAGOByE4e3U4f
	ZCLwv+SSGqC6SyungfNE4STIyzx3Lxh0FLVxzVo4EFf8MUPddBV9MT32WAwdIRXC5EUhat
	VbuUEOrKzrvR+BXYXnWF2UJHaTdMz7boQ2Umx1cvrG9idjROmYVRdArDHl/3omITaK1i2b
	R/YtKeVwNTxboV/IzJ8kIfhJzOI0aiYyWiaVgALxWRz2A0Ch3k6aZZYvn2Alq7ib2vCnwk
	9iT0/niLchHo8WBkMsM6bEjuttXj8r6JVbSL9TAVVArJY9O+MM/6SexQygAGLQ==
Received: from ns2.wilbury.net (ns2.wilbury.net [IPv6:2a01:b200:0:1:f816:3eff:fecd:13e6])
	(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 "svc.wilbury.net", Issuer "R3" (verified OK))
	(Authenticated sender: otis)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MFHpt4MvXz17Ds;
	Sat, 27 Aug 2022 13:38:46 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
Received: from smtpclient.apple (85-237-234-63.dynamic.orange.sk [85.237.234.63])
	(Authenticated sender: juraj@lutter.sk)
	by svc.wilbury.net (Postfix) with ESMTPSA id DAF0645D14F;
	Sat, 27 Aug 2022 15:38:44 +0200 (CEST)
From: Juraj Lutter 
Message-Id: 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_20A84A0F-B411-42BA-8CA7-96D01698B8C6"
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by
 design
Date: Sat, 27 Aug 2022 15:38:44 +0200
In-Reply-To: 
Cc: freebsd@oldach.net,
 freebsd-current@freebsd.org,
 freebsd-ports@freebsd.org,
 yasu@freebsd.org,
 freebsd@walstatt-de.de
To: Michael Gmelin 
References: <202208271318.27RDI9Jd044045@nuc.oldach.net>
 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661607527;
	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=VTC3eEx2et/1Lqhhi/kWquSQ746mnxKZNpdRQXt4pQ8=;
	b=kTxAjY+GuQO0eRemHHJycDcdz2aTD9DFDkt7sAiiHsyaXGgxQfkwI8E7Z4Au779spnj07w
	8J14jYF4/sr+4LekTU8oZsqo6hh6ZXX8+4MJnNx2HuDlpKrN5VVfHwgmHmH94JCRvCRVgX
	ejLs0WV49cGsyZyLjF8E8kc8HGNAOsC1za4OkEqrEQBDGk1RWHTDW5CUVMY0iYiks+sq4O
	1aoCJpVNYFok5LF1QKu6L2TSIy3xJhG+2zTz+j/cGHmnt6dHSU83bBUL9VHgLKH2IdkKsm
	u7AOpN7lULJa7J4Opib+ycKBYNW03LKg+mgvL3WjVnn11Q49B2q4oHDlMkSUhA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661607527; a=rsa-sha256; cv=none;
	b=oESJF0Y0WM3Zt/mxlC4AmyAdkwx+Kz6T3M2QkybH7jeqkcWnqlYX9NPbN4G8WFeSnWptti
	7Vmb+2ok6A5U1RAm+UExq7w8jWPIB0P/nQO4bR+fpnMMJ8sWBLZ5AVbsS7DHRBOfGcPOEz
	WAHNrf+kOBD45ZVQPfWRtwryxDgNsTEw0df/xa4/75l6JlqbsDixZx6AnRt5oGnGBijKjh
	yLMyGz2op6ITWv5lwu7aIYnyPtNxnymAUfkP0cVLNzkpQemmrQIGzGY/MqR2njH/VWYgCN
	LF1PPpCeMe79fWDfqAjf1+aKFwQy9J5jZjxcM6zEOib2DGSQ0h10XeN8Lrg45A==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_20A84A0F-B411-42BA-8CA7-96D01698B8C6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 27 Aug 2022, at 15:27, Michael Gmelin  wrote:
>=20
>=20
>=20
>> On 27. Aug 2022, at 15:18, freebsd@oldach.net wrote:
>>=20
>> =EF=BB=BFMichael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 =
(CEST):
>>> (you're removing /var/run, which shouldn't be removed
>>=20
>> Not quite. It's actually not uncommon to boot with an empty /var. =
Please see /etc/rc.d/var and related.
>=20
> That=E2=80=99s a good point.
>=20
>> The request that ports/packages should consider this case is not =
exactly unreasonable IMO.
>>=20
>=20
> If I was the maintainer, I would simply add the code to create the =
directory for robustness sake (I for one deleted subdirs in /var/run =
more than once and would expect a port to fix this on restart, also to =
make sure correct permissions are applied). But since it doesn=E2=80=99t =
seem like this is going to happen, adding a custom rc file would be a =
viable short term workaround for the requester.
>=20
> I like the idea of having something like tmpfiles.d, it would also =
help port maintainers (could also be done as a port).
>=20

As I have stated in one of those PR: clamd creates file in two =
locations:

- PidFile
- LocalSocket

Both the locations could be checked by rc.d script in clamd.conf (also =
freshclam eventually) and respective directories can be created from =
within start_precmd()

otis

=E2=80=94
Juraj Lutter
otis@FreeBSD.org


--Apple-Mail=_20A84A0F-B411-42BA-8CA7-96D01698B8C6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 27 Aug 2022, at 15:27, Michael Gmelin <grembo@freebsd.org> =
wrote:



On 27. Aug 2022, at 15:18, freebsd@oldach.net =
wrote:

=EF=BB=BFMichael Gmelin wrote on =
Sat, 27 Aug 2022 15:02:04 +0200 (CEST):
(you're removing /var/run, which shouldn't be =
removed

Not quite. It's =
actually not uncommon to boot with an empty /var. Please see =
/etc/rc.d/var and related.

That=E2=80=99s a good point.

The request that =
ports/packages should consider this case is not exactly unreasonable =
IMO.


If I was =
the maintainer, I would simply add the code to create the directory for =
robustness sake (I for one deleted subdirs in /var/run more than once =
and would expect a port to fix this on restart, also to make sure =
correct permissions are applied). But since it doesn=E2=80=99t seem like =
this is going to happen, adding a custom rc file would be a viable short =
term workaround for the requester.

I like =
the idea of having something like tmpfiles.d, it would also help port =
maintainers (could also be done as a port).


As I have =
stated in one of those PR: clamd creates file in two =
locations:

- PidFile
- =
LocalSocket

Both the locations could =
be checked by rc.d script in clamd.conf (also freshclam eventually) and =
respective directories can be created from within =
start_precmd()

otis



=E2=80=94
Juraj =
Lutter






=

--Apple-Mail=_20A84A0F-B411-42BA-8CA7-96D01698B8C6--

From nobody Sat Aug 27 15:26:15 2022
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 4MFLBx2NV5z4ZdFy;
	Sat, 27 Aug 2022 15:26:17 +0000 (UTC)
	(envelope-from jamie@catflap.org)
Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1])
	by mx1.freebsd.org (Postfix) with ESMTP id 4MFLBw5dGdz3dC3;
	Sat, 27 Aug 2022 15:26:16 +0000 (UTC)
	(envelope-from jamie@catflap.org)
X-Catflap-Envelope-From: 
X-Catflap-Envelope-To: freebsd-current@FreeBSD.org
Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49])
	by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 27RFQGN0071258;
	Sat, 27 Aug 2022 16:26:16 +0100 (BST)
	(envelope-from jamie@donotpassgo.dyslexicfish.net)
Received: (from jamie@localhost)
	by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 27RFQF3U071257;
	Sat, 27 Aug 2022 16:26:15 +0100 (BST)
	(envelope-from jamie)
From: Jamie Landeg-Jones 
Message-Id: <202208271526.27RFQF3U071257@donotpassgo.dyslexicfish.net>
Date: Sat, 27 Aug 2022 16:26:15 +0100
Organization: Dyslexic Fish
To: grembo@FreeBSD.org, freebsd@oldach.net
Cc: yasu@FreeBSD.org, freebsd@walstatt-de.de, freebsd-ports@FreeBSD.org,
        freebsd-current@FreeBSD.org
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by
 design
References: <202208271318.27RDI9Jd044045@nuc.oldach.net>
 
In-Reply-To: 
User-Agent: Heirloom mailx 12.4 7/29/08
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sat, 27 Aug 2022 16:26:16 +0100 (BST)
X-Rspamd-Queue-Id: 4MFLBw5dGdz3dC3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=catflap.org;
	spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org
X-Spamd-Result: default: False [-3.70 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[catflap.org,none];
	R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net:c];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org,freebsd-ports@FreeBSD.org];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEFALL_USER(0.00)[jamie];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_FIVE(0.00)[6];
	TO_DN_NONE(0.00)[];
	ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]
X-ThisMailContainsUnwantedMimeParts: N

Michael Gmelin  wrote:

> I like the idea of having something like tmpfiles.d, it would also help port maintainers (could also be done as a port).

I use tmpfs for /var/run and already have such a script for this very reason
(although not clamav)

I would have thought each port startup script should ensure it's file/directory
exists before attempting to launch - having "tmpfiles.d" would still require
some changes for the port maintainer to make to their port, but I guess it
may help to keep things centralised.

I'm willing to "standardise" my script if it would help, but as it stands, you
can see it here:

http://freebsd.dyslexicfish.net/src/

15:47 (71) "~/x" jamie@newbie% cat /usr/common/etc/var_run.mtree
# File/Directory        User           Group        Perms
#
distccd.pid             distcc         distcc         640
ntop/                   ntop           ntop           750
nsd/                    nsd            nsd            750
netdata/                netdata        netdata        750
screens/                root           wheel         1777
sshdbanner/             sshdbanner     sshdbanner     755
spamd/                  spamd          spamd          750
symon.pid               _symon         _symon         640
symux.pid               _symon         _symon         640
vnstat/                 vnstat         vnstat         750
 

From nobody Sat Aug 27 15:26:38 2022
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 4MFLCR1t2Bz4ZdM1;
	Sat, 27 Aug 2022 15:26:43 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFLCQ2m7wz3fSk;
	Sat, 27 Aug 2022 15:26:42 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227])
	by cmsmtp with ESMTP
	id RvtbosFtJSp39RxhpoPmey; Sat, 27 Aug 2022 15:26:41 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id Rxhmou3jEGRNlRxhnoi1bT; Sat, 27 Aug 2022 15:26:41 +0000
X-Authority-Analysis: v=2.4 cv=Sfrky9du c=1 sm=1 tr=0 ts=630a37b1
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=biHskzXt2R4A:10 a=6I5d2MoRAAAA:8
 a=gRS1eiuiAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=R0zMgeHHeiDL7zLRjdsA:9
 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=udpbrAo2yJH2O6eCpvBn:22
 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id 735AB1594;
	Sat, 27 Aug 2022 08:26:38 -0700 (PDT)
Received: from slippy (localhost [IPv6:::1])
	by slippy.cwsent.com (Postfix) with ESMTP id 5FB1C2B0;
	Sat, 27 Aug 2022 08:26:38 -0700 (PDT)
Date: Sat, 27 Aug 2022 08:26:38 -0700
From: Cy Schubert 
To: Juraj Lutter , freebsd@walstatt-de.de
Cc: Michael Gmelin , freebsd@oldach.net,
 freebsd-current@freebsd.org, freebsd-ports@freebsd.org, yasu@freebsd.org
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by
 design
Message-ID: <20220827082638.57901a72@slippy>
In-Reply-To: 
References: <202208271318.27RDI9Jd044045@nuc.oldach.net>
	
	
Organization: KOMQUATS
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-CMAE-Envelope: MS4xfPeqJGiz1ILL44o16BHcK03y4P02Pe9qa2bhtGnNq4DSj7sKNE4SmgwofQS1VGQUMjdzyYAx3SkXl68WQlqjcU2zblfebScneknX5OU3Fo/NI38VVHTp
 j/N/mIiyCmRsiJntK2O+9vvLHAvf6pcpHaygPsg/jGnptac4AxAxthbi514ETCUBUJNDBZL6Z9RbvV+4apRHEuT2mXNABAZvxR5VFgxrCi8dAv0B9f5wuxQo
 kJin//oJ9Jxoiy5x4h81ILInfyaPd09FoXsBE7oBnJMOQGesVxSjXFs5VTa8NUSj9bJD36GEJL4gWqjHz6SkxgmStwNZyFCC6xSgfh1oYbVHGkMCj5GXesiQ
 blEQhyH+wnVIHWekqkSzcSqV6azuDiyiBXxSZtV1sLsMpEI86ZU=
X-Rspamd-Queue-Id: 4MFLCQ2m7wz3fSk
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.79 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	MID_RHS_NOT_FQDN(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[7];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	RCVD_COUNT_FIVE(0.00)[5];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, 27 Aug 2022 15:38:44 +0200
Juraj Lutter  wrote:

> > On 27 Aug 2022, at 15:27, Michael Gmelin  wrote:
> >=20
> >=20
> >  =20
> >> On 27. Aug 2022, at 15:18, freebsd@oldach.net wrote:
> >>=20
> >> =EF=BB=BFMichael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST=
): =20
> >>> (you're removing /var/run, which shouldn't be removed =20
> >>=20
> >> Not quite. It's actually not uncommon to boot with an empty /var. Plea=
se see /etc/rc.d/var and related. =20
> >=20
> > That=E2=80=99s a good point.
> >  =20
> >> The request that ports/packages should consider this case is not exact=
ly unreasonable IMO.
> >>  =20
> >=20
> > If I was the maintainer, I would simply add the code to create the dire=
ctory for robustness sake (I for one deleted subdirs in /var/run more than =
once and would expect a port to fix this on restart, also to make sure corr=
ect permissions are applied). But since it doesn=E2=80=99t seem like this i=
s going to happen, adding a custom rc file would be a viable short term wor=
karound for the requester.
> >=20
> > I like the idea of having something like tmpfiles.d, it would also help=
 port maintainers (could also be done as a port).
> >  =20
>=20
> As I have stated in one of those PR: clamd creates file in two locations:
>=20
> - PidFile
> - LocalSocket
>=20
> Both the locations could be checked by rc.d script in clamd.conf (also fr=
eshclam eventually) and respective directories can be created from within s=
tart_precmd()
>=20
> otis
>=20
> =E2=80=94
> Juraj Lutter
> otis@FreeBSD.org
>=20

As stated before in this thread, replacing /var/run with tmpfs is not a
supported configuration. However if users wish to replace /var/run
with tmpfs they can create an rc script (I put my extra rc scripts in
/etc/local/rc.d) to create the hierarc
If one does this they can either use mtree(1) to create the hierarchy
or simply take a snapshot (find /var/run -type d | cpio -o >
/etc/local/my_var_run.cpio), having their rc script recreate the
hierarchy using cpio -i < /etc/local/my_var_run.cpio). And
be periodically updated the archive as needed, probably through a
shutdown script.

One will notice that /etc/mtree/BSD.var.dist shows us what is created
in /var/run by default during installworld.

The change requested is not specifically for an individual port but
essentially a FreeBSD-wide infrastructure change. I don't think this
is reasonable without a lot of consideration about what will be broken
during the process of changing build and boot processes and the
potential POLA fallout from such a change. A change like this needs to
be architected.

I don't think this is the mailing list to discuss this topic. This
should be discussed on ports@. Not here. Maybe it should be moved there
as this is a ports not a base O/S issue.

--=20
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e^(i*pi)+1=3D0

From nobody Sat Aug 27 16:37:14 2022
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 4MFMmt26PDz4Zlvn;
	Sat, 27 Aug 2022 16:37:18 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFMms5r46z3lRH;
	Sat, 27 Aug 2022 16:37:17 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142])
	by cmsmtp with ESMTP
	id RuuTosE7mSp39Ryo9oPyvz; Sat, 27 Aug 2022 16:37:17 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id Ryo6onIokuJwwRyo7oSYf6; Sat, 27 Aug 2022 16:37:17 +0000
X-Authority-Analysis: v=2.4 cv=F+BEy4tN c=1 sm=1 tr=0 ts=630a483d
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=biHskzXt2R4A:10 a=6I5d2MoRAAAA:8 a=gRS1eiuiAAAA:8
 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=-zgykTQsJxoM9Py5vosA:9 a=CjuIK1q_8ugA:10
 a=IjZwj45LgO3ly-622nXo:22 a=udpbrAo2yJH2O6eCpvBn:22 a=Ia-lj3WSrqcvXOmTRaiG:22
 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id 5769DB1;
	Sat, 27 Aug 2022 09:37:14 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id 410FBAA; Sat, 27 Aug 2022 09:37:14 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Cy Schubert 
cc: Juraj Lutter , freebsd@walstatt-de.de,
    Michael Gmelin , freebsd@oldach.net,
    freebsd-current@freebsd.org, freebsd-ports@freebsd.org,
    yasu@freebsd.org
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by 
 design
In-reply-to: <20220827082638.57901a72@slippy>
References: <202208271318.27RDI9Jd044045@nuc.oldach.net> 
  
  
 <20220827082638.57901a72@slippy>
Comments: In-reply-to Cy Schubert 
   message dated "Sat, 27 Aug 2022 08:26:38 -0700."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 27 Aug 2022 09:37:14 -0700
Message-Id: <20220827163714.410FBAA@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfGzkOoVaZn2R6RKJsmpB1H0/JqkP53yvp578xLooRj1n9qW8gtLF0DwVfkLEDDTyXnm3FYAuFrSinZj9n2EXIje/m6eMSrq0+GkH8DK95PGSST/cY3yz
 Wg+qP8N3vpshX0KTXFW0d76rHp9xbFUlqy/3C9CbQQMFf7y6KscwJgemuq09McMXvLy9X+bHhdz7RrYU//8bcCuePumLtAjRdf/Li3KjDz2n4MRLEgwMDTLA
 la3B+XdKx2wkC4Xx54MFr7/0ucPXbaEw/L9NGenMXDCHfXUwhOdKt18G64bNb+38SIe9YUUkcbikUga5NLtJ2OI8W/VkDnQfOfXnWpW6VAhI1OeAGszST08j
 pUgIOs8bNO/7/ERWAIRMV3zpQ7G9ZdbanDfwwlgDQVGfVLJWl0g=
X-Rspamd-Queue-Id: 4MFMms5r46z3lRH
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[8];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	REPLYTO_EQ_FROM(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message <20220827082638.57901a72@slippy>, Cy Schubert writes:
> On Sat, 27 Aug 2022 15:38:44 +0200
> Juraj Lutter  wrote:
>
> > > On 27 Aug 2022, at 15:27, Michael Gmelin  wrote:
> > >=20
> > >=20
> > >  =20
> > >> On 27. Aug 2022, at 15:18, freebsd@oldach.net wrote:
> > >>=20
> > >> =EF=BB=BFMichael Gmelin wrote on Sat, 27 Aug 2022 15:02:04 +0200 (CEST=
> ): =20
> > >>> (you're removing /var/run, which shouldn't be removed =20
> > >>=20
> > >> Not quite. It's actually not uncommon to boot with an empty /var. Plea=
> se see /etc/rc.d/var and related. =20
> > >=20
> > > That=E2=80=99s a good point.
> > >  =20
> > >> The request that ports/packages should consider this case is not exact=
> ly unreasonable IMO.
> > >>  =20
> > >=20
> > > If I was the maintainer, I would simply add the code to create the dire=
> ctory for robustness sake (I for one deleted subdirs in /var/run more than =
> once and would expect a port to fix this on restart, also to make sure corr=
> ect permissions are applied). But since it doesn=E2=80=99t seem like this i=
> s going to happen, adding a custom rc file would be a viable short term wor=
> karound for the requester.
> > >=20
> > > I like the idea of having something like tmpfiles.d, it would also help=
>  port maintainers (could also be done as a port).
> > >  =20
> >=20
> > As I have stated in one of those PR: clamd creates file in two locations:
> >=20
> > - PidFile
> > - LocalSocket
> >=20
> > Both the locations could be checked by rc.d script in clamd.conf (also fr=
> eshclam eventually) and respective directories can be created from within s=
> tart_precmd()
> >=20
> > otis
> >=20
> > =E2=80=94
> > Juraj Lutter
> > otis@FreeBSD.org
> >=20
>
> As stated before in this thread, replacing /var/run with tmpfs is not a
> supported configuration. However if users wish to replace /var/run
> with tmpfs they can create an rc script (I put my extra rc scripts in
> /etc/local/rc.d) to create the hierarc
> If one does this they can either use mtree(1) to create the hierarchy
> or simply take a snapshot (find /var/run -type d | cpio -o >
> /etc/local/my_var_run.cpio), having their rc script recreate the
> hierarchy using cpio -i < /etc/local/my_var_run.cpio). And
> be periodically updated the archive as needed, probably through a
> shutdown script.
>
> One will notice that /etc/mtree/BSD.var.dist shows us what is created
> in /var/run by default during installworld.
>
> The change requested is not specifically for an individual port but
> essentially a FreeBSD-wide infrastructure change. I don't think this
> is reasonable without a lot of consideration about what will be broken
> during the process of changing build and boot processes and the
> potential POLA fallout from such a change. A change like this needs to
> be architected.
>
> I don't think this is the mailing list to discuss this topic. This
> should be discussed on ports@. Not here. Maybe it should be moved there
> as this is a ports not a base O/S issue.

This will resolve the problem:

#!/bin/sh

# PROVIDE: kq-var-run
# REQUIRE: zfs tmp
# BEFORE: FILESYSTEMS

. /etc/rc.subr

name=kq_var_run
rcvar=kq_var_run_enable
extra_commands="update create"
start_cmd="kq_var_run_start"
create_cmd="kq_var_run_create"
update_cmd="kq_var_run_create"
# stop_cmd="kq_var_run_create"

load_rc_config $name

# Set defaults
: ${kq_var_run_enable:="NO"}
: ${kq_var_run_mtree:="/etc/local/mtree/KQ.var-run.mtree"}

kq_var_run_start() {
	df -ttmpfs /var/run > /dev/null 2>&1 &&
		mtree -f ${kq_var_run_mtree} -p /var/run
}

kq_var_run_create() {
	mtree -cbdj -p /var/run > ${kq_var_run_mtree}
}

run_rc_command "$1"

A person could add stop_cmd="kq_var_run_create" to save the /var/run mtree 
at shutdown instead of manually. Works with tmpfs /var/run.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e^(i*pi)+1=0



From nobody Sun Aug 28 09:37:16 2022
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 4MFpPz3Xm6z4bD8P;
	Sun, 28 Aug 2022 09:37:27 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFpPx1BcQz3qP4;
	Sun, 28 Aug 2022 09:37:25 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id c4920b47;
	Sun, 28 Aug 2022 09:37:17 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id fa4950c3 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Sun, 28 Aug 2022 09:37:17 +0000 (UTC)
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 (1.0)
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by design
From: Michael Gmelin 
In-Reply-To: <202208280842.27S8gDXn055868@nuc.oldach.net>
Date: Sun, 28 Aug 2022 11:37:16 +0200
Cc: Cy.Schubert@cschubert.com, otis@freebsd.org, freebsd@walstatt-de.de,
 freebsd-current@freebsd.org, freebsd-ports@freebsd.org, yasu@freebsd.org
Message-Id: <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>
References: <202208280842.27S8gDXn055868@nuc.oldach.net>
To: freebsd@oldach.net
X-Mailer: iPhone Mail (19G82)
X-Rspamd-Queue-Id: 4MFpPx1BcQz3qP4
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-2.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[7];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[grembo];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	TO_DN_NONE(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote:
>=20
> =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 (CEST):
>> As stated before in this thread, replacing /var/run with tmpfs is not a
>> supported configuration.
>=20
> Not supported? What is the purpose of /etc/rc.d/var then? That creates a t=
mpfs backed /var, populates it through mtree, and makes a proper /var/run av=
ailable.
>=20
> However it doesn't (yet) create /var/run/clamav of course.
>=20
> It would be fairly easy to extend /etc/rc.d/var by a logic that walks thro=
ugh /usr/local/etc/mtree/* and runs mtree on each of the files found as need=
ed. All that the security/clamav port would need to do then is to drop an ap=
propriate small mtree file as /usr/local/etc/mtree/clamav. =46rom a port's p=
erspective that is the same logic as dropping service scripts as /usr/local/=
etc/rc.d/clamav-*.

=46rom a user's perspective, it would be preferable to have this happen at s=
ervice start though, as (unlike in the setup described) reboots don't happen=
 that frequently, but files in /var/run might get deleted manually. Maybe so=
me rc framework based solution would make sense, e.g., a variable `mtree_fil=
es`, which, if set, is applied in the default start_precmd. Besides being mo=
re resilient, this would also have the advantage that all required file syst=
ems should be available at that point and the separation between system and p=
orts would be more clear. Another advantage would be that directories are on=
ly created for services that are actually enabled/started.

Cheers
Michael



From nobody Sun Aug 28 09:43:21 2022
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 4MFpY22Jhgz4bDfV;
	Sun, 28 Aug 2022 09:43:34 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFpY047Zpz3s2g;
	Sun, 28 Aug 2022 09:43:32 +0000 (UTC)
	(envelope-from agh@riseup.net)
Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84])
	(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
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.riseup.net", Issuer "R3" (not verified))
	by mx0.riseup.net (Postfix) with ESMTPS id 4MFpXy6FH7z9sBk;
	Sun, 28 Aug 2022 09:43:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
	t=1661679811; bh=3doXzHEzYA4rs52rMpQGRBmbAeDSkGsTsld9btxcjEM=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=syB9wQJr7T7s/qZThgNRvCR+cvbfH4BkgQsrhioNisfAowlWn2uCCKCCj9pIep3tL
	 u1e6Trh1crg3Hc78q2Ba+46z83YzcVFzEIC69wR6lZgl+sFCH2eVJN4O7eYUVcbHwH
	 RKos1ynkV2BrywCTubfBZMENJZ1Ug5QHxnmzoE5o=
X-Riseup-User-ID: 67E60D59F6D5C73433D63EA6FBE0C536A2E329B60F4F02D86F749C40E9FE73F4
Received: from [127.0.0.1] (localhost [127.0.0.1])
	 by fews2.riseup.net (Postfix) with ESMTPSA id 4MFpXv42G5z1y9N;
	Sun, 28 Aug 2022 09:43:27 +0000 (UTC)
Date: Sun, 28 Aug 2022 17:43:21 +0800
From: Alastair Hogge 
To: Michael Gmelin 
Cc: freebsd@oldach.net, Cy.Schubert@cschubert.com, otis@freebsd.org,
 freebsd@walstatt-de.de, freebsd-current@freebsd.org,
 freebsd-ports@freebsd.org, yasu@freebsd.org
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by
 design
Message-ID: <20220828174321.59b23cbc@direwolf.home.arpa>
In-Reply-To: <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>
References: <202208280842.27S8gDXn055868@nuc.oldach.net>
	<163333B4-76A1-4E46-B7C3-60492D379C6E@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=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4MFpY047Zpz3s2g
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=riseup.net header.s=squak header.b=syB9wQJr;
	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
X-Spamd-Result: default: False [-4.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	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];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_SEVEN(0.00)[8];
	ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[riseup.net:+];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[riseup.net:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sun, 28 Aug 2022 11:37:16 +0200
Michael Gmelin  wrote:

> > On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote:
> >=20
> > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 (CEST): =
=20
> >> As stated before in this thread, replacing /var/run with tmpfs is
> >> not a supported configuration. =20
> >=20
> > Not supported? What is the purpose of /etc/rc.d/var then? That
> > creates a tmpfs backed /var, populates it through mtree, and makes
> > a proper /var/run available.
> >=20
> > However it doesn't (yet) create /var/run/clamav of course.
> >=20
> > It would be fairly easy to extend /etc/rc.d/var by a logic that
> > walks through /usr/local/etc/mtree/* and runs mtree on each of the
> > files found as needed. All that the security/clamav port would need
> > to do then is to drop an appropriate small mtree file as
> > /usr/local/etc/mtree/clamav. From a port's perspective that is the
> > same logic as dropping service scripts as
> > /usr/local/etc/rc.d/clamav-*. =20
>=20
> From a user's perspective, it would be preferable to have this happen
> at service start though, as (unlike in the setup described) reboots
> don't happen that frequently, but files in /var/run might get deleted
> manually. Maybe some rc framework based solution would make sense,
> e.g., a variable `mtree_files`, which, if set, is applied in the
> default start_precmd. Besides being more resilient, this would also
> have the advantage that all required file systems should be available
> at that point and the separation between system and ports would be
> more clear. Another advantage would be that directories are only
> created for services that are actually enabled/started.

Yes, something in the RC framework would be nice.

From nobody Sun Aug 28 10:05:01 2022
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 4MFq1v4m3Bz4bGHB;
	Sun, 28 Aug 2022 10:05:07 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFq1t4Gssz3tbM;
	Sun, 28 Aug 2022 10:05:06 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250])
	by cmsmtp with ESMTP
	id SBKpoRgu9S8WrSFA9oPnhv; Sun, 28 Aug 2022 10:05:05 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id SFA6onPz9C3uhSFA8o0eUs; Sun, 28 Aug 2022 10:05:05 +0000
X-Authority-Analysis: v=2.4 cv=a6MjSGeF c=1 sm=1 tr=0 ts=630b3dd1
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=biHskzXt2R4A:10 a=XldT38RWNwACPDQzwzUA:9 a=gRS1eiuiAAAA:8
 a=eM-nEs0M4Gr-ZpHJD-4A:9 a=CjuIK1q_8ugA:10 a=3xW0S8O8ZcswAB4HatcA:9
 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=ics_IjAVWSmO8OVX31YA:9
 a=BOg4e644cxQA:10 a=udpbrAo2yJH2O6eCpvBn:22 a=Ia-lj3WSrqcvXOmTRaiG:22
 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id 0B801BC4;
	Sun, 28 Aug 2022 03:05:02 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id EBA69307; Sun, 28 Aug 2022 03:05:01 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: freebsd@oldach.net (Helge Oldach)
cc: Cy.Schubert@cschubert.com (Cy Schubert), otis@FreeBSD.org,
    freebsd@walstatt-de.de, grembo@freebsd.org,
    freebsd-current@freebsd.org, freebsd-ports@freebsd.org,
    yasu@freebsd.org
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by 
 design
In-reply-to: <202208280842.27S8gDXn055868@nuc.oldach.net>
References: <202208280842.27S8gDXn055868@nuc.oldach.net>
Comments: In-reply-to freebsd@oldach.net (Helge Oldach)
   message dated "Sun, 28 Aug 2022 10:42:13 +0200."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: multipart/mixed ;
	boundary="==_Exmh_1661679707_33080"
Date: Sun, 28 Aug 2022 03:05:01 -0700
Message-Id: <20220828100501.EBA69307@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfFBEpWwwPTBxqnWg+tH2lUmE/2HAC2j5+HiZy80t6YXaGQI3tmxL8MxDA7Qykrak2wV61SL9UzF30AhBtnS7TzRO1d3aO8N7De1Q4GV/rywgaQ03SaJy
 GIuSzI6YofvMIy1YYq55HKKABZjafjwrk3NP/UpgeJTAg3JBB3SHj8z5AeJqonX4kXHUhMf5r6G2SxllBgV2t3u1BrcDlzA6AyaHLoTGvGzS31bASl8ly1N0
 cchH0L1o5b1sCCWpDNdVIPZYSMaHfzZnM/O80UD043fIo2bGVdod41IBOLFH0T8iroxl6G8S5OvpIRW/xldZorcsdBjoxP6/GjN1DFmo2jk9uovCZlTuiLTR
 08CQ6P2+3rpu9xDYWE5X3gJ8lRwp/rtkkFpu7URX1e7kRVuhDyQ=
X-Rspamd-Queue-Id: 4MFq1t4Gssz3tbM
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	RCPT_COUNT_SEVEN(0.00)[8];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	REPLYTO_EQ_FROM(0.00)[];
	TO_DN_NONE(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multipart MIME message.

--==_Exmh_1661679707_33080
Content-Type: text/plain; charset=us-ascii

In message <202208280842.27S8gDXn055868@nuc.oldach.net>, Helge Oldach 
writes:
> Cy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 (CEST):
> > As stated before in this thread, replacing /var/run with tmpfs is not a
> > supported configuration.
>
> Not supported? What is the purpose of /etc/rc.d/var then? That creates a tmpf
> s backed /var, populates it through mtree, and makes a proper /var/run availa
> ble.
>
> However it doesn't (yet) create /var/run/clamav of course.
>
> It would be fairly easy to extend /etc/rc.d/var by a logic that walks through
>  /usr/local/etc/mtree/* and runs mtree on each of the files found as needed. 
> All that the security/clamav port would need to do then is to drop an appropr
> iate small mtree file as /usr/local/etc/mtree/clamav. From a port's perspecti
> ve that is the same logic as dropping service scripts as /usr/local/etc/rc.d/
> clamav-*.
>
> Kind regards
> Helge

This is because you don't already have a /var/run/clamav yet. Unfortunately 
this dies not retroactively create /var/run/clamav.

My new copy of the script, attached, also does not retroactively create the 
directory. Create the directory by hand. Use your server. Reboot and the 
directories will be recreated.

If converting from UFS or ZFS /var/run, simply add the tmpfs mountpoint 
after adding and enabling the script and reboot. (I prefix all locally 
written scripts with kq-).

Remember, this does not retroactively create /var/run/clamav if it doesn't 
already exist. This only makes mounting of tmpfs /var/run an option 
possible.



--==_Exmh_1661679707_33080
Content-Type: text/plain ; name="kq-var-run"; charset=us-ascii
Content-Description: kq-var-run

#!/bin/sh

# PROVIDE: kq-var-run
# REQUIRE: zfs tmp
# BEFORE: FILESYSTEMS

. /etc/rc.subr

name=kq_var_run
rcvar=kq_var_run_enable
extra_commands="load save"
start_cmd="kq_var_run_start"
load_cmd="kq_var_run_load"
save_cmd="kq_var_run_save"
stop_cmd="kq_var_run_stop"

load_rc_config $name

# Set defaults
: ${kq_var_run_enable:="NO"}
: ${kq_var_run_mtree:="/var/db/mtree/BSD.var-run.mtree"}
: ${kq_var_run_autosave:="YES"}

kq_var_run_load() {
	test -f ${kq_var_run_mtree} &&
		mtree -U -i -q -f ${kq_var_run_mtree} -p /var/run > /dev/null
}

kq_var_run_save() {
	if [ ! -d $(dirname ${kq_var_run_mtree}) ]; then
		mkdir -p ${kq_var_run_mtree}
	fi
	mtree -dcbj -p /var/run > ${kq_var_run_mtree}
}

kq_var_run_start() {
	df -ttmpfs /var/run > /dev/null 2>&1 &&
		kq_var_run_load
}

kq_var_run_stop() {
	df -ttmpfs /var/run > /dev/null 2>&1 && 
		checkyesno kq_var_run_autosave &&
			kq_var_run_save
}

run_rc_command "$1"

--==_Exmh_1661679707_33080
Content-Type: text/plain; charset=us-ascii

Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e^(i*pi)+1=0

--==_Exmh_1661679707_33080--



From nobody Sun Aug 28 10:21:24 2022
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 4MFqNm2FrZz4bHhF;
	Sun, 28 Aug 2022 10:21:28 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFqNl1QXxz3wjy;
	Sun, 28 Aug 2022 10:21:27 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227])
	by cmsmtp with ESMTP
	id RxJfosJ4aSp39SFPyoROL8; Sun, 28 Aug 2022 10:21:26 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id SFPwoy91NGRNlSFPxojEhB; Sun, 28 Aug 2022 10:21:26 +0000
X-Authority-Analysis: v=2.4 cv=Sfrky9du c=1 sm=1 tr=0 ts=630b41a6
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=biHskzXt2R4A:10 a=6I5d2MoRAAAA:8 a=gRS1eiuiAAAA:8
 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=z6ogyWo-_p8JWzdixu8A:9 a=CjuIK1q_8ugA:10
 a=IjZwj45LgO3ly-622nXo:22 a=udpbrAo2yJH2O6eCpvBn:22 a=Ia-lj3WSrqcvXOmTRaiG:22
 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id 53B42BE1;
	Sun, 28 Aug 2022 03:21:24 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id 409EC26D; Sun, 28 Aug 2022 03:21:24 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Michael Gmelin 
cc: freebsd@oldach.net, Cy.Schubert@cschubert.com, otis@freebsd.org,
    freebsd@walstatt-de.de, freebsd-current@freebsd.org,
    freebsd-ports@freebsd.org, yasu@freebsd.org
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by 
 design
In-reply-to: <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>
References: <202208280842.27S8gDXn055868@nuc.oldach.net> 
 <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>
Comments: In-reply-to Michael Gmelin 
   message dated "Sun, 28 Aug 2022 11:37:16 +0200."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 28 Aug 2022 03:21:24 -0700
Message-Id: <20220828102124.409EC26D@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfENr+TLOMsoVU549R2YUtKs/gclD7ge5ZvAT+ngpl49mIbzr8s2HTdwruu1jIGernIV1+EmNewtVix9E2ozQcu2tZW/gFdmR7kdjsTBY9Pm95OG4gSyi
 q+wv6ETb4vmZnqXJvOWKnGXGp8k15xw6vRjivPDs56QnBAYfCoFq1dVQjKF3j+AxdaqOtRwKA9l1nobJVLE/ft2wFHjmZRv1Wa8k41+efNrmKSiZrUvZO7u7
 vRhyiiQxBIsd9Tin+XkACtHBP3+6jT5jZdRialUnvNgC9p1lsrxqPBvQxnUqCi/ss1Ze8JFv95mkSOPZ1jFrqB+YUxHgdXrOXEAN8R5gP5LjbmDIDzrwg+Nv
 9XfWqWQ+LMJXvQbAMzrzhyjig6Ec/Z2ZVlUq1NzKT3m1xCfbesg=
X-Rspamd-Queue-Id: 4MFqNl1QXxz3wjy
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[8];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	REPLYTO_EQ_FROM(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>, Michael 
Gmelin w
rites:
> 
>
>
> > On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote:
> >=20
> > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 (CEST):
> >> As stated before in this thread, replacing /var/run with tmpfs is not a
> >> supported configuration.
> >=20
> > Not supported? What is the purpose of /etc/rc.d/var then? That creates a t=
> mpfs backed /var, populates it through mtree, and makes a proper /var/run av=
> ailable.
> >=20
> > However it doesn't (yet) create /var/run/clamav of course.
> >=20
> > It would be fairly easy to extend /etc/rc.d/var by a logic that walks thro=
> ugh /usr/local/etc/mtree/* and runs mtree on each of the files found as need=
> ed. All that the security/clamav port would need to do then is to drop an ap=
> propriate small mtree file as /usr/local/etc/mtree/clamav. =46rom a port's p=
> erspective that is the same logic as dropping service scripts as /usr/local/=
> etc/rc.d/clamav-*.
>
> =46rom a user's perspective, it would be preferable to have this happen at s=
> ervice start though, as (unlike in the setup described) reboots don't happen=
>  that frequently, but files in /var/run might get deleted manually. Maybe so=
> me rc framework based solution would make sense, e.g., a variable `mtree_fil=
> es`, which, if set, is applied in the default start_precmd. Besides being mo=
> re resilient, this would also have the advantage that all required file syst=
> ems should be available at that point and the separation between system and p
> =
> orts would be more clear. Another advantage would be that directories are on=
> ly created for services that are actually enabled/started.

Unfortunately this requires all ports to include an mtree file. Relying on 
port maintainers who are human to ensure that these files are created and 
updated when ports are created and maintained will result in more human 
error. I've learned over my long career to rely more on automation than 
human beings. Automation [should] never fail and when it does it does 
temporarily until the bug is found and fixed. Human beings inconsistently 
fail.

If it were an auto-discovery script that created an mtree file as part of 
the packaging process, it would be another matter. But this optional 
solution path should be discussed on ports@, not here.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e^(i*pi)+1=0




From nobody Sun Aug 28 11:01:07 2022
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 4MFrGq01nJz4bLSw;
	Sun, 28 Aug 2022 11:01:23 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: from mail.evolve.de (mail.evolve.de [213.239.217.29])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "mail.evolve.de", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFrGn2qpsz40gJ;
	Sun, 28 Aug 2022 11:01:21 +0000 (UTC)
	(envelope-from grembo@freebsd.org)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTP id 0355e33b;
	Sun, 28 Aug 2022 11:01:19 +0000 (UTC)
Received: 
	by mail.evolve.de (OpenSMTPD) with ESMTPSA id 1026e1c6 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO);
	Sun, 28 Aug 2022 11:01:19 +0000 (UTC)
Date: Sun, 28 Aug 2022 13:01:07 +0200
From: Michael Gmelin 
To: Cy Schubert 
Cc: Michael Gmelin , freebsd@oldach.net,
 otis@freebsd.org, freebsd@walstatt-de.de, freebsd-current@freebsd.org,
 freebsd-ports@freebsd.org, yasu@freebsd.org
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by 
 design
Message-ID: <20220828130107.1a76d54a.grembo@freebsd.org>
In-Reply-To: <20220828102124.409EC26D@slippy.cwsent.com>
References: <202208280842.27S8gDXn055868@nuc.oldach.net>
	<163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>
	<20220828102124.409EC26D@slippy.cwsent.com>
X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}>
 +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl
 LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL
 EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl
 YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq
 AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY
 fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM
 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea
 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+
 xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA
 Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n
 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v
 f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT
 L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF
 CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc
 Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII=
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MFrGn2qpsz40gJ
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org
X-Spamd-Result: default: False [-2.10 / 15.00];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[8];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	FREEFALL_USER(0.00)[grembo];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On Sun, 28 Aug 2022 03:21:24 -0700
Cy Schubert  wrote:

> In message <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>,
> Michael Gmelin w
> rites:
> > 
> >
> >  
> > > On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote:
> > >=20
> > > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200
> > > (CEST):  
> > >> As stated before in this thread, replacing /var/run with tmpfs
> > >> is not a supported configuration.  
> > >=20
> > > Not supported? What is the purpose of /etc/rc.d/var then? That
> > > creates a t=  
> > mpfs backed /var, populates it through mtree, and makes a proper
> > /var/run av= ailable.  
> > >=20
> > > However it doesn't (yet) create /var/run/clamav of course.
> > >=20
> > > It would be fairly easy to extend /etc/rc.d/var by a logic that
> > > walks thro=  
> > ugh /usr/local/etc/mtree/* and runs mtree on each of the files
> > found as need= ed. All that the security/clamav port would need to
> > do then is to drop an ap= propriate small mtree file as
> > /usr/local/etc/mtree/clamav. =46rom a port's p= erspective that is
> > the same logic as dropping service scripts as /usr/local/=
> > etc/rc.d/clamav-*.
> >
> > =46rom a user's perspective, it would be preferable to have this
> > happen at s= ervice start though, as (unlike in the setup
> > described) reboots don't happen= that frequently, but files in
> > /var/run might get deleted manually. Maybe so= me rc framework
> > based solution would make sense, e.g., a variable `mtree_fil= es`,
> > which, if set, is applied in the default start_precmd. Besides
> > being mo= re resilient, this would also have the advantage that all
> > required file syst= ems should be available at that point and the
> > separation between system and p = orts would be more clear. Another
> > advantage would be that directories are on= ly created for services
> > that are actually enabled/started.  
> 
> Unfortunately this requires all ports to include an mtree file.
> Relying on port maintainers who are human to ensure that these files
> are created and updated when ports are created and maintained will
> result in more human error. I've learned over my long career to rely
> more on automation than human beings. Automation [should] never fail
> and when it does it does temporarily until the bug is found and
> fixed. Human beings inconsistently fail.
> 
> If it were an auto-discovery script that created an mtree file as
> part of the packaging process, it would be another matter. But this
> optional solution path should be discussed on ports@, not here.
> 
> 

I don't have much skin in the game, but I created a little proof of
concept to allow further discussion (which is not ports-specific, as it
works for all service scripts):

https://reviews.freebsd.org/D36385

This basically allows both system admins and port maintainers to
create mtree files in /usr/local/etc/mtree (or /etc/mtree, as it's
always relative to the service script called) which are automatically
applied on service start. It's non-intrusive and doesn't require any
sweeping changes to existing ports/services.

In this specific case, the requester could create
/usr/local/etc/mtree/clamav-clamd with the required content (or
persuade the port maintainer to include that file).

You could of course add some construct to the ports framework that
picks up certain directories from the package list automatically and
places them into an mtree file as part of the build or installation
process. But that would be an additional feature on top of this change.

This is meant to inspire more discussions, I'm not trying to force
anything in. ;)

Cheers
Michael

-- 
Michael Gmelin

From nobody Sun Aug 28 13:11:20 2022
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 4MFv8r71qdz4ZZTc;
	Sun, 28 Aug 2022 13:11:24 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MFv8q6pyHz47N3;
	Sun, 28 Aug 2022 13:11:23 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142])
	by cmsmtp with ESMTP
	id SHnyoRnxvS8WrSI4RoPzF5; Sun, 28 Aug 2022 13:11:23 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id SI4PorK7juJwwSI4PoTmPw; Sun, 28 Aug 2022 13:11:23 +0000
X-Authority-Analysis: v=2.4 cv=F+BEy4tN c=1 sm=1 tr=0 ts=630b697b
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=biHskzXt2R4A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8
 a=gRS1eiuiAAAA:8 a=EkcXrb_YAAAA:8 a=haJdyl2PuIvToo3mPV8A:9 a=CjuIK1q_8ugA:10
 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=udpbrAo2yJH2O6eCpvBn:22
 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id CD16DC71;
	Sun, 28 Aug 2022 06:11:20 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id C3781317; Sun, 28 Aug 2022 06:11:20 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Michael Gmelin 
cc: Cy Schubert , freebsd@oldach.net,
    otis@freebsd.org, freebsd@walstatt-de.de,
    freebsd-current@freebsd.org, freebsd-ports@freebsd.org,
    yasu@freebsd.org
Subject: Re: security/clamav: /ar/run on TMPFS renders the port broken by 
 design
In-reply-to: <20220828130107.1a76d54a.grembo@freebsd.org>
References: <202208280842.27S8gDXn055868@nuc.oldach.net> 
 <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org> 
 <20220828102124.409EC26D@slippy.cwsent.com> <20220828130107.1a76d54a.grembo@freebsd.org>
Comments: In-reply-to Michael Gmelin 
   message dated "Sun, 28 Aug 2022 13:01:07 +0200."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 28 Aug 2022 06:11:20 -0700
Message-Id: <20220828131120.C3781317@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfKkQmmCNPaOcN6yeOjUAajwkZ5rcAKXFGIO12O0q/Mays8QFxkJfMa6plv2ucTS27u4Zmw+zJBMXxiGcLgDW+odNRH/KoRhFcVRJSPn8/15+bR0LOtga
 EMrvQdPn1Ene7NnUdrMZ1vha8gh0msmtj4zB7+ayDSUEWx95Uc7WSmoJ3TnU30a5cTPNEOCeW5tEK8Lx1ol8zxE+1AyBuOvf921m6jL/nMzFEDCSTZk6ExAz
 f7zemrJpmFkfrClIoNmjN1uqg3pHTiRppPfPdMBlfl9i/WXdFW7mHXZaIIhRqbAphW7eyJlKbZN59jVbuRcMUzZR7ifzHT2OI94+ElgmqH6IzMnZWaTDF70e
 ZvyAYPrIodxUB/bBGNmpW3JyJhWprRa5cHLYy/6+vZKsV2fH+2Y=
X-Rspamd-Queue-Id: 4MFv8q6pyHz47N3
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[8];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	REPLYTO_EQ_FROM(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message <20220828130107.1a76d54a.grembo@freebsd.org>, Michael Gmelin 
writes:
> 
>
>
> On Sun, 28 Aug 2022 03:21:24 -0700
> Cy Schubert  wrote:
>
> > In message <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>,
> > Michael Gmelin w
> > rites:
> > > 
> > >
> > >  
> > > > On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote:
> > > >=20
> > > > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200
> > > > (CEST):  
> > > >> As stated before in this thread, replacing /var/run with tmpfs
> > > >> is not a supported configuration.  
> > > >=20
> > > > Not supported? What is the purpose of /etc/rc.d/var then? That
> > > > creates a t=  
> > > mpfs backed /var, populates it through mtree, and makes a proper
> > > /var/run av= ailable.  
> > > >=20
> > > > However it doesn't (yet) create /var/run/clamav of course.
> > > >=20
> > > > It would be fairly easy to extend /etc/rc.d/var by a logic that
> > > > walks thro=  
> > > ugh /usr/local/etc/mtree/* and runs mtree on each of the files
> > > found as need= ed. All that the security/clamav port would need to
> > > do then is to drop an ap= propriate small mtree file as
> > > /usr/local/etc/mtree/clamav. =46rom a port's p= erspective that is
> > > the same logic as dropping service scripts as /usr/local/=
> > > etc/rc.d/clamav-*.
> > >
> > > =46rom a user's perspective, it would be preferable to have this
> > > happen at s= ervice start though, as (unlike in the setup
> > > described) reboots don't happen= that frequently, but files in
> > > /var/run might get deleted manually. Maybe so= me rc framework
> > > based solution would make sense, e.g., a variable `mtree_fil= es`,
> > > which, if set, is applied in the default start_precmd. Besides
> > > being mo= re resilient, this would also have the advantage that all
> > > required file syst= ems should be available at that point and the
> > > separation between system and p = orts would be more clear. Another
> > > advantage would be that directories are on= ly created for services
> > > that are actually enabled/started.  
> > 
> > Unfortunately this requires all ports to include an mtree file.
> > Relying on port maintainers who are human to ensure that these files
> > are created and updated when ports are created and maintained will
> > result in more human error. I've learned over my long career to rely
> > more on automation than human beings. Automation [should] never fail
> > and when it does it does temporarily until the bug is found and
> > fixed. Human beings inconsistently fail.
> > 
> > If it were an auto-discovery script that created an mtree file as
> > part of the packaging process, it would be another matter. But this
> > optional solution path should be discussed on ports@, not here.
> > 
> > 
>
> I don't have much skin in the game, but I created a little proof of
> concept to allow further discussion (which is not ports-specific, as it
> works for all service scripts):
>
> https://reviews.freebsd.org/D36385

I've been toying with the idea for a few months but was never bothered to 
create a review or even a script for that matter.

>
> This basically allows both system admins and port maintainers to
> create mtree files in /usr/local/etc/mtree (or /etc/mtree, as it's
> always relative to the service script called) which are automatically
> applied on service start. It's non-intrusive and doesn't require any
> sweeping changes to existing ports/services.

Understood that this is a manual process.

>
> In this specific case, the requester could create
> /usr/local/etc/mtree/clamav-clamd with the required content (or
> persuade the port maintainer to include that file).
>
> You could of course add some construct to the ports framework that
> picks up certain directories from the package list automatically and
> places them into an mtree file as part of the build or installation
> process. But that would be an additional feature on top of this change.

Someone could. Personally, I think that's a lot of work compared to simply 
saving the state of /var/run at shutdown and restoring it at boot. I can't 
speak for the ports management though.

>
> This is meant to inspire more discussions, I'm not trying to force
> anything in. ;)

Agreed.

I cobbled something up yesterday that saves the directory tree state of 
/var/run prior to shutdown (or manually) and restores it at boot.

https://reviews.freebsd.org/D36386

People can try it out if they want. If there's enough interest I'd be 
willing to commit it.

We have a few options on the table and probably more. The ports 
infrastructure option is probably the most work. Adding functionality to 
all the ports that use /var/run is also a lot of work and if relying on 
individual porters, will likely take some time and be varied in 
implementation and robustness.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e^(i*pi)+1=0






From nobody Sun Aug 28 19:28:14 2022
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 4MG3Wg63lHz4bCgd
	for ; Sun, 28 Aug 2022 19:28:15 +0000 (UTC)
	(envelope-from freqlabs@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MG3Wg5Xs0z3YmL
	for ; Sun, 28 Aug 2022 19:28:15 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661714895;
	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=hU8AkK8bAlAwlF0ASlXJXOhaHvoOAYJZOaV2TbTrjoM=;
	b=vjKcXKJM1gF9JOJO7YhhS5fOmTesuERdS2K19PkgDxEXsr1r1soXJAtad69g4o858BVzmP
	l3HBeaGOqhRHzOAfNTUKsuY/4xZd451X0F5hjjEeL7/28ZsLUDJsfl3lGYr9SjGAoP5GUZ
	fifKHRA6tue/fjMPiRUkmBkT6UfoLKoo1zzrtzUdb51DMlDL68V4n744yJ4PgpOY+mxlbB
	JLknJEx9a9gg8kohP13iCywlpwgFG24y5teMRczJUF0IIstYzqQpfmv+XCCHcOxjtM0U79
	5hOb+UqftiUjz9N2vBIoSYjVcPUxSpXx9JOBQDVMumDLM0bJijSezTbo9qvHPw==
Received: from [IPV6:2600:1700:358a:c660:c85c:eb28:4f32:5c18] (unknown [IPv6:2600:1700:358a:c660:c85c:eb28:4f32:5c18])
	(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: freqlabs/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MG3Wg3rKcz1Dtc
	for ; Sun, 28 Aug 2022 19:28:15 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
Message-ID: 
Date: Sun, 28 Aug 2022 15:28:14 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.13.0
Subject: Re: Beadm can't create snapshot
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
 
From: Ryan Moeller 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661714895;
	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=hU8AkK8bAlAwlF0ASlXJXOhaHvoOAYJZOaV2TbTrjoM=;
	b=Y1cTT/J9RT2HrT2cRL3RoWN1rmChhXT8ECmchHZLSTJTiLouU6trNFppeLjLU9MzRAD2/G
	1UqHWMJfnXQymRhIHME5DWWgdsQMup6T0rZS/ArNzlucNeU+nP00V/CFTY7V1X3CEQLL3O
	ooMth8bFO/sN0sTBiXkoK8ITEna3DjS1dcJgVZj/iTHx/f62exCJ6lOcY3Uuz3gTj3bFBg
	S6sQpFjtpr17V1gapbcIp/H8eaZ4Oh4jkX+Xdg1NkKoJt0JUu7+Z5tm8kLu85qtjvdtkH+
	CGg+i/KhJjpu+CWlxvwzvcHJL1TL8FkO4aBG+VI+WKQs4iQyM696ts4xk6+thg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661714895; a=rsa-sha256; cv=none;
	b=SeI1vATT2rY8TUwk5RYsi4tgxkdaPhVFDSahVXSUrk8kO50jo8bCOrmiTscl+nNF94F2LM
	Ulh1aT5RAotgnbIADv5ua1GD74fJrcE2OullkcL+SY4jGMgqTZT9iG7Bv5NWTSYeRj6GC/
	mkgGiMXAYvoI79PazPH0oX+NHQKU/7hHLKPB0aLEfh6jrL7PyxCp7Fl6so0Dpy2Z2HNWas
	t6kmVCQSBSU8RQFWIXjjG/+3ASEBLnQoTbwUO4Pl8AbFDdnbx6vEKxRyQHKr/xlR4LpYHb
	GoqGF/MoyjP8cmaE0LzbKwUAs/KxJHknUM8qIqLFJVNotp0qgkSwTim01IciQw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


On 8/17/22 12:16 PM, Ryan Moeller wrote:
>
> On 8/17/22 12:05 PM, Ryan Moeller wrote:
>>
>> On 8/17/22 10:35 AM, Thomas Laus wrote:
>>> I attempted to create a ZFS snapshot after upgrading this morning 
>>> and received this error
>>>
>>> # beadm create n257443
>>> cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly
>>> #
>>
>>
>> This looks like a bug in beadm. It must be trying to set the 
>> snapshots_changed property when cloning the snapshot for the BE, but 
>> the property is of course readonly.
>>
>> -Ryan
>>
>
> I took a closer look at what beadm is doing and this appears to be a 
> bug in the property after all. beadm filters by source "local" or 
> "received" and for "snapshots_changed" the source is "local" when it 
> should be "-" like other readonly properties. We'll get this fixed ASAP.
>
> -Ryan
>

Now fixed as of 
https://github.com/openzfs/zfs/commit/518b4876022eee58b14903da09b99c01b8caa754

-Ryan


>>
>>>
>>> My version info:
>>>
>>> 14.0-CURRENT FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed 
>>> Aug 17 08:15:27 EDT 2022
>>>
>>> There was not any information in UPDATING about any required ZFS 
>>> configuration changes required nor any ZFS flags that listed 
>>> 'snapshots_changed' as something that needed a new value.  There is 
>>> actually a new snapshot created, but 'beadm list' does not show it 
>>> and the boot menu does not have it listed.
>>>
>>> Tom
>>>
>>
>

From nobody Sun Aug 28 19:34:48 2022
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 4MG3gN4lTXz4bDDS
	for ; Sun, 28 Aug 2022 19:34:56 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MG3gM6G1yz3bHC;
	Sun, 28 Aug 2022 19:34:55 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:Cc:To:From:Date:MIME-Version:Sender:Reply-To:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=cgsaEielD/0sHw1YCRkvbEU6wjNDh3yK5HhG2aBzgHM=; b=lubwKrvKkFRau11ovxlSyFVIPO
	aIVZrxOJAnWFkitKnZJ2JuK6qYq5AZqZnSN9kY1FvjEw9mvOG2IA8lKyIroorP0NFAbn+kp0fFQs0
	DAIGOOpaz2TG0f0ku0gpTdqlII/Wm9wQoJT/ZCKWRPlmo16lvyYXUFr7QRuTDOsh3odYSO4zp0JP/
	R2RW1LMr1PtbQMPfVUfiMfEnFAmRyJ18AbJLrO+1AJjJVflzpgd5hpm2xnnEvymxH5HJNe990iB8V
	l9GGAUVpwTH7rPZsAyu4nrF5rWGCH+hdnM+WCcR34FHlIyLbw7pFI2EhyHE80aur7gK5TVDgYRyZ/
	twG6K+fw==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:38216 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oSO3U-000PRL-FI;
	Sun, 28 Aug 2022 14:34:48 -0500
Received: from 2600:1700:210:b18f:a9c6:cb29:6732:c21b
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sun, 28 Aug 2022 14:34:48 -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
Date: Sun, 28 Aug 2022 14:34:48 -0500
From: Larry Rosenman 
To: Ryan Moeller 
Cc: freebsd-current@freebsd.org
Subject: Re: Beadm can't create snapshot
In-Reply-To: 
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
 
 
Message-ID: <097ab4e937a428f772480b0e2de42ab7@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4MG3gM6G1yz3bHC
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=lubwKrvK;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:55103, ipnet:2602:fcdb::/36, country:US];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[ler];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 08/28/2022 2:28 pm, Ryan Moeller wrote:
> On 8/17/22 12:16 PM, Ryan Moeller wrote:
>> 
>> On 8/17/22 12:05 PM, Ryan Moeller wrote:
>>> 
>>> On 8/17/22 10:35 AM, Thomas Laus wrote:
>>>> I attempted to create a ZFS snapshot after upgrading this morning 
>>>> and received this error
>>>> 
>>>> # beadm create n257443
>>>> cannot create 'zroot/ROOT/n257443': 'snapshots_changed' is readonly
>>>> #
>>> 
>>> 
>>> This looks like a bug in beadm. It must be trying to set the 
>>> snapshots_changed property when cloning the snapshot for the BE, but 
>>> the property is of course readonly.
>>> 
>>> -Ryan
>>> 
>> 
>> I took a closer look at what beadm is doing and this appears to be a 
>> bug in the property after all. beadm filters by source "local" or 
>> "received" and for "snapshots_changed" the source is "local" when it 
>> should be "-" like other readonly properties. We'll get this fixed 
>> ASAP.
>> 
>> -Ryan
>> 
> 
> Now fixed as of
> https://github.com/openzfs/zfs/commit/518b4876022eee58b14903da09b99c01b8caa754
> 

That doesn't look right?  It's about arc_c_max, and not properties?
> -Ryan
> 
> 
>>> 
>>>> 
>>>> My version info:
>>>> 
>>>> 14.0-CURRENT FreeBSD 14.0-CURRENT #9 main-n257443-f7413197245: Wed 
>>>> Aug 17 08:15:27 EDT 2022
>>>> 
>>>> There was not any information in UPDATING about any required ZFS 
>>>> configuration changes required nor any ZFS flags that listed 
>>>> 'snapshots_changed' as something that needed a new value.  There is 
>>>> actually a new snapshot created, but 'beadm list' does not show it 
>>>> and the boot menu does not have it listed.
>>>> 
>>>> Tom
>>>> 
>>> 
>> 

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Sun Aug 28 19:37:22 2022
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 4MG3kB6fs5z4bDM1
	for ; Sun, 28 Aug 2022 19:37:22 +0000 (UTC)
	(envelope-from freqlabs@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MG3kB64wLz3c7d
	for ; Sun, 28 Aug 2022 19:37:22 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661715442;
	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=8ON4008WNUUof7YDvp4V519vf5I90PM5Lmebmlc04qs=;
	b=rUkwhTKJgnocB0djHOBr5X/GG6FmsZYJV+ci9dz37mcz+M3zWvSDTbXSfLJHz+PNu+y2j8
	X6LwwByeOKO/HqFL618WX4akD/Fjptrq9DixTu8xYfuNxCkptue0Tu68gw0Og1SVim1Xm0
	zUuRMG2BxYE6OX4v+nTAHcaNhZvcHF6n1UhIDJCgvujY0eLpuGRDVBY6mkN2oTaLxwW5+u
	xcnPXjE4OEQ0kTW3dKfi18co7z3lV54U7jCN9YTih20biTinu0zJ7NNCLDeSj6OH8DruvY
	2g9Bi/HmmXGZtDWx51/KyIX43hGJ1FrofGrDnmJchg9sqMrVeMVSvHKyDEuhqw==
Received: from [IPV6:2600:1700:358a:c660:c85c:eb28:4f32:5c18] (unknown [IPv6:2600:1700:358a:c660:c85c:eb28:4f32:5c18])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: freqlabs/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MG3kB4NYKz1Dbv
	for ; Sun, 28 Aug 2022 19:37:22 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
Message-ID: 
Date: Sun, 28 Aug 2022 15:37:22 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.13.0
Subject: Re: Beadm can't create snapshot
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org>
 
 
From: Ryan Moeller 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661715442;
	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=8ON4008WNUUof7YDvp4V519vf5I90PM5Lmebmlc04qs=;
	b=Vc6c2RLOC6SvnpPBjjJP8wPzQpOgvOvWJA/zUxh8nmG95l+yD7j5b2yaOQ4gwRGGd5191n
	pZbcDGbpkeY4PrG+wBnrTUSL1bw4ASjazN97SXVRER/XnSvxggCsIUo8HIj2dAcm0mWKjh
	gPprPqC02y3f2yQ+oigpmkhMMBxyeUKNOCuyYrwbZirptrkwNl6gahxElIOJqRIvi+9w/J
	rYxWap8QFXi/OlX+8cbStDthfN6b4Z/OjzKdiMoN7CS8Dnxn+HLPPyb1EHF3wEVUS2wmPE
	eItpmMmH+22Vdwx3+pIUrBBsc62LSNJPdzrjmVdmxr8wwytGppcJkameAdPSaw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661715442; a=rsa-sha256; cv=none;
	b=Du9Dopbb9S52CJl9g/h0IcBTCBhmX6p6NEmU2pGHACCiVwqygdmkLykob6S9fogZkEdZdq
	KqqHxOiWcFT5ghj4tfhF1kKj5IvTqaUzCdP/UrAQ/z7dqLk6/H44Lcqo4NoAI8zi9KffPm
	rw81qgoAl3FMjIEuCtiaviTKlSvXyr2BWHGBUvkSDyw1R9UTiAam2IJxLtwVcc99FCNC3Y
	+V3QWipSkRj56sat76g7qLohnbHKxp+9jYFDdR9F15gB4sdO9AruF614htsiRBtelLzcNB
	4Hwkcbu0h243mmYm1bEl80OZ+5wS8fpeUOckbNz6r6Jce0mZlGCbhrul3ACJmg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


> Now fixed as of 
> https://github.com/openzfs/zfs/commit/518b4876022eee58b14903da09b99c01b8caa754
>
> -Ryan
>

Whoops, here's the correct link 
https://cgit.freebsd.org/src/commit/?id=08aba0aec7b7f676ccc3f7886f59f277d668d5b4 



From nobody Sun Aug 28 23:35:33 2022
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 4MG90C5HSSz4ZgCC
	for ; Sun, 28 Aug 2022 23:34:51 +0000 (UTC)
	(envelope-from kevans@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MG90C4rBVz4485;
	Sun, 28 Aug 2022 23:34:51 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661729691;
	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=mO35fhdiQOHruCbcYhfNNVHH4WKSA+TlAZ7vlHjheQc=;
	b=e0gAwlPQMSEKE0udMM9NwDOpeIzCoc8zOvtB+St8EHpM6OotpPjuazaYjhOKvoGfdfTkba
	47W5VlKJcO4A8cykSGnRC62zfz0aPgzkNYnr0SqkSjjI1z0Tl7Jh2JpAZMD+B7DO93+mKS
	bYtwmeJqrh7LVwLLJr7LHc8XBsLY/6cjUck24sWRbpwivI6mZiK0v8FZCOPnupGxi5GNVq
	swW6Hr3ZLxVEjYiL68TDWsFszWw8s8lPDvu/nmtI0z5rhm7/Jlqw3hqvCxRfCC7HTMpLEl
	U0I9Zk80XAQfJZNRma/JsFneexRd0JaguMZWoZnpnREBpxaQtw7Q11xa1z1QzQ==
Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: kevans)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MG90C3sZzz1Fbs;
	Sun, 28 Aug 2022 23:34:51 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
Received: by mail-qt1-f172.google.com with SMTP id cr9so5053861qtb.13;
        Sun, 28 Aug 2022 16:34:51 -0700 (PDT)
X-Gm-Message-State: ACgBeo0a+BhUjVOu3mYAtbg05iYbwJEDPmfhkouURgV7D3/LiahpbytQ
	3fdW2/keFBqH26htH/8yX/eiVqJ0llkdHlOPDEE=
X-Google-Smtp-Source: AA6agR58NyBY9E9vGDv2zmiAgln/+AdsEBsjyEaq8D3964FykSHCcBSNSIsIUg9ycCaojlyCBByB8uLu0jiVVeEbRj8=
X-Received: by 2002:ac8:5f0e:0:b0:344:8737:7c02 with SMTP id
 x14-20020ac85f0e000000b0034487377c02mr8266537qta.312.1661729690819; Sun, 28
 Aug 2022 16:34:50 -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: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <2818f3da-3ae2-e6e3-9282-8b62263fb5f3@FreeBSD.org> 
  <623263165.219.1661170200563@localhost>
 
 <2078216761.314.1661260774009@localhost> 
In-Reply-To: 
From: Kyle Evans 
Date: Sun, 28 Aug 2022 16:35:33 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Beadm can't create snapshot
To: Peter Jeremy 
Cc: Ronald Klop , freebsd-current@freebsd.org, 
	Ryan Moeller , "Patrick M. Hausen" , 
	Allan Jude 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661729691;
	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=mO35fhdiQOHruCbcYhfNNVHH4WKSA+TlAZ7vlHjheQc=;
	b=He/fms2j41CjmHtVJhxFifpllu4og+XOd7V+Q4NmpDtD7AKhWDHLm6mFuu6Dj5K1hyxnIk
	hl/sej+tpEc+K9K6jL/fSf3iARqS6hSUC9GUwvLPgQQ+sxAIQYnhxxU0/3gFQiZWk1bgFP
	6ABCcsQJyVeI71mo0SimXhA1atv7avWvI+3RasUdTR+U0AmKXGGN+jw2an1Lm769sN1cnG
	JcKjzlrLnA14SpN8au47AQocHAIH5NsT1ZZtoYecTQD4dVJCm56v5UHiH5mYyjHwsxPBpU
	jBPbXaaDf1qnhqKJBXFKqlo9QTnQp5c/RIdS7Fw9wAeDjGHN4mG4tjEPXeAPxw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661729691; a=rsa-sha256; cv=none;
	b=VYfvCpkKh7vaiCCoBNelFk58g4laBXMBLmwR8Ej5kW/I+25KA2Jpp0iIMRtoxQoo8ciR+I
	FdEXie6MfxGDV8DCLbaUoCnMAO86R3JM8Go+19C9816VgOIh/yE+edRiXMDsdJmUUTPFrP
	2+axaHZwreI7mUmfckxMma//xwwbG5P/V/T5Gp/8vCGmyfOS7Ddb4tKHbOuRmEENksI3EO
	zqkecKXo8hz47zHwLEMqIVAaupFr1bXv9aTRv8CWUCExralfwwM8E/Vez3ftB50RpAEL5T
	LpgkBzHcKSLuwDeFh4Wi6oGbq/gcvEnP+CHOc2EWuTZTX2LElsJKlqiN9CwbmQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Aug 23, 2022 at 2:44 PM Peter Jeremy  wrote:
>
> On 2022-Aug-23 15:19:34 +0200, Ronald Klop  wrote:
> >Van: Kyle Evans 
> >> I was not aware that beadm touches loader.conf, but I find that
> >> slightly horrifying. I won't personally make bectl do that, but I
> >> guess I could at least document that it doesn't...
> >
> >Today I looked up something for boot environments myself and read this: =
https://wiki.freebsd.org/BootEnvironments#Setting_Boot_Dataset
> >
> >"In order for boot environments to be effective, you must let the bootfs=
 zpool property control which dataset gets mounted as the root. Particularl=
y, /etc/fstab must be purged of any / mount, and /boot/loader.conf must not=
 be setting vfs.root.mountfrom directly. "
> >
> >So it is documented somewhere at least.
>
> Looking at the wiki history, Kyle wrote that in January 2020.  I
> wonder if he recalls where that requirement came from.
>
> I've gone rummaging through the mailing list history and other wiki
> pages.  It seems that vfs.root.mountfrom used to be required - e.g.
>  https://lists.freebsd.org/pipermail/freebsd-fs/2011-September/012482.htm=
l
>  https://lists.freebsd.org/pipermail/svn-src-head/2011-October/030641.htm=
l
> and people wanted to change that - e.g.
>  https://lists.freebsd.org/pipermail/freebsd-current/2009-October/012933.=
html
>  https://lists.freebsd.org/pipermail/freebsd-fs/2010-March/008010.html
> resulting in it becoming optional in May 2012:
>  https://lists.freebsd.org/pipermail/svn-src-head/2012-May/036902.html
>
> Based on the quoted wiki entry, it seems that sometime between May
> 2012 and January 2020, vfs.root.mountfrom went from "must be set" to
> "must not be set" and I can't find anywhere where that is publicised.
> This is a serious problem because we now have the situation where
> some documentation still says to set vfs.root.mountfrom - e.g.
>  https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror step 2.6
> and people are still using it without being warned that it shouldn't
> be used - e.g. the thread starting
>  https://lists.freebsd.org/pipermail/freebsd-fs/2020-July/028351.html
>

Allan knows the history here a lot better, but you should basically be
looking for where loader started using the 'bootfs' pool property
properly. That is the flag day for when vfs.root.mountfrom really
shouldn't be set, because loader will derive it correctly from bootfs
(via the selector in the menu, if needed).

> I've had a look at the beadm source and it preserves/updates
> vfs.root.mountfrom if it's present in loader.conf but doesn't add it
> if it's not present.
>

Right, basically they're working around some bad image vendors that
still did the wrong thing even as of recent versions. e.g.,
DigitalOcean never fixed their image to stop setting
vfs.root.mountfrom and it drove me absolutely crazy. It's also
necessary for bootpool setups, but bootpool setups should be
vanishingly rare to the point that the remaining folks with bootpool
setups should know what they need to do and probably don't need this.
What beadm does is also technically wrong, and I'll complain about
that in a minute, too.

> IMO, if bectl isn't going to update loader.conf, it needs to warn and
> fail if loader.conf contains a vfs.root.mountfrom that points to a
> BE that's different to bootfs.  (And ideally, a similar check of
> /etc/fstab, though beadm doesn't touch that).
>

Honestly, I'm really not a fan of this idea for a couple of different
reasons, but I wouldn't mind updating `bectl check` (probably with an
optional `-v` flag) to check for this kind of stuff and warn when it
finds something. My main complaint is that if I'm the one writing this
patch, I don't want to just check /boot/loader.conf; I want to process
it exactly like loader would to reduce false negatives. Perhaps you
use /boot/loader.conf, but someone else used /boot/loader.conf.local
-- the correct sanity check recursively processes loader_conf_files
rooted at /boot/defaults/loader.conf.

That brings me back to what beadm does, which bothers me a little bit
and I'll probably prod vermaden about it. Rewriting any
vfs.root.mountfrom line to the new BE is ~ok, but it completely
disregards the contents of the variable. vfs.root.mountfrom can be
used for more than just this limited BE selection, so it should really
tighten down the scope of which ones it rewrites to values beginning
with "zfs:" at the very least.

From nobody Mon Aug 29 06:24:47 2022
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 4MGL5z3Hpzz4bPb1;
	Mon, 29 Aug 2022 06:25:27 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MGL5x4l2bz3XR9;
	Mon, 29 Aug 2022 06:25:25 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by smtp5.goneo.de (Postfix) with ESMTPS id EDFD910A1E8B;
	Mon, 29 Aug 2022 08:25:17 +0200 (CEST)
Received: from hub1.goneo.de (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by hub1.goneo.de (Postfix) with ESMTPS id E15BA10A1E98;
	Mon, 29 Aug 2022 08:25:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
	s=DKIM001; t=1661754315;
	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=dYhJL1zs8hPl53/PvgZQ9OP1VkmLXaKRiuRdxz4ZT+s=;
	b=XMLc5MoPkayMHP8YEfPpU5gcWr6KeII/AmKzO8FMEmwQE6DePVgp9KTWPa7UXU3FT7q+CV
	V9bIyTvTgHT6Zejg6itUzIbggY9baCuYuiGGABYAkbiiLHA+F8Ydk/pvEEWNc079D7QiU/
	fHeqZthazr6rE+FysZfLcXNtFEpR9/aOV+stTNObDaT/8LHFcrvPA9LZy8GP8sq5xja9nZ
	UfLcDmUgM1hU9OBI2c2I+Q0ejVVcYO695U/q2kL7sCpPPkCcbczoIUBD+z3yjPiTqw3Eyi
	n5deDTXxvb9VtocLcJ3dH3gzKztZnzaYQjIsrJ3oYUUVX85BTcARt40HIPoxSA==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-089-012-115-185.89.12.pool.telefonica.de [89.12.115.185])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by hub1.goneo.de (Postfix) with ESMTPSA id 7B04C10A1EA5;
	Mon, 29 Aug 2022 08:25:15 +0200 (CEST)
Date: Mon, 29 Aug 2022 08:24:47 +0200
From: FreeBSD User 
To: Cy Schubert 
Cc: Michael Gmelin , freebsd@oldach.net,
 otis@freebsd.org, freebsd-current@freebsd.org, freebsd-ports@freebsd.org,
 yasu@freebsd.org
Subject: Re: security/clamav: /var/run on TMPFS renders the port broken by 
 design
Message-ID: <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de>
In-Reply-To: <20220828131120.C3781317@slippy.cwsent.com>
References: <202208280842.27S8gDXn055868@nuc.oldach.net>
	<163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>
	<20220828102124.409EC26D@slippy.cwsent.com>
	<20220828130107.1a76d54a.grembo@freebsd.org>
	<20220828131120.C3781317@slippy.cwsent.com>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-UID: faa7e9
X-Rspamd-UID: 0497e6
X-Rspamd-Queue-Id: 4MGL5x4l2bz3XR9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=XMLc5MoP;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.60) smtp.mailfrom=freebsd@walstatt-de.de
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_SEVEN(0.00)[7];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[walstatt-de.de:+];
	RCVD_COUNT_THREE(0.00)[4];
	ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	DMARC_NA(0.00)[walstatt-de.de];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Am Sun, 28 Aug 2022 06:11:20 -0700
Cy Schubert  schrieb:

> In message <20220828130107.1a76d54a.grembo@freebsd.org>, Michael Gmelin 
> writes:
> > 
> >
> >
> > On Sun, 28 Aug 2022 03:21:24 -0700
> > Cy Schubert  wrote:
> >  
> > > In message <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>,
> > > Michael Gmelin w
> > > rites:  
> > > > 
> > > >
> > > >    
> > > > > On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote:
> > > > >=20
> > > > > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200
> > > > > (CEST):    
> > > > >> As stated before in this thread, replacing /var/run with tmpfs
> > > > >> is not a supported configuration.    
> > > > >=20
> > > > > Not supported? What is the purpose of /etc/rc.d/var then? That
> > > > > creates a t=    
> > > > mpfs backed /var, populates it through mtree, and makes a proper
> > > > /var/run av= ailable.    
> > > > >=20
> > > > > However it doesn't (yet) create /var/run/clamav of course.
> > > > >=20
> > > > > It would be fairly easy to extend /etc/rc.d/var by a logic that
> > > > > walks thro=    
> > > > ugh /usr/local/etc/mtree/* and runs mtree on each of the files
> > > > found as need= ed. All that the security/clamav port would need to
> > > > do then is to drop an ap= propriate small mtree file as
> > > > /usr/local/etc/mtree/clamav. =46rom a port's p= erspective that is
> > > > the same logic as dropping service scripts as /usr/local/=
> > > > etc/rc.d/clamav-*.
> > > >
> > > > =46rom a user's perspective, it would be preferable to have this
> > > > happen at s= ervice start though, as (unlike in the setup
> > > > described) reboots don't happen= that frequently, but files in
> > > > /var/run might get deleted manually. Maybe so= me rc framework
> > > > based solution would make sense, e.g., a variable `mtree_fil= es`,
> > > > which, if set, is applied in the default start_precmd. Besides
> > > > being mo= re resilient, this would also have the advantage that all
> > > > required file syst= ems should be available at that point and the
> > > > separation between system and p = orts would be more clear. Another
> > > > advantage would be that directories are on= ly created for services
> > > > that are actually enabled/started.    
> > > 
> > > Unfortunately this requires all ports to include an mtree file.
> > > Relying on port maintainers who are human to ensure that these files
> > > are created and updated when ports are created and maintained will
> > > result in more human error. I've learned over my long career to rely
> > > more on automation than human beings. Automation [should] never fail
> > > and when it does it does temporarily until the bug is found and
> > > fixed. Human beings inconsistently fail.
> > > 
> > > If it were an auto-discovery script that created an mtree file as
> > > part of the packaging process, it would be another matter. But this
> > > optional solution path should be discussed on ports@, not here.
> > > 
> > >   
> >
> > I don't have much skin in the game, but I created a little proof of
> > concept to allow further discussion (which is not ports-specific, as it
> > works for all service scripts):
> >
> > https://reviews.freebsd.org/D36385  
> 
> I've been toying with the idea for a few months but was never bothered to 
> create a review or even a script for that matter.
> 
> >
> > This basically allows both system admins and port maintainers to
> > create mtree files in /usr/local/etc/mtree (or /etc/mtree, as it's
> > always relative to the service script called) which are automatically
> > applied on service start. It's non-intrusive and doesn't require any
> > sweeping changes to existing ports/services.  
> 
> Understood that this is a manual process.
> 
> >
> > In this specific case, the requester could create
> > /usr/local/etc/mtree/clamav-clamd with the required content (or
> > persuade the port maintainer to include that file).
> >
> > You could of course add some construct to the ports framework that
> > picks up certain directories from the package list automatically and
> > places them into an mtree file as part of the build or installation
> > process. But that would be an additional feature on top of this change.  
> 
> Someone could. Personally, I think that's a lot of work compared to simply 
> saving the state of /var/run at shutdown and restoring it at boot. I can't 
> speak for the ports management though.
> 
> >
> > This is meant to inspire more discussions, I'm not trying to force
> > anything in. ;)  
> 
> Agreed.
> 
> I cobbled something up yesterday that saves the directory tree state of 
> /var/run prior to shutdown (or manually) and restores it at boot.
> 
> https://reviews.freebsd.org/D36386
> 
> People can try it out if they want. If there's enough interest I'd be 
> willing to commit it.
> 
> We have a few options on the table and probably more. The ports 
> infrastructure option is probably the most work. Adding functionality to 
> all the ports that use /var/run is also a lot of work and if relying on 
> individual porters, will likely take some time and be varied in 
> implementation and robustness.
> 
> 

I'd like to add a sidenote here, if one may please.

Checking today NanoBSD based projects, i.e. XigmaNAS, which also let /var reside on a memory
disk and the way NanoBSD handles /var, contradicts some claims that is is 'unsupported' to put
/var on a volatile memory infrastructure.

On the other hand, there are only few ports which create subfolders to, i.e., /var/run not
congruent what the specific metree sketch implies, the port security/clamav is one of those
few.

The question that bothers me most and this is just from the pratical point of view as stated
initially and from a second view, just out of curiosity:

what (fatal?) implications does it have to create some folders by port's rc-script in /var/run
or whatever folder is needed to be on a volatile memory device for FreeBSD base system's mtree
infrastructure?

-- 
O. Hartmann

From nobody Mon Aug 29 08:31:28 2022
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 4MGNvc0Sxpz4bbRf;
	Mon, 29 Aug 2022 08:31:40 +0000 (UTC)
	(envelope-from franco@lastsummer.de)
Received: from host64.shmhost.net (host64.shmhost.net [IPv6:2a01:4f8:a0:51d3::107: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 4MGNvb1DMhz3hGB;
	Mon, 29 Aug 2022 08:31:38 +0000 (UTC)
	(envelope-from franco@lastsummer.de)
Received: from smtpclient.apple (p200300cd873ac5fc3984e35a6110a933.dip0.t-ipconnect.de [IPv6:2003:cd:873a:c5fc:3984:e35a:6110:a933])
	by host64.shmhost.net (Postfix) with ESMTPSA id 4MGNvP3m8LzP2Hd;
	Mon, 29 Aug 2022 10:31:29 +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 14.0 \(3654.120.0.1.13\))
Subject: Re: security/clamav: /var/run on TMPFS renders the port broken by 
 design
From: Franco Fichtner 
In-Reply-To: <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de>
Date: Mon, 29 Aug 2022 10:31:28 +0200
Cc: Cy Schubert ,
 Michael Gmelin ,
 freebsd@oldach.net,
 otis@freebsd.org,
 Current FreeBSD ,
 FreeBSD Ports ,
 yasu@freebsd.org,
 "freebsd-pkg@freebsd.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <25A758F5-784E-45EC-8F9A-278E0D3AB8DE@lastsummer.de>
References: <202208280842.27S8gDXn055868@nuc.oldach.net>
 <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>
 <20220828102124.409EC26D@slippy.cwsent.com>
 <20220828130107.1a76d54a.grembo@freebsd.org>
 <20220828131120.C3781317@slippy.cwsent.com>
 <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de>
To: FreeBSD User 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Virus-Scanned: clamav-milter 0.103.6 at host64.shmhost.net
X-Virus-Status: Clean
X-Rspamd-Queue-Id: 4MGNvb1DMhz3hGB
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of franco@lastsummer.de has no SPF policy when checking 2a01:4f8:a0:51d3::107:1) smtp.mailfrom=franco@lastsummer.de
X-Spamd-Result: default: False [-1.60 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-pkg@FreeBSD.org,freebsd-ports@freebsd.org];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_SEVEN(0.00)[9];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[lastsummer.de];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> On 29. Aug 2022, at 8:24 AM, FreeBSD User  =
wrote:
>=20
> Checking today NanoBSD based projects, i.e. XigmaNAS, which also let =
/var reside on a memory
> disk and the way NanoBSD handles /var, contradicts some claims that is =
is 'unsupported' to put
> /var on a volatile memory infrastructure.

I fully agree with the situation that at least NanoBSD has always been a =
valid
use case for this and don't see the need to "recycle" contents in =
/var/run and
let alone assume software that state inside /var/run is not volatile.

Milage varies for other /var related subdirectories of course, but =
people using
a /var MFS type setup have managed the situation for many years anyway =
with all
of its ups and downs.

The situation is a bit sloppy on the ClamAV end and has been for a =
couple of
releases assuming this and that and failing on tmpfs nodes, not =
bootstrapping
required things in the first place, but let's just assume that is the =
case for
other software as well now or in the future.

> what (fatal?) implications does it have to create some folders by =
port's rc-script in /var/run
> or whatever folder is needed to be on a volatile memory device for =
FreeBSD base system's mtree
> infrastructure?

So the obvious "separation of concerns" solution isn't something that =
was being
discussed here seeing that this is a ports/packages related issue:

The fix in all cases is to upgrade/reinstall the package in question, so
the knowledge of these required directories is buried inside the =
+POST_INSTALL
script but you cannot easily re-run these scripts since there is no =
command
option for it.  Obviously this beats having a copy of the package lying =
around
just to reinstall it on a reboot...

In the past you were able to extract them from "pkg info --raw =
$packagename",
and run them in the shell but that workaround is no longer feasible for =
LUA
scripting was added since pkg uses internal definitions in the ports =
tree
provided scripts.

Whether or not someone will have to script something to rerun the =
+POST_INSTALL
on reboot shouldn't stop from adding a pkg script run option to enable =
the former.

Solutions not involving the actual ports scripts seem to be =
over-engineering
when trying to record "unknown state" for a "reproducible outcome".  ;)


Cheers,
Franco=

From nobody Mon Aug 29 09:12:44 2022
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 4MGPqQ2FtQz4Zggr;
	Mon, 29 Aug 2022 09:13:06 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MGPqM756mz3nRB;
	Mon, 29 Aug 2022 09:13:03 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 27T9Cimb002833;
	Mon, 29 Aug 2022 18:12:44 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Mon, 29 Aug 2022 18:12:44 +0900
From: Tomoaki AOKI 
To: Franco Fichtner 
Cc: FreeBSD User ,
        Cy Schubert
 ,
        Michael Gmelin , freebsd@oldach.net,
        otis@freebsd.org, Current FreeBSD
 ,
        FreeBSD Ports , yasu@freebsd.org,
        "freebsd-pkg@freebsd.org" 
Subject: Re: security/clamav: /var/run on TMPFS renders the port broken by 
 design
Message-Id: <20220829181244.f0354f2433e668f467ff6391@dec.sakura.ne.jp>
In-Reply-To: <25A758F5-784E-45EC-8F9A-278E0D3AB8DE@lastsummer.de>
References: <202208280842.27S8gDXn055868@nuc.oldach.net>
	<163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>
	<20220828102124.409EC26D@slippy.cwsent.com>
	<20220828130107.1a76d54a.grembo@freebsd.org>
	<20220828131120.C3781317@slippy.cwsent.com>
	<20220829082514.63926a46@thor.intern.walstatt.dynvpn.de>
	<25A758F5-784E-45EC-8F9A-278E0D3AB8DE@lastsummer.de>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MGPqM756mz3nRB
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-pkg@FreeBSD.org,freebsd-ports@freebsd.org,freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	RCPT_COUNT_SEVEN(0.00)[10];
	R_DKIM_NA(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[sakura.ne.jp];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 29 Aug 2022 10:31:28 +0200
Franco Fichtner  wrote:

> Hi,
> 
> > On 29. Aug 2022, at 8:24 AM, FreeBSD User  wrote:
> > 
> > Checking today NanoBSD based projects, i.e. XigmaNAS, which also let /var reside on a memory
> > disk and the way NanoBSD handles /var, contradicts some claims that is is 'unsupported' to put
> > /var on a volatile memory infrastructure.
> 
> I fully agree with the situation that at least NanoBSD has always been a valid
> use case for this and don't see the need to "recycle" contents in /var/run and
> let alone assume software that state inside /var/run is not volatile.
> 
> Milage varies for other /var related subdirectories of course, but people using
> a /var MFS type setup have managed the situation for many years anyway with all
> of its ups and downs.
> 
> The situation is a bit sloppy on the ClamAV end and has been for a couple of
> releases assuming this and that and failing on tmpfs nodes, not bootstrapping
> required things in the first place, but let's just assume that is the case for
> other software as well now or in the future.

Uncertain about current default, but at least, at some point,
varmfs="AUTO" on /etc/defaults/rc.conf forcibly create and mount
mfs on /var, overriding existing contents, unless varmfs="NO"
exists on /etc/rc.conf[.local].

If the behaviour is unchanged until now, no port SHALL assume
non-volatile /var, and use usually-non-volatile {LOCALBASE}/var instead.
At least, security/rkhunter uses there.

For use-case writes to non-volatile fs is prohibited and volatile
fs'es are mandated to be cleared daily, the admin should create
script(s) to

 1. stop all jobs writing to (allowed) volatile fs,
 2. clear volatile fs'es,
 3. then restart stopped jobs

on {LOCALBASE}/etc/periodic/daily.


> > what (fatal?) implications does it have to create some folders by port's rc-script in /var/run
> > or whatever folder is needed to be on a volatile memory device for FreeBSD base system's mtree
> > infrastructure?
> 
> So the obvious "separation of concerns" solution isn't something that was being
> discussed here seeing that this is a ports/packages related issue:
> 
> The fix in all cases is to upgrade/reinstall the package in question, so
> the knowledge of these required directories is buried inside the +POST_INSTALL
> script but you cannot easily re-run these scripts since there is no command
> option for it.  Obviously this beats having a copy of the package lying around
> just to reinstall it on a reboot...
> 
> In the past you were able to extract them from "pkg info --raw $packagename",
> and run them in the shell but that workaround is no longer feasible for LUA
> scripting was added since pkg uses internal definitions in the ports tree
> provided scripts.
> 
> Whether or not someone will have to script something to rerun the +POST_INSTALL
> on reboot shouldn't stop from adding a pkg script run option to enable the former.
> 
> Solutions not involving the actual ports scripts seem to be over-engineering
> when trying to record "unknown state" for a "reproducible outcome".  ;)
> 
> 
> Cheers,
> Franco
> 


-- 
Tomoaki AOKI    

From nobody Mon Aug 29 14:14:58 2022
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 4MGXWm0B1Cz4bDQ4
	for ; Mon, 29 Aug 2022 14:15:00 +0000 (UTC)
	(envelope-from 01000182e9f49b75-35f2fff9-c6f9-4b37-8e4c-263309620d31-000000@amazonses.com)
Received: from a8-24.smtp-out.amazonses.com (a8-24.smtp-out.amazonses.com [54.240.8.24])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MGXWl2VHDz4HvZ
	for ; Mon, 29 Aug 2022 14:14:59 +0000 (UTC)
	(envelope-from 01000182e9f49b75-35f2fff9-c6f9-4b37-8e4c-263309620d31-000000@amazonses.com)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1661782498;
	h=Message-ID:Date:MIME-Version:Subject:From:To:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID;
	bh=Yexi13YvMa4/dPMETa8UCp3i6jz8B+8BxG1fEpyv5yg=;
	b=cjvb8ltqpHUUrOL54dvH/53Bn0iVGbcKjPCcjpN3FGAYNj1+8TnLVYqChyFf5G+x
	T7QMITuBong8CHk5W5WM1cfjz3eSSMx2b5bt9CuYdMbj4sCpp2O+MaBd16xvm4vzzPs
	EzXjsKSL5AvN+82LFDcZNOntLQe/VO9cOky80TIk=
Message-ID: <01000182e9f49b75-35f2fff9-c6f9-4b37-8e4c-263309620d31-000000@email.amazonses.com>
Date: Mon, 29 Aug 2022 14:14:58 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: Beadm can't create snapshot
Content-Language: en-US
From: Thomas Laus 
To: Current FreeBSD 
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
In-Reply-To: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES
X-SES-Outgoing: 2022.08.29-54.240.8.24
X-Rspamd-Queue-Id: 4MGXWl2VHDz4HvZ
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=cjvb8ltq;
	dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=acm.org (policy=none);
	spf=pass (mx1.freebsd.org: domain of 01000182e9f49b75-35f2fff9-c6f9-4b37-8e4c-263309620d31-000000@amazonses.com designates 54.240.8.24 as permitted sender) smtp.mailfrom=01000182e9f49b75-35f2fff9-c6f9-4b37-8e4c-263309620d31-000000@amazonses.com
X-Spamd-Result: default: False [-0.60 / 15.00];
	FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	FORGED_SENDER(0.30)[lausts@acm.org,01000182e9f49b75-35f2fff9-c6f9-4b37-8e4c-263309620d31-000000@amazonses.com];
	R_DKIM_ALLOW(-0.20)[amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw];
	R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18];
	DMARC_POLICY_SOFTFAIL(0.10)[acm.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none];
	MIME_GOOD(-0.10)[text/plain];
	RWL_MAILSPIKE_POSSIBLE(0.00)[54.240.8.24:from];
	FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,01000182e9f49b75-35f2fff9-c6f9-4b37-8e4c-263309620d31-000000@amazonses.com];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:14618, ipnet:54.240.8.0/21, country:US];
	RCVD_COUNT_ZERO(0.00)[0];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[amazonses.com:+];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[54.240.8.24:from];
	DWL_DNSWL_NONE(0.00)[amazonses.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 8/17/22 10:35, Thomas Laus wrote:
> I attempted to create a ZFS snapshot after upgrading this morning and 
> received this error
>
After all of the discussion to compare and contrast beadm vs. bectl my 
read only bit is still set as of this morning 29-AUG-2022.

# beadm create n257658
cannot create 'zroot/ROOT/n257658': 'snapshots_changed' is readonly
#

I thought that this 'feature' was fixed a while ago.

Tom


-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

From nobody Mon Aug 29 15:28:42 2022
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 4MGZ8q75VPz4bLgV
	for ; Mon, 29 Aug 2022 15:28:43 +0000 (UTC)
	(envelope-from freqlabs@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MGZ8q6c2Xz4Nmf
	for ; Mon, 29 Aug 2022 15:28:43 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661786923;
	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=+2X9i8Evk3YYVHH+g/PRrzTnYl9w48DVGdbcZDAKiTQ=;
	b=X5xIwuBhYhSZsPOtkp11I3kbG/zbrRfzFDKn+z8DNKhXbkPeUkKR9uzYLtx4wCLocG34y8
	nUgDcLUINMei4JKvnVW5a8LMjF0hWYIVX8pzHPTwszzrLxNbT3CfJM8aKrjmks32sm5tXG
	R1YoAh2dnNduo64czbTJKMjDViRESPmfgJseDyANpyClUpop3V9EKRlNkymlfR97W2cr2f
	OPvOT9W9WJcnCHSFDyrTM9fh3xo9R3pB/9m7dX529HVRt86mfO1v4G/YSpOp4M4yaQV2CU
	Jz9kdd3AQFLExBB+rHb7dEpvGc6CdnvwFONdgASLvaWhDtJaz+OmiZOj+OF6ZQ==
Received: from [IPV6:2600:1700:358a:c660:74e4:e806:136e:5e3f] (unknown [IPv6:2600:1700:358a:c660:74e4:e806:136e:5e3f])
	(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: freqlabs/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MGZ8q549kz1JKY
	for ; Mon, 29 Aug 2022 15:28:43 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
Message-ID: 
Date: Mon, 29 Aug 2022 11:28:42 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.13.0
Subject: Re: Beadm can't create snapshot
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <01000182e9f49b75-35f2fff9-c6f9-4b37-8e4c-263309620d31-000000@email.amazonses.com>
From: Ryan Moeller 
In-Reply-To: <01000182e9f49b75-35f2fff9-c6f9-4b37-8e4c-263309620d31-000000@email.amazonses.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661786923;
	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=+2X9i8Evk3YYVHH+g/PRrzTnYl9w48DVGdbcZDAKiTQ=;
	b=uUB7U9NOIuSYUF/WNxt2LV/pcZt947XkjoZrI+orPPKBlKRTcdpS1roRQ2DUIyarO338xM
	k5KKz/TxkzeKm4//xjIwTaRPfQv1NQcKgBGfizf1pioyHBvm/39qKCQ0aYsZ0xHpb0xybQ
	8NxmsbiUGK2RJqLGybOUczuxV/9xzaVtmHBpZ4bBPj91UBJ9FGh3U1PQkGNeOlivz0SeDx
	NyKalSbN4+dXVGQNN+XpdXV5Y2wssb8FsvYsEG5fzbQU9ju7/HJbY+t51h00B0rvPU9ntd
	3zGmX1oqAVpzM5ZQsFb9J7y3hi61RAw1MQUC1vtb9dblijMxbLcphFfuphb/2A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661786923; a=rsa-sha256; cv=none;
	b=NBc6Yxbfl3tA96A5D0D/SDh2UhJKFioLfjdwZW2MTtH0cbzbRNPH507r6jAQcC2NMF8d9t
	4QeKbyGIU6PNfvoT6aaaFQN2RY/hgYdmG9pDEebUwVpVulRV/t6BMygPQv7DitOL2ew3hA
	3NYmqGmlaU9yhhHKhA2a4cKe1JtFcgU18ihyCsM1spT4dlrPtPkcd8L7JMnlm7eFv64fZw
	+9K45n7UMpZiy1q045t9UrWjM3WJUc735FLq4xamsMpuiPkNppiI9UXljM+i/SWIFqsfa1
	8T2m9Of2mWPvbXvy4ZlLKV1TweAyof1K1inYFZLpLqd/aYkenC5j2ylZqwzSQw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


On 8/29/22 10:14 AM, Thomas Laus wrote:
> On 8/17/22 10:35, Thomas Laus wrote:
>> I attempted to create a ZFS snapshot after upgrading this morning and 
>> received this error
>>
> After all of the discussion to compare and contrast beadm vs. bectl my 
> read only bit is still set as of this morning 29-AUG-2022.
>
> # beadm create n257658
> cannot create 'zroot/ROOT/n257658': 'snapshots_changed' is readonly
> #
>
> I thought that this 'feature' was fixed a while ago.
>
> Tom
>

It's fixed but it's not going to fix datasets that have been snapshotted 
with the bug. The bug was that the property was stored in a ZAP that ZFS 
assumes contains only local properties. The fix is to store the property 
in a different ZAP, but if you already have it in the wrong ZAP it 
overrides the one stored in the correct place. I'm going to do some 
testing today and throw together a temporary patch that will remove it.

-Ryan


From nobody Mon Aug 29 15:29:44 2022
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 4MGZB24S8Bz4bLd0
	for ; Mon, 29 Aug 2022 15:29:46 +0000 (UTC)
	(envelope-from garga@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MGZB23zV6z4PrG
	for ; Mon, 29 Aug 2022 15:29:46 +0000 (UTC)
	(envelope-from garga@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661786986;
	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=i4h53+32t4xxqQd2LqTqlcUhtFDK7mtVLmI4twnRWWk=;
	b=of8fZo3NCDaVdLK1RvdvaEHpXaKuQEGRW/mt6jyv2ZEG32T9G2AN7ZI+RHC7W/idKGb6Vk
	JQq9T2NVpuJ2QASxKz94kOM4WZO/29GrTs/yHhw7wYj5WAVczJYvwIGLkEyoBpPEFuovYo
	Hk8qLJ5J153BIb6DM1Zoi/R0p4jqp8RQDYoJ028vVCI8oWN5SETL0pgIJ7IJhpr+HPY73G
	fWiHEWWV0sDYOGg7kAu3ALqQmtIY6/R0bBEPKAys5SmHxlA1oyvEo/tap8yq8n6CLKW62m
	hGJ4UEJ0X7e/oVEdkyBAGaQoVHITY7M8bubtqttBRlc1my1TcLbYv0i9aqTsBg==
Received: from [172.21.4.170] (dynamic-177-53-82-16.telecominternet.net.br [177.53.82.16])
	(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: garga)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MGZB21GdYz1JKZ
	for ; Mon, 29 Aug 2022 15:29:46 +0000 (UTC)
	(envelope-from garga@FreeBSD.org)
Message-ID: <9636d41e-bf21-8130-ff15-e5dcbaaa4fe8@FreeBSD.org>
Date: Mon, 29 Aug 2022 12:29: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/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.0
Content-Language: en-US
To: Current FreeBSD 
From: Renato Botelho 
Subject: archivers/arj fails to build on jail
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661786986;
	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=i4h53+32t4xxqQd2LqTqlcUhtFDK7mtVLmI4twnRWWk=;
	b=lobl6CH1VdBmqsEPGfm5zQIZqhKHokZw+C5iEoEFMOAe0/tDPv4HG0WtZBsAHxpF7FTUCw
	C8wHUnu7nXmVqGKWe3Z2vZ9gBcA6uYWYD2bjzjJjiVB8ddeamOZLdOMPXF23j2RH5GJ6Pk
	LrOAjFZWq4ZpEg0CiQJY0c7O9t2ktW9IPWpjC4dDMVCZwcU+eOwoH6lrQc2rbhLGC0Abo3
	VcU5nHNcNamy5R9XVAfkD4mafXL3JDFjM0HsRjCjqhk6baVsgRyz+AHJxcew23MR8pjEzp
	+E5kbTV7MQdoNfgFKbZuuBTlLZo/hwpm9d/QbqbCwQaU+BCepURfPYdiXnw24g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661786986; a=rsa-sha256; cv=none;
	b=MYBZOGkyWDO5SHBxuM00dGM1oU/UqkoD/zYjP0cooFS7FVTKDmU68ZUhp73Jtg6c/nOtqk
	GtZeWgXkTIjmOCvj9/2az75Huh6WsV4kZ/NuUoJykBlI9oBA3nn3/OTD4rbNBObPvRBI9k
	bssJ0k3V3Sz+V/vTgIelDbHydh1yqXn76mGTrqoyDJysqx3+8J/urw28gA39JXcuLEkZRQ
	GMhyYayHYjFaTpsIENSw7BKEW/KN1H7yj9fq7HCLrQREyuy0gzNv0UPAoB/2PnYW67pQ0L
	qDFaRF9WiglaRoDpxNhistlxzE4Biz5n4oeAGIwI3ngxaj7Y5RiTzH8w0d3wVw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

There is a PR [1] opened for years reporting arj fails to build on a 
jail.  Recently I reproduced it on a system running CURRENT.

I just launched a jail and tried to build it, and got the error as 
described:

gmake[3]: *** [GNUmakefile:258: freebsd12.1/en/rs/msg_crp.h] Abort trap

msgbind binary built inside arj, when called, ends like this.  I has no 
clue about what could be the root cause here.  I also don't understand 
why arj builds fine on poudriere, which uses jail as well.

If anyone has any idea about what could be causing this, please let me know.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235636
-- 
Renato Botelho

From nobody Mon Aug 29 16:57:29 2022
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 4MGc7M1t7Hz4bVTk;
	Mon, 29 Aug 2022 16:57:35 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MGc7L17hPz3L87;
	Mon, 29 Aug 2022 16:57:34 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142])
	by cmsmtp with ESMTP
	id ShazoSetvS8WrSi4roT2Pb; Mon, 29 Aug 2022 16:57:33 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id Si4ooxPkMuJwwSi4poVvSx; Mon, 29 Aug 2022 16:57:33 +0000
X-Authority-Analysis: v=2.4 cv=F+BEy4tN c=1 sm=1 tr=0 ts=630ceffd
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=biHskzXt2R4A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8
 a=gRS1eiuiAAAA:8 a=EkcXrb_YAAAA:8 a=LXEpIe3u_CHbWU6wHioA:9
 a=iOwzQaJqgoF0qnYM:21 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22
 a=IjZwj45LgO3ly-622nXo:22 a=udpbrAo2yJH2O6eCpvBn:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id 0206F26E;
	Mon, 29 Aug 2022 09:57:29 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id C15F4121; Mon, 29 Aug 2022 09:57:29 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: FreeBSD User 
cc: Cy Schubert ,
    Michael Gmelin , freebsd@oldach.net,
    otis@freebsd.org, freebsd-current@freebsd.org,
    freebsd-ports@freebsd.org, yasu@freebsd.org
Subject: Re: security/clamav: /var/run on TMPFS renders the port broken by 
 design
In-reply-to: <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de>
References: <202208280842.27S8gDXn055868@nuc.oldach.net> 
 <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org> 
 <20220828102124.409EC26D@slippy.cwsent.com> <20220828130107.1a76d54a.grembo@freebsd.org> <20220828131120.C3781317@slippy.cwsent.com> <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de>
Comments: In-reply-to FreeBSD User 
   message dated "Mon, 29 Aug 2022 08:24:47 +0200."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 29 Aug 2022 09:57:29 -0700
Message-Id: <20220829165729.C15F4121@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfFUCc9/1umJ6vpMqs2MccId2EURivPbDjOnulmy/JKTN0+VuIwtZOp/EINWwK3dfMCIKp9OXFP1dn1A2kCfBeMZX9QGHYqxbrnu3biIKQTG3lsZF4HAb
 B/PmTEhuzcTPDPnuekJViT4+bJA2JBhDDs9UwIrLWyOtRmLgOVLv88my2phDtY84wWbIptXDdPOM8MzO9neBN4GJ23Zrjoow9pEhgPFzwNn3WwzwjiMoUy1H
 ryTfTbbbbqVdGsfe8BjNT+dhKmjl3Bmzg2Yb8QJhbNFm3wMkeTdMekf+/srCF/OXEfAdDLOT1BrppLHzKFxFLK7dDbGNgO2e7DDsDvIOms3q6joJMYpJ6cfD
 8lyztpqwPE9qGGY0PbZGywx9Jd/i5UumuOK/y+YvLBQx5HpqtoQ=
X-Rspamd-Queue-Id: 4MGc7L17hPz3L87
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[8];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org,freebsd-current@freebsd.org];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	REPLYTO_EQ_FROM(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message <20220829082514.63926a46@thor.intern.walstatt.dynvpn.de>, 
FreeBSD Us
er writes:
> Am Sun, 28 Aug 2022 06:11:20 -0700
> Cy Schubert  schrieb:
>
> > In message <20220828130107.1a76d54a.grembo@freebsd.org>, Michael Gmelin 
> > writes:
> > > 
> > >
> > >
> > > On Sun, 28 Aug 2022 03:21:24 -0700
> > > Cy Schubert  wrote:
> > >  
> > > > In message <163333B4-76A1-4E46-B7C3-60492D379C6E@freebsd.org>,
> > > > Michael Gmelin w
> > > > rites:  
> > > > > 
> > > > >
> > > > >    
> > > > > > On 28. Aug 2022, at 10:42, freebsd@oldach.net wrote:
> > > > > >=20
> > > > > > =EF=BB=BFCy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200
> > > > > > (CEST):    
> > > > > >> As stated before in this thread, replacing /var/run with tmpfs
> > > > > >> is not a supported configuration.    
> > > > > >=20
> > > > > > Not supported? What is the purpose of /etc/rc.d/var then? That
> > > > > > creates a t=    
> > > > > mpfs backed /var, populates it through mtree, and makes a proper
> > > > > /var/run av= ailable.    
> > > > > >=20
> > > > > > However it doesn't (yet) create /var/run/clamav of course.
> > > > > >=20
> > > > > > It would be fairly easy to extend /etc/rc.d/var by a logic that
> > > > > > walks thro=    
> > > > > ugh /usr/local/etc/mtree/* and runs mtree on each of the files
> > > > > found as need= ed. All that the security/clamav port would need to
> > > > > do then is to drop an ap= propriate small mtree file as
> > > > > /usr/local/etc/mtree/clamav. =46rom a port's p= erspective that is
> > > > > the same logic as dropping service scripts as /usr/local/=
> > > > > etc/rc.d/clamav-*.
> > > > >
> > > > > =46rom a user's perspective, it would be preferable to have this
> > > > > happen at s= ervice start though, as (unlike in the setup
> > > > > described) reboots don't happen= that frequently, but files in
> > > > > /var/run might get deleted manually. Maybe so= me rc framework
> > > > > based solution would make sense, e.g., a variable `mtree_fil= es`,
> > > > > which, if set, is applied in the default start_precmd. Besides
> > > > > being mo= re resilient, this would also have the advantage that all
> > > > > required file syst= ems should be available at that point and the
> > > > > separation between system and p = orts would be more clear. Another
> > > > > advantage would be that directories are on= ly created for services
> > > > > that are actually enabled/started.    
> > > > 
> > > > Unfortunately this requires all ports to include an mtree file.
> > > > Relying on port maintainers who are human to ensure that these files
> > > > are created and updated when ports are created and maintained will
> > > > result in more human error. I've learned over my long career to rely
> > > > more on automation than human beings. Automation [should] never fail
> > > > and when it does it does temporarily until the bug is found and
> > > > fixed. Human beings inconsistently fail.
> > > > 
> > > > If it were an auto-discovery script that created an mtree file as
> > > > part of the packaging process, it would be another matter. But this
> > > > optional solution path should be discussed on ports@, not here.
> > > > 
> > > >   
> > >
> > > I don't have much skin in the game, but I created a little proof of
> > > concept to allow further discussion (which is not ports-specific, as it
> > > works for all service scripts):
> > >
> > > https://reviews.freebsd.org/D36385  
> > 
> > I've been toying with the idea for a few months but was never bothered to 
> > create a review or even a script for that matter.
> > 
> > >
> > > This basically allows both system admins and port maintainers to
> > > create mtree files in /usr/local/etc/mtree (or /etc/mtree, as it's
> > > always relative to the service script called) which are automatically
> > > applied on service start. It's non-intrusive and doesn't require any
> > > sweeping changes to existing ports/services.  
> > 
> > Understood that this is a manual process.
> > 
> > >
> > > In this specific case, the requester could create
> > > /usr/local/etc/mtree/clamav-clamd with the required content (or
> > > persuade the port maintainer to include that file).
> > >
> > > You could of course add some construct to the ports framework that
> > > picks up certain directories from the package list automatically and
> > > places them into an mtree file as part of the build or installation
> > > process. But that would be an additional feature on top of this change.  
> > 
> > Someone could. Personally, I think that's a lot of work compared to simply 
> > saving the state of /var/run at shutdown and restoring it at boot. I can't 
> > speak for the ports management though.
> > 
> > >
> > > This is meant to inspire more discussions, I'm not trying to force
> > > anything in. ;)  
> > 
> > Agreed.
> > 
> > I cobbled something up yesterday that saves the directory tree state of 
> > /var/run prior to shutdown (or manually) and restores it at boot.
> > 
> > https://reviews.freebsd.org/D36386
> > 
> > People can try it out if they want. If there's enough interest I'd be 
> > willing to commit it.
> > 
> > We have a few options on the table and probably more. The ports 
> > infrastructure option is probably the most work. Adding functionality to 
> > all the ports that use /var/run is also a lot of work and if relying on 
> > individual porters, will likely take some time and be varied in 
> > implementation and robustness.
> > 
> > 
>
> I'd like to add a sidenote here, if one may please.
>
> Checking today NanoBSD based projects, i.e. XigmaNAS, which also let /var res
> ide on a memory
> disk and the way NanoBSD handles /var, contradicts some claims that is is 'un
> supported' to put
> /var on a volatile memory infrastructure.

There is no argument that /var/run on tmpfs should not be done. IIRC RHEL 
puts /tmp and /var/run on tmpfs. And, when I worked with Solaris and Tru64, 
both put /tmp on tmpfs.

>
> On the other hand, there are only few ports which create subfolders to, i.e.,
>  /var/run not
> congruent what the specific metree sketch implies, the port security/clamav i
> s one of those
> few.

If /var/run is tmpfs when the system is built the script I posted would 
handle this. However, after the tact, and remove the old /var/run instead 
of having the tmpfs mounted on top of a fully populated /var/run that 
should probably be removed. But we can leave that as an exercise for the SA 
to figure out.

>
> The question that bothers me most and this is just from the pratical point of
>  view as stated
> initially and from a second view, just out of curiosity:
>
> what (fatal?) implications does it have to create some folders by port's rc-s
> cript in /var/run
> or whatever folder is needed to be on a volatile memory device for FreeBSD ba
> se system's mtree
> infrastructure?

You need to ask port maintainers that. But remember, shotgun approaches to 
problems simply create technical debt that has to be paid with interest. 
And, it's always the developer who pays.

It's better to consider a holistic solution rather than pick away at it.

Try my rc script. Simply enable it and change your /var/run to tmpfs. Then 
reboot. If you want to dispose of any cruft on disk you can reboot into 
single user and clean it up at a later date.

One final word: We should consider /tmp and /var/run as tmpfs as default, 
just as RHEL, Solaris and back in the day Tru64. (Though I recall DG/UX, 
HP-UX and NCR AT&T SysVR4 never used tmpfs.) On the flip side, embedded 
systems with limited RAM may be the exception but that can be mitigated 
with a size option (not used by Solaris but used by Tru64).

Try the script. ;)


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e^(i*pi)+1=0



From nobody Mon Aug 29 23:32:33 2022
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 4MGmvV42bqz4b0CN
	for ; Mon, 29 Aug 2022 23:32:54 +0000 (UTC)
	(envelope-from jsm@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MGmvV3Kgxz3r78;
	Mon, 29 Aug 2022 23:32:54 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661815974;
	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=jDcv2JiksqxWEdebKd4L6G1pqrq+xlyEz3Ufee2jDEg=;
	b=qWdFh2bCud8Fxf1EvcRT3NUmFTAzGpfQ5Y4nyaKbanlTAu+jaIzdAqMvewbcLjKxrqCRaD
	K2z8Fxb5EYSO8jpZSku/0/n5FvYKY768xFH9O8lHNkCn482/GRnBmz+RDNZCxOD7T8SCXI
	UZnCG2TYfIecaWXl1Inxa/EX9rFfz5CAICWnR90TV9oZTqCyQM1EOr7zMy+wymddIsnBsN
	xBazaNs9nTRwa9SN3w/KKB70ErNI2JUaWatFgE2qoxBA7AJQGQqBYYdRGvaL4nEYksfZ0c
	pF5spixeYGeTfaJoh2GHvchCYtbFTfXvye9iwrKZkOxeBpCAzuP6k1Vduo2IqA==
Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202])
	(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: jsm)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MGmvV03Zdz1KTR;
	Mon, 29 Aug 2022 23:32:53 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
Message-ID: <430844d1-ae2f-90d2-eec7-646c848e084f@FreeBSD.org>
Date: Tue, 30 Aug 2022 01:32:33 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: archivers/arj fails to build on jail
Content-Language: en-US
To: Renato Botelho ,
 Current FreeBSD 
References: <9636d41e-bf21-8130-ff15-e5dcbaaa4fe8@FreeBSD.org>
From: Jesper Schmitz Mouridsen 
In-Reply-To: <9636d41e-bf21-8130-ff15-e5dcbaaa4fe8@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661815974;
	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=jDcv2JiksqxWEdebKd4L6G1pqrq+xlyEz3Ufee2jDEg=;
	b=jhEBN+GxXlLPsnlZ/qczbvQYVW19mn2dNd+jXiDidyw2vjlcgBlC+ZEhSEhuZ0M7PXCEtS
	dqNrDMfPRwq1VkKs+INYXBAFFpB6MYhS8Ii3dSrZy521n9QkXGr759hh7NvoAoRJf2n3XG
	nt7kO4EO+yQdh+2zwc9O07675MJg4oJLejmcnT3+PedrYDOsb4LYTgaq5UygG+ZXPy9r+4
	JTmCNdRECH+0oMZ0KdJBET/lCp2RVC74/VijgPu/Noq5JUqycop3dDcfl37zEYOd3gDGCc
	qczvfdLFw9RsXlFCyWx4NqOK/A2PuSyqzDcpGWmcsnlOHvJeo53PGjMWl9MRCA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661815974; a=rsa-sha256; cv=none;
	b=OA/S6LmgdlGN/fsucVuEbgrlFiXPYLxxHbd7kTLq6z81BklSl4wGVEt9csp7F9wMhvKl1o
	UMVpbCEfIsVi5J7SAsmVIIthwfbImwZOR4lude339WOrnR412Vx7TSv9khj4yG+zD8PivT
	WUoC+YsjDBUewiH9ETrqbX3FCGGp2WrwIFGiY0m71EDmEJpu1q9YVBFYO60gWOMLy0wAj7
	+6uahyVjM5lYItfSmI6GRravGHbRq99CbHyGsBxnx6kmq4HCzc/WULVNDC7PTZ2yaKnBDF
	HYici/WdCsdaSn203BhY+/BUV5YrdOxm3lEti9bzKxVkrTVuthZmtHNes4Xe5A==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N



On 29.08.2022 17.29, Renato Botelho wrote:
> There is a PR [1] opened for years reporting arj fails to build on a 
> jail.  Recently I reproduced it on a system running CURRENT.
> 
> I just launched a jail and tried to build it, and got the error as 
> described:
Did you use ezjail?

I tried to replicate and I think the error is triggered by
the nullfs usage of ezjail. I copied the settings of ezjail without
nullfs usage (using the basejail as path adding etc from the failing 
jail to it and removing the fstab from jail.conf) and arj did get a 
working msgbind.
> 
> gmake[3]: *** [GNUmakefile:258: freebsd12.1/en/rs/msg_crp.h] Abort trap
> 
> msgbind binary built inside arj, when called, ends like this.  I has no 
> clue about what could be the root cause here.  I also don't understand 
> why arj builds fine on poudriere, which uses jail as well.
> 
> If anyone has any idea about what could be causing this, please let me 
> know.
> 
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235636

From nobody Tue Aug 30 10:41:02 2022
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 4MH3kf4tMCz4Zx2x
	for ; Tue, 30 Aug 2022 10:41:14 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2104.outbound.protection.outlook.com [40.92.97.104])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MH3kd5stJz3Zl6
	for ; Tue, 30 Aug 2022 10:41:13 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Vl+zazWxsqdOMTOb0NB7vu0CgSAwcZIaP3nBUyU7a10TJHm0uC6D7zhVKv4sl+1UhthTg9ktHu8zhafdHDc+vzg1I6MW5irT1oBXeB25HPVlmlJw2H/P6yy5H3qWRE5ki58YmcTI9/TQ56HOCt1DAlpsI6Vn4oQaXhsfVbXJ6pZkASOqPazwnbOvGw+sfHFofZoHxvmMQuP6e2PDs9QWFQFIGFSxzOzRz9fUoCEkIq6bpM27t5Tj2vCMAq8plLNRbMQhasr73d1JEzxJjtEW40+fcRk2BxRm7Ihk0rZ45kY1ERIdvAi+toDNmDcAv199ucyWrT117lafppclEHzV+w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=6iwJ2IpNwqES8BW7MqewbnUWt6FxzIL6J1YszRyvPWI=;
 b=cpuWk9O3YnuPwNChfTePlY2/DzKvOubz3ZcaeJH+Q7FWTQa7GfTQ+seFZzx/cFzRNlkMJ+2v66sjtTPDy22Clqd6myl8uSZc+7+vpeyg/J7IU+lcaBIaZN8dHHQ2oh1wT2YVgmYZViASyZWCMzrlu6OJCmr4mr40gc/AjUowj8pj+rW5w6iuEnFw+M+xz/0uv7rPDMK156rbetqBdJuRFdNVVkVnqLzsrx5k9FzZJEoOMaVhcc6nD7VzqgEmDZ9pAvaA7IkT13x/d4VCc5vC2Aa+OGkaZPeo70VPV3DfTpnCA5nbq6522C80GsCwlq5Zp8Sz74YFh1WnZs8rpO5izA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6iwJ2IpNwqES8BW7MqewbnUWt6FxzIL6J1YszRyvPWI=;
 b=JmC1LoTy6UAQqpczJHW9yiBQO40Bs7/DsCJscpRFYO+FZK6cWk/btkFzhrphpc5x6D3Sj0U9c8yZJsitqFDp+moOtbbYnY3xEFzCnAg6nxciabBhU+52NbP0WQK3qgESiHxxNbJT3wnFHNZY5jopHcH3vXsOe5RcqzgCrYKkZ6r9FJ8LxFYmnRy7nlQBwoVJ32OeumMwEVIMliDlJvbkn/a7shB0iBgBS2BaZBfeQXs5QVqiBIMUGYgSRryO/uWIYtyCOWr6aFk0ejY2ArK6kYtbg1BuvQfbPdXpAjSLAq0Z0E+/hc4Wl0VkabqpMFbqYjC0zNkUd4oLQm9Lks9nGQ==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by RIZP284MB0921.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:52::9) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5566.15; Tue, 30 Aug 2022 10:41:10 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::8423:7f52:935f:65e2%9]) with mapi id 15.20.5566.021; Tue, 30 Aug 2022
 10:41:10 +0000
Date: Tue, 30 Aug 2022 07:41:02 -0300 (-03)
From: Ivan Quitschal 
To: freebsd-current@freebsd.org
Subject: vt newscon image viewer
Message-ID:
 
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-TMN: [fnL7OOE7ZJbnzdLD/yLL0mEmuUj46Pk2]
X-ClientProxiedBy: CP5P284CA0024.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:94::11) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: dbd26c52-09af-4190-98cb-08da8a7426c4
X-MS-TrafficTypeDiagnostic: RIZP284MB0921:EE_
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	cTJMWBYSm5aX3q0Bmc3cGneebqZHZx9wSyhFBBsp9fB3cNEfTkEZcN8XV6apHnt6wC7EXruGFKmkLabNv6Kfz3aKlJ0AWNMQX/aUTWtPOTuGBXV1aBvRGBzzcnsUvOCLTHOLfUaEjUdBrQ3glUI0tv4hKM0Dqg8EiuhJBZcRIakyFV5zAJ7sFVExyiH4qiIOeGEr76tD/+uWR2F5OVIPPEP7u+k5aRgf1ZCHLqItCcrSQ+KAWvgtc0qerv/ER/Fp1xQPGzKRj7Ossz9zaJ92kSBNNTWBbSOEAXEZHwEFr+i3aqHpGraHgd68x7PtwOF1gk1+UHMA5JVgrix4wndYjNmF8ezyXRNIqBUbA2GLzhYJ3DYGrABE0X/THssRI/MzdAuzEGnKMOKjlMDThLEubkaH/AdBIxo0HLA0wat0u50Xok+WFfujtTA1cKQpaq895FkeRlqTdO96EwQM0RGFPPg1xhj0tm7HGHN7FvV36yP7o6g2SIcheIA0eJhXt/LueMDjjeoEiJMufBuZt6uKtFIH+jhZSUAUO21a/i8tdqn0lnmD1BpsaBblfrsKXXLQeR1NX98r/4h+jxYDWeiZstMp3XXv1z/J9HVIB/hXNntxoBEbYFTI35uaNRdDJT1w
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?Dqg64XWlKq0pTz7ECfgthaMQQc4Ry4K+TLzLwzTcSJ38zbIXH6d1USebzpsN?=
 =?us-ascii?Q?GV10wpUX9i/ASluc68f77wju9KcTBKBunGDE74tqYAMuxwgDYyOdKZS/YOaI?=
 =?us-ascii?Q?XWM8SXH3tJ2bI9CtMVHEIalA/8WTb3SZ6L2Xcbzbv+8wPCKIbL6ENe1l0zcD?=
 =?us-ascii?Q?i8pJQAxcdUOCj7smxR/wSbNonjjP4vwDjxKbwOnF5i5GsV7Pfzhbg8I7DNT6?=
 =?us-ascii?Q?EUAcYzQV5OKYVyFNXS9I2PWWbXPBuXxJKzTlRQpwe9+3f9Uuu+voc8KfuF3u?=
 =?us-ascii?Q?y5FzYBXulTHivU3BO0IB5LTk8otXFt6az6yVLX0j+G2bv+a1/+qvjE4OADK8?=
 =?us-ascii?Q?yO/UL5w9o9mdaEzQsT9zJjTaVzOQ/P1RCrKTyUP/XkYnCVmFYvl67SrE7Rxi?=
 =?us-ascii?Q?cmAKAzE21hEWZve9cUCUtkKvwjku0UeKktWjS9UnGsBr96R061h/s1+Ct4gH?=
 =?us-ascii?Q?9L3vZX2mmkZVg1BAS8lpjsknrhEazVVO0rcfgsp3M9vNrodtrvpXHL9o/fS8?=
 =?us-ascii?Q?SnOjWS4JqmCcTxFiVfGEZw8AZXJhlqraDn4uUNGnoF5ge9mm1TUhxVPuVhOR?=
 =?us-ascii?Q?28KMTUq/FFk9qTehYIECgfOrqv3QY0ZithvimnzB0A7mv54OeL/7LJoUzuRZ?=
 =?us-ascii?Q?bS6L98DdmVu2qtGF7roOguNUsuARPwtpiKgGXlVxIvboFsDBVLHF0KAP24U2?=
 =?us-ascii?Q?xcvT/Fcw6rHam4dWl9kjSaualkGksJKN3gQEr1I0xMbQfqJDig9XgIq/cByg?=
 =?us-ascii?Q?OycZsBfqUmYf98YcX+APsiWT7Lg9OewP67Nh3lWMX14j3JpsFSSStQakZHa7?=
 =?us-ascii?Q?BcThA2QlCjHORFUIBSu/tdiQyO2IrDsimY7TGVStncNGcZEpfCdc+VdIzWTq?=
 =?us-ascii?Q?jGLV3HUuD63HStXvtytIqK4JDc9sUxNYmoXogFTX0Xp1gZDtqOh1ny1tgDCd?=
 =?us-ascii?Q?epS2GhhSTaG7EXKBHh9YxTlY3T7R7mQGlWZfSFzYYffnxSeWu72HviNA0mV+?=
 =?us-ascii?Q?iJe2Wx23RGUIrEuisDFr2YT7jq0w7VWwRjZYt28BdzAASExqAeBrhZHc88Vl?=
 =?us-ascii?Q?9GThdiRtC451agZclIcqgW2CRJJV5F22zkJ1sPuuDdcd0DwobrJdBSWrotin?=
 =?us-ascii?Q?CF0E0vaZ/yRXAwfwqPZmTHu2qhMr65i5y01BnwRfcfEHXiSbQ2OnzgB1kT9c?=
 =?us-ascii?Q?ArRGpMIxE1RZ7Gx9A3r4AYBnadKwBWmbMbslZucyczbpWnHHsfpep6me/pTD?=
 =?us-ascii?Q?5G05rGL0xUYcz8Mh/WpU2I6X04gDYgArsNbL2h0mpQ=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: dbd26c52-09af-4190-98cb-08da8a7426c4
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Aug 2022 10:41:10.6039
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: RIZP284MB0921
X-Rspamd-Queue-Id: 4MH3kd5stJz3Zl6
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=JmC1LoTy;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.104 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.37 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-0.99)[-0.993];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	NEURAL_HAM_MEDIUM(-0.39)[-0.394];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.104:from];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.97.104:from];
	DKIM_TRACE(0.00)[hotmail.com:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[hotmail.com];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N


Hi All

I couldnt find anywhere any image viewer for vt newcons like we had in  syscons 
with ZGV.

is there any? or just bitmap viewers such as  "tiv" and "viu" ?

right now im using "viu" because this is what comes more closer to the original 
photo

thanks

--tzk

PS: wont harm asking. anything for video as well ?


From nobody Tue Aug 30 11:17:26 2022
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 4MH4XV6nvFz4b1kW
	for ; Tue, 30 Aug 2022 11:17:30 +0000 (UTC)
	(envelope-from garga@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MH4XV68Z6z3dMN;
	Tue, 30 Aug 2022 11:17:30 +0000 (UTC)
	(envelope-from garga@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661858250;
	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=v+hjkzAQNAs80okqzzj1NpMENv4RTrPfKROpKGVeo1E=;
	b=lkE7cgPkzWS73kMx3lyoAHRPoq95NwwCVeKpjtdsFhwxlJCkoqhMkgqzDX/N0L5L+l+gdg
	wVt6xoX8t2bhFI5USF+XBjElj+zVfI7nCrg7OicPvQhIFmdi0vq0a4ANOKz6KFjbCGV1AI
	x11VpkUWkGB+cbDFL+nfFo92El+90v3uXEyJ1s6WGn3g+TczuYhAfXCC2h9rdeXrGM/aNC
	B7+PGtcXqssx6AAn6lWGTlJH85TQUuh81exLzqDSGIvqN1Tdi+XkhCJOSe2igCQYkUhsYH
	HvgIeQ59mspuIERMFx8RsxsJ0+6mdmD0lhlY+L8kmk4O5o18jt+mA9v6A8j6UA==
Received: from [172.21.4.170] (dynamic-177-53-82-16.telecominternet.net.br [177.53.82.16])
	(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: garga)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MH4XV0Q6sz1N0q;
	Tue, 30 Aug 2022 11:17:29 +0000 (UTC)
	(envelope-from garga@FreeBSD.org)
Message-ID: <74388082-ea84-564c-44ee-f1a568b75d5b@FreeBSD.org>
Date: Tue, 30 Aug 2022 08:17:26 -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/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.0
Subject: Re: archivers/arj fails to build on jail
To: Jesper Schmitz Mouridsen ,
 Current FreeBSD 
References: <9636d41e-bf21-8130-ff15-e5dcbaaa4fe8@FreeBSD.org>
 <430844d1-ae2f-90d2-eec7-646c848e084f@FreeBSD.org>
Content-Language: en-US
Cc: erdgeist@erdgeist.org
From: Renato Botelho 
In-Reply-To: <430844d1-ae2f-90d2-eec7-646c848e084f@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661858250;
	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=v+hjkzAQNAs80okqzzj1NpMENv4RTrPfKROpKGVeo1E=;
	b=m5vGY2Lo2jJBwGFX5oyLOC3DfwLmmVqutcwaobSlcIqfGyABzOOvKBSkZWOD07o7J8k3jW
	f/RJIa/bRivYDMnh7wlRpk790LKU5qGPjPh+CqIPvRe7sWOpVSDy5LszyAomA9jiwZjycL
	OIxuh/nvi/Yz719vwEZ+d10jBCDUxZrsz323umGxnowgJ406wzPa7tK8XchHiGSW/bqSar
	XyGd8dTFpU9ZUQyp0xpYfDIow4WU3uf097DnAzTOl3IE6xl5nPeNEpCyKKExq8QxYW+ibI
	Od9gUtyfyLX8TDQ5tgo3jPfepKtWdxui4YvOg2EUgQ40bG5nRXz8lTo68uL0vg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661858250; a=rsa-sha256; cv=none;
	b=RNeB02b65RmcyT4eI6sKbCvXqvh1BhMROLjmbiORTlj1qgzwCyJ6hgaDT7+mm72O2pxrCs
	W6UNPqJFnzn26q85vTscNmr3K4fZ3jC78JwU11sTXz9j2vnQ6iou7/b9FzDTz97RBvApao
	nMcR46owK2PaHAPSHPKBmDiQS5F6qOpoxU9Wcffr5yr/D/oJywtQcUTL191N0bxjxl0G6v
	YMFRuFGlsEz28GwAkBhR/vZZgjQIfve9o5lPMdG0UhIlWl/Fw5f6NWEM2BbIKFGMMxnLNd
	n8EM2BIx3dGWInMWe0Qi5s5MCkybaFlgD4RvLpqknNqLRmMQDFmwQnJ2S/KtFg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote:
> 
> 
> On 29.08.2022 17.29, Renato Botelho wrote:
>> There is a PR [1] opened for years reporting arj fails to build on a 
>> jail.  Recently I reproduced it on a system running CURRENT.
>>
>> I just launched a jail and tried to build it, and got the error as 
>> described:
> Did you use ezjail?
> 
> I tried to replicate and I think the error is triggered by
> the nullfs usage of ezjail. I copied the settings of ezjail without
> nullfs usage (using the basejail as path adding etc from the failing 
> jail to it and removing the fstab from jail.conf) and arj did get a 
> working msgbind.

Yes, I also use ezjail.  I'm cc'ing ezjail's maintainer to see if we can 
get some advice.

Thanks!

>>
>> gmake[3]: *** [GNUmakefile:258: freebsd12.1/en/rs/msg_crp.h] Abort trap
>>
>> msgbind binary built inside arj, when called, ends like this.  I has 
>> no clue about what could be the root cause here.  I also don't 
>> understand why arj builds fine on poudriere, which uses jail as well.
>>
>> If anyone has any idea about what could be causing this, please let me 
>> know.
>>
>> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235636

-- 
Renato Botelho


From nobody Tue Aug 30 14:35:01 2022
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 4MH8wl5nTnz4bMpt
	for ; Tue, 30 Aug 2022 14:35:19 +0000 (UTC)
	(envelope-from jsm@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MH8wl5HGMz3qYw;
	Tue, 30 Aug 2022 14:35:19 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661870119;
	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=ly5qFpoSnL3F7BUwg627opckcUgZedqz12HlujstMXo=;
	b=ox1HjNS+YTjxiBf3brMbSK64vK2Oktr8WAJWnwa9f2X/Q8YFhucAoa0vXfRNxWtT3LJs5l
	M8aeoG7JraGTpMXkTmuNnhfIfmqkVPJke0XQGxRUJ1w/ueKs24091X1dwePK8+geZuUkpj
	5o2OlxR/L2sXiMJAWeir1cENF2mNVJ7UQgowAeJvJKkx8Pp7nrWHLs/O19VDfoFA30K18j
	HgNxgEmcqLY5SCmns7sX2Q05bsoJ6ZNqilUuQIiz7QWpnS1lo2j1OwWhpV34qPnx+7JARL
	U39ne4RtD3mxeyHc7ISJvBwTHXzriX0w+9WcD+KFdAOIlX7VS6BKPrAOx+Y0+Q==
Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202])
	(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: jsm)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MH8wl1DSXz1NPs;
	Tue, 30 Aug 2022 14:35:19 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
Message-ID: 
Date: Tue, 30 Aug 2022 16:35:01 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: archivers/arj fails to build on jail
Content-Language: en-US
To: Renato Botelho ,
 Current FreeBSD 
Cc: erdgeist@erdgeist.org
References: <9636d41e-bf21-8130-ff15-e5dcbaaa4fe8@FreeBSD.org>
 <430844d1-ae2f-90d2-eec7-646c848e084f@FreeBSD.org>
 <74388082-ea84-564c-44ee-f1a568b75d5b@FreeBSD.org>
From: Jesper Schmitz Mouridsen 
In-Reply-To: <74388082-ea84-564c-44ee-f1a568b75d5b@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661870119;
	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=ly5qFpoSnL3F7BUwg627opckcUgZedqz12HlujstMXo=;
	b=ulZPuSFVHBNpVViYWP5uXldVCfvJWsCrqdodX8OAViTUx31uArLXswyg1LlvdCcXDtH/WQ
	tHqa/LZ/dAY+e+BpwC+MZvHyVuWldBo5WXx4YdJv5DfDHeukzXO6naEyCG3AVDNBjIcMWk
	08Jgsywzm6Yo2KK08+/lHw4U7Zwfv8vsQx/ofZGASSvOZAYmfRDrOjVnx3/ttWZT2oRawL
	2i5fRxaOtVrTvDqNfiZCOzHdiX1SfUeRhZc4IfpStNPHZf2BBFX9l0hU74wUqfyPkJTbtx
	VwrGGJpzH5GXaNIdwZPqOlQjqNg6rFhweu8izpzUWyiE9JyFqo92bQJ2/KSZ2w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661870119; a=rsa-sha256; cv=none;
	b=DP94W4M9rKF7o33AYEgvvTjU3g5Czhz8Ub5T/QB9L9FPCsk1pRa6iZNU9XM6q6tkUe0Sdk
	KdIuUWv/8yo1TXdGOt1VolAAktkZefehMHV/kLkTfhHiRaFgsaLkuZ2viHz3DpnuLjVOT3
	qmRYWaNxcAJR/UqlT0GZDPv7eM0XG+z1jpR38myY4n7WvYdshtYGpPy0PrwjrLgqe8vGbC
	BzcRaueX5tuJshtP7F045HUTEZE0fBwusHRssV210VTRPUIC/ePhe3wjrYd9d5TJoeejz3
	QhtmTkn5FdCNskBIVda/yTXh+gT3+CA4849hMXhVmK78JBBjRSTj6w3gKWCbtw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


On 30.08.2022 13.17, Renato Botelho wrote:
> On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote:
>>
>>
>> On 29.08.2022 17.29, Renato Botelho wrote:
>>> There is a PR [1] opened for years reporting arj fails to build on a 
>>> jail.  Recently I reproduced it on a system running CURRENT.
>>>
>>> I just launched a jail and tried to build it, and got the error as 
>>> described:
>> Did you use ezjail?
>>
>> I tried to replicate and I think the error is triggered by
>> the nullfs usage of ezjail. I copied the settings of ezjail without
>> nullfs usage (using the basejail as path adding etc from the failing 
>> jail to it and removing the fstab from jail.conf) and arj did get a 
>> working msgbind.
>
> Yes, I also use ezjail.  I'm cc'ing ezjail's maintainer to see if we 
> can get some advice.
>
> Thanks!
>
Hi again.


I narrowed this down to  symlinks ,wiithin the jail, to the nullfs 
mountpoint.

Replacing symlinks to the basejail mount point with dirs and setting 
this in the fstab of the jail

and msgbind is a valid executable

/usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0
/usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0
/usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0
/usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0
/usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0
/usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0
/usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0
/usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0
/usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs ro 0 0
/usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0
/usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0
/usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs ro 0 0
/usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0
/usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0
/usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs ro 0 0
/usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0

It should be further narrowed down but nullfs alone is not the issue.

>>>
>>> gmake[3]: *** [GNUmakefile:258: freebsd12.1/en/rs/msg_crp.h] Abort trap
>>>
>>> msgbind binary built inside arj, when called, ends like this. I has 
>>> no clue about what could be the root cause here.  I also don't 
>>> understand why arj builds fine on poudriere, which uses jail as well.
>>>
>>> If anyone has any idea about what could be causing this, please let 
>>> me know.
>>>
>>> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235636
>

From nobody Tue Aug 30 15:39:48 2022
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 4MHBMC0mW3z4Zkk1
	for ; Tue, 30 Aug 2022 15:39:51 +0000 (UTC)
	(envelope-from garga@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MHBMC0Cb1z3xvR;
	Tue, 30 Aug 2022 15:39:51 +0000 (UTC)
	(envelope-from garga@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661873991;
	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=ItNzVMSjTwJUQ8dOal+/NAlKlT1qJeAoPAHsUNNifBs=;
	b=C56DGy42LVGp0JDpAGMgZA93O1IxwOXxdTmsbkTkNBS0mBJa4keebHyCnX9ALWmTs2eHd0
	LuPtal6SnI8d117q96oLeJ6s/063ohIAJtu3fBb2+fuCGUKSdpttcjmkHU/AUdAg4w+53o
	N7Apuaqwevp/rYYx8xSjCGOczv389ePkDBSrQ5C/X+0ahIyxspH4cBt1Qy6wSEdTnFw6oJ
	5FwbjIa8HF6CnBW9eHpqOr9Wud7DeigalWc05EQg1oeCaQzGIFOzpoYZ5VhVQ+oQ62yTRJ
	XAZtL3r682VSkvalJAhmcfzAf8baigeBRshKaLyzUDT1kQ+17P2A66Ccu0IMew==
Received: from [172.21.4.170] (dynamic-177-53-82-16.telecominternet.net.br [177.53.82.16])
	(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: garga)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MHBMB2cnvz1Njl;
	Tue, 30 Aug 2022 15:39:50 +0000 (UTC)
	(envelope-from garga@FreeBSD.org)
Message-ID: 
Date: Tue, 30 Aug 2022 12:39:48 -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/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.0
Subject: Re: archivers/arj fails to build on jail
Content-Language: en-US
To: Jesper Schmitz Mouridsen ,
 Current FreeBSD 
Cc: erdgeist@erdgeist.org
References: <9636d41e-bf21-8130-ff15-e5dcbaaa4fe8@FreeBSD.org>
 <430844d1-ae2f-90d2-eec7-646c848e084f@FreeBSD.org>
 <74388082-ea84-564c-44ee-f1a568b75d5b@FreeBSD.org>
 
From: Renato Botelho 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661873991;
	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=ItNzVMSjTwJUQ8dOal+/NAlKlT1qJeAoPAHsUNNifBs=;
	b=x7/W/IQCRgxMrD+ci1HekxtThqVz/EsknQMUXLoMEibymcMH9vIB55PFo2AigBbUVoy+kI
	BuXIi3x/FCVy2H+ATCNgl9dflVtT7Kg0Nl4r2fO+JlnwHNTZKGMqQYAXWD08T4NxcfFebP
	fkLNXvN2frSbiS+GjZ3jhgssDo3yRSbGgpB++xN8yz9uxkzlx9CzPcMPrFe9yCbicApeUs
	P/sDDCNA/Bkqkgw7tMBTaQ8L6OU2dpTDU/M+FVZY1L3w/pcWcKCp/sQXENCsQCDOR1brfN
	/Z//I91paVRWzV9pYR8P58iWi7jra2ME2trV/r18qQ9t1mOE2duUjC+kquS4Ww==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661873991; a=rsa-sha256; cv=none;
	b=MGiZ3eBMz7mQCftqOSrDU5bK934mj0EFcyGQM0uSBzAmcaK+8hqKX3QDm6pqCuG8T4Id7w
	PqiJ3Vy9cih80FdTDTdih64RIKTeQsJhk1agW+B8VELJmM8T1azBcJGqlJxT+DDOsyJBND
	cxpI3pRQTgtDZrw0pypdj8Fp4YZulFldmHy5xSxwk35cnAB2/OAFbmeF4VWq+MLdwGx2uV
	TkRogmFseSd8ENgytzt2+jYgwaQ2SbRCjIz1KarzTtltMSps/SoRMKfMZomNqyfaR11fJ6
	AnjxA5Z/h4j+gyTswgTziFJONWZFBwud1U2vOBoO5HEpVBk0G85UrbO4RrNM0g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 30/08/22 11:35, Jesper Schmitz Mouridsen wrote:
> 
> On 30.08.2022 13.17, Renato Botelho wrote:
>> On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote:
>>>
>>>
>>> On 29.08.2022 17.29, Renato Botelho wrote:
>>>> There is a PR [1] opened for years reporting arj fails to build on a 
>>>> jail.  Recently I reproduced it on a system running CURRENT.
>>>>
>>>> I just launched a jail and tried to build it, and got the error as 
>>>> described:
>>> Did you use ezjail?
>>>
>>> I tried to replicate and I think the error is triggered by
>>> the nullfs usage of ezjail. I copied the settings of ezjail without
>>> nullfs usage (using the basejail as path adding etc from the failing 
>>> jail to it and removing the fstab from jail.conf) and arj did get a 
>>> working msgbind.
>>
>> Yes, I also use ezjail.  I'm cc'ing ezjail's maintainer to see if we 
>> can get some advice.
>>
>> Thanks!
>>
> Hi again.
> 
> 
> I narrowed this down to  symlinks ,wiithin the jail, to the nullfs 
> mountpoint.
> 
> Replacing symlinks to the basejail mount point with dirs and setting 
> this in the fstab of the jail
> 
> and msgbind is a valid executable
> 
> /usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0
> /usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0
> /usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0
> /usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0
> /usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0
> /usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0
> /usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0
> /usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0
> /usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs ro 0 0
> /usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0
> /usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0
> /usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs ro 0 0
> /usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0
> /usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0
> /usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs ro 0 0
> /usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0
> 
> It should be further narrowed down but nullfs alone is not the issue.

Interesting.  And just to add a note here, I copied msgbind from jail to 
host and tried to execute it to confirm binary was really bad and I got 
the same Abort trap message.

-- 
Renato Botelho


From nobody Tue Aug 30 16:03:48 2022
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 4MHBtv04vhz4Zn81
	for ; Tue, 30 Aug 2022 16:03:51 +0000 (UTC)
	(envelope-from garga@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MHBtt6cVcz41vn;
	Tue, 30 Aug 2022 16:03:50 +0000 (UTC)
	(envelope-from garga@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661875430;
	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=AhKUnQvxJE2PWCixaLPL3RKdZ1kKAekzjLOcQMZw/Ww=;
	b=sB+yLRKSME+wJMmok+WIAtZIhZMjZW8jYKs0VKsvPe5TreH7tEwLu8Tw2FCRX3I4saev41
	xUE2b9TnmEbYr3zU0KsMTq3ykOmINmQQB4jyfJLeHm7m8ZZoDz7kn8OAcbBv6Xikm2N7gI
	FW3lJfW6Pj5NKBXJRqhUA7aVPQl93qjuuN5/sfelDXUH0zEcZxQuP+ghcnhmO5Qb0bQIJM
	XUSRVStjBW9VtP5zjJBzKKgY4+cP2cVsefKSbXSRMLX2vvCuR2dNo0BI3OQTxWR39mBqZe
	Sk+xNzc8CmRJcW2y0CI47wSu+NVaFpzJsk3dZMqjBSYNpmaJNP/laWuWCbaJIA==
Received: from [172.21.4.170] (dynamic-177-53-82-16.telecominternet.net.br [177.53.82.16])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: garga)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MHBtt1pPfz1NYl;
	Tue, 30 Aug 2022 16:03:50 +0000 (UTC)
	(envelope-from garga@FreeBSD.org)
Message-ID: 
Date: Tue, 30 Aug 2022 13:03:48 -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/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.0
Subject: Re: archivers/arj fails to build on jail
Content-Language: en-US
From: Renato Botelho 
To: Jesper Schmitz Mouridsen ,
 Current FreeBSD 
Cc: erdgeist@erdgeist.org
References: <9636d41e-bf21-8130-ff15-e5dcbaaa4fe8@FreeBSD.org>
 <430844d1-ae2f-90d2-eec7-646c848e084f@FreeBSD.org>
 <74388082-ea84-564c-44ee-f1a568b75d5b@FreeBSD.org>
 
 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661875430;
	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=AhKUnQvxJE2PWCixaLPL3RKdZ1kKAekzjLOcQMZw/Ww=;
	b=hbQPPvNHeviiaSfRWSw/le/ndAmqdZmVT0/MGrs/8nGAOsuN36mOBwc5343IGAHYCbYDW/
	r96dLuUirLyrIk4wk+72HnFVX2Zu0adM8F5DSGk7poFQgyL27kx4KSVpXxjdt7Z2D3vYcC
	ORJTqUOwwX+TyIyT0HiXwJAwyV8M7klYYEy1EDAjHBqC/T9HZ04lPpRShoGqUzUMbK/L33
	NWVo5NhwrIRfwRXceFSM/UFQcRQ+nKCS+lrI9wmTMPsIqa3BQ2pn3t0hMxy5Jo3srzPA/B
	Wo8nKa8WQXxQBd4RAZaUUYtOJc9r8mWzRW63+6OXV6cgxzV4z3nV5bQali58MQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661875430; a=rsa-sha256; cv=none;
	b=UuQE9+BZSzxN1t1H5qqc475aDbCUXyHDGgXcoGgNKbVKx86sha0Bb1iiGnhYlsOGemaz8M
	9E67A3+eNwlUkcpSzL8qL4SWEKTfgaRkJvTpK3KmPCoJ+Dq8gOGuy4ssTEEZ6tE6Qa2hsV
	VJRpoZMMCCV3jLeFz7B3q9ba49Zk+cVIuA9FdqnMK2AHwcqTEHJb7oqOe6yJ8v5Ii6EQht
	QGouRGNXtzQlVTJ4D8xV2C2wDC9QUrMOT1q14woxRqXrpn9GrYkGRbT1YFHj5etc9kYQR9
	OQSyJTs1CCKcwd8HLlNJbgBKdHMjUDXgt9Z4NQAO20SP7OwcmiR10pqWwlzkIw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 30/08/22 12:39, Renato Botelho wrote:
> On 30/08/22 11:35, Jesper Schmitz Mouridsen wrote:
>>
>> On 30.08.2022 13.17, Renato Botelho wrote:
>>> On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote:
>>>>
>>>>
>>>> On 29.08.2022 17.29, Renato Botelho wrote:
>>>>> There is a PR [1] opened for years reporting arj fails to build on 
>>>>> a jail.  Recently I reproduced it on a system running CURRENT.
>>>>>
>>>>> I just launched a jail and tried to build it, and got the error as 
>>>>> described:
>>>> Did you use ezjail?
>>>>
>>>> I tried to replicate and I think the error is triggered by
>>>> the nullfs usage of ezjail. I copied the settings of ezjail without
>>>> nullfs usage (using the basejail as path adding etc from the failing 
>>>> jail to it and removing the fstab from jail.conf) and arj did get a 
>>>> working msgbind.
>>>
>>> Yes, I also use ezjail.  I'm cc'ing ezjail's maintainer to see if we 
>>> can get some advice.
>>>
>>> Thanks!
>>>
>> Hi again.
>>
>>
>> I narrowed this down to  symlinks ,wiithin the jail, to the nullfs 
>> mountpoint.
>>
>> Replacing symlinks to the basejail mount point with dirs and setting 
>> this in the fstab of the jail
>>
>> and msgbind is a valid executable
>>
>> /usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0
>> /usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0
>> /usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0
>> /usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0
>> /usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0
>> /usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0
>> /usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0
>> /usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0
>> /usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs ro 
>> 0 0
>> /usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0
>> /usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0
>> /usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs ro 
>> 0 0
>> /usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0
>> /usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0
>> /usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs ro 
>> 0 0
>> /usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0
>>
>> It should be further narrowed down but nullfs alone is not the issue.
> 
> Interesting.  And just to add a note here, I copied msgbind from jail to 
> host and tried to execute it to confirm binary was really bad and I got 
> the same Abort trap message.
> 

And one more interesting information is it builds fine with gcc.  I just 
added USE_GCC=yes to the port and it worked.

-- 
Renato Botelho


From nobody Tue Aug 30 16:45:49 2022
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 4MHCqN4PrRz4ZsJB
	for ; Tue, 30 Aug 2022 16:45:52 +0000 (UTC)
	(envelope-from jsm@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MHCqN3sKlz47LD;
	Tue, 30 Aug 2022 16:45:52 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661877952;
	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=Z8ZDPVR3oGq5/CwnUoZSKOIRB8K2rPle9KSoIYQRoRc=;
	b=RISWCMYYj5lgYjeigiP5uf0tyiKn6kg6aALLsQXctkowCo/OX5GkTjVB3l2XY3OpiktDWr
	IyUMJekqBf/8PYwORu9KMsPGQmZREw7kv1zLVySKI9+yHbRGDs7hsA+BIEtCXzAoSzs7qk
	9o0xSZhaNsaaDkl/RPYX2ZCZD93dbz3UjhFPj/dTkM/u3ir/0dRkY1PpFg+xKYmOXha8X+
	SlNrGFxynHp4rqfPBoaywaCji0M2Wv3GYMlAB1SCAmR0XCOFmERNJdBXmKNpnh+RdHfeAw
	m5pH+tzVjbuaPEwQabiGGmfeEvVdMpJsyLK6mwIaqiLoJ9Cz5g3Y4P+yyQKEQQ==
Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202])
	(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: jsm)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MHCqM6ph7z1Nwj;
	Tue, 30 Aug 2022 16:45:51 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
Message-ID: <503d2719-4942-3d2e-b6c8-7fcd91f4fe4a@FreeBSD.org>
Date: Tue, 30 Aug 2022 18:45:49 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: archivers/arj fails to build on jail
Content-Language: en-US
To: Renato Botelho ,
 Current FreeBSD 
Cc: erdgeist@erdgeist.org
References: <9636d41e-bf21-8130-ff15-e5dcbaaa4fe8@FreeBSD.org>
 <430844d1-ae2f-90d2-eec7-646c848e084f@FreeBSD.org>
 <74388082-ea84-564c-44ee-f1a568b75d5b@FreeBSD.org>
 
 
 
From: Jesper Schmitz Mouridsen 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661877952;
	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=Z8ZDPVR3oGq5/CwnUoZSKOIRB8K2rPle9KSoIYQRoRc=;
	b=rNSDEFrzC5FvoHr/9ZV/a9sPYo/3c3EDTLMwkaVFz/TOVMoW4WHBYEHnFtVOAXpYhFaPBW
	CyUN1CEJ/QDHKWSRrK8Omp2OjeJsygO5o7ya2UBDIG9tyW3nWAShSMFntHca/wM60RgvTV
	qrIiExY9Emxkz6KcGZ/V5OmzAmj/x/F+mGhFmSIyPLHfmnCOyV9XN6Pkh6ZfWcqcGtIN8c
	+JC+vFYE8sTh0cTyND1fPVWxQEmTyp5Mg3jQu+wom/7PhaPKJrVB4AMp0nN9xHciZZz5RC
	AAYphGMhiU1FbWlnzJMAQuuUsykEZ1cJrsY8S6nN7cz7PEwPq/KyfOG5OOyn7A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661877952; a=rsa-sha256; cv=none;
	b=dMAJ4T4cF6ImWbZ4yzZDSWjAFar0z4kErZnjssJNV7ufBlPn2AHDUW3BHpUaBM+eP02KP9
	LpR2hlYkZQmOJBhFL7h0GYoyVcmcchdrJ2SHzhbD5Pe3pzhy0kqyNBGIg8rp+xD2T8M3h0
	4knhnXnPJrGuw6/Upgcd1TCERr8hCPLwsNgHEkYxXCItCjoSocaYq+w5HP3b/GGeStU2bW
	hVIgd9WrxafglAI9h2oFNxKffU2yvD5LkZx1YGJtYsW/OnoZJ4NxCZlTU5OgsPtjlDRV1e
	iXSybKSbATfyYi365Enh11gI4SaPZVOFv7o/4vRZdBKG+BtW8LxMMoabz7TY8g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


On 30.08.2022 18.03, Renato Botelho wrote:
> On 30/08/22 12:39, Renato Botelho wrote:
>> On 30/08/22 11:35, Jesper Schmitz Mouridsen wrote:
>>>
>>> On 30.08.2022 13.17, Renato Botelho wrote:
>>>> On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote:
>>>>>
>>>>>
>>>>> On 29.08.2022 17.29, Renato Botelho wrote:
>>>>>> There is a PR [1] opened for years reporting arj fails to build 
>>>>>> on a jail.  Recently I reproduced it on a system running CURRENT.
>>>>>>
>>>>>> I just launched a jail and tried to build it, and got the error 
>>>>>> as described:
>>>>> Did you use ezjail?
>>>>>
>>>>> I tried to replicate and I think the error is triggered by
>>>>> the nullfs usage of ezjail. I copied the settings of ezjail without
>>>>> nullfs usage (using the basejail as path adding etc from the 
>>>>> failing jail to it and removing the fstab from jail.conf) and arj 
>>>>> did get a working msgbind.
>>>>
>>>> Yes, I also use ezjail.  I'm cc'ing ezjail's maintainer to see if 
>>>> we can get some advice.
>>>>
>>>> Thanks!
>>>>
>>> Hi again.
>>>
>>>
>>> I narrowed this down to  symlinks ,wiithin the jail, to the nullfs 
>>> mountpoint.
>>>
>>> Replacing symlinks to the basejail mount point with dirs and setting 
>>> this in the fstab of the jail
>>>
>>> and msgbind is a valid executable
>>>
>>> /usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0
>>> /usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0
>>> /usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0
>>> /usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0
>>> /usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0
>>> /usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0
>>> /usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0
>>> /usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0
>>> /usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs 
>>> ro 0 0
>>> /usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0
>>> /usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0
>>> /usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs 
>>> ro 0 0
>>> /usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0
>>> /usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0
>>> /usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs 
>>> ro 0 0
>>> /usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0
>>>
>>> It should be further narrowed down but nullfs alone is not the issue.
>>
>> Interesting.  And just to add a note here, I copied msgbind from jail 
>> to host and tried to execute it to confirm binary was really bad and 
>> I got the same Abort trap message.
>>
>
> And one more interesting information is it builds fine with gcc. I 
> just added USE_GCC=yes to the port and it worked.
>
if you inspect the output of realpath /usr/bin/cc i think we are close 
to a cause.. it includes /basejail in my setup.. if you copy cc out of 
basejail e.g /usr/local/bin and make CC=/usr/local/bin it also works..

perhaps some linking  of msgbind fails because of "wrong" realpath...


From nobody Tue Aug 30 17:19:55 2022
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 4MHDZj1Yb0z4ZwZt
	for ; Tue, 30 Aug 2022 17:19:57 +0000 (UTC)
	(envelope-from jsm@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MHDZj10nhz3CbY;
	Tue, 30 Aug 2022 17:19:57 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661879997;
	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=sBwRTNvTgJNuij5CavVnXRkMy891pjgVjkmu0AX+t6M=;
	b=ZmZfkvdEJII5M8ft3Ll8FRgWcYWegbX1iiNODg+7QI1Xexfl5+/dWGx2TaYnxUrqPSaDZp
	jvOzT2Wv7cYBc+Y0YP2mcHvF2TgUBwBn8Q80zn7zdPRb2W7ytIZergylHzPfIq2Uw1yrFS
	RtsNI6C3p+/8Q+tArq297pp620c1DS8eTHYh0WyN/WSB8M5wYvcDIh74ZmWFdxj0pn0y8a
	ds7dRB17mBFXReouTATvbOa3mksGRbWcTqpCpHY/g8LZPlbTQjHXlhkUPoLcwEePxgiuNc
	AIivpZoWwsct6QC50+MrvofvTZ2uEJqYVNE0n03+QdYJ929LlKTYE6d3sL2+rg==
Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: jsm)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MHDZh3yTtz1P4y;
	Tue, 30 Aug 2022 17:19:56 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
Message-ID: <63bd8a64-33a7-64b7-8014-6ac936c56668@FreeBSD.org>
Date: Tue, 30 Aug 2022 19:19:55 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: archivers/arj fails to build on jail
Content-Language: en-US
From: Jesper Schmitz Mouridsen 
To: Renato Botelho ,
 Current FreeBSD 
Cc: erdgeist@erdgeist.org
References: <9636d41e-bf21-8130-ff15-e5dcbaaa4fe8@FreeBSD.org>
 <430844d1-ae2f-90d2-eec7-646c848e084f@FreeBSD.org>
 <74388082-ea84-564c-44ee-f1a568b75d5b@FreeBSD.org>
 
 
 
 <503d2719-4942-3d2e-b6c8-7fcd91f4fe4a@FreeBSD.org>
In-Reply-To: <503d2719-4942-3d2e-b6c8-7fcd91f4fe4a@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661879997;
	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=sBwRTNvTgJNuij5CavVnXRkMy891pjgVjkmu0AX+t6M=;
	b=kR/NLf98XKP4W/QglQjBVr/MJimGnUpPz0WdC7DV7JJ3T+8DMVYcTfeWVAzMfamCDrgEuK
	xIjOTFI2X9O8xaXzruKmq51HqSuee2/agbTDcNvrsHp2s8NxLRbYwQGpQXQqQK3d9EwcTl
	AoHZbe/17ry5d/vpW5g0WaejRW9ZTZVf5l1lK5m96jla6E7yQnD8u/a3kqbeOzq+cCODOv
	fpiRbBXQRm9AM9QKYof5mqa0zMejsL0HzIRs0SsBgxAW5QD3MvNOYu2Fnyiw2JxeRT3UmP
	RNfXV6YHEEf9mPHBdYlOgoCFrJal58YQkU4QGB1VoIlewE0XFSPmF6XdDdH9UQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661879997; a=rsa-sha256; cv=none;
	b=IYgUN8ROtUqiJlRUHQOcJPehdm2zCQhEjyAPleO/cXXyQ0t6rm+wuZpk3jcJENPetBRrTk
	lRJoKW0RBGic1J6tRn4WxjZxvpmT2em9EOm5urx1vXs2V9MHeAd9aE+IjiLTvEWkmiYXK4
	sQTluwdXsNWEG1mYuNYzrJ+2dLaNCFRXhpt0Vh9d4YFMdPj5aN6E0Bb8KriO469G3llD0X
	IRrcjWbxLLh7O24MYaKUuumk7O5Uw1LGiLK1PuNMGaT2Wl4goINc47Xx4Vv05GX6J/TnnN
	mjSYoWhtzuu6Zs+MD3zuePnEO4q3uA4iWlMbFxjHodg3CWdVT0wuhcSUV3Q8Mw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N



On 30.08.2022 18.45, Jesper Schmitz Mouridsen wrote:
> 
> On 30.08.2022 18.03, Renato Botelho wrote:
>> On 30/08/22 12:39, Renato Botelho wrote:
>>> On 30/08/22 11:35, Jesper Schmitz Mouridsen wrote:
>>>>
>>>> On 30.08.2022 13.17, Renato Botelho wrote:
>>>>> On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote:
>>>>>>
>>>>>>
>>>>>> On 29.08.2022 17.29, Renato Botelho wrote:
>>>>>>> There is a PR [1] opened for years reporting arj fails to build 
>>>>>>> on a jail.  Recently I reproduced it on a system running CURRENT.
>>>>>>>
>>>>>>> I just launched a jail and tried to build it, and got the error 
>>>>>>> as described:
>>>>>> Did you use ezjail?
>>>>>>
>>>>>> I tried to replicate and I think the error is triggered by
>>>>>> the nullfs usage of ezjail. I copied the settings of ezjail without
>>>>>> nullfs usage (using the basejail as path adding etc from the 
>>>>>> failing jail to it and removing the fstab from jail.conf) and arj 
>>>>>> did get a working msgbind.
>>>>>
>>>>> Yes, I also use ezjail.  I'm cc'ing ezjail's maintainer to see if 
>>>>> we can get some advice.
>>>>>
>>>>> Thanks!
>>>>>
>>>> Hi again.
>>>>
>>>>
>>>> I narrowed this down to  symlinks ,wiithin the jail, to the nullfs 
>>>> mountpoint.
>>>>
>>>> Replacing symlinks to the basejail mount point with dirs and setting 
>>>> this in the fstab of the jail
>>>>
>>>> and msgbind is a valid executable
>>>>
>>>> /usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0
>>>> /usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0
>>>> /usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0
>>>> /usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0
>>>> /usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0
>>>> /usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0
>>>> /usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0
>>>> /usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0
>>>> /usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs 
>>>> ro 0 0
>>>> /usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0
>>>> /usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0
>>>> /usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs 
>>>> ro 0 0
>>>> /usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0
>>>> /usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0
>>>> /usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs 
>>>> ro 0 0
>>>> /usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0
>>>>
>>>> It should be further narrowed down but nullfs alone is not the issue.
>>>
>>> Interesting.  And just to add a note here, I copied msgbind from jail 
>>> to host and tried to execute it to confirm binary was really bad and 
>>> I got the same Abort trap message.
>>>
>>
>> And one more interesting information is it builds fine with gcc. I 
>> just added USE_GCC=yes to the port and it worked.
>>
> if you inspect the output of realpath /usr/bin/cc i think we are close 
> to a cause.. it includes /basejail in my setup.. if you copy cc out of 
> basejail e.g /usr/local/bin and make CC=/usr/local/bin it also works..
> 
> perhaps some linking  of msgbind fails because of "wrong" realpath...

That even manifests without a jail so moving /usr/bin to 
/something/usr/bin and having /usr/bin as a śyḿlink to 
/something/usr/bin breaks the port


From nobody Tue Aug 30 18:58:17 2022
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 4MHGmC5CwXz4b6Tq
	for ; Tue, 30 Aug 2022 18:58:19 +0000 (UTC)
	(envelope-from jsm@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MHGmC4ScKz3P5N;
	Tue, 30 Aug 2022 18:58:19 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661885899;
	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=McJsvo7CP8bklxWyF1Rr9FfQ/eExm80JnMpCnfAaVNQ=;
	b=GnkebPea+AAIMvOt1q3zSCJGvrwq1TDlT0qLwFCD2QpPhsJmp+NIGK2yA0VZC+MZ2uejn0
	7UtVhzvnjloBYEJmG6Zo0vNvxz8v4T9TM7oUXWzEG+YMlw+eNtDbYGAyRcnMF4JcJ1k8O8
	TsnnOz6mu2W7keK2+Fyl0MhpZzh9TSfRakuEbJnqX5VFBrZ6rmXBt9FXctzX8eBuhiN7Uo
	8+3N3B5A3d1K9IVbz6Ct2jAUJGLUazIDTVAVmDPzFxfD1QC2JkT4kcdXdev1kQEiQ51odD
	ORV0jqAmolTGLpYd6RgPBYJFlvYVUEJ77hgTSZbKc53kr5G512nruKRkRbcEnQ==
Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202])
	(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: jsm)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MHGmC0Pvbz1NyK;
	Tue, 30 Aug 2022 18:58:18 +0000 (UTC)
	(envelope-from jsm@FreeBSD.org)
Message-ID: 
Date: Tue, 30 Aug 2022 20:58:17 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: archivers/arj fails to build on jail
Content-Language: en-US
From: Jesper Schmitz Mouridsen 
To: Renato Botelho ,
 Current FreeBSD 
Cc: erdgeist@erdgeist.org
References: <9636d41e-bf21-8130-ff15-e5dcbaaa4fe8@FreeBSD.org>
 <430844d1-ae2f-90d2-eec7-646c848e084f@FreeBSD.org>
 <74388082-ea84-564c-44ee-f1a568b75d5b@FreeBSD.org>
 
 
 
 <503d2719-4942-3d2e-b6c8-7fcd91f4fe4a@FreeBSD.org>
In-Reply-To: <503d2719-4942-3d2e-b6c8-7fcd91f4fe4a@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661885899;
	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=McJsvo7CP8bklxWyF1Rr9FfQ/eExm80JnMpCnfAaVNQ=;
	b=RCPa8Kp5KJSfb5pxKC12dD17dMK7dpr/S+ujvFaf/vGijGaEhiqtPXIfi7GbscWSaANxXx
	0EBJ3UtpaHS1B5JbRQG7xXdxOK8POg+Czq6ZlOQQ4tFw1bKni+hD7y8sEVGB5BR08iV/lX
	xL++90aVtee8Nw4S55lQNj5sD2219mJNoMgaYVZy2XWYY80g/sg6tKzy31JMyWJhuhcqIF
	mM+c6c7N+EJSLSiTmHrL3Y49s3eNfuTKWjlqyiJEa2K3EdqoMszgYfn/wvAMDImT6N4/+r
	TJlRzE7skwz3M2aPrixu9o/+o87EE/QuzGd6WPIN/f+kuzuivORtLMVUBLa1wQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661885899; a=rsa-sha256; cv=none;
	b=BHp3HjNmZG9bmTPoJ7ZMQd45WWlQwbN5yi0he3TOqbD9PVAVJ/lKkKTT5bpMaqW5tuOwJg
	AFqQwVQNwZA9oD5Z5WoSPk6n+ciOo04LjLD4KwCBGT3Y0y3kVi9KvUWoaJHRYL4e62E3Ds
	m28IDKciYz9ELP2Iiz6MJMqG/zgksvHge2RqmHzlDanyTfaQ6cdpYf41sB4T/PEf9yQcsI
	34VHLC6GdrfU+UEbOXviCep+brV2ws6js+XYGXUiaQmRYY54Wj50I3Yovz3RdMTL5p7IYe
	PCIti0vwONdrO7HXKmY5wWtqsQiKteyiOMfsJDpu4QqooGC+1HgcwhdqXc896g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

A rude patch.

--- Makefile.orig       2022-08-30 22:43:09.142346000 +0200
+++ Makefile    2022-08-30 22:44:54.509741000 +0200
@@ -60,6 +60,7 @@
         @${REINPLACE_CMD} -e 's!-O2!!' -e 's!ALIGN_POINTERS!&,1,desc!' \
                 -e 's!USE_COLORS!&,1,desc!' ${WRKSRC}/gnu/configure.in
         @${REINPLACE_CMD} -e 's!^static !!' ${WRKSRC}/integr.c
+       @${REINPLACE_CMD} -e s/'LD_STRIP="gnu\/stripgcc.lnk"'/''/ 
${WRKSRC}/gnu/configure.in

  post-install:
         @${MKDIR} ${STAGEDIR}${DOCSDIR}


On 30.08.2022 18.45, Jesper Schmitz Mouridsen wrote:
> 
> On 30.08.2022 18.03, Renato Botelho wrote:
>> On 30/08/22 12:39, Renato Botelho wrote:
>>> On 30/08/22 11:35, Jesper Schmitz Mouridsen wrote:
>>>>
>>>> On 30.08.2022 13.17, Renato Botelho wrote:
>>>>> On 29/08/22 20:32, Jesper Schmitz Mouridsen wrote:
>>>>>>
>>>>>>
>>>>>> On 29.08.2022 17.29, Renato Botelho wrote:
>>>>>>> There is a PR [1] opened for years reporting arj fails to build 
>>>>>>> on a jail.  Recently I reproduced it on a system running CURRENT.
>>>>>>>
>>>>>>> I just launched a jail and tried to build it, and got the error 
>>>>>>> as described:
>>>>>> Did you use ezjail?
>>>>>>
>>>>>> I tried to replicate and I think the error is triggered by
>>>>>> the nullfs usage of ezjail. I copied the settings of ezjail without
>>>>>> nullfs usage (using the basejail as path adding etc from the 
>>>>>> failing jail to it and removing the fstab from jail.conf) and arj 
>>>>>> did get a working msgbind.
>>>>>
>>>>> Yes, I also use ezjail.  I'm cc'ing ezjail's maintainer to see if 
>>>>> we can get some advice.
>>>>>
>>>>> Thanks!
>>>>>
>>>> Hi again.
>>>>
>>>>
>>>> I narrowed this down to  symlinks ,wiithin the jail, to the nullfs 
>>>> mountpoint.
>>>>
>>>> Replacing symlinks to the basejail mount point with dirs and setting 
>>>> this in the fstab of the jail
>>>>
>>>> and msgbind is a valid executable
>>>>
>>>> /usr/jails/basejail/bin /usr/jails/test1/bin nullfs ro 0 0
>>>> /usr/jails/basejail/boot /usr/jails/test1/boot nullfs ro 0 0
>>>> /usr/jails/basejail/lib /usr/jails/test1/lib nullfs ro 0 0
>>>> /usr/jails/basejail/libexec /usr/jails/test1/libexec nullfs ro 0 0
>>>> /usr/jails/basejail/rescue /usr/jails/test1/rescue nullfs ro 0 0
>>>> /usr/jails/basejail/sbin /usr/jails/test1/sbin nullfs ro 0 0
>>>> /usr/jails/basejail/usr/bin /usr/jails/test1/usr/bin nullfs ro 0 0
>>>> /usr/jails/basejail/usr/lib /usr/jails/test1/usr/lib nullfs ro 0 0
>>>> /usr/jails/basejail/usr/include /usr/jails/test1/usr/include nullfs 
>>>> ro 0 0
>>>> /usr/jails/basejail/usr/lib32 /usr/jails/test1/usr/lib32 nullfs ro 0 0
>>>> /usr/jails/basejail/usr/ports /usr/jails/test1/usr/ports nullfs ro 0 0
>>>> /usr/jails/basejail/usr/libdata /usr/jails/test1/usr/libdata nullfs 
>>>> ro 0 0
>>>> /usr/jails/basejail/usr/sbin /usr/jails/test1/usr/sbin nullfs ro 0 0
>>>> /usr/jails/basejail/usr/share /usr/jails/test1/usr/share nullfs ro 0 0
>>>> /usr/jails/basejail/usr/libexec /usr/jails/test1/usr/libexec nullfs 
>>>> ro 0 0
>>>> /usr/jails/basejail/usr/src /usr/jails/test1/usr/src nullfs ro 0 0
>>>>
>>>> It should be further narrowed down but nullfs alone is not the issue.
>>>
>>> Interesting.  And just to add a note here, I copied msgbind from jail 
>>> to host and tried to execute it to confirm binary was really bad and 
>>> I got the same Abort trap message.
>>>
>>
>> And one more interesting information is it builds fine with gcc. I 
>> just added USE_GCC=yes to the port and it worked.
>>
> if you inspect the output of realpath /usr/bin/cc i think we are close 
> to a cause.. it includes /basejail in my setup.. if you copy cc out of 
> basejail e.g /usr/local/bin and make CC=/usr/local/bin it also works..
> 
> perhaps some linking  of msgbind fails because of "wrong" realpath...
> 
> 

From nobody Thu Sep  1 00:00:08 2022
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 4MJ1Q03vLHz4bjZ7;
	Thu,  1 Sep 2022 00:00:08 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MJ1Q02hDvz3sqx;
	Thu,  1 Sep 2022 00:00:08 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1661990408;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=;
	b=G1LDVHAoU8THrSlO73FFeIjz46KPvYokMnNWcLsHF6i9z5I7DwpE1pdN5bcDUld11coFL2
	D3BnFaUvMYSmBpU5KNDwbiNwW6QZRu/H+Dj6evMlNcrnlpOeEE59cm8FTcx0eQgiO2ud3U
	ICd36xTgFn7/lgozer72gJ/GE+MxGRKO8SFWc0tIJjj/Rm1Gf22mo9VACQL9NFVxyrweaR
	io1nwYbmuWo2sPDroJbpOQu0Wc/SGE7cbmZhEW/+7PExKkcA2x3iBg5Lldah0nsDVadRkh
	vOJ/Qd6a0yS6zbtJTIH0ruUHJNDTkdRjvllYCG6mPQcb/aT2PzW9WTGCWDUhkw==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id 34F3A173A9; Thu,  1 Sep 2022 00:00:08 +0000 (UTC)
To: freebsd-quarterly-calls@FreeBSD.org
Subject: Call for 2022Q3 quarterly status reports
Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org
Message-Id: <20220901000008.34F3A173A9@freefall.freebsd.org>
Date: Thu,  1 Sep 2022 00:00:08 +0000 (UTC)
From: Lorenzo Salvadore 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1661990408;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=;
	b=fGeHSZxYqCH/HXQujod2RBmG81zZena28K1aR/jY7idqy8hAM0bL4qcEEvDkKCpzsJhSO/
	HYyMI1ffXNRum7QQnpc6RgmaBv+Nq4m4cWDmUzUQN7YBAtcsxY1DYZzK9cSofnRKrwLLr7
	8RzdMniS0o8a5K30s99RI4cAoUNeZRU0rESxEQzMO3gkEhK9z7rwUEoYFPpqicoh+F7rKS
	Jzbb5eisaFKNmNPoFUTND/GHJ5rBvRiDc5odU6FnlL2/5qeYVydPBUL3f7eA9HeYKK4qUu
	yHauYiO4pJYKdcbAhiUqSR104eg+xBzfcTvAPM/cplQp4i4xC7FSItAnD4PBdw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661990408; a=rsa-sha256; cv=none;
	b=npiMCWPUzHLvEkmck/qhB1v3qhQBi4/qfV4yJWtp08ZyZTO3K1BLg5oCT2jIQj5DxGBi+g
	mqTLDntrGujKbGiHrjzc9N8GLfpYfvDrQQZuJMMRwtPSZyuq5wTBb0S8JLNRUAc01r+mdB
	Q8bSIyCQ/b8ZqdPOl3vMZyd68LUk1gz5j34d/GSnwpPfnxSnY/L8blpdlwiPkx76Lvn3TA
	qe4dhHiEQunMSy/mcRDF9IkHCMQv4jqyYQTSMTxHILSF6Bvq2eAaUIiohSVf68vgI+HI/C
	u7dgk/F0OeJ1V1zLqJ1q6Qlmo/H/gkwQ064iUiVXeFkp1Nr+VIrpUPIcKMO0hA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
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

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
September, 30th 2022 for work done since the last round of Quarterly Reports:
July 2022 - September 2022.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the AsciiDoctor template, fill it in, and
email it to quarterly-submissions@FreeBSD.org.
The new AsciiDoctor template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc

We look forward to seeing your 2022Q3 reports!

Thanks,

Lorenzo Salvadore (on behalf of quarterly@)

From nobody Fri Sep  2 12:05:37 2022
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 4MJxSh5pKZz4bsjg
	for ; Fri,  2 Sep 2022 12:05:40 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MJxSh0cx2z42sR
	for ; Fri,  2 Sep 2022 12:05:40 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: by mail-lj1-x22c.google.com with SMTP id z20so2047950ljq.3
        for ; Fri, 02 Sep 2022 05:05:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date;
        bh=bh+DR1bX4qi7vDCTGYx7+DVgEWjGuD8q49OxjnLJzTU=;
        b=UngdU7hd+UFnzADM2XHD0OMZAQjd8CohlbEAG0ZIAAoWb4sBVvaTQZO5E1agzcbnvp
         d/7KEHz+ozm2ITjbHDApbON0Y1HPmhaTD+FMOagKvgVWbqYA7g7I/DwazoSaJnA7inKY
         7E9l5FqjFyjzDvNQ+WR1I1dG0WOOBxC8cEYpie2ygy0+tdu7QYGtrnG7BjHqe15tBmyQ
         tR/UCjSOTcSkAqPcr9qoQAQo625MkuuSBIzM4iA4mfJjbEYOEV6dhcu0kxV7sp88B/wV
         9180tDU4A8qlTBc2eYW3IOImHwOM6W4exOkqdpcqnCjyCqU8xpUWwQHiMZw2JNW7hEak
         w8Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date;
        bh=bh+DR1bX4qi7vDCTGYx7+DVgEWjGuD8q49OxjnLJzTU=;
        b=z7HLJOIbWvhJGDmmrxxY+CUc6CpM6yiOAt/VZMxBaRcTa5DfDWUpqnZJI42UoMrVWq
         5wqOrfU31NUCgz2pdnOFQtjbNU3m1FdVMj7dSiI4MdWudxcXsSd/539tpfB3FyXLZtPO
         XPxJJtgRTA4JoA5I3T+t2qqohKe5oBW0rBLpw7UuSEo6B2dgeUZ7UCJIETYKdobllipi
         8Z+mN7RNFDkgWldtQ1eWA5lhf/jPieJ3p9xuACq5fBjPw2bDHiLfI5Ef5TD0eAQcZYjX
         H3WWcvUPlU0PCkgFaLVLfeNFW+mhxIwuf+wM5zDOW9M7LunP1hWG/amMkpBooZF6PE58
         H2nA==
X-Gm-Message-State: ACgBeo3LUhT4GA+Jx/tdS1ErjefinZ3gvrebelUCtU9Ha6LhYAIncYp+
	UHTrnugr7/hLsNYj5bGhhtfh4Y9tHaT1GzgQXcIka+Jh
X-Google-Smtp-Source: AA6agR7mSJN/8/PJ7XJUDDfwB6Z2Ld60N0DNekeil13IsILT9wDuZ01fc3uIE3UD1pwKtIm/cD8AgBaD26z3IC3/ccY=
X-Received: by 2002:a2e:bc06:0:b0:266:23b7:283d with SMTP id
 b6-20020a2ebc06000000b0026623b7283dmr6535600ljf.151.1662120337716; Fri, 02
 Sep 2022 05:05:37 -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
Received: by 2002:a05:6520:14d:b0:211:6cae:be17 with HTTP; Fri, 2 Sep 2022
 05:05:37 -0700 (PDT)
From: Mateusz Guzik 
Date: Fri, 2 Sep 2022 14:05:37 +0200
Message-ID: 
Subject: kernel-side thread stack swapping
To: freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MJxSh0cx2z42sR
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=UngdU7hd;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) smtp.mailfrom=mjguzik@gmail.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22c:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

Is this really of practical use today?

I have a WIP patch which needs to temporarily store something on the
stack and should things go wrong enough it will be accessed by UMA,
which can't handle the fault nor decide to skip the access.

I can add something like td_pinstack or whatever to keep it around,
but perhaps the entire machinery can be just whacked?

-- 
Mateusz Guzik 

From nobody Fri Sep  2 14:06:02 2022
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 4MK07j6JRHz4Zg2g
	for ; Fri,  2 Sep 2022 14:06:09 +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 4MK07j1l1Tz3F01
	for ; Fri,  2 Sep 2022 14:06:09 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 282E622X040640
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 2 Sep 2022 17:06:05 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 282E62dU040639;
	Fri, 2 Sep 2022 17:06:02 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Fri, 2 Sep 2022 17:06:02 +0300
From: Konstantin Belousov 
To: Mateusz Guzik 
Cc: freebsd-current@freebsd.org
Subject: Re: kernel-side thread stack swapping
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=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home
X-Rspamd-Queue-Id: 4MK07j1l1Tz3F01
X-Spamd-Bar: -
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
X-Spamd-Result: default: False [-1.95 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.95)[-0.951];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none];
	FREEMAIL_FROM(0.00)[gmail.com];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	TO_DN_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	HAS_XAW(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Sep 02, 2022 at 02:05:37PM +0200, Mateusz Guzik wrote:
> Is this really of practical use today?
> 
> I have a WIP patch which needs to temporarily store something on the
> stack and should things go wrong enough it will be accessed by UMA,
> which can't handle the fault nor decide to skip the access.
> 
> I can add something like td_pinstack or whatever to keep it around,
> but perhaps the entire machinery can be just whacked?
p_hold already does that.

From nobody Fri Sep  2 14:11:40 2022
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 4MK0G81rfKz4Zh2B
	for ; Fri,  2 Sep 2022 14:11:44 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MK0G74TxZz3GMv
	for ; Fri,  2 Sep 2022 14:11:43 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: by mail-lj1-x22d.google.com with SMTP id r27so1974124ljn.0
        for ; Fri, 02 Sep 2022 07:11:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc:subject:date;
        bh=L+DOZd8lKYgIiKDKlg25yb0PeJlqQWAFsATC84UgqRw=;
        b=Py6JNccxbGkO1hzsTkjgg3LCsYjHF8jXBoxOu/LftJgIYW0FNR0l84Jebe6B9mHceI
         45AGKLVTNCdTQEazM4TnVl8uOqTKJPyt2+im53PJ14bTW4+vID24jue81eDo7opHyTRN
         Mx7gDZwRT8pCfY1tYp5n0bVHAP+o9Mo97k+6TMtPXK9j70TsclhsMuJSzIkyXEy2eQ68
         moqAdKJRbRklNJIdVGHXZjW5uFojK0GoGC8HJsvnL+0rPm1I2CuFUr5FjGM8ozp7s3Iz
         F2TaMYzEciq6wYunEQqXu4wKwVN/nFG8xV9KYEMjlUxdtSVXO3TW+yxKUlGbyCQ4mlJ9
         Gh3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=L+DOZd8lKYgIiKDKlg25yb0PeJlqQWAFsATC84UgqRw=;
        b=y/xg9LKc5I/VVO2htjEHOOzwxfShJYySophVwfpKCMRww8zCQTSs5pqZCuOqPzR2DA
         N8PK/C+IKnVpAY4sC6hqi/+SI+V6Sgv4j8eDexH3lptfMrgqkbtX1Widzf/bY0jzbwv/
         84NqPm/vndcqOr/cRX2GnSaRZg70jXlQoVCv/c8p7XEHPtYKwIyNBzBoaI8wsc9vsZTO
         Qfk5gKDmnKXshrJebGZ+iEQBgSwdTU/WJDwOg9SWU9OqDtJNmv0Ct9sODGO3lrFaRl3W
         CLL+exs8KsW+//wFdJvwnEPEGMB4SEwX5n1zkxkdahXiKqWM0gdu5Dmw0a7P7jFLrUHm
         gNHg==
X-Gm-Message-State: ACgBeo0H6OQ5MqJxxg6I3/LVnpkn+YhfNWirPHBB224L6oYRRKI66BkS
	1somCkASli6TQ5lSeaj+1Wp1RPFg7dmoNPFFl/RHv/TG
X-Google-Smtp-Source: AA6agR4BLdV4KZ3yZRK5QhV+VXeCOZFEToZ4TzPemPU0l6iV+rMFlf9EMYUchRo419h+wsweEi5N7FePmJ6aaUkNVls=
X-Received: by 2002:a2e:aa1c:0:b0:268:fd46:e590 with SMTP id
 bf28-20020a2eaa1c000000b00268fd46e590mr432887ljb.206.1662127901673; Fri, 02
 Sep 2022 07:11:41 -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
Received: by 2002:a05:6520:14d:b0:211:6cae:be17 with HTTP; Fri, 2 Sep 2022
 07:11:40 -0700 (PDT)
In-Reply-To: 
References: 
 
From: Mateusz Guzik 
Date: Fri, 2 Sep 2022 16:11:40 +0200
Message-ID: 
Subject: Re: kernel-side thread stack swapping
To: Konstantin Belousov 
Cc: freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MK0G74TxZz3GMv
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Py6JNccx;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::22d as permitted sender) smtp.mailfrom=mjguzik@gmail.com
X-Spamd-Result: default: False [-2.40 / 15.00];
	NEURAL_HAM_MEDIUM(-0.98)[-0.977];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	NEURAL_HAM_SHORT(-0.42)[-0.418];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22d:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCPT_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_COUNT_THREE(0.00)[3];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 9/2/22, Konstantin Belousov  wrote:
> On Fri, Sep 02, 2022 at 02:05:37PM +0200, Mateusz Guzik wrote:
>> Is this really of practical use today?
>>
>> I have a WIP patch which needs to temporarily store something on the
>> stack and should things go wrong enough it will be accessed by UMA,
>> which can't handle the fault nor decide to skip the access.
>>
>> I can add something like td_pinstack or whatever to keep it around,
>> but perhaps the entire machinery can be just whacked?
> p_hold already does that.
>

I only need to protect the one stack and more importantly don't want
to take the proc lock to bump p_hold (nor convert it to atomics), it's
all thread-local so to speak.

-- 
Mateusz Guzik 

From nobody Fri Sep  2 14:17:04 2022
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 4MK0NS01t9z4Zhrp
	for ; Fri,  2 Sep 2022 14:17:12 +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 4MK0NR0yH9z3KY3
	for ; Fri,  2 Sep 2022 14:17:10 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 282EH4bK043177
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 2 Sep 2022 17:17:07 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 282EH4lL043176;
	Fri, 2 Sep 2022 17:17:04 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Fri, 2 Sep 2022 17:17:04 +0300
From: Konstantin Belousov 
To: Mateusz Guzik 
Cc: freebsd-current@freebsd.org
Subject: Re: kernel-side thread stack swapping
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=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home
X-Rspamd-Queue-Id: 4MK0NR0yH9z3KY3
X-Spamd-Bar: --
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
X-Spamd-Result: default: False [-2.95 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.99)[-0.987];
	NEURAL_HAM_SHORT(-0.97)[-0.968];
	DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FREEMAIL_FROM(0.00)[gmail.com];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	HAS_XAW(0.00)[];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Sep 02, 2022 at 04:11:40PM +0200, Mateusz Guzik wrote:
> On 9/2/22, Konstantin Belousov  wrote:
> > On Fri, Sep 02, 2022 at 02:05:37PM +0200, Mateusz Guzik wrote:
> >> Is this really of practical use today?
> >>
> >> I have a WIP patch which needs to temporarily store something on the
> >> stack and should things go wrong enough it will be accessed by UMA,
> >> which can't handle the fault nor decide to skip the access.
> >>
> >> I can add something like td_pinstack or whatever to keep it around,
> >> but perhaps the entire machinery can be just whacked?
> > p_hold already does that.
> >
> 
> I only need to protect the one stack and more importantly don't want
> to take the proc lock to bump p_hold (nor convert it to atomics), it's
> all thread-local so to speak.

You do not want to take proc lock, or cannot?  Note that only sleeping
thread' stack can be swapped out.

From nobody Fri Sep  2 14:26:16 2022
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 4MK0Zz1YKjz4Zk1c
	for ; Fri,  2 Sep 2022 14:26:19 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MK0Zy4ChCz3MRw
	for ; Fri,  2 Sep 2022 14:26:18 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: by mail-lj1-x234.google.com with SMTP id k22so2451143ljg.2
        for ; Fri, 02 Sep 2022 07:26:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc:subject:date;
        bh=DxFcGWSc57uGvKtL7PtpVKc75BnmyPT3uqftHh7jFeU=;
        b=gSWxxwUKMxlxTRgjCuOFzeGSOy7sgYyCMWw7QkXvZSmO0MjbyDKvFhlnRbAZjQEAPb
         cRmPD5d22UCiKCQcTRwYlS91mCPzzd90OizyjnEpyp/xbcmAMmSrkuc/UYGyT+0Isw3W
         tI2tRLYcZDPV315cr8QjCWRUro8Gb31eVq0yDzT54sX8r1d/2nvahU54TyzI3JDjz/SC
         pVHlVo4QdLBhzMg/vKJ7z2aeA/6r/FvNFYekywXJZmeYrhooJe6QFZO36wzXPp0f60UF
         s5TNEhURxKt/AzHkmCADsZwuC55bz/PBlZ3rDA0tImRaU7lAajumtQHaq+ttQCkh7m54
         apuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=DxFcGWSc57uGvKtL7PtpVKc75BnmyPT3uqftHh7jFeU=;
        b=Dk7B3W180mSZNFrrPybqBZWZrcXKMx4QNEpn1LMtuu9nSiK26KonTmpB8SaQXXWWHc
         KbB44HOXfHlD+znAYE7SjrrISBv1XQzCv5uYUlefeQQBOg6MRKDs63NS3OjrIIKb/8cs
         hfMc9NCJptAbc33xtW1TCj2GjBWbTTJR+rt5AmKnLES+d5QIJEl24Ep5UhkF9R92GeNG
         3Z7bT3Y5uKxp60uM3aFok2GQ+pVoKyNyVNWHgA1agkO7WFh6OLvnLeFDnTXdfSmJ8Yw1
         fHJVb3e9vtI172A+qd1CSFmr1zIqs6TLpRRQltgCx17DB8EgK0ZLNFDgihk7iDjssmJq
         WeZQ==
X-Gm-Message-State: ACgBeo37c2s0fuxMr0aC6fIclkQWgHX0rTHiGEwFzHnbIG+YrE8dJ1Uk
	bmldM6FV+97VKuCtekgEHRgjjYeqMbUs5aK0gAI=
X-Google-Smtp-Source: AA6agR7Wdz1e+aiFbsbBiYgtVsPQfaBzr0wH1mMHb6ENPYdw57Nq5KvtlU7iY9zCMAYmiDPo04vTKVzIrkXYivwDqio=
X-Received: by 2002:a2e:bc06:0:b0:266:23b7:283d with SMTP id
 b6-20020a2ebc06000000b0026623b7283dmr6711340ljf.151.1662128777044; Fri, 02
 Sep 2022 07:26:17 -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
Received: by 2002:a05:6520:14d:b0:211:6cae:be17 with HTTP; Fri, 2 Sep 2022
 07:26:16 -0700 (PDT)
In-Reply-To: 
References: 
  
 
From: Mateusz Guzik 
Date: Fri, 2 Sep 2022 16:26:16 +0200
Message-ID: 
Subject: Re: kernel-side thread stack swapping
To: Konstantin Belousov 
Cc: freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MK0Zy4ChCz3MRw
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=gSWxxwUK;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::234 as permitted sender) smtp.mailfrom=mjguzik@gmail.com
X-Spamd-Result: default: False [-3.98 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	NEURAL_HAM_MEDIUM(-0.98)[-0.982];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::234:from];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_TO(0.00)[gmail.com];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 9/2/22, Konstantin Belousov  wrote:
> On Fri, Sep 02, 2022 at 04:11:40PM +0200, Mateusz Guzik wrote:
>> On 9/2/22, Konstantin Belousov  wrote:
>> > On Fri, Sep 02, 2022 at 02:05:37PM +0200, Mateusz Guzik wrote:
>> >> Is this really of practical use today?
>> >>
>> >> I have a WIP patch which needs to temporarily store something on the
>> >> stack and should things go wrong enough it will be accessed by UMA,
>> >> which can't handle the fault nor decide to skip the access.
>> >>
>> >> I can add something like td_pinstack or whatever to keep it around,
>> >> but perhaps the entire machinery can be just whacked?
>> > p_hold already does that.
>> >
>>
>> I only need to protect the one stack and more importantly don't want
>> to take the proc lock to bump p_hold (nor convert it to atomics), it's
>> all thread-local so to speak.
>
> You do not want to take proc lock, or cannot?  Note that only sleeping
> thread' stack can be swapped out.
>

To add some context here I'm looking at reworking vnode batching in
vdrop -> vdbatch_enqueue to remove vnode interlock -> vdbatch lock ->
vnode list lock dependency (and improve scalability of the thing).

Adding a proc lock here would negatively affect performance for
everyone *and* weirdly serialize same-proc consumers.

-- 
Mateusz Guzik 

From nobody Sat Sep  3 16:19:12 2022
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 4MKg313T76z4bpPm
	for ; Sat,  3 Sep 2022 16:19:25 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MKg302gRFz3fKl
	for ; Sat,  3 Sep 2022 16:19:24 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: by mail-qk1-f176.google.com with SMTP id a10so3838000qkl.13
        for ; Sat, 03 Sep 2022 09:19:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date;
        bh=4950GfzXLuqs1VOJgflb2hHQLDLETSH3JYpRj3nLdOA=;
        b=gxzzh5XTaP+Qac6zykopqExWYs0ck73oQOxSBvxU+8NqydlizrVumhT6icbNYRyL9M
         pe+KyGUFXbj8sqzEqQJWIpPa1H6t3r+9geqDR3jeSffLhxoL+R18oqZqLpublpCX1CtB
         DkX1tF3+8rhXl6bIAUcPPz3ngxXQ7Xek6u88xDIM/H1R7KWAdvYOiRhw05Ttdk4hn4Cu
         T6aBWff/GjzuX8SPdzmF7gFUkjwoc+Hh8iMEUQ9QekF70B2c7NSeWvV8s+Wm01K0AJnQ
         5F2g5E+w3sT+RVulTYcGYokDt81yoTIYzmfrR7XfLe9gS5jdPa7FwKReTxQRe8HmRLm/
         JL2w==
X-Gm-Message-State: ACgBeo1//ZlLnNnQa8rTn6P4G0aRLlfaFEFqDYkJMHsySKR+2fijXYNA
	s9VjuY/tgwi5dWfzln1jAnJFSKMo+lfJPOrfWpLzpi+rNcI=
X-Google-Smtp-Source: AA6agR4mZmn9ZAPwmWzCHICUHojxQm9cLtA5qVCGa3c/ynUPLituXEbfwNd7BFo9rFl6Bkt2Prr+H/mO18cYXri1hIw=
X-Received: by 2002:a05:620a:b04:b0:6ba:e707:b245 with SMTP id
 t4-20020a05620a0b0400b006bae707b245mr27655499qkg.418.1662221962841; Sat, 03
 Sep 2022 09:19:22 -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: Alan Somers 
Date: Sat, 3 Sep 2022 10:19:12 -0600
Message-ID: 
Subject: Header symbols that shouldn't be visible to ports?
To: FreeBSD CURRENT 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MKg302gRFz3fKl
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.176 as permitted sender) smtp.mailfrom=asomers@gmail.com
X-Spamd-Result: default: False [-1.94 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.94)[-0.945];
	FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[text/plain];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DMARC_NA(0.00)[freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.222.176:from];
	FROM_HAS_DN(0.00)[];
	TO_DOM_EQ_FROM_DOM(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.176:from];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	R_DKIM_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FREEFALL_USER(0.00)[asomers];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

Our /usr/include headers define a lot of symbols that are used by
critical utilities in the base system like ps and ifconfig, but aren't
stable across major releases.  Since they aren't stable, utilities
built for older releases won't run correctly on newer ones.  Would it
make sense to guard these symbols so they can't be used by programs in
the ports tree?  There is some precedent for that, for example
_WANT_SOCKET and _WANT_MNTOPTNAMES.

I'm particular, I'm thinking about symbols like the following:
MINCORE_SUPER
TDF_*
PRI_MAX*
PRI_MIN*
PI_*, PRIBIO, PVFS, etc
IFCAP_*
RLIM_NLIMITS
IFF_*
*_MAXID

Clearly delineating private symbols like this would ease the
maintenance burden on languages that rely on FFI, like Ruby and Rust.
FFI basically assumes that symbols once defined will never change.

-Alan

From nobody Sun Sep  4 05:09:53 2022
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 4ML08B6cfNz4bSTb
	for ; Sun,  4 Sep 2022 05:10:02 +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 4ML0894WZtz3k5Y;
	Sun,  4 Sep 2022 05:10:01 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 28459rPI020140
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 4 Sep 2022 08:09:56 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 28459rUC020139;
	Sun, 4 Sep 2022 08:09:53 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Sun, 4 Sep 2022 08:09:53 +0300
From: Konstantin Belousov 
To: Alan Somers 
Cc: FreeBSD CURRENT 
Subject: Re: Header symbols that shouldn't be visible to ports?
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=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home
X-Rspamd-Queue-Id: 4ML0894WZtz3k5Y
X-Spamd-Bar: -
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
X-Spamd-Result: default: False [-1.92 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.98)[-0.979];
	NEURAL_HAM_SHORT(-0.94)[-0.937];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	HAS_XAW(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> Our /usr/include headers define a lot of symbols that are used by
> critical utilities in the base system like ps and ifconfig, but aren't
> stable across major releases.  Since they aren't stable, utilities
> built for older releases won't run correctly on newer ones.  Would it
> make sense to guard these symbols so they can't be used by programs in
> the ports tree?  There is some precedent for that, for example
> _WANT_SOCKET and _WANT_MNTOPTNAMES.
_WANT_SOCKET is clearly about exposing parts of the kernel definitions
for userspace code that wants to dig into kernel structures.  Similarly
for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.  The
definitions are guarded by additional defines not due to their instability,
but because using them in userspace requires (much) more preparation from
userspace environment, which is either not trivial (_WANT_SOCKET) or
contradicts to standartized use of the header (_WANT_MNTOPTNAMES + 
sys/mount.h).

> 
> I'm particular, I'm thinking about symbols like the following:
> MINCORE_SUPER
Why this symbol should be hidden?  It is implementation-defined and
intended to be exposed to userspace.  All MINCORE_* not only MINCORE_SUPER
are under BSD_VISIBLE braces, because POSIX does not define the symbols.

> TDF_*
These symbols coming from non-standard header sys/proc.h.  If userspace
includes the header, it is already outside any formal standard, and I
do not see a reason to make the implementation more convoluted there.

> PRI_MAX*
> PRI_MIN*
> PI_*, PRIBIO, PVFS, etc
> IFCAP_*
These are all implementation-specific and come from non-standard headers,
unless I am mistaken, then please correct me.

> RLIM_NLIMITS
> IFF_*
Same.

> *_MAXID
This is too broad.

> 
> Clearly delineating private symbols like this would ease the
> maintenance burden on languages that rely on FFI, like Ruby and Rust.
> FFI basically assumes that symbols once defined will never change.

Why e.g. sys/proc.h is ever consumed by FFI wrappers?

From nobody Sun Sep  4 21:49:29 2022
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 4MLQLN4fNvz4bjpQ
	for ; Sun,  4 Sep 2022 21:50:20 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MLQLN1H5dz3XVN
	for ; Sun,  4 Sep 2022 21:50:20 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Received: by mail-io1-xd34.google.com with SMTP id h78so5634511iof.13
        for ; Sun, 04 Sep 2022 14:50:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :from:to:cc:subject:date;
        bh=vNiZ+OkC/eyJZrI6dF8ZIcJRhgKe3VJZ4rR/yG2AbYU=;
        b=qtJA1Spir4zABggvb/Wf2+sViBJIv2lBKUsI3LpEmFU/fogrJ4EI7pN5sxYsj4H2My
         t3kLk/clUcvA/aelGkMUETWNS6deEyrjI8GIoX7oaw89iGLlt2vNe/wvoAFC0ttC/5Vr
         TrGTl+DrE4b3cGQqZHGe1JUcmLbPoOk6hdCi5lIFRE+JSmxcxIoEeVeKqt3JyrvF0eM4
         N6ZLmnX9gwRI007Sy4xN18w+01Oy/9oj+j64eGDZkadx4jD2/lfHTLuVkyof3LYWyWYM
         cT3Ax9jf5yzyKLBMf0ENAcYwET6aLESaMQVQq2xdCAKYS0orJ/rKQkfMhtui10TwxPaJ
         buLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :x-gm-message-state:from:to:cc:subject:date;
        bh=vNiZ+OkC/eyJZrI6dF8ZIcJRhgKe3VJZ4rR/yG2AbYU=;
        b=5asXsFr9subUM6mQxwIyxygqfOB80qj4TbIviqt9HULHa7QYs7fsJ05HL+CfMz53tY
         tq7FJQIpghOeKXxL9/9pjUpfKC5E2y7LH6qdotG/50h3Hv4d04QGZMn+JvTFGCEmdoZP
         LosgRAja4CxeekoTgv9S7b93kbGH2qOcgoDx5b3NdkmIqK+oNeDgH/z7mynleyo39fH3
         pnoqfwX7ZCff149a4lhJ934L5ktIymjXFcCdCxi5+jSWoNvJXnzvm09J9JfHlbqS34Zs
         qzk6ymgPCa3oM0bJCPvibNoO+lo+sus8rN/lt6snCOx5rt3dP//0Thqht3kjS+RV84+1
         87+w==
X-Gm-Message-State: ACgBeo3GqeXVpLYlI9KCHzZqy4JV55QuRUmG5U5yQaARj+DY8xcsqaLd
	K5gS6AJ/NzG93Wop3jYE82PJXCRVrX+6uVPHssTC4XIC
X-Google-Smtp-Source: AA6agR4BOxjP5B1rX7Xk/Tts5LMTZog/0JgVkqBiQk5fm2lDNmzgHQeIKY/mHK0PB7zOvOP657UZytoitzgPqVWoAY4=
X-Received: by 2002:a05:6638:3010:b0:341:dda0:dcc5 with SMTP id
 r16-20020a056638301000b00341dda0dcc5mr23411143jak.210.1662328219312; Sun, 04
 Sep 2022 14:50:19 -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: 
 <2ba3e191-64c1-b854-3eb3-080345b56839@FreeBSD.org> <20220820181357.GA5624@darkbeer.org>
  <20220820184531.GA6367@darkbeer.org>
In-Reply-To: <20220820184531.GA6367@darkbeer.org>
From: Kevin Oberman 
Date: Sun, 4 Sep 2022 14:49:29 -0700
Message-ID: 
Subject: Re: Status of Alder Lake support
To: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000000329f205e7e0f3f9"
X-Rspamd-Queue-Id: 4MLQLN1H5dz3XVN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=qtJA1Spi;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::d34 as permitted sender) smtp.mailfrom=kob6558@gmail.com
X-Spamd-Result: default: False [-3.64 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.975];
	NEURAL_HAM_MEDIUM(-0.97)[-0.966];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d34:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000000329f205e7e0f3f9
Content-Type: text/plain; charset="UTF-8"

On Sat, Aug 20, 2022 at 11:45 AM Amar Takhar  wrote:

> On 2022-08-20 11:36 -0700, Kevin Oberman wrote:
> 
> > Wow! That's a little more disturbing.
>
> Especially since it's a i9-12900KF so I have a whole 8 cores disabled!
>
>
> > As to the audio issue, I've been having a similar issue for some time,
> > especially with Firefox using any of the available audio systems. Works
> best
> > with OSS.
> >
> > What I hear is not popping, but brief dropouts which I perceived as
> pops. It
> > sounds a lot like data rate mismatch where the audio is output at a
> slightly
> > faster rate than it is input.  As a result, the buffers empty
> periodically and
> > you hear a fraction of a second of silence.
>
> Yes exactly.  Sorry it's better described as clipping and that is exactly
> what I
> thought was happening too.  There were some suggestions in that ticket I
> tried
> to no avail.  It's almost like something is blocking the buffer from being
> filled.  The same issue happens when I use an external USB audio card but
> it's
> nowhere near as bad.
>
> After this many months I'd like to say I've gotten used to it but some
> videos
> are particularly bad so there is some correlation to what audio is being
> played.
>
>
> > This is not an Alder Lake issue as it's been hitting me on my Comet Lake
> > processor.
>
> Oh well that's good to know you should update that ticket (#263385) as
> I've only
> known Alder Lake to be an issue up to this point.
>
> Is this happening on CURRENT?  I'll upgrade for sure if I can use my E
> cores and
> avoid UFS corruption.
>
>
> Amar.
>

My Alder Lake has only run CURRENT as it is most likely going to get
graphics support and a fix for hte file system crashes first.

Sadly, disabling soft updates does not fix the problem. I got one more VFS
crash after disabling them. Still, a single dump while building around 1000
ports is a huge improvement! Having soft updates enabled clearly makes the
likelihood of a crash much greater. I have opened ticket 266145 on this
problem if you want to see if this goes anywhere. Since it looks like a mix
of performance and efficiency core will be hte norm from now on from both
Intel and AMD, this clearly will need some attention soon.
-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

--0000000000000329f205e7e0f3f9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Sat, Aug 20, 2022 at 11:45 A=
M Amar Takhar <verm@darkbeer.org> wrote:
On 2022-08-20 11:36 -0700, Kevin Oberman wrot=
e:

<snip>

> Wow! That's a little more disturbing.=C2=A0



Especially since it's a i9-12900KF so I have a whole 8 cores disabled!<=
br>




> As to the audio issue, I've been having a similar issue for some t=
ime,

> especially with Firefox using any of the available audio systems. Work=
s best

> with OSS.

> 

> What I hear is not popping, but brief dropouts which I perceived as po=
ps. It

> sounds a lot like data rate mismatch where the audio is output at a sl=
ightly

> faster rate than it is input.=C2=A0 As a result, the buffers empty per=
iodically and

> you hear a fraction of a second of silence.



Yes exactly.=C2=A0 Sorry it's better described as clipping and that is =
exactly what I 

thought was happening too.=C2=A0 There were some suggestions in that ticket=
 I tried 

to no avail.=C2=A0 It's almost like something is blocking the buffer fr=
om being 

filled.=C2=A0 The same issue happens when I use an external USB audio card =
but it's 

nowhere near as bad.



After this many months I'd like to say I've gotten used to it but s=
ome videos 

are particularly bad so there is some correlation to what audio is being pl=
ayed.





> This is not an Alder Lake issue as it's been hitting me on my Come=
t Lake

> processor.=C2=A0



Oh well that's good to know you should update that ticket (#263385) as =
I've only 

known Alder Lake to be an issue up to this point.



Is this happening on CURRENT?=C2=A0 I'll upgrade for sure if I can use =
my E cores and 

avoid UFS corruption.





Amar.



My Alder Lake has only run C=
URRENT as it is most likely going to get graphics support and a fix for hte=
 file system crashes first.

Sadly, disab=
ling soft updates does not fix the problem. I got one more VFS crash after =
disabling them. Still, a single dump while building around 1000 ports is a =
huge improvement! Having soft updates enabled clearly makes the likelihood =
of a crash much greater. I have opened ticket 266145 on this problem if you=
 want to see if this goes anywhere. Since it looks like a mix of performanc=
e and efficiency core will be hte norm from now on from both Intel and AMD,=
 this clearly will need some attention soon.
-- 


--0000000000000329f205e7e0f3f9--

From nobody Mon Sep  5 05:33:52 2022
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 4MLcdN3nRmz4cCMG
	for ; Mon,  5 Sep 2022 05:34:00 +0000 (UTC)
	(envelope-from verm@darkbeer.org)
Received: from mx.coeval.ca (mx.coeval.ca [184.75.211.21])
	(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 4MLcdM2g9dz46BB
	for ; Mon,  5 Sep 2022 05:33:59 +0000 (UTC)
	(envelope-from verm@darkbeer.org)
Received: from mx.darkbeer.org (unknown [192.168.211.20])
	by mx.coeval.ca (Postfix) with ESMTP id 5D14F43605C
	for ; Mon,  5 Sep 2022 05:33:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbeer.org; s=mail;
	t=1662356032; bh=OHtrR/9moCeQrSZVA17pdJw6WpdEYhBr/55CDi2bEyM=;
	h=Date:From:To:Subject:References:In-Reply-To;
	b=U+CiVw7xEP7SSUCuBKVdmb3TvU1+ULb1LzB1qCXShMpolaCbiOZgEeZ/KDJ7R6Pjn
	 Tp0BdL7up4zMIYDl8BfzV45XBr7FLras04icRn/iCzEtHIG0qiy2o75Hd9NdM5PynW
	 X+dklKbQHkKF4rlg6BFZ/uDVENphLjR/S8qrNB94=
Received: by mx.darkbeer.org (Postfix, from userid 1001)
	id 583DC470BFC; Mon,  5 Sep 2022 05:33:52 +0000 (UTC)
Date: Mon, 5 Sep 2022 05:33:52 +0000
From: Amar Takhar 
To: freebsd-current@freebsd.org
Subject: Re: Status of Alder Lake support
Message-ID: <20220905053352.GA12178@darkbeer.org>
Mail-Followup-To: freebsd-current@freebsd.org
References: 
 <2ba3e191-64c1-b854-3eb3-080345b56839@FreeBSD.org>
 <20220820181357.GA5624@darkbeer.org>
 
 <20220820184531.GA6367@darkbeer.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-Rspamd-Queue-Id: 4MLcdM2g9dz46BB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=darkbeer.org header.s=mail header.b=U+CiVw7x;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of verm@darkbeer.org designates 184.75.211.21 as permitted sender) smtp.mailfrom=verm@darkbeer.org
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.995];
	NEURAL_HAM_LONG(-0.99)[-0.995];
	R_SPF_ALLOW(-0.20)[+ip4:184.75.211.21];
	R_DKIM_ALLOW(-0.20)[darkbeer.org:s=mail];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[darkbeer.org:+];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[darkbeer.org];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:32489, ipnet:184.75.211.0/24, country:CA];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-09-04 14:49 -0700, Kevin Oberman wrote:
> On Sat, Aug 20, 2022 at 11:45 AM Amar Takhar  wrote:
> 
> My Alder Lake has only run CURRENT as it is most likely going to get graphics
> support and a fix for hte file system crashes first.

Mine is a i9-12900KF so no graphics card to worry about.


> Sadly, disabling soft updates does not fix the problem. I got one more VFS
> crash after disabling them. Still, a single dump while building around 1000
> ports is a huge improvement! Having soft updates enabled clearly makes the
> likelihood of a crash much greater. I have opened ticket 266145 on this problem
> if you want to see if this goes anywhere. Since it looks like a mix of
> performance and efficiency core will be hte norm from now on from both Intel
> and AMD, this clearly will need some attention soon.

Yes I had the same issues tonight using CURRENT as well.  Disabling soft updates 
did seem to make it happy for a bit longer but once it hits something on the 
filesystem it does not like it will consistently crash even across reboots.  In 
both cases it was an rm -rf of a directory with a lot of files (70k).

I did update that ticket thanks for opening one.


Amar.

From nobody Mon Sep  5 14:41:58 2022
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 4MLrnv6HHwz4cXZn
	for ; Mon,  5 Sep 2022 14:42:11 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MLrnv0CCzz3rLF
	for ; Mon,  5 Sep 2022 14:42:11 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: by mail-qk1-f178.google.com with SMTP id g16so6389095qkl.11
        for ; Mon, 05 Sep 2022 07:42:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=MrMFuCng7BW283AVm2kBKjNQtrdmpFjCQDfEfWP/Xwk=;
        b=UXHgPLIwsB3drt1DjFld+4yDjOQBZ2fY2PgVJn4SvM2XIjyOb4S+ZPKqod+QIjYSZ1
         SZgEoNoolT3Le6X6940EMFakyaGgl41rMrPrkauOqYDIAhchdrEmjEEXE6bwDhvu/g8n
         3KYRqKV97R+fv8/KfY2WWB50IZI9EzZsJvirx6aBJKER8xBU8+FoU8PJNVc1XPXjJ3jl
         Duhp44M2ZtJeMXv8rj3V/iHNG4VhX7+fZu4/vznTaawyQbjMdsUyH/LzmOK/bQ7cw8SR
         WwbsmcpD4sTU7CpccqRjwPiuX5svChT1fY7mxNiW9YEbzzXUVFgUz0sQmgdfDYAeZpAX
         WX7Q==
X-Gm-Message-State: ACgBeo1Twcf8rijBq6aVnYDPclxWPmecB3BahA8RwZ3x6fo+c6si3os5
	EsPQFbFzC8TcJqxkH3VNvk9zdqfNqqesNb/2BH5C/NwX55U=
X-Google-Smtp-Source: AA6agR6hCFgYnLuj9U+7QjdnsbG0IhCdTTChIgI2hoWlEPe5DOYfzK3PCIwcPooFnIWCiO+WduqQ3ukgpr7qmrxEHfs=
X-Received: by 2002:a05:620a:4104:b0:6bb:61ce:73a3 with SMTP id
 j4-20020a05620a410400b006bb61ce73a3mr32530096qko.250.1662388929884; Mon, 05
 Sep 2022 07:42:09 -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: Alan Somers 
Date: Mon, 5 Sep 2022 08:41:58 -0600
Message-ID: 
Subject: Re: Header symbols that shouldn't be visible to ports?
To: Konstantin Belousov 
Cc: FreeBSD CURRENT 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MLrnv0CCzz3rLF
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.178 as permitted sender) smtp.mailfrom=asomers@gmail.com
X-Spamd-Result: default: False [-1.71 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	NEURAL_HAM_MEDIUM(-0.72)[-0.721];
	FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.222.178:from];
	FREEFALL_USER(0.00)[asomers];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	FREEMAIL_TO(0.00)[gmail.com];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.178:from];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	R_DKIM_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov  wrote:
>
> On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> > Our /usr/include headers define a lot of symbols that are used by
> > critical utilities in the base system like ps and ifconfig, but aren't
> > stable across major releases.  Since they aren't stable, utilities
> > built for older releases won't run correctly on newer ones.  Would it
> > make sense to guard these symbols so they can't be used by programs in
> > the ports tree?  There is some precedent for that, for example
> > _WANT_SOCKET and _WANT_MNTOPTNAMES.
> _WANT_SOCKET is clearly about exposing parts of the kernel definitions
> for userspace code that wants to dig into kernel structures.  Similarly
> for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.  The
> definitions are guarded by additional defines not due to their instability,
> but because using them in userspace requires (much) more preparation from
> userspace environment, which is either not trivial (_WANT_SOCKET) or
> contradicts to standartized use of the header (_WANT_MNTOPTNAMES +
> sys/mount.h).
>
> >
> > I'm particular, I'm thinking about symbols like the following:
> > MINCORE_SUPER
> Why this symbol should be hidden?  It is implementation-defined and
> intended to be exposed to userspace.  All MINCORE_* not only MINCORE_SUPER
> are under BSD_VISIBLE braces, because POSIX does not define the symbols.

Because it isn't stable.  It changed for example in rev 847ab36bf22
for 13.0.  Programs using the older value (including virtually every
Rust program) won't work on 13.0 and later.

>
> > TDF_*
> These symbols coming from non-standard header sys/proc.h.  If userspace
> includes the header, it is already outside any formal standard, and I
> do not see a reason to make the implementation more convoluted there.
>
> > PRI_MAX*
> > PRI_MIN*
> > PI_*, PRIBIO, PVFS, etc
> > IFCAP_*
> These are all implementation-specific and come from non-standard headers,
> unless I am mistaken, then please correct me.
>
> > RLIM_NLIMITS
> > IFF_*
> Same.
>
> > *_MAXID
> This is too broad.

I'm talking about symbols like IPV6CTL_MAXID, which record the size of
sysctl lists.  Obviously, these symbols can't be stable, and probably
aren't useful outside of the base system.

>
> >
> > Clearly delineating private symbols like this would ease the
> > maintenance burden on languages that rely on FFI, like Ruby and Rust.
> > FFI basically assumes that symbols once defined will never change.
>
> Why e.g. sys/proc.h is ever consumed by FFI wrappers?

I should add a little detail.  Rust uses FFI to access C functions,
and #define'd constants are redefined in the Rust bindings.  For most
Rust programs, the build process doesn't check the contents of
/usr/include in any way.  Instead, all of that stuff is hard-coded in
the Rust bindings.  That makes cross-compiling a breeze!  But it does
cause problems when the C library changes.  Adding a new symbol, like
copy_file_range, isn't so bad.  If your Rust program doesn't use it,
then the Rust binding will become an unused symbol and get eliminated
by the linker.  If your Rust program does use it OTOH, then it will be
resolved by the dynamic linker at runtime - if you're running on
FreeBSD 13 or newer.  Otherwise, your program will fail to run.  A
bigger problem is with symbols that change.  For example, the 64-bit
inode stuff.  Rust programs still use a FreeBSD 11 ABI (we're working
on that).  But other symbols change more frequently.  Things like
PRI_MAX_REALTIME can change between any two releases.  That creates a
big maintenance burden to keep track of them in the FFI bindings.  And
they also aren't very useful in cross-compiled programs targeting a
FreeBSD 11 ABI.  Instead, they really need to have bindings
automatically generated at build time.  That's possible, but it's not
the default.

So what the Rust community really needs is a way to know which symbols
will be stable across releases, and which might vary.  Are you
suggesting that anything from a non-POSIX header file should be
considered variable?

From nobody Mon Sep  5 14:53:32 2022
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 4MLs361D53z4cYk2
	for ; Mon,  5 Sep 2022 14:53:38 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MLs350pKKz3tlk;
	Mon,  5 Sep 2022 14:53:37 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-il1-x12d.google.com with SMTP id k9so1569896ils.12;
        Mon, 05 Sep 2022 07:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:sender:from:to:cc:subject:date;
        bh=gEDLec3QbUzLipKlU2tkbcmA9TFoQ/2NMQlfHtEmg18=;
        b=hLOF6n5AwT4k0xbeMUO8NeCQ+St2CTrTTiFC4YEo+Tvu5YtP7NojB82DjV5+xZv8X9
         8nNJhz4TV7Qf2NO4Jp4UpljxmZwooNwTXgh/szwVldmnHCQnH13oxH2baFKBuhs+Hoob
         Z4sE/wYXrGqayS4FeOiZQ1atlY3dUQHIVK5+f3X0nmd9n5PkiWfQUIECNawIi21jTjMb
         sfAYyvm7gczJiXKA/rud7YQcQOAQ/dYc575k+D+Guj/MwBbJx3KH3pz6/S3gOo1LaAsr
         CelAk0WlWYOmTH1vqyABTFFwLXy7OJ8qfmpp7p5Ewr/5VANRki4yOEzHQ+zdzYTQ+gWe
         Ac9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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;
        bh=gEDLec3QbUzLipKlU2tkbcmA9TFoQ/2NMQlfHtEmg18=;
        b=Kpj/9SEBjKxBgTngS+4NvapoCvxGlB75YfjqELZewfUzSNCenPs67ipjf839IhCOTp
         Bf4VqtpASE8P1u7P2cbBjRiP5JEbRhBBxa4Qt5yR7TuqWZo5DcXVQOVvB48YDGSIeufH
         UCQusG/mfAew/V/fPMkQy400wuUFfJrGPKyN4E8cYKr1fTJJ0PiRQOv/8DX8GIoDO/Jp
         4egeTLPwht7msMdlKWcT6C8aChxlmCaVvFyXSzoUNrrzynHOel5AxLUgNCUTjJa12TKe
         yKpHh4jNTeP4Glsd98HtY4MuS925jRmLv+HmbkyWYuptz23JNjQrvnlTQeKcynKarmtg
         BRzA==
X-Gm-Message-State: ACgBeo3N8C0sW84lgxU540+9uG+QPAb/D9DndABzQQ4jyN8oKSrs3zVe
	1KoUMqJb0zK0FQDKmp5tAX2x/7juxAg=
X-Google-Smtp-Source: AA6agR7ywDAHM9v5YbaMIDVumiHTssNO+EmYgUTZHjx3VfDgcNoBusbmeTIsbtGNHjP9GNX1wNJFJw==
X-Received: by 2002:a92:c20f:0:b0:2ea:e8b5:ba16 with SMTP id j15-20020a92c20f000000b002eae8b5ba16mr18709268ilo.280.1662389615797;
        Mon, 05 Sep 2022 07:53:35 -0700 (PDT)
Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237])
        by smtp.gmail.com with ESMTPSA id z66-20020a0293c8000000b00342cb39de68sm4068491jah.130.2022.09.05.07.53.34
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 05 Sep 2022 07:53:35 -0700 (PDT)
Date: Mon, 5 Sep 2022 10:53:32 -0400
From: Mark Johnston 
To: Alan Somers 
Cc: Konstantin Belousov ,
	FreeBSD CURRENT 
Subject: Re: Header symbols that shouldn't be visible to ports?
Message-ID: 
References: 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4MLs350pKKz3tlk
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=hLOF6n5A;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::12d as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-1.52 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.82)[-0.825];
	MID_RHS_NOT_FQDN(0.50)[];
	FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12d:from];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Sep 05, 2022 at 08:41:58AM -0600, Alan Somers wrote:
> On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov  wrote:
> >
> > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> > > Our /usr/include headers define a lot of symbols that are used by
> > > critical utilities in the base system like ps and ifconfig, but aren't
> > > stable across major releases.  Since they aren't stable, utilities
> > > built for older releases won't run correctly on newer ones.  Would it
> > > make sense to guard these symbols so they can't be used by programs in
> > > the ports tree?  There is some precedent for that, for example
> > > _WANT_SOCKET and _WANT_MNTOPTNAMES.
> > _WANT_SOCKET is clearly about exposing parts of the kernel definitions
> > for userspace code that wants to dig into kernel structures.  Similarly
> > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.  The
> > definitions are guarded by additional defines not due to their instability,
> > but because using them in userspace requires (much) more preparation from
> > userspace environment, which is either not trivial (_WANT_SOCKET) or
> > contradicts to standartized use of the header (_WANT_MNTOPTNAMES +
> > sys/mount.h).
> >
> > >
> > > I'm particular, I'm thinking about symbols like the following:
> > > MINCORE_SUPER
> > Why this symbol should be hidden?  It is implementation-defined and
> > intended to be exposed to userspace.  All MINCORE_* not only MINCORE_SUPER
> > are under BSD_VISIBLE braces, because POSIX does not define the symbols.
> 
> Because it isn't stable.  It changed for example in rev 847ab36bf22
> for 13.0.  Programs using the older value (including virtually every
> Rust program) won't work on 13.0 and later.

Why won't they work?  Code that tests (vec[i] & MINCORE_SUPER) using the
old value will still give the same result when running on a newer
kernel, since MINCORE_PSIND(1) is 0x20, the old MINCORE_SUPER value.
This isn't to say that the change was perfectly backwards compatible,
but I haven't seen an example of code which was broken by the change.

From nobody Mon Sep  5 15:07:49 2022
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 4MLsMl134sz4cb7g
	for ; Mon,  5 Sep 2022 15:08:03 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MLsMk01yTz3wF2;
	Mon,  5 Sep 2022 15:08:02 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: by mail-qv1-f51.google.com with SMTP id s13so3369982qvq.10;
        Mon, 05 Sep 2022 08:08:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=aSemKmkJaRJgYfMCH3v4toQkWwyqWpdJSoCS+EiVst4=;
        b=nbkavKKvzLqlBIA+atHVa2Ft/zGpTHsgx0zj+3fhxN4fivLNDao9JLEW1echc0mlV/
         qJo01r+H+o4ymA56LSaehzymLj1qhfbzW0JrhvHqlMbb17WJrRvFny4u1VStRF03w2nx
         OeYLas8yHlcs8BfZrpRDRPSPpLgZVNiIe1W0dLuEJ9yQeSCKdFImouCOnMZ0FYMr/Rar
         pG5qZYadbIUvTYl2RiaFyBeQINJC9iT0apTMSo9SU/S5d77dLR8nwALYMu/skyZIiUiG
         5O/eljO9dEK/Tju9XeY33seGj6U+3iQQYGAhyAKLMPovrKx/bhg1z/h6U68FREzOEch6
         zZMw==
X-Gm-Message-State: ACgBeo1gXFIjo3lW9fZkCOgEYUn5IijS340zzNsw+uRDHne5vbqz2qH6
	HmDujFZVXAv6myQQ0dd9+WW64ivg7t5o75TfhVgTSlQpdho=
X-Google-Smtp-Source: AA6agR68kdKY6hbPqeXdEKSL62Ti5DOiXfwALkxkdiuv4hDGeApTHG0f1VLabZPdYNd017UC0SiewoWKTJGJ7A9AreI=
X-Received: by 2002:a05:6214:598c:b0:4a6:570d:9d20 with SMTP id
 ll12-20020a056214598c00b004a6570d9d20mr4235241qvb.94.1662390480243; Mon, 05
 Sep 2022 08:08:00 -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: Alan Somers 
Date: Mon, 5 Sep 2022 09:07:49 -0600
Message-ID: 
Subject: Re: Header symbols that shouldn't be visible to ports?
To: Mark Johnston 
Cc: Konstantin Belousov , FreeBSD CURRENT 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MLsMk01yTz3wF2
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.219.51 as permitted sender) smtp.mailfrom=asomers@gmail.com
X-Spamd-Result: default: False [-1.99 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	NEURAL_HAM_MEDIUM(-0.99)[-0.995];
	FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.51:from];
	R_DKIM_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.219.51:from];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FREEFALL_USER(0.00)[asomers];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[freebsd.org];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Sep 5, 2022 at 8:53 AM Mark Johnston  wrote:
>
> On Mon, Sep 05, 2022 at 08:41:58AM -0600, Alan Somers wrote:
> > On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov  wrote:
> > >
> > > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> > > > Our /usr/include headers define a lot of symbols that are used by
> > > > critical utilities in the base system like ps and ifconfig, but aren't
> > > > stable across major releases.  Since they aren't stable, utilities
> > > > built for older releases won't run correctly on newer ones.  Would it
> > > > make sense to guard these symbols so they can't be used by programs in
> > > > the ports tree?  There is some precedent for that, for example
> > > > _WANT_SOCKET and _WANT_MNTOPTNAMES.
> > > _WANT_SOCKET is clearly about exposing parts of the kernel definitions
> > > for userspace code that wants to dig into kernel structures.  Similarly
> > > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.  The
> > > definitions are guarded by additional defines not due to their instability,
> > > but because using them in userspace requires (much) more preparation from
> > > userspace environment, which is either not trivial (_WANT_SOCKET) or
> > > contradicts to standartized use of the header (_WANT_MNTOPTNAMES +
> > > sys/mount.h).
> > >
> > > >
> > > > I'm particular, I'm thinking about symbols like the following:
> > > > MINCORE_SUPER
> > > Why this symbol should be hidden?  It is implementation-defined and
> > > intended to be exposed to userspace.  All MINCORE_* not only MINCORE_SUPER
> > > are under BSD_VISIBLE braces, because POSIX does not define the symbols.
> >
> > Because it isn't stable.  It changed for example in rev 847ab36bf22
> > for 13.0.  Programs using the older value (including virtually every
> > Rust program) won't work on 13.0 and later.
>
> Why won't they work?  Code that tests (vec[i] & MINCORE_SUPER) using the
> old value will still give the same result when running on a newer
> kernel, since MINCORE_PSIND(1) is 0x20, the old MINCORE_SUPER value.
> This isn't to say that the change was perfectly backwards compatible,
> but I haven't seen an example of code which was broken by the change.

Well, from mincore(2):

In particular, applications compiled using the old value of
MINCORE_SUPER will not identify large pages with size index 2 as being
large pages.

From nobody Tue Sep  6 13:34:22 2022
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 4MMRFM4yxNz4bqFQ
	for ; Tue,  6 Sep 2022 13:34: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 4MMRFL5C5Kz3y1Y;
	Tue,  6 Sep 2022 13:34:30 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 286DYM0R059621
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 6 Sep 2022 16:34:25 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 286DYMNK059620;
	Tue, 6 Sep 2022 16:34:22 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Tue, 6 Sep 2022 16:34:22 +0300
From: Konstantin Belousov 
To: Alan Somers 
Cc: FreeBSD CURRENT 
Subject: Re: Header symbols that shouldn't be visible to ports?
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=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home
X-Rspamd-Queue-Id: 4MMRFL5C5Kz3y1Y
X-Spamd-Bar: -
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
X-Spamd-Result: default: False [-2.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	HAS_XAW(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Sep 05, 2022 at 08:41:58AM -0600, Alan Somers wrote:
> On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov  wrote:
> >
> > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> > > Our /usr/include headers define a lot of symbols that are used by
> > > critical utilities in the base system like ps and ifconfig, but aren't
> > > stable across major releases.  Since they aren't stable, utilities
> > > built for older releases won't run correctly on newer ones.  Would it
> > > make sense to guard these symbols so they can't be used by programs in
> > > the ports tree?  There is some precedent for that, for example
> > > _WANT_SOCKET and _WANT_MNTOPTNAMES.
> > _WANT_SOCKET is clearly about exposing parts of the kernel definitions
> > for userspace code that wants to dig into kernel structures.  Similarly
> > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.  The
> > definitions are guarded by additional defines not due to their instability,
> > but because using them in userspace requires (much) more preparation from
> > userspace environment, which is either not trivial (_WANT_SOCKET) or
> > contradicts to standartized use of the header (_WANT_MNTOPTNAMES +
> > sys/mount.h).
> >
> > >
> > > I'm particular, I'm thinking about symbols like the following:
> > > MINCORE_SUPER
> > Why this symbol should be hidden?  It is implementation-defined and
> > intended to be exposed to userspace.  All MINCORE_* not only MINCORE_SUPER
> > are under BSD_VISIBLE braces, because POSIX does not define the symbols.
> 
> Because it isn't stable.  It changed for example in rev 847ab36bf22
> for 13.0.  Programs using the older value (including virtually every
> Rust program) won't work on 13.0 and later.
As Mark replied, older values still mostly work.  It was considered to
not make unacceptable ABI change.

> 
> >
> > > TDF_*
> > These symbols coming from non-standard header sys/proc.h.  If userspace
> > includes the header, it is already outside any formal standard, and I
> > do not see a reason to make the implementation more convoluted there.
> >
> > > PRI_MAX*
> > > PRI_MIN*
> > > PI_*, PRIBIO, PVFS, etc
> > > IFCAP_*
> > These are all implementation-specific and come from non-standard headers,
> > unless I am mistaken, then please correct me.
> >
> > > RLIM_NLIMITS
> > > IFF_*
> > Same.
> >
> > > *_MAXID
> > This is too broad.
> 
> I'm talking about symbols like IPV6CTL_MAXID, which record the size of
> sysctl lists.  Obviously, these symbols can't be stable, and probably
> aren't useful outside of the base system.
The programs are not forced to use the symbols.  FFI bindings should not
provide them, why do we need to specifically hide such defines?

> 
> >
> > >
> > > Clearly delineating private symbols like this would ease the
> > > maintenance burden on languages that rely on FFI, like Ruby and Rust.
> > > FFI basically assumes that symbols once defined will never change.
> >
> > Why e.g. sys/proc.h is ever consumed by FFI wrappers?
> 
> I should add a little detail.  Rust uses FFI to access C functions,
> and #define'd constants are redefined in the Rust bindings.  For most
> Rust programs, the build process doesn't check the contents of
> /usr/include in any way.  Instead, all of that stuff is hard-coded in
> the Rust bindings.  That makes cross-compiling a breeze!
Well, at the cost of the maintaining Rust libc crate.
[Sorry, cannot refrain https://kib.kiev.ua/kib/rust_c_ffi.png ]

> But it does
> cause problems when the C library changes.  Adding a new symbol, like
> copy_file_range, isn't so bad.  If your Rust program doesn't use it,
> then the Rust binding will become an unused symbol and get eliminated
> by the linker.  If your Rust program does use it OTOH, then it will be
> resolved by the dynamic linker at runtime - if you're running on
> FreeBSD 13 or newer.  Otherwise, your program will fail to run.
The program would either fail at start if it does not reference the
symbol version in some other way (due to other symbol), or at runtime
when trying to do dynamic binding to that symbol otherwise.

> A
> bigger problem is with symbols that change.  For example, the 64-bit
> inode stuff.  Rust programs still use a FreeBSD 11 ABI (we're working
> on that).
We did not changed symbols for ino64.  Old symbols were retained, the new
symbols were added under the new version.

> But other symbols change more frequently.  Things like
> PRI_MAX_REALTIME can change between any two releases.  That creates a
> big maintenance burden to keep track of them in the FFI bindings.  And
> they also aren't very useful in cross-compiled programs targeting a
> FreeBSD 11 ABI.  Instead, they really need to have bindings
> automatically generated at build time.  That's possible, but it's not
> the default.
> 
> So what the Rust community really needs is a way to know which symbols
> will be stable across releases, and which might vary.
Symbols, as something exported from libc/libthr/libm, are stable.
We promise this and follow this promise strictly from FreeBSD 6.x.

Some defines from headers are not stable, but they do not form the exported
system ABI anyway.  You need to know what you are doing when changing libc.
Similarly, when you update Rust libc crate, you have to know what you are
providing, it cannot be done automatically.

Expecting that we (FreeBSD developers) would mark up each definition in
the headers files is unreasonable.  Even if this enormous work would be
done once, it rot immediately.  The outcome of the work is not used by
anything in either the base system, or in 99.999% of the ports.  As result,
anybody doing any work on the base libraries, make mistakes.

> Are you
> suggesting that anything from a non-POSIX header file should be
> considered variable?
No, I suggest that anything not in POSIX namespace should be scrutinized
for ABI stability, instead of stating that 'it is available, so lets make
bindings for it'.

I have the sympathy for Rust decision to provide isolated libc crate.
It certainly makes sense for the Rust ecosystem.

But then having this crate to depend on autogeneration from /usr/include
negates the intent of isolation.  I think, if you want to have
automatic binding generation used, you must provide the white list of
symbols and definitions that go into the crate.

From nobody Tue Sep  6 15:07:21 2022
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 4MMTJl0YGbz4c16L
	for ; Tue,  6 Sep 2022 15:07:35 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MMTJk2p3Qz4623
	for ; Tue,  6 Sep 2022 15:07:34 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x936.google.com with SMTP id s5so4449410uar.1
        for ; Tue, 06 Sep 2022 08:07:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=kIk9hr+28Jf1EdYY5P+lc4Th0woLqhAnSmDF3E+MVps=;
        b=Dp4bCbVoLJJrT36wQxNcAuuIpthcnr0hIxUZ2HRJ1A8WanqfJdM91cYy5/Drj/sqkd
         u5MnQkCVsVpRCOmcT3CcSLwcaSZiEpBP1AiLxWkkvnXJ4+8oxHChDkRwED3q/kEyyyuT
         JOzc7wt5G1kq5OmvVNPCANOEn53oiikiON2odG4qAKMryNK+6BWLHnnVKLpT0DxYCqag
         E0Dc8ykMqGr6ni+Bg4mSc0kJZnoA6FHcRSpt4GUmAb4V7lPFywc3sKIg/Lo2OC4JYIdJ
         Q1OHx+CUr68bmwNSuwiEipl7ydtRDHxEya68K0XFdv5P45nDk9iqd36xoUcXrECD/RZy
         uORQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=kIk9hr+28Jf1EdYY5P+lc4Th0woLqhAnSmDF3E+MVps=;
        b=Bmj8i0s7ITPpwkEy7fImzX0rp7qmj+moTLEUBRQOQjGUC1xi4EpDJQ95nkuUbfqf8i
         F551xZae2kCBYwjr7Ubm3eZ2sfQkeGQme9b6WVKLGebhHgMrFEmUHwdfJnW6XrvtL/sy
         Pa/li9jH9EiXLgUn+3wrf3kDc1lVi3MT+osLkYfzgoMZWhKorrZjHJi9Mcc5sqHaL1C3
         qjvA+iZkGINqygzO/g1zGS4POUeetrMfCCA3IoQxf5PBuY5+DODEh2KMHWObgn1sisQz
         +GfUuXSvZLDsHPmM7GM/HHvEffMcPqVlObB0FrBt+ilH6aV6EtUF5dJWLI1X+tEcuMLq
         cUZA==
X-Gm-Message-State: ACgBeo3IMMHx8eyua3z2Z6zCoejqLXO9HcVXAYNRPf8Q1307pqnxMWNd
	cguj5QcKv01s4JlQjfVIxcNks1+oI66W0tWR8xPEC1/n8N7uvg==
X-Google-Smtp-Source: AA6agR6iYEgMJtSmzOERdviSifQX/7aIOPtmHyDm0a3ojC/4On/EqAB9nbCOCZCVN1VV73q1CASoFRct3vXm96FmbbI=
X-Received: by 2002:a9f:2067:0:b0:387:984d:4a8e with SMTP id
 94-20020a9f2067000000b00387984d4a8emr16293970uam.60.1662476852440; Tue, 06
 Sep 2022 08:07:32 -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: Tue, 6 Sep 2022 09:07:21 -0600
Message-ID: 
Subject: Re: Header symbols that shouldn't be visible to ports?
To: Konstantin Belousov 
Cc: Alan Somers , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000003cc41d05e8038e3f"
X-Rspamd-Queue-Id: 4MMTJk2p3Qz4623
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Dp4bCbVo;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::936) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::936:from];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000003cc41d05e8038e3f
Content-Type: text/plain; charset="UTF-8"

On Tue, Sep 6, 2022 at 7:34 AM Konstantin Belousov 
wrote:

> On Mon, Sep 05, 2022 at 08:41:58AM -0600, Alan Somers wrote:
> > On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov 
> wrote:
> > >
> > > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> > > > Our /usr/include headers define a lot of symbols that are used by
> > > > critical utilities in the base system like ps and ifconfig, but
> aren't
> > > > stable across major releases.  Since they aren't stable, utilities
> > > > built for older releases won't run correctly on newer ones.  Would it
> > > > make sense to guard these symbols so they can't be used by programs
> in
> > > > the ports tree?  There is some precedent for that, for example
> > > > _WANT_SOCKET and _WANT_MNTOPTNAMES.
> > > _WANT_SOCKET is clearly about exposing parts of the kernel definitions
> > > for userspace code that wants to dig into kernel structures.  Similarly
> > > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.  The
> > > definitions are guarded by additional defines not due to their
> instability,
> > > but because using them in userspace requires (much) more preparation
> from
> > > userspace environment, which is either not trivial (_WANT_SOCKET) or
> > > contradicts to standartized use of the header (_WANT_MNTOPTNAMES +
> > > sys/mount.h).
> > >
> > > >
> > > > I'm particular, I'm thinking about symbols like the following:
> > > > MINCORE_SUPER
> > > Why this symbol should be hidden?  It is implementation-defined and
> > > intended to be exposed to userspace.  All MINCORE_* not only
> MINCORE_SUPER
> > > are under BSD_VISIBLE braces, because POSIX does not define the
> symbols.
> >
> > Because it isn't stable.  It changed for example in rev 847ab36bf22
> > for 13.0.  Programs using the older value (including virtually every
> > Rust program) won't work on 13.0 and later.
> As Mark replied, older values still mostly work.  It was considered to
> not make unacceptable ABI change.
>
> >
> > >
> > > > TDF_*
> > > These symbols coming from non-standard header sys/proc.h.  If userspace
> > > includes the header, it is already outside any formal standard, and I
> > > do not see a reason to make the implementation more convoluted there.
> > >
> > > > PRI_MAX*
> > > > PRI_MIN*
> > > > PI_*, PRIBIO, PVFS, etc
> > > > IFCAP_*
> > > These are all implementation-specific and come from non-standard
> headers,
> > > unless I am mistaken, then please correct me.
> > >
> > > > RLIM_NLIMITS
> > > > IFF_*
> > > Same.
> > >
> > > > *_MAXID
> > > This is too broad.
> >
> > I'm talking about symbols like IPV6CTL_MAXID, which record the size of
> > sysctl lists.  Obviously, these symbols can't be stable, and probably
> > aren't useful outside of the base system.
> The programs are not forced to use the symbols.  FFI bindings should not
> provide them, why do we need to specifically hide such defines?
>
> >
> > >
> > > >
> > > > Clearly delineating private symbols like this would ease the
> > > > maintenance burden on languages that rely on FFI, like Ruby and Rust.
> > > > FFI basically assumes that symbols once defined will never change.
> > >
> > > Why e.g. sys/proc.h is ever consumed by FFI wrappers?
> >
> > I should add a little detail.  Rust uses FFI to access C functions,
> > and #define'd constants are redefined in the Rust bindings.  For most
> > Rust programs, the build process doesn't check the contents of
> > /usr/include in any way.  Instead, all of that stuff is hard-coded in
> > the Rust bindings.  That makes cross-compiling a breeze!
> Well, at the cost of the maintaining Rust libc crate.
> [Sorry, cannot refrain https://kib.kiev.ua/kib/rust_c_ffi.png ]
>
> > But it does
> > cause problems when the C library changes.  Adding a new symbol, like
> > copy_file_range, isn't so bad.  If your Rust program doesn't use it,
> > then the Rust binding will become an unused symbol and get eliminated
> > by the linker.  If your Rust program does use it OTOH, then it will be
> > resolved by the dynamic linker at runtime - if you're running on
> > FreeBSD 13 or newer.  Otherwise, your program will fail to run.
> The program would either fail at start if it does not reference the
> symbol version in some other way (due to other symbol), or at runtime
> when trying to do dynamic binding to that symbol otherwise.
>
> > A
> > bigger problem is with symbols that change.  For example, the 64-bit
> > inode stuff.  Rust programs still use a FreeBSD 11 ABI (we're working
> > on that).
> We did not changed symbols for ino64.  Old symbols were retained, the new
> symbols were added under the new version.
>
> > But other symbols change more frequently.  Things like
> > PRI_MAX_REALTIME can change between any two releases.  That creates a
> > big maintenance burden to keep track of them in the FFI bindings.  And
> > they also aren't very useful in cross-compiled programs targeting a
> > FreeBSD 11 ABI.  Instead, they really need to have bindings
> > automatically generated at build time.  That's possible, but it's not
> > the default.
> >
> > So what the Rust community really needs is a way to know which symbols
> > will be stable across releases, and which might vary.
> Symbols, as something exported from libc/libthr/libm, are stable.
> We promise this and follow this promise strictly from FreeBSD 6.x.
>
> Some defines from headers are not stable, but they do not form the exported
> system ABI anyway.  You need to know what you are doing when changing libc.
> Similarly, when you update Rust libc crate, you have to know what you are
> providing, it cannot be done automatically.
>

FreeBSD developers get this wrong from time to time. We have to carefully
curate
new symbols to the libraires, and deal with #defines that are part of the
core ABI that
we've kept stable. We don't have any formal tests here to ensure things
work, apart
from people trying things and having them break due to some oversight.

For example, recently, the CAM ioctls changed so that old passthrough CCB
ioctls
stopped working. It took months for people to notice. It was broken in a
release. The
fix was a trivial one-liner once someone noticed and made the effort. Since
there was
no automation to test it, it went unnoticed.


> Expecting that we (FreeBSD developers) would mark up each definition in
> the headers files is unreasonable.  Even if this enormous work would be
> done once, it rot immediately.  The outcome of the work is not used by
> anything in either the base system, or in 99.999% of the ports.  As result,
> anybody doing any work on the base libraries, make mistakes.
>
> > Are you
> > suggesting that anything from a non-POSIX header file should be
> > considered variable?
> No, I suggest that anything not in POSIX namespace should be scrutinized
> for ABI stability, instead of stating that 'it is available, so lets make
> bindings for it'.
>
> I have the sympathy for Rust decision to provide isolated libc crate.
> It certainly makes sense for the Rust ecosystem.
>
> But then having this crate to depend on autogeneration from /usr/include
> negates the intent of isolation.  I think, if you want to have
> automatic binding generation used, you must provide the white list of
> symbols and definitions that go into the crate.
>

I agree with kib: I don't see how asking developers to know, a priori,
which of our unstable interfaces will change and which won't.  If you import
things that aren't in the POSIX namespace, you need to work with those
namespace providers to import them properly. Whitelisting is the only way
that I see it working.

At most, we have resources to allow you to maintain this list, and allow you
to make changes on a best effort basis that history has suggested will be
about 90% successful. Absent some automation that enforces it, it will
break.
And even with automation, you'll need someone to review breakage and/or
additions to ensure the right things get updated. Developers might be able
to lend a hand, but that can't be relied upon without oversight to work.

Warner

--0000000000003cc41d05e8038e3f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Sep 6, 2022 at 7:34 AM Konsta=
ntin Belousov <kostikbel@gmail.co=
m> wrote:
On Mon, Sep 05, 2022 at 08:41:58AM -0600, Alan Somers wrote:

> On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov <kostikbel@gmail.com> wrot=
e:

> >

> > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:

> > > Our /usr/include headers define a lot of symbols that are us=
ed by

> > > critical utilities in the base system like ps and ifconfig, =
but aren't

> > > stable across major releases.=C2=A0 Since they aren't st=
able, utilities

> > > built for older releases won't run correctly on newer on=
es.=C2=A0 Would it

> > > make sense to guard these symbols so they can't be used =
by programs in

> > > the ports tree?=C2=A0 There is some precedent for that, for =
example

> > > _WANT_SOCKET and _WANT_MNTOPTNAMES.

> > _WANT_SOCKET is clearly about exposing parts of the kernel defini=
tions

> > for userspace code that wants to dig into kernel structures.=C2=
=A0 Similarly

> > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.=C2=
=A0 The

> > definitions are guarded by additional defines not due to their in=
stability,

> > but because using them in userspace requires (much) more preparat=
ion from

> > userspace environment, which is either not trivial (_WANT_SOCKET)=
 or

> > contradicts to standartized use of the header (_WANT_MNTOPTNAMES =
+

> > sys/mount.h).

> >

> > >

> > > I'm particular, I'm thinking about symbols like the =
following:

> > > MINCORE_SUPER

> > Why this symbol should be hidden?=C2=A0 It is implementation-defi=
ned and

> > intended to be exposed to userspace.=C2=A0 All MINCORE_* not only=
 MINCORE_SUPER

> > are under BSD_VISIBLE braces, because POSIX does not define the s=
ymbols.

> 

> Because it isn't stable.=C2=A0 It changed for example in rev 847ab=
36bf22

> for 13.0.=C2=A0 Programs using the older value (including virtually ev=
ery

> Rust program) won't work on 13.0 and later.

As Mark replied, older values still mostly work.=C2=A0 It was considered to=


not make unacceptable ABI change.



> 

> >

> > > TDF_*

> > These symbols coming from non-standard header sys/proc.h.=C2=A0 I=
f userspace

> > includes the header, it is already outside any formal standard, a=
nd I

> > do not see a reason to make the implementation more convoluted th=
ere.

> >

> > > PRI_MAX*

> > > PRI_MIN*

> > > PI_*, PRIBIO, PVFS, etc

> > > IFCAP_*

> > These are all implementation-specific and come from non-standard =
headers,

> > unless I am mistaken, then please correct me.

> >

> > > RLIM_NLIMITS

> > > IFF_*

> > Same.

> >

> > > *_MAXID

> > This is too broad.

> 

> I'm talking about symbols like IPV6CTL_MAXID, which record the siz=
e of

> sysctl lists.=C2=A0 Obviously, these symbols can't be stable, and =
probably

> aren't useful outside of the base system.

The programs are not forced to use the symbols.=C2=A0 FFI bindings should n=
ot

provide them, why do we need to specifically hide such defines?



> 

> >

> > >

> > > Clearly delineating private symbols like this would ease the=


> > > maintenance burden on languages that rely on FFI, like Ruby =
and Rust.

> > > FFI basically assumes that symbols once defined will never c=
hange.

> >

> > Why e.g. sys/proc.h is ever consumed by FFI wrappers?

> 

> I should add a little detail.=C2=A0 Rust uses FFI to access C function=
s,

> and #define'd constants are redefined in the Rust bindings.=C2=A0 =
For most

> Rust programs, the build process doesn't check the contents of

> /usr/include in any way.=C2=A0 Instead, all of that stuff is hard-code=
d in

> the Rust bindings.=C2=A0 That makes cross-compiling a breeze!

Well, at the cost of the maintaining Rust libc crate.

[Sorry, cannot refrain https://kib.kiev.ua/kib/rust_c_ffi.png<=
/a> ]



> But it does

> cause problems when the C library changes.=C2=A0 Adding a new symbol, =
like

> copy_file_range, isn't so bad.=C2=A0 If your Rust program doesn=
9;t use it,

> then the Rust binding will become an unused symbol and get eliminated<=
br>
> by the linker.=C2=A0 If your Rust program does use it OTOH, then it wi=
ll be

> resolved by the dynamic linker at runtime - if you're running on
> FreeBSD 13 or newer.=C2=A0 Otherwise, your program will fail to run.
The program would either fail at start if it does not reference the

symbol version in some other way (due to other symbol), or at runtime

when trying to do dynamic binding to that symbol otherwise.



> A

> bigger problem is with symbols that change.=C2=A0 For example, the 64-=
bit

> inode stuff.=C2=A0 Rust programs still use a FreeBSD 11 ABI (we're=
 working

> on that).

We did not changed symbols for ino64.=C2=A0 Old symbols were retained, the =
new

symbols were added under the new version.



> But other symbols change more frequently.=C2=A0 Things like

> PRI_MAX_REALTIME can change between any two releases.=C2=A0 That creat=
es a

> big maintenance burden to keep track of them in the FFI bindings.=C2=
=A0 And

> they also aren't very useful in cross-compiled programs targeting =
a

> FreeBSD 11 ABI.=C2=A0 Instead, they really need to have bindings

> automatically generated at build time.=C2=A0 That's possible, but =
it's not

> the default.

> 

> So what the Rust community really needs is a way to know which symbols=


> will be stable across releases, and which might vary.

Symbols, as something exported from libc/libthr/libm, are stable.

We promise this and follow this promise strictly from FreeBSD 6.x.



Some defines from headers are not stable, but they do not form the exported=


system ABI anyway.=C2=A0 You need to know what you are doing when changing =
libc.

Similarly, when you update Rust libc crate, you have to know what you are
providing, it cannot be done automatically.

=

FreeBSD developers get this wrong from time to time. We have to carefu=
lly curate
new symbols to the libraires, and deal with #defines t=
hat are part of the core ABI that
we've kept stable. We don&#=
39;t have any formal tests here to ensure things work, apart
from=
 people trying things and having them break due to some oversight.


Expecting that we (FreeBSD developers) would mark up each definition in

the headers files is unreasonable.=C2=A0 Even if this enormous work would b=
e

done once, it rot immediately.=C2=A0 The outcome of the work is not used by=


anything in either the base system, or in 99.999% of the ports.=C2=A0 As re=
sult,

anybody doing any work on the base libraries, make mistakes.



> Are you

> suggesting that anything from a non-POSIX header file should be

> considered variable?

No, I suggest that anything not in POSIX namespace should be scrutinized
for ABI stability, instead of stating that 'it is available, so lets ma=
ke

bindings for it'.



I have the sympathy for Rust decision to provide isolated libc crate.

It certainly makes sense for the Rust ecosystem.



But then having this crate to depend on autogeneration from /usr/include
negates the intent of isolation.=C2=A0 I think, if you want to have

automatic binding generation used, you must provide the white list of

symbols and definitions that go into the crate.

I agree with kib: I don't see how asking developers to know, a=
 priori,
which of our unstable interfaces will change and which w=
on't.=C2=A0 If you import
things that aren't in the POSIX=
 namespace, you need to work with those
namespace providers to im=
port them properly. Whitelisting is the only way
that I see it wo=
rking.

At most, we have resources to allow you to =
maintain this list, and allow you
to make changes on a best effor=
t basis that history has suggested will be
about 90% successful. =
Absent some automation that enforces it, it will break.
And even =
with automation, you'll need someone to review breakage and/or
additions to ensure the right things get updated. Developers might be abl=
e
to lend a hand, but that can't be relied upon without overs=
ight to work.

Warner



--0000000000003cc41d05e8038e3f--

From nobody Tue Sep  6 16:36:52 2022
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 4MMWJ21ZcWz4c9WH
	for ; Tue,  6 Sep 2022 16:37:06 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MMWJ11ksTz3MRk
	for ; Tue,  6 Sep 2022 16:37:05 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: by mail-qt1-f174.google.com with SMTP id c20so8442346qtw.8
        for ; Tue, 06 Sep 2022 09:37:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=4Av/m1XT+t+lIiYg/DgcNHX1CCv7XMpRXUZ5BgN/Dvw=;
        b=qwCiXm9RjwbrXs89SR1KJgAs0+301NJLzsuq4sYqShgabt/IXI8LTSv9FvmAskjCsy
         bEsR+/4aeTKoEVI8IxngxYhS+1EseTpNVAbhb84VLaEmohCv25MiOHfaj5SZOCe8VliM
         ykwRI+ZX0T+eKlU2AV/KD9yqRKYZYay88HEZ9bn0ORnIiUooegPdAoF42AhAHbeH7rFK
         EDdamlMoAAtFEJ9caxNTntwM5TnmQYWq3B1ojWIoEkQQQ4HUys4BHNU6LhJDKwwU9dJK
         gf584K0tgU2oox6F9waGjDiCgskMdvy8Ej/TrbB8xoOFFSHY4mPr2N6nakrPJD8gE6LO
         UkyA==
X-Gm-Message-State: ACgBeo3UYu17/QYflkN1KA2Tl+xVWVmgjbsg9Rb8czgw4dmSOQCn3QMB
	u1m9EPyGyMrpJ4f0YhCkBERAZw+ON2TqynRZ3+Y=
X-Google-Smtp-Source: AA6agR7bee+7y+jYvOU5IP4SlFXQkd8JZ1diC6IsFp2CBVyj2dS74dmBni06RmHKmFWoN93UJdC6iWC+CqjOdasJ6Dc=
X-Received: by 2002:a05:622a:52:b0:344:7021:dafa with SMTP id
 y18-20020a05622a005200b003447021dafamr43493883qtw.52.1662482223576; Tue, 06
 Sep 2022 09:37:03 -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: Alan Somers 
Date: Tue, 6 Sep 2022 10:36:52 -0600
Message-ID: 
Subject: Re: Header symbols that shouldn't be visible to ports?
To: Warner Losh 
Cc: Konstantin Belousov , FreeBSD CURRENT 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MMWJ11ksTz3MRk
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=asomers@gmail.com
X-Spamd-Result: default: False [-2.10 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[text/plain];
	RWL_MAILSPIKE_GOOD(-0.10)[209.85.160.174:from];
	MIME_TRACE(0.00)[0:+];
	DMARC_NA(0.00)[freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_ALL(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.160.174:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	R_DKIM_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com];
	RCPT_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[];
	FREEFALL_USER(0.00)[asomers];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Sep 6, 2022 at 9:07 AM Warner Losh  wrote:
>
>
>
> On Tue, Sep 6, 2022 at 7:34 AM Konstantin Belousov  wrote:
>>
>> On Mon, Sep 05, 2022 at 08:41:58AM -0600, Alan Somers wrote:
>> > On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov  wrote:
>> > >
>> > > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
>> > > > Our /usr/include headers define a lot of symbols that are used by
>> > > > critical utilities in the base system like ps and ifconfig, but aren't
>> > > > stable across major releases.  Since they aren't stable, utilities
>> > > > built for older releases won't run correctly on newer ones.  Would it
>> > > > make sense to guard these symbols so they can't be used by programs in
>> > > > the ports tree?  There is some precedent for that, for example
>> > > > _WANT_SOCKET and _WANT_MNTOPTNAMES.
>> > > _WANT_SOCKET is clearly about exposing parts of the kernel definitions
>> > > for userspace code that wants to dig into kernel structures.  Similarly
>> > > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.  The
>> > > definitions are guarded by additional defines not due to their instability,
>> > > but because using them in userspace requires (much) more preparation from
>> > > userspace environment, which is either not trivial (_WANT_SOCKET) or
>> > > contradicts to standartized use of the header (_WANT_MNTOPTNAMES +
>> > > sys/mount.h).
>> > >
>> > > >
>> > > > I'm particular, I'm thinking about symbols like the following:
>> > > > MINCORE_SUPER
>> > > Why this symbol should be hidden?  It is implementation-defined and
>> > > intended to be exposed to userspace.  All MINCORE_* not only MINCORE_SUPER
>> > > are under BSD_VISIBLE braces, because POSIX does not define the symbols.
>> >
>> > Because it isn't stable.  It changed for example in rev 847ab36bf22
>> > for 13.0.  Programs using the older value (including virtually every
>> > Rust program) won't work on 13.0 and later.
>> As Mark replied, older values still mostly work.  It was considered to
>> not make unacceptable ABI change.
>>
>> >
>> > >
>> > > > TDF_*
>> > > These symbols coming from non-standard header sys/proc.h.  If userspace
>> > > includes the header, it is already outside any formal standard, and I
>> > > do not see a reason to make the implementation more convoluted there.
>> > >
>> > > > PRI_MAX*
>> > > > PRI_MIN*
>> > > > PI_*, PRIBIO, PVFS, etc
>> > > > IFCAP_*
>> > > These are all implementation-specific and come from non-standard headers,
>> > > unless I am mistaken, then please correct me.
>> > >
>> > > > RLIM_NLIMITS
>> > > > IFF_*
>> > > Same.
>> > >
>> > > > *_MAXID
>> > > This is too broad.
>> >
>> > I'm talking about symbols like IPV6CTL_MAXID, which record the size of
>> > sysctl lists.  Obviously, these symbols can't be stable, and probably
>> > aren't useful outside of the base system.
>> The programs are not forced to use the symbols.  FFI bindings should not
>> provide them, why do we need to specifically hide such defines?

Because if anybody ever adds it to the libc crate, then it's basically
stuck there forever.  There's precedent for hiding defines like this:
https://reviews.freebsd.org/D25816

>>
>> >
>> > >
>> > > >
>> > > > Clearly delineating private symbols like this would ease the
>> > > > maintenance burden on languages that rely on FFI, like Ruby and Rust.
>> > > > FFI basically assumes that symbols once defined will never change.
>> > >
>> > > Why e.g. sys/proc.h is ever consumed by FFI wrappers?
>> >
>> > I should add a little detail.  Rust uses FFI to access C functions,
>> > and #define'd constants are redefined in the Rust bindings.  For most
>> > Rust programs, the build process doesn't check the contents of
>> > /usr/include in any way.  Instead, all of that stuff is hard-coded in
>> > the Rust bindings.  That makes cross-compiling a breeze!
>> Well, at the cost of the maintaining Rust libc crate.
>> [Sorry, cannot refrain https://kib.kiev.ua/kib/rust_c_ffi.png ]
>>
>> > But it does
>> > cause problems when the C library changes.  Adding a new symbol, like
>> > copy_file_range, isn't so bad.  If your Rust program doesn't use it,
>> > then the Rust binding will become an unused symbol and get eliminated
>> > by the linker.  If your Rust program does use it OTOH, then it will be
>> > resolved by the dynamic linker at runtime - if you're running on
>> > FreeBSD 13 or newer.  Otherwise, your program will fail to run.
>> The program would either fail at start if it does not reference the
>> symbol version in some other way (due to other symbol), or at runtime
>> when trying to do dynamic binding to that symbol otherwise.
>>
>> > A
>> > bigger problem is with symbols that change.  For example, the 64-bit
>> > inode stuff.  Rust programs still use a FreeBSD 11 ABI (we're working
>> > on that).
>> We did not changed symbols for ino64.  Old symbols were retained, the new
>> symbols were added under the new version.

Yes, I spoke imprecisely.  I should've said "defines", not "symbols"
as in "ELF symbols".  The changes to defines like "struct stat" are
the reason that the libc crate is stuck with the FreeBSD 11 ABI.

>>
>> > But other symbols change more frequently.  Things like
>> > PRI_MAX_REALTIME can change between any two releases.  That creates a
>> > big maintenance burden to keep track of them in the FFI bindings.  And
>> > they also aren't very useful in cross-compiled programs targeting a
>> > FreeBSD 11 ABI.  Instead, they really need to have bindings
>> > automatically generated at build time.  That's possible, but it's not
>> > the default.
>> >
>> > So what the Rust community really needs is a way to know which symbols
>> > will be stable across releases, and which might vary.
>> Symbols, as something exported from libc/libthr/libm, are stable.
>> We promise this and follow this promise strictly from FreeBSD 6.x.
>>
>> Some defines from headers are not stable, but they do not form the exported
>> system ABI anyway.  You need to know what you are doing when changing libc.
>> Similarly, when you update Rust libc crate, you have to know what you are
>> providing, it cannot be done automatically.
>
>
> FreeBSD developers get this wrong from time to time. We have to carefully curate
> new symbols to the libraires, and deal with #defines that are part of the core ABI that
> we've kept stable. We don't have any formal tests here to ensure things work, apart
> from people trying things and having them break due to some oversight.
>
> For example, recently, the CAM ioctls changed so that old passthrough CCB ioctls
> stopped working. It took months for people to notice. It was broken in a release. The
> fix was a trivial one-liner once someone noticed and made the effort. Since there was
> no automation to test it, it went unnoticed.
>
>>
>> Expecting that we (FreeBSD developers) would mark up each definition in
>> the headers files is unreasonable.  Even if this enormous work would be
>> done once, it rot immediately.  The outcome of the work is not used by
>> anything in either the base system, or in 99.999% of the ports.  As result,
>> anybody doing any work on the base libraries, make mistakes.
>>
>> > Are you
>> > suggesting that anything from a non-POSIX header file should be
>> > considered variable?
>> No, I suggest that anything not in POSIX namespace should be scrutinized
>> for ABI stability, instead of stating that 'it is available, so lets make
>> bindings for it'.

Well, that would be nice.  But it's too late :( .  People add defines
all the time, and then we're pretty much stuck with them, owing to
libc's very conservative backwards-compatibility policy.  For example
https://github.com/rust-lang/libc/pull/2572 , which added a bunch of
MNTK_* defines.

>>
>> I have the sympathy for Rust decision to provide isolated libc crate.
>> It certainly makes sense for the Rust ecosystem.
>>
>> But then having this crate to depend on autogeneration from /usr/include
>> negates the intent of isolation.  I think, if you want to have
>> automatic binding generation used, you must provide the white list of
>> symbols and definitions that go into the crate.

Actually, that's technically how it works.  There is no autogeneration
for libc.  But there _is_ autogeneration during its CI tests.  So
effectively all of the defined constants _are_ a whitelist.  The
problem is that people add to the whitelist too eagerly.

>
>
> I agree with kib: I don't see how asking developers to know, a priori,
> which of our unstable interfaces will change and which won't.  If you import
> things that aren't in the POSIX namespace, you need to work with those
> namespace providers to import them properly. Whitelisting is the only way
> that I see it working.
>
> At most, we have resources to allow you to maintain this list, and allow you
> to make changes on a best effort basis that history has suggested will be
> about 90% successful. Absent some automation that enforces it, it will break.
> And even with automation, you'll need someone to review breakage and/or
> additions to ensure the right things get updated. Developers might be able
> to lend a hand, but that can't be relied upon without oversight to work.
>
> Warner

So you both seem to be saying that there's no rule we can use to
exclude some defines from libc, and that everything will have to be
evaluated on a case-by-case basis, right?  Ok, I can do that.  It'll
just be more effort than I'd hoped for.
-Alan

From nobody Tue Sep  6 16:45:53 2022
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 4MMWVP0BdRz4cB5j
	for ; Tue,  6 Sep 2022 16:46:05 +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 4MMWVN20Y2z3Pn4;
	Tue,  6 Sep 2022 16:46:04 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 286Gjrpj008372
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 6 Sep 2022 19:45:56 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 286GjrfU008371;
	Tue, 6 Sep 2022 19:45:53 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Tue, 6 Sep 2022 19:45:53 +0300
From: Konstantin Belousov 
To: Alan Somers 
Cc: Warner Losh ,
        FreeBSD CURRENT 
Subject: Re: Header symbols that shouldn't be visible to ports?
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=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home
X-Rspamd-Queue-Id: 4MMWVN20Y2z3Pn4
X-Spamd-Bar: -
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
X-Spamd-Result: default: False [-1.99 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.99)[-0.993];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	HAS_XAW(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Sep 06, 2022 at 10:36:52AM -0600, Alan Somers wrote:
> On Tue, Sep 6, 2022 at 9:07 AM Warner Losh  wrote:
> >
> >
> >
> > On Tue, Sep 6, 2022 at 7:34 AM Konstantin Belousov  wrote:
> >>
> >> On Mon, Sep 05, 2022 at 08:41:58AM -0600, Alan Somers wrote:
> >> > On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov  wrote:
> >> > >
> >> > > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> >> > > > Our /usr/include headers define a lot of symbols that are used by
> >> > > > critical utilities in the base system like ps and ifconfig, but aren't
> >> > > > stable across major releases.  Since they aren't stable, utilities
> >> > > > built for older releases won't run correctly on newer ones.  Would it
> >> > > > make sense to guard these symbols so they can't be used by programs in
> >> > > > the ports tree?  There is some precedent for that, for example
> >> > > > _WANT_SOCKET and _WANT_MNTOPTNAMES.
> >> > > _WANT_SOCKET is clearly about exposing parts of the kernel definitions
> >> > > for userspace code that wants to dig into kernel structures.  Similarly
> >> > > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.  The
> >> > > definitions are guarded by additional defines not due to their instability,
> >> > > but because using them in userspace requires (much) more preparation from
> >> > > userspace environment, which is either not trivial (_WANT_SOCKET) or
> >> > > contradicts to standartized use of the header (_WANT_MNTOPTNAMES +
> >> > > sys/mount.h).
> >> > >
> >> > > >
> >> > > > I'm particular, I'm thinking about symbols like the following:
> >> > > > MINCORE_SUPER
> >> > > Why this symbol should be hidden?  It is implementation-defined and
> >> > > intended to be exposed to userspace.  All MINCORE_* not only MINCORE_SUPER
> >> > > are under BSD_VISIBLE braces, because POSIX does not define the symbols.
> >> >
> >> > Because it isn't stable.  It changed for example in rev 847ab36bf22
> >> > for 13.0.  Programs using the older value (including virtually every
> >> > Rust program) won't work on 13.0 and later.
> >> As Mark replied, older values still mostly work.  It was considered to
> >> not make unacceptable ABI change.
> >>
> >> >
> >> > >
> >> > > > TDF_*
> >> > > These symbols coming from non-standard header sys/proc.h.  If userspace
> >> > > includes the header, it is already outside any formal standard, and I
> >> > > do not see a reason to make the implementation more convoluted there.
> >> > >
> >> > > > PRI_MAX*
> >> > > > PRI_MIN*
> >> > > > PI_*, PRIBIO, PVFS, etc
> >> > > > IFCAP_*
> >> > > These are all implementation-specific and come from non-standard headers,
> >> > > unless I am mistaken, then please correct me.
> >> > >
> >> > > > RLIM_NLIMITS
> >> > > > IFF_*
> >> > > Same.
> >> > >
> >> > > > *_MAXID
> >> > > This is too broad.
> >> >
> >> > I'm talking about symbols like IPV6CTL_MAXID, which record the size of
> >> > sysctl lists.  Obviously, these symbols can't be stable, and probably
> >> > aren't useful outside of the base system.
> >> The programs are not forced to use the symbols.  FFI bindings should not
> >> provide them, why do we need to specifically hide such defines?
> 
> Because if anybody ever adds it to the libc crate, then it's basically
> stuck there forever.  There's precedent for hiding defines like this:
> https://reviews.freebsd.org/D25816
> 
> >>
> >> >
> >> > >
> >> > > >
> >> > > > Clearly delineating private symbols like this would ease the
> >> > > > maintenance burden on languages that rely on FFI, like Ruby and Rust.
> >> > > > FFI basically assumes that symbols once defined will never change.
> >> > >
> >> > > Why e.g. sys/proc.h is ever consumed by FFI wrappers?
> >> >
> >> > I should add a little detail.  Rust uses FFI to access C functions,
> >> > and #define'd constants are redefined in the Rust bindings.  For most
> >> > Rust programs, the build process doesn't check the contents of
> >> > /usr/include in any way.  Instead, all of that stuff is hard-coded in
> >> > the Rust bindings.  That makes cross-compiling a breeze!
> >> Well, at the cost of the maintaining Rust libc crate.
> >> [Sorry, cannot refrain https://kib.kiev.ua/kib/rust_c_ffi.png ]
> >>
> >> > But it does
> >> > cause problems when the C library changes.  Adding a new symbol, like
> >> > copy_file_range, isn't so bad.  If your Rust program doesn't use it,
> >> > then the Rust binding will become an unused symbol and get eliminated
> >> > by the linker.  If your Rust program does use it OTOH, then it will be
> >> > resolved by the dynamic linker at runtime - if you're running on
> >> > FreeBSD 13 or newer.  Otherwise, your program will fail to run.
> >> The program would either fail at start if it does not reference the
> >> symbol version in some other way (due to other symbol), or at runtime
> >> when trying to do dynamic binding to that symbol otherwise.
> >>
> >> > A
> >> > bigger problem is with symbols that change.  For example, the 64-bit
> >> > inode stuff.  Rust programs still use a FreeBSD 11 ABI (we're working
> >> > on that).
> >> We did not changed symbols for ino64.  Old symbols were retained, the new
> >> symbols were added under the new version.
> 
> Yes, I spoke imprecisely.  I should've said "defines", not "symbols"
> as in "ELF symbols".  The changes to defines like "struct stat" are
> the reason that the libc crate is stuck with the FreeBSD 11 ABI.
> 
> >>
> >> > But other symbols change more frequently.  Things like
> >> > PRI_MAX_REALTIME can change between any two releases.  That creates a
> >> > big maintenance burden to keep track of them in the FFI bindings.  And
> >> > they also aren't very useful in cross-compiled programs targeting a
> >> > FreeBSD 11 ABI.  Instead, they really need to have bindings
> >> > automatically generated at build time.  That's possible, but it's not
> >> > the default.
> >> >
> >> > So what the Rust community really needs is a way to know which symbols
> >> > will be stable across releases, and which might vary.
> >> Symbols, as something exported from libc/libthr/libm, are stable.
> >> We promise this and follow this promise strictly from FreeBSD 6.x.
> >>
> >> Some defines from headers are not stable, but they do not form the exported
> >> system ABI anyway.  You need to know what you are doing when changing libc.
> >> Similarly, when you update Rust libc crate, you have to know what you are
> >> providing, it cannot be done automatically.
> >
> >
> > FreeBSD developers get this wrong from time to time. We have to carefully curate
> > new symbols to the libraires, and deal with #defines that are part of the core ABI that
> > we've kept stable. We don't have any formal tests here to ensure things work, apart
> > from people trying things and having them break due to some oversight.
> >
> > For example, recently, the CAM ioctls changed so that old passthrough CCB ioctls
> > stopped working. It took months for people to notice. It was broken in a release. The
> > fix was a trivial one-liner once someone noticed and made the effort. Since there was
> > no automation to test it, it went unnoticed.
> >
> >>
> >> Expecting that we (FreeBSD developers) would mark up each definition in
> >> the headers files is unreasonable.  Even if this enormous work would be
> >> done once, it rot immediately.  The outcome of the work is not used by
> >> anything in either the base system, or in 99.999% of the ports.  As result,
> >> anybody doing any work on the base libraries, make mistakes.
> >>
> >> > Are you
> >> > suggesting that anything from a non-POSIX header file should be
> >> > considered variable?
> >> No, I suggest that anything not in POSIX namespace should be scrutinized
> >> for ABI stability, instead of stating that 'it is available, so lets make
> >> bindings for it'.
> 
> Well, that would be nice.  But it's too late :( .  People add defines
> all the time, and then we're pretty much stuck with them, owing to
> libc's very conservative backwards-compatibility policy.  For example
> https://github.com/rust-lang/libc/pull/2572 , which added a bunch of
> MNTK_* defines.
> 
> >>
> >> I have the sympathy for Rust decision to provide isolated libc crate.
> >> It certainly makes sense for the Rust ecosystem.
> >>
> >> But then having this crate to depend on autogeneration from /usr/include
> >> negates the intent of isolation.  I think, if you want to have
> >> automatic binding generation used, you must provide the white list of
> >> symbols and definitions that go into the crate.
> 
> Actually, that's technically how it works.  There is no autogeneration
> for libc.  But there _is_ autogeneration during its CI tests.  So
> effectively all of the defined constants _are_ a whitelist.  The
> problem is that people add to the whitelist too eagerly.
> 
> >
> >
> > I agree with kib: I don't see how asking developers to know, a priori,
> > which of our unstable interfaces will change and which won't.  If you import
> > things that aren't in the POSIX namespace, you need to work with those
> > namespace providers to import them properly. Whitelisting is the only way
> > that I see it working.
> >
> > At most, we have resources to allow you to maintain this list, and allow you
> > to make changes on a best effort basis that history has suggested will be
> > about 90% successful. Absent some automation that enforces it, it will break.
> > And even with automation, you'll need someone to review breakage and/or
> > additions to ensure the right things get updated. Developers might be able
> > to lend a hand, but that can't be relied upon without oversight to work.
> >
> > Warner
> 
> So you both seem to be saying that there's no rule we can use to
> exclude some defines from libc, and that everything will have to be
> evaluated on a case-by-case basis, right?  Ok, I can do that.  It'll
> just be more effort than I'd hoped for.

Yes, the case by case basis is the only workable solution IMO.

But, with regard to backward compatibility of libc crate, and inability
to remove any added symbols.  Note that things like TDF_* defines are
innocent even if not correct: they are practically useless for any
usermode code.  So if the symbols are present but the definition does
not match currently running libc or kernel, there is no harm (except
possibly some tests for libc crate failing).

From nobody Wed Sep  7 14:55:24 2022
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 4MN50J204Kz4cbgd
	for ; Wed,  7 Sep 2022 14:55:28 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MN50H4CfVz3T2x;
	Wed,  7 Sep 2022 14:55:27 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250])
	by cmsmtp with ESMTP
	id VruIoaNOBS8WrVwScowSPc; Wed, 07 Sep 2022 14:55:26 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id VwSaojPanC3uhVwSboN3Q5; Wed, 07 Sep 2022 14:55:26 +0000
X-Authority-Analysis: v=2.4 cv=a6MjSGeF c=1 sm=1 tr=0 ts=6318b0de
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=xOM3xZuef0cA:10 a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8
 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=9rOpkhTHWMKq_9iKNLkA:9 a=CjuIK1q_8ugA:10
 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id A715E768;
	Wed,  7 Sep 2022 07:55:24 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id 7C9881FB; Wed,  7 Sep 2022 07:55:24 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Alan Somers 
cc: Konstantin Belousov ,
    FreeBSD CURRENT 
Subject: Re: Header symbols that shouldn't be visible to ports?
In-reply-to: 
References:   
Comments: In-reply-to Alan Somers 
   message dated "Mon, 05 Sep 2022 08:41:58 -0600."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 07 Sep 2022 07:55:24 -0700
Message-Id: <20220907145524.7C9881FB@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfPfgOUSt8YIbnSN/CQ9oauMdEgdszkYNHkGMdlBVH/6WXhE97DP0bT6ehrK9ZUzB7nZiI0/HfTMBEMt1/NKwCjUnlwMYFxgqF4mhaJuJySvb0eC552fo
 wpTymBzt/VEO92vVaWXjYL9et4ccNRPJqDLZo9kzURs+cR02hT0brGlJF1clfsfoMWm+TeQRH+nH16nUuYfQ3DDW/MsNRJCH0l4ydGe0/fTT2M2Iwq/yKcKR
 v8ESdT9JSbFLNZlW9POxdLP6wvKoZOc7bQplsid3jA0=
X-Rspamd-Queue-Id: 4MN50H4CfVz3T2x
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-0.80 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_THREE(0.00)[3];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	REPLYTO_EQ_FROM(0.00)[];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message 
, Alan Somers writes:
> On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov  wro
> te:
> >
> > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> > > Our /usr/include headers define a lot of symbols that are used by
> > > critical utilities in the base system like ps and ifconfig, but aren't
> > > stable across major releases.  Since they aren't stable, utilities
> > > built for older releases won't run correctly on newer ones.  Would it
> > > make sense to guard these symbols so they can't be used by programs in
> > > the ports tree?  There is some precedent for that, for example
> > > _WANT_SOCKET and _WANT_MNTOPTNAMES.
> > _WANT_SOCKET is clearly about exposing parts of the kernel definitions
> > for userspace code that wants to dig into kernel structures.  Similarly
> > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.  The
> > definitions are guarded by additional defines not due to their instability,
> > but because using them in userspace requires (much) more preparation from
> > userspace environment, which is either not trivial (_WANT_SOCKET) or
> > contradicts to standartized use of the header (_WANT_MNTOPTNAMES +
> > sys/mount.h).
> >
> > >
> > > I'm particular, I'm thinking about symbols like the following:
> > > MINCORE_SUPER
> > Why this symbol should be hidden?  It is implementation-defined and
> > intended to be exposed to userspace.  All MINCORE_* not only MINCORE_SUPER
> > are under BSD_VISIBLE braces, because POSIX does not define the symbols.
>
> Because it isn't stable.  It changed for example in rev 847ab36bf22
> for 13.0.  Programs using the older value (including virtually every
> Rust program) won't work on 13.0 and later.
>
> >
> > > TDF_*
> > These symbols coming from non-standard header sys/proc.h.  If userspace
> > includes the header, it is already outside any formal standard, and I
> > do not see a reason to make the implementation more convoluted there.
> >
> > > PRI_MAX*
> > > PRI_MIN*
> > > PI_*, PRIBIO, PVFS, etc
> > > IFCAP_*
> > These are all implementation-specific and come from non-standard headers,
> > unless I am mistaken, then please correct me.
> >
> > > RLIM_NLIMITS
> > > IFF_*
> > Same.
> >
> > > *_MAXID
> > This is too broad.
>
> I'm talking about symbols like IPV6CTL_MAXID, which record the size of
> sysctl lists.  Obviously, these symbols can't be stable, and probably
> aren't useful outside of the base system.
>
> >
> > >
> > > Clearly delineating private symbols like this would ease the
> > > maintenance burden on languages that rely on FFI, like Ruby and Rust.
> > > FFI basically assumes that symbols once defined will never change.
> >
> > Why e.g. sys/proc.h is ever consumed by FFI wrappers?
>
> I should add a little detail.  Rust uses FFI to access C functions,
> and #define'd constants are redefined in the Rust bindings.  For most
> Rust programs, the build process doesn't check the contents of
> /usr/include in any way.  Instead, all of that stuff is hard-coded in
> the Rust bindings.  That makes cross-compiling a breeze!  But it does
> cause problems when the C library changes.  Adding a new symbol, like
> copy_file_range, isn't so bad.  If your Rust program doesn't use it,
> then the Rust binding will become an unused symbol and get eliminated
> by the linker.  If your Rust program does use it OTOH, then it will be
> resolved by the dynamic linker at runtime - if you're running on
> FreeBSD 13 or newer.  Otherwise, your program will fail to run.  A
> bigger problem is with symbols that change.  For example, the 64-bit
> inode stuff.  Rust programs still use a FreeBSD 11 ABI (we're working
> on that).  But other symbols change more frequently.  Things like
> PRI_MAX_REALTIME can change between any two releases.  That creates a
> big maintenance burden to keep track of them in the FFI bindings.  And
> they also aren't very useful in cross-compiled programs targeting a
> FreeBSD 11 ABI.  Instead, they really need to have bindings
> automatically generated at build time.  That's possible, but it's not
> the default.

This is exactly what happened with DMD D. When 64-bit statfs was introduced 
all DMD D compiled programs failed to run and recompiling didn't help. The 
DMD upstream failed to understand the problem. Eventually the port had to 
be removed.

>
> So what the Rust community really needs is a way to know which symbols
> will be stable across releases, and which might vary.  Are you
> suggesting that anything from a non-POSIX header file should be
> considered variable?
>

Rust and every other community.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e^(i*pi)+1=0



From nobody Wed Sep  7 15:59:39 2022
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 4MN6Qc4VQDz4bWfJ
	for ; Wed,  7 Sep 2022 15:59:52 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MN6Qb5JHQz3v2K
	for ; Wed,  7 Sep 2022 15:59:51 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: by mail-qt1-f175.google.com with SMTP id cr9so10736303qtb.13
        for ; Wed, 07 Sep 2022 08:59:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:subject:message-id:date:from:in-reply-to:references:mime-version
         :x-gm-message-state:from:to:cc:subject:date;
        bh=7OPAYTtszQhb468ZWEYWXzb6gXEpm9MUAz6LMijkHrY=;
        b=x/xFgEDhDfBXaSEmacwUJZoCFTuTPjbMkNAO9dQ7czjETIBNbldb4ADllsReVfw4t7
         Ht8/cmgPpOti28XZlsLw31WPzR/iqHYjDB2Ju7Vw2i915VpEbmUeSi5ZqTB1p4+ideER
         tfoSDiiFvNW0jNH5bYE8MFySPv22he4yS3N4/xdQ4I+649RrzfgpIFUihFvKvYM7egUf
         xQg7sJY0UP2mgiWwhElVVcjd3kyCuKxoJd8Yitub0vrt5K9mnDJuOBOJdWOxPLiS/5Tc
         NwRnaJOsAIpkSjqFI8s3RsJg3I6gB6y+jIYvtT7qIqaHvcoyjzJNg3/LSScUwO26ix+9
         /vjA==
X-Gm-Message-State: ACgBeo2nXFJ8XI99piLSD3oxosetMF9frEth2jwJMLFN2yRafV6sxerL
	MlJOaAfU6QTG2D4jsThCZ+mOFiqcfPjuXwfQ6UM=
X-Received: by 2002:ac8:5f4e:0:b0:345:45d:3701 with SMTP id
 y14-20020ac85f4e000000b00345045d3701mt3838152qta.139.1662566390150; Wed, 07
 Sep 2022 08:59:50 -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: 
  
 <20220907145524.7C9881FB@slippy.cwsent.com>
In-Reply-To: <20220907145524.7C9881FB@slippy.cwsent.com>
From: Alan Somers 
Date: Wed, 7 Sep 2022 09:59:39 -0600
Message-ID: 
Subject: Re: Header symbols that shouldn't be visible to ports?
Cc: Alan Somers , Konstantin Belousov , 
	FreeBSD CURRENT 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MN6Qb5JHQz3v2K
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=asomers@gmail.com
X-Spamd-Result: default: False [0.00 / 15.00];
	MISSING_TO(2.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[text/plain];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DMARC_NA(0.00)[freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.160.175:from];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.160.175:from];
	RCPT_COUNT_THREE(0.00)[3];
	FREEFALL_USER(0.00)[asomers];
	RCVD_COUNT_TWO(0.00)[2];
	R_DKIM_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	FREEMAIL_CC(0.00)[freebsd.org,gmail.com]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Sep 7, 2022 at 8:55 AM Cy Schubert  wrote:
>
> In message  om>
> , Alan Somers writes:
> > On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov  wro
> > te:
> > >
> > > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> > > > Our /usr/include headers define a lot of symbols that are used by
> > > > critical utilities in the base system like ps and ifconfig, but aren't
> > > > stable across major releases.  Since they aren't stable, utilities
> > > > built for older releases won't run correctly on newer ones.  Would it
> > > > make sense to guard these symbols so they can't be used by programs in
> > > > the ports tree?  There is some precedent for that, for example
> > > > _WANT_SOCKET and _WANT_MNTOPTNAMES.
> > > _WANT_SOCKET is clearly about exposing parts of the kernel definitions
> > > for userspace code that wants to dig into kernel structures.  Similarly
> > > for _WANT_MNTOPTNAMES, but in fact this thing is quite stable.  The
> > > definitions are guarded by additional defines not due to their instability,
> > > but because using them in userspace requires (much) more preparation from
> > > userspace environment, which is either not trivial (_WANT_SOCKET) or
> > > contradicts to standartized use of the header (_WANT_MNTOPTNAMES +
> > > sys/mount.h).
> > >
> > > >
> > > > I'm particular, I'm thinking about symbols like the following:
> > > > MINCORE_SUPER
> > > Why this symbol should be hidden?  It is implementation-defined and
> > > intended to be exposed to userspace.  All MINCORE_* not only MINCORE_SUPER
> > > are under BSD_VISIBLE braces, because POSIX does not define the symbols.
> >
> > Because it isn't stable.  It changed for example in rev 847ab36bf22
> > for 13.0.  Programs using the older value (including virtually every
> > Rust program) won't work on 13.0 and later.
> >
> > >
> > > > TDF_*
> > > These symbols coming from non-standard header sys/proc.h.  If userspace
> > > includes the header, it is already outside any formal standard, and I
> > > do not see a reason to make the implementation more convoluted there.
> > >
> > > > PRI_MAX*
> > > > PRI_MIN*
> > > > PI_*, PRIBIO, PVFS, etc
> > > > IFCAP_*
> > > These are all implementation-specific and come from non-standard headers,
> > > unless I am mistaken, then please correct me.
> > >
> > > > RLIM_NLIMITS
> > > > IFF_*
> > > Same.
> > >
> > > > *_MAXID
> > > This is too broad.
> >
> > I'm talking about symbols like IPV6CTL_MAXID, which record the size of
> > sysctl lists.  Obviously, these symbols can't be stable, and probably
> > aren't useful outside of the base system.
> >
> > >
> > > >
> > > > Clearly delineating private symbols like this would ease the
> > > > maintenance burden on languages that rely on FFI, like Ruby and Rust.
> > > > FFI basically assumes that symbols once defined will never change.
> > >
> > > Why e.g. sys/proc.h is ever consumed by FFI wrappers?
> >
> > I should add a little detail.  Rust uses FFI to access C functions,
> > and #define'd constants are redefined in the Rust bindings.  For most
> > Rust programs, the build process doesn't check the contents of
> > /usr/include in any way.  Instead, all of that stuff is hard-coded in
> > the Rust bindings.  That makes cross-compiling a breeze!  But it does
> > cause problems when the C library changes.  Adding a new symbol, like
> > copy_file_range, isn't so bad.  If your Rust program doesn't use it,
> > then the Rust binding will become an unused symbol and get eliminated
> > by the linker.  If your Rust program does use it OTOH, then it will be
> > resolved by the dynamic linker at runtime - if you're running on
> > FreeBSD 13 or newer.  Otherwise, your program will fail to run.  A
> > bigger problem is with symbols that change.  For example, the 64-bit
> > inode stuff.  Rust programs still use a FreeBSD 11 ABI (we're working
> > on that).  But other symbols change more frequently.  Things like
> > PRI_MAX_REALTIME can change between any two releases.  That creates a
> > big maintenance burden to keep track of them in the FFI bindings.  And
> > they also aren't very useful in cross-compiled programs targeting a
> > FreeBSD 11 ABI.  Instead, they really need to have bindings
> > automatically generated at build time.  That's possible, but it's not
> > the default.
>
> This is exactly what happened with DMD D. When 64-bit statfs was introduced
> all DMD D compiled programs failed to run and recompiling didn't help. The
> DMD upstream failed to understand the problem. Eventually the port had to
> be removed.

Ouch.  Does DMD not use ELF symbol versioning?  That's what Rust does.
So all Rust programs are still using the FreeBSD 11 version of "struct
statfs", and the libc function they link to is "statfs@FBSD_1.0"
instead of "statfs".

>
> >
> > So what the Rust community really needs is a way to know which symbols
> > will be stable across releases, and which might vary.  Are you
> > suggesting that anything from a non-POSIX header file should be
> > considered variable?
> >
>
> Rust and every other community.
>
>
> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX:     Web:  http://www.FreeBSD.org
> NTP:               Web:  https://nwtime.org
>
>                         e^(i*pi)+1=0
>
>

From nobody Thu Sep  8 08:24:02 2022
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 4MNXGD3vxpz4bWjS
	for ; Thu,  8 Sep 2022 08:24:04 +0000 (UTC)
	(envelope-from theraven@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MNXGD3HxWz3kQn;
	Thu,  8 Sep 2022 08:24:04 +0000 (UTC)
	(envelope-from theraven@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1662625444;
	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=yrholDB23pJhwkOfXJLKAABzFsZuKdx6OhG/ZgODSbk=;
	b=B/gs7awXA4fKFaY6OFBKtqw8hMn3Q//QgmPjl0nFH7upOKgb4zb/bkxBEZxYPCAtsnryMV
	S+WTNedmfJnnTR/ySDDc5z8Vx+MNmwK+FdnBgTwZ98W1WO+OivGEyPhIPB0wC3T5LkbTEA
	Yvgzt986+bpgvsAF1fC+0Iz+x32RB6WtUBZphpG/qkbFUbJxQNhij0GPAA+c/xcDld60iI
	qQE36/OejvTBx052xJJE9gC+jZwbwB5Fo2S0zNGh10zcVxg8THcPS3/4H23HwbaKcO7bzC
	WkYDEDSyWD1atZ5eH29prtdy9k1TrKzgXb45F33dgFDwmvs+rwCa8RP6Okh/hw==
Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195])
	(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: theraven)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MNXGD2191z17nj;
	Thu,  8 Sep 2022 08:24:04 +0000 (UTC)
	(envelope-from theraven@FreeBSD.org)
Received: from smtpclient.apple (host86-139-146-83.range86-139.btcentralplus.com [86.139.146.83])
	by smtp.theravensnest.org (Postfix) with ESMTPSA id 5ADD69455;
	Thu,  8 Sep 2022 09:24:03 +0100 (BST)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: Header symbols that shouldn't be visible to ports?
From: David Chisnall 
In-Reply-To: <20220907145524.7C9881FB@slippy.cwsent.com>
Date: Thu, 8 Sep 2022 09:24:02 +0100
Cc: Alan Somers ,
 Konstantin Belousov ,
 FreeBSD CURRENT 
Content-Transfer-Encoding: quoted-printable
Message-Id: <87CEB36F-4D12-4A3B-A38D-C1FECA2C5FD4@FreeBSD.org>
References: 
 
 
 <20220907145524.7C9881FB@slippy.cwsent.com>
To: Cy Schubert 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1662625444;
	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=yrholDB23pJhwkOfXJLKAABzFsZuKdx6OhG/ZgODSbk=;
	b=h/GTT7JV/EKmPO8in/QiGOY7/+2fmIhz46J1ZvItWAZpLrPz3Nw4ESv4KY+zSpx/eb4EY5
	iQu6n9eADgbgkq6yM/1VwlV97OejrkyEuIoShmhs74Qvtkz0M/aT491U5TTxp5U2plcZLu
	LLEBOD/JzaZiCYHM83BKBHDMci/gAnsSy+1l7LM4Gns/5aUkxG3d3TDkdsgNHNnDeewoIx
	Ebg8o76BWBHhjOpfc38ucrXLcdy5/Q9KzBcuc0d2fnwDKH2PfjFKgr1ChEX8gMGOFrXGMV
	Yd4xULoBbUTemFdkMbOj7eGuBFUyB8OCvfZX/IQTAvXCZezE0K8QNEXJTq+6Jw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662625444; a=rsa-sha256; cv=none;
	b=ZLeX+wQ9Mt9uZ0WHC0PIF23Y/Ybo1jrjAQCIqWx+2mcMHdr1AB7Wp2tLBtElWOVtmQEtbN
	MlXfTU5riiGCuASJkHxb6xprKF7KB4EzcHgfGVL21eUH2kxncvt8RkaSvWd2eSpZHCWVQ4
	//m/j/9cCisd5MDkar9KKJvYHJsjkulZ6sNYsfe9zGvO95AQUmAA3yCvEnXx44HG4BoeUC
	LJQXos6aAPOAwVOI9zGi/V6KnXpjQOJfLihvEl0evL+f6S2RtnZa6bWF0DR9h5U5Z9HFU0
	W3vSk6dcLbUIgxF9CmPJwxceXFou8JzMZUROJ3dxKbLJd/RUxmucNSdCXwFsow==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 7 Sep 2022, at 15:55, Cy Schubert  wrote:
>=20
> This is exactly what happened with DMD D. When 64-bit statfs was =
introduced=20
> all DMD D compiled programs failed to run and recompiling didn't help. =
The=20
> DMD upstream failed to understand the problem. Eventually the port had =
to=20
> be removed.

I=E2=80=99m not sure that I understand the problem.  This should matter =
only for libraries that pass a statbuf across their ABI boundary.  =
Anyone using libc will see the old version of the symbol and just use =
the old statbuf.  Anyone using the old syscall number and doing system =
calls directly will see the compat version of the structure.  Anyone =
taking the statbuf and passing it to a C library compiled with the newer =
headers will see compat problems (but the same is true for a C library =
asking a C program to pass it a statbuf and having the two compiled =
against different kernel versions).

There=E2=80=99s a lot that we could do in system headers to make them =
more FFI-friendly.  For example:

 - Use `enum`s rather than `#define`s for constants.

 - Add the flags-enum attribute for flags, so that FFI layers that can =
parse attributes get more semantic information.

 - Add non-null attributes on all arguments and returns that=20

 - Use `static inline` functions instead of macros where possible and =
expose them with a macro for `static inline` so that an FFI layer can =
compile the headers in a mode that makes these functions that they can =
link against.  For Rust, this can be compiled to LLVM IR and linked =
against and inlined into the Rust code, so things like the Capsicum =
permissions bitmap setting code wouldn=E2=80=99t need duplicating in =
Rust.

 - Mark functions with availability attributes so that FFI knows when =
it=E2=80=99s using deprecated / unstable values and can make strong ABI =
guarantees.

 - Add tests for the headers to the tree.

In 12.0, someone decided to rewrite a load of kernel headers to use =
macros instead of inline functions, which then broke C++ code in the =
kernel by changing properly namespaced things into symbols that would =
replace every identifier.  I=E2=80=99d love to see a concerted effort to =
use a post-1999 style for our headers.

David


From nobody Thu Sep  8 10:50:28 2022
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 4MNbWF32xBz4bp8X;
	Thu,  8 Sep 2022 10:50:33 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4MNbWD2Stgz4065;
	Thu,  8 Sep 2022 10:50:32 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 6361726050E;
	Thu,  8 Sep 2022 12:50:31 +0200 (CEST)
Message-ID: 
Date: Thu, 8 Sep 2022 12:50:28 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Content-Language: en-US
To: FreeBSD Current ,
 "freebsd-arch@freebsd.org" 
From: Hans Petter Selasky 
Subject: [RFC] Proposal adding new sorting algorithm, bsort() to libc
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MNbWD2Stgz4065
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org,freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

See:
https://reviews.freebsd.org/D36493

Looking through base I see qsort() being used in places it shouldn't be 
used. For example in fts_open().

If for example you fill a directory with 64k simply numerical file names 
in the wrong order and ask fts_open() to sort these ascending for 
example, qsort() will end stuck for a long-long time. So either switch 
to mergesort, or if malloc() is unacceptable, use something like bsort() 
which I've implemented in the above review as a drop-in replacement for 
qsort(). The advantage with bsort() is that in can be CPU accelerated, 
due to fixed comparison patterns.

Quick sort is not always a quick sorting algorithm. Quick means simple, 
and not clever this time.

For the qsort's bad pattern, sorting 4096 entries 1024 times in a row took:

qsort: 15 seconds
bsort: 230 milliseconds (non-CPU accelerated)
mergesort: 30 milliseconds

The problem with qsort() is that as the array size grows, the time 
consumption just gets worse and worse for the bad-patterns.

Sorry there is no nice and fancy paper yet about this.

--HPS

From nobody Thu Sep  8 11:37:16 2022
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 4MNcYG54jzz4bv47;
	Thu,  8 Sep 2022 11:37:22 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4MNcYF5rfRz44dX;
	Thu,  8 Sep 2022 11:37:21 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 631E4260525;
	Thu,  8 Sep 2022 13:37:20 +0200 (CEST)
Message-ID: <6883e9bf-fce2-4514-e8b4-0689b4ecf6e4@selasky.org>
Date: Thu, 8 Sep 2022 13:37:16 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: [RFC] Proposal adding new sorting algorithm, bsort() to libc
Content-Language: en-US
From: Hans Petter Selasky 
To: FreeBSD Current ,
 "freebsd-arch@freebsd.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MNcYF5rfRz44dX
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org,freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/8/22 12:50, Hans Petter Selasky wrote:
> See:
> https://reviews.freebsd.org/D36493
> 
> Looking through base I see qsort() being used in places it shouldn't be 
> used. For example in fts_open().
> 
> If for example you fill a directory with 64k simply numerical file names 
> in the wrong order and ask fts_open() to sort these ascending for 
> example, qsort() will end stuck for a long-long time. So either switch 
> to mergesort, or if malloc() is unacceptable, use something like bsort() 
> which I've implemented in the above review as a drop-in replacement for 
> qsort(). The advantage with bsort() is that in can be CPU accelerated, 
> due to fixed comparison patterns.
> 
> Quick sort is not always a quick sorting algorithm. Quick means simple, 
> and not clever this time.
> 
> For the qsort's bad pattern, sorting 4096 entries 1024 times in a row took:
> 
> qsort: 15 seconds
> bsort: 230 milliseconds (non-CPU accelerated)
> mergesort: 30 milliseconds
> 
> The problem with qsort() is that as the array size grows, the time 
> consumption just gets worse and worse for the bad-patterns.
> 
> Sorry there is no nice and fancy paper yet about this.
> 
> --HPS
> 

Hi,

Also see the "kill_ls.c" test program I attached to D36493, which shows 
the direct affect of qsort() on the regular "ls" command!

--HPS

From nobody Fri Sep  9 17:32:30 2022
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 4MPNNf1F2zz4bvlt
	for ; Fri,  9 Sep 2022 17:32:34 +0000 (UTC)
	(envelope-from bz@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MPNNf0jlHz3D9b
	for ; Fri,  9 Sep 2022 17:32:34 +0000 (UTC)
	(envelope-from bz@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1662744754;
	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=NIFltIW07s9IWTqPm+mGfa88ExiQrgl2iagVAwTSWUM=;
	b=VrayuPbUMLviK0UNIaZaOqN4E73Yn4D2+mexTOlhiEr86eLRC0B3pQw0wPOWd5n+G07piu
	oZ4VrQBxJfUqPPtC4/AurbqIvzdY7ItzBdOUWPGAljr98oPRnfPMpCtO2vFOO4gPiSvLpW
	YkGbmIYUmiS4yqddD86QQi3R8I5gPvQ1Ob/G6eb5AUhLifB8z/oeVWfotDTDNbXQ84I1TH
	irwpcd1dTc6Dtm6JkLceGpE2qfmgYk8R5PLC5t3Va1JyrhgaWnzbK9pjCApaokZFyG3UAk
	akxy4tCOUAjCc37xeCDA/0RZ4xJQOGsFn647609SqD347n0pmBkMzYAYgm/nCQ==
Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified))
	(Authenticated sender: bz/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MPNNd691cz1FWC
	for ; Fri,  9 Sep 2022 17:32:33 +0000 (UTC)
	(envelope-from bz@FreeBSD.org)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mx1.sbone.de (Postfix) with ESMTPS id A5D818D4A215
	for ; Fri,  9 Sep 2022 17:32:32 +0000 (UTC)
Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPS id 3B07D5C3A831
	for ; Fri,  9 Sep 2022 17:32:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024)
	with ESMTP id zI1gvE09xaPp for ;
	Fri,  9 Sep 2022 17:32:30 +0000 (UTC)
Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPSA id DC30E5C3A82F
	for ; Fri,  9 Sep 2022 17:32:30 +0000 (UTC)
Date: Fri, 9 Sep 2022 17:32:30 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: current@FreeBSD.org
Subject: Realtek rtw89 - in main - help request (fwd)
Message-ID: 
X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1662744754;
	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=NIFltIW07s9IWTqPm+mGfa88ExiQrgl2iagVAwTSWUM=;
	b=UaCbZ/+yiJ18/c2T06cBizMKm+3JrT8nK6oVAsCjpFDw2grsUaPMmJvelXB47ysm58gN99
	K0RLPETuecZ7beZebVSldTSdJTtpRirWpLZBy9eQcAKKEBOLg0L0BDsJa0cO+NwZ7RhSQE
	BCtSZp0bWdHMvt3T/nrEj6LoDmioDVsQFMqoSxVxf1zjDwUYuKEvnsNOlDtR0u74kkrwBC
	Nt2Vglze709IvJAfRuz8OZwv3QEX1aMNux5jCh2VKypvqiK2LHG6QoYzCZh5lpNfGTezBb
	2RPJuO/CNrxoTJBcNampQWWsXhIk8mMSCw/RLo+GqS9YKk5JGJikjqJteXDwCQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662744754; a=rsa-sha256; cv=none;
	b=rS3Wj1BrLKFZaVArqR+woYY3DpPUX0Pf2wW0dqfubUEro79GtsF29pv11LCeGVcPo/2zZF
	2k5EBJISU76Ih0/D3Y3mcaD3t6v19a36hogHesWSzzDD9WqF2e/4Lcdm4xJy5VvLiUE0fU
	TUVI+/RrFemskcWIOj58d15M012CNwnetGdCyia1JIoKhsLOCnn7zI4OKBszPdEGHrsRbz
	FQj+cGs3poKsZE3lfSjVcRPgd9m7TBdZOiV9iLeRj8XE2OvZrEB4WrSNCytHM9iaNeqRvX
	sc19cF0I8eQtHhtB5ozNr+XrMIYev2MG7iiVl5AZcKW2BGxc5I0GpZ4XyGiEAg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

Hi,

I figured not all may follow freebsd-wireless so forwarding here.
Please follow-up on freebsd-wireless or with me if possible.

Lots of joy,
/bz

-- 
Bjoern A. Zeeb                                                     r15:7

---------- Forwarded message ----------
Date: Fri, 9 Sep 2022 16:49:38 +0000 (UTC)
From: Bjoern A. Zeeb 
To: FreeBSD wireless mailing list 
Subject: Realtek rtw89 - in main - help request

Hi,

I just added Realtek's rtw89 driver to main (CURRENT, HEAD we have too
many names for that since CVS days).  I've been sitting for too long on
it (almost done) and figured that "you" could help if it was available.

It is still disconected from the build, the man page is missing, .. but
if added to sys/modules/Makefile would compile, load, load firmware,
create a wireless interface, scan...

I'll update https://wiki.freebsd.org/WiFi/Rtw89 in a bit to add any
news I can think of.

*** Important for rtw89 owners ***

I know I exchanged emails with some of you before.
If you have an rtw89 (89 not 88!) please drop me a line and mention
(1) if you want to test as-is now;  it would be good if the current
     state as I see it can be replicated
(2) are able to help debugging and/or implementing what is left to pass
     packets
(3) you cannot do (2) but you'd be willing to test changes if (1) worked
     for you.

I'll be at EuroBSDCon next week, so my reply time may vary.  If you have
an rtw89 and be there definitively corner me! :)

Thakns a lot,
Bjoern

-- 
Bjoern A. Zeeb                                                     r15:7


From nobody Mon Sep 12 09:29:32 2022
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 4MR1Wx6fzHz4c0ty
	for ; Mon, 12 Sep 2022 09:29:33 +0000 (UTC)
	(envelope-from freqlabs@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MR1Wx69wKz3Zvw
	for ; Mon, 12 Sep 2022 09:29:33 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1662974973;
	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=TfZskDPc6gFRV0py0t5ZO29ObvMVRsNDxO1Hsz2ZFY4=;
	b=gsknyPOikpXxXJ7vMJ0W6IAor/d62elSGQmB60FqP3wyfV4Y/aAuCFPXPEqcS6lFSFGoYG
	Jrs1WKZdtC6mcAQ/cDycZu4JMYZD34Ehu/idpMfYC1Fjf7b+N7oF5y8wriui2qMSJKdCcp
	YVTDj6ajruNnQnXk5KPy6thPoy635xYIrIWQSRXzbWAbEN1FNQHupyWURRKksEg8d6fHAI
	A9DhdhGIF7DipGQ+mDHyemU47r9zn89lwTwmCw9EljQRrPrkbUY5HEW9sYFsEPgtneI01b
	UXc7KJBpNp6WJvaYGfHkJ86wqawlclWjO7z2TEDNU01hJh9ov1lPJXg+NsJwbw==
Received: from [192.168.1.66] (69-228-200-148.lightspeed.knvltn.sbcglobal.net [69.228.200.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)
	(Authenticated sender: freqlabs/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MR1Wx4PYyzTDP
	for ; Mon, 12 Sep 2022 09:29:33 +0000 (UTC)
	(envelope-from freqlabs@FreeBSD.org)
Message-ID: <5cb26532-11d6-60cb-bbd8-4fa99db83a32@FreeBSD.org>
Date: Mon, 12 Sep 2022 05:29:32 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.13.0
Subject: Re: Beadm can't create snapshot
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <01000182e9f49b75-35f2fff9-c6f9-4b37-8e4c-263309620d31-000000@email.amazonses.com>
 
From: Ryan Moeller 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1662974973;
	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=TfZskDPc6gFRV0py0t5ZO29ObvMVRsNDxO1Hsz2ZFY4=;
	b=G0JbL9jkDgvhh8A2Tz72yTCWWn+/iMW3KARd6zu55yyv3QZzTA5bxwok/WvmcwjzY0ZgRx
	51KZmN7WLu/mLxrv3UW3Z8auSF/c2izjuSRmq1y5WP+HVyvIHh5d5I3zohJKBI6uUoSKJJ
	NzSHJ9rrPLYzRUnGz07zETo0b7RNf758UnTyZixd1x6z5I4/f9/hCFEGBnHNKQLKgYonK+
	oHk/Jhn3Tpj4CMw04SSBtFlWCciqtGyBlSxaC1cK/30AfP5lrFO9bSy9YhUeYLBB2ILAjm
	O40EhniK12OkLq8eHw9KQGvV4I8b2Hz4W+VU5AOoGfeL8VzaR+IIpG16yrV77Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662974973; a=rsa-sha256; cv=none;
	b=UqrDAGs+JYp9d7AtoGSkTTq5WEDN2vDA2eoHVJhz+UKsBIHHRHefZFz0K/udq0f6/9yHRT
	4CaEF/NU3FWOwGodhtthpl/Ta+jG8+rPzDiv5/M3kJGSYOaN5pJGmMpQl8FUPmuAtYKAcV
	9EEoINBBfaBXuGFiMTjDtxLIweUMwsd8RS+P3ts3VS1YXCi4VNbJU7cQs4rdVlFsjc81D+
	GSmdl2ESA441p22FUg2usIigpqHpe8KD4kePptu7M/q/ZGrItYzwOreisv4n6wbHFzyitN
	L7Nu0EyTqZ3mSVos+UrJ0qphPH34XLXBVNbA43ysy0mYfqPr8DtbNVJyAp5tPQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


On 8/29/22 11:28 AM, Ryan Moeller wrote:
>
> On 8/29/22 10:14 AM, Thomas Laus wrote:
>> On 8/17/22 10:35, Thomas Laus wrote:
>>> I attempted to create a ZFS snapshot after upgrading this morning 
>>> and received this error
>>>
>> After all of the discussion to compare and contrast beadm vs. bectl 
>> my read only bit is still set as of this morning 29-AUG-2022.
>>
>> # beadm create n257658
>> cannot create 'zroot/ROOT/n257658': 'snapshots_changed' is readonly
>> #
>>
>> I thought that this 'feature' was fixed a while ago.
>>
>> Tom
>>
>
> It's fixed but it's not going to fix datasets that have been 
> snapshotted with the bug. The bug was that the property was stored in 
> a ZAP that ZFS assumes contains only local properties. The fix is to 
> store the property in a different ZAP, but if you already have it in 
> the wrong ZAP it overrides the one stored in the correct place. I'm 
> going to do some testing today and throw together a temporary patch 
> that will remove it.
>
> -Ryan
>
>
Here's the patch for the kernel and brief instructions:

https://reviews.freebsd.org/P547

-Ryan

From nobody Mon Sep 12 12:10:44 2022
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 4MR63m2qfGz4cRLT;
	Mon, 12 Sep 2022 12:53:56 +0000 (UTC)
	(envelope-from dsl@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MR63m2S95z3nkT;
	Mon, 12 Sep 2022 12:53:56 +0000 (UTC)
	(envelope-from dsl@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1662987236;
	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=vLp+XGXa+qCOi+kDCBACiyV2vhs4+LMtmCGw8l06dyY=;
	b=nXh15A1NCc0YSrlHe3bayr7yMVOtXDXweM9csa1yWgbizB+ZsMOnxqo2cPlzKWIgLqy7w/
	IBr+3SEwkp5Qy7XbAnOE3vD0QpGiiW8ZRK7U8jFGbuALB1jj++f90yLdB5TqrUfsEzee9q
	zXVO+HeCb5pse+gqzaP4qkfFYjDFJLGsoxKOURV5CJUgarzJxTPpM+WQtNhZc0wjDi0IaB
	cH7qVys4wdkTqFRGa1vKwj+0TLqPiSUkddalRkhlLoDRYrbiP04262ivsh/oAvkPXYbHbH
	KqsIoCaXjhVai2TLygq21lCQFF0i/lT9NbwDZgLyr6n7djFOtfJKI1WqSEXsTA==
Received: from localhost (bmj149.neoplus.adsl.tpnet.pl [83.28.229.149])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	(Authenticated sender: dsl)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MR63l3KrnzTrr;
	Mon, 12 Sep 2022 12:53:55 +0000 (UTC)
	(envelope-from dsl@FreeBSD.org)
References: 
 
 <1800459695.1.1646649539521@mailrelay>
 <132978150.92.1646660769467@mailrelay> 
 <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz>
  <20220308154204.GA37265@www.zefox.net>
User-agent: mu4e 1.6.10; emacs 28.1
From: Dmitry Salychev 
To: bob prohaska 
Cc: Mark Johnston , Andrew Turner ,
 Ronald Klop , Mark Millard ,
 freebsd-arm@freebsd.org, freebsd-current@freebsd.org
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64
 Feb 28))
Date: Mon, 12 Sep 2022 14:10:44 +0200
In-reply-to: <20220308154204.GA37265@www.zefox.net>
Message-ID: <86czc0eotc.fsf@peasant.tower.home>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1662987236;
	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=vLp+XGXa+qCOi+kDCBACiyV2vhs4+LMtmCGw8l06dyY=;
	b=qT3NCvCwgF6PbUkcfLsb3AKWznrCCvQo0vIl27bGcrnRy1vvHNnsHiZB0YJenX9SbvQMl5
	gpBKz6V1SIT0frhyKRdeu6NV886MeA3n7Q5BzPD9NnPriI54sjQLaa9s/6CcEym3k/Clwd
	GyhjbS7d+BRDxetj/xidgZDZ3AcUo4Y8zOFasAW8rwjwkhNmWscUiYMWjxbfXidr0lMJ5Q
	j0yxEcLpFpE8lCuafWC34aYlG3e5qTeaCWq4O4Zki4k1792qbNwBfgt22jNwDputpvHeRB
	a3MYdkrYibDEqk8KZIk8wZ1IXI35T5DoFDxiLeEEJUxyNGJH6V6b+GY5u00m4A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662987236; a=rsa-sha256; cv=none;
	b=fSnK2WajqNveM8tkHybFOtK0HeGsPpnRbt6WJyNvOB93uehPQe0I0vBmXYF9dEOjca2VAV
	pleLTGJ0465zvP92TgC3dWa9nwgL25t6xrSHHj7JM4HRxp3tjNSqSnT/stiVzUyojAzdw/
	sW2AizgiWm1k2Z8O2tsyTP0QGUDmoXSdsaHdjuUHFSKwQWa0OKw6dO5Rf3pQ3lsi/KtPpm
	4cAgYe9tk/LU+FRV/PluivGFG2DRuBKfgFBMSpwlX29JOeQFBFq5B+3ftlHC2lu7wcqJ0o
	NtYD2gvwJn9E9plzYyw1+GTx2CXJkKJVy24xowOEpZs1/kQqI8tNGFpvSzurfQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--=-=-=
Content-Type: text/plain
Content-Disposition: attachment; filename=dpaa2_panics.txt

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff000000460268 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff000000460018 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077c05c in do_el1h_sync (td=0xffffa000006d8000, frame=0xffff0000b23a24c0) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  0xffff000000760d40 in arm_gic_v3_intr (arg=0xffffa000021ab000) at /usr/src/sys/arm64/arm64/gic_v3.c:505
#7  0xffff00000074be4c in intr_irq_handler (tf=0xffff0000b23a26e0) at /usr/src/sys/kern/subr_intr.c:327
#8  0xffff00000074be4c in intr_irq_handler (tf=0xffffa000006d8000) at /usr/src/sys/kern/subr_intr.c:327
#9  
#10 cpu_idle (busy=) at /usr/src/sys/arm64/arm64/machdep.c:257
#11 0xffff000000491ab4 in sched_idletd (dummy=dummy@entry=0x0) at /usr/src/sys/kern/sched_ule.c:3070
#12 0xffff000000416440 in fork_exit (callout=0xffff00000049163c , arg=0x0, frame=0xffff0000b23a2990) at /usr/src/sys/kern/kern_fork.c:1102
#13 

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff000000460268 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff000000460018 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077c05c in do_el1h_sync (td=0xffffa000024b5600, frame=0xffff0000bcda29c0) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  0xffff0000004ced5c in witness_lock (lock=lock@entry=0xffffa0000056ca20, flags=8, file=file@entry=0xffff00000093011e "/usr/src/sys/dev/dpaa2/dpaa2_swp.c", line=line@entry=795) at /usr/src/sys/kern/subr_witness.c:1505
#7  0xffff00000043a3a8 in __mtx_lock_flags (c=0xffffa0000056ca38, opts=0, file=0xffff00000093011e "/usr/src/sys/dev/dpaa2/dpaa2_swp.c", line=795) at /usr/src/sys/kern/kern_mutex.c:290
#8  0xffff0000007d60a8 in dpaa2_swp_enq_mult (swp=swp@entry=0xffffa0000056ca00, ed=ed@entry=0xffff0000bcda2c70, fd=fd@entry=0xffff0000bcda2df8, flags=flags@entry=0xffff0000bcda2c6c, frames_n=frames_n@entry=1) at /usr/src/sys/dev/dpaa2/dpaa2_swp.c:795
#9  0xffff0000007d445c in dpaa2_io_enq_multiple_fq (iodev=, fqid=, fd=0xffff00000093011e, frames_n=1473863424) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:343
#10 0xffff0000007d7e3c in DPAA2_SWP_ENQ_MULTIPLE_FQ (fqid=205, fd=0xffff0000bcda2df8, frames_n=1, dev=) at ./dpaa2_swp_if.h:45
#11 dpaa2_ni_tx (sc=, tx=, m=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2717
#12 dpaa2_ni_transmit (ifp=, m=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2374
#13 0xffff0000005878bc in ether_output_frame (ifp=ifp@entry=0xffffa00002550800, m=0x8, m@entry=0xffffa00032552900) at /usr/src/sys/net/if_ethersubr.c:513
#14 0xffff0000005876f4 in ether_output (ifp=0xffffa00002550800, m=0xffffa00032552900, dst=0xffffa00028010b68, ro=0xffffa00028010b48) at /usr/src/sys/net/if_ethersubr.c:436
#15 0xffff0000005dff2c in ip_output (m=0xffff00000093011e, m@entry=0xffffa00032552900, opt=, ro=0xffffa00028010b48, flags=, imo=0x0, inp=0xffffa000280109f0) at /usr/src/sys/netinet/ip_output.c:793
#16 0xffff0000005f7204 in tcp_default_output (tp=0xffff000111f72590) at /usr/src/sys/netinet/tcp_output.c:1542
#17 0xffff0000005f0ca4 in tcp_output (tp=0xffff000111f72590) at /usr/src/sys/netinet/tcp_var.h:407
#18 tcp_do_segment (m=0xffffa08004b26d00, th=0xffff00011d8ec0e2, so=0xffff000111f27d80, tp=0xffff000111f72590, drop_hdrlen=52, tlen=, iptos=) at /usr/src/sys/netinet/tcp_input.c:3294
#19 0xffff0000005ee094 in tcp_input_with_port (mp=, offp=, proto=, port=0) at /usr/src/sys/netinet/tcp_input.c:1425
#20 0xffff0000005eee70 in tcp_input (mp=0xffffa0000056ca20, offp=0x8, proto=9634078) at /usr/src/sys/netinet/tcp_input.c:1520
#21 0xffff0000005dbed4 in ip_input (m=0x0) at /usr/src/sys/netinet/ip_input.c:838
#22 0xffff0000005a4110 in netisr_dispatch_src (proto=1, source=0, m=0xffffa08004b26d00) at /usr/src/sys/net/netisr.c:1153
#23 0xffff0000005a44c0 in netisr_dispatch (proto=5687840, m=0xffff00000093011e) at /usr/src/sys/net/netisr.c:1244
#24 0xffff000000587a64 in ether_demux (ifp=ifp@entry=0xffffa00002550800, m=0x8) at /usr/src/sys/net/if_ethersubr.c:925
#25 0xffff0000005890e0 in ether_input_internal (ifp=0xffffa00002550800, m=0x8) at /usr/src/sys/net/if_ethersubr.c:711
#26 ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:741
#27 0xffff0000005a4110 in netisr_dispatch_src (proto=proto@entry=5, source=0, m=m@entry=0xffffa08004b26d00) at /usr/src/sys/net/netisr.c:1153
#28 0xffff0000005a44c0 in netisr_dispatch (proto=5687840, proto@entry=5, m=0xffff00000093011e, m@entry=0xffffa08004b26d00) at /usr/src/sys/net/netisr.c:1244
#29 0xffff000000587f24 in ether_input (ifp=0xffffa00002550800, m=0xffffa08004b26d00) at /usr/src/sys/net/if_ethersubr.c:832
#30 0xffff0000007dc3c8 in dpaa2_ni_rx (chan=0xffff0000be8f5000, fq=, fd=0xffff0000befb1360) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2870
#31 0xffff0000007dbf40 in dpaa2_ni_consume_frames (chan=0xffff0000be8f5000, src=, consumed=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2763
#32 dpaa2_ni_poll (arg=0xffff0000be8f5000) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2633
#33 0xffff0000007d4ac8 in dpaa2_io_intr (arg=0xffffa000006c7c00) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:540
#34 0xffff000000419f54 in intr_event_execute_handlers (ie=0xffffa00000576200, p=) at /usr/src/sys/kern/kern_intr.c:1205
#35 ithread_execute_handlers (ie=0xffffa00000576200, p=) at /usr/src/sys/kern/kern_intr.c:1218
#36 ithread_loop (arg=, arg@entry=0xffffa000006c0a00) at /usr/src/sys/kern/kern_intr.c:1306
#37 0xffff000000416440 in fork_exit (callout=0xffff000000419cac , arg=0xffffa000006c0a00, frame=0xffff0000bcda3990) at /usr/src/sys/kern/kern_fork.c:1102
#38 

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff000000460268 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff000000460018 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077c05c in do_el1h_sync (td=0xffffa000024b5600, frame=0xffff0000bcda2db0) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  0xffff0000005dee5c in ip_output (m=, m@entry=0xffffa00007036700, opt=, ro=0xffffa0006d1f5e98, flags=0, imo=0x0, inp=0xffffa0006d1f5d40) at /usr/src/sys/sys/mbuf.h:1533
#7  0xffff0000005f7204 in tcp_default_output (tp=0xffff00011e090450) at /usr/src/sys/netinet/tcp_output.c:1542
#8  0xffff0000005f0ca4 in tcp_output (tp=0xffff00011e090450) at /usr/src/sys/netinet/tcp_var.h:407
#9  tcp_do_segment (m=0xffffa00007036700, th=0xffff00011d71e0e2, so=0xffff00011cd8d680, tp=0xffff00011e090450, drop_hdrlen=52, tlen=, iptos=) at /usr/src/sys/netinet/tcp_input.c:3294
#10 0xffff0000005ee094 in tcp_input_with_port (mp=, offp=, proto=, port=0) at /usr/src/sys/netinet/tcp_input.c:1425
#11 0xffff0000005eee70 in tcp_input (mp=0xffffa00007036770, offp=0x1, proto=9323951) at /usr/src/sys/netinet/tcp_input.c:1520
#12 0xffff0000005dbed4 in ip_input (m=0x0) at /usr/src/sys/netinet/ip_input.c:838
#13 0xffff0000005a4110 in netisr_dispatch_src (proto=1, source=0, m=0xffffa00007036700) at /usr/src/sys/net/netisr.c:1153
#14 0xffff0000005a44c0 in netisr_dispatch (proto=117663600, m=0xffff0000008e45af) at /usr/src/sys/net/netisr.c:1244
#15 0xffff000000587a64 in ether_demux (ifp=ifp@entry=0xffffa00002550800, m=0x1) at /usr/src/sys/net/if_ethersubr.c:925
#16 0xffff0000005890e0 in ether_input_internal (ifp=0xffffa00002550800, m=0x1) at /usr/src/sys/net/if_ethersubr.c:711
#17 ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:741
#18 0xffff0000005a4110 in netisr_dispatch_src (proto=proto@entry=5, source=0, m=m@entry=0xffffa00007036700) at /usr/src/sys/net/netisr.c:1153
#19 0xffff0000005a44c0 in netisr_dispatch (proto=117663600, proto@entry=5, m=0xffff0000008e45af, m@entry=0xffffa00007036700) at /usr/src/sys/net/netisr.c:1244
#20 0xffff000000587f24 in ether_input (ifp=0xffffa00002550800, m=0xffffa00007036700) at /usr/src/sys/net/if_ethersubr.c:832
#21 0xffff0000007dc3c8 in dpaa2_ni_rx (chan=0xffff0000be8f5000, fq=, fd=0xffff0000befb1260) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2870
#22 0xffff0000007dbf40 in dpaa2_ni_consume_frames (chan=0xffff0000be8f5000, src=, consumed=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2763
#23 dpaa2_ni_poll (arg=0xffff0000be8f5000) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2633
#24 0xffff0000007d4ac8 in dpaa2_io_intr (arg=0xffffa000006c7c00) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:540
#25 0xffff000000419f54 in intr_event_execute_handlers (ie=0xffffa00000576200, p=) at /usr/src/sys/kern/kern_intr.c:1205
#26 ithread_execute_handlers (ie=0xffffa00000576200, p=) at /usr/src/sys/kern/kern_intr.c:1218
#27 ithread_loop (arg=, arg@entry=0xffffa000006c0a00) at /usr/src/sys/kern/kern_intr.c:1306
#28 0xffff000000416440 in fork_exit (callout=0xffff000000419cac , arg=0xffffa000006c0a00, frame=0xffff0000bcda3990) at /usr/src/sys/kern/kern_fork.c:1102
#29 

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff000000460268 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff000000460018 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077c05c in do_el1h_sync (td=0xffffa08070a06600, frame=0xffff000111df33d0) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  0xffff0000004ced5c in witness_lock (lock=lock@entry=0xffff00011d2c2420, flags=8, file=file@entry=0xffff000000860324 "/usr/src/sys/kern/uipc_socket.c", line=line@entry=2240) at /usr/src/sys/kern/subr_witness.c:1505
#7  0xffff00000043a3a8 in __mtx_lock_flags (c=0xffff00011d2c2438, opts=0, file=0xffff000000860324 "/usr/src/sys/kern/uipc_socket.c", line=2240) at /usr/src/sys/kern/kern_mutex.c:290
#8  0xffff000000508f54 in soreceive_generic (so=0xffff00011d2c2200, psa=0x0, uio=, mp0=, controlp=0x0, flagsp=) at /usr/src/sys/kern/uipc_socket.c:2240
#9  0xffff00000050a57c in soreceive (so=0xffff00011d2c2420, psa=0x8, uio=0xffff000000860324, mp0=0x8c0, controlp=0xffffa08157d8c800, flagsp=0x10) at /usr/src/sys/kern/uipc_socket.c:2839
#10 0xffff0000004d37f4 in fo_read (fp=0xffffa0002f5215f0, uio=0xffff000111df3780, active_cred=0xffff000000860324, flags=0, td=0xffffa08070a06600) at /usr/src/sys/sys/file.h:341
#11 dofileread (td=td@entry=0xffffa08070a06600, fd=fd@entry=5, fp=0xffffa0002f5215f0, auio=auio@entry=0xffff000111df3780, offset=, flags=0) at /usr/src/sys/kern/sys_generic.c:369
#12 0xffff0000004d3460 in kern_readv (td=0xffffa08070a06600, fd=5, auio=auio@entry=0xffff000111df3780) at /usr/src/sys/kern/sys_generic.c:290
#13 0xffff0000004d3400 in sys_read (td=0xffff00011d2c2420, uap=) at /usr/src/sys/kern/sys_generic.c:206
#14 0xffff00000077c8c4 in syscallenter (td=0xffffa08070a06600) at /usr/src/sys/arm64/arm64/../../kern/subr_syscall.c:189
#15 svc_handler (td=0xffffa08070a06600, frame=) at /usr/src/sys/arm64/arm64/trap.c:199
#16 do_el0_sync (td=0xffffa08070a06600, frame=) at /usr/src/sys/arm64/arm64/trap.c:603
#17 
#18 0x00000000859c9ef0 in ?? ()
#19 0x0000000088c00000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff000000460268 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff000000460018 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077c05c in do_el1h_sync (td=0xffffa000022b3000, frame=0xffff0000bcd79f90) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  0xffff0000004ced5c in witness_lock (lock=0xffff000000e31b00 , flags=8, file=0xffff0000008e30ac "/usr/src/sys/kern/kern_timeout.c", line=582) at /usr/src/sys/kern/subr_witness.c:1505
#7  0xffff00000047d4ec in callout_lock (c=0xffff0001121792c0) at /usr/src/sys/kern/kern_timeout.c:582
#8  callout_reset_sbt_on (c=0xffff0001121792c0, sbt=, prec=, ftn=0xffff00000047d4ec , arg=0xffff000112179000, cpu=0, flags=256) at /usr/src/sys/kern/kern_timeout.c:962
#9  0xffff0000005f0480 in tcp_do_segment (m=0xffffa08089e89c00, th=0xffff00011c8150e2, so=0xffff00011cd40b00, tp=, drop_hdrlen=52, tlen=, iptos=) at /usr/src/sys/netinet/tcp_input.c:2913
#10 0xffff0000005ee094 in tcp_input_with_port (mp=, offp=, proto=, port=0) at /usr/src/sys/netinet/tcp_input.c:1425
#11 0xffff0000005eee70 in tcp_input (mp=0xffff000000e31b00 , offp=0x8, proto=9318572) at /usr/src/sys/netinet/tcp_input.c:1520
#12 0xffff0000005dbed4 in ip_input (m=0x0) at /usr/src/sys/netinet/ip_input.c:838
#13 0xffff0000005a4110 in netisr_dispatch_src (proto=1, source=0, m=0xffffa08089e89c00) at /usr/src/sys/net/netisr.c:1153
#14 0xffff0000005a44c0 in netisr_dispatch (proto=14883584, m=0xffff0000008e30ac) at /usr/src/sys/net/netisr.c:1244
#15 0xffff000000587a64 in ether_demux (ifp=ifp@entry=0xffffa00002350800, m=0x8) at /usr/src/sys/net/if_ethersubr.c:925
#16 0xffff0000005890e0 in ether_input_internal (ifp=0xffffa00002350800, m=0x8) at /usr/src/sys/net/if_ethersubr.c:711
#17 ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:741
#18 0xffff0000005a4110 in netisr_dispatch_src (proto=proto@entry=5, source=0, m=m@entry=0xffffa08089e89c00) at /usr/src/sys/net/netisr.c:1153
#19 0xffff0000005a44c0 in netisr_dispatch (proto=14883584, proto@entry=5, m=0xffff0000008e30ac, m@entry=0xffffa08089e89c00) at /usr/src/sys/net/netisr.c:1244
#20 0xffff000000587f24 in ether_input (ifp=0xffffa00002350800, m=0xffffa08089e89c00) at /usr/src/sys/net/if_ethersubr.c:832
#21 0xffff0000007dc3c8 in dpaa2_ni_rx (chan=0xffff0000bf737000, fq=, fd=0xffff0000bfdf30a0) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2870
#22 0xffff0000007dbf40 in dpaa2_ni_consume_frames (chan=0xffff0000bf737000, src=, consumed=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2763
#23 dpaa2_ni_poll (arg=0xffff0000bf737000) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2633
#24 0xffff0000007d4ac8 in dpaa2_io_intr (arg=0xffffa000006c6180) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:540
#25 0xffff000000419f54 in intr_event_execute_handlers (ie=0xffffa00000576500, p=) at /usr/src/sys/kern/kern_intr.c:1205
#26 ithread_execute_handlers (ie=0xffffa00000576500, p=) at /usr/src/sys/kern/kern_intr.c:1218
#27 ithread_loop (arg=, arg@entry=0xffffa000006c0a60) at /usr/src/sys/kern/kern_intr.c:1306
#28 0xffff000000416440 in fork_exit (callout=0xffff000000419cac , arg=0xffffa000006c0a60, frame=0xffff0000bcd7a990) at /usr/src/sys/kern/kern_fork.c:1102
#29 

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff00000045d214 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff00000045cfc4 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077385c in do_el1h_sync (td=0xffffa00001d61000, frame=0xffff0000bc7b26a0) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  sleepq_switch (wchan=0xffffa00000724780, wchan@entry=0x0, pri=0, pri@entry=7489536) at /usr/src/sys/kern/subr_sleepqueue.c:613
#7  0xffff0000004b8994 in sleepq_wait (wchan=, pri=) at /usr/src/sys/kern/subr_sleepqueue.c:660
#8  0xffff000000469134 in _sleep (ident=0xffffa00000724780, lock=0xffffa00000724800, priority=0, wmesg=0xffff000000885cee "-", sbt=0, pr=0, flags=256) at /usr/src/sys/kern/kern_synch.c:225
#9  0xffff0000004bed64 in TQ_SLEEP (tq=0xffffa00000724780, p=0xffffa00000724780, wm=) at /usr/src/sys/kern/subr_taskqueue.c:126
#10 taskqueue_thread_loop (arg=arg@entry=0xffff0000bd74e5a0) at /usr/src/sys/kern/subr_taskqueue.c:834
#11 0xffff000000413568 in fork_exit (callout=0xffff0000004beca8 , arg=0xffff0000bd74e5a0, frame=0xffff0000bc7b2990) at /usr/src/sys/kern/kern_fork.c:1102
#12 

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff00000045d214 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff00000045cfc4 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077385c in do_el1h_sync (td=0xffffa00001ab8600, frame=0xffff0000bc7a2f50) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  mb_dtor_mbuf (mem=0xffffa0001d418800, size=256, arg=0x0) at /usr/src/sys/kern/kern_mbuf.c:681
#7  0xffff000000703e4c in item_dtor (zone=zone@entry=0xffff000041b5f000, item=item@entry=0xffffa0001d418800, size=256, udata=udata@entry=0x0, skip=) at /usr/src/sys/vm/uma_core.c:3488
#8  0xffff000000702a08 in uma_zfree_arg (zone=0xffff000041b5f000, item=item@entry=0xffffa0001d418800, udata=0x0) at /usr/src/sys/vm/uma_core.c:4493
#9  0xffff0000004332cc in mb_free_ext (m=m@entry=0xffffa0001d418800) at /usr/src/sys/kern/kern_mbuf.c:1212
#10 0xffff000000431c2c in m_free (m=0xffffa0001d418800) at /usr/src/sys/sys/mbuf.h:1523
#11 0xffff00000043303c in m_freem (mb=0xffff000000432194 , mb@entry=0xffff00011d95f590) at /usr/src/sys/kern/kern_mbuf.c:1571
#12 0xffff0000005012fc in sbdrop (sb=sb@entry=0xffff00011c921310, len=, len@entry=2896) at /usr/src/sys/kern/uipc_sockbuf.c:1654
#13 0xffff0000005ebfec in tcp_do_segment (m=0xffffa08148514300, th=0xffff00011bbee0e2, so=0xffff00011c921000, tp=0xffff00011d95f590, drop_hdrlen=52, tlen=, iptos=) at /usr/src/sys/netinet/tcp_input.c:1850
#14 0xffff0000005e829c in tcp_input_with_port (mp=, offp=, proto=, port=0) at /usr/src/sys/netinet/tcp_input.c:1425
#15 0xffff0000005e9078 in tcp_input (mp=0xffffa0001d418800, offp=0x100, proto=0) at /usr/src/sys/netinet/tcp_input.c:1520
#16 0xffff0000005d60dc in ip_input (m=0x0) at /usr/src/sys/netinet/ip_input.c:838
#17 0xffff00000059e3b0 in netisr_dispatch_src (proto=1, source=0, m=0xffffa08148514300) at /usr/src/sys/net/netisr.c:1153
#18 0xffff00000059e760 in netisr_dispatch (proto=490833920, m=0x0) at /usr/src/sys/net/netisr.c:1244
#19 0xffff000000581dcc in ether_demux (ifp=ifp@entry=0xffffa00001b57800, m=0x100) at /usr/src/sys/net/if_ethersubr.c:925
#20 0xffff000000583430 in ether_input_internal (ifp=0xffffa00001b57800, m=0x100) at /usr/src/sys/net/if_ethersubr.c:711
#21 ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:741
#22 0xffff00000059e3b0 in netisr_dispatch_src (proto=proto@entry=5, source=0, m=m@entry=0xffffa08148514300) at /usr/src/sys/net/netisr.c:1153
#23 0xffff00000059e760 in netisr_dispatch (proto=490833920, proto@entry=5, m=0x0, m@entry=0xffffa08148514300) at /usr/src/sys/net/netisr.c:1244
#24 0xffff00000058228c in ether_input (ifp=0xffffa00001b57800, m=0xffffa08148514300) at /usr/src/sys/net/if_ethersubr.c:832
#25 0xffff0000007d3bc4 in dpaa2_ni_rx (chan=0xffff0000be1d1000, fq=, fd=0xffff0000be88d060) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2879
#26 0xffff0000007d37a8 in dpaa2_ni_consume_frames (chan=0xffff0000be1d1000, src=, consumed=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2770
#27 dpaa2_ni_poll (arg=0xffff0000be1d1000) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2633
#28 0xffff0000007cc2a8 in dpaa2_io_intr (arg=0xffffa000006bfc00) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:540
#29 0xffff00000041707c in intr_event_execute_handlers (ie=0xffffa0000056e200, p=) at /usr/src/sys/kern/kern_intr.c:1205
#30 ithread_execute_handlers (ie=0xffffa0000056e200, p=) at /usr/src/sys/kern/kern_intr.c:1218
#31 ithread_loop (arg=, arg@entry=0xffffa000006b8a00) at /usr/src/sys/kern/kern_intr.c:1306
#32 0xffff000000413568 in fork_exit (callout=0xffff000000416dd4 , arg=0xffffa000006b8a00, frame=0xffff0000bc7a3990) at /usr/src/sys/kern/kern_fork.c:1102
#33 

---

Undefined instruction: f9401bf9
  x0:                0
  x1: ffffa0000073ae50
  x2:                1
  x3:                0
  x4:                0
  x5:                1
  x6:                0
  x7: ffff0000bc795c8c (_end + bb7e4c8c)
  x8:         9de11000
  x9:                0
 x10:                0
 x11:              1ff
 x12:              5a8
 x13:               42
 x14:         9ac68042
 x15:                1
 x16:            10000
 x17:          83cdd00
 x18: ffff0000bc795c50 (_end + bb7e4c50)
 x19:               1d
 x20: ffff0000bdebfc18 (_end + bcf0ec18)
 x21: ffffa00043275a00
 x22: ffff0000bd478000 (_end + bc4c7000)
 x23: ffff0000bdebfc20 (_end + bcf0ec20)
 x24: ffff0000bdebf1a0 (_end + bcf0e1a0)
 x25: ffff0000c0211000 (_end + bf260000)
 x26: ffff0000bde0e000 (_end + bce5d000)
 x27: ffff0000bde0e000 (_end + bce5d000)
 x28: ffff0000bdebfc08 (_end + bcf0ec08)
 x29: ffff0000bc795e20 (_end + bb7e4e20)
  sp: ffff0000bc795c50
  lr: ffff0000007cf584 (dpaa2_ni_transmit + 2bc)
 elr: ffff00000049c5c0 (bus_dmamap_load + 114)
spsr:         80000045
 far:     129a54403538
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 3
time = 1662915749
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x13c
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x194
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
bus_dmamap_load() at bus_dmamap_load+0x114
ether_output_frame() at ether_output_frame+0xd4
ether_output() at ether_output+0x640
ip_output() at ip_output+0x1264
tcp_default_output() at tcp_default_output+0x1eb4
tcp_do_segment() at tcp_do_segment+0x1da4
tcp_input_with_port() at tcp_input_with_port+0xc00
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x30c
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_demux() at ether_demux+0x174
ether_nh_input() at ether_nh_input+0x3ec
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_input() at ether_input+0x80
dpaa2_ni_rx() at dpaa2_ni_rx+0x174
dpaa2_ni_poll() at dpaa2_ni_poll+0xb8
dpaa2_io_intr() at dpaa2_io_intr+0x13c
ithread_loop() at ithread_loop+0x2a4
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100104 ]
Stopped at      kdb_enter+0x44: undefined       f900027f

---

Undefined instruction: a8c17bfd
  x0: ffffa00001ab6000
  x1: ffff0000bc78aaa0 (_end + bb7d9aa0)
  x2: ffff0000418f4300 (_end + 40943300)
  x3:              8e4
  x4: ffff0000bc78aaa0 (_end + bb7d9aa0)
  x5:                0
  x6:                0
  x7: ffff0000bc78a5dc (_end + bb7d95dc)
  x8:                0
  x9:                1
 x10:             2710
 x11:         7ff8d402
 x12:         7ff8a9fb
 x13:             2af8
 x14:             2a07
 x15:                0
 x16:                1
 x17:              100
 x18: ffff0000bc78a790 (_end + bb7d9790)
 x19: ffffa00001ab6000
 x20: ffffa000006d0000
 x21: ffff0000418f4300 (_end + 40943300)
 x22: ffff000000bb3000 (sdt_vfs_vop_vop_spare3_return + 58)
 x23: ffff000000e5ea58 (group + 40)
 x24:                0
 x25: ffff0000bc78a7b8 (_end + bb7d97b8)
 x26: ffff000000e00000 (thread0_st + 380)
 x27: ffff000000e55000 (kdb_why + 0)
 x28: ffff000000c3ee80 (pcpu_entry_tdq + 0)
 x29: ffff0000bc78a790 (_end + bb7d9790)
  sp: ffff0000bc78a790
  lr: ffff0000007734b4 (cpu_switch + 60)
 elr: ffff000000775540 (vfp_save_state + e0)
spsr:               c5
 far:         8649a000
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 7
time = 1662916027
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x13c
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x194
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
vfp_save_state() at vfp_save_state+0xe0
cpu_switch() at cpu_switch+0x5c
mi_switch() at mi_switch+0x184
ithread_loop() at ithread_loop+0x9c
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100100 ]
Stopped at      kdb_enter+0x44: undefined       f900027f

---

panic: mutex  not owned at /usr/src/sys/kern/uipc_socket.c:2187
cpuid = 7
time = 1662916786
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x13c
panic() at panic+0x44
__mtx_assert() at __mtx_assert+0xf0
soreceive_generic() at soreceive_generic+0x54c
soreceive() at soreceive+0x44
dofileread() at dofileread+0x7c
kern_readv() at kern_readv+0x50
sys_read() at sys_read+0x80
do_el0_sync() at do_el0_sync+0x54c
handle_el0_sync() at handle_el0_sync+0x40
--- exception, esr 0x56000000
KDB: enter: panic
[ thread pid 1991 tid 100180 ]
Stopped at      kdb_enter+0x44: undefined       f900027f

---

Undefined instruction: b9805668
  x0:                0
  x1: ffffa00001ab8600
  x2: ffff0000008998ad (do_execve.fexecv_proc_title + 10764)
  x3:               7e
  x4:               6d
  x5:               cb
  x6: ffff0000bc7a2cd8 (_end + bb7f1cd8)
  x7: ffff0000bc7a2cd4 (_end + bb7f1cd4)
  x8: ffffa00001ab8600
  x9:                2
 x10:                0
 x11: ffff000000ead678 (w_locklistdata + 3ff30)
 x12:                3
 x13:                2
 x14:            10000
 x15:                1
 x16:            10000
 x17:         f5fa4dfb
 x18: ffff0000bc7a2bc0 (_end + bb7f1bc0)
 x19: ffffa0001e44a400
 x20: ffff0000bc7a2cd4 (_end + bb7f1cd4)
 x21: ffff0000bc7a2cd8 (_end + bb7f1cd8)
 x22: ffffa0003b0379a4
 x23:               42
 x24: ffffa00001b5f400
 x25: ffffa0003b037962
 x26:              6c0
 x27: ffffa0003b038022
 x28:              962
 x29: ffff0000bc7a2be0 (_end + bb7f1be0)
  sp: ffff0000bc7a2bc0
  lr: ffff00000074da20 (bounce_bus_dmamap_load_buffer + d4)
 elr: ffff00000074db1c (bounce_bus_dmamap_load_buffer + 1d0)
spsr:         20000045
 far:         82f3fdac
panic: Unknown kernel exception 0 esr_el1 2000000
cpuid = 4
time = 1662917050
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x13c
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x194
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x2000000
bounce_bus_dmamap_load_buffer() at bounce_bus_dmamap_load_buffer+0x1d0
bus_dmamap_load_mbuf_sg() at bus_dmamap_load_mbuf_sg+0x88
dpaa2_ni_transmit() at dpaa2_ni_transmit+0x190
ether_output_frame() at ether_output_frame+0xd4
ether_output() at ether_output+0x640
ip_output() at ip_output+0x1264
tcp_default_output() at tcp_default_output+0x1eb4
tcp_output() at tcp_output+0x38
tcp_do_segment() at tcp_do_segment+0x28d8
tcp_input_with_port() at tcp_input_with_port+0xc00
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x30c
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_demux() at ether_demux+0x174
ether_nh_input() at ether_nh_input+0x3ec
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_input() at ether_input+0x80
dpaa2_ni_rx() at dpaa2_ni_rx+0x174
dpaa2_ni_poll() at dpaa2_ni_poll+0xb8
dpaa2_io_intr() at dpaa2_io_intr+0x13c
ithread_loop() at ithread_loop+0x2a4
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100103 ]
Stopped at      kdb_enter+0x44: undefined       f900027f

---

Fatal data abort:
  x0: ffffa00001ab6000
  x1: ffff0000bc785fb8 (_end + bb7d4fb8)
  x2: ffff000000928fa8 (console_pausestr + 24fd1)
  x3:               7e
  x4:               7e
  x5:               60
  x6: d28938770a080101
  x7: fc7aaec8d2893877
  x8:                0
  x9:                2
 x10:                2
 x11: ffff000000eada30 (w_locklistdata + 402e8)
 x12:                3
 x13:                2
 x14:                0
 x15:                1
 x16:                0
 x17:               28
 x18: ffff0000bc786030 (_end + bb7d5030)
 x19: ffff00011c52ecf0
 x20: ffff00011bb4a680
 x21: ffff00011c52ed10
 x22: ffffa0812fc9cd00
 x23: ffff00011c52ed08
 x24:              5a8
 x25: ffffa0812fc9cd84
 x26: ffff000000857a08 (cam_status_table + 4b60)
 x27: ffff000000bb3000 (sdt_vfs_vop_vop_spare3_return + 58)
 x28:                1
 x29: ffff0000bc786190 (_end + bb7d5190)
  sp: ffff0000bc786030
  lr: ffff0000005f126c (tcp_default_output + 1d18)
 elr: fffefffffc7f2b70
spsr:         20000045
 far: fffefffffc7f2b70
 esr:         86000004
panic: vm_fault failed: fffefffffc7f2b70 error 1
cpuid = 7
time = 1662983268
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x13c
panic() at panic+0x44
data_abort() at data_abort+0x2ec
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x86000004
(null)() at 0xfffffffffc7f2b70
tcp_do_segment() at tcp_do_segment+0x1da4
tcp_input_with_port() at tcp_input_with_port+0xc00
tcp_input() at tcp_input+0xc
ip_input() at ip_input+0x30c
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_demux() at ether_demux+0x174
ether_nh_input() at ether_nh_input+0x3ec
netisr_dispatch_src() at netisr_dispatch_src+0xe0
ether_input() at ether_input+0x80
dpaa2_ni_rx() at dpaa2_ni_rx+0x174
dpaa2_ni_poll() at dpaa2_ni_poll+0x140
dpaa2_io_intr() at dpaa2_io_intr+0x13c
ithread_loop() at ithread_loop+0x2a4
fork_exit() at fork_exit+0x74
fork_trampoline() at fork_trampoline+0x14
KDB: enter: panic
[ thread pid 12 tid 100100 ]
Stopped at      kdb_enter+0x44: undefined       f900027f
db>

---

(kgdb) bt
#0  breakpoint () at /usr/src/sys/arm64/include/cpufunc.h:36
#1  kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:508
#2  0xffff00000045d214 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:967
#3  0xffff00000045cfc4 in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:903
#4  0xffff00000077385c in do_el1h_sync (td=0xffffa00001ab6000, frame=0xffff0000bc785a30) at /usr/src/sys/arm64/arm64/trap.c:532
#5  
#6  bounce_bus_dmamap_load_buffer (dmat=0xffffa00001b5f400, map=0xffffa0001e4b7800, buf=0xffffa0005200ea62, buflen=66, pmap=0xffff000000fa1050 , 
    flags=, segs=0xffff0000bc785cd8, segp=0xffff0000bc785cd4) at /usr/src/sys/arm64/arm64/busdma_bounce.c:868
#7  0xffff00000049c7c4 in _bus_dmamap_load_buffer (dmat=0xffffa00001b5f400, map=0xffffa0001e4b7800, buf=0xffff0000008998ad, buflen=126, 
    pmap=0xffff000000fa1050 , flags=2049, segs=0xffff0000bc785cd8, segp=0xffff0000bc785cd4) at /usr/src/sys/arm64/include/bus_dma.h:129
#8  _bus_dmamap_load_mbuf_sg (m0=, nsegs=0xffff0000bc785cd4, flags=1, dmat=, map=, segs=)
    at /usr/src/sys/kern/subr_bus_dma.c:252
#9  bus_dmamap_load_mbuf_sg (dmat=0xffffa00001b5f400, map=0xffffa0001e4b7800, m0=, m0@entry=0xffffa0005200ea00, segs=segs@entry=0xffff0000bc785cd8, 
    nsegs=nsegs@entry=0xffff0000bc785cd4, flags=flags@entry=1) at /usr/src/sys/kern/subr_bus_dma.c:530
#10 0xffff0000007cf45c in dpaa2_ni_tx (sc=0xffff0000bd478000, tx=0xffff0000bf0c51a0, m=0xffffa0005200ea00) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2683
#11 dpaa2_ni_transmit (ifp=, m=0xffffa0005200ea00) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2374
#12 0xffff000000581c24 in ether_output_frame (ifp=ifp@entry=0xffffa00001b57800, m=0xffffa00001ab6000, m@entry=0xffffa0005200ea00)
    at /usr/src/sys/net/if_ethersubr.c:513
#13 0xffff000000581a5c in ether_output (ifp=0xffffa00001b57800, m=0xffffa0005200ea00, dst=0xffffa000495734c8, ro=0xffffa000495734a8)
    at /usr/src/sys/net/if_ethersubr.c:436
#14 0xffff0000005da134 in ip_output (m=0xffff0000008998ad, m@entry=0xffffa0005200ea00, opt=, ro=0xffffa000495734a8, flags=, imo=0x0, 
    inp=0xffffa00049573350) at /usr/src/sys/netinet/ip_output.c:793
#15 0xffff0000005f140c in tcp_default_output (tp=0xffff0000fe9fc000) at /usr/src/sys/netinet/tcp_output.c:1542
#16 0xffff0000005ec720 in tcp_output (tp=tp@entry=0xffff0000fe9fc000) at /usr/src/sys/netinet/tcp_var.h:407
#17 0xffff0000005eb9e0 in tcp_do_segment (m=, th=, so=0xffff00011c7d9680, tp=0xffff0000fe9fc000, drop_hdrlen=52, tlen=, 
    iptos=) at /usr/src/sys/netinet/tcp_input.c:1963
#18 0xffff0000005e829c in tcp_input_with_port (mp=, offp=, proto=, port=0) at /usr/src/sys/netinet/tcp_input.c:1425
#19 0xffff0000005e9078 in tcp_input (mp=0x0, offp=0xffffa00001ab6000, proto=9017517) at /usr/src/sys/netinet/tcp_input.c:1520
#20 0xffff0000005d60dc in ip_input (m=0x0) at /usr/src/sys/netinet/ip_input.c:838
#21 0xffff00000059e3b0 in netisr_dispatch_src (proto=1, source=0, m=0xffffa00052009c00) at /usr/src/sys/net/netisr.c:1153
#22 0xffff00000059e760 in netisr_dispatch (proto=0, m=0xffff0000008998ad) at /usr/src/sys/net/netisr.c:1244
#23 0xffff000000581dcc in ether_demux (ifp=ifp@entry=0xffffa00001b57800, m=0xffffa00001ab6000) at /usr/src/sys/net/if_ethersubr.c:925
#24 0xffff000000583430 in ether_input_internal (ifp=0xffffa00001b57800, m=0xffffa00001ab6000) at /usr/src/sys/net/if_ethersubr.c:711
#25 ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:741
#26 0xffff00000059e3b0 in netisr_dispatch_src (proto=proto@entry=5, source=0, m=m@entry=0xffffa00052009c00) at /usr/src/sys/net/netisr.c:1153
#27 0xffff00000059e760 in netisr_dispatch (proto=0, proto@entry=5, m=0xffff0000008998ad, m@entry=0xffffa00052009c00) at /usr/src/sys/net/netisr.c:1244
#28 0xffff00000058228c in ether_input (ifp=0xffffa00001b57800, m=0xffffa00052009c00) at /usr/src/sys/net/if_ethersubr.c:832
#29 0xffff0000007d3be4 in dpaa2_ni_rx (chan=0xffff0000bf014000, fq=, fd=0xffff0000bf6d00a0) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2879
#30 0xffff0000007d37c8 in dpaa2_ni_consume_frames (chan=0xffff0000bf014000, src=, consumed=) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2770
#31 dpaa2_ni_poll (arg=0xffff0000bf014000) at /usr/src/sys/dev/dpaa2/dpaa2_ni.c:2633
#32 0xffff0000007cc2c8 in dpaa2_io_intr (arg=0xffffa000006be180) at /usr/src/sys/dev/dpaa2/dpaa2_io.c:540
--Type  for more, q to quit, c to continue without paging--
#33 0xffff00000041707c in intr_event_execute_handlers (ie=0xffffa0000056e500, p=) at /usr/src/sys/kern/kern_intr.c:1205
#34 ithread_execute_handlers (ie=0xffffa0000056e500, p=) at /usr/src/sys/kern/kern_intr.c:1218
#35 ithread_loop (arg=, arg@entry=0xffffa000006b8a60) at /usr/src/sys/kern/kern_intr.c:1306
#36 0xffff000000413568 in fork_exit (callout=0xffff000000416dd4 , arg=0xffffa000006b8a60, frame=0xffff0000bc786990) at /usr/src/sys/kern/kern_fork.c:1102
#37 
(kgdb)

--=-=-=
Content-Type: text/plain


Hi,

It seems that the recent 14-CURRENT/aarch64 (866e021) with DPAA2 drivers
panics under network throughtput stress test in random places with
unknown kernel exception 0 esr_el1 2000000 on Ten64 board (based on
NXP's LS1088A, Cortex-A53), but the same code doesn't panic on HoneyComb
(NXP LX2160A, Cortex-A72) even after ~10h long tests.

I've gathered some stack backtraces from ddb and kgdb (attached).
Panic itself can easily be reproduced after several minutes from the
start of the test. I've tried to change PCPU_PTR macro to use get_pcpu
again (as discussed in the thread earlier), but it didn't help.

If you want to get your hands dirty, DPAA2 stuff I'm using is at
https://github.com/mcusim/freebsd-src/tree/lx2160acex7-exp (branch is
lx2160acex7-exp!)

Any ideas or places to check would be really helpful.

bob prohaska  writes:

> On Mon, Mar 07, 2022 at 11:45:02AM -0500, Mark Johnston wrote:
>> On Mon, Mar 07, 2022 at 04:25:22PM +0000, Andrew Turner wrote:
>> > 
>> > > On 7 Mar 2022, at 15:13, Mark Johnston  wrote:
>> > > ...
>> > > A (the?) problem is that the compiler is treating "pc" as an alias
>> > > for x18, but the rmlock code assumes that the pcpu pointer is loaded
>> > > once, as it dereferences "pc" outside of the critical section.  On
>> > > arm64, if a context switch occurs between the store at _rm_rlock+144 and
>> > > the load at +152, and the thread is migrated to another CPU, then we'll
>> > > end up using the wrong CPU ID in the rm->rm_writecpus test.
>> > > 
>> > > I suspect the problem is unique to arm64 as its get_pcpu()
>> > > implementation is different from the others in that it doesn't use
>> > > volatile-qualified inline assembly.  This has been the case since
>> > > https://cgit.freebsd.org/src/commit/?id=63c858a04d56529eddbddf85ad04fc8e99e73762
>> > > 
>> > > .
>> > > 
>> > > I haven't been able to reproduce any crashes running poudriere in an
>> > > arm64 AWS instance, though.  Could you please try the patch below and
>> > > confirm whether it fixes your panics?  I verified that the apparent
>> > > problem described above is gone with the patch.
>> > 
>> > Alternatively (or additionally) we could do something like the following. There are only a few MI users of get_pcpu with the main place being in rm locks.
>> > 
>> > diff --git a/sys/arm64/include/pcpu.h b/sys/arm64/include/pcpu.h
>> > index 09f6361c651c..59b890e5c2ea 100644
>> > --- a/sys/arm64/include/pcpu.h
>> > +++ b/sys/arm64/include/pcpu.h
>> > @@ -58,7 +58,14 @@ struct pcpu;
>> > 
>> >  register struct pcpu *pcpup __asm ("x18");
>> > 
>> > -#define        get_pcpu()      pcpup
>> > +static inline struct pcpu *
>> > +get_pcpu(void)
>> > +{
>> > +       struct pcpu *pcpu;
>> > +
>> > +       __asm __volatile("mov   %0, x18" : "=&r"(pcpu));
>> > +       return (pcpu);
>> > +}
>> > 
>> >  static inline struct thread *
>> >  get_curthread(void)
>> 
>> Indeed, I think this is probably the best solution.
>
> Just for fun I tried the patch on a Pi3 running -current, updated a day or two
> prior. The patch applied, compiled and seemed to run acceptably, but when I 
> left a -j2 -DWITH_META_MODE buildworld running it crashed overnight, reporting
>
>
> login: panic: rm_rlock: recursed on non-recursive rmlock sysctl lock @ /usr/src/sys/kern/kern_sysctl.c:193
>
> cpuid = 0
> time = 1646720264
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> _rm_rlock_debug() at _rm_rlock_debug+0x214
> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x140
> sysctl_root() at sysctl_root+0x1ac
> userland_sysctl() at userland_sysctl+0x140
> sys___sysctl() at sys___sysctl+0x68
> do_el0_sync() at do_el0_sync+0x520
> handle_el0_sync() at handle_el0_sync+0x40
> --- exception, esr 0x56000000
> KDB: enter: panic
> [ thread pid 869 tid 100091 ]
> Stopped at      kdb_enter+0x44: undefined       f902011f
>
>
> I tried typing bt at the debugger prompt but got no more output. 
>
> I've put the buildworld log file at
> http://www.zefox.net/~fbsd/rpi3/crashes/20220307/
>
> Hope this is of some use....
>
> bob prohaska


-- 
Dmitry Salychev

--=-=-=--

From nobody Mon Sep 12 19:51:16 2022
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 4MRHKK6S08z4c8N2
	for ; Mon, 12 Sep 2022 19:51:17 +0000 (UTC)
	(envelope-from 0100018333418770-45f3584b-6271-4b63-9933-d548b812a4fb-000000@amazonses.com)
Received: from a48-89.smtp-out.amazonses.com (a48-89.smtp-out.amazonses.com [54.240.48.89])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MRHKK0QhBz3bGC
	for ; Mon, 12 Sep 2022 19:51:17 +0000 (UTC)
	(envelope-from 0100018333418770-45f3584b-6271-4b63-9933-d548b812a4fb-000000@amazonses.com)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1663012276;
	h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID;
	bh=J5mwZo6sPDZ4e2nndIfLimFFyomfcTGyQyMxJeqpNco=;
	b=DKsSAHvFwu7YYjd607cLd4vyYd0uX7q1Skbh3PFbLcV8et9SKoOVr6VOidm28Vpl
	MTzGeTHAH+DHaIpHP5j9uB/5npi7FjQxHKtjlROJYrAljVTXppzV2NsUpPa/4obUlfC
	yXkwJubFLTd1WHOxDeFOlhvQlIl2SyPecHD8ts/0=
Message-ID: <0100018333418770-45f3584b-6271-4b63-9933-d548b812a4fb-000000@email.amazonses.com>
Date: Mon, 12 Sep 2022 19:51:16 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: Beadm can't create snapshot
Content-Language: en-US
To: freebsd-current@freebsd.org
References: <01000182ac3b8593-fb381303-5719-4863-8fda-2530efcab31b-000000@email.amazonses.com>
 <01000182e9f49b75-35f2fff9-c6f9-4b37-8e4c-263309620d31-000000@email.amazonses.com>
 
 <5cb26532-11d6-60cb-bbd8-4fa99db83a32@FreeBSD.org>
From: Thomas Laus 
In-Reply-To: <5cb26532-11d6-60cb-bbd8-4fa99db83a32@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES
X-SES-Outgoing: 2022.09.12-54.240.48.89
X-Rspamd-Queue-Id: 4MRHKK0QhBz3bGC
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=DKsSAHvF;
	dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=acm.org (policy=none);
	spf=pass (mx1.freebsd.org: domain of 0100018333418770-45f3584b-6271-4b63-9933-d548b812a4fb-000000@amazonses.com designates 54.240.48.89 as permitted sender) smtp.mailfrom=0100018333418770-45f3584b-6271-4b63-9933-d548b812a4fb-000000@amazonses.com
X-Spamd-Result: default: False [0.52 / 15.00];
	FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.75)[-0.749];
	FORGED_SENDER(0.30)[lausts@acm.org,0100018333418770-45f3584b-6271-4b63-9933-d548b812a4fb-000000@amazonses.com];
	R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18];
	R_DKIM_ALLOW(-0.20)[amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw];
	NEURAL_HAM_LONG(-0.13)[-0.133];
	DMARC_POLICY_SOFTFAIL(0.10)[acm.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_COUNT_ZERO(0.00)[0];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US];
	MIME_TRACE(0.00)[0:+];
	FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,0100018333418770-45f3584b-6271-4b63-9933-d548b812a4fb-000000@amazonses.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	DKIM_TRACE(0.00)[amazonses.com:+];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[54.240.48.89:from];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	DWL_DNSWL_NONE(0.00)[amazonses.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 9/12/22 05:29, Ryan Moeller wrote:
> 
> Here's the patch for the kernel and brief instructions:
> 
> https://reviews.freebsd.org/P547
>
That worked.  I was not familiar with patching a file using git.  My 
experience has always used the 'patch' utility and a unified diff.  I 
just made a backup of the file, copied and pasted the change to the 
original file and compiled a new kernel.  After rebooting, I was able to 
use 'beadm' to create a new snapshot.  I revisited the file and removed 
the changes and recompiled the kernel.

All is good

Thanks

Tom



-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

From nobody Mon Sep 12 22:08:03 2022
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 4MRLMJ3htJz4cRyx
	for ; Mon, 12 Sep 2022 22:08:12 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MRLMH3c4Hz3nV9
	for ; Mon, 12 Sep 2022 22:08:11 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663020489; bh=Juet28JHQoTk7pUt6F14Xiwobbzqd1dn7xB7vgJkxsc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KH5KpTB/zF2zuCbwJtc7XGwxbLlrqpFV/ePDyMcxuYgG8+vCZirb1Fa76j5nkpefEP4yzCRhRZrwzNHX3wsUDs/EKYx8DOK8vk+0y3a2BSxpO0o+0O1B4CXlFRNwp/ygZrt6QxZyyUH4zN2GB+T3ZR5JE6EHdr21b7vE592wrCqrOFi0WWlGe4YlELGWzSrn6/0l0KYSoLngVCDmJpbOCO+V+Hd+IqsksuXzJDE7QEaJ4SYE8PUjvy+ii7Lg8iQOAOzpOJHEN/lH+UiCeC+KDbqwunBwXam74uM6ERH7VcOQ4REHGGdKqmEphTyTv9TiG/Dsa9onFm2/w+DtwYBQbw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663020489; bh=9MF9J5Fwq2IggiN/dpBKn/At/qon/3irl8EmVs5ZwLC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SBee2E/msP3WKuvcLVXhtocCvkzyN4DpymGRUymSizSrhrr7k6MpxQNcLTQzfdmpV/6Am35+NnKQAaE5u4ifrBjL/EtotEqwky+xvRiVArldcJJV/zR/cK2G86Q3IXWjQyOvOHaNr2MZ45tRM+pXIlBPZx2Mo312N3XXZz0FTshrxMiI5HlTkayoSFczyWGPUqNiV/wpMnT/8tBVgXV9jXrvixZHCm0LHpPYQmgzIqPDGwfZjDUALryDrxL+zkNAHbhv+din7ybheUCT1Pof0ekTAJHlvPTWPha8A5n99K0dSfTmZzdOwmRCYaCn4S6Ko6gX2caNdFBotDLQo6+rJw==
X-YMail-OSG: k1FghOsVM1k_pE9Cr1T3r55xkXQTlHmc2MQ7IQ2ci41yJB0cnKuuJiOlwEgjgtP
 ajLGYM.TGyQkwBoMk178Wf7X02x.IpCzPNXi.nTayVtVPSamzILlDA0K934vFTrm4T7yqqV.GUIN
 rN2TZaMSGpr1fCnuT8GQs6jqc0VJtbpd8lHOa5JeDcHjwggMc5J655PkLkfh889Gx9UX4qmVQVJ4
 54lFdjLrdFxckHDOfE.kS0BQvdtHphJu.UKQth1yJTb8xBK_Z5wYPOMmp2173nJ9aaTRmLZ0CyLl
 rkdps0sLvoI2tRyjF.3WHOZSqz4Z64iPgGwrR0DPDh3WWoz.JiLwjvoYlAfqHC.96_eQryM8yLng
 LEuXxnHrdbJP5_CSCAgtTSg8eGUiF9Ry8aDBz7.b3Q4KOsS4cWxOn6VhbxGsTKe9zli54JZSMGMm
 El4QWu0NsFAhAuCs8sTSt9I7Z9y0LmgABzDVZN8hG4aPqmrm8yqzxyvxMnNccOslJoE6z0EjUhG7
 cQUkC0SM7n.55Bm_5w4czLI80gQmhImw2g.kT7uO1hJ6L0jvEa4f64kqdbqLBybL7VWFjlhEvnOm
 0VCBjXuEw5HyAkcxBHH5wtYwNGGce4XOIMMCEFHCraEcDzCs0A3o8fDjYuw8uNnZsxwhDvLAgmN4
 5ALvimLknO.j9fZaR8Mke2zWw_mGuuec7iq1eWGYCpY5HgqrzpCXYn9hn_aQQGCyAe0guvLMaE25
 vd5jVgmvoBuz8X5NnxHIFYCmfWkXbRLXDBzrXJMe0hLghgQVj7Qm9YfTHUSRKDDWU8.tpeN1.P3j
 55x5ofaNzauPwFglRcBDWg2UCpPkabSRUKPytoVPk2okj2dZZcKyHvQBerBZAVhN78LIVfi8sbWQ
 EvO0fDMO72bem0B.Q3lKpijqHgDXSNebriiu5YaVO2H494AEePBaWXo.Pi7JCSIlkjPPPaL7faSm
 C3_N2Cnc2YMW6D7CMgW8ApmTc41jpAIgtlmsZhivYKTII3oFxYDpKBehHsoJfxqPOmcK8JKMGZ12
 VDg10Z_UIYi.B63ATQ_rvxCatT301.cZ8.EUzC2TNlwCqvpG8K3RTbDCIeRZtUJktbDRW76eCGKo
 euwadv7vjiHooqoMAOYrMyIIQW298I4AWKjUjb_8khYV4jctY5Y99bl8GXM4XO.x2xhxj.fsCUxk
 M3ACOR90vond1taVmN89l6cXoeqwwQ6KoSY5RYo8Jo3rakHNUjEXCFN5e8PXfpwQYA8GDH99dGEl
 dUbr3beHGSAML9v8gerItLxI7gockVr4BbJ.pgwbSajs3dMo5_KIrUdPBxcDy_8ZYvhLU7P2Mm3_
 95gzfNNYRQ8.uezNRlv7VLQgpiaPjh9OkxVz1QuUTTM3EnDcgqKs3uLcEMY2a5IlsO52doVUK1Ht
 U4yprxLiKtXgWrHdFXO9fSx5HN8G2PuvMNIfr0ociDYyeRjpeFu7PI_QRrPEU8VGAXjrjj3jkpEY
 Go0HfOS6d_ZTLKsIPOjo8EyEi0vVrMt9ZQYYEE6YVzZj6d4nTt6E.YBNgq0TEPfziiGbU7_a4s3U
 4TuATJGbnWkH57n0HBOQfAp2SHsWskD_9gScfA34D2iXnswWaptRf6tGbrz49KDFy71zMRraZn12
 dWeG2ddU9pXKx6lJzQ9b8_00uup1R36rx1C.VqYaJu2xwTBxSWfV4a6v9OtsrNB4XPmoXFK3sJ2r
 jHYZvZrow4lTen7oEOzcnrleUEh.qqfNevYV4iBS74A2aB2xNwXAXEd5zhIvXZgUnAVtqnl9skqP
 hH1m.veGPWoJJg84hdSGqFYjBhbZRE7_.t43pNPRYcwlwbxBVtCFDwZiOXJodDa3dpprcKTnsK99
 1AqWoeg4EC6gks6n6MklY7HkXuMkb8GSAy4DEBf0kKozNmSAjJoLNDTaIYlt5zDUitzwXu2ik8hX
 95bRc5g3QZsn5n36KfMw_qmvlKgXkWmZkcuBDM5RJQcShQYXB8G1H.29xAPq9I2sZatHXquO94BQ
 Noyflevo8zejEzIC.d5Mu4RpKkkMYx.cZvoQbO_9uPALz9Zn9J3lwB0eA5uFq7I0.wX.MCYluYtn
 9wgS6YLOfChHoCYm8GlKFASYapXU50iyV5GqzpJ1X.ZrSpKpG8Gf.6joF_a7L9rDGVplr7fVQ9US
 _mEZNSXoJPYtfBZscxx0K9erP7eOp0Tfcm.4toJiyx7rKrQwY7ad4RBYXddhy6avKvlHcst1EPfi
 0856v4a9066Nn9fk.MbbSam0Th6xC2lWd0PeLYFQyPgETgqqzrJTY54xBvTZ3NAMYSr3.iCGVg66
 NM1XwY9M-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Sep 2022 22:08:09 +0000
Received: by hermes--production-gq1-5499fdd576-49dgt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 84fd9d53cc1b48dc6ce704638f11ed39;
          Mon, 12 Sep 2022 22:08:04 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: panic: data abort in critical section or under mutex  (was: Re:
 panic: Unknown kernel exception 0 esr_el1 2000000 (on 14-CURRENT/aarch64 Feb
 28))
From: Mark Millard 
In-Reply-To: <86czc0eotc.fsf@peasant.tower.home>
Date: Mon, 12 Sep 2022 15:08:03 -0700
Cc: bob prohaska ,
 Mark Johnston ,
 Andrew Turner ,
 Ronald Klop ,
 freebsd-arm ,
 freebsd-current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E1552DB-4A65-4DFF-BC79-CFE045ECF972@yahoo.com>
References: 
 
 <1800459695.1.1646649539521@mailrelay> <132978150.92.1646660769467@mailrelay>
  <3374E0F8-D712-4ED0-A62B-B6924FC8A5E2@fubar.geek.nz>
  <20220308154204.GA37265@www.zefox.net>
 <86czc0eotc.fsf@peasant.tower.home>
To: Dmitry Salychev 
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4MRLMH3c4Hz3nV9
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="KH5KpTB/";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.996];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	NEURAL_HAM_MEDIUM(-0.99)[-0.993];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_SEVEN(0.00)[7];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Sep-12, at 05:10, Dmitry Salychev  wrote:

> 
> Hi,
>=20
> It seems that the recent 14-CURRENT/aarch64 (866e021) with DPAA2 =
drivers
> panics under network throughtput stress test in random places

3 of your examples get a signal handler called at the
exact same instruction:

#6  0xffff0000004ced5c in witness_lock

The parameters vary, as do the callers:

#7  0xffff00000043a3a8 in __mtx_lock_flags
(twice)
vs.
#7  0xffff00000047d4ec in callout_lock
(once)

Showing one more level, where all are distinct:

#8  0xffff0000007d60a8 in dpaa2_swp_enq_mult =
(swp=3Dswp@entry=3D0xffffa0000056ca00, ed=3Ded@entry=3D0xffff0000bcda2c70,=
 fd=3Dfd@entry=3D0xffff0000bcda2df8, =
flags=3Dflags@entry=3D0xffff0000bcda2c6c, frames_n=3Dframes_n@entry=3D1) =
at /usr/src/sys/dev/dpaa2/dpaa2_swp.c:795
vs.
#8  0xffff000000508f54 in soreceive_generic (so=3D0xffff00011d2c2200, =
psa=3D0x0, uio=3D, mp0=3D, controlp=3D0x0, =
flagsp=3D) at /usr/src/sys/kern/uipc_socket.c:2240
vs.
#8  callout_reset_sbt_on (c=3D0xffff0001121792c0, sbt=3D, =
prec=3D, ftn=3D0xffff00000047d4ec =
, arg=3D0xffff000112179000, cpu=3D0, =
flags=3D256) at /usr/src/sys/kern/kern_timeout.c:962
(no address shown)

Perhaps looking at what the code at 0xffff0000004ced5c
(and before) is doing with what kinds of data would be
useful compared to the less frequent example signal
handler invocations. It is common to all 3 call-chains
above. If dumps for them are around, more than the code
might be able to be looked into.


> with
> unknown kernel exception 0 esr_el1 2000000 on Ten64 board (based on
> NXP's LS1088A, Cortex-A53), but the same code doesn't panic on =
HoneyComb
> (NXP LX2160A, Cortex-A72) even after ~10h long tests.
>=20
> I've gathered some stack backtraces from ddb and kgdb (attached).
> Panic itself can easily be reproduced after several minutes from the
> start of the test. I've tried to change PCPU_PTR macro to use get_pcpu
> again (as discussed in the thread earlier), but it didn't help.
>=20
> If you want to get your hands dirty, DPAA2 stuff I'm using is at
> https://github.com/mcusim/freebsd-src/tree/lx2160acex7-exp (branch is
> lx2160acex7-exp!)
>=20
> Any ideas or places to check would be really helpful.



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


From nobody Mon Sep 12 23:05:29 2022
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 4MRMf14Bzhz4cZSk
	for ; Mon, 12 Sep 2022 23:06:01 +0000 (UTC)
	(envelope-from shiorid@mail.shiori.com.br)
Received: from mail.shiori.com.br (mail.shiori.com.br [54.232.176.79])
	(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 "shiori.com.br", Issuer "ZeroSSL RSA Domain Secure Site CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MRMf04zpwz3tSf
	for ; Mon, 12 Sep 2022 23:06:00 +0000 (UTC)
	(envelope-from shiorid@mail.shiori.com.br)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.shiori.com.br;
	s=dkim; t=1663023958;
	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=ac6DQ3c0OXoreM3XbKKtHcri+vm/ZX1Y/Cvunxzilm0=;
	b=yNFrQmA/kzH0i9kGf+LX2+ZLBi32o5/3IxrO32/K5kNDQVsSb3v20Go5PLtA8NmphT4Vm5
	eDSamTCenkkkJnDLYgL3/vwKvRlSSLIsHVwsfahcsQcu5ClDvEqRpSqJR2rqCNVHSC816d
	gN8avydrcrdgwYjYOtg892TeLBfxB1yt1AJZhyNCoPDnGEK1BRuDSCKzq10ZE25X16KlqH
	1Urs5+8Ky9zMf+lZWDLryhaZG5Wz58+tq1HDnODW5OCLNsL2UvgYJQ94E+5EXsKMpdbb5P
	Z6RklA6DS/DU5s3nLVEeeywbgzhVb5lZQR2SHV8z0iqYVBjfJSHe29tqfoP0eQ==
Received: from mail.shiori.com.br (localhost [127.0.0.1])
	by mail.shiori.com.br (OpenSMTPD) with ESMTP id f30bd8f8
	for ;
	Mon, 12 Sep 2022 23:05:58 +0000 (UTC)
Received: 
	by mail.shiori.com.br (OpenSMTPD) with ESMTPSA id 621f9085 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO)
	for ;
	Mon, 12 Sep 2022 23:05:58 +0000 (UTC)
Received: from shiorid (uid 1001)
	(envelope-from shiorid@mail.shiori.com.br)
	id d47
	by misaka.local (DragonFly Mail Agent v0.13+ on misaka.local);
	Mon, 12 Sep 2022 23:05:56 +0000
From: Filipe da Silva Santos 
To: freebsd-current@FreeBSD.org
Subject: WITH_BHYVE_SNAPSHOT broken after 9cc9abf4
Date: Mon, 12 Sep 2022 23:05:29 +0000
Message-ID: <86sfkw2nye.fsf@mail.shiori.com.br>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"
X-Rspamd-Queue-Id: 4MRMf04zpwz3tSf
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none ("invalid DKIM record") header.d=mail.shiori.com.br header.s=dkim header.b="yNFrQmA/";
	dmarc=fail reason="No valid SPF" header.from=shiori.com.br (policy=reject);
	spf=none (mx1.freebsd.org: domain of shiorid@mail.shiori.com.br has no SPF policy when checking 54.232.176.79) smtp.mailfrom=shiorid@mail.shiori.com.br
X-Spamd-Result: default: False [-2.86 / 15.00];
	SIGNED_PGP(-2.00)[];
	DMARC_POLICY_REJECT(2.00)[shiori.com.br : No valid SPF,reject];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.99)[-0.993];
	NEURAL_HAM_LONG(-0.97)[-0.969];
	FORGED_SENDER(0.30)[contact@mail.shiori.com.br,shiorid@mail.shiori.com.br];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_DKIM_PERMFAIL(0.00)[mail.shiori.com.br:s=dkim];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:16509, ipnet:54.232.128.0/18, country:US];
	DKIM_TRACE(0.00)[mail.shiori.com.br:~];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_NEQ_ENVFROM(0.00)[contact@mail.shiori.com.br,shiorid@mail.shiori.com.br];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	R_SPF_NA(0.00)[no SPF record];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=-=-=
Content-Type: text/plain

int vcpu declared in line 1247 isn't being used, since it's now being
redefined inside the for loop in line 1589.

diff --git a/usr.sbin/bhyve/bhyverun.c b/usr.sbin/bhyve/bhyverun.c
index 550cc9d15..27f1d8ea8 100644
--- a/usr.sbin/bhyve/bhyverun.c
+++ b/usr.sbin/bhyve/bhyverun.c
@@ -1244,7 +1244,6 @@ main(int argc, char *argv[])
 #ifdef BHYVE_SNAPSHOT
	char *restore_file;
	struct restore_state rstate;
-       int vcpu;

	restore_file = NULL;
 #endif

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iJEEARYKADkWIQTiwNfLPLmvvYTb8NynA2ni+ens+gUCYx+7VBscY29udGFjdEBt
YWlsLnNoaW9yaS5jb20uYnIACgkQpwNp4vnp7PoFmQD/SA9z4nJhUyGcVuS55UG3
5JM2/TLo+BAl0NhiUrwxNnAA/2A238OTz1Tg8So7aX1mDaJEEXEGvKFDiOpSgSrz
GOoM
=p5kX
-----END PGP SIGNATURE-----
--=-=-=--

From nobody Tue Sep 13 06:34:03 2022
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 4MRYbB0zXSz4cdcJ
	for ; Tue, 13 Sep 2022 06:34:14 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
Received: from mx.blih.net (mx.blih.net [212.83.155.74])
	(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 "mx.blih.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MRYb917Gmz3Mj4
	for ; Tue, 13 Sep 2022 06:34:12 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com;
	s=mx; t=1663050845;
	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=qby0C+jRiYNH3vL0prnKsZ1isEVhpAdv4Ag3xpO+JtU=;
	b=neQ2db7U1XCFYsqqQ3JAZLRAaOQvySIXx8v7K2/jUuxIJi1CB7jpB0YGw+MkdSjsWG8E30
	S6vIQCi9K1RhxlhsAGuG7jcZv8U4ulNCiPbdLOnpe6GKdZk2jKrY2K9LIdZ8fdjijBYTna
	7Une3sBuW4/cMntc61B2SxQWLlVQXtg=
Received: from skull.home.blih.net ( [94.238.214.231])
	by mx.blih.net (OpenSMTPD) with ESMTPSA id 9dd2cd7c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Tue, 13 Sep 2022 06:34:05 +0000 (UTC)
Date: Tue, 13 Sep 2022 08:34:03 +0200
From: Emmanuel Vadot 
To: Filipe da Silva Santos 
Cc: freebsd-current@FreeBSD.org
Subject: Re: WITH_BHYVE_SNAPSHOT broken after 9cc9abf4
Message-Id: <20220913083403.800ee2bf1cbe115ad38c7aaa@bidouilliste.com>
In-Reply-To: <86sfkw2nye.fsf@mail.shiori.com.br>
References: <86sfkw2nye.fsf@mail.shiori.com.br>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MRYb917Gmz3Mj4
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bidouilliste.com header.s=mx header.b=neQ2db7U;
	dmarc=pass (policy=none) header.from=bidouilliste.com;
	spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx];
	R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[manu];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[bidouilliste.com:+];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 12 Sep 2022 23:05:29 +0000
Filipe da Silva Santos  wrote:

> int vcpu declared in line 1247 isn't being used, since it's now being
> redefined inside the for loop in line 1589.
> 
> diff --git a/usr.sbin/bhyve/bhyverun.c b/usr.sbin/bhyve/bhyverun.c
> index 550cc9d15..27f1d8ea8 100644
> --- a/usr.sbin/bhyve/bhyverun.c
> +++ b/usr.sbin/bhyve/bhyverun.c
> @@ -1244,7 +1244,6 @@ main(int argc, char *argv[])
>  #ifdef BHYVE_SNAPSHOT
> 	char *restore_file;
> 	struct restore_state rstate;
> -       int vcpu;
> 
> 	restore_file = NULL;
>  #endif

 Hello Filipe,

 Sorry for the breakage, should be fixed in 10c6af344108.

-- 
Emmanuel Vadot  

From nobody Thu Sep 15 00:00:03 2022
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 4MSclS0mHgz4cXy1;
	Thu, 15 Sep 2022 00:00:04 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MSclS0F63z3tT2;
	Thu, 15 Sep 2022 00:00:04 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663200004;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=;
	b=NNDB7hdZRf3sTVZqHcjX1NoRAQRY2s4FPSER7hm3hgllVsbnJnSaYnxhhToUN5wSf/xdEU
	2ixtXd6IowVqXP9Y1S3ZRWrYEiWgSw4l6OhNAcjU7qb0R+d6LGWCjliIc2vyZDy2DNGv0w
	6iqtsZBy+eoVZs+t/gmnVkmq487Tu5Uj/mm5mZ/mbMtOHsIWBbbEFicKxkAtdG+9s83Hcq
	9512IBwLOagT+Wb64izg/MaBwWs2c+/5WBTe/OjXyB+9EBPQV63VoeTzgZXtl0AVvbnS8Z
	1Rid7afg7UqIG90jxf4A+Fc4Ho91clV+QHSaL+6NmKoZdsfDjNE07TsHxqCYNQ==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id C545CA8F7; Thu, 15 Sep 2022 00:00:03 +0000 (UTC)
To: freebsd-quarterly-calls@FreeBSD.org
Subject: [2 WEEKS LEFT REMINDER] Call for 2022Q3 quarterly status reports
Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org
Message-Id: <20220915000003.C545CA8F7@freefall.freebsd.org>
Date: Thu, 15 Sep 2022 00:00:03 +0000 (UTC)
From: Lorenzo Salvadore 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663200004;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=;
	b=w0upiJ4n56abGegJ+6iLAsvLdc8GEbCl4878nq6PbyrRBy7NFotUgISdpEvcH68bgsnAyJ
	B+kSWviTsc4RKNYsMXDRNUyPgHP4jj+jNi0wR0BVeBnwIFSG96jUy2N7Mv3rmfv6AwdsaO
	2tjbcHOzDvHDLJ1nC9xQLqLuk0QBl7zWWVtwE4AApAnGnvK7Mwzw2bohAIKQVEuTqvGJ2J
	OAdrnhl7yb1ZuSuRSmb0UFjpwKciclt/K/huqr6hxH+d1qhJgbdYrwPhCCCktkcYdTWEs3
	mrQ+/DtKcrtnSORtDehzGzzd7b0rhLj9hf9v2avXHeg/m8+PnfbkqUd9M4LTeQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663200004; a=rsa-sha256; cv=none;
	b=ZwZ/LNK9K7MsFctfFxXn+k3/y+AUBLeYFysRbPKPK7Svk4H7aUCnQsv6jNn7ziTtTSDWb2
	Ev2mX1WXGKdcrJ9S5utAW3n7xeSFdabxYzESnsySRauDVKKxYk4vSKFpiu/q0f0zyHyLTr
	ZHGSi8CecKr3ntDuTVaNZIxS02ksPWMgk+BGDFz1kwuvrRBnOFA8oIxOw6UIVK9zipRKCb
	dYCCvJKG0OKI+b3qP4O1sMEn8CIPmpurMxu5gQdE5ysjFKQozU3OVc1jiEqPGRDMfHzpZy
	Pf4RUYiVowmoriyeWa8o8AWpb4NMW1O0kpS0x9rl4tvb9wXxUmRXijHJFB1csg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
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

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
September, 30th 2022 for work done since the last round of Quarterly Reports:
July 2022 - September 2022.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the AsciiDoctor template, fill it in, and
email it to quarterly-submissions@FreeBSD.org.
The new AsciiDoctor template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc

We look forward to seeing your 2022Q3 reports!

Thanks,

Lorenzo Salvadore (on behalf of quarterly@)

From nobody Thu Sep 15 13:45:14 2022
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 4MSz3m0x3Hz4cJ87;
	Thu, 15 Sep 2022 13:45:24 +0000 (UTC)
	(envelope-from des@des.no)
Received: from smtp.des.no (smtp.des.no [95.217.20.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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MSz3l1TVdz3vSq;
	Thu, 15 Sep 2022 13:45:23 +0000 (UTC)
	(envelope-from des@des.no)
Received: from ltc.des.no (unknown [84.211.31.80])
	by smtp.des.no (Postfix) with ESMTPSA id AE3CF25C81;
	Thu, 15 Sep 2022 13:45:14 +0000 (UTC)
Received: by ltc.des.no (Postfix, from userid 1001)
	id 3763E92A05; Thu, 15 Sep 2022 15:45:14 +0200 (CEST)
From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= 
To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org,
 freebsd-security@freebsd.org
Subject: Putting OPIE to rest
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (berkeley-unix)
Date: Thu, 15 Sep 2022 15:45:14 +0200
Message-ID: <86h718sqdx.fsf@ltc.des.no>
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-Queue-Id: 4MSz3l1TVdz3vSq
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of des@des.no designates 95.217.20.81 as permitted sender) smtp.mailfrom=des@des.no
X-Spamd-Result: default: False [-2.58 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	R_MIXED_CHARSET(0.71)[subject];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org,freebsd-security@freebsd.org];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:24940, ipnet:95.217.0.0/16, country:DE];
	ARC_NA(0.00)[];
	FREEFALL_USER(0.00)[des];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[des.no];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I will be removing OPIE from the main branch within the next few days.
It has long outlived its usefulness.  Anyone still using it should look
into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator).

https://reviews.freebsd.org/D36592

DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no

From nobody Thu Sep 15 15:16:22 2022
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 4MT14y1VWhz4cY02
	for ; Thu, 15 Sep 2022 15:16:34 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2094.outbound.protection.outlook.com [40.92.97.94])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MT14w41lhz3ClY
	for ; Thu, 15 Sep 2022 15:16:32 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ZfBnkekxL7s9xsmOOFRQqFgfO+XGQj5L3WZhRRstU/b+SGBEMu/mFTK32n/LmJUKWdPSY3iqetd5dgtxEelXSgD5RByUNmhqGuN5U6QTzH7S/8qiykqhz3NfnNGQ9P1fUrDPzMpPf8Oqj4fRiHYihnexqW745TYinWHxsJciXWgs1sVysvYqU5JVemqQP0Y0cEnxL8duETBAURtE+FrsKq3TMmDj6d7D+tvEnRZm5AENIPdh3ZAC94K1ilhSSaJDegcroojCX2I/DHg/X0XYqrLL+I6m1VljwE9FU345kF5Y8OvxfZI4ZqyFebmlvmJ1rRP2aGc+Dej1hew6UxNJrA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=xYEsNMpO5aofC4SgM//e07ICGJ52i4X+J3uET0rp3Fw=;
 b=UMwm0AnQgJDVgOj+3DNobrnqkh8unRKjXsD7S+ZtGWrrCHirSHeAAPdhSmgJT7VvBz1SA57rJFLrfIY/gGf2iNIchQ2m/TxXTGjRrk9EUUp5iLltHvAfZSlpHRMmrs76Kd/JDtiv2iezQoiAjKM+wrP0ST3rGe80pHUlNTiLaC/N/qD8czV+jS5yjHIGFz4/f5P96pk0+rh8IdkpqHyjVBlZanVOEA0bZspK396wBjBN8cxTIoEpsyvgCSqFFz4785+onF+WbUzFZcFr3ozLUWvWyMszwtsQ0VL+yZcg5URwhlI7g4y1Id6llVvnHIECOV3ucQzIaCfwFLVjiz3Hhw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xYEsNMpO5aofC4SgM//e07ICGJ52i4X+J3uET0rp3Fw=;
 b=Dek/IMHG0uQdEMfpsP1UaZ0l8Pos5Mdp7M0s1pfTEzcNvmve+Slqh7RjMQLdbOI/MBPSqzIus8q49VahiP5O6b+MqjNbtLmJyn+khoUiZFnUuWEGQxf0lGxrtcPZPnh7cbuYatWnDzsuJoxqK9T83LDBf0ywXPLb/5iuQIxE3kz4BSSQ4hQCTZ/ghTy8v8YI5nmzD4NQ21Cirvj+Cvih8ZORYvtMwx4MNccNYWTnAj+IYquMR9Q157Tk2fzWR4d6BFdkbi6GttZ8LO0zzKh90LxslGhyTEyGzLHp5VGQvcjkSx4+M4sGJZNtHR8S0/sCE2AZGx/yE715AFyarDTZPQ==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by FRBP284MB0124.BRAP284.PROD.OUTLOOK.COM (2603:10d6:203:19::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.19; Thu, 15 Sep
 2022 15:16:29 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::d573:9d8a:cfec:4e6b]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::d573:9d8a:cfec:4e6b%4]) with mapi id 15.20.5612.022; Thu, 15 Sep 2022
 15:16:28 +0000
Date: Thu, 15 Sep 2022 12:16:22 -0300 (-03)
From: Ivan Quitschal 
To: freebsd-current@freebsd.org
Subject: TP-LINK USB no carrier after speed test
Message-ID:
 
Content-Type: text/plain; format=flowed; charset=US-ASCII
X-TMN: [cKBVa1CD+v8XPiAm3/8ZUR32KtZV+rPg]
X-ClientProxiedBy: CP2P215CA0012.LAMP215.PROD.OUTLOOK.COM
 (2603:10d6:102:1::22) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <28a2d4c5-9c14-4afc-bd4a-d9a480afc64a@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|FRBP284MB0124:EE_
X-MS-Office365-Filtering-Correlation-Id: c824d813-b5e3-4ccf-c27a-08da972d4350
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	wlH5F0q/v+MG7ThSxX6YeZoCXnSuKmkktcbnVq5FM+fxFdcjn76iRHX+4ZUz289GdS2pUpHiz9jL1pm28jpwFQfsTu5Dks9Hfd7NHLP9egktgYyCNi0b0IpgjGMaIyQ8UXLNWN1o1Np/c3GZ1UTm2griEPVx1m0as/mlc3AuzKa8oelgiE5xt1nsi7ZW0ElzwaPoODyHpa6VwS/8iZXnWgQx7p1GRyIUUYaem15I1VPph0+63G9ribI0qMppgFZLUT8VJxz9pMSul0FxVjaSqN9lxfXGopNY5DGhcbtGsShlAhN+e1+IyFo7VWzeklhgybsPV8fV/immzdS9Ds7glH/LBFUZoNzg7cqpHO1S9McOEvoHofsDubpQMz4UeaVF0zjjUy0BqD2TCIii2Sp5anXyzaERsYAUHV5c79IAs/78aZsnwht9YGkU1TuPai3+kYe2lRBHvy/KoSeYq/yGYkm/fTgEs/MSwR7zKsooegDEVAGNJkWNuhDiHi+/Gg020JsebVALBCYoy8QsrY7YvN0xB+YxloJkP4sGHTHo9KrF4WSZPVlbHNZHB0ybZUrC7VjqrxtiWXkaK8C93/6Z0GiTvLK0pwnjX3jzB9P+SewDclYZtqIr28keoQEmyZ7Z+qNfK+qMiQkb7sHXqjGenQ==
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?ZTZtNYgs5dzsFnZYDVsniJk+6YLBKSvN67PGP0izVekJsWzvB7EXGEMxQFXj?=
 =?us-ascii?Q?k+wGLV87I1f0TGf8YCJRRreOw1PkrJZaN/2BObsTFfNKmSK3WxB4297YJXaS?=
 =?us-ascii?Q?no2HQWFNe4whKCoCPwa1cp/VpSDsviiNitQwwPAvpeoF/okdqGXUgyLKfqNh?=
 =?us-ascii?Q?YiddVXMN4IJfcqVR4qOWNDyCKBOiUNoT5TokviUjYFtXIjUWWdVwGl8GH8O2?=
 =?us-ascii?Q?8x2tH488lf/IVczZ0cCdwHM2DeFQkpFFzJUZhbvXqfdfCE+VOPIlJS2zJB0g?=
 =?us-ascii?Q?pe7KSz6RY/s9Ga6kl8kOguvAP8qEC3tVY+WwCfwPp/6R0Y1R+q3MDRe9YFtB?=
 =?us-ascii?Q?693dGn/l0z5RnQNi4/hwO9Inubw6v/DPbTZkwRPiEaHmf/abyjAKggURaKXR?=
 =?us-ascii?Q?CRKnESRLockD6zYJdvOkq9GMN8qFtPCx8Ws3JIgKtvp1jzpht+Zn+RG5W+Dq?=
 =?us-ascii?Q?Z41TY6+V7Ds1PWvm5euOdFfM/GJfdZb1vQo7vS85xidrO4INeip9VdmkoQVv?=
 =?us-ascii?Q?H914vz6ANRnuxa3PGMEsCJFeaxjBRfSytghrxgJfDVawmUbecVig3hwJXjos?=
 =?us-ascii?Q?9ex1yupJgi51zuMaGOdRdw0ZaBuK5K39Zbk1dfp4UMoqeZQEKPtQ4g/JdDfA?=
 =?us-ascii?Q?Xf44kJN1iayEKJoz0kr0q9A41MAaH1V3Rta5vAedIH+lofNzvsRJzGBAYnWe?=
 =?us-ascii?Q?7VMEiBd7TSRW67/u7w4WNUCvgz5EW6nBgnQYeZhSHyokuGNWBh//DREmBZSq?=
 =?us-ascii?Q?KnUW+pvJULdD7NO0E0YBGZZ6i6I5oEErCidrxkMHZOr3mAS4ajXbWhyPp4as?=
 =?us-ascii?Q?4rW6RsQOVkhnx9x/4lSZVOcuH9pAytETOuJ6rDreaCRF+76jszzI0D0QArDF?=
 =?us-ascii?Q?K16Tr/fVyqKRuNZFunbbdFIJ68vSLDuPXJESVhzVCT0gBt8IQE7sYyRG0CbQ?=
 =?us-ascii?Q?0RdTZFkIcSilP1QpimxRtB9oslC83a4K30mNPxOxHdw8s6xGM9nPw7cpLuxc?=
 =?us-ascii?Q?V+OJf3Jj1hbA9UPqqjSoq1AaarGLgtYi3CK08Oq56G/kVruNQDj6VepikMWO?=
 =?us-ascii?Q?tzPi1u92VOu4/Mq4uhqxUK8uEMDEec4aTWXHbXYLB3NHwnJMV4gyuphwFMLm?=
 =?us-ascii?Q?4M9J7zdU/4uufBqgqU13M0fT1G28WYHSzwFxg7eHuzAt0EPkUbjvhPmjd/M0?=
 =?us-ascii?Q?5HBP5B4yOMzsgFcSuQycOMgKggBARqMJnejb8Kr+a0jPTTnIWb5JhfZQX6ET?=
 =?us-ascii?Q?CUC2V+lSLaiWx8wpOf1W9CJn0HnfKrw4EfD5XcLREw=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: c824d813-b5e3-4ccf-c27a-08da972d4350
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2022 15:16:28.9253
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRBP284MB0124
X-Rspamd-Queue-Id: 4MT14w41lhz3ClY
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b="Dek/IMHG";
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.94 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-5.00 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	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)[hotmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.94:from];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_NONE(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N


Hi All

Does anybody have any idea what could be happening here?.
I have a laptop DELL INSPIRON 3511 and everything works just fine, literally 
everything. even the iwlwifi0.

But in order to use my full 600mbps, i dont use the wireless but a TP-LINK USB 
ethernet connected on "ue0"

ugen0.6:  at usbus0, cfg=0 md=HOST spd=HIGH 
(480Mbps) pwr=ON (200mA)


but something really strange is happening .. everytime i open the chromium e do 
a speedtest (could be speedtest.net or any other) , at the end of the test the 
eth interface dies .. it changes from full-duplex to half-duplex/no carrier and 
the only way to get the internet back thru ue0 is by rebooting the whole thing.
not even a "service netif restart" does anything

if anyone has any ideas why is that , would be appreciated

thanks

--tzk




From nobody Thu Sep 15 15:18:43 2022
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 4MT17l2NMmz4cYcj
	for ; Thu, 15 Sep 2022 15:18:59 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4MT17k0FDCz3DlY
	for ; Thu, 15 Sep 2022 15:18:58 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.3.0.9] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 12EF0260B86;
	Thu, 15 Sep 2022 17:18:48 +0200 (CEST)
Message-ID: <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
Date: Thu, 15 Sep 2022 17:18:43 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: TP-LINK USB no carrier after speed test
Content-Language: en-US
To: Ivan Quitschal , freebsd-current@freebsd.org
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MT17k0FDCz3DlY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[hotmail.com,freebsd.org];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/15/22 17:16, Ivan Quitschal wrote:
> 
> Hi All
> 
> Does anybody have any idea what could be happening here?.
> I have a laptop DELL INSPIRON 3511 and everything works just fine, 
> literally everything. even the iwlwifi0.
> 
> But in order to use my full 600mbps, i dont use the wireless but a 
> TP-LINK USB ethernet connected on "ue0"
> 
> ugen0.6:  at usbus0, cfg=0 md=HOST spd=HIGH 
> (480Mbps) pwr=ON (200mA)
> 
> 
> but something really strange is happening .. everytime i open the 
> chromium e do a speedtest (could be speedtest.net or any other) , at the 
> end of the test the eth interface dies .. it changes from full-duplex to 
> half-duplex/no carrier and the only way to get the internet back thru 
> ue0 is by rebooting the whole thing.
> not even a "service netif restart" does anything
> 
> if anyone has any ideas why is that , would be appreciated
> 

Hi,

I think it some new features they use in the USB data protocol which we 
don't support. Check the Linux code.

Between does:

usbconfig -d 0.6 reset

recover the device?

--HPS

From nobody Thu Sep 15 15:23:26 2022
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 4MT1F04SFBz4cYvp
	for ; Thu, 15 Sep 2022 15:23:32 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4MT1Dz63jhz3G9Q
	for ; Thu, 15 Sep 2022 15:23:31 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.3.0.9] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 45EB9260B86;
	Thu, 15 Sep 2022 17:23:30 +0200 (CEST)
Message-ID: <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
Date: Thu, 15 Sep 2022 17:23:26 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: TP-LINK USB no carrier after speed test
Content-Language: en-US
From: Hans Petter Selasky 
To: Ivan Quitschal , freebsd-current@freebsd.org
References: 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
In-Reply-To: <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MT1Dz63jhz3G9Q
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[hotmail.com,freebsd.org];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/15/22 17:18, Hans Petter Selasky wrote:
> On 9/15/22 17:16, Ivan Quitschal wrote:
>>
>> Hi All
>>
>> Does anybody have any idea what could be happening here?.
>> I have a laptop DELL INSPIRON 3511 and everything works just fine, 
>> literally everything. even the iwlwifi0.
>>
>> But in order to use my full 600mbps, i dont use the wireless but a 
>> TP-LINK USB ethernet connected on "ue0"
>>
>> ugen0.6:  at usbus0, cfg=0 md=HOST 
>> spd=HIGH (480Mbps) pwr=ON (200mA)
>>
>>
>> but something really strange is happening .. everytime i open the 
>> chromium e do a speedtest (could be speedtest.net or any other) , at 
>> the end of the test the eth interface dies .. it changes from 
>> full-duplex to half-duplex/no carrier and the only way to get the 
>> internet back thru ue0 is by rebooting the whole thing.
>> not even a "service netif restart" does anything
>>
>> if anyone has any ideas why is that , would be appreciated
>>
> 
> Hi,
> 
> I think it some new features they use in the USB data protocol which we 
> don't support. Check the Linux code.
> 
> Between does:
> 
> usbconfig -d 0.6 reset
> 
> recover the device?
> 
> --HPS
> 

Hi,

Search for axge on bugzilla:

I suspect you are using this chipset:

Try:

usbconfig show_ifdrv

To know for sure.

Also see:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210488

--HPS

From nobody Thu Sep 15 15:33:28 2022
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 4MT1Sb3vL1z4cbDj
	for ; Thu, 15 Sep 2022 15:33:35 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2104.outbound.protection.outlook.com [40.92.97.104])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MT1SZ2SBYz3HbN
	for ; Thu, 15 Sep 2022 15:33:34 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=arp7UbZbM/k++uK1NJEAmYJh/y7/1y+XKzoi3pgBaXkXC/4HN8MIz4eJmd7pxxbKuZfiYVpaf/+nmC3eWiDaovS3BN1ChVSWo29fErdYSJ8VTRi6M5y6UdElBZ9iRcab1QxaL8Jcom3bbZ381cOJcZbIGBXJmJ+h4J3WRs/0qKKEC/CAad2R1DOticpicvZCO8D/SyrjGTof7/mm4cZ3DJhu8JFGTb974BS9a6+7CqknwqW6kEOCnz6BniXhXsZjZOK5XyMkW9QJ7b4XatLDJdbypfnuy8F1hUlDsjJJWaUb24A3oHbPh8tUfWpyaUKnPQk7hZk7ygQ4Kx0YL8/MsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4Lb6Il9WDhhahCKVm78OXlEpHAqcdvwjIcirTU6HN1s=;
 b=CI+FRx8XieK7AhThtk4kmVBMaxxvRKiDHCx9+b8ca5l50PoZLc9739PO6j33TxIHYSi2ynrhe78xgU+/16x7AYyxTJ6NeXs6gBI2Xdi2ErcO1n78C0rosUpuwFzlaGmTT+bRGYEtxfvuEtuRIBFxBrp6lQBnJetSqwKArFjpkI/BYFUBMuqFYMl9qQU2P+ud8qVIRq6VGPCgU/jZiq3+Ev/KH+yOYrH50kFHnhTW9ZMYWeccH/Q0xvWBwM3kAu2nImYfnvULfysrpLz/X4lm8pwdd52x+ISIcdxOoCRVMF5Au9ZTfbaOhtLqr970TaJhKLsD77ofChAspTouzzfPGQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4Lb6Il9WDhhahCKVm78OXlEpHAqcdvwjIcirTU6HN1s=;
 b=fr2MV6gTgj5/JWilBe1pjXiRhjwfTq0zllqVO75d2JTemuwyvJz/8tu/YJK/Jk1K7QzpO+it80KWXFOIDoJyopTjjIQwwTTeZJsOvs5bv4Arhsj1BBV2LdkjwnDsKE4kSwqUEb7yWxbkNs3mq2hE4JmpruWVO5qgbCSYz/4D4kD5/QLv9E6pKIzPbBJlohx/JkW3FyYyO3ITn2JjNhZZclv/F6WdGjugOUMbZUVtEmv1O0Hiyag2GWnLMjcPd7c0D6Hg/py6z/bxEvcbop2yfqRLfxalNYklpEM9KOYsaFirXib78EqRKtpcWRNwbeMWBF5U1/0B/akDojtC4AvHrA==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by ROAP284MB1676.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:93::7) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5612.22; Thu, 15 Sep 2022 15:33:31 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::d573:9d8a:cfec:4e6b]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::d573:9d8a:cfec:4e6b%4]) with mapi id 15.20.5612.022; Thu, 15 Sep 2022
 15:33:30 +0000
Date: Thu, 15 Sep 2022 12:33:28 -0300 (-03)
From: Ivan Quitschal 
To: Hans Petter Selasky 
cc: Ivan Quitschal , freebsd-current@freebsd.org
Subject: Re: TP-LINK USB no carrier after speed test
In-Reply-To: <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
Message-ID:
 
References:  <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org> <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-TMN: [dsDCNCm3XU+dl0/EnZOIklJPYx4ux7tu]
X-ClientProxiedBy: CP4P284CA0020.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:126::6) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <1022e4ca-3aae-b4c5-b9dc-f331ee31c228@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|ROAP284MB1676:EE_
X-MS-Office365-Filtering-Correlation-Id: 7168b7b7-10ad-46e4-f230-08da972fa477
X-MS-Exchange-SLBlob-MailProps:
	C/ir7cSdGlvQpGJCIvaIQIydtot4Nh/QmNTgV4FIFh/NxCOGnirrM9RGOh252J5B/2fCytr6e6rpse2JSRf/kxPqQA0x0A2gGNK7qx2uhpnbNGKDspDmiQnXxhUIk+mdWG8kqc2TFjXJSraaWRVmeNF5XTfrpV0VBlWzvS4yy7VtRVE4IlxVJq0TiIxRg5D1/VhADFb5mNLrHYYvvOXt+C2yHuWTVZBl9/xpEWyCH+ZNWk3CYduiLJx5rZmtU5b/3gEc5B1Jt3sXj5asRj/dD4sa8np/6erpxksHVQFRJEFpe+46SLGDYefFmWdVCE9lmot3vw3QpWHdqvz2QXxKcveaPA3tuvZDEWb+ebv0WEYZVW2lrzQ+7koc2ceyTiaWoP98Tcrbf1SQ5rVLyL162bztLiGXW76OT2UhW6SuoS444VDycA6arwddl6MLE3Dv4+kUugPEIOrnSpSx5n7QtQnVnmpczeasmELbIeq4RUm9+KFrD9YnG12qxRbUMLMBef8JATzzngVVblM+UEqX92wFBV0+S82IRVw9FmeRqLT2WeUq+jh1/DfjRMujtJBoqfDheKL1h35XyqPQ/Azrpy9wkqAwPyJsJzNAFg3EOGB7AueiTXQsQ/QnA4Lm0Iwd3+piYAnCIWR3Z1oNOQIdpvcDucYxrFNCR6tBF/L5+I0SlNWmDPKjLYFhy+zVrDgB9dEETf+0aTgAee4TsmnGklvCc+VzvuZCxF8Gc3fOGUsvHGnXVb4DGmaFt1froh92
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	qEuDsAtHSIgCr1+6px1h0Xmb1NPt8/iCtW3q6O13PynlzRq5j6Ep6Kb8zbc8DuCvHgNqP3zX3odJI9YOwYSfq7JomAXCxQSsZt/tlbEY2B+MRGvnknrYVw+UP+S8E9wrYWPHu4+H7U6R8nV7j/vQ5DfQG66LIEJ2iCeSpqwm3BKFPw3y4pgsjK65gqjXZVDRqw3k4vNT4ZUMnu3DKW6RLTUTbOQnCiknrJmKz9c7H4MW8UjkhT0k6h1RC0SJx3TGDd7jfQmJblteXnFww/lg3nmr5q150UZOH81/JMJkbmdlLo5EDiKweaoVWeGUt0/KfI+UPBYDCMQtWem4iTkhgGOIpBRF3hju8TklTTtzPjqkEkTMQdsUml5N3T77hQPpxmRgmjn8AMKyRsJSs5e+kkIizPwJPQ/X/jNHdLE3avIgRT6FT7XMoXfRqQjTPZBxapI7sZX8PPhHXfbsc6w9I30HkniCpR4CRbW9Sf/a7arfYJpv6wmZjXI74t+P9Np5tzOhRu0HYiJAxiyoNL6GnlqS1/uvVHXR3XnciK4h5Uf2CBzOhVzt/r2aJUpsbG+l9gWasaLOBjn8Vnem14UA3VARU6HWmwVNe+jSyTis/0XDMNoShyNOe2TecXIKoc4Zz6YWoDl3mjT8ZELrsLIFPAMu/vFtkSzW5M9tZKLmTAYr0F1ML4v5sTZtrbxWpQOY
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?T8WuweUtP32QrhTGtcathYTXBK+uhJ0AgwQtreFbAElA2C2PLZekbu+N+spd?=
 =?us-ascii?Q?GkJ/+FO0VcJUIgUOIQ8MZktE94seKcSjUExqgG5cj+QNKPXv4nCtF6bMhdGD?=
 =?us-ascii?Q?oJanE4dBDxYR9fdX9hLYYGAJcr03bg7kgu/SzjDdid1ovCjJYJskkg79sVCv?=
 =?us-ascii?Q?3tq5hWy9LwGIieM8wn+JBFIqyhbkuFJTNI7gnhrEaC1eGRq1BrN25vFC9Cei?=
 =?us-ascii?Q?eB54z2oxRDpeKLo7l+CZ2axgTYVazPa4RxAS2MY30qgXD9Maa/9gnI2mHI2F?=
 =?us-ascii?Q?Y17eROmPtYBauCexQS3etxxp91IwfVz2TQ0RE9S/AlmXorMJGgB0SGbLTf0+?=
 =?us-ascii?Q?EViEPaKKI7PVTkxHBej0UZpetYhVjbgzSBDU9utg99xE+8O9t7PirZO7A2uE?=
 =?us-ascii?Q?bCZTasUKTVBdxrFzT3tJprBnFq5e+j/+7kz8ZCCrfDmoj688e4i8s1axiCJm?=
 =?us-ascii?Q?npF6uKWuvlpylunWUvWAbpwGzBDUAH8W9vQlCmSHEnUCw0lHouUYRy8gppuv?=
 =?us-ascii?Q?f2SHUS8rhoivudkUPKEHwfDXtPA/4sfBMJjrsIykszTupFonxuS4/lRJN5Io?=
 =?us-ascii?Q?dqX35SodDesRP+/aTn9jRj19mCOxipAXz5ZcO3G1DL+hAFErKBM/Jep3/TkP?=
 =?us-ascii?Q?5L4kxuRQ3hjjoJhTCXSBm/7ISIUynCi3bhqg/08fv6nXuBHp9crsQyVliIfA?=
 =?us-ascii?Q?ZbOB+xt/eVbunAgWiTn8j/IgZffzBGNwCk4klJsrxCF7xmPRd2uotq2T6QBY?=
 =?us-ascii?Q?a5YXtGExqo2K9pvtgf4qbVeHS/f9DCi3zNZiS75QUj3Dlbq4QpLT3KaiA7HY?=
 =?us-ascii?Q?+mkIb02AsQBuvwN0kwX6LAe1Q0tdSRATItVxouBP7PnzmQPDIGWHUW7ViiRW?=
 =?us-ascii?Q?BxgZe3USzHH3FGdN2fK3/yojaCcGC3rBP8up2RvelfGVm37cMYgAIxUFk1yC?=
 =?us-ascii?Q?HQ3+1ZA/4F7orRyXYNmz4ppaYyKWgO3HhUJyqqP/gdOhpFgudfLdl8Spmzxg?=
 =?us-ascii?Q?AIpnhas5G8qa8VxGVcelrdHQpO8hwvg8+AqOllfBoCGsaEffo/bPP58OkH02?=
 =?us-ascii?Q?fRxF2+gwkhyREdG/kFUpoPvOryLcgwsR6AjUTh6OPZyCSlG5ru8NWeza2nmm?=
 =?us-ascii?Q?Bvhp4EkgvqQ3Eaw7Kgi0OSRmSwc1fkU8gvquZ3+UvF0m67qEVd20Jv7GX3KT?=
 =?us-ascii?Q?RDefetlscauo2nq0SFyQsZkz7dDuvdfzUvH53o4547pEVi4iH8xN1XBE8z7L?=
 =?us-ascii?Q?2uyen19uMgFFeOFI0Tpsbnei9y4hAWQAr4FRYUAIMw=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 7168b7b7-10ad-46e4-f230-08da972fa477
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2022 15:33:30.7574
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB1676
X-Rspamd-Queue-Id: 4MT1SZ2SBYz3HbN
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=fr2MV6gT;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.104 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-5.00 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.104:from];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[hotmail.com,freebsd.org];
	FROM_HAS_DN(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.97.104:from];
	DKIM_TRACE(0.00)[hotmail.com:+];
	RCPT_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	FREEMAIL_FROM(0.00)[hotmail.com];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N



On Thu, 15 Sep 2022, Hans Petter Selasky wrote:

> On 9/15/22 17:18, Hans Petter Selasky wrote:
>> On 9/15/22 17:16, Ivan Quitschal wrote:
>>> 
>>> Hi All
>>> 
>>> Does anybody have any idea what could be happening here?.
>>> I have a laptop DELL INSPIRON 3511 and everything works just fine, 
>>> literally everything. even the iwlwifi0.
>>> 
>>> But in order to use my full 600mbps, i dont use the wireless but a TP-LINK 
>>> USB ethernet connected on "ue0"
>>> 
>>> ugen0.6:  at usbus0, cfg=0 md=HOST spd=HIGH 
>>> (480Mbps) pwr=ON (200mA)
>>> 
>>> 
>>> but something really strange is happening .. everytime i open the chromium 
>>> e do a speedtest (could be speedtest.net or any other) , at the end of the 
>>> test the eth interface dies .. it changes from full-duplex to 
>>> half-duplex/no carrier and the only way to get the internet back thru ue0 
>>> is by rebooting the whole thing.
>>> not even a "service netif restart" does anything
>>> 
>>> if anyone has any ideas why is that , would be appreciated
>>> 
>> 
>> Hi,
>> 
>> I think it some new features they use in the USB data protocol which we 
>> don't support. Check the Linux code.
>> 
>> Between does:
>> 
>> usbconfig -d 0.6 reset
>> 
>> recover the device?
>> 
>> --HPS
>> 
>
> Hi,
>
> Search for axge on bugzilla:
>
> I suspect you are using this chipset:
>
> Try:
>
> usbconfig show_ifdrv
>
> To know for sure.
>
> Also see:
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7Cedde022bc19842d21eec08da972e3fb5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637988522152537501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wWy4fA5uwNIN2SC%2F1BNEwdJP6pHW5bsrKyhuVkbHEZs%3D&reserved=0
>
> --HPS
>


Hi Hans,

actually the driver i use is not agxe (i thought it would be by the time i
bought the usbcard)

this is the module im using

if_ure.ko

and thank you , yes, reseting the usb entry with your command worked just fine.
i got the internet back after doing this

usbconfig -d 0.6 reset

do we have a bug here then?

thank you

--tzk




From nobody Thu Sep 15 15:36:59 2022
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 4MT1Xg5VXLz4cbkh
	for ; Thu, 15 Sep 2022 15:37:07 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2050.outbound.protection.outlook.com [40.92.96.50])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MT1Xf3V8Jz3KdL
	for ; Thu, 15 Sep 2022 15:37:06 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Vcrx4BkiVdgq07JSuPUFLOBZoV6WzFM6YwypbfRbAj5KO2s1zliKL3b8VFVcBCSjRyPgROY/tzSiqvFSXCqqvNJ6737hRmo05GcqMWX5cLtznsVdmUwiBylHddr9tgvLOvo/9RUx5Ze1r1+OQgNA/07iattc2sRmD7Jx3zz+dQuDutdY4V6QZHLcWwZmE+5FRrgeRITi17YtkIWrs12S9TGh01DnAOBLtSWLZSH1BAJeH4OGI5D12K7AUK5bD6HPyVMZdk79CyKT7R+8Y0yUwvoLQSzsv+GGbtBpsia2DJcxbCi36DfQkYCr+Wl/WaBldO8iYdKsL2yIfYdGvBRQ8w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=bGdYIYExRdCuGnkemwG/QuxUg38pEp3S0+FWrdB5S/U=;
 b=dtmpsDRE8wEdfJogUN8aOTQtMY9BkYREwxqoA49/d32+tUoYF6baPatxDL5ZYnwjChjMDA9ckCpKwfp55RpERinFfa0UHJZ7rqjDX7GvsFwngVKId8r9nm6Td0eZH7eoQFL4zfgNk/wHbTJUDQaqsZSIQgady4Oiupvx84BxAz5QwyZANjy01mYLbdQZ8GRMkZKgHVZqHo6MD/SVPg4HyOof2mE6DO7iXDP9UbMzrgLaSxtTfmBSk5pG0ZkoqYde1NLPbeOWsOSrp6skwzzYAHEULAKEYfNmYb/hsaS6iChUTgwH5Ltk4AkgYH3+V4S0pSKOb1DhBFUh+5BVdNwHLg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=bGdYIYExRdCuGnkemwG/QuxUg38pEp3S0+FWrdB5S/U=;
 b=JGKvJ+rpHzKbn7+ZdnyNPvs145r46q3oFB61CvPGrq5LDQAPFXpmt3zt1tm+0xXXPaELYb+nNelaZRLFcNAglwfgiHJCAf8k/Y9uKCKz4Ci2vTwCbhymEHJ6faWcq06llk7RmIvaWFPl9ddhA5xG/AtvztzslcjiqeELO7srPEAfeni+Vmi4brvdsVhCVoTScmjdfbte0b3cJui9+lcVk4yGDmIiG8N2/rl9M4VycwQEwbouPi3jPeuu7IkkGpKD5Q5CPvCod3P8AaNMsKiqGP0yfpeRg+HAAZrdWwF/C7/c48GtEicEGiRxxJt+wldF1i4027W7siH9p7jSljgoMA==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CPYP284MB0097.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:72::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.14; Thu, 15 Sep
 2022 15:37:01 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::d573:9d8a:cfec:4e6b]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::d573:9d8a:cfec:4e6b%4]) with mapi id 15.20.5612.022; Thu, 15 Sep 2022
 15:37:01 +0000
Date: Thu, 15 Sep 2022 12:36:59 -0300 (-03)
From: Ivan Quitschal 
To: Ivan Quitschal 
cc: Hans Petter Selasky , freebsd-current@freebsd.org
Subject: Re: TP-LINK USB no carrier after speed test
In-Reply-To: 
Message-ID:
 
References:  <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org> <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-TMN: [f1EpJuykHTbDI0eQSpXAgFkQ/FWqvhr5]
X-ClientProxiedBy: CP6P284CA0058.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:1ab::11) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <16595173-6a73-5734-ae5-e973bec567f0@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|CPYP284MB0097:EE_
X-MS-Office365-Filtering-Correlation-Id: f9fc8d29-f0eb-49b8-fe95-08da97302222
X-MS-Exchange-SLBlob-MailProps:
	C/ir7cSdGlvQpGJCIvaIQIydtot4Nh/QmNTgV4FIFh/NxCOGnirrM9RGOh252J5B/2fCytr6e6rpse2JSRf/kxPqQA0x0A2gGNK7qx2uhpnw0on2y1545jcqwPYDZYfrgH5V3nWbHeDzGg3XAaDTuCYOlUMuzrjPtEZf1hKh3+d92LPFABLKD88sdiDLwD6IYEn1wbg390WUkroe1Vrj3etOt+iB2cvGUIdt+3BTk4RI4XANGQZV8hE8Zb8chi3EppWd2sGHFZYdmLtMh3vH/imt2HFmPDdE9HYuWEzdvCIToqKwhj3xYUFLcpGYa9HMHnD6Vze8viu2ZBwvB/X/z5LQkdCzFXBDowOPWd0bSXWaT4tLe/Gnj7fGWZIDTAra0Qx4EeXVN415rhiIexizv48XObwNQGtjLz7vWC0wiNkfQ47O0KXiqvybc8pIES/egDm8tBoP9yvOHVtfXcLXvazBm9AdOwzV7bhfVlTA0pAS9OWgwlRcH80rFs01WxAwZwLyp0h7kBXSTBtvMMOsEK/rrIbbQcOvPaUS5HF4s+mBKaVtoG45bnAo5n2jVi0tZTKIWaovYyFMzHbgYGhbnrdAzMtBCJrh1b7SABW65PyylB6lqZiRzd5uiwjSX8ysOUl2x7lyh9ql3bSn0MEi/O0GPlwCavPkDvvhWB3T8uhy16OLqUIRBuZuhSTfXQEsG76/WQjCPt6+5RBpWcZp1KwBwhH4k0fqea/OVJYXba2qvFX00nd4cJhg0VF+82yO
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	K/zuU2nk6wLlugpTTi7t3gcuWhREKpwPXTFe7G/5xtNFpmCTnD+QvfKBzorS5ja6eutZcYCKwcbtZLG71aZMT0Eh5jYLPh+ykxuDjhs8BA0q378WcT8sWqDgyA5g6Sy6nqdyimTAk18wgbJb8Yu7TuIQ9abo5pS4fvWPIj4wp3Irz102pm9qpu01W7ZuDvVx0awocnWNPRSdVevYcPv+TKZZss1HCAR4rfsbAZ8890n5QOuAvHl7CT7oUtyW0D16/j+f9XNX99JBDmHM0O1DeYRrRLLiKuYwkrbgfvm8wL6RwoCwSotSee/wuaZpbTejoQ2nDey4f6DbSCmqZZsFmsgIxx9vSFPl+Bjjw+sZnRsJVx1x2Zi5xRx5MvqjEioyAOXaes88tVKxpPmqVUDlkh2wPqr5XpLpxKWb+Ba0fPewX3AS4nD5zJEZzRJpHWsKPWGfO/xS4vQsHoE4qQkrxbT/HMZuP4kAFpoeQunjiD1vs7yUuVUEStEZsk1/CT54pWsY8UUzUKjA/oSGLSOUES6z4YRlzR6MI8qnTibbGDZT8h/01lqKkDtBChSHiEnNtVmnrdmHwOP5OWxygMwwu9zH6gMov474bBJ8hO1JtY2dHfxn9N4YyyXQWqHzOuZaPQ51cXoihkOJjVtK4tJvEtWDy4IjZzFEJsUmK6qgvil0PQWg9emSUqalQOvDuYR4
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?CE/3vQnyXolPk0QabGYyR/FGqZ7+YRVO4/BDzeos2lxva6NY0ISFv1zX+69Q?=
 =?us-ascii?Q?5iki8TWoKeGfWQd9gsRxjbbvtuzIIfSHnkkplU37L7k+AhDDYKFWPak03+Xa?=
 =?us-ascii?Q?JJJMmbVFHbIQUW7vARTIoZfbqdkAIAj+8wd36DqGMHDeEjr4NKWaPGQQGFGT?=
 =?us-ascii?Q?PUf8e59/PnU7AZeSZsBqP4C75NUxQh7UuZDNB59L8FzwZGahln/903HeqWR8?=
 =?us-ascii?Q?mT1FToIQMJwWEGQg7y4P+dYPOS14TrZLRxkpsJFV0mkcFLXUYo7u4E6VJZ7i?=
 =?us-ascii?Q?p7OVxGpV1TLh5ylwnlQcxL4j9rB3/TKH2IY66uwJFqkkmU7fVFyfkmNCo58x?=
 =?us-ascii?Q?K/zevS8dyYxpVrFOfeu12Haf1TbcANuHX5KHQmit9UVPSlwvv/htcvkqfGB0?=
 =?us-ascii?Q?ZoJRxKAUo3EbS5pPYqG+tTaJm/eZ5vVrEIM0kGzBc3JWTXhqyxtXG3uVHyDS?=
 =?us-ascii?Q?AJvSNjK4YZi8Bq9paUTqOdwfZzQr87Cgmpcf728WZdmEpVlnEJ5EDZ1tSasT?=
 =?us-ascii?Q?LXo52Xjlz4ib7/SBmBklnVx9joQ3H/qlC/7TXXrAigd0V8pKT9cxKtO2fE/v?=
 =?us-ascii?Q?gSs4Ns0KoWcw8Bdor6Jw1jtoWQNn+KDlKmtxiOMRErLaVR6SOxMFaaOly+VB?=
 =?us-ascii?Q?YiWFr2zDAZHpPZRClZ1Urmil7dPHQD3dkM5zKZWgP9Wp/MBwpcxi+Giyu6iM?=
 =?us-ascii?Q?tQMKslxFiRbm+ZYe3mBneNEOav0YP7qWwjDYP75mVXI+sqibfLvujdOr9YFm?=
 =?us-ascii?Q?7HtUAEdZNyWCcz4600Yx3SxULlvPkaAU1gm9B3a+kTjhQxRqrKOli63JYKDT?=
 =?us-ascii?Q?V4L8mu6QTdUzr7G2kIijYHbKO9tuBIc/alj200uy40BJE22RwwHxJYpfOkoM?=
 =?us-ascii?Q?lJldG/RaTz5CrC7+yuJQEalDqS6z9SadrkanKDklKtpDK0C+OQV2jS6i2kig?=
 =?us-ascii?Q?kHmLvrmADgXGEyyFdgiUNUG7nXmvpAp93VR9hecIZ+JYwebnBSTQToXF8q2t?=
 =?us-ascii?Q?+emx9Cw72xd65NAVWNxXfIm3WJ/eNz10z0QoWO62rT+6hGVfzY0JTdxyjybF?=
 =?us-ascii?Q?O9ck7+hUxCwev07mrgQ8lyOfm7+CT2sxVjjDM5V1R1dhguwi1lxgmo0npIHL?=
 =?us-ascii?Q?qOiDMmo5grTAP3nxgDgQUFNoQkhzHSMFpxBiLLTH2Lv/lZpzznwo4LsmA1Pl?=
 =?us-ascii?Q?QeOaZjdNjh/JfhlFkbypBRIgw8B6WQoKJ0kCpromC3FKBU3zqZ0nUFaYyyL5?=
 =?us-ascii?Q?watVX9j3gcYXPJf3bcPbxHhZoHp7DQzHkhlXavRq5g=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: f9fc8d29-f0eb-49b8-fe95-08da97302222
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2022 15:37:01.5945
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPYP284MB0097
X-Rspamd-Queue-Id: 4MT1Xf3V8Jz3KdL
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=JGKvJ+rp;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.50 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-5.00 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15:c];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[hotmail.com];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.96.50:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.96.50:from];
	DKIM_TRACE(0.00)[hotmail.com:+];
	RCPT_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	FREEMAIL_FROM(0.00)[hotmail.com];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N



On Thu, 15 Sep 2022, Ivan Quitschal wrote:

>
>
> On Thu, 15 Sep 2022, Hans Petter Selasky wrote:
>
>> On 9/15/22 17:18, Hans Petter Selasky wrote:
>>> On 9/15/22 17:16, Ivan Quitschal wrote:
>>>> 
>>>> Hi All
>>>> 
>>>> Does anybody have any idea what could be happening here?.
>>>> I have a laptop DELL INSPIRON 3511 and everything works just fine, 
>>>> literally everything. even the iwlwifi0.
>>>> 
>>>> But in order to use my full 600mbps, i dont use the wireless but a 
>>>> TP-LINK USB ethernet connected on "ue0"
>>>> 
>>>> ugen0.6:  at usbus0, cfg=0 md=HOST spd=HIGH 
>>>> (480Mbps) pwr=ON (200mA)
>>>> 
>>>> 
>>>> but something really strange is happening .. everytime i open the 
>>>> chromium e do a speedtest (could be speedtest.net or any other) , at the 
>>>> end of the test the eth interface dies .. it changes from full-duplex to 
>>>> half-duplex/no carrier and the only way to get the internet back thru ue0 
>>>> is by rebooting the whole thing.
>>>> not even a "service netif restart" does anything
>>>> 
>>>> if anyone has any ideas why is that , would be appreciated
>>>> 
>>> 
>>> Hi,
>>> 
>>> I think it some new features they use in the USB data protocol which we 
>>> don't support. Check the Linux code.
>>> 
>>> Between does:
>>> 
>>> usbconfig -d 0.6 reset
>>> 
>>> recover the device?
>>> 
>>> --HPS
>>> 
>> 
>> Hi,
>> 
>> Search for axge on bugzilla:
>> 
>> I suspect you are using this chipset:
>> 
>> Try:
>> 
>> usbconfig show_ifdrv
>> 
>> To know for sure.
>> 
>> Also see:
>> 
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7Ce7f888b3635f4e898ca308da972fa69b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637988528164303655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zvw7m8lJ%2FHocK%2FXJIDfdPv%2FArCpE5pk9lYz%2BY8WzMCc%3D&reserved=0
>> 
>> --HPS
>> 
>
>
> Hi Hans,
>
> actually the driver i use is not agxe (i thought it would be by the time i
> bought the usbcard)
>
> this is the module im using
>
> if_ure.ko
>
> and thank you , yes, reseting the usb entry with your command worked just 
> fine.
> i got the internet back after doing this
>
> usbconfig -d 0.6 reset
>
> do we have a bug here then?
>
> thank you
>
> --tzk
>

oh, i forgot to mention that the ure driver freezes not during the 
download test but in the middle of the upload, always

dont know if that helps

thanks

--tzk

From nobody Thu Sep 15 16:45:11 2022
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 4MT33M6QJWz4cmVt
	for ; Thu, 15 Sep 2022 16:45:19 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2095.outbound.protection.outlook.com [40.92.97.95])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MT33L1d75z3Rdn
	for ; Thu, 15 Sep 2022 16:45:18 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=XjZfZGCarq2sQ+XLhceUJ5lP6/MNaWxrsa3hQLMF1tU28K6WYP4Z8AQj/gDSTAdYOVWH0GSyytlhIwDMmtAFDbbgsiWA40LAojn1akMc76JLvn6oSvRTwdtAVyG/nwtVoTaKP0pLf5d2eQ0lAwta5fp5uH2tgZXx9DqucvTBpVDLOos+Bod1OowXVVhFwE2ELqQUxVEVeKdxR3BRpfz0R07iC0nL+NwNKE+JBrCgcCEUoprU+8MqL4rRNEEIkVDeoBHUv4mq9rpZeIjMQJlaO2ViOS7gZn4Bedb9oDqXgvNHvFKycawlvWJpRDRHtTvB2BQ8MgbQPhl6I7yCt8UATw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=P+G2BslvLufl8bNzLLx0JTiL7uKitJWT7imkcmV2qRk=;
 b=JpFRsjyV6QXP1PuVuuCn6cABuW1Cv9MlLfQ6L1OLmqU2tcZHS2KttUJ811uEKSJOw4uH/2N7aSFujGDmW/OeVU3a46qv+D705K/99poVQaDJEY+4lzltqgV9l065gW73yfQII+jTd7yreegt4qbBXWoHruK/bl8xIJMo8kFrNC9OZqgQkcAr+2NyHlYbKZeudo2xM6V2OJowowqT3fNKLgkH31ND/7rVJ+NCZPdMqpoBMDrTz7GNXCKdF4Gu8hBvsXRm6JdM8eJTP/icFYIYDNwAPwwQbiAg7kMqA7FyVvll27oNJwsye3FnfJnHSNXiUdGJKUoh8j+SBtAV9JI/SQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=P+G2BslvLufl8bNzLLx0JTiL7uKitJWT7imkcmV2qRk=;
 b=KBIWEDb926Xby/Zx2FzmMxgkaXN92iUkEfJoubAMD8i5Eg2/EHNFY0YBX/7/rmfgstwKTE97afw+9K/u1/fSHEh6R0JzN5CEA+ytmHCafhEX1225byRruELDpIW3VB9xRcEBSgHNsTe3syVXKVHVBf0/LQ0RiD3gQ/CPjUiNLZrw0SCuSPotmETkGtvzKpZ/EJbhyP+kZ5n9u+sXEPRFb/S9hQFznFjSQOq/Nd2YKJusjBk3CDQMxOYu5Mac27K4qic6lSCj4fUXiFHRS5JVYUI/rfabhy9oRSBIKRjZOSNuLQPZWt9QnM2Rs0T+3O3YibTKTx5QjZc2ZmlnnHiGaw==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CPZP284MB0150.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:32::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.22; Thu, 15 Sep
 2022 16:45:14 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::d573:9d8a:cfec:4e6b]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::d573:9d8a:cfec:4e6b%4]) with mapi id 15.20.5612.022; Thu, 15 Sep 2022
 16:45:14 +0000
Date: Thu, 15 Sep 2022 13:45:11 -0300 (-03)
From: Ivan Quitschal 
To: Ivan Quitschal 
cc: Hans Petter Selasky , freebsd-current@freebsd.org
Subject: Re: TP-LINK USB no carrier after speed test
In-Reply-To: 
Message-ID:
 
References:  <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org> <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org> 
 
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-TMN: [ba3fx7sK+t2qHYvJ2uUOUdKqTxuSusLn]
X-ClientProxiedBy: CP5P284CA0088.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:93::21) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <98fe8bf2-50fe-5cc3-5590-715a79e5193e@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|CPZP284MB0150:EE_
X-MS-Office365-Filtering-Correlation-Id: 9767c000-284f-49d2-323d-08da9739a94c
X-MS-Exchange-SLBlob-MailProps:
	C/ir7cSdGlvQpGJCIvaIQIydtot4Nh/QW11rs1HBUEvgGYHTRbd+gN2oG1rWfe/9OFpzmBBsdbKTwA2NzC3moR7h7i7usqpxK1wooTAbszuA3HAk+0noCQicug3IoW9OlkoMw5cVVcaF6kpBb9uQ/KDgN4MDbn0UqaQ2n4XBu5SMJcvjTjmTYavmbHfqefo0O9yNhtlc6rSbjH2444lixtxiYiirEQ1nhVUj+BCqLHLA4a0STNl/u3ajoWu+BkDBxWGBr2nuCESyxWosw2KFsY8pPg10SrGtSlyscLBjvCU2YDqNyknCW99LZo7AnoAUFfRMHKgAdYFBbxvyie6Ngn57pDX/UquvRdZmTsAAZUsjqzIk4Tk1wjGpkhrX0Sf+MymOakI9aINwREVJEyCzl+6aZezm8eGZLAkPZBWs4vZOK6ffBZMU/PYoW+SFwe45a2qzmqTgCtqYFQmd75ZxhqExTuxHhECikpB9okKwMIQRYrg/67ypFmrmmMzKFyZcG2lk/Yd4Hj6/UD8o1fLVh3U+L/B2keI0Iaa9FXA536J2J4alJfahrZRwNVRGqPD2xGUc0TrDnCq+ieku0SaISU8By2d70N1cFuXviegkp4/3teWY64A1k2PyIJ//czDQS5ZX6wkccMw7AyrNfgB+Zr0GO1Nk2yW8y+GNUdnarvFhfx6BQstbg5e7EtQlKEq05HOd3IZwReeF9u7+dblc+3jH0hPvuLR3sXYh4ri8KrBkI8Azazq1xGgZ3WKk0vH4
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	a4zovuet8PfXKAmXvoyHDBbbmfCTTHgFeJyy4DCe9w6O5F+67HJfxGybeVZHJA82V5epAUKLeUe3rFJ6oyoeXd+hnBvmqicsrBpwu2s6pcddu1Oa2fPEgOaxCoieR8Li6JwivAo6QMk9b1mr8uUyCKXMwX+JTaSQ0UWtEqQGd7LUDkaiqdKak6XKTuJ7v2ppQFrKv8ddQrvzK34T2u6pZOfO7zDRWqQylSBx+TrSovsrvvF6+2z28z66PUcBLBAkp/nMxT9ht/FP7L4UH+umMNHkfbBaJX5EiSIL+PgsOgOdrVGMxNHsSI+/qgEMORINk+lovXWGJWkEuEUsnYhckqHCJF+NLheDxBhyHzNdGhYmfqK7s6JCB0P1NC5FLP0fAf58JfstJyT74jP6NasZ44LsBuZDuX3zcCC5qtPceMEkI6m8t5D4Y53rY3BIfipOGj7DKtqF3xSNfYWT3M+YN0MOnSWp+DCKE0OA+trZXH+E72sCnsukTCL4NhajJmkJcL3KXveABGCgMCQlrTzbY3/+Iea4Dv23mIeBl1SUmE2Pu4S7wt8sHGG6eZzLswkm9XTe0LGlLdBgVAFcO+dLQj0HjBoowDV/gV3mggYn5qwJRcYXHHUEtKyMw1RZsTAMYBq3Y/afu30wzhMDBtUWgmyhCQV/C8yov5xDeewzmlTOPDKW46GbjcGEuXkVLfKU
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?XUeThWXmBjNR4Bdp0801XfYpbS6S++4RNFOOB+/Z/UcEbzRVRR6cbTTBKV+Y?=
 =?us-ascii?Q?EQRwizcDbIKM8tOz+TbSsWsVm6U4LbgKiOPCFCGGBfhwzfGMRwOw488k+5jG?=
 =?us-ascii?Q?TznywCxsc2eQsC9n35MA5CoHvRdZIPnNRVy7za1OWPBhfwJSz/eJC6i9Qn5W?=
 =?us-ascii?Q?dEVz+Dv4tZzUiNZKcfVjv9Piz0fmIRtZlH5MeKZ0p894OPzbGZVBO9OOiizT?=
 =?us-ascii?Q?G000xULYEL25n50vOn4t7+J6M2UlYFRDGh9F6wqsKBxV/QOgPeOFyTxd6baF?=
 =?us-ascii?Q?EDMKzS/SuxfGcXOnoENUokmd7XGkMqxk3txFQyeZf0IfVD0HAK4FZb+H7Epq?=
 =?us-ascii?Q?8T5t/zAWOzC0RnL4Zq/zDIta0LbTVgp/qgoG3wukFkb2j3+q/D6L4H4k6eQa?=
 =?us-ascii?Q?GbGoiHjVIOzjAXuqaPw5U43EnyDqTY8MrHbf+3zxTTxQWvC4IuXIdkMGDtv8?=
 =?us-ascii?Q?pOMPIPr25FfETSCFzkW0/II1kFEwMou3d8rndLqBjV07P3H5nZaFNkfpoOwA?=
 =?us-ascii?Q?BxRLSDjPNkA4imD/4q5eI9MX6cqL1fN8B72NZt5VzqTJXjLV5eJiyih+Fcuq?=
 =?us-ascii?Q?5ilE/u/lPad7OpsFQ9Sa4cPNwixT3F1khwAYEUWdWVv7dGDBvTjzqCTDGcHQ?=
 =?us-ascii?Q?QBeeMy3K15k6hIJnxTa7GfA2bv0QXuUHhAI8pj0iH/wjl6LnULWxDvRdVaMS?=
 =?us-ascii?Q?j1W0PaVEqYGrwewmeUxXAIfdj6tPh/BFjgQ3aOFdI6Rw9xEyM98sE/1lshSr?=
 =?us-ascii?Q?qbncGXEE8ICRYSCR6TPxACToTQuf1m1CE2VakFuw+moIApuQeGwzz4XvoI2v?=
 =?us-ascii?Q?Jk8SGT85ykhbqGIuWomdcs3AEV6aKRHhv0wiLQjugPHERJGrNNl1TSBvYQeO?=
 =?us-ascii?Q?glwqWACYx4juBH6y0lBIQFPHeAm2K1Hvi5mltxswjBUG2AwJn98an7+4ZCcG?=
 =?us-ascii?Q?P7MD9hRtq/H+IHMCfuu4ZcQNDa0OmwXVd9IWgica1Fv+RDSsHAMk2FlTIono?=
 =?us-ascii?Q?YofU2gF/TrSuHuzDHA12yBajLkaKN/ShcFckpwCHPQf15bAVIiOY6jOs8daj?=
 =?us-ascii?Q?QcS46nHXx1z1ZY9AutQqSxNAhVKNef+5Jt0vEks3u7FAkq+gy1ENtaxBCKnj?=
 =?us-ascii?Q?Fsf19EmK3r1dH+3+qLUvJw6teuJruTN1IX8ohRv3+jZnq3Gr4QdWMz/G5oCG?=
 =?us-ascii?Q?bz0G8n0DWXJyHAM8CuloJaO3tvfE4aH40epKnQ62O19/L+RDfeyQWNqd5UId?=
 =?us-ascii?Q?Ytpg5avzhD15zWNJWUVDeq5un3wf/c5K/CUsLDkjdw=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 9767c000-284f-49d2-323d-08da9739a94c
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2022 16:45:14.3304
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPZP284MB0150
X-Rspamd-Queue-Id: 4MT33L1d75z3Rdn
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=KBIWEDb9;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.95 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-5.00 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[hotmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.95:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FREEMAIL_FROM(0.00)[hotmail.com];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N



On Thu, 15 Sep 2022, Ivan Quitschal wrote:

>
>
> On Thu, 15 Sep 2022, Ivan Quitschal wrote:
>
>> 
>> 
>> On Thu, 15 Sep 2022, Hans Petter Selasky wrote:
>> 
>>> On 9/15/22 17:18, Hans Petter Selasky wrote:
>>>> On 9/15/22 17:16, Ivan Quitschal wrote:
>>>>> 
>>>>> Hi All
>>>>> 
>>>>> Does anybody have any idea what could be happening here?.
>>>>> I have a laptop DELL INSPIRON 3511 and everything works just fine, 
>>>>> literally everything. even the iwlwifi0.
>>>>> 
>>>>> But in order to use my full 600mbps, i dont use the wireless but a 
>>>>> TP-LINK USB ethernet connected on "ue0"
>>>>> 
>>>>> ugen0.6:  at usbus0, cfg=0 md=HOST spd=HIGH 
>>>>> (480Mbps) pwr=ON (200mA)
>>>>> 
>>>>> 
>>>>> but something really strange is happening .. everytime i open the 
>>>>> chromium e do a speedtest (could be speedtest.net or any other) , at the 
>>>>> end of the test the eth interface dies .. it changes from full-duplex to 
>>>>> half-duplex/no carrier and the only way to get the internet back thru 
>>>>> ue0 is by rebooting the whole thing.
>>>>> not even a "service netif restart" does anything
>>>>> 
>>>>> if anyone has any ideas why is that , would be appreciated
>>>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> I think it some new features they use in the USB data protocol which we 
>>>> don't support. Check the Linux code.
>>>> 
>>>> Between does:
>>>> 
>>>> usbconfig -d 0.6 reset
>>>> 
>>>> recover the device?
>>>> 
>>>> --HPS
>>>> 
>>> 
>>> Hi,
>>> 
>>> Search for axge on bugzilla:
>>> 
>>> I suspect you are using this chipset:
>>> 
>>> Try:
>>> 
>>> usbconfig show_ifdrv
>>> 
>>> To know for sure.
>>> 
>>> Also see:
>>> 
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7C84d8684abc754f0596a108da97302431%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637988530285207791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Lrg%2Fy3DsJOZj8MedxLJz2nkpm0swb8W%2F%2Bk1ZoRPKMT8%3D&reserved=0
>>> 
>>> --HPS
>>> 
>> 
>> 
>> Hi Hans,
>> 
>> actually the driver i use is not agxe (i thought it would be by the time i
>> bought the usbcard)
>> 
>> this is the module im using
>> 
>> if_ure.ko
>> 
>> and thank you , yes, reseting the usb entry with your command worked just 
>> fine.
>> i got the internet back after doing this
>> 
>> usbconfig -d 0.6 reset
>> 
>> do we have a bug here then?
>> 
>> thank you
>> 
>> --tzk
>> 
>
> oh, i forgot to mention that the ure driver freezes not during the download 
> test but in the middle of the upload, always
>
> dont know if that helps
>
> thanks
>
> --tzk
>

hi Hans

i've seen you made 2 patches for ure driver which looked like a little with the 
problem im having here.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256675

problem is, its not compiling any longer, code must have changed since you made 
the patch.

regarding the "axge" bugzilla you sent me , THATS EXACTLY the problem im 
having. The workaround for the guy's problem 
was doing this:

# ifconfig ue0 media 1000baseT mediaopt flow

problem is, my ure/ue0 interface does not have that option "flow"

-----------------------------
[tzk@tzk-inspiron ~ ]$ ifconfig -m ue0
ue0: flags=8843 metric 0 mtu 1500

options=68009b

capabilities=68009b
         ether 54:af:97:86:be:2c
         inet 192.168.0.35 netmask 0xffffff00 broadcast 192.168.0.255
         media: Ethernet 1000baseT 
         status: active
         supported media:
                 media autoselect
                 media 1000baseT mediaopt full-duplex,master
                 media 1000baseT mediaopt full-duplex
                 media 100baseTX mediaopt full-duplex
                 media 100baseTX
                 media 10baseT/UTP mediaopt full-duplex
                 media 10baseT/UTP
                 media none
         nd6 options=29
--------------------------------

any ideas or any other patch you made ?
appreciate any insights

thanks in advance

--tzk

From nobody Thu Sep 15 22:27:21 2022
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 4MTBf63JNsz4cWbG
	for ; Thu, 15 Sep 2022 22:27:26 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTBf44jFdz3tF7
	for ; Thu, 15 Sep 2022 22:27:24 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
	by mailout.nyi.internal (Postfix) with ESMTP id B0B955C00FB
	for ; Thu, 15 Sep 2022 18:27:23 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
  by compute4.internal (MEProxy); Thu, 15 Sep 2022 18:27:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm2; t=1663280843; x=1663367243; bh=k/b1d0UB0i
	fTKx6cvM+4Te97B6TedgNxdyoUeDvwwM4=; b=HYqlQPHtRCd4pmSogz1FB1qoVe
	eTIusQCD4bM/qIfzK26LeIyNoIIhTF1tV0CuAdRBTGpSh7E9bLfixOgeInU1BSdh
	gygib2waCXFZY2Tb2J9QgdEojwiFmuGgYXWUqZKRdOky8bxgrTPiwQ4ZBCaNS3CM
	MguP4EvTWEfGSiGlzXSozO/1dzWw7m5lhNSuUJTW5NPzBDIepzHZFe8ks/s4mago
	9c953n5PKf9gUYstXrG/LHM7gUjJlF1lu24CVZ+deilVdOCCAP+sFfyok5TPxxy8
	AUShikbIxBFktjoNKp7vgVsFtzSiZeR4PgbPfK9ngQyvmcWjgsc+HVo6hIZQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:in-reply-to:message-id
	:mime-version:references:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm2; t=1663280843; x=1663367243; bh=k/b1d0UB0ifTKx6cvM+4Te97B6Te
	dgNxdyoUeDvwwM4=; b=s9ogTl3LNuNHFcO2gwTC+B/TTXnpdP31fuf8+klTo+oB
	RhK6k8+9PaXA71lUTG/+NDndhXApdulctbPt2vnBBNwVwZaDCyk07Z6JR6AyWbwL
	gfzbxfEEUQ47GwtJT4djiL+qzbbixqhNE9d319o41LU9A7AKAtmewYwUTouMbMQ9
	sALfPdsttHkdmD57VqsEuVAirvoA0bkfzcv1yRkHcckFcfQzoUM+KhwbFzUMQbu7
	spvfw7RGcgcnRcNJ0xFuLKachV60iQ9eU+X7XFeFyN9oKSDTs+90M2jhLfoDmNLF
	knGWb420PjDRayY5tvqM5mqkSF+cq4OYpuF0rS7hqA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeduledgudduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtro
    dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr
    thhtvghrnhepieevgfefgeffhffggfeitdejjefhteeffefgleefieevleevjeeuieduge
    elgffgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep
    vhhoihgusehfqdhmrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Thu, 15 Sep 2022 18:27:23 -0400 (EDT)
Date: Thu, 15 Sep 2022 23:27:21 +0100
From: void 
To: freebsd-current@freebsd.org
Subject: Re: TP-LINK USB no carrier after speed test
Message-ID: 
Mail-Followup-To: freebsd-current@freebsd.org
References: 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
 <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4MTBf44jFdz3tF7
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm2 header.b=HYqlQPHt;
	dkim=pass header.d=messagingengine.com header.s=fm2 header.b=s9ogTl3L;
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.27 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-4.44 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	NEURAL_HAM_MEDIUM(-0.98)[-0.983];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	NEURAL_HAM_LONG(-0.36)[-0.357];
	R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2];
	RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from];
	MIME_GOOD(-0.10)[text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Sep 15, 2022 at 01:45:11PM -0300, Ivan Quitschal wrote:

>capabilities=68009b
>         ether 54:af:97:86:be:2c
>         inet 192.168.0.35 netmask 0xffffff00 broadcast 192.168.0.255
>         media: Ethernet 1000baseT 
>         status: active
>         supported media:
>                 media autoselect
>                 media 1000baseT mediaopt full-duplex,master
>                 media 1000baseT mediaopt full-duplex
>                 media 100baseTX mediaopt full-duplex
>                 media 100baseTX
>                 media 10baseT/UTP mediaopt full-duplex
>                 media 10baseT/UTP
>                 media none
>         nd6 options=29

In /etc/rc.conf, is it autoselected (so no mediaopt line) 
or are you specifying the media 1000baseT mediaopt full-duplex,master ?

I'm asking because some network devices sometimes seem to *require* 
the speed to be specified because they don't play well autonegotiating.
-- 

From nobody Thu Sep 15 23:00:32 2022
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 4MTCNP1Y1Dz4ccTf;
	Thu, 15 Sep 2022 23:00:37 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTCNN3ZZTz3xhp;
	Thu, 15 Sep 2022 23:00:36 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: by mail-pl1-x62c.google.com with SMTP id l10so19750158plb.10;
        Thu, 15 Sep 2022 16:00:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :references:in-reply-to:mime-version:from:to:cc:subject:date;
        bh=gLruk2nidha8R62TkgaOHg0e26WXRaBz3m5BXBrVhoo=;
        b=G+LD/RKdVCweubJZ8OqPVD+lS6expHB+ecnO/BJYeuw1CGsYfypoUTSLCu5p0UGdSj
         /8Zh9YitukTG5y8qeXte+gQbtQ4UlRkpToPMyWpwQoXZnQ2QHJNb0/+CnqAy88p1R8OW
         ntzh64FVYfb96OBZ8qmjBesnMJoaRHVZ3bikZfPXd1h5dIl4iGdgYfnpTV3mYA6+Fuad
         mcuTbnwslkmD1otpOYjEztQzxCADTQ2eb60tVMEFFL/MeZ5RqVVnE9t+Ms5WfuBgYixB
         jve7uxIeAmz8qXhtzdUfzdyaFgA/DNWcCi0gs9GgBw5FHIeu607FGewANv9TQ2IlCkN2
         V/kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc
         :subject:date;
        bh=gLruk2nidha8R62TkgaOHg0e26WXRaBz3m5BXBrVhoo=;
        b=FkXk7AVzIla3AqmrszoSxQZX/Zt5cNq0wL/bxeaWnhULmT6LbNi2hSTQpV0zfnBXRW
         v4xFfaIl1kkEmD/ae6rmRHPpiqkUyZrmb0VbdSWyjZQHUYGeR8ZEHCnOdJRf+cfwQy28
         RGi8+oT0PLShmfSsNur5Fq+PD4jDZAtbKTHEmRgIWGeoWkemsh7I1i3xeE7hc/DD4T8I
         O+XDSJN92FYP+eVTtbsyRxRq5CWoQBkvveIdOkLIqjpiTKZXZU5ORQeitVMb7r8sqKmT
         MH2ljlbsPtX3lneLNKSfHl2DxYyot8GuHMOvvBMBnYHomrBvwb5s7x9l/wAqgLB/3W2N
         Tetw==
X-Gm-Message-State: ACrzQf1FTWdJLyyvk3VB5Ohxd5hYSn6W4YJEHUaOXIzsE8Lz6XQbWFcc
	I1vxD5CQbcOP5FbMtzRZMCJKXlbgKOM6psDdjcunVmcT/Zen1c3Sj38=
X-Google-Smtp-Source: AMsMyM4N7Vm064HzmmxQ4iU4V/a5hF2nVDIZRdQ0fmLAB/FPeclm+1E6rswlQ0njFisCA9FdkU2OVv/sDs4XODDRYPE=
X-Received: by 2002:a17:902:f682:b0:178:3ede:a12f with SMTP id
 l2-20020a170902f68200b001783edea12fmr1857064plg.26.1663282833258; Thu, 15 Sep
 2022 16:00:33 -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
Received: by 2002:a17:902:ccc9:b0:175:41cd:2693 with HTTP; Thu, 15 Sep 2022
 16:00:32 -0700 (PDT)
In-Reply-To: <86h718sqdx.fsf@ltc.des.no>
References: <86h718sqdx.fsf@ltc.des.no>
From: grarpamp 
Date: Thu, 15 Sep 2022 19:00:32 -0400
Message-ID: 
Subject: Re: Putting OPIE to rest
To: freebsd-security@freebsd.org
Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, des@des.no
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4MTCNN3ZZTz3xhp
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="G+LD/RKd";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::62c as permitted sender) smtp.mailfrom=grarpamp@gmail.com
X-Spamd-Result: default: False [-2.53 / 15.00];
	NEURAL_HAM_MEDIUM(-0.86)[-0.857];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	NEURAL_HAM_LONG(-0.48)[-0.475];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	NEURAL_HAM_SHORT(-0.20)[-0.199];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-security@freebsd.org,freebsd-hackers@freebsd.org,freebsd-current@freebsd.org];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::62c:from];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 9/15/22, Dag-Erling Sm=C3=B8rgrav  wrote:
> I will be removing OPIE from the main branch within the next few days.
> It has long outlived its usefulness.  Anyone still using it should look
> into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator).
> https://reviews.freebsd.org/D36592

At least so long as PAM remains available, OPIE should be
maintained as a PAM option, and be updated.

OPIE is the only PAM that allows printing out the future
secure tokens. Old school, secure, it just works.

HOTP requires hardware, TOTP requires time,
neither are printable, both of those require some other
[hackable] hw/sw device that costs $$$ money, and
those devices all have different threat/failure/admin models
than simple paper.

If people don't like...
- The hash algo, a volunteer committer can update it to sha256.
- The list of words, a volunteer committer can update it to
read from a list of admin supplied words in:
/etc/opie_words.txt
- The number of words, a volunteer committer can add an
option to the config for that.
- The writeable state breaking in a read-only root, a volunteer
committer can add a config option to point that elsewhere.
- The randomness, a volunteer committer can update it
to modern randomness.

And if people still don't like it, then commit those simple updates,
and push it out to ports, instead of killing users use of it.

From nobody Thu Sep 15 23:38:35 2022
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 4MTDDS5yNsz4cjNY;
	Thu, 15 Sep 2022 23:38:48 +0000 (UTC)
	(envelope-from des@des.no)
Received: from smtp.des.no (smtp.des.no [IPv6:2a01:4f9:c011:3eaf::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTDDQ4L09z46Rd;
	Thu, 15 Sep 2022 23:38:46 +0000 (UTC)
	(envelope-from des@des.no)
Received: from ltc.des.no (unknown [84.211.31.80])
	by smtp.des.no (Postfix) with ESMTPSA id A302D26161;
	Thu, 15 Sep 2022 23:38:35 +0000 (UTC)
Received: by ltc.des.no (Postfix, from userid 1001)
	id 435B4924D4; Fri, 16 Sep 2022 01:38:35 +0200 (CEST)
From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= 
To: grarpamp 
Cc: freebsd-security@freebsd.org,  freebsd-hackers@freebsd.org,
  freebsd-current@freebsd.org
Subject: Re: Putting OPIE to rest
In-Reply-To: 
	(grarpamp@gmail.com's message of "Thu, 15 Sep 2022 19:00:32 -0400")
References: <86h718sqdx.fsf@ltc.des.no>
	
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (berkeley-unix)
Date: Fri, 16 Sep 2022 01:38:35 +0200
Message-ID: <86czbwryx0.fsf@ltc.des.no>
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-Queue-Id: 4MTDDQ4L09z46Rd
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of des@des.no designates 2a01:4f9:c011:3eaf::2 as permitted sender) smtp.mailfrom=des@des.no
X-Spamd-Result: default: False [-2.67 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	R_MIXED_CHARSET(0.62)[subject];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	ASN(0.00)[asn:24940, ipnet:2a01:4f9::/32, country:DE];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org,freebsd-security@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEFALL_USER(0.00)[des];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[des.no];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

grarpamp  writes:
> OPIE is the only PAM that allows printing out the future
> secure tokens. Old school, secure, it just works.
>
> HOTP requires hardware, TOTP requires time,
> neither are printable, both of those require some other
> [hackable] hw/sw device that costs $$$ money, and
> those devices all have different threat/failure/admin models
> than simple paper.

Neither HOTP nor TOTP require dedicated devices.  HOTP codes are
sequential and can be pre-generated and printed if that's what you
prefer.

DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no

From nobody Fri Sep 16 06:20:59 2022
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 4MTP8n08MNz4cYPv
	for ; Fri, 16 Sep 2022 06:21:13 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTP8m1RCxz3bh1
	for ; Fri, 16 Sep 2022 06:21:12 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.3.0.5] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id B4247260236;
	Fri, 16 Sep 2022 08:21:02 +0200 (CEST)
Message-ID: 
Date: Fri, 16 Sep 2022 08:20:59 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: TP-LINK USB no carrier after speed test
Content-Language: en-US
To: Ivan Quitschal 
Cc: freebsd-current@freebsd.org
References: 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
 <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MTP8m1RCxz3bh1
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[hotmail.com];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/15/22 17:36, Ivan Quitschal wrote:
> 
> 
> On Thu, 15 Sep 2022, Ivan Quitschal wrote:
> 
>>
>>
>> On Thu, 15 Sep 2022, Hans Petter Selasky wrote:
>>
>>> On 9/15/22 17:18, Hans Petter Selasky wrote:
>>>> On 9/15/22 17:16, Ivan Quitschal wrote:
>>>>>
>>>>> Hi All
>>>>>
>>>>> Does anybody have any idea what could be happening here?.
>>>>> I have a laptop DELL INSPIRON 3511 and everything works just fine, 
>>>>> literally everything. even the iwlwifi0.
>>>>>
>>>>> But in order to use my full 600mbps, i dont use the wireless but a 
>>>>> TP-LINK USB ethernet connected on "ue0"
>>>>>
>>>>> ugen0.6:  at usbus0, cfg=0 md=HOST 
>>>>> spd=HIGH (480Mbps) pwr=ON (200mA)
>>>>>
>>>>>
>>>>> but something really strange is happening .. everytime i open the 
>>>>> chromium e do a speedtest (could be speedtest.net or any other) , 
>>>>> at the end of the test the eth interface dies .. it changes from 
>>>>> full-duplex to half-duplex/no carrier and the only way to get the 
>>>>> internet back thru ue0 is by rebooting the whole thing.
>>>>> not even a "service netif restart" does anything
>>>>>
>>>>> if anyone has any ideas why is that , would be appreciated
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> I think it some new features they use in the USB data protocol which 
>>>> we don't support. Check the Linux code.
>>>>
>>>> Between does:
>>>>
>>>> usbconfig -d 0.6 reset
>>>>
>>>> recover the device?
>>>>
>>>> --HPS
>>>>
>>>
>>> Hi,
>>>
>>> Search for axge on bugzilla:
>>>
>>> I suspect you are using this chipset:
>>>
>>> Try:
>>>
>>> usbconfig show_ifdrv
>>>
>>> To know for sure.
>>>
>>> Also see:
>>>
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7Ce7f888b3635f4e898ca308da972fa69b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637988528164303655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zvw7m8lJ%2FHocK%2FXJIDfdPv%2FArCpE5pk9lYz%2BY8WzMCc%3D&reserved=0 
>>>
>>>
>>> --HPS
>>>
>>
>>
>> Hi Hans,
>>
>> actually the driver i use is not agxe (i thought it would be by the 
>> time i
>> bought the usbcard)
>>
>> this is the module im using
>>
>> if_ure.ko
>>
>> and thank you , yes, reseting the usb entry with your command worked 
>> just fine.
>> i got the internet back after doing this
>>
>> usbconfig -d 0.6 reset
>>
>> do we have a bug here then?
>>
>> thank you
>>
>> --tzk
>>
> 
> oh, i forgot to mention that the ure driver freezes not during the 
> download test but in the middle of the upload, always
> 
> dont know if that helps
> 
> thanks
> 
> --tzk

Hi Ivan,

Yes, there seems to be problem there. I need to look at the driver. 
Maybe it is simply sending too much data, than the device can handle!

--HPS

From nobody Fri Sep 16 06:34:03 2022
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 4MTPRl3V8mz4cb3M
	for ; Fri, 16 Sep 2022 06:34:11 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4MTPRk1xfVz3dBq
	for ; Fri, 16 Sep 2022 06:34:10 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.3.0.5] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 51DCD260236;
	Fri, 16 Sep 2022 08:34:08 +0200 (CEST)
Message-ID: <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
Date: Fri, 16 Sep 2022 08:34:03 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: TP-LINK USB no carrier after speed test
Content-Language: en-US
From: Hans Petter Selasky 
To: Ivan Quitschal 
Cc: freebsd-current@freebsd.org
References: 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
 <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
 
 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MTPRk1xfVz3dBq
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[hotmail.com];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/16/22 08:20, Hans Petter Selasky wrote:
> On 9/15/22 17:36, Ivan Quitschal wrote:
>>
>>
>> On Thu, 15 Sep 2022, Ivan Quitschal wrote:
>>
>>>
>>>
>>> On Thu, 15 Sep 2022, Hans Petter Selasky wrote:
>>>
>>>> On 9/15/22 17:18, Hans Petter Selasky wrote:
>>>>> On 9/15/22 17:16, Ivan Quitschal wrote:
>>>>>>
>>>>>> Hi All
>>>>>>
>>>>>> Does anybody have any idea what could be happening here?.
>>>>>> I have a laptop DELL INSPIRON 3511 and everything works just fine, 
>>>>>> literally everything. even the iwlwifi0.
>>>>>>
>>>>>> But in order to use my full 600mbps, i dont use the wireless but a 
>>>>>> TP-LINK USB ethernet connected on "ue0"
>>>>>>
>>>>>> ugen0.6:  at usbus0, cfg=0 md=HOST 
>>>>>> spd=HIGH (480Mbps) pwr=ON (200mA)
>>>>>>
>>>>>>
>>>>>> but something really strange is happening .. everytime i open the 
>>>>>> chromium e do a speedtest (could be speedtest.net or any other) , 
>>>>>> at the end of the test the eth interface dies .. it changes from 
>>>>>> full-duplex to half-duplex/no carrier and the only way to get the 
>>>>>> internet back thru ue0 is by rebooting the whole thing.
>>>>>> not even a "service netif restart" does anything
>>>>>>
>>>>>> if anyone has any ideas why is that , would be appreciated
>>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I think it some new features they use in the USB data protocol 
>>>>> which we don't support. Check the Linux code.
>>>>>
>>>>> Between does:
>>>>>
>>>>> usbconfig -d 0.6 reset
>>>>>
>>>>> recover the device?
>>>>>
>>>>> --HPS
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> Search for axge on bugzilla:
>>>>
>>>> I suspect you are using this chipset:
>>>>
>>>> Try:
>>>>
>>>> usbconfig show_ifdrv
>>>>
>>>> To know for sure.
>>>>
>>>> Also see:
>>>>
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7Ce7f888b3635f4e898ca308da972fa69b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637988528164303655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zvw7m8lJ%2FHocK%2FXJIDfdPv%2FArCpE5pk9lYz%2BY8WzMCc%3D&reserved=0 
>>>>
>>>>
>>>> --HPS
>>>>
>>>
>>>
>>> Hi Hans,
>>>
>>> actually the driver i use is not agxe (i thought it would be by the 
>>> time i
>>> bought the usbcard)
>>>
>>> this is the module im using
>>>
>>> if_ure.ko
>>>
>>> and thank you , yes, reseting the usb entry with your command worked 
>>> just fine.
>>> i got the internet back after doing this
>>>
>>> usbconfig -d 0.6 reset
>>>
>>> do we have a bug here then?
>>>
>>> thank you
>>>
>>> --tzk
>>>
>>
>> oh, i forgot to mention that the ure driver freezes not during the 
>> download test but in the middle of the upload, always
>>
>> dont know if that helps
>>
>> thanks
>>
>> --tzk
> 
> Hi Ivan,
> 
> Yes, there seems to be problem there. I need to look at the driver. 
> Maybe it is simply sending too much data, than the device can handle!
> 
> --HPS
> 

Hi,

Try lowering this constant to 8192:

sys/dev/usb/net/if_urereg.h:#define	URE_TX_BUFSZ		16384

Then recompile and install if_ure:

make -C sys/modules/usb/ure KMODDIR=/boot/kernel all install

--HPS

From nobody Fri Sep 16 06:38:44 2022
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 4MTPY62z1Wz4cbkX
	for ; Fri, 16 Sep 2022 06:38:50 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTPY56Hhhz3fKV
	for ; Fri, 16 Sep 2022 06:38:49 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.3.0.5] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 4776B260236;
	Fri, 16 Sep 2022 08:38:48 +0200 (CEST)
Message-ID: <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
Date: Fri, 16 Sep 2022 08:38:44 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: TP-LINK USB no carrier after speed test
Content-Language: en-US
From: Hans Petter Selasky 
To: Ivan Quitschal 
Cc: freebsd-current@freebsd.org
References: 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
 <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
In-Reply-To: <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4MTPY56Hhhz3fKV
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[hotmail.com];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/16/22 08:34, Hans Petter Selasky wrote:
> On 9/16/22 08:20, Hans Petter Selasky wrote:
>> On 9/15/22 17:36, Ivan Quitschal wrote:
>>>
>>>
>>> On Thu, 15 Sep 2022, Ivan Quitschal wrote:
>>>
>>>>
>>>>
>>>> On Thu, 15 Sep 2022, Hans Petter Selasky wrote:
>>>>
>>>>> On 9/15/22 17:18, Hans Petter Selasky wrote:
>>>>>> On 9/15/22 17:16, Ivan Quitschal wrote:
>>>>>>>
>>>>>>> Hi All
>>>>>>>
>>>>>>> Does anybody have any idea what could be happening here?.
>>>>>>> I have a laptop DELL INSPIRON 3511 and everything works just 
>>>>>>> fine, literally everything. even the iwlwifi0.
>>>>>>>
>>>>>>> But in order to use my full 600mbps, i dont use the wireless but 
>>>>>>> a TP-LINK USB ethernet connected on "ue0"
>>>>>>>
>>>>>>> ugen0.6:  at usbus0, cfg=0 md=HOST 
>>>>>>> spd=HIGH (480Mbps) pwr=ON (200mA)
>>>>>>>
>>>>>>>
>>>>>>> but something really strange is happening .. everytime i open the 
>>>>>>> chromium e do a speedtest (could be speedtest.net or any other) , 
>>>>>>> at the end of the test the eth interface dies .. it changes from 
>>>>>>> full-duplex to half-duplex/no carrier and the only way to get the 
>>>>>>> internet back thru ue0 is by rebooting the whole thing.
>>>>>>> not even a "service netif restart" does anything
>>>>>>>
>>>>>>> if anyone has any ideas why is that , would be appreciated
>>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I think it some new features they use in the USB data protocol 
>>>>>> which we don't support. Check the Linux code.
>>>>>>
>>>>>> Between does:
>>>>>>
>>>>>> usbconfig -d 0.6 reset
>>>>>>
>>>>>> recover the device?
>>>>>>
>>>>>> --HPS
>>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Search for axge on bugzilla:
>>>>>
>>>>> I suspect you are using this chipset:
>>>>>
>>>>> Try:
>>>>>
>>>>> usbconfig show_ifdrv
>>>>>
>>>>> To know for sure.
>>>>>
>>>>> Also see:
>>>>>
>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7Ce7f888b3635f4e898ca308da972fa69b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637988528164303655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zvw7m8lJ%2FHocK%2FXJIDfdPv%2FArCpE5pk9lYz%2BY8WzMCc%3D&reserved=0 
>>>>>
>>>>>
>>>>> --HPS
>>>>>
>>>>
>>>>
>>>> Hi Hans,
>>>>
>>>> actually the driver i use is not agxe (i thought it would be by the 
>>>> time i
>>>> bought the usbcard)
>>>>
>>>> this is the module im using
>>>>
>>>> if_ure.ko
>>>>
>>>> and thank you , yes, reseting the usb entry with your command worked 
>>>> just fine.
>>>> i got the internet back after doing this
>>>>
>>>> usbconfig -d 0.6 reset
>>>>
>>>> do we have a bug here then?
>>>>
>>>> thank you
>>>>
>>>> --tzk
>>>>
>>>
>>> oh, i forgot to mention that the ure driver freezes not during the 
>>> download test but in the middle of the upload, always
>>>
>>> dont know if that helps
>>>
>>> thanks
>>>
>>> --tzk
>>
>> Hi Ivan,
>>
>> Yes, there seems to be problem there. I need to look at the driver. 
>> Maybe it is simply sending too much data, than the device can handle!
>>
>> --HPS
>>
> 
> Hi,
> 
> Try lowering this constant to 8192:
> 
> sys/dev/usb/net/if_urereg.h:#define    URE_TX_BUFSZ        16384
> 
> Then recompile and install if_ure:
> 
> make -C sys/modules/usb/ure KMODDIR=/boot/kernel all install
> 
> --HPS
> 

You can also try other values, like subtracting one.

--HPS

From nobody Fri Sep 16 12:18:39 2022
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 4MTY5P296tz4cf1L
	for ; Fri, 16 Sep 2022 12:18:49 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1anam02olkn2024.outbound.protection.outlook.com [40.92.44.24])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTY5M6nKgz4JkX
	for ; Fri, 16 Sep 2022 12:18:47 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=fEOd+6W+vIsJkQt2qgSyAdfnsBuSgReg35SBf+YMcxPQyMtvvFCdEdxRTv4HcJ+cEku4OMOM4OffiU2t12lpCeic00HcqZxTPeNat273CmYgXbXvUyLk8jtxUNDynJEQXaladQiLvgUCFrENmhGXjL2s/JMuQZ5I2yQkQS1N7nx2wvNSzU5ywvkRwiAmXaLNLZWkeL29qGkqryx8MzIz/Lu46M0wU8w6TEjncJAgOJVZeKLmUBvH6l399FeF9LKHaEuTIitCbJyY5yXQfPKckJXl6TYDkPEtekWiNdklkqAMYONslHnVfkv1FPm07j9gTCQk6wNTd20lBSkBFR2j3A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=fOtfekFfGWWwtabuSIUWbWXSFWhaSw1LxXfFdq/PhUw=;
 b=SrYIFEy1TvULOrGKpj7+UMzpxYBCXPV1S0Mew6TNIfR6Dd/gbZQYBx5q+ePZPVtZ1bKJvdw/sGP5/NND0Sj3piNDitTmurLS+Xnu5H0rFTyYI9FT/LejIrGW1UdLWWEdATGw9rHPkoM+/673J3Ti760ihhDwJAY5Tr3Zz0rujHR/hlJZDiWW3z6HOhtzOPE7oxmiXaEldA3BKSz/nmfF1DKAt9R7jaNs2h7rQgVbGYGGEy1Omllw/7//XdLTr5mtCXot04YWKmIK/CKQ64TvG54d7uja55G8PQosSmSz+eNXFyDJYOA5ISPeX4D3JILtfOCQs6Qf5SJ2PDhrm12FAg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=fOtfekFfGWWwtabuSIUWbWXSFWhaSw1LxXfFdq/PhUw=;
 b=W9AMo/1OPu+GJHNFaF0pDvJvuqgEFf4tAm1BbpGDx/tOeYlE92X+3OlWDPPI/51+caGyoE6ao45l4/Ma8yvI+tSWnCY61mKnzHNH4FpN9KYwqmRzoezzBmIqnVlbOKam399awOG5apZiymxM5JhNzzusUXXshmPjLho3AQtC/afe+MKJKCxIIrtUAv16QWxjQwePjhHzvTzadhi/WfIXEAIoFDCTylhn9t7TOvhzXhnn+euOFWR1Lt8EJo5sB3x36aJqa4RmSL1J2PuLLltmVfz6g+VyQUwal0n5K8B0PvNJC0Z1olP4TscU8wTtpBLU2Bk46tYvL849/CgxCoKIiw==
Received: from CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:f3::5) by
 ROAP284MB0317.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:38::12) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5632.15; Fri, 16 Sep 2022 12:18:44 +0000
Received: from CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM
 ([fe80::4f:e243:b3:f536]) by CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM
 ([fe80::4f:e243:b3:f536%7]) with mapi id 15.20.5632.016; Fri, 16 Sep 2022
 12:18:44 +0000
Date: Fri, 16 Sep 2022 09:18:39 -0300 (-03)
From: Ivan Quitschal 
To: Hans Petter Selasky 
cc: Ivan Quitschal , freebsd-current@freebsd.org
Subject: Re: TP-LINK USB no carrier after speed test
In-Reply-To: <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
Message-ID:
 
References:  <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org> <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org> 
   <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org> <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
Content-Type: multipart/mixed; boundary="3432851520-1025263881-1663330723=:2212"
X-TMN: [1vRuoUit4gBhO6QSvppX+hj9stI1W1kH]
X-ClientProxiedBy: CPYP284CA0070.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:80::21) To CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:f3::5)
X-Microsoft-Original-Message-ID:
 <3ccb2b53-a5eb-c055-5948-55461e87d4d5@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP5P284MB1902:EE_|ROAP284MB0317:EE_
X-MS-Office365-Filtering-Correlation-Id: aed9e420-2230-47e8-f42d-08da97dd990e
X-MS-Exchange-SLBlob-MailProps:
	C/ir7cSdGlvfvB+aWLoH0RMQISXNbg+SXfi5z+k0U0YEkSScSE93iU4XmJkGCNxYOX4QKeonKAgojX6SwmAnmtm/uSD3YhOkP2eiCGw4RfCSBdjk1nndT7mdHT/h8qPD458PY8qMNEVfHGlhPCLP+rNKbDPYMW50P+tB3SaxuG2KA2r+g8FUwz2DIENlGmMOwi2vdThmDwPGDtjYe05se0FKZlLOa0d6j1NMtj2kzwdR38L4CnRAFmTmacItR3zLFn/OgpnVr17oKHnQngM+7WsW2wLrvci3NsTUCT77ZhIUgZnXdooJbGhv+bWT1OwJHudsvC2542PG2CaygfyzNk+RaLAuGVeTlF+NAHKEYUIJ2sYPjR3Ts3gjibcvWR8qIeKqNveHmZpSyI/CncMaQMwfPRDs+ppT1eELvCwADwxBY60vh4GghUVu4ed/yx8pJhmRy5MiJzxbaT9NbqUfJY5TvQUrpQ1RJVnoeK4880J/DGMN0o/HY/Y65mTHuR8e/3burcmLYiMoj4XcVaNA+A2i+Uq+gBzyNmViefkq9SYP2BlBg8qXxcYqbqO9tz/IWIRbyddFTfcJGOu9J6bVLqwsyospAO7kOypCd9dkwFNsJ+sOutlD2ABMtV93pOS6NK7wygl6i7Sl3k3DKEpsxtY2e6LaBuBmoi1eyF+hQiVNLPfQH8v48Ve0i0yvCsQZZjhVdk3wErt9mWgMbww11ANv4m7t00t+P6siKiRDwyLINkJdrkUK76yYB40SyAMS
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	5Kz595cnqz9iDIZ2wUFD8Xjn+ksvMRHU2EvzVgTFLxNdzdxFTSzYA3bFegq3cKT1/P8wwhlBs+BJdchhrXkPoGi2NkTbcCdYsRRe3/UTwRPF0n5Y10vooYJjnbGLmboTM5pPvjAci06tNogZJsSDmX0rJgIyPdC9kCXejUfTrx18jwBImKY7hK7xEu/6SbB2P87++tbhdQxDmkSjLaJgA9gaglwIWpbZL0ZbbY/e+odVTr4sNSoLHl+xsYfajQtyZauF+seyAZCBgkOf95bjc8MhrmFqrKOHXJEcuwpby+4Y+IMb5NBGtOxpy2soZw7XsOudlxzsAbs/VsP7lh3BY5XKVcr3HJaWILkRgEn3NeIIsKV2mzkTK73XvkBvyFTX3xDuAMBBzN69r8BbqbTYPbNC+IYOva2qlknyreUwiiaIt5oepDTWBIgh2zA6Pb8hrtXhAOTHUxM35zaLxK1TmmfhRIH0ztGVjS94z63OLWPL4dAh4o4yAtBiznaPKsI3bmhu/XQS/kYqYcUwqaKTWvtTDg3UlZTLm7DE/O53oTOLDprd7zckA5KCEcTxbuLqO/7TrpHXkBimklxSPhXyj4lXVXvWgsVy3ULUv0aF0lm/LS44dkkSqr/tn70zermJOznF5RPczpAiIEt67wDEWT4vs+m/GGVc2+7LahxGgLYcTf7kmU6H78I2Gv4ygATg
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?QUw5SWEvVWcrclpSWFJUdW9hZ0xMS21ndzlHb3Q0bTZSQWRTbkpBMUVWL0ln?=
 =?utf-8?B?NndUUElZSGNEWHBUOXF5UzhTZjlndm5BT2gyL2RwRUpJZHF1bUNBV2diTFp0?=
 =?utf-8?B?TTFmNVErOFFMdHlNVERSSkdFNGZJZXVQMStKWHZOVENWYnZSTHFJU1FpVXhz?=
 =?utf-8?B?SlcwZnJXTCtXeFVCTnIxeXloSGhUQkVZUnkwOTdLNzhhSjUvcENsaU1kcU9o?=
 =?utf-8?B?K1RnZzFQMkpmU29JN2NMamFNekovOG9RTzlyd01LVGFkb0Z3aFNlZG9LVFNZ?=
 =?utf-8?B?WWlJd2Rjbm5ldExPYk5rS0pnbDluZDJXQ1RFTDlLWHNmNmViR1J1SkFmUm9l?=
 =?utf-8?B?SlF2Skcwd1JRVlY1aVdYSE5PU1UxcE9CTzlTR1o0SU0ybHpsdWxVazBaTHFD?=
 =?utf-8?B?SExMYVU5S1o4dVIyMFZkRVJBU21DSVdUQzIvN0czZG9rL2FjQmJmeHlsaGFW?=
 =?utf-8?B?ci8vOG1OTDVPclZ2SlFERHNzZ3BkMUVsYnVIUzNyZHYvV29VRXhaK0pwYVk2?=
 =?utf-8?B?WlNsemlYaGwrU01uKzc0YVlCQ002ZnpQZ2cyeDBoeUp6bWx0RW1BTE1WOUg3?=
 =?utf-8?B?bjdNMjBrYXpNbVdNSlY1M0t1OEFIM1hMNDBERUtLSnU2bCthYlB2K2N4UGJY?=
 =?utf-8?B?RnZuZ2dvSjZ4aWxGR3h6eEh2SWtQYkVWVFp3QldYY2g3THc3YXJEOWR6eUNp?=
 =?utf-8?B?U2RaRVhXZm9FT3Iyb09zc2hxTVBKQXJ6QjJsYTgyQzUwUkx3RDEreklYOHdI?=
 =?utf-8?B?MkRRV1NWMVJZMS90MDRESFFWQzIrN1BIVUIwbUhaREUzc3FBbm5MTG1pUEdK?=
 =?utf-8?B?WUNXVDVFRjI2UVpveDlGU1JkSmJ0cVJPeVlRSUdkbzJ5ak5WUnNwMW1NUVdQ?=
 =?utf-8?B?SHNJTVZmejN5Nld6L045UkR5MzUzYkxLazZid0QxVERnNitwajl5MFh6N2Er?=
 =?utf-8?B?SGRIaTNaeGU2MHY4cDI5aWovOHlTdmNHOWdtOFpiL1lwZnUyV3MrUGxGSG5C?=
 =?utf-8?B?V2xIYUFuWWhVanEwbTdXd1BZRXpOb1VCTDRYNFgxdTJHOTROTXBzMlpDSnhI?=
 =?utf-8?B?S2ZxS2ZnaUI3dXVXdkMvR0RhTXVIaU1vSHcydHoyZUNvMnJLTHBrclp0bnpH?=
 =?utf-8?B?K2NjbHprUWxvd1RueVZBc1JPRCtqSnFLeWt4VFZHTHJpVXNNVkpRS29BcUdF?=
 =?utf-8?B?NitWdXh5aFpNQ0xUZlVkOFdDeGN5V2d2UWpKbk5NSEpuSjBwRmhEN3Fabys1?=
 =?utf-8?B?c0xXRlpsSHFQK2tPenhMRGY2MUtXRTBsZC9LWXFpaFBjTG1QYWdJWEsyQ05Y?=
 =?utf-8?B?N29nZS9uRVhOaEdFQ0w0a1RuZkIzalZXQTFKWktXL1g0cHdnYk5Hd241dyt3?=
 =?utf-8?B?SXBuc3owdU5xRGxwS0M4Q0t1NHpwejhSQjZTdnYrS1Jia3IvM1laMmNVRHg2?=
 =?utf-8?B?djZlZlE0Z3ZhcStIU2hXWFV0QkxLbUdVVGZPTXk4TUMyc3ZkZEd2VkNZRDFD?=
 =?utf-8?B?d2hFeCtlR3E0T3BJczNXY1g5bHFtcTR5cU1VbmwxazVBQmNHTUhxMEZ5cWU4?=
 =?utf-8?B?VkRRN2hsRC9DcE81cVhCYXFWS2dCVEw4UHJLQmxrSWVhWEd5b2RWQzNudmNx?=
 =?utf-8?B?UzNrZEUzK3ZqYzVnTU9MdW9vZFZHK2UzaHhvYzhKSXluT1FNeCtFcktwdTFs?=
 =?utf-8?B?Q1Z1dnFSRnpSZTZhUnJkZDR3YktUNWFNRmNRWFIyVzNVcVNmVlJQQVh3PT0=?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: aed9e420-2230-47e8-f42d-08da97dd990e
X-MS-Exchange-CrossTenant-AuthSource: CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2022 12:18:44.3759
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB0317
X-Rspamd-Queue-Id: 4MTY5M6nKgz4JkX
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b="W9AMo/1O";
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.44.24 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-3.60 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	CTYPE_MIXED_BOGUS(1.00)[];
	NEURAL_HAM_SHORT(-0.98)[-0.979];
	NEURAL_HAM_LONG(-0.96)[-0.961];
	NEURAL_HAM_MEDIUM(-0.66)[-0.660];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	MIME_TRACE(0.00)[0:+,1:+];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.44.24:from];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[hotmail.com,freebsd.org];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--3432851520-1025263881-1663330723=:2212
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT



On Fri, 16 Sep 2022, Hans Petter Selasky wrote:

> On 9/16/22 08:34, Hans Petter Selasky wrote:
>> On 9/16/22 08:20, Hans Petter Selasky wrote:
>>> On 9/15/22 17:36, Ivan Quitschal wrote:
>>>> 
>>>> 
>>>> On Thu, 15 Sep 2022, Ivan Quitschal wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, 15 Sep 2022, Hans Petter Selasky wrote:
>>>>> 
>>>>>> On 9/15/22 17:18, Hans Petter Selasky wrote:
>>>>>>> On 9/15/22 17:16, Ivan Quitschal wrote:
>>>>>>>> 
>>>>>>>> Hi All
>>>>>>>> 
>>>>>>>> Does anybody have any idea what could be happening here?.
>>>>>>>> I have a laptop DELL INSPIRON 3511 and everything works just fine, 
>>>>>>>> literally everything. even the iwlwifi0.
>>>>>>>> 
>>>>>>>> But in order to use my full 600mbps, i dont use the wireless but a 
>>>>>>>> TP-LINK USB ethernet connected on "ue0"
>>>>>>>> 
>>>>>>>> ugen0.6:  at usbus0, cfg=0 md=HOST 
>>>>>>>> spd=HIGH (480Mbps) pwr=ON (200mA)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> but something really strange is happening .. everytime i open the 
>>>>>>>> chromium e do a speedtest (could be speedtest.net or any other) , at 
>>>>>>>> the end of the test the eth interface dies .. it changes from 
>>>>>>>> full-duplex to half-duplex/no carrier and the only way to get the 
>>>>>>>> internet back thru ue0 is by rebooting the whole thing.
>>>>>>>> not even a "service netif restart" does anything
>>>>>>>> 
>>>>>>>> if anyone has any ideas why is that , would be appreciated
>>>>>>>> 
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I think it some new features they use in the USB data protocol which 
>>>>>>> we don't support. Check the Linux code.
>>>>>>> 
>>>>>>> Between does:
>>>>>>> 
>>>>>>> usbconfig -d 0.6 reset
>>>>>>> 
>>>>>>> recover the device?
>>>>>>> 
>>>>>>> --HPS
>>>>>>> 
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Search for axge on bugzilla:
>>>>>> 
>>>>>> I suspect you are using this chipset:
>>>>>> 
>>>>>> Try:
>>>>>> 
>>>>>> usbconfig show_ifdrv
>>>>>> 
>>>>>> To know for sure.
>>>>>> 
>>>>>> Also see:
>>>>>> 
>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7C266a987745fc4f2d0b9008da97ae1d13%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637989071335334015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zKuhXtYc%2FG3qpRtU%2FZNr5uEeQARsGudcWIlC1bVOsLE%3D&reserved=0 
>>>>>> 
>>>>>> --HPS
>>>>>> 
>>>>> 
>>>>> 
>>>>> Hi Hans,
>>>>> 
>>>>> actually the driver i use is not agxe (i thought it would be by the time 
>>>>> i
>>>>> bought the usbcard)
>>>>> 
>>>>> this is the module im using
>>>>> 
>>>>> if_ure.ko
>>>>> 
>>>>> and thank you , yes, reseting the usb entry with your command worked 
>>>>> just fine.
>>>>> i got the internet back after doing this
>>>>> 
>>>>> usbconfig -d 0.6 reset
>>>>> 
>>>>> do we have a bug here then?
>>>>> 
>>>>> thank you
>>>>> 
>>>>> --tzk
>>>>> 
>>>> 
>>>> oh, i forgot to mention that the ure driver freezes not during the 
>>>> download test but in the middle of the upload, always
>>>> 
>>>> dont know if that helps
>>>> 
>>>> thanks
>>>> 
>>>> --tzk
>>> 
>>> Hi Ivan,
>>> 
>>> Yes, there seems to be problem there. I need to look at the driver. Maybe 
>>> it is simply sending too much data, than the device can handle!
>>> 
>>> --HPS
>>> 
>> 
>> Hi,
>> 
>> Try lowering this constant to 8192:
>> 
>> sys/dev/usb/net/if_urereg.h:#define    URE_TX_BUFSZ        16384
>> 
>> Then recompile and install if_ure:
>> 
>> make -C sys/modules/usb/ure KMODDIR=/boot/kernel all install
>> 
>> --HPS
>> 
>
> You can also try other values, like subtracting one.
>
> --HPS
>


hi Hans,

it worked but with a cost.

i tried 8192 and it works 5 tests (5 speed tests in a row). freezes on the 6th.

then i tried 4096 no success

then i tried bufsize 2048 and its working now, i did several tests in a row and 
the 
internet keeps working just fine. but i noticed that the speed also dropped.

with the same server , testing on windows, it goes like:
600 download / 300 upload

and on freebsd with 2048 bufsiz it goes like:
300 download / 150 upload


so it worked with a cost like i said, i had to give up half of my bandwitch

what do you think ?

and thank you again

--tzk

--3432851520-1025263881-1663330723=:2212--

From nobody Fri Sep 16 13:40:01 2022
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 4MTZvH0KW1z4csgs
	for ; Fri, 16 Sep 2022 13:40:11 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTZvF3WSpz3KDw
	for ; Fri, 16 Sep 2022 13:40:09 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.3.0.9] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id D73F6260734;
	Fri, 16 Sep 2022 15:40:05 +0200 (CEST)
Message-ID: <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
Date: Fri, 16 Sep 2022 15:40:01 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: TP-LINK USB no carrier after speed test
Content-Language: en-US
To: Ivan Quitschal 
Cc: freebsd-current@freebsd.org
References: 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
 <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4MTZvF3WSpz3KDw
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.995];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[hotmail.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/16/22 14:18, Ivan Quitschal wrote:
> 
> 
> On Fri, 16 Sep 2022, Hans Petter Selasky wrote:
> 
>> On 9/16/22 08:34, Hans Petter Selasky wrote:
>>> On 9/16/22 08:20, Hans Petter Selasky wrote:
>>>> On 9/15/22 17:36, Ivan Quitschal wrote:
>>>>>
>>>>>
>>>>> On Thu, 15 Sep 2022, Ivan Quitschal wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 15 Sep 2022, Hans Petter Selasky wrote:
>>>>>>
>>>>>>> On 9/15/22 17:18, Hans Petter Selasky wrote:
>>>>>>>> On 9/15/22 17:16, Ivan Quitschal wrote:
>>>>>>>>>
>>>>>>>>> Hi All
>>>>>>>>>
>>>>>>>>> Does anybody have any idea what could be happening here?.
>>>>>>>>> I have a laptop DELL INSPIRON 3511 and everything works just 
>>>>>>>>> fine, literally everything. even the iwlwifi0.
>>>>>>>>>
>>>>>>>>> But in order to use my full 600mbps, i dont use the wireless 
>>>>>>>>> but a TP-LINK USB ethernet connected on "ue0"
>>>>>>>>>
>>>>>>>>> ugen0.6:  at usbus0, cfg=0 md=HOST 
>>>>>>>>> spd=HIGH (480Mbps) pwr=ON (200mA)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> but something really strange is happening .. everytime i open 
>>>>>>>>> the chromium e do a speedtest (could be speedtest.net or any 
>>>>>>>>> other) , at the end of the test the eth interface dies .. it 
>>>>>>>>> changes from full-duplex to half-duplex/no carrier and the only 
>>>>>>>>> way to get the internet back thru ue0 is by rebooting the whole 
>>>>>>>>> thing.
>>>>>>>>> not even a "service netif restart" does anything
>>>>>>>>>
>>>>>>>>> if anyone has any ideas why is that , would be appreciated
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I think it some new features they use in the USB data protocol 
>>>>>>>> which we don't support. Check the Linux code.
>>>>>>>>
>>>>>>>> Between does:
>>>>>>>>
>>>>>>>> usbconfig -d 0.6 reset
>>>>>>>>
>>>>>>>> recover the device?
>>>>>>>>
>>>>>>>> --HPS
>>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Search for axge on bugzilla:
>>>>>>>
>>>>>>> I suspect you are using this chipset:
>>>>>>>
>>>>>>> Try:
>>>>>>>
>>>>>>> usbconfig show_ifdrv
>>>>>>>
>>>>>>> To know for sure.
>>>>>>>
>>>>>>> Also see:
>>>>>>>
>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&data=05%7C01%7C%7C266a987745fc4f2d0b9008da97ae1d13%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637989071335334015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zKuhXtYc%2FG3qpRtU%2FZNr5uEeQARsGudcWIlC1bVOsLE%3D&reserved=0 
>>>>>>>
>>>>>>> --HPS
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Hans,
>>>>>>
>>>>>> actually the driver i use is not agxe (i thought it would be by 
>>>>>> the time i
>>>>>> bought the usbcard)
>>>>>>
>>>>>> this is the module im using
>>>>>>
>>>>>> if_ure.ko
>>>>>>
>>>>>> and thank you , yes, reseting the usb entry with your command 
>>>>>> worked just fine.
>>>>>> i got the internet back after doing this
>>>>>>
>>>>>> usbconfig -d 0.6 reset
>>>>>>
>>>>>> do we have a bug here then?
>>>>>>
>>>>>> thank you
>>>>>>
>>>>>> --tzk
>>>>>>
>>>>>
>>>>> oh, i forgot to mention that the ure driver freezes not during the 
>>>>> download test but in the middle of the upload, always
>>>>>
>>>>> dont know if that helps
>>>>>
>>>>> thanks
>>>>>
>>>>> --tzk
>>>>
>>>> Hi Ivan,
>>>>
>>>> Yes, there seems to be problem there. I need to look at the driver. 
>>>> Maybe it is simply sending too much data, than the device can handle!
>>>>
>>>> --HPS
>>>>
>>>
>>> Hi,
>>>
>>> Try lowering this constant to 8192:
>>>
>>> sys/dev/usb/net/if_urereg.h:#define    URE_TX_BUFSZ        16384
>>>
>>> Then recompile and install if_ure:
>>>
>>> make -C sys/modules/usb/ure KMODDIR=/boot/kernel all install
>>>
>>> --HPS
>>>
>>
>> You can also try other values, like subtracting one.
>>
>> --HPS
>>
> 
> 
> hi Hans,
> 
> it worked but with a cost.
> 
> i tried 8192 and it works 5 tests (5 speed tests in a row). freezes on 
> the 6th.
> 
> then i tried 4096 no success
> 
> then i tried bufsize 2048 and its working now, i did several tests in a 
> row and the internet keeps working just fine. but i noticed that the 
> speed also dropped.
> 
> with the same server , testing on windows, it goes like:
> 600 download / 300 upload
> 
> and on freebsd with 2048 bufsiz it goes like:
> 300 download / 150 upload
> 
> 
> so it worked with a cost like i said, i had to give up half of my bandwitch
> 
> what do you think ?
> 
> and thank you again
> 
> --tzk

Hi,

Can you try this instead:

usbconfig -d X.Y set_config 1

X.Y are the numbers after ugenX.Y

Then it will use a different driver.

--HPS

From nobody Fri Sep 16 13:41:21 2022
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 4MTZwk0kH8z4btX1
	for ; Fri, 16 Sep 2022 13:41:26 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTZwj1bjKz3LJV
	for ; Fri, 16 Sep 2022 13:41:25 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.3.0.9] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id C7FA7260734;
	Fri, 16 Sep 2022 15:41:23 +0200 (CEST)
Message-ID: <95e6b844-c832-ee32-1238-e30d93cee9b4@selasky.org>
Date: Fri, 16 Sep 2022 15:41:21 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: TP-LINK USB no carrier after speed test
Content-Language: en-US
To: Ivan Quitschal 
Cc: freebsd-current@freebsd.org
References: 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
 <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MTZwj1bjKz3LJV
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[hotmail.com];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

I compared the Linux code and the FreeBSD code, and the Linux code has 
firmware upload support for this device. Maybe implementing that will 
fix some issues. Will come back to this after EuroBSDcon :-)

--HPS

From nobody Fri Sep 16 13:42:31 2022
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 4MTZyC0F4Sz4bv07
	for ; Fri, 16 Sep 2022 13:42:43 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTZyB6lDvz3MTQ
	for ; Fri, 16 Sep 2022 13:42:42 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663335762;
	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=ZSTcaczpe0dMgsuCUPdGKe289Fo3Vp3/eZkOiEz0naw=;
	b=hUpY7I0lpDoKVkKDjqvFlZwu60NTlgwdJqdX3mvn5FLqFwPFKQ5DTC1LSH58JzXb5TkEi2
	Umnw47IzX5PZIoChZduw4iIchQu/Xref9oL0giaJ9aCMa98IN7sNg4j2ElcANzqLUKimK1
	0hpYybhCc4vSJ+utMwoN3/bh5gcHhkuRdOWJdRl3J/e5nAOWRE1NjEC+j5iEwbsfwzWvbs
	3/cWIWfkSjMkjWM1OLvsSmSl8xVKyOJyPi+zH7hHR/F5Hw4tbvAjyycanLqFxxMXXjp3//
	wHx66JS9RRx8M3dmK/n/P9D1f18zF542qT/1xbOoWd4FheKVZ3NNRGdQop++zg==
Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MTZyB5mr2zqr0
	for ; Fri, 16 Sep 2022 13:42:42 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f174.google.com with SMTP id g85so5006878vkf.10
        for ; Fri, 16 Sep 2022 06:42:42 -0700 (PDT)
X-Gm-Message-State: ACrzQf1jI2fztrwd4pIDVfA4evoqH0YZVYfZJjqzb/q8P5g2PH3ot7G1
	I67sKwlY3QhE0HcKpovq/1EdhloVadJDr7jU5VU=
X-Google-Smtp-Source: AMsMyM7UbueOdmuratUsyk/Yt4OtaH7SaSKnrRSrG+vAwHKbD2JHd6GShkyXvt0XGVhfwLKgVrXisJp+WX/o4exGFJY=
X-Received: by 2002:a1f:24d5:0:b0:3a2:f067:66f6 with SMTP id
 k204-20020a1f24d5000000b003a2f06766f6mr2107975vkk.13.1663335762162; Fri, 16
 Sep 2022 06:42:42 -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: Nuno Teixeira 
Date: Fri, 16 Sep 2022 14:42:31 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: My first commit to src!
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000003efab405e8cb894d"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663335762;
	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=ZSTcaczpe0dMgsuCUPdGKe289Fo3Vp3/eZkOiEz0naw=;
	b=wXLCPpLINRIZ/2Z6/BBF4i1aEXPv1tFtue4tl9q/E5Id2Z/RwVDgN5jdi0f2Hs7m5en3X5
	Rve9Zu/RzDmUWeLi6tAUyob/dL0okG2Z9UU0uyQK5ZwjD0HN40SzqiWfIm0N4nJZa4sSta
	qpmsrrOr3XQWGBUI156LtvkxpcaCh2ETt/bRhGDN2ipMCZy1J4R7wc3Zkh5SRwof9zcsKo
	6/sx+cEq3r1uiS5B7ZvzC/Lxus9cQUnG74ES2GC4qU9jpz3U2qoYhPW0s8uPQQM7FOydQ1
	5rx/UUp30JW+dg7OsfdCmIshmpix4uJz5ZISV/XHBHDqP0gRCXIvifysTlY5ng==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663335762; a=rsa-sha256; cv=none;
	b=EDCSx7na046dTe3YH6SxS/VsQZqmXd5ELyl17TaEhCgvAaVvy7VUbQkUxT9VGEird7ZlwY
	DpZpAXbfr6nKcJ/xBRiElhIwA7KESSwMQRCwRMlNpycLr5j8UE7ugJJM9xwTw/B3RTQF5V
	YmJT7pcg3nOoAFB1QwYyfnMxJx1RBaUISHD4MyROi4+fxZBIXqVSucdGP7wFk9I07tCyb1
	p0KBzj8sXsqtBReihQyKUen1IGiHIpJu1N7SPQZ/VWa0+DJDTh9HcVK97v4/7oQL2mJgxA
	bbd9uSOlzYqEkjCfYNCZEjeHq/ZGWBr80Mkna/1geCAWKxdBsETnA6oi1ZizQQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000003efab405e8cb894d
Content-Type: text/plain; charset="UTF-8"

Hello to all!

Just to let anyone knows that I made my first commit to src:

https://cgit.freebsd.org/src/commit/?id=b44869cba1b391931b831135a9cefcc6ca635103

It took me almost 2 years until I find right device hints, nids and stuff
to get my speakers to work.

It was a very special moment when I commit it.

Thanks to all and specially thanks to @emaste,

-- 
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000003efab405e8cb894d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello to all!

Just to let an=
yone knows that I made my first commit to src:


It took me almost 2 y=
ears until I find right device hints, nids and stuff to get my speakers to =
work.

It was a very special moment when I commit i=
t.

Thanks to all and specially thanks to @emaste,<=
br>

-- 
Nuno Teixeira
FreeBSD Committer (ports)
=



--0000000000003efab405e8cb894d--

From nobody Fri Sep 16 14:31:16 2022
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 4MTc2K1CpWz4c4RK
	for ; Fri, 16 Sep 2022 14:31:21 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2069.outbound.protection.outlook.com [40.92.97.69])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTc2H75W3z3WQp
	for ; Fri, 16 Sep 2022 14:31:19 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=MMevikk8jFLSsF6A2VDslP3UUh2MGRkF5Pq09GxuE15eO5HaNkZXNM4gc0HldZFyfcFTIiyzfkvezg3T7X452pYswLhaUyk5wuXOSub27FCAYa56Qe4gJAM6j7JAs0txF5RoLNMbnw4okvlbo6Chg8cOSGx1cz6CcUiLMdzsR6kZd+HTzCav5DTg48YickUdC0sERBNISaaVZr06mMouPjSo4egEs9xIUDQYY/X8igB1DfYtzWXfAA+K9QOGKjuN70+0viG4jnwwcz121mxw1ZCyM08LQ+gEKmy+smvO978j3emB+SuE9XHI5DdY//v8rTPWU2EFwwowL4SMHG1ynA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=CWKsE5m/W5pzwEs2+MOXr95rDDiujbTCBc4BccPqzHQ=;
 b=Ns+AhXQCUKNGwCku3Rt3nDkexm286qrxK4DRDuqOB5YD6uzVw9Dh6Dh5dPI8/CWYcxZJXAyCfJ2iv0o3sbj9j/rYjEIzicJb9x+k4pkAyozbm8xADg+VQYkzSaPBIKV8kFQs0g8TVcEj+iNGEgMAW+ufGaJJu4wACuIZXMmbTrQR9AmmOG5Bkz8shsQyPrcVpTxtxP0D/iGtpMoX0hyQgA3rp23cwdwingYNhCa9EidJb7DFo+VkkGw8e3h1ZZDTxBq1tXMtxSFYW6IhXYKriQ8PwKV2qcb4KTW4mD7iZoragcm0Zm+0QTfEX4xf/QnMu8PC03Qfg9CfYsRKzCQrlQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=CWKsE5m/W5pzwEs2+MOXr95rDDiujbTCBc4BccPqzHQ=;
 b=JKnONeYnH64Ac+OdQevU6zbr/AoQp8ZK0pIdqB4bFk8+9RK4NyWzxf9gsfP/C5RyM/WTE35ykxHIMFyjaaPoe1OibUUimT3VpmTXeStt/dPLjM2/f5DqAhDV7mX+4kqSu48V3rC0YC6+mYFd2g03sZP+LNt8wncLcocpr4fX75HqqRNn1bEHZ7X00nS/NPIK1mkEmaiPr3ZwLewO9sQeIHoyKMWaIAEQQ8UmWA1sHtfWxMfr5tNLlhlrIHlQ4bD3Pzdnh3/Xj44aFOs6grbDLwZhBWt+zUtO+wa+wgH1pJrofK7NE9F83nBoNetg0gg/0OInISPgpV7gKNto6DlA1g==
Received: from CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:f3::5) by
 CPYP284MB0164.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:76::9) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5612.19; Fri, 16 Sep 2022 14:31:16 +0000
Received: from CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM
 ([fe80::4f:e243:b3:f536]) by CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM
 ([fe80::4f:e243:b3:f536%7]) with mapi id 15.20.5632.016; Fri, 16 Sep 2022
 14:31:16 +0000
From: Ivan Quitschal 
To: Hans Petter Selasky 
CC: "freebsd-current@freebsd.org" 
Subject: RES: TP-LINK USB no carrier after speed test
Thread-Topic: TP-LINK USB no carrier after speed test
Thread-Index:
 AQHYyRYh90zfGba+7EWJS9V+b+FDta3gmrWAgAABUgCAAALNAIAAAPyAgAD2/ICAAAOngIAAAU8AgABe+YCAABa8gIAADhYQ
Date: Fri, 16 Sep 2022 14:31:16 +0000
Message-ID:
 
References:
 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
 <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
In-Reply-To: <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [Z8P7yPYxrzpGzwjC6RYvvyv7aU0uDQoJaRGqmMEwRLdnAO9mUs1PaD4sNgLmRS8l]
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CP5P284MB1902:EE_|CPYP284MB0164:EE_
x-ms-office365-filtering-correlation-id: a2e62400-6d51-4cad-22cb-08da97f01d1a
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 OBp5SSf1rXt+/dNCBENQQo1DrHSf30p17SmbapwU+CJat7HV3C0husI4mGNokRNx+GIDbnTlDm6aNBiF97DrkwjYPoisREU04dcHl8f2gLt+RcsyQUMECVE/lVfABWSfLyNfTx7lMbzg9Q8GymSau2KPl0aHATwlgwPdlt+G8HbfM6DY58lUqJsv7fXe56Dn1XD74AeO39jj+/VBGpMRy3hJy18eDk+pn449CaSQ3MbCz934zy81ti9D1GT3BDCWIrrVJBJDVlRmp10ZpoYd32OpqroGwV/9NFL5QJv5DfnoOhxRCAlXl+VJV/hSL6t1ukeBDCVYCA3GK/ix8g3NZshs8WixEJ9cXHWJINH4HI9QujwYfeRgugFfWO4JCU09G+E643AW2bZ8o5pt4oQl5P9o3G9aJ+cvgksBf5a1aEvorvv9zZh5D68AFtYN6HgvUeRKZvqADt+0tVPIexsyTww6CgN/C29LeC/Ca3xqQbGZDRr6ucZbspqRmk4w5WF/dA8NoDBxoz30nJx0uoBLzXQ+4IAazARF86FVACuul4O3pVe0iKNlkJP2HSO/8nndZ4tpiqOuGii07+fRD6Bx6ndK/cxs87FuvlarRkGuz6Y4J5U+5kCjUJPfalRXMAfV
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?FfCFlYYQ3tdVNMjhVp74Ec8IU+VElGwvVKE2R2FTk+oLcGHUlJL40UEagQ?=
 =?iso-8859-1?Q?iennRoh+lULE+290Q2rdCayPfpB85BAnCdio3GiOijRRSCsXXPx3P9nLTq?=
 =?iso-8859-1?Q?8azxwp4IMoamrtupZHlqFIeEbUG4vspKG2ssgwoAEQXq+dx+EILnJiCt15?=
 =?iso-8859-1?Q?cAIYXbVIgPQvaTxOqytprSmHz3jyO9WNfjCcx40weWgR+AfkMLaDv7fGM1?=
 =?iso-8859-1?Q?xn34Kybd74buO4Eqj1ws1aACRKoyEil0HqmvbzFl9gpBrwY2VOi6EHcqBM?=
 =?iso-8859-1?Q?/WxEu56ZHaiA29EGIzh6uDIHRppz3QzM4mDMswDJPAEzpu8BNW6gChQUem?=
 =?iso-8859-1?Q?TXPOiIrHHImDsRMfaSRwzglwBFOt8U49ywd/J4oZY9CWw4k+oMwzGf2UX7?=
 =?iso-8859-1?Q?DINSEmB0TZ/AYp7au/D6xpeEroCenhGIIOemvF3KPWRKagBKX+FC4kupfq?=
 =?iso-8859-1?Q?PGo4paOGpS/hcEwcF/+/9HEeBHg76wc+XqZXviI50iAqmZ4DwYD3YjqncQ?=
 =?iso-8859-1?Q?MTWGjufZApt/JnX8dWwhqTLtBNMUkvh9OzDYMyOIPhAwCKcWmgh6caWcvl?=
 =?iso-8859-1?Q?DwLO1dvlTfFB2nwCNJrgOXSwGSVc4srWO0kf9y5FXxOMaI8geMscLLPOzO?=
 =?iso-8859-1?Q?wTH4W3Be7goxNinNmFC8HrgezT1sEsjBS12VRMtqh0O1SrfBXw15cdfemG?=
 =?iso-8859-1?Q?MO8X7EHm8KUs7bDOIb3KLoX+Mq9famrX93iwZMytvZDPf+cI5lMmPgpm6X?=
 =?iso-8859-1?Q?3K8rS4+pLTxSxNXqG4+P893pv4nqD9b6quL+kZDCJusEuvA61RDs62NoCH?=
 =?iso-8859-1?Q?Mfl4CuAezClbuBND8TUwwT1jbOJ2DdjfbGBDjLDIuzRWVGUe24eCyGQljE?=
 =?iso-8859-1?Q?XfJ+eg1C1CSrlDH4kxSxycxpRQi2H80J879/UgMaLlQ51cjOUrJZhdI+N1?=
 =?iso-8859-1?Q?xJaUUQ9di58TZ5ZsBA5szBwudrZox7u3ZerfpYdu5rbzGZ5vuoAv8Xehxm?=
 =?iso-8859-1?Q?F39yRJGAsMDpqJJhqvHEM8BeBt3pX/nQ6/VbjQ5xY+km+amik2kpDUTtvl?=
 =?iso-8859-1?Q?WrRoPaSqmKNVP6OuPdM4WHKRMoXooUcNEerum5ae69gvN83pp0wOFnsFjp?=
 =?iso-8859-1?Q?/+V61OInrcHSCVnonx9XupIvY0siyq9QUw/Uu1dOejR3FnMp9hNlsuAUoS?=
 =?iso-8859-1?Q?IbMYJlvcjlw2gTCEAXtyR4UaYH4feSZvw7ML8r3C9OJCEe6j1ICnZAoD7x?=
 =?iso-8859-1?Q?P7wYi0EFJ0/zrOqLCDRbZ7tAEIE9ubEFBzYGaLo8P7mcbr6t7JQjzmbt/m?=
 =?iso-8859-1?Q?qVTref5Y5vPHB7jiMb80aEQgqM2PQu8H7396ubhBeQgKvamOoQSO+6Ci+N?=
 =?iso-8859-1?Q?O9JniiS90Z?=
Content-Type: text/plain; charset="iso-8859-1"
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
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: a2e62400-6d51-4cad-22cb-08da97f01d1a
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2022 14:31:16.1364
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPYP284MB0164
X-Rspamd-Queue-Id: 4MTc2H75W3z3WQp
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=JKnONeYn;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.69 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.90 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.98)[-0.981];
	NEURAL_HAM_LONG(-0.92)[-0.921];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.69:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[hotmail.com];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



> -----Mensagem original-----
> De: Hans Petter Selasky 
> Enviada em: sexta-feira, 16 de setembro de 2022 10:40
> Para: Ivan Quitschal 
> Cc: freebsd-current@freebsd.org
> Assunto: Re: TP-LINK USB no carrier after speed test
>=20
> On 9/16/22 14:18, Ivan Quitschal wrote:
> >
> >
> > On Fri, 16 Sep 2022, Hans Petter Selasky wrote:
> >
> >> On 9/16/22 08:34, Hans Petter Selasky wrote:
> >>> On 9/16/22 08:20, Hans Petter Selasky wrote:
> >>>> On 9/15/22 17:36, Ivan Quitschal wrote:
> >>>>>
> >>>>>
> >>>>> On Thu, 15 Sep 2022, Ivan Quitschal wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, 15 Sep 2022, Hans Petter Selasky wrote:
> >>>>>>
> >>>>>>> On 9/15/22 17:18, Hans Petter Selasky wrote:
> >>>>>>>> On 9/15/22 17:16, Ivan Quitschal wrote:
> >>>>>>>>>
> >>>>>>>>> Hi All
> >>>>>>>>>
> >>>>>>>>> Does anybody have any idea what could be happening here?.
> >>>>>>>>> I have a laptop DELL INSPIRON 3511 and everything works just
> >>>>>>>>> fine, literally everything. even the iwlwifi0.
> >>>>>>>>>
> >>>>>>>>> But in order to use my full 600mbps, i dont use the wireless
> >>>>>>>>> but a TP-LINK USB ethernet connected on "ue0"
> >>>>>>>>>
> >>>>>>>>> ugen0.6:  at usbus0, cfg=3D0
> >>>>>>>>> md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (200mA)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> but something really strange is happening .. everytime i open
> >>>>>>>>> the chromium e do a speedtest (could be speedtest.net or any
> >>>>>>>>> other) , at the end of the test the eth interface dies .. it
> >>>>>>>>> changes from full-duplex to half-duplex/no carrier and the
> >>>>>>>>> only way to get the internet back thru ue0 is by rebooting the
> >>>>>>>>> whole thing.
> >>>>>>>>> not even a "service netif restart" does anything
> >>>>>>>>>
> >>>>>>>>> if anyone has any ideas why is that , would be appreciated
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I think it some new features they use in the USB data protocol
> >>>>>>>> which we don't support. Check the Linux code.
> >>>>>>>>
> >>>>>>>> Between does:
> >>>>>>>>
> >>>>>>>> usbconfig -d 0.6 reset
> >>>>>>>>
> >>>>>>>> recover the device?
> >>>>>>>>
> >>>>>>>> --HPS
> >>>>>>>>
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Search for axge on bugzilla:
> >>>>>>>
> >>>>>>> I suspect you are using this chipset:
> >>>>>>>
> >>>>>>> Try:
> >>>>>>>
> >>>>>>> usbconfig show_ifdrv
> >>>>>>>
> >>>>>>> To know for sure.
> >>>>>>>
> >>>>>>> Also see:
> >>>>>>>
> >>>>>>> https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F=
%
> >>>>>>>
> 2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&d
> >>>>>>>
> ata=3D05%7C01%7C%7C7d0b875611fa4c22aa6808da97e8f75a%7C84df9e7fe9f6
> >>>>>>>
> 40afb435aaaaaaaaaaaa%7C1%7C0%7C637989324107373931%7CUnknown%7C
> TW
> >>>>>>>
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> >>>>>>>
> JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3Do%2B12TNKJ4bcBBj1b4r4TT
> 1f
> >>>>>>> xyEalCMDMjOepy3MZm5c%3D&reserved=3D0
> >>>>>>>
> >>>>>>> --HPS
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Hi Hans,
> >>>>>>
> >>>>>> actually the driver i use is not agxe (i thought it would be by
> >>>>>> the time i bought the usbcard)
> >>>>>>
> >>>>>> this is the module im using
> >>>>>>
> >>>>>> if_ure.ko
> >>>>>>
> >>>>>> and thank you , yes, reseting the usb entry with your command
> >>>>>> worked just fine.
> >>>>>> i got the internet back after doing this
> >>>>>>
> >>>>>> usbconfig -d 0.6 reset
> >>>>>>
> >>>>>> do we have a bug here then?
> >>>>>>
> >>>>>> thank you
> >>>>>>
> >>>>>> --tzk
> >>>>>>
> >>>>>
> >>>>> oh, i forgot to mention that the ure driver freezes not during the
> >>>>> download test but in the middle of the upload, always
> >>>>>
> >>>>> dont know if that helps
> >>>>>
> >>>>> thanks
> >>>>>
> >>>>> --tzk
> >>>>
> >>>> Hi Ivan,
> >>>>
> >>>> Yes, there seems to be problem there. I need to look at the driver.
> >>>> Maybe it is simply sending too much data, than the device can handle=
!
> >>>>
> >>>> --HPS
> >>>>
> >>>
> >>> Hi,
> >>>
> >>> Try lowering this constant to 8192:
> >>>
> >>> sys/dev/usb/net/if_urereg.h:#define=A0=A0=A0 URE_TX_BUFSZ=A0=A0=A0=A0=
=A0=A0=A0 16384
> >>>
> >>> Then recompile and install if_ure:
> >>>
> >>> make -C sys/modules/usb/ure KMODDIR=3D/boot/kernel all install
> >>>
> >>> --HPS
> >>>
> >>
> >> You can also try other values, like subtracting one.
> >>
> >> --HPS
> >>
> >
> >
> > hi Hans,
> >
> > it worked but with a cost.
> >
> > i tried 8192 and it works 5 tests (5 speed tests in a row). freezes on
> > the 6th.
> >
> > then i tried 4096 no success
> >
> > then i tried bufsize 2048 and its working now, i did several tests in
> > a row and the internet keeps working just fine. but i noticed that the
> > speed also dropped.
> >
> > with the same server , testing on windows, it goes like:
> > 600 download / 300 upload
> >
> > and on freebsd with 2048 bufsiz it goes like:
> > 300 download / 150 upload
> >
> >
> > so it worked with a cost like i said, i had to give up half of my
> > bandwitch
> >
> > what do you think ?
> >
> > and thank you again
> >
> > --tzk
>=20
> Hi,
>=20
> Can you try this instead:
>=20
> usbconfig -d X.Y set_config 1
>=20
> X.Y are the numbers after ugenX.Y
>=20
> Then it will use a different driver.
>=20
> --HPS

Hi Hans,=20

After the usbconfig -d X.Y set_config 1, the interface doesn't work anymore=
, how can I undo this?

Thanks

Ivan

From nobody Fri Sep 16 14:36:26 2022
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 4MTc8J6Qw1z4c57L
	for ; Fri, 16 Sep 2022 14:36:32 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4MTc8H0Ncrz3XcY
	for ; Fri, 16 Sep 2022 14:36:31 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.3.0.9] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 2FEBB2600DF;
	Fri, 16 Sep 2022 16:36:29 +0200 (CEST)
Message-ID: <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
Date: Fri, 16 Sep 2022 16:36:26 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: RES: TP-LINK USB no carrier after speed test
Content-Language: en-US
To: Ivan Quitschal 
Cc: "freebsd-current@freebsd.org" 
References: 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
 <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4MTc8H0Ncrz3XcY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.995];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	FREEMAIL_TO(0.00)[hotmail.com];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/16/22 16:31, Ivan Quitschal wrote:
> 
> 
>> -----Mensagem original-----
>> De: Hans Petter Selasky 
>> Enviada em: sexta-feira, 16 de setembro de 2022 10:40
>> Para: Ivan Quitschal 
>> Cc: freebsd-current@freebsd.org
>> Assunto: Re: TP-LINK USB no carrier after speed test
>>
>> On 9/16/22 14:18, Ivan Quitschal wrote:
>>>
>>>
>>> On Fri, 16 Sep 2022, Hans Petter Selasky wrote:
>>>
>>>> On 9/16/22 08:34, Hans Petter Selasky wrote:
>>>>> On 9/16/22 08:20, Hans Petter Selasky wrote:
>>>>>> On 9/15/22 17:36, Ivan Quitschal wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 15 Sep 2022, Ivan Quitschal wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 15 Sep 2022, Hans Petter Selasky wrote:
>>>>>>>>
>>>>>>>>> On 9/15/22 17:18, Hans Petter Selasky wrote:
>>>>>>>>>> On 9/15/22 17:16, Ivan Quitschal wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi All
>>>>>>>>>>>
>>>>>>>>>>> Does anybody have any idea what could be happening here?.
>>>>>>>>>>> I have a laptop DELL INSPIRON 3511 and everything works just
>>>>>>>>>>> fine, literally everything. even the iwlwifi0.
>>>>>>>>>>>
>>>>>>>>>>> But in order to use my full 600mbps, i dont use the wireless
>>>>>>>>>>> but a TP-LINK USB ethernet connected on "ue0"
>>>>>>>>>>>
>>>>>>>>>>> ugen0.6:  at usbus0, cfg=0
>>>>>>>>>>> md=HOST spd=HIGH (480Mbps) pwr=ON (200mA)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> but something really strange is happening .. everytime i open
>>>>>>>>>>> the chromium e do a speedtest (could be speedtest.net or any
>>>>>>>>>>> other) , at the end of the test the eth interface dies .. it
>>>>>>>>>>> changes from full-duplex to half-duplex/no carrier and the
>>>>>>>>>>> only way to get the internet back thru ue0 is by rebooting the
>>>>>>>>>>> whole thing.
>>>>>>>>>>> not even a "service netif restart" does anything
>>>>>>>>>>>
>>>>>>>>>>> if anyone has any ideas why is that , would be appreciated
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I think it some new features they use in the USB data protocol
>>>>>>>>>> which we don't support. Check the Linux code.
>>>>>>>>>>
>>>>>>>>>> Between does:
>>>>>>>>>>
>>>>>>>>>> usbconfig -d 0.6 reset
>>>>>>>>>>
>>>>>>>>>> recover the device?
>>>>>>>>>>
>>>>>>>>>> --HPS
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Search for axge on bugzilla:
>>>>>>>>>
>>>>>>>>> I suspect you are using this chipset:
>>>>>>>>>
>>>>>>>>> Try:
>>>>>>>>>
>>>>>>>>> usbconfig show_ifdrv
>>>>>>>>>
>>>>>>>>> To know for sure.
>>>>>>>>>
>>>>>>>>> Also see:
>>>>>>>>>
>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%
>>>>>>>>>
>> 2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&d
>>>>>>>>>
>> ata=05%7C01%7C%7C7d0b875611fa4c22aa6808da97e8f75a%7C84df9e7fe9f6
>>>>>>>>>
>> 40afb435aaaaaaaaaaaa%7C1%7C0%7C637989324107373931%7CUnknown%7C
>> TW
>>>>>>>>>
>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
>>>>>>>>>
>> JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=o%2B12TNKJ4bcBBj1b4r4TT
>> 1f
>>>>>>>>> xyEalCMDMjOepy3MZm5c%3D&reserved=0
>>>>>>>>>
>>>>>>>>> --HPS
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Hans,
>>>>>>>>
>>>>>>>> actually the driver i use is not agxe (i thought it would be by
>>>>>>>> the time i bought the usbcard)
>>>>>>>>
>>>>>>>> this is the module im using
>>>>>>>>
>>>>>>>> if_ure.ko
>>>>>>>>
>>>>>>>> and thank you , yes, reseting the usb entry with your command
>>>>>>>> worked just fine.
>>>>>>>> i got the internet back after doing this
>>>>>>>>
>>>>>>>> usbconfig -d 0.6 reset
>>>>>>>>
>>>>>>>> do we have a bug here then?
>>>>>>>>
>>>>>>>> thank you
>>>>>>>>
>>>>>>>> --tzk
>>>>>>>>
>>>>>>>
>>>>>>> oh, i forgot to mention that the ure driver freezes not during the
>>>>>>> download test but in the middle of the upload, always
>>>>>>>
>>>>>>> dont know if that helps
>>>>>>>
>>>>>>> thanks
>>>>>>>
>>>>>>> --tzk
>>>>>>
>>>>>> Hi Ivan,
>>>>>>
>>>>>> Yes, there seems to be problem there. I need to look at the driver.
>>>>>> Maybe it is simply sending too much data, than the device can handle!
>>>>>>
>>>>>> --HPS
>>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Try lowering this constant to 8192:
>>>>>
>>>>> sys/dev/usb/net/if_urereg.h:#define    URE_TX_BUFSZ        16384
>>>>>
>>>>> Then recompile and install if_ure:
>>>>>
>>>>> make -C sys/modules/usb/ure KMODDIR=/boot/kernel all install
>>>>>
>>>>> --HPS
>>>>>
>>>>
>>>> You can also try other values, like subtracting one.
>>>>
>>>> --HPS
>>>>
>>>
>>>
>>> hi Hans,
>>>
>>> it worked but with a cost.
>>>
>>> i tried 8192 and it works 5 tests (5 speed tests in a row). freezes on
>>> the 6th.
>>>
>>> then i tried 4096 no success
>>>
>>> then i tried bufsize 2048 and its working now, i did several tests in
>>> a row and the internet keeps working just fine. but i noticed that the
>>> speed also dropped.
>>>
>>> with the same server , testing on windows, it goes like:
>>> 600 download / 300 upload
>>>
>>> and on freebsd with 2048 bufsiz it goes like:
>>> 300 download / 150 upload
>>>
>>>
>>> so it worked with a cost like i said, i had to give up half of my
>>> bandwitch
>>>
>>> what do you think ?
>>>
>>> and thank you again
>>>
>>> --tzk
>>
>> Hi,
>>
>> Can you try this instead:
>>
>> usbconfig -d X.Y set_config 1
>>
>> X.Y are the numbers after ugenX.Y
>>
>> Then it will use a different driver.
>>
>> --HPS
> 
> Hi Hans,
> 
> After the usbconfig -d X.Y set_config 1, the interface doesn't work anymore, how can I undo this?
> 
> Thanks
> 
> Ivan
> 

usbconfig -d X.Y set_config 0

or

usbconfig -d X.Y reset

Did you check dmesg?

--HPS

From nobody Fri Sep 16 15:09:38 2022
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 4MTctm636Zz4cBWc
	for ; Fri, 16 Sep 2022 15:09:52 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2060.outbound.protection.outlook.com [40.92.97.60])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTctl6ckYz3cgN
	for ; Fri, 16 Sep 2022 15:09:51 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=XY656RnIV4STMT0syfogaZkz8CkElWSIJFb7dj0XP3VEcg2XPHI1xUHjbDJBwSxN76ypjR8OPSvmSnWJJEK64B2qGVi2KS04BHatSLdl7H77iSwDitlU3At0wUQLxu2BHqo3cr2wjK5n1zc3VcUF2Xv2WV6QcccWgXC3w+tdeEs6LRM9MzrJUbDMG4UFbSpEGvvcnQ4u2q7FnigYOI/mFzPTOWJSGNKwWZv2Vcgp9H2tfrNwLHoK51cxsf+Mosey/seDxWDMw6pb54ECNeieMMmJWLvvVVTdCYB0d5glekyMqfseMYd7GpJQ5zYxj5RHtsqSzKmIH0NKBYIvozXStQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Q7UeQ9dcCK8FIQoBIxkGOPLpnjoS2RwKVYRYWM976XI=;
 b=NI6xruIQN5LZyleFO1E0OOm88Bkc1uIZojTIXkOQDE8AcY+LXcUEBSCGCSKXqob4Z9jAYU4VEddoTq5jKkuNBPA9KtGeccg3jUCAhwe/zSmofE0547ucg9XFvCODxCvl3oS3MeGKGJFPh4YujuSZVLFF86CneQyXFugdzqH5u3xp3n5GSh4ZlP4J7pJscpWoMoVZU55IC6h3tnD+EO1wq8WcVc5+IPKgGXwkl6I2egqBpSzNMrNUFT378nv0TalkH+3utKrmyMpueUTetq/JRiK8raB2cnNyvnrjnvh0bOy9pcgrqnyRpNYKSrJziZcAWBSh4qfOTKJlLAnhkMAv5g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Q7UeQ9dcCK8FIQoBIxkGOPLpnjoS2RwKVYRYWM976XI=;
 b=f5Rt18ddgTJqqFR2oJaBLh2RsKCTI42ka9qxylVBqCTxsx/tWl70RY4rFA42XUEicoiH/PJmC3rqksQNjdd9UevKuxbJ+KdMJLWKpnJ38IpbNmfJ7gOEYsnZOCuFxQbVk/uVaWKw4ijplw0u8MiyJAJLW15M0AXt3hnh51zd9alyHreWlTZiXEd6BQxiqu8svaEibwDA+0dACdJrPdWTPegRSS6Y7/vT3BN4gY5375SdaB1cFoh2zyNKdVY0oW1EgUZjgVm0OPmZQKFRTCX/snJcvki05DygKDHlfDpymxw0rYAC6iUHZSCOu/VvPOilz22B19K7iBX4zJQ+SQGsGw==
Received: from CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:f3::5) by
 CP5P284MB1742.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:f3::6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5612.22; Fri, 16 Sep 2022 15:09:44 +0000
Received: from CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM
 ([fe80::4f:e243:b3:f536]) by CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM
 ([fe80::4f:e243:b3:f536%7]) with mapi id 15.20.5632.016; Fri, 16 Sep 2022
 15:09:44 +0000
Date: Fri, 16 Sep 2022 12:09:38 -0300 (-03)
From: Ivan Quitschal 
To: Hans Petter Selasky 
cc: Ivan Quitschal , 
    "freebsd-current@freebsd.org" 
Subject: Re: RES: TP-LINK USB no carrier after speed test
In-Reply-To: <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
Message-ID:
 
References:  <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org> <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org> 
   <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org> <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
  <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org> 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
Content-Type: multipart/mixed; boundary="3432851520-162302078-1663340984=:2349"
X-TMN: [wuGnmfCk+G7pQSzaE6Lm+7Wx5aTsT1CS]
X-ClientProxiedBy: CPYP284CA0051.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:81::20) To CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:f3::5)
X-Microsoft-Original-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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP5P284MB1902:EE_|CP5P284MB1742:EE_
X-MS-Office365-Filtering-Correlation-Id: 88b7b950-fee5-43ad-529b-08da97f57cfe
X-MS-Exchange-SLBlob-MailProps:
	q3cIJLDN2c+MMZeZaNYDDS8hSvPfBqkHJPwnFfTBvqat+8rGkpQFhevDNRP9m3Jc442Xji4qw6wDIP4UvIEKoQx8LL7mQV9KsF8WhdibgzO1xhIagVSeUoGLCppR1a/N72JdinpfmuVN6zJWjKzFUaYw35Qv4eluyQWlUgtn7dXTe//WaI4fbM++oUw1NOtRCbeJAfVnOjt7hMOPq6uINeBkVgq7AnqHugxD4dPb0Rbeb8DxCNI85sk4kViFU674ntiN/NcPXYCzKhgKZovXmYH5T2px11rhgZacHNx/XFXsV3iPcHTFM9bA04bOgYkpOBctHAatiYBA6P57Cgpgdd2fMVumJztXNlNTFG21SxIj22gtLtnFndqoOdS1AGhhBa1AqN79eCXp/Exp60JROgoO+QSTNYKnZ90FLtDdm5EGtM3QrWBiivrY8U+kkmCxVHxJg0/vNinSzChA8lwoBi1WENOrUqF4Om8G4YPKxC9nHK5OBRuXj0y/gEsSvoGvTCijEzOH2k+U4ycpnXZQReN2GsBaapTjoy97aGVK/IzGVaelIVkrXn+8B1OE5QjA8lNGz0z84feBA2YSVLgZhzgg4E1nlwuiu+sgcbby15zxJtm6wulwfDZ/b4Fv/TUQTwG5wUcBX94QLrYd3g2BwTwNvaKT3WrCflflWs+0BkImaFHuxdq56L9r6bHjqsI4
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	QrO5aN4PdCSh7+yS9c/SJTokhJ2rOxDpPcjTzPMhklPH2tQqX8nuo3LJds1ygXuhzfwXcDIiyKNeX9iII8t6/6r+dQThlD00gfQLdP61TeUaqBtBcJOp6dV3A/2kA6PQ/TgZxV/C+nioIJC5UlmPHKjc+CNpbCJoJ+O0FnjOlSK7y+cLADvWT0QR9A7HmdEFKPhlHDco0bpYfV4RiIDP6RgEynvU8K4RNnHN6K4Juzc1Q5mCZEKNo6gGF6lHE2EacvCaHCZhKZED9+roHR/G4S8PEtbH8d4gLXJGmGngWDw2jM1zjL0FsnXbww6+tcJOeGbgjw4CV0lHMZdMlbOqZxTCyxAzSpuqkI6KrnQitSBiL91LdW6nO5q9W3uyfUOCEAAaXjXDQQc1+GMeLMhbYYNWAZPWicmaBb/4B+NTJkDm179LRhqGvkL9D4Wf3OHMdDUn2zAPVrzlmELovhSojseQn9FFfB4RhSSwrC75Lq6jM8A3+yU8PrFgrDMO/mOxqkhrmjYmKfLgMvxuKhK83m6PweViX4ww1xdhkGOvSDjPd8Gr5Rln+Su06or3w/XiPyITbwCe/iVj/a+Pm9U3edaY8NLd3oYhQ/coeuLtzstzlPecVliHyjAMGyCZbKmD0uBnOYVR0GkfUmsfAkk/TilEdGzY8YtixqyajX/KtbJ84dMFQRiJMAsSKvCrYiqd
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?MUtIVm92Zm9nd2V2Ynl4S1N3WUI0OTlFUldNSkhWdWU0Q2dlNzlZRllMREVj?=
 =?utf-8?B?dHVrMXc5RHpSNXNPc2JBR0Y0VkFwbVhoZThUZXMvc1lzZmNWbHo5ZWN1Mndt?=
 =?utf-8?B?SVMxZk5hNXg5SldCRGQ1ckRGc3VJREZJUmxSbEcxUzlhbkFPNjNITG1kRU1k?=
 =?utf-8?B?NFRyd2E0TTVrYU9wQlNjSTlmMDh4SXZlLzNsWDZXZmRNeFY5R3I0WHliUnZ1?=
 =?utf-8?B?WUYxT01yZWpSNVlaS0NsMHZSTU9lVXdrcWw3MnFrTWExN3Z2OWdTcmlpb3dx?=
 =?utf-8?B?YXEwL00wdDV4QmtQRTZURHFOZUVZRTJiOEJCNHVUeERTK29MM0xXNDFwcFMr?=
 =?utf-8?B?QmFic3F1UWdNRXB3UEdneE5wZytXUUdzNXZ1T2tTSWtIRDhpaGNBUHZxMzZW?=
 =?utf-8?B?WkJjZmhpV3hqOVlveDJ1cW9vUHowcG11RUwrQUxiVTRWYUlPTFp0dUV3MWo1?=
 =?utf-8?B?UHhkcUdSVWQ3djBuanFicHlheDhBdi9GMFdtZ2NhVlpVdEVXWHBoR21tWEVl?=
 =?utf-8?B?aFVLa1d5Y0d0SFpRa0NUNXpvMGRRR3FIVFhneTE0ZWdqeWM4WUpJbGJ4M3I4?=
 =?utf-8?B?SnlMUGY0aFJmUTM5QWJjcHVlbG5Zc2NKeU1Pb1l0RWQ2Z0JXRmEwVnlaS1h5?=
 =?utf-8?B?WndobGpHM0dkR1ZDN1o0czNFVjRDWkJpSDY0NzRveXM2YmtGd1g2eWozZDdv?=
 =?utf-8?B?dWVFNU1yK1pvVktCbER5K0s4MDJCQ3ZPRTR3K0pjNTNGWW5mMkVmTXhkRERn?=
 =?utf-8?B?eG8wRG1UZzhnV1Z2a3JxcHNZemJnMWZjZU4wNjdkS2Q2QjAwb0Q1aWp6VUNC?=
 =?utf-8?B?cnpzVUNiWElHR2pmZmpjL09aeVNhZUxlQm1tSTJhMDlKQjlzaW9YcDZQbTRK?=
 =?utf-8?B?VEVEa01tRmY0REFuQnZQRFVqcjBlSnFsMFpMWFZ4S2dpS0lCdDc3amNwbU9u?=
 =?utf-8?B?V1F2OW5NZS9xREdadVNDTFI4U1RSSE5ZRUU3Ynh3Qy9HNkVqOTFVeVM4N1hq?=
 =?utf-8?B?K2E1UWhQUDdvaS9sQm1UV2xScURKaWJoZ2RBN1hLSWZNczQvaTQzU2p0Y0pq?=
 =?utf-8?B?N1NLaEwrNGhYK0FxcmtZYlM5cTNOdEg5cXpKR2dmbVY5TkVZVG1iMkU4Rjdo?=
 =?utf-8?B?NVhna2JWZURaWW4yWFFHM2U2RUpUMTQzWSt6NHpmclpwYk1EQ0dwS3FqK3l6?=
 =?utf-8?B?UWYwbUROM1lBSGpVMjVyb2hLZ2hHMmRvTmhWWWcwZndaMHNrN3BHZVNZZFJG?=
 =?utf-8?B?ZUIrT3Z0YlpmcnFqMGJsTGFMQWR4d1RDVEk1Uk8zMnNxdGMrREF1RkJ5MDcw?=
 =?utf-8?B?V1c2MUo1d0FnemswTHVBS0xxajJKRlgyekFMZGdkT1NRbExvSE1vdDJIbUNo?=
 =?utf-8?B?YWROQVRlRk9XYlkvSW9tK2dhUHVZVWRPSit3dE1xMjh0NHBUUmo1d2Y0L1FO?=
 =?utf-8?B?ZStDR2oyMUZiZlNPZ3hxcmtsV0RFNHZvTW9TZlArOVdEOEdJZ2MzMFdJWFNH?=
 =?utf-8?B?KzFhQ243MmJ0ckNuWURmN0p2U2NObCtUTVN3N1dhRWNod2hJM1pLemR3bndR?=
 =?utf-8?B?b292WXp2R1FSZWRibWVob0EzWVNWZDlMV3RZL1BhWStTZ1JRT0xGTkNkcjZs?=
 =?utf-8?B?a3VSeXFWQ2RYVjNsNlIrNS9FNnk4bm5wTDFzbkgzUFJ1aDlZWTNicEVFQXhh?=
 =?utf-8?B?eCs3c0Rzb0IydFdBazVDa0VnQTFFbSs0dXEvTDU2L1hkRTZUMVdnNkh3PT0=?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 88b7b950-fee5-43ad-529b-08da97f57cfe
X-MS-Exchange-CrossTenant-AuthSource: CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2022 15:09:44.8826
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP5P284MB1742
X-Rspamd-Queue-Id: 4MTctl6ckYz3cgN
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=f5Rt18dd;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.60 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-3.92 / 15.00];
	CTYPE_MIXED_BOGUS(1.00)[];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-0.99)[-0.992];
	NEURAL_HAM_SHORT(-0.98)[-0.983];
	NEURAL_HAM_MEDIUM(-0.94)[-0.943];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.60:from];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.97.60:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	DKIM_TRACE(0.00)[hotmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	MIME_TRACE(0.00)[0:+,1:+];
	FREEMAIL_CC(0.00)[hotmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--3432851520-162302078-1663340984=:2349
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT



On Fri, 16 Sep 2022, Hans Petter Selasky wrote:

> On 9/16/22 16:31, Ivan Quitschal wrote:
>> 
>> 
>>> -----Mensagem original-----
>>> De: Hans Petter Selasky 
>>> Enviada em: sexta-feira, 16 de setembro de 2022 10:40
>>> Para: Ivan Quitschal 
>>> Cc: freebsd-current@freebsd.org
>>> Assunto: Re: TP-LINK USB no carrier after speed test
>>> 
>>> On 9/16/22 14:18, Ivan Quitschal wrote:
>>>> 
>>>> 
>>>> On Fri, 16 Sep 2022, Hans Petter Selasky wrote:
>>>> 
>>>>> On 9/16/22 08:34, Hans Petter Selasky wrote:
>>>>>> On 9/16/22 08:20, Hans Petter Selasky wrote:
>>>>>>> On 9/15/22 17:36, Ivan Quitschal wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu, 15 Sep 2022, Ivan Quitschal wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Thu, 15 Sep 2022, Hans Petter Selasky wrote:
>>>>>>>>> 
>>>>>>>>>> On 9/15/22 17:18, Hans Petter Selasky wrote:
>>>>>>>>>>> On 9/15/22 17:16, Ivan Quitschal wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi All
>>>>>>>>>>>> 
>>>>>>>>>>>> Does anybody have any idea what could be happening here?.
>>>>>>>>>>>> I have a laptop DELL INSPIRON 3511 and everything works just
>>>>>>>>>>>> fine, literally everything. even the iwlwifi0.
>>>>>>>>>>>> 
>>>>>>>>>>>> But in order to use my full 600mbps, i dont use the wireless
>>>>>>>>>>>> but a TP-LINK USB ethernet connected on "ue0"
>>>>>>>>>>>> 
>>>>>>>>>>>> ugen0.6:  at usbus0, cfg=0
>>>>>>>>>>>> md=HOST spd=HIGH (480Mbps) pwr=ON (200mA)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> but something really strange is happening .. everytime i open
>>>>>>>>>>>> the chromium e do a speedtest (could be speedtest.net or any
>>>>>>>>>>>> other) , at the end of the test the eth interface dies .. it
>>>>>>>>>>>> changes from full-duplex to half-duplex/no carrier and the
>>>>>>>>>>>> only way to get the internet back thru ue0 is by rebooting the
>>>>>>>>>>>> whole thing.
>>>>>>>>>>>> not even a "service netif restart" does anything
>>>>>>>>>>>> 
>>>>>>>>>>>> if anyone has any ideas why is that , would be appreciated
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> I think it some new features they use in the USB data protocol
>>>>>>>>>>> which we don't support. Check the Linux code.
>>>>>>>>>>> 
>>>>>>>>>>> Between does:
>>>>>>>>>>> 
>>>>>>>>>>> usbconfig -d 0.6 reset
>>>>>>>>>>> 
>>>>>>>>>>> recover the device?
>>>>>>>>>>> 
>>>>>>>>>>> --HPS
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> Search for axge on bugzilla:
>>>>>>>>>> 
>>>>>>>>>> I suspect you are using this chipset:
>>>>>>>>>> 
>>>>>>>>>> Try:
>>>>>>>>>> 
>>>>>>>>>> usbconfig show_ifdrv
>>>>>>>>>> 
>>>>>>>>>> To know for sure.
>>>>>>>>>> 
>>>>>>>>>> Also see:
>>>>>>>>>> 
>>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%
>>>>>>>>>> 
>>> 2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&d
>>>>>>>>>> 
>>> ata=05%7C01%7C%7C7d0b875611fa4c22aa6808da97e8f75a%7C84df9e7fe9f6
>>>>>>>>>> 
>>> 40afb435aaaaaaaaaaaa%7C1%7C0%7C637989324107373931%7CUnknown%7C
>>> TW
>>>>>>>>>> 
>>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
>>>>>>>>>> 
>>> JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=o%2B12TNKJ4bcBBj1b4r4TT
>>> 1f
>>>>>>>>>> xyEalCMDMjOepy3MZm5c%3D&reserved=0
>>>>>>>>>> 
>>>>>>>>>> --HPS
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hi Hans,
>>>>>>>>> 
>>>>>>>>> actually the driver i use is not agxe (i thought it would be by
>>>>>>>>> the time i bought the usbcard)
>>>>>>>>> 
>>>>>>>>> this is the module im using
>>>>>>>>> 
>>>>>>>>> if_ure.ko
>>>>>>>>> 
>>>>>>>>> and thank you , yes, reseting the usb entry with your command
>>>>>>>>> worked just fine.
>>>>>>>>> i got the internet back after doing this
>>>>>>>>> 
>>>>>>>>> usbconfig -d 0.6 reset
>>>>>>>>> 
>>>>>>>>> do we have a bug here then?
>>>>>>>>> 
>>>>>>>>> thank you
>>>>>>>>> 
>>>>>>>>> --tzk
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> oh, i forgot to mention that the ure driver freezes not during the
>>>>>>>> download test but in the middle of the upload, always
>>>>>>>> 
>>>>>>>> dont know if that helps
>>>>>>>> 
>>>>>>>> thanks
>>>>>>>> 
>>>>>>>> --tzk
>>>>>>> 
>>>>>>> Hi Ivan,
>>>>>>> 
>>>>>>> Yes, there seems to be problem there. I need to look at the driver.
>>>>>>> Maybe it is simply sending too much data, than the device can handle!
>>>>>>> 
>>>>>>> --HPS
>>>>>>> 
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Try lowering this constant to 8192:
>>>>>> 
>>>>>> sys/dev/usb/net/if_urereg.h:#define    URE_TX_BUFSZ        16384
>>>>>> 
>>>>>> Then recompile and install if_ure:
>>>>>> 
>>>>>> make -C sys/modules/usb/ure KMODDIR=/boot/kernel all install
>>>>>> 
>>>>>> --HPS
>>>>>> 
>>>>> 
>>>>> You can also try other values, like subtracting one.
>>>>> 
>>>>> --HPS
>>>>> 
>>>> 
>>>> 
>>>> hi Hans,
>>>> 
>>>> it worked but with a cost.
>>>> 
>>>> i tried 8192 and it works 5 tests (5 speed tests in a row). freezes on
>>>> the 6th.
>>>> 
>>>> then i tried 4096 no success
>>>> 
>>>> then i tried bufsize 2048 and its working now, i did several tests in
>>>> a row and the internet keeps working just fine. but i noticed that the
>>>> speed also dropped.
>>>> 
>>>> with the same server , testing on windows, it goes like:
>>>> 600 download / 300 upload
>>>> 
>>>> and on freebsd with 2048 bufsiz it goes like:
>>>> 300 download / 150 upload
>>>> 
>>>> 
>>>> so it worked with a cost like i said, i had to give up half of my
>>>> bandwitch
>>>> 
>>>> what do you think ?
>>>> 
>>>> and thank you again
>>>> 
>>>> --tzk
>>> 
>>> Hi,
>>> 
>>> Can you try this instead:
>>> 
>>> usbconfig -d X.Y set_config 1
>>> 
>>> X.Y are the numbers after ugenX.Y
>>> 
>>> Then it will use a different driver.
>>> 
>>> --HPS
>> 
>> Hi Hans,
>> 
>> After the usbconfig -d X.Y set_config 1, the interface doesn't work 
>> anymore, how can I undo this?
>> 
>> Thanks
>> 
>> Ivan
>> 
>
> usbconfig -d X.Y set_config 0
>
> or
>
> usbconfig -d X.Y reset
>
> Did you check dmesg?
>
> --HPS
>

hi Hans,

i had to reboot my router but i got my interface back running.
and i have good news
after that, im still using the buffersiz 2048 and this time i got 600mbps 
download /300 upload just like that.
these 2 things were not related i can see.

i guess thats it , looks like its solved.. i will keep monitoring here , but so 
far so good

thank you a lot as always

--tzk
--3432851520-162302078-1663340984=:2349--

From nobody Sat Sep 17 03:57:23 2022
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 4MTxwS2rxRz4c4Xf
	for ; Sat, 17 Sep 2022 03:57:28 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MTxwR44Gpz3F46;
	Sat, 17 Sep 2022 03:57:27 +0000 (UTC)
	(envelope-from grahamperrin@gmail.com)
Received: by mail-wr1-x42c.google.com with SMTP id e16so38869788wrx.7;
        Fri, 16 Sep 2022 20:57:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:cc:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date;
        bh=PCWRvldZCnA6HVUyyjfc9Zva4IMQtkIqjr6Sg5fPQ1U=;
        b=Au9shOfdyIdqfx5CSVW7XkJ1K236IwaIvN7WHKXPHZxnftoK3Jtoxu0IPmza+0pg4b
         0K2kQGBSDjOo8rHop6hw1wLL85/Ej8CIx63JG8skXCI82YmecZ1BvJzzFCReyyVvsTDM
         3XR4tK8uNQW5Kje63u0pcmS2Ux9/mZaqzYBbGJrA9I8+fNYOjY7hwIHKEjVxRowKtCR0
         h55sIks+B6z0sGIh5gbnFhKE29DF5NeR5Zr5XXCGgI9tf13UpjNqGAFygxh5GWvC8TUt
         oCworMFA85TN3as2tKfQJ4ueyuliYMV0wwJlHQQ00C0/9Jp79UD7HE/IPn3fP7dXyYu1
         l/Qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:cc:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date;
        bh=PCWRvldZCnA6HVUyyjfc9Zva4IMQtkIqjr6Sg5fPQ1U=;
        b=pCbLB3qVScYCztsQYWityhCNfl4GcKGa1spH7dOnfJmKpD0QQn+rMImyVP+L/+nmch
         3nouHZ6MO1GfXlmBtRy9gK7zaUldPm6pEb3yw7JrZ3hJM5muKiVBXysWv7EsMc+piKGT
         o9dIxtbNPj5JAXGEbzkEoxlecS+9wV0Vx6mTT5ANDkOUL432S72kEXewuJVTrLhNlCge
         bPWPPXU1urBOkjvxA7/2FQyPKp2xrZWIg21FetXavKDqo7OYMLU/4rRR+flrMay78njE
         GEwWqB5wA6y9mwIKmj8fEIJJ2cG6/9Up63EhZwcbNCyTsRv+z8T6OChcRFHyGocJ5+9b
         NhVA==
X-Gm-Message-State: ACrzQf2MALuv+kf8VPO2BZ5gTrPQBbzBU/c9p2GvrLKftUyj9Z1tSg+B
	lbahpjB1GD17HSvWTOwKopC3G1qRkxnMBg==
X-Google-Smtp-Source: AMsMyM7nIOU6vlBge37s1zi9ybVhdd16LeJNVHGRQHf4fybne2WHzmQIV5LA/8yV24EdKzgyTHnPLg==
X-Received: by 2002:a05:6000:168d:b0:22a:d704:1ad1 with SMTP id y13-20020a056000168d00b0022ad7041ad1mr4820590wrd.436.1663387045391;
        Fri, 16 Sep 2022 20:57:25 -0700 (PDT)
Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2])
        by smtp.gmail.com with ESMTPSA id p10-20020a5d48ca000000b00229d55994e0sm1683492wrs.59.2022.09.16.20.57.24
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 16 Sep 2022 20:57:24 -0700 (PDT)
Message-ID: <35bd4c7f-47da-c912-c5b8-62812ca00c15@gmail.com>
Date: Sat, 17 Sep 2022 04:57:23 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: My first commit to src!
Content-Language: en-GB
To: Nuno Teixeira 
References: 
Cc: FreeBSD CURRENT 
From: Graham Perrin 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MTxwR44Gpz3F46
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Au9shOfd;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) smtp.mailfrom=grahamperrin@gmail.com
X-Spamd-Result: default: False [-3.81 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-0.99)[-0.990];
	NEURAL_HAM_LONG(-0.82)[-0.825];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEFALL_USER(0.00)[grahamperrin];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c:from];
	DKIM_TRACE(0.00)[gmail.com:+];
	SUBJECT_ENDS_EXCLAIM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 16/09/2022 14:42, Nuno Teixeira wrote:
> Hello to all!
>
> Just to let anyone knows that I made my first commit to src:
>
> https://cgit.freebsd.org/src/commit/?id=b44869cba1b391931b831135a9cefcc6ca635103
>
> It took me almost 2 years until I find right device hints, nids and 
> stuff to get my speakers to work.
>
> It was a very special moment when I commit it.
>
> Thanks to all and specially thanks to @emaste,
>
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)
Congratulations!

From nobody Sat Sep 17 10:41:25 2022
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 4MV6td1qhyz4cLGP
	for ; Sat, 17 Sep 2022 10:41:29 +0000 (UTC)
	(envelope-from garyj@gmx.de)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MV6tc20pZz3nw9
	for ; Sat, 17 Sep 2022 10:41:28 +0000 (UTC)
	(envelope-from garyj@gmx.de)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
	s=badeba3b8450; t=1663411286;
	bh=wcAXL9d8MMXkOuvbzSgq8ZmkorSIzdgLGnXESMR+upI=;
	h=X-UI-Sender-Class:Date:From:To:Subject:Reply-To;
	b=YS80O9ua96+Rede3cmMCUyJm3QfO35K6kiPh9W3Pz2OUGz5prU8ig/ejFLkxwo9Wa
	 MLMPg/RAD63CixsAPurdsCJ2TK5D/b+ilz/vwmGqL7weIF+NBZW4mjmx1E5IjwLIWo
	 zHsf5lajYnn3U2ZlucgGU66EvcPZuFu/FtY8GqD8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from ernst.home ([91.2.48.8]) by mail.gmx.net (mrgmx004
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Msq2E-1pSRKg1kL2-00tFpo for
 ; Sat, 17 Sep 2022 12:41:26 +0200
Date: Sat, 17 Sep 2022 12:41:25 +0200
From: Gary Jennejohn 
To: current@freebsd.org
Subject: build of vfs_lookup.c now broken in non-INVARIANTS kernels
Message-ID: <20220917124125.586efc59@ernst.home>
Reply-To: garyj@gmx.de
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:ccO4iitzO7obrZwV5XEPFOe6Jkmm2bzclh/vUiNhuTtVgVrikHX
 3DHgHsifAyYWsShR2fbST66kv0KEsV+9KEfxemYcxehwags9+pwFMAu0aYxtz9q2oGvsSQ8
 PvzmXfmydSs8yKivTYnuJpj3bAtXzXkBpjFGMINB2gllvn7DYPX52cTHeSjwu7aaCLsVaqG
 Y4UH6poEc5T90L5vf+Ujg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:igsvrFDn444=:IZWiA30chJzN0dA1+q0Lwc
 S07xMOjTMILSELKtXSd535rfbARpg/A6CD+lg+PqDb0RI0nicr1fDjVJ+N/4JmRss3JrJSj8B
 4Sd+ybliRUSkmjkeJaJxJXt+M9jzVtDTuUCz7VevP+f+N/IuW63HEc/ylXtgf3LLzZjLb5rBQ
 XKkWnMNXdR2mjI2QKon8Qx2PJJOHoyLJvzNNUU00g5TNfBAFrO1fp+eMmalcddEMGJ4HEYk9R
 NnwG4bWkrGPWzePMds3tjWVU57xxWJ5uAZ3Dd34AM7v04Ht7YBGrCnFwSLb3rrM2cJQsHLgjR
 UUa7+MWwuigAtVnSt2Enft8J5cE9vzuuGQ+tL2azLJjtAMLC9sV29XBUbKQI+WLts9Le6D9Ld
 8oqkC8rNGUa+9BSBkLRXjvjMV4p0xgdmihVkKoKtMk5qRZRREpVlORPDAWnIWEUHz78X3PGEh
 f/CtzXfUynlGa38MhkaIlmKhiEiGWJwMwXpvY4HAYcnGVSooBw+gByiNQ9LRZVkIZTosHA1u9
 CX9FtfOuMXjGR/5pYBmVX/llCqURPR1/aXteOTZWjgoGa1Ogt9RccSsbn/mH90cbOsfn0VYdN
 YQ5s3RWDAAEjEPPX5X/y4ia3XUqNJb2YX6eJxjzNGincJyYaW09LD+PBC7r3e0KUmqMBnMdde
 G1b+E6CdpdIYreVpnfH8XBWtnY7Xn6mSbKUtyAfoG1XvuOyfjJtGreVP5J8Twvmtw8T8zqoqh
 cHH7P7tdsi7uqHYR0+B9ebQWv+H2zIeCtxZqhV805Wfdk+hYE9hVN2hTZPeTRnObh6jsq6xlv
 ugiduxNNm/9XlkdavHphSPhVJRdcUPLirusjPU/35VJBmKZ6e1+j7QJLxe4bOzZuIZfGk2fqc
 I7n93YXYLaWrllruIfkAoCUrwbVQLOOhNPSgTsXjFZ3wU2qz37YlnzMB1Z+w4lD8QyR1+1ya+
 Yg+RaGeCxlwOy/BEW67ADYx2VsofAdo51CW1/LsBhWHSM/+FcCmOdEfd8YSyWpswq95B/WeS1
 WFBYeJ7mxA4acpqxAn1O2U4knrMojKvfRdlkXX6paAOkN6nH6gdIZ6EfvNsGDR1FQiclf7IZM
 FYkupISmck3KrZjm0qpFElBCEZoJ5TH6Tk5NH2k5+C0/kSk4P6tZAFGY23dyjUQ3ttoeVdRRm
 Ms4Oc=
X-Rspamd-Queue-Id: 4MV6tc20pZz3nw9
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=YS80O9ua;
	dmarc=pass (policy=none) header.from=gmx.de;
	spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.15.15 as permitted sender) smtp.mailfrom=garyj@gmx.de
X-Spamd-Result: default: False [-4.87 / 15.00];
	DWL_DNSWL_LOW(-1.00)[gmx.net:dkim];
	NEURAL_HAM_SHORT(-0.98)[-0.984];
	NEURAL_HAM_MEDIUM(-0.95)[-0.951];
	NEURAL_HAM_LONG(-0.84)[-0.838];
	DMARC_POLICY_ALLOW(-0.50)[gmx.de,none];
	R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450];
	R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.15:from];
	FREEMAIL_REPLYTO(0.00)[gmx.de];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.15:from];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	HAS_REPLYTO(0.00)[garyj@gmx.de];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	FREEMAIL_FROM(0.00)[gmx.de];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_NONE(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[gmx.net:+];
	FREEMAIL_ENVFROM(0.00)[gmx.de];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Compiling vfs_lookup.c now fails when NONINVARIANTS is not included in
the kernel config file because NDVALIDATE is defined as NDVALIDATE_impl,
which itself is only defined when NONINVARIANTS is also defined.

This breaks buildkernel.

=2D-
Gary Jennejohn

From nobody Sat Sep 17 10:46:36 2022
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 4MV70Z27X3z4cM7J
	for ; Sat, 17 Sep 2022 10:46:38 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MV70Y3vQ5z3qXY
	for ; Sat, 17 Sep 2022 10:46:37 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: by mail-oi1-x232.google.com with SMTP id t62so9042913oie.10
        for ; Sat, 17 Sep 2022 03:46:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc:subject:date;
        bh=asC8DVx4iMgP5hEq7WOfyPBQrkTcibdR4Suw2OqY8DQ=;
        b=CiKIRUBgJODBTx+OPHiPkj43Zw78lcWfrv9lNLr3LkLvhaHjD9Tj4AnkmpLuwSALDg
         k5L41R7UTOdmRAG0UQ9v/W6cEtXEJN+LgdWDkayRg3oeQnos/Z3gLHX07tePAua/Wsy6
         2td+y2TmoUA6sKFwsUvu6IdbZbJOGsm4pZ24T1ygtBQyCLjM/ulL2eHqlTiD3LloUOwP
         Z6IJw8xf6P9jbeuHFXPje+iRttZC6Fv/ePup4H9FDdIbu9MDrGIAo0uJxBDfYg/kYdgA
         raQE/4ghuMO9KWD7WBgSITA4bo9wKp0msCWL0y4H08lg8P84xKjenDNg4HqK1d16qDt7
         SJng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=asC8DVx4iMgP5hEq7WOfyPBQrkTcibdR4Suw2OqY8DQ=;
        b=iNxdXNeou1HhKLu5X6dowKE0delc8sr/2E3mgIfUnUK3Nhk68i6gAS5PyRV2nH+0R8
         ryC9FL+wDzms04sRopN7jRNZMinqIma+GHpOe3PA3RivDpq07hdylupqh0PsyYAsaFef
         TSGh8M9aaQ4Kt+b8otX5d5LLyuJi9jI5JpbybxVs797hjIJUJlSCEIko+poFTnSg+mYT
         gLxxREzrio59tyHPSIpBIAxjetE2y49HLLggOzCO85ZfgZ2wQiPAksjZ+L5Dx0jLJPF9
         2QnPkCQzWH3AMPHGGf+vlT/0QlUia5j9Fi6EjxFYKzd0jPS+yYdRVKXEmY5i97qG1D6b
         6Btw==
X-Gm-Message-State: ACrzQf2GCICxF3DoVaKyMkWXGYM+u3uvsVIVQcTVJieRenBm8mSi1IzG
	6i+D5E70Nfn4kH5awDzEwuc6jBB5YRA0j9fptY4=
X-Google-Smtp-Source: AMsMyM5uYwifUIXnjKjx+Q3FUknlVgkuSIQaA9eB8oel6+Is2mBolxTmLKUEJLxXaJdxJUHxb+QLaYtdvVpRjh6J+rY=
X-Received: by 2002:a05:6808:201b:b0:350:87c:a8c6 with SMTP id
 q27-20020a056808201b00b00350087ca8c6mr4312674oiw.228.1663411596748; Sat, 17
 Sep 2022 03:46:36 -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
Received: by 2002:a8a:352:0:b0:474:267f:5338 with HTTP; Sat, 17 Sep 2022
 03:46:36 -0700 (PDT)
In-Reply-To: <20220917124125.586efc59@ernst.home>
References: <20220917124125.586efc59@ernst.home>
From: Mateusz Guzik 
Date: Sat, 17 Sep 2022 12:46:36 +0200
Message-ID: 
Subject: Re: build of vfs_lookup.c now broken in non-INVARIANTS kernels
To: garyj@gmx.de
Cc: current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MV70Y3vQ5z3qXY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=CiKIRUBg;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2607:f8b0:4864:20::232 as permitted sender) smtp.mailfrom=mjguzik@gmail.com
X-Spamd-Result: default: False [-3.88 / 15.00];
	NEURAL_HAM_SHORT(-0.99)[-0.986];
	NEURAL_HAM_MEDIUM(-0.98)[-0.984];
	NEURAL_HAM_LONG(-0.91)[-0.912];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::232:from];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[gmail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmx.de];
	MLMMJ_DEST(0.00)[current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

fixed in https://cgit.freebsd.org/src/commit/?id=b77bdfdb67c2e9660658a0373662e4263a905e90

On 9/17/22, Gary Jennejohn  wrote:
> Compiling vfs_lookup.c now fails when NONINVARIANTS is not included in
> the kernel config file because NDVALIDATE is defined as NDVALIDATE_impl,
> which itself is only defined when NONINVARIANTS is also defined.
>
> This breaks buildkernel.
>
> --
> Gary Jennejohn
>
>


-- 
Mateusz Guzik 

From nobody Sat Sep 17 10:56:15 2022
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 4MV7Ck5b9Pz4cNtY
	for ; Sat, 17 Sep 2022 10:56:18 +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 (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MV7Cj5N2Bz3sDc
	for ; Sat, 17 Sep 2022 10:56:17 +0000 (UTC)
	(envelope-from garyj@gmx.de)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
	s=badeba3b8450; t=1663412176;
	bh=MQC1ImainCpwfCT0GDXxHhivrwt2WY184a3eig7Iwgg=;
	h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References:
	 Reply-To;
	b=dPHfk6h/KfjuQEjM+yQmIwq32cVw2u+SdRte1LWDSYTF+QF3pHM1y1k7EJyXrcMsg
	 hGi1117I3tqR0NCIWDPzE4xX3ka+sY1TT3APZvoaoEvRKBEjuoG6TBmdumt+eYBiTf
	 0VcDM5F4lSzUwlG67PFmajXxnQcZa4MxQOQ5hS8E=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from ernst.home ([91.2.48.8]) by mail.gmx.net (mrgmx004
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N0oFz-1pTGq50hD3-00wovD for
 ; Sat, 17 Sep 2022 12:56:16 +0200
Date: Sat, 17 Sep 2022 12:56:15 +0200
From: Gary Jennejohn 
To: current@freebsd.org
Subject: Re: build of vfs_lookup.c now broken in non-INVARIANTS kernels
Message-ID: <20220917125615.08f68e43@ernst.home>
In-Reply-To: <20220917124125.586efc59@ernst.home>
References: <20220917124125.586efc59@ernst.home>
Reply-To: garyj@gmx.de
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:525GW+obwi5vhkkDt/K9FDU1pSokJr9naVRBTvqmaH/Ka7xw4ha
 /Q5osVqnG4E+prEJIQ4386TDktAWazSqbxFCSDB8V6YfZIJGczl+Oy0D34VObSMooJiDW+9
 Y6zZf8QIUTOZQQGpN3dHioKIcINxu3UtvR9S0yWh0dR+4NRIePmCDZbbVqa3I4AV6uPSQxB
 Uv2KgReHlH6MkylPBYC+Q==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:q4TD00f7pyQ=:qtGFwYhclj8B/4NUYYONnn
 sLpRfFBFxlDyHFFdP9TdPKjt/7nwm/dOWMbhX8vJSjbhj3gqX6R9j5D59b1WIOTqQPCTicLhH
 tKv8zpWTaPAlv37J/u524q1jQUCEwfPTaVZnAtHDjoQ31iirls/IJADX/xnnvgM7vOanTIe2+
 8meEYMoKNTKaPeoP5lG6LU8DHXtK4Ri/kqBdRxqQfUpBa9yGAGKmU0pTPuGh5y0vfFyfRS0mx
 muCObsOx836oW17UR1oqXRBFHhEfmvnEHTUn0UqwBc5x7efFLckYtyZvebL7HOty2n/w10RLR
 UZXPlqElXhGakX2A+lcY68v57YnBemHVynvMB81cABt8wTvZIPNfEf0PkID+CLBX98knrv9XS
 leYevM4/chJ0TMAS83JGAklHGoiwDwEmUOraqm5zk/b6G/1exLOpXG5E5YfC+LoOqGwtGHBcE
 hMTj1S/vEFQcI/iw7vmnCTmxnbRequYA8BKF8539AjAQBNj0TzvWIxVm8g6O6k82Raz37Zk81
 wOR53YQNAWwHEOp/ZfeRwUmLAFgjGtMAF/r8uZNzYr9EzbHitfINmuANUvEo7grcnilJaF1uR
 UG+eogz7lOt2etn1LlVrTuhSPUOPrE5AjOiRaBl6OIYdRRnDg64xo/5ft+I82f26SepKUg/L8
 HxBxdRxaVUEWP77VbbPJj3X+WwVai5espT0n0M+cFQjKHjMj+htSmID45OsQnQUSE9UssowTh
 2w3V82S30t7dG7OB+GZXK0AdYjIsZ1lRpFMuIg1CvTrBVuKhiyzuj7WY2GQE/VvCvsF+3Bk4w
 rV1FwPnxchPU+nXnzsUjkpemyUl9z+lAFf7Il0dOj1yiUFVu5vkuGattMdT5qX2TL/FDivcxI
 y9sym+9aZ4P72pEFO4ll7kPAYodVO1MknLNfhdk9OBL/oZ+mqVMhGUFslyf9qF92cJXlUBoJx
 8zJW3ps8FJ9PdOmmm0AXnGh+1/yvJP0mxAKt/eE9FiG8nKAQLdRtGgZxRrpsMA8s8L5Nyn/CL
 3jKfAxaBRpRET+bjAu8LLunsgz7KGLvgR7H3yUlCuyHreEJ52oTSZDfOuQvrp4W83zeIRRXdk
 xt6fapZA+UcumI9FYveQ0TPbW+aeISMYFsoH82sxF3DXQXZXSlmj+R9guhqcuhls3w0XPfpA2
 PDwBc=
X-Rspamd-Queue-Id: 4MV7Cj5N2Bz3sDc
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b="dPHfk6h/";
	dmarc=pass (policy=none) header.from=gmx.de;
	spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.15.19 as permitted sender) smtp.mailfrom=garyj@gmx.de
X-Spamd-Result: default: False [-4.87 / 15.00];
	DWL_DNSWL_LOW(-1.00)[gmx.net:dkim];
	NEURAL_HAM_MEDIUM(-0.98)[-0.975];
	NEURAL_HAM_LONG(-0.90)[-0.900];
	NEURAL_HAM_SHORT(-0.90)[-0.897];
	DMARC_POLICY_ALLOW(-0.50)[gmx.de,none];
	R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450];
	R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.19:from];
	FREEMAIL_REPLYTO(0.00)[gmx.de];
	RCPT_COUNT_ONE(0.00)[1];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	HAS_REPLYTO(0.00)[garyj@gmx.de];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	FREEMAIL_FROM(0.00)[gmx.de];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_NONE(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[gmx.net:+];
	FREEMAIL_ENVFROM(0.00)[gmx.de];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, 17 Sep 2022 12:41:25 +0200
Gary Jennejohn  wrote:

> Compiling vfs_lookup.c now fails when NONINVARIANTS is not included in
> the kernel config file because NDVALIDATE is defined as NDVALIDATE_impl,
> which itself is only defined when NONINVARIANTS is also defined.
>
> This breaks buildkernel.
>

Woops. NONINVARIANTS should be INVARIANTS.

=2D-
Gary Jennejohn

From nobody Sat Sep 17 11:21:01 2022
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 4MV7mK36cYz4cSQC
	for ; Sat, 17 Sep 2022 11:21:05 +0000 (UTC)
	(envelope-from garyj@gmx.de)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MV7mJ0yzFz3xRJ
	for ; Sat, 17 Sep 2022 11:21:03 +0000 (UTC)
	(envelope-from garyj@gmx.de)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
	s=badeba3b8450; t=1663413662;
	bh=VEthu1jEbKPvqrPK8WU6VVHE7oWRCcgiZaBS9x23hNA=;
	h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References:
	 Reply-To;
	b=HLa/UfmVklEs/5Dr/VxI/jFhd7L4UE37kIw6b3bJXiBK9vkniO/Wz0RcfSy5scuVS
	 9EcoQMdyxHE6Z6z47QW7TBVZABk9PN1lp3h+hZqjCYjPLf27FM9zg0LRn0watWle1n
	 VkDltl0grhfvXWfmzes/0WM7f6DK1G4yNuwyb4Fg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from ernst.home ([91.2.48.8]) by mail.gmx.net (mrgmx104
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mf078-1pFjVs0frW-00gWwJ; Sat, 17
 Sep 2022 13:21:02 +0200
Date: Sat, 17 Sep 2022 13:21:01 +0200
From: Gary Jennejohn 
To: Mateusz Guzik 
Cc: current@freebsd.org
Subject: Re: build of vfs_lookup.c now broken in non-INVARIANTS kernels
Message-ID: <20220917132101.10732281@ernst.home>
In-Reply-To: 
References: <20220917124125.586efc59@ernst.home>
	
Reply-To: garyj@gmx.de
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:at8uNmG3JkYJEuagFYmdhp0E3I01Bup1NYx3win+mkzpBdnOdpr
 xGU2ScMkrEpQdE99L8+VRU82fSn/QFyuwJETvuREdXdDMsraIkstGCxQ/487TLEWYhIsylM
 ZaAJIBEq1dQqVw2cI8byHmwwu1MPZP2tC+QFMBzun88Io+cwbcGmCwjbwa2YcAj/t328cbW
 5ZhsJtTxODp+SxbwOtzeg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:/joM0HKPqww=:rHvfccUj3DsxZqEEe6AwJw
 ZM1JCiHYokOgfZohaLR86h5uBSV7ExHUs0C1dMOffQrdEEblqvHM9ass5YYhcyX4EwwddM0yM
 eVml3PALYDQOFu/u907sU6slf1Ti5ogQvVb1PmIBfR4JklN7bu5mPbeP38TbPWsk3lsPeZUzv
 8yWydYSWx1shvj2Ns0hPpGnuH+jqOVolHVgMpq7KAXmmDY0BW9mHQMqqR8giE+eTJsST7uw9j
 rTiz5+F450i8YxSOdU75m6dhMAxa1RSVqaD/CygGxXUmNHBGq6q9uvi3udGtl5EgVzpHaDL2l
 qpqvUEAm+9+lFlXaG90evCKMFW51jEjwUqOipeVA6fgNEwFaKZoAOhFPQHyHicYPPtaUPuCkd
 S4n4vt0GXxqsgnAmRFJfkpkAMATD8LPnzF20x5kepzf9XB8Cm8tnOkE7vC0zgrqsAwIXv26yY
 HFnqwro1I5N8ASqXfvWsi/mPLqd7HKYnJUiEbv6mfIQlAk0P32bJ6xOy7iRbl85xUb90xRid6
 ssGIJ2vCfKBm2tjJUpVidIFdGmTIwuvfA9INt98chanyfPxxb8f+7+ErhCdJVAWfHsFGHDpzI
 8roG1/Pxh92JUO1Ru37mRqZeNJiB/Ht0Kb6n3Fy5ooLMIJ1K0EnuDCMGkP4Tmu2WSwOgwAOHc
 nKLxwBgUtwaqpQ8cjdvF5DK3SeZbc6cysZLycXLppHsFQhljH+Zuzk3dS8kH8caIe3IdyJ7dl
 67B5dL53EUWYCT/hF767TJbyOaBQ7mGhKX9Zo9uHSxkrW9/LlbeVU8lWe7HUrA/sot+64HxkG
 rO2KCkFUYv/dbVPLJuYcjTyhm0vcNVYa8fQkNHKePaf2oTlEejStkEWYS6wGeEApT0exxsDHm
 ycO9lpExC60NiFoaj4Vueahy5ls0BgKAxNo7iotfac6JLvE9wDdm9ZWnWRtmx3Q9CYkiUJqL7
 +OpqW9CUCc94xfaY9cV0iczsd+3BmMfdjeBaY60odmyL0rsZp1gRA2i3BrxMawKxbvEY15XDK
 5XfWUIXSMSnf1ESOwsy18tuDWJLMfV3JphbuDsINJ9UvipG8MN5eIIVD1lZ3WIKcj+5v7oHDC
 b/TLTBQV2mpiN4nqRA/CG81R4GVn71Z2yJtbLj6Ell8JUYPOdL7ei60SFolOwUhmobIo/8t8c
 JKUMs=
X-Rspamd-Queue-Id: 4MV7mJ0yzFz3xRJ
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b="HLa/UfmV";
	dmarc=pass (policy=none) header.from=gmx.de;
	spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.17.20 as permitted sender) smtp.mailfrom=garyj@gmx.de
X-Spamd-Result: default: False [-4.27 / 15.00];
	DWL_DNSWL_LOW(-1.00)[gmx.net:dkim];
	NEURAL_HAM_SHORT(-0.98)[-0.984];
	NEURAL_HAM_MEDIUM(-0.88)[-0.879];
	DMARC_POLICY_ALLOW(-0.50)[gmx.de,none];
	NEURAL_HAM_LONG(-0.30)[-0.305];
	R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27:c];
	R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450];
	RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.20:from];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_REPLYTO(0.00)[gmx.de];
	RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.20:from];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	HAS_REPLYTO(0.00)[garyj@gmx.de];
	ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE];
	FREEMAIL_ENVFROM(0.00)[gmx.de];
	FREEMAIL_FROM(0.00)[gmx.de];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[gmx.net:+];
	FREEMAIL_TO(0.00)[gmail.com];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, 17 Sep 2022 12:46:36 +0200
Mateusz Guzik  wrote:

> fixed in https://cgit.freebsd.org/src/commit/?id=3Db77bdfdb67c2e9660658a=
0373662e4263a905e90
>
> On 9/17/22, Gary Jennejohn  wrote:
> > Compiling vfs_lookup.c now fails when NONINVARIANTS is not included in
> > the kernel config file because NDVALIDATE is defined as NDVALIDATE_imp=
l,
> > which itself is only defined when NONINVARIANTS is also defined.
> >
> > This breaks buildkernel.
> >

Thanks!

=2D-
Gary Jennejohn

From nobody Sat Sep 17 13:28:44 2022
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 4MVBbg29Zlz4cpsB
	for ; Sat, 17 Sep 2022 13:28:47 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MVBbf0Ljgz49vw
	for ; Sat, 17 Sep 2022 13:28:45 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 28HDSipm086652
	for ; Sat, 17 Sep 2022 13:28:44 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 28HDSiAB086651
	for current@freebsd.org; Sat, 17 Sep 2022 06:28:44 -0700 (PDT)
	(envelope-from david)
Date: Sat, 17 Sep 2022 06:28:44 -0700
From: David Wolfskill 
To: current@freebsd.org
Subject: panic after update from main-n258027-c9baa974717a to
 main-n258075-5b5b7e2ca2fa
Message-ID: 
Reply-To: current@freebsd.org
Mail-Followup-To: current@freebsd.org
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="X5zzPCptBDPJDaA8"
Content-Disposition: inline
X-Rspamd-Queue-Id: 4MVBbf0Ljgz49vw
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-0.38 / 15.00];
	REPLYTO_EQ_TO_ADDR(5.00)[];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	NEURAL_HAM_MEDIUM(-0.99)[-0.986];
	R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	DMARC_NA(0.00)[catwhisker.org];
	R_DKIM_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[david];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	HAS_REPLYTO(0.00)[current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


--X5zzPCptBDPJDaA8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Not reproducible on reboot; only happened on one machine (main laptop)
out of 3 that I updated this morning.  No dump. :-/

A screenshot, a copy of the full dmesg.boot from the
immediately-following successful (verbose) boot, and a copy of the
uname output:

FreeBSD 14.0-CURRENT #589 main-n258075-5b5b7e2ca2fa: Sat Sep 17 12:22:57 UT=
C 2022     root@g1-70.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys=
/CANARY amd64 1400068 1400068

may be found at https://www.catwhisker.org/~david/FreeBSD/head/n258075/

The screenshot includes a backtrace; a hand-transcription:

Trying to mount root from ufs:/dev/ada0s4a [rw]...
panic: Assertion _ndp->ni_cnd.cn_pnbuf !=3D NULL failed at /usr/src/sys/ker=
n/vfs_mountroot.c:731
cpuid =3D 1
time =3D 2
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff804b9dfb =3D db_trace_self_wrapper+0x2=
b/frame 0xfffffe0fba5d4af0
vpanic() at 0xffffffff80bd90f1 =3D vpanic+0x151/frame 0xfffffe0fba5d4b40
panic() at 0xffffffff80bd8ec3 =3D panic+0x43/frame 0xfffffe0fba5d4ba0
parse_mount_dev_present() at 0xffffffff80cc7f76 =3D parse_mount_dev_present=
+0x116/frame 0xfffffe0fba5d4c90
parse_mount() at 0xffffffff80cc7c49 =3D parse_mount+0x5c9/frame 0xfffffe0fb=
a5d4d00
vfs_mountroot() at 0xffffffff80cc60c3 =3D vfs_mountroot+0x7c3/frame 0xfffff=
e0fba5d4e60
start_init() at 0xffffffff80b60093 =3D start_init+0x23/frame 0xfffffe0fba5d=
4ef0
fork_exit() at 0xffffffff80b8f770 =3D fork_exit+0x80/frame 0xfffffe0fba5d4f=
30
fork_trampoline() at 0xffffffff810c264e =3D fork_trampoline+0xe/frame 0xfff=
ffe0fba5d4f30
--- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 ---
KDB: enter: panic
[ thread pid 1 tid 100002 ]
Stopped at	0xffffffff80c26ac2 =3D kdb_enter+0x32:	movq	$0,0x12ab643(%rip)
db>=20



For all I know, the machine may be a little flaky -- it is the
oldest of the 3.  But I thought it might be worth mentioning.

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
"In my administration, I'm going to enforce all laws concerning the
protection of classified information. No one will be above the law."
 -- D. Trump, August, 2016

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--X5zzPCptBDPJDaA8
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYyXLjF8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1NT0AP9yOtXm/FqxHAIuORBC6EGMC/lHF8Q/B4dfbWGM7iafdQEAtlK5aVcequ1Z
vALlHpaGRL5Nii+zqMncK65h7aS3eQY=
=Gyz6
-----END PGP SIGNATURE-----

--X5zzPCptBDPJDaA8--

From nobody Sat Sep 17 13:34:42 2022
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 4MVBkX5pyFz4cqkt
	for ; Sat, 17 Sep 2022 13:34:44 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MVBkX1HwFz3D34
	for ; Sat, 17 Sep 2022 13:34:44 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: by mail-ot1-x336.google.com with SMTP id r13-20020a056830418d00b0065601df69c0so11367909otu.7
        for ; Sat, 17 Sep 2022 06:34:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:references:in-reply-to:mime-version
         :from:to:cc:subject:date;
        bh=xBfHwr447PinBcvfmkJX6lVv7YrGc4B9dcY6VKC4EYs=;
        b=kffV6Y/oCJnkszps3NmsBX1BskipwIEpS1/5rCe+c+EprpGu4jBorY6ZV43xr1OoAH
         y5s6IMR5wkLBCKgrtAtT0Goj32m6svYZyMco+vijWHv1qsoS9mfm+/oFCK6ThMDfE+Ly
         JCsDH13kf05nZA89gHawT/RFHjzmeOTFd8dAlx1QzKx+I1Z4N8d40HZiUiEzWQyrIMPD
         Nqa3CRE1AlFjIU0QIvGWD0KGS1a1yyr+geu+I5NeNaQvQYT93C2ukpHceY6d1NV+b9Q3
         Q7CVWej9n4NKr40Vl+clFv+e026SUqUoFeGBHNYq8chpT92mCFY2vkKzb0bR6Cpc4W1+
         1lsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:references:in-reply-to:mime-version
         :x-gm-message-state:from:to:cc:subject:date;
        bh=xBfHwr447PinBcvfmkJX6lVv7YrGc4B9dcY6VKC4EYs=;
        b=gVw/q/ZMb0DDlaE2xpv6Y2jK96+IfbWA00OlS/A7IywshJy7BS4uDGmmhZg59BZ/Mv
         f5LkWYRsG52aQ5fm1QzmV/o6LygxstmqKQxgZJJegoN/PWWh+S4koE7WTGvj1qtUx1Fj
         x4kxp2V+uLRe3BIukla1JaS/enisvtmhWjoWkjcMhHLtFGjxCdyB4u1HOCMN++dj5l1S
         LfCj1WDDRTo4VOqT54rqptHXFnyW+zCp96uYTeK+Je3FT0LgCUymjBWAyt1pZz/YJEnx
         NEmqji7kP07jTeV4Uj2vFuBAbTNjdO2cwdrlwKMA6UhLnVZAnHjFPc2/xToMv76oDCRh
         9tyQ==
X-Gm-Message-State: ACrzQf3dALdFTfYbs4xLLRMRlJQ5iug4q2dzTNukNlTAF2oVvXokyKIY
	sOZ5Rj/a500mNjWfNPXUsKHg/gk+RRNbkOHQ5kLkUg/Z
X-Google-Smtp-Source: AMsMyM6ppptx1zpvSectBAOE8J5NKY3jra4AOi1xQLu4XGdJ9+ykjMjmI9H0P7Uy8yXOC3D7Svi9CNM7sDd4gFpjmgI=
X-Received: by 2002:a9d:19a3:0:b0:658:8ff0:54a2 with SMTP id
 k32-20020a9d19a3000000b006588ff054a2mr4334956otk.281.1663421683427; Sat, 17
 Sep 2022 06:34:43 -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
Received: by 2002:a8a:352:0:b0:474:267f:5338 with HTTP; Sat, 17 Sep 2022
 06:34:42 -0700 (PDT)
In-Reply-To: 
References: 
From: Mateusz Guzik 
Date: Sat, 17 Sep 2022 15:34:42 +0200
Message-ID: 
Subject: Re: panic after update from main-n258027-c9baa974717a to main-n258075-5b5b7e2ca2fa
To: current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MVBkX1HwFz3D34
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="kffV6Y/o";
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2607:f8b0:4864:20::336 as permitted sender) smtp.mailfrom=mjguzik@gmail.com
X-Spamd-Result: default: False [-3.27 / 15.00];
	NEURAL_HAM_SHORT(-0.99)[-0.987];
	NEURAL_HAM_LONG(-0.98)[-0.975];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	NEURAL_HAM_MEDIUM(-0.31)[-0.309];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::336:from];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

this is already fixed, please update

On 9/17/22, David Wolfskill  wrote:
> Not reproducible on reboot; only happened on one machine (main laptop)
> out of 3 that I updated this morning.  No dump. :-/
>
> A screenshot, a copy of the full dmesg.boot from the
> immediately-following successful (verbose) boot, and a copy of the
> uname output:
>
> FreeBSD 14.0-CURRENT #589 main-n258075-5b5b7e2ca2fa: Sat Sep 17 12:22:57 UTC
> 2022
> root@g1-70.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> amd64 1400068 1400068
>
> may be found at https://www.catwhisker.org/~david/FreeBSD/head/n258075/
>
> The screenshot includes a backtrace; a hand-transcription:
>
> Trying to mount root from ufs:/dev/ada0s4a [rw]...
> panic: Assertion _ndp->ni_cnd.cn_pnbuf != NULL failed at
> /usr/src/sys/kern/vfs_mountroot.c:731
> cpuid = 1
> time = 2
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0xffffffff804b9dfb =
> db_trace_self_wrapper+0x2b/frame 0xfffffe0fba5d4af0
> vpanic() at 0xffffffff80bd90f1 = vpanic+0x151/frame 0xfffffe0fba5d4b40
> panic() at 0xffffffff80bd8ec3 = panic+0x43/frame 0xfffffe0fba5d4ba0
> parse_mount_dev_present() at 0xffffffff80cc7f76 =
> parse_mount_dev_present+0x116/frame 0xfffffe0fba5d4c90
> parse_mount() at 0xffffffff80cc7c49 = parse_mount+0x5c9/frame
> 0xfffffe0fba5d4d00
> vfs_mountroot() at 0xffffffff80cc60c3 = vfs_mountroot+0x7c3/frame
> 0xfffffe0fba5d4e60
> start_init() at 0xffffffff80b60093 = start_init+0x23/frame
> 0xfffffe0fba5d4ef0
> fork_exit() at 0xffffffff80b8f770 = fork_exit+0x80/frame 0xfffffe0fba5d4f30
> fork_trampoline() at 0xffffffff810c264e = fork_trampoline+0xe/frame
> 0xfffffe0fba5d4f30
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
> [ thread pid 1 tid 100002 ]
> Stopped at	0xffffffff80c26ac2 = kdb_enter+0x32:	movq	$0,0x12ab643(%rip)
> db>
>
>
>
> For all I know, the machine may be a little flaky -- it is the
> oldest of the 3.  But I thought it might be worth mentioning.
>
> Peace,
> david
> --
> David H. Wolfskill                              david@catwhisker.org
> "In my administration, I'm going to enforce all laws concerning the
> protection of classified information. No one will be above the law."
>  -- D. Trump, August, 2016
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>


-- 
Mateusz Guzik 

From nobody Sun Sep 18 11:50:07 2022
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 4MVmMY5Zvkz4csR4
	for ; Sun, 18 Sep 2022 11:50:17 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2107.outbound.protection.outlook.com [40.92.97.107])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MVmMX6k4dz44g6
	for ; Sun, 18 Sep 2022 11:50:16 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=C4niQJBab5dOp01/FRSIPgTH0sNuGPqxUzECB0xVKVzETK/4Q9rG7e7wQ1jzUqJ/xLG/OgneIofh37hUr8pUIAnxTh1mFP1NspO9mtUZvTkiT3xG8+DbMG83FjHCKsWPOeCCQ/g2p778Wo66Lshv3BIimI2ZAe1cFlkAadGDIo7wQxjKF/QSfF90CZMLQqABmFR6qWqbwsw3dTAKL60Q8Rnae32zIKc8HNjMYVKIhvArubBMUbPdTYHwVusAURRVRflfE9O2711lkJ3kOMTwq9xLQl5l53rDQtoGuQxtjqQzrJW8m7fn4RfjvL54q7hbgE3UVcV26vsNAinao6hoog==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=8J785LkGkqORPv+08EMazbK+ZkDI6SrfR9FdIwi8wvo=;
 b=Zywn1SH41Sq0MgnRO4KtIYRT+udVrB7ViaIkcAI72gSxTunt0Q0ObyWaUBPuux0WiO+0qzO+dmNn8oEdNoeuAGGfDHOFNjJ/jz0C7u8D+90gxndZJLe93DebKdnnDzARs9FLlRPP3Nb3smpNCAe0jZqtyYciCTQohxUDEOFY4ZioKwAQcHv0AOwtaLnYx330ydJXZcshmue1vsWGJgAWTTcrKIvNuAn0gqLmL7+Be9hLWUTuTvysjXR603z0QzpK80LvsDwgITQxLAlOlr3W0qYTv2R8pD9FZXgPrXDUjZbzoE/aE1EpqAuvy4/XdQuI/MidU0RiUELexpLN0bKnHg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=8J785LkGkqORPv+08EMazbK+ZkDI6SrfR9FdIwi8wvo=;
 b=Ry7HEKkZ0yRPsUXiq/PvhIGJwwulqvAGQ12RGNjuMTU7F1RcC+rBEHCnXJuXzInS+BO0jE2a6I6dxayLmYSqsYanXszziUHTltNtOUDSYE0cr6NKrAEQntKykcVJcfmG/6bNutE4WmMCYV1CHoQfvdhXbpnmFOq4P91opk3zYNrU9FNnn9RXDETiVYSTAzrf2rbHtKgKEBr+E58cw2I7IbVTKjzaU/+0Zm1NI3Glfk341PBzzDcfN96nTr9OaccM8mgkIObSght5fsU+1q7rtKmYjoMmtdn/xVPl0Z7e+bhDYMp+6uW+4mvYVum2sAuacelkOEUstUD2Gxd3QQ6cvQ==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by ROAP284MB0143.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:3c::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.16; Sun, 18 Sep
 2022 11:50:12 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::81cf:90c7:6a5d:63bb]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::81cf:90c7:6a5d:63bb%5]) with mapi id 15.20.5632.017; Sun, 18 Sep 2022
 11:50:12 +0000
Date: Sun, 18 Sep 2022 08:50:07 -0300 (-03)
From: Ivan Quitschal 
To: Ivan Quitschal 
cc: Hans Petter Selasky , 
    "freebsd-current@freebsd.org" 
Subject: Re: RES: TP-LINK USB no carrier after speed test
In-Reply-To: 
Message-ID:
 
References:  <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org> <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org> 
   <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org> <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
  <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>  <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
Content-Type: multipart/mixed; boundary="3432851520-1708053192-1663501811=:1771"
X-TMN: [1WrfwDWjBlFJIjQ66hLfbbmbLjdMOHc/]
X-ClientProxiedBy: CPYP284CA0032.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:69::19) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <939e71fd-1311-5eca-7527-f4dbfe55e8e@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|ROAP284MB0143:EE_
X-MS-Office365-Filtering-Correlation-Id: 824b2594-587c-4b81-56b1-08da996bf16e
X-MS-Exchange-SLBlob-MailProps:
	q3cIJLDN2c/UwBD+dPvUl+TRcNVRU6IENAiALoNTy46fB2VUgQft2gn4bda5BYH5XYf840LZlo0N3qYgNhhtKbD40ThrS4Cq4Ocw+VpU5hWgQp4C3oeq+FUrBDL8STde8EPYTcSfsosY+FrxR2hHA6Myve9kzAn1zUzPVOiUKHbi/lpznna8qEFbD0DJiCR1vD6qFENSfYO+Fs/jo3Y3Wv+Ogo39C9nBgG1y50ZTiK05ienl/R/LzfCF83fmMHzZH+5SlU4+h9Xg7pzVsc5EUAw6JHPYjmtE1/n+53zDrJZq2R3J7ZBlvK8CwappsVCusF0lsjBK4qfz74rSepxkUyGwymyg0qX8Ta4PEJbx4Cvs9zF/WQIUloDmZjDAEEeYtZ/fZBhIycDxkkXtAhfFQFj19bSdnhHYNc10YJ8Uts8lFCzGgjhnn7gWA6IkKueFBLbWyu9AC+dY29KHxon/rzNox+cLCFb1Ddtt7rZT/69gpDOvviTMdaFtYzALpUbYUJMoHTVmrbRQkZdDBgSq6jRq7zE4R0CKA2GBPb/73VThezWTStGuX83777GLeXeysHEHG2YV7gpSVY6mq/F4kTDHtG68tZGqXUVOk+i/AFPT/0QHOwuYWAIxit0fiKYDar8nsL/r1FzJrWqMCKd6WHlW2Mb06mva4AB8GQv2aiLuAfjBKcsDltnYHS92o41L
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	vJrER9UBa+OxoXVFbnTPGcEU5b9NAlWHaoeGyTQc6GbfNxZC9LfIjO42VSHYuxsyv9N4mAf/lYiptchrUnymk0UuLFQwZaOZ765JIMuzJOI9KkRztedVY2DbifZ04NSMIyxXSzkQ6hZBFa0XuZkO6rM+F7SgRy71eQddxsR7Z8on9cq0QzykykQmmR42Qb+dcYJF7IDLxKw8jdLgWTFG8ywAE0pj3hg3qhlsuG6S6I/zVql8AMLjgNceIlIH9OltFNL1AvLDyCMQmJlGfP0e/oN6z+/sNtgJHqbrztZtWqrx1UQ3P2HfDotgniSgpqNN/gGqtAI56HlVzhVvWZyJZtH/OtFumbomAWEmbRRa9qe4Xxex5j5iYjL6rA5LyQkjhrgEFTcT2r968rtIvHdJPvwKsTb8n4UBivqxHm71wI+xC6gtnUR31jZziCKl09fypa/Dp/BmW86ZXEFQ+WdSzSigJnjcgs0x0SiPn9Ixx2meSTUxEhhz/MB5poD9oyVN8XdNRcxRnfCgmj6c4n/Uwf/rqcf7yqmNkj/lU5tItG5MedukzpVgXfCYUBJ+giHxNZGsOS40oX/KU6TWZnhMWsqMQhhd6K0lj+1YPsH82gblH/zDunXmfPy+8meNuXFRf3XuOBpo6xgbR4DMs9XyV7CglncJREJKfbBUBs3u37KzVDjwsBL7k/+rloLaiUTt
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Z0dncTJKdlYzWGZhK1ZzRUMzVVMyR3Z6S0tySW96eCtobUpCUFFDcWVZZ0dH?=
 =?utf-8?B?b0NwbjB0SEhCQyswc3ZIUkJzc3ZOek1MRU1sOTM5VmZEb1IrVzl4REg2c1lm?=
 =?utf-8?B?NHRGMDFOV3pFakJZRkVMdVNqZmkwQVpITUxkaUdKTHpZMjhzMnNpSGEvdldx?=
 =?utf-8?B?cGVjN0JUUXpqM2MvM1BoN3hPbXJJVmlvcnMwTWdWWmJlc3lKU25yZktwdTNR?=
 =?utf-8?B?eTV4WGJ6cmRjZEFoSExrNnVCM3JoKzhjbmNObmQ2dVphM2tYODd0YXV5cVhV?=
 =?utf-8?B?QSswdEhJM1JIRmNKNnVGMWJlS09CZDdQWm52cTFLdkVwUUFKUjc3TTRnOWFa?=
 =?utf-8?B?V1JoaVE5SklaNWdseVJtMjVmdk80dWZOZHRDTlNTTjloQUMvY29lRGgraGI3?=
 =?utf-8?B?M1dYUE0xQkpQbTFUbXBOVXZ0VWhiN2E5MEhDc2NrQUhaeXNxZk14cjkydkxm?=
 =?utf-8?B?b2UyWk1XYkNVV3pQb3dmc0pBaHJYZlR1cTRTRm1GTmNJelY1cjg4QnhPbGNO?=
 =?utf-8?B?Nng3WlZuQzFjUmEvdkRZZjRuOTRBZm9hWUtOUXVHQmpLSkVtVUkrQlVxMWVo?=
 =?utf-8?B?bElER3VZRDBHQzFqZHNwaW0wYjlGK3cvYjdPeXJ4ZFpOSlJ0N0pkYnIzQWR0?=
 =?utf-8?B?U3ZiU0RJbWlkdFhFUUNJdi96MGJkRG9EUTFrUGd0c2hWeG4xRTdCMStPajVP?=
 =?utf-8?B?VWMxQ2dYQ1Q0Z0ZDa3N1RU1Fb0FESEw4YnRrazNJRjhkcXc5MGRaRGNPbTcv?=
 =?utf-8?B?aERpTkRIZ3RFUnpKUkdMbWhGTWs1eldRZ2xjSG1IT29IcWF3eWRwWFl2aWJO?=
 =?utf-8?B?d2F2b2xaZVZuRWFyeEZrUkN1aTFwV0dKcmZZVXBBQ0QzcG1lcUdQbUQ0aUxi?=
 =?utf-8?B?VStaUUtSTlRBT2lPUnZVcGZkOXZuTHdhUVBaTVovcHdqa0pZaHEyTWhoNVQy?=
 =?utf-8?B?SG9MOTZkbXlTQnkvK01ERFFsWGhHUHNOVVFYQVlLalRGUFJCMmpoUG1CQlFP?=
 =?utf-8?B?RzRCdkh0eXQ3YWw5U1hBemI5clJyOWViNFlibzQrMk5mSVB6RCtKcXRabmNV?=
 =?utf-8?B?bWFsNm1aRVJnMUlnZVoyaWZLc0RSUU4xS053b1lCbU5UcUN4OU5SV1IvM1Fa?=
 =?utf-8?B?ajBGVGtOZ0hKakxqcHIzRHc2NUd6ZncwK2RqaUZqYThMeW4wbzdoejk2Q0tC?=
 =?utf-8?B?bkVZU2I1UTgrY3ZFL1NMc0dPdWZTdkRBaTVVcE9aVXU1VkkzNWhCbWt3bVhZ?=
 =?utf-8?B?My9JdU10TVVlNzFIakg3SjhabDAyejhpdkRzcTNHN0dEMGNlY0F4NTJkMEIv?=
 =?utf-8?B?ajh4dnVLZmlRWGxVMXZ6Y1dncUdsaFF0dDArZVpmczVxVkU4aDU5b3ZWNjlr?=
 =?utf-8?B?cjRQTXU4Wm94REkxRGgzbno4YXQzM2lyMDl6WXRBdjJtdUxYbFZiTjJCWDhY?=
 =?utf-8?B?d29wZ2d2L3VVeWk4Z3VuMEZLMHZTeU52S0NrOFdpM29kMXJxZEFFQjJzNnE2?=
 =?utf-8?B?YUE1dFp3SUpObmpnQzIrcE5XMGp0dkdwR1cyTjJyZm10VWRaQzZ1c2NiT1E1?=
 =?utf-8?B?N1RWa2dzV2JnTmFHWE1ab0lqbitxeGN0SFVqaUhhUzcwSGh4dUNTM0JKV2ZS?=
 =?utf-8?B?a2VYSEZBK2UvVTVycGJUd2xuVFJYZ3U0NExTT0lzMFFoOTFvY1ZXSitScFlK?=
 =?utf-8?B?dUFyTCs2alRTUXUvRmliSUpUclR4QXVpODZyTERiKzlEWVFic2VtanZ3PT0=?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 824b2594-587c-4b81-56b1-08da996bf16e
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2022 11:50:12.8684
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB0143
X-Rspamd-Queue-Id: 4MVmMX6k4dz44g6
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=Ry7HEKkZ;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.107 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-2.98 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	CTYPE_MIXED_BOGUS(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	NEURAL_HAM_MEDIUM(-0.76)[-0.764];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	NEURAL_HAM_LONG(-0.22)[-0.216];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.107:from];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[hotmail.com];
	MIME_TRACE(0.00)[0:+,1:+];
	RCVD_TLS_LAST(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.97.107:from]
X-ThisMailContainsUnwantedMimeParts: N

--3432851520-1708053192-1663501811=:1771
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT



On Fri, 16 Sep 2022, Ivan Quitschal wrote:

>
>
> On Fri, 16 Sep 2022, Hans Petter Selasky wrote:
>
>> On 9/16/22 16:31, Ivan Quitschal wrote:
>>> 
>>> 
>>>> -----Mensagem original-----
>>>> De: Hans Petter Selasky 
>>>> Enviada em: sexta-feira, 16 de setembro de 2022 10:40
>>>> Para: Ivan Quitschal 
>>>> Cc: freebsd-current@freebsd.org
>>>> Assunto: Re: TP-LINK USB no carrier after speed test
>>>> 
>>>> On 9/16/22 14:18, Ivan Quitschal wrote:
>>>>> 
>>>>> 
>>>>> On Fri, 16 Sep 2022, Hans Petter Selasky wrote:
>>>>> 
>>>>>> On 9/16/22 08:34, Hans Petter Selasky wrote:
>>>>>>> On 9/16/22 08:20, Hans Petter Selasky wrote:
>>>>>>>> On 9/15/22 17:36, Ivan Quitschal wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Thu, 15 Sep 2022, Ivan Quitschal wrote:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Thu, 15 Sep 2022, Hans Petter Selasky wrote:
>>>>>>>>>> 
>>>>>>>>>>> On 9/15/22 17:18, Hans Petter Selasky wrote:
>>>>>>>>>>>> On 9/15/22 17:16, Ivan Quitschal wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Does anybody have any idea what could be happening here?.
>>>>>>>>>>>>> I have a laptop DELL INSPIRON 3511 and everything works just
>>>>>>>>>>>>> fine, literally everything. even the iwlwifi0.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> But in order to use my full 600mbps, i dont use the wireless
>>>>>>>>>>>>> but a TP-LINK USB ethernet connected on "ue0"
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ugen0.6:  at usbus0, cfg=0
>>>>>>>>>>>>> md=HOST spd=HIGH (480Mbps) pwr=ON (200mA)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> but something really strange is happening .. everytime i open
>>>>>>>>>>>>> the chromium e do a speedtest (could be speedtest.net or any
>>>>>>>>>>>>> other) , at the end of the test the eth interface dies .. it
>>>>>>>>>>>>> changes from full-duplex to half-duplex/no carrier and the
>>>>>>>>>>>>> only way to get the internet back thru ue0 is by rebooting the
>>>>>>>>>>>>> whole thing.
>>>>>>>>>>>>> not even a "service netif restart" does anything
>>>>>>>>>>>>> 
>>>>>>>>>>>>> if anyone has any ideas why is that , would be appreciated
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> 
>>>>>>>>>>>> I think it some new features they use in the USB data protocol
>>>>>>>>>>>> which we don't support. Check the Linux code.
>>>>>>>>>>>> 
>>>>>>>>>>>> Between does:
>>>>>>>>>>>> 
>>>>>>>>>>>> usbconfig -d 0.6 reset
>>>>>>>>>>>> 
>>>>>>>>>>>> recover the device?
>>>>>>>>>>>> 
>>>>>>>>>>>> --HPS
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> Search for axge on bugzilla:
>>>>>>>>>>> 
>>>>>>>>>>> I suspect you are using this chipset:
>>>>>>>>>>> 
>>>>>>>>>>> Try:
>>>>>>>>>>> 
>>>>>>>>>>> usbconfig show_ifdrv
>>>>>>>>>>> 
>>>>>>>>>>> To know for sure.
>>>>>>>>>>> 
>>>>>>>>>>> Also see:
>>>>>>>>>>> 
>>>>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%
>>>>>>>>>>> 
>>>> 2Fbugs.freebsd.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D210488&d
>>>>>>>>>>> 
>>>> ata=05%7C01%7C%7C7d0b875611fa4c22aa6808da97e8f75a%7C84df9e7fe9f6
>>>>>>>>>>> 
>>>> 40afb435aaaaaaaaaaaa%7C1%7C0%7C637989324107373931%7CUnknown%7C
>>>> TW
>>>>>>>>>>> 
>>>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
>>>>>>>>>>> 
>>>> JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=o%2B12TNKJ4bcBBj1b4r4TT
>>>> 1f
>>>>>>>>>>> xyEalCMDMjOepy3MZm5c%3D&reserved=0
>>>>>>>>>>> 
>>>>>>>>>>> --HPS
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Hi Hans,
>>>>>>>>>> 
>>>>>>>>>> actually the driver i use is not agxe (i thought it would be by
>>>>>>>>>> the time i bought the usbcard)
>>>>>>>>>> 
>>>>>>>>>> this is the module im using
>>>>>>>>>> 
>>>>>>>>>> if_ure.ko
>>>>>>>>>> 
>>>>>>>>>> and thank you , yes, reseting the usb entry with your command
>>>>>>>>>> worked just fine.
>>>>>>>>>> i got the internet back after doing this
>>>>>>>>>> 
>>>>>>>>>> usbconfig -d 0.6 reset
>>>>>>>>>> 
>>>>>>>>>> do we have a bug here then?
>>>>>>>>>> 
>>>>>>>>>> thank you
>>>>>>>>>> 
>>>>>>>>>> --tzk
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> oh, i forgot to mention that the ure driver freezes not during the
>>>>>>>>> download test but in the middle of the upload, always
>>>>>>>>> 
>>>>>>>>> dont know if that helps
>>>>>>>>> 
>>>>>>>>> thanks
>>>>>>>>> 
>>>>>>>>> --tzk
>>>>>>>> 
>>>>>>>> Hi Ivan,
>>>>>>>> 
>>>>>>>> Yes, there seems to be problem there. I need to look at the driver.
>>>>>>>> Maybe it is simply sending too much data, than the device can handle!
>>>>>>>> 
>>>>>>>> --HPS
>>>>>>>> 
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Try lowering this constant to 8192:
>>>>>>> 
>>>>>>> sys/dev/usb/net/if_urereg.h:#define    URE_TX_BUFSZ        16384
>>>>>>> 
>>>>>>> Then recompile and install if_ure:
>>>>>>> 
>>>>>>> make -C sys/modules/usb/ure KMODDIR=/boot/kernel all install
>>>>>>> 
>>>>>>> --HPS
>>>>>>> 
>>>>>> 
>>>>>> You can also try other values, like subtracting one.
>>>>>> 
>>>>>> --HPS
>>>>>> 
>>>>> 
>>>>> 
>>>>> hi Hans,
>>>>> 
>>>>> it worked but with a cost.
>>>>> 
>>>>> i tried 8192 and it works 5 tests (5 speed tests in a row). freezes on
>>>>> the 6th.
>>>>> 
>>>>> then i tried 4096 no success
>>>>> 
>>>>> then i tried bufsize 2048 and its working now, i did several tests in
>>>>> a row and the internet keeps working just fine. but i noticed that the
>>>>> speed also dropped.
>>>>> 
>>>>> with the same server , testing on windows, it goes like:
>>>>> 600 download / 300 upload
>>>>> 
>>>>> and on freebsd with 2048 bufsiz it goes like:
>>>>> 300 download / 150 upload
>>>>> 
>>>>> 
>>>>> so it worked with a cost like i said, i had to give up half of my
>>>>> bandwitch
>>>>> 
>>>>> what do you think ?
>>>>> 
>>>>> and thank you again
>>>>> 
>>>>> --tzk
>>>> 
>>>> Hi,
>>>> 
>>>> Can you try this instead:
>>>> 
>>>> usbconfig -d X.Y set_config 1
>>>> 
>>>> X.Y are the numbers after ugenX.Y
>>>> 
>>>> Then it will use a different driver.
>>>> 
>>>> --HPS
>>> 
>>> Hi Hans,
>>> 
>>> After the usbconfig -d X.Y set_config 1, the interface doesn't work 
>>> anymore, how can I undo this?
>>> 
>>> Thanks
>>> 
>>> Ivan
>>> 
>> 
>> usbconfig -d X.Y set_config 0
>> 
>> or
>> 
>> usbconfig -d X.Y reset
>> 
>> Did you check dmesg?
>> 
>> --HPS
>> 
>
> hi Hans,
>
> i had to reboot my router but i got my interface back running.
> and i have good news
> after that, im still using the buffersiz 2048 and this time i got 600mbps 
> download /300 upload just like that.
> these 2 things were not related i can see.
>
> i guess thats it , looks like its solved.. i will keep monitoring here , but 
> so far so good
>
> thank you a lot as always
>
> --tzk
>

Hi Hans

just a heads up, it worked, tested a thousand times and the problem does not 
occur anylonger after i changed the constant to 2048

but upload speed was affcted a little i believe.
insted of 600/300 of internet speed , im having 600/90

but thats fine, way better now.

should this bug be in bugzilla for this ure driver as well wehave for axge?

thanks

--tzk

--3432851520-1708053192-1663501811=:1771--

From nobody Mon Sep 19 16:37:52 2022
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 4MWVj6398Fz4dLNJ;
	Mon, 19 Sep 2022 16:38:02 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MWVj53tkFz3cwB;
	Mon, 19 Sep 2022 16:38:01 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 7C29A2605DD;
	Mon, 19 Sep 2022 18:37:53 +0200 (CEST)
Message-ID: 
Date: Mon, 19 Sep 2022 18:37:52 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: RES: TP-LINK USB no carrier after speed test
Content-Language: en-US
To: Ivan Quitschal 
Cc: "freebsd-current@freebsd.org" ,
 "freebsd-usb@FreeBSD.org" 
References: 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
 <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MWVj53tkFz3cwB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.25 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	NEURAL_HAM_MEDIUM(-0.95)[-0.952];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	FREEMAIL_TO(0.00)[hotmail.com];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[selasky.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/18/22 13:50, Ivan Quitschal wrote:
> Hi Hans
> 
> just a heads up, it worked, tested a thousand times and the problem does 
> not occur anylonger after i changed the constant to 2048
> 
> but upload speed was affcted a little i believe.
> insted of 600/300 of internet speed , im having 600/90
> 
> but thats fine, way better now.
> 
> should this bug be in bugzilla for this ure driver as well wehave for axge?
> 
> thanks
> 
> --tzk

Hi Ivan,

I got one of those if_ure adapters at my hand, and will test it a bit 
before concluding. Stay tuned and thanks for your testing efforts!

--HPS

From nobody Mon Sep 19 20:19:09 2022
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 4MWbcM40wFz4cjlX
	for ; Mon, 19 Sep 2022 20:19:15 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MWbcK0zdqz3ww6
	for ; Mon, 19 Sep 2022 20:19:13 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.165] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id F0C612606D1;
	Mon, 19 Sep 2022 22:19:10 +0200 (CEST)
Content-Type: multipart/mixed; boundary="------------S23e54ZH7iidwiK6QXlRf5x9"
Message-ID: 
Date: Mon, 19 Sep 2022 22:19:09 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: RES: TP-LINK USB no carrier after speed test
To: Ivan Quitschal 
Cc: "freebsd-current@freebsd.org" 
References: 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
 <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
Content-Language: en-US
From: Hans Petter Selasky 
In-Reply-To: 
X-Rspamd-Queue-Id: 4MWbcK0zdqz3ww6
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-2.16 / 15.00];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	NEURAL_HAM_MEDIUM(-0.96)[-0.962];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_BASE64_TEXT(0.10)[];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_TO(0.00)[hotmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	HAS_ATTACHMENT(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------S23e54ZH7iidwiK6QXlRf5x9
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ivan,

Can you also test this USB kernel patch? And revert your if_ure.c patch?

--HPS
--------------S23e54ZH7iidwiK6QXlRf5x9
Content-Type: text/x-patch; charset=UTF-8; name="a.diff"
Content-Disposition: attachment; filename="a.diff"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3N5cy9kZXYvdXNiL3VzYl90cmFuc2Zlci5jIGIvc3lzL2Rldi91c2Iv
dXNiX3RyYW5zZmVyLmMKaW5kZXggMjBlZDJjODk3YWFjLi43NTc2OTc5MjYxMDYgMTAwNjQ0
Ci0tLSBhL3N5cy9kZXYvdXNiL3VzYl90cmFuc2Zlci5jCisrKyBiL3N5cy9kZXYvdXNiL3Vz
Yl90cmFuc2Zlci5jCkBAIC00MTksNiArNDE5LDcgQEAgdXNiZF9nZXRfbWF4X2ZyYW1lX2xl
bmd0aChjb25zdCBzdHJ1Y3QgdXNiX2VuZHBvaW50X2Rlc2NyaXB0b3IgKmVkZXNjLAogCiAJ
CXN3aXRjaCAodHlwZSkgewogCQljYXNlIFVFX0NPTlRST0w6CisJCWNhc2UgVUVfQlVMSzoK
IAkJCW1heF9wYWNrZXRfY291bnQgPSAxOwogCQkJYnJlYWs7CiAJCWNhc2UgVUVfSVNPQ0hS
T05PVVM6CkBAIC01MjksNiArNTMwLDcgQEAgdXNiZF90cmFuc2Zlcl9zZXR1cF9zdWIoc3Ry
dWN0IHVzYl9zZXR1cF9wYXJhbXMgKnBhcm0pCiAKIAkJc3dpdGNoICh0eXBlKSB7CiAJCWNh
c2UgVUVfQ09OVFJPTDoKKwkJY2FzZSBVRV9CVUxLOgogCQkJeGZlci0+bWF4X3BhY2tldF9j
b3VudCA9IDE7CiAJCQlicmVhazsKIAkJY2FzZSBVRV9JU09DSFJPTk9VUzoK

--------------S23e54ZH7iidwiK6QXlRf5x9--

From nobody Mon Sep 19 20:27:29 2022
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 4MWbnv33phz4clPX
	for ; Mon, 19 Sep 2022 20:27:31 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2051.outbound.protection.outlook.com [40.107.115.51])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MWbnt3DJ2z3yfl
	for ; Mon, 19 Sep 2022 20:27:30 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=QdvbhmgJRXXz4iBUtBjHR1XSA8ArD/UpEKi3pulkswsBw7l0Y54NYBmiMkoRr3gqqTD9QKCECDBjpvl/GzloffaPaMCO2cflPK8b6JZRUjgSPSQnyP3/lwIkIhknpoKmxwc7FLobqHiz0jVfyloiaLhsf6aEKhHTCw6c2U480CpqJkhFW1naK4ZobRcNSEZoLNs9WrPBnWCFsdTgoB7M8LCWdOQITmREaPG5Dy5h6lEx+rivAFB48f9dZSRN2JUPvNo0dddwBlWpGZBRurt3VvSHKNgJMrU0SgGvs4mCCBTXpkgOT+on3YxeRretT10WxizAC55Y/BE2T5kVWIIPRg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=P0dUWvPYrISPVF5e/8WXPnWsfgUI4uju6JE7GlTkTL8=;
 b=b4jyHWBb+ypxe7HF3lJ70sqr+GYjgex6tSHPHFWHijQTDiZ9nBiwBLG9eRSWGg6yJvGkEuZbvJAeBff4XW6Gr1u9oABq51gWKyMDI7e4iEv1RXaUuuWkhGmP6V9aCsXiWgC1zSjXq9+upagSWP7VyfVRpPk3+pkKvz6Aw1gfpkgc0ZRdpt2RDbC+NsrycVKXWZYvxzxDV3/KBxunccGbLw6H7an3XeRlpQzxW1wGiqm/nN/1gQc+uDBLGQBhAPZyAgbTal7vO1uHxJEUH5k5LmNTaM8udrzGwEoQTYhQDBlH78SnpDuV7ErPJX3kCifj1qN0Mt2q3NAFQ0ZX8zbrpg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca;
 dkim=pass header.d=uoguelph.ca; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=P0dUWvPYrISPVF5e/8WXPnWsfgUI4uju6JE7GlTkTL8=;
 b=IfqCujnrEXdCUMbuQLSmEsTJjM6BrRO02W9KU4G1Yvlyed3uQj3wrSlK8fGJZnoyjy0NezHCYs/RU65WW1CyPgfU4YyURq3zeAKY9/gWHxsDyziu7EiLFs5g89k+Y+47Lnkb2piNks7+J239oNUwpx1rhmvj7WQgzFODvuD6dFrj6i7AGucYjmZGbuVfiBlQoxfW2rVJ7mGnqYWj+kPdKoEiJV5wZTFP+RcRGmCpnxTMNYwCvjaxc2SoXDbp9/0zvrGGhk7Is6fHoSF6WLgIM0b6tCsc0go4MV0kyr6Jjq4m4yC+LTgzaA0vSs2YmLGbYH/deMMqkdlqxUjEcng0Uw==
Received: from YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:6::7) by
 YT1PR01MB9004.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:cf::15) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5632.15; Mon, 19 Sep 2022 20:27:29 +0000
Received: from YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::980d:23ea:9bc2:9f37]) by YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::980d:23ea:9bc2:9f37%9]) with mapi id 15.20.5632.021; Mon, 19 Sep 2022
 20:27:29 +0000
From: Rick Macklem 
To: freebsd-current 
Subject: domain names and internationalization?
Thread-Topic: domain names and internationalization?
Thread-Index: AQHYzGXJ7Fz67yTB+EqnzSr9KBXoDg==
Date: Mon, 19 Sep 2022 20:27:29 +0000
Message-ID:
 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: YQXPR01MB4150:EE_|YT1PR01MB9004:EE_
x-ms-office365-filtering-correlation-id: e8c094b4-056d-458a-61ac-08da9a7d5f89
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 VzwDCi0vPjJhgNw8wmFNdiKdCObW5EWgSUSwqftg6n44Kn+eaFS7tMfrpberbTHHT/F41gZOfC+u+DisdV64Kd+SONjprXqSmu0rDR7+kuRC2ZUQegjrwdmUiVJM1VgffK6/VvoV0EXASUl5qT7EvOPMNvUqJINRqXa3/C2XJnezjJcuOSpUV9Z2e5lAgyUHdlHH/rHzUloiYdwYXP8LwwhUcYHmsM6IAUu9jv5MkpfGan+6LzK7S2Ibu2bW+qaXaoxaSf+RUbGHDRRHbBB++dJ4OdE4C2ybjtp48e4dTqi9Kps+d5tXSukofVajDPy0xsSRuN5nCBr5ZI5YRoCCGRSCqs2GsyVG27EJLt4JCuvBsPj48/fcCj7DXbWDQldMYtPDKAEpKTZFeNujWFi/XxiukdUgbnQsCEHUkkESrk9C2XJo49MDWoD1xAOn0zsKaaSBZ3HqGVathtosD1ADUgSLOOSBoGhVZVYdP5QwxZpD9zIYQSKnjjD0LqQ+IbmS8WdDkBqq+QFKKpEcHqiJLBDUbCXJi0F6qsE6ECYIhKb6Kpc92yl9vTi2GBJV+8aL3owMS1CGp9A8ExeG+SvLxiFjUi7ukmxzec7yF9GPXcNmUuTf9lpXSLtLpqc7LeSF2L7vDizYnfrm9uOk+9QDhmeQOMsu2Yn6Mr1Ycp01GR1FIIZ+LrrdiK9ikFRjCn3wo/P9Ybp7AJEsXZgWCjc5QIlBjzscxnr2Gpzr3CtYn9HN5tbiuB/qO7+up3nNgN6WOc3P8d5q5mKeT75Fju5P3w==
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(366004)(136003)(346002)(376002)(39860400002)(396003)(451199015)(71200400001)(66476007)(122000001)(91956017)(33656002)(86362001)(41320700001)(38070700005)(55016003)(38100700002)(5660300002)(2906002)(478600001)(4744005)(66946007)(66556008)(64756008)(66446008)(52536014)(8936002)(76116006)(6916009)(786003)(8676002)(316002)(186003)(83380400001)(41300700001)(3480700007)(6506007)(7696005)(9686003);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?dslmICmJ3rFWn4YGXs0GSHJ4Mq7ICXc+iNHS2wVRlKMrELv2XSpwxPgU70?=
 =?iso-8859-1?Q?m52s/uH3WG/XqaVWM/TbiICguLnsyiLFbMfVQwuU+FRQm0eH46fZlPQ5Hc?=
 =?iso-8859-1?Q?tV/FZcqSTVMzngOq10WZmamZnXFRW95u3ZugHlV3ibz0xKZUH/SL03MJQb?=
 =?iso-8859-1?Q?KluRQqNISvZB3rcUbBwjD3GCCBya/+SD1OprsWGAk+csq+JSet2MtT/R74?=
 =?iso-8859-1?Q?7wo8OYPtrMHgM+qc7eyZpCCc5+90XiDp9gqgSdWGywt/J7hL/vEMmtvK9J?=
 =?iso-8859-1?Q?Bx7TAand8CfDbjtcofYGzQpC/4uf/ORGszueQPokeiz4dPQghNbptzvJVQ?=
 =?iso-8859-1?Q?0I2qvCUmqoCClpA3DMpPgF4Ic1HF+VYtikXAMYK6I2nfHN+c3W/4EhK+l2?=
 =?iso-8859-1?Q?AUgDWGjjwfZHmwUJeF3rMOTgapqvgF5I12QL9gslsSSWzs61nbXaVv+YiZ?=
 =?iso-8859-1?Q?dPMd8L0v2tbJCM7vJLFD2k+01G7S1h9FwhU/1l7CoJNLzNZeF/sAKBssJU?=
 =?iso-8859-1?Q?zNbXyDCeQe0iT/ruauDfVn8bzaJZYZjujENw+iKda4ib3ZBybb8U/E88wv?=
 =?iso-8859-1?Q?28mLgF/Sm8DDT31gX0MOc2io+jUhiIaiYrfia89wCNpQxoWytjIEk4FvLn?=
 =?iso-8859-1?Q?e6s456Bs6ndryovDhkLyFt6gySUJVAtzWCE+gVJTB1HcnN3O+60Zz07v/g?=
 =?iso-8859-1?Q?Ix/f1nt3fT8rTjj1ZFnVw27X9UzkWA8yzWR5yDJuOjveJG6K9VJ/Q2h790?=
 =?iso-8859-1?Q?TC/V5otLT3GG/Xdnx5MDzEcdWzxHVx+gbOhQNO0lwHzXTUGFw8uxq6elTl?=
 =?iso-8859-1?Q?f2MrBbZVRC7VRIM0GmMi1NySRp8yATKR1jTCP4GDrC0q41rzy/BJMP2rsm?=
 =?iso-8859-1?Q?JVT8Hcl+NW7ePr6W1a3yaANnxGqSVLPO9HHm69fRXt5qf+vPATkDRsw2iS?=
 =?iso-8859-1?Q?xKYRTqBkEThuvfHRGd2TC4aL8sBaKOia8CCvyxG0MRzzAa7WzeQ8opsqvi?=
 =?iso-8859-1?Q?9PPwyFA/LxEgYwewzElWSumcLTASK3Whzr825C1ZQVtPXt4yC9uFkZwj1K?=
 =?iso-8859-1?Q?qgu11HaqTZjaX5SrNRMCQ+ZUTx/n9mZlsioZi/I2fJbOgRhHOGXDoXS39e?=
 =?iso-8859-1?Q?rpw+Kp6SWkiklIcKGpKTG7b6dhUHEDhxQt1UA2KNivfkt2QK8463xq9UYg?=
 =?iso-8859-1?Q?VvQHhnybOdm7FsWtJ5lmHhLLqKsq6+Jpct1ODm/uuxNNOpr85MH7aME+Qa?=
 =?iso-8859-1?Q?x+1BcuxD1Tu7Zt7mHWYLh0aajw2ToKu8CBYjXrZMVNwahLS1sUOm67mL2S?=
 =?iso-8859-1?Q?c4AZwHjWnIGk5FkLB1Zvjjv1NnuxKZVLfFxfwgMedy2sf23z8xuvHbpVXC?=
 =?iso-8859-1?Q?wyFZ0aANdHpz91hojwgrWDT1R+JvEg5OvtA9jwr7Md/FU4mAUYjhnt/Fv6?=
 =?iso-8859-1?Q?LGRX2RYoe2Kf/fmhdEHkpH7UxJlsFlIXrcpiIsuJ1QJW0q8ICEaXQoLuKg?=
 =?iso-8859-1?Q?ApJd/Cj2j/CylyYqIQQCQ+wv79XmD6gy1FnyIJQZu5IHbBWaWtHa3SfnqQ?=
 =?iso-8859-1?Q?ijwMfJ05mZQc9yPisIAi3LmWputZDV13pyg0EAcudPMFn9v/BALlFZ+vol?=
 =?iso-8859-1?Q?YwKamoRSiN2E+TbzrlbEzUiSwwsQm148FVHoJlpqB6NcWVLrRvbsQ2dtQl?=
 =?iso-8859-1?Q?cH2FBCCMM10HaZ/mBZBBwf+DgAg0XsSfQW0TE5WN?=
Content-Type: text/plain; charset="iso-8859-1"
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
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: e8c094b4-056d-458a-61ac-08da9a7d5f89
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2022 20:27:29.0462
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zadOBYC43ffn6zwq6noHD0H9nFFjWVjgI3CgJYZ0aQSVWTZSpcz5G4xYy9yYd5/JM7Lc+qxX7FNR2uwu1zwpUw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB9004
X-Rspamd-Queue-Id: 4MWbnt3DJ2z3yfl
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=IfqCujnr;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=uoguelph.ca;
	spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.115.51 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca
X-Spamd-Result: default: False [-4.99 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none];
	R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2];
	R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[40.107.115.51:from];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[rmacklem];
	DKIM_TRACE(0.00)[uoguelph.ca:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.115.51:from]
X-ThisMailContainsUnwantedMimeParts: N

Hi,=0A=
=0A=
Recently there has been discussion on the NFSv4 IETF working=0A=
group email list w.r.t. internationalization for the domain name=0A=
it uses for users/groups.=0A=
=0A=
Right now, I am pretty sure the FreeBSD nfsuserd(8) only works=0A=
for ascii domain names, but...=0A=
=0A=
I am hoping someone knows what DNS does in this area (the=0A=
working group list uses terms like umlaut, which I have never=0A=
even heard of;-).=0A=
=0A=
I know essentially nothing about internationalization, so any hints=0A=
will be appreciated.=0A=
=0A=
Thanks, rick=0A=

From nobody Mon Sep 19 21:48:14 2022
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 4MWdbC67ksz4cy2q
	for ; Mon, 19 Sep 2022 21:48:23 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam02olkn2082.outbound.protection.outlook.com [40.92.43.82])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MWdbB3M0lz45qw
	for ; Mon, 19 Sep 2022 21:48:22 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=aOK2moB7QXi+6LLA4RBciA091CsQTzyaukYPOMVqoelNIydbTa/iIG9xmoKAIHFW/RUk2b4PaXPYC5PO06XU5ti21Kl2+sDZ8EC/9YdWVIjrdPNoqEgwc8QYoqCNSD9OTg0Sgp67+rVQBTws48ViyO83DYqyj+qI2ssamnSI60yp92kVO0IXbEtX95uQi0DlANT3LSqEU5QakNlBxH7/IsXFfJrZWZwOLLjG2Y0dp+VIAyuT3E7ISWsvtpJBH2fhKDz7iw6rylsAc7KN7AZ5G9ZWpUsmhcpOUAlb1TTLDJqqfSbkEK6F3IsHGCYrG1gbMQMwOgmYLsYjVB1sQFKLLg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=V2tbChkV3fdFyLY3+d6C4tmJ4JzX/PMJxUOR1ReEuqY=;
 b=PaUh5cyc7uSHincXUb8sKaLWzamBwSWGM5K3lFiVowXvs4wTBMhMPmETo99z74o4BIO4QFhrbWPmadStLiB1S6L3aWCtLFyTKkWUhjU9NiRyFkivp/X/6XiNAevw81zE394kgPrs5dF+4/QXeTRBw3buoCfjow3qnpDaT1gtDDFbhdT1KdTnNNgGdpXxL6JeIIxH7Jljv/xYrfazpiizq6Nf9XV34+5xRmpzHlCaxkYVamFD/2lj0iaJeL8Jmqni+xet0lCo6bFRW9PsG7Y992QZ9dWJcGfB7I4PsOb3JeOu85jk+CCGGUIDQagPnbyrDCvWJPjRan0GgsTG1Qq5Kg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=V2tbChkV3fdFyLY3+d6C4tmJ4JzX/PMJxUOR1ReEuqY=;
 b=UVzFCa0+lwNaWB/6UvKb4xV7FPIR+1nYy7tOtR059vp38DTF5EVZtQ23ZMVYSILBsBFangDHll+A0W8BsPeC6Qko5oLYmPV3SjUOoOSixnKwAOPvMdZ9StinpoYKxGUyLBhRYxwOmFrBsflhOKsDGHmrv/WcgYwGP+mi64CMPuubzVZvMf1YRZDQOmGnJAmqNAdskqKoXSFfR5Dfh9xHiNR40Ng04v5Oe0ckJKFb8QFNzmXQTiP4XIJX3I/qDeGMuGOv3w+qDZ4094EZ9GEgJ8tKb5wdkM9esQl0LY++jp/5+3Q9mWDVcF7eJGv8eJEdVTG3701I768TX8Dx4eMVIQ==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by ROAP284MB0286.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:38::6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5632.16; Mon, 19 Sep 2022 21:48:20 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::81cf:90c7:6a5d:63bb]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::81cf:90c7:6a5d:63bb%5]) with mapi id 15.20.5632.021; Mon, 19 Sep 2022
 21:48:20 +0000
Date: Mon, 19 Sep 2022 18:48:14 -0300 (-03)
From: Ivan Quitschal 
To: Hans Petter Selasky 
cc: Ivan Quitschal , 
    "freebsd-current@freebsd.org" 
Subject: Re: RES: TP-LINK USB no carrier after speed test
In-Reply-To: 
Message-ID:
 
References:  <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org> <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org> 
   <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org> <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
  <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>  <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
   
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-TMN: [fM8KHrxQhYlV9MMwKBj00tK+AwX/z/GR]
X-ClientProxiedBy: CP3P284CA0030.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:6c::35) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|ROAP284MB0286:EE_
X-MS-Office365-Filtering-Correlation-Id: 0e1e7edc-99e1-4f98-3b7c-08da9a88aa61
X-MS-Exchange-SLBlob-MailProps:
	q3cIJLDN2c91Hjp3O+l7cwx3BDA4Erwti+938QMm0bzOdFfQRKU+XkjCMZo1ORvEpufb75eDeufviLsQ50VZrT/BhxeS3tyR1tf7dM1OY7FXkB0msQH88PhEEl4/7+pFrxJsi4tXEKSwCROlCiQby8g9XJCgWox5igyZTCiWZMHo5h0DOrOsLJiWx/jd39F8nG2LZl1zjH5lExiXrf3DkKQ8ePx3xNoVJ/R3xi686WHA5Hx9J/tCR7J6EcCOYYQV7wmY5BLEuF01/c0HbgVeF3IFuPbDbqKbsPWU9QuXu7PPsC+XMk8jMKqNqSWTYMl9SaWAubnhvwhCFqgme21bI3iUn+E6oerJmS3K1uJ5ddeepcMfl0YSNmMssq+tKw5TmG9Vez4k+M7Nde1ex+kGDtOs2xq8lO2NfHPH0EkPG0aKpZs/X6SMFvhO1kF9xzaIBRi7/aTQVOmigwnQV/O2jQE8RWSXyyzBz/JoKkhcAFayelDNvQwJ65Hh3Wm811nz88KBMu93idi0Y6X3xdjoJK05+rEKGAsgrO6RFGV1s7pHioABSZk54b19HKJuBwyhzAUTZpUxK8X0E1Wv0I/QQxKQNL6VbwusDHGXNp9K/M47edM+M4SOrSb+x1p9o1QMjS3EFMArydrpPnLZHFkkQqkaE5RPlefL/wd1vBVk0GMZhQlgT/bMBfCMAkA9JKaW
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	hIgZez/AD25GvYHthEMA9TZvq+Su1Ngpsdq8wJqzJnn0DqzE1QWteuxj2rBR3RAeO8YWuID3RuYsVdHOU9oz8pVOidJE0atqElI2qT8BWAq4cCP1AP+C1yM2SswEmNOu9MLNsD5UwxD6g2HGYfAQvzn20ubEGp+vzw8C/AaiWABWw0eZBqeQRkJerN5Z4LwrIuIALRQ52syPwd+FW/D0iSmzwb8AbE35KeJKFv8sPN9Ujpmwgeg9C4VxuSW+otHcMIjskhu2o8PnE+kWyX6b/gsDQzeMJ+idj5NR3i9W/wBUnFtCATxzhrYIzRJNiNA3JlJWOm6RW25WmWqptFJJhiTCUehUAEKZm+rw0DRgGRsynuwE/Or+pQY0b+TPUj/a6r01l9G+D1rp5778sf/fEyoRmfzybFC/CjPUyMvF+0EisAkPTLAntlZ8zSnSDOaOybBmV5EGnJVexqDexmAoYRMtQuLaTvdHXYJIrsAOMrWV2mW6RW8WZtMZqKzPtfvXqLk0aMHMabMPdVOLRS9busv4o6XfU9KYK8VPthOQcjFyX8ajZqz8ckRTIQNwsiJYDV+Hac23Ul+oGHtanQSVkQo+ZVr2IgBg1P4IdjJJY4IaUU/WJ1TbNiKzdjj9dGUm2tDeiLaWOU834n8bB5nObSLshYcd1qScNFpMnbH6bSesBjqzlhO8PhvAWNAZSqSr
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?OQ3K5cp+ciX0ikpOd5KODMLH+36LUqhOoFoN/BIj3b5oaHSl+9KhGEEqWfoM?=
 =?us-ascii?Q?oif5xnltlZZqz9PneBNDuttpHeMniasLR7/0u0yDRDJkhPTvZg44VriqxUk1?=
 =?us-ascii?Q?y8UEP5wOKa+3ATr4KnDregdEFLNKaA2qznNuTyCm1sk0atxUdzvI+cRvRcL6?=
 =?us-ascii?Q?+d5Vg31znIDUKvnmL1AxNqAWt+ZSmEdgFlRb/8YQ9GefUsuo+CfnlLaOx6Mn?=
 =?us-ascii?Q?H4JCo49RJzDV/G2gRe2c3nZejGwAqT6UEgqk1z1jbcJ1Wj0Jfg1rMc1bLNOX?=
 =?us-ascii?Q?FuVIO/rnVQK5aT6oYzlzzaaXkVlTKzhgAVOdl/IMt1H8rog9PlI5MQToVFaz?=
 =?us-ascii?Q?w1H4oSiDtuL5QLQwj0cqpdNErLtRGUHu4QRIFmHUTB70iqrYmCjwOBoRrJA9?=
 =?us-ascii?Q?6rLmQ/nemwBi2hQryp7JPAnVUmzKIUByoC93WiPiaznD8OOlDEnafq9Xx0d4?=
 =?us-ascii?Q?XnMyX7hxqyoMZk6iVTfcl60qsoRXR/B8Nn3hXpgF9h/CVrU60YM2u1TkM3f3?=
 =?us-ascii?Q?diOTgeHJHsXtwMJp+GH8FfR7cSTQ6HAwj/x82UQVBgJ8hsf1NmwiYdFIuAhi?=
 =?us-ascii?Q?c93GjhHyhJ25NvjnjPCs0xukdPLaNJnXd7KD9kaHB8IRc7wGBpfvjhRizhvB?=
 =?us-ascii?Q?hrzfMnMiypGKFOyV2uu/+sVqlScSQoByPYE2N3VCbszYZ9oioes1KRuB95Zl?=
 =?us-ascii?Q?cOc441gAnn8aRZqtt/PZZ17sCVp417276sRwwaALiQVTR9ipzFOsYG/G+BCr?=
 =?us-ascii?Q?ww08Hx51nVjUtB2+n4z25uI53Rjmz3Ly8AsuRVUl9jE9foKHYJArFsHEGt4q?=
 =?us-ascii?Q?ZkrotI0ZA/XV3O/V3ZCFzZnvnpmfwLHKeXkJCL71ybU+R947qMbBI91910uL?=
 =?us-ascii?Q?qSE4NTzQ1M0Az2i0pZtD3Ho+Xsow8ywBNvbkoSQYM3Ce3kp/U/PT2UshPLNE?=
 =?us-ascii?Q?WRIPua3rXt9tLY/sW5qAg8ZFneIA7R+aXFiV/fT/r3LC2pXj9E6NqrZFIEkV?=
 =?us-ascii?Q?nfRg3QOGhEJ0gMjPgd2O/E0s4CIElRUtv3CjXnWj6YBZg0V7kYPWRwFuOMXr?=
 =?us-ascii?Q?aqb8DNbsqbKGeF4jnyiIwk8cmLjo6748t3kqT0a4FGaqT9+P05Q4aDJCOfwg?=
 =?us-ascii?Q?OpU5HdsBN6B7ekmS+2lRul5du0CpexNMs+aS7MWLsLEjkBXeXb9BOVRy/d8R?=
 =?us-ascii?Q?wwmaNMrI7e/zLel7E+++1w8dcCk805RmRbTIp43zIFkP1A+6tIH3I6/nOep1?=
 =?us-ascii?Q?wgOyFWsH2DuobQxxi1vE3yPppFDP2glT14Y6rueT7A=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e1e7edc-99e1-4f98-3b7c-08da9a88aa61
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Sep 2022 21:48:19.9483
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB0286
X-Rspamd-Queue-Id: 4MWdbB3M0lz45qw
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=UVzFCa0+;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.43.82 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-3.79 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_SHORT(-0.90)[-0.903];
	NEURAL_HAM_LONG(-0.64)[-0.637];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	NEURAL_HAM_MEDIUM(-0.24)[-0.244];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.43.82:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[hotmail.com,freebsd.org];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N



On Mon, 19 Sep 2022, Hans Petter Selasky wrote:

> Hi Ivan,
>
> Can you also test this USB kernel patch? And revert your if_ure.c patch?
>
> --HPS
>

hi Hans,

it *almost* worked ... everything was perfect , full speed 600/300 on the first 
5 tests (on sppedtest.net), on the 6th test, the same problem happened 
unfortunately

thanks

--tzk


From nobody Tue Sep 20 02:51:43 2022
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 4MWmKx0lLRz4cn7Q
	for ; Tue, 20 Sep 2022 02:52:21 +0000 (UTC)
	(envelope-from m.e.sanliturk@gmail.com)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MWmKw3b9sz3GRC
	for ; Tue, 20 Sep 2022 02:52:20 +0000 (UTC)
	(envelope-from m.e.sanliturk@gmail.com)
Received: by mail-yb1-xb32.google.com with SMTP id a67so1489063ybb.3
        for ; Mon, 19 Sep 2022 19:52:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=+0HSJKaOeQntpRcGAeD9Woi0VFaydpIIFCZGC7aeFek=;
        b=FRlnzZpmK5+BBfSVIeoU9WW/oDc9jAgOeN4b2Qx35ZrXs9FdpxVIRzP8ZsfOf3JCpk
         Fyx2v7wXPUh6gHgqtZI0HzqfKUAHihsR7Cx0remRlS06/aDXqXD8gvKOUFvsdmHVZ7de
         rgiNb2dhhIQwsPJAdMOtdkGrS5FSeSsMUwgyWbcT2ZM7+9VuKysCqZl3b3VjZndakghj
         B0iEwe1388GINIV7vtjioO4Jwyab+GtOsCv6w3juj/Pv0ZrngCocF/Ja9uzcf51Co93Z
         WaPLiOtzpvZxopEEngLQ4C4rnVIt/SsZYMxBQrus4Jgpazp8mRgkbudlBzkS0cKvzKA8
         LNsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=+0HSJKaOeQntpRcGAeD9Woi0VFaydpIIFCZGC7aeFek=;
        b=LESmLP9YaIo8FRvNVm4rq5ukdg1KEtaI4KpSL4dYejyTl+ooqWpsLuKouLyiGc0D1D
         LRGLyIPGHGShNbazqBf8WegfV2BHbw82fuTwZyHq87SjUMSKik5OGIIndDIp9ihD/z/v
         LRl1bxgAcZFq1TOXFPbMplfoGQCU/DlK0XpHk76+D6+Ml0+wrpYK2fWlvRWJTO91iI1J
         TlIwwQeGqCOtAsGIV+STwRRoDVriXWf68L7RVnhcX8ZbF646IEkz9yxCsAIu6YuDgj3i
         zvcn9R0NtwbcMYBow1fOBzBP7EUfC8zOGG1vySCsF5PJcrTWICm3h1aC36QUOfpKNC38
         uKmg==
X-Gm-Message-State: ACrzQf2LlZtbTzMr/Fc3HP3Pe9fYle4AlwVp0IqjbRZZQlhk8DsGzdtg
	YM/1LkvPFTkB22dzAAxTxksZvMZQQg4n8+hO1UQ=
X-Google-Smtp-Source: AMsMyM5dYATqNAeKfoSbX5P1obJJO7SMUnJkuSLfQaOWseeCK7h1MVT5RqNfublAuNgcd3ci/jBLI4tjJNHxQsl+IdY=
X-Received: by 2002:a25:660e:0:b0:6ad:896c:f8d0 with SMTP id
 a14-20020a25660e000000b006ad896cf8d0mr17905501ybc.517.1663642339478; Mon, 19
 Sep 2022 19:52:19 -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: Mehmet Erol Sanliturk 
Date: Tue, 20 Sep 2022 05:51:43 +0300
Message-ID: 
Subject: Re: domain names and internationalization?
To: Rick Macklem 
Cc: freebsd-current 
Content-Type: multipart/alternative; boundary="000000000000ad93f005e912ea83"
X-Rspamd-Queue-Id: 4MWmKw3b9sz3GRC
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=FRlnzZpm;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of m.e.sanliturk@gmail.com designates 2607:f8b0:4864:20::b32 as permitted sender) smtp.mailfrom=m.e.sanliturk@gmail.com
X-Spamd-Result: default: False [-2.93 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.98)[-0.980];
	NEURAL_HAM_LONG(-0.95)[-0.949];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b32:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TAGGED_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000ad93f005e912ea83
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 19, 2022 at 11:27 PM Rick Macklem  wrote:

> Hi,
>
> Recently there has been discussion on the NFSv4 IETF working
> group email list w.r.t. internationalization for the domain name
> it uses for users/groups.
>
> Right now, I am pretty sure the FreeBSD nfsuserd(8) only works
> for ascii domain names, but...
>
> I am hoping someone knows what DNS does in this area (the
> working group list uses terms like umlaut, which I have never
> even heard of;-).
>
> I know essentially nothing about internationalization, so any hints
> will be appreciated.
>
> Thanks, rick
>
>




https://en.wikipedia.org/wiki/Internationalization_and_localization
Internationalization and localization

https://www.google.com/search?q=3Dinternationalization+%28i18n%29&sxsrf=3DA=
LiCzsbsXi8Z_tScj_8BZPTxNfpQvwPEYw%3A1663641967630&ei=3DbykpY8iJJpeBxc8PjpCF=
8AY&oq=3Dinternationalization&gs_lcp=3DCgdnd3Mtd2l6EAEYADIKCAAQRxDWBBCwAzIK=
CAAQRxDWBBCwAzIKCAAQRxDWBBCwAzIKCAAQRxDWBBCwAzIKCAAQRxDWBBCwAzIKCAAQRxDWBBC=
wAzIKCAAQRxDWBBCwAzIKCAAQRxDWBBCwAzIHCAAQsAMQQzIHCAAQsAMQQ0oECEEYAEoECEYYAF=
AAWABgr11oAXABeACAAQCIAQCSAQCYAQDIAQrAAQE&sclient=3Dgws-wiz

internationalization (i18n)



With my best wishes  for all .


Mehmet Erol Sanliturk

--000000000000ad93f005e912ea83
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Sep 19, 2022=
 at 11:27 PM Rick Macklem <rmack=
lem@uoguelph.ca> wrote:
Hi,



Recently there has been discussion on the NFSv4 IETF working

group email list w.r.t. internationalization for the domain name

it uses for users/groups.



Right now, I am pretty sure the FreeBSD nfsuserd(8) only works

for ascii domain names, but...



I am hoping someone knows what DNS does in this area (the

working group list uses terms like umlaut, which I have never

even heard of;-).



I know essentially nothing about internationalization, so any hints

will be appreciated.



Thanks, rick







Internationalization and localization


in=
ternationalization (i18n)



With my best wishes=C2=A0 for all .


Mehmet Erol Sanliturk





<=
br>


=C2=A0


--000000000000ad93f005e912ea83--

From nobody Tue Sep 20 05:52:27 2022
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 4MWrLV3W1zz4dDBR
	for ; Tue, 20 Sep 2022 05:53:06 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MWrLT25SXz3Yy2
	for ; Tue, 20 Sep 2022 05:53:05 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id 4578C1F27;
	Tue, 20 Sep 2022 07:52:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1663653172;
	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; bh=fBfKoxluyoh0u+M/816lhtApj4VRJJKYBgmO68ezeOw=;
	b=WX9J6AYbKTUpSlF2n7LaZuVBf2E/U1QO6hLUmYDDpC/RiMST6/0K4i/QmpNH3ky124/qEu
	4SVFH6VWQ4RtQYozZojcB35MybAU7RUm9Vi+RDg+Z3blfSY5oOjBLVHV4Wkxe+jCxoW0EQ
	ZCXTqZgyYLjwAofY6z7BrUR0U8lbdLpJc2Mgd1cC8+3Txt0q1eodjrDFmDW4WMlx7/m8WN
	iN33QuRghfrulR7+3/aNVzn7HzH10/dsOxe5zrQGMC5HJT3G87rQkasaBIn5SWYk1kAlkA
	njen7G4vfySsRYzgsWS2ap/A6xzYG7SHa1YKnPKMEpkzhzhRZupgvRdXyI7XHg==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id F2C953583;
	Tue, 20 Sep 2022 07:52:31 +0200 (CEST)
Date: Tue, 20 Sep 2022 07:52:27 +0200
Message-ID: <20220920075227.Horde.YJH3cypQ-cCIMM7xHh6Gh4p@webmail.leidinger.net>
From: Alexander Leidinger 
To: Rick Macklem 
Cc: freebsd-current 
Subject: Re: domain names and internationalization?
In-Reply-To: 
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_uiVlQhJga9dk_8iccXEBlbV";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4MWrLT25SXz3Yy2
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=WX9J6AYb;
	dmarc=pass (policy=quarantine) header.from=leidinger.net;
	spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net
X-Spamd-Result: default: False [-5.06 / 15.00];
	SIGNED_PGP(-2.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.99)[-0.986];
	NEURAL_HAM_MEDIUM(-0.97)[-0.973];
	DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine];
	R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_SPF_ALLOW(-0.20)[+mx];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[leidinger.net:+];
	ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_uiVlQhJga9dk_8iccXEBlbV
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Rick Macklem  (from Mon, 19 Sep 2022=20=20
20:27:29=20+0000):

> Hi,
>
> Recently there has been discussion on the NFSv4 IETF working
> group email list w.r.t. internationalization for the domain name
> it uses for users/groups.
>
> Right now, I am pretty sure the FreeBSD nfsuserd(8) only works
> for ascii domain names, but...
>
> I am hoping someone knows what DNS does in this area (the
> working group list uses terms like umlaut, which I have never
> even heard of;-).

DNS does this:
     https://en.wikipedia.org/wiki/Punycode
This page also shows some umlauts (German ones to be precise, e.g.=20=20
"B=C3=BCcher") and other things like chinese and other characters.

There are libs which do the conversation, e.g.=20=20
https://www.gnu.org/software/libidn/doxygen/index.html
I=20don't know if there are libs with more preferred licenses.

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_uiVlQhJga9dk_8iccXEBlbV
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmMpVRoACgkQEg2wmwP4
2IbI5w//Siv2KpSK+5UNI8R6r7Q3nCxxIgD24ySqHKEfgzFU1212EYeVUlXmevdu
OOT1VOspTcL9nN5dTEVrYtfiY+wEDro8vVEU1x5YCZ1sps8XGCPHV5a0NWLKfkf6
n2KnuP1jTXtR/8AO3AyxmWsyivvCD15pqKdF+rwS+Ch2EmABYKefFlq5oTAvTBXV
ra/dZnVe5A426GbKZAJgLautnkrosePKhNTKEO4dXKLhjwWDMb2jAYShPtSUW6a4
YRyB/XtPGN1s7JeMxNHHRAeYIqHYXceaLeQU+UQYMvRVe+CMQp44dNEJp0YMPDro
UsJpK+qawPApjHEtI6ytxPQ0WEAeivN3eOnIcQ9qRdhWCnHkgh5adTTFm+19eHI/
mp9ELQlDdAG5XnsigvYF5VSl+gMlVtJhGSH5vCtsXzgT4muDsjyIJXUa9uM8yJf9
5mO9YRz3Fzmx1sSs4rtlLBngQd5ewo084OAixLQ/ezL1nFaso68NlHYjxVMo/LJh
hL5HkJ9XpRHwJv7yOMx3deeqQuMbL3kIDpsDHGBWcIUtiznBAKuFCO/4C4d0ND1X
A2uTO42ydIwLtvpNrIw+VkBsqlHSaIOoqZuL7QZX8MILrne5AXAP9kzecYf41E1F
NKQxuwAnTMC0UzERFpMrthKuqAVhsxLL1A+3oHfSQWDTGUkO2+s=
=PG2C
-----END PGP SIGNATURE-----

--=_uiVlQhJga9dk_8iccXEBlbV--

From nobody Tue Sep 20 07:31:08 2022
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 4MWtWj2V54z4cF2K
	for ; Tue, 20 Sep 2022 07:31:13 +0000 (UTC)
	(envelope-from se@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MWtWj225fz3ltg;
	Tue, 20 Sep 2022 07:31:13 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663659073;
	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=D0AN3vP8dnoUSZPo1uuYrjGew4tnaruwG9trU3xzqS0=;
	b=j2rMsu50gCKLgyiWJ3vbZbjM6N78LaYdr0e4ljpM5O5tIi4kYF8oqZLVaHDxMCbP7o+VPf
	YpcIVcEGbvHywxvBlqSrkePegZZvSnt2+Dk7zbr05jQw3tfg8lEpIK6xXNFhtvoeKpIwed
	RfTBngW0UDN5bBUmxnYebcSgegwd6Ni/kYsfwPesKp36f+1sbKQshBHdBvUfd7hVFHcuQ0
	yRYaVBOBFUhuoXgV/VLlQ/FKMpl8/87o62H1oTkxO7tBcxZk+l+G7UmZeRE6CHzx4I2cCz
	5JAqWmZL4sn2EbF4vejL7XnYwXScoPJ2eURaOS+uq4b6zdt99dq9aK78J27Wqw==
Received: from [IPV6:2003:cd:5f24:dc00:8961:6db6:e7ab:e906] (p200300cd5f24dc0089616db6e7abe906.dip0.t-ipconnect.de [IPv6:2003:cd:5f24:dc00:8961:6db6:e7ab:e906])
	(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: se/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MWtWh4jgpz18qr;
	Tue, 20 Sep 2022 07:31:12 +0000 (UTC)
	(envelope-from se@FreeBSD.org)
Message-ID: 
Date: Tue, 20 Sep 2022 09:31:08 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.2
Subject: Re: domain names and internationalization?
To: Rick Macklem 
References: 
From: Stefan Esser 
Cc: freebsd-current 
Content-Language: en-US
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663659073;
	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=D0AN3vP8dnoUSZPo1uuYrjGew4tnaruwG9trU3xzqS0=;
	b=bvCayp8HDZ6mREuL42knHYMqDHmpd80NTXwZSFbJuOJMgpMiEuIfjOzuF6nuMITDns6KJh
	kb9yaP0wdWyVWAIxNAgZEz3xanzISnTmWvbSoqxHfSLEfKDuBhdtblR3c4X6uzGQwOk6Ea
	9Bk1EdoVAGAJU4OuyXAWEt+xM4rAYyHmpScTljz7A329YGC2LgN0+iG6SBcYTCYezpMy9f
	R6LpyDP2ykGuZsol2bVRB1EldTVm5Hz0G55ao36vRIP0SX2AyMz+NQIhYQoCy+xvNwFpg2
	AUnprFgVGvAEZl/wy5fK9rrAmkSXP24cHWw5kHQRd7RuY1JdACdGN3NGUEwQoQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663659073; a=rsa-sha256; cv=none;
	b=IJ33WRa6nhspzWz39VGvuW9wkrAZCm28R6+25p8yjKCE9nhDVD6AeXspR4s7NTvaGJzSgJ
	p0xbKRaHjzKv8egUoHAr7GksXWdHkfWrzhkwlEehjzH8E9R2DPdR64nDyXaxPnexPPrz9T
	sVi82KID8iGEO7Yvo1Fgnb8SYhdClmmif8N8Dxs8UQLEH7lflXZty7cfK1hb4kZKM7jii5
	K8Hn2fGFOSv4Nl0oBOr9yfw6Vjehgk+XyW31EfZFj2wmzKJdaw8NaYmn84LaJOvrO/MGTE
	NSDeiaXzvFX2TJSxzl1itdPDdt0KP+a9rlH+INsPvE3bufpJX0d40H/Yv8DqTA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

Am 19.09.22 um 22:27 schrieb Rick Macklem:
> Hi,
> 
> Recently there has been discussion on the NFSv4 IETF working
> group email list w.r.t. internationalization for the domain name
> it uses for users/groups.

Hi Rick,

I do assume that you know about RFC 3492 (Punycode):

	https://datatracker.ietf.org/doc/html/rfc3492

> Right now, I am pretty sure the FreeBSD nfsuserd(8) only works
> for ascii domain names, but...

You can manually translate domain names into their Punycode
representation. The NFS code could work with them and only
translate them back to UTF-8 (or whatever) for display purposes.

For pure ASCII this is an identity transformation, for names
that actually represent UTF-8 strings, the value to send to
DNS servers (and to locally store in the daemon) could be the
internally stored Punycode representation.

> I am hoping someone knows what DNS does in this area (the
> working group list uses terms like umlaut, which I have never
> even heard of;-).

That's the contraction of "ae", "oe", "ue" that has long ago
been introduced into the German writing system, with the "e"
abbreviated to two dots above the vocal, e.g. "ae" --> "ä".
Just a convenience rule to speed up manually copying the bible
in monasteries in medieval times ;-)

But there are many other accented letters in other languages,
that can be used in internationalized domain names, and the
whole set of Unicode characters can be represented using
Punycode.

> I know essentially nothing about internationalization, so any hints
> will be appreciated.

For a start:

	https://en.wikipedia.org/wiki/Internationalized_domain_name
	https://en.wikipedia.org/wiki/Punycode

There are C implementations of the transformations, e.g. in the
dns/libidn2 port.

We do not seem to have equivalent library functions in the
FreeBSD base system yet, but probably should provide them.

Best regards, STefan

From nobody Tue Sep 20 13:14:16 2022
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 4MX27l10GVz4c9Nw
	for ; Tue, 20 Sep 2022 13:14:27 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2104.outbound.protection.outlook.com [40.92.96.104])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MX27k03jzz3JDn
	for ; Tue, 20 Sep 2022 13:14:25 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Fea8h3f9nI1D6YJOHvxOir4BANi0hQfyBPdH/zC0hveVVqC1R1F09Ub5F+ew2baT5MiW6gXchzMei1duNQ98aBl6kKRPYv+8yz8QyWkcBbc7F0yrySeqrbqRKwq+BqFg+g1VbGSytn8Q/etX/nTpJJwHtmj83de8sKjqXKXG6cQ8XGPaMOM4zCWFtvUuP2lf5Wg5zcLwuPMANdCS1SbF7LwwlX3OH1xBpjQU95Dg4rhwTGTOdEVF8H3936z71utKXEHa9yK8bm8nT+kjFEGs6/IPv7gOkO+ZqLS+nRyBSFuVPcw4VdpV9HQqQOmj7oywnXb2lHCuYfe6xok/9u3kZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Yl+BI2CneSHjji6VVFpSoJMOLwl1BYSnjEj+g4aDnbg=;
 b=AvMNB9BMT9EQiZCvBh8BqiGaL8ExwwXCc2HiGMRr3L+Vzx0uVSQB6A2fJURVLuNcbex9qeaUSjLAgKSS4aTwXZ0ycQSku1V479oLtCyyNZErgSzmEAy0FHCpMew7QCLXY4opL3qMFYmGJHIJ2Z+UmwSOn75LkdqEdJRRNXu3OdwDmj7xBtJexWoLzSnjEdlyYzR4GY4bKqyeL1mdiC/lfQ7SCDZg7nDVEpDjrto3HOzA2jV8bieLC05/Z/7YjzKTNd87p89OfZf75taZZmZHaOOe6XCO2z/bJArPMbn+mk827s33zlT9mA9z/Ld+kXrjmuwEIeyOXGcDmTNV3FmNXg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Yl+BI2CneSHjji6VVFpSoJMOLwl1BYSnjEj+g4aDnbg=;
 b=ZoGvv9l6MYw4Xxp0qa50FIH9Yim716j4FnHZ/LkrTyKXrwr7rjTFPTRzG3GdsHsv7p/DihW3Kjeb0nOQO7EKbdetMX6eVjlwS424fxCEN8SJUAgz33ZcAvQMCOs3oxbS1Mhy98noL4kFY18lVp9kpTNmjq4Ita6zS6gaVImuSzRAYI8rxQfLpi5T7fH26jwZ2np5W1dpnf1ySri7TDZ4ZeAtBEe7GWiyzGcMm9GOWyx53XI7hmJ5PtQnt1TJC7TWVhnnJ164ik2VFg3niUpb6gN4gKA7ObTe+p4CssKnL1rTsGbVZM72vMbt58fV1oHxdD7NeP7pDUXAErIpX/vqhg==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CP4P284MB1874.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:dc::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.16; Tue, 20 Sep
 2022 13:14:21 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::81cf:90c7:6a5d:63bb]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::81cf:90c7:6a5d:63bb%5]) with mapi id 15.20.5632.021; Tue, 20 Sep 2022
 13:14:21 +0000
Date: Tue, 20 Sep 2022 10:14:16 -0300 (-03)
From: Ivan Quitschal 
To: Ivan Quitschal 
cc: Hans Petter Selasky , 
    "freebsd-current@freebsd.org" 
Subject: Re: RES: TP-LINK USB no carrier after speed test
In-Reply-To: 
Message-ID:
 
References:   
  <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org> <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org> 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>  <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org> 
   
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-TMN: [wrkEJWm1GkGIa1PbEFSxNdKW6TtXdylL]
X-ClientProxiedBy: CP3P284CA0015.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:6c::20) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <20ba9be4-e358-9d69-4bc5-e1b6ddd08c30@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|CP4P284MB1874:EE_
X-MS-Office365-Filtering-Correlation-Id: c1f0e829-7a6a-48ac-345a-08da9b0a07fe
X-MS-Exchange-SLBlob-MailProps:
	q3cIJLDN2c9l5B4cABGfy55JoN+RZ8JpXdcQ449Ji6RhOzfD3c4ONyaxbmnnC92ePx+7HYKNydcUqek755nN5eb/w4FEsozo4/diM3lOpagFbA2+XNaxmyV95vofpszVQ/p4Q54q++m/23HUAElMNErJRuhLhVhBST8zFEFZEfiTqOxT2c7feCLZgDCb6gYeSzUnIcDmYA9QE8IMgdHd/ZBaVO9ZGpSZWf8jnjcMlsMgof85jh36vyr16vaT6lsY15P+Gp8wAO4JGyMfOOyJuZ4lLRSSnxQ3v3EbBNBgyOBkMECyaF6J3hjwO+tQpC7PGgNjc2Zc6kmuz4ucyuttT1xeqB3bJv71HLUOfjTToNQpQ8AjOJQYeLpnW1lJ9em+YZkjg76JffqCxPVh3/mzx6GHLdTFgkiizmsSPYkMMDGnuecxCkHJeQFDXpaCJPYfQHlNSRTqT5Uig4inm5FPEV5W9uapnkix+P1zq9u49/7CwNBI6n9bUk8Gb321BNvzP4wfz2LO/DsZip9Efh1bdhYf6yDFMQy4m+qLuXfPm6q8yQy6PhoklGT7z1AQwQ7RDY7VkeBT9MKD7IgxUmIVa4BEjOi5nX5inY22gd+zhqD5uK6iVNFfuPM2yQsGpGZoLE66fUwtfrz6l55PDHtEl3giJtnOvDhd3ZSo0VJSLH+FDGogqOyL1W8m7L3+fQy+
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	CF6SXvlGmz4GCCWku+ll+id2uYXWLTI6Zx38hToX/tRdLGgNU8BqFKcqKHqRxeUfPkD0HjxiQaePEu6Q6ShIRL7Slk7GoYezKX7DYsk5lbuLThPA4MXXd5PLDbXEO0ZxfLxO5OlxjS9NRCIWjuAN82tshy/jTyFNSGa9ZOLO1cUYLYqyFIL0jpUqCa+dOMYSSHviDkabd+UIq4vmw2aysN77gJrGGnWlhEW7bRN9OY1eYMCb2tXbpUwH4uNcyDs1RmtBebbXW2OjO1pK6pcpAgiY7HR1EnZxyDFGr861/bntiBI5qOMCUsSSe+WMNE5mqJsbjnhaWIVqu8Rk/iMimJoLrI0F39X89alZY2lBYamFz2pWIUjEPHQfBs0zpauFHyL/cholNSBkOQFdZ9kdO8G3MTnp7Rh461sFpl/4DLmHmP1kB3kpeWi9KWaKajXeX1vCjIlAGDwub5f2k6FwuTV7n09kEsr2x+HtJScNPEz2nR9xfer0BKcWuDqKw2kCt9G46Wq6UkmAQMhLG1gJDef8tysFMatg2jfHL6PRZhIxHfd+ASUwhrP5jiNJLyLl4KqE6iVVS2VLk9Y13bb7xL/44LmbNNxDFgKUwrz1TklWxBBLL3mE3OB89IHmL5cGPjBeba2HAt03YyJ9kGQU8Z+9HUZQb5NaCgAERRwzfQS8nwOw/Kd2kbnAynzLG3sD
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?I+EJm4KH9Wega4LlyZ2v+VvdAT9X6/HoNmKdnl/rvYYkKiZUBr1lpplRaWfa?=
 =?us-ascii?Q?bB0WyI5EW9mVnNI9MEjxQI8HKTnGRaYL6HMN7JJNgLgPEIFfPy0DmMOS9tBb?=
 =?us-ascii?Q?vJi8Na5ZMLPr8oSxSAg5ZOXkBdDsr9+5Oe8yeDYD0EsaeM+CAgkgp/jlzkNe?=
 =?us-ascii?Q?3Afw9IGMyDLrXJjP6uG1PoA7qu5s2TWFFiuoHe1kNLdk1uYHd4Dc6bYjJxca?=
 =?us-ascii?Q?3503aom/GZj+V1Tz+cTF4j4KzIeJwM6yya1M0ne5Qamy1DU3ARGSpUMVrULa?=
 =?us-ascii?Q?ettYuR2GnqsQmKj6GwBZHbKAprTAwg1rFakbQio/1lRzUJX2fqUEP4av1mRG?=
 =?us-ascii?Q?n2kcXiR99u8NLH0wwvW3hcp+QuLXea4qYjf2jSE02kgGZXRqltMnhhHvr3nH?=
 =?us-ascii?Q?I7+oYqJBo+NytupDitX4kQyEXX9yD7A4uGwSoD3EamfAnUM4D6DLeIsUmD8O?=
 =?us-ascii?Q?Nr72K3je2r5fEUUo/TMU3dJciwuTQaLNp9lGtCYeHKFIrqhbZ+J/cApXxgAk?=
 =?us-ascii?Q?6QpBrDv6X0vdjCeiNcuwz8874fcJN3P5qGW8F+QzSnfXxUMloksiz0yhmq9Y?=
 =?us-ascii?Q?jNr5OpIDxUuipM9NHrmVB31q/Q6wr29HI0F+qK0xtXGuVPO1waxUF8hcb4L8?=
 =?us-ascii?Q?XmT6vih3R7EzVLrHIVvDpb52BkkAAbZECFVMa9V4iFE35unNC4mIwILZJ+sF?=
 =?us-ascii?Q?jpKIsVgyNpN97KpuJYd9d0jmSFp4Iz6IPCX7Nm0+DrZmLS9qgxXWypk/BW3l?=
 =?us-ascii?Q?mFaKiqKDAS7Ri1+Khx/BiyGtMqOk9cbECBTlSgrQEFrW9g3gcTgNt7zXuVK6?=
 =?us-ascii?Q?yAmbwCJppW1c5g9Jg8TUJ2ZnMnlgJv/+RnkucDX+DHRrD0KRG80VFwj9wHnI?=
 =?us-ascii?Q?wz8CC268r8E1rSerd2SvpTa6UM2rIaZa2flhhXzfqQyePwUTkax0fcyCGe/o?=
 =?us-ascii?Q?RTCsZRPZrL09rjwmqvuCW7ai0wLIax4SrwDgdrjmv5z8r1/4N0I8ui0EROcw?=
 =?us-ascii?Q?ljBiMJtRZ1VvFGmQtkIvrLlBBB27MpjVbGloPnVGdBC1mKqUr5oQkvdieQ1P?=
 =?us-ascii?Q?+c4hvpQS21vrqO1jLlTTZPyR0hyg27APO5NEejBXelfIx1oN23Ulc0yNb7CB?=
 =?us-ascii?Q?VDlM+zos2dVgDnDLL+d58NXQElyXo8dp4TR6D2kHjjFV+eC0ASN5oIZpl3+9?=
 =?us-ascii?Q?xTxMD4ulrwG/hvXixHO8J7wz80mDYOHyZzohSOAh3zPogHtBSZakNSxgaP6y?=
 =?us-ascii?Q?3KHsibL++UMh8UTp13W2n9HWMAaofIB1EtEqLHNxsQ=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: c1f0e829-7a6a-48ac-345a-08da9b0a07fe
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2022 13:14:21.8361
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP4P284MB1874
X-Rspamd-Queue-Id: 4MX27k03jzz3JDn
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=ZoGvv9l6;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.104 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.39 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_MEDIUM(-0.92)[-0.915];
	NEURAL_HAM_LONG(-0.91)[-0.909];
	NEURAL_HAM_SHORT(-0.56)[-0.564];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[hotmail.com];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.96.104:from];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_EQ_ADDR_SOME(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On Mon, 19 Sep 2022, Ivan Quitschal wrote:

>
>
> On Mon, 19 Sep 2022, Hans Petter Selasky wrote:
>
>> Hi Ivan,
>> 
>> Can you also test this USB kernel patch? And revert your if_ure.c patch?
>> 
>> --HPS
>> 
>
> hi Hans,
>
> it *almost* worked ... everything was perfect , full speed 600/300 on the 
> first 5 tests (on sppedtest.net), on the 6th test, the same problem happened 
> unfortunately
>
> thanks
>
> --tzk
>
>

hi Hans

today i tested again and the problem ocurred right away at the first attempt :(
but the problem is definitely related to that constant and upload.
I got it back to 2048 and the problem never happened again. but of course , the 
upload speed also dropped back to 90mbps (instead of 300)

thanks

--tzk

From nobody Tue Sep 20 22:14:10 2022
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 4MXG6l0WPWz4cQ86
	for ; Tue, 20 Sep 2022 22:14:23 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXG6l02vjz3TXB
	for ; Tue, 20 Sep 2022 22:14:23 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663712063;
	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=ha0TvNYYaZCykTGG1Vwbo438Yo37nZM/l6dz3eY2Jy4=;
	b=mJPP+Z1yM8TNS3PZABV+pyF5MLfgdDDOcFAvpkZYCAHtgmZM8Yb1MGsBqtfDA1qMOYTekL
	GUCEmrNrr2kJRNzYfylZfWlA1vyHcsZMQrLnJ505ZTDyjz0ixMJf3M3cAjyt66xLYTHxL7
	oT2cMOktVV1Y4xBgL8xblRhtNYewlcxMIBqy561fn7ZHdrOg08z9xp7kW+uKwuEreqpNyk
	k9LrDPoMo5L//33g51YUUrndr2rBZ3f9ejy/TICQ0S3eFvD+zm5UGSAjvusa0Cv+jowrNl
	Hqu1v7LNLXxVuChfHspQeTvZy6CD4fL73lRaWJU6TCXwik1caOTLlQq0mXeFyQ==
Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MXG6k5xMPz1Cjl
	for ; Tue, 20 Sep 2022 22:14:22 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f180.google.com with SMTP id g185so2186898vkb.13
        for ; Tue, 20 Sep 2022 15:14:22 -0700 (PDT)
X-Gm-Message-State: ACrzQf2kLTe9xHSxd8WvxAWgFqkMZ+JEHxH7fdsKw90U0dWqetwcnVOM
	YVQmoxhsFmoxk/UbTJ/w+mywSxG8jVb3zcFSknA=
X-Google-Smtp-Source: AMsMyM7bksxQcpR6BxmHB1UBaytYVjuEwHeYbnhLnqqKq+wTFshbaNFYVCKLSxC7YeO4KNyWJ1t2+2hC2twitF4V4OA=
X-Received: by 2002:a1f:24d5:0:b0:3a2:f067:66f6 with SMTP id
 k204-20020a1f24d5000000b003a2f06766f6mr9327443vkk.13.1663712062030; Tue, 20
 Sep 2022 15:14:22 -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: Nuno Teixeira 
Date: Tue, 20 Sep 2022 23:14:10 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Good practices with bectl
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000774b4405e9232637"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663712063;
	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=ha0TvNYYaZCykTGG1Vwbo438Yo37nZM/l6dz3eY2Jy4=;
	b=P8VBb7ZN6wK9RVjhKEd7xkkb4ooTsQXvvvPlc7CUZf5acbQykHu4c3jjgRFjoq7btBLS7X
	pD04mlT33y2Jw2RtSNb4y+Zl6j0GBPmG0o9nZ0pNOyEkQl/nv7JcKXpIVDncsvh+MAb2n2
	MrdexHqkHx8bUBNVoRw5pm+0NFpSVGOMXF1dY38vGbDWOuUK2XToBinypYvc92vIX4T58U
	0oNGDE+kKVtByOCmHGUajD3reoDyhp2JdZp3esgxaBqFCO22lBgvKJn/8syM98FMPnqktO
	mceGhq8W1mcYAb8/6hAmvXnVbvxz7nd4AlYwi/PIWmAvr3AnNU4GAD7SZZkLKw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663712063; a=rsa-sha256; cv=none;
	b=V1fNlrL7/QanAt6zde/k8xCTwqZUH0MxXi7pppGFmZgiGajyhO0GlGbzQlgaMt18e9m4HJ
	F94ESTyYAD8R2u6gSthEwwR2wGpN6HuEH1/7vvJcd59MKqlLTow+tFtbE1CTZj3BYs8Sxn
	8otsWSlz6eNwweqRn5aNPAxBHDCAWX+siF2zy/G5WkVSgSZ4Wnzn/ptquCOyx5cWM5+uCK
	WAd4Vpc+x8zPlnL92BGu3vg+74qFxNq0byhLPZEUVSVUYb7Ws7TBys5z9Ev83y/y2LsRLF
	DXuhdwVOJyXD7YYq/VQYjxD3nS9/4Wv/KFK28VKfB87Ok4RKtXpCmsarwbZprQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000774b4405e9232637
Content-Type: text/plain; charset="UTF-8"

Hello to all,

I will use becl for the first time for current upgrades.
Just to check that I'm thinking correctly:

Create a test environment for upgrade:
> bectl create -r test (should I use '-r'?)
Activate test:
> bectl activate test
> reboot
...
> upgrade OS on test
> reboot
...
if a problem happens, reboot default from BE loader
---
if everything fine destroy default and rename test to default
> bectl destroy -o default
> bectl rename test default
repeat on next upgrade

Don't know if a faster way exists with chroot or bectl jail...

Any hints appreciated.

Thanks,
-- 
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000774b4405e9232637
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello to all,

I will use bec=
l for the first time for current upgrades.
Just to check that I&#=
39;m thinking correctly:

Create a test environment=
 for upgrade:
> bectl create -r test (should I use '-r'=
;?)
Activate test:
> bectl activate test
> reboot
...
> upgrade OS on test
> reboot
...
if a problem happens, reboot default =
from BE loader
---
if everything fine destroy defau=
lt and rename test to default
> bectl destroy -o default
> bectl rename test default
repeat on next upgrade

Don't know if a faster way exists with chroot or=
 bectl jail...

Any hints appreciated.
Thanks,
-- 
Nuno Teixeira
FreeBSD Committer (ports)


--000000000000774b4405e9232637--

From nobody Tue Sep 20 22:19:49 2022
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 4MXGFH3Gx3z4cR17
	for ; Tue, 20 Sep 2022 22:20:03 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXGFG4RPqz3Vlx;
	Tue, 20 Sep 2022 22:20:02 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: by mail-wm1-f43.google.com with SMTP id k3-20020a05600c1c8300b003b4fa1a85f8so107411wms.3;
        Tue, 20 Sep 2022 15:20:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=ONwegdLwly6e4zwA94wpT+sQIcHQBGhkR3fAbOblw3w=;
        b=ctfgU+uN9rnBjy+J6sd6aCHEf0mRvNg5G74k41i7NypLh367XUOO/f6XXyDPkFZqvB
         06LbdRopysB5qU5Nm50oGJZd8b/foRwNQkLVvqMx5LNSVqp1Ba42hxakee5gRvy2d7wg
         XxeP8h1dQ5n9F+J/5QGosP9vb6u0blEKTLfdQzj52k9euFEj+vRq01q7AcZwzSSucaV8
         XBgLP+E6SepaYucrjaTpmcNOalYrs8mJJoDGyksJSjFXPdK2L1/NSAQyS0qdn4ZUNDda
         wthItLcQggO7/g8LOrXMG3Jc/K/GPnTOZnOlM+NwUGEV+FXLunRl0so4vqvu20Fh/UI+
         PrKA==
X-Gm-Message-State: ACrzQf23/2IpBmtD2BymdjjqfRF6iJpk8pykVRV7pN31hnZOa+q+P4YR
	fwn1HoUkuysy4NoHuyBIbJ08yazubYwTGwoa5A7S6E4+zsU=
X-Google-Smtp-Source: AMsMyM4TJe6NO3eSFWNjip4exfCYPIdIMy3HIwGoCzbKWwpSARAFDXSrAOtY2bLLDxLbxyKMzmYttctMq0CX6DSinNI=
X-Received: by 2002:a7b:ca49:0:b0:3b4:7555:4dac with SMTP id
 m9-20020a7bca49000000b003b475554dacmr3833993wml.130.1663712400619; Tue, 20
 Sep 2022 15:20:00 -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: Alan Somers 
Date: Tue, 20 Sep 2022 16:19:49 -0600
Message-ID: 
Subject: Re: Good practices with bectl
To: Nuno Teixeira 
Cc: FreeBSD CURRENT 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MXGFG4RPqz3Vlx
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=asomers@gmail.com
X-Spamd-Result: default: False [-2.65 / 15.00];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	NEURAL_HAM_LONG(-0.90)[-0.903];
	NEURAL_HAM_MEDIUM(-0.75)[-0.753];
	FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	R_DKIM_NA(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.128.43:from];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.128.43:from];
	ARC_NA(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[asomers];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Sep 20, 2022 at 4:14 PM Nuno Teixeira  wrote:
>
> Hello to all,
>
> I will use becl for the first time for current upgrades.
> Just to check that I'm thinking correctly:
>
> Create a test environment for upgrade:
> > bectl create -r test (should I use '-r'?)
> Activate test:
> > bectl activate test
> > reboot
> ...
> > upgrade OS on test
> > reboot
> ...
> if a problem happens, reboot default from BE loader
> ---
> if everything fine destroy default and rename test to default
> > bectl destroy -o default
> > bectl rename test default
> repeat on next upgrade
>
> Don't know if a faster way exists with chroot or bectl jail...
>
> Any hints appreciated.
>
> Thanks,
> --
> Nuno Teixeira
> FreeBSD Committer (ports)

I don't think you need to use "-r".  Also, you're forgetting one of
the best things about boot environments: you can upgrade them even
when not booted into them.  That's faster than upgrading the running
BE.  Here is the procedure I use:

RELEASE=Whatever
sudo bectl create ${RELEASE}
sudo bectl mount ${RELEASE}
BASEDIR=/tmp/be_mount.XXXX    # Use mount point returned by bectl mount
sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update
upgrade -r ${RELEASE}
sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
# Ignore admonitions to reboot, since we're using a boot environment
sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
sudo bectl activate ${RELEASE}
sudo reboot

This general procedure works just as well if you're upgrading from source, too.

sudo make DESTDIR=${BASEDIR} installworld
sudo mergemaster -m $PWD -D $BASEDIR -U

-Alan

From nobody Tue Sep 20 23:09:46 2022
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 4MXHLv0CP8z4cZDl
	for ; Tue, 20 Sep 2022 23:09:59 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXHLt6tPqz3ZWB;
	Tue, 20 Sep 2022 23:09:58 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663715399;
	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=t6sCLKHkBPOMUakWRlQi490FGQQxBC9yn7Y8V8iBMI4=;
	b=tHxMPPi9h7vQB7dSFLYnDp/7Su3SenQsClSOFYRER/kN5UCi8/1ChB7+PfXvEhhDV6QHug
	/RyrqmkRFgUu/vRhK2fhh1JTBFo5LlRMKktV4un8QZnJfU7E8EqHUOfUs/ARAG5GSQK29K
	ZJbLqJYKbqZggN7dtg+sqUjJcqyyObH5nEqaah6YbgFhkhTFSQqaFf8Ca7ohEpGdle/gpU
	qp4cuYTfGyFIgfOhto9I/lB1tKJ+qaNI5/g2bsDRFTjLXvu7i6hOXD9GpIzk13/15jTgR6
	dJrL9svyg/519hYrUR7XzvV/v3rgZ2TRSxWegRrQYEWMEWh5mEjdl7tuIXbLFA==
Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MXHLt5dNlz1Cmq;
	Tue, 20 Sep 2022 23:09:58 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f172.google.com with SMTP id v192so2253772vkv.7;
        Tue, 20 Sep 2022 16:09:58 -0700 (PDT)
X-Gm-Message-State: ACrzQf2ro2XOWxuluY1QIptzj9SofPAIxGptSeeem/cst4Ez8rgWbyLh
	KQv4qynQiOfY8lYXzgtSYX610fMIHJ3uxFtlaC8=
X-Google-Smtp-Source: AMsMyM4QMgQlQh9kzvi0G8MPA+ERyEznKZgi++2tsdyqx07cMENx+5IooSCP9Yp8FDfHkOi8JZEodEGHecWxHmVpP7I=
X-Received: by 2002:a05:6122:990:b0:3a2:e74e:5995 with SMTP id
 g16-20020a056122099000b003a2e74e5995mr9088841vkd.25.1663715398373; Tue, 20
 Sep 2022 16:09: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: 
 
In-Reply-To: 
From: Nuno Teixeira 
Date: Wed, 21 Sep 2022 00:09:46 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Good practices with bectl
To: Alan Somers 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="00000000000053d8e805e923edf7"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663715399;
	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=t6sCLKHkBPOMUakWRlQi490FGQQxBC9yn7Y8V8iBMI4=;
	b=GqK+KA6DlzuV7igvUwHq9e1o5C7INjocpPa6LheHjv7eRgVTcM03OP1WQCPg4i3z5Ls6Wh
	yxqId6rODPtD2Eylxr/fKk7/EQtv/gFO6QPo6DKnby/ZmIeLyCDbJpHxjeBpWNqclfV+4E
	/ijSCzgC1Wp3pOkKPAxURYstOgZfs06wuTwGTa7RCqXqQ615X6bT3TiMr+6GjoxDk/JqXH
	7gw78I63Yo5FvR5WAz+JmcV2yWtTOwpbQz3oSy9iRf9JlsL/0VMX8+ZJrqoC1Uyvipi2kY
	A1upEBBxRbQ8ybWbt6lSXcrmrg/DAbi9EH3v6eW6HIzFDIPc4Kz8WPYn8lqfsQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663715399; a=rsa-sha256; cv=none;
	b=e/BxXwmM5r8epVEWLiWruWomRciaarbRNPzueZqi7IX2jc/Uq+Yp5wTBT3u8zz5sXt0E6T
	yL9jymiCPDXake24VDD7Hd88dd9hpA/n99mZbxIdmXXrrpulepva2EocDRfHAGUWjDlgc8
	/6qV4zhV3gPS933Knmvtk5dGklAFtOvxj/NZZsYz7yWz7tHjPY4GyWn3llPJkmXa/9w6N/
	JuBlkLnD5YZlkRvYwGfylOWAqMLhopym3VPwMc1/zvnMaddUyMd4XgG8G7Ly3uZuQDh6z0
	rAxx9Zk88GulfHWL6ZnWRupP2m8RMOXPwUqOA3oB4ioHzVFIB9QUfjtOitv3GQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--00000000000053d8e805e923edf7
Content-Type: text/plain; charset="UTF-8"

Hi Alan,

This general procedure works just as well if you're upgrading from source,
> too.
>
> sudo make DESTDIR=${BASEDIR} installworld
> sudo mergemaster -m $PWD -D $BASEDIR -U
>

(mergemaster -m  -D )

using etcupdate:
(etcupdate -s  -D ), source defaults to /usr/src

> etcupdate -D $BASEDIR

Need to find how to execute:
`make delete-old delete-old-libs` since $BASEDIR don't have /usr/src

Thanks
-- 
Nuno Teixeira
FreeBSD Committer (ports)

--00000000000053d8e805e923edf7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Alan,


This general procedure works just as well if you're upgrading from sour=
ce, too.



sudo make DESTDIR=3D${BASEDIR} installworld

sudo mergemaster -m $PWD -D $BASEDIR -U

(mergemaster -m </path/to/sources> -D </destdir/path>)

using etcupdate:
(etcupdate -s <source&g=
t; -D <destdir>), source defaults to /usr/src

> etcupdate -D $BASEDIR

Need to find how to e=
xecute:
`make delete-old delete-old-libs` since $BASEDIR don&=
#39;t have /usr/src

Thanks
-- 
Nuno Teixeira
FreeBSD Committer (ports)


--00000000000053d8e805e923edf7--

From nobody Tue Sep 20 23:11:41 2022
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 4MXHP53Wt5z4cZmc
	for ; Tue, 20 Sep 2022 23:11:53 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXHP534Xwz3bgX;
	Tue, 20 Sep 2022 23:11:53 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663715513;
	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=momNNGKvKiTWFsKUFTHvcfSHjWe4iQWLWCMwLZxvmnY=;
	b=sYTVRX664eL8MhPekTuz8LvQk+wi5Ei2Ve4lCskQ3r32xfxYMnXujfOfubsoZh5c3FsibR
	Xn45eB8dwG0sHsM2ZkzF2EuJq3HbNmK0gnCH1FYId2OT2NRK3RiYD3Sor1UCOHqSDY7yEH
	PhWpYid5FkwR7W0+wccXtPTkyobOUdP7TZWm04sOrtsp0U1peMQ7cgqI+2IWtosrEWvCV2
	e+uGOwQ0VlYdtIC7Bx69FNQoF+qsj6wAiarV+9PZI3ZCv1Fj7RPruMmE4ryCI7n1rdY124
	OFzaXAjNcoBBIu66CHg+U0b78OBqRUf7FvkyvrGzOinNbp1WM+5rR9Ui0fQ0gg==
Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MXHP527Jkz1CDf;
	Tue, 20 Sep 2022 23:11:53 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f169.google.com with SMTP id s12so2243486vkn.11;
        Tue, 20 Sep 2022 16:11:53 -0700 (PDT)
X-Gm-Message-State: ACrzQf1E/FX2eYNAffuCKo8QMwkqZBYBMxqkwn/8se3GkGWjyEsmc93z
	Uv/WSv8pAOxQ/9H5cpOyuEBn9KnOZ8Qyfc3nDQQ=
X-Google-Smtp-Source: AMsMyM4+GSE28A6euQyzK+xHzBOLdU7MHISvEGzaLoSWmmeO6PTDUlNrH1zrw0Bple1BbNWfn6xwlG6qq329RabFixU=
X-Received: by 2002:a1f:b6ca:0:b0:396:a637:61c8 with SMTP id
 g193-20020a1fb6ca000000b00396a63761c8mr9044852vkf.5.1663715512887; Tue, 20
 Sep 2022 16:11:52 -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: Nuno Teixeira 
Date: Wed, 21 Sep 2022 00:11:41 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Good practices with bectl
To: Alan Somers 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="00000000000027306f05e923f4d9"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663715513;
	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=momNNGKvKiTWFsKUFTHvcfSHjWe4iQWLWCMwLZxvmnY=;
	b=VKLtCRD62EVWtlriTlPwWJTpCx1PkB75LpL4JAiSu8a+5EgoBH2tntDav4pyjBECvWqq8V
	AW+xnjGlg8VtArcsQ55CM9HDDEEUv4hjCV4FdBi8Ptdn7uvij/Ll/RhuUfUpnXvdzoOV55
	hRHpGUgrwwsg+c405t7Tgw+Mj3IOsxjMB3au6IyIpcXE+biANusnEppoUCFvFhRnsWXwpi
	BRZwJKyYvxbQtr657PZuo8EYpmkjNEjWpZhyVb0N8GZlcoxUQVKnk1nsrjhEq8bql1g8em
	Y9YxwYApKoJ8YAYKET5UfcrG0sj/2uTfvfKP1zzWevOvqeUdRhAUi04Q92jkiw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663715513; a=rsa-sha256; cv=none;
	b=DQmwMlK0K0aI7fSxuHSoqBDoURnZfGx3nDNeadxB3kr8LB7aMp3q4JMYDUru6G/ldFeFil
	zivYYvgjdhxkV2D9WMF7o21IH54l980roq02bnNvNwLp2VZWaUeeAfN+1xopM3/3gT4EkM
	hoUPpSsYZPpqzT6J9kizD/y8AADYGeRGPnXtO+2TRsNNjyHPUqKkpZQ9roJaOLFmw9thda
	LQW/O4cpxwiRWNnqlsYnS4MZJAoD+8vjDYYsTTEq3W23oxfU2houftJecVptkfLZ6Lq7+g
	nug1TlMVi7mzfnKsnLxB+mXdKptW6Y9a1YuEgjdCZDQIdmhZ9D1HFOYmXTjN/Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--00000000000027306f05e923f4d9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

(...)
maybe:
> yes | make DESTDIR=3D${BASEDIR} delete-old delete-old-libs

Nuno Teixeira  escreveu no dia quarta, 21/09/2022 =C3=
=A0(s)
00:09:

> Hi Alan,
>
> This general procedure works just as well if you're upgrading from source=
,
>> too.
>>
>> sudo make DESTDIR=3D${BASEDIR} installworld
>> sudo mergemaster -m $PWD -D $BASEDIR -U
>>
>
> (mergemaster -m  -D )
>
> using etcupdate:
> (etcupdate -s  -D ), source defaults to /usr/src
>
> > etcupdate -D $BASEDIR
>
> Need to find how to execute:
> `make delete-old delete-old-libs` since $BASEDIR don't have /usr/src
>
> Thanks
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--00000000000027306f05e923f4d9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


(...)
maybe:
> yes | make =
DESTDIR=3D${BASEDIR} delete-old delete-old-libs

Nuno Teixeira <=
eduardo@freebsd.org> escreveu=
 no dia quarta, 21/09/2022 =C3=A0(s) 00:09:
Hi Alan,
<=
/div>

This general procedure works just as well if you're upgrading from sour=
ce, too.



sudo make DESTDIR=3D${BASEDIR} installworld

sudo mergemaster -m $PWD -D $BASEDIR -U

(mergemaster -m </path/to/sources> -D </destdir/path>)

using etcupdate:
(etcupdate -s <source&g=
t; -D <destdir>), source defaults to /usr/src

> etcupdate -D $BASEDIR

Need to find how to e=
xecute:
`make delete-old delete-old-libs` since $BASEDIR don&=
#39;t have /usr/src

Thanks
-- 
Nuno =
Teixeira
FreeBSD Committer (ports)




-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--00000000000027306f05e923f4d9--

From nobody Tue Sep 20 23:17:13 2022
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 4MXHWQ3szxz4cb6l
	for ; Tue, 20 Sep 2022 23:17:22 +0000 (UTC)
	(envelope-from paul@gromit.dlib.vt.edu)
Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.123])
	(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 4MXHWP31pkz3crk;
	Tue, 20 Sep 2022 23:17:21 +0000 (UTC)
	(envelope-from paul@gromit.dlib.vt.edu)
Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::5])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 81F806B4A1;
	Tue, 20 Sep 2022 19:17:14 -0400 (EDT)
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 \(3696.120.41.1.1\))
Subject: Re: Good practices with bectl
From: Paul Mather 
In-Reply-To: 
Date: Tue, 20 Sep 2022 19:17:13 -0400
Cc: Nuno Teixeira ,
 FreeBSD CURRENT 
Content-Transfer-Encoding: quoted-printable
Message-Id: <780F7E98-661B-49B5-BF0C-1E5A7EB7F1EE@gromit.dlib.vt.edu>
References: 
 
To: Alan Somers 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MXHWP31pkz3crk
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.126.123) smtp.mailfrom=paul@gromit.dlib.vt.edu
X-Spamd-Result: default: False [-2.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.989];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none];
	MIME_TRACE(0.00)[0:+];
	TO_DN_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_COUNT_TWO(0.00)[2];
	R_SPF_NA(0.00)[no SPF record];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FREEFALL_USER(0.00)[paul];
	ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sep 20, 2022, at 6:19 PM, Alan Somers  wrote:

> On Tue, Sep 20, 2022 at 4:14 PM Nuno Teixeira  =
wrote:
>>=20
>> Hello to all,
>>=20
>> I will use becl for the first time for current upgrades.
>> Just to check that I'm thinking correctly:
>>=20
>> Create a test environment for upgrade:
>>> bectl create -r test (should I use '-r'?)
>> Activate test:
>>> bectl activate test
>>> reboot
>> ...
>>> upgrade OS on test
>>> reboot
>> ...
>> if a problem happens, reboot default from BE loader
>> ---
>> if everything fine destroy default and rename test to default
>>> bectl destroy -o default
>>> bectl rename test default
>> repeat on next upgrade
>>=20
>> Don't know if a faster way exists with chroot or bectl jail...
>>=20
>> Any hints appreciated.
>>=20
>> Thanks,
>> --
>> Nuno Teixeira
>> FreeBSD Committer (ports)
>=20
> I don't think you need to use "-r".  Also, you're forgetting one of
> the best things about boot environments: you can upgrade them even
> when not booted into them.  That's faster than upgrading the running
> BE.  Here is the procedure I use:
>=20
> RELEASE=3DWhatever
> sudo bectl create ${RELEASE}
> sudo bectl mount ${RELEASE}
> BASEDIR=3D/tmp/be_mount.XXXX    # Use mount point returned by bectl =
mount
> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update
> upgrade -r ${RELEASE}
> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update =
install
> # Ignore admonitions to reboot, since we're using a boot environment
> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update =
install
> sudo bectl activate ${RELEASE}
> sudo reboot
>=20
> This general procedure works just as well if you're upgrading from =
source, too.
>=20
> sudo make DESTDIR=3D${BASEDIR} installworld
> sudo mergemaster -m $PWD -D $BASEDIR -U


There's even a handy tool in /usr/src/tools/build that can be used as a =
wrapper to install a SRC build into a new boot environment.  It's =
/usr/src/tools/build/beinstall.sh (see man beinstall(8) for details).  =
It will create a new boot environment from a source build, run etcupdate =
and so forth, and even mark the new boot environment as the one to be =
active on reboot.  All you need to do is reboot.  I've been using it for =
source upgrades for a while now without problems.  The best thing, for =
me, is it cuts out all that time doing "make installworld" and etcupdate =
in single user mode, thus minimising downtime.

Cheers,

Paul.


From nobody Wed Sep 21 00:24:54 2022
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 4MXK1b2Z4nz4cn4l
	for ; Wed, 21 Sep 2022 00:25:07 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXK1b23x6z3jwS;
	Wed, 21 Sep 2022 00:25:07 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663719907;
	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=9DJYAGjvbMI9I6Le3gGddBVu/A7ob4CoVOzl7SFTcTE=;
	b=v8e6NKQsO2e8OOymBmZJpkmLoRzxxE85Hb3TahTl7vYhkDa8rAuiwhAxJemM/0aVI4WDRE
	3121rtA3Paa48GbinUOGi9Xtr2sgF38PunvNon3z+H6rbHjZUoRZgNfYHAqbhf6jWy/OVr
	rcNXTkUAf7fp2/oTM0WUhqismF99q8ppXcapYONA0beaZeQBcSK3fxQPtzQ1MEpVqrIsdx
	as6IUXnHcLFpvZb4XsTEe9HKMS9XZneJmsbC0qD3pbppT8XlNouE542vd4zYTuz8gVo5ia
	RiLGJG1CLm+9gnUAWToYGZfr6VJD5mLZv3ocso088d/BBioTwYZ0AchZ/J6PVw==
Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MXK1b0xqXz1D4Z;
	Wed, 21 Sep 2022 00:25:07 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f43.google.com with SMTP id a129so5065277vsc.0;
        Tue, 20 Sep 2022 17:25:07 -0700 (PDT)
X-Gm-Message-State: ACrzQf3O1c9B/8mf3IAi/11xgI6q7+t8NW9mmUvZQ31rXH3RWlq7USaB
	ZLWIYM7UwlxlklQDjiRa5Qiz8ijcOSbEKSR2emw=
X-Google-Smtp-Source: AMsMyM666UnRsr0tFiXyi0IotSOoCG1kSo41Xk9a6jG6utly1Q/FX8BVRkfuHsS9wS3wGk/I2+uQu2n0n9s2pSKW2Ps=
X-Received: by 2002:a67:a202:0:b0:39b:181d:bd20 with SMTP id
 l2-20020a67a202000000b0039b181dbd20mr4096917vse.51.1663719906299; Tue, 20 Sep
 2022 17:25:06 -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: 
  <780F7E98-661B-49B5-BF0C-1E5A7EB7F1EE@gromit.dlib.vt.edu>
In-Reply-To: <780F7E98-661B-49B5-BF0C-1E5A7EB7F1EE@gromit.dlib.vt.edu>
From: Nuno Teixeira 
Date: Wed, 21 Sep 2022 01:24:54 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Good practices with bectl
To: Paul Mather 
Cc: Alan Somers , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000055b0605e924fa53"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663719907;
	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=9DJYAGjvbMI9I6Le3gGddBVu/A7ob4CoVOzl7SFTcTE=;
	b=iIISb+L8DR92mgG+kv/vqEm6f7xeraZikmNCTlkC2p9X8+n9d/DctSKCVmBi19kFUtSHiu
	WAc5Vm0WniW9adoaN685RkoDzD0ntZUuywnoK9mHBHwtM74kYRtRKa0tI1OWhCL0TLvHbo
	Y/0iHSVqG7usSEgfS5xG/vAklrs9tAzSHkqAkAi49VbQIB2RV/LFBI1yfWiQY/dSCxFWfK
	xSKq9ctoGX5NijykY8tbYdfiReh+RMfKKfepdL0LxoY9AOVtrZ0eDDF9QBTh1L6sH3jR8m
	poriXRBJxYDYCqkcawiiSYmhDJCfd8B4PVTManVahGAW/em6xuEDph78gJEgrw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663719907; a=rsa-sha256; cv=none;
	b=vUANhd0mJC+Ktj9PB+CPRJs0O+llZxYC1vBJujmQl46i8TK5b7H/sbcjVjZL1T/Xz1fwRu
	gGWUTUw6dyTzYo26cntTlLNPy5JxGCRl8oWj2H7UMSraGmSYsBn5wcWw56l5H6ilTWj6dU
	VuM9oGiA3Fc7gfsePp1DFIFwUPJLQ3ikZMWQCxT32xSWTk7sb9Xzp1mwc5GGTefGNBNsbK
	NP3LWX0SU4yYetDMK3XquB+zSjOks7D/pkzlkDiIOkrVXN4Cc34+jsSLT4b/W/KAEfT3IN
	yMOvHCmwaIQqr2gN0d5kgkFwW/m9jV5jH4abl9piIP7yY9Th+CtxwFR5Anw4hQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000055b0605e924fa53
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Paul,

Really nice! I will test it soon.

Cheers

Paul Mather  escreveu no dia quarta, 21/09/2022
=C3=A0(s) 00:17:

> On Sep 20, 2022, at 6:19 PM, Alan Somers  wrote:
>
> > On Tue, Sep 20, 2022 at 4:14 PM Nuno Teixeira 
> wrote:
> >>
> >> Hello to all,
> >>
> >> I will use becl for the first time for current upgrades.
> >> Just to check that I'm thinking correctly:
> >>
> >> Create a test environment for upgrade:
> >>> bectl create -r test (should I use '-r'?)
> >> Activate test:
> >>> bectl activate test
> >>> reboot
> >> ...
> >>> upgrade OS on test
> >>> reboot
> >> ...
> >> if a problem happens, reboot default from BE loader
> >> ---
> >> if everything fine destroy default and rename test to default
> >>> bectl destroy -o default
> >>> bectl rename test default
> >> repeat on next upgrade
> >>
> >> Don't know if a faster way exists with chroot or bectl jail...
> >>
> >> Any hints appreciated.
> >>
> >> Thanks,
> >> --
> >> Nuno Teixeira
> >> FreeBSD Committer (ports)
> >
> > I don't think you need to use "-r".  Also, you're forgetting one of
> > the best things about boot environments: you can upgrade them even
> > when not booted into them.  That's faster than upgrading the running
> > BE.  Here is the procedure I use:
> >
> > RELEASE=3DWhatever
> > sudo bectl create ${RELEASE}
> > sudo bectl mount ${RELEASE}
> > BASEDIR=3D/tmp/be_mount.XXXX    # Use mount point returned by bectl mou=
nt
> > sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update
> > upgrade -r ${RELEASE}
> > sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update
> install
> > # Ignore admonitions to reboot, since we're using a boot environment
> > sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update
> install
> > sudo bectl activate ${RELEASE}
> > sudo reboot
> >
> > This general procedure works just as well if you're upgrading from
> source, too.
> >
> > sudo make DESTDIR=3D${BASEDIR} installworld
> > sudo mergemaster -m $PWD -D $BASEDIR -U
>
>
> There's even a handy tool in /usr/src/tools/build that can be used as a
> wrapper to install a SRC build into a new boot environment.  It's
> /usr/src/tools/build/beinstall.sh (see man beinstall(8) for details).  It
> will create a new boot environment from a source build, run etcupdate and
> so forth, and even mark the new boot environment as the one to be active =
on
> reboot.  All you need to do is reboot.  I've been using it for source
> upgrades for a while now without problems.  The best thing, for me, is it
> cuts out all that time doing "make installworld" and etcupdate in single
> user mode, thus minimising downtime.
>
> Cheers,
>
> Paul.
>
>
>

--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000055b0605e924fa53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Paul,

Really nice! I will=
 test it soon.

Cheers

Paul Mather <paul@gromit.dlib.vt.edu> esc=
reveu no dia quarta, 21/09/2022 =C3=A0(s) 00:17:
On Sep 20, 2022, at 6:19 PM, Alan Somers &=
lt;asomers@freebsd=
.org> wrote:



> On Tue, Sep 20, 2022 at 4:14 PM Nuno Teixeira <eduardo@freebsd.org> wrote:

>> 

>> Hello to all,

>> 

>> I will use becl for the first time for current upgrades.

>> Just to check that I'm thinking correctly:

>> 

>> Create a test environment for upgrade:

>>> bectl create -r test (should I use '-r'?)

>> Activate test:

>>> bectl activate test

>>> reboot

>> ...

>>> upgrade OS on test

>>> reboot

>> ...

>> if a problem happens, reboot default from BE loader

>> ---

>> if everything fine destroy default and rename test to default

>>> bectl destroy -o default

>>> bectl rename test default

>> repeat on next upgrade

>> 

>> Don't know if a faster way exists with chroot or bectl jail...=


>> 

>> Any hints appreciated.

>> 

>> Thanks,

>> --

>> Nuno Teixeira

>> FreeBSD Committer (ports)

> 

> I don't think you need to use "-r".=C2=A0 Also, you'=
re forgetting one of

> the best things about boot environments: you can upgrade them even

> when not booted into them.=C2=A0 That's faster than upgrading the =
running

> BE.=C2=A0 Here is the procedure I use:

> 

> RELEASE=3DWhatever

> sudo bectl create ${RELEASE}

> sudo bectl mount ${RELEASE}

> BASEDIR=3D/tmp/be_mount.XXXX=C2=A0 =C2=A0 # Use mount point returned b=
y bectl mount

> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update<=
br>
> upgrade -r ${RELEASE}

> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update =
install

> # Ignore admonitions to reboot, since we're using a boot environme=
nt

> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update =
install

> sudo bectl activate ${RELEASE}

> sudo reboot

> 

> This general procedure works just as well if you're upgrading from=
 source, too.

> 

> sudo make DESTDIR=3D${BASEDIR} installworld

> sudo mergemaster -m $PWD -D $BASEDIR -U





There's even a handy tool in /usr/src/tools/build that can be used as a=
 wrapper to install a SRC build into a new boot environment.=C2=A0 It's=
 /usr/src/tools/build/beinstall.sh (see man beinstall(8) for details).=C2=
=A0 It will create a new boot environment from a source build, run etcupdat=
e and so forth, and even mark the new boot environment as the one to be act=
ive on reboot.=C2=A0 All you need to do is reboot.=C2=A0 I've been usin=
g it for source upgrades for a while now without problems.=C2=A0 The best t=
hing, for me, is it cuts out all that time doing "make installworld&qu=
ot; and etcupdate in single user mode, thus minimising downtime.



Cheers,



Paul.








-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--000000000000055b0605e924fa53--

From nobody Wed Sep 21 00:41:51 2022
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 4MXKNx10X9z4cqNS
	for ; Wed, 21 Sep 2022 00:41:53 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXKNx08RFz3mCj
	for ; Wed, 21 Sep 2022 00:41:53 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663720913;
	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=BEjEzqimlNw4dqjwk2xj1mVi1Bs5Ytz0US3KIF7OHgA=;
	b=D98QuZZD3Kakn8lFPt0A2CUiyM/GRzsjgDSjef8MVT91vRtJQenI4dpr8JhXhw3iLZ910q
	shCSI2piyyl653sU4fmiZ+gs+TciblxgJeuPCLkXWQ5FNNV0Q5CUenOJifMbE4fK3wAew0
	hBoJzFuiCHi4NMxXF/AUqYL7qMu4NxcoLNMUJDosScWBn2G+3/11HtzsLoxcQWnyAgwAUj
	NS70becGM1NMr9nwxGaTRRt3SKNtI90uygti2QxzMKW9+ZOfXa4HSTWAp7ld9JquNz17od
	eHQFwxzF2Uzn7ToUL4vD/n3X3QeRkbmSuRD3pcovafoZGOUchkLjeplM8SnGzQ==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MXKNw50k8z1D2G
	for ; Wed, 21 Sep 2022 00:41:52 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: <66e3b639-5490-77cc-93dc-9e8d5f6431d3@freebsd.org>
Date: Wed, 21 Sep 2022 01:41:51 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: beinstall(8) (was: Good practices with bectl)
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: 
 
 <780F7E98-661B-49B5-BF0C-1E5A7EB7F1EE@gromit.dlib.vt.edu>
From: Graham Perrin 
Organization: FreeBSD
In-Reply-To: <780F7E98-661B-49B5-BF0C-1E5A7EB7F1EE@gromit.dlib.vt.edu>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------mpG0SDuFpRNrwIukARgNyCxV"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663720913;
	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=BEjEzqimlNw4dqjwk2xj1mVi1Bs5Ytz0US3KIF7OHgA=;
	b=ouI0zFOMtqLzYwHu/suwBCeH+5bontkJHwJCCFHSMDBw3O2FwBKqS+JCzugEp2p63AhRYY
	Voyc/3fHqjwxnQpFL2PrvJs2nKgCmJOsPhOjNj7Wpzp7vorXpfDvdA4uI03ry3BbHp0yb2
	eTeGuqzWt1COjLxIeEE1czxIvic4thm5hhpsVeqRRbpo5b30+j0U7Gx+4rCpkO3lyuLstX
	I/pwiAd3qcEwNbWZNaLqeVDkue8AaXcIhiWI2/5pXiS/vDWsFsxLs3j4dUB1OrY9qemRGo
	z3VRxkqjxhhRSmm+KARROaG+PnDVI3syqAvzclhuz7sZTOwsyeQ/vojdByKgAQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663720913; a=rsa-sha256; cv=none;
	b=HG8JrcFX43PJqHb8tlHoMPd+ejuIEw4W9jW4IS6r90DpWLf8e1qvLV2b1+paSVd51+5A3z
	mWKs0eDGZ6ONHUiyaXPxB8vVXUeFlxwO+xv8GsVKeUP+1Y2r4zSxH3fRR0BwX27we4hiyP
	/5VWdLE3s+h7oosM0NncvTvT+J9oIwNhAhzHQHVlGYFTxVXqH9ARyiGlkf0WKrUjwyJwcl
	nfb2XX8smC7xFZJl7hPLE2tmKZUeT3FBWO+1IVGkAPoukCZND3sks0V6ZV1E7JveCINKaQ
	+r2VToAjX4AQoNCiiSWoFdaqsHdgAuUmgCVuPomAtvIDy6TVReIYn3DY02yKGQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------mpG0SDuFpRNrwIukARgNyCxV
Content-Type: multipart/mixed; boundary="------------JaFPHU20wIxwJPIdNbR4cM7c";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: <66e3b639-5490-77cc-93dc-9e8d5f6431d3@freebsd.org>
Subject: beinstall(8) (was: Good practices with bectl)
References: 
 
 <780F7E98-661B-49B5-BF0C-1E5A7EB7F1EE@gromit.dlib.vt.edu>
In-Reply-To: <780F7E98-661B-49B5-BF0C-1E5A7EB7F1EE@gromit.dlib.vt.edu>

--------------JaFPHU20wIxwJPIdNbR4cM7c
Content-Type: multipart/alternative;
 boundary="------------jwnXiCZHwgoRE5V0oziA27bU"

--------------jwnXiCZHwgoRE5V0oziA27bU
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjEvMDkvMjAyMiAwMDoxNywgUGF1bCBNYXRoZXIgd3JvdGU6DQoNCj4g4oCmIGEgaGFu
ZHkgdG9vbCBpbiAvdXNyL3NyYy90b29scy9idWlsZCB0aGF0IGNhbiBiZSB1c2VkIGFzIGEg
d3JhcHBlciANCj4gdG8gaW5zdGFsbCBhIFNSQyBidWlsZCBpbnRvIGEgbmV3IGJvb3QgZW52
aXJvbm1lbnQuIEl0J3MgDQo+IC91c3Ivc3JjL3Rvb2xzL2J1aWxkL2JlaW5zdGFsbC5zaCAo
c2VlIG1hbiBiZWluc3RhbGwoOCkgZm9yIGRldGFpbHMpLiDigKYNCg0KVGhhbmtzLiBGWUk6
DQoNCmJlaW5zdGFsbC5zaCg4KSBzaG91bGQgYmUgaW4gdGhlIEZyZWVCU0QgSGFuZGJvb2sN
CjxodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTI2
MzQ5ND4NCg0KYmVpbnN0YWxsLnNoIHdpdGggYSBwb3J0OiBpbnN0YWxsa2VybmVsIGZhaWxl
ZCwgY2hyb290ZWQgbWFrZSBpbiANCi90bXAvYmVpbnN0YWxsLuKLry9tbnQgZmFpbGVkDQo8
aHR0cHM6Ly9idWdzLmZyZWVic2Qub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0yNjM2
MjA+DQoNCg==
--------------jwnXiCZHwgoRE5V0oziA27bU
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 21/09/2022 00:17, Paul Mather wrote:

    

    
=E2=80=A6
      a handy tool in /usr/src/tools/build that can be used as a wrapper
      to install a SRC build into a new boot environment. It's
      /usr/src/tools/build/beinstall.sh (see man beinstall(8) for
      details). =E2=80=A6

    

    
Thanks. FYI: 

    

    
beinstall.sh(8) should be in
          the FreeBSD Handbook

      <https://bugs.freebsd.org/bugzilla=
/show_bug.cgi?id=3D263494>

    
beinstall.sh with a port:
          installkernel failed, chrooted make in /tmp/beinstall.=E2=8B=AF=
/mnt
          failed

      <https://bugs.freebsd.org/bugzilla=
/show_bug.cgi?id=3D263620>

  
  


--------------jwnXiCZHwgoRE5V0oziA27bU--

--------------JaFPHU20wIxwJPIdNbR4cM7c--

--------------mpG0SDuFpRNrwIukARgNyCxV
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmMqXc8FAwAAAAAACgkQt2dIb0oY1Auo
eQ//SyXOusulhOFI408KgCqWe1GlmO3S/BNmovVptO8B40hV+Mk3LtSipYvygUhzqa2qM6tdolBp
2voTpx27y3SZILuqWGyK/5vkluienu50EY+/HNbYobFL58mtPqduQudJMFfXlIkfGnvXSEy4MsDU
rOwv7lcwH/+TKB2sEElE0h39WZo5FNyoeG/qeUdp5Jq3P7YR6AUtpEql3zjl4zRzSKE/UvPR3J4L
rjnzhcOAJnHGdsiWOXddMKdyMXFxKCUgAK9XArSrEWpHUytL/KGK0XubO/wYIWknzovMVnbgpGcs
8hCVIiiKk5f8FHRw2ybVjiw6MKaA70A9izaGKQef00CDeE1Qd3ARC4kfk+apDRtsI/tzvg+EYtzU
mN644NSM6IRdoGU4FANncHrapRcztdtpqFIUYzHN3kJNQ8gad/wmsRzU7BJFAUnlLVt0vGyRsFII
rRDfK6eRt2SOLOMJyFoExXjMYESOmTLaNz9qScKcypyYb8q95f++QfEJFgfwYUuzCkqRgWfUll0L
bmfLYx/AnjJEJX2H8XvRdQ0OrH0UoL1/s2DhI+pKPcHMWUE1c+gok8Ehyk3/1SwjbUuNbe/zed80
Zz+nRn1BjR12Vje7DrP2ClZ8e0kFtjOWb4VFjPldh8WlsAGzijFWp/79bNb+ntLhqRxAMzTmqqXn
Q6A=
=6fPO
-----END PGP SIGNATURE-----

--------------mpG0SDuFpRNrwIukARgNyCxV--

From nobody Wed Sep 21 00:47:18 2022
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 4MXKWG299jz4cqwN
	for ; Wed, 21 Sep 2022 00:47:22 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXKWG1TNxz3nRN
	for ; Wed, 21 Sep 2022 00:47:22 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663721242;
	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=pDaie6/Qt2O4wYg+TQ9sSUXgH9QP1rxALa9JxXlrHRQ=;
	b=UGFlVU+OwrjDMsfJ83PZETbqLPzsb9/UXVxWAU+nkgWE+PJX2jVhplsGTDh2tiR180T/1u
	w0svWRI4CPe3yWNKTBHlWNUHmtJuwpfIuU4Is7ifsAbuSsGcL88Qvn31Xq5HmcItyCAcSp
	FQERys6fuW5K32/cclOs0L0yw0SglR8LuZlN54j1Vt7qm/HEZO4yWSt74NuLWrzs9IERPk
	AVS4Cc449Y67JBirLMNK5lmk/042LIFIfAEtwnHE0yXSgSj7L1YTUM9u0aZCJq8Ldqra+h
	ASkGBCwhEBpqDFB+DpJe8MMU0DnpuP4HERZciO6eXEwrD6hVvrGHaWbg9dOlAw==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MXKWD4S44z1Cnw
	for ; Wed, 21 Sep 2022 00:47:20 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: <35f04731-8daa-53de-d28a-96bae81146ca@freebsd.org>
Date: Wed, 21 Sep 2022 01:47:18 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: Good practices with bectl
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: 
From: Graham Perrin 
Organization: FreeBSD
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------HuzgY0vvUXdVgEIsK19IOP3a"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663721242;
	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=pDaie6/Qt2O4wYg+TQ9sSUXgH9QP1rxALa9JxXlrHRQ=;
	b=RjIGg1Cjsoff8mE0rb0C3SwdG56jYK3ucAovyj2CgN1y5jhngjZ4YdH7HqZzR7RDQhZbaS
	cj94m6hcPokhZL1pBOsr/9FcGZDLvMIMlSnG5Xie8nqUrg8gXy724AqMjCNbsBucbraNaA
	2NBBUGHQbnp0A4IzM7vqUOF0jXcHoBupKmzy+MdsOBcLfhIrL+odlA4IQCc/Cw8yAnWfWu
	S/RHKh2FWiuS3QfGfyirHK3dGbxUVerU7VCwNsnLNQcrZrGEs6qISLstfN7W7X5Gmr4Kpa
	oCd1lDpcUm14xv7aAmFc76eLulsbwrzNCuZtLPZ39YFdd0oXx9DEqeSXKevEbA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663721242; a=rsa-sha256; cv=none;
	b=fKoBcz7IZELXee/dnyX65jXIphyRDqI7FUnupwXRBYxKosjz9vlHJLJrdrUiKIOIR4qspk
	WAN8Zp6VQfxlo4JdeGrKIxjREpe92pjOiylFyKWml6G+ctE6Kl8MXKaDFlVe1XiTwIvclg
	53IK3DdG61a3+cEOx3A159niyDpKgGSLVbRaz88n4LO0jh7GEpUxkb1HEPE698FKTEyyTK
	jeAyaXuk3ThQw5a7O0DlO80UsiCwDl1OnM9KiEcW8D1itDBhXAt0MUMaDt52uk5PwPukff
	3PsygRRCzp3sEqG51ENGh6TgnZ4gp1Dj/8nBHTEKhK+sNz8VP1k6WHNR//ZNhQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------HuzgY0vvUXdVgEIsK19IOP3a
Content-Type: multipart/mixed; boundary="------------ZwgkQ2ZS04o20aPlM0WPVNHX";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: <35f04731-8daa-53de-d28a-96bae81146ca@freebsd.org>
Subject: Re: Good practices with bectl
References: 
In-Reply-To: 

--------------ZwgkQ2ZS04o20aPlM0WPVNHX
Content-Type: multipart/alternative;
 boundary="------------SmvYqTt8crcNPOuLhnFfA0BY"

--------------SmvYqTt8crcNPOuLhnFfA0BY
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjAvMDkvMjAyMiAyMzoxNCwgTnVubyBUZWl4ZWlyYSB3cm90ZToNCg0KPiBIZWxsbyB0
byBhbGwsDQo+DQo+IEkgd2lsbCB1c2UgYmVjbCBmb3IgdGhlIGZpcnN0IHRpbWUgZm9yIGN1
cnJlbnQgdXBncmFkZXMuDQo+IEp1c3QgdG8gY2hlY2sgdGhhdCBJJ20gdGhpbmtpbmcgY29y
cmVjdGx5Og0KPg0KPiBDcmVhdGUgYSB0ZXN0IGVudmlyb25tZW50IGZvciB1cGdyYWRlOg0K
PiA+IGJlY3RsIGNyZWF0ZSAtciB0ZXN0IChzaG91bGQgSSB1c2UgJy1yJz8pDQo+IEFjdGl2
YXRlIHRlc3Q6DQo+ID4gYmVjdGwgYWN0aXZhdGUgdGVzdA0KPiA+IHJlYm9vdA0KPiAuLi4N
Cj4gPiB1cGdyYWRlIE9TIG9uIHRlc3QNCj4g4oCmDQpJZiB1c2luZyBmcmVlYnNkLXVwZGF0
ZSg4KSB0byBwZXJmb3JtIHRoZSB1cGdyYWRlOiBwbGVhc2UgYmUgYXdhcmUgdGhhdCwgDQp3
aXRoIHJlY2VudCByZWxlYXNlcyBvZiB0aGUgT1MsIHRoZXJlJ3MgYXV0b21hdGVkIGNyZWF0
aW9uIG9mIGEgc25hcHNob3QgDQpvZiBhIGJvb3QgZW52aXJvbm1lbnQuDQoNCjxodHRwczov
L3d3dy5mcmVlYnNkLm9yZy9jZ2kvbWFuLmNnaT9xdWVyeT1mcmVlYnNkLXVwZGF0ZS5jb25m
JnNla3Rpb249NSZtYW5wYXRoPUZyZWVCU0Q+LCANCkNyZWF0ZUJvb3RFbnYNCg0KT21pdHRl
ZCBmcm9tIHJlbGVhc2Ugbm90ZXM7IHNvcnJ5Lg0KDQo=
--------------SmvYqTt8crcNPOuLhnFfA0BY
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 20/09/2022 23:14, Nuno Teixeira wrote:

    

    

      
      

        
Hello to all,

        


        

        
I will use becl for the first time for current upgrades.
        
Just to check that I'm thinking correctly:

        


        

        
Create a test environment for upgrade:

        
> bectl create -r test (should I use '-r'?)

        

        
Activate test:

        
> bectl activate test

        
> reboot

        

        
...

        
> upgrade OS on test

        =E2=80=A6

      

    

    If using freebsd-update(8) to perform the upgrade: please be aware
    that, with recent releases of the OS, there's automated creation of
    a snapshot of a boot environment. 

    
<https://www.freebsd.org/cgi/man.cgi?query=3Dfreebsd-update.con=
f&sektion=3D5&manpath=3DFreeBSD>,
      CreateBootEnv

    
Omitted from release notes; sorry. 

    

  
  


--------------SmvYqTt8crcNPOuLhnFfA0BY--

--------------ZwgkQ2ZS04o20aPlM0WPVNHX--

--------------HuzgY0vvUXdVgEIsK19IOP3a
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmMqXxYFAwAAAAAACgkQt2dIb0oY1Av7
Cw/+INFLHMp8T/8GRTeZIADPjE7ZF1rnUaH44gbrWcVcNppQWXoQseWbKAMjcLgj8u80NCQrmfB+
pNBQBaW2/3tdNq03cVmEeXgRpuX3m950lSgVfmV+4J/qlRHtRUHFxXxrHNQQUfDocffzqZAh+EI1
dXSkZDbEK4fhg66JKyRU+IfopOqkU4nW/Iqmp1023H2VjHh3h4i4tpZIHIjybyC43HS+rX6PS30v
K6t5wOtqSkzOB3sR/OrtrNQfi3gZRZsWq8ZYJB+sfycFV3oxPKL7molYM4gsiLVCy1biejA+3RVj
GD5nhftxYtWZa01vsBck26j9m1mS1Zp6RxzS5r1IXREn/inh90Z4Dmw0F0mWmruh4nx/5C7Iz70d
5+h1ssqritdNZqJqL5qMLX9G6rLNzEAL7A2GxXMoigPjUpPsdI+e8b1sMat5XCgqsc9PKyzuMskd
5/0+U1gPZesR3cXiQ3kKm80YNNr3xkSIC+aQo6sZ96SKGX//Fqs8jv0/AT+YDNKFeGJfiBq3siKy
pP9u6VLVbzm9h43Yk2Hu2vlWTEpTF1uFeo9vQkbZmpbXc9OLAnkQytIserA6VPEGnXVPTQv8kd0j
PHguczlCWHf7+/HoURkG5VP0AeTlOKRNNHy1Oso6sWBOtb+3lDmId4x4qu4QmVLiTwNy7trX9GY/
3rk=
=xK8p
-----END PGP SIGNATURE-----

--------------HuzgY0vvUXdVgEIsK19IOP3a--

From nobody Wed Sep 21 00:58:34 2022
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 4MXKmD3j1mz4csGW
	for ; Wed, 21 Sep 2022 00:58:36 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXKmD353Lz3q8h
	for ; Wed, 21 Sep 2022 00:58:36 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663721916;
	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=5wDKIEffhSaGN9ck4ekEinSmM3VeWT3useXrAx+CzC0=;
	b=i367kMvvIQ89W1DXfFi1ZhufvrmJ/danh/A3Sj4zs9tDrq/S+ip9MjLyNhzNbE1b6/+MRC
	rcChdgFmqScbGXob9HxfV4Ilw5o7nVyyIgAj/GA9FMVyNxpPi66tYJuY55HuDSYqk2eM/u
	q2+xx2OVOCLVHWaVpGLFuIXaqV9SPBTto+y9SG2mDJQIC29cnN8U0eDxKVemYTNX1+L/IR
	/+bEuE2hTTAqgITsQSkwbE/10vjp4RMgEpytyISYKHaawFXPd4N7Mq2TF2RBrKTdewrdRg
	dUMIwewjSxdWkqhmXLhHxRpHkxbt59kO61iuZW9r+uvh+ena2xmN7tTRtokBaw==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MXKmD0g5Dz1Clj
	for ; Wed, 21 Sep 2022 00:58:35 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: 
Date: Wed, 21 Sep 2022 01:58:34 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: Good practices with bectl
Content-Language: en-GB
From: Graham Perrin 
To: freebsd-current@freebsd.org
References: 
 <35f04731-8daa-53de-d28a-96bae81146ca@freebsd.org>
Organization: FreeBSD
In-Reply-To: <35f04731-8daa-53de-d28a-96bae81146ca@freebsd.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------GIsyHtbl4jog0QzcOyN0Uxp7"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663721916;
	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=5wDKIEffhSaGN9ck4ekEinSmM3VeWT3useXrAx+CzC0=;
	b=vuXBZKFe5b9joYRXT1mG1+ka9oDAfPNQMeEx9mU13A1U968+eflQPemmZXC1qFKu2xA8WB
	CX8jtDe8FkHaGUQwlKHajrpfd6SXfNgWTkr7dGgBkuOvh74Lhzc3MSF8+Zn3Xinfzrkqwq
	Gwnaiw7/04DRu58Wh4668vBsWyJOuOdljVmQQ/eFF/XVsbapCJjBB/VDuM3bT5/z/rFZ3t
	RpHR3WTwhyB7fUFBBz8xd0nfMlWz5tLMHmbQeCjbOcdQGIBXXEcX+rMAKAfSvX7R0cRT+G
	OHj9vRY3yYjbZGrJjkvJkYXT7kUozSyNdSE0IhBzeIuaLa8oqy5apptjyqNcsg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663721916; a=rsa-sha256; cv=none;
	b=XvXeBhNHTsdJk85QYeq3keCu0lchFtclfqz+Kk8KeuNV5KUlZJpSzVNYVrsCDlvH6UP7kL
	6fSAkqA3rKjOb2+922Lc5tOVCJeuiZwtNZovQosSBKlbpV/gnbrlbDHWHM5aYC34XzqT/t
	D7JMt10wtpmWPVpH0JAjrTmu0VnZpZTCcv652om3eJULTAoGYnf9mEnDLCmiE9vc7ylwIo
	C3i9Kve2L5ifh6Yd8k/EgH4V9OWiFjnx5OZ+pGxwytzj2TyvGXXFvK8GR5dJwirc2WEf7e
	ImU0rM3f3kBKVPpB+4fJ/RPB46nvVvGmfqrvwpKB+eCGawAq1Wq8a7+Be8Q19A==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------GIsyHtbl4jog0QzcOyN0Uxp7
Content-Type: multipart/mixed; boundary="------------KP1dm86mfNCMQJibQVdDeCo8";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: 
Subject: Re: Good practices with bectl
References: 
 <35f04731-8daa-53de-d28a-96bae81146ca@freebsd.org>
In-Reply-To: <35f04731-8daa-53de-d28a-96bae81146ca@freebsd.org>

--------------KP1dm86mfNCMQJibQVdDeCo8
Content-Type: multipart/alternative;
 boundary="------------QcMdX50ea4qYF0xAJeA1JU26"

--------------QcMdX50ea4qYF0xAJeA1JU26
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjEvMDkvMjAyMiAwMTo0NywgR3JhaGFtIFBlcnJpbiB3cm90ZToNCj4NCj4gT24gMjAv
MDkvMjAyMiAyMzoxNCwgTnVubyBUZWl4ZWlyYSB3cm90ZToNCj4NCj4+IEhlbGxvIHRvIGFs
bCwNCj4+DQo+PiBJIHdpbGwgdXNlIGJlY2wgZm9yIHRoZSBmaXJzdCB0aW1lIGZvciBjdXJy
ZW50IHVwZ3JhZGVzLg0KPj4gSnVzdCB0byBjaGVjayB0aGF0IEknbSB0aGlua2luZyBjb3Jy
ZWN0bHk6DQo+Pg0KPj4gQ3JlYXRlIGEgdGVzdCBlbnZpcm9ubWVudCBmb3IgdXBncmFkZToN
Cj4+ID4gYmVjdGwgY3JlYXRlIC1yIHRlc3QgKHNob3VsZCBJIHVzZSAnLXInPykNCj4+IEFj
dGl2YXRlIHRlc3Q6DQo+PiA+IGJlY3RsIGFjdGl2YXRlIHRlc3QNCj4+ID4gcmVib290DQo+
PiAuLi4NCj4+ID4gdXBncmFkZSBPUyBvbiB0ZXN0DQo+PiDigKYNCj4gSWYgdXNpbmcgZnJl
ZWJzZC11cGRhdGUoOCkgdG8gcGVyZm9ybSB0aGUgdXBncmFkZTogcGxlYXNlIGJlIGF3YXJl
IA0KPiB0aGF0LCB3aXRoIHJlY2VudCByZWxlYXNlcyBvZiB0aGUgT1MsIHRoZXJlJ3MgYXV0
b21hdGVkIGNyZWF0aW9uIG9mIGEgDQo+IHNuYXBzaG90IG9mIGEgYm9vdCBlbnZpcm9ubWVu
dC4NCj4NCj4gPGh0dHBzOi8vd3d3LmZyZWVic2Qub3JnL2NnaS9tYW4uY2dpP3F1ZXJ5PWZy
ZWVic2QtdXBkYXRlLmNvbmYmc2VrdGlvbj01Jm1hbnBhdGg9RnJlZUJTRD4sIA0KPiBDcmVh
dGVCb290RW52DQo+DQo+IE9taXR0ZWQgZnJvbSByZWxlYXNlIG5vdGVzOyBzb3JyeS4NCj4N
ClRydWU6IG5vIGZyZWVic2QtdXBkYXRlIGZvciBDVVJSRU5ULCBob3dldmVyIEknbSByYWlz
aW5nIGF3YXJlbmVzcyBvZiANCnRoZSBhdXRvbWF0aW9uLiAoTXkgb3duIGV4cGVyaWVuY2U6
IGEgaGFiaXQgYWRvcHRlZCB3aXRoIENVUlJFTlQgbWlnaHQgDQpiZSBhY2NpZGVudGFsbHkg
cmVwZWF0ZWQgd2l0aCBSRUxFQVNFLikNCg0KRm9yIHVwZGF0ZXMvdXBncmFkZXMgdG8gQ1VS
UkVOVDogSSBkbyBwcmVmZXIgdG8gY3JlYXRlLCBhY3RpdmF0ZSB0aGVuIA0KYm9vdCBhbiBl
bnZpcm9ubWVudCBiZWZvcmUgaW5zdGFsbGluZy4NCg0KLS0tLQ0KDQpXaXRoIHRoZSBhbHRl
cm5hdGl2ZSAoYSBzbmFwc2hvdCB0aGF0J3Mgbm90IGFjdGl2ZSksIGFuZCBhIERlZmF1bHQg
Ym9vdCANCmVudmlyb25tZW50LCB0aGluZ3MgY2FuIGJlY29tZSBjb25mdXNpbmcgd2hlbiB0
aGUgcHJlZmVycmVkIGVudmlyb25tZW50IA0KaXMgbm8gbG9uZ2VyIERlZmF1bHQsIGVzcGVj
aWFsbHkgaWYgKGluIHJhcmUgc2l0dWF0aW9ucykgRGVmYXVsdCBiZWNvbWVzIA0Kbm8gbG9u
Z2VyIGJvb3RhYmxlLiBOZWVkIHRvIHRoaW5rIF92ZXJ5XyBjYXJlZnVsbHkgYWJvdXQgbmFt
ZXMgYW5kIHRoZSANCmFwcHJvcHJpYXRlbmVzcyBvZiByZW5hbWluZy4NCg0K
--------------QcMdX50ea4qYF0xAJeA1JU26
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 21/09/2022 01:47, Graham Perrin
      wrote:

    

    

      
      
On 20/09/2022 23:14, Nuno Teixeira wrote:

      

      

        
        

          
Hello to all,

          


          

          
I will use becl for the first time for current upgrades.
          
Just to check that I'm thinking correctly:

          


          

          
Create a test environment for upgrade:

          
> bectl create -r test (should I use '-r'?)

          

          
Activate test:

          
> bectl activate test

          
> reboot

          

          
...

          
> upgrade OS on test

          =E2=80=A6

        

      

      If using freebsd-update(8) to perform the upgrade: please be aware
      that, with recent releases of the OS, there's automated creation
      of a snapshot of a boot environment. 

      
<https://www.freebsd.org/cgi/man.cg=
i?query=3Dfreebsd-update.conf&sektion=3D5&manpath=3DFreeBSD>,
        CreateBootEnv

      
Omitted from release notes; sorry. 

      

      
    

    
True: no freebsd-update for CURRENT, however I'm raising
      awareness of the automation. (My own experience: a habit adopted
      with CURRENT might be accidentally repeated with RELEASE.)

    
For updates/upgrades to CURRENT: I do prefer to create, activate
      then boot an environment before installing. 

    

    
----

    
With the alternative (a snapshot that's not active), and a
      Default boot environment, things can become confusing when the
      preferred environment is no longer Default, especially if (in rare
      situations) Default becomes no longer bootable. Need to think
      _very_ carefully about names and the appropriateness of renaming.
      

    

  


--------------QcMdX50ea4qYF0xAJeA1JU26--

--------------KP1dm86mfNCMQJibQVdDeCo8--

--------------GIsyHtbl4jog0QzcOyN0Uxp7
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmMqYboFAwAAAAAACgkQt2dIb0oY1AvA
eA/+LNR8sCZZLfDUJr5OUcpXUd9OmfI7FaVhCrqVWQh2NQ6+ywSWe2poFihG2SCeDU0/i3tEm9Ly
V3UdJaGh3q2TzoybWAQ7pdRD2GNyZHFZt7vcf6U5PMvROYKZOj4h+UMyRaPbUEDdD9B7CDSCuHDb
+ceozIdX3PPSZ84w+6FljbwmGfn5/dkxMUc0ZJceQocXD3oJFUNN6Kyr+J3z80lV14fybBLrk6LV
etZ/ixjhnm6elxG+AGVWUpxb9n76U293GFm77W8c9Ymy4S6fYLgqi2LMdh/JmX5ljUsq2VkRaFhl
fTd6NfihiZUlpmdHKAX4F6NNo+Tj/KSP4vMVJvCQoKbLbgcuj5GRQo9fjnRw892CsjLPckr2ZxbL
HbdkdknQUbU+fumbXBcEbubaipAOnpV9npKYgopy+3ckinFjpbtwm69Y8IEZ7XkDxx0i+MMgCbEX
mRGdlAzr63KqDFHqcGqr6xO8qWuJ6ma4Iub9duV5/yMDXebcD8tlhfyDX6DpKM8Kfcfkyfj7vmPv
US4DJhyjan7p9/UBQgqINmYYbls+5RaUJRWi/1od/GhlRsTu/3B0QkbbrNbtHqyhbxCM3H0WsY87
TaBTlOFoC2usL8uMFwnKeiWySEi3Mzf4YkxqWKLiDwY6dNO+vd43iKaZBrHNqioTDdX8yfWSxC6t
QWQ=
=uDAr
-----END PGP SIGNATURE-----

--------------GIsyHtbl4jog0QzcOyN0Uxp7--

From nobody Wed Sep 21 07:29:01 2022
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 4MXVQm0rbtz4cZ2g
	for ; Wed, 21 Sep 2022 07:29:04 +0000 (UTC)
	(envelope-from zirias@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXVQm0CGMz3Lxc
	for ; Wed, 21 Sep 2022 07:29:04 +0000 (UTC)
	(envelope-from zirias@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663745344;
	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=INxDZlYBZBZibsVgClCWj0CvDSA2CiDRknJg8H7A2gM=;
	b=RUACcIWMisgsUczGrFbXfHjz4i3NFC447ZdlyzUXqnZiOP8aiyOpH8pz5ZN2wpBVJFIr7W
	PVgTatnI8rVQiH9qMDCgCG6/HGgDIFmviXrPvUElNt6YPJK2HMdP2oMHN/dklbk0aNMX76
	LSyjCuL0dNrocrgc7gvOWLMHcdUtthE9Zmcg/FQz7yNxTK7XT8GHmf+gqdnHPu6p7j53d7
	l3mamkxNYo+zB1B3TZIGHIE6ZQ3sadyLeoaJAyqkL84kJiD36bwbRm9N75S2JVaTfK6C63
	At0ZseZ9/qBJXpYOrElvPmXS0Kgsw8GreUFmqgJM7ZIpMpxxAtChmdj3P/bOdA==
Received: from stef.palmen-it.de (stef.palmen-it.de [IPv6:2001:470:1f0b:bbb:1::1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	(Authenticated sender: zirias/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MXVQl6GNjz1F8y
	for ; Wed, 21 Sep 2022 07:29:03 +0000 (UTC)
	(envelope-from zirias@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=palmen-it.de; s=20200414; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:
	Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
	Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
	List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=INxDZlYBZBZibsVgClCWj0CvDSA2CiDRknJg8H7A2gM=; b=Clw0mq2MIKQpjCnlvnqJ1bdO5F
	VBXdQdU+akcnoo9lGeLXSYoHFUCHISLb3F8ayNwPBIe4ginDNptrwoUVz0BuDt8+5UAusaQRYunYM
	S2x8isLFezH0vJ4NbjzGejdjyNYLjxbFkjMZ4eI/quRikMyyBFRepii/CSfEULiTyqQ5GtNzLafVJ
	+nQCcVpIHZV7N7G0rqKMY40MccScFpq3vO477aia+4F970iRnQUKX6SflT9aTl8WOrkm/2bIXM0I5
	vXw9JxXRvyIGs2fBlnP+ydVaw52LZXUMpV3M9xY+a7/yEXFbfXJHVbVgQj6dmsJIHV8hdqJGBrm5Q
	BgxXvIXA==;
Received: from [192.168.71.101] (helo=mail.home.palmen-it.de)
	by stef.palmen-it.de with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from )
	id 1oauAI-003iOk-4U
	for freebsd-current@freebsd.org; Wed, 21 Sep 2022 09:29:02 +0200
Received: from nexus.home.palmen-it.de ([192.168.99.2])
	by mail.home.palmen-it.de with esmtpsa  (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oauAH-000Bcw-M2
	for freebsd-current@freebsd.org;
	Wed, 21 Sep 2022 07:29:01 +0000
Date: Wed, 21 Sep 2022 09:29:01 +0200
From: Felix Palmen 
To: freebsd-current@freebsd.org
Subject: Re: Good practices with bectl
Message-ID: <20220921072901.5wbxe55wo2shpjrx@nexus.home.palmen-it.de>
Mail-Followup-To: freebsd-current@freebsd.org
X-Face: /1K@t"h.}e~pR@]c7HorQ!T`F^RJCa'BCr#e>IKA{>C/9OTGB4|xh"y2{?1Z5M
 i2w"AH^pN_LlHR^{+f',_Np~;.B;!M/bL}*qk]p5*r7F5vW};{:@4u5S?T&f0$7BJ-71Q5SV]:v$`5
 A0[DZ:=?S52x8HJ~5@^P_\T@MsjG{R(
Organization: FreeBSD.org
References: 
 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="x6o6yjjnfxp6cqhs"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20220429
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663745344;
	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:dkim-signature;
	bh=INxDZlYBZBZibsVgClCWj0CvDSA2CiDRknJg8H7A2gM=;
	b=gxq4JjaJYXM8M4gyVCWYCMmkV9uBg4bGiVTsLInHkxQbrhujR1eU0dZdvvIvHj8SjzVpg9
	ASYrKMMu8XFa5PqSHmIqtDF0WgjYWnr82r/IxOe6z8PpbOekfJ/DjFShq/R/VHRdj/QFjX
	rDLgI+Obt4kKkIpD37X+dkGhkYIUiMXyMS+UWdSpmGjizq5OWzymkJTxs4gBgTS9sWUd6p
	TmFWAresUfVRo0u5g+SkfPPq2zYpN/XShbTBlUeEJV9sp5C3zMYV130riOfSlE8mTKS8TW
	ya/9T/aAMRFvToen9JO3+zi7LyIZH1ltInBGPfmsOpMyt5suPHu1isKIWXAMZA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663745344; a=rsa-sha256; cv=none;
	b=ej5Zci0WkMka4k9+xa30HeZaUjvt65MbdfCS4CCGTcAUafKoeXXolwGWJNTbZw1ptcHiM8
	Yb3ucnOxrSGJV1l6Tn5o+fE0FC4pLFrKCW9x9Ubj5c8IATAuZgYgGGVWFSpeADUmdykJ3E
	Z29XcLWWSFW0Q27EDy//x50YRdQX8ZCGO7xpRX4wyzLbDqrm5dNCTRKZcm8wEHOjB6lfnN
	akA2uDIWjX5Q+2X8N4IsWT56XbA0rDQn4xCIJUQHyp/hRbqdKltEe7QYlH2wL3xflrBP4V
	PhyOsWQqvkvbU6S+U9xTLDWie/hR7vkcw4m6PmY5eyAOOTsw+OzJPAeHbwl4ew==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--x6o6yjjnfxp6cqhs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Nuno Teixeira  [20220921 00:11]:
> (...)
> maybe:
> > yes | make DESTDIR=3D${BASEDIR} delete-old delete-old-libs

Exactly, DESTDIR is used by all the targets.

BTW, you can just set BATCH_DELETE_OLD_FILES=3Dyes (either on the
command-line or in make.conf) instead of using "yes" here.

--=20
 Felix Palmen      {private}   felix@palmen-it.de
 -- ports committer (mentee) --            {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231

--x6o6yjjnfxp6cqhs
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEABYKAH0WIQRpNhPVW79IN7ISOsxUreAGmHnyMQUCYyq9Nl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0Njkz
NjEzRDU1QkJGNDgzN0IyMTIzQUNDNTRBREUwMDY5ODc5RjIzMQAKCRBUreAGmHny
MSKIAP4iXHWYRFYyDQyGiMAeRHE0Tt8S7RFqV6bJ1UKJIrmhtwD/VWS71hlC7Del
St7cFbGxS6ox46anIc3nJnLdcvEbtwI=
=Qauo
-----END PGP SIGNATURE-----

--x6o6yjjnfxp6cqhs--

From nobody Wed Sep 21 09:27:06 2022
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 4MXY3Z0S00z4crrR
	for ; Wed, 21 Sep 2022 09:27:38 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXY3Y0W0mz3Y46
	for ; Wed, 21 Sep 2022 09:27:37 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id E6B8022E1E
	for ; Wed, 21 Sep 2022 11:27:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1663752445;
	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=6khdutkiHCAgbDMvQ23CCCgQxbcVfN3Y5blxisG7/K8=;
	b=AKdcp96L5ATcATfqPlK+SLWeSuveM1/hbDnD9/ieWXOJmwXW+rnkBO66mcJqZ8KcMAT0V3
	YhC/E7tH9I8vkG9nf+wCvFRkodGdAmM4Y9Ypoe3jpMvE4YK+8iZeJUkz1XO88nT5d5wOtm
	+StfB2XtL0Dv44OXk0pDtzQ4q+C2Uz6VWR5iBm4mQYpx38jYy5n3BGrvH2hTiRXJb1U8ez
	y0r6rbxxhVvt7lxfoorrb7GRHbkm0ULufm4DuTq/b4ad1wqJd7APeV9kEmXlw24xmpy2cy
	akarX+om+VotjsMMSUuY/xad5gauHj7XoEWeNWM5Z8l0RG16IlNBpcDioN05eQ==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 750E3B503
	for ; Wed, 21 Sep 2022 11:27:06 +0200 (CEST)
Date: Wed, 21 Sep 2022 11:27:06 +0200
Message-ID: <20220921112706.Horde.eNaqpvIqq64Qe7crIQQ9JwX@webmail.leidinger.net>
From: Alexander Leidinger 
To: freebsd-current@freebsd.org
Subject: Re: Good practices with bectl
References: 
 
 
 
In-Reply-To: 
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_px8gzOvLdbccM2CvKle0Mbv";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4MXY3Y0W0mz3Y46
X-Spamd-Bar: ------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=AKdcp96L;
	dmarc=pass (policy=quarantine) header.from=leidinger.net;
	spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net
X-Spamd-Result: default: False [-6.08 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.99)[-0.991];
	NEURAL_HAM_MEDIUM(-0.99)[-0.987];
	DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine];
	MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	DKIM_TRACE(0.00)[leidinger.net:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_px8gzOvLdbccM2CvKle0Mbv
Content-Type: multipart/alternative; boundary="=_4_D8aUEwudNf2m4ZCtgG65Y"

This message is in MIME format.

--=_4_D8aUEwudNf2m4ZCtgG65Y
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Description: Textnachricht
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

  Quoting Nuno Teixeira  (from Wed, 21 Sep 2022=20=20
00:11:41=20+0100):

> (...)
>    maybe:
>    > yes | make DESTDIR=3D${BASEDIR} delete-old delete-old-libs

make DESTDIR=3D${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old delete-old-li=
bs

Usually I replace the delete-old-libs with check-old, as I don't want=20=20
to=20blindly delete them (some ports may depend on them... at least for=20=
=20
the=20few libs which don't have symbol versioning).

Bye,
Alexander.
--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_4_D8aUEwudNf2m4ZCtgG65Y
Content-Type: text/html; charset=utf-8
Content-Description: HTML-Nachricht
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable









Quoting Nuno Teixeira <eduardo=
@freebsd.org> (from Wed, 21 Sep 2022 00:11:41 +0100):






(...)


maybe:


> yes | make DESTDIR=3D${BASEDIR} delete-old delete-old-libs






make DESTDIR=3D${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old delete-old=
-libs



Usually I replace the delete-old-libs with check-old, as I don't want to bl=
indly delete them (some ports may depend on them... at least for the few li=
bs which don't have symbol versioning).



Bye,

Alexander.






--=_4_D8aUEwudNf2m4ZCtgG65Y--

--=_px8gzOvLdbccM2CvKle0Mbv
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmMq2OkACgkQEg2wmwP4
2IZjQg/+PrDiEuek+Bvv738I2URZ95QAeUpOa7j22jsgWB3YXEXPDglZFXKM45D7
5/2Txp3AVM5qhV4FtFAwyeP5AZnEbJa4m9eaq5xntMS/fJYZgbBIxykQz7UM7VQY
sv7GiLkBzdlewXnP0K+yI1RX/CqfEMN4IOVXm8vRhZ95TWMiju9EchEflPP2VEbk
Jqb3fjC537uo1YIk8AckU6HP9wFoLyxeovhd8cTPUcAfOoNCpnd/8zFPBCFKp61z
NoykrdLIDc1co20Ydw0BcCsg+H1afGVf6DXBo+twT8WqPG4c47JSdyNV8UO5IVyi
XfYuPM1Bmp666kFV8WTOZ9g8Y26N083qs4Dj9ToDxChdNs437hDRJXCVsTnlkCkB
6ABZ8hDbmN4RBcWpUse5pj/E+DCB04ANa/b1eA178quYa5ABvycjLdOSMRJ6yHHT
SBozP2b9SDBJQxc7SQ/Ry0A8MBi+IJnPdlmSN36UuNZDn6a/JE7vUL6jgZqJQGGG
iR/IgxJq1rtjXyfcJjJCPNKSeCm8qKidthOyDqK5VMc/I2AtGjpxJG/a+uj1lj8K
mvowJMlAG7r3QsNRjYpBcsGDGHIwjRNNyFeQjX7YXuXUw3XqRmCYraSHmtv5kY9l
xFzIhQ/SIQs9rT+mXFl9NNfiGYBvxJEOpwpZZDtFagvWsYc/TjA=
=zvd8
-----END PGP SIGNATURE-----

--=_px8gzOvLdbccM2CvKle0Mbv--

From nobody Wed Sep 21 09:30:56 2022
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 4MXY7g2pzSz4cs4G
	for ; Wed, 21 Sep 2022 09:31:11 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXY7f4qVkz3c1Y
	for ; Wed, 21 Sep 2022 09:31:10 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id 6CAF322E3B
	for ; Wed, 21 Sep 2022 11:30:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1663752658;
	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=wWS2pF6V9h8j3V+r012hQTPxiBP83UBPi6wOic4j98U=;
	b=m+4/Ag8IdiJP9n2mTLaHV2nZxmNFI//HAgC692VdjOeu4jFrZj6EhU0A4PBb1tD9HRth/K
	NER0Z/SA385ASnhhN6kZvDzo6WXVLRwLZRoqrYcWBMoHHQXv1/9x7Ani/3Q47ck/qTFDhk
	bgxcher3CWNLyo80wWuI3lnx/I+cq1J5PLGmHzNQl1tfz6VYnoE5t3+rHQOzNe4TrK3D88
	sUdfnfB/FFQ/7kmTCIvTElMXlLB/i5WccswzjD4eWRucsCmDVYESTsFBWayJ1PyZB6oeLE
	+eYoRvweBkoW6Lb7aJfg2ChPHsOTkUR3bdXdEvJ9IcHTptX2NpfBmm1VBaHMng==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 2F5F0B581
	for ; Wed, 21 Sep 2022 11:30:56 +0200 (CEST)
Date: Wed, 21 Sep 2022 11:30:56 +0200
Message-ID: <20220921113056.Horde.ZyKstMrOaHfBMOLkkFIYWoU@webmail.leidinger.net>
From: Alexander Leidinger 
To: freebsd-current@freebsd.org
Subject: Re: Good practices with bectl
References: 
 
In-Reply-To: 
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_jURz6V-8pmtVZ0BpKUaQyqA";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4MXY7f4qVkz3c1Y
X-Spamd-Bar: ------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b="m+4/Ag8I";
	dmarc=pass (policy=quarantine) header.from=leidinger.net;
	spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net
X-Spamd-Result: default: False [-6.08 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.996];
	NEURAL_HAM_MEDIUM(-0.98)[-0.980];
	DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine];
	R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_SPF_ALLOW(-0.20)[+mx:c];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[leidinger.net:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_jURz6V-8pmtVZ0BpKUaQyqA
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Alan Somers  (from Tue, 20 Sep 2022=20=20
16:19:49=20-0600):

> sudo bectl activate ${RELEASE}

Failsafe (if the machine is too far away to simply walk over and=20=20
switch=20to the old BE):
bectl activate -t ${RELEASE}

Needs an activate without -t later.

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_jURz6V-8pmtVZ0BpKUaQyqA
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmMq2c8ACgkQEg2wmwP4
2IaqVw/+I1rFJKk4cvd7y91HYMHXLLvpM0ypPlpHw25cV4k+vzLb3vOvzfCZfcoq
u+CvUXZYW2/NoKzFf1q8hH49VE4QI8MMFIFGIQmxE/apg59DxdARlGVqv+m31oy8
Tbn8lyB91MUU36tvWBkWanRPHS891ZQIimAMTq0JshtiL8Hbc2Xpq3IhY5bUGxLB
vsbmf6u/pAEkgdf/sbyHIF0Kc+87qhjIkValrqzoOwSz77vMw0BADJY8h5RvyeA3
2Y1KrzcXz7T9Mqa7+lJpULImcSdxKGLzUSj+6pD2cZFEJ9YtUx+cJopFXuKfEJXq
X5cT62HULpA9Jt2Ar10jVOqvdOI0D4Hozak735WAj5k//En3OFr8adm7vzyyL7nb
XNf5Nb8HQ2Z5Cs1ajXHn+zHo7caZfZQ01Ve91TOPe2DPKx8rYRQ7T0GeCHb+cz/I
qNWK8O30Ow346U1/Sq4OhuhDiAGw5m34uWrhabSty/XTxa+oJMPT4ho5qs/0jHw9
Sl6ayme6ogIC6SqpdujhY+0hR6qWvK1QQTjrnDXyDyMVo0KciTiaC8dkZW4MfYba
ORdsQlFoRPY6tcLqxEwwhf6NTTqmAO4V3SGnJeEKCjWTj3coflzeWFh3x8Lr7ply
p04wOA/rJ5uxmrLHGVjz6mNEeKdtIbBQoLLHfhh21QadnNXUYLU=
=rSHm
-----END PGP SIGNATURE-----

--=_jURz6V-8pmtVZ0BpKUaQyqA--

From nobody Wed Sep 21 10:25:52 2022
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 4MXZLr73c3z4d0Vn
	for ; Wed, 21 Sep 2022 10:25:56 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXZLq2Dm1z3lgf
	for ; Wed, 21 Sep 2022 10:25:55 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 28LAPrYT037121;
	Wed, 21 Sep 2022 10:25:53 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 28LAPr8A037120;
	Wed, 21 Sep 2022 03:25:53 -0700 (PDT)
	(envelope-from david)
Date: Wed, 21 Sep 2022 03:25:52 -0700
From: David Wolfskill 
To: Alexander Leidinger 
Cc: freebsd-current@freebsd.org
Subject: Re: Good practices with bectl
Message-ID: 
Reply-To: current@freebsd.org
Mail-Followup-To: current@freebsd.org,
	Alexander Leidinger ,
	freebsd-current@freebsd.org
References: 
 
 
 
 <20220921112706.Horde.eNaqpvIqq64Qe7crIQQ9JwX@webmail.leidinger.net>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Nand08OWZsxV+qvC"
Content-Disposition: inline
In-Reply-To: <20220921112706.Horde.eNaqpvIqq64Qe7crIQQ9JwX@webmail.leidinger.net>
X-Rspamd-Queue-Id: 4MXZLq2Dm1z3lgf
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-5.32 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.99)[-0.992];
	NEURAL_HAM_MEDIUM(-0.93)[-0.930];
	R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	HAS_REPLYTO(0.00)[current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEFALL_USER(0.00)[david];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	FROM_HAS_DN(0.00)[];
	REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[catwhisker.org];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Nand08OWZsxV+qvC
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 21, 2022 at 11:27:06AM +0200, Alexander Leidinger wrote:
>   ...
> make DESTDIR=3D${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old delete-old-=
libs
>=20
> Usually I replace the delete-old-libs with check-old, as I don't want =20
> to blindly delete them (some ports may depend on them... at least for =20
> the few libs which don't have symbol versioning).
> ....

A way to address that issue that may work for you is to install
appropriate misc/compat* ports/packages.

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
In 2022, the governors of Texas and Florida resurrect the racist
ploys of the "White Citizens=E2=80=99 Council" of 1962 -- at taxpayers' exp=
ense.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--Nand08OWZsxV+qvC
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYyrmsF8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1P0/AP9zsqYVqVPgkxsYwO572Vr2asX/XwMQynI9qtt6tVfU6QEA1OS/PXV5yXyz
IaiDXiQiC310YguByHGYLRct8VaiAQw=
=I6IB
-----END PGP SIGNATURE-----

--Nand08OWZsxV+qvC--

From nobody Wed Sep 21 10:44:52 2022
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 4MXZn95S2Fz4d2fv
	for ; Wed, 21 Sep 2022 10:45:17 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXZn85QmZz3p8w
	for ; Wed, 21 Sep 2022 10:45:16 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id D43BF22ED4
	for ; Wed, 21 Sep 2022 12:45:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1663757110;
	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=LaWoidQQRndKJ4jJGb/JFLEikfS5ScDh+Op4JtjTujs=;
	b=gCgnscBQ6fIAUOXbyrVqDosE5iHHx83E3XCPXtYLT0Q6dAq+C9vbWtVpzTH3Lu4M7+WOV0
	UlXiGzYaLgqwSx4WQVGMfDV2LCmYItOcbDPZ791KzyDWuseRURW0W6YsdorMzNftBcuPT7
	bIKzV8StZQqsa+liXdSSsOUqfGmwOG1zWuSHHdx9kxBcu5jCyTIoPRH05/w1G8lNNuqWVR
	PhehB0/S7GyriJfl7JOglz34BWEZEUTXjIYgnE6gm7b0ln502OuV9XQlV2pTCe8IuqNPNo
	0LUd3oz7WPNGhx3pGDcqXEvHV7NqtPVu2+e7YZX+U9AzrDrRQ3TJrY4MErR/vQ==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id B65A0B504
	for ; Wed, 21 Sep 2022 12:44:52 +0200 (CEST)
Date: Wed, 21 Sep 2022 12:44:52 +0200
Message-ID: <20220921124452.Horde.BSQPZ4imQhhKUUE0k3W5iFb@webmail.leidinger.net>
From: Alexander Leidinger 
To: freebsd-current@freebsd.org
Subject: Re: Good practices with bectl
References: 
 
 
 
 <20220921112706.Horde.eNaqpvIqq64Qe7crIQQ9JwX@webmail.leidinger.net>
 
In-Reply-To: 
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_5dUNs74UqHYLC-LI7lB1pgt";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4MXZn85QmZz3p8w
X-Spamd-Bar: ------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=gCgnscBQ;
	dmarc=pass (policy=quarantine) header.from=leidinger.net;
	spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net
X-Spamd-Result: default: False [-6.06 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.990];
	NEURAL_HAM_MEDIUM(-0.97)[-0.970];
	DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine];
	R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_SPF_ALLOW(-0.20)[+mx:c];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[leidinger.net:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_5dUNs74UqHYLC-LI7lB1pgt
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting David Wolfskill  (from Wed, 21 Sep 2022=20=20
03:25:52=20-0700):

> On Wed, Sep 21, 2022 at 11:27:06AM +0200, Alexander Leidinger wrote:
>>   ...
>> make DESTDIR=3D${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old delete-old=
-libs
>>
>> Usually I replace the delete-old-libs with check-old, as I don't want
>> to blindly delete them (some ports may depend on them... at least for
>> the few libs which don't have symbol versioning).
>> ....
>
> A way to address that issue that may work for you is to install
> appropriate misc/compat* ports/packages.

I'm running exclusively on -current. In the cases where this happens,=20=20
there=20are no compat packages yet. And I rather update the ports than=20=
=20
to=20install a compat package. It doesn't hurt me to keep the libs=20=20
during=20the pkg rebuild.

In the generic case I prefer to stay safe and keep the libs until I=20=20
validated=20that nothing uses them anymore. That's the reason why I made=20=
=20
the=20delete-old-libs functionality separate from delete-old already in=20=
=20
the=20initial implementation.

Bye,
Alexander.
--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_5dUNs74UqHYLC-LI7lB1pgt
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmMq6yMACgkQEg2wmwP4
2IYnzA//YA22dvR+qZchp+e45BSTB+0ReHy64BPDoEx5m1NAwhASB7JUbufCmAdi
Krp3Fqaw/CpwJTysthGxVnp7+fwNXIRyFFBn/MAhmb5cqx/GpHGDpMnf4BxKXo9O
FY8BxR8oRFfvUToTJkTG3PL01OpxQeRGraA+zAlDJdHotdqTUOMWSQ8mptqPMpds
Ej45ppIMWBlsVRxakpmbdqIWeUfeD3Kg5tqbwTwEeGGrQQtyxeHSmDzLE/w2vAuw
2oLKL+8rwFqEopSviEhuV/XYjO+m3XPJMErnGFEwv2d9i4jgcLVN5nXjUtdJHJmC
mTBYEeqteo1/l5MiW4p9eT6tg50MsIXeSc3O6Jsb+fK6JzndPR6iKhUbWTo24dZq
e/KE7fEf1FPHIl1tPf2cf0Doai7Gc5lhZlI5TKX0cZ4zdL3khZH/MDClXTeAXhPh
lYsSqN27lXXQdKbLa7AJhHoIEHnZg/7nEno6Gm2Nz4OXKzr7wys5yApnc/tMsz03
04ZU64LBL62VAh5vtQRm0X+mHAHhOs8fIVuXe78O3w1eXyYsRbTtuM/exDUQ2Bg5
82DQlC3iOzo3OPXXt63fvWPgCGQcTudAgPSqF5Hzdn2ZdTzG2UCIO2Z89m/tbKvu
MNbVYNX6gJahKDgiFpOuPA3r+TioUmSG34N2MfugDgZND8atG3c=
=5wSP
-----END PGP SIGNATURE-----

--=_5dUNs74UqHYLC-LI7lB1pgt--

From nobody Wed Sep 21 10:56:06 2022
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 4MXb2070bBz4d3rc
	for ; Wed, 21 Sep 2022 10:56:24 +0000 (UTC)
	(envelope-from rbgarga@gmail.com)
Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXb202fPjz3qmh;
	Wed, 21 Sep 2022 10:56:24 +0000 (UTC)
	(envelope-from rbgarga@gmail.com)
Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-12b542cb1d3so8393074fac.13;
        Wed, 21 Sep 2022 03:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:newsgroups:cc:to:subject:user-agent:mime-version:date
         :message-id:sender:from:to:cc:subject:date;
        bh=kUlHK05r20DEVsu7XS4tDcvnRcOsfhjwwciz+ey2xmU=;
        b=N1RM+HmO5GU3u+C7vQQ3EhMIQsudM/lHQQdSd20/i74j2oqkaoMWKDxzhd1s0bqCem
         zXCJ9pq77zwuYZcPG+fMlqgyZcGtF98nR3A6+HbBLVz1iB4nhCSGijljUgAemIVI5GNg
         xhT6RpQELHjCSGMobQHB/IBSca5L+v5tZ1Bv0lXL/v/c8jlGKxA2pIvVQ2P6n8/und4p
         be0+8nNEerR2/aVfSyj6mMXQo5wUR9Sqqjv4NHr54kq7X/jGBCl2Qfw1UqDg5bV1UCW7
         WOKUiNUzim/tXv4RW7g20tprekZNIL5t6oWbBOWC1nDgUsg12PAL5FQcg57sTo45I/CR
         w3Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:newsgroups:cc:to:subject:user-agent:mime-version:date
         :message-id:sender:x-gm-message-state:from:to:cc:subject:date;
        bh=kUlHK05r20DEVsu7XS4tDcvnRcOsfhjwwciz+ey2xmU=;
        b=TjVgKSQYIJc6yCwi3/FOEpBCPVkvXUFdtd2ZF14eWUkRX+9DJXuAJDbyBSYZoODyCj
         7LIIxVpW9ESIQCUf7u6Xp0vt8GWnYwuTczx1LuIW/zd1IYEfJUrp/sNZzSjuL0SgI7jN
         v9w3Og6Idhe1q9nIXlOFPqEX3NaHK8QQ7rspBC+nVm88gImpnvUGYLMALuD4a5zYadq2
         0EbJt/vIra49gx4+XO1ow1xWpU6TOFgqKsF4CjMDhVeURK8ofAQFD6xjiUUZJM3MLpEv
         pm+w/BH4CmZMeCzDLjBHO1Ygn6P6Li6T9/9/NdiqqKYKYLCl091BWqrlUd+1Vrc7Pn87
         zGTg==
X-Gm-Message-State: ACrzQf1AOo1Ke8/wy8+TZREZLWqY/rS0DpJfG8wO+SZhVouzE0Vnzt8J
	Ujhn9zRrJbH5gRgWXxqX+aMFrG2R7ijBDw==
X-Google-Smtp-Source: AMsMyM73V5EZyBd6Blx72XufE2ycbw/DPnso4iw6yGNnCwtGvQ2zn25uPDzxMzIlDcTVaLgMSur0vg==
X-Received: by 2002:a05:6870:e615:b0:12d:943e:256a with SMTP id q21-20020a056870e61500b0012d943e256amr726091oag.83.1663757782350;
        Wed, 21 Sep 2022 03:56:22 -0700 (PDT)
Received: from ?IPV6:2804:f1c:80b:5a00:95e7:f07:aba7:cea6? ([2804:f1c:80b:5a00:95e7:f07:aba7:cea6])
        by smtp.gmail.com with ESMTPSA id u18-20020a056870701200b0012d130c2fdasm1305668oae.48.2022.09.21.03.56.19
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 21 Sep 2022 03:56:21 -0700 (PDT)
Message-ID: <34b7b81f-0b38-c6ea-559e-370d8f29b0c4@FreeBSD.org>
Date: Wed, 21 Sep 2022 07:56:06 -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/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.2
Subject: Re: Good practices with bectl
To: Alan Somers , Nuno Teixeira 
Cc: FreeBSD CURRENT 
Newsgroups: gmane.os.freebsd.current
References: 
 
Content-Language: en-US
From: Renato Botelho 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MXb202fPjz3qmh
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=N1RM+HmO;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of rbgarga@gmail.com designates 2001:4860:4864:20::30 as permitted sender) smtp.mailfrom=rbgarga@gmail.com
X-Spamd-Result: default: False [-1.24 / 15.00];
	NEURAL_HAM_LONG(-0.94)[-0.935];
	NEURAL_HAM_SHORT(-0.92)[-0.917];
	NEURAL_SPAM_MEDIUM(0.82)[0.817];
	FORGED_SENDER(0.30)[garga@FreeBSD.org,rbgarga@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::30:from];
	ARC_NA(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	FROM_NEQ_ENVFROM(0.00)[garga@FreeBSD.org,rbgarga@gmail.com];
	ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 20/09/22 19:19, Alan Somers wrote:
> On Tue, Sep 20, 2022 at 4:14 PM Nuno Teixeira  wrote:
>>
>> Hello to all,
>>
>> I will use becl for the first time for current upgrades.
>> Just to check that I'm thinking correctly:
>>
>> Create a test environment for upgrade:
>>> bectl create -r test (should I use '-r'?)
>> Activate test:
>>> bectl activate test
>>> reboot
>> ...
>>> upgrade OS on test
>>> reboot
>> ...
>> if a problem happens, reboot default from BE loader
>> ---
>> if everything fine destroy default and rename test to default
>>> bectl destroy -o default
>>> bectl rename test default
>> repeat on next upgrade
>>
>> Don't know if a faster way exists with chroot or bectl jail...
>>
>> Any hints appreciated.
>>
>> Thanks,
>> --
>> Nuno Teixeira
>> FreeBSD Committer (ports)
> 
> I don't think you need to use "-r".  Also, you're forgetting one of
> the best things about boot environments: you can upgrade them even
> when not booted into them.  That's faster than upgrading the running
> BE.  Here is the procedure I use:
> 
> RELEASE=Whatever
> sudo bectl create ${RELEASE}
> sudo bectl mount ${RELEASE}
> BASEDIR=/tmp/be_mount.XXXX    # Use mount point returned by bectl mount
> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update
> upgrade -r ${RELEASE}
> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
> # Ignore admonitions to reboot, since we're using a boot environment
> sudo freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
> sudo bectl activate ${RELEASE}

I like to use `sudo bectl activate -t ${RELEASE}`, it activates new 
partition to be ROOT only for the next boot.  If something goes wrong, 
you just need to power cycle the machine and it will boot on previous 
partition.

After a success boot you must run `sudo bectl activate RELEASE` again to 
make it permanent.

> sudo reboot
> 
> This general procedure works just as well if you're upgrading from source, too.
> 
> sudo make DESTDIR=${BASEDIR} installworld
> sudo mergemaster -m $PWD -D $BASEDIR -U
> 
> -Alan
> 
> 


From nobody Wed Sep 21 11:08:38 2022
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 4MXbJM1BLRz4d5GF
	for ; Wed, 21 Sep 2022 11:08:51 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXbJM0h0Bz3tdt
	for ; Wed, 21 Sep 2022 11:08:51 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663758531;
	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=YcCE4ZcjEMpSSm9+JXD4ZRASGZILhVwf6Bh0LXza92w=;
	b=ShlTPnc1J7kK3PwGeoR3hmuWDlcPGO2rVOUZ+sF9JnA2P/i+Z9oEbnDuRQCb9Z6zqYGj/B
	/K2r8cC6bd6PJKg2pJiLLCfOZmqEkN9KZ7kI7C2OS0mger4N9kpMfO2adlwtdHJ02jUwqB
	DRsMzxdRkCw3JLTOXMy4ucWcLH+6cXS8SBOT1SwcpvnB9s7koDI8EU3SGHQRLLFWeW0XNl
	Ng/lH49dgWnUQQMow3D/PhcxeDsCaikV8JNUNRPjcvbhru5bChxm9GueO/3H5gqeMBegff
	RYJnnG9MEd5gKksSunUmTbwRADdYdb5LD7nHqUiA/8LpU1i32BoJhMP/kE1QQA==
Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MXbJL6bCBz1Fvv
	for ; Wed, 21 Sep 2022 11:08:50 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f53.google.com with SMTP id q26so6282419vsr.7
        for ; Wed, 21 Sep 2022 04:08:50 -0700 (PDT)
X-Gm-Message-State: ACrzQf10u/DFBMBOdh4CW+Mm9Rn9mAZ4AtskBLlYcM3mBVRCVzRq1m+g
	6Fu2h+SueXCFrZIQIQsCB2cqepUQtCauEuVKwnE=
X-Google-Smtp-Source: AMsMyM50qc1wy6oo0P1EOcTauFoefwpR3YL4PYMvP1pgsu8eAuhPL2+IcDDXY4pvX4XG9IvwEdzXWbCpkWb5NuZWWzM=
X-Received: by 2002:a67:d793:0:b0:398:506b:747b with SMTP id
 q19-20020a67d793000000b00398506b747bmr9803535vsj.19.1663758530137; Wed, 21
 Sep 2022 04:08:50 -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: 
 
 
 
 <20220921112706.Horde.eNaqpvIqq64Qe7crIQQ9JwX@webmail.leidinger.net>
  <20220921124452.Horde.BSQPZ4imQhhKUUE0k3W5iFb@webmail.leidinger.net>
In-Reply-To: <20220921124452.Horde.BSQPZ4imQhhKUUE0k3W5iFb@webmail.leidinger.net>
From: Nuno Teixeira 
Date: Wed, 21 Sep 2022 12:08:38 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Good practices with bectl
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000002e540105e92df84e"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663758531;
	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=YcCE4ZcjEMpSSm9+JXD4ZRASGZILhVwf6Bh0LXza92w=;
	b=rO5Z1D8/jyXxCkqocEPpRF69B1EFwuWHHPLMCcYDANx4YJycdLv8D5DyfCEJqaimqga9NO
	YvXTLT8EhWJhg813b9nxOjoZVCCgF2V+Sr00Fo3wI43K8FpNIfX4N/XQrJqXrptg6cbnxZ
	OgctJhplMvV9XLmOplTRCL+/p1pQB5v6qwFuI88sGzfUpJnGe4idz0r1fwiSXul0yyRqya
	8nLQViEeTnBGaGwZrpZ8OUvCOgu0tEPj2FEbCBK5oY6dg5rlxkqSqKYk27MlWX1UQcdI/q
	RN+iCpq9Dx+LiGDqT2ZnMZlo8qH+hzg4Ajrwh6JCITAXR8ilKCh5iL+LmMfDwA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663758531; a=rsa-sha256; cv=none;
	b=oPUiFkR5re0Q57Qcm+FixD63z2YShZX/tqVCx4Sle06gybbDKpb3s4hJHc5SyQ9In4kRcm
	cUwOQGjbBjd8wS0tGhW/azhihFqd+OYKPAfb4BsX+mPsrX0TgO6+2B9GvkRImIb7lYRqYJ
	53MVPKXVLKHVj/+CXv1eYrA5qmspOZpapCQ9LnkXGiHfGdlnCTWU4fFrLs0I8BDSdxj0Gn
	SJwm1Oph59XPygNC9ZYUxSjeCjt3J1Na1A8xKuYa66u5sp+wnCVUq3g/GzIiphKXzK7mg7
	dGacSZ+ouwnsbzGaiEFq1G1H8A0QjaRifn7Nj/+tN/lKlRCjqoYSNYnazqGfCA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000002e540105e92df84e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Summary: Using bectl for upgrades

RELEASE=3DWhatever
> bectl create ${RELEASE}
> bectl mount ${RELEASE}
BASEDIR=3D/tmp/be_mount.XXXX # Use mount point returned by bectl mount

[freebsd-update method]
> freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update \
upgrade -r ${RELEASE}
> freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
# Ignore admonitions to reboot, since we're using a boot environment
> freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
> bectl activate ${RELEASE}
#> bectl activate -t ${RELEASE} # Failsafe (if the machine is too far away
to simply walk over and
switch to the old BE):
> reboot

[upgrade from source method]
> make DESTDIR=3D${BASEDIR} installkernel
> etcupdate -p -D $BASEDIR
> make DESTDIR=3D${BASEDIR} installworld
> etcupdate -D $BASEDIR
> make DESTDIR=3D${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old
delete-old-libs
> bectl activate ${RELEASE}
#> bectl activate -t ${RELEASE} # Failsafe (if the machine is too far away
to simply walk over and
switch to the old BE):
> reboot

Alexander Leidinger  escreveu no dia quarta,
21/09/2022 =C3=A0(s) 11:45:

> Quoting David Wolfskill  (from Wed, 21 Sep 2022
> 03:25:52 -0700):
>
> > On Wed, Sep 21, 2022 at 11:27:06AM +0200, Alexander Leidinger wrote:
> >>   ...
> >> make DESTDIR=3D${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old
> delete-old-libs
> >>
> >> Usually I replace the delete-old-libs with check-old, as I don't want
> >> to blindly delete them (some ports may depend on them... at least for
> >> the few libs which don't have symbol versioning).
> >> ....
> >
> > A way to address that issue that may work for you is to install
> > appropriate misc/compat* ports/packages.
>
> I'm running exclusively on -current. In the cases where this happens,
> there are no compat packages yet. And I rather update the ports than
> to install a compat package. It doesn't hurt me to keep the libs
> during the pkg rebuild.
>
> In the generic case I prefer to stay safe and keep the libs until I
> validated that nothing uses them anymore. That's the reason why I made
> the delete-old-libs functionality separate from delete-old already in
> the initial implementation.
>
> Bye,
> Alexander.
> --
> http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000002e540105e92df84e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Summary: Using bectl for upgrades

<=
/div>
RELEASE=3DWhatever

> bectl create ${RELEASE}

> bectl mount ${RELEASE}

BASEDIR=3D/tmp/be_mount.XXXX # Use mount point returned by bectl mount



[freebsd-update method]
> freebs=
d-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update \

upgrade -r ${RELEASE}

> freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update insta=
ll

# Ignore admonitions to reboot, since we're using a boot environment
> freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update insta=
ll

> bectl activate ${RELEASE}
#> bectl activate -t ${RELEASE}=
 # Failsafe (if the machine is too far away to simply walk over and=C2=A0 <=
br>
switch to the old BE):

> reboot

[upgrade from source method]
> make DESTDIR=3D${BASEDIR} installkernel
> etcupdate -p -=
D $BASEDIR
> make DESTDIR=3D${BASEDIR} installworld
=
> etcupdate -D $BASEDIR
> make DESTDIR=3D${BASEDIR} -DBATCH=
_DELETE_OLD_FILES delete-old delete-old-libs
> bectl activate =
${RELEASE}
#> bectl activate -t ${RELEASE} # Failsafe (if the =
machine is too far away to simply walk over and=C2=A0 

switch to the old BE):
> reboot

Alexander Leidinger =
<Alexander@leidinger.net&=
gt; escreveu no dia quarta, 21/09/2022 =C3=A0(s) 11:45:
Quoting David Wolfskill <david@catwhisker.org=
> (from Wed, 21 Sep 2022=C2=A0 

03:25:52 -0700):



> On Wed, Sep 21, 2022 at 11:27:06AM +0200, Alexander Leidinger wrote:
>>=C2=A0 =C2=A0...

>> make DESTDIR=3D${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old dele=
te-old-libs

>>

>> Usually I replace the delete-old-libs with check-old, as I don'=
;t want

>> to blindly delete them (some ports may depend on them... at least =
for

>> the few libs which don't have symbol versioning).

>> ....

>

> A way to address that issue that may work for you is to install

> appropriate misc/compat* ports/packages.



I'm running exclusively on -current. In the cases where this happens,=
=C2=A0 

there are no compat packages yet. And I rather update the ports than=C2=A0 =


to install a compat package. It doesn't hurt me to keep the libs=C2=A0 =


during the pkg rebuild.



In the generic case I prefer to stay safe and keep the libs until I=C2=A0 <=
br>
validated that nothing uses them anymore. That's the reason why I made=
=C2=A0 

the delete-old-libs functionality separate from delete-old already in=C2=A0=
 

the initial implementation.



Bye,

Alexander.

-- 

h=
ttp://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF=


htt=
p://www.FreeBSD.org=C2=A0 =C2=A0 netchild@FreeBSD.org=C2=A0 : PGP 0x8F3=
1830F9F2772BF




-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--0000000000002e540105e92df84e--

From nobody Wed Sep 21 21:27:40 2022
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 4MXs2Q6Kzwz4cNJG
	for ; Wed, 21 Sep 2022 21:27:42 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2063.outbound.protection.outlook.com [40.107.115.63])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MXs2P5BZkz3qg8
	for ; Wed, 21 Sep 2022 21:27:41 +0000 (UTC)
	(envelope-from rmacklem@uoguelph.ca)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=WqnrsjM6CF9Ffg16Q5eORSiOwk+5nXSRJ0uGRxh9g+Uc/UsUJYfAzwe7Z0l0pjTYQB5TNhvBod3Gtf50WC0ndTHq+bjN0trUqDnvjXRyTpFCihnYHDp/SuvyIeGLvCcL66MyBKyGM/kHS6QXwGV0rl2Fvnh0yZ4bJ9vbNRECzrWomFHqtN90xa90MNTJSS2fjYXl3qGTyY7XjPdzPCOdMFmLv2fBxYFk7HBZNzRf9+JRpmxbQIftMXoCEH158F6hUtwYve8BkVxe48yOFrhS6VYikvFRUjEcC6Jz3xmfBJ1gPAqbbt1KQrXVaKcpuv3n+wfXTUwhfJ99RUVcUBZ3Zg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=7wtDmuqsvQsU+Qju9fJtOsfYlA2kexPZ5YL3RH0BXi0=;
 b=Mhh343D0F28OjzF4+3HklMMCpp4HyOa25RpTG0AXiqJvWq/cIDPuFh5Y4aF44D+b0kpCQKXRIfqnDrw4EVXYNCtly+v0LI3PwJWj3VzFtvnemNTUGc4EFaP9+TBTErU+uIuJ6IQMnZYNN0moPQiHx5zzgJZ/hV4m7qtlje1zzqKl86uTin3uQj0NrEK079LnSvgvRkJTK63uqe0enP4iPmaF7/pV91v28ILL/kms/x+t8FcDsdVcdjfS1q7jMDHdeuo1KfYMTex6/Of9yF0LSVgLzMH9KIZ0kM7wOKEmBA53IjSfq2sYCkxiTJMaPG5O7WlGuQQnlhsPo19UvaWzsQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca;
 dkim=pass header.d=uoguelph.ca; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=7wtDmuqsvQsU+Qju9fJtOsfYlA2kexPZ5YL3RH0BXi0=;
 b=DssJwGPlOQMi/r2pBmzim0j+0YnH694eVQgV0i/8Jv4htF/LDg7CrgWRCBLZ4DdITDtJSza1VUWH+AKg8xllsVxX3yPd+w5BfSiaHYVPG5KwwxLft+0EYaI9cMHgh7RxIHKdA/1lrgh+FuNL9dv+fUbiycqYnjnaUHiJ3jjDG6OupkTbZrYVowlYjaiL05M9Cvde/Q97QOn7wXUnR93gMzgUYhF7KsyMD0/1La9M2ma0dckAx8+BvcvKQbe0vUJ944rfJlSrULpzcecCpzEKoqes5KdScxMCs35FZ4juyiBJ8eGQqS9zbrrPKnczzB/+DPpgLK5FSQbOVoZnPj1qbA==
Received: from YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:6::7) by
 YT3PR01MB6129.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:5e::19) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5654.17; Wed, 21 Sep 2022 21:27:40 +0000
Received: from YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::9ae8:40c5:73ee:7df7]) by YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM
 ([fe80::9ae8:40c5:73ee:7df7%5]) with mapi id 15.20.5654.017; Wed, 21 Sep 2022
 21:27:40 +0000
From: Rick Macklem 
To: freebsd-current 
Subject: Re: domain names and internationalization?
Thread-Topic: domain names and internationalization?
Thread-Index: AQHYzGXJ7Fz67yTB+EqnzSr9KBXoDq3nO3qAgAA/rWGAAu2//Q==
Date: Wed, 21 Sep 2022 21:27:40 +0000
Message-ID:
 
References:
 
 
 
In-Reply-To:
 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: YQXPR01MB4150:EE_|YT3PR01MB6129:EE_
x-ms-office365-filtering-correlation-id: a9fcd1d2-56fc-4620-3a15-08da9c181cb2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 bf7PaqfJlH7TEyMIklV+NWS4dil028Vbv8ASb+H1ieY+WFh5jwiZiatnCCj3P4002/izje3DFvu55DFk4NYeyCt3FnfiVQRW89dRoBMVpQXGUcx9qx52t1kUGLqrayvnzthfaBFjvxkeWM5D6WKBXh28JCRJqVw06cYiDxdTwwGEINpwJ37FnkeLC/NrtdoWBFZVT80sHUIlJUnH/qBwH4yr6l3d4etlYp/93E2cIv/gL137ZWqehuc/zeTSNsrgVv5aFor6FH6NrS5R+aZSYELYf2B9eXs9UGNuepyqDsEC3+1V2ZvxcggsRWIlwcEdPHMrMTYbQX3hVwgx4yD8qi8YIXTebHnLeQCBeXA/Alxd2oH55IeJjacltyvC4rOfjVhP3dsEYpDZPQ+wbXuNDmJf6Tbkk7WO/TXgQbjjNJx3oQNLIgIq3a83l7v3KQsjDtldxD2Hg3dl73iVEp9B7cArIIO73nqWfdNw29bFHMFoHGWqicNEyiZzddD62DzqgUw7SIY5rdYRi20tGj3sloKXYKRIz2u1RM32bi8tX7w1o2IP4etuqntOcl6YchE2mpe27R2Rq7dhzQCKcxD/47JOU9Dvxi2afBfagffTJbr3Qha9xnzitIIlkGCSHglWXMXV7BCVfgAKejFngguR+ZWmfDryp+kK8yGzPGth2Z9bMNENUVHJxjT+5mk9hdLkHTC/TaFW87xgGcPiKuCf4uZfEzurWuKZVF2etInZMJqW8lZUNuLrplyQe5U6wrg8U5ayaiNTwl81MTAKIcfThIn8lxVbsZGJpkUBUII1z5E=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(366004)(136003)(346002)(39860400002)(376002)(396003)(451199015)(186003)(64756008)(66446008)(66556008)(38070700005)(71200400001)(76116006)(83380400001)(41300700001)(66946007)(91956017)(6506007)(5660300002)(786003)(6916009)(9686003)(33656002)(66476007)(2906002)(86362001)(8676002)(316002)(478600001)(38100700002)(41320700001)(122000001)(7696005)(8936002)(3480700007)(55016003)(52536014);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?AIpyZg+Gk6qTXohb0uuAZ/ptENJAOh3zdm5Vn1gq4wCPpD9IfacbflefmB?=
 =?iso-8859-1?Q?2Lqbz3PgV5Bf1OFYBfPoBoiLG+rnjjyW+YDE1l7idXNcWSC06RuVDC1Gz/?=
 =?iso-8859-1?Q?MbkoPo3oAl3kjVtDpAE04vyPk8DodeA37IrVxLa0v3L43v3K4ELpJsBpnP?=
 =?iso-8859-1?Q?VFFZQuO3WNO97IYGLLYbrfiyUKdWd79u9uhxzur0IyLrj9Vxc5KVVfH6I9?=
 =?iso-8859-1?Q?Meks8Um59mkSlM1a6n5ixlEbcyyLP0kpoFG4piByqhPyUQZhxBcL9QUfHc?=
 =?iso-8859-1?Q?MNWUnOD87JUCRWY98R5mVzf275be2j+VzoR3MALoFHvEYbruD1Ykv6zGOy?=
 =?iso-8859-1?Q?kngqmsx3jGkOxHFQQ8dzDi26Yj07qrm/9ifRSdVFrlwV5E5Q0ooLCEJqdt?=
 =?iso-8859-1?Q?qhRSL7JJ84fMU1hLcmEFT+k3NsgpHuaPvbAU6yYp425XiAhFHWKsfDnEhl?=
 =?iso-8859-1?Q?mREfgYsNmAD4psNKD+pGSV5i8XjrHgSqjfglwWiUHSx5Sj5+I8elnxD4A7?=
 =?iso-8859-1?Q?bvvQZJMC8QzXiWXBncCbwvpoFlCa+3eSzdo2k/xtXxHA7gl4uboK449xr1?=
 =?iso-8859-1?Q?vG4rmwarOxAF4iAFwlpUo1Su84CdbIaytdYNA1w4kyZ7xgja2joAosA8my?=
 =?iso-8859-1?Q?7AT2Y0n4frycBaHA+zl0t2qs+bAkBgm5kUN1YIG7CDXXgortNT4uHTuXzP?=
 =?iso-8859-1?Q?z90srA9al1vtuIxkU5YIZBZEctn6fKSho4ipz1BB+BubNYY9YtWIpHTNAZ?=
 =?iso-8859-1?Q?+UasRuCm8igc9U5C2bq/VT2Il1GchP6kVVgn4nVqtY1YRS9EtqPv/rM48E?=
 =?iso-8859-1?Q?EaXV8EnUGGTx8j2UxqjaYzHDlGaVSJ1rzMLGE+Ou+yuHfrHbvEH8LrEkjO?=
 =?iso-8859-1?Q?MrRsfamx6d9KG4lcsO05yLEL8p6cIqmqAv72JMFgyVhZ72v1sh/SYUKk+N?=
 =?iso-8859-1?Q?ffpb3JleOzKUpVYMx6T7o42Yr7Ek5aBlkPHLoW8e9Vef7lqYXTUShfCkb2?=
 =?iso-8859-1?Q?QjBJORb5xEklbTjwF06T+4Qop7us8We8RHjRd8iZxDvrwIyyfQtIP2GF8C?=
 =?iso-8859-1?Q?s2fq4MYp4T7kTz5yX6LrTxqLvCKdY/0O6PwfU+8C9yanUQEjyUhA3fUllS?=
 =?iso-8859-1?Q?6/zLAUS5K2Dbmkb7mgIvDlVtY+tRsQ34dwkKpspaskryNhBkk7WMfVY3JU?=
 =?iso-8859-1?Q?UiqE6TW62p2vpPQ/WeNuHEGhC/oRCc7ZAn7vSOVHPSXiP9k2XDHLe8SrLq?=
 =?iso-8859-1?Q?ho/DazoeyhNrByXXGN5LhEcK1UkWdzRSnNPxAYBEEKdQEAgaC89ZMCsyS7?=
 =?iso-8859-1?Q?RO5Ah72HOcZHaPAGmGQK3i5s0OX9Jasz1cXE0da26F8ELHO1mGzymQIMo9?=
 =?iso-8859-1?Q?1kmOZXGf4Wn1XylwdHF78UPotL4fikhTvJYlNsO+XjHhpDvI75GXLpiLow?=
 =?iso-8859-1?Q?zx+Zu4msWV4m6ivlgoPU1GNQFyhGTKDb0jAzzcL7YtNo5hOtzC7Vzrmj/m?=
 =?iso-8859-1?Q?Rhz5IOAhjPXoFbXCZQ4T4iCgRSIOJi8cEcTnJVwZ+Fo8tOiAAX3ZaA1NPi?=
 =?iso-8859-1?Q?FgHjQTONQ4j3zCJ4Kx1/WKCXB5u5ntLzLDa7dacfhVz87PB7Jm+cWLAi+l?=
 =?iso-8859-1?Q?96CYgJ0BW0gQB8G01VBKNhK4F/PctJYuPBVNY58RdudP1EmsSDj+ozD1JD?=
 =?iso-8859-1?Q?SNEXio0wiEyu72KrvDh48vu70HooPO5aZYaUdq8/?=
Content-Type: text/plain; charset="iso-8859-1"
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
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YQXPR01MB4150.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: a9fcd1d2-56fc-4620-3a15-08da9c181cb2
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2022 21:27:40.0780
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: a9Lc/02CzdC2M+QWRx73lsfqHs8p9oDkHlpe9/YU+F0yR/eWbwfco+6yDa5nerUAV5NDHbz6+7q64w2PhJQFpQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT3PR01MB6129
X-Rspamd-Queue-Id: 4MXs2P5BZkz3qg8
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=DssJwGPl;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=uoguelph.ca;
	spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.115.63 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca
X-Spamd-Result: default: False [-4.89 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	SUBJECT_ENDS_QUESTION(1.00)[];
	DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.96)[-0.961];
	NEURAL_HAM_LONG(-0.93)[-0.932];
	DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none];
	R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2];
	R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.107.115.63:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[rmacklem];
	DKIM_TRACE(0.00)[uoguelph.ca:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.115.63:from]
X-ThisMailContainsUnwantedMimeParts: N

Christoph Moench-Tegeder  wrote:=0A=
>## Rick Macklem (rmacklem@uoguelph.ca):=0A=
>=0A=
>> I am hoping someone knows what DNS does in this area (the=0A=
>> working group list uses terms like umlaut, which I have never=0A=
>> even heard of;-).=0A=
>=0A=
>The dry start on that topic is RFC5890=0A=
>https://datatracker.ietf.org/doc/html/rfc5890=0A=
>The Wikipedia overview looks really decent:=0A=
>https://en.wikipedia.org/wiki/Internationalized_domain_name=0A=
>What else?=0A=
Thanks. Both the RFC and wikipedia article were useful.=0A=
=0A=
It turns out that the messy part for NFSv4 is that the RFCs=0A=
specified that the labels were in Unicode (U-labels) and=0A=
not A-labels.=0A=
--> RFC 7530 also wants the code to translate an A-label=0A=
       to a U-label and then compare U-labels. (Not sure why=0A=
       that is preferable to a case independent comparison of=0A=
       the A-labels, but maybe the intent was that an A-label=0A=
       would compare the same as a U-label in a domain name?)=0A=
=0A=
The FreeBSD man page for hostname(1) and gethostname(3)=0A=
don't seem to limit the labels in the name to A-label format.=0A=
=0A=
Does anyone use non-ascii (ie. a U-label with multibyte characters=0A=
in it) in a machine's hostname?=0A=
=0A=
Right now the coding of nfsuserd(8) does not conform to the RFCs,=0A=
but should work for domain names where all the labels are=0A=
A-labels (either LDN or "xn--" followed by a Punycode encoded=0A=
unicode string).=0A=
=0A=
rick=0A=
=0A=
Gru=DF <-- see? eszett :)=0A=
Christoph=0A=
=0A=
--=0A=
Spare Space=0A=

From nobody Thu Sep 22 18:31:40 2022
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 4MYP505MqJz4d0j8
	for ; Thu, 22 Sep 2022 18:31:48 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MYP4z3pCfz3cgx
	for ; Thu, 22 Sep 2022 18:31:47 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 28MIVe4x001306
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Thu, 22 Sep 2022 11:31:40 -0700 (PDT)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 28MIVeJE001305
	for freebsd-current@freebsd.org; Thu, 22 Sep 2022 11:31:40 -0700 (PDT)
	(envelope-from sgk)
Date: Thu, 22 Sep 2022 11:31:40 -0700
From: Steve Kargl 
To: freebsd-current@freebsd.org
Subject: A panic a day
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Rspamd-Queue-Id: 4MYP4z3pCfz3cgx
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]
X-ThisMailContainsUnwantedMimeParts: N

All,

I updated my kernel/world/all ports on Sept 19 2022.
Since then, I have had daily panics and hard lock-up
(no panic, keyboard, mouse, network, ...).  The one
panic I did witness sent text scolling off the screen.
There is no dump, or at least, I haven't figured out
a way to get a dump.

Using ports/graphics/tesseract and then hand editing 
the OCR result, the last visible portions is


panic() at panic+0x43/frame 0xfffffe00daf65550
__mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc6/frame 0xfffffe00daf655e0
sched_add() at sched_add+0x98/frame 0xfffffe00daf656a0
setrunnable() at setrunnable+0x73/frame 0xfffffe00daf656d0
wakeup_any() at wakeup_any+0x1f/frame 0xfffffe00daf656f0
taskqueue_enqueue_locked() at taskqueue_enqueue_locked+0x13e/frame 0xfffffe00daf65720
taskqueue_enqueue_timeout_sbt() at taskqueue_enqueue_timeout_sbt+0xe5/frame 0xfffffe00daf65770
resettodr() at resettodr+0x7a/frame 0xfffffe00daf657b0
kern_reboot() at kern_reboot+0x2ae/frame 0xfffffe00daf657f0
vpanic() at vpanic+0x1be/frame 0xfffffe00daf65840
panic() at panic+0x43/frame 0xfffffe00daf658a0
__mtx_lock_spin_flags() at __mix_lock_spin_flags+0xc6/frame 0xfffffe00daf65ab0
sched_add() at sched_add+0x98/frame 0xfffffe00daf65990
setrunnable() at setrunnable+0x73/frame 0xfffffe008daf659c0
wakeup_any() at wakeup_any+0x1f/frame 0xfffffe00daf659e0
taskqueue_enqueue_locked() at taskqueue_enqueue_locked+0x13e/frame 0xfffffe00daf65a11
drm_crtc_helper_set_config() at drm_crtc_helper_set_config+0x971/frame 0xfffffe00daf65abl
radeon_crtc_set_config() at radeon_crtc_set_config+0x22/frame 0xfffffe00daf65ad0
__drm_mode_set_config_internal() at __drm_mode_set_config_internal+0xdd/frame 0xfffffe00daf65b10
drm_client_modeset_commit_locked() at drm_client_modeset_commit_locked+0x160/frame 0xfffffe00daf65b50
drm_client_modeset_commit() at drm_client_modeset_commit+0x21/frame 0xfffffe00daf65b70
drm_fb_helper_restore_fbdev_mode_unlocked() at drm_fb_helper_restore_fbdev_mode_unlocked+0x81/frame 
vt_kms_postswitch() at vt_kms_postswitch+0x166/frame 0xfffffe00daf65bd0
vt_window_switch() at vt_window_switch+0x119/frame 0xfffffe00daf65c1d
vtterm_cngrab() at vtterm_cngrab+0x4f/frame 0xfffffe00daf65c30
cngrab() at cngrab+0x26/frame 0xfffffe00daf65ca0
vpanic() at vpanic+0xf0/frame 0xfffffe00daf65ca0
panic() at panic+0x43/frame 0xfffffe00daf65d00
__mtx_assert() at __mtx_assert+0x9d/frame 0xfffffe00daf65d10
ast_sched_locked() at ast_sched_locked+0x29/frame 0xfffffe00daf65d30
sched_add() at sched_add+0x4c5/frame 0xfffffe00daf65df0
sched_switch() at sched_switch+0x9f/frame 0xfffffe00daf65e20
mi_switch() at mi_switch+0x14b/frame 0xfffffe00daf65e40
sched_bind() at sched_bind+0x73/frame 0xfffffe00daf65e60
pcpu_cache_drain_safe() at pcpu_cache_drain_safe+0x25a/frame 0xfffffe00daf65e90
uma_reclaim_domain() at uma_reclain_domain+0x279/frame Buf ffffe00dafohech
uma_reclaim_worker() at uma_reclaim_worker+0x35/frame 0xfffffe00daf65ef0
fork_exit() at fork_exit+0x80/frame 0xfffffe00daf65f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00daf65f30
--- trap 0, rip = 0, rop = 0, rbp = 0 ---

panic: mtx_lock_spin: recursed on non-recursive mutex sleepq chain @ /usr/src/sys/kern/subr_sleepqueue.c:267

cpuid = 7
time = 1663634259
KDB: stack backtrace:
db_trace_self_wrapper() at 

-- 
Steve

From nobody Thu Sep 22 19:00:53 2022
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 4MYPkj2w9qz4d3gy
	for ; Thu, 22 Sep 2022 19:01:01 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MYPkh4cGqz3fvv
	for ; Thu, 22 Sep 2022 19:01:00 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-il1-x12d.google.com with SMTP id i16so2373034ilq.0
        for ; Thu, 22 Sep 2022 12:01:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:sender:from:to:cc:subject:date;
        bh=Vw7H/BeVI2HhGWl4qzJNU3Yrcn/ZnLVTSRCPwqoIFGI=;
        b=fwCYdK+O/rsolcGpyCl3X+dMeP/lxwv4/VrAdPtm6mLJpVLbduYnb7xXeFfp0tAbdF
         8ANv9WCdKFuzCAjnXDFvAWizdgfLuUR4P20IKsWBLWVlIE3K/eHTdQGTpvlbNDBnbfmv
         j43/tlfGXhSiPUSGqMy4lcwGMis8MZRLQlLYgQnvRSILQXw2PbN0Yd+w0E0deXatG5Wq
         DC/E/4v+CPxT6dzzGLJKUQT5DDG+wucGrLWLDy28knqMEjWuqOPXOr4wCRkSCO58q+1R
         jzmHXrm10fa7a/QdFIXNIEZuThUsopQNVuBYiUJBbHiUvAum2t9ikX5Yrgf1QN2kKQFM
         skMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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;
        bh=Vw7H/BeVI2HhGWl4qzJNU3Yrcn/ZnLVTSRCPwqoIFGI=;
        b=b5N1R5bGiXchpGte9Qgishlc01js48RU1mX9rC/fi+rWDJC3gHZo89U8JxHsgowKzZ
         GbQrtT2sqj5t5yBL/VKLJjS9XeCSdWgB+3jSk7IC2vtohEfJdT/Ga7XUVF0bM2ySXTbp
         eCxvLQknVMYl1q9ymZFX2Fz1Y6/xZodV7GBon+HLmlm8lnLAsh1nOiHVj1vJ8QLgBpYn
         b2VpwxOPIOA5nj2DWRRuNWlTTP73OyrRXenDO2BoCxzSlpimyJciD0qn56FkXw2AKXH1
         8jSm7stzFNKYkUh7eWD4ERQWb2YZHyH/JK5WzhZleyGOKflceE0V+yT1g32lI5F7NHep
         epnw==
X-Gm-Message-State: ACrzQf1waVXyIaLWqpwDbJpEqs3L6rwpkimVVOYwXWc3yavynqQ4fyKs
	suWH4kt4WgTeFXIJHIQ6EAFZttxnqqM=
X-Google-Smtp-Source: AMsMyM7R7aBncpRIewcYIaz0n/acdxBil/HYwqmZ/H6CQYzGRK37SLdzob471mlgZI2zdq18zPdktA==
X-Received: by 2002:a05:6e02:1e06:b0:2f6:2666:e8ca with SMTP id g6-20020a056e021e0600b002f62666e8camr2374952ila.173.1663873259693;
        Thu, 22 Sep 2022 12:00:59 -0700 (PDT)
Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237])
        by smtp.gmail.com with ESMTPSA id f4-20020a05660215c400b00688faad4741sm2596178iow.24.2022.09.22.12.00.56
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 22 Sep 2022 12:00:57 -0700 (PDT)
Date: Thu, 22 Sep 2022 15:00:53 -0400
From: Mark Johnston 
To: Steve Kargl 
Cc: freebsd-current@freebsd.org
Subject: Re: A panic a day
Message-ID: 
References: 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4MYPkh4cGqz3fvv
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=fwCYdK+O;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::12d as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-2.70 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	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:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12d:from];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Sep 22, 2022 at 11:31:40AM -0700, Steve Kargl wrote:
> All,
> 
> I updated my kernel/world/all ports on Sept 19 2022.
> Since then, I have had daily panics and hard lock-up
> (no panic, keyboard, mouse, network, ...).  The one
> panic I did witness sent text scolling off the screen.
> There is no dump, or at least, I haven't figured out
> a way to get a dump.
> 
> Using ports/graphics/tesseract and then hand editing 
> the OCR result, the last visible portions is
> 
> 
> panic() at panic+0x43/frame 0xfffffe00daf65550
> __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc6/frame 0xfffffe00daf655e0
> sched_add() at sched_add+0x98/frame 0xfffffe00daf656a0
> setrunnable() at setrunnable+0x73/frame 0xfffffe00daf656d0
> wakeup_any() at wakeup_any+0x1f/frame 0xfffffe00daf656f0
> taskqueue_enqueue_locked() at taskqueue_enqueue_locked+0x13e/frame 0xfffffe00daf65720
> taskqueue_enqueue_timeout_sbt() at taskqueue_enqueue_timeout_sbt+0xe5/frame 0xfffffe00daf65770
> resettodr() at resettodr+0x7a/frame 0xfffffe00daf657b0
> kern_reboot() at kern_reboot+0x2ae/frame 0xfffffe00daf657f0
> vpanic() at vpanic+0x1be/frame 0xfffffe00daf65840
> panic() at panic+0x43/frame 0xfffffe00daf658a0
> __mtx_lock_spin_flags() at __mix_lock_spin_flags+0xc6/frame 0xfffffe00daf65ab0
> sched_add() at sched_add+0x98/frame 0xfffffe00daf65990
> setrunnable() at setrunnable+0x73/frame 0xfffffe008daf659c0
> wakeup_any() at wakeup_any+0x1f/frame 0xfffffe00daf659e0
> taskqueue_enqueue_locked() at taskqueue_enqueue_locked+0x13e/frame 0xfffffe00daf65a11
> drm_crtc_helper_set_config() at drm_crtc_helper_set_config+0x971/frame 0xfffffe00daf65abl
> radeon_crtc_set_config() at radeon_crtc_set_config+0x22/frame 0xfffffe00daf65ad0
> __drm_mode_set_config_internal() at __drm_mode_set_config_internal+0xdd/frame 0xfffffe00daf65b10
> drm_client_modeset_commit_locked() at drm_client_modeset_commit_locked+0x160/frame 0xfffffe00daf65b50
> drm_client_modeset_commit() at drm_client_modeset_commit+0x21/frame 0xfffffe00daf65b70
> drm_fb_helper_restore_fbdev_mode_unlocked() at drm_fb_helper_restore_fbdev_mode_unlocked+0x81/frame 
> vt_kms_postswitch() at vt_kms_postswitch+0x166/frame 0xfffffe00daf65bd0
> vt_window_switch() at vt_window_switch+0x119/frame 0xfffffe00daf65c1d
> vtterm_cngrab() at vtterm_cngrab+0x4f/frame 0xfffffe00daf65c30
> cngrab() at cngrab+0x26/frame 0xfffffe00daf65ca0
> vpanic() at vpanic+0xf0/frame 0xfffffe00daf65ca0
> panic() at panic+0x43/frame 0xfffffe00daf65d00
> __mtx_assert() at __mtx_assert+0x9d/frame 0xfffffe00daf65d10
> ast_sched_locked() at ast_sched_locked+0x29/frame 0xfffffe00daf65d30
> sched_add() at sched_add+0x4c5/frame 0xfffffe00daf65df0
> sched_switch() at sched_switch+0x9f/frame 0xfffffe00daf65e20
> mi_switch() at mi_switch+0x14b/frame 0xfffffe00daf65e40
> sched_bind() at sched_bind+0x73/frame 0xfffffe00daf65e60
> pcpu_cache_drain_safe() at pcpu_cache_drain_safe+0x25a/frame 0xfffffe00daf65e90
> uma_reclaim_domain() at uma_reclain_domain+0x279/frame Buf ffffe00dafohech
> uma_reclaim_worker() at uma_reclaim_worker+0x35/frame 0xfffffe00daf65ef0
> fork_exit() at fork_exit+0x80/frame 0xfffffe00daf65f30
> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00daf65f30
> --- trap 0, rip = 0, rop = 0, rbp = 0 ---

It looks like you use the 4BSD scheduler?  I think there's a bug in
kick_other_cpu() in that it doesn't make sure that the remote CPU's
curthread lock is held when modifying thread state.  Because 4BSD has a
global scheduler lock, this is often true in practice, but doesn't have
to be.

I think this untested patch will address the panics.  The bug was there
for a long time but some recent restructuring added an assertion which
caught it.

diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
index 9d48aa746f6d..484864b66c1c 100644
--- a/sys/kern/sched_4bsd.c
+++ b/sys/kern/sched_4bsd.c
@@ -1282,9 +1282,10 @@ kick_other_cpu(int pri, int cpuid)
 	}
 #endif /* defined(IPI_PREEMPTION) && defined(PREEMPTION) */
 
-	ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
-	ipi_cpu(cpuid, IPI_AST);
-	return;
+	if (pcpu->pc_curthread->td_lock == &sched_lock) {
+		ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
+		ipi_cpu(cpuid, IPI_AST);
+	}
 }
 #endif /* SMP */
 
@@ -1397,7 +1398,7 @@ sched_add(struct thread *td, int flags)
 
 	cpuid = PCPU_GET(cpuid);
 	if (single_cpu && cpu != cpuid) {
-	        kick_other_cpu(td->td_priority, cpu);
+		kick_other_cpu(td->td_priority, cpu);
 	} else {
 		if (!single_cpu) {
 			tidlemsk = idle_cpus_mask;

From nobody Thu Sep 22 19:05:46 2022
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 4MYPrG3DSVz4d40B
	for ; Thu, 22 Sep 2022 19:05:50 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MYPrF5LgMz3hPl;
	Thu, 22 Sep 2022 19:05:49 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 28MJ5kf4049166
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 22 Sep 2022 12:05:47 -0700 (PDT)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 28MJ5kgG049165;
	Thu, 22 Sep 2022 12:05:46 -0700 (PDT)
	(envelope-from sgk)
Date: Thu, 22 Sep 2022 12:05:46 -0700
From: Steve Kargl 
To: Mark Johnston 
Cc: freebsd-current@freebsd.org
Subject: Re: A panic a day
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
References: 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4MYPrF5LgMz3hPl
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US];
	TO_DN_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Sep 22, 2022 at 03:00:53PM -0400, Mark Johnston wrote:
> On Thu, Sep 22, 2022 at 11:31:40AM -0700, Steve Kargl wrote:
> > All,
> > 
> > I updated my kernel/world/all ports on Sept 19 2022.
> > Since then, I have had daily panics and hard lock-up
> > (no panic, keyboard, mouse, network, ...).  The one
> > panic I did witness sent text scolling off the screen.
> > There is no dump, or at least, I haven't figured out
> > a way to get a dump.
> > 
> > Using ports/graphics/tesseract and then hand editing 
> > the OCR result, the last visible portions is
> > 
> > 

(panic messages removed).

> It looks like you use the 4BSD scheduler?  I think there's a bug in
> kick_other_cpu() in that it doesn't make sure that the remote CPU's
> curthread lock is held when modifying thread state.  Because 4BSD has a
> global scheduler lock, this is often true in practice, but doesn't have
> to be.

Yes, I use 4BSD.  ULE has very poor performance for HPC type work with
OpenMPI.  

> I think this untested patch will address the panics.  The bug was there
> for a long time but some recent restructuring added an assertion which
> caught it.

I'll give it a try, and report back.  Thanks!

-- 
steve

> diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> index 9d48aa746f6d..484864b66c1c 100644
> --- a/sys/kern/sched_4bsd.c
> +++ b/sys/kern/sched_4bsd.c
> @@ -1282,9 +1282,10 @@ kick_other_cpu(int pri, int cpuid)
>  	}
>  #endif /* defined(IPI_PREEMPTION) && defined(PREEMPTION) */
>  
> -	ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
> -	ipi_cpu(cpuid, IPI_AST);
> -	return;
> +	if (pcpu->pc_curthread->td_lock == &sched_lock) {
> +		ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
> +		ipi_cpu(cpuid, IPI_AST);
> +	}
>  }
>  #endif /* SMP */
>  
> @@ -1397,7 +1398,7 @@ sched_add(struct thread *td, int flags)
>  
>  	cpuid = PCPU_GET(cpuid);
>  	if (single_cpu && cpu != cpuid) {
> -	        kick_other_cpu(td->td_priority, cpu);
> +		kick_other_cpu(td->td_priority, cpu);
>  	} else {
>  		if (!single_cpu) {
>  			tidlemsk = idle_cpus_mask;

-- 
Steve

From nobody Thu Sep 22 19:07:08 2022
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 4MYPsp5ycrz4d47N
	for ; Thu, 22 Sep 2022 19:07:10 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MYPsp32yWz3jMF;
	Thu, 22 Sep 2022 19:07:10 +0000 (UTC)
	(envelope-from mjguzik@gmail.com)
Received: by mail-oi1-x236.google.com with SMTP id v130so13622028oie.2;
        Thu, 22 Sep 2022 12:07:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc:subject:date;
        bh=LuQkMHT2CIEungGaWtcwBCHNiMRtB504iKdVte5fI6M=;
        b=eB9H8p6ceYkNzF3rMrbFJ5lQztUpJZAVP/nopLAmcWBRJGxATQ2nP5uaPk5HHWii5e
         MHBCAlhJhJ6z3qYVLVuoAvrOECNzqOU3F0OyQ1p2V7Qq1v13/ha3Qqpm6b7yS/kBTqJB
         bOuoCITUcqINV8kAnlGhohrEPSsB0kLh/TLZPxUsTK4xr+r94nA1tdufw/ux0odhsx9q
         W7iF1JQJSSy2VpjUaaSZGViNZTw8NL6pymbVkEpBg6h+FHgcV1GGhW6TXzO4f+BZWKsW
         646P2nZSfOjXOpiXfnmMc+8qU4/Ds9J1RPrVwPMIZNfUXV9WwrBrL1sEHjNBO3+7AUx6
         xBKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=LuQkMHT2CIEungGaWtcwBCHNiMRtB504iKdVte5fI6M=;
        b=Mo3wGxPW6TQBkfLSgjyZj+PMrGKLIsSHb2TOa4ZE0Rsrosq/md3p/o3yHNKsYm8ggG
         /wPXFLfXjqpMHBFds0iEpw9NSqiN9A5MwwIGp+sU6C8BbYgKIGXU21wZhM+7/MAAX8MM
         gral1x92cufDd+pBlho7Jjh3MnS5/W0znLJKTY4ZLaC0rrNMOHjxFHl7ihV7Msuve2oY
         KUubz0ZP1zXTbcekFnqdFoybk3IYeWfhbU3DeIwg8MtcCfn/eXQr0E8nRBIgA+hvS9m5
         XcBdLkWiqvlO3L2X4d6Ja+trx5ptDeF4q14JxYSdVjbtHRuTeCmpbft+gLiCSEz7iMat
         Tc3w==
X-Gm-Message-State: ACrzQf0WHuDBvJGdiVvlRFYbRVwtbt4xjva2zXw0rJTJKG3lz8CNzzTD
	FYKGBHaEuCUlXMJQxHxMK59eKaxcnIs70JA9xB26ig2L
X-Google-Smtp-Source: AMsMyM5SU9xff/gPZg1ZfExMq/fUjnQkaoLgUG9jfpiEXJn0qzoS1d79hn3WKf5RW+uCD2Sy7AwPiPpNjFdUcNYsYgk=
X-Received: by 2002:a05:6808:2390:b0:350:5c6b:5ef9 with SMTP id
 bp16-20020a056808239000b003505c6b5ef9mr2397360oib.96.1663873629642; Thu, 22
 Sep 2022 12:07:09 -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
Received: by 2002:a8a:352:0:b0:474:267f:5338 with HTTP; Thu, 22 Sep 2022
 12:07:08 -0700 (PDT)
In-Reply-To: 
References: 
  
From: Mateusz Guzik 
Date: Thu, 22 Sep 2022 21:07:08 +0200
Message-ID: 
Subject: Re: A panic a day
To: sgk@troutmask.apl.washington.edu
Cc: Mark Johnston , freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MYPsp32yWz3jMF
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=eB9H8p6c;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2607:f8b0:4864:20::236 as permitted sender) smtp.mailfrom=mjguzik@gmail.com
X-Spamd-Result: default: False [-3.78 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.984];
	NEURAL_HAM_MEDIUM(-0.79)[-0.793];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::236:from];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 9/22/22, Steve Kargl  wrote:
> On Thu, Sep 22, 2022 at 03:00:53PM -0400, Mark Johnston wrote:
>> On Thu, Sep 22, 2022 at 11:31:40AM -0700, Steve Kargl wrote:
>> > All,
>> >
>> > I updated my kernel/world/all ports on Sept 19 2022.
>> > Since then, I have had daily panics and hard lock-up
>> > (no panic, keyboard, mouse, network, ...).  The one
>> > panic I did witness sent text scolling off the screen.
>> > There is no dump, or at least, I haven't figured out
>> > a way to get a dump.
>> >
>> > Using ports/graphics/tesseract and then hand editing
>> > the OCR result, the last visible portions is
>> >
>> >
>
> (panic messages removed).
>
>> It looks like you use the 4BSD scheduler?  I think there's a bug in
>> kick_other_cpu() in that it doesn't make sure that the remote CPU's
>> curthread lock is held when modifying thread state.  Because 4BSD has a
>> global scheduler lock, this is often true in practice, but doesn't have
>> to be.
>
> Yes, I use 4BSD.  ULE has very poor performance for HPC type work with
> OpenMPI.
>

Is there an easy way to set it up for testing purposes?

>> I think this untested patch will address the panics.  The bug was there
>> for a long time but some recent restructuring added an assertion which
>> caught it.
>
> I'll give it a try, and report back.  Thanks!
>
> --
> steve
>
>> diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
>> index 9d48aa746f6d..484864b66c1c 100644
>> --- a/sys/kern/sched_4bsd.c
>> +++ b/sys/kern/sched_4bsd.c
>> @@ -1282,9 +1282,10 @@ kick_other_cpu(int pri, int cpuid)
>>  	}
>>  #endif /* defined(IPI_PREEMPTION) && defined(PREEMPTION) */
>>
>> -	ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
>> -	ipi_cpu(cpuid, IPI_AST);
>> -	return;
>> +	if (pcpu->pc_curthread->td_lock == &sched_lock) {
>> +		ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
>> +		ipi_cpu(cpuid, IPI_AST);
>> +	}
>>  }
>>  #endif /* SMP */
>>
>> @@ -1397,7 +1398,7 @@ sched_add(struct thread *td, int flags)
>>
>>  	cpuid = PCPU_GET(cpuid);
>>  	if (single_cpu && cpu != cpuid) {
>> -	        kick_other_cpu(td->td_priority, cpu);
>> +		kick_other_cpu(td->td_priority, cpu);
>>  	} else {
>>  		if (!single_cpu) {
>>  			tidlemsk = idle_cpus_mask;
>
> --
> Steve
>
>


-- 
Mateusz Guzik 

From nobody Thu Sep 22 20:40:08 2022
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 4MYRx84363z4dFKK
	for ; Thu, 22 Sep 2022 20:40:12 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MYRx64xcHz3q4X;
	Thu, 22 Sep 2022 20:40:10 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 28MKe8sR001197
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Thu, 22 Sep 2022 13:40:08 -0700 (PDT)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 28MKe8vq001196;
	Thu, 22 Sep 2022 13:40:08 -0700 (PDT)
	(envelope-from sgk)
Date: Thu, 22 Sep 2022 13:40:08 -0700
From: Steve Kargl 
To: Mateusz Guzik 
Cc: Mark Johnston , freebsd-current@freebsd.org
Subject: Re: A panic a day
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
References: 
 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4MYRx64xcHz3q4X
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US];
	RCVD_TLS_LAST(0.00)[];
	R_DKIM_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Sep 22, 2022 at 09:07:08PM +0200, Mateusz Guzik wrote:
> On 9/22/22, Steve Kargl  wrote:
> > On Thu, Sep 22, 2022 at 03:00:53PM -0400, Mark Johnston wrote:
> >> On Thu, Sep 22, 2022 at 11:31:40AM -0700, Steve Kargl wrote:
> >> > All,
> >> >
> >> > I updated my kernel/world/all ports on Sept 19 2022.
> >> > Since then, I have had daily panics and hard lock-up
> >> > (no panic, keyboard, mouse, network, ...).  The one
> >> > panic I did witness sent text scolling off the screen.
> >> > There is no dump, or at least, I haven't figured out
> >> > a way to get a dump.
> >> >
> >> > Using ports/graphics/tesseract and then hand editing
> >> > the OCR result, the last visible portions is
> >> >
> >> >
> >
> > (panic messages removed).
> >
> >> It looks like you use the 4BSD scheduler?  I think there's a bug in
> >> kick_other_cpu() in that it doesn't make sure that the remote CPU's
> >> curthread lock is held when modifying thread state.  Because 4BSD has a
> >> global scheduler lock, this is often true in practice, but doesn't have
> >> to be.
> >
> > Yes, I use 4BSD.  ULE has very poor performance for HPC type work with
> > OpenMPI.
> >
> 
> Is there an easy way to set it up for testing purposes?
> 

I reported this years ago.  One instance is here

https://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html

and, I've tested ULE a few times since.

A HPC program, compiled with openmpi, can spawn multiple images.
The gist of the problem is that under ULE, if one gets in an
over-subscribed situation (e.g., N+1 images and only N cpus),
then ULE's cpu affinity will place two images on 1 cpu.  Those
images ping-pong.  The other N-1 images run happily.  An image
that completes its task will then wait on the ping-pong match
before getting its next quantum of work.  Under 4BSD, the N+1
images simply run on the N cpus where each gets a cpu slice. 

Note, you don't need an openmpi program to get this situation.
Simply use a numerical intensive code that takes 5 or so minutes
to complete.  Start N+1 jobs.  You'll get 2 jobs completing for
1 CPU.   

-- 
Steve

From nobody Fri Sep 23 16:46:08 2022
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 4MYyhj0vLRz4cNsn
	for ; Fri, 23 Sep 2022 16:46:13 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MYyhg6Gg5z3C3f;
	Fri, 23 Sep 2022 16:46:11 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 28NGk8ls014730
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 23 Sep 2022 09:46:08 -0700 (PDT)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 28NGk88r014729;
	Fri, 23 Sep 2022 09:46:08 -0700 (PDT)
	(envelope-from sgk)
Date: Fri, 23 Sep 2022 09:46:08 -0700
From: Steve Kargl 
To: Mark Johnston 
Cc: freebsd-current@freebsd.org
Subject: Re: A panic a day
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
References: 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4MYyhg6Gg5z3C3f
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US];
	TO_DN_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Sep 22, 2022 at 03:00:53PM -0400, Mark Johnston wrote:
> 
> I think this untested patch will address the panics.  The bug was there
> for a long time but some recent restructuring added an assertion which
> caught it.
> 
> diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> index 9d48aa746f6d..484864b66c1c 100644
> --- a/sys/kern/sched_4bsd.c
> +++ b/sys/kern/sched_4bsd.c
> @@ -1282,9 +1282,10 @@ kick_other_cpu(int pri, int cpuid)
>  	}
>  #endif /* defined(IPI_PREEMPTION) && defined(PREEMPTION) */
>  
> -	ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
> -	ipi_cpu(cpuid, IPI_AST);
> -	return;
> +	if (pcpu->pc_curthread->td_lock == &sched_lock) {
> +		ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
> +		ipi_cpu(cpuid, IPI_AST);
> +	}
>  }
>  #endif /* SMP */
>  
> @@ -1397,7 +1398,7 @@ sched_add(struct thread *td, int flags)
>  
>  	cpuid = PCPU_GET(cpuid);
>  	if (single_cpu && cpu != cpuid) {
> -	        kick_other_cpu(td->td_priority, cpu);
> +		kick_other_cpu(td->td_priority, cpu);
>  	} else {
>  		if (!single_cpu) {
>  			tidlemsk = idle_cpus_mask;

Mark,

My system has been running a fairly heavy load with this
patch for the last 20 or so hours without any incidences.
In fact, the system feels snappier.  Thanks for the quick
response with a patch.

-- 
Steve

From nobody Fri Sep 23 21:33:10 2022
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 4MZ53t5F7Fz4d0lf;
	Fri, 23 Sep 2022 21:33: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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MZ53t4Rlnz3ZfR;
	Fri, 23 Sep 2022 21:33:14 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663968794;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=3XSBssKp5p4oMOTqLhyHr99E90QGaCxAeiVOy9PImYc=;
	b=v0ZR1l7rmMa+iVF5sHYR401WQKKP4j37sSCTxebL/ZEVG4VOxU0Agq4WSk4oxgdDzd4p6i
	mIfBwtBEY4tnX0nr5jCtAz4tLPAoJloV5SF/ZPOsZuP5OsvPZKJO2UX/D1pfy21Am2VWkB
	g2kK3XyTUzHNhFtyBWAkQMDoqambzsyfbjIqrqzrCCGunWjmFrqfGhuuk8+jcpFIhU1BeQ
	iM+c5vZd9bj2teK8pV7X/LHGs4IT5Uc6ubbLr3764UnF1TKm2GyFdpBKKr8TMXdl91wW0G
	CnRtsTbswUyNIfsR7Evp7jrwac4d889q+d5saAS7CRNpXiSM4zVs3ZMhcTn4zg==
Received: from [192.168.0.88] (unknown [195.64.148.76])
	(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 4MZ53s6HDZz1S87;
	Fri, 23 Sep 2022 21:33:13 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Message-ID: 
Date: Sat, 24 Sep 2022 00:33:10 +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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.3.0
Content-Language: en-US
To: freebsd-stable List 
Cc: FreeBSD Current 
From: Andriy Gapon 
Subject: usbhid panic when switching vt-s (invariants+witness enabled)
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663968794;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=3XSBssKp5p4oMOTqLhyHr99E90QGaCxAeiVOy9PImYc=;
	b=sYbnWkI+Mz2sJYXV/tMZ+p6s60siWu91Yr2prBuGBjEL1oxI/yGtBXq2YoLaRwBRhRWQBy
	DYAH0+xep3bgRX5XzvuDZQgPTwiQdbEiqoZWv3oWi5S+w8HxbNxOW5+ca3FNU1tDOJj49G
	ZIO8R/Tif/1XDMDJNR0m4uHV8XrWcS/CVFo5M9broEMMy04jhPycvToji+UPMmfVaCAqnM
	Rc8pNK7ka2gGxxCRZvi2CkLObjd8GduF6BrTKjVmyT/Rb00WWPOpSz/oi6SM9NdTBgiD86
	AfG2eIdkexXG1Cowjg8kDCsGcFaXEWYqSe2dKlZkrMWGWYPKTKor4r3aEd85JA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663968794; a=rsa-sha256; cv=none;
	b=t07oLyLEqIcyaGLA5KtSKqgwBCg+4DcnouS5Mbg24HloMjAUoNoew7x6FkQAIWini1Nl3l
	Rny1gNyk6anT7lpzaHo6+6blJKb7hx6PIT3DDPSEXcd6VlnjSKpZExNCmgpE+jVGwUTeCP
	4MLhS8+i/7YGPfUFkd2OfAmPfTg14vIGZNF4a7Oigju+jwO0UvXX2ZQp3yyd5pa+6WeY4S
	ZxuHKGSbRoxntlphclg7A/BvkYllSqexrkEm3+CbInb8YeI6YHyQ1+AwloCMIiZZCfZ7xn
	3OQEvBJ2Z7+U37E5tKkGCymWlqtBjQaex9xjQ1I9drELN9pC72hIxQ9DA3CoCQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


It seems that the problem may be related to different keyboard LED states 
between the VTs.  The system is a fresh stable/13.  The panic looks like an 
attempt to sleep while in an interrupt thread (a callout?).

panic: sleepq_add: td 0xfffff80006af0000 to sleep on wchan 0xfffff802ea752e08 
with sleeping prohibited
cpuid = 5
time = 1663940484
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff8061555b = db_trace_self_wrapper+0x2b/frame 
0xfffffe003590e7f0
kdb_backtrace() at 0xffffffff80942637 = kdb_backtrace+0x37/frame 0xfffffe003590e8a0
vpanic() at 0xffffffff808f4c84 = vpanic+0x184/frame 0xfffffe003590e900
panic() at 0xffffffff808f4a33 = panic+0x43/frame 0xfffffe003590e960
sleepq_add() at 0xffffffff809521ab = sleepq_add+0x37b/frame 0xfffffe003590e9b0
_sleep() at 0xffffffff80902118 = _sleep+0x238/frame 0xfffffe003590ea40
usbhid_sync_xfer() at 0xffffffff8532e071 = usbhid_sync_xfer+0x171/frame 
0xfffffe003590eaa0
usbhid_set_report() at 0xffffffff8532db26 = usbhid_set_report+0x96/frame 
0xfffffe003590eae0
hid_set_report() at 0xffffffff80686caa = hid_set_report+0x6a/frame 
0xfffffe003590eb20
hidbus_write() at 0xffffffff85335a7c = hidbus_write+0x5c/frame 0xfffffe003590eb50
hid_write() at 0xffffffff80686b98 = hid_write+0x58/frame 0xfffffe003590eb80
hkbd_set_leds() at 0xffffffff85c1cfe6 = hkbd_set_leds+0x206/frame 0xfffffe003590ebc0
hkbd_ioctl_locked() at 0xffffffff85c1cd6b = hkbd_ioctl_locked+0x33b/frame 
0xfffffe003590ec20
hkbd_ioctl_locked() at 0xffffffff85c1caff = hkbd_ioctl_locked+0xcf/frame 
0xfffffe003590ec80
hkbd_ioctl() at 0xffffffff85c1ba5a = hkbd_ioctl+0xba/frame 0xfffffe003590ecc0
kbdmux_ioctl() at 0xffffffff80695d3b = kbdmux_ioctl+0x12b/frame 0xfffffe003590ed00
vt_window_switch() at 0xffffffff8079d969 = vt_window_switch+0x229/frame 
0xfffffe003590ed40
vt_switch_timer() at 0xffffffff807a15a1 = vt_switch_timer+0x21/frame 
0xfffffe003590ed60
softclock_call_cc() at 0xffffffff809127c4 = softclock_call_cc+0x244/frame 
0xfffffe003590ee20
softclock() at 0xffffffff80912c1c = softclock+0x7c/frame 0xfffffe003590ee50
ithread_loop() at 0xffffffff808b662a = ithread_loop+0x2da/frame 0xfffffe003590eef0
fork_exit() at 0xffffffff808b2f85 = fork_exit+0xc5/frame 0xfffffe003590ef30
fork_trampoline() at 0xffffffff80c084fe = fork_trampoline+0xe/frame 
0xfffffe003590ef30


-- 
Andriy Gapon

From nobody Fri Sep 23 21:43:40 2022
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 4MZ5J765ZDz4d1mM;
	Fri, 23 Sep 2022 21:43:51 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4MZ5J64gZzz3dqF;
	Fri, 23 Sep 2022 21:43:50 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 36B44260BD2;
	Fri, 23 Sep 2022 23:43:43 +0200 (CEST)
Message-ID: <0668f473-f6d3-eacf-e4ef-f8530563daed@selasky.org>
Date: Fri, 23 Sep 2022 23:43:40 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: usbhid panic when switching vt-s (invariants+witness enabled)
To: Andriy Gapon , freebsd-stable List 
Cc: FreeBSD Current ,
 Vladimir Kondratyev 
References: 
Content-Language: en-US
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4MZ5J64gZzz3dqF
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_ALL(0.00)[];
	MLMMJ_DEST(0.00)[current@FreeBSD.org,stable@FreeBSD.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/23/22 23:33, Andriy Gapon wrote:
> 
> It seems that the problem may be related to different keyboard LED 
> states between the VTs.  The system is a fresh stable/13.  The panic 
> looks like an attempt to sleep while in an interrupt thread (a callout?).
> 

Hi,

I suspect vt_switch_timer must have a task to handle those requests, 
which allows sleeping.

Vladimir, will you handle this?

It is a minor regression issue when using the new usbhid feature.

--HPS

> panic: sleepq_add: td 0xfffff80006af0000 to sleep on wchan 
> 0xfffff802ea752e08 with sleeping prohibited
> cpuid = 5
> time = 1663940484
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0xffffffff8061555b = 
> db_trace_self_wrapper+0x2b/frame 0xfffffe003590e7f0
> kdb_backtrace() at 0xffffffff80942637 = kdb_backtrace+0x37/frame 
> 0xfffffe003590e8a0
> vpanic() at 0xffffffff808f4c84 = vpanic+0x184/frame 0xfffffe003590e900
> panic() at 0xffffffff808f4a33 = panic+0x43/frame 0xfffffe003590e960
> sleepq_add() at 0xffffffff809521ab = sleepq_add+0x37b/frame 
> 0xfffffe003590e9b0
> _sleep() at 0xffffffff80902118 = _sleep+0x238/frame 0xfffffe003590ea40
> usbhid_sync_xfer() at 0xffffffff8532e071 = usbhid_sync_xfer+0x171/frame 
> 0xfffffe003590eaa0
> usbhid_set_report() at 0xffffffff8532db26 = usbhid_set_report+0x96/frame 
> 0xfffffe003590eae0
> hid_set_report() at 0xffffffff80686caa = hid_set_report+0x6a/frame 
> 0xfffffe003590eb20
> hidbus_write() at 0xffffffff85335a7c = hidbus_write+0x5c/frame 
> 0xfffffe003590eb50
> hid_write() at 0xffffffff80686b98 = hid_write+0x58/frame 0xfffffe003590eb80
> hkbd_set_leds() at 0xffffffff85c1cfe6 = hkbd_set_leds+0x206/frame 
> 0xfffffe003590ebc0
> hkbd_ioctl_locked() at 0xffffffff85c1cd6b = 
> hkbd_ioctl_locked+0x33b/frame 0xfffffe003590ec20
> hkbd_ioctl_locked() at 0xffffffff85c1caff = hkbd_ioctl_locked+0xcf/frame 
> 0xfffffe003590ec80
> hkbd_ioctl() at 0xffffffff85c1ba5a = hkbd_ioctl+0xba/frame 
> 0xfffffe003590ecc0
> kbdmux_ioctl() at 0xffffffff80695d3b = kbdmux_ioctl+0x12b/frame 
> 0xfffffe003590ed00
> vt_window_switch() at 0xffffffff8079d969 = vt_window_switch+0x229/frame 
> 0xfffffe003590ed40
> vt_switch_timer() at 0xffffffff807a15a1 = vt_switch_timer+0x21/frame 
> 0xfffffe003590ed60
> softclock_call_cc() at 0xffffffff809127c4 = 
> softclock_call_cc+0x244/frame 0xfffffe003590ee20
> softclock() at 0xffffffff80912c1c = softclock+0x7c/frame 0xfffffe003590ee50
> ithread_loop() at 0xffffffff808b662a = ithread_loop+0x2da/frame 
> 0xfffffe003590eef0
> fork_exit() at 0xffffffff808b2f85 = fork_exit+0xc5/frame 0xfffffe003590ef30
> fork_trampoline() at 0xffffffff80c084fe = fork_trampoline+0xe/frame 
> 0xfffffe003590ef30
> 
> 


From nobody Sat Sep 24 00:00:05 2022
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 4MZ8KL15kGz4dGb9;
	Sat, 24 Sep 2022 00:00:06 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MZ8KL0WLgz3rkp;
	Sat, 24 Sep 2022 00:00:06 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1663977606;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=;
	b=Qz8zi/y6oP6137Dhlcgou53SC4vVKWCL9d+q5XvUoB4kI289p5Dl14QBucDgw9Bo6o3lHm
	xfeAcPy//+dN0D4sSKIVPREA75ZoZ3Gk9ODByAUuxoGhRAoTTMlnw3ezzeBDGR3NOF8l50
	Bw3nJhmejPKjLkw2SEkter5LCl5hF21KbZRd3c/FGmQOuvccs/h7Urt3McZxLJhfwL6CbE
	L3Qy3QN0awXldCaTguIh1ZZJI6tNn6JMmNbYICc+WXcO1qfiYGlXxzsaXThT/wdxWDyeGp
	J1vOKMeepIHMFRENuuC+fiiXjnFaAcGKEmJKXyjKKn6EHqsH/7P17jrBjTkRFg==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id E61284AB6; Sat, 24 Sep 2022 00:00:05 +0000 (UTC)
To: freebsd-quarterly-calls@FreeBSD.org
Subject: [LAST OFFICIAL REMINDER] Call for 2022Q3 quarterly status reports
Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org
Message-Id: <20220924000005.E61284AB6@freefall.freebsd.org>
Date: Sat, 24 Sep 2022 00:00:05 +0000 (UTC)
From: Lorenzo Salvadore 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1663977606;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=;
	b=EY57eT8hhUNaNydAs1J2lS2y+9LtNXJ3w+lFGfZN3/1E6JwD0RWBgLOO7CvOkXmmGJmjfQ
	vgr9BD6Q57vxW/dM6AjSdwRblevnw07Nl+a5p3VbvoVpEGL1/6afiSO5BXh5xw/ys8qlIK
	bml5wSPLDytMeUAjEOQqtojBf4JYcJSkXncT8CDq2iqDx+xY3nZmZBUTWoa6oQe9wdn55E
	zoI6KeyQB0v8Xe3ZQYNArCTwNlkIs2WfSoTOcusM6NzcgGaHqCRD1eCQ1TXr7e5U65ovKW
	owHnbgJclhONNsz8keGAy9pC/uqshJlpdrUPXxuCZ3DQsltD9S33tB/yQPwz1Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663977606; a=rsa-sha256; cv=none;
	b=xGOz5qm87xoh1NNsBh1RrGJ4HcykSok7lZwotgsC4Jmwf7iJngbQ4w9vMzU53Cfdzww5M6
	QriJdPujONSZW9Gp+JxV/QGUg/S/ytufUTXtx4+tIHsy3B5UPVfvqsNHYtQ7OEEr7neOKu
	BmTjVv7vPshtX/ykwbWffOsu/VddyqlhUep8bD7U/PTZDEm/l5JLTQM2gsRY09jWdhuPwT
	i5734I4kYsH+ToAh/XGgmSQ8rJhRiXz6sz/bo+ZzCU8ecpLCSPYEzzOdHtCVVRVRUWXvEd
	IG1xpbWppWvc0jSmQ+haFYD37FH06ehqeRk1c4IIw9eCGxOOLfKkX82h+EweZg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N
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

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
September, 30th 2022 for work done since the last round of Quarterly Reports:
July 2022 - September 2022.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the AsciiDoctor template, fill it in, and
email it to quarterly-submissions@FreeBSD.org.
The new AsciiDoctor template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc

We look forward to seeing your 2022Q3 reports!

Thanks,

Lorenzo Salvadore (on behalf of quarterly@)

From nobody Sat Sep 24 00:22:31 2022
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 4MZ8qK0YxTz4dJqK
	for ; Sat, 24 Sep 2022 00:22:37 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MZ8qH6K1wz3vxj
	for ; Sat, 24 Sep 2022 00:22:35 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: by mail-io1-xd36.google.com with SMTP id r134so1168684iod.8
        for ; Fri, 23 Sep 2022 17:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:sender:from:to:cc:subject:date;
        bh=jgkSdylOfZaB9kzgswSnupJwGqKfDbo4Sw2lZTtqDJ4=;
        b=U0iCJZyybcA1m8NunMfBYw7FLXzhVxxlpII3KmwVhDY7JmNMJO4cqkXrVHhPMZ/gz0
         gn36l8tMRD65Co+iSVPqnxZyvqxZsnfL2STQniby9b/rvzDfL8QpMmRu4vmLd5yvjVJB
         u+Ax9ud/K9LP1ZzylBzcr/Vs91HKj3HAAOh4mDzVfAXQUULPVOJ69YgPtXlbhAwvRZRx
         +JbNjwaE7AtdZSSSUvZxK+Mu3bVSpN0BdCd9+j3zrLXxUENssVU4Grr3ZQ9xK8VRIngx
         fSA/vsmgviHAIuQtkjsf4T6Jmfwla7P7rZgw2luLQZB43Zrx3Lt/lG7L3zRe6Choj8SN
         JeAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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;
        bh=jgkSdylOfZaB9kzgswSnupJwGqKfDbo4Sw2lZTtqDJ4=;
        b=ck+Fq60pWKAjYvbRJKLVayIDk/gobWiTFxX3CqkfGcBrcSZ6ANFYaoCeehOx0OvAT9
         HAVrjqYvjgNGfCBBHC49lG5EfekGYsOQWEl/cvTtTGH5M+KYFc1eP3NYXphXuBusULb8
         by7+uCx19fSTIznSzCHWEc5+aKl7ZvyI2phzXa6xiaoD3B+Va1xamCSWmUOHH35QYRsg
         cNhY5Dkl1rHJOmmh5DuqFpwvLxKow3JwfgqJYGtmZWSDbw2dC48ZOhNG5y+TJI49ZEPK
         4X6Z4fU3BLN12tZevtzH4LhC0rMaVCdFCNoQwnzFeIOSovXsAhdjJzuzYi0pdcXaRETX
         pwPQ==
X-Gm-Message-State: ACrzQf0s2+o62uviV4oUPgFyG+fmzhPgTd8PEQ+LoLJhOTQ/UHcBGi1E
	cc9NHqmb2AEqBmJKTuDbslH+gwl7svU=
X-Google-Smtp-Source: AMsMyM7Tj2aZ2M06FnkjfpsRp3dn0JGstb7CkffZREq7RMhZv7bo7lU4KicLN7be2iMrRVFWtWgLWw==
X-Received: by 2002:a6b:691d:0:b0:6a3:e87e:5aed with SMTP id e29-20020a6b691d000000b006a3e87e5aedmr4940251ioc.56.1663978954940;
        Fri, 23 Sep 2022 17:22:34 -0700 (PDT)
Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237])
        by smtp.gmail.com with ESMTPSA id j21-20020a056638053500b0035a9b0050easm3972242jar.18.2022.09.23.17.22.33
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 23 Sep 2022 17:22:34 -0700 (PDT)
Date: Fri, 23 Sep 2022 20:22:31 -0400
From: Mark Johnston 
To: Steve Kargl 
Cc: freebsd-current@freebsd.org
Subject: Re: A panic a day
Message-ID: 
References: 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4MZ8qH6K1wz3vxj
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=U0iCJZyy;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d36 as permitted sender) smtp.mailfrom=markjdb@gmail.com
X-Spamd-Result: default: False [-2.70 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	MID_RHS_NOT_FQDN(0.50)[];
	FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d36:from];
	DMARC_NA(0.00)[freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Sep 23, 2022 at 09:46:08AM -0700, Steve Kargl wrote:
> On Thu, Sep 22, 2022 at 03:00:53PM -0400, Mark Johnston wrote:
> > 
> > I think this untested patch will address the panics.  The bug was there
> > for a long time but some recent restructuring added an assertion which
> > caught it.
> > 
> > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> > index 9d48aa746f6d..484864b66c1c 100644
> > --- a/sys/kern/sched_4bsd.c
> > +++ b/sys/kern/sched_4bsd.c
> > @@ -1282,9 +1282,10 @@ kick_other_cpu(int pri, int cpuid)
> >  	}
> >  #endif /* defined(IPI_PREEMPTION) && defined(PREEMPTION) */
> >  
> > -	ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
> > -	ipi_cpu(cpuid, IPI_AST);
> > -	return;
> > +	if (pcpu->pc_curthread->td_lock == &sched_lock) {
> > +		ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
> > +		ipi_cpu(cpuid, IPI_AST);
> > +	}
> >  }
> >  #endif /* SMP */
> >  
> > @@ -1397,7 +1398,7 @@ sched_add(struct thread *td, int flags)
> >  
> >  	cpuid = PCPU_GET(cpuid);
> >  	if (single_cpu && cpu != cpuid) {
> > -	        kick_other_cpu(td->td_priority, cpu);
> > +		kick_other_cpu(td->td_priority, cpu);
> >  	} else {
> >  		if (!single_cpu) {
> >  			tidlemsk = idle_cpus_mask;
> 
> Mark,
> 
> My system has been running a fairly heavy load with this
> patch for the last 20 or so hours without any incidences.
> In fact, the system feels snappier.  Thanks for the quick
> response with a patch.

Thanks, committed in c2d27b0ec700.

From nobody Sat Sep 24 13:47:27 2022
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 4MZVh40JRJz4cj1c
	for ; Sat, 24 Sep 2022 13:47:32 +0000 (UTC)
	(envelope-from tamelingdaniel@gmail.com)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MZVh337kzz44m0
	for ; Sat, 24 Sep 2022 13:47:31 +0000 (UTC)
	(envelope-from tamelingdaniel@gmail.com)
Received: by mail-wm1-x329.google.com with SMTP id r133-20020a1c448b000000b003b494ffc00bso4887268wma.0
        for ; Sat, 24 Sep 2022 06:47:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:to:from:date:from:to:cc:subject:date;
        bh=ALqjrpleWwr8tEosb47plvccLRiBWcvvnr92kGZTlBA=;
        b=Gb6VtR7hWGF8alNCO+bAnAiAp7+GKs4fZNTm2JAm4ETeP95Wg4g1HBkI/cG1weRkNO
         SPnhTAJ8emni6QnUwD2rUqTOQWUIjjSl9ViFgqabBf2VV49NefS0Mp4gHNrYEXvpyUjf
         y487b24AsnCjqmDRikKGgmsKBWZQY4cf5hgOrHG1marDlWfLkFTZaZto4bmery3izWRW
         PTzZnn8swyvlyxYaTqABj9ZdFCz4JJU1cc0g4ieH1P2zaCnIK67UfXdcoGg8QESSOuGZ
         7IAcSBJX+5PHjXuzPmJX8xIDqiDRpy33tVu07482ueaZ+A0E3/7eDvTyimblQjgbpb42
         a38A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date;
        bh=ALqjrpleWwr8tEosb47plvccLRiBWcvvnr92kGZTlBA=;
        b=l6JgF3qXZylqTFAxP7jxrNoGbUp6PO4OLmoFpCTX38GcGaQqEo8zOFgaPPUQ0I9S4L
         RQuicByXz6mGEU5k37NVUvx6LmxXdLorq4sBTZqQC8hCgeIAbPux+Ntskdd3MvDWYFc5
         IYIW28EBcg2sk/zRabvKApSvs9jBmrOShFLkWJ9ed67O0ydqmmxggPaQj9nzdW7xABMP
         x/+48KuE9MrzHAzpwGCEu8HWtsf93gnSWKcnuombgDGlUsST1JzUSa0lrBi408m69Jij
         c1HmN/PMAG3hXBH1CdnkT648A3wFct3gmcTrzqy9y6rmP7LnjdJY3W7eAgYccshWL6Ny
         as4w==
X-Gm-Message-State: ACrzQf1R2XseR7Pkm6knNnNjysetDw519Aj43T2T7P2Rlw+JM+VOx1vg
	WI0OgIi0+a4Wkt6L4GQbbx8pSXoqda0=
X-Google-Smtp-Source: AMsMyM6UfDujiaNkihQfk9aV1RnW0B0QzIh6pRsZBjYGQHIjXad/NZ7XrEzEym0pdab6vzzIcMUi1w==
X-Received: by 2002:a05:600c:3483:b0:3b4:99f4:1191 with SMTP id a3-20020a05600c348300b003b499f41191mr8958032wmq.147.1664027249428;
        Sat, 24 Sep 2022 06:47:29 -0700 (PDT)
Received: from localhost (dslb-188-109-244-245.188.109.pools.vodafone-ip.de. [188.109.244.245])
        by smtp.gmail.com with ESMTPSA id f12-20020a05600c4e8c00b003b33943ce5esm6121117wmq.32.2022.09.24.06.47.28
        for 
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 24 Sep 2022 06:47:28 -0700 (PDT)
Date: Sat, 24 Sep 2022 15:47:27 +0200
From: Daniel Tameling 
To: freebsd-current@freebsd.org
Subject: Re: Good practices with bectl
Message-ID: 
References: 
 
 
 
 <20220921112706.Horde.eNaqpvIqq64Qe7crIQQ9JwX@webmail.leidinger.net>
 
 <20220921124452.Horde.BSQPZ4imQhhKUUE0k3W5iFb@webmail.leidinger.net>
 
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
In-Reply-To: 
X-Rspamd-Queue-Id: 4MZVh337kzz44m0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Gb6VtR7h;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of tamelingdaniel@gmail.com designates 2a00:1450:4864:20::329 as permitted sender) smtp.mailfrom=tamelingdaniel@gmail.com
X-Spamd-Result: default: False [-3.87 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.95)[-0.946];
	NEURAL_HAM_LONG(-0.93)[-0.926];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::329:from];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Sep 21, 2022 at 12:08:38PM +0100, Nuno Teixeira wrote:
> Summary: Using bectl for upgrades
> 
> RELEASE=Whatever
> > bectl create ${RELEASE}
> > bectl mount ${RELEASE}
> BASEDIR=/tmp/be_mount.XXXX # Use mount point returned by bectl mount
> 
> [freebsd-update method]
> > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update \
> upgrade -r ${RELEASE}
> > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
> # Ignore admonitions to reboot, since we're using a boot environment
> > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update install
> > bectl activate ${RELEASE}
> #> bectl activate -t ${RELEASE} # Failsafe (if the machine is too far away
> to simply walk over and
> switch to the old BE):
> > reboot
> 
> [upgrade from source method]
> > make DESTDIR=${BASEDIR} installkernel
> > etcupdate -p -D $BASEDIR
> > make DESTDIR=${BASEDIR} installworld
> > etcupdate -D $BASEDIR
> > make DESTDIR=${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old
> delete-old-libs
> > bectl activate ${RELEASE}
> #> bectl activate -t ${RELEASE} # Failsafe (if the machine is too far away
> to simply walk over and
> switch to the old BE):
> > reboot
> 

Would it be possible to add this to the handbook? I know that I will be looking for it when I upgrade next time.

Best regards,
Daniel

From nobody Sat Sep 24 17:08:54 2022
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 4MZb8g1dtHz4d5xH
	for ; Sat, 24 Sep 2022 17:09:07 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MZb8g19c7z3NgK
	for ; Sat, 24 Sep 2022 17:09:07 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664039347;
	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=+OiLkNfvbxepCcTlB8/ajGtf1AGDrouwbAFVbORfDaQ=;
	b=B/5NiC+EMtPsmvcf5DflZMU0joM1FYL4UMvYqfhBLBRAsAf+a/Api3LzsDCc+blBX9CFQ5
	mhOlXxzWejEgSpo5gpYR50WbOH10NO7R9f71Pn8UppOvLA9bfWWMGyeOk2ICd3eoVAPCBC
	S9hfqRF+GG9pNDXNMZv7y57B0KpL6/nkJMJZEuvNOTaikV6U2XTKAXvXt16AzzWbM1Qr6f
	7q+W5QkuwsKBZ795d834yYiGr8OHj0DM9qj+1GCucYay8BlVUEGwhxWdm4oTdfxF+9UF/i
	K8I3qdDep8o0Uafl5fTzrd7+FAmVkBtNQ7uRYakwWEWKJmgD6I7BdSAnI+nDPQ==
Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MZb8f753yzXL4
	for ; Sat, 24 Sep 2022 17:09:06 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f42.google.com with SMTP id 63so2846621vse.2
        for ; Sat, 24 Sep 2022 10:09:06 -0700 (PDT)
X-Gm-Message-State: ACrzQf0pgxsbS4eqUiYzOPDPOO4vJAa6w6CAbXQyH+0MX20KLcTDkmF0
	bL9z/tLBcSZLuBLhT+ss4522ZFHpEQ4QNYsruMU=
X-Google-Smtp-Source: AMsMyM7UWRS/HYBVq2Lix+nLh2cNgohkpSVuWNvpeL+WsWoHD1Mhd4xRd3nY+j5HfciFgXBr4357Id0g7Ku5n8DSxo4=
X-Received: by 2002:a67:d793:0:b0:398:506b:747b with SMTP id
 q19-20020a67d793000000b00398506b747bmr5501042vsj.19.1664039346191; Sat, 24
 Sep 2022 10:09:06 -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: 
 
 
 
 <20220921112706.Horde.eNaqpvIqq64Qe7crIQQ9JwX@webmail.leidinger.net>
  <20220921124452.Horde.BSQPZ4imQhhKUUE0k3W5iFb@webmail.leidinger.net>
  
In-Reply-To: 
From: Nuno Teixeira 
Date: Sat, 24 Sep 2022 18:08:54 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Good practices with bectl
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000001f454805e96f5ad7"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664039347;
	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=+OiLkNfvbxepCcTlB8/ajGtf1AGDrouwbAFVbORfDaQ=;
	b=ssNWag6vKeDUOF20lIU4syd22cbff79+XUlwJb8Hf1Elhv3SgRIU2XCdb94my9GqNWnoSk
	IxSgwzXtkXN5fjbKHhWfWAeyKrKJOFjdCH7eNaHV31Bj9ajATeDx807MRN9gmtvGso8Im/
	zE8WHOJqcFCYsjK93saEko0HH7PzJFO5Xe86wW7AUm5d5xqUfYljjXVGbZ51v/Z7/NYE0z
	UsQpGOJIrfJFVseFhlEcHSssQqiMv8Q2v/N9vEp4cnMpqqAWe8r/LFxR3VvkJT+41hPhyh
	QsrZAW7rg0m9TwbcIqEfrstbpMk5tHHh9geWPKjHzHqv94WlmyjkK+VgW1j8zA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664039347; a=rsa-sha256; cv=none;
	b=VBj/InKRRdNHMfKxm+6nKNo3lDsI+1vTqEehSY6hRl2Q4VeAGoFGbCMm7GgQhd3MnuSNXw
	0hk22P/ImErXymR6IeVLnblkeYwW4vm3+YGMg8/AYrHtNBRC8Ks6/zZiUtc8Hlz6OaOQu8
	mpZbfpnZyuT6DiHQPT+0zVGo0UQegVmTGNc0nVCqup7DmrI9LyZx8FtvM5jLUiYAt2rg5W
	/6SS6vPcJYmvIMjYxvBmetFagSTipFajbqQSRfrALrjTMlau15DO7Tjgraem9WVlZ6JGje
	4yEY8ehD9cQ8M2yBJNKugjm/e9YpMW8i8jZp6da5+JVMJ62bYWyR+81LnrGSKg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000001f454805e96f5ad7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

And src/tools/build/beinstall.sh too!

beinstall.sh is just great:
`bectl list`:
---
 BE                           Active Mountpoint Space Created
 14.0-CURRENT-20220924.142841 NR     /          110G  2022-09-24 17:48
 default                      -      -          2.41G 2021-07-06 11:03
---

Cheers

Daniel Tameling  escreveu no dia s=C3=A1bado,
24/09/2022 =C3=A0(s) 14:47:

> On Wed, Sep 21, 2022 at 12:08:38PM +0100, Nuno Teixeira wrote:
> > Summary: Using bectl for upgrades
> >
> > RELEASE=3DWhatever
> > > bectl create ${RELEASE}
> > > bectl mount ${RELEASE}
> > BASEDIR=3D/tmp/be_mount.XXXX # Use mount point returned by bectl mount
> >
> > [freebsd-update method]
> > > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update \
> > upgrade -r ${RELEASE}
> > > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update
> install
> > # Ignore admonitions to reboot, since we're using a boot environment
> > > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update
> install
> > > bectl activate ${RELEASE}
> > #> bectl activate -t ${RELEASE} # Failsafe (if the machine is too far
> away
> > to simply walk over and
> > switch to the old BE):
> > > reboot
> >
> > [upgrade from source method]
> > > make DESTDIR=3D${BASEDIR} installkernel
> > > etcupdate -p -D $BASEDIR
> > > make DESTDIR=3D${BASEDIR} installworld
> > > etcupdate -D $BASEDIR
> > > make DESTDIR=3D${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old
> > delete-old-libs
> > > bectl activate ${RELEASE}
> > #> bectl activate -t ${RELEASE} # Failsafe (if the machine is too far
> away
> > to simply walk over and
> > switch to the old BE):
> > > reboot
> >
>
> Would it be possible to add this to the handbook? I know that I will be
> looking for it when I upgrade next time.
>
> Best regards,
> Daniel
>
>

--=20
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000001f454805e96f5ad7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


And src/tools/build/beinstall.sh too!

<=
/div>
beinstall.sh is just great:
`bectl list`:
---=

=C2=A0BE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Active Mountpoint Space Created=C2=A014.0-CURRENT-20220924.142841 NR =C2=A0 =C2=A0 / =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0110G =C2=A02022-09-24 17:48
=C2=A0default =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- =C2=A0 =C2=
=A0 =C2=A0- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.41G 2021-07-06 11:03
<=
div>---

Cheers

Daniel Tameling <tamelingdaniel@gmail.com> escr=
eveu no dia s=C3=A1bado, 24/09/2022 =C3=A0(s) 14:47:
On Wed, Sep 21, 2022 at 12:08:38PM +01=
00, Nuno Teixeira wrote:

> Summary: Using bectl for upgrades

> 

> RELEASE=3DWhatever

> > bectl create ${RELEASE}

> > bectl mount ${RELEASE}

> BASEDIR=3D/tmp/be_mount.XXXX # Use mount point returned by bectl mount=


> 

> [freebsd-update method]

> > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update =
\

> upgrade -r ${RELEASE}

> > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update =
install

> # Ignore admonitions to reboot, since we're using a boot environme=
nt

> > freebsd-update -b ${BASEDIR} -d ${BASEDIR}/var/db/freebsd-update =
install

> > bectl activate ${RELEASE}

> #> bectl activate -t ${RELEASE} # Failsafe (if the machine is too f=
ar away

> to simply walk over and

> switch to the old BE):

> > reboot

> 

> [upgrade from source method]

> > make DESTDIR=3D${BASEDIR} installkernel

> > etcupdate -p -D $BASEDIR

> > make DESTDIR=3D${BASEDIR} installworld

> > etcupdate -D $BASEDIR

> > make DESTDIR=3D${BASEDIR} -DBATCH_DELETE_OLD_FILES delete-old

> delete-old-libs

> > bectl activate ${RELEASE}

> #> bectl activate -t ${RELEASE} # Failsafe (if the machine is too f=
ar away

> to simply walk over and

> switch to the old BE):

> > reboot

> 



Would it be possible to add this to the handbook? I know that I will be loo=
king for it when I upgrade next time.



Best regards,

Daniel






-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--0000000000001f454805e96f5ad7--

From nobody Sat Sep 24 17:49:59 2022
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 4MZc3v68H1z4d9wg
	for ; Sat, 24 Sep 2022 17:50:03 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MZc3v5MRHz3R5w
	for ; Sat, 24 Sep 2022 17:50:03 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664041803;
	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=0ciiWSvalIGR8RbSpJNgL6Tb1EiAj9jKLEl0Sqkhh9k=;
	b=wZmP757kRCAzCbL49mxnDYix3gpCihU5U1iSiWY/EuFBprrIMFjTIhIXzuBRe/E8O2Vcob
	476EiN+YRvyWRDYoFt1SxJh/j9n26MPhsi0dy2aIkj4nOZc3te1X1X1vpERHzTW2+/mZFu
	cwi24Zsv1ZMPb9t1aLlWz044CX+7fQHZRiEH7Oq+Z5e3WgqFddGAbI8BWkvgpFyyMBv0bA
	UzYEz5vl/AYDtWju9UvC1cJrXPWAvEaBpXJifi6AloGvY2lH1ACi3kxLjdEw19V7+6u++x
	FoROYDTNdznp/jAQxfPqJhC461Et88oAfI+FTz46ROA28OpQdkl+dtLc+77Mzw==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MZc3v36CszXTc
	for ; Sat, 24 Sep 2022 17:50:03 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: 
Date: Sat, 24 Sep 2022 18:49:59 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: Good practices with bectl
To: freebsd-current@freebsd.org
References: 
 
 
 
 <20220921112706.Horde.eNaqpvIqq64Qe7crIQQ9JwX@webmail.leidinger.net>
 
 <20220921124452.Horde.BSQPZ4imQhhKUUE0k3W5iFb@webmail.leidinger.net>
 
 
Content-Language: en-GB
From: Graham Perrin 
Organization: FreeBSD
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------jux1ZdeHRByrgxTDmrqyY9uT"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664041803;
	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=0ciiWSvalIGR8RbSpJNgL6Tb1EiAj9jKLEl0Sqkhh9k=;
	b=H5ZfqokVkfSjP39474nFhPwIFH8SyVmZ6xlxducOlIVkp1yii+CL0c/fRKPUDmdgQIq00o
	HFwFA2w7yas6YBHvHOAfEKmSyle8T/UJnT/41uC1H1mQX2Gd6ZuiQDKtgIeLJaSkIxCen2
	535s2O1SU+mK7q/7d9CYLfvePZEr06Pcl2GszndHXzZd/rHjE53EvK/PFA8br8URNtZRrw
	p03NQECUBTMlvDcGSI82inj84lgHxW6DGUgJ8M1EfKZOm/zOnU9SHY+HvCGjjnWG6+nBmD
	Xkgfjko/E+Nlo1xbupSUk6xhmcLM4Uj657RCNB8XBvWfCLGd2V7+OySFYt/Erg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664041803; a=rsa-sha256; cv=none;
	b=ab9F1UoqTcMo8qLdnj8ARJ1yv1Miy5zqeXnoOOElR+8NxdnjRRlLIEfd2N8HPc0X+9EVNG
	L+rRM116XkzoJSYlxWrANXGHZnX0KSkbvDHFSYckOvxva2JINKv0fbMXI/GQusGVULhiGZ
	auV9T6mQiLyjsOOVYfoRTWSq1r4KQ2NuqFYie21YeUUA2h4m82PtcygTixIqZlp5r9Zsmf
	nFiV9rv6R48IX9ZAXEMAowEhCM7TBqrgnQjsAYFGJqVDi5SK5uYavXN5KAzeR+fY1yG+zy
	cf1/ZzuQlORLRaxyk0Cj6Ig9gceJxCViLFKcU7PfymtrlVr0qqe1yMcFVwtjVw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------jux1ZdeHRByrgxTDmrqyY9uT
Content-Type: multipart/mixed; boundary="------------wpkshDi30tSYyN3ZiDR07mRB";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: 
Subject: Re: Good practices with bectl
References: 
 
 
 
 <20220921112706.Horde.eNaqpvIqq64Qe7crIQQ9JwX@webmail.leidinger.net>
 
 <20220921124452.Horde.BSQPZ4imQhhKUUE0k3W5iFb@webmail.leidinger.net>
 
 
In-Reply-To: 

--------------wpkshDi30tSYyN3ZiDR07mRB
Content-Type: multipart/alternative;
 boundary="------------pPXXa4A0s5CrWtBCQKF5NOOp"

--------------pPXXa4A0s5CrWtBCQKF5NOOp
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjQvMDkvMjAyMiAxNDo0NywgRGFuaWVsIFRhbWVsaW5nIHdyb3RlOg0KPiDigKYgV291
bGQgaXQgYmUgcG9zc2libGUgdG8gYWRkIHRoaXMgdG8gdGhlIGhhbmRib29rPyDigKYNCg0K
RnJlZUJTRCBidWcgMjYzMzMxIOKAkyBFeHBsYWluIHVzZSBvZiBiZWN0bCAoaWYgdXNpbmcg
WkZTKSBpbiB0aGUgdXBkYXRpbmcgDQpGcmVlQlNEIHNlY3Rpb24gb2YgdGhlIEZyZWVCU0Qg
SGFuZGJvb2sNCjxodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvc2hvd19idWcu
Y2dpP2lkPTI2MzMzMT4NCg0K
--------------pPXXa4A0s5CrWtBCQKF5NOOp
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 24/09/2022 14:47, Daniel Tameling
      wrote:

    

    

      
=E2=80=A6 Would it be possib=
le to add this to the handbook? =E2=80=A6

    

    
FreeBSD bug 263331 =E2=80=93 Explain use of bectl (if using ZFS) i=
n the
      updating FreeBSD section of the FreeBSD Handbook

      <https://bugs.freebsd.org/bugzilla=
/show_bug.cgi?id=3D263331>

    

  
  


--------------pPXXa4A0s5CrWtBCQKF5NOOp--

--------------wpkshDi30tSYyN3ZiDR07mRB--

--------------jux1ZdeHRByrgxTDmrqyY9uT
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmMvQ0cFAwAAAAAACgkQt2dIb0oY1AuS
4g/9FPsqJohq+BSbuT2f/fM4zSEYjEYn+gLEf3Xkg193DjjkNfXeIP3j4PhE4FB2L7cU+zdyLr0+
g7kGpjzCR0/sTT7ZbotxrDCEs1Tyyn3xQQWRhMTzWXe/sjzBCd6AaDYjPvSHUI7iMm5OAVPEGZ13
Ft25zF11xUoA/FwTHCQoTWWHhlZzcz0hShXqy99wjzGdWpkBInt2FCZFfTeLEOdo/U+/FnOTgCFu
GbFDQP0EVt0NkNsQZuPXH93DLkcSvM1G0OqA3cx1CYWnL0n4VS5WzD4GFPMNMFJwV1zqVlWXiJLX
4HhRrB5dWXSj+0gKnoC1XhYcs5yxBlgll2C/yuRr2X2TXO0idQjGugbq/GGF0VTx4ORJQa1Q37o5
rQHq6Hw/yU5mVUCmG7jWJeiK1CR/DtrVqcNpWgWoIhs4hRq1UFSQHEw2LH4MSfKiMEhFmDvt1m0w
eKh7GBdoy67rBscLtrpl2fBJOy5rmgxE3bUnPgqlJ47qjcJHRt7rkpoT+QRaAfMzsYHTlxoV0H7q
XKI/rWgNUaBHdDBqVJfOjJPYIvp2h8/PxBr4JeQJZt7RKFBqEMJ/XjeOdJky7qBvciM9NxlI1oHJ
FYHr9U1eH79G1tIDef8GR7kwGbEwFDVy4EpadDx1sLUqgi56CDRzzkKvYQ9EY2MxIqKn+B8k9LwU
yOI=
=TAv4
-----END PGP SIGNATURE-----

--------------jux1ZdeHRByrgxTDmrqyY9uT--

From nobody Sat Sep 24 17:52:39 2022
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 4MZc6x5xRCz4dBMH
	for ; Sat, 24 Sep 2022 17:52:41 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MZc6x5FkPz3SX7
	for ; Sat, 24 Sep 2022 17:52:41 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664041961;
	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=JHL4qzSf9nQPxd0LujFK11ZJHfy8W0OP0bHwH5gxuos=;
	b=omLxEysS+FOZ2lE2CsypHYOi9y2L2d1ozMKAeLkC44wOhEd7pMjUB8rVKoM68Rn24uaEr8
	g6bTtEzdeWgn5VK7NbqiRWKFmc+zRZEFv6Yeaa9fKIsFWilFtMRxApx4huw9zHyBYZSq9Q
	6B7L8PmRCVNfvouvS2WPUWpVunjZGFKzi6CWh8hxCrQTH6rOoKJb4KOywBFA2kA0Ii4/vL
	dgb/ZD6Hs8YvKlrlKss7WQ/b3j/AmWT16gTtj4rzkXsbhDh1rJ7NSep4wyXb6qfiCCBSm3
	tqsQZVZlyPImgdjoUfMWvVqG/fiaX4UvLcY784Bve8u0RAICiiwxGpca/YdLvw==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MZc6x38kSzXLk
	for ; Sat, 24 Sep 2022 17:52:41 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: 
Date: Sat, 24 Sep 2022 18:52:39 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: Good practices with bectl
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: 
 
 
 
 <20220921112706.Horde.eNaqpvIqq64Qe7crIQQ9JwX@webmail.leidinger.net>
 
 <20220921124452.Horde.BSQPZ4imQhhKUUE0k3W5iFb@webmail.leidinger.net>
 
 
 
From: Graham Perrin 
Organization: FreeBSD
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------5PJR0brE8R6xvnaN35ZTYaky"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664041961;
	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=JHL4qzSf9nQPxd0LujFK11ZJHfy8W0OP0bHwH5gxuos=;
	b=bBGGBK4yNXZjsAr1yvL/tQRi213BsJv0PwpCDcJ3UaartiXj4QjpGNtAnjeEIF/plJpAfA
	dNfp+7QacSUyAbBIF9CZ343Wn6YSSWWVTuLipKkYaB/KVjC8hUPb9qVn3z9MGDmgmyVdI+
	pOswWoK2TTn+lSwqS+8A7M90v5RybTnzELyDZkPWxODdIcos7v4fngjYlQZwzBbXwLlsn8
	kKa1CfwiHvs+Qqj7nPh7sFTf+gxO6ykCfdvMx6JCEUPKkG7S/ZfDPqxiZLmKjzXCg0qqp7
	1dGHo14Els7wHBy7/rikp0hAuZMB6lUZXnbSe1A7pGKVTPBuHW3vLV/fNS31zA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664041961; a=rsa-sha256; cv=none;
	b=oGGV2lBZRbLY9py7fLjQGrdKZecMv66xQAw7jQNBPi7Pi3aXUjVrNASmNYdMLIyI82XQmK
	uslHQJllR/A18Bxmwc7/SzHixKPcodDbafHtkC7tXHCMzz17gFE16WhB7ok2CRI+C4BITL
	LDLqxBQzC/7dCTRPUFng1wBr/ZutRE0SNJnPI8gk8a/6ewp6Y/W9x4PLuIBsNJKxx6EQAc
	hT4VztejdmrAh0F0RPBwDn5eCJWrcxTzYay2twRWMj00dpOiEVumThWKK5oYIzHqA3teHm
	C09T3UC/D7YRJ9RGtiq2BMwRw0WcRtetwlOh7bTGv2yZiHQprd4rVOnZ6ti85g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------5PJR0brE8R6xvnaN35ZTYaky
Content-Type: multipart/mixed; boundary="------------v002o0GV0nd4buBluc60nBP3";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: 
Subject: Re: Good practices with bectl
References: 
 
 
 
 <20220921112706.Horde.eNaqpvIqq64Qe7crIQQ9JwX@webmail.leidinger.net>
 
 <20220921124452.Horde.BSQPZ4imQhhKUUE0k3W5iFb@webmail.leidinger.net>
 
 
 
In-Reply-To: 

--------------v002o0GV0nd4buBluc60nBP3
Content-Type: multipart/alternative;
 boundary="------------fdwWZm0J0wgSjefFyaG0oFbI"

--------------fdwWZm0J0wgSjefFyaG0oFbI
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjQvMDkvMjAyMiAxODowOCwgTnVubyBUZWl4ZWlyYSB3cm90ZToNCg0KPiBBbmQgc3Jj
L3Rvb2xzL2J1aWxkL2JlaW5zdGFsbC5zaCB0b28hDQo+DQo+IOKApg0KDQo8aHR0cHM6Ly9s
aXN0cy5mcmVlYnNkLm9yZy9hcmNoaXZlcy9mcmVlYnNkLWN1cnJlbnQvMjAyMi1TZXB0ZW1i
ZXIvMDAyNjA3Lmh0bWw+DQoNCg==
--------------fdwWZm0J0wgSjefFyaG0oFbI
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 24/09/2022 18:08, Nuno Teixeira wrote:

    

    

      
And src/tools/build/beinstall.sh too!

        

        =E2=80=A6

      

    

    
<https://lists=
=2Efreebsd.org/archives/freebsd-current/2022-September/002607.html>

    

  
  


--------------fdwWZm0J0wgSjefFyaG0oFbI--

--------------v002o0GV0nd4buBluc60nBP3--

--------------5PJR0brE8R6xvnaN35ZTYaky
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmMvQ+cFAwAAAAAACgkQt2dIb0oY1AvU
aQ//Zol87gDynoHuHDUKweocnvibcCBksp4HcZ+x26h1ACbOxPnU0a0Fj8vujp31W+CIhrXFQtPd
ujAi2j5J+gO794WI8ulq0h+X1oNvZ/CnaTPgRtchqp7w0ptYaO2puLhaD6B+H30ysiyvv7eUt85e
KRY47BA7FCe6daWGVgDWWbGTm2CQM0JFYbhPLEJVrKQGBFjAW7yZloS2fQIgtyOCrFEOkNeMEHro
lvvXQKzvcGCvUgSOQSLGRyv/JcoOvG1B8NbKzBS104HMWHlCoE1Enr7pC1SYdhHcoeA7/vE7s2zM
ch6QBoIG/fB/voXEiy7TUmKcexy1YiZRiP9HT+3diFcBjn07xf8lgOU6Dx1ZC5r0jOve9IeAI6fI
mWSbzcssLD56A8IPCQsporpE8l3azGEztQY2q2gjK+e3UU3ESMGR8/W+9dAEomdK+hkyF6VUhQsn
QaW9tJHDEb+9oi+FkAOvYqLfvLkDboHK/hk+G0TYZs3Wg4QUEdBWetKyj5UO2KaBg6TTYjVXNy1q
ZlSv6wdelIYo22IEW2vIHvQEnWuHMlARDgkn3R2aCn5/KCVT2w4ZkaiKvi68tVEnDneX5m7RHhI4
E4Q2Wtv+dXxZ0eFAOM1AfMwqmYM+X2mXaAhKhRwV3D2Q2CUuGtGevajrUaiwh48nFWRd5TmMgJbL
7R4=
=umGp
-----END PGP SIGNATURE-----

--------------5PJR0brE8R6xvnaN35ZTYaky--

From nobody Sun Sep 25 17:12:31 2022
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 4MbCFG2mgSz4cSwg
	for ; Sun, 25 Sep 2022 17:15:14 +0000 (UTC)
	(envelope-from naddy@mips.inka.de)
Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MbCFD6nz3z3CDT
	for ; Sun, 25 Sep 2022 17:15:12 +0000 (UTC)
	(envelope-from naddy@mips.inka.de)
Received: from mips.inka.de (naddy@[127.0.0.1])
	by mail.inka.de with uucp (rmailwrap 0.5) 
	id 1ocVDc-003RmG-EJ; Sun, 25 Sep 2022 19:15:04 +0200
Received: from lorvorc.mips.inka.de (localhost [127.0.0.1])
	by lorvorc.mips.inka.de (8.16.1/8.16.1) with ESMTP id 28PHCVEg025916
	for ; Sun, 25 Sep 2022 19:12:31 +0200 (CEST)
	(envelope-from naddy@lorvorc.mips.inka.de)
Received: (from naddy@localhost)
	by lorvorc.mips.inka.de (8.16.1/8.16.1/Submit) id 28PHCVMb025915
	for freebsd-current@freebsd.org; Sun, 25 Sep 2022 19:12:31 +0200 (CEST)
	(envelope-from naddy)
Date: Sun, 25 Sep 2022 19:12:31 +0200
From: Christian Weisgerber 
To: freebsd-current@freebsd.org
Subject: Did clang 14 lose some intrinsics support?
Message-ID: 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Rspamd-Queue-Id: 4MbCFD6nz3z3CDT
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of naddy@mips.inka.de has no SPF policy when checking 2a04:c9c7:0:1073:217:a4ff:fe3b:e77c) smtp.mailfrom=naddy@mips.inka.de
X-Spamd-Result: default: False [-1.09 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.990];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	DMARC_NA(0.00)[inka.de];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	RCPT_COUNT_ONE(0.00)[1];
	FREEFALL_USER(0.00)[naddy];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:202113, ipnet:2a04:c9c0::/29, country:DE];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Did we lose support for SSSE3 and AVX2 intrinsics on amd64 with
clang 14?

I don't have access to an up-to-date -CURRENT box.  Can somebody
run the script at the end and report the output?  Those checks are
found in the wild, I extracted them from the audio/flac port.

So far, what I'm seeing:

===> clang version 13.0.0
#define AVX2_SUPPORTED 1
#define AVX_SUPPORTED 1
#define FMA_SUPPORTED 1
#define SSE2_SUPPORTED 1
#define SSE4_1_SUPPORTED 1
#define SSE_SUPPORTED 1
#define SSSE3_SUPPORTED 1

===> clang version 14.0.5
#define AVX_SUPPORTED 1
#define FMA_SUPPORTED 1
#define SSE2_SUPPORTED 1
#define SSE4_1_SUPPORTED 1
#define SSE_SUPPORTED 1

------------------->
#!/bin/sh
(cc -E -dM - | fgrep SUPPORTED) <; Sun, 25 Sep 2022 19:02:31 +0000 (UTC)
	(envelope-from jbeich@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MbFd31vcSz3LVZ;
	Sun, 25 Sep 2022 19:02:31 +0000 (UTC)
	(envelope-from jbeich@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664132551;
	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=aWNJSFOSeauX9YwdfhBcRoDms4bkaDoD+yPPBFknfUw=;
	b=OgD4Lje9LYHHjyLz8fVX9ATNg5eq7hFjXsM7LyzsCyoL2uKqcXwwQhY/mblzBD7k2LXNk8
	gt1eb8t5VXA+dVAFSBDq3g3V2jvJqUIoH8tlVbphH0K6C91x14i+IohyLvfscrlG1t127F
	H/i8DDeESd4tt6rj5dnTQlbWtGXAPIBNEFL6y8fySJtSxjBJENciIz5ktf6sc6BjvNuV7f
	DCO5gcwQLgw97XeS+dOpag9hyAsjx9sGle9XaDN9K+gc7lQN3u7aqp1awAwMICNjrzlhU9
	sGRUMhEkZZR70bt1J84UrZaTm3gEVkKmaA0B9rTNM/bP1BIMWmD2V+RjWKmyRg==
Received: by freefall.freebsd.org (Postfix, from userid 1354)
	id 27D9C8E0E; Sun, 25 Sep 2022 19:02:31 +0000 (UTC)
From: Jan Beich 
To: Christian Weisgerber 
Cc: freebsd-current@freebsd.org
Subject: Re: Did clang 14 lose some intrinsics support?
In-Reply-To:  (Christian Weisgerber's
	message of "Sun, 25 Sep 2022 19:12:31 +0200")
References: 
Date: Sun, 25 Sep 2022 21:02:08 +0200
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
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664132551;
	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=aWNJSFOSeauX9YwdfhBcRoDms4bkaDoD+yPPBFknfUw=;
	b=c3rZDH8GV1DUdRWM1X6TMlhCJ5OMM7xagzSIkM82PtOkUT1A9LIyGYKiG3qXdDfsO3OBTC
	VlW1vwhOjM6WycO0WBnAF89A2XYKGvrJeGl2MBFDvBQNAIlv6ej5NLemRooqA+9NBlzm0j
	ATaKqgt/vspdKv+rWhrPBwhSAEOaweJfxv+JuXwpRiW+kKNmsnE03IxuE7r/f6xIi1LH5B
	326ELQk2adkVdgIFnFNX3+hIGVLhh4FVJlP9OO1uSiEaKZlTYQDKkVJlk415F11W8107v0
	HiAeThE66ZepeUK/9SeB1+WHYEkHo4Ehd46pAeGmoTTEmFsH00MzK5P6cSpVrQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664132551; a=rsa-sha256; cv=none;
	b=U9HWYz1fhIc87nvo07mCN/G5JwZOq9KYewIq01hz2YmdYI1gCL7vAKIvGXzKHbARS3WX/x
	5xYaBWokIiFF5f/xbI8h+07kOH6Gl7MLF346d/x+BJ1KCuq8Ew9ofgEYBG1xA685COq7T1
	VbeKc7gNAkv2ItJPrb4Xfzqo9h9wpWQWrJh3V2Di39i2UimGbgj+C9K5mCsDiZSgWB2D+i
	p+3hw4/WjLjRvX/UJOBOBQRfpnNRfVlV6w6aZhYdxcvZ6I2H69GJ6fmbiAqFutzz9g29BF
	ykP3cY+9q6u70xneRoYwprpdzYpBhIzzPgqEIVXlj38yyvfs1+zJp8S0ky7csg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

Christian Weisgerber  writes:

> Did we lose support for SSSE3 and AVX2 intrinsics on amd64 with
> clang 14?

__builtin_* appear unstable unlike _mm* intrinsics. Clang 15 seems
to hide more but I'm not sure about the cause (need bisecting).

===> clang version 15.0.1
#define SSE2_SUPPORTED 1
#define SSE_SUPPORTED 1

===> clang version 15.0.1 with -march=native
#define AVX_SUPPORTED 1
#define FMA_SUPPORTED 1
#define SSE2_SUPPORTED 1
#define SSE4_1_SUPPORTED 1
#define SSE_SUPPORTED 1

> #if __has_builtin(__builtin_ia32_pabsd128)
>   #define SSSE3_SUPPORTED 1
> #endif
[...]
> #if __has_builtin(__builtin_ia32_pabsd256)
>   #define AVX2_SUPPORTED 1
> #endif

See https://github.com/llvm/llvm-project/commit/e5147f82e1cb

- Instead of __builtin_ia32_pabsd128 maybe use _mm_abs_epi32
- Instead of __builtin_ia32_pabsd256 maybe use _mm256_abs_epi32

From nobody Sun Sep 25 20:46:47 2022
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 4MbHyB16b3z4cvjJ
	for ; Sun, 25 Sep 2022 20:47:30 +0000 (UTC)
	(envelope-from dim@FreeBSD.org)
Received: from springbank.echomania.com (springbank.echomania.com [149.210.134.147])
	(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 "springbank.echomania.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MbHy82CfHz3XXj;
	Sun, 25 Sep 2022 20:47:28 +0000 (UTC)
	(envelope-from dim@FreeBSD.org)
X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com
Received: from smtpclient.apple (tensor.andric.com [87.251.56.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by springbank.echomania.com (Postfix) with ESMTPSA id 511DB580331;
	Sun, 25 Sep 2022 22:47:19 +0200 (CEST)
Content-Type: multipart/signed;
	boundary="Apple-Mail=_6A6C5323-8673-47D3-90AB-FAAB7E847848";
	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 \(3696.120.41.1.1\))
Subject: Re: Did clang 14 lose some intrinsics support?
From: Dimitry Andric 
In-Reply-To: 
Date: Sun, 25 Sep 2022 22:46:47 +0200
Cc: Christian Weisgerber ,
 freebsd-current@freebsd.org
Message-Id: <1A903FD8-D904-4B91-ABC4-2F704F0E2CF4@FreeBSD.org>
References: 
 
To: Jan Beich 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MbHy82CfHz3XXj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 149.210.134.147 is neither permitted nor denied by domain of dim@FreeBSD.org) smtp.mailfrom=dim@FreeBSD.org
X-Spamd-Result: default: False [-3.70 / 15.00];
	SIGNED_PGP(-2.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:20857, ipnet:149.210.128.0/17, country:NL];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[dim];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	HAS_ATTACHMENT(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_6A6C5323-8673-47D3-90AB-FAAB7E847848
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On 25 Sep 2022, at 21:02, Jan Beich  wrote:
> 
> Christian Weisgerber  writes:
> 
>> Did we lose support for SSSE3 and AVX2 intrinsics on amd64 with
>> clang 14?
> 
> __builtin_* appear unstable unlike _mm* intrinsics. Clang 15 seems
> to hide more but I'm not sure about the cause (need bisecting).

Yeah, these internal names are constantly changing. I don't know the
reason for it, but it's terribly annoying when diagnosing failures with
preprocessed files, as these tend to break when compiled with a much
earlier or later copy of clang.


> ===> clang version 15.0.1
> #define SSE2_SUPPORTED 1
> #define SSE_SUPPORTED 1
> 
> ===> clang version 15.0.1 with -march=native
> #define AVX_SUPPORTED 1
> #define FMA_SUPPORTED 1
> #define SSE2_SUPPORTED 1
> #define SSE4_1_SUPPORTED 1
> #define SSE_SUPPORTED 1
> 
>> #if __has_builtin(__builtin_ia32_pabsd128)
>>  #define SSSE3_SUPPORTED 1
>> #endif
> [...]
>> #if __has_builtin(__builtin_ia32_pabsd256)
>>  #define AVX2_SUPPORTED 1
>> #endif
> 
> See https://github.com/llvm/llvm-project/commit/e5147f82e1cb
> 
> - Instead of __builtin_ia32_pabsd128 maybe use _mm_abs_epi32
> - Instead of __builtin_ia32_pabsd256 maybe use _mm256_abs_epi32
> 

I'm wondering why this rather fragile method is chosen? If you want to
know whether SSE is supported, you check for __SSE__, and similarly
__SSE2__, __AVX__ and a bunch of others. That is also portable to gcc.

-Dimitry


--Apple-Mail=_6A6C5323-8673-47D3-90AB-FAAB7E847848
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

iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYzC+NwAKCRCwXqMKLiCW
o7zLAJ4+KxyghfjJZriIcC2tPbhcZPQ7eACg8KGwhFatN/7MdCi+EC0cliBs9v8=
=XJ7C
-----END PGP SIGNATURE-----

--Apple-Mail=_6A6C5323-8673-47D3-90AB-FAAB7E847848--

From nobody Sun Sep 25 21:38:10 2022
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 4MbK6t1Y4yz4d1yk
	for ; Sun, 25 Sep 2022 21:40:06 +0000 (UTC)
	(envelope-from naddy@mips.inka.de)
Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MbK6s3Bn3z3jZW;
	Sun, 25 Sep 2022 21:40:05 +0000 (UTC)
	(envelope-from naddy@mips.inka.de)
Received: from mips.inka.de (naddy@[127.0.0.1])
	by mail.inka.de with uucp (rmailwrap 0.5) 
	id 1ocZM4-003Vmc-70; Sun, 25 Sep 2022 23:40:04 +0200
Received: from lorvorc.mips.inka.de (localhost [127.0.0.1])
	by lorvorc.mips.inka.de (8.16.1/8.16.1) with ESMTP id 28PLcA9X032553;
	Sun, 25 Sep 2022 23:38:10 +0200 (CEST)
	(envelope-from naddy@lorvorc.mips.inka.de)
Received: (from naddy@localhost)
	by lorvorc.mips.inka.de (8.16.1/8.16.1/Submit) id 28PLcA0A032552;
	Sun, 25 Sep 2022 23:38:10 +0200 (CEST)
	(envelope-from naddy)
Date: Sun, 25 Sep 2022 23:38:10 +0200
From: Christian Weisgerber 
To: Dimitry Andric 
Cc: Jan Beich , Christian Weisgerber ,
        freebsd-current@freebsd.org
Subject: Re: Did clang 14 lose some intrinsics support?
Message-ID: 
References: 
 
 <1A903FD8-D904-4B91-ABC4-2F704F0E2CF4@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: <1A903FD8-D904-4B91-ABC4-2F704F0E2CF4@FreeBSD.org>
X-Rspamd-Queue-Id: 4MbK6s3Bn3z3jZW
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of naddy@mips.inka.de has no SPF policy when checking 2a04:c9c7:0:1073:217:a4ff:fe3b:e77c) smtp.mailfrom=naddy@mips.inka.de
X-Spamd-Result: default: False [-1.09 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	NEURAL_HAM_LONG(-0.99)[-0.992];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	ASN(0.00)[asn:202113, ipnet:2a04:c9c0::/29, country:DE];
	FREEFALL_USER(0.00)[naddy];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[inka.de];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Dimitry Andric:

> > See https://github.com/llvm/llvm-project/commit/e5147f82e1cb
> > 
> > - Instead of __builtin_ia32_pabsd128 maybe use _mm_abs_epi32
> > - Instead of __builtin_ia32_pabsd256 maybe use _mm256_abs_epi32
> 
> I'm wondering why this rather fragile method is chosen? If you want to
> know whether SSE is supported, you check for __SSE__, and similarly
> __SSE2__, __AVX__ and a bunch of others. That is also portable to gcc.

__AVX__, for instance, is not defined unless you compile with -mavx,
which also allows the compiler to issue AVX instructions during
normal code generation.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

From nobody Mon Sep 26 02:30:07 2022
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 4MbRZs2pqyz4cbBl;
	Mon, 26 Sep 2022 02:31:17 +0000 (UTC)
	(envelope-from rizzo@i805.com.br)
Received: from server.i805.com.br (mailhost.i805.com.br [50.7.13.2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "freebsd12.vm", Issuer "freebsd12.vm" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MbRZr06mGz45h5;
	Mon, 26 Sep 2022 02:31:15 +0000 (UTC)
	(envelope-from rizzo@i805.com.br)
Received: from server.i805.com.br (localhost [127.0.0.1])
	by server.i805.com.br (8.16.1/8.16.1) with ESMTPS id 28Q2U79j096101
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 25 Sep 2022 23:30:08 -0300 (-03)
	(envelope-from rizzo@server.i805.com.br)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=i805.com.br;
	s=myselector; t=1664159408;
	bh=bp85XCqzUiWac4b86J1po93rej/w6pWGSVxgppH5ezI=;
	h=From:Subject:To:Date;
	b=hqTqNXVx0GuUItWdOuZ9LLK/qc65fsHe0VkvyMKU00BsChWuMGpoEaNNclonLgZjP
	 H4xeXlSrM6WpnkSRqjeC3sylvZa5Qik/qgO45EkX8rukL5TDyD6EN+n5Glt7Zi3LMb
	 t4d+s24Zjl9BL3u6i+VWxKN6MCN5XLPUIwaHNcuDx7D8WDcaKiuk4uv5q2ThjBVucn
	 T7PHAqihgeTvOxz/QKz/u1DYyXsOKHw/OmbcEIfSsoEvPP26WKTFH+VbXQkFoPG9fj
	 Axld4a5X2l2UMI1fLs5jfJQnMcTtv6QQN5SPyO63NRMsri1VUFM2FQKndF9dgRLsLI
	 ZWFhVV+YSICEw==
Received: (from root@localhost)
	by server.i805.com.br (8.16.1/8.16.1/Submit) id 28Q2U7KN096100;
	Sun, 25 Sep 2022 23:30:07 -0300 (-03)
	(envelope-from rizzo)
From: Nilton Jose Rizzo 
Message-Id: <202209260230.28Q2U7KN096100@server.i805.com.br>
Subject: Problem with NVIDIA drivers 390 and 470 on current
To: current@freebsd.org, ports@freebsd.org
Date: Sun, 25 Sep 2022 23:30:07 -0300 (-03)
X-Mailer: ELM [version 2.5 PL8]
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED
	autolearn=unavailable autolearn_force=no version=3.4.5
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on server.i805.com.br
X-Rspamd-Queue-Id: 4MbRZr06mGz45h5
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=i805.com.br header.s=myselector header.b=hqTqNXVx;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of rizzo@i805.com.br designates 50.7.13.2 as permitted sender) smtp.mailfrom=rizzo@i805.com.br
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	R_SPF_ALLOW(-0.20)[+ip4:50.7.13.2];
	R_DKIM_ALLOW(-0.20)[i805.com.br:s=myselector];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[current@freebsd.org,ports@freebsd.org];
	DKIM_TRACE(0.00)[i805.com.br:+];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[i805.com.br];
	TO_DN_NONE(0.00)[];
	ASN(0.00)[asn:174, ipnet:50.7.8.0/21, country:US]
X-ThisMailContainsUnwantedMimeParts: N

Hi all,

I'm updated my box to last 14-current today and I get error on ports compialtion.

% uname -a
FreeBSD valfenda 14.0-CURRENT FreeBSD 14.0-CURRENT #17 main-1a2b55732f: Sun Sep 25 21:14:19 -03 2022     rizzo@valfenda:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64   

When I try to install a nvidia driver from ports, I get this error:

cc  -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.151\" -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 -fno-strict-aliasing -mno-red-zone -mcmode
l=kernel -Wno-sign-compare -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -DNV_SPECTRE_V2=1 -DNV_KERNEL_INTERFACE_LAYER -Werror=undef  -Werror -D_KERNEL -DKLD_MODULE -n
ostdinc  -I. -I../common/inc -include /usr/ports/x11/nvidia-driver-390/work/NVIDIA-FreeBSD-x86_64-390.151/src/nvidia/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contri
b/ck/include -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/s
ys/x86/include -fdebug-prefix-map=./i386=/usr/src/sys/i386/include     -MD  -MF.depend.nvlink_freebsd.o -MTnvlink_freebsd.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-ss
e -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -
Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=tautological-compar
e -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -
Wno-format-zero-length   -mno-aes -mno-avx  -std=iso9899:1999 -c nvlink_freebsd.c -o nvlink_freebsd.o
--- nvidia_os.o ---
nvidia_os.c:280:19: error: incompatible integer to pointer conversion passing 'vm_offset_t' (aka 'unsigned long') to parameter of type 'void *' [-Werror,-Wint-conversion]
    pmap_unmapdev((vm_offset_t)address, size);
                  ^~~~~~~~~~~~~~~~~~~~
./machine/pmap.h:511:26: note: passing argument to parameter here
void    pmap_unmapdev(void *, vm_size_t);
                            ^
1 error generated.
*** [nvidia_os.o] Error code 1

make[4]: stopped in /usr/ports/x11/nvidia-driver-390/work/NVIDIA-FreeBSD-x86_64-390.151/src/nvidia
--- nvidia_subr.o ---
nvidia_subr.c:1133:13: error: incompatible pointer to integer conversion assigning to 'vm_offset_t' (aka 'unsigned long') from 'void *' [-Werror,-Wint-conversion]
    address = NV_KMEM_ALLOC_CONTIG(size, flags, 0,
            ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nvidia_subr.c:1182:22: error: incompatible integer to pointer conversion passing 'vm_offset_t' (aka 'unsigned long') to parameter of type 'void *' [-Werror,-Wint-conversi
on]
        NV_KMEM_FREE(at->pte_array[0].virtual_address, at->size);
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nv-freebsd.h:416:15: note: expanded from macro 'NV_KMEM_FREE'
    kmem_free(address, size)
              ^~~~~~~
/usr/src/sys/vm/vm_extern.h:73:22: note: passing argument to parameter 'addr' here
void kmem_free(void *addr, vm_size_t size);
                     ^
nvidia_subr.c:1208:18: error: incompatible integer to pointer conversion passing 'vm_offset_t' (aka 'unsigned long') to parameter of type 'void *' [-Werror,-Wint-conversi
on]
    NV_KMEM_FREE(at->pte_array[0].virtual_address, at->size);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nv-freebsd.h:416:15: note: expanded from macro 'NV_KMEM_FREE'
    kmem_free(address, size)
              ^~~~~~~
/usr/src/sys/vm/vm_extern.h:73:22: note: passing argument to parameter 'addr' here
void kmem_free(void *addr, vm_size_t size);
                     ^
nvidia_subr.c:1271:17: error: incompatible pointer to integer conversion assigning to 'vm_offset_t' (aka 'unsigned long') from 'void *' [-Werror,-Wint-conversion]
        address = NV_KMEM_ALLOC_CONTIG(PAGE_SIZE, flags, 0,
                ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nvidia_subr.c:1325:22: error: incompatible integer to pointer conversion passing 'vm_offset_t' (aka 'unsigned long') to parameter of type 'void *' [-Werror,-Wint-conversi
on]
        NV_KMEM_FREE(at->pte_array[i].virtual_address, PAGE_SIZE);
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nv-freebsd.h:416:15: note: expanded from macro 'NV_KMEM_FREE'
    kmem_free(address, size)
              ^~~~~~~
/usr/src/sys/vm/vm_extern.h:73:22: note: passing argument to parameter 'addr' here
void kmem_free(void *addr, vm_size_t size);
                     ^
nvidia_subr.c:1354:22: error: incompatible integer to pointer conversion passing 'vm_offset_t' (aka 'unsigned long') to parameter of type 'void *' [-Werror,-Wint-conversi
on]
        NV_KMEM_FREE(at->pte_array[i].virtual_address, PAGE_SIZE);
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nv-freebsd.h:416:15: note: expanded from macro 'NV_KMEM_FREE'                                                                                                          
    kmem_free(address, size)
              ^~~~~~~
/usr/src/sys/vm/vm_extern.h:73:22: note: passing argument to parameter 'addr' here
void kmem_free(void *addr, vm_size_t size);
                     ^
6 errors generated.
*** [nvidia_subr.o] Error code 1

make[4]: stopped in /usr/ports/x11/nvidia-driver-390/work/NVIDIA-FreeBSD-x86_64-390.151/src/nvidia
2 errors

make[4]: stopped in /usr/ports/x11/nvidia-driver-390/work/NVIDIA-FreeBSD-x86_64-390.151/src/nvidia

make[3]: stopped in /usr/ports/x11/nvidia-driver-390/work/NVIDIA-FreeBSD-x86_64-390.151/src

make[2]: stopped in /usr/ports/x11/nvidia-driver-390/work/NVIDIA-FreeBSD-x86_64-390.151
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/x11/nvidia-driver-390
*** Error code 1

Stop.
make: stopped in /usr/ports/x11/nvidia-driver-390
#                                                               


TIA

Nilton J. Rizzo

From nobody Mon Sep 26 03:03:34 2022
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 4MbSJ960M8z4cfvN;
	Mon, 26 Sep 2022 03:03:37 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MbSJ84bY8z48st;
	Mon, 26 Sep 2022 03:03:36 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 28Q33Ysj009754;
	Mon, 26 Sep 2022 03:03:34 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 28Q33YuI009753;
	Sun, 25 Sep 2022 20:03:34 -0700 (PDT)
	(envelope-from david)
Date: Sun, 25 Sep 2022 20:03:34 -0700
From: David Wolfskill 
To: Nilton Jose Rizzo 
Cc: current@freebsd.org, ports@freebsd.org
Subject: Re: Problem with NVIDIA drivers 390 and 470 on current
Message-ID: 
Mail-Followup-To: David Wolfskill ,
	Nilton Jose Rizzo , current@freebsd.org,
	ports@freebsd.org
References: <202209260230.28Q2U7KN096100@server.i805.com.br>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Obj66s8tW641BQUH"
Content-Disposition: inline
In-Reply-To: <202209260230.28Q2U7KN096100@server.i805.com.br>
X-Rspamd-Queue-Id: 4MbSJ84bY8z48st
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-5.40 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c];
	MLMMJ_DEST(0.00)[current@freebsd.org,ports@freebsd.org];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[david];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[catwhisker.org];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Obj66s8tW641BQUH
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 25, 2022 at 11:30:07PM -0300, Nilton Jose Rizzo wrote:
> Hi all,
>=20
> I'm updated my box to last 14-current today and I get error on ports comp=
ialtion.
> ....

Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266561

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
In 2022, the governors of Texas and Florida resurrect the racist
ploys of the "White Citizens=E2=80=99 Council" of 1962 -- at taxpayers' exp=
ense.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--Obj66s8tW641BQUH
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYzEWhV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1DWoAP9ZQiCL/6fRsWlvGqlYU+g1m2HjlcT49K/Gkp5aCHX//QD/VTTOqtgWv0vP
OJc3fwmLJe/eBdZAX/JibdORVHC00AY=
=T3HI
-----END PGP SIGNATURE-----

--Obj66s8tW641BQUH--

From nobody Mon Sep 26 10:03:03 2022
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 4MbdcK07Cwz4dbJG
	for ; Mon, 26 Sep 2022 10:03:13 +0000 (UTC)
	(envelope-from dim@FreeBSD.org)
Received: from springbank.echomania.com (springbank.echomania.com [149.210.134.147])
	(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 "springbank.echomania.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MbdcJ0lKcz3YW0;
	Mon, 26 Sep 2022 10:03:12 +0000 (UTC)
	(envelope-from dim@FreeBSD.org)
X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com
Received: from smtpclient.apple (tensor.andric.com [87.251.56.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by springbank.echomania.com (Postfix) with ESMTPSA id 689CB5802D1;
	Mon, 26 Sep 2022 12:03:09 +0200 (CEST)
Content-Type: multipart/signed;
	boundary="Apple-Mail=_8AB4E2B0-A601-47B5-A484-B6BF430ABC73";
	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 \(3696.120.41.1.1\))
Subject: Re: Did clang 14 lose some intrinsics support?
From: Dimitry Andric 
In-Reply-To: 
Date: Mon, 26 Sep 2022 12:03:03 +0200
Cc: Jan Beich ,
 freebsd-current@freebsd.org
Message-Id: <430A830E-3473-4EF4-9605-039F8254999C@FreeBSD.org>
References: 
 
 <1A903FD8-D904-4B91-ABC4-2F704F0E2CF4@FreeBSD.org>
 
To: Christian Weisgerber 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MbdcJ0lKcz3YW0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 149.210.134.147 is neither permitted nor denied by domain of dim@FreeBSD.org) smtp.mailfrom=dim@FreeBSD.org
X-Spamd-Result: default: False [-3.70 / 15.00];
	SIGNED_PGP(-2.00)[];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:20857, ipnet:149.210.128.0/17, country:NL];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[dim];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	HAS_ATTACHMENT(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_8AB4E2B0-A601-47B5-A484-B6BF430ABC73
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On 25 Sep 2022, at 23:38, Christian Weisgerber  wrote:
> 
> Dimitry Andric:
> 
>>> See https://github.com/llvm/llvm-project/commit/e5147f82e1cb
>>> 
>>> - Instead of __builtin_ia32_pabsd128 maybe use _mm_abs_epi32
>>> - Instead of __builtin_ia32_pabsd256 maybe use _mm256_abs_epi32
>> 
>> I'm wondering why this rather fragile method is chosen? If you want to
>> know whether SSE is supported, you check for __SSE__, and similarly
>> __SSE2__, __AVX__ and a bunch of others. That is also portable to gcc.
> 
> __AVX__, for instance, is not defined unless you compile with -mavx,
> which also allows the compiler to issue AVX instructions during
> normal code generation.

Sure, but if you are compiling without -mavx, why would you want the AVX
intrinsics? You cannot use AVX intrinsics anyway, if AVX is not enabled.

So I don't fully understand the problem this configure scripting is
supposed to solve?

In my opinion, if you would want to know whether the compiler supports
AVX in any mode, you would first attempt to run "$CC -mavx" and if that
succeeds, run a test case which checks for the __AVX__ define. If both
succeed, then AVX intrinsics work, otherwise they don't. Rinse and
repeat for any other particular extension you would want to check. And
should work for both clang and gcc.

-Dimitry


--Apple-Mail=_8AB4E2B0-A601-47B5-A484-B6BF430ABC73
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

iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYzF41wAKCRCwXqMKLiCW
o3MJAJ92D3yV4DrEbi0462z69A8A5OdjtwCgjm2hJohnFzfsjYb/SlcYQ/nHIpU=
=mwlY
-----END PGP SIGNATURE-----

--Apple-Mail=_8AB4E2B0-A601-47B5-A484-B6BF430ABC73--

From nobody Mon Sep 26 13:04:20 2022
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 4Mbjdg12B6z4WWYT
	for ; Mon, 26 Sep 2022 13:04:39 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mbjdf0702z3nV3;
	Mon, 26 Sep 2022 13:04:37 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id DA7EA27079;
	Mon, 26 Sep 2022 15:04:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1664197464;
	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=zV2lKDX0L0B4Ouo+C569ePe+KTWD/gjQRRYWZa5T7zU=;
	b=h5P6yV7SbZDVfi/VI+lPj6f6EUjZV8w8aqea8R91Gcg94+r8SrhQ7NBc4v0lnz0kT9DY9U
	otXGGOPHZB9Ep6TjsCavgsQ1cSef6rwOxFIl3n8b2S5vyC60VrwFSL0meuTlU9/mOa4weC
	maYAyjYUUnBvqUjLYwCc74YwwYtygljOgk2W6RPAyg3lib8oT+shoFuoeeemQRtGZhktVp
	MFFNRi0ZGthgVLGMJTSEcHy5gEhxHMU2ELDJeQSmPeHBaORgnQfX4YMixhzvXzZqWcrN3i
	D0EIgXicU/SQJFg6XE01OQETaPW6JTvzXaZ9Pa8YaxwyV3ijoMzoUxFF6YTF1A==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id F11EFB50F;
	Mon, 26 Sep 2022 15:04:20 +0200 (CEST)
Date: Mon, 26 Sep 2022 15:04:20 +0200
Message-ID: <20220926150420.Horde.FuZYvVwObx9ZEQ0mSecOTiA@webmail.leidinger.net>
From: Alexander Leidinger 
To: Dimitry Andric 
Cc: Christian Weisgerber , Jan Beich
 ,
        freebsd-current@freebsd.org
Subject: Re: Did clang 14 lose some intrinsics support?
References: 
 
 <1A903FD8-D904-4B91-ABC4-2F704F0E2CF4@FreeBSD.org>
 
 <430A830E-3473-4EF4-9605-039F8254999C@FreeBSD.org>
In-Reply-To: <430A830E-3473-4EF4-9605-039F8254999C@FreeBSD.org>
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_06V_u4-GPAXmrydi1OosBwC";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4Mbjdf0702z3nV3
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=h5P6yV7S;
	dmarc=pass (policy=quarantine) header.from=leidinger.net;
	spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net
X-Spamd-Result: default: False [-5.10 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[leidinger.net:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE];
	RCPT_COUNT_THREE(0.00)[4];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_06V_u4-GPAXmrydi1OosBwC
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Dimitry Andric  (from Mon, 26 Sep 2022=20=20
12:03:03=20+0200):

> Sure, but if you are compiling without -mavx, why would you want the AVX
> intrinsics? You cannot use AVX intrinsics anyway, if AVX is not enabled.
>
> So I don't fully understand the problem this configure scripting is
> supposed to solve?

Think about run time check of available CPU features and then using=20=20
this=20code for performance critical sections only. Allows to generate=20=
=20
programs=20which are generic to all CPUs in the main code paths, and=20=20
able=20to switch to high performance implementations of critical code=20=20
paths=20depending on the feature of the CPU.

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_06V_u4-GPAXmrydi1OosBwC
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmMxo1MACgkQEg2wmwP4
2Iaxvg/8C9kurtHyy2KIjM9gjkqfYmgZMYBkyNkpuumMiQibY5w6jclYNFVqSfYE
h5nB+SeH//GMhee+C4FtRamE9gAsJE2JYhw5nmMv7TDDzrIvtnuvHZMZDhscs0ey
nn3wIu569ZLecKh1LklD00u7zUBHNvWsB3BobGIxsG2IQV81BSFnL8yJZTBixPmD
2E0y6jO5oKw9c13CVl+Pzgtua/gbKcWDc0a99xxDe/q3VQ0IUN8sLfwJbD+jWeHZ
nA7EmuIs+o0mxOwZF5uiE44ef+1UxRFjuexZ/T2yeVm/Cv+cgigq/clRANRnzhDY
78Tr8VassWhTuJVErIrt6anXrhCUdekXm/AdPOaSfvhgrMUdWThF7e/ppLfPrRb+
y00AlSDYDROEUL4AmRCfytOLGtcDDNpda6B0A/3siZ+uPZH+K6S4BrF6ulHARu5I
LLwhegt0tPnWRrYiRtEoFbqrQqE0GsaSQFihadaNh15nqRXkrk24PxMqB2/6tIri
23uwL51IpgxTLKEesmNRTIr6BkH5C0gDM0YaEWgvNPLoZyTa5Iw+sKW+C7xNH3jz
wx2rI8jI1a6plIA6wWN6N0FW+AMHDS5xY7SjzgdxA39UIoAQm81hq/8XpE67yfc5
qZeHQ7oaUDO2PZcNbR0fbEoKGhTkaZO6clURErbHZ314hJxKYNs=
=Bu1G
-----END PGP SIGNATURE-----

--=_06V_u4-GPAXmrydi1OosBwC--

From nobody Mon Sep 26 13:54:04 2022
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 4Mbkkp3KN9z4WcnN
	for ; Mon, 26 Sep 2022 13:54:10 +0000 (UTC)
	(envelope-from lev@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mbkkp2nFWz3t22
	for ; Mon, 26 Sep 2022 13:54:10 +0000 (UTC)
	(envelope-from lev@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664200450; h=from:from:reply-to: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=65xUnMZwteZu6Ofe4v31ldO2yLgz8ydwcy1UUv1GtEQ=;
	b=xWIJp5mnOwYlncyBmO6YETLdSZrulnjjFwgY8c4DzJ4UXNbyyYuc5Z35M+i+sCNM0EEb9c
	a32qOVo+HV0Am2DkOKR+QXwB2mJW8ADwx6B5j/FIS00/nGoZCkV/rJZOJ8iwlU8sWHzIS8
	rIogyeUmdTq+XyU0tpNqW0IlTvfYyTKsB5LA4OnFiRrL6FzqHMPg/JBvoHHnBGyFWxQAPW
	a7eTj0dfcFVGesJqfXBYN9EJMoZrgbqq+LSDZcLyisE/NnDu01uL9e5+nuROEsw2NQLT+r
	G6yhQxHTHNcKrTVDdiqZq10vYJpGw62K184UxznkXUWnzV5zk4DUfEmlWEutbg==
Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.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 did not present a certificate)
	(Authenticated sender: lev/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mbkkp19Ndzh84
	for ; Mon, 26 Sep 2022 13:54:10 +0000 (UTC)
	(envelope-from lev@FreeBSD.org)
Received: from [192.168.2.89] (unknown [37.252.88.96])
	(Authenticated sender: lev@serebryakov.spb.ru)
	by onlyone.not-for.work (Postfix) with ESMTPSA id 2097AC88B
	for ; Mon, 26 Sep 2022 16:54:06 +0300 (MSK)
Message-ID: <8cd08b95-396a-b8a3-e33a-b0482a7f23e5@FreeBSD.org>
Date: Mon, 26 Sep 2022 16:54:04 +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/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: Did clang 14 lose some intrinsics support?
Content-Language: en-US
To: freebsd-current@freebsd.org
References: 
 
 <1A903FD8-D904-4B91-ABC4-2F704F0E2CF4@FreeBSD.org>
 
 <430A830E-3473-4EF4-9605-039F8254999C@FreeBSD.org>
From: Lev Serebryakov 
Reply-To: lev@FreeBSD.org
Organization: FreeBSD
In-Reply-To: <430A830E-3473-4EF4-9605-039F8254999C@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664200450; h=from:from:reply-to: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=65xUnMZwteZu6Ofe4v31ldO2yLgz8ydwcy1UUv1GtEQ=;
	b=d17mwh/SHkD6kdMSxGRWA5MSinZZo0sm2mFokRvif9UTv4biKeMJp3KpBub1VaCvPrT0lg
	E6Ha16w+X2mTwBqiTN7yke6YQxeBfO5vRHIM9u/y9tisQ+zrHqeOGrI0gUK4LlkU40BfzA
	6wAurifSbleZIhky8NAhhGqchaijrDozfB1cGo7q8kqN/jRZtShar+EoaYsFkA1yuLVVpJ
	wLZNXp6X0wmU4DpJdaytr6NA27mWl+reTQLVOj6LCSTS69Ovgv5tVqfJ0y5lRPEDxCy1yI
	h5fWiIPFqN+XwoZENmfnCP06vVqRP+neIJCRCGHX/nZIJLXtFWIQg/G9D9Fe9w==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664200450; a=rsa-sha256; cv=none;
	b=G4fP0GKjz+9195qYhcDNDObtbLqWzVtolCwIQuLu1igJzEB+Z9H7NeyFPeC9qQzfbi5yqR
	9jmx2/lD2sG5gVUYVhsCKQyaWTzM9AJi+5UY+4hAo17H2f6qAnYZOqYNqTUqyDhQO5IHVi
	v6vC+7UU6WOCZJgA4aTHrF2TXd+NdPsochz+DI/yk7b7l9GdWzu4R3iFJZ6rRqUQbQCmoW
	g+LkpWX6BGEe+gzmohC4gN8C1YcFIHUVpUUFsncnJDti4WozVUWW3X9aVB2Ad8/ljC6tRt
	eVVj7DhgYktsPLt7QvxhyxA/T1xyllnF5IDpw8PqnvJeNozwWJ1PEHCzAFgRYw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 26.09.2022 13:03, Dimitry Andric wrote:

> Sure, but if you are compiling without -mavx, why would you want the AVX
> intrinsics? You cannot use AVX intrinsics anyway, if AVX is not enabled.
   Because autovectorization (generation of SSE or AVX instructions by compiler itself, without intrinsics) can pessimize code.

   Sometimes it is valuable to know exactly where AVX is used. I don't have examples on hands, but I've seen situations, when autovectorized code was much slower than scalar code.

-- 
// Lev Serebryakov


From nobody Mon Sep 26 13:54:12 2022
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 4Mbkl31cVZz4Wcj3;
	Mon, 26 Sep 2022 13:54:23 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mbkl22qSHz3tyS;
	Mon, 26 Sep 2022 13:54:22 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 318322600F3;
	Mon, 26 Sep 2022 15:54:14 +0200 (CEST)
Content-Type: multipart/mixed; boundary="------------a8adxqA50NrtCs0331Ya7O0D"
Message-ID: <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
Date: Mon, 26 Sep 2022 15:54:12 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: RES: TP-LINK USB no carrier after speed test
Content-Language: en-US
From: Hans Petter Selasky 
To: Ivan Quitschal 
Cc: "freebsd-current@freebsd.org" ,
 "freebsd-usb@FreeBSD.org" 
References: 
 <7d14c045-81dc-fc08-4d62-69fb90a26edb@selasky.org>
 <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org>
 
 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
In-Reply-To: 
X-Rspamd-Queue-Id: 4Mbkl22qSHz3tyS
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-0.31 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_SHORT(-0.80)[-0.802];
	NEURAL_SPAM_LONG(0.69)[0.689];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_BASE64_TEXT(0.10)[];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	FREEMAIL_TO(0.00)[hotmail.com];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	MIME_TRACE(0.00)[0:+,1:+,2:+];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCPT_COUNT_THREE(0.00)[3];
	HAS_ATTACHMENT(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------a8adxqA50NrtCs0331Ya7O0D
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ivan,

Can you revert all if_ure patches, and try this one instead.

--HPS
--------------a8adxqA50NrtCs0331Ya7O0D
Content-Type: text/x-patch; charset=UTF-8; name="a.diff"
Content-Disposition: attachment; filename="a.diff"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3N5cy9kZXYvdXNiL2NvbnRyb2xsZXIveGhjaS5jIGIvc3lzL2Rldi91
c2IvY29udHJvbGxlci94aGNpLmMKaW5kZXggMDQ1YmU5YTQwYjk5Li4wOWFlZmIwMjY4N2Qg
MTAwNjQ0Ci0tLSBhL3N5cy9kZXYvdXNiL2NvbnRyb2xsZXIveGhjaS5jCisrKyBiL3N5cy9k
ZXYvdXNiL2NvbnRyb2xsZXIveGhjaS5jCkBAIC0yODQ4LDggKzI4NDgsMTYgQEAgeGhjaV90
cmFuc2Zlcl9pbnNlcnQoc3RydWN0IHVzYl94ZmVyICp4ZmVyKQogCiAJLyogY2hlY2sgaWYg
YWxyZWFkeSBpbnNlcnRlZCAqLwogCWlmICh4ZmVyLT5mbGFnc19pbnQuYmFuZHdpZHRoX3Jl
Y2xhaW1lZCkgewotCQlEUFJJTlRGTig4LCAiQWxyZWFkeSBpbiBzY2hlZHVsZVxuIik7Ci0J
CXJldHVybiAoMCk7CisJCURQUklOVEZOKDgsICJBbHJlYWR5IGluIHNjaGVkdWxlIChyaW5n
aW4gZG9vcmJlbGwgb25seSlcbiIpOworCisJCS8qCisJCSAqIEFwcGFyZW50bHkgdGhlcmUg
bWF5IGJlIGEgcmFjZSB3aXRoIG11bHRpCisJCSAqIGJ1ZmZlcmluZywgdGhhdCB0aGUgaGFy
ZHdhcmUgZG9lc24ndCBzZWUgdGhlIG5ldworCQkgKiBjaGFpbiBiaXQgdmFsdWUgYW5kIHN0
b3BzIHRoZSBlbmRwb2ludAorCQkgKiBleGVjdXRpb24uIEZpeCB0aGlzIGJ5IHJpbmdpbmcg
dGhlIGRvb3JiZWxsIGFmdGVyCisJCSAqIGVhY2ggYW5kIGV2ZXJ5IGpvYiB0aGF0IGhhcyBi
ZWVuIGNvbXBsZXRlZC4KKwkJICovCisJCWdvdG8gcmluZ19kb29yYmVsbDsKIAl9CiAKIAlw
ZXBleHQgPSB4aGNpX2dldF9lbmRwb2ludF9leHQoeGZlci0+eHJvb3QtPnVkZXYsCkBAIC0y
OTY2LDYgKzI5NzQsNyBAQCB4aGNpX3RyYW5zZmVyX2luc2VydChzdHJ1Y3QgdXNiX3hmZXIg
KnhmZXIpCiAKIAl4ZmVyLT5mbGFnc19pbnQuYmFuZHdpZHRoX3JlY2xhaW1lZCA9IDE7CiAK
K3JpbmdfZG9vcmJlbGw6CiAJeGhjaV9lbmRwb2ludF9kb29yYmVsbCh4ZmVyKTsKIAogCXJl
dHVybiAoMCk7Cg==

--------------a8adxqA50NrtCs0331Ya7O0D--

From nobody Mon Sep 26 14:20:15 2022
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 4MblK907KRz4XBNF
	for ; Mon, 26 Sep 2022 14:20:29 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MblK7646Zz3xKS
	for ; Mon, 26 Sep 2022 14:20:27 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ua1-x931.google.com with SMTP id p17so2467919uao.11
        for ; Mon, 26 Sep 2022 07:20:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=FalTkhh3952KWYuCSngkEOhw0AHxDD/CvyQkOdr/ZmA=;
        b=nxUMClzgo9wYnUWyT4YJA258k4PeHPtYw2jCnV61cv3NdLJicXkZnYMInkABmEC69U
         hMCMJ+IbUEhCmUGfJ37xo/8fxYap18GMWJQVROZ7pkf8SeO+sO2mfko/QARfC/9ebKW4
         xcaJT14juAQN40wnpj3B4VNlZO3ySixTWYl3sULEGF29rDW1CSH1TrqgmFu4bb5fkuIY
         1EUcp/zTmUEtlZ6+pV4zCmM/HVLeklxkGRmUlDeQBsnyV1nHa9hHwVAKaLOxgs2Vn8qN
         5+vkvLgcq1EKxy+Cz0lyb4x9tnlpdEuCiRDkkXO3NsCRvxVvtATU8FyN/d8S2rAwEuyR
         bdlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=FalTkhh3952KWYuCSngkEOhw0AHxDD/CvyQkOdr/ZmA=;
        b=t1zYz5BniyTWnQxWXgAkZg8NGDTIAIPuabLOwhtJdOh6VLqdPpcBBM/dnfwtKQfy1l
         whmV+YziieSe6nzKTPQ0+ZHTHUFIO0L7bswcBfCyL6CZTUapB6RfFZNL4OyxoxLOro/L
         JGQjiENmMDZp+d78GZCMFsi3tt3p4x1lJ/Fdk7kKlgkt25yWRglppttlGCs2+V/c8aCm
         5W9eGKMZylbisyx8BqAKUVlnYFM/VZZufJv9sqZvo8ZEgNZ62RG0d/l8fy33D5ITtccn
         5eS+n/hmC/1GgbSzPFWN7KBmPEYvspmjrTc0ml7ciXZ/xEEcxffmldSTMAGROGI6+DAt
         bvZQ==
X-Gm-Message-State: ACrzQf2rIT447anl9V4x70xaX2Iuuvb1esV3HXW/JRc6S04GFU4OiaOw
	SmojwERQsMSc8yuzEGHhq0UW/+ypGGDr1N0wHSuEGedno1M=
X-Google-Smtp-Source: AMsMyM4eXXPE3mtqA2ZqII3kz0+Z/AlVZc7Yqig8jvYmpR+8VlbC4ciMi8S1vQDsyY7GjrCH/rBeuwgq5WLVcruYPBw=
X-Received: by 2002:ab0:3734:0:b0:3cd:9399:44b9 with SMTP id
 s20-20020ab03734000000b003cd939944b9mr2571037uag.60.1664202026903; Mon, 26
 Sep 2022 07:20:26 -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:  
 <1A903FD8-D904-4B91-ABC4-2F704F0E2CF4@FreeBSD.org> 
 <430A830E-3473-4EF4-9605-039F8254999C@FreeBSD.org> <8cd08b95-396a-b8a3-e33a-b0482a7f23e5@FreeBSD.org>
In-Reply-To: <8cd08b95-396a-b8a3-e33a-b0482a7f23e5@FreeBSD.org>
From: Warner Losh 
Date: Mon, 26 Sep 2022 08:20:15 -0600
Message-ID: 
Subject: Re: Did clang 14 lose some intrinsics support?
To: Lev Serebryakov 
Cc: FreeBSD Current 
Content-Type: multipart/alternative; boundary="000000000000a5fec005e9953a5b"
X-Rspamd-Queue-Id: 4MblK7646Zz3xKS
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=nxUMClzg;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::931) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-1.99 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.99)[-0.993];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::931:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000a5fec005e9953a5b
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 26, 2022, 7:54 AM Lev Serebryakov  wrote:

> On 26.09.2022 13:03, Dimitry Andric wrote:
>
> > Sure, but if you are compiling without -mavx, why would you want the AVX
> > intrinsics? You cannot use AVX intrinsics anyway, if AVX is not enabled.
>    Because autovectorization (generation of SSE or AVX instructions by
> compiler itself, without intrinsics) can pessimize code.
>
>    Sometimes it is valuable to know exactly where AVX is used. I don't
> have examples on hands, but I've seen situations, when autovectorized code
> was much slower than scalar code.
>

The detection method that dim@ outline will work just fine for the
autodetect script. It just replaces the internal, charging undocumented
names for standard ones.

How you later compile individual bits of code is orthogonal.

Warner

>

--000000000000a5fec005e9953a5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Sep 26, 2022, 7:54 AM Lev Serebryakov <lev@freebsd.org> wrote:
On 26.09.2022 13:03, Dimitry Andric wrote:



> Sure, but if you are compiling without -mavx, why would you want the A=
VX

> intrinsics? You cannot use AVX intrinsics anyway, if AVX is not enable=
d.

=C2=A0 =C2=A0Because autovectorization (generation of SSE or AVX instructio=
ns by compiler itself, without intrinsics) can pessimize code.



=C2=A0 =C2=A0Sometimes it is valuable to know exactly where AVX is used. I =
don't have examples on hands, but I've seen situations, when autove=
ctorized code was much slower than scalar code.

The detection method that di=
m@ outline will work just fine for the autodetect script. It just replaces =
the internal, charging undocumented names for standard ones.

How you later compile individual bits=
 of code is orthogonal.=C2=A0

Warner




--000000000000a5fec005e9953a5b--

From nobody Mon Sep 26 15:13:10 2022
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 4MbmV31pZHz4XJsk;
	Mon, 26 Sep 2022 15:13:15 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MbmV23KcKz423g;
	Mon, 26 Sep 2022 15:13:14 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 0387226023C;
	Mon, 26 Sep 2022 17:13:12 +0200 (CEST)
Message-ID: 
Date: Mon, 26 Sep 2022 17:13:10 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: usbhid panic when switching vt-s (invariants+witness enabled)
Content-Language: en-US
From: Hans Petter Selasky 
To: Andriy Gapon , freebsd-stable List 
Cc: FreeBSD Current ,
 Vladimir Kondratyev 
References: 
 <0668f473-f6d3-eacf-e4ef-f8530563daed@selasky.org>
In-Reply-To: <0668f473-f6d3-eacf-e4ef-f8530563daed@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MbmV23KcKz423g
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	MLMMJ_DEST(0.00)[current@FreeBSD.org,stable@FreeBSD.org];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_ALL(0.00)[];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/23/22 23:43, Hans Petter Selasky wrote:
> vpanic() at 0xffffffff808f4c84 = vpanic+0x184/frame 0xfffffe003590e900
> panic() at 0xffffffff808f4a33 = panic+0x43/frame 0xfffffe003590e960
> sleepq_add() at 0xffffffff809521ab = sleepq_add+0x37b/frame 
> 0xfffffe003590e9b0
> _sleep() at 0xffffffff80902118 = _sleep+0x238/frame 0xfffffe003590ea40
> usbhid_sync_xfer() at 0xffffffff8532e071 = usbhid_sync_xfer+0x171/frame 
> 0xfffffe003590eaa0
> usbhid_set_report() at 0xffffffff8532db26 = usbhid_set_report+0x96/frame 
> 0xfffffe003590eae0
> hid_set_report() at 0xffffffff80686caa = hid_set_report+0x6a/frame 
> 0xfffffe003590eb20
> hidbus_write() at 0xffffffff85335a7c = hidbus_write+0x5c/frame 
> 0xfffffe003590eb50
> hid_write() at 0xffffffff80686b98 = hid_write+0x58/frame 0xfffffe003590eb80
> hkbd_set_leds() at 0xffffffff85c1cfe6 = hkbd_set_leds+0x206/frame 
> 0xfffffe003590ebc0
> hkbd_ioctl_locked() at 0xffffffff85c1cd6b = 
> hkbd_ioctl_locked+0x33b/frame 0xfffffe003590ec20
> hkbd_ioctl_locked() at 0xffffffff85c1caff = hkbd_ioctl_locked+0xcf/frame 
> 0xfffffe003590ec80
> hkbd_ioctl() at 0xffffffff85c1ba5a = hkbd_ioctl+0xba/frame 
> 0xfffffe003590ecc0
> kbdmux_ioctl() at 0xffffffff80695d3b = kbdmux_ioctl+0x12b/frame 
> 0xfffffe003590ed00
> vt_window_switch() at 0xffffffff8079d969 = vt_window_switch+0x229/frame 
> 0xfffffe003590ed40
> vt_switch_timer() at 0xffffffff807a15a1 = vt_switch_timer+0x21/frame 
> 0xfffffe003590ed60

Can you test this patch:
https://reviews.freebsd.org/D36715

--HPS

From nobody Mon Sep 26 17:11:25 2022
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 4Mbq6g3dbcz4YJNT;
	Mon, 26 Sep 2022 17:11:39 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2062.outbound.protection.outlook.com [40.92.97.62])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mbq6f4JHFz3H0S;
	Mon, 26 Sep 2022 17:11:38 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=eZOm0a3zCqkcOypHGoCtiHPBSm7R/H01IX343avbgFB3GqNBu+UhKSSCzY11Yfw3+PgQn2rlOfSD2zFBRAa7sQrab/eIfi8ROgFsuM1U5Z9cSUwzcxzt9bGTtBXHIoumMn9sMrpfb7UJah6hImZizDUpWU4OUGBuMr0NSVPxHsbaXMZd611n2DAwRC3Sspg3ThLmCDtTnbtF/nn48IqOrZD6BHD37TluF1uA+uiedgHj7l4k2IEdw1IJ8LyLS7ZNQE2m4JnHb/eQpvtezSsu0FAyRabmxV1RsaVDQ5Ep7f3cjbAqGMk4MLqGeZwEJ+vi582vAWoAarJ2ylyto2+KgQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QXkKqSfDy3EpAf0GYdC9kodOIY5iiLuApUYV+F2kNTU=;
 b=m5cCnj1QbcEMkzixR4EqTfV6uog7A9SVFlRuamFIaaAAhZUwrKrJzXdlCuX6Gzy9JjKxjfHHRv/aj48BvO+Iqrc5aGX3htaJ8x71tYC5X84XEu4ciMoYDkVrk8jFyETEMzRqC7oX6yCqH5nBfQX/QM1ukY1eZiANyRmXOEZs18jS0pQEuveXLNFlLjIklAD7mC7r8h4FKWVHVZG5Awdsa3xergizcSgLsY3dbV6NOXPCkaeZlc8OkB2/9amwN2ejzbD4NKxgxkap6KhIAC0EInZy0eyFeaep90CNgGeprXDMMJLA4Vn25CwbJJHNjGpiHbwX+RtPc16iPybimm8mgg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=QXkKqSfDy3EpAf0GYdC9kodOIY5iiLuApUYV+F2kNTU=;
 b=OWq1et0s+MhEtYptb5tX1onwjBK1uirtMv2ukjAUbowZWqI5dL2YgvXTWGTUKyUaxAElrqYv6wB1X9MovBIo4givfiVdepQ95dCvv5KIR93h1VbE3PixI4KnVtcAEQaxzieoOh7K/+Qwa2O03/xgUg61PRiwp1Muq7CRfMcJW79Bd9J/6hwxSkxrj7HN5986GywWdYXdmhuhMQ+KnbL9dF50gcm9I48Q3wzppJHyBJPYDQVShcehCBzUNMQxY4KxRfzthKnKae/eIqf6oTYfGTksKlMhQdcWb+ddOWaPGtzm3qmIUB8NKt+IU8I71ijaRhIZPzOuxEJRUjdTaHrGYw==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by FRBP284MB0217.BRAP284.PROD.OUTLOOK.COM (2603:10d6:203:3a::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.18; Mon, 26 Sep
 2022 17:11:34 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79%7]) with mapi id 15.20.5654.025; Mon, 26 Sep 2022
 17:11:34 +0000
Date: Mon, 26 Sep 2022 14:11:25 -0300 (-03)
From: Ivan Quitschal 
To: Hans Petter Selasky 
cc: Ivan Quitschal , 
    "freebsd-current@freebsd.org" , 
    "freebsd-usb@FreeBSD.org" 
Subject: Re: RES: TP-LINK USB no carrier after speed test
In-Reply-To: <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
Message-ID:
 
References:  <9188fd1d-00ae-134b-488a-e75fbd152c98@selasky.org> 
   <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org> <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
  <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>  <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
   
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-TMN: [0A9oIqRtChsFViS1sB/BrdJKIyYIs6Pp]
X-ClientProxiedBy: CP5P284CA0028.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:94::15) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|FRBP284MB0217:EE_
X-MS-Office365-Filtering-Correlation-Id: 9d323309-b835-4e06-5f61-08da9fe227c3
X-MS-Exchange-SLBlob-MailProps:
	PHS9e/w+tWKqANVeuxeUUHE7MmlXsKSuQ4LVZVrhzDNteaDmhNxUrzt7RIuA6G1gAUWnY6u49U+SJpOx6Z7CVS3BCV126wkEeiKa2iTdlZv+nANmNx+GTsIs4UNbjph74Iti4QdDolst+Qa54VrQoyWC8BLgexiuqUDnzC1JLgqCnOUO9Sq7pp2rUoPh6+RVIadJnCJLt8krtlzgVMbhoaevu0LV3YNIq+amZAdK1U6Qhh7vtAJxiS+zhlvAZc+I5KznEop85ScOEHHxK3vpsUd9sHJuWQENCvH+heAxkL9z+pMS0B4BT1QYdBxlX3z+V2VnJZVJdAakklXATz6XpchhEtrJOEFO5bTZy8DwhSfgg8s1JW9BUKqSwREWe0ZLg+IJ4/uA9cW2jBBBczb4zI8hilje9PM8F8dtYMTC758Oe8+ixlKuNkufBKMbFSGBRVRce/TUgeCKEICgY68CxrGO1TOTO4jeqibn+/VxFFUGVSlGzKbWszOvK8Z1DFQzbQR+oiSI6totAVhtOngEIzWx4Vvy4v8hqB6SoztfJzUv16kKZBxxLO69paM3lWSAIdAJyf1dWJwiv7A6u4TmknJMgN1gba3q7+F0UZj33v5cdDnD1J+Nc3sxG9InkE9diguvoZGBOGv6Gi+UbuDsf08iyQtA4Tfy3TyakoDvjS42lFXgMs/PCP6Qq+7D2QwHgYBMMzyn23K1zaBdjJOgvA==
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	eGrrsZmmgbeb6Y5og+lXdnegmcH+EzRBlOFAhl8xHa/ImwicGY3ZLrW6e61oeqKYmZPlT1HpC09hPiNVosK5Ebi9DXG2kBMtd/8Ir5wnNdnxayF2o+yO7fIvY8fTiA5StI3Bd56pEbEZtZoBxiHAOAbbOG0bIX0nVKLaBuLFDyX5td0r+qgSZPYtpTMcwDrvFJaAeTcBxR7XnsZfh1qZWfQNK3YBt4UzHkSfVcOHj+0/LSWaxEw521dT89IpAI/IB438EqDS453PHxhexqtuzPlNPZSRQ0Xh0ZpE63dXFtLhNwUOk55YC2RM8pGworLUH0Hy/DR5mbdb/f6h1Qba+Zq7fOC4RE3dRSwsGzzoFZKHtxxVuuGR4En/1UPSxjprJAqoFRDwdGL8CySxQaZJx6YVryCRVjlwN1U/gPLL4VRCvzH2sm5t7mM5/R98kfYCVS24s55Pw4UdAYl2O+6i/nrEyK6P1Y1vE8cNdgxYCLsnZPeCeriiLqQsdUXzj0c2ctfGMj7DGFU1kpTyUfuKYODFEHl1oEGagGLKfDL2fa4v3N7BGmSXkiGNP2WMx+wlbjo/qT+Rr1KvZdH0mIlXs61FNXB7RF71s9/qkMBRSpwVanbIMw7pV7NlVxKMrnGMv18gYQufP3PR/lUGb/VWj7pKhIVxn2aDk5LBIZ6biH5sYEOuqh4WPnU19lx7+29m
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?iLw4Wyr8Vr4BpVY/qKCg3ARAHRtOP+rqP95+EyrOFRHc9z/6sd9+YysKxHUj?=
 =?us-ascii?Q?Zky9MqVQyhqP7H+pdAU/6Tg/LFoWryJ0J5vRbNqBjZqGf4aYdMesD5Hs7Wvd?=
 =?us-ascii?Q?TWQkIUGGYZawFt2YrXXaCsmXcJN6CCOTAX2rys4Idx7Qx0w+9eQ0BPAmeOSG?=
 =?us-ascii?Q?dF9v9Gq3fEG3pnngNDFMww3nAMkqcnio4e1AjcCZCrU+Q737M4B8tow35ALq?=
 =?us-ascii?Q?H+0Lkh4SpyXFrXO+XLmWXXqDTlgJHRU/Rm3mt41Me0UBH4xHnYTBZJOQaltw?=
 =?us-ascii?Q?KreD35Ix+NfmVBAs+z/1VaZnmmJJAUdoxWmCidx6LG8X1zFfJmBMOdaxcSlK?=
 =?us-ascii?Q?HSFrbXh7RDpr6uxQ+VSPvy0f9ND0LgrM/anv42REZSG2cF4NTqHuUtQnz3i9?=
 =?us-ascii?Q?Crf3SH3Hpi2hfRbWO5yHvkoF9OrIkinXKXU0+Nxl9H6v195d76GWeyYy/YLV?=
 =?us-ascii?Q?yHZKqoT2rQXzZX1l9BqVFJOAREgSsf+g3TZMwrfqC0tZxykaDkBLEQ7g/GLR?=
 =?us-ascii?Q?bVA9XgcVUrz0P3BX1i4iHQRfXVApWieDXrduU9EFIjS7ixzvM+P62VIKAMbe?=
 =?us-ascii?Q?6ODpETkmrOHb4TGXMB5HDoobURb8SUIgar35rQCz2QLxdk3c073rwFX2ZvPp?=
 =?us-ascii?Q?vuZiuYaJQQbRcNSFN4GcycHUm66iMaiT5AEWYXY+eQ9pymrM057OhyFFZHwe?=
 =?us-ascii?Q?Uu0VbDUGVkCwptYPtqTB74+I+cc4jytIJH5T2UyRqd/RJk7UPhwMXuG0zlyJ?=
 =?us-ascii?Q?kEuiTkpSPBahfo1iNi0puJQENhIbu8DAqfpAqMFba1hJaHAJjn8JdBZLpbR0?=
 =?us-ascii?Q?S43H+57bT+wmCa35+EaVFltOG/Ble1w6/QzYRPH/8m9T1OPRAZ5QyvpZAvLb?=
 =?us-ascii?Q?zb5hrTUo3CYqnpkexSrOnXR7Ipzb8aJ+KRs5UgpG+CdI5IS8hURKU6KO8V+1?=
 =?us-ascii?Q?qQ9PSdbtFTsZg1N8oMJOIJJC4nMXZOmWKztk3IiAKaYjR7AKE0FTsqVvXt7K?=
 =?us-ascii?Q?Z3Bet9dOpc/pc/yYKysML3mk6CsKMEFc/bi5ZSqDHo3Ac1t1HWI/y/mo7cnk?=
 =?us-ascii?Q?F7+uCzrACYk49q3OG3TQqUF1sFImDeXZahu+i19o48CKB+3ib2JajHazan0g?=
 =?us-ascii?Q?AX6ExSQw23rCCdN36ynNBVng0q55NhHO1SaJ51dF+iDEUkVVa1Tpu+CbgPnD?=
 =?us-ascii?Q?4MNV7tI8XF3n9BpO+eXWfTAN/Y1lM//PR5GBMMzxDep7dASV7XP3iUWR0JNQ?=
 =?us-ascii?Q?1nDk57vSgWHh6HkgQYIns0D6hDdk4UAE7AHKvUQ6DQ=3D=3D?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 9d323309-b835-4e06-5f61-08da9fe227c3
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2022 17:11:34.3058
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRBP284MB0217
X-Rspamd-Queue-Id: 4Mbq6f4JHFz3H0S
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=OWq1et0s;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.62 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-3.89 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-0.94)[-0.936];
	NEURAL_HAM_MEDIUM(-0.74)[-0.744];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	NEURAL_HAM_SHORT(-0.21)[-0.205];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.62:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[hotmail.com,freebsd.org,FreeBSD.org];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_EQ_ADDR_SOME(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N



On Mon, 26 Sep 2022, Hans Petter Selasky wrote:

> Hi Ivan,
>
> Can you revert all if_ure patches, and try this one instead.
>
> --HPS
>


hi Hans

bad news im afraid, problem occurred at the first attempt on speedtest.net.
and I'm really trying to help you analizying this code here myself, but problem 
is: 
im far from expert on network protocol business. if it is a network problem at 
all. 
seems to me more like a USB protocol limit issue or something ..  just FYI , 
limiting that first constant to 2048 still limits my  upload to 90mbps , and 
also still solves the issue .. there has to be something about it obviously

dont remember if i told you that but the tp-link adapter is currently plugged in 
a USB 3.2 port anyway

anything i could do to help you on something here? just let me know

thanks

--tzk


From nobody Mon Sep 26 19:28:52 2022
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 4Mbt9369sVz4cZ3g;
	Mon, 26 Sep 2022 19:28:55 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mbt9328khz3YwB;
	Mon, 26 Sep 2022 19:28:55 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: by mail-qt1-x836.google.com with SMTP id y2so4771473qtv.5;
        Mon, 26 Sep 2022 12:28:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:from:to:cc:subject:date;
        bh=lnaH4TEblo0xgVE2JSnMRqLTTr4JUxpP2bpv7luBiT4=;
        b=CxVtaMIzIV1nuI2jKosy63TWOQG1tepUgySkbRM+SS2WHlbSWg3o+XICyVnKCYoNv5
         TEnKFzlp03jOjiWsnU2ekk9ILXILVUN2T27TpsQsN5X0e2hEX2Y8yH+0vSX1iVKl4pTE
         Bdv5TfJFApv4fc1ZsOq/WbyyYsVQxUi9udkXaOV2QGAN/Ma3ppk0/J03DI3qJsRvqyz5
         gLSmdbgEH736NiO23SG45lcLZtE5G4loa509d7/xukbfWiw3kStvoxB4bXrSX6gw0BiJ
         KT7tOj/8gjjsGaTMD4eGijc/yG6+BF5l7ho58nG/gO2RzU9oIBk1X1n+jzRYpRk/hu5+
         gElw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:x-gm-message-state:from:to:cc:subject:date;
        bh=lnaH4TEblo0xgVE2JSnMRqLTTr4JUxpP2bpv7luBiT4=;
        b=dZOCVKAJs4dXEmOxCgnPh8a2mQlMlrfTpwudDgBgBUGP5yNoLmY7HqH4Fps9FPnKIP
         uNnN7lhLX2r/IwBAeDb0iWlkYB9mSKXJlxTrBW3O60Dj94xKu5iffl/fYa17SiCxW+bT
         d+ici62H15y5s/d4EMxYiZnoztzrBFDhCwVNkvW57OJihzlkItCVf2k9Y/BXtDeEYb5R
         VSN72M9yOJB1zOHq9mTO0MnBjUl+nBtL/qO9lZFvbE7o9wUY4zyS6bghkBshrMao6edQ
         qGK8WWJ35p2ZUX4fDJ0tKNtB8hJ8OgdZOvdOklK0vt8KI/ZJzb9jD1Mk2OCfCtL9InIY
         95JA==
X-Gm-Message-State: ACrzQf35MHV9uI6SlOC/BHiTXF6oyy5pbXhJ3JZlUM5tPMDIx/uRBZh3
	GgWbTqnmO0HTmH8shD7in4rnx6DPW3nkKw==
X-Google-Smtp-Source: AMsMyM7swkCBo4Uu9w8n0CV7xBnHa9tim7PF/+gFsO63MAGmksDmh31m6B00XiPJUvn1Dsr7QqEPVw==
X-Received: by 2002:a05:622a:1701:b0:35b:b3bb:7c4e with SMTP id h1-20020a05622a170100b0035bb3bb7c4emr18935370qtk.195.1664220533363;
        Mon, 26 Sep 2022 12:28:53 -0700 (PDT)
Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234])
        by smtp.gmail.com with ESMTPSA id m7-20020a05620a290700b006bb8b5b79efsm12422325qkp.129.2022.09.26.12.28.52
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 26 Sep 2022 12:28:53 -0700 (PDT)
Message-ID: 
Date: Mon, 26 Sep 2022 15:28:52 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: RES: TP-LINK USB no carrier after speed test
Content-Language: en-US
To: Ivan Quitschal , Hans Petter Selasky 
Cc: "freebsd-current@freebsd.org" ,
 "freebsd-usb@FreeBSD.org" 
References: 
 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
 
From: Alexander Motin 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Mbt9328khz3YwB
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=CxVtaMIz;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::836 as permitted sender) smtp.mailfrom=mavbsd@gmail.com
X-Spamd-Result: default: False [-3.14 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.94)[-0.935];
	FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[freebsd.org];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::836:from];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_TO(0.00)[hotmail.com,selasky.org];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Ivan,

On 26.09.2022 13:11, Ivan Quitschal wrote:
> bad news im afraid, problem occurred at the first attempt on speedtest.net.
> and I'm really trying to help you analizying this code here myself, but 
> problem is: im far from expert on network protocol business. if it is a 
> network problem at all. seems to me more like a USB protocol limit issue 
> or something ..  just FYI , limiting that first constant to 2048 still 
> limits my  upload to 90mbps , and also still solves the issue .. there 
> has to be something about it obviously

On my tests I found that reduction of URE_MAX_TX from 4 to 1 actually 
help a lot more without so dramatic performance decrease.  Though it is 
likely only a workaround and does not explain the cause, so I hope Hans 
more ideas for us to test. ;)

-- 
Alexander Motin

From nobody Mon Sep 26 21:29:18 2022
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 4Mbwr35tNHz4V70N;
	Mon, 26 Sep 2022 21:29:23 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mbwr221d9z3qj0;
	Mon, 26 Sep 2022 21:29:22 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 06590260AFB;
	Mon, 26 Sep 2022 23:29:19 +0200 (CEST)
Message-ID: <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
Date: Mon, 26 Sep 2022 23:29:18 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: RES: TP-LINK USB no carrier after speed test
To: Alexander Motin , Ivan Quitschal 
Cc: "freebsd-current@freebsd.org" ,
 "freebsd-usb@FreeBSD.org" 
References: 
 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
 
 
Content-Language: en-US
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Mbwr221d9z3qj0
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.18 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.976];
	NEURAL_HAM_MEDIUM(-0.90)[-0.904];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[FreeBSD.org,hotmail.com];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[selasky.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/26/22 21:28, Alexander Motin wrote:
> Ivan,
> 
> On 26.09.2022 13:11, Ivan Quitschal wrote:
>> bad news im afraid, problem occurred at the first attempt on 
>> speedtest.net.
>> and I'm really trying to help you analizying this code here myself, 
>> but problem is: im far from expert on network protocol business. if it 
>> is a network problem at all. seems to me more like a USB protocol 
>> limit issue or something ..  just FYI , limiting that first constant 
>> to 2048 still limits my  upload to 90mbps , and also still solves the 
>> issue .. there has to be something about it obviously
> 
> On my tests I found that reduction of URE_MAX_TX from 4 to 1 actually 
> help a lot more without so dramatic performance decrease.  Though it is 
> likely only a workaround and does not explain the cause, so I hope Hans 
> more ideas for us to test. ;)
> 

Hi,

I've got a supposedly "broken" if_ure dongle from Alexander, but I'm 
unable to reproduce the if_ure hang on two different pieces of XHCI 
hardware, Intel based and AMD based, which I've got.

This leads me to believe there is a bug in the XHCI driver or hardware 
on your system.

Can you share the pciconfig -lv output for your XHCI controllers?

Also, when running the stress test and you see the traffic stops, what 
happens if you run this command as root on the ugen which the if_ure 
belongs to:

usbconfig -d ugenX.Y dump_string 0

Does the traffic resume?

--HPS

From nobody Mon Sep 26 22:25:56 2022
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 4Mby5Q2VdNz4YBx7;
	Mon, 26 Sep 2022 22:26:02 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2089.outbound.protection.outlook.com [40.92.96.89])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mby5P0Jwmz3wwF;
	Mon, 26 Sep 2022 22:26:01 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Vd4mY8A7dbxwAgtdfgXLqatbFhViZb1XcqdiYTgIRx6E3M5JWmSyOwKiaKAlhmOgJpDiFV+6ZDOtgtP3KGLcQytXZKaBWaq0yg13irQ8FFh9Lk7XYcptBAqFUJRPvnJ7NajDlVagwiXH50QSKJ/asn9TURVOuRAYaVmUatcCKDAMbH2RUS63CGOUzzq6aEawiVqA5/wQf1WJN89DnxKlQ16Fm45+4G3GqJ81fGF7//BvNm7OsMCn9iNDsmD9ucXgEnNWjdmhYHTudEzsDgUUfB5gjqtERd0d1ua5QbnDEgN3F32e8ra8vAZo73aSifpNKhfHD+GzAPzze+lRt0eUmQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=1A86+YHyDJfzqX5RLcNwWjlgdzT4XH91+P8HwwBG+2U=;
 b=dHiMAV6tUt2wpYGmzFkkQMmxyzzk3j/q1g6jyxmhe64SNnQNrBQwPJo57he1jctkBoNMDtb7b5JQ7qidMAadJKMxZDjOnutz7XuuNGJMET6I7aTtj30pttizJN3uV0Fs0sEQn6UmQlXcMeKhjUMSLnxmjb9/zrsJoI7AkNqLiAzVrpUuIVjwlmA/2erSeHI5LgPSkw+swrvazogUYhefvTrvVNbMuVj20V7nKJ8/44dgh0KA9JAwLpudmv3FF43kl9nAI/DsyudbgyP7exVcfdTZcZi1yZU7gGrJwgQUe9hNzrJrNNCOdRKsdBhP/Hj34MnDhWhKUVlYAqnGn9SRFw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=1A86+YHyDJfzqX5RLcNwWjlgdzT4XH91+P8HwwBG+2U=;
 b=ZOOLTiWHLOHE7Z9YQsMzCeQFUE4ewn5gZrKmv9ZoPN1OHbNrUm6n6Saww2ivUc0w/C+5F/sYOYv12AUg1tBSEXCqT+kryukoeABHT7TQXu2qZT0Th0NjgC6H9p8ifWMyAdQX12DMoxtvlvZjvixMVGAD4DqJrcAPTUsfsAyVzcgCzY2LKMsfdWHVeQf2j3uPyk9+Q0o1XpyBJ/RDiEiD1gjbDlxHM9R5zhOMoaoTVnceqnRVviABifqDC+SqGAxPIUnG/wY6RgDMEUB30VIY01Uoean9Arshw0ZkAYBM/wkBgdSJg1JEqiWTGErfC0GlOU72GgtXAo5e8C1zEPsI9Q==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CP4P284MB1873.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:109::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.16; Mon, 26 Sep
 2022 22:25:57 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79%7]) with mapi id 15.20.5654.025; Mon, 26 Sep 2022
 22:25:57 +0000
From: Ivan Quitschal 
To: Hans Petter Selasky , Alexander Motin 
CC: "freebsd-current@freebsd.org" ,
	"freebsd-usb@FreeBSD.org" 
Subject: RES: RES: TP-LINK USB no carrier after speed test
Thread-Topic: RES: TP-LINK USB no carrier after speed test
Thread-Index:
 AQHYyRYh90zfGba+7EWJS9V+b+FDta3gmrWAgAABUgCAAALNAIAAAPyAgAD2/ICAAAOngIAAAU8AgABe+YCAABa8gIAADhYQgAABrQCAAAlGAIAC7OyAgAHiugCACtKXAIAANxqAgAAmZwCAACGnAIAADsmw
Date: Mon, 26 Sep 2022 22:25:56 +0000
Message-ID:
 
References:
 
 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
 
 
 <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
In-Reply-To: <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [G5z/hHYbRSlyWl3n4QgZS7FoFv1Qi7vXdK+y3OaxK5EFacEioBuJ5Q2WjtyCBlEs]
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CP6P284MB1900:EE_|CP4P284MB1873:EE_
x-ms-office365-filtering-correlation-id: 55080414-ecd3-4f8b-0c4b-08daa00e1521
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 y67NUFwTzp135HT8uVoc7efUtnlCMr97DpdXb/gcABhXz0c7VEgt4u2CWv+sZbsKHqIcF5eXVOPc8vrysgxt0IGE95xcVLI5UaypdXV36b5oO6yg9Q+cpG/w85bR6mTb/OETN1IiVJeo6hpR9ZzYrROsMDkbvtsqVUzJ+oriz3KRVrN+yZroKSmrQNXZ7rGqb+DCfaajqOSgSvOp5cO7z2846Nij1F3FbZi9EaMhK6zUxzWEfKMEOU7I4EyJ7zH+sFrbVkUljUK9vpCAjNkO0ETkN6uTJiayLa8utOrfEKmsgrMbQKh9g/tajYYfK28qZk26/IwcPHqFdW4te3RJIHjDGYDKvVc9HaKpqgvQf537DzdWcP2+mC4brNCOMy6LQna1Y/NlLZhuM523hc+xliC2TZLJB3L7S5doLbxCxJ5PWIwDFGCMSWD33xESUGSMnt4702PKlzTsdJLXIyf55lh/p2tTYv1oqYc7FNzYvMQ4h6pAXeBxisFxvwmcVxAD7bkh2UsHqmGdu9W9Jd0PyfLbsDQjFflYIOXRdaJIMYssInOf3GFvgxdxT+bxN77N1d9Qjohg0cQuvfEi5ddnMKxnjm77Mg2rBdzZSX0mSzaYEeR0Kk52HCEYU9buaX744TIYda8/7YwL4X8tI9AsJg==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?aGdybC9iY2hZT2MxNE4zbkNZa1pyWjh4eEYwck1KUDhHY0k2T1RhZFRublU5?=
 =?utf-8?B?K3VEN3dMVzJKSkVDcS9Rcm5rTGFwK2VXejFPQWIxV0h6cWZDc1gxaldiR2ph?=
 =?utf-8?B?YWJWaTJhSXlLUFpMS1J0aENDNHQ1OWltZGlVTDFraHVsbWlGdkIwcjBHOHBZ?=
 =?utf-8?B?aUFWQ2pvRjN0OXlIbWNvRnRIUGxmSk9PM1MyMnJXSVVVeXhldHUvVnRWK292?=
 =?utf-8?B?SXAyRUE4Q3RSUmp0cU5sSUdsRGlsRzU4RnBGVmZ0MmttQVdwZDZTNVZFdGlU?=
 =?utf-8?B?b2RQRWhvSjJrR0xQeVEwSlE3SURSRGpzN1Q3c3FlU3V5U2N5WkJpVHd0VlJS?=
 =?utf-8?B?N3RJTUMvbFdJNk1ZNk9HNlBnNGt1QVhLOEV4d2Yzb053ei9QNHY5Mkd2RzNH?=
 =?utf-8?B?NFA4QTM4OG9rMElSUXBuSWxUNEJ2Z2VHZ0pFMGlDYTVtOW0vNFhWcFFFMG4y?=
 =?utf-8?B?MVBUVkJNclcwMDA1alR2ZUlLYjhPZElOWEdKRE94aS9ERzUzcE9EbzFLdGtO?=
 =?utf-8?B?UUg0T0Z3Mi9Ickx1Nm04ZUtEYmZUQjFuL3p5TjZLdTNZemh1dGs1bHJtYWZs?=
 =?utf-8?B?OHNYb1ZPbnZSU2xwVFY2aklIbVBReGI3UUVGQkFLa1YzNTFBdGRJVGRrVWZ0?=
 =?utf-8?B?YUEzbHBIT0t5T01MM0VOVm9ld1BsYzk5b1ZaQTZBWFA1Q0l2NXhtMGdGWFdP?=
 =?utf-8?B?bzB1QUpkaEpGeSs2UWJldUpsaHdPWXcrSExPVFgySHdvYldhL2NFWU5CTnFm?=
 =?utf-8?B?UVdac1Rtdmx2bERpMTQxMmE2NU5EMHNVdmpMTXZDaEk1ZGlZdDhqZitWcllR?=
 =?utf-8?B?UmxYWlFjWStHdzVsTGdjNW9QcGtMYmNVWkxEajFidzZmUlFiS0kxZDhQTWtE?=
 =?utf-8?B?VzRWRHMyV1VqRllWdzF5VGhQbEZrbXdRa2FWdWU3ZzhiNVJmV2U0clVIUnJ0?=
 =?utf-8?B?SCtWWlpPT202TjA4R3pqcjN4UHlORi83c3lOVGp3N1FEb3FoTEtGQlIvbTMx?=
 =?utf-8?B?alR5T0hDdHJ3ZEJtWTU4ZWV6MUlnSk04K1Zrd3dUUGdwc2wyc0s2RW9VSXFD?=
 =?utf-8?B?Z25qcTI3MmtGRllzN2UzOHpwdi9yazNXVjVmTkFLZVA2L2MyUjBBWU1RUU1L?=
 =?utf-8?B?RW9hV2hHek16WXBZUW1VOVpaQldDbTdNQnVyWjh2TFlwZzF1UUM0VVpFdFBs?=
 =?utf-8?B?aGo3eDBnS0VwWklkT3hNUmgwNnVaeDZkZWVLbUc2bFNVQXFLMTdCU2I3SFl1?=
 =?utf-8?B?TzJaeHhBbDVaNjBuSlE4ZmN3NnFITmt2TUdISmYzTXhKSmZ0QWJtSzEycy9h?=
 =?utf-8?B?cHNwRGJnTHE5OUlLYzNVOVZybGdRUU90WjZ3NzdvTmcrOGpwWUFTMXE2TFFY?=
 =?utf-8?B?QWNlbHZKNDI4QjlEc2o1NDZCMFVBSmpLYzY5ZXNhcExabTJXVWE5NW0vajd5?=
 =?utf-8?B?NWJ4VXJKcVpoUm52Wld1alV0d0kweEdJMWZkUEljYVNQQ1QrbklHcjFaM3F1?=
 =?utf-8?B?NTh3ZVBZQjFkaityei80ZFBsU2VxSFEzcnlESWZBWnQzNGNGZEhaZlVOU3JO?=
 =?utf-8?B?NnZKN1ZXLzhxRGxFVXlYNXhIM3lFZTl2anVLSmtTRkdQMFR0dGpnTUVESFdj?=
 =?utf-8?B?WHVVOUhtdUVDZEpXajdCSlVMZTFhdnVWSjFndGIranBEcFIrblcxUmJ2cUQy?=
 =?utf-8?B?M1AyTTRxNDIrQ2h3S0t4L0gvYUNQM25SSGpUVVB0UGw4MXg4KzhkT2t3Z0s3?=
 =?utf-8?Q?McyK+yoIfhXLXaPak2E16q4RpQCQjTM1LD8Dg0L?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 55080414-ecd3-4f8b-0c4b-08daa00e1521
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2022 22:25:57.0195
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP4P284MB1873
X-Rspamd-Queue-Id: 4Mby5P0Jwmz3wwF
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=ZOOLTiWH;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.89 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-4.64 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	NEURAL_HAM_MEDIUM(-0.75)[-0.752];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	MIME_GOOD(-0.10)[text/plain];
	MIME_BASE64_TEXT(0.10)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.96.89:from];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_EQ_ADDR_SOME(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

DQoNCj4gLS0tLS1NZW5zYWdlbSBvcmlnaW5hbC0tLS0tDQo+IERlOiBIYW5zIFBldHRlciBTZWxh
c2t5IDxocHNAc2VsYXNreS5vcmc+DQo+IEVudmlhZGEgZW06IHNlZ3VuZGEtZmVpcmEsIDI2IGRl
IHNldGVtYnJvIGRlIDIwMjIgMTg6MjkNCj4gUGFyYTogQWxleGFuZGVyIE1vdGluIDxtYXZARnJl
ZUJTRC5vcmc+OyBJdmFuIFF1aXRzY2hhbA0KPiA8dGV6ZWthQGhvdG1haWwuY29tPg0KPiBDYzog
ZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnOyBmcmVlYnNkLXVzYkBGcmVlQlNELm9yZw0KPiBB
c3N1bnRvOiBSZTogUkVTOiBUUC1MSU5LIFVTQiBubyBjYXJyaWVyIGFmdGVyIHNwZWVkIHRlc3QN
Cj4gDQo+IE9uIDkvMjYvMjIgMjE6MjgsIEFsZXhhbmRlciBNb3RpbiB3cm90ZToNCj4gPiBJdmFu
LA0KPiA+DQo+ID4gT24gMjYuMDkuMjAyMiAxMzoxMSwgSXZhbiBRdWl0c2NoYWwgd3JvdGU6DQo+
ID4+IGJhZCBuZXdzIGltIGFmcmFpZCwgcHJvYmxlbSBvY2N1cnJlZCBhdCB0aGUgZmlyc3QgYXR0
ZW1wdCBvbg0KPiA+PiBzcGVlZHRlc3QubmV0Lg0KPiA+PiBhbmQgSSdtIHJlYWxseSB0cnlpbmcg
dG8gaGVscCB5b3UgYW5hbGl6eWluZyB0aGlzIGNvZGUgaGVyZSBteXNlbGYsDQo+ID4+IGJ1dCBw
cm9ibGVtIGlzOiBpbSBmYXIgZnJvbSBleHBlcnQgb24gbmV0d29yayBwcm90b2NvbCBidXNpbmVz
cy4gaWYNCj4gPj4gaXQgaXMgYSBuZXR3b3JrIHByb2JsZW0gYXQgYWxsLiBzZWVtcyB0byBtZSBt
b3JlIGxpa2UgYSBVU0IgcHJvdG9jb2wNCj4gPj4gbGltaXQgaXNzdWUgb3Igc29tZXRoaW5nIC4u
wqAganVzdCBGWUkgLCBsaW1pdGluZyB0aGF0IGZpcnN0IGNvbnN0YW50DQo+ID4+IHRvIDIwNDgg
c3RpbGwgbGltaXRzIG15wqAgdXBsb2FkIHRvIDkwbWJwcyAsIGFuZCBhbHNvIHN0aWxsIHNvbHZl
cyB0aGUNCj4gPj4gaXNzdWUgLi4gdGhlcmUgaGFzIHRvIGJlIHNvbWV0aGluZyBhYm91dCBpdCBv
YnZpb3VzbHkNCj4gPg0KPiA+IE9uIG15IHRlc3RzIEkgZm91bmQgdGhhdCByZWR1Y3Rpb24gb2Yg
VVJFX01BWF9UWCBmcm9tIDQgdG8gMSBhY3R1YWxseQ0KPiA+IGhlbHAgYSBsb3QgbW9yZSB3aXRo
b3V0IHNvIGRyYW1hdGljIHBlcmZvcm1hbmNlIGRlY3JlYXNlLsKgIFRob3VnaCBpdA0KPiA+IGlz
IGxpa2VseSBvbmx5IGEgd29ya2Fyb3VuZCBhbmQgZG9lcyBub3QgZXhwbGFpbiB0aGUgY2F1c2Us
IHNvIEkgaG9wZQ0KPiA+IEhhbnMgbW9yZSBpZGVhcyBmb3IgdXMgdG8gdGVzdC4gOykNCj4gPg0K
PiANCj4gSGksDQo+IA0KPiBJJ3ZlIGdvdCBhIHN1cHBvc2VkbHkgImJyb2tlbiIgaWZfdXJlIGRv
bmdsZSBmcm9tIEFsZXhhbmRlciwgYnV0IEknbSB1bmFibGUgdG8NCj4gcmVwcm9kdWNlIHRoZSBp
Zl91cmUgaGFuZyBvbiB0d28gZGlmZmVyZW50IHBpZWNlcyBvZiBYSENJIGhhcmR3YXJlLCBJbnRl
bCBiYXNlZA0KPiBhbmQgQU1EIGJhc2VkLCB3aGljaCBJJ3ZlIGdvdC4NCj4gDQo+IFRoaXMgbGVh
ZHMgbWUgdG8gYmVsaWV2ZSB0aGVyZSBpcyBhIGJ1ZyBpbiB0aGUgWEhDSSBkcml2ZXIgb3IgaGFy
ZHdhcmUgb24geW91cg0KPiBzeXN0ZW0uDQo+IA0KPiBDYW4geW91IHNoYXJlIHRoZSBwY2ljb25m
aWcgLWx2IG91dHB1dCBmb3IgeW91ciBYSENJIGNvbnRyb2xsZXJzPw0KPiANCj4gQWxzbywgd2hl
biBydW5uaW5nIHRoZSBzdHJlc3MgdGVzdCBhbmQgeW91IHNlZSB0aGUgdHJhZmZpYyBzdG9wcywg
d2hhdCBoYXBwZW5zIGlmDQo+IHlvdSBydW4gdGhpcyBjb21tYW5kIGFzIHJvb3Qgb24gdGhlIHVn
ZW4gd2hpY2ggdGhlIGlmX3VyZSBiZWxvbmdzIHRvOg0KPiANCj4gdXNiY29uZmlnIC1kIHVnZW5Y
LlkgZHVtcF9zdHJpbmcgMA0KPiANCj4gRG9lcyB0aGUgdHJhZmZpYyByZXN1bWU/DQo+IA0KPiAt
LUhQUw0KDQpIaSBIYW5zLCANCmhvdyBkbyB5b3Ugd2FudCBtZSB0byBkbyB0aG9zZSB0ZXN0cyBm
b3IgeW91ID8gd2l0aCBvciB3aXRob3V0IGFueSBvZiB5b3VyIHBhdGNoZXM/IFdpdGggdGhlIGFj
dHVhbCBjb2RlIG9uIGdpdCA/DQoNCmhpIEFsZXhhbmRlciwNCkkgZGlkIHdoYXQgeW91IHN1Z2dl
c3RlZCwgYW5kIHdoYXQgaGFwcGVuZWQgd2FzIHRoZSBpbnZlcnNlLCB0aGUgdXBsb2FkIGdvdCBi
YWNrIHRvIDMwMG1icHMgLCBhbmQgd2hhdCBkcm9wcGVkIHRvIGEgaGFsZiB3YXMgdGhlIGRvd25s
b2FkLCBkcm9wcGVkIHRvIDIwMCBpbnN0ZWFkIG9mIDYwMCBoZWhlDQoNCi0tdHprDQo=

From nobody Mon Sep 26 23:33:36 2022
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 4Mbzbc6PMSz4YKg6;
	Mon, 26 Sep 2022 23:33:48 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2048.outbound.protection.outlook.com [40.92.97.48])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mbzbb34pZz41d1;
	Mon, 26 Sep 2022 23:33:47 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=KLvXHFJr2jEwdmS7VeUB9bzMX3RdE/483mTgtmG1+y4cw1jd4cXN4nUHhZMhq3vvwUQgOqiGGYa4kyVVLw0aMgwglOmxG5TszJ9JxK0PMgYRpZ6UwYEykH9GYP9HabyHN14+tSHebCd2bDphG4MieIhm2XSrkT/KGA4tVR13ULjfzuP8XbgCyMw24cnEHFCgSMuz4Sqsg5nPUl+r5DAbMK6pVCBluaOvknvIGqKcImAM25mSUzRzKKsabl4/dNxrAYaCAvZVjGtpmEJTo7ToxPQ6CfppSz5G6EKTJqzYCEjb8g+X3yC3DdVsiugKG+LNJYh7nqegkU03jLW1ZNKOIA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=vrXlc8knbXyQ/7nb/3hb7yzeRS1+xZHSW9srlDn1dn0=;
 b=lJKEJTyONz9G4U7gT00M1OrgWd+18WTM2WiN1nD2dyhkZf0rJHMVzvXY+ssnm5XWrmIn/3qvYkXKfe95cEowY2cJdY5M6jcOw3Fgh7/XtpCYMrUOJQnv/5W2RkxhLBHNNh18wVtpK3Cxykjfn4uQk9qFfZHc5Xuv3YoeHzPQl3rYn8IRzVz0d5deQUTz2634x9bmm/qMvRBZ2UZ3vquzh+fscqJ6+qUsvQbYCIyl5sGHpchNjIGZeiQgQqTYGT2jiLosV9B1k7JQ48uqw+lJOdw7fKhNSlQMSXTbxG6KY1FUYdM5iWVr866QpBlcz2co8OtK5/1NreW0RtPoOMrWGA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=vrXlc8knbXyQ/7nb/3hb7yzeRS1+xZHSW9srlDn1dn0=;
 b=G2TQaXPPU10uyaC3w2CcDJB5ps456D+EmJ1ivwXiDgbJu7ul3aC6cZqhW6mLuiwOCJI7yZbJwP7xNuTJmfbFLwswtYgUU/X+DxePvjzsXSBSIAndN1xKDdY8bYWW6+ATEqCpDqyotINS2ISQzbGrxjOMrAo7VrgMYSdIZtB/kWhXOjUxOHdddOSU+ZxnDoIrYc/GVsLwpAceZ4OErF1dH5S0WSTnWfJXlqFHjuhgh99X8pMeTpoquzBoaq+n8ye8nl4xGiyukLgVyxr/zUqTUNJSV8tSjJdMPlCuRVU6znQSvafDpI51DLlSut1z8/CAopE+N+hZFYimoTJaQ3sBIA==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CPZP284MB0214.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:38::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.14; Mon, 26 Sep
 2022 23:33:42 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79%7]) with mapi id 15.20.5654.025; Mon, 26 Sep 2022
 23:33:42 +0000
Date: Mon, 26 Sep 2022 20:33:36 -0300 (-03)
From: Ivan Quitschal 
To: Hans Petter Selasky 
cc: Alexander Motin , Ivan Quitschal , 
    "freebsd-current@freebsd.org" , 
    "freebsd-usb@FreeBSD.org" 
Subject: Re: RES: TP-LINK USB no carrier after speed test
In-Reply-To: <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
Message-ID:
 
References:   <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org> <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
  <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>  <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
    <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
   <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
Content-Type: multipart/mixed; boundary="3432851520-1520251259-1664235221=:1871"
X-TMN: [Z9r7HdgSaFFZp+uXvZu14unQq2BW0D6q]
X-ClientProxiedBy: CP3P284CA0114.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:6f::29) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|CPZP284MB0214:EE_
X-MS-Office365-Filtering-Correlation-Id: 31fd4c94-a48a-4c09-de0e-08daa0178c00
X-MS-Exchange-SLBlob-MailProps:
	CLk2x5OX5VYubCRRXjIAqRqXFyeHFDJptjFA/vLl4BgxT6ohlIwO1hpNT0LrgLPpJs0MHNie14wHgHFrOhZVQiOqTbFS0hSTNTKnuk+Q2df8XYEgu2DssOoa8VO4StAGRGL+c0RiAXdYlMnpZ8APsBQIhj99nalLI3BFqA7rfsI26NsIPcYO+VplcxsNGwZbKbTou6f9wWaE9b7YKJg8UlSOMcaBGOkCyvBSrEN9VqrmsnF23Tznj5lGbL14MVmbOEDnBZ9Zz59yTGQZMWg8QRYLEk5/Ho6X5+Zia28nkYmOLXsEqKrQN8C9PnR30lfipQT6LwdifIaLbGBavSrbxeNkDNMTOlAlw4SsaekwMQGpfZgmOyLnnpiIeHSFKzoLTzSF2fD8w/RKq03ylldBXReidSwuddZOg23BbmFaipYcbUvHwxBjWGoitZ2ucrzcgCYTPEjjKrQZWE0EfjkIYsFbKXwnep2THol770yZx0WAXGixXvSGJX+3Hg8Ig6KkAal2kqWJjVi2KLCwJ5ezZhJyNGRIa3443f0TUJgYW5Ju4Sy2VXvNKr1Pq3dFRhaoeKFdcIJk4jBKbSNd3Ne6j10ojA9QDhUJRtI3f0mq3OmoxFeI6jTD2AymQpQ9k0AzPlN1ku55R2qHIH7E2RP9n8tL3VO3Tjg7dWBrIJiVm6w4ffDSr8VosQbJ8sOLzuyf2W4Rb6bb0F/nh+d79rMJ6g==
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	uAvxhmoWRS6mGOpbTya/WDEHBTcmmKmpJc8O/xNmToBlIVtNeF6RwdA58CEFP4xu/n8gEhMdCsTpN8+W2fUKs+dD3rMNuguM6aiJ0Hu9BE69xGYuFjckW2ezPGal7z2E8uWTZ9GcP7aiP4/wvMeVx0hsjThPniF+h9StmCsGN/qEalgTpewFVC+ZGVeOFNZ3rf0xMoxc7lcwM2rKCgYjX6z5RoVy0EQP81xF/yO3LWxK5nueQGhF6h8two7UJz1gs24zxfd06/cuukQwRkCDPuZkKjE2EoSBCAmtDjjEjgYDn/roiLlNLztnONYUXZNzWh66jIbagn1u6dqIZrjmgcYEjX8JgSpo0ndY0ZL++zli43LxOI33hwwsYVt3RiPdVcAsR1wWeOka8cYFHyDUit7aYCOJ5g4rU6tiTyUxfJb/HtVOBTU05gquFLN80Kn6WUpMnkqGLqEEzrN3feJ6FqX9j4Yk+Y49ro/oomY5dFqlucjLPMLksWCxXPTfyWhs4dMtO32hV9PWofWRIMOBurVY6UfmBf9JVZ+WLIuAqDEBL19rWlPQi37oDmL2iII86m3CIdRY6ZMkMzzWtON0u1IzW+9JybAgHUEoxRyZg+CwhkNLcrAt3tlPEfz6uby0JMsPVnHn3LVXHzhZ4h/feXqzx6OeoenUngmDKXNT/oX2S8Y8TH7mBgxoHtsoyWk5
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?MWV1b0pLemVEUGRuVW41MG5VaHhOYzlmeEthOHEvSE8xa085YlpsSmgrNWo4?=
 =?utf-8?B?bmVob2NDTHZUMTFFZCtjdGc5QkFoYTBMNVFUanlTUVVWdnIxMkU0aGJLaUpm?=
 =?utf-8?B?bk52WUhwNjBhQzFSYTd5b2dPY0tIa0dlQm9yS01ZVU5TR0ZMNDNSa2RhWkVR?=
 =?utf-8?B?ZWFDRnFwTzhOd1BMLzl3aGJFc1ZOWFFyY2V4d1RFa0JNS1RMMDIzVkRMRXZH?=
 =?utf-8?B?eXhQWlpPU0haQld4ejMwbE5Wc1FMbUE3WS9BWHNONy8xbFlHbWVMYm0xMXI4?=
 =?utf-8?B?RzFSeHFMaUlZKzliMVRaVGFnYkxlZ2xQOWIvTS8wcG91eWU5WEtibXZCVGJi?=
 =?utf-8?B?UzJRaG14M1RqTkg0UWZWa2t5bXIvczYyK25CZGYvRXF4UjVkTnVyUVhzUlRi?=
 =?utf-8?B?eUk5NnFWRXJGRWE0MWt4RTRuK2lHenhRYm94Q2NtWERyRWpvdlJXdWpjdzNa?=
 =?utf-8?B?bkwrVHlPV0VJUWlJdzR2aEhiVnlyKzhqWGJWN1VRMHRYMkRQYTR1aFZvWHhu?=
 =?utf-8?B?VEM4VWk4TVdHT2RRNElteksxaHhDMVE4WkpZYmRUeVVPVnpJdGN0Y1JQaUFq?=
 =?utf-8?B?eXY4SUJVQWh3czdhNm81WXk5U21wcGJ2TUFQUVpSaVdXRkRIdU1XYUpKNHJp?=
 =?utf-8?B?ODBQNVROR0dMN2wzMFc0OThLa1l3WS9LUlVSNm1LMVExekhXZGl6NjRmaHU2?=
 =?utf-8?B?S2RJczEzMjBlL2I5cHhJa0NNQW9XRXVRdEROckF1NlJXWjZKUFo1cm1OQmlu?=
 =?utf-8?B?OUtjS1laUlZJMS9aclpNUGpUeVVwalJaUEpRV2QrU2IzOEFsR0lDcEZuaktk?=
 =?utf-8?B?dFRMVTZaNlRxY25iSkZ0d1lXYkx1MlFMQ3Uya2FVZ0pvWnRnUmtaNklPNTBs?=
 =?utf-8?B?ekNIWVh0ZU5LYSs0a3FZM0F3UFQwT3FyRHlqbHg1S2VLR01tVGd1WENQbHhp?=
 =?utf-8?B?bjdaelp5RGdLRFE2b0ZNdGozaHVkdlpwQUJuUWFsZGptMXk0eFl4d2lJV3hn?=
 =?utf-8?B?RHZ4NFNMRDFYK3BROStHdyt3dUdyTDJoSXpZeWNleGR4emFva3I0R0FldS9v?=
 =?utf-8?B?S2pjS2wrYUx4R2ZjSkxmSkZNakk3VWt3dUJVdStFK0NtTm52dVN6WW1kMmhN?=
 =?utf-8?B?VjR4NW1CM1gvL29wem9UTnA0eXU2VkI0cUdoS0R4emt3TW53VkZ3RW1LWGFT?=
 =?utf-8?B?NmRrdUZxeVhWTkpOcGs4akYxZS9mSmNEQTJ4NFJJRjlVUytWUUhaNUhkYVdV?=
 =?utf-8?B?WVBENFYySUhheFNiOENZdHpGUWZCYmYyYnNmSnVtb092aXExRHRjSDRsRi8v?=
 =?utf-8?B?bmZ4dk50N1NZRGwxdzJ6VmhpbElZYkNQTE1LclZEZTE5c2pkZ3Y1Q2JqbENi?=
 =?utf-8?B?SE54cE9TbzByeWxuOVVjN1hiNkxxWnVpVm5yNVRxQmt1YVA2a0VJdGdaN0lj?=
 =?utf-8?B?U3RYTnZ0aFB1OXlqNXFrL2hsZG1lbTM1V0hlei9oQzZlYWttbzFvbTJ6VDNv?=
 =?utf-8?B?VnFyYi9IQWVOUExJMUZXcitkQ1FYMlo4UUtBd1FHTUl3NDJuckNYcTVSWDU0?=
 =?utf-8?B?Q2dHWnhKSHkwSjRyRzU2ZnpDbG9aT0J6L3FRRDEzN0VsRmRNOXIxWlZzblJ2?=
 =?utf-8?B?VmZVTFFvWUVyWGhCd0FoODd3ZmJKS1NlcFdyYklKQnFtWlJnaGhtVU00TXdP?=
 =?utf-8?B?WVhzRXZHK3FlY01PZGV3QmlDeVgzR2hnd0F4N0JRSlBMb1FVUGo0amN3PT0=?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 31fd4c94-a48a-4c09-de0e-08daa0178c00
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2022 23:33:42.8028
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CPZP284MB0214
X-Rspamd-Queue-Id: 4Mbzbb34pZz41d1
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=G2TQaXPP;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.48 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-2.76 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	CTYPE_MIXED_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	NEURAL_SPAM_SHORT(0.24)[0.241];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	FROM_HAS_DN(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.48:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	RCPT_COUNT_FIVE(0.00)[5];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	MIME_TRACE(0.00)[0:+,1:+];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_CC(0.00)[FreeBSD.org,hotmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--3432851520-1520251259-1664235221=:1871
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT



On Mon, 26 Sep 2022, Hans Petter Selasky wrote:

> On 9/26/22 21:28, Alexander Motin wrote:
>> Ivan,
>> 
>> On 26.09.2022 13:11, Ivan Quitschal wrote:
>>> bad news im afraid, problem occurred at the first attempt on 
>>> speedtest.net.
>>> and I'm really trying to help you analizying this code here myself, but 
>>> problem is: im far from expert on network protocol business. if it is a 
>>> network problem at all. seems to me more like a USB protocol limit issue 
>>> or something ..  just FYI , limiting that first constant to 2048 still 
>>> limits my  upload to 90mbps , and also still solves the issue .. there has 
>>> to be something about it obviously
>> 
>> On my tests I found that reduction of URE_MAX_TX from 4 to 1 actually help 
>> a lot more without so dramatic performance decrease.  Though it is likely 
>> only a workaround and does not explain the cause, so I hope Hans more ideas 
>> for us to test. ;)
>> 
>
> Hi,
>
> I've got a supposedly "broken" if_ure dongle from Alexander, but I'm unable 
> to reproduce the if_ure hang on two different pieces of XHCI hardware, Intel 
> based and AMD based, which I've got.
>
> This leads me to believe there is a bug in the XHCI driver or hardware on 
> your system.
>
> Can you share the pciconfig -lv output for your XHCI controllers?
>
> Also, when running the stress test and you see the traffic stops, what 
> happens if you run this command as root on the ugen which the if_ure belongs 
> to:
>
> usbconfig -d ugenX.Y dump_string 0
>
> Does the traffic resume?
>
> --HPS
>

hi Hans

without any patch , the actual code on repository


pciconf -lv
xhci0@pci0:0:20:0:  class=0x0c0330 rev=0x20 hdr=0x00 vendor=0x8086 device=0xa0ed 
subvendor=0x1028 subdevice=0x0ab0
     vendor     = 'Intel Corporation'
     device     = 'Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller'
     class      = serial bus
     subclass   = USB

did the stress test, got the problem, then i tried the below

[root@tzk-inspiron ~ ]# usbconfig -d ugen0.6 dump_string 0
STRING_0x00 = 0x04, 0x03, 0x09, 0x04
[root@tzk-inspiron ~ ]#

nothing happened, still no carrier. in order to get back the internet i had to
[root@tzk-inspiron ~ ]# usbconfig -d ugen0.6 reset

--tzk
--3432851520-1520251259-1664235221=:1871--

From nobody Tue Sep 27 00:24:08 2022
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 4Mc0jp12FJz4cf32;
	Tue, 27 Sep 2022 00:24:14 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mc0jm56XZz455S;
	Tue, 27 Sep 2022 00:24:12 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: by mail-qv1-xf30.google.com with SMTP id i15so5346604qvp.5;
        Mon, 26 Sep 2022 17:24:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:from:to:cc:subject:date;
        bh=P2xnKOfbMmkRs5+M4hB1w4HsdvkiEzihniPW7wU6QvU=;
        b=mi8PytvZZ3tuSt8epA2h85h1/vmqwah1qoe2K1ClMxg6k4Ny34VGDREIuEHvZIaBZa
         pXpOJ+tW+OuOunEOMnsXdNwmpqJ2kNSsNQWa/DkBadb2sjaWS2pMkdOjV2JnEIgjerPI
         DuyHS1gmgeXFANOUMgHEri6GYQ6wpwKjnJzyKxcCHwsks66mPWMC1RswOrOHqiJQoBqV
         RJ11OeBdc7cKc29S6BKcadScdusYP5dxEIEC1KWEJUIEoLJNNtRKxDKmjtWV3H1iXdUP
         DKC9MMJJypMdFEVTZuFTeyL5VeLemKQTM4rQtyelgZ930fU+p2Ylc//W5C3QKcsJUPE9
         wzWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:cc:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:x-gm-message-state:from:to:cc:subject:date;
        bh=P2xnKOfbMmkRs5+M4hB1w4HsdvkiEzihniPW7wU6QvU=;
        b=bkJUIkQW8wKGBD/AVEv1iSiTE4bGuBTnFDpee5N6g1gqzfUeXkyy1sgq2a76uePS72
         88pi3A6KRuDaOiO4Q0m8UVz16W0L8bu5jhR8FZl4Nf5+MJMYYEfKet6SKxgl8QIpgeiR
         UB771lfJL61CQ3RnsdBRILamii5KEKpkc/0xPkBDCrGi7c5fJiYLpHnHlfIQdKsRNLFB
         L8pNDPiJZe3X6VL2jNK9XbiAP5IWOjKSnQzl5ANYZA66Qg/pMAbEgtMqrD9iQ3g8sXW1
         D1vnAPTDe/uNaH3jDslBGydgUolBFYVobvlZTyD5+pbnW+CiWqDShIFANZrkeCEszpWw
         z0fQ==
X-Gm-Message-State: ACrzQf0EK+fFIxXjbQarVszRMJl/sRxlZ2j02oUkWMr7RcM5+yeaWBm/
	tFDcwslgKpEisFRpjxU4Pf0=
X-Google-Smtp-Source: AMsMyM5HKTUn4VIL2iObmViPhTFILq6vDZqvprZTvRs/ap8WMBrjF+kxtDcKPPTwBSaSmiLqHiFhCA==
X-Received: by 2002:a05:6214:29c3:b0:4ad:8c17:885 with SMTP id gh3-20020a05621429c300b004ad8c170885mr17842513qvb.98.1664238250098;
        Mon, 26 Sep 2022 17:24:10 -0700 (PDT)
Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234])
        by smtp.gmail.com with ESMTPSA id f3-20020ac81343000000b00346414a0ca1sm11527724qtj.1.2022.09.26.17.24.09
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 26 Sep 2022 17:24:09 -0700 (PDT)
Message-ID: 
Date: Mon, 26 Sep 2022 20:24:08 -0400
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: RES: TP-LINK USB no carrier after speed test
Content-Language: en-US
To: Hans Petter Selasky , Ivan Quitschal 
Cc: "freebsd-current@freebsd.org" ,
 "freebsd-usb@FreeBSD.org" 
References: 
 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
 
 
 <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
From: Alexander Motin 
In-Reply-To: <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Mc0jm56XZz455S
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=mi8PytvZ;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::f30 as permitted sender) smtp.mailfrom=mavbsd@gmail.com
X-Spamd-Result: default: False [-3.19 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.990];
	FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[freebsd.org];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f30:from];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_TO(0.00)[selasky.org,hotmail.com];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 26.09.2022 17:29, Hans Petter Selasky wrote:
> I've got a supposedly "broken" if_ure dongle from Alexander, but I'm 
> unable to reproduce the if_ure hang on two different pieces of XHCI 
> hardware, Intel based and AMD based, which I've got.
> 
> This leads me to believe there is a bug in the XHCI driver or hardware 
> on your system.
> 
> Can you share the pciconfig -lv output for your XHCI controllers?

I have two laptops of different generations reproducing this problem, 
but both are having Thunderbolt on the USB-C ports:

This is one (7th Gen Core i7):

xhci1@pci0:56:0:0:      class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x8086 
device=0x15d4 subvendor=0x2222 subdevice=0x1111
     vendor     = 'Intel Corporation'
     device     = 'JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine 
Ridge 4C 2016]'
     class      = serial bus
     subclass   = USB
     bar   [10] = type Memory, range 32, base 0xc3f00000, size 65536, 
enabled
     cap 01[80] = powerspec 3  supports D0 D1 D2 D3  current D0
     cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 message
     cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS
                  max read 512
                  link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) 
ClockPM disabled
     ecap 0003[100] = Serial 1 20ff910876f10c00
     ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected
     ecap 0002[300] = VC 1 max VC0
     ecap 0004[400] = Power Budgeting 1
     ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216
     ecap 0018[600] = LTR 1
     ecap 0019[700] = PCIe Sec 1 lane errors 0

This is another (11th Gen Core i7);

xhci0@pci0:0:13:0:      class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 
device=0x9a13 subvendor=0x1028 subdevice=0x0991
     vendor     = 'Intel Corporation'
     device     = 'Tiger Lake-LP Thunderbolt 4 USB Controller'
     class      = serial bus
     subclass   = USB
     bar   [10] = type Memory, range 64, base 0x60552c0000, size 65536, 
enabled
     cap 01[70] = powerspec 2  supports D0 D3  current D0
     cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message
     cap 09[90] = vendor (length 20) Intel cap 15 version 0
     cap 09[b0] = vendor (length 0) Intel cap 0 version 1

Does the system you also has Thunderbolt chip, or you use native Intel 
chipet's XHCI?

> Also, when running the stress test and you see the traffic stops, what 
> happens if you run this command as root on the ugen which the if_ure 
> belongs to:
> 
> usbconfig -d ugenX.Y dump_string 0
> 
> Does the traffic resume?

Nope. Out of 4 times when traffic stopped 2 times it reported  and 2 times it completed successfully, but it neither case it 
recovered traffic.  Only reset recovered it.

-- 
Alexander Motin

From nobody Tue Sep 27 07:13:48 2022
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 4Mc9pT6clmz4WWVw;
	Tue, 27 Sep 2022 07:13:53 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4Mc9pS5wLFz3pX6;
	Tue, 27 Sep 2022 07:13:52 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id B76F62600F3;
	Tue, 27 Sep 2022 09:13:50 +0200 (CEST)
Message-ID: <3b6f9f26-ee87-e844-5429-1d0399e02737@selasky.org>
Date: Tue, 27 Sep 2022 09:13:48 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: RES: RES: TP-LINK USB no carrier after speed test
To: Ivan Quitschal , Alexander Motin 
Cc: "freebsd-current@freebsd.org" ,
 "freebsd-usb@FreeBSD.org" 
References: 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
 
 
 <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
 
Content-Language: en-US
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Mc9pS5wLFz3pX6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[hotmail.com,FreeBSD.org];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[selasky.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/27/22 00:25, Ivan Quitschal wrote:
> Hi Hans,
> how do you want me to do those tests for you ? with or without any of your patches? With the actual code on git ?

Without any patches.

--HPS

From nobody Tue Sep 27 07:19:00 2022
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 4Mc9wV1k1Fz4WX9d;
	Tue, 27 Sep 2022 07:19:06 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mc9wT1XdCz3r2F;
	Tue, 27 Sep 2022 07:19:05 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 8A3392600F3;
	Tue, 27 Sep 2022 09:19:02 +0200 (CEST)
Message-ID: <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org>
Date: Tue, 27 Sep 2022 09:19:00 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: RES: TP-LINK USB no carrier after speed test
Content-Language: en-US
To: Alexander Motin , Ivan Quitschal 
Cc: "freebsd-current@freebsd.org" ,
 "freebsd-usb@FreeBSD.org" 
References: 
 <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org>
 <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
 
 
 <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Mc9wT1XdCz3r2F
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[FreeBSD.org,hotmail.com];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[selasky.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/27/22 02:24, Alexander Motin wrote:
> On 26.09.2022 17:29, Hans Petter Selasky wrote:
>> I've got a supposedly "broken" if_ure dongle from Alexander, but I'm 
>> unable to reproduce the if_ure hang on two different pieces of XHCI 
>> hardware, Intel based and AMD based, which I've got.
>>
>> This leads me to believe there is a bug in the XHCI driver or hardware 
>> on your system.
>>
>> Can you share the pciconfig -lv output for your XHCI controllers?
> 
> I have two laptops of different generations reproducing this problem, 
> but both are having Thunderbolt on the USB-C ports:
> 
> This is one (7th Gen Core i7):
> 
> xhci1@pci0:56:0:0:      class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x8086 
> device=0x15d4 subvendor=0x2222 subdevice=0x1111
>      vendor     = 'Intel Corporation'
>      device     = 'JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine 
> Ridge 4C 2016]'
>      class      = serial bus
>      subclass   = USB
>      bar   [10] = type Memory, range 32, base 0xc3f00000, size 65536, 
> enabled
>      cap 01[80] = powerspec 3  supports D0 D1 D2 D3  current D0
>      cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 message
>      cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS
>                   max read 512
>                   link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) 
> ClockPM disabled
>      ecap 0003[100] = Serial 1 20ff910876f10c00
>      ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected
>      ecap 0002[300] = VC 1 max VC0
>      ecap 0004[400] = Power Budgeting 1
>      ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216
>      ecap 0018[600] = LTR 1
>      ecap 0019[700] = PCIe Sec 1 lane errors 0
> 
> This is another (11th Gen Core i7);
> 
> xhci0@pci0:0:13:0:      class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 
> device=0x9a13 subvendor=0x1028 subdevice=0x0991
>      vendor     = 'Intel Corporation'
>      device     = 'Tiger Lake-LP Thunderbolt 4 USB Controller'
>      class      = serial bus
>      subclass   = USB
>      bar   [10] = type Memory, range 64, base 0x60552c0000, size 65536, 
> enabled
>      cap 01[70] = powerspec 2  supports D0 D3  current D0
>      cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message
>      cap 09[90] = vendor (length 20) Intel cap 15 version 0
>      cap 09[b0] = vendor (length 0) Intel cap 0 version 1
> 
> Does the system you also has Thunderbolt chip, or you use native Intel 
> chipet's XHCI?
> 
>> Also, when running the stress test and you see the traffic stops, what 
>> happens if you run this command as root on the ugen which the if_ure 
>> belongs to:
>>
>> usbconfig -d ugenX.Y dump_string 0
>>
>> Does the traffic resume?
> 
> Nope. Out of 4 times when traffic stopped 2 times it reported  error> and 2 times it completed successfully, but it neither case it 
> recovered traffic.  Only reset recovered it.
> 

Hi Alexander,

Could you run "usbdump -d X.Y" at the same time to capture all the errors?

Looking especially for USB_ERR_TIMEOUT .

I have this:

xhci0@pci0:3:0:3:	class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 
device=0x15e0 subvendor=0x1849 subdevice=0xffff
     vendor     = 'Advanced Micro Devices, Inc. [AMD]'
     device     = 'Raven USB 3.1'
     class      = serial bus
     subclass   = USB

xhci0@pci0:0:20:0:	class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086 
device=0x9d2f subvendor=0x8086 subdevice=0x9d2f
     vendor     = 'Intel Corporation'
     device     = 'Sunrise Point-LP USB 3.0 xHCI Controller'
     class      = serial bus
     subclass   = USB

--HPS

From nobody Tue Sep 27 12:17:10 2022
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 4McJXh6v6Yz4crMH;
	Tue, 27 Sep 2022 12:17:24 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2067.outbound.protection.outlook.com [40.92.97.67])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4McJXg4nrlz3HLm;
	Tue, 27 Sep 2022 12:17:23 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=lwIXW96bBL6KDHBxqZLEEG6xPqIpnNGIBe2Qc0kk3OInyGr2s55dKTL/VA9MePy1n2dRN0/1jwAiNzdbBXKhtT2Mz0pS2o6HRsVgmyg50pr/VK0usPaQuMLdgJ9L8q0JTEANMX1ghsFaidaX/uJq7VBDWN+C8BCuYLQ2w5H8pmlxiUZVEKz8iRU3X2PWSjRHfTK080Mqyko5aZOoLMBNrOwEa3cH/wJggmgGoxAQXxO5iBA9ad7SdpBdzVAUbwI5CJ9oLDBPu2ioxVDqjuUuPUyvAtmuFv6fGBlX4EBLprfghoCuF0DvwvNrJ4T1FlGFOTUcRAmGNF8I4GvSoqnOng==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=4E2HcyoI53ErFAYzixtWSMls9EpcDUzmdCV250DtJtw=;
 b=NcCyTqbMgqkkXLT2UG9RO/XCRqZxpT49uib4Mcl/ysc3KlXP6K5BVI1n8aroXW8PUDrARj3BaDsglzCyWQ2NuChCQVcyaIEuH6o5er7oPZzm0ynjcyZdJY+Hdq35+wZRtG6a1eNNIW91hp7DYVhjY1px8BWQKel9JrIwlpcPbxk7mervpk4ywflV4uotfPOZRlSd4SdpEUaPaN1Zqd9y9gc2J5yb5E7i4yj7bK6OpPF2QnwvGoMJEf3sn2A9jhSPUqEmv9/CS3fyk2jG9rLrsFuFLairhy6acWjHieee9ubrh15ta/UyjY6FZTVW9qyT9Va5RqWN7O8WvfBmcAO3mw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4E2HcyoI53ErFAYzixtWSMls9EpcDUzmdCV250DtJtw=;
 b=KqpsW7mOOOLUyZxReDdxMQsMFtclTA2qKaxNEX21kxB9A+rlf6b+57bsCTsdR2p0ERAqxV/ETskQUMnFRL+kkY40QMZhP7agCXhn9J7iMqNGeJ2FBWxxoGU/ufQQH3i0zoq7WoOwKopILQmQAibzWMen+28i3Vd+UMhKIekJUXYVJEH/3eUObd6WyWvcHsLwpbwfjhcZbNB0m6ZBsR73CVFkfLw3CBbY8IrDf8u8AP82mxzRXseuLFl4BD2sjw0occMUpMwmYPDn0uvFP5JBpOSRiy93PZRJvaRkaTANv2t6d5o0A8sKmGbBeVRTiHJX9q3jvq6DHKw36aFfnuGFKg==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by FRBP284MB0361.BRAP284.PROD.OUTLOOK.COM (2603:10d6:203:1a::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.15; Tue, 27 Sep
 2022 12:17:19 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79%7]) with mapi id 15.20.5654.025; Tue, 27 Sep 2022
 12:17:18 +0000
Date: Tue, 27 Sep 2022 09:17:10 -0300 (-03)
From: Ivan Quitschal 
To: Hans Petter Selasky 
cc: Alexander Motin , Ivan Quitschal , 
    "freebsd-current@freebsd.org" , 
    "freebsd-usb@FreeBSD.org" 
Subject: Re: RES: TP-LINK USB no carrier after speed test
In-Reply-To: <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org>
Message-ID:
 
References:  <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org>  <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
  <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>  
  <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>  
 <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>  <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org>
Content-Type: multipart/mixed; boundary="3432851520-2064475307-1664281036=:2472"
X-TMN: [KEo83ZQQBxq3j5gJEn1a4xIDZm+Hsozf]
X-ClientProxiedBy: CP6P284CA0104.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:1a8::8) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <62132e1-b872-8ab8-5837-1f9165c05eae@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|FRBP284MB0361:EE_
X-MS-Office365-Filtering-Correlation-Id: 21cff022-ed21-429d-abf1-08daa082375f
X-MS-Exchange-SLBlob-MailProps:
	CLk2x5OX5VYIEVPJgTXfPo7gMCDobOFYBAsBp5+tEhdsxp+htsICkMkGkun60KVJghNMfvEoQlGysro/qOge4Z6VzewnpRvRT89hcoSf6RUEdMJTgQeKD3S7b6f2sjs7z4bh4IX/uWffN+KPOnOUxF0bY6QfjgeOXZjXH91uVGNkWeqT7QRUTAAojsNeVLMtfcf1Lo7ZjXFdxmjeDp8f0cUofGRcUS8EoorNkt7FD4M6+rlBF8B/iwpskoEykF7uQWcEFSqysFJcemBLTqMQiOpN5K8nu/4dCGKrh0Vpq7WHDdtAIa/VYpp0LANbYr1K41FJZHhb0rnj9pQuRM7T3cfiXsUqFhafty98P0fVc3O4S2OL8e0DV1ObXItzxYEO5HFcZB5NkDvu19HKy+axNTzsZiV04HjFLSF3N2EWjC1wBF6gJl91fJ3eoEz4wwNZC4YIrmovAqJO5D4rCPx9Dy1hWCHPL3VEWznQJFQ4mGvbbxXbXKflNXr//IBOsveajD36n9RX7bsXmQg/27NmKzD6Qp50aLWKXAIIro/OkJYxmf+VQ7deKSXp92waSc0z02juYYl7XsXpWH4znx6ack7JoqtHTq+OQWezTBEYJ68nqbreQwR7RadIEg0eRN0bJrfA4uQX5dx7kUP0/a+w0NXCGCdQtw2K8bsRVCMMzwg2vq5D4tKxpU6laVGwCYfYdDR8cHD8w2vb7crW5kmtLA==
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	2B8kXobVP1y7p9OTIDWgNAzX2d0ABFl7zoT36IW+7FDSQPPtYTyA013kP2FWWBApgtFjNGVTt521SYPEDY/Ep14iHfCn9+mrSgODv2Wedf2Z/JOGUGdOCVgQikWs49vOqFS5ONndlbNdDE6tcygL4QEnTJmPGyxdVbbJ/8nVIlQeooTfXbmSY2eJuxE14BO1TrUPpZzYNSxWyQs63W0mSJgmmJiLxFPXsPfImcS8aI2EccevVJMwGDRKTqcRsXLaUbNi76WBbtsm+9PpLuafac4pitgYktEkuiZxvBAVW+7/vE/Zt7ZGygKm9ymbRkMFr6aRb7srhIwJUZIva8WEOWF3aYh/B7Zeu0JbmbRx50MQmEtbHkj6S4ojuXI3p/v/phiDTETsYHXVR666a9OBUadDN/aQxbVNlgzzYovfxVcY+1UPBZcoqE9Z5sstsbFQAylxb/ImNYvCt5pNJROkkYGndq5PUW8foAkj9x1X4ZGsrIbyZQN0Z79dI1OEoDxoZUbrXsk/Wesiot/GqU8puu3Wi1RaLkP9+25k08tz6baphDzHS94d95xo7fzSYCIRQh8gcvaHLsGnVWGWrzXwGtYF+rUlLCOv6eLnMpij1mxb+ObKlCaC5KSoxGEwmcpqmRzbUoU81p/5xn68Zu2yhQoYNUn+ndGwKs1/AOT08M+nZahY/sGf7fvKldOplX+Z
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?L1RyTUV5UTVuQ1lMTVdJZ1VRMUg5clhnVFZiUE9ZTSs2NGVKWGk0cnVhMm1N?=
 =?utf-8?B?anN5YXlSdmJINXNSL3JCSURFMVlKS2s1WmFjM1RJUnh3RkdtT1dEQzB6cFJD?=
 =?utf-8?B?U3lzOWZkL0NoYjdFY04wZnNOOEhrZW1Xc3B0ei9uV0MzcXA1SGNGZk1TV1N6?=
 =?utf-8?B?WEFxblRCWXhZY0l3dzlRbVBJVmZRd2NNaDdtZ3h2TUFVRnhOMjRWNEFhU0RT?=
 =?utf-8?B?TUE2eEpiS0N5eGNyem5zd1hqTzMxeVZlZ2syOTBGUFE4dER2M0lZdXJRNTYw?=
 =?utf-8?B?WFZwVnlYZlRSbVgxa2FmeGlGdVNhaVNsVnFXK29HRk5UbXhPcVBGRGlZZFRR?=
 =?utf-8?B?cTFxTmVpc3hnK29oRCtraTM3a3ZwUysxam1nbVZ1V1lBR2RIWmdqeVcwVlgz?=
 =?utf-8?B?QWhZbnJ0WjdHRUVSU3diT1hiK0RBK1krc1FJS0pBMXRUTWplVTlrZXpPa0lj?=
 =?utf-8?B?cjBqTmc2elpBUEdJQWw0N2JFL215TjNrTVBTTTN1ZTNkZzBjTmN3Y0VabkZU?=
 =?utf-8?B?eFpxRDhFOURCZzRNY21IMVR3ZU1yTi9WMHBRMC9Eb3VDOStKZ1NTdUtjV0x4?=
 =?utf-8?B?R2FxSURLYVVQYXBCR284cWNEcGQ4S3hWRTV1bFJidUxHZDJJSkRkVVFJYkJN?=
 =?utf-8?B?K1IvdURveEdLNWgydmJ1bTkyUllOYkc4ZzdiVEtEdmYva0lBL1ZVcXhqeHdY?=
 =?utf-8?B?bTJpakF6WmRLYVpxTFBOa1FIalhnU3V3UTREYlcvckV0YjZJVDNZWDNXbExN?=
 =?utf-8?B?a2toY2tyV3ZUTzdsbEl5VmlhMGlTM3FDd05aY3pHYjlHYml0SUVDeUYvbTBR?=
 =?utf-8?B?ZE04NWJRcTVoakpHekpzTjcyT2JlMlBEYTFQSVdXTEJYanhtZXFGbHFLbkFt?=
 =?utf-8?B?dnNXQzNhVjRSN05TUW5mdmc3Ti9lelliQmxGakRYMFVNMmR3bmhVOVpqcE5U?=
 =?utf-8?B?M0t1MmJLN1dlYUxDOGhKV0lOMlIyenBoUzl5YjAzb3dEZ2haeW1kTEErNERQ?=
 =?utf-8?B?R3B1TzVKL01SVi9NQ0FNdHFBM1NydlRaeGpoQ3NkcUw3UU1Ib0ZQOW9KM2pu?=
 =?utf-8?B?algvRUFvL2NrYWQ0L2lSUytYQ0RZRkhLbGJHdS9kTS9YSEZmTUhYb2RJV2ls?=
 =?utf-8?B?N1hKb2RaVGVvM0MveFFlTUVLdG1YSEZvOVhUakQyaW5XcEh0enZIR2tBNnJC?=
 =?utf-8?B?bTRhU1NZWGYzQTIwcS9TUXlNNStXVkJXbnJqdGYraDREMTJ6TnlGSGN2L2tD?=
 =?utf-8?B?elBvaG1mMlpaTWV4NmhkRzNzQm95WkxiU3VHYStreGQvZUh5QWVaYkdjVm12?=
 =?utf-8?B?WVFMV0xlb3BiVFZ4VFY0V0t3a2YwNHQrVHM3OWJZMWhZVEhwM0VRSFF4RmNH?=
 =?utf-8?B?YUlYeTY1V0JZUGxGaUFLSHdtM1N5VG03NHVEZlhCYVkzZ2RDdjU1VEZVWFcv?=
 =?utf-8?B?QThhZkk5QTY3Ty9LZlBPTUkvWWVvdlJkNFZLTjl6R0Ryak93K2ZYTU9ubUdC?=
 =?utf-8?B?VEZDRmZJaFdVRXRjN09WaytRdzhRVG1xaEsyK2RuYVVDM2hCb1k2dnhCL1F6?=
 =?utf-8?B?akJJZ2J6dW1XT1hmTWlaSjlUbHo5K0dMektVcjh1Q255Qm5yekZtZzZzdWtQ?=
 =?utf-8?B?NDNTdDVTbkxMVFRPR0RpWEVYTVh1c1hzVmNXNFhxNVdmNWJiUUhIM0R5U2FI?=
 =?utf-8?B?U2ZwN2NEUlU3Z1UwSlJQc1VtL2tBNlIxYm93NXI4elI0ZFFJMTBBZXVRPT0=?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 21cff022-ed21-429d-abf1-08daa082375f
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2022 12:17:18.8833
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRBP284MB0361
X-Rspamd-Queue-Id: 4McJXg4nrlz3HLm
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=KqpsW7mO;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.67 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-2.92 / 15.00];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.990];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	MIME_BASE64_TEXT(0.10)[];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	NEURAL_HAM_MEDIUM(-0.03)[-0.034];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.67:from];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:+,5:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	HAS_ATTACHMENT(0.00)[];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	RCPT_COUNT_FIVE(0.00)[5];
	DKIM_TRACE(0.00)[hotmail.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_CC(0.00)[FreeBSD.org,hotmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--3432851520-2064475307-1664281036=:2472
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT



On Tue, 27 Sep 2022, Hans Petter Selasky wrote:

> On 9/27/22 02:24, Alexander Motin wrote:
>> On 26.09.2022 17:29, Hans Petter Selasky wrote:
>>> I've got a supposedly "broken" if_ure dongle from Alexander, but I'm 
>>> unable to reproduce the if_ure hang on two different pieces of XHCI 
>>> hardware, Intel based and AMD based, which I've got.
>>> 
>>> This leads me to believe there is a bug in the XHCI driver or hardware on 
>>> your system.
>>> 
>>> Can you share the pciconfig -lv output for your XHCI controllers?
>> 
>> I have two laptops of different generations reproducing this problem, but 
>> both are having Thunderbolt on the USB-C ports:
>> 
>> This is one (7th Gen Core i7):
>> 
>> xhci1@pci0:56:0:0:      class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x8086 
>> device=0x15d4 subvendor=0x2222 subdevice=0x1111
>>      vendor     = 'Intel Corporation'
>>      device     = 'JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine 
>> Ridge 4C 2016]'
>>      class      = serial bus
>>      subclass   = USB
>>      bar   [10] = type Memory, range 32, base 0xc3f00000, size 65536, 
>> enabled
>>      cap 01[80] = powerspec 3  supports D0 D1 D2 D3  current D0
>>      cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 message
>>      cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS
>>                   max read 512
>>                   link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) ClockPM 
>> disabled
>>      ecap 0003[100] = Serial 1 20ff910876f10c00
>>      ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected
>>      ecap 0002[300] = VC 1 max VC0
>>      ecap 0004[400] = Power Budgeting 1
>>      ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216
>>      ecap 0018[600] = LTR 1
>>      ecap 0019[700] = PCIe Sec 1 lane errors 0
>> 
>> This is another (11th Gen Core i7);
>> 
>> xhci0@pci0:0:13:0:      class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 
>> device=0x9a13 subvendor=0x1028 subdevice=0x0991
>>      vendor     = 'Intel Corporation'
>>      device     = 'Tiger Lake-LP Thunderbolt 4 USB Controller'
>>      class      = serial bus
>>      subclass   = USB
>>      bar   [10] = type Memory, range 64, base 0x60552c0000, size 65536, 
>> enabled
>>      cap 01[70] = powerspec 2  supports D0 D3  current D0
>>      cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message
>>      cap 09[90] = vendor (length 20) Intel cap 15 version 0
>>      cap 09[b0] = vendor (length 0) Intel cap 0 version 1
>> 
>> Does the system you also has Thunderbolt chip, or you use native Intel 
>> chipet's XHCI?
>> 
>>> Also, when running the stress test and you see the traffic stops, what 
>>> happens if you run this command as root on the ugen which the if_ure 
>>> belongs to:
>>> 
>>> usbconfig -d ugenX.Y dump_string 0
>>> 
>>> Does the traffic resume?
>> 
>> Nope. Out of 4 times when traffic stopped 2 times it reported  
>> and 2 times it completed successfully, but it neither case it recovered 
>> traffic.  Only reset recovered it.
>> 
>
> Hi Alexander,
>
> Could you run "usbdump -d X.Y" at the same time to capture all the errors?
>
> Looking especially for USB_ERR_TIMEOUT .
>
> I have this:
>
> xhci0@pci0:3:0:3:	class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 
> device=0x15e0 subvendor=0x1849 subdevice=0xffff
>    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
>    device     = 'Raven USB 3.1'
>    class      = serial bus
>    subclass   = USB
>
> xhci0@pci0:0:20:0:	class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086 
> device=0x9d2f subvendor=0x8086 subdevice=0x9d2f
>    vendor     = 'Intel Corporation'
>    device     = 'Sunrise Point-LP USB 3.0 xHCI Controller'
>    class      = serial bus
>    subclass   = USB
>
> --HPS
>


hi Hans

i think i got some good logs for you

before the problem i ran this:

ugen0.10:  at usbus0, cfg=0 md=HOST spd=SUPER 
(5.0Gbps) pwr=ON (72mA)

# usbconfig -d ugen0.10 >> before
# usbconfig -d ugen0.10 dump_all_desc >> before
# usbconfig -d ugen0.10 dump_stats >> before_status

the after the problem happened i ran

# usbconfig -d ugen0.10 >> after
# usbconfig -d ugen0.10 dump_all_desc >> after
# usbconfig -d ugen0.10 dump_stats >> after_status


just by looking i already see some problems comparing both

for example

before the problem we have:

----------------------
ugen0.10:  at usbus0, cfg=0 md=HOST spd=SUPER 
(5.0Gbps) pwr=ON (72mA)
ugen0.10:  at usbus0, cfg=0 md=HOST spd=SUPER 
(5.0Gbps) pwr=ON (72mA)

   bLength = 0x0012
   bDescriptorType = 0x0001
   bcdUSB = 0x0300
   bDeviceClass = 0x0000  
   bDeviceSubClass = 0x0000
   bDeviceProtocol = 0x0000
   bMaxPacketSize0 = 0x0009
   idVendor = 0x2357
   idProduct = 0x0601
   bcdDevice = 0x3000
****
   iManufacturer = 0x0001  
   iProduct = 0x0002  
   iSerialNumber = 0x0006  <000001>
   bNumConfigurations = 0x0002

------------------------

after the problem

--------------------------
ugen0.10:  at usbus0, cfg=0 md=HOST spd=SUPER 
(5.0Gbps) pwr=ON (72mA)
ugen0.10:  at usbus0, cfg=0 md=HOST spd=SUPER 
(5.0Gbps) pwr=ON (72mA)

   bLength = 0x0012
   bDescriptorType = 0x0001
   bcdUSB = 0x0300
   bDeviceClass = 0x0000  
   bDeviceSubClass = 0x0000
   bDeviceProtocol = 0x0000
   bMaxPacketSize0 = 0x0009
   idVendor = 0x2357
   idProduct = 0x0601
   bcdDevice = 0x3000
****
iManufacturer = 0x0001  
   iProduct = 0x0002  
   iSerialNumber = 0x0006  
   bNumConfigurations = 0x0002

  Configuration index 0 
--------------------------


the log in ttyv0 was this:

ure0: at uhub0, port 14, addr 9 (disconnected)
Sep 27 08:55:58 tzk-inspiron dhclient[1201]: receive_packet failed on ue0: 
Device not configured
Sep 27 08:55:58 tzk-inspiron dhclient[1201]: ioctl(SIOCGIFFLAGS) on ue0: 
Operation not permitted
Sep 27 08:55:58 tzk-inspiron dhclient[1201]: Interface ue0 no longer appears 
valid.
Sep 27 08:55:58 tzk-inspiron dhclient[1201]: No live interfaces to poll on - 
exiting.
Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
Sep 27 08:55:58 tzk-inspiron dhclient[1201]: connection closed
Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
rgephy0: detached
miibus0: detached
ure0: detached


difference between before_status and after_status

before_status:

ugen0.10:  at usbus0, cfg=0 md=HOST spd=SUPER 
(5.0Gbps) pwr=ON (72mA)

{
     UE_CONTROL_OK       : 2389
     UE_ISOCHRONOUS_OK   : 0
     UE_BULK_OK          : 803
     UE_INTERRUPT_OK     : 0
     UE_CONTROL_FAIL     : 0
     UE_ISOCHRONOUS_FAIL : 0
     UE_BULK_FAIL        : 0
     UE_INTERRUPT_FAIL   : 0
}


after_status:

ugen0.10:  at usbus0, cfg=0 md=HOST spd=SUPER 
(5.0Gbps) pwr=ON (72mA)

{
     UE_CONTROL_OK       : 4275
     UE_ISOCHRONOUS_OK   : 0
     UE_BULK_OK          : 1126702
     UE_INTERRUPT_OK     : 0
     UE_CONTROL_FAIL     : 326
     UE_ISOCHRONOUS_FAIL : 0
     UE_BULK_FAIL        : 42
     UE_INTERRUPT_FAIL   : 0
}



i hope that helps


all log files are attached

thanks

--tzk

--3432851520-2064475307-1664281036=:2472
Content-Type: text/plain; charset=US-ASCII; name=after
Content-Transfer-Encoding: BASE64
Content-ID: <20582bf3-4e6e-d26a-2e5f-cd428ecefa0@hotmail.com>
Content-Description: after
Content-Disposition: attachment; filename=after

dWdlbjAuMTA6IDxUUC1MaW5rIFVTQiAxMC8xMDAvMTAwMCBMQU4+IGF0IHVzYnVzMCwgY2ZnPTAg
bWQ9SE9TVCBzcGQ9U1VQRVIgKDUuMEdicHMpIHB3cj1PTiAoNzJtQSkNCnVnZW4wLjEwOiA8VFAt
TGluayBVU0IgMTAvMTAwLzEwMDAgTEFOPiBhdCB1c2J1czAsIGNmZz0wIG1kPUhPU1Qgc3BkPVNV
UEVSICg1LjBHYnBzKSBwd3I9T04gKDcybUEpDQoNCiAgYkxlbmd0aCA9IDB4MDAxMiANCiAgYkRl
c2NyaXB0b3JUeXBlID0gMHgwMDAxIA0KICBiY2RVU0IgPSAweDAzMDAgDQogIGJEZXZpY2VDbGFz
cyA9IDB4MDAwMCAgPFByb2JlZCBieSBpbnRlcmZhY2UgY2xhc3M+DQogIGJEZXZpY2VTdWJDbGFz
cyA9IDB4MDAwMCANCiAgYkRldmljZVByb3RvY29sID0gMHgwMDAwIA0KICBiTWF4UGFja2V0U2l6
ZTAgPSAweDAwMDkgDQogIGlkVmVuZG9yID0gMHgyMzU3IA0KICBpZFByb2R1Y3QgPSAweDA2MDEg
DQogIGJjZERldmljZSA9IDB4MzAwMCANCiAgaU1hbnVmYWN0dXJlciA9IDB4MDAwMSAgPHJldHJp
ZXZpbmcgc3RyaW5nIGZhaWxlZD4NCiAgaVByb2R1Y3QgPSAweDAwMDIgIDxyZXRyaWV2aW5nIHN0
cmluZyBmYWlsZWQ+DQogIGlTZXJpYWxOdW1iZXIgPSAweDAwMDYgIDxyZXRyaWV2aW5nIHN0cmlu
ZyBmYWlsZWQ+DQogIGJOdW1Db25maWd1cmF0aW9ucyA9IDB4MDAwMiANCg0KIENvbmZpZ3VyYXRp
b24gaW5kZXggMA0KDQogICAgYkxlbmd0aCA9IDB4MDAwOSANCiAgICBiRGVzY3JpcHRvclR5cGUg
PSAweDAwMDIgDQogICAgd1RvdGFsTGVuZ3RoID0gMHgwMDM5IA0KICAgIGJOdW1JbnRlcmZhY2Vz
ID0gMHgwMDAxIA0KICAgIGJDb25maWd1cmF0aW9uVmFsdWUgPSAweDAwMDEgDQogICAgaUNvbmZp
Z3VyYXRpb24gPSAweDAwMDAgIDxubyBzdHJpbmc+DQogICAgYm1BdHRyaWJ1dGVzID0gMHgwMGEw
IA0KICAgIGJNYXhQb3dlciA9IDB4MDAyNCANCg0KICAgIEludGVyZmFjZSAwDQogICAgICBiTGVu
Z3RoID0gMHgwMDA5IA0KICAgICAgYkRlc2NyaXB0b3JUeXBlID0gMHgwMDA0IA0KICAgICAgYklu
dGVyZmFjZU51bWJlciA9IDB4MDAwMCANCiAgICAgIGJBbHRlcm5hdGVTZXR0aW5nID0gMHgwMDAw
IA0KICAgICAgYk51bUVuZHBvaW50cyA9IDB4MDAwMyANCiAgICAgIGJJbnRlcmZhY2VDbGFzcyA9
IDB4MDBmZiAgPFZlbmRvciBzcGVjaWZpYz4NCiAgICAgIGJJbnRlcmZhY2VTdWJDbGFzcyA9IDB4
MDBmZiANCiAgICAgIGJJbnRlcmZhY2VQcm90b2NvbCA9IDB4MDAwMCANCiAgICAgIGlJbnRlcmZh
Y2UgPSAweDAwMDAgIDxubyBzdHJpbmc+DQoNCiAgICAgRW5kcG9pbnQgMA0KICAgICAgICBiTGVu
Z3RoID0gMHgwMDA3IA0KICAgICAgICBiRGVzY3JpcHRvclR5cGUgPSAweDAwMDUgDQogICAgICAg
IGJFbmRwb2ludEFkZHJlc3MgPSAweDAwODEgIDxJTj4NCiAgICAgICAgYm1BdHRyaWJ1dGVzID0g
MHgwMDAyICA8QlVMSz4NCiAgICAgICAgd01heFBhY2tldFNpemUgPSAweDA0MDAgDQogICAgICAg
IGJJbnRlcnZhbCA9IDB4MDAwMCANCiAgICAgICAgYlJlZnJlc2ggPSAweDAwMDAgDQogICAgICAg
IGJTeW5jaEFkZHJlc3MgPSAweDAwMDAgDQoNCiAgICAgIEFkZGl0aW9uYWwgRGVzY3JpcHRvcg0K
DQogICAgICBiTGVuZ3RoID0gMHgwNg0KICAgICAgYkRlc2NyaXB0b3JUeXBlID0gMHgzMA0KICAg
ICAgYkRlc2NyaXB0b3JTdWJUeXBlID0gMHgwMw0KICAgICAgIFJBVyBkdW1wOiANCiAgICAgICAw
eDAwIHwgMHgwNiwgMHgzMCwgMHgwMywgMHgwMCwgMHgwMCwgMHgwMA0KDQoNCiAgICAgRW5kcG9p
bnQgMQ0KICAgICAgICBiTGVuZ3RoID0gMHgwMDA3IA0KICAgICAgICBiRGVzY3JpcHRvclR5cGUg
PSAweDAwMDUgDQogICAgICAgIGJFbmRwb2ludEFkZHJlc3MgPSAweDAwMDIgIDxPVVQ+DQogICAg
ICAgIGJtQXR0cmlidXRlcyA9IDB4MDAwMiAgPEJVTEs+DQogICAgICAgIHdNYXhQYWNrZXRTaXpl
ID0gMHgwNDAwIA0KICAgICAgICBiSW50ZXJ2YWwgPSAweDAwMDAgDQogICAgICAgIGJSZWZyZXNo
ID0gMHgwMDAwIA0KICAgICAgICBiU3luY2hBZGRyZXNzID0gMHgwMDAwIA0KDQogICAgICBBZGRp
dGlvbmFsIERlc2NyaXB0b3INCg0KICAgICAgYkxlbmd0aCA9IDB4MDYNCiAgICAgIGJEZXNjcmlw
dG9yVHlwZSA9IDB4MzANCiAgICAgIGJEZXNjcmlwdG9yU3ViVHlwZSA9IDB4MDMNCiAgICAgICBS
QVcgZHVtcDogDQogICAgICAgMHgwMCB8IDB4MDYsIDB4MzAsIDB4MDMsIDB4MDAsIDB4MDAsIDB4
MDANCg0KDQogICAgIEVuZHBvaW50IDINCiAgICAgICAgYkxlbmd0aCA9IDB4MDAwNyANCiAgICAg
ICAgYkRlc2NyaXB0b3JUeXBlID0gMHgwMDA1IA0KICAgICAgICBiRW5kcG9pbnRBZGRyZXNzID0g
MHgwMDgzICA8SU4+DQogICAgICAgIGJtQXR0cmlidXRlcyA9IDB4MDAwMyAgPElOVEVSUlVQVD4N
CiAgICAgICAgd01heFBhY2tldFNpemUgPSAweDAwMDIgDQogICAgICAgIGJJbnRlcnZhbCA9IDB4
MDAwOCANCiAgICAgICAgYlJlZnJlc2ggPSAweDAwMDAgDQogICAgICAgIGJTeW5jaEFkZHJlc3Mg
PSAweDAwMDAgDQoNCiAgICAgIEFkZGl0aW9uYWwgRGVzY3JpcHRvcg0KDQogICAgICBiTGVuZ3Ro
ID0gMHgwNg0KICAgICAgYkRlc2NyaXB0b3JUeXBlID0gMHgzMA0KICAgICAgYkRlc2NyaXB0b3JT
dWJUeXBlID0gMHgwMA0KICAgICAgIFJBVyBkdW1wOiANCiAgICAgICAweDAwIHwgMHgwNiwgMHgz
MCwgMHgwMCwgMHgwMCwgMHgwMiwgMHgwMA0KDQoNCg0KDQo=

--3432851520-2064475307-1664281036=:2472
Content-Type: text/plain; charset=US-ASCII; name=after_status
Content-Transfer-Encoding: BASE64
Content-ID: <58b2588f-d2e9-f492-47a2-b76eb2353ad2@hotmail.com>
Content-Description: after_status
Content-Disposition: attachment; filename=after_status

dWdlbjAuMTA6IDxUUC1MaW5rIFVTQiAxMC8xMDAvMTAwMCBMQU4+IGF0IHVzYnVzMCwgY2ZnPTAg
bWQ9SE9TVCBzcGQ9U1VQRVIgKDUuMEdicHMpIHB3cj1PTiAoNzJtQSkNCg0Kew0KICAgIFVFX0NP
TlRST0xfT0sgICAgICAgOiA0Mjc1DQogICAgVUVfSVNPQ0hST05PVVNfT0sgICA6IDANCiAgICBV
RV9CVUxLX09LICAgICAgICAgIDogMTEyNjcwMg0KICAgIFVFX0lOVEVSUlVQVF9PSyAgICAgOiAw
DQogICAgVUVfQ09OVFJPTF9GQUlMICAgICA6IDMyNg0KICAgIFVFX0lTT0NIUk9OT1VTX0ZBSUwg
OiAwDQogICAgVUVfQlVMS19GQUlMICAgICAgICA6IDQyDQogICAgVUVfSU5URVJSVVBUX0ZBSUwg
ICA6IDANCn0NCg0K

--3432851520-2064475307-1664281036=:2472
Content-Type: text/plain; charset=US-ASCII; name=before
Content-Transfer-Encoding: BASE64
Content-ID: <8d65c5dc-d397-462-f713-4485e23e853a@hotmail.com>
Content-Description: before
Content-Disposition: attachment; filename=before

dWdlbjAuMTA6IDxUUC1MaW5rIFVTQiAxMC8xMDAvMTAwMCBMQU4+IGF0IHVzYnVzMCwgY2ZnPTAg
bWQ9SE9TVCBzcGQ9U1VQRVIgKDUuMEdicHMpIHB3cj1PTiAoNzJtQSkNCnVnZW4wLjEwOiA8VFAt
TGluayBVU0IgMTAvMTAwLzEwMDAgTEFOPiBhdCB1c2J1czAsIGNmZz0wIG1kPUhPU1Qgc3BkPVNV
UEVSICg1LjBHYnBzKSBwd3I9T04gKDcybUEpDQoNCiAgYkxlbmd0aCA9IDB4MDAxMiANCiAgYkRl
c2NyaXB0b3JUeXBlID0gMHgwMDAxIA0KICBiY2RVU0IgPSAweDAzMDAgDQogIGJEZXZpY2VDbGFz
cyA9IDB4MDAwMCAgPFByb2JlZCBieSBpbnRlcmZhY2UgY2xhc3M+DQogIGJEZXZpY2VTdWJDbGFz
cyA9IDB4MDAwMCANCiAgYkRldmljZVByb3RvY29sID0gMHgwMDAwIA0KICBiTWF4UGFja2V0U2l6
ZTAgPSAweDAwMDkgDQogIGlkVmVuZG9yID0gMHgyMzU3IA0KICBpZFByb2R1Y3QgPSAweDA2MDEg
DQogIGJjZERldmljZSA9IDB4MzAwMCANCiAgaU1hbnVmYWN0dXJlciA9IDB4MDAwMSAgPFRQLUxp
bms+DQogIGlQcm9kdWN0ID0gMHgwMDAyICA8VVNCIDEwLzEwMC8xMDAwIExBTj4NCiAgaVNlcmlh
bE51bWJlciA9IDB4MDAwNiAgPDAwMDAwMT4NCiAgYk51bUNvbmZpZ3VyYXRpb25zID0gMHgwMDAy
IA0KDQogQ29uZmlndXJhdGlvbiBpbmRleCAwDQoNCiAgICBiTGVuZ3RoID0gMHgwMDA5IA0KICAg
IGJEZXNjcmlwdG9yVHlwZSA9IDB4MDAwMiANCiAgICB3VG90YWxMZW5ndGggPSAweDAwMzkgDQog
ICAgYk51bUludGVyZmFjZXMgPSAweDAwMDEgDQogICAgYkNvbmZpZ3VyYXRpb25WYWx1ZSA9IDB4
MDAwMSANCiAgICBpQ29uZmlndXJhdGlvbiA9IDB4MDAwMCAgPG5vIHN0cmluZz4NCiAgICBibUF0
dHJpYnV0ZXMgPSAweDAwYTAgDQogICAgYk1heFBvd2VyID0gMHgwMDI0IA0KDQogICAgSW50ZXJm
YWNlIDANCiAgICAgIGJMZW5ndGggPSAweDAwMDkgDQogICAgICBiRGVzY3JpcHRvclR5cGUgPSAw
eDAwMDQgDQogICAgICBiSW50ZXJmYWNlTnVtYmVyID0gMHgwMDAwIA0KICAgICAgYkFsdGVybmF0
ZVNldHRpbmcgPSAweDAwMDAgDQogICAgICBiTnVtRW5kcG9pbnRzID0gMHgwMDAzIA0KICAgICAg
YkludGVyZmFjZUNsYXNzID0gMHgwMGZmICA8VmVuZG9yIHNwZWNpZmljPg0KICAgICAgYkludGVy
ZmFjZVN1YkNsYXNzID0gMHgwMGZmIA0KICAgICAgYkludGVyZmFjZVByb3RvY29sID0gMHgwMDAw
IA0KICAgICAgaUludGVyZmFjZSA9IDB4MDAwMCAgPG5vIHN0cmluZz4NCg0KICAgICBFbmRwb2lu
dCAwDQogICAgICAgIGJMZW5ndGggPSAweDAwMDcgDQogICAgICAgIGJEZXNjcmlwdG9yVHlwZSA9
IDB4MDAwNSANCiAgICAgICAgYkVuZHBvaW50QWRkcmVzcyA9IDB4MDA4MSAgPElOPg0KICAgICAg
ICBibUF0dHJpYnV0ZXMgPSAweDAwMDIgIDxCVUxLPg0KICAgICAgICB3TWF4UGFja2V0U2l6ZSA9
IDB4MDQwMCANCiAgICAgICAgYkludGVydmFsID0gMHgwMDAwIA0KICAgICAgICBiUmVmcmVzaCA9
IDB4MDAwMCANCiAgICAgICAgYlN5bmNoQWRkcmVzcyA9IDB4MDAwMCANCg0KICAgICAgQWRkaXRp
b25hbCBEZXNjcmlwdG9yDQoNCiAgICAgIGJMZW5ndGggPSAweDA2DQogICAgICBiRGVzY3JpcHRv
clR5cGUgPSAweDMwDQogICAgICBiRGVzY3JpcHRvclN1YlR5cGUgPSAweDAzDQogICAgICAgUkFX
IGR1bXA6IA0KICAgICAgIDB4MDAgfCAweDA2LCAweDMwLCAweDAzLCAweDAwLCAweDAwLCAweDAw
DQoNCg0KICAgICBFbmRwb2ludCAxDQogICAgICAgIGJMZW5ndGggPSAweDAwMDcgDQogICAgICAg
IGJEZXNjcmlwdG9yVHlwZSA9IDB4MDAwNSANCiAgICAgICAgYkVuZHBvaW50QWRkcmVzcyA9IDB4
MDAwMiAgPE9VVD4NCiAgICAgICAgYm1BdHRyaWJ1dGVzID0gMHgwMDAyICA8QlVMSz4NCiAgICAg
ICAgd01heFBhY2tldFNpemUgPSAweDA0MDAgDQogICAgICAgIGJJbnRlcnZhbCA9IDB4MDAwMCAN
CiAgICAgICAgYlJlZnJlc2ggPSAweDAwMDAgDQogICAgICAgIGJTeW5jaEFkZHJlc3MgPSAweDAw
MDAgDQoNCiAgICAgIEFkZGl0aW9uYWwgRGVzY3JpcHRvcg0KDQogICAgICBiTGVuZ3RoID0gMHgw
Ng0KICAgICAgYkRlc2NyaXB0b3JUeXBlID0gMHgzMA0KICAgICAgYkRlc2NyaXB0b3JTdWJUeXBl
ID0gMHgwMw0KICAgICAgIFJBVyBkdW1wOiANCiAgICAgICAweDAwIHwgMHgwNiwgMHgzMCwgMHgw
MywgMHgwMCwgMHgwMCwgMHgwMA0KDQoNCiAgICAgRW5kcG9pbnQgMg0KICAgICAgICBiTGVuZ3Ro
ID0gMHgwMDA3IA0KICAgICAgICBiRGVzY3JpcHRvclR5cGUgPSAweDAwMDUgDQogICAgICAgIGJF
bmRwb2ludEFkZHJlc3MgPSAweDAwODMgIDxJTj4NCiAgICAgICAgYm1BdHRyaWJ1dGVzID0gMHgw
MDAzICA8SU5URVJSVVBUPg0KICAgICAgICB3TWF4UGFja2V0U2l6ZSA9IDB4MDAwMiANCiAgICAg
ICAgYkludGVydmFsID0gMHgwMDA4IA0KICAgICAgICBiUmVmcmVzaCA9IDB4MDAwMCANCiAgICAg
ICAgYlN5bmNoQWRkcmVzcyA9IDB4MDAwMCANCg0KICAgICAgQWRkaXRpb25hbCBEZXNjcmlwdG9y
DQoNCiAgICAgIGJMZW5ndGggPSAweDA2DQogICAgICBiRGVzY3JpcHRvclR5cGUgPSAweDMwDQog
ICAgICBiRGVzY3JpcHRvclN1YlR5cGUgPSAweDAwDQogICAgICAgUkFXIGR1bXA6IA0KICAgICAg
IDB4MDAgfCAweDA2LCAweDMwLCAweDAwLCAweDAwLCAweDAyLCAweDAwDQoNCg0KDQoNCiBDb25m
aWd1cmF0aW9uIGluZGV4IDENCg0KICAgIGJMZW5ndGggPSAweDAwMDkgDQogICAgYkRlc2NyaXB0
b3JUeXBlID0gMHgwMDAyIA0KICAgIHdUb3RhbExlbmd0aCA9IDB4MDA2MiANCiAgICBiTnVtSW50
ZXJmYWNlcyA9IDB4MDAwMiANCiAgICBiQ29uZmlndXJhdGlvblZhbHVlID0gMHgwMDAyIA0KICAg
IGlDb25maWd1cmF0aW9uID0gMHgwMDAwICA8bm8gc3RyaW5nPg0KICAgIGJtQXR0cmlidXRlcyA9
IDB4MDBhMCANCiAgICBiTWF4UG93ZXIgPSAweDAwMjQgDQoNCiAgICBJbnRlcmZhY2UgMA0KICAg
ICAgYkxlbmd0aCA9IDB4MDAwOSANCiAgICAgIGJEZXNjcmlwdG9yVHlwZSA9IDB4MDAwNCANCiAg
ICAgIGJJbnRlcmZhY2VOdW1iZXIgPSAweDAwMDAgDQogICAgICBiQWx0ZXJuYXRlU2V0dGluZyA9
IDB4MDAwMCANCiAgICAgIGJOdW1FbmRwb2ludHMgPSAweDAwMDEgDQogICAgICBiSW50ZXJmYWNl
Q2xhc3MgPSAweDAwMDIgIDxDb21tdW5pY2F0aW9uIGRldmljZT4NCiAgICAgIGJJbnRlcmZhY2VT
dWJDbGFzcyA9IDB4MDAwNiANCiAgICAgIGJJbnRlcmZhY2VQcm90b2NvbCA9IDB4MDAwMCANCiAg
ICAgIGlJbnRlcmZhY2UgPSAweDAwMDUgIDxDREMgQ29tbXVuaWNhdGlvbnMgQ29udHJvbD4NCg0K
ICAgICAgQWRkaXRpb25hbCBEZXNjcmlwdG9yDQoNCiAgICAgIGJMZW5ndGggPSAweDA1DQogICAg
ICBiRGVzY3JpcHRvclR5cGUgPSAweDI0DQogICAgICBiRGVzY3JpcHRvclN1YlR5cGUgPSAweDAw
DQogICAgICAgUkFXIGR1bXA6IA0KICAgICAgIDB4MDAgfCAweDA1LCAweDI0LCAweDAwLCAweDEw
LCAweDAxDQoNCg0KICAgICAgQWRkaXRpb25hbCBEZXNjcmlwdG9yDQoNCiAgICAgIGJMZW5ndGgg
PSAweDA1DQogICAgICBiRGVzY3JpcHRvclR5cGUgPSAweDI0DQogICAgICBiRGVzY3JpcHRvclN1
YlR5cGUgPSAweDA2DQogICAgICAgUkFXIGR1bXA6IA0KICAgICAgIDB4MDAgfCAweDA1LCAweDI0
LCAweDA2LCAweDAwLCAweDAxDQoNCg0KICAgICAgQWRkaXRpb25hbCBEZXNjcmlwdG9yDQoNCiAg
ICAgIGJMZW5ndGggPSAweDBkDQogICAgICBiRGVzY3JpcHRvclR5cGUgPSAweDI0DQogICAgICBi
RGVzY3JpcHRvclN1YlR5cGUgPSAweDBmDQogICAgICAgUkFXIGR1bXA6IA0KICAgICAgIDB4MDAg
fCAweDBkLCAweDI0LCAweDBmLCAweDAzLCAweDAwLCAweDAwLCAweDAwLCAweDAwLCANCiAgICAg
ICAweDA4IHwgMHhlYSwgMHgwNSwgMHgwMCwgMHgwMCwgMHgwMA0KDQoNCiAgICAgRW5kcG9pbnQg
MA0KICAgICAgICBiTGVuZ3RoID0gMHgwMDA3IA0KICAgICAgICBiRGVzY3JpcHRvclR5cGUgPSAw
eDAwMDUgDQogICAgICAgIGJFbmRwb2ludEFkZHJlc3MgPSAweDAwODMgIDxJTj4NCiAgICAgICAg
Ym1BdHRyaWJ1dGVzID0gMHgwMDAzICA8SU5URVJSVVBUPg0KICAgICAgICB3TWF4UGFja2V0U2l6
ZSA9IDB4MDAxMCANCiAgICAgICAgYkludGVydmFsID0gMHgwMDA4IA0KICAgICAgICBiUmVmcmVz
aCA9IDB4MDAwMCANCiAgICAgICAgYlN5bmNoQWRkcmVzcyA9IDB4MDAwMCANCg0KICAgICAgQWRk
aXRpb25hbCBEZXNjcmlwdG9yDQoNCiAgICAgIGJMZW5ndGggPSAweDA2DQogICAgICBiRGVzY3Jp
cHRvclR5cGUgPSAweDMwDQogICAgICBiRGVzY3JpcHRvclN1YlR5cGUgPSAweDAwDQogICAgICAg
UkFXIGR1bXA6IA0KICAgICAgIDB4MDAgfCAweDA2LCAweDMwLCAweDAwLCAweDAwLCAweDA4LCAw
eDAwDQoNCg0KDQogICAgSW50ZXJmYWNlIDENCiAgICAgIGJMZW5ndGggPSAweDAwMDkgDQogICAg
ICBiRGVzY3JpcHRvclR5cGUgPSAweDAwMDQgDQogICAgICBiSW50ZXJmYWNlTnVtYmVyID0gMHgw
MDAxIA0KICAgICAgYkFsdGVybmF0ZVNldHRpbmcgPSAweDAwMDAgDQogICAgICBiTnVtRW5kcG9p
bnRzID0gMHgwMDAwIA0KICAgICAgYkludGVyZmFjZUNsYXNzID0gMHgwMDBhICA8Q0RDLWRhdGE+
DQogICAgICBiSW50ZXJmYWNlU3ViQ2xhc3MgPSAweDAwMDAgDQogICAgICBiSW50ZXJmYWNlUHJv
dG9jb2wgPSAweDAwMDAgDQogICAgICBpSW50ZXJmYWNlID0gMHgwMDAwICA8bm8gc3RyaW5nPg0K
DQoNCiAgICBJbnRlcmZhY2UgMSBBbHQgMQ0KICAgICAgYkxlbmd0aCA9IDB4MDAwOSANCiAgICAg
IGJEZXNjcmlwdG9yVHlwZSA9IDB4MDAwNCANCiAgICAgIGJJbnRlcmZhY2VOdW1iZXIgPSAweDAw
MDEgDQogICAgICBiQWx0ZXJuYXRlU2V0dGluZyA9IDB4MDAwMSANCiAgICAgIGJOdW1FbmRwb2lu
dHMgPSAweDAwMDIgDQogICAgICBiSW50ZXJmYWNlQ2xhc3MgPSAweDAwMGEgIDxDREMtZGF0YT4N
CiAgICAgIGJJbnRlcmZhY2VTdWJDbGFzcyA9IDB4MDAwMCANCiAgICAgIGJJbnRlcmZhY2VQcm90
b2NvbCA9IDB4MDAwMCANCiAgICAgIGlJbnRlcmZhY2UgPSAweDAwMDQgIDxFdGhlcm5ldCBEYXRh
Pg0KDQogICAgIEVuZHBvaW50IDANCiAgICAgICAgYkxlbmd0aCA9IDB4MDAwNyANCiAgICAgICAg
YkRlc2NyaXB0b3JUeXBlID0gMHgwMDA1IA0KICAgICAgICBiRW5kcG9pbnRBZGRyZXNzID0gMHgw
MDgxICA8SU4+DQogICAgICAgIGJtQXR0cmlidXRlcyA9IDB4MDAwMiAgPEJVTEs+DQogICAgICAg
IHdNYXhQYWNrZXRTaXplID0gMHgwNDAwIA0KICAgICAgICBiSW50ZXJ2YWwgPSAweDAwMDAgDQog
ICAgICAgIGJSZWZyZXNoID0gMHgwMDAwIA0KICAgICAgICBiU3luY2hBZGRyZXNzID0gMHgwMDAw
IA0KDQogICAgICBBZGRpdGlvbmFsIERlc2NyaXB0b3INCg0KICAgICAgYkxlbmd0aCA9IDB4MDYN
CiAgICAgIGJEZXNjcmlwdG9yVHlwZSA9IDB4MzANCiAgICAgIGJEZXNjcmlwdG9yU3ViVHlwZSA9
IDB4MDMNCiAgICAgICBSQVcgZHVtcDogDQogICAgICAgMHgwMCB8IDB4MDYsIDB4MzAsIDB4MDMs
IDB4MDAsIDB4MDAsIDB4MDANCg0KDQogICAgIEVuZHBvaW50IDENCiAgICAgICAgYkxlbmd0aCA9
IDB4MDAwNyANCiAgICAgICAgYkRlc2NyaXB0b3JUeXBlID0gMHgwMDA1IA0KICAgICAgICBiRW5k
cG9pbnRBZGRyZXNzID0gMHgwMDAyICA8T1VUPg0KICAgICAgICBibUF0dHJpYnV0ZXMgPSAweDAw
MDIgIDxCVUxLPg0KICAgICAgICB3TWF4UGFja2V0U2l6ZSA9IDB4MDQwMCANCiAgICAgICAgYklu
dGVydmFsID0gMHgwMDAwIA0KICAgICAgICBiUmVmcmVzaCA9IDB4MDAwMCANCiAgICAgICAgYlN5
bmNoQWRkcmVzcyA9IDB4MDAwMCANCg0KICAgICAgQWRkaXRpb25hbCBEZXNjcmlwdG9yDQoNCiAg
ICAgIGJMZW5ndGggPSAweDA2DQogICAgICBiRGVzY3JpcHRvclR5cGUgPSAweDMwDQogICAgICBi
RGVzY3JpcHRvclN1YlR5cGUgPSAweDAzDQogICAgICAgUkFXIGR1bXA6IA0KICAgICAgIDB4MDAg
fCAweDA2LCAweDMwLCAweDAzLCAweDAwLCAweDAwLCAweDAwDQoNCg0KDQoNCg==

--3432851520-2064475307-1664281036=:2472
Content-Type: text/plain; charset=US-ASCII; name=before_status
Content-Transfer-Encoding: BASE64
Content-ID: 
Content-Description: before_status
Content-Disposition: attachment; filename=before_status

dWdlbjAuMTA6IDxUUC1MaW5rIFVTQiAxMC8xMDAvMTAwMCBMQU4+IGF0IHVzYnVzMCwgY2ZnPTAg
bWQ9SE9TVCBzcGQ9U1VQRVIgKDUuMEdicHMpIHB3cj1PTiAoNzJtQSkNCg0Kew0KICAgIFVFX0NP
TlRST0xfT0sgICAgICAgOiAyMzg5DQogICAgVUVfSVNPQ0hST05PVVNfT0sgICA6IDANCiAgICBV
RV9CVUxLX09LICAgICAgICAgIDogODAzDQogICAgVUVfSU5URVJSVVBUX09LICAgICA6IDANCiAg
ICBVRV9DT05UUk9MX0ZBSUwgICAgIDogMA0KICAgIFVFX0lTT0NIUk9OT1VTX0ZBSUwgOiAwDQog
ICAgVUVfQlVMS19GQUlMICAgICAgICA6IDANCiAgICBVRV9JTlRFUlJVUFRfRkFJTCAgIDogMA0K
fQ0KDQo=

--3432851520-2064475307-1664281036=:2472--

From nobody Tue Sep 27 13:22:50 2022
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 4McL0Q5nXSz4d0P2;
	Tue, 27 Sep 2022 13:23:02 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4McL0P66r0z3SMw;
	Tue, 27 Sep 2022 13:23:01 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id B5418260160;
	Tue, 27 Sep 2022 15:22:53 +0200 (CEST)
Message-ID: <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org>
Date: Tue, 27 Sep 2022 15:22:50 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: RES: TP-LINK USB no carrier after speed test
To: Ivan Quitschal 
Cc: Alexander Motin ,
 "freebsd-current@freebsd.org" ,
 "freebsd-usb@FreeBSD.org" 
References: 
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
 
 
 <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
 
 <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org>
 
Content-Language: en-US
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4McL0P66r0z3SMw
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.21 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.91)[-0.905];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[hotmail.com];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[selasky.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/27/22 14:17, Ivan Quitschal wrote:
> 
> 
> On Tue, 27 Sep 2022, Hans Petter Selasky wrote:
> 
>> On 9/27/22 02:24, Alexander Motin wrote:
>>> On 26.09.2022 17:29, Hans Petter Selasky wrote:
>>>> I've got a supposedly "broken" if_ure dongle from Alexander, but I'm 
>>>> unable to reproduce the if_ure hang on two different pieces of XHCI 
>>>> hardware, Intel based and AMD based, which I've got.
>>>>
>>>> This leads me to believe there is a bug in the XHCI driver or 
>>>> hardware on your system.
>>>>
>>>> Can you share the pciconfig -lv output for your XHCI controllers?
>>>
>>> I have two laptops of different generations reproducing this problem, 
>>> but both are having Thunderbolt on the USB-C ports:
>>>
>>> This is one (7th Gen Core i7):
>>>
>>> xhci1@pci0:56:0:0:      class=0x0c0330 rev=0x02 hdr=0x00 
>>> vendor=0x8086 device=0x15d4 subvendor=0x2222 subdevice=0x1111
>>>      vendor     = 'Intel Corporation'
>>>      device     = 'JHL6540 Thunderbolt 3 USB Controller (C step) 
>>> [Alpine Ridge 4C 2016]'
>>>      class      = serial bus
>>>      subclass   = USB
>>>      bar   [10] = type Memory, range 32, base 0xc3f00000, size 65536, 
>>> enabled
>>>      cap 01[80] = powerspec 3  supports D0 D1 D2 D3  current D0
>>>      cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 message
>>>      cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS
>>>                   max read 512
>>>                   link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) 
>>> ClockPM disabled
>>>      ecap 0003[100] = Serial 1 20ff910876f10c00
>>>      ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected
>>>      ecap 0002[300] = VC 1 max VC0
>>>      ecap 0004[400] = Power Budgeting 1
>>>      ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216
>>>      ecap 0018[600] = LTR 1
>>>      ecap 0019[700] = PCIe Sec 1 lane errors 0
>>>
>>> This is another (11th Gen Core i7);
>>>
>>> xhci0@pci0:0:13:0:      class=0x0c0330 rev=0x01 hdr=0x00 
>>> vendor=0x8086 device=0x9a13 subvendor=0x1028 subdevice=0x0991
>>>      vendor     = 'Intel Corporation'
>>>      device     = 'Tiger Lake-LP Thunderbolt 4 USB Controller'
>>>      class      = serial bus
>>>      subclass   = USB
>>>      bar   [10] = type Memory, range 64, base 0x60552c0000, size 
>>> 65536, enabled
>>>      cap 01[70] = powerspec 2  supports D0 D3  current D0
>>>      cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message
>>>      cap 09[90] = vendor (length 20) Intel cap 15 version 0
>>>      cap 09[b0] = vendor (length 0) Intel cap 0 version 1
>>>
>>> Does the system you also has Thunderbolt chip, or you use native 
>>> Intel chipet's XHCI?
>>>
>>>> Also, when running the stress test and you see the traffic stops, 
>>>> what happens if you run this command as root on the ugen which the 
>>>> if_ure belongs to:
>>>>
>>>> usbconfig -d ugenX.Y dump_string 0
>>>>
>>>> Does the traffic resume?
>>>
>>> Nope. Out of 4 times when traffic stopped 2 times it reported >> error> and 2 times it completed successfully, but it neither case it 
>>> recovered traffic.  Only reset recovered it.
>>>
>>
>> Hi Alexander,
>>
>> Could you run "usbdump -d X.Y" at the same time to capture all the 
>> errors?
>>
>> Looking especially for USB_ERR_TIMEOUT .
>>
>> I have this:
>>
>> xhci0@pci0:3:0:3:    class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 
>> device=0x15e0 subvendor=0x1849 subdevice=0xffff
>>    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
>>    device     = 'Raven USB 3.1'
>>    class      = serial bus
>>    subclass   = USB
>>
>> xhci0@pci0:0:20:0:    class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086 
>> device=0x9d2f subvendor=0x8086 subdevice=0x9d2f
>>    vendor     = 'Intel Corporation'
>>    device     = 'Sunrise Point-LP USB 3.0 xHCI Controller'
>>    class      = serial bus
>>    subclass   = USB
>>
>> --HPS
>>
> 
> 
> hi Hans
> 
> i think i got some good logs for you
> 
> before the problem i ran this:
> 
> ugen0.10:  at usbus0, cfg=0 md=HOST 
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
> 
> # usbconfig -d ugen0.10 >> before
> # usbconfig -d ugen0.10 dump_all_desc >> before
> # usbconfig -d ugen0.10 dump_stats >> before_status
> 
> the after the problem happened i ran
> 
> # usbconfig -d ugen0.10 >> after
> # usbconfig -d ugen0.10 dump_all_desc >> after
> # usbconfig -d ugen0.10 dump_stats >> after_status
> 
> 
> just by looking i already see some problems comparing both
> 
> for example
> 
> before the problem we have:
> 
> ----------------------
> ugen0.10:  at usbus0, cfg=0 md=HOST 
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
> ugen0.10:  at usbus0, cfg=0 md=HOST 
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
> 
>    bLength = 0x0012
>    bDescriptorType = 0x0001
>    bcdUSB = 0x0300
>    bDeviceClass = 0x0000  
>    bDeviceSubClass = 0x0000
>    bDeviceProtocol = 0x0000
>    bMaxPacketSize0 = 0x0009
>    idVendor = 0x2357
>    idProduct = 0x0601
>    bcdDevice = 0x3000
> ****
>    iManufacturer = 0x0001  
>    iProduct = 0x0002  
>    iSerialNumber = 0x0006  <000001>
>    bNumConfigurations = 0x0002
> 
> ------------------------
> 
> after the problem
> 
> --------------------------
> ugen0.10:  at usbus0, cfg=0 md=HOST 
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
> ugen0.10:  at usbus0, cfg=0 md=HOST 
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
> 
>    bLength = 0x0012
>    bDescriptorType = 0x0001
>    bcdUSB = 0x0300
>    bDeviceClass = 0x0000  
>    bDeviceSubClass = 0x0000
>    bDeviceProtocol = 0x0000
>    bMaxPacketSize0 = 0x0009
>    idVendor = 0x2357
>    idProduct = 0x0601
>    bcdDevice = 0x3000
> ****
> iManufacturer = 0x0001  
>    iProduct = 0x0002  
>    iSerialNumber = 0x0006  
>    bNumConfigurations = 0x0002
> 
>   Configuration index 0 --------------------------
> 
> 
> the log in ttyv0 was this:
> 
> ure0: at uhub0, port 14, addr 9 (disconnected)
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: receive_packet failed on 
> ue0: Device not configured
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: ioctl(SIOCGIFFLAGS) on ue0: 
> Operation not permitted
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: Interface ue0 no longer 
> appears valid.
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: No live interfaces to poll 
> on - exiting.
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: connection closed
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
> rgephy0: detached
> miibus0: detached
> ure0: detached
> 
> 
> difference between before_status and after_status
> 
> before_status:
> 
> ugen0.10:  at usbus0, cfg=0 md=HOST 
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
> 
> {
>      UE_CONTROL_OK       : 2389
>      UE_ISOCHRONOUS_OK   : 0
>      UE_BULK_OK          : 803
>      UE_INTERRUPT_OK     : 0
>      UE_CONTROL_FAIL     : 0
>      UE_ISOCHRONOUS_FAIL : 0
>      UE_BULK_FAIL        : 0
>      UE_INTERRUPT_FAIL   : 0
> }
> 
> 
> after_status:
> 
> ugen0.10:  at usbus0, cfg=0 md=HOST 
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
> 
> {
>      UE_CONTROL_OK       : 4275
>      UE_ISOCHRONOUS_OK   : 0
>      UE_BULK_OK          : 1126702
>      UE_INTERRUPT_OK     : 0
>      UE_CONTROL_FAIL     : 326
>      UE_ISOCHRONOUS_FAIL : 0
>      UE_BULK_FAIL        : 42
>      UE_INTERRUPT_FAIL   : 0
> }
> 
> 
> 
> i hope that helps
> 
> 
> all log files are attached
> 
> thanks
> 
> --tzk


One more test request:

Make sure you have a kernel with "options USB_DEBUG".

Then after "iperf" says 0bits/s, then you run:

sysctl hw.usb.xhci.debug=29

Then run those usbconfig commands.

Then then:

sysctl hw.usb.xhci.debug=0

And collect the logs from /var/log/messages .

Like said earlier, I wonder if the fault is in the XHCI controller 
itself or something that has to do with thunderbolt, because on my 
machine there is no indication of a if_ure device failure. The only way 
to know for sure is to buy a USB 3.0 wire analyzer, like the beagle one, 
but I'm unsure if they support USB-C .

Thank you!

--HPS

From nobody Tue Sep 27 18:17:54 2022
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 4McSXn3Sn7z4YMZ7;
	Tue, 27 Sep 2022 18:18:01 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4McSXm2lRdz41KZ;
	Tue, 27 Sep 2022 18:18:00 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id DA307260160;
	Tue, 27 Sep 2022 20:17:57 +0200 (CEST)
Message-ID: <37d15b0a-0cc1-0830-98a9-c7e19b7a7ef5@selasky.org>
Date: Tue, 27 Sep 2022 20:17:54 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: RES: TP-LINK USB no carrier after speed test
From: Hans Petter Selasky 
To: Ivan Quitschal 
Cc: Alexander Motin ,
 "freebsd-current@freebsd.org" ,
 "freebsd-usb@FreeBSD.org" 
References: 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
 
 
 <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
 
 <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org>
 
 <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org>
Content-Language: en-US
In-Reply-To: <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4McSXm2lRdz41KZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.26 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.96)[-0.964];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[hotmail.com];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[selasky.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/27/22 15:22, Hans Petter Selasky wrote:
> On 9/27/22 14:17, Ivan Quitschal wrote:
>>
>>
>> On Tue, 27 Sep 2022, Hans Petter Selasky wrote:
>>
>>> On 9/27/22 02:24, Alexander Motin wrote:
>>>> On 26.09.2022 17:29, Hans Petter Selasky wrote:
>>>>> I've got a supposedly "broken" if_ure dongle from Alexander, but 
>>>>> I'm unable to reproduce the if_ure hang on two different pieces of 
>>>>> XHCI hardware, Intel based and AMD based, which I've got.
>>>>>
>>>>> This leads me to believe there is a bug in the XHCI driver or 
>>>>> hardware on your system.
>>>>>
>>>>> Can you share the pciconfig -lv output for your XHCI controllers?
>>>>
>>>> I have two laptops of different generations reproducing this 
>>>> problem, but both are having Thunderbolt on the USB-C ports:
>>>>
>>>> This is one (7th Gen Core i7):
>>>>
>>>> xhci1@pci0:56:0:0:      class=0x0c0330 rev=0x02 hdr=0x00 
>>>> vendor=0x8086 device=0x15d4 subvendor=0x2222 subdevice=0x1111
>>>>      vendor     = 'Intel Corporation'
>>>>      device     = 'JHL6540 Thunderbolt 3 USB Controller (C step) 
>>>> [Alpine Ridge 4C 2016]'
>>>>      class      = serial bus
>>>>      subclass   = USB
>>>>      bar   [10] = type Memory, range 32, base 0xc3f00000, size 
>>>> 65536, enabled
>>>>      cap 01[80] = powerspec 3  supports D0 D1 D2 D3  current D0
>>>>      cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 
>>>> message
>>>>      cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS
>>>>                   max read 512
>>>>                   link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) 
>>>> ClockPM disabled
>>>>      ecap 0003[100] = Serial 1 20ff910876f10c00
>>>>      ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected
>>>>      ecap 0002[300] = VC 1 max VC0
>>>>      ecap 0004[400] = Power Budgeting 1
>>>>      ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216
>>>>      ecap 0018[600] = LTR 1
>>>>      ecap 0019[700] = PCIe Sec 1 lane errors 0
>>>>
>>>> This is another (11th Gen Core i7);
>>>>
>>>> xhci0@pci0:0:13:0:      class=0x0c0330 rev=0x01 hdr=0x00 
>>>> vendor=0x8086 device=0x9a13 subvendor=0x1028 subdevice=0x0991
>>>>      vendor     = 'Intel Corporation'
>>>>      device     = 'Tiger Lake-LP Thunderbolt 4 USB Controller'
>>>>      class      = serial bus
>>>>      subclass   = USB
>>>>      bar   [10] = type Memory, range 64, base 0x60552c0000, size 
>>>> 65536, enabled
>>>>      cap 01[70] = powerspec 2  supports D0 D3  current D0
>>>>      cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 
>>>> message
>>>>      cap 09[90] = vendor (length 20) Intel cap 15 version 0
>>>>      cap 09[b0] = vendor (length 0) Intel cap 0 version 1
>>>>
>>>> Does the system you also has Thunderbolt chip, or you use native 
>>>> Intel chipet's XHCI?
>>>>
>>>>> Also, when running the stress test and you see the traffic stops, 
>>>>> what happens if you run this command as root on the ugen which the 
>>>>> if_ure belongs to:
>>>>>
>>>>> usbconfig -d ugenX.Y dump_string 0
>>>>>
>>>>> Does the traffic resume?
>>>>
>>>> Nope. Out of 4 times when traffic stopped 2 times it reported >>> error> and 2 times it completed successfully, but it neither case it 
>>>> recovered traffic.  Only reset recovered it.
>>>>
>>>
>>> Hi Alexander,
>>>
>>> Could you run "usbdump -d X.Y" at the same time to capture all the 
>>> errors?
>>>
>>> Looking especially for USB_ERR_TIMEOUT .
>>>
>>> I have this:
>>>
>>> xhci0@pci0:3:0:3:    class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 
>>> device=0x15e0 subvendor=0x1849 subdevice=0xffff
>>>    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
>>>    device     = 'Raven USB 3.1'
>>>    class      = serial bus
>>>    subclass   = USB
>>>
>>> xhci0@pci0:0:20:0:    class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086 
>>> device=0x9d2f subvendor=0x8086 subdevice=0x9d2f
>>>    vendor     = 'Intel Corporation'
>>>    device     = 'Sunrise Point-LP USB 3.0 xHCI Controller'
>>>    class      = serial bus
>>>    subclass   = USB
>>>
>>> --HPS
>>>
>>
>>
>> hi Hans
>>
>> i think i got some good logs for you
>>
>> before the problem i ran this:
>>
>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>
>> # usbconfig -d ugen0.10 >> before
>> # usbconfig -d ugen0.10 dump_all_desc >> before
>> # usbconfig -d ugen0.10 dump_stats >> before_status
>>
>> the after the problem happened i ran
>>
>> # usbconfig -d ugen0.10 >> after
>> # usbconfig -d ugen0.10 dump_all_desc >> after
>> # usbconfig -d ugen0.10 dump_stats >> after_status
>>
>>
>> just by looking i already see some problems comparing both
>>
>> for example
>>
>> before the problem we have:
>>
>> ----------------------
>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>
>>    bLength = 0x0012
>>    bDescriptorType = 0x0001
>>    bcdUSB = 0x0300
>>    bDeviceClass = 0x0000  
>>    bDeviceSubClass = 0x0000
>>    bDeviceProtocol = 0x0000
>>    bMaxPacketSize0 = 0x0009
>>    idVendor = 0x2357
>>    idProduct = 0x0601
>>    bcdDevice = 0x3000
>> ****
>>    iManufacturer = 0x0001  
>>    iProduct = 0x0002  
>>    iSerialNumber = 0x0006  <000001>
>>    bNumConfigurations = 0x0002
>>
>> ------------------------
>>
>> after the problem
>>
>> --------------------------
>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>
>>    bLength = 0x0012
>>    bDescriptorType = 0x0001
>>    bcdUSB = 0x0300
>>    bDeviceClass = 0x0000  
>>    bDeviceSubClass = 0x0000
>>    bDeviceProtocol = 0x0000
>>    bMaxPacketSize0 = 0x0009
>>    idVendor = 0x2357
>>    idProduct = 0x0601
>>    bcdDevice = 0x3000
>> ****
>> iManufacturer = 0x0001  
>>    iProduct = 0x0002  
>>    iSerialNumber = 0x0006  
>>    bNumConfigurations = 0x0002
>>
>>   Configuration index 0 --------------------------
>>
>>
>> the log in ttyv0 was this:
>>
>> ure0: at uhub0, port 14, addr 9 (disconnected)
>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: receive_packet failed on 
>> ue0: Device not configured
>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: ioctl(SIOCGIFFLAGS) on 
>> ue0: Operation not permitted
>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: Interface ue0 no longer 
>> appears valid.
>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: No live interfaces to 
>> poll on - exiting.
>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: connection closed
>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
>> rgephy0: detached
>> miibus0: detached
>> ure0: detached
>>
>>
>> difference between before_status and after_status
>>
>> before_status:
>>
>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>
>> {
>>      UE_CONTROL_OK       : 2389
>>      UE_ISOCHRONOUS_OK   : 0
>>      UE_BULK_OK          : 803
>>      UE_INTERRUPT_OK     : 0
>>      UE_CONTROL_FAIL     : 0
>>      UE_ISOCHRONOUS_FAIL : 0
>>      UE_BULK_FAIL        : 0
>>      UE_INTERRUPT_FAIL   : 0
>> }
>>
>>
>> after_status:
>>
>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>
>> {
>>      UE_CONTROL_OK       : 4275
>>      UE_ISOCHRONOUS_OK   : 0
>>      UE_BULK_OK          : 1126702
>>      UE_INTERRUPT_OK     : 0
>>      UE_CONTROL_FAIL     : 326
>>      UE_ISOCHRONOUS_FAIL : 0
>>      UE_BULK_FAIL        : 42
>>      UE_INTERRUPT_FAIL   : 0
>> }
>>
>>
>>
>> i hope that helps
>>
>>
>> all log files are attached
>>
>> thanks
>>
>> --tzk
> 
> 
> One more test request:
> 
> Make sure you have a kernel with "options USB_DEBUG".
> 
> Then after "iperf" says 0bits/s, then you run:
> 
> sysctl hw.usb.xhci.debug=29
> 
> Then run those usbconfig commands.
> 
> Then then:
> 
> sysctl hw.usb.xhci.debug=0
> 
> And collect the logs from /var/log/messages .
> 
> Like said earlier, I wonder if the fault is in the XHCI controller 
> itself or something that has to do with thunderbolt, because on my 
> machine there is no indication of a if_ure device failure. The only way 
> to know for sure is to buy a USB 3.0 wire analyzer, like the beagle one, 
> but I'm unsure if they support USB-C .
> 
> Thank you!
> 
> --HPS
> 

FYI: There is some experimental thunderbolt support at:

https://github.com/hselasky/usb4

But I'm not sure if it supports the hardware you've got.

--HPS

From nobody Wed Sep 28 09:10:45 2022
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 4McrLx6llTz4d6Rv;
	Wed, 28 Sep 2022 09:10:49 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2048.outbound.protection.outlook.com [40.92.96.48])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4McrLx0Jh5z43Ty;
	Wed, 28 Sep 2022 09:10:49 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=jNZ1uav1YKC0xAX9a5kNGNzRzSG6z9/Q7vq0msMxaEhCPf4Oqy5VSKY19X4Drq8S1X7u2yM8q8Y9n+EGEMNDe68gUyzB2jP+VopYpZyea3ZxMdP4gfCFydz8iekjYs1Wk2EG/DjDZFuMSYzIKXPiocMN0kYsycUwCCycP92C8xqv78k1TCXcrfjU2auEb5FdbsS5PwszIChMzxxOgKlThLJ43YOcTa645SDYyiiSaaNhUpwNovPAZIJvgl2ntz1CYNIldZoH/EtmF7npCdiEoqVoLbdhMdpOcqtsrLoUDkuL1R5pd8xjnZCh/mGXFiowDvIChXPpxaB+yLsFbEnkAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=AV5cNqSmHtkbYqxKMen0/1u+74sfv/Tgp7P9Q8Cikso=;
 b=l4zaYsYKzm7l0u/nOCDb9uqYfdGDvjkmwhGqjYEksJhOjvCce8DQq7bPTduSC+XJOlIifaSO6WMseOZ8SLur1gdEJ67J3cdqQZSLnd3sVGprj+TsQqtxafPz/mlrBCqgNSEDhCqG6c10cIwwhJoCKdcoD4wgeRWZHR/ii1rmM3uIMUJOeufCncmyRmIIZIK6S9bNnD9hI9PL9vppzfyc7/9yhzvr5dwOr4mxR4xQjo0R3RLOfm+nubAyVqCA44HAlzu9FwOLhu+y26nRQzvZ7elPGBDVt7wl0thCAQhfufje2FzgruiPafKRma9eRmo8Qh1fkzKC6DRrQLHxk+Ldjg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=AV5cNqSmHtkbYqxKMen0/1u+74sfv/Tgp7P9Q8Cikso=;
 b=B9h0N/YUo8MSbe1LRTw2z6TROoVqOzeWNSJXDAWSaiVXP76tASkLGSrSfMVzcqhWcSMsFcCdSa5ofgfs1YzQlrYoY6qVYCRuW4id5XWWLgQ2OBsVUSIAqEbM5TviWKTdL1EhsIwrHeZBTIzlExGBh+ngmvbAYg3ha6oj+nIPUdT6MskNk5n8qSiwlYz3BUR+YjG94a6MU1Xp7nbJ7tfvy/tog8ZtJox2Hd0t/qcagh69KABOiO00zLPFE2cBB8azSrLsQq3AU+ofXFXU/nV8NVZusT6q7VUnIuzx7YdzQo4Zsat9u5CsJLeTgzTDryUMXoHXw0CMg18xAi1F/Z+oqw==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CP4P284MB1844.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:dd::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.14; Wed, 28 Sep
 2022 09:10:45 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79%7]) with mapi id 15.20.5654.025; Wed, 28 Sep 2022
 09:10:45 +0000
From: Ivan Quitschal 
To: Hans Petter Selasky 
CC: Alexander Motin , "freebsd-current@freebsd.org"
	, "freebsd-usb@FreeBSD.org"
	
Subject: RES: RES: TP-LINK USB no carrier after speed test
Thread-Topic: RES: TP-LINK USB no carrier after speed test
Thread-Index:
 AQHYyRYh90zfGba+7EWJS9V+b+FDta3gmrWAgAABUgCAAALNAIAAAPyAgAD2/ICAAAOngIAAAU8AgABe+YCAABa8gIAADhYQgAABrQCAAAlGAIAC7OyAgAHiugCACtKXAIAANxqAgAAmZwCAACGnAIAAMNkAgABz6QCAAFNPAIAAElkAgABScACAAPkaMA==
Date: Wed, 28 Sep 2022 09:10:45 +0000
Message-ID:
 
References:
 
 <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org>
 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
 
 
 <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
 
 <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org>
 
 <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org>
 <37d15b0a-0cc1-0830-98a9-c7e19b7a7ef5@selasky.org>
In-Reply-To: <37d15b0a-0cc1-0830-98a9-c7e19b7a7ef5@selasky.org>
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [BiFWNv0P8ER5cidOZnjYp3T99WU67nafOyWSKqBY9gm/xTxmW+oeIzpXKhrCz27D]
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CP6P284MB1900:EE_|CP4P284MB1844:EE_
x-ms-office365-filtering-correlation-id: 96740ca6-ba01-4e03-6979-08daa131536c
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 JHczUqaSxGHQERvFzSbIH8cTdYfyJwq1YoJJ8c5WlGPcTwliwkc/u15F70uE94ZliTSf7fy3njz6GsjMHNBTP7MxHPVeZCa3KsigWIlPMyaTWAHa8r1RpnD8HRy/h4Qr3cq5S2ftWDBQp1hIDyDr5Y2nRufRtCgAYIwp6gX8IEtv/wGFuTaEVkLPQQWT9tArAfIWl3icniAc+B+FtJke4xidnOu+avK3rekeQNVmBC5pwGld8j4EoL2WodzdyPwPQl61dUFNrUDox6GOwAgFJxFm1qitgJo5MR96lT6WMH10b3lOu9vo7+U+1Yc1mB4QGdZhCMbsoQFkEXU7t5FBVHZqcLP5fKL12t82eFB3pGIJOqKe++hbDNFzaESRRna8R4w3rnvoTDXCJq0sTZQ+eCWT+Bg9c3cqPBFDuSMhJL+RWhGqaHsMIq6gJDDTxMe2QjOY0PoyW5bt4i5dzVm5nZ9KhshGWZyjuoIDsc/bRw6L0EKre53lBQgOqmDBbGq4LqwJPopiULv+DAaeoLAMjxxd4iU0ZMr7QYCYHsgu+jK2Rvii4sdqz33+s3lrQNirTLyRUOVwAQYF3IkN+4d2451CDVLyx+FnZGhzZjNUzT6CrRju7NvhnkYJzfpM703t
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?PiamZ2ioVVVjEAm6waNgLJzIeQPOSwdCkDvF6Hz06yAQXrDv7Kjq9b6+fc1R?=
 =?us-ascii?Q?ny/GsYFp91PDzj3zUpopIpIPITu8muAZAz+pv3hcM0hORK4G+ME82E9DJ5ku?=
 =?us-ascii?Q?EeOdrpONjXQQByG0EQnw+vOyS3qol1kVDcnfCwDcpXhbUxH6YyuhU7ts0knH?=
 =?us-ascii?Q?BnYZl98YPt+ZXvJzy2j3D3KFbQ7tRc2+GKTa7meZplmJQOEVmX3F9xXMNyGg?=
 =?us-ascii?Q?dMqPjr5YZdSekedRplrqNaOMIlbtqw7Bm6A1bwFzOaRQq3tDr24jQq7/6p/o?=
 =?us-ascii?Q?yj26egnKIB6NKV87fyRoEwHUgp+swfuu8K+qhBuehhZKDJ8h0QOqYfil5UxD?=
 =?us-ascii?Q?H4OSC845W/sSzshpXDLs7Py+SBxiUySu9ADat04YjxZYHumkt2+0W3VVL3GH?=
 =?us-ascii?Q?zN1617yUxv8KOm452HaU/xYnnFWfpIRpSk2om8OPx+XsZrN/bb5sVvPPs9RH?=
 =?us-ascii?Q?E5ijbOBlGg2UqEinA7SQ36LNcnLKMGgcCA8Vpy8jUjUAZA1AbURCVX9RFADC?=
 =?us-ascii?Q?kPSlJxmJ99881lvq7pULldfCRgrin7aEmmKGDo16s00hVQrZt3SKW9WgyRL5?=
 =?us-ascii?Q?BlLD8h8aQaYjFGU+mRq22ImZUdEXoG1H6N3cU+z00Ip6/ILD60/0Ejm9AZn/?=
 =?us-ascii?Q?YESAB2yxIfmuwTFxNdg52m/4wN58VLansrkOzCqMhl8oh1aPMdry25C73wx1?=
 =?us-ascii?Q?JX5b0Kj8KP0MUov9oYUsKGD5zZXvQg5R66syFPwqtmckgc+IPtV0w/81LUmw?=
 =?us-ascii?Q?GqMaKatZ+ZGZFDQpk7/SPehn+IW69qnrl8UQ8ea/zZukAsejqwF2LNMJsnwP?=
 =?us-ascii?Q?vzvJvZm2Co+lmSc/9KwsHpntrk6AHWYqTkoIggMvI9NJGb7+I14LOsYisQC0?=
 =?us-ascii?Q?goP0VeMppBuvgD40yT4cKtwTrpu4crkA+8EyTU2ZSds6WGQWu9JNO4l8laTO?=
 =?us-ascii?Q?wr+i8VztmTYpAuCcjquyp83hzFXk88olr/NhCvwTwyeAwEFk42hThl47CCZI?=
 =?us-ascii?Q?IiZUmdWM8CjiNtcEk+IkKwa8S7tm5qReK19PszweG9QkX/6DSKU/8XwO1XeL?=
 =?us-ascii?Q?RIN9SWXUz0HElUCTlUOzwv0ij8fB2JuzGv1xV88CFoT3dy2nPS5SftqEzB4r?=
 =?us-ascii?Q?1DkhzF6FN5nkoeSOMqcjtaWHHdmcA0g09ivAFRytfabdcqE9IeM9tAcXUXXi?=
 =?us-ascii?Q?5dwqU/28kmA66MU79VUJDI6EakV49pUFj5c0TiAEAvEaxaH+o/m9uYe/nt99?=
 =?us-ascii?Q?1ZLpH4Fb3aoZ44NypnAYn2cidilEXf4Pox3WlJUZHAi1K3gjxjE6i2rV9xlv?=
 =?us-ascii?Q?vZqbTSi4uDcnwM7NMnhyZlFC?=
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
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 96740ca6-ba01-4e03-6979-08daa131536c
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2022 09:10:45.1273
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP4P284MB1844
X-Rspamd-Queue-Id: 4McrLx0Jh5z43Ty
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b="B9h0N/YU";
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.48 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-3.63 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.87)[-0.870];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	NEURAL_SPAM_LONG(0.23)[0.235];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15:c];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.96.48:from];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_EQ_ADDR_SOME(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

>=20
> FYI: There is some experimental thunderbolt support at:
>=20
> https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu=
b.c
> om%2Fhselasky%2Fusb4&data=3D05%7C01%7C%7C14c86eee9f5d492c41d50
> 8daa0b49bdb%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6379989
> 94857157968%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
> =3D%2FOnIO3esoAmi1FSPkHRYpHCHkcN6U2rO9WhaimdaVbk%3D&reserved
> =3D0
>=20
> But I'm not sure if it supports the hardware you've got.
>=20
> --HPS


Hi Hans

Should i wait to apply this thunderbolt business just yet , at least you an=
alize the log I sent you in the last email or should I go for it ?

Thanks

--tzk

From nobody Wed Sep 28 09:42:58 2022
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 4Mcs4922VXz4dRfH;
	Wed, 28 Sep 2022 09:43:05 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4Mcs482dhSz4756;
	Wed, 28 Sep 2022 09:43:04 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 85BD0260246;
	Wed, 28 Sep 2022 11:43:01 +0200 (CEST)
Message-ID: 
Date: Wed, 28 Sep 2022 11:42:58 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: RES: TP-LINK USB no carrier after speed test
To: Ivan Quitschal 
Cc: Alexander Motin ,
 "freebsd-current@freebsd.org" ,
 "freebsd-usb@FreeBSD.org" 
References: 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
 
 
 <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
 
 <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org>
 
 <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org>
 <37d15b0a-0cc1-0830-98a9-c7e19b7a7ef5@selasky.org>
 
Content-Language: en-US
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Mcs482dhSz4756
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_LONG(-1.00)[-0.996];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[hotmail.com];
	ARC_NA(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[selasky.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/28/22 11:07, Ivan Quitschal wrote:
> 
> 
> On Tue, 27 Sep 2022, Hans Petter Selasky wrote:
> 
>> On 9/27/22 15:22, Hans Petter Selasky wrote:
>>> On 9/27/22 14:17, Ivan Quitschal wrote:
>>>>
>>>>
>>>> On Tue, 27 Sep 2022, Hans Petter Selasky wrote:
>>>>
>>>>> On 9/27/22 02:24, Alexander Motin wrote:
>>>>>> On 26.09.2022 17:29, Hans Petter Selasky wrote:
>>>>>>> I've got a supposedly "broken" if_ure dongle from Alexander, but 
>>>>>>> I'm unable to reproduce the if_ure hang on two different pieces 
>>>>>>> of XHCI hardware, Intel based and AMD based, which I've got.
>>>>>>>
>>>>>>> This leads me to believe there is a bug in the XHCI driver or 
>>>>>>> hardware on your system.
>>>>>>>
>>>>>>> Can you share the pciconfig -lv output for your XHCI controllers?
>>>>>>
>>>>>> I have two laptops of different generations reproducing this 
>>>>>> problem, but both are having Thunderbolt on the USB-C ports:
>>>>>>
>>>>>> This is one (7th Gen Core i7):
>>>>>>
>>>>>> xhci1@pci0:56:0:0:      class=0x0c0330 rev=0x02 hdr=0x00 
>>>>>> vendor=0x8086 device=0x15d4 subvendor=0x2222 subdevice=0x1111
>>>>>>      vendor     = 'Intel Corporation'
>>>>>>      device     = 'JHL6540 Thunderbolt 3 USB Controller (C step) 
>>>>>> [Alpine Ridge 4C 2016]'
>>>>>>      class      = serial bus
>>>>>>      subclass   = USB
>>>>>>      bar   [10] = type Memory, range 32, base 0xc3f00000, size 
>>>>>> 65536, enabled
>>>>>>      cap 01[80] = powerspec 3  supports D0 D1 D2 D3  current D0
>>>>>>      cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 
>>>>>> message
>>>>>>      cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS
>>>>>>                   max read 512
>>>>>>                   link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) 
>>>>>> ClockPM disabled
>>>>>>      ecap 0003[100] = Serial 1 20ff910876f10c00
>>>>>>      ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected
>>>>>>      ecap 0002[300] = VC 1 max VC0
>>>>>>      ecap 0004[400] = Power Budgeting 1
>>>>>>      ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216
>>>>>>      ecap 0018[600] = LTR 1
>>>>>>      ecap 0019[700] = PCIe Sec 1 lane errors 0
>>>>>>
>>>>>> This is another (11th Gen Core i7);
>>>>>>
>>>>>> xhci0@pci0:0:13:0:      class=0x0c0330 rev=0x01 hdr=0x00 
>>>>>> vendor=0x8086 device=0x9a13 subvendor=0x1028 subdevice=0x0991
>>>>>>      vendor     = 'Intel Corporation'
>>>>>>      device     = 'Tiger Lake-LP Thunderbolt 4 USB Controller'
>>>>>>      class      = serial bus
>>>>>>      subclass   = USB
>>>>>>      bar   [10] = type Memory, range 64, base 0x60552c0000, size 
>>>>>> 65536, enabled
>>>>>>      cap 01[70] = powerspec 2  supports D0 D3  current D0
>>>>>>      cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 
>>>>>> message
>>>>>>      cap 09[90] = vendor (length 20) Intel cap 15 version 0
>>>>>>      cap 09[b0] = vendor (length 0) Intel cap 0 version 1
>>>>>>
>>>>>> Does the system you also has Thunderbolt chip, or you use native 
>>>>>> Intel chipet's XHCI?
>>>>>>
>>>>>>> Also, when running the stress test and you see the traffic stops, 
>>>>>>> what happens if you run this command as root on the ugen which 
>>>>>>> the if_ure belongs to:
>>>>>>>
>>>>>>> usbconfig -d ugenX.Y dump_string 0
>>>>>>>
>>>>>>> Does the traffic resume?
>>>>>>
>>>>>> Nope. Out of 4 times when traffic stopped 2 times it reported 
>>>>>>  and 2 times it completed successfully, but it neither 
>>>>>> case it recovered traffic.  Only reset recovered it.
>>>>>>
>>>>>
>>>>> Hi Alexander,
>>>>>
>>>>> Could you run "usbdump -d X.Y" at the same time to capture all the 
>>>>> errors?
>>>>>
>>>>> Looking especially for USB_ERR_TIMEOUT .
>>>>>
>>>>> I have this:
>>>>>
>>>>> xhci0@pci0:3:0:3:    class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 
>>>>> device=0x15e0 subvendor=0x1849 subdevice=0xffff
>>>>>    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
>>>>>    device     = 'Raven USB 3.1'
>>>>>    class      = serial bus
>>>>>    subclass   = USB
>>>>>
>>>>> xhci0@pci0:0:20:0:    class=0x0c0330 rev=0x21 hdr=0x00 
>>>>> vendor=0x8086 device=0x9d2f subvendor=0x8086 subdevice=0x9d2f
>>>>>    vendor     = 'Intel Corporation'
>>>>>    device     = 'Sunrise Point-LP USB 3.0 xHCI Controller'
>>>>>    class      = serial bus
>>>>>    subclass   = USB
>>>>>
>>>>> --HPS
>>>>>
>>>>
>>>>
>>>> hi Hans
>>>>
>>>> i think i got some good logs for you
>>>>
>>>> before the problem i ran this:
>>>>
>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>
>>>> # usbconfig -d ugen0.10 >> before
>>>> # usbconfig -d ugen0.10 dump_all_desc >> before
>>>> # usbconfig -d ugen0.10 dump_stats >> before_status
>>>>
>>>> the after the problem happened i ran
>>>>
>>>> # usbconfig -d ugen0.10 >> after
>>>> # usbconfig -d ugen0.10 dump_all_desc >> after
>>>> # usbconfig -d ugen0.10 dump_stats >> after_status
>>>>
>>>>
>>>> just by looking i already see some problems comparing both
>>>>
>>>> for example
>>>>
>>>> before the problem we have:
>>>>
>>>> ----------------------
>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>
>>>>    bLength = 0x0012
>>>>    bDescriptorType = 0x0001
>>>>    bcdUSB = 0x0300
>>>>    bDeviceClass = 0x0000  
>>>>    bDeviceSubClass = 0x0000
>>>>    bDeviceProtocol = 0x0000
>>>>    bMaxPacketSize0 = 0x0009
>>>>    idVendor = 0x2357
>>>>    idProduct = 0x0601
>>>>    bcdDevice = 0x3000
>>>> ****
>>>>    iManufacturer = 0x0001  
>>>>    iProduct = 0x0002  
>>>>    iSerialNumber = 0x0006  <000001>
>>>>    bNumConfigurations = 0x0002
>>>>
>>>> ------------------------
>>>>
>>>> after the problem
>>>>
>>>> --------------------------
>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>
>>>>    bLength = 0x0012
>>>>    bDescriptorType = 0x0001
>>>>    bcdUSB = 0x0300
>>>>    bDeviceClass = 0x0000  
>>>>    bDeviceSubClass = 0x0000
>>>>    bDeviceProtocol = 0x0000
>>>>    bMaxPacketSize0 = 0x0009
>>>>    idVendor = 0x2357
>>>>    idProduct = 0x0601
>>>>    bcdDevice = 0x3000
>>>> ****
>>>> iManufacturer = 0x0001  
>>>>    iProduct = 0x0002  
>>>>    iSerialNumber = 0x0006  
>>>>    bNumConfigurations = 0x0002
>>>>
>>>>   Configuration index 0 --------------------------
>>>>
>>>>
>>>> the log in ttyv0 was this:
>>>>
>>>> ure0: at uhub0, port 14, addr 9 (disconnected)
>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: receive_packet failed 
>>>> on ue0: Device not configured
>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: ioctl(SIOCGIFFLAGS) on 
>>>> ue0: Operation not permitted
>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: Interface ue0 no longer 
>>>> appears valid.
>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: No live interfaces to 
>>>> poll on - exiting.
>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: connection closed
>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
>>>> rgephy0: detached
>>>> miibus0: detached
>>>> ure0: detached
>>>>
>>>>
>>>> difference between before_status and after_status
>>>>
>>>> before_status:
>>>>
>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>
>>>> {
>>>>      UE_CONTROL_OK       : 2389
>>>>      UE_ISOCHRONOUS_OK   : 0
>>>>      UE_BULK_OK          : 803
>>>>      UE_INTERRUPT_OK     : 0
>>>>      UE_CONTROL_FAIL     : 0
>>>>      UE_ISOCHRONOUS_FAIL : 0
>>>>      UE_BULK_FAIL        : 0
>>>>      UE_INTERRUPT_FAIL   : 0
>>>> }
>>>>
>>>>
>>>> after_status:
>>>>
>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>
>>>> {
>>>>      UE_CONTROL_OK       : 4275
>>>>      UE_ISOCHRONOUS_OK   : 0
>>>>      UE_BULK_OK          : 1126702
>>>>      UE_INTERRUPT_OK     : 0
>>>>      UE_CONTROL_FAIL     : 326
>>>>      UE_ISOCHRONOUS_FAIL : 0
>>>>      UE_BULK_FAIL        : 42
>>>>      UE_INTERRUPT_FAIL   : 0
>>>> }
>>>>
>>>>
>>>>
>>>> i hope that helps
>>>>
>>>>
>>>> all log files are attached
>>>>
>>>> thanks
>>>>
>>>> --tzk
>>>
>>>
>>> One more test request:
>>>
>>> Make sure you have a kernel with "options USB_DEBUG".
>>>
>>> Then after "iperf" says 0bits/s, then you run:
>>>
>>> sysctl hw.usb.xhci.debug=29
>>>
>>> Then run those usbconfig commands.
>>>
>>> Then then:
>>>
>>> sysctl hw.usb.xhci.debug=0
>>>
>>> And collect the logs from /var/log/messages .
>>>
>>> Like said earlier, I wonder if the fault is in the XHCI controller 
>>> itself or something that has to do with thunderbolt, because on my 
>>> machine there is no indication of a if_ure device failure. The only 
>>> way to know for sure is to buy a USB 3.0 wire analyzer, like the 
>>> beagle one, but I'm unsure if they support USB-C .
>>>
>>> Thank you!
>>>
>>> --HPS
>>>
>>
>> FYI: There is some experimental thunderbolt support at:
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhselasky%2Fusb4&data=05%7C01%7C%7C14c86eee9f5d492c41d508daa0b49bdb%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637998994857157968%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FOnIO3esoAmi1FSPkHRYpHCHkcN6U2rO9WhaimdaVbk%3D&reserved=0
>>
>> But I'm not sure if it supports the hardware you've got.
>>
>> --HPS
>>
> 
> 
> Hi Hans
> 
> i got two log versions for you, one with the constant set to 2048 (the 
> working version) , and the other with no patches whatsoever (the bad 
> version)
> 
> since the entire logs reached more than 150M of size, i had to cut to 
> the last 1000 lines , hope toats enough
> 
> pleaes find attached the two files
> 
> the xhci_NOT_working i stoped recording right after the problem ocurred
> 
> please let me know if you need something else
> 
> thank you
> 
> --tzk

I need the full log.

The XHCI driver is very verbose you see.

Maybe you can do some filtering, like figuring out all the status codes 
you see:

status=1
status=13

and so on.

--HPS

From nobody Wed Sep 28 09:47:39 2022
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 4Mcs9Y5SPDz4dS13;
	Wed, 28 Sep 2022 09:47:45 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mcs9X4Vhxz49gG;
	Wed, 28 Sep 2022 09:47:44 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 28S9lekV083029;
	Wed, 28 Sep 2022 18:47:41 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Wed, 28 Sep 2022 18:47:39 +0900
From: Tomoaki AOKI 
To: Hans Petter Selasky 
Cc: Ivan Quitschal , Alexander Motin ,
        "freebsd-current@freebsd.org" ,
        "freebsd-usb@FreeBSD.org" 
Subject: Re: RES: TP-LINK USB no carrier after speed test
Message-Id: <20220928184739.95ad942622d6aa505cd3a4e6@dec.sakura.ne.jp>
In-Reply-To: <37d15b0a-0cc1-0830-98a9-c7e19b7a7ef5@selasky.org>
References: 
	
	<9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
	
	
	
	<5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
	
	
	<1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
	
	<4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org>
	
	<93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org>
	<37d15b0a-0cc1-0830-98a9-c7e19b7a7ef5@selasky.org>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Mcs9X4Vhxz49gG
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-usb@FreeBSD.org,freebsd-current@freebsd.org];
	FREEMAIL_CC(0.00)[hotmail.com,FreeBSD.org,freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	MIME_TRACE(0.00)[0:+];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[sakura.ne.jp];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 27 Sep 2022 20:17:54 +0200
Hans Petter Selasky  wrote:

> On 9/27/22 15:22, Hans Petter Selasky wrote:

   (snip)

> FYI: There is some experimental thunderbolt support at:
> 
> https://github.com/hselasky/usb4
> 
> But I'm not sure if it supports the hardware you've got.
> 
> --HPS

Thanks for the hard work and info.

As I stated on Bug 237666 [1], I have Titan Ridge TB3 bridge on my
ThinkPad P52. The relevant part of HW probe is at comment 206 [2].
Are there any other info I can provide for Titan Ridge support?
(Not yet tried the codes.)

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666

[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666#c206

-- 
Tomoaki AOKI    

From nobody Wed Sep 28 09:56:39 2022
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 4McsMw5W9Wz4dT7L;
	Wed, 28 Sep 2022 09:56:44 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4McsMw0NjYz3CTT;
	Wed, 28 Sep 2022 09:56:44 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 53C02260246;
	Wed, 28 Sep 2022 11:56:42 +0200 (CEST)
Message-ID: <79bd962c-8db2-3e49-410a-325b6e2bdb2d@selasky.org>
Date: Wed, 28 Sep 2022 11:56:39 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: RES: TP-LINK USB no carrier after speed test
Content-Language: en-US
To: Tomoaki AOKI 
Cc: Ivan Quitschal , Alexander Motin ,
 "freebsd-current@freebsd.org" ,
 "freebsd-usb@FreeBSD.org" 
References: 
 <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org>
 
 
 
 <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>
 
 
 <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
 
 <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org>
 
 <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org>
 <37d15b0a-0cc1-0830-98a9-c7e19b7a7ef5@selasky.org>
 <20220928184739.95ad942622d6aa505cd3a4e6@dec.sakura.ne.jp>
From: Hans Petter Selasky 
In-Reply-To: <20220928184739.95ad942622d6aa505cd3a4e6@dec.sakura.ne.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4McsMw0NjYz3CTT
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	FREEMAIL_CC(0.00)[hotmail.com,FreeBSD.org,freebsd.org];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 9/28/22 11:47, Tomoaki AOKI wrote:
> As I stated on Bug 237666 [1], I have Titan Ridge TB3 bridge on my
> ThinkPad P52. The relevant part of HW probe is at comment 206 [2].
> Are there any other info I can provide for Titan Ridge support?
> (Not yet tried the codes.)
> 
> [1]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666
> 
> [2]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666#c206

I cannot promise anything and I don't have an overview which TB3 
controllers are compatible with eachother. Maybe grepping for the PCI 
ID's in Linux will give some clues, hence I don't have access to any 
thunderbolt documentation myself!

--HPS

From nobody Wed Sep 28 11:54:12 2022
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 4Mcvzb3Mjvz4V1n9;
	Wed, 28 Sep 2022 11:54:19 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2102.outbound.protection.outlook.com [40.92.96.102])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4McvzY6Zgfz3Rhv;
	Wed, 28 Sep 2022 11:54:17 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=cu+tpCq6do7iw9+ETha4IQeERR3BAI9Rmx32TQa4Txrx107qwvjCWcia/ODoQumTApecEw6aFCmCW2DBmvnyF4EhqF1TxonvhFVHcvuZRUkLdFmFWL7zoalvo3q0MmNxe7zY38Isx3emGOZ6O4B5aa5TpfVc0IljNFcl6DTL/8Ekq0U3r19SuMRdYBFLPpqJ5vZVdW3SiRTeTLpw2DeCnKobhVqlVYRNTugSdSt3Wn4lI1S2V65LAO11byYQp7RIkMUMMtqMFhW4+7k+28lFex8LzW4mXLYRj3fjia2xMOKX/bmeawQ3hEhitWFOyiqEFXqRENtsrcLhCe5y/AVQag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=MC98ZBavT565CPs4DHmFCtT9bmBxFi1DKInR/4/+92A=;
 b=J5+DTu8E8wqlPf3es0/pXoJRD9qFld6IfvsnHvhNAOkedg0wN8/DFxeuyJwds4xCDOHB226Gtzq1N/MuX6x3azmdfPhfGdP0I/tV1qnx/u5UWtXlX5+HNU7kh/kHgQmKYRL5J1OuUByW0KKUEf7NhnT6WGOSQ/968X5zU3otN7fAvZrkJDRYhJEC7R8HR1vRKHrinEnQOPp2EaW9JHGf3Lee2wwxA2FegjVZosiCv1iPEF+RPwvsxYC8v4VJiI4pZyXQIYj+Qgt56gAZd1rVmxW59KtwiyUP3VVlaGeP9dfqBv1lARQnwGvaAvFc6toQSBrlG6SzJboWuZnyrjgH6A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=MC98ZBavT565CPs4DHmFCtT9bmBxFi1DKInR/4/+92A=;
 b=srZkpNnvOR+XJY/eBCzIUaxALXCIkU0VsaNqUv30CafwEYDF8SlqiifoHLbl0Daatm1l3w0AAIufjfZuVG1Gp3/OsPViuy1TnfgFhOV7CtFlT5CK2cls9OzjidPHzbjVFflkufJfIQl4x3UBEjk5ptISc9s835Me12LmWn96oFgk6Vv7bIzo4Bm6xgzLBTOvF3TlPV+f0j4GXDh7kUzOibPxi58C+UA+rzAfXSAtfY4/AhaaCNqhkR/QSWf5knlEhWqVOfgPqnN+jzeSc/QuEMMfUwa+FD9Y1OhMGkwPHyZ4gXWK+BoS16XpJPys1EIroNFt8NVTH+5DA1HEgpeYOw==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CP4P284MB1859.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:dc::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.17; Wed, 28 Sep
 2022 11:54:13 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::97ca:1c5:b250:8f79%7]) with mapi id 15.20.5654.025; Wed, 28 Sep 2022
 11:54:13 +0000
Date: Wed, 28 Sep 2022 08:54:12 -0300 (-03)
From: Ivan Quitschal 
To: Hans Petter Selasky 
cc: Ivan Quitschal , Alexander Motin , 
    "freebsd-current@freebsd.org" , 
    "freebsd-usb@FreeBSD.org" 
Subject: Re: RES: TP-LINK USB no carrier after speed test
In-Reply-To: 
Message-ID:
 
References:   
  <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org>  
 <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>  <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org> 
 <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org> <37d15b0a-0cc1-0830-98a9-c7e19b7a7ef5@selasky.org>  
Content-Type: multipart/mixed; boundary="3432851520-1700655352-1664366053=:1776"
X-TMN: [s192eJ7ajOOxcgHqwxVlLmvZG6Ftazxq]
X-ClientProxiedBy: CP4P284CA0021.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:126::20) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <54ef5c22-f9a9-c2f4-5e78-272c4fdd446b@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|CP4P284MB1859:EE_
X-MS-Office365-Filtering-Correlation-Id: 7d16dcb2-3067-445b-8e0e-08daa1482965
X-MS-Exchange-SLBlob-MailProps:
	CLk2x5OX5VbLoOWJP0LVdFOjpBUuKUL9gEuofgmu8Lx+JFh0DtWsldthp7f4z0lQLjuPfJlF+vyNFPH2XQEPaP4a+kTASYtXT7CkiIWJkPMOZLujscGEia+ZboxRz5QkTMFAS57jeGeXrdqOlOsxhwtuMAVKm+7L7HnW2srS3nEltlWuIWtu7f3TotT4TlhSgNtz4qfzxJBobWmjKncszoGB4YCe491SPLxFdjC5rbFyeRpuKts9o/FUChc//gTA1LdvMfAcpUqMoRQQRtM4Brn3C/CM3MxUJsKUuG4gpDiO0ovA/Rz7k/wYNvZiDfPmSKjb5Dq4CkLdd5RStheqDE6aNJBaZLljsWhIVtmJQxuZzTihumclWRp/B/TbbYRRQMcVPokeclVBaj+GLX6WyTSksgF528wPon4rWmarWz6Q5K2hyPH5in1yVnWZ62IUs5vBuO4DK157h9R7Y9ogGcK6+q/8QZUGzvNnQ4xcmhgfjfrTzqsmHYZkilVOhI1FZfefC4dsyS56Q7mysw4MDGd2TCyRf6OBMN0nYF3oGOnGwWn07fEQ6a49M466SWJqdmfzBqBTH38DTukfv0lx8kk48Cvcp0It3IeP2m/Isqu1oAiG7qNJ8bRO3QqeZYPNMW0h5EEk62tRAOVCrYsfRi+Bbz8HAOmGDykY74Jobf0t/qhYas2xnnOH2FZuTerST4+a7/A2Prq80cCyiiHPLA==
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	dfKy/4Ax+Kumbjed4GfnD1C/vjk3ZFSQ9cY2AalWMCppMFvGWP2yxKCEsGHufmG8aN194xc/a9tUQR6fEuCy6954KtQkWvcIYT7n1d0rAyh4zWaliLUh7QctrGHEcrPmyaCd2OqBHe1ZxKh2E1t4L6Is5ihuy5mvt2MqhzrQ72myQOb8yByzzkGPal1WH/xkMvtg7IOYmSenMzk/CStwzdbH1YQa9+wTzXPT00Mz3I50AbDPBSEInFPmUdBTAjAGDsbGUDKp3xhIPkt6Y3mQohM3HQGh+7wQFIX5aaxbmJpDUEDNOp+Tfrp/96EPPGj5MTVzb0jDckod58+bKNS/j8l8kAjoaGuLIecfkJv7Z4nzboeTIn0r5hxNcY956fY5Ky/WT64oD7LRjpqbvPYLPYU/ftU0ywYBSgEA62uR9EcprsKuZOfUPXZxxV1Iu2cGgMEsD+RRFnMAcOh7jZUfzfR8hq/7MwjQ+3SSgSPfsEKYIVuyLEv7RSLMiH4fZBdzMr7sh7ONNojvxLr5k15atFbuS2R9i4C0XTbKCyzAhvu+2/ulyt0BrMH4SYz52MjkD2ptQCpdAN6wgTRXJLvydrGb37WUlvonpb8HE97SSCdkuqKgdmnlK9RrsBH5Pbc5HPGhw5kv0WoRBa7uxJK7cxv0RrBlCf6KDnUkNRjgQNA=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?VWdtU0VneVNJdmJFdTRBZW5ydzUrcjZCdU10dFh1TTdTNnp5ZVR4ZUNHZ1pP?=
 =?utf-8?B?TTRqVWlta0lxckx0REQ4Y25EQTg3S003akNJTmJEZTFWcWdUZzRjN3k5SjdB?=
 =?utf-8?B?Z2dROENLV1NzbGVETXU2aWlxc1VEL1FsR1RVY1FkQmcySVJzQ0lic0YzUzZv?=
 =?utf-8?B?Y0RBdFdQREVaTWFBM3hSSEE4UXZDUTdRZU1nUDlSdWpCN3hmK0FnMld1TjRn?=
 =?utf-8?B?czZtYTNFNzUvMWJHUFppOHBFZjBUOHNRMGxBWExDcWV5cjdxS3YrRW9LVGFn?=
 =?utf-8?B?Z3Bua3RQVmk1THBhRlF2bmN4aG80SXFITzNoUC9qVStKVFA5Rm9MWHhGK3FD?=
 =?utf-8?B?bXJlRVdSTXNTMnpvQ2VHNEQyT09SZWtDaEN1NVgrMmlnVDlPK0t5M0g1V2pG?=
 =?utf-8?B?bE5qR2VNOXF2UllvSWk5YzFweTc4dVoxWjU5WmdCUzBHQTJ4OC9WejEvZFVX?=
 =?utf-8?B?SHJVQ3JYbGJxWUVDbFdWSHBmUTNKUlIxV29VS2JDNENHTWVFaTVZNDNZcFFn?=
 =?utf-8?B?MVVlWFR5cFArc091RVlXU3F4WFNiUit1MlFNNEtaR0dlVE5xQ0g5WWpKMk82?=
 =?utf-8?B?MnRlKzdib2YyOHFDMXdBSnJ3em9HNGRscXRNN3k4UmxTdlMvdnY2dyt4RG54?=
 =?utf-8?B?K09RS1JtTmpZSFdkK2xVZmtxRVBYR08wa0JlbStnTUdMWDZFS1hZOSs4M3Va?=
 =?utf-8?B?M2hwbnk0NFBJY2hZdUs3M05CVHM3bWcydm1kK2Q0K3RWY3pudGxOZnBoL1pq?=
 =?utf-8?B?bHM2QUQ5TFZNMjhVbDI1N3hHVEhYTFNETlRHYytnblBOcGROQjN5eHFqRmhq?=
 =?utf-8?B?TDhONW9URFN5a0x3L1VOOCtEbkRDbXZNemo3QzVZTzl5d2RXNG5GaWdwcENv?=
 =?utf-8?B?Q2hkV3RaSTdBVTltSDZtdm9WSkFDaG1yTVJIWjlFeTd2bExuOUxEd05GSG1i?=
 =?utf-8?B?S3BkZzhncGRRUWZ4UFNmLzNJTzV1UUxoSEVoanNoNDNLZDdXM052TDc4Wnp0?=
 =?utf-8?B?ZEJ3NjR2NG5FYTlpTWRvRVVCR0dRWlZHSFFYalNZbm4wVFJHTHFFaEp1cDg1?=
 =?utf-8?B?akVxbGNVQ2w2eHFpcHdvV1E2U0ZZUEdmUVA4bWFxZlBEeXFJaStnemxaSHpr?=
 =?utf-8?B?WllQUVc0cm1rVkpoOEI0TkxSTEE2OUNGV0x6VW95K3g2cHEvVUtNcGM2U2Qr?=
 =?utf-8?B?dzFXSEpsYTVrMy94eGwwNXh0VjZTOEFQNk9KWkVnYmRUSDlmYnFldFlvemJX?=
 =?utf-8?B?c0M1cHRJakxnd2ZaUDhQenFXZzZoWDZkUjFqUHlDRllpN2hTYXNQSGJKQ0d5?=
 =?utf-8?B?aDgweEVkS0NmeHpXUnorWVZoajU1NVJNWXRjMGU1b3dodHJELzJFdGc3dHFU?=
 =?utf-8?B?VGlyeHNqU3BIU3ZjUVFYQmFrSC8xN0J4SmYrQmp1d29CLy9JWEVlL0RMMWhU?=
 =?utf-8?B?dCt4c0dDMmpxd2pkTFk1OEhmbHhIMmRqdkRraTR4akxaWS9UZjZEMzZFTVRP?=
 =?utf-8?B?aDhUcHVyRi9RdTVyS2JSVm9tcGx4a04wZm42dWpOSHZWbUlSaGtjN0dDZlUz?=
 =?utf-8?B?TUF6ajFBQXpkLzdjVlNobDlGRzhwbVlRamFrWVlualdyMWFVMnVUZHM0N0tu?=
 =?utf-8?B?L0VRZ2hWbTdmRDluakMwYnE2enFjRGZrQWZLd1FXWDlGMGFmMFNuam9Tc2FM?=
 =?utf-8?B?YTBaS2JJbkl6Tnd3dkhMQVRxMEdUS2tEU3RSS1YwWnUrS1ovYkFvWExnPT0=?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d16dcb2-3067-445b-8e0e-08daa1482965
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2022 11:54:13.6990
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP4P284MB1859
X-Rspamd-Queue-Id: 4McvzY6Zgfz3Rhv
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=srZkpNnv;
	arc=pass ("microsoft.com:s=arcselector9901:i=1");
	dmarc=pass (policy=none) header.from=hotmail.com;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.96.102 as permitted sender) smtp.mailfrom=tezeka@hotmail.com
X-Spamd-Result: default: False [-3.97 / 15.00];
	CTYPE_MIXED_BOGUS(1.00)[];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.986];
	NEURAL_HAM_LONG(-0.98)[-0.984];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	FROM_HAS_DN(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.96.102:from];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	MIME_TRACE(0.00)[0:+,1:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org];
	RCPT_COUNT_FIVE(0.00)[5];
	FREEMAIL_FROM(0.00)[hotmail.com];
	TO_DN_SOME(0.00)[];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[hotmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_CC(0.00)[hotmail.com,FreeBSD.org,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--3432851520-1700655352-1664366053=:1776
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT



On Wed, 28 Sep 2022, Hans Petter Selasky wrote:

> On 9/28/22 11:07, Ivan Quitschal wrote:
>> 
>> 
>> On Tue, 27 Sep 2022, Hans Petter Selasky wrote:
>> 
>>> On 9/27/22 15:22, Hans Petter Selasky wrote:
>>>> On 9/27/22 14:17, Ivan Quitschal wrote:
>>>>> 
>>>>> 
>>>>> On Tue, 27 Sep 2022, Hans Petter Selasky wrote:
>>>>> 
>>>>>> On 9/27/22 02:24, Alexander Motin wrote:
>>>>>>> On 26.09.2022 17:29, Hans Petter Selasky wrote:
>>>>>>>> I've got a supposedly "broken" if_ure dongle from Alexander, but I'm 
>>>>>>>> unable to reproduce the if_ure hang on two different pieces of XHCI 
>>>>>>>> hardware, Intel based and AMD based, which I've got.
>>>>>>>> 
>>>>>>>> This leads me to believe there is a bug in the XHCI driver or 
>>>>>>>> hardware on your system.
>>>>>>>> 
>>>>>>>> Can you share the pciconfig -lv output for your XHCI controllers?
>>>>>>> 
>>>>>>> I have two laptops of different generations reproducing this problem, 
>>>>>>> but both are having Thunderbolt on the USB-C ports:
>>>>>>> 
>>>>>>> This is one (7th Gen Core i7):
>>>>>>> 
>>>>>>> xhci1@pci0:56:0:0:      class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x8086 
>>>>>>> device=0x15d4 subvendor=0x2222 subdevice=0x1111
>>>>>>>      vendor     = 'Intel Corporation'
>>>>>>>      device     = 'JHL6540 Thunderbolt 3 USB Controller (C step) 
>>>>>>> [Alpine Ridge 4C 2016]'
>>>>>>>      class      = serial bus
>>>>>>>      subclass   = USB
>>>>>>>      bar   [10] = type Memory, range 32, base 0xc3f00000, size 65536, 
>>>>>>> enabled
>>>>>>>      cap 01[80] = powerspec 3  supports D0 D1 D2 D3  current D0
>>>>>>>      cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 
>>>>>>> message
>>>>>>>      cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS
>>>>>>>                   max read 512
>>>>>>>                   link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) 
>>>>>>> ClockPM disabled
>>>>>>>      ecap 0003[100] = Serial 1 20ff910876f10c00
>>>>>>>      ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected
>>>>>>>      ecap 0002[300] = VC 1 max VC0
>>>>>>>      ecap 0004[400] = Power Budgeting 1
>>>>>>>      ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216
>>>>>>>      ecap 0018[600] = LTR 1
>>>>>>>      ecap 0019[700] = PCIe Sec 1 lane errors 0
>>>>>>> 
>>>>>>> This is another (11th Gen Core i7);
>>>>>>> 
>>>>>>> xhci0@pci0:0:13:0:      class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 
>>>>>>> device=0x9a13 subvendor=0x1028 subdevice=0x0991
>>>>>>>      vendor     = 'Intel Corporation'
>>>>>>>      device     = 'Tiger Lake-LP Thunderbolt 4 USB Controller'
>>>>>>>      class      = serial bus
>>>>>>>      subclass   = USB
>>>>>>>      bar   [10] = type Memory, range 64, base 0x60552c0000, size 
>>>>>>> 65536, enabled
>>>>>>>      cap 01[70] = powerspec 2  supports D0 D3  current D0
>>>>>>>      cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 
>>>>>>> message
>>>>>>>      cap 09[90] = vendor (length 20) Intel cap 15 version 0
>>>>>>>      cap 09[b0] = vendor (length 0) Intel cap 0 version 1
>>>>>>> 
>>>>>>> Does the system you also has Thunderbolt chip, or you use native Intel 
>>>>>>> chipet's XHCI?
>>>>>>> 
>>>>>>>> Also, when running the stress test and you see the traffic stops, 
>>>>>>>> what happens if you run this command as root on the ugen which the 
>>>>>>>> if_ure belongs to:
>>>>>>>> 
>>>>>>>> usbconfig -d ugenX.Y dump_string 0
>>>>>>>> 
>>>>>>>> Does the traffic resume?
>>>>>>> 
>>>>>>> Nope. Out of 4 times when traffic stopped 2 times it reported >>>>>> error> and 2 times it completed successfully, but it neither case it 
>>>>>>> recovered traffic.  Only reset recovered it.
>>>>>>> 
>>>>>> 
>>>>>> Hi Alexander,
>>>>>> 
>>>>>> Could you run "usbdump -d X.Y" at the same time to capture all the 
>>>>>> errors?
>>>>>> 
>>>>>> Looking especially for USB_ERR_TIMEOUT .
>>>>>> 
>>>>>> I have this:
>>>>>> 
>>>>>> xhci0@pci0:3:0:3:    class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022 
>>>>>> device=0x15e0 subvendor=0x1849 subdevice=0xffff
>>>>>>    vendor     = 'Advanced Micro Devices, Inc. [AMD]'
>>>>>>    device     = 'Raven USB 3.1'
>>>>>>    class      = serial bus
>>>>>>    subclass   = USB
>>>>>> 
>>>>>> xhci0@pci0:0:20:0:    class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086 
>>>>>> device=0x9d2f subvendor=0x8086 subdevice=0x9d2f
>>>>>>    vendor     = 'Intel Corporation'
>>>>>>    device     = 'Sunrise Point-LP USB 3.0 xHCI Controller'
>>>>>>    class      = serial bus
>>>>>>    subclass   = USB
>>>>>> 
>>>>>> --HPS
>>>>>> 
>>>>> 
>>>>> 
>>>>> hi Hans
>>>>> 
>>>>> i think i got some good logs for you
>>>>> 
>>>>> before the problem i ran this:
>>>>> 
>>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>> 
>>>>> # usbconfig -d ugen0.10 >> before
>>>>> # usbconfig -d ugen0.10 dump_all_desc >> before
>>>>> # usbconfig -d ugen0.10 dump_stats >> before_status
>>>>> 
>>>>> the after the problem happened i ran
>>>>> 
>>>>> # usbconfig -d ugen0.10 >> after
>>>>> # usbconfig -d ugen0.10 dump_all_desc >> after
>>>>> # usbconfig -d ugen0.10 dump_stats >> after_status
>>>>> 
>>>>> 
>>>>> just by looking i already see some problems comparing both
>>>>> 
>>>>> for example
>>>>> 
>>>>> before the problem we have:
>>>>> 
>>>>> ----------------------
>>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>> 
>>>>>    bLength = 0x0012
>>>>>    bDescriptorType = 0x0001
>>>>>    bcdUSB = 0x0300
>>>>>    bDeviceClass = 0x0000  
>>>>>    bDeviceSubClass = 0x0000
>>>>>    bDeviceProtocol = 0x0000
>>>>>    bMaxPacketSize0 = 0x0009
>>>>>    idVendor = 0x2357
>>>>>    idProduct = 0x0601
>>>>>    bcdDevice = 0x3000
>>>>> ****
>>>>>    iManufacturer = 0x0001  
>>>>>    iProduct = 0x0002  
>>>>>    iSerialNumber = 0x0006  <000001>
>>>>>    bNumConfigurations = 0x0002
>>>>> 
>>>>> ------------------------
>>>>> 
>>>>> after the problem
>>>>> 
>>>>> --------------------------
>>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>> 
>>>>>    bLength = 0x0012
>>>>>    bDescriptorType = 0x0001
>>>>>    bcdUSB = 0x0300
>>>>>    bDeviceClass = 0x0000  
>>>>>    bDeviceSubClass = 0x0000
>>>>>    bDeviceProtocol = 0x0000
>>>>>    bMaxPacketSize0 = 0x0009
>>>>>    idVendor = 0x2357
>>>>>    idProduct = 0x0601
>>>>>    bcdDevice = 0x3000
>>>>> ****
>>>>> iManufacturer = 0x0001  
>>>>>    iProduct = 0x0002  
>>>>>    iSerialNumber = 0x0006  
>>>>>    bNumConfigurations = 0x0002
>>>>> 
>>>>>   Configuration index 0 --------------------------
>>>>> 
>>>>> 
>>>>> the log in ttyv0 was this:
>>>>> 
>>>>> ure0: at uhub0, port 14, addr 9 (disconnected)
>>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: receive_packet failed on 
>>>>> ue0: Device not configured
>>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: ioctl(SIOCGIFFLAGS) on ue0: 
>>>>> Operation not permitted
>>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: Interface ue0 no longer 
>>>>> appears valid.
>>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: No live interfaces to poll 
>>>>> on - exiting.
>>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
>>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: connection closed
>>>>> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
>>>>> rgephy0: detached
>>>>> miibus0: detached
>>>>> ure0: detached
>>>>> 
>>>>> 
>>>>> difference between before_status and after_status
>>>>> 
>>>>> before_status:
>>>>> 
>>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>> 
>>>>> {
>>>>>      UE_CONTROL_OK       : 2389
>>>>>      UE_ISOCHRONOUS_OK   : 0
>>>>>      UE_BULK_OK          : 803
>>>>>      UE_INTERRUPT_OK     : 0
>>>>>      UE_CONTROL_FAIL     : 0
>>>>>      UE_ISOCHRONOUS_FAIL : 0
>>>>>      UE_BULK_FAIL        : 0
>>>>>      UE_INTERRUPT_FAIL   : 0
>>>>> }
>>>>> 
>>>>> 
>>>>> after_status:
>>>>> 
>>>>> ugen0.10:  at usbus0, cfg=0 md=HOST 
>>>>> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>>>>> 
>>>>> {
>>>>>      UE_CONTROL_OK       : 4275
>>>>>      UE_ISOCHRONOUS_OK   : 0
>>>>>      UE_BULK_OK          : 1126702
>>>>>      UE_INTERRUPT_OK     : 0
>>>>>      UE_CONTROL_FAIL     : 326
>>>>>      UE_ISOCHRONOUS_FAIL : 0
>>>>>      UE_BULK_FAIL        : 42
>>>>>      UE_INTERRUPT_FAIL   : 0
>>>>> }
>>>>> 
>>>>> 
>>>>> 
>>>>> i hope that helps
>>>>> 
>>>>> 
>>>>> all log files are attached
>>>>> 
>>>>> thanks
>>>>> 
>>>>> --tzk
>>>> 
>>>> 
>>>> One more test request:
>>>> 
>>>> Make sure you have a kernel with "options USB_DEBUG".
>>>> 
>>>> Then after "iperf" says 0bits/s, then you run:
>>>> 
>>>> sysctl hw.usb.xhci.debug=29
>>>> 
>>>> Then run those usbconfig commands.
>>>> 
>>>> Then then:
>>>> 
>>>> sysctl hw.usb.xhci.debug=0
>>>> 
>>>> And collect the logs from /var/log/messages .
>>>> 
>>>> Like said earlier, I wonder if the fault is in the XHCI controller itself 
>>>> or something that has to do with thunderbolt, because on my machine there 
>>>> is no indication of a if_ure device failure. The only way to know for 
>>>> sure is to buy a USB 3.0 wire analyzer, like the beagle one, but I'm 
>>>> unsure if they support USB-C .
>>>> 
>>>> Thank you!
>>>> 
>>>> --HPS
>>>> 
>>> 
>>> FYI: There is some experimental thunderbolt support at:
>>> 
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhselasky%2Fusb4&data=05%7C01%7C%7Cc2f534f631fd47afec9908daa135d60b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637999549868812246%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uL5DwbPcldediZmBiufQXnkF7%2F2WQTizqVLAYBHZjqA%3D&reserved=0
>>> 
>>> But I'm not sure if it supports the hardware you've got.
>>> 
>>> --HPS
>>> 
>> 
>> 
>> Hi Hans
>> 
>> i got two log versions for you, one with the constant set to 2048 (the 
>> working version) , and the other with no patches whatsoever (the bad 
>> version)
>> 
>> since the entire logs reached more than 150M of size, i had to cut to the 
>> last 1000 lines , hope toats enough
>> 
>> pleaes find attached the two files
>> 
>> the xhci_NOT_working i stoped recording right after the problem ocurred
>> 
>> please let me know if you need something else
>> 
>> thank you
>> 
>> --tzk
>
> I need the full log.
>
> The XHCI driver is very verbose you see.
>
> Maybe you can do some filtering, like figuring out all the status codes you 
> see:
>
> status=1
> status=13
>
> and so on.
>
> --HPS
>


hi Hans

i will try to do some logs filtered like you said , and will also try to 
compress as much as i want the full ones. ( i may be able to transform 150M into 
no more than 10M, its all plain text)

i will send you here and the list as soon as i do this .. dont know if ill be 
able to do this today, but tomorrow you'll get the full logs even if i have to 
open the ftp for you myself :- )


thanks

--tzk

--3432851520-1700655352-1664366053=:1776--

From nobody Fri Sep 30 10:31:10 2022
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 4Mf62m4KZMz4d2rf;
	Fri, 30 Sep 2022 10:31:12 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mf62m3txjz3Np2;
	Fri, 30 Sep 2022 10:31:12 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664533872;
	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=rCrkZnLQi6Ijq3pk1ggWGAH2ehrYLWM6gzxbDQtVNgU=;
	b=T2Nr6OfPMWSRQNtkulNOm2YH05eNduCOtLhUscm+1xiAHzbCNQ06UvGKkdxsKj0zo6XL2j
	hOZf6Hw2PRU8l3g3+Lw+OvdXfNCSMQP0noIkXvdslZaW0f+YQmfYTf8XQrBbv1g3CX/Ft1
	L4mdTlJKJCf1XSkBfszdmp4B+ZoDKNxWz2Nxpl6d9Er3i3XfQqYzak8lIjJ3+4dXz+Z0Lq
	PhwtQUXsccf0dSYsqTAII6D5g5yB4pGKNqu61PDWK0Ywq9R9is6kuiko4dA8vzjV/8U1IK
	u7jBHbdtQ2FNpWMA6Hks8XMV8+RET9l0aBDY/nfxuQGYaGZTesz7E9rw4b4vpA==
Received: from [192.168.0.88] (unknown [195.64.148.76])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: avg/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mf62l5lTyz12Hm;
	Fri, 30 Sep 2022 10:31:11 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Message-ID: <88231845-21c6-302a-4ea8-962877470284@FreeBSD.org>
Date: Fri, 30 Sep 2022 13:31:10 +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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.3.0
From: Andriy Gapon 
Subject: Re: usbhid panic when switching vt-s (invariants+witness enabled)
Content-Language: en-US
To: Hans Petter Selasky ,
 freebsd-stable List 
Cc: FreeBSD Current ,
 Vladimir Kondratyev 
References: 
 <0668f473-f6d3-eacf-e4ef-f8530563daed@selasky.org>
 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664533872;
	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=rCrkZnLQi6Ijq3pk1ggWGAH2ehrYLWM6gzxbDQtVNgU=;
	b=oEc/nxk1p4xwTixt+BaFJVYcZtceTg11lTZYueclvSc5ewAC1N/DdTqA06Kp07coy5kYvG
	1az7wd8TroqzVZbUdnDiLSD0MB+wMLTcnyU1HV8060u6q8p0Sd9yWlhOgBrwLOQvdIh+p5
	4yitnvUIHXYsPMFq+PZ9gFFBk/ea3AlxOJByQ3FJhR5Hl8E+Oy65mbzzlZAlVIjTnnKHR8
	8AiwMzVs6Jfwu9DzaBd3SWX1IKJaKloL2NesvfIytpKQ5pXouW7KQ52JB3dgddEdfYOd4s
	7gdLeialxAsoyx9WfkMYq5mIbSxvCPcqlqApWtEykWIJD6wyO23E59+K1BM6KA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664533872; a=rsa-sha256; cv=none;
	b=P1ajUyOaxUWGN1wE58IZ/9bOyiYxsqhxy5JVQTkFm2UH6G5/xXIkMRiyB1xT9GdwdDK+CV
	moMkKeyJbVRdP94CNrRvfKnhpM9SxqIZWrc12YFYaG6qU2XCu24wjdUfD0Iy5YFDfRSJaj
	DLsHMuWPfwnMx05OL6wrZtbs8VwqDZ5YBs0uu0L13DFzPN7FaR0IvC3g/QbVBW5VZNYEW/
	z1aFnnTz1GZxrVk/ZtbZpSZ1FA0eAjlg3qNtV182kbu/0ELl/uMgErXt+9WBORQy+BgMPP
	3nrLqP3sMTrcKUbEJJWjxeJ3R/piAQyaCwZKmBPYIW7gNcacJ29Spx8w/U608g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 26/09/2022 18:13, Hans Petter Selasky wrote:
> On 9/23/22 23:43, Hans Petter Selasky wrote:
>> vpanic() at 0xffffffff808f4c84 = vpanic+0x184/frame 0xfffffe003590e900
>> panic() at 0xffffffff808f4a33 = panic+0x43/frame 0xfffffe003590e960
>> sleepq_add() at 0xffffffff809521ab = sleepq_add+0x37b/frame 0xfffffe003590e9b0
>> _sleep() at 0xffffffff80902118 = _sleep+0x238/frame 0xfffffe003590ea40
>> usbhid_sync_xfer() at 0xffffffff8532e071 = usbhid_sync_xfer+0x171/frame 
>> 0xfffffe003590eaa0
>> usbhid_set_report() at 0xffffffff8532db26 = usbhid_set_report+0x96/frame 
>> 0xfffffe003590eae0
>> hid_set_report() at 0xffffffff80686caa = hid_set_report+0x6a/frame 
>> 0xfffffe003590eb20
>> hidbus_write() at 0xffffffff85335a7c = hidbus_write+0x5c/frame 0xfffffe003590eb50
>> hid_write() at 0xffffffff80686b98 = hid_write+0x58/frame 0xfffffe003590eb80
>> hkbd_set_leds() at 0xffffffff85c1cfe6 = hkbd_set_leds+0x206/frame 
>> 0xfffffe003590ebc0
>> hkbd_ioctl_locked() at 0xffffffff85c1cd6b = hkbd_ioctl_locked+0x33b/frame 
>> 0xfffffe003590ec20
>> hkbd_ioctl_locked() at 0xffffffff85c1caff = hkbd_ioctl_locked+0xcf/frame 
>> 0xfffffe003590ec80
>> hkbd_ioctl() at 0xffffffff85c1ba5a = hkbd_ioctl+0xba/frame 0xfffffe003590ecc0
>> kbdmux_ioctl() at 0xffffffff80695d3b = kbdmux_ioctl+0x12b/frame 
>> 0xfffffe003590ed00
>> vt_window_switch() at 0xffffffff8079d969 = vt_window_switch+0x229/frame 
>> 0xfffffe003590ed40
>> vt_switch_timer() at 0xffffffff807a15a1 = vt_switch_timer+0x21/frame 
>> 0xfffffe003590ed60
> 
> Can you test this patch:
> https://reviews.freebsd.org/D36715

Sorry that it took a while.
I cannot reproduce the problem after applying the patch.
I see that you already committed the change, but I thought that I'd let you know.
Thank you very much!

-- 
Andriy Gapon


From nobody Fri Sep 30 12:08:12 2022
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 4Mf8Bw51pCz4dhd5;
	Fri, 30 Sep 2022 12:08:24 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4Mf8Bv5gsGz3XP3;
	Fri, 30 Sep 2022 12:08:23 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 0FF962601C3;
	Fri, 30 Sep 2022 14:08:15 +0200 (CEST)
Message-ID: 
Date: Fri, 30 Sep 2022 14:08:12 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: usbhid panic when switching vt-s (invariants+witness enabled)
Content-Language: en-US
To: Andriy Gapon , freebsd-stable List 
Cc: FreeBSD Current ,
 Vladimir Kondratyev 
References: 
 <0668f473-f6d3-eacf-e4ef-f8530563daed@selasky.org>
 
 <88231845-21c6-302a-4ea8-962877470284@FreeBSD.org>
From: Hans Petter Selasky 
In-Reply-To: <88231845-21c6-302a-4ea8-962877470284@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Mf8Bv5gsGz3XP3
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.987];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_ALL(0.00)[];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[current@FreeBSD.org,stable@FreeBSD.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 9/30/22 12:31, Andriy Gapon wrote:
> On 26/09/2022 18:13, Hans Petter Selasky wrote:
>> On 9/23/22 23:43, Hans Petter Selasky wrote:
>>> vpanic() at 0xffffffff808f4c84 = vpanic+0x184/frame 0xfffffe003590e900
>>> panic() at 0xffffffff808f4a33 = panic+0x43/frame 0xfffffe003590e960
>>> sleepq_add() at 0xffffffff809521ab = sleepq_add+0x37b/frame 
>>> 0xfffffe003590e9b0
>>> _sleep() at 0xffffffff80902118 = _sleep+0x238/frame 0xfffffe003590ea40
>>> usbhid_sync_xfer() at 0xffffffff8532e071 = 
>>> usbhid_sync_xfer+0x171/frame 0xfffffe003590eaa0
>>> usbhid_set_report() at 0xffffffff8532db26 = 
>>> usbhid_set_report+0x96/frame 0xfffffe003590eae0
>>> hid_set_report() at 0xffffffff80686caa = hid_set_report+0x6a/frame 
>>> 0xfffffe003590eb20
>>> hidbus_write() at 0xffffffff85335a7c = hidbus_write+0x5c/frame 
>>> 0xfffffe003590eb50
>>> hid_write() at 0xffffffff80686b98 = hid_write+0x58/frame 
>>> 0xfffffe003590eb80
>>> hkbd_set_leds() at 0xffffffff85c1cfe6 = hkbd_set_leds+0x206/frame 
>>> 0xfffffe003590ebc0
>>> hkbd_ioctl_locked() at 0xffffffff85c1cd6b = 
>>> hkbd_ioctl_locked+0x33b/frame 0xfffffe003590ec20
>>> hkbd_ioctl_locked() at 0xffffffff85c1caff = 
>>> hkbd_ioctl_locked+0xcf/frame 0xfffffe003590ec80
>>> hkbd_ioctl() at 0xffffffff85c1ba5a = hkbd_ioctl+0xba/frame 
>>> 0xfffffe003590ecc0
>>> kbdmux_ioctl() at 0xffffffff80695d3b = kbdmux_ioctl+0x12b/frame 
>>> 0xfffffe003590ed00
>>> vt_window_switch() at 0xffffffff8079d969 = 
>>> vt_window_switch+0x229/frame 0xfffffe003590ed40
>>> vt_switch_timer() at 0xffffffff807a15a1 = vt_switch_timer+0x21/frame 
>>> 0xfffffe003590ed60
>>
>> Can you test this patch:
>> https://reviews.freebsd.org/D36715
> 
> Sorry that it took a while.
> I cannot reproduce the problem after applying the patch.
> I see that you already committed the change, but I thought that I'd let 
> you know.
> Thank you very much!
> 

You are welcome!

--HPS

From nobody Sat Oct  1 21:57:29 2022
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 4Mg1DX1fzjz4f68g
	for ; Sat,  1 Oct 2022 21:57:48 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mg1DV02Kqz3SNB
	for ; Sat,  1 Oct 2022 21:57:46 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To:
	From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=Jrri14YFw/R/3PpiA7BudN1+stPV3hZxh0SogMbSlhU=; b=lu7584hG+12bMX5etBUFQOQ3cH
	qFpnXOgQFCu5lP/BV5CRKYfbNDvghvZvc+OjRLFgVP5HGQ/WA/uFxEGNGAgysORsacC/cxEqCzRXy
	OWPYI6p1Es0VM7MtyC609mSKkBCGeNjx0slCuM4WDcyCje3GntY4deiba84eJtZU0IzFsiIaj4J3u
	ERhV4300y7cqzeOLVPGyWN4RKnwHwossw0I5Iu3gNxJJ7xh3+UG0kRKpGaK8bP6qd0JhrpxF1eazG
	le0NHlBPDlbv+IF8ZviuZdJu4ZLX5P1RtJRgV0Ju2aUXee2g6Z2gH3OmhyYUxkF8UtbQRlhpWjKrE
	kYDfSGqQ==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:37088 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oekUD-000NFA-UM
	for freebsd-current@freebsd.org;
	Sat, 01 Oct 2022 16:57:29 -0500
Received: from 2600:1700:210:b18f:8cb4:f417:c3e6:a42
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sat, 01 Oct 2022 16:57:29 -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
Date: Sat, 01 Oct 2022 16:57:29 -0500
From: Larry Rosenman 
To: Freebsd current 
Subject: Build Break?
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Mg1DV02Kqz3SNB
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=lu7584hG;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-2.99 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:55103, ipnet:192.147.25.0/24, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[ler];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--- all_subdir_nfscommon ---
Building 
/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/nfscommon/nfs_commonkrpc.o
--- all_subdir_netgraph ---
--- all_subdir_netgraph/deflate ---
Building 
/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/deflate/offset.inc
--- all_subdir_netgraph/device ---
Building 
/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/device/i386
--- all_subdir_netgraph/echo ---
===> netgraph/echo (all)
--- all_subdir_netlink ---
--- netlink_io.o ---
/usr/src/sys/netlink/netlink_io.c:146:2: error: implicit declaration of 
function 'mtx_lock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
         NLP_LOCK(nlp);
         ^
/usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro 
'NLP_LOCK'
#define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:159:2: error: implicit declaration of 
function 'mtx_unlock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
         NLP_UNLOCK(nlp);
         ^
/usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
'NLP_UNLOCK'
#define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:159:2: note: did you mean 'mtx_lock'?
/usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
'NLP_UNLOCK'
#define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:146:2: note: 'mtx_lock' declared here
         NLP_LOCK(nlp);
         ^
/usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro 
'NLP_LOCK'
#define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:177:2: error: implicit declaration of 
function 'mtx_lock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
         SOCKBUF_LOCK(sb);
         ^
/usr/src/sys/sys/sockbuf.h:187:28: note: expanded from macro 
'SOCKBUF_LOCK'
#define SOCKBUF_LOCK(_sb)               mtx_lock(SOCKBUF_MTX(_sb))
                                         ^
/usr/src/sys/netlink/netlink_io.c:189:2: error: implicit declaration of 
function 'mtx_unlock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
         SOCKBUF_UNLOCK(sb);
         ^
/usr/src/sys/sys/sockbuf.h:189:30: note: expanded from macro 
'SOCKBUF_UNLOCK'
#define SOCKBUF_UNLOCK(_sb)             mtx_unlock(SOCKBUF_MTX(_sb))
                                         ^
/usr/src/sys/netlink/netlink_io.c:202:2: error: implicit declaration of 
function 'mtx_lock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
         NLP_LOCK(nlp);
         ^
/usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro 
'NLP_LOCK'
#define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:207:3: error: implicit declaration of 
function 'mtx_unlock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
                 NLP_UNLOCK(nlp);
                 ^
/usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
'NLP_UNLOCK'
#define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:225:3: error: implicit declaration of 
function 'mtx_unlock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
                 SOCKBUF_UNLOCK(sb);
                 ^
/usr/src/sys/sys/sockbuf.h:189:30: note: expanded from macro 
'SOCKBUF_UNLOCK'
#define SOCKBUF_UNLOCK(_sb)             mtx_unlock(SOCKBUF_MTX(_sb))
                                         ^
/usr/src/sys/netlink/netlink_io.c:232:2: error: implicit declaration of 
function 'mtx_unlock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
         NLP_UNLOCK(nlp);
         ^
/usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
'NLP_UNLOCK'
#define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:281:2: error: implicit declaration of 
function 'mtx_lock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
         NLP_LOCK(nlp);
         ^
/usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro 
'NLP_LOCK'
#define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:299:2: error: implicit declaration of 
function 'mtx_unlock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
         NLP_UNLOCK(nlp);
         ^
/usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
'NLP_UNLOCK'
#define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:354:2: error: implicit declaration of 
function 'mtx_lock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
         NLP_LOCK(nlp);
         ^
/usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro 
'NLP_LOCK'
#define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:357:3: error: implicit declaration of 
function 'mtx_unlock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
                 NLP_UNLOCK(nlp);
                 ^
/usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
'NLP_UNLOCK'
#define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:369:3: error: implicit declaration of 
function 'mtx_unlock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
                 NLP_UNLOCK(nlp);
                 ^
/usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
'NLP_UNLOCK'
#define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:395:2: error: implicit declaration of 
function 'mtx_unlock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
         NLP_UNLOCK(nlp);
         ^
/usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
'NLP_UNLOCK'
#define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:519:3: error: implicit declaration of 
function 'mtx_lock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
                 NLP_LOCK(nlp);
                 ^
/usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro 
'NLP_LOCK'
#define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
                                 ^
/usr/src/sys/netlink/netlink_io.c:521:3: error: implicit declaration of 
function 'mtx_unlock' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
                 NLP_UNLOCK(nlp);
                 ^
/usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro 
'NLP_UNLOCK'
#define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
                                 ^
16 errors generated.
--- all_subdir_netgraph ---
--- all_subdir_netgraph/device ---
--- i386 ---
i386 -> /usr/src/sys/i386/include
Building 
/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/device/vnode_if_newproto.h
--- all_subdir_netlink ---
*** [netlink_io.o] Error code 1

make[4]: stopped in /usr/src/sys/modules/netlink
.ERROR_TARGET='netlink_io.o'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netlink/netlink_io.o.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes 
verbose'
         5.79 real        30.04 user         9.35 sys

make[1]: stopped in /usr/src

make: stopped in /usr/src

ler in 🌠borg in src🔒 on î‚  ler/freebsd-main-changes:main [⇡] on â˜ï¸  
(us-east-1) took 1m56s
â¯

ler in 🌠borg in src🔒 on î‚  ler/freebsd-main-changes:main [⇡] on â˜ï¸  
(us-east-1)
â¯



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Sun Oct  2 02:39:24 2022
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 4Mg7TX2dvxz4dgM6
	for ; Sun,  2 Oct 2022 02:39:28 +0000 (UTC)
	(envelope-from ler@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mg7TX24MQz3pj6;
	Sun,  2 Oct 2022 02:39:28 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664678368;
	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=I+pDxCXfT1x4itBP94y+eugLLce+/wSgb8KdwuyXq8Y=;
	b=kDJMRM2m9OlhuGx3o06lVEQytBRfVgiPVZ6BPwJn5kZBV2MRmYL0z5hrlY2gwl3MjeNH/k
	jUwYiPZQ78FLEiKZGluL4G3uaX1gm3jmhT3Hkeoi1s+p9RzCETVI0MbDb9f10Hdb+8+hN5
	6HeTGbnKpd/FBQVLz1VD36QqoeeRIF7RBuVU2k3SFsVaBYgLIRCMiuzWWKhrBsYKrsi+rC
	NuzFxONJCers0InaZ+PjR1K19uB54Dy5fjY6upNbIeiogIGCqicbyqPJqGerbXqus9sayt
	nEqE3j8Utf8DBRiiQI+vviCYhkBwpiwNKA/j0U7BBh4o/brbmE4BICd8VfZaAA==
Received: from thebighonker.lerctr.org (unknown [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	(Authenticated sender: ler/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mg7TX0vs0z19Sj;
	Sun,  2 Oct 2022 02:39:28 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To:
	From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=I+pDxCXfT1x4itBP94y+eugLLce+/wSgb8KdwuyXq8Y=; b=Ts7wzwjJbZtzgWxQ/89YktK02s
	Rssk89e3UuvW4+frwrDwm9SvjfrP8YSYYwgmR1jrW34woLHKnPqq9N3YiyPPPGB0PyKlwSTxqNlte
	bjJFRWSoeag9ChngbWCfeLpCZ1hg9+vsNHu2uE4XoVZY1Vz+4zcAWKCG5ViuJzvZtXxsfmD2vcOC4
	h/L06cLXiKWFCvgg4sShtwjSmjOn2nHKGALDu/Xc2DSBciQXXN+JifRt4Q1mow4APg1MWfW6vqiZB
	7UUFc+8ehDGh32I7nMhuHLxRzIPzS9vq+45nddli6j9R5afZGu6r5jafhc2WmBVk+DY/noOCvWCCC
	0CaIB8GQ==;
Authentication-Results: thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
Received-SPF: softfail (thebighonker.lerctr.org: transitioning domain of FreeBSD.org does not designate 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@FreeBSD.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:61112 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oeot3-0001lo-6W;
	Sat, 01 Oct 2022 21:39:25 -0500
Received: from 2600:1700:210:b18f:8cb4:f417:c3e6:a42
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sat, 01 Oct 2022 21:39:24 -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
Date: Sat, 01 Oct 2022 21:39:24 -0500
From: Larry Rosenman 
To: Freebsd current , Mark Johnston
 
Subject: BOOT CRASH -- Current -CURRENT
Message-ID: <9de62c1d7c3eae83b97a1004780a8d0d@FreeBSD.org>
X-Sender: ler@FreeBSD.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664678368;
	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:dkim-signature;
	bh=I+pDxCXfT1x4itBP94y+eugLLce+/wSgb8KdwuyXq8Y=;
	b=An/pwWZ3k9mudZftpkQ46sV11/hx4GPEMsYjeHnSJrxY295RDC5u2IyTrmtKH6S7n6BFG+
	44aoC2JcbkEJBt794ZmZ6L0V6S1n1z+2qcA5Kz/UHZ7YDMqVF/nNCCXqnGvxagfmtEp83c
	3UqPBvyGxtuAVL/gqnFrydExNp4cBCAUoosBHfJRvOF7fmM/dWszLXipBzxHk92sBoBDwS
	3qOySXYHkjxRJOXJZJPZ55FFspuZvOKWk4LVi7vbQG7hCtpSiRBTUhLvzIejgma+k2a9ln
	EgaNBdxu2AAEK/UIfbwHDfRhRu9Bd50KotbXLgSb/o8bVv5BC0Tt2lx3anDiOQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664678368; a=rsa-sha256; cv=none;
	b=ncGndOFfXMqo8yjP7GoORYw8vMyBVkzTLYVnCJZs4KutdERDPYn8VwzPVsl7zsd8eeRA4S
	3IiGlamn7T5IDNXqaErFbnYCkduVKhKZqfFZguy+/8nNui7dvFzFmt2lARY7DAbpBA3Ggq
	Kwrj9mOpmHKmkYdiXE0xB14CSolwkLKl4uQiwsaInggj+isWY5CWjL2lacgkrvGSeSBuKd
	HVyTHr4PesB91utHkY/uLcLQVHLzkNXej58usT1GOU7xMEt0SYKTGGejYZrdEU23JINeCY
	79IQu7R/cPsXCJEoHnPuiL9GBiEFknBR0i9nsIr16kh/oq67j+Uyy1s7QNwOew==
ARC-Authentication-Results: i=1;
	thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
X-ThisMailContainsUnwantedMimeParts: N


⯠more info.11
Dump header from device: /dev/mfid0p3
   Architecture: amd64
   Architecture Version: 2
   Dump Length: 126748815
   Blocksize: 512
   Compression: zstd
   Dumptime: 2022-10-01 21:26:40 -0500
   Hostname:
   Magic: FreeBSD Kernel Dump
   Version String: FreeBSD 14.0-CURRENT #168 
ler/freebsd-main-changes-n258354-6cdd871ebc4: Sat Oct  1 21:13:01 CDT 
2022
     root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
   Panic String: page fault
   Dump Parity: 501115454
   Bounds: 11
   Dump Status: good

I do have source and debug stuff, BUT kgdb croaks on me.

I *CAN* give access to the machine.

the console backtrace showed something about the kld load of 
dependencies.



-- 
Larry Rosenman                     http://people.freebsd.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Sun Oct  2 02:55:46 2022
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 4Mg7rN3rlDz4dhYK
	for ; Sun,  2 Oct 2022 02:55:48 +0000 (UTC)
	(envelope-from ler@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mg7rN3Mf4z3r7r;
	Sun,  2 Oct 2022 02:55:48 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664679348;
	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=YP8E9NkOMZR0/yHscX4O18hPwTB61wOE3L428Xpbbys=;
	b=QOaNG9VeviQAG9qCgLClMhj96fsYazM+nZVGVR2dhnh7Ci2eHD8bu9QlqcxRJm+MbHQ/f/
	OUiZR9EOAPqbu3d8AG/6n8JhjCBvwa5GGvMcb3ACQMQtT+pg1NqjHNUtWcPOFdk6DOTyQr
	HbCg79pcRmYh7Vs5vH6Hyraamh065Ytg97m2C3/ab5vvxHkekUICTkaKQVOn3nlysDeEOL
	lAT5pp83PjHYCwVilRvLb86W673nFi2Zj7xGEbFyFcn2a3MN/Yxho9azSfhb8aK2l+89cP
	u7wJQkm48Kmvah2Dl88sAYfTGFwI8j6DIKEybctuzEBs/W3dgR4VUg3pfF9hlw==
Received: from thebighonker.lerctr.org (unknown [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	(Authenticated sender: ler/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mg7rN1Yncz19HG;
	Sun,  2 Oct 2022 02:55:48 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:References:
	In-Reply-To:Subject:To:From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=YP8E9NkOMZR0/yHscX4O18hPwTB61wOE3L428Xpbbys=; b=kk+5/SLUyiL1TykGlffBr1VbDQ
	vRZ1RBmWMeex1jI0vEaA9KihBjN0cWEV0IENMrfsmlDQ1FGUSaMX/8eUOTZF2u6aOh/zzFbXcPqKz
	W53OALVo5O7lxh58ueUVoowqBWIQ8RxC2Guc3EPvZB14XCckkzcf2vB6R5NXjhEPY0bnFneZRvX+O
	KAlQggFe9vrAqIdIWhji/rklq70gukm2NXnWDccPOPNCsuBSl3PJIcDW4S2DEKSkJMZll+rD9wz1h
	kgjl/akpWet/W5rsjIiqlzz0p17T2wCQA9iQHi/pj+WHMO8dtQ8S2DsaKTJhjAOAh9fc/bz3v8Ecj
	WwsPewHQ==;
Authentication-Results: thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
Received-SPF: softfail (thebighonker.lerctr.org: transitioning domain of FreeBSD.org does not designate 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@FreeBSD.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:55792 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oep8s-0002E5-7g;
	Sat, 01 Oct 2022 21:55:46 -0500
Received: from 2600:1700:210:b18f:8cb4:f417:c3e6:a42
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sat, 01 Oct 2022 21:55:46 -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
Date: Sat, 01 Oct 2022 21:55:46 -0500
From: Larry Rosenman 
To: Freebsd current , Mark Johnston
 
Subject: Re: BOOT CRASH -- Current -CURRENT
In-Reply-To: <9de62c1d7c3eae83b97a1004780a8d0d@FreeBSD.org>
References: <9de62c1d7c3eae83b97a1004780a8d0d@FreeBSD.org>
Message-ID: <8333399b3872514e621554c25ed42068@FreeBSD.org>
X-Sender: ler@FreeBSD.org
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664679348;
	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:dkim-signature;
	bh=YP8E9NkOMZR0/yHscX4O18hPwTB61wOE3L428Xpbbys=;
	b=dSi5uNv1R8fwpUcC/awFhfSV6Sv8ZMtalpNQgxzR6qkP2QZBIrn3y7gk0ubOQ0EqG9FB8j
	5xFGmBjiVEN53AhWgvzUZ5Zuju9XVyrQcMudXUf0RtJr71NaDWmvux4ijljrGKoiIuXlID
	DeWqGMivhzJ/mcZH/5ya5Ex7l6JsIFSRkxWszCUpGxmFrsNDsv3D0OTtLL8T0Shx7W2xxT
	x9ZLuhao7hrB4eXUY8k2iREvUbiEOYWsIlzC2hvncrrLk1r7F8528xzimVfPsPQZzWGIS2
	eSc8KCzByxyKhescTy1IkMtxQL9CiUEiYag05G1UBguX+WN+rxCiL1I7o70FfQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664679348; a=rsa-sha256; cv=none;
	b=mlSYRrwejBw00tQa/DXbwCvKT+W8FfXFgVLu+chMN4SX8bQoYh9l6Z0cGKkgLJh9jbDB78
	hs0jQh60rKFQF3Z4nURhijqERZ0PMcTCTWrg2Udicl8FxwcL26yG2hx1RuWVUAyqxXOEFO
	iKDdkq1D0D4Tld+KVTc2wfXWlifUHTezYjEWjsFxcacLB0BCa6Y51BVWZHHFEk3epcvffx
	GzrV+gVhBKddu9fwvxNrmTN0Y61e5YhA80R/mcigM43Zj2nbSLZRp+npbl5NPlyWP2j9oa
	edUMgPyLY7NWSrM5s2l5c8wx6zd+QvQB40UXP3XHyF8DkK4LCfjXt9HuLVb7aA==
ARC-Authentication-Results: i=1;
	thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
X-ThisMailContainsUnwantedMimeParts: N

On 10/01/2022 9:39 pm, Larry Rosenman wrote:
> ⯠more info.11
> Dump header from device: /dev/mfid0p3
>   Architecture: amd64
>   Architecture Version: 2
>   Dump Length: 126748815
>   Blocksize: 512
>   Compression: zstd
>   Dumptime: 2022-10-01 21:26:40 -0500
>   Hostname:
>   Magic: FreeBSD Kernel Dump
>   Version String: FreeBSD 14.0-CURRENT #168 
> ler/freebsd-main-changes-n258354-6cdd871ebc4: Sat Oct  1 21:13:01 CDT 
> 2022
>     root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
>   Panic String: page fault
>   Dump Parity: 501115454
>   Bounds: 11
>   Dump Status: good
> 
> I do have source and debug stuff, BUT kgdb croaks on me.
> 
> I *CAN* give access to the machine.
> 
> the console backtrace showed something about the kld load of 
> dependencies.

Here's the BT:
⯠sudo kgdb -c vmcore.11 /mnt/usr/lib/debug/boot/kernel/kernel.debug
GNU gdb (GDB) 12.1 [GDB v12.1 for FreeBSD]
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
     .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/usr/lib/debug/boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:
---<>---
Copyright (c) 1992-2022 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 14.0-CURRENT #168 ler/freebsd-main-changes-n258354-6cdd871ebc4: 
Sat Oct  1 21:13:01 CDT 2022
     root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL 
amd64
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git 
llvmorg-14.0.5-0-gc12386ae247c)
VT(efifb): resolution 640x480
CPU: Intel(R) Xeon(R) CPU           X5660  @ 2.80GHz (2793.07-MHz 
K8-class CPU)
   Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c  Stepping=2
   
Features=0xbfebfbff
   
Features2=0x29ee3ff
   AMD Features=0x2c100800
   AMD Features2=0x1
   Structured Extended Features3=0x9c000000
   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
   TSC: P-state invariant, performance statistics
real memory  = 137438953472 (131072 MB)
avail memory = 133789515776 (127591 MB)
CPU microcode: no matching update found
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs
FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 hardware threads
random: unblocking device.
ioapic1: MADT APIC ID 1 != hw id 0
ioapic0  irqs 0-23
ioapic1  irqs 32-55
Launching APs: 1 8 7 5 2 12 15 17 14 20 3 18 13 4 19 10 22 11 6 9 16 23 
21
TCP_ratelimit: Is now initialized
TCP Hpts created 24 swi interrupt threads and bound 24 to NUMA domains
random: entropy device external interface
kbd1 at kbdmux0
acpi0: 
acpi0: Power Button (fixed)
apei0:  on acpi0
cpu0:  on acpi0
atrtc0:  port 0x70-0x7f irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x5f irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0:  iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 350
Event timer "HPET1" frequency 14318180 Hz quality 340
Event timer "HPET2" frequency 14318180 Hz quality 340
Event timer "HPET3" frequency 14318180 Hz quality 340
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
pci1:  at device 0.1 (no driver attached)
pcib2:  at device 3.0 on pci0
pci2:  on pcib2
pci2:  at device 0.0 (no driver attached)
pci2:  at device 0.1 (no driver attached)
pcib3:  at device 4.0 on pci0
pci3:  on pcib3
mfi0:  port 0xfc00-0xfcff mem 
0xdf1bc000-0xdf1bffff,0xdf1c0000-0xdf1fffff irq 33 at device 0.0 on pci3
mfi0: Using MSI
mfi0: Megaraid SAS driver Ver 4.23
mfi0: FW MaxCmds = 1008, limiting to 128
mfi0: 55158 (717992596s/0x0020/info) - Shutdown command received from 
host
pcib4: mfi0: 55159 (boot + 33s/0x0020/info) - 
Firmware initialization started (PCI ID 0079/1000/1f17/1028)
mfi0: 55160 (boot + 33s/0x0020/info) - Firmware version 2.100.03-4651
  at device 5.0 on pci0
pci4: mfi0: 55161 (boot + 35s/0x0008/info) - Battery 
Present
mfi0: 55162 (boot + 35s/0x0020/info) - Package version 12.10.7-0001
mfi0: 55163 (boot + 35s/0x0020/info) - Board Revision A00
  on pcib4
pcib5: mfi0: 55164 (boot + 63s/0x0004/info) - 
Enclosure PD 20(c None/p0) communication restored
  at device 6.0 on pci0
pci5: mfi0: 55165 (boot + 63s/0x0002/info) - Inserted: 
Encl PD 20
mfi0: 55166 (boot + 63s/0x0002/info) - Inserted: PD 20(c None/p0) Info: 
enclPd=20, scsiType=d, portMap=00, sasAddr=5b4ba0b019ef on pcib5
pcib6: e700,0000000000000000
mfi0: 55167 (boot + 63s/0x0002/info) - Inserted: PD 00(e0x20/s0)
  at device 7.0 on pci0
pci6: mfi0: 55168 (boot + 63s/0x0002/info) - Inserted: PD 
00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=04, 
sasAddr=4433221107000 on pcib6
pcib7: 000,0000000000000000
mfi0: 55169 (boot + 63s/0x0002/WARN) - PD 00(e0x20/s0) is not a 
certified drive
mfi0: 55170 (boot + 63s/0x0002/info) - Inserted: PD 01(e0x20/s1)
  at device 9.0 on pci0
pci7: mfi0: 55171 (boot + 63s/0x0002/info) - Inserted: PD 
01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=05, 
sasAddr=4433221106000 on pcib7
pci0: 000,0000000000000000
mfi0: 55172 (boot + 63s/0x0002/WARN) - PD 01(e0x20/s1) is not a 
certified drive
mfi0: 55173 (boot + 63s/0x0002/info) - Inserted: PD 02(e0x20/s2)
  at device 20.0 (no driver attached)
pci0: mfi0: 55174 (boot + 
63s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: enclPd=20, 
scsiType=0, portMap=02, sasAddr=4433221105000 at device 20.1 (no driver 
attached)
pci0: 000,0000000000000000
mfi0: 55175 (boot + 63s/0x0002/WARN) - PD 02(e0x20/s2) is not a 
certified drive
mfi0: 55176 (boot + 63s/0x0002/info) - Inserted: PD 03(e0x20/s3)
  at device 20.2 (no driver attached)
uhci0: mfi0: 55177 (boot + 
63s/0x0002/info) - Inserted: PD 03(e0x20/s3) Info: enclPd=20, 
scsiType=0, portMap=01, sasAddr=4433221104000 port 0xec40-0xec5f irq 17 
at device 26.0 on pci0
000,0000000000000000
mfi0: 55178 (boot + 63s/0x0002/WARN) - PD 03(e0x20/s3) is not a 
certified drive
mfi0: 55179 (boot + 63s/0x0002/info) - Inserted: PD 04(e0x20/s4)
mfi0: 55180 (boot + 63s/0x0002/info) - Inserted: PD 04(e0x20/s4) Info: 
enclPd=20, scsiType=0, portMap=03, 
sasAddr=4433221103000000,0000000000000000
mfi0: 55181 (boot + 63s/0x0002/WARN) - PD 04(e0x20/s4) is not a 
certified drive
mfi0: 55182 (boot + 63s/0x0002/info) - Inserted: PD 05(e0x20/s5)
usbus0 on uhci0
mfi0: 55183 (boot + 63s/0x0002/info) - Inserted: PD 05(e0x20/s5) Info: 
enclPd=20, scsiType=0, portMap=00, 
sasAddr=4433221102000000,0000000000000000
mfi0: 55184 (boot + 63s/0x0002/WARN) - PD 05(e0x20/s5) is not a 
certified drive
mfi0: 55185 (717992711s/0x0020/info) - Time established as 10/02/22  
2:25:11; (86 seconds since power on)
mfi0: 55186 (717992725s/0x0008/info) - Battery temperature is normal
mfi0: 55187 (717992725s/0x0008/info) - Current capacity of the battery 
is above threshold
usbus0: 12Mbps Full Speed USB v1.0
uhci1: mfi0: 55188 
(717992725s/0x0008/info) - Battery started charging
  port 0xec60-0xec7f irq 18 at device 26.1 on pci0
usbus1 on uhci1
usbus1: 12Mbps Full Speed USB v1.0
ehci0:  mem 
0xdf0de000-0xdf0de3ff irq 19 at device 26.7 on pci0
usbus2: EHCI version 1.0
usbus2 on ehci0
usbus2: 480Mbps High Speed USB v2.0
uhci2:  port 0xec80-0xec9f irq 21 at 
device 29.0 on pci0
usbus3 on uhci2
usbus3: 12Mbps Full Speed USB v1.0
uhci3:  port 0xeca0-0xecbf irq 20 at 
device 29.1 on pci0
usbus4 on uhci3
usbus4: 12Mbps Full Speed USB v1.0
ehci1:  mem 
0xdf0df000-0xdf0df3ff irq 21 at device 29.7 on pci0
usbus5: EHCI version 1.0
usbus5 on ehci1
usbus5: 480Mbps High Speed USB v2.0
pcib8:  at device 30.0 on pci0
pci8:  on pcib8
vgapci0:  mem 
0xd5800000-0xd5ffffff,0xde7fc000-0xde7fffff,0xde800000-0xdeffffff irq 19 
at device 3.0 on pci8
vgapci0: Boot video device
isab0:  at device 31.0 on pci0
isa0:  on isab0
pci0:  at device 31.2 (no driver attached)
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (115200,n,8,1)
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
orm0:  at iomem 
0xc0000-0xc7fff,0xc8000-0xcdfff,0xec000-0xeffff pnpid ORM0000 on isa0
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
est0:  on cpu0
Timecounter "TSC-low" frequency 1396499882 Hz quality 1000
Timecounters tick every 1.000 msec
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
ugen0.1:  at usbus0
ugen1.1:  at usbus1
ugen5.1:  at usbus5
ugen2.1:  at usbus2
mfid0 on mfi0
mfid0: 1907200MB (3905945600 sectors) RAID volume 'Disk2' is optimal
ugen3.1:  at usbus3
ugen4.1:  at usbus4
mfid1 on mfi0
mfid1: 1907200MB (3905945600 sectors) RAID volume 'Disk1' is optimal
uhub0 on usbus1
uhub0:  on usbus1
uhub1 on usbus0
mfid2 on mfi0
mfid2: 2861056MB (5859442688 sectors) RAID volume 'Disk0' is optimal
uhub1:  on usbus0
uhub2 on usbus3
uhub2:  on usbus3
uhub3 on usbus4
uhub3:  on usbus4
uhub4 on usbus5
uhub4:  on usbus5
mfid3 on mfi0
mfid3: 2861056MB (5859442688 sectors) RAID volume 'Disk4' is optimal
uhub5 on usbus2
uhub5:  on usbus2
mfid4 on mfi0
mfid4: 1907200MB (3905945600 sectors) RAID volume 'Disk3' is optimal
mfid5 on mfi0
mfid5: 1907200MB (3905945600 sectors) RAID volume 'DIsk5' is optimal
Trying to mount root from zfs:zroot/ROOT/14-2022_10_01-2113 []...
uhub0: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub3: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
Root mount waiting for: usbus2 usbus5
uhub4: 4 ports with 4 removable, self powered
uhub5: 4 ports with 4 removable, self powered
Root mount waiting for: usbus2 usbus5
ugen2.2:  at usbus2
uhub6 on uhub5
uhub6:  
on usbus2
uhub6: MTT enabled
uhub6: 3 ports with 3 removable, self powered
ugen0.2:  at usbus0
ukbd0 on uhub1
ukbd0:  on usbus0
kbd2 at ukbd0
ugen3.2:  at usbus3
ugen3.3:  at usbus3
ukbd1 on uhub2
ukbd1:  on usbus3
kbd3 at ukbd1
Dual Console: Video Primary, Serial Secondary
<118>sysctl: net.inet.tcp.functions_default=rack at line 55: No such 
file or directory
<118>Setting hostuuid: 4c4c4544-0035-4310-8048-c7c04f524c31.
<118>Setting hostid: 0xd7b851f2.
<118>no pools available to import
<118>Starting file system checks:
<118>Mounting local filesystems:.
<118>Loading kernel modules:
aesni0: 
coretemp0:  on cpu0
link_elf_obj: symbol nhgrp_get_group undefined
linker_load_file: /boot/kernel/netlink.ko - unsupported file type
KLD linux_common.ko: depends on netlink - not available or version 
mismatch
linker_load_file: /boot/kernel/linux_common.ko - unsupported file type
KLD linux.ko: depends on linux_common - not available or version 
mismatch
linker_load_file: /boot/kernel/linux.ko - unsupported file type
<118>kldload: an error occurred while loading module linux. Please check 
dmesg(8) for more details.
<118>/etc/rc: WARNING: Unable to load kernel module linux
ichwd0:  on isa0
efirtc0: 
efirtc0: registered as a time-of-day clock, resolution 1.000000s
ipmi0:  on isa0
ipmi0: KCS mode found at io 0xca8 alignment 0x4 on isa
ipmi0: IPMI device rev. 0, firmware rev. 2.92, version 2.0, device 
support mask 0xdf
ipmi0: Number of channels 5
ipmi0: Attached watchdog
ipmi0: Establishing power cycle handler
hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 
IAP/4/48/0x3ff 
IAF/3/48/0x67 
UCP/8/48/0x3f8 UCF/1/48/0x60
mfip0:  on mfi0
ioat0:  mem 0xdf0e0000-0xdf0e3fff irq 51 at device 22.0 on 
pci0
ioat0: Capabilities: 
77
ioat1:  mem 0xdf0e4000-0xdf0e7fff irq 52 at device 22.1 on 
pci0
ioat1: Capabilities: 
77
ioat2:  mem 0xdf0e8000-0xdf0ebfff irq 53 at device 22.2 on 
pci0
ioat2: Capabilities: 
77
ioat3:  mem 0xdf0ec000-0xdf0effff irq 54 at device 22.3 on 
pci0
ioat3: Capabilities: 
77
ioat4:  mem 0xdf0f0000-0xdf0f3fff irq 51 at device 22.4 on 
pci0
ioat4: Capabilities: 
77
ioat5:  mem 0xdf0f4000-0xdf0f7fff irq 52 at device 22.5 on 
pci0
ioat5: Capabilities: 
77
ioat6:  mem 0xdf0f8000-0xdf0fbfff irq 53 at device 22.6 on 
pci0
ioat6: Capabilities: 
77
ioat7:  mem 0xdf0fc000-0xdf0fffff irq 54 at device 22.7 on 
pci0
ioat7: Capabilities: 
77
bce0:  mem 
0xd6000000-0xd7ffffff irq 36 at device 0.0 on pci1
<6>bce0: Using defaults for TSO: 65518/35/2048
<6>bce0: Ethernet address: a4:ba:db:29:66:95
bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (7.10.0); 
Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)
Coal (RX:6,6,18,18; TX:20,20,80,80)
bce1:  mem 
0xd8000000-0xd9ffffff irq 48 at device 0.1 on pci1
<6>bce1: Using defaults for TSO: 65518/35/2048
<6>bce1: Ethernet address: a4:ba:db:29:66:97
bce1: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (7.10.0); 
Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)
Coal (RX:6,6,18,18; TX:20,20,80,80)
bce2:  mem 
0xda000000-0xdbffffff irq 32 at device 0.0 on pci2
<6>bce2: Using defaults for TSO: 65518/35/2048
<6>bce2: Ethernet address: a4:ba:db:29:66:99
bce2: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (7.10.0); 
Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)
Coal (RX:6,6,18,18; TX:20,20,80,80)
bce3:  mem 
0xdc000000-0xddffffff irq 42 at device 0.1 on pci2
<6>bce3: Using defaults for TSO: 65518/35/2048
<6>bce3: Ethernet address: a4:ba:db:29:66:9b
bce3: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (7.10.0); 
Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)
Coal (RX:6,6,18,18; TX:20,20,80,80)
miibus0:  on bce0
brgphy0:  PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
miibus1:  on bce1
brgphy1:  PHY 1 on miibus1
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
miibus2:  on bce2
brgphy2:  PHY 1 on miibus2
brgphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
miibus3:  on bce3
ses0 at mfi0 bus 0 scbus0 target 32 lun 0
ses0:  Fixed Enclosure Services SPC-3 SCSI device
ses0: 150.000MB/s transfers
ses0: SES Device
brgphy3:  PHY 1 on miibus3
brgphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
ums0 on uhub2
ums0:  on usbus3
ums0: 3 buttons and [Z] coordinates ID=0
atapci0:  port 
0xec10-0xec17,0xec08-0xec0b,0xec18-0xec1f,0xec0c-0xec0f,0xec20-0xec2f,0xec30-0xec3f 
irq 23 at device 31.2 on pci0
atapci0: failed to add ata child device
ata2:  at channel 0 on atapci0
device_attach: ata2 attach returned 6
<118>Autoloading module: acpi_wmi
acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
link_elf_obj: symbol nhgrp_get_group undefined
linker_load_file: /boot/kernel/netlink.ko - unsupported file type
KLD linux_common.ko: depends on netlink - not available or version 
mismatch


Fatal trap 12: page fault while in kernel mode
cpuid = 12; apic id = 00
fault virtual address	= 0x0
fault code		= supervisor read data, page not present
instruction pointer	= 0x20:0xffffffff8231c132
stack pointer	        = 0x28:0xfffffe02b284c530
frame pointer	        = 0x28:0xfffffe02b284c560
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 232 (kldload)
rdi: fffff80121ab14b0 rsi: fffffe02b284c538 rdx:                0
rcx: ffffffff825dbde0  r8:                4  r9:               f3
rax:                0 rbx: fffff801219f2000 rbp: fffffe02b284c560
r10:               f3 r11: ff9094d191909292 r12: fffff801219f2040
r13: fffffe02b284c584 r14: fffffe02b284c584 r15: ffffffff825dbdd0
trap number		= 12
panic: page fault
cpuid = 12
time = 1664677600
KDB: stack backtrace:
#0 0xffffffff80508e9d at kdb_backtrace+0x5d
#1 0xffffffff804bc741 at vpanic+0x151
#2 0xffffffff804bc5e3 at panic+0x43
#3 0xffffffff807afe59 at trap_fatal+0x409
#4 0xffffffff807afeaf at trap_pfault+0x4f
#5 0xffffffff80787d18 at calltrap+0x8
#6 0xffffffff8048fddb at linker_file_unload+0xdb
#7 0xffffffff807bc858 at link_elf_load_file+0x198
#8 0xffffffff8048f659 at linker_load_module+0x999
#9 0xffffffff804921b3 at linker_load_dependencies+0xe3
#10 0xffffffff807bd7b3 at link_elf_load_file+0x10f3
#11 0xffffffff8048f659 at linker_load_module+0x999
#12 0xffffffff80491351 at kern_kldload+0x141
#13 0xffffffff8049145b at sys_kldload+0x5b
#14 0xffffffff807b074c at amd64_syscall+0x10c
#15 0xffffffff8078862b at fast_syscall_common+0xf8
Uptime: 21s
Dumping 5418 out of 131021 
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:59
59		__asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
(kgdb) bt
#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:59
#1  dump_savectx () at /usr/src/sys/kern/kern_shutdown.c:405
#2  0xffffffff804bc2e8 in dumpsys (di=0x0)
     at /usr/src/sys/x86/include/dump.h:87
#3  doadump (textdump=) at 
/usr/src/sys/kern/kern_shutdown.c:434
#4  kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:541
#5  0xffffffff804bc7ae in vpanic (fmt=,
     ap=ap@entry=0xfffffe02b284c380) at 
/usr/src/sys/kern/kern_shutdown.c:979
#6  0xffffffff804bc5e3 in panic (fmt=)
     at /usr/src/sys/kern/kern_shutdown.c:903
#7  0xffffffff807afe59 in trap_fatal (frame=0xfffffe02b284c470, eva=0)
     at /usr/src/sys/amd64/amd64/trap.c:955
#8  0xffffffff807afeaf in trap_pfault (frame=0xfffffe02b284c470,
     usermode=false, signo=, ucode=)
     at /usr/src/sys/amd64/amd64/trap.c:763
#9  
#10 0xffffffff8231c132 in sdt_kld_unload_try (arg=,
     lf=, error=0xfffffe02b284c584)
     at /usr/src/sys/cddl/dev/sdt/sdt.c:345
#11 0xffffffff8048fddb in linker_file_unload (
     file=file@entry=0xfffff80116250780, flags=flags@entry=1)
     at /usr/src/sys/kern/kern_linker.c:675
#12 0xffffffff807bc858 in link_elf_load_file (cls=,
     filename=, result=)
--Type  for more, q to quit, c to continue without paging--
     at /usr/src/sys/kern/link_elf_obj.c:1243
#13 0xffffffff8048f659 in LINKER_LOAD_FILE (
     cls=0xffffffff80adb370 , result=0xfffffe02b284c800,
     filename=) at ./linker_if.h:214
#14 linker_load_file (filename=, result=)
     at /usr/src/sys/kern/kern_linker.c:461
#15 linker_load_module (kldname=kldname@entry=0x0,
     modname=modname@entry=0xffffffff825c292c "linux_common",
     parent=parent@entry=0xfffff80114a96d80,
     verinfo=verinfo@entry=0xffffffff825ce198 
<_linuxelf_depend_on_linux_common>, lfpp=lfpp@entry=0x0) at 
/usr/src/sys/kern/kern_linker.c:2205
#16 0xffffffff804921b3 in linker_load_dependencies (lf=0x0,
     lf@entry=0xfffff80114a96d80) at /usr/src/sys/kern/kern_linker.c:2295
#17 0xffffffff807bd7b3 in link_elf_load_file (cls=,
     filename=0xfffff8014f472480 "/boot/kernel/linux.ko",
     result=0xfffffe02b284cc10) at /usr/src/sys/kern/link_elf_obj.c:1212
#18 0xffffffff8048f659 in LINKER_LOAD_FILE (
     cls=0xffffffff80adb370 , result=0xfffffe02b284cc10,
     filename=) at ./linker_if.h:214
#19 linker_load_file (filename=, result=)
     at /usr/src/sys/kern/kern_linker.c:461
#20 linker_load_module (kldname=kldname@entry=0x0,
     modname=modname@entry=0xfffff80101a31c00 "linux", 
parent=parent@entry=0x0,
     verinfo=verinfo@entry=0x0, lfpp=lfpp@entry=0xfffffe02b284cda0)
--Type  for more, q to quit, c to continue without paging--
     at /usr/src/sys/kern/kern_linker.c:2205
#21 0xffffffff80491351 in kern_kldload (td=td@entry=0xfffffe024ad8c3a0,
     file=file@entry=0xfffff80101a31c00 "linux",
     fileid=fileid@entry=0xfffffe02b284cde4)
     at /usr/src/sys/kern/kern_linker.c:1164
#22 0xffffffff8049145b in sys_kldload (td=0xfffffe024ad8c3a0,
     uap=) at /usr/src/sys/kern/kern_linker.c:1187
#23 0xffffffff807b074c in syscallenter (td=0xfffffe024ad8c3a0)
     at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189
#24 amd64_syscall (td=0xfffffe024ad8c3a0, traced=0)
     at /usr/src/sys/amd64/amd64/trap.c:1200
#25 
#26 0x00000e4050df371a in ?? ()
Backtrace stopped: Cannot access memory at address 0xe404dfc6fa8
(kgdb)

What else do y'all need?
-- 
Larry Rosenman                     http://people.freebsd.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Sun Oct  2 03:04:56 2022
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 4Mg83C3GKSz4djn2
	for ; Sun,  2 Oct 2022 03:05:11 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mg83B3HGcz3sVL
	for ; Sun,  2 Oct 2022 03:05:10 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ed1-x529.google.com with SMTP id x59so524340ede.7
        for ; Sat, 01 Oct 2022 20:05:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=H7l9VqHc+OlOp74/PeT7x4/XU0yp+sFse1iQQTnC/vc=;
        b=2PbuGDm6LXgPWIeDcIA+7BbKA8zOUq9Y8gX7HBPVZOFmUnuPLF6qMLE2c/0cgGkjen
         jbjY/qlJYCbIbZS+v+6wh5tmfdd6pbM32bLwDIAbgXABeJqpHZYQIf2epzeutcrNqMw7
         yCMOpxZCNaZL0VsmCtDzIBNz/7Td2RBizfTzSJVO7DC0OJu8L3lM7RG/q/71mKQf28gL
         aC8NnwxvQzzmp+b+mG2j1/GnwH9tAt38109pFq87izBa5WOwu4G/2RiA77EZa19mx0c9
         Z2ASzi2G7ZGGycu5g+3yXkPPf5PVcPeygoGyk6uAaoy8rM7SoYO545MUZBAqRZzBHpF0
         hloA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=H7l9VqHc+OlOp74/PeT7x4/XU0yp+sFse1iQQTnC/vc=;
        b=HbbxEZ832SYqfGBmOZu/rEyICf9hq6ipOfCZkdEClI3l7G+CU3vA7vUm2aTTz19DRR
         udnHu3XLpXjeVYZbCeUna/IFPVfyVKIYZDZNFyEsqcVkIvpSRJNUVQV5bdqDdCW+IgTU
         RsCkYXTWmN0rqsusx3khTVbxqNNSJWEP8FxpQy5ds7WSOZeV0hRG/qfODBTIMpvef69g
         bjxGJsYPRDTE3VPP9/z2KOq02LqgYzbxJcuqv4gRuS9TvDE0iw+iF56vafH0uw1jvUXI
         QJ2E95k7L/4ZmZAi2xmeF6RbE1B7oupeMhwNJW3ywgVhiDHg3degDLDRfbnR/naodBFj
         z7RA==
X-Gm-Message-State: ACrzQf0ToP9TOAMd7/9TEBUeZzULotU6mJDJDVpH9ceEkua7HNAV6GiP
	9ZVF/zwxMAwd4L6w7qCQAa5DsZeo2ORdAz+CLoInIGHhHQY=
X-Google-Smtp-Source: AMsMyM7pJYmI6W1TnN5gFqFSGYlYWg3tthyqwraSTy60eeEV2IHUc+YoJrJF5bIbemvW20WoNcbtZ4q8t2qkUdh8pHk=
X-Received: by 2002:a05:6402:3206:b0:458:c6ef:a5aa with SMTP id
 g6-20020a056402320600b00458c6efa5aamr3164870eda.127.1664679907494; Sat, 01
 Oct 2022 20:05: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
References: <9de62c1d7c3eae83b97a1004780a8d0d@FreeBSD.org>
In-Reply-To: <9de62c1d7c3eae83b97a1004780a8d0d@FreeBSD.org>
From: Warner Losh 
Date: Sat, 1 Oct 2022 21:04:56 -0600
Message-ID: 
Subject: Re: BOOT CRASH -- Current -CURRENT
To: Larry Rosenman 
Cc: Freebsd current , Mark Johnston 
Content-Type: multipart/alternative; boundary="0000000000008d1e7305ea047e73"
X-Rspamd-Queue-Id: 4Mg83B3HGcz3sVL
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=2PbuGDm6;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::529) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000008d1e7305ea047e73
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Do  you have a /boot tarball that can be loaded in a VM that recreates the
problem (along with a clean hash)?

But before you try that, have you tried a completely clean rebuild of the
kernel to preclude the possibility that something is somehow cross threaded=
?

Warner

On Sat, Oct 1, 2022 at 8:39 PM Larry Rosenman  wrote:

>
> =E2=9D=AF more info.11
> Dump header from device: /dev/mfid0p3
>    Architecture: amd64
>    Architecture Version: 2
>    Dump Length: 126748815
>    Blocksize: 512
>    Compression: zstd
>    Dumptime: 2022-10-01 21:26:40 -0500
>    Hostname:
>    Magic: FreeBSD Kernel Dump
>    Version String: FreeBSD 14.0-CURRENT #168
> ler/freebsd-main-changes-n258354-6cdd871ebc4: Sat Oct  1 21:13:01 CDT
> 2022
>      root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
>    Panic String: page fault
>    Dump Parity: 501115454
>    Bounds: 11
>    Dump Status: good
>
> I do have source and debug stuff, BUT kgdb croaks on me.
>
> I *CAN* give access to the machine.
>
> the console backtrace showed something about the kld load of
> dependencies.
>
>
>
> --
> Larry Rosenman                     http://people.freebsd.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>
>

--0000000000008d1e7305ea047e73
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Do=C2=A0 you have a /boot tarball that can be loaded in a =
VM that recreates the problem (along with a clean hash)?

But before you try that, have you tried a completely clean rebuild of the =
kernel to preclude the possibility that something is somehow cross threaded=
?

Warner

On Sat, Oct 1, 2022 at 8:39 PM Larry=
 Rosenman <ler@freebsd.org> wr=
ote:


=E2=9D=AF more info.11

Dump header from device: /dev/mfid0p3

=C2=A0 =C2=A0Architecture: amd64

=C2=A0 =C2=A0Architecture Version: 2

=C2=A0 =C2=A0Dump Length: 126748815

=C2=A0 =C2=A0Blocksize: 512

=C2=A0 =C2=A0Compression: zstd

=C2=A0 =C2=A0Dumptime: 2022-10-01 21:26:40 -0500

=C2=A0 =C2=A0Hostname:

=C2=A0 =C2=A0Magic: FreeBSD Kernel Dump

=C2=A0 =C2=A0Version String: FreeBSD 14.0-CURRENT #168 

ler/freebsd-main-changes-n258354-6cdd871ebc4: Sat Oct=C2=A0 1 21:13:01 CDT =


2022

=C2=A0 =C2=A0 =C2=A0root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/L=
ER-MINIMAL

=C2=A0 =C2=A0Panic String: page fault

=C2=A0 =C2=A0Dump Parity: 501115454

=C2=A0 =C2=A0Bounds: 11

=C2=A0 =C2=A0Dump Status: good



I do have source and debug stuff, BUT kgdb croaks on me.



I *CAN* give access to the machine.



the console backtrace showed something about the kld load of 

dependencies.







-- 

Larry Rosenman=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0http://people.freebsd.org/~ler

Phone: +1 214-642-9640=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0E-Mail: ler@FreeBSD.org

US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106






--0000000000008d1e7305ea047e73--

From nobody Sun Oct  2 03:06:12 2022
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 4Mg84R4TkWz4djsv
	for ; Sun,  2 Oct 2022 03:06:15 +0000 (UTC)
	(envelope-from ler@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mg84R3yY7z3tql;
	Sun,  2 Oct 2022 03:06:15 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664679975;
	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=O84ctDNyXNQFHvXgcoYfk0cjEzf40avXre+IqSzkGKs=;
	b=hO+HuhDjZnfESI5XBqy59FWhxtQ9VmZWcwnBLditvHfDMeKflC1oHp5oiamnVOtjVgUcYW
	0szBFbni+ETj/VEyRLg9wp0228VpjdJKd1NNv0WeesolPjuhWwwgmoxGbZOB+ddI7wZZnn
	Cx+GaUJOkyi1gzQHhQle55nZuWOOEbSbIi2hg3llJK6Qzcln3lY9CTIcHWeIH7+EkoscEG
	IEGrV/gwRcKcOWDwaP1mYqGy54eAwKFdctN+NxM0emdxKQ7W7NHUgMnnY1S34ecC8jTexS
	hGc3Au4IQyQ2ruYQkMWJG7LEqHyQrcjYsY1qnUCnC0S8kYx+rtPO3+i+20beDw==
Received: from thebighonker.lerctr.org (unknown [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	(Authenticated sender: ler/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mg84R2s1pz196M;
	Sun,  2 Oct 2022 03:06:15 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=O84ctDNyXNQFHvXgcoYfk0cjEzf40avXre+IqSzkGKs=; b=P4fit7BYwV0ITOKRZFs7lLVCcT
	uBwAsFNt98kP2WDKhFT2/VN0GTxTCNz/lZ/xoZxsZAW3GupvMa6lMg8bBgIiW/LSfHMr75PKq7uDb
	R1PYLfOz59jQR6FifWIs2qax+zOZ96D1Bd1ZzZEevq90ow7lN/q1Qbhq1rORZnnaZeO5j3Jv8KYcr
	Fky5zuAoemibqEC0els8YVh/J8WylGeXd3d+bN9ThMUzjsmgVVP9sWWxyL4rK+LlWD0ii4iI7pj03
	rWFB3YkFHdd3V8wV59E1iblqjVau6m+cikQzILjZ4Gp1CjkPYY+hXFPZz7vwR949prGhTJW1ChbcQ
	xi2R6Qow==;
Authentication-Results: thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
Received-SPF: softfail (thebighonker.lerctr.org: transitioning domain of FreeBSD.org does not designate 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@FreeBSD.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:59599 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oepIz-0002Oq-44;
	Sat, 01 Oct 2022 22:06:13 -0500
Received: from 2600:1700:210:b18f:8cb4:f417:c3e6:a42
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sat, 01 Oct 2022 22:06:12 -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
Date: Sat, 01 Oct 2022 22:06:12 -0500
From: Larry Rosenman 
To: Warner Losh 
Cc: Freebsd current , Mark Johnston
 
Subject: Re: BOOT CRASH -- Current -CURRENT
In-Reply-To: 
References: <9de62c1d7c3eae83b97a1004780a8d0d@FreeBSD.org>
 
Message-ID: 
X-Sender: ler@FreeBSD.org
Content-Type: multipart/alternative;
 boundary="=_ad1b41f14a64dc531e1261c837b7d7a7"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664679975;
	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:dkim-signature;
	bh=O84ctDNyXNQFHvXgcoYfk0cjEzf40avXre+IqSzkGKs=;
	b=Toj2GFSFbYXBXOcXkTtvV2cACtxd+U7zALrYdYBc7z37bO4FfZfU6IRFU9bAEE+JGWFM1N
	yLUjok50Nn9aDCC2PSeMPwf+fwBwsjU9Xg8dZmu9wNLlec4zw6AkKYRlsU9itDzTk9Vhqm
	GuyD6j0/X6jjFlhp9aThVMKhpfTA/1JRlSX2NbEpw5uxJ5Qq1gWB60QVWp/KzUb32RiC5u
	Exho3moj386pyP66Fd0BiTjzLQpSkD1c2xJXppDBo76kOgIhyncT11V0kfpIgmtffQRKuw
	8qwKcOl/EchaK8KMhxWinu0cbYTEpXBTKDqaWC/p+cULGRlyebA0oFNTXaU3Kg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664679975; a=rsa-sha256; cv=none;
	b=mh8eafFb9UNmc10MV+ZsH6lS4RvuljkP8xe7W56yaWO+jDxgwTi7vcdyl/xQi/dcV768fw
	SFP4DMeX+C3m5LxsKrQlnvLsZDMiG5lZUtYJNKQqePw42WGBbouPSBkTpUEoCYz+Hal5tN
	uc7DZRDUTa03RWhr2ep6iQEsO6sfDSDfZpWUztbuiuEWbFOouXVUd/O/3uEvAabzvK/X8s
	ec7buEAgedcd971S96mC8wkHf39fWE6LcAqGVu7Ft+2jVwerHQAMUKU/zYESBF84uXf3t2
	fKAovH41dKl5pUwzoj9p9MBMLoi7oupP4L365btJch9Q67DqNZnKXTRxKJ1uFw==
ARC-Authentication-Results: i=1;
	thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
X-ThisMailContainsUnwantedMimeParts: N

--=_ad1b41f14a64dc531e1261c837b7d7a7
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed



On 10/01/2022 10:04 pm, Warner Losh wrote:

> Do  you have a /boot tarball that can be loaded in a VM that recreates 
> the problem (along with a clean hash)?
> 
> But before you try that, have you tried a completely clean rebuild of 
> the kernel to preclude the possibility that something is somehow cross 
> threaded?
> 
> Warner
> 
> On Sat, Oct 1, 2022 at 8:39 PM Larry Rosenman  wrote:
> 
>> ⯠more info.11
>> Dump header from device: /dev/mfid0p3
>> Architecture: amd64
>> Architecture Version: 2
>> Dump Length: 126748815
>> Blocksize: 512
>> Compression: zstd
>> Dumptime: 2022-10-01 21:26:40 -0500
>> Hostname:
>> Magic: FreeBSD Kernel Dump
>> Version String: FreeBSD 14.0-CURRENT #168
>> ler/freebsd-main-changes-n258354-6cdd871ebc4: Sat Oct  1 21:13:01 CDT
>> 2022
>> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
>> Panic String: page fault
>> Dump Parity: 501115454
>> Bounds: 11
>> Dump Status: good
>> 
>> I do have source and debug stuff, BUT kgdb croaks on me.
>> 
>> I *CAN* give access to the machine.
>> 
>> the console backtrace showed something about the kld load of
>> dependencies.
>> 
>> --
>> Larry Rosenman                     http://people.freebsd.org/~ler
>> Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
>> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

let me wipe /usr/obj, and rebuild everything (I *DO* use meta-mode).

-- 
Larry Rosenman                     http://people.freebsd.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_ad1b41f14a64dc531e1261c837b7d7a7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



On 10/01/2022 10:04 pm, Warner Losh wrote:






Do  you have a /boot tarball that can be loaded in a =
VM that recreates the problem (along with a clean hash)?

 


But before you try that, have you tried a completely clean rebuild of =
the kernel to preclude the possibility that something is somehow cross thre=
aded?


 


Warner








On Sat, Oct 1, 2022 at 8:39 PM Larr=
y Rosenman <ler@fr=
eebsd.org> wrote:



=E2=9D=AF more info.=
11
Dump header from device: /dev/mfid0p3
   Architectur=
e: amd64
   Architecture Version: 2
   Dump L=
ength: 126748815
   Blocksize: 512
   Compres=
sion: zstd
   Dumptime: 2022-10-01 21:26:40 -0500
 =
;  Hostname:
   Magic: FreeBSD Kernel Dump
  =
 Version String: FreeBSD 14.0-CURRENT #168 
ler/freebsd-main-chan=
ges-n258354-6cdd871ebc4: Sat Oct  1 21:13:01 CDT 
2022
 =
;    root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MI=
NIMAL
   Panic String: page fault
   Dump Par=
ity: 501115454
   Bounds: 11
   Dump Status: =
good

I do have source and debug stuff, BUT kgdb croaks on me.
I *CAN* give access to the machine.

the console backtra=
ce showed something about the kld load of 
dependencies.


-- 
Larry Rosenman            =
         http://people.freebsd.org/~=
ler
Phone: +1 214-642-9640           =
;      E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr,=
 Round Rock, TX 78665-2106









let me wipe /usr/obj, and rebuild everything (I *DO* use meta-mode).




=
-- 
Larry Rosenman        =
;             http://people.fre=
ebsd.org/~ler
Phone: +1 214-642-9640         &=
nbsp;       E-Mail: ler@F=
reeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106





--=_ad1b41f14a64dc531e1261c837b7d7a7--

From nobody Sun Oct  2 03:08:32 2022
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 4Mg87K1jqkz4dk2w
	for ; Sun,  2 Oct 2022 03:08:45 +0000 (UTC)
	(envelope-from wlosh@bsdimp.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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mg87J2hmzz3vtC
	for ; Sun,  2 Oct 2022 03:08:44 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ed1-x533.google.com with SMTP id x59so529046ede.7
        for ; Sat, 01 Oct 2022 20:08:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date;
        bh=1TQu1HnUpLtgupT1pxIG1DmogEMWVkfIWK6clZKuUmc=;
        b=kKl7VOy7j5uHNTc6rqDow0iBCJ/rbLiWTgfpf6YE3oFdOJMKSv9jsKSoK0aFAFe+cD
         nBrUTt0WmNwHA7ZosFTT2PdJKPav+ohQubrhQX8M0xXYe+ujRi3T0l0K+xshZfqAwnto
         n0FO0GWy4G35/jSeDpSo5JdM9SHHe0occKm0K8imu4dr/g9ge3znCGRcuuQMnCe9slEZ
         FU1Ti89aYwOvcArTMHW/f0GrqaNkG8lf13kIyMFRliPBpofpeosQq0nqfEYByj8zCM5o
         gFNuWSKKwlWlrvqHZTdlQB6Tx+nRdYPhcD+6IbRDHtigtGQHmJs6WquQGN8dOPYLCvW1
         NDPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date;
        bh=1TQu1HnUpLtgupT1pxIG1DmogEMWVkfIWK6clZKuUmc=;
        b=2ANFcAZHGi+J4zGaU6whzxkDxT3thbXEp+PXFGVCvYhp1KLGJ5YcedUyiJLIxQspSC
         R7hghqCZV4f4r3b9H76xQcrXfw6jjX468J8RgbWQyzl1f19khJjkpf4dv1t+EdZ63wqB
         DV+btrWn5pnZMyQJPBqq+bxdjavBotuNC9QbIutmUpjsODhpr/0YAAUYQedTYBZLNkye
         pMIISJBYNBQkULHJKx90Q/xPq2di0b6W58EqI8WV77wq0B6O21UkWTjYemCuFEJmo8Sj
         dSNy0bzUKbYY2S1O8/xcykWSyPfzyoeOVwUvu4GYHxBWMt6uNH3XekTpfbSp+Udgs/Sy
         3AuA==
X-Gm-Message-State: ACrzQf1+0WAwIPTCBY+rDh0eyjXyBjHjHX4Rf9CSc8/DvsW0+eRipY+Q
	pqKPDFZ6LBb7TDlSQbK5wo3GJxpE9MfqMFByTu7SwA==
X-Google-Smtp-Source: AMsMyM6wP/NFcbCj9c5XXwgZ9wsWIS/WvyjeJYvzwgp4m1dKc1Dl92yFMUq+m6YFewGZsjfYBHpDqzOHjULvVKzk91c=
X-Received: by 2002:a05:6402:84c:b0:451:a99b:f74a with SMTP id
 b12-20020a056402084c00b00451a99bf74amr13798311edz.100.1664680123013; Sat, 01
 Oct 2022 20:08:43 -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: <9de62c1d7c3eae83b97a1004780a8d0d@FreeBSD.org> 
 
In-Reply-To: 
From: Warner Losh 
Date: Sat, 1 Oct 2022 21:08:32 -0600
Message-ID: 
Subject: Re: BOOT CRASH -- Current -CURRENT
To: Larry Rosenman 
Cc: Freebsd current , Mark Johnston 
Content-Type: multipart/alternative; boundary="00000000000065ac9c05ea048b2a"
X-Rspamd-Queue-Id: 4Mg87J2hmzz3vtC
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=kKl7VOy7;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::533) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000065ac9c05ea048b2a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 1, 2022 at 9:06 PM Larry Rosenman  wrote:

> On 10/01/2022 10:04 pm, Warner Losh wrote:
>
> Do  you have a /boot tarball that can be loaded in a VM that recreates th=
e
> problem (along with a clean hash)?
>
> But before you try that, have you tried a completely clean rebuild of the
> kernel to preclude the possibility that something is somehow cross thread=
ed?
>
> Warner
>
> On Sat, Oct 1, 2022 at 8:39 PM Larry Rosenman  wrote:
>
>
> =E2=9D=AF more info.11
> Dump header from device: /dev/mfid0p3
>    Architecture: amd64
>    Architecture Version: 2
>    Dump Length: 126748815
>    Blocksize: 512
>    Compression: zstd
>    Dumptime: 2022-10-01 21:26:40 -0500
>    Hostname:
>    Magic: FreeBSD Kernel Dump
>    Version String: FreeBSD 14.0-CURRENT #168
> ler/freebsd-main-changes-n258354-6cdd871ebc4: Sat Oct  1 21:13:01 CDT
> 2022
>      root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
>    Panic String: page fault
>    Dump Parity: 501115454
>    Bounds: 11
>    Dump Status: good
>
> I do have source and debug stuff, BUT kgdb croaks on me.
>
> I *CAN* give access to the machine.
>
> the console backtrace showed something about the kld load of
> dependencies.
>
>
>
> --
> Larry Rosenman                     http://people.freebsd.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>
> let me wipe /usr/obj, and rebuild everything (I *DO* use meta-mode).
>

I've had fewer problems with it than non-meta mode, but this looks like a
'corruption' or 'cross threaded' crash I've chased in the past that went
away with a rebuild. So it's better to be sure...

Warner

--00000000000065ac9c05ea048b2a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Oct 1, 2022 at 9:06 PM Larry =
Rosenman <ler@freebsd.org> wro=
te:


On 10/01/2022 10:04 pm, Warner L=
osh wrote:






Do=C2=A0 you have a /boot tarball that can be loaded in a =
VM that recreates the problem (along with a clean hash)?

=C2=A0


But before you try that, have you tried a completely clean rebuild of =
the kernel to preclude the possibility that something is somehow cross thre=
aded?


=C2=A0


Warner








On Sat, Oct 1, 2022 at 8:39 PM Larry Rosenman <ler@freebs=
d.org> wrote:



=E2=9D=AF more info.11
Dump header from =
device: /dev/mfid0p3
=C2=A0 =C2=A0Architecture: amd64
=C2=A0 =C2=A0Ar=
chitecture Version: 2
=C2=A0 =C2=A0Dump Length: 126748815
=C2=A0 =C2=
=A0Blocksize: 512
=C2=A0 =C2=A0Compression: zstd
=C2=A0 =C2=A0Dumptim=
e: 2022-10-01 21:26:40 -0500
=C2=A0 =C2=A0Hostname:
=C2=A0 =C2=A0Magi=
c: FreeBSD Kernel Dump
=C2=A0 =C2=A0Version String: FreeBSD 14.0-CURRENT=
 #168 
ler/freebsd-main-changes-n258354-6cdd871ebc4: Sat Oct=C2=A0 1 21:=
13:01 CDT 
2022
=C2=A0 =C2=A0 =C2=A0root@borg.lerctr.org:/usr/obj/usr=
/src/amd64.amd64/sys/LER-MINIMAL
=C2=A0 =C2=A0Panic String: page fault=C2=A0 =C2=A0Dump Parity: 501115454
=C2=A0 =C2=A0Bounds: 11
=C2=A0 =
=C2=A0Dump Status: good

I do have source and debug stuff, BUT kgdb c=
roaks on me.

I *CAN* give access to the machine.

the console =
backtrace showed something about the kld load of 
dependencies.

<=
br>
-- 
Larry Rosenman=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://people.freebsd.org/~ler=

Phone: +1 214-642-9640=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr, Round =
Rock, TX 78665-2106









let me wipe /usr/obj, and rebuild everything (I *DO* use meta-mode).
=


I've had fewer problems with it =
than non-meta mode, but this looks like a 'corruption' or 'cros=
s threaded' crash I've chased in the past that went away with a reb=
uild. So it's better to be sure...

Warner=C2=
=A0


--00000000000065ac9c05ea048b2a--

From nobody Sun Oct  2 03:43:33 2022
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 4Mg8vY0yLVz4dnSH
	for ; Sun,  2 Oct 2022 03:43:37 +0000 (UTC)
	(envelope-from ler@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mg8vY0Lj0z3yk6;
	Sun,  2 Oct 2022 03:43:37 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664682217;
	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=JaJ3TSL8NRwTGJhfM2IxtvKkuuQm8KifUpMwtYsiPSM=;
	b=GlYHEjl6dCggQHoOC5fzMBg/uW/FVKjCPddPZO15zVECTugur4H5XLO+glsWriyCIY9/c3
	PmSZdJ4BmVGE61xr+ZIjXVDeWuWgQHh6miZauFCxI/dp2+glKJ480f81ngdgxJYChK6oQ5
	qAMoJY+0rbz+joicAWJDyUSpEfW5GYCmN/kqxJoOqmmno2MOJS/90kW1kCCyps+lNPAeKN
	0ANOv1NyZVZDM4ajAw3DrfEABiVR9TOIbV0H6pT10DSju2VUjtgwzYe5jDMGJbA9bWQwZf
	z3sMeknls3JwJ/07bbs22mLuY+hpujOmCEixzoGUigRyO5bqfWEzFtcFS5PzSg==
Received: from thebighonker.lerctr.org (unknown [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	(Authenticated sender: ler/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mg8vX686kz19Wp;
	Sun,  2 Oct 2022 03:43:36 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=JaJ3TSL8NRwTGJhfM2IxtvKkuuQm8KifUpMwtYsiPSM=; b=febdX2yFf1piKr8DMvmyLDj8Ed
	WTLKXjr6ihQMspHj/cqMgp3ZrGMrR4gNy8vEXPMnq3Hg8nWe2HJ2qoivTWqBEpY4waIvl7K8zKXEG
	xvIii3A+Yw/mM6Fy9PHmMaAUWL0cKp7vr6KlAh7F6d6i78TB2Y6AecEVXyLPMr0f5uX0qK72HethS
	l37vv39BliHNKrXjgTSSqQpc2LJ6AVQUOnovsma8lsghscXDo57tvzHELhmDovfhtmjTaOPPXIKPD
	+dJNwQBi1gR5fdCpY7UY82bmoz65x3h8jX6pPH/eHnz974y93710NHuOXPKWpSF5brrjtHZFern+N
	bNXXR8xw==;
Authentication-Results: thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
Received-SPF: softfail (thebighonker.lerctr.org: transitioning domain of FreeBSD.org does not designate 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@FreeBSD.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:56776 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oept7-0002sM-VJ;
	Sat, 01 Oct 2022 22:43:34 -0500
Received: from 2600:1700:210:b18f:8cb4:f417:c3e6:a42
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sat, 01 Oct 2022 22:43:33 -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
Date: Sat, 01 Oct 2022 22:43:33 -0500
From: Larry Rosenman 
To: Warner Losh 
Cc: Freebsd current , Mark Johnston
 
Subject: Re: BOOT CRASH -- Current -CURRENT
In-Reply-To: 
References: <9de62c1d7c3eae83b97a1004780a8d0d@FreeBSD.org>
 
 
 
Message-ID: <6d03cfe3d1c0244ffb9703b05af3bcb5@FreeBSD.org>
X-Sender: ler@FreeBSD.org
Content-Type: multipart/alternative;
 boundary="=_9d12cb3723ce7e191af500a92e340bbd"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664682217;
	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:dkim-signature;
	bh=JaJ3TSL8NRwTGJhfM2IxtvKkuuQm8KifUpMwtYsiPSM=;
	b=cXGmAnhbGced0bfsPH6IrPXew0/kHtaD4bfCtKx/diR2CZ+qRr8Al9lJeG5zGtTjP/5K+h
	9Y2lGvSkH9SvRtJAhaqDx142iND1bhIgtdvvwIwqg+5T3esdCdgu0+yAe9b9/ev2wD65Ft
	xIJWbeD5Zqflxo3vnB0z2HiUL3VrwuD5x7TV2iL5a8xhEqrwEbYZZKxu0DtriX8U9yPrKL
	M29cwm1EmG03j6hJLSd4oj8SAgR3YNCeZZcbJEyD0tJ6JkyIlsTYvM2uSKCiShgzVUIZ2x
	cp2VWH3CzFEJfFXgaKkqzy/evTJEZE/sgUGC4rZ0OsDxAcXAdi2KjehldcLhoQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664682217; a=rsa-sha256; cv=none;
	b=Q1k/AtmXVnR2AN90R/BDnWPf3M/gs0i7dVXXFDkJsHDRvlzbCehekGcZxgXjmmQWs2KQF1
	st1MtB/almiUi62CYmXf0jbqlE2YIQcOxjg1MAiPBemA4JTZ16GSot8u7v68jjeJkeYfnK
	8GBMn5sVjK5v3mfbNakmyoSZKhv0Fnw4zJcPg0e3Ftpj13/v51B1W0WtMmx5dRCaO4Su1u
	YAOSnt5IavI8usU3Nt8pvVD6+zRkj4oaUQoawNxfoz1lpo9rqCxCP2hYonPkWXMmUrzZuc
	DRfyfWQt3Xf0q1BzL3zjspuTBNNkxmPB0R1kyc2DjVnNXLz4cYkwF2sF0Oo9Ww==
ARC-Authentication-Results: i=1;
	thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
X-ThisMailContainsUnwantedMimeParts: N

--=_9d12cb3723ce7e191af500a92e340bbd
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed



On 10/01/2022 10:08 pm, Warner Losh wrote:

> On Sat, Oct 1, 2022 at 9:06 PM Larry Rosenman  wrote:
> 
> On 10/01/2022 10:04 pm, Warner Losh wrote:
> 
> Do  you have a /boot tarball that can be loaded in a VM that recreates 
> the problem (along with a clean hash)?
> 
> But before you try that, have you tried a completely clean rebuild of 
> the kernel to preclude the possibility that something is somehow cross 
> threaded?
> 
> Warner
> 
> On Sat, Oct 1, 2022 at 8:39 PM Larry Rosenman  wrote:
> ⯠more info.11
> Dump header from device: /dev/mfid0p3
> Architecture: amd64
> Architecture Version: 2
> Dump Length: 126748815
> Blocksize: 512
> Compression: zstd
> Dumptime: 2022-10-01 21:26:40 -0500
> Hostname:
> Magic: FreeBSD Kernel Dump
> Version String: FreeBSD 14.0-CURRENT #168
> ler/freebsd-main-changes-n258354-6cdd871ebc4: Sat Oct  1 21:13:01 CDT
> 2022
> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
> Panic String: page fault
> Dump Parity: 501115454
> Bounds: 11
> Dump Status: good
> 
> I do have source and debug stuff, BUT kgdb croaks on me.
> 
> I *CAN* give access to the machine.
> 
> the console backtrace showed something about the kld load of
> dependencies.
> 
> --
> Larry Rosenman                     http://people.freebsd.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

let me wipe /usr/obj, and rebuild everything (I *DO* use meta-mode).

I've had fewer problems with it than non-meta mode, but this looks like 
a 'corruption' or 'cross threaded' crash I've chased in the past that 
went away with a rebuild. So it's better to be sure...

Warner

Still breaks -- did someone(tm) forget to make netlink a module?

-- 
Larry Rosenman                     http://people.freebsd.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_9d12cb3723ce7e191af500a92e340bbd
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



On 10/01/2022 10:08 pm, Warner Losh wrote:








 






On Sat, Oct 1, 2022 at 9:06 PM Larr=
y Rosenman <ler@fr=
eebsd.org> wrote:






On 10/01/2022 10:04 pm, Warner=
 Losh wrote:






Do  you have a /boot tarball that can be loaded in a =
VM that recreates the problem (along with a clean hash)?

 


But before you try that, have you tried a completely clean rebuild of =
the kernel to preclude the possibility that something is somehow cross thre=
aded?


 


Warner








On Sat, Oct 1, 2022 at 8:39 PM Larry Rosenman <ler@freebsd.org> wrot=
e:



=E2=9D=AF more info.11
Dump header from=
 device: /dev/mfid0p3
   Architecture: amd64
  &nb=
sp;Architecture Version: 2
   Dump Length: 126748815
&n=
bsp;  Blocksize: 512
   Compression: zstd
  &=
nbsp;Dumptime: 2022-10-01 21:26:40 -0500
   Hostname:
&=
nbsp;  Magic: FreeBSD Kernel Dump
   Version String: Fr=
eeBSD 14.0-CURRENT #168 
ler/freebsd-main-changes-n258354-6cdd871ebc4:=
 Sat Oct  1 21:13:01 CDT 
2022
     root@borg=
=2Elerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
  &nbs=
p;Panic String: page fault
   Dump Parity: 501115454
&n=
bsp;  Bounds: 11
   Dump Status: good

I do h=
ave source and debug stuff, BUT kgdb croaks on me.

I *CAN* give =
access to the machine.

the console backtrace showed something ab=
out the kld load of 
dependencies.



-- 
Lar=
ry Rosenman                  &=
nbsp;  http://people.freebsd.org/~ler
Phone: +1=
 214-642-9640                 =
E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-=
2106









let me wipe /usr/obj, and rebuild everything (I *DO* use meta-mode).






 


I've had fewer problems with it than non-meta mode, but this looks lik=
e a 'corruption' or 'cross threaded' crash I've chased in the past that wen=
t away with a rebuild. So it's better to be sure...


 


Warner 










Still breaks -- did someone(tm) forget to make netlink a module?







=
-- 
Larry Rosenman        =
;             http://people.fre=
ebsd.org/~ler
Phone: +1 214-642-9640         &=
nbsp;       E-Mail: ler@F=
reeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106





--=_9d12cb3723ce7e191af500a92e340bbd--

From nobody Sun Oct  2 04:12:23 2022
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 4Mg9Xn4yqhz4drJb
	for ; Sun,  2 Oct 2022 04:12:25 +0000 (UTC)
	(envelope-from ler@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mg9Xn4hYQz41kr;
	Sun,  2 Oct 2022 04:12:25 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664683945;
	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=q5I9s8//+6d91H4tR7S1jJoHG2Kma9LlOd1yOFaD0wU=;
	b=w2ivBOH/Hzz1zq9Zp9pDrAMle7a1+DPzH83ihtVzhZ/lwdkIKHftBGDSGjryByLAw5LNFf
	2fJKlcwPna1Fys12wkrXMVTKg44igOex7AaHJJHBjqdG+QauV34idI13i7fZZ2jjTka+vZ
	GpQaNuTTVyY7Zw/qJyEGAjr+hsNxgSCCr26xld+7oizatPHIeOxN7cKxIu8XQwUSYcjqay
	md8gfgFsDdkHt2C3udklpQIiKcSQPBgcczCzuQz/lhU6D4k8o7nfnJgO1zN4yP8sBTmlbs
	A3/32lwNLLXWJbTMi/VCaad71rT5BmdBRiIAzZmN/RGlZ4RsZHYVz4b/OWvYzw==
Received: from thebighonker.lerctr.org (unknown [IPv6:2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	(Authenticated sender: ler/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mg9Xn2T3Mz19ls;
	Sun,  2 Oct 2022 04:12:25 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:To:From:
	Date:MIME-Version:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=q5I9s8//+6d91H4tR7S1jJoHG2Kma9LlOd1yOFaD0wU=; b=QNLaji5aBTCupN9YKjXeKRci+/
	5fHYu6OexUofJPU3JfWhTjc3wsYbHIcqCwFliMVGlKSIRJ6EqrCmWfU/EmDKBn6WReuz2NvplrAQK
	uXLUx3oZTiJ6gU6Up6ByBlL2FXSYihiD8ACryf6gq2wcDrQRIVzgQkGuM+cPDsPeNV9/PPFdNHiKI
	IBdTfmrWv0zFfJuZhb2N8pHkkBolJsNXSl4UeVnzAeHVVCk2742+qPBxAVHFzOMCPKzCPvoOaQPRf
	8ToMJWKn3Y3aCgILiahVr72fxm5mvsUGqV6qYbLZG5djUcjrbUfUC0vWeFMdzONk8sOTWYfYzvG3V
	cbP5eGZw==;
Authentication-Results: thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
Received-SPF: softfail (thebighonker.lerctr.org: transitioning domain of FreeBSD.org does not designate 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@FreeBSD.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:18050 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1oeqL2-0003OH-3E;
	Sat, 01 Oct 2022 23:12:24 -0500
Received: from 2600:1700:210:b18f:8cb4:f417:c3e6:a42
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sat, 01 Oct 2022 23:12:23 -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
Date: Sat, 01 Oct 2022 23:12:23 -0500
From: Larry Rosenman 
To: Warner Losh , Freebsd current
 , Mark Johnston 
Subject: Re: BOOT CRASH -- Current -CURRENT
In-Reply-To: <6d03cfe3d1c0244ffb9703b05af3bcb5@FreeBSD.org>
References: <9de62c1d7c3eae83b97a1004780a8d0d@FreeBSD.org>
 
 
 
 <6d03cfe3d1c0244ffb9703b05af3bcb5@FreeBSD.org>
Message-ID: <555871472eda375673b6b7d8eabc6264@FreeBSD.org>
X-Sender: ler@FreeBSD.org
Content-Type: multipart/alternative;
 boundary="=_c6fac64eb3c0d4c1aa3bdb883c568a3b"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664683945;
	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:dkim-signature;
	bh=q5I9s8//+6d91H4tR7S1jJoHG2Kma9LlOd1yOFaD0wU=;
	b=ZWO35zQjO+PJuqnciC8k/Ps9Xc7Pev1gm2SrFreNJ4PF7pz7W7PcM8SoIn75VLRZK5GE1e
	dUji9VBRpul06JKc+MNPts/FvChJsiGZsAugBS4jf9sG3+CY288Ey+1aqtirSjrlV3kCVk
	SL8Zv/q+uySndxdhzLV2JeqjnlHbqdHmJKzV+spkQ+79mlaKMx+RGHrswOndDgS7BM7IVM
	Y+TGTW78/mj1vDA1roygUEeBkiCpKbxWWyv/+buu8vxfF6IJwbjvypUK6KduG5vyiwheMU
	ui0DXBTM3GSiQ2XhneqivPxZ5xBLOEXlu7uniYutro3zYX52gHjgeudK7WpEJA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664683945; a=rsa-sha256; cv=none;
	b=OyksYIzM7vbiLQyEZlW5cqrna0DqUPBLhCjGSav+0uX1QfzjPrtK/imBaVg+hs+kZRUpGR
	YgZKeo0LiaacAQC1DwWAbwazNzO1G8YO+ecekpUspshfitiS66RPoMR0Uao4IYbIDXjvFx
	PVkkwQlNdOfAsEGQkTbF8htS2wv1s19F7cEEHzV1sYsHQsYd/WvUyl+oPzjqp4Jdyh6bIj
	5CpLGx4c8HQ7Ai3SCdFutQxdko6OeRMwb0w7A8Vzi+m8DAFTYTvnH6WvEJR/OO6GT9B+5S
	RjM1BPBQBJWOAUg/vPwn5wLnrc9BD599yPEHM1Top2xhpU744GyEp5mcWZDoUQ==
ARC-Authentication-Results: i=1;
	thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
X-ThisMailContainsUnwantedMimeParts: N

--=_c6fac64eb3c0d4c1aa3bdb883c568a3b
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed



On 10/01/2022 10:43 pm, Larry Rosenman wrote:

> On 10/01/2022 10:08 pm, Warner Losh wrote:
> 
> On Sat, Oct 1, 2022 at 9:06 PM Larry Rosenman  wrote:
> 
> On 10/01/2022 10:04 pm, Warner Losh wrote:
> 
> Do  you have a /boot tarball that can be loaded in a VM that recreates 
> the problem (along with a clean hash)?
> 
> But before you try that, have you tried a completely clean rebuild of 
> the kernel to preclude the possibility that something is somehow cross 
> threaded?
> 
> Warner
> 
> On Sat, Oct 1, 2022 at 8:39 PM Larry Rosenman  wrote:
> ⯠more info.11
> Dump header from device: /dev/mfid0p3
> Architecture: amd64
> Architecture Version: 2
> Dump Length: 126748815
> Blocksize: 512
> Compression: zstd
> Dumptime: 2022-10-01 21:26:40 -0500
> Hostname:
> Magic: FreeBSD Kernel Dump
> Version String: FreeBSD 14.0-CURRENT #168
> ler/freebsd-main-changes-n258354-6cdd871ebc4: Sat Oct  1 21:13:01 CDT
> 2022
> root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
> Panic String: page fault
> Dump Parity: 501115454
> Bounds: 11
> Dump Status: good
> 
> I do have source and debug stuff, BUT kgdb croaks on me.
> 
> I *CAN* give access to the machine.
> 
> the console backtrace showed something about the kld load of
> dependencies.
> 
> --
> Larry Rosenman                     http://people.freebsd.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

let me wipe /usr/obj, and rebuild everything (I *DO* use meta-mode).

I've had fewer problems with it than non-meta mode, but this looks like 
a 'corruption' or 'cross threaded' crash I've chased in the past that 
went away with a rebuild. So it's better to be sure...

Warner

Still breaks -- did someone(tm) forget to make netlink a module?

-- 
Larry Rosenman                     http://people.freebsd.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

⯠sudo kgdb -c vmcore.12 /mnt/usr/lib/debug/boot/kernel/kernel.debug
GNU gdb (GDB) 12.1 [GDB v12.1 for FreeBSD]
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
     .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/usr/lib/debug/boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:
---<>---
Copyright (c) 1992-2022 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
  The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 14.0-CURRENT #0 ler/freebsd-main-changes-n258354-6cdd871ebc4: 
Sat Oct  1 22:30:48 CDT 2022
     root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL 
amd64
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git 
llvmorg-14.0.5-0-gc12386ae247c)
VT(efifb): resolution 640x480
CPU: Intel(R) Xeon(R) CPU           X5660  @ 2.80GHz (2793.16-MHz 
K8-class CPU)
   Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c  Stepping=2
   
Features=0xbfebfbff
   
Features2=0x29ee3ff
   AMD Features=0x2c100800
   AMD Features2=0x1
   Structured Extended Features3=0x9c000000
   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
   TSC: P-state invariant, performance statistics
real memory  = 137438953472 (131072 MB)
avail memory = 133789515776 (127591 MB)
CPU microcode: no matching update found
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs
FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 hardware threads
random: unblocking device.
ioapic1: MADT APIC ID 1 != hw id 0
ioapic0  irqs 0-23
ioapic1  irqs 32-55
Launching APs: 1 14 12 21 2 6 17 10 18 15 4 19 7 3 8 20 13 5 23 11 9 16 
22
TCP_ratelimit: Is now initialized
TCP Hpts created 24 swi interrupt threads and bound 24 to NUMA domains
random: entropy device external interface
kbd1 at kbdmux0
acpi0: 
acpi0: Power Button (fixed)
apei0:  on acpi0
cpu0:  on acpi0
atrtc0:  port 0x70-0x7f irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x5f irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0:  iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 350
Event timer "HPET1" frequency 14318180 Hz quality 340
Event timer "HPET2" frequency 14318180 Hz quality 340
Event timer "HPET3" frequency 14318180 Hz quality 340
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
pci1:  at device 0.1 (no driver attached)
pcib2:  at device 3.0 on pci0
pci2:  on pcib2
pci2:  at device 0.0 (no driver attached)
pci2:  at device 0.1 (no driver attached)
pcib3:  at device 4.0 on pci0
pci3:  on pcib3
mfi0:  port 0xfc00-0xfcff mem 
0xdf1bc000-0xdf1bffff,0xdf1c0000-0xdf1fffff irq 33 at device 0.0 on pci3
mfi0: Using MSI
mfi0: Megaraid SAS driver Ver 4.23
mfi0: FW MaxCmds = 1008, limiting to 128
mfi0: 55346 (717997792s/0x0020/info) - Shutdown command received from 
host
pcib4: mfi0: 55347 (boot + 33s/0x0020/info) - 
Firmware initialization started (PCI ID 0079/1000/1f17/1028)
mfi0: 55348 (boot + 33s/0x0020/info) - Firmware version 2.100.03-4651
  at device 5.0 on pci0
pci4: mfi0: 55349 (boot + 35s/0x0008/info) - Battery 
Present
mfi0: 55350 (boot + 35s/0x0020/info) - Package version 12.10.7-0001
mfi0: 55351 (boot + 35s/0x0020/info) - Board Revision A00
  on pcib4
pcib5: mfi0: 55352 (boot + 63s/0x0004/info) - 
Enclosure PD 20(c None/p0) communication restored
  at device 6.0 on pci0
pci5: mfi0: 55353 (boot + 63s/0x0002/info) - Inserted: 
Encl PD 20
mfi0: 55354 (boot + 63s/0x0002/info) - Inserted: PD 20(c None/p0) Info: 
enclPd=20, scsiType=d, portMap=00, sasAddr=5b4ba0b019ef on pcib5
pcib6: e700,0000000000000000
mfi0: 55355 (boot + 63s/0x0002/info) - Inserted: PD 00(e0x20/s0)
mfi0: 55356 (boot + 63s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: 
enclPd=20, scsiType=0, portMap=04, sasAddr=4433221107000 at device 7.0 
on pci0
pci6: 000,0000000000000000
mfi0: 55357 (boot + 63s/0x0002/WARN) - PD 00(e0x20/s0) is not a 
certified drive
mfi0: 55358 (boot + 63s/0x0002/info) - Inserted: PD 01(e0x20/s1)
  on pcib6
pcib7: mfi0: 55359 (boot + 63s/0x0002/info) - 
Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=05, 
sasAddr=4433221106000 at device 9.0 on pci0
pci7: 000,0000000000000000
mfi0: 55360 (boot + 63s/0x0002/WARN) - PD 01(e0x20/s1) is not a 
certified drive
mfi0: 55361 (boot + 63s/0x0002/info) - Inserted: PD 02(e0x20/s2)
  on pcib7
pci0: mfi0: 55362 (boot + 
63s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: enclPd=20, 
scsiType=0, portMap=01, sasAddr=4433221105000 at device 20.0 (no driver 
attached)
pci0: 000,0000000000000000
mfi0: 55363 (boot + 63s/0x0002/WARN) - PD 02(e0x20/s2) is not a 
certified drive
mfi0: 55364 (boot + 63s/0x0002/info) - Inserted: PD 03(e0x20/s3)
  at device 20.1 (no driver attached)
pci0: mfi0: 55365 (boot + 
63s/0x0002/info) - Inserted: PD 03(e0x20/s3) Info: enclPd=20, 
scsiType=0, portMap=02, sasAddr=4433221104000 at device 20.2 (no driver 
attached)
uhci0: 000,0000000000000000
  port 0xec40-0xec5f irq 17 at device 26.0 on pci0
mfi0: 55366 (boot + 63s/0x0002/WARN) - PD 03(e0x20/s3) is not a 
certified drive
mfi0: 55367 (boot + 63s/0x0002/info) - Inserted: PD 04(e0x20/s4)
mfi0: 55368 (boot + 63s/0x0002/info) - Inserted: PD 04(e0x20/s4) Info: 
enclPd=20, scsiType=0, portMap=03, 
sasAddr=4433221103000000,0000000000000000
mfi0: 55369 (boot + 63s/0x0002/WARN) - PD 04(e0x20/s4) is not a 
certified drive
mfi0: 55370 (boot + 63s/0x0002/info) - Inserted: PD 05(e0x20/s5)
mfi0: 55371 (boot + 63s/0x0002/info) - Inserted: PD 05(e0x20/s5) Info: 
enclPd=20, scsiType=0, portMap=00, 
sasAddr=4433221102000usbus0000,0000000000000000
mfi0: 55372 (boot + 63s/0x0002/WARN) - PD 05(e0x20/s5) is not a 
certified drive
mfi0: 55373 (boot + 100s/0x0008/info) - Battery temperature is normal
  on uhci0
mfi0: 55374 (boot + 100s/0x0008/info) - Current capacity of the battery 
is above threshold
mfi0: 55375 (boot + 100s/0x0008/info) - Battery charge complete
mfi0: 55376 (717997971s/0x0020/info) - Time established as 10/02/22  
3:52:51; (148 seconds since power on)
usbus0: 12Mbps Full Speed USB v1.0
uhci1:  port 0xec60-0xec7f irq 18 at 
device 26.1 on pci0
usbus1 on uhci1
usbus1: 12Mbps Full Speed USB v1.0
ehci0:  mem 
0xdf0de000-0xdf0de3ff irq 19 at device 26.7 on pci0
usbus2: EHCI version 1.0
usbus2 on ehci0
usbus2: 480Mbps High Speed USB v2.0
uhci2:  port 0xec80-0xec9f irq 21 at 
device 29.0 on pci0
usbus3 on uhci2
usbus3: 12Mbps Full Speed USB v1.0
uhci3:  port 0xeca0-0xecbf irq 20 at 
device 29.1 on pci0
usbus4 on uhci3
usbus4: 12Mbps Full Speed USB v1.0
ehci1:  mem 
0xdf0df000-0xdf0df3ff irq 21 at device 29.7 on pci0
usbus5: EHCI version 1.0
usbus5 on ehci1
usbus5: 480Mbps High Speed USB v2.0
pcib8:  at device 30.0 on pci0
pci8:  on pcib8
vgapci0:  mem 
0xd5800000-0xd5ffffff,0xde7fc000-0xde7fffff,0xde800000-0xdeffffff irq 19 
at device 3.0 on pci8
vgapci0: Boot video device
isab0:  at device 31.0 on pci0
isa0:  on isab0
pci0:  at device 31.2 (no driver attached)
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (115200,n,8,1)
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
orm0:  at iomem 
0xc0000-0xc7fff,0xc8000-0xcdfff,0xec000-0xeffff pnpid ORM0000 on isa0
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
est0:  on cpu0
Timecounter "TSC-low" frequency 1396499773 Hz quality 1000
Timecounters tick every 1.000 msec
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
ugen0.1:  at usbus0
ugen2.1:  at usbus2
mfid0 on mfi0
mfid0: 1907200MB (3905945600 sectors) RAID volume 'Disk2' is optimal
ugen1.1:  at usbus1
uhub0 on usbus0
uhub0:  on usbus0
ugen4.1:  at usbus4
uhub1 on usbus1
uhub1:  on usbus1
mfid1 on mfi0
mfid1: 1907200MB (3905945600 sectors) RAID volume 'Disk1' is optimal
uhub2 on usbus4
uhub2:  on usbus4
uhub3 on usbus2
uhub3:  on usbus2
ugen5.1:  at usbus5
ugen3.1:  at usbus3
mfid2 on mfi0
mfid2: 2861056MB (5859442688 sectors) RAID volume 'Disk0' is optimal
uhub4 on usbus5
uhub4:  on usbus5
mfid3 on mfi0
mfid3: 2861056MB (5859442688 sectors) RAID volume 'Disk4' is optimal
uhub5 on usbus3
uhub5:  on usbus3
mfid4 on mfi0
mfid4: 1907200MB (3905945600 sectors) RAID volume 'Disk3' is optimal
mfid5 on mfi0
mfid5: 1907200MB (3905945600 sectors) RAID volume 'DIsk5' is optimal
Trying to mount root from zfs:zroot/ROOT/14-2022_10_01-2233 []...
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub5: 2 ports with 2 removable, self powered
Root mount waiting for: usbus2 usbus5
uhub3: 4 ports with 4 removable, self powered
uhub4: 4 ports with 4 removable, self powered
Root mount waiting for: usbus2 usbus5
ugen2.2:  at usbus2
uhub6 on uhub3
uhub6:  
on usbus2
uhub6: MTT enabled
ugen0.2:  at usbus0
ukbd0 on uhub0
ukbd0:  on usbus0
kbd2 at ukbd0
uhub6: 3 ports with 3 removable, self powered
ugen3.2:  at usbus3
ugen3.3:  at usbus3
ukbd1 on uhub5
ukbd1:  on usbus3
kbd3 at ukbd1
Dual Console: Video Primary, Serial Secondary
<118>sysctl: net.inet.tcp.functions_default=rack at line 55: No such 
file or directory
<118>Setting hostuuid: 4c4c4544-0035-4310-8048-c7c04f524c31.
<118>Setting hostid: 0xd7b851f2.
<118>no pools available to import
<118>Starting file system checks:
<118>Mounting local filesystems:.
<118>Loading kernel modules:
aesni0: 
coretemp0:  on cpu0
link_elf_obj: symbol nhgrp_get_group undefined
linker_load_file: /boot/kernel/netlink.ko - unsupported file type
KLD linux_common.ko: depends on netlink - not available or version 
mismatch
linker_load_file: /boot/kernel/linux_common.ko - unsupported file type
KLD linux.ko: depends on linux_common - not available or version 
mismatch
linker_load_file: /boot/kernel/linux.ko - unsupported file type
<118>kldload: an error occurred while loading module linux. Please check 
dmesg(8) for more details.
<118>/etc/rc: WARNING: Unable to load kernel module linux
ichwd0:  on isa0
efirtc0: 
efirtc0: registered as a time-of-day clock, resolution 1.000000s
ipmi0:  on isa0
ipmi0: KCS mode found at io 0xca8 alignment 0x4 on isa
ipmi0: IPMI device rev. 0, firmware rev. 2.92, version 2.0, device 
support mask 0xdf
ipmi0: Number of channels 5
ipmi0: Attached watchdog
ipmi0: Establishing power cycle handler
hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 
IAP/4/48/0x3ff 
IAF/3/48/0x67 
UCP/8/48/0x3f8 UCF/1/48/0x60
mfip0:  on mfi0
ioat0:  mem 0xdf0e0000-0xdf0e3fff irq 51 at device 22.0 on 
pci0
ioat0: Capabilities: 
77
ioat1:  mem 0xdf0e4000-0xdf0e7fff irq 52 at device 22.1 on 
pci0
ioat1: Capabilities: 
77
ioat2:  mem 0xdf0e8000-0xdf0ebfff irq 53 at device 22.2 on 
pci0
ioat2: Capabilities: 
77
ioat3:  mem 0xdf0ec000-0xdf0effff irq 54 at device 22.3 on 
pci0
ioat3: Capabilities: 
77
ioat4:  mem 0xdf0f0000-0xdf0f3fff irq 51 at device 22.4 on 
pci0
ioat4: Capabilities: 
77
ioat5:  mem 0xdf0f4000-0xdf0f7fff irq 52 at device 22.5 on 
pci0
ioat5: Capabilities: 
77
ioat6:  mem 0xdf0f8000-0xdf0fbfff irq 53 at device 22.6 on 
pci0
ioat6: Capabilities: 
77
ioat7:  mem 0xdf0fc000-0xdf0fffff irq 54 at device 22.7 on 
pci0
ioat7: Capabilities: 
77
bce0:  mem 
0xd6000000-0xd7ffffff irq 36 at device 0.0 on pci1
<6>bce0: Using defaults for TSO: 65518/35/2048
<6>bce0: Ethernet address: a4:ba:db:29:66:95
bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (7.10.0); 
Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)
Coal (RX:6,6,18,18; TX:20,20,80,80)
bce1:  mem 
0xd8000000-0xd9ffffff irq 48 at device 0.1 on pci1
<6>bce1: Using defaults for TSO: 65518/35/2048
<6>bce1: Ethernet address: a4:ba:db:29:66:97
bce1: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (7.10.0); 
Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)
Coal (RX:6,6,18,18; TX:20,20,80,80)
bce2:  mem 
0xda000000-0xdbffffff irq 32 at device 0.0 on pci2
<6>bce2: Using defaults for TSO: 65518/35/2048
<6>bce2: Ethernet address: a4:ba:db:29:66:99
bce2: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (7.10.0); 
Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)
Coal (RX:6,6,18,18; TX:20,20,80,80)
bce3:  mem 
0xdc000000-0xddffffff irq 42 at device 0.1 on pci2
<6>bce3: Using defaults for TSO: 65518/35/2048
<6>bce3: Ethernet address: a4:ba:db:29:66:9b
bce3: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (7.10.0); 
Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)
Coal (RX:6,6,18,18; TX:20,20,80,80)
miibus0:  on bce0
brgphy0:  PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
miibus1:  on bce1
brgphy1:  PHY 1 on miibus1
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
miibus2:  on bce2
brgphy2:  PHY 1 on miibus2
brgphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
miibus3:  on bce3
brgphy3:  PHY 1 on miibus3
brgphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
ums0 on uhub5
ums0:  on usbus3
ums0: 3 buttons and [Z] coordinates ID=0
ses0 at mfi0 bus 0 scbus0 target 32 lun 0
ses0:  Fixed Enclosure Services SPC-3 SCSI device
ses0: 150.000MB/s transfers
ses0: SES Device
atapci0:  port 
0xec10-0xec17,0xec08-0xec0b,0xec18-0xec1f,0xec0c-0xec0f,0xec20-0xec2f,0xec30-0xec3f 
irq 23 at device 31.2 on pci0
atapci0: failed to add ata child device
ata2:  at channel 0 on atapci0
device_attach: ata2 attach returned 6
<118>Autoloading module: acpi_wmi
acpi_wmi0:  on acpi0
acpi_wmi0: cannot find EC device
link_elf_obj: symbol nhgrp_get_group undefined
linker_load_file: /boot/kernel/netlink.ko - unsupported file type
KLD linux_common.ko: depends on netlink - not available or version 
mismatch

Fatal trap 12: page fault while in kernel mode
cpuid = 20; apic id = 12
fault virtual address = 0x0
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff8231c132
stack pointer         = 0x28:0xfffffe02b296a530
frame pointer         = 0x28:0xfffffe02b296a560
code segment = base 0x0, limit 0xfffff, type 0x1b
  = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 232 (kldload)
rdi: fffff80128ca00b0 rsi: fffffe02b296a538 rdx:                0
rcx: ffffffff825dbde0  r8:                4  r9:               f3
rax:                0 rbx: fffff80128b9ae80 rbp: fffffe02b296a560
r10:               f3 r11: ff9094d191909292 r12: fffff80128b9aec0
r13: fffffe02b296a584 r14: fffffe02b296a584 r15: ffffffff825dbdd0
trap number = 12
panic: page fault
cpuid = 20
time = 1664682860
KDB: stack backtrace:
#0 0xffffffff80508e9d at kdb_backtrace+0x5d
#1 0xffffffff804bc741 at vpanic+0x151
#2 0xffffffff804bc5e3 at panic+0x43
#3 0xffffffff807afe59 at trap_fatal+0x409
#4 0xffffffff807afeaf at trap_pfault+0x4f
#5 0xffffffff80787d18 at calltrap+0x8
#6 0xffffffff8048fddb at linker_file_unload+0xdb
#7 0xffffffff807bc858 at link_elf_load_file+0x198
#8 0xffffffff8048f659 at linker_load_module+0x999
#9 0xffffffff804921b3 at linker_load_dependencies+0xe3
#10 0xffffffff807bd7b3 at link_elf_load_file+0x10f3
#11 0xffffffff8048f659 at linker_load_module+0x999
#12 0xffffffff80491351 at kern_kldload+0x141
#13 0xffffffff8049145b at sys_kldload+0x5b
#14 0xffffffff807b074c at amd64_syscall+0x10c
#15 0xffffffff8078862b at fast_syscall_common+0xf8
Uptime: 22s
Dumping 5423 out of 131021 
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:5959 __asm("movq 
%%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
(kgdb) bt full
#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:59
         td = 
#1  dump_savectx () at /usr/src/sys/kern/kern_shutdown.c:405
No locals.
#2  0xffffffff804bc2e8 in dumpsys (di=0x0) at 
/usr/src/sys/x86/include/dump.h:87
No locals.
#3  doadump (textdump=) at 
/usr/src/sys/kern/kern_shutdown.c:434
         di = 0x0
         error = 
         coredump = 1
         di = 
#4  kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:541
         once = 0
#5  0xffffffff804bc7ae in vpanic (fmt=, 
ap=ap@entry=0xfffffe02b296a380)
     at /usr/src/sys/kern/kern_shutdown.c:979
         buf = "page fault", '\000' 
         other_cpus = {__bits = {15728639, 0, 0, 0}}
         td = 0xfffffe00e153d1e0
         bootopt = 
         newpanic = 
#6  0xffffffff804bc5e3 in panic (fmt=) at 
/usr/src/sys/kern/kern_shutdown.c:903
         ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 
0xfffffe02b296a3b0,
             reg_save_area = 0xfffffe02b296a350}}
#7  0xffffffff807afe59 in trap_fatal (frame=0xfffffe02b296a470, eva=0) 
at /usr/src/sys/amd64/amd64/trap.c:955
         softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, 
ssd_dpl = 0, ssd_p = 1, ssd_long = 1,
           ssd_def32 = 0, ssd_gran = 1}
         code = 
         gdt = 
         ss = 40
         type = 
         handled = 
#8  0xffffffff807afeaf in trap_pfault (frame=0xfffffe02b296a470, 
usermode=false, signo=,
     ucode=) at /usr/src/sys/amd64/amd64/trap.c:763
         td = 0xfffffe00e153d1e0
         p = 
         eva = 0
         map = 
         ftype = 
         rv = 
--Type  for more, q to quit, c to continue without paging--
#9  
No locals.
#10 0xffffffff8231c132 in sdt_kld_unload_try (arg=, 
lf=,
     error=0xfffffe02b296a584) at /usr/src/sys/cddl/dev/sdt/sdt.c:345
         begin = 
         end = 
         curr = 0xffffffff825dbdd0
         prov = 0xfffff80128b9aec0
         tmp = 0xfffff80128b9ae80
#11 0xffffffff8048fddb in linker_file_unload 
(file=file@entry=0xfffff80101392a80, flags=flags@entry=1)
     at /usr/src/sys/kern/kern_linker.c:675
         _ep = 0xfffff80128b9af00
         _t = 0xfffff80128b9af00
         _el = 0xfffff80117b87280
         error = 0
         mod = 
         next = 
         ml = 
         nextml = 
         i = 
         cp = 
#12 0xffffffff807bc858 in link_elf_load_file (cls=, 
filename=,
     result=) at /usr/src/sys/kern/link_elf_obj.c:1243
         td = 0xfffffe00e153d1e0
         error = 8
         shdr = 
         lf = 0xfffff80101392a80
         mapsize = 
         hdr = 0xfffff80117db0100
         nd = 0xfffff8011793f300
         flags = 1
         resid = 
         ef = 
         nbytes = 
         i = 
         symtabindex = 
         symstrindex = 
         nsym = 
         shstrindex = 
--Type  for more, q to quit, c to continue without paging--
         alignmask = 
         mapbase = 
         pb = 
         rl = 
         ra = 
         j = 
         es = 
#13 0xffffffff8048f659 in LINKER_LOAD_FILE (cls=0xffffffff80adb370 
,
     result=0xfffffe02b296a800, filename=) at 
./linker_if.h:214
         _m = 
         rc = 
         _desc = 
         _cep = 
         _ce = 
#14 linker_load_file (filename=, result=) 
at /usr/src/sys/kern/kern_linker.c:461
         lf = 0x0
         lc = 0xffffffff80adb370 
         foundfile = 0
         error = 
         modules = 
         _el = 
         _ep = 
         _t = 
         _tid = 
         _v = 
         _v = 
         _v = 
#15 linker_load_module (kldname=kldname@entry=0x0, 
modname=modname@entry=0xffffffff825c292c "linux_common",
     parent=parent@entry=0xfffff8011775e300,
     verinfo=verinfo@entry=0xffffffff825ce198 
<_linuxelf_depend_on_linux_common>, lfpp=lfpp@entry=0x0)
     at /usr/src/sys/kern/kern_linker.c:2205
         pathname = 
         filename = 
         error = 
         lfdep = 
#16 0xffffffff804921b3 in linker_load_dependencies (lf=0x0, 
lf@entry=0xfffff8011775e300)
     at /usr/src/sys/kern/kern_linker.c:2295
         error = 0
         start = 
--Type  for more, q to quit, c to continue without paging--
         stop = 
         mdp = 0xffffffff825cfab8 
<__set_modmetadata_set_sym__mod_metadata_md_linuxelf_on_linux_common>
         modname = 0xffffffff825c292c "linux_common"
         verinfo = 0xffffffff825ce198 <_linuxelf_depend_on_linux_common>
         mp = 
         nmodname = 
         nmdp = 
         nmp = 
         mod = 
         lfdep = 
         ver = 
#17 0xffffffff807bd7b3 in link_elf_load_file (cls=,
     filename=0xfffff801018e3880 "/boot/kernel/linux.ko", 
result=0xfffffe02b296ac10)
     at /usr/src/sys/kern/link_elf_obj.c:1212
         td = 0xfffffe00e153d1e0
         error = 
         shdr = 0xfffff801367be800
         lf = 0xfffff80128ca00b0
         mapsize = 
         hdr = 0xfffff80136929c00
         nd = 0xfffff80117958e00
         flags = 1
         resid = 
         ef = 0xfffff80128ca00b0
         nbytes = 
         i = 
         symtabindex = 
         symstrindex = 
         nsym = 
         shstrindex = 
         alignmask = 
         mapbase = 
         pb = 
         rl = 
         ra = 
         j = 
         es = 
#18 0xffffffff8048f659 in LINKER_LOAD_FILE (cls=0xffffffff80adb370 
,
     result=0xfffffe02b296ac10, filename=) at 
./linker_if.h:214
--Type  for more, q to quit, c to continue without paging--
         _m = 
         rc = 
         _desc = 
         _cep = 
         _ce = 
#19 linker_load_file (filename=, result=) 
at /usr/src/sys/kern/kern_linker.c:461
         lf = 0x0
         lc = 0xffffffff80adb370 
         foundfile = 0
         error = 
         modules = 
         _el = 
         _ep = 
         _t = 
         _tid = 
         _v = 
         _v = 
         _v = 
#20 linker_load_module (kldname=kldname@entry=0x0, 
modname=modname@entry=0xfffff8013632f800 "linux",
     parent=parent@entry=0x0, verinfo=verinfo@entry=0x0, 
lfpp=lfpp@entry=0xfffffe02b296ada0)
     at /usr/src/sys/kern/kern_linker.c:2205
         pathname = 
         filename = 
         error = 
         lfdep = 
#21 0xffffffff80491351 in kern_kldload (td=td@entry=0xfffffe00e153d1e0,
     file=file@entry=0xfffff8013632f800 "linux", 
fileid=fileid@entry=0xfffffe02b296ade4)
     at /usr/src/sys/kern/kern_linker.c:1164
         error = 
         modname = 0xfffff8013632f800 "linux"
         kldname = 0x0
         lf = 0xfffff80101633100
#22 0xffffffff8049145b in sys_kldload (td=0xfffffe00e153d1e0, 
uap=)
     at /usr/src/sys/kern/kern_linker.c:1187
         pathname = 0xfffff8013632f800 "linux"
         error = 0
         fileid = -2047
#23 0xffffffff807b074c in syscallenter (td=0xfffffe00e153d1e0)
     at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189
--Type  for more, q to quit, c to continue without paging--
         p = 0xfffffe00dfa4b008
         sa = 
         error = 
         se = 0xffffffff80a6ffc0 
         traced = 
         sy_thr_static = 
         _tid = 
         _v = 
         _v = 
         _audit_entered = 
         _tid = 
         _v = 
         _v = 
         _tid = 
         _v = 
         _v = 
#24 amd64_syscall (td=0xfffffe00e153d1e0, traced=0) at 
/usr/src/sys/amd64/amd64/trap.c:1200
         ksi = {ksi_link = {tqe_next = 0xfffffe02b296af30, tqe_prev = 
0xffffffff807af891 },
           ksi_info = {si_signo = -1298747696, si_errno = -510, si_code = 
-2142476180, si_pid = -1,
             si_uid = 0, si_status = 0, si_addr = 0x0, si_value = 
{sival_int = 0, sival_ptr = 0x0,
               sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = 
{_trapno = 0}, _timer = {_timerid = 0,
                 _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, 
_capsicum = {_syscall = 0},
               __spare__ = {__spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 
0, 0}}}}, ksi_flags = 0,
           ksi_sigq = 0x0}
#25 
No locals.
#26 0x000006977a82871a in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x69779933668

Sure looks like netlink needs to be made available as a kld.....

-- 
Larry Rosenman                     http://people.freebsd.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_c6fac64eb3c0d4c1aa3bdb883c568a3b
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



On 10/01/2022 10:43 pm, Larry Rosenman wrote:








On 10/01/2022 10:08 pm, Warner Losh wrote:








 






On Sat, Oct 1, 2022 at 9:06 PM La=
rry Rosenman <ler@=
freebsd.org> wrote:






On 10/01/2022 10:04 pm, Warn=
er Losh wrote:






Do  you have a /boot tarball that can be loaded in a =
VM that recreates the problem (along with a clean hash)?

 


But before you try that, have you tried a completely clean rebuild of =
the kernel to preclude the possibility that something is somehow cross thre=
aded?


 


Warner








On Sat, Oct 1, 2022 at 8:39 PM Larry Rosenman <ler@freebsd.org> wrot=
e:



=E2=9D=AF more info.11
Dump header from=
 device: /dev/mfid0p3
   Architecture: amd64
  &nb=
sp;Architecture Version: 2
   Dump Length: 126748815
&n=
bsp;  Blocksize: 512
   Compression: zstd
  &=
nbsp;Dumptime: 2022-10-01 21:26:40 -0500
   Hostname:
&=
nbsp;  Magic: FreeBSD Kernel Dump
   Version String: Fr=
eeBSD 14.0-CURRENT #168 
ler/freebsd-main-changes-n258354-6cdd871ebc4:=
 Sat Oct  1 21:13:01 CDT 
2022
     root@borg=
=2Elerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
  &nbs=
p;Panic String: page fault
   Dump Parity: 501115454
&n=
bsp;  Bounds: 11
   Dump Status: good

I do h=
ave source and debug stuff, BUT kgdb croaks on me.

I *CAN* give =
access to the machine.

the console backtrace showed something ab=
out the kld load of 
dependencies.



-- 
Lar=
ry Rosenman                  &=
nbsp;  http://people.freebsd.org/~ler
Phone: +1=
 214-642-9640                 =
E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-=
2106









let me wipe /usr/obj, and rebuild everything (I *DO* use meta-mode).






 


I've had fewer problems with it than non-meta mode, but this looks lik=
e a 'corruption' or 'cross threaded' crash I've chased in the past that wen=
t away with a rebuild. So it's better to be sure...


 


Warner 










Still breaks -- did someone(tm) forget to make netlink a module?







-- 
Larry Rosenman       =
              http://peopl=
e.freebsd.org/~ler
Phone: +1 214-642-9640       &nb=
sp;         E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr, Round =
Rock, TX 78665-2106










=E2=9D=AF sudo kgdb -c vmcore.12 /mnt/usr/lib/debug/boot/kernel/=
kernel.debug


GNU gdb (GDB) 12.1 [GDB v12.1 for FreeBSD]


Copyright (C) 2022 Free Software Foundation, Inc.


License GPLv3+: GNU GPL version 3 or later <http://gnu.org/li=
censes/gpl.html>


This is free software: you are free to change and redistribute i=
t.


There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.


This GDB was configured as "x86_64-portbld-freebsd14.0".<=
/div>

Type "show configuration" for configuration details.


For bug reporting instructions, please see:


<https://www.gnu.org/software/gdb/bugs/>.


Find the GDB manual and other documentation resources online at:=



    <http://www.gnu.org/software/gdb/documentation/=
>.


 


For help, type "help".


Type "apropos word" to search for commands related to "word"...<=
/span>


Reading symbols from /mnt/usr/lib/debug/boot/kernel/kernel.debug=
=2E..


 


Unread portion of the kernel message buffer:


---<<BOOT>>---


Copyright (c) 1992-2022 The FreeBSD Project.


Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 19=
93, 1994


 The Regents of the University of California. All rights reserve=
d.


FreeBSD is a registered trademark of The FreeBSD Foundation.


FreeBSD 14.0-CURRENT #0 ler/freebsd-main-changes-n258354-6cdd871=
ebc4: Sat Oct  1 22:30:48 CDT 2022


    root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/=
sys/LER-MINIMAL amd64


FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-proje=
ct.git llvmorg-14.0.5-0-gc12386ae247c)


VT(efifb): resolution 640x480


CPU: Intel(R) Xeon(R) CPU          &nbs=
p;X5660  @ 2.80GHz (2793.16-MHz K8-class CPU)


  Origin=3D"GenuineIntel"  Id=3D0x206c2  Family=
=3D0x6  Model=3D0x2c  Stepping=3D2


  Features=3D0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,C=
X8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,=
SS,HTT,TM,PBE>


  Features2=3D0x29ee3ff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL=
,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AESNI&g=
t;


  AMD Features=3D0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM=
>


  AMD Features2=3D0x1<LAHF>


  Structured Extended Features3=3D0x9c000000<IBPB,STIBP,=
L1DFL,SSBD>


  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID


  TSC: P-state invariant, performance statistics

real memory  =3D 137438953472 (131072 MB)


avail memory =3D 133789515776 (127591 MB)


CPU microcode: no matching update found


Event timer "LAPIC" quality 600


ACPI APIC Table: <DELL   PE_SC3  >

FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs


FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 hardware threads


random: unblocking device.


ioapic1: MADT APIC ID 1 !=3D hw id 0


ioapic0 <Version 2.0> irqs 0-23


ioapic1 <Version 2.0> irqs 32-55


Launching APs: 1 14 12 21 2 6 17 10 18 15 4 19 7 3 8 20 13 5 23 =
11 9 16 22


TCP_ratelimit: Is now initialized


TCP Hpts created 24 swi interrupt threads and bound 24 to NUMA d=
omains


random: entropy device external interface


kbd1 at kbdmux0


acpi0: <DELL PE_SC3>


acpi0: Power Button (fixed)


apei0: <ACPI Platform Error Interface> on acpi0

cpu0: <ACPI CPU> on acpi0


atrtc0: <AT realtime clock> port 0x70-0x7f irq 8 on acpi0<=
/span>


atrtc0: registered as a time-of-day clock, resolution 1.000000s<=
/span>


Event timer "RTC" frequency 32768 Hz quality 0


attimer0: <AT timer> port 0x40-0x5f irq 0 on acpi0<=
/div>

Timecounter "i8254" frequency 1193182 Hz quality 0


Event timer "i8254" frequency 1193182 Hz quality 100


hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed=
003ff on acpi0


Timecounter "HPET" frequency 14318180 Hz quality 950


Event timer "HPET" frequency 14318180 Hz quality 350


Event timer "HPET1" frequency 14318180 Hz quality 340

Event timer "HPET2" frequency 14318180 Hz quality 340

Event timer "HPET3" frequency 14318180 Hz quality 340

Timecounter "ACPI-fast" frequency 3579545 Hz quality 900<=
/div>

acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80=
b on acpi0


pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0


pci0: <ACPI PCI bus> on pcib0


pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0<=
/div>

pci1: <ACPI PCI bus> on pcib1


pci1: <network, ethernet> at device 0.0 (no driver attache=
d)


pci1: <network, ethernet> at device 0.1 (no driver attache=
d)


pcib2: <ACPI PCI-PCI bridge> at device 3.0 on pci0<=
/div>

pci2: <ACPI PCI bus> on pcib2


pci2: <network, ethernet> at device 0.0 (no driver attache=
d)


pci2: <network, ethernet> at device 0.1 (no driver attache=
d)


pcib3: <ACPI PCI-PCI bridge> at device 4.0 on pci0<=
/div>

pci3: <ACPI PCI bus> on pcib3


mfi0: <Dell PERC H700 Integrated> port 0xfc00-0xfcff mem 0=
xdf1bc000-0xdf1bffff,0xdf1c0000-0xdf1fffff irq 33 at device 0.0 on pci3


mfi0: Using MSI


mfi0: Megaraid SAS driver Ver 4.23


mfi0: FW MaxCmds =3D 1008, limiting to 128


mfi0: 55346 (717997792s/0x0020/info) - Shutdown command received=
 from host


pcib4: <ACPI PCI-PCI bridge>mfi0: 55347 (boot + 33s/0x0020=
/info) - Firmware initialization started (PCI ID 0079/1000/1f17/1028)


mfi0: 55348 (boot + 33s/0x0020/info) - Firmware version 2.100.03=
-4651


 at device 5.0 on pci0


pci4: <ACPI PCI bus>mfi0: 55349 (boot + 35s/0x0008/info) -=
 Battery Present


mfi0: 55350 (boot + 35s/0x0020/info) - Package version 12.10.7-0=
001


mfi0: 55351 (boot + 35s/0x0020/info) - Board Revision A00=



 on pcib4


pcib5: <ACPI PCI-PCI bridge>mfi0: 55352 (boot + 63s/0x0004=
/info) - Enclosure PD 20(c None/p0) communication restored


 at device 6.0 on pci0


pci5: <ACPI PCI bus>mfi0: 55353 (boot + 63s/0x0002/info) -=
 Inserted: Encl PD 20


mfi0: 55354 (boot + 63s/0x0002/info) - Inserted: PD 20(c None/p0=
) Info: enclPd=3D20, scsiType=3Dd, portMap=3D00, sasAddr=3D5b4ba0b019ef on =
pcib5


pcib6: <ACPI PCI-PCI bridge>e700,0000000000000000

mfi0: 55355 (boot + 63s/0x0002/info) - Inserted: PD 00(e0x20/s0)=



mfi0: 55356 (boot + 63s/0x0002/info) - Inserted: PD 00(e0x20/s0)=
 Info: enclPd=3D20, scsiType=3D0, portMap=3D04, sasAddr=3D4433221107000 at =
device 7.0 on pci0


pci6: <ACPI PCI bus>000,0000000000000000


mfi0: 55357 (boot + 63s/0x0002/WARN) - PD 00(e0x20/s0) is not a =
certified drive


mfi0: 55358 (boot + 63s/0x0002/info) - Inserted: PD 01(e0x20/s1)=



 on pcib6


pcib7: <ACPI PCI-PCI bridge>mfi0: 55359 (boot + 63s/0x0002=
/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=3D20, scsiType=3D0, portMap=
=3D05, sasAddr=3D4433221106000 at device 9.0 on pci0


pci7: <ACPI PCI bus>000,0000000000000000


mfi0: 55360 (boot + 63s/0x0002/WARN) - PD 01(e0x20/s1) is not a =
certified drive


mfi0: 55361 (boot + 63s/0x0002/info) - Inserted: PD 02(e0x20/s2)=



 on pcib7


pci0: <base peripheral, interrupt controller>mfi0: 55362 (=
boot + 63s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: enclPd=3D20, scsi=
Type=3D0, portMap=3D01, sasAddr=3D4433221105000 at device 20.0 (no driver a=
ttached)


pci0: <base peripheral, interrupt controller>000,000000000=
0000000


mfi0: 55363 (boot + 63s/0x0002/WARN) - PD 02(e0x20/s2) is not a =
certified drive


mfi0: 55364 (boot + 63s/0x0002/info) - Inserted: PD 03(e0x20/s3)=



 at device 20.1 (no driver attached)


pci0: <base peripheral, interrupt controller>mfi0: 55365 (=
boot + 63s/0x0002/info) - Inserted: PD 03(e0x20/s3) Info: enclPd=3D20, scsi=
Type=3D0, portMap=3D02, sasAddr=3D4433221104000 at device 20.2 (no driver a=
ttached)


uhci0: <Intel 82801I (ICH9) USB controller>000,00000000000=
00000


 port 0xec40-0xec5f irq 17 at device 26.0 on pci0

mfi0: 55366 (boot + 63s/0x0002/WARN) - PD 03(e0x20/s3) is not a =
certified drive


mfi0: 55367 (boot + 63s/0x0002/info) - Inserted: PD 04(e0x20/s4)=



mfi0: 55368 (boot + 63s/0x0002/info) - Inserted: PD 04(e0x20/s4)=
 Info: enclPd=3D20, scsiType=3D0, portMap=3D03, sasAddr=3D4433221103000000,=
0000000000000000


mfi0: 55369 (boot + 63s/0x0002/WARN) - PD 04(e0x20/s4) is not a =
certified drive


mfi0: 55370 (boot + 63s/0x0002/info) - Inserted: PD 05(e0x20/s5)=



mfi0: 55371 (boot + 63s/0x0002/info) - Inserted: PD 05(e0x20/s5)=
 Info: enclPd=3D20, scsiType=3D0, portMap=3D00, sasAddr=3D4433221102000usbu=
s0000,0000000000000000


mfi0: 55372 (boot + 63s/0x0002/WARN) - PD 05(e0x20/s5) is not a =
certified drive


mfi0: 55373 (boot + 100s/0x0008/info) - Battery temperature is n=
ormal


 on uhci0


mfi0: 55374 (boot + 100s/0x0008/info) - Current capacity of the =
battery is above threshold


mfi0: 55375 (boot + 100s/0x0008/info) - Battery charge complete<=
/span>


mfi0: 55376 (717997971s/0x0020/info) - Time established as 10/02=
/22  3:52:51; (148 seconds since power on)


usbus0: 12Mbps Full Speed USB v1.0


uhci1: <Intel 82801I (ICH9) USB controller> port 0xec60-0x=
ec7f irq 18 at device 26.1 on pci0


usbus1 on uhci1


usbus1: 12Mbps Full Speed USB v1.0


ehci0: <Intel 82801I (ICH9) USB 2.0 controller> mem 0xdf0d=
e000-0xdf0de3ff irq 19 at device 26.7 on pci0


usbus2: EHCI version 1.0


usbus2 on ehci0


usbus2: 480Mbps High Speed USB v2.0


uhci2: <Intel 82801I (ICH9) USB controller> port 0xec80-0x=
ec9f irq 21 at device 29.0 on pci0


usbus3 on uhci2


usbus3: 12Mbps Full Speed USB v1.0


uhci3: <Intel 82801I (ICH9) USB controller> port 0xeca0-0x=
ecbf irq 20 at device 29.1 on pci0


usbus4 on uhci3


usbus4: 12Mbps Full Speed USB v1.0


ehci1: <Intel 82801I (ICH9) USB 2.0 controller> mem 0xdf0d=
f000-0xdf0df3ff irq 21 at device 29.7 on pci0


usbus5: EHCI version 1.0


usbus5 on ehci1


usbus5: 480Mbps High Speed USB v2.0


pcib8: <ACPI PCI-PCI bridge> at device 30.0 on pci0=



pci8: <ACPI PCI bus> on pcib8


vgapci0: <VGA-compatible display> mem 0xd5800000-0xd5fffff=
f,0xde7fc000-0xde7fffff,0xde800000-0xdeffffff irq 19 at device 3.0 on pci8<=
/span>


vgapci0: Boot video device


isab0: <PCI-ISA bridge> at device 31.0 on pci0


isa0: <ISA bus> on isab0


pci0: <mass storage, ATA> at device 31.2 (no driver attach=
ed)


uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags =
0x10 on acpi0


uart0: console (115200,n,8,1)


uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acp=
i0


orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0=
xcdfff,0xec000-0xeffff pnpid ORM0000 on isa0


atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 o=
n isa0


atkbd0: <AT Keyboard> irq 1 on atkbdc0


kbd0 at atkbd0


atkbd0: [GIANT-LOCKED]


est0: <Enhanced SpeedStep Frequency Control> on cpu0


Timecounter "TSC-low" frequency 1396499773 Hz quality 1000


Timecounters tick every 1.000 msec


ZFS filesystem version: 5


ZFS storage pool version: features support (5000)


ugen0.1: <Intel UHCI root HUB> at usbus0


ugen2.1: <Intel EHCI root HUB> at usbus2


mfid0 on mfi0


mfid0: 1907200MB (3905945600 sectors) RAID volume 'Disk2' is opt=
imal


ugen1.1: <Intel UHCI root HUB> at usbus1


uhub0 on usbus0


uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1=
> on usbus0


ugen4.1: <Intel UHCI root HUB> at usbus4


uhub1 on usbus1


uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1=
> on usbus1


mfid1 on mfi0


mfid1: 1907200MB (3905945600 sectors) RAID volume 'Disk1' is opt=
imal


uhub2 on usbus4


uhub2: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1=
> on usbus4


uhub3 on usbus2


uhub3: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1=
> on usbus2


ugen5.1: <Intel EHCI root HUB> at usbus5


ugen3.1: <Intel UHCI root HUB> at usbus3


mfid2 on mfi0


mfid2: 2861056MB (5859442688 sectors) RAID volume 'Disk0' is opt=
imal


uhub4 on usbus5


uhub4: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1=
> on usbus5


mfid3 on mfi0


mfid3: 2861056MB (5859442688 sectors) RAID volume 'Disk4' is opt=
imal


uhub5 on usbus3


uhub5: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1=
> on usbus3


mfid4 on mfi0


mfid4: 1907200MB (3905945600 sectors) RAID volume 'Disk3' is opt=
imal


mfid5 on mfi0


mfid5: 1907200MB (3905945600 sectors) RAID volume 'DIsk5' is opt=
imal


Trying to mount root from zfs:zroot/ROOT/14-2022_10_01-2233 []..=
=2E


uhub0: 2 ports with 2 removable, self powered


uhub1: 2 ports with 2 removable, self powered


uhub2: 2 ports with 2 removable, self powered


uhub5: 2 ports with 2 removable, self powered


Root mount waiting for: usbus2 usbus5


uhub3: 4 ports with 4 removable, self powered


uhub4: 4 ports with 4 removable, self powered


Root mount waiting for: usbus2 usbus5


ugen2.2: <vendor 0x0424 product 0x2514> at usbus2

uhub6 on uhub3


uhub6: <vendor 0x0424 product 0x2514, class 9/0, rev 2.00/0.0=
0, addr 2> on usbus2


uhub6: MTT enabled


ugen0.2: <Raritan D2CIM-VUSB> at usbus0


ukbd0 on uhub0


ukbd0: <Keybd+Abs+Rel Mouse> on usbus0


kbd2 at ukbd0


uhub6: 3 ports with 3 removable, self powered


ugen3.2: <American Power Conversion Back-UPS RS 1500MS FW:952=
=2Ee3 .D USB FW:e3> at usbus3


ugen3.3: <Avocent USB Composite Device-0> at usbus3=



ukbd1 on uhub5


ukbd1: <Keyboard> on usbus3


kbd3 at ukbd1


Dual Console: Video Primary, Serial Secondary


<118>sysctl: net.inet.tcp.functions_default=3Drack at line=
 55: No such file or directory


<118>Setting hostuuid: 4c4c4544-0035-4310-8048-c7c04f524c3=
1.


<118>Setting hostid: 0xd7b851f2.


<118>no pools available to import


<118>Starting file system checks:


<118>Mounting local filesystems:.


<118>Loading kernel modules:


aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>

coretemp0: <CPU On-Die Thermal Sensors> on cpu0

link_elf_obj: symbol nhgrp_get_group undefined


linker_load_file: /boot/kernel/netlink.ko - unsupported file typ=
e


KLD linux_common.ko: depends on netlink - not available or versi=
on mismatch


linker_load_file: /boot/kernel/linux_common.ko - unsupported fil=
e type


KLD linux.ko: depends on linux_common - not available or version=
 mismatch


linker_load_file: /boot/kernel/linux.ko - unsupported file type<=
/span>


<118>kldload: an error occurred while loading module linux=
=2E Please check dmesg(8) for more details.


<118>/etc/rc: WARNING: Unable to load kernel module linux<=
/span>


ichwd0: <Intel ICH9 watchdog timer> on isa0


efirtc0: <EFI Realtime Clock>


efirtc0: registered as a time-of-day clock, resolution 1.000000s=



ipmi0: <IPMI System Interface> on isa0


ipmi0: KCS mode found at io 0xca8 alignment 0x4 on isa

ipmi0: IPMI device rev. 0, firmware rev. 2.92, version 2.0, devi=
ce support mask 0xdf


ipmi0: Number of channels 5


ipmi0: Attached watchdog


ipmi0: Establishing power cycle handler


hwpmc: SOFT/16/64/0x67<INT,USR,SYS,REA,WRI> TSC/1/64/0x20&=
lt;REA> IAP/4/48/0x3ff<INT,USR,SYS,EDG,THR,REA,WRI,INV,QUA,PRC> IA=
F/3/48/0x67<INT,USR,SYS,REA,WRI> UCP/8/48/0x3f8<EDG,THR,REA,WRI,IN=
V,QUA,PRC> UCF/1/48/0x60<REA,WRI>


mfip0: <SCSI Passthrough Bus> on mfi0


ioat0: <TBG IOAT Ch0> mem 0xdf0e0000-0xdf0e3fff irq 51 at =
device 22.0 on pci0


ioat0: Capabilities: 77<Block_Fill,Move_CRC,DCA,Marker_Skippi=
ng,CRC,Page_Break>


ioat1: <TBG IOAT Ch1> mem 0xdf0e4000-0xdf0e7fff irq 52 at =
device 22.1 on pci0


ioat1: Capabilities: 77<Block_Fill,Move_CRC,DCA,Marker_Skippi=
ng,CRC,Page_Break>


ioat2: <TBG IOAT Ch2> mem 0xdf0e8000-0xdf0ebfff irq 53 at =
device 22.2 on pci0


ioat2: Capabilities: 77<Block_Fill,Move_CRC,DCA,Marker_Skippi=
ng,CRC,Page_Break>


ioat3: <TBG IOAT Ch3> mem 0xdf0ec000-0xdf0effff irq 54 at =
device 22.3 on pci0


ioat3: Capabilities: 77<Block_Fill,Move_CRC,DCA,Marker_Skippi=
ng,CRC,Page_Break>


ioat4: <TBG IOAT Ch4> mem 0xdf0f0000-0xdf0f3fff irq 51 at =
device 22.4 on pci0


ioat4: Capabilities: 77<Block_Fill,Move_CRC,DCA,Marker_Skippi=
ng,CRC,Page_Break>


ioat5: <TBG IOAT Ch5> mem 0xdf0f4000-0xdf0f7fff irq 52 at =
device 22.5 on pci0


ioat5: Capabilities: 77<Block_Fill,Move_CRC,DCA,Marker_Skippi=
ng,CRC,Page_Break>


ioat6: <TBG IOAT Ch6> mem 0xdf0f8000-0xdf0fbfff irq 53 at =
device 22.6 on pci0


ioat6: Capabilities: 77<Block_Fill,Move_CRC,DCA,Marker_Skippi=
ng,CRC,Page_Break>


ioat7: <TBG IOAT Ch7> mem 0xdf0fc000-0xdf0fffff irq 54 at =
device 22.7 on pci0


ioat7: Capabilities: 77<Block_Fill,Move_CRC,DCA,Marker_Skippi=
ng,CRC,Page_Break>


bce0: <QLogic NetXtreme II BCM5709 1000Base-T (C0)> mem 0x=
d6000000-0xd7ffffff irq 36 at device 0.0 on pci1


<6>bce0: Using defaults for TSO: 65518/35/2048


<6>bce0: Ethernet address: a4:ba:db:29:66:95


bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (=
7.10.0); Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)


Coal (RX:6,6,18,18; TX:20,20,80,80)


bce1: <QLogic NetXtreme II BCM5709 1000Base-T (C0)> mem 0x=
d8000000-0xd9ffffff irq 48 at device 0.1 on pci1


<6>bce1: Using defaults for TSO: 65518/35/2048


<6>bce1: Ethernet address: a4:ba:db:29:66:97


bce1: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (=
7.10.0); Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)


Coal (RX:6,6,18,18; TX:20,20,80,80)


bce2: <QLogic NetXtreme II BCM5709 1000Base-T (C0)> mem 0x=
da000000-0xdbffffff irq 32 at device 0.0 on pci2


<6>bce2: Using defaults for TSO: 65518/35/2048


<6>bce2: Ethernet address: a4:ba:db:29:66:99


bce2: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (=
7.10.0); Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)


Coal (RX:6,6,18,18; TX:20,20,80,80)


bce3: <QLogic NetXtreme II BCM5709 1000Base-T (C0)> mem 0x=
dc000000-0xddffffff irq 42 at device 0.1 on pci2


<6>bce3: Using defaults for TSO: 65518/35/2048


<6>bce3: Ethernet address: a4:ba:db:29:66:9b


bce3: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (=
7.10.0); Bufs (RX:8;TX:8;PG:32); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.13)


Coal (RX:6,6,18,18; TX:20,20,80,80)


miibus0: <MII bus> on bce0


brgphy0: <BCM5709 10/100/1000baseT PHY> PHY 1 on miibus0


brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1=
000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto=
-flow


miibus1: <MII bus> on bce1


brgphy1: <BCM5709 10/100/1000baseT PHY> PHY 1 on miibus1


brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1=
000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto=
-flow


miibus2: <MII bus> on bce2


brgphy2: <BCM5709 10/100/1000baseT PHY> PHY 1 on miibus2


brgphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1=
000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto=
-flow


miibus3: <MII bus> on bce3


brgphy3: <BCM5709 10/100/1000baseT PHY> PHY 1 on miibus3


brgphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1=
000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto=
-flow


ums0 on uhub5


ums0: <Mouse> on usbus3


ums0: 3 buttons and [Z] coordinates ID=3D0


ses0 at mfi0 bus 0 scbus0 target 32 lun 0


ses0: <DP BACKPLANE 1.07> Fixed Enclosure Services SPC-3 S=
CSI device


ses0: 150.000MB/s transfers


ses0: SES Device


atapci0: <Intel ATA controller> port 0xec10-0xec17,0xec08-=
0xec0b,0xec18-0xec1f,0xec0c-0xec0f,0xec20-0xec2f,0xec30-0xec3f irq 23 at de=
vice 31.2 on pci0


atapci0: failed to add ata child device


ata2: <ATA channel> at channel 0 on atapci0


device_attach: ata2 attach returned 6


<118>Autoloading module: acpi_wmi


acpi_wmi0: <ACPI-WMI mapping> on acpi0


acpi_wmi0: cannot find EC device


link_elf_obj: symbol nhgrp_get_group undefined


linker_load_file: /boot/kernel/netlink.ko - unsupported file typ=
e


KLD linux_common.ko: depends on netlink - not available or versi=
on mismatch


 


 


Fatal trap 12: page fault while in kernel mode


cpuid =3D 20; apic id =3D 12


fault virtual address =3D 0x0


fault code =3D supervisor read data, page not present

instruction pointer =3D 0x20:0xffffffff8231c132


stack pointer         =3D 0x28:0xfffffe02b29=
6a530


frame pointer         =3D 0x28:0xfffffe02b29=
6a560


code segment =3D base 0x0, 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 232 (kldload)


rdi: fffff80128ca00b0 rsi: fffffe02b296a538 rdx:    &n=
bsp;           0


rcx: ffffffff825dbde0  r8:         =
;       4  r9:           =
    f3


rax:                0 rb=
x: fffff80128b9ae80 rbp: fffffe02b296a560


r10:               f3 r1=
1: ff9094d191909292 r12: fffff80128b9aec0


r13: fffffe02b296a584 r14: fffffe02b296a584 r15: ffffffff825dbdd=
0


trap number =3D 12


panic: page fault


cpuid =3D 20


time =3D 1664682860


KDB: stack backtrace:


#0 0xffffffff80508e9d at kdb_backtrace+0x5d


#1 0xffffffff804bc741 at vpanic+0x151


#2 0xffffffff804bc5e3 at panic+0x43


#3 0xffffffff807afe59 at trap_fatal+0x409


#4 0xffffffff807afeaf at trap_pfault+0x4f


#5 0xffffffff80787d18 at calltrap+0x8


#6 0xffffffff8048fddb at linker_file_unload+0xdb


#7 0xffffffff807bc858 at link_elf_load_file+0x198


#8 0xffffffff8048f659 at linker_load_module+0x999


#9 0xffffffff804921b3 at linker_load_dependencies+0xe3

#10 0xffffffff807bd7b3 at link_elf_load_file+0x10f3


#11 0xffffffff8048f659 at linker_load_module+0x999


#12 0xffffffff80491351 at kern_kldload+0x141


#13 0xffffffff8049145b at sys_kldload+0x5b


#14 0xffffffff807b074c at amd64_syscall+0x10c


#15 0xffffffff8078862b at fast_syscall_common+0xf8


Uptime: 22s


Dumping 5423 out of 131021 MB:..1%..11%..21%..31%..41%..51%..61%=
=2E.71%..81%..91%


 


__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:5959 __a=
sm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(struct pcpu,

(kgdb) bt full


#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h=
:59


        td =3D <optimized out><=
/div>

#1  dump_savectx () at /usr/src/sys/kern/kern_shutdown.c:40=
5


No locals.


#2  0xffffffff804bc2e8 in dumpsys (di=3D0x0) at /usr/src/sy=
s/x86/include/dump.h:87


No locals.


#3  doadump (textdump=3D<optimized out>) at /usr/src/=
sys/kern/kern_shutdown.c:434


        di =3D 0x0


        error =3D <optimized out>


        coredump =3D 1


        di =3D <optimized out><=
/div>

#4  kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shu=
tdown.c:541


        once =3D 0


#5  0xffffffff804bc7ae in vpanic (fmt=3D<optimized out&g=
t;, ap=3Dap@entry=3D0xfffffe02b296a380)


    at /usr/src/sys/kern/kern_shutdown.c:979

        buf =3D "page fault", '\000' <rep=
eats 245 times>


        other_cpus =3D {__bits =3D {15728639=
, 0, 0, 0}}


        td =3D 0xfffffe00e153d1e0

        bootopt =3D <unavailable>


        newpanic =3D <optimized out>


#6  0xffffffff804bc5e3 in panic (fmt=3D<unavailable>)=
 at /usr/src/sys/kern/kern_shutdown.c:903


        ap =3D {{gp_offset =3D 16, fp_offset=
 =3D 48, overflow_arg_area =3D 0xfffffe02b296a3b0,


            reg_save_area =3D 0xff=
fffe02b296a350}}


#7  0xffffffff807afe59 in trap_fatal (frame=3D0xfffffe02b29=
6a470, eva=3D0) at /usr/src/sys/amd64/amd64/trap.c:955


        softseg =3D {ssd_base =3D 0, ssd_lim=
it =3D 1048575, ssd_type =3D 27, ssd_dpl =3D 0, ssd_p =3D 1, ssd_long =3D 1=
,


          ssd_def32 =3D 0, ssd_gran =3D=
 1}


        code =3D <optimized out>


        gdt =3D <optimized out>=



        ss =3D 40


        type =3D <optimized out>


        handled =3D <optimized out>


#8  0xffffffff807afeaf in trap_pfault (frame=3D0xfffffe02b2=
96a470, usermode=3Dfalse, signo=3D<optimized out>,


    ucode=3D<optimized out>) at /usr/src/sys/amd=
64/amd64/trap.c:763


        td =3D 0xfffffe00e153d1e0

        p =3D <optimized out>

        eva =3D 0


        map =3D <optimized out>=



        ftype =3D <optimized out>


        rv =3D <optimized out><=
/div>

--Type <RET> for more, q to quit, c to continue without pa=
ging--


#9  <signal handler called>


No locals.


#10 0xffffffff8231c132 in sdt_kld_unload_try (arg=3D<optimize=
d out>, lf=3D<optimized out>,


    error=3D0xfffffe02b296a584) at /usr/src/sys/cddl/d=
ev/sdt/sdt.c:345


        begin =3D <optimized out>


        end =3D <optimized out>=



        curr =3D 0xffffffff825dbdd0

        prov =3D 0xfffff80128b9aec0

        tmp =3D 0xfffff80128b9ae80

#11 0xffffffff8048fddb in linker_file_unload (file=3Dfile@entry=
=3D0xfffff80101392a80, flags=3Dflags@entry=3D1)


    at /usr/src/sys/kern/kern_linker.c:675


        _ep =3D 0xfffff80128b9af00

        _t =3D 0xfffff80128b9af00

        _el =3D 0xfffff80117b87280

        error =3D 0


        mod =3D <optimized out>=



        next =3D <optimized out>


        ml =3D <optimized out><=
/div>

        nextml =3D <optimized out>


        i =3D <optimized out>

        cp =3D <optimized out><=
/div>

#12 0xffffffff807bc858 in link_elf_load_file (cls=3D<optimize=
d out>, filename=3D<optimized out>,


    result=3D<optimized out>) at /usr/src/sys/ke=
rn/link_elf_obj.c:1243


        td =3D 0xfffffe00e153d1e0

        error =3D 8


        shdr =3D <optimized out>


        lf =3D 0xfffff80101392a80

        mapsize =3D <optimized out>


        hdr =3D 0xfffff80117db0100

        nd =3D 0xfffff8011793f300

        flags =3D 1


        resid =3D <optimized out>


        ef =3D <optimized out><=
/div>

        nbytes =3D <optimized out>


        i =3D <optimized out>

        symtabindex =3D <optimized out>=
;


        symstrindex =3D <optimized out>=
;


        nsym =3D <optimized out>


        shstrindex =3D <optimized out>=



--Type <RET> for more, q to quit, c to continue without pa=
ging--


        alignmask =3D <optimized out><=
/span>


        mapbase =3D <optimized out>


        pb =3D <optimized out><=
/div>

        rl =3D <optimized out><=
/div>

        ra =3D <optimized out><=
/div>

        j =3D <optimized out>

        es =3D <optimized out><=
/div>

#13 0xffffffff8048f659 in LINKER_LOAD_FILE (cls=3D0xffffffff80ad=
b370 <link_elf_class>,


    result=3D0xfffffe02b296a800, filename=3D<optimi=
zed out>) at ./linker_if.h:214


        _m =3D <optimized out><=
/div>

        rc =3D <optimized out><=
/div>

        _desc =3D <optimized out>


        _cep =3D <optimized out>


        _ce =3D <optimized out>=



#14 linker_load_file (filename=3D<optimized out>, result=
=3D<optimized out>) at /usr/src/sys/kern/kern_linker.c:461

        lf =3D 0x0


        lc =3D 0xffffffff80adb370 <link_e=
lf_class>


        foundfile =3D 0


        error =3D <optimized out>


        modules =3D <optimized out>


        _el =3D <optimized out>=



        _ep =3D <optimized out>=



        _t =3D <optimized out><=
/div>

        _tid =3D <optimized out>


        _v =3D <optimized out><=
/div>

        _v =3D <optimized out><=
/div>

        _v =3D <optimized out><=
/div>

#15 linker_load_module (kldname=3Dkldname@entry=3D0x0, modname=
=3Dmodname@entry=3D0xffffffff825c292c "linux_common",


    parent=3Dparent@entry=3D0xfffff8011775e300,=



    verinfo=3Dverinfo@entry=3D0xffffffff825ce198 <_=
linuxelf_depend_on_linux_common>, lfpp=3Dlfpp@entry=3D0x0)


    at /usr/src/sys/kern/kern_linker.c:2205

        pathname =3D <optimized out>


        filename =3D <optimized out>


        error =3D <optimized out>


        lfdep =3D <optimized out>


#16 0xffffffff804921b3 in linker_load_dependencies (lf=3D0x0, lf=
@entry=3D0xfffff8011775e300)


    at /usr/src/sys/kern/kern_linker.c:2295

        error =3D 0


        start =3D <optimized out>


--Type <RET> for more, q to quit, c to continue without pa=
ging--


        stop =3D <optimized out>


        mdp =3D 0xffffffff825cfab8 <__set=
_modmetadata_set_sym__mod_metadata_md_linuxelf_on_linux_common>

        modname =3D 0xffffffff825c292c "linu=
x_common"


        verinfo =3D 0xffffffff825ce198 <_=
linuxelf_depend_on_linux_common>


        mp =3D <optimized out><=
/div>

        nmodname =3D <optimized out>


        nmdp =3D <optimized out>


        nmp =3D <optimized out>=



        mod =3D <optimized out>=



        lfdep =3D <optimized out>


        ver =3D <optimized out>=



#17 0xffffffff807bd7b3 in link_elf_load_file (cls=3D<optimize=
d out>,


    filename=3D0xfffff801018e3880 "/boot/kernel/linux.=
ko", result=3D0xfffffe02b296ac10)


    at /usr/src/sys/kern/link_elf_obj.c:1212

        td =3D 0xfffffe00e153d1e0

        error =3D <optimized out>


        shdr =3D 0xfffff801367be800

        lf =3D 0xfffff80128ca00b0

        mapsize =3D <optimized out>


        hdr =3D 0xfffff80136929c00

        nd =3D 0xfffff80117958e00

        flags =3D 1


        resid =3D <optimized out>


        ef =3D 0xfffff80128ca00b0

        nbytes =3D <optimized out>


        i =3D <optimized out>

        symtabindex =3D <optimized out>=
;


        symstrindex =3D <optimized out>=
;


        nsym =3D <optimized out>


        shstrindex =3D <optimized out>=



        alignmask =3D <optimized out><=
/span>


        mapbase =3D <optimized out>


        pb =3D <optimized out><=
/div>

        rl =3D <optimized out><=
/div>

        ra =3D <optimized out><=
/div>

        j =3D <optimized out>

        es =3D <optimized out><=
/div>

#18 0xffffffff8048f659 in LINKER_LOAD_FILE (cls=3D0xffffffff80ad=
b370 <link_elf_class>,


    result=3D0xfffffe02b296ac10, filename=3D<optimi=
zed out>) at ./linker_if.h:214


--Type <RET> for more, q to quit, c to continue without pa=
ging--


        _m =3D <optimized out><=
/div>

        rc =3D <optimized out><=
/div>

        _desc =3D <optimized out>


        _cep =3D <optimized out>


        _ce =3D <optimized out>=



#19 linker_load_file (filename=3D<optimized out>, result=
=3D<optimized out>) at /usr/src/sys/kern/kern_linker.c:461

        lf =3D 0x0


        lc =3D 0xffffffff80adb370 <link_e=
lf_class>


        foundfile =3D 0


        error =3D <optimized out>


        modules =3D <optimized out>


        _el =3D <optimized out>=



        _ep =3D <optimized out>=



        _t =3D <optimized out><=
/div>

        _tid =3D <optimized out>


        _v =3D <optimized out><=
/div>

        _v =3D <optimized out><=
/div>

        _v =3D <optimized out><=
/div>

#20 linker_load_module (kldname=3Dkldname@entry=3D0x0, modname=
=3Dmodname@entry=3D0xfffff8013632f800 "linux",


    parent=3Dparent@entry=3D0x0, verinfo=3Dverinfo@ent=
ry=3D0x0, lfpp=3Dlfpp@entry=3D0xfffffe02b296ada0)


    at /usr/src/sys/kern/kern_linker.c:2205

        pathname =3D <optimized out>


        filename =3D <optimized out>


        error =3D <optimized out>


        lfdep =3D <optimized out>


#21 0xffffffff80491351 in kern_kldload (td=3Dtd@entry=3D0xfffffe=
00e153d1e0,


    file=3Dfile@entry=3D0xfffff8013632f800 "linux", fi=
leid=3Dfileid@entry=3D0xfffffe02b296ade4)


    at /usr/src/sys/kern/kern_linker.c:1164

        error =3D <optimized out>


        modname =3D 0xfffff8013632f800 "linu=
x"


        kldname =3D 0x0


        lf =3D 0xfffff80101633100

#22 0xffffffff8049145b in sys_kldload (td=3D0xfffffe00e153d1e0, =
uap=3D<optimized out>)


    at /usr/src/sys/kern/kern_linker.c:1187

        pathname =3D 0xfffff8013632f800 "lin=
ux"


        error =3D 0


        fileid =3D -2047


#23 0xffffffff807b074c in syscallenter (td=3D0xfffffe00e153d1e0)=



    at /usr/src/sys/amd64/amd64/../../kern/subr_syscal=
l.c:189


--Type <RET> for more, q to quit, c to continue without pa=
ging--


        p =3D 0xfffffe00dfa4b008


        sa =3D <optimized out><=
/div>

        error =3D <optimized out>


        se =3D 0xffffffff80a6ffc0 <sysent=
+9728>


        traced =3D <optimized out>


        sy_thr_static =3D <optimized out&=
gt;


        _tid =3D <optimized out>


        _v =3D <optimized out><=
/div>

        _v =3D <optimized out><=
/div>

        _audit_entered =3D <optimized out=
>


        _tid =3D <optimized out>


        _v =3D <optimized out><=
/div>

        _v =3D <optimized out><=
/div>

        _tid =3D <optimized out>


        _v =3D <optimized out><=
/div>

        _v =3D <optimized out><=
/div>

#24 amd64_syscall (td=3D0xfffffe00e153d1e0, traced=3D0) at /usr/=
src/sys/amd64/amd64/trap.c:1200


        ksi =3D {ksi_link =3D {tqe_next =3D =
0xfffffe02b296af30, tqe_prev =3D 0xffffffff807af891 <trap+1809>},


          ksi_info =3D {si_signo =3D -1=
298747696, si_errno =3D -510, si_code =3D -2142476180, si_pid =3D -1,


            si_uid =3D 0, si_statu=
s =3D 0, si_addr =3D 0x0, si_value =3D {sival_int =3D 0, sival_ptr =3D 0x0,=



              sigval_int =3D =
0, sigval_ptr =3D 0x0}, _reason =3D {_fault =3D {_trapno =3D 0}, _timer =3D=
 {_timerid =3D 0,


                _overrun=
 =3D 0}, _mesgq =3D {_mqd =3D 0}, _poll =3D {_band =3D 0}, _capsicum =3D {_=
syscall =3D 0},


              __spare__ =3D {=
__spare1__ =3D 0, __spare2__ =3D {0, 0, 0, 0, 0, 0, 0}}}}, ksi_flags =3D 0,=



          ksi_sigq =3D 0x0}


#25 <signal handler called>


No locals.


#26 0x000006977a82871a in ?? ()


No symbol table info available.


Backtrace stopped: Cannot access memory at address 0x69779933668=



 


Sure looks like netlink needs to be made available as a kld.....=





=
-- 
Larry Rosenman        =
;             http://people.fre=
ebsd.org/~ler
Phone: +1 214-642-9640         &=
nbsp;       E-Mail: ler@F=
reeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106





--=_c6fac64eb3c0d4c1aa3bdb883c568a3b--

From nobody Sun Oct  2 13:12:29 2022
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 4MgPX53x0Dz4dPwN
	for ; Sun,  2 Oct 2022 13:12:37 +0000 (UTC)
	(envelope-from melifaro@ipfw.ru)
Received: from forward500j.mail.yandex.net (forward500j.mail.yandex.net [5.45.198.250])
	(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 4MgPX33CV8z3rvk
	for ; Sun,  2 Oct 2022 13:12:35 +0000 (UTC)
	(envelope-from melifaro@ipfw.ru)
Received: from iva5-057a0d1fbbd8.qloud-c.yandex.net (iva5-057a0d1fbbd8.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:7f1c:0:640:57a:d1f])
	by forward500j.mail.yandex.net (Yandex) with ESMTP id 2A76A6CB653D;
	Sun,  2 Oct 2022 16:12:32 +0300 (MSK)
Received: by iva5-057a0d1fbbd8.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id xxp1p8T9HS-CUiGYDsY;
	Sun, 02 Oct 2022 16:12:31 +0300
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client certificate not present)
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1664716351;
	bh=EwJgxWdkZzPb+tNQBREoCUzkb+dJA7YBnLzUkMVpQgM=;
	h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject;
	b=MgSmtRFTsQXHkpHqi2O7bIqDI8Nfo6AJuFOT7Jw0P8do6SmYK6hxeeemwIC3YITDv
	 x5eKmK7rgxoc2y+s+3u+blW+01YujItSe805zE16Fyo+HVEU4UwDIZi05V91wohw3+
	 bMpESFqBM1A0O+L/6Q7biGg9yj98kENwPVrWhfKQ=
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: Build Break?
From: "Alexander V. Chernikov" 
In-Reply-To: 
Date: Sun, 2 Oct 2022 14:12:29 +0100
Cc: Freebsd current 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F2A1941-C042-47FF-969C-3D993D56D088@ipfw.ru>
References: 
To: Larry Rosenman 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4MgPX33CV8z3rvk
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=ipfw.ru header.s=mail header.b=MgSmtRFT;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 5.45.198.250 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru
X-Spamd-Result: default: False [-2.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:5.45.198.0/23];
	R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail];
	RCVD_IN_DNSWL_LOW(-0.10)[5.45.198.250:from];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	DMARC_NA(0.00)[ipfw.ru];
	FREEFALL_USER(0.00)[melifaro];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[ipfw.ru:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:13238, ipnet:5.45.192.0/18, country:RU];
	RWL_MAILSPIKE_POSSIBLE(0.00)[5.45.198.250:from]
X-ThisMailContainsUnwantedMimeParts: N



> On 1 Oct 2022, at 22:57, Larry Rosenman  wrote:
>=20
> --- all_subdir_nfscommon ---
> Building =
/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/n=
fscommon/nfs_commonkrpc.o
> --- all_subdir_netgraph ---
> --- all_subdir_netgraph/deflate ---
> Building =
/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/n=
etgraph/deflate/offset.inc
> --- all_subdir_netgraph/device ---
> Building =
/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/n=
etgraph/device/i386
> --- all_subdir_netgraph/echo ---
> =3D=3D=3D> netgraph/echo (all)
> --- all_subdir_netlink ---
> --- netlink_io.o ---
> /usr/src/sys/netlink/netlink_io.c:146:2: error: implicit declaration =
of function 'mtx_lock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        NLP_LOCK(nlp);
That=E2=80=99s interesting. netlink_io.c includes sys/mutex.h which =
defines mutex_lock() / mutex_unlock().
 Could you share the diff between GENERIC and LER-MINIMAL?

>        ^
> /usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro =
'NLP_LOCK'
> #define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:159:2: error: implicit declaration =
of function 'mtx_unlock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        NLP_UNLOCK(nlp);
>        ^
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro =
'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:159:2: note: did you mean =
'mtx_lock'?
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro =
'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:146:2: note: 'mtx_lock' declared =
here
>        NLP_LOCK(nlp);
>        ^
> /usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro =
'NLP_LOCK'
> #define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:177:2: error: implicit declaration =
of function 'mtx_lock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        SOCKBUF_LOCK(sb);
>        ^
> /usr/src/sys/sys/sockbuf.h:187:28: note: expanded from macro =
'SOCKBUF_LOCK'
> #define SOCKBUF_LOCK(_sb)               mtx_lock(SOCKBUF_MTX(_sb))
>                                        ^
> /usr/src/sys/netlink/netlink_io.c:189:2: error: implicit declaration =
of function 'mtx_unlock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        SOCKBUF_UNLOCK(sb);
>        ^
> /usr/src/sys/sys/sockbuf.h:189:30: note: expanded from macro =
'SOCKBUF_UNLOCK'
> #define SOCKBUF_UNLOCK(_sb)             mtx_unlock(SOCKBUF_MTX(_sb))
>                                        ^
> /usr/src/sys/netlink/netlink_io.c:202:2: error: implicit declaration =
of function 'mtx_lock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        NLP_LOCK(nlp);
>        ^
> /usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro =
'NLP_LOCK'
> #define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:207:3: error: implicit declaration =
of function 'mtx_unlock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>                NLP_UNLOCK(nlp);
>                ^
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro =
'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:225:3: error: implicit declaration =
of function 'mtx_unlock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>                SOCKBUF_UNLOCK(sb);
>                ^
> /usr/src/sys/sys/sockbuf.h:189:30: note: expanded from macro =
'SOCKBUF_UNLOCK'
> #define SOCKBUF_UNLOCK(_sb)             mtx_unlock(SOCKBUF_MTX(_sb))
>                                        ^
> /usr/src/sys/netlink/netlink_io.c:232:2: error: implicit declaration =
of function 'mtx_unlock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        NLP_UNLOCK(nlp);
>        ^
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro =
'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:281:2: error: implicit declaration =
of function 'mtx_lock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        NLP_LOCK(nlp);
>        ^
> /usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro =
'NLP_LOCK'
> #define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:299:2: error: implicit declaration =
of function 'mtx_unlock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        NLP_UNLOCK(nlp);
>        ^
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro =
'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:354:2: error: implicit declaration =
of function 'mtx_lock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        NLP_LOCK(nlp);
>        ^
> /usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro =
'NLP_LOCK'
> #define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:357:3: error: implicit declaration =
of function 'mtx_unlock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>                NLP_UNLOCK(nlp);
>                ^
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro =
'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:369:3: error: implicit declaration =
of function 'mtx_unlock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>                NLP_UNLOCK(nlp);
>                ^
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro =
'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:395:2: error: implicit declaration =
of function 'mtx_unlock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>        NLP_UNLOCK(nlp);
>        ^
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro =
'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:519:3: error: implicit declaration =
of function 'mtx_lock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>                NLP_LOCK(nlp);
>                ^
> /usr/src/sys/netlink/netlink_var.h:79:25: note: expanded from macro =
'NLP_LOCK'
> #define NLP_LOCK(_nlp)          mtx_lock(&((_nlp)->nl_lock))
>                                ^
> /usr/src/sys/netlink/netlink_io.c:521:3: error: implicit declaration =
of function 'mtx_unlock' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
>                NLP_UNLOCK(nlp);
>                ^
> /usr/src/sys/netlink/netlink_var.h:80:26: note: expanded from macro =
'NLP_UNLOCK'
> #define NLP_UNLOCK(_nlp)        mtx_unlock(&((_nlp)->nl_lock))
>                                ^
> 16 errors generated.
> --- all_subdir_netgraph ---
> --- all_subdir_netgraph/device ---
> --- i386 ---
> i386 -> /usr/src/sys/i386/include
> Building =
/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/n=
etgraph/device/vnode_if_newproto.h
> --- all_subdir_netlink ---
> *** [netlink_io.o] Error code 1
>=20
> make[4]: stopped in /usr/src/sys/modules/netlink
> .ERROR_TARGET=3D'netlink_io.o'
> =
.ERROR_META_FILE=3D'/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/u=
sr/src/sys/modules/netlink/netlink_io.o.meta'
> .MAKE.LEVEL=3D'4'
> MAKEFILE=3D''
> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes=
 verbose'
>        5.79 real        30.04 user         9.35 sys
>=20
> make[1]: stopped in /usr/src
>=20
> make: stopped in /usr/src
>=20
> ler in =F0=9F=8C=90 borg in src=F0=9F=94=92 on =EE=82=A0 =
ler/freebsd-main-changes:main [=E2=87=A1] on =E2=98=81=EF=B8=8F  =
(us-east-1) took 1m56s
> =E2=9D=AF
>=20
> ler in =F0=9F=8C=90 borg in src=F0=9F=94=92 on =EE=82=A0 =
ler/freebsd-main-changes:main [=E2=87=A1] on =E2=98=81=EF=B8=8F  =
(us-east-1)
> =E2=9D=AF
>=20
>=20
>=20
> --=20
> Larry Rosenman                     http://www.lerctr.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>=20


From nobody Sun Oct  2 15:48:34 2022
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 4MgT084RmNz4dhJZ
	for ; Sun,  2 Oct 2022 15:48:40 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MgT074HS5z42Qb
	for ; Sun,  2 Oct 2022 15:48:39 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=R0DJ/pWRuMPmJzDG0PGEYxOSjldLW5s47SqA2K/y1jw=; b=zaKr69PTMNi2k1epDJh+yZWm9o
	/oJ1rIyaBX1BjvC1GXfMwt3xlFXNu9v3hOKdh0HgmdrGYMIEp/L8qekaRHHSFM2lnhgq2Lna0SaiK
	ElboMGHzEui2XX6guK+NiTGJcWe3To9dgFMvri1ao+NOkngYx1YBlPtSavYJZvEv+8NNDSuSrH6Xe
	oKybGvLxU9PJiCyOEX52ZFoJvbkOV0Xk+LIDh0+6JYwNkvNMzvxg2Dkyjbmnu8noDrKoeRPRYimJd
	8W/bFJPWNG92rkkhG2mF0B09fQMQ0Bas85slAue4Fl1jJMnOoBO2MFdeftiyu+OPrSrliraC/Vwob
	AYBKr3Sw==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:14857 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1of1Ck-000EnM-9f;
	Sun, 02 Oct 2022 10:48:34 -0500
Received: from 2600:1700:210:b18f:8cb4:f417:c3e6:a42
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sun, 02 Oct 2022 10:48:34 -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
Date: Sun, 02 Oct 2022 10:48:34 -0500
From: Larry Rosenman 
To: "Alexander V. Chernikov" 
Cc: Freebsd current 
Subject: Re: Build Break?
In-Reply-To: <7F2A1941-C042-47FF-969C-3D993D56D088@ipfw.ru>
References: 
 <7F2A1941-C042-47FF-969C-3D993D56D088@ipfw.ru>
Message-ID: <86d49c96fbe0bd3776d8e21580c85676@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: multipart/mixed;
 boundary="=_638bd1f3e6e435733e159e41a9eb8dc7"
X-Rspamd-Queue-Id: 4MgT074HS5z42Qb
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=zaKr69PT;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-1.90 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-diff];
	MIME_BASE64_TEXT(0.10)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEFALL_USER(0.00)[ler];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	HAS_ATTACHMENT(0.00)[];
	ASN(0.00)[asn:55103, ipnet:192.147.25.0/24, country:US];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]
X-ThisMailContainsUnwantedMimeParts: N

--=_638bd1f3e6e435733e159e41a9eb8dc7
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed

On 10/02/2022 8:12 am, Alexander V. Chernikov wrote:
>> On 1 Oct 2022, at 22:57, Larry Rosenman  wrote:
>> 
>> --- all_subdir_nfscommon ---
>> Building 
>> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/nfscommon/nfs_commonkrpc.o
>> --- all_subdir_netgraph ---
>> --- all_subdir_netgraph/deflate ---
>> Building 
>> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/deflate/offset.inc
>> --- all_subdir_netgraph/device ---
>> Building 
>> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/device/i386
>> --- all_subdir_netgraph/echo ---
>> ===> netgraph/echo (all)
>> --- all_subdir_netlink ---
>> --- netlink_io.o ---
>> /usr/src/sys/netlink/netlink_io.c:146:2: error: implicit declaration 
>> of function 'mtx_lock' is invalid in C99 
>> [-Werror,-Wimplicit-function-declaration]
>>        NLP_LOCK(nlp);
> That’s interesting. netlink_io.c includes sys/mutex.h which defines 
> mutex_lock() / mutex_unlock().
>  Could you share the diff between GENERIC and LER-MINIMAL?
> 
attached.

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

--=_638bd1f3e6e435733e159e41a9eb8dc7
Content-Transfer-Encoding: base64
Content-Type: text/x-diff;
 name=kernel.diff
Content-Disposition: attachment;
 filename=kernel.diff;
 size=17238

LS0tIEdFTkVSSUMJMjAyMi0wOC0xOCAxNDo0NDozNS41NzY4NDQwMDAgLTA1MDAKKysrIExFUi1N
SU5JTUFMCTIwMjItMTAtMDIgMTA6NDY6NDEuMzA4OTI2MDAwIC0wNTAwCkBAIC0xLDQwMSArMSwz
MiBAQAotIwotIyBHRU5FUklDIC0tIEdlbmVyaWMga2VybmVsIGNvbmZpZ3VyYXRpb24gZmlsZSBm
b3IgRnJlZUJTRC9hbWQ2NAotIwotIyBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzIGZpbGUs
IHBsZWFzZSByZWFkIHRoZSBjb25maWcoNSkgbWFudWFsIHBhZ2UsCi0jIGFuZC9vciB0aGUgaGFu
ZGJvb2sgc2VjdGlvbiBvbiBLZXJuZWwgQ29uZmlndXJhdGlvbiBGaWxlczoKLSMKLSMgICAgaHR0
cHM6Ly9kb2NzLmZyZWVic2Qub3JnL2VuL2Jvb2tzL2hhbmRib29rL2tlcm5lbGNvbmZpZy8ja2Vy
bmVsY29uZmlnLWNvbmZpZwotIwotIyBUaGUgaGFuZGJvb2sgaXMgYWxzbyBhdmFpbGFibGUgbG9j
YWxseSBpbiAvdXNyL3NoYXJlL2RvYy9oYW5kYm9vawotIyBpZiB5b3UndmUgaW5zdGFsbGVkIHRo
ZSBkb2MgZGlzdHJpYnV0aW9uLCBvdGhlcndpc2UgYWx3YXlzIHNlZSB0aGUKLSMgRnJlZUJTRCBX
b3JsZCBXaWRlIFdlYiBzZXJ2ZXIgKGh0dHBzOi8vd3d3LkZyZWVCU0Qub3JnLykgZm9yIHRoZQot
IyBsYXRlc3QgaW5mb3JtYXRpb24uCi0jCi0jIEFuIGV4aGF1c3RpdmUgbGlzdCBvZiBvcHRpb25z
IGFuZCBtb3JlIGRldGFpbGVkIGV4cGxhbmF0aW9ucyBvZiB0aGUKLSMgZGV2aWNlIGxpbmVzIGlz
IGFsc28gcHJlc2VudCBpbiB0aGUgLi4vLi4vY29uZi9OT1RFUyBhbmQgTk9URVMgZmlsZXMuCi0j
IElmIHlvdSBhcmUgaW4gZG91YnQgYXMgdG8gdGhlIHB1cnBvc2Ugb3IgbmVjZXNzaXR5IG9mIGEg
bGluZSwgY2hlY2sgZmlyc3QKLSMgaW4gTk9URVMuCi0jCi0jICRGcmVlQlNEJAorIyBMRVItTUlO
SU1BTCAgLS0ga2VybmVsIGNvbmZpZyBiYXNlZCBvbiBNSU5JTUFMCiAKLWNwdQkJSEFNTUVSCi1p
ZGVudAkJR0VORVJJQworaW5jbHVkZQkJTUlOSU1BTAoraWRlbnQJCUxFUi1NSU5JTUFMCiAKLW1h
a2VvcHRpb25zCURFQlVHPS1nCQkjIEJ1aWxkIGtlcm5lbCB3aXRoIGdkYigxKSBkZWJ1ZyBzeW1i
b2xzCi1tYWtlb3B0aW9ucwlXSVRIX0NURj0xCQkjIFJ1biBjdGZjb252ZXJ0KDEpIGZvciBEVHJh
Y2Ugc3VwcG9ydAotCi1vcHRpb25zIAlTQ0hFRF9VTEUJCSMgVUxFIHNjaGVkdWxlcgotb3B0aW9u
cyAJTlVNQQkJCSMgTm9uLVVuaWZvcm0gTWVtb3J5IEFyY2hpdGVjdHVyZSBzdXBwb3J0Ci1vcHRp
b25zIAlQUkVFTVBUSU9OCQkjIEVuYWJsZSBrZXJuZWwgdGhyZWFkIHByZWVtcHRpb24KLW9wdGlv
bnMgCVZJTUFHRQkJCSMgU3Vic3lzdGVtIHZpcnR1YWxpemF0aW9uLCBlLmcuIFZORVQKLW9wdGlv
bnMgCUlORVQJCQkjIEludGVyTkVUd29ya2luZwotb3B0aW9ucyAJSU5FVDYJCQkjIElQdjYgY29t
bXVuaWNhdGlvbnMgcHJvdG9jb2xzCi1vcHRpb25zIAlJUFNFQ19TVVBQT1JUCQkjIEFsbG93IGts
ZGxvYWQgb2YgaXBzZWMgYW5kIHRjcG1kNQotb3B0aW9ucwkJUk9VVEVfTVBBVEgJCSMgTXVsdGlw
YXRoIHJvdXRpbmcgc3VwcG9ydAotb3B0aW9ucwkJRklCX0FMR08JCSMgTW9kdWxhciBmaWIgbG9v
a3Vwcwotb3B0aW9ucyAJVENQX09GRkxPQUQJCSMgVENQIG9mZmxvYWQKLW9wdGlvbnMgCVRDUF9C
TEFDS0JPWAkJIyBFbmhhbmNlZCBUQ1AgZXZlbnQgbG9nZ2luZwotb3B0aW9ucyAJVENQX0hIT09L
CQkjIGhob29rKDkpIGZyYW1ld29yayBmb3IgVENQCi1vcHRpb25zCQlUQ1BfUkZDNzQxMwkJIyBU
Q1AgRmFzdCBPcGVuCi1vcHRpb25zIAlTQ1RQX1NVUFBPUlQJCSMgQWxsb3cga2xkbG9hZCBvZiBT
Q1RQCi1vcHRpb25zCQlLRVJOX1RMUwkJIyBUTFMgdHJhbnNtaXQgJiByZWNlaXZlIG9mZmxvYWQK
LW9wdGlvbnMgCUZGUwkJCSMgQmVya2VsZXkgRmFzdCBGaWxlc3lzdGVtCi1vcHRpb25zIAlTT0ZU
VVBEQVRFUwkJIyBFbmFibGUgRkZTIHNvZnQgdXBkYXRlcyBzdXBwb3J0Ci1vcHRpb25zIAlVRlNf
QUNMCQkJIyBTdXBwb3J0IGZvciBhY2Nlc3MgY29udHJvbCBsaXN0cwotb3B0aW9ucyAJVUZTX0RJ
UkhBU0gJCSMgSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcgZGlyZWN0b3JpZXMKLW9wdGlvbnMg
CVVGU19HSk9VUk5BTAkJIyBFbmFibGUgZ2pvdXJuYWwtYmFzZWQgVUZTIGpvdXJuYWxpbmcKLW9w
dGlvbnMgCVFVT1RBCQkJIyBFbmFibGUgZGlzayBxdW90YXMgZm9yIFVGUwotb3B0aW9ucyAJTURf
Uk9PVAkJCSMgTUQgaXMgYSBwb3RlbnRpYWwgcm9vdCBkZXZpY2UKLW9wdGlvbnMgCU5GU0NMCQkJ
IyBOZXR3b3JrIEZpbGVzeXN0ZW0gQ2xpZW50Ci1vcHRpb25zIAlORlNECQkJIyBOZXR3b3JrIEZp
bGVzeXN0ZW0gU2VydmVyCi1vcHRpb25zIAlORlNMT0NLRAkJIyBOZXR3b3JrIExvY2sgTWFuYWdl
cgotb3B0aW9ucyAJTkZTX1JPT1QJCSMgTkZTIHVzYWJsZSBhcyAvLCByZXF1aXJlcyBORlNDTAot
b3B0aW9ucyAJTVNET1NGUwkJCSMgTVNET1MgRmlsZXN5c3RlbQotb3B0aW9ucyAJQ0Q5NjYwCQkJ
IyBJU08gOTY2MCBGaWxlc3lzdGVtCi1vcHRpb25zIAlQUk9DRlMJCQkjIFByb2Nlc3MgZmlsZXN5
c3RlbSAocmVxdWlyZXMgUFNFVURPRlMpCi1vcHRpb25zIAlQU0VVRE9GUwkJIyBQc2V1ZG8tZmls
ZXN5c3RlbSBmcmFtZXdvcmsKLW9wdGlvbnMgCVRNUEZTCQkJIyBFZmZpY2llbnQgbWVtb3J5IGZp
bGVzeXN0ZW0KLW9wdGlvbnMgCUdFT01fUkFJRAkJIyBTb2Z0IFJBSUQgZnVuY3Rpb25hbGl0eS4K
LW9wdGlvbnMgCUdFT01fTEFCRUwJCSMgUHJvdmlkZXMgbGFiZWxpemF0aW9uCi1vcHRpb25zIAlF
RklSVAkJCSMgRUZJIFJ1bnRpbWUgU2VydmljZXMgc3VwcG9ydAotb3B0aW9ucyAJQ09NUEFUX0ZS
RUVCU0QzMgkjIENvbXBhdGlibGUgd2l0aCBpMzg2IGJpbmFyaWVzCi1vcHRpb25zIAlDT01QQVRf
RlJFRUJTRDQJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q0Ci1vcHRpb25zIAlDT01QQVRfRlJF
RUJTRDUJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q1Ci1vcHRpb25zIAlDT01QQVRfRlJFRUJT
RDYJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q2Ci1vcHRpb25zIAlDT01QQVRfRlJFRUJTRDcJ
CSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q3Ci1vcHRpb25zIAlDT01QQVRfRlJFRUJTRDkJCSMg
Q29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q5Ci1vcHRpb25zIAlDT01QQVRfRlJFRUJTRDEwCSMgQ29t
cGF0aWJsZSB3aXRoIEZyZWVCU0QxMAotb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0QxMQkjIENvbXBh
dGlibGUgd2l0aCBGcmVlQlNEMTEKLW9wdGlvbnMgCUNPTVBBVF9GUkVFQlNEMTIJIyBDb21wYXRp
YmxlIHdpdGggRnJlZUJTRDEyCi1vcHRpb25zIAlDT01QQVRfRlJFRUJTRDEzCSMgQ29tcGF0aWJs
ZSB3aXRoIEZyZWVCU0QxMwotb3B0aW9ucyAJU0NTSV9ERUxBWT01MDAwCQkjIERlbGF5IChpbiBt
cykgYmVmb3JlIHByb2JpbmcgU0NTSQotb3B0aW9ucyAJS1RSQUNFCQkJIyBrdHJhY2UoMSkgc3Vw
cG9ydAotb3B0aW9ucyAJU1RBQ0sJCQkjIHN0YWNrKDkpIHN1cHBvcnQKLW9wdGlvbnMgCVNZU1ZT
SE0JCQkjIFNZU1Ytc3R5bGUgc2hhcmVkIG1lbW9yeQotb3B0aW9ucyAJU1lTVk1TRwkJCSMgU1lT
Vi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwotb3B0aW9ucyAJU1lTVlNFTQkJCSMgU1lTVi1zdHlsZSBz
ZW1hcGhvcmVzCi1vcHRpb25zIAlfS1BPU0lYX1BSSU9SSVRZX1NDSEVEVUxJTkcgIyBQT1NJWCBQ
MTAwM18xQiByZWFsLXRpbWUgZXh0ZW5zaW9ucwotb3B0aW9ucyAJUFJJTlRGX0JVRlJfU0laRT0x
MjgJIyBQcmV2ZW50IHByaW50ZiBvdXRwdXQgYmVpbmcgaW50ZXJzcGVyc2VkLgotb3B0aW9ucyAJ
S0JEX0lOU1RBTExfQ0RFVgkjIGluc3RhbGwgYSBDREVWIGVudHJ5IGluIC9kZXYKLW9wdGlvbnMg
CUhXUE1DX0hPT0tTCQkjIE5lY2Vzc2FyeSBrZXJuZWwgaG9va3MgZm9yIGh3cG1jKDQpCi1vcHRp
b25zIAlBVURJVAkJCSMgU2VjdXJpdHkgZXZlbnQgYXVkaXRpbmcKLW9wdGlvbnMgCUNBUEFCSUxJ
VFlfTU9ERQkJIyBDYXBzaWN1bSBjYXBhYmlsaXR5IG1vZGUKLW9wdGlvbnMgCUNBUEFCSUxJVElF
UwkJIyBDYXBzaWN1bSBjYXBhYmlsaXRpZXMKLW9wdGlvbnMgCU1BQwkJCSMgVHJ1c3RlZEJTRCBN
QUMgRnJhbWV3b3JrCi1vcHRpb25zIAlLRFRSQUNFX0ZSQU1FCQkjIEVuc3VyZSBmcmFtZXMgYXJl
IGNvbXBpbGVkIGluCi1vcHRpb25zIAlLRFRSQUNFX0hPT0tTCQkjIEtlcm5lbCBEVHJhY2UgaG9v
a3MKLW9wdGlvbnMgCUREQl9DVEYJCQkjIEtlcm5lbCBFTEYgbGlua2VyIGxvYWRzIENURiBkYXRh
Ci1vcHRpb25zIAlJTkNMVURFX0NPTkZJR19GSUxFCSMgSW5jbHVkZSB0aGlzIGZpbGUgaW4ga2Vy
bmVsCi1vcHRpb25zIAlSQUNDVAkJCSMgUmVzb3VyY2UgYWNjb3VudGluZyBmcmFtZXdvcmsKLW9w
dGlvbnMgCVJBQ0NUX0RFRkFVTFRfVE9fRElTQUJMRUQgIyBTZXQga2Vybi5yYWNjdC5lbmFibGU9
MCBieSBkZWZhdWx0Ci1vcHRpb25zIAlSQ1RMCQkJIyBSZXNvdXJjZSBsaW1pdHMKLQotIyBEZWJ1
Z2dpbmcgc3VwcG9ydC4gIEFsd2F5cyBuZWVkIHRoaXM6Ci1vcHRpb25zIAlLREIJCQkjIEVuYWJs
ZSBrZXJuZWwgZGVidWdnZXIgc3VwcG9ydC4KLW9wdGlvbnMgCUtEQl9UUkFDRQkJIyBQcmludCBh
IHN0YWNrIHRyYWNlIGZvciBhIHBhbmljLgotIyBGb3IgZnVsbCBkZWJ1Z2dlciBzdXBwb3J0IHVz
ZSAodHVybiBvZmYgaW4gc3RhYmxlIGJyYW5jaCk6Ci1vcHRpb25zIAlCVUZfVFJBQ0tJTkcJCSMg
VHJhY2sgYnVmZmVyIGhpc3RvcnkKLW9wdGlvbnMgCUREQgkJCSMgU3VwcG9ydCBEREIuCi1vcHRp
b25zIAlGVUxMX0JVRl9UUkFDS0lORwkjIFRyYWNrIG1vcmUgYnVmZmVyIGhpc3RvcnkKLW9wdGlv
bnMgCUdEQgkJCSMgU3VwcG9ydCByZW1vdGUgR0RCLgotb3B0aW9ucyAJREVBRExLUkVTCQkjIEVu
YWJsZSB0aGUgZGVhZGxvY2sgcmVzb2x2ZXIKLW9wdGlvbnMgCUlOVkFSSUFOVFMJCSMgRW5hYmxl
IGNhbGxzIG9mIGV4dHJhIHNhbml0eSBjaGVja2luZwotb3B0aW9ucyAJSU5WQVJJQU5UX1NVUFBP
UlQJIyBFeHRyYSBzYW5pdHkgY2hlY2tzIG9mIGludGVybmFsIHN0cnVjdHVyZXMsIHJlcXVpcmVk
IGJ5IElOVkFSSUFOVFMKLW9wdGlvbnMgCVFVRVVFX01BQ1JPX0RFQlVHX1RSQVNICSMgVHJhc2gg
cXVldWUoMikgaW50ZXJuYWwgcG9pbnRlcnMgb24gaW52YWxpZGF0aW9uCi1vcHRpb25zIAlXSVRO
RVNTCQkJIyBFbmFibGUgY2hlY2tzIHRvIGRldGVjdCBkZWFkbG9ja3MgYW5kIGN5Y2xlcwotb3B0
aW9ucyAJV0lUTkVTU19TS0lQU1BJTgkjIERvbid0IHJ1biB3aXRuZXNzIG9uIHNwaW5sb2NrcyBm
b3Igc3BlZWQKLW9wdGlvbnMgCU1BTExPQ19ERUJVR19NQVhaT05FUz04CSMgU2VwYXJhdGUgbWFs
bG9jKDkpIHpvbmVzCi1vcHRpb25zIAlWRVJCT1NFX1NZU0lOSVQ9MAkjIFN1cHBvcnQgZGVidWcu
dmVyYm9zZV9zeXNpbml0LCBvZmYgYnkgZGVmYXVsdAotCi0jIEtlcm5lbCBTYW5pdGl6ZXJzCi0j
b3B0aW9ucyAJQ09WRVJBR0UJCSMgR2VuZXJpYyBrZXJuZWwgY292ZXJhZ2UuIFVzZWQgYnkgS0NP
VgotI29wdGlvbnMgCUtDT1YJCQkjIEtlcm5lbCBDb3ZlcmFnZSBTYW5pdGl6ZXIKLSMgV2Fybmlu
ZzogS1VCU0FOIGNhbiByZXN1bHQgaW4gYSBrZXJuZWwgdG9vIGxhcmdlIGZvciBsb2FkZXIgdG8g
bG9hZAotI29wdGlvbnMgCUtVQlNBTgkJCSMgS2VybmVsIFVuZGVmaW5lZCBCZWhhdmlvciBTYW5p
dGl6ZXIKLSNvcHRpb25zIAlLQ1NBTgkJCSMgS2VybmVsIENvbmN1cnJlbmN5IFNhbml0aXplcgot
Citub29wdGlvbnMgCVdJVE5FU1MJCQkjIEVuYWJsZSBjaGVja3MgdG8gZGV0ZWN0IGRlYWRsb2Nr
cyBhbmQgY3ljbGVzCitub29wdGlvbnMgCVdJVE5FU1NfU0tJUFNQSU4JIyBEb24ndCBydW4gd2l0
bmVzcyBvbiBzcGlubG9ja3MgZm9yIHNwZWVkCitvcHRpb25zCQlLREJfVU5BVFRFTkRFRAorI29w
dGlvbnMJCURFQlVHX01FTUdVQVJECisjb3B0aW9ucwkJREVCVUdfUkVEWk9ORQorbWFrZW9wdGlv
bnMgCVdJVEhfRVhUUkFfVENQX1NUQUNLUz0xCitvcHRpb25zIAlUQ1BIUFRTCitkZXZpY2UJCW1m
aQorb3B0aW9ucwkJVENQX1JGQzc0MTMKICMgS2VybmVsIGR1bXAgZmVhdHVyZXMuCi1vcHRpb25z
IAlFS0NECQkJIyBTdXBwb3J0IGZvciBlbmNyeXB0ZWQga2VybmVsIGR1bXBzCi1vcHRpb25zIAlH
WklPCQkJIyBnemlwLWNvbXByZXNzZWQga2VybmVsIGFuZCB1c2VyIGR1bXBzCi1vcHRpb25zIAla
U1RESU8JCQkjIHpzdGQtY29tcHJlc3NlZCBrZXJuZWwgYW5kIHVzZXIgZHVtcHMKLW9wdGlvbnMg
CURFQlVHTkVUCQkjIGRlYnVnbmV0IG5ldHdvcmtpbmcKLW9wdGlvbnMgCU5FVERVTVAJCQkjIG5l
dGR1bXAoNCkgY2xpZW50IHN1cHBvcnQKLW9wdGlvbnMgCU5FVEdEQgkJCSMgbmV0Z2RiKDQpIGNs
aWVudCBzdXBwb3J0CitvcHRpb25zICAgICAgICAgRUtDRCAgICAgICAgICAgICAgICAgICAgIyBT
dXBwb3J0IGZvciBlbmNyeXB0ZWQga2VybmVsIGR1bXBzCitvcHRpb25zICAgICAgICAgR1pJTyAg
ICAgICAgICAgICAgICAgICAgIyBnemlwLWNvbXByZXNzZWQga2VybmVsIGFuZCB1c2VyIGR1bXBz
CitvcHRpb25zICAgICAgICAgWlNURElPICAgICAgICAgICAgICAgICAgIyB6c3RkLWNvbXByZXNz
ZWQga2VybmVsIGFuZCB1c2VyIGR1bXBzCitvcHRpb25zICAgICAgICAgTkVURFVNUCAgICAgICAg
ICAgICAgICAgIyBuZXRkdW1wKDQpIGNsaWVudCBzdXBwb3J0CisjIGlwc2VjIHN1cHBvcnQKK29w
dGlvbnMJCUlQU0VDX1NVUFBPUlQKK2RldmljZQkJY3J5cHRvCiAKLSMgTWFrZSBhbiBTTVAtY2Fw
YWJsZSBrZXJuZWwgYnkgZGVmYXVsdAotb3B0aW9ucyAJU01QCQkJIyBTeW1tZXRyaWMgTXVsdGlQ
cm9jZXNzb3IgS2VybmVsCi1vcHRpb25zIAlFQVJMWV9BUF9TVEFSVFVQCisjbmV0Z3JhcGggZGVi
dWcKK29wdGlvbnMJCU5FVEdSQVBIX0RFQlVHCiAKLSMgQ1BVIGZyZXF1ZW5jeSBjb250cm9sCi1k
ZXZpY2UJCWNwdWZyZXEKKyN0Y3AgcmF0ZWxpbWl0CitvcHRpb25zCQlSQVRFTElNSVQKIAotIyBC
dXMgc3VwcG9ydC4KLWRldmljZQkJYWNwaQotZGV2aWNlCQlzbWJpb3MKLW9wdGlvbnMgCUlPTU1V
Ci1kZXZpY2UJCXBjaQotb3B0aW9ucyAJUENJX0hQCQkJIyBQQ0ktRXhwcmVzcyBuYXRpdmUgSG90
UGx1Zwotb3B0aW9ucwkJUENJX0lPVgkJCSMgUENJIFNSLUlPViBzdXBwb3J0Ci0KLW9wdGlvbnMg
CUNPTVBBVF9MSU5VWEtQSQotCi0jIEVuYWJsZSBzdXBwb3J0IGZvciB0aGUga2VybmVsIFBMTCB0
byB1c2UgYW4gZXh0ZXJuYWwgUFBTIHNpZ25hbCwKLSMgdW5kZXIgc3VwZXJ2aXNpb24gb2YgW3hd
bnRwZCg4KQotIyBNb3JlIGluZm8gaW4gbnRwZCBkb2N1bWVudGF0aW9uOiBodHRwOi8vd3d3LmVl
Y2lzLnVkZWwuZWR1L35udHAKLQotb3B0aW9ucyAJUFBTX1NZTkMKLQotIyBGbG9wcHkgZHJpdmVz
Ci1kZXZpY2UJCWZkYwotCi0jIEFUQSBjb250cm9sbGVycwotZGV2aWNlCQlhaGNpCQkJIyBBSENJ
LWNvbXBhdGlibGUgU0FUQSBjb250cm9sbGVycwotZGV2aWNlCQlhdGEJCQkjIExlZ2FjeSBBVEEv
U0FUQSBjb250cm9sbGVycwotZGV2aWNlCQltdnMJCQkjIE1hcnZlbGwgODhTWDUwWFgvODhTWDYw
WFgvODhTWDcwWFgvU29DIFNBVEEKLWRldmljZQkJc2lpcwkJCSMgU2lsaWNvbkltYWdlIFNpSTMx
MjQvU2lJMzEzMi9TaUkzNTMxIFNBVEEKLQotIyBTQ1NJIENvbnRyb2xsZXJzCi1kZXZpY2UJCWFo
YwkJCSMgQUhBMjk0MCBhbmQgb25ib2FyZCBBSUM3eHh4IGRldmljZXMKLWRldmljZQkJYWhkCQkJ
IyBBSEEzOTMyMC8yOTMyMCBhbmQgb25ib2FyZCBBSUM3OXh4IGRldmljZXMKLWRldmljZQkJaHB0
aW9wCQkJIyBIaWdocG9pbnQgUm9ja2V0UmFpZCAzeHh4IHNlcmllcwotZGV2aWNlCQlpc3AJCQkj
IFFsb2dpYyBmYW1pbHkKLSNkZXZpY2UJCWlzcGZ3CQkJIyBGaXJtd2FyZSBmb3IgUUxvZ2ljIEhC
QXMtIG5vcm1hbGx5IGEgbW9kdWxlCi1kZXZpY2UJCW1wdAkJCSMgTFNJLUxvZ2ljIE1QVC1GdXNp
b24KLWRldmljZQkJbXBzCQkJIyBMU0ktTG9naWMgTVBULUZ1c2lvbiAyCi1kZXZpY2UJCW1wcgkJ
CSMgTFNJLUxvZ2ljIE1QVC1GdXNpb24gMwotZGV2aWNlCQlzeW0JCQkjIE5DUi9TeW1iaW9zIExv
Z2ljCi1kZXZpY2UJCWlzY2kJCQkjIEludGVsIEM2MDAgU0FTIGNvbnRyb2xsZXIKLWRldmljZQkJ
b2NzX2ZjCQkJIyBFbXVsZXggRkMgYWRhcHRlcnMKLWRldmljZQkJcHZzY3NpCQkJIyBWTXdhcmUg
UFZTQ1NJCi0KLSMgQVRBL1NDU0kgcGVyaXBoZXJhbHMKLWRldmljZQkJc2NidXMJCQkjIFNDU0kg
YnVzIChyZXF1aXJlZCBmb3IgQVRBL1NDU0kpCi1kZXZpY2UJCWNoCQkJIyBTQ1NJIG1lZGlhIGNo
YW5nZXJzCi1kZXZpY2UJCWRhCQkJIyBEaXJlY3QgQWNjZXNzIChkaXNrcykKLWRldmljZQkJc2EJ
CQkjIFNlcXVlbnRpYWwgQWNjZXNzICh0YXBlIGV0YykKLWRldmljZQkJY2QJCQkjIENECi1kZXZp
Y2UJCXBhc3MJCQkjIFBhc3N0aHJvdWdoIGRldmljZSAoZGlyZWN0IEFUQS9TQ1NJIGFjY2VzcykK
LWRldmljZQkJc2VzCQkJIyBFbmNsb3N1cmUgU2VydmljZXMgKFNFUyBhbmQgU0FGLVRFKQotI2Rl
dmljZQkJY3RsCQkJIyBDQU0gVGFyZ2V0IExheWVyCi0KLSMgUkFJRCBjb250cm9sbGVycyBpbnRl
cmZhY2VkIHRvIHRoZSBTQ1NJIHN1YnN5c3RlbQotZGV2aWNlCQlhcmNtc3IJCQkjIEFyZWNhIFNB
VEEgSUkgUkFJRAotZGV2aWNlCQljaXNzCQkJIyBDb21wYXEgU21hcnQgUkFJRCA1KgotZGV2aWNl
CQlpcHMJCQkjIElCTSAoQWRhcHRlYykgU2VydmVSQUlECi1kZXZpY2UJCXNtYXJ0cHFpCQkjIE1p
Y3Jvc2VtaSBzbWFydHBxaSBkcml2ZXIKLWRldmljZQkJdHdzCQkJIyBMU0kgM3dhcmUgOTc1MCBT
QVRBK1NBUyA2R2IvcyBSQUlEIGNvbnRyb2xsZXIKLQotIyBSQUlEIGNvbnRyb2xsZXJzCi1kZXZp
Y2UJCWFhYwkJCSMgQWRhcHRlYyBGU0EgUkFJRAotZGV2aWNlCQlhYWNwCQkJIyBTQ1NJIHBhc3N0
aHJvdWdoIGZvciBhYWMgKHJlcXVpcmVzIENBTSkKLWRldmljZQkJYWFjcmFpZAkJCSMgQWRhcHRl
YyBieSBQTUMgUkFJRAotZGV2aWNlCQlpZGEJCQkjIENvbXBhcSBTbWFydCBSQUlECi1kZXZpY2UJ
CW1maQkJCSMgTFNJIE1lZ2FSQUlEIFNBUwotZGV2aWNlCQltbHgJCQkjIE15bGV4IERBQzk2MCBm
YW1pbHkKLWRldmljZQkJbXJzYXMJCQkjIExTSS9BdmFnbyBNZWdhUkFJRCBTQVMvU0FUQSwgNkdi
L3MgYW5kIDEyR2IvcwotZGV2aWNlCQlwbXNwY3YJCQkjIFBNQy1TaWVycmEgU0FTL1NBVEEgQ29u
dHJvbGxlciBkcml2ZXIKLSNYWFggcG9pbnRlci9pbnQgd2FybmluZ3MKLSNkZXZpY2UJCXBzdAkJ
CSMgUHJvbWlzZSBTdXBlcnRyYWsgU1g2MDAwCi1kZXZpY2UJCXR3ZQkJCSMgM3dhcmUgQVRBIFJB
SUQKLQotIyBOVk0gRXhwcmVzcyAoTlZNZSkgc3VwcG9ydAotZGV2aWNlCQludm1lCQkJIyBiYXNl
IE5WTWUgZHJpdmVyCi1kZXZpY2UJCW52ZAkJCSMgZXhwb3NlIE5WTWUgbmFtZXNwYWNlcyBhcyBk
aXNrcywgZGVwZW5kcyBvbiBudm1lCi0KLSMgSW50ZWwgVm9sdW1lIE1hbmFnZW1lbnQgRGV2aWNl
IChWTUQpIHN1cHBvcnQKLWRldmljZQkJdm1kCi0KLSMgYXRrYmRjMCBjb250cm9scyBib3RoIHRo
ZSBrZXlib2FyZCBhbmQgdGhlIFBTLzIgbW91c2UKLWRldmljZQkJYXRrYmRjCQkJIyBBVCBrZXli
b2FyZCBjb250cm9sbGVyCi1kZXZpY2UJCWF0a2JkCQkJIyBBVCBrZXlib2FyZAotZGV2aWNlCQlw
c20JCQkjIFBTLzIgbW91c2UKLQotZGV2aWNlCQlrYmRtdXgJCQkjIGtleWJvYXJkIG11bHRpcGxl
eGVyCi0KLSMgc3lzY29ucyBpcyB0aGUgbGVnYWN5IGNvbnNvbGUgZHJpdmVyLCByZXNlbWJsaW5n
IGFuIFNDTyBjb25zb2xlCi1kZXZpY2UJCXZnYQkJCSMgVkdBIHZpZGVvIGNhcmQgZHJpdmVyCi1k
ZXZpY2UJCXNwbGFzaAkJCSMgU3BsYXNoIHNjcmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1cHBvcnQK
LWRldmljZQkJc2MKLW9wdGlvbnMgCVNDX1BJWEVMX01PREUJCSMgYWRkIHN1cHBvcnQgZm9yIHRo
ZSByYXN0ZXIgdGV4dCBtb2RlCi0KLSMgdnQgaXMgdGhlIGRlZmF1bHQgdmlkZW8gY29uc29sZSBk
cml2ZXIKLWRldmljZQkJdnQKLWRldmljZQkJdnRfdmdhCi1kZXZpY2UJCXZ0X2VmaWZiCi1kZXZp
Y2UJCXZ0X3ZiZWZiCi0KLWRldmljZQkJYWdwCQkJIyBzdXBwb3J0IHNldmVyYWwgQUdQIGNoaXBz
ZXRzCi0KLSMgQ2FyZEJ1cyBicmlkZ2Ugc3VwcG9ydAotZGV2aWNlCQljYmIJCQkjIENhcmRCdXMg
KHllbnRhKSBicmlkZ2UKLWRldmljZQkJY2FyZGJ1cwkJCSMgQ2FyZEJ1cyAoMzItYml0KSBidXMK
LQotIyBTZXJpYWwgKENPTSkgcG9ydHMKLWRldmljZQkJdWFydAkJCSMgR2VuZXJpYyBVQVJUIGRy
aXZlcgotCi0jIFBhcmFsbGVsIHBvcnQKLWRldmljZQkJcHBjCi1kZXZpY2UJCXBwYnVzCQkJIyBQ
YXJhbGxlbCBwb3J0IGJ1cyAocmVxdWlyZWQpCi1kZXZpY2UJCWxwdAkJCSMgUHJpbnRlcgotZGV2
aWNlCQlwcGkJCQkjIFBhcmFsbGVsIHBvcnQgaW50ZXJmYWNlIGRldmljZQotI2RldmljZQkJdnBv
CQkJIyBSZXF1aXJlcyBzY2J1cyBhbmQgZGEKLQotZGV2aWNlCQlwdWMJCQkjIE11bHRpIEkvTyBj
YXJkcyBhbmQgbXVsdGktY2hhbm5lbCBVQVJUcwotCi0jIFBDSS9QQ0ktWC9QQ0llIEV0aGVybmV0
IE5JQ3MgdGhhdCB1c2UgaWZsaWIgaW5mcmFzdHJ1Y3R1cmUKLWRldmljZQkJaWZsaWIKLWRldmlj
ZQkJZW0JCQkjIEludGVsIFBSTy8xMDAwIEdpZ2FiaXQgRXRoZXJuZXQgRmFtaWx5Ci1kZXZpY2UJ
CWlnYwkJCSMgSW50ZWwgSTIyNSAyLjVHIEV0aGVybmV0Ci1kZXZpY2UJCWl4CQkJIyBJbnRlbCBQ
Uk8vMTBHYkUgUENJRSBQRiBFdGhlcm5ldAotZGV2aWNlCQlpeHYJCQkjIEludGVsIFBSTy8xMEdi
RSBQQ0lFIFZGIEV0aGVybmV0Ci1kZXZpY2UJCWl4bAkJCSMgSW50ZWwgNzAwIFNlcmllcyBQaHlz
aWNhbCBGdW5jdGlvbgotZGV2aWNlCQlpYXZmCQkJIyBJbnRlbCBBZGFwdGl2ZSBWaXJ0dWFsIEZ1
bmN0aW9uCi1kZXZpY2UJCWljZQkJCSMgSW50ZWwgODAwIFNlcmllcyBQaHlzaWNhbCBGdW5jdGlv
bgotZGV2aWNlCQl2bXgJCQkjIFZNd2FyZSBWTVhORVQzIEV0aGVybmV0Ci1kZXZpY2UJCWF4cAkJ
CSMgQU1EIEVQWUMgaW50ZWdyYXRlZCBOSUMgKHJlcXVpcmVzIG1paWJ1cykKLQotIyBQQ0kgRXRo
ZXJuZXQgTklDcy4KLWRldmljZQkJYnhlCQkJIyBCcm9hZGNvbSBOZXRYdHJlbWUgSUkgQkNNNTc3
MVgvQkNNNTc4WFggMTBHYkUKLWRldmljZQkJbGUJCQkjIEFNRCBBbTc5MDAgTEFOQ0UgYW5kIEFt
NzlDOXh4IFBDbmV0Ci1kZXZpY2UJCXRpCQkJIyBBbHRlb24gTmV0d29ya3MgVGlnb24gSS9JSSBn
aWdhYml0IEV0aGVybmV0Ci0KLSMgTnZpZGlhL01lbGxhbm94IENvbm5lY3QtWCA0IGFuZCBsYXRl
ciwgRXRoZXJuZXQgb25seQotIyAgbyByZXF1aXJlcyBDT01QQVRfTElOVVhLUEkgYW5kIHh6KDQp
Ci0jICBvIG1seDVpYiByZXF1aXJlcyBpYmNvcmUgaW5mcmEgYW5kIGlzIG5vdCBpbmNsdWRlZCBi
eSBkZWZhdWx0Ci1kZXZpY2UJCW1seDUJCQkjIEJhc2UgZHJpdmVyCi1kZXZpY2UJCW1seGZ3CQkJ
IyBGaXJtd2FyZSB1cGRhdGUKLWRldmljZQkJbWx4NWVuCQkJIyBFdGhlcm5ldCBkcml2ZXIKLQot
IyBQQ0kgRXRoZXJuZXQgTklDcyB0aGF0IHVzZSB0aGUgY29tbW9uIE1JSSBidXMgY29udHJvbGxl
ciBjb2RlLgotIyBOT1RFOiBCZSBzdXJlIHRvIGtlZXAgdGhlICdkZXZpY2UgbWlpYnVzJyBsaW5l
IGluIG9yZGVyIHRvIHVzZSB0aGVzZSBOSUNzIQotZGV2aWNlCQltaWlidXMJCQkjIE1JSSBidXMg
c3VwcG9ydAotZGV2aWNlCQlhZQkJCSMgQXR0YW5zaWMvQXRoZXJvcyBMMiBGYXN0RXRoZXJuZXQK
LWRldmljZQkJYWdlCQkJIyBBdHRhbnNpYy9BdGhlcm9zIEwxIEdpZ2FiaXQgRXRoZXJuZXQKLWRl
dmljZQkJYWxjCQkJIyBBdGhlcm9zIEFSODEzMS9BUjgxMzIgRXRoZXJuZXQKLWRldmljZQkJYWxl
CQkJIyBBdGhlcm9zIEFSODEyMS9BUjgxMTMvQVI4MTE0IEV0aGVybmV0Ci1kZXZpY2UJCWJjZQkJ
CSMgQnJvYWRjb20gQkNNNTcwNi9CQ001NzA4IEdpZ2FiaXQgRXRoZXJuZXQKLWRldmljZQkJYmZl
CQkJIyBCcm9hZGNvbSBCQ000NDB4IDEwLzEwMCBFdGhlcm5ldAotZGV2aWNlCQliZ2UJCQkjIEJy
b2FkY29tIEJDTTU3MHh4IEdpZ2FiaXQgRXRoZXJuZXQKLWRldmljZQkJY2FzCQkJIyBTdW4gQ2Fz
c2luaS9DYXNzaW5pKyBhbmQgTlMgRFA4MzA2NSBTYXR1cm4KLWRldmljZQkJZGMJCQkjIERFQy9J
bnRlbCAyMTE0MyBhbmQgdmFyaW91cyB3b3JrYWxpa2VzCi1kZXZpY2UJCWV0CQkJIyBBZ2VyZSBF
VDEzMTAgMTAvMTAwL0dpZ2FiaXQgRXRoZXJuZXQKLWRldmljZQkJZnhwCQkJIyBJbnRlbCBFdGhl
ckV4cHJlc3MgUFJPLzEwMEIgKDgyNTU3LCA4MjU1OCkKLWRldmljZQkJZ2VtCQkJIyBTdW4gR0VN
L1N1biBFUkkvQXBwbGUgR01BQwotZGV2aWNlCQlqbWUJCQkjIEpNaWNyb24gSk1DMjUwIEdpZ2Fi
aXQvSk1DMjYwIEZhc3QgRXRoZXJuZXQKLWRldmljZQkJbGdlCQkJIyBMZXZlbCAxIExYVDEwMDEg
Z2lnYWJpdCBFdGhlcm5ldAotZGV2aWNlCQltc2sJCQkjIE1hcnZlbGwvU3lzS29ubmVjdCBZdWtv
biBJSSBHaWdhYml0IEV0aGVybmV0Ci1kZXZpY2UJCW5mZQkJCSMgblZpZGlhIG5Gb3JjZSBNQ1Ag
b24tYm9hcmQgRXRoZXJuZXQKLWRldmljZQkJbmdlCQkJIyBOYXRTZW1pIERQODM4MjAgZ2lnYWJp
dCBFdGhlcm5ldAotZGV2aWNlCQlyZQkJCSMgUmVhbFRlayA4MTM5QysvODE2OS84MTY5Uy84MTEw
UwotZGV2aWNlCQlybAkJCSMgUmVhbFRlayA4MTI5LzgxMzkKLWRldmljZQkJc2dlCQkJIyBTaWxp
Y29uIEludGVncmF0ZWQgU3lzdGVtcyBTaVMxOTAvMTkxCi1kZXZpY2UJCXNpcwkJCSMgU2lsaWNv
biBJbnRlZ3JhdGVkIFN5c3RlbXMgU2lTIDkwMC9TaVMgNzAxNgotZGV2aWNlCQlzawkJCSMgU3lz
S29ubmVjdCBTSy05ODR4ICYgU0stOTgyeCBnaWdhYml0IEV0aGVybmV0Ci1kZXZpY2UJCXN0ZQkJ
CSMgU3VuZGFuY2UgU1QyMDEgKEQtTGluayBERkUtNTUwVFgpCi1kZXZpY2UJCXN0Z2UJCQkjIFN1
bmRhbmNlL1RhbWFyYWNrIFRDOTAyMSBnaWdhYml0IEV0aGVybmV0Ci1kZXZpY2UJCXZnZQkJCSMg
VklBIFZUNjEyeCBnaWdhYml0IEV0aGVybmV0Ci1kZXZpY2UJCXZyCQkJIyBWSUEgUmhpbmUsIFJo
aW5lIElJCi1kZXZpY2UJCXhsCQkJIyAzQ29tIDNjOTB4IChgYEJvb21lcmFuZycnLCBgYEN5Y2xv
bmUnJykKLQotIyBXaXJlbGVzcyBOSUMgY2FyZHMKLWRldmljZQkJd2xhbgkJCSMgODAyLjExIHN1
cHBvcnQKLW9wdGlvbnMgCUlFRUU4MDIxMV9ERUJVRwkJIyBlbmFibGUgZGVidWcgbXNncwotb3B0
aW9ucyAJSUVFRTgwMjExX1NVUFBPUlRfTUVTSAkjIGVuYWJsZSA4MDIuMTFzIGRyYWZ0IHN1cHBv
cnQKLWRldmljZQkJd2xhbl93ZXAJCSMgODAyLjExIFdFUCBzdXBwb3J0Ci1kZXZpY2UJCXdsYW5f
Y2NtcAkJIyA4MDIuMTEgQ0NNUCBzdXBwb3J0Ci1kZXZpY2UJCXdsYW5fdGtpcAkJIyA4MDIuMTEg
VEtJUCBzdXBwb3J0Ci1kZXZpY2UJCXdsYW5fYW1ycgkJIyBBTVJSIHRyYW5zbWl0IHJhdGUgY29u
dHJvbCBhbGdvcml0aG0KLWRldmljZQkJYXRoCQkJIyBBdGhlcm9zIE5JQ3MKLWRldmljZQkJYXRo
X3BjaQkJCSMgQXRoZXJvcyBwY2kvY2FyZGJ1cyBnbHVlCi1kZXZpY2UJCWF0aF9oYWwJCQkjIHBj
aS9jYXJkYnVzIGNoaXAgc3VwcG9ydAotb3B0aW9ucyAJQUhfQVI1NDE2X0lOVEVSUlVQVF9NSVRJ
R0FUSU9OICMgQVI1NDE2IGludGVycnVwdCBtaXRpZ2F0aW9uCi1vcHRpb25zIAlBVEhfRU5BQkxF
XzExTgkJIyBFbmFibGUgODAyLjExbiBzdXBwb3J0IGZvciBBUjU0MTYgYW5kIGxhdGVyCi1kZXZp
Y2UJCWF0aF9yYXRlX3NhbXBsZQkJIyBTYW1wbGVSYXRlIHR4IHJhdGUgY29udHJvbCBmb3IgYXRo
Ci0jZGV2aWNlCQlid2kJCQkjIEJyb2FkY29tIEJDTTQzMHgvQkNNNDMxeCB3aXJlbGVzcyBOSUNz
LgotI2RldmljZQkJYnduCQkJIyBCcm9hZGNvbSBCQ000M3h4IHdpcmVsZXNzIE5JQ3MuCi1kZXZp
Y2UJCWlwdwkJCSMgSW50ZWwgMjEwMCB3aXJlbGVzcyBOSUNzLgotZGV2aWNlCQlpd2kJCQkjIElu
dGVsIDIyMDBCRy8yMjI1QkcvMjkxNUFCRyB3aXJlbGVzcyBOSUNzLgotZGV2aWNlCQlpd24JCQkj
IEludGVsIDQ5NjUvMTAwMC81MDAwLzYwMDAgd2lyZWxlc3MgTklDcy4KLWRldmljZQkJbWFsbwkJ
CSMgTWFydmVsbCBMaWJlcnRhcyB3aXJlbGVzcyBOSUNzLgotZGV2aWNlCQltd2wJCQkjIE1hcnZl
bGwgODhXODM2MyA4MDIuMTFuIHdpcmVsZXNzIE5JQ3MuCi1kZXZpY2UJCXJhbAkJCSMgUmFsaW5r
IFRlY2hub2xvZ3kgUlQyNTAwIHdpcmVsZXNzIE5JQ3MuCi1kZXZpY2UJCXdwaQkJCSMgSW50ZWwg
Mzk0NUFCRyB3aXJlbGVzcyBOSUNzLgotCi0jIFBzZXVkbyBkZXZpY2VzLgotZGV2aWNlCQljcnlw
dG8JCQkjIGNvcmUgY3J5cHRvIHN1cHBvcnQKLWRldmljZQkJYWVzbmkJCQkjIEFFUy1OSSBPcGVu
Q3J5cHRvIG1vZHVsZQotZGV2aWNlCQlsb29wCQkJIyBOZXR3b3JrIGxvb3BiYWNrCi1kZXZpY2UJ
CXBhZGxvY2tfcm5nCQkjIFZJQSBQYWRsb2NrIFJORwotZGV2aWNlCQlyZHJhbmRfcm5nCQkjIElu
dGVsIEJ1bGwgTW91bnRhaW4gUk5HCi1kZXZpY2UJCWV0aGVyCQkJIyBFdGhlcm5ldCBzdXBwb3J0
Ci1kZXZpY2UJCXZsYW4JCQkjIDgwMi4xUSBWTEFOIHN1cHBvcnQKLWRldmljZQkJdHVudGFwCQkJ
IyBQYWNrZXQgdHVubmVsLgotZGV2aWNlCQltZAkJCSMgTWVtb3J5ICJkaXNrcyIKLWRldmljZQkJ
Z2lmCQkJIyBJUHY2IGFuZCBJUHY0IHR1bm5lbGluZwotZGV2aWNlCQlmaXJtd2FyZQkJIyBmaXJt
d2FyZSBhc3Npc3QgbW9kdWxlCi1kZXZpY2UJCXh6CQkJIyBsem1hIGRlY29tcHJlc3Npb24KLQot
IyBUaGUgYGJwZicgZGV2aWNlIGVuYWJsZXMgdGhlIEJlcmtlbGV5IFBhY2tldCBGaWx0ZXIuCi0j
IEJlIGF3YXJlIG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb25zZXF1ZW5jZXMgb2YgZW5hYmxpbmcg
dGhpcyEKLSMgTm90ZSB0aGF0ICdicGYnIGlzIHJlcXVpcmVkIGZvciBESENQLgotZGV2aWNlCQli
cGYJCQkjIEJlcmtlbGV5IHBhY2tldCBmaWx0ZXIKLQotIyBVU0Igc3VwcG9ydAotb3B0aW9ucyAJ
VVNCX0RFQlVHCQkjIGVuYWJsZSBkZWJ1ZyBtc2dzCi1kZXZpY2UJCXVoY2kJCQkjIFVIQ0kgUENJ
LT5VU0IgaW50ZXJmYWNlCi1kZXZpY2UJCW9oY2kJCQkjIE9IQ0kgUENJLT5VU0IgaW50ZXJmYWNl
Ci1kZXZpY2UJCWVoY2kJCQkjIEVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlIChVU0IgMi4wKQotZGV2
aWNlCQl4aGNpCQkJIyBYSENJIFBDSS0+VVNCIGludGVyZmFjZSAoVVNCIDMuMCkKLWRldmljZQkJ
dXNiCQkJIyBVU0IgQnVzIChyZXF1aXJlZCkKLWRldmljZQkJdWtiZAkJCSMgS2V5Ym9hcmQKLWRl
dmljZQkJdW1hc3MJCQkjIERpc2tzL01hc3Mgc3RvcmFnZSAtIFJlcXVpcmVzIHNjYnVzIGFuZCBk
YQotCi0jIFNvdW5kIHN1cHBvcnQKLWRldmljZQkJc291bmQJCQkjIEdlbmVyaWMgc291bmQgZHJp
dmVyIChyZXF1aXJlZCkKLWRldmljZQkJc25kX2NtaQkJCSMgQ01lZGlhIENNSTgzMzgvQ01JODcz
OAotZGV2aWNlCQlzbmRfY3NhCQkJIyBDcnlzdGFsIFNlbWljb25kdWN0b3IgQ1M0NjF4LzQyOHgK
LWRldmljZQkJc25kX2VtdTEwa3gJCSMgQ3JlYXRpdmUgU291bmRCbGFzdGVyIExpdmUhIGFuZCBB
dWRpZ3kKLWRldmljZQkJc25kX2VzMTM3eAkJIyBFbnNvbmlxIEF1ZGlvUENJIEVTMTM3eAotZGV2
aWNlCQlzbmRfaGRhCQkJIyBJbnRlbCBIaWdoIERlZmluaXRpb24gQXVkaW8KLWRldmljZQkJc25k
X2ljaAkJCSMgSW50ZWwsIE5WaWRpYSBhbmQgb3RoZXIgSUNIIEFDJzk3IEF1ZGlvCi1kZXZpY2UJ
CXNuZF92aWE4MjMzCQkjIFZJQSBWVDgyMzN4IEF1ZGlvCi0KLSMgTU1DL1NECi1kZXZpY2UJCW1t
YwkJCSMgTU1DL1NEIGJ1cwotZGV2aWNlCQltbWNzZAkJCSMgTU1DL1NEIG1lbW9yeSBjYXJkCi1k
ZXZpY2UJCXNkaGNpCQkJIyBHZW5lcmljIFBDSSBTRCBIb3N0IENvbnRyb2xsZXIKLWRldmljZQkJ
cnRzeAkJCSMgUmVhbHRlayBTRCBjYXJkIHJlYWRlcgotCi0jIFZpcnRJTyBzdXBwb3J0Ci1kZXZp
Y2UJCXZpcnRpbwkJCSMgR2VuZXJpYyBWaXJ0SU8gYnVzIChyZXF1aXJlZCkKLWRldmljZQkJdmly
dGlvX3BjaQkJIyBWaXJ0SU8gUENJIGRldmljZQotZGV2aWNlCQl2dG5ldAkJCSMgVmlydElPIEV0
aGVybmV0IGRldmljZQotZGV2aWNlCQl2aXJ0aW9fYmxrCQkjIFZpcnRJTyBCbG9jayBkZXZpY2UK
LWRldmljZQkJdmlydGlvX3Njc2kJCSMgVmlydElPIFNDU0kgZGV2aWNlCi1kZXZpY2UJCXZpcnRp
b19iYWxsb29uCQkjIFZpcnRJTyBNZW1vcnkgQmFsbG9vbiBkZXZpY2UKLQotIyBMaW51eCBLVk0g
cGFyYXZpcnR1YWxpemF0aW9uIHN1cHBvcnQKLWRldmljZQkJa3ZtX2Nsb2NrCQkjIEtWTSBwYXJh
dmlydHVhbCBjbG9jayBkcml2ZXIKLQotIyBIeXBlclYgZHJpdmVycyBhbmQgZW5oYW5jZW1lbnQg
c3VwcG9ydAotZGV2aWNlCQloeXBlcnYJCQkjIEh5cGVyViBkcml2ZXJzIAotCi0jIFhlbiBIVk0g
R3Vlc3QgT3B0aW1pemF0aW9ucwotIyBOT1RFOiBYRU5IVk0gZGVwZW5kcyBvbiB4ZW5wY2kgYW5k
IHhlbnRpbWVyLgotIyBUaGV5IG11c3QgYmUgYWRkZWQgb3IgcmVtb3ZlZCB0b2dldGhlci4KLW9w
dGlvbnMgCVhFTkhWTQkJCSMgWGVuIEhWTSBrZXJuZWwgaW5mcmFzdHJ1Y3R1cmUKLWRldmljZQkJ
eGVucGNpCQkJIyBYZW4gSFZNIEh5cGVydmlzb3Igc2VydmljZXMgZHJpdmVyCi1kZXZpY2UJCXhl
bnRpbWVyCQkjIFhlbiB4ODYgUFYgdGltZXIgZGV2aWNlCi0KLSMgTmV0bWFwIHByb3ZpZGVzIGRp
cmVjdCBhY2Nlc3MgdG8gVFgvUlggcmluZ3Mgb24gc3VwcG9ydGVkIE5JQ3MKLWRldmljZQkJbmV0
bWFwCQkJIyBuZXRtYXAoNCkgc3VwcG9ydAotCi0jIGV2ZGV2IGludGVyZmFjZQotb3B0aW9ucyAJ
RVZERVZfU1VQUE9SVAkJIyBldmRldiBzdXBwb3J0IGluIGxlZ2FjeSBkcml2ZXJzCi1kZXZpY2UJ
CWV2ZGV2CQkJIyBpbnB1dCBldmVudCBkZXZpY2Ugc3VwcG9ydAotZGV2aWNlCQl1aW5wdXQJCQkj
IGluc3RhbGwgL2Rldi91aW5wdXQgY2RldgotCi0jIEhJRCBzdXBwb3J0Ci1vcHRpb25zIAlISURf
REVCVUcJCSMgZW5hYmxlIGRlYnVnIG1zZ3MKLWRldmljZQkJaGlkCQkJIyBHZW5lcmljIEhJRCBz
dXBwb3J0Ci1vcHRpb25zIAlJSUNISURfU0FNUExJTkcJCSMgV29ya2Fyb3VuZCBtaXNzaW5nIEdQ
SU8gSU5UUiBzdXBwb3J0CisjIyBJTlZBUklBTlRTCitvcHRpb25zCQlJTlZBUklBTlRfU1VQUE9S
VAorI29wdGlvbnMJCUlOVkFSSUFOVFMK
--=_638bd1f3e6e435733e159e41a9eb8dc7--

From nobody Sun Oct  2 16:18:45 2022
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 4MgTfx2z6Xz4dlG3
	for ; Sun,  2 Oct 2022 16:18:49 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MgTfv6Jwbz45kb
	for ; Sun,  2 Oct 2022 16:18:47 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=WcQukLALkii0fZX3ROHSAFpmZjr5GBpM8OjSWH54H6g=; b=CmwTOyRUONb/ZCak9aXo53fXyR
	N3A6Mwo1awTMPQbYCmZDISt8W1DjF4e447jKcuzdGyv3oS65MarLvk8fR9oJDOKifKadXloD8OAqf
	UXFXT2UPw0kBzg3IG261iYde+UG4graRFviYnEWMtJUK8FUpyMUDU1CiLUzeFjHPXquc2A12qfbfs
	y4YbNs0BxguSY+y56l+GA1iri071kzy9wT9pC8lyKU2/O75ubLo0WdAx1ds9eAIlsBwNHKwjhkAbp
	P3fjBDAG3auetUzJlTmJ4Dchnv82cGtP+m/xwBZeHr+5Ezu/oyb8/x3dG2nZKBQew6pejsnEbOoaI
	x8hSMjfg==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:33204 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1of1fy-000FO7-19;
	Sun, 02 Oct 2022 11:18:46 -0500
Received: from 2600:1700:210:b18f:8cb4:f417:c3e6:a42
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sun, 02 Oct 2022 11:18:45 -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
Date: Sun, 02 Oct 2022 11:18:45 -0500
From: Larry Rosenman 
To: "Alexander V. Chernikov" 
Cc: Freebsd current 
Subject: Re: Build Break?
In-Reply-To: <7F2A1941-C042-47FF-969C-3D993D56D088@ipfw.ru>
References: 
 <7F2A1941-C042-47FF-969C-3D993D56D088@ipfw.ru>
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: multipart/mixed;
 boundary="=_12afec66927d0cf5c6de37ca74b122a5"
X-Rspamd-Queue-Id: 4MgTfv6Jwbz45kb
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=CmwTOyRU;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-1.90 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	R_SPF_ALLOW(-0.20)[+mx:c];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	MIME_BASE64_TEXT(0.10)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEFALL_USER(0.00)[ler];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	HAS_ATTACHMENT(0.00)[];
	ASN(0.00)[asn:55103, ipnet:192.147.25.0/24, country:US];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]
X-ThisMailContainsUnwantedMimeParts: N

--=_12afec66927d0cf5c6de37ca74b122a5
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed

On 10/02/2022 8:12 am, Alexander V. Chernikov wrote:
>> On 1 Oct 2022, at 22:57, Larry Rosenman  wrote:
>> 
>> --- all_subdir_nfscommon ---
>> Building 
>> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/nfscommon/nfs_commonkrpc.o
>> --- all_subdir_netgraph ---
>> --- all_subdir_netgraph/deflate ---
>> Building 
>> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/deflate/offset.inc
>> --- all_subdir_netgraph/device ---
>> Building 
>> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/device/i386
>> --- all_subdir_netgraph/echo ---
>> ===> netgraph/echo (all)
>> --- all_subdir_netlink ---
>> --- netlink_io.o ---
>> /usr/src/sys/netlink/netlink_io.c:146:2: error: implicit declaration 
>> of function 'mtx_lock' is invalid in C99 
>> [-Werror,-Wimplicit-function-declaration]
>>        NLP_LOCK(nlp);
> That’s interesting. netlink_io.c includes sys/mutex.h which defines 
> mutex_lock() / mutex_unlock().
>  Could you share the diff between GENERIC and LER-MINIMAL?
> 
I sent the diff in another message, but here is LER-MINIMAL.

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

--=_12afec66927d0cf5c6de37ca74b122a5
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name=LER-MINIMAL
Content-Disposition: attachment;
 filename=LER-MINIMAL;
 size=908

IyBMRVItTUlOSU1BTCAgLS0ga2VybmVsIGNvbmZpZyBiYXNlZCBvbiBNSU5JTUFMCgppbmNsdWRl
CQlNSU5JTUFMCmlkZW50CQlMRVItTUlOSU1BTAoKbm9vcHRpb25zIAlXSVRORVNTCQkJIyBFbmFi
bGUgY2hlY2tzIHRvIGRldGVjdCBkZWFkbG9ja3MgYW5kIGN5Y2xlcwpub29wdGlvbnMgCVdJVE5F
U1NfU0tJUFNQSU4JIyBEb24ndCBydW4gd2l0bmVzcyBvbiBzcGlubG9ja3MgZm9yIHNwZWVkCm9w
dGlvbnMJCUtEQl9VTkFUVEVOREVECiNvcHRpb25zCQlERUJVR19NRU1HVUFSRAojb3B0aW9ucwkJ
REVCVUdfUkVEWk9ORQptYWtlb3B0aW9ucyAJV0lUSF9FWFRSQV9UQ1BfU1RBQ0tTPTEKb3B0aW9u
cyAJVENQSFBUUwpkZXZpY2UJCW1maQpvcHRpb25zCQlUQ1BfUkZDNzQxMwojIEtlcm5lbCBkdW1w
IGZlYXR1cmVzLgpvcHRpb25zICAgICAgICAgRUtDRCAgICAgICAgICAgICAgICAgICAgIyBTdXBw
b3J0IGZvciBlbmNyeXB0ZWQga2VybmVsIGR1bXBzCm9wdGlvbnMgICAgICAgICBHWklPICAgICAg
ICAgICAgICAgICAgICAjIGd6aXAtY29tcHJlc3NlZCBrZXJuZWwgYW5kIHVzZXIgZHVtcHMKb3B0
aW9ucyAgICAgICAgIFpTVERJTyAgICAgICAgICAgICAgICAgICMgenN0ZC1jb21wcmVzc2VkIGtl
cm5lbCBhbmQgdXNlciBkdW1wcwpvcHRpb25zICAgICAgICAgTkVURFVNUCAgICAgICAgICAgICAg
ICAgIyBuZXRkdW1wKDQpIGNsaWVudCBzdXBwb3J0CiMgaXBzZWMgc3VwcG9ydApvcHRpb25zCQlJ
UFNFQ19TVVBQT1JUCmRldmljZQkJY3J5cHRvCgojbmV0Z3JhcGggZGVidWcKb3B0aW9ucwkJTkVU
R1JBUEhfREVCVUcKCiN0Y3AgcmF0ZWxpbWl0Cm9wdGlvbnMJCVJBVEVMSU1JVAoKIyMgSU5WQVJJ
QU5UUwpvcHRpb25zCQlJTlZBUklBTlRfU1VQUE9SVAojb3B0aW9ucwkJSU5WQVJJQU5UUwo=
--=_12afec66927d0cf5c6de37ca74b122a5--

From nobody Sun Oct  2 16:27:23 2022
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 4MgTs03sn0z4dmQ0
	for ; Sun,  2 Oct 2022 16:27:32 +0000 (UTC)
	(envelope-from melifaro@ipfw.ru)
Received: from forward502o.mail.yandex.net (forward502o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::612])
	(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 4MgTry4fgfz47JB
	for ; Sun,  2 Oct 2022 16:27:30 +0000 (UTC)
	(envelope-from melifaro@ipfw.ru)
Received: from myt6-9cfe67cfd141.qloud-c.yandex.net (myt6-9cfe67cfd141.qloud-c.yandex.net [IPv6:2a02:6b8:c12:25a9:0:640:9cfe:67cf])
	by forward502o.mail.yandex.net (Yandex) with ESMTP id B78CE25D4014;
	Sun,  2 Oct 2022 19:27:24 +0300 (MSK)
Received: from 2a02:6b8:c12:1d99:0:640:ab18:0 (2a02:6b8:c12:1d99:0:640:ab18:0 [2a02:6b8:c12:1d99:0:640:ab18:0])
	by myt6-9cfe67cfd141.qloud-c.yandex.net (mxback/Yandex) with HTTP id ERTBDf2fViE1-RNfKTbqq;
	Sun, 02 Oct 2022 19:27:23 +0300
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1664728043;
	bh=Ai1Usz9Gv32SBwkzwNvI8jtUh9w0Ku2wP/xPAr24IdY=;
	h=Message-Id:References:Date:Cc:Subject:In-Reply-To:To:From;
	b=GXFMZI+GzjlnZvWRgmk6rWugL4DPijeu5mhyO9JPb3sLrGI/l7AKxcHeyOSi9qL/P
	 AXJeqwq7g4IigBs60cQedYEC9h+gUmtuvADcH1ViwkP/6kUPGrKLrEg2hPFOMzbYta
	 vvNXFVtGYrnhAgE8EuQsN5Jc8o072RfgXD6rDAgM=
Received: by mf26vabs2z5ql63q.myt.yp-c.yandex.net with HTTP;
	Sun, 02 Oct 2022 19:27:23 +0300
From: Alexander V. Chernikov 
To: Larry Rosenman 
Cc: Freebsd current 
In-Reply-To: 
References:  
	 <7F2A1941-C042-47FF-969C-3D993D56D088@ipfw.ru>
Subject: Re: Build Break?
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
X-Mailer: Yamail [ http://yandex.ru ] 5.0
Date: Sun, 02 Oct 2022 17:27:23 +0100
Message-Id: <1818751664728043@mf26vabs2z5ql63q.myt.yp-c.yandex.net>
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=utf-8
X-Rspamd-Queue-Id: 4MgTry4fgfz47JB
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=ipfw.ru header.s=mail header.b=GXFMZI+G;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 2a02:6b8:0:1a2d::612 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru
X-Spamd-Result: default: False [-2.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail];
	R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0:1a2d::/64];
	MIME_HTML_ONLY(0.20)[];
	MIME_BASE64_TEXT(0.10)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:~];
	RCPT_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	ASN(0.00)[asn:208722, ipnet:2a02:6b8::/32, country:FI];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[melifaro];
	DKIM_TRACE(0.00)[ipfw.ru:+];
	DMARC_NA(0.00)[ipfw.ru];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

MDIuMTAuMjAyMiwgMTc6MTgsICJMYXJyeSBSb3Nlbm1hbiIgJmx0O2xlckBsZXJjdHIub3JnJmd0
Ozo8YnIgLz48YmxvY2txdW90ZT48cD5PbiAxMC8wMi8yMDIyIDg6MTIgYW0sIEFsZXhhbmRlciBW
LiBDaGVybmlrb3Ygd3JvdGU6PGJyIC8+PC9wPjxibG9ja3F1b3RlIGNsYXNzPSIyMTBlN2E4NDhl
OGZjYjQ1d21pLXF1b3RlIj48YmxvY2txdW90ZSBjbGFzcz0iMjEwZTdhODQ4ZThmY2I0NXdtaS1x
dW90ZSI+wqBPbiAxIE9jdCAyMDIyLCBhdCAyMjo1NywgTGFycnkgUm9zZW5tYW4gJmx0OzxhIGhy
ZWY9Im1haWx0bzpsZXJAbGVyY3RyLm9yZyI+bGVyQGxlcmN0ci5vcmc8L2E+Jmd0OyB3cm90ZTo8
YnIgLz7CoDxiciAvPsKgLS0tIGFsbF9zdWJkaXJfbmZzY29tbW9uIC0tLTxiciAvPsKgQnVpbGRp
bmcgPGJyIC8+wqAvdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3N5cy9MRVItTUlOSU1BTC9t
b2R1bGVzL3Vzci9zcmMvc3lzL21vZHVsZXMvbmZzY29tbW9uL25mc19jb21tb25rcnBjLm88YnIg
Lz7CoC0tLSBhbGxfc3ViZGlyX25ldGdyYXBoIC0tLTxiciAvPsKgLS0tIGFsbF9zdWJkaXJfbmV0
Z3JhcGgvZGVmbGF0ZSAtLS08YnIgLz7CoEJ1aWxkaW5nIDxiciAvPsKgL3Vzci9vYmovdXNyL3Ny
Yy9hbWQ2NC5hbWQ2NC9zeXMvTEVSLU1JTklNQUwvbW9kdWxlcy91c3Ivc3JjL3N5cy9tb2R1bGVz
L25ldGdyYXBoL2RlZmxhdGUvb2Zmc2V0LmluYzxiciAvPsKgLS0tIGFsbF9zdWJkaXJfbmV0Z3Jh
cGgvZGV2aWNlIC0tLTxiciAvPsKgQnVpbGRpbmcgPGJyIC8+wqAvdXNyL29iai91c3Ivc3JjL2Ft
ZDY0LmFtZDY0L3N5cy9MRVItTUlOSU1BTC9tb2R1bGVzL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0
Z3JhcGgvZGV2aWNlL2kzODY8YnIgLz7CoC0tLSBhbGxfc3ViZGlyX25ldGdyYXBoL2VjaG8gLS0t
PGJyIC8+wqA9PT0mZ3Q7IG5ldGdyYXBoL2VjaG8gKGFsbCk8YnIgLz7CoC0tLSBhbGxfc3ViZGly
X25ldGxpbmsgLS0tPGJyIC8+wqAtLS0gbmV0bGlua19pby5vIC0tLTxiciAvPsKgL3Vzci9zcmMv
c3lzL25ldGxpbmsvbmV0bGlua19pby5jOjE0NjoyOiBlcnJvcjogaW1wbGljaXQgZGVjbGFyYXRp
b24gPGJyIC8+wqBvZiBmdW5jdGlvbiAnbXR4X2xvY2snIGlzIGludmFsaWQgaW4gQzk5IDxiciAv
PsKgWy1XZXJyb3IsLVdpbXBsaWNpdC1mdW5jdGlvbi1kZWNsYXJhdGlvbl08YnIgLz7CoMKgwqDC
oMKgwqDCoMKgTkxQX0xPQ0sobmxwKTs8YnIgLz48L2Jsb2NrcXVvdGU+wqBUaGF04oCZcyBpbnRl
cmVzdGluZy4gbmV0bGlua19pby5jIGluY2x1ZGVzIHN5cy9tdXRleC5oIHdoaWNoIGRlZmluZXMg
PGJyIC8+wqBtdXRleF9sb2NrKCkgLyBtdXRleF91bmxvY2soKS48YnIgLz7CoMKgQ291bGQgeW91
IHNoYXJlIHRoZSBkaWZmIGJldHdlZW4gR0VORVJJQyBhbmQgTEVSLU1JTklNQUw/PGJyIC8+wqA8
YnIgLz48L2Jsb2NrcXVvdGU+PHA+SSBzZW50IHRoZSBkaWZmIGluIGFub3RoZXIgbWVzc2FnZSwg
YnV0IGhlcmUgaXMgTEVSLU1JTklNQUwuPC9wPjwvYmxvY2txdW90ZT5UaGFuayB5b3UhPGRpdj5T
byBpdOKAmXMgbm9uLW5ldHdvcmtpbmcgY29uZmlnLiBJ4oCZbGwgbWFrZSBuZXRsaW5rIGJ1aWxk
IMKgY29uZGl0aW9uYWwgb24gSU5FVCB8fCBJTkVUNiB0b2RheS90b21vcnJvdy48YnIgLz48Ymxv
Y2txdW90ZT48cD48L3A+PHNwYW4gY2xhc3M9ImY1NWJiYjRlZWVmMjA4ZTh3bWktc2lnbiI+LS0g
PGJyIC8+TGFycnkgUm9zZW5tYW4gICAgICAgICAgICAgICAgICAgICA8YSBocmVmPSJodHRwOi8v
d3d3LmxlcmN0ci5vcmcvfmxlciI+aHR0cDovL3d3dy5sZXJjdHIub3JnL35sZXI8L2E+PGJyIC8+
UGhvbmU6IDxzcGFuIGNsYXNzPSIxZjFlYTE5M2Y2NzM1Y2Ywd21pLWNhbGx0byI+KzEgMjE0LTY0
Mi05NjQwPC9zcGFuPiAgICAgICAgICAgICAgICAgRS1NYWlsOiA8YSBocmVmPSJtYWlsdG86bGVy
QGxlcmN0ci5vcmciPmxlckBsZXJjdHIub3JnPC9hPjxiciAvPlVTIE1haWw6IDU3MDggU2FiYmlh
IERyLCBSb3VuZCBSb2NrLCBUWCA8c3BhbiBjbGFzcz0iMWYxZWExOTNmNjczNWNmMHdtaS1jYWxs
dG8iPjc4NjY1LTIxMDY8L3NwYW4+PGJyIC8+PC9zcGFuPjwvYmxvY2txdW90ZT48L2Rpdj4=

From nobody Sun Oct  2 16:44:00 2022
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 4MgVD53QYCz4dnj8
	for ; Sun,  2 Oct 2022 16:44:05 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MgVD42Tsxz49Lf;
	Sun,  2 Oct 2022 16:44:04 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227])
	by cmsmtp with ESMTP
	id ey5IoPaz7Sp39f24RoHj9Y; Sun, 02 Oct 2022 16:44:03 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id f24PozF3flQu6f24Qo2Z5R; Sun, 02 Oct 2022 16:44:03 +0000
X-Authority-Analysis: v=2.4 cv=YfOuWidf c=1 sm=1 tr=0 ts=6339bfd3
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=Qawa6l4ZSaYA:10 a=6I5d2MoRAAAA:8 a=6VqBrpBaAAAA:8
 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=bKrEB4Z2yty1j8sjinEA:9
 a=JOWeiY5itpwPQvuQ8dm/GawRuwE=:19 a=CjuIK1q_8ugA:10 a=kcW0WbjXQlUA:10
 a=ge1EvK-SRjoA:10 a=IjZwj45LgO3ly-622nXo:22 a=l6wOqGboJC1rSQv2Z1Bd:22
 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id 09D10808;
	Sun,  2 Oct 2022 09:44:01 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id CC846B5; Sun,  2 Oct 2022 09:44:00 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Warner Losh 
cc: Larry Rosenman ,
    Freebsd current ,
    Mark Johnston 
Subject: Meta Mode (was: Re: BOOT CRASH -- Current -CURRENT)
In-reply-to: 
References: <9de62c1d7c3eae83b97a1004780a8d0d@FreeBSD.org> 
  
  
Comments: In-reply-to Warner Losh 
   message dated "Sat, 01 Oct 2022 21:08:32 -0600."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 02 Oct 2022 09:44:00 -0700
Message-Id: <20221002164400.CC846B5@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfC5vaWCe2dmumGVBLznaBGy6y9J7RVuPlCTJ8sc51zc/66PlZBIXyfaJyHxDuUIZFWO5ReBf62equTgDNG3dfpoWbSCGUbXD5xv33BFN4P4NfCZk9ZLg
 FvT+5sP+XRziKDH4dVK/L8gJ77mFAANbBVBGsQiVu3VDY5S0u0IMxpkqPbGuVg5tUAuZH2wf+e8t8wmQ8JJE9PCtU5NdX4XgJDTjJ8zk9ojV/TLMzrS4EzZz
 T23sgcLKyA3Dwx7EVSCeJ0ZKcrl+0/tfbfTO/qwRjBoXqi3ntUP3zrM1XwPZPVr+
X-Rspamd-Queue-Id: 4MgVD42Tsxz49Lf
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	MV_CASE(0.50)[];
	RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	TO_DN_ALL(0.00)[];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	REPLYTO_EQ_FROM(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	RCPT_COUNT_THREE(0.00)[4];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message 
, Warner Losh writes:
> --00000000000065ac9c05ea048b2a
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> On Sat, Oct 1, 2022 at 9:06 PM Larry Rosenman  wrote:
>
> > On 10/01/2022 10:04 pm, Warner Losh wrote:
> >
> > Do  you have a /boot tarball that can be loaded in a VM that recreates th=
> e
> > problem (along with a clean hash)?
> >
> > But before you try that, have you tried a completely clean rebuild of the
> > kernel to preclude the possibility that something is somehow cross thread=
> ed?
> >
> > Warner
> >
> > On Sat, Oct 1, 2022 at 8:39 PM Larry Rosenman  wrote:
> >
> >
> > =E2=9D=AF more info.11
> > Dump header from device: /dev/mfid0p3
> >    Architecture: amd64
> >    Architecture Version: 2
> >    Dump Length: 126748815
> >    Blocksize: 512
> >    Compression: zstd
> >    Dumptime: 2022-10-01 21:26:40 -0500
> >    Hostname:
> >    Magic: FreeBSD Kernel Dump
> >    Version String: FreeBSD 14.0-CURRENT #168
> > ler/freebsd-main-changes-n258354-6cdd871ebc4: Sat Oct  1 21:13:01 CDT
> > 2022
> >      root@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
> >    Panic String: page fault
> >    Dump Parity: 501115454
> >    Bounds: 11
> >    Dump Status: good
> >
> > I do have source and debug stuff, BUT kgdb croaks on me.
> >
> > I *CAN* give access to the machine.
> >
> > the console backtrace showed something about the kld load of
> > dependencies.
> >
> >
> >
> > --
> > Larry Rosenman                     http://people.freebsd.org/~ler
> > Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
> > US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
> >
> > let me wipe /usr/obj, and rebuild everything (I *DO* use meta-mode).
> >
>
> I've had fewer problems with it than non-meta mode, but this looks like a
> 'corruption' or 'cross threaded' crash I've chased in the past that went
> away with a rebuild. So it's better to be sure...

I think so too. What may appear to be a gratuitous rebuild of llvm, for 
example, is in fact meta mode rebuilding because of some makefile change. 
Without meta mode I've experienced odd weirdnesses that are fixed through a 
subsequent clean build.

I just started using meta mode again this week after a few years hiatus to 
see if it addresses the occasional weird behaviour due to something not 
being rebuilt when it should have been.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org
NTP:               Web:  https://nwtime.org

			e^(i*pi)+1=0



From nobody Sun Oct  2 16:44:47 2022
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 4MgVDz6vbKz4dnnq
	for ; Sun,  2 Oct 2022 16:44:51 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MgVDz1HN8z3C4k
	for ; Sun,  2 Oct 2022 16:44:51 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=QQIMuG03wMemA/o2l32QqcVmlXbxP2eJWhKbmwWmQhQ=; b=sibvLUHgz2gC6HLinMAtl7hHxB
	8e+XlGSiK5d4UUHTyJe2TRU2rHrvBAYndDpSNnjhx+GgxdZwHnvJv+Ko0H361jOB/IqNOSzpvKz6D
	/cQKcumml7onb1lIz1QhY/OIVnlgvpGWbJQn5qsH1krXB5H6z8J2TjNm4p9WXSn39vlEMbLWeEaT+
	ta2+6UutagGEqRIwrjZWO3rfjBGvxDn4fXSg8YlQyIJchEwEoGdCkadcRhwaJoe+ubZH9SiOyYi+f
	BOyhBRCw7jB3vJy8Vj8OaJUzN2doy/TChqMR+ehUEHOBZoJivMEcaVQcr5JB70M4WWXkmtdb8NLgJ
	aJiFs1UQ==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:61045 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1of25A-000Fu0-2R;
	Sun, 02 Oct 2022 11:44:48 -0500
Received: from 2600:1700:210:b18f:8cb4:f417:c3e6:a42
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sun, 02 Oct 2022 11:44:47 -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
Date: Sun, 02 Oct 2022 11:44:47 -0500
From: Larry Rosenman 
To: "Alexander V. Chernikov" 
Cc: Freebsd current 
Subject: Re: Build Break?
In-Reply-To: <1818751664728043@mf26vabs2z5ql63q.myt.yp-c.yandex.net>
References: 
 
 <7F2A1941-C042-47FF-969C-3D993D56D088@ipfw.ru>
 <1818751664728043@mf26vabs2z5ql63q.myt.yp-c.yandex.net>
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: multipart/alternative;
 boundary="=_abe3dae1e14f244fab9f2abc05ac4b14"
X-Rspamd-Queue-Id: 4MgVDz1HN8z3C4k
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=sibvLUHg;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:55103, ipnet:192.147.25.0/24, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[ler];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=_abe3dae1e14f244fab9f2abc05ac4b14
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



On 10/02/2022 11:27 am, Alexander V. Chernikov wrote:

> 02.10.2022, 17:18, "Larry Rosenman" :
> 
> On 10/02/2022 8:12 am, Alexander V. Chernikov wrote:  On 1 Oct 2022, at 
> 22:57, Larry Rosenman  wrote:
> 
> --- all_subdir_nfscommon ---
> Building
> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/nfscommon/nfs_commonkrpc.o
> --- all_subdir_netgraph ---
> --- all_subdir_netgraph/deflate ---
> Building
> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/deflate/offset.inc
> --- all_subdir_netgraph/device ---
> Building
> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/device/i386
> --- all_subdir_netgraph/echo ---
> ===> netgraph/echo (all)
> --- all_subdir_netlink ---
> --- netlink_io.o ---
> /usr/src/sys/netlink/netlink_io.c:146:2: error: implicit declaration
> of function 'mtx_lock' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
> NLP_LOCK(nlp);  That's interesting. netlink_io.c includes sys/mutex.h 
> which defines
> mutex_lock() / mutex_unlock().
> Could you share the diff between GENERIC and LER-MINIMAL?

I sent the diff in another message, but here is LER-MINIMAL. Thank you!
So it's non-networking config. I'll make netlink build  conditional on 
INET || INET6 today/tomorrow.

I actually kldload a bunch of stuff.
kld_list="aesni coretemp filemon linux ichsmb ichwd cpuctl cryptodev 
dtraceall i
pmi "
kld_list="$kld_list if_bridge bridgestp if_tuntap hwpmc tcp_rack mfip 
ioat"
kld_list="$kld_list if_bce usb ukbd usb_quirk usb_template ums uhci xhci 
ehci oh
ci"
kld_list="$kld_list efirt nfscl nfscommon nfsd nfslockd nfssvc"
kld_list="$kld_list ataintel geom_label"
#kld_list="$kld_list geom_label"

> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_abe3dae1e14f244fab9f2abc05ac4b14
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



On 10/02/2022 11:27 am, Alexander V. Chernikov wrote:=





02.10.2022, 17:18, "Larry Rosenman" <ler@lerctr.o=
rg>:




On 10/02/2022 8:12 am, Alexander V. Chernikov wrote:




 On 1 Oct 2022, at 2=
2:57, Larry Rosenman <ler@lerctr.org> wrote:
 
 --- all_subdir_nfsc=
ommon ---
 Building 
 /usr/obj/usr/src/amd64.amd64/sys/=
LER-MINIMAL/modules/usr/src/sys/modules/nfscommon/nfs_commonkrpc.o
&nb=
sp;--- all_subdir_netgraph ---
 --- all_subdir_netgraph/deflate -=
--
 Building 
 /usr/obj/usr/src/amd64.amd64/sys/LER-MIN=
IMAL/modules/usr/src/sys/modules/netgraph/deflate/offset.inc
 ---=
 all_subdir_netgraph/device ---
 Building 
 /usr/obj/us=
r/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/devi=
ce/i386
 --- all_subdir_netgraph/echo ---
 =3D=3D=3D>=
; netgraph/echo (all)
 --- all_subdir_netlink ---
 --- =
netlink_io.o ---
 /usr/src/sys/netlink/netlink_io.c:146:2: error:=
 implicit declaration 
 of function 'mtx_lock' is invalid in C99 =

 [-Werror,-Wimplicit-function-declaration]
  &nbs=
p;     NLP_LOCK(nlp);

 That's interesting. netlink_io.c includes sys/mutex.h which defines <=
br /> mutex_lock() / mutex_unlock().
  Could you share =
the diff between GENERIC and LER-MINIMAL?
 


I sent the diff in another message, but here is LER-MINIMAL.



Thank you!

So it's non-networking config. I'll make netlink build  condition=
al on INET || INET6 today/tomorrow.


 


I actually kldload a bunch of stuff.


kld_list=3D"aesni coretemp filemon linux ichsmb ichwd cpuctl cryptodev=
 dtraceall i
pmi "
kld_list=3D"$kld_list if_bridge bridgestp if_t=
untap hwpmc tcp_rack mfip ioat"
kld_list=3D"$kld_list if_bce usb ukbd =
usb_quirk usb_template ums uhci xhci ehci oh
ci"
kld_list=3D"$kld=
_list efirt nfscl nfscommon nfsd nfslockd nfssvc"
kld_list=3D"$kld_lis=
t ataintel geom_label"
#kld_list=3D"$kld_list geom_label"


 









-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr,=
 Round Rock, TX 78665-2106













=
-- 
Larry Rosenman        =
;             http://www.lerctr.org=
/~ler
Phone: +1 214-642-9640           &n=
bsp;     E-Mail: ler@lerctr.org=

US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106





--=_abe3dae1e14f244fab9f2abc05ac4b14--

From nobody Sun Oct  2 16:49:10 2022
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 4MgVL246Fnz4dp78
	for ; Sun,  2 Oct 2022 16:49:14 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MgVL168pCz3D4q
	for ; Sun,  2 Oct 2022 16:49:13 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=v7jR7BCEsPbAyPE/F/dVdpYg1vrEgQRqdy2gFbJXIVo=; b=YWoUBRovvRkDAiTxEFj+3Ns4qY
	gUUO9E1uGGhgDO/TC4ias96HIH+Qw+HJbVdbmGvp8Bkf4ro7BYrorHSTpNkhlxev3zi4fekn9H7yE
	1pnCdCrXVQ75eK5zAqWYRvWPdrT3Ltuyo31D/3cWUTFwdGoSZMR6ojUT19hd5W76L11H6fj8FKMPb
	zFhIqYz/fWLk97Eax7lrNbKN2z1g3r73PI6G8rSC1A6hj3b0D6FJw1rhRRdzdTLtFNXs+D+knSgJz
	+K6nQ7nAuvwiac7eLaYIkXGhk5IyZE4gVrpAUPSEbX1FaRv2og64iiaUG0+e7MEiD03CVsQUqZFN7
	kzU2q0vg==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:44462 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1of29O-000G0C-TO;
	Sun, 02 Oct 2022 11:49:10 -0500
Received: from 2600:1700:210:b18f:8cb4:f417:c3e6:a42
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Sun, 02 Oct 2022 11:49:10 -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
Date: Sun, 02 Oct 2022 11:49:10 -0500
From: Larry Rosenman 
To: "Alexander V. Chernikov" 
Cc: Freebsd current 
Subject: Re: Build Break?
In-Reply-To: 
References: 
 
 <7F2A1941-C042-47FF-969C-3D993D56D088@ipfw.ru>
 <1818751664728043@mf26vabs2z5ql63q.myt.yp-c.yandex.net>
 
Message-ID: 
X-Sender: ler@lerctr.org
Content-Type: multipart/mixed;
 boundary="=_1f891785f981fd25d83c81c4e3f1ddab"
X-Rspamd-Queue-Id: 4MgVL168pCz3D4q
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=YWoUBRov;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-1.90 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	R_SPF_ALLOW(-0.20)[+mx:c];
	MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain];
	MIME_BASE64_TEXT(0.10)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FREEFALL_USER(0.00)[ler];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	HAS_ATTACHMENT(0.00)[];
	ASN(0.00)[asn:55103, ipnet:192.147.25.0/24, country:US];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[lerctr.org:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]
X-ThisMailContainsUnwantedMimeParts: N

--=_1f891785f981fd25d83c81c4e3f1ddab
Content-Type: multipart/alternative;
 boundary="=_de5a987d26aa7293e5ea39ce843203c1"

--=_de5a987d26aa7293e5ea39ce843203c1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



On 10/02/2022 11:44 am, Larry Rosenman wrote:

> On 10/02/2022 11:27 am, Alexander V. Chernikov wrote:
> 02.10.2022, 17:18, "Larry Rosenman" :
> 
> On 10/02/2022 8:12 am, Alexander V. Chernikov wrote:  On 1 Oct 2022, at 
> 22:57, Larry Rosenman  wrote:
> 
> --- all_subdir_nfscommon ---
> Building
> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/nfscommon/nfs_commonkrpc.o
> --- all_subdir_netgraph ---
> --- all_subdir_netgraph/deflate ---
> Building
> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/deflate/offset.inc
> --- all_subdir_netgraph/device ---
> Building
> /usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/device/i386
> --- all_subdir_netgraph/echo ---
> ===> netgraph/echo (all)
> --- all_subdir_netlink ---
> --- netlink_io.o ---
> /usr/src/sys/netlink/netlink_io.c:146:2: error: implicit declaration
> of function 'mtx_lock' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
> NLP_LOCK(nlp);  That's interesting. netlink_io.c includes sys/mutex.h 
> which defines
> mutex_lock() / mutex_unlock().
> Could you share the diff between GENERIC and LER-MINIMAL?

I sent the diff in another message, but here is LER-MINIMAL. Thank you!
So it's non-networking config. I'll make netlink build  conditional on 
INET || INET6 today/tomorrow.

I actually kldload a bunch of stuff.
kld_list="aesni coretemp filemon linux ichsmb ichwd cpuctl cryptodev 
dtraceall i
pmi "
kld_list="$kld_list if_bridge bridgestp if_tuntap hwpmc tcp_rack mfip 
ioat"
kld_list="$kld_list if_bce usb ukbd usb_quirk usb_template ums uhci xhci 
ehci oh
ci"
kld_list="$kld_list efirt nfscl nfscommon nfsd nfslockd nfssvc"
kld_list="$kld_list ataintel geom_label"
#kld_list="$kld_list geom_label"

> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: ler@lerctr.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

also MINIMAL (which I INCLUDE) does have INET/INET6...

PFA MINIMAL

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_de5a987d26aa7293e5ea39ce843203c1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



On 10/02/2022 11:44 am, Larry Rosenman wrote:








On 10/02/2022 11:27 am, Alexander V. Chernikov wrot=
e:




02.10.2022, 17:18, "Larry Rosenman" <ler@lerctr=
=2Eorg>:




On 10/02/2022 8:12 am, Alexander V. Chernikov wrote:




 On 1 Oct 2022, at=
 22:57, Larry Rosenman <ler@lerctr.org> wrote:
 
 --- all_subdir_nf=
scommon ---
 Building 
 /usr/obj/usr/src/amd64.amd64/sy=
s/LER-MINIMAL/modules/usr/src/sys/modules/nfscommon/nfs_commonkrpc.o
&=
nbsp;--- all_subdir_netgraph ---
 --- all_subdir_netgraph/deflate=
 ---
 Building 
 /usr/obj/usr/src/amd64.amd64/sys/LER-M=
INIMAL/modules/usr/src/sys/modules/netgraph/deflate/offset.inc
 -=
-- all_subdir_netgraph/device ---
 Building 
 /usr/obj/=
usr/src/amd64.amd64/sys/LER-MINIMAL/modules/usr/src/sys/modules/netgraph/de=
vice/i386
 --- all_subdir_netgraph/echo ---
 =3D=3D=3D&=
gt; netgraph/echo (all)
 --- all_subdir_netlink ---
 --=
- netlink_io.o ---
 /usr/src/sys/netlink/netlink_io.c:146:2: erro=
r: implicit declaration 
 of function 'mtx_lock' is invalid in C9=
9 
 [-Werror,-Wimplicit-function-declaration]
  &n=
bsp;     NLP_LOCK(nlp);

 That's interesting. netlink_io.c includes sys/mutex.h which defines <=
br /> mutex_lock() / mutex_unlock().
  Could you share =
the diff between GENERIC and LER-MINIMAL?
 


I sent the diff in another message, but here is LER-MINIMAL.



Thank you!

So it's non-networking config. I'll make netlink build  condition=
al on INET || INET6 today/tomorrow.


 


I actually kldload a bunch of stuff.


kld_list=3D"aesni coretemp filemon linux ichsmb ichwd cpuctl cryptodev=
 dtraceall i
pmi "
kld_list=3D"$kld_list if_bridge bridgestp if_t=
untap hwpmc tcp_rack mfip ioat"
kld_list=3D"$kld_list if_bce usb ukbd =
usb_quirk usb_template ums uhci xhci ehci oh
ci"
kld_list=3D"$kld=
_list efirt nfscl nfscommon nfsd nfslockd nfssvc"
kld_list=3D"$kld_lis=
t ataintel geom_label"
#kld_list=3D"$kld_list geom_label"


 









-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr=
, Round Rock, TX 78665-2106<=
/span>













-- 
Larry Rosenman       =
              http://www.lerct=
r.org/~ler
Phone: +1 214-642-9640         &nbs=
p;       E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 7=
8665-2106










also MINIMAL (which I INCLUDE) does have INET/INET6...


PFA MINIMAL




=
-- 
Larry Rosenman        =
;             http://www.lerctr.org=
/~ler
Phone: +1 214-642-9640           &n=
bsp;     E-Mail: ler@lerctr.org=

US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106





--=_de5a987d26aa7293e5ea39ce843203c1--

--=_1f891785f981fd25d83c81c4e3f1ddab
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name=MINIMAL
Content-Disposition: attachment;
 filename=MINIMAL;
 size=5627

IwojIE1JTklNQUwgLS0gTW9zdGx5IE1pbmltYWwga2VybmVsIGNvbmZpZ3VyYXRpb24gZmlsZSBm
b3IgRnJlZUJTRC9hbWQ2NAojCiMgTWFueSBkZWZpbml0aW9ucyBvZiBtaW5pbWFsIGFyZSBwb3Nz
aWJsZS4gVGhlIG9uZSB0aGlzIGZpbGUgZm9sbG93cyBpcwojIEdFTkVSSUMsIG1pbnVzIGFsbCBm
dW5jdGlvbmFsaXR5IHRoYXQgY2FuIGJlIHJlcGxhY2VkIGJ5IGxvYWRpbmcga2VybmVsCiMgbW9k
dWxlcy4KIwojIEV4Y2VwdGlvbnM6CiMgbyBXaGlsZSBVRlMgaXMgYnVpbGRhYmxlIGFzIGEgbW9k
dWxlLCB0aGUgY3VycmVudCBtb2R1bGUgbGFja3MKIyAgIHNvbWUgZmVhdHVyZXMgKEFDTCwgR0pP
VVJOQUwpIHRoYXQgR0VORVJJQyBpbmNsdWRlcy4KIyBvIGFjcGkgYXMgYSBtb2R1bGUgaGFzIGJl
ZW4gcmVwb3J0ZWQgZmxha2V5IGFuZCBub3Qgd2VsbCB0ZXN0ZWQsIHNvCiMgICBpcyBpbmNsdWRl
ZCBpbiB0aGUga2VybmVsLgojIG8gKG5vbi1sb2FkZWQpIHJhbmRvbSBpcyBpbmNsdWRlZCBkdWUg
dG8gdW5jZXJ0YWludHkuLi4KIyBvIE1hbnkgbmV0d29ya2luZyB0aGluZ3MgYXJlIGluY2x1ZGVk
CiMKIyBGb3Igbm93LCBwbGVhc2UgcnVuIGNoYW5nZXMgdG8gdGhlc2UgbGlzdCBwYXN0IGltcEBm
cmVlYnNkLm9yZwojCiMgRm9yIG1vcmUgaW5mb3JtYXRpb24gb24gdGhpcyBmaWxlLCBwbGVhc2Ug
cmVhZCB0aGUgY29uZmlnKDUpIG1hbnVhbCBwYWdlLAojIGFuZC9vciB0aGUgaGFuZGJvb2sgc2Vj
dGlvbiBvbiBLZXJuZWwgQ29uZmlndXJhdGlvbiBGaWxlczoKIwojICAgIGh0dHBzOi8vZG9jcy5m
cmVlYnNkLm9yZy9lbi9ib29rcy9oYW5kYm9vay9rZXJuZWxjb25maWcvI2tlcm5lbGNvbmZpZy1j
b25maWcKIwojIFRoZSBoYW5kYm9vayBpcyBhbHNvIGF2YWlsYWJsZSBsb2NhbGx5IGluIC91c3Iv
c2hhcmUvZG9jL2hhbmRib29rCiMgaWYgeW91J3ZlIGluc3RhbGxlZCB0aGUgZG9jIGRpc3RyaWJ1
dGlvbiwgb3RoZXJ3aXNlIGFsd2F5cyBzZWUgdGhlCiMgRnJlZUJTRCBXb3JsZCBXaWRlIFdlYiBz
ZXJ2ZXIgKGh0dHBzOi8vd3d3LkZyZWVCU0Qub3JnLykgZm9yIHRoZQojIGxhdGVzdCBpbmZvcm1h
dGlvbi4KIwojIEFuIGV4aGF1c3RpdmUgbGlzdCBvZiBvcHRpb25zIGFuZCBtb3JlIGRldGFpbGVk
IGV4cGxhbmF0aW9ucyBvZiB0aGUKIyBkZXZpY2UgbGluZXMgaXMgYWxzbyBwcmVzZW50IGluIHRo
ZSAuLi8uLi9jb25mL05PVEVTIGFuZCBOT1RFUyBmaWxlcy4KIyBJZiB5b3UgYXJlIGluIGRvdWJ0
IGFzIHRvIHRoZSBwdXJwb3NlIG9yIG5lY2Vzc2l0eSBvZiBhIGxpbmUsIGNoZWNrIGZpcnN0CiMg
aW4gTk9URVMuCiMKIyAkRnJlZUJTRCQKCmNwdQkJSEFNTUVSCmlkZW50CQlNSU5JTUFMCgptYWtl
b3B0aW9ucwlERUJVRz0tZwkJIyBCdWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkgZGVidWcgc3ltYm9s
cwptYWtlb3B0aW9ucwlXSVRIX0NURj0xCQkjIFJ1biBjdGZjb252ZXJ0KDEpIGZvciBEVHJhY2Ug
c3VwcG9ydAoKb3B0aW9ucyAJU0NIRURfVUxFCQkjIFVMRSBzY2hlZHVsZXIKb3B0aW9ucyAJTlVN
QQkJCSMgTm9uLVVuaWZvcm0gTWVtb3J5IEFyY2hpdGVjdHVyZSBzdXBwb3J0Cm9wdGlvbnMgCVBS
RUVNUFRJT04JCSMgRW5hYmxlIGtlcm5lbCB0aHJlYWQgcHJlZW1wdGlvbgpvcHRpb25zIAlJTkVU
CQkJIyBJbnRlck5FVHdvcmtpbmcKb3B0aW9ucyAJSU5FVDYJCQkjIElQdjYgY29tbXVuaWNhdGlv
bnMgcHJvdG9jb2xzCm9wdGlvbnMgCVRDUF9PRkZMT0FECQkjIFRDUCBvZmZsb2FkCm9wdGlvbnMg
CVNDVFBfU1VQUE9SVAkJIyBBbGxvdyBrbGRsb2FkIG9mIFNDVFAKb3B0aW9ucyAJRkZTCQkJIyBC
ZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJU09GVFVQREFURVMJCSMgRW5hYmxlIEZG
UyBzb2Z0IHVwZGF0ZXMgc3VwcG9ydApvcHRpb25zIAlVRlNfQUNMCQkJIyBTdXBwb3J0IGZvciBh
Y2Nlc3MgY29udHJvbCBsaXN0cwpvcHRpb25zIAlVRlNfRElSSEFTSAkJIyBJbXByb3ZlIHBlcmZv
cm1hbmNlIG9uIGJpZyBkaXJlY3RvcmllcwpvcHRpb25zIAlVRlNfR0pPVVJOQUwJCSMgRW5hYmxl
IGdqb3VybmFsLWJhc2VkIFVGUyBqb3VybmFsaW5nCm9wdGlvbnMgCVFVT1RBCQkJIyBFbmFibGUg
ZGlzayBxdW90YXMgZm9yIFVGUwpvcHRpb25zIAlNRF9ST09UCQkJIyBNRCBpcyBhIHBvdGVudGlh
bCByb290IGRldmljZQpvcHRpb25zIAlDT01QQVRfRlJFRUJTRDMyCSMgQ29tcGF0aWJsZSB3aXRo
IGkzODYgYmluYXJpZXMKb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q0CQkjIENvbXBhdGlibGUgd2l0
aCBGcmVlQlNENApvcHRpb25zIAlDT01QQVRfRlJFRUJTRDUJCSMgQ29tcGF0aWJsZSB3aXRoIEZy
ZWVCU0Q1Cm9wdGlvbnMgCUNPTVBBVF9GUkVFQlNENgkJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJT
RDYKb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q3CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNENwpv
cHRpb25zIAlDT01QQVRfRlJFRUJTRDkJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q5Cm9wdGlv
bnMgCUNPTVBBVF9GUkVFQlNEMTAJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDEwCm9wdGlvbnMg
CUNPTVBBVF9GUkVFQlNEMTEJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDExCm9wdGlvbnMgCUNP
TVBBVF9GUkVFQlNEMTIJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDEyCm9wdGlvbnMgCUNPTVBB
VF9GUkVFQlNEMTMJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDEzCm9wdGlvbnMgCVNDU0lfREVM
QVk9NTAwMAkJIyBEZWxheSAoaW4gbXMpIGJlZm9yZSBwcm9iaW5nIFNDU0kKb3B0aW9ucyAJS1RS
QUNFCQkJIyBrdHJhY2UoMSkgc3VwcG9ydApvcHRpb25zIAlTVEFDSwkJCSMgc3RhY2soOSkgc3Vw
cG9ydApvcHRpb25zIAlTWVNWU0hNCQkJIyBTWVNWLXN0eWxlIHNoYXJlZCBtZW1vcnkKb3B0aW9u
cyAJU1lTVk1TRwkJCSMgU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwpvcHRpb25zIAlTWVNWU0VN
CQkJIyBTWVNWLXN0eWxlIHNlbWFwaG9yZXMKb3B0aW9ucyAJX0tQT1NJWF9QUklPUklUWV9TQ0hF
RFVMSU5HICMgUE9TSVggUDEwMDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMKb3B0aW9ucyAJUFJJ
TlRGX0JVRlJfU0laRT0xMjgJIyBQcmV2ZW50IHByaW50ZiBvdXRwdXQgYmVpbmcgaW50ZXJzcGVy
c2VkLgpvcHRpb25zIAlLQkRfSU5TVEFMTF9DREVWCSMgaW5zdGFsbCBhIENERVYgZW50cnkgaW4g
L2RldgpvcHRpb25zIAlIV1BNQ19IT09LUwkJIyBOZWNlc3Nhcnkga2VybmVsIGhvb2tzIGZvciBo
d3BtYyg0KQpvcHRpb25zIAlBVURJVAkJCSMgU2VjdXJpdHkgZXZlbnQgYXVkaXRpbmcKb3B0aW9u
cyAJQ0FQQUJJTElUWV9NT0RFCQkjIENhcHNpY3VtIGNhcGFiaWxpdHkgbW9kZQpvcHRpb25zIAlD
QVBBQklMSVRJRVMJCSMgQ2Fwc2ljdW0gY2FwYWJpbGl0aWVzCm9wdGlvbnMgCU1BQwkJCSMgVHJ1
c3RlZEJTRCBNQUMgRnJhbWV3b3JrCm9wdGlvbnMgCUtEVFJBQ0VfRlJBTUUJCSMgRW5zdXJlIGZy
YW1lcyBhcmUgY29tcGlsZWQgaW4Kb3B0aW9ucyAJS0RUUkFDRV9IT09LUwkJIyBLZXJuZWwgRFRy
YWNlIGhvb2tzCm9wdGlvbnMgCUREQl9DVEYJCQkjIEtlcm5lbCBFTEYgbGlua2VyIGxvYWRzIENU
RiBkYXRhCm9wdGlvbnMgCUlOQ0xVREVfQ09ORklHX0ZJTEUJIyBJbmNsdWRlIHRoaXMgZmlsZSBp
biBrZXJuZWwKCiMgRGVidWdnaW5nIHN1cHBvcnQuICBBbHdheXMgbmVlZCB0aGlzOgpvcHRpb25z
IAlLREIJCQkjIEVuYWJsZSBrZXJuZWwgZGVidWdnZXIgc3VwcG9ydC4Kb3B0aW9ucyAJS0RCX1RS
QUNFCQkjIFByaW50IGEgc3RhY2sgdHJhY2UgZm9yIGEgcGFuaWMuCgojIE1ha2UgYW4gU01QLWNh
cGFibGUga2VybmVsIGJ5IGRlZmF1bHQKb3B0aW9ucyAJU01QCQkJIyBTeW1tZXRyaWMgTXVsdGlQ
cm9jZXNzb3IgS2VybmVsCm9wdGlvbnMgCUVBUkxZX0FQX1NUQVJUVVAKCiMgQ1BVIGZyZXF1ZW5j
eSBjb250cm9sCmRldmljZQkJY3B1ZnJlcQoKIyBCdXMgc3VwcG9ydC4KZGV2aWNlCQlhY3BpCm9w
dGlvbnMgCUlPTU1VCmRldmljZQkJcGNpCgojIGF0a2JkYzAgY29udHJvbHMgYm90aCB0aGUga2V5
Ym9hcmQgYW5kIHRoZSBQUy8yIG1vdXNlCmRldmljZQkJYXRrYmRjCQkJIyBBVCBrZXlib2FyZCBj
b250cm9sbGVyCmRldmljZQkJYXRrYmQJCQkjIEFUIGtleWJvYXJkCmRldmljZQkJcHNtCQkJIyBQ
Uy8yIG1vdXNlCgpkZXZpY2UJCWtiZG11eAkJCSMga2V5Ym9hcmQgbXVsdGlwbGV4ZXIKCiMgc3lz
Y29ucyBpcyB0aGUgbGVnYWN5IGNvbnNvbGUgZHJpdmVyLCByZXNlbWJsaW5nIGFuIFNDTyBjb25z
b2xlCmRldmljZQkJdmdhCQkJIyBWR0EgdmlkZW8gY2FyZCBkcml2ZXIKZGV2aWNlCQlzcGxhc2gJ
CQkjIFNwbGFzaCBzY3JlZW4gYW5kIHNjcmVlbiBzYXZlciBzdXBwb3J0CmRldmljZQkJc2MKb3B0
aW9ucyAJU0NfUElYRUxfTU9ERQkJIyBhZGQgc3VwcG9ydCBmb3IgdGhlIHJhc3RlciB0ZXh0IG1v
ZGUKCiMgdnQgaXMgdGhlIGRlZmF1bHQgdmlkZW8gY29uc29sZSBkcml2ZXIKZGV2aWNlCQl2dApk
ZXZpY2UJCXZ0X3ZnYQpkZXZpY2UJCXZ0X2VmaWZiCmRldmljZQkJdnRfdmJlZmIKCmRldmljZQkJ
YWdwCQkJIyBzdXBwb3J0IHNldmVyYWwgQUdQIGNoaXBzZXRzCgojIEJyaW5nIGluICd1YXJ0JyBh
cyB3ZWxsLCBzaW5jZSBpdCBjYW4gYmUgYSBjb25zb2xlIGRyaXZlciBhbmQgYWxsIGNvbnNvbGUK
IyBkcml2ZXJzIG11c3QgYmUgY29tcGlsZWQgaW50byB0aGUga2VybmVsLgpkZXZpY2UJCXVhcnQK
CiMgUHNldWRvIGRldmljZXMuCmRldmljZQkJbG9vcAkJCSMgTmV0d29yayBsb29wYmFjawpkZXZp
Y2UJCXBhZGxvY2tfcm5nCQkjIFZJQSBQYWRsb2NrIFJORwpkZXZpY2UJCXJkcmFuZF9ybmcJCSMg
SW50ZWwgQnVsbCBNb3VudGFpbiBSTkcKZGV2aWNlCQlldGhlcgkJCSMgRXRoZXJuZXQgc3VwcG9y
dAoKIyBUaGUgYGJwZicgZGV2aWNlIGVuYWJsZXMgdGhlIEJlcmtlbGV5IFBhY2tldCBGaWx0ZXIu
CiMgQmUgYXdhcmUgb2YgdGhlIGFkbWluaXN0cmF0aXZlIGNvbnNlcXVlbmNlcyBvZiBlbmFibGlu
ZyB0aGlzIQojIE5vdGUgdGhhdCAnYnBmJyBpcyByZXF1aXJlZCBmb3IgREhDUC4KZGV2aWNlCQli
cGYJCQkjIEJlcmtlbGV5IHBhY2tldCBmaWx0ZXIKCiMgTGludXggS1ZNIHBhcmF2aXJ0dWFsaXph
dGlvbiBzdXBwb3J0CmRldmljZQkJa3ZtX2Nsb2NrCQkjIEtWTSBwYXJhdmlydHVhbCBjbG9jayBk
cml2ZXIKCiMgWGVuIEhWTSBHdWVzdCBPcHRpbWl6YXRpb25zCiMgTk9URTogWEVOSFZNIGRlcGVu
ZHMgb24geGVucGNpIGFuZCB4ZW50aW1lci4KIyBUaGV5IG11c3QgYmUgYWRkZWQgb3IgcmVtb3Zl
ZCB0b2dldGhlci4Kb3B0aW9ucyAJWEVOSFZNCQkJIyBYZW4gSFZNIGtlcm5lbCBpbmZyYXN0cnVj
dHVyZQpkZXZpY2UJCXhlbnBjaQkJCSMgWGVuIEhWTSBIeXBlcnZpc29yIHNlcnZpY2VzIGRyaXZl
cgpkZXZpY2UJCXhlbnRpbWVyCQkjIFhlbiB4ODYgUFYgdGltZXIgZGV2aWNlCgojIGV2ZGV2IGlu
dGVyZmFjZQpvcHRpb25zIAlFVkRFVl9TVVBQT1JUCQkjIGV2ZGV2IHN1cHBvcnQgaW4gbGVnYWN5
IGRyaXZlcnMKZGV2aWNlCQlldmRldgkJCSMgaW5wdXQgZXZlbnQgZGV2aWNlIHN1cHBvcnQKZGV2
aWNlCQl1aW5wdXQJCQkjIGluc3RhbGwgL2Rldi91aW5wdXQgY2Rldgo=
--=_1f891785f981fd25d83c81c4e3f1ddab--

From nobody Mon Oct  3 00:45:31 2022
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 4Mghvx47Jqz4f0Qm
	for ; Mon,  3 Oct 2022 00:45:49 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mghvx1XsCz3wlY
	for ; Mon,  3 Oct 2022 00:45:49 +0000 (UTC)
	(envelope-from 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 2930jV9U010108
	for ; Sun, 2 Oct 2022 17:45:37 -0700 (PDT)
	(envelope-from bsd-lists@bsdforge.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
Date: Sun, 02 Oct 2022 17:45:31 -0700
From: Chris 
To: freebsd-current 
Subject: psm0: unable to allocate IRQ
User-Agent: UDNSMS/17.0
Message-ID: <17441b9fc2e1ea1842b8a95a7a2883d9@bsdforge.com>
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_a9eee56f85a8c96c7fb37279d75cf272"
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4Mghvx1XsCz3wlY
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-Spamd-Result: default: False [0.00 / 15.00];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_a9eee56f85a8c96c7fb37279d75cf272
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

I've spent the last 2 days attempting to get a fresh install of
stable/13-n252407-f42139db639 working on a Dell Inspiron 5755.
The problem I struggled with was getting the trackpad (synaptics?)
to be recognized and function. As it is, it's only ever recognized
as a mouse, and then, only if i kldload(8) ums(4). I'm pretty
sure this is on a psm(4). But any attempts to use psm fail with
psm0: unable to allocate IRQ.
An error I found in dmesg(8) on a verbose boot. Anybody familiar
with this, or have any thoughts on how I might track this down?

To rule out hardware; I installed Slackware along side the
FreeBSD install, and it has no trouble creating a full featured
trackpad under the MATE DE.

Thank you for all your time, and consideration.

--chris
--=_a9eee56f85a8c96c7fb37279d75cf272
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_a9eee56f85a8c96c7fb37279d75cf272--

From nobody Mon Oct  3 13:20:25 2022
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 4Mh1fr3trpz4V4HG
	for ; Mon,  3 Oct 2022 13:20:36 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4Mh1fq1mDxz3vnY
	for ; Mon,  3 Oct 2022 13:20:35 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 2222826019B
	for ; Mon,  3 Oct 2022 15:20:27 +0200 (CEST)
Message-ID: <6b306ee5-fe7e-33a4-e87a-af852d3ffedf@selasky.org>
Date: Mon, 3 Oct 2022 15:20:25 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Content-Language: en-US
To: FreeBSD Current 
From: Hans Petter Selasky 
Subject: [RFC] Three patches for time infrastructure in FreeBSD!
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Mh1fq1mDxz3vnY
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-2.79 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_LONG(-0.49)[-0.490];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	SUBJECT_ENDS_EXCLAIM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_ALL(0.00)[];
	R_DKIM_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

I've made three patches to improve conversion between timing units, like 
sbintime, and usecs and so on.

I've been testing these for some days and can see a notiable difference 
when using realtime audio applications, in the form of less jitter, 
audio/hpsjam and video-chat using www/firefox .

https://reviews.freebsd.org/D36857

https://reviews.freebsd.org/D36858

https://reviews.freebsd.org/D36858

--HPS

From nobody Mon Oct  3 13:26:50 2022
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 4Mh1p72r7kz4V52G
	for ; Mon,  3 Oct 2022 13:26:55 +0000 (UTC)
	(envelope-from garga@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mh1p71qvHz3wwp;
	Mon,  3 Oct 2022 13:26:55 +0000 (UTC)
	(envelope-from garga@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664803615;
	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=+fA1loaij1uKrKZdJ9elbOpEu8MWxXNukGBCBxQQr7g=;
	b=dHjJaHcUPozFLdkj7wmF7xZXkRyqR5b4RswIjOWTj1P1aZ27iFCAuK5PP3C3l7EGYmNhXb
	NpNHUEs6eAlhG1c1GJswDt9H0J70OyG4F42XrAzIYtnDmZKKIdd12IXa9f+jDSswSwEv1D
	lKGfwHVLEvpiOC+YZDohiY2IElTSuONcBsd0ydUK5nQWEKkZ2FBjD/VLMLCPAePE/tVq+Y
	+wmoZjhXC/xnpUatVJvA50TrGYVXelrjrsETLEjgTwLsk0P6+JIGYW8Yp/PpUjNUbjEHKZ
	J1ne1lPlovqwuCSkblcPxod9GIaYyJI8s8LeCePBIaaG77fh7zRb76K9YdnDlA==
Received: from [IPV6:2804:f1c:80b:5a00:8ea:bbb5:1b03:7ff9] (unknown [IPv6:2804:f1c:80b:5a00:8ea:bbb5:1b03:7ff9])
	(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: garga)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mh1p64Y4yz1H6c;
	Mon,  3 Oct 2022 13:26:54 +0000 (UTC)
	(envelope-from garga@FreeBSD.org)
Message-ID: <9fc2ad6a-3e50-895b-1fd0-cfe80a9f9a1b@FreeBSD.org>
Date: Mon, 3 Oct 2022 10:26:50 -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/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.3.1
Subject: Re: [RFC] Three patches for time infrastructure in FreeBSD!
To: Hans Petter Selasky ,
 FreeBSD Current 
References: <6b306ee5-fe7e-33a4-e87a-af852d3ffedf@selasky.org>
Content-Language: en-US
From: Renato Botelho 
In-Reply-To: <6b306ee5-fe7e-33a4-e87a-af852d3ffedf@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664803615;
	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=+fA1loaij1uKrKZdJ9elbOpEu8MWxXNukGBCBxQQr7g=;
	b=vnzMKQPuEyAmuPSfTb066tEtEtegiGGDrhBySOhqiU4sZiGFZB5YL7/s5+Uzm1qbfgBMIf
	4Ct+wIeSVP2Hb3UTn0u29HBHnsM4P5M1TVbl9fv+NtdQkeEY1mK2NnVmRTO9K1fuCGuZ/e
	65FuiWdb9AfGnhzWR3coqj27wytS3iQRRoeHIuPlbrre2ciCY6yM8rZy1PdTR6dJZjiwiU
	Iqj8Ui7QS7gh1N0N+3ICDAqeT1mQJvXIkZCOv+qehAtN0sH0PsfakPcasbuBLS2qg8kKBH
	P6DsmoDSPGU7Q7roQpd04gMh+d2afoROAM2UIrkITZY2p2Il9yJkaMukO5zQqQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664803615; a=rsa-sha256; cv=none;
	b=UGDcjTPZyGD7ui9ev/QcGocqXMkxoh1nZB0r2WHff1sTrs1dS7UFp9268DemnWtYCw7QE+
	x8Mjz1A2fCY9KW1tBLD+ijIGhl0p/Ch0N83RcJlI/3YDhOquEtUG8mQsGPVpsND8qu1y8n
	yf0CuF+04Cl5Gi165SzDKMK3xMh6dof7F085BfIVIcO5lC8ZrqTkTb8DmSUL8iJpDAnXND
	3YKeW4NwKSSElGaCwIaQMs3pAcjFFnTaxA4stIQ4r/nJpsi54uewCLNWss6d9848II6Ee+
	ib7j7v2DZvQzBaGGV6msBfnWWYNaSisFQZRrEJ+vA2u6BsdJk4f+kq8a76AF9Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 03/10/22 10:20, Hans Petter Selasky wrote:
> Hi,
> 
> I've made three patches to improve conversion between timing units, like 
> sbintime, and usecs and so on.
> 
> I've been testing these for some days and can see a notiable difference 
> when using realtime audio applications, in the form of less jitter, 
> audio/hpsjam and video-chat using www/firefox .
> 
> https://reviews.freebsd.org/D36857
> 
> https://reviews.freebsd.org/D36858
> 
> https://reviews.freebsd.org/D36858

You added D36858 twice.

-- 
Renato Botelho


From nobody Mon Oct  3 13:27:50 2022
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 4Mh1qN2xbJz4V54R
	for ; Mon,  3 Oct 2022 13:28:00 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mh1qM4f6tz3y3d;
	Mon,  3 Oct 2022 13:27:59 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 6F05426019B;
	Mon,  3 Oct 2022 15:27:52 +0200 (CEST)
Message-ID: <4c90ffef-d376-2776-a24c-305dce77a037@selasky.org>
Date: Mon, 3 Oct 2022 15:27:50 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: [RFC] Three patches for time infrastructure in FreeBSD!
Content-Language: en-US
To: Renato Botelho ,
 FreeBSD Current 
References: <6b306ee5-fe7e-33a4-e87a-af852d3ffedf@selasky.org>
 <9fc2ad6a-3e50-895b-1fd0-cfe80a9f9a1b@FreeBSD.org>
From: Hans Petter Selasky 
In-Reply-To: <9fc2ad6a-3e50-895b-1fd0-cfe80a9f9a1b@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Mh1qM4f6tz3y3d
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-1.35 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_SPAM_LONG(0.95)[0.946];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	SUBJECT_ENDS_EXCLAIM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	RCPT_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 10/3/22 15:26, Renato Botelho wrote:
> On 03/10/22 10:20, Hans Petter Selasky wrote:
>> Hi,
>>
>> I've made three patches to improve conversion between timing units, 
>> like sbintime, and usecs and so on.
>>
>> I've been testing these for some days and can see a notiable 
>> difference when using realtime audio applications, in the form of less 
>> jitter, audio/hpsjam and video-chat using www/firefox .
>>
>> https://reviews.freebsd.org/D36857
>>
>> https://reviews.freebsd.org/D36858
>>
>> https://reviews.freebsd.org/D36858
> 
> You added D36858 twice.
> 

Off-by one:

https://reviews.freebsd.org/D36859

--HPS

From nobody Mon Oct  3 14:57:13 2022
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 4Mh3pV2fR2z4cwSH
	for ; Mon,  3 Oct 2022 14:57:22 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mh3pT6LgDz44Jn
	for ; Mon,  3 Oct 2022 14:57:21 +0000 (UTC)
	(envelope-from 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 293EvEIS028109
	for ; Mon, 3 Oct 2022 07:57:20 -0700 (PDT)
	(envelope-from bsd-lists@bsdforge.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
Date: Mon, 03 Oct 2022 07:57:13 -0700
From: Chris 
To: freebsd-current 
Subject: Re: psm0: unable to allocate IRQ
In-Reply-To: <17441b9fc2e1ea1842b8a95a7a2883d9@bsdforge.com>
References: <17441b9fc2e1ea1842b8a95a7a2883d9@bsdforge.com>
User-Agent: UDNSMS/17.0
Message-ID: <367346e54761e295c21bac42afad6b4f@bsdforge.com>
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_44b7ab5834ed36874a5d524c02416de7"
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4Mh3pT6LgDz44Jn
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-Spamd-Result: default: False [0.00 / 15.00];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_44b7ab5834ed36874a5d524c02416de7
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-10-02 17:45, Chris wrote:
> I've spent the last 2 days attempting to get a fresh install of
> stable/13-n252407-f42139db639 working on a Dell Inspiron 5755.

Just attempted it again with the
14.0-CURRENT-amd64-20220930-42dc8696df5-258315 image, with the
same results. Yet Linux && Windows work as intended. Any thoughts
on how I might track the problem down in FreeBSD?
Thanks.

> The problem I struggled with was getting the trackpad (synaptics?)
> to be recognized and function. As it is, it's only ever recognized
> as a mouse, and then, only if i kldload(8) ums(4). I'm pretty
> sure this is on a psm(4). But any attempts to use psm fail with
> psm0: unable to allocate IRQ.
> An error I found in dmesg(8) on a verbose boot. Anybody familiar
> with this, or have any thoughts on how I might track this down?
> 
> To rule out hardware; I installed Slackware along side the
> FreeBSD install, and it has no trouble creating a full featured
> trackpad under the MATE DE.
> 
> Thank you for all your time, and consideration.
> 
> --chris

--=_44b7ab5834ed36874a5d524c02416de7
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_44b7ab5834ed36874a5d524c02416de7--

From nobody Mon Oct  3 15:05:30 2022
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 4Mh40L73hgz4cx9X
	for ; Mon,  3 Oct 2022 15:05:54 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mh40K6Bl2z45S1
	for ; Mon,  3 Oct 2022 15:05:53 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1])
	by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 293F5VjR028156;
	Mon, 3 Oct 2022 08:05:31 -0700 (PDT)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: (from freebsd-rwg@localhost)
	by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 293F5U0s028155;
	Mon, 3 Oct 2022 08:05:30 -0700 (PDT)
	(envelope-from freebsd-rwg)
From: "Rodney W. Grimes" 
Message-Id: <202210031505.293F5U0s028155@gndrsh.dnsmgr.net>
Subject: Re: psm0: unable to allocate IRQ
In-Reply-To: <367346e54761e295c21bac42afad6b4f@bsdforge.com>
To: Chris 
Date: Mon, 3 Oct 2022 08:05:30 -0700 (PDT)
CC: freebsd-current 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Rspamd-Queue-Id: 4Mh40K6Bl2z45S1
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net
X-Spamd-Result: default: False [-2.10 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	TO_DN_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	DMARC_NA(0.00)[dnsmgr.net];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> On 2022-10-02 17:45, Chris wrote:
> > I've spent the last 2 days attempting to get a fresh install of
> > stable/13-n252407-f42139db639 working on a Dell Inspiron 5755.
> 
> Just attempted it again with the
> 14.0-CURRENT-amd64-20220930-42dc8696df5-258315 image, with the
> same results. Yet Linux && Windows work as intended. Any thoughts
> on how I might track the problem down in FreeBSD?
> Thanks.
> 
> > The problem I struggled with was getting the trackpad (synaptics?)
> > to be recognized and function. As it is, it's only ever recognized
> > as a mouse, and then, only if i kldload(8) ums(4). I'm pretty
> > sure this is on a psm(4). But any attempts to use psm fail with
> > psm0: unable to allocate IRQ.
> > An error I found in dmesg(8) on a verbose boot. Anybody familiar
> > with this, or have any thoughts on how I might track this down?
> > 
> > To rule out hardware; I installed Slackware along side the
> > FreeBSD install, and it has no trouble creating a full featured
> > trackpad under the MATE DE.

And in Slackware did it show up as a psm device,
and if it did what IRQ is it using.

Or what I suspect, is it shows up as a USB device.

> > 
> > Thank you for all your time, and consideration.
> > 
> > --chris


-- 
Rod Grimes                                                 rgrimes@freebsd.org

From nobody Mon Oct  3 16:32:23 2022
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 4Mh5wH0F9zz4ddLq
	for ; Mon,  3 Oct 2022 16:32:31 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mh5wG5r4Jz3PWt
	for ; Mon,  3 Oct 2022 16:32:30 +0000 (UTC)
	(envelope-from 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 293GWNlI053607;
	Mon, 3 Oct 2022 09:32:29 -0700 (PDT)
	(envelope-from bsd-lists@bsdforge.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
Date: Mon, 03 Oct 2022 09:32:23 -0700
From: Chris 
To: "Rodney W. Grimes" 
Cc: freebsd-current 
Subject: Re: psm0: unable to allocate IRQ
In-Reply-To: <202210031505.293F5U0s028155@gndrsh.dnsmgr.net>
References: <202210031505.293F5U0s028155@gndrsh.dnsmgr.net>
User-Agent: UDNSMS/17.0
Message-ID: <38cb26da1cf458689a8c7db3c2bc806a@bsdforge.com>
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_21ccc9214e394347865791e2eb3ca3fe"
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4Mh5wG5r4Jz3PWt
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-Spamd-Result: default: False [0.00 / 15.00];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_21ccc9214e394347865791e2eb3ca3fe
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-10-03 08:05, Rodney W. Grimes wrote:
>> On 2022-10-02 17:45, Chris wrote:
>> > I've spent the last 2 days attempting to get a fresh install of
>> > stable/13-n252407-f42139db639 working on a Dell Inspiron 5755.
>> 
>> Just attempted it again with the
>> 14.0-CURRENT-amd64-20220930-42dc8696df5-258315 image, with the
>> same results. Yet Linux && Windows work as intended. Any thoughts
>> on how I might track the problem down in FreeBSD?
>> Thanks.
>> 
>> > The problem I struggled with was getting the trackpad (synaptics?)
>> > to be recognized and function. As it is, it's only ever recognized
>> > as a mouse, and then, only if i kldload(8) ums(4). I'm pretty
>> > sure this is on a psm(4). But any attempts to use psm fail with
>> > psm0: unable to allocate IRQ.
>> > An error I found in dmesg(8) on a verbose boot. Anybody familiar
>> > with this, or have any thoughts on how I might track this down?
>> >
>> > To rule out hardware; I installed Slackware along side the
>> > FreeBSD install, and it has no trouble creating a full featured
>> > trackpad under the MATE DE.
> 
> And in Slackware did it show up as a psm device,
> and if it did what IRQ is it using.
> 
> Or what I suspect, is it shows up as a USB device.

Mr. Grimes, you're wise well beyond your years.
IOW Thanks! You nailed it.

# lsusb
Bus 004 Device 003: ID 8087:07dc Intel Corp.
Bus 004 Device 002: ID 0438:7900 Advanced Micro Devices, Inc.
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 004: ID 06cb:75bf Synaptics, Inc.  
<===================================
Bus 003 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card 
Reader Controller
Bus 003 Device 002: ID 0438:7900 Advanced Micro Devices, Inc.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 064e:920b Suyin Corp. Integrated_Webcam_HD
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
     |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
         |__ Port 1: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
         |__ Port 1: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
     |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
         |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, 
Driver=rtsx_usb, 480M
         |__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 
12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
     |__ Port 2: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
     |__ Port 2: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M

Now. If I can only figure out why FreeBSD's Synaptics module
only polls psm(4).

Thanks, Rodney!

--chris
--=_21ccc9214e394347865791e2eb3ca3fe
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_21ccc9214e394347865791e2eb3ca3fe--

From nobody Tue Oct  4 08:53:04 2022
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 4MhWgw01P9z4V8fZ
	for ; Tue,  4 Oct 2022 08:53:16 +0000 (UTC)
	(envelope-from alfadev@protonmail.com)
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130])
	(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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MhWgv1B7mz3FhT
	for ; Tue,  4 Oct 2022 08:53:15 +0000 (UTC)
	(envelope-from alfadev@protonmail.com)
Date: Tue, 04 Oct 2022 08:53:04 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=protonmail3; t=1664873592; x=1665132792;
	bh=Ixz2vvc7VnyqIiadny8THR3hoOb4PF7DCkcocOq07os=;
	h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
	 Subject:Reply-To:Feedback-ID:Message-ID;
	b=p5UMo9o01D9HX5WlcZ+ilgnBptr4leSndL3wbgaYT+7J+sbrNK2G6tsF+cLXa/Hl5
	 H7GVJds/ogeMAK/a1i8px4EqAUV/JkZFGLGOpxA+BpKzkQslKA1ePpBhbsyUw2HC5p
	 5D70RAsQiNpIY+R/l3t+SSDWHN7et/YrY8W9iptNIJ7w7qaWuNO0twik4c1HCU9/7v
	 5JGxW5U/lTj7HODhpsoZp+//ghKOK7wSCroekzrknkYmVkxDv1KLaB2Lv05mFGM9/G
	 Cl8/lfWwZcZnggORTb4aEjho7Iapl6N/GpQHga0ckr5MUsLZ1iTcML5zr8eQsZAyIM
	 fvnsZYbJdT1lQ==
To: "freebsd-current@FreeBSD.org" 
From: alfadev 
Subject: How to Enable support for IPsec deprecated algorithms: 3DES, MD5-HMAC
Message-ID: 
Feedback-ID: 37008931:user:proton
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="b1_Vv1HplekoC6NxculTkiOrMAE8MR0iaYuigQ7xZ96I"
X-Rspamd-Queue-Id: 4MhWgv1B7mz3FhT
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=p5UMo9o0;
	dmarc=pass (policy=quarantine) header.from=protonmail.com;
	spf=pass (mx1.freebsd.org: domain of alfadev@protonmail.com designates 185.70.40.130 as permitted sender) smtp.mailfrom=alfadev@protonmail.com
X-Spamd-Result: default: False [-1.37 / 15.00];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	NEURAL_HAM_SHORT(-0.99)[-0.990];
	NEURAL_HAM_LONG(-0.70)[-0.696];
	DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine];
	NEURAL_SPAM_MEDIUM(0.22)[0.220];
	R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail3];
	R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MIME_BASE64_TEXT(0.10)[];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	TO_DN_EQ_ADDR_ALL(0.00)[];
	RCVD_COUNT_ZERO(0.00)[0];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[protonmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[protonmail.com:+];
	FREEMAIL_FROM(0.00)[protonmail.com];
	RCPT_COUNT_ONE(0.00)[1];
	HAS_PHPMAILER_SIG(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.

--b1_Vv1HplekoC6NxculTkiOrMAE8MR0iaYuigQ7xZ96I
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SGksIGkgYW0gdHJ5aW5nIHRvIG1vdmUgbXkgZ2F0ZXdheSBmcm9tIEZyZWVCU0QgMTEuMCB0byBG
cmVlQlNEIDE0LjAgdG8gdXNlCm5ld2x5IGFkZGVkIGlwZncgdGFibGUgbG9va3VwIGZvciBtYWMg
YWRkcmVzc2VzIChodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDM1MTAzKQoKQWxzbyBJIGhh
dmUgdG9vIG1hbnkgSVBTZWMgY29ubmVjdGlvbnMgYmV0d2VlbiBmb3J0aWdhdGUsIGNpc2NvIGV0
Yy4KQW5kIHRoZWlyIG9wZXJhdG9ycyB1c2Ugb25seSAzREVTIGFsZ29yaXRobXMgYW5kIHRoZXkg
aGF2ZSBubyBpbnRlbnRpb24gdG8gY2hhbmdlIGl0IGZvciBtZS4KU28sIG5vdyBpIGhhdmUgdG8g
ZW5hYmxlIDNERVMgc3VwcG9ydCBmb3IgRnJlZUJTRCAxNC4wIC4KClRvIGFkZCAzREVTIHN1cHBv
cnQgYWdhaW4gaSBjaGFuZ2VkIHNvbWUgZmlsZXMgc2hvd24gYmVsb3cuCkkgYW0gbm90IHN1cmUg
d2hhdCBpIGRpZCBhbnkgaGVscCB3ZWxjb21lcy4KCmkgcmVzdG9yZWQgYmVsb3cgZmlsZXM6Cgpo
dHRwczovL2NnaXQuZnJlZWJzZC5vcmcvc3JjL2NvbW1pdC8/aWQ9MTZhYWJiNzYxYzBhCgotcnct
ci0tci0tCVtsaWIvbGliaXBzZWMvcGZrZXlfZHVtcC5jXShodHRwczovL2NnaXQuZnJlZWJzZC5v
cmcvc3JjL2RpZmYvbGliL2xpYmlwc2VjL3Bma2V5X2R1bXAuYz9pZD0xNmFhYmI3NjFjMGEpCTI1
Cgotcnctci0tci0tCVtzYmluL3NldGtleS9zYW1wbGUuY2ZdKGh0dHBzOi8vY2dpdC5mcmVlYnNk
Lm9yZy9zcmMvZGlmZi9zYmluL3NldGtleS9zYW1wbGUuY2Y/aWQ9MTZhYWJiNzYxYzBhKQk3OQoK
LXJ3LXItLXItLQlbc2Jpbi9zZXRrZXkvc2V0a2V5LjhdKGh0dHBzOi8vY2dpdC5mcmVlYnNkLm9y
Zy9zcmMvZGlmZi9zYmluL3NldGtleS9zZXRrZXkuOD9pZD0xNmFhYmI3NjFjMGEpCTI5Cgotcnct
ci0tci0tCVtzYmluL3NldGtleS90ZXN0LXBma2V5LmNdKGh0dHBzOi8vY2dpdC5mcmVlYnNkLm9y
Zy9zcmMvZGlmZi9zYmluL3NldGtleS90ZXN0LXBma2V5LmM/aWQ9MTZhYWJiNzYxYzBhKQkzMgoK
LXJ3LXItLXItLQlbc2Jpbi9zZXRrZXkvdG9rZW4ubF0oaHR0cHM6Ly9jZ2l0LmZyZWVic2Qub3Jn
L3NyYy9kaWZmL3NiaW4vc2V0a2V5L3Rva2VuLmw/aWQ9MTZhYWJiNzYxYzBhKQkxMQoKLXJ3LXIt
LXItLQlbc3lzL25ldGlwc2VjL2lwc2VjLmNdKGh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9zcmMv
ZGlmZi9zeXMvbmV0aXBzZWMvaXBzZWMuYz9pZD0xNmFhYmI3NjFjMGEpCTUKCi1ydy1yLS1yLS0J
W3N5cy9uZXRpcHNlYy9pcHNlYy5oXShodHRwczovL2NnaXQuZnJlZWJzZC5vcmcvc3JjL2RpZmYv
c3lzL25ldGlwc2VjL2lwc2VjLmg/aWQ9MTZhYWJiNzYxYzBhKQkyCgotcnctci0tci0tCVtzeXMv
bmV0aXBzZWMva2V5LmNdKGh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9zcmMvZGlmZi9zeXMvbmV0
aXBzZWMva2V5LmM/aWQ9MTZhYWJiNzYxYzBhKQkxMgoKLXJ3LXItLXItLQlbc3lzL25ldGlwc2Vj
L3hmb3JtX2FoLmNdKGh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9zcmMvZGlmZi9zeXMvbmV0aXBz
ZWMveGZvcm1fYWguYz9pZD0xNmFhYmI3NjFjMGEpCTI2Cgotcnctci0tci0tCVtzeXMvbmV0aXBz
ZWMveGZvcm1fZXNwLmNdKGh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9zcmMvZGlmZi9zeXMvbmV0
aXBzZWMveGZvcm1fZXNwLmM/aWQ9MTZhYWJiNzYxYzBhKQkyNQoKLXJ3LXItLXItLQlbdXNyLmJp
bi9uZXRzdGF0L2lwc2VjLmNdKGh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9zcmMvZGlmZi91c3Iu
YmluL25ldHN0YXQvaXBzZWMuYz9pZD0xNmFhYmI3NjFjMGEpCgpodHRwczovL2NnaXQuZnJlZWJz
ZC5vcmcvc3JjL2NvbW1pdC8/aWQ9NmM4MGMzMTllZjg4Cgotcnctci0tci0tCVtzeXMvb3BlbmNy
eXB0by9jcnlwdG9kZXYuY10oaHR0cHM6Ly9jZ2l0LmZyZWVic2Qub3JnL3NyYy9kaWZmL3N5cy9v
cGVuY3J5cHRvL2NyeXB0b2Rldi5jP2lkPTZjODBjMzE5ZWY4OCkKLXJ3LXItLXItLQlbc3lzL29w
ZW5jcnlwdG8vY3J5cHRvZGV2Ll0oaHR0cHM6Ly9jZ2l0LmZyZWVic2Qub3JnL3NyYy9kaWZmL3N5
cy9vcGVuY3J5cHRvL2NyeXB0b2Rldi5jP2lkPTZjODBjMzE5ZWY4OCloCgpDb21waWxlZCBOZXcg
S2VybmVsIHdpdGggdGhpcyBleHRyYSBvcHRpb25zOgoKIyBPV05LRVJOdjEKaW5jbHVkZSBHRU5F
UklDaWRlbnQgT1dOS0VSTnYxCgpvcHRpb25zIElQRklSRVdBTEwKb3B0aW9ucyBEVU1NWU5FVApv
cHRpb25zIElQRklSRVdBTExfREVGQVVMVF9UT19BQ0NFUFQKb3B0aW9ucyBJUERJVkVSVApvcHRp
b25zIElQU0VDCm9wdGlvbnMgSVBTRUNfU1VQUE9SVApkZXZpY2UgY3J5cHRvCgpjZCAvdXNyL3Ny
YwptYWtlIC1qJChzeXNjdGwgLW4gaHcubmNwdSkgYnVpbGRrZXJuZWwgS0VSTkNPTkY9T1dOS0VS
TnYxCgpCdXQgV2hlbiBpIHRyeSB0byBjb21waWxlIG5ldyBrZXJuZWwgaXQgZ2V0cyB0b28gbWFu
eSBlcnJvcnMuCmFueSBoZWxwIHdpbGwgYmUgYXBwcmVjaWF0ZWQgYXQgdGhpcyBwb2ludC4uCgpQ
YXJ0IG9mIEVycm9yIExvZ3M6Ci0tIGFsbF9zdWJkaXJfY3J5cHRvZGV2IC0tLQovdXNyL3NyYy9z
eXMvb3BlbmNyeXB0by9jcnlwdG9kZXYuYzozMTQ6MTY6IGVycm9yOiBpbmNvbXBhdGlibGUgZnVu
Y3Rpb24gcG9pbnRlciB0eXBlcyBpbml0aWFsaXppbmcgJ2ZvX3N0YXRfdCAqJyAoYWthICdpbnQg
KCopKHN0cnVjdCBmaWxlICosIHN0cnVjdCBzdGF0ICosIHN0cnVjdCB1Y3JlZCAqKScpIHdpdGgg
YW4gZXhwcmVzc2lvbiBvZiB0eXBlICdpbnQgKHN0cnVjdCBmaWxlICosIHN0cnVjdCBzdGF0ICos
IHN0cnVjdCB1Y3JlZCAqLCBzdHJ1Y3QgdGhyZWFkICopJyBbLVdlcnJvciwtV2luY29tcGF0aWJs
ZS1mdW5jdGlvbi1wb2ludGVyLXR5cGVzXQouZm9fc3RhdCA9IGNyeXB0b2Zfc3RhdCwKXn5+fn5+
fn5+fn5+Ci91c3Ivc3JjL3N5cy9vcGVuY3J5cHRvL2NyeXB0b2Rldi5jOjQxMjoxNDogZXJyb3I6
IHVzZSBvZiB1bmRlY2xhcmVkIGlkZW50aWZpZXIgJ2VuY194Zm9ybV9kZXMnOyBkaWQgeW91IG1l
YW4gJ2VuY194Zm9ybV9jY20nPwp0eGZvcm0gPSAmZW5jX3hmb3JtX2RlczsKXn5+fn5+fn5+fn5+
fgplbmNfeGZvcm1fY2NtCi91c3Ivc3JjL3N5cy9vcGVuY3J5cHRvL3hmb3JtX2VuYy5oOjEwNToz
MTogbm90ZTogJ2VuY194Zm9ybV9jY20nIGRlY2xhcmVkIGhlcmUKZXh0ZXJuIGNvbnN0IHN0cnVj
dCBlbmNfeGZvcm0gZW5jX3hmb3JtX2NjbTsKXgovdXNyL3NyYy9zeXMvb3BlbmNyeXB0by9jcnlw
dG9kZXYuYzo0MTU6MTQ6IGVycm9yOiB1c2Ugb2YgdW5kZWNsYXJlZCBpZGVudGlmaWVyICdlbmNf
eGZvcm1fM2RlcycKdHhmb3JtID0gJmVuY194Zm9ybV8zZGVzOwpeLi4u

--b1_Vv1HplekoC6NxculTkiOrMAE8MR0iaYuigQ7xZ96I
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij48c3BhbiBz
dHlsZT0ibGluZS1oZWlnaHQ6MS41O2ZvbnQtZmFtaWx5OnN5c3RlbS11aSwgc2Fucy1zZXJpZiI+
PGZvbnQgZmFjZT0ibW9ub3NwYWNlIiBjb2xvcj0iIzMzMzMzMyI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMy4zMzMzcHg7d2hpdGUtc3BhY2U6cHJlIj5IaSwgaSBhbSB0cnlpbmcgdG8gbW92ZSBt
eSBnYXRld2F5IGZyb20gPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwgMjU1
LCAyNTUpO2Rpc3BsYXk6aW5saW5lICFpbXBvcnRhbnQiPkZyZWVCU0QgMTEuMCB0byA8L3NwYW4+
RnJlZUJTRCAxNC4wIHRvIHVzZTwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjxkaXYgc3R5bGU9ImxpbmUt
aGVpZ2h0OjEuNTtmb250LWZhbWlseTpzeXN0ZW0tdWksIHNhbnMtc2VyaWYiPjxmb250IGZhY2U9
Im1vbm9zcGFjZSIgY29sb3I9IiMzMzMzMzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMz
M3B4O3doaXRlLXNwYWNlOnByZSI+bmV3bHkgYWRkZWQgaXBmdyB0YWJsZSBsb29rdXAgZm9yIG1h
YyBhZGRyZXNzZXMgKDxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9E
MzUxMDMiIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciIgdGFyZ2V0PSJfYmxhbmsi
IHN0eWxlPSJjb2xvcjp2YXIoLS1pbnRlcmFjdGlvbi1ub3JtKTt0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO2N1cnNvcjpwb2ludGVyIj5odHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDM1MTAz
PC9hPik8L3NwYW4+PC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2IHN0eWxlPSJsaW5lLWhlaWdodDox
LjU7Zm9udC1mYW1pbHk6c3lzdGVtLXVpLCBzYW5zLXNlcmlmIj48YnI+PC9kaXY+PGRpdiBzdHls
ZT0ibGluZS1oZWlnaHQ6MS41O2ZvbnQtZmFtaWx5OnN5c3RlbS11aSwgc2Fucy1zZXJpZiI+PGZv
bnQgZmFjZT0ibW9ub3NwYWNlIiBjb2xvcj0iIzMzMzMzMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMy4zMzMzcHg7d2hpdGUtc3BhY2U6cHJlIj5BbHNvIEkgaGF2ZSB0b28gbWFueSBJUFNlYyBj
b25uZWN0aW9ucyBiZXR3ZWVuIGZvcnRpZ2F0ZSwgY2lzY28gZXRjLiA8L3NwYW4+PC9mb250Pjwv
ZGl2PjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuNTtmb250LWZhbWlseTpzeXN0ZW0tdWksIHNh
bnMtc2VyaWYiPjxmb250IGZhY2U9Im1vbm9zcGFjZSIgY29sb3I9IiMzMzMzMzMiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O3doaXRlLXNwYWNlOnByZSI+QW5kIHRoZWlyIG9wZXJh
dG9ycyB1c2Ugb25seSAzREVTIGFsZ29yaXRobXMgYW5kIHRoZXkgaGF2ZSBubyBpbnRlbnRpb24g
dG8gY2hhbmdlIGl0IGZvciBtZS48L3NwYW4+PC9mb250PjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUt
aGVpZ2h0OjEuNTtmb250LWZhbWlseTpzeXN0ZW0tdWksIHNhbnMtc2VyaWYiPjxmb250IGZhY2U9
Im1vbm9zcGFjZSIgY29sb3I9IiMzMzMzMzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMz
M3B4O3doaXRlLXNwYWNlOnByZSI+U28sIG5vdyBpIGhhdmUgdG8gZW5hYmxlIDNERVMgc3VwcG9y
dCBmb3IgRnJlZUJTRCAxNC4wIC48L3NwYW4+PC9mb250PjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUt
aGVpZ2h0OjEuNTtmb250LWZhbWlseTpzeXN0ZW0tdWksIHNhbnMtc2VyaWYiPjxmb250IGZhY2U9
Im1vbm9zcGFjZSIgY29sb3I9IiMzMzMzMzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMz
M3B4O3doaXRlLXNwYWNlOnByZSI+PGJyPjwvc3Bhbj48L2ZvbnQ+PC9kaXY+PGRpdiBzdHlsZT0i
bGluZS1oZWlnaHQ6MS41O2ZvbnQtZmFtaWx5OnN5c3RlbS11aSwgc2Fucy1zZXJpZiI+PGZvbnQg
ZmFjZT0ibW9ub3NwYWNlIiBjb2xvcj0iIzMzMzMzMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
My4zMzMzcHg7d2hpdGUtc3BhY2U6cHJlIj5UbyBhZGQgM0RFUyBzdXBwb3J0IGFnYWluIGkgY2hh
bmdlZCBzb21lIGZpbGVzIHNob3duIGJlbG93Ljwvc3Bhbj48L2ZvbnQ+PC9kaXY+PGRpdiBzdHls
ZT0ibGluZS1oZWlnaHQ6MS41O2ZvbnQtZmFtaWx5OnN5c3RlbS11aSwgc2Fucy1zZXJpZiI+PGZv
bnQgZmFjZT0ibW9ub3NwYWNlIiBjb2xvcj0iIzMzMzMzMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMy4zMzMzcHg7d2hpdGUtc3BhY2U6cHJlIj5JIGFtIG5vdCBzdXJlIHdoYXQgaSBkaWQgYW55
IGhlbHAgd2VsY29tZXMuPC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2IHN0eWxlPSJsaW5lLWhlaWdo
dDoxLjU7Zm9udC1mYW1pbHk6c3lzdGVtLXVpLCBzYW5zLXNlcmlmIj48Zm9udCBmYWNlPSJtb25v
c3BhY2UiIGNvbG9yPSIjMzMzMzMzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDt3
aGl0ZS1zcGFjZTpwcmUiPjxicj48L3NwYW4+PC9mb250PjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUt
aGVpZ2h0OjEuNTtmb250LWZhbWlseTpzeXN0ZW0tdWksIHNhbnMtc2VyaWYiPjxmb250IGZhY2U9
Im1vbm9zcGFjZSIgY29sb3I9IiMzMzMzMzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMz
M3B4O3doaXRlLXNwYWNlOnByZSI+aSByZXN0b3JlZCBiZWxvdyBmaWxlczo8L3NwYW4+PC9mb250
PjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuNTtmb250LWZhbWlseTpzeXN0ZW0tdWks
IHNhbnMtc2VyaWYiPjxmb250IGZhY2U9Im1vbm9zcGFjZSIgY29sb3I9IiMzMzMzMzMiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O3doaXRlLXNwYWNlOnByZSI+PGJyPjwvc3Bhbj48
L2ZvbnQ+PC9kaXY+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS41O2ZvbnQtZmFtaWx5OnN5c3Rl
bS11aSwgc2Fucy1zZXJpZiI+PGZvbnQgZmFjZT0ibW9ub3NwYWNlIiBjb2xvcj0iIzMzMzMzMyI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7d2hpdGUtc3BhY2U6cHJlIj48c3Bhbj48
YSBocmVmPSJodHRwczovL2NnaXQuZnJlZWJzZC5vcmcvc3JjL2NvbW1pdC8/aWQ9MTZhYWJiNzYx
YzBhIiByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIHRhcmdldD0iX2JsYW5rIiBz
dHlsZT0iY29sb3I6dmFyKC0taW50ZXJhY3Rpb24tbm9ybSk7dGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTtjdXJzb3I6cG9pbnRlciI+aHR0cHM6Ly9jZ2l0LmZyZWVic2Qub3JnL3NyYy9jb21taXQv
P2lkPTE2YWFiYjc2MWMwYTwvYT48L3NwYW4+PGJyPjwvc3Bhbj48L2ZvbnQ+PC9kaXY+PGRpdiBz
dHlsZT0ibGluZS1oZWlnaHQ6MS41O2ZvbnQtZmFtaWx5OnN5c3RlbS11aSwgc2Fucy1zZXJpZiI+
PGZvbnQgZmFjZT0ibW9ub3NwYWNlIiBjb2xvcj0iIzMzMzMzMyI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMy4zMzMzcHg7d2hpdGUtc3BhY2U6cHJlIj48dGFibGUgc3R5bGU9Im1hcmdpbi1ib3R0
b206MHB4O3RhYmxlLWxheW91dDphdXRvO2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZTtib3JkZXI6
MXB4IHNvbGlkIHJnYigxNzAsIDE3MCwgMTcwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyMzgsIDIz
OCwgMjM4KTtmb250LWZhbWlseTpzYW5zLXNlcmlmO3doaXRlLXNwYWNlOm5vcm1hbCI+PHRib2R5
Pjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDtwYWRkaW5nOjAuMmVtIDAu
MmVtIDAuMWVtIDAuMWVtO2JvcmRlcjpub25lO3doaXRlLXNwYWNlOm5vd3JhcCI+LXJ3LXItLXIt
LTwvdGQ+PHRkIHN0eWxlPSJmb250LXNpemU6MWVtO21hcmdpbjowcHg7cGFkZGluZzowLjJlbSAw
LjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6bm9uZSI+PGEgaHJlZj0iaHR0cHM6Ly9jZ2l0LmZyZWVi
c2Qub3JnL3NyYy9kaWZmL2xpYi9saWJpcHNlYy9wZmtleV9kdW1wLmM/aWQ9MTZhYWJiNzYxYzBh
IiByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIHRhcmdldD0iX2JsYW5rIiBzdHls
ZT0iY29sb3I6Ymx1ZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO2N1cnNvcjpwb2ludGVyIj5s
aWIvbGliaXBzZWMvcGZrZXlfZHVtcC5jPC9hPjwvdGQ+PHRkIHN0eWxlPSJmb250LXNpemU6MWVt
O21hcmdpbjowcHg7dGV4dC1hbGlnbjpyaWdodDtwYWRkaW5nOjAuMmVtIDAuMmVtIDAuMWVtIDAu
MWVtO2JvcmRlcjpub25lIj4yNTwvdGQ+PHRkIHN0eWxlPSJmb250LXNpemU6MWVtO21hcmdpbjow
cHg7cGFkZGluZzowLjJlbSAwLjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6bm9uZTt3aWR0aDo1MDBw
eDt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPjx0YWJsZSB3aWR0aD0iNzklIiBzdHlsZT0ibWFyZ2lu
LWJvdHRvbTowcHg7dGFibGUtbGF5b3V0OmF1dG87Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlO2Jv
cmRlcjpub25lIj48dGJvZHk+PHRyPjx0ZCBzdHlsZT0ibWFyZ2luOjBweDtoZWlnaHQ6N3B0O2Jh
Y2tncm91bmQtY29sb3I6cmdiKDg1LCAyMDQsIDg1KTt3aWR0aDowcHgiPjwvdGQ+PHRkIHN0eWxl
PSJtYXJnaW46MHB4O2hlaWdodDo3cHQ7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjA0LCA4NSwgODUp
O3dpZHRoOjEyNC44MTJweCI+PC90ZD48dGQgc3R5bGU9Im1hcmdpbjowcHg7aGVpZ2h0OjdwdDt3
aWR0aDoyNzAuMTg4cHgiPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PC90ZD48L3RyPjx0cj48
dGQgc3R5bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDtwYWRkaW5nOjAuMmVtIDAuMmVtIDAu
MWVtIDAuMWVtO2JvcmRlcjpub25lO3doaXRlLXNwYWNlOm5vd3JhcCI+LXJ3LXItLXItLTwvdGQ+
PHRkIHN0eWxlPSJmb250LXNpemU6MWVtO21hcmdpbjowcHg7cGFkZGluZzowLjJlbSAwLjJlbSAw
LjFlbSAwLjFlbTtib3JkZXI6bm9uZSI+PGEgaHJlZj0iaHR0cHM6Ly9jZ2l0LmZyZWVic2Qub3Jn
L3NyYy9kaWZmL3NiaW4vc2V0a2V5L3NhbXBsZS5jZj9pZD0xNmFhYmI3NjFjMGEiIHJlbD0ibm9y
ZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjpi
bHVlO3RleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7Y3Vyc29yOnBvaW50ZXIiPnNiaW4vc2V0a2V5
L3NhbXBsZS5jZjwvYT48L3RkPjx0ZCBzdHlsZT0iZm9udC1zaXplOjFlbTttYXJnaW46MHB4O3Rl
eHQtYWxpZ246cmlnaHQ7cGFkZGluZzowLjJlbSAwLjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6bm9u
ZSI+Nzk8L3RkPjx0ZCBzdHlsZT0iZm9udC1zaXplOjFlbTttYXJnaW46MHB4O3BhZGRpbmc6MC4y
ZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVyOm5vbmU7d2lkdGg6NTAwcHg7dmVydGljYWwtYWxp
Z246bWlkZGxlIj48dGFibGUgd2lkdGg9Ijc5JSIgc3R5bGU9Im1hcmdpbi1ib3R0b206MHB4O3Rh
YmxlLWxheW91dDphdXRvO2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZTtib3JkZXI6bm9uZSI+PHRi
b2R5Pjx0cj48dGQgc3R5bGU9Im1hcmdpbjowcHg7aGVpZ2h0OjdwdDtiYWNrZ3JvdW5kLWNvbG9y
OnJnYig4NSwgMjA0LCA4NSk7d2lkdGg6MTU5Ljk2OXB4Ij48L3RkPjx0ZCBzdHlsZT0ibWFyZ2lu
OjBweDtoZWlnaHQ6N3B0O2JhY2tncm91bmQtY29sb3I6cmdiKDIwNCwgODUsIDg1KTt3aWR0aDoy
MzUuMDE2cHgiPjwvdGQ+PHRkIHN0eWxlPSJtYXJnaW46MHB4O2hlaWdodDo3cHQ7d2lkdGg6MC4w
MTU2MjVweCI+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L3RkPjwvdHI+PHRyPjx0ZCBzdHls
ZT0iZm9udC1zaXplOjFlbTttYXJnaW46MHB4O3BhZGRpbmc6MC4yZW0gMC4yZW0gMC4xZW0gMC4x
ZW07Ym9yZGVyOm5vbmU7d2hpdGUtc3BhY2U6bm93cmFwIj4tcnctci0tci0tPC90ZD48dGQgc3R5
bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDtwYWRkaW5nOjAuMmVtIDAuMmVtIDAuMWVtIDAu
MWVtO2JvcmRlcjpub25lIj48YSBocmVmPSJodHRwczovL2NnaXQuZnJlZWJzZC5vcmcvc3JjL2Rp
ZmYvc2Jpbi9zZXRrZXkvc2V0a2V5Ljg/aWQ9MTZhYWJiNzYxYzBhIiByZWw9Im5vcmVmZXJyZXIg
bm9mb2xsb3cgbm9vcGVuZXIiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6Ymx1ZTt0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO2N1cnNvcjpwb2ludGVyIj5zYmluL3NldGtleS9zZXRrZXku
ODwvYT48L3RkPjx0ZCBzdHlsZT0iZm9udC1zaXplOjFlbTttYXJnaW46MHB4O3RleHQtYWxpZ246
cmlnaHQ7cGFkZGluZzowLjJlbSAwLjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6bm9uZSI+Mjk8L3Rk
Pjx0ZCBzdHlsZT0iZm9udC1zaXplOjFlbTttYXJnaW46MHB4O3BhZGRpbmc6MC4yZW0gMC4yZW0g
MC4xZW0gMC4xZW07Ym9yZGVyOm5vbmU7d2lkdGg6NTAwcHg7dmVydGljYWwtYWxpZ246bWlkZGxl
Ij48dGFibGUgd2lkdGg9Ijc5JSIgc3R5bGU9Im1hcmdpbi1ib3R0b206MHB4O3RhYmxlLWxheW91
dDphdXRvO2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZTtib3JkZXI6bm9uZSI+PHRib2R5Pjx0cj48
dGQgc3R5bGU9Im1hcmdpbjowcHg7aGVpZ2h0OjdwdDtiYWNrZ3JvdW5kLWNvbG9yOnJnYig4NSwg
MjA0LCA4NSk7d2lkdGg6MjAuMTQwNnB4Ij48L3RkPjx0ZCBzdHlsZT0ibWFyZ2luOjBweDtoZWln
aHQ6N3B0O2JhY2tncm91bmQtY29sb3I6cmdiKDIwNCwgODUsIDg1KTt3aWR0aDoxMjQuODEycHgi
PjwvdGQ+PHRkIHN0eWxlPSJtYXJnaW46MHB4O2hlaWdodDo3cHQ7d2lkdGg6MjUwLjA0N3B4Ij48
L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjwvdGQ+PC90cj48dHI+PHRkIHN0eWxlPSJmb250LXNp
emU6MWVtO21hcmdpbjowcHg7cGFkZGluZzowLjJlbSAwLjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6
bm9uZTt3aGl0ZS1zcGFjZTpub3dyYXAiPi1ydy1yLS1yLS08L3RkPjx0ZCBzdHlsZT0iZm9udC1z
aXplOjFlbTttYXJnaW46MHB4O3BhZGRpbmc6MC4yZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVy
Om5vbmUiPjxhIGhyZWY9Imh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9zcmMvZGlmZi9zYmluL3Nl
dGtleS90ZXN0LXBma2V5LmM/aWQ9MTZhYWJiNzYxYzBhIiByZWw9Im5vcmVmZXJyZXIgbm9mb2xs
b3cgbm9vcGVuZXIiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6Ymx1ZTt0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lO2N1cnNvcjpwb2ludGVyIj5zYmluL3NldGtleS90ZXN0LXBma2V5LmM8
L2E+PC90ZD48dGQgc3R5bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDt0ZXh0LWFsaWduOnJp
Z2h0O3BhZGRpbmc6MC4yZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVyOm5vbmUiPjMyPC90ZD48
dGQgc3R5bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDtwYWRkaW5nOjAuMmVtIDAuMmVtIDAu
MWVtIDAuMWVtO2JvcmRlcjpub25lO3dpZHRoOjUwMHB4O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+
PHRhYmxlIHdpZHRoPSI3OSUiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBweDt0YWJsZS1sYXlvdXQ6
YXV0bztib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym9yZGVyOm5vbmUiPjx0Ym9keT48dHI+PHRk
IHN0eWxlPSJtYXJnaW46MHB4O2hlaWdodDo3cHQ7YmFja2dyb3VuZC1jb2xvcjpyZ2IoODUsIDIw
NCwgODUpO3dpZHRoOjgwLjE3MTlweCI+PC90ZD48dGQgc3R5bGU9Im1hcmdpbjowcHg7aGVpZ2h0
OjdwdDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyMDQsIDg1LCA4NSk7d2lkdGg6ODAuMTcxOXB4Ij48
L3RkPjx0ZCBzdHlsZT0ibWFyZ2luOjBweDtoZWlnaHQ6N3B0O3dpZHRoOjIzNC42NTZweCI+PC90
ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L3RkPjwvdHI+PHRyPjx0ZCBzdHlsZT0iZm9udC1zaXpl
OjFlbTttYXJnaW46MHB4O3BhZGRpbmc6MC4yZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVyOm5v
bmU7d2hpdGUtc3BhY2U6bm93cmFwIj4tcnctci0tci0tPC90ZD48dGQgc3R5bGU9ImZvbnQtc2l6
ZToxZW07bWFyZ2luOjBweDtwYWRkaW5nOjAuMmVtIDAuMmVtIDAuMWVtIDAuMWVtO2JvcmRlcjpu
b25lIj48YSBocmVmPSJodHRwczovL2NnaXQuZnJlZWJzZC5vcmcvc3JjL2RpZmYvc2Jpbi9zZXRr
ZXkvdG9rZW4ubD9pZD0xNmFhYmI3NjFjMGEiIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29w
ZW5lciIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjpibHVlO3RleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7Y3Vyc29yOnBvaW50ZXIiPnNiaW4vc2V0a2V5L3Rva2VuLmw8L2E+PC90ZD48dGQg
c3R5bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDt0ZXh0LWFsaWduOnJpZ2h0O3BhZGRpbmc6
MC4yZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVyOm5vbmUiPjExPC90ZD48dGQgc3R5bGU9ImZv
bnQtc2l6ZToxZW07bWFyZ2luOjBweDtwYWRkaW5nOjAuMmVtIDAuMmVtIDAuMWVtIDAuMWVtO2Jv
cmRlcjpub25lO3dpZHRoOjUwMHB4O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PHRhYmxlIHdpZHRo
PSI3OSUiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBweDt0YWJsZS1sYXlvdXQ6YXV0bztib3JkZXIt
Y29sbGFwc2U6Y29sbGFwc2U7Ym9yZGVyOm5vbmUiPjx0Ym9keT48dHI+PHRkIHN0eWxlPSJtYXJn
aW46MHB4O2hlaWdodDo3cHQ7YmFja2dyb3VuZC1jb2xvcjpyZ2IoODUsIDIwNCwgODUpO3dpZHRo
OjBweCI+PC90ZD48dGQgc3R5bGU9Im1hcmdpbjowcHg7aGVpZ2h0OjdwdDtiYWNrZ3JvdW5kLWNv
bG9yOnJnYigyMDQsIDg1LCA4NSk7d2lkdGg6NTQuODkwNnB4Ij48L3RkPjx0ZCBzdHlsZT0ibWFy
Z2luOjBweDtoZWlnaHQ6N3B0O3dpZHRoOjM0MC4xMDlweCI+PC90ZD48L3RyPjwvdGJvZHk+PC90
YWJsZT48L3RkPjwvdHI+PHRyPjx0ZCBzdHlsZT0iZm9udC1zaXplOjFlbTttYXJnaW46MHB4O3Bh
ZGRpbmc6MC4yZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVyOm5vbmU7d2hpdGUtc3BhY2U6bm93
cmFwIj4tcnctci0tci0tPC90ZD48dGQgc3R5bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDtw
YWRkaW5nOjAuMmVtIDAuMmVtIDAuMWVtIDAuMWVtO2JvcmRlcjpub25lIj48YSBocmVmPSJodHRw
czovL2NnaXQuZnJlZWJzZC5vcmcvc3JjL2RpZmYvc3lzL25ldGlwc2VjL2lwc2VjLmM/aWQ9MTZh
YWJiNzYxYzBhIiByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIHRhcmdldD0iX2Js
YW5rIiBzdHlsZT0iY29sb3I6Ymx1ZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO2N1cnNvcjpw
b2ludGVyIj5zeXMvbmV0aXBzZWMvaXBzZWMuYzwvYT48L3RkPjx0ZCBzdHlsZT0iZm9udC1zaXpl
OjFlbTttYXJnaW46MHB4O3RleHQtYWxpZ246cmlnaHQ7cGFkZGluZzowLjJlbSAwLjJlbSAwLjFl
bSAwLjFlbTtib3JkZXI6bm9uZSI+NTwvdGQ+PHRkIHN0eWxlPSJmb250LXNpemU6MWVtO21hcmdp
bjowcHg7cGFkZGluZzowLjJlbSAwLjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6bm9uZTt3aWR0aDo1
MDBweDt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPjx0YWJsZSB3aWR0aD0iNzklIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbTowcHg7dGFibGUtbGF5b3V0OmF1dG87Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNl
O2JvcmRlcjpub25lIj48dGJvZHk+PHRyPjx0ZCBzdHlsZT0ibWFyZ2luOjBweDtoZWlnaHQ6N3B0
O2JhY2tncm91bmQtY29sb3I6cmdiKDg1LCAyMDQsIDg1KTt3aWR0aDowcHgiPjwvdGQ+PHRkIHN0
eWxlPSJtYXJnaW46MHB4O2hlaWdodDo3cHQ7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjA0LCA4NSwg
ODUpO3dpZHRoOjI0Ljg3NXB4Ij48L3RkPjx0ZCBzdHlsZT0ibWFyZ2luOjBweDtoZWlnaHQ6N3B0
O3dpZHRoOjM3MC4xMjVweCI+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L3RkPjwvdHI+PHRy
Pjx0ZCBzdHlsZT0iZm9udC1zaXplOjFlbTttYXJnaW46MHB4O3BhZGRpbmc6MC4yZW0gMC4yZW0g
MC4xZW0gMC4xZW07Ym9yZGVyOm5vbmU7d2hpdGUtc3BhY2U6bm93cmFwIj4tcnctci0tci0tPC90
ZD48dGQgc3R5bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDtwYWRkaW5nOjAuMmVtIDAuMmVt
IDAuMWVtIDAuMWVtO2JvcmRlcjpub25lIj48YSBocmVmPSJodHRwczovL2NnaXQuZnJlZWJzZC5v
cmcvc3JjL2RpZmYvc3lzL25ldGlwc2VjL2lwc2VjLmg/aWQ9MTZhYWJiNzYxYzBhIiByZWw9Im5v
cmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6
Ymx1ZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO2N1cnNvcjpwb2ludGVyIj5zeXMvbmV0aXBz
ZWMvaXBzZWMuaDwvYT48L3RkPjx0ZCBzdHlsZT0iZm9udC1zaXplOjFlbTttYXJnaW46MHB4O3Rl
eHQtYWxpZ246cmlnaHQ7cGFkZGluZzowLjJlbSAwLjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6bm9u
ZSI+MjwvdGQ+PHRkIHN0eWxlPSJmb250LXNpemU6MWVtO21hcmdpbjowcHg7cGFkZGluZzowLjJl
bSAwLjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6bm9uZTt3aWR0aDo1MDBweDt2ZXJ0aWNhbC1hbGln
bjptaWRkbGUiPjx0YWJsZSB3aWR0aD0iNzklIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTowcHg7dGFi
bGUtbGF5b3V0OmF1dG87Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlO2JvcmRlcjpub25lIj48dGJv
ZHk+PHRyPjx0ZCBzdHlsZT0ibWFyZ2luOjBweDtoZWlnaHQ6N3B0O2JhY2tncm91bmQtY29sb3I6
cmdiKDg1LCAyMDQsIDg1KTt3aWR0aDowcHgiPjwvdGQ+PHRkIHN0eWxlPSJtYXJnaW46MHB4O2hl
aWdodDo3cHQ7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjA0LCA4NSwgODUpO3dpZHRoOjkuODc1cHgi
PjwvdGQ+PHRkIHN0eWxlPSJtYXJnaW46MHB4O2hlaWdodDo3cHQ7d2lkdGg6Mzg1LjEyNXB4Ij48
L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjwvdGQ+PC90cj48dHI+PHRkIHN0eWxlPSJmb250LXNp
emU6MWVtO21hcmdpbjowcHg7cGFkZGluZzowLjJlbSAwLjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6
bm9uZTt3aGl0ZS1zcGFjZTpub3dyYXAiPi1ydy1yLS1yLS08L3RkPjx0ZCBzdHlsZT0iZm9udC1z
aXplOjFlbTttYXJnaW46MHB4O3BhZGRpbmc6MC4yZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVy
Om5vbmUiPjxhIGhyZWY9Imh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9zcmMvZGlmZi9zeXMvbmV0
aXBzZWMva2V5LmM/aWQ9MTZhYWJiNzYxYzBhIiByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9v
cGVuZXIiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6Ymx1ZTt0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO2N1cnNvcjpwb2ludGVyIj5zeXMvbmV0aXBzZWMva2V5LmM8L2E+PC90ZD48dGQg
c3R5bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDt0ZXh0LWFsaWduOnJpZ2h0O3BhZGRpbmc6
MC4yZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVyOm5vbmUiPjEyPC90ZD48dGQgc3R5bGU9ImZv
bnQtc2l6ZToxZW07bWFyZ2luOjBweDtwYWRkaW5nOjAuMmVtIDAuMmVtIDAuMWVtIDAuMWVtO2Jv
cmRlcjpub25lO3dpZHRoOjUwMHB4O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+PHRhYmxlIHdpZHRo
PSI3OSUiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBweDt0YWJsZS1sYXlvdXQ6YXV0bztib3JkZXIt
Y29sbGFwc2U6Y29sbGFwc2U7Ym9yZGVyOm5vbmUiPjx0Ym9keT48dHI+PHRkIHN0eWxlPSJtYXJn
aW46MHB4O2hlaWdodDo3cHQ7YmFja2dyb3VuZC1jb2xvcjpyZ2IoODUsIDIwNCwgODUpO3dpZHRo
OjBweCI+PC90ZD48dGQgc3R5bGU9Im1hcmdpbjowcHg7aGVpZ2h0OjdwdDtiYWNrZ3JvdW5kLWNv
bG9yOnJnYigyMDQsIDg1LCA4NSk7d2lkdGg6NjAuMDMxMnB4Ij48L3RkPjx0ZCBzdHlsZT0ibWFy
Z2luOjBweDtoZWlnaHQ6N3B0O3dpZHRoOjMzNC45NjlweCI+PC90ZD48L3RyPjwvdGJvZHk+PC90
YWJsZT48L3RkPjwvdHI+PHRyPjx0ZCBzdHlsZT0iZm9udC1zaXplOjFlbTttYXJnaW46MHB4O3Bh
ZGRpbmc6MC4yZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVyOm5vbmU7d2hpdGUtc3BhY2U6bm93
cmFwIj4tcnctci0tci0tPC90ZD48dGQgc3R5bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDtw
YWRkaW5nOjAuMmVtIDAuMmVtIDAuMWVtIDAuMWVtO2JvcmRlcjpub25lIj48YSBocmVmPSJodHRw
czovL2NnaXQuZnJlZWJzZC5vcmcvc3JjL2RpZmYvc3lzL25ldGlwc2VjL3hmb3JtX2FoLmM/aWQ9
MTZhYWJiNzYxYzBhIiByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIHRhcmdldD0i
X2JsYW5rIiBzdHlsZT0iY29sb3I6Ymx1ZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO2N1cnNv
cjpwb2ludGVyIj5zeXMvbmV0aXBzZWMveGZvcm1fYWguYzwvYT48L3RkPjx0ZCBzdHlsZT0iZm9u
dC1zaXplOjFlbTttYXJnaW46MHB4O3RleHQtYWxpZ246cmlnaHQ7cGFkZGluZzowLjJlbSAwLjJl
bSAwLjFlbSAwLjFlbTtib3JkZXI6bm9uZSI+MjY8L3RkPjx0ZCBzdHlsZT0iZm9udC1zaXplOjFl
bTttYXJnaW46MHB4O3BhZGRpbmc6MC4yZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVyOm5vbmU7
d2lkdGg6NTAwcHg7dmVydGljYWwtYWxpZ246bWlkZGxlIj48dGFibGUgd2lkdGg9Ijc5JSIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MHB4O3RhYmxlLWxheW91dDphdXRvO2JvcmRlci1jb2xsYXBzZTpj
b2xsYXBzZTtib3JkZXI6bm9uZSI+PHRib2R5Pjx0cj48dGQgc3R5bGU9Im1hcmdpbjowcHg7aGVp
Z2h0OjdwdDtiYWNrZ3JvdW5kLWNvbG9yOnJnYig4NSwgMjA0LCA4NSk7d2lkdGg6NS4xMjVweCI+
PC90ZD48dGQgc3R5bGU9Im1hcmdpbjowcHg7aGVpZ2h0OjdwdDtiYWNrZ3JvdW5kLWNvbG9yOnJn
YigyMDQsIDg1LCA4NSk7d2lkdGg6MTI0LjgxMnB4Ij48L3RkPjx0ZCBzdHlsZT0ibWFyZ2luOjBw
eDtoZWlnaHQ6N3B0O3dpZHRoOjI2NS4wNjJweCI+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48
L3RkPjwvdHI+PHRyPjx0ZCBzdHlsZT0iZm9udC1zaXplOjFlbTttYXJnaW46MHB4O3BhZGRpbmc6
MC4yZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVyOm5vbmU7d2hpdGUtc3BhY2U6bm93cmFwIj4t
cnctci0tci0tPC90ZD48dGQgc3R5bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDtwYWRkaW5n
OjAuMmVtIDAuMmVtIDAuMWVtIDAuMWVtO2JvcmRlcjpub25lIj48YSBocmVmPSJodHRwczovL2Nn
aXQuZnJlZWJzZC5vcmcvc3JjL2RpZmYvc3lzL25ldGlwc2VjL3hmb3JtX2VzcC5jP2lkPTE2YWFi
Yjc2MWMwYSIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIiB0YXJnZXQ9Il9ibGFu
ayIgc3R5bGU9ImNvbG9yOmJsdWU7dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTtjdXJzb3I6cG9p
bnRlciI+c3lzL25ldGlwc2VjL3hmb3JtX2VzcC5jPC9hPjwvdGQ+PHRkIHN0eWxlPSJmb250LXNp
emU6MWVtO21hcmdpbjowcHg7dGV4dC1hbGlnbjpyaWdodDtwYWRkaW5nOjAuMmVtIDAuMmVtIDAu
MWVtIDAuMWVtO2JvcmRlcjpub25lIj4yNTwvdGQ+PHRkIHN0eWxlPSJmb250LXNpemU6MWVtO21h
cmdpbjowcHg7cGFkZGluZzowLjJlbSAwLjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6bm9uZTt3aWR0
aDo1MDBweDt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPjx0YWJsZSB3aWR0aD0iNzklIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbTowcHg7dGFibGUtbGF5b3V0OmF1dG87Ym9yZGVyLWNvbGxhcHNlOmNvbGxh
cHNlO2JvcmRlcjpub25lIj48dGJvZHk+PHRyPjx0ZCBzdHlsZT0ibWFyZ2luOjBweDtoZWlnaHQ6
N3B0O2JhY2tncm91bmQtY29sb3I6cmdiKDg1LCAyMDQsIDg1KTt3aWR0aDowcHgiPjwvdGQ+PHRk
IHN0eWxlPSJtYXJnaW46MHB4O2hlaWdodDo3cHQ7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjA0LCA4
NSwgODUpO3dpZHRoOjEyNC44MTJweCI+PC90ZD48dGQgc3R5bGU9Im1hcmdpbjowcHg7aGVpZ2h0
OjdwdDt3aWR0aDoyNzAuMTg4cHgiPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PC90ZD48L3Ry
Pjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxZW07bWFyZ2luOjBweDtwYWRkaW5nOjAuMmVtIDAu
MmVtIDAuMWVtIDAuMWVtO2JvcmRlcjpub25lO3doaXRlLXNwYWNlOm5vd3JhcCI+LXJ3LXItLXIt
LTwvdGQ+PHRkIHN0eWxlPSJmb250LXNpemU6MWVtO21hcmdpbjowcHg7cGFkZGluZzowLjJlbSAw
LjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6bm9uZSI+PGEgaHJlZj0iaHR0cHM6Ly9jZ2l0LmZyZWVi
c2Qub3JnL3NyYy9kaWZmL3Vzci5iaW4vbmV0c3RhdC9pcHNlYy5jP2lkPTE2YWFiYjc2MWMwYSIg
cmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9
ImNvbG9yOmJsdWU7dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTtjdXJzb3I6cG9pbnRlciI+dXNy
LmJpbi9uZXRzdGF0L2lwc2VjLmM8L2E+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48YnI+PC9z
cGFuPjwvZm9udD48L2Rpdj48ZGl2IHN0eWxlPSJsaW5lLWhlaWdodDoxLjU7Zm9udC1mYW1pbHk6
c3lzdGVtLXVpLCBzYW5zLXNlcmlmIj48Zm9udCBmYWNlPSJtb25vc3BhY2UiIGNvbG9yPSIjMzMz
MzMzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDt3aGl0ZS1zcGFjZTpwcmUiPjxz
cGFuPjxhIGhyZWY9Imh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9zcmMvY29tbWl0Lz9pZD02Yzgw
YzMxOWVmODgiIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciIgdGFyZ2V0PSJfYmxh
bmsiIHN0eWxlPSJjb2xvcjp2YXIoLS1pbnRlcmFjdGlvbi1ub3JtKTt0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO2N1cnNvcjpwb2ludGVyIj5odHRwczovL2NnaXQuZnJlZWJzZC5vcmcvc3JjL2Nv
bW1pdC8/aWQ9NmM4MGMzMTllZjg4PC9hPjwvc3Bhbj48L3NwYW4+PC9mb250PjwvZGl2PjxkaXYg
c3R5bGU9ImxpbmUtaGVpZ2h0OjEuNTtmb250LWZhbWlseTpzeXN0ZW0tdWksIHNhbnMtc2VyaWYi
Pjxmb250IGZhY2U9Im1vbm9zcGFjZSIgY29sb3I9IiMzMzMzMzMiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTMuMzMzM3B4O3doaXRlLXNwYWNlOnByZSI+PHRhYmxlIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjBweDt0YWJsZS1sYXlvdXQ6YXV0bztib3JkZXItY29sbGFwc2U6Y29sbGFwc2U7Ym9yZGVy
OjFweCBzb2xpZCByZ2IoMTcwLCAxNzAsIDE3MCk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjM4LCAy
MzgsIDIzOCk7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt3aGl0ZS1zcGFjZTpub3JtYWwiPjx0Ym9k
eT48dHI+PHRkIHN0eWxlPSJmb250LXNpemU6MWVtO21hcmdpbjowcHg7cGFkZGluZzowLjJlbSAw
LjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6bm9uZTt3aGl0ZS1zcGFjZTpub3dyYXAiPi1ydy1yLS1y
LS08L3RkPjx0ZCBzdHlsZT0iZm9udC1zaXplOjFlbTttYXJnaW46MHB4O3BhZGRpbmc6MC4yZW0g
MC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVyOm5vbmUiPjxhIGhyZWY9Imh0dHBzOi8vY2dpdC5mcmVl
YnNkLm9yZy9zcmMvZGlmZi9zeXMvb3BlbmNyeXB0by9jcnlwdG9kZXYuYz9pZD02YzgwYzMxOWVm
ODgiIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciIgdGFyZ2V0PSJfYmxhbmsiIHN0
eWxlPSJjb2xvcjpibHVlO3RleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7Y3Vyc29yOnBvaW50ZXIi
PnN5cy9vcGVuY3J5cHRvL2NyeXB0b2Rldi5jPC9hPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+
PHRhYmxlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBweDt0YWJsZS1sYXlvdXQ6YXV0bztib3JkZXIt
Y29sbGFwc2U6Y29sbGFwc2U7Ym9yZGVyOjFweCBzb2xpZCByZ2IoMTcwLCAxNzAsIDE3MCk7YmFj
a2dyb3VuZC1jb2xvcjpyZ2IoMjM4LCAyMzgsIDIzOCk7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjt3
aGl0ZS1zcGFjZTpub3JtYWwiPjx0Ym9keT48dHI+PHRkIHN0eWxlPSJmb250LXNpemU6MWVtO21h
cmdpbjowcHg7cGFkZGluZzowLjJlbSAwLjJlbSAwLjFlbSAwLjFlbTtib3JkZXI6bm9uZTt3aGl0
ZS1zcGFjZTpub3dyYXAiPi1ydy1yLS1yLS08L3RkPjx0ZCBzdHlsZT0iZm9udC1zaXplOjFlbTtt
YXJnaW46MHB4O3BhZGRpbmc6MC4yZW0gMC4yZW0gMC4xZW0gMC4xZW07Ym9yZGVyOm5vbmUiPjxh
IGhyZWY9Imh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9zcmMvZGlmZi9zeXMvb3BlbmNyeXB0by9j
cnlwdG9kZXYuYz9pZD02YzgwYzMxOWVmODgiIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29w
ZW5lciIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjpibHVlO3RleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7Y3Vyc29yOnBvaW50ZXIiPnN5cy9vcGVuY3J5cHRvL2NyeXB0b2Rldi48L2E+aDwv
dGQ+PC90cj48L3Rib2R5PjwvdGFibGU+DQo8YnI+PC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2IHN0
eWxlPSJsaW5lLWhlaWdodDoxLjU7Zm9udC1mYW1pbHk6c3lzdGVtLXVpLCBzYW5zLXNlcmlmIj48
Zm9udCBmYWNlPSJtb25vc3BhY2UiIGNvbG9yPSIjMzMzMzMzIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEzLjMzMzNweDt3aGl0ZS1zcGFjZTpwcmUiPkNvbXBpbGVkIE5ldyBLZXJuZWwgd2l0aCB0
aGlzIGV4dHJhIG9wdGlvbnM6PC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2IHN0eWxlPSJsaW5lLWhl
aWdodDoxLjU7Zm9udC1mYW1pbHk6c3lzdGVtLXVpLCBzYW5zLXNlcmlmIj48Zm9udCBmYWNlPSJt
b25vc3BhY2UiIGNvbG9yPSIjMzMzMzMzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNw
eDt3aGl0ZS1zcGFjZTpwcmUiPjxicj48L3NwYW4+PC9mb250PjwvZGl2PjxkaXYgc3R5bGU9Imxp
bmUtaGVpZ2h0OjEuNTtmb250LWZhbWlseTpzeXN0ZW0tdWksIHNhbnMtc2VyaWYiPjxmb250IGZh
Y2U9Im1vbm9zcGFjZSIgY29sb3I9IiMzMzMzMzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu
MzMzM3B4O3doaXRlLXNwYWNlOnByZSI+PHNwYW4+IyBPV05LRVJOdjE8L3NwYW4+PGRpdj48c3Bh
bj5pbmNsdWRlIEdFTkVSSUM8L3NwYW4+PC9kaXY+PHNwYW4+aWRlbnQgT1dOS0VSTnYxPC9zcGFu
Pjxicj48L3NwYW4+PC9mb250PjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuNTtmb250
LWZhbWlseTpzeXN0ZW0tdWksIHNhbnMtc2VyaWYiPjxmb250IGZhY2U9Im1vbm9zcGFjZSIgY29s
b3I9IiMzMzMzMzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O3doaXRlLXNwYWNl
OnByZSI+PHNwYW4+PGJyPjwvc3Bhbj48L3NwYW4+PC9mb250PjwvZGl2PjxkaXYgc3R5bGU9Imxp
bmUtaGVpZ2h0OjEuNTtmb250LWZhbWlseTpzeXN0ZW0tdWksIHNhbnMtc2VyaWYiPjxmb250IGZh
Y2U9Im1vbm9zcGFjZSIgY29sb3I9IiMzMzMzMzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu
MzMzM3B4O3doaXRlLXNwYWNlOnByZSI+PHNwYW4+b3B0aW9ucyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgSVBGSVJFV0FMTDwvc3Bhbj48ZGl2PjxzcGFuPm9wdGlvbnMgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IERVTU1ZTkVUPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+b3B0aW9ucyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSVBGSVJFV0FMTF9ERUZBVUxUX1RPX0FDQ0VQVDwv
c3Bhbj48L2Rpdj48ZGl2PjxzcGFuPm9wdGlvbnMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IElQRElWRVJUPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+b3B0aW9ucyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgSVBTRUM8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5vcHRpb25zICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyBJUFNFQ19TVVBQT1JUPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+
ZGV2aWNlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjcnlwdG88L3NwYW4+PC9k
aXY+PGRpdj48c3Bhbj48YnI+PC9zcGFuPjwvZGl2PjxzcGFuPjwvc3Bhbj48L3NwYW4+PC9mb250
PjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuNTtmb250LWZhbWlseTpzeXN0ZW0tdWks
IHNhbnMtc2VyaWYiPjxmb250IGZhY2U9Im1vbm9zcGFjZSIgY29sb3I9IiMzMzMzMzMiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTMuMzMzM3B4O3doaXRlLXNwYWNlOnByZSI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxNHB4O3doaXRlLXNwYWNlOm5vcm1hbDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigy
NTUsIDI1NSwgMjU1KSI+Y2QgL3Vzci9zcmM8L3NwYW4+PGJyIHN0eWxlPSJmb250LXNpemU6MTRw
eDt3aGl0ZS1zcGFjZTpub3JtYWw7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LCAyNTUsIDI1NSki
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRweDt3aGl0ZS1zcGFjZTpub3JtYWw7YmFja2dyb3Vu
ZC1jb2xvcjpyZ2IoMjU1LCAyNTUsIDI1NSkiPm1ha2UgLWokKHN5c2N0bCAtbiBody5uY3B1KSBi
dWlsZGtlcm5lbCBLRVJOQ09ORj1PV05LRVJOdjE8L3NwYW4+PGJyPjwvc3Bhbj48L2ZvbnQ+PC9k
aXY+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS41O2ZvbnQtZmFtaWx5OnN5c3RlbS11aSwgc2Fu
cy1zZXJpZiI+PGZvbnQgZmFjZT0ibW9ub3NwYWNlIiBjb2xvcj0iIzMzMzMzMyI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7d2hpdGUtc3BhY2U6cHJlIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjE0cHg7d2hpdGUtc3BhY2U6bm9ybWFsO2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwg
MjU1LCAyNTUpIj48YnI+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9kaXY+PGRpdiBzdHlsZT0ibGlu
ZS1oZWlnaHQ6MS41O2ZvbnQtZmFtaWx5OnN5c3RlbS11aSwgc2Fucy1zZXJpZiI+QnV0IFdoZW4g
aSZuYnNwOyB0cnkgdG8gY29tcGlsZSBuZXcga2VybmVsJm5ic3A7IGl0IGdldHMgdG9vIG1hbnkg
ZXJyb3JzLjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuNTtmb250LWZhbWlseTpzeXN0
ZW0tdWksIHNhbnMtc2VyaWYiPmFueSBoZWxwIHdpbGwgYmUgYXBwcmVjaWF0ZWQgYXQgdGhpcyBw
b2ludC4uPC9kaXY+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS41O2ZvbnQtZmFtaWx5OnN5c3Rl
bS11aSwgc2Fucy1zZXJpZiI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuNTtm
b250LWZhbWlseTpzeXN0ZW0tdWksIHNhbnMtc2VyaWYiPjxiPlBhcnQgb2YgRXJyb3IgTG9nczo8
L2I+PC9kaXY+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS41O2ZvbnQtZmFtaWx5OnN5c3RlbS11
aSwgc2Fucy1zZXJpZiI+PHNwYW4+LS0gYWxsX3N1YmRpcl9jcnlwdG9kZXYgLS0tPC9zcGFuPjxk
aXY+PHNwYW4+L3Vzci9zcmMvc3lzL29wZW5jcnlwdG8vY3J5cHRvZGV2LmM6MzE0OjE2OiBlcnJv
cjogaW5jb21wYXRpYmxlIGZ1bmN0aW9uIHBvaW50ZXIgdHlwZXMgaW5pdGlhbGl6aW5nICdmb19z
dGF0X3QgKicgKGFrYSAnaW50ICgqKShzdHJ1Y3QgZmlsZSAqLCBzdHJ1Y3Qgc3RhdCAqLCBzdHJ1
Y3QgdWNyZWQgKiknKSB3aXRoIGFuIGV4cHJlc3Npb24gb2YgdHlwZSAnaW50IChzdHJ1Y3QgZmls
ZSAqLCBzdHJ1Y3Qgc3RhdCAqLCBzdHJ1Y3QgdWNyZWQgKiwgc3RydWN0IHRocmVhZCAqKScgWy1X
ZXJyb3IsLVdpbmNvbXBhdGlibGUtZnVuY3Rpb24tcG9pbnRlci10eXBlc108L3NwYW4+PC9kaXY+
PGRpdj48c3Bhbj4mbmJzcDsgJm5ic3A7IC5mb19zdGF0ID0gY3J5cHRvZl9zdGF0LDwvc3Bhbj48
L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDtefn5+fn5+fn5+fn48L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4vdXNyL3Ny
Yy9zeXMvb3BlbmNyeXB0by9jcnlwdG9kZXYuYzo0MTI6MTQ6IGVycm9yOiB1c2Ugb2YgdW5kZWNs
YXJlZCBpZGVudGlmaWVyICdlbmNfeGZvcm1fZGVzJzsgZGlkIHlvdSBtZWFuICdlbmNfeGZvcm1f
Y2NtJz88L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0
eGZvcm0gPSAmYW1wO2VuY194Zm9ybV9kZXM7PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBe
fn5+fn5+fn5+fn5+PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbmNfeGZvcm1fY2NtPC9z
cGFuPjwvZGl2PjxkaXY+PHNwYW4+L3Vzci9zcmMvc3lzL29wZW5jcnlwdG8veGZvcm1fZW5jLmg6
MTA1OjMxOiBub3RlOiAnZW5jX3hmb3JtX2NjbScgZGVjbGFyZWQgaGVyZTwvc3Bhbj48L2Rpdj48
ZGl2PjxzcGFuPmV4dGVybiBjb25zdCBzdHJ1Y3QgZW5jX3hmb3JtIGVuY194Zm9ybV9jY207PC9z
cGFuPjwvZGl2PjxkaXY+PHNwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgXjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPi91c3Ivc3JjL3N5cy9vcGVuY3J5
cHRvL2NyeXB0b2Rldi5jOjQxNToxNDogZXJyb3I6IHVzZSBvZiB1bmRlY2xhcmVkIGlkZW50aWZp
ZXIgJ2VuY194Zm9ybV8zZGVzJzwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7IHR4Zm9ybSA9ICZhbXA7ZW5jX3hmb3JtXzNkZXM7PC9zcGFuPjwvZGl2Pjxk
aXY+PHNwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBePC9zcGFuPjwvZGl2PjxzcGFuPi4uLjwvc3Bhbj48L2Rpdj48L2Rpdj48
ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jayIgc3R5bGU9ImZvbnQtZmFtaWx5
OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyI+PGJyPg0KPC9kaXY+DQo=


--b1_Vv1HplekoC6NxculTkiOrMAE8MR0iaYuigQ7xZ96I--


From nobody Tue Oct  4 13:14:04 2022
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 4MhdSy0nN2z4dqwl
	for ; Tue,  4 Oct 2022 13:14:10 +0000 (UTC)
	(envelope-from joh.hendriks@gmail.com)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MhdSx3YCBz3bM2
	for ; Tue,  4 Oct 2022 13:14:09 +0000 (UTC)
	(envelope-from joh.hendriks@gmail.com)
Received: by mail-ed1-x531.google.com with SMTP id w10so5869534edd.4
        for ; Tue, 04 Oct 2022 06:14:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:subject:from:to:content-language
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date;
        bh=efwPfhwmkKfZOFaI12vYuDlYEfc21KYHVr9uxd6a434=;
        b=Q744vDAFxmwvwmk0zwIV7yHYGUYtyaUJe/TtJN0rBiPEIrosENt2QmM3G9UO6sfsQy
         fYACZo/OIWCoMNTjxSWSbk84UE6jp47t6zEvIDsBsmn6A84y9FYcIplxpx/EKNWOm558
         BwLql0lYh+YGGc+eBe7FjV8JUlmdLh3HISEpgCB2bY1KQ3Aezm33jaZRHiXkKJMyK0l9
         XetPBEa32/I2B2CXUTQBI882+/b7sWtzXvCzWFWh0t28DI+E/o4PnMPK88OxxkSUgrgc
         HSNjrT1/DemdkzkXAGPhydbxmiZyfp6F9Z1BG8NBO+Gn5ld7P2Uif8FRRv/KKwNCXvZQ
         sIww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:subject:from:to:content-language
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date;
        bh=efwPfhwmkKfZOFaI12vYuDlYEfc21KYHVr9uxd6a434=;
        b=dMTlOk5A7Zmt9BFKHknDZ2e5Wm34C1S3yV3SZ5mf0xA+xvBV5htlKjf5jkzS9WlI2r
         RUo6qQoTshJQloX2FjeqCjUTcGL3HcdfkQvMvthpgq8Egw9/9tkjx5ZF30LV90B3tnzU
         XGMgLFZsne02FjA5yAHB2qMEuWQk39ni+PTolzpfuLC+Czj52wn1CHMHmNNVTohkM+cU
         kyEV8F8aU7dPYB9qeubvQr2W92ZFo7+WJ+8x1kYqqyV98csKRIcYuh0NiZPjZ0d87VY/
         gyMChrnUsjNXerJpRkG/8hdd5uOFch7kWdShAXz8hItsg6eVPIt1jjsYpr6RXQ6x5lgv
         7rrA==
X-Gm-Message-State: ACrzQf2CKcDU1f780GuPfx6SkkTbLInwkd6dOvPKrGo7ZOLI3xfjHM/P
	+wdax067TeyfhYXvHqhwekcVd15ZgOs=
X-Google-Smtp-Source: AMsMyM6MxlM+EGlBh0LDONly97kmLatAFAEQeMnTviP1tLHqJ0Q6YrwBqgqVaKN99RYuq9CR00sSTA==
X-Received: by 2002:aa7:c78d:0:b0:454:fe1d:8eb1 with SMTP id n13-20020aa7c78d000000b00454fe1d8eb1mr23130776eds.59.1664889245537;
        Tue, 04 Oct 2022 06:14:05 -0700 (PDT)
Received: from ?IPV6:2001:990:1:1378:b1:6b4e:d21b:6513? ([2001:990:1:1378:b1:6b4e:d21b:6513])
        by smtp.gmail.com with ESMTPSA id 12-20020a170906318c00b0078c1e174e11sm2764687ejy.136.2022.10.04.06.14.04
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 04 Oct 2022 06:14:05 -0700 (PDT)
Message-ID: 
Date: Tue, 4 Oct 2022 15:14:04 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.3.0
Content-Language: en-US
To: FreeBSD Current 
From: Johan Hendriks 
Subject: build world fails on raw_ip.c
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4MhdSx3YCBz3bM2
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Q744vDAF;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of joh.hendriks@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=joh.hendriks@gmail.com
X-Spamd-Result: default: False [-3.88 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	NEURAL_HAM_MEDIUM(-0.88)[-0.883];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TAGGED_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::531:from];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

I just updated the source today but now i get an error building world.
The old build was from yesterday which was fine!

Building /usr/obj/usr/src/amd64.amd64/sys/KRNL/raw_ip.o
cc -target x86_64-unknown-freebsd14.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe 
-fno-strict-aliasing -march=broadwell -g -nostdinc  -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-fdebug-prefix-map=./machine=/usr/src/sys/amd64/include 
-fdebug-prefix-map=./x86=/usr/src/sys/x86/include 
-fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
-Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-unknown-pragmas 
-Wno-error=tautological-compare -Wno-error=empty-body 
-Wno-error=parentheses-equality -Wno-error=unused-function 
-Wno-error=pointer-sign -Wno-error=shift-negative-value 
-Wno-address-of-packed-member -Wno-format-zero-length   -mno-aes 
-mno-avx  -std=iso9899:1999 -Werror /usr/src/sys/netinet/raw_ip.c
/usr/src/sys/netinet/raw_ip.c:811:3: error: too few arguments to 
function call, expected 4, have 2
                 IPSEC_CTLINPUT(ipv4, icmp);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/src/sys/netipsec/ipsec_support.h:222:61: note: expanded from macro 
'IPSEC_CTLINPUT'
     ipsec_kmod_ctlinput(proto ## _ipsec_support, __VA_ARGS__)
     ~~~~~~~~~~~~~~~~~~~                                     ^
/usr/src/sys/netipsec/ipsec_support.h:196:5: note: 'ipsec_kmod_ctlinput' 
declared here
int ipsec_kmod_ctlinput(struct ipsec_support * const, int,
     ^
1 error generated.
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/KRNL
.ERROR_TARGET='raw_ip.o'
.ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/sys/KRNL/raw_ip.o.meta'
.MAKE.LEVEL='2'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes verbose curdirOk=yes'
_ERROR_CMD='cc -target x86_64-unknown-freebsd14.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe 
-fno-strict-aliasing -march=broadwell -g -nostdinc  -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-fdebug-prefix-map=./machine=/usr/src/sys/amd64/include 
-fdebug-prefix-map=./x86=/usr/src/sys/x86/include 
-fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel 
-mno-red-zone -mno-mmx -mno-sse -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
-Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-unknown-pragmas 
-Wno-error=tautological-compare -Wno-error=empty-body 
-Wno-error=parentheses-equality -Wno-error=unused-function 
-Wno-error=pointer-sign -Wno-error=shift-negative-value 
-Wno-address-of-packed-member -Wno-format-zero-length   -mno-aes 
-mno-avx  -std=iso9899:1999 -Werror /usr/src/sys/netinet/raw_ip.c; 
ctfconvert -L VERSION -g raw_ip.o;'
.CURDIR='/usr/obj/usr/src/amd64.amd64/sys/KRNL'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64/sys/KRNL'
.TARGETS='all'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20220726'
PATH='/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk 
/usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk 
/etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk 
/usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk 
/usr/src/share/mk/bsd.suffixes.mk /etc/make.conf 
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk 
/etc/src.conf Makefile /usr/src/sys/conf/kern.pre.mk 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.endian.mk /usr/src/share/mk/bsd.linker.mk 
/usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/kern.post.mk 
/usr/src/sys/conf/kern.mk /dev/null'
.PATH='. /usr/obj/usr/src/amd64.amd64/sys/KRNL'
         2.21 real         2.07 user         0.14 sys

regards,
Johan Hendriks


From nobody Tue Oct  4 13:20:05 2022
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 4Mhdbs0Ywfz4drb2
	for ; Tue,  4 Oct 2022 13:20:09 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mhdbr4N2Rz3cWT
	for ; Tue,  4 Oct 2022 13:20:08 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 2A899260410;
	Tue,  4 Oct 2022 15:20:07 +0200 (CEST)
Message-ID: 
Date: Tue, 4 Oct 2022 15:20:05 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: build world fails on raw_ip.c
Content-Language: en-US
To: Johan Hendriks ,
 FreeBSD Current 
References: 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Mhdbr4N2Rz3cWT
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	TAGGED_RCPT(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 10/4/22 15:14, Johan Hendriks wrote:
> I just updated the source today but now i get an error building world.
> The old build was from yesterday which was fine!
> 
> Building /usr/obj/usr/src/amd64.amd64/sys/KRNL/raw_ip.o
> cc -target x86_64-unknown-freebsd14.0 
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe 
> -fno-strict-aliasing -march=broadwell -g -nostdinc  -I. -I/usr/src/sys 
> -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt 
> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
> -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include 
> -fdebug-prefix-map=./x86=/usr/src/sys/x86/include 
> -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel 
> -mno-red-zone -mno-mmx -mno-sse -msoft-float 
> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
> -Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes 
> -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign 
> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
> -fdiagnostics-show-option -Wno-unknown-pragmas 
> -Wno-error=tautological-compare -Wno-error=empty-body 
> -Wno-error=parentheses-equality -Wno-error=unused-function 
> -Wno-error=pointer-sign -Wno-error=shift-negative-value 
> -Wno-address-of-packed-member -Wno-format-zero-length   -mno-aes 
> -mno-avx  -std=iso9899:1999 -Werror /usr/src/sys/netinet/raw_ip.c
> /usr/src/sys/netinet/raw_ip.c:811:3: error: too few arguments to 
> function call, expected 4, have 2
>                  IPSEC_CTLINPUT(ipv4, icmp);
>                  ^~~~~~~~~~~~~~~~~~~~~~~~~~
> /usr/src/sys/netipsec/ipsec_support.h:222:61: note: expanded from macro 
> 'IPSEC_CTLINPUT'
>      ipsec_kmod_ctlinput(proto ## _ipsec_support, __VA_ARGS__)
>      ~~~~~~~~~~~~~~~~~~~                                     ^
> /usr/src/sys/netipsec/ipsec_support.h:196:5: note: 'ipsec_kmod_ctlinput' 
> declared here
> int ipsec_kmod_ctlinput(struct ipsec_support * const, int,
>      ^
> 1 error generated.
> *** Error code 1
> 

I've mailed the responsible committer.

Just do:

diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC
index 9178abba36cc..ed8045e48257 100644
--- a/sys/amd64/conf/GENERIC
+++ b/sys/amd64/conf/GENERIC
@@ -30,7 +30,7 @@ options       PREEMPTION              # Enable kernel 
thread preemption
  options        VIMAGE                  # Subsystem virtualization, 
e.g. VNET
  options        INET                    # InterNETworking
  options        INET6                   # IPv6 communications protocols
-options        IPSEC_SUPPORT           # Allow kldload of ipsec and tcpmd5
+# options      IPSEC_SUPPORT           # Allow kldload of ipsec and tcpmd5
  options                ROUTE_MPATH             # Multipath routing support
  options                FIB_ALGO                # Modular fib lookups
  options        TCP_OFFLOAD             # TCP offload



For now.

--HPS

From nobody Tue Oct  4 13:35:25 2022
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 4Mhdxm4nksz4dt29
	for ; Tue,  4 Oct 2022 13:35:40 +0000 (UTC)
	(envelope-from garyj@gmx.de)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mhdxl0KFKz3dxq
	for ; Tue,  4 Oct 2022 13:35:38 +0000 (UTC)
	(envelope-from garyj@gmx.de)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
	s=badeba3b8450; t=1664890534;
	bh=jLJhb+svF9fhHWdx9dr6fAJzJS4k/oO8xbnOkdA54nU=;
	h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References:
	 Reply-To;
	b=UbTcW//s4XM5QBO4JnLPbCPQbhNr+92n16UBh5wnWO65kQD9ME1G7r8c/3Qv/sAjh
	 MArklt0CX/JpANw0E8ZCDRmwatFtVmgdrRc3GzIdyvH8MlOBubVAuBhXiUbYrdth38
	 rlblKAGSGTDkAhL2Couy+hKH3M4B5bJNsHdWxy9c=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from ernst.home ([91.2.53.8]) by mail.gmx.net (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N6bk4-1pGiL20tCw-0183hS; Tue, 04
 Oct 2022 15:35:34 +0200
Date: Tue, 4 Oct 2022 15:35:25 +0200
From: Gary Jennejohn 
To: Hans Petter Selasky 
Cc: Johan Hendriks , FreeBSD Current
 
Subject: Re: build world fails on raw_ip.c
Message-ID: <20221004153525.7a31a62d@ernst.home>
In-Reply-To: 
References: 
	
Reply-To: garyj@gmx.de
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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:3dTqR1ndqgpW/1UTg3Ri0zz3g0yauBLs/vWsYymcGM6eFlnCA7C
 x98lSarDQMboZThqsBQZJeFWOzgFFimkBJ4lLS/Iu9fWV/rnHPt1jHnodttp2OJCXN91hql
 ZisQXlmnClKncRmSAlW2gXgHJMdmYy/aJMk+7XOmIhWdKFcW47KmNFm4R4WMeJnbFmJeQrD
 OWrngliHYKvhz4mnQM0oA==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:zaEfxePJLK0=:aFZdKKgFoBnCAEu4JFNB5A
 24UkCqBQfH6OxiSJtYrzE9p2ui2kZcfGAeJh2Q1glwi2rYZLPwcleIxlHj3lNxLpyOUmrfNu4
 Yphi8Kj4BCvHdHwOwc2+Wo77burEQUkkSK9sJBR+rE3hGB2v5kMB0MyCucS4BbTQflTgIirZw
 yzrQNcKnUAzhdboUz4mw6yoXpUF/VxW5fF8Iw+81SI2Rh9BK2aXD3S6syqtRyTqXiVEtkej4b
 94Lfa6SWHWrbG71ndSVe25wiHO0ggllSSe8YWkaj5EA/xT7GSwzNnAutwz4i4CBSvdQ7oNDfy
 InJtqECjlsjLnXJx94ct8JzRtMV/NIeHtsNdt54cqI+1+gf3zqh/q9GGTkkT8MYrZNSzCP54m
 wBgk8FVpSfoQ78JiYeZnrx350ty5ZdkhXJKGPPqRVXcrdYPkockiTGpgR2fsCaKEPkjvkDUAy
 miAbJLI/58EpqMLriLOmatOYVgK7dErFJ6WzoF53uob87S169wXlyhIEBQdYri6CvBaJ1Vy6F
 q6hPfPZPsF65YeGZK5t5PqUMN5a9VJHo4kBKkmaUqfggrikm3f9P5YXDvBfR7UZm7NgNKzcQg
 4KZ1ljEyGslHcTSAGZ2J9uK3iTELZlgPWr+IyZ/D9jPpVYy4U6YSixWcjCrioeWIyLSQx3JnO
 IXhWBW3zL1BIOemg2NafIqpoWvmLQSczx2t2/z6EFEe9BtE6YNKwAtud2kqcr5mgi7lGp525w
 R0ytMcrDS2r/YrqStkedyGVUgy7SXXa7wtzLPbQ50TQRFDv2XEtjoH2Xv9D4XyWtrGz30vypT
 HA7uzasZ4SoDSJ2ik7SFLK7YfXJLBf8rFgaFRiPFC5HclAkGUo8BwFwNOaxRHyMWK7IXpT1RZ
 I6LfRGYsOAbrcz5fLtwlarYCUJ6VgU8ZgUDJ3oubBPmhvzY/la7V6Hxsuze11AXpj6AMjKZch
 unriP5sQMLOP5mzsYe8Xx4utAj6G46YuCOL3TdUuh4pjy0FayIWk4B2b6ucr93T03u6Mkka10
 P0oNP501Y1I+GzLxfNt7ABp0dYM8MDRNV7QubkjbX+x+weAcZ7hc3jayliRiVJ5g42PjPjMvn
 wit1Eu8xrIlMQ1V5SBvAyHdinjguYORzCw3wXEznFvH4HhBlV5LNPVQ2exau74hni5iToPU9L
 EJwKQ=
X-Rspamd-Queue-Id: 4Mhdxl0KFKz3dxq
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b="UbTcW//s";
	dmarc=pass (policy=none) header.from=gmx.de;
	spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.15.18 as permitted sender) smtp.mailfrom=garyj@gmx.de
X-Spamd-Result: default: False [-2.14 / 15.00];
	DWL_DNSWL_LOW(-1.00)[gmx.net:dkim];
	NEURAL_SPAM_MEDIUM(0.96)[0.964];
	NEURAL_HAM_SHORT(-0.95)[-0.947];
	DMARC_POLICY_ALLOW(-0.50)[gmx.de,none];
	R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450];
	R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.18:from];
	NEURAL_HAM_LONG(-0.06)[-0.058];
	TAGGED_RCPT(0.00)[];
	FREEMAIL_REPLYTO(0.00)[gmx.de];
	HAS_REPLYTO(0.00)[garyj@gmx.de];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org];
	RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.18:from];
	RCPT_COUNT_THREE(0.00)[3];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	TO_DN_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmx.de];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[gmx.net:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE];
	FREEMAIL_ENVFROM(0.00)[gmx.de];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 4 Oct 2022 15:20:05 +0200
Hans Petter Selasky  wrote:

> On 10/4/22 15:14, Johan Hendriks wrote:
> > I just updated the source today but now i get an error building world.
> > The old build was from yesterday which was fine!
> >
> > Building /usr/obj/usr/src/amd64.amd64/sys/KRNL/raw_ip.o
> > cc -target x86_64-unknown-freebsd14.0 > --sysroot=3D/usr/obj/usr/src/a=
md64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe >=
 -fno-strict-aliasing -march=3Dbroadwell -g -nostdinc=A0 -I. -I/usr/src/sy=
s > -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt > -D_K=
ERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -fn=
o-omit-frame-pointer -mno-omit-leaf-frame-pointer > -fdebug-prefix-map=3D.=
/machine=3D/usr/src/sys/amd64/include > -fdebug-prefix-map=3D./x86=3D/usr/=
src/sys/x86/include > -fdebug-prefix-map=3D./i386=3D/usr/src/sys/i386/incl=
ude -mcmodel=3Dkernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fn=
o-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector > -W=
all -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-=
arith -Wcast-qual -Wundef -Wno-pointer-sign > -D__printf__=3D__freebsd_kpr=
intf__ -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-unknown-pra=
gmas > -Wno-error=3Dtautological-compare -Wno-error=3Dempty-body > -Wno-er=
ror=3Dparentheses-equality -Wno-error=3Dunused-function > -Wno-error=3Dpoi=
nter-sign -Wno-error=3Dshift-negative-value > -Wno-address-of-packed-membe=
r -Wno-format-zero-length=A0=A0 -mno-aes > -mno-avx=A0 -std=3Diso9899:1999=
 -Werror /usr/src/sys/netinet/raw_ip.c
> > /usr/src/sys/netinet/raw_ip.c:811:3: error: too few arguments to > fun=
ction call, expected 4, have 2
> >  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IPSEC_CTLINPUT(ipv4, ic=
mp);
> >  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^~~~~~~~~~~~~~~~~~~~~~~=
~~~
> > /usr/src/sys/netipsec/ipsec_support.h:222:61: note: expanded from macr=
o > 'IPSEC_CTLINPUT'
> >  =A0=A0=A0 ipsec_kmod_ctlinput(proto ## _ipsec_support, __VA_ARGS__)
> >  =A0=A0=A0 ~~~~~~~~~~~~~~~~~~~=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^
> > /usr/src/sys/netipsec/ipsec_support.h:196:5: note: 'ipsec_kmod_ctlinpu=
t' > declared here
> > int ipsec_kmod_ctlinput(struct ipsec_support * const, int,
> >  =A0=A0=A0 ^
> > 1 error generated.
> > *** Error code 1
> >
>
> I've mailed the responsible committer.
>
> Just do:
>
> diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC
> index 9178abba36cc..ed8045e48257 100644
> --- a/sys/amd64/conf/GENERIC
> +++ b/sys/amd64/conf/GENERIC
> @@ -30,7 +30,7 @@ options       PREEMPTION              # Enable kernel =
thread preemption
>   options        VIMAGE                  # Subsystem virtualization, e.g=
. VNET
>   options        INET                    # InterNETworking
>   options        INET6                   # IPv6 communications protocols
> -options        IPSEC_SUPPORT           # Allow kldload of ipsec and tcp=
md5
> +# options      IPSEC_SUPPORT           # Allow kldload of ipsec and tcp=
md5
>   options                ROUTE_MPATH             # Multipath routing sup=
port
>   options                FIB_ALGO                # Modular fib lookups
>   options        TCP_OFFLOAD             # TCP offload
>
>
>
> For now.
>

There are the usual other problems, like always assuming the every user
has INET6 defined in their kernel config file.

Here's an error I just saw:

/usr/src/sys/netinet/tcp_subr.c:136:8: error: unknown type name 'ip6proto_=
ctlinput_t'; did you mean 'ipproto_ctlinput_t'?
static ip6proto_ctlinput_t tcp6_ctlinput;
       ^~~~~~~~~~~~~~~~~~~
       ipproto_ctlinput_t
/usr/src/sys/netinet/ip_var.h:242:14: note: 'ipproto_ctlinput_t' declared =
here
typedef void    ipproto_ctlinput_t(struct icmp *);
                ^
1 error generated.
=2D-- tcp_subr.o ---
*** [tcp_subr.o] Error code 1

=2D-
Gary Jennejohn

From nobody Tue Oct  4 13:45:41 2022
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 4Mhf9X54TBz4dttG
	for ; Tue,  4 Oct 2022 13:45:52 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mhf9W404xz3gJY
	for ; Tue,  4 Oct 2022 13:45:51 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 0BB45260410;
	Tue,  4 Oct 2022 15:45:44 +0200 (CEST)
Message-ID: <17c4fa52-6707-f6cd-8de0-c72334e9c8b0@selasky.org>
Date: Tue, 4 Oct 2022 15:45:41 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: build world fails on raw_ip.c
Content-Language: en-US
To: garyj@gmx.de
Cc: Johan Hendriks ,
 FreeBSD Current 
References: 
 
 <20221004153525.7a31a62d@ernst.home>
From: Hans Petter Selasky 
In-Reply-To: <20221004153525.7a31a62d@ernst.home>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
X-Rspamd-Queue-Id: 4Mhf9W404xz3gJY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	MIME_BASE64_TEXT(0.10)[];
	R_DKIM_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[gmx.de];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TAGGED_RCPT(0.00)[];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

T24gMTAvNC8yMiAxNTozNSwgR2FyeSBKZW5uZWpvaG4gd3JvdGU6DQo+IE9uIFR1ZSwgNCBP
Y3QgMjAyMiAxNToyMDowNSArMDIwMA0KPiBIYW5zIFBldHRlciBTZWxhc2t5IDxocHNAc2Vs
YXNreS5vcmc+IHdyb3RlOg0KPiANCj4+IE9uIDEwLzQvMjIgMTU6MTQsIEpvaGFuIEhlbmRy
aWtzIHdyb3RlOg0KPj4+IEkganVzdCB1cGRhdGVkIHRoZSBzb3VyY2UgdG9kYXkgYnV0IG5v
dyBpIGdldCBhbiBlcnJvciBidWlsZGluZyB3b3JsZC4NCj4+PiBUaGUgb2xkIGJ1aWxkIHdh
cyBmcm9tIHllc3RlcmRheSB3aGljaCB3YXMgZmluZSENCj4+Pg0KPj4+IEJ1aWxkaW5nIC91
c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvc3lzL0tSTkwvcmF3X2lwLm8NCj4+PiBjYyAt
dGFyZ2V0IHg4Nl82NC11bmtub3duLWZyZWVic2QxNC4wID4gLS1zeXNyb290PS91c3Ivb2Jq
L3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wID4gLUIvdXNyL29iai91c3Ivc3JjL2FtZDY0LmFt
ZDY0L3RtcC91c3IvYmluIC1jIC1PMiAtcGlwZSA+IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1t
YXJjaD1icm9hZHdlbGwgLWcgLW5vc3RkaW5jwqAgLUkuIC1JL3Vzci9zcmMvc3lzID4gLUkv
dXNyL3NyYy9zeXMvY29udHJpYi9jay9pbmNsdWRlIC1JL3Vzci9zcmMvc3lzL2NvbnRyaWIv
bGliZmR0ID4gLURfS0VSTkVMIC1ESEFWRV9LRVJORUxfT1BUSU9OX0hFQURFUlMgLWluY2x1
ZGUgb3B0X2dsb2JhbC5oIC1mbm8tY29tbW9uID4gLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW1uby1vbWl0LWxlYWYtZnJhbWUtcG9pbnRlciA+IC1mZGVidWctcHJlZml4LW1hcD0uL21h
Y2hpbmU9L3Vzci9zcmMvc3lzL2FtZDY0L2luY2x1ZGUgPiAtZmRlYnVnLXByZWZpeC1tYXA9
Li94ODY9L3Vzci9zcmMvc3lzL3g4Ni9pbmNsdWRlID4gLWZkZWJ1Zy1wcmVmaXgtbWFwPS4v
aTM4Nj0vdXNyL3NyYy9zeXMvaTM4Ni9pbmNsdWRlIC1tY21vZGVsPWtlcm5lbCA+IC1tbm8t
cmVkLXpvbmUgLW1uby1tbXggLW1uby1zc2UgLW1zb2Z0LWZsb2F0ID4gLWZuby1hc3luY2hy
b25vdXMtdW53aW5kLXRhYmxlcyAtZmZyZWVzdGFuZGluZyAtZndyYXB2IC1mc3RhY2stcHJv
dGVjdG9yID4gLVdhbGwgLVduZXN0ZWQtZXh0ZXJucyAtV3N0cmljdC1wcm90b3R5cGVzIC1X
bWlzc2luZy1wcm90b3R5cGVzID4gLVdwb2ludGVyLWFyaXRoIC1XY2FzdC1xdWFsIC1XdW5k
ZWYgLVduby1wb2ludGVyLXNpZ24gPiAtRF9fcHJpbnRmX189X19mcmVlYnNkX2twcmludGZf
XyAtV21pc3NpbmctaW5jbHVkZS1kaXJzID4gLWZkaWFnbm9zdGljcy1zaG93LW9wdGlvbiAt
V25vLXVua25vd24tcHJhZ21hcyA+IC1Xbm8tZXJyb3I9dGF1dG9sb2dpY2FsLWNvbXBhcmUg
LVduby1lcnJvcj1lbXB0eS1ib2R5ID4gLVduby1lcnJvcj1wYXJlbnRoZXNlcy1lcXVhbGl0
eSAtV25vLWVycm9yPXVudXNlZC1mdW5jdGlvbiA+IC1Xbm8tZXJyb3I9cG9pbnRlci1zaWdu
IC1Xbm8tZXJyb3I9c2hpZnQtbmVnYXRpdmUtdmFsdWUgPiAtV25vLWFkZHJlc3Mtb2YtcGFj
a2VkLW1lbWJlciAtV25vLWZvcm1hdC16ZXJvLWxlbmd0aMKgwqAgLW1uby1hZXMgPiAtbW5v
LWF2eMKgIC1zdGQ9aXNvOTg5OToxOTk5IC1XZXJyb3IgL3Vzci9zcmMvc3lzL25ldGluZXQv
cmF3X2lwLmMNCj4+PiAvdXNyL3NyYy9zeXMvbmV0aW5ldC9yYXdfaXAuYzo4MTE6MzogZXJy
b3I6IHRvbyBmZXcgYXJndW1lbnRzIHRvID4gZnVuY3Rpb24gY2FsbCwgZXhwZWN0ZWQgNCwg
aGF2ZSAyDQo+Pj4gICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgSVBTRUNfQ1RM
SU5QVVQoaXB2NCwgaWNtcCk7DQo+Pj4gICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgXn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn4NCj4+PiAvdXNyL3NyYy9zeXMvbmV0aXBz
ZWMvaXBzZWNfc3VwcG9ydC5oOjIyMjo2MTogbm90ZTogZXhwYW5kZWQgZnJvbSBtYWNybyA+
ICdJUFNFQ19DVExJTlBVVCcNCj4+PiAgIMKgwqDCoCBpcHNlY19rbW9kX2N0bGlucHV0KHBy
b3RvICMjIF9pcHNlY19zdXBwb3J0LCBfX1ZBX0FSR1NfXykNCj4+PiAgIMKgwqDCoCB+fn5+
fn5+fn5+fn5+fn5+fn5+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIF4NCj4+PiAvdXNyL3NyYy9zeXMv
bmV0aXBzZWMvaXBzZWNfc3VwcG9ydC5oOjE5Njo1OiBub3RlOiAnaXBzZWNfa21vZF9jdGxp
bnB1dCcgPiBkZWNsYXJlZCBoZXJlDQo+Pj4gaW50IGlwc2VjX2ttb2RfY3RsaW5wdXQoc3Ry
dWN0IGlwc2VjX3N1cHBvcnQgKiBjb25zdCwgaW50LA0KPj4+ICAgwqDCoMKgIF4NCj4+PiAx
IGVycm9yIGdlbmVyYXRlZC4NCj4+PiAqKiogRXJyb3IgY29kZSAxDQo+Pj4NCj4+DQo+PiBJ
J3ZlIG1haWxlZCB0aGUgcmVzcG9uc2libGUgY29tbWl0dGVyLg0KPj4NCj4+IEp1c3QgZG86
DQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9jb25mL0dFTkVSSUMgYi9zeXMvYW1k
NjQvY29uZi9HRU5FUklDDQo+PiBpbmRleCA5MTc4YWJiYTM2Y2MuLmVkODA0NWU0ODI1NyAx
MDA2NDQNCj4+IC0tLSBhL3N5cy9hbWQ2NC9jb25mL0dFTkVSSUMNCj4+ICsrKyBiL3N5cy9h
bWQ2NC9jb25mL0dFTkVSSUMNCj4+IEBAIC0zMCw3ICszMCw3IEBAIG9wdGlvbnMgICAgICAg
UFJFRU1QVElPTiAgICAgICAgICAgICAgIyBFbmFibGUga2VybmVsIHRocmVhZCBwcmVlbXB0
aW9uDQo+PiAgICBvcHRpb25zICAgICAgICBWSU1BR0UgICAgICAgICAgICAgICAgICAjIFN1
YnN5c3RlbSB2aXJ0dWFsaXphdGlvbiwgZS5nLiBWTkVUDQo+PiAgICBvcHRpb25zICAgICAg
ICBJTkVUICAgICAgICAgICAgICAgICAgICAjIEludGVyTkVUd29ya2luZw0KPj4gICAgb3B0
aW9ucyAgICAgICAgSU5FVDYgICAgICAgICAgICAgICAgICAgIyBJUHY2IGNvbW11bmljYXRp
b25zIHByb3RvY29scw0KPj4gLW9wdGlvbnMgICAgICAgIElQU0VDX1NVUFBPUlQgICAgICAg
ICAgICMgQWxsb3cga2xkbG9hZCBvZiBpcHNlYyBhbmQgdGNwbWQ1DQo+PiArIyBvcHRpb25z
ICAgICAgSVBTRUNfU1VQUE9SVCAgICAgICAgICAgIyBBbGxvdyBrbGRsb2FkIG9mIGlwc2Vj
IGFuZCB0Y3BtZDUNCj4+ICAgIG9wdGlvbnMgICAgICAgICAgICAgICAgUk9VVEVfTVBBVEgg
ICAgICAgICAgICAgIyBNdWx0aXBhdGggcm91dGluZyBzdXBwb3J0DQo+PiAgICBvcHRpb25z
ICAgICAgICAgICAgICAgIEZJQl9BTEdPICAgICAgICAgICAgICAgICMgTW9kdWxhciBmaWIg
bG9va3Vwcw0KPj4gICAgb3B0aW9ucyAgICAgICAgVENQX09GRkxPQUQgICAgICAgICAgICAg
IyBUQ1Agb2ZmbG9hZA0KPj4NCj4+DQo+Pg0KPj4gRm9yIG5vdy4NCj4+DQo+IA0KPiBUaGVy
ZSBhcmUgdGhlIHVzdWFsIG90aGVyIHByb2JsZW1zLCBsaWtlIGFsd2F5cyBhc3N1bWluZyB0
aGUgZXZlcnkgdXNlcg0KPiBoYXMgSU5FVDYgZGVmaW5lZCBpbiB0aGVpciBrZXJuZWwgY29u
ZmlnIGZpbGUuDQo+IA0KPiBIZXJlJ3MgYW4gZXJyb3IgSSBqdXN0IHNhdzoNCj4gDQo+IC91
c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9zdWJyLmM6MTM2Ojg6IGVycm9yOiB1bmtub3duIHR5
cGUgbmFtZSAnaXA2cHJvdG9fY3RsaW5wdXRfdCc7IGRpZCB5b3UgbWVhbiAnaXBwcm90b19j
dGxpbnB1dF90Jz8NCj4gc3RhdGljIGlwNnByb3RvX2N0bGlucHV0X3QgdGNwNl9jdGxpbnB1
dDsNCj4gICAgICAgICBefn5+fn5+fn5+fn5+fn5+fn5+DQo+ICAgICAgICAgaXBwcm90b19j
dGxpbnB1dF90DQo+IC91c3Ivc3JjL3N5cy9uZXRpbmV0L2lwX3Zhci5oOjI0MjoxNDogbm90
ZTogJ2lwcHJvdG9fY3RsaW5wdXRfdCcgZGVjbGFyZWQgaGVyZQ0KPiB0eXBlZGVmIHZvaWQg
ICAgaXBwcm90b19jdGxpbnB1dF90KHN0cnVjdCBpY21wICopOw0KPiAgICAgICAgICAgICAg
ICAgIF4NCj4gMSBlcnJvciBnZW5lcmF0ZWQuDQo+IC0tLSB0Y3Bfc3Vici5vIC0tLQ0KPiAq
KiogW3RjcF9zdWJyLm9dIEVycm9yIGNvZGUgMQ0KPiANCj4gLS0NCj4gR2FyeSBKZW5uZWpv
aG4NCg0KSSB0aGluayB0aGlzIHNob3VsZCBmaXggaXQgZm9yIG5vdy4gV2lsbCBsZXQgR2xl
YiByZXZpZXcgd2hlbiBoZSdzIGJhY2sgDQppbiB0aGUgb2ZmaWNlIGFnYWluLg0KDQpodHRw
czovL2NnaXQuZnJlZWJzZC5vcmcvc3JjL2NvbW1pdC8/aWQ9OWY2OWMwYjg3ZGEzZmFhMDJh
YmNlZGI2OTY4OWIxYWIxZWRmNTcxYQ0KDQotLUhQUw0K

From nobody Tue Oct  4 13:49:36 2022
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 4MhfFw0jSdz4dvGx
	for ; Tue,  4 Oct 2022 13:49:40 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MhfFv3QTlz3hbZ
	for ; Tue,  4 Oct 2022 13:49:39 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 0F9EF260410;
	Tue,  4 Oct 2022 15:49:38 +0200 (CEST)
Message-ID: 
Date: Tue, 4 Oct 2022 15:49:36 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: build world fails on raw_ip.c
Content-Language: en-US
To: garyj@gmx.de
Cc: Johan Hendriks ,
 FreeBSD Current 
References: 
 
 <20221004153525.7a31a62d@ernst.home>
From: Hans Petter Selasky 
In-Reply-To: <20221004153525.7a31a62d@ernst.home>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
X-Rspamd-Queue-Id: 4MhfFv3QTlz3hbZ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MIME_BASE64_TEXT(0.10)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org];
	R_DKIM_NA(0.00)[];
	FREEMAIL_TO(0.00)[gmx.de];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TAGGED_RCPT(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[selasky.org];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

T24gMTAvNC8yMiAxNTozNSwgR2FyeSBKZW5uZWpvaG4gd3JvdGU6DQo+IE9uIFR1ZSwgNCBP
Y3QgMjAyMiAxNToyMDowNSArMDIwMA0KPiBIYW5zIFBldHRlciBTZWxhc2t5IDxocHNAc2Vs
YXNreS5vcmc+IHdyb3RlOg0KPiANCj4+IE9uIDEwLzQvMjIgMTU6MTQsIEpvaGFuIEhlbmRy
aWtzIHdyb3RlOg0KPj4+IEkganVzdCB1cGRhdGVkIHRoZSBzb3VyY2UgdG9kYXkgYnV0IG5v
dyBpIGdldCBhbiBlcnJvciBidWlsZGluZyB3b3JsZC4NCj4+PiBUaGUgb2xkIGJ1aWxkIHdh
cyBmcm9tIHllc3RlcmRheSB3aGljaCB3YXMgZmluZSENCj4+Pg0KPj4+IEJ1aWxkaW5nIC91
c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvc3lzL0tSTkwvcmF3X2lwLm8NCj4+PiBjYyAt
dGFyZ2V0IHg4Nl82NC11bmtub3duLWZyZWVic2QxNC4wID4gLS1zeXNyb290PS91c3Ivb2Jq
L3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wID4gLUIvdXNyL29iai91c3Ivc3JjL2FtZDY0LmFt
ZDY0L3RtcC91c3IvYmluIC1jIC1PMiAtcGlwZSA+IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1t
YXJjaD1icm9hZHdlbGwgLWcgLW5vc3RkaW5jwqAgLUkuIC1JL3Vzci9zcmMvc3lzID4gLUkv
dXNyL3NyYy9zeXMvY29udHJpYi9jay9pbmNsdWRlIC1JL3Vzci9zcmMvc3lzL2NvbnRyaWIv
bGliZmR0ID4gLURfS0VSTkVMIC1ESEFWRV9LRVJORUxfT1BUSU9OX0hFQURFUlMgLWluY2x1
ZGUgb3B0X2dsb2JhbC5oIC1mbm8tY29tbW9uID4gLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIg
LW1uby1vbWl0LWxlYWYtZnJhbWUtcG9pbnRlciA+IC1mZGVidWctcHJlZml4LW1hcD0uL21h
Y2hpbmU9L3Vzci9zcmMvc3lzL2FtZDY0L2luY2x1ZGUgPiAtZmRlYnVnLXByZWZpeC1tYXA9
Li94ODY9L3Vzci9zcmMvc3lzL3g4Ni9pbmNsdWRlID4gLWZkZWJ1Zy1wcmVmaXgtbWFwPS4v
aTM4Nj0vdXNyL3NyYy9zeXMvaTM4Ni9pbmNsdWRlIC1tY21vZGVsPWtlcm5lbCA+IC1tbm8t
cmVkLXpvbmUgLW1uby1tbXggLW1uby1zc2UgLW1zb2Z0LWZsb2F0ID4gLWZuby1hc3luY2hy
b25vdXMtdW53aW5kLXRhYmxlcyAtZmZyZWVzdGFuZGluZyAtZndyYXB2IC1mc3RhY2stcHJv
dGVjdG9yID4gLVdhbGwgLVduZXN0ZWQtZXh0ZXJucyAtV3N0cmljdC1wcm90b3R5cGVzIC1X
bWlzc2luZy1wcm90b3R5cGVzID4gLVdwb2ludGVyLWFyaXRoIC1XY2FzdC1xdWFsIC1XdW5k
ZWYgLVduby1wb2ludGVyLXNpZ24gPiAtRF9fcHJpbnRmX189X19mcmVlYnNkX2twcmludGZf
XyAtV21pc3NpbmctaW5jbHVkZS1kaXJzID4gLWZkaWFnbm9zdGljcy1zaG93LW9wdGlvbiAt
V25vLXVua25vd24tcHJhZ21hcyA+IC1Xbm8tZXJyb3I9dGF1dG9sb2dpY2FsLWNvbXBhcmUg
LVduby1lcnJvcj1lbXB0eS1ib2R5ID4gLVduby1lcnJvcj1wYXJlbnRoZXNlcy1lcXVhbGl0
eSAtV25vLWVycm9yPXVudXNlZC1mdW5jdGlvbiA+IC1Xbm8tZXJyb3I9cG9pbnRlci1zaWdu
IC1Xbm8tZXJyb3I9c2hpZnQtbmVnYXRpdmUtdmFsdWUgPiAtV25vLWFkZHJlc3Mtb2YtcGFj
a2VkLW1lbWJlciAtV25vLWZvcm1hdC16ZXJvLWxlbmd0aMKgwqAgLW1uby1hZXMgPiAtbW5v
LWF2eMKgIC1zdGQ9aXNvOTg5OToxOTk5IC1XZXJyb3IgL3Vzci9zcmMvc3lzL25ldGluZXQv
cmF3X2lwLmMNCj4+PiAvdXNyL3NyYy9zeXMvbmV0aW5ldC9yYXdfaXAuYzo4MTE6MzogZXJy
b3I6IHRvbyBmZXcgYXJndW1lbnRzIHRvID4gZnVuY3Rpb24gY2FsbCwgZXhwZWN0ZWQgNCwg
aGF2ZSAyDQo+Pj4gICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgSVBTRUNfQ1RM
SU5QVVQoaXB2NCwgaWNtcCk7DQo+Pj4gICDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgXn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn4NCj4+PiAvdXNyL3NyYy9zeXMvbmV0aXBz
ZWMvaXBzZWNfc3VwcG9ydC5oOjIyMjo2MTogbm90ZTogZXhwYW5kZWQgZnJvbSBtYWNybyA+
ICdJUFNFQ19DVExJTlBVVCcNCj4+PiAgIMKgwqDCoCBpcHNlY19rbW9kX2N0bGlucHV0KHBy
b3RvICMjIF9pcHNlY19zdXBwb3J0LCBfX1ZBX0FSR1NfXykNCj4+PiAgIMKgwqDCoCB+fn5+
fn5+fn5+fn5+fn5+fn5+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIF4NCj4+PiAvdXNyL3NyYy9zeXMv
bmV0aXBzZWMvaXBzZWNfc3VwcG9ydC5oOjE5Njo1OiBub3RlOiAnaXBzZWNfa21vZF9jdGxp
bnB1dCcgPiBkZWNsYXJlZCBoZXJlDQo+Pj4gaW50IGlwc2VjX2ttb2RfY3RsaW5wdXQoc3Ry
dWN0IGlwc2VjX3N1cHBvcnQgKiBjb25zdCwgaW50LA0KPj4+ICAgwqDCoMKgIF4NCj4+PiAx
IGVycm9yIGdlbmVyYXRlZC4NCj4+PiAqKiogRXJyb3IgY29kZSAxDQo+Pj4NCj4+DQo+PiBJ
J3ZlIG1haWxlZCB0aGUgcmVzcG9uc2libGUgY29tbWl0dGVyLg0KPj4NCj4+IEp1c3QgZG86
DQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9jb25mL0dFTkVSSUMgYi9zeXMvYW1k
NjQvY29uZi9HRU5FUklDDQo+PiBpbmRleCA5MTc4YWJiYTM2Y2MuLmVkODA0NWU0ODI1NyAx
MDA2NDQNCj4+IC0tLSBhL3N5cy9hbWQ2NC9jb25mL0dFTkVSSUMNCj4+ICsrKyBiL3N5cy9h
bWQ2NC9jb25mL0dFTkVSSUMNCj4+IEBAIC0zMCw3ICszMCw3IEBAIG9wdGlvbnMgICAgICAg
UFJFRU1QVElPTiAgICAgICAgICAgICAgIyBFbmFibGUga2VybmVsIHRocmVhZCBwcmVlbXB0
aW9uDQo+PiAgICBvcHRpb25zICAgICAgICBWSU1BR0UgICAgICAgICAgICAgICAgICAjIFN1
YnN5c3RlbSB2aXJ0dWFsaXphdGlvbiwgZS5nLiBWTkVUDQo+PiAgICBvcHRpb25zICAgICAg
ICBJTkVUICAgICAgICAgICAgICAgICAgICAjIEludGVyTkVUd29ya2luZw0KPj4gICAgb3B0
aW9ucyAgICAgICAgSU5FVDYgICAgICAgICAgICAgICAgICAgIyBJUHY2IGNvbW11bmljYXRp
b25zIHByb3RvY29scw0KPj4gLW9wdGlvbnMgICAgICAgIElQU0VDX1NVUFBPUlQgICAgICAg
ICAgICMgQWxsb3cga2xkbG9hZCBvZiBpcHNlYyBhbmQgdGNwbWQ1DQo+PiArIyBvcHRpb25z
ICAgICAgSVBTRUNfU1VQUE9SVCAgICAgICAgICAgIyBBbGxvdyBrbGRsb2FkIG9mIGlwc2Vj
IGFuZCB0Y3BtZDUNCj4+ICAgIG9wdGlvbnMgICAgICAgICAgICAgICAgUk9VVEVfTVBBVEgg
ICAgICAgICAgICAgIyBNdWx0aXBhdGggcm91dGluZyBzdXBwb3J0DQo+PiAgICBvcHRpb25z
ICAgICAgICAgICAgICAgIEZJQl9BTEdPICAgICAgICAgICAgICAgICMgTW9kdWxhciBmaWIg
bG9va3Vwcw0KPj4gICAgb3B0aW9ucyAgICAgICAgVENQX09GRkxPQUQgICAgICAgICAgICAg
IyBUQ1Agb2ZmbG9hZA0KPj4NCj4+DQo+Pg0KPj4gRm9yIG5vdy4NCj4+DQo+IA0KPiBUaGVy
ZSBhcmUgdGhlIHVzdWFsIG90aGVyIHByb2JsZW1zLCBsaWtlIGFsd2F5cyBhc3N1bWluZyB0
aGUgZXZlcnkgdXNlcg0KPiBoYXMgSU5FVDYgZGVmaW5lZCBpbiB0aGVpciBrZXJuZWwgY29u
ZmlnIGZpbGUuDQo+IA0KPiBIZXJlJ3MgYW4gZXJyb3IgSSBqdXN0IHNhdzoNCj4gDQo+IC91
c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9zdWJyLmM6MTM2Ojg6IGVycm9yOiB1bmtub3duIHR5
cGUgbmFtZSAnaXA2cHJvdG9fY3RsaW5wdXRfdCc7IGRpZCB5b3UgbWVhbiAnaXBwcm90b19j
dGxpbnB1dF90Jz8NCj4gc3RhdGljIGlwNnByb3RvX2N0bGlucHV0X3QgdGNwNl9jdGxpbnB1
dDsNCj4gICAgICAgICBefn5+fn5+fn5+fn5+fn5+fn5+DQo+ICAgICAgICAgaXBwcm90b19j
dGxpbnB1dF90DQo+IC91c3Ivc3JjL3N5cy9uZXRpbmV0L2lwX3Zhci5oOjI0MjoxNDogbm90
ZTogJ2lwcHJvdG9fY3RsaW5wdXRfdCcgZGVjbGFyZWQgaGVyZQ0KPiB0eXBlZGVmIHZvaWQg
ICAgaXBwcm90b19jdGxpbnB1dF90KHN0cnVjdCBpY21wICopOw0KPiAgICAgICAgICAgICAg
ICAgIF4NCj4gMSBlcnJvciBnZW5lcmF0ZWQuDQo+IC0tLSB0Y3Bfc3Vici5vIC0tLQ0KPiAq
KiogW3RjcF9zdWJyLm9dIEVycm9yIGNvZGUgMQ0KPiANCj4gLS0NCj4gR2FyeSBKZW5uZWpv
aG4NCj4gDQoNCkknbGwgbGVhdmUgZml4aW5nIHRoZSBMSU5ULU5PSU5FVDYgZm9yIEdsZWIu
IFNlZW1zIGxpa2UgaXQgbmVlZHMgYSBiaXQgDQptb3JlIGNoYW5nZXMuDQoNCkF0IGxlYXN0
IExJTlQgYW5kIEdFTkVSSUMgaXMgZmluZS4NCg0KLS1IUFMNCg==

From nobody Tue Oct  4 13:59:51 2022
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 4MhfTl3t0hz4dwHY
	for ; Tue,  4 Oct 2022 13:59:55 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MhfTk6YG6z3kXM
	for ; Tue,  4 Oct 2022 13:59:54 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id B8145260410;
	Tue,  4 Oct 2022 15:59:53 +0200 (CEST)
Message-ID: <077ca487-2a5c-fba4-513b-9b34322fe547@selasky.org>
Date: Tue, 4 Oct 2022 15:59:51 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: build world fails on raw_ip.c
Content-Language: en-US
From: Hans Petter Selasky 
To: garyj@gmx.de
Cc: Johan Hendriks ,
 FreeBSD Current 
References: 
 
 <20221004153525.7a31a62d@ernst.home>
 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4MhfTk6YG6z3kXM
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_TO(0.00)[gmx.de];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	R_DKIM_NA(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TAGGED_RCPT(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[selasky.org];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On 10/4/22 15:49, Hans Petter Selasky wrote:
> On 10/4/22 15:35, Gary Jennejohn wrote:
>> On Tue, 4 Oct 2022 15:20:05 +0200
>> Hans Petter Selasky  wrote:
>>
>>> On 10/4/22 15:14, Johan Hendriks wrote:
>>>> I just updated the source today but now i get an error building world.
>>>> The old build was from yesterday which was fine!
>>>>
>>>> Building /usr/obj/usr/src/amd64.amd64/sys/KRNL/raw_ip.o
>>>> cc -target x86_64-unknown-freebsd14.0 > 
>>>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > 
>>>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe > 
>>>> -fno-strict-aliasing -march=broadwell -g -nostdinc  -I. 
>>>> -I/usr/src/sys > -I/usr/src/sys/contrib/ck/include 
>>>> -I/usr/src/sys/contrib/libfdt > -D_KERNEL 
>>>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > 
>>>> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > 
>>>> -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include > 
>>>> -fdebug-prefix-map=./x86=/usr/src/sys/x86/include > 
>>>> -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel 
>>>> > -mno-red-zone -mno-mmx -mno-sse -msoft-float > 
>>>> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv 
>>>> -fstack-protector > -Wall -Wnested-externs -Wstrict-prototypes 
>>>> -Wmissing-prototypes > -Wpointer-arith -Wcast-qual -Wundef 
>>>> -Wno-pointer-sign > -D__printf__=__freebsd_kprintf__ 
>>>> -Wmissing-include-dirs > -fdiagnostics-show-option 
>>>> -Wno-unknown-pragmas > -Wno-error=tautological-compare 
>>>> -Wno-error=empty-body > -Wno-error=parentheses-equality 
>>>> -Wno-error=unused-function > -Wno-error=pointer-sign 
>>>> -Wno-error=shift-negative-value > -Wno-address-of-packed-member 
>>>> -Wno-format-zero-length   -mno-aes > -mno-avx  -std=iso9899:1999 
>>>> -Werror /usr/src/sys/netinet/raw_ip.c
>>>> /usr/src/sys/netinet/raw_ip.c:811:3: error: too few arguments to > 
>>>> function call, expected 4, have 2
>>>>                   IPSEC_CTLINPUT(ipv4, icmp);
>>>>                   ^~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> /usr/src/sys/netipsec/ipsec_support.h:222:61: note: expanded from 
>>>> macro > 'IPSEC_CTLINPUT'
>>>>       ipsec_kmod_ctlinput(proto ## _ipsec_support, __VA_ARGS__)
>>>>       ~~~~~~~~~~~~~~~~~~~                                     ^
>>>> /usr/src/sys/netipsec/ipsec_support.h:196:5: note: 
>>>> 'ipsec_kmod_ctlinput' > declared here
>>>> int ipsec_kmod_ctlinput(struct ipsec_support * const, int,
>>>>       ^
>>>> 1 error generated.
>>>> *** Error code 1
>>>>
>>>
>>> I've mailed the responsible committer.
>>>
>>> Just do:
>>>
>>> diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC
>>> index 9178abba36cc..ed8045e48257 100644
>>> --- a/sys/amd64/conf/GENERIC
>>> +++ b/sys/amd64/conf/GENERIC
>>> @@ -30,7 +30,7 @@ options       PREEMPTION              # Enable 
>>> kernel thread preemption
>>>    options        VIMAGE                  # Subsystem virtualization, 
>>> e.g. VNET
>>>    options        INET                    # InterNETworking
>>>    options        INET6                   # IPv6 communications 
>>> protocols
>>> -options        IPSEC_SUPPORT           # Allow kldload of ipsec and 
>>> tcpmd5
>>> +# options      IPSEC_SUPPORT           # Allow kldload of ipsec and 
>>> tcpmd5
>>>    options                ROUTE_MPATH             # Multipath routing 
>>> support
>>>    options                FIB_ALGO                # Modular fib lookups
>>>    options        TCP_OFFLOAD             # TCP offload
>>>
>>>
>>>
>>> For now.
>>>
>>
>> There are the usual other problems, like always assuming the every user
>> has INET6 defined in their kernel config file.
>>
>> Here's an error I just saw:
>>
>> /usr/src/sys/netinet/tcp_subr.c:136:8: error: unknown type name 
>> 'ip6proto_ctlinput_t'; did you mean 'ipproto_ctlinput_t'?
>> static ip6proto_ctlinput_t tcp6_ctlinput;
>>         ^~~~~~~~~~~~~~~~~~~
>>         ipproto_ctlinput_t
>> /usr/src/sys/netinet/ip_var.h:242:14: note: 'ipproto_ctlinput_t' 
>> declared here
>> typedef void    ipproto_ctlinput_t(struct icmp *);
>>                  ^
>> 1 error generated.
>> --- tcp_subr.o ---
>> *** [tcp_subr.o] Error code 1
>>
>> -- 
>> Gary Jennejohn
>>
> 
> I'll leave fixing the LINT-NOINET6 for Gleb. Seems like it needs a bit 
> more changes.
> 
> At least LINT and GENERIC is fine.
> 
> --HPS

Fixed too:
https://cgit.freebsd.org/src/commit/?id=c2a808b977dd61c0d69d878cd1bef6b016114d14

Was trivial.

--HPS


From nobody Tue Oct  4 15:58:23 2022
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 4Mhj6T6y7Qz4f84V
	for ; Tue,  4 Oct 2022 15:58:25 +0000 (UTC)
	(envelope-from jhb@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mhj6T6BgFz3xkH;
	Tue,  4 Oct 2022 15:58:25 +0000 (UTC)
	(envelope-from jhb@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1664899105;
	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=9yDpAy3INkVUN9eQzDrm75O6dYjsM8SJZzCt1RganQ8=;
	b=v8Xwjt7RVmkv8qtSzVp0kq0EW//gj1Xd6qYCi0OsIq+jo5g60MbNLDLpQhq2DDLR/xrMG3
	zrz2Pa1hRrNG37v6+pCi3Zk85OLpffZ/MsdU4h19AIFh9p+bM04gWZuEXCi+dtc5Ujf2pW
	QIaNgPa6T6wI5gan+Nn7PblUo6UTwHEUnZLXLjjyEdvcd1lkNyA34x+z1jlnjsqsA1PmpZ
	MuHrI175vvZ9w18hlzZ93Snz0/g8Pm17Y7su2GMWUG9r6dJr0l3zPqhyKr79K5haOGcGdJ
	quYCQ615mvEmrL0KEgd78A/5M3zTjdAhr5ccn/X9F2OaNqdAfDnqYBHAgkxamQ==
Received: from [IPV6:2601:648:8684:ad0:c138:fd94:ebf2:bb32] (unknown [IPv6:2601:648:8684:ad0:c138:fd94:ebf2:bb32])
	(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: jhb)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mhj6T3JJRz1MwG;
	Tue,  4 Oct 2022 15:58:25 +0000 (UTC)
	(envelope-from jhb@FreeBSD.org)
Message-ID: <79536835-6ebe-4bad-c5b7-71632323cbb9@FreeBSD.org>
Date: Tue, 4 Oct 2022 08:58:23 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.13.1
Content-Language: en-US
To: alfadev ,
 "freebsd-current@FreeBSD.org" 
References: 
From: John Baldwin 
Subject: Re: How to Enable support for IPsec deprecated algorithms: 3DES,
 MD5-HMAC
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1664899105;
	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=9yDpAy3INkVUN9eQzDrm75O6dYjsM8SJZzCt1RganQ8=;
	b=tRWFGKMNrl/C8C4g1mdQ3UXW71LaGBypsuTXxBwIGkMqibJjqmHqbrURDEJuePyIgD/BCX
	V9YjP5awzgNoCD2CVZisDXKKpRwOuJFf6gA9h4whlr3x/d3/O6FmEJ+ZdT1U9/qUpm8XLB
	lut7FByRkxCEJ405+tLXRwsgbO7rwdoVv11T7kZyLcW/sUVuXIMAAwao3Fsap+fcNCch8O
	bsMmwzXMYvRixWjhuNcVas6rDbqeom/Kf9cXpFIZgOb26cwPyuxXvGzt0naHCcPLErEoxL
	6gGBY1ufK37NKUbhEgW3tX4G5cufebOsCbzwXlmgilZ5HEXldok0snu6hDWi2A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664899105; a=rsa-sha256; cv=none;
	b=QrUT4Kp3YXCVCZBpzgdOnWsgoPi8l0kfU8gnWccv5ooMfdABonriSELgpt11VK86RgPdYG
	dqEHKy/UGq+9J34xHixJcyO1uyQi4w052t1gCsreb9YJIVh1G77U0Xhrj7ZFR2RTncxkC/
	lKPIkRK4Qxszv9vqsG5F3tqwUy6LnAkGYqKneSTpdeQms8veJUOBe3TMwCjSTYAWK+k+cZ
	cP4Uvo1lPXiXUYFdP4BImuGdp9OLNxjrAdphbzqor7m+gutSHK+7ch/zQvGiIJh0B7Uarg
	RM1zfUOGTaImSIf0vLwhSqKKfoTZ9fPzhtMYJiNcZNWsrt5iucyPuemVCB5eoQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 10/4/22 1:53 AM, alfadev wrote:
> Hi, i am trying to move my gateway from FreeBSD 11.0 to FreeBSD 14.0 to use
> newly added ipfw table lookup for mac addresses (https://reviews.freebsd.org/D35103)
> 
> Also I have too many IPSec connections between fortigate, cisco etc.
> And their operators use only 3DES algorithms and they have no intention to change it for me.
> So, now i have to enable 3DES support for FreeBSD 14.0 .
> 
> To add 3DES support again i changed some files shown below.
> I am not sure what i did any help welcomes.

You do not want to just restore the files as-is.  You instead want to revert some of the
diffs from the first commit.  The second commit for /dev/crypto doesn't matter for IPsec
and you can ignore it.

However, you will need to also partially revert commit 0e00c709d7f1cdaeb584d244df9534bcdd0ac527
which removes DES and 3DES from OCF itself.  This is what removed enc_xform_des for example.

-- 
John Baldwin

From nobody Wed Oct  5 14:03:59 2022
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 4MjGXB6Fbsz4fJ01
	for ; Wed,  5 Oct 2022 14:04:10 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MjGX92Bvlz3XV8
	for ; Wed,  5 Oct 2022 14:04:09 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.155] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id A9F522604CD
	for ; Wed,  5 Oct 2022 16:04:00 +0200 (CEST)
Message-ID: <9673a0b1-e6b0-8cef-18bd-d630f0e28724@selasky.org>
Date: Wed, 5 Oct 2022 16:03:59 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: Accessibility in the FreeBSD installer and console
Content-Language: en-US
From: Hans Petter Selasky 
To: freebsd-current@freebsd.org
References: <080B179E-359E-4796-BFC8-0AAC65089100@googlemail.com>
 <788EF362-E06B-4BA9-BDDB-E550D35E21CB@freebsd.org>
 <4B9142D0-626B-43B0-A8EF-A71CB655E080@googlemail.com>
 
 
 <97b63c7e-0d34-f92f-19da-09cacfd02ef4@selasky.org>
In-Reply-To: <97b63c7e-0d34-f92f-19da-09cacfd02ef4@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MjGX92Bvlz3XV8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	DMARC_NA(0.00)[selasky.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 7/18/22 14:46, Hans Petter Selasky wrote:
> Hi,
> 
> There are three work in progress patches pending:
> 
> 1) Updates for kernel
> https://reviews.freebsd.org/D35754
> 
> 2) Updates for beep
> https://reviews.freebsd.org/D35772
> 
> 3) New vtspeakd daemon
> https://reviews.freebsd.org/D35776
> 
> Please test if you can!
> 
> Feedback is welcome.
> 
> --HPS
> 

All patches are now updated containing new and interesting features!

Please test!

--HPS

From nobody Fri Oct  7 07:48:08 2022
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 4MkL5V3MZrz4fbj7
	for ; Fri,  7 Oct 2022 07:48:14 +0000 (UTC)
	(envelope-from alfadev@protonmail.com)
Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25])
	(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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MkL5T2TWCz3N28;
	Fri,  7 Oct 2022 07:48:13 +0000 (UTC)
	(envelope-from alfadev@protonmail.com)
Date: Fri, 07 Oct 2022 07:48:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=protonmail3; t=1665128890; x=1665388090;
	bh=9qDlBFQpt0OO7aZg0pwuGeZ3rJMwPCsPMisbL4g9c2Q=;
	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;
	b=GbbriR0N1HlFa3gySwmuqBWYXO6fqumWU94FueyFjKOtcpv7VCf02x7Ned+XruvWV
	 8pzPZYZrY7c+jAqWFEbfOdlH0A4HHEAMbEiGJk+/hR16m9oIOwQB9l8y8ifneaJ9pc
	 7rP7LuVEXHOFBCsvAVI+DmD1TrTFdNFQsroYiLavFQnnYZ8Di0cpuJYiu+LHRzynNq
	 p/FE5ksXUUIB6dabyB+oJLiNm0cek4kXpnD6uTg2PXoN6yGVzSebiViuVqYDKd8ERn
	 MvP/+B+IfcoUMx1QEwb3m9DCTkSUKKJ/aA0lVAhF1SKUgb3PCDK7Xf51XYn1aQXkBY
	 vrVnU4BZeBxuw==
To: John Baldwin 
From: alfadev 
Cc: "freebsd-current@FreeBSD.org" 
Subject: Re: How to Enable support for IPsec deprecated algorithms: 3DES, MD5-HMAC
Message-ID: 
In-Reply-To: <79536835-6ebe-4bad-c5b7-71632323cbb9@FreeBSD.org>
References:  <79536835-6ebe-4bad-c5b7-71632323cbb9@FreeBSD.org>
Feedback-ID: 37008931:user:proton
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-Queue-Id: 4MkL5T2TWCz3N28
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=GbbriR0N;
	dmarc=pass (policy=quarantine) header.from=protonmail.com;
	spf=pass (mx1.freebsd.org: domain of alfadev@protonmail.com designates 185.70.43.25 as permitted sender) smtp.mailfrom=alfadev@protonmail.com
X-Spamd-Result: default: False [-3.91 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	NEURAL_HAM_SHORT(-0.92)[-0.918];
	DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine];
	R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail3];
	R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	RCVD_COUNT_ZERO(0.00)[0];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[protonmail.com];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[protonmail.com:+];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[protonmail.com];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


> You do not want to just restore the files as-is. You instead want to reve=
rt some of the
> diffs from the first commit. The second commit for /dev/crypto doesn't ma=
tter for IPsec
> and you can ignore it.
>=20
> However, you will need to also partially revert commit 0e00c709d7f1cdaeb5=
84d244df9534bcdd0ac527
> which removes DES and 3DES from OCF itself. This is what removed enc_xfor=
m_des for example.
>=20
> --
> John Baldwin

Hi, I have limited knowledge i, tried to revert commit 0e00c709d7f1cdaeb584=
d244df9534bcdd0ac527
but it returned fatal: bad object 0e00c709d...
Instead i changed all files before that commit but no luck i got too many  =
build errors.

Could you help me at this point? How can i revert to that commit and enable=
 3des support?




From nobody Mon Oct 10 10:37:13 2022
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 4MmFjv1FNtz4f6q2
	for ; Mon, 10 Oct 2022 10:37:55 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
Received: from mail.oetec.com (mail.oetec.com [108.160.241.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.oetec.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MmFjt21Jhz3ky7
	for ; Mon, 10 Oct 2022 10:37:54 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
X-Spam-Status: No
X-oetec-MailScanner-From: dclarke@blastwave.org
X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=-3.096, required 6, autolearn=not spam, ALL_TRUSTED -1.00,
	BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10,
	DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, URIBL_BLOCKED 0.00,
	URIBL_DBL_BLOCKED_OPENDNS 0.00, URIBL_ZEN_BLOCKED_OPENDNS 0.00,
	WEIRD_QUOTING 0.00)
X-oetec-MailScanner: Found to be clean
X-oetec-MailScanner-ID: 29AAbDEf005041
X-oetec-MailScanner-Information: Please contact oetec for more information
Received: from [172.16.35.2] (cpeac202e7325b3-cmac202e7325b0.cpe.net.cable.rogers.com [99.253.170.241])
	(authenticated bits=0)
	by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 29AAbDEf005041
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT)
	for ; Mon, 10 Oct 2022 06:37:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org;
	s=default; t=1665398235;
	bh=Y0CCZJD/++iq/CuSfcpwAs2gQvsHo6s6d4HkCMIGKZI=;
	h=Date:To:From:Subject:From;
	b=cJIFNeucmH0h5huW//OdY/qJRdz0joDvfeNi9Mt7E9ntg3ElelMdtNbZmboIWZFlp
	 3DKWfm2jC+piRd1sRLTFBx3GbpMHmJewLAc1YYBKqdy4PK/Ll61SOv+7WLC8RYcQbt
	 wozIRnT+X4V1rPEDReAUH8RoWqqrE+vLGeyeCBkCTuIeKzJr5gBuuG02uAP/5Mt+35
	 EJRU6LmoAq4NNKS+ONxkx5mceWNFLN7XPL+dBLrx84QaU3os09C89SkeVfTW7nnQ3O
	 K3K45ov9tZBaVZj3HRB+Dhft0XMMtMBtADBWPIFMtmq7T1WZGqAaWx87dNqkigxNW0
	 Ad5HINVOyIJ2Q==
Message-ID: <4a476b1c-74e4-9cb8-17a4-202c81b2da1d@blastwave.org>
Date: Mon, 10 Oct 2022 10:37:13 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
To: FreeBSD CURRENT 
Content-Language: en-US
From: Dennis Clarke 
Subject: Has anyone tried to build QEMU from ports lately?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MmFjt21Jhz3ky7
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=blastwave.org header.s=default header.b=cJIFNeuc;
	dmarc=pass (policy=quarantine) header.from=blastwave.org;
	spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org
X-Spamd-Result: default: False [-3.70 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine];
	RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	R_SPF_ALLOW(-0.20)[+a:c];
	R_DKIM_ALLOW(-0.20)[blastwave.org:s=default];
	RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA];
	MIME_TRACE(0.00)[0:+];
	DKIM_TRACE(0.00)[blastwave.org:+];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


On :

phobos#
phobos# uname -apKU
FreeBSD phobos 14.0-CURRENT FreeBSD 14.0-CURRENT #14 
main-n258340-497cdf9673e: Sun Oct  2 09:51:14 GMT 2022 
root@phobos:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400072 
1400072
phobos#


Seems to fail in a pretty consistent fashion :

.
.
.
[5633/6772] Compiling C object libqemu-arm-bsd-user.fa.p/bsd-user_mmap.c.o
[5634/6772] Compiling C object libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o
FAILED: libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o
cc -m64 -mcx16 -Ilibqemu-arm-bsd-user.fa.p -I. -I.. -Itarget/arm 
-I../target/arm -I../common-user/host/x86_64 -I../bsd-user/include 
-Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-user/host/x86_64 
-Ibsd-user -I../bsd-user -I../bsd-user/arm -Iqapi -Itrace -Iui 
-Iui/shader -I/usr/local/include/capstone 
-I/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb 
-I/usr/local/include -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall 
-Winvalid-pch -std=gnu11 -O0 -g -iquote . -iquote 
/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb 
-iquote 
/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/include 
-iquote 
/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/tcg/i386 
-pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k 
-Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs 
-Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides 
-Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int 
-Wno-typedef-redefinition -Wno-tautological-type-limit-compare 
-Wno-psabi -fstack-protector-strong -O2 -pipe -fstack-protector-strong 
-fno-strict-aliasing '-DPREFIX=\""/usr/local\""' -fPIE -DNEED_CPU_H 
'-DCONFIG_TARGET="arm-bsd-user-config-target.h"' 
'-DCONFIG_DEVICES="arm-bsd-user-config-devices.h"' -MD -MQ 
libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -MF 
libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o.d -o 
libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -c ../bsd-user/signal.c
In file included from ../bsd-user/signal.c:27:
In file included from ../bsd-user/host/x86_64/host-signal.h:14:
In file included from /usr/include/vm/pmap.h:92:
/usr/include/machine/pmap.h:452:2: error: fields must have a constant 
size: 'variable length array in structure' extension will never be supported
         PV_CHUNK_HEADER
         ^
/usr/include/machine/pmap.h:448:12: note: expanded from macro 
'PV_CHUNK_HEADER'
         uint64_t                pc_map[_NPCM];  /* bitmap; 1 = free */  \
                                 ^
/usr/include/machine/pmap.h:456:2: error: fields must have a constant 
size: 'variable length array in structure' extension will never be supported
         PV_CHUNK_HEADER
         ^
/usr/include/machine/pmap.h:448:12: note: expanded from macro 
'PV_CHUNK_HEADER'
         uint64_t                pc_map[_NPCM];  /* bitmap; 1 = free */  \
                                 ^
2 errors generated.
ninja: build stopped: subcommand failed.
gmake[3]: *** [Makefile:162: run-ninja] Error 1
gmake[3]: Leaving directory 
'/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/build'
gmake[2]: *** [GNUmakefile:11: all] Error 2
gmake[2]: Leaving directory 
'/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb'
*** Error code 2

Stop.
make[1]: stopped in /usr/ports/emulators/qemu-devel
*** Error code 1

Stop.
make: stopped in /usr/ports/emulators/qemu-devel
phobos#
phobos# pwd
/usr/ports/emulators/qemu-devel
phobos#

Possibly a problem with -linotify or who knows what ?

Also see :

   https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg01280.html

In any case, something feels wrong here.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From nobody Mon Oct 10 16:56:23 2022
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 4MmQ6s3lrSz4fn7b
	for ; Mon, 10 Oct 2022 16:56:37 +0000 (UTC)
	(envelope-from wlosh@bsdimp.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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MmQ6r4Hsmz4Hp0
	for ; Mon, 10 Oct 2022 16:56:36 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ed1-x530.google.com with SMTP id a13so16786532edj.0
        for ; Mon, 10 Oct 2022 09:56:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=D3+uOyd+V1CXS+qW/PqXdQm8mdFxC6S7u3QkknTaueE=;
        b=UI3WBChdn8DZ0heAVfu+sy4b+vzYL7Pyr7x1zpHQi4MNMUbekfQebogAIc3IJc0dAD
         Ecb+ssJF3BOybolLTOWzil65+Tx9vWqnaaDwBm/Rv0BWDRMI47ozbUejH1+vX4GgVDU7
         IKSn8ylXHqa5fTgx8EybyHb9l6qzZMTPUdT2EFn85ZbT2qyDbVPDwVCY63pZk4nZEjFX
         M5laQ48+F3CShg6tjSaVzLnSSvQC5ObL/l+yDB9GYpwXW2Ac+hIX+iiO9iglYk21OAH+
         3V3qwdg7HtdpN4yp2tHJKfyA0m5ds3E6+Tfa8rbQ/DrIoCxJ2c9+d5HI2dKRLzMUOHcy
         wRpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=D3+uOyd+V1CXS+qW/PqXdQm8mdFxC6S7u3QkknTaueE=;
        b=AUDofAtuZQbVWWyoykbdlf6KL0g1/n8m5zDPZ9rs0AQxGn6VxCRCtTNt4yrgpArBmf
         ABHmrhqumiJLGqMGILRxxwx2eSPrNfK5VQX9uxFoTis1siCZcROQyOj7FQnqyfigMPr1
         ZVIfqGmXsgbRBsSlZJhbaHjxyT81CBQJCUXSUK+quGeN13JdvYDaYAGeaeBs75fV4kw/
         pA58oKnxDLune6N96lPNmnbSqO6pX1GWd7YaLvcMlTMXp79W4RtEiuFEyClGD0nOXcvo
         hLX/3y2R495t1myj6ykrLXKeY0ACRM3iVxsYSQpuGZHRccXQfaKuStT2wVvsjxZUHyCs
         VktA==
X-Gm-Message-State: ACrzQf2jmmyTMHrQyWnKj+B8H0ouejieogJocWq5hJBK2XwczESSu0H7
	x2sdqVzHu0jSgho6KP5ZYk+P2zgC2xySdYU8um4E+Eu3HEs=
X-Google-Smtp-Source: AMsMyM7Wm86GRBaa0YspzxaKe1oZf73l7F0l2TSWoQoOrRTbKzGG0esaMX/Bl/FD+e0gNiD6H3hCfVgpfDq/Cstszc8=
X-Received: by 2002:a05:6402:2682:b0:45a:d14:38f2 with SMTP id
 w2-20020a056402268200b0045a0d1438f2mr18342350edd.48.1665420994886; Mon, 10
 Oct 2022 09:56:34 -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: <4a476b1c-74e4-9cb8-17a4-202c81b2da1d@blastwave.org>
In-Reply-To: <4a476b1c-74e4-9cb8-17a4-202c81b2da1d@blastwave.org>
From: Warner Losh 
Date: Mon, 10 Oct 2022 10:56:23 -0600
Message-ID: 
Subject: Re: Has anyone tried to build QEMU from ports lately?
To: Dennis Clarke 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000cd554a05eab10a60"
X-Rspamd-Queue-Id: 4MmQ6r4Hsmz4Hp0
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=UI3WBChd;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::530) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000cd554a05eab10a60
Content-Type: text/plain; charset="UTF-8"

I know what's causing this problem. I'll resolve.

tl/dr: _pv_entry.h depends on sys/param.h being included before its use.

Warner

On Mon, Oct 10, 2022 at 4:38 AM Dennis Clarke  wrote:

>
> On :
>
> phobos#
> phobos# uname -apKU
> FreeBSD phobos 14.0-CURRENT FreeBSD 14.0-CURRENT #14
> main-n258340-497cdf9673e: Sun Oct  2 09:51:14 GMT 2022
> root@phobos:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400072
> 1400072
> phobos#
>
>
> Seems to fail in a pretty consistent fashion :
>
> .
> .
> .
> [5633/6772] Compiling C object libqemu-arm-bsd-user.fa.p/bsd-user_mmap.c.o
> [5634/6772] Compiling C object
> libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o
> FAILED: libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o
> cc -m64 -mcx16 -Ilibqemu-arm-bsd-user.fa.p -I. -I.. -Itarget/arm
> -I../target/arm -I../common-user/host/x86_64 -I../bsd-user/include
> -Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-user/host/x86_64
> -Ibsd-user -I../bsd-user -I../bsd-user/arm -Iqapi -Itrace -Iui
> -Iui/shader -I/usr/local/include/capstone
> -I/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb
>
> -I/usr/local/include -I/usr/local/include/glib-2.0
> -I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall
> -Winvalid-pch -std=gnu11 -O0 -g -iquote . -iquote
> /usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb
>
> -iquote
> /usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/include
>
> -iquote
> /usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/tcg/i386
>
> -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings
> -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv
> -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k
> -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs
> -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides
> -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int
> -Wno-typedef-redefinition -Wno-tautological-type-limit-compare
> -Wno-psabi -fstack-protector-strong -O2 -pipe -fstack-protector-strong
> -fno-strict-aliasing '-DPREFIX=\""/usr/local\""' -fPIE -DNEED_CPU_H
> '-DCONFIG_TARGET="arm-bsd-user-config-target.h"'
> '-DCONFIG_DEVICES="arm-bsd-user-config-devices.h"' -MD -MQ
> libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -MF
> libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o.d -o
> libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -c ../bsd-user/signal.c
> In file included from ../bsd-user/signal.c:27:
> In file included from ../bsd-user/host/x86_64/host-signal.h:14:
> In file included from /usr/include/vm/pmap.h:92:
> /usr/include/machine/pmap.h:452:2: error: fields must have a constant
> size: 'variable length array in structure' extension will never be
> supported
>          PV_CHUNK_HEADER
>          ^
> /usr/include/machine/pmap.h:448:12: note: expanded from macro
> 'PV_CHUNK_HEADER'
>          uint64_t                pc_map[_NPCM];  /* bitmap; 1 = free */  \
>                                  ^
> /usr/include/machine/pmap.h:456:2: error: fields must have a constant
> size: 'variable length array in structure' extension will never be
> supported
>          PV_CHUNK_HEADER
>          ^
> /usr/include/machine/pmap.h:448:12: note: expanded from macro
> 'PV_CHUNK_HEADER'
>          uint64_t                pc_map[_NPCM];  /* bitmap; 1 = free */  \
>                                  ^
> 2 errors generated.
> ninja: build stopped: subcommand failed.
> gmake[3]: *** [Makefile:162: run-ninja] Error 1
> gmake[3]: Leaving directory
>
> '/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/build'
> gmake[2]: *** [GNUmakefile:11: all] Error 2
> gmake[2]: Leaving directory
>
> '/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb'
> *** Error code 2
>
> Stop.
> make[1]: stopped in /usr/ports/emulators/qemu-devel
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/emulators/qemu-devel
> phobos#
> phobos# pwd
> /usr/ports/emulators/qemu-devel
> phobos#
>
> Possibly a problem with -linotify or who knows what ?
>
> Also see :
>
>    https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg01280.html
>
> In any case, something feels wrong here.
>
>
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
> GreyBeard and suspenders optional
>
>

--000000000000cd554a05eab10a60
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I know what's causing this problem. I'll resolve.<=
div>
tl/dr: _pv_entry.h depends on sys/param.h being included=
 before its use.

Warner

On Mon, Oct 10, 2022=
 at 4:38 AM Dennis Clarke <dcla=
rke@blastwave.org> wrote:


On :



phobos#

phobos# uname -apKU

FreeBSD phobos 14.0-CURRENT FreeBSD 14.0-CURRENT #14 

main-n258340-497cdf9673e: Sun Oct=C2=A0 2 09:51:14 GMT 2022 

root@phobos:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400072 
1400072

phobos#





Seems to fail in a pretty consistent fashion :



.

.

.

[5633/6772] Compiling C object libqemu-arm-bsd-user.fa.p/bsd-user_mmap.c.o<=
br>
[5634/6772] Compiling C object libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.=
o

FAILED: libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o

cc -m64 -mcx16 -Ilibqemu-arm-bsd-user.fa.p -I. -I.. -Itarget/arm 

-I../target/arm -I../common-user/host/x86_64 -I../bsd-user/include 

-Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-user/host/x86_64 

-Ibsd-user -I../bsd-user -I../bsd-user/arm -Iqapi -Itrace -Iui 

-Iui/shader -I/usr/local/include/capstone 

-I/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcd=
d1b165edb 

-I/usr/local/include -I/usr/local/include/glib-2.0 

-I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall 

-Winvalid-pch -std=3Dgnu11 -O0 -g -iquote . -iquote 

/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1=
b165edb 

-iquote 

/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1=
b165edb/include 

-iquote 

/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1=
b165edb/tcg/i386 

-pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=3D64 -D_LARGEFILE_SOURCE 

-Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings 

-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 

-Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k 

-Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs 

-Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides 

-Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int 
-Wno-typedef-redefinition -Wno-tautological-type-limit-compare 

-Wno-psabi -fstack-protector-strong -O2 -pipe -fstack-protector-strong 

-fno-strict-aliasing '-DPREFIX=3D\""/usr/local\""&#=
39; -fPIE -DNEED_CPU_H 

'-DCONFIG_TARGET=3D"arm-bsd-user-config-target.h"' 

'-DCONFIG_DEVICES=3D"arm-bsd-user-config-devices.h"' -MD =
-MQ 

libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -MF 

libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o.d -o 

libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -c ../bsd-user/signal.c

In file included from ../bsd-user/signal.c:27:

In file included from ../bsd-user/host/x86_64/host-signal.h:14:

In file included from /usr/include/vm/pmap.h:92:

/usr/include/machine/pmap.h:452:2: error: fields must have a constant 

size: 'variable length array in structure' extension will never be =
supported

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PV_CHUNK_HEADER

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^

/usr/include/machine/pmap.h:448:12: note: expanded from macro 

'PV_CHUNK_HEADER'

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint64_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 pc_map[_NPCM];=C2=A0 /* bitmap; 1 =3D free */=C2=
=A0 \

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^

/usr/include/machine/pmap.h:456:2: error: fields must have a constant 

size: 'variable length array in structure' extension will never be =
supported

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PV_CHUNK_HEADER

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^

/usr/include/machine/pmap.h:448:12: note: expanded from macro 

'PV_CHUNK_HEADER'

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint64_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 pc_map[_NPCM];=C2=A0 /* bitmap; 1 =3D free */=C2=
=A0 \

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^

2 errors generated.

ninja: build stopped: subcommand failed.

gmake[3]: *** [Makefile:162: run-ninja] Error 1

gmake[3]: Leaving directory 

'/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004=
dcdd1b165edb/build'

gmake[2]: *** [GNUmakefile:11: all] Error 2

gmake[2]: Leaving directory 

'/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004=
dcdd1b165edb'

*** Error code 2



Stop.

make[1]: stopped in /usr/ports/emulators/qemu-devel

*** Error code 1



Stop.

make: stopped in /usr/ports/emulators/qemu-devel

phobos#

phobos# pwd

/usr/ports/emulators/qemu-devel

phobos#



Possibly a problem with -linotify or who knows what ?



Also see :



=C2=A0 =C2=A0https://lists.non=
gnu.org/archive/html/qemu-devel/2022-10/msg01280.html



In any case, something feels wrong here.





-- 

Dennis Clarke

RISC-V/SPARC/PPC/ARM/CISC

UNIX and Linux spoken

GreyBeard and suspenders optional






--000000000000cd554a05eab10a60--

From nobody Mon Oct 10 17:53:29 2022
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 4MmRNl5KHPz4ddx0
	for ; Mon, 10 Oct 2022 17:53:43 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MmRNk5H64z4QQS
	for ; Mon, 10 Oct 2022 17:53:42 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ed1-x52a.google.com with SMTP id l22so16935081edj.5
        for ; Mon, 10 Oct 2022 10:53:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Z0Ow4Zx9Hxxp0D8Fnp+VY1s22nP6Wgs195pWjI6zoH0=;
        b=IZrCI+p1yTQ2OK0wbsnK37m/ptFUsbBCTPppbMW3pmXpnZqjy0P6lihmLXcMO5ljsy
         J9hP7hlpGegYXWM02vJyU97UTs3k9zSyrEBbAEtEhavuBwi06/8+/sLf9WIO2NOyBsVr
         KG60oM17EVSVd9zhJO38ZhFZmqTl3/vqFW7OXKyHm9eQdN7xIcDL+BJHC7+zLFqY5JMv
         xx+efCWgi3hNX/vm8CD+7CBnlP1TuU60NzKZVumsPwxNEyxiWUjN5//zhLyhucIsSSpW
         AuEZRYwq4Kos6jYDQf2RvQcmPG4N96ueUQ60NoY+KruofrjwxiwJsf4slp1kCp8FZPXZ
         yJyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Z0Ow4Zx9Hxxp0D8Fnp+VY1s22nP6Wgs195pWjI6zoH0=;
        b=jg6hNbFmgvX81cF84RhoBV2PQFwTyEKnqNaS4KPM9X57jJ+D1D6HkP4inMJUwPbvjR
         TMXsET05S2QP4TRalt/rytv3K1WjQd+lcjRVJT7EACHyRKjWaBlaHDT81E0VDFRmvnW+
         3buWqgJghDD+YVTNT8XlrRYbS46iO8ZHMM3jDltkWNCv5GdfHTJV3r9n7cT48LORdxa9
         ZSjv7O8CKp0tSy0MLFR3fEVtFie5Wx7wexLkBfw6lWs3SIf7YZoy85cdeGm9Deiq0kW5
         Cff4HpozpjyeGNvQaUs9zSEZHb3C/yPlbQ8+P64ZLOcdpi7QIIOsRlpQHtC5xlNVOh+d
         5bKw==
X-Gm-Message-State: ACrzQf2WtqJWZa1O4V3/xavItPRklVXyKZveE1hpfoSZp8wWAN+llNke
	tOrcTPU1FL9SJRh0LI14ivGY+D/BfNzf4nE2IzRdCw==
X-Google-Smtp-Source: AMsMyM7kiYzqUsqKXHXWZPSgsuaEdxInGlVDwr1lpPiLbVk3QeQk5DkMajbiy9WKaEnuUPcUXDbCpOGMmjJGM7+vbpE=
X-Received: by 2002:a05:6402:2696:b0:45a:9264:64d8 with SMTP id
 w22-20020a056402269600b0045a926464d8mr14021198edd.154.1665424421497; Mon, 10
 Oct 2022 10:53:41 -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: <4a476b1c-74e4-9cb8-17a4-202c81b2da1d@blastwave.org> 
In-Reply-To: 
From: Warner Losh 
Date: Mon, 10 Oct 2022 11:53:29 -0600
Message-ID: 
Subject: Re: Has anyone tried to build QEMU from ports lately?
To: Dennis Clarke 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000000b46f205eab1d741"
X-Rspamd-Queue-Id: 4MmRNk5H64z4QQS
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=IZrCI+p1;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::52a) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000000b46f205eab1d741
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 10, 2022 at 10:56 AM Warner Losh  wrote:

> I know what's causing this problem. I'll resolve.
>
> tl/dr: _pv_entry.h depends on sys/param.h being included before its use.
>

https://reviews.freebsd.org/D36927 fixes it by making sys/_pv_entry.h more
self-contained and less reliant on param.h pollution. The kernel includes
that
everywhere it's used, but userland is more hit or miss because
machine/pmap.h
isn't a well defined interface, but is needed for some things sometimes.

Warner


> Warner
>
> On Mon, Oct 10, 2022 at 4:38 AM Dennis Clarke 
> wrote:
>
>>
>> On :
>>
>> phobos#
>> phobos# uname -apKU
>> FreeBSD phobos 14.0-CURRENT FreeBSD 14.0-CURRENT #14
>> main-n258340-497cdf9673e: Sun Oct  2 09:51:14 GMT 2022
>> root@phobos:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400072
>> 1400072
>> phobos#
>>
>>
>> Seems to fail in a pretty consistent fashion :
>>
>> .
>> .
>> .
>> [5633/6772] Compiling C object libqemu-arm-bsd-user.fa.p/bsd-user_mmap.c.o
>> [5634/6772] Compiling C object
>> libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o
>> FAILED: libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o
>> cc -m64 -mcx16 -Ilibqemu-arm-bsd-user.fa.p -I. -I.. -Itarget/arm
>> -I../target/arm -I../common-user/host/x86_64 -I../bsd-user/include
>> -Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-user/host/x86_64
>> -Ibsd-user -I../bsd-user -I../bsd-user/arm -Iqapi -Itrace -Iui
>> -Iui/shader -I/usr/local/include/capstone
>> -I/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb
>>
>> -I/usr/local/include -I/usr/local/include/glib-2.0
>> -I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall
>> -Winvalid-pch -std=gnu11 -O0 -g -iquote . -iquote
>> /usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb
>>
>> -iquote
>> /usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/include
>>
>> -iquote
>> /usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/tcg/i386
>>
>> -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
>> -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings
>> -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv
>> -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k
>> -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs
>> -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides
>> -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int
>> -Wno-typedef-redefinition -Wno-tautological-type-limit-compare
>> -Wno-psabi -fstack-protector-strong -O2 -pipe -fstack-protector-strong
>> -fno-strict-aliasing '-DPREFIX=\""/usr/local\""' -fPIE -DNEED_CPU_H
>> '-DCONFIG_TARGET="arm-bsd-user-config-target.h"'
>> '-DCONFIG_DEVICES="arm-bsd-user-config-devices.h"' -MD -MQ
>> libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -MF
>> libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o.d -o
>> libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -c ../bsd-user/signal.c
>> In file included from ../bsd-user/signal.c:27:
>> In file included from ../bsd-user/host/x86_64/host-signal.h:14:
>> In file included from /usr/include/vm/pmap.h:92:
>> /usr/include/machine/pmap.h:452:2: error: fields must have a constant
>> size: 'variable length array in structure' extension will never be
>> supported
>>          PV_CHUNK_HEADER
>>          ^
>> /usr/include/machine/pmap.h:448:12: note: expanded from macro
>> 'PV_CHUNK_HEADER'
>>          uint64_t                pc_map[_NPCM];  /* bitmap; 1 = free */  \
>>                                  ^
>> /usr/include/machine/pmap.h:456:2: error: fields must have a constant
>> size: 'variable length array in structure' extension will never be
>> supported
>>          PV_CHUNK_HEADER
>>          ^
>> /usr/include/machine/pmap.h:448:12: note: expanded from macro
>> 'PV_CHUNK_HEADER'
>>          uint64_t                pc_map[_NPCM];  /* bitmap; 1 = free */  \
>>                                  ^
>> 2 errors generated.
>> ninja: build stopped: subcommand failed.
>> gmake[3]: *** [Makefile:162: run-ninja] Error 1
>> gmake[3]: Leaving directory
>>
>> '/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb/build'
>> gmake[2]: *** [GNUmakefile:11: all] Error 2
>> gmake[2]: Leaving directory
>>
>> '/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb'
>> *** Error code 2
>>
>> Stop.
>> make[1]: stopped in /usr/ports/emulators/qemu-devel
>> *** Error code 1
>>
>> Stop.
>> make: stopped in /usr/ports/emulators/qemu-devel
>> phobos#
>> phobos# pwd
>> /usr/ports/emulators/qemu-devel
>> phobos#
>>
>> Possibly a problem with -linotify or who knows what ?
>>
>> Also see :
>>
>>    https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg01280.html
>>
>> In any case, something feels wrong here.
>>
>>
>> --
>> Dennis Clarke
>> RISC-V/SPARC/PPC/ARM/CISC
>> UNIX and Linux spoken
>> GreyBeard and suspenders optional
>>
>>

--0000000000000b46f205eab1d741
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Oct 10, 2022 at 10:56 AM Warn=
er Losh <imp@bsdimp.com> wrote:=

I know what's causing this problem. I'll resolve.

<=
div>tl/dr: _pv_entry.h depends on sys/param.h being included before its use=
.

https://reviews.freebsd.org/D36927 fixes it by making=
 sys/_pv_entry.h more
self-contained and less reliant on para=
m.h pollution. The kernel includes that
everywhere it's used,=
 but userland is more hit or miss because machine/pmap.h
isn'=
t a well defined interface, but is needed for some things sometimes.
<=
div>
Warner
=C2=A0
Warner

On Mon, Oct 10, 20=
22 at 4:38 AM Dennis Clarke <dclarke@blastwave.org> wrote:


On :



phobos#

phobos# uname -apKU

FreeBSD phobos 14.0-CURRENT FreeBSD 14.0-CURRENT #14 

main-n258340-497cdf9673e: Sun Oct=C2=A0 2 09:51:14 GMT 2022 

root@phobos:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400072 
1400072

phobos#





Seems to fail in a pretty consistent fashion :



.

.

.

[5633/6772] Compiling C object libqemu-arm-bsd-user.fa.p/bsd-user_mmap.c.o<=
br>
[5634/6772] Compiling C object libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.=
o

FAILED: libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o

cc -m64 -mcx16 -Ilibqemu-arm-bsd-user.fa.p -I. -I.. -Itarget/arm 

-I../target/arm -I../common-user/host/x86_64 -I../bsd-user/include 

-Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-user/host/x86_64 

-Ibsd-user -I../bsd-user -I../bsd-user/arm -Iqapi -Itrace -Iui 

-Iui/shader -I/usr/local/include/capstone 

-I/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcd=
d1b165edb 

-I/usr/local/include -I/usr/local/include/glib-2.0 

-I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall 

-Winvalid-pch -std=3Dgnu11 -O0 -g -iquote . -iquote 

/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1=
b165edb 

-iquote 

/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1=
b165edb/include 

-iquote 

/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1=
b165edb/tcg/i386 

-pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=3D64 -D_LARGEFILE_SOURCE 

-Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings 

-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 

-Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k 

-Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs 

-Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides 

-Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int 
-Wno-typedef-redefinition -Wno-tautological-type-limit-compare 

-Wno-psabi -fstack-protector-strong -O2 -pipe -fstack-protector-strong 

-fno-strict-aliasing '-DPREFIX=3D\""/usr/local\""&#=
39; -fPIE -DNEED_CPU_H 

'-DCONFIG_TARGET=3D"arm-bsd-user-config-target.h"' 

'-DCONFIG_DEVICES=3D"arm-bsd-user-config-devices.h"' -MD =
-MQ 

libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -MF 

libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o.d -o 

libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o -c ../bsd-user/signal.c

In file included from ../bsd-user/signal.c:27:

In file included from ../bsd-user/host/x86_64/host-signal.h:14:

In file included from /usr/include/vm/pmap.h:92:

/usr/include/machine/pmap.h:452:2: error: fields must have a constant 

size: 'variable length array in structure' extension will never be =
supported

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PV_CHUNK_HEADER

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^

/usr/include/machine/pmap.h:448:12: note: expanded from macro 

'PV_CHUNK_HEADER'

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint64_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 pc_map[_NPCM];=C2=A0 /* bitmap; 1 =3D free */=C2=
=A0 \

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^

/usr/include/machine/pmap.h:456:2: error: fields must have a constant 

size: 'variable length array in structure' extension will never be =
supported

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PV_CHUNK_HEADER

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^

/usr/include/machine/pmap.h:448:12: note: expanded from macro 

'PV_CHUNK_HEADER'

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint64_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 pc_map[_NPCM];=C2=A0 /* bitmap; 1 =3D free */=C2=
=A0 \

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^

2 errors generated.

ninja: build stopped: subcommand failed.

gmake[3]: *** [Makefile:162: run-ninja] Error 1

gmake[3]: Leaving directory 

'/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004=
dcdd1b165edb/build'

gmake[2]: *** [GNUmakefile:11: all] Error 2

gmake[2]: Leaving directory 

'/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004=
dcdd1b165edb'

*** Error code 2



Stop.

make[1]: stopped in /usr/ports/emulators/qemu-devel

*** Error code 1



Stop.

make: stopped in /usr/ports/emulators/qemu-devel

phobos#

phobos# pwd

/usr/ports/emulators/qemu-devel

phobos#



Possibly a problem with -linotify or who knows what ?



Also see :



=C2=A0 =C2=A0https://lists.non=
gnu.org/archive/html/qemu-devel/2022-10/msg01280.html



In any case, something feels wrong here.





-- 

Dennis Clarke

RISC-V/SPARC/PPC/ARM/CISC

UNIX and Linux spoken

GreyBeard and suspenders optional








--0000000000000b46f205eab1d741--

From nobody Tue Oct 11 04:20:40 2022
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 4MmjKD1GD9z4dnKb;
	Tue, 11 Oct 2022 04:21:36 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
Received: from mail.oetec.com (mail.oetec.com [108.160.241.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.oetec.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MmjKC2l2Xz3wn6;
	Tue, 11 Oct 2022 04:21:35 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
X-Spam-Status: No
X-oetec-MailScanner-From: dclarke@blastwave.org
X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=-5.104, required 6, autolearn=not spam, ALL_TRUSTED -1.00,
	BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10,
	DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -2.01,
	URIBL_BLOCKED 0.00, URIBL_DBL_BLOCKED_OPENDNS 0.00,
	URIBL_ZEN_BLOCKED_OPENDNS 0.00)
X-oetec-MailScanner: Found to be clean
X-oetec-MailScanner-ID: 29B4Keru031727
X-oetec-MailScanner-Information: Please contact oetec for more information
Received: from [172.16.35.2] (cpeac202e7325b3-cmac202e7325b0.cpe.net.cable.rogers.com [99.253.170.241])
	(authenticated bits=0)
	by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 29B4Keru031727
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT);
	Tue, 11 Oct 2022 00:20:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org;
	s=default; t=1665462042;
	bh=5yBhqbZ0zwpOmbmnU2tH+VuxAOYB5DysWbqWTZrH8pY=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=kYzWRb138+LWXsoywSjZACGnSrxdM0Ik2NJBA90JnEoEBXfHbVwzjrIP+Nch+8JHj
	 igTv9nAmhcD5iYGCZGG+nFNv4fBy9lVELfihAWL9/o0sV86YXuP3JCjM0Ti2NhM+BD
	 XrkL6xZsF8yCaoXWtXA+LjSobexyKOhmoV4csU+GeScCY5ulkCDR7lrk3+tMrj9xXA
	 V7lZfRL9UQSLIyFFGFCLZf13TdGUgJP4AoBn9q9pD7oOwPGCM3PoguJwx8NJJq6PCL
	 sLKTrm6X/qgNYe898XNaZf9v9xd/DENukxspp/ni0xfDu6OtNz4E8sXbm66+aFI1S6
	 TWJbsNvqbMC1A==
Message-ID: 
Date: Tue, 11 Oct 2022 04:20:40 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: Has anyone tried to build QEMU from ports lately?
Content-Language: en-US
To: Warner Losh 
Cc: FreeBSD CURRENT , riscv@freebsd.org
References: <4a476b1c-74e4-9cb8-17a4-202c81b2da1d@blastwave.org>
 
 
From: Dennis Clarke 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MmjKC2l2Xz3wn6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=blastwave.org header.s=default header.b=kYzWRb13;
	dmarc=pass (policy=quarantine) header.from=blastwave.org;
	spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org
X-Spamd-Result: default: False [-3.70 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine];
	RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	R_SPF_ALLOW(-0.20)[+mx];
	RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from];
	R_DKIM_ALLOW(-0.20)[blastwave.org:s=default];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[riscv@freebsd.org,freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[blastwave.org:+];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 10/10/22 17:53, Warner Losh wrote:
> On Mon, Oct 10, 2022 at 10:56 AM Warner Losh  wrote:
> 
>> I know what's causing this problem. I'll resolve.
>>
>> tl/dr: _pv_entry.h depends on sys/param.h being included before its use.
>>
> 
> https://reviews.freebsd.org/D36927 fixes it by making sys/_pv_entry.h more
> self-contained and less reliant on param.h pollution. The kernel includes
> that
> everywhere it's used, but userland is more hit or miss because
> machine/pmap.h
> isn't a well defined interface, but is needed for some things sometimes.
> 

I am not sure where this is related, however, there is a change in QEMU:


https://github.com/qemu/qemu/commit/a4a9a4432e2bf280a989ca344466d7375db7993f


Which seems to provide a way around some really long ISA cpu name data 
that gets caught in sys/riscv/riscv/identcpu.c at around line 113 or
so :


#ifdef FDT
/*
  * The ISA string is made up of a small prefix (e.g. rv64) and up to 26 
letters
  * indicating the presence of the 26 possible standard extensions. 
Therefore 32
  * characters will be sufficient.
  */
#define ISA_NAME_MAXLEN         32
#define ISA_PREFIX              ("rv" __XSTRING(__riscv_xlen))
#define ISA_PREFIX_LEN          (sizeof(ISA_PREFIX) - 1)


So if a person did not know about the new boolean
thingy "short-isa-string" then any attempt to boot
FreeBSD 14.0 on rv64imafdc ends up with a neato
little messy KASSERT :

sedna$
sedna$ uname -apKU
FreeBSD sedna 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC amd64 
amd64 1301000 1301000
sedna$ /usr/local/bin/qemu-system-riscv64 --version
QEMU emulator version 7.1.0
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
sedna$
sedna$
sedna$ /usr/local/bin/qemu-system-riscv64 \
 > -machine virt -m 32768M -smp 8 -nographic \
 > -bios /usr/local/share/opensbi/lp64/generic/firmware/fw_jump.elf \
 > -kernel /usr/local/share/u-boot/u-boot-qemu-riscv64/u-boot.bin \
 > -drive 
file=/opt/qemu/riscv/fbsd14/fbsd14_rv64imafdc.qcow2,format=qcow2,id=hd0 \
 > -device virtio-blk-device,drive=hd0 \
 > -object rng-random,filename=/dev/urandom,id=rng0 \
 > -device virtio-rng-device,rng=rng0 \
 > -device virtio-net-device,netdev=usernet \
 > -netdev user,id=usernet,hostfwd=tcp::10000-:22

OpenSBI v1.1
    ____                    _____ ____ _____
   / __ \                  / ____|  _ \_   _|
  | |  | |_ __   ___ _ __ | (___ | |_) || |
  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
  | |__| | |_) |  __/ | | |____) | |_) || |_
   \____/| .__/ \___|_| |_|_____/|____/_____|
         | |
         |_|

Platform Name             : riscv-virtio,qemu
Platform Features         : medeleg
Platform HART Count       : 8
Platform IPI Device       : aclint-mswi
Platform Timer Device     : aclint-mtimer @ 10000000Hz
Platform Console Device   : uart8250
Platform HSM Device       : ---
Platform Reboot Device    : sifive_test
Platform Shutdown Device  : sifive_test
Firmware Base             : 0x80000000
Firmware Size             : 352 KB
Runtime SBI Version       : 1.0

Domain0 Name              : root
Domain0 Boot HART         : 7
Domain0 HARTs             : 0*,1*,2*,3*,4*,5*,6*,7*
Domain0 Region00          : 0x0000000002000000-0x000000000200ffff (I)
Domain0 Region01          : 0x0000000080000000-0x000000008007ffff ()
Domain0 Region02          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
Domain0 Next Address      : 0x0000000080200000
Domain0 Next Arg1         : 0x0000000082200000
Domain0 Next Mode         : S-mode
Domain0 SysReset          : yes

Boot HART ID              : 7
Boot HART Domain          : root
Boot HART Priv Version    : v1.12
Boot HART Base ISA        : rv64imafdch
Boot HART ISA Extensions  : time
Boot HART PMP Count       : 16
Boot HART PMP Granularity : 4
Boot HART PMP Address Bits: 54
Boot HART MHPM Count      : 16
Boot HART MIDELEG         : 0x0000000000001666
Boot HART MEDELEG         : 0x0000000000f0b509


U-Boot 2022.04 (Sep 06 2022 - 07:24:53 +0000)

CPU:   rv64imafdch_zicsr_zifencei_zba_zbb_zbc_zbs
Model: riscv-virtio,qemu
DRAM:  32 GiB
Core:  19 devices, 10 uclasses, devicetree: board
Flash: 32 MiB
Loading Environment from nowhere... OK
In:    uart@10000000
Consoles: EFI console
     Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk0p1:
FreeBSD/riscv EFI loader, Revision 1.1
(Fri Oct  7 04:52:01 UTC 2022 root@releng1.nyi.freebsd.org)

    Command line arguments: l
    Image base: 0xfe669000
    EFI version: 2.90
/  ______               ____   _____ _____
   |  ____|             |  _ \ / ____|  __ \
   | |___ _ __ ___  ___ | |_) | (___ | |  | |
   |  ___| '__/ _ \/ _ \|  _ < \___ \| |  | |
   | |   | | |  __/  __/| |_) |____) | |__| |
   | |   | | |    |    ||     |      |      |
   |_|   |_|  \___|\___||____/|_____/|_____/      ``` 
      `
                                                 s` 
`.....---.......--.```   -/
  +---------- Welcome to FreeBSD -----------+    +o   .--`         /y:` 
      +.
  |                                         |     yo`:.            :o 
    `+-
  |  1. Boot Multi user [Enter]             |      y/               -/` 
   -o/
  |  2. Boot Single user                    |     .- 
::/sy+:.
  |  3. Escape to loader prompt             |     / 
`--  /
  |  4. Reboot                              |    `: 
      :`
  |  5. Cons: Video                         |    `: 
      :`
  |                                         |     / 
      /
  |  Options:                               |     .- 
     -.
  |  6. Kernel: default/kernel (1 of 1)     |      -- 
    -.
  |  7. Boot Options                        |       `:`                  `:`
  |                                         |         .--             `--.
  |                                         |            .---.....----.
  +-----------------------------------------+
    Autoboot in 0 seconds. [Space] to pause
Loading kernel...
/boot/kernel/kernel text=0x5b3a88 text=0x175c2c data=0xf4208 
data=0x1f74+0x2738dc 0x8+0x1f46fb8+0x8+0xf3f1e
Loading configured modules...
can't find '/etc/hostid'
can't find '/boot/entropy'
Using DTB provided by EFI at 0x87efb000.
Kernel entry at 0xf680002e...
Kernel args: (null)
---<>---
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2022 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
         The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 14.0-CURRENT #0 main-n258483-b05b1ecbef0: Fri Oct  7 05:52:47 
UTC 2022
 
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/riscv.riscv64/sys/GENERIC 
riscv
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git 
llvmorg-14.0.5-0-gc12386ae247c)
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
SBI: OpenSBI v1.1
SBI Specification Version: 1.0
CPU(0): Unknown Implementer Unknown Processor
real memory  = 34359738368 (32768 MB)
avail memory = 33401937920 (31854 MB)
Starting CPU 1 (hart 0)
Starting CPU 2 (hart 1)
Starting CPU 3 (hart 2)
Starting CPU 4 (hart 3)
Starting CPU 5 (hart 4)
Starting CPU 6 (hart 5)
Starting CPU 7 (hart 6)
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
panic: ISA string truncated
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x38
kdb_backtrace() at kdb_backtrace+0x2c
vpanic() at vpanic+0x126
panic() at panic+0x2a
fill_elf_hwcap() at fill_elf_hwcap+0x220
mi_startup() at mi_startup+0x1d2
va() at va+0x7e
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at      kdb_enter+0x4a: sd      zero,0(s1)
db> halt
qemu-system-riscv64: terminating on signal 1 from pid 2765 (csh)
sedna$

due to :

         /*
          * Iterate through the CPUs and examine their ISA string. While we
          * could assign elf_hwcap to be whatever the boot CPU supports, to
          * handle the (unusual) case of running a system with hetergeneous
          * ISAs, keep only the extension bits that are common to all harts.
          */
         for (node = OF_child(node); node > 0; node = OF_peer(node)) {
                 /* Skip any non-CPU nodes, such as cpu-map. */
                 if (!ofw_bus_node_is_compatible(node, "riscv"))
                         continue;

                 len = OF_getprop(node, "riscv,isa", isa, sizeof(isa));
                 KASSERT(len <= ISA_NAME_MAXLEN, ("ISA string truncated"));
                 if (len == -1) {
                         if (bootverbose)
                                 printf("fill_elf_hwcap: "
                                     "Can't find riscv,isa property\n");
                         return;
                 } else if (strncmp(isa, ISA_PREFIX, ISA_PREFIX_LEN) != 0) {
                         if (bootverbose)
                                 printf("fill_elf_hwcap: "
                                     "Unsupported ISA string: %s\n", isa);
                         return;
                 }


again in sys/riscv/riscv/identcpu.c

However this seems to work :

sedna$ /usr/local/bin/qemu-system-riscv64 \
 > -machine virt -m 32768M -smp 8 -cpu rv64,short-isa-string=on \
 > -nographic \
 > -bios /usr/local/share/opensbi/lp64/generic/firmware/fw_jump.elf \
 > -kernel /usr/local/share/u-boot/u-boot-qemu-riscv64/u-boot.bin \
 > -drive 
file=/opt/qemu/riscv/fbsd14/fbsd14_rv64imafdc.qcow2,format=qcow2,id=hd0 \
 > -device virtio-blk-device,drive=hd0 \
 > -object rng-random,filename=/dev/urandom,id=rng0 \
 > -device virtio-rng-device,rng=rng0 \
 > -device virtio-net-device,netdev=usernet \
 > -netdev user,id=usernet,hostfwd=tcp::10000-:22


OpenSBI v1.1
    ____                    _____ ____ _____
   / __ \                  / ____|  _ \_   _|
  | |  | |_ __   ___ _ __ | (___ | |_) || |
  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
  | |__| | |_) |  __/ | | |____) | |_) || |_
   \____/| .__/ \___|_| |_|_____/|____/_____|
         | |
         |_|

Platform Name             : riscv-virtio,qemu
Platform Features         : medeleg
Platform HART Count       : 8
Platform IPI Device       : aclint-mswi
Platform Timer Device     : aclint-mtimer @ 10000000Hz
Platform Console Device   : uart8250
Platform HSM Device       : ---
Platform Reboot Device    : sifive_test
Platform Shutdown Device  : sifive_test
Firmware Base             : 0x80000000
Firmware Size             : 352 KB
Runtime SBI Version       : 1.0

Domain0 Name              : root
Domain0 Boot HART         : 7
Domain0 HARTs             : 0*,1*,2*,3*,4*,5*,6*,7*
Domain0 Region00          : 0x0000000002000000-0x000000000200ffff (I)
Domain0 Region01          : 0x0000000080000000-0x000000008007ffff ()
Domain0 Region02          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
Domain0 Next Address      : 0x0000000080200000
Domain0 Next Arg1         : 0x0000000082200000
Domain0 Next Mode         : S-mode
Domain0 SysReset          : yes

Boot HART ID              : 7
Boot HART Domain          : root
Boot HART Priv Version    : v1.12
Boot HART Base ISA        : rv64imafdch
Boot HART ISA Extensions  : time
Boot HART PMP Count       : 16
Boot HART PMP Granularity : 4
Boot HART PMP Address Bits: 54
Boot HART MHPM Count      : 16
Boot HART MIDELEG         : 0x0000000000001666
Boot HART MEDELEG         : 0x0000000000f0b509


U-Boot 2022.04 (Sep 06 2022 - 07:24:53 +0000)

CPU:   rv64imafdch
Model: riscv-virtio,qemu
DRAM:  32 GiB
Core:  19 devices, 10 uclasses, devicetree: board
Flash: 32 MiB
Loading Environment from nowhere... OK
In:    uart@10000000
Consoles: EFI console
     Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk0p1:
FreeBSD/riscv EFI loader, Revision 1.1
(Fri Oct  7 04:52:01 UTC 2022 root@releng1.nyi.freebsd.org)

    Command line arguments: l
    Image base: 0xfe669000
    EFI version: 2.90
    ______               ____   _____ _____
   |  ____|             |  _ \ / ____|  __ \
   | |___ _ __ ___  ___ | |_) | (___ | |  | |
   |  ___| '__/ _ \/ _ \|  _ < \___ \| |  | |
   | |   | | |  __/  __/| |_) |____) | |__| |
   | |   | | |    |    ||     |      |      |
   |_|   |_|  \___|\___||____/|_____/|_____/      ``` 
      `
                                                 s` 
`.....---.......--.```   -/
  +---------- Welcome to FreeBSD -----------+    +o   .--`         /y:` 
      +.
  |                                         |     yo`:.            :o 
    `+-
  |  1. Boot Single user [Enter]            |      y/               -/` 
   -o/
  |  2. Boot Multi user                     |     .- 
::/sy+:.
  |  3. Escape to loader prompt             |     / 
`--  /
  |  4. Reboot                              |    `: 
      :`
  |  5. Cons: Video                         |    `: 
      :`
  |                                         |     / 
      /
  |  Options:                               |     .- 
     -.
  |  6. Kernel: default/kernel (1 of 1)     |      -- 
    -.
  |  7. Boot Options                        |       `:`                  `:`
  |                                         |         .--             `--.
  |                                         |            .---.....----.
  +-----------------------------------------+

Loading kernel...
/boot/kernel/kernel text=0x5b3a88 text=0x175c2c data=0xf4208 
data=0x1f74+0x2738dc 0x8+0x1f46fb8+0x8+0xf3f1e
Loading configured modules...
can't find '/etc/hostid'
can't find '/boot/entropy'
Using DTB provided by EFI at 0x87efb000.
Kernel entry at 0xf680002e...
Kernel args: (null)
---<>---
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2022 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
         The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 14.0-CURRENT #0 main-n258483-b05b1ecbef0: Fri Oct  7 05:52:47 
UTC 2022
 
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/riscv.riscv64/sys/GENERIC 
riscv
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git 
llvmorg-14.0.5-0-gc12386ae247c)
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
SBI: OpenSBI v1.1
SBI Specification Version: 1.0
CPU(0): Unknown Implementer Unknown Processor
real memory  = 34359738368 (32768 MB)
avail memory = 33401909248 (31854 MB)
Starting CPU 1 (hart 0)
Starting CPU 2 (hart 1)
Starting CPU 3 (hart 2)
Starting CPU 4 (hart 3)
Starting CPU 5 (hart 4)
Starting CPU 6 (hart 5)
Starting CPU 7 (hart 6)
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
arc4random: WARNING: initial seeding bypassed the cryptographic random 
device because it was not yet seeded and the knob 
'bypass_before_seeding' was enabled.
random: entropy device external interface
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
simplebus1:  on ofwbus0
plic0:  mem 0xc000000-0xc5fffff irq 
10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25 on simplebus1
timer0: 
Timecounter "RISC-V Timecounter" frequency 10000000 Hz quality 1000
Event timer "RISC-V Eventtimer" frequency 10000000 Hz quality 1000
riscv_syscon0:  mem 0x100000-0x100fff on simplebus1
rcons0: 
cpulist0:  on ofwbus0
cpu0:  on cpulist0
cpu1:  on cpulist0
cpu2:  on cpulist0
cpu3:  on cpulist0
cpu4:  on cpulist0
cpu5:  on cpulist0
cpu6:  on cpulist0
cpu7:  on cpulist0
goldfish_rtc0:  mem 0x101000-0x101fff irq 0 on simplebus1
goldfish_rtc0: registered as a time-of-day clock, resolution 1.000000s
uart0: <16550 or compatible> mem 0x10000000-0x100000ff irq 1 on simplebus1
uart0: console (115200,n,8,1)
syscon_power0:  on simplebus1
syscon_power1:  on simplebus1
pcib0:  mem 0x30000000-0x3fffffff on simplebus1
pci0:  on pcib0
virtio_mmio0:  mem 0x10008000-0x10008fff irq 2 on 
simplebus1
vtblk0:  on virtio_mmio0
vtblk0: 6176MB (12649600 512 byte sectors)
virtio_mmio1:  mem 0x10007000-0x10007fff irq 3 on 
simplebus1
virtio_mmio2:  mem 0x10006000-0x10006fff irq 4 on 
simplebus1
vtnet0:  on virtio_mmio2
vtnet0: Ethernet address: 52:54:00:12:34:56
Timecounters tick every 1.000 msec
usb_needs_explore_all: no devclass
Trying to mount root from ufs:/dev/gpt/rootfs [rw]...
Release APs
WARNING: WITNESS option enabled, expect reduced performance.
random: unblocking device.
Enter full pathname of shell or RETURN for /bin/sh:
root@:/ # uname -apKU
FreeBSD  14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n258483-b05b1ecbef0: 
Fri Oct  7 05:52:47 UTC 2022 
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/riscv.riscv64/sys/GENERIC 
riscv riscv64 1400072 1400072
root@:/ # sysctl hw.ncpu
hw.ncpu: 8
root@:/ # sysctl hw.model
sysctl: unknown oid 'hw.model'
root@:/ # sysctl hw.physmem
hw.physmem: 34312138752
root@:/ # shutdown -p 'now'
Shutdown NOW!
shutdown: [pid 22]
root@:/ # wall: can't open temporary file: Read-only file system
2022-10-11T04:17:08.354519+00:00 - shutdown 22 - - power-down by root:

System shutdown time has arrived
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 0 0 0 0 0 0 0 0 0 0 done
All buffers synced.
Uptime: 56s
sedna$


Sort of makes me wonder if perhaps a longer cpu ISA name string would
be of any benefit?  I am curious what the string was that tossed the
KASSERT myself.  Also funny that sysctl hw.model returns nothing useful.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional






From nobody Tue Oct 11 04:24:31 2022
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 4MmjPW4Q0kz4dp19;
	Tue, 11 Oct 2022 04:25:19 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
Received: from mail.oetec.com (mail.oetec.com [108.160.241.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.oetec.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MmjPW0PsVz40Rg;
	Tue, 11 Oct 2022 04:25:19 +0000 (UTC)
	(envelope-from dclarke@blastwave.org)
X-Spam-Status: No
X-oetec-MailScanner-From: dclarke@blastwave.org
X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=-5.104, required 6, autolearn=not spam, ALL_TRUSTED -1.00,
	BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10,
	DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -2.01,
	URIBL_BLOCKED 0.00, URIBL_DBL_BLOCKED_OPENDNS 0.00,
	URIBL_ZEN_BLOCKED_OPENDNS 0.00)
X-oetec-MailScanner: Found to be clean
X-oetec-MailScanner-ID: 29B4OVml031876
X-oetec-MailScanner-Information: Please contact oetec for more information
Received: from [172.16.35.2] (cpeac202e7325b3-cmac202e7325b0.cpe.net.cable.rogers.com [99.253.170.241])
	(authenticated bits=0)
	by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 29B4OVml031876
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT);
	Tue, 11 Oct 2022 00:24:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org;
	s=default; t=1665462273;
	bh=Mvf4kgaje8DEwWvBdRxEbzdESVG0rNsk/HHYW1ggqSs=;
	h=Date:Subject:From:To:Cc:References:In-Reply-To:From;
	b=W97J6Pcbdx3m4IbExzq9YGYXMZi4BdUJ/5XEKmJddZHkmYwLdFTRp1ZDylyy6KGyr
	 WnjpGvmW5YMFv6JW6ROEFllt/ckdJXJJDJZCZU68X6GDPF8Ibxin07Eite/NDzC4/t
	 4yW95EPZq7YvEelLyjJTnbvOSjve87cKUrpB4QWi9dYLjuE5xftClHRVq6nX+n71uo
	 3VfJ9FlDFUUyi0/syatMUljto9Wa58GFd+WlZrFT40igUzQenH80X4igL4f/rfAP2N
	 NjGPc9OoGFfOJcqlIG8E54ts1NA9QzKY8afQPuLdk4AB/px809nyKZTq55kCmdlEon
	 UYbZVHL/YctlA==
Message-ID: <11c1eb3b-0ef4-2c2f-513e-6555346a67ea@blastwave.org>
Date: Tue, 11 Oct 2022 04:24:31 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: Has anyone tried to build QEMU from ports lately?
Content-Language: en-US
From: Dennis Clarke 
To: Warner Losh 
Cc: FreeBSD CURRENT , riscv@freebsd.org
References: <4a476b1c-74e4-9cb8-17a4-202c81b2da1d@blastwave.org>
 
 
 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MmjPW0PsVz40Rg
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=blastwave.org header.s=default header.b=W97J6Pcb;
	dmarc=pass (policy=quarantine) header.from=blastwave.org;
	spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org
X-Spamd-Result: default: False [-3.70 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	RCVD_DKIM_ARC_DNSWL_MED(-0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine];
	R_SPF_ALLOW(-0.20)[+mx:c];
	RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from];
	R_DKIM_ALLOW(-0.20)[blastwave.org:s=default];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[riscv@freebsd.org,freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DKIM_TRACE(0.00)[blastwave.org:+];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 10/11/22 04:20, Dennis Clarke wrote:
> On 10/10/22 17:53, Warner Losh wrote:
>> On Mon, Oct 10, 2022 at 10:56 AM Warner Losh  wrote:
>>
>>> I know what's causing this problem. I'll resolve.
>>>
>>> tl/dr: _pv_entry.h depends on sys/param.h being included before its use.
>>>
>>
>> https://reviews.freebsd.org/D36927 fixes it by making sys/_pv_entry.h 
>> more
>> self-contained and less reliant on param.h pollution. The kernel includes
>> that
>> everywhere it's used, but userland is more hit or miss because
>> machine/pmap.h
>> isn't a well defined interface, but is needed for some things sometimes.
>>
> 
> I am not sure where this is related, however, there is a change in QEMU:
> 
> 
> https://github.com/qemu/qemu/commit/a4a9a4432e2bf280a989ca344466d7375db7993f 
> 
> 
> 
> Which seems to provide a way around some really long ISA cpu name data 
> that gets caught in sys/riscv/riscv/identcpu.c at around line 113 or
> so :
> 
> 

Forgot to mention :

https://github.com/qemu/qemu/blob/master/hw/riscv/virt.c#L248

I wonder what the string is that tossed the KASSERT.



-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From nobody Wed Oct 12 17:36:57 2022
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 4Mnfwd0CClz4fpwZ
	for ; Wed, 12 Oct 2022 17:37:05 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mnfwc5Zh7z3Ypl
	for ; Wed, 12 Oct 2022 17:37:04 +0000 (UTC)
	(envelope-from 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 29CHav3g061546
	for ; Wed, 12 Oct 2022 10:37:03 -0700 (PDT)
	(envelope-from bsd-lists@bsdforge.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
Date: Wed, 12 Oct 2022 10:36:57 -0700
From: Chris 
To: freebsd-current 
Subject: athp / ath10k or the Atheros QCA6174
User-Agent: UDNSMS/17.0
Message-ID: <24b2845daed3179048ff68c0991d8fa7@bsdforge.com>
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_49a5b31f13f66db3c7e3ea77ec0f203e"
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4Mnfwc5Zh7z3Ypl
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-Spamd-Result: default: False [0.00 / 15.00];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_49a5b31f13f66db3c7e3ea77ec0f203e
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

It appears that many chips like the Atheros/Qualcomm QCA6174 are
supported on FreeBSD by the athp or the ath10k. But in some
7 years now, neither of those drivers have come to fruition.
Are there any plans to complete either of these? Or is there
a different option for these chips?

Thank you for all your time and consideration.

--chris
--=_49a5b31f13f66db3c7e3ea77ec0f203e
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_49a5b31f13f66db3c7e3ea77ec0f203e--

From nobody Thu Oct 13 10:48:27 2022
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 4Mp5pm0gnjz4fgnC;
	Thu, 13 Oct 2022 10:48:32 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mp5pm05Mcz43PC;
	Thu, 13 Oct 2022 10:48:32 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1665658112;
	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=q8tz6GuYAt+Y9uAnYSt5vo+uDyQWFETwiy/EcYZjPB4=;
	b=vB36qt3SDPsvWbg2QieJcyJs9IkA3UugU7RiTJY5Lvz5zLOAb0GYTVV6MIQiMhVauVPaHj
	BN1EogKhVtr+rTxpj92z9X93ieKp0NyhadJPGWRUJROWpqXIBLEhfaXyOPDghQoYiVI1Vx
	SoZ/ok6OBQirnPI3mxptZhcfWHiHe8lusFJocNub8FxdisfwyvHJC4c4/mMqwXJ78BmOsx
	VmCKHDvvnUWuW4q9DEBDbQ83lQeREYuLhpeCMOwoLExk6FrxRHJq3y709xEkB/YqwzWMiP
	osjFRw/uQzCOQFz0bkRVA+5p6s5Fe+cSoFTUTOrZGnWlJCbJ1nCojLAgX0eL8g==
Received: from [192.168.0.88] (unknown [195.64.148.76])
	(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 4Mp5pl3YKWz17tF;
	Thu, 13 Oct 2022 10:48:31 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Message-ID: 
Date: Thu, 13 Oct 2022 13:48:27 +0300
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.3.2
Subject: UDP port re-use [Was: in_pcbbind_setup: wrong condition regarding
 INP_REUSEPORT ?]
Content-Language: en-US
From: Andriy Gapon 
To: "net@FreeBSD.org" , FreeBSD Current 
References: 
 <896ee089-27ad-c98f-6bf9-4b05caf778fd@freebsd.org>
 <9037ac3d-8d8e-2d7d-cbdb-996a53613aca@FreeBSD.org>
In-Reply-To: <9037ac3d-8d8e-2d7d-cbdb-996a53613aca@FreeBSD.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1665658112;
	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=q8tz6GuYAt+Y9uAnYSt5vo+uDyQWFETwiy/EcYZjPB4=;
	b=U9btPVK6IEv+s2dFh5a2a7E/csEOtkcvnmK548t2Z/FbZUtrl/3HfTYxCgJI87Jbz5BUhJ
	HFtW6KPSqcv6kmobPnXK94uFU3Do/C8t5YIT3jxxBwEJcsFcVGGSiYDbeJUdhbgS8g7fCh
	r/m3unB9nFz0rQyTabzboH6vQgCib6cobG1xVyqJ2Rm0jJPj3gEax0cvsZar4TTbXUPeF6
	sq+D3Q0F8tcSJGwdW7rB/8ncXiUoo9vIH26HowoAZ9iT2UGwi4lqx3aWB2tBsOwPrX7pt3
	1oYKkgMD50eNPmq+qYzAFXXeedOg5oAM8lBbASHxJLOgUhSVa0D/2PME4/Ei3Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1665658112; a=rsa-sha256; cv=none;
	b=vXVoGaguI/vGIoCnS/hZi7CLGsO/dhDfnH4jF3LjUr8RLxOE7Vw0M410ks/xFz3LkiqgJC
	T2GocxTFpJ0TCcLTYufZfJUhd24b3oqesX0APlxZaXG1RUmaKS+Uu8Y1Ne2R7QpM5Il7H4
	cYyTN3A6xOgEIlcUrNtK78gfQQ8otNaCbbYWDZ2kvGDnohLRIj7KE+r1etzB5vYR4Vfsxw
	PBlyLX6pUd/bEUEjyLsQIW7Gw8CaTiCpDiYtgmoBnnRGi9gIhHmAwn46HP5iAsATEpHZtt
	FtK7ENdDJgJ+n7LtmrodbDSU7h5Aw+HODLoL53nmYeBt4sFNUERd2nSb0dUNfg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


Do we have test cases or a document that can be a definitive guide to UDP port 
re-use on FreeBSD?
Including effects of INP_REUSEADDR, INP_REUSEPORT and INP_REUSEPORT_LB socket 
options, socket addresses, socket credentials?
I can find some descriptions on the internet, but they do not seem to be 
complete.  The effect of addresses is under-described and I do not see any 
mention of credentials (UIDs).

Is there a way to tell if some behavior is correct or not?
Is it all in heads of people and in the change history?

On 04/10/2022 14:46, Andriy Gapon wrote:
> On 04/10/2022 14:37, Sean Bruno wrote:
>>
>>
>> On 10/3/22 04:14, Andriy Gapon wrote:
>>>
>>> I must admit that the condition in question is fairly long and non-trivial 
>>> and I cannot decipher it, but these two lines look wrong to me:
>>>
>>>                                       (t->inp_flags2 & INP_REUSEPORT) ||
>>>                                       (t->inp_flags2 & INP_REUSEPORT_LB) == 
>>> 0) &&
>>>
>>> I'd expect that the check would be symmetric with respect to INP_REUSEPORT 
>>> and INP_REUSEPORT_LB.
>>> The problem seems to come from 1a43cff92a20d / r334719 / D11003.
>>>
>>
>> I think you are pointing at this absurd conditional?
>>
>> https://cgit.freebsd.org/src/tree/sys/netinet/in_pcb.c#n1049
>>
>> Besides the twisted logic, what problem are you trying to solve?
> 
> Yes, that conditional.
> I pointed out the part of it that does not make sense to me.
> 
> Also, in my tests SO_REUSEPORT does not actually allow to share a port.
> Test scenario:
> - create a UDP socket
> - setsockopt(SO_REUSEPORT)
> - bind the socket to a port and wild card address
> - success
> - now repeat the previous steps with the same port *under a different user id*
> - bind fails
> 
> I wonder if the following would be a correct change.
> 
> diff --git a/sys/netinet/in_pcb.c b/sys/netinet/in_pcb.c
> index d9247f50d32b..f5e6e3932a96 100644
> --- a/sys/netinet/in_pcb.c
> +++ b/sys/netinet/in_pcb.c
> @@ -1003,6 +1003,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, 
> in_addr_t *laddrp,
>       /*
>        * XXX
>        * This entire block sorely needs a rewrite.
> +     * And a good comment describing the rationale behind the conditions.
>        */
>                   if (t &&
>                       ((inp->inp_flags2 & INP_BINDMULTI) == 0) &&
> @@ -1011,8 +1012,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, 
> in_addr_t *laddrp,
>                        ntohl(t->inp_faddr.s_addr) == INADDR_ANY) &&
>                       (ntohl(sin->sin_addr.s_addr) != INADDR_ANY ||
>                        ntohl(t->inp_laddr.s_addr) != INADDR_ANY ||
> -                     (t->inp_flags2 & INP_REUSEPORT) ||
> -                     (t->inp_flags2 & INP_REUSEPORT_LB) == 0) &&
> +                     (t->inp_flags2 & (INP_REUSEPORT | INP_REUSEPORT_LB)) == 0) &&
>                       (inp->inp_cred->cr_uid !=
>                        t->inp_cred->cr_uid))
>                       return (EADDRINUSE);
> 

-- 
Andriy Gapon


From nobody Fri Oct 14 17:14:51 2022
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 4MptLW5GDMz4ftFj
	for ; Fri, 14 Oct 2022 17:15:15 +0000 (UTC)
	(envelope-from pbowen@fastmail.fm)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MptLV6Tptz3L54
	for ; Fri, 14 Oct 2022 17:15:14 +0000 (UTC)
	(envelope-from pbowen@fastmail.fm)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
	by mailout.west.internal (Postfix) with ESMTP id 9AEC232001C6
	for ; Fri, 14 Oct 2022 13:15:13 -0400 (EDT)
Received: from imap49 ([10.202.2.99])
  by compute1.internal (MEProxy); Fri, 14 Oct 2022 13:15:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h=
	cc:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm3; t=1665767713; x=1665854113; bh=UIE2548Gex
	4z9i5SMC6vreYhgxAYt5G7T0Kvz8W7veA=; b=cM+6gu7EXxWjxP4Juw29q/7DQ0
	sSYg00bGe31LVnLCK337LvmkqI8denT77Pt1y9XyjtyIrGCWm/KZvyj8gj86alR8
	RmxonoY2t22TuuSITwKvqpnvlQdiOqGwovn8WRt2AlWEJUfux+D0Z8WvsxIfNHMl
	ljFFOQ4EqKr6PwBUW0RLTStEPwt5tS/qW5PJHe0/LsYGYVNCHcOR8t3de76hU0sx
	7X7W3YClTULDV7rGbUdB5e2Km/8UFKUJxJoxpnzMuNDe6KLVwDhvmOX6Lfsh9pUO
	MFhU13VRR3C+Kvsvvy7hrCp7kDnqCrbq4Aq9sTZ7wzbwO92IR2kdrgV2AZmg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:in-reply-to:message-id
	:mime-version:references:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm3; t=1665767713; x=1665854113; bh=UIE2548Gex4z9i5SMC6vreYhgxAY
	t5G7T0Kvz8W7veA=; b=QFU4YPj1NpkrairWEPW/8GUpniCOXoHmoza44pI7Mn7y
	ihiGuJGjAE2v2gV5vo0u8Cf91zAcIdUE2FYmNV2i6lX1cu91hOEOsYUgftY0hlaI
	sGtIHORdn+2Lf1OXI1sGGPGUt3INLOu4E8VPES0SGUvySF/k/4iQXpeNXXa267Eh
	jsQqSirO55fXH9zkzmj1NzdPcYsKILe/yZJF/kvV7OMl5PJ7IsIl3nRrfP4XX5Ns
	yhDEa7+ptCwlY+Yg+LMjJBuusDrGUuTIxARLbqjhUYmwQuXyUYoY6Otp9kId7HhW
	KTw3BGBYvQ+313tdN+dS8/hPVVtVL7gs6xYD5+Cwow==
X-ME-Sender: 
    
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeekvddgudduudcutefuodetggdotefrod
    ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
    necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg
    dtreerreertdenucfhrhhomhepfdfrrghtrhhitghkuceuohifvghnfdcuoehpsghofigv
    nhesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepledttdetvefgkeejfe
    efffevgfduffetvedtveehfeetleeigeevjeehvddugeefnecuvehluhhsthgvrhfuihii
    vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgsohifvghnsehfrghsthhmrghilh
    drfhhm
X-ME-Proxy: 
    
    
    
Feedback-ID: i8ecd41a5:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501)
	id ED92B15A0087; Fri, 14 Oct 2022 13:15:12 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1047-g9e4af4ada4-fm-20221005.001-g9e4af4ad
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
Message-Id: <5fc5a86f-9bef-41a8-8127-3406f3c18ca3@app.fastmail.com>
In-Reply-To: 
 
References: 
 
 
Date: Fri, 14 Oct 2022 12:14:51 -0500
From: "Patrick Bowen" 
To: freebsd-current@freebsd.org
Subject: Drm-kmod and 14-CURRENT
Content-Type: multipart/alternative;
 boundary=326b778651b64678b939783e01c3b5da
X-Rspamd-Queue-Id: 4MptLV6Tptz3L54
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=fastmail.fm header.s=fm3 header.b=cM+6gu7E;
	dkim=pass header.d=messagingengine.com header.s=fm3 header.b=QFU4YPj1;
	dmarc=pass (policy=none) header.from=fastmail.fm;
	spf=pass (mx1.freebsd.org: domain of pbowen@fastmail.fm designates 64.147.123.21 as permitted sender) smtp.mailfrom=pbowen@fastmail.fm
X-Spamd-Result: default: False [-5.59 / 15.00];
	DWL_DNSWL_LOW(-2.00)[messagingengine.com:dkim,fastmail.fm:dkim];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[fastmail.fm,none];
	R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21];
	R_DKIM_ALLOW(-0.20)[fastmail.fm:s=fm3,messagingengine.com:s=fm3];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from];
	XM_UA_NO_VERSION(0.01)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	FREEMAIL_ENVFROM(0.00)[fastmail.fm];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[fastmail.fm];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[fastmail.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

--326b778651b64678b939783e01c3b5da
Content-Type: text/plain

Hello all,

I've just used reinstall.sh to add a CURRENT boot environment to a 13.1 ZFS installation. Xorg doesn't load in CURRENT, presumably because the drm-kmod doesn't work with 14. I tried to build drm-current-kmod from ports but the build errors out.

I can send all the error messages and dmesg and such if necessary, but I'm betting it's just a simple fix that I'm unaware of. The graphics is i915 Intel BTW.

TIA for your help,
Patrick
--326b778651b64678b939783e01c3b5da
Content-Type: text/html


Hello all,

I've just used reinstall.sh to add a CURRENT boot environment to a 13.1 ZFS installation. Xorg doesn't load in CURRENT, presumably because the drm-kmod doesn't work with 14. I tried to build drm-current-kmod from ports but the build errors out.

I can send all the error messages and dmesg and such if necessary, but I'm betting it's just a simple fix that I'm unaware of. The graphics is i915 Intel BTW.

TIA for your help,
Patrick

--326b778651b64678b939783e01c3b5da--

From nobody Fri Oct 14 17:53:21 2022
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 4MpvBg05l8z4fxXb
	for ; Fri, 14 Oct 2022 17:53:31 +0000 (UTC)
	(envelope-from pete@nomadlogic.org)
Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226])
	(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 "mail.nomadlogic.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MpvBf0X8sz3PLC
	for ; Fri, 14 Oct 2022 17:53:29 +0000 (UTC)
	(envelope-from pete@nomadlogic.org)
Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214])
	by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id dd7a3c9e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Fri, 14 Oct 2022 17:53:22 +0000 (UTC)
Content-Type: multipart/alternative;
 boundary="------------s0300wL4Hlzf94qw1jN4ihVg"
Message-ID: 
Date: Fri, 14 Oct 2022 10:53:21 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.3
Subject: Re: Drm-kmod and 14-CURRENT
To: Patrick Bowen , freebsd-current@freebsd.org
References: 
 
 <5fc5a86f-9bef-41a8-8127-3406f3c18ca3@app.fastmail.com>
Content-Language: en-US
From: Pete Wright 
In-Reply-To: <5fc5a86f-9bef-41a8-8127-3406f3c18ca3@app.fastmail.com>
X-Rspamd-Queue-Id: 4MpvBf0X8sz3PLC
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=quarantine) header.from=nomadlogic.org;
	spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org
X-Spamd-Result: default: False [-3.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FREEMAIL_TO(0.00)[fastmail.fm,freebsd.org];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------s0300wL4Hlzf94qw1jN4ihVg
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 10/14/22 10:14, Patrick Bowen wrote:
> Hello all,
>
> I've just used reinstall.sh to add a CURRENT boot environment to a 
> 13.1 ZFS installation. Xorg doesn't load in CURRENT, presumably 
> because the drm-kmod doesn't work with 14. I tried to build 
> drm-current-kmod from ports but the build errors out.
>
> I can send all the error messages and dmesg and such if necessary, but 
> I'm betting it's just a simple fix that I'm unaware of. The graphics 
> is i915 Intel BTW.
>

I think you want to use graphics/drm-510-kmod

this is what i use on my systems running CURRENT, it tracks the 5.10 
linux kernel.  iirc drm-current-kmod and drm-devel-kmod have been 
retired in favor of this one.

-pete

-- 
Pete Wright
pete@nomadlogic.org
@nomadlogicLA

--------------s0300wL4Hlzf94qw1jN4ihVg
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    

    
On 10/14/22 10:14, Patrick Bowen wrote:

    

    

      
      
      
      

        
Hello all,

        

        


        

        
I've just used
          reinstall.sh to add a CURRENT boot environment to a 13.1 ZFS
          installation. Xorg doesn't load in CURRENT, presumably because
          the drm-kmod doesn't work with 14. I tried to build
          drm-current-kmod from ports but the build errors out.

        

        


        

        
I can send all the
          error messages and dmesg and such if necessary, but I'm
          betting it's just a simple fix that I'm unaware of. The
          graphics is i915 Intel BTW.

        

        


        

      

    

    

    I think you want to use graphics/drm-510-kmod

    

    this is what i use on my systems running CURRENT, it tracks the 5.10
    linux kernel.  iirc drm-current-kmod and drm-devel-kmod have been
    retired in favor of this one.

    

    -pete

    
-- 
Pete Wright
pete@nomadlogic.org
@nomadlogicLA

  


--------------s0300wL4Hlzf94qw1jN4ihVg--

From nobody Sat Oct 15 11:52:45 2022
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 4MqM7z4cL3z4fS6M
	for ; Sat, 15 Oct 2022 11:52:47 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MqM7z44r7z3X2g
	for ; Sat, 15 Oct 2022 11:52:47 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1665834767;
	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=CqZVc+vheSr4R17xdKs4NwqenXcbenUMRZg8t2Ydcgk=;
	b=On3EquUm1nlC5L+7xfGLPkV4NL67KisYY5JYpBjVC6N8XNW7ORBMkOqtP/+m8gC4yA165m
	ujSazAkCwxXgukdwAhH4XcZHA54i7kxOdZ3VFoJfY++zHZ/conQ/IaCmLQD4z2fc95bs3O
	V+yd4+T13whx87CXRNc2y9zfd6gfgN3jO0I2Ai1X7etGd1zOqjhzB/ufU+rnWSh0whYSM6
	5xm4GlYQzN9OqWjLBIbkImwhpq4YOlVTVDlnNTsMmEjNlgM+8pKkKB6rQIMkEe6GGfEDsD
	YDqtArOillIjirk4u0DN5dRL6DgddMnFJP/8d3rfqNxq9CS4KVu+xWfiycV0iQ==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MqM7z20lZz1Jdp
	for ; Sat, 15 Oct 2022 11:52:47 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: <02a89817-e8c6-c80e-7dac-dd08a4ed0782@freebsd.org>
Date: Sat, 15 Oct 2022 12:52:45 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.3
Subject: Re: Drm-kmod and 14-CURRENT
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: 
 
 <5fc5a86f-9bef-41a8-8127-3406f3c18ca3@app.fastmail.com>
 
From: Graham Perrin 
Organization: FreeBSD
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------m2qiC00bVADh3EV4OVD1n90m"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1665834767;
	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=CqZVc+vheSr4R17xdKs4NwqenXcbenUMRZg8t2Ydcgk=;
	b=Ez9jRzf+nsRv4nMirDxyV/IE5NJJ2eUGQbaBpF2pP8mJOiGr6zXt+PDmbSrgkWCMQpjIWY
	IokMcmwon3XDnc0J8ajq+pjqL/P/29nBrJjj7VSVJcA+j5X3bkS++rZ9uUzdd8qZDNhK8i
	XIdTedIdjsStNkLUDxvpYEE2Ys8RR/Isb5x9tsA2zb4XkVD2MuzCs9v+ximeGeyaOIzGfy
	KJUCUpKKt8uj9VK0t3LElJ8b3Azui/VgGSqtd4qMwYzAWalnBh0z5H9j8VB9Efisnfs5oK
	a/FZTCWcfohqScxEVrue8zZkPF+aoXeUb2JC3CCLsxTqUk9hpUU7sS6ShSi6rA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1665834767; a=rsa-sha256; cv=none;
	b=fdZwaUanqaiSR7qHkQpuG8g1u9p4ppVtg5ui0EA+tSkHgkBDMVS94W4SlRZ7ZxIkykLqi6
	FFu/A/P2SfHbypuU2jA4U4XDoksVisMyk5n9x7qaDtgKaZHRbbQMkbA9Z7aN6KS4+mt+Xx
	WfbMr8bc/BeNMvbVa7Zgd1lBx0N1ymZHwTWEHAfcO+DqWjl6HRMacqwskWs2qOuXfOub1S
	RBg01GzPXFnsqRqQslRur0GkZOn3h33lywAMkbGNNkxG14OscQOhg9lrkMu7QDg2C0gGyi
	GhJwXZjykKGySBXB5oumEtKxLXQe0xwaPmYV3VJ2kNd/4+9xVYTDVXDchbnM1w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------m2qiC00bVADh3EV4OVD1n90m
Content-Type: multipart/mixed; boundary="------------zixl1a3EIvOUX8NWDydieYZF";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: <02a89817-e8c6-c80e-7dac-dd08a4ed0782@freebsd.org>
Subject: Re: Drm-kmod and 14-CURRENT
References: 
 
 <5fc5a86f-9bef-41a8-8127-3406f3c18ca3@app.fastmail.com>
 
In-Reply-To: 

--------------zixl1a3EIvOUX8NWDydieYZF
Content-Type: multipart/alternative;
 boundary="------------Dup5DRoLuD7eM60lL3z5W1tb"

--------------Dup5DRoLuD7eM60lL3z5W1tb
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTQvMTAvMjAyMiAxODo1MywgUGV0ZSBXcmlnaHQgd3JvdGU6DQo+DQo+IE9uIDEwLzE0
LzIyIDEwOjE0LCBQYXRyaWNrIEJvd2VuIHdyb3RlOg0KPj4gSGVsbG8gYWxsLA0KPj4NCj4+
IEkndmUganVzdCB1c2VkIHJlaW5zdGFsbC5zaCB0byBhZGQgYSBDVVJSRU5UIGJvb3QgZW52
aXJvbm1lbnQgdG8gYSANCj4+IDEzLjEgWkZTIGluc3RhbGxhdGlvbi4gWG9yZyBkb2Vzbid0
IGxvYWQgaW4gQ1VSUkVOVCwgcHJlc3VtYWJseSANCj4+IGJlY2F1c2UgdGhlIGRybS1rbW9k
IGRvZXNuJ3Qgd29yayB3aXRoIDE0LiBJIHRyaWVkIHRvIGJ1aWxkIA0KPj4gZHJtLWN1cnJl
bnQta21vZCBmcm9tIHBvcnRzIGJ1dCB0aGUgYnVpbGQgZXJyb3JzIG91dC4NCj4+DQo+PiBJ
IGNhbiBzZW5kIGFsbCB0aGUgZXJyb3IgbWVzc2FnZXMgYW5kIGRtZXNnIGFuZCBzdWNoIGlm
IG5lY2Vzc2FyeSwgDQo+PiBidXQgSSdtIGJldHRpbmcgaXQncyBqdXN0IGEgc2ltcGxlIGZp
eCB0aGF0IEknbSB1bmF3YXJlIG9mLiBUaGUgDQo+PiBncmFwaGljcyBpcyBpOTE1IEludGVs
IEJUVy4NCg0KUGF0cmljazogd2hpY2ggdmVyc2lvbiBvZiBGcmVlQlNELCBleGFjdGx5Pw0K
DQpmcmVlYnNkLXZlcnNpb24gLWtydSA7IHVuYW1lIC1hS1UNCg0KDQo+IEkgdGhpbmsgeW91
IHdhbnQgdG8gdXNlIGdyYXBoaWNzL2RybS01MTAta21vZA0KPg0KPiB0aGlzIGlzIHdoYXQg
aSB1c2Ugb24gbXkgc3lzdGVtcyBydW5uaW5nIENVUlJFTlQsIGl0IHRyYWNrcyB0aGUgNS4x
MCANCj4gbGludXgga2VybmVsLsKgIGlpcmMgZHJtLWN1cnJlbnQta21vZCBhbmQgZHJtLWRl
dmVsLWttb2QgaGF2ZSBiZWVuIA0KPiByZXRpcmVkIGluIGZhdm9yIG9mIHRoaXMgb25lLg0K
DQpUcnVlLCBkcm0tY3VycmVudC1rbW9kIGFuZCBkcm0tZGV2ZWwta21vZCB3ZXJlIGRlbGV0
ZWQgb24gMXN0IE1heSAyMDIyOg0KDQo8aHR0cHM6Ly9naXRodWIuY29tL0ZyZWVCU0QvZnJl
ZWJzZC1wb3J0cy9jb21taXQvZmFlOWU0OWRkNjNmNDExOTgzY2M5YTdmNjJmMGZhODQxODc5
N2IzNT4NCg0KZ3JhcGhpY3MvZHJtLWttb2QgaXMgYSBtZXRhLXBvcnQgdGhhdCBkb2VzIHdv
cmsgb24gRnJlZUJTRCAxNC4wLUNVUlJFTlQuIA0KN3RoIFNlcHRlbWJlcjoNCg0KPGh0dHBz
Oi8vZ2l0aHViLmNvbS9mcmVlYnNkL2ZyZWVic2QtcG9ydHMvY29tbWl0L2UyMzZjOTk0YmM4
N2EzYmU2N2YwMzBiNWM3YzZmZjcyZGYxMTlhYzU+IA0KDQoNCmdyYXBoaWNzL2RybS1rbW9k
IHNob3VsZCBhdXRvbWF0aWNhbGx5IGluc3RhbGwgZ3JhcGhpY3MvZHJtLTUxMC1rbW9kLiAN
ClBhY2thZ2VkOg0KDQo8aHR0cHM6Ly93d3cuZnJlc2hwb3J0cy5vcmcvZ3JhcGhpY3MvZHJt
LTUxMC1rbW9kLyNwYWNrYWdlcz4NCg0KVGhlIHBhY2thZ2Ugd2FzIGJ1aWx0IGluIGEgMTQw
MDA3MiBqYWlsIGVudmlyb25tZW50IG9uIGEgMTQwMDA2MyBob3N0Og0KDQo8aHR0cDovL2Jl
ZWZ5MTgubnlpLmZyZWVic2Qub3JnL2RhdGEvbWFpbi1hbWQ2NC1kZWZhdWx0L3A3M2NhYWIy
Mzc1NDNfc2FiOTI5MzIzOWMvbG9ncy9kcm0tNTEwLWttb2QtNS4xMC4xMTNfNy5sb2c+DQoN
Cg==
--------------Dup5DRoLuD7eM60lL3z5W1tb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 14/10/2022 18:53, Pete Wright wrote=
:

    

    

      
      

      
On 10/14/22 10:14, Patrick Bowen
        wrote:

      

      

        
        
        

On Sat, Oct 15, 2022, at 6:52 AM, Graham Perrin wrote:
On 14/10/2022 18:53, Pete Wright wrote:

On 10/14/22 10:14, Patrick Bowen
        wrote:
Hello all,

I've just used
            reinstall.sh to add a CURRENT boot environment to a 13.1 ZFS
            installation. Xorg doesn't load in CURRENT, presumably
            because the drm-kmod doesn't work with 14. I tried to build
            drm-current-kmod from ports but the build errors out.

I can send all the
            error messages and dmesg and such if necessary, but I'm
            betting it's just a simple fix that I'm unaware of. The
            graphics is i915 Intel BTW.
Patrick: which version of FreeBSD, exactly? 
freebsd-version -kru ; uname -aKU

Graham,

14.0-CURRENT
14.0-CURRENT
14.0-CURRENT
FreeBSD Thanos 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n258598-07b1ea961af: Thu Oct 13 17:48:02 CDT 2022     root@Thanos:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1400072 1400072

I
      think you want to use graphics/drm-510-kmod
 
 this is what i use on my systems running CURRENT, it tracks the
      5.10 linux kernel.  iirc drm-current-kmod and drm-devel-kmod have
      been retired in favor of this one.
True, drm-current-kmod and drm-devel-kmod were deleted on 1st May
      2022: 
<https://github.com/FreeBSD/freebsd-ports/commit/fae9e49dd63f411983cc9a7f62f0fa8418797b35>
graphics/drm-kmod is a meta-port that does work on FreeBSD
      14.0-CURRENT. 7th September: 
<https://github.com/freebsd/freebsd-ports/commit/e236c994bc87a3be67f030b5c7c6ff72df119ac5> 
graphics/drm-kmod should automatically install
      graphics/drm-510-kmod. Packaged: 
<https://www.freshports.org/graphics/drm-510-kmod/#packages>
The package was built in a 1400072 jail environment on a 1400063
      host: 
<http://beefy18.nyi.freebsd.org/data/main-amd64-default/p73caab237543_sab9293239c/logs/drm-510-kmod-5.10.113_7.log>

Attachments:
  • OpenPGP_signature

-- 
  Patrick Bowen
  pbowen@fastmail.fm



--f5e88cde8dd845b289abeec55361331d--

From nobody Sun Oct 16 14:59:28 2022
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 4Mr3FP4s3Tz4fPBd
	for ; Sun, 16 Oct 2022 14:59:53 +0000 (UTC)
	(envelope-from dch@skunkwerks.at)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mr3FN6hl4z3SSY
	for ; Sun, 16 Oct 2022 14:59:52 +0000 (UTC)
	(envelope-from dch@skunkwerks.at)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
	by mailout.west.internal (Postfix) with ESMTP id 16A4D3200583;
	Sun, 16 Oct 2022 10:59:51 -0400 (EDT)
Received: from imap44 ([10.202.2.94])
  by compute2.internal (MEProxy); Sun, 16 Oct 2022 10:59:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at;
	 h=cc:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm1; t=1665932390; x=1666018790; bh=JeB9dulCxT
	rVOq33GZKsojPPz7pRldelpRr2fd01blw=; b=zOczN1ythbwO5sR0LQDeDO1Xj8
	IsY7urAb50QKQzFhnwnXkdqczMoN+Equ27hWe9dnMPde9AI4QUdKOf60+wTxMBNP
	lK16LRfYe04U/CF8fGcEgNSL0Cji4RSBy3fMI/WuGqJKGOruCzicxJWM0ueCzxpr
	0Ual1YTVVvYMkc21bFbh1LSQUex+m3iAEmPfNr+Pu8S/7dq/2a4SuFEnj7yza1+/
	tPbpswENaFfBAm7e6hIHYSzAcwk+HnJvV+zBcjF4hn800OxEPO287NlIEvCSf5lp
	6sIQ5XPi43JD4LpIRoZL7ZfQBAtksMJ3VlY3TdubqRNzYrYvMoH4FnUCqgiA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:in-reply-to:message-id
	:mime-version:references:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm3; t=1665932390; x=1666018790; bh=JeB9dulCxTrVOq33GZKsojPPz7pR
	ldelpRr2fd01blw=; b=U09weGCAdAcursOo3xiqOz4yvJCQmZaNa1roK3pnAD9x
	4oXL/2X97Q/svTuJZqdvcizIbGTe/hXJRrnSqFLI9atuZisikPa5mgTahF91ZO5r
	6bEeg+iSfT1K3SuRuit//U/QZdRxwQckk2NfPVgTBLZePJrWhmUEDCOlLCrZ9QfN
	RkhVHHd4pCBW13Y3F+ChgjSX767pMB0Co9sfNfUTBXEoAhHYyYNtVjn33pJk9NnG
	T6dHJX0s488EFCQyV4B84cmAs81Hc+BRmhPRwSJPVsBbDjZJPiZFkheoD1cwIWEs
	PDmoBqM4Oj/aIf98rLNaSEQmz+GQEkB/Xzklf40O0Q==
X-ME-Sender: 
    
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeekjedgkeegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
    cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdffrghv
    vgcuvehothhtlhgvhhhusggvrhdfuceouggthhesshhkuhhnkhifvghrkhhsrdgrtheqne
    cuggftrfgrthhtvghrnhepkefffedvfeetkeffgefgffdvfeeugfeuhffhhfdufedvtefg
    ieelueejffehvdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh
    hfrhhomhepuggthhesshhkuhhnkhifvghrkhhsrdgrth
X-ME-Proxy: 
    
    
    
Feedback-ID: ic0e84090:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501)
	id 2F72C36A0073; Sun, 16 Oct 2022 10:59:50 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1047-g9e4af4ada4-fm-20221005.001-g9e4af4ad
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
Message-Id: <2f1ee31b-8704-40eb-9823-73b1050df62d@app.fastmail.com>
In-Reply-To: <16f828bc-725a-4e20-bc3c-20e1732d8741@app.fastmail.com>
References: 
 
 
 <5fc5a86f-9bef-41a8-8127-3406f3c18ca3@app.fastmail.com>
 
 <02a89817-e8c6-c80e-7dac-dd08a4ed0782@freebsd.org>
 <16f828bc-725a-4e20-bc3c-20e1732d8741@app.fastmail.com>
Date: Sun, 16 Oct 2022 14:59:28 +0000
From: "Dave Cottlehuber" 
To: "Patrick Bowen" ,
 freebsd-current 
Subject: Re: Drm-kmod and 14-CURRENT
Content-Type: text/plain
X-Rspamd-Queue-Id: 4Mr3FN6hl4z3SSY
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=skunkwerks.at header.s=fm1 header.b=zOczN1yt;
	dkim=pass header.d=messagingengine.com header.s=fm3 header.b=U09weGCA;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 64.147.123.21 as permitted sender) smtp.mailfrom=dch@skunkwerks.at
X-Spamd-Result: default: False [-4.09 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21];
	R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm1,messagingengine.com:s=fm3];
	RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from];
	MIME_GOOD(-0.10)[text/plain];
	XM_UA_NO_VERSION(0.01)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_TO(0.00)[fastmail.fm,freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_ALL(0.00)[];
	FREEFALL_USER(0.00)[dch];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+];
	DMARC_NA(0.00)[skunkwerks.at];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	ARC_NA(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, 15 Oct 2022, at 20:57, Patrick Bowen wrote:
> On Sat, Oct 15, 2022, at 6:52 AM, Graham Perrin wrote:
>> On 14/10/2022 18:53, Pete Wright wrote:
>>> 
>>> On 10/14/22 10:14, Patrick Bowen wrote:
>>>> Hello all,
>>>> 
>>>> I've just used reinstall.sh to add a CURRENT boot environment to a 13.1 ZFS installation. Xorg doesn't load in CURRENT, presumably because the drm-kmod doesn't work with 14. I tried to build drm-current-kmod from ports but the build errors out.

Try bumping your ports drm-510-kmod to 0b1394a6 (1 Oct).

I bumped my i915 14.0-CURRENT laptop this morning and
did not get Xorg starting either until rebuilding latest
5.10.113_7 drm-510-kmod before it worked again.

A+
Dave

From nobody Sun Oct 16 17:51:37 2022
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 4Mr73c0VYFz4fjSs;
	Sun, 16 Oct 2022 17:51:40 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mr73b0kqbz3rGF;
	Sun, 16 Oct 2022 17:51:39 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: by mail-vs1-xe2d.google.com with SMTP id k6so9525060vsc.8;
        Sun, 16 Oct 2022 10:51:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :references:in-reply-to:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=sxK6oqqPu5Ol/+0lvQQb486TkPrbd/nR/j3PEc89wpc=;
        b=ZvDB0N1uFEBI+FXd6sTcml7XKWx05YWd1QUthGf647nBWAw31EpdUn5TTNsR2mfVkz
         8GL032D9ObegT8kgwNe/QFGsie9iXzoqgIMlUZGyF7by+zJj0IXaaRgJdrJ6pykaFNsk
         /6beaZjP9hZzRocJ64GM/tHzN9Cov8n6mkBYKzlhjL7HgUvHPty+2uAg3OO0pkTDI2Sh
         7K7bRCuHZN6DqoZ2xtSoeDyDEl2kkaJziUP5BjE31vmh9GHKvX8tJzbYgLNxjkmbWwBE
         LkYtFmMeMo/vOas4XSZ7iyydcqGDN2YqQxG4nlD7Q+TR5W+BXyGfiDuqVYahKJlQVfDj
         I45g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=sxK6oqqPu5Ol/+0lvQQb486TkPrbd/nR/j3PEc89wpc=;
        b=Frmukbhot5iY95kQxoxHBZ7gmsXipc3ijH5yJsZ5nt6mtv4XH764xfO8T3yqTQELJ8
         GpkaBssurU1pW6tOUryxW8FjsLAOJrCm8ystv4n3WHQ/LOCGFpu4B4zeV3IDiahgmc2l
         gRygL9vKlKdbNu3Vq1M/CtyPVpTt4a29jeXyilwe7T9WY5loslX5ycAxuQFf9HfGv75S
         Ns37KlkLFAEZBJGz2qI3Q6xqGfdCuuwxzSSh4cpALcsfkPcGiTRccE4gXYkcdj7ZB2jv
         85VNY+QNojHoQTL07Ekvf5ler/X5cK1vOJZKwmC66Xk/WKJ9bYAdE2LawQ4igWN5n4y+
         T9fQ==
X-Gm-Message-State: ACrzQf38opa/zn4yesMTHk7kFOuBCFKNcC/s7+uELyPdKknq43TszZ3Z
	shBefVMsyfY/NLa5zh4fm4ShAc+e18Wa7eFPhrTwzXyHHkyxH9lu
X-Google-Smtp-Source: AMsMyM7rGNZVK6c6m3A/OtlWqEaMQ+L0yi0iNVkbGmt1/neZ5YDA1Oa+Rr+HMlyhGYkCN65emFoBW35C5WnkPrSVHEw=
X-Received: by 2002:a67:b74a:0:b0:399:4161:9f94 with SMTP id
 l10-20020a67b74a000000b0039941619f94mr2494132vsh.1.1665942698019; Sun, 16 Oct
 2022 10:51:38 -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
Received: by 2002:a59:8cd1:0:b0:319:151e:7726 with HTTP; Sun, 16 Oct 2022
 10:51:37 -0700 (PDT)
In-Reply-To: <86czbwryx0.fsf@ltc.des.no>
References: <86h718sqdx.fsf@ltc.des.no> 
 <86czbwryx0.fsf@ltc.des.no>
From: grarpamp 
Date: Sun, 16 Oct 2022 13:51:37 -0400
Message-ID: 
Subject: Re: Putting OPIE to rest
To: freebsd-security@freebsd.org
Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, 
	freebsd-stable@freebsd.org, freebsd-questions@freebsd.org, des@des.no
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4Mr73b0kqbz3rGF
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=ZvDB0N1u;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::e2d as permitted sender) smtp.mailfrom=grarpamp@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_LONG(-0.99)[-0.993];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2d:from];
	MLMMJ_DEST(0.00)[freebsd-security@freebsd.org,freebsd-hackers@freebsd.org,freebsd-current@freebsd.org,freebsd-stable@freebsd.org,freebsd-questions@freebsd.org];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_FIVE(0.00)[6];
	RCVD_TLS_LAST(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

On 9/15/22, Dag-Erling Sm=C3=B8rgrav  wrote:
> Neither HOTP nor TOTP require dedicated devices.
> HOTP codes are sequential and can be pre-generated...

Those aren't really their intended or advertised usage models,
nor do common implementations support those modes.
Is FreeBSD contributing and supplying ones that do?
OPIE's model already intends for and supports no-device and printout.

To emphasize and extend...
https://lists.freebsd.org/archives/freebsd-current/2022-September/002573.ht=
ml

It should also be noted that the affected scope here is not just 'FreeBSD u=
sers
logging into FreeBSD shell', there are also applications out there that com=
pile
against and use FreeBSD's libopie, some of which are in ports some are not.

OPIE does not exist as a port+package, thus re POLA for users,
it should not be removed until such time as one is provided.

Where is discussion on these.

And why isn't every other 'old, outlived, non-hipster' pam
authentication plugin being
arbitrarily removed and non-portified, such as say tacacs, radius,
krb, rhosts, etc.
And if those pam are there, why then are hip OAUTH HOTP TOTP etc type thing=
s
not added, lib-ified, etc.

From nobody Mon Oct 17 14:08:11 2022
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 4Mrf3P5qbSz4g39D
	for ; Mon, 17 Oct 2022 14:08:17 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mrf3N4DRcz3Bn8
	for ; Mon, 17 Oct 2022 14:08:16 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
	by mailout.west.internal (Postfix) with ESMTP id 9658C3200915
	for ; Mon, 17 Oct 2022 10:08:14 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
  by compute2.internal (MEProxy); Mon, 17 Oct 2022 10:08:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:message-id
	:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=
	1666015694; x=1666102094; bh=888ROFLDTp/G/uslJGxdFQd+c7PBYFn8CZx
	xgAveWl0=; b=MDEnZS7NcqbMasa4T6sfq1ucn66DsWpvz2QahFmS8uFyE1PZqbI
	aPK2ITy1kgVLePaW9OK6yyswvzp8d+BJQuHHFvbPLYbCQPR5SgjKRX/6rha2jZU+
	88wDdNzmGuAkLarvK9JyhS0YHQeZkt5rT1DLrJsNhNSkTb46zKNtPgqBoIdWgC1x
	EhrVc0c6EQXdt/AtODxgSEsBDpoqed+FdlCo1dd9Yy97LcgunJD3rZS0nZJS3z+g
	QE7rg/Kh/5r2v1at1Nb+PHe5uvwcEeDMuHcKp9k1wq79GqWBtoHV9eh0X3rzMdpb
	7Zo3NVJCnSyB91t1hxmZghC30AwX1/UHJnA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:message-id:mime-version
	:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1666015694; x=
	1666102094; bh=888ROFLDTp/G/uslJGxdFQd+c7PBYFn8CZxxgAveWl0=; b=D
	f4eoVSWSkdltg2O2Qs2IdcMxcSAaDlYCddP6Ahw4cXdSiWPqMGqCVCLMs0fSWoSU
	+w/ZapNTe0Z/T5Gwh3k6Bqrve7PRCOIhcwtN5B+EECHwoQWk795J1d0l+obaltEp
	YDdVh/KWcv9B6kzfVb0yCMThSukqKs4k7O4gnDR/oSyAAffw7TiDMZ+OrXRhZtGq
	OGw5ULtljt9+2wCs4OrroYyFPnIk8H+MaMA69joTiPCZrY7dzdDfyC+h5o0X+Wmh
	/4mnYCch+fUjI/mfBPoviKlvKSAnr68nzpQykVge8KFVP1t4QlenfMA5llWjiGVw
	PVJFN56ikxz4duKl1pwxA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeekledgjeduucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd
    dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht
    vghrnhepkeefudfggfeiueeiffehgfdvffejuddvhfdvieefledvjedthfdvheejhffgle
    eunecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgep
    tdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Mon, 17 Oct 2022 10:08:13 -0400 (EDT)
Date: Mon, 17 Oct 2022 15:08:11 +0100
From: void 
To: freebsd-current@freebsd.org
Subject: pkg won't bootstrap on -current
Message-ID: 
Mail-Followup-To: freebsd-current@freebsd.org
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
X-Rspamd-Queue-Id: 4Mrf3N4DRcz3Bn8
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm3 header.b=MDEnZS7N;
	dkim=pass header.d=messagingengine.com header.s=fm3 header.b="D f4eoVS";
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.19 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-4.58 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	NEURAL_HAM_SHORT(-0.48)[-0.482];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3];
	R_SPF_ALLOW(-0.20)[+ip4:64.147.123.19];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.19:from];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	MIME_TRACE(0.00)[0:+];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_COUNT_THREE(0.00)[4];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

It seems pkg won't bootstrap on -current, at least not for me on arm64.aarch64
I've not tried yet with just a snapshot.

version is main-n258626-865f46b25559 built today 17th Oct 22.

The error is
# pkg bootstrap
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:aarch64/latest, please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Child process pid=10086 terminated abnormally: Segmentation fault

tried installing the port

/usr/ports/ports-mgmt/pkg# make install
===>  Installing for pkg-1.18.4
===>  Checking if pkg is already installed
===>   Registering installation for pkg-1.18.4
Child process pid=37844 terminated abnormally: Segmentation fault
*** Error code 139

Stop.
make[2]: stopped in /usr/ports/ports-mgmt/pkg
*** Error code 1

# which pkg-static
/usr/local/sbin/pkg-static

# /usr/local/sbin/pkg-static bootstrap
Child process pid=39006 terminated abnormally: Segmentation fault

There's a core file. lldb is installed. if someone can clue me in to how it's used,
i can supply more info

There's nothing in /var/db/pkg

TIA for any clues

From nobody Mon Oct 17 16:53:50 2022
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 4MrjkW2mF6z4Zvs8
	for ; Mon, 17 Oct 2022 16:53:55 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MrjkV3kRGz3Y3K
	for ; Mon, 17 Oct 2022 16:53:54 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666025632; bh=2YUF3R7h1rqdQMXBurZmpGgXzFWAjGH0YL42EacEGFQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=G/hMAvPga/M7qxGrcKn3zq0g0/sZYr+yoCRl/oj+vxq2bQCAr+2Wr1/YWpnDg1zUuOrtR1wlhGxDmQN+kxVOKOM9nRefKC7BdTjqXsWV/swU9FQNoQH2EdIRFBwGY/E9BzbxvWIxSy662aXPeJQpo8CBy9O4hjVAZBoEyQz7jj2X0BG6gsYK7qNgCbkQe8B1PMnlDpqtqKyaBERThFtwztYOYBR2YZDCqp+5Y6uUe6CHWzlqq09PlObjLZqrZ5KGvPOuW3AefGtkxp47bS3nZYnKEUCg0NcqHDsCy65/5YZwzdZl4XiUPFEOt12JM2LmBmGQw2iG1GUFulxRcemp8A==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666025632; bh=urC1/grqjJEtpS9tfwHPKn9xlnRQtqOTx7NdnACm4Rq=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=nQWyrghu4PcdMW6ItJEpGi3VcXi/guELV62pFlohMIsufK/PtIoj/LRGGFM7cMMz9bgGWxW5RkvTRptsVEWaeKQy94GPgKAZVGlDaVLe+Q5sNLHjNMABFfuWF03v/CuxGWhzj167GGe2QFD/BgeQDh9haAD5AzLrgzUtn72Y/zm7ZL+nzegTJrLzf2BzwacdeYeklgERLJwQt88U/x2BExz2CfBUGd7TWZJvhzHtHQt/ghvPH+2il2FIFMnY1CYRce0n3sRrT/Kzb9y9eZ/CD+qhe/uxJ9At/Z64mucIfDXPSyphpkYjhissel29ezS+XJ40IPisDvYrvEjspZLGZQ==
X-YMail-OSG: h51rVuQVM1kOQHGD1iA9b2FI.a_wZGCUv5oIqwcLvBXcuR9j7pq75ImN7UNQFvp
 TR666I_y0cfH3B0ANMb5zrpgMpaqp_AAvuLhSkQNkZq6B4ryBmql4ZkONliLop2FvQAzcC5gN.Fq
 OLCWJtjlFwj31ocpTQwKickl0GT8.Zsz1yCMmFx5haGN0AQsmZ0u3mRdB0lJyV_GZtHmKK.YF4PJ
 EhR_oJQbnWNbdq6y6SSpNbVphruL2SDY8P6n49nZFp2gcmmjfKgbJBMqr..IYExv2u3bh.hUWuIF
 Zn1j8dVSJOl._CRdzYab4W9KlnCfcigVOuyM5M8pcbv7uXXV1ZHhYrZVtiCAmDj2Oyw1e.DimG1B
 vUDhW8npSp8XPHGrw7EIbnXKbVr70XxkcZ1_y885nI5O3v4RlaXV7PBreuUZ0y3ElyfnZRLJhtBI
 8jFNAPbs2r4hPwMyIgz_hikKo8LZiC7fdWDsG9ydVVRvhRF7U4lJXllKkoEZDOjpx8e98oJziAlu
 ZXQ.KmayojzbxFhnYUpSKmgqDQAMATxcGQCviWnC_AxZK4RBfbRv_dgq.DgBY.feVSRVgnHZ2l06
 aogkKW88AjEXoI93yoxvZ1jErd2o0U1Ql7aoDm_dl87TIwP4Fb_LFemgFx_mehXD8Hv_vikCfLHn
 LfTlNeG0WjhlN9M.XV3Es6LrW.En7dP6rN3Q6Hqx9.sNBuK_We6jRRGi8WTdrCNo7gMC0WGqhnvs
 .nmTPx2F9YsCc7HfZf4._67.gY7aNi5tL93Yp1KEYf7Nvk6Sy2ZL01QKTDf0t32LeUOxMsrNupuR
 QOdCbLjNBTEKGW5ynIu9M7eRnCJI01g_pD2Y5nnROcaum08E8o0xUZpg2K.GTKnMEFpI_.YlHuVX
 bi0FyHOw8y1V4mXYhN.cs5ijDl3.bM8BWb7ZUrxg9gJ2tWMY.LdwGgANBEfztF5Hy049QiEcybfS
 YFtc8v_fh0NdUjzdmkGbloT5DYU0flCzFPwmFbBl1VVONufafXEB4CRui.9tnQxlQkvp9.Zbl_pb
 sm6408N5gLrnvAL1a5S7uRkn15U84IiKti_v7pzRaT_pKgpALmOwgSA2KFwl.tFSXWIJ1EaOwZwh
 36ly_4cPGkjbivWGde9ERF5e7iPAjAx4bC2RM_pGQxZPHZgpqKoDZHJJIwX.2n6kdG6rneT.ilo2
 9mJ0r0shbST8pDhd0SvZAv9Lru6y3bLN.PMCkBIPm7jntlMpbVBlMsEPq32M1rhTEF0TRnCzyJlq
 qKsnHh_prKEfh8Fxk_dNOPeXmUzHSukFNn7o8wHtYpWZQGUB.X0w4VGVcTwOUGaEXL8fSXYDJ2Cd
 ltD06xCKL1nkGtoa0ziBWrvV7mmkjwryzn3VNNmpDBqNXNWUbijz57LVESrFaxgQ3z53P3hyFWRh
 MBTDiIxOK7dMSI46bdjRdD_64keKYBL_pvxO15TQpSQA_mn8dkE5UChNpM6QlwwfoMLDJlAKZYJW
 jWYUqBZB8G7WNCNay5_HIBsamwSKl6J_wtNDnqBG9RtRCV4POQ4znvBJt4WrgjKKB2ACvyJ564vT
 U5DBwTBJtOuOwoxTHM7JJtOU0JYq8fTZ.Dek2NUURfn6vdtOWonv2Od8tEn8SSMgdVOqroA4qYGf
 UFT_pZO1sVV8KWy.THsg979.ZFjvuLcVhCSpnWZTMWzzWOGU0iaaiH_NN7NOqDrqYU1W2wCqCTGk
 rt.rQW9KbR1YhNGz._csySh9BiubNiC2j_vVFGYV47Lc2weAEX1WYS9XrP6eDJRLpsV3uJaJY2Ai
 IT5.XaexS4cpjJRGkINw0_fD83gNnuRFOpVkt7SEkHtuAeJaEpd6I9cglZS_eRzOuq4U09rQLWwJ
 Ysz0gQ7FsXWKaiW_jX71eo58TJfmtnlxML9D6NoEpYKCUP9_6Xofd96Tl9m06xNNVCLeLf8UuT1R
 jjCEjoeBAbk7WX6RV21lPlxQgtg79rPGEN8ULDTMu_vPDniGc6TYBnQ6HeXUoHNeXJ9Zv3LwoNbk
 EzmBqN5WmcjzICrudp89iblWIQk480qqi2FzAVSiwWcWlFkQY1jvj2DejU.ZrxDfFWUiKFH34s5l
 YMhzKVHw2dkDg6hkcuwmNlY.IEhU3kLzviFJzFNZeGeTbXhP8SxE_s3Etsge6rORfLwYLy9aGIdz
 AeJHJeASvauSweRDRNsoV2QhXg34nCUtnMXOvmExK3.hdsN4ZzFnovaUeGXEOqdAhrG5qeZ5pTxO
 1_hFlQ___4McVQO8pe6.rm1AalLJ.eWuT3u4BhOFy9F_yrdUL8vcD8yQ_tN8YesZiMgiJsc1O8QH
 zzXWExat2XKfYUYeFSBP.4Q--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 17 Oct 2022 16:53:52 +0000
Received: by hermes--production-gq1-75cfcccdb-kcc9l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ecc4d7ad476043ac682eff5617169993;
          Mon, 17 Oct 2022 16:53:51 +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 \(3696.120.41.1.1\))
Subject: RE: pkg won't bootstrap on -current
Message-Id: <15240B12-7B81-42B1-BA8E-170021D0B8E4@yahoo.com>
Date: Mon, 17 Oct 2022 09:53:50 -0700
To: void ,
 freebsd-current 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
References: <15240B12-7B81-42B1-BA8E-170021D0B8E4.ref@yahoo.com>
X-Rspamd-Queue-Id: 4MrjkV3kRGz3Y3K
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="G/hMAvPg";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.97)[-0.970];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_TO(0.00)[f-m.fm,freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

void  wrote on
Date: Mon, 17 Oct 2022 14:08:11 UTC :

> It seems pkg won't bootstrap on -current, at least not for me on =
arm64.aarch64
> I've not tried yet with just a snapshot.
>=20
> version is main-n258626-865f46b25559 built today 17th Oct 22.
>=20
> The error is
> # pkg bootstrap
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]: y
> Bootstrapping pkg from =
pkg+http://pkg.FreeBSD.org/FreeBSD:14:aarch64/latest, please wait...
> Verifying signature with trusted certificate =
pkg.freebsd.org.2013102301... done
> Child process pid=3D10086 terminated abnormally: Segmentation fault
>=20
> tried installing the port
>=20
> /usr/ports/ports-mgmt/pkg# make install
> =3D=3D=3D>  Installing for pkg-1.18.4
> =3D=3D=3D>  Checking if pkg is already installed
> =3D=3D=3D>   Registering installation for pkg-1.18.4
> Child process pid=3D37844 terminated abnormally: Segmentation fault
> *** Error code 139
>=20
> Stop.
> make[2]: stopped in /usr/ports/ports-mgmt/pkg
> *** Error code 1
>=20
> # which pkg-static
> /usr/local/sbin/pkg-static
>=20
> # /usr/local/sbin/pkg-static bootstrap
> Child process pid=3D39006 terminated abnormally: Segmentation fault
>=20
> There's a core file. lldb is installed. if someone can clue me in to =
how it's used,
> i can supply more info
>=20
> There's nothing in /var/db/pkg


[Summary: I got no problems bootstrapping pkg via
the snapshot dated 20221014 in its .img file name.]

I dd'd over the most recent aarch64-RPI snapshot:

FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221014-2e0e2739273-258600.img

and booted it in an 8 GiByte RPI4B (with an EtherNet
connection in place):

# uname -apKU
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 =
main-n258600-2e0e2739273: Fri Oct 14 09:50:23 UTC 2022     =
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC =
arm64 aarch64 1400072 1400072

I tried bootstrapping pkg:

# pkg bootstrap
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from =
pkg+http://pkg.FreeBSD.org/FreeBSD:14:aarch64/latest, please wait...
Verifying signature with trusted certificate =
pkg.freebsd.org.2013102301... done
Installing pkg-1.18.4...
Extracting pkg-1.18.4: 100%

It executes just fine:

/usr/local/sbin/pkg-static info pkg
pkg-1.18.4
Name           : pkg
Version        : 1.18.4
Installed on   : Fri Oct 14 10:49:12 2022 UTC
Origin         : ports-mgmt/pkg
Architecture   : FreeBSD:14:aarch64
Prefix         : /usr/local
Categories     : ports-mgmt
Licenses       : BSD2CLAUSE
Maintainer     : pkg@FreeBSD.org
WWW            : https://github.com/freebsd/pkg
Comment        : Package manager
Options        :
        DOCS           : on
Shared Libs provided:
        libpkg.so.4
Annotations    :
        FreeBSD_version: 1400072
Flat size      : 31.8MiB
Description    :
Package management tool

WWW: https://github.com/freebsd/pkg

# pkg info pkg
pkg-1.18.4
Name           : pkg
Version        : 1.18.4
Installed on   : Fri Oct 14 10:49:12 2022 UTC
Origin         : ports-mgmt/pkg
Architecture   : FreeBSD:14:aarch64
Prefix         : /usr/local
Categories     : ports-mgmt
Licenses       : BSD2CLAUSE
Maintainer     : pkg@FreeBSD.org
WWW            : https://github.com/freebsd/pkg
Comment        : Package manager
Options        :
        DOCS           : on
Shared Libs provided:
        libpkg.so.4
Annotations    :
        FreeBSD_version: 1400072
Flat size      : 31.8MiB
Description    :
Package management tool

WWW: https://github.com/freebsd/pkg


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


From nobody Mon Oct 17 16:59:36 2022
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 4Mrjs56Vdxz4ZwGF
	for ; Mon, 17 Oct 2022 16:59:37 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mrjs561Nkz3ZtM
	for ; Mon, 17 Oct 2022 16:59:37 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1666025977;
	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=6N+taiQlN/nUorgHLB54mS8zrVz8317nSdzt3D679Us=;
	b=ZSda9C/583e858fY/9yxHXRlfdCC4N/mMjrNEyxxFNALOq2O8sTJpTfogpa/MfbyFgrAmT
	Vg+CQgVaFP4F3Ghu/XtnVXcTS+WX+Em/bTa2dtDu2n2ib0nDc8dZJ46Fkr6De2ZX4ovyic
	G7zingUqffHZVTkGEMWjKiE3eqoZM+JMmC7Jb/KM5SQAcO+fQYrIskh4DgQvtJVrqb3y+V
	jF00XS1v1mMkGdK35h9L0MSeJIgclfrnHpDhyV/xMm8hiIsYyiCZ/0V6DGN3RiuZabXF+2
	PadCJtrpx1Qa3YM5Ntn0UD5ZJRz8yhAcxM9g4w2G2wpRzNTrvSvxO07NpXgD8g==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mrjs53g87z1Tvc
	for ; Mon, 17 Oct 2022 16:59:37 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: 
Date: Mon, 17 Oct 2022 17:59:36 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.0
Subject: Re: pkg won't bootstrap on -current
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: 
From: Graham Perrin 
Organization: FreeBSD
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------4YwjSCL140Jsh0Ijfxex98Zd"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666025977;
	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=6N+taiQlN/nUorgHLB54mS8zrVz8317nSdzt3D679Us=;
	b=lXg1/HbTEfp9nmB+x2eRTD9iAO8SzF1W8Ftc8OOYk8UrZ2Fi7p4HxAIiteymt9CcUIApXn
	Fjc1yikl+MmaL6GK3IF8wajgX07szhJ9fXmuErnKBvXQCGCKc16h5gghq1jyiwlBxRGNHq
	3BxC3LCm1Gs0LvQvAJxUtBNbhDGUmRAjSRziaxjVscBRkZ77qy3qXm138cSiBWJclHjVYZ
	SefAcpNecJjHEYhPOohDov4rJKCs0shoP8jKiuh/vMFEHvt9OBmn2mM202WiFeTSMV0RwB
	VkFtMft/5VCGn+qTUwX/jnI6lZMYDAUsZgvtrjepStrc+E3ao9oQig5F91NwXQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666025977; a=rsa-sha256; cv=none;
	b=rkE3NIHpA2RsT9qqB7Cnv1BlFAPTFh5YcA7XR8pu030JfAY1bD1zDX6HL/z7HoXv7gx0ws
	QaiCqI6Gcx0zHSaEBH9p2xQwb2nguLbRQOKzU39FuBuiKfqB2TlSR4g1YrE8ZqXDgZyRh+
	7RaovJJQ6Wr86ibnw2N9CEB/UEc/wnBdtpSMUPaiFwYS7/I+NAn2HcaLAW9CyDkUj3n9hA
	jxiKuE3SBAS7SwgnDS0NpA2uOa57mpBE8A2V3cEPnMoHk0mBl2h5QjbgGMvoZBsyAZbhpY
	o0/WQ/305c7+CuAi2CJhHaAXNM8KDW88KrYtthj16b92NvP5zACq4LCHUW+24g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------4YwjSCL140Jsh0Ijfxex98Zd
Content-Type: multipart/mixed; boundary="------------1MOmQkK6qP020unMOwmA7f7o";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: 
Subject: Re: pkg won't bootstrap on -current
References: 
In-Reply-To: 

--------------1MOmQkK6qP020unMOwmA7f7o
Content-Type: multipart/alternative;
 boundary="------------TAbCLXuKgYw2El0ZurKrS93g"

--------------TAbCLXuKgYw2El0ZurKrS93g
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMTcvMTAvMjAyMiAxNTowOCwgdm9pZCB3cm90ZToNCj4g4oCmIGFybTY0LmFhcmNoNjQg
4oCmDQo+DQo+IHZlcnNpb24gaXMgbWFpbi1uMjU4NjI2LTg2NWY0NmIyNTU1OSBidWlsdCB0
b2RheSAxN3RoIE9jdCAyMi4NCkluIGNvbnRleHQ6IDxodHRwczovL2NnaXQuZnJlZWJzZC5v
cmcvc3JjL2xvZy8/cXQ9cmFuZ2UmcT04NjVmNDZiMjU1NTk+IA0KYXJvdW5kIHR3ZW50eSBo
b3VycyBhZ28uDQo+IOKApg0KPiBDaGlsZCBwcm9jZXNzIHBpZD0xMDA4NiB0ZXJtaW5hdGVk
IGFibm9ybWFsbHk6IFNlZ21lbnRhdGlvbiBmYXVsdA0KPiDigKYNCg0KDQpBIGxhenkgZ3Vl
c3M6IHNpbXBsZSBsYWNrIG9mIG1lbW9yeT8NCg0KT24gb25lIGhhbmQ6IEkgZG9uJ3QgaW1h
Z2luZSB0aGlzIG9jY3VycmluZyBmb3IgcGtnIGJvb3RzdHJhcC4gT24gdGhlIA0Kb3RoZXI6
IEkgbmV2ZXIgdG91Y2hlZCBhcm02NC5hYXJjaDY0DQoNCg==
--------------TAbCLXuKgYw2El0ZurKrS93g
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 17/10/2022 15:08, void wrote:

    

    
=E2=80=A6
      arm64.aarch64
      =E2=80=A6

      

      version is main-n258626-865f46b25559 built today 17th Oct 22.
      

    

    In context:
    <https://cgit.freebsd.org/src=
/log/?qt=3Drange&q=3D865f46b25559>
    around twenty hours ago. 

    

      =E2=80=A6

      Child process pid=3D10086 terminated abnormally: Segmentation fault=

      

      =E2=80=A6

    

    


    

    
A lazy guess: simple lack of memory? 

    

    
On one hand: I don't imagine this occurring for pkg bootstrap. On
      the other: I never touched arm64.aarch64

  
  


--------------TAbCLXuKgYw2El0ZurKrS93g--

--------------1MOmQkK6qP020unMOwmA7f7o--

--------------4YwjSCL140Jsh0Ijfxex98Zd
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmNNifgFAwAAAAAACgkQt2dIb0oY1Au+
Xw/+NubKOmpXinKUow4HdYd6FqKt6iE5Fb03Ya33ye2V/Xbuhc/+v5SGISTGq8ITgdVtmVIM+SCR
imWlCVhjY4SpfmOV28LHmSTH1Kywy1boEzYsaSWlk/d5u0mRTra8UnpobG8refno3KefxdIpGjPL
krs4S6+hKtUqZLtBJFSMCVkB8GTn3u/k0E1MlWMwjAa9zH8rTYbjWhZTxv6LQPDf8NvykYu97UiH
nIDrgAORh458+KoLrGghpp33rTc6OxbK7firOaQH8Lv2ND9gEaqsRvdqn8FYt4KjP+/0H+mq6RvT
fC+NanJATmSOvBjfZg9m0x9AfIMvUo+ESr5uhkPaoF097fADsqhLx0m9K10mJuTO4OYsA9FF0w9L
KsEOn4SeSIVIpl13mDo8IPtjF3q/9ofDuOUQs/SvBM/ikxuXuKy7fjy8Wz1McxBJYe+D78+TJ1uq
9YKlmXecsrFsptMZsJ/3wnnE2RSjvyIiZXPPXmoR1xDhG+JZ0Cy38BC9MLGMqA3o6OCmOO5nnKMH
xZ69rcMtCBl951IHOqmtvfG1k7Diexeu7ie53v12SRk24YCVGzj2KbTTs8uq07riw9zCE+TPJYhG
eyGBnoNN4iolELHwB7ivIhZGzToPd7ZbGIX8/kI23OMR12M/1TZ+D7QSLfLRAx/0BNugcsux9S/g
CWw=
=s0oT
-----END PGP SIGNATURE-----

--------------4YwjSCL140Jsh0Ijfxex98Zd--

From nobody Mon Oct 17 19:35:59 2022
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 4MrnKX6pmyz4fGqn
	for ; Mon, 17 Oct 2022 19:36:00 +0000 (UTC)
	(envelope-from 01000183e7721daa-e8bd17be-b93d-4542-925a-d294bb684b30-000000@amazonses.com)
Received: from a48-104.smtp-out.amazonses.com (a48-104.smtp-out.amazonses.com [54.240.48.104])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MrnKX0Z7fz3y37
	for ; Mon, 17 Oct 2022 19:36:00 +0000 (UTC)
	(envelope-from 01000183e7721daa-e8bd17be-b93d-4542-925a-d294bb684b30-000000@amazonses.com)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1666035359;
	h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type:Content-Transfer-Encoding:Feedback-ID;
	bh=wSnJUEc1nEbeUdlXycudLeTT2IKhxotYd0f0e7aIXx0=;
	b=TU9kK9zfiIN0J0VvajfdxRtALZMiOGHXdGjM7o0q5G6s6yb5jaFjOg3D0kj7HIN6
	JE+eiuQRg7F1yqW9fsDReM8uYOii3VkFxF0RxZd1D2/8gE9e5YyymTZ2J8n7o0YwdTN
	yHBdxp5yUseqO4B4a9H7zRf0IvdDnFEJGqLrfhAY=
Message-ID: <01000183e7721daa-e8bd17be-b93d-4542-925a-d294bb684b30-000000@email.amazonses.com>
Date: Mon, 17 Oct 2022 19:35:59 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.0
Content-Language: en-US
To: Current FreeBSD 
From: Thomas Laus 
Subject: Installation using NFS spams console
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES
X-SES-Outgoing: 2022.10.17-54.240.48.104
X-Rspamd-Queue-Id: 4MrnKX0Z7fz3y37
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=TU9kK9zf;
	dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=acm.org (policy=none);
	spf=pass (mx1.freebsd.org: domain of 01000183e7721daa-e8bd17be-b93d-4542-925a-d294bb684b30-000000@amazonses.com designates 54.240.48.104 as permitted sender) smtp.mailfrom=01000183e7721daa-e8bd17be-b93d-4542-925a-d294bb684b30-000000@amazonses.com
X-Spamd-Result: default: False [-0.45 / 15.00];
	FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.998];
	NEURAL_HAM_LONG(-0.86)[-0.855];
	FORGED_SENDER(0.30)[lausts@acm.org,01000183e7721daa-e8bd17be-b93d-4542-925a-d294bb684b30-000000@amazonses.com];
	R_DKIM_ALLOW(-0.20)[amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw];
	R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18];
	MIME_GOOD(-0.10)[text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[acm.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none];
	FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,01000183e7721daa-e8bd17be-b93d-4542-925a-d294bb684b30-000000@amazonses.com];
	RCVD_COUNT_ZERO(0.00)[0];
	ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[54.240.48.104:from];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[amazonses.com:+];
	RCVD_IN_DNSWL_NONE(0.00)[54.240.48.104:from];
	FROM_HAS_DN(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[amazonses.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

I have been building FreeBSD CURRENT every 2 weeks for years.  I build 
on a fest PC and then use NFS exports of /usr/src and /usr/obj to update 
several other PC's.  I received many 'Permission denied' messages as the 
kernel and world installs progressed.

make[4]: warning: 
/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/zlib: 
Permission denied.

This did not happen 2 weeks ago with:

main-258348-ffbc2a58b13a.

I built:

main-n258628-0ca740d9a639

Today and received the above messages.  I have an empty /etc/exports 
file and the problem directories have the zfs properties of sharenfs set 
to yes.  There was nothing in /usr/src/UPDATING today with any NFS 
listed changes.  Everything installed correctly after showing this 
warning for every file.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

From nobody Thu Oct 20 10:03:26 2022
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 4MtNTY0mxSz4gPRq
	for ; Thu, 20 Oct 2022 10:03:29 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MtNTX6yhfz3PbL
	for ; Thu, 20 Oct 2022 10:03:28 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1666260209;
	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=ovVb4i6L8BsLu8b/HQ7iyoE1H1VTEqmx2RktlDgdLFo=;
	b=aXrbxkL07EF+VpFCxP5rKelStF3F9vXEsILahWb8zScPL2aFO+4iru7kBcurb8tmsCVrWq
	wtNwRpoMKondW/EghjaGLufF/8oBl4ZjQ4XmoVYy+cQ1kV2Ec3Rcf+RRxAd7+9zsBLj0XM
	wHaG8jBy1JuJbpufBdHaJNpeN3HISdTshJ7kOEGSxu6i8ad/ucXGuDPsxVnnCnZoGBQlNj
	CNyfVzqjuvlQ8GaPq03BOlvEOSN1pyapzsPBUejeA/IICgJECUA2am2SorUnk2flYc9IPI
	twuYnDzch6eBEmXHIYLFb6uwM+ztyvLneKLvQOQPrmjvdBWhj8F7rCGR5r/sXg==
Received: from [192.168.0.88] (unknown [195.64.148.76])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: avg/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MtNTX4F26zTMc
	for ; Thu, 20 Oct 2022 10:03:28 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Message-ID: <2292945b-c6ba-69c4-e1fd-2726528993cd@FreeBSD.org>
Date: Thu, 20 Oct 2022 13:03:26 +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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.4.0
Content-Language: en-US
To: FreeBSD Current 
From: Andriy Gapon 
Subject: loader.efi module path vs kernel directory
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666260209;
	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=ovVb4i6L8BsLu8b/HQ7iyoE1H1VTEqmx2RktlDgdLFo=;
	b=cZJxFOZg3QRo0fm2SjhN48z9BAIGQrdYvI8AL6bvmMPWquHa6KrJC6CgVCkakxhKr7rKWB
	wB9/Y+w06yXNqTpwcUYUGRPjP9wJnd2wPwD65rsRVMaH22qnwyIfSEwdHDHfceS7yDDyf3
	KA/EXQ620+Q8Ky2RCFBR9qF+kV2GplAIj+A2KXCjWI4ENsBiQuVYTK58A7B2+1Nd38DwiV
	r4RxJiVIf/kx7icsJyeNDw4DV7Emcq4e+psW/PNjk0iSVbX7gs80IrFZaKudV5ieJljklQ
	ceeIMPMeyX1yRt4bxF0Batwd4B07jijWgu9BDqRa6VJ1F8pibIGz7GJXuZOEYA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666260209; a=rsa-sha256; cv=none;
	b=xssdThicIeemW2N7p+6h9UiQte8kEGJnFgEABQ8MTkGd5Qg3ks6i7fWsHXUUKODQ41Bz67
	ZxqvmgcZ5b0ygisxS+SQ+Hba4jC+GDfouH7zbddhaj0L5iq6uuyV0lShfYAAKBOePh/VgU
	YnvLjI9vgfMYxcwbeCWdGyH01tC6pilaRWgrgugreEJ8zcM90stBq6EKjqrp1DM3zIcHCn
	4dT/LNT1h1sIk1DwDkgGZ8EWgTcorPrs0O1vJfKla4DS/+Mivyw5JBrFg0cqo+JfCs69l9
	IAXZuA3szmdkI6DY/+/psVhTjiQUnHXiXVgF6CqKQB77bk8gxTuB5Ob87+bqrw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


I recently needed to recover a system by manually preloading a driver.
To a bit of surprise, simple 'load $modname' did not work, I had to use 'load 
/boot/kernel/$modname.ko'.  I didn't have to do this in a long time, but I 
recall that the short command used to work.  Additionally, required modules also 
failed to get loaded automatically because loader couldn't find them.

I am not sure what the issue is.  Is it that /boot/kernel is not in module path 
(as per /boot/defaults/loader.conf) ? Or is it that /boot/kernel does not get 
added to the *effective* module path?

Thanks!
-- 
Andriy Gapon

From nobody Thu Oct 20 10:08:09 2022
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 4MtNb70hKBz4gPrl
	for ; Thu, 20 Oct 2022 10:08:19 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
Received: from mx.blih.net (mx.blih.net [212.83.155.74])
	(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 "mx.blih.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MtNb60Hf0z3QkG;
	Thu, 20 Oct 2022 10:08:17 +0000 (UTC)
	(envelope-from manu@bidouilliste.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com;
	s=mx; t=1666260490;
	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=z8iO7TlztoojbauGLd++gTeXDBWMw6cdyIHKQ9SzECA=;
	b=Y+GG4SQA4jAPr7YpQ9rm2I3lert5KVMCYEuBpFJEvH8c59jWxCa7YRdRReaSucOHP0J/+x
	oTmsaRnsuJtQV8lK1PkYZOegRLC/Qu9OGIjSkiYOT9Y17wfVavHnwaEf1HGNX4JLN75lT6
	HNAtYShWaHl9cC7j14Jh4EKQ/xrjxl4=
Received: from amy.home.blih.net (lfbn-lyo-1-2174-132.w90-66.abo.wanadoo.fr [90.66.97.132])
	by mx.blih.net (OpenSMTPD) with ESMTPSA id 59a800d1 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Thu, 20 Oct 2022 10:08:10 +0000 (UTC)
Date: Thu, 20 Oct 2022 12:08:09 +0200
From: Emmanuel Vadot 
To: Andriy Gapon 
Cc: FreeBSD Current 
Subject: Re: loader.efi module path vs kernel directory
Message-Id: <20221020120809.f3a21c9a5c33a2ba440ddc01@bidouilliste.com>
In-Reply-To: <2292945b-c6ba-69c4-e1fd-2726528993cd@FreeBSD.org>
References: <2292945b-c6ba-69c4-e1fd-2726528993cd@FreeBSD.org>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MtNb60Hf0z3QkG
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bidouilliste.com header.s=mx header.b=Y+GG4SQA;
	dmarc=pass (policy=none) header.from=bidouilliste.com;
	spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none];
	R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx];
	R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[current@FreeBSD.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR];
	MIME_TRACE(0.00)[0:+];
	DKIM_TRACE(0.00)[bidouilliste.com:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEFALL_USER(0.00)[manu];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 20 Oct 2022 13:03:26 +0300
Andriy Gapon  wrote:

> 
> I recently needed to recover a system by manually preloading a driver.
> To a bit of surprise, simple 'load $modname' did not work, I had to use 'load 
> /boot/kernel/$modname.ko'.  I didn't have to do this in a long time, but I 
> recall that the short command used to work.  Additionally, required modules also 
> failed to get loaded automatically because loader couldn't find them.
> 
> I am not sure what the issue is.  Is it that /boot/kernel is not in module path 
> (as per /boot/defaults/loader.conf) ? Or is it that /boot/kernel does not get 
> added to the *effective* module path?
> 
> Thanks!
> -- 
> Andriy Gapon
> 

 if you escape to prompt directly loader didn't loaded all it's config
so there is no modulepath defined, you need to 'boot-conf' to load the
configuration files.

 Cheers,

-- 
Emmanuel Vadot  

From nobody Thu Oct 20 10:20:12 2022
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 4MtNs75HF0z4gR9M
	for ; Thu, 20 Oct 2022 10:20:27 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from mr85p00im-zteg06022001.me.com (mr85p00im-zteg06022001.me.com [17.58.23.193])
	(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 4MtNs70mFnz3SjC
	for ; Thu, 20 Oct 2022 10:20:27 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1666261225; bh=635PhzGMJHqTfOsMX3Hp5tVSTMcu5hp3d6EvtFnwrnQ=;
	h=Content-Type:From:Mime-Version:Subject:Date:Message-Id:To;
	b=1omzTZ4NzTyyFhtpjwo1yx84WUwBRCj51EeXsc6ulcuAvINNIlNMZGKDHJsnCPhBC
	 D3ubfXceY49AxEDCVQbx4eLC3sdDvk44der+yMYEX308Z4SSXdYHgfDUWZpcO2Na9M
	 1LTS1OwqylfqvlYGBgxQyZGGf7kEr3ag2YoYJsXmRaCxQPNRXUAGyXU4aZzAWBvXN/
	 aDNVgGDx8gJonV6NEHUzzC/PTMOJBt96GITbE0BTFJIuv9SFFAEHawrIMEZZPxmHB7
	 1gNTHgS2dumQ6hSePLvDcsHvikt1Z7iCliPYY0XA9jO4CvZRnloGgrqUTKVcaGgrGF
	 /PLV9dID8Qoog==
Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18])
	by mr85p00im-zteg06022001.me.com (Postfix) with ESMTPSA id 42DC6800815;
	Thu, 20 Oct 2022 10:20:25 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Toomas Soome 
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 (1.0)
Subject: Re: loader.efi module path vs kernel directory
Date: Thu, 20 Oct 2022 13:20:12 +0300
Message-Id: <31145ADA-5932-4858-B3F8-E21CA3F0721B@me.com>
References: <20221020120809.f3a21c9a5c33a2ba440ddc01@bidouilliste.com>
Cc: Andriy Gapon , FreeBSD Current 
In-Reply-To: <20221020120809.f3a21c9a5c33a2ba440ddc01@bidouilliste.com>
To: Emmanuel Vadot 
X-Mailer: iPhone Mail (20A380)
X-Proofpoint-ORIG-GUID: M2knYw3yytT7WOJWEIcXFYia3kWSbRvG
X-Proofpoint-GUID: M2knYw3yytT7WOJWEIcXFYia3kWSbRvG
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.425,18.0.572,17.11.62.513.0000000_definitions?=
 =?UTF-8?Q?=3D2022-01-14=5F01:2022-01-14=5F01,2020-02-14=5F11,2021-12-02?=
 =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999
 malwarescore=0 mlxscore=0 clxscore=1015 adultscore=0 bulkscore=0
 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-2209130000 definitions=main-2210200060
X-Rspamd-Queue-Id: 4MtNs70mFnz3SjC
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=1omzTZ4N;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.23.193 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-3.60 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16];
	R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[17.58.23.193:from];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[tsoome];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RWL_MAILSPIKE_POSSIBLE(0.00)[17.58.23.193:from];
	ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[me.com:dkim];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[me.com:+];
	TO_DN_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[me.com];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[me.com];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Also, instead of manual load, you may want to use enable-module.

Sent from my iPhone

> On 20. Oct 2022, at 13:08, Emmanuel Vadot  wrote:
>=20
> =EF=BB=BFOn Thu, 20 Oct 2022 13:03:26 +0300
> Andriy Gapon  wrote:
>=20
>>=20
>> I recently needed to recover a system by manually preloading a driver.
>> To a bit of surprise, simple 'load $modname' did not work, I had to use '=
load=20
>> /boot/kernel/$modname.ko'.  I didn't have to do this in a long time, but I=
=20
>> recall that the short command used to work.  Additionally, required modul=
es also=20
>> failed to get loaded automatically because loader couldn't find them.
>>=20
>> I am not sure what the issue is.  Is it that /boot/kernel is not in modul=
e path=20
>> (as per /boot/defaults/loader.conf) ? Or is it that /boot/kernel does not=
 get=20
>> added to the *effective* module path?
>>=20
>> Thanks!
>> --=20
>> Andriy Gapon
>>=20
>=20
> if you escape to prompt directly loader didn't loaded all it's config
> so there is no modulepath defined, you need to 'boot-conf' to load the
> configuration files.
>=20
> Cheers,
>=20
> --=20
> Emmanuel Vadot  
>=20

From nobody Thu Oct 20 10:27:34 2022
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 4MtP1Q2gxKz4gRsD
	for ; Thu, 20 Oct 2022 10:27:38 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MtP1Q29Prz3VWL;
	Thu, 20 Oct 2022 10:27:38 +0000 (UTC)
	(envelope-from avg@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1666261658;
	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=ZO6qwOEIVP0eoRh+dH7ud4qw9Q6SfOMRgS0nzBwG228=;
	b=d1hIq+iEGMG1vgQ+YpGciZnYKlXynVqMQwLOAJAXv3o8ZjjtryYeLQU0t86awVaYuhwf9l
	/Fz7lIKbImJE8CcRd05RSWaYW2X4DVhISVA3n4GMqxvp4iBBp+7mkxJYBgAzedvkHGNmhT
	qQoMcCh8Yj9JX9DqWftuu7rxF6ntnzenKDpQgWqTBi6rGy8D4Z+LKRny8Ls6oSsGe5Y4yE
	rmBnN+fSK23wsmhO/+BUAZS1eZnw6ZznRlOY49XDrtPjOR/83kK8/Nhk8CiiIKoMKu4W3z
	2XOgYOZ4I51mndIK4iJjHlyG+MVskIa852Xp1XWF+Y4T9x4nuXhfphvsA6fPQg==
Received: from [192.168.0.88] (unknown [195.64.148.76])
	(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 4MtP1P4mTLzTbN;
	Thu, 20 Oct 2022 10:27:37 +0000 (UTC)
	(envelope-from avg@freebsd.org)
Message-ID: <02e51d32-7585-9a0e-ec41-6f9b198ce625@FreeBSD.org>
Date: Thu, 20 Oct 2022 13:27:34 +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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.4.0
From: Andriy Gapon 
Subject: Re: loader.efi module path vs kernel directory
Content-Language: en-US
To: Toomas Soome , Emmanuel Vadot 
Cc: FreeBSD Current 
References: <20221020120809.f3a21c9a5c33a2ba440ddc01@bidouilliste.com>
 <31145ADA-5932-4858-B3F8-E21CA3F0721B@me.com>
In-Reply-To: <31145ADA-5932-4858-B3F8-E21CA3F0721B@me.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666261658;
	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=ZO6qwOEIVP0eoRh+dH7ud4qw9Q6SfOMRgS0nzBwG228=;
	b=GtPlZcVCB3ccENu9I+oOPUmj61rPwX1X1qjti0lgyu0OlBPUlRfJYkLGUps7kLAj+WvR5z
	BqaegPudD8roUCAYySiLzNfKWDwaiT4TAaqRRpeGmlcitf9EfgR1yMykciobwE04Xbn33z
	LXCvN1+sw74sB5MPIiG/e6yUE45/X4WPn+fmsuEJ9Vb7OYKBiVEw1O7J/+Qr0mTd2/jLUr
	FSWkj/YtXQzcPxOQ/xyP8FIB7jZzTc9VIRylBamhiTWgn041Ft3Pw2gJWmbjexty121xNB
	TCdPiRmqLhfTvb5rxuQvHrxoZWxygLdYguLglnyEGsJe1QEdKV8J8plZqA6MgQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666261658; a=rsa-sha256; cv=none;
	b=OsW1XwwETPZ9/pjYWFuLT4tr1KO0uE4JVqbEImyowqai1EG50+vF7G1aWWLy7/M9xWx8aN
	lQ/gAutH6VCes8i+4ibvazbbvZfamhhVxKIvzscRdWfTKsIiN8yU/5Rq6Jy7OiP+N1pUVm
	P3wreJcGbGADDh3aEQcrHCEDX5ui+V33sWgJZp+jf380BjtU6XZTbUquApL/GMieqm8fLT
	ob3ag/y+421DzkJwZ9VuHQXSA7PQmu35/mvYTbIC0KujmdcIcRcjyOi7oSfyiakAPD8im2
	rbCPsXQdXXBRw675XkNsbtHH27nL3i165uyR7HRtDeyT6AotYMcmRjQ9lYEI1A==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 20/10/2022 13:20, Toomas Soome wrote:
> Also, instead of manual load, you may want to use enable-module.

Emmanuel, Toomas,

thank you very much for the suggestions.

It seems like my installation may be messed up or outdated somehow, see below 
(and sorry about those ^M-s).  I do not seem to have boot-conf or *-module commands.

I checked that the EFI partition has exactly the same loader.efi as in /boot, 
but maybe some other files (configuration?) are outdated.
Also, forgot to mention, this is with stable/13, not main / current.

OK ?^M
Available commands:^M
   copy_staging     copy staging^M
   staging_slop     set staging slop^M
   efi-autoresizeconEFI Auto-resize Console^M
   gop              graphics output protocol^M
   uga              universal graphics adapter^M
   efi-seed-entropy try to get entropy from the EFI RNG^M
   poweroff         power off the system^M
   reboot           reboot the system^M
   quit             exit the loader^M
   memmap           print memory map^M
   configuration    print configuration tables^M
   mode             change or display EFI text modes^M
   lsefi            list EFI handles^M
   chain            chain load file^M
   netserver        change or display netserver URI^M
   loadfont         load console font from file^M
   grab_faults      grab faults^M
   ungrab_faults    ungrab faults^M
   fault            generate fault^M
   boot             boot a file or loaded kernel^M
   autoboot         boot automatically after a delay^M
   help             detailed help^M
   ?                list commands^M
   show             show variable(s)^M
   set              set a variable^M
   unset            unset a variable^M
   echo             echo arguments^M
   read             read input from the terminal^M
   more             show contents of a file^M
   lsdev            list all devices^M
   readtest         Time a file read^M
   include          read commands from a file^M
   ls               list files^M
   load             load a kernel or module^M
   unload           unload all modules^M
   lsmod            list loaded modules^M
   pnpmatch         list matched modules based on pnpinfo^M
   pnpload          load matched modules based on pnpinfo^M
   pnpautoload      auto load modules based on pnpinfo^M
   nvstore          manage non-volatile data^M
   map-vdisk        map file as virtual disk^M
   unmap-vdisk      unmap virtual disk^M
   bcachestat       get disk block cache stats^M
   lszfs            list child datasets of a zfs dataset^M
   reloadbe         refresh the list of ZFS Boot Environments^M
   efi-show         print some or all EFI variables^M
   efi-set          set EFI variables^M
   efi-unset        delete / unset EFI variables^M

> 
> Sent from my iPhone
> 
>> On 20. Oct 2022, at 13:08, Emmanuel Vadot  wrote:
>>
>> On Thu, 20 Oct 2022 13:03:26 +0300
>> Andriy Gapon  wrote:
>>
>>>
>>> I recently needed to recover a system by manually preloading a driver.
>>> To a bit of surprise, simple 'load $modname' did not work, I had to use 'load
>>> /boot/kernel/$modname.ko'.  I didn't have to do this in a long time, but I
>>> recall that the short command used to work.  Additionally, required modules also
>>> failed to get loaded automatically because loader couldn't find them.
>>>
>>> I am not sure what the issue is.  Is it that /boot/kernel is not in module path
>>> (as per /boot/defaults/loader.conf) ? Or is it that /boot/kernel does not get
>>> added to the *effective* module path?
>>>
>>> Thanks!
>>> -- 
>>> Andriy Gapon
>>>
>>
>> if you escape to prompt directly loader didn't loaded all it's config
>> so there is no modulepath defined, you need to 'boot-conf' to load the
>> configuration files.
>>
>> Cheers,
>>
>> -- 
>> Emmanuel Vadot  
>>

-- 
Andriy Gapon


From nobody Thu Oct 20 10:58:13 2022
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 4MtPhq5pDtz4gW67
	for ; Thu, 20 Oct 2022 10:58:19 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from mr85p00im-zteg06021901.me.com (mr85p00im-zteg06021901.me.com [17.58.23.194])
	(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 4MtPhp4hZhz3ZrP
	for ; Thu, 20 Oct 2022 10:58:18 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1666263497; bh=G2ZQ9+Qbvk6E9joW5ZxtWfK/JvJH9wJ1t4yotGqHaV0=;
	h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To;
	b=1wNUItmnju5828LaL+keBh3FH8Kmz7Lo6DIf0JkRCcO/dK4An3K7MUENUOU+Lj47D
	 Yap6xxuONIxo08cRgN8lpgpPPc6X1bWhP4duZAJksS4dqDX/jtoHCMqalupdGHbyck
	 iUFDpDJRw7h1TkQX0itKRp26qtsiATO9iSmH9uCyjTG1HM1cIVOEdnPtM5n/1UYGWF
	 /4z++PQQH+CqDoKCMlKmOPS9wFhGFnUTH5VW7Kb0MjdPqLbJ5aAeDDLBxVKAoJURKf
	 Ajd/aLRvp3cXsB6nV4fKOMrK4hLedMfJ0FO3snG+YqRlP+klLiC2izi9/5ZnmbV7jR
	 9mebQ3pfCvg5w==
Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18])
	by mr85p00im-zteg06021901.me.com (Postfix) with ESMTPSA id 5E6D874076B;
	Thu, 20 Oct 2022 10:58:15 +0000 (UTC)
From: Toomas Soome 
Message-Id: 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_DCE11B8E-D7EC-42CC-B3BE-8B6E6778E7DB"
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: loader.efi module path vs kernel directory
Date: Thu, 20 Oct 2022 13:58:13 +0300
In-Reply-To: <02e51d32-7585-9a0e-ec41-6f9b198ce625@FreeBSD.org>
Cc: Emmanuel Vadot ,
 FreeBSD Current 
To: Andriy Gapon 
References: <20221020120809.f3a21c9a5c33a2ba440ddc01@bidouilliste.com>
 <31145ADA-5932-4858-B3F8-E21CA3F0721B@me.com>
 <02e51d32-7585-9a0e-ec41-6f9b198ce625@FreeBSD.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Proofpoint-ORIG-GUID: iKpSkiZTC5HPXLe0IKdczcQIqM-5LPVl
X-Proofpoint-GUID: iKpSkiZTC5HPXLe0IKdczcQIqM-5LPVl
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.572,17.11.62.513.0000000_definitions?=
 =?UTF-8?Q?=3D2020-02-14=5F11:2020-02-14=5F02,2020-02-14=5F11,2021-12-02?=
 =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0
 phishscore=0 bulkscore=0 malwarescore=0 mlxscore=0 spamscore=0
 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-2209130000 definitions=main-2210200065
X-Rspamd-Queue-Id: 4MtPhp4hZhz3ZrP
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=1wNUItmn;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.23.194 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-3.60 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[17.58.23.194:from];
	FREEFALL_USER(0.00)[tsoome];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[me.com:dkim];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[me.com:+];
	TO_DN_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[me.com];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[me.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_DCE11B8E-D7EC-42CC-B3BE-8B6E6778E7DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


the problem with =E2=80=98?=E2=80=99 command is that it only does list =
commands written in C, it does not list scripted commands. cli_lua(8) =
should list lua specific ones. And at least my stable/13 branch does =
seem to confirm, enable-module, disable-module, toggle-module and =
show-module-options should be present (defined in /boot/lua/cli.lua). I =
am also pretty sure, Kyle did add those when 13 was current, lua version =
was missing those, Forth version had them first:)

rgds,
toomas

> On 20. Oct 2022, at 13:27, Andriy Gapon  wrote:
>=20
> On 20/10/2022 13:20, Toomas Soome wrote:
>> Also, instead of manual load, you may want to use enable-module.
>=20
> Emmanuel, Toomas,
>=20
> thank you very much for the suggestions.
>=20
> It seems like my installation may be messed up or outdated somehow, =
see below (and sorry about those ^M-s).  I do not seem to have boot-conf =
or *-module commands.
>=20
> I checked that the EFI partition has exactly the same loader.efi as in =
/boot, but maybe some other files (configuration?) are outdated.
> Also, forgot to mention, this is with stable/13, not main / current.
>=20
> OK ?^M
> Available commands:^M
>  copy_staging     copy staging^M
>  staging_slop     set staging slop^M
>  efi-autoresizeconEFI Auto-resize Console^M
>  gop              graphics output protocol^M
>  uga              universal graphics adapter^M
>  efi-seed-entropy try to get entropy from the EFI RNG^M
>  poweroff         power off the system^M
>  reboot           reboot the system^M
>  quit             exit the loader^M
>  memmap           print memory map^M
>  configuration    print configuration tables^M
>  mode             change or display EFI text modes^M
>  lsefi            list EFI handles^M
>  chain            chain load file^M
>  netserver        change or display netserver URI^M
>  loadfont         load console font from file^M
>  grab_faults      grab faults^M
>  ungrab_faults    ungrab faults^M
>  fault            generate fault^M
>  boot             boot a file or loaded kernel^M
>  autoboot         boot automatically after a delay^M
>  help             detailed help^M
>  ?                list commands^M
>  show             show variable(s)^M
>  set              set a variable^M
>  unset            unset a variable^M
>  echo             echo arguments^M
>  read             read input from the terminal^M
>  more             show contents of a file^M
>  lsdev            list all devices^M
>  readtest         Time a file read^M
>  include          read commands from a file^M
>  ls               list files^M
>  load             load a kernel or module^M
>  unload           unload all modules^M
>  lsmod            list loaded modules^M
>  pnpmatch         list matched modules based on pnpinfo^M
>  pnpload          load matched modules based on pnpinfo^M
>  pnpautoload      auto load modules based on pnpinfo^M
>  nvstore          manage non-volatile data^M
>  map-vdisk        map file as virtual disk^M
>  unmap-vdisk      unmap virtual disk^M
>  bcachestat       get disk block cache stats^M
>  lszfs            list child datasets of a zfs dataset^M
>  reloadbe         refresh the list of ZFS Boot Environments^M
>  efi-show         print some or all EFI variables^M
>  efi-set          set EFI variables^M
>  efi-unset        delete / unset EFI variables^M
>=20
>> Sent from my iPhone
>>> On 20. Oct 2022, at 13:08, Emmanuel Vadot  =
wrote:
>>>=20
>>> =EF=BB=BFOn Thu, 20 Oct 2022 13:03:26 +0300
>>> Andriy Gapon  wrote:
>>>=20
>>>>=20
>>>> I recently needed to recover a system by manually preloading a =
driver.
>>>> To a bit of surprise, simple 'load $modname' did not work, I had to =
use 'load
>>>> /boot/kernel/$modname.ko'.  I didn't have to do this in a long =
time, but I
>>>> recall that the short command used to work.  Additionally, required =
modules also
>>>> failed to get loaded automatically because loader couldn't find =
them.
>>>>=20
>>>> I am not sure what the issue is.  Is it that /boot/kernel is not in =
module path
>>>> (as per /boot/defaults/loader.conf) ? Or is it that /boot/kernel =
does not get
>>>> added to the *effective* module path?
>>>>=20
>>>> Thanks!
>>>> --=20
>>>> Andriy Gapon
>>>>=20
>>>=20
>>> if you escape to prompt directly loader didn't loaded all it's =
config
>>> so there is no modulepath defined, you need to 'boot-conf' to load =
the
>>> configuration files.
>>>=20
>>> Cheers,
>>>=20
>>> --=20
>>> Emmanuel Vadot  
>>>=20
>=20
> --=20
> Andriy Gapon


--Apple-Mail=_DCE11B8E-D7EC-42CC-B3BE-8B6E6778E7DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



the problem with =E2=80=98?=E2=80=99 =
command is that it only does list commands written in C, it does not =
list scripted commands. cli_lua(8) should list lua specific ones. And at =
least my stable/13 branch does seem to confirm, enable-module, =
disable-module, toggle-module and show-module-options should be present =
(defined in /boot/lua/cli.lua). I am also pretty sure, Kyle did add =
those when 13 was current, lua version was missing those, Forth version =
had them first:)

rgds,
toomas

On 20. =
Oct 2022, at 13:27, Andriy Gapon <avg@FreeBSD.org> wrote:

On 20/10/2022 13:20, Toomas Soome wrote:
Also, =
instead of manual load, you may want to use enable-module.

Emmanuel, Toomas,

thank you very much for the suggestions.

It seems like =
my installation may be messed up or outdated somehow, see below (and =
sorry about those ^M-s).  I do not seem to have boot-conf or =
*-module commands.

I checked that the EFI partition has exactly the same =
loader.efi as in /boot, but maybe some other files (configuration?) are =
outdated.
Also, forgot =
to mention, this is with stable/13, not main / current.

OK =
?^M
Available =
commands:^M
 copy_staging     copy =
staging^M
 staging_slop     set staging =
slop^M
 efi-autoresizeconEFI Auto-resize Console^M
 gop =
            &n=
bsp;graphics output protocol^M
 uga =
            &n=
bsp;universal graphics adapter^M
 efi-seed-entropy try to get entropy from the EFI =
RNG^M
 poweroff =
        power off the =
system^M
 reboot =
          reboot the =
system^M
 quit =
            ex=
it the loader^M
 memmap =
          print memory =
map^M
 configuration    print configuration =
tables^M
 mode =
            ch=
ange or display EFI text modes^M
 lsefi =
           list =
EFI handles^M
 chain =
           chain =
load file^M
 netserver=
        change or display netserver =
URI^M
 loadfont =
        load console font from =
file^M
 grab_faults      grab =
faults^M
 ungrab_faults    ungrab =
faults^M
 fault =
           generate=
 fault^M
 boot =
            bo=
ot a file or loaded kernel^M
 autoboot =
        boot automatically after =
a delay^M
 help =
            de=
tailed help^M
 ? =
            &n=
bsp;  list commands^M
 show =
            sh=
ow variable(s)^M
 set =
            &n=
bsp;set a variable^M
 unset =
           unset =
a variable^M
 echo =
            ec=
ho arguments^M
 read =
            re=
ad input from the terminal^M
 more =
            sh=
ow contents of a file^M
 lsdev =
           list =
all devices^M
 readtest =
        Time a file =
read^M
 include =
         read commands from =
a file^M
 ls =
            &n=
bsp; list files^M
 load =
            lo=
ad a kernel or module^M
 unload =
          unload all =
modules^M
 lsmod =
           list =
loaded modules^M
 pnpmatch =
        list matched modules =
based on pnpinfo^M
 pnpload =
         load matched =
modules based on pnpinfo^M
 pnpautoload      auto load =
modules based on pnpinfo^M
 nvstore =
         manage =
non-volatile data^M
 map-vdisk        map =
file as virtual disk^M
 unmap-vdisk      unmap virtual =
disk^M
 bcachestat       get disk =
block cache stats^M
 lszfs =
           list =
child datasets of a zfs dataset^M
 reloadbe =
        refresh the list of ZFS =
Boot Environments^M
 efi-show =
        print some or all EFI =
variables^M
 efi-set =
         set EFI =
variables^M
 efi-unset=
        delete / unset EFI =
variables^M

Sent =
from my iPhone
On 20. =
Oct 2022, at 13:08, Emmanuel Vadot <manu@bidouilliste.com> wrote:

=EF=BB=BFOn Thu, 20 Oct 2022 13:03:26 +0300
Andriy Gapon <avg@FreeBSD.org> wrote:


I =
recently needed to recover a system by manually preloading a driver.
To a bit of surprise, simple 'load $modname' did not work, I =
had to use 'load
/boot/kernel/$modname.ko'.  I didn't =
have to do this in a long time, but I
recall that the =
short command used to work.  Additionally, required modules also
failed to get loaded automatically because loader couldn't =
find them.

I am not sure what the issue is. =
 Is it that /boot/kernel is not in module path
(as =
per /boot/defaults/loader.conf) ? Or is it that /boot/kernel does not =
get
added to the *effective* module path?

Thanks!
-- 
Andriy =
Gapon


if you =
escape to prompt directly loader didn't loaded all it's config
so there is no modulepath defined, you need to 'boot-conf' to =
load the
configuration files.

Cheers,

-- 
Emmanuel =
Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>


-- 
Andriy =
Gapon

=

--Apple-Mail=_DCE11B8E-D7EC-42CC-B3BE-8B6E6778E7DB--

From nobody Thu Oct 20 10:59:08 2022
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 4MtPjq3tfVz4gW6Q
	for ; Thu, 20 Oct 2022 10:59:11 +0000 (UTC)
	(envelope-from tsoome@me.com)
Received: from mr85p00im-zteg06021901.me.com (mr85p00im-zteg06021901.me.com [17.58.23.194])
	(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 4MtPjp6K2Sz3bsj
	for ; Thu, 20 Oct 2022 10:59:10 +0000 (UTC)
	(envelope-from tsoome@me.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai;
	t=1666263550; bh=C00VytFcS4pcll26/XJLpsXJkgJUOZ3Sy3vGxDgZfxU=;
	h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To;
	b=rF4YQPM3Viml+WInhDQ8fXYsFtr7Hv1hvtxLZeGRm5/QU/H7hmonPnxvts+dtof96
	 jXI57ETMF44/M11jSLdOEwSGt892tcvSfrtH6TzGY3MABN50JOleaXS1v5jHaZ6Lo+
	 6156CzZCriBl/DV5JiuIX2qRqYNji9A79vx9wyELlljL8asQSn/FCSb3MRAy9yTdJZ
	 fdQ3F4WFhh8r7E75NqR7c2hUGKSpVWkMzjAGYMktlXyjtPR7NsEHzJNgB8v7jtDlNW
	 2U31Rxgzik5B5o9+9K0I3RbU6LNyf1CjkgPcsRCiWkv57gD4IYIi5KBUsVK83CekMh
	 WDnnUqacUMeSQ==
Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18])
	by mr85p00im-zteg06021901.me.com (Postfix) with ESMTPSA id BD9F2740778;
	Thu, 20 Oct 2022 10:59:08 +0000 (UTC)
From: Toomas Soome 
Message-Id: <77E8AA2C-0B87-46BD-84A3-5E0099E2B7E1@me.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9BA88ED4-74E5-4344-9421-21EC4109D154"
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: loader.efi module path vs kernel directory
Date: Thu, 20 Oct 2022 13:59:08 +0300
In-Reply-To: 
Cc: Emmanuel Vadot ,
 FreeBSD Current 
To: Andriy Gapon 
References: <20221020120809.f3a21c9a5c33a2ba440ddc01@bidouilliste.com>
 <31145ADA-5932-4858-B3F8-E21CA3F0721B@me.com>
 <02e51d32-7585-9a0e-ec41-6f9b198ce625@FreeBSD.org>
 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Proofpoint-ORIG-GUID: juyvil4BYUU2DBSXMkZ4xc0MiNOYWV3Z
X-Proofpoint-GUID: juyvil4BYUU2DBSXMkZ4xc0MiNOYWV3Z
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.572,17.11.62.513.0000000_definitions?=
 =?UTF-8?Q?=3D2020-02-14=5F11:2020-02-14=5F02,2020-02-14=5F11,2021-12-02?=
 =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0
 phishscore=0 bulkscore=0 malwarescore=0 mlxscore=0 spamscore=0
 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-2209130000 definitions=main-2210200065
X-Rspamd-Queue-Id: 4MtPjp6K2Sz3bsj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=me.com header.s=1a1hai header.b=rF4YQPM3;
	dmarc=pass (policy=quarantine) header.from=me.com;
	spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 17.58.23.194 as permitted sender) smtp.mailfrom=tsoome@me.com
X-Spamd-Result: default: False [-3.60 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine];
	R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai];
	R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16:c];
	RCVD_IN_DNSWL_LOW(-0.10)[17.58.23.194:from];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	FREEFALL_USER(0.00)[tsoome];
	DWL_DNSWL_NONE(0.00)[me.com:dkim];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[me.com:+];
	TO_DN_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[me.com];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[me.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_9BA88ED4-74E5-4344-9421-21EC4109D154
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Whoops, meant cli.lua(8), of course.

> On 20. Oct 2022, at 13:58, Toomas Soome  wrote:
>=20
>=20
> the problem with =E2=80=98?=E2=80=99 command is that it only does list =
commands written in C, it does not list scripted commands. cli_lua(8) =
should list lua specific ones. And at least my stable/13 branch does =
seem to confirm, enable-module, disable-module, toggle-module and =
show-module-options should be present (defined in /boot/lua/cli.lua). I =
am also pretty sure, Kyle did add those when 13 was current, lua version =
was missing those, Forth version had them first:)
>=20
> rgds,
> toomas
>=20
>> On 20. Oct 2022, at 13:27, Andriy Gapon > wrote:
>>=20
>> On 20/10/2022 13:20, Toomas Soome wrote:
>>> Also, instead of manual load, you may want to use enable-module.
>>=20
>> Emmanuel, Toomas,
>>=20
>> thank you very much for the suggestions.
>>=20
>> It seems like my installation may be messed up or outdated somehow, =
see below (and sorry about those ^M-s).  I do not seem to have boot-conf =
or *-module commands.
>>=20
>> I checked that the EFI partition has exactly the same loader.efi as =
in /boot, but maybe some other files (configuration?) are outdated.
>> Also, forgot to mention, this is with stable/13, not main / current.
>>=20
>> OK ?^M
>> Available commands:^M
>>  copy_staging     copy staging^M
>>  staging_slop     set staging slop^M
>>  efi-autoresizeconEFI Auto-resize Console^M
>>  gop              graphics output protocol^M
>>  uga              universal graphics adapter^M
>>  efi-seed-entropy try to get entropy from the EFI RNG^M
>>  poweroff         power off the system^M
>>  reboot           reboot the system^M
>>  quit             exit the loader^M
>>  memmap           print memory map^M
>>  configuration    print configuration tables^M
>>  mode             change or display EFI text modes^M
>>  lsefi            list EFI handles^M
>>  chain            chain load file^M
>>  netserver        change or display netserver URI^M
>>  loadfont         load console font from file^M
>>  grab_faults      grab faults^M
>>  ungrab_faults    ungrab faults^M
>>  fault            generate fault^M
>>  boot             boot a file or loaded kernel^M
>>  autoboot         boot automatically after a delay^M
>>  help             detailed help^M
>>  ?                list commands^M
>>  show             show variable(s)^M
>>  set              set a variable^M
>>  unset            unset a variable^M
>>  echo             echo arguments^M
>>  read             read input from the terminal^M
>>  more             show contents of a file^M
>>  lsdev            list all devices^M
>>  readtest         Time a file read^M
>>  include          read commands from a file^M
>>  ls               list files^M
>>  load             load a kernel or module^M
>>  unload           unload all modules^M
>>  lsmod            list loaded modules^M
>>  pnpmatch         list matched modules based on pnpinfo^M
>>  pnpload          load matched modules based on pnpinfo^M
>>  pnpautoload      auto load modules based on pnpinfo^M
>>  nvstore          manage non-volatile data^M
>>  map-vdisk        map file as virtual disk^M
>>  unmap-vdisk      unmap virtual disk^M
>>  bcachestat       get disk block cache stats^M
>>  lszfs            list child datasets of a zfs dataset^M
>>  reloadbe         refresh the list of ZFS Boot Environments^M
>>  efi-show         print some or all EFI variables^M
>>  efi-set          set EFI variables^M
>>  efi-unset        delete / unset EFI variables^M
>>=20
>>> Sent from my iPhone
>>>> On 20. Oct 2022, at 13:08, Emmanuel Vadot > wrote:
>>>>=20
>>>> =EF=BB=BFOn Thu, 20 Oct 2022 13:03:26 +0300
>>>> Andriy Gapon > wrote:
>>>>=20
>>>>>=20
>>>>> I recently needed to recover a system by manually preloading a =
driver.
>>>>> To a bit of surprise, simple 'load $modname' did not work, I had =
to use 'load
>>>>> /boot/kernel/$modname.ko'.  I didn't have to do this in a long =
time, but I
>>>>> recall that the short command used to work.  Additionally, =
required modules also
>>>>> failed to get loaded automatically because loader couldn't find =
them.
>>>>>=20
>>>>> I am not sure what the issue is.  Is it that /boot/kernel is not =
in module path
>>>>> (as per /boot/defaults/loader.conf) ? Or is it that /boot/kernel =
does not get
>>>>> added to the *effective* module path?
>>>>>=20
>>>>> Thanks!
>>>>> --=20
>>>>> Andriy Gapon
>>>>>=20
>>>>=20
>>>> if you escape to prompt directly loader didn't loaded all it's =
config
>>>> so there is no modulepath defined, you need to 'boot-conf' to load =
the
>>>> configuration files.
>>>>=20
>>>> Cheers,
>>>>=20
>>>> --=20
>>>> Emmanuel Vadot > >
>>>>=20
>>=20
>> --=20
>> Andriy Gapon
>=20


--Apple-Mail=_9BA88ED4-74E5-4344-9421-21EC4109D154
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Whoops, meant cli.lua(8), of course.

On 20. =
Oct 2022, at 13:58, Toomas Soome <tsoome@me.com> wrote:


the problem with =E2=80=98?=E2=80=99 command is that it =
only does list commands written in C, it does not list scripted =
commands. cli_lua(8) should list lua specific ones. And at least my =
stable/13 branch does seem to confirm, enable-module, disable-module, =
toggle-module and show-module-options should be present (defined in =
/boot/lua/cli.lua). I am also pretty sure, Kyle did add those when 13 =
was current, lua version was missing those, Forth version had them =
first:)

rgds,
toomas

On 20. Oct 2022, at 13:27, Andriy Gapon <avg@FreeBSD.org> =
wrote:

On 20/10/2022 13:20, Toomas Soome wrote:
Also, =
instead of manual load, you may want to use enable-module.

Emmanuel, Toomas,

thank you very much for the suggestions.

It seems like =
my installation may be messed up or outdated somehow, see below (and =
sorry about those ^M-s).  I do not seem to have boot-conf or =
*-module commands.

I checked that the EFI partition has exactly the same =
loader.efi as in /boot, but maybe some other files (configuration?) are =
outdated.
Also, forgot =
to mention, this is with stable/13, not main / current.

OK =
?^M
Available =
commands:^M
 copy_staging     copy =
staging^M
 staging_slop     set staging =
slop^M
 efi-autoresizeconEFI Auto-resize Console^M
 gop =
            &n=
bsp;graphics output protocol^M
 uga =
            &n=
bsp;universal graphics adapter^M
 efi-seed-entropy try to get entropy from the EFI =
RNG^M
 poweroff =
        power off the =
system^M
 reboot =
          reboot the =
system^M
 quit =
            ex=
it the loader^M
 memmap =
          print memory =
map^M
 configuration    print configuration =
tables^M
 mode =
            ch=
ange or display EFI text modes^M
 lsefi =
           list =
EFI handles^M
 chain =
           chain =
load file^M
 netserver=
        change or display netserver =
URI^M
 loadfont =
        load console font from =
file^M
 grab_faults      grab =
faults^M
 ungrab_faults    ungrab =
faults^M
 fault =
           generate=
 fault^M
 boot =
            bo=
ot a file or loaded kernel^M
 autoboot =
        boot automatically after =
a delay^M
 help =
            de=
tailed help^M
 ? =
            &n=
bsp;  list commands^M
 show =
            sh=
ow variable(s)^M
 set =
            &n=
bsp;set a variable^M
 unset =
           unset =
a variable^M
 echo =
            ec=
ho arguments^M
 read =
            re=
ad input from the terminal^M
 more =
            sh=
ow contents of a file^M
 lsdev =
           list =
all devices^M
 readtest =
        Time a file =
read^M
 include =
         read commands from =
a file^M
 ls =
            &n=
bsp; list files^M
 load =
            lo=
ad a kernel or module^M
 unload =
          unload all =
modules^M
 lsmod =
           list =
loaded modules^M
 pnpmatch =
        list matched modules =
based on pnpinfo^M
 pnpload =
         load matched =
modules based on pnpinfo^M
 pnpautoload      auto load =
modules based on pnpinfo^M
 nvstore =
         manage =
non-volatile data^M
 map-vdisk        map =
file as virtual disk^M
 unmap-vdisk      unmap virtual =
disk^M
 bcachestat       get disk =
block cache stats^M
 lszfs =
           list =
child datasets of a zfs dataset^M
 reloadbe =
        refresh the list of ZFS =
Boot Environments^M
 efi-show =
        print some or all EFI =
variables^M
 efi-set =
         set EFI =
variables^M
 efi-unset=
        delete / unset EFI =
variables^M

Sent =
from my iPhone
On 20. =
Oct 2022, at 13:08, Emmanuel Vadot <manu@bidouilliste.com> wrote:

=EF=BB=BFOn Thu, 20 Oct 2022 13:03:26 +0300
Andriy Gapon <avg@FreeBSD.org> wrote:


I =
recently needed to recover a system by manually preloading a driver.
To a bit of surprise, simple 'load $modname' did not work, I =
had to use 'load
/boot/kernel/$modname.ko'.  I didn't =
have to do this in a long time, but I
recall that the =
short command used to work.  Additionally, required modules also
failed to get loaded automatically because loader couldn't =
find them.

I am not sure what the issue is. =
 Is it that /boot/kernel is not in module path
(as =
per /boot/defaults/loader.conf) ? Or is it that /boot/kernel does not =
get
added to the *effective* module path?

Thanks!
-- 
Andriy =
Gapon


if you =
escape to prompt directly loader didn't loaded all it's config
so there is no modulepath defined, you need to 'boot-conf' to =
load the
configuration files.

Cheers,

-- 
Emmanuel =
Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>


-- 
Andriy =
Gapon


=

--Apple-Mail=_9BA88ED4-74E5-4344-9421-21EC4109D154--

From nobody Thu Oct 20 12:35:51 2022
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 4MtRsV0ssQz4ghpC
	for ; Thu, 20 Oct 2022 12:35:58 +0000 (UTC)
	(envelope-from olivier.freebsd@free.fr)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.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 4MtRsT0x8dz3nfR;
	Thu, 20 Oct 2022 12:35:57 +0000 (UTC)
	(envelope-from olivier.freebsd@free.fr)
Received: from ravel.localnet (unknown [109.210.37.138])
	(Authenticated sender: olivier.freebsd@free.fr)
	by smtp1-g21.free.fr (Postfix) with ESMTPSA id E9582B00583;
	Thu, 20 Oct 2022 14:35:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr;
	s=smtp-20201208; t=1666269354;
	bh=nUulfe1VAaP58UceX9o8aDBGBr8QaQgBiyuQi54Mjos=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=s/oMvrtqDVDLex74SkLJcREHYWK3/AZd46nsXgQVdhi9F/p0KACBKYl9rZ4xm5EYk
	 grcTVMDMBx6ZSArD9JtXb4qmP99o2ISD16C5910nIOOlgl6Io/HHhsndexShZniV5X
	 BxdobhP+5oT+M3HTiuIHWoAFQsF+BNqDaeQrubi2m7kzYEIsFjQlm7BkSqeW1pum5o
	 VNEFwCXJjWjuBjCyXv5ZYr1Gw7xvCeATldZjLVWgM+R/eBBbHPvxnbnakFguja8F4s
	 1fJ3XM9IJCs10zXrMsrrPCtfcPOPHeDg7YOkhWhr79nJDEsv/t3bLruYFSGwWl3eA/
	 oDldGjlxkVpJg==
From: Olivier Certner 
To: Andriy Gapon , FreeBSD Current 
Cc: Emmanuel Vadot 
Subject: Re: loader.efi module path vs kernel directory
Date: Thu, 20 Oct 2022 14:35:51 +0200
Message-ID: <2694410.TYJnH3iKXO@ravel>
In-Reply-To: <20221020120809.f3a21c9a5c33a2ba440ddc01@bidouilliste.com>
References: <2292945b-c6ba-69c4-e1fd-2726528993cd@FreeBSD.org> <20221020120809.f3a21c9a5c33a2ba440ddc01@bidouilliste.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-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MtRsT0x8dz3nfR
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=free.fr header.s=smtp-20201208 header.b="s/oMvrtq";
	dmarc=pass (policy=none) header.from=free.fr;
	spf=pass (mx1.freebsd.org: domain of olivier.freebsd@free.fr designates 212.27.42.1 as permitted sender) smtp.mailfrom=olivier.freebsd@free.fr
X-Spamd-Result: default: False [-3.05 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.95)[-0.952];
	MID_RHS_NOT_FQDN(0.50)[];
	CTE_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[free.fr,none];
	R_SPF_ALLOW(-0.20)[+ip4:212.27.42.1];
	R_DKIM_ALLOW(-0.20)[free.fr:s=smtp-20201208];
	RWL_MAILSPIKE_GOOD(-0.10)[212.27.42.1:from];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[212.27.42.1:from];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[free.fr:dkim];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[free.fr:+];
	TO_DN_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[free.fr];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[free.fr];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:12322, ipnet:212.27.32.0/19, country:FR];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hi Andriy,

>  if you escape to prompt directly loader didn't loaded all it's config
> so there is no modulepath defined, you need to 'boot-conf' to load the
> configuration files.

You might prefer to use 'read-conf' instead of interrupting 'boot-conf''s countdown.

Regards.

-- 
Olivier Certner



From nobody Fri Oct 21 07:37:39 2022
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 4MtxBt0zVvz4fRPQ
	for ; Fri, 21 Oct 2022 07:37:42 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MtxBs18kqz44PM
	for ; Fri, 21 Oct 2022 07:37:41 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: by mail-vs1-xe2d.google.com with SMTP id x66so401179vsb.3
        for ; Fri, 21 Oct 2022 00:37:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:references:in-reply-to:mime-version
         :from:to:cc:subject:date:message-id:reply-to;
        bh=bw+73h2mPB2HPTlHR1b0MHYgokvQ39I0YffcK1BoOjQ=;
        b=ksnzm37aDlaDwGP20dBk1MPKGfBe/hF6E37NHO97TfgV/ujdh5GzVKFnnSd6k45zyB
         xUUVSkLjgA2QlkADFcl5/YKeRCeSnBvCdneuuhfPiR+W1OPqqmjcijaqyI5nh5VPlOnG
         hAdcL9mGnzbWCFosdfkuP+DhMqhvxBWFcg7aXgZZVltaIHfqoAaz7b9ZSnkO51x+6iGA
         spy9v2KCaMGV6mPlmGSGXVBMnGiY6gnlPjxjF+rjBUIb6M1eIDC7JnJrkS/WzTJqG/oV
         rT87+gg6U5ytKFSeE/qGCR/9yF2hkCeW7R8m2UxS6j7fpqVtyVCPwo126l8OD3Tnpzw1
         o3Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:references:in-reply-to:mime-version
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=bw+73h2mPB2HPTlHR1b0MHYgokvQ39I0YffcK1BoOjQ=;
        b=Z+zC2HzdXR+gOQ3rEK38/rhCGpzjxbUG1YBVPXOqrngiXlCJ8DC9ya7alJQqjVF7mO
         3c6u5pda37S7R6dfrPII6e/w5FuSMTNkPNAG1NNRBW93yZVsjlcI0h4CeOGJ4Cf/A7OD
         WbNtoMW+umSbe6zCDhqmga4uwn3CmSk202Nk1z3UldEhBOFFXTtYK5i4rgiQY62l5Kzs
         9fzrV59bO1awVNU1Dt2jJ+RWgQ/8V7LN5dAkIOrVYUNBrkYkp4/KmwmmkOwXfSkaFr03
         vjd3D5IHXtsCApVLPh6/pUApeLD2hnNUb7phrz+3hwkNMPVXsdPjiYmlvFur+oJRGVrL
         p6kw==
X-Gm-Message-State: ACrzQf2usuQNojubgHHKFN1q4GdEMFSIiLXPyUdm78PVNCeeEj7IqXqq
	Syxhi5lMXpnybYWu2WAtWwts0thGws19RxUESvAcjF/adSIKzH/jl/Y=
X-Google-Smtp-Source: AMsMyM4xK+NSojhS9tm8bgSPWv4X9rh+G/25JjOe9iKEDeveaCMQCIMOFAUdjSLYckwWv/ljEbXMmOXL6UJ/aMC696I=
X-Received: by 2002:a67:fad5:0:b0:3a6:5bc5:ffd8 with SMTP id
 g21-20020a67fad5000000b003a65bc5ffd8mr10872782vsq.23.1666337859933; Fri, 21
 Oct 2022 00:37:39 -0700 (PDT)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Received: by 2002:a59:8cd1:0:b0:319:151e:7726 with HTTP; Fri, 21 Oct 2022
 00:37:39 -0700 (PDT)
In-Reply-To: <2ba3e191-64c1-b854-3eb3-080345b56839@FreeBSD.org>
References: 
 <2ba3e191-64c1-b854-3eb3-080345b56839@FreeBSD.org>
From: grarpamp 
Date: Fri, 21 Oct 2022 03:37:39 -0400
Message-ID: 
Subject: Re: Status of Alder Lake support
To: current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MtxBs18kqz44PM
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=ksnzm37a;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::e2d as permitted sender) smtp.mailfrom=grarpamp@gmail.com
X-Spamd-Result: default: False [-3.99 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.995];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2d:from];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-ThisMailContainsUnwantedMimeParts: N

> What is the current state of support for Alder Lake CPUs

Some opensource support and tools for managing certain
aspects of Alder Lake should be appearing before long...

https://www.tomshardware.com/news/intel-confirms-6gb-alder-lake-bios-source-code-leak-new-details-emerge

From nobody Fri Oct 21 09:25:36 2022
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 4MtzbN40p9z4fx9k;
	Fri, 21 Oct 2022 09:25:36 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MtzbN3LjVz3N6k;
	Fri, 21 Oct 2022 09:25:36 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1666344336;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=SSWHsdNyW4P6abdSBASBod10O2bKf3hcWhbm7nPDq0M=;
	b=aPCJmbRsVajC+G0N67UcUIsB2EqeNEgJUgPhBJjIYyxOGJJqF6Oy0R1R7dBLdaUfptxV8e
	qvYIIyB+pBkspLovMt8cjSWS7IL4ILCaP23EVR2Zf8QCAeQ+mtoOm8ibVzICfN0QGTbRQO
	cSwMpdE3Wj32tZrgEsXZ/xrXSfrjS9jnUBf2p2sLRnXoemwRDGLsqaqXpFeYeyw66LCxvO
	k74uBKkPt+MIqMw++obg2x47XzX5YC81TvxjeFOAe1rmCfprez2FTBniAgLb3/JpPnUW6Z
	ICd/RTYqJJrrNYeeNfgg0T5+4qC2tofZ7nMajmAIvdQabDn3an5Vou4g7wfb2A==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id 5D8571AE16; Fri, 21 Oct 2022 09:25:36 +0000 (UTC)
Date: Fri, 21 Oct 2022 09:25:36 +0000
From: Lorenzo Salvadore 
To: freebsd-hackers@freebsd.org
Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org
Subject: FreeBSD Quarterly Status Report - Third Quarter 2022
Message-ID: 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline; filename="report.txt"
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666344336;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding;
	bh=SSWHsdNyW4P6abdSBASBod10O2bKf3hcWhbm7nPDq0M=;
	b=yBkHN650aLi8+BOX/ZPBuNy9WaV+mycbNYrw48QFpYlJPAeFQfUpV/ALQQ8pcA7AcKuYfd
	rnvoAFiwnrIwsZDCA8nvZJ8F5hdtSHH2CT/KIlRx6oo83t3MmzY3ffTcTUmAserNEMMsrY
	cYzYpmLkfYV4gJQMB8U+/3pxXPlBMjn92wdMfUcVaAQhYfVF8MHN3XSxCmKwsXKaYpztra
	5eJGC6Zdeca0LvKR8iq6nr81wQLSnO1JodB9+/Mggep3MA8zJPathGytMcjhBMv6QT3Uek
	+PSa+ZgXqO8plmx5QEYHaX/YPHDtqOxZEqu5nMDfnjsAvMis6FON4ghvcur/Jg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666344336; a=rsa-sha256; cv=none;
	b=RPCCkCn20k9L1I2SnfCJeIiYXivOBEE0ZKgL10SevrcIDj5buxWDKY2zxhGRykMgrq3BGt
	Nf4jSGRtWqPlHnitlNbQU4Wyg5D80Rtyw3EHgpp55GUg+Zhi9MwoLNBJPZvXwwt7Q5+rQb
	1WgV37gsPUz2QCw5z4oe4qIZe8HBD/wtQPhVmQb7w+9uxTQc7UsK0wgLK9RH/XkTqK0Jzv
	LWIqwomZoW39yT841wnXv1w86qXWMW4p4ng1LxCpMjFiNEQcPeO5CQ2bEIkdNxacoDoEQB
	DGkLOmO55vTl7OuAMtOHclrXh1WXT9BuHNCy74soak7RvTAZ3jWZrS9zansV9w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

FreeBSD Quarterly Status Report Third Quarter 2022

Here is the third quarterly report for year 2022, with 24 reports included,
which is slightly fewer than last quarter.

I notice that in the past we had quarters with many more reports: often more
than 30, sometimes even more than 40. Thus I would like to encourage all of you
to submit reports: reports are useful to share your work, to find help, to have
more eyes reviewing your changes, to have more people testing your software, to
reach a wider audience whenever you need to tell something to all of the
FreeBSD community and in many other cases. Please do not be shy and do not
worry if you are not a native English speaker or if you are not proficient in
AsciiDoc syntax: the quarterly team will be glad to help you in whatever you
need.

On the other hand, if you really do not have anything to report, then maybe you
might like to join one of the interesting projects described below, or you
might be inspired from one of them to do something new, thus having something
to report in the future.

We wish you all a pleasant read.

Lorenzo Salvadore, on behalf of the status report team.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

A rendered version of this report is available here:
https://www.freebsd.org/status/report-2022-07-2022-09/

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Table of Contents

  • FreeBSD Team Reports
      â–¡ FreeBSD Core Team
      â–¡ FreeBSD Foundation
      â–¡ FreeBSD Release Engineering Team
      â–¡ Cluster Administration Team
      â–¡ Continuous Integration
      â–¡ Ports Collection
  • Projects
      â–¡ OpenStack on FreeBSD
      â–¡ FreeBSD as a Tier 1 cloud-init Platform
  • Userland
      â–¡ bhyve debug server enhancements
      â–¡ Rewrite of pjdfstest
      â–¡ Ongoing work on LLDB multiprocess debugging support
      â–¡ DTrace: Instruction-level dynamic tracing
  • Kernel
      â–¡ ENA FreeBSD Driver Update
      â–¡ wtap(4) enhancement
      â–¡ Intel wireless towards 11ac
      â–¡ More wireless updates
      â–¡ Enabling Snapshots on Filesystems Using Journaled Soft Updates
  • Architectures
      â–¡ FreeBSD/Firecracker
  • Documentation
      â–¡ Documentation Engineering Team
  • Ports
      â–¡ Calendar-data: License added
      â–¡ KDE on FreeBSD
      â–¡ GCC: New maintainer, GCC 12.2 and more
      â–¡ sysutils/lsof major upgrade
  • Third Party Projects
      â–¡ Containers and FreeBSD: Pot, Potluck and Potman

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the
Administration Page.

FreeBSD Core Team

Contact: FreeBSD Core Team 

The FreeBSD Core Team is the governing body of FreeBSD.

Completed Items

New Core Team Secretary

All members of the Core Team express publicly their gratitude to Muhammad
Moinur Rahman (bofh) for serving as the Core Team Secretary for the past two
years.

The Core Team approved Sergio Carlavilla (carlavilla) as the new Core Team
secretary.

Procedure to handle GDPR deletion request

The Core Team has reviewed the procedure to handle GDPR deletions requests with
help from Foundation lawysers. The document is currently being written and will
be published after completion.

New Privacy Policy

The Core Team is working closely with the FreeBSD Foundation to update the
Privacy Policy to properly align with current laws and practices found on
similar websites such as ours.

Bruce Evans memorial plaque

The Core Team unanimously votes to allow the memorial plaque for Bruce Evans
mentioning him as co-founder of FreeBSD.

EuroBSDCon core team office hour

On Friday, September 16, the new Core Team presented at EuroBSDcon 2022
Developer Summit. The Core Team introduced themselves and talked a bit about
their plans for this term. There were discussions, Q & A, and suggestions from
the attendees about the details.

Commit bits

Core approved reactivating the source commit bit for Konrad Witaszczyk (def@).
Right now Konrad is working at Cambridge University, where he is responsible
for developing CheriBSD.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

FreeBSD Foundation

Links:
FreeBSD Foundation URL: https://www.FreeBSDFoundation.org
Technology Roadmap URL: https://FreeBSDFoundation.org/blog/technology-roadmap/
Donate URL: https://www.FreeBSDFoundation.org/donate/
Foundation Partnership Program URL: https://www.FreeBSDFoundation.org/
FreeBSD-foundation-partnership-program
FreeBSD Journal URL: https://www.FreeBSDFoundation.org/journal/
Foundation News and Events URL: https://www.FreeBSDFoundation.org/
news-and-events/

Contact: Deb Goodkin 

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to
supporting and promoting the FreeBSD Project and community worldwide. Donations
from individuals and corporations are used to fund and manage software
development projects, conferences, and developer summits. We also provide
travel grants to FreeBSD contributors, purchase and support hardware to improve
and maintain FreeBSD infrastructure, and provide resources to improve security,
quality assurance, and release engineering efforts. We publish marketing
material to promote, educate, and advocate for the FreeBSD Project, facilitate
collaboration between commercial vendors and FreeBSD developers, and finally,
represent the FreeBSD Project in executing contracts, license agreements, and
other legal arrangements that require a recognized legal entity.

Fundraising Efforts

First, I’d like to send a big thank you to everyone who gave a financial
contribution to our efforts. We are 100% funded by your donations, so every
contribution helps us continue to support FreeBSD in many ways, including some
of the work funded and published in this status report.

We support FreeBSD in five main areas. Software development is the largest area
we fund with through staff developers and contractors who implement new
features, support tier 1 platforms, review patches, and fix issues. You can
find out some of the work we did under OS Improvements in this report. FreeBSD
Advocacy is another area that we support to spread the word about FreeBSD at
conferences, in presentations online and in-person, tutorials and how-to
guides. We purchase and support hardware for the FreeBSD infrastructure that
supports the work going on in the Project. Virtual and in-person events are
organized by the Foundation to help connect and engage community members to
share their knowledge and collaborate on projects. Finally, we provide legal
support to the Project when needed and protect the FreeBSD trademarks.

Our goal this year is to raise at a minimum $1,400,000 towards a spending
budget of around $2,000,000. As we enter the last quarter of 2022, our donation
total sits at $167,348, so we still need your help. If you haven’t made a
donation this year, please consider making one at https://freebsdfoundation.org
/donate/. We also have a Partnership Program for larger commercial donors. You
can find out more at https://freebsdfoundation.org/our-donors/
freebsd-foundation-partnership-program/

OS Improvements

During the second quarter of 2022, 300 src, 36 ports, and 13 doc tree commits
were made that identified The FreeBSD Foundation as a sponsor. Some of that
work has dedicated report entries.

  • FreeBSD as a Tier I cloud-init Platform

  • Intel wireless towards 11ac

  • LLDB multiprocess debugging support

  • OpenStack on FreeBSD

  • Snapshots on Filesystems Using Journaled Soft Updates

The other sponsored work is challenging to concisely summarize. It varies from
complex new features to various bug fixes spanning the src tree. Here is a
small sample to give a flavor of last quarter’s work.

  • 240afd8 makefs: Add ZFS support

    This allows one to take a staged directory tree and create a file consisting
    of a ZFS pool with one or more datasets that contain the contents of the
    directory tree.  This is useful for creating virtual machine images without
    using the kernel to create a pool; "zpool create" requires root privileges and
    currently is not permitted in jails.  makefs -t zfs also provides reproducible
    images by using a fixed seed for pseudo-random number generation, used for
    generating GUIDs and hash salts.  makefs -t zfs requires relatively little by
    way of machine resources.

  • 36f1526 Add experimental 16k page support on arm64

    Add initial 16k page support on arm64. It is considered experimental, with no
    guarantee of compatibility with userspace or kernel modules built with the
    current 4k page size. Testing has shown good results in kernel workloads that
    allocate and free large amounts of memory as only a quarter of the number of
    calls into the VM subsystem are needed in the best case.

  • 1424f65 vm_pager: Remove the default pager

    It's unused now.  Keep the OBJ_DEFAULT identifier, but make it an alias of
    OBJT_SWAP for the benefit of out-of-tree code.

  • a889a65 eventtimer: Fix several races in the timer reload code

    In handleevents(), lock the timer state before fetching the time for the next
    event.  A concurrent callout_cc_add() call might be changing the next event
    time, and the race can cause handleevents() to program an out-of-date time,
    causing the callout to run later (by an unbounded period, up to the idle
    hardclock period of 1s) than requested.

Bhyve Issue Support

The Foundation contracted John Baldwin to dedicate time to Bhyve as issues
arise, especially security issues. Here is a summary of his 2022q3 work on that
contract.

  • bb31aee bhyve virtio-scsi: Avoid out of bounds accesses to guest requests.

  • 62806a7 bhyve virtio-scsi: Tidy warning and debug prints.

  • 7afe342 bhyve e1000: Sanitize transmit ring indices.

  • c94f30e bhyve: Validate host PAs used to map passthrough BARs.

  • 16bedf5 pci: Add helper routines to iterate over a device’s BARs.

  • baf753c bhyve: Support other schemes for naming pass-through devices.

  • fa46f37 bhyve e1000: Skip packets with a small header.

  • e7439f6 bhyve xhci: Cache the value of MaxPStreams when initializing an
    endpoint.

RISC-V Improvements

At the end of the quarter, the Foundation contracted Mitchell Horne to add and
improve support for RISC-V hardware. Mitchell will also perform general
maintenance such as fixing bugs, handling reports, providing review for new
code changes, and improving source code legibility and documentation.

Continuous Integration and Quality Assurance

The Foundation provides a full-time staff member and funds projects to improve
continuous integration, automated testing, and overall quality assurance
efforts for the FreeBSD project. You can read about CI activities this quarter
in a dedicated entry.

FreeBSD Advocacy and Education

Much of our effort is dedicated to Project advocacy. This may involve
highlighting interesting FreeBSD work, producing literature and video
tutorials, attending events, or giving presentations. The goal of the
literature we produce is to teach people FreeBSD basics and help make their
path to adoption or contribution easier. Other than attending and presenting at
events, we encourage and help community members run their own FreeBSD events,
give presentations, or staff FreeBSD tables.

The FreeBSD Foundation sponsors many conferences, events, and summits around
the globe. These events can be BSD-related, open source, or technology events
geared towards underrepresented groups. We support the FreeBSD-focused events
to help provide a venue for sharing knowledge, working together on projects,
and facilitating collaboration between developers and commercial users. This
all helps provide a healthy ecosystem. We support the non-FreeBSD events to
promote and raise awareness of FreeBSD, to increase the use of FreeBSD in
different applications, and to recruit more contributors to the Project. We are
continuing to attend events both in person and virtual as well as planning the
November Vendor Summit. In addition to attending and planning virtual events,
we are continually working on new training initiatives and updating our
selection of how-to guides to facilitate getting more folks to try out FreeBSD.

Check out some of the advocacy and education work we did last quarter:

  • Held a FreeBSD Workshop and Staffed a booth at Scale 19x in Los Angeles, CA
    on July 28-30. You can read more about our participation in the SCALE19X
    Conference Report

  • Sponsored and attended COSCUP, July 30-31, Taiwan

  • Attended the EuroBSDCon Developer Summit and sponsored and attended
    EuroBSDcon 2022, September 15-18, Vienna, Austria

  • Sponsored and Presented at the Rocky Mountain Celebration of Women in
    Computing, September 29-30, 2022. Slides from Deb’s presentation can be
    found here.

  • Published the FreeBSD Foundation Summer 2022 Update

  • Continued our participation in Google Summer of Code as both an admin and
    mentors. Interviews with some of the Google Summer of Code Students can be
    found here.

  • Introduced a new FreeBSD Resources page that allows for search by type of
    subject, type of content and difficulty level.

  • New Blog Posts:

      â–¡ Guest Post: FreeBSD in Science

      â–¡ Advocating for FreeBSD in 2022 and Beyond

      â–¡ August Foundation Fundraising Update

      â–¡ Sharing Dual-Licensed Drivers between Linux and FreeBSD

  • New and Updated How-To and Quick Guides:

      â–¡ FreeBSD Quick Guide: Video Playback on FreeBSD

      â–¡ Binary Package Management on FreeBSD

We help educate the world about FreeBSD by publishing the professionally
produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is
now a free publication. Find out more and access the latest issues at https://
www.FreeBSDfoundation.org/journal/.

You can find out more about events we attended and upcoming events at https://
www.FreeBSDfoundation.org/news-and-events/.

Legal/FreeBSD IP

The Foundation owns the FreeBSD trademarks, and it is our responsibility to
protect them. We also provide legal support for the core team to investigate
questions that arise.

Go to https://www.FreeBSDFoundation.org to find more about how we support
FreeBSD and how we can help you!

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

FreeBSD Release Engineering Team

Links:
FreeBSD 12.4-RELEASE schedule URL: https://www.freebsd.org/releases/12.4R/
schedule/
FreeBSD 13.2-RELEASE schedule URL: https://www.freebsd.org/releases/13.2R/
schedule/
FreeBSD 14.0-RELEASE schedule URL: https://www.freebsd.org/releases/14.0R/
schedule/
FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/
ISO-IMAGES/

Contact: FreeBSD Release Engineering Team, 

The FreeBSD Release Engineering Team is responsible for setting and publishing
release schedules for official project releases of FreeBSD, announcing code
freezes and maintaining the respective branches, among other things.

During the third quarter of 2022, the Release Engineering Team continued
providing weekly development snapshot builds for the main, stable/13, and
stable/12 branches.

Additionally, the schedules for the upcoming 12.4, 13.2, and 14.0 release
cycles were published on the Project website.

Sponsor: Rubicon Communications, LLC ("Netgate") Sponsor: The FreeBSD
Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Cluster Administration Team

Links:
Cluster Administration Team members URL: https://www.freebsd.org/administration
/#t-clusteradm

Contact: Cluster Administration Team 

FreeBSD Cluster Administration Team members are responsible for managing the
machines the Project relies on to synchronise its distributed work and
communications. In this quarter, the team has worked on the following:

  • Added additional storage to the CI system. It will help store more
    artifacts.

  • VuXML deployed in all official mirrors. It speeds up the pkg audit
    functionality.

  • A new (and additional) monitoring system is in place.

  • A few old and faulty machines were decommissioned.

  • Moved several services to newer hardware.

  • Regular cluster-wide software upgrades

  • Regular support for FreeBSD.org user accounts

  • Regular disk and parts support (and replacement) for all physical hosts and
    mirrors.

Work in progress:

  • git infra: Add --filter support.

  • Work with the PowerPC team to improve the package builders, universal, and
    reference machines.

  • Site audit at our primary site: inventory of spares and other miscellanea
    occupying space in our cabinets.

  • Discussions with Juniper about a donation of new switches for our primary
    site.

  • Plan for a large scale network upgrade at our primary site.

  • Cluster refresh (more extended project). Most cluster machines are running
    FreeBSD 13-STABLE or 14-CURRENT as of 2022-09-30. Only a handful of
    machines are still on FreeBSD 12-STABLE.

We are looking for an additional full mirror site (five servers) in Europe. See
generic mirrored layout for our needs. Offers of additional single-server
mirrors are always welcome too, especially in Europe.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Continuous Integration

Links:
FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org
FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org
FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins
Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI
3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI
Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg
FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci
dev-ci Mailing List URL: https://lists.freebsd.org/subscription/dev-ci

Contact: Jenkins Admin 
Contact: Li-Wen Hsu 
Contact: freebsd-testing Mailing List
Contact: IRC #freebsd-ci channel on EFNet

The FreeBSD CI team maintains the continuous integration system of the FreeBSD
project. The CI system checks the committed changes can be successfully built,
then performs various tests and analysis over the newly built results. The
artifacts from those builds are archived in the artifact server for further
testing and debugging needs. The CI team members examine the failing builds and
unstable tests and work with the experts in that area to fix the code or adjust
test infrastructure.

During the third quarter of 2022, we continued working with the contributors
and developers in the project to fulfill their testing needs and also keep
collaborating with external projects and companies to improve their products
and FreeBSD.

Important completed tasks:

  • Expand the artifact storage space for adding more types of artifacts and
    longer retention period.

  • Present Testing/CI Status Update in EuroBSDcon 2022 Developer Summit

  • Add main-powerpc-images and main-powerpcspe-images

Work in progress tasks:

  • Designing and implementing pre-commit CI building and testing (to support
    the workflow working group)

  • Designing and implementing use of CI cluster to build release artifacts as
    release engineering does

  • Testing and merging pull requests in the FreeBSD-ci repo

  • Simplifying CI/test environment setting up for contributors and developers

  • Setting up the CI stage environment and putting the experimental jobs on it

  • Organizing the scripts in freebsd-ci repository to prepare for merging to
    src repository

  • Updating documents on wiki

Open or queued tasks:

  • Collecting and sorting CI tasks and ideas

  • Setting up public network access for the VM guest running tests

  • Implementing use of bare-metal hardware to run test suites

  • Adding drm ports building tests against -CURRENT

  • Planning to run ztest tests

  • Adding more external toolchain related jobs

  • Improving maturity of the hardware lab and adding more hardware for testing

  • Helping more software get FreeBSD support in its CI pipeline (Wiki pages:
    3rdPartySoftwareCI, HostedCI)

  • Working with hosted CI providers to have better FreeBSD support

Please see freebsd-testing@ related tickets for more WIP information, and don’t
hesitate to join the effort!

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Ports Collection

Links:
About FreeBSD Ports URL:https://www.FreeBSD.org/ports/
Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#
ports-contributing
FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/
Ports Management Team URL: https://www.freebsd.org/portmgr/
Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/

Contact: René Ladan 
Contact: FreeBSD Ports Management Team 

The Ports Management Team is responsible for overseeing the overall direction
of the Ports Tree, building packages, and personnel matters. Below is what
happened in the last quarter.

Currently there are just over 30,500 ports in the Ports Tree. There are
currently just under 2,800 open ports PRs of which 750 are unassigned. The last
quarter saw 9,137 commits by 151 committers on the main branch and 589 commits
by 61 committers on the 2022Q3 branch. Compared to two quarters ago, this means
a slight increase in the number of ports, but also a slight increase in the
number of (unassigned) ports PRs and a slight decrease in the number of commits
made.

In the last quarter, we welcomed Felix Palmen (zirias@) as a new ports
committer, welcomed back Akinori MUSHA (knu@), and said goodbye to Olli Hauer
(ohauer@). We also welcomed Luca Pizzamiglio (pizzamig@) as an official member
of portmgr.

Some large changes in the Ports Tree were made during the last quarter:

  • "Created by" lines have been removed from the top of each Makefile, as a
    lot of those were outdated.

  • WWW: has been moved from each pkg-descr into each Makefile as a variable;
    the below write-up is from Stefan Eßer (se@) who did the work:

The description of a port’s functionality should end with the URL of a web page
that provides further information, such as best practices for usage or
configuration. This information can be displayed with pkg query -e for
installed packages or pkg rquery -e for available packages. The URL used to be
appended to the end of the ports' pkg-descr files, with the prefix "WWW: ", so
that tools could extract the URL from the description. Over time, many of these
URLs have become stale, since port updates generally change only the Makefile,
not the pkg-descr file. By moving the definition of these URLs into the
Makefiles, maintainers are more likely to update the URL along with other port
changes, and tools have easier access to them. The URLs are now assigned to the
WWW macro in the Makefile and can be queried with make -V WWW in the port
directory. Tools that process the description contained in the package files
still work because the "WWW: " lines at the end are generated from the WWW
values in the Makefiles.

During EuroBSDCon, portmgr@ had a discussion about improving the situation for
kernel module packages. Various possibilities have been discussed.

The following happened under the hood:

  • one new USES, "vala", was added.

  • The default version of Go got bumped to 1.19

  • CMake is now a meta-port

  • Initial support for Qt 6 was added, at version 6.3.2

  • Vim no longer installs a system-wide vimrc

  • A number of major ports got updated:

      â–¡ pkg 1.18.4

      â–¡ Chromium 106.0.5249.91

      â–¡ Firefox 105.0.1

          ☆ Firefox ESR 102.3.0

      â–¡ KDE Applications 22.8.1

      â–¡ KDE Frameworks 5.98

      â–¡ Rust 1.63.0

      â–¡ SDL 2.24.0

      â–¡ Xorg server 21.1.4 (overhaul)

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Projects

Projects that span multiple categories, from the kernel and userspace to the
Ports Collection or external projects.

OpenStack on FreeBSD

Links:
OpenStack URL: https://www.openstack.org/
OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd

Contact: Chih-Hsin Chang 
Contact: Li-Wen Hsu 

OpenStack is an open-source cloud operating system for different types of
resources like virtual and bare-metal machines. Users can spawn FreeBSD
instances on the open cloud platform, but it is not currently possible to run
OpenStack control plane on FreeBSD hosts. The goal of this project is to port
key OpenStack components so that FreeBSD can function as an OpenStack host.

Academic and industrial research groups have been evaluating CHERI-enabled
Morello boards since mid-2022. A resource orchestration platform like OpenStack
can improve the speed and cost of provisioning, managing, and recycling those
boards.

Starting in January 2022, Chih-Hsin Chang has been working to port several
OpenStack components to run on FreeBSD, including:

  • Keystone (identity service)

  • Glance (image service)

  • Placement (resource tracking and inventory service)

  • Neutron (networking service)

  • Nova (compute service)

Some of the items are still under heavy development. For instance, due to the
design of Neutron, the DHCP servers are placed inside Linux network namespaces.
It is necessary to find an alternative, e.g. vnet, on FreeBSD and adapt it.
Most of the time the porting strategy is to make as small of an impact as
possible by working around obstacles. But something like oslo.privsep deserves
a true porting. oslo.privsep is rooted in Linux capabilities to do the
privilege separation work. Right now we just bypassed any Linux
capabilities-related operation inside oslo.privsep. So there is plenty of
hackish spots in the source code and configurations currently. All of these
along with the building and installation steps will be collected in the project
repositories.

In Q4 Chih-Hsin plans to focus on porting Neutron and Nova in order to complete
the VM lifecycle operations. The highlights include:

  • DHCP integration

  • FreeBSD bridge driver/agent

  • Bhyve + Libvirt integration

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

FreeBSD as a Tier 1 cloud-init Platform

Links:
cloud-init Website URL: https://cloud-init.io/
cloud-init Documentation URL: https://cloudinit.readthedocs.io/en/latest/
cloud-init ongoing refactorization URL: link:https://github.com/canonical/
cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst

Contact: Mina Galić 

cloud-init is the standard way of provisioning servers in the cloud.
Unfortunately, cloud-init support for operating systems other than Linux is
rather poor, and the lack of cloud-init support on FreeBSD is a hindrance to
cloud providers who want to offer FreeBSD as a Tier 1 platform. To remedy the
situation, this project aims to bring FreeBSD cloud-init support on par with
Linux support. The broader plan is to lift support across all BSDs.

The project deliverables include completing an extraction of certain networking
classes, implementing ifconfig(8) and login.conf(5) parsers, implementing IPv6
configuration, creating devd.conf(5) rules for Azure, and FreeBSD Handbook
documentation about productionizing FreeBSD.

On the way there, any BSD-related bugs found in modules and documentation will
also be fixed.

People interested in helping with the project can help with testing new
features and fixes through net/cloud-init-devel, which will be updated on a
weekly basis. Further, people with access to, and experience with, OpenBSD and
NetBSD are also highly welcome to help.

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Userland

Changes affecting the base system and programs in it.

bhyve debug server enhancements

Links:
link: Wiki project page
link: Differential
Contact: Bojan Novković 

The goal of this project was to enhance the functionality of bhyve’s debug
server. Several existing features related to single-stepping are tied to
Intel-specific VM mechanisms, which severely impairs bhyve’s debugging
functionality on other x86 platforms. The first goal dealt with extending
single-stepping support to AMD hosts. The second goal was to add support for
hardware watchpoints using the guest OS’s hardware debugging registers.

The project was carried out under Google’s Summer of Code program and was
finished around the end of July. The project’s wiki also contains detailed
documentation regarding several implemented mechanisms.

The changes can be summarized as follows:

  • Support for placing software breakpoints inside virtual machines on AMD
    platforms,

  • Support for single-stepping virtual machines on AMD platforms,

  • Support for placing hardware watchpoints inside virtual machines on Intel
    and AMD platforms.

Any feedback, comments and discussions are welcome and would be greatly
appreciated.

Sponsor: Google Summer of Code

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Rewrite of pjdfstest

Links:
Github URL: https://github.com/musikid/pjdfstest
Blog URL: https://musikid.github.io/blog/rewrite-pjdfstest/
Contact: Alan Somers 

Back in 2007, Pawel Jakub Dawidek  wrote pjdfstest, a POSIX
file system conformance test tool. He originally wrote it to validate the port
of ZFS to FreeBSD, but it has subsequently been used for other file systems and
other operating systems.

This year, Sayafdine Said  rewrote it under Google’s
sponsorship. The new version has several improvements:

  • More configurable, for better use with other file systems.

  • Much faster, largely thanks to said configurability.

  • Better test case isolation, making failure easy to debug.

  • No longer requires root privileges for all test cases.

  • Test cases can be run in a debugger.

  • More maintainable, less duplication.

There are still a couple of lingering PRs to complete, but we expect to wrap
those up and add pjdfstest to the ports collection soon. From there, it will be
used both by /usr/tests for ZFS and UFS, and by external developers for other
file systems.

Sponsor: Google Summer of Code

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Ongoing work on LLDB multiprocess debugging support

Links:
Moritz Systems Project Description URL: https://www.moritz.systems/blog/
multiprocess-support-for-lldb/
Progress Report 1 URL: https://www.moritz.systems/blog/
implementing-non-stop-protocol-compatibility-in-lldb/
Progress Report 2 URL: https://www.moritz.systems/blog/
full-multiprocess-support-in-lldb-server/

Contact: Kamil Rytarowski 
Contact: Michał Górny 

According to the upstream description, "LLDB is a next generation,
high-performance debugger. It is built as a set of reusable components which
highly leverage existing libraries in the larger LLVM Project, such as the
Clang expression parser and LLVM disassembler."

FreeBSD includes LLDB in the base system. The previous sponsored projects
improved LLDB, to make it a credible debugger for the base system, although it
still has a few limitations compared to the contemporary versions of GNU GDB.
This project started in April 2022. It aims to implement full support for
debugging multiple processes simultaneously.

At the start of the project, LLDB featured very limited support for
multiprocess debugging. Currently, the server is already able to monitor
multiple processes using the multiprocess extension to the GDB Remote Serial
Protocol. The work on implementing the client-side counterpart for this
protocol is ongoing.

Once the project is finished, LLDB will be able to trace an arbitrary number of
forked processes simultaneously (equivalent to GDB’s detach-on-fork off).

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

DTrace: Instruction-level dynamic tracing

Links:
Wiki article URL: https://wiki.freebsd.org/SummerOfCode2022Projects/
InstructionLevelDynamicTracing
Final code review URL: https://reviews.freebsd.org/D36851

Contact: Christos Margiolis 
Contact: Mark Johnston 

kinst is a new DTrace provider that allows for arbitrary kernel instruction
tracing.

The provider is currently implemented only for amd64, but we plan to port it to
other architectures in the future as well.

kinst probes are created on demand by libdtrace, and a probe can be created for
nearly every instruction in the kernel. Probes take the form of:

kinst:::

where "module" is the kernel module containing the named function, "function"
is the kernel function to be traced, and "offset" is the offset to a specific
instruction. Omitting "offset" causes all instructions in the function to be
traced. Omitting "module" causes DTrace to search all kernel modules for the
function.

For example, to trace the second instruction in amd64_syscall(), first
determine the offset of the second instruction:

# kgdb
(kgdb) disas /r amd64_syscall
Dump of assembler code for function amd64_syscall:
   0xffffffff809256c0 <+0>:     55      push   %rbp
   0xffffffff809256c1 <+1>:     48 89 e5        mov    %rsp,%rbp
   0xffffffff809256c4 <+4>:     41 57   push   %r15

The offset is 1. Then, to trace it:

# dtrace -n 'kinst::amd64_syscall:1'

A new "regs" keyword was also added to the D language, providing read-only
access to CPU registers at the point where the probe fired. For example, to
trace the contents of the frame pointer (register %rbp on amd64) when the
kinst::amd64_syscall:1 probe fires:

# dtrace -n 'kinst::amd64_syscall:1 {printf("0x%x", regs[R_RBP]);}'

kinst works similarly to the FBT (function boundary tracing) provider in that
it places a breakpoint on the target instruction and hooks into the kernel’s
breakpoint handler. It is more powerful than FBT since it can be used to create
probes at arbitrary points within a function, rather than at function
boundaries. Because kinst has to be able to trace arbitrary instructions, it
does not emulate most of them in software but rather causes the traced thread
to execute a copy of the instruction before returning to the original code.

Planned future work includes porting kinst to additional platforms, especially
arm64 and riscv, and developing tooling that can use kinst to trace calls to
inline functions using the kernel’s debugging symbols.

Sponsor: Google, Inc. (GSOC 2022)

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Kernel

Updates to kernel subsystems/features, driver support, filesystems, and more.

ENA FreeBSD Driver Update

Links:
ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/
ena/README.rst

Contact: Michal Krawczyk 
Contact: David Arinzon 
Contact: Marcin Wojtas 

ENA (Elastic Network Adapter) is the smart NIC available in the virtualized
environment of Amazon Web Services (AWS). The ENA driver supports multiple
transmit and receive queues and can handle up to 100 Gb/s of network traffic,
depending on the instance type on which it is used.

Completed since the last update:

  • Upstream of the ENA driver v2.6.0 and v2.6.1, included:

      â–¡ Fix for the performance degradation after reset issue on 6-gen
        instances,

      â–¡ Fix of the false netmap assertions with KASSERT enabled,

      â–¡ Code cleanup and style fixes,

      â–¡ Logging improvements,

      â–¡ Fix to the retrieval of the ENI metrics.

Sponsor: Amazon.com Inc

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

wtap(4) enhancement

Links:
Add sta, hostap and adhoc mode to wtap wlan simulator

Contact: En-Wei Wu 
Contact: Li-Wen Hsu 
Contact: Bjoern A. Zeeb 

wtap(4) is a net80211(4) Wi-Fi simulator introduced by Monthadar Al Jaberi <
monthadar@gmail.com> and Adrian Chadd  in 2012. It
originally supported 802.11s mesh mode and was used for verification. During
the 2022 Google Summer of Code, En-Wei had been working on bringing sta,
hostap, adhoc and monitor modes to it. The work also covers adding basic tests
for net80211(4) with wtap(4), written in atf(7).

For more details, please check the project wiki page.

Sponsor: Google Summer of Code Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Intel wireless towards 11ac

Links:
Intel iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/
Iwlwifi

Contact: Bjoern A. Zeeb 

The ongoing project aims to support the latest Intel wireless chipsets on
FreeBSD using LinuxKPI compat code backed by native net80211 and kernel code.
In addition work is on the way to support 11n and 11ac standards in the
LinuxKPI 802.11 compat code and fill gaps for mostly 11ac in the native
net80211 wireless stack.

For the Intel iwlwifi wireless driver there were no major updates in the last
months. We updated the firmware to the latest publicly available version and
fixed some of the most visible bugs. Work is also on the way to support the D3
power saving code.

LinuxKPI compat code also got some improvements and fixes which at times were
only observable on certain generations of iwlwifi chipsets.

Changes in net80211 and LinuxKPI compat code for 11n and 11ac have little
public visibility so far in order to not break basic support. Updates to
constants based on newer 802.11 standards and other changes without
user-visible effect were merged, and functional changes will follow in the
coming months, initially hidden behind compile-time or runtime options.

Improvements and updates were largely merged back to stable/13 for the benefit
of the users tracking this branch and to help with more testing.

For the latest state of the development, please follow the freebsd-wireless
mailing list and check the wiki pages.

Sponsor: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

More wireless updates

Links:
Bjoern’s Wireless Work In Progress landing page URL: https://people.freebsd.org
/~bz/wireless/
Realtek rtw88 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw88
Realtek rtw89 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw89
MediaTek mt76 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Mt76
QCA ath11k status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Ath11k

Contact: Bjoern A. Zeeb 

Currently development is mostly driven by Intel’s iwlwifi driver again (see
other report). As the saying goes ''each one helps the other'' so has work on
Realtek’s rtw89 driver helped find a bug in LinuxKPI bothering iwlwifi users.
For this status report the topic is mostly more drivers, which do need more
LinuxKPI support.

Various work in progress:

  • Realtek’s rtw88 PCI is in-tree as-is and after a fruitful discussion with
    Hans Petter Selasky at EuroBSDCon work on LinuxKPI USB support for the
    rtw88 USB WiFi dongles will continue.

  • Realtek’s rtw89 driver was committed to main but is not connected to the
    build yet. Scanning already works but packets are not yet passing. Having
    the driver in-tree already eased testing for users having that chipset in
    order to identify more unimplemented LinuxKPI bits (some of which will help
    the other drivers as well) and reduced work for me.

  • The next drivers to probably hit the tree will be based on MediaTek’s mt76
    driver (for 7921 and 7915) which I have compiling and started testing.

  • Based on requests I am also working on ath11k to support STA mode given
    some vendors seem to ship Laptops with those chips.

While some of this clearly benefits from work sponsored by The FreeBSD
Foundation for iwlwifi and newer standard support, a lot of this is just
free-time work. If you are interested in any of these drivers I would greatly
appreciate if some more hands would help with one or the other. This could be
regularly testing updates to main, writing documentation and updating wiki
pages, tracking PRs, trying out patches, helping with work on individual
LinuxKPI bits with or without 802.11 work, or simply debugging problems with
individual drivers and/or chipsets. If you are interested in helping with any
one of the above, please drop me an email.

For the latest state of the development, please follow the freebsd-wireless
mailing list and check the wiki pages (as soon as they exist).

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Enabling Snapshots on Filesystems Using Journaled Soft Updates

Links:
Milestone 1 Core Changes URL: https://reviews.freebsd.org/D36491

Contact: Kirk McKusick 

This project will make UFS/FFS filesystem snapshots available when running with
journaled soft updates.

The UFS/FFS filesystem has the ability to take snapshots. Because the taking of
snapshots was added after soft updates were written they were fully integrated
with soft updates. When journaled soft updates were added in 2010, they were
never integrated with snapshots. So snapshots cannot be used on filesystems
running with journaled soft updates.

Snapshots became less important with the support for ZFS on FreeBSD since ZFS
can take snapshots quickly and easily. However there remain two instances where
UFS snapshots are still important. The first is that they allow reliable dumps
of live filesystems which avoids possibly hours of down time. The second is
that they allow the running of background fsck. Similar to the need for scrub
in ZFS, fsck needs to be run periodically to find undetected disk failures.
Snapshots allow fsck to be run on live filesystems rather than needing to
schedule down time to run it.

This project has two milestones:

 1. enable snapshots when running with journaled soft updates and ensure that
    they can be used for doing background dumps on a live filesystem. This
    milestone should be completed by the end of 2022.

 2. extend fsck_ffs to be able to do a background check using a snapshot on a
    filesystem running with journaled soft updates. This milestone is expected
    by Q3 of 2023.

Sponsored by: The FreeBSD Foundation

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Architectures

Updating platform-specific features and bringing in support for the new
hardware platform.

FreeBSD/Firecracker

Links:
Firecracker VM

Contact: Colin Percival 

Firecracker is an open source "microVM" developed by Amazon Web Services; it is
designed for the needs of "serverless" compute environments and has a
particular focus on security and minimalism.

Starting in June 2022, Colin Percival has been working to port FreeBSD to run
in the Firecracker environment, with significant assistance from other FreeBSD
developers. As of this quarterly report, a set of patches are pending review
which collectively add the needed support to make FreeBSD functional in a
patched version of Firecracker.

In Q4 Colin intends to finish committing the relevant patches to FreeBSD,
release a kernel and disk image so other FreeBSD users can experiment with
Firecracker, and update and merge Firecracker patches which add PVH boot
support (used by FreeBSD).

This work has already produced "spinoff" benefits in revealing ways to speed up
the FreeBSD boot process; due to its low overhead and minimal environment,
Firecracker is an excellent context to work on this.

This work is supported by Colin’s FreeBSD/EC2 Patreon.

Sponsor: https://www.patreon.com/cperciva

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Documentation

Noteworthy changes in the documentation tree, manual pages, or new external
books/documents.

Documentation Engineering Team

Link: FreeBSD Documentation Project
Link: FreeBSD Documentation Project Primer for New Contributors
Link: Documentation Engineering Team

Contact: FreeBSD Doceng Team 

The doceng@ team is a body to handle some of the meta-project issues associated
with the FreeBSD Documentation Project; for more information, see FreeBSD
Doceng Team Charter.

During the last quarter:

  • 0mp@ stepped down as Doceng’s Secretary, fernape@ joined as the new
    Secretary. Doceng would like to thank 0mp@ for his service.

  • eadler@'s doc bit was taken in for safekeeping per his request.

  • A git commit message template was added for the doc repository.

Items pending and in the discussion:

  • Remove outdated translations from the Website and Documentation portal.

FreeBSD’s Documentation Project Primer

The FDP was expanded with information on trademark handling.

Porter’s Handbook:

  • The documentation on porting Haskell programs was updated.

  • The move of WWW from pkg-descr to Makefile was documented.

  • Qt 6-related documentation has been added following the import of the
    library in the ports framework.

FreeBSD Translations on Weblate

Link: Translate FreeBSD on Weblate
Link: FreeBSD Weblate Instance

Q3 2022 Status

  • 12 languages

  • 148 registered users

      â–¡ Gasol Wu joined the Chinese translation team.

      â–¡ Alvaro Felipe Calle joined the Spanish translation team.

Languages

  • Chinese (Simplified) (zh-cn) (progress: 8%)

  • Chinese (Traditional) (zh-tw) (progress: 4%)

  • Dutch (nl) (progress: 1%)

  • French (fr) (progress: 1%)

  • German (de) (progress: 1%)

  • Indonesian (id) (progress: 1%)

  • Italian (it) (progress: 4%)

  • Norwegian (nb-no) (progress: 1%)

  • Persian (fa-ir) (progress: 3%)

  • Portuguese (pt-br) (progress: 16%)

  • Spanish (es) (progress: 15%)

  • Turkish (tr) (progress: 2%)

We want to thank everyone who contributed, translating or reviewing documents.

Please, promote this effort in your local user group, we always need more
volunteers.

FreeBSD Manual Pages Portal

Contact: Sergio Carlavilla 

The Manual Pages Portal has been redesigned to use mandoc(1) for rendering. A
portal preview is available. Feedback has been collected and addressed where
possible. There are some remaining non-blocking issues. Doceng@ would like to
move forward with the migration to this new portal.

Thanks to all of those who reviewed it and provided feedback.

FreeBSD Website Revamp - WebApps working group

Contact: Sergio Carlavilla 

Working group in charge of creating the new FreeBSD Documentation Portal and
redesigning the FreeBSD main website and its components. FreeBSD developers can
follow and join the working group on the FreeBSD Slack channel #wg-www21. The
work will be divided into four phases:

 1. Redesign of the Documentation Portal

    Create a new design, responsive and with global search. (Complete)

 2. Redesign of the Manual Pages on web

    Scripts to generate the HTML pages using mandoc. (Complete)

 3. Redesign of the Ports page on web

    Ports scripts to create an applications portal. (Work in progress)

 4. Redesign of the FreeBSD main website

    New design, responsive and dark theme. (Not started)

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Ports

Changes affecting the Ports Collection, whether sweeping changes that touch
most of the tree, or individual ports themselves.

Calendar-data: License added

Links
GitHub calendar-data repository URL: https://github.com/freebsd/calendar-data

Contact: Stefan Eßer 
Contact: Lorenzo Salvadore 
Contact: Warner Losh 

The port deskutils/calendar-data contains calendar files for the BSD calendar
program and is maintained by se@. The data for this port lives in a GitHub
repository, which at the moment is maintained mainly by salvadore@.

About two years ago, the calendar files in the base repository were removed
from there and a new repository was created on GitHub; see also this
Phabricator review about the creation of the associated port. This improvement
allows calendar files to be updated independently from the base system.

Unfortunately, when the repository was created, it was forgotten to add a
license to it. The issue has been solved this quarter with this pull request
submitted by salvadore@ and merged by imp@. Since the data originally came from
the src repository, the same licence applies. If in the past you have
contributed to the calendar files with different licensing assumptions, please
inform us so that we can license your contributions accordingly or remove them.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

KDE on FreeBSD

Links:
KDE FreeBSD URL: https://freebsd.kde.org/
KDE Community FreeBSD URL: https://community.kde.org/FreeBSD

Contact: Adriaan de Groot 

The KDE on FreeBSD project packages the software from the KDE Community, along
with dependencies and related software, for the FreeBSD ports tree. The
software includes a full desktop environment called KDE Plasma (for both X11
and Wayland) and hundreds of applications that can be used on any FreeBSD
machine.

The KDE team (kde@) is part of desktop@ and x11@, building the software stack
to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop
machine. The notes below describe mostly ports for KDE, but also include items
that are important for the entire desktop stack.

Qt6 Landed

The big news in the KDE ports is not directly KDE-related. Qt6 has landed,
which prepares us for the next generation of Qt-based applications.

It is now possible to have USES=qt:6 to select the new Qt version. Some ports
have been flavorized to make use of the new version.

KDE itself is not affected: the upstream work on KDE Frameworks for Qt6 is not
yet completed. Most of the KDE Frameworks will compile with Qt6, but that is
not important for FreeBSD ports yet. With devel/qt6 you get Qt 6.4.0, released
at the end of the quarter.

KDE Stack

KDE Gear releases happen every quarter, KDE Plasma updates once a month, and
KDE Frameworks have a new release every month as well. These (large) updates
land shortly after their upstream release and are not listed separately.

  • KDE Frameworks 5 is now at version 5.98 (latest monthly release from
    September 2022).

  • KDE Gear is now version 22.08.1 (update for September 2022).

  • KDE Plasma is now version 5.24.6 (update for July 2022).

Note that KDE Plasma 5.25 has been released upstream, but is waiting on fixes
before it can land in the ports tree (for example, this KActivityManager bug in
KDE’s bug-tracker).

Related Ports

  • accessibility/qt5-speech now supports multiple backends, as well as
    no-backends, for speech synthesis.

  • devel/cmake was reorganized, so that devel/cmake is now a metaport that
    installs devel/cmake-core and the rest of the CMake suite. (Thanks to
    diizzy@) The CMake ports were also updated to version 3.24, with attendant
    changes in ports all over the tree.

  • net/qt5-network has improved compatibility with libressl.

  • x11/plasma-wayland-protocols was updated in advance of KDE Plasma Desktop
    updates in the next quarter.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

GCC: New maintainer, GCC 12.2 and more

Links:
GCC Project URL: https://gcc.gnu.org
GCC 11 release series URL: https://gcc.gnu.org/gcc-11/
GCC 12 release series URL: https://gcc.gnu.org/gcc-12/

Contact: 
Contact: Lorenzo Salvadore 

  • salvadore@ adopted all existing ports corresponding to supported versions
    of gcc, namely: lang/gcc10, lang/gcc11, lang/gcc11-devel, lang/gcc12, lang/
    gcc12-devel and lang/gcc13-devel. At the moment -devel ports are updated
    weekly, unless a build failure makes it impossible. Of course, in the
    latter case, the build failure is fixed and/or reported upstream as soon as
    possible.

  • GCC 12.2 has been released. Traditionally, FreeBSD waits for the release of
    the second minor version of GCC to use it as default GCC version, so that
    most of the software needing to be compiled with GCC has already been
    ported to the latest major version. Thus, work has started to update the
    default GCC version to version 12. Thank you very much to antoine@ who has
    already run the first exp-run and to all the contributors, maintainers and
    committers involved in the process. https://bugs.freebsd.org/bugzilla/
    show_bug.cgi?id=2659548

  • Discussion about LTO keeps going with many different points of view. If
    interested, you can read the latest contributions to the topic: lang/gcc11:
    Needs build time warning for /tmp consumption and lang/gcc11: build gets
    stuck. Reminder: LTO_BOOTSTRAP is an option enabled by default. If you
    build the port on your machine and its resources consumption is not
    acceptable, disabling this option will get you a lighter compilation.

  • jbeich@ submitted a patch to expose non-default -stdlib=libc++ support,
    which has been successfully committed to all relevant ports (gcc >= 11).
    link: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265962

  • diizzy@ refreshed the mirrors list in the MASTER_SITE_GCC variables, also
    removing ftp mirrors. The main GCC site is used as fallback. link: https://
    reviews.freebsd.org/D36372

  • Help is still needed with these three changes to work through with upstream
    GCC (requires expertise with the GCC sources and upstream, not with the
    ports framework):

      â–¡ upstreaming lang/gcc11/patch-gets-no-more

      â–¡ upstreaming lang/gcc11/patch-arm-unwind-cxx-support

      â–¡ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256874

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

sysutils/lsof major upgrade

Link:
lsof project repo URL: https://github.com/lsof-org/lsof

Contact:
Larry Rosenman 

sysutils/lsof had a major upgrade to no longer look in /dev/kmem for data, and
to use the userland API. This took a long time to hit the tree, but is finally
done. It fixes lsof(8) to work with ZFS again for the first time since
13.0-RELEASE.

This will make maintenance much easier going forward.

To the kernel folks: if you make changes that break lsof, please submit a
GitHub pull request to https://github.com/lsof-org/lsof. Please test any
changes to the interfaces that lsof uses and make sure they still work. These
all should be userland interfaces now, but please test.

My thanks to Warner Losh , Mateusz Guzik ,
and Ed Maste  for help getting this major change landed.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

Third Party Projects

Many projects build upon FreeBSD or incorporate components of FreeBSD into
their project. As these projects may be of interest to the broader FreeBSD
community, we sometimes include brief updates submitted by these projects in
our quarterly report. The FreeBSD project makes no representation as to the
accuracy or veracity of any claims in these submissions.

Containers and FreeBSD: Pot, Potluck and Potman

Links:
Pot organization on github URL: https://github.com/bsdpot

Contact: Luca Pizzamiglio (Pot) 
Contact: Stephan Lichtenauer (Potluck) 
Contact: Michael Gmelin (Potman) 

Pot is a jail management tool that also supports orchestration through Nomad.

During the last quarter, pot 0.15.3 was released. It contains a number of
improvements like mount-out to remove or unmount a previously mount-in folder
or filesystem, signal and exec commands, better jail lifecycle handling, and
many bug fixes.

A new version of the Nomad driver, nomad-pot-driver 0.9.0, was also released
with signal and exec support and stability fixes.

Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: a
repository of pot flavours and complete container images for usage with pot and
in many cases Nomad.

Since the last status report, many changes were committed, including many fixes
and improvements to core images like grafana, postgresql-patroni or loki.
Additionally, all images have been rebuilt for FreeBSD 13.1 and 12.3 and to
include the current quarterly versions of the packages being used.

Last not least, Luca held the pot implementation and ecosystem talk How far a
naive FreeBSD container implementation can go at EuroBSDCon 2022.

As always, feedback and patches are welcome.

From nobody Sun Oct 23 09:33:31 2022
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 4MwChL33YGz4fWb9
	for ; Sun, 23 Oct 2022 09:34:10 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MwChK2Q96z3DHr
	for ; Sun, 23 Oct 2022 09:34:09 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by smtp5.goneo.de (Postfix) with ESMTPS id 2570C10A32DA
	for ; Sun, 23 Oct 2022 11:34:01 +0200 (CEST)
Received: from hub1.goneo.de (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by hub1.goneo.de (Postfix) with ESMTPS id 3571210A1E96
	for ; Sun, 23 Oct 2022 11:33:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
	s=DKIM001; t=1666517639;
	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=jbbFGVwx4Bap7iJrCK/B6zL51N9pvJZhCxGjWfNi2kE=;
	b=Q8UXWAON9eYMbuQJWNhoobjVnkC/voqoCHv7nq6vmHehimvmX6Q7qZkJBhJOsAuvbkaK1y
	RyIVzk9401NI+pPbhACKjJ4HrEAqLVZ1XkXJ7rP8mMMrNPQkmnUAPGgfEezBrOSp/RNWmr
	Kvx1iQza0nanwX3byyiSp/gAQJXHydOqNL74iW12uF57oba9WsxtRvE6pCBGRWWzKisItr
	08Z1VzO2FgS3VNEgAJBkcjo2nkfEB7nBBdgam/C1pJpRioiO1mGR243Ih2KtTJAUITRk6o
	sRGi1wSd/HRUCM2o0mYjF03vxhGORzO+5CBQqGcZLP6aQI2GgtnlZs7gCozr7Q==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-183-091-027.77.183.pool.telefonica.de [77.183.91.27])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by hub1.goneo.de (Postfix) with ESMTPSA id ED7FF10A32F4
	for ; Sun, 23 Oct 2022 11:33:58 +0200 (CEST)
Date: Sun, 23 Oct 2022 11:33:31 +0200
From: FreeBSD User 
To: FreeBSD CURRENT 
Subject: Bug 206165 - resolv.conf(5) is missing documentation on options
 (i.e. EDNS0)
Message-ID: <20221023113358.5e8dea3e@thor.intern.walstatt.dynvpn.de>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-UID: 3310db
X-Rspamd-UID: be9f9a
X-Rspamd-Queue-Id: 4MwChK2Q96z3DHr
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=Q8UXWAON;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.60) smtp.mailfrom=freebsd@walstatt-de.de
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[walstatt-de.de:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	TO_DN_ALL(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	RCPT_COUNT_ONE(0.00)[1];
	ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[walstatt-de.de];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hello folks,

I ran today into a problem, that the reolveer option "edns0" isn't documented (as well as some
others). Searching the net reveals, that there is a PR open with exactly that issue since
January 2016, since then, code has changed I presume.

Could someone please take care of that issue? "man 5 resolver" does not cover all options one
can provide via /etc/resolv.conf, see 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206165

Thank you very much in advance,

O. Hartmann


-- 
O. Hartmann

From nobody Mon Oct 24 05:20:40 2022
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 4Mwk265B1Jz4gd4b;
	Mon, 24 Oct 2022 05:21:18 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mwk254KC6z3q5Q;
	Mon, 24 Oct 2022 05:21:17 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by smtp6.goneo.de (Postfix) with ESMTPS id ECBE610A32E1;
	Mon, 24 Oct 2022 07:21:09 +0200 (CEST)
Received: from hub2.goneo.de (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPS id 5E36510A32CF;
	Mon, 24 Oct 2022 07:21:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
	s=DKIM001; t=1666588868;
	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=JjltwPWZ/R9kTT9qnLxBCA/otUmJJGDOpjTPq0O+6BU=;
	b=Vp8sErnlf98R2WByYoynLITweQVGvg72XX/c4eqI0Ua/53eWZi5DsjOhZBWPkT7XOKcPCO
	AePEft5XZcoYYqocmEFdgoin2bKojB3xbLGAon3nSuUNCYDebjlmtUmK+hyr/l7zhB0d7Q
	RYtYX4N62bSn8gvbTXouXFPrTQELMOdjvLLLEdD13e5Zt1D/gEovUauZeyFi9F+m1pNxh0
	NJn2hMuVmRBKTgxvgtGnCPHKQF/r2oBbUYFEv+SyfBrKTW6ByBbtNJ666FCB5udf3urdeA
	P3tNqdBK21stClkmHHumG7cAR5eBZR8dwd2GiqpNcjgy7Bsr12achjU9oJhqww==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-191-058-066.77.191.pool.telefonica.de [77.191.58.66])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPSA id 2BFA310A32C0;
	Mon, 24 Oct 2022 07:21:08 +0200 (CEST)
Date: Mon, 24 Oct 2022 07:20:40 +0200
From: FreeBSD User 
To: freebsd-net@freebsd.org, FreeBSD CURRENT 
Subject: mpd5: Howto restart a connection from mpd5-console?
Message-ID: <20221024072107.471684ea@thor.intern.walstatt.dynvpn.de>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-UID: fa960d
X-Rspamd-UID: d57969
X-Rspamd-Queue-Id: 4Mwk254KC6z3q5Q
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=Vp8sErnl;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.31) smtp.mailfrom=freebsd@walstatt-de.de
X-Spamd-Result: default: False [-2.30 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-net@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	DKIM_TRACE(0.00)[walstatt-de.de:+];
	HAS_ORG_HEADER(0.00)[];
	ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[walstatt-de.de];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Hello,

On recent FreeBSD 13-STABLE (FreeBSD 13.1-STABLE #129 n252824-84b4709f38f: Sat Oct 22 11:45:10
CEST 2022 amd64), restarting mpd5 with an active PPPOE connection crashes FreeBSD.

We run a small home brewn FreeBSD based routing and firewalling instance based upon a
PCengines APU2C4. Since our ISP is very rigid by resetting the line exactly after 24 hours, we
prevent being reset in the middle of the day-to-day work by restarting the connection at
night. So far, that worked now for a couple of years - until recently, the cause is unknown,
possibly a bug in FBSD and/or mpd5.

mpd5 is built on a local poudriere utilizing FreeBSD 13-STABLE as well, last try was to have
mpd5 compiled with the same base of the OS as the router/firewall will run.

Now I try to find a way how to restart gracefully via mpd5 console (script) the connection
without restarting mpd5 and therefore not crashing the underlying system.

Any tips?

Thansk in advance,

O. Hartmann



-- 
O. Hartmann

From nobody Mon Oct 24 14:59:21 2022
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 4MwysB4z5vz4ftrV
	for ; Mon, 24 Oct 2022 14:59:26 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MwysB4S59z3NKW;
	Mon, 24 Oct 2022 14:59:26 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1666623566;
	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=BmcWbvxIAyBkXUPgLH3ikFOO+C94aU0PGfYxg7kQzuM=;
	b=jq0s0KRNmlsXTA92M3htotzjiKIyDxtRk7uFbkQ9tuJaNbxhI/O9aS6MgHf+G+BsmdREu4
	9LteylaLhitmF6xjUgsZ6CRyj7d7g99GkIYmDVVH0e+xYMUAOJxBMkd6yIcCCN5475LPif
	KBbH7IM532uUfWAC/eV3vWfRfrjHIKQuid3WFUaDcMVEuHbZ7LLeeIg56/f8k8cG0qxuDa
	VGTCob/tWEwgAYLWy6PP2zvBqQCMSN/IHRHpISuIRLXNfm0eYSPt4z7Hyf3rDsYdzcCPQz
	K7P9PKuXGxEbjiApKbmRY/P+ia/8BgLuFQxU2M9m3bUiLvM4kgSxwWAKnc6ZuQ==
Received: from [192.168.0.88] (unknown [195.64.148.76])
	(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 4Mwys92fpWzqm8;
	Mon, 24 Oct 2022 14:59:25 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Message-ID: <9b143ad9-2274-af16-294c-2bb5f5c7ad09@FreeBSD.org>
Date: Mon, 24 Oct 2022 17:59:21 +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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.4.0
From: Andriy Gapon 
Subject: Re: loader.efi module path vs kernel directory
To: Toomas Soome 
Cc: Emmanuel Vadot ,
 FreeBSD Current 
References: <20221020120809.f3a21c9a5c33a2ba440ddc01@bidouilliste.com>
 <31145ADA-5932-4858-B3F8-E21CA3F0721B@me.com>
 <02e51d32-7585-9a0e-ec41-6f9b198ce625@FreeBSD.org>
 
 <77E8AA2C-0B87-46BD-84A3-5E0099E2B7E1@me.com>
Content-Language: en-US
In-Reply-To: <77E8AA2C-0B87-46BD-84A3-5E0099E2B7E1@me.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666623566;
	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=BmcWbvxIAyBkXUPgLH3ikFOO+C94aU0PGfYxg7kQzuM=;
	b=Ln5aCurJvwYf8Ny7jCVljfPK20lRsnqNofWkLl/CSKwNNOAWVP1zFob2PF6dXieHDeDaH9
	TMFf/oZgHnu27cfTWddtwA+MJmIk+UXsEqIE+wQpdeLXrlPFqqgP7FC28ng9XdqdTF4uV4
	tDcWINGMEqAWogZm24qVCFoN0vR4HB6mo4FzC2GMNQ63lev/hcDr+ssgqsDvBju5p1zLqi
	Ops7kMrF2BQ9JbI6sXOjZ08saiy8wvCaeFGqAJJXNulESgoqBaIiI9zHPtajHjZI8mIIgc
	vkt1exCtPXwqXL0QlyCVBhDfH05zm3avCnPVPkjKNZQbwN1onPPhy0xz66yHOQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666623566; a=rsa-sha256; cv=none;
	b=c++PCA0u99cYbxDied6zRLHfIW1T4X8KZnRKpiMv/nvUNmRwltcad7GbIj918xCouWM+Vd
	vxrmnUPuywYizz9u8w3lFhChnaffYWWvl7/J7Ct3XwY0Yakbt2XnSPYXzIzRJe6FIgAZ85
	ePrfGhxch9NprfhV+5mVFXy5ujric+EKzGWTXKnMQ0Boeegf6uic76KFCRdv0cWfhPKsnK
	BgjLiwZo9WQfHP7o/vzrcW9N6sHJifQbTE/w2s8yJIpDxMw/IYISoSM3hXSdh12I59dsO3
	3CgwZOf4KkEN4OkSx7RZULfK8GBA7XjGMzeVIJxj9MEm6D7yMNnk8UmujSdgHQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

On 20/10/2022 13:59, Toomas Soome wrote:
> Whoops, meant cli.lua(8), of course.

Thank you very much to everyone who helped!

The commands are available indeed, just not listed by loader.
I had a recollection that in the past I saw them listed either with '?' or 
'help'.  Maybe that was with forth loader.

It would be nice if there was a way to list the extended commands online (via 
loader itself) as loader does not have command completion and it's not always 
possible to get another system for exploring manual pages while being stuck in 
loader.

Anyway, thank you again.

>> On 20. Oct 2022, at 13:58, Toomas Soome > 
>> wrote:
>>
>>
>> the problem with ‘?’ command is that it only does list commands written in C, 
>> it does not list scripted commands. cli_lua(8) should list lua specific ones. 
>> And at least my stable/13 branch does seem to confirm, enable-module, 
>> disable-module, toggle-module and show-module-options should be present 
>> (defined in /boot/lua/cli.lua). I am also pretty sure, Kyle did add those when 
>> 13 was current, lua version was missing those, Forth version had them first:)
>>
>> rgds,
>> toomas
>>
>>> On 20. Oct 2022, at 13:27, Andriy Gapon >> > wrote:
>>>
>>> On 20/10/2022 13:20, Toomas Soome wrote:
>>>> Also, instead of manual load, you may want to use enable-module.
>>>
>>> Emmanuel, Toomas,
>>>
>>> thank you very much for the suggestions.
>>>
>>> It seems like my installation may be messed up or outdated somehow, see below 
>>> (and sorry about those ^M-s).  I do not seem to have boot-conf or *-module 
>>> commands.
>>>
>>> I checked that the EFI partition has exactly the same loader.efi as in /boot, 
>>> but maybe some other files (configuration?) are outdated.
>>> Also, forgot to mention, this is with stable/13, not main / current.
>>>
>>> OK ?^M
>>> Available commands:^M
>>>  copy_staging     copy staging^M
>>>  staging_slop     set staging slop^M
>>>  efi-autoresizeconEFI Auto-resize Console^M
>>>  gop              graphics output protocol^M
>>>  uga              universal graphics adapter^M
>>>  efi-seed-entropy try to get entropy from the EFI RNG^M
>>>  poweroff         power off the system^M
>>>  reboot           reboot the system^M
>>>  quit             exit the loader^M
>>>  memmap           print memory map^M
>>>  configuration    print configuration tables^M
>>>  mode             change or display EFI text modes^M
>>>  lsefi            list EFI handles^M
>>>  chain            chain load file^M
>>>  netserver        change or display netserver URI^M
>>>  loadfont         load console font from file^M
>>>  grab_faults      grab faults^M
>>>  ungrab_faults    ungrab faults^M
>>>  fault            generate fault^M
>>>  boot             boot a file or loaded kernel^M
>>>  autoboot         boot automatically after a delay^M
>>>  help             detailed help^M
>>>  ?                list commands^M
>>>  show             show variable(s)^M
>>>  set              set a variable^M
>>>  unset            unset a variable^M
>>>  echo             echo arguments^M
>>>  read             read input from the terminal^M
>>>  more             show contents of a file^M
>>>  lsdev            list all devices^M
>>>  readtest         Time a file read^M
>>>  include          read commands from a file^M
>>>  ls               list files^M
>>>  load             load a kernel or module^M
>>>  unload           unload all modules^M
>>>  lsmod            list loaded modules^M
>>>  pnpmatch         list matched modules based on pnpinfo^M
>>>  pnpload          load matched modules based on pnpinfo^M
>>>  pnpautoload      auto load modules based on pnpinfo^M
>>>  nvstore          manage non-volatile data^M
>>>  map-vdisk        map file as virtual disk^M
>>>  unmap-vdisk      unmap virtual disk^M
>>>  bcachestat       get disk block cache stats^M
>>>  lszfs            list child datasets of a zfs dataset^M
>>>  reloadbe         refresh the list of ZFS Boot Environments^M
>>>  efi-show         print some or all EFI variables^M
>>>  efi-set          set EFI variables^M
>>>  efi-unset        delete / unset EFI variables^M
>>>
>>>> Sent from my iPhone
>>>>> On 20. Oct 2022, at 13:08, Emmanuel Vadot >>>> > wrote:
>>>>>
>>>>> On Thu, 20 Oct 2022 13:03:26 +0300
>>>>> Andriy Gapon > wrote:
>>>>>
>>>>>>
>>>>>> I recently needed to recover a system by manually preloading a driver.
>>>>>> To a bit of surprise, simple 'load $modname' did not work, I had to use 'load
>>>>>> /boot/kernel/$modname.ko'.  I didn't have to do this in a long time, but I
>>>>>> recall that the short command used to work.  Additionally, required 
>>>>>> modules also
>>>>>> failed to get loaded automatically because loader couldn't find them.
>>>>>>
>>>>>> I am not sure what the issue is.  Is it that /boot/kernel is not in module 
>>>>>> path
>>>>>> (as per /boot/defaults/loader.conf) ? Or is it that /boot/kernel does not get
>>>>>> added to the *effective* module path?
>>>>>>
>>>>>> Thanks!
>>>>>> --
>>>>>> Andriy Gapon
>>>>>>
>>>>>
>>>>> if you escape to prompt directly loader didn't loaded all it's config
>>>>> so there is no modulepath defined, you need to 'boot-conf' to load the
>>>>> configuration files.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> --
>>>>> Emmanuel Vadot > 
>>>>> >
>>>>>
>>>
>>> --
>>> Andriy Gapon
>>
> 

-- 
Andriy Gapon


From nobody Tue Oct 25 02:11:28 2022
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 4MxFmj72NHz4gGrX
	for ; Tue, 25 Oct 2022 02:11:33 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25])
	(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 4MxFmj1Z1zz3XRw
	for ; Tue, 25 Oct 2022 02:11:33 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
	by mailout.west.internal (Postfix) with ESMTP id 31C2E32008C3
	for ; Mon, 24 Oct 2022 22:11:31 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
  by compute1.internal (MEProxy); Mon, 24 Oct 2022 22:11:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:message-id
	:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=
	1666663890; x=1666750290; bh=XqfzPqCb4IwNKc8lB5ufT3bdbU5aKo46u4y
	q2QFtMI0=; b=BjLhuMGfaooOlOZ6j530D8BVaw2aFgi5hGMj7r0gHJ4fvka0Yok
	C7ktKS0jV12r4Wa5Ji1wcG8FK/6yls8cND4Ur6HyyVV2YWXWJodS5NEaSLWleB0P
	ZCD7BG7GitqcqeVye52inyAGzfFqHSUOGBM3tzI3bRu+T+ADO6qzOJu7mWfdv44p
	k6YeGHs+Dzmr+CK0D3ljDyOxPGdqUhI4Ld/3EjCLTPbAhEB+/HhGm+Ke9ndnxPAp
	ywAmGtfqSwrJpuWt2DG/FXdtpQQVOo62WTUgebTJkBbLm/TiRLn9nFzN+wSCWyKs
	kh9S1i4lEY1D+qmV8QV0OqewqLED+U0Tz4Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:message-id:mime-version
	:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1666663890; x=
	1666750290; bh=XqfzPqCb4IwNKc8lB5ufT3bdbU5aKo46u4yq2QFtMI0=; b=R
	cX/nGoKe96wNR7mNtKv6MSICclpGCV4rvLPk5Ht7qAnd38vlQwPUXpYlp69kTBTt
	xkA29cCz0PqWQ+zprSQkhQq41XCYiHjIDaa+9p2k3vepSDqDltOd7kTRM/9i7U7M
	TKnLTdkt8bSU+Q9CI45V9if3DRCFChJ4cimjijyX+YHJgAfd7z3c+OhsSzkimN/1
	xZ27l0rfBRr8RbgI8kzuDarjCRWLPAZONGK4H1ctpAJB7O1JkkD/A3G0azhC8cI+
	8RK4VPk8OZnbCxhUjfCOJZFmQOpFFnw63rQIZ13peMYML277IHk7gTail2C5dbMn
	0v4q8ONXu/lhtq82gfJXA==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrgedthedgheekucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd
    dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht
    vghrnhepveduffeivdfffffghfegfeejfefftdeiteehteekfefhvdefgfettdeuheegff
    eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho
    ihgusehfqdhmrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Mon, 24 Oct 2022 22:11:30 -0400 (EDT)
Date: Tue, 25 Oct 2022 03:11:28 +0100
From: void 
To: freebsd-current@freebsd.org
Subject: ns8250: UART FCR is broken
Message-ID: 
Mail-Followup-To: freebsd-current@freebsd.org
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
X-Rspamd-Queue-Id: 4MxFmj1Z1zz3XRw
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm3 header.b=BjLhuMGf;
	dkim=pass header.d=messagingengine.com header.s=fm3 header.b="R cX/nGo";
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-4.75 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.65)[-0.648];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3];
	R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from]
X-ThisMailContainsUnwantedMimeParts: N

hello freebsd-current@,

this started appearing in dmesg

ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
ns8250: UART FCR is broken
uart0: console (9600,n,8,1)
ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
ns8250: UART FCR is broken
ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart2: <16550 or compatible> port 0x3e8-0x3ef irq 4 on acpi0
ns8250: UART FCR is broken

The system is a bhyve guest running main-n258723-e0c3f66b4d5f on amd64
with a lightly modified generic-nodebug. There's no physical hardware
attached to any com port on the host. Do I need to be concerned with this
or is it a known issue? is it a real hardware problem? The host runs many
bhyve guests.

TIA,


From nobody Tue Oct 25 16:27:48 2022
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 4Mxcn22MRlz4gGLd
	for ; Tue, 25 Oct 2022 16:28:06 +0000 (UTC)
	(envelope-from ler@lerctr.org)
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mxcn11n9kz4F2g
	for ; Tue, 25 Oct 2022 16:28:05 +0000 (UTC)
	(envelope-from ler@lerctr.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Transfer-Encoding:Content-Type:Message-ID:Subject:To:
	From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description:
	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
	In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=GWnOofX3A295AJDk1jneTStpgooQ54OjyLBpvMvFzgI=; b=veDI8BYiSiO+o5Y+kHGi5YQ4tT
	POt1/NashZf3xUP5NLsfsgL+5NHui3c2+KSwVfj8r8IQ1olE2a3zqFzA+IR5+qftHrl0SJftMDudS
	q3RbVQmgioAAiD+W0iLT/0R/G9Xq0lc4293l5O5XePAJMzvw7KrhKXQPy3w+Aasx8NywDgV6zbchl
	tzOkMW3Qhwbc7AgRuLDco2HuYnB58doxiD0GR9i9DSaD2wIq4sSXW7gW41G0QR1ojEJp7zij1+fC+
	PlBf2KclFlyQGgI2TW3Yarnd/UHv7Jl97ou7PzaLsiXnvZMgcgaYVjRQIizKtSyPq2BTIVEtXrYIm
	i8sc93RA==;
Received-SPF: pass (thebighonker.lerctr.org: domain of lerctr.org designates 2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4 as permitted sender) client-ip=2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4; envelope-from=ler@lerctr.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([2602:fcdb:0:10:7ae3:b5ff:fe1b:23b4]:30804 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1onMmK-0006yX-FE
	for freebsd-current@freebsd.org;
	Tue, 25 Oct 2022 11:27:48 -0500
Received: from 2600:1700:210:b18f:5d54:379d:120c:7851
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Tue, 25 Oct 2022 11:27:48 -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
Date: Tue, 25 Oct 2022 11:27:48 -0500
From: Larry Rosenman 
To: Freebsd current 
Subject: BUILD BREAK:
Message-ID: <3addedfdc5fedbef0ac037a5e83abd2a@lerctr.org>
X-Sender: ler@lerctr.org
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4Mxcn11n9kz4F2g
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=lerctr.org header.s=ler2019 header.b=veDI8BYi;
	dmarc=pass (policy=none) header.from=lerctr.org;
	spf=pass (mx1.freebsd.org: domain of ler@lerctr.org designates 192.147.25.65 as permitted sender) smtp.mailfrom=ler@lerctr.org
X-Spamd-Result: default: False [-3.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	SUBJ_ALL_CAPS(0.90)[12];
	DMARC_POLICY_ALLOW(-0.50)[lerctr.org,none];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[lerctr.org:s=ler2019];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[lerctr.org:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:55103, ipnet:192.147.25.0/24, country:US];
	FREEFALL_USER(0.00)[ler];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Building 
/usr/obj/usr/src/amd64.amd64/tests/sys/net/routing/test_rtsock_l3.debug
--- all_subdir_tests/sys/kern ---
--- subr_physmem_test ---
--- subr_physmem_test.o ---
In file included from /usr/src/tests/sys/kern/subr_physmem_test.c:34:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/physmem.h:57:1: error: 
unknown type name 'bool'
bool physmem_excluded(vm_paddr_t pa, vm_size_t sz);
^



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106

From nobody Wed Oct 26 20:48:11 2022
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 4MyLW06gGcz4g1g9
	for ; Wed, 26 Oct 2022 20:48:28 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MyLW01nR8z45fH;
	Wed, 26 Oct 2022 20:48:28 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: by mail-ej1-f51.google.com with SMTP id k2so24854537ejr.2;
        Wed, 26 Oct 2022 13:48:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=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=5dTggOeEo8gcVqrFdVinElabDbbPFej6hzzA59bBK2I=;
        b=v+tUvM+u4bzfHy8qT9OLrOd6GFZX9Om+a+39BuMeY9+YXqvMiNNZMmaOR0nPvMB+ZM
         DEvu9SH/wPgJzIoiamd7oEGtVcV69144u7a7rI3fOvLLnVGKdViIJ+zRscPdQ7TV+lvw
         RILwF/Dnj/0iVih81aBz3br1GNNes//LTguL8W68T5WpOEPyTV2KxRuNpOtCpOq+ElvP
         Ewn28Af2tiNY9IiFuLuH8lkY9vDxCmzhom5N+lTZlJo5AQLQpye/FoPtMC9m8C4h0V6h
         yo44UL6rpSMf2NmwSX7p/98F/OqD0WmNU+I7VfW3+l62JrF5lBd1cYYeHQnDQswcYtBt
         FZbw==
X-Gm-Message-State: ACrzQf0fNcnKbhb9zpcdNWsrx7YiZfugQVZtU8qal4Yfg0tRCPAyjA5g
	L6b3l9UBklovTwDbTsLdRT70h3IdjFHsxMxz+QHdCy7ueZo=
X-Google-Smtp-Source: AMsMyM5cHJFmWa9qaY2ev8aeY7kVQodho5FbMEnS4Yp5wlvkJySJY+Pc+3b1yDbZaGoXvv+EDbmrN0dkFJwjthJdkQY=
X-Received: by 2002:a17:906:ee81:b0:77e:829a:76e9 with SMTP id
 wt1-20020a170906ee8100b0077e829a76e9mr40683010ejb.207.1666817305860; Wed, 26
 Oct 2022 13:48:25 -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: Ed Maste 
Date: Wed, 26 Oct 2022 16:48:11 -0400
Message-ID: 
Subject: Re: ns8250: UART FCR is broken
To: freebsd-current@freebsd.org, Colin Percival 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4MyLW01nR8z45fH
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com
X-Spamd-Result: default: False [-3.10 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[text/plain];
	RWL_MAILSPIKE_GOOD(-0.10)[209.85.218.51:from];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.218.51:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	MIME_TRACE(0.00)[0:+];
	FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com];
	RCPT_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[carpeddiem];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 24 Oct 2022 at 22:11, void  wrote:
>
> hello freebsd-current@,
>
> this started appearing in dmesg
>
> ns8250: UART FCR is broken
> ns8250: UART FCR is broken

This message was added as part of Colin's work to support FreeBSD in
the Firecracker VMM
https://cgit.freebsd.org/src/commit/?id=c4b68e7e53bb352be3fa16995b99764c03097e66

In this case it indicates that bhyve has the same bug/missing
functionality as Firecracker -- it doesn't implement the FCR_XMT_RST
or FCR_RCV_RST bits. You can safely ignore the message, and it will
disappear once someone adds the required support to bhyve. We should
probably also have the kernel emit the message only once. I've CC'd
Colin for comment.

From nobody Wed Oct 26 21:15:29 2022
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 4MyM6D50tlz4g5P3
	for ; Wed, 26 Oct 2022 21:15:32 +0000 (UTC)
	(envelope-from cperciva@freebsd.org)
Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204])
	by mx1.freebsd.org (Postfix) with SMTP id 4MyM6C4yQKz48lW
	for ; Wed, 26 Oct 2022 21:15:31 +0000 (UTC)
	(envelope-from cperciva@freebsd.org)
Received: (qmail 30611 invoked from network); 26 Oct 2022 21:15:30 -0000
Received: from unknown (HELO dell7390.daemonology.net) (127.0.0.1)
  by mail.tarsnap.com with SMTP; 26 Oct 2022 21:15:30 -0000
Received: (qmail 64184 invoked from network); 26 Oct 2022 21:15:30 -0000
Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1)
  by localhost with SMTP; 26 Oct 2022 21:15:30 -0000
Message-ID: 
Date: Wed, 26 Oct 2022 14:15:29 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.0
Subject: Re: ns8250: UART FCR is broken
Content-Language: en-US
To: Ed Maste , freebsd-current@freebsd.org
References: 
 
From: Colin Percival 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MyM6C4yQKz48lW
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 54.86.246.204 is neither permitted nor denied by domain of cperciva@freebsd.org) smtp.mailfrom=cperciva@freebsd.org
X-Spamd-Result: default: False [0.50 / 15.00];
	VIOLATED_DIRECT_SPF(3.50)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[54.86.246.204:from];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[cperciva];
	ASN(0.00)[asn:14618, ipnet:54.86.0.0/16, country:US];
	TO_DN_SOME(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	DMARC_NA(0.00)[freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 10/26/22 13:48, Ed Maste wrote:
> On Mon, 24 Oct 2022 at 22:11, void  wrote:
>> this started appearing in dmesg
>>
>> ns8250: UART FCR is broken
>> ns8250: UART FCR is broken
> 
> This message was added as part of Colin's work to support FreeBSD in
> the Firecracker VMM
> https://cgit.freebsd.org/src/commit/?id=c4b68e7e53bb352be3fa16995b99764c03097e66
> 
> In this case it indicates that bhyve has the same bug/missing
> functionality as Firecracker -- it doesn't implement the FCR_XMT_RST
> or FCR_RCV_RST bits. You can safely ignore the message, and it will
> disappear once someone adds the required support to bhyve. We should
> probably also have the kernel emit the message only once. I've CC'd
> Colin for comment.

Indeed, looking at usr.sbin/bhyve/uart_emul.c it looks like FCR_XMT_RST is
not emulated.  This is different from Firecracker, which doesn't emulate
either anything from the FCR and where I was seeing the receive side not
being flushed, but I'm glad my warning was able to flag a bug. :-)

If "void" is comfortable with kernel hacking, it would be great to confirm
that the warning is indeed coming from the transmit side not being flushed;
a printf("drain = %d\n", drain); would be sufficient.

And yes, only emitting this warning once per device (or once per boot?)
would probably be good.

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid

From nobody Thu Oct 27 03:29:27 2022
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 4MyWPp0xq4z4fx8v
	for ; Thu, 27 Oct 2022 03:29:34 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20])
	(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 4MyWPn1T9Bz3STY
	for ; Thu, 27 Oct 2022 03:29:33 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Received: from pps.filterd (m0170398.ppops.net [127.0.0.1])
	by mx0b-00154904.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29QIpIJ5024613
	for ; Wed, 26 Oct 2022 23:29:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject :
 date : message-id : content-type : mime-version; s=smtpout1;
 bh=N96dhxGDEn2/t67fjtTfpDfj+R/n0oPchyfko4kz7Wk=;
 b=XPM+H0rIGoXzyT/hkUEt/iOrIa5etYw/pkXS1r24tbs07Ps2SfPPNt1X+7Y88P7a8NMm
 ZPkecb9NpBGzkj5y++RaRn8utZHVoCABgjICV4uQ3JEg2sWF/Xjs3561d89onleLBDOZ
 2Si+p6D+Da+yd9bqP2k7QD1eeE6TtMthqTMuPgmyQqzbHqVvaI/g1V8EtVcXtzlzpEvm
 umhogB+jxuHRbYeOH0dOFx08S3KL208405+HNMKOth3sF6fkZCTSrNJ/Ps0veeONmN3t
 51DF2hlX5PuIy3+ebhuRoTSZd9aN0IRDNZgQzr5/gw0eSjh6NS9BF7RswKSBrAGBSstB Mg== 
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37])
	by mx0b-00154904.pphosted.com (PPS) with ESMTPS id 3kfahrhhyw-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
	for ; Wed, 26 Oct 2022 23:29:30 -0400
Received: from pps.filterd (m0134318.ppops.net [127.0.0.1])
	by mx0a-00154901.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29R3SSGp013961
	for ; Wed, 26 Oct 2022 23:29:30 -0400
Received: from nam02-bn1-obe.outbound.protection.outlook.com (mail-bn1nam07lp2040.outbound.protection.outlook.com [104.47.51.40])
	by mx0a-00154901.pphosted.com (PPS) with ESMTPS id 3kfah55g3k-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)
	for ; Wed, 26 Oct 2022 23:29:30 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=UXHNYPNo+HU77YkCm/byhKRjf31DupeZciL62m8+ndOeFhWzvuic9ksj7kLTfQR/0zh44K94qaa2AeZcMfW6HhrI0Eq1rwou97/dkfe71JVnM5dpRvVNe4S3SLSEVABWgKS4zF/Pw89EXKmDzJU5BoWJtYLubGpFShCZ6r8qK9MxyJgwEIIWU6sJALF4HYOTp1CjiK4ySV9JcX7iCQVHsiaPli0YVpoSITOiNar9EE5tSXokhO+WpE+H0Xssq0YP9+uS7YxkJArn+khu/+SLrFfMGzAL7gJiYefwXnCQ4FFu0PtwJNw7UzpeLwGozKrL+PiYklF5Q7wiLwlVN1VcoQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=N96dhxGDEn2/t67fjtTfpDfj+R/n0oPchyfko4kz7Wk=;
 b=DI1XLvtdzwR+eTf/6GxpSl90nEBrWYsipXxyg1LdyERBh3h7r+NFlsQ52yGbHhFqFTuenpIS6ROngKd8dAxAvyITGqdoQcLYGcpKS+fk9CSn33a2oZlFuw7wv8MlKXwqLZ+9Hzg8ywkCfJqK0R0mHiDtvI38tG+FFtmiXzf/HQvg4ksvNmrH+e/yp7PI+fGZ8JBJ/MawsWrC8LWWvx2X1FzcD2wGTDv6mTO1L66g3t1AkisNqr2lGRhENk/0jwMxA3EqzBbfuxO/eBF/buAbNiIMaxmaAp8LsQ2roaqM4OrF2xH1tgr5Pfud31/j8L2Klx7wq11EG9nuvMnBAA7mqQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com;
 dkim=pass header.d=dell.com; arc=none
Received: from PH0PR19MB4938.namprd19.prod.outlook.com (2603:10b6:510:94::9)
 by BL3PR19MB6465.namprd19.prod.outlook.com (2603:10b6:208:3b4::20) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.28; Thu, 27 Oct
 2022 03:29:27 +0000
Received: from PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::2674:57b2:996:111b]) by PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::2674:57b2:996:111b%3]) with mapi id 15.20.5746.028; Thu, 27 Oct 2022
 03:29:27 +0000
From: "Chen, Alvin W" 
To: freebsd-current 
Subject: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake) support
Thread-Topic: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Thread-Index: AdjptCu1BUq3xWQjS9a169SAwDUljw==
Date: Thu, 27 Oct 2022 03:29:27 +0000
Message-ID: 
 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Enabled=true;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SetDate=2022-10-27T03:29:25Z;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Method=Standard;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Name=No Protection (Label
 Only) - Internal Use;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ActionId=21e67b69-dbdf-4c03-b91c-5d05dc8534f7;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ContentBits=2
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR19MB4938:EE_|BL3PR19MB6465:EE_
x-ms-office365-filtering-correlation-id: 5084a2b4-582f-4025-3f42-08dab7cb73c1
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 i4Xc0sfBCNpikfcpSsgemDT36bhww0i5qpF9ftI7kmi5Ae4fuWysN+WZbbdY7PcLduQ065kSEgyLdBSapGUBIfjXq6jXCJgI7WOV5ZnF0tD2+h7A2lhR3btte8EO6TFXa6E+sJ15DC6slpnAHTkzivK0vtgnqwAUkoKTLFJuyoC7T0vSfcoSqe0FF81oXZqnfl3uhW/GwbafSCU6i5Oh+u/Z/NQm9P68XVli/5kvNciYnI/wPzIcpLpUuTqhvqBEMLgZ1oLQpPjVy4gvlnCEWefIMYBWvGi+nRMJjuBNF8JbvfreDlsj3fIrVq/2ZBzJXGAr9HsTxQXlEEk1CtYxHTuJqLnBBbpeEO9gxBXuddVAhW0wcvBPkBtMORz1kJCrP5kxFVDDfNT5xuDcWZlV17Kzv7y+80VJNpLKWCfHJu3Tx3lIdKrwBaRD74AU3dELfjasP/SFsownbf/K08ZvmrvyJ8PXfWXEAX97KpMk1pn3OoThOuAXdFVaii3HhCuqIH+JjrlNsSamymRrY5AlKxUFLP9ut2EwGxXOF2+nxERUTIsBE0v4bcoj3QTeNowASf+04W5+6vNmpmXtSsFqThizP2FIPk+dgzpeLWsTGntZ1BzDPstBTSD3Wgs+fsZcc9Ff1b9QySvuZQbQTJgoIlYHBE1fco2uWz7Onk3Iger9Vt8rCZbT4jryATeZy43mFokjnkfAcL7tJUySn9ceNTMAXxZtkbF0ZLu89KJqtNKxYY66Xt6CttC6UONV+vDpgvidTYgoaOvtUuKPQe/MZw==
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR19MB4938.namprd19.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(346002)(376002)(396003)(39860400002)(136003)(366004)(451199015)(66446008)(33656002)(558084003)(86362001)(66476007)(38100700002)(82960400001)(38070700005)(8936002)(5660300002)(76116006)(66556008)(66946007)(52536014)(6916009)(122000001)(6506007)(8676002)(7696005)(9686003)(26005)(186003)(71200400001)(2906002)(316002)(786003)(64756008)(478600001)(41300700001)(55016003)(66899015);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?YYNIO+fDPoHV7HBh7vXK9AYY/piHJCbc7icP0WBZXISjKyBxI3TZYqPsb1/J?=
 =?us-ascii?Q?jqmbP+QSku100Qk381Ua1E0XQRb+kYbGnLzifsLW+aFdGuZiKyGzto0ZkVeA?=
 =?us-ascii?Q?jS59xEmKfSOmKLzuFiV46/tPQBxCodpwWm0PAw3ZcqKSeEt7cItz56uZEYVf?=
 =?us-ascii?Q?q2iyZm9i4T4eZcTunZGzaynQGzyqgghmRgJS6jrLvm9CIigd4fapY9ICdr9m?=
 =?us-ascii?Q?OkrEaGXXmn/FSg0wqie62S1EklQdhlycb1P0PMYA6DGCTHH0qvS/eQw7ipTq?=
 =?us-ascii?Q?qCDhEBRDPWt+bM06gEi03JvXPUqZip1lPzbhBNWzVDqPTZ2Tr5irJkrJks0g?=
 =?us-ascii?Q?p2NiFYWILjgOzy/4BXYOiidYutmivASFimMOKVD9cki+T7Q12PD/P+55/Mp8?=
 =?us-ascii?Q?9bzjxnlij5KmnNj1V3/Mh2tAf0OKogC/d3N+sjiIiGZH53/Nw6vzFHduRm1u?=
 =?us-ascii?Q?7LKMSNeW7NcEkiNPw21QYWXtJVlja2BaQg3J2XO6XZNYwcsCDvSr7N/HVNdE?=
 =?us-ascii?Q?cj1KQoj28A9KuLg6RU1Fe5JZnMYW6dSkGsaOhz29MnJLhhhQ+N3uMOmyj230?=
 =?us-ascii?Q?/xmKNT54OdvyfgzhFOZpQ+ZKe1fbPSu64n8AWbUlS4Amgud5Qu9EeDbRuWhD?=
 =?us-ascii?Q?kTMrURVB+gtxH+oGkMYWNLDYXrDuiZvlwkv4EUJbtPISHTOZfSqWxcCM041c?=
 =?us-ascii?Q?JOJrhUJ7XjLtHRK8V/ZGl3Z9hGF2WGpuM/P4xJJ2Pt7oncXTW+OXeGmYTo8y?=
 =?us-ascii?Q?K68kpMJnmBsEs4KPubR6Ks7yzfQjAqaHzAYMopAbI+aUH6UXr7+1t7Ht4gdL?=
 =?us-ascii?Q?ZFPU0nDZZbjWBASUK+S8xgYfdnRaC0JC8yl0ujrLZf4i+DeFBMxyzDY2hEBP?=
 =?us-ascii?Q?JdfdTggEHJJGLXQ6QnRN+LjcdKSkzxsX+ErJv4NFHT5ryrjro8xvggEcJvn5?=
 =?us-ascii?Q?a8N0Kh0fEGVedKZ8J3YB8aDrJ1wx9q+xotUAL8TxCAU95wwxRjP3jglOyyN1?=
 =?us-ascii?Q?ljgye3aH+yE54wGWqBzBR4KRTX2aVYIfk506XMNWScWErBZBC7sD6cwuvQv/?=
 =?us-ascii?Q?TouCs3cU/j4PE+0foZGzt1eQiimQsnkmk83R+l+XR6yYLQSATB5hiI1sVOWM?=
 =?us-ascii?Q?qLJlPN9ZUTzlvl09xV80xZM6U92SFgx5ubbClYjS71lkCKWzFw0JKz7lCsdX?=
 =?us-ascii?Q?d4COTFaq55Qk3WxEEC2IuMGtLTXmQySkvatag5eROTqi2RIFzyV0yLCMsuyI?=
 =?us-ascii?Q?dJS3qg0+PcjJTf51VmvEtY+TW58P8JNZfcww6Rz8Tg31lrhzmsl5JCvuwyJW?=
 =?us-ascii?Q?e5hVhovyjgHEIwwnZWblAkCV05vWKw9U8c78N3u2nAvOpJiYtwUXwWHis7wP?=
 =?us-ascii?Q?wXp9PxvBC2ymd4AcWJ+W4Ih6JNh3PaW5AAPv2Jp13SjtO4Ywoc2bVI13mc9S?=
 =?us-ascii?Q?wYp8xDItKt39XQ/Ud6o2FIRuZ2UDXagTPuVb+c53Qzs7S+Zdy2/EI0bWJHG+?=
 =?us-ascii?Q?qNvlEkMbrGhSKWxqwad7MYT3eKtSGoqHdjooM4Gc+M+CVlvalA7D8riTOK/a?=
 =?us-ascii?Q?lCYfdyyD4xVdZL5HD93NFBPuhDesoJtKug5r6kKe?=
Content-Type: multipart/alternative;
	boundary="_000_PH0PR19MB49386F16177AC787CFFAD05C9E339PH0PR19MB4938namp_"
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-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR19MB4938.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5084a2b4-582f-4025-3f42-08dab7cb73c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2022 03:29:27.4478
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vPDQ8axWPZ+EfJX3UQPfwNGtwr13oq1nVJ8HH1gXYvwvOJmI/1vcqQIW9e35hWWyKR+3Q8oYb8TgAazwTh4AmA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR19MB6465
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-10-26_10,2022-10-26_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0
 clxscore=1011 priorityscore=1501 bulkscore=0 suspectscore=0 spamscore=0
 malwarescore=0 lowpriorityscore=0 impostorscore=0 mlxlogscore=502
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2210270018
X-Proofpoint-GUID: dWCAP755G_Rmw9UsiEv28i5p2BHZdvUS
X-Proofpoint-ORIG-GUID: dWCAP755G_Rmw9UsiEv28i5p2BHZdvUS
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 suspectscore=0
 phishscore=0 mlxscore=0 mlxlogscore=612 bulkscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000
 definitions=main-2210270018
X-Rspamd-Queue-Id: 4MyWPn1T9Bz3STY
X-Spamd-Bar: -------
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=dell.com header.s=smtpout1 header.b=XPM+H0rI;
	arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}");
	dmarc=pass (policy=reject) header.from=dell.com;
	spf=pass (mx1.freebsd.org: domain of Weike.Chen@Dell.com designates 148.163.137.20 as permitted sender) smtp.mailfrom=Weike.Chen@Dell.com
X-Spamd-Result: default: False [-7.10 / 15.00];
	WHITELIST_SPF_DKIM(-3.00)[dell.com:d:+,Dell.com:s:+];
	DWL_DNSWL_LOW(-1.00)[dell.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	ARC_REJECT(1.00)[signature check failed: fail, {[1] = sig:microsoft.com:reject}];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[dell.com,reject];
	R_DKIM_ALLOW(-0.20)[dell.com:s=smtpout1];
	R_SPF_ALLOW(-0.20)[+ip4:148.163.137.20];
	RCVD_IN_DNSWL_LOW(-0.10)[67.231.157.37:received];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:22843, ipnet:148.163.137.0/24, country:US];
	RWL_MAILSPIKE_POSSIBLE(0.00)[148.163.137.20:from];
	RCPT_COUNT_ONE(0.00)[1];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[104.47.51.40:received];
	RCVD_COUNT_SEVEN(0.00)[7];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[dell.com:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--_000_PH0PR19MB49386F16177AC787CFFAD05C9E339PH0PR19MB4938namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Any body know the status to support P Core and E Core?
Now WA is: disable PCID.


Regards,
Alvin Chen
Dell ThinOS | Dell - Comercial Client Group
Teams/Zoom: weike_chen@dell.com



Internal Use - Confidential

--_000_PH0PR19MB49386F16177AC787CFFAD05C9E339PH0PR19MB4938namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Any body know the status to support P Core and E Cor=
e?


Now WA is: disable PCID.


 


 


Regards,


Alvin Chen


Dell ThinOS | Dell – Comercial Client Group 


Teams/Zoom: <=
span style=3D"color:#0563C1">weike_chen@dell.com


 




Internal Use - Con=
fidential






--_000_PH0PR19MB49386F16177AC787CFFAD05C9E339PH0PR19MB4938namp_--

From nobody Thu Oct 27 12:57:58 2022
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 4Mym1g3MQPz4fy2F
	for ; Thu, 27 Oct 2022 12:57:59 +0000 (UTC)
	(envelope-from matteo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Mym1g2qt6z3DNh
	for ; Thu, 27 Oct 2022 12:57:59 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1666875479;
	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=1bn2oMc1Jh54JbUNJR5nABGyFHmTW38HMJPwFPfi3Q0=;
	b=gGLuKXRNoSfLneiUN4M7Ce6TH5CgtXr9TVvJIq6uw6EQM4ah8SrjnvQ+rRjTw6T0GBsIvC
	1WjJydRUtEJThwECc4IFjnxq3Lb7dOktni4ZLyeV8v/PqmOdLMT/xpxucnQEYVGQWEsGmj
	0gbsjnRtwaGyOKfZOsx0iAOehbqbMyQ9ij9xpNTbsQKcGZ/lD+2zLYrUhX59ljZVd+crCR
	Qopu+ux/GuCYHu6TSYMmZmUuyBzHwBbmi5elGBcYboCO+toXqDZKibcdBqPFzn7m9M4N2D
	PUHsR84QpJmuVa2FJ+FqBdWgMNyBiQxUo2g5Sh+/AP77AL2YuIgvFXzmAWUa7w==
Received: from ubertino.local (unknown [IPv6:2601:19b:4400:1779::102c])
	(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: matteo/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mym1g177SzqC5
	for ; Thu, 27 Oct 2022 12:57:58 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Date: Thu, 27 Oct 2022 08:57:58 -0400
From: Matteo Riondato 
To: freebsd-current@freebsd.org
Subject: Re: ns8250: UART FCR is broken
Message-ID: <20221027125758.nexluqtw6n2tgklq@ubertino.local>
X-PGP-Key: http://rionda.to/files/matteogpg.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-sha512;
	protocol="application/pgp-signature"; boundary="u772wrfl6ai37fqp"
Content-Disposition: inline
In-Reply-To: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666875479;
	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=1bn2oMc1Jh54JbUNJR5nABGyFHmTW38HMJPwFPfi3Q0=;
	b=onhjdjMVKkTsoysOeIHCdNPwIZHHvESISFndt75UjPg8KG7NMel4pT2q9BBt65xZhzz+MV
	FdYYf9reu8ec7nfSqEbDxDoKAEqmSIklTAftaamvBjahApRmXjZY2bYE/W5ha69pwY4UnR
	5RgOR+WPeZXB0vx2dRCEbtke9GMyLYzS9zN9JsN6ZOoEC83DNdlcbA6YjUmj4SOaApBUZB
	9BRGI9BenVMWkDtsBrdsfENfcDhmlzo+o4sRZ8QZwKxSs4AvW+BHAy4h8QV+SODR4Rvu0w
	wl1qkJCOX8NQNAmAESiYb8QNrgFGGLUfFeAkJ1O25tk+iLoxWBb+pOkinYSnaw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666875479; a=rsa-sha256; cv=none;
	b=Cmu2ZSKuEjihrupPETmwueau3vzal3m5w+1HGqDkV+02vWh0TO6fivBjrpSQyYNujhg8Dl
	R9gUledeVLnSifHUH0GTFSA6MCOwoyU9WMFjtHVsEXA/UnpIcVy0Mzn273My6wp/ZcazI7
	qDKJJfaASXQBZFFY/fd3wPet8pKlmudGik2doJBXORa2QLoH3Vcpdpu5+hMquDNruZxTwV
	MRpDeMY3gOwq2QZcNpMiP4xWFseDsSWK5krvwwahmyIe5yq6et7qP7F6tvuAT71rELlYpN
	sELUUAwZ9VHBpnz1D3WFbMpZEHbfbrEmocx/Pi1VKzlqijApH0tgHU2GNqjQEw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--u772wrfl6ai37fqp
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-10-26 at 17:15 EDT, Colin Percival  wrote:

>On 10/26/22 13:48, Ed Maste wrote:
>>On Mon, 24 Oct 2022 at 22:11, void  wrote:
>>>this started appearing in dmesg
>>>
>>>ns8250: UART FCR is broken
>>>ns8250: UART FCR is broken
>>
>>This message was added as part of Colin's work to support FreeBSD in=20
>>the Firecracker VMM=20
>>https://cgit.freebsd.org/src/commit/?id=3Dc4b68e7e53bb352be3fa16995b99764=
c03097e66
>>
>>In this case it indicates that bhyve has the same bug/missing=20
>>functionality as Firecracker -- it doesn't implement the FCR_XMT_RST=20
>>or FCR_RCV_RST bits. You can safely ignore the message, and it will=20
>>disappear once someone adds the required support to bhyve. We should=20
>>probably also have the kernel emit the message only once. I've CC'd=20
>>Colin for comment.
>
>Indeed, looking at usr.sbin/bhyve/uart_emul.c it looks like FCR_XMT_RST is=
=20
>not emulated.  This is different from Firecracker, which doesn't emulate=
=20
>either anything from the FCR and where I was seeing the receive side not=
=20
>being flushed, but I'm glad my warning was able to flag a bug. :-)
>
>If "void" is comfortable with kernel hacking, it would be great to=20
>confirm >that the warning is indeed coming from the transmit side not=20
>being flushed; a printf("drain =3D %d\n", drain); would be sufficient.
>
>And yes, only emitting this warning once per device (or once per boot?)=20
>would probably be good.

I got the same message on real hardware, no virtualization involved as=20
either host or guest. Is that expected at all?

Relevant lines from /var/run/dmesg.boot:

ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (115200,n,8,1)
ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
ns8250: UART FCR is broken

Thanks,
Matteo

--u772wrfl6ai37fqp
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmNagFATGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVAdiaD/sH+AwdmtBelsTFQYHTmhQjwUdlUPcJ
kfl76olCRnHw+geWQUZ4XpAVwV7GkcJ/4DWRrsVBtLTARgu/jomL40rbwPCD4WlQ
xAvZPbgKkOyQrbFhyknY8YDqgMidBqCCidyn19AAqk+NfuERleUbI5d1m6J9XdCJ
C1eTBbBsZECwYbGuE/ClswcKvlBxDUNc8RYyd6AX5b7kLOQq8uBJXh+OXM1xuUHd
rPQoFzVgCBKnFeOWnpCxhvDp2oVFsx8ZOYKgf/gFdCLDUCwVvohDzcrERvO9pvsm
rSpXY+G/s+efKQuBfRER6B8hd1X3IJYPYUOB/q8f6vRehwpk87Oj1yMCZIFs9htf
YY8V+yYCsqMcoQ7tr0K7qvx036fjjHNZ5b2dd1tz++IiOCxPFU06C69jcdR7uBWW
YqBF2X4tHVQd+UvibhFuBUHzaBdU7ouaT//DYmE9x8xAL6OCbatqMpdYy+iBaHev
unP2/Hk1kkoQFUWzIuDRSkIzGV/WBI4i4vwaOG9dkgKVbpD/CMGYult5e7OOtQap
fWra8iknqd8e5xd4ujS/nCSkkvVrRx3LWFQ1KoM6G6/1dd7ItnKFcQvRHcLGKLfZ
XO8pP6Fx4vahm7MEu+82jlMlNpUxzkp2MXXtybMfzimlP7VONSyrTR6X0EWR8lg9
A1fWChLn0ONvYQ==
=j9Ka
-----END PGP SIGNATURE-----

--u772wrfl6ai37fqp--

From nobody Thu Oct 27 14:42:52 2022
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 4MypLn4mzrz4gCgY
	for ; Thu, 27 Oct 2022 14:42:57 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25])
	(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 4MypLm6ZVgz3WVJ
	for ; Thu, 27 Oct 2022 14:42:56 +0000 (UTC)
	(envelope-from void@f-m.fm)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
	by mailout.west.internal (Postfix) with ESMTP id 288C23200077
	for ; Thu, 27 Oct 2022 10:42:55 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
  by compute2.internal (MEProxy); Thu, 27 Oct 2022 10:42:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc
	:content-type:date:date:from:from:in-reply-to:in-reply-to
	:message-id:mime-version:references:reply-to:sender:subject
	:subject:to:to; s=fm3; t=1666881774; x=1666968174; bh=WMDDwE1Zje
	SG6kvq0XPMpAk6XvnNQwAkKWnbDEyNHL8=; b=g6JjVQCbZwW961NeW08rWSa1hc
	H3slTWxgkE4QKkoON9hnRtx41hW2ZkfEgGja4fUVko4msvlRWs1srA4rn+gylZbV
	i9ajimi7NDfUdvFUmDNJd6iAerDxlMZxquBchQnhkGurcDQiUzpr1+qe+44PwlHE
	5Rcp7Oy1v2wXXTmvyP+J8jxgDwQgGlkee7Iwu5Unr6Np6IF+EdiLktEyJxYKPW+e
	bupittXYbq3GPdz4UAYI3Yxj8lYGe21xJl6/X/yHREh0E6nC/03x3oyPoi3L1B0+
	qgFTc41lzFZg7XJLneulBSNXcXM8u0uNvaElguSmPdDIGoORC+AypqR9t0YQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:date:date:feedback-id
	:feedback-id:from:from:in-reply-to:in-reply-to:message-id
	:mime-version:references:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm3; t=1666881774; x=1666968174; bh=WMDDwE1ZjeSG6kvq0XPMpAk6XvnN
	QwAkKWnbDEyNHL8=; b=IcFOIFUW83svLRT3SWBBhW/XgOR39d2o935zZAUxCYyp
	j8Z4JZQQv92ui605li4eYM8z/mIxojhQifCDzfKDCXAN9UFJAJJL0nSC66dPfDHN
	GbNVF+78yLNjkY5kMRYtD2BhNCitL2Sb9nbIR2ikCamtGGdicoaniskJgyhUUFCO
	boFsS+qVY+sK5yBbawnW9XxDZUxlu+/9xtz0kgxMCe0WbWOVUCJaFZl172lQTfBi
	lattwqVmq00cwjC6JOtAFDwShxt4GMNI5SYxxt/rnBA+X0lrfB6N39mFwgzBTfQP
	KmKlo9NVNGFI8maPJBzEYUzIEfCptiAdiou3k/8Z3Q==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrtdeggdejkecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttdertd
    dttddvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght
    thgvrhhnpeekleduvdelhfeileefgffghfffkedtheellefgudfgvdegkeejjedutdehhe
    fgueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehv
    ohhiugesfhdqmhdrfhhm
X-ME-Proxy: 
    
    
    
Feedback-ID: i2541463c:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Thu, 27 Oct 2022 10:42:54 -0400 (EDT)
Date: Thu, 27 Oct 2022 15:42:52 +0100
From: void 
To: freebsd-current@freebsd.org
Subject: Re: ns8250: UART FCR is broken
Message-ID: 
Mail-Followup-To: freebsd-current@freebsd.org
References: 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4MypLm6ZVgz3WVJ
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=f-m.fm header.s=fm3 header.b=g6JjVQCb;
	dkim=pass header.d=messagingengine.com header.s=fm3 header.b=IcFOIFUW;
	dmarc=pass (policy=none) header.from=f-m.fm;
	spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=void@f-m.fm
X-Spamd-Result: default: False [-4.74 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	NEURAL_HAM_MEDIUM(-0.90)[-0.901];
	NEURAL_HAM_SHORT(-0.74)[-0.741];
	DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none];
	R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3];
	R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[f-m.fm];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[f-m.fm];
	RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, Oct 26, 2022 at 02:15:29PM -0700, Colin Percival wrote:

>Indeed, looking at usr.sbin/bhyve/uart_emul.c it looks like FCR_XMT_RST is
>not emulated.  This is different from Firecracker, which doesn't emulate
>either anything from the FCR and where I was seeing the receive side not
>being flushed, but I'm glad my warning was able to flag a bug. :-)
>
>If "void" is comfortable with kernel hacking, it would be great to confirm
>that the warning is indeed coming from the transmit side not being flushed;
>a printf("drain = %d\n", drain); would be sufficient.
>
>And yes, only emitting this warning once per device (or once per boot?)
>would probably be good.

I'm happy to do some kernel hacking with this vm. Tell me what I need to
do.

Thanks,
-- 


From nobody Thu Oct 27 15:13:04 2022
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 4Myq1c1Fkyz4gHGs
	for ; Thu, 27 Oct 2022 15:13:08 +0000 (UTC)
	(envelope-from agh@riseup.net)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mx1.riseup.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Myq1b2CKgz3cjt;
	Thu, 27 Oct 2022 15:13:07 +0000 (UTC)
	(envelope-from agh@riseup.net)
Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84])
	(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
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.riseup.net", Issuer "R3" (not verified))
	by mx1.riseup.net (Postfix) with ESMTPS id 4Myq1Y0PS7zDrCg;
	Thu, 27 Oct 2022 15:13:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
	t=1666883585; bh=TmXbVl3e06waUvza25l9l6bkuJ06QqK1XQtigpsqgT0=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=kkLoGMIL4q1YXvXB+r1NkLiV1EluX9tWFDCapjMTlyrRkmi1gWOLncB59q/jrgUEB
	 oiBmJoUg/qg3HWNw9Y7/AwxLKNK7qL2YvUi/E/FXQWJNR4jBdHEbPhacHMVyKPiBeQ
	 eGC0jxByMLz3DR20frJiN9U/Vqv9O7UZSC2i3z0k=
X-Riseup-User-ID: D7D3EA2E3BE4905ED36A1D1DED9511C5C9F8BD4FD61299BBFB3BE690B95A2F07
Received: from [127.0.0.1] (localhost [127.0.0.1])
	 by fews2.riseup.net (Postfix) with ESMTPSA id 4Myq1X68FVz1yPb;
	Thu, 27 Oct 2022 15:13:04 +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: Thu, 27 Oct 2022 15:13:04 +0000
From: Alastair Hogge 
To: Matteo Riondato 
Cc: freebsd-current@freebsd.org
Subject: Re: ns8250: UART FCR is broken
In-Reply-To: <20221027125758.nexluqtw6n2tgklq@ubertino.local>
References: 
 
 
 <20221027125758.nexluqtw6n2tgklq@ubertino.local>
Message-ID: <9e39e3a2d2488815736c482de3f8b411@riseup.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4Myq1b2CKgz3cjt
X-Spamd-Bar: ----
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=riseup.net header.s=squak header.b=kkLoGMIL;
	dmarc=pass (policy=none) header.from=riseup.net;
	spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net
X-Spamd-Result: default: False [-4.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[riseup.net,none];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[riseup.net:s=squak];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from];
	RWL_MAILSPIKE_GOOD(-0.10)[198.252.153.129:from];
	DWL_DNSWL_NONE(0.00)[riseup.net:dkim];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[];
	ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[riseup.net:+];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-10-27 20:57, Matteo Riondato wrote:
> On 2022-10-26 at 17:15 EDT, Colin Percival  wrote:
> 
>>On 10/26/22 13:48, Ed Maste wrote:
>>>On Mon, 24 Oct 2022 at 22:11, void  wrote:
>>>>this started appearing in dmesg
>>>>
>>>>ns8250: UART FCR is broken
>>>>ns8250: UART FCR is broken
>>>
>>>This message was added as part of Colin's work to support FreeBSD in the Firecracker VMM https://cgit.freebsd.org/src/commit/?id=c4b68e7e53bb352be3fa16995b99764c03097e66
>>>
>>>In this case it indicates that bhyve has the same bug/missing functionality as Firecracker -- it doesn't implement the FCR_XMT_RST or FCR_RCV_RST bits. You can safely ignore the message, and it will disappear once someone adds the required support to bhyve. We should probably also have the kernel emit the message only once. I've CC'd Colin for comment.
>>
>>Indeed, looking at usr.sbin/bhyve/uart_emul.c it looks like FCR_XMT_RST is not emulated.  This is different from Firecracker, which doesn't emulate either anything from the FCR and where I was seeing the receive side not being flushed, but I'm glad my warning was able to flag a bug. :-)
>>
>>If "void" is comfortable with kernel hacking, it would be great to confirm >that the warning is indeed coming from the transmit side not being flushed; a printf("drain = %d\n", drain); would be sufficient.
>>
>>And yes, only emitting this warning once per device (or once per boot?) would probably be good.
> 
> I got the same message on real hardware, no virtualization involved as
> either host or guest. Is that expected at all?
> 
> Relevant lines from /var/run/dmesg.boot:
> 
> ns8250: UART FCR is broken
> ns8250: UART FCR is broken
> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> uart0: console (115200,n,8,1)
> ns8250: UART FCR is broken
> ns8250: UART FCR is broken
> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
> ns8250: UART FCR is broken

On 3 × bare metal 14-CURRENT hosts at
017367c1146a69baca6a1a0bea10b0cb02c72d85:
$ dmesg -a | egrep '(ns8250|uart)'
ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
ns8250: UART FCR is broken

From nobody Thu Oct 27 15:16:59 2022
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 4Myq6F43FBz4gHct
	for ; Thu, 27 Oct 2022 15:17:09 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4Myq6D2vvpz3fDv
	for ; Thu, 27 Oct 2022 15:17:08 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 29RFGxvw027546;
	Thu, 27 Oct 2022 10:16:59 -0500 (CDT)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id lYihLuugWmOYawAA4+wvSQ
	(envelope-from ); Thu, 27 Oct 2022 10:16:59 -0500
From: Mike Karels 
To: "Chen, Alvin W" 
Cc: freebsd-current 
Subject: Re: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Date: Thu, 27 Oct 2022 10:16:59 -0500
X-Mailer: MailMate (1.14r5921)
Message-ID: 
In-Reply-To: 
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=UTF-8
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail.karels.net id 29RFGxvw027546
X-Rspamd-Queue-Id: 4Myq6D2vvpz3fDv
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	R_DKIM_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	FREEFALL_USER(0.00)[mike];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[karels.net];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 26 Oct 2022, at 22:29, Chen, Alvin W wrote:

> Any body know the status to support P Core and E Core?
> Now WA is: disable PCID.

Disabling vm.pmap.pcid_enabled is the best workaround for now.
There has been some progress in investigations in the background, but I
don=E2=80=99t think there is a permanent solution yet.

btw, I haven=E2=80=99t heard reports about Raptor Lake yet.  Do you know =
if it has
the same problems as Alder Lake on hybrids?  I would guess it does.

		Mike
>
> Regards,
> Alvin Chen
> Dell ThinOS | Dell - Comercial Client Group
> Teams/Zoom: weike_chen@dell.com
>
>
>
> Internal Use - Confidential

From nobody Fri Oct 28 18:36:02 2022
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 4MzWTW3vXtz4gnBx
	for ; Fri, 28 Oct 2022 18:36:15 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MzWTW3Nn1z4Dbt
	for ; Fri, 28 Oct 2022 18:36:15 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1666982175;
	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=xUYfe3lWBkjKFQKRJCAuN8sHzhVYcEcZYABVYZLIYbg=;
	b=LYm4rZCAC/fN2JJ0Z9LEoHWLLTIjJQV/XOYnOz+99EUv85GeFTC3xcMKRF8A+3GiDMLPlC
	CgKPah1SaDvOlyNyPu/9ovUsVUJIXF/oMCoCo7jni1GFVB63E0lOyjklfnW2HB3nsVPuRq
	rGeiDTi+jQ1Ixtbry+TMffa6GbcUP+ZTlzav8EUwoTWynbMohakqO3X51Uv+XYWupqcwS6
	/BeFxX1zuoV2GQ5brdFB9enVZHYJ1iFLYdOCIB1AR23vTmJlJHYjER0ebju9JmQX37zVAU
	AkJKLynKC4HZ728FpmAnLBwzXbigcM9ETPpsg6msU5N9DU0Ps9Cl0VB7qeIZcw==
Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4MzWTW2G7zz1L0D
	for ; Fri, 28 Oct 2022 18:36:15 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f49.google.com with SMTP id n63so5952144vsc.8
        for ; Fri, 28 Oct 2022 11:36:15 -0700 (PDT)
X-Gm-Message-State: ACrzQf05T6Vjrf4ODHWUq7Ruae2tLa5TJr/cK4WLuQynAqEslXOSlAek
	91DdlSvOUBx2FumoIC/7OzpBKHtbx7YlaMmHdWI=
X-Google-Smtp-Source: AMsMyM6ZbZ/u6vKqGRlnmYVs4dwWrel1nM2XMiBLW2//y8crYHtTL49YPY1Bae+8VZSVANmNXEa4qzanKGpS3xU95+E=
X-Received: by 2002:a67:e8d0:0:b0:3a9:765b:38fe with SMTP id
 y16-20020a67e8d0000000b003a9765b38femr321757vsn.51.1666982174483; Fri, 28 Oct
 2022 11:36:14 -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: Nuno Teixeira 
Date: Fri, 28 Oct 2022 19:36:02 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: morse(6) sound
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000005b692405ec1c8892"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1666982175;
	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=xUYfe3lWBkjKFQKRJCAuN8sHzhVYcEcZYABVYZLIYbg=;
	b=yiqCqB6xwcLZUwI0wENgfFozGta4JvAmUZyJBv4FUhgPgup3SSSS2dK72JOg0ISJB9OlbZ
	awaftgQ8mDqJf1NUjztehTNnK8x3alYhWfykcmIa7pRyk0erCTJnm+FkA6HGqsVPeNobeV
	4sSs4gcT9GRlMuRraxAOUQXFUr51nEukSdKN8oVKnHEKxa1LGqavL3QM6ycFZzZjDvcFEU
	bEncDnNC6g2TOeZZxpBRilvoOK/ARZi4BXgXdDa4ySyBQkD3HRbzVmZ+xn+f3OdfJ+WupY
	A1+jXfXi/t+y7IvjIkV1OJEssi/9dn/jgF0u4+U+CmDba+4/mB9YbxQA6HgIoQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666982175; a=rsa-sha256; cv=none;
	b=JRQsMqtop9k4yJdJFut1i+T1Fl9xGojeMJwqAkMgQ/C3U+97h0QzPkNBBdSCu/aV8rSfWX
	KIG29+Ou/Ctd8t8BWO6pRviGUzQnZ/K3GbOi/l98Mi+e8C7KAfv++Pu+hSlPNi7CYKF2cn
	PWU8oLrdvOalk2j+3umWxFHj+4IOo+LD6FsCaStw48mV9Zpww3Qjz1BJDXS60RvTNXc8M+
	1SyOLr7Hs5LxtGto+gCWsd7Nsf3Lmsnxrgq92ucyl3mRzp+NPIxulKFqoPJ5lm85nW/xyN
	arFYtFRHPBQDFJml8kd4cNkpn58iQs0TAMHk1HR15k9QjZR5eaZn9hGKyoZ9aA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000005b692405ec1c8892
Content-Type: text/plain; charset="UTF-8"

Hello all,

Is there any way to get sound from morse(6) without speaker(4) device?

Thanks,

-- 
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000005b692405ec1c8892
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello all,

Is there any way =
to get sound from morse(6) without speaker(4) device?

Thanks,

-- 
Nuno Teixeira
FreeBSD Committer (ports)


--0000000000005b692405ec1c8892--

From nobody Fri Oct 28 21:49:28 2022
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 4MzbmW6D6sz4g02c
	for ; Fri, 28 Oct 2022 21:49:31 +0000 (UTC)
	(envelope-from cperciva@freebsd.org)
Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204])
	by mx1.freebsd.org (Postfix) with SMTP id 4MzbmV3rrQz3L0T
	for ; Fri, 28 Oct 2022 21:49:30 +0000 (UTC)
	(envelope-from cperciva@freebsd.org)
Received: (qmail 16507 invoked from network); 28 Oct 2022 21:49:28 -0000
Received: from unknown (HELO dell7390.daemonology.net) (127.0.0.1)
  by mail.tarsnap.com with SMTP; 28 Oct 2022 21:49:28 -0000
Received: (qmail 35977 invoked from network); 28 Oct 2022 21:49:28 -0000
Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1)
  by localhost with SMTP; 28 Oct 2022 21:49:28 -0000
Message-ID: 
Date: Fri, 28 Oct 2022 14:49:28 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.0
Subject: Re: ns8250: UART FCR is broken
Content-Language: en-US
From: Colin Percival 
To: freebsd-current@freebsd.org
References: 
 
 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4MzbmV3rrQz3L0T
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 54.86.246.204 is neither permitted nor denied by domain of cperciva@freebsd.org) smtp.mailfrom=cperciva@freebsd.org
X-Spamd-Result: default: False [0.50 / 15.00];
	VIOLATED_DIRECT_SPF(3.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	RCVD_NO_TLS_LAST(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	RCVD_IN_DNSWL_NONE(0.00)[54.86.246.204:from];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:14618, ipnet:54.86.0.0/16, country:US];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[cperciva];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	TO_DN_NONE(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	TO_DOM_EQ_FROM_DOM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

>> On Mon, 24 Oct 2022 at 22:11, void  wrote:
>>> this started appearing in dmesg
>>>
>>> ns8250: UART FCR is broken
>>> ns8250: UART FCR is broken
For the list: While I was correct that bhyve didn't emulate FCR_XMT_RST,
this warning was actually caused by a bug in my earlier commit.  It should
be fixed now:

> commit 5ad8c32c722b58da4c153f241201af51b11f3152
> Author:     Colin Percival 
> AuthorDate: 2022-10-28 04:42:44 +0000
> Commit:     Colin Percival 
> CommitDate: 2022-10-28 19:20:28 +0000
> 
>     ns8250: Fix sense of LSR_TEMT FCR check
>     
>     When flushing the UART, we need to drain manually if LSR_TEMT is
>     *not* asserted, aka. if the transmit FIFO is not empty.
>     
>     Reported by:    void 
>     Fixes:          c4b68e7e53bb "ns8250: Check if flush via FCR succeeded"
>     Differential Revision:  https://reviews.freebsd.org/D37185

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid

From nobody Fri Oct 28 22:12:51 2022
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 4MzcHc1Qvqz4g36L
	for ; Fri, 28 Oct 2022 22:13:00 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "gate2.funkthat.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4MzcHZ490Zz3PbD;
	Fri, 28 Oct 2022 22:12:58 +0000 (UTC)
	(envelope-from jmg@gold.funkthat.com)
Received: from gold.funkthat.com (localhost [127.0.0.1])
	by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 29SMCpHw027244
	(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Fri, 28 Oct 2022 15:12:51 -0700 (PDT)
	(envelope-from jmg@gold.funkthat.com)
Received: (from jmg@localhost)
	by gold.funkthat.com (8.15.2/8.15.2/Submit) id 29SMCpw6027243;
	Fri, 28 Oct 2022 15:12:51 -0700 (PDT)
	(envelope-from jmg)
Date: Fri, 28 Oct 2022 15:12:51 -0700
From: John-Mark Gurney 
To: Nuno Teixeira 
Cc: FreeBSD CURRENT 
Subject: Re: morse(6) sound
Message-ID: <20221028221251.GB3414@funkthat.com>
Mail-Followup-To: Nuno Teixeira ,
	FreeBSD CURRENT 
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-Operating-System: FreeBSD 11.3-STABLE amd64
X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7  ED9B D5FF 5A51 C0AC 3D65
X-Files: The truth is out there
X-URL: https://www.funkthat.com/
X-Resume: https://www.funkthat.com/~jmg/resume.html
X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE
X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger?
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Fri, 28 Oct 2022 15:12:51 -0700 (PDT)
X-Rspamd-Queue-Id: 4MzcHZ490Zz3PbD
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 2001:470:800b::2) smtp.mailfrom=jmg@gold.funkthat.com
X-Spamd-Result: default: False [-1.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com];
	FREEFALL_USER(0.00)[jmg];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[funkthat.com];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Nuno Teixeira wrote this message on Fri, Oct 28, 2022 at 19:36 +0100:
> Is there any way to get sound from morse(6) without speaker(4) device?

I mean, I guess you could use sox (play command) and sed to make the audio..

morse -s converts it to . and -'s, so then you convert each one of those to
a frequency and necessary delay.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From nobody Sat Oct 29 13:36:44 2022
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 4N00nj0Z7Fz4h4m8
	for ; Sat, 29 Oct 2022 13:36:57 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N00nj04YKz3ZDr
	for ; Sat, 29 Oct 2022 13:36:57 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667050617;
	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=pSLfPz96iVpxnCothdUuLAr9RY+nLdOyKG7p+FV/iZU=;
	b=ACJCIGhzPEF6tUxlo4z8mo3zqSy44QB/XLj8gqPamxtOTG0KPxCE7uMoLoCrg4yPPwjrrz
	aHF4kNHWc7Ccf6A+Xl4AAhBs5gli1MDJ7IMlt/OP9T2zYIQZYOrVFMKKZhefDeLXobLnGb
	0Mj8ypwpDMsC5cmq9wYcfFkqnszeEJpTXsQZtsw7SINFJbvERAGTHvGJfSPi1z+/LLiwYt
	AKDyCx2plhtFzV82iWGSydInisOGg166Vl3MqJX1LFHJquNel4HzTHIpEBY4nlAPy68B5a
	8SKk/z0Yw/5/otTKn/lQteDz+O+ayatfvJVm1nHa0UHD17sqHNgI7+ksvUdVgQ==
Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N00nh6DcYzh1H
	for ; Sat, 29 Oct 2022 13:36:56 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f41.google.com with SMTP id q127so7460755vsa.7
        for ; Sat, 29 Oct 2022 06:36:56 -0700 (PDT)
X-Gm-Message-State: ACrzQf3+uVHmF07M42PcGruKywwb763dzFfQceEWBDT3rNR2l234qB+N
	H+/Z/33ebiLDKO7GOL2DyKYeiPgJaTFa4GFTzIU=
X-Google-Smtp-Source: AMsMyM6dfm7rcX7qUGrm0PlxL8nTEjFGdgh14H3edmIZ8EcEX3xkMkAadmHkhmhs6VAyZZpsaiIo4P3RBZgIfJONmKM=
X-Received: by 2002:a67:e8d0:0:b0:3a9:765b:38fe with SMTP id
 y16-20020a67e8d0000000b003a9765b38femr1385777vsn.51.1667050615798; Sat, 29
 Oct 2022 06:36:55 -0700 (PDT)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 
In-Reply-To: 
From: Nuno Teixeira 
Date: Sat, 29 Oct 2022 14:36:44 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: morse(6) sound
To: Diane Bruce 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000c7004c05ec2c7786"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667050617;
	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=pSLfPz96iVpxnCothdUuLAr9RY+nLdOyKG7p+FV/iZU=;
	b=ndOX/so6cmxuHpVOWs1Njwi5EH7HoYB2tAjjMY+8LNHiZCo4Fr0cDFOoGY0KUnZVKk7pdK
	IbY6lCu3+CjG7nmUtwc9HBK2X2n2+78IZy0mbhbQMq52wk/U3TifK3Fg2FmdxmZLYIgXCP
	dI9FU6Sx+6OMto/WCxeyWFv0+MN3kmNtnTsassAHJJPFheWopqF1ovvK/Db26+sg7q/9gh
	VG71OD+61qoZzbx3WYKX5p3paAQQdaAMgDzEi0xewppIVqjo/JyXhPq/eGAomhP44yT8/K
	6Hdf5TtfoekuNzmqCfez1Bq2g0Qqc4nFYF+88FXPzTa+I9z7/PwjpHb3+28Gbw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667050617; a=rsa-sha256; cv=none;
	b=MyRH1CpS9IE5XY1sKIri1jBiyBIGsE8zLnMZ3sco2fEyc/6gfvOb72WFBidWwZIoiHTzGr
	szXHHqKFT/tHsQbQmS5u0ZXsdm2j8si1Jn1izYoA+UAg4/sJcd2DJbvV9ntlffMI7aGPLt
	gr5COxAMX+18FM7JpKM1rQzIAI4DPlrL7zOwEg5t+P9IrTlyQf6s0sP2KEoxSKD9siSDvx
	UAgTQuGrX9YwlGgwBwJ/IriXxnp5ntM3qno2g7v39Rxzi9AmUVjOHrbl+8UXAKJUeiW4uF
	FsMZRCSAvVr2fRJeDiqHBJp4xh9mMTTlUeImtff9XKbxzXFzsG2R9PjiL4/XGg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000c7004c05ec2c7786
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

unixcw is what I was looking for.
I think I will include it in some scripts just for fun :)

I've started with base morse because it was nice if it can be updated to
play on dsp too.

And yes, `cw -w 60 < /etc/passwd` it's really cool.

Thanks!



Diane Bruce  escreveu no dia s=C3=A1bado, 29/10/2022 =C3=A0(s) 1=
4:01:

> On Fri, Oct 28, 2022 at 07:36:02PM +0100, Nuno Teixeira wrote:
> > Hello all,
> >
> > Is there any way to get sound from morse(6) without speaker(4) device?
>
> Any reason you can't just use unixcw from ports ?
> Or would ebook2cw be better for your needs?
>
> P.S.
> cw -w 60 < /etc/passwd  is a trip
>
>
> >
> > Thanks,
> >
> > --
> > Nuno Teixeira
> > FreeBSD Committer (ports)
>
> --
> db@FreeBSD.org db@db.net http://www.db.net/~db
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000c7004c05ec2c7786
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

unixcw is what I was =
looking for.
I think I will include it in some scripts just for f=
un :)

I've started with base morse because it =
was nice if it can be updated to play on dsp too.

=
And yes, `cw -w 60 < /etc/passwd` it's really cool.
Thanks!



Diane Bruce <db@db.net> escreveu no dia s=C3=A1bado, 29/=
10/2022 =C3=A0(s) 14:01:
On Fri, Oct 28, 2022 at 07:36:02PM +0100, Nuno Teixeira wrote:
> Hello all,

> 

> Is there any way to get sound from morse(6) without speaker(4) device?=




Any reason you can't just use unixcw from ports ?

Or would ebook2cw be better for your needs?



P.S.

cw -w 60 < /etc/passwd=C2=A0 is a trip





> 

> Thanks,

> 

> -- 

> Nuno Teixeira

> FreeBSD Committer (ports)



-- 

db@FreeBSD.org db@db.net=
 htt=
p://www.db.net/~db




-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--000000000000c7004c05ec2c7786--

From nobody Sat Oct 29 14:23:40 2022
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 4N01qh5vmQz4fxgy
	for ; Sat, 29 Oct 2022 14:23:44 +0000 (UTC)
	(envelope-from matteo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N01qh5StDz3gQC
	for ; Sat, 29 Oct 2022 14:23:44 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667053424;
	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=uvPW6stOBC+fSAETOHz1XBZrbv90Q+meLe9br3flYQI=;
	b=PA2d0InqiYxcFKfdUQmCGxUT0HQoujY8lMMXhjyS9mnleCTkQkiaJz28sW8HagSi0RaNnx
	FcjO4sBf3jztaNDHVQAYiVaMzUXT5UlM+miTa0/TGUMO81IcHxO2XRpEDPszF/pQIDILuF
	abG73Uu0ZTIrphmMQrpgrxloWPIg6SWfzfvw0amAX04t7OEEwyAI8TXqtI4NDaTIMcoxoN
	Awi/JZzWiSle3Ks6Vx7ARS1KopHUfepCaKtSX/78GPqnqFttikrg2lyDrSV9a2QtGmwDeH
	/JcnikDycV/tEfWkSznISBzGapoDfARck8TaIaBiWL6pGGWAM3EIN6OxaZ8W9Q==
Received: from host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu (unknown [IPv6:2601:19b:4400:1779::1030])
	(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: matteo/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N01qh3z7NzhMS
	for ; Sat, 29 Oct 2022 14:23:44 +0000 (UTC)
	(envelope-from matteo@freebsd.org)
Date: Sat, 29 Oct 2022 10:23:40 -0400
From: Matteo Riondato 
To: freebsd-current@freebsd.org
Subject: Re: ns8250: UART FCR is broken
Message-ID: <20221029142340.z5v3tavbpl6thmpl@host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu>
X-PGP-Key: http://rionda.to/files/matteogpg.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-sha512;
	protocol="application/pgp-signature"; boundary="4mralf4sddikkwnq"
Content-Disposition: inline
In-Reply-To: 
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667053424;
	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=uvPW6stOBC+fSAETOHz1XBZrbv90Q+meLe9br3flYQI=;
	b=kYDc0fD3XSBo96iKe/sjnPI12Q4dmp1Tff7wDYg9TirtFJoUJmV1/nwAn7EDvvxnQ83ZBP
	QreN5L0fKgDotTZetNc0KmYCHOhGYdjAJuFCvzjI2ePnbPSQsVgC44mFoyOODrW1/2EUWH
	c/iC0n4j6sEXb8yvbgpKi+KbbtZXn7fWYdRXzbtWqyC36PZlMRQ5dWT+k7dF8NvFjtSE7A
	scOoGes6WBYAbrxusD9uickyNEm9z3c1+RWBuo5oYCDN5IRchtBfAYgKZBdZXSwGUrDK6A
	4OA+9147lb/l76IlC2/8K66LsFbfl25tOUM9Da5f0ewcdgdbj8If6M4ywtwFkg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667053424; a=rsa-sha256; cv=none;
	b=pzraLCqvMqBVmLMA43hUyYdDri2jl1bQb3ISzgStQCjlzHwTaR2IDafZibicIeAxRNoxeR
	6xjBnSatJ8/vjQ6qE/v3S+7Tm7EfhNzzMNuFf1X73vW+Ro8FF50ddeYC1PUOspcfZn/pZW
	AXKo843uAVsa3zyXIQx8sRyUjAa4Fb7mhObS5S/wInN01GoOSdop3l0x+LUsQsZVcADa7S
	NobYt/V8dxnk7Fzx+S958DisXevNM9N7Jva0PCH5iezZ/I0sdU1j26QJcwKBNmbVFyFiWj
	bMBwwVuEVI5P22GqO0HYttdGGX9Nwr5Obzrk4G4Y+gwwPB28yVtMKxKLWFxWAw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--4mralf4sddikkwnq
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-10-28 at 17:49 EDT, Colin Percival  wrote:

>>>On Mon, 24 Oct 2022 at 22:11, void  wrote:=20
>>>>this started appearing in dmesg
>>>>
>>>>ns8250: UART FCR is broken
>>>>ns8250: UART FCR is broken
>For the list: While I was correct that bhyve didn't emulate FCR_XMT_RST,=
=20
>this warning was actually caused by a bug in my earlier commit.  It should=
=20
>be fixed now:

I still see it on bare metal.

Thanks,
Matteo

--4mralf4sddikkwnq
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmNdN18TGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVAQSJEACQdFFwtYNA6Bmgo/sMUr9j0qVzXShI
w9mn4O7xWaugTZ9shwI/VE4SwTLdNQA5LymQl52faRm7QZYXi/0mHO3FrZiaSRqC
1wRebikUe6HQsYV78ukgzN/hgnLCv88gniUvKIwxtIXuAYkedPDhHaozEEo+8aBl
SmcteI/zIVuB5yHmsSydJ86wnszuEmPmXGfswkUpr5yGEUGj0NNZzlF2wmdvIQV7
AssgVs7t8KdeaaSTxDM41AtfJMAH349g0/hB7mLDDHs2K+8pb9bWI5wHmXLzUJmp
molq6ElotRZcFS76wJj37dLviMDeByktu2K+DiJYbsE8i+JPHRjski9BOIq3IH1x
XHam/dpZvRJ2ugQmKYgxaLVWYtvaQzHiAPxiype6TVDXdKGJaFx2hakv+3adNuEU
1c+/BVlMx+gYMvldk23TsGrwNInwm3bl8WFYd55muvU55dMlHcNAksixyDYw0yHN
JofRiUykWt/fqmKumALRlZ8J0yi/i3tfFKpUao+dPCd4KL1pq/c9napaDjqR+5OD
PkCs/fQirlUIiBxtK9+/zxy9+687RCIt9/vfkM5oIk0dkOP1NUX8bn/LaLfAHMQI
rDCd56dsIa12nkTLeV2xHr7iz0zipgFeoOkgEu/T4pRDFyaBv4we3cn5tYlpKvBw
rqCVFSmUFB0BrA==
=CXSO
-----END PGP SIGNATURE-----

--4mralf4sddikkwnq--

From nobody Sat Oct 29 15:33:07 2022
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 4N03N04M34z4g6vR
	for ; Sat, 29 Oct 2022 15:33:20 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4N03Mz4n41z3pDC;
	Sat, 29 Oct 2022 15:33:19 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.68] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id C672326035D;
	Sat, 29 Oct 2022 17:33:11 +0200 (CEST)
Message-ID: <106b05da-be44-ef6f-e2c8-0888ee71ed88@selasky.org>
Date: Sat, 29 Oct 2022 17:33:07 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: morse(6) sound
Content-Language: en-US
To: Nuno Teixeira , Diane Bruce 
Cc: FreeBSD CURRENT 
References: 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4N03Mz4n41z3pDC
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.27 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.99)[-0.994];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	TO_DN_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 10/29/22 15:36, Nuno Teixeira wrote:
> Hello,
> 
> unixcw is what I was looking for.
> I think I will include it in some scripts just for fun :)
> 
> I've started with base morse because it was nice if it can be updated to
> play on dsp too.
> 
> And yes, `cw -w 60 < /etc/passwd` it's really cool.
> 

You may want to look at beep(1). Maybe the two could be integrated.

--HPS


From nobody Sat Oct 29 15:44:46 2022
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 4N03dQ55Dbz4g7rg
	for ; Sat, 29 Oct 2022 15:44:58 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N03dQ4CY2z3rlH
	for ; Sat, 29 Oct 2022 15:44:58 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667058298;
	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=z68FJtCCw8OQPbNK5UvE6LOvrWHAC9BBQc0insgB6Lk=;
	b=pRlmfuyHQziIbimlrcQ8gjqN4GRLmmnJRr5UHSqXsmlxyVkFpLLCtf90uwfEXJUS+G2iyX
	ZC35tWR+Dam8MRRskPvmd89vLUE/Yq5X9bmBN9PArxlip80R5kJHO1Pl7WlQQoJ80FJvkc
	C70Ys9pbYxpvpr/EBrbitZa/rWnwvBV2+XXeCutTpRlrYIDD2KB4J/Yqzkss7FaJ1CVqAG
	DtZsRjhCCflXAAYtvd93G5molub8qyeh9rAUGaMHbFEWEY8/px1QsJ7geM3jW4t9H8YJEb
	C9hAPwpWHA60Yx8xNI5sGGDr8A3t8ViKuqdt3ps8Hj4gBrDlkzhB9TNALquaOA==
Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N03dQ3CQgzjtZ
	for ; Sat, 29 Oct 2022 15:44:58 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f45.google.com with SMTP id 3so7663270vsh.5
        for ; Sat, 29 Oct 2022 08:44:58 -0700 (PDT)
X-Gm-Message-State: ACrzQf3KaTVwcqZ80/V3rPYD/TZmapDzRyVhfvMdtmJYSpNNaPyDkMY+
	G/CU7yujKLMjpkSKYaLzrL9rO98YXDWxOYKsi6Q=
X-Google-Smtp-Source: AMsMyM6wOqRponDh9uHcUIHBQfmfECEvV0BvEl3AFRWu5e5p7MvZ4SHgeszOPbzpIo3xYQs9sG3z61ThJP2EyrnBZOM=
X-Received: by 2002:a67:d799:0:b0:3ac:390e:c6bd with SMTP id
 q25-20020a67d799000000b003ac390ec6bdmr1606781vsj.19.1667058297820; Sat, 29
 Oct 2022 08:44:57 -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: 
  
 <106b05da-be44-ef6f-e2c8-0888ee71ed88@selasky.org>
In-Reply-To: <106b05da-be44-ef6f-e2c8-0888ee71ed88@selasky.org>
From: Nuno Teixeira 
Date: Sat, 29 Oct 2022 16:44:46 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: morse(6) sound
To: Hans Petter Selasky 
Cc: Diane Bruce , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000a95ca805ec2e412b"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667058298;
	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=z68FJtCCw8OQPbNK5UvE6LOvrWHAC9BBQc0insgB6Lk=;
	b=XAJBvj0Sm1wcn0S5l5u3MNTf9LKk+i4OX7/1X0Kn91nizRkANSFw2FjYYcopSCQx2dYNxT
	lwHgaZYb4jRt1iwL+FRyt2GZeB6AV3SY4z8ZHJidxCzTb8+EZdkLqR95hHCghgxwVMmCLl
	ZOEYVrE+HCgkB9n2GKUVM7+JN23ROrqA/bfgJ+Md21oFTxOiJwfWtxqHgad/SKw+4MHljo
	iYU9UDb2pZUu34htRg5uis/PDnNXrBl6C0bNF4w9gctnoC8opsEs/udZ3YmFp3KcIdLRh2
	lzq9ASo+lR81XN211EpfCRKJ7KKX60dfyeWL4R3RssrlrLmAdun4Y0ZADZ0y3g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667058298; a=rsa-sha256; cv=none;
	b=mKCnq5x+7tskRVflhptTYT+t31CgiZPH7vSKNt2Ee8C7Dm1NW5VVZKPiWxB6HniRKsM2oG
	TZ9gjJ44CxsPDw6sCkB7NRrb9QRfNSQEULKjsDim63c6TOjwmJ3WBTd5aDHYbJ5wo9FwV5
	DFZPpDesR7gZKqolRLqfVgnhA7lGzpPiG6r/lLQIbZFXIegG4oAg3y9W0V6D0eX/cU0u2P
	YWBhkcBnGeFBnAa+JwrHjNSuYfaCtjGs2Ovs9ppHOGavHtBHrUAohumYtxFLCgfjqp3oYx
	gYhPsIB16N+rRUjlDoJJ+GPgiiRHZGzej1NshisuhAhl+XCVoCk6BORP2uVC0Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000a95ca805ec2e412b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Hans,

A few days ago I tried beep and it remembered me about morse sound only
available to speaker and not to dsp.

So, are you saying that morse could be changed to have dsp sound like beep?

Thanks,




Hans Petter Selasky  escreveu no dia s=C3=A1bado, 29/10/20=
22
=C3=A0(s) 16:33:

> On 10/29/22 15:36, Nuno Teixeira wrote:
> > Hello,
> >
> > unixcw is what I was looking for.
> > I think I will include it in some scripts just for fun :)
> >
> > I've started with base morse because it was nice if it can be updated t=
o
> > play on dsp too.
> >
> > And yes, `cw -w 60 < /etc/passwd` it's really cool.
> >
>
> You may want to look at beep(1). Maybe the two could be integrated.
>
> --HPS
>
>

--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000a95ca805ec2e412b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Hans,

A few days ago I=
 tried beep and it remembered me about morse sound only available to speake=
r and not to dsp.

So, are you saying that morse co=
uld be changed to have dsp sound like beep?

Thanks=
,




Hans Petter Selasky=
 <hps@selasky.org> escreveu no=
 dia s=C3=A1bado, 29/10/2022 =C3=A0(s) 16:33:
On 10/29/22 15:36, Nuno Teixeira wrote:

> Hello,

> 

> unixcw is what I was looking for.

> I think I will include it in some scripts just for fun :)

> 

> I've started with base morse because it was nice if it can be upda=
ted to

> play on dsp too.

> 

> And yes, `cw -w 60 < /etc/passwd` it's really cool.

> 



You may want to look at beep(1). Maybe the two could be integrated.



--HPS






-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--000000000000a95ca805ec2e412b--

From nobody Sat Oct 29 18:11:36 2022
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 4N06tv4SlWz4gTJD
	for ; Sat, 29 Oct 2022 18:11:51 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N06tt3MRPz3D5Q;
	Sat, 29 Oct 2022 18:11:50 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.68] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 8BFC32600D1;
	Sat, 29 Oct 2022 20:11:41 +0200 (CEST)
Message-ID: <10ff4875-c6bd-88a0-bf0d-7ae52106131e@selasky.org>
Date: Sat, 29 Oct 2022 20:11:36 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: morse(6) sound
To: Nuno Teixeira 
Cc: Diane Bruce , FreeBSD CURRENT 
References: 
 
 
 <106b05da-be44-ef6f-e2c8-0888ee71ed88@selasky.org>
 
Content-Language: en-US
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4N06tt3MRPz3D5Q
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.04 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.74)[-0.745];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	TO_DN_ALL(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 10/29/22 17:44, Nuno Teixeira wrote:
> Hello Hans,
> 
> A few days ago I tried beep and it remembered me about morse sound only
> available to speaker and not to dsp.
> 
> So, are you saying that morse could be changed to have dsp sound like beep?
> 
> Thanks,
> 

Technically you could symlink the two - yes.

--HPS

> 
> 
> 
> Hans Petter Selasky  escreveu no dia sábado, 29/10/2022
> à(s) 16:33:
> 
>> On 10/29/22 15:36, Nuno Teixeira wrote:
>>> Hello,
>>>
>>> unixcw is what I was looking for.
>>> I think I will include it in some scripts just for fun :)
>>>
>>> I've started with base morse because it was nice if it can be updated to
>>> play on dsp too.
>>>
>>> And yes, `cw -w 60 < /etc/passwd` it's really cool.
>>>
>>
>> You may want to look at beep(1). Maybe the two could be integrated.
>>
>> --HPS
>>
>>
> 


From nobody Sat Oct 29 18:18:13 2022
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 4N072T3Dxyz4gV57
	for ; Sat, 29 Oct 2022 18:18:25 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N072T2fVFz3DyS
	for ; Sat, 29 Oct 2022 18:18:25 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667067505;
	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=0VV2mOSjyVIb91HjImbuhLht/FtoSs9f1uxIgvRrASQ=;
	b=XpwAqvf9FFxgZsN5q7rd3HDW8c0t278gdAR8PWls52y+dZdrZO/W6zQODK695LqXwXn9yy
	/7bDlcDjVgbmvmZDb4cD2ceJ8qnnKnLqw5CYcMeR/XvJXldapdeR6WyyalA6+V4ZzpMyg3
	217Dxq3/ylB4Lf8w5ndu1zwcA9RfUBTvBgaqTQKrmBG6jl36ZlJo55InbRE8K8dTojQsxP
	SYYcz91jm1kg+NEGcgFUJHSstvqcsnJpl5HOkYsD1T03Qera7Z7zT6VOAjuoq1TlLqCe9x
	iWdFf6uFzhhjTLpHRvVArS5TBmFbLqsAJZxgg82TShQYeXewQhfz4q86bulJ8w==
Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N072T1ZbVzld5
	for ; Sat, 29 Oct 2022 18:18:25 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vs1-f52.google.com with SMTP id o5so7890662vsc.0
        for ; Sat, 29 Oct 2022 11:18:25 -0700 (PDT)
X-Gm-Message-State: ACrzQf1p05lYrwU2srIrWtQ+J12BxtPSMFYxKer/JY7YfIDUfyFTk/Rg
	MjCE7E4ijBRbDm+7XvPz+ZN/9z6lq1zu3uGK00o=
X-Google-Smtp-Source: AMsMyM64nh9r1jjHZxOwBEr8zIClmrgtqa7iFJEM0Uw1PfB1lgXveUwP9KJRfurLYrPyEcxImWBq7Gmt7wMMVmPwhvk=
X-Received: by 2002:a67:d799:0:b0:3ac:390e:c6bd with SMTP id
 q25-20020a67d799000000b003ac390ec6bdmr1776371vsj.19.1667067504694; Sat, 29
 Oct 2022 11:18:24 -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: 
  
 <106b05da-be44-ef6f-e2c8-0888ee71ed88@selasky.org> 
 <10ff4875-c6bd-88a0-bf0d-7ae52106131e@selasky.org>
In-Reply-To: <10ff4875-c6bd-88a0-bf0d-7ae52106131e@selasky.org>
From: Nuno Teixeira 
Date: Sat, 29 Oct 2022 19:18:13 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: morse(6) sound
To: Hans Petter Selasky 
Cc: Diane Bruce , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000006f1bf105ec30660e"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667067505;
	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=0VV2mOSjyVIb91HjImbuhLht/FtoSs9f1uxIgvRrASQ=;
	b=iBW2N1bI2fOLOQHJcuIZYBBdrl/iAI0VW/S17bhycEjkeDLMOCm2y6h53qMdCeIvvxuqjJ
	Ue3CdQOpngWA6XV57DIFBC7/ptbt/Qo3grStxMUftcBDLaZ7IP9rPhxjNV8DVSJUu/Zo2A
	o2hhk0XKXwYNpY+epMNwfbJhkpkaXS0QP3JT/YUmSBrH+GXN6Cs6sfccX9yz2TFpJ/8Czo
	3S1ponHl9pxT1g3BfrKVqP/v/jxlsL5Lh6Qz2paTmBu2sdMB5hOwwchosxZue5I4FDeGxe
	FPlaUkwTxHX9bqSVhjwmJX6zp7H3QGoW7WP2/ZgNOX2iTPv6ngrOaPAoFZ86Sw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667067505; a=rsa-sha256; cv=none;
	b=wKK5fh3M7jb3QoiVcL37xtJYc1epEpbK0DXNR2EaF0BiAt08OxTvzSCrx9WSYVOYtmWEVg
	ANgrWsZB2wPc8QRldSS5+V2ch57UTN12o3H4He3GpTdHam/GUkACL4u9aShRdHhUzFUCLH
	WRtHmxR6ulSwTfZyDiMGohdSXxI/mlfnIKTe81a4nIEUoJoJYwr30q9G/nBFcY6uHVlTR5
	LvpKk6i58ywRmPlwJrKdI7TNmltSjXn1Dwc6y81/kXDtgxBdzi00VlhFLMtDEzDusbX0ld
	TrUF1jVzBebfFKIdPcDmWMhfxzRKOKF0/thIo+TZj/FxWWiz3+UkD7oGKzupNQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--0000000000006f1bf105ec30660e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Technically you could symlink the two - yes.

Can't understand how, what do I missing?

Hans Petter Selasky  escreveu no dia s=C3=A1bado, 29/10/20=
22
=C3=A0(s) 19:11:

> On 10/29/22 17:44, Nuno Teixeira wrote:
> > Hello Hans,
> >
> > A few days ago I tried beep and it remembered me about morse sound only
> > available to speaker and not to dsp.
> >
> > So, are you saying that morse could be changed to have dsp sound like
> beep?
> >
> > Thanks,
> >
>
> Technically you could symlink the two - yes.
>
> --HPS
>
> >
> >
> >
> > Hans Petter Selasky  escreveu no dia s=C3=A1bado, 29/1=
0/2022
> > =C3=A0(s) 16:33:
> >
> >> On 10/29/22 15:36, Nuno Teixeira wrote:
> >>> Hello,
> >>>
> >>> unixcw is what I was looking for.
> >>> I think I will include it in some scripts just for fun :)
> >>>
> >>> I've started with base morse because it was nice if it can be updated
> to
> >>> play on dsp too.
> >>>
> >>> And yes, `cw -w 60 < /etc/passwd` it's really cool.
> >>>
> >>
> >> You may want to look at beep(1). Maybe the two could be integrated.
> >>
> >> --HPS
> >>
> >>
> >
>
>

--=20
Nuno Teixeira
FreeBSD Committer (ports)

--0000000000006f1bf105ec30660e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


> Technically you could symlink the two - yes.

Can't understand how, what do I missing?



Hans Petter Selasky <hps=
@selasky.org> escreveu no dia s=C3=A1bado, 29/10/2022 =C3=A0(s) 19:1=
1:
On 10/29/22 1=
7:44, Nuno Teixeira wrote:

> Hello Hans,

> 

> A few days ago I tried beep and it remembered me about morse sound onl=
y

> available to speaker and not to dsp.

> 

> So, are you saying that morse could be changed to have dsp sound like =
beep?

> 

> Thanks,

> 



Technically you could symlink the two - yes.



--HPS



> 

> 

> 

> Hans Petter Selasky <hps@selasky.org> escreveu no dia s=C3=A1bado, 29/10/2022

> =C3=A0(s) 16:33:

> 

>> On 10/29/22 15:36, Nuno Teixeira wrote:

>>> Hello,

>>>

>>> unixcw is what I was looking for.

>>> I think I will include it in some scripts just for fun :)

>>>

>>> I've started with base morse because it was nice if it can=
 be updated to

>>> play on dsp too.

>>>

>>> And yes, `cw -w 60 < /etc/passwd` it's really cool.

>>>

>>

>> You may want to look at beep(1). Maybe the two could be integrated=
.

>>

>> --HPS

>>

>>

> 






-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--0000000000006f1bf105ec30660e--

From nobody Sat Oct 29 18:22:14 2022
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 4N07715z5Dz4gVZJ
	for ; Sat, 29 Oct 2022 18:22:21 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N07710t5Xz3Gc6;
	Sat, 29 Oct 2022 18:22:21 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.68] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 658692600D1;
	Sat, 29 Oct 2022 20:22:19 +0200 (CEST)
Message-ID: 
Date: Sat, 29 Oct 2022 20:22:14 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: morse(6) sound
Content-Language: en-US
To: Nuno Teixeira 
Cc: Diane Bruce , FreeBSD CURRENT 
References: 
 
 
 <106b05da-be44-ef6f-e2c8-0888ee71ed88@selasky.org>
 
 <10ff4875-c6bd-88a0-bf0d-7ae52106131e@selasky.org>
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4N07710t5Xz3Gc6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.27 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.974];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	TO_DN_ALL(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 10/29/22 20:18, Nuno Teixeira wrote:
>> Technically you could symlink the two - yes.
> 
> Can't understand how, what do I missing?
> 

In the main() routine, the name of the program name is passed.

Then you just check if argv[0] == "morse" and invoke main_morse() 
instead, if you see. Of course you need to write main_morse() first, but 
you can re-use all the dsp code in there.

--HPS



From nobody Sat Oct 29 20:30:23 2022
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 4N09ym6pnKz4gnGw
	for ; Sat, 29 Oct 2022 20:30:24 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N09ym6XsZz3VJ8
	for ; Sat, 29 Oct 2022 20:30:24 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667075424;
	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=TxpJUJFERTdTMv1f0AsWmP+f4pgNhorPS9XwQ/kssWo=;
	b=McMLk04TOuIQ4fPMCQM5TahGpzxQizsZvqyTM1jRdea1qhD5yeggGYax0VRrWSbkPEDmoV
	qxXU1XFZrLFkV3WdU6IRTWR9gEpGJeqNcmUKXRpe5CIKaAQo+HJtI+mZvG0MKLQ8Cb6I7A
	i2swUPGpSwhWCtXA23kqjTj4lEbbGKIsuBb8z2cDZw+abGcyCTWuj711eshb6WtxuBpDS5
	QiSLv0qEuoXShnJXSeKvkZBT/El3gP+AZmXe2Sb/BL4K2/TGUpT8ocW3a7tTVqz81pYaS3
	EO8hUxckzB2hTaGbMLgktU15YhaLeG6XqNxusPTKC3RelYAHjEXSTLDkLAVO6Q==
Received: from [192.168.1.7] (79-66-138-149.dynamic.dsl.as9105.com [79.66.138.149])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N09ym3jx3zpB4
	for ; Sat, 29 Oct 2022 20:30:24 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: <3e925370-3f09-101d-e4f3-5fa2c7f28c83@freebsd.org>
Date: Sat, 29 Oct 2022 21:30:23 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
To: FreeBSD CURRENT 
Content-Language: en-GB
From: Graham Perrin 
Subject: poudriere jail update from source: syscall.mk does not exist
Organization: FreeBSD
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------lAaAKvhyjnKxZOWfz0xiOIsi"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667075424;
	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=TxpJUJFERTdTMv1f0AsWmP+f4pgNhorPS9XwQ/kssWo=;
	b=vJYh2rLqTsojtI+5fFKj61L7/gGUHdICmV2cKcBIU6QZGAoNMyIpv11iPWSC6JNMqPFiDO
	ov5sb23EUt7YZg90DLwkzMZU3d0fxVhZPE7b23ZdRc0XJM8kA9pOPXDZM8lnWtTWS6M/l8
	7Xoo5aJRFGjO6GkDQ31Wbgaa5GvANFWOYDy6JlVsWLRiyhi8EKd8jAXsPkA0ALoa1KWIFo
	Q6m8O/I0g0uGKCMOMKxzCL21HqkScUrwTRIHxsyzXXefTKwCv0v7IujjjCeGtJZFx3gq3I
	KvkxtoXUVknIoXxfGDxCwDcdUGCClKF9a1O/fENf3HzuGP9Jem518C5orvRExw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667075424; a=rsa-sha256; cv=none;
	b=ffearVG1dsdqlGYksc6SCi/CvfBd9EXKcIqdAPTaHLm5JAIGmvHQTu+s8WdsdBW5nL9un+
	NY33gS8pmj/I1B//QtolSsGd1GLdD01vmbeYWms/xitVVY4mJ4PV9eZ/TzEf92LUImHtRb
	cHlrqOf423A/2QsmymvG132keGHIeQfjjr3Og3NOeUhAQoTR1sNTVTU06o+hpOIN0bBH09
	NekVqFvWKhj+rWvPpn+PHFAlJKPtzSUWvKNUgJ1D/Zt8ZfI4yTEApgfklzLg2qXGqnbc50
	ccDi70/mFS/I2NpnmbZ8kdfg9BR5llhiC6UNIEFqNv/kGVTchVzArvfXdt/77w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------lAaAKvhyjnKxZOWfz0xiOIsi
Content-Type: multipart/mixed; boundary="------------F0xJz2zFb5a37vGrj5ltaUJp";
 protected-headers="v1"
From: Graham Perrin 
To: FreeBSD CURRENT 
Message-ID: <3e925370-3f09-101d-e4f3-5fa2c7f28c83@freebsd.org>
Subject: poudriere jail update from source: syscall.mk does not exist

--------------F0xJz2zFb5a37vGrj5ltaUJp
Content-Type: multipart/mixed; boundary="------------pmpocLHcMd1dz3Co5gbA3k5W"

--------------pmpocLHcMd1dz3Co5gbA3k5W
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

QWZ0ZXIgdXBkYXRpbmcgdG8geWVzdGVyZGF5J3MgYWJhOTIxYmQ5ZTE4NjlkYWU5YWU0Y2M2
ZTBjMDQ4Zjk5NzQwMTAzNCwgDQpJIGFpbWVkIGZvciBhIHJvdXRpbmUgdXBkYXRlIG9mIHRo
ZSBqYWlsIHRoYXQgSSB1c2VkIGZvciBwb3VkcmllcmUuDQoNCg0KcG91ZHJpZXJlIGphaWwg
LXUgLUogMSAtaiBtYWluDQrigKYNCj09PT4gbGliL2xpYmMgKGluc3RhbGwpDQptYWtlWzVd
OiAiL3Vzci9zcmMvbGliL2xpYmMvc3lzL01ha2VmaWxlLmluYyIgbGluZSA5OiBDYW5ub3Qg
b3BlbiANCi91c3Ivc3JjL3N5cy9zeXMvc3lzY2FsbC5taw0KbWFrZVs1XTogRmF0YWwgZXJy
b3JzIGVuY291bnRlcmVkIC0tIGNhbm5vdCBjb250aW51ZQ0KbWFrZVs1XTogc3RvcHBlZCBp
biAvdXNyL3NyYy9saWIvbGliYw0KKioqIEVycm9yIGNvZGUgMQ0K4oCmDQoNCg0KSG93IHRv
IHByb2NlZWQ/DQoNClRoYW5rcw0K
--------------pmpocLHcMd1dz3Co5gbA3k5W
Content-Type: text/plain; charset=UTF-8; name="poudriere jail -u -J 1 -j
 main.txt"
Content-Disposition: attachment; filename="poudriere jail -u -J 1 -j main.txt"
Content-Transfer-Encoding: base64

cm9vdEBtb3dhMjE5LWdqcDQtODU3MHAtZnJlZWJzZDp+ICMgcG91ZHJpZXJlIGphaWwgLXUg
LUogMSAtaiBtYWluClswMDowMDowMF0gVXBncmFkaW5nIHVzaW5nIHNyYz0vdXNyL3NyYwpb
MDA6MDA6MDBdIENvcHlpbmcgL3Vzci9zcmMgdG8gL3Vzci9sb2NhbC9wb3VkcmllcmUvamFp
bHMvbWFpbi91c3Ivc3JjLi4uIGRvbmUKYXdrOiBjYW4ndCBvcGVuIGZpbGUgL3Vzci9zcmMv
c3lzL3N5cy9wYXJhbS5oCiBzb3VyY2UgbGluZSBudW1iZXIgMQpbOiAtbHQ6IHVuZXhwZWN0
ZWQgb3BlcmF0b3IKWzogLWd0OiB1bmV4cGVjdGVkIG9wZXJhdG9yCls6IC1ndDogdW5leHBl
Y3RlZCBvcGVyYXRvcgpbMDA6MDA6MDJdIFN0YXJ0aW5nIG1ha2UgaW5zdGFsbHdvcmxkCnNo
OiBjYW5ub3Qgb3BlbiAvdXNyL3NyYy9zeXMvY29uZi9uZXd2ZXJzLnNoOiBObyBzdWNoIGZp
bGUgb3IgZGlyZWN0b3J5CmZpbmQ6IC91c3Ivc3JjL3N5cy9zeXMvcGFyYW0uaDogTm8gc3Vj
aCBmaWxlIG9yIGRpcmVjdG9yeQptYWtlWzFdOiAiL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5h
bWQ2NC90b29sY2hhaW4tbWV0YWRhdGEubWsiIGxpbmUgMTogVXNpbmcgY2FjaGVkIHRvb2xj
aGFpbiBtZXRhZGF0YSBmcm9tIGJ1aWxkIGF0IG1vd2EyMTktZ2pwNC04NTcwcC1mcmVlYnNk
IG9uIFNhdCAyOSBPY3QgMjAyMiAwMToyNjozOCBCU1QKYXdrOiBjYW4ndCBvcGVuIGZpbGUg
L3Vzci9zcmMvc3lzL2NvbmYvbmV3dmVycy5zaAogc291cmNlIGxpbmUgbnVtYmVyIDEKYXdr
OiBjYW4ndCBvcGVuIGZpbGUgL3Vzci9zcmMvc3lzL2NvbmYvbmV3dmVycy5zaAogc291cmNl
IGxpbmUgbnVtYmVyIDEKYXdrOiBjYW4ndCBvcGVuIGZpbGUgL3Vzci9zcmMvc3lzL2NvbmYv
bmV3dmVycy5zaAogc291cmNlIGxpbmUgbnVtYmVyIDEKYXdrOiBjYW4ndCBvcGVuIGZpbGUg
L3Vzci9zcmMvc3lzL3N5cy9wYXJhbS5oCiBzb3VyY2UgbGluZSBudW1iZXIgMQptYWtlWzFd
OiAiL3Vzci9zcmMvTWFrZWZpbGUuaW5jMSIgbGluZSA1MzE6IHdhcm5pbmc6ICJhd2sgJy9e
I2RlZmluZVtbOnNwYWNlOl1dKl9fRnJlZUJTRF92ZXJzaW9uLyB7IHByaW50ICQzIH0nICAv
dXNyL3NyYy9zeXMvc3lzL3BhcmFtLmgiIHJldHVybmVkIG5vbi16ZXJvIHN0YXR1cwotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQo+Pj4gSW5zdGFsbCBjaGVjayB3b3JsZAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpta2RpciAtcCAvdG1wL2lu
c3RhbGwucUV6RERhT2JJaQpwcm9ncz0kKGZvciBwcm9nIGluIFsgYXdrIGNhcF9ta2RiIGNh
dCBjaGZsYWdzIGNobW9kIGNob3duIGNtcCBjcCAgZGF0ZSBlY2hvIGVncmVwIGZpbmQgZ3Jl
cCBpZCBpbnN0YWxsICAgbG4gbWFrZSBta2RpciBtdHJlZSBtdiBwd2RfbWtkYiAgcm0gc2Vk
IHNlcnZpY2VzX21rZGIgc2ggc29ydCBzdHJpcCBzeXNjdGwgdGVzdCB0aW1lIHRydWUgdW5h
bWUgd2MgIHppYyB0enNldHVwICBtYWtld2hhdGlzOyBkbyAgaWYgcHJvZ3BhdGg9YGVudiBQ
QVRIPS91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL2JpbjovdXNyL29iai91c3Iv
c3JjL2FtZDY0LmFtZDY0L3RtcC91c3Ivc2JpbjovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFt
ZDY0L3RtcC91c3IvYmluOi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL2xlZ2Fj
eS91c3Ivc2JpbjovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC9sZWdhY3kvdXNy
L2JpbjovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC9sZWdhY3kvYmluOi91c3Iv
b2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL2xlZ2FjeS91c3IvbGliZXhlYzo6L3NiaW46
L2JpbjovdXNyL3NiaW46L3Vzci9iaW4gd2hpY2ggJHByb2dgOyB0aGVuICBlY2hvICRwcm9n
cGF0aDsgIGVsc2UgIGVjaG8gIlJlcXVpcmVkIHRvb2wgJHByb2cgbm90IGZvdW5kIGluIFBB
VEggKCRQQVRIKS4iID4mMjsgIGV4aXQgMTsgIGZpOyAgZG9uZSk7ICBpZiBbIC16ICIiIF0g
OyB0aGVuICBsaWJzPSQobGRkIC1mICIlbyAlcFxuIiAtZiAiJW8gJXBcbiIgJHByb2dzIDI+
L2Rldi9udWxsIHwgc29ydCAtdSB8IGdyZXAgLUV2ICdcWy4qXScgfCAgd2hpbGUgcmVhZCBs
aW5lOyBkbyAgc2V0IC0tICRsaW5lOyAgaWYgWyAiJDIgJDMiICE9ICJub3QgZm91bmQiIF07
IHRoZW4gIGVjaG8gJDI7ICBlbHNlICBlY2hvICJSZXF1aXJlZCBsaWJyYXJ5ICQxIG5vdCBm
b3VuZC4iID4mMjsgIGV4aXQgMTsgIGZpOyAgZG9uZSk7ICBmaTsgIGNwICRsaWJzICRwcm9n
cyAvdG1wL2luc3RhbGwucUV6RERhT2JJaQpjcCAtUiAke1BBVEhfTE9DQUxFOi0iL3Vzci9z
aGFyZS9sb2NhbGUifSAvdG1wL2luc3RhbGwucUV6RERhT2JJaS9sb2NhbGUKY2QgL3Vzci9z
cmM7IHRpbWUgZW52IE1BQ0hJTkVfQVJDSD1hbWQ2NCAgTUFDSElORT1hbWQ2NCAgQ1BVVFlQ
RT0gQ0M9ImNjIC10YXJnZXQgeDg2XzY0LXVua25vd24tZnJlZWJzZCAtLXN5c3Jvb3Q9L3Vz
ci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAgLUIvdXNyL29iai91c3Ivc3JjL2FtZDY0
LmFtZDY0L3RtcC91c3IvYmluIiBDWFg9ImMrKyAgLXRhcmdldCB4ODZfNjQtdW5rbm93bi1m
cmVlYnNkIC0tc3lzcm9vdD0vdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcCAtQi91
c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL3Vzci9iaW4iICBDUFA9ImNwcCAtdGFy
Z2V0IHg4Nl82NC11bmtub3duLWZyZWVic2QgLS1zeXNyb290PS91c3Ivb2JqL3Vzci9zcmMv
YW1kNjQuYW1kNjQvdG1wIC1CL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAvdXNy
L2JpbiIgIEFTPSJhcyIgQVI9ImFyIiBFTEZDVEw9ImVsZmN0bCIgTEQ9ImxkIiAgTExWTV9M
SU5LPSIiIE5NPW5tIE9CSkNPUFk9Im9iamNvcHkiICBSQU5MSUI9cmFubGliIFNUUklOR1M9
ICBTSVpFPSJzaXplIiBTVFJJUEJJTj0ic3RyaXAiIFBBVEg9L3Vzci9vYmovdXNyL3NyYy9h
bWQ2NC5hbWQ2NC90bXAvYmluOi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL3Vz
ci9zYmluOi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL3Vzci9iaW46L3Vzci9v
YmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAvbGVnYWN5L3Vzci9zYmluOi91c3Ivb2JqL3Vz
ci9zcmMvYW1kNjQuYW1kNjQvdG1wL2xlZ2FjeS91c3IvYmluOi91c3Ivb2JqL3Vzci9zcmMv
YW1kNjQuYW1kNjQvdG1wL2xlZ2FjeS9iaW46L3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2
NC90bXAvbGVnYWN5L3Vzci9saWJleGVjOjovdG1wL2luc3RhbGwucUV6RERhT2JJaSAgTERf
TElCUkFSWV9QQVRIPS90bXAvaW5zdGFsbC5xRXpERGFPYklpICBQQVRIX0xPQ0FMRT0vdG1w
L2luc3RhbGwucUV6RERhT2JJaS9sb2NhbGUgbWFrZSAtZiBNYWtlZmlsZS5pbmMxICBJTlNU
QUxMPSJpbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyIgTVRSRUVfQ01EPSJtdHJlZSAtTiAvdXNy
L3NyYy9ldGMiIF9fTUFLRV9TSEVMTD0vdG1wL2luc3RhbGwucUV6RERhT2JJaS9zaCByZWlu
c3RhbGw7ICBNQUNISU5FX0FSQ0g9YW1kNjQgIE1BQ0hJTkU9YW1kNjQgIENQVVRZUEU9IEND
PSJjYyAtdGFyZ2V0IHg4Nl82NC11bmtub3duLWZyZWVic2QgLS1zeXNyb290PS91c3Ivb2Jq
L3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wIC1CL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2
NC90bXAvdXNyL2JpbiIgQ1hYPSJjKysgIC10YXJnZXQgeDg2XzY0LXVua25vd24tZnJlZWJz
ZCAtLXN5c3Jvb3Q9L3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAgLUIvdXNyL29i
ai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC91c3IvYmluIiAgQ1BQPSJjcHAgLXRhcmdldCB4
ODZfNjQtdW5rbm93bi1mcmVlYnNkIC0tc3lzcm9vdD0vdXNyL29iai91c3Ivc3JjL2FtZDY0
LmFtZDY0L3RtcCAtQi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL3Vzci9iaW4i
ICBBUz0iYXMiIEFSPSJhciIgRUxGQ1RMPSJlbGZjdGwiIExEPSJsZCIgIExMVk1fTElOSz0i
IiBOTT1ubSBPQkpDT1BZPSJvYmpjb3B5IiAgUkFOTElCPXJhbmxpYiBTVFJJTkdTPSAgU0la
RT0ic2l6ZSIgU1RSSVBCSU49InN0cmlwIiBQQVRIPS91c3Ivb2JqL3Vzci9zcmMvYW1kNjQu
YW1kNjQvdG1wL2JpbjovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC91c3Ivc2Jp
bjovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC91c3IvYmluOi91c3Ivb2JqL3Vz
ci9zcmMvYW1kNjQuYW1kNjQvdG1wL2xlZ2FjeS91c3Ivc2JpbjovdXNyL29iai91c3Ivc3Jj
L2FtZDY0LmFtZDY0L3RtcC9sZWdhY3kvdXNyL2JpbjovdXNyL29iai91c3Ivc3JjL2FtZDY0
LmFtZDY0L3RtcC9sZWdhY3kvYmluOi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1w
L2xlZ2FjeS91c3IvbGliZXhlYzo6L3RtcC9pbnN0YWxsLnFFekREYU9iSWkgIExEX0xJQlJB
UllfUEFUSD0vdG1wL2luc3RhbGwucUV6RERhT2JJaSAgUEFUSF9MT0NBTEU9L3RtcC9pbnN0
YWxsLnFFekREYU9iSWkvbG9jYWxlIHJtIC1yZiAvdG1wL2luc3RhbGwucUV6RERhT2JJaQot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQo+Pj4gTWFraW5nIGhpZXJhcmNoeQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpjZCAvdXNyL3NyYzsgbWFr
ZSAtZiBNYWtlZmlsZS5pbmMxICBMT0NBTF9NVFJFRT0gaGllcmFyY2h5CmNkIC91c3Ivc3Jj
L2V0YzsgUEFUSD0vdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC9iaW46L3Vzci9v
YmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAvdXNyL3NiaW46L3Vzci9vYmovdXNyL3NyYy9h
bWQ2NC5hbWQ2NC90bXAvdXNyL2JpbjovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3Rt
cC9sZWdhY3kvdXNyL3NiaW46L3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAvbGVn
YWN5L3Vzci9iaW46L3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAvbGVnYWN5L2Jp
bjovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC9sZWdhY3kvdXNyL2xpYmV4ZWM6
Oi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL2JpbjovdXNyL29iai91c3Ivc3Jj
L2FtZDY0LmFtZDY0L3RtcC91c3Ivc2JpbjovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0
L3RtcC91c3IvYmluOi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL2xlZ2FjeS91
c3Ivc2JpbjovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC9sZWdhY3kvdXNyL2Jp
bjovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3RtcC9sZWdhY3kvYmluOi91c3Ivb2Jq
L3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL2xlZ2FjeS91c3IvbGliZXhlYzo6L3RtcC9pbnN0
YWxsLnFFekREYU9iSWkgbWFrZSBMT0NBTF9NVFJFRT0gZGlzdHJpYi1kaXJzCmZvciBmaWxl
IGluIC91c3Ivc2hhcmUvZG9jL3VzZC8xMC5leHJlZiAvdXNyL3NoYXJlL2RvYy91c2QvMTEu
ZWRpdCAvdXNyL3NoYXJlL2RvYy91c2QvMTIudmkgL3Vzci9zaGFyZS9kb2MvdXNkLzEzLnZp
cmVmOyBkbyAgaWYgWyAtZiAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluLyR7Zmls
ZX0gXTsgdGhlbiAgcm0gLWYgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFpbi8ke2Zp
bGV9OyAgZmk7ICBkb25lCm10cmVlIC1OIC91c3Ivc3JjL2V0YyAtZGVVIC1pIC1mIC91c3Iv
c3JjL2V0Yy9tdHJlZS9CU0Qucm9vdC5kaXN0IC1wIC91c3IvbG9jYWwvcG91ZHJpZXJlL2ph
aWxzL21haW4vCm10cmVlIC1OIC91c3Ivc3JjL2V0YyAtZGVVIC1pIC1mIC91c3Ivc3JjL2V0
Yy9tdHJlZS9CU0QudmFyLmRpc3QgLXAgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFp
bi92YXIKbXRyZWUgLU4gL3Vzci9zcmMvZXRjIC1kZVUgLWkgLWYgL3Vzci9zcmMvZXRjL210
cmVlL0JTRC51c3IuZGlzdCAtcCAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vz
cgptdHJlZSAtTiAvdXNyL3NyYy9ldGMgLWRlVSAtaSAtZiAvdXNyL3NyYy9ldGMvbXRyZWUv
QlNELmluY2x1ZGUuZGlzdCAtcCAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vz
ci9pbmNsdWRlCm10cmVlIC1OIC91c3Ivc3JjL2V0YyAtZGVVIC1pIC1mIC91c3Ivc3JjL2V0
Yy9tdHJlZS9CU0QuZGVidWcuZGlzdCAtcCAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9t
YWluL3Vzci9saWIKbXRyZWUgLU4gL3Vzci9zcmMvZXRjIC1kZVUgLWkgLWYgL3Vzci9zcmMv
ZXRjL210cmVlL0JTRC5saWIzMi5kaXN0IC1wIC91c3IvbG9jYWwvcG91ZHJpZXJlL2phaWxz
L21haW4vdXNyCm10cmVlIC1OIC91c3Ivc3JjL2V0YyAtZGVVIC1pIC1mIC91c3Ivc3JjL2V0
Yy9tdHJlZS9CU0QubGliMzIuZGlzdCAtcCAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9t
YWluL3Vzci9saWIvZGVidWcvdXNyCm10cmVlIC1OIC91c3Ivc3JjL2V0YyAtZGVVIC1pIC1m
IC91c3Ivc3JjL2V0Yy9tdHJlZS9CU0QudGVzdHMuZGlzdCAtcCAvdXNyL2xvY2FsL3BvdWRy
aWVyZS9qYWlscy9tYWluL3Vzci90ZXN0cwptdHJlZSAtTiAvdXNyL3NyYy9ldGMgLWRlVSAt
aSAtZiAvdXNyL3NyYy9ldGMvbXRyZWUvQlNELnRlc3RzLmRpc3QgLXAgL3Vzci9sb2NhbC9w
b3VkcmllcmUvamFpbHMvbWFpbi91c3IvbGliL2RlYnVnLy91c3IvdGVzdHMKbXRyZWUgLU4g
L3Vzci9zcmMvZXRjIC1kZVUgLWkgLWYgL3Vzci9zcmMvZXRjL210cmVlL0JTRC5zZW5kbWFp
bC5kaXN0IC1wIC91c3IvbG9jYWwvcG91ZHJpZXJlL2phaWxzL21haW4vCmluc3RhbGwgLU4g
L3Vzci9zcmMvZXRjIC1sIHMgLW8gcm9vdCAtZyB3aGVlbCAtbSA3NTUgLVQgInBhY2thZ2U9
dXRpbGl0aWVzIiAgIkMiICIvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vzci9z
aGFyZS9ubHMvUE9TSVgiCmluc3RhbGwgLU4gL3Vzci9zcmMvZXRjIC1sIHMgLW8gcm9vdCAt
ZyB3aGVlbCAtbSA3NTUgLVQgInBhY2thZ2U9dXRpbGl0aWVzIiAgIkMiICIvdXNyL2xvY2Fs
L3BvdWRyaWVyZS9qYWlscy9tYWluL3Vzci9zaGFyZS9ubHMvZW5fVVMuVVNfQVNDSUkiCgot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQo+Pj4gSW5zdGFsbGluZyBldmVyeXRoaW5nIHN0YXJ0ZWQgb24gU2F0IE9jdCAy
OSAxOToyMjoyMyBCU1QgMjAyMgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpjZCAvdXNyL3NyYzsgbWFrZSAtZiBNYWtl
ZmlsZS5pbmMxIGluc3RhbGwKbWFrZVszXTogIi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1k
NjQvdG9vbGNoYWluLW1ldGFkYXRhLm1rIiBsaW5lIDE6IFVzaW5nIGNhY2hlZCB0b29sY2hh
aW4gbWV0YWRhdGEgZnJvbSBidWlsZCBhdCBtb3dhMjE5LWdqcDQtODU3MHAtZnJlZWJzZCBv
biBTYXQgMjkgT2N0IDIwMjIgMDE6MjY6MzggQlNUCj09PT4gbGliIChpbnN0YWxsKQo9PT0+
IGxpYi9jc3UgKGluc3RhbGwpCj09PT4gbGliL2NzdS9hbWQ2NCAoaW5zdGFsbCkKaW5zdGFs
bGluZyBESVJTIEZJTEVTRElSCmluc3RhbGwgLU4gL3Vzci9zcmMvZXRjICAtZCAtbSAwNzU1
IC1vIHJvb3QgIC1nIHdoZWVsICAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vz
ci9saWIKaW5zdGFsbCAtTiAvdXNyL3NyYy9ldGMgIC1vIHJvb3QgIC1nIHdoZWVsIC1tIDQ0
NCAgU2NydDEubyAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vzci9saWIvU2Ny
dDEubwppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLW8gcm9vdCAgLWcgd2hlZWwgLW0gNDQ0
ICBjcnQxLm8gL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFpbi91c3IvbGliL2NydDEu
bwppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLW8gcm9vdCAgLWcgd2hlZWwgLW0gNDQ0ICBn
Y3J0MS5vIC91c3IvbG9jYWwvcG91ZHJpZXJlL2phaWxzL21haW4vdXNyL2xpYi9nY3J0MS5v
Cmluc3RhbGwgLU4gL3Vzci9zcmMvZXRjICAtbyByb290ICAtZyB3aGVlbCAtbSA0NDQgIGNy
dGJlZ2luLm8gL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFpbi91c3IvbGliL2NydGJl
Z2luLm8KaW5zdGFsbCAtTiAvdXNyL3NyYy9ldGMgIC1vIHJvb3QgIC1nIHdoZWVsIC1tIDQ0
NCAgY3J0YmVnaW5TLm8gL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFpbi91c3IvbGli
L2NydGJlZ2luUy5vCmluc3RhbGwgLU4gL3Vzci9zcmMvZXRjICAtbyByb290ICAtZyB3aGVl
bCAtbSA0NDQgIGNydGJlZ2luVC5vIC91c3IvbG9jYWwvcG91ZHJpZXJlL2phaWxzL21haW4v
dXNyL2xpYi9jcnRiZWdpblQubwppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLW8gcm9vdCAg
LWcgd2hlZWwgLW0gNDQ0ICBjcnRlbmQubyAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9t
YWluL3Vzci9saWIvY3J0ZW5kLm8KaW5zdGFsbCAtTiAvdXNyL3NyYy9ldGMgIC1vIHJvb3Qg
IC1nIHdoZWVsIC1tIDQ0NCAgY3J0ZW5kUy5vIC91c3IvbG9jYWwvcG91ZHJpZXJlL2phaWxz
L21haW4vdXNyL2xpYi9jcnRlbmRTLm8KaW5zdGFsbCAtTiAvdXNyL3NyYy9ldGMgIC1vIHJv
b3QgIC1nIHdoZWVsIC1tIDQ0NCAgY3J0aS5vIC91c3IvbG9jYWwvcG91ZHJpZXJlL2phaWxz
L21haW4vdXNyL2xpYi9jcnRpLm8KaW5zdGFsbCAtTiAvdXNyL3NyYy9ldGMgIC1vIHJvb3Qg
IC1nIHdoZWVsIC1tIDQ0NCAgY3J0bi5vIC91c3IvbG9jYWwvcG91ZHJpZXJlL2phaWxzL21h
aW4vdXNyL2xpYi9jcnRuLm8KPT09PiBsaWIvY3N1L3Rlc3RzIChpbnN0YWxsKQppbnN0YWxs
aW5nIERJUlMgdGVzdHNGSUxFU0RJUgppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLWQgLW0g
MDc1NSAtbyByb290ICAtZyB3aGVlbCAgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFp
bi91c3IvdGVzdHMvbGliL2NzdQppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLW8gcm9vdCAg
LWcgd2hlZWwgLW0gNDQ0ICBLeXVhZmlsZSAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9t
YWluL3Vzci90ZXN0cy9saWIvY3N1L0t5dWFmaWxlCj09PT4gbGliL2NzdS90ZXN0cy9kc28g
KGluc3RhbGwpCmluc3RhbGwgLU4gL3Vzci9zcmMvZXRjICAtcyAtbyByb290IC1nIHdoZWVs
IC1tIDQ0NCAgIC1TICBsaWJoX2NzdS5zbyAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9t
YWluL3Vzci90ZXN0cy9saWIvY3N1L2R5bmFtaWNsaWIvLwppbnN0YWxsIC1OIC91c3Ivc3Jj
L2V0YyAgLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgICAgbGliaF9jc3Uuc28uZGVidWcgL3Vz
ci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFpbi91c3IvbGliL2RlYnVnL3Vzci90ZXN0cy9s
aWIvY3N1L2R5bmFtaWNsaWIvLwo9PT0+IGxpYi9jc3UvdGVzdHMvZHluYW1pYyAoaW5zdGFs
bCkKaW5zdGFsbGluZyBESVJTIHRlc3RzRklMRVNESVIKaW5zdGFsbCAtTiAvdXNyL3NyYy9l
dGMgIC1kIC1tIDA3NTUgLW8gcm9vdCAgLWcgd2hlZWwgIC91c3IvbG9jYWwvcG91ZHJpZXJl
L2phaWxzL21haW4vdXNyL3Rlc3RzL2xpYi9jc3UvZHluYW1pYwppbnN0YWxsIC1OIC91c3Iv
c3JjL2V0YyAgLW8gcm9vdCAgLWcgd2hlZWwgLW0gNDQ0ICBLeXVhZmlsZSAvdXNyL2xvY2Fs
L3BvdWRyaWVyZS9qYWlscy9tYWluL3Vzci90ZXN0cy9saWIvY3N1L2R5bmFtaWMvS3l1YWZp
bGUKKGNkIC91c3Ivc3JjL2xpYi9jc3UvdGVzdHMvZHluYW1pYyAmJiAgREVQRU5ERklMRT0u
ZGVwZW5kLmluaXRfdGVzdCAgTk9fU1VCRElSPTEgbWFrZSAtZiAvdXNyL3NyYy9saWIvY3N1
L3Rlc3RzL2R5bmFtaWMvTWFrZWZpbGUgX1JFQ1VSU0lOR19QUk9HUz10ICAgUFJPRz1pbml0
X3Rlc3QgIGluc3RhbGwpCmluc3RhbGwgLU4gL3Vzci9zcmMvZXRjICAtcyAtbyByb290IC1n
IHdoZWVsIC1tIDU1NSAgIGluaXRfdGVzdCAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9t
YWluL3Vzci90ZXN0cy9saWIvY3N1L2R5bmFtaWMvaW5pdF90ZXN0Cmluc3RhbGwgLU4gL3Vz
ci9zcmMvZXRjICAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgaW5pdF90ZXN0LmRlYnVnIC91
c3IvbG9jYWwvcG91ZHJpZXJlL2phaWxzL21haW4vdXNyL2xpYi9kZWJ1Zy91c3IvdGVzdHMv
bGliL2NzdS9keW5hbWljL2luaXRfdGVzdC5kZWJ1ZwooY2QgL3Vzci9zcmMvbGliL2NzdS90
ZXN0cy9keW5hbWljICYmICBERVBFTkRGSUxFPS5kZXBlbmQuZmluaV90ZXN0ICBOT19TVUJE
SVI9MSBtYWtlIC1mIC91c3Ivc3JjL2xpYi9jc3UvdGVzdHMvZHluYW1pYy9NYWtlZmlsZSBf
UkVDVVJTSU5HX1BST0dTPXQgICBQUk9HPWZpbmlfdGVzdCAgaW5zdGFsbCkKaW5zdGFsbCAt
TiAvdXNyL3NyYy9ldGMgIC1zIC1vIHJvb3QgLWcgd2hlZWwgLW0gNTU1ICAgZmluaV90ZXN0
IC91c3IvbG9jYWwvcG91ZHJpZXJlL2phaWxzL21haW4vdXNyL3Rlc3RzL2xpYi9jc3UvZHlu
YW1pYy9maW5pX3Rlc3QKaW5zdGFsbCAtTiAvdXNyL3NyYy9ldGMgIC1vIHJvb3QgLWcgd2hl
ZWwgLW0gNDQ0ICBmaW5pX3Rlc3QuZGVidWcgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMv
bWFpbi91c3IvbGliL2RlYnVnL3Vzci90ZXN0cy9saWIvY3N1L2R5bmFtaWMvZmluaV90ZXN0
LmRlYnVnCihjZCAvdXNyL3NyYy9saWIvY3N1L3Rlc3RzL2R5bmFtaWMgJiYgIERFUEVOREZJ
TEU9LmRlcGVuZC5jeHhfY29uc3RydWN0b3JzICBOT19TVUJESVI9MSBtYWtlIC1mIC91c3Iv
c3JjL2xpYi9jc3UvdGVzdHMvZHluYW1pYy9NYWtlZmlsZSBfUkVDVVJTSU5HX1BST0dTPXQg
ICBQUk9HPWN4eF9jb25zdHJ1Y3RvcnMgUFJPR19DWFg9Y3h4X2NvbnN0cnVjdG9ycyBpbnN0
YWxsKQppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLXMgLW8gcm9vdCAtZyB3aGVlbCAtbSA1
NTUgICBjeHhfY29uc3RydWN0b3JzIC91c3IvbG9jYWwvcG91ZHJpZXJlL2phaWxzL21haW4v
dXNyL3Rlc3RzL2xpYi9jc3UvZHluYW1pYy9jeHhfY29uc3RydWN0b3JzCmluc3RhbGwgLU4g
L3Vzci9zcmMvZXRjICAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgY3h4X2NvbnN0cnVjdG9y
cy5kZWJ1ZyAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vzci9saWIvZGVidWcv
dXNyL3Rlc3RzL2xpYi9jc3UvZHluYW1pYy9jeHhfY29uc3RydWN0b3JzLmRlYnVnCj09PT4g
bGliL2NzdS90ZXN0cy9keW5hbWljbGliIChpbnN0YWxsKQppbnN0YWxsaW5nIERJUlMgdGVz
dHNGSUxFU0RJUgppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLWQgLW0gMDc1NSAtbyByb290
ICAtZyB3aGVlbCAgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFpbi91c3IvdGVzdHMv
bGliL2NzdS9keW5hbWljbGliCmluc3RhbGwgLU4gL3Vzci9zcmMvZXRjICAtbyByb290ICAt
ZyB3aGVlbCAtbSA0NDQgIEt5dWFmaWxlIC91c3IvbG9jYWwvcG91ZHJpZXJlL2phaWxzL21h
aW4vdXNyL3Rlc3RzL2xpYi9jc3UvZHluYW1pY2xpYi9LeXVhZmlsZQooY2QgL3Vzci9zcmMv
bGliL2NzdS90ZXN0cy9keW5hbWljbGliICYmICBERVBFTkRGSUxFPS5kZXBlbmQuY3h4X2Nv
bnN0cnVjdG9ycyAgTk9fU1VCRElSPTEgbWFrZSAtZiAvdXNyL3NyYy9saWIvY3N1L3Rlc3Rz
L2R5bmFtaWNsaWIvTWFrZWZpbGUgX1JFQ1VSU0lOR19QUk9HUz10ICAgUFJPRz1jeHhfY29u
c3RydWN0b3JzIFBST0dfQ1hYPWN4eF9jb25zdHJ1Y3RvcnMgaW5zdGFsbCkKaW5zdGFsbCAt
TiAvdXNyL3NyYy9ldGMgIC1zIC1vIHJvb3QgLWcgd2hlZWwgLW0gNTU1ICAgY3h4X2NvbnN0
cnVjdG9ycyAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vzci90ZXN0cy9saWIv
Y3N1L2R5bmFtaWNsaWIvY3h4X2NvbnN0cnVjdG9ycwppbnN0YWxsIC1OIC91c3Ivc3JjL2V0
YyAgLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgIGN4eF9jb25zdHJ1Y3RvcnMuZGVidWcgL3Vz
ci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFpbi91c3IvbGliL2RlYnVnL3Vzci90ZXN0cy9s
aWIvY3N1L2R5bmFtaWNsaWIvY3h4X2NvbnN0cnVjdG9ycy5kZWJ1ZwooY2QgL3Vzci9zcmMv
bGliL2NzdS90ZXN0cy9keW5hbWljbGliICYmICBERVBFTkRGSUxFPS5kZXBlbmQuaW5pdF90
ZXN0ICBOT19TVUJESVI9MSBtYWtlIC1mIC91c3Ivc3JjL2xpYi9jc3UvdGVzdHMvZHluYW1p
Y2xpYi9NYWtlZmlsZSBfUkVDVVJTSU5HX1BST0dTPXQgICBQUk9HPWluaXRfdGVzdCBQUk9H
X0NYWD1pbml0X3Rlc3QgaW5zdGFsbCkKaW5zdGFsbCAtTiAvdXNyL3NyYy9ldGMgIC1zIC1v
IHJvb3QgLWcgd2hlZWwgLW0gNTU1ICAgaW5pdF90ZXN0IC91c3IvbG9jYWwvcG91ZHJpZXJl
L2phaWxzL21haW4vdXNyL3Rlc3RzL2xpYi9jc3UvZHluYW1pY2xpYi9pbml0X3Rlc3QKaW5z
dGFsbCAtTiAvdXNyL3NyYy9ldGMgIC1vIHJvb3QgLWcgd2hlZWwgLW0gNDQ0ICBpbml0X3Rl
c3QuZGVidWcgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFpbi91c3IvbGliL2RlYnVn
L3Vzci90ZXN0cy9saWIvY3N1L2R5bmFtaWNsaWIvaW5pdF90ZXN0LmRlYnVnCihjZCAvdXNy
L3NyYy9saWIvY3N1L3Rlc3RzL2R5bmFtaWNsaWIgJiYgIERFUEVOREZJTEU9LmRlcGVuZC5m
aW5pX3Rlc3QgIE5PX1NVQkRJUj0xIG1ha2UgLWYgL3Vzci9zcmMvbGliL2NzdS90ZXN0cy9k
eW5hbWljbGliL01ha2VmaWxlIF9SRUNVUlNJTkdfUFJPR1M9dCAgIFBST0c9ZmluaV90ZXN0
IFBST0dfQ1hYPWZpbmlfdGVzdCBpbnN0YWxsKQppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAg
LXMgLW8gcm9vdCAtZyB3aGVlbCAtbSA1NTUgICBmaW5pX3Rlc3QgL3Vzci9sb2NhbC9wb3Vk
cmllcmUvamFpbHMvbWFpbi91c3IvdGVzdHMvbGliL2NzdS9keW5hbWljbGliL2ZpbmlfdGVz
dAppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgIGZp
bmlfdGVzdC5kZWJ1ZyAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vzci9saWIv
ZGVidWcvdXNyL3Rlc3RzL2xpYi9jc3UvZHluYW1pY2xpYi9maW5pX3Rlc3QuZGVidWcKPT09
PiBsaWIvY3N1L3Rlc3RzL2R5bmFtaWNwaWUgKGluc3RhbGwpCmluc3RhbGxpbmcgRElSUyB0
ZXN0c0ZJTEVTRElSCmluc3RhbGwgLU4gL3Vzci9zcmMvZXRjICAtZCAtbSAwNzU1IC1vIHJv
b3QgIC1nIHdoZWVsICAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vzci90ZXN0
cy9saWIvY3N1L2R5bmFtaWNwaWUKaW5zdGFsbCAtTiAvdXNyL3NyYy9ldGMgIC1vIHJvb3Qg
IC1nIHdoZWVsIC1tIDQ0NCAgS3l1YWZpbGUgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMv
bWFpbi91c3IvdGVzdHMvbGliL2NzdS9keW5hbWljcGllL0t5dWFmaWxlCihjZCAvdXNyL3Ny
Yy9saWIvY3N1L3Rlc3RzL2R5bmFtaWNwaWUgJiYgIERFUEVOREZJTEU9LmRlcGVuZC5pbml0
X3Rlc3QgIE5PX1NVQkRJUj0xIG1ha2UgLWYgL3Vzci9zcmMvbGliL2NzdS90ZXN0cy9keW5h
bWljcGllL01ha2VmaWxlIF9SRUNVUlNJTkdfUFJPR1M9dCAgIFBST0c9aW5pdF90ZXN0ICBp
bnN0YWxsKQppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLXMgLW8gcm9vdCAtZyB3aGVlbCAt
bSA1NTUgICBpbml0X3Rlc3QgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFpbi91c3Iv
dGVzdHMvbGliL2NzdS9keW5hbWljcGllL2luaXRfdGVzdAppbnN0YWxsIC1OIC91c3Ivc3Jj
L2V0YyAgLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgIGluaXRfdGVzdC5kZWJ1ZyAvdXNyL2xv
Y2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vzci9saWIvZGVidWcvdXNyL3Rlc3RzL2xpYi9j
c3UvZHluYW1pY3BpZS9pbml0X3Rlc3QuZGVidWcKKGNkIC91c3Ivc3JjL2xpYi9jc3UvdGVz
dHMvZHluYW1pY3BpZSAmJiAgREVQRU5ERklMRT0uZGVwZW5kLmZpbmlfdGVzdCAgTk9fU1VC
RElSPTEgbWFrZSAtZiAvdXNyL3NyYy9saWIvY3N1L3Rlc3RzL2R5bmFtaWNwaWUvTWFrZWZp
bGUgX1JFQ1VSU0lOR19QUk9HUz10ICAgUFJPRz1maW5pX3Rlc3QgIGluc3RhbGwpCmluc3Rh
bGwgLU4gL3Vzci9zcmMvZXRjICAtcyAtbyByb290IC1nIHdoZWVsIC1tIDU1NSAgIGZpbmlf
dGVzdCAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vzci90ZXN0cy9saWIvY3N1
L2R5bmFtaWNwaWUvZmluaV90ZXN0Cmluc3RhbGwgLU4gL3Vzci9zcmMvZXRjICAtbyByb290
IC1nIHdoZWVsIC1tIDQ0NCAgZmluaV90ZXN0LmRlYnVnIC91c3IvbG9jYWwvcG91ZHJpZXJl
L2phaWxzL21haW4vdXNyL2xpYi9kZWJ1Zy91c3IvdGVzdHMvbGliL2NzdS9keW5hbWljcGll
L2ZpbmlfdGVzdC5kZWJ1ZwooY2QgL3Vzci9zcmMvbGliL2NzdS90ZXN0cy9keW5hbWljcGll
ICYmICBERVBFTkRGSUxFPS5kZXBlbmQuY3h4X2NvbnN0cnVjdG9ycyAgTk9fU1VCRElSPTEg
bWFrZSAtZiAvdXNyL3NyYy9saWIvY3N1L3Rlc3RzL2R5bmFtaWNwaWUvTWFrZWZpbGUgX1JF
Q1VSU0lOR19QUk9HUz10ICAgUFJPRz1jeHhfY29uc3RydWN0b3JzIFBST0dfQ1hYPWN4eF9j
b25zdHJ1Y3RvcnMgaW5zdGFsbCkKaW5zdGFsbCAtTiAvdXNyL3NyYy9ldGMgIC1zIC1vIHJv
b3QgLWcgd2hlZWwgLW0gNTU1ICAgY3h4X2NvbnN0cnVjdG9ycyAvdXNyL2xvY2FsL3BvdWRy
aWVyZS9qYWlscy9tYWluL3Vzci90ZXN0cy9saWIvY3N1L2R5bmFtaWNwaWUvY3h4X2NvbnN0
cnVjdG9ycwppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLW8gcm9vdCAtZyB3aGVlbCAtbSA0
NDQgIGN4eF9jb25zdHJ1Y3RvcnMuZGVidWcgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMv
bWFpbi91c3IvbGliL2RlYnVnL3Vzci90ZXN0cy9saWIvY3N1L2R5bmFtaWNwaWUvY3h4X2Nv
bnN0cnVjdG9ycy5kZWJ1Zwo9PT0+IGxpYi9jc3UvdGVzdHMvc3RhdGljIChpbnN0YWxsKQpp
bnN0YWxsaW5nIERJUlMgdGVzdHNGSUxFU0RJUgppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAg
LWQgLW0gMDc1NSAtbyByb290ICAtZyB3aGVlbCAgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFp
bHMvbWFpbi91c3IvdGVzdHMvbGliL2NzdS9zdGF0aWMKaW5zdGFsbCAtTiAvdXNyL3NyYy9l
dGMgIC1vIHJvb3QgIC1nIHdoZWVsIC1tIDQ0NCAgS3l1YWZpbGUgL3Vzci9sb2NhbC9wb3Vk
cmllcmUvamFpbHMvbWFpbi91c3IvdGVzdHMvbGliL2NzdS9zdGF0aWMvS3l1YWZpbGUKKGNk
IC91c3Ivc3JjL2xpYi9jc3UvdGVzdHMvc3RhdGljICYmICBERVBFTkRGSUxFPS5kZXBlbmQu
aW5pdF90ZXN0ICBOT19TVUJESVI9MSBtYWtlIC1mIC91c3Ivc3JjL2xpYi9jc3UvdGVzdHMv
c3RhdGljL01ha2VmaWxlIF9SRUNVUlNJTkdfUFJPR1M9dCAgIFBST0c9aW5pdF90ZXN0ICBp
bnN0YWxsKQppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLXMgLW8gcm9vdCAtZyB3aGVlbCAt
bSA1NTUgICBpbml0X3Rlc3QgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFpbi91c3Iv
dGVzdHMvbGliL2NzdS9zdGF0aWMvaW5pdF90ZXN0Cmluc3RhbGwgLU4gL3Vzci9zcmMvZXRj
ICAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgaW5pdF90ZXN0LmRlYnVnIC91c3IvbG9jYWwv
cG91ZHJpZXJlL2phaWxzL21haW4vdXNyL2xpYi9kZWJ1Zy91c3IvdGVzdHMvbGliL2NzdS9z
dGF0aWMvaW5pdF90ZXN0LmRlYnVnCihjZCAvdXNyL3NyYy9saWIvY3N1L3Rlc3RzL3N0YXRp
YyAmJiAgREVQRU5ERklMRT0uZGVwZW5kLmZpbmlfdGVzdCAgTk9fU1VCRElSPTEgbWFrZSAt
ZiAvdXNyL3NyYy9saWIvY3N1L3Rlc3RzL3N0YXRpYy9NYWtlZmlsZSBfUkVDVVJTSU5HX1BS
T0dTPXQgICBQUk9HPWZpbmlfdGVzdCAgaW5zdGFsbCkKaW5zdGFsbCAtTiAvdXNyL3NyYy9l
dGMgIC1zIC1vIHJvb3QgLWcgd2hlZWwgLW0gNTU1ICAgZmluaV90ZXN0IC91c3IvbG9jYWwv
cG91ZHJpZXJlL2phaWxzL21haW4vdXNyL3Rlc3RzL2xpYi9jc3Uvc3RhdGljL2ZpbmlfdGVz
dAppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgIGZp
bmlfdGVzdC5kZWJ1ZyAvdXNyL2xvY2FsL3BvdWRyaWVyZS9qYWlscy9tYWluL3Vzci9saWIv
ZGVidWcvdXNyL3Rlc3RzL2xpYi9jc3Uvc3RhdGljL2ZpbmlfdGVzdC5kZWJ1ZwooY2QgL3Vz
ci9zcmMvbGliL2NzdS90ZXN0cy9zdGF0aWMgJiYgIERFUEVOREZJTEU9LmRlcGVuZC5jeHhf
Y29uc3RydWN0b3JzICBOT19TVUJESVI9MSBtYWtlIC1mIC91c3Ivc3JjL2xpYi9jc3UvdGVz
dHMvc3RhdGljL01ha2VmaWxlIF9SRUNVUlNJTkdfUFJPR1M9dCAgIFBST0c9Y3h4X2NvbnN0
cnVjdG9ycyBQUk9HX0NYWD1jeHhfY29uc3RydWN0b3JzIGluc3RhbGwpCmluc3RhbGwgLU4g
L3Vzci9zcmMvZXRjICAtcyAtbyByb290IC1nIHdoZWVsIC1tIDU1NSAgIGN4eF9jb25zdHJ1
Y3RvcnMgL3Vzci9sb2NhbC9wb3VkcmllcmUvamFpbHMvbWFpbi91c3IvdGVzdHMvbGliL2Nz
dS9zdGF0aWMvY3h4X2NvbnN0cnVjdG9ycwppbnN0YWxsIC1OIC91c3Ivc3JjL2V0YyAgLW8g
cm9vdCAtZyB3aGVlbCAtbSA0NDQgIGN4eF9jb25zdHJ1Y3RvcnMuZGVidWcgL3Vzci9sb2Nh
bC9wb3VkcmllcmUvamFpbHMvbWFpbi91c3IvbGliL2RlYnVnL3Vzci90ZXN0cy9saWIvY3N1
L3N0YXRpYy9jeHhfY29uc3RydWN0b3JzLmRlYnVnCj09PT4gbGliL2xpYmMgKGluc3RhbGwp
Cm1ha2VbNV06ICIvdXNyL3NyYy9saWIvbGliYy9zeXMvTWFrZWZpbGUuaW5jIiBsaW5lIDk6
IENhbm5vdCBvcGVuIC91c3Ivc3JjL3N5cy9zeXMvc3lzY2FsbC5tawptYWtlWzVdOiBGYXRh
bCBlcnJvcnMgZW5jb3VudGVyZWQgLS0gY2Fubm90IGNvbnRpbnVlCm1ha2VbNV06IHN0b3Bw
ZWQgaW4gL3Vzci9zcmMvbGliL2xpYmMKKioqIEVycm9yIGNvZGUgMQoKU3RvcC4KbWFrZVs0
XTogc3RvcHBlZCBpbiAvdXNyL3NyYy9saWIKKioqIEVycm9yIGNvZGUgMQoKU3RvcC4KbWFr
ZVszXTogc3RvcHBlZCBpbiAvdXNyL3NyYwoqKiogRXJyb3IgY29kZSAxCgpTdG9wLgptYWtl
WzJdOiBzdG9wcGVkIGluIC91c3Ivc3JjCiAgICAgICAgMS40NyByZWFsICAgICAgICAgMC43
OCB1c2VyICAgICAgICAgMC4zNiBzeXMKKioqIEVycm9yIGNvZGUgMQoKU3RvcC4KbWFrZVsx
XTogc3RvcHBlZCBpbiAvdXNyL3NyYwoqKiogRXJyb3IgY29kZSAxCgpTdG9wLgptYWtlOiBz
dG9wcGVkIGluIC91c3Ivc3JjClswMDowMDowNF0gRXJyb3I6IEZhaWxlZCB0byAnbWFrZSBp
bnN0YWxsd29ybGQnCnJvb3RAbW93YTIxOS1nanA0LTg1NzBwLWZyZWVic2Q6fiAjIAo=

--------------pmpocLHcMd1dz3Co5gbA3k5W--

--------------F0xJz2zFb5a37vGrj5ltaUJp--

--------------lAaAKvhyjnKxZOWfz0xiOIsi
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmNdjV8FAwAAAAAACgkQt2dIb0oY1Atn
3w/+LKKQUjNksjXwoN9vMcXEBWGImPO+bCXzyq7/tJ0oUzJvPwG4IACE/FJXqbm01WMRLk/rHv0p
29ma6i5hMdqj/NGK8QAfZEfcP3QVjQEMECjCc7Eu9K5PzI1Cn1YOKizaBvGbMRoNZEAdYs6k/pRY
tZOkypB1c1NK/NLckKCA8sOXaUrnYwqOxMh49wrvtRBZzMl/pcs2XqJK7fur+DJQpUdE3JEo+4mF
ofvbgLcdIc9uM4584erIHze6Iyq80WoSab16BDEVHvjU06AiaMQciixu17dXJut5ULg9fEGt/rfg
gYDGf74gprn61sUbn1QDaEmckOfTTCP9miG8jCg0z/lhkpCtFmhZ/gPuF2fFb4BAhQfaAEuI5f/R
5dZMbcmlWn/E7mL7btyC1V1u+G6J1fw6vKJ+AEIGcv5BTQvjFZ9N65VVVuGPGymfTHm2Z1ytfFwR
yvBDRCWpNVy3ySsh7Wxr/iipLt+Q9058rim9Vsqu951HGWvYTFrxWmhpYZOxq7qWp6DSoOIbL0X0
4OZgOrQk0J/wbxDE9Ufq1M81A14y25oxjIyxYNUvGPHfyiOdFMznT05fbSzfWitXabJEbM9PuCoV
axlm45NApBEiyC/fWABhkJTcxzEi38zOdjt9akxnGEUClfaQhHh2Rp1Or3TTl7roukStjneGpdP3
g/0=
=pJGI
-----END PGP SIGNATURE-----

--------------lAaAKvhyjnKxZOWfz0xiOIsi--

From nobody Sat Oct 29 22:05:57 2022
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 4N0D5F1Gmcz4h0M1
	for ; Sat, 29 Oct 2022 22:06:09 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N0D5F0nLrz3gPT
	for ; Sat, 29 Oct 2022 22:06:09 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667081169;
	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=JCgeNew5opcOzFIeCAi1EZVmgfVqcoDx+D+N5qRUvZk=;
	b=Oz7T811W0mexPRZCEERNf/EPqWWyJOa9Md1lyokDKAedxmuPYDNvRf47v5sWFyCpWhjewp
	VQjmev2a+cwKnSiANSeNcAovD+Von9qv6KZzttPZZ4xezV/++CPPneIJd8rq8zH0L9k8vp
	vQ4ynTHFpQ5guRkqGa7yeC77PHOH6APl8y+puh4YtVQl8Yo+C3cyDrRUSFoBI28bUOgYfY
	y5DbsT11Mp8Lh3zDOHCyjIBbp6FZf52TBtcJGkAMASFd+cjFP18LdVqk61TP4EAmNbY9Bh
	SUa+evS2C1gnHDGrufCo544h9vgSZS95UzShDlHx9907j7GbFRTzWIXm5414pA==
Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N0D5D6mnrzqHy
	for ; Sat, 29 Oct 2022 22:06:08 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-ua1-f45.google.com with SMTP id t26so3466579uaj.9
        for ; Sat, 29 Oct 2022 15:06:08 -0700 (PDT)
X-Gm-Message-State: ACrzQf3Z/soazU0v83MJLt3A7XpUPvzESsOX4krSALRBzDrnVpg7byKT
	RbTVyGJ7mwC+yi6N7fYp8NVeHjTum6yhxlMEWkg=
X-Google-Smtp-Source: AMsMyM4WjWZrK2hVUEUf1XbIINGVatLs8h9sJDhkDUB7RpB1vddqePU0BPtij4+jG+4lf5yfzfT8SMoccFWU6HXc0aA=
X-Received: by 2002:ab0:601a:0:b0:3d2:a014:b043 with SMTP id
 j26-20020ab0601a000000b003d2a014b043mr1237274ual.13.1667081168496; Sat, 29
 Oct 2022 15:06: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: 
  
 <106b05da-be44-ef6f-e2c8-0888ee71ed88@selasky.org> 
 <10ff4875-c6bd-88a0-bf0d-7ae52106131e@selasky.org> 
 
In-Reply-To: 
From: Nuno Teixeira 
Date: Sat, 29 Oct 2022 23:05:57 +0100
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: morse(6) sound
To: Hans Petter Selasky 
Cc: Diane Bruce , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000dc2e4c05ec33947d"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667081169;
	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=JCgeNew5opcOzFIeCAi1EZVmgfVqcoDx+D+N5qRUvZk=;
	b=UiTAPi+FM+59q5V5s90+2nKzZbVQplZ6x87ogofZSM5XAtVWxhfM3zTxdm9T+kom7i1jiG
	1RCCbNqwypu6rXYjXDVJxjqxS7SxKttcUd4MmcCQyzJBBGmmFaUofJR8aKnML3ZeORSHyF
	/cSnZp8v2lyV185huCN/7FK8YCqkV3FI+jKOczJhSzaSMo3TmAGNbt/pamq2dyTdTVnSSD
	DlTd+qzlx2AcAJM9eoSExkDehpG55ZOHKqfdg+im2F/JG45deEoHiZMgKOeoDOcQg9DgSN
	gK5tTuMN/zRU3HEXqeoLXRGGVt65exAkph3yel5lPCUOToq3r7Cn5IQfyG95dg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667081169; a=rsa-sha256; cv=none;
	b=i9EAqKvKNh7h7qXvh7URej9Pq2wIPh1/ZA4/jCkr+KCLHTemGNiRUx1mGKXpnVjsS9DngE
	zyRHEiQgWIfuY1wSas2tla5AmV9/hbkrl+NkKEg4Dhw/kZeYGu4Glt93lKlfEPLcqEnWQU
	VFdpLhN6/FVLoooWItiEM8KrT5MPsYZvIVzALoP6ZrGJ+AqM1iFDRMURtbbE/EhVKMLboR
	RikxddAvfGyLI3n7b+lhDArGMeje1cHkPCk3CCjmv/bPDOsyRgiZRoRM0w+V3XZJNgpcwq
	wUpSrCrNZ2UNyTWexG4kq3lDOR8Rbamd18f25xVTAQzgUefCy7lLFaVYceGM+g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000dc2e4c05ec33947d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Considering that morse could use same beep dsp code, instead of
repeating dsp code inside morse, why not use a dsp library or
something so that morse could use it without duplicating code?

Hans Petter Selasky  escreveu no dia s=C3=A1bado, 29/10/20=
22
=C3=A0(s) 19:22:

> On 10/29/22 20:18, Nuno Teixeira wrote:
> >> Technically you could symlink the two - yes.
> >
> > Can't understand how, what do I missing?
> >
>
> In the main() routine, the name of the program name is passed.
>
> Then you just check if argv[0] =3D=3D "morse" and invoke main_morse()
> instead, if you see. Of course you need to write main_morse() first, but
> you can re-use all the dsp code in there.
>
> --HPS
>
>
>

--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000dc2e4c05ec33947d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Considering that morse could use same beep dsp code, =
instead of
repeating dsp code inside morse, why not use a dsp lib=
rary or
something so that morse could use it without duplicating =
code?

Hans Petter Selasky <hps@s=
elasky.org> escreveu no dia s=C3=A1bado, 29/10/2022 =C3=A0(s) 19:22:=

On 10/29/22 20:=
18, Nuno Teixeira wrote:

>> Technically you could symlink the two - yes.

> 

> Can't understand how, what do I missing?

> 



In the main() routine, the name of the program name is passed.



Then you just check if argv[0] =3D=3D "morse" and invoke main_mor=
se() 

instead, if you see. Of course you need to write main_morse() first, but 
you can re-use all the dsp code in there.



--HPS








-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--000000000000dc2e4c05ec33947d--

From nobody Sat Oct 29 23:51:15 2022
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 4N0GQg5v9tz4gD7G
	for ; Sat, 29 Oct 2022 23:51:23 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4N0GQf74Q1z3qXf;
	Sat, 29 Oct 2022 23:51:22 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from [10.36.2.68] (unknown [178.232.223.95])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id D0EC526058F;
	Sun, 30 Oct 2022 01:51:20 +0200 (CEST)
Message-ID: 
Date: Sun, 30 Oct 2022 01:51:15 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: morse(6) sound
Content-Language: en-US
To: Nuno Teixeira 
Cc: Diane Bruce , FreeBSD CURRENT 
References: 
 
 
 <106b05da-be44-ef6f-e2c8-0888ee71ed88@selasky.org>
 
 <10ff4875-c6bd-88a0-bf0d-7ae52106131e@selasky.org>
 
 
 
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4N0GQf74Q1z3qXf
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	TO_DN_ALL(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 10/30/22 00:05, Nuno Teixeira wrote:
> Considering that morse could use same beep dsp code, instead of
> repeating dsp code inside morse, why not use a dsp library or
> something so that morse could use it without duplicating code?
> 

If you figure out a good name for it. Not sure if it is worth a library ...

--HPS


From nobody Sun Oct 30 13:41:52 2022
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 4N0csF0LYpz4gwVJ
	for ; Sun, 30 Oct 2022 13:42:09 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N0csD0dMZz3mZ4
	for ; Sun, 30 Oct 2022 13:42:08 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-3691e040abaso86954757b3.9
        for ; Sun, 30 Oct 2022 06:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=FCkJrIICOnROTeHxjXvWQtJTGWEsUJJZpZzDKM+qSs0=;
        b=MIkw2QYDsaq8X74H/fZXxygCeqmNXH89R8MivP/LijNeyC9n7HKcuMLqSVvXMGVcDF
         Dj1qn03GwfcBSRVpISrOYjZbatragKxUBAAvoZPg/IBQndrWZIsSHEyk9cucRwr1qpz8
         GpLuYWYeOr3kdVKpK4Sbb30NN6vrMh5dNJqhOZHjKxnImGqL9++ej3bbh44Fh3hSiaxZ
         wFWAGz48vKsstPTB5TSGyHOltjvcXLMcjrU6Ho1We+E4SIE/mwy80FEFtR83fWhuYYcM
         XxcOacsBkRRDfc13/oVzu6ml45DHZHm12Beg/BzonX6rTbY4L0e8ywbgahxchl5boIOb
         Sqkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=FCkJrIICOnROTeHxjXvWQtJTGWEsUJJZpZzDKM+qSs0=;
        b=EH3+A6t2ddPuGJyJEOdM+F0Iis/ZRe/DmulYppphqiPmrn6KE5uh+yVnuTqZtkf39Y
         iRWEIApPf8vy8xjg/loCueInVIhtiMmZNQRm0iwUoTcX6l/AVsn3oSafW5fVlsmOOo85
         eDq6xM9h3v4M/x19pvY+51kkHzlLGlcWN7Iq2CqMX/w39jSBf4464XfliXNp+WpTEqva
         Ac6FkvI/b5PLNXyr6tJQu5sw4bmD2VajAk8Gq1bHt2YTQBk3RRX0FWdNrJWiiuQOVdDQ
         BVh052qySQCmcX6qxoq9Sx2t+KdYAj6HyYh73HLmajyzdi8I3bvbP42GGN9j7rltONG/
         wqwQ==
X-Gm-Message-State: ACrzQf0MG/U0LG7URMYxzM8x3xok86iIl3rizVEEDs6v1FUpxvp78saS
	l4V5nbjZSgt2UvgvURH10sYXB1EDkBPM1XjV6KUr+7RoC7w=
X-Google-Smtp-Source: AMsMyM6DvgKpT0m+lL/b6zqfuzjuwaPtDagEFDfCJoQWAkZ+ozn67JDdO+5qRKZnQWlDGInw6IBTuDQmIebdhQkfjko=
X-Received: by 2002:a81:9e09:0:b0:370:4458:7538 with SMTP id
 m9-20020a819e09000000b0037044587538mr5152516ywj.53.1667137325967; Sun, 30 Oct
 2022 06:42:05 -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: Archimedes Gaviola 
Date: Sun, 30 Oct 2022 21:41:52 +0800
Message-ID: 
Subject: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000001b2d2005ec40a86c"
X-Rspamd-Queue-Id: 4N0csD0dMZz3mZ4
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=MIkw2QYD;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::1134 as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com
X-Spamd-Result: default: False [-3.97 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.972];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1134:from];
	ARC_NA(0.00)[];
	TAGGED_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_NONE(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000001b2d2005ec40a86c
Content-Type: text/plain; charset="UTF-8"

Hi,

I am building a kernel and world in 14.0-CURRENT
https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221027-769b884e2e2-258837.img.xz
with Raspberry Pi 3B  (ARM kernel config file and in default system
configurations) and compilation breaks due to "failed to reclaim memory"
error as found in the dmesg.

pid 91224 (llvm-tblgen), jid 0, uid 0, was killed: failed to reclaim memory
pid 91131 (make), jid 0, uid 0, was killed: failed to reclaim memory

Here's the set of the build commands I invoked.

root@generic# cd /usr/src ; make KERNCONF=ARM TARGET_ARCH=aarch64
buildkernel buildworld installkernel installworld distribution
DESTDIR=/home/freebsd/rpi3b

Somewhere below, the error occurred.

llvm-tblgen -gen-asm-matcher  -I /usr/src/contrib/llvm-project/llvm/include
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-asm-writer  -I /usr/src/contrib/llvm-project/llvm/include
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-callingconv  -I /usr/src/contrib/llvm-project/llvm/include
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-compress-inst-emitter  -I
/usr/src/contrib/llvm-project/llvm/include -I
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-dag-isel  -I /usr/src/contrib/llvm-project/llvm/include -I
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
*** Signal 9

Stop.
make[5]: stopped in /usr/src/lib/clang
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** Error code 1

Stop.
make[2]: stopped in /usr/src
    30924.61 real     27331.99 user      2960.40 sys
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

While checking the error message, it is spotted at the
/usr/src/sys/vm/vm_pageout.c in the vm_pageout_oom() routine.
...
        if (bigproc != NULL) {
                switch (shortage) {
                case VM_OOM_MEM:
                        reason = "failed to reclaim memory";
                        break;
                case VM_OOM_MEM_PF:
                        reason = "a thread waited too long to allocate a
page";
                        break;
                case VM_OOM_SWAPZ:
                        reason = "out of swap space";
                        break;
                default:
                        panic("unknown OOM reason %d", shortage);
                }
                if (vm_panic_on_oom != 0 && --vm_panic_on_oom == 0)
                        panic("%s", reason);
                PROC_LOCK(bigproc);
                killproc(bigproc, reason);
                sched_nice(bigproc, PRIO_MIN);
                _PRELE(bigproc);
                PROC_UNLOCK(bigproc);
        }
...

Any thoughts? As I don't have any idea about VM pageout.

Thanks and best regards,
Archimedes

--0000000000001b2d2005ec40a86c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I am building=
 a kernel and world in 14.0-CURRENT https://download.freebsd.org/f=
tp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch=
64-RPI-20221027-769b884e2e2-258837.img.xz with Raspberry Pi 3B=C2=A0 (A=
RM kernel config file and in default system configurations) and compilation=
 breaks due to "failed to reclaim memory" error as found in the d=
mesg.

pid 91224 (llvm-tblgen), jid 0, uid 0, w=
as killed: failed to reclaim memory
pid 91131 (make), jid 0, uid 0, was =
killed: failed to reclaim memory



Here's the set of the build commands I invoked.

root@generic#
 cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64 buildkernel=20
buildworld installkernel installworld distribution=20
DESTDIR=3D/home/freebsd/rpi3b




Somewhere below, the error occurred.

llvm-tblgen -gen-asm-matcher =C2=A0-I /usr/src/contrib/llv=
m-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RIS=
CV =C2=A0-d RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc =C2=A0/usr/s=
rc/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-=
asm-writer =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/=
contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenAsmWriter.inc.d=
 -o RISCVGenAsmWriter.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Targ=
et/RISCV/RISCV.td
llvm-tblgen -gen-callingconv =C2=A0-I /usr/src/contrib=
/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target=
/RISCV =C2=A0-d RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc =C2=A0=
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen=
 -gen-compress-inst-emitter =C2=A0-I /usr/src/contrib/llvm-project/llvm/inc=
lude -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVG=
enCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc =C2=A0/usr/s=
rc/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-=
dag-isel =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/co=
ntrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenDAGISel.inc.d -o =
RISCVGenDAGISel.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RIS=
CV/RISCV.td
*** Signal 9

Stop.
make[5]: stopped in /usr/src/li=
b/clang
*** Error code 1

Stop.
make[4]: stopped in /usr/src/li=
b
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** E=
rror code 1

Stop.
make[2]: stopped in /usr/src
=C2=A0 =C2=A0 3=
0924.61 real =C2=A0 =C2=A0 27331.99 user =C2=A0 =C2=A0 =C2=A02960.40 sys*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error=
 code 1

Stop.
make: stopped in /usr/src

=
While checking the error message, it is spotted at the /usr/src/sys/vm/vm_p=
ageout.c in the vm_pageout_oom() routine.
...
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 if (bigproc !=3D NULL) {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 switch (shortage) {
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case VM_OOM_MEM:
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reason =
=3D "failed to reclaim memory";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case VM_OOM_MEM_PF:
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 reason =3D "a thread waited too long to allocate a page";<=
br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 case VM_OOM_SWAPZ:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reason =3D "out of swap space&q=
uot;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 default:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 panic("unknown OOM reason %d", sh=
ortage);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (vm_panic_on_oom=
 !=3D 0 && --vm_panic_on_oom =3D=3D 0)
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 panic("%s&=
quot;, reason);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
PROC_LOCK(bigproc);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 killproc(bigproc, reason);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 sched_nice(bigproc, PRIO_MIN);
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _PRELE(bigproc);
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PROC_UNLOCK(bigproc);
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 }
...

Any thoughts? As I don't have any idea about VM pageout.

Thanks and best regards,
Archimedes



=C2=A0


--0000000000001b2d2005ec40a86c--

From nobody Sun Oct 30 17:29:14 2022
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 4N0jvR0c4Gz4g7mJ
	for ; Sun, 30 Oct 2022 17:29:23 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.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 4N0jvP5QG5z3H2y
	for ; Sun, 30 Oct 2022 17:29:21 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667150959; bh=k4/KP5nnN1yxthG/j3zo2ei/9+lpR6C/bkJCEqSoDBM=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=fMpOUioiv3BmPRgjCwQiSkuaagcclFiMkq3zRrStYG392ZYKojv/Aref1HBqF1kw/cruo45BxmSUVWPhVV+yU6zR286zY0oiDp9PGYOISqCvKJjpgA6yYzSLu5uR+vdZykPQ1pp2V5eKVXAnANWWjm5tLR6pZH4vxlL7G/J527PuGLOwuWUBtYOhAqTzeU1tYdwI9ctk9mF6h/p5BIxEUXCsskH6Ui5cRSq1wRNmBECiZOXbkRcRIkYCTCevSQq8egDoSwDhdJDLMRssql5mPGMygK6TmIdAxcFF+46v3QlzD4NBcboJ7U45waTgDhobT69zdChf4aNfet01YoC12w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667150959; bh=cjk7Dnoio6F4GIBXq58Rq+OiwgPWEyj0gVOj54i/R+K=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ZVJTC3QsTW8xVVq6KbOUvVbPQG5rPQQdA4QDPXuzheqxpNU8tl7xPhFod9tLBjZpY6d9WwKK2DfWcck3ihYaxWWeHv/YRoMIykLaA+w3GKjSY0DsO87a1qnfXM+6glLLGOsClVRVnpEj4cAqwkURX+dg6JPkt9ZkiF6Hq9eSfgiyqe9A1UTydSEO+o/VIhjI55zg5U2+JanHvLBOpJkXMRkm2dr2cWj5Y7f00FfcwhSUDylVV8UWbELNkTCJUq5s6PEVvxXB1P1QhTQ/wCiQf0HS8E6AbhbIY+FUAjid0Jj1STigwG8LHQktXexm+JKVO6bkOzYeTvE/PJ7T28HGqQ==
X-YMail-OSG: KF6svGUVM1mp60HOrk4s8LkrjatDV.dz2K__c1xS8utOjwYd_5P_LOKJl0MgWDc
 U9sNVtwlYSCkGrTIwSPty8fFolirN3GuWEWMRQu3K1mqAr17EMAPWCXdq8hB7nPsGw4ind8lz9vk
 VJCX_Xkt2XTq.7wp3mEZEpvJ0ql7R7OWk7DtZ.g34s26fLbkvcf3gXlRpK4uTkr1f2Ok7aFcCut1
 KVKjJ5DMz_bjrnVUM7EhQzXCntWpYyx7YodzzPfZlz4lwLf60LB_qt8Jm2q9W4S7Q6YAglAcrd6v
 z63vnMHh9l5.S3a73ZOxH8xPgBS2SzkpiuGBR.wnDrYQo290S2ApcUDmYtVM02go09m4qc_7zcUJ
 i7XlP2b58VZkllSyJ9INDURJ8lDmx9GZ1QJYYbH3l8ZSKjbT4As4itJ8U_DcDMUUPlGhrh4JCMYY
 SPJT1eormexdT.QRwfsmGmHxqjUyMAf2DoffheW6OImeypqdlOhRgPfGanbV_f30tusnbEsL.yMI
 EJE_zcglXYOyqJ156MahERyq0eepML8XE2ZBgWel6WQb8kiMKvQjxWFoTzGnwmW9l5AHCKdzS7tF
 fqylivjrfVuGfGv2MHzBPQBXc0w0GTxkcw9SQJYckUZXMiZ.nraViVj5c5pc20aj4lFJVXc81EXo
 iF_9SUrOZoUkZ.0Mg90PBzQFEl_BeYmlku73DBPiXa0kibA.RkqjMQB6rt_Lf3bhnEIVnFttVKUL
 OD9rw_snVMDxU3bQPkXHT6EJvcuHAuZ7JU46DO0PBn_HRMcnKY1vGB.k0Jw9QsKFHcOlJGcJmVEQ
 a56tgph6abLAVY4iNwZ9UWmx.BWUHvA4VV3b.RYKiFdOFSj.V0zdItNOI6J61o02uLdw42ulET2n
 s7ypOGC7lawGs6WadWHE.2lAtLSwwziQpt2BN1jF5.e2n.BIFP_Z3F_rhB1rU4Oub3Q19t9NFE8_
 KzR3KC9vmcpKikhcQPDAiXUEeAjxVupekDYJGiDgwb1RWhy8vVGY1oODAOstz8AnwPvm011aru8D
 S6s5thDud0GDkwOkhu1bWy7gwPEEF9EtZdn3FmXBmeAyZYQ5oHWJa4MuDGZLfSsgt7fMiAoWlqEB
 4AdMIOmOVHj9q9fgETNly3vflZCrAl9jMGWYJ4bXEfzvUnIMHPIPjgZXACyaIkRkz4Va7pUrkK9b
 24479Pp9tkYJxKuiMGT_WF46D8YWNGAYuGP.n4z.kfHa3bmUcSHWIUX0snXTFsaQOqi635fVCWyS
 hx8SNi9v5LRGIEbCTVPOKZ6E0kxIPvcxcGD7jvvhrKBiBqA7x5nizCO.3prrz9zB8cWVotarcR9Q
 0tJLMDXOL1d9ly9AxjKWZy21oGa5NvpUXYuAj2m.YauTws9271emqA.MHYXRknMIIyY8W.mZxoq1
 yUO5F3o_6ZX03c71hG_xrcQZzv6oDGNA7BNEn4X_JeG77bwXR6AHWIFTJ0Nl71hwFhHIjIVyysOw
 s5jLL5o5yedmFgIxDq9fROYUhOw211U3tHrekArMJeJuVCQz6YIQR6fX08vrgBd7eznB099TbPjM
 yI3_wHfMKksltsxtnjVks0Ts_YyER.PTEp4YcGVtHjq61ceZl__SRYY.Iqhwpeasl7yYDn1sfuXX
 VS3bIa3AxghU3Wz1nqv2RJ_cTOx_oocshM3f8ipFoB7_bz9_9J6VqaJTiGCVxh7MOqIvmXxTwUh.
 xH2s1ivx10Va_MWUAbSuTGhbGia9XjUwmQCbCoQKmPbOJLUR_9W7ORUgTs3EPbGAEBLxzMParaBf
 coveZ6C8kqh7Fjlm0_bSHucpJWvMEXv_uYCtdI_5ekgWVP3Hwpxm0Nh_oPb_vYfPsg8wReZMqJnJ
 swYgf9eIQDY9pZm2kyd1zX6KXXPi31sGVbzH9GYWfeyOSKujuilzAldGT9VIpmIo.lxRDqfXSJVB
 DPztuGwSdgQWXHYiWD.o_dRdrQDM3P8agWr8W_AF2QS8xj7a_BxE79K16iRlQLe361_d5hlGWzkg
 RwMGhwkaAHSz6SraoEjQGr8bbwJVdUTXUF__0GgTiMtQiSkWnt19LXAy2nwibkffnJRttFMxJpDE
 2Q0WjLtrZlAhFlSfyyRYA9c1aYDP2E3YLXVjps5Wz7qnDqtP7B3lTU8zD_I6_hPUkfNY8OsdzDz1
 i.BF71meDgY92BacEveNFvNDUepKdAwY9A1mQYdVFCwSFfCcJcnzGb5UHYnCpyZhJ_FivCegVgB7
 UBEFRYFN1WMYs3ZrnGxl.QOgPiXoza9yhUelhvonro.E40XxjLtbczO0c.SkodtayhFqt
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 Oct 2022 17:29:19 +0000
Received: by hermes--production-ne1-c47ffd5f5-8txkx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5672d07759705c3261dfab12ce59b9b3;
          Sun, 30 Oct 2022 17:29:17 +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 \(3696.120.41.1.1\))
Subject: RE: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
Message-Id: <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
Date: Sun, 30 Oct 2022 10:29:14 -0700
To: Archimedes Gaviola ,
 freebsd-current 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
X-Rspamd-Queue-Id: 4N0jvP5QG5z3H2y
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=fMpOUioi;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TAGGED_RCPT(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Archimedes Gaviola wrote on
Date: Sun, 30 Oct 2022 13:41:52 UTC :

> I am building a kernel and world in 14.0-CURRENT
> =
https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/F=
reeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221027-769b884e2e2-258837.img.xz
> with Raspberry Pi 3B  (ARM kernel config file and in default system
> configurations) and compilation breaks due to "failed to reclaim =
memory"
> error as found in the dmesg.
>=20
> pid 91224 (llvm-tblgen), jid 0, uid 0, was killed: failed to reclaim =
memory
> pid 91131 (make), jid 0, uid 0, was killed: failed to reclaim memory
>=20
> Here's the set of the build commands I invoked.
>=20
> root@generic# cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64
> buildkernel buildworld installkernel installworld distribution
> DESTDIR=3D/home/freebsd/rpi3b
>=20
> . . .
>=20
> Any thoughts? As I don't have any idea about VM pageout.

Multiple configuration things from what I use:

I use a swap partition (not a swap file!) to give the system
someplace to put copies of inactive memory pages (paging):

# swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/gpt/Rock64swp2   3670016        0  3670016     0%

where gpart show -p lists it as (a gpt context, not MBR):

      534528     7340032  da0p2  freebsd-swap  (3.5G)

and gpart show -pl lists it as:

      534528     7340032  da0p2  Rock64swp2  (3.5G)

(Note: swap file usage is subject to deadlock conditions
avoided by use of swap partitions.)

I use a serial console & ssh session only context to avoid
having sizable competition for RAM.

I avoid using tmpfs because it competes for RAM use.

I use the likes of ( in, say, /boot/loader/conf ):

#
# Delay when persistent low free RAM leads to
# Out Of Memory killing of processes:
vm.pageout_oom_seq=3D120

This delays potential "killed: failed to reclaim memory" kills,
possibly long enough to reach a state where sufficient memory is
reclaimed.

I'll note that the status "killed: failed to reclaim memory" does
not require that swap be used much at all. Sustained low free RAM
from just one process that always stays runnable and has a
sufficiently large active set of pages can be sufficient to end up
with such kills. Having swap allows for inactive pages to get out
of the way, which can help.

I use the likes of ( in, say, /etc/ssyctl.conf ):

#
# Together this pair avoids swapping out the process kernel stacks.
# This avoids processes for interacting with the system from being
# hung-up.
vm.swap_enabled=3D0
vm.swap_idle_enabled=3D0

This allows paging to the swap space but disallows moving
kernel thread stacks to the swap space. Otherwise the
processes used to interact with the RPi3 can become
non-runnable, preventing such interactions.

I have NVMe or SSD based USB media, not microsd cards nor
spinning rust. (I use just bootcode.bin and timeout files
on microsd media for the RPi3B. Even the rest of the RPi*
firmware is on the USB media, as well as u-boot.bin .)

My usage of such a configuration struture for building
software (world, kernel, ports) applies to all the
systems I do such with, including ones with a lot more
resources, including a lot more RAM.

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


From nobody Sun Oct 30 21:50:23 2022
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 4N0qhg23lQz4ghY1
	for ; Sun, 30 Oct 2022 21:50:27 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N0qhf4SjKz3y0h;
	Sun, 30 Oct 2022 21:50:26 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250])
	by cmsmtp with ESMTP
	id pD6CovB3XSp39pGCHooZRZ; Sun, 30 Oct 2022 21:50:25 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id pGCGoUiQjzeTTpGCHoDFkv; Sun, 30 Oct 2022 21:50:25 +0000
X-Authority-Analysis: v=2.4 cv=EY/b/dqC c=1 sm=1 tr=0 ts=635ef1a1
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=kj9zAlcOel0A:10 a=Qawa6l4ZSaYA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8
 a=EkcXrb_YAAAA:8 a=LtdyHnDGqpg16XKaWCEA:9 a=CjuIK1q_8ugA:10
 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id 7717B4B0;
	Sun, 30 Oct 2022 14:50:23 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id 3884B1B4; Sun, 30 Oct 2022 14:50:23 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Nuno Teixeira 
cc: FreeBSD CURRENT 
Subject: Re: morse(6) sound
In-reply-to: 
References: 
Comments: In-reply-to Nuno Teixeira 
   message dated "Fri, 28 Oct 2022 19:36:02 +0100."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 30 Oct 2022 14:50:23 -0700
Message-Id: <20221030215023.3884B1B4@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfJ5W5m7m5t413gVuHwb1k2Oc7YRlF7yoSBBiEgH2p9Mt5TDrBuXcO1vpSL3NaXr1SJ3Aj9t/EqK58xM6PakyBYwRyqI0Mc1o8IjS5niKiqb7XeJ41RcI
 OE8Fz773LME0s4826Q6UJReOTuT+Nr3BE5SnOUq0iUeS391YCK+qQca/ToI1akB8R9GZuE05jbtXSOr6aIJBfUbGBvHOYbcUOnyI0E7BpDpta6RVtiH+OT+A
 o9GEI+fB/qm3GxsSszie4Q==
X-Rspamd-Queue-Id: 4N0qhf4SjKz3y0h
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[3.97.99.33:from];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	ARC_NA(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	REPLYTO_EQ_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message 
, Nuno Teixeira writes:
> Hello all,
>
> Is there any way to get sound from morse(6) without speaker(4) device?

My question is, why is this still in base? Shouldn't it be a port? I don't 
think this software is of interest to the majority of FreeBSD users out 
there and would be a perfect candidate for migration to ports.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  https://FreeBSD.org
NTP:               Web:  https://nwtime.org

			e^(i*pi)+1=0



From nobody Mon Oct 31 02:47:30 2022
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 4N0yHk5gwMz4gM7n
	for ; Mon, 31 Oct 2022 02:47:46 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N0yHj5XDnz3WrV
	for ; Mon, 31 Oct 2022 02:47:45 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-yb1-xb31.google.com with SMTP id t186so12271979yba.12
        for ; Sun, 30 Oct 2022 19:47:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=p7l8Efk32oBX1iIXeoXC2IWvtD4FZPnN75TdimjE25E=;
        b=f7wlfwu4Z8vc3sKehG3QjA1FdriZAvyDFZzdZr4ncpLyl68BmLM1HX773T38nSZj5f
         85E4uc9U0iCE31xW4KUiwIu0nwjbgAuX5lWc9HSaszLPkk+z9oaEJaTa/ks38ZQT1n2A
         XEWk138YUeayuabZf3TA+TzR6BZpMxFyVFJ/PBjEGj25MfdpwUOhJL6lyFoE5IDvPn9G
         lEDEDZ1XGjshrKIHTMS3XGNKYrr58Rb+24LzizORRVqHssfOoHhxHFUzAw3IJr3p40yj
         1D4kKFpERi0nsJy9ogRd66YfHeEzX/5eVpsND+3nDPklyCCQjDfpuUCNbxPrbXcGbfJN
         Dxmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=p7l8Efk32oBX1iIXeoXC2IWvtD4FZPnN75TdimjE25E=;
        b=BDGeE1ECGrs6YvZXzn9934KVel7RV0pcOFG2TrZINgKzHr8zh912+NdjIZncBisq5q
         Xv2uMWSqumLvLPZIiSlbdXbGLuHBYaqFnKUP1pHPqRLdIJ1cnO+BZrTpwmco2KemGWGi
         +Q+cZmgaCkD1bPYhXwSIFB0xw3xsFtIxZOKpxFsyUJqBjnTUhkXHpuK9IFv6FcYBp3YT
         PIxLg5nzJyVnRSon49Heelh30/nNsJEK3x3J++oc3u2xQYE2tK9i4Y4RjX4obJx5zy7+
         ytQ8uOVDxMvFHelPing0Iov5qQ7rUuRIPaH39px59A4+/tQ31qRN5Medu7its/XGr+X+
         hvUQ==
X-Gm-Message-State: ACrzQf2s4F+n/S4fyzjePCTJ4bIaWAjK7+/RKX68o9hf5XuMsflAwbS6
	MeMA7DGnu/zdbKzr4Pual1cmFtO0lMCotMMvuEuPpIQaFBA=
X-Google-Smtp-Source: AMsMyM5t1VJXVCIdGoo+xr1zRw8W+PeXalNN+E2//zsh5gWiqO/nldTyxhWCycCXygWz8maEIVvxJMKnWvg1Q6QAKwU=
X-Received: by 2002:a25:6412:0:b0:6cc:6507:bfae with SMTP id
 y18-20020a256412000000b006cc6507bfaemr7008539ybb.537.1667184464366; Sun, 30
 Oct 2022 19:47:44 -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: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com> <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
In-Reply-To: <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
From: Archimedes Gaviola 
Date: Mon, 31 Oct 2022 10:47:30 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Mark Millard 
Cc: freebsd-current 
Content-Type: multipart/alternative; boundary="000000000000c615c905ec4ba1e6"
X-Rspamd-Queue-Id: 4N0yHj5XDnz3WrV
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=f7wlfwu4;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com
X-Spamd-Result: default: False [-3.55 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	NEURAL_HAM_MEDIUM(-0.55)[-0.551];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b31:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TAGGED_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000c615c905ec4ba1e6
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 31, 2022 at 1:29 AM Mark Millard  wrote:

> Archimedes Gaviola wrote on
> Date: Sun, 30 Oct 2022 13:41:52 UTC :
>
> > I am building a kernel and world in 14.0-CURRENT
> >
> https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221027-769b884e2e2-258837.img.xz
> > with Raspberry Pi 3B  (ARM kernel config file and in default system
> > configurations) and compilation breaks due to "failed to reclaim memory"
> > error as found in the dmesg.
> >
> > pid 91224 (llvm-tblgen), jid 0, uid 0, was killed: failed to reclaim
> memory
> > pid 91131 (make), jid 0, uid 0, was killed: failed to reclaim memory
> >
> > Here's the set of the build commands I invoked.
> >
> > root@generic# cd /usr/src ; make KERNCONF=ARM TARGET_ARCH=aarch64
> > buildkernel buildworld installkernel installworld distribution
> > DESTDIR=/home/freebsd/rpi3b
> >
> > . . .
> >
> > Any thoughts? As I don't have any idea about VM pageout.
>

Hi Mark,


>
> Multiple configuration things from what I use:
>
> I use a swap partition (not a swap file!) to give the system
> someplace to put copies of inactive memory pages (paging):
>
> # swapinfo
> Device          1K-blocks     Used    Avail Capacity
> /dev/gpt/Rock64swp2   3670016        0  3670016     0%
>

Oh I see, there's no swap partition in the default installation.

root@generic:~ # swapinfo
Device          1K-blocks     Used    Avail Capacity

root@generic:~ # top -S
last pid: 92429;  load averages:  0.00,  0.00,  0.00
                                    up 1+12:49:11  23:41:10
52 processes:  2 running, 48 sleeping, 2 waiting
CPU:  0.0% user,  0.0% nice,  0.6% system,  0.0% interrupt, 99.4% idle
Mem: 2000K Active, 626M Inact, 223M Wired, 97M Buf, 20M Free

Let me try to create a swap partition. Let me mount a spare USB flash drive
for swap as during the installation all my microSD card storage was
allocated in the root filesystem with growfs.


>
> where gpart show -p lists it as (a gpt context, not MBR):
>
>       534528     7340032  da0p2  freebsd-swap  (3.5G)
>
> and gpart show -pl lists it as:
>
>       534528     7340032  da0p2  Rock64swp2  (3.5G)
>

Okay noted on GPT not MBR method with gpart. By the way, what's the proper
allocation size of swap in FreeBSD? This RPi 3B has 1GB of RAM (~947 MB),
do I need to set twice the capacity of this physical RAM?


>
> (Note: swap file usage is subject to deadlock conditions
> avoided by use of swap partitions.)
>

This is noted.


>
> I use a serial console & ssh session only context to avoid
> having sizable competition for RAM.
>
> I avoid using tmpfs because it competes for RAM use.
>
> I use the likes of ( in, say, /boot/loader/conf ):
>
> #
> # Delay when persistent low free RAM leads to
> # Out Of Memory killing of processes:
> vm.pageout_oom_seq=120
>
> This delays potential "killed: failed to reclaim memory" kills,
> possibly long enough to reach a state where sufficient memory is
> reclaimed.
>

Alright this is well noted too.


>
> I'll note that the status "killed: failed to reclaim memory" does
> not require that swap be used much at all. Sustained low free RAM
> from just one process that always stays runnable and has a
> sufficiently large active set of pages can be sufficient to end up
> with such kills. Having swap allows for inactive pages to get out
> of the way, which can help.
>
> I use the likes of ( in, say, /etc/ssyctl.conf ):
>
> #
> # Together this pair avoids swapping out the process kernel stacks.
> # This avoids processes for interacting with the system from being
> # hung-up.
> vm.swap_enabled=0
> vm.swap_idle_enabled=0
>
> This allows paging to the swap space but disallows moving
> kernel thread stacks to the swap space. Otherwise the
> processes used to interact with the RPi3 can become
> non-runnable, preventing such interactions.
>

Okay this too is well noted.


>
> I have NVMe or SSD based USB media, not microsd cards nor
> spinning rust. (I use just bootcode.bin and timeout files
> on microsd media for the RPi3B. Even the rest of the RPi*
> firmware is on the USB media, as well as u-boot.bin .)
>
> My usage of such a configuration struture for building
> software (world, kernel, ports) applies to all the
> systems I do such with, including ones with a lot more
> resources, including a lot more RAM.
>

Thanks for these inputs, noted on these things! I haven't tried NVMe and
SSD media in my RPi 3B. So, they are far more superior as compared to
microSD cards when it comes to building software?

Thanks and best regards,
Archimedes

--000000000000c615c905ec4ba1e6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Oct 31, 2022 at 1:29 AM Mark =
Millard <marklmi@yahoo.com> =
wrote:
Archimede=
s Gaviola <archimedes.gaviola_at_gmail.com>wrote on<=
br>
Date: Sun, 30 Oct 2022 13:41:52 UTC :



> I am building a kernel and world in 14.0-CURRENT

> https://download.freebsd=
.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64=
-aarch64-RPI-20221027-769b884e2e2-258837.img.xz

> with Raspberry Pi 3B=C2=A0 (ARM kernel config file and in default syst=
em

> configurations) and compilation breaks due to "failed to reclaim =
memory"

> error as found in the dmesg.

> 

> pid 91224 (llvm-tblgen), jid 0, uid 0, was killed: failed to reclaim m=
emory

> pid 91131 (make), jid 0, uid 0, was killed: failed to reclaim memory
> 

> Here's the set of the build commands I invoked.

> 

> root@generic# cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64<=
br>
> buildkernel buildworld installkernel installworld distribution

> DESTDIR=3D/home/freebsd/rpi3b

> 

> . . .

> 

> Any thoughts? As I don't have any idea about VM pageout.

Hi Mark,
=C2=A0



Multiple configuration things from what I use:



I use a swap partition (not a swap file!) to give the system

someplace to put copies of inactive memory pages (paging):



# swapinfo

Device=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1K-blocks=C2=A0 =C2=A0 =C2=A0Used=
=C2=A0 =C2=A0 Avail Capacity

/dev/gpt/Rock64swp2=C2=A0 =C2=A03670016=C2=A0 =C2=A0 =C2=A0 =C2=A0 0=C2=A0 =
3670016=C2=A0 =C2=A0 =C2=A00%

Oh I see,=
 there's no swap partition in the default installation.

<=
/div>
root@generic:~ # swapinfo
Device =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A01K-blocks =C2=A0 =C2=A0 Used =C2=A0 =C2=A0Avail Capacity

root@=
generic:~ # top -S
last pid: 92429; =C2=A0load averages: =C2=A00.00, =C2=
=A00.00, =C2=A00.00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u=
p 1+12:49:11 =C2=A023:41:10
52 processes: =C2=A02 running, 48 sleeping, =
2 waiting
CPU: =C2=A00.0% user, =C2=A00.0% nice, =C2=A00.6% system, =C2=
=A00.0% interrupt, 99.4% idle
Mem: 2000K Active, 626M Inact, 223M Wired,=
 97M Buf, 20M Free

Let me try to create a swap par=
tition. Let me mount a spare USB flash drive for swap as during the install=
ation all my microSD card storage was allocated in the root filesystem with=
 growfs.=C2=A0 
=C2=A0 



where gpart show -p lists it as (a gpt context, not MBR):



=C2=A0 =C2=A0 =C2=A0 534528=C2=A0 =C2=A0 =C2=A07340032=C2=A0 da0p2=C2=A0 fr=
eebsd-swap=C2=A0 (3.5G)



and gpart show -pl lists it as:



=C2=A0 =C2=A0 =C2=A0 534528=C2=A0 =C2=A0 =C2=A07340032=C2=A0 da0p2=C2=A0 Ro=
ck64swp2=C2=A0 (3.5G)

Okay noted on GPT=
 not MBR method with gpart. By the way, what's the proper allocation si=
ze of swap in FreeBSD? This RPi 3B has 1GB of RAM (~947 MB), do I need to s=
et twice the capacity of this physical RAM?
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">


(Note: swap file usage is subject to deadlock conditions

avoided by use of swap partitions.)

Thi=
s is noted.
=C2=A0



I use a serial console & ssh session only context to avoid

having sizable competition for RAM.



I avoid using tmpfs because it competes for RAM use.



I use the likes of ( in, say, /boot/loader/conf ):



#

# Delay when persistent low free RAM leads to

# Out Of Memory killing of processes:

vm.pageout_oom_seq=3D120



This delays potential "killed: failed to reclaim memory" kills,
possibly long enough to reach a state where sufficient memory is

reclaimed.

Alright this is well noted t=
oo.
=C2=A0



I'll note that the status "killed: failed to reclaim memory" =
does

not require that swap be used much at all. Sustained low free RAM

from just one process that always stays runnable and has a

sufficiently large active set of pages can be sufficient to end up

with such kills. Having swap allows for inactive pages to get out

of the way, which can help.



I use the likes of ( in, say, /etc/ssyctl.conf ):



#

# Together this pair avoids swapping out the process kernel stacks.

# This avoids processes for interacting with the system from being

# hung-up.

vm.swap_enabled=3D0

vm.swap_idle_enabled=3D0



This allows paging to the swap space but disallows moving

kernel thread stacks to the swap space. Otherwise the

processes used to interact with the RPi3 can become

non-runnable, preventing such interactions.

=

Okay this too is well noted.
=C2=A0



I have NVMe or SSD based USB media, not microsd cards nor

spinning rust. (I use just bootcode.bin and timeout files

on microsd media for the RPi3B. Even the rest of the RPi*

firmware is on the USB media, as well as u-boot.bin .)



My usage of such a configuration struture for building

software (world, kernel, ports) applies to all the

systems I do such with, including ones with a lot more

resources, including a lot more RAM.

Th=
anks for these inputs, noted on these things! I haven't tried NVMe and =
SSD media in my RPi 3B. So, they are far more superior as compared to micro=
SD cards when it comes to building software?

Thanks and best regards,
Archimedes


--000000000000c615c905ec4ba1e6--

From nobody Mon Oct 31 04:00:27 2022
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 4N0zvn1MnQz4gWWZ
	for ; Mon, 31 Oct 2022 04:00:37 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N0zvm1HGdz3fxL
	for ; Mon, 31 Oct 2022 04:00:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667188833; bh=gO8i94fL/mZOFPBAHsIX5/VS+v2UJDADNVxb6T9ku5I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TBYbEUnnYBP0LGKpCeNbymKjY+pQeVLy/hGYBq5PzPgvS4tdgae0l5ZLlqSOj+LxKr+A9YU0SUiCaAMfvdJUOX06AEM0RDyFr6cpD2whv6gRX2J+O+QMNVLkUvEShzLKGeCrIkWI8cJaShreBeQURKPK5zp7F11F2Z2z7VX+fCaR/+RNh3xh3OioTCCQAyit3SWwUQgo4SFhSs18Be13UNe4kpQf/k776NJoCwPFQWvLkxJXON2d8uica2fFegAN2BI1Dzh5o8aopGMKQMPSdfwe/yQu95KX6V+Z7YuzJcah6fTq9FohgKwVggdt6TxOGeJGn4VHNjQQ9x6TWxO6mQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667188833; bh=w5icg3IJWlJv+w/yU4ltfFDXHI+eM7QHGzyetIxcHAt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nMI7aDGB9JmoO93EnQvt3Cf6bcXDZdLdJ2D08+qh7eco7Sv3idMkHq1oy0VCRUh19HVASVO3XskHf2MoY8ZxUo7KRLKokGVGnavfvMQYQTZG8mq8bPliwDrHyeg2PKwIVeyQTzmJez+sv4/npymeshDkJbS2VPsqQHVK5dSgQfViyIPAY2Ieekk5nmx/Pxri/BxfCRlla6Rv4MG9UohbkCRg5sZqtwfCqEdkr+im0iHmJFq8dAAD88wDMAQ6SJ89lfYVGpoY9jqrV1iKHM+7czVkGECXCXeQC7drb9CAkoaSm1J2ybAIXbhJ9VFOnmuTmqOCi1bNdYn3fc2DN6JRCA==
X-YMail-OSG: ZXHUv0IVM1kyT8Fkd3pBZ98kmjvCvU2_vckBeh98RRHo_61yFJfdfwsm6Z9ut_c
 owA0xnTNMn5NkrFbMh8ETMA3QB3HSYtMdj12RKqHIOFukKGP2ZpCQvt1JHfkctRCTOCwvCXXiLgi
 q71U9pXXoHeV8guP5u5Tt1vGH..mzFMhlgRshPbbJsWMESquzYO_UIV7gq8oFhHrlzHNkyARmmRS
 IwcOixqwxjVaUA9DhkBY78li58FFApv3vym5E9mh1tfZUdfOq4y4UiZIVZvBYdVZE3F6_QlGHMHR
 b6hfcvpj_TEKp_kfmqztVqR4s4tyNECvlFIMXqB.Ajd1fH1K6AppE1Qk4ptg2RzM_uBsuj6ubId_
 4ZwFGPoSpHvaFu99HuavCKIYw40L583Wu9FS1Ry89qW_EorHgAVr4sdBEKhp7pgDEk2tPydLwKbg
 pkTvxYvOWFd9n3Im73CGjzRgQFPTsV3yCngqoi0EXrupq3lcZu7foaQZj_9RItORP7EYW2P4hN5H
 pyhMt48CEKACD_b_SH5UzL5C7wBY.uAsShfsUPGrBrllVuFpg_7UpwfOjV4N01AL_sr_Jng0uh2A
 j3BEJJo1gmcn8CMH9G2G4repsASkCTkaDhsHRWzWwIUBEfse2eE32hSJA5JBAoPkRv2mOVbSh3MG
 pkX9NUZEJVdFq_FSHlgZiW5PW8mG.WgJZDm97CQdlORYjOjcm1MZs35tnryxzx3A1mlXV35Vmtbz
 l.cikA0seibnI5Hc5OcR6C0RFS76OlXLd0sg2PkWiAXDxhMElF9uUZeACOPwP1XPAkmSqu3gYfqy
 fy3p0Wf6ImQXuF4nhGS3QB6Xl0VmfoOo2bGiFmjgcuRIgwpJRhZOhXGkb3AlM9B4us96v1kEBje1
 BDGGOjoOHuo9FCj1kZDgHo6bN_2BzsqJDVchbNWUkSLx4QoiksRbWNR36v4mkzZqC99Xosb0Gy6b
 I8KO7lRkL5cUyrDhr.Wn_sUBVT.tYkfdVJ3syWIsYyYj2cTLyZydOdIrgvjNqGGUiAgd03d3huwt
 XMumSHizzBkCgvYqAM1OxF8odSuC1dg1ZEv_Zr.qzSHsmQ4OkC_AhdBkocT03g9Ee0ewzZi55BH2
 mySnWEhMy_ADFNPirO5SZ.YcZNTHfcGXhpbErUxOoFrN3.Hxyxglz47o3ZkrtqNKt6_HrRwDbwti
 b6UOdkeKL4KoQ0bcMctIZM2iIxeJoNRtEDPRdOjv1wGb6o7XqWVx1IutzA0uJRw297kZSWX6.82i
 uh1snz2JK0GAAH7W5uN2W1TUH24QfGzOhJfCcwWMqokUuRcA_mK6PX.fzZvJY_A6zvNxbP7XOlh6
 QPg00hk_Bxwh5.QOzuNpNFSXSkpMaautaGGviuElaOyrR3YrdmRVUixd1NrvMo10jtvDhbNpN1Rq
 7mE0RWk7QczEaY0G2Bz_7iXJWmCnG8cZhDXCEOEHMWK7Q5BB3AdpIVi9b4U2B0b0lGZTtTUjSSZz
 C_qRRHL9PvWqr9P.Xe.OdKXfjWD8gVLmLagRHVbNx8Rgf_XRrOa82fHNZ2BiWem584rtALd1uBuj
 c7GKZ19o_aapG8hON_07DBSmHsREDaDPVGlta6A9Lj0HMv3VY.epKtvLHqkRrE2UPouJ5bp8odbg
 AC_7FqbiYhENL6K7CIVF5mFX57ffuCf5owdPm6VaNHydxZQk1QKxAb3KqjA6w3LVmKlnJR2lN.B7
 HruIW2iJDSA_5Wxgp.NuAR4ioSUZqRXUcZdqEP9qPXnwFHIp_YCSseTt5KG7zow_OyrPg5CGKlPX
 rCQYK2PNvm4LoTGqXJ5N0asGwv.GowK8.qBDVZD5mEnuCat1X6FdEE6L5afRhGXDaAUaLbZuZAm4
 JU2Iib5xHIQg1YnfcFaEgnXn_0eV2Wo63bs6T1memfpnG2wC0whCoxLTb22O70ps.ic1I2Anzrq9
 Dra2Sgmcji_Z7Ni5PzsnJ_enHQcOZHJ4O.OIcF82QM0lxPS4IRZQEU1KzKaEDGaUT8bzPd7nLc2J
 xYKyGuP3M7Pn37Nx3S_HpQlBn93xP3DgF52V9yUtx7TXaWBFkSUeeH3WWUyFCtK5DHD7J48qplNV
 wETC8_mipmUa1F18cepvQh2GiqePtTNHRY0tbrVke5B7Y.nPtWnVVOpdJhmzhKjZfIhzHI8.bHgb
 M22lXZkguZRsOH9E06nd8hNEC3yFhnZqXc4rmNMGTc2lwnSBq16ebU9WqouZwkOd6YNt92HXsmj7
 WsTit6IGQ5LvGKwO1SO4CkXnAYjXsyUvKkq5ceJLcf3FqXzDH2JyIGKGeKo4qq_K.411yp3ZcVC6
 QM_o-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 31 Oct 2022 04:00:33 +0000
Received: by hermes--production-ne1-c47ffd5f5-cr29n (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fea0a44a9000fcdcbb4fde1f4cb12275;
          Mon, 31 Oct 2022 04:00:30 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
From: Mark Millard 
In-Reply-To: 
Date: Sun, 30 Oct 2022 21:00:27 -0700
Cc: freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N0zvm1HGdz3fxL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=TBYbEUnn;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TAGGED_RCPT(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_TO(0.00)[gmail.com];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-30, at 19:47, Archimedes Gaviola =
 wrote:

> On Mon, Oct 31, 2022 at 1:29 AM Mark Millard  =
wrote:
> Archimedes Gaviola wrote on
> Date: Sun, 30 Oct 2022 13:41:52 UTC :
>=20
> > I am building a kernel and world in 14.0-CURRENT
> > =
https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/F=
reeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221027-769b884e2e2-258837.img.xz
> > with Raspberry Pi 3B  (ARM kernel config file and in default system
> > configurations) and compilation breaks due to "failed to reclaim =
memory"
> > error as found in the dmesg.
> >=20
> > pid 91224 (llvm-tblgen), jid 0, uid 0, was killed: failed to reclaim =
memory
> > pid 91131 (make), jid 0, uid 0, was killed: failed to reclaim memory
> >=20
> > Here's the set of the build commands I invoked.
> >=20
> > root@generic# cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64
> > buildkernel buildworld installkernel installworld distribution
> > DESTDIR=3D/home/freebsd/rpi3b
> >=20
> > . . .
> >=20
> > Any thoughts? As I don't have any idea about VM pageout.
>=20
> Hi Mark,
> =20
>=20
> Multiple configuration things from what I use:
>=20
> I use a swap partition (not a swap file!) to give the system
> someplace to put copies of inactive memory pages (paging):
>=20
> # swapinfo
> Device          1K-blocks     Used    Avail Capacity
> /dev/gpt/Rock64swp2   3670016        0  3670016     0%
>=20
> Oh I see, there's no swap partition in the default installation.
>=20
> root@generic:~ # swapinfo
> Device          1K-blocks     Used    Avail Capacity
>=20
> root@generic:~ # top -S
> last pid: 92429;  load averages:  0.00,  0.00,  0.00                   =
                                        up 1+12:49:11  23:41:10
> 52 processes:  2 running, 48 sleeping, 2 waiting
> CPU:  0.0% user,  0.0% nice,  0.6% system,  0.0% interrupt, 99.4% idle
> Mem: 2000K Active, 626M Inact, 223M Wired, 97M Buf, 20M Free
>=20
> Let me try to create a swap partition. Let me mount a spare USB flash =
drive for swap as during the installation all my microSD card storage =
was allocated in the root filesystem with growfs. =20
>  =20
>=20
> where gpart show -p lists it as (a gpt context, not MBR):
>=20
>       534528     7340032  da0p2  freebsd-swap  (3.5G)
>=20
> and gpart show -pl lists it as:
>=20
>       534528     7340032  da0p2  Rock64swp2  (3.5G)
>=20
> Okay noted on GPT not MBR method with gpart.

I did not happen to have a MBR example around. So I could
only show GPT. The note was more to avoid confusion than
anything, since the two are not equivalent for how they
work.

> By the way, what's the proper allocation size of swap in FreeBSD?

FreeBSD has a waring that it produces indicating possible mistuning
when you potentially have too much. An example is:

warning: total configured swap (2097152 pages) exceeds maximum =
recommended amount (916632 pages).
warning: increase kern.maxswzone or reduce amount of swap.

The numbers are dependent on the amount of RAM present and
other details.

My understanding is that increasing kern.maxswzone has tradeoffs.
I avoid getting the message because I do not understand the
tradeoffs or how to manage the tradeoffs or even how to identify
an instance of hitting such a tradeoff.

For aarch64 I've been about to have swap of about 3.4 to 3.5 or
so times the amount of RAM without getting the warnings. That
is why 3.5G in my RPi3B example. (So RAM+SWAP approx.=3D 4.5*RAM.)
(armv7 only allows more like 1.8 times the RAM before getting
the warning.)

I avoid even getting too close to the warning as there seems to
be some build-to-build variability in what fits vs. not. This
avoids having to frequently adjust the size.

Going from the other side, how much RAM+SWAP will your activities
use? To avoid accurately figuring out such, you may just want to
have near the 3.4 to 3.5 times RAM. (There have been times when
clang had memory use oddities that required more than normal for
a time, for example.)

> This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the =
capacity of this physical RAM?

Ultimately your choice. How much parallel activity you
want to attempt likely contributes. If you build ports,
you might do so in a way that uses more RAM+SWAP than
system builds do, for example.

> (Note: swap file usage is subject to deadlock conditions
> avoided by use of swap partitions.)
>=20
> This is noted.
> =20
>=20
> I use a serial console & ssh session only context to avoid
> having sizable competition for RAM.
>=20
> I avoid using tmpfs because it competes for RAM use.
>=20
> I use the likes of ( in, say, /boot/loader/conf ):
>=20
> #
> # Delay when persistent low free RAM leads to
> # Out Of Memory killing of processes:
> vm.pageout_oom_seq=3D120
>=20
> This delays potential "killed: failed to reclaim memory" kills,
> possibly long enough to reach a state where sufficient memory is
> reclaimed.
>=20
> Alright this is well noted too.

There is tuning related to "a thread waited too long to
allocate a page" that happens because of paging I/O
characteristics. But but I've not hit that type of
error.

I'll also note that the "out of swap space" case is a
misnomer in that it is one or two of 2 internal data
structures that is out of space, not necessarily the
swap space on the media. Again, I've not ever hit that
type of error. I'm not aware of tuning for this case.

> I'll note that the status "killed: failed to reclaim memory" does
> not require that swap be used much at all. Sustained low free RAM
> from just one process that always stays runnable and has a
> sufficiently large active set of pages can be sufficient to end up
> with such kills. Having swap allows for inactive pages to get out
> of the way, which can help.
>=20
> I use the likes of ( in, say, /etc/ssyctl.conf ):
>=20
> #
> # Together this pair avoids swapping out the process kernel stacks.
> # This avoids processes for interacting with the system from being
> # hung-up.
> vm.swap_enabled=3D0
> vm.swap_idle_enabled=3D0
>=20
> This allows paging to the swap space but disallows moving
> kernel thread stacks to the swap space. Otherwise the
> processes used to interact with the RPi3 can become
> non-runnable, preventing such interactions.
>=20
> Okay this too is well noted.
> =20
>=20
> I have NVMe or SSD based USB media, not microsd cards nor
> spinning rust. (I use just bootcode.bin and timeout files
> on microsd media for the RPi3B. Even the rest of the RPi*
> firmware is on the USB media, as well as u-boot.bin .)

This may contribute to why I've never gotten a "a thread
waited too long to allocate a page" on any system. (Some
systems, while bootable via USB3 media I have, also have
have even faster internal media that is normally used.)

> My usage of such a configuration struture for building
> software (world, kernel, ports) applies to all the
> systems I do such with, including ones with a lot more
> resources, including a lot more RAM.
>=20
> Thanks for these inputs, noted on these things! I haven't tried NVMe =
and SSD media in my RPi 3B. So, they are far more superior as compared =
to microSD cards when it comes to building software?

My understanding is that microsd card media is fairly
generally not as good for such contexts: slower, fails
sooner, etc.

I happen to boot multiple types of machines from the
same media so I use USB3 media that is compatible with
USB2 use, a single such USB3 device not needing a
powered hub for use on the likes of an RPi3B. (Lots
of USB3 media around would require external power for
USB2 or an RPi3B use.) I need a powered hub for 2 or
more such media on a RPi3B.

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


From nobody Mon Oct 31 04:33:18 2022
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 4N10df2H2Vz4gbSN
	for ; Mon, 31 Oct 2022 04:33:26 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4N10dd2Mx7z3jWs
	for ; Mon, 31 Oct 2022 04:33:25 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667190803; bh=es08fjwyjcOznJh96oeHxTDTxvHoxxkDKW+ENypanGk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=aoNeZe1VSOFnFf+MgvjIxVknbT25ePac2ADU+e4GDouQSAbDAqcOTMho2A83TocLST8R1NhzTzfvqMN3QWiReXPN0hcX96aI6NIxkuvyBSftklFlxujGSfmoxyRYAHVoitlCDjRwkZQIOa+e3go83xMDgBGrkxBHegByuR0IFPosgeDovp2iZ84OD7rmJlf5UtgRuDWsqG2vAIc2KOYw3yFhwByguT3o0L/IuoZqN6Zp1L395pORS0X/4qRpq3bJysFJZRU+xQBM06tSNWwTN6t2wWrXrXfO5h0nUHHxl9B72nNFlME96S7UzZ8npjOXcpLnIw/mbBtmAE9vOX4m/Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667190803; bh=FtYwIKq157euCRB9lzhGHg75IlY4oRid3v8Cn0K5eVj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=W0M1sWXNA8xMIZ2t52eJJowMQso5BkUmMFfSw/qTXJh4LIn8+t0ilW+Z0RSVj4RH2LQ/XABZNifycKS1e2gPBB57spTSRqTq6jhvfpcCpnXMZc/pVbZgBHjezyNs70mx/opmUSinLKuDNykG8OikSPDxkJYuVsCK4hXNRbVqn1fRnXGP23c9JMvXMQn7jwCBfLw8XKfhKpOJVj7MaN21rd8W5yLaEA5qJU5HQTNGhjlbG4kQLCYtow40O35C63Lj6HDLytNpUkiP0cVPmq78NpEDo5arkbRG1f+BS5xP7KsWjXCckbvUbA+ZU8Mt7JaXrqifHISNuzIqk+W/Sc+DJQ==
X-YMail-OSG: yHiqKPAVM1nZGt2EVzoM.3erjAItMZ1zTT6Gc1XMF.raRMz2h5cZyfruE9sFisj
 3pKYT_EFZsS4zbdNYRPuZq3XXHnc5YZLhGVOqbHubLXv17pXIvSIG9vlU9b9CJnCU8vyXzw4Hv9g
 HTiG7WyUnw7gDEkYZsweR0Bi9w6vHsugZ1BWcThvWFkxywQ7maa8M9T6OoKlBFaKoqX54N9HHIM3
 D..ho1svg9fAL3SLNnHe2G7u1Dhfl0.p8rMhGHzfBn6ZBj86dwiI_0wPQJYGjc_OUpV2iA0w7e4a
 mnBvAdd4A7RfLupnaTl4Rqz6K1.8lt636gSoDNvBdOsMz7GQ3gy_u84evWlaZgyscz5mxysM0l9L
 ZN3Ykd3iQLSIOtXsgu63HhH_02fwcqNENw84pNlIaIDP2CYtLh9O38hCcE9N4FhHmFKWRrUaeHeM
 Djp.Rp.0qKqaCM7l.mzFFlJi_P0gjD2sTVvOATEU.x_xzBHLsJxX3cMnQtn9NqQ8nCG6veUKHEC3
 Tzoju6rmDEiVGkVc9ast6o0ST.0vw4JIG0bkQbmab3lPgCe9HWe1me2ZqPcGHoT9vnVNG_mPzj1V
 F3ol3dX.__ZppwZyFzA98km5PY0iWytqlZifpSF657.r0fx5MbDg7g04s8aYNqEyNVG5LYeOZRXC
 mowcwSRGCIklkLrTh3Yf_yfATBxzVvT5ZByt_yisC6FjeghkNfOVerr6dHHNPVYnugFPpESLkh.Z
 hDxvf43JCdHE4xcdszharUWxwtwx4haLLIPua0VVl5X5ONhDG.6KTN1t_WMxBWIT.7AotXKjxr6k
 ZTAXJUtdpxn0odFzdAxQz.n3o2qW2cNDrdnFkZjZ41SdDSZuTtypz7EfgU4HgCngh_D6avYHjLd7
 LE_Vk4r59eO7ZjaSunlaQS86lQm7rlj039U9GrQjEs9ofuXKC0lITz5.7RgdXQPp3BN4mBwTH7la
 DKMY7C.R0rAZkFxoTvTqYjgCjzCCkHaNl5UdNEMAU2KdW_TKJeH3ggltceCAwJOk8kKzLTTQEgSO
 llzmujKncDtH3Y9a2oIwHfZIh4PWr2D4Oqag4aNCu_Q0vofqY_wN_CkkwuPN6UxstCY31ysIH9gJ
 GXMI.Gkwro31_YD0VMSL9wYHtSQpt86OrfmiuzlZF7Wgww2StTCPLULOdGQWP1Ki5kqxBCByutKB
 XQAWRtAaiVTx5mL9MSdJgXjjCPW2nsj4JwRvL.XryU5.b37b4wWXdX_MPmX.jFe0KUOznJG0WWf1
 0YXJEbBCGIcHj4pxjYUA_OXnymaFsdfJLNfLqdVUK5R.B4w9fUAiJBTyESmSkTpLAJkIBeZPtbse
 gToLu.xSq5S2_.ccHGQ73QUIOAMcaUCjtrz9TUtMfNM4sLXe1NXOcKP7sIQjABBIKG8ssYzDyj9.
 5oow.8DP.9RNA_07q_PXbNCrxILdT8ZR9k7Y1GrFsN8e4FYGogBSXJPMqeyAvIncrKw0wYQZvWZa
 QPzIO37K3tbTln4XvCd_DSSknRWShbP_lf6nKPOj7AskvDBXi7ol6QZP2msDp6ikLnXLk5b7M9fG
 9pMy1Q5WfuJZ0OkEgg.ixMlxxvWk4GYGqTb3lYqRiFwNwnjYzBYGs0vyt8.S_kIgRugKJJ7aYgZs
 lHdefvlXSLpiTcgwFcLbQY2qBb6Q2Y7.TTS.wLl1ycxifMJfVXYhlbW1oSPAjisKknJhi6HYA_a5
 Kph8z7diK3HhCYdi7_C5egrBqHsc8PFx1JQZY2nUnW5ReR6_UeHRNDTZL290U6FRdqPR6ecEP5ag
 zWjH58mjqwYPRD6IV0jYs7RTwJNa6cbUDmhQQ0eHZXY5nz59AC6JlwvkxIYHnbYBQgoLlGw.ONYb
 jP2Jr51CvB9B84crywaOX2.zggRUGm6ufb5wp04rokdDXJwtKHTGzdeDasBwvaWvnzvZWdkI_H_W
 tfB3FLq1.0Obb6URTpbKuR4VMM31iQP10MKGDEL6V6ITpuiHKT0nAaGipUkXNJ9oqKlVKI6bpqn7
 UXKq7nkM7uMRMU_wYGSGLDHR2yvMcGbEy4UGwnVfdWCB5apgGllpjExnTn2OBCqhO1o5eyHkbSt8
 Ben6qDSEbWX.Q_SI83IYumvtp630r79yXq0IPyeig3bHhOK3jwaUrdavfCouLSUkjfejJZKnznv.
 hR2er2SqqP3u.0oqIWDZjQ3XdSjRGC2jJmBCx8Sws.aS2oEq2DYjXg5WH0imOYlMVXAiQUUwF5vB
 T18YLPdfsu1JLaZzZ.LCWkcLyoIo_JcpD9fvtz6x4NzbHfyVAzeLXd3NKjuNO5q.1h.ZWbLbsqP6
 E
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 31 Oct 2022 04:33:23 +0000
Received: by hermes--production-gq1-754cb59848-cmwdp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a83c721c04cff2f17b92852026dd07f6;
          Mon, 31 Oct 2022 04:33:19 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
From: Mark Millard 
In-Reply-To: 
Date: Sun, 30 Oct 2022 21:33:18 -0700
Cc: freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
 
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N10dd2Mx7z3jWs
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=aoNeZe1V;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TAGGED_RCPT(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_TO(0.00)[gmail.com];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Oct-30, at 21:00, Mark Millard  wrote:

> On 2022-Oct-30, at 19:47, Archimedes Gaviola =
 wrote:
>=20
>> On Mon, Oct 31, 2022 at 1:29 AM Mark Millard  =
wrote:
>> Archimedes Gaviola wrote on
>> Date: Sun, 30 Oct 2022 13:41:52 UTC :
>>=20
>>> I am building a kernel and world in 14.0-CURRENT
>>> =
https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/F=
reeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221027-769b884e2e2-258837.img.xz
>>> with Raspberry Pi 3B  (ARM kernel config file and in default system
>>> configurations) and compilation breaks due to "failed to reclaim =
memory"
>>> error as found in the dmesg.
>>>=20
>>> pid 91224 (llvm-tblgen), jid 0, uid 0, was killed: failed to reclaim =
memory
>>> pid 91131 (make), jid 0, uid 0, was killed: failed to reclaim memory
>>>=20
>>> Here's the set of the build commands I invoked.
>>>=20
>>> root@generic# cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64
>>> buildkernel buildworld installkernel installworld distribution
>>> DESTDIR=3D/home/freebsd/rpi3b
>>>=20
>>> . . .
>>>=20
>>> Any thoughts? As I don't have any idea about VM pageout.
>>=20
>> Hi Mark,
>>=20
>>=20
>> Multiple configuration things from what I use:
>>=20
>> I use a swap partition (not a swap file!) to give the system
>> someplace to put copies of inactive memory pages (paging):
>>=20
>> # swapinfo
>> Device          1K-blocks     Used    Avail Capacity
>> /dev/gpt/Rock64swp2   3670016        0  3670016     0%
>>=20
>> Oh I see, there's no swap partition in the default installation.
>>=20
>> root@generic:~ # swapinfo
>> Device          1K-blocks     Used    Avail Capacity
>>=20
>> root@generic:~ # top -S
>> last pid: 92429;  load averages:  0.00,  0.00,  0.00                  =
                                         up 1+12:49:11  23:41:10
>> 52 processes:  2 running, 48 sleeping, 2 waiting
>> CPU:  0.0% user,  0.0% nice,  0.6% system,  0.0% interrupt, 99.4% =
idle
>> Mem: 2000K Active, 626M Inact, 223M Wired, 97M Buf, 20M Free
>>=20
>> Let me try to create a swap partition. Let me mount a spare USB flash =
drive for swap as during the installation all my microSD card storage =
was allocated in the root filesystem with growfs. =20
>>=20
>>=20
>> where gpart show -p lists it as (a gpt context, not MBR):
>>=20
>>      534528     7340032  da0p2  freebsd-swap  (3.5G)
>>=20
>> and gpart show -pl lists it as:
>>=20
>>      534528     7340032  da0p2  Rock64swp2  (3.5G)
>>=20
>> Okay noted on GPT not MBR method with gpart.
>=20
> I did not happen to have a MBR example around. So I could
> only show GPT. The note was more to avoid confusion than
> anything, since the two are not equivalent for how they
> work.
>=20
>> By the way, what's the proper allocation size of swap in FreeBSD?
>=20
> FreeBSD has a waring that it produces indicating possible mistuning
> when you potentially have too much. An example is:

I seem to have been on a mission to make some typos . . .

"warning" would correct the above.

> warning: total configured swap (2097152 pages) exceeds maximum =
recommended amount (916632 pages).
> warning: increase kern.maxswzone or reduce amount of swap.
>=20
> The numbers are dependent on the amount of RAM present and
> other details.
>=20
> My understanding is that increasing kern.maxswzone has tradeoffs.
> I avoid getting the message because I do not understand the
> tradeoffs or how to manage the tradeoffs or even how to identify
> an instance of hitting such a tradeoff.
>=20
> For aarch64 I've been about to have swap of about 3.4 to 3.5 or
> so times the amount of RAM without getting the warnings.

"allowed", not "about". (This one was potentially confusing
enough to justify this message.)

> That
> is why 3.5G in my RPi3B example. (So RAM+SWAP approx.=3D 4.5*RAM.)
> (armv7 only allows more like 1.8 times the RAM before getting
> the warning.)
>=20
> I avoid even getting too close to the warning as there seems to
> be some build-to-build variability in what fits vs. not. This
> avoids having to frequently adjust the size.
>=20
> Going from the other side, how much RAM+SWAP will your activities
> use? To avoid accurately figuring out such, you may just want to
> have near the 3.4 to 3.5 times RAM. (There have been times when
> clang had memory use oddities that required more than normal for
> a time, for example.)
>=20
>> This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the =
capacity of this physical RAM?
>=20
> Ultimately your choice. How much parallel activity you
> want to attempt likely contributes. If you build ports,
> you might do so in a way that uses more RAM+SWAP than
> system builds do, for example.
>=20
>> (Note: swap file usage is subject to deadlock conditions
>> avoided by use of swap partitions.)
>>=20
>> This is noted.
>>=20
>>=20
>> I use a serial console & ssh session only context to avoid
>> having sizable competition for RAM.
>>=20
>> I avoid using tmpfs because it competes for RAM use.
>>=20
>> I use the likes of ( in, say, /boot/loader/conf ):
>>=20
>> #
>> # Delay when persistent low free RAM leads to
>> # Out Of Memory killing of processes:
>> vm.pageout_oom_seq=3D120
>>=20
>> This delays potential "killed: failed to reclaim memory" kills,
>> possibly long enough to reach a state where sufficient memory is
>> reclaimed.
>>=20
>> Alright this is well noted too.
>=20
> There is tuning related to "a thread waited too long to
> allocate a page" that happens because of paging I/O
> characteristics. But but I've not hit that type of
> error.
>=20
> I'll also note that the "out of swap space" case is a
> misnomer in that it is one or two of 2 internal data
> structures that is out of space, not necessarily the
> swap space on the media. Again, I've not ever hit that
> type of error. I'm not aware of tuning for this case.
>=20
>> I'll note that the status "killed: failed to reclaim memory" does
>> not require that swap be used much at all. Sustained low free RAM
>> from just one process that always stays runnable and has a
>> sufficiently large active set of pages can be sufficient to end up
>> with such kills. Having swap allows for inactive pages to get out
>> of the way, which can help.
>>=20
>> I use the likes of ( in, say, /etc/ssyctl.conf ):
>>=20
>> #
>> # Together this pair avoids swapping out the process kernel stacks.
>> # This avoids processes for interacting with the system from being
>> # hung-up.
>> vm.swap_enabled=3D0
>> vm.swap_idle_enabled=3D0
>>=20
>> This allows paging to the swap space but disallows moving
>> kernel thread stacks to the swap space. Otherwise the
>> processes used to interact with the RPi3 can become
>> non-runnable, preventing such interactions.
>>=20
>> Okay this too is well noted.
>>=20
>>=20
>> I have NVMe or SSD based USB media, not microsd cards nor
>> spinning rust. (I use just bootcode.bin and timeout files
>> on microsd media for the RPi3B. Even the rest of the RPi*
>> firmware is on the USB media, as well as u-boot.bin .)
>=20
> This may contribute to why I've never gotten a "a thread
> waited too long to allocate a page" on any system. (Some
> systems, while bootable via USB3 media I have, also have
> have even faster internal media that is normally used.)
>=20
>> My usage of such a configuration struture for building
>> software (world, kernel, ports) applies to all the
>> systems I do such with, including ones with a lot more
>> resources, including a lot more RAM.
>>=20
>> Thanks for these inputs, noted on these things! I haven't tried NVMe =
and SSD media in my RPi 3B. So, they are far more superior as compared =
to microSD cards when it comes to building software?
>=20
> My understanding is that microsd card media is fairly
> generally not as good for such contexts: slower, fails
> sooner, etc.
>=20
> I happen to boot multiple types of machines from the
> same media so I use USB3 media that is compatible with
> USB2 use, a single such USB3 device not needing a
> powered hub for use on the likes of an RPi3B. (Lots
> of USB3 media around would require external power for
> USB2 or an RPi3B use.) I need a powered hub for 2 or
> more such media on a RPi3B.
>=20

I'll note that the NVMe USB3 media seems to take longer
than normal to power-up/reset. I ended up needing to
have, for example, usb_pgood_delay assigned for
u-boot.bin use in booting. The older USB3 SSD media
did not require such, and still does not. This issue
is not limited to booting RPi*'s in my context.
(Although, where I use EDK2 UEFI/ACPI style booting,
I've not had to do anything special for EDK2.)


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


From nobody Mon Oct 31 05:47:28 2022
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 4N12HN1GD5z4glqG
	for ; Mon, 31 Oct 2022 05:47:44 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N12HM1Wg6z3ph5
	for ; Mon, 31 Oct 2022 05:47:43 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-yb1-xb32.google.com with SMTP id f205so12586923yba.2
        for ; Sun, 30 Oct 2022 22:47:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=aZyTYlN1WeKBSn5D6/lHUkwHpUvyeo0KhOWMYPjBwAE=;
        b=H8J4kNP7g+p9UbXH4qjSZRsASx/FBVhp1fPrJHsJMTVAPZe+I7GrY4cspQ2+GmG9Vr
         ph2XhbrKfh36Fv0UYZYQm5xB8GqjhDej3fZ10D1E7/K/ybmJOx625S8UT0+fMFikp1jV
         y3/QCB6Nof+2la42v3hE4qV0QlFKYQ5FpuFyNKzF7NaOd0XsxylZwf1uIJZFM46GIQaD
         ZfHG8MnRE6jR/YoSzazpSVEEZ2yfgowvy9HKF+210m+jWJgsw/EhOGPvJRyQHoDVvthF
         e1l8uQnNAb8Rrho1+AzOzZLrMFjGzfx4sGHmase+tHkbRjIAhUXqpTjIMVn/8QhKgcjj
         siJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=aZyTYlN1WeKBSn5D6/lHUkwHpUvyeo0KhOWMYPjBwAE=;
        b=jSD+T2SLqugmZCAyaMY5chiM9mimitaHRR9klRz7sPslQ3jb0dd9glJQJBFfV1TERA
         GonNLt6bZqJY0djaqHQje5OSi092SX2N9DrgvSNscWq2w9vri41pBjsZ57dpDI3PSOsH
         p7uHcQqE+AfwQijJ9Gcrr32DTmf8FgWwLBsJOS6eHbahRBQXBJRU5XCaGByjJo1VTdAi
         amLj2PXNGOeYtv70ErmhRAYjOHTIzj9x7THXCYwdoBx0dgz38YHsDg28Jj7+0nlr9nNz
         cHgZaIZk1LIMJQE0UNgSFzL0ALHSrqlggUo9/Z/YSnOyXuIELYVCJqS9VGM1FfecZiWD
         TzWQ==
X-Gm-Message-State: ACrzQf3EH5Qq+n/qD8XLtSBoABF//fdDkh8opq5t0/TaA7fh4GQJ7ZDZ
	KGFnv3hkj0gmc/wLw0XUnEpvVJV/8FyVS4iXDM/nqNw1
X-Google-Smtp-Source: AMsMyM4te2aorhd3CYpsPhdouu/Aw8V/6n0k1xgSonX+u2w/NSwwjIA1b7KxGy0aDo8mKOVQaNkwqE5aza+prDowSs8=
X-Received: by 2002:a5b:311:0:b0:6c3:b37b:a165 with SMTP id
 j17-20020a5b0311000000b006c3b37ba165mr10759305ybp.467.1667195262222; Sun, 30
 Oct 2022 22:47:42 -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: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Mon, 31 Oct 2022 13:47:28 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Mark Millard 
Cc: freebsd-current 
Content-Type: multipart/alternative; boundary="00000000000060449305ec4e25ea"
X-Rspamd-Queue-Id: 4N12HM1Wg6z3ph5
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=H8J4kNP7;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::b32 as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b32:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TAGGED_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000060449305ec4e25ea
Content-Type: text/plain; charset="UTF-8"

> Okay noted on GPT not MBR method with gpart.


> I did not happen to have a MBR example around. So I could
> only show GPT. The note was more to avoid confusion than
> anything, since the two are not equivalent for how they
> work.
>

Okay, this is noted.


>
> > By the way, what's the proper allocation size of swap in FreeBSD?
>
> FreeBSD has a waring that it produces indicating possible mistuning
> when you potentially have too much. An example is:
>
> warning: total configured swap (2097152 pages) exceeds maximum recommended
> amount (916632 pages).
> warning: increase kern.maxswzone or reduce amount of swap.
>
> The numbers are dependent on the amount of RAM present and
> other details.
>
> My understanding is that increasing kern.maxswzone has tradeoffs.
> I avoid getting the message because I do not understand the
> tradeoffs or how to manage the tradeoffs or even how to identify
> an instance of hitting such a tradeoff.
>

Basically the warning messages you've shared are the messages I encountered
with my older FreeBSD system running on MIPS32 at the time I allocated a
swap partition because of the higher allocation size I've made. So what I
did is gradually adjust the swap size until such warnings disappear. I did
not go through the details as most likely it requires a deeper knowledge on
this area. That's why this experience illuminated me again with my RPi 3B
ARM system on the proper allocation size. But yes, below you have the
allocation size.


>
> For aarch64 I've been about to have swap of about 3.4 to 3.5 or
> so times the amount of RAM without getting the warnings. That
> is why 3.5G in my RPi3B example. (So RAM+SWAP approx.= 4.5*RAM.)
> (armv7 only allows more like 1.8 times the RAM before getting
> the warning.)
>

Okay this is noted. I'll take the 3.5G size as this is based on your actual
experience.


>
> I avoid even getting too close to the warning as there seems to
> be some build-to-build variability in what fits vs. not. This
> avoids having to frequently adjust the size.
>
>
I, too, need to avoid such warnings as much as possible with this RPi 3B
configuration.


> Going from the other side, how much RAM+SWAP will your activities
> use? To avoid accurately figuring out such, you may just want to
> have near the 3.4 to 3.5 times RAM. (There have been times when
> clang had memory use oddities that required more than normal for
> a time, for example.)
>

I'll just follow the size you have and let me observe how it goes.


>
> > This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the
> capacity of this physical RAM?
>
> Ultimately your choice. How much parallel activity you
> want to attempt likely contributes. If you build ports,
> you might do so in a way that uses more RAM+SWAP than
> system builds do, for example.
>

Okay this is noted. For now, building the kernel and world is my goal, no
ports yet.


>
> > (Note: swap file usage is subject to deadlock conditions
> > avoided by use of swap partitions.)
> >
> > This is noted.
> >
> >
> > I use a serial console & ssh session only context to avoid
> > having sizable competition for RAM.
> >
> > I avoid using tmpfs because it competes for RAM use.
> >
> > I use the likes of ( in, say, /boot/loader/conf ):
> >
> > #
> > # Delay when persistent low free RAM leads to
> > # Out Of Memory killing of processes:
> > vm.pageout_oom_seq=120
> >
> > This delays potential "killed: failed to reclaim memory" kills,
> > possibly long enough to reach a state where sufficient memory is
> > reclaimed.
> >
> > Alright this is well noted too.
>
> There is tuning related to "a thread waited too long to
> allocate a page" that happens because of paging I/O
> characteristics. But but I've not hit that type of
> error.
>
> I'll also note that the "out of swap space" case is a
> misnomer in that it is one or two of 2 internal data
> structures that is out of space, not necessarily the
> swap space on the media. Again, I've not ever hit that
> type of error. I'm not aware of tuning for this case.
>

Okay, noted as well on this info. Let me just try the 3.5G swap allocation.
I will post another thread if I ever encounter these types of errors.


>
> > I'll note that the status "killed: failed to reclaim memory" does
> > not require that swap be used much at all. Sustained low free RAM
> > from just one process that always stays runnable and has a
> > sufficiently large active set of pages can be sufficient to end up
> > with such kills. Having swap allows for inactive pages to get out
> > of the way, which can help.
> >
> > I use the likes of ( in, say, /etc/ssyctl.conf ):
> >
> > #
> > # Together this pair avoids swapping out the process kernel stacks.
> > # This avoids processes for interacting with the system from being
> > # hung-up.
> > vm.swap_enabled=0
> > vm.swap_idle_enabled=0
> >
> > This allows paging to the swap space but disallows moving
> > kernel thread stacks to the swap space. Otherwise the
> > processes used to interact with the RPi3 can become
> > non-runnable, preventing such interactions.
> >
> > Okay this too is well noted.
> >
> >
> > I have NVMe or SSD based USB media, not microsd cards nor
> > spinning rust. (I use just bootcode.bin and timeout files
> > on microsd media for the RPi3B. Even the rest of the RPi*
> > firmware is on the USB media, as well as u-boot.bin .)
>
> This may contribute to why I've never gotten a "a thread
> waited too long to allocate a page" on any system. (Some
> systems, while bootable via USB3 media I have, also have
> have even faster internal media that is normally used.)
>

Alright so there's significance.


>
> > My usage of such a configuration struture for building
> > software (world, kernel, ports) applies to all the
> > systems I do such with, including ones with a lot more
> > resources, including a lot more RAM.
> >
> > Thanks for these inputs, noted on these things! I haven't tried NVMe and
> SSD media in my RPi 3B. So, they are far more superior as compared to
> microSD cards when it comes to building software?
>
> My understanding is that microsd card media is fairly
> generally not as good for such contexts: slower, fails
> sooner, etc.
>

I'll take note of this one as I may encounter those attributes along the
course of building software. It's something that I need to explore and do
some research ahead.


>
> I happen to boot multiple types of machines from the
> same media so I use USB3 media that is compatible with
> USB2 use, a single such USB3 device not needing a
> powered hub for use on the likes of an RPi3B. (Lots
> of USB3 media around would require external power for
> USB2 or an RPi3B use.) I need a powered hub for 2 or
> more such media on a RPi3B.
>

Okay, that's right.  In my experience, inserting some devices tends to
reset the 4 USB ports' power, thus to prevent such behavior needs a
self-powered hub.

Thanks and best regards,
Archimedes

--00000000000060449305ec4e25ea
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



> Okay noted on GPT not=
 MBR method with gpart.




I did not happen to have a MBR example around. So I could

only show GPT. The note was more to avoid confusion than

anything, since the two are not equivalent for how they

work.

Okay, this is noted.
=
=C2=A0



> By the way, what's the proper allocation size of swap in FreeBSD?<=
br>


FreeBSD has a waring that it produces indicating possible mistuning

when you potentially have too much. An example is:



warning: total configured swap (2097152 pages) exceeds maximum recommended =
amount (916632 pages).

warning: increase kern.maxswzone or reduce amount of swap.



The numbers are dependent on the amount of RAM present and

other details.



My understanding is that increasing kern.maxswzone has tradeoffs.

I avoid getting the message because I do not understand the

tradeoffs or how to manage the tradeoffs or even how to identify

an instance of hitting such a tradeoff.

Basically the warning messages you've shared are the messages I encoun=
tered with my older FreeBSD system running on MIPS32 at the time I allocate=
d a swap partition because of the higher allocation size I've made. So =
what I did is gradually adjust the swap size until such warnings disappear.=
 I did not go through the details as most likely it requires a deeper knowl=
edge on this area. That's why this experience illuminated me again with=
 my RPi 3B ARM system on the proper allocation size. But yes, below you hav=
e the allocation size. 
=C2=A0



For aarch64 I've been about to have swap of about 3.4 to 3.5 or

so times the amount of RAM without getting the warnings. That

is why 3.5G in my RPi3B example. (So RAM+SWAP approx.=3D 4.5*RAM.)

(armv7 only allows more like 1.8 times the RAM before getting

the warning.)

Okay this is noted. I'=
;ll take the 3.5G size as this is based on your actual experience.
=C2=A0



I avoid even getting too close to the warning as there seems to

be some build-to-build variability in what fits vs. not. This

avoids having to frequently adjust the size.



I, too, need to avoid such warnings as=
 much as possible with this RPi 3B configuration.
=C2=A0

Going from the other side, how much RAM+SWAP will your activities

use? To avoid accurately figuring out such, you may just want to

have near the 3.4 to 3.5 times RAM. (There have been times when

clang had memory use oddities that required more than normal for

a time, for example.)

I'll just fol=
low the size you have and let me observe how it goes.
=C2=A0
<=
/div>



> This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the capac=
ity of this physical RAM?



Ultimately your choice. How much parallel activity you

want to attempt likely contributes. If you build ports,

you might do so in a way that uses more RAM+SWAP than

system builds do, for example.

Okay thi=
s is noted. For now, building the kernel and world is my goal, no ports yet=
.
=C2=A0=C2=A0 



> (Note: swap file usage is subject to deadlock conditions

> avoided by use of swap partitions.)

> 

> This is noted.

>=C2=A0 

> 

> I use a serial console & ssh session only context to avoid

> having sizable competition for RAM.

> 

> I avoid using tmpfs because it competes for RAM use.

> 

> I use the likes of ( in, say, /boot/loader/conf ):

> 

> #

> # Delay when persistent low free RAM leads to

> # Out Of Memory killing of processes:

> vm.pageout_oom_seq=3D120

> 

> This delays potential "killed: failed to reclaim memory" kil=
ls,

> possibly long enough to reach a state where sufficient memory is

> reclaimed.

> 

> Alright this is well noted too.



There is tuning related to "a thread waited too long to

allocate a page" that happens because of paging I/O

characteristics. But but I've not hit that type of

error.



I'll also note that the "out of swap space" case is a

misnomer in that it is one or two of 2 internal data

structures that is out of space, not necessarily the

swap space on the media. Again, I've not ever hit that

type of error. I'm not aware of tuning for this case.
<=
div>
Okay, noted as well on this info. Let me just try the 3.=
5G swap allocation. I will post another thread if I ever encounter these ty=
pes of errors.
=C2=A0



> I'll note that the status "killed: failed to reclaim memory&q=
uot; does

> not require that swap be used much at all. Sustained low free RAM

> from just one process that always stays runnable and has a

> sufficiently large active set of pages can be sufficient to end up

> with such kills. Having swap allows for inactive pages to get out

> of the way, which can help.

> 

> I use the likes of ( in, say, /etc/ssyctl.conf ):

> 

> #

> # Together this pair avoids swapping out the process kernel stacks.
> # This avoids processes for interacting with the system from being

> # hung-up.

> vm.swap_enabled=3D0

> vm.swap_idle_enabled=3D0

> 

> This allows paging to the swap space but disallows moving

> kernel thread stacks to the swap space. Otherwise the

> processes used to interact with the RPi3 can become

> non-runnable, preventing such interactions.

> 

> Okay this too is well noted.

>=C2=A0 

> 

> I have NVMe or SSD based USB media, not microsd cards nor

> spinning rust. (I use just bootcode.bin and timeout files

> on microsd media for the RPi3B. Even the rest of the RPi*

> firmware is on the USB media, as well as u-boot.bin .)



This may contribute to why I've never gotten a "a thread

waited too long to allocate a page" on any system. (Some

systems, while bootable via USB3 media I have, also have

have even faster internal media that is normally used.)

Alright so there's significance.
=C2=A0
<=
/div>



> My usage of such a configuration struture for building

> software (world, kernel, ports) applies to all the

> systems I do such with, including ones with a lot more

> resources, including a lot more RAM.

> 

> Thanks for these inputs, noted on these things! I haven't tried NV=
Me and SSD media in my RPi 3B. So, they are far more superior as compared t=
o microSD cards when it comes to building software?



My understanding is that microsd card media is fairly

generally not as good for such contexts: slower, fails

sooner, etc.

I'll take note of this=
 one as I may encounter those attributes along the course of building softw=
are. It's something that I need to explore and do some research ahead.<=
br>
=C2=A0



I happen to boot multiple types of machines from the

same media so I use USB3 media that is compatible with

USB2 use, a single such USB3 device not needing a

powered hub for use on the likes of an RPi3B. (Lots

of USB3 media around would require external power for

USB2 or an RPi3B use.) I need a powered hub for 2 or

more such media on a RPi3B.

Okay, that's=
 right.=C2=A0 In my experience, inserting some devices tends to reset the 4=
 USB ports' power, thus to prevent such behavior needs a self-powered h=
ub.

Th=
anks and best regards,
Archimedes
=



--00000000000060449305ec4e25ea--

From nobody Wed Nov  2 21:09:24 2022
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 4N2ff96fBwz4gwRH
	for ; Wed,  2 Nov 2022 21:09:37 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N2ff8737Mz4N1t
	for ; Wed,  2 Nov 2022 21:09:36 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-yb1-xb2c.google.com with SMTP id g127so52984ybg.8
        for ; Wed, 02 Nov 2022 14:09:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=msDjbYujCdnuqZ+5BiUlTNV+7pLbTdnxvUVlHTCtHPI=;
        b=K44MIcecsYdb+QlIeAeeWbost8kzI4uVxFhM6L63YBwKaVkG6ZuUBkeKc3NMHskqK/
         SW6o5ZZdCtLQRT2Y20c8dEMxOfJflU9Y/jJ2hvD2NdsGcQPt939hOQ3eHjlW1lUXeT5f
         N9ftvYG/KR1K1gSOcct+4G45LKGRcjjcEi0z4yjBZXGBJj4GSDDZZm1JYXRU6b2YtuMR
         zeLXcYcAkZRi2Ozd7YnglaFbCS5E5xV2VBPQie5ka+BR7tQXQbrYdLIGEDGwtUHasBMy
         vR4XXbKFu6n7N395pdT+BYc8XwjRWeLSAzTg86vuYgZnJzgU3GIdZGp82Esfz7jvW3/W
         XiAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=msDjbYujCdnuqZ+5BiUlTNV+7pLbTdnxvUVlHTCtHPI=;
        b=549i7BnUOhjCl3KKFdWCbUkgwOjaHZ4uV1msLUA5AKmtUu8hBk7n8E5Tej++5T7QNM
         YM2KMQGX2RLaii32h0qckIf2E8O2at5TZ9ZC3Flyr5aUrHn0gxjf7BmXZUCsojY+o3pW
         9Eif1ByMD0L400N0kWKkixCgcKqHqz/oSoc5kWYIOScD0D0TxS6j1+AHPpI5r9SofO5u
         iM6y3o/h2QeRrARZGhDksv8b0et34eVQpzEEPi5EwJ4muf4M8Z6iz2n2kWs2bZtHN6T/
         hhW9PsC32dLkG60qgzUFI7Zm09GYFvwRURRY+bhOWldUBFmZiQve/kPZ0AO69+j0HVgv
         mQzQ==
X-Gm-Message-State: ACrzQf23GOOtqh7MJfDnfW84Sv8x954MKphftWDNocZDH7XDI78VOdz3
	x1y7nIgTpncqo1rsYKCFa9VPfd3S4UORznmggVk=
X-Google-Smtp-Source: AMsMyM4koggBLtVKWXiLuUKa3SaNXDyqEhYF0NjyBnlpfZg9Nac9ohdIVX3H4VIc9FA9VdtqwL8EzZGIsZXcOjUuPNc=
X-Received: by 2002:a25:d216:0:b0:6cf:e9f4:ace2 with SMTP id
 j22-20020a25d216000000b006cfe9f4ace2mr5295371ybg.84.1667423375588; Wed, 02
 Nov 2022 14:09:35 -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: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Thu, 3 Nov 2022 05:09:24 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Mark Millard 
Cc: freebsd-current 
Content-Type: multipart/alternative; boundary="000000000000fe329b05ec834162"
X-Rspamd-Queue-Id: 4N2ff8737Mz4N1t
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=K44MIcec;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::b2c as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com
X-Spamd-Result: default: False [-4.00 / 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)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2c:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TAGGED_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000fe329b05ec834162
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
> > Okay noted on GPT not MBR method with gpart.
>
>
>> I did not happen to have a MBR example around. So I could
>> only show GPT. The note was more to avoid confusion than
>> anything, since the two are not equivalent for how they
>> work.
>>
>
> Okay, this is noted.
>
>
>>
>> > By the way, what's the proper allocation size of swap in FreeBSD?
>>
>> FreeBSD has a waring that it produces indicating possible mistuning
>> when you potentially have too much. An example is:
>>
>> warning: total configured swap (2097152 pages) exceeds maximum
>> recommended amount (916632 pages).
>> warning: increase kern.maxswzone or reduce amount of swap.
>>
>> The numbers are dependent on the amount of RAM present and
>> other details.
>>
>> My understanding is that increasing kern.maxswzone has tradeoffs.
>> I avoid getting the message because I do not understand the
>> tradeoffs or how to manage the tradeoffs or even how to identify
>> an instance of hitting such a tradeoff.
>>
>
> Basically the warning messages you've shared are the messages I
> encountered with my older FreeBSD system running on MIPS32 at the time I
> allocated a swap partition because of the higher allocation size I've made.
> So what I did is gradually adjust the swap size until such warnings
> disappear. I did not go through the details as most likely it requires a
> deeper knowledge on this area. That's why this experience illuminated me
> again with my RPi 3B ARM system on the proper allocation size. But yes,
> below you have the allocation size.
>
>
>>
>> For aarch64 I've been about to have swap of about 3.4 to 3.5 or
>> so times the amount of RAM without getting the warnings. That
>> is why 3.5G in my RPi3B example. (So RAM+SWAP approx.= 4.5*RAM.)
>> (armv7 only allows more like 1.8 times the RAM before getting
>> the warning.)
>>
>
> Okay this is noted. I'll take the 3.5G size as this is based on your
> actual experience.
>
>
>>
>> I avoid even getting too close to the warning as there seems to
>> be some build-to-build variability in what fits vs. not. This
>> avoids having to frequently adjust the size.
>>
>>
> I, too, need to avoid such warnings as much as possible with this RPi 3B
> configuration.
>
>
>> Going from the other side, how much RAM+SWAP will your activities
>> use? To avoid accurately figuring out such, you may just want to
>> have near the 3.4 to 3.5 times RAM. (There have been times when
>> clang had memory use oddities that required more than normal for
>> a time, for example.)
>>
>
> I'll just follow the size you have and let me observe how it goes.
>
>
>>
>> > This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the
>> capacity of this physical RAM?
>>
>> Ultimately your choice. How much parallel activity you
>> want to attempt likely contributes. If you build ports,
>> you might do so in a way that uses more RAM+SWAP than
>> system builds do, for example.
>>
>
> Okay this is noted. For now, building the kernel and world is my goal, no
> ports yet.
>
>
>>
>> > (Note: swap file usage is subject to deadlock conditions
>> > avoided by use of swap partitions.)
>> >
>> > This is noted.
>> >
>> >
>> > I use a serial console & ssh session only context to avoid
>> > having sizable competition for RAM.
>> >
>> > I avoid using tmpfs because it competes for RAM use.
>> >
>> > I use the likes of ( in, say, /boot/loader/conf ):
>> >
>> > #
>> > # Delay when persistent low free RAM leads to
>> > # Out Of Memory killing of processes:
>> > vm.pageout_oom_seq=120
>> >
>> > This delays potential "killed: failed to reclaim memory" kills,
>> > possibly long enough to reach a state where sufficient memory is
>> > reclaimed.
>> >
>> > Alright this is well noted too.
>>
>> There is tuning related to "a thread waited too long to
>> allocate a page" that happens because of paging I/O
>> characteristics. But but I've not hit that type of
>> error.
>>
>> I'll also note that the "out of swap space" case is a
>> misnomer in that it is one or two of 2 internal data
>> structures that is out of space, not necessarily the
>> swap space on the media. Again, I've not ever hit that
>> type of error. I'm not aware of tuning for this case.
>>
>
> Okay, noted as well on this info. Let me just try the 3.5G swap
> allocation. I will post another thread if I ever encounter these types of
> errors.
>
>
>>
>> > I'll note that the status "killed: failed to reclaim memory" does
>> > not require that swap be used much at all. Sustained low free RAM
>> > from just one process that always stays runnable and has a
>> > sufficiently large active set of pages can be sufficient to end up
>> > with such kills. Having swap allows for inactive pages to get out
>> > of the way, which can help.
>> >
>> > I use the likes of ( in, say, /etc/ssyctl.conf ):
>> >
>> > #
>> > # Together this pair avoids swapping out the process kernel stacks.
>> > # This avoids processes for interacting with the system from being
>> > # hung-up.
>> > vm.swap_enabled=0
>> > vm.swap_idle_enabled=0
>> >
>> > This allows paging to the swap space but disallows moving
>> > kernel thread stacks to the swap space. Otherwise the
>> > processes used to interact with the RPi3 can become
>> > non-runnable, preventing such interactions.
>> >
>> > Okay this too is well noted.
>> >
>> >
>> > I have NVMe or SSD based USB media, not microsd cards nor
>> > spinning rust. (I use just bootcode.bin and timeout files
>> > on microsd media for the RPi3B. Even the rest of the RPi*
>> > firmware is on the USB media, as well as u-boot.bin .)
>>
>> This may contribute to why I've never gotten a "a thread
>> waited too long to allocate a page" on any system. (Some
>> systems, while bootable via USB3 media I have, also have
>> have even faster internal media that is normally used.)
>>
>
> Alright so there's significance.
>
>
>>
>> > My usage of such a configuration struture for building
>> > software (world, kernel, ports) applies to all the
>> > systems I do such with, including ones with a lot more
>> > resources, including a lot more RAM.
>> >
>> > Thanks for these inputs, noted on these things! I haven't tried NVMe
>> and SSD media in my RPi 3B. So, they are far more superior as compared to
>> microSD cards when it comes to building software?
>>
>> My understanding is that microsd card media is fairly
>> generally not as good for such contexts: slower, fails
>> sooner, etc.
>>
>
> I'll take note of this one as I may encounter those attributes along the
> course of building software. It's something that I need to explore and do
> some research ahead.
>
>
>>
>> I happen to boot multiple types of machines from the
>> same media so I use USB3 media that is compatible with
>> USB2 use, a single such USB3 device not needing a
>> powered hub for use on the likes of an RPi3B. (Lots
>> of USB3 media around would require external power for
>> USB2 or an RPi3B use.) I need a powered hub for 2 or
>> more such media on a RPi3B.
>>
>
> Okay, that's right.  In my experience, inserting some devices tends to
> reset the 4 USB ports' power, thus to prevent such behavior needs a
> self-powered hub.
>
>
Hi Mark,

Just an update, as kernel and world compilation is ongoing with my RPi3B
system (with swap partition) is doing so far, so good. It already surpassed
the tough part that breaks the compilation process here.
...

llvm-tblgen -gen-asm-matcher  -I /usr/src/contrib/llvm-project/llvm/include
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-asm-writer  -I /usr/src/contrib/llvm-project/llvm/include
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-callingconv  -I /usr/src/contrib/llvm-project/llvm/include
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-compress-inst-emitter  -I
/usr/src/contrib/llvm-project/llvm/include -I
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-dag-isel  -I /usr/src/contrib/llvm-project/llvm/include -I
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-disassembler  -I
/usr/src/contrib/llvm-project/llvm/include -I
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-global-isel  -I /usr/src/contrib/llvm-project/llvm/include
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-instr-info  -I /usr/src/contrib/llvm-project/llvm/include
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-emitter  -I /usr/src/contrib/llvm-project/llvm/include -I
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-pseudo-lowering  -I
/usr/src/contrib/llvm-project/llvm/include -I
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-register-bank  -I
/usr/src/contrib/llvm-project/llvm/include -I
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-register-info  -I
/usr/src/contrib/llvm-project/llvm/include -I
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-searchable-tables  -I
/usr/src/contrib/llvm-project/llvm/include -I
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-subtarget  -I /usr/src/contrib/llvm-project/llvm/include
-I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-searchable-tables  -I
/usr/src/contrib/llvm-project/llvm/include -I
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

Any thoughts why this part is quite a challenge when it comes to memory
usage? The other architectures do not possess such behavior... just curious.

Thanks and best regards,
Archimedes

--000000000000fe329b05ec834162
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Oct 31, 2022 at 1:47 PM Archi=
medes Gaviola <archimede=
s.gaviola@gmail.com> wrote:

> Ok=
ay noted on GPT not MBR method with gpart.




I did not happen to have a MBR example around. So I could

only show GPT. The note was more to avoid confusion than

anything, since the two are not equivalent for how they

work.

Okay, this is noted.
=
=C2=A0



> By the way, what's the proper allocation size of swap in FreeBSD?<=
br>


FreeBSD has a waring that it produces indicating possible mistuning

when you potentially have too much. An example is:



warning: total configured swap (2097152 pages) exceeds maximum recommended =
amount (916632 pages).

warning: increase kern.maxswzone or reduce amount of swap.



The numbers are dependent on the amount of RAM present and

other details.



My understanding is that increasing kern.maxswzone has tradeoffs.

I avoid getting the message because I do not understand the

tradeoffs or how to manage the tradeoffs or even how to identify

an instance of hitting such a tradeoff.

Basically the warning messages you've shared are the messages I encoun=
tered with my older FreeBSD system running on MIPS32 at the time I allocate=
d a swap partition because of the higher allocation size I've made. So =
what I did is gradually adjust the swap size until such warnings disappear.=
 I did not go through the details as most likely it requires a deeper knowl=
edge on this area. That's why this experience illuminated me again with=
 my RPi 3B ARM system on the proper allocation size. But yes, below you hav=
e the allocation size. 
=C2=A0



For aarch64 I've been about to have swap of about 3.4 to 3.5 or

so times the amount of RAM without getting the warnings. That

is why 3.5G in my RPi3B example. (So RAM+SWAP approx.=3D 4.5*RAM.)

(armv7 only allows more like 1.8 times the RAM before getting

the warning.)

Okay this is noted. I'=
;ll take the 3.5G size as this is based on your actual experience.
=C2=A0



I avoid even getting too close to the warning as there seems to

be some build-to-build variability in what fits vs. not. This

avoids having to frequently adjust the size.



I, too, need to avoid such warnings as=
 much as possible with this RPi 3B configuration.
=C2=A0

Going from the other side, how much RAM+SWAP will your activities

use? To avoid accurately figuring out such, you may just want to

have near the 3.4 to 3.5 times RAM. (There have been times when

clang had memory use oddities that required more than normal for

a time, for example.)

I'll just fol=
low the size you have and let me observe how it goes.
=C2=A0
<=
/div>



> This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the capac=
ity of this physical RAM?



Ultimately your choice. How much parallel activity you

want to attempt likely contributes. If you build ports,

you might do so in a way that uses more RAM+SWAP than

system builds do, for example.

Okay thi=
s is noted. For now, building the kernel and world is my goal, no ports yet=
.
=C2=A0=C2=A0 



> (Note: swap file usage is subject to deadlock conditions

> avoided by use of swap partitions.)

> 

> This is noted.

>=C2=A0 

> 

> I use a serial console & ssh session only context to avoid

> having sizable competition for RAM.

> 

> I avoid using tmpfs because it competes for RAM use.

> 

> I use the likes of ( in, say, /boot/loader/conf ):

> 

> #

> # Delay when persistent low free RAM leads to

> # Out Of Memory killing of processes:

> vm.pageout_oom_seq=3D120

> 

> This delays potential "killed: failed to reclaim memory" kil=
ls,

> possibly long enough to reach a state where sufficient memory is

> reclaimed.

> 

> Alright this is well noted too.



There is tuning related to "a thread waited too long to

allocate a page" that happens because of paging I/O

characteristics. But but I've not hit that type of

error.



I'll also note that the "out of swap space" case is a

misnomer in that it is one or two of 2 internal data

structures that is out of space, not necessarily the

swap space on the media. Again, I've not ever hit that

type of error. I'm not aware of tuning for this case.
<=
div>
Okay, noted as well on this info. Let me just try the 3.=
5G swap allocation. I will post another thread if I ever encounter these ty=
pes of errors.
=C2=A0



> I'll note that the status "killed: failed to reclaim memory&q=
uot; does

> not require that swap be used much at all. Sustained low free RAM

> from just one process that always stays runnable and has a

> sufficiently large active set of pages can be sufficient to end up

> with such kills. Having swap allows for inactive pages to get out

> of the way, which can help.

> 

> I use the likes of ( in, say, /etc/ssyctl.conf ):

> 

> #

> # Together this pair avoids swapping out the process kernel stacks.
> # This avoids processes for interacting with the system from being

> # hung-up.

> vm.swap_enabled=3D0

> vm.swap_idle_enabled=3D0

> 

> This allows paging to the swap space but disallows moving

> kernel thread stacks to the swap space. Otherwise the

> processes used to interact with the RPi3 can become

> non-runnable, preventing such interactions.

> 

> Okay this too is well noted.

>=C2=A0 

> 

> I have NVMe or SSD based USB media, not microsd cards nor

> spinning rust. (I use just bootcode.bin and timeout files

> on microsd media for the RPi3B. Even the rest of the RPi*

> firmware is on the USB media, as well as u-boot.bin .)



This may contribute to why I've never gotten a "a thread

waited too long to allocate a page" on any system. (Some

systems, while bootable via USB3 media I have, also have

have even faster internal media that is normally used.)

Alright so there's significance.
=C2=A0
<=
/div>



> My usage of such a configuration struture for building

> software (world, kernel, ports) applies to all the

> systems I do such with, including ones with a lot more

> resources, including a lot more RAM.

> 

> Thanks for these inputs, noted on these things! I haven't tried NV=
Me and SSD media in my RPi 3B. So, they are far more superior as compared t=
o microSD cards when it comes to building software?



My understanding is that microsd card media is fairly

generally not as good for such contexts: slower, fails

sooner, etc.

I'll take note of this=
 one as I may encounter those attributes along the course of building softw=
are. It's something that I need to explore and do some research ahead.<=
br>
=C2=A0



I happen to boot multiple types of machines from the

same media so I use USB3 media that is compatible with

USB2 use, a single such USB3 device not needing a

powered hub for use on the likes of an RPi3B. (Lots

of USB3 media around would require external power for

USB2 or an RPi3B use.) I need a powered hub for 2 or

more such media on a RPi3B.

Okay, that's=
 right.=C2=A0 In my experience, inserting some devices tends to reset the 4=
 USB ports' power, thus to prevent such behavior needs a self-powered h=
ub.


<=
/div>
Hi Mark,

Just an update, as kernel and w=
orld compilation is ongoing with my RPi3B system (with swap partition) is d=
oing so far, so good. It already surpassed the tough part that breaks the c=
ompilation process here.
...
<=
div>
llvm-tblgen -gen-asm-matcher =C2=A0-I /usr/src/contrib/l=
lvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/R=
ISCV =C2=A0-d RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc =C2=A0/usr=
/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -ge=
n-asm-writer =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/sr=
c/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenAsmWriter.inc=
.d -o RISCVGenAsmWriter.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Ta=
rget/RISCV/RISCV.td
llvm-tblgen -gen-callingconv =C2=A0-I /usr/src/contr=
ib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Targ=
et/RISCV =C2=A0-d RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc =C2=
=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tbl=
gen -gen-compress-inst-emitter =C2=A0-I /usr/src/contrib/llvm-project/llvm/=
include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RIS=
CVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc =C2=A0/us=
r/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -g=
en-dag-isel =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src=
/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenDAGISel.inc.d =
-o RISCVGenDAGISel.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/=
RISCV/RISCV.td
llvm-tblgen -gen-disassembler =C2=A0-I /usr/src/contrib/l=
lvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/R=
ISCV =C2=A0-d RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTable=
s.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.tdllvm-tblgen -gen-global-isel =C2=A0-I /usr/src/contrib/llvm-project/llvm/i=
nclude -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISC=
VGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc =C2=A0/usr/src/contrib/llvm-=
project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-instr-info =C2=
=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-p=
roject/llvm/lib/Target/RISCV =C2=A0-d RISCVGenInstrInfo.inc.d -o RISCVGenIn=
strInfo.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV=
.td
llvm-tblgen -gen-emitter =C2=A0-I /usr/src/contrib/llvm-project/llvm=
/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RI=
SCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc =C2=A0/usr/src/contr=
ib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-pseudo-l=
owering =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenMCPseudoLowering.i=
nc.d -o RISCVGenMCPseudoLowering.inc =C2=A0/usr/src/contrib/llvm-project/ll=
vm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-register-bank =C2=A0-I /us=
r/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/ll=
vm/lib/Target/RISCV =C2=A0-d RISCVGenRegisterBank.inc.d -o RISCVGenRegister=
Bank.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td=

llvm-tblgen -gen-register-info =C2=A0-I /usr/src/contrib/llvm-project/l=
lvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d=
 RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc =C2=A0/usr/src/cont=
rib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-searcha=
ble-tables =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/=
contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenSearchableTable=
s.inc.d -o RISCVGenSearchableTables.inc =C2=A0/usr/src/contrib/llvm-project=
/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-subtarget =C2=A0-I /usr=
/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llv=
m/lib/Target/RISCV =C2=A0-d RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtarge=
tInfo.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.t=
d
llvm-tblgen -gen-searchable-tables =C2=A0-I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=
=A0-d RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc =C2=A0/usr=
/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

Any thoughts why this part is quite a challenge when it comes to mem=
ory usage? The other architectures do not possess such behavior... just cur=
ious.

Thanks and best regards,
Archimede=
s

=C2=A0


--000000000000fe329b05ec834162--

From nobody Wed Nov  2 21:44:43 2022
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 4N2gQw30VZz4h1X6
	for ; Wed,  2 Nov 2022 21:44:56 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N2gQw29Wxz3DgW
	for ; Wed,  2 Nov 2022 21:44:56 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667425496;
	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=dZ0dtG82Wky6FyQLv0FvLKgI4PYZgE7oMNu22k32IFo=;
	b=fcuWFBg4D+VOBf+0eMHoVMFbqdLFPrIqX3SyaDnEp2xme4FTUJNPq+3ekBa7PgSdFb0kJi
	TS0QvbkYkykTTtQz00xTBy8o5OKgauRaXG1YE3JhtAT2Jd4weLGhw546uatnPKiJNNTCik
	WfB6328YAZ9rnx4wTTdRhp9r2h/wI9/kcm7SS/YGcc452z12yB0ow/2awg+Dg7uR1DQHzP
	5NwumvEQ5qyOx9rD4jZE9d4aOLqYT+bQQZTufGp6ZBbjk0QtJA+h7d2/PZLe9v8SR83vSc
	4ogv3WrI4tlKE78zE0vc/KPbc/J3H77YNCVIN9FC6xs3tmBaIxBMNzZKN8i4AA==
Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N2gQw0tLTzVkt
	for ; Wed,  2 Nov 2022 21:44:56 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f172.google.com with SMTP id m18so9610196vka.10
        for ; Wed, 02 Nov 2022 14:44:56 -0700 (PDT)
X-Gm-Message-State: ACrzQf3Zyp2cxuMd0V2LMW68tLM1LVQ9DcP9k4ibzeRo2VQ4Yo4b215f
	toYJ0uBQkjBr32wvG7xVLSu91hnofzIXAqV/Vx8=
X-Google-Smtp-Source: AMsMyM4aqFxZvl5BL220bwV5Y51F2ZKy1E0bZbCcAXm98pCYh6hAqcBufJADrFuv6Lad7saMCcVtHZQ2WGUsHd4MV84=
X-Received: by 2002:a05:6122:b51:b0:3b8:8c:e3dc with SMTP id
 17-20020a0561220b5100b003b8008ce3dcmr13361593vko.24.1667425495303; Wed, 02
 Nov 2022 14:44: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: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
 
In-Reply-To: 
From: Nuno Teixeira 
Date: Wed, 2 Nov 2022 21:44:43 +0000
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Archimedes Gaviola 
Cc: Mark Millard , freebsd-current 
Content-Type: multipart/alternative; boundary="000000000000564b1005ec83c0ce"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667425496;
	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=dZ0dtG82Wky6FyQLv0FvLKgI4PYZgE7oMNu22k32IFo=;
	b=NS7Njg7AJyuhfdf+6xjfVeYx8SeEm+qFXQF/PqPEMdST+S1uN/1Tgqu5jiDYF/IjHPXLWw
	IfoySE1dbboxDPtgOsKii+EACBk+kz6EjeujtYImO8Mltd6s0TrzjvqNDT3brR+oOuAfXl
	rSWegS/X4s5ymKn1vaIEmT+jpNG8/VMnzMocA1wXraNZp5jc2n3PxeXDOGR7nfB//KYfuY
	ODwwpK6TpzA+d4/KEJD14aDJZ16eoHimif9Zm3+90VGVhMc7/i1M1nsIa1h2FvRicVtqda
	TijP5fOIzs1pEcVPuSgnNU49AtfTdEA3ucl/iYJ/FNZx+tRG3MDZ4FA+HwVOZw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667425496; a=rsa-sha256; cv=none;
	b=FFVKGeATm5EMxP1yiI+Eq28zsA6hcwbF60kDOX9uDeH2nL3BldF0dqEfMEfsmAiOtkipr9
	+RkpXJCoeJWdXx+pwky+0vWV+vlah2i3CRVD8JE/0VUDVbB8LxYSIkwbtCyuYIRx8bPe5+
	0cY7bNydO0nB6kTjzRyVQBGAO3WsH79FCjX5JLn/gYmPzn1VDca7zoblKcbQlTt8IVNH3Q
	hh79vJnSNRuw7BZzw5TqDBuUWEqCgs5f7azC6F7bfXget5645AL1o3qIPuKyodFZtUmlNS
	uPHtPjxjqQJXv3tZzwUn2oqim+MerCIsxUhiRVoyBiQRVQ1WrjNdiSHVxoEKRA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000564b1005ec83c0ce
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

From
https://lists.freebsd.org/archives/freebsd-ports/2022-August/002476.html

---
With both FLANG and MLIR:
(...)
[13:49:55] [01] [13:49:17] Finished devel/llvm13 | llvm13-13.0.1_3: Success

load averages:   . . . MaxObs:   6.43,   5.91,   5.77
(Note: spanned overnight so the nightly cron job was
spanned.)

Note: Given that SWAP was used, I report more
Max(imum)Obs(erved) figures for this case than
I've been reporting for other tests:

5696Mi MaxObsActive
1775Mi MaxObsSwapUsed
7374Mi MaxObs(Act+Lndry+SwapUsed)
9333Mi MaxObs(Act+Wir+Lndry+SwapUsed)

Reminder: MaximumOfASum <=3D TheSumOfTheMaximums
Note: The various Maximums need not be from the same time.


By contrast . . .

No FLANG, no MLIR:

(...)
[11:07:48] [01] [08:58:53] Finished devel/llvm13 | llvm13-13.0.1_3: Success

load averages:   . . . MaxObs:   5.31,   4.94,   4.79

1479Mi MaxObs(Act+Lndry+SwapUsed)

So, vastly less RAM+SWAP space use. Somewhat under
5 hours less build time (about 9hr vs. somewhat under 14hr).
---

Archimedes Gaviola  escreveu no dia quarta,
2/11/2022 =C3=A0(s) 21:10:

>
>
> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
>
>>
>> > Okay noted on GPT not MBR method with gpart.
>>
>>
>>> I did not happen to have a MBR example around. So I could
>>> only show GPT. The note was more to avoid confusion than
>>> anything, since the two are not equivalent for how they
>>> work.
>>>
>>
>> Okay, this is noted.
>>
>>
>>>
>>> > By the way, what's the proper allocation size of swap in FreeBSD?
>>>
>>> FreeBSD has a waring that it produces indicating possible mistuning
>>> when you potentially have too much. An example is:
>>>
>>> warning: total configured swap (2097152 pages) exceeds maximum
>>> recommended amount (916632 pages).
>>> warning: increase kern.maxswzone or reduce amount of swap.
>>>
>>> The numbers are dependent on the amount of RAM present and
>>> other details.
>>>
>>> My understanding is that increasing kern.maxswzone has tradeoffs.
>>> I avoid getting the message because I do not understand the
>>> tradeoffs or how to manage the tradeoffs or even how to identify
>>> an instance of hitting such a tradeoff.
>>>
>>
>> Basically the warning messages you've shared are the messages I
>> encountered with my older FreeBSD system running on MIPS32 at the time I
>> allocated a swap partition because of the higher allocation size I've ma=
de.
>> So what I did is gradually adjust the swap size until such warnings
>> disappear. I did not go through the details as most likely it requires a
>> deeper knowledge on this area. That's why this experience illuminated me
>> again with my RPi 3B ARM system on the proper allocation size. But yes,
>> below you have the allocation size.
>>
>>
>>>
>>> For aarch64 I've been about to have swap of about 3.4 to 3.5 or
>>> so times the amount of RAM without getting the warnings. That
>>> is why 3.5G in my RPi3B example. (So RAM+SWAP approx.=3D 4.5*RAM.)
>>> (armv7 only allows more like 1.8 times the RAM before getting
>>> the warning.)
>>>
>>
>> Okay this is noted. I'll take the 3.5G size as this is based on your
>> actual experience.
>>
>>
>>>
>>> I avoid even getting too close to the warning as there seems to
>>> be some build-to-build variability in what fits vs. not. This
>>> avoids having to frequently adjust the size.
>>>
>>>
>> I, too, need to avoid such warnings as much as possible with this RPi 3B
>> configuration.
>>
>>
>>> Going from the other side, how much RAM+SWAP will your activities
>>> use? To avoid accurately figuring out such, you may just want to
>>> have near the 3.4 to 3.5 times RAM. (There have been times when
>>> clang had memory use oddities that required more than normal for
>>> a time, for example.)
>>>
>>
>> I'll just follow the size you have and let me observe how it goes.
>>
>>
>>>
>>> > This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the
>>> capacity of this physical RAM?
>>>
>>> Ultimately your choice. How much parallel activity you
>>> want to attempt likely contributes. If you build ports,
>>> you might do so in a way that uses more RAM+SWAP than
>>> system builds do, for example.
>>>
>>
>> Okay this is noted. For now, building the kernel and world is my goal, n=
o
>> ports yet.
>>
>>
>>>
>>> > (Note: swap file usage is subject to deadlock conditions
>>> > avoided by use of swap partitions.)
>>> >
>>> > This is noted.
>>> >
>>> >
>>> > I use a serial console & ssh session only context to avoid
>>> > having sizable competition for RAM.
>>> >
>>> > I avoid using tmpfs because it competes for RAM use.
>>> >
>>> > I use the likes of ( in, say, /boot/loader/conf ):
>>> >
>>> > #
>>> > # Delay when persistent low free RAM leads to
>>> > # Out Of Memory killing of processes:
>>> > vm.pageout_oom_seq=3D120
>>> >
>>> > This delays potential "killed: failed to reclaim memory" kills,
>>> > possibly long enough to reach a state where sufficient memory is
>>> > reclaimed.
>>> >
>>> > Alright this is well noted too.
>>>
>>> There is tuning related to "a thread waited too long to
>>> allocate a page" that happens because of paging I/O
>>> characteristics. But but I've not hit that type of
>>> error.
>>>
>>> I'll also note that the "out of swap space" case is a
>>> misnomer in that it is one or two of 2 internal data
>>> structures that is out of space, not necessarily the
>>> swap space on the media. Again, I've not ever hit that
>>> type of error. I'm not aware of tuning for this case.
>>>
>>
>> Okay, noted as well on this info. Let me just try the 3.5G swap
>> allocation. I will post another thread if I ever encounter these types o=
f
>> errors.
>>
>>
>>>
>>> > I'll note that the status "killed: failed to reclaim memory" does
>>> > not require that swap be used much at all. Sustained low free RAM
>>> > from just one process that always stays runnable and has a
>>> > sufficiently large active set of pages can be sufficient to end up
>>> > with such kills. Having swap allows for inactive pages to get out
>>> > of the way, which can help.
>>> >
>>> > I use the likes of ( in, say, /etc/ssyctl.conf ):
>>> >
>>> > #
>>> > # Together this pair avoids swapping out the process kernel stacks.
>>> > # This avoids processes for interacting with the system from being
>>> > # hung-up.
>>> > vm.swap_enabled=3D0
>>> > vm.swap_idle_enabled=3D0
>>> >
>>> > This allows paging to the swap space but disallows moving
>>> > kernel thread stacks to the swap space. Otherwise the
>>> > processes used to interact with the RPi3 can become
>>> > non-runnable, preventing such interactions.
>>> >
>>> > Okay this too is well noted.
>>> >
>>> >
>>> > I have NVMe or SSD based USB media, not microsd cards nor
>>> > spinning rust. (I use just bootcode.bin and timeout files
>>> > on microsd media for the RPi3B. Even the rest of the RPi*
>>> > firmware is on the USB media, as well as u-boot.bin .)
>>>
>>> This may contribute to why I've never gotten a "a thread
>>> waited too long to allocate a page" on any system. (Some
>>> systems, while bootable via USB3 media I have, also have
>>> have even faster internal media that is normally used.)
>>>
>>
>> Alright so there's significance.
>>
>>
>>>
>>> > My usage of such a configuration struture for building
>>> > software (world, kernel, ports) applies to all the
>>> > systems I do such with, including ones with a lot more
>>> > resources, including a lot more RAM.
>>> >
>>> > Thanks for these inputs, noted on these things! I haven't tried NVMe
>>> and SSD media in my RPi 3B. So, they are far more superior as compared =
to
>>> microSD cards when it comes to building software?
>>>
>>> My understanding is that microsd card media is fairly
>>> generally not as good for such contexts: slower, fails
>>> sooner, etc.
>>>
>>
>> I'll take note of this one as I may encounter those attributes along the
>> course of building software. It's something that I need to explore and d=
o
>> some research ahead.
>>
>>
>>>
>>> I happen to boot multiple types of machines from the
>>> same media so I use USB3 media that is compatible with
>>> USB2 use, a single such USB3 device not needing a
>>> powered hub for use on the likes of an RPi3B. (Lots
>>> of USB3 media around would require external power for
>>> USB2 or an RPi3B use.) I need a powered hub for 2 or
>>> more such media on a RPi3B.
>>>
>>
>> Okay, that's right.  In my experience, inserting some devices tends to
>> reset the 4 USB ports' power, thus to prevent such behavior needs a
>> self-powered hub.
>>
>>
> Hi Mark,
>
> Just an update, as kernel and world compilation is ongoing with my RPi3B
> system (with swap partition) is doing so far, so good. It already surpass=
ed
> the tough part that breaks the compilation process here.
> ...
>
> llvm-tblgen -gen-asm-matcher  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-asm-writer  -I /usr/src/contrib/llvm-project/llvm/includ=
e
> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-callingconv  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-compress-inst-emitter  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-dag-isel  -I /usr/src/contrib/llvm-project/llvm/include
> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-disassembler  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-global-isel  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-instr-info  -I /usr/src/contrib/llvm-project/llvm/includ=
e
> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-emitter  -I /usr/src/contrib/llvm-project/llvm/include -=
I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-pseudo-lowering  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-register-bank  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-register-info  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-searchable-tables  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-subtarget  -I /usr/src/contrib/llvm-project/llvm/include
> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-searchable-tables  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc
>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>
> Any thoughts why this part is quite a challenge when it comes to memory
> usage? The other architectures do not possess such behavior... just curio=
us.
>
> Thanks and best regards,
> Archimedes
>
>
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000564b1005ec83c0ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

From https:=
//lists.freebsd.org/archives/freebsd-ports/2022-August/002476.html

---
With both FLANG and MLIR:

(...)

[13:49:55] [01] [13:49:17] Finished devel/llvm13 | llvm13-13.0.1_3: Success=




load averages:=C2=A0 =C2=A0. . . MaxObs:=C2=A0 =C2=A06.43,=C2=A0 =C2=A05.91=
,=C2=A0 =C2=A05.77

(Note: spanned overnight so the nightly cron job was

spanned.)



Note: Given that SWAP was used, I report more

Max(imum)Obs(erved) figures for this case than

I've been reporting for other tests:



5696Mi MaxObsActive

1775Mi MaxObsSwapUsed

7374Mi MaxObs(Act+Lndry+SwapUsed)

9333Mi MaxObs(Act+Wir+Lndry+SwapUsed)



Reminder: MaximumOfASum <=3D TheSumOfTheMaximums

Note: The various Maximums need not be from the same time.





By contrast . . .



No FLANG, no MLIR:

<=
span>(...)

[11:07:48] [01] [08:58:53] Finished devel/llvm13 | llvm13-13.0.1_3: =
Success



load averages:=C2=A0 =C2=A0. . . MaxObs:=C2=A0 =C2=A05.31,=C2=A0 =C2=A04.94=
,=C2=A0 =C2=A04.79



1479Mi MaxObs(Act+Lndry+SwapUsed)



So, vastly less RAM+SWAP space use. Somewhat under

5 hours less build time (about 9hr vs. somewhat under 14hr).
---<=
br>

Archimedes Gaviola <archimedes.gaviola@gmail.com> escreveu no dia=
 quarta, 2/11/2022 =C3=A0(s) 21:10:


On Mon, Oct 31, 2=
022 at 1:47 PM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
<=
div dir=3D"ltr">
> Okay noted on GPT not MBR method with g=
part.




I did not happen to have a MBR example around. So I could

only show GPT. The note was more to avoid confusion than

anything, since the two are not equivalent for how they

work.

Okay, this is noted.
=
=C2=A0



> By the way, what's the proper allocation size of swap in FreeBSD?<=
br>


FreeBSD has a waring that it produces indicating possible mistuning

when you potentially have too much. An example is:



warning: total configured swap (2097152 pages) exceeds maximum recommended =
amount (916632 pages).

warning: increase kern.maxswzone or reduce amount of swap.



The numbers are dependent on the amount of RAM present and

other details.



My understanding is that increasing kern.maxswzone has tradeoffs.

I avoid getting the message because I do not understand the

tradeoffs or how to manage the tradeoffs or even how to identify

an instance of hitting such a tradeoff.

Basically the warning messages you've shared are the messages I encoun=
tered with my older FreeBSD system running on MIPS32 at the time I allocate=
d a swap partition because of the higher allocation size I've made. So =
what I did is gradually adjust the swap size until such warnings disappear.=
 I did not go through the details as most likely it requires a deeper knowl=
edge on this area. That's why this experience illuminated me again with=
 my RPi 3B ARM system on the proper allocation size. But yes, below you hav=
e the allocation size. 
=C2=A0



For aarch64 I've been about to have swap of about 3.4 to 3.5 or

so times the amount of RAM without getting the warnings. That

is why 3.5G in my RPi3B example. (So RAM+SWAP approx.=3D 4.5*RAM.)

(armv7 only allows more like 1.8 times the RAM before getting

the warning.)

Okay this is noted. I'=
;ll take the 3.5G size as this is based on your actual experience.
=C2=A0



I avoid even getting too close to the warning as there seems to

be some build-to-build variability in what fits vs. not. This

avoids having to frequently adjust the size.



I, too, need to avoid such warnings as=
 much as possible with this RPi 3B configuration.
=C2=A0

Going from the other side, how much RAM+SWAP will your activities

use? To avoid accurately figuring out such, you may just want to

have near the 3.4 to 3.5 times RAM. (There have been times when

clang had memory use oddities that required more than normal for

a time, for example.)

I'll just fol=
low the size you have and let me observe how it goes.
=C2=A0
<=
/div>



> This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the capac=
ity of this physical RAM?



Ultimately your choice. How much parallel activity you

want to attempt likely contributes. If you build ports,

you might do so in a way that uses more RAM+SWAP than

system builds do, for example.

Okay thi=
s is noted. For now, building the kernel and world is my goal, no ports yet=
.
=C2=A0=C2=A0 



> (Note: swap file usage is subject to deadlock conditions

> avoided by use of swap partitions.)

> 

> This is noted.

>=C2=A0 

> 

> I use a serial console & ssh session only context to avoid

> having sizable competition for RAM.

> 

> I avoid using tmpfs because it competes for RAM use.

> 

> I use the likes of ( in, say, /boot/loader/conf ):

> 

> #

> # Delay when persistent low free RAM leads to

> # Out Of Memory killing of processes:

> vm.pageout_oom_seq=3D120

> 

> This delays potential "killed: failed to reclaim memory" kil=
ls,

> possibly long enough to reach a state where sufficient memory is

> reclaimed.

> 

> Alright this is well noted too.



There is tuning related to "a thread waited too long to

allocate a page" that happens because of paging I/O

characteristics. But but I've not hit that type of

error.



I'll also note that the "out of swap space" case is a

misnomer in that it is one or two of 2 internal data

structures that is out of space, not necessarily the

swap space on the media. Again, I've not ever hit that

type of error. I'm not aware of tuning for this case.
<=
div>
Okay, noted as well on this info. Let me just try the 3.=
5G swap allocation. I will post another thread if I ever encounter these ty=
pes of errors.
=C2=A0



> I'll note that the status "killed: failed to reclaim memory&q=
uot; does

> not require that swap be used much at all. Sustained low free RAM

> from just one process that always stays runnable and has a

> sufficiently large active set of pages can be sufficient to end up

> with such kills. Having swap allows for inactive pages to get out

> of the way, which can help.

> 

> I use the likes of ( in, say, /etc/ssyctl.conf ):

> 

> #

> # Together this pair avoids swapping out the process kernel stacks.
> # This avoids processes for interacting with the system from being

> # hung-up.

> vm.swap_enabled=3D0

> vm.swap_idle_enabled=3D0

> 

> This allows paging to the swap space but disallows moving

> kernel thread stacks to the swap space. Otherwise the

> processes used to interact with the RPi3 can become

> non-runnable, preventing such interactions.

> 

> Okay this too is well noted.

>=C2=A0 

> 

> I have NVMe or SSD based USB media, not microsd cards nor

> spinning rust. (I use just bootcode.bin and timeout files

> on microsd media for the RPi3B. Even the rest of the RPi*

> firmware is on the USB media, as well as u-boot.bin .)



This may contribute to why I've never gotten a "a thread

waited too long to allocate a page" on any system. (Some

systems, while bootable via USB3 media I have, also have

have even faster internal media that is normally used.)

Alright so there's significance.
=C2=A0
<=
/div>



> My usage of such a configuration struture for building

> software (world, kernel, ports) applies to all the

> systems I do such with, including ones with a lot more

> resources, including a lot more RAM.

> 

> Thanks for these inputs, noted on these things! I haven't tried NV=
Me and SSD media in my RPi 3B. So, they are far more superior as compared t=
o microSD cards when it comes to building software?



My understanding is that microsd card media is fairly

generally not as good for such contexts: slower, fails

sooner, etc.

I'll take note of this=
 one as I may encounter those attributes along the course of building softw=
are. It's something that I need to explore and do some research ahead.<=
br>
=C2=A0



I happen to boot multiple types of machines from the

same media so I use USB3 media that is compatible with

USB2 use, a single such USB3 device not needing a

powered hub for use on the likes of an RPi3B. (Lots

of USB3 media around would require external power for

USB2 or an RPi3B use.) I need a powered hub for 2 or

more such media on a RPi3B.

Okay, that's=
 right.=C2=A0 In my experience, inserting some devices tends to reset the 4=
 USB ports' power, thus to prevent such behavior needs a self-powered h=
ub.


<=
/div>
Hi Mark,

Just an update, as kernel and w=
orld compilation is ongoing with my RPi3B system (with swap partition) is d=
oing so far, so good. It already surpassed the tough part that breaks the c=
ompilation process here.
...
<=
div>
llvm-tblgen -gen-asm-matcher =C2=A0-I /usr/src/contrib/l=
lvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/R=
ISCV =C2=A0-d RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc =C2=A0/usr=
/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -ge=
n-asm-writer =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/sr=
c/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenAsmWriter.inc=
.d -o RISCVGenAsmWriter.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Ta=
rget/RISCV/RISCV.td
llvm-tblgen -gen-callingconv =C2=A0-I /usr/src/contr=
ib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Targ=
et/RISCV =C2=A0-d RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc =C2=
=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tbl=
gen -gen-compress-inst-emitter =C2=A0-I /usr/src/contrib/llvm-project/llvm/=
include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RIS=
CVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc =C2=A0/us=
r/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -g=
en-dag-isel =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src=
/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenDAGISel.inc.d =
-o RISCVGenDAGISel.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/=
RISCV/RISCV.td
llvm-tblgen -gen-disassembler =C2=A0-I /usr/src/contrib/l=
lvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/R=
ISCV =C2=A0-d RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTable=
s.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.tdllvm-tblgen -gen-global-isel =C2=A0-I /usr/src/contrib/llvm-project/llvm/i=
nclude -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISC=
VGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc =C2=A0/usr/src/contrib/llvm-=
project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-instr-info =C2=
=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-p=
roject/llvm/lib/Target/RISCV =C2=A0-d RISCVGenInstrInfo.inc.d -o RISCVGenIn=
strInfo.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV=
.td
llvm-tblgen -gen-emitter =C2=A0-I /usr/src/contrib/llvm-project/llvm=
/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RI=
SCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc =C2=A0/usr/src/contr=
ib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-pseudo-l=
owering =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenMCPseudoLowering.i=
nc.d -o RISCVGenMCPseudoLowering.inc =C2=A0/usr/src/contrib/llvm-project/ll=
vm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-register-bank =C2=A0-I /us=
r/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/ll=
vm/lib/Target/RISCV =C2=A0-d RISCVGenRegisterBank.inc.d -o RISCVGenRegister=
Bank.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td=

llvm-tblgen -gen-register-info =C2=A0-I /usr/src/contrib/llvm-project/l=
lvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d=
 RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc =C2=A0/usr/src/cont=
rib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-searcha=
ble-tables =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/=
contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenSearchableTable=
s.inc.d -o RISCVGenSearchableTables.inc =C2=A0/usr/src/contrib/llvm-project=
/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-subtarget =C2=A0-I /usr=
/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llv=
m/lib/Target/RISCV =C2=A0-d RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtarge=
tInfo.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.t=
d
llvm-tblgen -gen-searchable-tables =C2=A0-I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=
=A0-d RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc =C2=A0/usr=
/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

Any thoughts why this part is quite a challenge when it comes to mem=
ory usage? The other architectures do not possess such behavior... just cur=
ious.

Thanks and best regards,
Archimede=
s

=C2=A0




-- 
Nuno Teixeira
FreeBSD Co=
mmitter (ports)


--000000000000564b1005ec83c0ce--

From nobody Wed Nov  2 21:46:47 2022
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 4N2gTJ01LNz4h1sM
	for ; Wed,  2 Nov 2022 21:47:00 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N2gTH6pRYz3FRt
	for ; Wed,  2 Nov 2022 21:46:59 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667425619;
	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=W/8vgSdvBUEqUWkJth9V8pfe9Poxrnf/h4hFi/xvWcM=;
	b=TFebn7TdSGSxJhgy4dEtkYrRclHM9Vi307Btm5+AGpfK+qtbAsjLyTgNg9pX1Y1x55I1QU
	uujwwVsjnce1kLe3HByNNSCdgp0ZworrXASWwOGLz0CFwCBdsWUzz6+dKfgq9jL0aSsbew
	y8RbRoDLp1KNvulWUOaivfelMAKtwfKMdXyEBJMTU9fM7r9wuVEF1HJiz1Fp+wZLuqdps3
	z6vz0AcfA5C0/Xs0gZunvma4FaqqScYHSnu/S2CfLBUC+Qz9AfZ9cOerr7mLRWqfKzLe35
	HXZnJ401FVrSl34HGclp1ZPAq4eWFLoOR2RfcKyBY3gc5CSC6ddg+dn6PzdYMw==
Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N2gTH5ZQGzVBk
	for ; Wed,  2 Nov 2022 21:46:59 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-ua1-f48.google.com with SMTP id p1so86892uak.11
        for ; Wed, 02 Nov 2022 14:46:59 -0700 (PDT)
X-Gm-Message-State: ACrzQf0f/dmel3Qj3jQy1b4uA3COGkWSV3ZVmngMIUfnPyv/4jxBzmjm
	MIEKvaIOzKLgC0rLO/C5ptuJLa5rgbNg6+Loy+o=
X-Google-Smtp-Source: AMsMyM7P14H6ol0VUveIbZBl3x0bVFgXvJ7iNbiH4Q7ZkbMoJu50cK0IfVpWqxJ4EpfGHbsO5BEWGAidUotPT4B4ek8=
X-Received: by 2002:ab0:204b:0:b0:3b5:7f97:3000 with SMTP id
 g11-20020ab0204b000000b003b57f973000mr11192514ual.13.1667425619323; Wed, 02
 Nov 2022 14:46:59 -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: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
  
In-Reply-To: 
From: Nuno Teixeira 
Date: Wed, 2 Nov 2022 21:46:47 +0000
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Archimedes Gaviola 
Cc: Mark Millard , freebsd-current 
Content-Type: multipart/alternative; boundary="000000000000bab44505ec83c7a4"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667425619;
	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=W/8vgSdvBUEqUWkJth9V8pfe9Poxrnf/h4hFi/xvWcM=;
	b=cgupmm3Aq3lm2ZivsfFsBej+yJy44aDg4TDxBwinmAMndNlMKclguworCta/SjXuPTof1W
	IX2kMT8nVAVIRVf3w/LPqqrKowBuqyE5T6k53Gt/2heipd8w3XeuswAgzMAi9sUHye+Ddg
	E18/FRNo+CoXqiklgUw+jaDANFpUBT02mGmkdr9nzDXksnoK7TvDApGBv00C8VYArUQ7pu
	mo9NW8Z6uVbjVyXgGVT4MNuZnG42EcuwUae+q3N5Hkn/h/yphlRSK6l8LchSzNM+5gK9TV
	77tN94zj/Gs3HW1Y3TfvKC1XrWpXtU3I+ckWsHMD3L1lg9re9Ks0SuF1DyK93g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667425619; a=rsa-sha256; cv=none;
	b=pEPjWFR5+j1dbFEcqzi1YtmVzG3KmGej/NrHB/4IKVGrcgBJOUIMdd9LHkLB+XIX6uPJE5
	QMFpPxv49tO53udA6gRbgptpBFBJoMIj+IJunyYZyZhPqfnZWzEHn1+aAP4a+6/305Oeqz
	eHqdAlLWJAOzQru5S5XHaho4QzBWWJBv94mnazXoDDm2H1rFsQiPiQ1VO/too9xLCcWEZk
	EgpbTAP9IjKDwNBHAiMS4C9KoiJbI2Z7X6+KhAsJk5JRqAHG/5dr5dD9piGG63xN/E4cmU
	Fqr+uP32+GwpW43rn8Oz+4NHhu2n1v8T5oemD+hoRRXjwMBsk1dxcB1zGB3IyA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

--000000000000bab44505ec83c7a4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry, wrong post!

Nuno Teixeira  escreveu no dia quarta, 2/11/2022 =C3=
=A0(s)
21:44:

> Hello,
>
> From
> https://lists.freebsd.org/archives/freebsd-ports/2022-August/002476.html
>
> ---
> With both FLANG and MLIR:
> (...)
> [13:49:55] [01] [13:49:17] Finished devel/llvm13 | llvm13-13.0.1_3: Succe=
ss
>
> load averages:   . . . MaxObs:   6.43,   5.91,   5.77
> (Note: spanned overnight so the nightly cron job was
> spanned.)
>
> Note: Given that SWAP was used, I report more
> Max(imum)Obs(erved) figures for this case than
> I've been reporting for other tests:
>
> 5696Mi MaxObsActive
> 1775Mi MaxObsSwapUsed
> 7374Mi MaxObs(Act+Lndry+SwapUsed)
> 9333Mi MaxObs(Act+Wir+Lndry+SwapUsed)
>
> Reminder: MaximumOfASum <=3D TheSumOfTheMaximums
> Note: The various Maximums need not be from the same time.
>
>
> By contrast . . .
>
> No FLANG, no MLIR:
>
> (...)
> [11:07:48] [01] [08:58:53] Finished devel/llvm13 | llvm13-13.0.1_3: Succe=
ss
>
> load averages:   . . . MaxObs:   5.31,   4.94,   4.79
>
> 1479Mi MaxObs(Act+Lndry+SwapUsed)
>
> So, vastly less RAM+SWAP space use. Somewhat under
> 5 hours less build time (about 9hr vs. somewhat under 14hr).
> ---
>
> Archimedes Gaviola  escreveu no dia quarta,
> 2/11/2022 =C3=A0(s) 21:10:
>
>>
>>
>> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <
>> archimedes.gaviola@gmail.com> wrote:
>>
>>>
>>> > Okay noted on GPT not MBR method with gpart.
>>>
>>>
>>>> I did not happen to have a MBR example around. So I could
>>>> only show GPT. The note was more to avoid confusion than
>>>> anything, since the two are not equivalent for how they
>>>> work.
>>>>
>>>
>>> Okay, this is noted.
>>>
>>>
>>>>
>>>> > By the way, what's the proper allocation size of swap in FreeBSD?
>>>>
>>>> FreeBSD has a waring that it produces indicating possible mistuning
>>>> when you potentially have too much. An example is:
>>>>
>>>> warning: total configured swap (2097152 pages) exceeds maximum
>>>> recommended amount (916632 pages).
>>>> warning: increase kern.maxswzone or reduce amount of swap.
>>>>
>>>> The numbers are dependent on the amount of RAM present and
>>>> other details.
>>>>
>>>> My understanding is that increasing kern.maxswzone has tradeoffs.
>>>> I avoid getting the message because I do not understand the
>>>> tradeoffs or how to manage the tradeoffs or even how to identify
>>>> an instance of hitting such a tradeoff.
>>>>
>>>
>>> Basically the warning messages you've shared are the messages I
>>> encountered with my older FreeBSD system running on MIPS32 at the time =
I
>>> allocated a swap partition because of the higher allocation size I've m=
ade.
>>> So what I did is gradually adjust the swap size until such warnings
>>> disappear. I did not go through the details as most likely it requires =
a
>>> deeper knowledge on this area. That's why this experience illuminated m=
e
>>> again with my RPi 3B ARM system on the proper allocation size. But yes,
>>> below you have the allocation size.
>>>
>>>
>>>>
>>>> For aarch64 I've been about to have swap of about 3.4 to 3.5 or
>>>> so times the amount of RAM without getting the warnings. That
>>>> is why 3.5G in my RPi3B example. (So RAM+SWAP approx.=3D 4.5*RAM.)
>>>> (armv7 only allows more like 1.8 times the RAM before getting
>>>> the warning.)
>>>>
>>>
>>> Okay this is noted. I'll take the 3.5G size as this is based on your
>>> actual experience.
>>>
>>>
>>>>
>>>> I avoid even getting too close to the warning as there seems to
>>>> be some build-to-build variability in what fits vs. not. This
>>>> avoids having to frequently adjust the size.
>>>>
>>>>
>>> I, too, need to avoid such warnings as much as possible with this RPi 3=
B
>>> configuration.
>>>
>>>
>>>> Going from the other side, how much RAM+SWAP will your activities
>>>> use? To avoid accurately figuring out such, you may just want to
>>>> have near the 3.4 to 3.5 times RAM. (There have been times when
>>>> clang had memory use oddities that required more than normal for
>>>> a time, for example.)
>>>>
>>>
>>> I'll just follow the size you have and let me observe how it goes.
>>>
>>>
>>>>
>>>> > This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the
>>>> capacity of this physical RAM?
>>>>
>>>> Ultimately your choice. How much parallel activity you
>>>> want to attempt likely contributes. If you build ports,
>>>> you might do so in a way that uses more RAM+SWAP than
>>>> system builds do, for example.
>>>>
>>>
>>> Okay this is noted. For now, building the kernel and world is my goal,
>>> no ports yet.
>>>
>>>
>>>>
>>>> > (Note: swap file usage is subject to deadlock conditions
>>>> > avoided by use of swap partitions.)
>>>> >
>>>> > This is noted.
>>>> >
>>>> >
>>>> > I use a serial console & ssh session only context to avoid
>>>> > having sizable competition for RAM.
>>>> >
>>>> > I avoid using tmpfs because it competes for RAM use.
>>>> >
>>>> > I use the likes of ( in, say, /boot/loader/conf ):
>>>> >
>>>> > #
>>>> > # Delay when persistent low free RAM leads to
>>>> > # Out Of Memory killing of processes:
>>>> > vm.pageout_oom_seq=3D120
>>>> >
>>>> > This delays potential "killed: failed to reclaim memory" kills,
>>>> > possibly long enough to reach a state where sufficient memory is
>>>> > reclaimed.
>>>> >
>>>> > Alright this is well noted too.
>>>>
>>>> There is tuning related to "a thread waited too long to
>>>> allocate a page" that happens because of paging I/O
>>>> characteristics. But but I've not hit that type of
>>>> error.
>>>>
>>>> I'll also note that the "out of swap space" case is a
>>>> misnomer in that it is one or two of 2 internal data
>>>> structures that is out of space, not necessarily the
>>>> swap space on the media. Again, I've not ever hit that
>>>> type of error. I'm not aware of tuning for this case.
>>>>
>>>
>>> Okay, noted as well on this info. Let me just try the 3.5G swap
>>> allocation. I will post another thread if I ever encounter these types =
of
>>> errors.
>>>
>>>
>>>>
>>>> > I'll note that the status "killed: failed to reclaim memory" does
>>>> > not require that swap be used much at all. Sustained low free RAM
>>>> > from just one process that always stays runnable and has a
>>>> > sufficiently large active set of pages can be sufficient to end up
>>>> > with such kills. Having swap allows for inactive pages to get out
>>>> > of the way, which can help.
>>>> >
>>>> > I use the likes of ( in, say, /etc/ssyctl.conf ):
>>>> >
>>>> > #
>>>> > # Together this pair avoids swapping out the process kernel stacks.
>>>> > # This avoids processes for interacting with the system from being
>>>> > # hung-up.
>>>> > vm.swap_enabled=3D0
>>>> > vm.swap_idle_enabled=3D0
>>>> >
>>>> > This allows paging to the swap space but disallows moving
>>>> > kernel thread stacks to the swap space. Otherwise the
>>>> > processes used to interact with the RPi3 can become
>>>> > non-runnable, preventing such interactions.
>>>> >
>>>> > Okay this too is well noted.
>>>> >
>>>> >
>>>> > I have NVMe or SSD based USB media, not microsd cards nor
>>>> > spinning rust. (I use just bootcode.bin and timeout files
>>>> > on microsd media for the RPi3B. Even the rest of the RPi*
>>>> > firmware is on the USB media, as well as u-boot.bin .)
>>>>
>>>> This may contribute to why I've never gotten a "a thread
>>>> waited too long to allocate a page" on any system. (Some
>>>> systems, while bootable via USB3 media I have, also have
>>>> have even faster internal media that is normally used.)
>>>>
>>>
>>> Alright so there's significance.
>>>
>>>
>>>>
>>>> > My usage of such a configuration struture for building
>>>> > software (world, kernel, ports) applies to all the
>>>> > systems I do such with, including ones with a lot more
>>>> > resources, including a lot more RAM.
>>>> >
>>>> > Thanks for these inputs, noted on these things! I haven't tried NVMe
>>>> and SSD media in my RPi 3B. So, they are far more superior as compared=
 to
>>>> microSD cards when it comes to building software?
>>>>
>>>> My understanding is that microsd card media is fairly
>>>> generally not as good for such contexts: slower, fails
>>>> sooner, etc.
>>>>
>>>
>>> I'll take note of this one as I may encounter those attributes along th=
e
>>> course of building software. It's something that I need to explore and =
do
>>> some research ahead.
>>>
>>>
>>>>
>>>> I happen to boot multiple types of machines from the
>>>> same media so I use USB3 media that is compatible with
>>>> USB2 use, a single such USB3 device not needing a
>>>> powered hub for use on the likes of an RPi3B. (Lots
>>>> of USB3 media around would require external power for
>>>> USB2 or an RPi3B use.) I need a powered hub for 2 or
>>>> more such media on a RPi3B.
>>>>
>>>
>>> Okay, that's right.  In my experience, inserting some devices tends to
>>> reset the 4 USB ports' power, thus to prevent such behavior needs a
>>> self-powered hub.
>>>
>>>
>> Hi Mark,
>>
>> Just an update, as kernel and world compilation is ongoing with my RPi3B
>> system (with swap partition) is doing so far, so good. It already surpas=
sed
>> the tough part that breaks the compilation process here.
>> ...
>>
>> llvm-tblgen -gen-asm-matcher  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-asm-writer  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-callingconv  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-compress-inst-emitter  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-dag-isel  -I /usr/src/contrib/llvm-project/llvm/include
>> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-disassembler  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-global-isel  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-instr-info  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-emitter  -I /usr/src/contrib/llvm-project/llvm/include
>> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-pseudo-lowering  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-register-bank  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-register-info  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-searchable-tables  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-subtarget  -I /usr/src/contrib/llvm-project/llvm/includ=
e
>> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> llvm-tblgen -gen-searchable-tables  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc
>>  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>
>> Any thoughts why this part is quite a challenge when it comes to memory
>> usage? The other architectures do not possess such behavior... just curi=
ous.
>>
>> Thanks and best regards,
>> Archimedes
>>
>>
>>
>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>


--=20
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000bab44505ec83c7a4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Sorry, wrong post!

Nuno Teixeira <eduardo@freebsd.org> escreveu no dia quarta, 2/=
11/2022 =C3=A0(s) 21:44:
Hello,


---
With bo=
th FLANG and MLIR:

(...)

[13:49:55] [01] [13:49:17] Finished devel/llvm13 | llvm13-13.0.1_3: Success=




load averages:=C2=A0 =C2=A0. . . MaxObs:=C2=A0 =C2=A06.43,=C2=A0 =C2=A05.91=
,=C2=A0 =C2=A05.77

(Note: spanned overnight so the nightly cron job was

spanned.)



Note: Given that SWAP was used, I report more

Max(imum)Obs(erved) figures for this case than

I've been reporting for other tests:



5696Mi MaxObsActive

1775Mi MaxObsSwapUsed

7374Mi MaxObs(Act+Lndry+SwapUsed)

9333Mi MaxObs(Act+Wir+Lndry+SwapUsed)



Reminder: MaximumOfASum <=3D TheSumOfTheMaximums

Note: The various Maximums need not be from the same time.





By contrast . . .



No FLANG, no MLIR:

<=
span>(...)

[11:07:48] [01] [08:58:53] Finished devel/llvm13 | llvm13-13.0.1_3: =
Success



load averages:=C2=A0 =C2=A0. . . MaxObs:=C2=A0 =C2=A05.31,=C2=A0 =C2=A04.94=
,=C2=A0 =C2=A04.79



1479Mi MaxObs(Act+Lndry+SwapUsed)



So, vastly less RAM+SWAP space use. Somewhat under

5 hours less build time (about 9hr vs. somewhat under 14hr).
---<=
br>

Archimedes Gaviola <archimedes.gaviola@gmail.com> escreveu no dia=
 quarta, 2/11/2022 =C3=A0(s) 21:10:


On Mon, Oct 31, 2=
022 at 1:47 PM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
<=
div dir=3D"ltr">
> Okay noted on GPT not MBR method with g=
part.




I did not happen to have a MBR example around. So I could

only show GPT. The note was more to avoid confusion than

anything, since the two are not equivalent for how they

work.

Okay, this is noted.
=
=C2=A0



> By the way, what's the proper allocation size of swap in FreeBSD?<=
br>


FreeBSD has a waring that it produces indicating possible mistuning

when you potentially have too much. An example is:



warning: total configured swap (2097152 pages) exceeds maximum recommended =
amount (916632 pages).

warning: increase kern.maxswzone or reduce amount of swap.



The numbers are dependent on the amount of RAM present and

other details.



My understanding is that increasing kern.maxswzone has tradeoffs.

I avoid getting the message because I do not understand the

tradeoffs or how to manage the tradeoffs or even how to identify

an instance of hitting such a tradeoff.

Basically the warning messages you've shared are the messages I encoun=
tered with my older FreeBSD system running on MIPS32 at the time I allocate=
d a swap partition because of the higher allocation size I've made. So =
what I did is gradually adjust the swap size until such warnings disappear.=
 I did not go through the details as most likely it requires a deeper knowl=
edge on this area. That's why this experience illuminated me again with=
 my RPi 3B ARM system on the proper allocation size. But yes, below you hav=
e the allocation size. 
=C2=A0



For aarch64 I've been about to have swap of about 3.4 to 3.5 or

so times the amount of RAM without getting the warnings. That

is why 3.5G in my RPi3B example. (So RAM+SWAP approx.=3D 4.5*RAM.)

(armv7 only allows more like 1.8 times the RAM before getting

the warning.)

Okay this is noted. I'=
;ll take the 3.5G size as this is based on your actual experience.
=C2=A0



I avoid even getting too close to the warning as there seems to

be some build-to-build variability in what fits vs. not. This

avoids having to frequently adjust the size.



I, too, need to avoid such warnings as=
 much as possible with this RPi 3B configuration.
=C2=A0

Going from the other side, how much RAM+SWAP will your activities

use? To avoid accurately figuring out such, you may just want to

have near the 3.4 to 3.5 times RAM. (There have been times when

clang had memory use oddities that required more than normal for

a time, for example.)

I'll just fol=
low the size you have and let me observe how it goes.
=C2=A0
<=
/div>



> This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the capac=
ity of this physical RAM?



Ultimately your choice. How much parallel activity you

want to attempt likely contributes. If you build ports,

you might do so in a way that uses more RAM+SWAP than

system builds do, for example.

Okay thi=
s is noted. For now, building the kernel and world is my goal, no ports yet=
.
=C2=A0=C2=A0 



> (Note: swap file usage is subject to deadlock conditions

> avoided by use of swap partitions.)

> 

> This is noted.

>=C2=A0 

> 

> I use a serial console & ssh session only context to avoid

> having sizable competition for RAM.

> 

> I avoid using tmpfs because it competes for RAM use.

> 

> I use the likes of ( in, say, /boot/loader/conf ):

> 

> #

> # Delay when persistent low free RAM leads to

> # Out Of Memory killing of processes:

> vm.pageout_oom_seq=3D120

> 

> This delays potential "killed: failed to reclaim memory" kil=
ls,

> possibly long enough to reach a state where sufficient memory is

> reclaimed.

> 

> Alright this is well noted too.



There is tuning related to "a thread waited too long to

allocate a page" that happens because of paging I/O

characteristics. But but I've not hit that type of

error.



I'll also note that the "out of swap space" case is a

misnomer in that it is one or two of 2 internal data

structures that is out of space, not necessarily the

swap space on the media. Again, I've not ever hit that

type of error. I'm not aware of tuning for this case.
<=
div>
Okay, noted as well on this info. Let me just try the 3.=
5G swap allocation. I will post another thread if I ever encounter these ty=
pes of errors.
=C2=A0



> I'll note that the status "killed: failed to reclaim memory&q=
uot; does

> not require that swap be used much at all. Sustained low free RAM

> from just one process that always stays runnable and has a

> sufficiently large active set of pages can be sufficient to end up

> with such kills. Having swap allows for inactive pages to get out

> of the way, which can help.

> 

> I use the likes of ( in, say, /etc/ssyctl.conf ):

> 

> #

> # Together this pair avoids swapping out the process kernel stacks.
> # This avoids processes for interacting with the system from being

> # hung-up.

> vm.swap_enabled=3D0

> vm.swap_idle_enabled=3D0

> 

> This allows paging to the swap space but disallows moving

> kernel thread stacks to the swap space. Otherwise the

> processes used to interact with the RPi3 can become

> non-runnable, preventing such interactions.

> 

> Okay this too is well noted.

>=C2=A0 

> 

> I have NVMe or SSD based USB media, not microsd cards nor

> spinning rust. (I use just bootcode.bin and timeout files

> on microsd media for the RPi3B. Even the rest of the RPi*

> firmware is on the USB media, as well as u-boot.bin .)



This may contribute to why I've never gotten a "a thread

waited too long to allocate a page" on any system. (Some

systems, while bootable via USB3 media I have, also have

have even faster internal media that is normally used.)

Alright so there's significance.
=C2=A0
<=
/div>



> My usage of such a configuration struture for building

> software (world, kernel, ports) applies to all the

> systems I do such with, including ones with a lot more

> resources, including a lot more RAM.

> 

> Thanks for these inputs, noted on these things! I haven't tried NV=
Me and SSD media in my RPi 3B. So, they are far more superior as compared t=
o microSD cards when it comes to building software?



My understanding is that microsd card media is fairly

generally not as good for such contexts: slower, fails

sooner, etc.

I'll take note of this=
 one as I may encounter those attributes along the course of building softw=
are. It's something that I need to explore and do some research ahead.<=
br>
=C2=A0



I happen to boot multiple types of machines from the

same media so I use USB3 media that is compatible with

USB2 use, a single such USB3 device not needing a

powered hub for use on the likes of an RPi3B. (Lots

of USB3 media around would require external power for

USB2 or an RPi3B use.) I need a powered hub for 2 or

more such media on a RPi3B.

Okay, that's=
 right.=C2=A0 In my experience, inserting some devices tends to reset the 4=
 USB ports' power, thus to prevent such behavior needs a self-powered h=
ub.


<=
/div>
Hi Mark,

Just an update, as kernel and w=
orld compilation is ongoing with my RPi3B system (with swap partition) is d=
oing so far, so good. It already surpassed the tough part that breaks the c=
ompilation process here.
...
<=
div>
llvm-tblgen -gen-asm-matcher =C2=A0-I /usr/src/contrib/l=
lvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/R=
ISCV =C2=A0-d RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc =C2=A0/usr=
/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -ge=
n-asm-writer =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/sr=
c/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenAsmWriter.inc=
.d -o RISCVGenAsmWriter.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Ta=
rget/RISCV/RISCV.td
llvm-tblgen -gen-callingconv =C2=A0-I /usr/src/contr=
ib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Targ=
et/RISCV =C2=A0-d RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc =C2=
=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tbl=
gen -gen-compress-inst-emitter =C2=A0-I /usr/src/contrib/llvm-project/llvm/=
include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RIS=
CVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc =C2=A0/us=
r/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -g=
en-dag-isel =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src=
/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenDAGISel.inc.d =
-o RISCVGenDAGISel.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/=
RISCV/RISCV.td
llvm-tblgen -gen-disassembler =C2=A0-I /usr/src/contrib/l=
lvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/R=
ISCV =C2=A0-d RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTable=
s.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.tdllvm-tblgen -gen-global-isel =C2=A0-I /usr/src/contrib/llvm-project/llvm/i=
nclude -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISC=
VGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc =C2=A0/usr/src/contrib/llvm-=
project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-instr-info =C2=
=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-p=
roject/llvm/lib/Target/RISCV =C2=A0-d RISCVGenInstrInfo.inc.d -o RISCVGenIn=
strInfo.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV=
.td
llvm-tblgen -gen-emitter =C2=A0-I /usr/src/contrib/llvm-project/llvm=
/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RI=
SCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc =C2=A0/usr/src/contr=
ib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-pseudo-l=
owering =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenMCPseudoLowering.i=
nc.d -o RISCVGenMCPseudoLowering.inc =C2=A0/usr/src/contrib/llvm-project/ll=
vm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-register-bank =C2=A0-I /us=
r/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/ll=
vm/lib/Target/RISCV =C2=A0-d RISCVGenRegisterBank.inc.d -o RISCVGenRegister=
Bank.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td=

llvm-tblgen -gen-register-info =C2=A0-I /usr/src/contrib/llvm-project/l=
lvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d=
 RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc =C2=A0/usr/src/cont=
rib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-searcha=
ble-tables =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/=
contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenSearchableTable=
s.inc.d -o RISCVGenSearchableTables.inc =C2=A0/usr/src/contrib/llvm-project=
/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-subtarget =C2=A0-I /usr=
/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llv=
m/lib/Target/RISCV =C2=A0-d RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtarge=
tInfo.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.t=
d
llvm-tblgen -gen-searchable-tables =C2=A0-I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=
=A0-d RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc =C2=A0/usr=
/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

Any thoughts why this part is quite a challenge when it comes to mem=
ory usage? The other architectures do not possess such behavior... just cur=
ious.

Thanks and best regards,
Archimede=
s

=C2=A0




-- 
Nuno Teixeira
FreeBSD Co=
mmitter (ports)




-- 
Nun=
o Teixeira
FreeBSD Committer (ports)


--000000000000bab44505ec83c7a4--

From nobody Wed Nov  2 23:52:40 2022
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 4N2kGS03Fwz4hGGg
	for ; Wed,  2 Nov 2022 23:52:48 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.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 4N2kGQ3kzCz3T2f
	for ; Wed,  2 Nov 2022 23:52:46 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667433164; bh=ulDP8axw2cmtK71xqHRmciA5N9p5mqfSCPW4JsU5ovM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=riP7qs0/Gy2eM8KBxx6uxV17ZlQ+pHrzx3m7/AU/wUQ7dszARrdzEIbKhHdBUgEYo0MvFt3DDwfv3MQMV4iIJgcSLpprOnueMLRfCRIxCrbTvjaPDr7fbgCKoEddRqA6vMhzARI1yU5KecdTl/0ZmaeqJoLpgClAA4fZQksJAKbc4AyUxj/SpiNejCDXasBf/QKvwrVOcnPwuGUKrv02WkfyGfwCb85wVMhMfzDUB/6N6IW/NZqqvBuNpkTWoZzu4QXNkzxki+UI+AmXmIv15zPJkNpo8giMW6lDNjgmaa/UyhHrP5FiJonIiZvW1uPO8gdz9+AYURRMIooXWGntog==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667433164; bh=QisC53Lue7e81HNDaduhvija7vuE6qFo6R6hws5+XBf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jr60bWTQRzTvq5z7XdmCS+cw8RdDNtPgzJ00LvBYr+jnelDRZg/+J0PMdaF7SFLrN39TvAeh02kwtE9BMP1PQaeIKq38wHm433yYOWzGeQmaUnFAFNTWLa+ca9bZ0BwvB3dLIrfZ8H69onuUJGNmDIdEEWQG4cN/ZyMQiC2v3SVUf8sK2DqAqraPjeDQQA+AJMRQqXQa8kM0AFXQ+p0EcZlKjL7raRGVwIcSdcz4mgTPL4QA3APs1v+cINJeJ61bWLzbmMfLaqPEeb2dz8wR7xIE1w1aq8EdoX0yciq8ahL8DSrWUpncXQilFmYQjrpYPJsIN4FXAWdc4P/m3XkNFA==
X-YMail-OSG: I1QEI3kVM1mQlzSBjO4.Cr0l0v8xEczTpqf6KQdpCW_48JOr6rqN8slIzUM3fdA
 4N87A2pY5IALhuDwjHj1.xnjCfFnqAd8cJc4aW9neRzg3Kcc41YjewZH171eOISzCh6WHgW5Js0i
 wMZ63s.lPQ_eaGcjBHYErQMyJ0xrZ6IMRH2DqVZonPw6c_sN_8LI8JlyOjHGCnQk8CbQ2zo3hIbP
 bVJPzOLn4FzzYYmdzIw7xjbK5s_awQ6O4xfVn5cf8qDLcxjO66ebKTFp.J71k1ewCaMIWKwgo4e5
 74zEaUzQHDyYz8nWmocvhY.KXaUD27cRD5dpx77nJevHYiM4FKjlnvBx7Pjk6JpoH8nOzHQw73XT
 Itm_7Jyfe52puSgRNJFep371oDJzrH8xlIpCeaJ5J5MD6Ti27n9MOXV7AcI08.JnK0WcotDXCFlm
 m.Yh14Wj9GBp5c7q6V17omaaJEn4qWH6J1gbjslwQk.QweAqEIMHuoTAQ_.zKXnaniPXZTIlySP_
 PGeoLBs5S29jSoEUTcIKgI4Wa5xqVfiWgcboovzf63z_BE_rjtBagNQDN.PINOv352X.WG2ABL9W
 Wo2lQwAyT3Zes23BIjJCKNuRE1ENYNjew2yFrbRI4CXbx3eKj03VDA8pMDoenGAA7iDcwSgLnASo
 jkGQ4zSUDbtOeBIxKeyfymagDJTrNvtWOLuDTsFctGnafEYEAmsZ_NdBsfdhe8puolvyGrvsCcYs
 4S1n0bPmy1eoQOv0M.C6nvtGgToyz5VYTmLK4rTqg2l97JmHGgDnZ3p9DWKjS9l8cBqLq9MY5yjf
 r5IFEiiR.M4_AXzXP6StJKd4KJ0j0XB94WVgPYhlrcf6b1P8f5VeByC_UADiJTkA.ZNTKn8O6_2H
 UzwM04aeSZpWe.HgkYqhh0nw5Pj4lkqfO0XONPskW6zB7jNzZ1pOOGO.gGWY.p_rB.brKqKyxi6i
 FH7Z0GRUA3_hSqCNU_dpn0YMucNL70QfaH3Fwe7jeRQN8sEc1GoQnb_TN3jwmNbiWKyj7IB2uR80
 TMcyjTk_RyW7__zFu6IF_B8N4e.2z2wmUsmL8EzUd2Ux_YBoJ8TmSYnvnnk57ybYI7EkorvpA0Hj
 U_Nz6HkSwhDUYKufwwUAB.QtBOtBphKAUcaZWZYf1YF3zouBwL2RtktPi5zyfBvCAv14Qhpkp9eP
 JzHIkYhP.ths1x5QGu2UpNFsEVugUfdxvr26MHOEcNjipZqcsjSDZWQbc856jRCOx8bHqkAB8hUj
 YvncgmZ6hdXFq3ctPZc5FMo_CyB4xfFbHVsRQVOLV5GKcatQhNVaU.PfRExdVp3b43pdEPEzBvz7
 fs0B7bzBC8Qfvk4ZKHs4tjo.fRG8M8ZLgwuycc8EXrSm7TXoUlWkoVsulv3JCMmRpoJ69bL_5WfA
 mSA2EQ0R0WJfH9XUFRgLSxJHTZnwobEsDSm8d_yA3pH0AiXmVMkf9Y_6fOcWWoRVr.i597m3G6uM
 Q9xrQi4WSUN.wnIaiamEA8vi13GHgn6Do1zaX5XJY0crc94J1WnLxR4OMA98AsaWa0kP3s2JMO65
 YJdjyl8pVPJ6frpfjLsl4eFD0fTGovIn3BDRByYRcJB6DakjpSjsHkGqgon6XOvdMGLfvsg6HVpF
 3vBe.vnnRfKf85AOUmnzD.pIGzGKsNKPuR.lQRx2jBCpf.78EdfVOoZswY8Y..__NYRkZ4PC7ixr
 NClaHeWelTbfhhlB1TPhL5sT7pvz_YFirkN7MioT_ZnAw0k4EkMr_5tCOLyCBNpHWcrG3n4nMtR_
 xxJW8UOI_RLUxEnV_FYin7AYplRp6wNLZ_5whfpM3icbDi0hUUJRXNCrIs_vrxFHbNsjvkQ9kuyG
 28AuvaV06NQEVGvZm_adlZqoal.Wz1ujVLf8GMRjTFetqgulnh3__lnh973i5g2hz5TZ7Yw6gP.s
 sWRCWaZTDDTDEGyZ_EL5cO5nQ8w7S8AlGH4dnRfv5qM4.pufQ2MZktyuzwnvl9qamze4eu_pQM2l
 UEk_I.J.PVeh_rdVugresQUKx6MLQ1_BDXIRNobmyL1iBB0VOkJFjw0qA.AZBCSMyGcv1XbOSv.t
 L5SKYG5OV.8Ee9KCW9ZiO229OlwN9nhOuBul.QVj9UgZqe9DOWVbLlo1riXqQXoLnq8H2VszM29S
 tyk6crAziywgVwk4YnVZseliYG9CKhMH0g.1UuEYw8bB5GB67thJTn0nk9qnAycZ5m5BLojrA8Z.
 .f4sxqzeHtGYriRCE53LJT6YVLyzRoQzLkF5XACg3HyyNExpWKd89xPaZhB08TIKG976ht2gPX3w
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 2 Nov 2022 23:52:44 +0000
Received: by hermes--production-ne1-6bcfb7fb87-s7whx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d3dd359c258b6cd3740c614188fe598f;
          Wed, 02 Nov 2022 23:52:42 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
From: Mark Millard 
In-Reply-To: 
Date: Wed, 2 Nov 2022 16:52:40 -0700
Cc: freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
 
 
 
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N2kGQ3kzCz3T2f
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="riP7qs0/";
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.90)[-0.901];
	NEURAL_HAM_MEDIUM(-0.80)[-0.800];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]
X-ThisMailContainsUnwantedMimeParts: N

On 2022-Nov-2, at 14:09, Archimedes Gaviola =
 wrote:

> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola =
 wrote:
>=20
> . . .
>=20
> . . .
>=20
>=20
> Hi Mark,
>=20
> Just an update, as kernel and world compilation is ongoing with my =
RPi3B system (with swap partition) is doing so far, so good. It already =
surpassed the tough part that breaks the compilation process here.
> ...
>=20
> llvm-tblgen -gen-asm-matcher  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-asm-writer  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-callingconv  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-compress-inst-emitter  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-dag-isel  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-disassembler  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-global-isel  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-instr-info  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-emitter  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-pseudo-lowering  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-register-bank  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-register-info  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-searchable-tables  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-subtarget  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-searchable-tables  -I =
/usr/src/contrib/llvm-project/llvm/include -I =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d =
RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc  =
/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>=20
> Any thoughts why this part is quite a challenge when it comes to =
memory usage? The other architectures do not possess such behavior... =
just curious.

I've not done any monitoring of buildworld buildkernel build
activity (RAM use, memory space use, swap partition use over
time) on RPi3B class hardware in a very long time.

Even on systems that I have monitored in more recent times,
what I usually monitor tends to be builds with -jN (such as
-j4 fora 4-hardware-thread system). (I once did have an
example of -j3 taking less time than -j4 on a RPi4B.
Basically, the memory subsystem can be saturated without all
the cores being in use. The extra interference made things
take longer.)

You had listed that you were using the likes of:

# cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64 \
buildkernel buildworld installkernel installworld distribution \
DESTDIR=3D/home/freebsd/rpi3b

I'll note that the standard order of the first 2 is:

buildworld buildkernel

This is because buildworld builds some software that
buildkernel does not build for itself but does use.
There is a kernel-toolchain target for avoiding the
need to do a full buildworld just to buildkernel , so:

kernel-toolchain buildkernel

is an expected sequence.

I do not know how long a from-scratch buildworld
buildkernel without a -jN takes on a RPi3B these
days. If I remember right, for -jN with 1
To: current@freebsd.org
Cc: net@freebsd.org
Subject: trpt(8) to be decomissioned
Message-ID: 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Rspamd-Queue-Id: 4N3RRj098xz44q6
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org
X-Spamd-Result: default: False [-3.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[current@freebsd.org,net@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[freebsd.org];
	R_SPF_SOFTFAIL(0.00)[~all];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[glebius];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	HAS_XAW(0.00)[];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

  Hi,

trpt(8) is utility to pull TCP debugging data from the kernel
in 4.2BSD. We still have it in the base, with corresponding
TCPDEBUG option in the kernel and SO_DEBUG socket option.

At the same time we have much more powerful debugging facilities
for TCP, e.g. the Dtrace probing, the TCP black box logging and
siftr.  These are the tools that modern developers use.

Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@.
None of them new what trpt(8) is :) Looks like a good justification
to me.

-- 
Gleb Smirnoff

From nobody Fri Nov  4 06:03:29 2022
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 4N3VRn1xDzz4h7pJ;
	Fri,  4 Nov 2022 06:03:33 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4N3VRl5kGRz4PdL;
	Fri,  4 Nov 2022 06:03:31 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 2A463TMF070098;
	Fri, 4 Nov 2022 01:03:29 -0500 (CDT)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id CFTWGjGrZGPQEQEA4+wvSQ
	(envelope-from ); Fri, 04 Nov 2022 01:03:29 -0500
From: Mike Karels 
To: Gleb Smirnoff 
Cc: current@freebsd.org, net@freebsd.org
Subject: Re: trpt(8) to be decomissioned
Date: Fri, 04 Nov 2022 01:03:29 -0500
X-Mailer: MailMate (1.14r5921)
Message-ID: <97286FA9-DD47-4EB2-BD7A-C2A8BC8B62B5@karels.net>
In-Reply-To: 
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
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4N3VRl5kGRz4PdL
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net
X-Spamd-Result: default: False [-2.70 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	R_MISSING_CHARSET(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_NO_TLS_LAST(0.10)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MLMMJ_DEST(0.00)[net@freebsd.org,current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[karels.net];
	FREEFALL_USER(0.00)[mike];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote:

>   Hi,
>
> trpt(8) is utility to pull TCP debugging data from the kernel
> in 4.2BSD. We still have it in the base, with corresponding
> TCPDEBUG option in the kernel and SO_DEBUG socket option.
>
> At the same time we have much more powerful debugging facilities
> for TCP, e.g. the Dtrace probing, the TCP black box logging and
> siftr.  These are the tools that modern developers use.
>
> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@.
> None of them new what trpt(8) is :) Looks like a good justification
> to me.

I have used trpt, but not for many years.  It was done before tcpdump
as well.  Its time has long since gone.

		Mike
> -- =

> Gleb Smirnoff

From nobody Fri Nov  4 07:19:19 2022
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 4N3X7R3H2pz4hHp3
	for ; Fri,  4 Nov 2022 07:19:31 +0000 (UTC)
	(envelope-from max@baroi.com)
Received: from mailin02.mxof.com (mailin02.mxof.com [72.20.134.35])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.mxof.com", Issuer "GeoTrust TLS DV RSA Mixed SHA256 2020 CA-1" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N3X7P603Mz3Hq1
	for ; Fri,  4 Nov 2022 07:19:29 +0000 (UTC)
	(envelope-from max@baroi.com)
Received: from mta01.mxof.net (mta01.mxof.net [10.1.0.31])
	by mailin02.mxof.com (8.15.2/8.15.2/Debian-8) with ESMTPS id 2A47JLTQ005505
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
	Fri, 4 Nov 2022 07:19:21 GMT
Received: from mta01.mxof.net (localhost [127.0.0.1])
	by mta01.mxof.net (Postfix) with ESMTPS id 2A7312607E0;
	Fri,  4 Nov 2022 00:19:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mta01.mxof.net (Postfix) with ESMTP id 1C3D0260E4C;
	Fri,  4 Nov 2022 00:19:21 -0700 (PDT)
Received: from mta01.mxof.net ([127.0.0.1])
	by localhost (mta01.mxof.net [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id YwUW8SIjonlB; Fri,  4 Nov 2022 00:19:21 -0700 (PDT)
Received: from dummy.faircode.eu (cpe-172-116-59-145.socal.res.rr.com [172.116.59.145])
	(Authenticated sender: max@baroi.com)
	by mta01.mxof.net (Postfix) with ESMTPSA id CD5B72607E0;
	Fri,  4 Nov 2022 00:19:20 -0700 (PDT)
Date: Fri, 4 Nov 2022 07:19:19 +0000 (UTC)
From: Max Baroi 
To: Mike Karels 
Cc: current@freebsd.org
Message-ID: <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.com>
In-Reply-To: <97286FA9-DD47-4EB2-BD7A-C2A8BC8B62B5@karels.net>
References:  <97286FA9-DD47-4EB2-BD7A-C2A8BC8B62B5@karels.net>
Subject: Re: trpt(8) to be decomissioned
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-Correlation-ID: <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.com>
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing:default, base:default, @@RPTN)
X-Spam-Score: 0.00 () [Hold at 7.10] 
X-CanIt-Geo: No geolocation information available for 10.1.0.31
X-CanItPRO-Stream: outgoing:default (inherits from base:default)
X-Canit-Stats-ID: 028E7jlId - b19985e7b721 - 20221104
X-Antispam-Training-Forget: https://spamblock.prxy.com/b.php?c=f&i=028E7jlId&m=b19985e7b721&rlm=outgoing&t=20221104
X-Antispam-Training-Nonspam: https://spamblock.prxy.com/b.php?c=n&i=028E7jlId&m=b19985e7b721&rlm=outgoing&t=20221104
X-Antispam-Training-Phish: https://spamblock.prxy.com/b.php?c=p&i=028E7jlId&m=b19985e7b721&rlm=outgoing&t=20221104
X-Antispam-Training-Spam: https://spamblock.prxy.com/b.php?c=s&i=028E7jlId&m=b19985e7b721&rlm=outgoing&t=20221104
X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.1.0.12
X-Rspamd-Queue-Id: 4N3X7P603Mz3Hq1
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of max@baroi.com designates 72.20.134.35 as permitted sender) smtp.mailfrom=max@baroi.com
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:72.20.134.32/28];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:394437, ipnet:72.20.134.0/24, country:US];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DMARC_NA(0.00)[baroi.com];
	RCVD_COUNT_FIVE(0.00)[6];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[max];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

I'm sorry if this is an inappropriate suggestion, but I think it would be n=
eat if there was a place in the ports hierarchy for retired programs like t=
rpt. Maybe a "historical" or "archival" directory for programs phased out o=
f from base, especially ones that are almost four decades old.

-Max

Nov 3, 2022 11:04:07 PM Mike Karels :

> On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote:
>=20
>> =C2=A0 Hi,
>>=20
>> trpt(8) is utility to pull TCP debugging data from the kernel
>> in 4.2BSD. We still have it in the base, with corresponding
>> TCPDEBUG option in the kernel and SO_DEBUG socket option.
>>=20
>> At the same time we have much more powerful debugging facilities
>> for TCP, e.g. the Dtrace probing, the TCP black box logging and
>> siftr.=C2=A0 These are the tools that modern developers use.
>>=20
>> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@.
>> None of them new what trpt(8) is :) Looks like a good justification
>> to me.
>=20
> I have used trpt, but not for many years.=C2=A0 It was done before tcpdum=
p
> as well.=C2=A0 Its time has long since gone.
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mike
>> --=20
>> Gleb Smirnoff

From nobody Fri Nov  4 16:40:20 2022
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 4N3mbd6M58z4hBf8
	for ; Fri,  4 Nov 2022 16:41:17 +0000 (UTC)
	(envelope-from glebius@freebsd.org)
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-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N3mbc4tBPz3K4n
	for ; Fri,  4 Nov 2022 16:41:16 +0000 (UTC)
	(envelope-from glebius@freebsd.org)
Received: from cell.glebi.us (localhost [127.0.0.1])
	by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 2A4GeMYZ007604
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 4 Nov 2022 09:40:23 -0700 (PDT)
	(envelope-from glebius@freebsd.org)
Received: (from glebius@localhost)
	by cell.glebi.us (8.16.1/8.16.1/Submit) id 2A4GeLNj007603;
	Fri, 4 Nov 2022 09:40:21 -0700 (PDT)
	(envelope-from glebius@freebsd.org)
X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f
Date: Fri, 4 Nov 2022 09:40:20 -0700
From: Gleb Smirnoff 
To: Max Baroi 
Cc: Mike Karels , current@freebsd.org
Subject: Re: trpt(8) to be decomissioned
Message-ID: 
References: 
 <97286FA9-DD47-4EB2-BD7A-C2A8BC8B62B5@karels.net>
 <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.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=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.com>
X-Rspamd-Queue-Id: 4N3mbc4tBPz3K4n
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org
X-Spamd-Result: default: False [-3.09 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.989];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_THREE(0.00)[3];
	R_SPF_SOFTFAIL(0.00)[~all:c];
	DMARC_NA(0.00)[freebsd.org];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[glebius];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	HAS_XAW(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

  Max,

the reason I want to retire it is not that it consumes 40 Kb
in the repository.  The reason is that knows kernel structures,
and fails to compile after changes to them.  So the tool that
nobody uses requires special care when working on TCP.  The
kernel headers disclose the structures for trpt (with some
protection with _WANT_TCPCB, though) and some software from
ports (not calling names!) would start use them too. Now a
kernel developer needs to care not only about trpt, but
about this software, too.

On the kernel side there is also TCPDEBUG code that needs
to be kept compilable, while apparently nobody uses it.

On Fri, Nov 04, 2022 at 07:19:19AM +0000, Max Baroi wrote:
M> I'm sorry if this is an inappropriate suggestion, but I think it would be neat if there was a place in the ports hierarchy for retired programs like trpt. Maybe a "historical" or "archival" directory for programs phased out of from base, especially ones that are almost four decades old.
M> 
M> -Max
M> 
M> Nov 3, 2022 11:04:07 PM Mike Karels :
M> 
M> > On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote:
M> > 
M> >>   Hi,
M> >> 
M> >> trpt(8) is utility to pull TCP debugging data from the kernel
M> >> in 4.2BSD. We still have it in the base, with corresponding
M> >> TCPDEBUG option in the kernel and SO_DEBUG socket option.
M> >> 
M> >> At the same time we have much more powerful debugging facilities
M> >> for TCP, e.g. the Dtrace probing, the TCP black box logging and
M> >> siftr.  These are the tools that modern developers use.
M> >> 
M> >> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@.
M> >> None of them new what trpt(8) is :) Looks like a good justification
M> >> to me.
M> > 
M> > I have used trpt, but not for many years.  It was done before tcpdump
M> > as well.  Its time has long since gone.
M> > 
M> >         Mike
M> >> -- 
M> >> Gleb Smirnoff
M> 
M> 

-- 
Gleb Smirnoff

From nobody Fri Nov  4 17:07:00 2022
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 4N3nB05wdbz4hFQk
	for ; Fri,  4 Nov 2022 17:07:36 +0000 (UTC)
	(envelope-from max@baroi.com)
Received: from mailin02.mxof.com (mailin02.mxof.com [72.20.134.35])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.mxof.com", Issuer "GeoTrust TLS DV RSA Mixed SHA256 2020 CA-1" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N3n9z6sfKz3NYt;
	Fri,  4 Nov 2022 17:07:35 +0000 (UTC)
	(envelope-from max@baroi.com)
Received: from mta01.mxof.net (mta01.mxof.net [10.1.0.31])
	by mailin02.mxof.com (8.15.2/8.15.2/Debian-8) with ESMTPS id 2A4H725J015126
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
	Fri, 4 Nov 2022 17:07:24 GMT
Received: from mta01.mxof.net (localhost [127.0.0.1])
	by mta01.mxof.net (Postfix) with ESMTPS id EC5D32607E0;
	Fri,  4 Nov 2022 10:07:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mta01.mxof.net (Postfix) with ESMTP id DDC312612A0;
	Fri,  4 Nov 2022 10:07:02 -0700 (PDT)
Received: from mta01.mxof.net ([127.0.0.1])
	by localhost (mta01.mxof.net [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id qNSA1t9aPSct; Fri,  4 Nov 2022 10:07:02 -0700 (PDT)
Received: from [192.168.1.239] (cpe-172-116-59-145.socal.res.rr.com [172.116.59.145])
	(Authenticated sender: max@baroi.com)
	by mta01.mxof.net (Postfix) with ESMTPSA id A213B2607E0;
	Fri,  4 Nov 2022 10:07:02 -0700 (PDT)
Message-ID: <558fd211-3d92-240c-f33c-5377a1684444@baroi.com>
Date: Fri, 4 Nov 2022 10:07:00 -0700
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: trpt(8) to be decomissioned
Content-Language: en-US
To: Gleb Smirnoff 
Cc: current@freebsd.org
References: 
 <97286FA9-DD47-4EB2-BD7A-C2A8BC8B62B5@karels.net>
 <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.com>
 
From: Max Baroi 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing:default, base:default, @@RPTN)
X-Spam-Score: 0.00 () [Hold at 7.10] 
X-CanIt-Geo: No geolocation information available for 10.1.0.31
X-CanItPRO-Stream: outgoing:default (inherits from base:default)
X-Canit-Stats-ID: 028Eh732k - 80a069bfb220 - 20221104
X-Antispam-Training-Forget: https://spamblock.prxy.com/b.php?c=f&i=028Eh732k&m=80a069bfb220&rlm=outgoing&t=20221104
X-Antispam-Training-Nonspam: https://spamblock.prxy.com/b.php?c=n&i=028Eh732k&m=80a069bfb220&rlm=outgoing&t=20221104
X-Antispam-Training-Phish: https://spamblock.prxy.com/b.php?c=p&i=028Eh732k&m=80a069bfb220&rlm=outgoing&t=20221104
X-Antispam-Training-Spam: https://spamblock.prxy.com/b.php?c=s&i=028Eh732k&m=80a069bfb220&rlm=outgoing&t=20221104
X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.1.0.12
X-Rspamd-Queue-Id: 4N3n9z6sfKz3NYt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of max@baroi.com designates 72.20.134.35 as permitted sender) smtp.mailfrom=max@baroi.com
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	R_SPF_ALLOW(-0.20)[+ip4:72.20.134.32/28];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:394437, ipnet:72.20.134.0/24, country:US];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DMARC_NA(0.00)[baroi.com];
	RCVD_COUNT_FIVE(0.00)[6];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[max];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

Gleb,

Thank you for the response. I rescind my suggestion.

-Max

On 11/4/2022 9:40 AM, Gleb Smirnoff wrote:
>    Max,
>
> the reason I want to retire it is not that it consumes 40 Kb
> in the repository.  The reason is that knows kernel structures,
> and fails to compile after changes to them.  So the tool that
> nobody uses requires special care when working on TCP.  The
> kernel headers disclose the structures for trpt (with some
> protection with _WANT_TCPCB, though) and some software from
> ports (not calling names!) would start use them too. Now a
> kernel developer needs to care not only about trpt, but
> about this software, too.
>
> On the kernel side there is also TCPDEBUG code that needs
> to be kept compilable, while apparently nobody uses it.
>
> On Fri, Nov 04, 2022 at 07:19:19AM +0000, Max Baroi wrote:
> M> I'm sorry if this is an inappropriate suggestion, but I think it wou=
ld be neat if there was a place in the ports hierarchy for retired progra=
ms like trpt. Maybe a "historical" or "archival" directory for programs p=
hased out of from base, especially ones that are almost four decades old.
> M>
> M> -Max
> M>
> M> Nov 3, 2022 11:04:07 PM Mike Karels :
> M>
> M> > On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote:
> M> >
> M> >> =C2=A0 Hi,
> M> >>
> M> >> trpt(8) is utility to pull TCP debugging data from the kernel
> M> >> in 4.2BSD. We still have it in the base, with corresponding
> M> >> TCPDEBUG option in the kernel and SO_DEBUG socket option.
> M> >>
> M> >> At the same time we have much more powerful debugging facilities
> M> >> for TCP, e.g. the Dtrace probing, the TCP black box logging and
> M> >> siftr.=C2=A0 These are the tools that modern developers use.
> M> >>
> M> >> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@.
> M> >> None of them new what trpt(8) is :) Looks like a good justificati=
on
> M> >> to me.
> M> >
> M> > I have used trpt, but not for many years.=C2=A0 It was done before=
 tcpdump
> M> > as well.=C2=A0 Its time has long since gone.
> M> >
> M> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mike
> M> >> --
> M> >> Gleb Smirnoff
> M>
> M>
>

From nobody Fri Nov  4 17:35:17 2022
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 4N3nq95SgBz4hJTY
	for ; Fri,  4 Nov 2022 17:36:21 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N3nq93mXfz3RLk;
	Fri,  4 Nov 2022 17:36:21 +0000 (UTC)
	(envelope-from 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 2A4HZIbI078530;
	Fri, 4 Nov 2022 10:35:24 -0700 (PDT)
	(envelope-from bsd-lists@bsdforge.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
Date: Fri, 04 Nov 2022 10:35:17 -0700
From: Chris 
To: Gleb Smirnoff 
Cc: Max Baroi , Mike Karels ,
        current@freebsd.org
Subject: Re: trpt(8) to be decomissioned
In-Reply-To: 
References: 
 <97286FA9-DD47-4EB2-BD7A-C2A8BC8B62B5@karels.net>
 <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.com>
 
User-Agent: UDNSMS/17.0
Message-ID: 
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_b88e1c6315e239983193a3683d633181"
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4N3nq93mXfz3RLk
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-Spamd-Result: default: False [0.00 / 15.00];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_b88e1c6315e239983193a3683d633181
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed

On 2022-11-04 09:40, Gleb Smirnoff wrote:
> Max,
> 
> the reason I want to retire it is not that it consumes 40 Kb
> in the repository.  The reason is that knows kernel structures,
> and fails to compile after changes to them.  So the tool that
> nobody uses requires special care when working on TCP.  The
> kernel headers disclose the structures for trpt (with some
> protection with _WANT_TCPCB, though) and some software from
> ports (not calling names!) would start use them too. Now a
> kernel developer needs to care not only about trpt, but
> about this software, too.
> 
> On the kernel side there is also TCPDEBUG code that needs
> to be kept compilable, while apparently nobody uses it.
While I really hate hearing that small utils
(almost elegant in their simplicity) that have worked perfectly
well for a great many years must be kicked to the curb. I guess
I can see your point. However I think TCPDEBUG affects a great
deal more that trpt(8). I hope your not implying that it should
go as well.

> 
> On Fri, Nov 04, 2022 at 07:19:19AM +0000, Max Baroi wrote:
> M> I'm sorry if this is an inappropriate suggestion, but I think it would be 
> neat
> if there was a place in the ports hierarchy for retired programs like trpt. 
> Maybe
> a "historical" or "archival" directory for programs phased out of from base,
> especially ones that are almost four decades old.
> M>
> M> -Max
> M>
> M> Nov 3, 2022 11:04:07 PM Mike Karels :
> M>
> M> > On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote:
> M> >
> M> >>   Hi,
> M> >>
> M> >> trpt(8) is utility to pull TCP debugging data from the kernel
> M> >> in 4.2BSD. We still have it in the base, with corresponding
> M> >> TCPDEBUG option in the kernel and SO_DEBUG socket option.
> M> >>
> M> >> At the same time we have much more powerful debugging facilities
> M> >> for TCP, e.g. the Dtrace probing, the TCP black box logging and
> M> >> siftr.  These are the tools that modern developers use.
modern developer(s): those whom create things that scratch their itch,
without looking hard enough to see that something else was already available. 
;-)

> M> >>
> M> >> Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@.
> M> >> None of them new what trpt(8) is :) Looks like a good justification
> M> >> to me.
> M> >
> M> > I have used trpt, but not for many years.  It was done before tcpdump
> M> > as well.  Its time has long since gone.
> M> >
> M> >         Mike
> M> >> --
> M> >> Gleb Smirnoff
> M>
> M>
--chris
--=_b88e1c6315e239983193a3683d633181
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_b88e1c6315e239983193a3683d633181--

From nobody Fri Nov  4 17:47:09 2022
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 4N3p3t62r3z4hKdZ
	for ; Fri,  4 Nov 2022 17:47:22 +0000 (UTC)
	(envelope-from wlosh@bsdimp.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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N3p3s5XFfz3TNL
	for ; Fri,  4 Nov 2022 17:47:21 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: by mail-ed1-x536.google.com with SMTP id 21so8732117edv.3
        for ; Fri, 04 Nov 2022 10:47:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=lXOiyT57LASuHpwVRp1SD4NdUcH7RxY6S9FKsSjKnsI=;
        b=ug0hjjjV9+YnKnDS8pgrV5aEs4+27nntsjq6eD3t3LzT8MTKSIHjvvARUz7XqfBQAS
         O1lJC1nKu8TNkICi9ZHqQnNmfZNm7lJMKW4doFcqMyE0hZJATWk8FOxtSdy6xQIkPC65
         wRvPy2dU1y6TRodrPbif4H98eYwoAMTH/UYQsxeXVLmFiiNATny4B+PcXxmYzhl9TR+k
         2Zf+95mH+B0jsPk99020qGyNHR3T1lE4+n5y8EH+92Ol1mzcr1Bl6pqEn3c+nu9PH1Ny
         5rXfImInkQUpYRO85lCrIm8JWADnO3omK4trS2ugV9epNjU0+eA9q5ZFftdWQRWhg31a
         68DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=lXOiyT57LASuHpwVRp1SD4NdUcH7RxY6S9FKsSjKnsI=;
        b=wAgeXhsdKE/WMfy05L2qBQYwGrp+VNeuEcdHfg19S2wsrVOt0QH29NVZ5CTFssLpbk
         4xmD/5J0mh2AdExLDKk4+RGDFxg+WqgcgAq//VSL5EbNqGy7GzklffxBsobOu+kUm4+8
         DjG7Wtjkq/oAL91eSlqO+ZgryreW+yJc7r1izR9kxP/g9VyQHs4kXXIVpYLqmYSUqh2I
         vZLlLdDLYhn9RaIjjB340VWxWkv/MRSkpl+WcmqzOe8IUiypnA6RxrcbSMqjIJIG3u0Z
         mHtSGxpTAwD/HGQR46t3Nbad1uKJWhZn3CVmkXMrvt/3VCpU7xopgE4mKnftTjxbZjvf
         9ZYw==
X-Gm-Message-State: ACrzQf1ez6ECivp8VQ+JQRm4tlIioFbi6KRz79eSYMCyW0VQseQrbAOS
	Opa1bjb2hVCu7x0TunwIcMMNWcZsekQtvCpDO7LX3nvuOCA=
X-Google-Smtp-Source: AMsMyM4l8KnIo1eeE7swOwb6lSte9cgkF34Ne1f7OS/lR4PBkFa5ATJFJkGYa4aTYP8ZjCta4cml4iRNot+ywXDNPcg=
X-Received: by 2002:aa7:c859:0:b0:463:4b54:16a8 with SMTP id
 g25-20020aa7c859000000b004634b5416a8mr29927060edt.136.1667584040316; Fri, 04
 Nov 2022 10:47:20 -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:  <97286FA9-DD47-4EB2-BD7A-C2A8BC8B62B5@karels.net>
 <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.com>
In-Reply-To: <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.com>
From: Warner Losh 
Date: Fri, 4 Nov 2022 11:47:09 -0600
Message-ID: 
Subject: Re: trpt(8) to be decomissioned
To: Max Baroi 
Cc: Mike Karels , current@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000005b4b6205eca8aa5d"
X-Rspamd-Queue-Id: 4N3p3s5XFfz3TNL
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=ug0hjjjV;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::536) smtp.mailfrom=wlosh@bsdimp.com
X-Spamd-Result: default: False [-2.54 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.54)[-0.542];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_TLS_LAST(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000005b4b6205eca8aa5d
Content-Type: text/plain; charset="UTF-8"

On Fri, Nov 4, 2022 at 1:19 AM Max Baroi  wrote:

> I'm sorry if this is an inappropriate suggestion, but I think it would be
> neat if there was a place in the ports hierarchy for retired programs like
> trpt. Maybe a "historical" or "archival" directory for programs phased out
> of from base, especially ones that are almost four decades old.
>

The nice thing about revision control software is that it will have a copy
of this code forever.

Warner

--0000000000005b4b6205eca8aa5d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Nov 4, 2022 at 1:19 AM Max Ba=
roi <max@baroi.com> wrote:
I'm sorry if this=
 is an inappropriate suggestion, but I think it would be neat if there was =
a place in the ports hierarchy for retired programs like trpt. Maybe a &quo=
t;historical" or "archival" directory for programs phased ou=
t of from base, especially ones that are almost four decades old.

The nice thing about revision control software i=
s that it will have a copy of this code forever.

W=
arner


--0000000000005b4b6205eca8aa5d--

From nobody Sat Nov  5 01:54:21 2022
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 4N40sv09KZz4hLQq
	for ; Sat,  5 Nov 2022 01:54:27 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "Client", Issuer "CA" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N40ss5zBdz3T8v;
	Sat,  5 Nov 2022 01:54:25 +0000 (UTC)
	(envelope-from cy.schubert@cschubert.com)
Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183])
	by cmsmtp with ESMTP
	id qzV7oZaV0S8Wrr8O8o7RkG; Sat, 05 Nov 2022 01:54:24 +0000
Received: from spqr.komquats.com ([70.66.148.124])
	by cmsmtp with ESMTPA
	id r8O6o3CwViEh7r8O7obhmz; Sat, 05 Nov 2022 01:54:24 +0000
X-Authority-Analysis: v=2.4 cv=O9kqATxW c=1 sm=1 tr=0 ts=6365c250
 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17
 a=8nJEP1OIZ-IA:10 a=9xFQ1JgjjksA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8
 a=EkcXrb_YAAAA:8 a=yE5n2UwkCyHyYQ-dxykA:9 a=wPNLvfGTeEIA:10
 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22
Received: from slippy.cwsent.com (slippy [10.1.1.91])
	by spqr.komquats.com (Postfix) with ESMTP id 3757016B9;
	Fri,  4 Nov 2022 18:54:22 -0700 (PDT)
Received: by slippy.cwsent.com (Postfix, from userid 1000)
	id DC4B037F; Fri,  4 Nov 2022 18:54:21 -0700 (PDT)
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
Reply-to: Cy Schubert 
From: Cy Schubert 
X-os: FreeBSD
X-Sender: cy@cwsent.com
X-URL: http://www.cschubert.com/
To: Gleb Smirnoff 
cc: Max Baroi , Mike Karels ,
    current@freebsd.org
Subject: Re: trpt(8) to be decomissioned
In-reply-to: 
References:  <97286FA9-DD47-4EB2-BD7A-C2A8BC8B62B5@karels.net> <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.com> 
Comments: In-reply-to Gleb Smirnoff 
   message dated "Fri, 04 Nov 2022 09:40:20 -0700."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Fri, 04 Nov 2022 18:54:21 -0700
Message-Id: <20221105015421.DC4B037F@slippy.cwsent.com>
X-CMAE-Envelope: MS4xfMK44bd4y1wrOMk3y1z+G/uSIXJrhQV8BlaK045wt+X8cI1xNdnyCpTlK8LwxcvYE2MSoGsZ8tYBF39AiWUD7k7GqUEtl2sLbP1vqOmchqM2GPIy/zU1
 IqHEnXZWROSZMMw6TVF7u+53kXjAoAREqEtgELQ6IBgWnwJUNNHm63c53rn2B9IIXpSPvwjm9x2u2S8QR4S34vGyhyghOFn2AuDTDRFEiNz+ZLTPhIJUqToz
 sahjGL5vpIDK/Tw0q9HU1c3F5v1fsjmkHzyvWfsw8sU=
X-Rspamd-Queue-Id: 4N40ss5zBdz3T8v
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com
X-Spamd-Result: default: False [-1.59 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[3.97.99.32:from];
	HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_FIVE(0.00)[5];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US];
	REPLYTO_EQ_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[cschubert.com: no valid DMARC record];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

In message , Gleb Smirnoff writes:
>   Max,
>
> the reason I want to retire it is not that it consumes 40 Kb
> in the repository.  The reason is that knows kernel structures,
> and fails to compile after changes to them.  So the tool that
> nobody uses requires special care when working on TCP.  The
> kernel headers disclose the structures for trpt (with some
> protection with _WANT_TCPCB, though) and some software from
> ports (not calling names!) would start use them too. Now a
> kernel developer needs to care not only about trpt, but
> about this software, too.
 
I recall when Bryan Cantrill came to one of the local hotels here to 
announce Solaris 9, I remember him saying that Solaris truss was now an app 
that called DTrace functions. If people feel the need for trpt-like 
utility, would it be an idea to write it using DTrace calls? Could it be a 
GSoC project? It would be kind of neat for a co-op student or someone to 
get their feet wet with systems programming.

I typically use DTrace when snooping around looking for that proverbial 
needle in a haystack. And TCPDEBUG seems to be one of those things that 
DTrace was designed to replace.

It would be a good project to have a still in school upcoming developer to 
work on.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  https://FreeBSD.org
NTP:               Web:  https://nwtime.org

			e^(i*pi)+1=0





From nobody Sat Nov  5 09:28:51 2022
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 4N4Bym2T1Vz4hGF0
	for ; Sat,  5 Nov 2022 09:29:20 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N4Byl6RYWz475M
	for ; Sat,  5 Nov 2022 09:29:19 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: by mail-yb1-xb35.google.com with SMTP id e123so4068503ybh.11
        for ; Sat, 05 Nov 2022 02:29:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=sQqahxOSQapUklk+S4E8dlsF+Trat29UhVx/OeNVYc0=;
        b=j6ZQFPdoGCaVUHP7gPBENxHqSkOsMw3gTVXHi+x6k0GaKhd6Dn91X9WtEWotfLiZ9G
         41ybU0pJoq5togAgf1AzoFqPB0B63SjPDHMVQempYkfqzzBMji/4T51eHKmjVhKKDJDo
         0cb0ikLAIQA58tgsdwVAREdu20aZ2TLJaar1llVeQ/1QZT1ZW4BOe7RX58bKACsGi/Ns
         LiwQSSBK2qCVxJGWJIYWqJ58/mv3chyXkBkNHPy4Ym7zVtGxblfMSw3CyyhYKE+Bs75Q
         outYG3rPy2XSBvQhGkKnP5uMsKciaPvFf/kt/PEQwVBsydmrvXrduUzs1/c4FnFoBEHk
         XapA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=sQqahxOSQapUklk+S4E8dlsF+Trat29UhVx/OeNVYc0=;
        b=awGJSCvL3Vkxe24RtXXZdhISArmSRY0uRN78o1tyK9gz2EgH+sqcPP+/K21Gqnzw75
         tKSP2YOzU80HR5bA7lAw7DQkGZdTYktFnMfB9+/+bEYDSgLBMdl48XucZxjlJNRCutxq
         YVKeRJNxX1nH9WhV3ZhFtBXyb9keRneGNads1rMBpzRjU/DGEueTtdd944aCmxUJzJbk
         UBQ/lMNMO7PeENb3k2UwsZDWUczyOKWJlyS3WLoshUCuUBY3TNhO9VaCh4ACyr4IqY/H
         VwdDkOvzwMVCPtq09kM2ljbwS0qUxNcdiLTO8P2tBhggK470F4rcJdKH78OoskizSolK
         YtQw==
X-Gm-Message-State: ACrzQf3Zp7vKqaUAV3svdF5y5f7cg6Isleh0V477534JZxJpDHUjeTeS
	3hK3EzETSg+cxI/dbmmjizRZ2S/tHZCj8GPGryY+WML8Gvc=
X-Google-Smtp-Source: AMsMyM5COAsXk3D0PeKUwqKyo0ZVnL1DPKNZjbDqZe5tLdAlFUu1e0mqGXMApiWM5CgCFel59sba+0iBQvrqnlyz7Bc=
X-Received: by 2002:a25:3f86:0:b0:6bc:998:873e with SMTP id
 m128-20020a253f86000000b006bc0998873emr39834872yba.152.1667640559235; Sat, 05
 Nov 2022 02:29:19 -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: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Sat, 5 Nov 2022 17:28:51 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Mark Millard 
Cc: freebsd-current 
Content-Type: multipart/alternative; boundary="00000000000025763905ecb5d31f"
X-Rspamd-Queue-Id: 4N4Byl6RYWz475M
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=j6ZQFPdo;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::b35 as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com
X-Spamd-Result: default: False [-3.83 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.83)[-0.828];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b35:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TAGGED_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TO_DN_ALL(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000025763905ecb5d31f
Content-Type: text/plain; charset="UTF-8"

On Thu, Nov 3, 2022 at 7:52 AM Mark Millard  wrote:

> On 2022-Nov-2, at 14:09, Archimedes Gaviola 
> wrote:
>
> > On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> >
> > . . .
> >
> > . . .
> >
> >
> > Hi Mark,
> >
> > Just an update, as kernel and world compilation is ongoing with my RPi3B
> system (with swap partition) is doing so far, so good. It already surpassed
> the tough part that breaks the compilation process here.
> > ...
> >
> > llvm-tblgen -gen-asm-matcher  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-asm-writer  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-callingconv  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-compress-inst-emitter  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-dag-isel  -I /usr/src/contrib/llvm-project/llvm/include
> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-disassembler  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-global-isel  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-instr-info  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-emitter  -I /usr/src/contrib/llvm-project/llvm/include
> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-pseudo-lowering  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-register-bank  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-register-info  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-searchable-tables  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-subtarget  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> > llvm-tblgen -gen-searchable-tables  -I
> /usr/src/contrib/llvm-project/llvm/include -I
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
> RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc
> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> >
> > Any thoughts why this part is quite a challenge when it comes to memory
> usage? The other architectures do not possess such behavior... just curious.
>

Hi Mark,

Sorry for the late response, I got fully occupied at work for the past few
days due to deliverables. Thanks for your feedback and further inputs!


> I've not done any monitoring of buildworld buildkernel build
> activity (RAM use, memory space use, swap partition use over
> time) on RPi3B class hardware in a very long time.
>

It's alright, it so happened that I just observed that behavior on that
particular part as it requires more memory than other architectures while
compiling. The additional 3.5G swap partition really helps on that part
that's why I was so happy that the compilation continued and never broke.
Your input of having 3.5G swap allocation is very effective.

Even on systems that I have monitored in more recent times,
> what I usually monitor tends to be builds with -jN (such as
> -j4 fora 4-hardware-thread system). (I once did have an
> example of -j3 taking less time than -j4 on a RPi4B.
>

Wow, this is interesting this -jN. Let me explore this as well. I usually
build kernel the old way but recently since I have to include building the
world then I need to use the new way.


> Basically, the memory subsystem can be saturated without all
> the cores being in use. The extra interference made things
> take longer.)
>

Oh I see so it's the reason.


> You had listed that you were using the likes of:
>
> # cd /usr/src ; make KERNCONF=ARM TARGET_ARCH=aarch64 \
> buildkernel buildworld installkernel installworld distribution \
> DESTDIR=/home/freebsd/rpi3b
>
> I'll note that the standard order of the first 2 is:
>
> buildworld buildkernel
>
> This is because buildworld builds some software that
> buildkernel does not build for itself but does use.
>

Okay this is noted, thanks for clarifying and correcting me, I really
appreciate it. I'll reflect on the proper build sequence for much
efficiency.


> There is a kernel-toolchain target for avoiding the
> need to do a full buildworld just to buildkernel , so:
>
> kernel-toolchain buildkernel
>
> is an expected sequence.
>

Okay I'll take note of this too.


> I do not know how long a from-scratch buildworld
> buildkernel without a -jN takes on a RPi3B these
> days. If I remember right, for -jN with 1 saw claims about such they were somewhere in the
> range 36hr..48hr.


There's an ongoing build at the moment, it's already taking 41 hours since
I started it. I took another build when I came back home from the office.


> But I'm unsure of the specific N
> that was in use. Nor do I know the storage media
> type(s) involved, for example. I do not remember
> any reports for -j1.
>

I'll try this with RPi 3B. The current build that I have will be my
baseline.

Use of the likes of: vm.pageout_oom_seq=120
> was essential to such -jN usage on a RPi3B as N
> gets larger. Of course, swap partition use for
> paging was also essential.
>

Wow, that's great! I have this vm.pageout_oom_seq=120 configured in my
system now based on your previous inputs.

Likewise use of:
>
> vm.swap_enabled=0
> vm.swap_idle_enabled=0
>
> can be important to not losing communication
> with the RPi3B. Those last 2 are not tunable
> but are writable:
>
> # sysctl -aT | grep swap_
> # sysctl -aW | grep swap_
> vm.swap_enabled: 0
> . . .
> vm.swap_idle_enabled: 0
> . . .
>
> (This means that they have fewer places where
> assignments can be made. For example, the
> loader can not make the assignments.)
>
> By contrast, vm.pageout_oom_seq is both
> writable and tunable:
>
> # sysctl -aW | grep oom
> . . .
> vm.pageout_oom_seq: 120
> . . .
>
> # sysctl -aT | grep oom
> . . .
> vm.pageout_oom_seq: 120
> . . .
>
> (So even the loader can make such assignments.)
>

Yes, I have these two sysctl parameters configured in the system. Thanks
for the details and further inputs.


> I'll note that I've no interest in using arm hardware
> to build for other types of hardware. So I normally
> have the targeting of support for building for other
> architectures disabled when I build on aarch64 or
> armv7. (Basically, a less complete clang/clang++
> related toolchain ends up being built.)
>

Ah okay, so you mean to say that you disable these other architectures by
declaring and accomplishing it in the /etc/src.conf?

I'll provide an update here once the build is done knowing how long it
takes to finish.

Thanks and best regards,
Archimedes

--00000000000025763905ecb5d31f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable





On Thu, Nov 3, 2022 at 7:52 AM Mark Millard <marklmi@yahoo.com> wrote:
On 2022-Nov-2, at 14:09=
, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:



> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <archimedes.gaviola@gmail=
.com> wrote:

> 

> . . .

> 

> . . .

> 

> 

> Hi Mark,

> 

> Just an update, as kernel and world compilation is ongoing with my RPi=
3B system (with swap partition) is doing so far, so good. It already surpas=
sed the tough part that breaks the compilation process here.

> ...

> 

> llvm-tblgen -gen-asm-matcher=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc=C2=A0 /usr/src/contrib/l=
lvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-asm-writer=C2=A0 -I /usr/src/contrib/llvm-project/llv=
m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R=
ISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc=C2=A0 /usr/src/contrib/llvm=
-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-callingconv=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc=C2=A0 /usr/src/contrib=
/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-compress-inst-emitter=C2=A0 -I /usr/src/contrib/llvm-=
project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=
=C2=A0 -d RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.=
inc=C2=A0 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-dag-isel=C2=A0 -I /usr/src/contrib/llvm-project/llvm/=
include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RIS=
CVGenDAGISel.inc.d -o RISCVGenDAGISel.inc=C2=A0 /usr/src/contrib/llvm-proje=
ct/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-disassembler=C2=A0 -I /usr/src/contrib/llvm-project/l=
lvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d=
 RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc=C2=A0 /=
usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-global-isel=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc=C2=A0 /usr/src/contrib/l=
lvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-instr-info=C2=A0 -I /usr/src/contrib/llvm-project/llv=
m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R=
ISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc=C2=A0 /usr/src/contrib/llvm=
-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-emitter=C2=A0 -I /usr/src/contrib/llvm-project/llvm/i=
nclude -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RISC=
VGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc=C2=A0 /usr/src/contrib=
/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-pseudo-lowering=C2=A0 -I /usr/src/contrib/llvm-projec=
t/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0=
 -d RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc=C2=A0 /u=
sr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-bank=C2=A0 -I /usr/src/contrib/llvm-project/=
llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -=
d RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc=C2=A0 /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-info=C2=A0 -I /usr/src/contrib/llvm-project/=
llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -=
d RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc=C2=A0 /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=
=A0 -d RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc=C2=A0=
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-subtarget=C2=A0 -I /usr/src/contrib/llvm-project/llvm=
/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RI=
SCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc=C2=A0 /usr/src/contr=
ib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=
=A0 -d RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc=C2=A0 /us=
r/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> 

> Any thoughts why this part is quite a challenge when it comes to memor=
y usage? The other architectures do not possess such behavior... just curio=
us.

Hi Mark,

S=
orry for the late response, I got fully occupied at work for the past few d=
ays due to deliverables. Thanks for your feedback and further inputs!
=

=C2=A0

I've not done any monitoring of buildworld buildkernel build

activity (RAM use, memory space use, swap partition use over

time) on RPi3B class hardware in a very long time.
It's alright, it so happened that I just observed that beha=
vior on that particular part as it requires more memory than other architec=
tures while compiling. The additional 3.5G swap partition really helps on t=
hat part that's why I was so happy that the compilation continued and n=
ever broke. Your input of having 3.5G swap allocation is very effective.


Even on systems that I have monitored in more recent times,

what I usually monitor tends to be builds with -jN (such as

-j4 fora 4-hardware-thread system). (I once did have an

example of -j3 taking less time than -j4 on a RPi4B.
<=
br>
Wow, this is interesting this -jN. Let me explore this as wel=
l. I usually build kernel the old way but recently since I have to include =
building the world then I need to use the new way. 
=C2=A0

Basically, the memory subsystem can be saturated without all

the cores being in use. The extra interference made things

take longer.)

Oh I see so it's the =
reason.
=C2=A0

You had listed that you were using the likes of:



# cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64 \

buildkernel buildworld installkernel installworld distribution \

DESTDIR=3D/home/freebsd/rpi3b



I'll note that the standard order of the first 2 is:



buildworld buildkernel



This is because buildworld builds some software that

buildkernel does not build for itself but does use.
Okay this is noted, thanks for clarifying and correcting me, I=
 really appreciate it. I'll reflect on the proper build sequence for mu=
ch efficiency.
=C2=A0

There is a kernel-toolchain target for avoiding the

need to do a full buildworld just to buildkernel , so:



kernel-toolchain buildkernel



is an expected sequence.

Okay I'll =
take note of this too.
=C2=A0

I do not know how long a from-scratch buildworld

buildkernel without a -jN takes on a RPi3B these

days. If I remember right, for -jN with 1<N, I last

saw claims about such they were somewhere in the

range 36hr..48hr.

There's an ongoing bu=
ild at the moment, it's already taking 41 hours since I started it. I t=
ook another build when I came back home from the office.
=C2=
=A0
But I'm =
unsure of the specific N

that was in use. Nor do I know the storage media

type(s) involved, for example. I do not remember

any reports for -j1.

I'll try this =
with RPi 3B. The current build that I have will be my baseline.
<=
br>

Use of the likes of: vm.pageout_oom_seq=3D120

was essential to such -jN usage on a RPi3B as N

gets larger. Of course, swap partition use for

paging was also essential.

Wow, that=
9;s great! I have this=20
vm.pageout_oom_seq=3D120 configured in my system now based on your previous=
 inputs.


Likewise use of:



vm.swap_enabled=3D0

vm.swap_idle_enabled=3D0



can be important to not losing communication

with the RPi3B. Those last 2 are not tunable

but are writable:



# sysctl -aT | grep swap_

# sysctl -aW | grep swap_

vm.swap_enabled: 0

. . .

vm.swap_idle_enabled: 0

. . .



(This means that they have fewer places where

assignments can be made. For example, the

loader can not make the assignments.)



By contrast, vm.pageout_oom_seq is both

writable and tunable:



# sysctl -aW | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



# sysctl -aT | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



(So even the loader can make such assignments.)

Yes, I have these two sysctl parameters configured in the system. =
Thanks for the details and further inputs.
=C2=A0 
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
I'll note that I've no interest in using arm hardware

to build for other types of hardware. So I normally

have the targeting of support for building for other

architectures disabled when I build on aarch64 or

armv7. (Basically, a less complete clang/clang++

related toolchain ends up being built.)

Ah okay, so you mean to say that you disable these other architectures by =
declaring and accomplishing it in the /etc/src.conf?

I'll provide an update here once the build is done knowing how long =
it takes to finish.

Thanks and best regards,
Archimedes




--00000000000025763905ecb5d31f--

From nobody Sat Nov  5 13:48:42 2022
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 4N4Jk74j10z4hkJV
	for ; Sat,  5 Nov 2022 13:48:47 +0000 (UTC)
	(envelope-from tuexen@freebsd.org)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N4Jk65tWYz3ChY;
	Sat,  5 Nov 2022 13:48:46 +0000 (UTC)
	(envelope-from tuexen@freebsd.org)
Received: from smtpclient.apple (unknown [IPv6:2001:67c:370:128:4157:3bf6:a280:22db])
	(Authenticated sender: macmic)
	by drew.franken.de (Postfix) with ESMTPSA id 3127C751CFA10;
	Sat,  5 Nov 2022 14:48:43 +0100 (CET)
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.200.110.1.12\))
Subject: Re: trpt(8) to be decomissioned
From: tuexen@freebsd.org
In-Reply-To: <20221105015421.DC4B037F@slippy.cwsent.com>
Date: Sat, 5 Nov 2022 13:48:42 +0000
Cc: Gleb Smirnoff ,
 Max Baroi ,
 Mike Karels ,
 current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <97286FA9-DD47-4EB2-BD7A-C2A8BC8B62B5@karels.net>
 <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.com>
  <20221105015421.DC4B037F@slippy.cwsent.com>
To: Cy Schubert 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=disabled version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de
X-Rspamd-Queue-Id: 4N4Jk65tWYz3ChY
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 193.175.24.27 is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org
X-Spamd-Result: default: False [-2.70 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[193.175.24.27:from];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE];
	FROM_NO_DN(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	FREEFALL_USER(0.00)[tuexen];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

> On 5. Nov 2022, at 01:54, Cy Schubert  =
wrote:
>=20
> In message , Gleb Smirnoff writes:
>>  Max,
>>=20
>> the reason I want to retire it is not that it consumes 40 Kb
>> in the repository.  The reason is that knows kernel structures,
>> and fails to compile after changes to them.  So the tool that
>> nobody uses requires special care when working on TCP.  The
>> kernel headers disclose the structures for trpt (with some
>> protection with _WANT_TCPCB, though) and some software from
>> ports (not calling names!) would start use them too. Now a
>> kernel developer needs to care not only about trpt, but
>> about this software, too.
>=20
> I recall when Bryan Cantrill came to one of the local hotels here to=20=

> announce Solaris 9, I remember him saying that Solaris truss was now =
an app=20
> that called DTrace functions. If people feel the need for trpt-like=20
> utility, would it be an idea to write it using DTrace calls? Could it =
be a=20
> GSoC project? It would be kind of neat for a co-op student or someone =
to=20
> get their feet wet with systems programming.
>=20
> I typically use DTrace when snooping around looking for that =
proverbial=20
> needle in a haystack. And TCPDEBUG seems to be one of those things =
that=20
> DTrace was designed to replace.
>=20
> It would be a good project to have a still in school upcoming =
developer to=20
> work on.
That plan is to use BBLog as an replacement.

Best regards
Michael
>=20
>=20
> --=20
> Cheers,
> Cy Schubert 
> FreeBSD UNIX:     Web:  https://FreeBSD.org
> NTP:               Web:  https://nwtime.org
>=20
> e^(i*pi)+1=3D0
>=20
>=20
>=20
>=20
>=20


From nobody Sat Nov  5 15:38:30 2022
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 4N4M8w47QDz3ww5n
	for ; Sat,  5 Nov 2022 15:38:40 +0000 (UTC)
	(envelope-from dan@sunsaturn.com)
Received: from sunsaturn.com (sunsaturn.com [173.208.132.187])
	(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 "sunsaturn.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N4M8t5skxz3MSL
	for ; Sat,  5 Nov 2022 15:38:38 +0000 (UTC)
	(envelope-from dan@sunsaturn.com)
Received: by sunsaturn.com (Postfix, from userid 1001)
	id 93A7B6815B; Sat,  5 Nov 2022 10:38:30 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunsaturn.com;
	s=default; t=1667662710;
	bh=KCUgdL6TWD2gTNiE0W5+lcgl68fn/2dQlPgdoRzxgAI=;
	h=Date:From:To:Subject;
	b=j+nvTyoOZsHpQk3alx8CURloX1LMPlEV0qg/f88x3U58GwdNNvxYT5qk/uA71L7T0
	 ykhnTc6uO8gBGaA9tvZl6cm9Opf1Vd9dfREH8SOP/pLTHQqA5HafMOHXK6xYen/FS1
	 Qa16rsMncLV9dWMFk1XZolgoboiQFxDxJPUuOtOA=
Received: from localhost (localhost [127.0.0.1])
	by sunsaturn.com (Postfix) with ESMTP id 918EE6815A
	for ; Sat,  5 Nov 2022 10:38:30 -0500 (CDT)
Date: Sat, 5 Nov 2022 10:38:30 -0500 (CDT)
From: Dan The Man 
To: freebsd-current@FreeBSD.org
Subject: Options for production testing under current(samba slow)
Message-ID: <3b2a609d-5e80-edb3-e414-b5e774ad614d@sunsaturn.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; format=flowed; charset=US-ASCII
X-Rspamd-Queue-Id: 4N4M8t5skxz3MSL
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=sunsaturn.com header.s=default header.b=j+nvTyoO;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of dan@sunsaturn.com designates 173.208.132.187 as permitted sender) smtp.mailfrom=dan@sunsaturn.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[sunsaturn.com:s=default];
	R_SPF_ALLOW(-0.20)[+ip4:173.208.132.187];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	DKIM_TRACE(0.00)[sunsaturn.com:+];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[sunsaturn.com: no valid DMARC record];
	RCPT_COUNT_ONE(0.00)[1];
	ASN(0.00)[asn:32097, ipnet:173.208.128.0/17, country:US];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[dan];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


cd /usr/src/sys/amd64/conf
cp GENERIC-NODEBUG MYKERNEL;
(add: options         BHYVE_SNAPSHOT)
cd /usr/src
make -j12 buildworld -DWITH_BHYVE_SNAPSHOT -DWITH_MALLOC_PRODUCTION
make -j12 buildkernel KERNCONF=MYKERNEL
make installkernel KERNCONF=MYKERNEL
etc....

Been playing with current lately mostly to use bhyve suspend/resume(which 
works fine btw, other than core dumps if I left a cd device in there with 
an ISO etc).

I have noticed on samba I am loosing 100-200MB/s transfer speeds now over 
10gigabit ix0 device, I am wondering if I need more options than
-DWITH_MALLOC_PRODUCTION?


Dan.

--
Dan The Man
CEO & Founder
Websites, Domains and Everything else
http://www.SunSaturn.com/aboutus.php
Email: Dan@SunSaturn.com
PGP Key: https://SunSaturn.com/pgp.txt
A1A7 6E84 FB0B 8994 C3B5  A1BA FF6F 4997 7311 C386

From nobody Sun Nov  6 03:12:04 2022
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 4N4fY458Qkz4hDCc
	for ; Sun,  6 Nov 2022 03:12:08 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (www.zefox.net [50.1.20.27])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N4fY34MPjz3Lt8
	for ; Sun,  6 Nov 2022 03:12:07 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2A63C4Fr046038
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Sat, 5 Nov 2022 20:12:04 -0700 (PDT)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2A63C4qb046037
	for freebsd-current@freebsd.org; Sat, 5 Nov 2022 20:12:04 -0700 (PDT)
	(envelope-from fbsd)
Date: Sat, 5 Nov 2022 20:12:04 -0700
From: bob prohaska 
To: freebsd-current@freebsd.org
Subject: Seeking an idiot's guide to etcupdate/mergemaster
Message-ID: <20221106031204.GA45827@www.zefox.net>
References: 
 <20221021175142.GA62386@www.zefox.net>
 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
 <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
 <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com>
 <20221024174930.GA79381@www.zefox.net>
 
 <20221025005012.GA80394@www.zefox.net>
 <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com>
X-Rspamd-Queue-Id: 4N4fY34MPjz3Lt8
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net
X-Spamd-Result: default: False [-1.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	R_SPF_NA(0.00)[no SPF record];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	DMARC_NA(0.00)[zefox.net];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Oct 24, 2022 at 08:32:17PM -0700, Mark Millard wrote:
> 
> Your /etc/rc.d/ldconfig script seems to have not been updated
> by use of etcupdate or mergemaster or other such. (How much
> else is also out of date? How much of what you have for /etc/
> and the like goes back to 2022-Jan-07 or before?)
>
 
Alas, that is too true. The system was set up on July 2, 2020
and I've never managed to make sense of either mergemaster nor
etcupdate. Far as I could tell it didn't matter, the host ran
correctly, until now.

It's been transplanted to a new hard drive, which allows the
installation of a ports tree. Ports don't install because of
the stale /etc/rc.d/ldconfig file.

Since no changes have been made to /etc/ apart from /etc/rc.conf
is it possible to simply let mergemaster or etcupdate install
the latest defaults? I have looked at the manpage for etcupdate
and didn't recognize any straightforward way to simply accept
all updates. This particular system is expendable, so I'd be
glad to try things that might not work well, or at all. 

Apologies if I'm being dumb (probably guilty) or lazy (definitely
guilty). The barrage of questions generated by etcupdate  and
mergemaster is simply overwhelming. And, I suspect, largely 
unnecessary.   
 
Thanks for reading!

bob prohaska


From nobody Sun Nov  6 09:04:45 2022
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 4N4pNJ73kdz4gfB7
	for ; Sun,  6 Nov 2022 09:05:04 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.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 4N4pNH4GJtz3p0s
	for ; Sun,  6 Nov 2022 09:05:03 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667725501; bh=f6a9Ld8g+zeC52CX+wkdrkAWAvOh7iMViUCdYv3l/JE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=eh5WgmKb1mCfcI3ucqIi1K+nimWDAmkJDVaqSEkxgvAgiryYwTziQyQe1Av/TcP1UAUGxwFc0J1mhQJ+RpPfid8/Ml9/4BTWBp1l/vmiYrCkyGAO36X3/5abRml70YaaGm89tJQ/rH83UU0spNDYhL58yi7yGFJvUkpzN2vqmJTW7mbJQymYitLTjdTyRXJDcHHBwrvNmxqHDqEHokQ2OPu08WfQlzhj2jrNQPxn7L8fO5h2cj1rQhQPc5/VxXnG8mPzJpep+px4BS55zpf0DDoPHpGn208I1DioXmQP4iZY4FVhV29FqhS/d9Ka5ZvaDoQzus3V9RjPh2Mw240J1g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667725501; bh=gmfBx/xcP2H1mlWD7hvXhoRgcUr1X34dnWXJGjG9f+Y=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=mObwr/c1j0Lfi4OyLNEW6Z+IN5o8TM7YtLu//Q9maSOcp+xFuQ1yiOyqMV9feA9wqf8ibalf/mM+8zV6Okyk0johrqMFb2Ywq4oAvL3gh0cm0nwijULSk47uO1AzYHugj5eqkFMbLbVmXLn/Y7neiPG7DQxQ6OeNGUjbkhjI08cf1J0glexph0AKd+PoZUtNx3nbCoipGFuS3mAezy6NEhiMxrMsLeStRJB2jktf6uIIRd96u3OCr4rgReSBBMiTG7XXQxokVy60BFfvOaBEND5GOvdhAZSf8MW+WP26dJUnwcJVSm7DvWIAvxs6uzsUz9zhnWe/97pMLbI8TvZrRA==
X-YMail-OSG: fh3O3wMVM1mDmHFQIsApD1pqbz.Yzdm9P_25rdqx9dsjmPOWdgo2FftV56Z7OWA
 u8liBcv.2abacjyt2wRF70pk37IZM2JKTbRBMHMvI8vfxHk7PAx2VPih5m769AVWmeZjNAAmv2gq
 J.3Xohc1zeJ.QCJtrNE.6d78eCMO0uVhUcfglMKNrEzy4a61AgC5Y5c2FiXvpqrSNnD96FPMnpsv
 tGjKatsRrFXnO2tLRmQMDXxl9RVGK8HgqTbO1uKaVVmic1a3cvuF.xUuxhOoEcA3vkM9kA0V6guH
 cRhEs5rJrHFLu07poXBGpRTK285EiLvU2YmWlEIJWig._F5Z6YCphC09iUJy7SS9LmyAakd.U5Zd
 W9acWvI62xGf_sFlPpgtMY0UzIe.EWFWFraqBpkygqfKJu.wzL2.MPFi75iV0QGErybLqIYrwu3w
 RFpg1._cTsGg5XlO9YgePro2dIzHuK6U_exZBJCxvP6beVlsdjxccKSzOECobAjbtqdtyred5ajy
 8E1x7.PaZU1lWjvvpxbcPtwmyHr1eFoAakDeXy1.C8MT.PajgLtD4ljQcnYM0A5bCxmHyRfJ6GpS
 gx6CWYtXE2HKDRfxqmDvHfRbwUYW4.41nHNQfXpWpGnXklZzqIT623XPNqjoTuS.Ye4_KBFQoX9w
 KLeuVu.mk4BmUGkreUbWGZfqdm1Oma5QT9q9YLt9.fpU3fZ00sRw6tYogEvs4CsxGILs__sH5sJC
 MBUlLFz7evrfBE6AZyRF.CFZjSMU9MtAfnie77YRrDLST9jI3V_HtY30KxuvFdfcpSULO2RA_7fS
 w72BcvK.ESWuSoWFDNWv0gJ.gkPTllRQg9KKXk9rWG__izzWP5v1dJCjeL7.wmsVNzcL3.dkMlP2
 4._AoJ_En9HOxdRCO1BiuHtVoSUkynCApr9uZrkXp3Ro1XbCUaQQ7D7kgJVErv32Zrg_.LmtASXW
 wtanA6IyRyhSojOaj_2SRZIDipj4vR0nya0RL6i7euorisHsKdfsfAZHBX6hstK2_uuLvV1iI2fp
 PbFlsSvFBpGqTP8VQhOVKo0sz8jn1xovHp5gST1GgGivXxUONIIEQuidJ283MM8Xr3v1LDsH7IOu
 0NQNsh_Xv5rJo_vCjauApq8owH03DMDDxGNQDW74JI1hTpqFJelQLY1QFZoNyAYZKEcMbPyijnwB
 msbWyvTHYI9AJldE52lPKv1QVNW6_XWP2u1i4o7xbcwDXFx1Q5vCD8SDN33.S3n2iNGcaFjYs8Sq
 pNFRYW4TC08oCsdCXaPGM.wEtyy1SEyaKvRghLvM10zVdwWAwnKpZbL64dDbC3Wu_iA9dHgNhlXS
 0uD88mizMz54cH7_L_Y1iESPlSLSikuQhFeb.g7xd3IbTSWgLAXLQg2q8EhV8TF7kzZi5cln.vV2
 5YxSS8ycxMvpZ0d3uucNIhLcrwKLjLucRNMXdOls6YsctLOj2KvOCGx8GdKtXM0jdOJtg6ZIdOun
 KyAHGB6YAOrPciSIVbU6wbFxY8iLBzQjTW8SZpu3KL1Uo1B8VPffiWZQryjIrRYlyZJTAjItBIEf
 KVO2j2hwQ9ofpuDzcq0igylEU8uc9nrVbLpW.TaAThHeJ2uCz3ARjnE8ARQuYrDCF_92dcUNd8Wi
 hT6cjVr2Uw2nmzPm_Qau9h_3nSSkTzc.p51UIX9iWZZkiYhzVYE23GmpD3lCyadnhWWmU7bzLqc8
 LT4aE0mtohBiBgOPSKZ0BPQ4uCKKdg7clq4W8PvsnOMt5JoC08Dpwgt4KgfnSdcKkvBy7mau6ikw
 xfJeo4QVRmLL3qeq6EqVUgwf6SIQWa_zYakXdFCnKyHskY_oh9e.E8QbFgLatzjoFu5muYq0WGhm
 sX3cS2.QexEsfBORnq0u7cE97wbkz0n1oRgpW0Ig0WIcMUfhn2pW_CM08Y3KZrkSzEJqB7ObelC8
 d2Cm5hXRokkcKJoAfOppfP.lhBp2GoPpZFxUaznR9qTxCbvLvW2iqVn83_t7qpp.Lq7jftUOOiy0
 WEESLAsJmXGhigScokHBSSFiVEpNt3I49s0T4kA35I5o3FZSTsAfKq69etdD9QupcXWgcwEptGVd
 wbm8YBPhqWzG4fvILqHEcsGxmsCSnzas8VwJqocIaIp_e5gi73HQ6GFrKaujzel5ZBBDbPQfaBvA
 m1Y336Ohn02TAThP8VndC.oh02KsC5o0Y1apEX.Zz4MSMDjb1QiuKfdhrp0QegKZcwoMtLMMeLG4
 YI_KQRJvPEAUmflC.Xw0uzPjUXQ3ip86tlFIxQDP3yH93kLPOqZbZJHfVO.9cnYM6PpNJeCjptmO
 y784-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Nov 2022 09:05:01 +0000
Received: by hermes--production-bf1-5878955b5f-f7np2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7846ea7e39dbb75bffabd075f7a9bc3d;
          Sun, 06 Nov 2022 09:04:58 +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 \(3731.200.110.1.12\))
Subject: RE: Seeking an idiot's guide to etcupdate/mergemaster
Message-Id: 
Date: Sun, 6 Nov 2022 01:04:45 -0800
To: bob prohaska ,
 freebsd-current 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: 
X-Rspamd-Queue-Id: 4N4pNH4GJtz3p0s
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=eh5WgmKb;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N


bob prohaska  wrote on
Date: Sun, 06 Nov 2022 03:12:04 UTC :

> On Mon, Oct 24, 2022 at 08:32:17PM -0700, Mark Millard wrote:
> >=20
> > Your /etc/rc.d/ldconfig script seems to have not been updated
> > by use of etcupdate or mergemaster or other such. (How much
> > else is also out of date? How much of what you have for /etc/
> > and the like goes back to 2022-Jan-07 or before?)
> >
>=20
> Alas, that is too true. The system was set up on July 2, 2020
> and I've never managed to make sense of either mergemaster nor
> etcupdate. Far as I could tell it didn't matter, the host ran
> correctly, until now.
>=20
> It's been transplanted to a new hard drive, which allows the
> installation of a ports tree. Ports don't install because of
> the stale /etc/rc.d/ldconfig file.
>=20
> Since no changes have been made to /etc/ apart from /etc/rc.conf
> is it possible to simply let mergemaster or etcupdate install
> the latest defaults? I have looked at the manpage for etcupdate
> and didn't recognize any straightforward way to simply accept
> all updates. This particular system is expendable, so I'd be
> glad to try things that might not work well, or at all.=20
>=20
> Apologies if I'm being dumb (probably guilty) or lazy (definitely
> guilty). The barrage of questions generated by etcupdate and
> mergemaster is simply overwhelming. And, I suspect, largely=20
> unnecessary.  =20


[We will see if this helps or not . . .]

Before worrying about the actual updates, I'd start by just
establishing a set of default files to look at.

There are 2 contexts overall:

A) The source commit vintage for the live system
vs.
B) The source commit vintage for the update to be installed
   at some point

At this point I'm only dealing with (A).

Is your /usr/src/ the proper content for (A)? (B)? Something
else?

If you do not have a /usr/src/ that is the proper content for
(A), then you need to create a directory tree that does contain
such a source tree, such as via using git or other such to
establish the source tree.

I'll refer to: /usr/livesrc/=20

The command:

# etcupdate extras -s /usr/livesrc

will create: /var/db/etcupdate/current/

There you can look at the various default file contents.
More than /etc/ material will be present, for example:

/var/db/etcupdate/current/.cshrc
/var/db/etcupdate/current/.profile
/var/db/etcupdate/current/COPYRIGHT
/var/db/etcupdate/current/root/.cshrc
/var/db/etcupdate/current/root/.k5login
/var/db/etcupdate/current/root/.login
/var/db/etcupdate/current/root/.profile
/var/db/etcupdate/current/root/.shrc
/var/db/etcupdate/current/usr/share/nls/POSIX
/var/db/etcupdate/current/usr/share/nls/en_US.US_ASCII
/var/db/etcupdate/current/var/crash/minfree

Some files that you create or edit might not show up
under current/ at all. ( /etc/fstab and /etc/rc.conf
would be examples. )

You might not want to look at all the mismatches. But
you might want to look at the output of something like:

# find -s /var/db/etcupdate/current/ -print | more

to see if it reminds you of any files that you do want
preserve a copy of the old content of for reference. An
example might be: /etc/sysctl.conf
There could be others.

I'd expect that the following sort of command sequence
would mostly replace the live system's files with the
defaults (presumes done as root to be sure that files
are replaceable):

# cd /var/db/etcupdate/current/
# cp -aRx . /

However, there might be questions about hard links and
softlinks in the from-side or the to-side and how
things end up with such involved (after the cp -aRx
completes).

Note that you may have more build installs around that
you might need to be sure that they track, such as
directories for chroot use. This can get into using
command line options that indicate context so that
each context gets its own tracking. It should also
change things, like /var/db/etcupdate/current/
to have a path prefix involved:

/PATHPREFIX/var/db/etcupdate/current/

As for updates, I have scripts that do something like:

# #PRIOR source update and buildworld buildkernel ACTIVITY HERE.
# etcupdate . . . -p
# etcupdate . . . resolve -p
# make . . . installkernel . . .
# make . . . installworld . . .
# etcupdate
# etcupdate resolve
# make . . . delete-old check-old -DBATCH_DELETE_OLD_FILES

Note: delete-old-libs may need to be in its own time frame,
      after one is sure that those libraraies are no longer
      in use so that the delete will not break anything.

# etcupdate status
# etcupdate resolve

However, being paranoid, I use a script that runs each
etcupdate command with a context specified. An example
is:

env __MAKE_CONF=3D"/usr/home/root/src.configs/make.conf" \
SRCCONF=3D"/dev/null" =
SRC_ENV_CONF=3D"/usr/home/root/src.configs/src.conf.CA72-nodbg-clang.aarch=
64-host" \
MAKEOBJDIRPREFIX=3D"/tmp/usr/obj/BUILDs/main-CA72-nodbg-clang" \
etcupdate $* -s /usr/main-src -M TARGET_ARCH=3Daarch64

Note the $* which is where the command line arguments to the
script would go.

Similarly for my make commands:

kldload -n filemon && \
cd /usr/main-src && \
mkdir -p /usr/obj/BUILDs/main-CA72-nodbg-clang/sys-typescripts && \
env __MAKE_CONF=3D"/usr/home/root/src.configs/make.conf" \
SRCCONF=3D"/dev/null" =
SRC_ENV_CONF=3D"/usr/home/root/src.configs/src.conf.CA72-nodbg-clang.aarch=
64-host" \
MAKEOBJDIRPREFIX=3D"/usr/obj/BUILDs/main-CA72-nodbg-clang" \
WITH_META_MODE=3Dyes \
make $*

Part of this is that I've got far more than just one
environment that I build/install. Thus parts of my context
do not make for simple examples.

(I'll not get into why I have /tmp in the front of the
MAKEOBJDIRPREFIX for etcupdate --but not for make .)

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


From nobody Sun Nov  6 12:07:16 2022
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 4N4tQn4Wpmz4h2LR
	for ; Sun,  6 Nov 2022 12:07:29 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N4tQl1wd3z44cg
	for ; Sun,  6 Nov 2022 12:07:26 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2A6C7GIo038795;
	Sun, 6 Nov 2022 21:07:18 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Sun, 6 Nov 2022 21:07:16 +0900
From: Tomoaki AOKI 
To: bob prohaska 
Cc: freebsd-current@freebsd.org
Subject: Re: Seeking an idiot's guide to etcupdate/mergemaster
Message-Id: <20221106210716.1c997091ca40ea02ede9f159@dec.sakura.ne.jp>
In-Reply-To: <20221106031204.GA45827@www.zefox.net>
References: 
	<20221021175142.GA62386@www.zefox.net>
	
	<0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
	<71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
	<5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com>
	<20221024174930.GA79381@www.zefox.net>
	
	<20221025005012.GA80394@www.zefox.net>
	<605A6723-5D31-495C-8200-FD107115FC81@yahoo.com>
	<20221106031204.GA45827@www.zefox.net>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4N4tQl1wd3z44cg
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	R_SPF_NA(0.00)[no SPF record];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[sakura.ne.jp];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Sat, 5 Nov 2022 20:12:04 -0700
bob prohaska  wrote:

> On Mon, Oct 24, 2022 at 08:32:17PM -0700, Mark Millard wrote:
> > 
> > Your /etc/rc.d/ldconfig script seems to have not been updated
> > by use of etcupdate or mergemaster or other such. (How much
> > else is also out of date? How much of what you have for /etc/
> > and the like goes back to 2022-Jan-07 or before?)
> >
>  
> Alas, that is too true. The system was set up on July 2, 2020
> and I've never managed to make sense of either mergemaster nor
> etcupdate. Far as I could tell it didn't matter, the host ran
> correctly, until now.
> 
> It's been transplanted to a new hard drive, which allows the
> installation of a ports tree. Ports don't install because of
> the stale /etc/rc.d/ldconfig file.
> 
> Since no changes have been made to /etc/ apart from /etc/rc.conf
> is it possible to simply let mergemaster or etcupdate install
> the latest defaults? I have looked at the manpage for etcupdate
> and didn't recognize any straightforward way to simply accept
> all updates. This particular system is expendable, so I'd be
> glad to try things that might not work well, or at all. 
> 
> Apologies if I'm being dumb (probably guilty) or lazy (definitely
> guilty). The barrage of questions generated by etcupdate  and
> mergemaster is simply overwhelming. And, I suspect, largely 
> unnecessary.   
>  
> Thanks for reading!
> 
> bob prohaska

For a relatively casual way.

If I'm facing the same situation, I will...

 1. `mergemaster -UFiP` for now, then...
 2. `etcupdate extract -B` for next upgrade.

And on next upgrade, `etcupdate -p` before installing upgrade,
and then `etcupdate -B` after install.
You can add -n for dry-run before actual etcupdate.


For some notes:
mergemaster, the old and less maintained tool, uses current installation
and updated tree. Old dedault state is not at all considered.

So it could be used for already-updated states.

etcupdate, the currently maintained tool, uses previous and updated
defaults, and current installation (working environment).
It compares differences between old and new default, check if the
differences can be sanely applicable to currently working environment
or not, and if it's sane, apply the diff automatically.
If any conflict happenes, ask the admin (this case, you) for actions.

So it requires previous default state, thus cannot use for this case,
except you are sure what the actual previous revision was and can
prepare the source tree (possibly obj tree, too?) and somehow create
"current" tree ATM (will be turned over to "previous" tree on etcupdate
run).

See manpages for detail.

-- 
Tomoaki AOKI    

From nobody Sun Nov  6 12:44:51 2022
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 4N4vPp0V7tz4h6k3
	for ; Sun,  6 Nov 2022 12:51:42 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N4vPn0dtpz48ty
	for ; Sun,  6 Nov 2022 12:51:41 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 2A6Cpdgv046815
	for ; Sun, 6 Nov 2022 12:51:39 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 2A6Cpd9Y046814
	for current@freebsd.org; Sun, 6 Nov 2022 04:51:39 -0800 (PST)
	(envelope-from david)
Resent-From: David Wolfskill 
Resent-Date: Sun, 6 Nov 2022 04:51:39 -0800
Resent-Message-ID: 
Resent-To: current@freebsd.org
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 2A6CipD2046746;
	Sun, 6 Nov 2022 12:44:51 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 2A6CipRC046745;
	Sun, 6 Nov 2022 04:44:51 -0800 (PST)
	(envelope-from david)
Date: Sun, 6 Nov 2022 04:44:51 -0800
From: David Wolfskill 
To: current@freebsd.org
Subject: Build error in FreeBSD head, main-n259058-105019e0d6c ->
 main-n259061-b1258b76435
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: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="tii4aAjpkTFS7nz7"
Content-Disposition: inline
X-Rspamd-Queue-Id: 4N4vPn0dtpz48ty
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org
X-Spamd-Result: default: False [-5.40 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	DMARC_NA(0.00)[catwhisker.org];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	FREEFALL_USER(0.00)[david];
	RCVD_COUNT_FIVE(0.00)[5];
	ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--tii4aAjpkTFS7nz7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

And the only commit after main-n259061-b1258b76435 so far is
004bb636ca65f3239da284c20abb7f9d1d953dee, which claims:

| tcp: Move sysctl OIDs related to ECN to tcp_ecn.
| Keep all ECN related code in (mostly) one place.
|=20
| No functional change.

I'm seeing:

=2E..
building shared library libBIG5.so.5
Building /common/S4/obj/usr/src/amd64.amd64/lib/libiconv_modules/DECHanyu/l=
ibDECHanyu.so.5.full
In file included from /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:5=
6:
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29=
: warning: declaration of 'struct tcpcb' will not be visible outside of thi=
s function [-Wvisibility]
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
                            ^
Building /common/S4/obj/usr/src/amd64.amd64/lib/googletest/gtest/libprivate=
gtest.a
building static gtest library
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:19=
: error: incomplete definition of type 'struct tcpcb'
        return ((ack - tp->snd_una) / tp->t_maxseg +
                       ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29=
: note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
                            ^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:34=
: error: incomplete definition of type 'struct tcpcb'
        return ((ack - tp->snd_una) / tp->t_maxseg +
                                      ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29=
: note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
                            ^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:15=
: error: incomplete definition of type 'struct tcpcb'
                ((((ack - tp->snd_una) % tp->t_maxseg) !=3D 0) ? 1 : 0));
                          ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29=
: note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
                            ^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:30=
: error: incomplete definition of type 'struct tcpcb'
                ((((ack - tp->snd_una) % tp->t_maxseg) !=3D 0) ? 1 : 0));
                                         ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29=
: note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
                            ^
1 warning and 4 errors generated.
building static devdctl library
Building /common/S4/obj/usr/src/amd64.amd64/lib/libiconv_modules/EUC/libEUC=
=2Eso.5.full
In file included from /usr/src/lib/libstats/../../sys/netinet/tcp_stats.c:5=
6:
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29=
: warning: declaration of 'struct tcpcb' will not be visible outside of thi=
s function [-Wvisibility]
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
                            ^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:19=
: error: incomplete definition of type 'struct tcpcb'
        return ((ack - tp->snd_una) / tp->t_maxseg +
                       ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29=
: note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
                            ^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:557:34=
: error: incomplete definition of type 'struct tcpcb'
        return ((ack - tp->snd_una) / tp->t_maxseg +
                                      ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29=
: note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
                            ^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:15=
: error: incomplete definition of type 'struct tcpcb'
                ((((ack - tp->snd_una) % tp->t_maxseg) !=3D 0) ? 1 : 0));
                          ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29=
: note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
                            ^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:558:30=
: error: incomplete definition of type 'struct tcpcb'
Building /common/S4/obj/usr/src/amd64.amd64/lib/libwrap/libwrap.a
                ((((ack - tp->snd_una) % tp->t_maxseg) !=3D 0) ? 1 : 0));
                                         ~~^
/common/S4/obj/usr/src/amd64.amd64/tmp/usr/include/netinet/tcp_var.h:555:29=
: note: forward declaration of 'struct tcpcb'
tcp_packets_this_ack(struct tcpcb *tp, tcp_seq ack)
                            ^
Building /common/S4/obj/usr/src/amd64.amd64/lib/libdwarf/dwarf_funcs.pico
building static wrap library
building shared library libDECHanyu.so.5
Building /common/S4/obj/usr/src/amd64.amd64/lib/libpe/libpe.a
building shared library libEUC.so.5
Building /common/S4/obj/usr/src/amd64.amd64/lib/libiconv_modules/EUCTW/libE=
UCTW.so.5.full
Building /common/S4/obj/usr/src/amd64.amd64/lib/googletest/gtest/libprivate=
gtest.so.0.full
building shared library libprivategtest.so.0
building shared library libEUCTW.so.5
Building /common/S4/obj/usr/src/amd64.amd64/lib/libwrap/libwrap.so.6.full
Building /common/S4/obj/usr/src/amd64.amd64/lib/libefivar/libefivar.so.1.fu=
ll
building shared library libwrap.so.6
building static pe library
Building /common/S4/obj/usr/src/amd64.amd64/lib/libngatm/libngatm.a
Building /common/S4/obj/usr/src/amd64.amd64/lib/libdevdctl/libprivatedevdct=
l.so.0.full
Building /common/S4/obj/usr/src/amd64.amd64/lib/libfigpar/libfigpar.so.0.de=
bug
building shared library libefivar.so.1
Building /common/S4/obj/usr/src/amd64.amd64/kerberos5/lib/libhdb/_libinstall
Building /common/S4/obj/usr/src/amd64.amd64/lib/libfigpar/libfigpar.so.0
Building /common/S4/obj/usr/src/amd64.amd64/lib/libngatm/libngatm.so.4.full
Building /common/S4/obj/usr/src/amd64.amd64/kerberos5/lib/libasn1/_libinsta=
ll
Building /common/S4/obj/usr/src/amd64.amd64/lib/libiconv_modules/GBK2K/libG=
BK2K.so.5.full
building static ngatm library
building shared library libngatm.so.4
Building /common/S4/obj/usr/src/amd64.amd64/lib/libdwarf/dwarf_pro_funcs.pi=
co
building shared library libGBK2K.so.5
Building /common/S4/obj/usr/src/amd64.amd64/lib/libbluetooth/libbluetooth.s=
o.4.debug
Building /common/S4/obj/usr/src/amd64.amd64/lib/libbluetooth/libbluetooth.s=
o.4
Building /common/S4/obj/usr/src/amd64.amd64/kerberos5/lib/libheimntlm/_libi=
nstall
building shared library libprivatedevdctl.so.0
Building /common/S4/obj/usr/src/amd64.amd64/lib/libblacklist/libblacklist.s=
o.0.debug
Building /common/S4/obj/usr/src/amd64.amd64/lib/libz/libz.so.6.debug
Building /common/S4/obj/usr/src/amd64.amd64/kerberos5/lib/libasn1/_INCSINS
Building /common/S4/obj/usr/src/amd64.amd64/lib/libblacklist/libblacklist.s=
o.0
Building /common/S4/obj/usr/src/amd64.amd64/lib/libiconv_modules/HZ/libHZ.s=
o.5.full
Building /common/S4/obj/usr/src/amd64.amd64/lib/libdwarf/dwarf_pro_pubnames=
=2Epico
Building /common/S4/obj/usr/src/amd64.amd64/lib/libz/libz.so.6
Building /common/S4/obj/usr/src/amd64.amd64/lib/libvmmapi/libvmmapi.so.5.fu=
ll
building shared library libHZ.so.5
Building /common/S4/obj/usr/src/amd64.amd64/lib/libdwarf/dwarf_pro_types.pi=
co
building shared library libvmmapi.so.5

make[3]: stopped in /usr/src

make[3]: stopped in /usr/src

make[2]: stopped in /usr/src
       33.41 real       743.18 user        61.82 sys

make[1]: stopped in /usr/src

make: stopped in /usr/src

Script done, output file is s4
freebeast(14.0-C)[5]

while running on:

freebeast(14.0-C)[6] uname -aUK
FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #216 mai=
n-n259058-105019e0d6c: Sat Nov  5 11:05:01 UTC 2022     root@freebeast.catw=
hisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1400073 140=
0073
freebeast(14.0-C)[7]

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
If Trump doesn't want folks to liken his propaganda techniques to those
of the Third Reich, maybe he ought not USE those propaganda techniques.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--tii4aAjpkTFS7nz7
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCY2esQ18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1G9uAP9+qJYAVNN9Clwx+eozJti1j9uGS27lQSndIJg0cDWUpwEAj2LCjW54kz3t
0Mla781aSwBZu3zp0DGl1/nMLNvMxQ0=
=vk94
-----END PGP SIGNATURE-----

--tii4aAjpkTFS7nz7--

From nobody Sun Nov  6 14:04:56 2022
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 4N4x2N5YHvz4hGNp
	for ; Sun,  6 Nov 2022 14:05:00 +0000 (UTC)
	(envelope-from l.m.v.breda@xs4all.nl)
Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N4x2M1fGvz3KXs
	for ; Sun,  6 Nov 2022 14:04:59 +0000 (UTC)
	(envelope-from l.m.v.breda@xs4all.nl)
X-KPN-MessageId: fa986c01-5ddb-11ed-8a67-005056ab378f
Received: from smtp.kpnmail.nl (unknown [10.31.155.39])
	by ewsoutbound.so.kpn.org (Halon) with ESMTPS
	id fa986c01-5ddb-11ed-8a67-005056ab378f;
	Sun, 06 Nov 2022 15:04:50 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=xs4all.nl; s=xs4all01;
	h=content-type:mime-version:message-id:date:subject:to:from;
	bh=cv+rHRCTxN+8p3ASX+Ry7kBo0febTNH8qQPFIAkJ1fI=;
	b=pCdxRNU7rrWcD3qcPatBSkoe30zqTSOHqETCD0Xgf7jhK47NuZA71jdd+3j1bH6m5ZnAa9nzJHUzM
	 hrOgURMc857Hf0PRsOuCZf36kM4nFs49XycVyQvVpHRXabdGNfgSRWGkr69HUDtUIPB6NdnbxKOMbl
	 HFYo8PYD7fB0BRbF5ev/UKX6XqWxsv61DHOHTYmRdauEqmD3LC/2OqPIYNH4qbnZAKeYB614qeMpfl
	 NRPQ8mupG8tEX9yoSpdOBsABCV1bkK2PSQDcOOpvY6RB0cezd/E+8rV1m+tliDs+vC8oyA+oh5GcWc
	 PBR32nxSzk37c6VYW0dMzDRFcJPD6rw==
X-KPN-MID: 33|AmKCHRyhv1KLWiQkY9jbyj2/Fhh7gjDJKwml/sIP3HA0KkvB9pA+uwAZkqz77NY
 5wQhl3mAwewix+r/BRE8ZcVLCtu6ulL9FU/nAIxWf2sM=
X-KPN-VerifiedSender: Yes
X-CMASSUN: 33|KvdQow+bZRqUuH3Q1P2SREwasfKNmew2RybNSE2p93zNnxxM3m2oW1nG5E4iSl6
 bmfguFEiWKuEPMLjDnl+93Q==
X-Originating-IP: 77.174.182.228
Received: from MAIN (77-174-182-228.fixed.kpn.net [77.174.182.228])
	by smtp.xs4all.nl (Halon) with ESMTPSA
	id fe6cbcab-5ddb-11ed-b8b1-005056ab7447;
	Sun, 06 Nov 2022 15:04:56 +0100 (CET)
From: 
To: 
Subject: How to disable ACPI? (on FreeBSD14 CURRENT)
Date: Sun, 6 Nov 2022 15:04:56 +0100
Message-ID: <000501d8f1e8$c0442df0$40cc89d0$@xs4all.nl>
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="----=_NextPart_000_0006_01D8F1F1.220895F0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: Adjx59b9/943xIFwTsKggT01IGDN1g==
Content-Language: nl
X-Rspamd-Queue-Id: 4N4x2M1fGvz3KXs
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=xs4all.nl header.s=xs4all01 header.b=pCdxRNU7;
	dmarc=pass (policy=none) header.from=xs4all.nl;
	spf=pass (mx1.freebsd.org: domain of l.m.v.breda@xs4all.nl designates 195.121.94.170 as permitted sender) smtp.mailfrom=l.m.v.breda@xs4all.nl
X-Spamd-Result: default: False [-3.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	DMARC_POLICY_ALLOW(-0.50)[xs4all.nl,none];
	FORGED_SENDER(0.30)[louis.freebsd@xs4all.nl,l.m.v.breda@xs4all.nl];
	R_SPF_ALLOW(-0.20)[+ip4:195.121.94.170/32:c];
	R_DKIM_ALLOW(-0.20)[xs4all.nl:s=xs4all01];
	RCVD_IN_DNSWL_LOW(-0.10)[195.121.94.170:from];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	DWL_DNSWL_NONE(0.00)[xs4all.nl:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	FROM_NO_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	SUBJECT_HAS_QUESTION(0.00)[];
	ASN(0.00)[asn:8737, ipnet:195.121.64.0/18, country:NL];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[xs4all.nl];
	HAS_XOIP(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[louis.freebsd@xs4all.nl,l.m.v.breda@xs4all.nl];
	RCVD_COUNT_THREE(0.00)[3];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	DKIM_TRACE(0.00)[xs4all.nl:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_ENVFROM(0.00)[xs4all.nl];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multipart message in MIME format.

------=_NextPart_000_0006_01D8F1F1.220895F0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I need to disable acpi and the indicated method for that is to add =
^hint.acpi.0.disabled=3D"1"^ in /boot/loader.conf .

However that crashes my system !!!!!!=20

Not only that, to make it work again I have to edit loader.conf on a =
system which does ^not start^. =20

 =EF=BF=BD

After a lot of searching Internet came to the help with, I could start =
the system again:

1. Select 3. Escape to loader prompt at the splash screen

2. Type set hint.acpi.0.disabled=3D"0" on the loader prompt

3. Then type boot on the loader prompt

edit the loader.conf

Very very glad with that fix however

 =EF=BF=BD

However the problem is still there, no idea how to prevent the system =
from going to sleep (after about 10 minutes).

No idea how to change those 10 minutes to a much longer time as well =
....=20

 =EF=BF=BD

Note that I have gnome as gui and use the system more or less as server =
and manage the machine partly local via the GUI and partly remote via =
SSH.

 =EF=BF=BD

Related to GNOME I did try ^gsettings set =
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, =
however that did not solve the problem as well.

 =EF=BF=BD

In the end there seems to two problems

a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! =
! and=20

b) a GNOME issue (switching the system off during user inactivity, which =
is bullshit for a server / for ssh-login / with multiple users).

What IMHO apart from the screen lock, this is not a GNOME task but an OS =
 function to be configured by the system administrator.

 =EF=BF=BD

A third problem, not to be addressed here, is that recovery from sleep =
mode does not work on my system as well (even not S1).

 =EF=BF=BD

Most important for the moment is that the system keeps running / is not =
going down after x-time !=20

 =EF=BF=BD

Louis


------=_NextPart_000_0006_01D8F1F1.220895F0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


I need to =
disable acpi and the indicated method for that is to add =
^hint.acpi.0.disabled=3D"1"^ in /boot/loader.conf =
.
However =
that crashes my system !!!!!! 
Not only that, to make it work =
again I have to edit loader.conf on a system which does ^not start^. =
=C2=A0
 
After a lot of searching Internet came to the help with, I =
could start the system again:
1. Select 3. Escape to loader =
prompt at the splash screen
2. Type set =
hint.acpi.0.disabled=3D"0" on the loader =
prompt
3. =
Then type boot on the loader prompt
edit the =
loader.conf
Very very glad with that fix =
however
 
However the problem is still there, no idea how to prevent =
the system from going to sleep (after about 10 =
minutes).
No idea how to change those 10 minutes to a much longer =
time as well .... 
 
Note that I have gnome as gui and use the system more or =
less as server and manage the machine partly local via the GUI and =
partly remote via SSH.
 
Related to GNOME I did try ^gsettings set =
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, =
however that did not solve the problem as well.
 
In the end there seems to two =
problems
a) =
A BSD-issue ACPI-turn off in the bootloader is crashing the system ! ! =
and 
b) a =
GNOME issue (switching the system off during user inactivity, which is =
bullshit for a server / for ssh-login / with multiple =
users).
What IMHO apart from the screen lock, this is not a GNOME =
task but an OS=C2=A0 function to be configured by the system =
administrator.
 
A third problem, not to be addressed here, is that recovery =
from sleep mode does not work on my system as well (even not =
S1).
 
Most important for the moment is that the system keeps =
running / is not going down after x-time ! 
 
Louis

------=_NextPart_000_0006_01D8F1F1.220895F0--


From nobody Sun Nov  6 14:20:27 2022
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 4N4xNG1QzBz4hJ1D
	for ; Sun,  6 Nov 2022 14:20:30 +0000 (UTC)
	(envelope-from l.m.v.breda@xs4all.nl)
Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.169])
	(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 4N4xNF1rx0z3N1q
	for ; Sun,  6 Nov 2022 14:20:29 +0000 (UTC)
	(envelope-from l.m.v.breda@xs4all.nl)
X-KPN-MessageId: 294f80d1-5dde-11ed-823a-005056abad63
Received: from smtp.kpnmail.nl (unknown [10.31.155.39])
	by ewsoutbound.so.kpn.org (Halon) with ESMTPS
	id 294f80d1-5dde-11ed-823a-005056abad63;
	Sun, 06 Nov 2022 15:20:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=xs4all.nl; s=xs4all01;
	h=content-type:mime-version:message-id:date:subject:to:from;
	bh=Tk7Oeyrcpkpg7aagr7xFWGscfnCnp4BJGrcxS8XmeJU=;
	b=CgAhuNNWBoa0pZoRYdEFb4ajzGyV0bMw1ekgA5r1J03oPpaVXfSGkg90jA1GI2Y3u7YPz/cRAZm6a
	 i59QsnyoKkmqrwWYyVu6xTC3GxXJjV8+2azRpk1yDeMiYhn496Y1masTEW/4wn3I37V5qGkq/RRnfG
	 I3s5XKjc/HGNK2ociSj2l3N4MpXVrYqHQEubSnVkbAwf7yVbw/5QcX6AkDXRjc4kpgs87G557oYYy9
	 9ncZIJYIE+qcGOKm1aqIiTGqdXPtrePEFaA7L9jpLwwnx0nzKz9D6augIQtf/FeeoRcT60CxHzM+77
	 +L4LQRPty+2XYjLla8Fx0hAy2HxNTcA==
X-KPN-MID: 33|zjgbXwJB0abgToR8qCmAIYCBvEfBvgsjX48OdqrpA69nak3GNxc9TCaYo3SqAKk
 WJ/s0ymtfvjkI5stZFrUeookgBuErSvpq7aiviY2OLio=
X-KPN-VerifiedSender: Yes
X-CMASSUN: 33|xXR7pmtoy+4QCRIAHNYGZPTQHkFG/H7jJ66yxUx6lvybDFWw/38I5WdnaZcbrFb
 ueZDy8d14FAiuTSEH/eB3YA==
X-Originating-IP: 77.174.182.228
Received: from MAIN (77-174-182-228.fixed.kpn.net [77.174.182.228])
	by smtp.xs4all.nl (Halon) with ESMTPSA
	id 298ecbc1-5dde-11ed-b8b1-005056ab7447;
	Sun, 06 Nov 2022 15:20:28 +0100 (CET)
From: 
To: 
Subject: SAMBA 416-4.16.6 ad GNOME together is impossible :( 
Date: Sun, 6 Nov 2022 15:20:27 +0100
Message-ID: <000401d8f1ea$eb57c9f0$c2075dd0$@xs4all.nl>
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="----=_NextPart_000_0005_01D8F1F3.4D1CA720"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: Adjx6fAUl0384/4oScmoqZtbhrEp9w==
Content-Language: nl
X-Rspamd-Queue-Id: 4N4xNF1rx0z3N1q
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=xs4all.nl header.s=xs4all01 header.b=CgAhuNNW;
	dmarc=pass (policy=none) header.from=xs4all.nl;
	spf=pass (mx1.freebsd.org: domain of l.m.v.breda@xs4all.nl designates 195.121.94.169 as permitted sender) smtp.mailfrom=l.m.v.breda@xs4all.nl
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	SUBJECT_ENDS_SPACES(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[xs4all.nl,none];
	FORGED_SENDER(0.30)[louis.freebsd@xs4all.nl,l.m.v.breda@xs4all.nl];
	R_DKIM_ALLOW(-0.20)[xs4all.nl:s=xs4all01];
	R_SPF_ALLOW(-0.20)[+ip4:195.121.94.169/32];
	RCVD_IN_DNSWL_LOW(-0.10)[195.121.94.169:from];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	FROM_NO_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[xs4all.nl:dkim];
	ASN(0.00)[asn:8737, ipnet:195.121.64.0/18, country:NL];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[xs4all.nl];
	HAS_XOIP(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[louis.freebsd@xs4all.nl,l.m.v.breda@xs4all.nl];
	RCVD_COUNT_THREE(0.00)[3];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	DKIM_TRACE(0.00)[xs4all.nl:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_ENVFROM(0.00)[xs4all.nl];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multipart message in MIME format.

------=_NextPart_000_0005_01D8F1F3.4D1CA720
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I try to get FreeBSD14 current running with both

- GNOME

- SAMBA

That seems to be impossible =E2=98=B9  GNOME and SAMBA416 seems to be =
conflicting !=20

I need SAMBA416 since SAMBA413 is simply not working :(

 =EF=BF=BD

Installing SAMBA does remove GNOME components and vice versa.

 =EF=BF=BD

How to work around this !!??

So, that is a squeeze which urgently need repair IMHO

 =EF=BF=BD

Louis

 =EF=BF=BD

 =EF=BF=BD

pkg install samba416-4.16.6

Message from samba416-4.16.6

[1/4] Deinstalling gnome-shell-42.4_1...

[1/4] Deleting files for gnome-shell-42.4_1: 100%

[2/4] Deinstalling gnome-control-center-43.0...

[2/4] Deleting files for gnome-control-center-43.0: 100%

[3/4] Deinstalling samba413-4.13.17_4...

[3/4] Deleting files for samba413-4.13.17_4: 100%

[4/4] Installing samba416-4.16.6...

[4/4] Extracting samba416-4.16.6: 100%

 =EF=BF=BD

And then I have a fatal GNOME problem, and I have to install GNOME shell

Nov  6 12:29:20 SENIOR pkg[1897]: samba416-4.16.6 deinstalled

Nov  6 12:29:21 SENIOR pkg[1897]: samba413-4.13.17_4 installed

Nov  6 12:29:21 SENIOR pkg[1897]: gnome-control-center-43.0 installed

Nov  6 12:29:21 SENIOR pkg[1897]: gnome-shell-42.4_1 installed

 =EF=BF=BD

SAMBA and GNOME are both working =E2=80=A6.. apart from each other.=20

Where SAMBA is not yet 100% ok e.g. it indicates that the config is not =
ok where testparm says it is ok=20


------=_NextPart_000_0005_01D8F1F3.4D1CA720
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


I try to =
get FreeBSD14 current running with both
- GNOME
- SAMBA
That seems to be impossible =
=E2=98=B9 =C2=A0GNOME and =
SAMBA416 seems to be conflicting ! 
I need SAMBA416 since SAMBA413 is =
simply not working :(
 
Installing SAMBA does remove GNOME components and vice =
versa.
 
How to work around this !!??
So, that is a squeeze which =
urgently need repair IMHO
 
Louis
 
 
pkg install =
samba416-4.16.6
Message from samba416-4.16.6
[1/4] Deinstalling =
gnome-shell-42.4_1...
[1/4] Deleting files for gnome-shell-42.4_1: =
100%
[2/4] =
Deinstalling gnome-control-center-43.0...
[2/4] Deleting files for =
gnome-control-center-43.0: 100%
[3/4] Deinstalling =
samba413-4.13.17_4...
[3/4] Deleting files for samba413-4.13.17_4: =
100%
[4/4] =
Installing samba416-4.16.6...
[4/4] Extracting samba416-4.16.6: =
100%
 
And then I have a fatal GNOME problem, and I have to =
install GNOME shell
Nov=C2=A0 6 12:29:20 SENIOR pkg[1897]: samba416-4.16.6 =
deinstalled
Nov=C2=A0 6 12:29:21 SENIOR pkg[1897]: samba413-4.13.17_4 =
installed
Nov=C2=A0 6 12:29:21 SENIOR pkg[1897]: =
gnome-control-center-43.0 installed
Nov=C2=A0 6 12:29:21 SENIOR =
pkg[1897]: gnome-shell-42.4_1 installed
 
SAMBA and GNOME are both working =
=E2=80=A6.. apart from each other. 
Where SAMBA is not yet 100% ok e.g. =
it indicates that the config is not ok where testparm says it is ok =


------=_NextPart_000_0005_01D8F1F3.4D1CA720--


From nobody Sun Nov  6 14:44:03 2022
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 4N4xvn3lz2z4hLrN
	for ; Sun,  6 Nov 2022 14:44:21 +0000 (UTC)
	(envelope-from paul@gromit.dlib.vt.edu)
Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.123])
	(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 4N4xvm2t6Qz3Swv
	for ; Sun,  6 Nov 2022 14:44:20 +0000 (UTC)
	(envelope-from paul@gromit.dlib.vt.edu)
Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::5])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 663F523DB6;
	Sun,  6 Nov 2022 09:44:14 -0500 (EST)
From: Paul Mather 
Message-Id: <6012509C-F755-4406-BB72-6F1DE32BFF25@gromit.dlib.vt.edu>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6BBF53DD-8D7D-4370-A2D3-8FE3605FB868"
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.200.110.1.12\))
Subject: Re: SAMBA 416-4.16.6 ad GNOME together is impossible :( 
Date: Sun, 6 Nov 2022 09:44:03 -0500
In-Reply-To: <000401d8f1ea$eb57c9f0$c2075dd0$@xs4all.nl>
Cc: "" 
To: louis.freebsd@xs4all.nl
References: <000401d8f1ea$eb57c9f0$c2075dd0$@xs4all.nl>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N4xvm2t6Qz3Swv
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none);
	spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.126.123) smtp.mailfrom=paul@gromit.dlib.vt.edu
X-Spamd-Result: default: False [-2.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	SUBJECT_ENDS_SPACES(0.50)[];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none];
	ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[xs4all.nl];
	R_DKIM_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[paul];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_6BBF53DD-8D7D-4370-A2D3-8FE3605FB868
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 6, 2022, at 9:20 AM,  =
 wrote:

> I try to get FreeBSD14 current running with both
> - GNOME
> - SAMBA
> That seems to be impossible =E2=98=B9  GNOME and SAMBA416 seems to be =
conflicting !=20
> I need SAMBA416 since SAMBA413 is simply not working :(
> =20
> Installing SAMBA does remove GNOME components and vice versa.
> =20
> How to work around this !!??
> So, that is a squeeze which urgently need repair IMHO
> =20
> Louis
> =20
> =20
> pkg install samba416-4.16.6
> Message from samba416-4.16.6
> [1/4] Deinstalling gnome-shell-42.4_1...
> [1/4] Deleting files for gnome-shell-42.4_1: 100%
> [2/4] Deinstalling gnome-control-center-43.0...
> [2/4] Deleting files for gnome-control-center-43.0: 100%
> [3/4] Deinstalling samba413-4.13.17_4...
> [3/4] Deleting files for samba413-4.13.17_4: 100%
> [4/4] Installing samba416-4.16.6...
> [4/4] Extracting samba416-4.16.6: 100%
> =20
> And then I have a fatal GNOME problem, and I have to install GNOME =
shell
> Nov  6 12:29:20 SENIOR pkg[1897]: samba416-4.16.6 deinstalled
> Nov  6 12:29:21 SENIOR pkg[1897]: samba413-4.13.17_4 installed
> Nov  6 12:29:21 SENIOR pkg[1897]: gnome-control-center-43.0 installed
> Nov  6 12:29:21 SENIOR pkg[1897]: gnome-shell-42.4_1 installed
> =20
> SAMBA and GNOME are both working =E2=80=A6.. apart from each other.=20
> Where SAMBA is not yet 100% ok e.g. it indicates that the config is =
not ok where testparm says it is ok=20


I am not using GNOME, but I am using Samba 4.16 and it coexists with =
other ports for me.  I suspect the problem is that GNOME is being built =
against the current default for Samba (4.13) and so GNOME has the 4.13 =
version as a dependency.  Samba 4.16 and 4.13 conflict against each =
other, so when you try and install Samba 4.16 it will uninstall Samba =
4.13 (and GNOME, which depends upon it).  Conversely, if you install =
GNOME it will uninstall Samba 4.16 to make way for its Samba 4.13 =
dependency.

The way to fix this is to have your ports build against a common default =
version of Samba.  In my case, I build ports locally using Poudriere and =
added "samba=3D4.16" to the "DEFAULT_VERSIONS" definition in make.conf =
for that Poudriere ports jail.  So, any ports that build against Samba =
will use Samba 4.16 as a dependency, not 4.13.

If you are using FreeBSD repositories, you might have to wait for Samba =
to switch to 4.16 in /usr/ports/Mk/bsd.default-versions.mk before =
GNOME/Samba ports shake out the way you like.

Cheers,

Paul.=

--Apple-Mail=_6BBF53DD-8D7D-4370-A2D3-8FE3605FB868
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 6, =
2022, at 9:20 AM, <louis.freebsd@xs4all.nl> =
<louis.freebsd@xs4all.nl> wrote:

I try to get FreeBSD14 current running with =
both
- GNOME
- SAMBA
That seems to be impossible =E2=98=B9  GNOME and SAMBA416 =
seems to be conflicting ! 
I need SAMBA416 since SAMBA413 is =
simply not working :(
 
Installing SAMBA does remove GNOME components and vice =
versa.
 
How to work around this !!??
So, that is a squeeze which urgently =
need repair IMHO
 
Louis
 
 
pkg install samba416-4.16.6
Message from =
samba416-4.16.6
[1/4] Deinstalling =
gnome-shell-42.4_1...
[1/4] Deleting files for gnome-shell-42.4_1: =
100%
[2/4] =
Deinstalling gnome-control-center-43.0...
[2/4] Deleting files for =
gnome-control-center-43.0: 100%
[3/4] Deinstalling =
samba413-4.13.17_4...
[3/4] Deleting files for samba413-4.13.17_4: =
100%
[4/4] Installing =
samba416-4.16.6...
[4/4] Extracting samba416-4.16.6: =
100%
 
And then I have a fatal GNOME problem, and I have to =
install GNOME shell
Nov  6 12:29:20 SENIOR pkg[1897]: samba416-4.16.6 =
deinstalled
Nov  =
6 12:29:21 SENIOR pkg[1897]: samba413-4.13.17_4 =
installed
Nov  =
6 12:29:21 SENIOR pkg[1897]: gnome-control-center-43.0 =
installed
Nov  =
6 12:29:21 SENIOR pkg[1897]: gnome-shell-42.4_1 =
installed
 
SAMBA and GNOME are both working =E2=80=A6.. apart from =
each other. 
Where SAMBA is not yet 100% ok e.g. it =
indicates that the config is not ok where testparm says it is ok 


I am not using GNOME, but I am =
using Samba 4.16 and it coexists with other ports for me.  I =
suspect the problem is that GNOME is being built against the current =
default for Samba (4.13) and so GNOME has the 4.13 version as a =
dependency.  Samba 4.16 and 4.13 conflict against each other, so =
when you try and install Samba 4.16 it will uninstall Samba 4.13 (and =
GNOME, which depends upon it).  Conversely, if you install GNOME it =
will uninstall Samba 4.16 to make way for its Samba 4.13 =
dependency.

The way to fix this is to have your =
ports build against a common default version of Samba.  In my case, =
I build ports locally using Poudriere and added "samba=3D4.16" to the =
"DEFAULT_VERSIONS" definition in make.conf for that Poudriere ports =
jail.  So, any ports that build against Samba will use Samba 4.16 =
as a dependency, not 4.13.

If you are using =
FreeBSD repositories, you might have to wait for Samba to switch to 4.16 =
in /usr/ports/Mk/bsd.default-versions.mk before GNOME/Samba ports shake =
out the way you =
like.

Cheers,

Paul.=

--Apple-Mail=_6BBF53DD-8D7D-4370-A2D3-8FE3605FB868--

From nobody Sun Nov  6 17:35:47 2022
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 4N51js5DWNz4ggpm
	for ; Sun,  6 Nov 2022 17:36:01 +0000 (UTC)
	(envelope-from ggm@algebras.org)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N51jr6jxtz3n5B
	for ; Sun,  6 Nov 2022 17:35:59 +0000 (UTC)
	(envelope-from ggm@algebras.org)
Received: by mail-lf1-x135.google.com with SMTP id j4so13973894lfk.0
        for ; Sun, 06 Nov 2022 09:35:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=algebras-org.20210112.gappssmtp.com; s=20210112;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :from:to:cc:subject:date:message-id:reply-to;
        bh=6JBcAc6PhI1qyJDSfKWwPCZm7K+E4Fuqg4IgTGtgEls=;
        b=nmUohGOn/ZbIc2fnNkVAdS5CNSLfirLwxczL+Xzia2FRnMFh7QhBG25tP9BbOuyJVe
         NoZ8ZnqEmiNvPDVERkG9NLlVwnzbBHt5BnZWK9Fa5SD3Q+WzRvfFivUNA6k1gcflHKhe
         jJlTF+UsCN1KjmQ/NSL3P3vZjUfABMtUgAcA7gzby5t+jbdlVVD6rQvC/Vy/zXJeiOcg
         IbpzHg+ZiJqBw7a3qUzqpDTxr6Zq1KajHpYbxec675+5lsvsHPk6TqRpOfhYvdIzDvNP
         g57WABpx4N5pwdMIEt95ptK7mmNxXvF+XZYlhnAB61kROaonCYe1Sk1cTzxUi5pXb+Uf
         DUCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=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=6JBcAc6PhI1qyJDSfKWwPCZm7K+E4Fuqg4IgTGtgEls=;
        b=Tr93ijMt9J7lp1H8pw+yfnN8j6sG9F9/qxbK0M8acd8DtxOnf4wzQKYxCn7EFxMa+z
         F+WFlwBKVMPRlZeGnAbQ/37BVw88WjuVXLRrseyl3lYjXlrzs6WHhCZ3BC8FYfBb5SJx
         pZZCerVAveMRqRIFWOscI2r0kGykP3HEJnjMbjkhPQQ1uXaq89JRypbsg9BFRdii1fmY
         u5DotAdMaGJE2LDDpmGTBWRDb3WsdnvR8rqMdgaG0Iz3IEKHK4Y1vSlk/jRi9leNb6CI
         sZtqYGjd1AJSLrVn0PhOGWLhNkqJrcIgI9ipQ+v4oB699a4YL5fVp0jLxRh7G5AcuhlL
         iSnQ==
X-Gm-Message-State: ACrzQf2REyZBO+BvADHFcbz06vrGLacPIM7PoWSBiX7uFEACPzje+MuR
	k13g/rHWjzubyO+bE4Y+DGqPOn+FKulbg2rQbStroJ/6JW2P1Q==
X-Google-Smtp-Source: AMsMyM7sZt/RJrU/j9RrRFjaVHMs95HpZkWI86uviZeSEMqF87V+M58bJuVSUPmt48Gv8KXTYlpxul8ZrFd598dPJA0=
X-Received: by 2002:ac2:58cb:0:b0:4a2:6e08:2c50 with SMTP id
 u11-20020ac258cb000000b004a26e082c50mr17524886lfo.135.1667756158290; Sun, 06
 Nov 2022 09:35:58 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 <20221021175142.GA62386@www.zefox.net> 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com> <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
 <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com> <20221024174930.GA79381@www.zefox.net>
  <20221025005012.GA80394@www.zefox.net>
 <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com> <20221106031204.GA45827@www.zefox.net>
 <20221106210716.1c997091ca40ea02ede9f159@dec.sakura.ne.jp>
In-Reply-To: <20221106210716.1c997091ca40ea02ede9f159@dec.sakura.ne.jp>
From: George Michaelson 
Date: Sun, 6 Nov 2022 17:35:47 +0000
Message-ID: 
Subject: Re: Seeking an idiot's guide to etcupdate/mergemaster
To: freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4N51jr6jxtz3n5B
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=algebras-org.20210112.gappssmtp.com header.s=20210112 header.b=nmUohGOn;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of ggm@algebras.org designates 2a00:1450:4864:20::135 as permitted sender) smtp.mailfrom=ggm@algebras.org
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	R_DKIM_ALLOW(-0.20)[algebras-org.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::135:from];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[algebras-org.20210112.gappssmtp.com:+];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[algebras.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

I am probably alone in this but I find the CVS style <<<<>>>>
markers in the update diffs intensely confusing. Given many merges are
large blocks, its almost impossible to keep context flitting about in
vi to find the old/new insertions. The odd thing is that post edit,
the view you get afterward is traditional diff/patch mode, so its
really bizarre: shown one way in edit mode, shown another in review
mode before commit.

There are far more urgent problems than fixing my 61 year old diff
format confusion, I don't think this justifies a bug report.

TL;DR the merge process for FreeBSD-update and like, can be intensely
confusing when you try to reconcile what it tells you about /etc/

-G

On Sun, Nov 6, 2022 at 12:07 PM Tomoaki AOKI  wrote:
>
> On Sat, 5 Nov 2022 20:12:04 -0700
> bob prohaska  wrote:
>
> > On Mon, Oct 24, 2022 at 08:32:17PM -0700, Mark Millard wrote:
> > >
> > > Your /etc/rc.d/ldconfig script seems to have not been updated
> > > by use of etcupdate or mergemaster or other such. (How much
> > > else is also out of date? How much of what you have for /etc/
> > > and the like goes back to 2022-Jan-07 or before?)
> > >
> >
> > Alas, that is too true. The system was set up on July 2, 2020
> > and I've never managed to make sense of either mergemaster nor
> > etcupdate. Far as I could tell it didn't matter, the host ran
> > correctly, until now.
> >
> > It's been transplanted to a new hard drive, which allows the
> > installation of a ports tree. Ports don't install because of
> > the stale /etc/rc.d/ldconfig file.
> >
> > Since no changes have been made to /etc/ apart from /etc/rc.conf
> > is it possible to simply let mergemaster or etcupdate install
> > the latest defaults? I have looked at the manpage for etcupdate
> > and didn't recognize any straightforward way to simply accept
> > all updates. This particular system is expendable, so I'd be
> > glad to try things that might not work well, or at all.
> >
> > Apologies if I'm being dumb (probably guilty) or lazy (definitely
> > guilty). The barrage of questions generated by etcupdate  and
> > mergemaster is simply overwhelming. And, I suspect, largely
> > unnecessary.
> >
> > Thanks for reading!
> >
> > bob prohaska
>
> For a relatively casual way.
>
> If I'm facing the same situation, I will...
>
>  1. `mergemaster -UFiP` for now, then...
>  2. `etcupdate extract -B` for next upgrade.
>
> And on next upgrade, `etcupdate -p` before installing upgrade,
> and then `etcupdate -B` after install.
> You can add -n for dry-run before actual etcupdate.
>
>
> For some notes:
> mergemaster, the old and less maintained tool, uses current installation
> and updated tree. Old dedault state is not at all considered.
>
> So it could be used for already-updated states.
>
> etcupdate, the currently maintained tool, uses previous and updated
> defaults, and current installation (working environment).
> It compares differences between old and new default, check if the
> differences can be sanely applicable to currently working environment
> or not, and if it's sane, apply the diff automatically.
> If any conflict happenes, ask the admin (this case, you) for actions.
>
> So it requires previous default state, thus cannot use for this case,
> except you are sure what the actual previous revision was and can
> prepare the source tree (possibly obj tree, too?) and somehow create
> "current" tree ATM (will be turned over to "previous" tree on etcupdate
> run).
>
> See manpages for detail.
>
> --
> Tomoaki AOKI    
>

From nobody Sun Nov  6 20:16:47 2022
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 4N55Hy5jFKz4h1tY
	for ; Sun,  6 Nov 2022 20:17:18 +0000 (UTC)
	(envelope-from glebius@freebsd.org)
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-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N55Hx57MQz44v8
	for ; Sun,  6 Nov 2022 20:17:17 +0000 (UTC)
	(envelope-from glebius@freebsd.org)
Received: from cell.glebi.us (localhost [127.0.0.1])
	by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 2A6KGmcN015712
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 6 Nov 2022 12:16:48 -0800 (PST)
	(envelope-from glebius@freebsd.org)
Received: (from glebius@localhost)
	by cell.glebi.us (8.16.1/8.16.1/Submit) id 2A6KGltt015711;
	Sun, 6 Nov 2022 12:16:47 -0800 (PST)
	(envelope-from glebius@freebsd.org)
X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f
Date: Sun, 6 Nov 2022 12:16:47 -0800
From: Gleb Smirnoff 
To: Chris 
Cc: Max Baroi , Mike Karels ,
        current@freebsd.org
Subject: Re: trpt(8) to be decomissioned
Message-ID: 
References: 
 <97286FA9-DD47-4EB2-BD7A-C2A8BC8B62B5@karels.net>
 <4e69d854-e872-4833-b836-f9caf5fe76f0@baroi.com>
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4N55Hx57MQz44v8
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org
X-Spamd-Result: default: False [-3.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_THREE(0.00)[3];
	R_SPF_SOFTFAIL(0.00)[~all];
	DMARC_NA(0.00)[freebsd.org];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[glebius];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	HAS_XAW(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

  Chris,

On Fri, Nov 04, 2022 at 10:35:17AM -0700, Chris wrote:
C> > the reason I want to retire it is not that it consumes 40 Kb
C> > in the repository.  The reason is that knows kernel structures,
C> > and fails to compile after changes to them.  So the tool that
C> > nobody uses requires special care when working on TCP.  The
C> > kernel headers disclose the structures for trpt (with some
C> > protection with _WANT_TCPCB, though) and some software from
C> > ports (not calling names!) would start use them too. Now a
C> > kernel developer needs to care not only about trpt, but
C> > about this software, too.
C> > 
C> > On the kernel side there is also TCPDEBUG code that needs
C> > to be kept compilable, while apparently nobody uses it.
C> While I really hate hearing that small utils
C> (almost elegant in their simplicity) that have worked perfectly
C> well for a great many years must be kicked to the curb. I guess
C> I can see your point. However I think TCPDEBUG affects a great
C> deal more that trpt(8). I hope your not implying that it should
C> go as well.

I'd like to hear use scenarios of TCPDEBUG without trpt. What does
it provide that other logging facilities (BB, DTrace) doesn't?

-- 
Gleb Smirnoff

From nobody Sun Nov  6 22:47:38 2022
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 4N58dV6GdQz4hLQW
	for ; Sun,  6 Nov 2022 22:47:42 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N58dT4dB7z3mWY
	for ; Sun,  6 Nov 2022 22:47:41 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: by mail-qt1-x834.google.com with SMTP id c15so6073133qtw.8
        for ; Sun, 06 Nov 2022 14:47:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=ObTG2RKVMJkcnjU+T73K9zM0p3E+9q0gK+InPRK2Kmw=;
        b=ezSiqO1WsITTk+EF+GCu2kdnImJZu0Ww3IKjl5DXCQiKlaPizh+YMT81Ouoe8ifNnW
         dNMQxG6gZdzKjFSq9nou1c1NO4zi51BwNb3TJ24BioNj01shkl520P2js7ZJcqCj+Qcb
         yHspuRYDg2+qUZ5zjIkof8ItjzkE101WMp+OqV74J+IC3dUXjm/xv1a18PyzxvEw5/sz
         Xr99qq7HIWRiXm+vxkVCR2n5bPjm9HKlltwUrbn4lYYLzheD8UVZd24rzljk6U7BHCbn
         SzuNZdPpVtNQFDEgkpwVGWArUP1qEZKqWOoVEuzMOmhdackGXQljalg4YsjYluai5PGf
         u4GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id
         :sender:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ObTG2RKVMJkcnjU+T73K9zM0p3E+9q0gK+InPRK2Kmw=;
        b=19CBG+1tpZ/ph1P3WXUNwXDgYpEAwoxjBn0x1NddDGpNmx9PBphmFPV4YH4X1UtKsU
         INIfHCkaH92Q+0O7VJkUhhamw/8TBtgrzRV5pJVRN03tzcyebqjlH1Ew3M349k/GWrRE
         RHsUCSu0z0YjVJkAOVDyQeRfMkLrvAd5gvLgberxMURwC7jfpdfLRPnpv+An+u7ngz0l
         VSjCWSdTMLArhbwnSqB/GkIuoHmTJn/8tv70UznS+7EIWP/CPR1t8MlOOe+iennt5NdF
         QjrLQuOjb2Yswo0N9OFfKgh5yLYPlandfEwykBDLcvlFFKf5QE4LS3igAC+NMTi/A692
         Bwqw==
X-Gm-Message-State: ACrzQf1RVwN5q1p4G6qtWdbdaME4yMc1nBHFoTuJbN3nqy1nErkHgafP
	SyLjjIA2MFOe5d7IbYR9Ap2weID8HCY=
X-Google-Smtp-Source: AMsMyM4v49bNP1uL3yRTCb6n34IEfcSSdPul+CKToqjlhXLFdsLABg/3UAxSFbYfgV+59qM7mvSIvw==
X-Received: by 2002:ac8:604c:0:b0:3a5:26a5:6d93 with SMTP id k12-20020ac8604c000000b003a526a56d93mr31155339qtm.541.1667774860156;
        Sun, 06 Nov 2022 14:47:40 -0800 (PST)
Received: from ?IPV6:2600:1700:3580:3560:228:f8ff:fe04:d12? ([2600:1700:3580:3560:228:f8ff:fe04:d12])
        by smtp.gmail.com with ESMTPSA id j67-20020a378746000000b006fa5815b88dsm5275770qkd.88.2022.11.06.14.47.39
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sun, 06 Nov 2022 14:47:39 -0800 (PST)
Message-ID: <277f029d-828b-74c3-ab38-862c7959df55@FreeBSD.org>
Date: Sun, 6 Nov 2022 17:47:38 -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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: How to disable ACPI? (on FreeBSD14 CURRENT)
To: louis.freebsd@xs4all.nl, freebsd-current@FreeBSD.org
References: <000501d8f1e8$c0442df0$40cc89d0$@xs4all.nl>
Content-Language: en-US
From: Alexander Motin 
In-Reply-To: <000501d8f1e8$c0442df0$40cc89d0$@xs4all.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4N58dT4dB7z3mWY
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=ezSiqO1W;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::834 as permitted sender) smtp.mailfrom=mavbsd@gmail.com
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::834:from];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[];
	FREEMAIL_TO(0.00)[xs4all.nl,FreeBSD.org];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

Hi Louis,

You should not try to disable ACPI these days.  It was a recommendation 
in some cases probably ~15 years ago, but for many years now modern 
systems depend on ACPI for proper operation.  I have no idea what causes 
crash in your case, but I would not expect it to end up good any way.

I know nothing about GNOME, haven't touched it for many years, but it 
must be it what makes your laptop to sleep.  FreeBSD itself does not 
implement such automatic policies.

On 06.11.2022 09:04, louis.freebsd@xs4all.nl wrote:
> I need to disable acpi and the indicated method for that is to add 
> ^hint.acpi.0.disabled="1"^ in /boot/loader.conf .
> 
> However that crashes my system !!!!!!
> 
> Not only that, to make it work again I have to edit loader.conf on a 
> system which does ^not start^.
> 
> After a lot of searching Internet came to the help with, I could start 
> the system again:
> 
> 1. Select 3. Escape to loader prompt at the splash screen
> 
> 2. Type set hint.acpi.0.disabled="0" on the loader prompt
> 
> 3. Then type boot on the loader prompt
> 
> edit the loader.conf
> 
> Very very glad with that fix however
> 
> However the problem is still there, no idea how to prevent the system 
> from going to sleep (after about 10 minutes).
> 
> No idea how to change those 10 minutes to a much longer time as well ....
> 
> Note that I have gnome as gui and use the system more or less as server 
> and manage the machine partly local via the GUI and partly remote via SSH.
> 
> Related to GNOME I did try ^gsettings set 
> org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, 
> however that did not solve the problem as well.
> 
> In the end there seems to two problems
> 
> a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! 
> ! and
> 
> b) a GNOME issue (switching the system off during user inactivity, which 
> is bullshit for a server / for ssh-login / with multiple users).
> 
> What IMHO apart from the screen lock, this is not a GNOME task but an 
> OS  function to be configured by the system administrator.
> 
> A third problem, not to be addressed here, is that recovery from sleep 
> mode does not work on my system as well (even not S1).
> 
> Most important for the moment is that the system keeps running / is not 
> going down after x-time !

-- 
Alexander Motin

From nobody Sun Nov  6 22:59:15 2022
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 4N58tz6T94z4hP5C
	for ; Sun,  6 Nov 2022 22:59:23 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4N58ty59XCz3qCM;
	Sun,  6 Nov 2022 22:59:22 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 2A6MxFrk085984;
	Sun, 6 Nov 2022 16:59:15 -0600 (CST)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id X5TdJUM8aGPeTwEA4+wvSQ
	(envelope-from ); Sun, 06 Nov 2022 16:59:15 -0600
From: Mike Karels 
To: Alexander Motin 
Cc: louis.freebsd@xs4all.nl, freebsd-current@FreeBSD.org
Subject: Re: How to disable ACPI? (on FreeBSD14 CURRENT)
Date: Sun, 06 Nov 2022 16:59:15 -0600
X-Mailer: MailMate (1.14r5921)
Message-ID: 
In-Reply-To: <277f029d-828b-74c3-ab38-862c7959df55@FreeBSD.org>
References: <000501d8f1e8$c0442df0$40cc89d0$@xs4all.nl>
 <277f029d-828b-74c3-ab38-862c7959df55@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=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4N58ty59XCz3qCM
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_NO_TLS_LAST(0.10)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[karels.net];
	FREEFALL_USER(0.00)[mike];
	ARC_NA(0.00)[];
	FREEMAIL_CC(0.00)[xs4all.nl,FreeBSD.org];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On 6 Nov 2022, at 16:47, Alexander Motin wrote:

> Hi Louis,
>
> You should not try to disable ACPI these days.  It was a recommendation=
 in some cases probably ~15 years ago, but for many years now modern syst=
ems depend on ACPI for proper operation.  I have no idea what causes cras=
h in your case, but I would not expect it to end up good any way.
>
> I know nothing about GNOME, haven't touched it for many years, but it m=
ust be it what makes your laptop to sleep.  FreeBSD itself does not imple=
ment such automatic policies.

It could the BIOS also if this is a laptop.

		Mike

> On 06.11.2022 09:04, louis.freebsd@xs4all.nl wrote:
>> I need to disable acpi and the indicated method for that is to add ^hi=
nt.acpi.0.disabled=3D"1"^ in /boot/loader.conf .
>>
>> However that crashes my system !!!!!!
>>
>> Not only that, to make it work again I have to edit loader.conf on a s=
ystem which does ^not start^.
>>
>> After a lot of searching Internet came to the help with, I could start=
 the system again:
>>
>> 1. Select 3. Escape to loader prompt at the splash screen
>>
>> 2. Type set hint.acpi.0.disabled=3D"0" on the loader prompt
>>
>> 3. Then type boot on the loader prompt
>>
>> edit the loader.conf
>>
>> Very very glad with that fix however
>>
>> However the problem is still there, no idea how to prevent the system =
from going to sleep (after about 10 minutes).
>>
>> No idea how to change those 10 minutes to a much longer time as well .=
=2E..
>>
>> Note that I have gnome as gui and use the system more or less as serve=
r and manage the machine partly local via the GUI and partly remote via S=
SH.
>>
>> Related to GNOME I did try ^gsettings set org.gnome.settings-daemon.pl=
ugins.power sleep-inactive-ac-timeout 0^, however that did not solve the =
problem as well.
>>
>> In the end there seems to two problems
>>
>> a) A BSD-issue ACPI-turn off in the bootloader is crashing the system =
! ! and
>>
>> b) a GNOME issue (switching the system off during user inactivity, whi=
ch is bullshit for a server / for ssh-login / with multiple users).
>>
>> What IMHO apart from the screen lock, this is not a GNOME task but an =
OS=C2=A0 function to be configured by the system administrator.
>>
>> A third problem, not to be addressed here, is that recovery from sleep=
 mode does not work on my system as well (even not S1).
>>
>> Most important for the moment is that the system keeps running / is no=
t going down after x-time !
>
> -- =

> Alexander Motin

From nobody Mon Nov  7 03:03:25 2022
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 4N5GJc3Yhrz4gfgK
	for ; Mon,  7 Nov 2022 03:03:28 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5GJc2sz6z4DGk
	for ; Mon,  7 Nov 2022 03:03:28 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667790208;
	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=DuLgK/cua8/CC8EiJ2j/T0G1xrWr0qleymDYiXZ1mJ4=;
	b=CQoBw2oshh9DfGgVMVCH503Lu0nYBrrJZ6IQ0wOm8t/fzYanK2p1Xgt7pXhcuiJT0Mg40t
	46hewQb0It7NLZrVezFZEy0LhJU/gpPZdNtTN/ErrSIx8P34pB3lVZaMslHsF0wMbS5OJt
	ycqkTQ3pLOHRUr31I2KwWtQpqhftZLwAxV3YzJz69sHRxKEK9KEZONBfrZkNhNsFKTKbyE
	mu7AlLbwHtYw8cgVbk9u6K997HMzcwuv/OgIfDHb0mdJarHyVP867yD4PPrewB/Zlj5jON
	hsi3Zko/eB2T1pZvqtsbutl0gPRG84I7hWvb0b+fguuKzHMkONbCkutILVV9Uw==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N5GJc06YCz1JFK
	for ; Mon,  7 Nov 2022 03:03:27 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: <8e3e8a1f-495e-6c53-7450-5e22e6b50025@freebsd.org>
Date: Mon, 7 Nov 2022 03:03:25 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
To: freebsd-current@freebsd.org
References: <3e925370-3f09-101d-e4f3-5fa2c7f28c83@freebsd.org>
Content-Language: en-GB
From: Graham Perrin 
X-Priority: 5 (Lowest)
Subject: linsysfs on /usr/src/sys (linsysfs, local)
Organization: FreeBSD
In-Reply-To: <3e925370-3f09-101d-e4f3-5fa2c7f28c83@freebsd.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------yW3KBwhOm401gpTZJnkkxHBK"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667790208;
	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=DuLgK/cua8/CC8EiJ2j/T0G1xrWr0qleymDYiXZ1mJ4=;
	b=wcQt8+NYl2YXflHOfOOhyvWFYpcy7fV6bYeVXJM3aZB2TWQLxbaGiS1gCjOCUpzTz9B+6/
	PNuENNXoRw+ZldWMvOJrEcjuBmvXRgjbfsb2a1idD06KNr2jb6+QMfc2TWhryl8ncg5h+B
	h4kAOweG0S7KY03WTWjNcJqdSEKZX4HY7OBkwdafRSD6AsazK079j1xUYkZpvSZDfJoPO2
	AIyAjr+NUWylxve9wslazzm8P5sT2OVxB474+dTsmzsgJvM8Q/UDL26zCuWPrdfHyyjimb
	O3+G0QR60F5wku2tp+8qF5+djFX0YEVcG7TQxGGL3rZ7GD8p+utbQ0HM+uVE7g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667790208; a=rsa-sha256; cv=none;
	b=jxNR65JbTm/jCXKJ8pv9CFq0PM0RhRIFhJNAtAUF6f6w92ReS8sNY+lLXrW7tUlrJ164Mk
	4Xw5PPCKqwm6hr/yx1v1DwlxvuQ0hmhv3+il1BeWrhZ1FeCQh7V66sE0iSHQNFeWj8E+8Z
	hIkxqNL0Wh5yYCQZuj6JcZrgVUD3E+JID7dn9JBVbVFhwEFnAGeB+33f6XR/1/cDVpqJvy
	BAa7/PFJbdaoNKN4B1W21mOTZ9t9BJ8izm2qSvRwNyZWP3rXNRx8gfkfMo6pKK4fJxcLwW
	xgv7K6jRKQADRwsHe4DhsKlzxpsYaPYfK6CgzD/0unYhGfR2W6HCbJNSG0tXbA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------yW3KBwhOm401gpTZJnkkxHBK
Content-Type: multipart/mixed; boundary="------------0N0ENOmppInOEe4zvIHxw2ZI";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: <8e3e8a1f-495e-6c53-7450-5e22e6b50025@freebsd.org>
Subject: linsysfs on /usr/src/sys (linsysfs, local)
References: <3e925370-3f09-101d-e4f3-5fa2c7f28c83@freebsd.org>
In-Reply-To: <3e925370-3f09-101d-e4f3-5fa2c7f28c83@freebsd.org>

--------------0N0ENOmppInOEe4zvIHxw2ZI
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjkvMTAvMjAyMiAyMTozMCwgR3JhaGFtIFBlcnJpbiB3cm90ZToNCg0KPiBTdWJqZWN0
OiBwb3VkcmllcmUgamFpbCB1cGRhdGUgZnJvbSBzb3VyY2U6IHN5c2NhbGwubWsgZG9lcyBu
b3QgZXhpc3QNCg0KPiBBZnRlciB1cGRhdGluZyB0byB5ZXN0ZXJkYXkncyANCj4gYWJhOTIx
YmQ5ZTE4NjlkYWU5YWU0Y2M2ZTBjMDQ4Zjk5NzQwMTAzNCwgSSBhaW1lZCBmb3IgYSByb3V0
aW5lIHVwZGF0ZSANCj4gb2YgdGhlIGphaWwgdGhhdCBJIHVzZWQgZm9yIHBvdWRyaWVyZS4N
Cj4NCj4NCj4gcG91ZHJpZXJlIGphaWwgLXUgLUogMSAtaiBtYWluDQo+IOKApg0KPiA9PT0+
IGxpYi9saWJjIChpbnN0YWxsKQ0KPiBtYWtlWzVdOiAiL3Vzci9zcmMvbGliL2xpYmMvc3lz
L01ha2VmaWxlLmluYyIgbGluZSA5OiBDYW5ub3Qgb3BlbiANCj4gL3Vzci9zcmMvc3lzL3N5
cy9zeXNjYWxsLm1rDQo+IG1ha2VbNV06IEZhdGFsIGVycm9ycyBlbmNvdW50ZXJlZCAtLSBj
YW5ub3QgY29udGludWUNCj4gbWFrZVs1XTogc3RvcHBlZCBpbiAvdXNyL3NyYy9saWIvbGli
Yw0KPiAqKiogRXJyb3IgY29kZSAxDQo+IOKApg0KDQoNCmJkcmV3ZXJ5IGFuZCBvdGhlcnMg
aW4gSVJDIGhlbHBlZCBtZSB0byByZWFsaXNlIGFuIG9mZmVuZGluZyBtb3VudC4NCg0KDQpX
aXRoIGxpbnV4X2VuYWJsZTogWUVTLA0KDQpyb290QG1vd2EyMTktZ2pwNC04NTcwcC1mcmVl
YnNkOn4gIyBtb3VudCB8IGdyZXAgc3lzDQpsaW5zeXNmcyBvbiAvdXNyL3NyYy9zeXMgKGxp
bnN5c2ZzLCBsb2NhbCkNCnJvb3RAbW93YTIxOS1nanA0LTg1NzBwLWZyZWVic2Q6fiAjIGV4
aXQNCmxvZ291dA0KJSBncmVwIGxpbnN5c2ZzIC9ldGMvZnN0YWINCiMgbGluc3lzZnPCoMKg
wqDCoMKgIC9jb21wYXQvbGludXgvc3lzwqDCoMKgwqDCoMKgIGxpbnN5c2ZzIA0KcnfCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMMKgwqDCoMKg
IDANCiMgbGluc3lzZnPCoMKgwqDCoMKgwqDCoCAvY29tcGF0L3VidW50dS9zeXPCoMKgwqDC
oMKgIGxpbnN5c2ZzIA0KcncsbGF0ZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIDDCoMKgwqDCoCAwDQolDQoNCg0KQWZ0ZXIgbGludXhfZW5hYmxlOiBOTyBhbmQg
YSByZWJvb3QsDQoNCiUgc3lzcmMgLWYgL2V0Yy9yYy5jb25mIGxpbnV4X2VuYWJsZQ0KbGlu
dXhfZW5hYmxlOiBOTw0KJSBtb3VudCB8IGdyZXAgc3lzDQolIGRhdGUgOyB1bmFtZSAtYUtV
DQpXZWQgMiBOb3YgMjAyMiAxOTowNjowMSBHTVQNCkZyZWVCU0QgbW93YTIxOS1nanA0LTg1
NzBwLWZyZWVic2QgMTQuMC1DVVJSRU5UIEZyZWVCU0QgMTQuMC1DVVJSRU5UICMyNCANCm1h
aW4tbjI1ODkwMC1hYmE5MjFiZDllMTg6IFNhdCBPY3QgMjkgMTQ6Mzk6NTkgQlNUIDIwMjIg
DQpncmFoYW1wZXJyaW5AbW93YTIxOS1nanA0LTg1NzBwLWZyZWVic2Q6L3Vzci9vYmovdXNy
L3NyYy9hbWQ2NC5hbWQ2NC9zeXMvR0VORVJJQy1OT0RFQlVHIA0KYW1kNjQgMTQwMDA3MyAx
NDAwMDczDQolIHN1ZG8gc2VydmljZSBsaW51eCBvbmVzdGFydA0KZ3JhaGFtcGVycmluJ3Mg
cGFzc3dvcmQ6DQprbGRsb2FkOiBhbiBlcnJvciBvY2N1cnJlZCB3aGlsZSBsb2FkaW5nIG1v
ZHVsZSBsaW51eC4gUGxlYXNlIGNoZWNrIA0KZG1lc2coOCkgZm9yIG1vcmUgZGV0YWlscy4N
Ci9ldGMvcmMuZC9saW51eDogV0FSTklORzogVW5hYmxlIHRvIGxvYWQga2VybmVsIG1vZHVs
ZSBsaW51eA0Ka2xkbG9hZDogYW4gZXJyb3Igb2NjdXJyZWQgd2hpbGUgbG9hZGluZyBtb2R1
bGUgbGludXg2NC4gUGxlYXNlIGNoZWNrIA0KZG1lc2coOCkgZm9yIG1vcmUgZGV0YWlscy4N
Ci9ldGMvcmMuZC9saW51eDogV0FSTklORzogVW5hYmxlIHRvIGxvYWQga2VybmVsIG1vZHVs
ZSBsaW51eDY0DQolIG1vdW50IHwgZ3JlcCBzeXMNCmxpbnN5c2ZzIG9uIC9jb21wYXQvbGlu
dXgvc3lzIChsaW5zeXNmcywgbG9jYWwpDQolIHN1ZG8gc3lzcmMgbGludXhfZW5hYmxlPSJZ
RVMiDQpsaW51eF9lbmFibGU6IE5PIC0+IFlFUw0KJQ0KDQoNCldpdGggbGludXhfZW5hYmxl
OiBZRVMgKHJlLWVuYWJsZWQpIGFuZCBhIHJlYm9vdCwgdGhlIGNsb2JiZXIgb2YgDQovdXNy
L3NyYy9zeXMgcmVjdXJyZWQuDQoNCi0tLS0NCg0KUmVzb2x2ZWQgdGhyb3VnaCBhbiBPUyB1
cGRhdGUgb24gM3JkIE5vdmVtYmVyOg0KDQolIHVuYW1lIC1hS1UNCkZyZWVCU0QgbW93YTIx
OS1nanA0LTg1NzBwLWZyZWVic2QgMTQuMC1DVVJSRU5UIEZyZWVCU0QgMTQuMC1DVVJSRU5U
ICMyNSANCm1haW4tbjI1OTAwNC0yYzEwYmU5ZTA2ZDQ6IFRodSBOb3bCoCAzIDAwOjE0OjUy
IEdNVCAyMDIyIA0KZ3JhaGFtcGVycmluQG1vd2EyMTktZ2pwNC04NTcwcC1mcmVlYnNkOi91
c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvc3lzL0dFTkVSSUMtTk9ERUJVRyANCmFtZDY0
IDE0MDAwNzMgMTQwMDA3Mw0KDQo=

--------------0N0ENOmppInOEe4zvIHxw2ZI--

--------------yW3KBwhOm401gpTZJnkkxHBK
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmNodX0FAwAAAAAACgkQt2dIb0oY1Aux
Cg//VbwywQLOJ+Xk2u/Tj/o1m6IdUUJSWOf2PeG+chI7gSO4kMWNf7MICXGMzjT91v6Z8fvgRGjY
OHTish5r2Ee7zG86lB8+X7G8RBW+fNCnRswzvL9QIksN8LG/RNVACGqkHp3Xasrz2m1naXCWwQcH
Q+bqQGcWwROEvWLiXskzzDOiHkVNP7w2rb6ibyBkl4l4Pd7sIhGiRcuu5QCOvBcMOxVN8S8COQtV
G6E2RvR6Ku2Y0xGCXd6DP3Gu0DTi1Fc8+MQnk+YKpkeIckHxjPJzrrKdILG5mjs96MshMQ1WnivE
Mpdo+dyWPS91mVPe0SAubZN/5z5A6Zwevl/UJUGmV/Xbx6U3i8t1IkCgzIcqHCe6nsHGoerC/+3x
ejI7AZBWi8p4+DIsGcyvIbwJqBDFI/efZ8Q6d2UbPe4USzUpe4ytncKTiLpgHxyqRASUzVGN1Y81
FrmdG377UxoGwe3jsYzgajnbY/a2whJQQ/xZI9IWPTtA7Au6YRJLAzD8dX91CM+W+dEga30zSQRe
qk2qSvFNyR5EQ8XMLHRuhzPkPogvGMZtjG8NO0TBMTDZnfQsKYA9wHP3afNTBV8EuXGgCx2hGCJ8
vY07uCQvxSF3/yCTNuxsf84TAvUzCvCNUoqjpfjN5RKEZwZZJLTXn2N6UNOh25U5hy18sbXjlJnC
NGE=
=o0Ov
-----END PGP SIGNATURE-----

--------------yW3KBwhOm401gpTZJnkkxHBK--

From nobody Mon Nov  7 04:24:06 2022
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 4N5J5j30vyz4gqw1
	for ; Mon,  7 Nov 2022 04:24:09 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5J5j1fhWz4L4G
	for ; Mon,  7 Nov 2022 04:24:09 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667795049;
	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=LzSmJj4Yza70XendJPk1XXbD1SHUHc00hy7Jybig99I=;
	b=AQRU4NRz0LctQiuT538XKWNUpMx4G24wmyybD0lvQ9PU8QJVeyxBy6VouWpFv/+e1gsyTi
	afyc0ZI4aP1ZAibe1+sAqujsK8ECnaDqusSiKF9pTIoAcYU+C00ePX8H/BQFi0YvAFJKoz
	UHkczrh2Pbjkrqt8X2fHbGPzp70ivLdMglRcPrSzNdYgUvrDBgIR7qq4Hu4E5bxdczPZQL
	UIGxA3c3z47fXUWQM9u7ne3yxA7XlX7G86H8hPqwGNc4MIxdrf3kFJ92ZKd8EVIyKIVFZW
	6PSn0jyjs13o1weqmkeV4J0AIZLFV4+16M0zc6ktqe/SjZ428UajmzJGTl+Anw==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N5J5h64cpz1JRp
	for ; Mon,  7 Nov 2022 04:24:08 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: <37b896e9-14c5-5e12-42c2-f38aa648f413@freebsd.org>
Date: Mon, 7 Nov 2022 04:24:06 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: 
 <20221021175142.GA62386@www.zefox.net>
 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
 <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
 <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com>
 <20221024174930.GA79381@www.zefox.net>
 
 <20221025005012.GA80394@www.zefox.net>
 <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com>
 <20221106031204.GA45827@www.zefox.net>
 <20221106210716.1c997091ca40ea02ede9f159@dec.sakura.ne.jp>
 
From: Graham Perrin 
Subject: Re: Seeking an idiot's guide to etcupdate/mergemaster
Organization: FreeBSD
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------v0VgYj9tJAMgGWDHm0TRLopS"
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667795049;
	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=LzSmJj4Yza70XendJPk1XXbD1SHUHc00hy7Jybig99I=;
	b=tC+PFj/LoOX+N+wfV8NgJbi2bI+e2e5XdziiSRX3NBS/9oZkpK9rhL/nLE8kHlmEqJG2gB
	q6ms85+bBizMLL7ZdNwi7dFPVakzzp3zIg/kv78D5VVSj59PEuVMxadTw4q9CZ3MQupERd
	UC7o0F0Xg+pwedKdk/F86y4+aH8JQlgXGnck0zCG6SHj43ud1Iw+2TfRTqsNieTSw6xNRS
	riwPMCbzmgbv/ocvpi5WgF9FNjN9Pjo10sWIinUNpm9BlEz5s/XvZDBS1qL777uJjHmE0n
	IAGzxVSGWIA9rY7OW2wZeEScLe87yi4gc3pTLr+qhSllAQ5PptkV5K2G7N5FAA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667795049; a=rsa-sha256; cv=none;
	b=WAADp2v3AR3QRx+xJF0fEvUI5atL2wqIEhpSZw9GPrQAo7lQfID91f/kbVkcmcVqxT7sTO
	LV50qUFpmrBlVslAecqJAnGkwXCE9/FgG98Q8mQcFy57HL6qXKY+GTUerz+B/2aHakxKly
	8j1sjYbuFCX4ED8XeNFSLKLaoz44x8MbDzwta60AJ3CpizBJERSTaTIswDGwWkGTT0pNZm
	KpzC4bwtMu+XmPWyzEHtNhnKwcLeg8khjzIEKP8AUzmwIb8BwNNPO80dsUPfOvfdTv3pSG
	BXmPnBZ4O5qZXqcsYsdXTDnBWJJ4+opR7yULEnywBnVf5vw3MY7Rw1leF9eiPQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------v0VgYj9tJAMgGWDHm0TRLopS
Content-Type: multipart/mixed; boundary="------------aaShFLVSlFdU6oOzxstdc0n8";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: <37b896e9-14c5-5e12-42c2-f38aa648f413@freebsd.org>
Subject: Re: Seeking an idiot's guide to etcupdate/mergemaster
References: 
 <20221021175142.GA62386@www.zefox.net>
 
 <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
 <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com>
 <5719632F-8A92-4784-88D8-EAE3F20F2FA3@yahoo.com>
 <20221024174930.GA79381@www.zefox.net>
 
 <20221025005012.GA80394@www.zefox.net>
 <605A6723-5D31-495C-8200-FD107115FC81@yahoo.com>
 <20221106031204.GA45827@www.zefox.net>
 <20221106210716.1c997091ca40ea02ede9f159@dec.sakura.ne.jp>
 
In-Reply-To: 

--------------aaShFLVSlFdU6oOzxstdc0n8
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

ZXRjdXBkYXRlDQo9PT09PT09PT0NCg0KT24gMDYvMTEvMjAyMiAxNzozNSwgR2VvcmdlIE1p
Y2hhZWxzb24gd3JvdGU6DQoNCj4gSSBhbSBwcm9iYWJseSBhbG9uZSBpbiB0aGlzDQoNCllv
dSdyZSBub3QgYWxvbmUuDQoNCg0KPiDigKYgSSBmaW5kIHRoZSDigKYgPDw8PDwvPj4+Pj4N
Cj4gbWFya2VycyBpbiB0aGUgdXBkYXRlIGRpZmZzIGludGVuc2VseSBjb25mdXNpbmcuDQoN
CmRpZmYzIGJyYWNrZXRpbmcuDQoNCjw8PDw8PDwgaXMgd2hlcmUgYSBjb25mbGljdCBiZWdp
bnMsDQogPj4+Pj4+PiBpcyB3aGVyZSBpdCBlbmRzLg0KDQpCZXlvbmQgdGhhdCwgaXQgd2Fz
IGRpZmZpY3VsdCBmb3IgbWUgdG8gZmluZCBhbiBleHBsYW5hdGlvbiB0aGF0J3Mgc2ltcGxl
Lg0KDQpJbiB0aGUgbWlkc3Qgb2YgYSBsb25nIHBhZ2UgZnJvbSB0d2VudHktbmluZSB5ZWFy
cyBhZ286DQoNCjxodHRwOi8vd3d3LmhwY2MuZWNzLnNvdG9uLmFjLnVrL2hwY2kvdG9vbHMv
Y3ZzL2h0bWwvZGlmZi5odG1sI1NFQzUzPiANCmJlZ2lucyB3aXRoIHNpbXBsaWNpdHkuDQoN
CjxodHRwczovL2dpdGh1Yi5jb20vZnJlZWJzZC9mcmVlYnNkLXNyYy9jb21taXQvYTcyMTJl
NTcyMWJhZWIzMWViMTA0YzQ4MjljZGYyMGM1ODk2OTQ2Mz4gDQooMjAxNi0wOC0wNSkgcHV0
cyBkaWZmMygxKSBpbiB0aGUgY29udGV4dCBvZiBldGN1cGRhdGUoOCkuDQoNCjxodHRwczov
L3d3dy5mcmVlYnNkLm9yZy9jZ2kvbWFuLmNnaT9xdWVyeT1kaWZmMyZzZWt0aW9uPTEmbWFu
cGF0aD1GcmVlQlNEI1NFRV9BTFNPPiANCnN1Z2dlc3RzIGEgY29tbWFuZCB0aGF0IGhhcyBu
byBlZmZlY3Q6DQoNCiDCoMKgwqAgaW5mbyBkaWZmMw0KDQotLS0tDQoNCkZvciBwZW9wbGUg
d2hvIHByZWZlciBjb21wbGV4aXR5LCBmcm9tIHRoZSBvdXRzZXQsIHdoZW4gYXR0ZW1wdGlu
ZyB0byANCmdyYXNwIChvciByZW1lbWJlcikgc29tZXRoaW5nIHRoYXQncyBuZXcsIG9yIGNv
bXBsZXg6DQoNCjxodHRwczovL2Jsb2cuamNvZ2xhbi5jb20vMjAxNy8wNS8wOC9tZXJnaW5n
LXdpdGgtZGlmZjMvPg0KDQrigJMgdGhlIHRlYW0gaW5jbHVkZXMgQWxpY2UgYW5kIEJvYiBk
ZXZlbG9waW5nIGEgcmVjaXBlIGJvb2sgd2l0aCBhIHNvdXAgDQp3aXRoIHNpeCBpbmdyZWRp
ZW50cywgb25lIG9mIHdoaWNoIGlzIGEgY29tbW9uIGFsbGVyZ2VuIOKAkyBjZWxlcnksIA0K
Z2FybGljLCBvbmlvbnMsIHNhbG1vbiwgdG9tYXRvZXMsIHdpbmUg4oCTIHRoaW5ncyBnZXQg
Y2h1bmt5IHdoZW4gYm90aCANCkFsaWNlIGFuZCBCb2IgZGlmZmVyIGZyb20gdGhlIG9yaWdp
bmFsIGFuZCBuZWl0aGVyIEFkYW0gbm9yIEV2ZSBhcmUgDQplbWl0dGVkOyBhZGFwdGVkIGZy
b20gS2hhbm5hLCBTLiwgS3VuYWwsIEsuLCBQaWVyY2UsIEIuQy4gKDIwMDcpLiBBIA0KRm9y
bWFsIEludmVzdGlnYXRpb24gb2YgRGlmZjMuIEluOiBBcnZpbmQsIFYuLCBQcmFzYWQsIFMu
IChlZHMpIEZTVFRDUyANCjIwMDc6IEZvdW5kYXRpb25zIG9mIFNvZnR3YXJlIFRlY2hub2xv
Z3kgYW5kIFRoZW9yZXRpY2FsIENvbXB1dGVyIA0KU2NpZW5jZS4gRlNUVENTIDIwMDcuIExl
Y3R1cmUgTm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5jZSwgdm9sIDQ4NTUuIA0KU3ByaW5nZXIs
IEJlcmxpbiwgSGVpZGVsYmVyZy4gaHR0cHM6Ly9kb2kub3JnLzEwLjEwMDcvOTc4LTMtNTQw
LTc3MDUwLTNfNDANCg0KOi0pDQoNCg0KPiBHaXZlbiBtYW55IG1lcmdlcyBhcmUNCj4gbGFy
Z2UgYmxvY2tzLCBpdHMgYWxtb3N0IGltcG9zc2libGUgdG8ga2VlcCBjb250ZXh0IGZsaXR0
aW5nIGFib3V0IGluDQo+IHZpIOKApg0KDQo8aHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3Jn
L0QzNjc4Nj4NCg0KDQo+IFRMO0RSIHRoZSBtZXJnZSBwcm9jZXNzIGZvciBGcmVlQlNELXVw
ZGF0ZSBhbmQgbGlrZSwgY2FuIGJlIGludGVuc2VseQ0KPiBjb25mdXNpbmcgd2hlbiB5b3Ug
dHJ5IHRvIHJlY29uY2lsZSB3aGF0IGl0IHRlbGxzIHlvdSBhYm91dCAvZXRjLw0KPg0KPiAt
Rw0KPg0KPiBPbiBTdW4sIE5vdiA2LCAyMDIyIGF0IDEyOjA3IFBNIFRvbW9ha2kgQU9LSSA8
anVuY2hvb25AZGVjLnNha3VyYS5uZS5qcD4gd3JvdGU6DQo+IOKApg0K

--------------aaShFLVSlFdU6oOzxstdc0n8--

--------------v0VgYj9tJAMgGWDHm0TRLopS
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmNoiGcFAwAAAAAACgkQt2dIb0oY1AuA
fw//UuRIadxVwCDGBhvuMaGUIFGoqdoCrDr6HT16Ubtv9r+5W3CgthyVmpQ5Yx2WiOVS1adr1NQC
a8hJbv6nWDJpMHiGmR3J+VeLjLPEoqiNZyvhZ3T0nH4Mrr0v1SJIUtggDV5Uqn8M27fsM/Dm9ZHr
EbaCPGmFnhJASPcBNY+3ovam2BkEuwge6alj550wsm+53XzC492dnuT2XKBA/b3/BwD6LdH05Ol5
HLmNLE3Czu7GtOCYEXaJ7K552HSmWbxS1qRxK/fAHj3DlKh7if6I4I85mLsIoBARBLoKVTPpHGJ8
cuBabFaq5P5Wc3ITT0d7XLCj1QAfz5JxVEtUBRLPns9GCerqDozTn4HrJxFGQOQqPXTJ7ELbigAx
XhYkGgf3zRtOcbrVUM4QmLBAVFjLiKhiGz5ya/uNpvGlkq0zcOuCleCCAMRT8i3FlwHNtW/hl16O
I3WyPqWuMHIfB6A4SQ3neRHC+7g7UkjiV+u3jLuTj0R1hQ1GdYb4AwcSt7C5Lrc9j/pLIj/0mbm8
wyH+ztGQSZlNqhVuLmMS87X9Y5gMIMokabtLoYwDTmuSOYw+qsQ34xUx57mydEHha0nKKhmGvv1H
G/GWd6K5BjxX8VloVntFwnux7AP4tNiVT9MXpZYQ1bwMnyDHLzNuqBe7ownABBu/j8ysammNz7Tw
t+Y=
=YAwX
-----END PGP SIGNATURE-----

--------------v0VgYj9tJAMgGWDHm0TRLopS--

From nobody Mon Nov  7 04:46:06 2022
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 4N5JbN4Gtdz4gtN9
	for ; Mon,  7 Nov 2022 04:46:24 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4N5JbL65D0z4NmQ
	for ; Mon,  7 Nov 2022 04:46:22 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667796381; bh=T309y9MMcPKmjIUoW0HXDlyR4ZkwSD7fImlbt9leCSw=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=mx+eyPrgkMEsQ+t8L7hF24Ua/Yrn98zzXTccvZZzuZubmx6Js1FNEkguk5Bg8yckdp4ky4OJqj07tB/A1p2gLlFq5Us7S/bauFS/3kJ/ibPyf8VJQV3Z300Dlws4IzL88lZfiK6NcTDSYtddqikUg7AJS6Vju3Vm7O6GvSYugyiTaSXD0+x/HNXERli2uVxz+SVfJpOnw9JPxVhsmYeuLWaEmhp5Sub1/qXEV0NuDZd0HGyQwwA52lIC0xOAoq3a5pc+XppsK56xDCVGfmUviZzdphmUB0jylhRq9AstUY1+CJbAOQtGt/vImrGVCS4hVm77lDfCeAm3ivR7mQinVg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667796381; bh=m6BQErnkrdJiOj/wgAxmyCsaIy/iGwBDWV6WlqhReUJ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=RNc6G+F7EMOGzcKttOMpOTdsOGbxS7IuIfehOU8X5DDDdWC/vAIRYhIpAUiqBusGzjFewJVsZ/4OtMxsQsHAPVeyVSzjnPT+5j4Kr9Mxb/XNQymkHegAGopeNo2cHkMn9w7vJIJ4W5wvnB+EOaWuF45ON04Gmyk+mspkYfc9xp5QKZvkt6o+Njs+QV2XUaHlEQh4cobAPovrfwIV/kSIYlO1oCyZ+hY84HV2JBIs5MS0dq33zA0ybGxN7xlkPFspqnZyc12fEzkyul+RRSqndbpowKnGxbjJc6PwC2V1+5Mu/aGJZLD8XWwUYg7jkO730WaJFCUh1uPinA3yfbyihQ==
X-YMail-OSG: 0MJmW5kVM1km5D6aMAsTGebr6g8eskOmemHtIRFaExb.LsGBof7fv1KeyUG5GUm
 WXZfnC5djN_2kmjCarr8csvedF_OosQzr1F5DbjmD3BIWnWPz5T_.7Ky1Phb6Sb.YY_VtxWhxeEu
 61PoPR_Q6pD.3ohV8.D0zb5fwEmFp3bOeqPhJdxSM_8ZY6uvWPEZmEQhGchuHCrki1HtMC9LxikO
 cPFTSUwZGDM6PiYnfBHcimSD_YXcV1agS4EWr35XLjwLWryBFZnwPZefpbCnLT1VS71F.HT6Wn0r
 8x8NV7d3a.p04tE4._UUqIWegE8LCXSLtJZhM.Ri1gLlGtnz7p.JDhMl1SexSAuuncUj2jpKsOW3
 tI5CHhNu_F8OEQcRLB.fNSXh6mU4w1HT5M9SQml1ttTJuF9yjBIxa24H28vDk9__ha02lAeSZZMY
 5hsGViBDXRip_tCzt9ZCNpId_5qjWhNHLR1SCoEK_VTTqoPVzHb6Sq8uTFysmZS8Nf_P4Rw2ZPc9
 DLOdwf7jwYGMxJRLTj1SD.B32Cnwbecf5IvO1KKqfmhouXWGOzc326XHnF1gT5PmYutPoHqZQxOD
 aOWHox1qMF79XweuLoXbHnP8zw8ua.BtJwmmQ8WxpBsALXw9eYmi1cFJveIhsNjF6sg5zfjHo1DP
 eNpp38NdGGRCAlv.W02zEpAKqStDuWD7Am7fRUEexZrl7ZIsgKjE9Bfv3Qm0nS_eiFK6upOstYCz
 HL0tjrTkJ2wiW29EOdtZUpPZjUlhjf4JcIuULOFVrOT6y3yQMOWBiNY_dvUlAqATB5G7Hj4_BhLy
 NvlEMAosfAjShMg02ur4zX_VpEpOLqE4svd0s9zCcGfWMN9yRgvh7n7ypcxvrZT9GA1AKEy5IVxn
 _C6CJm_d8kEBfMuJBPbaLpVKgmWCU.q1VDiZ0MLP0CThPgloCZgxygDuQgcc9riIQ6BMp7bU_nsB
 edl7jBt5me.YttblRifx4mr0z7WZX9Y6rNyfipA7_aQhFe_OYyQoxAn12GxKlMOZAiUyYKSM_F.9
 S4Mhf9DzJPKYbfNteR7AuvHMopCDnoJnyzLPjFxZQeZnT7TpFJPNokp51YrgrJiKtXbQMCty6WTR
 vtu5.KPC3xA0f3WI7TKMdSvdpG8TBCyhqS0qD1ABk97iDk46o9dVyxKhzeMlWh0culq0Hl.P8ZEg
 VTugk7d6oLRAv4_i518M.JP.grpzz59mJrGr_48MzGPuPX3qGo3In8pdvYASWyy6xUz22JeAzn0z
 6fQqi0kWr.TSdfa7NUXBbCdpRrMoEGofC6OaWxgOCyedoiM2iLWLSM3FNAlokFNsAE5SlLFRoKYh
 3wceI0Xc.xJTygb76zpwt_oIPqw.UH0C_v2MEGHV0QC84B8sfD_kE4Ow0ccErZYpVFFKpQRbg8Tn
 CmfjCQQ.g8KpZumeInuPoKN4kCGjH6SUvcS3SUcj.BSmJChjj8eFXt_TvejwFufdWgYgNOL3QV59
 TTaFxHO5pWZ.IG.fUb0a676DpQff0Hekt.lPphzztsjUfjj2j6BdfFV_v1OM3tuhKoDFLVQeatqV
 Me0Af24rQiibNPCE6eLhq0uDudRGXC5xXYWlCQGTNU0Dnxbs5JJI3c4mRWEB4qMUyYMT968Ioacl
 ydYmWN.ja52Cb1Q.FMgqZirUg0_SPYTPV1W0A_Vuc1_2nQ95M1GR8JXvhdNFmK9PlvywSA38K3WY
 giiNGUmkavhM7FiYUUVZsgJ_OJwppA7C5qf42HoEsTYwguRK21y81Tx9ZXa7BmMFS0s0sL3XssaD
 01xw3YyeSZQBTHld..XT_x8A9WoKt3WTkoJ1O5msjGE_0Y02cdpfGr40.4Z782H0EnKI0nK61sr1
 WMajSYNIsSrsh2t0BHuk1zE0Qr2wHQioRCv3Du.rk9lZPDRGQ_5Etqx3USgZiX.1GxBVPpbKZuoD
 ujnwQOhGLTNUJY7JHmfmHuPBaG8D5phDsWD0iadbW42LIyrLLyuaOPe8Hsws4rZYQ7s6CBTBI5S3
 vTmHIVJvoraxvdP8.MfsQLuk5hEaaqDHREOG4CC7BoYbDO5B_OMD6EKa8eOGVQOUC3itGJB9u0di
 rxUbMJUbGLX3oKetFL604O0dFMC5ZI5xqDORXKKCYVvRWqwTsGEOUtzAl2w77mNA7.u.bgK0ZD26
 uLSZUrznEBAMcW8UBy5fEXX4ZeX6w9tNWDEok4FQMzlF2YYDwdN2lAOMoqXgce24mWFcR5wfLcca
 _Akyc_VqaY2ynjLv.8Tduv13MZDdpZOF6iVk6gvdrtl240CLBCHcb3UGBo71dTHeviwJ9nD4W
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Nov 2022 04:46:21 +0000
Received: by hermes--production-ne1-6bcfb7fb87-2hzbf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d420946141098baaed3cf27995795237;
          Mon, 07 Nov 2022 04:46:18 +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 \(3731.200.110.1.12\))
Subject: aarch64 main [so: 14] upgrade native boot message: "sh:
 /usr/libexec/hyperv/hyperv_vfattach: not found"
Message-Id: 
Date: Sun, 6 Nov 2022 20:46:06 -0800
To: freebsd-current ,
 freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: 
X-Rspamd-Queue-Id: 4N5JbL65D0z4NmQ
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=mx+eyPrg;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.97)[-0.969];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

The upgrade was to (long output line manually split for readability):

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #65
main-n259064-f83db6441a2f-dirty: Sun Nov  6 17:08:00 PST 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400073 1400073

This was a native FreeBSD boot on a HoneyComb, with hyperv not involved.

The sequencing of the message was:

. . .
Starting devd.
sh: /usr/libexec/hyperv/hyperv_vfattach: not found
Waiting 30s for the default route interface: ......(dpni0)
. . .

/usr/libexec/hyperv/ is empty:

# ls -Tla /usr/libexec/hyperv/
total 9
drwxr-xr-x   2 root  wheel   2 Apr  8 22:40:03 2021 .
drwxr-xr-x  10 root  wheel  68 Nov  6 20:31:00 2022 ..



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


From nobody Mon Nov  7 05:47:38 2022
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 4N5KyL6S4lz4h1tj
	for ; Mon,  7 Nov 2022 05:47:54 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5KyK1Rqcz3G1F
	for ; Mon,  7 Nov 2022 05:47:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667800071; bh=DfELz+aP2dtK2saus50P0XaMTTeNNjLCOkdF9urxVQs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=g8ADp3R9fvrIuOzSzA8CLXend7qwejwDKKH2BwWM3KlGRj3euWCfaypZRi0JJnELMCE/5KnWz2zohU3fMrjFxGLrxkAahBpJZFVzDt3SlFUIP+9y56mMgb/aHnjqKjxQ/Q1Ed6jHAit+XE0qFmiL89dNxhzyqF6+NJ0nSPJiXYgZwy1oNZLKDa4Orvvyjczvvm6eI+ek1263XlRgprDScqI1kcNHcmwiAS+JDcWMTNeV/m7hU+R2MfdYu5Dfj2MVtKJbd/p2s2uzho86XeXMsJ5XjOX51ZZ+9MeRD+JdU9jmFUpWgRfuWZ2aV0DSNuOhg20PsaJIyLPzHTD775OwUQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667800071; bh=f/QIfSk0kAdSUP1HlQlz5dkbL0k/mBzQbzL7KS65TMZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=okEYLu4UJ+uEWrcrH0Gw3sB7qBDuydpOYarqHW3MeXOqSokQ+5y1NYrUZACT4s9ENb3zLG5iYUbJ897fFOBRu9GyyNtaGyMZvhZGMIBC5Zn3u2yH18lzH0Q6dd8CvPw1xv69uLOfptsvJOjh2OIT/5j0dlEI6Pfe/582+uayf7Kbv+Pl1nKW55zJp0a997e2TgEpM2wfdppvyBhLEZzX2rE6EQtsRVdTvZwV9Q/uhc2gdzl/B2vDCRXIMWh0iHF35scKTged+aEiZHKElaafqmo0FwyORhId0U/+2KTvmdX2ylAGxWINbJRk0HUg0NGCxx6jRB21gXF+HdLuU+WIBQ==
X-YMail-OSG: lwzciOMVM1mhjK_FZ7rUcb_6CEGc.uSWD6JmmMDIHylzLY26OD0nM8sDVhthVtp
 cIfgtDOgMBr6yZKLg3S6SHoaysdS8E36mf7MT92yB7fLHVlAUw3Z9SkJ7tKCfqkcuIHW.pqSVbPg
 Pbrcro1VBBbhqbwBu66ZHBe_6Azg81q1_RA7Azod_E5CBw3hy7Skc4zvvruaFpkQ0BcBBNePNGQm
 JxWcnvZ.5d5kzgs8IDgArGiRVYM0Cma59WxaTPlHNC7rGzMxLwekGSiNi8_faS05.TvJ0M88PYYk
 b5dV3CfkgdYEHJiMzfBcpOSC_s1I0iRJ1OJKCJ6iK.DGVjzm8eDT_2Q3fLcEwPfZRZxyp1jeB2Yc
 NZherh0tZZPpXNS4irfq9fvGpd_uiIGeTy9mTjTY7mlgtGCjHrmtum_L5uTCFMuiv_DBZ.8R5bbx
 OS5QzOEaJ4y4RDrh.V1CCJ3N59sdLYG2kKOL3qtyxjeZq0p6lMAwjr0Q.810UghP4gK4sHRm2kak
 lasm9utnLuQu6X0SGfpBPbuuhGGQ9tSWQeMlGmDjaYYNd1XHQRoePP.LjPJaI0EKPuk8bx8RZZcg
 eYb6RaaPtFLhjuhj23G1bi9nwMkrV4EX8F_c6Lvf50n28rWZi2E3d6CuKMr82deMC52zMe1BCMP1
 yXY7iMQA6TOKQwYRwTtAWPX_uv7XlhDiQ4eOnh49VLN4HwXMKwmh3D4eOzCerxR6ZLWrVggPPma1
 NCkXKcL7slJ25uF0iKenWjfZ69zMqwpU04OQGxNsUahEP2gliW.9Yx_EIkfHtdS5Bw_eitbFCXf4
 Of3xM4.1tLKurfvxmoKQHQr5llcnbQnclDncISng0_QUw0vpWiBDZlzwqFxq7urY7HI6HInxj9m7
 M7dQbP0VN9gQK4Id4MLG_TUACv9W2ErznJEdwsOv7OCpLvD8E80GarQA8RUMcT8o4rz76llCf34.
 1vhPMBfarlTwoRO5ZVwxqm3nGQlnhsXE0ufLB6tZmpcZAVRwxJt_DmjGqLhfqDDQv9N9p2A0zQCj
 DVAbeV1MGZmr9RwdLCJQKhuJ.VjDjSxXZUJzRK6uMqEwDcGHOCMi5J.QS6ra7NAQvO5OaPw.MQCB
 TnVB_IXMjK9LZXrt7fxiKFXYDCBDNHmEr2cp2bxE4nO3K6nuLFL_zVCf.cPP90Vw1C.FhGOco1bR
 tnn8pFuF46dHoDV2e5uvxVEbIkZUPJuwmJ9BEVlQsoSDI6uz8cJ6_a.wm2BVA42uFtzbvdjUA2Kx
 75bg69NxhOCmq8bLHJhJAEanUeUzeEHf9BaO0omHMgRLeB3ShUiE9qRHa9PBV2wJshssLoZBtNZm
 4ZBjG_lw4Tsca2aQMet9eLJV8FxxWA3bOMetML9FWBYWhD8wn79sSIdoDLzWTgfQIs5DmTNriYu_
 swwRaIfxjySViBQ66L._cATzVKjmWyHc8tufHpvFPnngC8.NbrgekK8uE4DFPkSkIbfso8akyXLs
 51uAoHQRnuewLO89GnhVhoc9jiQRnxFiZAGqsyM44NqqQJYBsrIlUD.2P0yNYzrlF7AjeKFMhg4P
 lEF_9ZxgBYYkXVIZSyvmQBNXm8NQZFavMcQQmjNpsYu3_x0bmiKU8qDFhrRHs1ZPM9dSDscGPjAF
 V9EqajXYsyBZHex.Xq3fG_yTR.dz6aPqfQkuXMli5ZZvd9tUzKMaqdOlxZNhQnmWiLOtNii1VwB0
 MkpQh_rWyN41BvHGZsvvhmShMKIooUwWxyep.E87FCpJrFakiDUK8Ko_SgJX008BeQWvOWKE6.Zi
 Q23HqzOJSTKdogWnhuWLd6dfwkaF.XxmQ3_7P6yqEsftfzMwra64XiTvWJwOlSWgCV.CDPWonx47
 U9BTrTWAXgYHBaaUHclxvAgGaDT6uDJ3DmTlikzxyGJsnQfNscYWIFb8rjlZayLkG9OeEoIxvkBY
 .cvalpy39NAzN9H8HeCtMdvckyuEXFehsedXaFMfCtBrMT_lasJS0WdX.jVG0v0iJNY2HT45mcRH
 eeGc1K0twaid_drK5hGkx5sRi6zsmp3TKBSTnZnVZjLF_K0kNWwNVl6GlaM2yL.TMMK_0UJ_9M9N
 E2nZ3yl6Hnh3Z0JseCYs7VaFV5IUSsulAdfTuhy3BFBS666VZyRErLOx4cZlvswu2vQ9sTH2L.MU
 RGjFhrH1CuIp46FwQfFAAItR.gYLLX7TK4Qdcb2jYaaVO1NJzCFwN3T.jJH3ZTIYzxrbupsPkvId
 NGu6kpAgjomHXhiOfHsc1vPCpbWNLerQHeXXKUclC9YgTi_ZfLYVzmsZ4oCBK81h.9O_33a27S2o
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Nov 2022 05:47:51 +0000
Received: by hermes--production-bf1-5878955b5f-f7np2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 88e7308caa554a43cf8355c6fad28c9f;
          Mon, 07 Nov 2022 05:47:46 +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 \(3731.200.110.1.12\))
Subject: FYI: A main-n259064-f83db6441a2f-dirty non-reproducing crash of
 system clang
Message-Id: 
Date: Sun, 6 Nov 2022 21:47:38 -0800
To: freebsd-current ,
 freebsd-arm 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: 
X-Rspamd-Queue-Id: 4N5KyK1Rqcz3G1F
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=g8ADp3R9;
	dmarc=pass (policy=reject) header.from=yahoo.com;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]
X-ThisMailContainsUnwantedMimeParts: N

This is after having upgraded to and booted into (long output
line manually split for readability):

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #65
main-n259064-f83db6441a2f-dirty: Sun Nov  6 17:08:00 PST 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6=
4.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400073 1400073

I then started doing more builds and got the failure
indicated later. /var/log/messages and dmesg -a output
show no messages about the failure and no messages near
the time of the failure.

Unfortunately, the error did not reproduce via either:

A) The reproducer materials in /tmp/ .
or:
B) Restarting the build that failed.

Nor was a core file left behind to look at.

The system has been stable for a long time prior to this (hours,
days, weeks, months, . . .). The only new environmental thing
has been I've starting using dpni0 (via the new DPAA2 support)
instead of using an Ethernet dongle. This does not have a long
history yet but I had been using it since after my prior FreeBSD
update as well.

It was a -j16 buildworld that got the failure. The failure
messages look like:

. . .

PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and =
include the crash backtrace, preprocessed source, and associated run =
script.
Stack dump:
0. Program arguments: cc -O2 -pipe -fno-common -I. =
-I/usr/main-src/usr.sbin/config -DNDEBUG -g -gz=3Dzlib -std=3Dgnu99 =
-Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W =
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes =
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch =
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts =
-Wnested-externs -Wold-style-definition -Wno-pointer-sign =
-Wthread-safety -Wno-empty-body -Wno-string-plus-int =
-Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable =
-mcpu=3Dcortex-a53 -Qunused-arguments =
-I/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/leg=
acy/usr/include -c lang.c -o lang.o
. . .
#0 0x00000000038fa404 llvm::sys::PrintStackTrace(llvm::raw_ostream&, =
int) =
/usr/main-src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:1=
3
#1 0x00000000038f8720 llvm::sys::RunSignalHandlers() =
/usr/main-src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:98:18
#2 0x00000000038acb8c HandleCrash =
/usr/main-src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.c=
pp:79:5
#3 0x00000000038acb8c CrashRecoverySignalHandler(int) =
/usr/main-src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.c=
pp:392:51
#4 0x0000000089f2ba58 handle_signal =
/usr/main-src/lib/libthr/thread/thr_sig.c:0:3
cc: error: clang frontend command failed with exit code 139 (use -v to =
see invocation)
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git =
llvmorg-14.0.5-0-gc12386ae247c)
Target: aarch64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin
cc: note: diagnostic msg:  ********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
cc: note: diagnostic msg: /tmp/lang-0c2772.c
cc: note: diagnostic msg: /tmp/lang-0c2772.sh
cc: note: diagnostic msg: =20
********************
*** [lang.o] Error code 139

make[3]: stopped in /usr/main-src/usr.sbin/config
.ERROR_TARGET=3D'lang.o'
=
.ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm=
64.aarch64/tmp/obj-tools/usr.sbin/config/lang.o.meta'
.MAKE.LEVEL=3D'3'
MAKEFILE=3D''
.MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes =
verbose'
_ERROR_CMD=3D'cc  -O2 -pipe -fno-common -I. =
-I/usr/main-src/usr.sbin/config  -DNDEBUG  -g -gz=3Dzlib -std=3Dgnu99 =
-Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W =
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes =
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch =
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts =
-Wnested-externs -Wold-style-definition -Wno-pointer-sign =
-Wthread-safety -Wno-empty-body -Wno-string-plus-int =
-Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable  =
-mcpu=3Dcortex-a53 -Qunused-arguments    =
-I/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/leg=
acy/usr/include -c lang.c -o lang.o; ;'
.CURDIR=3D'/usr/main-src/usr.sbin/config'
.MAKE=3D'make'
=
.OBJDIR=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch6=
4/tmp/obj-tools/usr.sbin/config'
.TARGETS=3D'all'
DESTDIR=3D''
LD_LIBRARY_PATH=3D''
MACHINE=3D'arm64'
MACHINE_ARCH=3D'aarch64'
MAKEOBJDIRPREFIX=3D''
MAKESYSPATH=3D'/usr/main-src/share/mk'
MAKE_VERSION=3D'20220726'
=
PATH=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/t=
mp/legacy/usr/sbin:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6=
4.aarch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/mai=
n-src/arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA53-nodbg-clang/u=
sr/main-src/arm64.aarch64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr=
/bin'
SRCTOP=3D'/usr/main-src'
=
OBJTOP=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64=
/tmp/obj-tools'
.MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk =
/usr/main-src/share/mk/local.sys.env.mk =
/usr/main-src/share/mk/src.sys.env.mk =
/usr/home/root/src.configs/src.conf.CA53-nodbg-clang.aarch64-host =
/usr/main-src/share/mk/bsd.mkopt.mk =
/usr/main-src/share/mk/src.sys.obj.mk /usr/main-src/share/mk/auto.obj.mk =
/usr/main-src/share/mk/bsd.suffixes.mk =
/usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk =
/usr/main-src/share/mk/src.sys.mk /dev/null =
/usr/main-src/usr.sbin/config/Makefile =
/usr/main-src/tools/build/mk/bsd.prog.mk =
/usr/main-src/tools/build/mk/Makefile.boot.pre =
/usr/main-src/share/mk/bsd.prog.mk /usr/main-src/share/mk/bsd.init.mk =
/usr/main-src/share/mk/bsd.opts.mk /usr/main-src/share/mk/bsd.cpu.mk =
/usr/main-src/share/mk/local.init.mk /usr/main-src/share/mk/src.init.mk =
/usr/main-src/usr.sbin/config/../Makefile.inc =
/usr/main-src/share/mk/bsd.own.mk /usr/main-src/share/mk/bsd.compiler.mk =
/usr/main-src/share/mk/bsd.endian.mk =
/usr/main-src/share/mk/bsd.linker.mk =
/usr/main-src/share/mk/bsd.sanitizer.mk =
/usr/main-src/share/mk/bsd.libnames.mk =
/usr/main-src/share/mk/src.libnames.mk =
/usr/main-src/share/mk/src.opts.mk /usr/main-src/share/mk/bsd.nls.mk =
/usr/main-src/share/mk/bsd.confs.mk /usr/main-src/share/mk/bsd.files.mk =
/usr/main-src/share/mk/bsd.dirs.mk /usr/main-src/share/mk/bsd.incs.mk =
/usr/main-src/share/mk/bsd.links.mk /usr/main-src/share/mk/bsd.dep.mk =
/usr/main-src/share/mk/bsd.clang-analyze.mk =
/usr/main-src/share/mk/bsd.obj.mk /usr/main-src/share/mk/bsd.subdir.mk =
/usr/main-src/share/mk/bsd.sys.mk =
/usr/main-src/tools/build/mk/Makefile.boot'
.PATH=3D'. /usr/main-src/usr.sbin/config'
1 error

make[3]: stopped in /usr/main-src/usr.sbin/config
.ERROR_TARGET=3D'lang.o'
=
.ERROR_META_FILE=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm=
64.aarch64/tmp/obj-tools/usr.sbin/config/lang.o.meta'
.MAKE.LEVEL=3D'3'
MAKEFILE=3D''
.MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes =
verbose'
_ERROR_CMD=3D'cc  -O2 -pipe -fno-common -I. =
-I/usr/main-src/usr.sbin/config  -DNDEBUG  -g -gz=3Dzlib -std=3Dgnu99 =
-Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W =
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes =
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch =
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts =
-Wnested-externs -Wold-style-definition -Wno-pointer-sign =
-Wthread-safety -Wno-empty-body -Wno-string-plus-int =
-Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable  =
-mcpu=3Dcortex-a53 -Qunused-arguments    =
-I/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/tmp/leg=
acy/usr/include -c lang.c -o lang.o; ;'
.CURDIR=3D'/usr/main-src/usr.sbin/config'
.MAKE=3D'make'
=
.OBJDIR=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch6=
4/tmp/obj-tools/usr.sbin/config'
.TARGETS=3D'all'
DESTDIR=3D''
LD_LIBRARY_PATH=3D''
MACHINE=3D'arm64'
MACHINE_ARCH=3D'aarch64'
MAKEOBJDIRPREFIX=3D''
MAKESYSPATH=3D'/usr/main-src/share/mk'
MAKE_VERSION=3D'20220726'
=
PATH=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/t=
mp/legacy/usr/sbin:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6=
4.aarch64/tmp/legacy/usr/bin:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/mai=
n-src/arm64.aarch64/tmp/legacy/bin:/usr/obj/BUILDs/main-CA53-nodbg-clang/u=
sr/main-src/arm64.aarch64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr=
/bin'
SRCTOP=3D'/usr/main-src'
=
OBJTOP=3D'/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64=
/tmp/obj-tools'
.MAKE.MAKEFILES=3D'/usr/main-src/share/mk/sys.mk =
/usr/main-src/share/mk/local.sys.env.mk =
/usr/main-src/share/mk/src.sys.env.mk =
/usr/home/root/src.configs/src.conf.CA53-nodbg-clang.aarch64-host =
/usr/main-src/share/mk/bsd.mkopt.mk =
/usr/main-src/share/mk/src.sys.obj.mk /usr/main-src/share/mk/auto.obj.mk =
/usr/main-src/share/mk/bsd.suffixes.mk =
/usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk =
/usr/main-src/share/mk/src.sys.mk /dev/null =
/usr/main-src/usr.sbin/config/Makefile =
/usr/main-src/tools/build/mk/bsd.prog.mk =
/usr/main-src/tools/build/mk/Makefile.boot.pre =
/usr/main-src/share/mk/bsd.prog.mk /usr/main-src/share/mk/bsd.init.mk =
/usr/main-src/share/mk/bsd.opts.mk /usr/main-src/share/mk/bsd.cpu.mk =
/usr/main-src/share/mk/local.init.mk /usr/main-src/share/mk/src.init.mk =
/usr/main-src/usr.sbin/config/../Makefile.inc =
/usr/main-src/share/mk/bsd.own.mk /usr/main-src/share/mk/bsd.compiler.mk =
/usr/main-src/share/mk/bsd.endian.mk =
/usr/main-src/share/mk/bsd.linker.mk =
/usr/main-src/share/mk/bsd.sanitizer.mk =
/usr/main-src/share/mk/bsd.libnames.mk =
/usr/main-src/share/mk/src.libnames.mk =
/usr/main-src/share/mk/src.opts.mk /usr/main-src/share/mk/bsd.nls.mk =
/usr/main-src/share/mk/bsd.confs.mk /usr/main-src/share/mk/bsd.files.mk =
/usr/main-src/share/mk/bsd.dirs.mk /usr/main-src/share/mk/bsd.incs.mk =
/usr/main-src/share/mk/bsd.links.mk /usr/main-src/share/mk/bsd.dep.mk =
/usr/main-src/share/mk/bsd.clang-analyze.mk =
/usr/main-src/share/mk/bsd.obj.mk /usr/main-src/share/mk/bsd.subdir.mk =
/usr/main-src/share/mk/bsd.sys.mk =
/usr/main-src/tools/build/mk/Makefile.boot'
.PATH=3D'. /usr/main-src/usr.sbin/config'

make[2]: stopped in /usr/main-src

make[2]: stopped in /usr/main-src

make[2]: stopped in /usr/main-src
        6.42 real        26.37 user         5.47 sys

make[1]: stopped in /usr/main-src

make: stopped in /usr/main-src




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


From nobody Mon Nov  7 10:51:11 2022
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 4N5ShQ4RpZz4gfQ7
	for ; Mon,  7 Nov 2022 10:51:18 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5ShN68nyz4KKQ;
	Mon,  7 Nov 2022 10:51:15 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2A7ApBkc005769;
	Mon, 7 Nov 2022 19:51:12 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Mon, 7 Nov 2022 19:51:11 +0900
From: Tomoaki AOKI 
To: Graham Perrin 
Cc: freebsd-current@freebsd.org
Subject: Re: linsysfs on /usr/src/sys (linsysfs, local)
Message-Id: <20221107195111.78a575dc7769531e040dbcb4@dec.sakura.ne.jp>
In-Reply-To: <8e3e8a1f-495e-6c53-7450-5e22e6b50025@freebsd.org>
References: <3e925370-3f09-101d-e4f3-5fa2c7f28c83@freebsd.org>
	<8e3e8a1f-495e-6c53-7450-5e22e6b50025@freebsd.org>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4N5ShN68nyz4KKQ
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp
X-Spamd-Result: default: False [-1.60 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[sakura.ne.jp];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 7 Nov 2022 03:03:25 +0000
Graham Perrin  wrote:

> On 29/10/2022 21:30, Graham Perrin wrote:
> 
> > Subject: poudriere jail update from source: syscall.mk does not exist
> 
> > After updating to yesterday's 
> > aba921bd9e1869dae9ae4cc6e0c048f997401034, I aimed for a routine update 
> > of the jail that I used for poudriere.
> >
> >
> > poudriere jail -u -J 1 -j main
> > …
> > ===> lib/libc (install)
> > make[5]: "/usr/src/lib/libc/sys/Makefile.inc" line 9: Cannot open 
> > /usr/src/sys/sys/syscall.mk
> > make[5]: Fatal errors encountered -- cannot continue
> > make[5]: stopped in /usr/src/lib/libc
> > *** Error code 1
> > …
> 
> 
> bdrewery and others in IRC helped me to realise an offending mount.
> 
> 
> With linux_enable: YES,
> 
> root@mowa219-gjp4-8570p-freebsd:~ # mount | grep sys
> linsysfs on /usr/src/sys (linsysfs, local)
> root@mowa219-gjp4-8570p-freebsd:~ # exit
> logout
> % grep linsysfs /etc/fstab
> # linsysfs      /compat/linux/sys       linsysfs 
> rw                         0     0
> # linsysfs        /compat/ubuntu/sys      linsysfs 
> rw,late                    0     0
> %
> 
> 
> After linux_enable: NO and a reboot,
> 
> % sysrc -f /etc/rc.conf linux_enable
> linux_enable: NO
> % mount | grep sys
> % date ; uname -aKU
> Wed 2 Nov 2022 19:06:01 GMT
> FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #24 
> main-n258900-aba921bd9e18: Sat Oct 29 14:39:59 BST 2022 
> grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
> amd64 1400073 1400073
> % sudo service linux onestart
> grahamperrin's password:
> kldload: an error occurred while loading module linux. Please check 
> dmesg(8) for more details.
> /etc/rc.d/linux: WARNING: Unable to load kernel module linux
> kldload: an error occurred while loading module linux64. Please check 
> dmesg(8) for more details.
> /etc/rc.d/linux: WARNING: Unable to load kernel module linux64
> % mount | grep sys
> linsysfs on /compat/linux/sys (linsysfs, local)
> % sudo sysrc linux_enable="YES"
> linux_enable: NO -> YES
> %
> 
> 
> With linux_enable: YES (re-enabled) and a reboot, the clobber of 
> /usr/src/sys recurred.

Possibly because there is a symlink /sys pointing to /usr/sys?
The symlink is there historically, but already doesn't appear on
`man hier` or /etc/mtree/.

I finally found the revision 2878 at Mon Sep 19 01:40:40 1994 UTC [1]
stopped creating the symlink automatically using /etc/mtree/.

If the installation is old, kept-on-updating one, it would be time to
delete the symlink.


[1]
https://cgit.freebsd.org/src/commit/etc/mtree/BSD.root.dist?id=c27b58e1b62e792e35a27bc5fd261e04293b076e

> 
> ----
> 
> Resolved through an OS update on 3rd November:
> 
> % uname -aKU
> FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #25 
> main-n259004-2c10be9e06d4: Thu Nov  3 00:14:52 GMT 2022 
> grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
> amd64 1400073 1400073
> 


-- 
Tomoaki AOKI    

From nobody Mon Nov  7 11:01:54 2022
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 4N5Sws0Shtz4ggmW
	for ; Mon,  7 Nov 2022 11:02:05 +0000 (UTC)
	(envelope-from dchagin@heemeyer.club)
Received: from heemeyer.club (heemeyer.club [195.93.173.158])
	(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 4N5Swq5xHrz3sWh;
	Mon,  7 Nov 2022 11:02:03 +0000 (UTC)
	(envelope-from dchagin@heemeyer.club)
Received: from heemeyer.club (localhost [127.0.0.1])
	by heemeyer.club (8.17.1/8.16.1) with ESMTP id 2A7B1tWZ001472;
	Mon, 7 Nov 2022 14:01:55 +0300 (MSK)
	(envelope-from dchagin@heemeyer.club)
Received: (from dchagin@localhost)
	by heemeyer.club (8.17.1/8.16.1/Submit) id 2A7B1s9g001471;
	Mon, 7 Nov 2022 14:01:54 +0300 (MSK)
	(envelope-from dchagin)
Date: Mon, 7 Nov 2022 14:01:54 +0300
From: Dmitry Chagin 
To: Graham Perrin 
Cc: freebsd-current@freebsd.org
Subject: Re: linsysfs on /usr/src/sys (linsysfs, local)
Message-ID: 
References: <3e925370-3f09-101d-e4f3-5fa2c7f28c83@freebsd.org>
 <8e3e8a1f-495e-6c53-7450-5e22e6b50025@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=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8e3e8a1f-495e-6c53-7450-5e22e6b50025@freebsd.org>
X-Rspamd-Queue-Id: 4N5Swq5xHrz3sWh
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=none (mx1.freebsd.org: domain of dchagin@heemeyer.club has no SPF policy when checking 195.93.173.158) smtp.mailfrom=dchagin@heemeyer.club
X-Spamd-Result: default: False [-2.09 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.995];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:61400, ipnet:195.93.173.0/24, country:RU];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[heemeyer.club];
	FREEFALL_USER(0.00)[dchagin];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Nov 07, 2022 at 03:03:25AM +0000, Graham Perrin wrote:
> On 29/10/2022 21:30, Graham Perrin wrote:
> 
> > Subject: poudriere jail update from source: syscall.mk does not exist
> 
> > After updating to yesterday's 
> > aba921bd9e1869dae9ae4cc6e0c048f997401034, I aimed for a routine update 
> > of the jail that I used for poudriere.
> >
> >
> > poudriere jail -u -J 1 -j main
> > …
> > ===> lib/libc (install)
> > make[5]: "/usr/src/lib/libc/sys/Makefile.inc" line 9: Cannot open 
> > /usr/src/sys/sys/syscall.mk
> > make[5]: Fatal errors encountered -- cannot continue
> > make[5]: stopped in /usr/src/lib/libc
> > *** Error code 1
> > …
> 
> 
> bdrewery and others in IRC helped me to realise an offending mount.
> 
> 
> With linux_enable: YES,
> 
> root@mowa219-gjp4-8570p-freebsd:~ # mount | grep sys
> linsysfs on /usr/src/sys (linsysfs, local)
> root@mowa219-gjp4-8570p-freebsd:~ # exit
> logout
> % grep linsysfs /etc/fstab
> # linsysfs      /compat/linux/sys       linsysfs 
> rw                         0     0
> # linsysfs        /compat/ubuntu/sys      linsysfs 
> rw,late                    0     0
> %
> 
> 
> After linux_enable: NO and a reboot,
> 
> % sysrc -f /etc/rc.conf linux_enable
> linux_enable: NO
> % mount | grep sys
> % date ; uname -aKU
> Wed 2 Nov 2022 19:06:01 GMT
> FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #24 
> main-n258900-aba921bd9e18: Sat Oct 29 14:39:59 BST 2022 
> grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
> amd64 1400073 1400073
> % sudo service linux onestart
> grahamperrin's password:
> kldload: an error occurred while loading module linux. Please check 
> dmesg(8) for more details.
> /etc/rc.d/linux: WARNING: Unable to load kernel module linux
> kldload: an error occurred while loading module linux64. Please check 
> dmesg(8) for more details.
> /etc/rc.d/linux: WARNING: Unable to load kernel module linux64
> % mount | grep sys
> linsysfs on /compat/linux/sys (linsysfs, local)


assume linux_common failsed to load, as for now Linuxulator depends on
netlink module on -current.



> % sudo sysrc linux_enable="YES"
> linux_enable: NO -> YES
> %
> 
> 
> With linux_enable: YES (re-enabled) and a reboot, the clobber of 
> /usr/src/sys recurred.
> 
> ----
> 
> Resolved through an OS update on 3rd November:
> 
> % uname -aKU
> FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #25 
> main-n259004-2c10be9e06d4: Thu Nov  3 00:14:52 GMT 2022 
> grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
> amd64 1400073 1400073
> 




From nobody Mon Nov  7 15:21:05 2022
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 4N5Zgn3qt7z4hD8W
	for ; Mon,  7 Nov 2022 15:21:09 +0000 (UTC)
	(envelope-from l.m.v.breda@xs4all.nl)
Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5Zgl5tMrz3nNc
	for ; Mon,  7 Nov 2022 15:21:07 +0000 (UTC)
	(envelope-from l.m.v.breda@xs4all.nl)
X-KPN-MessageId: c7f5fd06-5eaf-11ed-8a67-005056ab378f
Received: from smtp.kpnmail.nl (unknown [10.31.155.37])
	by ewsoutbound.so.kpn.org (Halon) with ESMTPS
	id c7f5fd06-5eaf-11ed-8a67-005056ab378f;
	Mon, 07 Nov 2022 16:20:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=xs4all.nl; s=xs4all01;
	h=content-type:mime-version:message-id:date:subject:to:from;
	bh=N/frKrA5fynA/x/W+IucJ9VTf1EwJG8BYtKaBCSvDjA=;
	b=M0YGx4jWQ64buUZOqArHknZucEa3+82Pdv27iIs5VpmceZynmLuQHdnekZwO+BBeyI8Sqm936RtMA
	 ko7FEZGfpfXBTfUIQ1MC2soxeSCiyR9MpVVUu+pUs3eOWje/ca0MeF7Fk3TkE8eV9WUVUNgAxOEMmD
	 fM3Rzj+YKvfry/SKOh/8zjY+9sdrxBIOZ640LwQZK3YvIeVHEZWgVh/X9Ge4Qffyl95IB2OjkGDHA5
	 v5hcGeZePTlgrdp/GDkutEh/LVeLuz1IhTqNsOivPem+BxTA1p15ByxBLpNBi2as7yHVF0cVGx2ozv
	 332yg3TwGZnz3w7MbnvILvcK/4Bz1yA==
X-KPN-MID: 33|dlkGcfBDkbgDbfIrkxHqEL8zsQnGdLdwmL7MvyUMVKl15ceNbTI9Pua6ZpsqMxR
 x74wVguKshNcxzPMQVC2LFPpTjszqnxE7JclAwo39TVI=
X-KPN-VerifiedSender: Yes
X-CMASSUN: 33|g+9f9X5k5WlT48qkHEuC6nSOKc0T3YGngdNNt6kAwbkdyLJ+YSvBoNp4xr7hoNS
 +QwGlF5Dexh8OKzxxKN9C1Q==
X-Originating-IP: 77.174.182.228
Received: from MAIN (77-174-182-228.fixed.kpn.net [77.174.182.228])
	by smtp.xs4all.nl (Halon) with ESMTPSA
	id cc1db73a-5eaf-11ed-929c-005056ab1411;
	Mon, 07 Nov 2022 16:21:05 +0100 (CET)
From: 
To: 
Subject: Trying to compile theNVIDIA driver ........  however no ^bsd.sysdir.mk^ 
Date: Mon, 7 Nov 2022 16:21:05 +0100
Message-ID: <001c01d8f2bc$8dc96870$a95c3950$@xs4all.nl>
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="----=_NextPart_000_001D_01D8F2C4.EF8E6CB0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: nl
Thread-Index: AdjyvFdhcno8EJUpRo+T115VkYgZ/Q==
X-Rspamd-Queue-Id: 4N5Zgl5tMrz3nNc
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=xs4all.nl header.s=xs4all01 header.b=M0YGx4jW;
	dmarc=pass (policy=none) header.from=xs4all.nl;
	spf=pass (mx1.freebsd.org: domain of l.m.v.breda@xs4all.nl designates 195.121.94.170 as permitted sender) smtp.mailfrom=l.m.v.breda@xs4all.nl
X-Spamd-Result: default: False [-3.09 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_LONG(-0.79)[-0.790];
	SUBJECT_ENDS_SPACES(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[xs4all.nl,none];
	FORGED_SENDER(0.30)[louis.freebsd@xs4all.nl,l.m.v.breda@xs4all.nl];
	R_DKIM_ALLOW(-0.20)[xs4all.nl:s=xs4all01];
	R_SPF_ALLOW(-0.20)[+ip4:195.121.94.170/32];
	RCVD_IN_DNSWL_LOW(-0.10)[195.121.94.170:from];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	FROM_NO_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[xs4all.nl:dkim];
	ASN(0.00)[asn:8737, ipnet:195.121.64.0/18, country:NL];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[xs4all.nl];
	HAS_XOIP(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[louis.freebsd@xs4all.nl,l.m.v.breda@xs4all.nl];
	RCVD_COUNT_THREE(0.00)[3];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	DKIM_TRACE(0.00)[xs4all.nl:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_ENVFROM(0.00)[xs4all.nl];
	RCVD_TLS_ALL(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

This is a multipart message in MIME format.

------=_NextPart_000_001D_01D8F2C4.EF8E6CB0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

As the title is allready tells, I try to compile and install a NVIDIA =
driver for my 960 video card.=20

 =EF=BF=BD

So I downloaded the driver from the NVIDIA site and tried to compile. =
That =E2=80=A6 does not work

 =EF=BF=BD

Below the messages I get. It seems that the makefile expects =
bsd.sysdir.mk, which is not there

(I verified)

 =EF=BF=BD

How to fix this!?

How to setup the nvidia driver for FreeBSD 14 current?=20

 =EF=BF=BD

Below the error messages.

 =EF=BF=BD

Louis

 =EF=BF=BD

 =EF=BF=BD

[root@mysys /usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76]# make =
install clean

=3D=3D=3D> src (install)

=3D=3D=3D> src/nvidia (install)

make[2]: "/usr/share/mk/bsd.sysdir.mk" line 15: Unable to locate the =
kernel source tree. Set SYSDIR to override.

 =EF=BF=BD

make[2]: stopped in =
/usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76/src/nvidia

*** Error code 1

 =EF=BF=BD

Stop.

make[1]: stopped in =
/usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76/src

*** Error code 1

 =EF=BF=BD

Stop.

make: stopped in /usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76

[root@mysys /usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76]#


------=_NextPart_000_001D_01D8F2C4.EF8E6CB0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


As the =
title is allready tells, I try to compile and install a NVIDIA driver =
for my 960 video card. 
 
So I downloaded the driver from the NVIDIA site and tried =
to compile. That =E2=80=A6 does not work
 
Below the messages I get. It seems =
that the makefile expects bsd.sysdir.mk, which is not =
there
(I =
verified)
 
How to fix this!?
How to setup the nvidia driver for =
FreeBSD 14 current? 
 
Below the error messages.
 
Louis
 
 
 [root@mysys =
/usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76]# make install =
clean
=3D=3D=3D> src (install)
=3D=3D=3D> src/nvidia =
(install)
make[2]: "/usr/share/mk/bsd.sysdir.mk" line 15: =
Unable to locate the kernel source tree. Set SYSDIR to =
override.
 
make[2]: stopped in =
/usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76/src/nvidia=

*** Error code =
1
 
Stop.
make[1]: stopped in =
/usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76/src=

*** Error code =
1
 
Stop.
make: stopped in =
/usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76
=

[root@mysys =
/usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76]#

------=_NextPart_000_001D_01D8F2C4.EF8E6CB0--


From nobody Mon Nov  7 15:33:51 2022
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 4N5ZyY5D5zz4hFn2
	for ; Mon,  7 Nov 2022 15:33:57 +0000 (UTC)
	(envelope-from zirias@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5ZyY4Ctlz3QTT
	for ; Mon,  7 Nov 2022 15:33:57 +0000 (UTC)
	(envelope-from zirias@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1667835237;
	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=iD1eoSUb3shNX2wJkdz03Zh9Glp1K6Ormz9nFY2uLfk=;
	b=A4AESC9Cad264SGct+5WRDm+xfq+kNTeZStZC1sJzeBg/B+5kCWobPKoqH3Sevh9Y6pl0M
	CHJKsmkhx0k9ueQaGE3Aby5847+JfGLHcA2BG8UiUH5AyfdU+vcdugFM6EDIWnZQbAdCDU
	MaKr29ujhvH5zytpLT/CJuSqZLDQmus+SEceNlYTwo9+ca/8KfHjpd06BJVPsqXA6XvW5V
	aAoMrghGXI9d3MIUffjUG8SDPUa1dvu8g6CU5ImNLXv4ZxeTFLqsDpJpQaJ771YZw4BNq3
	z86Snu7AIy1AMhlg+eVseC5BZ6mLtyfrO/0N83kdarreLcuTxENmvYtqLQ/FEA==
Received: from stef.palmen-it.de (stef.palmen-it.de [IPv6:2001:470:1f0b:bbb:1::1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	(Authenticated sender: zirias/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N5ZyY38HbzWqy
	for ; Mon,  7 Nov 2022 15:33:57 +0000 (UTC)
	(envelope-from zirias@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=palmen-it.de; s=20200414; h=In-Reply-To:Content-Type:MIME-Version:
	References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:
	Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:
	Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:
	List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=iD1eoSUb3shNX2wJkdz03Zh9Glp1K6Ormz9nFY2uLfk=; b=BO0lKc0k63tZdtdWIiTRlIO/Zw
	qjBEkUtdtn6pKWDBzZOJv21lIulxwRLiV/Q/zXZ0ld22eahcO5JTDcherOCY2BEzWigyFh0Xa5psP
	bMSTIAl96gYKmKmq23AdGsraFwfEIqYc6A0zEBrrSPb+OAnOoB/4DNCQbrfOmKYJbuxmGB1/VxvR7
	vb1tcCCNxhXwAuFkHe8XuhlXm2Mp05bnMOgpluqyfjZsEFAAVHZ+h3I99QjfobzSZ2q1yP6B9kWdV
	ZJwaXtSy48us+hBIy4jUfFraIP66+17aA5bshRkIyBa0JTjE5TAIUeJ0Q6YMJbHouIpYpKJIrcRx+
	x+vzaycw==;
Received: from [192.168.71.101] (helo=mail.home.palmen-it.de)
	by stef.palmen-it.de with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from )
	id 1os48J-007Q0j-GX
	for freebsd-current@freebsd.org; Mon, 07 Nov 2022 16:33:55 +0100
Received: from nexus.home.palmen-it.de ([192.168.99.2])
	by mail.home.palmen-it.de with esmtpsa  (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1os48H-0001mY-LY
	for freebsd-current@freebsd.org;
	Mon, 07 Nov 2022 15:33:54 +0000
Date: Mon, 7 Nov 2022 16:33:51 +0100
From: Felix Palmen 
To: freebsd-current@freebsd.org
Subject: Re: Trying to compile theNVIDIA driver ........  however no
 ^bsd.sysdir.mk^
Message-ID: <20221107153351.ytcp6izukl6pxtqb@nexus.home.palmen-it.de>
Mail-Followup-To: freebsd-current@freebsd.org
X-Face: /1K@t"h.}e~pR@]c7HorQ!T`F^RJCa'BCr#e>IKA{>C/9OTGB4|xh"y2{?1Z5M
 i2w"AH^pN_LlHR^{+f',_Np~;.B;!M/bL}*qk]p5*r7F5vW};{:@4u5S?T&f0$7BJ-71Q5SV]:v$`5
 A0[DZ:=?S52x8HJ~5@^P_\T@MsjG{R(
Organization: FreeBSD.org
References: <001c01d8f2bc$8dc96870$a95c3950$@xs4all.nl>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="afjst5j2s625nswi"
Content-Disposition: inline
In-Reply-To: <001c01d8f2bc$8dc96870$a95c3950$@xs4all.nl>
User-Agent: NeoMutt/20220429
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1667835237;
	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:dkim-signature;
	bh=iD1eoSUb3shNX2wJkdz03Zh9Glp1K6Ormz9nFY2uLfk=;
	b=ShSq5pZLIMUSxQM9KPM1yqzwL9h1CEho9wXgLHpJ3mEL1q5ruA5V9/EUs2MXbSKBgpAhEr
	6Azf3AWUe08sc2TZdH1ksKt1Bs4fWl3Av31QHDI/jCfdpwIoI8thBI6g9oycpmQ5fQf8B8
	rb+vPjEFkA+m6BrEC1bd3Z+St2RSyZBKOQig0D8jVRUXxx/DV1POU3jwAYq8cVS5tFtUdy
	poZKojTYP0o7PomszIH7t4e144J/NyRLaRAPX9Y2RHUJhTcBYkdtTi4Ii4lzWyeg/PbooI
	UZG9ANow//2T2pcUJ9lm+HPe//vlh3eTqX/yd0Y7zkkdOsaWZT3Of3hSvC/5Ag==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667835237; a=rsa-sha256; cv=none;
	b=AUoJEmB1YRoIfoiJdTtGEgiNgttb4cgAnxarRbJplKpAI/gsExvw+nsWQdRosKmwaWdayB
	FJ/k6dHk6Exi9boZKM7GHrt4RxuE6gH/j1oSyXkYP+KU4Gzm6cDO+Zun6q1ontht9TnCdC
	RVLbXluvQnCHhLt9ClE8MwGYPriPMmwBX9TiwUmhgDB+66L5FUuOvCBDLYvCNN7JZ7n2z0
	BNyaPU4mZHwb8etJtGunZcFaXiUiMJadR41W0gG3LQq20qomoxKyVl7uzQtQDe8zPy8Mok
	iAp77bH8lWbO4akiV+lz1grKfEgub/IBrHmJMhT2eZ6ibvyY09F+atpc/Q3CHQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
X-ThisMailContainsUnwantedMimeParts: N


--afjst5j2s625nswi
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* louis.freebsd@xs4all.nl  [20221107 16:21]:
> So I downloaded the driver from the NVIDIA site and tried to compile. Tha=
t =E2=80=A6 does not work
>=20
> How to fix this!?

Use the port: https://www.freshports.org/x11/nvidia-driver/

--=20
 Felix Palmen      {private}   felix@palmen-it.de
 -- ports committer (mentee) --            {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231

--afjst5j2s625nswi
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEABYKAH0WIQRpNhPVW79IN7ISOsxUreAGmHnyMQUCY2klTV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0Njkz
NjEzRDU1QkJGNDgzN0IyMTIzQUNDNTRBREUwMDY5ODc5RjIzMQAKCRBUreAGmHny
MaXyAP9FxjIzljIYGIbYoSTRj2wdh5bQy6pAJiK6rjYhtvALsgD7BOcT1ckqJaiq
J38AUWaHcP0K1vp1N4dnJ2gDaKa+uw4=
=VzzU
-----END PGP SIGNATURE-----

--afjst5j2s625nswi--

From nobody Mon Nov  7 16:26:43 2022
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 4N5c7l65LJz4hLbc
	for ; Mon,  7 Nov 2022 16:26:59 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5c7l2qWpz4btC
	for ; Mon,  7 Nov 2022 16:26:59 +0000 (UTC)
	(envelope-from 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 2A7GQiUu042491;
	Mon, 7 Nov 2022 08:26:55 -0800 (PST)
	(envelope-from bsd-lists@bsdforge.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
Date: Mon, 07 Nov 2022 08:26:43 -0800
From: Chris 
To: louis.freebsd@xs4all.nl
Cc: freebsd-current@freebsd.org
Subject: Re: Trying to compile theNVIDIA driver ........  however no
 ^bsd.sysdir.mk^
In-Reply-To: <001c01d8f2bc$8dc96870$a95c3950$@xs4all.nl>
References: <001c01d8f2bc$8dc96870$a95c3950$@xs4all.nl>
User-Agent: UDNSMS/17.0
Message-ID: 
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_e40b5fce6bffd35f791a64896db5c09d"
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Rspamd-Queue-Id: 4N5c7l2qWpz4btC
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-Spamd-Result: default: False [0.00 / 15.00];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	local_wl_ip(0.00)[24.113.41.81]
X-ThisMailContainsUnwantedMimeParts: N

--=_e40b5fce6bffd35f791a64896db5c09d
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed

On 2022-11-07 07:21, louis.freebsd@xs4all.nl wrote:
> As the title is allready tells, I try to compile and install a NVIDIA driver 
> for
> my 960 video card.
> 
> So I downloaded the driver from the NVIDIA site and tried to compile. That … 
> does not work
> 
> 
> Below the messages I get. It seems that the makefile expects bsd.sysdir.mk, 
> which
> is not there
> 
> (I verified)
> 
> How to fix this!?
> 
> 
> Below the error messages.
> 
> Louis
> 
> make[2]: "/usr/share/mk/bsd.sysdir.mk" line 15: Unable to locate the kernel 
> source
> tree. Set SYSDIR to override.
> 
This message is trying to tell you that there is nothing in your /usr/src
It needs (at least) headers from the version of source of the system you're 
running.

HTH

--chris
> 
> make: stopped in /usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76
> 
> [root@mysys /usr/myshare/NV_driver/NVIDIA-FreeBSD-x86_64-515.76]#

--=_e40b5fce6bffd35f791a64896db5c09d
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_e40b5fce6bffd35f791a64896db5c09d--

From nobody Mon Nov  7 23:53:01 2022
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 4N5p2b2chsz4gln8
	for ; Mon,  7 Nov 2022 23:53:11 +0000 (UTC)
	(envelope-from dan@sunsaturn.com)
Received: from sunsaturn.com (sunsaturn.com [IPv6:2604:4300:a:196::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 (2048 bits) client-digest SHA256)
	(Client CN "sunsaturn.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5p2Y2yQgz64Mj
	for ; Mon,  7 Nov 2022 23:53:09 +0000 (UTC)
	(envelope-from dan@sunsaturn.com)
Received: by sunsaturn.com (Postfix, from userid 1001)
	id 46612684CD; Mon,  7 Nov 2022 17:53:01 -0600 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunsaturn.com;
	s=default; t=1667865181;
	bh=ZDE9/tCnrgmMu+z1J89mvmSsYkIhtsPlN6kbJldW/N4=;
	h=Date:From:To:Subject;
	b=WUh8W8eVUeiA0vOCwjHbGT5McQ4uUyZ8TZWawK4zkzUSxIsgZgapwGIamlEBv8iax
	 GFD5KnwTnkrBBKRdX4c7vU1IgYbhXhQRa76waqhYFTe3ynjAJQVbSNBbbraLPJc29o
	 a0uaiwypCvHP4mOiQEVZ4r7YJOKg3hzYew+W70G8=
Received: from localhost (localhost [127.0.0.1])
	by sunsaturn.com (Postfix) with ESMTP id 44336684DE
	for ; Mon,  7 Nov 2022 17:53:01 -0600 (CST)
Date: Mon, 7 Nov 2022 17:53:01 -0600 (CST)
From: Dan The Man 
To: freebsd-current@FreeBSD.org
Subject: vfs.zfs.vol.recursive hang makes it impossible to mount zvol
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; format=flowed
X-Rspamd-Queue-Id: 4N5p2Y2yQgz64Mj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=sunsaturn.com header.s=default header.b=WUh8W8eV;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of dan@sunsaturn.com designates 2604:4300:a:196::3 as permitted sender) smtp.mailfrom=dan@sunsaturn.com
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[sunsaturn.com:s=default];
	R_SPF_ALLOW(-0.20)[+ip6:2604:4300:a:196::3];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	DKIM_TRACE(0.00)[sunsaturn.com:+];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[sunsaturn.com: no valid DMARC record];
	RCPT_COUNT_ONE(0.00)[1];
	ASN(0.00)[asn:33387, ipnet:2604:4300::/32, country:US];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[dan];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N


router:~ # uname -a
FreeBSD router.sunsaturn.com 14.0-CURRENT FreeBSD 14.0-CURRENT #1 
main-n259058-105019e0d6c: Sat Nov  5 05:37:28 CDT 2022 
dan@router.sunsaturn.com:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64
router:~ # zfs create -V30G -o volmode=full zroot/asterisk2
(install a ZFS guest on it and call zroot testing)
router:~ # gpart show /dev/zvol/zroot/asterisk2
=>      40  62914480  zvol/zroot/asterisk2  GPT  (30G)
         40    532480                     1  efi  (260M)
     532520      2008                        - free -  (1.0M)
     534528  16777216                     2  freebsd-swap  (8.0G)
   17311744  45600768                     3  freebsd-zfs  (22G)
   62912512      2008                        - free -  (1.0M)

router:~ # gdisk -l /dev/zvol/zroot/asterisk2
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
   MBR: protective
   BSD: not present
   APM: not present
   GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/zvol/zroot/asterisk2: 62914560 sectors, 30.0 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 8ACD2112-5EBF-11ED-8F56-00A098E3C14E
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 40, last usable sector is 62914519
Partitions will be aligned on 8-sector boundaries
Total free space is 4016 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
    1              40          532519   260.0 MiB   EF00  efiboot0
    2          534528        17311743   8.0 GiB     A502  swap0
    3        17311744        62912511   21.7 GiB    A504  zfs0
router:~ # zpool import
    pool: testing
      id: 8013833172609421701
   state: UNAVAIL
status: One or more devices are missing from the system.
  action: The pool cannot be imported. Attach the missing
         devices and try again.
    see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-3C
  config:

         testing                   UNAVAIL  insufficient replicas
           zvol/zroot/asterisk2p3  UNAVAIL  cannot open
router:~ # sysctl vfs.zfs.vol.recursive=1
vfs.zfs.vol.recursive: 0 -> 1
router:~ # zpool import
    pool: testing
      id: 8013833172609421701
   state: ONLINE
  action: The pool can be imported using its name or numeric identifier.
  config:

         testing                   ONLINE
           zvol/zroot/asterisk2p3  ONLINE
router:~ # zpool import -fR /mnt testing

This hangs forever....
The only way to import that pool from the zvol that I know of.....



Dan


--
Dan The Man
CEO & Founder
Websites, Domains and Everything else
http://www.SunSaturn.com/aboutus.php
Email: Dan@SunSaturn.com
PGP Key: https://SunSaturn.com/pgp.txt
A1A7 6E84 FB0B 8994 C3B5  A1BA FF6F 4997 7311 C386

From nobody Tue Nov  8 00:43:30 2022
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 4N5q8j3D0Wz4gs5X
	for ; Tue,  8 Nov 2022 00:43:33 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5q8h2S1Gz3Mrt
	for ; Tue,  8 Nov 2022 00:43:32 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: by mail-qk1-x72c.google.com with SMTP id g10so8273307qkl.6
        for ; Mon, 07 Nov 2022 16:43:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=8Y+19Ouy3hZ3lf71pnaJrO21GromMGXmxfzAYd64b9s=;
        b=duRcSzQ9ufrLOPwh/eD31cdajjbNqAHxKkAhcxQIgwinChKzS+EHe+trq9tYdhtdXV
         UeTbLcg+sYRRDf9M2NNZY8j3eTPzHHaJ1mFRct3TPNfuJLxf46riL2vS7gTeeBPzJf/S
         5BbDMD0d18j6XnU58Sxr55HSpZ4CbjXgE/zCuJoMqS97XsG6ZSK4u2T49LCdhW7f91Ig
         VQq9IbopxSygSR1NHCPQtt1eQpQCh7RPoibcxlpAhYhxE5d53en9IXmu/Nvbg9Zzm2fg
         lQmIT+Ys9A1NXfC0HgbFJ26O2ulI68ZzIKJsivtERx5vyW0ilfYDFquT9gHtRngIsOfo
         osdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=8Y+19Ouy3hZ3lf71pnaJrO21GromMGXmxfzAYd64b9s=;
        b=3cK8nwpVhgorEvAKEkGlOCnOxvRUBgqEoaMPq0ThSFeqFOaEP+5MRVbGebfI9H8ih0
         t5TZ8YtmstZHQ1Sl076H3SPfI3vxDxbPJZBEaxo11UqNhOZo1+0JddwDlsdr+YJKR+YB
         0xHznwjzjnp3xtHBPoOt4OPDUfVDncbFins00UF98n7LlBRvAaoGDwoBuxlLt9sB8xeh
         UNA+zJWWAWhz8xN2c9FVb1Zhp4yig+0ka4s1PgtuYwOgmpuqxQmcQZ8rftpNuMZGD5C+
         5pdUE9lbfQAvTE4JWiHS5xPzsvFjnXW8Hs/rKx7zUnZWYfP8/8Ptu98Ldxd3iqGgg3Cp
         upog==
X-Gm-Message-State: ACrzQf0I5hxo/LAeb5jI/eK081e+bP8vqJCSQTQaUFnX2DEsJYSNe6Dl
	pUOg8HfdR3oTtEGfLobmzf4eM5dH9so=
X-Google-Smtp-Source: AMsMyM7akxq0AyV8luGRGL/jxCsVObFZ0wIRlm3dfd1YdbPSuSLE8NCvjNzItd1ozUh16DsW0nHc8Q==
X-Received: by 2002:a05:620a:1667:b0:6fa:1b5e:b9b4 with SMTP id d7-20020a05620a166700b006fa1b5eb9b4mr36089940qko.141.1667868211440;
        Mon, 07 Nov 2022 16:43:31 -0800 (PST)
Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234])
        by smtp.gmail.com with ESMTPSA id az8-20020a05620a170800b006bb87c4833asm7946300qkb.109.2022.11.07.16.43.30
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 07 Nov 2022 16:43:31 -0800 (PST)
Message-ID: <62348dc1-7f9a-f8ae-db77-f2f5d8a709d8@FreeBSD.org>
Date: Mon, 7 Nov 2022 19:43:30 -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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: vfs.zfs.vol.recursive hang makes it impossible to mount zvol
Content-Language: en-US
To: Dan The Man , freebsd-current@FreeBSD.org
References: 
From: Alexander Motin 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4N5q8h2S1Gz3Mrt
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=duRcSzQ9;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::72c as permitted sender) smtp.mailfrom=mavbsd@gmail.com
X-Spamd-Result: default: False [-3.19 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72c:from];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-ThisMailContainsUnwantedMimeParts: N

On 07.11.2022 18:53, Dan The Man wrote:
> router:~ # sysctl vfs.zfs.vol.recursive=1
> vfs.zfs.vol.recursive: 0 -> 1
> router:~ # zpool import
>     pool: testing
>       id: 8013833172609421701
>    state: ONLINE
>   action: The pool can be imported using its name or numeric identifier.
>   config:
> 
>          testing                   ONLINE
>            zvol/zroot/asterisk2p3  ONLINE
> router:~ # zpool import -fR /mnt testing
> 
> This hangs forever....
> The only way to import that pool from the zvol that I know of.....

Mounting ZFS from ZVOLs is blocked for a reason.  It causes deadlocks 
due to lock recursion.  I don't know what you are trying to achieve, but 
as alternatives, the ZVOL can be passed inside VM, it can be shared via 
iSCSI (even inside the host itself), etc.

-- 
Alexander Motin

From nobody Tue Nov  8 02:40:09 2022
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 4N5sln0N7dz4h61m
	for ; Tue,  8 Nov 2022 02:40:37 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5slm0Yr3z3cwR
	for ; Tue,  8 Nov 2022 02:40:36 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=C3ROZqM5;
	spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::b2f as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-yb1-xb2f.google.com with SMTP id 131so11473271ybl.3
        for ; Mon, 07 Nov 2022 18:40:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=3uiwpkxgshAFu/Nu3Vkh76nO8bjIeJKmNka7HJfmORc=;
        b=C3ROZqM5h1d3N9EZIKfbtotCUWhyNXV5PUZyoMfMJH37i9PCuAW8RyX0xK+XBJEAvu
         r96J4LgyXGYBV0SFGWTHRxwIAxLsRTbcBo5ULHc1oCn3Vl96KEzlv1SyE5Rk83hGxg2V
         aBeFMqCNVEFGXu960lxIQ/O5o1n+Hbzk7LzrOl9PwPqMGbog+MDhQLIUaSjifvyS9sXr
         TBsXezjjZYPFvcLbeka/CAjg52BvHgXGnektQ4nd1K+xy6i5o0WdN8wglXH9xPtg0CsW
         w1MJ05mGmk2XC+FLDXXG4Ksmys9f3TeWF1MTv5NsPajC58G4yvAVEpew6iwMFiwGQcmK
         LOeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=3uiwpkxgshAFu/Nu3Vkh76nO8bjIeJKmNka7HJfmORc=;
        b=RGWZjLwQBEIktP/6fMBp9Su41V+Xrx0Kr0ig2mxrce1yY5cK4nYvu6ZTRkdGPirZzC
         r5eYTloUHAT+QKHT7QmlakMGNG75+p0GoH9lqaaWgC7GtLgZBCfdQ3JzfBsJ6LqWjFEV
         oNGmzdGerTd+faMJ6vwigvEtrEXDzFNdoNb8p2gxBw4lLXfwZjnUGTE4FiRNUcdM5eki
         1C2JX/uFFZari7OSlZUNZmawbnTVpmK1XVbRhyv30vhTBcexZT0VEZzli8xqx/opm9ow
         7SfG/hN1E2JSZRIEK/Z9zREXGPPs+ZMHIOYEZbmNVHfSPw67Fg0GVlANlNxHy0QSX6Dc
         +uZQ==
X-Gm-Message-State: ACrzQf0U7+abaGlHSDC9pF754WLeYalNlgMayI6w3sQ2NfuiUOmjD0CC
	kwRyjIEsJrvp72HBHKtnzIkLcH5/Eu5QzOPljuZgAH6N0n0=
X-Google-Smtp-Source: AMsMyM5zDPl44V/Z7iVYi9zRVsa8lSY7Q2dQFFwnBLJJ0PZKnKvDWbqsGmIddJTnXEzlxiJRQF7wvsfKjBA0QYMGfUo=
X-Received: by 2002:a25:6412:0:b0:6cc:6507:bfae with SMTP id
 y18-20020a256412000000b006cc6507bfaemr49426491ybb.537.1667875235315; Mon, 07
 Nov 2022 18:40:35 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
 
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Tue, 8 Nov 2022 10:40:09 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Mark Millard 
Cc: freebsd-current 
Content-Type: multipart/alternative; boundary="000000000000ee420f05ecec76a2"
X-Rspamd-Queue-Id: 4N5slm0Yr3z3cwR
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2f:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TAGGED_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000ee420f05ecec76a2
Content-Type: text/plain; charset="UTF-8"

On Sat, Nov 5, 2022 at 5:28 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
>
> On Thu, Nov 3, 2022 at 7:52 AM Mark Millard  wrote:
>
>> On 2022-Nov-2, at 14:09, Archimedes Gaviola 
>> wrote:
>>
>> > On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <
>> archimedes.gaviola@gmail.com> wrote:
>> >
>> > . . .
>> >
>> > . . .
>> >
>> >
>> > Hi Mark,
>> >
>> > Just an update, as kernel and world compilation is ongoing with my
>> RPi3B system (with swap partition) is doing so far, so good. It already
>> surpassed the tough part that breaks the compilation process here.
>> > ...
>> >
>> > llvm-tblgen -gen-asm-matcher  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-asm-writer  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-callingconv  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-compress-inst-emitter  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-dag-isel  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-disassembler  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-global-isel  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-instr-info  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-emitter  -I /usr/src/contrib/llvm-project/llvm/include
>> -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-pseudo-lowering  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-register-bank  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-register-info  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-searchable-tables  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-subtarget  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> > llvm-tblgen -gen-searchable-tables  -I
>> /usr/src/contrib/llvm-project/llvm/include -I
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>> RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc
>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>> >
>> > Any thoughts why this part is quite a challenge when it comes to memory
>> usage? The other architectures do not possess such behavior... just curious.
>>
>
> Hi Mark,
>
> Sorry for the late response, I got fully occupied at work for the past few
> days due to deliverables. Thanks for your feedback and further inputs!
>
>
>> I've not done any monitoring of buildworld buildkernel build
>> activity (RAM use, memory space use, swap partition use over
>> time) on RPi3B class hardware in a very long time.
>>
>
> It's alright, it so happened that I just observed that behavior on that
> particular part as it requires more memory than other architectures while
> compiling. The additional 3.5G swap partition really helps on that part
> that's why I was so happy that the compilation continued and never broke.
> Your input of having 3.5G swap allocation is very effective.
>
> Even on systems that I have monitored in more recent times,
>> what I usually monitor tends to be builds with -jN (such as
>> -j4 fora 4-hardware-thread system). (I once did have an
>> example of -j3 taking less time than -j4 on a RPi4B.
>>
>
> Wow, this is interesting this -jN. Let me explore this as well. I usually
> build kernel the old way but recently since I have to include building the
> world then I need to use the new way.
>
>
>> Basically, the memory subsystem can be saturated without all
>> the cores being in use. The extra interference made things
>> take longer.)
>>
>
> Oh I see so it's the reason.
>
>
>> You had listed that you were using the likes of:
>>
>> # cd /usr/src ; make KERNCONF=ARM TARGET_ARCH=aarch64 \
>> buildkernel buildworld installkernel installworld distribution \
>> DESTDIR=/home/freebsd/rpi3b
>>
>> I'll note that the standard order of the first 2 is:
>>
>> buildworld buildkernel
>>
>> This is because buildworld builds some software that
>> buildkernel does not build for itself but does use.
>>
>
> Okay this is noted, thanks for clarifying and correcting me, I really
> appreciate it. I'll reflect on the proper build sequence for much
> efficiency.
>
>
>> There is a kernel-toolchain target for avoiding the
>> need to do a full buildworld just to buildkernel , so:
>>
>> kernel-toolchain buildkernel
>>
>> is an expected sequence.
>>
>
> Okay I'll take note of this too.
>
>
>> I do not know how long a from-scratch buildworld
>> buildkernel without a -jN takes on a RPi3B these
>> days. If I remember right, for -jN with 1> saw claims about such they were somewhere in the
>> range 36hr..48hr.
>
>
> There's an ongoing build at the moment, it's already taking 41 hours since
> I started it. I took another build when I came back home from the office.
>
>
>> But I'm unsure of the specific N
>> that was in use. Nor do I know the storage media
>> type(s) involved, for example. I do not remember
>> any reports for -j1.
>>
>
> I'll try this with RPi 3B. The current build that I have will be my
> baseline.
>
> Use of the likes of: vm.pageout_oom_seq=120
>> was essential to such -jN usage on a RPi3B as N
>> gets larger. Of course, swap partition use for
>> paging was also essential.
>>
>
> Wow, that's great! I have this vm.pageout_oom_seq=120 configured in my
> system now based on your previous inputs.
>
> Likewise use of:
>>
>> vm.swap_enabled=0
>> vm.swap_idle_enabled=0
>>
>> can be important to not losing communication
>> with the RPi3B. Those last 2 are not tunable
>> but are writable:
>>
>> # sysctl -aT | grep swap_
>> # sysctl -aW | grep swap_
>> vm.swap_enabled: 0
>> . . .
>> vm.swap_idle_enabled: 0
>> . . .
>>
>> (This means that they have fewer places where
>> assignments can be made. For example, the
>> loader can not make the assignments.)
>>
>> By contrast, vm.pageout_oom_seq is both
>> writable and tunable:
>>
>> # sysctl -aW | grep oom
>> . . .
>> vm.pageout_oom_seq: 120
>> . . .
>>
>> # sysctl -aT | grep oom
>> . . .
>> vm.pageout_oom_seq: 120
>> . . .
>>
>> (So even the loader can make such assignments.)
>>
>
> Yes, I have these two sysctl parameters configured in the system. Thanks
> for the details and further inputs.
>
>
>> I'll note that I've no interest in using arm hardware
>> to build for other types of hardware. So I normally
>> have the targeting of support for building for other
>> architectures disabled when I build on aarch64 or
>> armv7. (Basically, a less complete clang/clang++
>> related toolchain ends up being built.)
>>
>
> Ah okay, so you mean to say that you disable these other architectures by
> declaring and accomplishing it in the /etc/src.conf?
>
> I'll provide an update here once the build is done knowing how long it
> takes to finish.
>

Hi Mark,

With this set of build commands now,

# cd /usr/src; make -j3 KERNCONF=ARM TARGET_ARCH=aarch64 buildworld
kernel-toolchain buildkernel installworld installkernel distribution
DESTDIR=/home/freebsd/rpi3b

in RPi 3B, I encountered the other OOM error which is the 'thread waited
too long to allocate a page'. This occurred from every build I conducted.
Though the first error on 'failed to reclaim memory' was never experienced
again. Below are the error logs.
...
swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 4096
swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40960
pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to
allocate a page
swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192

Perhaps some further tweaks are needed in the system so I set aside my RPi
3B temporarily and switched over to my RPi 4B using the same microSD card
and USB flash drive (3.5 GB swap partition device) and the build completed
successfully. It took around 30 hours to complete. This RPi 4B has 2GB RAM
capacity while the RPi 3B has 1GB. From here, I'll continue looking further
for system tunables in RPi 3B which has lesser RAM capacity.

Thanks and best regards,
Archimedes

--000000000000ee420f05ecec76a2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Nov 5, 2022 at 5:28 PM Archim=
edes Gaviola <archimedes=
.gaviola@gmail.com> wrote:



On Thu, Nov 3, 2022 at 7:52 AM Mark Millard <marklmi@yahoo.com&=
gt; wrote:
On 20=
22-Nov-2, at 14:09, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrot=
e:



> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <archimedes.gaviola@gmail=
.com> wrote:

> 

> . . .

> 

> . . .

> 

> 

> Hi Mark,

> 

> Just an update, as kernel and world compilation is ongoing with my RPi=
3B system (with swap partition) is doing so far, so good. It already surpas=
sed the tough part that breaks the compilation process here.

> ...

> 

> llvm-tblgen -gen-asm-matcher=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc=C2=A0 /usr/src/contrib/l=
lvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-asm-writer=C2=A0 -I /usr/src/contrib/llvm-project/llv=
m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R=
ISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc=C2=A0 /usr/src/contrib/llvm=
-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-callingconv=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc=C2=A0 /usr/src/contrib=
/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-compress-inst-emitter=C2=A0 -I /usr/src/contrib/llvm-=
project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=
=C2=A0 -d RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.=
inc=C2=A0 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-dag-isel=C2=A0 -I /usr/src/contrib/llvm-project/llvm/=
include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RIS=
CVGenDAGISel.inc.d -o RISCVGenDAGISel.inc=C2=A0 /usr/src/contrib/llvm-proje=
ct/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-disassembler=C2=A0 -I /usr/src/contrib/llvm-project/l=
lvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d=
 RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc=C2=A0 /=
usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-global-isel=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc=C2=A0 /usr/src/contrib/l=
lvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-instr-info=C2=A0 -I /usr/src/contrib/llvm-project/llv=
m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R=
ISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc=C2=A0 /usr/src/contrib/llvm=
-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-emitter=C2=A0 -I /usr/src/contrib/llvm-project/llvm/i=
nclude -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RISC=
VGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc=C2=A0 /usr/src/contrib=
/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-pseudo-lowering=C2=A0 -I /usr/src/contrib/llvm-projec=
t/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0=
 -d RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc=C2=A0 /u=
sr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-bank=C2=A0 -I /usr/src/contrib/llvm-project/=
llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -=
d RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc=C2=A0 /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-info=C2=A0 -I /usr/src/contrib/llvm-project/=
llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -=
d RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc=C2=A0 /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=
=A0 -d RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc=C2=A0=
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-subtarget=C2=A0 -I /usr/src/contrib/llvm-project/llvm=
/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RI=
SCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc=C2=A0 /usr/src/contr=
ib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=
=A0 -d RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc=C2=A0 /us=
r/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> 

> Any thoughts why this part is quite a challenge when it comes to memor=
y usage? The other architectures do not possess such behavior... just curio=
us.

Hi Mark,

S=
orry for the late response, I got fully occupied at work for the past few d=
ays due to deliverables. Thanks for your feedback and further inputs!
=

=C2=A0

I've not done any monitoring of buildworld buildkernel build

activity (RAM use, memory space use, swap partition use over

time) on RPi3B class hardware in a very long time.
It's alright, it so happened that I just observed that beha=
vior on that particular part as it requires more memory than other architec=
tures while compiling. The additional 3.5G swap partition really helps on t=
hat part that's why I was so happy that the compilation continued and n=
ever broke. Your input of having 3.5G swap allocation is very effective.


Even on systems that I have monitored in more recent times,

what I usually monitor tends to be builds with -jN (such as

-j4 fora 4-hardware-thread system). (I once did have an

example of -j3 taking less time than -j4 on a RPi4B.
<=
br>
Wow, this is interesting this -jN. Let me explore this as wel=
l. I usually build kernel the old way but recently since I have to include =
building the world then I need to use the new way. 
=C2=A0

Basically, the memory subsystem can be saturated without all

the cores being in use. The extra interference made things

take longer.)

Oh I see so it's the =
reason.
=C2=A0

You had listed that you were using the likes of:



# cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64 \

buildkernel buildworld installkernel installworld distribution \

DESTDIR=3D/home/freebsd/rpi3b



I'll note that the standard order of the first 2 is:



buildworld buildkernel



This is because buildworld builds some software that

buildkernel does not build for itself but does use.
Okay this is noted, thanks for clarifying and correcting me, I=
 really appreciate it. I'll reflect on the proper build sequence for mu=
ch efficiency.
=C2=A0

There is a kernel-toolchain target for avoiding the

need to do a full buildworld just to buildkernel , so:



kernel-toolchain buildkernel



is an expected sequence.

Okay I'll =
take note of this too.
=C2=A0

I do not know how long a from-scratch buildworld

buildkernel without a -jN takes on a RPi3B these

days. If I remember right, for -jN with 1<N, I last

saw claims about such they were somewhere in the

range 36hr..48hr.

There's an ongoing bu=
ild at the moment, it's already taking 41 hours since I started it. I t=
ook another build when I came back home from the office.
=C2=
=A0
But I'm =
unsure of the specific N

that was in use. Nor do I know the storage media

type(s) involved, for example. I do not remember

any reports for -j1.

I'll try this =
with RPi 3B. The current build that I have will be my baseline.
<=
br>

Use of the likes of: vm.pageout_oom_seq=3D120

was essential to such -jN usage on a RPi3B as N

gets larger. Of course, swap partition use for

paging was also essential.

Wow, that=
9;s great! I have this=20
vm.pageout_oom_seq=3D120 configured in my system now based on your previous=
 inputs.


Likewise use of:



vm.swap_enabled=3D0

vm.swap_idle_enabled=3D0



can be important to not losing communication

with the RPi3B. Those last 2 are not tunable

but are writable:



# sysctl -aT | grep swap_

# sysctl -aW | grep swap_

vm.swap_enabled: 0

. . .

vm.swap_idle_enabled: 0

. . .



(This means that they have fewer places where

assignments can be made. For example, the

loader can not make the assignments.)



By contrast, vm.pageout_oom_seq is both

writable and tunable:



# sysctl -aW | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



# sysctl -aT | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



(So even the loader can make such assignments.)

Yes, I have these two sysctl parameters configured in the system. =
Thanks for the details and further inputs.
=C2=A0 
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
I'll note that I've no interest in using arm hardware

to build for other types of hardware. So I normally

have the targeting of support for building for other

architectures disabled when I build on aarch64 or

armv7. (Basically, a less complete clang/clang++

related toolchain ends up being built.)

Ah okay, so you mean to say that you disable these other architectures by =
declaring and accomplishing it in the /etc/src.conf?

I'll provide an update here once the build is done knowing how long =
it takes to finish.

=

Hi Mark,
<=
br>
With this set of build commands now,

# cd /us=
r/src; make -j3 KERNCONF=3DARM TARGET_ARCH=3Daarch64 buildworld kernel-tool=
chain buildkernel installworld installkernel distribution DESTDIR=3D/home/f=
reebsd/rpi3b

in RPi 3B, I encountered the other OOM error which is the 'threa=
d waited too long to allocate a page'. This occurred from every build I=
 conducted. Though the first error on 'failed to reclaim memory' wa=
s never experienced again. Below are the error logs.
...
swap_pager: indefinit=
e wait buffer: bufobj: 0, blkno: 256929, size: 4096
swap_pager: indefini=
te wait buffer: bufobj: 0, blkno: 3628, size: 4096
swap_pager: indefinit=
e wait buffer: bufobj: 0, blkno: 255839, size: 40960
pid 46153 (c++), ji=
d 0, uid 0, was killed: a thread waited too long to allocate a page
swap=
_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
sw=
ap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
swa=
p_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
sw=
ap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192

Perhaps so=
me further tweaks are needed in the system so I set aside my RPi 3B tempora=
rily and switched over to my RPi 4B using the same microSD card and USB fla=
sh drive (3.5 GB swap partition device) and the build completed successfull=
y. It took around 30 hours to complete. This RPi 4B has 2GB RAM capacity wh=
ile the RPi 3B has 1GB. From here, I'll continue looking further for sy=
stem tunables in RPi 3B which has lesser RAM capacity.

Thanks and best regards,
Archimedes 





--000000000000ee420f05ecec76a2--

From nobody Tue Nov  8 03:25:44 2022
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 4N5tm669Rdz4hBdL
	for ; Tue,  8 Nov 2022 03:25:58 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5tm53bJjz3jk4
	for ; Tue,  8 Nov 2022 03:25:57 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b="OUF/jVsO";
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667877955; bh=L49gnqqEmpcaQogZA4W/IRYs1DXgSYwe8zjAc8mjLwQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OUF/jVsOt+oebrKJob/PdZFYQ+17idHO6b3A8uavs7KwxApruliM4RbajiJoRXr1a4zAc0iuVJ/DBOLs5ohCiAhsUgr8NnO/31Mh7fMw+QhGd+FHTvkhNNJ60KM75K2+aWtwWxyyWWVMUHagoDMmQrsZhL+nt5mePcXY3Qp9lGOyOgcfmpHGGP8VoyouE4cMuMPdIOxSatClvIxv0AlxIwDjCOQFr9aHe8sENvzElj/72C/yFwaOu8yrXFkTQlD38sZ7i6wsZA6EUNR25BvJdG6E70ikf9z8wQAMMNR33Y4iB5Wv5OigB6eANeX05zJVlqB6u2KyHO9I9nOBHKLGEQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667877955; bh=w0h92JhlFiuB9KLd3/KhqDUt40fjVm7vFiW2qcO00AG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QYafP+dDoC1gPycubsQM/yraJMCPfgILStvunffV64Fxhki6UMtNg9cCZKDg9y4XGqjf3o3s2qDIpbAIwebZWydkrM/8v8gmD38nE2JGxeoYK6oTWs+jaogznxSJREp+mObB6CDLtu0GV1PSXWkb/2Otg06g7pc0m8lstaVB93HFqxFUddnt+DyFtwZtnhQeQsV2tMCYIpGEhzvwxXcwiJlCIFq4vB8+i9Kg3e1wQRMHebi9cISShu0fhQId5wMd+XxMbgD9quGquACk+rl7KUJm2ZW7Ywq7jVkkXx9Uaxe4SUNxul4k53fUXqCN4XdmOz8yszzXngA75qkt35kjUg==
X-YMail-OSG: cAmmOccVM1lp2zaPaDbHA0djE_Do1tSx4OISZclq6Arsa0S3mcvaBzv9u86fx3.
 SZfHph12t0VyLOSpS2Wx090DvrNHEJJXDYbg21auKx8sYuI4Yzm8Ml9w9lTAm93ZmLsFsrP4Y6J7
 BYPx3nsVNqZJW8uahNT7NJLu2DTHEoIGeoxmJsJByJzRg1DUJycH8uHb7pVYevgbOBYynXYC3dSS
 H0Piv5DJC4BZ1TonDJ9zPRCdnDlibEwVADiIFvg0ZYq84w5nfb57KF3T2na6_0JHH233f6DG1e2.
 aIZnSrkvSZi_DzGc1BNpZa61ujpcNKJ_fwNzvqL2FkaM1xRIs9HCOCVtAyenDbvHsRbFBSW8RNK8
 Ja4ylRRQZWWP5s1awQqdqKbRSFaJlskepM7cxHoJkM4_DBHm8TyG01TpvfQ0rdQzbar0iefs6gTk
 g__yCr2u2DZldhbQ8XnK4NWQCngJl5ZqFpoi.JKo2zS6J.QMvRmMI43FBvHrXZUozwnoe96D5Hk5
 5niYyLPGcGffGTsYcPDm6_4txMgTsfA0_tUWRDE6kj2qa_Q4Y9.Zu4OxDfAXcwW9LaGRYRDuavoo
 12ShFsRK_EWC5kA4lHSp31lOWONwIBIHpp9MbF8CCTZr2B4NJfqvu6NSaT.FLRVnUprIeU4G7UOL
 7AJZEf.mGE3JA48SaPpYArkLF7v5Kncg0HVNBiqOUq76xIILq0aYR_NQHhW2TvTGW9iyEPmSd9Yy
 2RIZjyc4YY9AgxoqE_kBz8MmLnTd1AinZqFlwkDU7iG.JdCNZpA6APT5bwhkyYJRYfsa_5Ww74nF
 UFJ7qQ4MnuAftqCUe6OKjXIrU.9l1aiIp6xFQFUz.oFWLYP8fWnCO01ImdEonHfy3PD4YPMOXBCg
 0tNnogxXVJDvTS4zf9dYoaGrDSVyD72kb4HUPUdLjD7gKWxUuyk89ajwEN_T0Kv3SdavJP_Uq54S
 oN9sXgF2DxM36ZtQqeI.meKvw3ETHLKMe2tb1gQRigX4nlNTZUs3VwHDZr0aX8Yvyxv2OkIjlqaB
 oUo8grcyXgTwHEEdKP3VEofUQpRRjSL8pmYNFf6gFEJ0_LXGAkIr6Mpv.88QAZcyQ4_itw3H4f5S
 lvsf7hB584sfyUNADVdDcDpoiogvftb2MCZNba7AOWoDeXCYNE8N.S1NTXB9OgQNGKRnLCs82KOl
 J9AFeT_5a8ZMmkjI3.7Prw2O_bzSotspx8mR.gKcvDbSsPMrCNthurpApYCIyti_Bn1fS0tH.V3Y
 86CmIGpU8yU4UwQtaNFVCL0jixcPKexX30_uE6u8Jgy5lZNoejjSS9_9XRwZRTOmXNvsEK1bKb2a
 GAq4ZL8og6n.NH_kkXna9BjTbg.LS0M8sP9AdZs3IaTkPMQjti8ANaqdwuunhlaMxynAXQN2mVGH
 OmtR4WSOeKwkeKAprlbcONjpTL9.5OlKPtgUGNPIyrqi1lZ04tOObtTOCYYzth9MAzva_PdoZ_A7
 ECDvBRNGqZMnm1ADiilYb3Mb_jjjzeBMRs33VS0LJ88ptTiDWXSPSM5Tc7R56ppzqigHt.NSM8Vs
 rt6.KhN6fV8KoLISnEZTsS3fzJgnVIk4PC65oIcBqvMWQseSdaULoAEyJ446aBOuFMIDa0JIQrZ2
 .385BTnHVxOeVTBGny_V1Gbl4UqJ6vY9f4yEg2CY8dP.mtQY8zoJ.FL9AjdOK2iTfRwIowhRf9aP
 d7LSgEbWsI87XK6DxQliz4FIzfL.zWkmZ3_lkQleVUhr0.VnT.WYp6cwuS8I9_cnvERTNGYHk50h
 oJg72KLdySzVSY6ku6sR6NsOgedv0.Y2GOZmW482HK7gre6mOr6mbGVUrWnragKs9MT_9OQLqPCL
 9H6TzIs_ZveJgvqY0V6uUm1auREnCit6mXQ7eHSNJlRUUIwq0O3vF412_euJD5zXAA37IVsQAmUs
 vj6pHtKX2cZlzRqQcExuW.uN7_pgkApD2iNyD6kL_VOPTr0NRBjZeK07op64dYfJDdcbRe.Hpfyg
 a6JWIyb.fWMmDbrbotUtBCtZiYIeUTh2PdBUX_wRLHzllJZv2fJaHSKTn3oT9XiTQWMgBVWFS68Z
 I2b20zVN7Bq3Rg7Gu3uGBYW0DISwBYrwo6Nd.ImsqnLhvijWrUFEeOe_PElWl0v5YTtcxu3zXYyv
 Ih0nb6ok8PylxAL5NOQz6c4LQ70vdfpCYLwObqUt7QN9KenJX9IE1CUKsIfIq1bRhIrqFXwpaWwn
 q9OEzZZgIzCDBAc..SMbk3hff9VO4.Tak4egQCu_S902758q6akQUDqMfpSNp8FmLEE7RKL6sYdG
 A
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Nov 2022 03:25:55 +0000
Received: by hermes--production-ne1-6bcfb7fb87-5nqxg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID de4db718e88503ce952a58191c5adf84;
          Tue, 08 Nov 2022 03:25:50 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
From: Mark Millard 
In-Reply-To: 
Date: Mon, 7 Nov 2022 19:25:44 -0800
Cc: freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
 
 
 
 
 
 
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N5tm53bJjz3jk4
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]
X-ThisMailContainsUnwantedMimeParts: N

On Nov 7, 2022, at 18:40, Archimedes Gaviola =
 wrote:

> . . .
>=20
> Hi Mark,
>=20
> With this set of build commands now,
>=20
> # cd /usr/src; make -j3 KERNCONF=3DARM TARGET_ARCH=3Daarch64 =
buildworld kernel-toolchain buildkernel installworld installkernel =
distribution DESTDIR=3D/home/freebsd/rpi3b
>=20
> in RPi 3B, I encountered the other OOM error which is the 'thread =
waited too long to allocate a page'. This occurred from every build I =
conducted. Though the first error on 'failed to reclaim memory' was =
never experienced again. Below are the error logs.
> ...
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: =
4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: =
40960
> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to =
allocate a page
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: =
28672
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: =
4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: =
8192
>=20
> Perhaps some further tweaks are needed in the system so I set aside my =
RPi 3B temporarily and switched over to my RPi 4B using the same microSD =
card and USB flash drive (3.5 GB swap partition device) and the build =
completed successfully. It took around 30 hours to complete. This RPi 4B =
has 2GB RAM capacity while the RPi 3B has 1GB. =46rom here, I'll =
continue looking further for system tunables in RPi 3B which has lesser =
RAM capacity.

Given that you have added enough swap/paging
space to avoid needing more:

#
# For plunty of swap/paging space (will not
# run out), avoid pageout delays leading to
# Out Of Memory killing of processes:
vm.pfault_oom_attempts=3D-1

With the above setting, if you did run out of
swap/paging space and needed more, deadlocks
would be possible as I understand. The above
disables getting that type of OOM kill
completely but, effectively, a deadlock is
sort of a form of less-controlled kill.

There is an alternative, but I've no clue how to
find what values to set for any specific context.
I just know the names and default values (as of
when I last checked such defaults):

#
# For possibly insufficient swap/paging space
# (might run out), increase the pageout delay
# that leads to Out Of Memory killing of
# processes (showing defaults at the time):
#vm.pfault_oom_attempts=3D 3
#vm.pfault_oom_wait=3D 10
# (The multiplication is the total but there
# are other potential tradoffs in the factors
# multiplied, even for nearly the same total.)

(Yes, one of those names is the same as was set
to -1 in the earlier suggestion above. -1
disables making attempts and just waits as long
as it takes. That makes vm.pfault_oom_wait
irrelevant in that kind of context.)

As for where the settings can be placed . . .

# sysctl -T vm.pfault_oom_attempts
vm.pfault_oom_attempts: -1

# sysctl -T vm.pfault_oom_wait
vm.pfault_oom_wait: 10

(So /boot/loader.conf is appropriate: loader tunables.)

# sysctl -W vm.pfault_oom_attempts
vm.pfault_oom_attempts: -1

# sysctl -W vm.pfault_oom_wait
vm.pfault_oom_wait: 10

(So /etc/sysctl.conf or the like is an alternative:
Also writable.)

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


From nobody Tue Nov  8 03:28:54 2022
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 4N5tqn1P1Yz4hBcq
	for ; Tue,  8 Nov 2022 03:29:09 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5tql4Rrhz3kVw
	for ; Tue,  8 Nov 2022 03:29:07 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=O7x2X0uB;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62e) smtp.mailfrom=wlosh@bsdimp.com;
	dmarc=none
Received: by mail-ej1-x62e.google.com with SMTP id f27so35291282eje.1
        for ; Mon, 07 Nov 2022 19:29:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=WQ/qWoz8VPFACCYLrk+hT7QYhlgUObqVtYYQC7QuXfo=;
        b=O7x2X0uB+ui8TB0msTOuuAe/pL2ctW65h4PfXnt/f/RZ/0GGkMbgvDg5eYf1LBiNld
         VJkKzkW2Htk9HNFocMApYaYZYWZeq4rLBSdGFyJkGXfEUqFLXbf2RbE0AJCqUuubBbM1
         Jupo9ErFkGGrZHujYiNUsS04l1equGO75eWu3NJRLlFW6IkaYiFi4SKWCGHMCMPRY33Q
         cX7B1bFLZwG9LtrkoveFyNDR2oG9PF/0Wo8JCFUSKvORfj3wfXCUIyW9uJikQGlztSAW
         8/pLev4KbrO8MGzyewT5ovO0aW2Le90j3YPpfWW+TB3TZDXqV0z2pRmQeOpa38x3ZdzF
         byaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=WQ/qWoz8VPFACCYLrk+hT7QYhlgUObqVtYYQC7QuXfo=;
        b=zgNik8QJ+psJRffskjWHEtpH7CLacLywDeuo2eEsRrdGP7HW1NOuDXOUaP4vgE4RuI
         tAgZsOe4M4qs+OMg042IbIKMn0biVvPG8Ls+uOd13PJbXBHLr4demSkv8GajghxdKea4
         d4+Z0/NM4jK/2z78/BxCDqrfQSf0yiASCzd15txYwQf+7b1cLxqCj9tWkmsoonPhUFMf
         xk5O6FgoZE+Rf0+pMS7LwX9DBWSjPKG4tD6+XoOtCV1pESeBpe+R6tbsZnCZy1T0HIOJ
         2WJk50r5Iy9E49Iw6rJm0kvwWyvw9SHkTNOdlLtWyZ6uOnC0bRN3CBg/uIG4Um81kJeS
         scMw==
X-Gm-Message-State: ACrzQf0ZBYCQxsVg7kR6RncaEFpTpZNvEuPoyspv/BDzprINDGS5cEo4
	sczinu10n1oB1BN63OrVYomtiWN4JB8Hfxpe30fR7Exv56k=
X-Google-Smtp-Source: AMsMyM6Q6S/A3rQy6Uc1cV6+oXgb14nNSj7o15yy39/5T0rk96lCmKp29IJTJLtz4220JydIJzdv2snbJ/RF6knoN+Q=
X-Received: by 2002:a17:906:3b17:b0:7ad:b645:9e3e with SMTP id
 g23-20020a1709063b1700b007adb6459e3emr47072928ejf.140.1667878145971; Mon, 07
 Nov 2022 19:29:05 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
 
  
 
In-Reply-To: 
From: Warner Losh 
Date: Mon, 7 Nov 2022 20:28:54 -0700
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Archimedes Gaviola 
Cc: Mark Millard , freebsd-current 
Content-Type: multipart/alternative; boundary="0000000000006b79ac05eced24f7"
X-Rspamd-Queue-Id: 4N5tql4Rrhz3kVw
X-Spamd-Bar: --
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	TAGGED_RCPT(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000006b79ac05eced24f7
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 7, 2022 at 7:40 PM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Sat, Nov 5, 2022 at 5:28 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
>
>>
>>
>>
>> On Thu, Nov 3, 2022 at 7:52 AM Mark Millard  wrote:
>>
>>> On 2022-Nov-2, at 14:09, Archimedes Gaviola <
>>> archimedes.gaviola@gmail.com> wrote:
>>>
>>> > On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <
>>> archimedes.gaviola@gmail.com> wrote:
>>> >
>>> > . . .
>>> >
>>> > . . .
>>> >
>>> >
>>> > Hi Mark,
>>> >
>>> > Just an update, as kernel and world compilation is ongoing with my
>>> RPi3B system (with swap partition) is doing so far, so good. It already
>>> surpassed the tough part that breaks the compilation process here.
>>> > ...
>>> >
>>> > llvm-tblgen -gen-asm-matcher  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-asm-writer  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-callingconv  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-compress-inst-emitter  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-dag-isel  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-disassembler  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-global-isel  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-instr-info  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-emitter  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-pseudo-lowering  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-register-bank  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-register-info  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-searchable-tables  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-subtarget  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> > llvm-tblgen -gen-searchable-tables  -I
>>> /usr/src/contrib/llvm-project/llvm/include -I
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>> RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc
>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>> >
>>> > Any thoughts why this part is quite a challenge when it comes to
>>> memory usage? The other architectures do not possess such behavior... just
>>> curious.
>>>
>>
>> Hi Mark,
>>
>> Sorry for the late response, I got fully occupied at work for the past
>> few days due to deliverables. Thanks for your feedback and further inputs!
>>
>>
>>> I've not done any monitoring of buildworld buildkernel build
>>> activity (RAM use, memory space use, swap partition use over
>>> time) on RPi3B class hardware in a very long time.
>>>
>>
>> It's alright, it so happened that I just observed that behavior on that
>> particular part as it requires more memory than other architectures while
>> compiling. The additional 3.5G swap partition really helps on that part
>> that's why I was so happy that the compilation continued and never broke.
>> Your input of having 3.5G swap allocation is very effective.
>>
>> Even on systems that I have monitored in more recent times,
>>> what I usually monitor tends to be builds with -jN (such as
>>> -j4 fora 4-hardware-thread system). (I once did have an
>>> example of -j3 taking less time than -j4 on a RPi4B.
>>>
>>
>> Wow, this is interesting this -jN. Let me explore this as well. I usually
>> build kernel the old way but recently since I have to include building the
>> world then I need to use the new way.
>>
>>
>>> Basically, the memory subsystem can be saturated without all
>>> the cores being in use. The extra interference made things
>>> take longer.)
>>>
>>
>> Oh I see so it's the reason.
>>
>>
>>> You had listed that you were using the likes of:
>>>
>>> # cd /usr/src ; make KERNCONF=ARM TARGET_ARCH=aarch64 \
>>> buildkernel buildworld installkernel installworld distribution \
>>> DESTDIR=/home/freebsd/rpi3b
>>>
>>> I'll note that the standard order of the first 2 is:
>>>
>>> buildworld buildkernel
>>>
>>> This is because buildworld builds some software that
>>> buildkernel does not build for itself but does use.
>>>
>>
>> Okay this is noted, thanks for clarifying and correcting me, I really
>> appreciate it. I'll reflect on the proper build sequence for much
>> efficiency.
>>
>>
>>> There is a kernel-toolchain target for avoiding the
>>> need to do a full buildworld just to buildkernel , so:
>>>
>>> kernel-toolchain buildkernel
>>>
>>> is an expected sequence.
>>>
>>
>> Okay I'll take note of this too.
>>
>>
>>> I do not know how long a from-scratch buildworld
>>> buildkernel without a -jN takes on a RPi3B these
>>> days. If I remember right, for -jN with 1>> saw claims about such they were somewhere in the
>>> range 36hr..48hr.
>>
>>
>> There's an ongoing build at the moment, it's already taking 41 hours
>> since I started it. I took another build when I came back home from the
>> office.
>>
>>
>>> But I'm unsure of the specific N
>>> that was in use. Nor do I know the storage media
>>> type(s) involved, for example. I do not remember
>>> any reports for -j1.
>>>
>>
>> I'll try this with RPi 3B. The current build that I have will be my
>> baseline.
>>
>> Use of the likes of: vm.pageout_oom_seq=120
>>> was essential to such -jN usage on a RPi3B as N
>>> gets larger. Of course, swap partition use for
>>> paging was also essential.
>>>
>>
>> Wow, that's great! I have this vm.pageout_oom_seq=120 configured in my
>> system now based on your previous inputs.
>>
>> Likewise use of:
>>>
>>> vm.swap_enabled=0
>>> vm.swap_idle_enabled=0
>>>
>>> can be important to not losing communication
>>> with the RPi3B. Those last 2 are not tunable
>>> but are writable:
>>>
>>> # sysctl -aT | grep swap_
>>> # sysctl -aW | grep swap_
>>> vm.swap_enabled: 0
>>> . . .
>>> vm.swap_idle_enabled: 0
>>> . . .
>>>
>>> (This means that they have fewer places where
>>> assignments can be made. For example, the
>>> loader can not make the assignments.)
>>>
>>> By contrast, vm.pageout_oom_seq is both
>>> writable and tunable:
>>>
>>> # sysctl -aW | grep oom
>>> . . .
>>> vm.pageout_oom_seq: 120
>>> . . .
>>>
>>> # sysctl -aT | grep oom
>>> . . .
>>> vm.pageout_oom_seq: 120
>>> . . .
>>>
>>> (So even the loader can make such assignments.)
>>>
>>
>> Yes, I have these two sysctl parameters configured in the system. Thanks
>> for the details and further inputs.
>>
>>
>>> I'll note that I've no interest in using arm hardware
>>> to build for other types of hardware. So I normally
>>> have the targeting of support for building for other
>>> architectures disabled when I build on aarch64 or
>>> armv7. (Basically, a less complete clang/clang++
>>> related toolchain ends up being built.)
>>>
>>
>> Ah okay, so you mean to say that you disable these other architectures by
>> declaring and accomplishing it in the /etc/src.conf?
>>
>> I'll provide an update here once the build is done knowing how long it
>> takes to finish.
>>
>
> Hi Mark,
>
> With this set of build commands now,
>
> # cd /usr/src; make -j3 KERNCONF=ARM TARGET_ARCH=aarch64 buildworld
> kernel-toolchain buildkernel installworld installkernel distribution
> DESTDIR=/home/freebsd/rpi3b
>
> in RPi 3B, I encountered the other OOM error which is the 'thread waited
> too long to allocate a page'. This occurred from every build I conducted.
> Though the first error on 'failed to reclaim memory' was never experienced
> again. Below are the error logs.
> ...
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40960
> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to
> allocate a page
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192
>

This means that paging to the swap partition and/or swap file took too long
(> 30 seconds... that's all that indefinite means). It also means that it
can't write to backing store dirty pages to give to another process...

Typical reason is that the disk / flash is not responsive to writes for
some reason. You'll need to find why... I'd look at trims.

Or.... if you can't change the disk... you need to put less memory pressure
on it..

Warner

Perhaps some further tweaks are needed in the system so I set aside my RPi
> 3B temporarily and switched over to my RPi 4B using the same microSD card
> and USB flash drive (3.5 GB swap partition device) and the build completed
> successfully. It took around 30 hours to complete. This RPi 4B has 2GB RAM
> capacity while the RPi 3B has 1GB. From here, I'll continue looking further
> for system tunables in RPi 3B which has lesser RAM capacity.
>
> Thanks and best regards,
> Archimedes
>
>
>
>

--0000000000006b79ac05eced24f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Nov 7, 2022 at 7:40 PM Archim=
edes Gaviola <archimedes=
.gaviola@gmail.com> wrote:


On Sat, Nov 5, 2022=
 at 5:28 PM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:



On Thu, Nov 3,=
 2022 at 7:52 AM Mark Millard <marklmi@yahoo.com> wrote:
On 2022-Nov-2, at 14:09, Archimedes Gaviol=
a <arc=
himedes.gaviola@gmail.com> wrote:



> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <archimedes.gaviola@gmail=
.com> wrote:

> 

> . . .

> 

> . . .

> 

> 

> Hi Mark,

> 

> Just an update, as kernel and world compilation is ongoing with my RPi=
3B system (with swap partition) is doing so far, so good. It already surpas=
sed the tough part that breaks the compilation process here.

> ...

> 

> llvm-tblgen -gen-asm-matcher=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc=C2=A0 /usr/src/contrib/l=
lvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-asm-writer=C2=A0 -I /usr/src/contrib/llvm-project/llv=
m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R=
ISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc=C2=A0 /usr/src/contrib/llvm=
-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-callingconv=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc=C2=A0 /usr/src/contrib=
/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-compress-inst-emitter=C2=A0 -I /usr/src/contrib/llvm-=
project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=
=C2=A0 -d RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.=
inc=C2=A0 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-dag-isel=C2=A0 -I /usr/src/contrib/llvm-project/llvm/=
include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RIS=
CVGenDAGISel.inc.d -o RISCVGenDAGISel.inc=C2=A0 /usr/src/contrib/llvm-proje=
ct/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-disassembler=C2=A0 -I /usr/src/contrib/llvm-project/l=
lvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d=
 RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc=C2=A0 /=
usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-global-isel=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc=C2=A0 /usr/src/contrib/l=
lvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-instr-info=C2=A0 -I /usr/src/contrib/llvm-project/llv=
m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R=
ISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc=C2=A0 /usr/src/contrib/llvm=
-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-emitter=C2=A0 -I /usr/src/contrib/llvm-project/llvm/i=
nclude -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RISC=
VGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc=C2=A0 /usr/src/contrib=
/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-pseudo-lowering=C2=A0 -I /usr/src/contrib/llvm-projec=
t/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0=
 -d RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc=C2=A0 /u=
sr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-bank=C2=A0 -I /usr/src/contrib/llvm-project/=
llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -=
d RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc=C2=A0 /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-info=C2=A0 -I /usr/src/contrib/llvm-project/=
llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -=
d RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc=C2=A0 /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=
=A0 -d RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc=C2=A0=
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-subtarget=C2=A0 -I /usr/src/contrib/llvm-project/llvm=
/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RI=
SCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc=C2=A0 /usr/src/contr=
ib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=
=A0 -d RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc=C2=A0 /us=
r/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> 

> Any thoughts why this part is quite a challenge when it comes to memor=
y usage? The other architectures do not possess such behavior... just curio=
us.

Hi Mark,

S=
orry for the late response, I got fully occupied at work for the past few d=
ays due to deliverables. Thanks for your feedback and further inputs!
=

=C2=A0

I've not done any monitoring of buildworld buildkernel build

activity (RAM use, memory space use, swap partition use over

time) on RPi3B class hardware in a very long time.
It's alright, it so happened that I just observed that beha=
vior on that particular part as it requires more memory than other architec=
tures while compiling. The additional 3.5G swap partition really helps on t=
hat part that's why I was so happy that the compilation continued and n=
ever broke. Your input of having 3.5G swap allocation is very effective.


Even on systems that I have monitored in more recent times,

what I usually monitor tends to be builds with -jN (such as

-j4 fora 4-hardware-thread system). (I once did have an

example of -j3 taking less time than -j4 on a RPi4B.
<=
br>
Wow, this is interesting this -jN. Let me explore this as wel=
l. I usually build kernel the old way but recently since I have to include =
building the world then I need to use the new way. 
=C2=A0

Basically, the memory subsystem can be saturated without all

the cores being in use. The extra interference made things

take longer.)

Oh I see so it's the =
reason.
=C2=A0

You had listed that you were using the likes of:



# cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64 \

buildkernel buildworld installkernel installworld distribution \

DESTDIR=3D/home/freebsd/rpi3b



I'll note that the standard order of the first 2 is:



buildworld buildkernel



This is because buildworld builds some software that

buildkernel does not build for itself but does use.
Okay this is noted, thanks for clarifying and correcting me, I=
 really appreciate it. I'll reflect on the proper build sequence for mu=
ch efficiency.
=C2=A0

There is a kernel-toolchain target for avoiding the

need to do a full buildworld just to buildkernel , so:



kernel-toolchain buildkernel



is an expected sequence.

Okay I'll =
take note of this too.
=C2=A0

I do not know how long a from-scratch buildworld

buildkernel without a -jN takes on a RPi3B these

days. If I remember right, for -jN with 1<N, I last

saw claims about such they were somewhere in the

range 36hr..48hr.

There's an ongoing bu=
ild at the moment, it's already taking 41 hours since I started it. I t=
ook another build when I came back home from the office.
=C2=
=A0
But I'm =
unsure of the specific N

that was in use. Nor do I know the storage media

type(s) involved, for example. I do not remember

any reports for -j1.

I'll try this =
with RPi 3B. The current build that I have will be my baseline.
<=
br>

Use of the likes of: vm.pageout_oom_seq=3D120

was essential to such -jN usage on a RPi3B as N

gets larger. Of course, swap partition use for

paging was also essential.

Wow, that=
9;s great! I have this=20
vm.pageout_oom_seq=3D120 configured in my system now based on your previous=
 inputs.


Likewise use of:



vm.swap_enabled=3D0

vm.swap_idle_enabled=3D0



can be important to not losing communication

with the RPi3B. Those last 2 are not tunable

but are writable:



# sysctl -aT | grep swap_

# sysctl -aW | grep swap_

vm.swap_enabled: 0

. . .

vm.swap_idle_enabled: 0

. . .



(This means that they have fewer places where

assignments can be made. For example, the

loader can not make the assignments.)



By contrast, vm.pageout_oom_seq is both

writable and tunable:



# sysctl -aW | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



# sysctl -aT | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



(So even the loader can make such assignments.)

Yes, I have these two sysctl parameters configured in the system. =
Thanks for the details and further inputs.
=C2=A0 
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
I'll note that I've no interest in using arm hardware

to build for other types of hardware. So I normally

have the targeting of support for building for other

architectures disabled when I build on aarch64 or

armv7. (Basically, a less complete clang/clang++

related toolchain ends up being built.)

Ah okay, so you mean to say that you disable these other architectures by =
declaring and accomplishing it in the /etc/src.conf?

I'll provide an update here once the build is done knowing how long =
it takes to finish.

=

Hi Mark,
<=
br>
With this set of build commands now,

# cd /us=
r/src; make -j3 KERNCONF=3DARM TARGET_ARCH=3Daarch64 buildworld kernel-tool=
chain buildkernel installworld installkernel distribution DESTDIR=3D/home/f=
reebsd/rpi3b

in RPi 3B, I encountered the other OOM error which is the 'threa=
d waited too long to allocate a page'. This occurred from every build I=
 conducted. Though the first error on 'failed to reclaim memory' wa=
s never experienced again. Below are the error logs.
...
swap_pager: indefinit=
e wait buffer: bufobj: 0, blkno: 256929, size: 4096
swap_pager: indefini=
te wait buffer: bufobj: 0, blkno: 3628, size: 4096
swap_pager: indefinit=
e wait buffer: bufobj: 0, blkno: 255839, size: 40960
pid 46153 (c++), ji=
d 0, uid 0, was killed: a thread waited too long to allocate a page
swap=
_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
sw=
ap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
swa=
p_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
sw=
ap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192

This means that paging to the swap =
partition and/or swap file took too long (> 30 seconds... that's all=
 that indefinite means). It also means that it can't write to backing s=
tore dirty pages to give to another process...

Typ=
ical reason is that the disk / flash is not responsive to writes for some r=
eason. You'll need to find why... I'd look at trims.

=

Or.... if you can't change the disk... you need to put less =
memory pressure on it..

Warner

Perhaps some further tweaks are needed in the system so=
 I set aside my RPi 3B temporarily and switched over to my RPi 4B using the=
 same microSD card and USB flash drive (3.5 GB swap partition device) and t=
he build completed successfully. It took around 30 hours to complete. This =
RPi 4B has 2GB RAM capacity while the RPi 3B has 1GB. From here, I'll c=
ontinue looking further for system tunables in RPi 3B which has lesser RAM =
capacity.

Thanks and best regards,
Archimedes 


=






--0000000000006b79ac05eced24f7--

From nobody Tue Nov  8 03:53:04 2022
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 4N5vMj3x9Mz4hFKc
	for ; Tue,  8 Nov 2022 03:53:21 +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 4N5vMj0djgz3mlf
	for ; Tue,  8 Nov 2022 03:53:21 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667879598; bh=svfxvPslHlqxwuw/NRqw9/CDN1XaXhiwFoC6q6Fdi2g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Z0QiUTh/uH2GHA+cnN0Hvkc2F+KmkuzDx+TMeFe1o+lvgix0MFltVkxUBMgRa0L5Nf7sz2fH+WzsOZGRpqzkggjCgmj8K6FA+8rqZGHnQvDShbMLYemGNUTdBtb15wHJasYwvuX7Yw1AYMF1HWcCx+zI/H/tAA8C5BuZ86lDgdV4J+q9eIQBeMkvDBvBXXJXlJ0s+Q/4beqDn59d2dRJnpq3urM0czX186oP542RbSXnbtkF9ZNd5cYs/u7Uw1z6hbRg7PL0x6V/5G4XET6e89WpzLyDuWNo4MPVx/tB3zCFNUQn5gD6j83Ht03Vyk3Wz/KW5CTgMfzaFTKX15WcIw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667879598; bh=vhmpN3dvNZiFNe6Z8W2nf6HJucfk9Ym9Ki6C0egmmD0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Sfbe29wyO9AFEIXKsmkiIO+mNMm/u26UJDR+dQbWNsmuKvxGSjXncQ4PUtL3cPMTMq1neOXm4xgDzohK3pNLwtGp6st8p3R5dBzqY5wfGR2XrvsRwXF9Pfi6U/bfIZRm4bjWJvIUjPezpSll4nByuK0JSeZ/TUgO1yXIR9StqEtMCGkBrPKkQ64rzV/ryxxa8fc+u+RlRn3P3g3Wj0m6KSctn5actzZjidRJNlRhTp6cY9goBTXTmAUf86/5BdyxOsM8a0/t7kTdWfQItbyABeOjv0rvnVcevKSfMGPR4HmOt2ppDrCk+a0M1CMJUU+B/xGrEqqa7yJuxQBTusuD5A==
X-YMail-OSG: HxO2j3MVM1kd7EuLO3NzlaiPM2SnBonvRJl1yDRAdq.Z73sIvpAG6fuoHEDg_Ge
 FNXH94SJMFc3c73PbpT5zsvBHU3GzH88vhUMkHvQElkZjjmEsnbcRcGB_xX3EK05lwE2b74JuvOF
 3qAAZHD9TvGOyBz2MQMcDAVKi642yve74NFKeX.O4O4NUJkgcITvifvZGDfSoHTNFz8yhyGvw5Lk
 UdlMVs2cMlVaE4pxFZXynDvKfCHewi5Fdb79H.BMvRUdSHer_Ek890xU6f4.KEmwJGyKd5IHCvtD
 WuzstCrMO7Vj_4gNkfpNwukhqbHAbxUu9yfAX_YKpEpH4hOzu09FDLSYUnUDTCBrGYpDrhR5gB51
 srJH2rl95HIjfeUOUo0Ozmau.BZKbdiVtCsqyqQ1wKWJtMWCxKEGRKGWZsajx7L4nwI76zMGVmma
 Nc5x7aTceMzTGTgA2HBr5H9lLDHvvluCsGoy2O50n7B0StlKZYSV9PPKyCuqswGe7qyGU2S.Kqo8
 7Yly1Zslydtcah0sXADDgICvVaWDDqx2csTHYY__QRfC9LyrdAaR.WdQSrb7IEHIXrvgfKjTN87O
 8FEi982CGK7IleW7V..AfWL7WkuomSON20Xm9qiMpHCHF9blqHZBXVRvzxX9KxeD29NW3O8dRWJB
 QeoB3CbikeSM5pEQscD.PKmUUMAgEHWDHYyRWWG.4.NhuUwiJeqvzgeNb_FZq._9xEC3k8KQzDZ.
 qvoDREhn9n9fzcbyVXxwh5DA5n0Zpw2BbSurTdxYsAWbF0oVhr9BKIc8LMJfIPtwc58jHRLeox9p
 t8.Yv23RGEiQ1mA6XaoGlOqPGUxVDESXxzlUht4t3sdB1SjSYPl4V4q809cmSsY42J1QxalqehU.
 wxlTr5CswrJ66n6N9J8Ms7eNi8vaNLmcDKX8imB.0a.m9hbi1MIVkVMty1q0GNaxKUjf513UsUlF
 RXpfAa6fGDyINNcK74_khoJITMbUJxhzXOPuMpsgtXw8yKTyM.mnSRzmDP0o5xOwLZZIx9CRTfbU
 yq9MiJfHATWR2oYk8iVmKzKJDipNLUySb.CxVGZLH3hwZQC_KpLqNtqkKsWVIkEl7_n5AA3s.YY_
 dN5ylsga9GCAIofeksTWk_2o0R5TmdW6BeXtRF6XEDQJTlF3J01KdJtibEnOQaXsoz6CNYEVE9Wg
 ktc82jCEMS4In4W.tnprtshEp7ZaPNIWCdDOY.XLnlnIKYEXbHlz43bHrYH.UxOtrhJNOvnDIheC
 qztpC.vkERGwN4t8C6AkQRrQUjU8opj0X.yFWbIHPAlVDGt536kSUOAfzM.gPjNWPAihIvHNtEFq
 GSIHg4CQvKxU_AjWik_GSHROzRaMTo2WO4DVaRiBEetInCHewUm5YR6qLTL2BJq_E8jBarsOFU3v
 nMC1idNNQBZeqE0Jh.p.iu5WDVodPeDKqNfDfeI09a8a0uDsssgERLTBh7CE3c3s1eOAjq6GENqU
 rztpGv62Fv41Y6FbwEJLMBelhFsdUI2GmZARawth2G9_r5NExBfl5udXDrBtfN4sHQ.bXz__E0B8
 wjVhlfcV0S8b.QFsbB3hh6nCDIk35p8c5OZGVv_MKeRiqfbEA9TOcYSmnTJk.iBtUzY8RC.gYZfF
 JhYZjxvVWsSFLkLIS4b08x_nN5GTiiBCGqjgiwmiGN.TQzWjoWBtWDCQylabszTKEfMXl6cR3hsL
 X5k3QP8Gdkp_YEwQsBOrcAKTA__ePlWg1nlzW9DlOA4_dtr65z21xBl.S2yV8CvJWEM9nCgEbqir
 h9wFZBcBQVC6b3yrfUbR923cBUb4B5OQOvK0duUcLIYELidib79YOlQ0vKJK33vBfxX8psky8CsJ
 k_EWU8hpFB.Vt_kXj89OpdM7rUdIjsJl5yErXrXBVaZ8j64j9P0j5K.c0Sufc8GfJYkIKiTqmUdG
 2Tw1p3ab2B8c9pN672d99EGDody9huPcrwOkBaYj_acLpxTgF1c2ILoiYiikV5pauqLEZwwdnFg5
 Okbax37xYuXrGJGhnhyUHwjFwbzxZxDGcpb_OwD8dHWkzyUn028KwwdlJZHSXDfDfiT7vJtLI2v5
 ka_8cwOxHueSxVGA41DRSZFAZIHVEg75XxpfGoPlqH85ibdxG_HV3BS5fVSFB1bECUxfGMTGlvfx
 eSmYDhwVFB2u4zRWvAoWkdzz0Rl0opEG6dbN1vKa1Cx90RUksBX.8tIR1fu9ggMfTj9MGCzTIako
 xqqeIOH5neyYk8SsEO0YOlvQuz.bFMjvKFJ4U0_VzGH6M.b3GGklUppT2SO1oYHIdokce9VSm6sM
 E
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Nov 2022 03:53:18 +0000
Received: by hermes--production-gq1-579bc4bddd-56gsn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 465ba13b284b16fc845b4f740172d2f9;
          Tue, 08 Nov 2022 03:53:14 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
From: Mark Millard 
In-Reply-To: 
Date: Mon, 7 Nov 2022 19:53:04 -0800
Cc: Warner Losh ,
 freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: <788B97E7-AA06-4A87-BB4A-CF2602DC1AD3@yahoo.com>
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
 
 
 
 
 
 
 
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N5vMj0djgz3mlf
X-Spamd-Bar: ----
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_RCPT(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]
X-ThisMailContainsUnwantedMimeParts: N

On Nov 7, 2022, at 19:28, Warner Losh  wrote:
>=20
> . . .
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: =
4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: =
40960
> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to =
allocate a page
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: =
28672
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: =
4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: =
8192
>=20
> This means that paging to the swap partition and/or swap file took too =
long (> 30 seconds... that's all that indefinite means).

FYI: I think the "indefinite wait buffer" bound that leads
to those messages is 20 sec (the hz*20 below):

        /*
         * Wait for the pages we want to complete.  VPO_SWAPINPROG is =
always
         * cleared on completion.  If an I/O error occurs, SWAPBLK_NONE
         * is set in the metadata for each page in the request.
         */
        VM_OBJECT_WLOCK(object);
        /* This could be implemented more efficiently with aflags */
        while ((ma[0]->oflags & VPO_SWAPINPROG) !=3D 0) {
                ma[0]->oflags |=3D VPO_SWAPSLEEP;
                VM_CNT_INC(v_intrans);
                if (VM_OBJECT_SLEEP(object, &object->handle, PSWP,
                    "swread", hz * 20)) {
                        printf(
"swap_pager: indefinite wait buffer: bufobj: %p, blkno: %jd, size: =
%ld\n",
                            bp->b_bufobj, (intmax_t)bp->b_blkno, =
bp->b_bcount);
                }
        }
        VM_OBJECT_WUNLOCK(object);

But the "was killed: a thread waited too long to allocate a page" is
tied to a total of 30 sec (3*10sec) from:

vm.pfault_oom_attempts=3D 3
vm.pfault_oom_wait=3D 10

(Presuming that you had defaults at the time.)

> It also means that it can't write to backing store dirty pages to give =
to another process...
>=20
> Typical reason is that the disk / flash is not responsive to writes =
for some reason. You'll need to find why... I'd look at trims.
>=20
> Or.... if you can't change the disk... you need to put less memory =
pressure on it..





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


From nobody Tue Nov  8 06:50:19 2022
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 4N5zJR1Rh7z4hYjY
	for ; Tue,  8 Nov 2022 06:50:47 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5zJQ6WPwz3J24
	for ; Tue,  8 Nov 2022 06:50:46 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-yb1-xb2d.google.com with SMTP id j2so16320796ybb.6
        for ; Mon, 07 Nov 2022 22:50:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=PPkcumAW3cR0UEoHxXLW/BGUmtVi0ojslBkFQ9nGBJs=;
        b=hx4UC5SO4zbRAw/y+dIwasYC0EnyAJSxHljFW0A1T0/zT8U4uICWRr7AEZJVLROsyy
         rFsjc+VR2iJDRwUlvBBlsqh7nwBax0eofdk6HXITsdfgRw5VxSqED29nrChQPPHsLN29
         IUdIN7PR6oise+BCvm7kVUG2Mg1K+QHc2iOlHe1JwDkK0NsqjNkSPDCWPYBCEwhhlOol
         vDpLgeVDtdJ0Q3nHQ/vLquDo8I/G0122BudqMsmz8VEz7uko54qUJu2h6DQveMB5Q/5U
         tzcVuhUdX6sJLiZsJ+Shjiwdt+QXouYSGuWmAtq5Gnz5MlpoWViq727Qp7rkfDGOAwbN
         RLLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=PPkcumAW3cR0UEoHxXLW/BGUmtVi0ojslBkFQ9nGBJs=;
        b=zK3kkwXlEhrVhnKXNvzTyRmZVDYatdp0EQEa50HTgojnLn5m75w1iu06ZvyJGA6KQz
         MASm2VfAAlqQVO0akOQeBM1Zz7hbok66J9P467SC4pNgzE1Eo0ed+EGJWIGGQ/1T2a5Y
         DqAODYJYYqh90+zbcW6qayJdxb/9AqdGbygrEClcnEHaCDX3L9/GvA6lvPpysxnqSEer
         WuAMUYKZsr1+5TpTP39/KkDeIPVTbU2BJkpOpnikEo/k7pQNR0pcLklifBE4mNoH1A/d
         pdQSn9BW0SBe3uX4fusu3qrqH6pg5v02az03YTG0BiztphtY1cwGlG6goVhNpZv/5MhF
         QuQA==
X-Gm-Message-State: ACrzQf2Vuc/qApIRtwHMgQsG2GagF3uvAqBPF407CPHbN1fSisNe36NO
	SgBwo3W44OeDPHD/iliQcizwe1rIqT32FkR/mku/a2znPWE=
X-Google-Smtp-Source: AMsMyM5kWpiXpe3BEh5hOobELpk10zQVIS+eXKc3rWYvZHaJARAFU42gXomhj/3m/u47T9Y08BQnVsL2uPvN9TKAbMY=
X-Received: by 2002:a25:3f86:0:b0:6bc:998:873e with SMTP id
 m128-20020a253f86000000b006bc0998873emr54247420yba.152.1667890245763; Mon, 07
 Nov 2022 22:50:45 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
 
  
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Tue, 8 Nov 2022 14:50:19 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Mark Millard 
Cc: freebsd-current 
Content-Type: multipart/alternative; boundary="0000000000009f850205eceff5e7"
X-Rspamd-Queue-Id: 4N5zJQ6WPwz3J24
X-Spamd-Bar: ----
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];
	TAGGED_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000009f850205eceff5e7
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 8, 2022 at 11:25 AM Mark Millard  wrote:

> On Nov 7, 2022, at 18:40, Archimedes Gaviola 
> wrote:
>
> > . . .
> >
> > Hi Mark,
> >
> > With this set of build commands now,
> >
> > # cd /usr/src; make -j3 KERNCONF=ARM TARGET_ARCH=aarch64 buildworld
> kernel-toolchain buildkernel installworld installkernel distribution
> DESTDIR=/home/freebsd/rpi3b
> >
> > in RPi 3B, I encountered the other OOM error which is the 'thread waited
> too long to allocate a page'. This occurred from every build I conducted.
> Though the first error on 'failed to reclaim memory' was never experienced
> again. Below are the error logs.
> > ...
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40960
> > pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to
> allocate a page
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192
> >
> > Perhaps some further tweaks are needed in the system so I set aside my
> RPi 3B temporarily and switched over to my RPi 4B using the same microSD
> card and USB flash drive (3.5 GB swap partition device) and the build
> completed successfully. It took around 30 hours to complete. This RPi 4B
> has 2GB RAM capacity while the RPi 3B has 1GB. From here, I'll continue
> looking further for system tunables in RPi 3B which has lesser RAM capacity.
>

Hi Mark,


> Given that you have added enough swap/paging
> space to avoid needing more:
>
> #
> # For plunty of swap/paging space (will not
> # run out), avoid pageout delays leading to
> # Out Of Memory killing of processes:
> vm.pfault_oom_attempts=-1
>
> With the above setting, if you did run out of
> swap/paging space and needed more, deadlocks
> would be possible as I understand. The above
> disables getting that type of OOM kill
> completely but, effectively, a deadlock is
> sort of a form of less-controlled kill.
>

Okay, confirmed the existing value is 3.

root@generic:~ # sysctl vm.pfault_oom_attempts
vm.pfault_oom_attempts: 3

and is writable as tested.

root@generic:~ # sysctl vm.pfault_oom_attempts=-1
vm.pfault_oom_attempts: 3 -> -1


> There is an alternative, but I've no clue how to
> find what values to set for any specific context.
> I just know the names and default values (as of
> when I last checked such defaults):
>
> #
> # For possibly insufficient swap/paging space
> # (might run out), increase the pageout delay
> # that leads to Out Of Memory killing of
> # processes (showing defaults at the time):
> #vm.pfault_oom_attempts= 3
> #vm.pfault_oom_wait= 10
> # (The multiplication is the total but there
> # are other potential tradoffs in the factors
> # multiplied, even for nearly the same total.)
>
> (Yes, one of those names is the same as was set
> to -1 in the earlier suggestion above. -1
> disables making attempts and just waits as long
> as it takes. That makes vm.pfault_oom_wait
> irrelevant in that kind of context.)
>
> As for where the settings can be placed . . .
>
> # sysctl -T vm.pfault_oom_attempts
> vm.pfault_oom_attempts: -1
>
> # sysctl -T vm.pfault_oom_wait
> vm.pfault_oom_wait: 10
>
> (So /boot/loader.conf is appropriate: loader tunables.)
>

Okay noted this.


>
> # sysctl -W vm.pfault_oom_attempts
> vm.pfault_oom_attempts: -1
>
> # sysctl -W vm.pfault_oom_wait
> vm.pfault_oom_wait: 10
>

Checking these values...

root@generic:~ # sysctl -T vm.pfault_oom_attempts
vm.pfault_oom_attempts: -1

root@generic:~ # sysctl -T vm.pfault_oom_wait
vm.pfault_oom_wait: 10


> (So /etc/sysctl.conf or the like is an alternative:
> Also writable.)
>

Okay this is noted.

Thanks and best regards,
Archimedes

--0000000000009f850205eceff5e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable





On Tue, Nov 8, 2022 at 11:25 AM Mark Millard <marklmi@yahoo.com> wrote:
On Nov 7, 2022, at 18:=
40, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:



> . . .

> 

> Hi Mark,

> 

> With this set of build commands now,

> 

> # cd /usr/src; make -j3 KERNCONF=3DARM TARGET_ARCH=3Daarch64 buildworl=
d kernel-toolchain buildkernel installworld installkernel distribution DEST=
DIR=3D/home/freebsd/rpi3b

> 

> in RPi 3B, I encountered the other OOM error which is the 'thread =
waited too long to allocate a page'. This occurred from every build I c=
onducted. Though the first error on 'failed to reclaim memory' was =
never experienced again. Below are the error logs.

> ...

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 40=
96

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096=


> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40=
960

> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to=
 allocate a page

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28=
672

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192=


> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 40=
96

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 81=
92

> 

> Perhaps some further tweaks are needed in the system so I set aside my=
 RPi 3B temporarily and switched over to my RPi 4B using the same microSD c=
ard and USB flash drive (3.5 GB swap partition device) and the build comple=
ted successfully. It took around 30 hours to complete. This RPi 4B has 2GB =
RAM capacity while the RPi 3B has 1GB. From here, I'll continue looking=
 further for system tunables in RPi 3B which has lesser RAM capacity.

Hi Mark,




Given that you have added enough swap/paging

space to avoid needing more:



#

# For plunty of swap/paging space (will not

# run out), avoid pageout delays leading to

# Out Of Memory killing of processes:

vm.pfault_oom_attempts=3D-1



With the above setting, if you did run out of

swap/paging space and needed more, deadlocks

would be possible as I understand. The above

disables getting that type of OOM kill

completely but, effectively, a deadlock is

sort of a form of less-controlled kill.

Okay, confirmed the existing value is 3.

root=
@generic:~ # sysctl vm.pfault_oom_attempts
vm.pfault_oom_attempts: 3

and is writable as tested.

r=
oot@generic:~ # sysctl vm.pfault_oom_attempts=3D-1
vm.pfault_oom_attempt=
s: 3 -> -1
=C2=A0

There is an alternative, but I've no clue how to

find what values to set for any specific context.

I just know the names and default values (as of

when I last checked such defaults):



#

# For possibly insufficient swap/paging space

# (might run out), increase the pageout delay

# that leads to Out Of Memory killing of

# processes (showing defaults at the time):

#vm.pfault_oom_attempts=3D 3

#vm.pfault_oom_wait=3D 10

# (The multiplication is the total but there

# are other potential tradoffs in the factors

# multiplied, even for nearly the same total.)



(Yes, one of those names is the same as was set

to -1 in the earlier suggestion above. -1

disables making attempts and just waits as long

as it takes. That makes vm.pfault_oom_wait

irrelevant in that kind of context.)



As for where the settings can be placed . . .



# sysctl -T vm.pfault_oom_attempts

vm.pfault_oom_attempts: -1



# sysctl -T vm.pfault_oom_wait

vm.pfault_oom_wait: 10



(So /boot/loader.conf is appropriate: loader tunables.)

Okay noted this.
=C2=A0



# sysctl -W vm.pfault_oom_attempts

vm.pfault_oom_attempts: -1



# sysctl -W vm.pfault_oom_wait

vm.pfault_oom_wait: 10

Checking these v=
alues...

root@generic:~ # sysctl -T vm.pfault_oom_=
attempts
vm.pfault_oom_attempts: -1

root@generic:~ # sysctl -T vm=
.pfault_oom_wait
vm.pfault_oom_wait: 10

<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">


(So /etc/sysctl.conf or the like is an alternative:

Also writable.)

Okay this is noted.

Tha=
nks and best regards,
Archimedes
<=
/div>



--0000000000009f850205eceff5e7--

From nobody Tue Nov  8 07:03:59 2022
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 4N5zcC4CY7z4gbw3
	for ; Tue,  8 Nov 2022 07:04:27 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5zcB56LZz3MQM
	for ; Tue,  8 Nov 2022 07:04:26 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-36a4b86a0abso125800497b3.7
        for ; Mon, 07 Nov 2022 23:04:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Ta27xDjNHXekNaDRZQc6cmIQAhodseI/zfeyBMa12oI=;
        b=XvTisQbKJf6JAdluXTzqs70DgM/fKOtvNuivKg/gA2f+S932w34WXKsf6tM6n9xTlu
         WDneKUQYOarlnJwC0/AYjxw9caJDd2K9+aI33aSj46xF/Y2SPy270ydhBtS1T6ymB/4F
         GZo7F2OuTeHzLaA7DyIKYLRUjLBysoMrCpvZpYjrlO4wao5y/CopxDteSXtji4BTTrN0
         SChmwaD2CxHI1hhOq/i1Sp/H++LYJkVdJdebbVfp5z3YlvJ34DyH6QM+NqO2QGOZ1JQe
         XHzkljyeYcpQRtV4ZDi7yz/hb8L3adrQvhkQUAi3LaeX6FI4HOYLACuBQttvHjXcNhfW
         8dIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Ta27xDjNHXekNaDRZQc6cmIQAhodseI/zfeyBMa12oI=;
        b=ByrjWA8RCNCF2/ttC3qlbxM0Noa4VH9Oefy1CegW6ptmyHrZPGqI+U+HaXzr4q4FVs
         sGtaLInpnpibPxBW/sApZlPmuf5fjHwtdNVJWWkpnTpleI7efDggVm4gwM44CTHBkcwF
         C3juYeApu0ufsI4UBmnryM5XdGGbVq4fCXryYz4qVwbTVw5gxcgnGFODOqguZhQDjQ8v
         iVXzg5L5VrdmKh5OO8EGLo4kx1OFRRx3Rog34rXuauPeTDJgwmal7ji672j5COtIdWq0
         YUVtwOf1csPzuTswTrcfd/aiDw36pYEYO85mQTV446xCJyC42VYx7FiAjEECypeIO/bv
         +dBQ==
X-Gm-Message-State: ACrzQf1pOHxEtNBkKlk3wMOjw5yvRg8hqtcjWI+bv6mdxg1oJSn7ZbWH
	mvSEec6XBsEOrmnUf0Myc2RVlU9cMxP9Ah956ihTXUhD
X-Google-Smtp-Source: AMsMyM4M3eQ5mVK1BCrP4VKpJU86GvuQjJUR/fqJl4cQzuf9E6oD1/2l1Eex3GobJa++Mf6zdFKlatS0MvK3tXedDms=
X-Received: by 2002:a0d:f985:0:b0:370:72ad:bc17 with SMTP id
 j127-20020a0df985000000b0037072adbc17mr39477072ywf.233.1667891065840; Mon, 07
 Nov 2022 23:04:25 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
 
  
  
In-Reply-To: 
From: Archimedes Gaviola 
Date: Tue, 8 Nov 2022 15:03:59 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Warner Losh 
Cc: Mark Millard , freebsd-current 
Content-Type: multipart/alternative; boundary="00000000000080e6fd05ecf0267f"
X-Rspamd-Queue-Id: 4N5zcB56LZz3MQM
X-Spamd-Bar: ----
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];
	TAGGED_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--00000000000080e6fd05ecf0267f
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 8, 2022 at 11:29 AM Warner Losh  wrote:

>
>
> On Mon, Nov 7, 2022 at 7:40 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
>
>>
>>
>> On Sat, Nov 5, 2022 at 5:28 PM Archimedes Gaviola <
>> archimedes.gaviola@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Thu, Nov 3, 2022 at 7:52 AM Mark Millard  wrote:
>>>
>>>> On 2022-Nov-2, at 14:09, Archimedes Gaviola <
>>>> archimedes.gaviola@gmail.com> wrote:
>>>>
>>>> > On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <
>>>> archimedes.gaviola@gmail.com> wrote:
>>>> >
>>>> > . . .
>>>> >
>>>> > . . .
>>>> >
>>>> >
>>>> > Hi Mark,
>>>> >
>>>> > Just an update, as kernel and world compilation is ongoing with my
>>>> RPi3B system (with swap partition) is doing so far, so good. It already
>>>> surpassed the tough part that breaks the compilation process here.
>>>> > ...
>>>> >
>>>> > llvm-tblgen -gen-asm-matcher  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-asm-writer  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-callingconv  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-compress-inst-emitter  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-dag-isel  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-disassembler  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-global-isel  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-instr-info  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-emitter  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-pseudo-lowering  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-register-bank  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-register-info  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-searchable-tables  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-subtarget  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-searchable-tables  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> >
>>>> > Any thoughts why this part is quite a challenge when it comes to
>>>> memory usage? The other architectures do not possess such behavior... just
>>>> curious.
>>>>
>>>
>>> Hi Mark,
>>>
>>> Sorry for the late response, I got fully occupied at work for the past
>>> few days due to deliverables. Thanks for your feedback and further inputs!
>>>
>>>
>>>> I've not done any monitoring of buildworld buildkernel build
>>>> activity (RAM use, memory space use, swap partition use over
>>>> time) on RPi3B class hardware in a very long time.
>>>>
>>>
>>> It's alright, it so happened that I just observed that behavior on that
>>> particular part as it requires more memory than other architectures while
>>> compiling. The additional 3.5G swap partition really helps on that part
>>> that's why I was so happy that the compilation continued and never broke.
>>> Your input of having 3.5G swap allocation is very effective.
>>>
>>> Even on systems that I have monitored in more recent times,
>>>> what I usually monitor tends to be builds with -jN (such as
>>>> -j4 fora 4-hardware-thread system). (I once did have an
>>>> example of -j3 taking less time than -j4 on a RPi4B.
>>>>
>>>
>>> Wow, this is interesting this -jN. Let me explore this as well. I
>>> usually build kernel the old way but recently since I have to include
>>> building the world then I need to use the new way.
>>>
>>>
>>>> Basically, the memory subsystem can be saturated without all
>>>> the cores being in use. The extra interference made things
>>>> take longer.)
>>>>
>>>
>>> Oh I see so it's the reason.
>>>
>>>
>>>> You had listed that you were using the likes of:
>>>>
>>>> # cd /usr/src ; make KERNCONF=ARM TARGET_ARCH=aarch64 \
>>>> buildkernel buildworld installkernel installworld distribution \
>>>> DESTDIR=/home/freebsd/rpi3b
>>>>
>>>> I'll note that the standard order of the first 2 is:
>>>>
>>>> buildworld buildkernel
>>>>
>>>> This is because buildworld builds some software that
>>>> buildkernel does not build for itself but does use.
>>>>
>>>
>>> Okay this is noted, thanks for clarifying and correcting me, I really
>>> appreciate it. I'll reflect on the proper build sequence for much
>>> efficiency.
>>>
>>>
>>>> There is a kernel-toolchain target for avoiding the
>>>> need to do a full buildworld just to buildkernel , so:
>>>>
>>>> kernel-toolchain buildkernel
>>>>
>>>> is an expected sequence.
>>>>
>>>
>>> Okay I'll take note of this too.
>>>
>>>
>>>> I do not know how long a from-scratch buildworld
>>>> buildkernel without a -jN takes on a RPi3B these
>>>> days. If I remember right, for -jN with 1>>> saw claims about such they were somewhere in the
>>>> range 36hr..48hr.
>>>
>>>
>>> There's an ongoing build at the moment, it's already taking 41 hours
>>> since I started it. I took another build when I came back home from the
>>> office.
>>>
>>>
>>>> But I'm unsure of the specific N
>>>> that was in use. Nor do I know the storage media
>>>> type(s) involved, for example. I do not remember
>>>> any reports for -j1.
>>>>
>>>
>>> I'll try this with RPi 3B. The current build that I have will be my
>>> baseline.
>>>
>>> Use of the likes of: vm.pageout_oom_seq=120
>>>> was essential to such -jN usage on a RPi3B as N
>>>> gets larger. Of course, swap partition use for
>>>> paging was also essential.
>>>>
>>>
>>> Wow, that's great! I have this vm.pageout_oom_seq=120 configured in my
>>> system now based on your previous inputs.
>>>
>>> Likewise use of:
>>>>
>>>> vm.swap_enabled=0
>>>> vm.swap_idle_enabled=0
>>>>
>>>> can be important to not losing communication
>>>> with the RPi3B. Those last 2 are not tunable
>>>> but are writable:
>>>>
>>>> # sysctl -aT | grep swap_
>>>> # sysctl -aW | grep swap_
>>>> vm.swap_enabled: 0
>>>> . . .
>>>> vm.swap_idle_enabled: 0
>>>> . . .
>>>>
>>>> (This means that they have fewer places where
>>>> assignments can be made. For example, the
>>>> loader can not make the assignments.)
>>>>
>>>> By contrast, vm.pageout_oom_seq is both
>>>> writable and tunable:
>>>>
>>>> # sysctl -aW | grep oom
>>>> . . .
>>>> vm.pageout_oom_seq: 120
>>>> . . .
>>>>
>>>> # sysctl -aT | grep oom
>>>> . . .
>>>> vm.pageout_oom_seq: 120
>>>> . . .
>>>>
>>>> (So even the loader can make such assignments.)
>>>>
>>>
>>> Yes, I have these two sysctl parameters configured in the system. Thanks
>>> for the details and further inputs.
>>>
>>>
>>>> I'll note that I've no interest in using arm hardware
>>>> to build for other types of hardware. So I normally
>>>> have the targeting of support for building for other
>>>> architectures disabled when I build on aarch64 or
>>>> armv7. (Basically, a less complete clang/clang++
>>>> related toolchain ends up being built.)
>>>>
>>>
>>> Ah okay, so you mean to say that you disable these other architectures
>>> by declaring and accomplishing it in the /etc/src.conf?
>>>
>>> I'll provide an update here once the build is done knowing how long it
>>> takes to finish.
>>>
>>
>> Hi Mark,
>>
>> With this set of build commands now,
>>
>> # cd /usr/src; make -j3 KERNCONF=ARM TARGET_ARCH=aarch64 buildworld
>> kernel-toolchain buildkernel installworld installkernel distribution
>> DESTDIR=/home/freebsd/rpi3b
>>
>> in RPi 3B, I encountered the other OOM error which is the 'thread waited
>> too long to allocate a page'. This occurred from every build I conducted.
>> Though the first error on 'failed to reclaim memory' was never experienced
>> again. Below are the error logs.
>> ...
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 4096
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40960
>> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to
>> allocate a page
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192
>>
>
> This means that paging to the swap partition and/or swap file took too
> long (> 30 seconds... that's all that indefinite means). It also means that
> it can't write to backing store dirty pages to give to another process...
>
> Typical reason is that the disk / flash is not responsive to writes for
> some reason. You'll need to find why... I'd look at trims.
>
> Or.... if you can't change the disk... you need to put less memory
> pressure on it..
>

Hi Warner,

This is noted too, if the error persists I'll try replacing it with another
USB flash drive.

Thanks and best regards,
Archimedes


>
> Warner
>
> Perhaps some further tweaks are needed in the system so I set aside my RPi
>> 3B temporarily and switched over to my RPi 4B using the same microSD card
>> and USB flash drive (3.5 GB swap partition device) and the build completed
>> successfully. It took around 30 hours to complete. This RPi 4B has 2GB RAM
>> capacity while the RPi 3B has 1GB. From here, I'll continue looking further
>> for system tunables in RPi 3B which has lesser RAM capacity.
>>
>> Thanks and best regards,
>> Archimedes
>>
>>
>>
>>

--00000000000080e6fd05ecf0267f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Nov 8, 2022 at 11:29 AM Warne=
r Losh <imp@bsdimp.com> wrote:<=
br>


On Mon, Nov 7, 2022 at 7:40 PM Archimedes Gaviola <=
;archimed=
es.gaviola@gmail.com> wrote:


On Sat, Nov 5, 20=
22 at 5:28 PM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
=




On Thu, Nov =
3, 2022 at 7:52 AM Mark Millard <marklmi@yahoo.com> wrote:
On 2022-Nov-2, at 14:09, Archimedes Gaviol=
a <arc=
himedes.gaviola@gmail.com> wrote:



> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <archimedes.gaviola@gmail=
.com> wrote:

> 

> . . .

> 

> . . .

> 

> 

> Hi Mark,

> 

> Just an update, as kernel and world compilation is ongoing with my RPi=
3B system (with swap partition) is doing so far, so good. It already surpas=
sed the tough part that breaks the compilation process here.

> ...

> 

> llvm-tblgen -gen-asm-matcher=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc=C2=A0 /usr/src/contrib/l=
lvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-asm-writer=C2=A0 -I /usr/src/contrib/llvm-project/llv=
m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R=
ISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc=C2=A0 /usr/src/contrib/llvm=
-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-callingconv=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc=C2=A0 /usr/src/contrib=
/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-compress-inst-emitter=C2=A0 -I /usr/src/contrib/llvm-=
project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=
=C2=A0 -d RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.=
inc=C2=A0 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-dag-isel=C2=A0 -I /usr/src/contrib/llvm-project/llvm/=
include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RIS=
CVGenDAGISel.inc.d -o RISCVGenDAGISel.inc=C2=A0 /usr/src/contrib/llvm-proje=
ct/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-disassembler=C2=A0 -I /usr/src/contrib/llvm-project/l=
lvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d=
 RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc=C2=A0 /=
usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-global-isel=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc=C2=A0 /usr/src/contrib/l=
lvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-instr-info=C2=A0 -I /usr/src/contrib/llvm-project/llv=
m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R=
ISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc=C2=A0 /usr/src/contrib/llvm=
-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-emitter=C2=A0 -I /usr/src/contrib/llvm-project/llvm/i=
nclude -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RISC=
VGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc=C2=A0 /usr/src/contrib=
/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-pseudo-lowering=C2=A0 -I /usr/src/contrib/llvm-projec=
t/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0=
 -d RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc=C2=A0 /u=
sr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-bank=C2=A0 -I /usr/src/contrib/llvm-project/=
llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -=
d RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc=C2=A0 /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-info=C2=A0 -I /usr/src/contrib/llvm-project/=
llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -=
d RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc=C2=A0 /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=
=A0 -d RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc=C2=A0=
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-subtarget=C2=A0 -I /usr/src/contrib/llvm-project/llvm=
/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RI=
SCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc=C2=A0 /usr/src/contr=
ib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=
=A0 -d RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc=C2=A0 /us=
r/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> 

> Any thoughts why this part is quite a challenge when it comes to memor=
y usage? The other architectures do not possess such behavior... just curio=
us.

Hi Mark,

S=
orry for the late response, I got fully occupied at work for the past few d=
ays due to deliverables. Thanks for your feedback and further inputs!
=

=C2=A0

I've not done any monitoring of buildworld buildkernel build

activity (RAM use, memory space use, swap partition use over

time) on RPi3B class hardware in a very long time.
It's alright, it so happened that I just observed that beha=
vior on that particular part as it requires more memory than other architec=
tures while compiling. The additional 3.5G swap partition really helps on t=
hat part that's why I was so happy that the compilation continued and n=
ever broke. Your input of having 3.5G swap allocation is very effective.


Even on systems that I have monitored in more recent times,

what I usually monitor tends to be builds with -jN (such as

-j4 fora 4-hardware-thread system). (I once did have an

example of -j3 taking less time than -j4 on a RPi4B.
<=
br>
Wow, this is interesting this -jN. Let me explore this as wel=
l. I usually build kernel the old way but recently since I have to include =
building the world then I need to use the new way. 
=C2=A0

Basically, the memory subsystem can be saturated without all

the cores being in use. The extra interference made things

take longer.)

Oh I see so it's the =
reason.
=C2=A0

You had listed that you were using the likes of:



# cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64 \

buildkernel buildworld installkernel installworld distribution \

DESTDIR=3D/home/freebsd/rpi3b



I'll note that the standard order of the first 2 is:



buildworld buildkernel



This is because buildworld builds some software that

buildkernel does not build for itself but does use.
Okay this is noted, thanks for clarifying and correcting me, I=
 really appreciate it. I'll reflect on the proper build sequence for mu=
ch efficiency.
=C2=A0

There is a kernel-toolchain target for avoiding the

need to do a full buildworld just to buildkernel , so:



kernel-toolchain buildkernel



is an expected sequence.

Okay I'll =
take note of this too.
=C2=A0

I do not know how long a from-scratch buildworld

buildkernel without a -jN takes on a RPi3B these

days. If I remember right, for -jN with 1<N, I last

saw claims about such they were somewhere in the

range 36hr..48hr.

There's an ongoing bu=
ild at the moment, it's already taking 41 hours since I started it. I t=
ook another build when I came back home from the office.
=C2=
=A0
But I'm =
unsure of the specific N

that was in use. Nor do I know the storage media

type(s) involved, for example. I do not remember

any reports for -j1.

I'll try this =
with RPi 3B. The current build that I have will be my baseline.
<=
br>

Use of the likes of: vm.pageout_oom_seq=3D120

was essential to such -jN usage on a RPi3B as N

gets larger. Of course, swap partition use for

paging was also essential.

Wow, that=
9;s great! I have this=20
vm.pageout_oom_seq=3D120 configured in my system now based on your previous=
 inputs.


Likewise use of:



vm.swap_enabled=3D0

vm.swap_idle_enabled=3D0



can be important to not losing communication

with the RPi3B. Those last 2 are not tunable

but are writable:



# sysctl -aT | grep swap_

# sysctl -aW | grep swap_

vm.swap_enabled: 0

. . .

vm.swap_idle_enabled: 0

. . .



(This means that they have fewer places where

assignments can be made. For example, the

loader can not make the assignments.)



By contrast, vm.pageout_oom_seq is both

writable and tunable:



# sysctl -aW | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



# sysctl -aT | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



(So even the loader can make such assignments.)

Yes, I have these two sysctl parameters configured in the system. =
Thanks for the details and further inputs.
=C2=A0 
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
I'll note that I've no interest in using arm hardware

to build for other types of hardware. So I normally

have the targeting of support for building for other

architectures disabled when I build on aarch64 or

armv7. (Basically, a less complete clang/clang++

related toolchain ends up being built.)

Ah okay, so you mean to say that you disable these other architectures by =
declaring and accomplishing it in the /etc/src.conf?

I'll provide an update here once the build is done knowing how long =
it takes to finish.

=

Hi Mark,
<=
br>
With this set of build commands now,

# cd /us=
r/src; make -j3 KERNCONF=3DARM TARGET_ARCH=3Daarch64 buildworld kernel-tool=
chain buildkernel installworld installkernel distribution DESTDIR=3D/home/f=
reebsd/rpi3b

in RPi 3B, I encountered the other OOM error which is the 'threa=
d waited too long to allocate a page'. This occurred from every build I=
 conducted. Though the first error on 'failed to reclaim memory' wa=
s never experienced again. Below are the error logs.
...
swap_pager: indefinit=
e wait buffer: bufobj: 0, blkno: 256929, size: 4096
swap_pager: indefini=
te wait buffer: bufobj: 0, blkno: 3628, size: 4096
swap_pager: indefinit=
e wait buffer: bufobj: 0, blkno: 255839, size: 40960
pid 46153 (c++), ji=
d 0, uid 0, was killed: a thread waited too long to allocate a page
swap=
_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
sw=
ap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
swa=
p_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
sw=
ap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192

This means that paging to the swap =
partition and/or swap file took too long (> 30 seconds... that's all=
 that indefinite means). It also means that it can't write to backing s=
tore dirty pages to give to another process...

Typ=
ical reason is that the disk / flash is not responsive to writes for some r=
eason. You'll need to find why... I'd look at trims.

=

Or.... if you can't change the disk... you need to put less =
memory pressure on it..

H=
i Warner,

This is noted too, if the error persists=
 I'll try replacing it with another USB flash drive.

=

Thanks and best regards,
Archimedes
=C2=
=A0

Warner

Perhaps some further tweaks are needed in the system=
 so I set aside my RPi 3B temporarily and switched over to my RPi 4B using =
the same microSD card and USB flash drive (3.5 GB swap partition device) an=
d the build completed successfully. It took around 30 hours to complete. Th=
is RPi 4B has 2GB RAM capacity while the RPi 3B has 1GB. From here, I'l=
l continue looking further for system tunables in RPi 3B which has lesser R=
AM capacity.

Thanks and best regards,
Archimedes =


<=
br>







--00000000000080e6fd05ecf0267f--

From nobody Tue Nov  8 07:15:30 2022
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 4N5zsT4xptz4gcqD
	for ; Tue,  8 Nov 2022 07:15:57 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N5zsT38Wqz3Pts
	for ; Tue,  8 Nov 2022 07:15:57 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-36cbcda2157so125760327b3.11
        for ; Mon, 07 Nov 2022 23:15:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=TZ6yQLoK7oFoICL4VB2EMFNiWktGMA0NhjpWA9MGNPA=;
        b=ZR/8ZtFi+BdFRIfZ/NA57k9D/V4Tf/wduSWrnvogjeQ1swFzD/W/jxR0jprEO8gFd6
         sgiRH51dvXPqggj1Fxbqbaj5neBQmXZv+bv/sTlg/MKkQhjUObqTIWnSpOOUdsksVtGz
         H3jeSkL7D/w6rzsrAQ/crAyTbe+78eh+KQrNzJEew0X3nFnGdBofotNfbiWUGb0tYBKf
         aWAuurvmvDesCOTVDEGUlolbR0252OemwbtFX23OQxZW3Z73D1wkmLHuGhP13xWRYO3X
         NaXCCGZNc2a+bMafDrbmZqj8G14l1NV8bc6AeAanGA8dj8ePM7/As0cl33VEwWox00x3
         EL9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=TZ6yQLoK7oFoICL4VB2EMFNiWktGMA0NhjpWA9MGNPA=;
        b=eTq821/KEWmWg1QqVVfqEKsRadgBOzIVXxmT8kWqkipUZaCqwJnQPBVAnNvcU4qv0A
         r86b3FvvfsQsI+kbtgAOsgVsnW76yzhPTAbaGrYORq/h5uR1V5z2dl8pI1XkhGcYXUEM
         UFRfskPwdi6vL3M51RPr/4oDRCYm5CtNyzbRucKMgiHO+wC2Fq6PysFD8Nfdcvewq+jc
         0XBKphMA5WJ5RBAabBHrUTbDEDuKdFBbRjU0wVDaly0ObcznsCSRqA5wRV1GGFq9r2Fo
         +ineTXQFh2lVCHb3f+4NxAFztdtSSFf6vgL9Mx1sOA4C07k3L/HWFyEbdGeak0CYJfQm
         xJUw==
X-Gm-Message-State: ACrzQf1Ho8fKBjV7CUkWsS+TLYrQzc7p/xki8dr9PXlIIbJ7/Gfg7x6S
	w/oSGOMbw53PYbBp2+TDRLxsorO67Co2+rEA5Y8=
X-Google-Smtp-Source: AMsMyM6X/iQeK36HkpzdKtZDtNwhDl4JoZ6o+pCpFs2vRvb81EmyzhUTTtVlsUKMMCsiZ1ELh66ddxU+ojsxqyGQrXc=
X-Received: by 2002:a81:4656:0:b0:367:6daf:84e4 with SMTP id
 t83-20020a814656000000b003676daf84e4mr50773260ywa.481.1667891756589; Mon, 07
 Nov 2022 23:15:56 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
 
  
 
  <788B97E7-AA06-4A87-BB4A-CF2602DC1AD3@yahoo.com>
In-Reply-To: <788B97E7-AA06-4A87-BB4A-CF2602DC1AD3@yahoo.com>
From: Archimedes Gaviola 
Date: Tue, 8 Nov 2022 15:15:30 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Mark Millard 
Cc: Warner Losh , freebsd-current 
Content-Type: multipart/alternative; boundary="000000000000ace67e05ecf04f5b"
X-Rspamd-Queue-Id: 4N5zsT38Wqz3Pts
X-Spamd-Bar: ----
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:2607:f8b0::/32, country:US]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000ace67e05ecf04f5b
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 8, 2022 at 11:53 AM Mark Millard  wrote:

> On Nov 7, 2022, at 19:28, Warner Losh  wrote:
> >
> > . . .
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40960
> > pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to
> allocate a page
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192
> >
> > This means that paging to the swap partition and/or swap file took too
> long (> 30 seconds... that's all that indefinite means).
>
> FYI: I think the "indefinite wait buffer" bound that leads
> to those messages is 20 sec (the hz*20 below):
>
>         /*
>          * Wait for the pages we want to complete.  VPO_SWAPINPROG is
> always
>          * cleared on completion.  If an I/O error occurs, SWAPBLK_NONE
>          * is set in the metadata for each page in the request.
>          */
>         VM_OBJECT_WLOCK(object);
>         /* This could be implemented more efficiently with aflags */
>         while ((ma[0]->oflags & VPO_SWAPINPROG) != 0) {
>                 ma[0]->oflags |= VPO_SWAPSLEEP;
>                 VM_CNT_INC(v_intrans);
>                 if (VM_OBJECT_SLEEP(object, &object->handle, PSWP,
>                     "swread", hz * 20)) {
>                         printf(
> "swap_pager: indefinite wait buffer: bufobj: %p, blkno: %jd, size: %ld\n",
>                             bp->b_bufobj, (intmax_t)bp->b_blkno,
> bp->b_bcount);
>                 }
>         }
>         VM_OBJECT_WUNLOCK(object);
>
> But the "was killed: a thread waited too long to allocate a page" is
> tied to a total of 30 sec (3*10sec) from:
>
> vm.pfault_oom_attempts= 3
> vm.pfault_oom_wait= 10
>
> (Presuming that you had defaults at the time.)
>

Confirming the default values.

root@generic:~ # sysctl -a | grep pfault_oom
vm.pfault_oom_wait: 10
vm.pfault_oom_attempts: 3


>
> > It also means that it can't write to backing store dirty pages to give
> to another process...
> >
> > Typical reason is that the disk / flash is not responsive to writes for
> some reason. You'll need to find why... I'd look at trims.
> >
> > Or.... if you can't change the disk... you need to put less memory
> pressure on it..
>
>
>
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>

--000000000000ace67e05ecf04f5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Nov 8, 2022 at 11:53 AM Mark =
Millard <marklmi@yahoo.com> =
wrote:
On Nov 7,=
 2022, at 19:28, Warner Losh <imp@bsdimp.com> wrote:

> 

> . . .

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 40=
96

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096=


> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40=
960

> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to=
 allocate a page

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28=
672

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192=


> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 40=
96

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 81=
92

> 

> This means that paging to the swap partition and/or swap file took too=
 long (> 30 seconds... that's all that indefinite means).



FYI: I think the "indefinite wait buffer" bound that leads

to those messages is 20 sec (the hz*20 below):



=C2=A0 =C2=A0 =C2=A0 =C2=A0 /*

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Wait for the pages we want to complete.=
=C2=A0 VPO_SWAPINPROG is always

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* cleared on completion.=C2=A0 If an I/O =
error occurs, SWAPBLK_NONE

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* is set in the metadata for each page in=
 the request.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 VM_OBJECT_WLOCK(object);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* This could be implemented more efficiently w=
ith aflags */

=C2=A0 =C2=A0 =C2=A0 =C2=A0 while ((ma[0]->oflags & VPO_SWAPINPROG) =
!=3D 0) {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ma[0]->oflags |=
=3D VPO_SWAPSLEEP;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VM_CNT_INC(v_intran=
s);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (VM_OBJECT_SLEEP=
(object, &object->handle, PSWP,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
;swread", hz * 20)) {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 printf(

"swap_pager: indefinite wait buffer: bufobj: %p, blkno: %jd, size: %ld=
\n",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 bp->b_bufobj, (intmax_t)bp->b_blkno, bp->=
b_bcount);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 VM_OBJECT_WUNLOCK(object);



But the "was killed: a thread waited too long to allocate a page"=
 is

tied to a total of 30 sec (3*10sec) from:



vm.pfault_oom_attempts=3D 3

vm.pfault_oom_wait=3D 10



(Presuming that you had defaults at the time.)

Confirming the default values.

root@generi=
c:~ # sysctl -a | grep pfault_oom
vm.pfault_oom_wait: 10
vm.pfault_oo=
m_attempts: 3
=C2=A0



> It also means that it can't write to backing store dirty pages to =
give to another process...

> 

> Typical reason is that the disk / flash is not responsive to writes fo=
r some reason. You'll need to find why... I'd look at trims.

> 

> Or.... if you can't change the disk... you need to put less memory=
 pressure on it..











=3D=3D=3D

Mark Millard

marklmi at yahoo.com






--000000000000ace67e05ecf04f5b--

From nobody Tue Nov  8 07:16:33 2022
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 4N5ztb141Rz4gdBf
	for ; Tue,  8 Nov 2022 07:16:55 +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 4N5ztZ0rjqz3R1d
	for ; Tue,  8 Nov 2022 07:16:54 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=pxb38J+v;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667891812; bh=PoRPq0wSfPuku/AH6cS3BJ/iVW7cKrPGDtevN6NuUBw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pxb38J+vZtAXJLPVONFEyFtFBtxKL5wPDqYOPz6xjMcfMZFJ2ajAOexq40mypAJLuS6+fL1yEWXHhiIHRH1qPCXfGqtJ0eaL9LazL2KFf7BgFheuaLwGnghZHzk/y3sFasGfjvNLQnVnsf9RHXwOxzT6PlE9jQuYe6zF5etC90hpo/Utqz/VY5j6ejiBug1zfmx93x6EIFp6TcL1uoOuFANlVsK6wnY7hPSOI/PK70F8I8XMCuK+Sz6zhJmJB/kq6z5FwV3WgetNzOB32y7iDaeNPMZUh81C8VODwKjfrhEZHOEDnfkDLGZegH8DO1Qb8tw7cVAifCtuv+92DbA/RA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667891812; bh=hNxe32SNww2/s8o5P6ahiByGDVtYjenDIF6PQZ+I6/z=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iH6qVg8NC4gbaSBhbZ6AAEhdo+je5jYilIgVW2c1VmMjD8ZAcvkifShdtkesrs8M6zzh6rTHaIUo7bSTfL1KVz0fEKVAhHrgXL+xRowf6EDW5ShNYEz+H9wbZ+D6d9k1iYknEoTJmRbH4FuEljhnezqoOR03pE7+AHLoJvko7qlQTG5v5JLkzxKin3RgwIbuo0zCwOiSZCrHaOTBAmZHdJpHk+q5paPIa+RBnk9bep2dvAYPWG/p26KCEA9u+fsstduU5pmK3wP1areeLHbPfz1DEzDV+szhV1FewxNkfCCHCyXBEde4gjGpRerVfi7yBc4vDarE6lrhHjl4VO7gBw==
X-YMail-OSG: sNez_jEVM1lYD_p1CPFC9jrOKAT66TM34h3ZdtNcAYf7PHkxA58QZ9WGbQSYSTs
 XUPNbpJFvUnmMCEGpv1K5rLli_zn3Cgq9k0UMgeZnm9NRIR13SNNMl477TSVjZ.CNqeXh6Q75ZCl
 WRXZOk2xbSIQ5QvRdw6yk_8FHE4lbURVQOMPniwsyx_XpbpgviwpHgidhWxKtISWSGDkicu0Oc7e
 n195Gfo6E3BniDdeVVeI3lr5Mw6kZKm1f9WzQE.JwWF8_sf8aGI37fZ_Il.O2qNtmwPQQsLN8onK
 B4.9ZQrqGWdPHZjMy1oXsYQ6CXc6haps3Oa2dN08RbU2Lg4f3ieQcUwK_AWA186W9.4BTYNoHzTt
 75IrPxi6xjTdgvR7EJCpJLClrXO9w_PG3HIw.Ky2KSHYDEq_ztN_ww6ZBwTo1U_30lZH0LYzmx06
 Pi2GZEKRj1G9Q.3qoUdNpdJ1sKI3ZdzX2p1TyUXVLzfK3KREBb5.zdxj1C3gq5trDX_t8K.pEWeR
 YE6gujUzB.s9o2nFqhGFiiezlDPcpachqD1wGqQFULVm1QWB0PkZ.hAe_TAVaesxs1np8HFLOlPs
 WmiNlkAfHvxnjpneDiGFk.t0EFkbn0.JalGBd7rMUDymqrkxbC1oMwUa1U_LvyLOmOsucBQrcMgY
 .51SKovacvRluMqb92vQ.LUm0gKOBjGF4kNAW9bWg2Py323CA_8Zd5bB283ZAPwtVAxuvwTRoT_G
 R7UP4K4ya3hEvbx9M2VE5ZwOwnrTU8sVXYlhpJX9psLj30OXgSi4maDaU9EOHrv0qGrzVM9brEb9
 h3lVOrTAU_bwIaxjtVTcZnZE_WaejXQVQI6b6xL04AJbgtJgHgoYGEOy7bSEK20R0vBVuPo9IuyT
 wZeTIjLcYhIUDI0ecDraObbfV4WKvITulR259eoFQe2lYEwFiaQ51X92neLIax_HL9bJHxcz09rO
 wj2hkly2qegMCmDhLhWpP7zPFCJEdzAxcxMsnESEv2co2KK2zpf5RvRgsHQuV3OQod2LxcZGSquh
 3QHs6O6fh5oIn3IBgyHttdUd1kfg0X0JfW0ulgSna_flKrED7uLxJ8biJxnPoggDNUTKfTS32pYQ
 x8hbEmrwX1iaIoprOEvkzw7KclwkYoB7Hs5D8k7IeZn047mljnUZbeYQ1hqYfwrTNVSL.bu_VQjp
 nR890e6NBF3Oj6yG4jMKq43DNXnafkjxYAdfYtkq1lDMMdYRVSFXp0GemcGFVUgkl90ySWjbA0uY
 tDgvPPRVS2bkTUBykK.qdpCICD5OAi73Ngxo0ZWnRGS342UWPMjmjp0KjbWiv1qFyv0883hBLYxl
 _pII6Xcjgwk6neEa2_OcpNa6OGMtB6Dr.DJyDX0UiE9u_K1ngzmUNfmcHphwO3t63jdexPrnWHr4
 ASTdjLx7V0nAC6fVpwZSfsbU7gry3up0EVlSaSZ2bGzQjokGCMVJbtXlbDqJ5bpzfF3ncvuY9laP
 _BOTwulMwOy7o_OCYse4QmAQO1PbJBrv3YkXo3z_YEn7FW5kD89Ty8ZkCYDCuMZXkpe1ES1.S8fN
 cGxKmgG1CY1DRkZoBBRN4QijiCphsSDi9JFlfgV1Xg3sET4PMG6cuQ1rdblefkgBtjCbQxJsOXCy
 BGFEj0x_LfwMWNEUmp0j.IF2370UpJHJOX5EOgZidmCwymi8x6tBcSAXNkhnLA6iSy_qoJqtZIZd
 nsa.0EeQka6H21rjhv6Kvtizu09lRFfGedR4fps6ajQe3eB00M3YkTf8HmJmleQsGbIZU0VaQbNo
 oUvhus6Ux5wVXUrQtOPXkqziEeBvr1of.z3AI8laFnB8bFZaS.eIERrwYesw.BxH.ng5bA9PSRRh
 slvDoxwlCDEP3apGpr7mp.qg41GyKt9UBJi_zxPNGmrTK_Rq.AgcSVcAlB30oQnelCOMXOtrIRk3
 k2JkcH1Kr.wvaWEFvZekHQKqPJsqbtj4kPWGQJoxSvaPCEDQ0IWn7_lRna5jtoMKGxeYenyGQE6a
 HVGOsaKRQc7C9QvOevt0YNQIXXNaj6Emsq69dhSig0YoN7J2s56RmIDrv.lUOGCXimIwAj5FJffb
 z_Fb68I3E6QQu6S0MxFr4zyf4RdyExapIdaWtObRUN9K.H2vs_w2nYn05.sI86GXXWTVvnmw4X75
 VAWJ5mZ_1sgHNKmcqJFUn0UtxO1SXA.2IGhl0Rtm68rYO2RPDcREbOOgoRdr9wPSNKv_0q.QSjTR
 pM1vU9j3k4tBoMB9rAZzLeeswalqv3b8_D_8l_GO9jekV_xFCe.fAEVBevQCAoe4lAGqoyQCiSML
 E
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Nov 2022 07:16:52 +0000
Received: by hermes--production-bf1-5878955b5f-d26fx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7cd0d4c2b2518068140815b23585b68a;
          Tue, 08 Nov 2022 07:16:45 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
From: Mark Millard 
In-Reply-To: 
Date: Mon, 7 Nov 2022 23:16:33 -0800
Cc: freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: <42F8289D-B144-44CB-AAB7-E53587F193E3@yahoo.com>
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
 
 
 
 
 
 
 
 
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N5ztZ0rjqz3R1d
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TAGGED_RCPT(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]
X-ThisMailContainsUnwantedMimeParts: N

On Nov 7, 2022, at 22:50, Archimedes Gaviola =
 wrote:

> . . .
> =20
>=20
>> # sysctl -W vm.pfault_oom_attempts
>> vm.pfault_oom_attempts: -1
>>=20
>> # sysctl -W vm.pfault_oom_wait
>> vm.pfault_oom_wait: 10

FYI: the -W just limits the command to writable cases.
If the text is not a writable, it will not get a line of output.

> root@generic:~ # sysctl -T vm.pfault_oom_attempts
> vm.pfault_oom_attempts: -1
>=20
> root@generic:~ # sysctl -T vm.pfault_oom_wait
> vm.pfault_oom_wait: 10

FYI: the -T just limits the command to loader tunable cases.
If the text is not loader tunable, it will not get a line of output.

If both -T and -W list the output line, then it is both
loader-tunable and writable. The values will be the same.

I use the -T and -W to discover/report the loader-tunable vs.
writable vs. both status (2 commands). Otherwise the -T and
-W are not necessary on the command lines.


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


From nobody Tue Nov  8 07:27:46 2022
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 4N607f1fnnz4gfFY
	for ; Tue,  8 Nov 2022 07:28:14 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N607d5PPzz3SJb
	for ; Tue,  8 Nov 2022 07:28:13 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-yb1-xb2e.google.com with SMTP id k13so12568789ybk.2
        for ; Mon, 07 Nov 2022 23:28:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=vdKPP9SK1L6oj91k/XxxNDPZ55JqjKjfH1XxYCbE1xA=;
        b=TPe4JKp4fnUVPGlvwc5wGK8BcIAxPbAnWnHegv3sE8zFC2NL9s7UGxAXJDQLO7MTUm
         fb4uHlWAPIjic/r8j/MZg2xYi8li6IoZCQjTjy3OrvWouIbCGSlr3JqWb+xEHBkzgjOj
         UWv0UY/6mjJLKu8oG8pLJ4i9v0klzoPUJ/mv+FxnrJFUqgMJUkq0uMDFhlZvTUM7piXY
         JyvjtUOIMw9/OoCErtuB0MsQgebv9BbTb1TADiZc07NERknTCv9MdcTHKhrZgtpsfTSl
         P3V7oVuqOthEgk+O21YJYB0HYyhKhiHeqVLjXpq/lZwUsh95EohrooS42aHjJVs/sAiA
         YjMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=vdKPP9SK1L6oj91k/XxxNDPZ55JqjKjfH1XxYCbE1xA=;
        b=FRGUymrkj9F8lLFG6Vj9FgIOQMdmcVFCUqr6cnnT93fNW/jpgWCCJ5F3i5YC5U+GwK
         AVJPoU6NFB6jtKVE9NHcLVITlYMiHCOUotctlWEitgQX4rnyVhyz4702LhBS7WJomMKN
         aEK1T3stidivQmIxhb17XfC+ZDOuvxjA2TnW7Oz2PBdLbtjN2ontZHxrXetjbza31cS3
         teCSjgiw4sCkRG2MAziVEXKRCaUjhotgGtlhayHV1zEPLlY1+pbkVkM+HZsJku0BhUqQ
         6Lu3wFYyGtgTztBK9Sw0yyd7xcKyZNFJGoUusuWveGYSVEOpGCR/0l6Cg02GsCdA7ELK
         0aIg==
X-Gm-Message-State: ACrzQf2oGiZEvO3+cDC4ZhLVmVPSvJUE2vzcIiM0Wc3KphpszZsLGTvb
	yc0v/m1e0QGON7qGyXXNpaa60FS1alt42NcNxMM=
X-Google-Smtp-Source: AMsMyM44eZZN9bCBYDI08Q/yoWVlmRuV0ItQOj5AxLzo0Iew3Cpkj4Ums98ZG8UqTZqUqz3NpjrywUO4bXYLzG8naHY=
X-Received: by 2002:a25:3f86:0:b0:6bc:998:873e with SMTP id
 m128-20020a253f86000000b006bc0998873emr54372384yba.152.1667892492567; Mon, 07
 Nov 2022 23:28:12 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
 
  
 
  
 <42F8289D-B144-44CB-AAB7-E53587F193E3@yahoo.com>
In-Reply-To: <42F8289D-B144-44CB-AAB7-E53587F193E3@yahoo.com>
From: Archimedes Gaviola 
Date: Tue, 8 Nov 2022 15:27:46 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Mark Millard 
Cc: freebsd-current 
Content-Type: multipart/alternative; boundary="0000000000008b096d05ecf07b42"
X-Rspamd-Queue-Id: 4N607d5PPzz3SJb
X-Spamd-Bar: ----
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];
	TAGGED_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000008b096d05ecf07b42
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 8, 2022 at 3:16 PM Mark Millard  wrote:

> On Nov 7, 2022, at 22:50, Archimedes Gaviola 
> wrote:
>
> > . . .
> >
> >
> >> # sysctl -W vm.pfault_oom_attempts
> >> vm.pfault_oom_attempts: -1
> >>
> >> # sysctl -W vm.pfault_oom_wait
> >> vm.pfault_oom_wait: 10
>
> FYI: the -W just limits the command to writable cases.
> If the text is not a writable, it will not get a line of output.
>
> > root@generic:~ # sysctl -T vm.pfault_oom_attempts
> > vm.pfault_oom_attempts: -1
> >
> > root@generic:~ # sysctl -T vm.pfault_oom_wait
> > vm.pfault_oom_wait: 10
>
> FYI: the -T just limits the command to loader tunable cases.
> If the text is not loader tunable, it will not get a line of output.
>
> If both -T and -W list the output line, then it is both
> loader-tunable and writable. The values will be the same.
>
> I use the -T and -W to discover/report the loader-tunable vs.
> writable vs. both status (2 commands). Otherwise the -T and
> -W are not necessary on the command lines.
>

This is well noted Mark, thanks for the detailed guide!


>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>

--0000000000008b096d05ecf07b42
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Nov 8, 2022 at 3:16 PM Mark M=
illard <marklmi@yahoo.com> w=
rote:
On Nov 7, =
2022, at 22:50, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:


> . . .

>=C2=A0 

> 

>> # sysctl -W vm.pfault_oom_attempts

>> vm.pfault_oom_attempts: -1

>> 

>> # sysctl -W vm.pfault_oom_wait

>> vm.pfault_oom_wait: 10



FYI: the -W just limits the command to writable cases.

If the text is not a writable, it will not get a line of output.



> root@generic:~ # sysctl -T vm.pfault_oom_attempts

> vm.pfault_oom_attempts: -1

> 

> root@generic:~ # sysctl -T vm.pfault_oom_wait

> vm.pfault_oom_wait: 10



FYI: the -T just limits the command to loader tunable cases.

If the text is not loader tunable, it will not get a line of output.



If both -T and -W list the output line, then it is both

loader-tunable and writable. The values will be the same.



I use the -T and -W to discover/report the loader-tunable vs.

writable vs. both status (2 commands). Otherwise the -T and

-W are not necessary on the command lines.

<=
div>This is well noted Mark, thanks for the detailed guide!
=C2=
=A0





=3D=3D=3D

Mark Millard

marklmi at yahoo.com






--0000000000008b096d05ecf07b42--

From nobody Tue Nov  8 12:15:06 2022
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 4N66Vh2cNhz4V6FQ
	for ; Tue,  8 Nov 2022 12:15:08 +0000 (UTC)
	(envelope-from SRS0=V+t4=3I=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 4N66Vh15nVz4JCC
	for ; Tue,  8 Nov 2022 12:15:08 +0000 (UTC)
	(envelope-from SRS0=V+t4=3I=klop.ws=ronald-lists@realworks.nl)
Authentication-Results: mx1.freebsd.org;
	none
Date: Tue, 8 Nov 2022 13:15:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2;
	t=1667909706;
	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=Okkcd7+R5Wq4wvKCBqvib9qeBA7wksCuFbObbHRrh1w=;
	b=L9FbFmrI/4JnK/2VLo1zZQD2CBy0wraTl1lY63TyzTMhOTWrA9jVt2sLgKdS8EUIEiDHc5
	7eZd0G4rOUauN/BKQ/OtsSvV4pwY8OzzfVpcix3NFxdfQYS2JlHPzuyYW6GC52OyiVkEXm
	kroyp0jV4xkvpWB8UIhu8fnLI1x5CMO0klTo+QPhe3scEbC0IzFJybohjhNcFYp3JEx6pw
	iQBmQkPrnGlpIldMqRLRVmrF7RfYj4XVbf2QWC+C5tTbI18ZwNKJ3leMa0cIGivVqZ4/Zl
	roP8rtLJl4osaCMq6xpvvR8kf753OjveOqTEm4nNj+8pN/7DkUrKsyDkIQtxMA==
From: Ronald Klop 
To: Archimedes Gaviola ,
	Warner Losh 
Cc: Mark Millard ,
	freebsd-current 
Message-ID: <1722758786.127406.1667909706281@localhost>
In-Reply-To: 
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
 
 
 
 
 
 
 
 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
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_127405_1504264931.1667909706277"
X-Mailer: Realworks (630.39)
Importance: Normal
X-Priority: 3 (Normal)
X-Rspamd-Queue-Id: 4N66Vh15nVz4JCC
X-Spamd-Bar: ----
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:3265, ipnet:194.109.0.0/16, country:NL];
	TAGGED_RCPT(0.00)[];
	TAGGED_FROM(0.00)[t4=3I=klop.ws=ronald-lists]
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_127405_1504264931.1667909706277
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 
Van: Warner Losh 
Datum: dinsdag, 8 november 2022 04:28
Aan: Archimedes Gaviola 
CC: Mark Millard , freebsd-current 
Onderwerp: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
> 
>  
>  
> On Mon, Nov 7, 2022 at 7:40 PM Archimedes Gaviola  wrote:
>> 
>>  
>>  
>> On Sat, Nov 5, 2022 at 5:28 PM Archimedes Gaviola  wrote:
>>> 
>>>  
>>>  
>>>  
>>> On Thu, Nov 3, 2022 at 7:52 AM Mark Millard  wrote:
>>>> On 2022-Nov-2, at 14:09, Archimedes Gaviola  wrote:
>>>> 
>>>> > On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola  wrote:
>>>> >
>>>> > . . .
>>>> >
>>>> > . . .
>>>> >
>>>> >
>>>> > Hi Mark,
>>>> >
>>>> > Just an update, as kernel and world compilation is ongoing with my RPi3B system (with swap partition) is doing so far, so good. It already surpassed the tough part that breaks the compilation process here.
>>>> > ...
>>>> >
>>>> > llvm-tblgen -gen-asm-matcher  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-asm-writer  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-callingconv  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-compress-inst-emitter  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-dag-isel  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-disassembler  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-global-isel  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-instr-info  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-emitter  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-pseudo-lowering  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-register-bank  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-register-info  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-searchable-tables  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-subtarget  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-searchable-tables  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> >
>>>> > Any thoughts why this part is quite a challenge when it comes to memory usage? The other architectures do not possess such behavior... just curious.>>> 
>>>  
>>> Hi Mark,
>>>  
>>> Sorry for the late response, I got fully occupied at work for the past few days due to deliverables. Thanks for your feedback and further inputs!
>>>  
>>>> I've not done any monitoring of buildworld buildkernel build
>>>> activity (RAM use, memory space use, swap partition use over
>>>> time) on RPi3B class hardware in a very long time.>>> 
>>>  
>>> It's alright, it so happened that I just observed that behavior on that particular part as it requires more memory than other architectures while compiling. The additional 3.5G swap partition really helps on that part that's why I was so happy that the compilation continued and never broke. Your input of having 3.5G swap allocation is very effective.
>>>  
>>>> Even on systems that I have monitored in more recent times,
>>>> what I usually monitor tends to be builds with -jN (such as
>>>> -j4 fora 4-hardware-thread system). (I once did have an
>>>> example of -j3 taking less time than -j4 on a RPi4B.>>> 
>>>  
>>> Wow, this is interesting this -jN. Let me explore this as well. I usually build kernel the old way but recently since I have to include building the world then I need to use the new way.
>>>  
>>>> Basically, the memory subsystem can be saturated without all
>>>> the cores being in use. The extra interference made things
>>>> take longer.)>>> 
>>>  
>>> Oh I see so it's the reason.
>>>  
>>>> You had listed that you were using the likes of:
>>>> 
>>>> # cd /usr/src ; make KERNCONF=ARM TARGET_ARCH=aarch64 \
>>>> buildkernel buildworld installkernel installworld distribution \
>>>> DESTDIR=/home/freebsd/rpi3b
>>>> 
>>>> I'll note that the standard order of the first 2 is:
>>>> 
>>>> buildworld buildkernel
>>>> 
>>>> This is because buildworld builds some software that
>>>> buildkernel does not build for itself but does use.>>> 
>>>  
>>> Okay this is noted, thanks for clarifying and correcting me, I really appreciate it. I'll reflect on the proper build sequence for much efficiency.
>>>  
>>>> There is a kernel-toolchain target for avoiding the
>>>> need to do a full buildworld just to buildkernel , so:
>>>> 
>>>> kernel-toolchain buildkernel
>>>> 
>>>> is an expected sequence.>>> 
>>>  
>>> Okay I'll take note of this too.
>>>  
>>>> I do not know how long a from-scratch buildworld
>>>> buildkernel without a -jN takes on a RPi3B these
>>>> days. If I remember right, for -jN with 1>>> saw claims about such they were somewhere in the
>>>> range 36hr..48hr.>>> 
>>>  
>>> There's an ongoing build at the moment, it's already taking 41 hours since I started it. I took another build when I came back home from the office.
>>>  
>>>> But I'm unsure of the specific N
>>>> that was in use. Nor do I know the storage media
>>>> type(s) involved, for example. I do not remember
>>>> any reports for -j1.>>> 
>>>  
>>> I'll try this with RPi 3B. The current build that I have will be my baseline.
>>>  
>>>> Use of the likes of: vm.pageout_oom_seq=120
>>>> was essential to such -jN usage on a RPi3B as N
>>>> gets larger. Of course, swap partition use for
>>>> paging was also essential.>>> 
>>>  
>>> Wow, that's great! I have this vm.pageout_oom_seq=120 configured in my system now based on your previous inputs.
>>>  
>>>> Likewise use of:
>>>> 
>>>> vm.swap_enabled=0
>>>> vm.swap_idle_enabled=0
>>>> 
>>>> can be important to not losing communication
>>>> with the RPi3B. Those last 2 are not tunable
>>>> but are writable:
>>>> 
>>>> # sysctl -aT | grep swap_
>>>> # sysctl -aW | grep swap_
>>>> vm.swap_enabled: 0
>>>> . . .
>>>> vm.swap_idle_enabled: 0
>>>> . . .
>>>> 
>>>> (This means that they have fewer places where
>>>> assignments can be made. For example, the
>>>> loader can not make the assignments.)
>>>> 
>>>> By contrast, vm.pageout_oom_seq is both
>>>> writable and tunable:
>>>> 
>>>> # sysctl -aW | grep oom
>>>> . . .
>>>> vm.pageout_oom_seq: 120
>>>> . . .
>>>> 
>>>> # sysctl -aT | grep oom
>>>> . . .
>>>> vm.pageout_oom_seq: 120
>>>> . . .
>>>> 
>>>> (So even the loader can make such assignments.)>>> 
>>>  
>>> Yes, I have these two sysctl parameters configured in the system. Thanks for the details and further inputs.
>>>  
>>>> I'll note that I've no interest in using arm hardware
>>>> to build for other types of hardware. So I normally
>>>> have the targeting of support for building for other
>>>> architectures disabled when I build on aarch64 or
>>>> armv7. (Basically, a less complete clang/clang++
>>>> related toolchain ends up being built.)>>> 
>>>  
>>> Ah okay, so you mean to say that you disable these other architectures by declaring and accomplishing it in the /etc/src.conf?
>>>  
>>> I'll provide an update here once the build is done knowing how long it takes to finish.
>> 
>>  
>> Hi Mark,
>>  
>> With this set of build commands now,
>>  
>> # cd /usr/src; make -j3 KERNCONF=ARM TARGET_ARCH=aarch64 buildworld kernel-toolchain buildkernel installworld installkernel distribution DESTDIR=/home/freebsd/rpi3b
>>  
>> in RPi 3B, I encountered the other OOM error which is the 'thread waited too long to allocate a page'. This occurred from every build I conducted. Though the first error on 'failed to reclaim memory' was never experienced again. Below are the error logs.
>> ...
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 4096
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40960
>> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to allocate a page
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192
> 
>  
> This means that paging to the swap partition and/or swap file took too long (> 30 seconds... that's all that indefinite means). It also means that it can't write to backing store dirty pages to give to another process...
>  
> Typical reason is that the disk / flash is not responsive to writes for some reason. You'll need to find why... I'd look at trims.
>  
> Or.... if you can't change the disk... you need to put less memory pressure on it..
>  
> Warner
>  



NB: a way to put less memory pressure on it is not using -j3, but -j2 or -j1 in your make command.

Regards,
Ronald.

 
------=_Part_127405_1504264931.1667909706277
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

 

Van: Warner Losh <imp@bsdimp.com>

Datum: dinsdag, 8 november 2022 04:28

Aan: Archimedes Gaviola <archimedes.gaviola@gmail.com>

CC: Mark Millard <marklmi@yahoo.com>, freebsd-current <freebsd-current@freebsd.org>

Onderwerp: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build













 

 




On Mon, Nov 7, 2022 at 7:40 PM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:







 

 




On Sat, Nov 5, 2022 at 5:28 PM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:







 





 

 




On Thu, Nov 3, 2022 at 7:52 AM Mark Millard <marklmi@yahoo.com> wrote:



On 2022-Nov-2, at 14:09, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:



> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:

>

> . . .

>

> . . .

>

>

> Hi Mark,

>

> Just an update, as kernel and world compilation is ongoing with my RPi3B system (with swap partition) is doing so far, so good. It already surpassed the tough part that breaks the compilation process here.

> ...

>

> llvm-tblgen -gen-asm-matcher  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-asm-writer  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-callingconv  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-compress-inst-emitter  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-dag-isel  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-disassembler  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-global-isel  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-instr-info  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-emitter  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-pseudo-lowering  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-bank  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-info  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-subtarget  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables  -I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc  /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

>

> Any thoughts why this part is quite a challenge when it comes to memory usage? The other architectures do not possess such behavior... just curious.



 



Hi Mark,



 



Sorry for the late response, I got fully occupied at work for the past few days due to deliverables. Thanks for your feedback and further inputs!



 



I've not done any monitoring of buildworld buildkernel build

activity (RAM use, memory space use, swap partition use over

time) on RPi3B class hardware in a very long time.



 



It's alright, it so happened that I just observed that behavior on that particular part as it requires more memory than other architectures while compiling. The additional 3.5G swap partition really helps on that part that's why I was so happy that the compilation continued and never broke. Your input of having 3.5G swap allocation is very effective.



 



Even on systems that I have monitored in more recent times,

what I usually monitor tends to be builds with -jN (such as

-j4 fora 4-hardware-thread system). (I once did have an

example of -j3 taking less time than -j4 on a RPi4B.



 



Wow, this is interesting this -jN. Let me explore this as well. I usually build kernel the old way but recently since I have to include building the world then I need to use the new way.



 



Basically, the memory subsystem can be saturated without all

the cores being in use. The extra interference made things

take longer.)



 



Oh I see so it's the reason.



 



You had listed that you were using the likes of:



# cd /usr/src ; make KERNCONF=ARM TARGET_ARCH=aarch64 \

buildkernel buildworld installkernel installworld distribution \

DESTDIR=/home/freebsd/rpi3b



I'll note that the standard order of the first 2 is:



buildworld buildkernel



This is because buildworld builds some software that

buildkernel does not build for itself but does use.



 



Okay this is noted, thanks for clarifying and correcting me, I really appreciate it. I'll reflect on the proper build sequence for much efficiency.



 



There is a kernel-toolchain target for avoiding the

need to do a full buildworld just to buildkernel , so:



kernel-toolchain buildkernel



is an expected sequence.



 



Okay I'll take note of this too.



 



I do not know how long a from-scratch buildworld

buildkernel without a -jN takes on a RPi3B these

days. If I remember right, for -jN with 1<N, I last

saw claims about such they were somewhere in the

range 36hr..48hr.



 



There's an ongoing build at the moment, it's already taking 41 hours since I started it. I took another build when I came back home from the office.



 



But I'm unsure of the specific N

that was in use. Nor do I know the storage media

type(s) involved, for example. I do not remember

any reports for -j1.



 



I'll try this with RPi 3B. The current build that I have will be my baseline.



 



Use of the likes of: vm.pageout_oom_seq=120

was essential to such -jN usage on a RPi3B as N

gets larger. Of course, swap partition use for

paging was also essential.



 



Wow, that's great! I have this vm.pageout_oom_seq=120 configured in my system now based on your previous inputs.



 



Likewise use of:



vm.swap_enabled=0

vm.swap_idle_enabled=0



can be important to not losing communication

with the RPi3B. Those last 2 are not tunable

but are writable:



# sysctl -aT | grep swap_

# sysctl -aW | grep swap_

vm.swap_enabled: 0

. . .

vm.swap_idle_enabled: 0

. . .



(This means that they have fewer places where

assignments can be made. For example, the

loader can not make the assignments.)



By contrast, vm.pageout_oom_seq is both

writable and tunable:



# sysctl -aW | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



# sysctl -aT | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



(So even the loader can make such assignments.)



 



Yes, I have these two sysctl parameters configured in the system. Thanks for the details and further inputs.



 



I'll note that I've no interest in using arm hardware

to build for other types of hardware. So I normally

have the targeting of support for building for other

architectures disabled when I build on aarch64 or

armv7. (Basically, a less complete clang/clang++

related toolchain ends up being built.)



 



Ah okay, so you mean to say that you disable these other architectures by declaring and accomplishing it in the /etc/src.conf?



 



I'll provide an update here once the build is done knowing how long it takes to finish.











 





Hi Mark,



 



With this set of build commands now,



 



# cd /usr/src; make -j3 KERNCONF=ARM TARGET_ARCH=aarch64 buildworld kernel-toolchain buildkernel installworld installkernel distribution DESTDIR=/home/freebsd/rpi3b



 



in RPi 3B, I encountered the other OOM error which is the 'thread waited too long to allocate a page'. This occurred from every build I conducted. Though the first error on 'failed to reclaim memory' was never experienced again. Below are the error logs.



...



swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 4096

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40960

pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to allocate a page

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192







 



This means that paging to the swap partition and/or swap file took too long (> 30 seconds... that's all that indefinite means). It also means that it can't write to backing store dirty pages to give to another process...



 



Typical reason is that the disk / flash is not responsive to writes for some reason. You'll need to find why... I'd look at trims.



 



Or.... if you can't change the disk... you need to put less memory pressure on it..



 



Warner



 



















NB: a way to put less memory pressure on it is not using -j3, but -j2 or -j1 in your make command.



Regards,

Ronald.



 
------=_Part_127405_1504264931.1667909706277--

From nobody Tue Nov  8 17:37:35 2022
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 4N6Fg454YGz4TyK3
	for ; Tue,  8 Nov 2022 17:37:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6Fg42Jxwz4CST
	for ; Tue,  8 Nov 2022 17:37:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667929070; bh=XAfOc03x/Z7Aq2COpSuK3CrhfKpLfG673QUrJF3vQAE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pX+KVwv9vwYwv4akUtxp8+tol5ce3P4VIbpRSx9AxqE8mrJ61KaOncoYKdWBO4VJAsEld89rCurgli4ve9gfQ5swNFv8cCBnwfQ//Y7KWw0Ta/KIFVsED/maOeEO10B4cilAKqqaLUsbmj7wOlo25GRfPaY5auf0T8RfSSb10VdfRJSGmTiqRmzvzzm8UlwYSqNnBv8mWWeAC8pJqqJSgyKfBPhrYa/HXYzM5bnrMo0IJ+XIByO+HtfXbtwkX7+buL56mdaKnwo4VNuen20TbsNVq8wgD3FcUKE3FiyqH8M8ymq4gNjD6K71BxAZzyQiYL0ff5S+4LMaqC+a/5Yukg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667929070; bh=wEz0uatC0lf2SuJ9HnONORlT+tX9Hi1hVl8HhiniOZ8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Lp1pUAb4ORuNm40Q+wY8UiQhxXYCwtpQex7ncogUMTlBXlxC7IaDhuD4GgY9jMUFnoG5UYncrvPaNSy9rv4xhqJR1w6Xdp4lI+bWdW5wvS89HXhNGCWHmFaH3Tnek0A4OuHXVUrMTZq6EApdxKgYrDAzgyErOfM3TjBn+g0viIyGaZX5u0bMYU7eVRTFyv4C/vmrjU4Yqshy6mLz0mwSD4/xSjh/XRoItq3CXdt7Hfb9YMORynfUSo4QOn06zGCy9gGvyZbrV/DyqTmXf/9lzntb6FtyJ5hBcnZE521JYkHJ3loyEnssNuZ0ABWvovbvgzDnCgXAvd0eUksp3AIE4g==
X-YMail-OSG: S9IdbR4VM1myJ3L7SKk2DIUyGHRk6JRtSlA9Ki2KKdm2AFIMQUtC6ha01l0r1XG
 gTAaLWOymXSZYxORKXmA28j1_ARrZv8JrZkvJLBfEo7jt7ED6mcVwIJ1KGA65F0c496f5Jr6Worv
 Q77YtKHP78xSJQvGJDM13wQMjhlMlWTxip98A.orFTucXzpuLKemI7T3E2Nu4gcBceHnYXeoPQKq
 LIc5WKnUSGZaW8u.7dXd0cBuTKIPl0UrtCmYPEBIyMaR_j_Hh6qpSKNe2MOnw1VLnDDqt8N5rQ99
 cnJFMU7L1kDRTC1xoeApe8DOVSYLbvAsYNdlYHqU_FDg42kifX2hNSbyJvqJnfxUjO.0Fq38FbEN
 l.HkZ5tf55EGa9.6hJP1S6LmqyCJAMbcqY0Usrxw0nt6zEtVfUuCiOkxfhf9ASbw7_SuAd673Pys
 pVtvw94QYJZiP2ELgvMieTtDGnyhwUrZ7PqL..tkjiTUKyZSoIEKTR75MgixxsTwQiEiudZYTNBr
 69V1Tw4hq_mpo9KuNZdZ.3PtzY1npSQFxWkGfyS2swQIhoY1jyCHTXQEiPq9eOwE9TYu.isdlELw
 HYEWHQEOv2V__Cjy.Ya_Zoims6r.fidcBp2Y3Rat_6v12uk2UawRHdeJSfX.LFFgkfMqq.ZPjmnK
 SMi4e98GeI1s54nKeSkD.f7UJY8wQ_tT79PhCMO9ShH81hUkRQt3P7gkZ1xU36MKTk9G5ZSJXoo6
 11imdzuc58BMXvPPf8ofJGgpg7TU8CDTnfmU4Xhk96bVTfftA7rDLREPVwXHd0mSAlzgMUazdomR
 YoXq7nSzigRwcijgsfz.bg5NtEJjHvxVCBFUqATl5a.Xqb285gLJwtmoBxaKRrEKzxTJKRfpOTxM
 TQWhOvwRb.NP0FFOC8lurctl3IRxkGPv_O4rm8JUycrfmYBCbyyO8krz94kqfokl.iqgUv_h8o8R
 6NUudXvoTOs4spP7FeL1w9rsls6utkysHeOWEJNU3ylvDWkyvosRcK.qrzpS4Wop4O1TYRJ66q4j
 wA_I03rlAat_XFpZPnEfnHCMPfR3_VxQbNFKRP42eYxBLtud7nmWeQGEC5tCLYIUjjPP8MgEnNgB
 gV9YqyJaPUMbY1GEyNCBwn28.dwcXi8qZp.9qqbxClJmwInYoUDRAjBCEHTAzXVNmmx2Kqcva_QV
 8r1JVIySJxZ0mlK4562c91ayseABCvNobjj7gBCX6SnoiGksGLNO.gaJ9X7qoV_ZfN1nmGtG1zgt
 xHX9AO58XtKMivcVxCVd51zZjQLPJdxyk4uHxr4XZkG1EVBtCZ6JKOXv71tgNdOYBEXC4WbSAvtd
 yz41TVnu07zMzkBZ1EgZgVHTDFFhhpzphru7i3bjYs2dkFN0KVEev2Q86SDSQjOtEHQPZVdUi.dH
 2jr9ulXbmqc4krtYM0n0NbwdM5e25gODbwh3Xn5.M0fyqX6oJgQR59JG.MyVwR7px21B.jGAu.e7
 A2mynw4iJRWBXHUIeC0sUEUbiSgzZIsK1idArYDtow1My2qsAB7MM7Qv_ogS2LTiAlRZYt9yH9vw
 pM2ZncXwquD2NpjyC.XBKP7CzPW.wmVS_NrV2BTa5yyvhB8q8DRtQkm.oz.jw_zFIzh2NgLyShPW
 YqTOwfKcSXyb7MJafNV_GS3362Cz8sQqFA3Ug.qPR7YYgz03fcioXnnm_zGkcCACvugsdo5oOECA
 hH5nipzhoXDF.6RF5zhXX1cNYTMsZkMMHMRQ9QOYBK4mhjP2OOQEbXd2Tazxtzpj7p24ayct1tpE
 xdveDNzb8ouVlOaoSg0CCfrVHITcXnFxjLasajePGcY7eCreT.4BT7q5GYv6ycXZFcCWm8hwZOPd
 GlhQYX0.BOgBXZSukqEEvb_zbxyZ0IsuatHWoTR3SfzDSpnIeegPEbnz0T64u0Z3jEngoantQ1dn
 UMDyVXa9uA.j2yLzUMXv4xD4qbWr09YExHQk1UFcEfPIH7OaCCuF45niWzNVpD7e9ALvBKYkSz7l
 XjRTHDUzJGzIf.SZDnRzFBS4QGQUm9hrmvlXy9zglsNS4EG0syZclIcKijAlJK5WLZABn7x7lBRa
 _nw2yc.x6NVhi.DJtBcToNiM86AIVIq69ZITrPymMKbjw.w_77u.zeul3xBP1OTzwsZ1pp8yLkXw
 a3VF2BMvL22txHD015rMypVP33DigFLTb0p6iqLMP6cobxTB7Ize3Q0xWRq7PTr8Nb46jah2OYjc
 Pxsn2oHpQcX1VfCZTnojQ_644WDkNFnOYi2FIUgx6ZFSojv3UsVjWFtE5F.KsVH6wwo9.g05Yj2x
 QwA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Nov 2022 17:37:50 +0000
Received: by hermes--production-ne1-6bcfb7fb87-8spmd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f36c19c8fea87d411cba89fde7e8d7be;
          Tue, 08 Nov 2022 17:37:47 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
From: Mark Millard 
X-Priority: 3 (Normal)
In-Reply-To: <1722758786.127406.1667909706281@localhost>
Date: Tue, 8 Nov 2022 09:37:35 -0800
Cc: Ronald Klop ,
 freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E33E6A3-ABB8-4804-B2A2-0E95E853C860@yahoo.com>
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
 
 
 
 
 
 
 
 
 <1722758786.127406.1667909706281@localhost>
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N6Fg42Jxwz4CST
X-Spamd-Bar: ----
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_RCPT(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]
X-ThisMailContainsUnwantedMimeParts: N

On Nov 8, 2022, at 04:15, Ronald Klop  wrote:

> Van: Warner Losh 
> Datum: dinsdag, 8 november 2022 04:28
> Aan: Archimedes Gaviola  . . .
> ...
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: =
4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: =
40960
> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to =
allocate a page
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: =
28672
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: =
4096
> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: =
8192
>   This means that paging to the swap partition and/or swap file took =
too long (> 30 seconds... that's all that indefinite means). It also =
means that it can't write to backing store dirty pages to give to =
another process...
>   Typical reason is that the disk / flash is not responsive to writes =
for some reason. You'll need to find why... I'd look at trims.
>   Or.... if you can't change the disk... you need to put less memory =
pressure on it..
>   Warner
>  =20
>=20
>=20
> NB: a way to put less memory pressure on it is not using -j3, but -j2 =
or -j1 in your make command.
>=20

Extending Ronold's comment: If things are really taking this
long for the paging I/O, you might actually find, say, -j2
takes less elapsed time than -j3 because of the latencies
involved in -j3 causing more overall delay.

vm.pfault_oom_attempts=3D-1 would still be appropriate for avoiding
I/O kills at any -jN: the smaller -jN just makes the issue less
likely, not impossible. (Again, presuming sufficient swap/paging
space if deadlock is to be well avoided.)

(I use NVMe or SSD USB media that do not get such long delays but
fit the power limitations of the context. I have about as little
on microsd card media as I can get away with in my context. I also
avoid spinning rust. Thus I've only gotten "indefinite wait buffer"
or the like back before such was true, long ago.)

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


From nobody Wed Nov  9 01:50:24 2022
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 4N6Sbv36S3z4XHgd
	for ; Wed,  9 Nov 2022 01:50:51 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6Sbv0qdvz42yr
	for ; Wed,  9 Nov 2022 01:50:51 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-yb1-xb2b.google.com with SMTP id 129so19402322ybb.12
        for ; Tue, 08 Nov 2022 17:50:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=KonXKAqebrAgUM5gPbJANlw+C+VQiy3J/RbH6SCM0O8=;
        b=BNw/2MB0ZL8UW3QIElYwcKGUvvdoyaY3P9fXjB1aAFNWx9TZLG13INcrbYN3ZT3yEn
         w5uKIk4EsFltPCjmEIIebgFzmIJ/lFjRezwuA8VMCPnpTe2HBcA5bu1c0TyVHAWAYNcq
         onBee5MPfszHpHXGn6DPk6CscdZN+OL/YTpHxr84LQknkAxc2hT2dRi1dSMg6QU7wEqZ
         XY8ASWM8qmqqWC4B7vtQKzorTITa1GFZTmXqUg+1opOwyspNzrCP+7N40INkebSKgD9v
         3ck6YWBrIEmOzV4RG6B9VVWktl4G5JSqk4xeUxDGO20odWqaisgK9f8kll/Q4xtqi1cE
         TN1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=KonXKAqebrAgUM5gPbJANlw+C+VQiy3J/RbH6SCM0O8=;
        b=7rDqw/rEIg++gIBqFw3LUrgG06HJDl1kYGiT+r68VNcfR5Ns38dKonWtE0OaehyEai
         eGm+sM8Vbswa7cGcH2z6qIup1mVvJYVoyLtIzSeDlKE6SmYjmqSpqckCN1d4jFX+CsmW
         c5ZxU1fwKPnwXap6EH1uhnTOe4U0++UJ+Gm31shQDfwIrbaAPci7q0NqIm9T0SY1FiV/
         SVd7KCd7lWgua91pEntDr2iaAqRBJtNG128KRm9yOxx9gwRJk+SPnqrKSA48GBZiL27O
         1/DIRKpE9GUydUjhw7TIuzd059jWEa/nuw3HEx/3Iweva/gGJBYiPa/HEDTWIi3c9Cu+
         43Vw==
X-Gm-Message-State: ACrzQf3HEM9IPzHSHN2e/u2gbJtliQllqRVdK4aBNE9ntIqL4Mq3mtHd
	KdeYSBj6q2prCv267GFl6qo494pbVNVdZxQpdAP3N3zV
X-Google-Smtp-Source: AMsMyM44qDFd8XL1ygezW2XPIDX5X0I0B25gDeukLfjYvY4CibG7Pade/ft2OBOfKeDE364ixTjxNyDjaEskRZkTPs8=
X-Received: by 2002:a25:3f86:0:b0:6bc:998:873e with SMTP id
 m128-20020a253f86000000b006bc0998873emr58555970yba.152.1667958650191; Tue, 08
 Nov 2022 17:50:50 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
 
  
 
  <1722758786.127406.1667909706281@localhost>
In-Reply-To: <1722758786.127406.1667909706281@localhost>
From: Archimedes Gaviola 
Date: Wed, 9 Nov 2022 09:50:24 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Ronald Klop 
Cc: Warner Losh , Mark Millard , 
	freebsd-current 
Content-Type: multipart/alternative; boundary="000000000000d8444805ecffe2a5"
X-Rspamd-Queue-Id: 4N6Sbv0qdvz42yr
X-Spamd-Bar: ----
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];
	TAGGED_FROM(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000d8444805ecffe2a5
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 8, 2022 at 8:15 PM Ronald Klop  wrote:

>
>
> *Van:* Warner Losh 
> *Datum:* dinsdag, 8 november 2022 04:28
> *Aan:* Archimedes Gaviola 
> *CC:* Mark Millard , freebsd-current <
> freebsd-current@freebsd.org>
> *Onderwerp:* Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B
> build
>
>
>
> On Mon, Nov 7, 2022 at 7:40 PM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
>
>>
>>
>> On Sat, Nov 5, 2022 at 5:28 PM Archimedes Gaviola <
>> archimedes.gaviola@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Thu, Nov 3, 2022 at 7:52 AM Mark Millard  wrote:
>>>
>>>> On 2022-Nov-2, at 14:09, Archimedes Gaviola <
>>>> archimedes.gaviola@gmail.com> wrote:
>>>>
>>>> > On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <
>>>> archimedes.gaviola@gmail.com> wrote:
>>>> >
>>>> > . . .
>>>> >
>>>> > . . .
>>>> >
>>>> >
>>>> > Hi Mark,
>>>> >
>>>> > Just an update, as kernel and world compilation is ongoing with my
>>>> RPi3B system (with swap partition) is doing so far, so good. It already
>>>> surpassed the tough part that breaks the compilation process here.
>>>> > ...
>>>> >
>>>> > llvm-tblgen -gen-asm-matcher  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-asm-writer  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-callingconv  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-compress-inst-emitter  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-dag-isel  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-disassembler  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-global-isel  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-instr-info  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-emitter  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-pseudo-lowering  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-register-bank  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-register-info  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-searchable-tables  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-subtarget  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> > llvm-tblgen -gen-searchable-tables  -I
>>>> /usr/src/contrib/llvm-project/llvm/include -I
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV  -d
>>>> RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc
>>>> /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>>>> >
>>>> > Any thoughts why this part is quite a challenge when it comes to
>>>> memory usage? The other architectures do not possess such behavior... just
>>>> curious.
>>>
>>>
>>> Hi Mark,
>>>
>>> Sorry for the late response, I got fully occupied at work for the past
>>> few days due to deliverables. Thanks for your feedback and further inputs!
>>>
>>>
>>>> I've not done any monitoring of buildworld buildkernel build
>>>> activity (RAM use, memory space use, swap partition use over
>>>> time) on RPi3B class hardware in a very long time.
>>>
>>>
>>> It's alright, it so happened that I just observed that behavior on that
>>> particular part as it requires more memory than other architectures while
>>> compiling. The additional 3.5G swap partition really helps on that part
>>> that's why I was so happy that the compilation continued and never broke.
>>> Your input of having 3.5G swap allocation is very effective.
>>>
>>>
>>>> Even on systems that I have monitored in more recent times,
>>>> what I usually monitor tends to be builds with -jN (such as
>>>> -j4 fora 4-hardware-thread system). (I once did have an
>>>> example of -j3 taking less time than -j4 on a RPi4B.
>>>
>>>
>>> Wow, this is interesting this -jN. Let me explore this as well. I
>>> usually build kernel the old way but recently since I have to include
>>> building the world then I need to use the new way.
>>>
>>>
>>>> Basically, the memory subsystem can be saturated without all
>>>> the cores being in use. The extra interference made things
>>>> take longer.)
>>>
>>>
>>> Oh I see so it's the reason.
>>>
>>>
>>>> You had listed that you were using the likes of:
>>>>
>>>> # cd /usr/src ; make KERNCONF=ARM TARGET_ARCH=aarch64 \
>>>> buildkernel buildworld installkernel installworld distribution \
>>>> DESTDIR=/home/freebsd/rpi3b
>>>>
>>>> I'll note that the standard order of the first 2 is:
>>>>
>>>> buildworld buildkernel
>>>>
>>>> This is because buildworld builds some software that
>>>> buildkernel does not build for itself but does use.
>>>
>>>
>>> Okay this is noted, thanks for clarifying and correcting me, I really
>>> appreciate it. I'll reflect on the proper build sequence for much
>>> efficiency.
>>>
>>>
>>>> There is a kernel-toolchain target for avoiding the
>>>> need to do a full buildworld just to buildkernel , so:
>>>>
>>>> kernel-toolchain buildkernel
>>>>
>>>> is an expected sequence.
>>>
>>>
>>> Okay I'll take note of this too.
>>>
>>>
>>>> I do not know how long a from-scratch buildworld
>>>> buildkernel without a -jN takes on a RPi3B these
>>>> days. If I remember right, for -jN with 1>>> saw claims about such they were somewhere in the
>>>> range 36hr..48hr.
>>>
>>>
>>> There's an ongoing build at the moment, it's already taking 41 hours
>>> since I started it. I took another build when I came back home from the
>>> office.
>>>
>>>
>>>> But I'm unsure of the specific N
>>>> that was in use. Nor do I know the storage media
>>>> type(s) involved, for example. I do not remember
>>>> any reports for -j1.
>>>
>>>
>>> I'll try this with RPi 3B. The current build that I have will be my
>>> baseline.
>>>
>>>
>>>> Use of the likes of: vm.pageout_oom_seq=120
>>>> was essential to such -jN usage on a RPi3B as N
>>>> gets larger. Of course, swap partition use for
>>>> paging was also essential.
>>>
>>>
>>> Wow, that's great! I have this vm.pageout_oom_seq=120 configured in my
>>> system now based on your previous inputs.
>>>
>>>
>>>> Likewise use of:
>>>>
>>>> vm.swap_enabled=0
>>>> vm.swap_idle_enabled=0
>>>>
>>>> can be important to not losing communication
>>>> with the RPi3B. Those last 2 are not tunable
>>>> but are writable:
>>>>
>>>> # sysctl -aT | grep swap_
>>>> # sysctl -aW | grep swap_
>>>> vm.swap_enabled: 0
>>>> . . .
>>>> vm.swap_idle_enabled: 0
>>>> . . .
>>>>
>>>> (This means that they have fewer places where
>>>> assignments can be made. For example, the
>>>> loader can not make the assignments.)
>>>>
>>>> By contrast, vm.pageout_oom_seq is both
>>>> writable and tunable:
>>>>
>>>> # sysctl -aW | grep oom
>>>> . . .
>>>> vm.pageout_oom_seq: 120
>>>> . . .
>>>>
>>>> # sysctl -aT | grep oom
>>>> . . .
>>>> vm.pageout_oom_seq: 120
>>>> . . .
>>>>
>>>> (So even the loader can make such assignments.)
>>>
>>>
>>> Yes, I have these two sysctl parameters configured in the system. Thanks
>>> for the details and further inputs.
>>>
>>>
>>>> I'll note that I've no interest in using arm hardware
>>>> to build for other types of hardware. So I normally
>>>> have the targeting of support for building for other
>>>> architectures disabled when I build on aarch64 or
>>>> armv7. (Basically, a less complete clang/clang++
>>>> related toolchain ends up being built.)
>>>
>>>
>>> Ah okay, so you mean to say that you disable these other architectures
>>> by declaring and accomplishing it in the /etc/src.conf?
>>>
>>> I'll provide an update here once the build is done knowing how long it
>>> takes to finish.
>>>
>>
>> Hi Mark,
>>
>> With this set of build commands now,
>>
>> # cd /usr/src; make -j3 KERNCONF=ARM TARGET_ARCH=aarch64 buildworld
>> kernel-toolchain buildkernel installworld installkernel distribution
>> DESTDIR=/home/freebsd/rpi3b
>>
>> in RPi 3B, I encountered the other OOM error which is the 'thread waited
>> too long to allocate a page'. This occurred from every build I conducted.
>> Though the first error on 'failed to reclaim memory' was never experienced
>> again. Below are the error logs.
>> ...
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 4096
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40960
>> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to
>> allocate a page
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192
>>
>
> This means that paging to the swap partition and/or swap file took too
> long (> 30 seconds... that's all that indefinite means). It also means that
> it can't write to backing store dirty pages to give to another process...
>
> Typical reason is that the disk / flash is not responsive to writes for
> some reason. You'll need to find why... I'd look at trims.
>
> Or.... if you can't change the disk... you need to put less memory
> pressure on it..
>
> Warner
>
>
>
>
>
> NB: a way to put less memory pressure on it is not using -j3, but -j2 or
> -j1 in your make command.
>
> Regards,
> Ronald.
>

Hi Ronald,

Okay, this is noted, thanks for the additional info.

Thanks and best regards,
Archimedes


>
>
>

--000000000000d8444805ecffe2a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Nov 8, 2022 at 8:15 PM Ronald=
 Klop <ronald-lists@klop.ws&=
gt; wrote:
=
=C2=A0

Van: Warner Losh <imp@bsdimp.com>

Datum: dinsdag, 8 november 2022 04:28

Aan: Archimedes Gaviola <archimedes.gaviola@gmail.com>

CC: Mark Millard <marklmi@yahoo.com>, freebsd-current <freebsd-current@freebsd.org>

Onderwerp: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B=
 build













=C2=A0

=C2=A0




On Mon, Nov 7, 2022 at 7:40 PM Archimedes Gaviola=
 <arch=
imedes.gaviola@gmail.com> wrote:







=C2=A0

=C2=A0




On Sat, Nov 5, 2022 at 5:28 PM Archimedes Gaviola=
 <arch=
imedes.gaviola@gmail.com> wrote:







=C2=A0





=C2=A0

=C2=A0




On Thu, Nov 3, 2022 at 7:52 AM Mark Millard <<=
a href=3D"mailto:marklmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com=
> wrote:



On 2022-Nov-2, at 14:09, =
Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:



> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <archimedes.gaviola@gmail=
.com> wrote:

>

> . . .

>

> . . .

>

>

> Hi Mark,

>

> Just an update, as kernel and world compilation is ongoing with my RPi=
3B system (with swap partition) is doing so far, so good. It already surpas=
sed the tough part that breaks the compilation process here.

> ...

>

> llvm-tblgen -gen-asm-matcher=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc=C2=A0 /usr/src/contrib/l=
lvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-asm-writer=C2=A0 -I /usr/src/contrib/llvm-project/llv=
m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R=
ISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc=C2=A0 /usr/src/contrib/llvm=
-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-callingconv=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc=C2=A0 /usr/src/contrib=
/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-compress-inst-emitter=C2=A0 -I /usr/src/contrib/llvm-=
project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=
=C2=A0 -d RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.=
inc=C2=A0 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-dag-isel=C2=A0 -I /usr/src/contrib/llvm-project/llvm/=
include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RIS=
CVGenDAGISel.inc.d -o RISCVGenDAGISel.inc=C2=A0 /usr/src/contrib/llvm-proje=
ct/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-disassembler=C2=A0 -I /usr/src/contrib/llvm-project/l=
lvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d=
 RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc=C2=A0 /=
usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-global-isel=C2=A0 -I /usr/src/contrib/llvm-project/ll=
vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d =
RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc=C2=A0 /usr/src/contrib/l=
lvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-instr-info=C2=A0 -I /usr/src/contrib/llvm-project/llv=
m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R=
ISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc=C2=A0 /usr/src/contrib/llvm=
-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-emitter=C2=A0 -I /usr/src/contrib/llvm-project/llvm/i=
nclude -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RISC=
VGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc=C2=A0 /usr/src/contrib=
/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-pseudo-lowering=C2=A0 -I /usr/src/contrib/llvm-projec=
t/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0=
 -d RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc=C2=A0 /u=
sr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-bank=C2=A0 -I /usr/src/contrib/llvm-project/=
llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -=
d RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc=C2=A0 /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-register-info=C2=A0 -I /usr/src/contrib/llvm-project/=
llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -=
d RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc=C2=A0 /usr/src/con=
trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=
=A0 -d RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc=C2=A0=
 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-subtarget=C2=A0 -I /usr/src/contrib/llvm-project/llvm=
/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RI=
SCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc=C2=A0 /usr/src/contr=
ib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj=
ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=
=A0 -d RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc=C2=A0 /us=
r/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

>

> Any thoughts why this part is quite a challenge when it comes to memor=
y usage? The other architectures do not possess such behavior... just curio=
us.



=C2=A0



Hi Mark,



=C2=A0



Sorry for the late response, I got fully occupied at work for the past=
 few days due to deliverables. Thanks for your feedback and further inputs!=




=C2=A0



I've not done any mon=
itoring of buildworld buildkernel build

activity (RAM use, memory space use, swap partition use over

time) on RPi3B class hardware in a very long time.



=C2=A0



It's alright, it so happened that I just observed that behavior on=
 that particular part as it requires more memory than other architectures w=
hile compiling. The additional 3.5G swap partition really helps on that par=
t that's why I was so happy that the compilation continued and never br=
oke. Your input of having 3.5G swap allocation is very effective.



=C2=A0



Even on systems that I ha=
ve monitored in more recent times,

what I usually monitor tends to be builds with -jN (such as

-j4 fora 4-hardware-thread system). (I once did have an

example of -j3 taking less time than -j4 on a RPi4B.



=C2=A0



Wow, this is interesting this -jN. Let me explore this as well. I usua=
lly build kernel the old way but recently since I have to include building =
the world then I need to use the new way.



=C2=A0



Basically, the memory sub=
system can be saturated without all

the cores being in use. The extra interference made things

take longer.)



=C2=A0



Oh I see so it's the reason.



=C2=A0



You had listed that you w=
ere using the likes of:



# cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64 \

buildkernel buildworld installkernel installworld distribution \

DESTDIR=3D/home/freebsd/rpi3b



I'll note that the standard order of the first 2 is:



buildworld buildkernel



This is because buildworld builds some software that

buildkernel does not build for itself but does use.



=C2=A0



Okay this is noted, thanks for clarifying and correcting me, I really =
appreciate it. I'll reflect on the proper build sequence for much effic=
iency.



=C2=A0



There is a kernel-toolcha=
in target for avoiding the

need to do a full buildworld just to buildkernel , so:



kernel-toolchain buildkernel



is an expected sequence.



=C2=A0



Okay I'll take note of this too.



=C2=A0



I do not know how long a =
from-scratch buildworld

buildkernel without a -jN takes on a RPi3B these

days. If I remember right, for -jN with 1<N, I last

saw claims about such they were somewhere in the

range 36hr..48hr.



=C2=A0



There's an ongoing build at the moment, it's already taking 41=
 hours since I started it. I took another build when I came back home from =
the office.



=C2=A0



But I'm unsure of the=
 specific N

that was in use. Nor do I know the storage media

type(s) involved, for example. I do not remember

any reports for -j1.



=C2=A0



I'll try this with RPi 3B. The current build that I have will be m=
y baseline.



=C2=A0



Use of the likes of: vm.p=
ageout_oom_seq=3D120

was essential to such -jN usage on a RPi3B as N

gets larger. Of course, swap partition use for

paging was also essential.



=C2=A0



Wow, that's great! I have this vm.pageout_oom_seq=3D120 configured=
 in my system now based on your previous inputs.



=C2=A0



Likewise use of:



vm.swap_enabled=3D0

vm.swap_idle_enabled=3D0



can be important to not losing communication

with the RPi3B. Those last 2 are not tunable

but are writable:



# sysctl -aT | grep swap_

# sysctl -aW | grep swap_

vm.swap_enabled: 0

. . .

vm.swap_idle_enabled: 0

. . .



(This means that they have fewer places where

assignments can be made. For example, the

loader can not make the assignments.)



By contrast, vm.pageout_oom_seq is both

writable and tunable:



# sysctl -aW | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



# sysctl -aT | grep oom

. . .

vm.pageout_oom_seq: 120

. . .



(So even the loader can make such assignments.)



=C2=A0



Yes, I have these two sysctl parameters configured in the system. Than=
ks for the details and further inputs.



=C2=A0



I'll note that I'=
ve no interest in using arm hardware

to build for other types of hardware. So I normally

have the targeting of support for building for other

architectures disabled when I build on aarch64 or

armv7. (Basically, a less complete clang/clang++

related toolchain ends up being built.)



=C2=A0



Ah okay, so you mean to say that you disable these other architectures=
 by declaring and accomplishing it in the /etc/src.conf?



=C2=A0



I'll provide an update here once the build is done knowing how lon=
g it takes to finish.











=C2=A0





Hi Mark,



=C2=A0



With this set of build commands now,



=C2=A0



# cd /usr/src; make -j3 KERNCONF=3DARM TARGET_AR=
CH=3Daarch64 buildworld kernel-toolchain buildkernel installworld installke=
rnel distribution DESTDIR=3D/home/freebsd/rpi3b



=C2=A0



in RPi 3B, I encountered the other OOM error whi=
ch is the 'thread waited too long to allocate a page'. This occurre=
d from every build I conducted. Though the first error on 'failed to re=
claim memory' was never experienced again. Below are the error logs.


...



swap_pager: indefinite wait buffer: bufobj: 0, b=
lkno: 256929, size: 4096

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40960
pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to allo=
cate a page

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192






=C2=A0



This means that paging to the swap partition and/or swap file took too=
 long (> 30 seconds... that's all that indefinite means). It also me=
ans that it can't write to backing store dirty pages to give to another=
 process...



=C2=A0



Typical reason is that the disk / flash is not responsive to writes fo=
r some reason. You'll need to find why... I'd look at trims.



=C2=A0



Or.... if you can't change the disk... you need to put less memory=
 pressure on it..



=C2=A0



Warner



=C2=A0



















NB: a way to put less memory pressure on it is not using -j3, but -j2 or -j=
1 in your make command.



Regards,

Ronald.

Hi Ronald,

=

Okay, this is noted, thanks for the additional info.
<=
br>
Thanks and best regards,
Archimedes
=C2=
=A0



=C2=A0


--000000000000d8444805ecffe2a5--

From nobody Wed Nov  9 02:15:32 2022
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 4N6T8t7011z4XMms
	for ; Wed,  9 Nov 2022 02:15:58 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6T8t543pz454n
	for ; Wed,  9 Nov 2022 02:15:58 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-369426664f9so150198777b3.12
        for ; Tue, 08 Nov 2022 18:15:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=yiUGOaqzYFdt08gpitYncF/qk5kV/GO81dF0qhXdp7w=;
        b=IRGskljUWv85OYRNkpXVS3UoZLP//wjvFts/1KfXwWhPsV7sIq7YeI6d4BX3BbZyGl
         dNOKWd8I00mZzJZbe1pSxT01+Sdy5WpdT//AzdIJ5sUWO1F+a0cDg3GQCTB8c2Us7m/F
         VYIBea6g3hYul0DvtCWVgTJ9NTzrUZtVu/VChras0bDsjzJ1ZAlrhSy+HL62zb6cdPqZ
         2Ag4O0vVEKOhk29EG7BDRpolu+64Gm8fr27nUu4VrLvz+QQmbMDJ89d96LLyDWLizqNB
         m/8JaAcBaRCV6tDv4PPoBgJFEQj2HOJJ/aCdTt7nGds59wW8pY31FpnqtyN/NAq5/AFB
         L+Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=yiUGOaqzYFdt08gpitYncF/qk5kV/GO81dF0qhXdp7w=;
        b=1To1Jf0XmK+MUzyJowR44TB8+HokR4hjJ+dG7db0z16EzUrC2JVyNdJJsPBLGINGE+
         MpturYX7WHH9Vorbsk6LBBmnfMWi04lV/UnAlLKzNi3HZh37RJ3wGAPOGeXZLcmehRqW
         Mk/wYsQHrJ8CftUnbgH60fna3xmF50WNvccP04E9+g9kjB3e64HV+iLWegSXl8upBF2E
         fQbAdAqzSOEahCwmDoa+OWur/j8gfeNWQ6Hh9/QoHxcq4kVC7Dr0KiJzA7V3HxcX34Ui
         i+H2Eroz3B58ual9gOgjVBe3rReJunr+twd2LLBOa681XXq63sA+yneM9qqPnHpiDMf1
         aXng==
X-Gm-Message-State: ACrzQf2lpwhpGRCRp4mk0GlNOESJel5rCRu2EyrSi1Hrhkq4jcCQzVGN
	DUI8Xc5iUx1ZGkRhm2s42d4i/eOSaJRUi85uWO8=
X-Google-Smtp-Source: AMsMyM6NLa00zi8rWbV1YjvVb/qqNUdz+qKeOQrEfc73tWohYv2W/VbUmFiBFpGHfNrQyi0HimyzZxXh5lkc0ngSkpk=
X-Received: by 2002:a81:4bcf:0:b0:367:bdfb:d0eb with SMTP id
 y198-20020a814bcf000000b00367bdfbd0ebmr56654861ywa.105.1667960157951; Tue, 08
 Nov 2022 18:15:57 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
 
  
 
 
 <1722758786.127406.1667909706281@localhost> <1E33E6A3-ABB8-4804-B2A2-0E95E853C860@yahoo.com>
In-Reply-To: <1E33E6A3-ABB8-4804-B2A2-0E95E853C860@yahoo.com>
From: Archimedes Gaviola 
Date: Wed, 9 Nov 2022 10:15:32 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Mark Millard 
Cc: Ronald Klop , freebsd-current 
Content-Type: multipart/alternative; boundary="000000000000b6dc8305ed003cfa"
X-Rspamd-Queue-Id: 4N6T8t543pz454n
X-Spamd-Bar: ----
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:2607:f8b0::/32, country:US]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000b6dc8305ed003cfa
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 9, 2022 at 1:37 AM Mark Millard  wrote:

> On Nov 8, 2022, at 04:15, Ronald Klop  wrote:
>
> > Van: Warner Losh 
> > Datum: dinsdag, 8 november 2022 04:28
> > Aan: Archimedes Gaviola  > . . .
> > ...
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40960
> > pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to
> allocate a page
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28672
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192
> >   This means that paging to the swap partition and/or swap file took too
> long (> 30 seconds... that's all that indefinite means). It also means that
> it can't write to backing store dirty pages to give to another process...
> >   Typical reason is that the disk / flash is not responsive to writes
> for some reason. You'll need to find why... I'd look at trims.
> >   Or.... if you can't change the disk... you need to put less memory
> pressure on it..
> >   Warner
> >
> >
> >
> > NB: a way to put less memory pressure on it is not using -j3, but -j2 or
> -j1 in your make command.
> >
>

Hi Mark,


> Extending Ronold's comment: If things are really taking this
> long for the paging I/O, you might actually find, say, -j2
> takes less elapsed time than -j3 because of the latencies
> involved in -j3 causing more overall delay.
>

Yes I'll take these options on lowering down N in the -jN parameter as my
next steps. So far so good with -j3, ongoing build is still observed for 17
hours now.


>
> vm.pfault_oom_attempts=-1 would still be appropriate for avoiding
> I/O kills at any -jN: the smaller -jN just makes the issue less
> likely, not impossible. (Again, presuming sufficient swap/paging
> space if deadlock is to be well avoided.)
>

The ongoing build is at the moment on
/usr/src/contrib/llvm-project/llvm/lib/*. I'm observing from time-to-time
if the error will occur again.


> (I use NVMe or SSD USB media that do not get such long delays but
> fit the power limitations of the context. I have about as little
> on microsd card media as I can get away with in my context. I also
> avoid spinning rust. Thus I've only gotten "indefinite wait buffer"
> or the like back before such was true, long ago.)
>

Okay thanks for sharing this one. Keeping this in my mind just in case I
needed these types of media soon.

Thanks and best regards,
Archimedes

--000000000000b6dc8305ed003cfa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Nov 9, 2022 at 1:37 AM Mark M=
illard <marklmi@yahoo.com> w=
rote:
On Nov 8, =
2022, at 04:15, Ronald Klop <ronald-lists@klop.ws> wrote:



> Van: Warner Losh <imp@bsdimp.com>

> Datum: dinsdag, 8 november 2022 04:28

> Aan: Archimedes Gaviola <archimedes.gaviola@gmail.com

> . . .

> ...

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 40=
96

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096=


> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40=
960

> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to=
 allocate a page

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28=
672

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192=


> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 40=
96

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 81=
92

>=C2=A0 =C2=A0This means that paging to the swap partition and/or swap f=
ile took too long (> 30 seconds... that's all that indefinite means)=
. It also means that it can't write to backing store dirty pages to giv=
e to another process...

>=C2=A0 =C2=A0Typical reason is that the disk / flash is not responsive =
to writes for some reason. You'll need to find why... I'd look at t=
rims.

>=C2=A0 =C2=A0Or.... if you can't change the disk... you need to put=
 less memory pressure on it..

>=C2=A0 =C2=A0Warner

>=C2=A0 =C2=A0

> 

> 

> NB: a way to put less memory pressure on it is not using -j3, but -j2 =
or -j1 in your make command.

> 

Hi Mark,
=C2=A0

Extending Ronold's comment: If things are really taking this

long for the paging I/O, you might actually find, say, -j2

takes less elapsed time than -j3 because of the latencies

involved in -j3 causing more overall delay.

=

Yes I'll take these options on lowering down N in the -jN paramete=
r as my next steps. So far so good with -j3, ongoing build is still observe=
d for 17 hours now.
=C2=A0 



vm.pfault_oom_attempts=3D-1 would still be appropriate for avoiding

I/O kills at any -jN: the smaller -jN just makes the issue less

likely, not impossible. (Again, presuming sufficient swap/paging

space if deadlock is to be well avoided.)

The ongoing build is at the moment on /usr/src/contrib/llvm-project/llvm=
/lib/*. I'm observing from time-to-time if the error will occur again.<=
br>
=C2=A0

(I use NVMe or SSD USB media that do not get such long delays but

fit the power limitations of the context. I have about as little

on microsd card media as I can get away with in my context. I also

avoid spinning rust. Thus I've only gotten "indefinite wait buffer=
"

or the like back before such was true, long ago.)

=

Okay thanks for sharing this one. Keeping this in my mind just i=
n case I needed these types of media soon.

Thanks =
and best regards,
Archimedes



--000000000000b6dc8305ed003cfa--

From nobody Wed Nov  9 12:46:10 2022
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 4N6l8N5s0gz4dJpk
	for ; Wed,  9 Nov 2022 12:46:28 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6l8M3TZmz41f3;
	Wed,  9 Nov 2022 12:46:27 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=mBBBgrkF;
	spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net;
	dmarc=pass (policy=quarantine) header.from=leidinger.net
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id ABD8122072;
	Wed,  9 Nov 2022 13:46:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1667997974;
	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=doKo8cj6/rMau/nbLBTmeZ6G5oBFzU/XSqS0Denjf98=;
	b=mBBBgrkF+0zfdBf5mGWgS2z2nvw1y4KIq48DjHQxHdmJq6XONsZGBU9I2pnUC5U7FlqvUd
	Ht3yQ2h4J+D2GDnaQ/8fYeGSi+kuLuqApUaqeTRSGYOB+IUjMnTkX+I5rYo0mWM4VSCwt5
	6gZFQXTI2x+H493VqLTzEfsRmpiNeoggO8Uq1RYlGz5HUXfNXBL98jiSsskBPH/VrWag/L
	PCojZH30/B/5S7he6qXYWOlQE3pZK9r80tN+I7BAs+Tm5L1NdE08SlkPxxjSlhCh79IezA
	58HhqKHiTe4mGKm4FsMeijDXXxajctzo2ueyiVw51j7BHy35tSEMb3GwhMAufA==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 52C62300B;
	Wed,  9 Nov 2022 13:46:12 +0100 (CET)
Date: Wed, 09 Nov 2022 13:46:10 +0100
Message-ID: <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
From: Alexander Leidinger 
To: Warner Losh , marklmi@yahoo.com, tsoome@freebsd.org
Cc: Li-Wen Hsu , current@freebsd.org
Subject: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main - rc(8):
 Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
In-Reply-To: <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_bMpPAB6BU7wUH7sU0BGV0-m";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Spamd-Bar: ------
X-Spamd-Result: default: False [-6.10 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[bsdimp.com,yahoo.com,freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	DKIM_TRACE(0.00)[leidinger.net:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_FIVE(0.00)[5];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4N6l8M3TZmz41f3
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_bMpPAB6BU7wUH7sU0BGV0-m
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Alexander Leidinger  (from Tue, 08=20=20
Nov=202022 10:50:53 +0100):

> Quoting Warner Losh  (from Mon, 7 Nov 2022 14:23:11 -0700=
):
>
>> =C2=A0
>>
>>       On Mon, Nov 7, 2022 at 4:15 AM Alexander Leidinger=20=20
>>=20 wrote:
>>
>>> Quoting Li-Wen Hsu  (from Mon, 7 Nov 2022 03:39:19 G=
MT):
>>>
>>>> The branch main has been updated by lwhsu:
>>>>
>>>> URL:=C2=A0
>>>> https://cgit.FreeBSD.org/src/commit/?id=3D72a1cb05cd230ce0d12a7180ae65=
ddbba2e0cb6d
>>>>
>>>> commit 72a1cb05cd230ce0d12a7180ae65ddbba2e0cb6d
>>>> Author:=C2=A0 =C2=A0 =C2=A0Li-Wen Hsu 
>>>> AuthorDate: 2022-11-07 03:30:09 +0000
>>>> Commit:=C2=A0 =C2=A0 =C2=A0Li-Wen Hsu 
>>>> CommitDate: 2022-11-07 03:30:09 +0000
>>>>
>>>> =C2=A0 =C2=A0 =C2=A0rc(8): Add a zpoolupgrade rc.d script
>>>>
>>>> =C2=A0 =C2=A0 =C2=A0If a zpool is created by makefs(8), its version is=
 5000, i.e., all
>>>> =C2=A0 =C2=A0 =C2=A0feature flags are off.=C2=A0 Introduce an rc scrip=
t to run `zpool upgrade`
>>>> =C2=A0 =C2=A0 =C2=A0over the assigned zpools on the first boot.=C2=A0 =
This is useful to the
>>>> =C2=A0 =C2=A0 =C2=A0ZFS based VM images built from release(7).
>>>
>>>> diff --git a/share/man/man5/rc.conf.5 b/share/man/man5/rc.conf.5
>>>> index f9ceabc83120..43fa44a5f1cb 100644
>>>> --- a/share/man/man5/rc.conf.5
>>>> +++ b/share/man/man5/rc.conf.5
>>>> @@ -24,7 +24,7 @@
>>>> =C2=A0 .\"
>>>> =C2=A0 .\" $FreeBSD$
>>>> =C2=A0 .\"
>>>> -.Dd August 28, 2022
>>>> +.Dd November 7, 2022
>>>> =C2=A0 .Dt RC.CONF 5
>>>> =C2=A0 .Os
>>>> =C2=A0 .Sh NAME
>>>> @@ -2109,6 +2109,13 @@ A space-separated list of ZFS pool names for=C2=
=A0
>>>> which new pool GUIDs should be
>>>> =C2=A0 assigned upon first boot.
>>>> =C2=A0 This is useful when using a ZFS pool copied from a template, su=
ch=C2=A0
>>>> as a virtual
>>>> =C2=A0 machine image.
>>>> +.It Va zpool_upgrade
>>>> +.Pq Vt str
>>>> +A space-separated list of ZFS pool names for which version should=C2=
=A0
>>>> be upgraded
>>>> +upon first boot.
>>>> +This is useful when using a ZFS pool generated by
>>>> +.Xr makefs 8
>>>> +utility.
>>>
>>> For someone who knows ZFS well, it is clear that only a zpool upgrade=
=C2=A0
>>> is done. Not so experienced people may assume there is a combination=C2=
=A0
>>> of zpool upgrade and zfs upgrade (more so for people which do not know=
=C2=A0
>>> what the difference is). Maybe you want to add some explicit=C2=A0
>>> documentation, that zfs upgrade + feature flags needs to be done by=C2=
=A0
>>> hand.
>>>
>>> And this brings me to a second topic, we don't have an explicit list=C2=
=A0
>>> of features which are supported by the bootloader (I had a look at the=
=C2=A0
>>> zfs and the boot related man pages, if I overlooked a place, then the=
=C2=A0
>>> other places should reference this important part with some text).
>>
>>    =C2=A0
>>    There is a fixed list of features we support in the boot loader:
>>    =C2=A0
>>    /*
>> =C2=A0* List of ZFS features supported for read
>> =C2=A0*/
>> static const char *features_for_read[] =3D {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:lz4_compress",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:hole_birth",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:extensible_dataset",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:embedded_data",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.open-zfs:large_blocks",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:sha512",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:skein",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.zfsonlinux:large_dnode",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.joyent:multi_vdev_crash_dump",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:spacemap_histogram",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:zpool_checkpoint",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:spacemap_v2",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:encryption",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:bookmark_v2",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.zfsonlinux:allocation_classes",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:resilver_defer",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:device_removal",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:obsolete_counts",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.intel:allocation_classes",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.freebsd:zstd_compress",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:bookmark_written",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:head_errlog",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.openzfs:blake3",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 NULL
>> };
>>    =C2=A0
>>    Any feature not on this list will cause the boot loader to=20=20
>>=20reject the pool.
>>    =C2=A0
>>    Whether or not it should do that by default, always, or never is an o=
pen
>>    question. I've thought there should be a 'shoot footing'=20=20
>>=20override that isn't
>>    there today.
>>    =C2=A0
>
> Thanks for the list. For those interested, it is in
> =C2=A0 =C2=A0=C2=A0$SRC/stand/libsa/zfs/zfsimpl.c
>
> Just to make my opinion expressed before explicit again, this should=20=
=20
>=20be documented in a boot / bootloader related man-page, but isn't.
>
> Should the above list be sorted in some way? Maybe in the same order=20=
=20
>=20as the zpool-features lists them (sort by feature name after the=20=20
>=20colon), or alphabetical?

Is it OK if I commit this alphabetical sorting?
---snip---
diff --git a/stand/libsa/zfs/zfsimpl.c b/stand/libsa/zfs/zfsimpl.c
index 6b961f3110a..36c90613e82 100644
--- a/stand/libsa/zfs/zfsimpl.c
+++ b/stand/libsa/zfs/zfsimpl.c
@@ -118,29 +118,29 @@ static vdev_list_t zfs_vdevs;
   * List of ZFS features supported for read
   */
  static const char *features_for_read[] =3D {
-        "org.illumos:lz4_compress",
-        "com.delphix:hole_birth",
-        "com.delphix:extensible_dataset",
-        "com.delphix:embedded_data",
-        "org.open-zfs:large_blocks",
-        "org.illumos:sha512",
-        "org.illumos:skein",
-        "org.zfsonlinux:large_dnode",
-        "com.joyent:multi_vdev_crash_dump",
-        "com.delphix:spacemap_histogram",
-        "com.delphix:zpool_checkpoint",
-        "com.delphix:spacemap_v2",
-        "com.datto:encryption",
          "com.datto:bookmark_v2",
-        "org.zfsonlinux:allocation_classes",
+        "com.datto:encryption",
          "com.datto:resilver_defer",
+        "com.delphix:bookmark_written",
          "com.delphix:device_removal",
+        "com.delphix:embedded_data",
+        "com.delphix:extensible_dataset",
+        "com.delphix:head_errlog",
+        "com.delphix:hole_birth",
          "com.delphix:obsolete_counts",
+        "com.delphix:spacemap_histogram",
+        "com.delphix:spacemap_v2",
+        "com.delphix:zpool_checkpoint",
          "com.intel:allocation_classes",
+        "com.joyent:multi_vdev_crash_dump",
          "org.freebsd:zstd_compress",
-        "com.delphix:bookmark_written",
-        "com.delphix:head_errlog",
+        "org.illumos:lz4_compress",
+        "org.illumos:sha512",
+        "org.illumos:skein",
+        "org.open-zfs:large_blocks",
          "org.openzfs:blake3",
+        "org.zfsonlinux:allocation_classes",
+        "org.zfsonlinux:large_dnode",
          NULL
  };
---snip---

> As Mark already mentioned some flags, I checked the features marked=20=20
>=20as read only (I checked in the zpool-features man page, including=20=20
>=20the dependencies documented there) and here are those not listed in=20=
=20
>=20zfsimpl.c. I would assume as they are read-only compatible, we=20=20
>=20should add them:
> =C2=A0 =C2=A0 com.delphix:async_destroy
> =C2=A0 =C2=A0 com.delphix:bookmarks
> =C2=A0 =C2=A0 org.openzfs:device_rebuild
> =C2=A0 =C2=A0 com.delphix:empty_bpobj
> =C2=A0 =C2=A0 com.delphix:enable_txg
> =C2=A0 =C2=A0 com.joyent:filesystem_limits
> =C2=A0 =C2=A0 com.delphix:livelist
> =C2=A0 =C2=A0 com.delphix:log_spacemap
> =C2=A0 =C2=A0 com.zfsonlinux:project_quota
> =C2=A0 =C2=A0 com.zfsonlinux:userobj_accounting
> =C2=A0 =C2=A0 com.openzfs:zilsaxattr

If my understanding is correct that the read-only compatible parts=20=20
(according=20to the zpool-features man page) are safe to add to the zfs=20=
=20
boot,=20here is what I have only build-tested (relative to the above=20=20
alphabetical=20sorting):
---snip---
--- zfsimpl.c_sorted        2022-11-09 12:55:06.346083000 +0100
+++ zfsimpl.c        2022-11-09 13:01:24.083364000 +0100
@@ -121,24 +121,35 @@
          "com.datto:bookmark_v2",
          "com.datto:encryption",
          "com.datto:resilver_defer",
+        "com.delphix:async_destroy",
          "com.delphix:bookmark_written",
+        "com.delphix:bookmarks",
          "com.delphix:device_removal",
          "com.delphix:embedded_data",
+        "com.delphix:empty_bpobj",
+        "com.delphix:enable_txg",
          "com.delphix:extensible_dataset",
          "com.delphix:head_errlog",
          "com.delphix:hole_birth",
+        "com.delphix:livelist",
+        "com.delphix:log_spacemap",
          "com.delphix:obsolete_counts",
          "com.delphix:spacemap_histogram",
          "com.delphix:spacemap_v2",
          "com.delphix:zpool_checkpoint",
          "com.intel:allocation_classes",
+        "com.joyent:filesystem_limits",
          "com.joyent:multi_vdev_crash_dump",
+        "com.openzfs:zilsaxattr",
+        "com.zfsonlinux:project_quota",
+        "com.zfsonlinux:userobj_accounting",
          "org.freebsd:zstd_compress",
          "org.illumos:lz4_compress",
          "org.illumos:sha512",
          "org.illumos:skein",
          "org.open-zfs:large_blocks",
          "org.openzfs:blake3",
+        "org.openzfs:device_rebuild",
          "org.zfsonlinux:allocation_classes",
          "org.zfsonlinux:large_dnode",
          NULL
---snip---

Anyone able to test some of those or confirms my understanding is=20=20
correct=20and would sign-off on a "reviewed by" level?

Bye,
Alexander.
--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_bMpPAB6BU7wUH7sU0BGV0-m
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNroRIACgkQEg2wmwP4
2IatPQ/9Ec9Cl+RsVO21ljwV/Ed0s1Wr33NjX8xYenpAnVOQ8CritxolkJYuTkUP
0ChSzMx7Pjjih2drT3X8UCtRLlAh5TpQBef1lu8DicurVbCMCu/K8C5RJiaHiS6G
u6KmZR2oGNClh0tyy34i98DM39c7RBYyKk/bCZhHJMZ6HnGqytTwaCeOoRG2SAJM
RAjFlq5/V0pzs6prGwCEcEXhHrdAbSw5ed/9UIKv7ulFIv73GK5g+9HB+SHbnHTJ
tDPYtfVh0MmNqpfvOVnG1QbQ2JTNOj3nON3LLx46+kbIG0oDR/wI6zMwQPsmZvEV
LjvEZz3w8u+4Ca4AZv6WWCAdt1I/5at1byK1R6zSXdonfBuL7CcOKlt/jX3o++Ps
ppVu9RVfP3Tg6zGfMx0S7G43TzQzligXfUyvM8KMj3uzc3bpgK5TJJYNPTv+Pu+U
ur2IUAR9/AP9YwI/wSXtjckWGd586A8nf5QqcLW5DzxrO0ldc4p5nZQQNcJqJabx
9GCp618YqOfM6vKcCgFHyZ6DrqvaVen8uNIRSnO/PwWeD0KmxOIU6uxwfAlnvhzP
CPGnVi8KhkhUhKDqkWE0dpUdHlKVvwZ1l4NUIAQEe9OoAXnQOfZHwShy2mBMbJQI
GQBaKo2XLGjhzeKzhGMqdZdDYfCqoeS+m0P2jyc4xoP6C9FRO+8=
=sKQf
-----END PGP SIGNATURE-----

--=_bMpPAB6BU7wUH7sU0BGV0-m--

From nobody Wed Nov  9 15:54:33 2022
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 4N6qKf0r30z4d989
	for ; Wed,  9 Nov 2022 15:54:46 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6qKd6xGCz4LJ5
	for ; Wed,  9 Nov 2022 15:54:45 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x634.google.com with SMTP id k2so47910424ejr.2
        for ; Wed, 09 Nov 2022 07:54:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=13tPxxBOugeaIMyUngvHrAuU0+t7XVxunInCMO8D008=;
        b=7cj5JaWv2sVoHoCvAHSLkJgZey36StKVLIHN4IOGuFf+CasZrdbEu0LNsIKCNqXQus
         vw/vxmcoKDjVxALzDb46zCtkF6ua2lH9WjmEYXm8idJCk0h6HpTd3NUuoeVq+tItM2Mw
         KKaQGzCCmHjL9ORDqPnip34apDV3uS9Ehg3LYDd2sE/TTb9mdOZ9Qjhu3nrAgOa8Sy8S
         DE+Wgw3y9BvGQTAX0yZDovhMaz5Up9UjGPQx8oeZbs14g5PQ40MiEO9mduUYXpFkOpUs
         O8GECOuqYoeC2vZSY3v0cMS/8AKGpn6gcDckYyZuli7hzXCRsNQTyXLim+kVrSV5Wc10
         KhaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=13tPxxBOugeaIMyUngvHrAuU0+t7XVxunInCMO8D008=;
        b=r/RZytlj4NIJMe3So8RoiaubQmP9RTUg19ZEolbM/lmQd2hYLwmZQTl67aCRyvaXDY
         OLB5cWvuZ0Ib3zJJgcptQ9mmi8BxXazSPzCgqDL6qysgcPQMgZT2IiuRKnIsNC0b2luk
         OWpIQ+zyeJw3KU/08Vdr5WP8Qz0ZW1aRTtmQgolJxEaX1uVIwIWGr6gkL+M4EnDY8xFN
         YrZx2g1/NmqL3pjR38UG6Bqqr7LBLMtbYiGX+8A5vGc3KbK8ICgr7jZwpjfaCDECf68X
         TOfO6tgt5LhukSTpO3Dc9AuukE9xAZvFtMW3EyInwvCfvZRqRgNKkEFd/0QPDxLI8eIC
         X2fw==
X-Gm-Message-State: ACrzQf1YCQUvCGuok51IRdSQ/pfyqx2928nvKpCtxHR9zK8O/nzsXZg4
	K2tg5nIn5uudmqTS/mWaWdtckakLXSD7qsaSwMIgYEoWeck=
X-Google-Smtp-Source: AMsMyM4YlmnvWbrqJ4Av/wuhRVtvuAVjXFCMV62BSFp20iYI2yJJdqR8PBmJpkRyiejKpOca+UvvBFjj/guBQj4eamI=
X-Received: by 2002:a17:906:3b17:b0:7ad:b645:9e3e with SMTP id
 g23-20020a1709063b1700b007adb6459e3emr53327255ejf.140.1668009284557; Wed, 09
 Nov 2022 07:54:44 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net> <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
In-Reply-To: <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
From: Warner Losh 
Date: Wed, 9 Nov 2022 08:54:33 -0700
Message-ID: 
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
To: Alexander Leidinger 
Cc: marklmi@yahoo.com, tsoome@freebsd.org, Li-Wen Hsu , 
	current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000e37acf05ed0bacb8"
X-Rspamd-Queue-Id: 4N6qKd6xGCz4LJ5
X-Spamd-Bar: ----
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:2a00:1450::/32, country:US]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e37acf05ed0bacb8
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 9, 2022 at 5:46 AM Alexander Leidinger 
wrote:

> Quoting Alexander Leidinger  (from Tue, 08
> Nov 2022 10:50:53 +0100):
>
> > Quoting Warner Losh  (from Mon, 7 Nov 2022 14:23:11
> -0700):
> >
> >>
> >>
> >>       On Mon, Nov 7, 2022 at 4:15 AM Alexander Leidinger
> >>  wrote:
> >>
> >>> Quoting Li-Wen Hsu  (from Mon, 7 Nov 2022 03:39:19
> GMT):
> >>>
> >>>> The branch main has been updated by lwhsu:
> >>>>
> >>>> URL:
> >>>>
> https://cgit.FreeBSD.org/src/commit/?id=72a1cb05cd230ce0d12a7180ae65ddbba2e0cb6d
> >>>>
> >>>> commit 72a1cb05cd230ce0d12a7180ae65ddbba2e0cb6d
> >>>> Author:     Li-Wen Hsu 
> >>>> AuthorDate: 2022-11-07 03:30:09 +0000
> >>>> Commit:     Li-Wen Hsu 
> >>>> CommitDate: 2022-11-07 03:30:09 +0000
> >>>>
> >>>>      rc(8): Add a zpoolupgrade rc.d script
> >>>>
> >>>>      If a zpool is created by makefs(8), its version is 5000, i.e.,
> all
> >>>>      feature flags are off.  Introduce an rc script to run `zpool
> upgrade`
> >>>>      over the assigned zpools on the first boot.  This is useful to
> the
> >>>>      ZFS based VM images built from release(7).
> >>>
> >>>> diff --git a/share/man/man5/rc.conf.5 b/share/man/man5/rc.conf.5
> >>>> index f9ceabc83120..43fa44a5f1cb 100644
> >>>> --- a/share/man/man5/rc.conf.5
> >>>> +++ b/share/man/man5/rc.conf.5
> >>>> @@ -24,7 +24,7 @@
> >>>>   .\"
> >>>>   .\" $FreeBSD$
> >>>>   .\"
> >>>> -.Dd August 28, 2022
> >>>> +.Dd November 7, 2022
> >>>>   .Dt RC.CONF 5
> >>>>   .Os
> >>>>   .Sh NAME
> >>>> @@ -2109,6 +2109,13 @@ A space-separated list of ZFS pool names for
> >>>> which new pool GUIDs should be
> >>>>   assigned upon first boot.
> >>>>   This is useful when using a ZFS pool copied from a template, such
> >>>> as a virtual
> >>>>   machine image.
> >>>> +.It Va zpool_upgrade
> >>>> +.Pq Vt str
> >>>> +A space-separated list of ZFS pool names for which version should
> >>>> be upgraded
> >>>> +upon first boot.
> >>>> +This is useful when using a ZFS pool generated by
> >>>> +.Xr makefs 8
> >>>> +utility.
> >>>
> >>> For someone who knows ZFS well, it is clear that only a zpool upgrade
> >>> is done. Not so experienced people may assume there is a combination
> >>> of zpool upgrade and zfs upgrade (more so for people which do not know
> >>> what the difference is). Maybe you want to add some explicit
> >>> documentation, that zfs upgrade + feature flags needs to be done by
> >>> hand.
> >>>
> >>> And this brings me to a second topic, we don't have an explicit list
> >>> of features which are supported by the bootloader (I had a look at the
> >>> zfs and the boot related man pages, if I overlooked a place, then the
> >>> other places should reference this important part with some text).
> >>
> >>
> >>    There is a fixed list of features we support in the boot loader:
> >>
> >>    /*
> >>  * List of ZFS features supported for read
> >>  */
> >> static const char *features_for_read[] = {
> >>         "org.illumos:lz4_compress",
> >>         "com.delphix:hole_birth",
> >>         "com.delphix:extensible_dataset",
> >>         "com.delphix:embedded_data",
> >>         "org.open-zfs:large_blocks",
> >>         "org.illumos:sha512",
> >>         "org.illumos:skein",
> >>         "org.zfsonlinux:large_dnode",
> >>         "com.joyent:multi_vdev_crash_dump",
> >>         "com.delphix:spacemap_histogram",
> >>         "com.delphix:zpool_checkpoint",
> >>         "com.delphix:spacemap_v2",
> >>         "com.datto:encryption",
> >>         "com.datto:bookmark_v2",
> >>         "org.zfsonlinux:allocation_classes",
> >>         "com.datto:resilver_defer",
> >>         "com.delphix:device_removal",
> >>         "com.delphix:obsolete_counts",
> >>         "com.intel:allocation_classes",
> >>         "org.freebsd:zstd_compress",
> >>         "com.delphix:bookmark_written",
> >>         "com.delphix:head_errlog",
> >>         "org.openzfs:blake3",
> >>         NULL
> >> };
> >>
> >>    Any feature not on this list will cause the boot loader to
> >> reject the pool.
> >>
> >>    Whether or not it should do that by default, always, or never is an
> open
> >>    question. I've thought there should be a 'shoot footing'
> >> override that isn't
> >>    there today.
> >>
> >
> > Thanks for the list. For those interested, it is in
> >     $SRC/stand/libsa/zfs/zfsimpl.c
> >
> > Just to make my opinion expressed before explicit again, this should
> > be documented in a boot / bootloader related man-page, but isn't.
> >
> > Should the above list be sorted in some way? Maybe in the same order
> > as the zpool-features lists them (sort by feature name after the
> > colon), or alphabetical?
>
> Is it OK if I commit this alphabetical sorting?
> ---snip---
> diff --git a/stand/libsa/zfs/zfsimpl.c b/stand/libsa/zfs/zfsimpl.c
> index 6b961f3110a..36c90613e82 100644
> --- a/stand/libsa/zfs/zfsimpl.c
> +++ b/stand/libsa/zfs/zfsimpl.c
> @@ -118,29 +118,29 @@ static vdev_list_t zfs_vdevs;
>    * List of ZFS features supported for read
>    */
>   static const char *features_for_read[] = {
> -        "org.illumos:lz4_compress",
> -        "com.delphix:hole_birth",
> -        "com.delphix:extensible_dataset",
> -        "com.delphix:embedded_data",
> -        "org.open-zfs:large_blocks",
> -        "org.illumos:sha512",
> -        "org.illumos:skein",
> -        "org.zfsonlinux:large_dnode",
> -        "com.joyent:multi_vdev_crash_dump",
> -        "com.delphix:spacemap_histogram",
> -        "com.delphix:zpool_checkpoint",
> -        "com.delphix:spacemap_v2",
> -        "com.datto:encryption",
>           "com.datto:bookmark_v2",
> -        "org.zfsonlinux:allocation_classes",
> +        "com.datto:encryption",
>           "com.datto:resilver_defer",
> +        "com.delphix:bookmark_written",
>           "com.delphix:device_removal",
> +        "com.delphix:embedded_data",
> +        "com.delphix:extensible_dataset",
> +        "com.delphix:head_errlog",
> +        "com.delphix:hole_birth",
>           "com.delphix:obsolete_counts",
> +        "com.delphix:spacemap_histogram",
> +        "com.delphix:spacemap_v2",
> +        "com.delphix:zpool_checkpoint",
>           "com.intel:allocation_classes",
> +        "com.joyent:multi_vdev_crash_dump",
>           "org.freebsd:zstd_compress",
> -        "com.delphix:bookmark_written",
> -        "com.delphix:head_errlog",
> +        "org.illumos:lz4_compress",
> +        "org.illumos:sha512",
> +        "org.illumos:skein",
> +        "org.open-zfs:large_blocks",
>           "org.openzfs:blake3",
> +        "org.zfsonlinux:allocation_classes",
> +        "org.zfsonlinux:large_dnode",
>           NULL
>   };
> ---snip---
>

This patch looks good because it's a nop and just tidies things up a bit.

Reviewed by: imp


> > As Mark already mentioned some flags, I checked the features marked
> > as read only (I checked in the zpool-features man page, including
> > the dependencies documented there) and here are those not listed in
> > zfsimpl.c. I would assume as they are read-only compatible, we
> > should add them:
> >     com.delphix:async_destroy
> >     com.delphix:bookmarks
> >     org.openzfs:device_rebuild
> >     com.delphix:empty_bpobj
> >     com.delphix:enable_txg
> >     com.joyent:filesystem_limits
> >     com.delphix:livelist
> >     com.delphix:log_spacemap
> >     com.zfsonlinux:project_quota
> >     com.zfsonlinux:userobj_accounting
> >     com.openzfs:zilsaxattr
>
> If my understanding is correct that the read-only compatible parts
> (according to the zpool-features man page) are safe to add to the zfs
> boot, here is what I have only build-tested (relative to the above
> alphabetical sorting):
> ---snip---
> --- zfsimpl.c_sorted        2022-11-09 12:55:06.346083000 +0100
> +++ zfsimpl.c        2022-11-09 13:01:24.083364000 +0100
> @@ -121,24 +121,35 @@
>           "com.datto:bookmark_v2",
>           "com.datto:encryption",
>           "com.datto:resilver_defer",
> +        "com.delphix:async_destroy",
>           "com.delphix:bookmark_written",
> +        "com.delphix:bookmarks",
>           "com.delphix:device_removal",
>           "com.delphix:embedded_data",
> +        "com.delphix:empty_bpobj",
> +        "com.delphix:enable_txg",
>           "com.delphix:extensible_dataset",
>           "com.delphix:head_errlog",
>           "com.delphix:hole_birth",
> +        "com.delphix:livelist",
> +        "com.delphix:log_spacemap",
>           "com.delphix:obsolete_counts",
>           "com.delphix:spacemap_histogram",
>           "com.delphix:spacemap_v2",
>           "com.delphix:zpool_checkpoint",
>           "com.intel:allocation_classes",
> +        "com.joyent:filesystem_limits",
>           "com.joyent:multi_vdev_crash_dump",
> +        "com.openzfs:zilsaxattr",
> +        "com.zfsonlinux:project_quota",
> +        "com.zfsonlinux:userobj_accounting",
>           "org.freebsd:zstd_compress",
>           "org.illumos:lz4_compress",
>           "org.illumos:sha512",
>           "org.illumos:skein",
>           "org.open-zfs:large_blocks",
>           "org.openzfs:blake3",
> +        "org.openzfs:device_rebuild",
>           "org.zfsonlinux:allocation_classes",
>           "org.zfsonlinux:large_dnode",
>           NULL
> ---snip---
>
> Anyone able to test some of those or confirms my understanding is
> correct and would sign-off on a "reviewed by" level?
>

I'm inclined to strongly NAK this patch, absent some way to test it.
There's no issues today with any of them being absent causing
problems on boot that have been reported. The ZFS that's in the
boot loader is a reduced copy of what's in base and not everything is
supported. There's no urgency here to rush into this. The ones that
are on the list already are for things that we know we support in the
boot loader because we've gone to the trouble to put blake3 or sha512
into it (note: Not all boot loaders will support all ZFS features in the
future... x86 BIOS booting likely is going to have to be frozen at its
current ZFS feature set due to code size issues).

While most of these options look OK on the surface, I'd feel a lot better
if there were tests for these to prove they work. I'd also feel better if
the ZFS experts could explain how those come to be set on a zpool
as well. I'd settle for a good script that could be run as root (better
would be not as root) that would take a filesystem that was created
by makefs -t zfs and turn on these features after an zpool upgrade.
I have the vague outlines of a test suite for the boot loader that I
could see about integrating something like that into, but most of my
time these days is chasing after 'the last bug' in some kboot stuff I'm
working on (which includes issues with our ZFS in the boot loader
integration).

So not a hard no, but I plea for additional scripts to create images
that can be tested.

Warner


> Bye,
> Alexander.
> --
> http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF
>

--000000000000e37acf05ed0bacb8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Nov 9, 2022 at 5:46 AM Alexan=
der Leidinger <Alexander@leid=
inger.net> wrote:
Quoting Alexander Leidinger <Alexander@leidinger.net> (from Tue, 08=
=C2=A0 

Nov 2022 10:50:53 +0100):



> Quoting Warner Losh <imp@bsdimp.com> (from Mon, 7 Nov 2022 14:23:11 -0700):

>

>> =C2=A0

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Mon, Nov 7, 2022 at 4:15 AM Alexander=
 Leidinger=C2=A0 

>> <A=
lexander@leidinger.net> wrote:

>>

>>> Quoting Li-Wen Hsu <lwhsu@freebsd.org> (from Mon, 7 Nov 2022 03:39:19 GM=
T):

>>>

>>>> The branch main has been updated by lwhsu:

>>>>

>>>> URL:=C2=A0

>>>> h=
ttps://cgit.FreeBSD.org/src/commit/?id=3D72a1cb05cd230ce0d12a7180ae65ddbba2=
e0cb6d

>>>>

>>>> commit 72a1cb05cd230ce0d12a7180ae65ddbba2e0cb6d

>>>> Author:=C2=A0 =C2=A0 =C2=A0Li-Wen Hsu <lwhsu@FreeBSD.or=
g>

>>>> AuthorDate: 2022-11-07 03:30:09 +0000

>>>> Commit:=C2=A0 =C2=A0 =C2=A0Li-Wen Hsu <lwhsu@FreeBSD.or=
g>

>>>> CommitDate: 2022-11-07 03:30:09 +0000

>>>>

>>>> =C2=A0 =C2=A0 =C2=A0rc(8): Add a zpoolupgrade rc.d script<=
br>
>>>>

>>>> =C2=A0 =C2=A0 =C2=A0If a zpool is created by makefs(8), it=
s version is 5000, i.e., all

>>>> =C2=A0 =C2=A0 =C2=A0feature flags are off.=C2=A0 Introduce=
 an rc script to run `zpool upgrade`

>>>> =C2=A0 =C2=A0 =C2=A0over the assigned zpools on the first =
boot.=C2=A0 This is useful to the

>>>> =C2=A0 =C2=A0 =C2=A0ZFS based VM images built from release=
(7).

>>>

>>>> diff --git a/share/man/man5/rc.conf.5 b/share/man/man5/rc.=
conf.5

>>>> index f9ceabc83120..43fa44a5f1cb 100644

>>>> --- a/share/man/man5/rc.conf.5

>>>> +++ b/share/man/man5/rc.conf.5

>>>> @@ -24,7 +24,7 @@

>>>> =C2=A0 .\"

>>>> =C2=A0 .\" $FreeBSD$

>>>> =C2=A0 .\"

>>>> -.Dd August 28, 2022

>>>> +.Dd November 7, 2022

>>>> =C2=A0 .Dt RC.CONF 5

>>>> =C2=A0 .Os

>>>> =C2=A0 .Sh NAME

>>>> @@ -2109,6 +2109,13 @@ A space-separated list of ZFS pool =
names for=C2=A0

>>>> which new pool GUIDs should be

>>>> =C2=A0 assigned upon first boot.

>>>> =C2=A0 This is useful when using a ZFS pool copied from a =
template, such=C2=A0

>>>> as a virtual

>>>> =C2=A0 machine image.

>>>> +.It Va zpool_upgrade

>>>> +.Pq Vt str

>>>> +A space-separated list of ZFS pool names for which versio=
n should=C2=A0

>>>> be upgraded

>>>> +upon first boot.

>>>> +This is useful when using a ZFS pool generated by

>>>> +.Xr makefs 8

>>>> +utility.

>>>

>>> For someone who knows ZFS well, it is clear that only a zpool =
upgrade=C2=A0

>>> is done. Not so experienced people may assume there is a combi=
nation=C2=A0

>>> of zpool upgrade and zfs upgrade (more so for people which do =
not know=C2=A0

>>> what the difference is). Maybe you want to add some explicit=
=C2=A0

>>> documentation, that zfs upgrade + feature flags needs to be do=
ne by=C2=A0

>>> hand.

>>>

>>> And this brings me to a second topic, we don't have an exp=
licit list=C2=A0

>>> of features which are supported by the bootloader (I had a loo=
k at the=C2=A0

>>> zfs and the boot related man pages, if I overlooked a place, t=
hen the=C2=A0

>>> other places should reference this important part with some te=
xt).

>>

>>=C2=A0 =C2=A0 =C2=A0

>>=C2=A0 =C2=A0 There is a fixed list of features we support in the b=
oot loader:

>>=C2=A0 =C2=A0 =C2=A0

>>=C2=A0 =C2=A0 /*

>> =C2=A0* List of ZFS features supported for read

>> =C2=A0*/

>> static const char *features_for_read[] =3D {

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:lz4_compress",<=
br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:hole_birth",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:extensible_dataset&q=
uot;,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:embedded_data",=


>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.open-zfs:large_blocks",=


>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:sha512",

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:skein",

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.zfsonlinux:large_dnode"=
,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.joyent:multi_vdev_crash_dump=
",

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:spacemap_histogram&q=
uot;,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:zpool_checkpoint&quo=
t;,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:spacemap_v2",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:encryption",

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:bookmark_v2",

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.zfsonlinux:allocation_classe=
s",

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:resilver_defer",<=
br>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:device_removal"=
,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:obsolete_counts"=
;,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.intel:allocation_classes&quo=
t;,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.freebsd:zstd_compress",=


>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:bookmark_written&quo=
t;,

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:head_errlog",
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.openzfs:blake3",

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 NULL

>> };

>>=C2=A0 =C2=A0 =C2=A0

>>=C2=A0 =C2=A0 Any feature not on this list will cause the boot load=
er to=C2=A0 

>> reject the pool.

>>=C2=A0 =C2=A0 =C2=A0

>>=C2=A0 =C2=A0 Whether or not it should do that by default, always, =
or never is an open

>>=C2=A0 =C2=A0 question. I've thought there should be a 'sho=
ot footing'=C2=A0 

>> override that isn't

>>=C2=A0 =C2=A0 there today.

>>=C2=A0 =C2=A0 =C2=A0

>

> Thanks for the list. For those interested, it is in

> =C2=A0 =C2=A0=C2=A0$SRC/stand/libsa/zfs/zfsimpl.c

>

> Just to make my opinion expressed before explicit again, this should=
=C2=A0 

> be documented in a boot / bootloader related man-page, but isn't.<=
br>
>

> Should the above list be sorted in some way? Maybe in the same order=
=C2=A0 

> as the zpool-features lists them (sort by feature name after the=C2=A0=
 

> colon), or alphabetical?



Is it OK if I commit this alphabetical sorting?

---snip---

diff --git a/stand/libsa/zfs/zfsimpl.c b/stand/libsa/zfs/zfsimpl.c

index 6b961f3110a..36c90613e82 100644

--- a/stand/libsa/zfs/zfsimpl.c

+++ b/stand/libsa/zfs/zfsimpl.c

@@ -118,29 +118,29 @@ static vdev_list_t zfs_vdevs;

=C2=A0 =C2=A0* List of ZFS features supported for read

=C2=A0 =C2=A0*/

=C2=A0 static const char *features_for_read[] =3D {

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:lz4_compress",

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:hole_birth",

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:extensible_dataset",
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:embedded_data",

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.open-zfs:large_blocks",

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:sha512",

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:skein",

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.zfsonlinux:large_dnode",

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.joyent:multi_vdev_crash_dump",<=
br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:spacemap_histogram",
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:zpool_checkpoint",

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:spacemap_v2",

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:encryption",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:bookmark_v2",

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.zfsonlinux:allocation_classes",=


+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:encryption",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:resilver_defer",
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:bookmark_written",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:device_removal",<=
br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:embedded_data",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:extensible_dataset",
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:head_errlog",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:hole_birth",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:obsolete_counts",=


+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:spacemap_histogram",
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:spacemap_v2",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:zpool_checkpoint",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.intel:allocation_classes"=
,

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.joyent:multi_vdev_crash_dump",<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.freebsd:zstd_compress",
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:bookmark_written",

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:head_errlog",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:lz4_compress",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:sha512",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:skein",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.open-zfs:large_blocks",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.openzfs:blake3",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.zfsonlinux:allocation_classes",=


+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.zfsonlinux:large_dnode",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NULL

=C2=A0 };

---snip---

This patch looks good becaus=
e it's a nop and just tidies things up a bit.

=
Reviewed by: imp
=C2=A0

> As Mark already mentioned some flags, I checked the features marked=C2=
=A0 

> as read only (I checked in the zpool-features man page, including=C2=
=A0 

> the dependencies documented there) and here are those not listed in=C2=
=A0 

> zfsimpl.c. I would assume as they are read-only compatible, we=C2=A0 <=
br>
> should add them:

> =C2=A0 =C2=A0 com.delphix:async_destroy

> =C2=A0 =C2=A0 com.delphix:bookmarks

> =C2=A0 =C2=A0 org.openzfs:device_rebuild

> =C2=A0 =C2=A0 com.delphix:empty_bpobj

> =C2=A0 =C2=A0 com.delphix:enable_txg

> =C2=A0 =C2=A0 com.joyent:filesystem_limits

> =C2=A0 =C2=A0 com.delphix:livelist

> =C2=A0 =C2=A0 com.delphix:log_spacemap

> =C2=A0 =C2=A0 com.zfsonlinux:project_quota

> =C2=A0 =C2=A0 com.zfsonlinux:userobj_accounting

> =C2=A0 =C2=A0 com.openzfs:zilsaxattr



If my understanding is correct that the read-only compatible parts=C2=A0 
(according to the zpool-features man page) are safe to add to the zfs=C2=A0=
 

boot, here is what I have only build-tested (relative to the above=C2=A0 
alphabetical sorting):

---snip---

--- zfsimpl.c_sorted=C2=A0 =C2=A0 =C2=A0 =C2=A0 2022-11-09 12:55:06.3460830=
00 +0100

+++ zfsimpl.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 2022-11-09 13:01:24.083364000 +010=
0

@@ -121,24 +121,35 @@

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:bookmark_v2",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:encryption",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.datto:resilver_defer",
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:async_destroy",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:bookmark_written"=
,

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:bookmarks",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:device_removal",<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:embedded_data",
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:empty_bpobj",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:enable_txg",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:extensible_dataset&quo=
t;,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:head_errlog",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:hole_birth",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:livelist",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:log_spacemap",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:obsolete_counts",=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:spacemap_histogram&quo=
t;,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:spacemap_v2",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.delphix:zpool_checkpoint"=
,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.intel:allocation_classes"=
,

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.joyent:filesystem_limits",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.joyent:multi_vdev_crash_dump&q=
uot;,

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.openzfs:zilsaxattr",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.zfsonlinux:project_quota",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "com.zfsonlinux:userobj_accounting",=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.freebsd:zstd_compress",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:lz4_compress",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:sha512",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.illumos:skein",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.open-zfs:large_blocks",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.openzfs:blake3",

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.openzfs:device_rebuild",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.zfsonlinux:allocation_classes&=
quot;,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "org.zfsonlinux:large_dnode",<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NULL

---snip---



Anyone able to test some of those or confirms my understanding is=C2=A0 
correct and would sign-off on a "reviewed by" level?

I'm inclined to strongly NAK this patch, absent=
 some way to test it.
There's no issues today with any of the=
m being absent causing
problems on boot that have been reported. =
The ZFS that's in the
boot loader is a reduced copy of what&#=
39;s in base and not everything is
supported. There's no urge=
ncy here to rush into this. The ones that
are on the list already=
 are for things that we know we support in the
boot loader becaus=
e we've gone to the trouble to put blake3 or sha512
into it (=
note: Not all boot loaders will support all ZFS features in the
f=
uture... x86 BIOS booting likely is going to have to be frozen at its
=

current ZFS feature set due to code size issues).

=

While most of these options look OK on the surface, I'd feel a lot=
 better
if there were tests for these to prove they work. I'd=
 also feel better if
the ZFS experts could explain how those come=
 to be set on a zpool
as well. I'd settle for a good script t=
hat could be run as root (better
would be not as root) that would=
 take a filesystem that was created
by makefs -t zfs and turn on =
these features after an zpool upgrade.
I have the vague outlines =
of a test suite for the boot loader that I
could see about integr=
ating something like that into, but most of my
time these days is=
 chasing after 'the last bug' in some kboot stuff I'm
working on (which includes issues with our ZFS in the boot loader
integration).

So not a hard no, but I plea for a=
dditional scripts to create images
that can be tested.
=

Warner
=C2=A0

Bye,

Alexander.

-- 

h=
ttp://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF=


htt=
p://www.FreeBSD.org=C2=A0 =C2=A0 netchild@FreeBSD.org=C2=A0 : PGP 0x8F3=
1830F9F2772BF




--000000000000e37acf05ed0bacb8--

From nobody Wed Nov  9 19:02:55 2022
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 4N6vVw6ccBz4V4cx
	for ; Wed,  9 Nov 2022 19:03:04 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4N6vVw3cwwz3gyN;
	Wed,  9 Nov 2022 19:03:04 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 228931;
 Wed, 9 Nov 2022 20:02:56 +0100
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 \(3696.120.41.1.1\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: "Patrick M. Hausen" 
In-Reply-To:
 
Date: Wed, 9 Nov 2022 20:02:55 +0100
Cc: Alexander Leidinger , Mark Millard
 , tsoome@freebsd.org, Li-Wen Hsu ,
 current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N6vVw3cwwz3gyN
X-Spamd-Bar: ----
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:16188, ipnet:217.29.32.0/20, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

Hi all,

> Am 09.11.2022 um 16:54 schrieb Warner Losh :
> >>    There is a fixed list of features we support in the boot loader:
> >>    [...]=20
> >>    Any feature not on this list will cause the boot loader to =20
> >> reject the pool.

I admit that I do not grasp the full implications of this thread and the =
proposed
and debated changes. Does that imply that a simple "zpool upgrade" of =
the
boot/root pool might lead to an unbootable system in the future - even =
if the
boot loader is upgraded as it should, too?

Kind regards, thanks for some insight,
Patrick=

From nobody Wed Nov  9 19:39:49 2022
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 4N6wKx6FHhz4VBph
	for ; Wed,  9 Nov 2022 19:40:21 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6wKx3FvCz3mwV;
	Wed,  9 Nov 2022 19:40:21 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id 5912D226F1;
	Wed,  9 Nov 2022 20:40:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668022815;
	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=YVY2QMHUuyobbaQZ0VBQD6UrvHqoV5tqWA1jLecNajc=;
	b=NN1sXY+ZYTrHYgtoWXPdjKXn3ZI6jyYST8nh3zlWdNsOHpcOU10SrepvAEtIMFobF8oQ/n
	p3qmDCZFHSRdCuIS5k8R98rmpgfgIez/T7XyVLDPdMef70J8EjA9WeDWmZsrC2AJc2viMv
	O94E99IN7N6ukM0TlvqkIJf+VGvUXjBeoSwOKh2HzjhgkD0Iw22wj4cgEpf64QpbIAAP/x
	x18C+yKqt0qi9WlCIu3tS72TBq5JkSYCOrqMvHkgk41rfpWEg8LkpK3PRpNYZQVJn3sOCD
	eQodvSt2O2JSE2d6Rdvvda8tPDf96XufGMNfiKLJOD0Z2YzYiK7Pgl/CIWuJng==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 562F9368C;
	Wed,  9 Nov 2022 20:39:51 +0100 (CET)
Date: Wed, 09 Nov 2022 20:39:49 +0100
Message-ID: <20221109203949.Horde.qIUauGgF-S3rZjw2-w-VIZT@webmail.leidinger.net>
From: Alexander Leidinger 
To: Warner Losh 
Cc: marklmi@yahoo.com, tsoome@freebsd.org, Li-Wen Hsu ,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
In-Reply-To: 
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_iRyGHLeLeeS0LMDvtdHFkCg";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4N6wKx3FvCz3mwV
X-Spamd-Bar: ----
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:34240, ipnet:89.238.64.0/18, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_iRyGHLeLeeS0LMDvtdHFkCg
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Warner Losh  (from Wed, 9 Nov 2022 08:54:33 -0700):

> On Wed, Nov 9, 2022 at 5:46 AM Alexander Leidinger 
> wrote:
>
>> Quoting Alexander Leidinger  (from Tue, 08
>> Nov 2022 10:50:53 +0100):

>> > Should the above list be sorted in some way? Maybe in the same order
>> > as the zpool-features lists them (sort by feature name after the
>> > colon), or alphabetical?
>>
>> Is it OK if I commit this alphabetical sorting?

[diff of feature-sorting]

>
> This patch looks good because it's a nop and just tidies things up a bit.
>
> Reviewed by: imp

Will do later.

>> > As Mark already mentioned some flags, I checked the features marked
>> > as read only (I checked in the zpool-features man page, including
>> > the dependencies documented there) and here are those not listed in
>> > zfsimpl.c. I would assume as they are read-only compatible, we
>> > should add them:
>> >     com.delphix:async_destroy
>> >     com.delphix:bookmarks
>> >     org.openzfs:device_rebuild
>> >     com.delphix:empty_bpobj
>> >     com.delphix:enable_txg
>> >     com.joyent:filesystem_limits
>> >     com.delphix:livelist
>> >     com.delphix:log_spacemap
>> >     com.zfsonlinux:project_quota
>> >     com.zfsonlinux:userobj_accounting
>> >     com.openzfs:zilsaxattr
>>
>> If my understanding is correct that the read-only compatible parts
>> (according to the zpool-features man page) are safe to add to the zfs
>> boot, here is what I have only build-tested (relative to the above
>> alphabetical sorting):
>> ---snip---
>> --- zfsimpl.c_sorted        2022-11-09 12:55:06.346083000 +0100
>> +++ zfsimpl.c        2022-11-09 13:01:24.083364000 +0100
>> @@ -121,24 +121,35 @@
>>           "com.datto:bookmark_v2",
>>           "com.datto:encryption",
>>           "com.datto:resilver_defer",
>> +        "com.delphix:async_destroy",
>>           "com.delphix:bookmark_written",
>> +        "com.delphix:bookmarks",
>>           "com.delphix:device_removal",
>>           "com.delphix:embedded_data",
>> +        "com.delphix:empty_bpobj",
>> +        "com.delphix:enable_txg",
>>           "com.delphix:extensible_dataset",
>>           "com.delphix:head_errlog",
>>           "com.delphix:hole_birth",
>> +        "com.delphix:livelist",
>> +        "com.delphix:log_spacemap",
>>           "com.delphix:obsolete_counts",
>>           "com.delphix:spacemap_histogram",
>>           "com.delphix:spacemap_v2",
>>           "com.delphix:zpool_checkpoint",
>>           "com.intel:allocation_classes",
>> +        "com.joyent:filesystem_limits",
>>           "com.joyent:multi_vdev_crash_dump",
>> +        "com.openzfs:zilsaxattr",
>> +        "com.zfsonlinux:project_quota",
>> +        "com.zfsonlinux:userobj_accounting",
>>           "org.freebsd:zstd_compress",
>>           "org.illumos:lz4_compress",
>>           "org.illumos:sha512",
>>           "org.illumos:skein",
>>           "org.open-zfs:large_blocks",
>>           "org.openzfs:blake3",
>> +        "org.openzfs:device_rebuild",
>>           "org.zfsonlinux:allocation_classes",
>>           "org.zfsonlinux:large_dnode",
>>           NULL
>> ---snip---
>>
>> Anyone able to test some of those or confirms my understanding is
>> correct and would sign-off on a "reviewed by" level?
>>
>
> I'm inclined to strongly NAK this patch, absent some way to test it.
> There's no issues today with any of them being absent causing
> problems on boot that have been reported. The ZFS that's in the
> boot loader is a reduced copy of what's in base and not everything is
> supported. There's no urgency here to rush into this. The ones that
> are on the list already are for things that we know we support in the
> boot loader because we've gone to the trouble to put blake3 or sha512
> into it (note: Not all boot loaders will support all ZFS features in the
> future... x86 BIOS booting likely is going to have to be frozen at its
> current ZFS feature set due to code size issues).
>
> While most of these options look OK on the surface, I'd feel a lot better
> if there were tests for these to prove they work. I'd also feel better if
> the ZFS experts could explain how those come to be set on a zpool
> as well. I'd settle for a good script that could be run as root (better
> would be not as root) that would take a filesystem that was created
> by makefs -t zfs and turn on these features after an zpool upgrade.
> I have the vague outlines of a test suite for the boot loader that I
> could see about integrating something like that into, but most of my
> time these days is chasing after 'the last bug' in some kboot stuff I'm
> working on (which includes issues with our ZFS in the boot loader
> integration).
>
> So not a hard no, but I plea for additional scripts to create images
> that can be tested.

I didn't want to commit untested or unverified stuff. I fully agree=20=20
with=20your reasoning.

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_iRyGHLeLeeS0LMDvtdHFkCg
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsAgQACgkQEg2wmwP4
2IZnLg//U34KrUAmwXUtGme8g9fJAZgrXMVotbGsyQVGRZPjKSGDh4W+pc38K2TW
FUMV/h/WAbUdhtv6tRZAJmJ1mkrP01RmfRMSsea6L9hBoO5E+0QZ/32EMTBbHYtT
awgrbQXgF9TGRKonQgxvTzBCo9NQcdXHz5V9OLl8SlgSwLKbjyVyKRyWfG6ysaF/
9vZ97VZ9OOa6NRUzWCZ/R5ZDILYuLPV8fUpTFpLQ5tOPY41KpJd/KE9qc9HZw61y
jWwbHlNdhCs5kvwLiJqoZ99z7wisSGjXqAdQHBkarNct3I2TPD5AthClJ7ffwUP0
WQ0wVtOMemtTDeo2qnX4I7wH7XWXtPuVgaKQcWsr39GVIq8KjY8ctlUMh2+5GqGW
aUvkat+W2/wEO8e702k+Gd528z1eluQScYyNIzZLPnHGlFw+qwz44Lw7ETA5cxLc
C4l2aIsBQ5b8wA5MFlvvrhHsc0vnz671kIiwqqObfJvXBMSwFCgH5Yhi1pAvD0DF
l6m+JVm5SS7eRe7+/yj5FtVGJxXpcIHggMazmCacREtSE1VYrYYHBTDCrcjTnET2
3FWBTbITBWQGq3hO2cxJPs8MxkMh7PFCrOd1YUThav3lHwKSl2G7MhVqtAMopQYs
lClJjrVd11Tvt7O08O11/oc7UdiMX2k+3aW+VoexVfsGH0R1hVo=
=y0JE
-----END PGP SIGNATURE-----

--=_iRyGHLeLeeS0LMDvtdHFkCg--

From nobody Wed Nov  9 19:45:09 2022
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 4N6wRq2WTxz4VNHD
	for ; Wed,  9 Nov 2022 19:45:27 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6wRp6PC0z3pGW;
	Wed,  9 Nov 2022 19:45:26 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id F1A86226F7;
	Wed,  9 Nov 2022 20:45:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668023113;
	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=wyaLFvmipII/s9rwcdBnVKA/iDqQd0PZx/pUfeasxOE=;
	b=d+2XQgt6aCBUYYl0xRR9aPL0PzWknscLfICW+rVHgYL/MMwIss4vAO9ndKiiRigtW3IvSN
	nLyqb8mg6Aicib3TwHrWuAVDCdcptKL/YTek1E/rPuy/f74vv7KhZMZvJGUcEWdjtGd5Pq
	ir8kvua/Y0NtrHIBs7Pem7ibDmYpX1lFeqHmSPot1t2Ggrl8g9+G2BO6y+PikPTWocoaXf
	+El3jM8iSMfp6SRP3cPx1e2zhHdYRdDIPpLLyG9iLWn22stwGUH6sosesNzxI/jIV1c2RM
	ftKvU3UoF0kQKWkPvMYEO2cMyx3I1V/wJH+fwAgmGKXsaHidh73ZVFPnuLKHiw==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 1EA70328A;
	Wed,  9 Nov 2022 20:45:10 +0100 (CET)
Date: Wed, 09 Nov 2022 20:45:09 +0100
Message-ID: <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
From: Alexander Leidinger 
To: "Patrick M. Hausen" 
Cc: Warner Losh , Mark Millard ,
        tsoome@freebsd.org, Li-Wen Hsu ,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
In-Reply-To: <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_-vjo0oXfJ21v_ayYXH5qY2Q";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4N6wRp6PC0z3pGW
X-Spamd-Bar: ----
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:34240, ipnet:2a00:1828::/32, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_-vjo0oXfJ21v_ayYXH5qY2Q
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022=20=20
20:02:55=20+0100):

> Hi all,
>
>> Am 09.11.2022 um 16:54 schrieb Warner Losh :
>> >>    There is a fixed list of features we support in the boot loader:
>> >>    [...]
>> >>    Any feature not on this list will cause the boot loader to
>> >> reject the pool.
>
> I admit that I do not grasp the full implications of this thread and=20=
=20
>=20the proposed
> and debated changes. Does that imply that a simple "zpool upgrade" of the
> boot/root pool might lead to an unbootable system in the future - even if=
 the
> boot loader is upgraded as it should, too?

For a recent pool (zpool get all rpool | grep -q feature && echo=20=20
recent=20enough): no.

But "zpool set feature@edonr=3Denabled rpool" (or any other feature not=20=
=20
in=20the list we talk about) would render it unbootable.

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_-vjo0oXfJ21v_ayYXH5qY2Q
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsA0UACgkQEg2wmwP4
2IbvZA//Qq2kiVFskVdrxgUt6pXRSNE4/OvIbRIaTQB+ZdEsF1eH7bgWXOt1bT2F
WIkA+iKhCj6IEMVuMBNUWHmLSwLm5u7yQoJ0mJnDWgCcMif+WW1JWxicBEmuP060
Zk6fmtic6vxZj1cSXiTMamIdq7Q5oQcBrjpwPmTdIwLplKgJ5AjWDoJFHTb7+aMv
upkz8jq0J26klmy1tdUKyi4OkUIecnuM3RzM+ocTHz0+c+Y7+Sr8bpaUk/SwxfEL
58dXAKtQ/lukBb1MbiZI/zacufM/MXgGf9biC4dv7VPEYsWzS27sr+yREo0DLMZo
uK5ZoSHSArcNh/rkrxX9RpzEp4TgAkOJYk6mu8RH+OKgDzt2ZD2FE4D4wW50Qyv5
GPOWJo2OJ0atWJNuXjMWU1T1KFz167eCnr2X/RSe1WdFUC3Ph77/5rmvXPiy89JL
3ljPdX0TJK9pmSr0Vx7VrHbRLcfSf3tQR23rDuy1esb52/LXJs/WU/BUk8gKA3lg
+sZwrZPm3AQA1zz43S1qC7ySReEPgkQgmj7QP8RLyOOzob9cJ7Onu50DUZzhFKRd
KiwrfhTHdYneAS9SGrHXzVKBehYq29NPsLgrHPiTeJHVQ1anv5xIGa1RAv8ZVAqO
6rztE26ME6T9rTX4btSIPW2JStTuwuQp3yNK2XdpbY7OA26eZZ0=
=kLm5
-----END PGP SIGNATURE-----

--=_-vjo0oXfJ21v_ayYXH5qY2Q--

From nobody Wed Nov  9 19:47:36 2022
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 4N6wVm1xFNz4XBgv
	for ; Wed,  9 Nov 2022 19:48:00 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits)
	 client-signature ECDSA (P-256))
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6wVm02cRz3qCv;
	Wed,  9 Nov 2022 19:48:00 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id A5D7A2275D;
	Wed,  9 Nov 2022 20:47:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668023274;
	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=dgVXiI/T7sMbhFlRAcGWPEE/VHhF/sRpycQa8h6J8x4=;
	b=kVzDmzfCPBbG0OKNcT7dvRIHTQNz431QP7hSgJfW7JawozL27xSarcR9JNXIs5j1fye+4c
	AO0CmeBp7yFy0j68la/l7cQlGP4mXlLBngxWXWD2pdTswp78ii7nCYG4V11mWJXk+SBRWB
	Wn5mKK0VVSwsZzsVTWi4A7BCuOrw66HyecNRpXSWShs8746kZ7skbexJ1Ut7lsSRZjefsU
	V/tu67DzQNp0LMJlagIHJk7M3j/hbjV/ivC235yKjZWbP6xcldaK62l7JAr4+w//vV9reh
	BUWTqnlvGjOsC6bshisBZheNFme5sDkXMFjHilPuo3039NcLhYzdqAnC54DZdg==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 4D10F34A2;
	Wed,  9 Nov 2022 20:47:36 +0100 (CET)
Date: Wed, 09 Nov 2022 20:47:36 +0100
Message-ID: <20221109204736.Horde.u-t3-sSaTA023DA3Tib0oV4@webmail.leidinger.net>
From: Alexander Leidinger 
To: Warner Losh 
Cc: marklmi@yahoo.com, tsoome@freebsd.org, Li-Wen Hsu ,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
In-Reply-To: 
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_a9S7OEUsez6ZAQpH6ZAXftv";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4N6wVm02cRz3qCv
X-Spamd-Bar: ----
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:34240, ipnet:89.238.64.0/18, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_a9S7OEUsez6ZAQpH6ZAXftv
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Warner Losh  (from Wed, 9 Nov 2022 08:54:33 -0700):

> as well. I'd settle for a good script that could be run as root (better
> would be not as root) that would take a filesystem that was created
> by makefs -t zfs and turn on these features after an zpool upgrade.
> I have the vague outlines of a test suite for the boot loader that I
> could see about integrating something like that into, but most of my
> time these days is chasing after 'the last bug' in some kboot stuff I'm
> working on (which includes issues with our ZFS in the boot loader
> integration).

How would you test a given image? bhyve/qemu/...?

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_a9S7OEUsez6ZAQpH6ZAXftv
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsA9cACgkQEg2wmwP4
2Ib4Eg//Z9+WzIuzqEEHueKuAUvXxr2MFaFuz0OvD0PZAh/l78U3rZ+Jzr24HtMO
inu0jUaTphgNavh9HOfVF3B2f6SHM+eiORBtPvIgXL6P9E1A8Mjkkgbo1ZMR0rqQ
pbu7PwIcyGEjXEd3S8X8zMK8WUcfW7RxnP6BKBrann//+8Eo0hmwET2O4WSndM0e
9+G2bCfPBfuj3xAmGDMc788YCEhs53doeGGcocZ0gZlytMIvsx11Xecy0F67alyr
SZlsEi77DXvE1Nyxu8F6t18k7NRkjL3njdiJfwcChIELrcwvp/lcJvn2Q/eoWFJI
avzqIZfx/jHpHq+8X3vsiUdPjZqR1ny+04cf3ch8vrjnbbLe/vEuyxo/Y79zKlVC
qF36ixrVRliCDVu60wkpcH0cl8VuaqcwRw32u51yLwEYvXcpEJxuLmX/eLcdfUBk
GAAsfsB5X+lq4doUkjmr0WrrlsK0kionnqU5v6r8shi2yaVOCsrqBbhrM6LV4Rs9
6OMrIUnt+CxBnvwI64SFA1cOxTTMmE0i81nBpYO58EtPoGpzzFLDmDZjOC+cOzxF
rgbNwn2xrkPi2tVyxRPUFkK2C7JH1YF5/4kyytyQT4ax/BhVi52VjLJTMWPnLv4T
hC+nzOxhFJBaNbs3ZM04NI5CXY/Rp3slcq+RsgWLRqnzuwYyE4U=
=oxbs
-----END PGP SIGNATURE-----

--=_a9S7OEUsez6ZAQpH6ZAXftv--

From nobody Wed Nov  9 19:49:37 2022
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 4N6wXg6mBfz4XCHQ
	for ; Wed,  9 Nov 2022 19:49:39 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4N6wXg5h2gz3r4S;
	Wed,  9 Nov 2022 19:49:39 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 00334F;
 Wed, 9 Nov 2022 20:49:38 +0100
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 \(3696.120.41.1.1\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: "Patrick M. Hausen" 
In-Reply-To:
 <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
Date: Wed, 9 Nov 2022 20:49:37 +0100
Cc: Warner Losh , Mark Millard ,
 tsoome@freebsd.org, Li-Wen Hsu , current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AFBB434-BB3B-4B5A-AB32-11DAFD03A2AD@hausen.com>
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
To: Alexander Leidinger 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N6wXg5h2gz3r4S
X-Spamd-Bar: ----
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:16188, ipnet:217.29.32.0/20, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> Am 09.11.2022 um 20:45 schrieb Alexander Leidinger =
:
> But "zpool set feature@edonr=3Denabled rpool" (or any other feature =
not in the list we talk about) would render it unbootable.

Sorry, just to be sure. So an active change of e.g. checksum or =
compression algorithm
might render the system unbootable but a zpool upgrade never will? At =
least not intentionally? ;-)

Thanks,
Patrick=

From nobody Wed Nov  9 19:51:31 2022
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 4N6wbH2109z4XCJJ
	for ; Wed,  9 Nov 2022 19:51:55 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6wbG6bFjz3sfS
	for ; Wed,  9 Nov 2022 19:51:54 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668023512; bh=ctG13hnhfMacOtgIGRDHGIeL8WzbNeNyWSuroH9tqpU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PwjHqDA3NjfvenfB3GNEz0sX4geuCNkQgAbVUdibPmKfrBJyjQr8xFGMdW4IOfgSbTNJfQUIHdDNvDKm0/+bT5Nyqm3MbqpvA4a+qep9YkEmkKgfWfPr/YBXpxZCZzzsQw4Gc3rFmu/p/OaVC28XTMvQQpoLlm7svelm5ENdd/YLwexziDRuRTlSW7Glb14YanGnHtI9TE8SktPmbs6dxMzJCK4e4HgkA5oU2QalKTU0Q2dbKgZnHNsuxLItVGIwRMb6yfD7enS3O6qVIB+Sy9n1DAxMgJJSHPwsUicW0Ly1OcBOT2/in4RXKRRGNFhWHdlmosG+XlgkXXGSMWqUjQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668023512; bh=wbuGX30dNAwHhweUweCjxe2uW/+OBrv3rTdjrVVr9WT=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=RhDcd9q5VH0F35afDYa6FhbPZTD/gHgtDPLlUXzQbyIWwc3AzdPwuDIegMSWSe3WqD2FRX4PD0QmtJp+xhwPSIh2WqNQoFiHH++3aWTsM/dLMrPs3Rl3A95wiLQs+yNM1Aiq48I47vIteh+oqlPtzXPlFV9mEnTv4rPRAj0XSjuByxTx0GoeLOHlH46aB7TtZUOOMy6le9NjwrqBekuJVR7618XvjtC7c8k36znqPFRy0L9rIcwYV5PB1teegJYYi/yyT4rd75j03uXOGhaN4ZNi07Y97O06rlVxjiN2UAYOQb9WY+ELQ2SjwcLIua/s0yrPN+ar7DwUmQ/iE+lmCg==
X-YMail-OSG: 2aEpe80VM1lND5zcgSX2Fs0YFrR3npp1cnaVtbwpIHKsS5J6PkCfUC7YMhsAYS8
 A02bevaTCnnO36o8ijjDbhLZq4iyG7aUTkwDja2mg7Cr3FoZApyqW8b8Ggx0xQIvV5uBnKSTp9Ik
 K7Z8cGNHQQlLqNPu3V4rUfGVNYxdNucEGAjeqEIQc7FwTyRwrMcIfastWZhbcJyV65P55sGOy3G5
 7eSMo2gIbhy7GsEA5iQfSNR3dNs4MumOCwg95llYYlLVZfz6wVlpt24erwwpbcUO9lH_NZy5zGL8
 4.a1X3Jm2byeRVAoi_yIuHEq5zGFrWO859Unewc_hae.0aQVJyRY279Wzat4prolQVTTh2xvA657
 o3Ah_oNZCsnZRJWogjdI_RuFXUCAF_z1oe7eGRJ1urM34g_F_5k5Ymp50Xh8JYrXtiyUO0zRKjNE
 t55RUl0objXCqspmxco0bMCYoqce1SxHis5D5eTBV62y8b2rjc325tdNXqSqX3i3eJ4KNLr6iFmq
 qRtHzYdOVsMGGvSME_gD2cXDhYXkJaXjS4eQtapAhO0DZOVklSsmojXs5KIxQ3OJj.nIAsUNf8CF
 XZ2qpzi4mmjKk4NOLmFyAE8lwdL6u5srWjc21lox01HZlcjA_dpjLtmYcQB5PqrzMNg4e7HYSv1.
 X2L95cJOV8qr1Zd3qUwRL6jxrnP5vD3QG8BhvNWLyIs6rvmrfrJAq1_gcRrTGOiBVmq9aZUxgHOa
 4vRLvadRkKBLRc1TzkLJLn3F4oseBdmbFAmXNsMsMqiLUm2MBABu7C2qQ6UtORSz7Y9P_MBUVEL5
 T8SzYk_ZXyIViAXpJwuRppKXtxy1rFhaL8a9kHWiGP_VCO8.A486_j1RO_x2H.Bz2WrrTWkRA0PS
 fbrOLcWYEGd044NHxvyrc0bch13p6soqFYCwF26Ac3j9jNIceRxTu3MXhCD08HtNRJQE.XsshXS.
 pxSVVKV4QZx519wm7KvR1PCo60mfn9vuwj18nqln4tiHCL0CRCdANpliUGfyzMHpsupwvePZXDfT
 cT46tBazMI.0lPpHvuNZKTSZqk8r0jfVjwrJ5SKm.uLD_7tRXtCtRk0ZsNEDRvWVuAmN7RKWWJoB
 vDJyDyWdRgKFGcjoNehUnXSgF.Se4R_BbTxDi6zi6p1QMCabct.UcLLOwMVumypdYkprLR9aQNMm
 87JGGDfIQFwufJt4pbMQ88u0L3WwTy1_4iY6X84kV_kTCyrYpUHsI3P.hm6gY4ETeSy5yj1wyN.d
 skyDgQ1yHbsgxkcp1ySJFEN9ROa1qheB_p3tPfGF_y.4FhG1ttV9IX4kY_cM1YIUp7TedpQM62Rt
 lAdmKdh8L3lTHGeYDuUxUAOxIh0IAJjDvfL_TQe49kCA1C3rEoowJb.BzyGn0gPrGsFcuzBxPe4d
 3flOdvk56i8Nbvp0VeoH7qFqF9LhNmEXrRkfb1gEWHbZHYBMzDKuFY5FKuJwxhANSBZVa_9uzwjJ
 QbN7n9VFw4xpsQEuFmjE6eHCV7knIMoNxK0zZAVHQ3d3ab.XRFaB98TuuXkjM9mu2IjPoaG48w0G
 Iso3cvbAoAUomnSOkhtXS878pef0dxvCUF5hWmKW_hIe3fmgS9SAcMkjsTkbwJoXBfIkTRJJFyjF
 yNqrUPnFq5OwfJZB28D5b0Jl4QLsSzKRbxPibT8fB0ucrlg_HfDjp6Ww6I.Jp7zjr9K15exL1iHE
 PkAWCiMe_VCA4tOzlWyn9fd.yti1D_xy3kIAwjZaoF6s0EK9OyIddjHtOCEt1uw5VtukY1OqwErk
 n7H1KjrewaJBb8WHjWsWW7ZQN6EKijrI2ggxghDEqk8F84g1cr7mESkpDncAxOvxrDo_DNrGMKmx
 q0dFQMizwCztXDiEXE6pFOhB5O0UyDFWAVwPfr6kh0QRx1QsuQu0aoSDF3ZSRkGOgv7DtaLPGz8Q
 VjJ8aHGcp8xxnyGtaX62yZTvnj8ihaRwd2QxMrNhhtioYOECJBcu6aFE37ISV0Uw5Eh8Cg0X3bAQ
 Td66RqUl3F8OYA9z6K7_KHepCKw8B6E8W0Qblm1SMZBACALiemMhw4djosM1GsCo9tNcAfF7d59a
 u56Rc5IexekHrb_gjMXD7APX2ZgQjev_HTXGEsyULo9Fgmxsgo9._kt7swGjWLXa4f9ymkS5UyPa
 VKQnD66HJgYbPrE0PHxCToxwCvynGPf5x9y7QeXMfsBs3FhnV.pRigZlqzE6KLeVnTLkVTmvrPgq
 iGCDrXerSotslE1r0sGdiiradeJxrMOxS89YYRgnDSFR0WDHpy0qc5d9pKXZAHGY2irEAVnfDNYv
 0
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 9 Nov 2022 19:51:52 +0000
Received: by hermes--production-bf1-5878955b5f-7hv65 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7baf9f2baad6a12cf45d1f094629a78b;
          Wed, 09 Nov 2022 19:51:45 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: Mark Millard 
In-Reply-To: <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
Date: Wed, 9 Nov 2022 11:51:31 -0800
Cc: Warner Losh ,
 Alexander Leidinger ,
 tsoome@freebsd.org,
 Li-Wen Hsu ,
 current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <66C46BAC-9411-4655-A3A2-C70756123F81@yahoo.com>
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
To: "Patrick M. Hausen" 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N6wbG6bFjz3sfS
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]
X-ThisMailContainsUnwantedMimeParts: N

On Nov 9, 2022, at 11:02, Patrick M. Hausen  wrote:
>=20
>> Am 09.11.2022 um 16:54 schrieb Warner Losh :
>>>>   There is a fixed list of features we support in the boot loader:
>>>>   [...]=20
>>>>   Any feature not on this list will cause the boot loader to =20
>>>> reject the pool.
>=20
> I admit that I do not grasp the full implications of this thread and =
the proposed
> and debated changes. Does that imply that a simple "zpool upgrade" of =
the
> boot/root pool might lead to an unbootable system in the future - even =
if the
> boot loader is upgraded as it should, too?

Not as you word it ("as it should"). But . . .

Using an actual example, if I understand/remember right:

When com.delphix:head_errlog was added to main [so: 14],
it was not added yet to the loader as of that commit.
As I understand some folks did pool upgrades before a
loader update for the issue was commited. These people
had the loader refuse the upgraded pools until the
loader was update was available and they got it installed.

There is likely a timing gottcha in that openzfs updates
probably have to be committed before the loader can be
updated to track. Landing in the middle without noticing
and upgrading both the loader and the pool(s) could lead
to such problems: not yet the right loader version to
upgrade to.

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


From nobody Wed Nov  9 19:58:46 2022
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 4N6wlg3CX2z4XDsm
	for ; Wed,  9 Nov 2022 19:59:11 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits)
	 client-signature ECDSA (P-256))
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6wlg1HtRz3thr;
	Wed,  9 Nov 2022 19:59:11 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id 3F3E62281B;
	Wed,  9 Nov 2022 20:59:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668023945;
	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=fvYGMqMHq1Kuwt63jMLDNX3jFWl1+hOlRilyDYhxscg=;
	b=MjEqvbJb/prh4jh9SNZokwFMa++SjTXFN3hDutVL2NVcoXFOS9Khc5sxIC/tb3ImTLx9YK
	NThF97BnGuAELIsVf/BJNvR0PRSotBpvRkuwWfe07ey3rVGUFdZapyIffSfo4mEmupzS4C
	6zdk0NpoPVtF+y/Jg/3Sha9Ad1kOKBWSrX4c5lwCQUAhsBvsv2zrCGp2CCOyC+gRrjYvth
	Afihha0IPYQwhZ8uvDnDL4eNm4ddN/JrK8gS7o8RGgMUmFyL6QuvLdm3kmdIl8mQ+63IOc
	2Q8zZwk7dVr1u5OqaHKgsDWgx7szTUgCHrpYS8JE2KMYL6U8QoP5R4fgFGJunA==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id AF3C1368D;
	Wed,  9 Nov 2022 20:58:46 +0100 (CET)
Date: Wed, 09 Nov 2022 20:58:46 +0100
Message-ID: <20221109205846.Horde.Rm5dcHB7p4mSbfFmxReYEDW@webmail.leidinger.net>
From: Alexander Leidinger 
To: "Patrick M. Hausen" 
Cc: Warner Losh , Mark Millard ,
        tsoome@freebsd.org, Li-Wen Hsu ,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
 <5AFBB434-BB3B-4B5A-AB32-11DAFD03A2AD@hausen.com>
In-Reply-To: <5AFBB434-BB3B-4B5A-AB32-11DAFD03A2AD@hausen.com>
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=__KYGARFryJXpMrE7GU9ivm8";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4N6wlg1HtRz3thr
X-Spamd-Bar: ----
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:34240, ipnet:2a00:1828::/32, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=__KYGARFryJXpMrE7GU9ivm8
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022=20=20
20:49:37=20+0100):

> Hi,
>
>> Am 09.11.2022 um 20:45 schrieb Alexander Leidinger=20=20
>>=20:
>> But "zpool set feature@edonr=3Denabled rpool" (or any other feature=20=
=20
>>=20not in the list we talk about) would render it unbootable.
>
> Sorry, just to be sure. So an active change of e.g. checksum or=20=20
>=20compression algorithm
> might render the system unbootable but a zpool upgrade never will?=20=20
>=20At least not intentionally? ;-)

If you mean "zpool upgrade", then no (modulo bugs). OpenZFS uses the=20=20
feature=20flags instead of zpool upgrade.

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=__KYGARFryJXpMrE7GU9ivm8
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsBnUACgkQEg2wmwP4
2IbNzg/+MTrsRIgUBEYPNXVdBJycHI3gvaIuWZ0OIB8VkE3VEGhnXJOzvUDXxd/a
udMMXp5b1ND6sSaS750YpQCCORuOuv9b38BUo4DDNIbOh7iI3YtV4dhjcJ0sgJsX
Pt0k8eKKl1v8fZnhmNZs/yPnG5NycVF9eKZaaxvA2qBKp2RCblt+BaKB9nsr9ld5
EN97u1RJyEG1Olp4p5jpB84GGOxth/o2L+8xgikj4ZWrLQa79mC1XIYAh/hATjac
Tx90NIN6zbEylF7URoy8I8fmONY/NIP7KvyWfR1agX3D2lLRaMv6sx/MSQV81b9j
AIkRYXuAetavO3zDiljlQlej3L7ArkS4Fsf7sVNSbeGq/bpNrBBFvQ1yA6n4mPgh
AN4cG8bv79UXa76gP8dHgVeLfw/vW8MSJo8VoKQkUnV9E+g+ZDRUbTD0czxpmaWg
OkHR412cbwhRx9hFu3CV9dPYg/jPqj2xgc+e3T7ranro64fTxO6fBmviOZ2jfTU6
Rl727cNVJO9CArC/mptpo2Z9Dh+qUO4eAqCvpnLOMCfCPK7P23zujWoVcz4hk19G
qHjCYp3VYXvpVp5rz+UvdhT52HBUucLic4+DqSE/CRKnlogZ5iL5cFezMOxii/vF
Bw3FdpUHtS4VdjXIs4or8dHkRynxwS7eBpiduK1EAd+e8Id2fdw=
=R9YA
-----END PGP SIGNATURE-----

--=__KYGARFryJXpMrE7GU9ivm8--

From nobody Wed Nov  9 20:10:18 2022
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 4N6x0v23wXz4XGFc
	for ; Wed,  9 Nov 2022 20:10:39 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6x0t6dPyz3wdb
	for ; Wed,  9 Nov 2022 20:10:38 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668024636; bh=PaYGGbcNiqQ9RXFOgAYFH38frb3sFJMPd5k8DiUh3ko=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Sv7xTTrXohPLt/Gzu+LvJlFrVgbarlwVBKhye43einSV8eVhdr+GZg0TweTS+8qwrVIwA8f/WSdd+5Vp6dDvaGwbr6w7rl7TRGLCM/YG5t89t63wdWYE4+shdoBWbkQUbdR/oWaV2eu0bDHrIUzPBInE3axDTryXj6DQwzHPa4IeobRfzbMioyCca1NLZQpds9zAl7IAGehgYu/WB2QLzIHtrt5GYe4S6zimeegSNzxMWqTIr/IrE8M71j50CtxiCcKwKsXl8ET4eRR/ryFCGA7BvL3xtrMlMB222a7g7H6pQfexSeFc2fe97MkD2ALxIxzMCuSY8xHkffMi/7ZwQA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668024636; bh=7WGknuh1SM+8nWLscTVW2cjMuHj/U9V5y+XYQxoyayR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gB57vVi14u7jjZBzOSOzx4R6QoxgbYBdWoS1ddEPO9sgWpZntCx4WFutA7bTtEHfHG+Bk9QBrc2Tawy3IrBlZq7ccIXtZf6jn5IPKy+xUnFjGoRmD0IpGRFixGagbeO69pcWoQvxYnkq9MjEe8ukoz/wjJCPbYByW1TSh7GWPCS6sLfYnQ4vmdly4Pbg6zlyWrPrfHkwXvhEvlMUe1JSm/21GH15ImxrsQiEatq9+rDHLRCXifvm2m32V0kfpZ2zTcC1ZVlBAbntcKAaxgPHFI3ObVdzsd7/TO5DKnI5wvdk8zeKDNeGQEvZQ1OhVRtncWgAl7JLAjoRCOch4TOiXw==
X-YMail-OSG: 9B7EO2gVM1nxW.c_57ZY8K6YU0foPaqKednqOxKWR8bxZq.XaPdyimICJsPautc
 ez6MiEmiimUEc6mUsEEWUkqxUntbs7f5RDmQMWPftXxw8zpUpTWPahwCscXPl44iVT0g1S51JHRl
 YWohM.oXjI2SsPYXTR9qiXJgIW7UhfDcH1UhN4a7cyZOFn2r9M_K7kqI92AXhMC1wrI5W4.dHzcM
 Pu9Oun8vBm0ZkAqnDY2Nflx.hW78Tq608KXBFYkVJPQnxBpFKIEKRpqlIfOyNAcqxgR00M0lDt1Z
 KrHX2sDotewsnDPyM04wfz9XIESYiQXh7d9CnhjvCvd9f6nUNP4vX7ZP0ouZqietD4doAqUYS.3S
 pUBfYpTPruWTY0KpydC01qATJAH5I89VvbaxipKlHqN.PM4NKlMvGlMgUeEiP_koK5VelqzB9_Q2
 rE6iYdWg41kik7MPGqIGeGbDsjvt7wElymgkGtrdbv6sgaVDVzH58HvPz_xWwLrwIGw3qjanxRBI
 TDSw2MJowER.DCn3ENrYeG8krr.cc7Ewv9JhVLbpt_GJLsfmuQ2FzVfIYPsWo7K4m1LGuBG7Gg2A
 1Iyvxo1uY89coax2oBfw_dkvrabtqPOrOwccYpLWh8sQWo4lZWyD4LsFo1u4jqZp5lSmDdMrqBst
 XZDn49hYGXjcKnympSMZF2pvrXblnn5Sr6WCTgJdC6K_I.5Wx52Bote77ua1rYxb17uMAay9ZRFL
 5RWkRnJTlHBnErLK99WeGlw3TRgat6.Zl0_U6UO1W_xMuTTkm0kUJgVpJAUyVmg.JTth2OA2NI1V
 tSeM494_r7kVDEhBY5U2lQoLxP391AyOkavKjRZc5M1_pbHCSRtqquv.8.zWfpl7tp_nnfbsIVcs
 ZBJ21_.zgtAz9fUOzBEJ2Bq36wetHNdNNQq2iPhejSTnQgDCJZMCiAkFXwI6etcgOvJSdwXnvbOg
 BqrhtSPkyZSvMmMFkCAdiM77ALGs8_8Ip0bWg3_g2XUbVlGIbRlKDs_Q216m9iizF5E_fSlLJNrS
 1q1Vob0D93eukA2P_QOIx._CA5tkoQsNifnVYqEF7hDpZZirz7.zL7UWy8191CJE9sxSba0YwS2j
 woToKQXFPVo97FKO7K26v38cojQgyk9y2ujyb25TP3zF9_9V770d0MZ3zc6xiQCeESjjlZ2u6B.y
 NGOEIbCB5I3qgXOmp4NhqKYymRXgL4fLL0CCzQ6_q8igywONpfYtYnrXrUZpPu5Wwhv9izkShXSb
 JPUiaRIAoaZvGwo.cPRzyHfiq92t1Rh2ggWof6FnpE9zJYgTztxI1v56Ix6iGP4t5XC2OhRA_f6q
 XTt4K8lRwz06GP2DCFlfRS4oRa9D4o4DnK1hbe7BGIA7oOl2f6seE.eYzSkl7PPWkz7KAlya6Ljj
 LfnKwIgDp4Uj5WmtCfqzAjuPVkolsRwLEAN3B_xyoWkGDfMXIFZP1OZ8vtnp5A5V8A3itHmBeCsn
 1hD0KL6GzVvCFk2zBdQq25LC8.pxvyA8y.p00Dp5yBCFVNrCZh6Bmpdq8LM2hkiCwt_n9TkGg1MU
 FBzpQYoC05X.Ut8jkHQEpWy_v8R3hfnWGWHee1bRpKRvHOlcD3BvJJ49Dk0ez.3rrU03v5bjPc24
 zFKThoWXiEF3oQopSCwmZH1ZIGwwM_UXnSRfdwq8SoRgJuXLwkk24La5XJM4mKRbVksj_wLxXwH_
 TGz3TOQR_ObjoxYULccgt90wckxylT9qpGBv8tJU6j7EhjRQSb_p.CzkW2i86v8v6.pURlpg27E9
 dQnqDudTnfi4_.ClIDjN24aPwIXNht_IenUb2XZCAlcWME.x8vDWW7EKsFcVoIdSMJYu537VXAkR
 z91VXKtlAlHybbTeK6BXtw74nDuvI_6dsTDS9kL6yqTxLlrZGNsZyUKdDrEDDSIvk6llcFlCFpn9
 YGi625QTCoaRj6rKEqnNK9dnk8L6eaaMBFz7eXQDTZB3N27wbjs.1v7tEdIm9NLu9Fr7Bz3b2vFj
 .HdgHig4GH7aGSTwEnmn3q2sqJc8C6iosjiSqxBjfexe.UIkIlYPZ9xy35CwSXZomJRDUTDkjHLF
 mqiZvtGcSLRLs22o0T9VTGUHx1zAy3q_LKW6PN0gLE5tEFhseqgtUpv_H8Akyux.yIybdJIxbs8n
 TgvhL73YfnFKOx1d5iFI_XS2aTcf28XlKYH4.lqX9fYx.03c_9HIQGsiK4KbOscNmq2qFF2oqvdq
 tdSu8Ex.PaWXuB.HA.hDFeMvrttbuL8NDd4VW6iqktYt.VaAkq.2c0sd5QLcXZgXWb6Lt.BPNP8M
 no1Q-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 9 Nov 2022 20:10:36 +0000
Received: by hermes--production-bf1-5878955b5f-kkjj4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 643760c0dbc0dfc9a9bb11c459c06e6f;
          Wed, 09 Nov 2022 20:10:30 +0000 (UTC)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: Mark Millard 
In-Reply-To: <20221109205846.Horde.Rm5dcHB7p4mSbfFmxReYEDW@webmail.leidinger.net>
Date: Wed, 9 Nov 2022 12:10:18 -0800
Cc: "Patrick M. Hausen" ,
 Warner Losh ,
 tsoome@freebsd.org,
 Li-Wen Hsu ,
 current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <671B1F82-A167-45D0-8BCC-4717F433BC11@yahoo.com>
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
 <5AFBB434-BB3B-4B5A-AB32-11DAFD03A2AD@hausen.com>
 <20221109205846.Horde.Rm5dcHB7p4mSbfFmxReYEDW@webmail.leidinger.net>
To: Alexander Leidinger 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N6x0t6dPyz3wdb
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]
X-ThisMailContainsUnwantedMimeParts: N

On Nov 9, 2022, at 11:58, Alexander Leidinger  =
wrote:

> Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022 =
20:49:37 +0100):
>=20
>> Hi,
>>=20
>>> Am 09.11.2022 um 20:45 schrieb Alexander Leidinger =
:
>>> But "zpool set feature@edonr=3Denabled rpool" (or any other feature =
not in the list we talk about) would render it unbootable.
>>=20
>> Sorry, just to be sure. So an active change of e.g. checksum or =
compression algorithm
>> might render the system unbootable but a zpool upgrade never will? At =
least not intentionally? ;-)
>=20
> If you mean "zpool upgrade", then no (modulo bugs). OpenZFS uses the =
feature flags instead of zpool upgrade.

I'm confused by that answer:

QUOTE of "man zpool-upgrade" output:
NAME
     zpool-upgrade =E2=80=93 manage version and feature flags of ZFS =
storage pools
. . .
DESCRIPTION
     zpool upgrade
             Displays pools which do not have all supported features =
enabled
             and pools formatted using a legacy ZFS version number.  =
These
             pools can continue to be used, but some features may not be
             available.  Use zpool upgrade -a to enable all features on =
all
             pools (subject to the -o compatibility property).
. . .
     zpool upgrade [-V version] -a|pool=E2=80=A6
             Enables all supported features on the given pool.
. . .
END QUOTE

zpool upgrade is a way of changing the feature flags, is it  not?

zpool upgrade also does not consider the loader's status, so far
as I know. If FreeBSD's kernel/world supports something that the
loader would reject, teh result is still rejection for booting.
As I understand, some folks ran into this for
com.delphix:head_errlog until an updated loader was available
and then installed.

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


From nobody Wed Nov  9 20:15:23 2022
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 4N6x6Y1VqWz4XH7W
	for ; Wed,  9 Nov 2022 20:15:33 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits)
	 client-signature ECDSA (P-256))
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6x6X253Gz3y5x;
	Wed,  9 Nov 2022 20:15:32 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b="SIAi/IwC";
	spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net;
	dmarc=pass (policy=quarantine) header.from=leidinger.net
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id CF15D22828;
	Wed,  9 Nov 2022 21:15:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668024926;
	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=fk4otahl7LWahxty9enI/mEV0tWAK63fzTvECCtNU1o=;
	b=SIAi/IwCHBDlqk+8+WoQxc/uUIRJ9qftcnaE9AE/M/pbMq3XrH84Wc/+CCRu4cZ03JznuA
	W27L3nYjgcj205QuzrObtzNCIgTE9/e1jB9XmdPhsCjEYkIqQkMt+0lZS/RC2zLgiOR3uZ
	/cU92fvBNgbT36RREkfNOqRcJbO8FpuzlOISgQGzKzzsM0ojk1M4DxwXMYYdJWmCvQD461
	fNDzLeTCRVPNWocIoijxyRDc07ZnFF4NyHZ78IRuO0f6o8KlMlZ8sguz9e8LwucXNHiwu6
	VYLBnXA4yIiz1LJU5yJdXdv3rUl4Hr/1MRrCsOnHmrNL/t9l8zDWw9Sb0ER81w==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 24F6234A3;
	Wed,  9 Nov 2022 21:15:24 +0100 (CET)
Date: Wed, 09 Nov 2022 21:15:23 +0100
Message-ID: <20221109211523.Horde.3dLzlxI4V6n_crjLsz_d08E@webmail.leidinger.net>
From: Alexander Leidinger 
To: "Patrick M. Hausen" 
Cc: imp@bsdimp.com, marklmi@yahoo.com, tsoome@freebsd.org, lwhsu@freebsd.org,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
 <5AFBB434-BB3B-4B5A-AB32-11DAFD03A2AD@hausen.com>
 <20221109205846.Horde.Rm5dcHB7p4mSbfFmxReYEDW@webmail.leidinger.net>
 <6C570897-1C17-43EF-A19C-0F50DA2669B0@hausen.com>
In-Reply-To: <6C570897-1C17-43EF-A19C-0F50DA2669B0@hausen.com>
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_p3gxBz2LtTE2NeI3kjiPm6c";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Spamd-Bar: ------
X-Spamd-Result: default: False [-6.10 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine];
	R_SPF_ALLOW(-0.20)[+mx:c];
	R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE];
	DKIM_TRACE(0.00)[leidinger.net:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[bsdimp.com,yahoo.com,freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_FIVE(0.00)[6];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4N6x6X253Gz3y5x
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_p3gxBz2LtTE2NeI3kjiPm6c
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022=20=20
21:02:52=20+0100):

> Hi,
>
>> Am 09.11.2022 um 20:58 schrieb Alexander Leidinger=20=20
>>=20:
>>
>> Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022=20=20
>>=2020:49:37 +0100):
>>
>>> Hi,
>>>
>>>> Am 09.11.2022 um 20:45 schrieb Alexander Leidinger=20=20
>>>>=20:
>>>> But "zpool set feature@edonr=3Denabled rpool" (or any other feature=20=
=20
>>>>=20not in the list we talk about) would render it unbootable.
>>>
>>> Sorry, just to be sure. So an active change of e.g. checksum or=20=20
>>>=20compression algorithm
>>> might render the system unbootable but a zpool upgrade never will?=20=
=20
>>>=20At least not intentionally? ;-)
>>
>> If you mean "zpool upgrade", then no (modulo bugs). OpenZFS uses=20=20
>>=20the feature flags instead of zpool upgrade.
>
> I know about feature flags and all my pools are recent enough to have the=
m.
>
> Yet, I made it a habit to whenever I see this message:
>
> -----------
> status: Some supported features are not enabled on the pool. The pool can
> 	still be used, but some features are unavailable.
> action: Enable all features using 'zpool upgrade'. Once this is done,
> 	the pool may no longer be accessible by software that does not support
> 	the features. See zpool-features(7) for details.
> -----------
>
> to do a "zpool upgrade" after some time of burn in followed by an=20=20
>=20update of the
> boot loader.
>
> I desire to know if that is in fact dangerous.

Ugh. This changed. It is indeed dangerous now. I just tested it with a=20=
=20
non-root=20pool which didn't had all flags enabled. "zpool upgrade=20=20
"=20will now enable all features.

I remember that it wasn't in the past and I had to enable the feature=20=20
flags=20by hand. I don't know if a pool with bootfs set is behaving=20=20
differently,=20but I consider testing this with a real rpool to be=20=20
dangerous.

Bye,
Alexander.

--=20
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_p3gxBz2LtTE2NeI3kjiPm6c
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsClsACgkQEg2wmwP4
2IacrQ/6AsOXPqZ/69u7Yssr5efUefe1ABdArQ7NL3nOuHq51pSOz6+P4yaL0nLV
8JM3REE/6n/moezidCRw9CRCWja0do3aqYJeibC9II8w11oCmFWfYe3GUmMmjs2f
oF9dgwUY5CrcvzKxw48q40lpLqYLVRcqd9CybEA7bGhYcGCBhC9OUlcRMlOlvNQW
PAeyM01DVebyBWOKHRoEvqkvCAew1f6uP5IH9NZCqQXB6uLQg8aAWuJtwnhCEbHT
z539mq2ho/0TsTAi2paTbryNyOOjnNfXL2pH9+kVTBTm2QoxCM2yG409g0hQwL57
IqD0+dFnI+OocQnpa1wPe+P2tZYDUXvCLRdgD3V9FDMY+f86hljgS5m8yHtKCvZ9
X7EqCEubnI6Xn21NI2zyk8D/y/QksrlE/9YQv5Wd27ZjKFLIFjwEjHMKsZRmHVil
jNNDjZhkYoMXuipNKX1igdt9PqOmUyDqYAEI4f0YSVT8c7q0q5CExPG3k4dTZNgi
vXPg0g2VCLTzZp577mIU7A7AJ2HL4dQfb4FGPd6o0LSVclmV6x5ZBK9OKEKIxhac
+R7u0aT10a7bmh6bSyjBlGPdtezwzlnmr4Jue/PdDsrle+bzwxfm9WQy9p7u/sk8
N/+iw9pnx47ZvrYoQfmIsRf1xQP0dAygUPkYEzbohJbL6JdaeQQ=
=2BuR
-----END PGP SIGNATURE-----

--=_p3gxBz2LtTE2NeI3kjiPm6c--

From nobody Wed Nov  9 20:19:23 2022
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 4N6xC234gBz4XHr5
	for ; Wed,  9 Nov 2022 20:19:26 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4N6xC21zSHz416p;
	Wed,  9 Nov 2022 20:19:26 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 05078A;
 Wed, 9 Nov 2022 21:19:24 +0100
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 \(3696.120.41.1.1\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: "Patrick M. Hausen" 
In-Reply-To:
 <20221109211523.Horde.3dLzlxI4V6n_crjLsz_d08E@webmail.leidinger.net>
Date: Wed, 9 Nov 2022 21:19:23 +0100
Cc: Warner Losh , marklmi@yahoo.com, tsoome@freebsd.org,
 lwhsu@freebsd.org, current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <63316DBD-FFB7-44BA-ADD3-CACBE715518D@hausen.com>
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
 <5AFBB434-BB3B-4B5A-AB32-11DAFD03A2AD@hausen.com>
 <20221109205846.Horde.Rm5dcHB7p4mSbfFmxReYEDW@webmail.leidinger.net>
 <6C570897-1C17-43EF-A19C-0F50DA2669B0@hausen.com>
 <20221109211523.Horde.3dLzlxI4V6n_crjLsz_d08E@webmail.leidinger.net>
To: Alexander Leidinger 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N6xC21zSHz416p
X-Spamd-Bar: ----
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:16188, ipnet:217.29.32.0/20, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> Am 09.11.2022 um 21:15 schrieb Alexander Leidinger =
:
> Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022 =
21:02:52 +0100):
>> Yet, I made it a habit to whenever I see this message:
>>=20
>> -----------
>> status: Some supported features are not enabled on the pool. The pool =
can
>> 	still be used, but some features are unavailable.
>> action: Enable all features using 'zpool upgrade'. Once this is done,
>> 	the pool may no longer be accessible by software that does not =
support
>> 	the features. See zpool-features(7) for details.
>> -----------
>>=20
>> to do a "zpool upgrade" after some time of burn in followed by an =
update of the
>> boot loader.
>>=20
>> I desire to know if that is in fact dangerous.
>=20
> Ugh. This changed. It is indeed dangerous now. I just tested it with a =
non-root pool which didn't had all flags enabled. "zpool upgrade " =
will now enable all features.

I know. But until now I assumed that features *enabled* but not *used* =
were not impeding booting.
And that for all others the boot loader was supposed to keep track.

Kind regards,
Patrick=

From nobody Wed Nov  9 20:19:47 2022
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 4N6xCb3JkQz4XJ7M
	for ; Wed,  9 Nov 2022 20:19:55 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits)
	 client-signature ECDSA (P-256))
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6xCb1nrYz41y9;
	Wed,  9 Nov 2022 20:19:55 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id 0A36F22A77;
	Wed,  9 Nov 2022 21:19:50 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668025190;
	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=CvgNjpOe+3529O4EoJgeUOmlgO5jpOg4QGoZR+xrLi0=;
	b=MBtkrN/8NDezb9afIjXWDDLdT37sLKOCsoGv3WiFuzMlm/KQbfVQYX6iNJI8CgJd7citAP
	j4diXPP5Cc/MPCBytt7kg1S7Zq4slEfFRaKqez0dQvPYHzLOcGBhnhFUzb6Q1E+qL8k7I/
	0JArV9eciSOckJFd3NZMQZZPeh/RHg1frJxE2JEXXrKVLSY2ssr74KV6c7Ct7TEyUR//mf
	HBRErqNFsEG5sKaclmUNzTROHT57FdDe6NlOP7pGDxVuvHLLiWOlyTsSYzEbrORYKx4od9
	DJPswPHWM3R2P21C/EKslWtypL1XM+eCQgw0oE5V4nH4ybjDzXnQKOy95ZQ7+g==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 43B823706;
	Wed,  9 Nov 2022 21:19:47 +0100 (CET)
Date: Wed, 09 Nov 2022 21:19:47 +0100
Message-ID: <20221109211947.Horde.F4xwQw3LUvp0P2aLceiZdwf@webmail.leidinger.net>
From: Alexander Leidinger 
To: Mark Millard 
Cc: "Patrick M. Hausen" , Warner Losh ,
        tsoome@freebsd.org, Li-Wen Hsu ,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
 <5AFBB434-BB3B-4B5A-AB32-11DAFD03A2AD@hausen.com>
 <20221109205846.Horde.Rm5dcHB7p4mSbfFmxReYEDW@webmail.leidinger.net>
 <671B1F82-A167-45D0-8BCC-4717F433BC11@yahoo.com>
In-Reply-To: <671B1F82-A167-45D0-8BCC-4717F433BC11@yahoo.com>
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_KjnKPZ7hG5wsqE2Wc6h-oZ7";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4N6xCb1nrYz41y9
X-Spamd-Bar: ----
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:34240, ipnet:2a00:1828::/32, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_KjnKPZ7hG5wsqE2Wc6h-oZ7
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Mark Millard  (from Wed, 9 Nov 2022=20=20
12:10:18=20-0800):

> On Nov 9, 2022, at 11:58, Alexander Leidinger=20=20
>=20 wrote:
>
>> Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022=20=20
>>=2020:49:37 +0100):
>>
>>> Hi,
>>>
>>>> Am 09.11.2022 um 20:45 schrieb Alexander Leidinger=20=20
>>>>=20:
>>>> But "zpool set feature@edonr=3Denabled rpool" (or any other feature=20=
=20
>>>>=20not in the list we talk about) would render it unbootable.
>>>
>>> Sorry, just to be sure. So an active change of e.g. checksum or=20=20
>>>=20compression algorithm
>>> might render the system unbootable but a zpool upgrade never will?=20=
=20
>>>=20At least not intentionally? ;-)
>>
>> If you mean "zpool upgrade", then no (modulo bugs). OpenZFS uses=20=20
>>=20the feature flags instead of zpool upgrade.
>
> I'm confused by that answer:

See my correction in another mail, the behavior seems to have changed=20=20
and=20yes, doing a zpool upgrade on a boot pool should not be done.

Maybe someone wants to check or add provisions to not do that on a=20=20
pool=20which has the bootfs property set.

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_KjnKPZ7hG5wsqE2Wc6h-oZ7
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsC2IACgkQEg2wmwP4
2IZOwBAAn/LRKpOS3GBLzw9SExbcTL0y2bUwbRZfukJjZNvXWPHoaIrXKUkfrkJA
8Wso+GRYmz/stEJfOIqIU190rp10RHn1vdrpOpEsFRYpTiCo33ZAStxMgb2UDtZ+
0yQ27ANCislTPR7edYADp/jf0VgxZv9E6iVgmQeepy2jUHwVW1XgJxXWO1DOrYTh
j28rL4hwW677AQJTR/ayraPG/TIPFAnD788ZUyCB7eYjG647NnMx4bHsPRAaWCd1
hACANciWmqjMIJQRYaLfUzSmzSZ5FKTyknTztqQc0WfPW5wdSvbK1LxzMKuPo5co
KEwopCbUwTVoLRrr6a22djmZTE9TVy6W1j62rK/t4NRKdOKOF2kx3w7rzMG0+khv
5NkNL7gut4vV4Xm7lJtG6Uzigy4aKguilO97isVSYRPFcAVPSFqwgDC0M1D7ERYn
ZFej++oMqxP4h9Uwpb3RQWnj5xPLue19f7DNEEjg69hAywB9n3BTb4jMtsjnRf+S
++W11pmj6haIVtKprYDAhnB6zK7G/ABg54StdaSblw7ot7kgG+O+A8iDerDQoyLP
+61PUH/4PFEuF2DtG4c36DyifP7QxKofZFbPQK14bDgayxIQH3RolCqb6dm2p8fw
G6jLM8Vn0ETs0j149vdXaeHjItMPDRHPIn2dojyf1KXnNmx2+6Q=
=Dtp9
-----END PGP SIGNATURE-----

--=_KjnKPZ7hG5wsqE2Wc6h-oZ7--

From nobody Wed Nov  9 20:31:49 2022
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 4N6xTV3yQpz4XKVM
	for ; Wed,  9 Nov 2022 20:31:58 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6xTV2ThZz45qJ;
	Wed,  9 Nov 2022 20:31:58 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id B567122A7E;
	Wed,  9 Nov 2022 21:31:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668025912;
	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=dzwxg3ye2i/L5kw2JNNFOqmSx/6GoabbiNYbNC2I+Pw=;
	b=T45QxSCQBiM73eHoUi1FbdCoSOJCuMd9kbpjxb60EhpjRPD0IjPVBXI1X1t/U/2BcRCKQa
	vXMKUG0dwLHjLf6lSJGFABnKwQt2nbURHk89Xm71uoGdu+3gE0dPgfzjMnTy/J1+kX7Evw
	LbVbA39PZIMuVOpnpTKi+CECj2y3MqooEGkKQ+O2qsKHciABqItbsmAJfYDw+FOSoMKiKn
	wJoQuYrFYocof0br0JFKUq/uNAnS02TVn/axwQ5JfgnerML/4h8LktJJLrKEMTDiJF1tta
	Wzl0nka+udD4pM6XodXVC3iPQKQRehCkngXeaUQnWCjlPbyXl1A8R1VTDSxfIQ==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 0285C328B;
	Wed,  9 Nov 2022 21:31:49 +0100 (CET)
Date: Wed, 09 Nov 2022 21:31:49 +0100
Message-ID: <20221109213149.Horde.hR9YpUCQ4NbOZcsX1JxqBgu@webmail.leidinger.net>
From: Alexander Leidinger 
To: "Patrick M. Hausen" 
Cc: Warner Losh , marklmi@yahoo.com, tsoome@freebsd.org,
        lwhsu@freebsd.org, current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
 <5AFBB434-BB3B-4B5A-AB32-11DAFD03A2AD@hausen.com>
 <20221109205846.Horde.Rm5dcHB7p4mSbfFmxReYEDW@webmail.leidinger.net>
 <6C570897-1C17-43EF-A19C-0F50DA2669B0@hausen.com>
 <20221109211523.Horde.3dLzlxI4V6n_crjLsz_d08E@webmail.leidinger.net>
 <63316DBD-FFB7-44BA-ADD3-CACBE715518D@hausen.com>
In-Reply-To: <63316DBD-FFB7-44BA-ADD3-CACBE715518D@hausen.com>
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_JwB9eaLzW-IX9D0XjJsiEyU";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4N6xTV2ThZz45qJ
X-Spamd-Bar: ----
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:34240, ipnet:89.238.64.0/18, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_JwB9eaLzW-IX9D0XjJsiEyU
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022=20=20
21:19:23=20+0100):

> Hi,
>
>> Am 09.11.2022 um 21:15 schrieb Alexander Leidinger=20=20
>>=20:
>> Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022=20=20
>>=2021:02:52 +0100):
>>> Yet, I made it a habit to whenever I see this message:
>>>
>>> -----------
>>> status: Some supported features are not enabled on the pool. The pool c=
an
>>> 	still be used, but some features are unavailable.
>>> action: Enable all features using 'zpool upgrade'. Once this is done,
>>> 	the pool may no longer be accessible by software that does not support
>>> 	the features. See zpool-features(7) for details.
>>> -----------
>>>
>>> to do a "zpool upgrade" after some time of burn in followed by an=20=20
>>>=20update of the
>>> boot loader.
>>>
>>> I desire to know if that is in fact dangerous.
>>
>> Ugh. This changed. It is indeed dangerous now. I just tested it=20=20
>>=20with a non-root pool which didn't had all flags enabled. "zpool=20=20
>>=20upgrade " will now enable all features.
>
> I know. But until now I assumed that features *enabled* but not=20=20
>=20*used* were not impeding booting.
> And that for all others the boot loader was supposed to keep track.

Some features are used directly when enabled. Some features go back to=20=
=20
the=20enabled state when some conditions are met. Some features are not=20=
=20
reversible=20without re-creating the pool (e.g. device_removal). The=20=20
zzpool-features=20man-page gives explanations which features belong into=20=
=20
which=20category.

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_JwB9eaLzW-IX9D0XjJsiEyU
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsDjUACgkQEg2wmwP4
2IYYtQ/+NxvKVOGdotRyEuS7XsqypDgfCXDoR8VGZQ+TGsxV7IbBBP/sl5gtP7/i
nHaPtJwbJYrK9FSHO/VTWr2C/ZZcn+WkYGwFpd3u2hyheVsgQCloeBFkAQe4Iql4
Vlb6LMovGOaaKEjQURapM8sZmczrxj3FFpjNVApQkQUFCcBBJMLE3HrnHoVWEMXH
7ZrVmu2uNw52JZmEQo/niwDIDFhduv1AERU2wb5keQUH3JBhJS3sYctnMnwaZlHi
KvrlCe753dABApHFs85PPunTUgTAH3oHDAaAHU4z9+BkJxCchZpYQk7AZ3wFUb0H
bn9YweYHbDgQz2V0VK+dvc/MFuuAnq/5J1il5LoV6Zr8NAlgqJiNi4qZrbw01F5N
7HJRcXIRvgN46FDkM12wnh3QLErslvYCct1Qs/M7cKsS9K+yenTZtGOuG7kD3G+v
/4gWT2gSihbwE/6sMKG1Rgcws3Udv/H8vcdUtg6c9g38jjzjOQffy+ETeaIc20K1
C2BrvkcQOfgaWO+P5ghVCQ0jakgNXxto2CG/3/cGC2svXkPJWiCJYEsWRazFcu/p
WXlKWluuKHR8dadPbtxuUhjtKVleRpvwqkxwjS860WPUos8hLl3Zzfj4DEQ7d7+M
q1Umsg0Sf9WdCOlxjtnKm0+NZNLPHAnhwypjeyeKp7dXAADI5Y8=
=/1/M
-----END PGP SIGNATURE-----

--=_JwB9eaLzW-IX9D0XjJsiEyU--

From nobody Wed Nov  9 20:40:39 2022
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 4N6xgb0k6Xz4XMF4
	for ; Wed,  9 Nov 2022 20:40:43 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4N6xgZ6lFxz46td;
	Wed,  9 Nov 2022 20:40:42 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 33EA32;
 Wed, 9 Nov 2022 21:40:40 +0100
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 \(3696.120.41.1.1\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: "Patrick M. Hausen" 
In-Reply-To:
 <20221109213149.Horde.hR9YpUCQ4NbOZcsX1JxqBgu@webmail.leidinger.net>
Date: Wed, 9 Nov 2022 21:40:39 +0100
Cc: Warner Losh , Mark Millard ,
 tsoome@freebsd.org, Li-Wen Hsu , current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
 <5AFBB434-BB3B-4B5A-AB32-11DAFD03A2AD@hausen.com>
 <20221109205846.Horde.Rm5dcHB7p4mSbfFmxReYEDW@webmail.leidinger.net>
 <6C570897-1C17-43EF-A19C-0F50DA2669B0@hausen.com>
 <20221109211523.Horde.3dLzlxI4V6n_crjLsz_d08E@webmail.leidinger.net>
 <63316DBD-FFB7-44BA-ADD3-CACBE715518D@hausen.com>
 <20221109213149.Horde.hR9YpUCQ4NbOZcsX1JxqBgu@webmail.leidinger.net>
To: Alexander Leidinger 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N6xgZ6lFxz46td
X-Spamd-Bar: ----
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:16188, ipnet:217.29.32.0/20, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> Am 09.11.2022 um 21:31 schrieb Alexander Leidinger =
:
> Some features are used directly when enabled. Some features go back to =
the enabled state when some conditions are met. Some features are not =
reversible without re-creating the pool (e.g. device_removal). The =
zzpool-features man-page gives explanations which features belong into =
which category.

I already knew most of this, too - but thanks for bringing it to my =
attention again.

If I have to check each individual feature with respect to its =
"bootability" in the future that
is really bad news given that I have about a hundred servers to manage.

So let me shortly describe our use case.

I run servers hosting jails. I upgrade them e.g. like this:

13.1
13.2
13.3
14.1
...

The "habit" that I cited is to upgrade the zpools to match the release. =
We use
freebsd-update and in the rare cases where we don't we track releng/x.y.

We do not run main/head in production.

Can I be confident about upgrading my pools or not? Modulo bugs, but we =
have
test systems, of course.

Kind regards,
Patrick=

From nobody Wed Nov  9 20:51:29 2022
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 4N6xwG3n5Bz4XNpj
	for ; Wed,  9 Nov 2022 20:51:42 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6xwG36P9z49LS
	for ; Wed,  9 Nov 2022 20:51:42 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x62d.google.com with SMTP id k2so50238670ejr.2
        for ; Wed, 09 Nov 2022 12:51:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=jf8bCXm//fBjEo1TEU388saC75X9BKcThB3koN4pWqM=;
        b=QVvx/CHHr0Jaz7rFSd3e86bcsdSuD4Xxr5qpirSLS0w96qcs11xBPcSmOTD+Gh2/8Q
         MDK1gAG5qLoqL28zJS2+p5d+jqbeZKpLL34ADs0Oknbo1Za391GZzBW7irkSeUeDolB1
         8j1dEJ0fAu9Hd+m58S9ZqU00NFuDiGyI/nqJTzCsmxkw9OtJcEqcjEMPSs9awO4qaarp
         BIYYdzGqrU6QurEMdMZazWzeEhhHcPk34cD7wlZ9mfoWaEcH7bDy7Ki9i/lalQdw7uek
         jtJhbNASOqCC7yTKfVQMRrGlDBCUTMvh2ppyBaLigaIbzxvCAHBpcCi7WcMRZNOYL5Zm
         JxJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=jf8bCXm//fBjEo1TEU388saC75X9BKcThB3koN4pWqM=;
        b=wKEFK4Y0AM1V/2JSq4iCshJ6QZPHG+BItZ9qvokbF0HmNTc2nXnAz5Y0eVvT4zAGk/
         u5PC6FUklV6m2ckrzI1hpJLdBdeBCWLQbbrMF7NmQA4YqF7TK2JiDqfEClzqXXxH+MEg
         AZ8O+/JGCUPEBHjht9YMdYbWbJyMj656jaiPZz1TYEo+wP7qsRRN4oWTpyn5gUy43Ugl
         l8slcl9/omJKGGLS5bI0VqFyfi1AIG2Y6cLh+YIOHjl5f7llLRpMb4j6QcAYe4HqWY2w
         bQRmVzEND7dDaEN3eiBhM9ipUUu55zoliRLYSDPPi8J0ybCMLiq42MskEn8mgXMrW5pQ
         fexQ==
X-Gm-Message-State: ACrzQf3S6PA+P9bZrBU61G6IwzB+HCxc17pxmgeet4uUozWDlSWGWQah
	Il74eAj+Nk7LTHJLQV5RjNO27KTR6f6aXNHirtLYEFT4Lj0=
X-Google-Smtp-Source: AMsMyM4eDpa4p5NEsLPeLTvRgmVHzaYnOdaP+glMK62JZQ+kGuw6QBGKcGG44b+390zH7ueYMg5UhTnVznJEI5XR6hM=
X-Received: by 2002:a17:906:338f:b0:78d:a4ab:e8ee with SMTP id
 v15-20020a170906338f00b0078da4abe8eemr1661795eja.140.1668027100771; Wed, 09
 Nov 2022 12:51:40 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
  <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
In-Reply-To: <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
From: Warner Losh 
Date: Wed, 9 Nov 2022 13:51:29 -0700
Message-ID: 
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
To: "Patrick M. Hausen" 
Cc: Alexander Leidinger , Mark Millard , tsoome@freebsd.org, 
	Li-Wen Hsu , current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000d165cb05ed0fd283"
X-Rspamd-Queue-Id: 4N6xwG36P9z49LS
X-Spamd-Bar: ----
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:2a00:1450::/32, country:US]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000d165cb05ed0fd283
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 9, 2022 at 12:02 PM Patrick M. Hausen  wrote:

> Hi all,
>
> > Am 09.11.2022 um 16:54 schrieb Warner Losh :
> > >>    There is a fixed list of features we support in the boot loader:
> > >>    [...]
> > >>    Any feature not on this list will cause the boot loader to
> > >> reject the pool.
>
> I admit that I do not grasp the full implications of this thread and the
> proposed
> and debated changes. Does that imply that a simple "zpool upgrade" of the
> boot/root pool might lead to an unbootable system in the future - even if
> the
> boot loader is upgraded as it should, too?
>

Yes. For safety, boot loader upgrade is mandatory when you do a zpool
upgrade of the root filesystem. It was definitely needed in the OpenZFS
jump, and we've had one or two other flag days since.

It would be nice if we had a failsafe here, but we don't today. With a
failsafe, we could say 'well, go ahead and try, even if it encounters
something it doesn't understand... to at least allow the system to boot.

Warner

--000000000000d165cb05ed0fd283
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Nov 9, 2022 at 12:02 PM Patri=
ck M. Hausen <pmh@hausen.com> w=
rote:
Hi all,


> Am 09.11.2022 um 16:54 schrieb Warner Losh <imp@bsdimp.com>:

> >>=C2=A0 =C2=A0 There is a fixed list of features we support in =
the boot loader:

> >>=C2=A0 =C2=A0 [...] 

> >>=C2=A0 =C2=A0 Any feature not on this list will cause the boot=
 loader to=C2=A0 

> >> reject the pool.



I admit that I do not grasp the full implications of this thread and the pr=
oposed

and debated changes. Does that imply that a simple "zpool upgrade"=
; of the

boot/root pool might lead to an unbootable system in the future - even if t=
he

boot loader is upgraded as it should, too?

<=
div>Yes. For safety, boot loader upgrade is mandatory when you do a zpool u=
pgrade of the root filesystem. It was definitely needed in the OpenZFS jump=
, and we've had one or two other flag days since.

<=
div>It would be nice if we had a failsafe here, but we don't today. Wit=
h a failsafe, we could say 'well, go ahead and try, even if it encounte=
rs something=C2=A0it doesn't understand... to at least allow the system=
 to boot.

Warner


--000000000000d165cb05ed0fd283--

From nobody Wed Nov  9 20:54:08 2022
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 4N6xz63TJ5z4XPXq
	for ; Wed,  9 Nov 2022 20:54:10 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4N6xz61RRsz4Ckd;
	Wed,  9 Nov 2022 20:54:10 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 02D2A9;
 Wed, 9 Nov 2022 21:54:08 +0100
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 \(3696.120.41.1.1\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: "Patrick M. Hausen" 
In-Reply-To:
 
Date: Wed, 9 Nov 2022 21:54:08 +0100
Cc: Alexander Leidinger , Mark Millard
 , tsoome@freebsd.org, Li-Wen Hsu ,
 current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N6xz61RRsz4Ckd
X-Spamd-Bar: ----
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:16188, ipnet:217.29.32.0/20, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

Hi Warner,

> Am 09.11.2022 um 21:51 schrieb Warner Losh :
> Yes. For safety, boot loader upgrade is mandatory when you do a zpool =
upgrade of the root filesystem.
> It was definitely needed in the OpenZFS jump, and we've had one or two =
other flag days since.

That's a given and not a problem. What I fear from my understanding of =
this thread so far is
that there might be a situation when I upgrade the zpool and the boot =
loader and the system
ends up unbootable nonetheless.

Possible or not?

Modulo bugs, try test systems first, etc. Of course.

Thanks,
Patrick=

From nobody Wed Nov  9 20:53:59 2022
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 4N6xz86rg3z4XPQy
	for ; Wed,  9 Nov 2022 20:54:12 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6xz84vfNz4CYT
	for ; Wed,  9 Nov 2022 20:54:12 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x62e.google.com with SMTP id q9so73634ejd.0
        for ; Wed, 09 Nov 2022 12:54:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=jLlHNwUfPkmnxSuv8+MVAk+F+oi1fJdnTkJm/Qi58Ss=;
        b=XFgUw6K2kwiWOuAI7u9V/97VtKuNvdOTkBjB7arL2/dBh1OOSl/HKeWHTJo4tnWwJq
         Gw6WDPPkUbIP7+E6RVN7+em9hlUjnWYX80MDw4EDhVBqsQWgr2GxsKwHoY8o/q+nrIdd
         oc5XObVFGbnbcWRBns/c0Nw0k0FhNhq3QKx8bIr6zv+thrkp8j4Xx1fYPYHYP8qUyiBe
         CxTtzvoHleQh9UiRlc4CTe2UBrMmaMC26wrSa70pG8wJduGOXMAyvb78B/VDc/kNKSG4
         Y9m3nEks+jjlW3izXkTXpMOVrQ8AxxKIoc5h6RzK9DZ+xst6vP/IwAokN5E3dZmi3Yjz
         DzHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=jLlHNwUfPkmnxSuv8+MVAk+F+oi1fJdnTkJm/Qi58Ss=;
        b=v5U3/kV71MAjcNL5mhYhuwBtNWiF5wXLdVrZcatcN28RhccyEgYUFHnFICazEFmbD6
         lrNM0z9/e+tmzqEUA+ynTLL2vs57jSuNhTLdqU2I9UWYhacb6gb3NEHrhf3ga4OU95IW
         SZaDvaWqlyeXSlyw9Wd+vkSgCb9oQ3haf2KK+rmPN8T6iMSbrRnhi8haEatETJ1kHLey
         U1mrbWh/ntQPxKMI4xMJq7bXTqrNuXXUt4//Uau8nTfUz/kFZjxmEcwkunCqTASMT0eY
         KBBImVaVIoZSTL0aIoQHSkY6VVSUW6/hkcYoSRrGFt5cuoX+/xxsxxvvVFDufNo9fi1H
         HjIQ==
X-Gm-Message-State: ACrzQf1ImPkfEc0/ALoaOtOmJqTnhTLl2EeD4w2S0np9rslhPWwStpNz
	35RoBcBf1ZkVvmWRCMz2Z05LsjDwKjPATrob2cLg2g==
X-Google-Smtp-Source: AMsMyM6jjzLwcBk47VcOYeEhqKxKhNmyuOnJhk37KkUVipW0sFuz2hqPIDj5rLuAUjwsmDQvfm8wvwPI9l/u+SPqZJI=
X-Received: by 2002:a17:906:3b17:b0:7ad:b645:9e3e with SMTP id
 g23-20020a1709063b1700b007adb6459e3emr53927931ejf.140.1668027250632; Wed, 09
 Nov 2022 12:54:10 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
  <20221109204736.Horde.u-t3-sSaTA023DA3Tib0oV4@webmail.leidinger.net>
In-Reply-To: <20221109204736.Horde.u-t3-sSaTA023DA3Tib0oV4@webmail.leidinger.net>
From: Warner Losh 
Date: Wed, 9 Nov 2022 13:53:59 -0700
Message-ID: 
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
To: Alexander Leidinger 
Cc: marklmi@yahoo.com, tsoome@freebsd.org, Li-Wen Hsu , 
	current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000c008da05ed0fdb68"
X-Rspamd-Queue-Id: 4N6xz84vfNz4CYT
X-Spamd-Bar: ----
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:2a00:1450::/32, country:US]
X-ThisMailContainsUnwantedMimeParts: N

--000000000000c008da05ed0fdb68
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 9, 2022 at 12:47 PM Alexander Leidinger 
wrote:

> Quoting Warner Losh  (from Wed, 9 Nov 2022 08:54:33
> -0700):
>
> > as well. I'd settle for a good script that could be run as root (better
> > would be not as root) that would take a filesystem that was created
> > by makefs -t zfs and turn on these features after an zpool upgrade.
> > I have the vague outlines of a test suite for the boot loader that I
> > could see about integrating something like that into, but most of my
> > time these days is chasing after 'the last bug' in some kboot stuff I'm
> > working on (which includes issues with our ZFS in the boot loader
> > integration).
>
> How would you test a given image? bhyve/qemu/...?
>

I have a script that creates a number of image files and a number of qemu
scripts that look
like the following:

/home/imp/git/qemu/00-build/qemu-system-aarch64 -nographic -machine
virt,gic-version=3 -m 512M -smp 4 \
        -cpu cortex-a57 \
        -drive
file=/home/imp/stand-test-root/images/arm64-aarch64/linuxboot-arm64-aarch64-zfs.img,if=none,id=drive0,cache=writeback
\
        -device virtio-blk,drive=drive0,bootindex=0 \
        -drive
file=/home/imp/stand-test-root/bios/edk2-arm64-aarch64-code.fd,format=raw,if=pflash
\
        -drive
file=/home/imp/stand-test-root/bios/edk2-arm64-aarch64-vars.fd,format=raw,if=pflash
\
        -monitor telnet::4444,server,nowait \
        -serial stdio $*

There's a list of these files that's generated and looks to see if it gets
to the 'success' echo in the minimal root I have for them.

Warner

--000000000000c008da05ed0fdb68
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Nov 9, 2022 at 12:47 PM Alexa=
nder Leidinger <Alexander@lei=
dinger.net> wrote:
Quoting Warner Losh <imp@bsdimp.com> (from Wed, 9 Nov 2022 08:54:33 -0700):


> as well. I'd settle for a good script that could be run as root (b=
etter

> would be not as root) that would take a filesystem that was created
> by makefs -t zfs and turn on these features after an zpool upgrade.
> I have the vague outlines of a test suite for the boot loader that I
> could see about integrating something like that into, but most of my
> time these days is chasing after 'the last bug' in some kboot =
stuff I'm

> working on (which includes issues with our ZFS in the boot loader

> integration).



How would you test a given image? bhyve/qemu/...?

=

I have a script that creates a number of image files and a numbe=
r of qemu scripts that look
like the following:

/home/imp/git/qemu/00-build/qemu-system-aarch64 -nographic -machine virt=
,gic-version=3D3 -m 512M -smp 4 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -cpu corte=
x-a57 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -drive file=3D/home/imp/stand-test-r=
oot/images/arm64-aarch64/linuxboot-arm64-aarch64-zfs.img,if=3Dnone,id=3Ddri=
ve0,cache=3Dwriteback \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -device virtio-blk,d=
rive=3Ddrive0,bootindex=3D0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -drive file=3D=
/home/imp/stand-test-root/bios/edk2-arm64-aarch64-code.fd,format=3Draw,if=
=3Dpflash \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -drive file=3D/home/imp/stand-te=
st-root/bios/edk2-arm64-aarch64-vars.fd,format=3Draw,if=3Dpflash \
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 -monitor telnet::4444,server,nowait \
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 -serial stdio $*

There=
9;s a list of these files that's generated and looks to see if it gets =
to the 'success' echo in the minimal root I have for them.

Warner


--000000000000c008da05ed0fdb68--

From nobody Wed Nov  9 20:56:43 2022
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 4N6y2K012Nz4XQ4p
	for ; Wed,  9 Nov 2022 20:56:57 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6y2J349Nz4Fcl
	for ; Wed,  9 Nov 2022 20:56:56 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x635.google.com with SMTP id ud5so50239113ejc.4
        for ; Wed, 09 Nov 2022 12:56:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=FYeFu/7iypRQ8uOA3rBhzPjMv222e9QEN6Df5mQC/3w=;
        b=Gnc+rWNvao/V+LZY0wmkDTqCi6JbWzyd6e5eYsz0I8pQbWpX/qKGxhG3t5ci/hSXcs
         GqIs1EZa1QG06R8d7dGDooDcuQ1CtOd9QgD64xdKfq9TLKuoclZl32XwphNfvl1iYyAE
         CTXVY8GFc8LWLiAL++8q3NpGyDP4VeroctNGehAXsoguxAOOmZ0DTtkwsNKD5JYGMhlI
         nNXbZ7wwqvSPmONEO6EPbWQ7M/R8iItts5Um6MKq8acc2c7ikZjvdUFZ2oXyPqTQGlwA
         EILBAypQp6q8VlZ8/P/toPsE8qpmFSUEccofRukB8OEiN3gJWdQ/4RK5GdCNUJ1+t7nu
         0h2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=FYeFu/7iypRQ8uOA3rBhzPjMv222e9QEN6Df5mQC/3w=;
        b=eVtjKLtlH+ZBjviXMG224f0rbMQMopfSFGa5lZ/OJQget/p/uhHcRgtYaPbuPOcMcA
         OgquDz+AxK/vTrS2drcHFfZ7bN+usVOnCtMlrV+YB4QyKPts2m1g1OQyTltfP+tkvfOD
         g763wcSkhXHSlSjHU3bMc3/haALmX95Coz2Q5JQWh4uYVqtSqvDeFozwRSFv2EmwlV80
         8o2sDLWaNK20rE12vp8lYYoEt6dVKGFwZldQC7POXsq5cCppaPUvXusxFiXoks25CExE
         LO7qf/3maUdjdUJ32i1uvqPdKzl70dkuDyqBAEFteREWQjXhP7A62MBe9HR9clWuZz4b
         kvHg==
X-Gm-Message-State: ACrzQf2FJ1oxNwaOGf6wADpiSgHMxwUkpkWj4oLn/0Mdr/WwyW0rCXL4
	yDjKzjngLnPa2GgtCUcrmk+o+k+xGWMKKe7142tLfA==
X-Google-Smtp-Source: AMsMyM7DnCCizAeFcJOh6U6kK6TTADA0h56aQxAJUA4PNo2fEkImB5Q9RqeHWk1FMxiEpqvHwCQqHKMlKkB7rKVUxCk=
X-Received: by 2002:a17:906:9d14:b0:799:9ace:e868 with SMTP id
 fn20-20020a1709069d1400b007999acee868mr1676803ejc.451.1668027414359; Wed, 09
 Nov 2022 12:56:54 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com> 
 
In-Reply-To: 
From: Warner Losh 
Date: Wed, 9 Nov 2022 13:56:43 -0700
Message-ID: 
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
To: "Patrick M. Hausen" 
Cc: Alexander Leidinger , Mark Millard , tsoome@freebsd.org, 
	Li-Wen Hsu , current@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000008250c205ed0fe5f7"
X-Rspamd-Queue-Id: 4N6y2J349Nz4Fcl
X-Spamd-Bar: ----
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:2a00:1450::/32, country:US]
X-ThisMailContainsUnwantedMimeParts: N

--0000000000008250c205ed0fe5f7
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 9, 2022 at 1:54 PM Patrick M. Hausen  wrote:

> Hi Warner,
>
> > Am 09.11.2022 um 21:51 schrieb Warner Losh :
> > Yes. For safety, boot loader upgrade is mandatory when you do a zpool
> upgrade of the root filesystem.
> > It was definitely needed in the OpenZFS jump, and we've had one or two
> other flag days since.
>
> That's a given and not a problem. What I fear from my understanding of
> this thread so far is
> that there might be a situation when I upgrade the zpool and the boot
> loader and the system
> ends up unbootable nonetheless.
>
> Possible or not?
>

If all you do is upgrade, then no, modulo bugs that we've thankfully not
had yet. It's when you enable something on the zpool that you can run into
trouble, but that's true independent of upgrade :)

Warner


> Modulo bugs, try test systems first, etc. Of course.
>
> Thanks,
> Patrick

--0000000000008250c205ed0fe5f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Nov 9, 2022 at 1:54 PM Patric=
k M. Hausen <pmh@hausen.com> wr=
ote:
Hi Warner,<=
br>


> Am 09.11.2022 um 21:51 schrieb Warner Losh <imp@bsdimp.com>:

> Yes. For safety, boot loader upgrade is mandatory when you do a zpool =
upgrade of the root filesystem.

> It was definitely needed in the OpenZFS jump, and we've had one or=
 two other flag days since.



That's a given and not a problem. What I fear from my understanding of =
this thread so far is

that there might be a situation when I upgrade the zpool and the boot loade=
r and the system

ends up unbootable nonetheless.



Possible or not?

If all you do is upgra=
de, then no, modulo bugs that we've thankfully not had yet. It's wh=
en you enable something on the zpool that you can run into trouble, but tha=
t's true independent of upgrade :)

Warner
=C2=A0

Modulo bugs, try test systems first, etc. Of course.



Thanks,

Patrick


--0000000000008250c205ed0fe5f7--

From nobody Wed Nov  9 20:58:36 2022
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 4N6y4G6Xtlz4XQH9
	for ; Wed,  9 Nov 2022 20:58:38 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4N6y4G5TLdz4Gds;
	Wed,  9 Nov 2022 20:58:38 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 3A2179;
 Wed, 9 Nov 2022 21:58:37 +0100
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 \(3696.120.41.1.1\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: "Patrick M. Hausen" 
In-Reply-To:
 
Date: Wed, 9 Nov 2022 21:58:36 +0100
Cc: Alexander Leidinger , Mark Millard
 , tsoome@freebsd.org, Li-Wen Hsu ,
 current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <313D3637-6913-401B-A711-679365E92935@hausen.com>
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 
 
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N6y4G5TLdz4Gds
X-Spamd-Bar: ----
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:16188, ipnet:217.29.32.0/20, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> Am 09.11.2022 um 21:56 schrieb Warner Losh 
>=20
> If all you do is upgrade, then no, modulo bugs that we've thankfully =
not had yet. It's when you enable something on the zpool that you can =
run into trouble, but that's true independent of upgrade :)

Thanks. That lets me sleep way better.

Kind regards,
Patrick=

From nobody Wed Nov  9 21:05:40 2022
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 4N6yDY6Qrxz4d8N0
	for ; Wed,  9 Nov 2022 21:05:49 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits)
	 client-signature ECDSA (P-256))
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6yDY4pRpz4J7h;
	Wed,  9 Nov 2022 21:05:49 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id EF0E722870;
	Wed,  9 Nov 2022 22:05:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668027944;
	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=xvkM2ngQvuiDVMcz7lvanwZv+awV9UsdTv2+8NNAly8=;
	b=hvf3zGQhIMtCvRUeVeQSC1IHrfRmXr7QuRVJEkN0H32Dmu+lTgqRFriI4eY5JLgOoi+6tA
	bdEi5fWu0x1TuEv4ybH4Ppxnd+I3mm8SegNUcyYPIHo2LdZ5rw1YpbgFQhJnQRufpXMehJ
	9z2VGs45k8iPypmJuV4A3t+Kkr4berxfGXfQreE757L/War+mEYsl2qsDQF865FZMwBkLm
	IXW6Gi3KhHnTvXr9h1MmiWMUxohra3MgcHzRcKI3EVXzoBXWTbL+uf3OrXNsvn6YCA1Gkm
	6wQ/9S6CJNJ8dJ9p2ukPq45ZLBwuWxs/KwvnOmJ+crzPiApdDOqfL5XWIg5rpA==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id F20B7338B;
	Wed,  9 Nov 2022 22:05:40 +0100 (CET)
Date: Wed, 09 Nov 2022 22:05:40 +0100
Message-ID: <20221109220540.Horde.6GRfN8bbUC4AsLcvjhWbUgm@webmail.leidinger.net>
From: Alexander Leidinger 
To: Warner Losh 
Cc: "Patrick M. Hausen" , Mark Millard ,
        tsoome@freebsd.org, Li-Wen Hsu ,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 
 
 
In-Reply-To: 
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_TIVGIgehbgMshMfaaDjE6vn";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4N6yDY4pRpz4J7h
X-Spamd-Bar: ----
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:34240, ipnet:89.238.64.0/18, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_TIVGIgehbgMshMfaaDjE6vn
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Warner Losh  (from Wed, 9 Nov 2022 13:56:43 -0700):

> On Wed, Nov 9, 2022 at 1:54 PM Patrick M. Hausen  wrote:
>
>> Hi Warner,
>>
>> > Am 09.11.2022 um 21:51 schrieb Warner Losh :
>> > Yes. For safety, boot loader upgrade is mandatory when you do a zpool
>> upgrade of the root filesystem.
>> > It was definitely needed in the OpenZFS jump, and we've had one or two
>> other flag days since.
>>
>> That's a given and not a problem. What I fear from my understanding of
>> this thread so far is
>> that there might be a situation when I upgrade the zpool and the boot
>> loader and the system
>> ends up unbootable nonetheless.
>>
>> Possible or not?
>>
>
> If all you do is upgrade, then no, modulo bugs that we've thankfully not
> had yet. It's when you enable something on the zpool that you can run int=
o
> trouble, but that's true independent of upgrade :)

Attention, "upgrade" is overloaded here. "OS upgrade" will not render=20=20
the=20pool unbootable (modulo bugs), but "zpool upgrade rpool" will=20=20
(except=20we have provisions that zpool upgrade doesn't enable all=20=20
features=20in case the bootfs property is set).

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_TIVGIgehbgMshMfaaDjE6vn
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsFiMACgkQEg2wmwP4
2IYCHBAAhA3f6ucB1WPdPS5GicWgsnXMusrm3QlZvLTKIVie/z8X0XNo94W2xibM
42VUsMyVf3xQn6zbrGt4+6xCLvKY5a6OB9+EsPOC6bMjn02LheMx3Ee+zHnTa7ii
W/Zg8aWwym+HOWisOhIxP667nA5yrLe1bcdjZ9lUK6G8PKWh6C9fBO5r9AcZIeVH
AERySjq4PliSH9/Uh6eLUEZgXxjfU6Nfd99PoNtYOo2zq5xfLHadcnJt9xuJtTiS
0nM1bhGpZ7VeHLSnia0t5n9NYiSAzWqUgynjUtPEOJA/WS+qZkBXgGOfUAJWgkfA
BAUNJ07vwSkBYG8C3bakYHfcpAFMUUeKdpKUbTh8JnbiDXLC+c10N1KXqxC1wVYO
DYK/JdabJj45ynM/xU9LpFq4EJo9YE1c2Wt4e6/oDQlhIFBUpLvjYTnSJ2ShU+oc
lFP9OWa4WlcJVi970JxJDNXAB3d0C6cCs95BZ0lbD5hHHqJHBsXaPY+9CCBNrVx4
FYWG2HFzadEzyFCBwTRqgGAxy7cO87zmC/vLV7HWBqdmVOiih3jFLSAsPVQQsfsz
VXUyIT1PICp/GsK7PpgiqYITfPyL+3s5JgELxFRbQ6R8jkZfBctMzYtpWMUvMLrS
xEzg7qFO2/g+UuOfE4d+W90Cr86Gjub5djkBMZHYh3/sf5tdNh0=
=m13E
-----END PGP SIGNATURE-----

--=_TIVGIgehbgMshMfaaDjE6vn--

From nobody Wed Nov  9 21:11:29 2022
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 4N6yM7636Gz4d94T
	for ; Wed,  9 Nov 2022 21:11:31 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4N6yM73FrSz4Kct;
	Wed,  9 Nov 2022 21:11:31 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 0CDED7;
 Wed, 9 Nov 2022 22:11:29 +0100
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 \(3696.120.41.1.1\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: "Patrick M. Hausen" 
In-Reply-To:
 <20221109220540.Horde.6GRfN8bbUC4AsLcvjhWbUgm@webmail.leidinger.net>
Date: Wed, 9 Nov 2022 22:11:29 +0100
Cc: Warner Losh , Mark Millard ,
 tsoome@freebsd.org, Li-Wen Hsu , current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <65689194-1F56-4429-9A52-794A8354D995@hausen.com>
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 
 
 
 <20221109220540.Horde.6GRfN8bbUC4AsLcvjhWbUgm@webmail.leidinger.net>
To: Alexander Leidinger 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N6yM73FrSz4Kct
X-Spamd-Bar: ----
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:16188, ipnet:217.29.32.0/20, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> Am 09.11.2022 um 22:05 schrieb Alexander Leidinger =
:
> Attention, "upgrade" is overloaded here. "OS upgrade" will not render =
the pool unbootable (modulo bugs), but "zpool upgrade rpool" will =
(except we have provisions that zpool upgrade doesn't enable all =
features in case the bootfs property is set).

And we are back at the start. The "problem" is that I really like =
consistency.
So when "zpool status" throws that ominous message at me - any you have
to admit that it is phrased like a warning - I want simply to get rid of =
that.
After a reasonable after-update grace period.

But during our discussion I have come to wonder:

- I upgrade from 13.0 to 13.1, I do a "zpool upgrade" afterwards, I also =
upgrade the boot loader

- I install 13.1 with ZFS

What is the difference? Shouldn't these two imaginary systems be =
absolutely the same in terms
of ZFS features, boot loader, and all that?

Kind regards,
Patrick=

From nobody Wed Nov  9 21:12:19 2022
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 4N6yND6V2Nz4d8lg
	for ; Wed,  9 Nov 2022 21:12:28 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6yND4zHxz4Lwp;
	Wed,  9 Nov 2022 21:12:28 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id BD6A72287E;
	Wed,  9 Nov 2022 22:12:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668028342;
	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=GEN+RXT2yNNb3jycqMObwhBkGYQyluUryflLBVKN14I=;
	b=ON+63j0unia0h1qcaBrPIpMelHE4LX8v4ThebN0dQXOd4k2rGHDekbopAfyULlRAspCsSu
	KYdybs6iQGy24dOhGKWcVuhBfHyU12R/pxJQTRJw+EK95xSCa8EVK2MZ8lxrnZwvZKTkUp
	OIldOumvNW5Eqic0W2AqX8mcG3pqy5dutV63mYj3iJO15coLVbNYw6ZX/zxP8QVYm5tVnm
	FDCO3lhtPZ6xCZ6s9MdzCn7LH9fx4owY5IIxHHo1ZhyN5JH960T5JbkLJtYHCKZrAezA/P
	UVdiakb7qToGFnuMnA72u6VAqn2bMstBazSRgdxMflfXFh6AnT5in590DbC+Rw==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 1AF12368E;
	Wed,  9 Nov 2022 22:12:20 +0100 (CET)
Date: Wed, 09 Nov 2022 22:12:19 +0100
Message-ID: <20221109221219.Horde.rvKH8QoLi2iPD3JbQNgK1Yz@webmail.leidinger.net>
From: Alexander Leidinger 
To: Warner Losh 
Cc: marklmi@yahoo.com, tsoome@freebsd.org, Li-Wen Hsu ,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <20221109204736.Horde.u-t3-sSaTA023DA3Tib0oV4@webmail.leidinger.net>
 
In-Reply-To: 
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_Y0Eh2IHRBdvh11-EeVaXxnB";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4N6yND4zHxz4Lwp
X-Spamd-Bar: ----
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:34240, ipnet:2a00:1828::/32, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_Y0Eh2IHRBdvh11-EeVaXxnB
Content-Type: multipart/alternative; boundary="=_fsmWNBJQBYx6MobCfF_DBVM"

This message is in MIME format.

--=_fsmWNBJQBYx6MobCfF_DBVM
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Description: Textnachricht
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

  Quoting Warner Losh  (from Wed, 9 Nov 2022 13:53:59 -0700=
):

> =C2=A0
>
>        On Wed, Nov 9, 2022 at 12:47 PM Alexander Leidinger=20=20
>=20 wrote:
>
>> Quoting Warner Losh  (from Wed, 9 Nov 2022 08:54:33 -070=
0):
>>
>>> as well. I'd settle for a good script that could be run as root (better
>>> would be not as root) that would take a filesystem that was created
>>> by makefs -t zfs and turn on these features after an zpool upgrade.
>>> I have the vague outlines of a test suite for the boot loader that I
>>> could see about integrating something like that into, but most of my
>>> time these days is chasing after 'the last bug' in some kboot stuff I'm
>>> working on (which includes issues with our ZFS in the boot loader
>>> integration).
>>
>> How would you test a given image? bhyve/qemu/...?
>
>     =C2=A0
>     I have a script that creates a number of image files and a=20=20
>=20number of qemu scripts that look
>     like the following:
>     =C2=A0
> /home/imp/git/qemu/00-build/qemu-system-aarch64 -nographic -machine=20=20
>=20virt,gic-version=3D3 -m 512M -smp 4 \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -cpu cortex-a57 \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -drive=20=20
>=20file=3D/home/imp/stand-test-root/images/arm64-aarch64/linuxboot-arm64-a=
arch64-zfs.img,if=3Dnone,id=3Ddrive0,cache=3Dwriteback=20=20
>=20\
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -device virtio-blk,drive=3Ddrive0,bootindex=
=3D0 \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -drive=20=20
>=20file=3D/home/imp/stand-test-root/bios/edk2-arm64-aarch64-code.fd,format=
=3Draw,if=3Dpflash=20=20
>=20\
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -drive=20=20
>=20file=3D/home/imp/stand-test-root/bios/edk2-arm64-aarch64-vars.fd,format=
=3Draw,if=3Dpflash=20=20
>=20\
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -monitor telnet::4444,server,nowait \
>     =C2=A0 =C2=A0 =C2=A0 =C2=A0 -serial stdio $*
>     =C2=A0
>     There's a list of these files that's generated and looks to see=20=20
>=20if it gets to the 'success' echo in the minimal root I have for them.
>     =C2=A0

So a little script which makes a copy of a source image, enables=20=20
features=20on the copies and spits out a list of image files would suit=20=
=20
your=20needs?
e.g.:
for feature A B C; do
=C2=A0=C2=A0 # ignoring inter-feature dependencies for a moment
=C2=A0 cp $source_image zfs_feature_$feature.img
=C2=A0 pool_name =3D import_pool zfs_feature_$feature.img
=C2=A0 enable_feature $pool_name $feature
=C2=A0 export_pool $pool_name
=C2=A0 echo zfs_feature_$feature.img
done

Bye,
Alexander.
--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_fsmWNBJQBYx6MobCfF_DBVM
Content-Type: text/html; charset=utf-8
Content-Description: HTML-Nachricht
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable









Quoting Warner Losh <imp@bsdimp.com=
> (from Wed, 9 Nov 2022 13:53:59 -0700):






 






On Wed, Nov 9, 2022 at 12:47 PM Alexa=
nder Leidinger <Alexander@lei=
dinger.net> wrote:




Quoting Warner Losh <imp@bsdimp.com> (from Wed, 9 Nov 2022 08:54:33 -0700):



> as well. I'd settle for a good script that could be run as root (bette=
r

> would be not as root) that would take a filesystem that was created
> by makefs -t zfs and turn on these features after an zpool upgrade.
> I have the vague outlines of a test suite for the boot loader that I
> could see about integrating something like that into, but most of my
> time these days is chasing after 'the last bug' in some kboot stuff I'=
m

> working on (which includes issues with our ZFS in the boot loader

> integration).



How would you test a given image? bhyve/qemu/...?




 


I have a script that creates a number of image files and a number of q=
emu scripts that look


like the following:


 

/home/imp/git/qemu/00-build/qemu-system-aarch64 -nographic -machine virt,gi=
c-version=3D3 -m 512M -smp 4 \

        -cpu cortex-a57 \

        -drive file=3D/home/imp/stand-test-root/images/=
arm64-aarch64/linuxboot-arm64-aarch64-zfs.img,if=3Dnone,id=3Ddrive0,cache=
=3Dwriteback \

        -device virtio-blk,drive=3Ddrive0,bootindex=3D0=
 \

        -drive file=3D/home/imp/stand-test-root/bios/ed=
k2-arm64-aarch64-code.fd,format=3Draw,if=3Dpflash \

        -drive file=3D/home/imp/stand-test-root/bios/ed=
k2-arm64-aarch64-vars.fd,format=3Draw,if=3Dpflash \

        -monitor telnet::4444,server,nowait \


        -serial stdio $*


 


There's a list of these files that's generated and looks to see if it =
gets to the 'success' echo in the minimal root I have for them.


 










So a little script which makes a copy of a source image, enables features o=
n the copies and spits out a list of image files would suit your needs?

e.g.:

for feature A B C; do

   # ignoring inter-feature dependencies for a moment

  cp $source_image zfs_feature_$feature.img

  pool_name =3D import_pool zfs_feature_$feature.img

  enable_feature $pool_name $feature

  export_pool $pool_name

  echo zfs_feature_$feature.img

done



Bye,

Alexander.




--=_fsmWNBJQBYx6MobCfF_DBVM--

--=_Y0Eh2IHRBdvh11-EeVaXxnB
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsF7MACgkQEg2wmwP4
2IaNnQ/8C4yTwyNPQXlTlEW1WlC+QVkbtImBmgyGqVX7ZUsPqMiFVAgm2+/74IFi
wd+iyQtlLMZE5cnSbqmx8mITT3xbgIf9tazyyEccATYmhgIhbfKFo+xWz2WxFxh1
f7Ao1+fKb9N2sjzlxjeutiFntu1Ee3bHeMRllWUeRdMY6Mkj7IJJj2eStxp6vlJF
whOwb2ZQvguVyuEqs98MMD/V66wDdL5qR8HihO48nqaDAFjGgH1QobVPLJtcHgC2
IIngQSsaidBo2RdbH5w0nZJF2MOH8koOtRJsos2ktfbrL7LJ48FLUBxV6nbCD9Q3
fb05AjZRWOY6W7Djy5zy7Qb1UBvHX0O9H8CJjNK9e2jcg5QhdWgxnsRFxbCw5blY
87QrPkPNGMCpQ1r/hpOhwR9uAKNNhZbRHutOLcLN9xi4KkoEXw7hMxmN5MLvlYEE
RogaHXV1YcU7NPKf742/+uWoji4HCatJ/QfkpYEfVQhZub7oKOjyGc5xFfctsmhb
hRyux+b/IxhIOJJ8YiZ0UrZgmI7ohuDQPS71XhCRKIyI0vL6W8GnhdlzK7OhrFof

JUHuZ3ov/xRXtdqskKTxvxlF3pM+MJAj1ys7e6aL9g4GaPJEKAcHXADLRRLbNVuq
2T7lCdqvYgjAsGjvJM2yCY8ud7zTfOpFy+Z3oPto36mxaydn3KY=
=uujD
-----END PGP SIGNATURE-----

--=_Y0Eh2IHRBdvh11-EeVaXxnB--

From nobody Wed Nov  9 21:18:41 2022
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 4N6yWY09tSz4d9vs
	for ; Wed,  9 Nov 2022 21:18:49 +0000 (UTC)
	(envelope-from brooks@spindle.one-eyed-alien.net)
Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229])
	(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 4N6yWX5Gvtz4N97;
	Wed,  9 Nov 2022 21:18:48 +0000 (UTC)
	(envelope-from brooks@spindle.one-eyed-alien.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001)
	id 0C83D3C0199; Wed,  9 Nov 2022 21:18:42 +0000 (UTC)
Date: Wed, 9 Nov 2022 21:18:41 +0000
From: Brooks Davis 
To: Alexander Leidinger 
Cc: Mark Millard , "Patrick M. Hausen" ,
	Warner Losh , tsoome@freebsd.org,
	Li-Wen Hsu , current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
Message-ID: <20221109211841.GC95557@spindle.one-eyed-alien.net>
References: 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
 <5AFBB434-BB3B-4B5A-AB32-11DAFD03A2AD@hausen.com>
 <20221109205846.Horde.Rm5dcHB7p4mSbfFmxReYEDW@webmail.leidinger.net>
 <671B1F82-A167-45D0-8BCC-4717F433BC11@yahoo.com>
 <20221109211947.Horde.F4xwQw3LUvp0P2aLceiZdwf@webmail.leidinger.net>
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-sha1;
	protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL"
Content-Disposition: inline
In-Reply-To: <20221109211947.Horde.F4xwQw3LUvp0P2aLceiZdwf@webmail.leidinger.net>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Rspamd-Queue-Id: 4N6yWX5Gvtz4N97
X-Spamd-Bar: ----
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:36236, ipnet:199.48.128.0/22, country:US]
X-ThisMailContainsUnwantedMimeParts: N


--vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 09, 2022 at 09:19:47PM +0100, Alexander Leidinger wrote:
> Quoting Mark Millard  (from Wed, 9 Nov 2022 =20
> 12:10:18 -0800):
>=20
> > On Nov 9, 2022, at 11:58, Alexander Leidinger =20
> >  wrote:
> >
> >> Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022 =20
> >> 20:49:37 +0100):
> >>
> >>> Hi,
> >>>
> >>>> Am 09.11.2022 um 20:45 schrieb Alexander Leidinger =20
> >>>> :
> >>>> But "zpool set feature@edonr=3Denabled rpool" (or any other feature =
=20
> >>>> not in the list we talk about) would render it unbootable.
> >>>
> >>> Sorry, just to be sure. So an active change of e.g. checksum or =20
> >>> compression algorithm
> >>> might render the system unbootable but a zpool upgrade never will? =
=20
> >>> At least not intentionally? ;-)
> >>
> >> If you mean "zpool upgrade", then no (modulo bugs). OpenZFS uses =20
> >> the feature flags instead of zpool upgrade.
> >
> > I'm confused by that answer:
>=20
> See my correction in another mail, the behavior seems to have changed =20
> and yes, doing a zpool upgrade on a boot pool should not be done.
>=20
> Maybe someone wants to check or add provisions to not do that on a =20
> pool which has the bootfs property set.

Literally the entire point of the script added in the commit this thread
is about upgrade the boot pool on first boot so that seems like it would
be counterproductive.

-- Brooks

--vtzGhvizbBRQ85DL
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJjbBkxAAoJEKzQXbSebgfAf8kIAIH1SijEkzgfq7D2pQVM6tdO
hhLlsbuQg6gR9zY75usNyCaGKbgH2ofUPJpmkYTHcmvhDUL2BYQiu9TpIc5uV6Ag
4VnfyX2esEMdu+PRMfAxyU95djYVRGwfZ8K50JfQhYHfEq+HQA5QdYu2l9R4n/wF
zytzfKNt668/nM1RfwrSPotuia6R1G9koxO43AjrN62joRrpECqemhuVzU03v0HP
7RO/89NFRwZTILuwRVzaRyg3IkDu+Wm0kWq8iXJex+OD5ceL2gkAkCpUZcjMrl/X
CfVSxShXZm4gwo0MhkFHZwVRdDhzbdBejyBIQuchAyBBCLF/PYVVPxhLqbz1TBY=
=mqqK
-----END PGP SIGNATURE-----

--vtzGhvizbBRQ85DL--

From nobody Wed Nov  9 21:26:00 2022
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 4N6yh04Nk2z4dCKJ
	for ; Wed,  9 Nov 2022 21:26:08 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits)
	 client-signature ECDSA (P-256))
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6yh02vnHz4Pgt;
	Wed,  9 Nov 2022 21:26:08 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id 3FCAE22B9A;
	Wed,  9 Nov 2022 22:26:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668029163;
	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=+wJAYanejM12yJIHxg3gGBMEOG04wH/eqmNTJ13Ybew=;
	b=VnYWINxFXqnNx45+dpSEZ0iOrC3QupowFCm0t3RYCePQhs9E5wVHRorFXam17u7Zxqjx4u
	9hzI1zljhopXZlFCetUGWxX9yXKTrisi9PQap+76j+4ZJ7sO421mLOxmXInuLFcfaPeYEL
	dmeo0O1eZRTrUDhE8U1bYHRu/502P2yKo7/nJe+Qa2fm/ajNHsQWi6Pd5xTqRE33kJmZ+f
	C18/SD9DATMC1P/KzIqSWz2IvTCpwpfO1m3j/BebhvHwHPFQQM6QS3is2hdTHZaRf3voZb
	5YojJHOGOybYJ7wKsHN14ug/V7E2B+k53qiPMofZhlGj/f4lu5IuzU9QmVBpsQ==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 84D0D338C;
	Wed,  9 Nov 2022 22:26:00 +0100 (CET)
Date: Wed, 09 Nov 2022 22:26:00 +0100
Message-ID: <20221109222600.Horde.yo1Ry8tPu9udiPqUgtdDHNG@webmail.leidinger.net>
From: Alexander Leidinger 
To: "Patrick M. Hausen" 
Cc: Warner Losh , Mark Millard ,
        tsoome@freebsd.org, Li-Wen Hsu ,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 
 
 
 <20221109220540.Horde.6GRfN8bbUC4AsLcvjhWbUgm@webmail.leidinger.net>
 <65689194-1F56-4429-9A52-794A8354D995@hausen.com>
In-Reply-To: <65689194-1F56-4429-9A52-794A8354D995@hausen.com>
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_5SWu4JVC2iqZQXg6UVJP3xs";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4N6yh02vnHz4Pgt
X-Spamd-Bar: ----
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:34240, ipnet:2a00:1828::/32, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_5SWu4JVC2iqZQXg6UVJP3xs
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022=20=20
22:11:29=20+0100):

> Hi,
>
>> Am 09.11.2022 um 22:05 schrieb Alexander Leidinger=20=20
>>=20:
>> Attention, "upgrade" is overloaded here. "OS upgrade" will not=20=20
>>=20render the pool unbootable (modulo bugs), but "zpool upgrade rpool"=20=
=20
>>=20will (except we have provisions that zpool upgrade doesn't enable=20=
=20
>>=20all features in case the bootfs property is set).
>
> And we are back at the start. The "problem" is that I really like=20=20
>=20consistency.
> So when "zpool status" throws that ominous message at me - any you have
> to admit that it is phrased like a warning - I want simply to get=20=20
>=20rid of that.
> After a reasonable after-update grace period.
>
> But during our discussion I have come to wonder:
>
> - I upgrade from 13.0 to 13.1, I do a "zpool upgrade" afterwards, I=20=20
>=20also upgrade the boot loader
>
> - I install 13.1 with ZFS
>
> What is the difference? Shouldn't these two imaginary systems be=20=20
>=20absolutely the same in terms
> of ZFS features, boot loader, and all that?

On quick look I haven't found a place where a compatibility setting is=20=
=20
used=20for the rpool during the creation, so I can't point out what the=20=
=20
exact=20difference is.
Given that empty_bpobj is not in the list of the boot code, it can't=20=20
be=20the same, some limit of enabled features has to be in place during=20=
=20
initial=20install, and your example has to be different.

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_5SWu4JVC2iqZQXg6UVJP3xs
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsGucACgkQEg2wmwP4
2IZ0bQ/+LwtM+ImQ66cuthOD1BO2oCnaIhl2LvtxxIl7HXW3VdHECEiYHI+bpWap
/1B94/ShoOgCDhpD12jmIIOCMYi38Q8ILKmzQWeBKFp7KxjYEQOUXQKNH3dYN0SE
zXZHCZarVeKkpzWzlwAWVIMjGBH9GrB7QgOFJ/CmRralun+U/8zEIMwTZ1Po8c/8
MCfTjnL4BACWr3K0aU18oRiPWNLO/cSJ7t1I5mZ0Kve9UUeseaL5mGbtYRGCqxZS
frCn7s10iywy+3ifZKmuHtqKUo9dJ5aI5e/u1pdzEeOiMPx+5vQ8wjkDkpEjnC+W
S/JetO4VGOmDEbyubzIQs6nCuP7rL+N11VHQet3QAZuFNdv2dwV+tl/35l9p1vdQ
sAMh6ZS8EZZHYCLAXU9n1D8wrE49kGYZx/XRzyBHtQVT8tt1LsIE8dPlccLBXK6t
u+fKZIXIQBgFhReAHA2hYEIsw09L4lsLuU4m/7FBq48uscZ/r501Tz4bfb8dzCUW
yfYzpi/HP1UwTAVrdMFWlDwIXFUfAhVsqV8azOc9vhRRXgqjq1hGKl1jiVhpLdqQ
eW8u0m9xosBgbNMmjj+elB7UzOt2MeMWJBk2JibSiIs9J0Dz2dK2Win7ozMWT0Bf
glfni7ILmyCMbGAkfxCAI2B1OJHwio2QPBgVTGO6L4+iPe9Ov+c=
=BZvq
-----END PGP SIGNATURE-----

--=_5SWu4JVC2iqZQXg6UVJP3xs--

From nobody Wed Nov  9 21:31:41 2022
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 4N6ypY1qq7z4dD6q
	for ; Wed,  9 Nov 2022 21:31:49 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits)
	 client-signature ECDSA (P-256))
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6ypY01gXz4R1j;
	Wed,  9 Nov 2022 21:31:49 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id D4EC922B1C;
	Wed,  9 Nov 2022 22:31:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668029503;
	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=KozT+rcAvDcrRuaYsO0BAsh82TsmKP4UDnCM/YXfHPI=;
	b=Tcjf3U/IEPs4YgV9KfsdtWE94kYdJqkYsU/p0lfVCmlQKL/twKlw4alsTI8WZV5rozkoDd
	tYe0/S1gX6JjexYjHwWpAOeCDxu2IGl/rOOG4l4MbsNwECoSM1JPTeY7qhZAxXV59S45Ui
	9q2JakIXPK4bavtcJDFYv/JwCCQyGLHQPFIzmqveIXJGnihPKc5vjq8Dm2BILPS4kIRQjf
	qVZ+xcc/goCLbE0S3J+nYhGZjCgWnRsRatI+tJ89sXqcH1IuApUDATpWlQurzbbjZxbirW
	6PACWCTC74uO9Bt9MVORs35rpRD+2P/VJyB70z+b84fzMLFYB4+y4NVzgbw/xQ==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 6E4CA34A4;
	Wed,  9 Nov 2022 22:31:41 +0100 (CET)
Date: Wed, 09 Nov 2022 22:31:41 +0100
Message-ID: <20221109223141.Horde.nBWydmiH2iSoYq79Rb8jk38@webmail.leidinger.net>
From: Alexander Leidinger 
To: Brooks Davis 
Cc: Mark Millard , "Patrick M. Hausen" ,
        Warner Losh , tsoome@freebsd.org,
        Li-Wen Hsu
 , current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 <20221109204509.Horde.lh5parVrWDSJ7kQCFa64hqe@webmail.leidinger.net>
 <5AFBB434-BB3B-4B5A-AB32-11DAFD03A2AD@hausen.com>
 <20221109205846.Horde.Rm5dcHB7p4mSbfFmxReYEDW@webmail.leidinger.net>
 <671B1F82-A167-45D0-8BCC-4717F433BC11@yahoo.com>
 <20221109211947.Horde.F4xwQw3LUvp0P2aLceiZdwf@webmail.leidinger.net>
 <20221109211841.GC95557@spindle.one-eyed-alien.net>
In-Reply-To: <20221109211841.GC95557@spindle.one-eyed-alien.net>
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_60q9Fa6oz_uZKdKGB16_EF6";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4N6ypY01gXz4R1j
X-Spamd-Bar: ----
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:34240, ipnet:2a00:1828::/32, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_60q9Fa6oz_uZKdKGB16_EF6
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Brooks Davis  (from Wed, 9 Nov 2022=20=20
21:18:41=20+0000):

> On Wed, Nov 09, 2022 at 09:19:47PM +0100, Alexander Leidinger wrote:
>> Quoting Mark Millard  (from Wed, 9 Nov 2022
>> 12:10:18 -0800):
>>
>> > On Nov 9, 2022, at 11:58, Alexander Leidinger
>> >  wrote:
>> >
>> >> Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022
>> >> 20:49:37 +0100):
>> >>
>> >>> Hi,
>> >>>
>> >>>> Am 09.11.2022 um 20:45 schrieb Alexander Leidinger
>> >>>> :
>> >>>> But "zpool set feature@edonr=3Denabled rpool" (or any other feature
>> >>>> not in the list we talk about) would render it unbootable.
>> >>>
>> >>> Sorry, just to be sure. So an active change of e.g. checksum or
>> >>> compression algorithm
>> >>> might render the system unbootable but a zpool upgrade never will?
>> >>> At least not intentionally? ;-)
>> >>
>> >> If you mean "zpool upgrade", then no (modulo bugs). OpenZFS uses
>> >> the feature flags instead of zpool upgrade.
>> >
>> > I'm confused by that answer:
>>
>> See my correction in another mail, the behavior seems to have changed
>> and yes, doing a zpool upgrade on a boot pool should not be done.
>>
>> Maybe someone wants to check or add provisions to not do that on a
>> pool which has the bootfs property set.
>
> Literally the entire point of the script added in the commit this thread
> is about upgrade the boot pool on first boot so that seems like it would
> be counterproductive.

Something is missing here. Either some pointer to some safetynet for=20=20
pools=20with the bootfs property set (or a similar "this is a bootable=20=
=20
pool"=20flag), or a real-world test of the script.

Any brave soul around to spin up a test-VM and perform a "echo before;=20=
=20
zpool=20get all rpool | grep feature; zpool upgrade rpool; echo after;=20=
=20
zpool=20get all rpool | grep feature" inside?

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_60q9Fa6oz_uZKdKGB16_EF6
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsHDwACgkQEg2wmwP4
2IZZXA/+I4O5NnA4VT+pQfBy0XdY94XJz1LYZt5xnbdWbQ8GJKRQ6UIPAGyH+bL7
Lb7je3C5c1s6/S2RWmMqM6FBx/u5BpFtZsF8LwgnhgE+G3YNDtr0w9VY8fJ+Dak9
ivdzlC5G1qWCOpxOy9+5WZUmCarMrdBFLcem/V/DNbnID/WmhF312zXjCwrOk52D
ZW3S4fgzXw6QMnnxFS8AkcRn+SsXZ891vxbp/fJ3AlmGlWJD/yhwITu3vlJw/R2Z
nUL67qSa60DimcdJbmlJyhl9qE3mh9FbQqho2OfG8QAaoa0tLH4TtsfKXVnhVcwc
Py4tLGiTJJ3josaB6zPOFqdD8FnpbJW5WFhJKbEb7r2oC4ySzB6voCQrVe+YHeM+
qndNy7NlG3oTafESrKTgYGedqpUFuZJ6mV4vHAXWT+x+n+fJwxB8370SAXKmowEU
ZMjwoaHhETzh8iFHdTEeXiPW3LZrMAwueS52gLRVCHVhb+FoEAHzjIZMOPb4ky3z
UGV4FUYh0zhXI8bkZE5uSKxtbGrI04noztMKXy+JaUwZ01MDr7d6tGyTMptpmcL5
msp8kbbAEPGzvcBIGvEvLnFCE+a6koL2B78CBGu0b/FnVDRgMphr62FvX0s3xUnM
DPNKXkLntlGazAz8MpcEyM6lRjpAA8E6IiQzy6IgCBy/nr4Limk=
=Ig1A
-----END PGP SIGNATURE-----

--=_60q9Fa6oz_uZKdKGB16_EF6--

From nobody Wed Nov  9 21:38:48 2022
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 4N6yyf3lp9z4dF5m
	for ; Wed,  9 Nov 2022 21:38:50 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4N6yyf2Kpgz4SNX;
	Wed,  9 Nov 2022 21:38:50 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 0F7B9D;
 Wed, 9 Nov 2022 22:38:48 +0100
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 \(3696.120.41.1.1\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: "Patrick M. Hausen" 
In-Reply-To:
 <20221109222600.Horde.yo1Ry8tPu9udiPqUgtdDHNG@webmail.leidinger.net>
Date: Wed, 9 Nov 2022 22:38:48 +0100
Cc: Warner Losh , Mark Millard ,
 tsoome@freebsd.org, Li-Wen Hsu , current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <40D4F908-CE30-4AAF-89FA-E6849027FB17@hausen.com>
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 
 
 
 <20221109220540.Horde.6GRfN8bbUC4AsLcvjhWbUgm@webmail.leidinger.net>
 <65689194-1F56-4429-9A52-794A8354D995@hausen.com>
 <20221109222600.Horde.yo1Ry8tPu9udiPqUgtdDHNG@webmail.leidinger.net>
To: Alexander Leidinger 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N6yyf2Kpgz4SNX
X-Spamd-Bar: ----
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:16188, ipnet:217.29.32.0/20, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> Am 09.11.2022 um 22:26 schrieb Alexander Leidinger =
:
> On quick look I haven't found a place where a compatibility setting is =
used for the rpool during the creation, so I can't point out what the =
exact difference is.
> Given that empty_bpobj is not in the list of the boot code, it can't =
be the same, some limit of enabled features has to be in place during =
initial install, and your example has to be different.

That feature was imported into FreeBSD in 2012 so it should be
enabled in every pool created since then.

Kind regards,
Patrick=

From nobody Wed Nov  9 21:47:28 2022
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 4N6z8l4sTxz4dGLY
	for ; Wed,  9 Nov 2022 21:47:35 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4N6z8g2NCXz4Tsf;
	Wed,  9 Nov 2022 21:47:31 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of pmh@hausen.com has no SPF policy when checking 217.29.33.228) smtp.mailfrom=pmh@hausen.com;
	dmarc=none
Received: from smtpclient.apple (87.138.185.145)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 223B9C;
 Wed, 9 Nov 2022 22:47:29 +0100
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 \(3696.120.41.1.1\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: "Patrick M. Hausen" 
In-Reply-To: <40D4F908-CE30-4AAF-89FA-E6849027FB17@hausen.com>
Date: Wed, 9 Nov 2022 22:47:28 +0100
Cc: Warner Losh , Mark Millard ,
 tsoome@freebsd.org, Li-Wen Hsu , current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 
 
 
 <20221109220540.Horde.6GRfN8bbUC4AsLcvjhWbUgm@webmail.leidinger.net>
 <65689194-1F56-4429-9A52-794A8354D995@hausen.com>
 <20221109222600.Horde.yo1Ry8tPu9udiPqUgtdDHNG@webmail.leidinger.net>
 <40D4F908-CE30-4AAF-89FA-E6849027FB17@hausen.com>
To: Alexander Leidinger 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Spamd-Bar: -
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	R_SPF_NA(0.00)[no SPF record];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	FREEMAIL_CC(0.00)[bsdimp.com,yahoo.com,freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_FIVE(0.00)[6];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[hausen.com];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4N6z8g2NCXz4Tsf
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> Am 09.11.2022 um 22:38 schrieb Patrick M. Hausen :
>> Am 09.11.2022 um 22:26 schrieb Alexander Leidinger =
:
>> On quick look I haven't found a place where a compatibility setting =
is used for the rpool during the creation, so I can't point out what the =
exact difference is.
>> Given that empty_bpobj is not in the list of the boot code, it can't =
be the same, some limit of enabled features has to be in place during =
initial install, and your example has to be different.
>=20
> That feature was imported into FreeBSD in 2012 so it should be
> enabled in every pool created since then.

I apologize, should have included that in the last mail.
This is a current FreeBSD 13.1-p2 hosting system we run.

Boots quite fine ;-)

Kind regards,
Patrick

-----------
[ry93@pdn006 ~]$ zpool get all zroot|grep feature
zroot  feature@async_destroy          enabled                        =
local
zroot  feature@empty_bpobj            active                         =
local
zroot  feature@lz4_compress           active                         =
local
zroot  feature@multi_vdev_crash_dump  enabled                        =
local
zroot  feature@spacemap_histogram     active                         =
local
zroot  feature@enabled_txg            active                         =
local
zroot  feature@hole_birth             active                         =
local
zroot  feature@extensible_dataset     active                         =
local
zroot  feature@embedded_data          active                         =
local
zroot  feature@bookmarks              enabled                        =
local
zroot  feature@filesystem_limits      enabled                        =
local
zroot  feature@large_blocks           enabled                        =
local
zroot  feature@large_dnode            enabled                        =
local
zroot  feature@sha512                 enabled                        =
local
zroot  feature@skein                  enabled                        =
local
zroot  feature@userobj_accounting     active                         =
local
zroot  feature@encryption             enabled                        =
local
zroot  feature@project_quota          active                         =
local
zroot  feature@device_removal         enabled                        =
local
zroot  feature@obsolete_counts        enabled                        =
local
zroot  feature@zpool_checkpoint       enabled                        =
local
zroot  feature@spacemap_v2            active                         =
local
zroot  feature@allocation_classes     enabled                        =
local
zroot  feature@resilver_defer         enabled                        =
local
zroot  feature@bookmark_v2            enabled                        =
local
zroot  feature@redaction_bookmarks    enabled                        =
local
zroot  feature@redacted_datasets      enabled                        =
local
zroot  feature@bookmark_written       enabled                        =
local
zroot  feature@log_spacemap           active                         =
local
zroot  feature@livelist               active                         =
local
zroot  feature@device_rebuild         enabled                        =
local
zroot  feature@zstd_compress          enabled                        =
local
zroot  feature@draid                  enabled                        =
local
-----------


From nobody Wed Nov  9 21:59:04 2022
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 4N6zQS52TDz4dJ0H
	for ; Wed,  9 Nov 2022 21:59:28 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6zQS1m51z4WYp;
	Wed,  9 Nov 2022 21:59:28 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id EF2ED22BCB;
	Wed,  9 Nov 2022 22:59:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668031163;
	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=LQX+4AnOrv+CgAh+9X2d1CH6cVXGrhRo/J5UODFg8/I=;
	b=wqGq7En71xrkWiNF48x2K4pMNZ4NhMNzaVSvLGgm/sGf0+E678AxrQvPD5roZ3O14RB5lV
	KhmHDTDOtBimg9RNMKg+t0ZzXT+DaiNxKP4u0Mal3eL3jOkIsi1Pi4roelyu3dRD8iOo/r
	QBHGIRP21Q7xEgYFWsPOO+jCOTh6iCsFQBa92o+yQ70odbeES0lsllPR11NzpIoEq06Jtf
	7Bp0sz3f8BUIOvu6YEf3vfADUR6J0sv8C5RwL0GwHDLhr9hDcah0g7b4+CVyAN9MriUZYB
	IH/qUNwE7XbpyxJJcxjmvaJHU+Yl4IfI4290m4xgNd7DM+Z5B8caj6Jktd3iCQ==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id E7DAE3586;
	Wed,  9 Nov 2022 22:59:04 +0100 (CET)
Date: Wed, 09 Nov 2022 22:59:04 +0100
Message-ID: <20221109225904.Horde.a8xggy6etutDDjHEEeWpdpb@webmail.leidinger.net>
From: Alexander Leidinger 
To: "Patrick M. Hausen" 
Cc: Warner Losh , Mark Millard ,
        tsoome@freebsd.org, Li-Wen Hsu ,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 
 
 
 <20221109220540.Horde.6GRfN8bbUC4AsLcvjhWbUgm@webmail.leidinger.net>
 <65689194-1F56-4429-9A52-794A8354D995@hausen.com>
 <20221109222600.Horde.yo1Ry8tPu9udiPqUgtdDHNG@webmail.leidinger.net>
 <40D4F908-CE30-4AAF-89FA-E6849027FB17@hausen.com>
 
In-Reply-To: 
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_sxpqu5UKDMZNwiBNssazIHz";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4N6zQS1m51z4WYp
X-Spamd-Bar: ----
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:34240, ipnet:2a00:1828::/32, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_sxpqu5UKDMZNwiBNssazIHz
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022=20=20
22:47:28=20+0100):

> Hi,
>
>> Am 09.11.2022 um 22:38 schrieb Patrick M. Hausen :
>>> Am 09.11.2022 um 22:26 schrieb Alexander Leidinger=20=20
>>>=20:
>>> On quick look I haven't found a place where a compatibility=20=20
>>>=20setting is used for the rpool during the creation, so I can't=20=20
>>>=20point out what the exact difference is.
>>> Given that empty_bpobj is not in the list of the boot code, it=20=20
>>>=20can't be the same, some limit of enabled features has to be in=20=20
>>>=20place during initial install, and your example has to be different.
>>
>> That feature was imported into FreeBSD in 2012 so it should be
>> enabled in every pool created since then.
>
> I apologize, should have included that in the last mail.
> This is a current FreeBSD 13.1-p2 hosting system we run.
>
> Boots quite fine ;-)

There are several in the list which are not in the list in zfsipl.c.=20=20
So=20that list is not the full truth...

Bye,
Alexander.

> -----------
> [ry93@pdn006 ~]$ zpool get all zroot|grep feature
> zroot  feature@async_destroy          enabled                        loca=
l
> zroot  feature@empty_bpobj            active                         loca=
l
> zroot  feature@lz4_compress           active                         loca=
l
> zroot  feature@multi_vdev_crash_dump  enabled                        loca=
l
> zroot  feature@spacemap_histogram     active                         loca=
l
> zroot  feature@enabled_txg            active                         loca=
l
> zroot  feature@hole_birth             active                         loca=
l
> zroot  feature@extensible_dataset     active                         loca=
l
> zroot  feature@embedded_data          active                         loca=
l
> zroot  feature@bookmarks              enabled                        loca=
l
> zroot  feature@filesystem_limits      enabled                        loca=
l
> zroot  feature@large_blocks           enabled                        loca=
l
> zroot  feature@large_dnode            enabled                        loca=
l
> zroot  feature@sha512                 enabled                        loca=
l
> zroot  feature@skein                  enabled                        loca=
l
> zroot  feature@userobj_accounting     active                         loca=
l
> zroot  feature@encryption             enabled                        loca=
l
> zroot  feature@project_quota          active                         loca=
l
> zroot  feature@device_removal         enabled                        loca=
l
> zroot  feature@obsolete_counts        enabled                        loca=
l
> zroot  feature@zpool_checkpoint       enabled                        loca=
l
> zroot  feature@spacemap_v2            active                         loca=
l
> zroot  feature@allocation_classes     enabled                        loca=
l
> zroot  feature@resilver_defer         enabled                        loca=
l
> zroot  feature@bookmark_v2            enabled                        loca=
l
> zroot  feature@redaction_bookmarks    enabled                        loca=
l
> zroot  feature@redacted_datasets      enabled                        loca=
l
> zroot  feature@bookmark_written       enabled                        loca=
l
> zroot  feature@log_spacemap           active                         loca=
l
> zroot  feature@livelist               active                         loca=
l
> zroot  feature@device_rebuild         enabled                        loca=
l
> zroot  feature@zstd_compress          enabled                        loca=
l
> zroot  feature@draid                  enabled                        loca=
l
> -----------


--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_sxpqu5UKDMZNwiBNssazIHz
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNsIqgACgkQEg2wmwP4
2IZpjw//TtB+YvtR2NvvRKpElUag5GHPOu98od6s1CMY6WLgxhw9K2Q3TaiIGy5Q
/BNMB1QWB7RjJ6xh8K5dOmEKnjaMIOa6pXx2GPBiW3f4FPZxtDAIpxHu7A1C91Pj
s5glCvt0vwyo8P6WAHoq5AYdVgv+gFkroYISOlyhnwH3LCePk0zWi7MHo2Efdotr
hBCvyBT+mSq2L09nllGPIVG6QpTgYQ6vZN70WmfvtoDPdKq4mlkB6V6wJOaEbk/m
n2f6GmXWyEm8rxM0iduYZsU8+LAs0esuk84zBHatGWpHU1HQJq6JoH0wfa5HACHW
3yGRVmVUjmlacATWxkZMFJ6VOQz/qXMEOPoazwbpvhzCK4APc4ET0F6mVfjvyAsJ
+el/zU3IWAfqUWAqN9fI1oui3gdoJ4hCbmdKVtVrJL9jxuRugr0gszcRgpDuAbtp
bItH6KivYNmwd+WdC+VreS6YSBfBY8Qt0/JFNEMt1gipZcLnCH91TH+OZIwBDcW3
QF5dg82G5OfKt4Ik39TkZCqr1RabthfS2jjRs7MkXZ4FJUb2jqCwf05D/y8mF7qa
Rp6BLwts4JKzCx00PI/R1HFkTL6S0wSVF8BnxUEH7pJBfVODVVDzWOz4SZ2TKfgh
zUAPofasN3c5QdIEdq595oKmrAKemBkx8NdxpOzOg2mRgTEeJS0=
=CCdi
-----END PGP SIGNATURE-----

--=_sxpqu5UKDMZNwiBNssazIHz--

From nobody Wed Nov  9 22:04:17 2022
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 4N6zX738yCz4dJgQ
	for ; Wed,  9 Nov 2022 22:04:23 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228])
	(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 4N6zX71Z9Qz4YBx;
	Wed,  9 Nov 2022 22:04:23 +0000 (UTC)
	(envelope-from pmh@hausen.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (140.82.8.233)
 by mail2.pluspunkthosting.de (Axigen)
 with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 0E197D;
 Wed, 9 Nov 2022 23:04:20 +0100
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 \(3696.120.41.1.1\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: "Patrick M. Hausen" 
In-Reply-To:
 <20221109225904.Horde.a8xggy6etutDDjHEEeWpdpb@webmail.leidinger.net>
Date: Wed, 9 Nov 2022 23:04:17 +0100
Cc: Warner Losh , Mark Millard ,
 tsoome@freebsd.org, Li-Wen Hsu , current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 
 
 
 <20221109220540.Horde.6GRfN8bbUC4AsLcvjhWbUgm@webmail.leidinger.net>
 <65689194-1F56-4429-9A52-794A8354D995@hausen.com>
 <20221109222600.Horde.yo1Ry8tPu9udiPqUgtdDHNG@webmail.leidinger.net>
 <40D4F908-CE30-4AAF-89FA-E6849027FB17@hausen.com>
 
 <20221109225904.Horde.a8xggy6etutDDjHEEeWpdpb@webmail.leidinger.net>
To: Alexander Leidinger 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4N6zX71Z9Qz4YBx
X-Spamd-Bar: ----
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:16188, ipnet:217.29.32.0/20, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> Am 09.11.2022 um 22:59 schrieb Alexander Leidinger =
:
> Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022 =
22:47:28 +0100):
>>=20
>> I apologize, should have included that in the last mail.
>> This is a current FreeBSD 13.1-p2 hosting system we run.
>> [ List of features from an active root pool ]
>> Boots quite fine ;-)
>=20
> There are several in the list which are not in the list in zfsipl.c. =
So that list is not the full truth...

Or whatever is missing is not critical to booting. The boot loader does =
not need
read/write access to the zpool. It only needs to be able to locate and =
read the kernel.

Kind regards,
Patrick=

From nobody Wed Nov  9 22:12:21 2022
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 4N6zjh3Vncz4dL9T
	for ; Wed,  9 Nov 2022 22:12:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N6zjh0xvNz4ZgX
	for ; Wed,  9 Nov 2022 22:12:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668031958; bh=W76b6JCXVx6zJJ5C3lZvzfDHxBPSlGdle0BgWBf21lM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NjrOX1lXHqkdrwcbn1WPYeJcVulox22S25DbKn3gFALOew87lnHxUwlfF86vsyY2tbpQmaPaY3UigyhytoaZuoc2M3YC0fzFowv3T/SI/td0IWV5WB5vlXos4s9gMmpivCUpqHa3Z5+St6Kd8wAcrCMkwB6Q9Wf1zBXbHEOHzkwV3+Nypt/VPc470MkviKfWQqUU97lKOIEypNRxjLoeqkDwu93BIZQN1i0AQPSVRqmsilYLHZMgjEaj9yOtpYmeyeXVN/dX9KiSLtRDZ5EAif4MLG9rYEpHBHFtDmatKkrXJsZokwrj1qF8q7E/8bimE++nmPYowKj+B6xFHMRwWA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668031958; bh=j9uipP8Td03oByEJ7gM3rmB4HxY28ruX9FrQtfzf+h6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uLr7+1njyRHbzDF9/oBJj1/ftdYHvn6bdCUWAHahNGXyviczsQxL+yyQZzF/mQ6gtyYEKfwj0fyFeX6Z5Jfe1yY4af5im7/gDqiehvpmanliHJxSuL6rXhAOUWS1TvQDx4yXIfIU5na6aiR6HGhcQwjKQNMJmCui+uN7siN3NXRTmcb/N2b2ll4lucYPhdeW2MghJlrAfZi+6Wn1tpTctx+5OvwdvvYJGUckrb933JJxH0n/cVziWDH6R00DBm7n5k2mlM4VhUd7zRgkCGnIRnrpj9Th/kx6gJubZ2x93fDTzE/24puncNwJVCyCM/eL28sseunZmQKYKrLqhhXCTA==
X-YMail-OSG: kIhg.sQVM1mzWNEY1PgcWlTGbnWb034eQlXF6Z5l8Mgj642Vy1poTxOpP7pQfO0
 B29NnXiaE9JImR.WZkZWDFAaG0p93TK4n5uT6grm.aWJuBQolR5YoDOSOdm.yk84j0x5tgKlWM6n
 UAzbAvU.t8ilKH1Y4BXpHfk_ChArpNR7j9BvtumjXuDg0mUSd6JpVHW3NF0C_.nfS1USxywj8pjT
 Srp8g8A1bw2HgWtG.V89MUiK.2ddPOz4DHVWJU36zAu5arIaYBXxvcQxwcxOdnbmkJz_DKrEncAr
 75JonUCxWqvsP.y7hLOXGB5kUUSGeP8_MU9.y.c9_zPkkAESYctG9gxI7UUqxLyqEvZeJeepM1_1
 PILfGi6jrLyF74qxSAgIe0mSVhGy1xClRm2caK8.725RKa5Rill8hFoRRmvOuh0bbmbZ2Zi43EwV
 PQ7HzM2bOOqtm3mfDKb7ZlNttjfQd.LMz1HEoTbHGp_44siQ89YAstGip8RzWy9Hjdzp7L4hWJOs
 iv0Jrylx86yyo2UlvDPXsLLIcBBTFWC3ci6ScIbWNvES_sPpigBlUI6X_mhUhLuJGGacULbYAL_0
 Hw8WrH79NJa2uh14loI1Y.5QyRe6LDleZxGDldg0rTov7d6AH0Z13h6xpLlDOW7QQPuqG3wVkNN4
 63RFeobCqMheEC.gzahDyzmuGNW7wPPyWHpLm8xU3thwskDnZS.wu39H7z98yaPaHoWEroKy_qP5
 Irq5n_MzfXZHSAUGa6b68rtrCFCsKQlUOXLTa4Tw00QiumZniMn9rdUBYZ7YJWAQIFdJjDrY4.yY
 VxJR9q1BfpXO4V5GcZRnHI8I2Kudd5l9LqQ3X6XnAcevBiuD1EFq8P9Qykiu0Vf4HEAcFfq5q.CW
 TxSCPmN1w2.gup4Htsw_79GSinLk_cYeQqjtGlY3C4Pp8dOrIKRzncZu02.6iNTSbAkafCyWQhth
 CUHkXyoEQGrd2DWwiHoyuBdJ5VP3f2jzsWe4cveAZBupS6hf7D1X3JnN4cZX4M9avqS1XI.H1wWQ
 V8zj0S_zBFK1a_ikEsGQf3.Wx8CL3eksAzzuXlnlF7blYIcQj9PXRZaQFAXc91oDJ8cUgf7oeJzD
 PfWO9TJ7psZlWqt6zeX42jyLeQAkmWze433MHOKGERLVTDinZt.r.3XhdHc7.dZqkAeubOD8vQXI
 BkagRPu3WaUJyM8R5oiGFAKXD3k1SccmE4u1RKVJmR4tWWahxMGm0ejTU_1mZynh_tVi3Qx2D1B3
 Xv8PWzDueFFE7tM_2_stIPOfKTeYyf7GM9o9d3d4aCtBSIUzowhFL1SPFkG8iLc0z2LQB.tQ8TS9
 vypcb321rJT_7e3YIwWsOszTO_1OzZW3GWZgQhfx.HjF4P.LGkNzANrsLvhovK240rKSi5XZywxP
 Pwg_auyruVPN94LLniuboEI9e5Vm1DUm3iQSjXgdE151t3vEW6cvjwlETuyCb2scSHEvf0Ywdyx9
 8Kzk4g5I0yvIVpYDL34BLkWv21i7eP9czionbApK0TZVpgCtAfn6rRm7TEbKo7sOFRra4g3AO3pl
 1PjtGglT3mef3Pd9O8YwUN0FLJlAa97z9J_oJn_2Kl9WI3_wxR4aCxWbEbopc_B9ShlcJOD9Umic
 UqRTCMBwE329GCkqD9nvgW.R6YnF_1Lc_pEWcEImeI7.ccx3YRT2M9xR581P6tLpKp98qiXomzkH
 CcOtbhPflKCCA1xnMPEYCeoPfuqnRmzDY30DakQJCoXLJ0xHRKGdN_JtjYS3WO1XaCuLd.0vkWLV
 rPIzd0bMrGaAfGTOqs22.FBdu1U.4YTEj.XavkHIKabpKleUwh.GJaYbAzKohaXT48EISc6irAGZ
 6k9kyVKS5VBvX2TYxZQr5aUZhNziBxtWTayIzVhidOzKdeYYe3_sdd.JrFdZGNCRMIVPabROHr5m
 P.DP26yv9X2TZjKZ1mMdtMPRLi9zdzmu0dm0JGIQwTneDCQ7WqAQeUQeG5gAVlJ8i3gIxnYB6pGx
 VFDF42xTLjX6f_IZifrIxVBYXCos8v8zRWd9tRqCSSkLU5X1JxvP1Au34uEBKsrNMsnD7Q5unBFZ
 fE4AKdAEN2qm7pgw1WjFwUBiK1CFqBrDRTqu0H82Vbej9_GBFqEhvMfwJkkTetX5rHS_9z58ksMT
 10HGdpd0dZ_vEfpbWB04_0A9009Hu4IxgzkfSjBZTn3EhXqHfDrRV0cPlJRadh_ym_FH8IkjnuTs
 OoDwaroXmgKX6Ifnts82YE_DGA30cPAHeyIEBw77R4HiiU9Rfb9Mu6FFYQORJqys8XcUjebekXD4
 ZvfF4Q5CW
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 9 Nov 2022 22:12:38 +0000
Received: by hermes--production-gq1-579bc4bddd-hw848 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 07b8ac7f76d99736ed60c23b7a7b8173;
          Wed, 09 Nov 2022 22:12:32 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
From: Mark Millard 
In-Reply-To: 
Date: Wed, 9 Nov 2022 14:12:21 -0800
Cc: "Patrick M. Hausen" ,
 Alexander Leidinger ,
 tsoome@freebsd.org,
 Li-Wen Hsu ,
 current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
 <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
 
 
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N6zjh0xvNz4ZgX
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]
X-ThisMailContainsUnwantedMimeParts: N

On Nov 9, 2022, at 12:56, Warner Losh  wrote:

> On Wed, Nov 9, 2022 at 1:54 PM Patrick M. Hausen  =
wrote:
>=20
> > Am 09.11.2022 um 21:51 schrieb Warner Losh :
> > Yes. For safety, boot loader upgrade is mandatory when you do a =
zpool upgrade of the root filesystem.
> > It was definitely needed in the OpenZFS jump, and we've had one or =
two other flag days since.
>=20
> That's a given and not a problem. What I fear from my understanding of =
this thread so far is
> that there might be a situation when I upgrade the zpool and the boot =
loader and the system
> ends up unbootable nonetheless.
>=20
> Possible or not?
>=20
> If all you do is upgrade, then no, modulo bugs that we've thankfully =
not had yet.

I guess you mean FreeBSD upgrade, not zpool updgrade?

For zpool upgrade after a main [so: 14] FreeBSD upgrade . . .

As I understand it, com.delphix:head_errlog was not added to
the loader until after some folks had done a zpool upgrade
and then could not boot. The loader was updated in response
to the people's problem with trying to boot.

Of course, this was main, not stable or releng/13.* or the
like. There is more control over the staging of updates
for them.

It would be nice if UPDATING reported when a openzfs update
was adding new zpool feature(s) to main and if the loader
was ready for them yet. If not: Later adding an entry for
the loader being ready for the feature(s).

> It's when you enable something on the zpool that you can run into =
trouble, but that's true independent of upgrade :)
>=20
> Warner
>   Modulo bugs, try test systems first, etc. Of course.
>=20

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


From nobody Thu Nov 10 00:32:06 2022
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 4N72pq2D7Wz4dmvK
	for ; Thu, 10 Nov 2022 00:32:19 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N72pp4qNkz3hhL;
	Thu, 10 Nov 2022 00:32:18 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2AA0W6UB075709;
	Thu, 10 Nov 2022 09:32:07 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Thu, 10 Nov 2022 09:32:06 +0900
From: Tomoaki AOKI 
To: "Patrick M. Hausen" 
Cc: Alexander Leidinger ,
        Warner Losh
 , Mark Millard ,
        tsoome@freebsd.org, Li-Wen Hsu ,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
Message-Id: <20221110093206.661bbe915fd2e37338df51be@dec.sakura.ne.jp>
In-Reply-To: 
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
	<20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
	<20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
	
	<460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
	
	
	
	<20221109220540.Horde.6GRfN8bbUC4AsLcvjhWbUgm@webmail.leidinger.net>
	<65689194-1F56-4429-9A52-794A8354D995@hausen.com>
	<20221109222600.Horde.yo1Ry8tPu9udiPqUgtdDHNG@webmail.leidinger.net>
	<40D4F908-CE30-4AAF-89FA-E6849027FB17@hausen.com>
	
	<20221109225904.Horde.a8xggy6etutDDjHEEeWpdpb@webmail.leidinger.net>
	
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4N72pp4qNkz3hhL
X-Spamd-Bar: ----
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:7684, ipnet:153.125.128.0/18, country:JP]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, 9 Nov 2022 23:04:17 +0100
"Patrick M. Hausen"  wrote:

> Hi,
> 
> > Am 09.11.2022 um 22:59 schrieb Alexander Leidinger :
> > Quoting "Patrick M. Hausen"  (from Wed, 9 Nov 2022 22:47:28 +0100):
> >> 
> >> I apologize, should have included that in the last mail.
> >> This is a current FreeBSD 13.1-p2 hosting system we run.
> >> [ List of features from an active root pool ]
> >> Boots quite fine ;-)
> > 
> > There are several in the list which are not in the list in zfsipl.c. So that list is not the full truth...
> 
> Or whatever is missing is not critical to booting. The boot loader does not need
> read/write access to the zpool. It only needs to be able to locate and read the kernel.
> 
> Kind regards,
> Patrick

loader needs to read /boot/loader.conf, related scripts and kmods
under /boot/ from boot pool, too. Not just kernel.

Maybe, `zpool upgrade` would need some overhaul, with small change
to stand/libsa/zfs/zfsimpl.c.

 *Move features_for_read[] alone to new, dedicated header that can be
  included from both stand/libsa/zfs/zfsimpl.c and any others (including
  zpool).

 *Let zpool to check whether the pool is bootable or not, and if
  bootable, only enable features included in the matrix, otherwise,
  enable all supported features on FreeBSD.

I don't think ALL OS'es that have OpenZFS inported can always boot with
all features enabled.
So changes to zpool would be able to OS independent except the header
defining features supported by its loader.

There can be other matrixes for implemented (after boot) and
default-to-be-enabled features. The OS-dependent matrixes would ease ZFS
developers to determine which features are implemented / defaulted /
bootable on specific OS. (Already there?)


-- 
Tomoaki AOKI    

From nobody Thu Nov 10 00:42:13 2022
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 4N732K1fklz4dpsj
	for ; Thu, 10 Nov 2022 00:42:17 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N732J66hyz3kGk;
	Thu, 10 Nov 2022 00:42:16 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2AA0gD11077092;
	Thu, 10 Nov 2022 09:42:13 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Thu, 10 Nov 2022 09:42:13 +0900
From: Tomoaki AOKI 
To: Mark Millard 
Cc: Warner Losh , "Patrick M. Hausen" ,
        Alexander Leidinger , tsoome@freebsd.org,
        Li-Wen
 Hsu , current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
Message-Id: <20221110094213.7c3d5a2bd2422b0b89ce4d12@dec.sakura.ne.jp>
In-Reply-To: 
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
	<20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
	
	<20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
	<20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
	
	<460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com>
	
	
	
	
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4N732J66hyz3kGk
X-Spamd-Bar: ----
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:7684, ipnet:153.125.128.0/18, country:JP]
X-ThisMailContainsUnwantedMimeParts: N

On Wed, 9 Nov 2022 14:12:21 -0800
Mark Millard  wrote:

> On Nov 9, 2022, at 12:56, Warner Losh  wrote:
> 
> > On Wed, Nov 9, 2022 at 1:54 PM Patrick M. Hausen  wrote:
> > 
> > > Am 09.11.2022 um 21:51 schrieb Warner Losh :
> > > Yes. For safety, boot loader upgrade is mandatory when you do a zpool upgrade of the root filesystem.
> > > It was definitely needed in the OpenZFS jump, and we've had one or two other flag days since.
> > 
> > That's a given and not a problem. What I fear from my understanding of this thread so far is
> > that there might be a situation when I upgrade the zpool and the boot loader and the system
> > ends up unbootable nonetheless.
> > 
> > Possible or not?
> > 
> > If all you do is upgrade, then no, modulo bugs that we've thankfully not had yet.
> 
> I guess you mean FreeBSD upgrade, not zpool updgrade?
> 
> For zpool upgrade after a main [so: 14] FreeBSD upgrade . . .
> 
> As I understand it, com.delphix:head_errlog was not added to
> the loader until after some folks had done a zpool upgrade
> and then could not boot. The loader was updated in response
> to the people's problem with trying to boot.
> 
> Of course, this was main, not stable or releng/13.* or the
> like. There is more control over the staging of updates
> for them.

Unfortunately, sometimes adding X-MFC-WITH is forgotton on follow-up
commits, making the commit NOT MFC'ed to stable/* and fire there again.

And unfortunately, even though X-MFC-WITH is added, sometimes MFC is
missed.


> It would be nice if UPDATING reported when a openzfs update
> was adding new zpool feature(s) to main and if the loader
> was ready for them yet. If not: Later adding an entry for
> the loader being ready for the feature(s).

+1.


> > It's when you enable something on the zpool that you can run into trouble, but that's true independent of upgrade :)
> > 
> > Warner
> >   Modulo bugs, try test systems first, etc. Of course.
> > 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 
> 


-- 
Tomoaki AOKI    

From nobody Thu Nov 10 14:35:28 2022
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 4N7PWv2Tyfz4XCwr
	for ; Thu, 10 Nov 2022 14:35:39 +0000 (UTC)
	(envelope-from dan@sunsaturn.com)
Received: from sunsaturn.com (sunsaturn.com [IPv6:2604:4300:a:196::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 (2048 bits) client-digest SHA256)
	(Client CN "sunsaturn.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N7PWs6sJJz4LSH;
	Thu, 10 Nov 2022 14:35:37 +0000 (UTC)
	(envelope-from dan@sunsaturn.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=sunsaturn.com header.s=default header.b=eUSoGekx;
	spf=pass (mx1.freebsd.org: domain of dan@sunsaturn.com designates 2604:4300:a:196::3 as permitted sender) smtp.mailfrom=dan@sunsaturn.com;
	dmarc=none
Received: by sunsaturn.com (Postfix, from userid 1001)
	id E015D69B44; Thu, 10 Nov 2022 08:35:28 -0600 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunsaturn.com;
	s=default; t=1668090928;
	bh=zDJv4dWNqvOv9ki7Ol/7yLwcuy1BhFkMT3Ygk1+F+8k=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=eUSoGekxmtkDrhYi+eEYYotCU5srJUJC2Y8p+LRt5bbvStpjay0B3VpNwC8pCkUku
	 bRxVQCxeLJCQrZI5ByVXULPoJBLXuUA57kR8euy08aHvJYp+m8klk8I3l45jMUSzL3
	 mOmmPWN7iY4JDjLU0Y8egR4aiM/AaCrSg3hEUlRc=
Received: from localhost (localhost [127.0.0.1])
	by sunsaturn.com (Postfix) with ESMTP id DF39D69BBF;
	Thu, 10 Nov 2022 08:35:28 -0600 (CST)
Date: Thu, 10 Nov 2022 08:35:28 -0600 (CST)
From: Dan The Man 
To: Alexander Motin 
cc: freebsd-current@FreeBSD.org
Subject: Re: vfs.zfs.vol.recursive hang makes it impossible to mount zvol
In-Reply-To: <62348dc1-7f9a-f8ae-db77-f2f5d8a709d8@FreeBSD.org>
Message-ID: <5014f48c-f70d-abd5-32b2-796acccda928@sunsaturn.com>
References:  <62348dc1-7f9a-f8ae-db77-f2f5d8a709d8@FreeBSD.org>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1969398039-1231111786-1668090928=:15763"
X-Spamd-Bar: --
X-Spamd-Result: default: False [-2.07 / 15.00];
	CTYPE_MIXED_BOGUS(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.997];
	NEURAL_HAM_MEDIUM(-0.57)[-0.572];
	R_SPF_ALLOW(-0.20)[+ip6:2604:4300:a:196::3];
	R_DKIM_ALLOW(-0.20)[sunsaturn.com:s=default];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	MIME_TRACE(0.00)[0:+,1:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[sunsaturn.com:+];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:33387, ipnet:2604:4300::/32, country:US];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[dan];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[sunsaturn.com: no valid DMARC record];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4N7PWs6sJJz4LSH
X-ThisMailContainsUnwantedMimeParts: N

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1969398039-1231111786-1668090928=:15763
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT


Hi Alexander,

Thank-you for getting back to me. I tried as you suggested going through 
scsi instead. While that does work being able to mount /dev/da* 
devices, an issue I have run into is that suspend/resume features do not 
seem to work with virtio-scsi.

If I set it back to virtio-blk through original /dev/zvol/zroot/* devices 
or through the scsi /dev/da* devices then suspend/resume works.

Let me elaborate, here is what I put together today based on your 
suggestion:

router:/root # cat /etc/ctl.conf
portal-group pg0 {
         discovery-auth-group no-authentication
         listen 127.0.0.1:3260
}
target iqn.2005-02.com.sunsaturn:target0 {
         auth-group no-authentication
         portal-group pg0
         #bhyve virti-iscsi disk - /dev/cam/ctl1.0
         port ioctl/1
         lun 0 {
                 path /dev/zvol/zroot/asterisk
                 serial 000c2937247001
                 device-id "iSCSI Disk 000c2937247001"
                 option vendor "FreeBSD"
                 option product "iSCSI Disk"
                 option revision "0123"
                 option insecure_tpc on
         }
}
target iqn.2005-02.com.sunsaturn:target1 {
         auth-group no-authentication
         portal-group pg0
         #bhyve virti-iscsi disk - /dev/cam/ctl2.0
         port ioctl/2

         lun 0 {
                 path /dev/zvol/zroot/asterisk2
                 serial 000c2937247002
                 device-id "iSCSI Disk 000c2937247002"
                 option vendor "FreeBSD"
                 option product "iSCSI Disk"
                 option revision "0123"
                 option insecure_tpc on
         }
         lun 1 {
                 path 
/vm/.iso/FreeBSD-14.0-CURRENT-amd64-20221103-5cc5c9254da-259005-disc1.iso
                 #byhve seems to just hang when I set it to an actual CDROM 
so let it default to type 0
                 #device-type 5
                 serial 000c2937247003
                 device-id "iSCSI CDROM ISO 000c2937247003"
                 option vendor "FreeBSD CDROM"
                 option product "iSCSI CDROM"
                 option revision "0123"
                 option insecure_tpc on
         }
}
router:/root # cat /etc/iscsi.conf
t0 {
         TargetAddress   = 127.0.0.1:3260
         TargetName      = iqn.2005-02.com.sunsaturn:target0
}
t1 {
         TargetAddress   = 127.0.0.1:3260
         TargetName      = iqn.2005-02.com.sunsaturn:target1
}
router:/root # tail -13 /etc/rc.conf
#ISCSI - service ctld start && service iscsid start
#server
ctld_enable="YES"          #load /etc/ctl.conf
iscsid_enable="YES"        #start iscsid process to connect to ctld
#client - service iscsictl start
iscsictl_enable="YES"      #connect to all targets in /etc/iscsi.conf
iscsictl_flags="-Aa"
#to kill all sessions:
#iscsictl -Ra
#to restart everything:
#iscsictl -Ra
#service ctld stop && service iscsid stop
#service ctld start && service iscsid start && service iscsictl start
router:/root #

Now anytime I use:
-s 4:0,virtio-scsi,/dev/cam/ctl1.0

I get coredumps as follows when resuming the guest:
./asterisk.sh: line 101:  7621 Segmentation fault      (core 
dumped) bhyve -c $CPU -m $RAM -w -H -A -s 0:0,hostbridge -s 
4:0,virtio-scsi,$STORAGE -s 5:0,virtio-net,$TAP -s 
29,fbuf,tcp=$HOST:$PORT,w=$WIDTH,h=$HEIGHT -s 30,xhci,tablet -s 31,lpc -l 
com1,$SERIAL -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd -r 
$DIR/default.ckp $VMNAME
The exit code was : 139

However if I used:
-s 4:0,virtio-blk,/dev/da1
or even:
-s 4:0,virtio-blk,/dev/zvol/zroot/asterisk

suspend/resume works properly. Is virtio-scsi supported through the ioctl 
devices?

I'll include my test suspend/resume script if you want to have a look:

#####asterisk.sh
#!/bin/bash
#
# General script to test bhyve suspend/resume features
#
# Requirements: FreeBSD current
# git clone https://git.FreeBSD.org/src.git /usr/src
# cd /usr/src/sys/amd64/conf (edit MYKERNEL) cp GENERIC MYKERNEL; (add: 
options         BHYVE_SNAPSHOT)
# cd /usr/src
# (find amount of CPUs and adjust -j below - "dmesg|grep SMP")
# make -j12 buildworld -DWITH_BHYVE_SNAPSHOT -DWITH_MALLOC_PRODUCTION
# make -j12 buildkernel KERNCONF=MYKERNEL
# make installkernel KERNCONF=MYKERNEL
# shutdown -r now
# cd /usr/src; make installworld
# shutdown -r now
# etcupdate -B
# pkg bootstrap -f #if new freebsd version
# pkg upgrade -f   #if new freebsd version
#
# Report anomolies to dan@sunsaturn.com

##############EDIT ME#####################


HOST="127.0.0.1"                        # vncviewer 127.0.0.1:5900 - pkg 
install tightvnc
PORT="5900"
WIDTH="800"
HEIGHT="600"
VMNAME="asterisk"
ISO="/vm/.iso/FreeBSD-14.0-CURRENT-amd64-20221103-5cc5c9254da-259005-disc1.iso"
DIR="/vm/asterisk"                      # Used to hold files when guest 
suspended
SERIAL="/dev/nmdm_asteriskA"           # For "screen /dev/nmdm_asteriskB" 
- pkg install screen
TAP="tap0"
CPU="8"
RAM="8G"

#For testing virtio-scsi
STORAGE="/dev/cam/ctl1.0"               # port from /etc/ctl.conf(port 
ioctl/1) - core dumping on resume
DEVICE="virtio-scsi"

#for testing virtio-blk                 # Comment out above 2 lines if 
using these
#DEVICE="virtio-blk"
#STORAGE="/dev/zvol/zroot/asterisk"     # Standard zvol
#STORAGE="/dev/da1"                     # Block device created from 
iscsictl

#########################################

usage() {
    echo "Usage: $1 start    (Start the guest: $VMNAME)";
    echo "Usage: $1 stop     (Stop the guest: $VMNAME)";
    echo "Usage: $1 resume   (Resume the guest from last suspend: 
$VMNAME)";
    echo "Usage: $1 suspend  (Suspend the guest: $VMNAME)";
    echo "Usage: $1 install  (Install new guest: $VMNAME)";
    exit
}

if [ ! -d "$DIR" ]; then
    mkdir -p $DIR
fi

#if [ -z "$2" ]; then
#   usage
#else
#   VMNAME=$2
#fi


if [ "$1" == "install" ]; then
    #Kill it before starting it
    echo "Execute: screen $SERIAL"
    bhyvectl --destroy --vm=$VMNAME
    bhyve -c $CPU -m $RAM -w -H -A \
       -s 0:0,hostbridge \
       -s 3:0,ahci-cd,$ISO \
       -s 4:0,virtio-scsi,$STORAGE  \
       -s 5:0,virtio-net,$TAP \
       -s 29,fbuf,tcp=$HOST:$PORT,w=$WIDTH,h=$HEIGHT \
       -s 30,xhci,tablet \
       -s 31,lpc -l com1,stdio \
       -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
       $VMNAME
    #kill it after
    bhyvectl --destroy --vm=$VMNAME
elif [ "$1" == "start" ]; then
    while true
    do
       echo "Starting $VMNAME -s 
29,fbuf,tcp=$HOST:$PORT,w=$WIDTH,h=$HEIGHT"
       #Kill it before starting it
       bhyvectl --destroy --vm=$VMNAME > /dev/null 2>&1
       if [ -f "$DIR/default.ckp" ]; then
          bhyve -c $CPU -m $RAM -w -H -A \
             -s 0:0,hostbridge \
             -s 4:0,virtio-scsi,$STORAGE  \
             -s 5:0,virtio-net,$TAP \
             -s 29,fbuf,tcp=$HOST:$PORT,w=$WIDTH,h=$HEIGHT \
             -s 30,xhci,tablet \
             -s 31,lpc -l com1,$SERIAL \
             -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
             $VMNAME
       fi
       #DISABLING REBOOT LOOP AS SUSPEND RETURNS ERROR CODE 0 AS WELL
       #if [ "$?" != 0 ];
       #then
       #   echo "The exit code was not reboot code 0!: $?"
       #   exit
       #fi
       echo "The exit code was : $?"
       exit
    done
elif [ "$1" == "resume" ]; then
    while true
    do
       echo "Starting $VMNAME -s 
29,fbuf,tcp=$HOST:$PORT,w=$WIDTH,h=$HEIGHT"
       #Kill it before starting it
       bhyvectl --destroy --vm=$VMNAME > /dev/null 2>&1
       if [ -f "$DIR/default.ckp" ]; then
          bhyve -c $CPU -m $RAM -w -H -A \
             -s 0:0,hostbridge \
             -s 4:0,virtio-scsi,$STORAGE  \
             -s 5:0,virtio-net,$TAP \
             -s 29,fbuf,tcp=$HOST:$PORT,w=$WIDTH,h=$HEIGHT \
             -s 30,xhci,tablet \
             -s 31,lpc -l com1,$SERIAL \
             -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
             -r $DIR/default.ckp \
             $VMNAME
       fi
       #DISABLING REBOOT LOOP AS SUSPEND RETURNS ERROR CODE 0 AS WELL
       #if [ "$?" != 0 ];
       #then
       #   echo "The exit code was not reboot code 0!: $?"
       #   exit
       #fi
       echo "The exit code was : $?"
       exit
    done
elif [ "$1" == "suspend" ];
then
    bhyvectl --suspend $DIR/default.ckp --vm=$VMNAME

elif [ "$1" == "stop" ]; then
    bhyvectl --destroy --vm=$VMNAME
else
    usage
fi
################



Dan.


--
Dan The Man
CEO & Founder
Websites, Domains and Everything else
http://www.SunSaturn.com/aboutus.php
Email: Dan@SunSaturn.com
PGP Key: https://SunSaturn.com/pgp.txt
A1A7 6E84 FB0B 8994 C3B5  A1BA FF6F 4997 7311 C386

On Mon, 7 Nov 2022, Alexander Motin wrote:

> On 07.11.2022 18:53, Dan The Man wrote:
>> router:~ # sysctl vfs.zfs.vol.recursive=1
>> vfs.zfs.vol.recursive: 0 -> 1
>> router:~ # zpool import
>>     pool: testing
>>       id: 8013833172609421701
>>    state: ONLINE
>>   action: The pool can be imported using its name or numeric identifier.
>>   config:
>>
>>          testing                   ONLINE
>>            zvol/zroot/asterisk2p3  ONLINE
>> router:~ # zpool import -fR /mnt testing
>> 
>> This hangs forever....
>> The only way to import that pool from the zvol that I know of.....
>
> Mounting ZFS from ZVOLs is blocked for a reason.  It causes deadlocks due to 
> lock recursion.  I don't know what you are trying to achieve, but as 
> alternatives, the ZVOL can be passed inside VM, it can be shared via iSCSI 
> (even inside the host itself), etc.
>
> -- 
> Alexander Motin
>
--1969398039-1231111786-1668090928=:15763--

From nobody Thu Nov 10 20:29:21 2022
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 4N7YN45sD5z4f3Tn
	for ; Thu, 10 Nov 2022 20:29:24 +0000 (UTC)
	(envelope-from l.m.v.breda@xs4all.nl)
Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.168])
	(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 4N7YN35cz7z472L
	for ; Thu, 10 Nov 2022 20:29:23 +0000 (UTC)
	(envelope-from l.m.v.breda@xs4all.nl)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=xs4all.nl header.s=xs4all01 header.b=nYNF4rDd;
	spf=pass (mx1.freebsd.org: domain of l.m.v.breda@xs4all.nl designates 195.121.94.168 as permitted sender) smtp.mailfrom=l.m.v.breda@xs4all.nl;
	dmarc=pass (policy=none) header.from=xs4all.nl
X-KPN-MessageId: 5bcb052c-6136-11ed-be70-005056aba152
Received: from smtp.kpnmail.nl (unknown [10.31.155.39])
	by ewsoutbound.so.kpn.org (Halon) with ESMTPS
	id 5bcb052c-6136-11ed-be70-005056aba152;
	Thu, 10 Nov 2022 21:29:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=xs4all.nl; s=xs4all01;
	h=content-type:mime-version:message-id:date:subject:to:from;
	bh=hLvzq14eRGqMalZMzgzeVfTUic+x/A06d0jyqW3SDNo=;
	b=nYNF4rDd2M5JF5ySCNPCJVaTuy93YHI1W8BrvYu7MIwjfEraJliXnmvA9qFmen31+f7S9tyyalrt2
	 1BIRZmm3ZuQkq6/hAQhh88imrG7M1G9io2agwT1qo0s3qqzyA2jkhohy6skUBxRcvDNL3pqBNltqhi
	 ANmGMPfk64y8vyAKcr3NDbQofkhuYR96Jjtbfhsdgozzi0wqtADgcMI5MoVAgQLOn5gehuW2cGxS04
	 s/mpyWpJCPYAGwl2zjVfeFdtHHHqOJ4RYowSWquRgmPtbmDPIGl2+N9E9rafYfd/BS5jVek0sAEcMJ
	 jPcTq9f8bccAP99Jt/iOZfw4UwPpQOw==
X-KPN-MID: 33|i8xHnBkGlnRgwpRHP9pFI2PjiLw4gyIYUlvT7w6pC4Zo1T7b26Shdy21PKdz20X
 L+E3RcLgR3dAFl+wD4FcygxTBg6PGpaWPW0f7pMvhzjQ=
X-KPN-VerifiedSender: Yes
X-CMASSUN: 33|9Q10nsTbRYH9uKqrPPskvRaPJpWhbYvpmmP/WY6mblqz6Hjirs3GsPhhLrBxU8A
 CaQAYHmuZK6R47VI+NKlmog==
X-Originating-IP: 77.174.182.228
Received: from MAIN (77-174-182-228.fixed.kpn.net [77.174.182.228])
	by smtp.xs4all.nl (Halon) with ESMTPSA
	id 5c1667ff-6136-11ed-b8b1-005056ab7447;
	Thu, 10 Nov 2022 21:29:22 +0100 (CET)
From: 
To: 
References: 
In-Reply-To: 
Subject: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
Date: Thu, 10 Nov 2022 21:29:21 +0100
Message-ID: <001901d8f543$1dab2900$59017b00$@xs4all.nl>
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="----=_NextPart_000_001A_01D8F54B.7F702D40"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: Adj1Qx1rZ9O38UdUT1OJo1zqqNXU+A==
Content-Language: nl
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.47 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.68)[-0.676];
	DMARC_POLICY_ALLOW(-0.50)[xs4all.nl,none];
	FORGED_SENDER(0.30)[louis.freebsd@xs4all.nl,l.m.v.breda@xs4all.nl];
	R_DKIM_ALLOW(-0.20)[xs4all.nl:s=xs4all01];
	R_SPF_ALLOW(-0.20)[+ip4:195.121.94.168/32];
	RCVD_IN_DNSWL_LOW(-0.10)[195.121.94.168:from];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	DWL_DNSWL_NONE(0.00)[xs4all.nl:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	ARC_NA(0.00)[];
	FROM_NO_DN(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	SUBJECT_HAS_QUESTION(0.00)[];
	ASN(0.00)[asn:8737, ipnet:195.121.64.0/18, country:NL];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[xs4all.nl];
	HAS_XOIP(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[louis.freebsd@xs4all.nl,l.m.v.breda@xs4all.nl];
	RCVD_COUNT_THREE(0.00)[3];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	DKIM_TRACE(0.00)[xs4all.nl:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_ENVFROM(0.00)[xs4all.nl];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4N7YN35cz7z472L
X-ThisMailContainsUnwantedMimeParts: N

This is a multipart message in MIME format.

------=_NextPart_000_001A_01D8F54B.7F702D40
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I am still desperately trying to stop FreeBSD from sleeping, but I =
simply do not manage.=20

 =EF=BF=BD

It is really very annoying that I have to restart the machine every 10 =
minutes, when I am working via SSH.

So if any one has a solution, it would be very much appreciated!

 =EF=BF=BD

It should =E2=80=A6.. be possible to kill / stop ACPI some how =
=F0=9F=98=8A

If absolutely not possible in the actual build =F0=9F=98=8A, a cron job =
restarting the timer every 5 minutes perhaps !!???

 =EF=BF=BD

It is possible perhaps =E2=80=A6 that GNOME is initiating this, despite =
that the GUI powersetting is screenblank =E2=80=9CNEVER=E2=80=9D.  =
=EF=BF=BD

Whatever is causing the problem, the settings should be such that ^no =
whatever program^ should not be capable to initiate the sleepmode.=20

 =EF=BF=BD

 =EF=BF=BD

Louis

------------------------

I need to disable acpi and the indicated method for that is to add =
^hint.acpi.0.disabled=3D"1"^ in /boot/loader.conf .

However that crashes my system !!!!!!=20

Not only that, to make it work again I have to edit loader.conf on a =
system which does ^not start^.  =EF=BF=BD

 =EF=BF=BD

After a lot of searching Internet came to the help with, I could start =
the system again:

1. Select 3. Escape to loader prompt at the splash screen

2. Type set hint.acpi.0.disabled=3D"0" on the loader prompt

3. Then type boot on the loader prompt

edit the loader.conf

Very very glad with that fix however

 =EF=BF=BD

However the problem is still there, no idea how to prevent the system =
from going to sleep (after about 10 minutes).

No idea how to change those 10 minutes to a much longer time as well =
....=20

 =EF=BF=BD

Note that I have gnome as gui and use the system more or less as server =
and manage the machine partly local via the GUI and partly remote via =
SSH.

 =EF=BF=BD

Related to GNOME I did try ^gsettings set =
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, =
however that did not solve the problem as well.

 =EF=BF=BD

In the end there seems to two problems

a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! =
! and=20

b) a GNOME issue (switching the system off during user inactivity, which =
is bullshit for a server / for ssh-login / with multiple users).

What IMHO apart from the screen lock, this is not a GNOME task but an OS =
=EF=BF=BD function to be configured by the system administrator.

 =EF=BF=BD

A third problem, not to be addressed here, is that recovery from sleep =
mode does not work on my system as well (even not S1).

 =EF=BF=BD

Most important for the moment is that the system keeps running / is not =
going down after x-time !=20

 =EF=BF=BD

Louis


------=_NextPart_000_001A_01D8F54B.7F702D40
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


I am still =
desperately trying to stop FreeBSD from sleeping, but I simply do not =
manage. 
 
It is really very annoying that I have to restart the =
machine every 10 minutes, when I am working via =
SSH.
So if =
any one has a solution, it would be very much =
appreciated!
 
It should =E2=80=A6.. be possible to kill / stop ACPI some =
how 😊
If absolutely not possible in the actual build 😊, a cron job =
restarting the timer every 5 minutes perhaps =
!!???
 
It is possible perhaps =E2=80=A6 that GNOME is initiating =
this, despite that the GUI powersetting is screenblank =
=E2=80=9CNEVER=E2=80=9D.  
Whatever is causing the problem, =
the settings should be such that ^no whatever program^ should not be =
capable to initiate the sleepmode. 
 
 
Louis
------------------------
I need to disable acpi and the =
indicated method for that is to add =
^hint.acpi.0.disabled=3D"1"^ in /boot/loader.conf =
.
However =
that crashes my system !!!!!! 
Not only that, to make it work =
again I have to edit loader.conf on a system which does ^not start^. =
 
 
After a lot of searching Internet came to the help with, I =
could start the system again:
1. Select 3. Escape to loader =
prompt at the splash screen
2. Type set =
hint.acpi.0.disabled=3D"0" on the loader =
prompt
3. =
Then type boot on the loader prompt
edit the =
loader.conf
Very very glad with that fix =
however
 
However the problem is still there, no idea how to prevent =
the system from going to sleep (after about 10 =
minutes).
No idea how to change those 10 minutes to a much longer =
time as well .... 
 
Note that I have gnome as gui and use the system more or =
less as server and manage the machine partly local via the GUI and =
partly remote via SSH.
 
Related to GNOME I did try ^gsettings set =
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, =
however that did not solve the problem as well.
 
In the end there seems to two =
problems
a) =
A BSD-issue ACPI-turn off in the bootloader is crashing the system ! ! =
and 
b) a =
GNOME issue (switching the system off during user inactivity, which is =
bullshit for a server / for ssh-login / with multiple =
users).
What IMHO apart from the screen lock, this is not a GNOME =
task but an OS  function to be configured by the system =
administrator.
 
A third problem, not to be addressed here, is that recovery =
from sleep mode does not work on my system as well (even not =
S1).
 
Most important for the moment is that the system keeps =
running / is not going down after x-time ! 
 
Louis

------=_NextPart_000_001A_01D8F54B.7F702D40--


From nobody Thu Nov 10 22:47:03 2022
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 4N7cR20tvnz4dFPS
	for ; Thu, 10 Nov 2022 22:47:10 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N7cR15J0gz4R3F
	for ; Thu, 10 Nov 2022 22:47:09 +0000 (UTC)
	(envelope-from hps@selasky.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: from [10.36.2.69] (unknown [178.232.52.78])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 6A7032605C4;
	Thu, 10 Nov 2022 23:47:07 +0100 (CET)
Message-ID: <84694be2-b7a0-4684-77b5-4e69cede2763@selasky.org>
Date: Thu, 10 Nov 2022 23:47:03 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on
 FreeBSD14 CURRENT)
To: louis.freebsd@xs4all.nl, freebsd-current@FreeBSD.org
References: <001901d8f543$1dab2900$59017b00$@xs4all.nl>
Content-Language: en-US
From: Hans Petter Selasky 
In-Reply-To: <001901d8f543$1dab2900$59017b00$@xs4all.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4N7cR15J0gz4R3F
X-Spamd-Bar: ----
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:24940, ipnet:2a01:4f8::/32, country:DE]
X-ThisMailContainsUnwantedMimeParts: N

Hi,

I don't know what you mean by "sleep", but some CPUs have bug and setting:

sysctl machdep.idle=spin

Helps!

--HPS

From nobody Fri Nov 11 02:52:00 2022
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 4N7jsh6D1sz4fl7n
	for ; Fri, 11 Nov 2022 02:52:08 +0000 (UTC)
	(envelope-from zlei.huang@gmail.com)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N7jsh2dtfz3h37
	for ; Fri, 11 Nov 2022 02:52:08 +0000 (UTC)
	(envelope-from zlei.huang@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pl1-x62e.google.com with SMTP id k7so3179779pll.6
        for ; Thu, 10 Nov 2022 18:52:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
         :from:from:to:cc:subject:date:message-id:reply-to;
        bh=tda2NTayZM1RRj6fUB7wzMaWzWAzP7+9sGz2tt5711A=;
        b=HQd4hPf+At/A5x361yqI9piNVrQjr0LXbxWMv8MqyqqD7rQspbMzRATKXMkyucPH/d
         IHEP4WhFacYQG79clRtFsvEiOic6Y4g9V8LEWLmGBB6XpM4EvtkJEatjAP68mUCb8WgX
         4fqbTPcoMe5HXe/PdE8fUVzVJD/ZI8k+9TZPawGLKyHSdDF1e9TQv0LDzN/ZAcZ7DY0Y
         EJLdvjrhcn7W2R64UZlES+yxRnRivzLpobvIr2FpU+AHwN50CgNT3mKKXGE5tOIuvl5f
         kbwM394DHJcheLTjEHiZavbfmTcxXbVi/ZUUZ0TU838Pq5azPt+qSyvwtMF81MI6oKI5
         qylQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
         :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=tda2NTayZM1RRj6fUB7wzMaWzWAzP7+9sGz2tt5711A=;
        b=6RzPyx6DpTvrYAx2zvQHoFnHxTxiU7PgxOS1KN7Bqu3yLA3ovKvuXbjD9guFV7c6mY
         XEFUK/tPIcdw3s0PgYNJqlO1/k/kjD+2cPGe+TbBRGEY0ewPAfIoi7OrY1Vz75uepUPt
         Pa8Wziq6YHoYdRzWgqzLIK6OGydrhvKFtWM5VtAoKxEUO5ZwAo/9L48aMtTed8xIG/Yo
         5B1q2cDGVOrPeLV1C6oMD41nxPXeSvQq2YT81ckRSHtbyWw/8r8dI/3YmH5DK34Hkhzl
         wylWNirhHthVVDCRrcF4kBSzIDUCAeXJGDhKNOBTkAnUKXdF+duBWhcyFhvTAV7xNOeB
         AbNg==
X-Gm-Message-State: ACrzQf25dUGSBRRdEcH3khMDALzZ1revwDVlNDyUpAPUSWA6F1QxK8Yu
	MnvynetUEUmw58P7grMuYO3jRrdTCQKdYA==
X-Google-Smtp-Source: AMsMyM71dsQfFw70N/Tz6RCYbN25EbvrZ70AHzuY8kZ/LNnQjiNo4RbY82NfNrFtZxoD5O8U7l+jCQ==
X-Received: by 2002:a17:90a:ca03:b0:212:e2e9:a522 with SMTP id x3-20020a17090aca0300b00212e2e9a522mr3164512pjt.55.1668135127019;
        Thu, 10 Nov 2022 18:52:07 -0800 (PST)
Received: from [172.17.252.129] (ns1.oxydns.net. [45.32.91.63])
        by smtp.gmail.com with ESMTPSA id mi3-20020a17090b4b4300b0020d3662cc77sm3741999pjb.48.2022.11.10.18.52.05
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 10 Nov 2022 18:52:06 -0800 (PST)
From: Zhenlei Huang 
Message-Id: <56341E2C-8856-40FB-AC4E-00DB4E116F19@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F7DEA399-0E0A-4AAE-8A54-546A4EBA34F3"
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 13.4 \(3608.120.23.2.7\))
Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on
 FreeBSD14 CURRENT)
Date: Fri, 11 Nov 2022 10:52:00 +0800
In-Reply-To: <001901d8f543$1dab2900$59017b00$@xs4all.nl>
Cc: "" 
To: louis.freebsd@xs4all.nl
References: <001901d8f543$1dab2900$59017b00$@xs4all.nl>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-Rspamd-Queue-Id: 4N7jsh2dtfz3h37
X-Spamd-Bar: ----
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:2607:f8b0::/32, country:US]
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_F7DEA399-0E0A-4AAE-8A54-546A4EBA34F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Nov 11, 2022, at 4:29 AM,  =
 wrote:
>=20
> I am still desperately trying to stop FreeBSD from sleeping, but I =
simply do not manage.=20
> =20
> It is really very annoying that I have to restart the machine every 10 =
minutes, when I am working via SSH.

I think you will need to find the event triggering sleep (ACPI s1 / s3) =
every 10 minutes.

> So if any one has a solution, it would be very much appreciated!
> =20
> It should =E2=80=A6.. be possible to kill / stop ACPI some how =F0=9F=98=
=8A
> If absolutely not possible in the actual build =F0=9F=98=8A, a cron =
job restarting the timer every 5 minutes perhaps !!???
> =20
> It is possible perhaps =E2=80=A6 that GNOME is initiating this, =
despite that the GUI powersetting is screenblank =E2=80=9CNEVER=E2=80=9D. =
=20

Probably. (or some other components of the GNOME)

I've dozens of VMs / baremetal machines used as servers and routers. =
None of them sleep (without explicitly means such as acpiconf).
I've not use FreeBSD as desktop since about ten year ago.

> Whatever is causing the problem, the settings should be such that ^no =
whatever program^ should not be capable to initiate the sleepmode.=20
> =20
> =20
> Louis
> ------------------------
> I need to disable acpi and the indicated method for that is to add =
^hint.acpi.0.disabled=3D"1"^ in /boot/loader.conf .
> However that crashes my system !!!!!!=20
> Not only that, to make it work again I have to edit loader.conf on a =
system which does ^not start^. =20
> =20
> After a lot of searching Internet came to the help with, I could start =
the system again:
> 1. Select 3. Escape to loader prompt at the splash screen
> 2. Type set hint.acpi.0.disabled=3D"0" on the loader prompt
> 3. Then type boot on the loader prompt
> edit the loader.conf
> Very very glad with that fix however
> =20
> However the problem is still there, no idea how to prevent the system =
from going to sleep (after about 10 minutes).
> No idea how to change those 10 minutes to a much longer time as well =
....=20
> =20
> Note that I have gnome as gui and use the system more or less as =
server and manage the machine partly local via the GUI and partly remote =
via SSH.

I think you can disable GUI / GNOME completely and try again.

> =20
> Related to GNOME I did try ^gsettings set =
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, =
however that did not solve the problem as well.
> =20
> In the end there seems to two problems
> a) A BSD-issue ACPI-turn off in the bootloader is crashing the system =
! ! and=20
> b) a GNOME issue (switching the system off during user inactivity, =
which is bullshit for a server / for ssh-login / with multiple users).
> What IMHO apart from the screen lock, this is not a GNOME task but an =
OS  function to be configured by the system administrator.
> =20
> A third problem, not to be addressed here, is that recovery from sleep =
mode does not work on my system as well (even not S1).
> =20
> Most important for the moment is that the system keeps running / is =
not going down after x-time !=20
> =20
> Louis

Best regards,
Zhenlei


--Apple-Mail=_F7DEA399-0E0A-4AAE-8A54-546A4EBA34F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Nov 11, 2022, at 4:29 AM, <louis.freebsd@xs4all.nl> <louis.freebsd@xs4all.nl> wrote:

I am still desperately trying to stop FreeBSD from sleeping, =
but I simply do not manage. 
 
It is really very annoying that I have to =
restart the machine every 10 minutes, when I am working via =
SSH.

I=
 think you will need to find the event triggering sleep (ACPI s1 / s3) =
every 10 minutes.

So if any one has a solution, it would be very much =
appreciated!
 
It should =E2=80=A6=
.. be possible to kill / stop ACPI some how =F0=9F=98=8A
If absolutely not possible in the actual build =F0=9F=98=8A, a cron =
job restarting the timer every 5 minutes perhaps !!???
 
It is possible perhaps =E2=80=A6 that GNOME is =
initiating this, despite that the GUI powersetting is screenblank =
=E2=80=9CNEVER=E2=80=9D. =
 

Probably. (or some other components of the =
GNOME)

I've =
dozens of VMs / baremetal machines used as servers and routers. None of =
them sleep (without explicitly means such as =
acpiconf).
I've not use FreeBSD as desktop since =
about ten year ago.

Whatever is causing the problem, the settings should be such =
that ^no whatever program^ should not be capable to initiate the =
sleepmode. 
 
 
Louis
------------------------
I need to =
disable acpi and the indicated method for that is to add =
^hint.acpi.0.disabled=3D"1"^ in /boot/loader.conf .
However that crashes my system !!!!!! 
Not only that, to make it work again I have to edit =
loader.conf on a system which does ^not start^.  
 
After a lot of searching Internet came to the =
help with, I could start the system again:
1. Select 3. Escape to loader prompt at the splash screen
2. Type set hint.acpi.0.disabled=3D"0" on the loader =
prompt
3. Then type boot on the loader prompt
edit the loader.conf
Very very glad =
with that fix however
 
However the problem is still there, no idea =
how to prevent the system from going to sleep (after about 10 =
minutes).
No idea how to change those 10 minutes to a =
much longer time as well .... 
 
Note that I have gnome as gui and use the =
system more or less as server and manage the machine partly local via =
the GUI and partly remote via =
SSH.

I=
 think you can disable GUI / GNOME completely and try =
again.

 
Related to GNOME I did try ^gsettings set =
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, =
however that did not solve the problem as well.
 
In the end there seems to two problems
a) A BSD-issue ACPI-turn off in the bootloader is crashing =
the system ! ! and 
b) a GNOME issue (switching the system off during user =
inactivity, which is bullshit for a server / for ssh-login / with =
multiple users).
What IMHO apart from the screen lock, this is =
not a GNOME task but an OS  function to be configured by the system =
administrator.
 
A third problem, =
not to be addressed here, is that recovery from sleep mode does not work =
on my system as well (even not =
S1).
 
Most important for the moment is that the =
system keeps running / is not going down after x-time ! 
 
Louis

Best regards,
Zhenlei

=

--Apple-Mail=_F7DEA399-0E0A-4AAE-8A54-546A4EBA34F3--

From nobody Fri Nov 11 03:21:24 2022
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 4N7kWV38Sfz4frBf
	for ; Fri, 11 Nov 2022 03:21:26 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N7kWV1B7lz3kkd
	for ; Fri, 11 Nov 2022 03:21:26 +0000 (UTC)
	(envelope-from mavbsd@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-qt1-x831.google.com with SMTP id jr19so2125648qtb.7
        for ; Thu, 10 Nov 2022 19:21:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=WNVegz/V5+AY1Selbl6H2oQc8p3kADpGWcxKtOfykZ8=;
        b=DSgNTxl1jRBC5wNGii/xnyiec1Y74mjUSkQ+NY0UmXVq6JGC90noDDvxh7XbSK+6Kx
         YFU1edht0lUtPukuqg1LhSIIwsgMrw093ttXwM6CUa2YNuBTycEry7Equ/XeNe6vuJlC
         jleU+PvpCan1bHWqTeQb4sIn/cWV0sbkXJkGRvPbP3KWGH5BqG1EmERu/JMdetE8baXg
         Pn7JsrwcdECMwCk70E7j7vt/ytSu2md/K3w6goT+HE6oj6VZWDP4N11IUiIBm/PfUEie
         vgOvjYQ1LADFEEoO627Qhdd3zNbRA6QNzMla0gOPdFD+1QpVo6Pvh52jqRZj5ng0Tg/x
         Pcug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :sender:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=WNVegz/V5+AY1Selbl6H2oQc8p3kADpGWcxKtOfykZ8=;
        b=hD1UUNF5V6BjOqtgkWU+NZEG1TIHxN9EzPtCTfr7BYPGaiB7pu43RiZiequKKsk4N3
         xLSJd1vlwKFy+A7F+W6AdX9LRjpA2WG3nVU3PBRfKb5y/PhzMUxgit0nrfzhJ1AnBn6W
         mTQ33skiay+8KDeDRiwfELRjbZ5vqxdB58TE3eRZ36j9b3zCSKMWCCrl/xD/ez3EvflQ
         +EAtqt4NCUtkrSODB1hvbwTheCW7YsdjZ/hVav6nzUY5dBWDWBonDom3mRkU0MyNE7fV
         N+Dk8cjYeQinT0mpUgQwGbfJMrXBacsGp2oingr9+/zHi2SlS3dsbXd3gd7T5PKNSPSt
         nE7g==
X-Gm-Message-State: ACrzQf0vM9gt/CrDhHwAz9zeuehgjUatTB4Ybj7yzDIc+3b6wFkU9T/C
	FQ3aIVdSmHZz/NdmrEK0emSjJycQgpI=
X-Google-Smtp-Source: AMsMyM6rRfK00ZpCUDyr8H5jK0Nxx91JbdqETr6pmNw9N+BDSL7mv81waHCriqiWZrY0UadLTNH3Uw==
X-Received: by 2002:a05:622a:410f:b0:3a4:f053:6f0 with SMTP id cc15-20020a05622a410f00b003a4f05306f0mr2823570qtb.441.1668136885399;
        Thu, 10 Nov 2022 19:21:25 -0800 (PST)
Received: from [192.168.1.66] (104-55-12-234.lightspeed.knvltn.sbcglobal.net. [104.55.12.234])
        by smtp.gmail.com with ESMTPSA id g19-20020ac84b73000000b003a50c9993e1sm623927qts.16.2022.11.10.19.21.24
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 10 Nov 2022 19:21:25 -0800 (PST)
Message-ID: <01051bc5-07fd-95c5-1309-6358a8f971e5@FreeBSD.org>
Date: Thu, 10 Nov 2022 22:21:24 -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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on
 FreeBSD14 CURRENT)
Content-Language: en-US
To: louis.freebsd@xs4all.nl, freebsd-current@FreeBSD.org
References: <001901d8f543$1dab2900$59017b00$@xs4all.nl>
From: Alexander Motin 
In-Reply-To: <001901d8f543$1dab2900$59017b00$@xs4all.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4N7kWV1B7lz3kkd
X-Spamd-Bar: ----
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-ThisMailContainsUnwantedMimeParts: N

On 10.11.2022 15:29, louis.freebsd@xs4all.nl wrote:
> I am still desperately trying to stop FreeBSD from sleeping, but I 
> simply do not manage.
> 
> It is really very annoying that I have to restart the machine every 10 
> minutes, when I am working via SSH.
> 
> So if any one has a solution, it would be very much appreciated!
> 
> It should ….. be possible to kill / stop ACPI some how 😊
> 
> If absolutely not possible in the actual build 😊, a cron job restarting 
> the timer every 5 minutes perhaps !!???

I've never used it, so just an idea, but there is sysctl 
kern.suspend_blocked that being set to 1 seems should block suspend 
requests.  You may try to set it and see what happen.

> It is possible perhaps … that GNOME is initiating this, despite that the 
> GUI powersetting is screenblank “NEVERâ€.

It is not a screen blank.  Gnome site tells: 
https://help.gnome.org/users/gnome-help/stable/power-autosuspend.html.en

> Whatever is causing the problem, the settings should be such that ^no 
> whatever program^ should not be capable to initiate the sleepmode.

Does the system suspends if you do not start Gnome?  For example if you 
boot into single-user mode and leave the system there?  It would be the 
easiest test probably.

-- 
Alexander Motin

From nobody Fri Nov 11 03:36:49 2022
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 4N7ksW3gKbz4d9Kj
	for ; Fri, 11 Nov 2022 03:37:03 +0000 (UTC)
	(envelope-from sr@genyosha.net)
Received: from ns4.genyosha.net (ns4.genyosha.net [50.53.250.75])
	(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 "float.home.genyosha.net", Issuer "float.home.genyosha.net" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N7ksV4yl6z3mkg
	for ; Fri, 11 Nov 2022 03:37:02 +0000 (UTC)
	(envelope-from sr@genyosha.net)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of sr@genyosha.net designates 50.53.250.75 as permitted sender) smtp.mailfrom=sr@genyosha.net;
	dmarc=none
Received: from dragon.home.genyosha.net (ops.genyosha.net [50.53.250.77])
	by ns4.genyosha.net (8.16.1/8.16.1) with ESMTPS id 2AB3asS6031438
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Thu, 10 Nov 2022 19:36:54 -0800 (PST)
	(envelope-from sr@genyosha.net)
Received: from dragon.home.genyosha.net (localhost [127.0.0.1])
	by dragon.home.genyosha.net (8.14.7/8.14.7) with ESMTP id 2AB3anf6015819;
	Thu, 10 Nov 2022 19:36:49 -0800
Received: (from sr@localhost)
	by dragon.home.genyosha.net (8.14.7/8.14.7/Submit) id 2AB3anw5015818;
	Thu, 10 Nov 2022 19:36:49 -0800
Date: Thu, 10 Nov 2022 19:36:49 -0800
From: Steve Rikli 
To: freebsd-current@FreeBSD.org
Cc: louis.freebsd@xs4all.nl
Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on
 FreeBSD14 CURRENT)
Message-ID: 
References: <001901d8f543$1dab2900$59017b00$@xs4all.nl>
 <01051bc5-07fd-95c5-1309-6358a8f971e5@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=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <01051bc5-07fd-95c5-1309-6358a8f971e5@FreeBSD.org>
X-Greylist: inspected by milter-greylist-4.6.4 (ns4.genyosha.net [50.53.250.75]); Thu, 10 Nov 2022 19:36:55 -0800 (PST) for IP:'50.53.250.77' DOMAIN:'ops.genyosha.net' HELO:'dragon.home.genyosha.net' FROM:'sr@genyosha.net' RCPT:''
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (ns4.genyosha.net [50.53.250.75]); Thu, 10 Nov 2022 19:36:55 -0800 (PST)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:20055, ipnet:50.53.0.0/16, country:US];
	R_DKIM_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEMAIL_CC(0.00)[xs4all.nl];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	DMARC_NA(0.00)[genyosha.net];
	SUBJECT_HAS_QUESTION(0.00)[]
X-Rspamd-Queue-Id: 4N7ksV4yl6z3mkg
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Nov 10, 2022 at 10:21:24PM -0500, Alexander Motin wrote:
> On 10.11.2022 15:29, louis.freebsd@xs4all.nl wrote:
> > I am still desperately trying to stop FreeBSD from sleeping, but I
> > simply do not manage.
> > 
> > It is really very annoying that I have to restart the machine every 10
> > minutes, when I am working via SSH.
> > 
> > So if any one has a solution, it would be very much appreciated!
> > 
> > It should ….. be possible to kill / stop ACPI some how 😊
> > 
> > If absolutely not possible in the actual build 😊, a cron job restarting
> > the timer every 5 minutes perhaps !!???
> 
> I've never used it, so just an idea, but there is sysctl
> kern.suspend_blocked that being set to 1 seems should block suspend
> requests.  You may try to set it and see what happen.
> 
> > It is possible perhaps … that GNOME is initiating this, despite that the
> > GUI powersetting is screenblank “NEVERâ€.
> 
> It is not a screen blank.  Gnome site tells:
> https://help.gnome.org/users/gnome-help/stable/power-autosuspend.html.en
> 
> > Whatever is causing the problem, the settings should be such that ^no
> > whatever program^ should not be capable to initiate the sleepmode.
> 
> Does the system suspends if you do not start Gnome?  For example if you boot
> into single-user mode and leave the system there?  It would be the easiest
> test probably.

This sounds somewhat like the Gnome gdm3 behavior that causes some(?)
Linuxes to suspend & sleep after 20 minutes (ymmv?) by default if gdm3
is running. E.g.

https://wiki.debian.org/Suspend

IME it didn't matter if user was logged in to desktop or not, the mere
presence of a running gdm3 process was enough to trigger the behavior
unless it was disabled. My FreeBSD's without gdm3 don't see this.

Obviously there's no Linux systemD in-play here, but along the lines
Alexander suggests, you might try stopping any running gdm3 processes
and see if the sleep behavior persists. That would at least give some
hint as to the vicinity of the problem.

sr.

From nobody Sat Nov 12 08:10:35 2022
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 4N8SvQ3cmzz4g32B
	for ; Sat, 12 Nov 2022 08:11:14 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N8SvP37SSz3DDW;
	Sat, 12 Nov 2022 08:11:13 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=hFvbWOML;
	spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net;
	dmarc=pass (policy=quarantine) header.from=leidinger.net
Received: from outgoing.leidinger.net (p508d4280.dip0.t-ipconnect.de [80.141.66.128])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id 37A95A3C;
	Sat, 12 Nov 2022 09:10:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668240658;
	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=VvGRWX1vKSXQqbIeHUnVUiNkqjEqcnnvvufzgBvzf2Q=;
	b=hFvbWOMLuMQ/kiuOJExFkXpe6+bVmA8V6On/XCQnRkxP0kfGCSqyvx7aV3+Kk0BPWbPgWB
	cbr6nHjqX/7zRRlgO52+Ab/jypOM/AWtRckAw7egyHBuniTcYc/M7R2hTSA4+dwDtr4j9e
	C76Vh00ZVg/mD6mvxbcQFQYaNhMAyNvKQH71jm+CdZtmDPjJaLdF4IoE/zUBqd4HP+DZ6E
	2OGvEDAs5x62vU6mPqRcYfUiKYBw1BJCKkreZJeaBeU89oO+58fZBgGRsu/SVwbK3Mt5pi
	3a8nx5V5ufS7u0d2QOu90weLn2FKPfNCcjy6p4ATeTsGsiKSrX3/wGQy/Kg5tw==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id A6A3C6398;
	Sat, 12 Nov 2022 09:10:36 +0100 (CET)
Date: Sat, 12 Nov 2022 09:10:35 +0100
Message-ID: <20221112091035.Horde.S6Ainwo5Vov9bxEzOc-OBp-@webmail.leidinger.net>
From: Alexander Leidinger 
To: Warner Losh 
Cc: marklmi@yahoo.com, tsoome@freebsd.org, Li-Wen Hsu ,
        current@freebsd.org
Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main -
 rc(8): Add a zpoolupgrade rc.d script)
References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org>
 <20221107121514.Horde.nulS9Wg1s3yzAsXXkuJRBa9@webmail.leidinger.net>
 
 <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net>
 <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net>
 
In-Reply-To: 
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_jzBIpF1ILYUWc_qNVNX7OHN";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Spamd-Bar: -----
X-Spamd-Result: default: False [-6.00 / 15.00];
	SIGNED_PGP(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine];
	R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex];
	MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_UNKNOWN(0.10)[application/x-sh];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	FREEMAIL_CC(0.00)[yahoo.com,freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	DKIM_TRACE(0.00)[leidinger.net:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	HAS_ATTACHMENT(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-Rspamd-Queue-Id: 4N8SvP37SSz3DDW
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_jzBIpF1ILYUWc_qNVNX7OHN
Content-Type: multipart/mixed; boundary="=_UzBLOkrCuK6M6ceKx8dmdaa"

This message is in MIME format.

--=_UzBLOkrCuK6M6ceKx8dmdaa
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Warner Losh  (from Wed, 9 Nov 2022 08:54:33 -0700):

> On Wed, Nov 9, 2022 at 5:46 AM Alexander Leidinger 
> wrote:

> While most of these options look OK on the surface, I'd feel a lot better
> if there were tests for these to prove they work. I'd also feel better if
> the ZFS experts could explain how those come to be set on a zpool
> as well. I'd settle for a good script that could be run as root (better

It is explained in the zpool-features man page.

> would be not as root) that would take a filesystem that was created
> by makefs -t zfs and turn on these features after an zpool upgrade.

Script attached. Maybe a little bit too verbose, but you can see which=20=
=20
features=20are active directly, and which ones only enabled.

It expects a zroot.img in the current directory and creates copies to=20=20
zroot_num_featurename.img=20where it enables the features. In the=20=20
beginning=20are some variables to adapt to pool/image name and=20=20
destination=20directory.

Bye,
Alexander.
--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_UzBLOkrCuK6M6ceKx8dmdaa
Content-Type: application/x-sh; name=zpool_features.sh
Content-Disposition: attachment; size=1956; filename=zpool_features.sh
Content-Transfer-Encoding: base64

IyEvYmluL3NoCgppZiBbICQod2hvYW1pKSAhPSByb290IF07IHRoZW4KCWVjaG8genBvb2wgaW1w
b3J0IG5lZWRzIHJvb3QgcGVybWlzc2lvbnMsIGFib3J0aW5nCglleGl0IDEKZmkKCQpzb3VyY2Vu
YW1lPXpyb290CnNvdXJjZWV4dD1pbWcKc291cmNlaW1nPSR7c291cmNlbmFtZX0uJHtzb3VyY2Vl
eHR9CnBvb2xuYW1lPXRlc3Ryb290Cm1kZXZpY2U9bWQ5CmRlc3RwYXRoPS4KCmNvdW50PTAKIyBz
b3J0IG9yZGVyIG9mIGZlYXR1cmVzOiBhcyBpbiBtYW4tcGFnZSwKIyBidXQgZGVwZW5kZW5jaWVz
IGxpZnRlZCB0byBiZWZvcmUgZmlyc3QgdXNlIGluIGRlcGVuZGVuY3kKIyBuZXcgaW4gMTQ6IGJs
YWtlMywgaGVhZF9lcnJsb2csIHppbHNheGF0dHIKZm9yIGZlYXR1cmUgaW4gYWxsb2NhdGlvbl9j
bGFzc2VzIFwKCQlhc3luY19kZXN0cm95IFwKCQlleHRlbnNpYmxlX2RhdGFzZXQgXAoJCWV4dGVu
c2libGVfZGF0YXNldCxibGFrZTMgXAoJCWV4dGVuc2libGVfZGF0YXNldCxib29rbWFya3MgXAoJ
CWV4dGVuc2libGVfZGF0YXNldCxib29rbWFya3MsYm9va21hcmtfdjIgXAoJCWV4dGVuc2libGVf
ZGF0YXNldCxib29rbWFya3MsYm9va21hcmtfdjIsYm9va21hcmtfd3JpdHRlbiBcCgkJZGV2aWNl
X3JlYnVpbGQgXAoJCWRldmljZV9yZW1vdmFsIFwKCQlkcmFpZCBcCgkJZXh0ZW5zaWJsZV9kYXRh
c2V0LGVkb25yIFwKCQllbWJlZGRlZF9kYXRhIFwKCQllbXB0eV9icG9iaiBcCgkJZW5hYmxlZF90
eGcgXAoJCWV4dGVuc2libGVfZGF0YXNldCxib29rbWFya3MsYm9va21hcmtfdjIsZW5jcnlwdGlv
biBcCgkJZXh0ZW5zaWJsZV9kYXRhc2V0LGZpbGVzeXN0ZW1fbGltaXRzIFwKCQloZWFkX2Vycmxv
ZyBcCgkJZW5hYmxlZF90eGcsaG9sZV9iaXJ0aCBcCgkJZXh0ZW5zaWJsZV9kYXRhc2V0LGxhcmdl
X2Jsb2NrcyBcCgkJZXh0ZW5zaWJsZV9kYXRhc2V0LGxhcmdlX2Rub2RlIFwKCQlsaXZlbGlzdCBc
CgkJc3BhY2VtYXBfdjIgXAoJCXNwYWNlbWFwX3YyLGxvZ19zcGFjZW1hcCBcCgkJbHo0X2NvbXBy
ZXNzIFwKCQltdWx0aV92ZGV2X2NyYXNoX2R1bXAgXAoJCWRldmljZV9yZW1vdmFsLG9ic29sZXRl
X2NvdW50cyBcCgkJZXh0ZW5zaWJsZV9kYXRhc2V0LHByb2plY3RfcXVvdGEgXAoJCWV4dGVuc2li
bGVfZGF0YXNldCxib29rbWFya3MscmVkYWN0aW9uX2Jvb2ttYXJrcyBcCgkJZXh0ZW5zaWJsZV9k
YXRhc2V0LHJlZGFjdGVkX2RhdGFzZXRzIFwKCQlyZXNpbHZlcl9kZWZlciBcCgkJZXh0ZW5zaWJs
ZV9kYXRhc2V0LHNoYTUxMiBcCgkJZXh0ZW5zaWJsZV9kYXRhc2V0LHNrZWluIFwKCQlzcGFjZW1h
cF9oaXN0b2dyYW0gXAoJCWV4dGVuc2libGVfZGF0YXNldCx1c2Vyb2JqX2FjY291bnRpbmcgXAoJ
CWV4dGVuc2libGVfZGF0YXNldCx6aWxzYXhhdHRyIFwKCQl6cG9vbF9jaGVja3BvaW50IFwKCQll
eHRlbnNpYmxlX2RhdGFzZXQsenN0ZF9jb21wcmVzczsgZG8KCWNvdW50MD0kKHByaW50ZiAiJTAz
ZCIgJGNvdW50KQoJCglkZXN0aW1nPSR7ZGVzdHBhdGh9LyR7c291cmNlbmFtZX1fJHtjb3VudDB9
XyR7ZmVhdHVyZX0uJHtzb3VyY2VleHR9CgllY2hvICR7ZGVzdGltZ30KCgljcCAtdiAke3NvdXJj
ZWltZ30gJHtkZXN0aW1nfQoJbWRjb25maWcgLXUgJHttZGV2aWNlfSAke2Rlc3RpbWd9IHx8IGV4
aXQgMQoJenBvb2wgaW1wb3J0ICAtZCAvZGV2LyR7bWRldmljZX0gLVIgL3RtcC8ke3Bvb2xuYW1l
fSAke3Bvb2xuYW1lfQoJZm9yIGZlYXQgaW4gJChlY2hvICR7ZmVhdHVyZX0gfCBzZWQgLWUgJ3M6
LDogOmcnKTsgZG8KCQl6cG9vbCBzZXQgZmVhdHVyZUAke2ZlYXR9PWVuYWJsZWQgJHtwb29sbmFt
ZX0KCQl6cG9vbCBnZXQgZmVhdHVyZUAke2ZlYXR9ICR7cG9vbG5hbWV9Cglkb25lCgl6cG9vbCBl
eHBvcnQgJHtwb29sbmFtZX0KCW1kY29uZmlnIC1kdSAke21kZXZpY2V9CgkKCWNvdW50PSQoKCR7
Y291bnR9ICsgMSkpCmRvbmUK
--=_UzBLOkrCuK6M6ceKx8dmdaa--

--=_jzBIpF1ILYUWc_qNVNX7OHN
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmNvVPoACgkQEg2wmwP4
2IakYxAAjvny3MUhq13bNLzJ8utxpFADbSRs91Ee1Np9iEtfBN5tFoJWLLihjjV5
m985o1awU/f3WDdqS/g3sXWmP++1PbBsIZ39BEyGQkPqhh0IFsgH7PifVO6qTYEM
TWxEskGiYD/sZj0jQZEarkS9oY6WMFit/ycWW3lrAhrsIMIO/RCG/jaZMfXRG9jX
sVIC1oa4y/mZTLtiWHjKLclHYOWj7trG02T8F0H1Vzh36OyMWnfDwL3eBGDrSnN2
kcHMIX8W2mW5Cx7zboC4Ph7PhsdmNJxQOBxn03Lvv20rf3eNvwdKKEmByDQ+TGUf
luC/KxB/U8YG/g+wwsEcjErEPvXnp7YgUVpwvQQkFb9cHtG6vXSXW1Pg0Pq7Kb9c
Mw1pwN9JGqOR8IEy3VNqADgjFlHmk3cAJ233yAYIjfxT5zeAZNBaGJ9NOu/o1H8k
EKuEbbl4U6n5XrMw1J3ZY0IBgSQEoutwIb+C5nzsUWpzGgJM+O//8lpXhBQhX7jD
XmCMZPgdUGQOryn/rhd6obf2VJ/TTeN0EcZY4U7A9DGWp1KAuxqSygBhcBelXcrD
116t/2TjTOceIVzvLnCyIQQHLP2bN8awV7lGE68aR8B05j59bbNLmgPauoqwk398
RJb33Led7THT6lK61RHq6Bvu+JBN+gs0kn32Vxyy4zGfzwSGi1E=
=ts8o
-----END PGP SIGNATURE-----

--=_jzBIpF1ILYUWc_qNVNX7OHN--

From nobody Sun Nov 13 04:14:50 2022
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 4N8zcY3Bnpz4hLtD
	for ; Sun, 13 Nov 2022 04:15:09 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N8zcX2b32z4Znr
	for ; Sun, 13 Nov 2022 04:15:08 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=RQzZR6n4;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668312905; bh=rKVMGSgaEjPznRzP6SL+u2j5tXmIWP5HtYaLUDq/CE4=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=RQzZR6n4BBmNGfW/SMxhrFJf5pCXQCwWu8RSjbP0YPitaH4+Zi18d9IRXwaczvYqZdAjU39ExEkBoLn4UI1c7FgsDhO3c0+vjFacltOeT/Luj0lAb65UZDalih8dq52I2kTsGw2TGMwTdRu6kj2RClE967KOXf+kqkT8m/VU8oG5GaiFN6FFCXbD5++5k7ekZIhsHzJNT8As0j+aqRr5DRdI6gnvTxRGHCNl1dLzvnfLcmIz5NKr2yvZ+7HvYUaH6Z4SjaZ/gfi1ev1BvMjWqkBakCMNN0iJtvjkmNlWh7J8cDxTVHQu74SocYVvkEsLvjqNYw4rcqfFwE44zIvZNw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668312905; bh=LiM50tQcWMuEeZwhSiPyRWYScT0JTuwjezneajdJi0c=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Qnw9LU1sZ3p3BgZ/GX/DDequRwf+98mMF26tjfLb0d1mycXlqSxG/fxk6wlHaTQAc6r0MFNrYWxgtdDmcjxGeJgosRoIdtVgzD/xvYFF7Pm7cam7XOb7/1YxqXdVmm6Aykd4OJkIOkgVEpVU9eFDdnsLdqLH8rTVTaP0Y892Rtm7XIYsfkRmlT33NiTCNuzdIbqnGRKvW9d/bG8o11g+uORhITJq6qOwtKIeYWo0Mb3aQSXhpQcWwI6gWWHqZzxTed7b7ozE43sv2IEnPGrpTlvAbTl1EMwVFDGJ1SLEWc6ztahGhRrQuBK6M06kw4+qoFP9hJAiFoiFi7Yd4YNdRQ==
X-YMail-OSG: Pep950wVM1mR5LqpGrb92yT8Ti.lvesOV_fn.Hhb2_5H0saA1DwKs9UVapsJEt8
 bjDx4WpiDEOa19FGllDQRE_Dam5m7ZgvEqH9mJPJOY4mW9DLsjJY5g._yrIX5TxtzUC0DBBK5eH4
 FI3WNQLvRvtJ_Kg4z8nAlaXXeoQ4F2UIZqUldIl04bfaWD.c1fGwlxjgMC_vqwYXg8yRQ9qq5V0c
 EEpIWCUuHlOR43T2RzeCQfI3Qp4qseUzU3pxrUSoDDteug3B1k2NZJjUmUeaHHl7z.5i01amloAz
 ldvYMHXU11OJAJIXYeRMgPeuSd90Sk_dcw7l7NL.nrXx2exCHDDmy7bQkABAg4cxqilaP5h1yYp4
 6.gIz1sx4jRKhlD6kRScnmEcNVO6iNNmb9QaqxeYNuGTeBXjSdAXPTgyBGHikPmJ8xhUrSlOARx0
 04EVEbAOJF9FlapnSgKOW.FHD5FCZU4Ry0mF069Jc07pBVAYGFnaVwGCwU6p53XU7umKjJdB0ZOe
 K9yj_3xt1Vs_upIaA7bxiT_DDnhBm5xrhn13JK5GpkP4HDeaDwAtVIdqYZutrtizqrMjHk0SGsRS
 5y12uq25TQTc.4rluh_EeLh4.wywXjovYTKYJYmeIk6wgKyuJAkFtzod2izlVBPmFqydamLYgWYs
 YHPUyFkuqDTrSm9MhYMA2mpiqfC8MC2bZ6aKJCb1WA8IXgbrwZGA5To_Sig5Ch8VkDmDJtzBWQAT
 DpjL6ha2AeBNEMsaeiVSvSqK6v3mo44ReuzdCQFt5.j8y.Xy9ZSKiV0la9sKu7g7SafsFq1P0MsL
 0BeyVe3b44No0gXcz00CBQsFmJXGTlCX2Z7gfZN80KTmaOgbWs5z0P6VsLMbgbqb1HWdbamB.MoS
 TJ1mY4Ygnq0DlqiGAt02sFuyciuJDLXPFH_UE27JqfWlf5odvG_dCEhuXxWXU8miNLayxsHHZeMt
 G.gbRggGdsETEyV3nuXP1GYQYcLILslOscWvoUqL32RoOlfuhfmIZ4gp.AcFUocudpBptd0j7RiY
 H96fyccKEa0IJzLO21MdeGuPvQUgmgdiAvGYGn2gnxNl3srrpUpeeDZ02XSiKTz7JKdu0e5VqERQ
 qk9fl6vLb_Gpv87d86LVdPCNOe_o3u6LTolV0o_NioUKCwSS4jjGqIdm5Sj_ywaqaG_wB_DBiQMX
 W.t0P7yL.D2Qb6l4TfnFEaTGedzhOeSySCWQvO7pVebO9CNxz_0BvBkHChspKSPLmyp2hdiJMKQ8
 Igt2V3Ao.3GnNslSVgMltWLDwAK6vBmri_Sne8vGwVxVbuhm9yjHSFNr0Cb4frbT9VJaQXuDz1WJ
 .WVUWMnXzsbUpisnCFr4w89VZJsZQY9BqKk_xSRdC8_IrcOPaaC2fMz6KUhszRSXXWJg7c9ILeZS
 4F7mQpHFW0BfgbuvM6GVpNKW9wODvJkzGK9niY7RS2RPD3uN_3fmSvZ9CeUzS_g.TSpF9jjIhhiz
 pdeXekczHZTCSXD49hB7QJ8Os2d0AbyeINTR0s.UjHoDMfJslQYDiqFBuf7esEXzyTykkJAt.y4F
 DOHqngJ0D9RJu3k5cgrcU4dSPYHmySk8nM_x5zRrY3ohxJJH.uDOCHHry1PsFa2_3eMnhybbKLJW
 4dm1N_4BxMhuizXJfk1s4.mMmrSyoPO0eRNNcDrPm6uzxmRCAD5nBIBakgwpzeLPt7Ff8FRNV_0m
 CDD4nTCKZtEFAQUBR9tlu5nUy3Ot3xYFjjH3mC6IT6CYBQI.uahuqVR72UP2rPf_tfJ3bIU4RBNS
 _f5WYIli7Ku9RDuWzSHTHk5m_z4q4gnMTgVnSvkkEyaZBbEJKMr_V4jLyyqCBOChqxGMrR7r4ayL
 .kMAgSsefnmuiERG5ml1rmLi1IntQPRKVqYTQVxEs5Cndvr27KYWFDBUQz8SPdrrQ.99yH7sNN5n
 bxahmgmdlbvX15iH2NoSEV7Kdnx6H.AdOieguIqB18MEOVDRruP1VRuat2b3jPlNdruu76CRvuFN
 Otf_EydFKsI0hKu_TJDR5kKeoHr2DXereX8Ht5352cb_qPR7l498.XH2roU55RyJtyljglXUF9WX
 wJPYGCZ6r2LnNe7OnnzCZCFlXW1OFEZqgFY3BQUQZDThVM.9IfwGnGCBSFUxsqObx3kqa_t.Oz30
 ggc3foG8p2WNe4S_V3fV.uyj14tJ5jTcgkNi5ShIRgaM.5JKzbyhRqtslO10qe2TuqzCP2RKLdHd
 AKJvu8bR5JcO.OBHPq.VrC9ryM1gCkuWIxpjMVAFzV5zuMKIKh_7N1zU5qMwY
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Nov 2022 04:15:05 +0000
Received: by hermes--production-bf1-5878955b5f-jp8q4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b568be205fdcf84c3d97e18090ab9c9d;
          Sun, 13 Nov 2022 04:15:03 +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 \(3731.200.110.1.12\))
Subject: Odd sysctl -d kern.bootfile result
Message-Id: 
Date: Sat, 12 Nov 2022 20:14:50 -0800
To: freebsd-current 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: 
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from]
X-Rspamd-Queue-Id: 4N8zcX2b32z4Znr
X-ThisMailContainsUnwantedMimeParts: N

The context:

# ls -Tldt /boot/kern*/kernel
-r-xr-xr-x  1 root  wheel  40003240 Nov  6 16:32:05 2022 =
/boot/kernel/kernel
-r-xr-xr-x  1 root  wheel  39990232 Jul  6 11:21:16 2022 =
/boot/kernel.old/kernel
-r-xr-xr-x  1 root  wheel  31401824 Aug 19 03:16:29 2021 =
/boot/kernel.dbg/kernel

# uname -apKU # Note: output line split for readability
FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #55
main-n259064-f83db6441a2f-dirty: Sun Nov  6 16:31:55 PST 2022
=
root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a=
md64/sys/GENERIC-NODBG
amd64 amd64 1400073 1400073


But . . .

# sysctl -d kern.bootfile
kern.bootfile: Name of kernel file booted

# sysctl -W kern.bootfile
kern.bootfile: /boot/kernel.old/kernel

Looks wrong to me. (I've never explicitly assigned to kern.bootfile .)

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


From nobody Sun Nov 13 04:42:25 2022
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 4N90DF1c8Kz4hR1W
	for ; Sun, 13 Nov 2022 04:42:37 +0000 (UTC)
	(envelope-from kevans@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N90DF0wT0z3CC5
	for ; Sun, 13 Nov 2022 04:42:37 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1668314557;
	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=TPqiqoJ1xEVUVrkzEjp2p9q0x7qyZA5Fhe1Xnoi6CYg=;
	b=ihMztwsl99xow0Z7lerqpMgZqZCOOLDL6RQPdt4V7D0Bib2k1AafgzvXL4Ui3QFsJaq6qj
	dGxcGzC6wc49W1v6pumavs+Ry5O8f6wrMqAyXFTE6j3oKPDHPMIdiMXN33yP4O2szA2rbE
	9r7O5eVNoUHtKV7nqcyEeX5RJwTKrFr9oikw/XUqfdmzidL2z41toP5JmTSwuGaqKf0FvD
	asvVPO2bEquc8gbz68FWhH/IAqcesXiVmPWGstGHNMWZdCBghwAopaagGHEvaQzPXY6Hg/
	9SlS8B3RVJOYgVETVkyAfJpTrkeFGcBaQTDouC59E0PF6Rtd9rDjdTtjShPDGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1668314557;
	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=TPqiqoJ1xEVUVrkzEjp2p9q0x7qyZA5Fhe1Xnoi6CYg=;
	b=yhYdIz0F+L+MXebuV2YjDsbQWE5nxamvxwjGtIX+vCGShFWQrkXIhivvl9iBe4JJHGGTxG
	ycQJTL6LY57ER3Y8EO2v+t6SkyMnRR3s3glH3WhjAZZ5qVaR5lh7JCrmrx8tp8YZ03loPP
	y7DDiid8fgFWm+MzcsBRS5nZozyJ3HeBK0Cu5uddULuA60Pmhl0cCUFywnyS5o7/k5sw7H
	bqdgexbYK2uY2lduyEvMeq1Nx4g/LUSuGRzw+0es0lLLFDIRIvw1q+iUgDiGRE2ehn1MrX
	Z5aQeXyRsyOKRgDsxMKzh5ag4GaUrlFuxH/dOtEZoNGym1BYAIvvE8UKTEUjKA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668314557; a=rsa-sha256; cv=none;
	b=xpf/5Zw2anFTi4aAQiNBkBZ9x4mCzAOgJ7F2PD7csxM/aMwrjUO0fgXeloxRweXXIz63IB
	SV+9TvKiCf3laOi/0k1kZVWJYtXuKa5EUNCs9zf2Tbug9hrHBGwmrwODIxhuPzAIkgEpwm
	aBxJ7Cs23l4fu51+e2Cdjmw6oOC9ug3+4VnKvbB4i5zGLNhPRAOgI+E6XoYem0XPHFW3rD
	4KSAII4i/P+GPrbAPAGTELjuvJ1e9539/L0dPzf38E4S1LV1o2JnrszQx3+WhgbLNpIggT
	7cgHxsMUfnQYzAVvA026yDHcOdbxZHRhh7HCv4u9ZSL1Ajcq4bfNpO44i4lrwQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: kevans)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4N90DD72YHzkV5
	for ; Sun, 13 Nov 2022 04:42:36 +0000 (UTC)
	(envelope-from kevans@freebsd.org)
Received: by mail-qv1-f54.google.com with SMTP id w10so6027565qvr.3
        for ; Sat, 12 Nov 2022 20:42:36 -0800 (PST)
X-Gm-Message-State: ANoB5pkbr4RWfqJxaFpRljoPE/N+dZo9gh+JPRMOcSlC8UW0yrl7sYKE
	Xw6zRo/1op9aEioF6m2X3IEumX89Kq4qfrH3AOQ=
X-Google-Smtp-Source: AA0mqf7DuB00+4YXHv/XEZMZFTANM0ImqNUve+yQd5wl5oPjwqU9u2x8mmymFCwiPvWmRiAbwQI6xMfjSZPBjSadgFY=
X-Received: by 2002:ad4:5442:0:b0:4c6:1029:a36e with SMTP id
 h2-20020ad45442000000b004c61029a36emr8061500qvt.90.1668314556060; Sat, 12 Nov
 2022 20:42:36 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Kyle Evans 
Date: Sat, 12 Nov 2022 22:42:25 -0600
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Odd sysctl -d kern.bootfile result
To: Mark Millard 
Cc: freebsd-current 
Content-Type: text/plain; charset="UTF-8"
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Nov 12, 2022 at 10:16 PM Mark Millard  wrote:
>
> The context:
>
> # ls -Tldt /boot/kern*/kernel
> -r-xr-xr-x  1 root  wheel  40003240 Nov  6 16:32:05 2022 /boot/kernel/kernel
> -r-xr-xr-x  1 root  wheel  39990232 Jul  6 11:21:16 2022 /boot/kernel.old/kernel
> -r-xr-xr-x  1 root  wheel  31401824 Aug 19 03:16:29 2021 /boot/kernel.dbg/kernel
>
> # uname -apKU # Note: output line split for readability
> FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #55
> main-n259064-f83db6441a2f-dirty: Sun Nov  6 16:31:55 PST 2022
> root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG
> amd64 amd64 1400073 1400073
>
>
> But . . .
>
> # sysctl -d kern.bootfile
> kern.bootfile: Name of kernel file booted
>
> # sysctl -W kern.bootfile
> kern.bootfile: /boot/kernel.old/kernel
>
> Looks wrong to me. (I've never explicitly assigned to kern.bootfile .)
>

The usual suspect here is that you did an `installkernel` -- if it
replaces kern.bootfile, it moves the old kern.bootfile to
/boot/kernel.old and updates the sysctl to reflect the new location so
that it still accurately reflects the booted kernel.

Thanks,

Kyle Evans

From nobody Sun Nov 13 09:23:19 2022
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 4N96SR6Pxkz4hNhQ
	for ; Sun, 13 Nov 2022 09:23:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N96SR3TGqz40Q8
	for ; Sun, 13 Nov 2022 09:23:35 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668331412; bh=F3jnvmLgqN1hIyqFTQg2hnuzg9Dsw/L2GtrmhGb6YJs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WHDxgshCHh+OBwlX2/htaW0rsyX1Gjc0jZ6MgGYf8bCmn/DvsUop6Va2WsWpBAcZT5HV6IdC3IZB2SSf9P8FlVVDK2DIhP2Hy899rvuTlJGHxhR2QJ+WANJ3Mbk2wyt8XMs7NMsjKGmzeqxsiEMqhxldIkexAmmTfurlh+EjG+V2ONCxVTWtoJbnmP3hVtjkdcPCHyw6eeWO6rb/YgdSpSuHtebFCYySIpOMLZm4K0HW1cbpF7kqq0TsfjZnoPUXflXUplqF7OZrgtcJkoqAWPBPGKQ1puWl4TlONETeDdKdp7ERvsZXpYZUuZLALfCJ6A/9MAcptITVBc/K5Qe0sg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668331412; bh=iRmExUImY6TasepzYDGUTZoCF337JSjP1+iGpAhd79l=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PWB6CopwrrZJG3b1eUiKHDR8qOPZEBYWr92a1zEk+FfTepxivp8gD/ygWH1FwwL4pQH6F1chKiv+UqINIhEAeZ4y3LelAZfezclRcu2SQ1MA6Jh2GzpaEW01SH0h0wyiPcSVjjkbiiHMFNdcsbJ59X4Y4Bn61G/k1tFGQeS1VWTlA+eqD6maouBRFjfZOlPPVfRvOC91KDJX4MyJNbklWLEUS1Ts6zgwUuHhP7EgmRTPxZT2BjVVilS01ujR6DlcEvvVNIT5/B/ywOuVxQdWgygdgRD1aIAve5o5r/4MI8Kcox8tf6z5SzGfJXGrXzeID+WMY9zrk8/GrobJ78cEaA==
X-YMail-OSG: auVf8foVM1kp6bdvywHXLL8cHThbbv.5U9P7ObqURkuq80br6mR4wXt96M8bldC
 q0lmm4WWOOOaOBAbLWTFugasAqMnJstYclJlFugaKuyDWJ_tJfzvyd7Uflk0_iq6wUMKINxcPG8N
 peHfzihihEeFSeADFzp3x0WjYP50pg39AXhXu5F7bHYLKkBDua7mBkpcvSiK.xTvLVrLx8RprWQQ
 VGKH3uz_OjKNq.X8JSOb8k2veQDpgYdC1ND9ZuI3kBmL5fl8FGIYjYwaAkb1R0iUthsvb3_hSRwu
 y7jKK0pLQgvMGNnMH8DG1NNIlAvEfP0jcCE33NinpRdd8We.yAc8GtXptwpZmV07HZoju4_lYBNh
 jgbpMonew3VqwC3OhodFC4CH9.Ix5Z7mmWElU_UqTP0JkFLJLgCAuYDaHrHYqBjXSh3kHDB0_iYb
 ue9Qsl4jWw_Dh_9FE4OFZ7TOkmOwX6OBTDG6GAefiOzkNPbiqcp037U2e7.aB.5BJsvtHYf7OtxF
 V_AWRtoN9zaSKwSNsWFTKnFGJGrvtQQGOnd28r.DFHg1Zqj9zFZGVSwrS_vc02n8gM9DzFQltXl5
 .OTp8tolifQqZI9uxYWYWyeTq8tHWHdK25tH2uqKjeD8vp7X0952hfYBOh6dYeCczSgdByDW2S8P
 FHMsZpyX5LF9zjsYK5bRKYrcFNT.bwrPJ36GxLbjkZFVTnhfWm0BzIo.X6RmJJdkU2PFJ3fuEoRY
 1PPMo0.EXz4I707H6X9WZAX0On4umc9j2aF44b0pq3D9isuN8an5hP8SlXNuZMo_JfQN_cbK.4YN
 oo7cS.C9DeT5BLT_D9OS6v2ZsJHqzNMK4v7KYB65dLbq7THG6T2TASSPaq1z_VbdPPysuT7zQj6E
 NBgDy4VpuTdDZWCd4DYBKJhSZNm53A.iYUB9aTSF8r575qmbBI2khWm8VyQeV9nj4dUcpJ0lI.RV
 k33tunQqivns3ulbLhWGrKByc_SKG4EXeY7QyzyYtFyGBWSF_EUxjUHYKuUiLmqwrEfRpzWAqA7F
 0aCYRK9mLg25Ni1EzpRtgbXMqFKcDPR0p6WQIGDR.o.jUhnmTJUWuK5SWp9ZN.tAd7YvbnlaYLV_
 gcKQVh.h1KuBonFVk18eJXzQwoQmDNlRwihwDdwnfXPYxf1m5UAScI5a8rFv_jE4nNRy4yBlQxzO
 gsiMmMAamtqi_cqYnJg9JJwDNoyITCivJMTFXkGEOHvfU9C9_NmPmwUMA3gJWv8yB8dFeii05kJJ
 qaGdR7N0GlaE3_Pig0aNBQIKoI_YvTqKO8XbTfDIJKpk4nFrosLKspsJCkYMtRkh_n5OMQaWMe.M
 qzl48G5iHVSb222pnFalW60GxwMYK0G7QJybDyEE63_r2yhiAwqxntMyIL0ECsA7XzWzyiq5U6W_
 oNxoSonOJWp1HaavqLaOeST5X0jWbX7w6s3kjpyRxfQjevK7mEdea59J21BGkTvrmjYrhiDPoGun
 okrZuNUu0rw1p8Xcuz4VY9OeoyVVmPPyBo8ofHZd5TU_0Q3SVYM36fxvjYuEH_Gnxv2.h.0WkQiu
 FDEFETUD8AkYKK.t71nyZXEEgrI9Y7M8VfoCgSQ1WoCJU0bZYWgFnyv.nISOjEHSD2V4o8rTAeni
 kXcBxpbNokqbspAPEF0l09Jc54C3J_DRMn4S0CNw1qcVfD5RjW5iOkmeybOuO_Jn_X4zWZeQelNB
 E7O55j1l.HaDDytb23n9iEn.nlwsG3RfO86ZKDhV.QaPCSzSelnZK4c9vPOro1Z1b5aJRpzvzf7J
 OEabmSKfqKlwaOOlrIF4xu13o10XFMq0RKKasjComp8cTDblOdR6ipYZR0xKqNxsU3_LYB_Glo6S
 sX8d.v31qttg8fletIfTnTE5Gi36bszQNJTjRkIDbdt0httCVsRmYMHvsfpHY2RlFD69ozvUPugw
 bjpKqryQY2dUElhoW.WbGpiQ70BcpPyax6hPPBoDtyiiiLtgKGuiwgyFIFfoPtSiWDS7WKstJfs7
 dUBsMoO.KgYCu1WH46dSlnpxFzZ0TtZLZRZYYGln_hUq.n.wmOAFrR.oN5qnNRzsePEBOrdo4i9h
 YEH_Lqbrj6hbYzxEDhB1p33BvsKSDwQAVZdq7QTzDj6xOLCZ.B9WeiLFTyCRZ79ADCCbBF.KafqO
 N4XCsxRK4T5zWoRPO1tneL24wULOJO4yjml.oiW.NQ6073d6jhjEQzRSMkU0krpZ9NvdGZC_0aN9
 tgl8tyALeQLr6D5qIVx5VQAKWIOq_45I5O3pQQxrc9pkLeAaV4RI_2ht32wf_kySeOOrU6388PjA
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Nov 2022 09:23:32 +0000
Received: by hermes--production-gq1-579bc4bddd-hwj6j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 901d7d142b7665aebbf93ae8853e7dd7;
          Sun, 13 Nov 2022 09:23:30 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: Re: Odd sysctl -d kern.bootfile result
From: Mark Millard 
In-Reply-To: 
Date: Sun, 13 Nov 2022 01:23:19 -0800
Cc: freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
To: Kyle Evans 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Rspamd-Queue-Id: 4N96SR3TGqz40Q8
X-Spamd-Bar: ----
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]
X-ThisMailContainsUnwantedMimeParts: N

On Nov 12, 2022, at 20:42, Kyle Evans  wrote:

> On Sat, Nov 12, 2022 at 10:16 PM Mark Millard  =
wrote:
>>=20
>> The context:
>>=20
>> # ls -Tldt /boot/kern*/kernel
>> -r-xr-xr-x  1 root  wheel  40003240 Nov  6 16:32:05 2022 =
/boot/kernel/kernel
>> -r-xr-xr-x  1 root  wheel  39990232 Jul  6 11:21:16 2022 =
/boot/kernel.old/kernel
>> -r-xr-xr-x  1 root  wheel  31401824 Aug 19 03:16:29 2021 =
/boot/kernel.dbg/kernel
>>=20
>> # uname -apKU # Note: output line split for readability
>> FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #55
>> main-n259064-f83db6441a2f-dirty: Sun Nov  6 16:31:55 PST 2022
>> =
root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a=
md64/sys/GENERIC-NODBG
>> amd64 amd64 1400073 1400073
>>=20
>>=20
>> But . . .
>>=20
>> # sysctl -d kern.bootfile
>> kern.bootfile: Name of kernel file booted
>>=20
>> # sysctl -W kern.bootfile
>> kern.bootfile: /boot/kernel.old/kernel
>>=20
>> Looks wrong to me. (I've never explicitly assigned to kern.bootfile =
.)
>>=20
>=20
> The usual suspect here is that you did an `installkernel` -- if it
> replaces kern.bootfile, it moves the old kern.bootfile to
> /boot/kernel.old and updates the sysctl to reflect the new location so
> that it still accurately reflects the booted kernel.

Ahh: no, but, yes, sort of. For:

# bectl list
BE             Active Mountpoint Space Created
13S-amd64      -      -          4.96G 2021-08-20 16:57
13_0R-amd64    -      -          4.30G 2021-08-20 16:56
13_1R-amd64    -      -          3.76G 2022-03-10 12:38
main-amd64     NR     /          7.26G 2022-11-06 20:02
old-main-amd64 -      -          2.37G 2022-10-14 14:59

I normally boot main-amd64 but I also maintain the 13*-amd64's via
mounting and chrooting into the 13*-amd64 be's and doing buildworld
buildkernel and installkernel installworld while chrooted (no
reboot). (I generate and boot an updated main-amd64 first.) The:

kernel-install: .PHONY
. . .
                sysctl kern.bootfile=3D${DESTDIR}${KODIR}.old/"`basename =
"$$thiskernel"`" ; \

is apparently not local to the chroot's context but changes the
booted system's live value despite the live system not being
what was updated.

The be entry usage is not essential here. chroot'ing into a
directory tree used for the same sort of purpose for UFS
(or ZFS) would have the same issue if installkernel was
part of the activity.

I may consider saving and restoring kern.bootfile in my
13*-amd64 procedures so that kern.bootfile does not end up
being misleading.

Thanks for the note!

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


From nobody Sun Nov 13 15:47:40 2022
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 4N9Gzj1qjLz4hQZx
	for ; Sun, 13 Nov 2022 15:47:45 +0000 (UTC)
	(envelope-from l.m.v.breda@xs4all.nl)
Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N9Gzg2jnbz3j3m
	for ; Sun, 13 Nov 2022 15:47:43 +0000 (UTC)
	(envelope-from l.m.v.breda@xs4all.nl)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=xs4all.nl header.s=xs4all01 header.b=iJg2iLeU;
	spf=pass (mx1.freebsd.org: domain of l.m.v.breda@xs4all.nl designates 195.121.94.167 as permitted sender) smtp.mailfrom=l.m.v.breda@xs4all.nl;
	dmarc=pass (policy=none) header.from=xs4all.nl
X-KPN-MessageId: 80c8e839-636a-11ed-a5a6-005056abbe64
Received: from smtp.kpnmail.nl (unknown [10.31.155.39])
	by ewsoutbound.so.kpn.org (Halon) with ESMTPS
	id 80c8e839-636a-11ed-a5a6-005056abbe64;
	Sun, 13 Nov 2022 16:47:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=xs4all.nl; s=xs4all01;
	h=content-type:mime-version:message-id:date:subject:to:from;
	bh=fG6laj46KmErkAnbTXOBbl2A3mr4wRRrjk5dHCBSfwU=;
	b=iJg2iLeUCkBDRcBqI73/DOzmPvDVn6O2HB0tcyru8mpuffNQsbyQ6smN7NSI3gWNiECaSRMX5qDfS
	 F+lz3rPvEOiJV3eb67y6ArytKh/ykDfaV0DqE/rLaY14RyUa0xiHxDRbA2R4Fr62UzeNEZ7gkC9sKz
	 neMaaYsUe20HsXfRQDM9FAjevY/TPCE/d3agxFw3HvuioDkq+sLA/nb/MDwTarIne9aMnNnGGrsGDx
	 T/yn7rvCgNPQPGlqhfETxBpEQ0nznI/hbqgKVgYa7klN6J61xgN9JLlGebj/GgDGUUGoTyqCY9faMK
	 zYf0Ctn+6qan1u9fktU4wLnTnVjdzLg==
X-KPN-MID: 33|+ouguoWR0k4w3ey8z/Y0pqNcEtlLcbgnk1YjyTAoBI57alpRjH/lmJI/rh0Un4h
 GqFtKjpJ4HpJWMWmRbmxEMGb6Up7RfLXzuKyKCeLZFMM=
X-KPN-VerifiedSender: Yes
X-CMASSUN: 33|I6EGQcPWeEo/TKCLIYBpUZsBLZRxevPIhfDXjNoT4tLfHnCJiX47g0/wMlG5Jab
 RTuH8fhiKnAg242llL96nqw==
X-Originating-IP: 77.174.182.228
Received: from MAIN (77-174-182-228.fixed.kpn.net [77.174.182.228])
	by smtp.xs4all.nl (Halon) with ESMTPSA
	id 8135bad9-636a-11ed-b8b1-005056ab7447;
	Sun, 13 Nov 2022 16:47:40 +0100 (CET)
From: 
To: "'Kirk McKusick'" 
Cc: 
References: <202211130022.2AD0MYiW023709@chez.mckusick.com>
In-Reply-To: <202211130022.2AD0MYiW023709@chez.mckusick.com>
Subject: RE: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
Date: Sun, 13 Nov 2022 16:47:40 +0100
Message-ID: <000d01d8f777$42eb10a0$c8c131e0$@xs4all.nl>
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-Mailer: Microsoft Outlook 16.0
Thread-Index: AQDt7DtUGkthWTj4TPziqLFRIfjyNLATEpfw
Content-Language: nl
X-Spamd-Result: default: False [-0.80 / 15.00];
	DMARC_POLICY_ALLOW(-0.50)[xs4all.nl,none];
	FORGED_SENDER(0.30)[louis.freebsd@xs4all.nl,l.m.v.breda@xs4all.nl];
	R_SPF_ALLOW(-0.20)[+ip4:195.121.94.167/32];
	R_DKIM_ALLOW(-0.20)[xs4all.nl:s=xs4all01];
	RCVD_IN_DNSWL_LOW(-0.10)[195.121.94.167:from];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_ALL(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_NEQ_ENVFROM(0.00)[louis.freebsd@xs4all.nl,l.m.v.breda@xs4all.nl];
	FROM_NO_DN(0.00)[];
	ASN(0.00)[asn:8737, ipnet:195.121.64.0/18, country:NL];
	FREEMAIL_ENVFROM(0.00)[xs4all.nl];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[xs4all.nl:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_SOME(0.00)[];
	HAS_XOIP(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[];
	FREEMAIL_FROM(0.00)[xs4all.nl];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[xs4all.nl:dkim]
X-Rspamd-Queue-Id: 4N9Gzg2jnbz3j3m
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

I noticed that after disabling gdm in /etc/rc.conf ^"gdm_enable=3D"N"^ =
the system stays active.
However ..... that is also the end the GUI .... in this case GNOME.

Since I could not work which a machine hibernating every ^10 minutes^, I =
have disabled gdm for the moment.=20
That does not take away that that is ...... ridiculous !!

There should be a way to disable ACPI in FreeBSD so that even gdm can =
not "kill" the machine !!
I say ^kill^ because there is also another bug, the machine is not =
properly restarting form hibernation,=20
Even not from S1.

Louis =20
-----Original Message-----
From: Kirk McKusick =20
Sent: Sunday, November 13, 2022 1:23 AM
To: louis.freebsd@xs4all.nl
Cc: freebsd-current@FreeBSD.org
Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable =
ACPI? (on FreeBSD14 CURRENT)

> From: 
> To: 
> Subject: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI?=20
> (on FreeBSD14 CURRENT)
> Date: Thu, 10 Nov 2022 21:29:21 +0100
>=20
> I am still desperately trying to stop FreeBSD from sleeping, but I=20
> simply do not manage.
>=20
> It is really very annoying that I have to restart the machine every
> 10 minutes, when I am working via SSH.
>=20
> So if any one has a solution, it would be very much appreciated!
>=20
> It should =E2=80=A6.. be possible to kill / stop ACPI some how =
=F0=9F=98=8A
>=20
> If absolutely not possible in the actual build =F0=9F=98=8A, a cron =
job=20
> restarting the timer every 5 minutes perhaps !!???
>=20
> It is possible perhaps =E2=80=A6 that GNOME is initiating this, =
despite that=20
> the GUI powersetting is screenblank =E2=80=9CNEVER=E2=80=9D.  =20
>=20
> Whatever is causing the problem, the settings should be such that ^no=20
> whatever program^ should not be capable to initiate the sleepmode.
>=20
> Louis

If you are using Gnome, Gnome suspends the machine after 20 minutes if =
there is no mouse or keyboard activity. I went into settings, but there =
is no way to adjust this feature. Some web searching brought me to this =
page:

https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22

Apparently the 20-minute suspend was made unchangable (at least not =
without changing the source code for Gnome and rebuilding it).
Apparently this change was made to comply with EU power regulations.
Anyway, this ruled out Gnome for me.

	Kirk McKusick


From nobody Sun Nov 13 17:53:00 2022
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 4N9KmV03mVz4hml5
	for ; Sun, 13 Nov 2022 17:53:14 +0000 (UTC)
	(envelope-from sr@genyosha.net)
Received: from ns4.genyosha.net (ns4.genyosha.net [50.53.250.75])
	(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 "float.home.genyosha.net", Issuer "float.home.genyosha.net" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N9KmT4KZXz3wkV
	for ; Sun, 13 Nov 2022 17:53:13 +0000 (UTC)
	(envelope-from sr@genyosha.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from dragon.home.genyosha.net (ops.genyosha.net [50.53.250.77])
	by ns4.genyosha.net (8.16.1/8.16.1) with ESMTPS id 2ADHr5Tp050075
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Sun, 13 Nov 2022 09:53:06 -0800 (PST)
	(envelope-from sr@genyosha.net)
Received: from dragon.home.genyosha.net (localhost [127.0.0.1])
	by dragon.home.genyosha.net (8.14.7/8.14.7) with ESMTP id 2ADHr0g4003749;
	Sun, 13 Nov 2022 09:53:00 -0800
Received: (from sr@localhost)
	by dragon.home.genyosha.net (8.14.7/8.14.7/Submit) id 2ADHr037003748;
	Sun, 13 Nov 2022 09:53:00 -0800
Date: Sun, 13 Nov 2022 09:53:00 -0800
From: Steve Rikli 
To: louis.freebsd@xs4all.nl
Cc: freebsd-current@FreeBSD.org
Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on
 FreeBSD14 CURRENT)
Message-ID: 
References: <202211130022.2AD0MYiW023709@chez.mckusick.com>
 <000d01d8f777$42eb10a0$c8c131e0$@xs4all.nl>
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: <000d01d8f777$42eb10a0$c8c131e0$@xs4all.nl>
X-Greylist: inspected by milter-greylist-4.6.4 (ns4.genyosha.net [50.53.250.75]); Sun, 13 Nov 2022 09:53:06 -0800 (PST) for IP:'50.53.250.77' DOMAIN:'ops.genyosha.net' HELO:'dragon.home.genyosha.net' FROM:'sr@genyosha.net' RCPT:''
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (ns4.genyosha.net [50.53.250.75]); Sun, 13 Nov 2022 09:53:06 -0800 (PST)
X-Rspamd-Queue-Id: 4N9KmT4KZXz3wkV
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:20055, ipnet:50.53.0.0/16, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Sun, Nov 13, 2022 at 04:47:40PM +0100, louis.freebsd@xs4all.nl wrote:
> I noticed that after disabling gdm in /etc/rc.conf ^"gdm_enable="N"^ the system stays active.
> However ..... that is also the end the GUI .... in this case GNOME.
> 
> Since I could not work which a machine hibernating every ^10 minutes^, I have disabled gdm for the moment. 
> That does not take away that that is ...... ridiculous !!

Seems like you aren't alone in that opinion -- there are several threads
for multiple OSes about this same topic. Kirk's findings below match my
recollection -- this is Gnome default behavior nowdays.

In any case, since we obviously can't use the Linux systemD settings to
control the behavior in FreeBSD, a few folks mentioned other workarounds
with things like dconf; e.g. this suggestion which came originally from
the Arch linux folks:

https://twitter.com/_neelc/status/1487200568149831681

https://wiki.archlinux.org/title/GDM#GDM_auto-suspend_(GNOME_3.28)

Something like:

  sudo -u gdm dbus-launch gsettings set \
  org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'

>From the threads, it sounds like part of the problem is this behavior and
settings are per-user, so making a system-wide change is hard. Not sure
how this workaround will play in your situation.

My FreeBSD servers don't run a gui display manager; my Debian laptop
runs gdm3 display manager but I switched to Xfce for the window manager
around the time Gnome3 came out (too many changes for my taste).  Fwiw
the Xfce Power Manager has controls for system power save / sleep mode
for "On battery" and "Plugged in", including "never".

Cheers,
sr.


> There should be a way to disable ACPI in FreeBSD so that even gdm can not "kill" the machine !!
> I say ^kill^ because there is also another bug, the machine is not properly restarting form hibernation, 
> Even not from S1.
> 
> Louis  
> 
> -----Original Message-----
> From: Kirk McKusick  
> Sent: Sunday, November 13, 2022 1:23 AM
> To: louis.freebsd@xs4all.nl
> Cc: freebsd-current@FreeBSD.org
> Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
> 
> > From: 
> > To: 
> > Subject: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? 
> > (on FreeBSD14 CURRENT)
> > Date: Thu, 10 Nov 2022 21:29:21 +0100
> > 
> > I am still desperately trying to stop FreeBSD from sleeping, but I 
> > simply do not manage.
> > 
> > It is really very annoying that I have to restart the machine every
> > 10 minutes, when I am working via SSH.
> > 
> > So if any one has a solution, it would be very much appreciated!
> > 
> > It should ….. be possible to kill / stop ACPI some how 😊
> > 
> > If absolutely not possible in the actual build 😊, a cron job 
> > restarting the timer every 5 minutes perhaps !!???
> > 
> > It is possible perhaps … that GNOME is initiating this, despite that 
> > the GUI powersetting is screenblank “NEVERâ€.   
> > 
> > Whatever is causing the problem, the settings should be such that ^no 
> > whatever program^ should not be capable to initiate the sleepmode.
> > 
> > Louis
> 
> If you are using Gnome, Gnome suspends the machine after 20 minutes if there is no mouse or keyboard activity. I went into settings, but there is no way to adjust this feature. Some web searching brought me to this page:
> 
> https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22
> 
> Apparently the 20-minute suspend was made unchangable (at least not without changing the source code for Gnome and rebuilding it).
> Apparently this change was made to comply with EU power regulations.
> Anyway, this ruled out Gnome for me.
> 
> 	Kirk McKusick

From nobody Sun Nov 13 22:10:44 2022
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 4N9RTl34rwz4hH4Y
	for ; Sun, 13 Nov 2022 22:10:51 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N9RTk66Nbz3KQM
	for ; Sun, 13 Nov 2022 22:10:50 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2ADMAiiM078365;
	Mon, 14 Nov 2022 07:10:45 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Mon, 14 Nov 2022 07:10:44 +0900
From: Tomoaki AOKI 
To: Steve Rikli 
Cc: louis.freebsd@xs4all.nl, freebsd-current@FreeBSD.org
Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI?
 (on FreeBSD14 CURRENT)
Message-Id: <20221114071044.ded87a4bd11f9aa8e948ebcf@dec.sakura.ne.jp>
In-Reply-To: 
References: <202211130022.2AD0MYiW023709@chez.mckusick.com>
	<000d01d8f777$42eb10a0$c8c131e0$@xs4all.nl>
	
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.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-2022-JP
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4N9RTk66Nbz3KQM
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Sun, 13 Nov 2022 09:53:00 -0800
Steve Rikli  wrote:

> On Sun, Nov 13, 2022 at 04:47:40PM +0100, louis.freebsd@xs4all.nl wrote:
> > I noticed that after disabling gdm in /etc/rc.conf ^"gdm_enable="N"^ the system stays active.
> > However ..... that is also the end the GUI .... in this case GNOME.
> > 
> > Since I could not work which a machine hibernating every ^10 minutes^, I have disabled gdm for the moment. 
> > That does not take away that that is ...... ridiculous !!
> 
> Seems like you aren't alone in that opinion -- there are several threads
> for multiple OSes about this same topic. Kirk's findings below match my
> recollection -- this is Gnome default behavior nowdays.
> 
> In any case, since we obviously can't use the Linux systemD settings to
> control the behavior in FreeBSD, a few folks mentioned other workarounds
> with things like dconf; e.g. this suggestion which came originally from
> the Arch linux folks:
> 
> https://twitter.com/_neelc/status/1487200568149831681
> 
> https://wiki.archlinux.org/title/GDM#GDM_auto-suspend_(GNOME_3.28)
> 
> Something like:
> 
>   sudo -u gdm dbus-launch gsettings set \
>   org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
> 
> >From the threads, it sounds like part of the problem is this behavior and
> settings are per-user, so making a system-wide change is hard. Not sure
> how this workaround will play in your situation.
> 
> My FreeBSD servers don't run a gui display manager; my Debian laptop
> runs gdm3 display manager but I switched to Xfce for the window manager
> around the time Gnome3 came out (too many changes for my taste).  Fwiw
> the Xfce Power Manager has controls for system power save / sleep mode
> for "On battery" and "Plugged in", including "never".

Found these.

 https://unix.stackexchange.com/questions/289640/how-to-create-a-default-system-wide-dconf-setting-starting-from-just-created-ad

 https://askubuntu.com/questions/1038184/how-to-lockdown-system-wide-settings-with-dconf

/etc/ in those should be read /usr/local/etc/ on FreeBSD.
And possibly defaults of each application are stored
under /usr/local/share/ or under /usr/local/lib/.

BTW, I'm basically using x11/mate, a fork from Gnome2.
It doesn't sleep by default on AC powerline.
(Old installation succeeding Gnome2 settings. So current default could
be different, though.)

> 
> Cheers,
> sr.
> 
> 
> > There should be a way to disable ACPI in FreeBSD so that even gdm can not "kill" the machine !!
> > I say ^kill^ because there is also another bug, the machine is not properly restarting form hibernation, 
> > Even not from S1.
> > 
> > Louis  
> > 
> > -----Original Message-----
> > From: Kirk McKusick  
> > Sent: Sunday, November 13, 2022 1:23 AM
> > To: louis.freebsd@xs4all.nl
> > Cc: freebsd-current@FreeBSD.org
> > Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
> > 
> > > From: 
> > > To: 
> > > Subject: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? 
> > > (on FreeBSD14 CURRENT)
> > > Date: Thu, 10 Nov 2022 21:29:21 +0100
> > > 
> > > I am still desperately trying to stop FreeBSD from sleeping, but I 
> > > simply do not manage.
> > > 
> > > It is really very annoying that I have to restart the machine every
> > > 10 minutes, when I am working via SSH.
> > > 
> > > So if any one has a solution, it would be very much appreciated!
> > > 
> > > It should $B!D(B.. be possible to kill / stop ACPI some how $B".(B
> > > 
> > > If absolutely not possible in the actual build $B".(B, a cron job 
> > > restarting the timer every 5 minutes perhaps !!???
> > > 
> > > It is possible perhaps $B!D(B that GNOME is initiating this, despite that 
> > > the GUI powersetting is screenblank $B!H(BNEVER$B!I(B.   
> > > 
> > > Whatever is causing the problem, the settings should be such that ^no 
> > > whatever program^ should not be capable to initiate the sleepmode.
> > > 
> > > Louis
> > 
> > If you are using Gnome, Gnome suspends the machine after 20 minutes if there is no mouse or keyboard activity. I went into settings, but there is no way to adjust this feature. Some web searching brought me to this page:
> > 
> > https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22
> > 
> > Apparently the 20-minute suspend was made unchangable (at least not without changing the source code for Gnome and rebuilding it).
> > Apparently this change was made to comply with EU power regulations.
> > Anyway, this ruled out Gnome for me.
> > 
> > 	Kirk McKusick
> 


-- 
Tomoaki AOKI    

From nobody Mon Nov 14 00:21:46 2022
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 4N9VP84DlKz4hY7j
	for ; Mon, 14 Nov 2022 00:22:04 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N9VP81jGkz3qFb
	for ; Mon, 14 Nov 2022 00:22:04 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-37063f855e5so92530977b3.3
        for ; Sun, 13 Nov 2022 16:22:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=odOZBb/4GT/LXiyvT0G2bkf0QPQFpHy+BiybvYcbcGM=;
        b=InqqgoxbooI4U6upaNBOT/RDtnEpTEDwpTY2Z2HdhLdEfxc71UxUJ3DF7jSvOnBhZm
         pfozgV+X9kk4G7Ny2cQOvzKGUxrJBEDjCcOY4DIHJ/Vvn2+ZDRq2Po5MbpdyULGtTkWZ
         CF2N+nu0kbvSR4ujQsXyzguIRdiCN/F8Asei2xN6EOBBcX5UCw3kGR02ByMKs3zFVqgl
         oWrzCOBCEICfAXH8onUQOzIQUd/TcgL6AmDbqJ1g1B7AlGqOmKhPq91eNGvE9ANzmh8u
         gjNFr5dV5A8vIvhxMTs5avXBH04Zl8belR9a/WQyGFQT8v/KDsTfUlr2bjt067ERPW1A
         YtVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=odOZBb/4GT/LXiyvT0G2bkf0QPQFpHy+BiybvYcbcGM=;
        b=CBpOHCzTjpQPLjupWF9CEltQO3Rcsg5TD7M6IpQCt4tHehkSHTsskdjvJpyyrHd8L6
         d9/+QUqCkXdbqRzR0xJAGsvK8BTNEG59YeybQsaqMimgpPFKTiDRNBWqQ0UkvTbj9qJW
         bkPbXQ/9hZcohZD0XDmStOco3fuU7mDAZLct5Gr1WZBIMqKXLtSOTntXW1QEZqCFAdoq
         +Dod9jOoPNbYEo5WM8EgGZ/XisMxtfdjj5c6k5XZCSaZeF/60phnOHbIDUl3yHpE39cC
         VH8+KfQRRAoWHw9IXp4pJ8FhnPjlolYlfquHqqnA5us8XDO6VFtT0bjBfuVBvd/wy3ex
         o/3w==
X-Gm-Message-State: ANoB5pn6O1V7wLiT12DIhRpzCjL342SOtMr2uHZn7zPjzmkguux+uoXk
	2/4zuPJl9DY1nSjNZbDav4ypPZfkvz058KSae59q0hp5SU0=
X-Google-Smtp-Source: AA0mqf6pB3Kje3nlTIHAMZLLdXLrQb1QqRPUfjzSXGmDkv+Xs2Dg/a/t9g8+ySrou4CZRPslq8uOq5BHStQdT8vRIDo=
X-Received: by 2002:a81:7841:0:b0:36b:84e6:16b2 with SMTP id
 t62-20020a817841000000b0036b84e616b2mr11486778ywc.372.1668385322311; Sun, 13
 Nov 2022 16:22:02 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <202211130022.2AD0MYiW023709@chez.mckusick.com>
 <000d01d8f777$42eb10a0$c8c131e0$@xs4all.nl> 
 <20221114071044.ded87a4bd11f9aa8e948ebcf@dec.sakura.ne.jp>
In-Reply-To: <20221114071044.ded87a4bd11f9aa8e948ebcf@dec.sakura.ne.jp>
From: Kevin Oberman 
Date: Sun, 13 Nov 2022 16:21:46 -0800
Message-ID: 
Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on
 FreeBSD14 CURRENT)
To: Tomoaki AOKI 
Cc: Steve Rikli , louis.freebsd@xs4all.nl, freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000007c23ae05ed633afc"
X-Rspamd-Queue-Id: 4N9VP81jGkz3qFb
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--0000000000007c23ae05ed633afc
Content-Type: text/plain; charset="UTF-8"

On Sun, Nov 13, 2022 at 2:11 PM Tomoaki AOKI 
wrote:

> On Sun, 13 Nov 2022 09:53:00 -0800
> Steve Rikli  wrote:
>
> > On Sun, Nov 13, 2022 at 04:47:40PM +0100, louis.freebsd@xs4all.nl wrote:
> > > I noticed that after disabling gdm in /etc/rc.conf ^"gdm_enable="N"^
> the system stays active.
> > > However ..... that is also the end the GUI .... in this case GNOME.
> > >
> > > Since I could not work which a machine hibernating every ^10 minutes^,
> I have disabled gdm for the moment.
> > > That does not take away that that is ...... ridiculous !!
> >
> > Seems like you aren't alone in that opinion -- there are several threads
> > for multiple OSes about this same topic. Kirk's findings below match my
> > recollection -- this is Gnome default behavior nowdays.
> >
> > In any case, since we obviously can't use the Linux systemD settings to
> > control the behavior in FreeBSD, a few folks mentioned other workarounds
> > with things like dconf; e.g. this suggestion which came originally from
> > the Arch linux folks:
> >
> > https://twitter.com/_neelc/status/1487200568149831681
> >
> > https://wiki.archlinux.org/title/GDM#GDM_auto-suspend_(GNOME_3.28)
> >
> > Something like:
> >
> >   sudo -u gdm dbus-launch gsettings set \
> >   org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
> 'nothing'
> >
> > >From the threads, it sounds like part of the problem is this behavior
> and
> > settings are per-user, so making a system-wide change is hard. Not sure
> > how this workaround will play in your situation.
> >
> > My FreeBSD servers don't run a gui display manager; my Debian laptop
> > runs gdm3 display manager but I switched to Xfce for the window manager
> > around the time Gnome3 came out (too many changes for my taste).  Fwiw
> > the Xfce Power Manager has controls for system power save / sleep mode
> > for "On battery" and "Plugged in", including "never".
>
> Found these.
>
>
> https://unix.stackexchange.com/questions/289640/how-to-create-a-default-system-wide-dconf-setting-starting-from-just-created-ad
>
>
> https://askubuntu.com/questions/1038184/how-to-lockdown-system-wide-settings-with-dconf
>
> /etc/ in those should be read /usr/local/etc/ on FreeBSD.
> And possibly defaults of each application are stored
> under /usr/local/share/ or under /usr/local/lib/.
>
> BTW, I'm basically using x11/mate, a fork from Gnome2.
> It doesn't sleep by default on AC powerline.
> (Old installation succeeding Gnome2 settings. So current default could
> be different, though.)
>
> >
> > Cheers,
> > sr.
>

This is the source of foolishness that led to the creation of Linux Mint
and to Mate. Mate does not have this stupidness and I suspect that Cinnamon
does not, either. Gnome has simply gone off the rails.

Another option is to NOT use gdm, but start Gnome with startx, which I have
always done. You will need to create a suitable .xinitrc to set up dbus and
run X as a child:
exec ck-launch-session dbus-launch --exit-with-session mate-session
 Under Linux this stuff is all wrapped around systemd which makes dealing
with it a pain.

I am not remotely expert on this, but it works OK and I am hoping to figure
out a bit more as time is available.
-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

--0000000000007c23ae05ed633afc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Sun, Nov 13, 2022 at 2:11 PM=
 Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
On Sun, 13 Nov =
2022 09:53:00 -0800

Steve Rikli <sr@gen=
yosha.net> wrote:



> On Sun, Nov 13, 2022 at 04:47:40PM +0100, louis.freebsd@xs4all.nl wrote:

> > I noticed that after disabling gdm in /etc/rc.conf ^"gdm_ena=
ble=3D"N"^ the system stays active.

> > However ..... that is also the end the GUI .... in this case GNOM=
E.

> > 

> > Since I could not work which a machine hibernating every ^10 minu=
tes^, I have disabled gdm for the moment. 

> > That does not take away that that is ...... ridiculous !!

> 

> Seems like you aren't alone in that opinion -- there are several t=
hreads

> for multiple OSes about this same topic. Kirk's findings below mat=
ch my

> recollection -- this is Gnome default behavior nowdays.

> 

> In any case, since we obviously can't use the Linux systemD settin=
gs to

> control the behavior in FreeBSD, a few folks mentioned other workaroun=
ds

> with things like dconf; e.g. this suggestion which came originally fro=
m

> the Arch linux folks:

> 

> https://twitter.com/_neelc/status/1487200=
568149831681

> 

> https://wiki.archlinux.org/ti=
tle/GDM#GDM_auto-suspend_(GNOME_3.28)

> 

> Something like:

> 

>=C2=A0 =C2=A0sudo -u gdm dbus-launch gsettings set \

>=C2=A0 =C2=A0org.gnome.settings-daemon.plugins.power sleep-inactive-ac-=
type 'nothing'

> 

> >From the threads, it sounds like part of the problem is this behav=
ior and

> settings are per-user, so making a system-wide change is hard. Not sur=
e

> how this workaround will play in your situation.

> 

> My FreeBSD servers don't run a gui display manager; my Debian lapt=
op

> runs gdm3 display manager but I switched to Xfce for the window manage=
r

> around the time Gnome3 came out (too many changes for my taste).=C2=A0=
 Fwiw

> the Xfce Power Manager has controls for system power save / sleep mode=


> for "On battery" and "Plugged in", including "=
;never".



Found these.



=C2=A0https://unix.stackexchange.com/questions/=
289640/how-to-create-a-default-system-wide-dconf-setting-starting-from-just=
-created-ad



=C2=A0https:/=
/askubuntu.com/questions/1038184/how-to-lockdown-system-wide-settings-with-=
dconf



/etc/ in those should be read /usr/local/etc/ on FreeBSD.

And possibly defaults of each application are stored

under /usr/local/share/ or under /usr/local/lib/.



BTW, I'm basically using x11/mate, a fork from Gnome2.

It doesn't sleep by default on AC powerline.

(Old installation succeeding Gnome2 settings. So current default could

be different, though.)



> 

> Cheers,

> sr.

This is the source of foo=
lishness that led to the creation of Linux Mint and to Mate. Mate does not =
have this stupidness and I suspect that Cinnamon does not, either. Gnome ha=
s simply gone off the rails. 

Anothe=
r option is to NOT use gdm, but start Gnome with startx, which I have alway=
s done. You will need to create a suitable .xinitrc to set up dbus and run =
X as a child:
exec ck-launch-session dbus-launch --exit-with=
-session mate-session
=C2=A0Under Linux this stuff is all wr=
apped around systemd which makes dealing with it a pain.

I am not remotely expert on this, but it works OK and =
I am hoping to figure out a bit more as time is available.
-=
- 
Kevin Oberman, Part time kid herder and reti=
red Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB9=
8AFA78E3B78C1694B318AB39EF1B055683


--0000000000007c23ae05ed633afc--

From nobody Mon Nov 14 06:50:20 2022
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 4N9g1H06mWz4hFBW
	for ; Mon, 14 Nov 2022 06:50:27 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20])
	(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 4N9g1G0cq4z4PHj
	for ; Mon, 14 Nov 2022 06:50:25 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=dell.com header.s=smtpout1 header.b=krJwIGmk;
	spf=pass (mx1.freebsd.org: domain of Weike.Chen@Dell.com designates 148.163.133.20 as permitted sender) smtp.mailfrom=Weike.Chen@Dell.com;
	dmarc=pass (policy=reject) header.from=dell.com;
	arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}")
Received: from pps.filterd (m0170393.ppops.net [127.0.0.1])
	by mx0a-00154904.pphosted.com (8.17.1.19/8.17.1.5) with ESMTP id 2AE4ttkv029110;
	Mon, 14 Nov 2022 01:50:24 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=smtpout1;
 bh=P+rRDfoIFy51FndV60HappSptdUrZ8vlXiZdez/M7gI=;
 b=krJwIGmkPVq7oOXndVHLjkvqRFFjfI4/mF4la3DdKqTJsDbgiQ/Ij1GTjV2UlyWsDHdS
 1k88phtBllEgUUCNKhDaj0PZUxC72WKLaKM0MVSyNpI9B99DzelnClFspGrXhbLpbSPC
 V0N4lfaia0/PlbcnQhQIv/tHtG6xm2vulM3tEn9gtkNnoodDmV/POW/D3w9oXdME2hk0
 DaAiyZv7+vdH1sEfG+wHDg3763cEl/rhrHnxD0V5yiUE7+cdleVX7Nu46zzvsPyiTvBy
 67unLXZUASRFsYRDl1YuTiJEfYoI4XvOZrZb5RkkDEKGmPDPTJ90eSRjSrzMOJ9trSt3 uw== 
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39])
	by mx0a-00154904.pphosted.com (PPS) with ESMTPS id 3kuf2t8ct1-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
	Mon, 14 Nov 2022 01:50:24 -0500
Received: from pps.filterd (m0133268.ppops.net [127.0.0.1])
	by mx0a-00154901.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AE6ZGen017855;
	Mon, 14 Nov 2022 01:50:24 -0500
Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2169.outbound.protection.outlook.com [104.47.55.169])
	by mx0a-00154901.pphosted.com (PPS) with ESMTPS id 3kughqg70m-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
	Mon, 14 Nov 2022 01:50:23 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=oSDO4vCjlw4ovDKe5n33cKN7Tgn62zzH0im4JUW2O4Q42PqDiqAls81SXSu0LhQDvyUcjsrGKdRsAQYUUlODsRdYywuc7n+O1lL16T1E4Akc3FYegZAL9gGmAj3zyaE9qSh5893ZZRFFiEExDGwgQlxLXz1FStR6bY5e1SEnx57wDRskmZl+1ou7nTS9nhbmBvZAMYToYp1RgeEH00E7XDPJW1ZNwZed4RKVtOFUbqYlVMtD1gaKPQlb1rG5UQEE7YRHHN7iVmcdkIpn9hT0GXct09u45tmslQtxAbZmrFMiAj/x+B0e2oshTcOnQzJn3XU66epKfKPfzyOZhFMZQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=P+rRDfoIFy51FndV60HappSptdUrZ8vlXiZdez/M7gI=;
 b=gqcwTH68/kGQVEMtQNVR3FXJP7iDY3R3TdPmAoRu+Vqn+f1G201+bKwdrhSyibdcBEH8pHRFia/HNF2sCG2sGfyZY+3I2usizzZmcj8IXwsR5h+I3YqRunf8nh7nImYOXKNwOxBSQG9L3aH1Ca7rv/nhbJEFpTXlqcDf/HIYZBNvx4U1IiBUy1SnyE4S99OhP0GQUdW01w5hEpqOLvS9RrbAQDHxo1VgV3Y+p8vsjtFORcNVElUsKgUl90TnGAgW+yfzTcVncvGP5g/Y7Ln2j1TLlJJOzgYjjPic94DQPAM4g84sK0+tqE27AMnbzi0x0dnU5fH+W8TkrF2CjhhWvw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com;
 dkim=pass header.d=dell.com; arc=none
Received: from PH0PR19MB4938.namprd19.prod.outlook.com (2603:10b6:510:94::9)
 by BLAPR19MB4484.namprd19.prod.outlook.com (2603:10b6:208:29c::6) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.13; Mon, 14 Nov
 2022 06:50:20 +0000
Received: from PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::2674:57b2:996:111b]) by PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::2674:57b2:996:111b%3]) with mapi id 15.20.5813.017; Mon, 14 Nov 2022
 06:50:20 +0000
From: "Chen, Alvin W" 
To: Mike Karels 
CC: freebsd-current 
Subject: RE: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Thread-Topic: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Thread-Index: AdjptCu1BUq3xWQjS9a169SAwDUljwAYvyqAA3ddajA=
Date: Mon, 14 Nov 2022 06:50:20 +0000
Message-ID: 
 
References: 
 
 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Enabled=true;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SetDate=2022-11-14T06:50:17Z;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Method=Standard;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Name=No Protection (Label
 Only) - Internal Use;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ActionId=1c67bad4-422f-4715-99cb-5c937a7fa09b;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ContentBits=2
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR19MB4938:EE_|BLAPR19MB4484:EE_
x-ms-office365-filtering-correlation-id: f932cc5b-0099-4009-b7d1-08dac60c7f7f
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 EpILwjrmhxajOJCBJ1T9PMA+DNkT5VqfXSrhNPjiaG8ZSYBC0mxoQNwmnKV0hDo0Hm1QhiumD69Rs1mhgMFzso+2u/eR8/CdxG2JjxCsfXKN2oIG8ekG3N5D1m/Npa9C3/BKCt+XCKKw3zgfge+fPN+9PZYOCtIRFL6F7pa2dZrP7FWzo9k14h7u4mh1g+URc2uV/SnHz1aphCwih8YZ0t5epWt6SDIDIH3bgExv6/8KdtwWO0PdM5hpWeIGqwPWKzab4i6I0UUWU6XET43bSnQODWGL1FXQfxGsDJgIi6h5L4/SJjgC0Vw2mX+zk8K9lsA6KUOncCwQOgxGZykHGKpK3GMDIrzr7ewYJ1A8sEXGuyNgD8jTICshiAz7C+1/3/DCa0hayyDigFQ/UjnPlV8/nUk2v+dGG+TSqfA+iipfHJ6wW4YbWkZp3s2LxJ6xvuXRPXfs11BMCurZTyeA5+hDSs1hUsadxxf36g8cDNVXylTzRLoHfMgLyXRcQBm3uMlCEilPMEfAQHb9IeDzzfPrEO3S5HsGtCbOlPxc+1/Fy05vDFPUxwYPON5ycACbakYYbPihiD9juTPBsBovqDjXGFaJH1hH2dO73fFzOjzhAUjcuwvQPtJuvW0D9/ZqFVWDb+NPadMQPCM7uqfqt22dNtiier6g0p/dQPYaN1JtV7UeGy5EoohpexM5YYvg6tWvmeoVYAGXrQ6lzUlXtxCU3tr0shwF48ci+dYSC8hGMHsd61qby0hw236qn+A6rTFSscxe5hutk4MInJitdg==
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR19MB4938.namprd19.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(396003)(346002)(366004)(136003)(39860400002)(376002)(451199015)(82960400001)(38070700005)(33656002)(86362001)(478600001)(55016003)(83380400001)(38100700002)(122000001)(2906002)(9686003)(26005)(6506007)(7696005)(53546011)(52536014)(6916009)(71200400001)(8936002)(66446008)(786003)(316002)(5660300002)(186003)(41300700001)(66476007)(4326008)(66946007)(8676002)(66556008)(76116006)(64756008);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?utf-8?B?dlZMUW0vMUpKSGlsNGpSVjF1Y28zWlFldHFERVRlcWlHSGwvYkpuUC9CY3JN?=
 =?utf-8?B?b2ZJajM4L3pnNTJaNEgxV2d5MS9oVHJtZFZjeEdmckdXN2d5QUhXdkVmbGhY?=
 =?utf-8?B?MFg0R0ZrdUlkSDlrbmkwUzk5bW9MUWIxS2N4Ty9WTVhNOXRaTTloZStYY25w?=
 =?utf-8?B?TllwSkNTckx1RHJueUZtaGdLaGNUZ2JZYncwOFZmSkVHUThNTVZRQkI0bXV3?=
 =?utf-8?B?T3RZVnRBcTZUWEZUMndpSVVTMlg1YVY0bitWaFJROG1VSmx6ekZ3KzJqaUFD?=
 =?utf-8?B?bFZMbXhOeWQrQ0ZpZlZ1OFpGWEJtL0VUYk9UV0l5bXdTUEVUSW01cUZTa2Jw?=
 =?utf-8?B?cjNZaXhLdk1rakJKN1pIOGtZZlpmUHZiR0pvMW5ncUdBZTZFa1NsQlVTeUF1?=
 =?utf-8?B?OWUzYm5LZ1FuMXBQd2ZBMUZGRE5xbmlDRzJYbENuM2VLQjdvZkhEYzVocnRI?=
 =?utf-8?B?NXZSMEpUK0Joa2VhL3NBc252bWwyR0I2Z042cmI4Mk5GMEJkWTBMSm1EZFc4?=
 =?utf-8?B?eUdiRDV5UXJWMUtBZEhNbXBITUl6OUQvdHQ0bHRhUHBQcnVOUUR1cUsxOE1G?=
 =?utf-8?B?dWd3dEdLMXRPcVk1NUpIODZXbld2OUxlcGhtdURLODFJRnBDaDgyVGoxTTFz?=
 =?utf-8?B?MzFaUFpxTzl0TE94SVB4bk52UUVhVnRlM1QwRFB1SWhVSm53ZjVnWk1LMDFB?=
 =?utf-8?B?SEgyYnRkNkZEdWlCbGxhTFQ2aEJLenhVVEExSzZtME16MElQanYvMmJmc003?=
 =?utf-8?B?VHFMVUsvS1FpV0xVRDJDZDhqVFNzclIwU09xeWpIK1dETy92L0cvaktyMjRD?=
 =?utf-8?B?ZjJoUldBdEZYWFB4WjJ0U1hNeERSQ3NXdDlhbGtOOFhhTzZOd2RUbVJld2Fp?=
 =?utf-8?B?a1FUaVJyaWkrWGFmalBrdnc4cVErT2hTb1IxejcwQ1BSbWllelZwWUdJaTJB?=
 =?utf-8?B?ZlNHeU9KMzFxSm1SL0x0ZFFyRWdlT3UyUGhySmhHcGpzUEtDdkd4NUFtK0Nw?=
 =?utf-8?B?YW53OGVUWm84OCtOenJ0UWthRTFNMVJWQ096YUJDTnJ5TVdtNkRiSDA0bkdw?=
 =?utf-8?B?WCtkU29iQUVpbTVEMkZoYUNsMGg2ODlsdUhzMU5xRWFQWVNHNmNLQnF2UW1D?=
 =?utf-8?B?aldvOThHaGZNK1VPUUZNSER1OGQ3YkdIM2xIaDF4R0dBNXRTTEVVYTlvc0Yy?=
 =?utf-8?B?bXd0U1dSYVNpcnpSRWpnRVdaL0Y4WmZaaFVzZTY4UlVBZTFpVE9FRVE3VExo?=
 =?utf-8?B?ejI2ejdCZmROMmlqd2hnQlhUS0hHN2FnQ2VlN3hoQ3NPMHNOSlFHRkFnV1M0?=
 =?utf-8?B?U3RQdXhLdGFsZkYyTHFISDZPZEVlRlh0Vk95R0NOVmllKy9uR0dQazBraXQ0?=
 =?utf-8?B?bm5oQ0FIWnV2RnI0ODF2OWRpS0w0b2FScUh6am9GZ09PUDRJVVpVV2tjbHph?=
 =?utf-8?B?RlZId3Q0YjFRRGROczBpL0cxTVVrMWJQZEEzWjRXZnBlR2JwV1Nra3BYMDB3?=
 =?utf-8?B?aUpKUlNEUytIZEZVa0lFNDNGbmZDWXlHa1A2bE5ncXY2czNHZUtDdWFvL0E5?=
 =?utf-8?B?N0pxR3VOcUdKYzdNUzhpUDZ1ZDFXNmRTZzZYSEJHRjFxRmY4S3cwSmxNY1Iw?=
 =?utf-8?B?T2ducURPNXNHYVBORmlWTWdsUktNeDN5L0UrSjhoUXRCVHJjcXViYy9vTVFz?=
 =?utf-8?B?SHU3TUtxSml2T2dNSEgxZTJrY09pdEZlQjdvWnprSmcyVmJnTGxwTnV3dHo0?=
 =?utf-8?B?cCtSSFNuVlVWVkpZNVpQWXRZY2U5NWd5NEJ4Y0JqMFM5Y3grVE1WSzVkRzNS?=
 =?utf-8?B?RE16NkQwY1BRMEN1b2VtSlRjWStNNno4bWF5RHFWN1JUdlVSMUxUVjR0aTNo?=
 =?utf-8?B?cCtUMUZtekxIVGJxNlEzTnRrMHByYXpiTDBVVEVDdmh2V3NYWXI3ZDhnbExR?=
 =?utf-8?B?eFBzTDJiY1U5dEZCeVk5S05oSGJYRkhDS2FZckRGUWpoTXZVWHRkSnd5dTh0?=
 =?utf-8?B?d09BNG9wbG9tQ01TQTkrMlBXWHZZczBYTzVNa1VEdW1uaG1EQnEzNWxRS1hy?=
 =?utf-8?B?OEp0eEZ6TDBYcGNHSDlEOUxDSm1sMVM0RkM3d3RDVHNJWUp2V3hsMldLbUZa?=
 =?utf-8?Q?qVQDklIHOPKyomyMCVzB0KU8J?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR19MB4938.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f932cc5b-0099-4009-b7d1-08dac60c7f7f
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2022 06:50:20.7174
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rWiL4ltiK4r3VEjszMxxLbQL9Pz9q60e7pHqB8usw7s9RW8xTZwdqp/wdFfhJBTuhaz0Bk7pliAg01MxTOGjjA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR19MB4484
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-11-14_06,2022-11-11_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 suspectscore=0
 mlxscore=0 mlxlogscore=999 clxscore=1015 priorityscore=1501 phishscore=0
 adultscore=0 impostorscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000
 definitions=main-2211140050
X-Proofpoint-ORIG-GUID: FZZKxiOYVPmSXxtmImfQzHHAROEX_XvI
X-Proofpoint-GUID: FZZKxiOYVPmSXxtmImfQzHHAROEX_XvI
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0
 phishscore=0 mlxlogscore=999 spamscore=0 mlxscore=0 bulkscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2211140050
X-Spamd-Result: default: False [-5.10 / 15.00];
	WHITELIST_SPF_DKIM(-3.00)[dell.com:d:+,Dell.com:s:+];
	ARC_REJECT(1.00)[signature check failed: fail, {[1] = sig:microsoft.com:reject}];
	DWL_DNSWL_LOW(-1.00)[dell.com:dkim];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[dell.com,reject];
	R_DKIM_ALLOW(-0.20)[dell.com:s=smtpout1];
	RCVD_IN_DNSWL_LOW(-0.20)[67.231.149.39:received,148.163.133.20:from];
	R_SPF_ALLOW(-0.20)[+ip4:148.163.133.20];
	MIME_GOOD(-0.10)[text/plain];
	MIME_BASE64_TEXT(0.10)[];
	DKIM_TRACE(0.00)[dell.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:26211, ipnet:148.163.133.0/24, country:US];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_SEVEN(0.00)[7];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_IN_DNSWL_NONE(0.00)[104.47.55.169:received];
	RWL_MAILSPIKE_POSSIBLE(0.00)[148.163.133.20:from]
X-Rspamd-Queue-Id: 4N9g1G0cq4z4PHj
X-Spamd-Bar: -----
X-ThisMailContainsUnwantedMimeParts: N

DQoNCkludGVybmFsIFVzZSAtIENvbmZpZGVudGlhbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4gRnJvbTogTWlrZSBLYXJlbHMgPG1pa2VAa2FyZWxzLm5ldD4NCj4gU2VudDog
MjAyMuW5tDEw5pyIMjfml6UgMjM6MTcNCj4gVG86IENoZW4sIEFsdmluIFcNCj4gQ2M6IGZyZWVi
c2QtY3VycmVudA0KPiBTdWJqZWN0OiBSZTogU3RhdHVzIG9mIEludGVsIEh5YnJpZCBDUFUgc3Vw
cG9ydCAoQWxkZXIgTGFrZS9SYXB0b3IgTGFrZSkNCj4gc3VwcG9ydA0KPiANCj4gDQo+IFtFWFRF
Uk5BTCBFTUFJTF0NCj4gDQo+IE9uIDI2IE9jdCAyMDIyLCBhdCAyMjoyOSwgQ2hlbiwgQWx2aW4g
VyB3cm90ZToNCj4gDQo+ID4gQW55IGJvZHkga25vdyB0aGUgc3RhdHVzIHRvIHN1cHBvcnQgUCBD
b3JlIGFuZCBFIENvcmU/DQo+ID4gTm93IFdBIGlzOiBkaXNhYmxlIFBDSUQuDQo+IA0KPiBEaXNh
Ymxpbmcgdm0ucG1hcC5wY2lkX2VuYWJsZWQgaXMgdGhlIGJlc3Qgd29ya2Fyb3VuZCBmb3Igbm93
Lg0KPiBUaGVyZSBoYXMgYmVlbiBzb21lIHByb2dyZXNzIGluIGludmVzdGlnYXRpb25zIGluIHRo
ZSBiYWNrZ3JvdW5kLCBidXQgSSBkb27igJl0DQo+IHRoaW5rIHRoZXJlIGlzIGEgcGVybWFuZW50
IHNvbHV0aW9uIHlldC4NCj4gDQo+IGJ0dywgSSBoYXZlbuKAmXQgaGVhcmQgcmVwb3J0cyBhYm91
dCBSYXB0b3IgTGFrZSB5ZXQuICBEbyB5b3Uga25vdyBpZiBpdCBoYXMgdGhlDQo+IHNhbWUgcHJv
YmxlbXMgYXMgQWxkZXIgTGFrZSBvbiBoeWJyaWRzPyAgSSB3b3VsZCBndWVzcyBpdCBkb2VzLg0K
PiANCg0KSSBnZXQgb25lIFJQTC1TIERWVCwgYW5kIGl0IGhhc24ndCBtb2RlIG5hbWUgeWV0IGFz
IGl0IGlzIHRoZSBlbmdpbmVlcmluZyBDUFUgaW50ZWwgcHJvdmlkZWQgZm9yIHZhbGlkYXRpb24u
DQpCYXNlZCBvbiBteSB0ZXN0aW5nLCB0aGUgaXNzdWUgaXMgc3RpbGwgdGhlcmU6DQoNCiJCb290
IHRvIHNoZWxsIGJ5IFVTQiBkaXNrIGluc3RhbGxlciwgYW5kIG1vdW50IGEgRkFUMzIgcGFydGl0
aW9uIChvbiBTU0QpLCBhbmQgY29weSBhIDMwME1CIGZpbGUgdG8gdGhlIEZBVDMyLCBjb21wYXJl
IHRoZSBzaGEyNTYgY2hlY2tzdW1zIGZvciB0aGUgc291cmNlIGZpbGUgYW5kIHRoZSBkc3QgZmls
ZSwgdGhlIGNoZWNrc3VtIGFyZSBkaWZmZXJlbnQuIg0K

From nobody Mon Nov 14 07:09:24 2022
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 4N9gYC0rKRz4hJCg
	for ; Mon, 14 Nov 2022 07:14:39 +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 4N9gYB3YBPz4RfR
	for ; Mon, 14 Nov 2022 07:14:38 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 2AE79OqJ026428
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 14 Nov 2022 09:09:27 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 2AE79OqJ026428
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 2AE79Oef026426;
	Mon, 14 Nov 2022 09:09:24 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Mon, 14 Nov 2022 09:09:24 +0200
From: Konstantin Belousov 
To: "Chen, Alvin W" 
Cc: Mike Karels ,
        freebsd-current 
Subject: Re: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
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=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home
X-Rspamd-Queue-Id: 4N9gYB3YBPz4RfR
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Nov 14, 2022 at 06:50:20AM +0000, Chen, Alvin W wrote:
> 
> 
> Internal Use - Confidential
> 
> 
> > -----Original Message-----
> > From: Mike Karels 
> > Sent: 2022年10月27日 23:17
> > To: Chen, Alvin W
> > Cc: freebsd-current
> > Subject: Re: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
> > support
> > 
> > 
> > [EXTERNAL EMAIL]
> > 
> > On 26 Oct 2022, at 22:29, Chen, Alvin W wrote:
> > 
> > > Any body know the status to support P Core and E Core?
> > > Now WA is: disable PCID.
> > 
> > Disabling vm.pmap.pcid_enabled is the best workaround for now.
> > There has been some progress in investigations in the background, but I don’t
> > think there is a permanent solution yet.
> > 
> > btw, I haven’t heard reports about Raptor Lake yet.  Do you know if it has the
> > same problems as Alder Lake on hybrids?  I would guess it does.
> > 
> 
> I get one RPL-S DVT, and it hasn't mode name yet as it is the engineering CPU intel provided for validation.
> Based on my testing, the issue is still there:
> 
> "Boot to shell by USB disk installer, and mount a FAT32 partition (on SSD), and copy a 300MB file to the FAT32, compare the sha256 checksums for the source file and the dst file, the checksum are different."

You might use this patch meantime
https://kib.kiev.ua/git/gitweb.cgi?p=deviant3.git;a=commit;h=5d72240a8777b26d5e0a7d2d26bb919d05f60002

From nobody Mon Nov 14 17:48:12 2022
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 4N9xcN3PgKz4hdwx
	for ; Mon, 14 Nov 2022 17:48:20 +0000 (UTC)
	(envelope-from verm@darkbeer.org)
Received: from mx.coeval.ca (mx.coeval.ca [184.75.211.21])
	(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 4N9xcM3fNPz4KxM
	for ; Mon, 14 Nov 2022 17:48:19 +0000 (UTC)
	(envelope-from verm@darkbeer.org)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=darkbeer.org header.s=mail header.b="HefJVN/U";
	spf=pass (mx1.freebsd.org: domain of verm@darkbeer.org designates 184.75.211.21 as permitted sender) smtp.mailfrom=verm@darkbeer.org;
	dmarc=none
Received: from mx.darkbeer.org (unknown [192.168.211.20])
	by mx.coeval.ca (Postfix) with ESMTP id C469F43605D
	for ; Mon, 14 Nov 2022 17:48:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbeer.org; s=mail;
	t=1668448092; bh=SzKRnI4XvyeiygTE3+z/VthWL4VQG0fMV636svNrX1A=;
	h=Date:From:To:Subject:References:In-Reply-To;
	b=HefJVN/USWmwMfo41SH3+m70uRyDBWbd/XTSsRZj0BjYpqRjhuHiptvHaV/y2jqCe
	 frLklubWebbaNcPdKTRrpK/8BXAc6adEtrrpJGuaGBaxnBbYDiPOVDYrQ8njS7x5Re
	 St97myNCbwNCHvfFfpg2UQ7Y5O08UQEJJqrnUKhg=
Received: by mx.darkbeer.org (Postfix, from userid 1001)
	id BD63B470BFC; Mon, 14 Nov 2022 17:48:12 +0000 (UTC)
Date: Mon, 14 Nov 2022 17:48:12 +0000
From: Amar Takhar 
To: freebsd-current@freebsd.org
Subject: Re: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Message-ID: <20221114174812.GA20495@darkbeer.org>
Mail-Followup-To: freebsd-current@freebsd.org
References: 
 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Spamd-Result: default: False [-1.45 / 15.00];
	NEURAL_HAM_SHORT(-0.95)[-0.946];
	R_DKIM_ALLOW(-0.20)[darkbeer.org:s=mail];
	R_SPF_ALLOW(-0.20)[+ip4:184.75.211.21];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	DKIM_TRACE(0.00)[darkbeer.org:+];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[darkbeer.org];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:32489, ipnet:184.75.211.0/24, country:CA];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4N9xcM3fNPz4KxM
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

On 2022-11-14 09:09 +0200, Konstantin Belousov wrote:
> 
> You might use this patch meantime
> https://kib.kiev.ua/git/gitweb.cgi?p=deviant3.git;a=commit;h=5d72240a8777b26d5e0a7d2d26bb919d05f60002

I know this is -CURRENT but will this work on 13.1 as well?  I use that as my 
main workstation.

Also does vm.pmap.pcid_enabled need to be set to 0 still?

Hopefully this fixes the sound issues as well right now I have all my E-cores 
disabled but sound issues persist.

Thanks!


Amar.

From nobody Mon Nov 14 21:07:17 2022
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 4NB2251Vtpz4dMsH
	for ; Mon, 14 Nov 2022 21:07:25 +0000 (UTC)
	(envelope-from dan@sunsaturn.com)
Received: from sunsaturn.com (sunsaturn.com [IPv6:2604:4300:a:196::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 (2048 bits) client-digest SHA256)
	(Client CN "sunsaturn.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NB22433mNz3hT9;
	Mon, 14 Nov 2022 21:07:24 +0000 (UTC)
	(envelope-from dan@sunsaturn.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=sunsaturn.com header.s=default header.b=gfRr1UtF;
	spf=pass (mx1.freebsd.org: domain of dan@sunsaturn.com designates 2604:4300:a:196::3 as permitted sender) smtp.mailfrom=dan@sunsaturn.com;
	dmarc=none
Received: by sunsaturn.com (Postfix, from userid 1001)
	id 9CF6293ED; Mon, 14 Nov 2022 15:07:17 -0600 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunsaturn.com;
	s=default; t=1668460037;
	bh=Rh8jyXuH+CWYMhNdXl1JcCeZirWG8Ivplja9AImsJiw=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=gfRr1UtF/6gn7Mb/+rkaiMr+4NTNBVHROUtCCcvFwrNpo2zHiuEF1FR4yd6pZ9yqp
	 cVB1nWO4b5q3ng25V0GSIoKDx6m2GVpyEJBrZd47rTX3pFE1T7O5P5SyF1OOpE/KZz
	 /ERuGpj0a/nfWVEvErUDe4+FwZKDxLcHnabFxXfk=
Received: from localhost (localhost [127.0.0.1])
	by sunsaturn.com (Postfix) with ESMTP id 9AA2494F0;
	Mon, 14 Nov 2022 15:07:17 -0600 (CST)
Date: Mon, 14 Nov 2022 15:07:17 -0600 (CST)
From: Dan The Man 
To: Alexander Motin 
cc: freebsd-current@FreeBSD.org
Subject: Re: vfs.zfs.vol.recursive hang makes it impossible to mount zvol
In-Reply-To: <62348dc1-7f9a-f8ae-db77-f2f5d8a709d8@FreeBSD.org>
Message-ID: <8c9459bc-a15d-3b73-9ad5-1227372b7e14@sunsaturn.com>
References:  <62348dc1-7f9a-f8ae-db77-f2f5d8a709d8@FreeBSD.org>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1969398039-1361763688-1668460037=:67313"
X-Spamd-Result: default: False [-0.50 / 15.00];
	CTYPE_MIXED_BOGUS(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip6:2604:4300:a:196::3];
	R_DKIM_ALLOW(-0.20)[sunsaturn.com:s=default];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	MIME_TRACE(0.00)[0:+,1:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:33387, ipnet:2604:4300::/32, country:US];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[dan];
	DKIM_TRACE(0.00)[sunsaturn.com:+];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[sunsaturn.com: no valid DMARC record];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NB22433mNz3hT9
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1969398039-1361763688-1668460037=:67313
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT



https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267769

I'm just going to submit bug this way, I do like fact I can mount ZFS 
guests now, and I love being able to pass through multiple disks through 
with one line to bhyve such as :
-s 4:0,virtio-scsi,/dev/cam/ctl1.0

very handy, and very organized especially if someone wanted to pass 10 
devices through to a guest with a 1 liner to bhyve.

I am not sure what is happening after resume, would be disheartening to 
have to go back to virtio-blk :( Think virtio-blk being phased out to 
virtio-scsi from what I have read.


Dan.

--
Dan The Man
CEO & Founder
Websites, Domains and Everything else
http://www.SunSaturn.com/aboutus.php
Email: Dan@SunSaturn.com
PGP Key: https://SunSaturn.com/pgp.txt
A1A7 6E84 FB0B 8994 C3B5  A1BA FF6F 4997 7311 C386

On Mon, 7 Nov 2022, Alexander Motin wrote:

> On 07.11.2022 18:53, Dan The Man wrote:
>> router:~ # sysctl vfs.zfs.vol.recursive=1
>> vfs.zfs.vol.recursive: 0 -> 1
>> router:~ # zpool import
>>     pool: testing
>>       id: 8013833172609421701
>>    state: ONLINE
>>   action: The pool can be imported using its name or numeric identifier.
>>   config:
>>
>>          testing                   ONLINE
>>            zvol/zroot/asterisk2p3  ONLINE
>> router:~ # zpool import -fR /mnt testing
>> 
>> This hangs forever....
>> The only way to import that pool from the zvol that I know of.....
>
> Mounting ZFS from ZVOLs is blocked for a reason.  It causes deadlocks due to 
> lock recursion.  I don't know what you are trying to achieve, but as 
> alternatives, the ZVOL can be passed inside VM, it can be shared via iSCSI 
> (even inside the host itself), etc.
>
> -- 
> Alexander Motin
>
--1969398039-1361763688-1668460037=:67313--

From nobody Tue Nov 15 07:49:55 2022
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 4NBJHY5DlZz4hFGp
	for ; Tue, 15 Nov 2022 07:50:01 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20])
	(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 4NBJHY09KRz3pMq;
	Tue, 15 Nov 2022 07:50:00 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from pps.filterd (m0170394.ppops.net [127.0.0.1])
	by mx0b-00154904.pphosted.com (8.17.1.19/8.17.1.5) with ESMTP id 2AF4Q5Ju003415;
	Tue, 15 Nov 2022 02:49:58 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=smtpout1;
 bh=pAfCrOvvbbtA9xjQOM9IA01s7dRT1bwGZOnkzrFjnro=;
 b=aNqIWqGdQHKGRV8ZhXlTAILhswwamSD1Cv5MrgFHUz5iKKcY0l9icEwXqX3t0mU3SJEY
 JuCKv7omwkfpPkZL+zCgujpTNOQponGviaymIp+VE1f2oWdTG8yqr58y4QlyE5gmqoDC
 OmnO/b+LTLquICGqmWTe5rsAQcaYPQHdEgUQAVJcKcCKb4hvpz31tCK8DVKczlaHew2R
 xY/wVf+aE35+ZbfoJfMB49OovY3RP5jZmR7v+TYhJkFJgxHk4gwH813HrSPS2Xx7U2ks
 oSZszqxa+BBBxfOJjpLTzr10fIGtQNhoX0zyJMnpqnwST2rsXXwuSVXScPNvWrejCHH9 yw== 
Received: from mx0a-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37])
	by mx0b-00154904.pphosted.com (PPS) with ESMTPS id 3kv3r58r5c-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
	Tue, 15 Nov 2022 02:49:58 -0500
Received: from pps.filterd (m0089484.ppops.net [127.0.0.1])
	by mx0b-00154901.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AF7mCuh020006;
	Tue, 15 Nov 2022 02:49:58 -0500
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2047.outbound.protection.outlook.com [104.47.66.47])
	by mx0b-00154901.pphosted.com (PPS) with ESMTPS id 3kv6pv82c2-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
	Tue, 15 Nov 2022 02:49:58 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ApEcVcD6qeIyEFOn5z73lZ5rFPY1OqqAY4uJ1FAWz3eo++F3axqYh6siQfYw4iqypHwjx9g5cdE8v4NBim+bDNVzEDBtynP7Mmc4mJhdH6ajjro08OMhBtEn0SIaGvHxo6Ie9iFhrx7TQjFDWgd/XB+5wq7543xzIBFRnCtQUqxfrzc4Po9R0W8cGtUTUc+muHIMubCE9BZqGgi29/4xw3dxZ/vAtMCew3DUREVyT6KK5fnPCOy0NwMVk9zufOBBv1Y71PHVDXaG8BB2WCPyBAMGPKUGvu+blJHHxOy9SynmgxKEojKgRVyYSHbRcIsIQYIrOL+VSYYNDwfyGFcBBA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=pAfCrOvvbbtA9xjQOM9IA01s7dRT1bwGZOnkzrFjnro=;
 b=CYJvyAXS8fq3M0q5MISaQZzS3xeKbIdEcI/R70O1F/zL4mT4X93F6UyLPjaxsoJ7ccDj157/0Lvs00egQmQAOnzvbzM8f/4X9eVBFOkQJ2jCnsRVDf8HQ4n2kZUJiYdUP9LqSk339ExRZLq37hvaj5BUCQgnYCbYQ6yN5d0V/7YizKJl/e7lJCvpEZOhBH0BW5kUe1cZattyZqyTHrX1Cjv7grODMLJQE+FLk1wNH1Gsb69WISRS0BYzG9mUxrlvxNgx6Ant0lh1g4if3Zb3zCWWMk5npOzN8OZ1somK/+Oc/fO7r4Q29M0vPhFLTrUVo8fOFGlDhT1p6x4eP+imnQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com;
 dkim=pass header.d=dell.com; arc=none
Received: from PH0PR19MB4938.namprd19.prod.outlook.com (2603:10b6:510:94::9)
 by SA0PR19MB4286.namprd19.prod.outlook.com (2603:10b6:806:91::23) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.13; Tue, 15 Nov
 2022 07:49:55 +0000
Received: from PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::2674:57b2:996:111b]) by PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::2674:57b2:996:111b%3]) with mapi id 15.20.5813.018; Tue, 15 Nov 2022
 07:49:55 +0000
From: "Chen, Alvin W" 
To: Konstantin Belousov 
CC: Amar Takhar ,
        "freebsd-current@freebsd.org"
	
Subject: RE: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Thread-Topic: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Thread-Index: AdjptCu1BUq3xWQjS9a169SAwDUljwAYvyqAA3ddajAAANodAAAWT1EAAByl5KA=
Date: Tue, 15 Nov 2022 07:49:55 +0000
Message-ID: 
 
References: 
 
 
 
  <20221114174812.GA20495@darkbeer.org>
In-Reply-To: <20221114174812.GA20495@darkbeer.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Enabled=true;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SetDate=2022-11-15T07:49:53Z;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Method=Standard;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Name=No Protection (Label
 Only) - Internal Use;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ActionId=084008f3-ece7-4810-839a-662a34e148b4;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ContentBits=2
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR19MB4938:EE_|SA0PR19MB4286:EE_
x-ms-office365-filtering-correlation-id: 73f18f50-167a-4bbf-e5da-08dac6ddfc6e
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 UG8B6cICKJfLAufa1rPvsyt2g3vApiO3IPJJeWPLvTKXPy8T+TQP2j/88aR+buXQjcs91vY3KBsVPVLDWjYpziBMxEBmcwwPVPdlQJh40m1zGbw+Rzz13QqFLPxLDZrCsSCRINBRQ5zcb3bWiq3Jg+y/JqCY4x40VU0DbtJieDsvTl7R4ZjFnQ9huYt9xTgxSW5Jvm5OiRMzFeY5gETsSwsm3PsvyhDrRGBFcknGgOdNlnWievGFo3p8XTVZX+TjD0AHiTGFOdDxRb252DsAvepiiDsZlytC7OGTzPyThTorejWRkhX+BCpKfaJ09C9AlMOpPoEF87BdV1iTXDVCziuyT5oEa7pSJbCjUhiGxNfPbZAUGl7hx0EfINxalLqLCP5YqF18irgUePRz0IWjBSqHqtbSDRnCzyRHnt852NnuOaxJxkRSgqiDxNokMlmfIOcbZsTLijRidK6xrVlv8KrCjGkbrxqQOOQrrjDRVD0UzY2BdCl8nq9Vv5L+2Yb5YSsAKMQdD64VaIAzFphytdXPQ4cEfQxi0AZAOoFeqMwvQfLu7zeqePyIwMqPLRem6Y3rOTRK2TZmSroBmkelxagKYycapdTUgkqdrb7VQVI9V0ifFnTOLG5VwPfg5++RwGPMqbcfZaERcZCpkoVgTnUd8e9nL88DzZSbAwHSRA3bg77ldxeEC3QWZWRtfAGm7vz78AK8eVl8cCHAdJhsBb+slmqsxuXgWh591nqFDEmM/VLPjhiszOmhpkxGN2cHc3K4c1nzFc/rZTS58wkjkSBHKYWE7Qc6/zAiMVmqm2U=
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR19MB4938.namprd19.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(376002)(396003)(39860400002)(366004)(346002)(136003)(451199015)(26005)(76116006)(66946007)(66556008)(66476007)(66446008)(64756008)(9686003)(786003)(316002)(6916009)(8676002)(19627235002)(52536014)(8936002)(5660300002)(186003)(4326008)(53546011)(41300700001)(7696005)(54906003)(6506007)(83380400001)(4001150100001)(2906002)(86362001)(82960400001)(38100700002)(38070700005)(33656002)(55016003)(122000001)(966005)(478600001)(71200400001);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?zF82ToCXDRJdQFxmyglswHNDA4msCnbA/at6VlH9NbRcvqWQSHpqMyTtbHot?=
 =?us-ascii?Q?722P8L4GsrOpH/EC4lQD6NxHwClTLWlTNadhaHoIt24cLzwmZz/7Tz7dJoeh?=
 =?us-ascii?Q?k0NMJnofPixxWeFt/VyJe23UJ7K1V2Z6xHg4PsshGbGuUyC3kRXl+j8j1vmR?=
 =?us-ascii?Q?2g27VpU6exa+M33XRe3qQrjH9sD1cWb0P8+IQtGXIe8pWpXLFXJOjKsMSdtP?=
 =?us-ascii?Q?uRNFty26XIWYdvfycaTKWIUDqxUyRNhnd4suAn9bayHVPu3qUmrYfrTnr93m?=
 =?us-ascii?Q?aRV6zXKRsWbZJpvHzcsvVDHJavaW/7uolNCeNPZ28fwDcGKZkFv7Vi37ytP2?=
 =?us-ascii?Q?liDQSgmozd0IHZK3nDgrE9QuxG7dy4uJrY9RyXoie00nf29zwQeFTUQ4BQq5?=
 =?us-ascii?Q?bOZcGQuDxDokvM8Uet+GPDzZ6hdtYCI3FFEjUzg4ZvF74YgLKLeW5Y/J4coJ?=
 =?us-ascii?Q?hVR+OdvWPpqF+dMZIer7rqXftYXu/08leaglR4FvkMlGWiy+6i9Gp/b+9rfC?=
 =?us-ascii?Q?wI2moUXqdFEaWpJNOiPDbt8v81eVa1phOTGp7p7kaswkjratQpRXVviPyeY9?=
 =?us-ascii?Q?ItRgRnJ1Ml/NYKnDj4saW31JASnPAAXofWg4KZvTFED7hap7zt7IrUh2ASUF?=
 =?us-ascii?Q?uVz4JfBpHm9L4BTztvQAV8uVEm720PGMlgBnILLGVkPKba3iG3Adys/f2sSW?=
 =?us-ascii?Q?r/BA5m7wAmvSpi4bT1kn4CGubK9r2t2wDU41/TGnbCZEQhdHkTbX7NtBa5Rn?=
 =?us-ascii?Q?2m1bEeSUcYNy96qY5aTI/3L2M6oWR4LLrCzW5QdtSy41WiP6tw20OyCaXhol?=
 =?us-ascii?Q?2gfdJZEVC/0RS6mTJdgWFbgCNCWAZpAo1wGAPBvvsE80M8LAipelFqWS8jgL?=
 =?us-ascii?Q?IxeJA7UqSNEv6yvd7niGHaRqxRVkEYdieDdmSwso6YHVXNCiR8Mm5l0wxiBz?=
 =?us-ascii?Q?090Dpr0pWvJDu3wKbfnSP+H51RYea+Pz1DPOKs06HPmR6aZ/GpMMCr5ubRq2?=
 =?us-ascii?Q?sUtfPCzBul3JNpjjbYokiB5SZqwO4edQijMNTn6myocq6KL4CIkPintkQE5y?=
 =?us-ascii?Q?i3ri8w4/ryHP9nSEoxeB3D6gn8HSh11u6R2oXE2eYfcHEGFcjV5HhdiVJ6vb?=
 =?us-ascii?Q?x684ckbvAGW4Y1qn8KJ00U824XN1y8dpv63Z+wC2lo0rqAmkMe8m/w5ODPX3?=
 =?us-ascii?Q?0okNwFgE548HttySmw7VxgefngxUjS+cuj+TpjfVFQGiP0RMvtMfO3vtvsz7?=
 =?us-ascii?Q?6IB+sqziT1jOWIlJZxzkLVQlkwUZUHaRAwA7cxEad4bxH8xu63rtDPnXsrCv?=
 =?us-ascii?Q?QmDxbprWCwTRFb7ltSD3CT1xxoOQXLUZtaBDLGoJIlTyVJQDlJntkeQuWZYe?=
 =?us-ascii?Q?7QKQmRpA2mYYAU6XX0Wxu8ojYVE9ZO/xaQzFMM68WmeM87Tty6IsRsOGvIn0?=
 =?us-ascii?Q?uGldl1XZ/0cVL8XxokZA8O42FeUbgXXDXa7O2Z4tnYC26rL4ELcOYtriulB6?=
 =?us-ascii?Q?rI9yPG4+u7mNctFfr6Oa0rYxqkkCl6WAM9s8X1xuOnu8OhpfF5YD2DfZdRxb?=
 =?us-ascii?Q?mSt5ySV6XR6eGtveaMU228PwibBzG5UbsBy6+cOl?=
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
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR19MB4938.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 73f18f50-167a-4bbf-e5da-08dac6ddfc6e
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2022 07:49:55.1232
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fjwfvWM9/ghKyNZJOLUgYOiPftePyVpeabVT+5/f1zh81R6QkwfFyFoLvBU1e/s/yU2okA6qjGIRT6rSJhyDVQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR19MB4286
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-11-15_02,2022-11-11_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501
 bulkscore=0 clxscore=1011 lowpriorityscore=0 malwarescore=0 suspectscore=0
 phishscore=0 mlxlogscore=990 adultscore=0 impostorscore=0 mlxscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2211150056
X-Proofpoint-ORIG-GUID: SzrlZfY0qcbb_K3zGev9C6qTugLG5Pvs
X-Proofpoint-GUID: SzrlZfY0qcbb_K3zGev9C6qTugLG5Pvs
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 bulkscore=0
 malwarescore=0 mlxlogscore=999 mlxscore=0 spamscore=0 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000
 definitions=main-2211150056
X-Rspamd-Queue-Id: 4NBJHY09KRz3pMq
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:22843, ipnet:148.163.137.0/24, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Kongstantin,

I am not familiar with TLB part implementation for BSD. Based on your patch=
, it looks like disable PCID or force flush TLB for E core. Is that right?
Would you mind explain a little more to help understand the code?


Internal Use - Confidential

> -----Original Message-----
> From: owner-freebsd-current@freebsd.org  current@freebsd.org> On Behalf Of Amar Takhar
> Sent: Tuesday, November 15, 2022 1:48 AM
> To: freebsd-current@freebsd.org
> Subject: Re: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
> support
>=20
>=20
> [EXTERNAL EMAIL]
>=20
> On 2022-11-14 09:09 +0200, Konstantin Belousov wrote:
> >
> > You might use this patch meantime
> > https://urldefense.com/v3/__https://kib.kiev.ua/git/gitweb.cgi?p=3Ddevi=
a
> >
> nt3.git;a=3Dcommit;h=3D5d72240a8777b26d5e0a7d2d26bb919d05f60002__;!!LpKI
> !g
> > -6xRexMgrS7blkbBAEW-CU6xx2soVgqJcn34v5a-
> vYybodWNslFhcgFr631abOyXATJf_r
> > ACTtzog$ [kib[.]kiev[.]ua]
>=20
> I know this is -CURRENT but will this work on 13.1 as well?  I use that a=
s my
> main workstation.
>=20
> Also does vm.pmap.pcid_enabled need to be set to 0 still?
>=20
> Hopefully this fixes the sound issues as well right now I have all my E-c=
ores
> disabled but sound issues persist.
>=20
> Thanks!
>=20
>=20
> Amar.

From nobody Tue Nov 15 16:05:34 2022
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 4NBWHM5wXBz4h6G3
	for ; Tue, 15 Nov 2022 16:05:35 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Received: from www.zefox.net (www.zefox.net [50.1.20.27])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NBWHL6Ntmz3nds
	for ; Tue, 15 Nov 2022 16:05:34 +0000 (UTC)
	(envelope-from fbsd@www.zefox.net)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net;
	dmarc=none
Received: from www.zefox.net (localhost [127.0.0.1])
	by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 2AFG5YaU000394
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Tue, 15 Nov 2022 08:05:35 -0800 (PST)
	(envelope-from fbsd@www.zefox.net)
Received: (from fbsd@localhost)
	by www.zefox.net (8.16.1/8.15.2/Submit) id 2AFG5YLr000393
	for freebsd-current@freebsd.org; Tue, 15 Nov 2022 08:05:34 -0800 (PST)
	(envelope-from fbsd)
Date: Tue, 15 Nov 2022 08:05:34 -0800
From: bob prohaska 
To: freebsd-current@freebsd.org
Subject: Turning security email back on
Message-ID: <20221115160534.GA386@www.zefox.net>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spamd-Result: default: False [1.71 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-0.98)[-0.981];
	NEURAL_SPAM_MEDIUM(0.80)[0.795];
	MID_RHS_WWW(0.50)[];
	WWW_DOT_DOMAIN(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US];
	R_SPF_NA(0.00)[no SPF record];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DMARC_NA(0.00)[zefox.net];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NBWHL6Ntmz3nds
X-Spamd-Bar: +
X-ThisMailContainsUnwantedMimeParts: N

It looks as if daily email reporting login failures and system status
are no longer being sent out on -current. Is there a switch for 
/etc/rc.conf that will turn them back on? 

Thanks for reading,

bob prohaska


From nobody Tue Nov 15 16:22:55 2022
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 4NBWgX2FhXz4h8yd
	for ; Tue, 15 Nov 2022 16:23:04 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NBWgW6BT2z3r38
	for ; Tue, 15 Nov 2022 16:23:03 +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 2AFGMtW6076760;
	Tue, 15 Nov 2022 08:23:01 -0800 (PST)
	(envelope-from bsd-lists@bsdforge.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
Date: Tue, 15 Nov 2022 08:22:55 -0800
From: Chris 
To: bob prohaska 
Cc: freebsd-current@freebsd.org
Subject: Re: Turning security email back on
In-Reply-To: <20221115160534.GA386@www.zefox.net>
References: <20221115160534.GA386@www.zefox.net>
User-Agent: UDNSMS/17.0
Message-ID: 
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_88409390ff0e1666311884b4265adf8c"
X-Rspamd-Queue-Id: 4NBWgW6BT2z3r38
X-Spamd-Bar: ----
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-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--=_88409390ff0e1666311884b4265adf8c
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-11-15 08:05, bob prohaska wrote:
> It looks as if daily email reporting login failures and system status
> are no longer being sent out on -current. Is there a switch for
> /etc/rc.conf that will turn them back on?
Isn't this facilitated in periodic(8)

HTH

--Chris
> 
> Thanks for reading,
> 
> bob prohaska

--=_88409390ff0e1666311884b4265adf8c
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_88409390ff0e1666311884b4265adf8c--

From nobody Tue Nov 15 16:25:40 2022
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 4NBWkc1Gmcz4h971
	for ; Tue, 15 Nov 2022 16:25:44 +0000 (UTC)
	(envelope-from otis@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NBWkc0k41z3s4M;
	Tue, 15 Nov 2022 16:25:44 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1668529544;
	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=c7HJTdX5i/sEHiakoPNVDLKbKPNNnAOXZ4kQ74sMH/k=;
	b=kPe94oB3EAIpgZWRdHx6GkgYf2B6z/oj0T+mMJsJgwDw22EUvjLtbOHF/9PQ9HMR9mbzRF
	gWEyXxSVcX9eClce5SyuMEnl4lKS2rAt0DhyUtrcQqGK9eaGJkQPTOBslsjv+HYPfAOGJw
	mfnU6F4kDoBHC+C9McHgvF2V5DRDMALw7Kjw5nqYzZpm8BJQl1gtYvnl6w1Jo8pUCCzqTF
	8qf8zpg6s6AMlve7xFGDnTWqa/VVuEMrqlycsRwMWgQQy//WWpuYlkau/UcGWyfjbpaGKs
	VzNFMGhKxow15DkxTBPAbL7G6K5hW2nAcqs2xUtWznuxPAjzeGbq2P5AOGAczg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1668529544;
	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=c7HJTdX5i/sEHiakoPNVDLKbKPNNnAOXZ4kQ74sMH/k=;
	b=IpUOm4ujTchzfEFcXShJXM8czoP4PfDFSV6tPt+70yrZUtTuZ9e1EZL53GESo+ijMuegA1
	g1R1X2zLGwlTMpg0Wcidr0fG3TVgxx38GD9XZLC1rk15Y/Vdroj/KmxZ/deFlcmPwcBFXg
	1zu7FUMIigv6w48oF19O+lCxoisb/lHRDRDbarc8PqnutzP6Z9nm61pItQNNbDghI5pquG
	ADT8iamqS5NXL4LkG+bk1m9vFnBmJI5oyRkomlP0xQ3mtpb2PvEyqbuzEVCfh52Y2c8A3d
	Dbq+5UmHrEqGnKBeJCSfn89hDJxB9gdzaWQb1iTDOuzUMlVPUgfp0M2tECTKTQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668529544; a=rsa-sha256; cv=none;
	b=lacocEiRKFEACCuiJU4plBM7DtZ29xBeZ8UsMDYxeeipcSG+MtQjISv+tHlSKA356e1PuS
	4ZnCbcCcfn7vG0zwCrsfptiUiltDYjnFF42WZ12j5hHwhSochgD7KzNpQUl3Y0vZ7tYzhX
	c3wipfLm+cbATo5bqfEXmKyilmsJJeUcSlwWZquaoBd9dQ8dojUsgrZlswJ2XmRkG3PJ97
	GMwG/J8W2hW7WlMhv8KIBPV377OTb9gU8TUk+NVbC0nhUwnxCfq9i8N7/eFYXJnlQUY9mx
	mr4oVS05z+pcHHcjRgH72ixbytVf5cmghCC1GkxYdL2eun2D73JaPVhuOGB7WQ==
Received: from ns2.wilbury.net (ns2.wilbury.net [92.60.51.55])
	(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 "svc.wilbury.net", Issuer "R3" (verified OK))
	(Authenticated sender: otis)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NBWkb5vdzzdDk;
	Tue, 15 Nov 2022 16:25:43 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
Received: from smtpclient.apple (unknown [217.73.28.193])
	(Authenticated sender: juraj@lutter.sk)
	by svc.wilbury.net (Postfix) with ESMTPSA id AA12C45D27F;
	Tue, 15 Nov 2022 17:25:40 +0100 (CET)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: Turning security email back on
From: Juraj Lutter 
In-Reply-To: 
Date: Tue, 15 Nov 2022 17:25:40 +0100
Cc: bob prohaska ,
 freebsd-current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20221115160534.GA386@www.zefox.net>
 
To: Chris 
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,MAY_BE_FORGED,
	RCVD_IN_DNSWL_BLOCKED,RDNS_NONE,SPF_HELO_NONE,SPF_SOFTFAIL
	autolearn=no autolearn_force=no version=3.4.5
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on ns2.wilbury.net
X-ThisMailContainsUnwantedMimeParts: N



> On 15 Nov 2022, at 17:22, Chris  wrote:
>=20
> On 2022-11-15 08:05, bob prohaska wrote:
>> It looks as if daily email reporting login failures and system status
>> are no longer being sent out on -current. Is there a switch for
>> /etc/rc.conf that will turn them back on?
> Isn't this facilitated in periodic(8)

Moreover, there was a switch from sendmail to dma very recently.

Isn=E2=80=99t this the case? Difficult to judge without knowing more =
details (like, snippets from logs, etc=E2=80=A6)


=E2=80=94
Juraj Lutter
otis@FreeBSD.org


From nobody Wed Nov 16 05:28:16 2022
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 4NBs610yqsz4dHD4
	for ; Wed, 16 Nov 2022 05:28:41 +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 4NBs602Rw1z3KWG
	for ; Wed, 16 Nov 2022 05:28:40 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 2AG5SGD4016774
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 16 Nov 2022 07:28:19 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 2AG5SGD4016774
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 2AG5SGDB016773;
	Wed, 16 Nov 2022 07:28:16 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Wed, 16 Nov 2022 07:28:16 +0200
From: Konstantin Belousov 
To: "Chen, Alvin W" 
Cc: Amar Takhar ,
        "freebsd-current@freebsd.org" 
Subject: Re: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Message-ID: 
References: 
 
 
 
 <20221114174812.GA20495@darkbeer.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=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home
X-Rspamd-Queue-Id: 4NBs602Rw1z3KWG
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Nov 15, 2022 at 07:49:55AM +0000, Chen, Alvin W wrote:
> Kongstantin,
> 
> I am not familiar with TLB part implementation for BSD. Based on your patch, it looks like disable PCID or force flush TLB for E core. Is that right?
> Would you mind explain a little more to help understand the code?

The patch does what its title said. On small cores it does not rely on
INVLPG to flush global TLB entries.  Instead, total flush of TLB with
INVPCID instruction is performed.

For large cores, no change in behavior is intended.
> 
> 
> Internal Use - Confidential
> 
> > -----Original Message-----
> > From: owner-freebsd-current@freebsd.org  > current@freebsd.org> On Behalf Of Amar Takhar
> > Sent: Tuesday, November 15, 2022 1:48 AM
> > To: freebsd-current@freebsd.org
> > Subject: Re: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
> > support
> > 
> > 
> > [EXTERNAL EMAIL]
> > 
> > On 2022-11-14 09:09 +0200, Konstantin Belousov wrote:
> > >
> > > You might use this patch meantime
> > > https://urldefense.com/v3/__https://kib.kiev.ua/git/gitweb.cgi?p=devia
> > >
> > nt3.git;a=commit;h=5d72240a8777b26d5e0a7d2d26bb919d05f60002__;!!LpKI
> > !g
> > > -6xRexMgrS7blkbBAEW-CU6xx2soVgqJcn34v5a-
> > vYybodWNslFhcgFr631abOyXATJf_r
> > > ACTtzog$ [kib[.]kiev[.]ua]
> > 
> > I know this is -CURRENT but will this work on 13.1 as well?  I use that as my
> > main workstation.
> > 
> > Also does vm.pmap.pcid_enabled need to be set to 0 still?
> > 
> > Hopefully this fixes the sound issues as well right now I have all my E-cores
> > disabled but sound issues persist.
> > 
> > Thanks!
> > 
> > 
> > Amar.

From nobody Fri Nov 18 04:47:58 2022
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 4ND46L50DJz4hJR5
	for ; Fri, 18 Nov 2022 04:48:10 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4ND46J6nQbz4DZq
	for ; Fri, 18 Nov 2022 04:48:08 +0000 (UTC)
	(envelope-from hps@selasky.org)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org;
	dmarc=none
Received: from [10.36.2.69] (unknown [84.210.222.10])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 087DA2600C9
	for ; Fri, 18 Nov 2022 05:48:00 +0100 (CET)
Message-ID: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
Date: Fri, 18 Nov 2022 05:47:58 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Content-Language: en-US
To: FreeBSD Current 
From: Hans Petter Selasky 
Subject: ULE realtime scheduler advice needed
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.989];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DMARC_NA(0.00)[selasky.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	MIME_TRACE(0.00)[0:+];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4ND46J6nQbz4DZq
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hi,

I'm doing some work with audio and have noticed some problems with the 
ULE scheduler. I have a program that generate audio based on 
key-presses. When no keys are pressed, the load is near 0%, but as soon 
as you start pressing keys, the load goes maybe to 80% of a CPU core. 
This program I run with rtprio 8 xxx. The issue I observe or hear 
actually, is that it takes too long until the scheduler grasps that this 
program needs it's own CPU core and stops time-sharing the program. When 
I however use cpuset -l xxx rtprio 8 yyy everything is good, and the 
program outputs realtime audio in-time.

Or is this perhaps a CPU frequency stepping issue?

Any advice on where to look?

--HPS

From nobody Fri Nov 18 05:30:59 2022
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 4ND53t3T6Pz4hQJq
	for ; Fri, 18 Nov 2022 05:31:06 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20])
	(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 4ND53s2X8Wz4JGZ
	for ; Fri, 18 Nov 2022 05:31:05 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=dell.com header.s=smtpout1 header.b=CQlqF6ER;
	spf=pass (mx1.freebsd.org: domain of Weike.Chen@Dell.com designates 148.163.137.20 as permitted sender) smtp.mailfrom=Weike.Chen@Dell.com;
	dmarc=pass (policy=reject) header.from=dell.com;
	arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}")
Received: from pps.filterd (m0170394.ppops.net [127.0.0.1])
	by mx0b-00154904.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AI55X3A032258;
	Fri, 18 Nov 2022 00:31:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=smtpout1;
 bh=sKxYA70QlHHsHJKn1/F+8WDgysQzk3efuUfS1CfB0+8=;
 b=CQlqF6ER8yKmXKZmIk1THzFC5YtD81wSqcvfcGesjHQg8YD7mlYnk1a77tDxzQ8xU+/t
 TavznqXsXQgThxQCjxjbhYmaRd7Tk8rOt69F/cRzKhkNz7fsPJluMeDgsUwnxUGo6YsP
 pKU6mhFFO8RBBTfBzTmbZXQjkYAHAmY82KCn+bcFFtfMFU1lIIbTB+K0c4cFcLsHqoSa
 AT6/ILGdp+hvJPVtd+59+C5ui0r4R7EHNsdOKpGb7435MR+YJf+GmVGFy3we08SIE8Of
 KBTKaCrVkwAYGFKAU7eQqKQOc0TPmUzd00c7O2TLu0ZqnKjs+hmf74nOglpm+l/Wz/PF kg== 
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39])
	by mx0b-00154904.pphosted.com (PPS) with ESMTPS id 3kx0tahc6w-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
	Fri, 18 Nov 2022 00:31:03 -0500
Received: from pps.filterd (m0142699.ppops.net [127.0.0.1])
	by mx0a-00154901.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AI4fTgE024592;
	Fri, 18 Nov 2022 00:31:02 -0500
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2049.outbound.protection.outlook.com [104.47.66.49])
	by mx0a-00154901.pphosted.com (PPS) with ESMTPS id 3kx0s8tf5n-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
	Fri, 18 Nov 2022 00:31:01 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=JGwRh+e/Ujw8/y3qrWPuxQ9ypseYXFptCsi1dW0TdeGLpbkYd/86VTC/Oz3TuM9iVQtdyUu4xbxYblzVAccdeVHu0y4LKonfkKB5gjyydL0fLDmUPdZC52LWrwxMj1nf3R6KIJuzeVrIlPngeLm/A21HhiT2A3KESpNd1jXG67GOSnVdzA5AzZoVHOM+ucCGbOF2/RdTMabqpfYy6qht89yx8qFOpsJZdxkHVQocM2OFvMnimFgVYKGpaG2IzFAJc5BBpz19jAoNxggG4l5G3jRb136J6Hl3Deg0+wlpuq/rh1tN5vfKp3XfZedUEAOjzeIj9nyvx6kI61HZ/DvRkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=sKxYA70QlHHsHJKn1/F+8WDgysQzk3efuUfS1CfB0+8=;
 b=J0ezGOxx8Re5z3tnXYh52rqKpT/EvvZvorrq2M7oPAUgNkoNCKZPEVEhX3A5pHfhNzK0aGWChaso3g0UNSg9B1K57GN41lJ16eGUKRPaH1JutzCqb2GCyyTR2A6rjuYs0me5ChAh7GvHrwbncOLcTTpgRNrWxgrOPqZ6z/6ytOGy+lCvFyPNfYSeX6j1dfrG6ToY7HRnjKFz7buWQ7Gy0IeGa4XquCAD38APBtaQ90VnlYhOAJdvCgjPwgpwEuw4Vccyiybp92KqaiYJdIR2d8YBoXrrlYObE4ayTlwu4alQl4861srvcqxJDSTGg+gCd/VAmJWKEVrua8ho0JtJoQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com;
 dkim=pass header.d=dell.com; arc=none
Received: from PH0PR19MB4938.namprd19.prod.outlook.com (2603:10b6:510:94::9)
 by MN0PR19MB5755.namprd19.prod.outlook.com (2603:10b6:208:376::21) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.14; Fri, 18 Nov
 2022 05:30:59 +0000
Received: from PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::2674:57b2:996:111b]) by PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::2674:57b2:996:111b%3]) with mapi id 15.20.5813.020; Fri, 18 Nov 2022
 05:30:59 +0000
From: "Chen, Alvin W" 
To: Konstantin Belousov 
CC: Amar Takhar ,
        "freebsd-current@freebsd.org"
	
Subject: RE: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Thread-Topic: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Thread-Index: 
 AdjptCu1BUq3xWQjS9a169SAwDUljwAYvyqAA3ddajAAANodAAAWT1EAAByl5KAALhfMAABkkAeA
Date: Fri, 18 Nov 2022 05:30:59 +0000
Message-ID: 
 
References: 
 
 
 
  <20221114174812.GA20495@darkbeer.org>
 
 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Enabled=true;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SetDate=2022-11-18T05:30:57Z;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Method=Standard;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Name=No Protection (Label
 Only) - Internal Use;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ActionId=8dd8748d-b4e7-47d8-816e-ac20f1f0f6bc;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ContentBits=2
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR19MB4938:EE_|MN0PR19MB5755:EE_
x-ms-office365-filtering-correlation-id: 6bfc7bd8-168e-493e-9784-08dac926130d
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 AVBobA8ZRITYTAVUyLvwKIYJB6bJanXcFZnPIHyJ4h3fLApnz0DLXpMIomehsXf/jXpyL+A/+g0tNqWKkKdH538VlH8ZSYHtXY0IiCHz15TP08GdwELWht2jjVR+6yXOgatb+0MfziHH0m9Pwr5byinL3aLecvKjnMOzbLE2Wm94cfVtAnI9iob4n1RdNqhH0uVnKgvRMp31dlSJUL3LgF800LPPnz8lDXGuOU0eSkIMSgu+08WBh3QikFoU6i1TDenVeWQ/+VpkxnLywcTcPhlCTJPa7w/QvO2xiqRb975zV2edq7NxEVmFx2NGTxMLYmsUh3Co4+Ex6dezf7Cp+QUXbVDK91CkACYDpiT5S5409rqUf+WxNdIejOTuoe/CVVVU5HnaMY9Y159jlraMdDTKu/ZvUCWXqD0f4RQTI/02mByBdPq9bQeTjZX4aNhbI8y0fR7oHfrx4+j80GH4HBVF+FSaO4asOfWWH14Zt5cgO6AwQchRXjdV1Px/aTVOmBSQco0wCNQXuB3xwnL3ANWt343GwsRpCwouHd4jaXFv/+uWutB+RYrgPTEnXrArqs+NHWh9fVteRxWZIEKRwK7m9pAEvBYLVzvx4IMIwPnfOduCJMwQyvlsxMmubAZakZdhhVkQ3ycgX3C2bOcaY5Kbw5pGmvyTPLOnkS9mEdOShEnqWSMemvwryhiuoawjtvgpODvZb1EPwLLKcWTcbQ==
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR19MB4938.namprd19.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(346002)(396003)(366004)(376002)(136003)(39860400002)(451199015)(66476007)(86362001)(186003)(76116006)(38100700002)(55016003)(66446008)(4326008)(66556008)(9686003)(64756008)(8676002)(52536014)(33656002)(41300700001)(66946007)(478600001)(71200400001)(26005)(5660300002)(786003)(316002)(38070700005)(122000001)(8936002)(6916009)(6506007)(82960400001)(54906003)(4744005)(7696005)(2906002);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?D99QZm9PEEua2XnQXydqToVeV4qRbIjQv24Yl2NtzyCeQiKTxzTvrY3MHZoH?=
 =?us-ascii?Q?28XdL/FQWo4U147cY+Z2yP1dRokiklLfBTRnbHAB9CfIS78dZQ33fEc6WpvZ?=
 =?us-ascii?Q?SIMBxZY/bDMAKg6neQdzbPzdyMfTeRCikhYyR73gVmhHoWDPwMJERVgJemRj?=
 =?us-ascii?Q?54/u4mdJVLuVOY2wq+tEpg758LT0HaTTCh6LkH8bg4kJuZH5H4jpvMxZoOaG?=
 =?us-ascii?Q?mdODZf17RG29/9yrAIIaC+Tgmhl57q3639SLW4Myi6XrzArnFUFbyj511/7q?=
 =?us-ascii?Q?FJwiKwY90twFdI7o/8YerH5zuxQ9UZkXBVnwB/gyH9OawY5Se0f1KWrIyTVu?=
 =?us-ascii?Q?Y/9DUM53BkVzj2x+9ZSiX0rotlUtP9PBLDldr9HOnv+1ERXbzNco8mr+Xj3b?=
 =?us-ascii?Q?3U1rWckZ4h4SyUgmuerxtXmDLxAKqktI4+VJK+zhn7mxtUpDKvL7c10ePU68?=
 =?us-ascii?Q?yepnNNnZbupYBSXl5LOhqSjMbRYpxm28g0XVpr7S1n3Ist1LjDM1aBugfdVF?=
 =?us-ascii?Q?9t65cZGFaQD2TsWTOxkD2dxhF1hAOuCLJ4fJAWpICO9qxlwpIFObECfuH1Jh?=
 =?us-ascii?Q?8yz6bXe27W69o7SHsp+tspTypnxQqH0jNu2NBbIRH4TwD6nt63JPPnlErOtL?=
 =?us-ascii?Q?FSl2/mFc1WsE6wliJHJSk5Dn61NRvV+qvZekQvggTqR6PeLtcZ2DGjdAuj2D?=
 =?us-ascii?Q?eWzGQHDkAQdqqkrT6/+BBaxySyM3da8LPmH4iFEz+OlErFakjD1z5oyiGohM?=
 =?us-ascii?Q?tZPys0UxpRQh0nKHuht3yBoRScUxQnZIRC7jc4YZa9ZPKYip1jfjX2GPmfOf?=
 =?us-ascii?Q?mal438if97D/qSbNE9Cbqj0dRc3VQpXf1t9Qxx473FWG9L1Ew65voK7w3Dyi?=
 =?us-ascii?Q?L9RcQ3ibiau3LPcmWprSTn3JvNrdwPVNhsaqPCBMMmOj47Hn9p6U6lfm8AQB?=
 =?us-ascii?Q?ic+0CPf5g2aiMmA0aTIxqTGIh9EEBt+t90BKB6r8Lpi40Msrp3PWuzOzGqhi?=
 =?us-ascii?Q?5d/b1a6ANu/OWGwZEwjHqy6bC+iNsj2kdU0nggiZ0BuBJwT6YbFyMB/1yyhw?=
 =?us-ascii?Q?Hb1HyOYqLt4VR10OL7CfvTexZ3txMgKcyqV0Z/kwJ/mmj+0PqabmH+YFNiw6?=
 =?us-ascii?Q?aED9oxhErLvoyWaSOjGpuRJ5Sv0VZQZbyuKEZZENLBIOTTmpaN8y0GXfs42i?=
 =?us-ascii?Q?5BqkmSBraJw4JZPZ8FOLCDM4oScWAY1iq6yhmu7FDU+35jqcQPAK+ByPsm8k?=
 =?us-ascii?Q?vmdxwFRPRKs1cSY0M+R8VvmMQSrPyPfC0TCn/BYAh11ki5fGusfGOWdTShCn?=
 =?us-ascii?Q?9CBEbRvGmLm2Ew/HyJ2kgyMzUpFurngDgcpcefVHBgLKLrYjniCX+VfxJdx8?=
 =?us-ascii?Q?XEr/NAfbOoOm2c5uSqD1fIugUz+gO3H5eWzVVo4tKFj9tI3CJGOqjISxY3vU?=
 =?us-ascii?Q?qvoJ+ieAbVLpVuVQjrDVuN7pl2dSbz9Dmi0rtVjdab2tRxCN8KGXizNqwQNP?=
 =?us-ascii?Q?+ti8ziy4XFA/g5rclfXDxZmGAmzo2pcCUQFp1uMqJ9m4h8rNRTT5f6U6Rqjr?=
 =?us-ascii?Q?d/DCEVeoz4aWE0ODGF2QV9QV1DShDrs1rgbouV1v?=
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
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR19MB4938.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6bfc7bd8-168e-493e-9784-08dac926130d
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2022 05:30:59.1319
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HcYdhAFk4ecUxFmL/Xuq7viblGzry1m1RhH+h4UW6xqPJd32AeNeolyKBuQmRvsKqr7Owf75ja5JUQUO+TZ27w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR19MB5755
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-11-17_06,2022-11-17_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 clxscore=1011
 lowpriorityscore=0 spamscore=0 impostorscore=0 mlxlogscore=308
 malwarescore=0 priorityscore=1501 mlxscore=0 adultscore=0 phishscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2211180036
X-Proofpoint-GUID: bgOrKT3Rj8IoiGihorNMuwD7U3rvCnWt
X-Proofpoint-ORIG-GUID: bgOrKT3Rj8IoiGihorNMuwD7U3rvCnWt
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=390 spamscore=0
 adultscore=0 phishscore=0 malwarescore=0 bulkscore=0 suspectscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2211180036
X-Spamd-Result: default: False [-7.10 / 15.00];
	WHITELIST_SPF_DKIM(-3.00)[dell.com:d:+,Dell.com:s:+];
	DWL_DNSWL_LOW(-1.00)[dell.com:dkim];
	ARC_REJECT(1.00)[signature check failed: fail, {[1] = sig:microsoft.com:reject}];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[dell.com,reject];
	R_SPF_ALLOW(-0.20)[+ip4:148.163.137.20];
	R_DKIM_ALLOW(-0.20)[dell.com:s=smtpout1];
	RCVD_IN_DNSWL_LOW(-0.10)[67.231.149.39:received];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[104.47.66.49:received];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[148.163.137.20:from];
	RCPT_COUNT_THREE(0.00)[3];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	ASN(0.00)[asn:22843, ipnet:148.163.137.0/24, country:US];
	DKIM_TRACE(0.00)[dell.com:+];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_SEVEN(0.00)[7]
X-Rspamd-Queue-Id: 4ND53s2X8Wz4JGZ
X-Spamd-Bar: -------
X-ThisMailContainsUnwantedMimeParts: N

> > I am not familiar with TLB part implementation for BSD. Based on your
> patch, it looks like disable PCID or force flush TLB for E core. Is that =
right?
> > Would you mind explain a little more to help understand the code?
>=20
> The patch does what its title said. On small cores it does not rely on IN=
VLPG
> to flush global TLB entries.  Instead, total flush of TLB with INVPCID
> instruction is performed.
>=20
> For large cores, no change in behavior is intended.

Thanks. I apply the patch and test for 10 hours+ on my ADL-P laptop. It wor=
ks well, and the issue is never reproduced.

Internal Use - Confidential

From nobody Fri Nov 18 08:18:28 2022
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 4ND8nd4lp9z4hpxh
	for ; Fri, 18 Nov 2022 08:19:01 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4ND8nc7466z4Y7k
	for ; Fri, 18 Nov 2022 08:19:00 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from outgoing.leidinger.net (p5b165cc5.dip0.t-ipconnect.de [91.22.92.197])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id 021B3264D5;
	Fri, 18 Nov 2022 09:18:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1668759528;
	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; bh=c+FO7D/mwO+iDTv1LzBp8iaJQkkMJcprKLYcJVltP1g=;
	b=xyBreU+VPziL5zIOQkayRp1p19SrTKQTNGisG7gLg6y/okHuH2XEbH3IT+F9VGsIpVurt6
	0F5gGt2Q/SJMC8qPzArmTT5S1pKIPZ1Fj5jn2Dui16mCSXdKMfl6gW3ZbXkMYrTmji/g/0
	ctfYxLeU7bZpgWga4LKHbqDhWZD/uPCsTc9EM6unETyLJAaIOSH5Hr3ejFGtsMT+hRNigv
	o+gjjYmxixhtDR3VSF44aUaxZGyEKJNSVQaQFS1wDOjlP1h/exPYz0u93lBmmnwr/SrM0h
	0ZnhAfNQDp6wa8NsfLpVhETp+u3YedSYngNwAfihdV6mOOjNLk1WfQcUN19llg==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256)
	(Client did not present a certificate)
	by outgoing.leidinger.net (Postfix) with ESMTPS id 4BD6E587;
	Fri, 18 Nov 2022 09:18:28 +0100 (CET)
Date: Fri, 18 Nov 2022 09:18:28 +0100
Message-ID: <20221118091828.Horde.xkZUBiYzzOgubFonR22tMzm@webmail.leidinger.net>
From: Alexander Leidinger 
To: Hans Petter Selasky 
Cc: FreeBSD Current 
Subject: Re: ULE realtime scheduler advice needed
In-Reply-To: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_tggxlP2Ao4En0EIkGQsAPKT";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Rspamd-Queue-Id: 4ND8nc7466z4Y7k
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_tggxlP2Ao4En0EIkGQsAPKT
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoting Hans Petter Selasky  (from Fri, 18 Nov 2022=20=20
05:47:58=20+0100):

> Hi,
>
> I'm doing some work with audio and have noticed some problems with=20=20
>=20the ULE scheduler. I have a program that generate audio based on=20=20
>=20key-presses. When no keys are pressed, the load is near 0%, but as=20=
=20
>=20soon as you start pressing keys, the load goes maybe to 80% of a CPU=20=
=20
>=20core. This program I run with rtprio 8 xxx. The issue I observe or=20=
=20
>=20hear actually, is that it takes too long until the scheduler grasps=20=
=20
>=20that this program needs it's own CPU core and stops time-sharing the=20=
=20
>=20program. When I however use cpuset -l xxx rtprio 8 yyy everything is=20=
=20
>=20good, and the program outputs realtime audio in-time.

I have something in my mind about ULE not handling idleprio and/or=20=20
rtprio=20correctly, but I have no pointer to a validation of this.

> Or is this perhaps a CPU frequency stepping issue?

You could play with
rc.conf (/etc/rc.d/power_profile):
performance_cpu_freq=3D"HIGH"
performance_cx_lowest=3D"C3"   # see sysctl hw.cpu.0 | grep cx
economy_cx_lowest=3D"C3"       # see sysctl hw.cpu.0 | grep cx

Your system may provide other Cx possibilities, and ging to a lower=20=20
number=20(e.g. C1) means less power-saving but faster response from the=20=
=20
CPU=20(I do not expect that this is causing the issue you have).

> Any advice on where to look?

Potential sysctl to play with to change "interactivity detection" in ULE:
https://www.mail-archive.com/freebsd-stable@freebsd.org/msg112118.html

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_tggxlP2Ao4En0EIkGQsAPKT
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmN3P9MACgkQEg2wmwP4
2Ib46g/+MHdv1DNmg2mSrSzPDxYx79Vz/HFnMMe1wSGf9DOJll6nheyouIypoE+O
rZu+Z9dppbNi+hAMnnSbQ5NHSCj2sI7BR/dOJt0B4f5l0SwmNs6Ph28HXQju12pp
/Zmh9AtZZwaw2qCXmbA5uEyEJmkIIsqnXMXQ7HDlPKP+b9q7vj/+XqsO/rE2QCK1
RLYlAGvfdZ2vo/gQovE8k5Bfn+8JtizsNm0Pwj7EZCHNLhgA1vU4QKzjCMWScyhx
0OPxuYiIZcgcKQt3rRBs0ivhodjuEc13BzEiFlQJ8/ILdw7QnWNiWYXxuoKtWC7n
T/wKmfqvv7zRwWAQt3fE4BcQZw9Z9fAkLQPX1S/vwprHzlhHZ6mJukUNxgj5FVXG
dnQ/+gRHi7av8k2ntWSgkKLn3btb2GMjaQBRmcZ+/R+BHxkI/lJV3oEYRLLRA/Bq
SoxURWjJQMBiZcoHsjgCnR62TbPXG1YiJ7YfXMLkgT4pZ19ngIjMSgGALkCS8nGb
u00HyIJoccrQvytgIBHgdInUFW6rQdIW9hfzQun7rvVNQ1noqxs9khbFiqUATbZF
qDWkPP7sF9cn86p/IFn6xIuo2HaiJXzAviGPKTB+jHnJdd2jOPtNdnAW/pdTKT5l
SDm64xoUIaFYqfgV7UsbM+gkdondTeRyC90GYdeOeGEd6ySs4Mg=
=lrgw
-----END PGP SIGNATURE-----

--=_tggxlP2Ao4En0EIkGQsAPKT--

From nobody Fri Nov 18 19:56:53 2022
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 4NDSH55b3Lz4h6pP
	for ; Fri, 18 Nov 2022 19:57:05 +0000 (UTC)
	(envelope-from mira@chlastak.cz)
Received: from mxb-1-3f7.seznam.cz (mxb-1-3f7.seznam.cz [IPv6:2a02:598:128:8a00::1000:3f7])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "email-registrator.ops.iszn.cz", Issuer "Servers 2022.1" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NDSH41Z6yz3jCs
	for ; Fri, 18 Nov 2022 19:57:03 +0000 (UTC)
	(envelope-from mira@chlastak.cz)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=emailprofi.seznam.cz header.s=szn20221014 header.b=ighBgcsa;
	spf=none (mx1.freebsd.org: domain of mira@chlastak.cz has no SPF policy when checking 2a02:598:128:8a00::1000:3f7) smtp.mailfrom=mira@chlastak.cz;
	dmarc=none
Received: from email.seznam.cz
	by smtpc-mxb-68545b7b84-q2m5b
	(smtpc-mxb-68545b7b84-q2m5b [2a02:598:128:8a00::1000:3f7])
	id 58f79a54d4370ca05a800f6f;
	Fri, 18 Nov 2022 20:56:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=emailprofi.seznam.cz; s=szn20221014; t=1668801419;
	bh=yjpmgGYM1ejiyUdnE9eXsegguqMC+51vsQgv5Nw4sVk=;
	h=Received:From:Content-Type:Mime-Version:Subject:Message-Id:Date:
	 To:X-Mailer;
	b=ighBgcsaUgH3zYqc91Vf27pNx6KPCjV41U4LgY55O63QYkdgpy0ejNj8RTeKW4TC4
	 CmXpAHeDFFAqTg4hg0b16xyVVjWkYef+mm0E1joDnh/hIXnpXRU0ISRFkTSmoODljw
	 T+rAxf0bS8Wxi5MflAOeWmcXUNCgjyEoEPeqp+PLUkIN16yqDw0Da1WuX2xnGqSaJh
	 1FaTPB+Ac7ZSgatsFnU28oYh3m1Yt4mfaCG0Cma/dqp+4NKr4Jr/2djXebAxR+/i5O
	 4pNd6CE/cosaL5oGxRLK2bR+osyDtTPmQU/+WgBXmAN5kv/bQGAZmLO9bfYrLaMSqM
	 AbUiTZ+2Tf5+w==
Received: from [10.10.100.102] (cust.uvtnet.cz [185.63.97.36])
	by email-relay16.ko.seznam.cz (Seznam SMTPD 1.3.140) with ESMTP;
	Fri, 18 Nov 2022 20:56:58 +0100 (CET)  
From: =?utf-8?Q?Chlast=C3=A1k_Miroslav?= 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_3A7CEF12-6CD0-48EF-B7AE-B9193C5F13FD"
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 13.4 \(3608.120.23.2.7\))
Subject: loader.conf and rootdev option for memory disk
Message-Id: <2E58D34B-F8C5-4291-B019-9E24F56DC3DF@chlastak.cz>
Date: Fri, 18 Nov 2022 20:56:53 +0100
To: FreeBSD CURRENT 
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-Spamd-Result: default: False [-3.80 / 15.00];
	DWL_DNSWL_LOW(-1.00)[seznam.cz:dkim];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[emailprofi.seznam.cz:s=szn20221014];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[emailprofi.seznam.cz:+];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_ALL(0.00)[];
	DMARC_NA(0.00)[chlastak.cz];
	ASN(0.00)[asn:43037, ipnet:2a02:598::/32, country:CZ];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NDSH41Z6yz3jCs
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_3A7CEF12-6CD0-48EF-B7AE-B9193C5F13FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,

In the /boot/defaults/loader.conf are these options for memory disk =
settings:

#mdroot_load=3D"YES"              # The "mdroot" prefix is arbitrary.
#mdroot_type=3D"md_image"         # Create md(4) disk at boot.
#mdroot_name=3D"/boot/root.img"   # Path to a file containing the image.
#rootdev=3D"ufs:/dev/md0"         # Set the root filesystem to md(4) =
device.


But - is this example for rootdev option still right? Because =
=E2=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on =
freebsd 12.3 this does not work and generates error message:

Can=E2=80=99t determine root device


When I use this option with value =E2=80=9C/dev/md0=E2=80=9D or =
=E2=80=9Cmd0=E2=80=9D (even with this option commented out), so the =
machine boots correctly without any error.

=E2=80=94
Mira=

--Apple-Mail=_3A7CEF12-6CD0-48EF-B7AE-B9193C5F13FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
all,

In the =
/boot/defaults/loader.conf are these options for memory disk =
settings:

#mdroot_load=3D"YES"            =
  # The "mdroot" prefix is arbitrary.
#mdroot_type=3D"md_image"   =
      # Create md(4) disk at boot.
#mdroot_name=3D"/boot/root.img"   # Path to a file =
containing the image.
#rootdev=3D"ufs:/dev/md0"         # Set =
the root filesystem to md(4) device.


But - is this example for rootdev option still right? Because =
=E2=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on =
freebsd 12.3 this does not work and generates error message:

Can=E2=80=99t determine root device


When I use this option with value =E2=80=9C/dev/md0=E2=80=9D =
or =E2=80=9Cmd0=E2=80=9D (even with this option commented out), so =
the machine boots correctly without any error.

=E2=80=94
Mira
=

--Apple-Mail=_3A7CEF12-6CD0-48EF-B7AE-B9193C5F13FD--

From nobody Fri Nov 18 20:13:31 2022
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 4NDSfJ1Sp4z4h9HH
	for ; Fri, 18 Nov 2022 20:13:44 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NDSfJ1255z3knF
	for ; Fri, 18 Nov 2022 20:13:44 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x631.google.com with SMTP id gv23so15714614ejb.3
        for ; Fri, 18 Nov 2022 12:13:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=PgqSeQ27DIGzOG3ulltysje36PLCgTpDdODFBvx121I=;
        b=1ssUpZWg++wYHcBJesi0g0HheYhd/tZnxPAbYAMvKjMTZtrQW5kahNq9YRRDtS/vuY
         jO/1ZKFpiR0kfSvWWokvMD3mUnBnFmo+Tx0q9ttm0rFxSYGqSQTXnUTWVKwEiF4VCKc4
         36hEb/cy5H8KF7uOOfJs4a71tpRhwOkAyxZwq2rwC3/e5GS3vUGyMFNfkIdh8Z8gfhMX
         tkVklyIks/Thg6CU1kip8Dw2o3lbkbsB1qrVJjxWBIePyQCtB0whT5yiXG1RlpI6TJMz
         3OdiVl5YhbqtN/Vr9b0PxPYRVPMbeFX369/Cz0qY8s/rtOZDVTYFbXXebH4h00e0j9Om
         0txg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=PgqSeQ27DIGzOG3ulltysje36PLCgTpDdODFBvx121I=;
        b=z59QeNkSD9aDbmeKjMsotBNLi2UpKv44RpSL5qLtWG4h/j063A1MQx9c5vz49zGhMZ
         9FBF3KzIeEbu8yYtEfq9jlzvy9HDpN1AOo+8txTvf/RxexydvtCaBU2IsEi8sYUMZKdj
         yb6UEdlQPNsfelCn+vgG1bBBrzHtxjXbrxreveP+3xa2g9/f2XrYyaTAoBWPQkTs8/F3
         QJqlZh2Odt11FII6EiFksQculBA8tPaiNqjuv9wE7U+Ho6nePIGU8FQEs4p5AqzbvHRe
         X4h8jRAuzs4dawgt9o42l2UEYi6U+IAGBUwGrZY9ZfqAy31o0bDtbC0X5f7uO7WBdoPq
         xyhQ==
X-Gm-Message-State: ANoB5pmdtf1zUIeN8UGavfBnQ5CrkfydAi9rhbmxVWrJ/C7qFa91JaG7
	FnqBU8ErPKif+oobboKoTQkj8sEct8GuYZoChPmUEfQKzAvh6g==
X-Google-Smtp-Source: AA0mqf7GlilwpQDpZTE38DIUuzSdGVuQMPfBzJPn0JU9gyQlqHPoSmCwv2P/E/vmaRh+E5bUTTZA+qr1m3Bn29dW8DA=
X-Received: by 2002:a17:906:b210:b0:7ae:d116:fabb with SMTP id
 p16-20020a170906b21000b007aed116fabbmr7204346ejz.317.1668802422682; Fri, 18
 Nov 2022 12:13:42 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <2E58D34B-F8C5-4291-B019-9E24F56DC3DF@chlastak.cz>
In-Reply-To: <2E58D34B-F8C5-4291-B019-9E24F56DC3DF@chlastak.cz>
From: Warner Losh 
Date: Fri, 18 Nov 2022 13:13:31 -0700
Message-ID: 
Subject: Re: loader.conf and rootdev option for memory disk
To: =?UTF-8?Q?Chlast=C3=A1k_Miroslav?= 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000009ae2aa05edc4577c"
X-Rspamd-Queue-Id: 4NDSfJ1255z3knF
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--0000000000009ae2aa05edc4577c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 18, 2022 at 12:57 PM Chlast=C3=A1k Miroslav  =
wrote:

> Hi all,
>
> In the /boot/defaults/loader.conf are these options for memory disk
> settings:
>
> #mdroot_load=3D"YES"              # The "mdroot" prefix is arbitrary.
> #mdroot_type=3D"md_image"         # Create md(4) disk at boot.
> #mdroot_name=3D"/boot/root.img"   # Path to a file containing the image.
> #rootdev=3D"ufs:/dev/md0"         # Set the root filesystem to md(4) devi=
ce.
>
>
> But - is this example for rootdev option still right? Because
> =E2=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on freebsd=
 12.3 this does
> not work and generates error message:
>
> Can=E2=80=99t determine root device
>
>
> When I use this option with value =E2=80=9C/dev/md0=E2=80=9D or =E2=80=9C=
md0=E2=80=9D (even with this
> option commented out), so the machine boots correctly without any error.
>

I think you want vfs.root.mountfrom=3D instead of rootdev=3D here.

Warner


> =E2=80=94
> Mira
>

--0000000000009ae2aa05edc4577c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Nov 18, 2022 at 12:57 PM Chla=
st=C3=A1k Miroslav <mira@chlastak.cz=
> wrote:
=

Hi all,

In the=
 /boot/defaults/loader.conf are these options for memory disk settings:

#mdroot_load=3D"YES=
"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # The "mdroot&q=
uot; prefix is arbitrary.
#mdroot_type=3D=
"md_image" =C2=A0 =C2=A0 =C2=A0 =C2=A0 # Create md(4) disk at boo=
t.
#mdroot_name=3D"/boot/root.img&qu=
ot; =C2=A0 # Path to a file containing the image.
#rootdev=3D"ufs:/dev/md0" =C2=A0 =C2=A0 =C2=A0 =C2=A0 # =
Set the root filesystem to md(4) device.


But - is this example for rootdev option still right? Because =E2=
=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on freebsd 12.3=
 this does not work and generates error message:

Can=E2=80=99t determine root=
 device


When I use this option with va=
lue =E2=80=9C/dev/md0=E2=80=9D or =E2=80=9Cmd0=E2=80=9D (even with this opt=
ion commented out),=C2=A0so the machine boots correctly without any error.<=
/div>

I think you want=C2=A0vfs.root.=
mountfrom=3D instead of rootdev=3D here.

Warner
=C2=A0
=E2=80=94=

Mira


--0000000000009ae2aa05edc4577c--

From nobody Sat Nov 19 09:28:50 2022
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 4NDpJ11jR3z4hBhM
	for ; Sat, 19 Nov 2022 09:29:05 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4NDpHx5L9tz4Vrd
	for ; Sat, 19 Nov 2022 09:29:01 +0000 (UTC)
	(envelope-from hps@selasky.org)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org;
	dmarc=none
Received: from [10.36.2.69] (unknown [84.210.222.10])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 92B662604E8;
	Sat, 19 Nov 2022 10:28:52 +0100 (CET)
Message-ID: 
Date: Sat, 19 Nov 2022 10:28:50 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: ULE realtime scheduler advice needed
To: Alexander Leidinger 
Cc: FreeBSD Current 
References: <20221118091828.Horde.xkZUBiYzzOgubFonR22tMzm@webmail.leidinger.net>
Content-Language: en-US
From: Hans Petter Selasky 
In-Reply-To: <20221118091828.Horde.xkZUBiYzzOgubFonR22tMzm@webmail.leidinger.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.989];
	R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net];
	MIME_GOOD(-0.10)[text/plain];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DMARC_NA(0.00)[selasky.org];
	FROM_HAS_DN(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NDpHx5L9tz4Vrd
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hi Alexander,

Thank you for the pointers.

I will try it out.

--HPS

On 11/18/22 09:18, Alexander Leidinger wrote:
> Quoting Hans Petter Selasky  (from Fri, 18 Nov 2022 
> 05:47:58 +0100):
> 
>> Hi,
>>
>> I'm doing some work with audio and have noticed some problems with the 
>> ULE scheduler. I have a program that generate audio based on 
>> key-presses. When no keys are pressed, the load is near 0%, but as 
>> soon as you start pressing keys, the load goes maybe to 80% of a CPU 
>> core. This program I run with rtprio 8 xxx. The issue I observe or 
>> hear actually, is that it takes too long until the scheduler grasps 
>> that this program needs it's own CPU core and stops time-sharing the 
>> program. When I however use cpuset -l xxx rtprio 8 yyy everything is 
>> good, and the program outputs realtime audio in-time.
> 
> I have something in my mind about ULE not handling idleprio and/or 
> rtprio correctly, but I have no pointer to a validation of this.
> 
>> Or is this perhaps a CPU frequency stepping issue?
> 
> You could play with
> rc.conf (/etc/rc.d/power_profile):
> performance_cpu_freq="HIGH"
> performance_cx_lowest="C3"   # see sysctl hw.cpu.0 | grep cx
> economy_cx_lowest="C3"       # see sysctl hw.cpu.0 | grep cx
> 
> Your system may provide other Cx possibilities, and ging to a lower 
> number (e.g. C1) means less power-saving but faster response from the 
> CPU (I do not expect that this is causing the issue you have).
> 
>> Any advice on where to look?
> 
> Potential sysctl to play with to change "interactivity detection" in ULE:
> https://www.mail-archive.com/freebsd-stable@freebsd.org/msg112118.html
> 
> Bye,
> Alexander.
> 

From nobody Sat Nov 19 12:21:44 2022
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 4NDt7Y5dZ4z4hd8b
	for ; Sat, 19 Nov 2022 12:22:01 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NDt7Y12Lzz3HLV
	for ; Sat, 19 Nov 2022 12:22:00 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2AJCLjTR071280;
	Sat, 19 Nov 2022 21:21:50 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Sat, 19 Nov 2022 21:21:44 +0900
From: Tomoaki AOKI 
To: Hans Petter Selasky 
Cc: Alexander Leidinger ,
        FreeBSD Current
 
Subject: Re: ULE realtime scheduler advice needed
Message-Id: <20221119212144.03c1fbda951b4137b116a6bb@dec.sakura.ne.jp>
In-Reply-To: 
References: <20221118091828.Horde.xkZUBiYzzOgubFonR22tMzm@webmail.leidinger.net>
	
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4NDt7Y12Lzz3HLV
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

I've  lost track with, but IIRC, someone wrote here, or other ML, or
even forums, kern.sched.preempt_thresh=224 was the default for PC-BSD.

And found some discussion started at [1] on freebsd-stable ML in Apr.
2018.

One more place is at forums [2].

Sorry, not read all of them to confirm.


[1]
https://lists.freebsd.org/pipermail/freebsd-stable/2018-April/088678.html

[2]
https://forums.freebsd.org/threads/general-freebsd-desktop-workload-optimization-thread.21853/



On Sat, 19 Nov 2022 10:28:50 +0100
Hans Petter Selasky  wrote:

> Hi Alexander,
> 
> Thank you for the pointers.
> 
> I will try it out.
> 
> --HPS
> 
> On 11/18/22 09:18, Alexander Leidinger wrote:
> > Quoting Hans Petter Selasky  (from Fri, 18 Nov 2022 
> > 05:47:58 +0100):
> > 
> >> Hi,
> >>
> >> I'm doing some work with audio and have noticed some problems with the 
> >> ULE scheduler. I have a program that generate audio based on 
> >> key-presses. When no keys are pressed, the load is near 0%, but as 
> >> soon as you start pressing keys, the load goes maybe to 80% of a CPU 
> >> core. This program I run with rtprio 8 xxx. The issue I observe or 
> >> hear actually, is that it takes too long until the scheduler grasps 
> >> that this program needs it's own CPU core and stops time-sharing the 
> >> program. When I however use cpuset -l xxx rtprio 8 yyy everything is 
> >> good, and the program outputs realtime audio in-time.
> > 
> > I have something in my mind about ULE not handling idleprio and/or 
> > rtprio correctly, but I have no pointer to a validation of this.
> > 
> >> Or is this perhaps a CPU frequency stepping issue?
> > 
> > You could play with
> > rc.conf (/etc/rc.d/power_profile):
> > performance_cpu_freq="HIGH"
> > performance_cx_lowest="C3"   # see sysctl hw.cpu.0 | grep cx
> > economy_cx_lowest="C3"       # see sysctl hw.cpu.0 | grep cx
> > 
> > Your system may provide other Cx possibilities, and ging to a lower 
> > number (e.g. C1) means less power-saving but faster response from the 
> > CPU (I do not expect that this is causing the issue you have).
> > 
> >> Any advice on where to look?
> > 
> > Potential sysctl to play with to change "interactivity detection" in ULE:
> > https://www.mail-archive.com/freebsd-stable@freebsd.org/msg112118.html
> > 
> > Bye,
> > Alexander.
> > 
> 


-- 
Tomoaki AOKI    

From nobody Sat Nov 19 18:57:47 2022
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 4NF2wN6DLgz4hf7S
	for ; Sat, 19 Nov 2022 18:57:56 +0000 (UTC)
	(envelope-from mira@chlastak.cz)
Received: from mxb-1-3f7.seznam.cz (mxb-1-3f7.seznam.cz [IPv6:2a02:598:128:8a00::1000:3f7])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "email-registrator.ops.iszn.cz", Issuer "Servers 2022.1" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NF2wN34TYz4FP0
	for ; Sat, 19 Nov 2022 18:57:56 +0000 (UTC)
	(envelope-from mira@chlastak.cz)
Authentication-Results: mx1.freebsd.org;
	none
Received: from email.seznam.cz
	by smtpc-mxb-68545b7b84-q2m5b
	(smtpc-mxb-68545b7b84-q2m5b [2a02:598:128:8a00::1000:3f7])
	id 6adaccd2e61a5a2668ad59e9;
	Sat, 19 Nov 2022 19:57:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=emailprofi.seznam.cz; s=szn20221014; t=1668884271;
	bh=JKEDpAdPVGQ0cXfqhn+6C4JvPItiaCg2BDTsDKEYszc=;
	h=Received:From:Message-Id:Content-Type:Mime-Version:Subject:Date:
	 In-Reply-To:Cc:To:References:X-Mailer;
	b=djWbmasEw5wqiR+oS6UTVWT5pjEwYhbBS4UaVBB33uvBzGJQzYzPwibXJ/ZXB5wow
	 FGzOx/aOLjJvRCuZF+Wrt0eIFZAF7Klu32KPCi6kAjcIpOLNX0iPygc7GWLirFU5rg
	 AQPA43DUlGrZI6MHQ2jLQ5eYI9FXTQTFKCcXKa8rla8j4HQEGK53RqMza4dQNN+470
	 anZoeh04tjZ+IB7emvbPUmboyM3RVWlWnuwY9MJz9GzQX5LFcg/c+Nk7TdBBiAtKQa
	 6FubmUcEe5gXm+WOHgdNal/Ag4OTmyYgIvGB/PbsjA7km30vnpc7az4s4oigRKvR42
	 VVwSIjDIdXx5A==
Received: from [10.10.100.102] (cust.uvtnet.cz [185.63.97.36])
	by email-relay2.ko.seznam.cz (Seznam SMTPD 1.3.140) with ESMTP;
	Sat, 19 Nov 2022 19:57:49 +0100 (CET)  
From: =?utf-8?Q?Chlast=C3=A1k_Miroslav?= 
Message-Id: 
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C9DE10EB-BB9F-4B0A-8B1D-5293F75C27EE"
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 13.4 \(3608.120.23.2.7\))
Subject: Re: loader.conf and rootdev option for memory disk
Date: Sat, 19 Nov 2022 19:57:47 +0100
In-Reply-To: 
Cc: FreeBSD CURRENT 
To: Warner Losh 
References: <2E58D34B-F8C5-4291-B019-9E24F56DC3DF@chlastak.cz>
 
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-Rspamd-Queue-Id: 4NF2wN34TYz4FP0
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:43037, ipnet:2a02:598::/32, country:CZ]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_C9DE10EB-BB9F-4B0A-8B1D-5293F75C27EE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I have my device working for now - but the question is - Is the =
documentation and example for =E2=80=9Crootdev=E2=80=9D right or not?

=E2=80=94
Mira

> On 18 Nov 2022, at 21:13, Warner Losh  wrote:
>=20
>=20
>=20
> On Fri, Nov 18, 2022 at 12:57 PM Chlast=C3=A1k Miroslav =
> wrote:
> Hi all,
>=20
> In the /boot/defaults/loader.conf are these options for memory disk =
settings:
>=20
> #mdroot_load=3D"YES"              # The "mdroot" prefix is arbitrary.
> #mdroot_type=3D"md_image"         # Create md(4) disk at boot.
> #mdroot_name=3D"/boot/root.img"   # Path to a file containing the =
image.
> #rootdev=3D"ufs:/dev/md0"         # Set the root filesystem to md(4) =
device.
>=20
>=20
> But - is this example for rootdev option still right? Because =
=E2=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on =
freebsd 12.3 this does not work and generates error message:
>=20
> Can=E2=80=99t determine root device
>=20
>=20
> When I use this option with value =E2=80=9C/dev/md0=E2=80=9D or =
=E2=80=9Cmd0=E2=80=9D (even with this option commented out), so the =
machine boots correctly without any error.
>=20
> I think you want vfs.root.mountfrom=3D instead of rootdev=3D here.
>=20
> Warner
> =20
> =E2=80=94
> Mira


--Apple-Mail=_C9DE10EB-BB9F-4B0A-8B1D-5293F75C27EE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
have my device working for now - but the question is - Is the =
documentation and example for =E2=80=9Crootdev=E2=80=9D right or =
not?

=E2=80=94
Mira

On 18 Nov 2022, at 21:13, =
Warner Losh <imp@bsdimp.com> wrote:



On Fri, Nov 18, 2022 at 12:57 PM Chlast=C3=A1k =
Miroslav <mira@chlastak.cz> wrote:
Hi all,

In the /boot/defaults/loader.conf are these options for =
memory disk settings:

#mdroot_load=3D"YES"            =
  # The "mdroot" prefix is arbitrary.
#mdroot_type=3D"md_image"   =
      # Create md(4) disk at boot.
#mdroot_name=3D"/boot/root.img"   # Path to a file =
containing the image.
#rootdev=3D"ufs:/dev/md0"         # Set =
the root filesystem to md(4) device.


But - is this example for rootdev option still right? Because =
=E2=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on =
freebsd 12.3 this does not work and generates error message:

Can=E2=80=99t determine root device


When I use this option with value =E2=80=9C/dev/md0=E2=80=9D =
or =E2=80=9Cmd0=E2=80=9D (even with this option commented out), so =
the machine boots correctly without any =
error.

I think you want vfs.root.mountfrom=3D instead of =
rootdev=3D here.

Warner
 
=E2=80=94
Mira
=

--Apple-Mail=_C9DE10EB-BB9F-4B0A-8B1D-5293F75C27EE--

From nobody Sat Nov 19 20:58:45 2022
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 4NF5c21ylxz4hxNS
	for ; Sat, 19 Nov 2022 20:58:58 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NF5c14lXLz4QQq
	for ; Sat, 19 Nov 2022 20:58:57 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2AJKwjC3033600;
	Sun, 20 Nov 2022 05:58:46 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Sun, 20 Nov 2022 05:58:45 +0900
From: Tomoaki AOKI 
To: =?UTF-8?B?Q2hsYXN0w6Fr?= Miroslav 
Cc: FreeBSD CURRENT 
Subject: Re: loader.conf and rootdev option for memory disk
Message-Id: <20221120055845.366367f1d371ae4d6eb8d747@dec.sakura.ne.jp>
In-Reply-To: 
References: <2E58D34B-F8C5-4291-B019-9E24F56DC3DF@chlastak.cz>
	
	
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4NF5c14lXLz4QQq
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

IIUC, rootdev should be set in loader.env, if needed.
`man 5 loader.conf` has nothing about rootdev variable.

(It's undocumented, IIRC.)


On Sat, 19 Nov 2022 19:57:47 +0100
Chlasták Miroslav  wrote:

> I have my device working for now - but the question is - Is the documentation and example for “rootdev†right or not?
> 
> —
> Mira
> 
> > On 18 Nov 2022, at 21:13, Warner Losh  wrote:
> > 
> > 
> > 
> > On Fri, Nov 18, 2022 at 12:57 PM Chlasták Miroslav > wrote:
> > Hi all,
> > 
> > In the /boot/defaults/loader.conf are these options for memory disk settings:
> > 
> > #mdroot_load="YES"              # The "mdroot" prefix is arbitrary.
> > #mdroot_type="md_image"         # Create md(4) disk at boot.
> > #mdroot_name="/boot/root.img"   # Path to a file containing the image.
> > #rootdev="ufs:/dev/md0"         # Set the root filesystem to md(4) device.
> > 
> > 
> > But - is this example for rootdev option still right? Because “ufs:/dev/md0†works fine on freebsd 12.1, but on freebsd 12.3 this does not work and generates error message:
> > 
> > Can’t determine root device
> > 
> > 
> > When I use this option with value “/dev/md0†or “md0†(even with this option commented out), so the machine boots correctly without any error.
> > 
> > I think you want vfs.root.mountfrom= instead of rootdev= here.
> > 
> > Warner
> >  
> > —
> > Mira
> 


-- 
é’木 知明  [Tomoaki AOKI]    

From nobody Sat Nov 19 21:31:42 2022
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 4NF6L351fJz4j2RR
	for ; Sat, 19 Nov 2022 21:31:55 +0000 (UTC)
	(envelope-from mira@chlastak.cz)
Received: from mxb-1-3f7.seznam.cz (mxb-1-3f7.seznam.cz [IPv6:2a02:598:128:8a00::1000:3f7])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "email-registrator.ops.iszn.cz", Issuer "Servers 2022.1" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NF6L318vGz3G6j
	for ; Sat, 19 Nov 2022 21:31:55 +0000 (UTC)
	(envelope-from mira@chlastak.cz)
Authentication-Results: mx1.freebsd.org;
	none
Received: from email.seznam.cz
	by smtpc-mxb-68545b7b84-q2m5b
	(smtpc-mxb-68545b7b84-q2m5b [2a02:598:128:8a00::1000:3f7])
	id 17a7e74f9b6771bb15d07274;
	Sat, 19 Nov 2022 22:31:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=emailprofi.seznam.cz; s=szn20221014; t=1668893506;
	bh=rmGjO+2iIDRXh+vG4MNZIeVzwix+XV+6O+Uqq5oXHlA=;
	h=Received:From:Message-Id:Content-Type:Mime-Version:Subject:Date:
	 In-Reply-To:Cc:To:References:X-Mailer;
	b=B/EWe7kkUiYL3e2J0uY1WcNl10fPUCpR66uVccMS6qsiZHAfmF0k9oHBSb3eFJNRo
	 WUOR6I5s9qRP3CIp0UJM2FfLE97j/WBVPDapqqJUjW2Wpd4mXU1hSzEzf7YYurTgGz
	 Ikr1OjypWxRGI0GIBg7sw2R8QE4D37xrdOMuEGYPNQiakESnDHgU0FWU/32A3fJxkB
	 XvmE2Bxg5UBjVrX2tBUtepsvb/tLeGTa2xIrWHbs30vi81Mkru/kpyqnkt0Woh7RCY
	 SMBE3DpAvkfIqFPkkE5lQfNFw6gTmgqZofqNT5wMLgicp01qTXsPhECoWGA5h5fnL8
	 ZeKqe6F2TyJUA==
Received: from [10.10.100.102] (cust.uvtnet.cz [185.63.97.36])
	by email-relay4.ng.seznam.cz (Seznam SMTPD 1.3.140) with ESMTP;
	Sat, 19 Nov 2022 22:31:44 +0100 (CET)  
From: =?utf-8?Q?Chlast=C3=A1k_Miroslav?= 
Message-Id: <97A75B5E-6C38-4CFB-9978-7E254595D980@chlastak.cz>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_50BCB33F-6C39-4359-A528-FC4EA71B940C"
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 13.4 \(3608.120.23.2.7\))
Subject: Re: loader.conf and rootdev option for memory disk
Date: Sat, 19 Nov 2022 22:31:42 +0100
In-Reply-To: <20221120055845.366367f1d371ae4d6eb8d747@dec.sakura.ne.jp>
Cc: FreeBSD CURRENT 
To: Tomoaki AOKI 
References: <2E58D34B-F8C5-4291-B019-9E24F56DC3DF@chlastak.cz>
 
 
 <20221120055845.366367f1d371ae4d6eb8d747@dec.sakura.ne.jp>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-Rspamd-Queue-Id: 4NF6L318vGz3G6j
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:43037, ipnet:2a02:598::/32, country:CZ]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_50BCB33F-6C39-4359-A528-FC4EA71B940C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Look at the file /boot/defaults/loader.conf:

=E2=80=A6
###  Initial memory disk settings  ###########################
#mdroot_load=3D"YES"              # The "mdroot" prefix is arbitrary.
#mdroot_type=3D"md_image"         # Create md(4) disk at boot.
#mdroot_name=3D"/boot/root.img"   # Path to a file containing the image.
#rootdev=3D"ufs:/dev/md0"         # Set the root filesystem to md(4) =
device.
=E2=80=A6

=E2=80=94
Mira

> On 19 Nov 2022, at 21:58, Tomoaki AOKI  =
wrote:
>=20
> IIUC, rootdev should be set in loader.env, if needed.
> `man 5 loader.conf` has nothing about rootdev variable.
>=20
> (It's undocumented, IIRC.)
>=20
>=20
> On Sat, 19 Nov 2022 19:57:47 +0100
> Chlast=C3=A1k Miroslav > =
wrote:
>=20
>> I have my device working for now - but the question is - Is the =
documentation and example for =E2=80=9Crootdev=E2=80=9D right or not?
>>=20
>> =E2=80=94
>> Mira
>>=20
>>> On 18 Nov 2022, at 21:13, Warner Losh > wrote:
>>>=20
>>>=20
>>>=20
>>> On Fri, Nov 18, 2022 at 12:57 PM Chlast=C3=A1k Miroslav =
 >> wrote:
>>> Hi all,
>>>=20
>>> In the /boot/defaults/loader.conf are these options for memory disk =
settings:
>>>=20
>>> #mdroot_load=3D"YES"              # The "mdroot" prefix is =
arbitrary.
>>> #mdroot_type=3D"md_image"         # Create md(4) disk at boot.
>>> #mdroot_name=3D"/boot/root.img"   # Path to a file containing the =
image.
>>> #rootdev=3D"ufs:/dev/md0"         # Set the root filesystem to md(4) =
device.
>>>=20
>>>=20
>>> But - is this example for rootdev option still right? Because =
=E2=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on =
freebsd 12.3 this does not work and generates error message:
>>>=20
>>> Can=E2=80=99t determine root device
>>>=20
>>>=20
>>> When I use this option with value =E2=80=9C/dev/md0=E2=80=9D or =
=E2=80=9Cmd0=E2=80=9D (even with this option commented out), so the =
machine boots correctly without any error.
>>>=20
>>> I think you want vfs.root.mountfrom=3D instead of rootdev=3D here.
>>>=20
>>> Warner
>>>=20
>>> =E2=80=94
>>> Mira
>>=20
>=20
>=20
> --=20
> =E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E  [Tomoaki AOKI]    =
>


--Apple-Mail=_50BCB33F-6C39-4359-A528-FC4EA71B940C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Look =
at the file /boot/defaults/loader.conf:

=E2=80=A6
###  Initial memory disk settings =
 ###########################
#mdroot_load=3D"YES=
"              # The "mdroot" prefix =
is arbitrary.
#mdroot_type=3D"md_image"   =
      # Create md(4) disk at boot.
#mdroot_name=3D"/boot/root.img"   # Path to a file =
containing the image.
#rootdev=3D"ufs:/dev/md0" =
        # Set the root filesystem to md(4) =
device.
=E2=80=A6

=E2=80=94
Mira

On 19 Nov 2022, at 21:58, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:

IIUC, rootdev should be set in =
loader.env, if needed.
`man 5 loader.conf` has nothing about rootdev =
variable.

(It's =
undocumented, IIRC.)


On Sat, 19 Nov 2022 19:57:47 +0100
Chlast=C3=A1k Miroslav =
<mira@chlastak.cz> wrote:

I =
have my device working for now - but the question is - Is the =
documentation and example for =E2=80=9Crootdev=E2=80=9D right or not?

=E2=80=94
Mira

On 18 Nov 2022, at =
21:13, Warner Losh <imp@bsdimp.com> wrote:



On Fri, Nov 18, 2022 at 12:57 PM Chlast=C3=A1k =
Miroslav <mira@chlastak.cz <mailto:mira@chlastak.cz>> wrote:
Hi =
all,

In the /boot/defaults/loader.conf are =
these options for memory disk settings:

#mdroot_load=3D"YES" =
            &n=
bsp;# The "mdroot" prefix is arbitrary.
#mdroot_type=3D"md_image" =
        # Create md(4) disk at =
boot.
#mdroot_name=3D"/boot/root.img"   # Path =
to a file containing the image.
#rootdev=3D"ufs:/dev/md0" =
        # Set the root =
filesystem to md(4) device.


But - is this example for rootdev option still right? Because =
=E2=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on =
freebsd 12.3 this does not work and generates error message:

Can=E2=80=99t determine root device


When I use this option with =
value =E2=80=9C/dev/md0=E2=80=9D or =E2=80=9Cmd0=E2=80=9D (even with =
this option commented out), so the machine boots correctly without any =
error.

I think you want vfs.root.mountfrom=3D=
 instead of rootdev=3D here.

Warner

=E2=80=94
Mira



-- 
=E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=
=8E  [Tomoaki AOKI]    <junchoon@dec.sakura.ne.jp>

=

--Apple-Mail=_50BCB33F-6C39-4359-A528-FC4EA71B940C--

From nobody Sun Nov 20 01:00:46 2022
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 4NFBzK2XDnz4hLYH
	for ; Sun, 20 Nov 2022 01:01:01 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NFBzJ5FHnz3nTr
	for ; Sun, 20 Nov 2022 01:00:59 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2AK10l7M063367;
	Sun, 20 Nov 2022 10:00:47 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Sun, 20 Nov 2022 10:00:46 +0900
From: Tomoaki AOKI 
To: =?UTF-8?B?Q2hsYXN0w6Fr?= Miroslav 
Cc: FreeBSD CURRENT 
Subject: Re: loader.conf and rootdev option for memory disk
Message-Id: <20221120100046.b44741ca341c1593a72f594b@dec.sakura.ne.jp>
In-Reply-To: <97A75B5E-6C38-4CFB-9978-7E254595D980@chlastak.cz>
References: <2E58D34B-F8C5-4291-B019-9E24F56DC3DF@chlastak.cz>
	
	
	<20221120055845.366367f1d371ae4d6eb8d747@dec.sakura.ne.jp>
	<97A75B5E-6C38-4CFB-9978-7E254595D980@chlastak.cz>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4NFBzJ5FHnz3nTr
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

But your previous post shows rootdev= there didn't work, and needed
setting vfs.root.mountfrom=.

OTOH, rootdev= is reported to work in efi/boot/freebsd/loader.env (with
efi loader) on freebsd-users-jp ML (as it's Japanese ML, in Japanese)
this year.

So /boot/defaults/loader.conf (/usr/src/stand/defaults/loader.conf)
should be fixed, and what should be set in loader.env should be
documented.

 *Dedicated brand-new manpage or in boot.8 (or in loader.8 describing
  rootdev, or loader.conf.8 in contrast with itself).


On Sat, 19 Nov 2022 22:31:42 +0100
Chlasták Miroslav  wrote:

> Look at the file /boot/defaults/loader.conf:
> 
> …
> ###  Initial memory disk settings  ###########################
> #mdroot_load="YES"              # The "mdroot" prefix is arbitrary.
> #mdroot_type="md_image"         # Create md(4) disk at boot.
> #mdroot_name="/boot/root.img"   # Path to a file containing the image.
> #rootdev="ufs:/dev/md0"         # Set the root filesystem to md(4) device.
> …
> 
> —
> Mira
> 
> > On 19 Nov 2022, at 21:58, Tomoaki AOKI  wrote:
> > 
> > IIUC, rootdev should be set in loader.env, if needed.
> > `man 5 loader.conf` has nothing about rootdev variable.
> > 
> > (It's undocumented, IIRC.)
> > 
> > 
> > On Sat, 19 Nov 2022 19:57:47 +0100
> > Chlasták Miroslav > wrote:
> > 
> >> I have my device working for now - but the question is - Is the documentation and example for “rootdev†right or not?
> >> 
> >> —
> >> Mira
> >> 
> >>> On 18 Nov 2022, at 21:13, Warner Losh > wrote:
> >>> 
> >>> 
> >>> 
> >>> On Fri, Nov 18, 2022 at 12:57 PM Chlasták Miroslav  >> wrote:
> >>> Hi all,
> >>> 
> >>> In the /boot/defaults/loader.conf are these options for memory disk settings:
> >>> 
> >>> #mdroot_load="YES"              # The "mdroot" prefix is arbitrary.
> >>> #mdroot_type="md_image"         # Create md(4) disk at boot.
> >>> #mdroot_name="/boot/root.img"   # Path to a file containing the image.
> >>> #rootdev="ufs:/dev/md0"         # Set the root filesystem to md(4) device.
> >>> 
> >>> 
> >>> But - is this example for rootdev option still right? Because “ufs:/dev/md0†works fine on freebsd 12.1, but on freebsd 12.3 this does not work and generates error message:
> >>> 
> >>> Can’t determine root device
> >>> 
> >>> 
> >>> When I use this option with value “/dev/md0†or “md0†(even with this option commented out), so the machine boots correctly without any error.
> >>> 
> >>> I think you want vfs.root.mountfrom= instead of rootdev= here.
> >>> 
> >>> Warner
> >>> 
> >>> —
> >>> Mira
> >> 
> > 
> > 
> > -- 
> > é’木 知明  [Tomoaki AOKI]    >
> 


-- 
é’木 知明  [Tomoaki AOKI]    

From nobody Sun Nov 20 03:32:52 2022
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 4NFGLp3bZbz4hlJd
	for ; Sun, 20 Nov 2022 03:33:06 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NFGLp1dNRz43D3
	for ; Sun, 20 Nov 2022 03:33:06 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ed1-x529.google.com with SMTP id b8so1291491edf.11
        for ; Sat, 19 Nov 2022 19:33:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=XUMx4izZRjhFHxRJf6P44fDzusC+WEuQQgGD1SvWrws=;
        b=Oz5iKDFqfaYfsOaw51jgTZ183JKu31H1SY8NjJSoUW1taU0LeXGtVr0PNplLdU403O
         F49IeAl7LbqwZDOQIlTf/YSkQ9mzm0EjhbT0TEqT8FfWM6H4Tc7UP6juQKyKkM//0LN6
         +1QF3dYydCexlehIq5mUJ07/TlcSel1I02tiy6mu4gSoSHTI8pK8XTwc2BdpxxkrsrFW
         X0B4NaGIsglB5Bc0iiByramozugQmIzClQCF3//6+AcWU071LFB5pr/X78VM840DeyLy
         T4iaYc4gb0RKfDW229tx5j0mG1yuJFP6tadd1TrVuqM2VbMfRrfOR4viFE8+AC4wANsI
         GVag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=XUMx4izZRjhFHxRJf6P44fDzusC+WEuQQgGD1SvWrws=;
        b=5vJFP+sDf3lhDSdHyfXG9mISSJGMCvFpGYZrlzIAfQKisNPkoNx7Bcu+GzfyNu0eSF
         ex2NyhqIV+geb7nqkLDUlam9MapcgxvbPgJEJWbnlDhCTOQL/PM/xxcdHNwC7eaiabbh
         9bMlE5AqEESjcoY7vsT6nlW8CrEc71c/f3WDdnESZzeh/Qb9C9rPqBWdKB9j30jlsZza
         yo/10z31IeThKb346hYyMoQoMdw3pK1AFAt8bq081ww3ThYYQNsFPwHY+as5USCAn+Pb
         fU9DVH3Ihwl3gNyfPcxy0BJ3+mUZawPLzZOQ3tm7/UqLuAgL/T1I3pgRyVStkclckMfF
         od/Q==
X-Gm-Message-State: ANoB5pkWcPclO3LXBEUcfwo0oRPjPU6BPFVvnS5sijylAj63lIlkRIds
	kHLW27QzCro6aC2kr4oQs9iv7fbtcCsHsrgzFN+JwwKte0k=
X-Google-Smtp-Source: AA0mqf6iVcyhti3bbIvS6OClNZa3Mggv2rvwthI5kleg6Aev3CqxZ95613IZsEcDlhhSxVp+jlTPit+EJr1dLwP7CFY=
X-Received: by 2002:a05:6402:509:b0:466:7500:b5df with SMTP id
 m9-20020a056402050900b004667500b5dfmr11455534edv.48.1668915184008; Sat, 19
 Nov 2022 19:33:04 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <2E58D34B-F8C5-4291-B019-9E24F56DC3DF@chlastak.cz>
 
  <20221120055845.366367f1d371ae4d6eb8d747@dec.sakura.ne.jp>
 <97A75B5E-6C38-4CFB-9978-7E254595D980@chlastak.cz> <20221120100046.b44741ca341c1593a72f594b@dec.sakura.ne.jp>
In-Reply-To: <20221120100046.b44741ca341c1593a72f594b@dec.sakura.ne.jp>
From: Warner Losh 
Date: Sat, 19 Nov 2022 20:32:52 -0700
Message-ID: 
Subject: Re: loader.conf and rootdev option for memory disk
To: Tomoaki AOKI 
Cc: =?UTF-8?Q?Chlast=C3=A1k_Miroslav?= , 
	FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000b4161705edde9863"
X-Rspamd-Queue-Id: 4NFGLp1dNRz43D3
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000b4161705edde9863
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 19, 2022 at 6:01 PM Tomoaki AOKI 
wrote:

> But your previous post shows rootdev=3D there didn't work, and needed
> setting vfs.root.mountfrom=3D.
>
> OTOH, rootdev=3D is reported to work in efi/boot/freebsd/loader.env (with
> efi loader) on freebsd-users-jp ML (as it's Japanese ML, in Japanese)
> this year.
>
> So /boot/defaults/loader.conf (/usr/src/stand/defaults/loader.conf)
> should be fixed, and what should be set in loader.env should be
> documented.
>
>  *Dedicated brand-new manpage or in boot.8 (or in loader.8 describing
>   rootdev, or loader.conf.8 in contrast with itself).
>

Reading the code it's complicated.

rootdev looks like it overrides the default root... unless
vfs.root.mountfrom
has already been set.


>
> On Sat, 19 Nov 2022 22:31:42 +0100
> Chlast=C3=A1k Miroslav  wrote:
>
> > Look at the file /boot/defaults/loader.conf:
> >
> > =E2=80=A6
> > ###  Initial memory disk settings  ###########################
> > #mdroot_load=3D"YES"              # The "mdroot" prefix is arbitrary.
> > #mdroot_type=3D"md_image"         # Create md(4) disk at boot.
> > #mdroot_name=3D"/boot/root.img"   # Path to a file containing the image=
.
> > #rootdev=3D"ufs:/dev/md0"         # Set the root filesystem to md(4)
> device.
> > =E2=80=A6
> >
> > =E2=80=94
> > Mira
> >
> > > On 19 Nov 2022, at 21:58, Tomoaki AOKI 
> wrote:
> > >
> > > IIUC, rootdev should be set in loader.env, if needed.
> > > `man 5 loader.conf` has nothing about rootdev variable.
> > >
> > > (It's undocumented, IIRC.)
> > >
> > >
> > > On Sat, 19 Nov 2022 19:57:47 +0100
> > > Chlast=C3=A1k Miroslav > w=
rote:
> > >
> > >> I have my device working for now - but the question is - Is the
> documentation and example for =E2=80=9Crootdev=E2=80=9D right or not?
> > >>
> > >> =E2=80=94
> > >> Mira
> > >>
> > >>> On 18 Nov 2022, at 21:13, Warner Losh  imp@bsdimp.com>> wrote:
> > >>>
> > >>>
> > >>>
> > >>> On Fri, Nov 18, 2022 at 12:57 PM Chlast=C3=A1k Miroslav    mira@chlastak.cz>>> wrote:
> > >>> Hi all,
> > >>>
> > >>> In the /boot/defaults/loader.conf are these options for memory disk
> settings:
> > >>>
> > >>> #mdroot_load=3D"YES"              # The "mdroot" prefix is arbitrar=
y.
> > >>> #mdroot_type=3D"md_image"         # Create md(4) disk at boot.
> > >>> #mdroot_name=3D"/boot/root.img"   # Path to a file containing the
> image.
> > >>> #rootdev=3D"ufs:/dev/md0"         # Set the root filesystem to md(4=
)
> device.
> > >>>
> > >>>
> > >>> But - is this example for rootdev option still right? Because
> =E2=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on freebsd=
 12.3 this does
> not work and generates error message:
> > >>>
> > >>> Can=E2=80=99t determine root device
> > >>>
> > >>>
> > >>> When I use this option with value =E2=80=9C/dev/md0=E2=80=9D or =E2=
=80=9Cmd0=E2=80=9D (even with
> this option commented out), so the machine boots correctly without any
> error.
> > >>>
> > >>> I think you want vfs.root.mountfrom=3D instead of rootdev=3D here.
> > >>>
> > >>> Warner
> > >>>
> > >>> =E2=80=94
> > >>> Mira
> > >>
> > >
> > >
> > > --
> > > =E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E  [Tomoaki AOKI]     junchoon@dec.sakura.ne.jp>>
> >
>
>
> --
> =E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E  [Tomoaki AOKI]    
>
>

--000000000000b4161705edde9863
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Nov 19, 2022 at 6:01 PM Tomoa=
ki AOKI <junchoon@dec.sakur=
a.ne.jp> wrote:
But your previous post shows rootdev=3D there didn't work, and n=
eeded

setting vfs.root.mountfrom=3D.



OTOH, rootdev=3D is reported to work in efi/boot/freebsd/loader.env (with
efi loader) on freebsd-users-jp ML (as it's Japanese ML, in Japanese)
this year.



So /boot/defaults/loader.conf (/usr/src/stand/defaults/loader.conf)

should be fixed, and what should be set in loader.env should be

documented.



=C2=A0*Dedicated brand-new manpage or in boot.8 (or in loader.8 describing<=
br>
=C2=A0 rootdev, or loader.conf.8 in contrast with itself).
=


Reading the code it's complicated.

rootdev looks like it overrides the default root... unless vfs.roo=
t.mountfrom
has already been set.
=C2=A0



On Sat, 19 Nov 2022 22:31:42 +0100

Chlast=C3=A1k Miroslav <mira@chlastak.cz> wrote:



> Look at the file /boot/defaults/loader.conf:

> 

> =E2=80=A6

> ###=C2=A0 Initial memory disk settings=C2=A0 #########################=
##

> #mdroot_load=3D"YES"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 # The "mdroot" prefix is arbitrary.

> #mdroot_type=3D"md_image"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0#=
 Create md(4) disk at boot.

> #mdroot_name=3D"/boot/root.img"=C2=A0 =C2=A0# Path to a file=
 containing the image.

> #rootdev=3D"ufs:/dev/md0"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0#=
 Set the root filesystem to md(4) device.

> =E2=80=A6

> 

> =E2=80=94

> Mira

> 

> > On 19 Nov 2022, at 21:58, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> =
wrote:

> > 

> > IIUC, rootdev should be set in loader.env, if needed.

> > `man 5 loader.conf` has nothing about rootdev variable.

> > 

> > (It's undocumented, IIRC.)

> > 

> > 

> > On Sat, 19 Nov 2022 19:57:47 +0100

> > Chlast=C3=A1k Miroslav <mira@chlastak.cz <mailto:mira@chlastak.cz>> wrote:

> > 

> >> I have my device working for now - but the question is - Is t=
he documentation and example for =E2=80=9Crootdev=E2=80=9D right or not?
> >> 

> >> =E2=80=94

> >> Mira

> >> 

> >>> On 18 Nov 2022, at 21:13, Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com>> wro=
te:

> >>> 

> >>> 

> >>> 

> >>> On Fri, Nov 18, 2022 at 12:57 PM Chlast=C3=A1k Miroslav &=
lt;mira@chlastak.cz <mailto:mira@ch=
lastak.cz> <mailto:mira@chlastak.cz <mailto:mira@chlastak.cz>>> wrote:

> >>> Hi all,

> >>> 

> >>> In the /boot/defaults/loader.conf are these options for m=
emory disk settings:

> >>> 

> >>> #mdroot_load=3D"YES"=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 # The "mdroot" prefix is arbitrary.

> >>> #mdroot_type=3D"md_image"=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0# Create md(4) disk at boot.

> >>> #mdroot_name=3D"/boot/root.img"=C2=A0 =C2=A0# P=
ath to a file containing the image.

> >>> #rootdev=3D"ufs:/dev/md0"=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0# Set the root filesystem to md(4) device.

> >>> 

> >>> 

> >>> But - is this example for rootdev option still right? Bec=
ause =E2=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on free=
bsd 12.3 this does not work and generates error message:

> >>> 

> >>> Can=E2=80=99t determine root device

> >>> 

> >>> 

> >>> When I use this option with value =E2=80=9C/dev/md0=E2=80=
=9D or =E2=80=9Cmd0=E2=80=9D (even with this option commented out), so the =
machine boots correctly without any error.

> >>> 

> >>> I think you want vfs.root.mountfrom=3D instead of rootdev=
=3D here.

> >>> 

> >>> Warner

> >>> 

> >>> =E2=80=94

> >>> Mira

> >> 

> > 

> > 

> > -- 

> > =E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E=C2=A0 [Tomoaki AOKI]=C2=A0 =
=C2=A0 <j=
unchoon@dec.sakura.ne.jp <mailto:junchoon@dec.sakura.ne.jp>>

> 





-- 

=E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E=C2=A0 [Tomoaki AOKI]=C2=A0 =C2=A0 <=
;junchoon@de=
c.sakura.ne.jp>






--000000000000b4161705edde9863--

From nobody Sun Nov 20 03:37:58 2022
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 4NFGSh6fDbz4hlnT
	for ; Sun, 20 Nov 2022 03:38:12 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NFGSg6TW0z44JQ
	for ; Sun, 20 Nov 2022 03:38:11 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=hPfyDA4E;
	spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::636) smtp.mailfrom=wlosh@bsdimp.com;
	dmarc=none
Received: by mail-ej1-x636.google.com with SMTP id vv4so12433197ejc.2
        for ; Sat, 19 Nov 2022 19:38:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=cacDhosgfswcgvZv1/LceQO3x011BALySjeuyuQefwY=;
        b=hPfyDA4EITs0xVFsIrRJFNHaWuhLFvOlRkTrm7nx00Bz4nQHEThSoh4JGlp7YAxTi9
         zAnAMbaNqC83QatbhJAtIvAc0xLCvNwyfTiTYipmfKoNdtP8TbKlJq0n1LlbHMfMxkio
         VNlVwYnSLkMYBeIx48C4A0TIYbxUzDwrYWswnDAooIXFwdp7sJUl9HTin0rLG0S1FqUE
         GYJZYN+qPfrsgHSCYN2uVfQ+j51qwvxfwFJIOuJcxdj1SAhQ0bC9TnhWAKVbTv4J54iI
         2hZeuT8u+DPKSKnlx2PgAflrwwMhsRb19ISULrFFLpZ9rvgQZ2oP7zgEWjAOibkpKAtk
         WH7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=cacDhosgfswcgvZv1/LceQO3x011BALySjeuyuQefwY=;
        b=TEbb/AwdLziUW9c3L6J1ldYt8J31LL475WB+mrd9Azx241w5QcCr/DhNG7RlJEnF2a
         Q3OjC3C0GalyuZ0ca8daz38duCSWlIvyhUtvLCwGXW7ZBeEg57LZXICgOulr0ROfOPmu
         1OF+lcivt+LDnvVR8nGkIBtokK3itLNeWv4xFowCTVa+ulct1ViM6nKD17lCmtGUO0zG
         x0Vwrasltib9uOirw463MFAdLrJpRZZG+fbjONAq3jNbc9kwM3TQ5wYZ5utaoqmdiUyu
         7bZ3IcVMzvUpDzGNATAatyA/7K2513jz8kt2WX3wrQ0lLARunCN9Srfc7Q+IxR+/ePRO
         zKVg==
X-Gm-Message-State: ANoB5pkDCzieLAG2SN+/By+8/3jpcOq/amVIe2lQ0bLspoW4TKeiHYGE
	SAmOTxtsFpkb2rRQeVYD+cLf++JH8dSjeUrfUW7WWcrwZS4=
X-Google-Smtp-Source: AA0mqf60rsdfeSSW5wMOPLctrtsMqcY8WXzjbXmvhAv1zODXCyMR2uLsYKPvb/rxY3vx98ey/Pk8tH1hTqzpCLCjHLg=
X-Received: by 2002:a17:906:b210:b0:7ae:d116:fabb with SMTP id
 p16-20020a170906b21000b007aed116fabbmr10888805ejz.317.1668915490445; Sat, 19
 Nov 2022 19:38:10 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <2E58D34B-F8C5-4291-B019-9E24F56DC3DF@chlastak.cz>
 
  <20221120055845.366367f1d371ae4d6eb8d747@dec.sakura.ne.jp>
 <97A75B5E-6C38-4CFB-9978-7E254595D980@chlastak.cz> <20221120100046.b44741ca341c1593a72f594b@dec.sakura.ne.jp>
 
In-Reply-To: 
From: Warner Losh 
Date: Sat, 19 Nov 2022 20:37:58 -0700
Message-ID: 
Subject: Re: loader.conf and rootdev option for memory disk
To: Tomoaki AOKI 
Cc: =?UTF-8?Q?Chlast=C3=A1k_Miroslav?= , 
	FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000f7f4dc05eddeaa0f"
X-Spamd-Result: default: False [-2.98 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.977];
	FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com];
	R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	R_SPF_NA(0.00)[no SPF record];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com];
	RCPT_COUNT_THREE(0.00)[3];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[bsdimp.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NFGSg6TW0z44JQ
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--000000000000f7f4dc05eddeaa0f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 19, 2022 at 8:32 PM Warner Losh  wrote:

>
>
> On Sat, Nov 19, 2022 at 6:01 PM Tomoaki AOKI 
> wrote:
>
>> But your previous post shows rootdev=3D there didn't work, and needed
>> setting vfs.root.mountfrom=3D.
>>
>> OTOH, rootdev=3D is reported to work in efi/boot/freebsd/loader.env (wit=
h
>> efi loader) on freebsd-users-jp ML (as it's Japanese ML, in Japanese)
>> this year.
>>
>> So /boot/defaults/loader.conf (/usr/src/stand/defaults/loader.conf)
>> should be fixed, and what should be set in loader.env should be
>> documented.
>>
>>  *Dedicated brand-new manpage or in boot.8 (or in loader.8 describing
>>   rootdev, or loader.conf.8 in contrast with itself).
>>
>
> Reading the code it's complicated.
>
> rootdev looks like it overrides the default root... unless
> vfs.root.mountfrom
> has already been set.
>

It's also a name in the 'boot loader' device namespace, not in the FreeBSD
device namespace, so it shouldn't be 'ufs:/dev/foo' but rather 'disk1p3:'
or similar. It's only when it's 'zfs:' that the boot loader device name
space
and the FreeBSD device name space overlap (also zfs: is special cased).

It's also a bit complicated because it's not used as 'currdev' either. It's
strictly a hint for where to mount FreeBSD's root front, but it's not used
to find boot scripts and config files. That's always done with 'currdev'
if no device is specified.

It's also a little more complex with OpenFirmware is involved, but
that's rare these days, so I'll not go into that.

Warner


>
>> On Sat, 19 Nov 2022 22:31:42 +0100
>> Chlast=C3=A1k Miroslav  wrote:
>>
>> > Look at the file /boot/defaults/loader.conf:
>> >
>> > =E2=80=A6
>> > ###  Initial memory disk settings  ###########################
>> > #mdroot_load=3D"YES"              # The "mdroot" prefix is arbitrary.
>> > #mdroot_type=3D"md_image"         # Create md(4) disk at boot.
>> > #mdroot_name=3D"/boot/root.img"   # Path to a file containing the imag=
e.
>> > #rootdev=3D"ufs:/dev/md0"         # Set the root filesystem to md(4)
>> device.
>> > =E2=80=A6
>> >
>> > =E2=80=94
>> > Mira
>> >
>> > > On 19 Nov 2022, at 21:58, Tomoaki AOKI 
>> wrote:
>> > >
>> > > IIUC, rootdev should be set in loader.env, if needed.
>> > > `man 5 loader.conf` has nothing about rootdev variable.
>> > >
>> > > (It's undocumented, IIRC.)
>> > >
>> > >
>> > > On Sat, 19 Nov 2022 19:57:47 +0100
>> > > Chlast=C3=A1k Miroslav > =
wrote:
>> > >
>> > >> I have my device working for now - but the question is - Is the
>> documentation and example for =E2=80=9Crootdev=E2=80=9D right or not?
>> > >>
>> > >> =E2=80=94
>> > >> Mira
>> > >>
>> > >>> On 18 Nov 2022, at 21:13, Warner Losh > imp@bsdimp.com>> wrote:
>> > >>>
>> > >>>
>> > >>>
>> > >>> On Fri, Nov 18, 2022 at 12:57 PM Chlast=C3=A1k Miroslav <
>> mira@chlastak.cz  > >> wrote:
>> > >>> Hi all,
>> > >>>
>> > >>> In the /boot/defaults/loader.conf are these options for memory dis=
k
>> settings:
>> > >>>
>> > >>> #mdroot_load=3D"YES"              # The "mdroot" prefix is arbitra=
ry.
>> > >>> #mdroot_type=3D"md_image"         # Create md(4) disk at boot.
>> > >>> #mdroot_name=3D"/boot/root.img"   # Path to a file containing the
>> image.
>> > >>> #rootdev=3D"ufs:/dev/md0"         # Set the root filesystem to md(=
4)
>> device.
>> > >>>
>> > >>>
>> > >>> But - is this example for rootdev option still right? Because
>> =E2=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on freebs=
d 12.3 this does
>> not work and generates error message:
>> > >>>
>> > >>> Can=E2=80=99t determine root device
>> > >>>
>> > >>>
>> > >>> When I use this option with value =E2=80=9C/dev/md0=E2=80=9D or =
=E2=80=9Cmd0=E2=80=9D (even with
>> this option commented out), so the machine boots correctly without any
>> error.
>> > >>>
>> > >>> I think you want vfs.root.mountfrom=3D instead of rootdev=3D here.
>> > >>>
>> > >>> Warner
>> > >>>
>> > >>> =E2=80=94
>> > >>> Mira
>> > >>
>> > >
>> > >
>> > > --
>> > > =E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E  [Tomoaki AOKI]    > junchoon@dec.sakura.ne.jp>>
>> >
>>
>>
>> --
>> =E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E  [Tomoaki AOKI]    
>>
>>

--000000000000f7f4dc05eddeaa0f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Nov 19, 2022 at 8:32 PM Warne=
r Losh <imp@bsdimp.com> wrote:<=
br>


On Sat, Nov 19, 2022 at 6:01 PM Tomoaki AOKI <junchoon@dec.sak=
ura.ne.jp> wrote:
But your previous post shows rootdev=3D there didn't work, a=
nd needed

setting vfs.root.mountfrom=3D.



OTOH, rootdev=3D is reported to work in efi/boot/freebsd/loader.env (with
efi loader) on freebsd-users-jp ML (as it's Japanese ML, in Japanese)
this year.



So /boot/defaults/loader.conf (/usr/src/stand/defaults/loader.conf)

should be fixed, and what should be set in loader.env should be

documented.



=C2=A0*Dedicated brand-new manpage or in boot.8 (or in loader.8 describing<=
br>
=C2=A0 rootdev, or loader.conf.8 in contrast with itself).
=


Reading the code it's complicated.

rootdev looks like it overrides the default root... unless vfs.roo=
t.mountfrom
has already been set.

It's also a name in the 'boot loader' de=
vice namespace, not in the FreeBSD
device namespace, so it should=
n't be 'ufs:/dev/foo' but rather 'disk1p3:'
o=
r similar. It's only when it's 'zfs:' that the boot loader =
device name space
and the FreeBSD device name space overlap (also=
 zfs: is special cased).

It's also a bit compl=
icated because it's not used as 'currdev' either. It's
strictly a hint for where to mount FreeBSD's root front, but it&#=
39;s not used
to find boot scripts and config files. That's a=
lways done with 'currdev'
if no device is specified.

It's also a little more complex with OpenFirmware =
is involved, but
that's rare these days, so I'll not go i=
nto that.

Warner
=C2=A0



On Sat, 19 Nov 2022 22:31:42 +0100

Chlast=C3=A1k Miroslav <mira@chlastak.cz> wrote:



> Look at the file /boot/defaults/loader.conf:

> 

> =E2=80=A6

> ###=C2=A0 Initial memory disk settings=C2=A0 #########################=
##

> #mdroot_load=3D"YES"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 # The "mdroot" prefix is arbitrary.

> #mdroot_type=3D"md_image"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0#=
 Create md(4) disk at boot.

> #mdroot_name=3D"/boot/root.img"=C2=A0 =C2=A0# Path to a file=
 containing the image.

> #rootdev=3D"ufs:/dev/md0"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0#=
 Set the root filesystem to md(4) device.

> =E2=80=A6

> 

> =E2=80=94

> Mira

> 

> > On 19 Nov 2022, at 21:58, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> =
wrote:

> > 

> > IIUC, rootdev should be set in loader.env, if needed.

> > `man 5 loader.conf` has nothing about rootdev variable.

> > 

> > (It's undocumented, IIRC.)

> > 

> > 

> > On Sat, 19 Nov 2022 19:57:47 +0100

> > Chlast=C3=A1k Miroslav <mira@chlastak.cz <mailto:mira@chlastak.cz>> wrote:

> > 

> >> I have my device working for now - but the question is - Is t=
he documentation and example for =E2=80=9Crootdev=E2=80=9D right or not?
> >> 

> >> =E2=80=94

> >> Mira

> >> 

> >>> On 18 Nov 2022, at 21:13, Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com>> wro=
te:

> >>> 

> >>> 

> >>> 

> >>> On Fri, Nov 18, 2022 at 12:57 PM Chlast=C3=A1k Miroslav &=
lt;mira@chlastak.cz <mailto:mira@ch=
lastak.cz> <mailto:mira@chlastak.cz <mailto:mira@chlastak.cz>>> wrote:

> >>> Hi all,

> >>> 

> >>> In the /boot/defaults/loader.conf are these options for m=
emory disk settings:

> >>> 

> >>> #mdroot_load=3D"YES"=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 # The "mdroot" prefix is arbitrary.

> >>> #mdroot_type=3D"md_image"=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0# Create md(4) disk at boot.

> >>> #mdroot_name=3D"/boot/root.img"=C2=A0 =C2=A0# P=
ath to a file containing the image.

> >>> #rootdev=3D"ufs:/dev/md0"=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0# Set the root filesystem to md(4) device.

> >>> 

> >>> 

> >>> But - is this example for rootdev option still right? Bec=
ause =E2=80=9Cufs:/dev/md0=E2=80=9D works fine on freebsd 12.1, but on free=
bsd 12.3 this does not work and generates error message:

> >>> 

> >>> Can=E2=80=99t determine root device

> >>> 

> >>> 

> >>> When I use this option with value =E2=80=9C/dev/md0=E2=80=
=9D or =E2=80=9Cmd0=E2=80=9D (even with this option commented out), so the =
machine boots correctly without any error.

> >>> 

> >>> I think you want vfs.root.mountfrom=3D instead of rootdev=
=3D here.

> >>> 

> >>> Warner

> >>> 

> >>> =E2=80=94

> >>> Mira

> >> 

> > 

> > 

> > -- 

> > =E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E=C2=A0 [Tomoaki AOKI]=C2=A0 =
=C2=A0 <j=
unchoon@dec.sakura.ne.jp <mailto:junchoon@dec.sakura.ne.jp>>

> 





-- 

=E9=9D=92=E6=9C=A8 =E7=9F=A5=E6=98=8E=C2=A0 [Tomoaki AOKI]=C2=A0 =C2=A0 <=
;junchoon@de=
c.sakura.ne.jp>








--000000000000f7f4dc05eddeaa0f--

From nobody Mon Nov 21 03:48:58 2022
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 4NFth11WT9z4hCkq
	for ; Mon, 21 Nov 2022 03:50:09 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NFth00wxhz46WM
	for ; Mon, 21 Nov 2022 03:50:08 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=BxsDfZgj;
	spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::1136 as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-3a4c2c83300so6312867b3.13
        for ; Sun, 20 Nov 2022 19:50:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=LyEgcMDewvLIc1qY+Siti4IMendDb8bUL2v1yYiVc9k=;
        b=BxsDfZgjJYr9SvEBClsadrmFUc6yK8VEdLOJPyZhjy0fq2RJmlWKjXMvvlShsjdYws
         jQhRQffHNqV9+AEVPzv8LDYG4RhL59s4OGLaGPuIrPgis3O8r6mnOt5NDQqiYTVNlzZn
         TJj9pn+QhRHrv6hOZTbscEESpZaOmAPfCG/hiKRA/x0GErVbMp2GzQwOBQsIqfNjy7Dg
         MOu7uoTkhjXbxqS+lQLVdPkEUKr7DG3ZCDkZY+1ahgbRt6omaClNIdtcwFOlY7HhoKp2
         Bz0YCaErah3oTa613ozGbBkDckJZ18mFjGJ16LH36bOP0PN+MGIOTA/Mt/T642B7W68s
         pduQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=LyEgcMDewvLIc1qY+Siti4IMendDb8bUL2v1yYiVc9k=;
        b=pTL9S7MRxFa/6XfAUln93tgd0mK1xYo4/2jkHxK8f2mXOUT+MwHAHDPdd2+Rjlv4x5
         zEX7+vLxmIT3KWwdgmiVKx8bNnEs4DY2xXQZAMbPMTZ85D1zTqEJpHR4HnxCQanOdyuc
         oCgbUwYAu/3GLeIOJ3vSalGfpi106B7JxRmRK1nh4Q5g4a4sfsUSq0imc4kFaXjFX7+p
         lENZ+jLodf8tk9fwoucJ4DF2ySvne+dlac/6SZ5Dfxev0Rg9z/fT12ofvQeREwVqPCtU
         YlVIlmENwngOeewWUP8TkX+ghGxzthQxrtNJIJecXBAmfw24IPP8E7/ECJ36VfOARJ/W
         YJIQ==
X-Gm-Message-State: ANoB5pmfmLYH9HypjoYc6BsLGpxZaMFuvy44Z4RAIMFG78fVrw6Kck9m
	nzqB/hL0c6SEjT0RFZxX/2Td39ao3IVEwdlOO8jY5XTRu3o=
X-Google-Smtp-Source: AA0mqf6g0UtGXx/+87KUfp+6aWEH4PmIH5Z0hNAOEOnq4uu4n8QOSU5xRGv0rmBkbKFvMIGYqscoaEIcywI4co+/DI4=
X-Received: by 2002:a81:ff09:0:b0:367:6bb7:9ba9 with SMTP id
 k9-20020a81ff09000000b003676bb79ba9mr15181689ywn.231.1669002606565; Sun, 20
 Nov 2022 19:50:06 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
 
  
 
 
 <1722758786.127406.1667909706281@localhost> <1E33E6A3-ABB8-4804-B2A2-0E95E853C860@yahoo.com>
 
In-Reply-To: 
From: Archimedes Gaviola 
Date: Mon, 21 Nov 2022 11:48:58 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Mark Millard 
Cc: Ronald Klop , freebsd-current 
Content-Type: multipart/alternative; boundary="0000000000007e5df705edf2f368"
X-Spamd-Result: default: False [-2.45 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.987];
	NEURAL_SPAM_MEDIUM(0.54)[0.540];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1136:from];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TAGGED_FROM(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FREEMAIL_TO(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_TLS_LAST(0.00)[]
X-Rspamd-Queue-Id: 4NFth00wxhz46WM
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--0000000000007e5df705edf2f368
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 9, 2022 at 10:15 AM Archimedes Gaviola <
archimedes.gaviola@gmail.com> wrote:

>
>
> On Wed, Nov 9, 2022 at 1:37 AM Mark Millard  wrote:
>
>> On Nov 8, 2022, at 04:15, Ronald Klop  wrote:
>>
>> > Van: Warner Losh 
>> > Datum: dinsdag, 8 november 2022 04:28
>> > Aan: Archimedes Gaviola > > . . .
>> > ...
>> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 4096
>> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
>> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size:
>> 40960
>> > pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to
>> allocate a page
>> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size:
>> 28672
>> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
>> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 4096
>> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 8192
>> >   This means that paging to the swap partition and/or swap file took
>> too long (> 30 seconds... that's all that indefinite means). It also means
>> that it can't write to backing store dirty pages to give to another
>> process...
>> >   Typical reason is that the disk / flash is not responsive to writes
>> for some reason. You'll need to find why... I'd look at trims.
>> >   Or.... if you can't change the disk... you need to put less memory
>> pressure on it..
>> >   Warner
>> >
>> >
>> >
>> > NB: a way to put less memory pressure on it is not using -j3, but -j2
>> or -j1 in your make command.
>> >
>>
>
> Hi Mark,
>
>
>> Extending Ronold's comment: If things are really taking this
>> long for the paging I/O, you might actually find, say, -j2
>> takes less elapsed time than -j3 because of the latencies
>> involved in -j3 causing more overall delay.
>>
>
> Yes I'll take these options on lowering down N in the -jN parameter as my
> next steps. So far so good with -j3, ongoing build is still observed for 17
> hours now.
>
>
>>
>> vm.pfault_oom_attempts=-1 would still be appropriate for avoiding
>> I/O kills at any -jN: the smaller -jN just makes the issue less
>> likely, not impossible. (Again, presuming sufficient swap/paging
>> space if deadlock is to be well avoided.)
>>
>
> The ongoing build is at the moment on
> /usr/src/contrib/llvm-project/llvm/lib/*. I'm observing from time-to-time
> if the error will occur again.
>
>
>> (I use NVMe or SSD USB media that do not get such long delays but
>> fit the power limitations of the context. I have about as little
>> on microsd card media as I can get away with in my context. I also
>> avoid spinning rust. Thus I've only gotten "indefinite wait buffer"
>> or the like back before such was true, long ago.)
>>
>
> Okay thanks for sharing this one. Keeping this in my mind just in case I
> needed these types of media soon.
>
> Thanks and best regards,
> Archimedes
>

Hi Mark,

As a recap on the kernel tunables, the changes are the following,

root@generic:~ # sysctl -a | grep oom
vm.pageout_oom_seq: 120
vm.pfault_oom_wait: 10
vm.pfault_oom_attempts: -1

With -j1 and -j2 options, both were able to complete the kernel and
buildworld compilation in 103 and 84 hours respectively. Though I still
could see messages on "swap_pager: indefinite wait buffer: bufobj" but
definitely it's ignorable as it survived the compilation process. With the
-j3 option, it failed along the course of compilation, it encountered the
previous error on "failed to reclaim memory" but this time this error is
not that relevant as -j1 and -j2 already works. Preferably with -j2 as the
appropriate choice for my RPi 3B build setup.

Thanks and best regards,
Archimedes

--0000000000007e5df705edf2f368
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Nov 9, 2022 at 10:15 AM Archi=
medes Gaviola <archimede=
s.gaviola@gmail.com> wrote:


On Wed, Nov 9, 202=
2 at 1:37 AM Mark Millard <marklmi@yahoo.com> wrote:
On Nov 8, 2022, at 04:15, Ronald Klop <ronald-lists@klop.ws<=
/a>> wrote:



> Van: Warner Losh <imp@bsdimp.com>

> Datum: dinsdag, 8 november 2022 04:28

> Aan: Archimedes Gaviola <archimedes.gaviola@gmail.com

> . . .

> ...

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: 40=
96

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096=


> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: 40=
960

> pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to=
 allocate a page

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: 28=
672

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192=


> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: 40=
96

> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: 81=
92

>=C2=A0 =C2=A0This means that paging to the swap partition and/or swap f=
ile took too long (> 30 seconds... that's all that indefinite means)=
. It also means that it can't write to backing store dirty pages to giv=
e to another process...

>=C2=A0 =C2=A0Typical reason is that the disk / flash is not responsive =
to writes for some reason. You'll need to find why... I'd look at t=
rims.

>=C2=A0 =C2=A0Or.... if you can't change the disk... you need to put=
 less memory pressure on it..

>=C2=A0 =C2=A0Warner

>=C2=A0 =C2=A0

> 

> 

> NB: a way to put less memory pressure on it is not using -j3, but -j2 =
or -j1 in your make command.

> 

Hi Mark,
=C2=A0

Extending Ronold's comment: If things are really taking this

long for the paging I/O, you might actually find, say, -j2

takes less elapsed time than -j3 because of the latencies

involved in -j3 causing more overall delay.

=

Yes I'll take these options on lowering down N in the -jN paramete=
r as my next steps. So far so good with -j3, ongoing build is still observe=
d for 17 hours now.
=C2=A0 



vm.pfault_oom_attempts=3D-1 would still be appropriate for avoiding

I/O kills at any -jN: the smaller -jN just makes the issue less

likely, not impossible. (Again, presuming sufficient swap/paging

space if deadlock is to be well avoided.)

The ongoing build is at the moment on /usr/src/contrib/llvm-project/llvm=
/lib/*. I'm observing from time-to-time if the error will occur again.<=
br>
=C2=A0

(I use NVMe or SSD USB media that do not get such long delays but

fit the power limitations of the context. I have about as little

on microsd card media as I can get away with in my context. I also

avoid spinning rust. Thus I've only gotten "indefinite wait buffer=
"

or the like back before such was true, long ago.)

=

Okay thanks for sharing this one. Keeping this in my mind just i=
n case I needed these types of media soon.

Thanks =
and best regards,
Archimedes

Hi Mark,

As a recap on the kerne=
l tunables, the changes are the following,

roo=
t@generic:~ # sysctl -a | grep oom
vm.pageout_oom_seq: 120
vm.pfault_=
oom_wait: 10
vm.pfault_oom_attempts: -1

With -j=
1 and -j2 options, both were able to complete the kernel and buildworld com=
pilation in 103 and 84 hours respectively. Though I still could see message=
s on "swap_pager: indefinite wait buffer: bufobj" but definitely =
it's ignorable as it survived the compilation process. With the -j3 opt=
ion, it failed along the course of compilation, it encountered the previous=
 error on "failed to reclaim memory" but this time this error is =
not that relevant as -j1 and -j2 already works. Preferably with -j2 as the =
appropriate choice for my RPi 3B build setup.

Than=
ks and best regards,
Archimedes


--0000000000007e5df705edf2f368--

From nobody Mon Nov 21 04:24:15 2022
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 4NFvRm4BZvz4hMnp
	for ; Mon, 21 Nov 2022 04:24:36 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NFvRk5m0lz4Cgj
	for ; Mon, 21 Nov 2022 04:24:34 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=MUnCBLJY;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669004672; bh=hARqPhrZOEwbkHqwMKU77+oGgweMSRYX1MXWpD/wAUo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=MUnCBLJYXxzsCs4xW0xbFu226UcCt3ELt98qTSgeoa+XeZBWPy4nvXj7/s9GBVsCNw0RUG04tT3eQkmUf69FOE8W+9ZfCQGEAIAG5o8ebJe/ce70+e8o5tXa+rVxjUPPDujcXETR3V15tJx4D2kExBOaedtArTbMa9rCc8lmWMdUb77R/JznlJvyJjLTCORBbmMIuNnhJ417VdQMS6sPVhB5VbvNmUgEYplwX8a6zAb4bRodfWqWLuFnzcke/E6ZBeP2elhndFeN2Yj7x5FKWzIzcozbjOmM78J3NRfB++K7Y9H0JUB7tVDSGZnDopEAAlUMxiPwVhNLJG+qTs5H8Q==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669004672; bh=k0x9qmQ4izj/KZJPQ8bVdd9Kti5TLfTI1jJ7xzsWfdC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BgpG72o7ui2J2kHgxcjrPjsi2xfR+DjvaddEOnx78Tf/EayU96a4hxtbEG/F8sM2MfK3eBQDpiF40JxMRoOZv/218r1VF6TgpkakBtDxMnswESZGF+3izGkv7zC0Vg5R0VI5EJmiVQOE4ecZ87YWL2HC4QatWM4H1eCURZYwX4c91k2sxxxQmbbtqB+/lgG06ya/nnCatjmr1bzupA9TBj+HDOdAQgW+JntMPFHPCNL0TJFR53zx0gVCtfT/J1zp3b0Jy0xF/6Io5QHyk+xt67g5lDPMkwzTXXJDIZCuHPMhmpds6l4RSecbqRh5Og14LqtTH2inmx4Y2FHMqc2UKQ==
X-YMail-OSG: lbOpOHMVM1nBkKfuY8V_6YPVRqNXpRT9dhxu.5K7QoAggNjeeqTFVjjtj.jV7vL
 z0UoOaC.M0KJIsJGWZslMX8jsp6reafjbx8LpZ97sX9aVuFwpz_N0Egc6u26YAYC92h_W6LlzRJa
 aawbhjXR5opntbdUdhpEITFAz1geCvoCN1JTLBSwV.fOr4OLCWVdCE6qgjhXanJEMbuGpILDHPRG
 xUCCx.ld4HlQ3.zUPH7p4ukvFdnQVl1oIjGHqsFs27mSjf8GM3ke8faumrmruTDWZPuwGJKBQ7zw
 C5AiiokKAQkeNsodP4tJre4CFYgI8m59ynM8Hk2FW5ddIiV5DFY7qDa0yVtPyS.VS5kyHmfZR6kP
 9h86Mt8KDusj710aBwmlg_gbJMlJbwZUh.NI7rMvoLsVbsfLFMhl5kZBX.Wrx_l.3Gkty8C07wF_
 RVl0mbcFheg1PS.pFtVGPVS1bLZvYawbGjXo4M8JDWBHGaoz1IeZiUrjCLKQBHgWUDoeIk1s8MQc
 YbMWT7rGiMBvQ3jpGxi3TAwAoH1qwky9EHPGdj4Y5lYWAU.ZoeQMWH8fk8lCS9kOfaNxfEOM5UGw
 gBRG12ljHjAB685X_4r9yDgd2ONXQcqy6nII3orCRw3fvnPh_8wOE68Ai7mfvbg.cB2nUbZ_sYQS
 dys4X2KDANNNXqi2WjEK869JgQuX3SHALfE7NYaln6xT0dG2h0erOADagfLGqhivKgJu1JEDSeCa
 Cus4aOcL6kmiSG2xR_EKkXRaqkuHKsl8nZq8NRXOGWo9Ka7TQCeDJTHwnWANRPBYyBTDc3mNjy8V
 0r1p2sLTmbIo1.siQslOrLD1vQBdVdtCVWUwLEIMUdp_3Xqheo8XePEfvIZlYK11nqJx2cD31Wgr
 HjItYFI84YXKpwsM10HuDM3UsjaombwC86LmExpqtUdo9zS_dvAN6nq8wKGpDIiJ0kr..rE3Xzcq
 zC9VgSYKID49UEz0Y3Si.i_tqQD9sriPJOiVKk2gXPS7hdD7OM66vk7wfFu3AaJYktjgjMBOKMap
 Fahq9Izk9xEfWIk650wSfTibJ2HFAj00fCO2_6VwMSVZ0Oo7GicIvpGwNl11qDdZxCEVpA9zQZuU
 ybiWDR6Iy9wQGc0fdq_wNUbnq1dSpWo3sWXFCoDhF2SDyqdX5rcXljqAHGJKaW22a_xSdPnCrFyf
 zTVTrL.6e5SXCseerxHs4AiIU4.sO_3I35VUjSobYFGp7UNr79dEJQDzeV4pB43TdYPUP9lt.ZK7
 tXaz2OFJhfxivOlbLX.HXBTuV8VSpBAkdFYqOW_lcJ4SKBZIRJQyzWD313vCC18r29gv61jezM4T
 zjblykSw1wIRxkJwL7xPUrUanhLVoIcjRwvCWJPH53PG0ecBCKQvPRXP6rsw03Zre_TTvk7TMEM_
 rSyFehqArQXBuL0T4bQyYOB_Iu5t9AZNpV5.fW2ifzgpAELbOi9Em37YIciLkUJe_voiAEE7VdVT
 FyehCFNJ36G1sz4swgSxy9Dt2b5HODoIdhrNHplUDaJnvgs9xxXRGK3VMomRLxUKby0W5NRklCU0
 D10ODjab.QUyjnK2aC4De3EKZTOFUAoO3QD6jDRJ7yveQUNvqJnn1RtnaniCEmd56MuCwomIa42e
 pJvv4PFh07pANjCL.wfv3hEbfYIEPhfe7pWJZXJ_ONHgrPWwajog1LxYti7gt2KpvK_ffNlAd7fY
 EIsVv2ZM9f3mZqZXAzsQtjwzdrTypq_UlIRAhI.wEPEfypysb.rhLU3eXiflrUf71ImhMujPfVOs
 gs.ZbI3oETL0NDgFtOQmCPwVxfEd5iFvpaCL7nAMX0u92nB3sBEBC2pAwuwtj5ny6AcmB_bZaUCn
 omsSkODNNiPTo2jJK1Zp9Sxe_xxiJVe1MHRPAqzp6lQ1wAzeochDyGL.BvGadJOJd0XafOqrtR7B
 bWsG9TW.dSAsmm0K6NXtdKtflOEZw_dM8cV9Ez3MaT1ANAzGKcaFAECd2P0QSToGtgDwEzjbf5HL
 DfzOLgoNGbHtqOnjFePIrFvV29Cg5Si5kHFE0.Bw182uyJUzMz3IxWSH84.1cOCYsKyRfRTk7c2b
 NuBkuXkHFxD9LkcJ4g2SA1SlRW6zd_de5eY8zdtJshM0.XBSgtLdLCdSFyLBhItWbbEtiGmvp0rR
 o87WZEa4ueH5k7HnSwyy.nh0KRHu_6bMSHtvZhysfBqlZw3EZ78VJ73FGBBWQKCe64dvI6ix3l1K
 JgGGUgG6imEm.e_FrMXt_pgNWO5TfluXUzrrZ_flaHbTZBUM.dDcQj94_XzdtiUD7kc0fR.koLc8
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 21 Nov 2022 04:24:32 +0000
Received: by hermes--production-ne1-6bcfb7fb87-2hzbf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f2efe04f4aa2c047135eaa1a2c6e7c26;
          Mon, 21 Nov 2022 04:24:27 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
From: Mark Millard 
In-Reply-To: 
Date: Sun, 20 Nov 2022 20:24:15 -0800
Cc: Ronald Klop ,
 freebsd-current 
Content-Transfer-Encoding: quoted-printable
Message-Id: <320C43A9-74FF-4848-9035-98BA1B71C44E@yahoo.com>
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com>
 
 
 
 
 
 
 
 
 <1722758786.127406.1667909706281@localhost>
 <1E33E6A3-ABB8-4804-B2A2-0E95E853C860@yahoo.com>
 
 
To: Archimedes Gaviola 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Spamd-Result: default: False [-3.48 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	NEURAL_HAM_MEDIUM(-0.98)[-0.985];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TAGGED_RCPT(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4NFvRk5m0lz4Cgj
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Nov 20, 2022, at 19:48, Archimedes Gaviola =
 wrote:

> On Wed, Nov 9, 2022 at 10:15 AM Archimedes Gaviola =
 wrote:
> On Wed, Nov 9, 2022 at 1:37 AM Mark Millard  wrote:
> On Nov 8, 2022, at 04:15, Ronald Klop  wrote:
>=20
> > Van: Warner Losh 
> > Datum: dinsdag, 8 november 2022 04:28
> > Aan: Archimedes Gaviola  > . . .
> > ...
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size: =
4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: =
4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size: =
40960
> > pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long =
to allocate a page
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size: =
28672
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: =
8192
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size: =
4096
> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size: =
8192
> >   This means that paging to the swap partition and/or swap file took =
too long (> 30 seconds... that's all that indefinite means). It also =
means that it can't write to backing store dirty pages to give to =
another process...
> >   Typical reason is that the disk / flash is not responsive to =
writes for some reason. You'll need to find why... I'd look at trims.
> >   Or.... if you can't change the disk... you need to put less memory =
pressure on it..
> >   Warner
> >  =20
> . . .
>=20
> Hi Mark,
>=20
> As a recap on the kernel tunables, the changes are the following,
>=20
> root@generic:~ # sysctl -a | grep oom
> vm.pageout_oom_seq: 120
> vm.pfault_oom_wait: 10

FYI . . .

As long as:

vm.pfault_oom_attempts =3D=3D -1=20

vm.pfault_oom_wait is ignored. It also likely does
nothing for:

vm.pfault_oom_attempts =3D=3D 0

vm.pfault_oom_wait gets involved for:

0 < vm.pfault_oom_attempts .

> vm.pfault_oom_attempts: -1
>=20
> With -j1 and -j2 options, both were able to complete the kernel and =
buildworld compilation in 103 and 84 hours respectively. Though I still =
could see messages on "swap_pager: indefinite wait buffer: bufobj" but =
definitely it's ignorable as it survived the compilation process. With =
the -j3 option, it failed along the course of compilation, it =
encountered the previous error on "failed to reclaim memory" but this =
time this error is not that relevant as -j1 and -j2 already works. =
Preferably with -j2 as the appropriate choice for my RPi 3B build setup.

Glad you got it working in your context.

Thanks for the report. My media does not lead to the
conditions and, so, does not lead to learning the
behavior when "swap_pager: indefinite wait buffer:
bufobj" is significantly involved (for the time scale
of waits that you got into).

The implication of the result is that you would
need a larger vm.pageout_oom_seq value in order
for -j3 to finish normally. Based on my media,
I've never had to use larger values, but, I knew
it was a technical possibility to need such. I do
not know how to pre-calculate what value would
work.

(I'm not suggesting any more -j3 experiments.)

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


From nobody Mon Nov 21 09:29:25 2022
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 4NG2Dr3rnZz4hTnT
	for ; Mon, 21 Nov 2022 09:30:36 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NG2Dr1tTyz3kPd
	for ; Mon, 21 Nov 2022 09:30:36 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-yb1-xb2d.google.com with SMTP id f201so12878386yba.12
        for ; Mon, 21 Nov 2022 01:30:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=1Gie+xm1gIfpJZyDDwaucUkjBIkVZ37EZ6sCvP+t//A=;
        b=N8mnVKHmlOZvhPXJpehuveLBjB4cXd4nMTneLsIcQeL08EJuNEgI4gjFbRUbv9maDl
         l9n4tuDHb1USCLq2c/FtADTJgsa6OIPs6p/2LdrB5xM+gKlc3+IYbbzOgHLS7nKNz3pg
         8X8wyl7VwheHRzChZQz1sKXLa11GZtCbCH5Q+bbhlVncRR2mYoLAOhI06+YF6lZIul3q
         7VnuEnLitsRUr1SA1uAjFPAUk5J+lnv5j+dU48kTtg/4oYLYXbdnu7v9R8tvKoWdo2Wa
         /Nk+V261T7BEOM0KtHCmTnxUeAPfC6Tm2DAdck33gnXG3EB07A4T+hFcZUqhNc082U3M
         fT2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=1Gie+xm1gIfpJZyDDwaucUkjBIkVZ37EZ6sCvP+t//A=;
        b=FabHrININc5clzFn6Cp5xqdHNNzmtHBFEIYNFGJWOnoD4wqHO3lZBqtygTTtYTcz2A
         B1Sy1R3hVNqodAJ2q3YS9D7aMFyuvQiojwK+OdJKIJEF1zxRvBxAc4/TfojOXWJdeGdu
         U4vQbcoNMuv2s1jlJp5oCibX6UMULpzWH8DNTS2WvsyVurDIJulZgBkGAUkdKvTd7c+J
         LsgRcIkwJDp68kbpnKRGYz5lqJDoDL6nm52/L8iWZlZcIWKbEtRiV/vvPp9/iat7TM+z
         rJYmCakElA60swn88SIaM9lIg7YwDdrDkrm9SZ6k76VB1sJFY/ETQgdGb96UcmsT2Tyd
         vY6A==
X-Gm-Message-State: ANoB5pkiHd/MSaKDKEx3w1aCuxBaBnhvbl7SVULw/ILuagG7oC4FD7ks
	DObizdTKHqaD6LIU9XITcmvgGMivGvq6vI2/qKY=
X-Google-Smtp-Source: AA0mqf6bEX2ZkEl3o8oQDzqb6BoO7lr7hwaSo1koVSfvAWr9UAbF/VGc/LMeocok8j8DWdzRhwLymdGHiordgZukD3Q=
X-Received: by 2002:a25:cfcb:0:b0:6e6:d92d:e1 with SMTP id f194-20020a25cfcb000000b006e6d92d00e1mr15759153ybg.308.1669023035429;
 Mon, 21 Nov 2022 01:30:35 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com>
 <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> 
  
 
  
 
 
 <1722758786.127406.1667909706281@localhost> <1E33E6A3-ABB8-4804-B2A2-0E95E853C860@yahoo.com>
 
  <320C43A9-74FF-4848-9035-98BA1B71C44E@yahoo.com>
In-Reply-To: <320C43A9-74FF-4848-9035-98BA1B71C44E@yahoo.com>
From: Archimedes Gaviola 
Date: Mon, 21 Nov 2022 17:29:25 +0800
Message-ID: 
Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build
To: Mark Millard 
Cc: Ronald Klop , freebsd-current 
Content-Type: multipart/alternative; boundary="00000000000026194e05edf7b5f2"
X-Rspamd-Queue-Id: 4NG2Dr1tTyz3kPd
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	TAGGED_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--00000000000026194e05edf7b5f2
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 21, 2022 at 12:24 PM Mark Millard  wrote:

> On Nov 20, 2022, at 19:48, Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
>
> > On Wed, Nov 9, 2022 at 10:15 AM Archimedes Gaviola <
> archimedes.gaviola@gmail.com> wrote:
> > On Wed, Nov 9, 2022 at 1:37 AM Mark Millard  wrote:
> > On Nov 8, 2022, at 04:15, Ronald Klop  wrote:
> >
> > > Van: Warner Losh 
> > > Datum: dinsdag, 8 november 2022 04:28
> > > Aan: Archimedes Gaviola  > > . . .
> > > ...
> > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, size:
> 4096
> > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size: 4096
> > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, size:
> 40960
> > > pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too long to
> allocate a page
> > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, size:
> 28672
> > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size: 8192
> > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, size:
> 4096
> > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, size:
> 8192
> > >   This means that paging to the swap partition and/or swap file took
> too long (> 30 seconds... that's all that indefinite means). It also means
> that it can't write to backing store dirty pages to give to another
> process...
> > >   Typical reason is that the disk / flash is not responsive to writes
> for some reason. You'll need to find why... I'd look at trims.
> > >   Or.... if you can't change the disk... you need to put less memory
> pressure on it..
> > >   Warner
> > >
> > . . .
> >
> > Hi Mark,
> >
> > As a recap on the kernel tunables, the changes are the following,
> >
> > root@generic:~ # sysctl -a | grep oom
> > vm.pageout_oom_seq: 120
> > vm.pfault_oom_wait: 10
>

Hi,


>
> FYI . . .
>
> As long as:
>
> vm.pfault_oom_attempts == -1
>
> vm.pfault_oom_wait is ignored. It also likely does
> nothing for:
>
> vm.pfault_oom_attempts == 0
>
> vm.pfault_oom_wait gets involved for:
>
> 0 < vm.pfault_oom_attempts .
>

Okay, noted on this.


>
> > vm.pfault_oom_attempts: -1
> >
> > With -j1 and -j2 options, both were able to complete the kernel and
> buildworld compilation in 103 and 84 hours respectively. Though I still
> could see messages on "swap_pager: indefinite wait buffer: bufobj" but
> definitely it's ignorable as it survived the compilation process. With the
> -j3 option, it failed along the course of compilation, it encountered the
> previous error on "failed to reclaim memory" but this time this error is
> not that relevant as -j1 and -j2 already works. Preferably with -j2 as the
> appropriate choice for my RPi 3B build setup.
>
> Glad you got it working in your context.
>
> Thanks for the report.


I too am glad about the outcome of the testing. In the context of -j1 and
-j2 build options, the oom kernel tunable settings were very effective.
Thanks a lot for your help!


> My media does not lead to the
> conditions and, so, does not lead to learning the
> behavior when "swap_pager: indefinite wait buffer:
> bufobj" is significantly involved (for the time scale
> of waits that you got into).
>

Ah okay, as you are using a more powerful media so there's no manifestation
of such messages. Nice and good to know.


>
> The implication of the result is that you would
> need a larger vm.pageout_oom_seq value in order
> for -j3 to finish normally.


Oh I see I will take note of this one. Thanks for the further hint! I can
explore this soon.


> Based on my media,
> I've never had to use larger values, but, I knew
> it was a technical possibility to need such. I do
> not know how to pre-calculate what value would
> work.
>
> (I'm not suggesting any more -j3 experiments.)
>

It's alright, if I have spare time I will explore the -j3 settings further.
For now -j2 is sufficient.

To Warner and Ronald, thanks as well to your inputs!

Best regards,
Archimedes


>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>

--00000000000026194e05edf7b5f2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Nov 21, 2022 at 12:24 PM Mark=
 Millard <marklmi=
@yahoo.com> wrote:
On Nov 20, 2022, at 19:48, Archimedes Gaviola <archimedes.gaviola@gmai=
l.com> wrote:



> On Wed, Nov 9, 2022 at 10:15 AM Archimedes Gaviola <archimedes.gaviola@gmail=
.com> wrote:

> On Wed, Nov 9, 2022 at 1:37 AM Mark Millard <marklmi@yahoo.com> wrote:

> On Nov 8, 2022, at 04:15, Ronald Klop <ronald-lists@klop.ws> wrote:

> 

> > Van: Warner Losh <imp@bsdimp.com>

> > Datum: dinsdag, 8 november 2022 04:28

> > Aan: Archimedes Gaviola <archimedes.gaviola@gmail.com

> > . . .

> > ...

> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256929, siz=
e: 4096

> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3628, size:=
 4096

> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255839, siz=
e: 40960

> > pid 46153 (c++), jid 0, uid 0, was killed: a thread waited too lo=
ng to allocate a page

> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255857, siz=
e: 28672

> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 3634, size:=
 8192

> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 256037, siz=
e: 4096

> > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 255320, siz=
e: 8192

> >=C2=A0 =C2=A0This means that paging to the swap partition and/or s=
wap file took too long (> 30 seconds... that's all that indefinite m=
eans). It also means that it can't write to backing store dirty pages t=
o give to another process...

> >=C2=A0 =C2=A0Typical reason is that the disk / flash is not respon=
sive to writes for some reason. You'll need to find why... I'd look=
 at trims.

> >=C2=A0 =C2=A0Or.... if you can't change the disk... you need t=
o put less memory pressure on it..

> >=C2=A0 =C2=A0Warner

> >=C2=A0 =C2=A0

> . . .

> 

> Hi Mark,

> 

> As a recap on the kernel tunables, the changes are the following,

> 

> root@generic:~ # sysctl -a | grep oom

> vm.pageout_oom_seq: 120

> vm.pfault_oom_wait: 10

Hi,
=C2=A0



FYI . . .



As long as:



vm.pfault_oom_attempts =3D=3D -1 



vm.pfault_oom_wait is ignored. It also likely does

nothing for:



vm.pfault_oom_attempts =3D=3D 0



vm.pfault_oom_wait gets involved for:



0 < vm.pfault_oom_attempts .

Okay, n=
oted on this.
=C2=A0



> vm.pfault_oom_attempts: -1

> 

> With -j1 and -j2 options, both were able to complete the kernel and bu=
ildworld compilation in 103 and 84 hours respectively. Though I still could=
 see messages on "swap_pager: indefinite wait buffer: bufobj" but=
 definitely it's ignorable as it survived the compilation process. With=
 the -j3 option, it failed along the course of compilation, it encountered =
the previous error on "failed to reclaim memory" but this time th=
is error is not that relevant as -j1 and -j2 already works. Preferably with=
 -j2 as the appropriate choice for my RPi 3B build setup.



Glad you got it working in your context.



Thanks for the report. 

I too am glad about=
 the outcome of the testing. In the context of -j1 and -j2 build options, t=
he oom kernel tunable settings were very effective. Thanks a lot for your h=
elp!
=C2=A0
My media does not lead to the

conditions and, so, does not lead to learning the

behavior when "swap_pager: indefinite wait buffer:

bufobj" is significantly involved (for the time scale

of waits that you got into).

Ah okay, a=
s you are using a more powerful media so there's no manifestation of su=
ch messages. Nice and good to know.
=C2=A0



The implication of the result is that you would

need a larger vm.pageout_oom_seq value in order

for -j3 to finish normally.

Oh I see I will=
 take note of this one. Thanks for the further hint! I can explore this soo=
n.
=C2=A0 
Based on my media,

I've never had to use larger values, but, I knew

it was a technical possibility to need such. I do

not know how to pre-calculate what value would

work.



(I'm not suggesting any more -j3 experiments.)
It's alright, if I have spare time I will explore the -j3 s=
ettings further. For now -j2 is sufficient.

To=
 Warner and Ronald, thanks as well to your inputs!

Best regards,
Archimedes
=C2=A0



=3D=3D=3D

Mark Millard

marklmi at yahoo.com






--00000000000026194e05edf7b5f2--

From nobody Mon Nov 21 19:12:44 2022
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 4NGH8c5XHXz4hHRN
	for ; Mon, 21 Nov 2022 19:12:48 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGH8b6rGQz3nxd
	for ; Mon, 21 Nov 2022 19:12:47 +0000 (UTC)
	(envelope-from markjdb@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=TaWzJR94;
	spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::830 as permitted sender) smtp.mailfrom=markjdb@gmail.com;
	dmarc=none
Received: by mail-qt1-x830.google.com with SMTP id s4so7900373qtx.6
        for ; Mon, 21 Nov 2022 11:12:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        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=nxoFJ9uRaKzis8Ou/6d1kE9Qn6NH9avcqtnses/4M8M=;
        b=TaWzJR94CgNXv5j4rSP1Nb02oRUW2sTUXeOtt8yKnvZv675ZT84yM9X9rOrhBDHNKr
         ByRsIbATp6+RaRK1+qSi56oliSXaGhhBxiL1PWrR01Yn79d4ZuFpqb5XGH4J0ejd+z56
         mAnAs3+QQUPMx81UmRN5WJBctlhvrSAxXaM+9dsfnxaQnpP8e6CZxSeoUIwBnwD0Cmx4
         JKo796OH0d0s4PU9WI8sPcKW/NxvvhF96n2rUJmI69Gd/dSzDT+VCYIYDdSRWbJmmWI6
         Hb8O2/Sp4vOTdDxngj2ZAEwvDCte1GRgThd4kfPVq2t8bofXw69bdKYz6A5Jaq2ePd8z
         AUmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        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=nxoFJ9uRaKzis8Ou/6d1kE9Qn6NH9avcqtnses/4M8M=;
        b=3EGK0fQioJ6NsZ/cZuMKIXEauYIl9rfLe1BD6ELtcu1/4Aj9/3I3bE6NWf57ELtQM9
         aJnIJsvLSTK3uJQ7Z2ZpEBsqPoxJ8RuQpthgdG5ccKvoV884GvgN6RaRfRXZtwC7mjMB
         XXW9iQzq6cNDfA4rExsdmDaf15aZuXHmT41CsjMiVeHeseHiU7nBSzs+VJdbiWr5+rlA
         tcytJhOUYaUPjpenJAyf1ykRz0Z1jKwn1Y+0hulr9eU4tmrUDqpO+9JBreZITnu6dyqw
         kngBVSCg3EioJDEAqinfiyLkm/8fT9+flLhxfBpc9IgQvYt3L6Eoe3rw52FsB7fzP6GD
         XoJA==
X-Gm-Message-State: ANoB5pmMXbHhShGSnj7R0ynSeS4l6DiY78rKccgPr9To4rzNeng9vfVf
	NNHl7JPG2RNZpMbUBTjy05GyGRiipbI=
X-Google-Smtp-Source: AA0mqf5ZVV+LGYO2qdUYNLSuArMY6zO4G+F0IB7wdL6tLqy2UHAGETUSjGu/GpsupoLoWB8EiyHxmw==
X-Received: by 2002:ac8:6a1a:0:b0:35c:f2e5:a673 with SMTP id t26-20020ac86a1a000000b0035cf2e5a673mr19092904qtr.232.1669057966891;
        Mon, 21 Nov 2022 11:12:46 -0800 (PST)
Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237])
        by smtp.gmail.com with ESMTPSA id g24-20020ac87758000000b003a611cb2a95sm7091734qtu.9.2022.11.21.11.12.45
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 21 Nov 2022 11:12:46 -0800 (PST)
Date: Mon, 21 Nov 2022 14:12:44 -0500
From: Mark Johnston 
To: Hans Petter Selasky 
Cc: FreeBSD Current 
Subject: Re: ULE realtime scheduler advice needed
Message-ID: 
References: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.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: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
X-Spamd-Result: default: False [-2.70 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	MID_RHS_NOT_FQDN(0.50)[];
	FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-Rspamd-Queue-Id: 4NGH8b6rGQz3nxd
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Nov 18, 2022 at 05:47:58AM +0100, Hans Petter Selasky wrote:
> Hi,
> 
> I'm doing some work with audio and have noticed some problems with the 
> ULE scheduler. I have a program that generate audio based on 
> key-presses. When no keys are pressed, the load is near 0%, but as soon 
> as you start pressing keys, the load goes maybe to 80% of a CPU core. 
> This program I run with rtprio 8 xxx. The issue I observe or hear 
> actually, is that it takes too long until the scheduler grasps that this 
> program needs it's own CPU core and stops time-sharing the program. When 
> I however use cpuset -l xxx rtprio 8 yyy everything is good, and the 
> program outputs realtime audio in-time.
> 
> Or is this perhaps a CPU frequency stepping issue?
> 
> Any advice on where to look?

There were some bug fixes earlier this year to address problems where
high-priority threads were not getting scheduled quickly enough.  If
you're using an old kernel, they might improve things:

https://cgit.freebsd.org/src/commit/?id=0927ff78147b4d00a75054bbad299946208e1e91
https://cgit.freebsd.org/src/commit/?id=6d3f74a14a83b867c273c6be2599da182a9b9ec7
https://cgit.freebsd.org/src/commit/?id=03f868b163ad46d6f7cb03dc46fb83ca01fb8f69
https://cgit.freebsd.org/src/commit/?id=a889a65ba36985dfb31111ac1607be35ca2b2c8c

Otherwise, you might try using tools/sched/schedgraph.d and
schedgraph.py to visualize what's going on.  schedgraph.d logs all
scheduler events of interest and schedgraph.py presents a row for each
CPU and thread in the system, making it easier to see why threads are
waiting on runqueues.

From nobody Mon Nov 21 20:24:37 2022
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 4NGJlh6QhZz4hRmp
	for ; Mon, 21 Nov 2022 20:24:48 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [88.99.82.50])
	(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 4NGJlh3rwHz3w16;
	Mon, 21 Nov 2022 20:24:48 +0000 (UTC)
	(envelope-from hps@selasky.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: from [10.36.2.69] (unknown [84.210.222.10])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 5537A260252;
	Mon, 21 Nov 2022 21:24:40 +0100 (CET)
Message-ID: <2863b1e9-f18f-11c7-6f0d-364030103806@selasky.org>
Date: Mon, 21 Nov 2022 21:24:37 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: ULE realtime scheduler advice needed
To: Mark Johnston 
Cc: FreeBSD Current 
References: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
 
Content-Language: en-US
From: Hans Petter Selasky 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4NGJlh3rwHz3w16
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On 11/21/22 20:12, Mark Johnston wrote:
> There were some bug fixes earlier this year to address problems where
> high-priority threads were not getting scheduled quickly enough.  If
> you're using an old kernel, they might improve things:

Are any of these fixes merged to stable/13 ?

--HPS

From nobody Tue Nov 22 12:15:33 2022
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 4NGjrp180bz4hVXS
	for ; Tue, 22 Nov 2022 12:15:38 +0000 (UTC)
	(envelope-from joh.hendriks@gmail.com)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGjrm74rNz42ZV
	for ; Tue, 22 Nov 2022 12:15:36 +0000 (UTC)
	(envelope-from joh.hendriks@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=DLQsChJI;
	spf=pass (mx1.freebsd.org: domain of joh.hendriks@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=joh.hendriks@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-ej1-x632.google.com with SMTP id vv4so26055140ejc.2
        for ; Tue, 22 Nov 2022 04:15:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id:from
         :to:cc:subject:date:message-id:reply-to;
        bh=LzWefzOTa6nbij111qyV9vRv+Os8XftwCT4rnnqTdu0=;
        b=DLQsChJI7nLjLapoyuGHepUqr7+NYGdxTfHeC1VWN98ZjbXPd5vM9lWseRMlAxDM5Y
         G2mBdwDFXHkzuoMQmoihHK+S3xHxa56L13mD4CHEh57GAqYO8nbtx+FgVs4QMrlHIhCk
         yrIFVc0wMk6knC7EuA6XP4drFokHEMHzvyOAy8D/96/Q3gmROLTY4j5cdWU176Ub0D3K
         9Ad/N8bDPQCKg4STzLMNXVKkeftLdM6o5mwmN3m/5Nne2cS3KtQTb3xc2nB9tSOF0Fbc
         wbkUvGZ+MnuLgrTsK4WBwLyydzFWdOTwXLdggjbeCZoKsPqJdPFIy6IEiTXTR0FQd5z7
         YWog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=LzWefzOTa6nbij111qyV9vRv+Os8XftwCT4rnnqTdu0=;
        b=js691udwJsT95Qk5JLjTp6qLnvqK788BZappxZvR0wnKVSa3YMrbkkuuzLlXROJeEh
         gqYIpXvcnkBb2HwPmpU8RLQRI99xc4UyDYMvPXF90wqSu51+FNLeyfjCOnI4gvsSgux3
         AObsnqQt0SOUWh7mc8yqucBMS+CPXs2lAqOzVvoCh9DYJ9LlHdVCvw+cAzUzbn4UcNAt
         UnWlNkM/GPxY1FweFiTIHrtEum/Xr4rEdGVxPP8DMJdi12Qv1S4lyvaF3RuTL2LuKIXI
         +73sW46wK9r0EWnE4oLDwPo0lkeLsUTfbppUukLD0ehuJRAyc7xYWI2eudXX9zWViluL
         sONw==
X-Gm-Message-State: ANoB5pnE0JAK8QVJFUkCXG/rmDXPJlI5c8iDGPin9FJdwgYT79PPeXGo
	8iwG23tjM8FFff2x/BvaSa3HNaHEzeg=
X-Google-Smtp-Source: AA0mqf5s44E+CypJUfc7fAZJpA0KyGECYD9ek7V+MUOV+kq0Jdj1ZHZJFDNsjSMLQKZXFiasVb4zfQ==
X-Received: by 2002:a17:906:4a8a:b0:7ad:bc84:2f23 with SMTP id x10-20020a1709064a8a00b007adbc842f23mr20325327eju.262.1669119335358;
        Tue, 22 Nov 2022 04:15:35 -0800 (PST)
Received: from ?IPV6:2001:990:1:1378:a514:490c:f75d:b29f? ([2001:990:1:1378:a514:490c:f75d:b29f])
        by smtp.gmail.com with ESMTPSA id lc14-20020a170906dfee00b007ae07e63a85sm6100253ejc.211.2022.11.22.04.15.34
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 22 Nov 2022 04:15:34 -0800 (PST)
Message-ID: <600fd39e-d22c-4626-fa88-9af6aea7e432@gmail.com>
Date: Tue, 22 Nov 2022 13:15:33 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.5.0
Subject: Re: ULE realtime scheduler advice needed
To: freebsd-current@freebsd.org
References: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
  <2863b1e9-f18f-11c7-6f0d-364030103806@selasky.org>
Content-Language: en-US
From: Johan Hendriks 
In-Reply-To: <2863b1e9-f18f-11c7-6f0d-364030103806@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-3.93 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.93)[-0.928];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TAGGED_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::632:from];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4NGjrm74rNz42ZV
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N


On 21/11/2022 21:24, Hans Petter Selasky wrote:
> On 11/21/22 20:12, Mark Johnston wrote:
>> There were some bug fixes earlier this year to address problems where
>> high-priority threads were not getting scheduled quickly enough.  If
>> you're using an old kernel, they might improve things:
>
> Are any of these fixes merged to stable/13 ?
>
> --HPS
>
It looks like it.
https://freshbsd.org/freebsd/src?q=sched_ule.c




From nobody Tue Nov 22 15:12:28 2022
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 4NGnnS219cz4hrg2
	for ; Tue, 22 Nov 2022 15:13:00 +0000 (UTC)
	(envelope-from mack@macktronics.com)
Received: from mail.macktronics.com (coco.macktronics.com [209.181.253.65])
	(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 4NGnnR03VKz4JKQ
	for ; Tue, 22 Nov 2022 15:12:59 +0000 (UTC)
	(envelope-from mack@macktronics.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of mack@macktronics.com designates 209.181.253.65 as permitted sender) smtp.mailfrom=mack@macktronics.com;
	dmarc=pass (policy=none) header.from=macktronics.com
Received: from olive.macktronics.com (unknown [209.181.253.67])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.macktronics.com (Postfix) with ESMTPS id 58A711C0
	for ; Tue, 22 Nov 2022 09:12:29 -0600 (CST)
Date: Tue, 22 Nov 2022 09:12:28 -0600 (CST)
From: Dan Mack 
To: freebsd-current@freebsd.org
Subject: dmesg content lifetime
Message-ID: <9d519f-ce87-72d-dc6-789817468974@macktronics.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; format=flowed; charset=US-ASCII
X-Spamd-Result: default: False [-3.77 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.973];
	DMARC_POLICY_ALLOW(-0.50)[macktronics.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:209.181.253.64/29];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:209, ipnet:209.181.252.0/23, country:US];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NGnnR03VKz4JKQ
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

It seems like dmesg content ages out over time.   Is there a way to leave 
the contents based on a fixed memory size instead?

Dan


From nobody Tue Nov 22 15:18:12 2022
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 4NGnvj4t4wz4hscY
	for ; Tue, 22 Nov 2022 15:18:25 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450: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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGnvj2v6Lz4KR4
	for ; Tue, 22 Nov 2022 15:18:25 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ed1-x52b.google.com with SMTP id l24so8505816edj.8
        for ; Tue, 22 Nov 2022 07:18:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=pp9zl30T0zltio+5vTNKmRfWtgSu8yZC3AI7dX08ViU=;
        b=Px/0PQYZk/RKdrcUPQ+99KUnzcBL4PExF1e5gF+vK258hD2bX5ANwf9MZLztw+m7pA
         uG7gfupA3VGA4UVh/ijAADTnUOXSfo15zh4JH2WyiTxRR6vyAMAdL/DLEyT//x0irmtz
         kPfSulJgQ8BZi/LHFIVBVCaOng/MHEqotko/rCFG4SNBXY8mFO1RIGc9NjAvGPqA2Nt0
         SOmJaH9CG/FmVsQDRe6AdKR5dYQb8YO7oQrLqTcL3anv4SIgb0eR/VbiPOQ3hDq2sFE4
         Jz+T29WaY52F2kZX+NdusoVb1lP7Hqvn5AfSZXEokuBDM/ZA7HnQpZGiIIV1ZhzzXSiP
         Cb2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=pp9zl30T0zltio+5vTNKmRfWtgSu8yZC3AI7dX08ViU=;
        b=UbpyEDqLoA/Z16FTofLKBpYB+sGuzQMEFfwbRL6VL4EGq9Wje8heUsouC7PEog7+Zh
         MV1RbA2uJ3htSVUSUkVg6ANL93k/lxBB+D27nOQR1OosnIXLHTov9crTV3JAqYZABNTr
         UBrhAtnD8OsSa5P6f4zAZT4bYrAAeWI0d2UqnzVzOQFzBj3tsB1dATH/4cD4YN9xLtLs
         TmeE+EdknxRwYEdeajm2VQtPDmaA4nF2OQwWmVpkl5k7Fl71NFGdRyArfTkyoY3b2fAr
         kl6TALZj0uzg6zTsPCyGL/9qHSRebehKALwP1KYNstwDzQk9aVYcoRqhuzvIwtySGR4p
         +U7g==
X-Gm-Message-State: ANoB5pnV1ClssHQKCmhETvRvIdwOuZGRGInBOez5GySL5z8zqfqiAZ9y
	w3zwQ5mtpPbw4MwJ+oJc/5NZSyJu0oQ79vYM1B++deRYacM=
X-Google-Smtp-Source: AA0mqf7wugLK+TfSd9UIHolAKXOEuPP8ujtsM1N5BaH8ZSgyxyOCNNLoh2U92XdveWK4V+o8tTMNHhhiuXNWdkFqkeQ=
X-Received: by 2002:a05:6402:48d:b0:461:c3d9:c6a3 with SMTP id
 k13-20020a056402048d00b00461c3d9c6a3mr4209058edv.154.1669130303542; Tue, 22
 Nov 2022 07:18:23 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <9d519f-ce87-72d-dc6-789817468974@macktronics.com>
In-Reply-To: <9d519f-ce87-72d-dc6-789817468974@macktronics.com>
From: Warner Losh 
Date: Tue, 22 Nov 2022 08:18:12 -0700
Message-ID: 
Subject: Re: dmesg content lifetime
To: Dan Mack 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000d3ad4d05ee10ae90"
X-Rspamd-Queue-Id: 4NGnvj2v6Lz4KR4
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000d3ad4d05ee10ae90
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 22, 2022 at 8:13 AM Dan Mack  wrote:

> It seems like dmesg content ages out over time.   Is there a way to leave
> the contents based on a fixed memory size instead?
>

It already is a fixed memory size. Do you see it all disappear at once, or
over time?

Warner

--000000000000d3ad4d05ee10ae90
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Nov 22, 2022 at 8:13 AM Dan M=
ack <mack@macktronics.com>=
; wrote:
It seem=
s like dmesg content ages out over time.=C2=A0 =C2=A0Is there a way to leav=
e 

the contents based on a fixed memory size instead?
It already is a fixed memory size. Do you see it all disappear =
at once, or over time?

Warner=C2=A0


--000000000000d3ad4d05ee10ae90--

From nobody Tue Nov 22 15:34:50 2022
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 4NGpH60WXmz4hv6l
	for ; Tue, 22 Nov 2022 15:35:14 +0000 (UTC)
	(envelope-from mack@macktronics.com)
Received: from mail.macktronics.com (coco.macktronics.com [209.181.253.65])
	(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 4NGpH603Djz4N2L
	for ; Tue, 22 Nov 2022 15:35:14 +0000 (UTC)
	(envelope-from mack@macktronics.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from olive.macktronics.com (unknown [209.181.253.67])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.macktronics.com (Postfix) with ESMTPS id 460B61CA;
	Tue, 22 Nov 2022 09:34:50 -0600 (CST)
Date: Tue, 22 Nov 2022 09:34:50 -0600 (CST)
From: Dan Mack 
To: Warner Losh 
cc: freebsd-current@freebsd.org
Subject: Re: dmesg content lifetime
In-Reply-To: 
Message-ID: <6146841c-baef-134-dcd9-30db2d92732@macktronics.com>
References: <9d519f-ce87-72d-dc6-789817468974@macktronics.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; format=flowed
X-Rspamd-Queue-Id: 4NGpH603Djz4N2L
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:209, ipnet:209.181.252.0/23, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


It disappears a piece at a time - the oldest entries disappear first. 
However, it vanishes even when there are only 2-3 lines in it so I didn't 
think capacity was in play as I expected.

So for example I might see a rate-limit entry from someone spamming the 
system and then it will usually be gone in a couple days and the buffer is 
completely empty.   Similarly if I do something like ifconfig em0 down; 
ifconfig em0 up ; it's logged but disappears after a day or so.

I'm looking to see if this is just a cron job or something clearing it as 
it might be user-error on my part.   Also this is an older system so I'll 
probably look at it again after I update.

Thank you,

Dan


On Tue, 22 Nov 2022, Warner Losh wrote:

> On Tue, Nov 22, 2022 at 8:13 AM Dan Mack  wrote:
>
>> It seems like dmesg content ages out over time.   Is there a way to leave
>> the contents based on a fixed memory size instead?
>>
>
> It already is a fixed memory size. Do you see it all disappear at once, or
> over time?
>
> Warner
>

From nobody Tue Nov 22 15:44:45 2022
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 UTF8SMTP id 4NGpVQ49kgz4hwKg
	for ; Tue, 22 Nov 2022 15:45:02 +0000 (UTC)
	(envelope-from kabaev@gmail.com)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with UTF8SMTPS id 4NGpVQ1WRHz4PXW
	for ; Tue, 22 Nov 2022 15:45:02 +0000 (UTC)
	(envelope-from kabaev@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-qt1-x82f.google.com with SMTP id e15so9509900qts.1
        for ; Tue, 22 Nov 2022 07:45:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=mime-version:references:in-reply-to:message-id:subject:cc:to:from
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=P2IAOuXlPBZcumTrRySEhC3kjiOYeB0s4Rn6nHeF4F0=;
        b=mf2jpCNf7apsEyNPVXo3OVc63N8R5YTnrtWVzYcNJW8/WheWuVmY8qOA4pPuPd/2k3
         TAGyYLEaFCT9AmAjSoVo8fTPyUViaAG+PoOrJX2haszVLCWEc8nJgWwbMi12oeNBZhXu
         zVvVVT/jF7Su8X3DJ4n/zmihKs2kOopRGcHgweLkVoFpWh86ve1qN/aN9yunvggDlIve
         aTYeGfWg+hKgT9PURMsJLtOWWBzMUO80TvgzXLpDBEzjdvgHUu3UH3g+zaitvsNvqycC
         vFv0fCtG+RnNUAWGOf+6ASbzabmv0WtpQ+MZlfL2GGnC79vrSSJRxg7gjACMf/8R5vdd
         iVuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=mime-version:references:in-reply-to:message-id:subject:cc:to:from
         :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=P2IAOuXlPBZcumTrRySEhC3kjiOYeB0s4Rn6nHeF4F0=;
        b=1xML3i7xB9c41zeEyhi1Fzm4NWRSOPU1+1JrHKbgn9s5x15iiMG910aKSckDmfd9Vw
         +TqLux3vEjkngQeBh9HzGPn5fOBXIyHSdcWrG4IdnQBE4/wgITdfe9vYpmG/piwxVCEP
         zq3dkbwXHoNO0XwqdcYAEwuHuqcod8NWYiU/b4JOqcowcPaA9toibQyLnNVMcjJdiC3D
         2MZOFHu0EVVpAEy2/1KRdKyoFgd6tKk+9bjOjVruQbjJldMcxOkWw2/Rf1SHu/C/v9XE
         /mKAOBzZ1RuIcwAI4G+CVzyEGSW398TyXT+Lz+as4dsJQBScSToe1vHViU726t6QTB6f
         7J1w==
X-Gm-Message-State: ANoB5pkTOqqv+GY9Zjm9/txr7p7wKY67UuyoHSdeINUetN/UvvU/+zGn
	hncC08bxt+5qm+LOfeb+7kCNWGjHTkw=
X-Google-Smtp-Source: AA0mqf5zswxOCr5xXKUneCROKwau3y2kdYfwtAa9EXAyt++/+RGpuuaQby/sUs3S9bHoEkOILf1Lhg==
X-Received: by 2002:ac8:514b:0:b0:35d:5a2e:72f with SMTP id h11-20020ac8514b000000b0035d5a2e072fmr4355504qtn.324.1669131900844;
        Tue, 22 Nov 2022 07:45:00 -0800 (PST)
Received: from kan ([2601:18f:701:29c0:2e4d:54ff:fe51:fcf3])
        by smtp.gmail.com with ESMTPSA id j12-20020a05620a410c00b006eef13ef4c8sm10678559qko.94.2022.11.22.07.44.59
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 22 Nov 2022 07:44:59 -0800 (PST)
Date: Tue, 22 Nov 2022 10:44:45 -0500
From: Alexander Kabaev 
To: Dan Mack 
Cc: freebsd-current@freebsd.org
Subject: Re: dmesg content lifetime
Message-ID: <20221122104445.4ed88f6f@kan>
In-Reply-To: <9d519f-ce87-72d-dc6-789817468974@macktronics.com>
References: <9d519f-ce87-72d-dc6-789817468974@macktronics.com>
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/ImeeSaRkAnPSQSX=1cHYX=o";
 protocol="application/pgp-signature"; micalg=pgp-sha1
X-Rspamd-Queue-Id: 4NGpVQ1WRHz4PXW
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--Sig_/ImeeSaRkAnPSQSX=1cHYX=o
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Tue, 22 Nov 2022 09:12:28 -0600 (CST)
Dan Mack  wrote:

> It seems like dmesg content ages out over time.   Is there a way to
> leave the contents based on a fixed memory size instead?
>=20
> Dan
>=20
I think this is how it works: the kernel message bugger is of fixed
size and kernel and syslog sequences (dmesg -a) share it. The other
syslog users eventually puts enough content in there to displace all of
kernel messages. If the kernel stays quiet, 'dmesg' then returns
nothing, as by default it filters syslog entries that do not KERN
facility out, see sbin/dmesg/dmesg.c.

--=20
Alexander Kabaev

--Sig_/ImeeSaRkAnPSQSX=1cHYX=o
Content-Type: application/pgp-signature
Content-Description: Ð¦Ð¸Ñ„Ñ€Ð¾Ð²Ð°Ñ Ð¿Ð¾Ð´Ð¿Ð¸ÑÑŒ OpenPGP

-----BEGIN PGP SIGNATURE-----

iL0EARECAH0WIQR0dKhH2/VQpfw+8iNDrPWMyb5dlgUCY3zubl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0NzQ3
NEE4NDdEQkY1NTBBNUZDM0VGMjIzNDNBQ0Y1OENDOUJFNUQ5NgAKCRBDrPWMyb5d
lpWbAKDQjgJPdILO4zm/hhcHUxb+TH46VwCfTexeYDaj7/ire5gpCGz4LeTvKZc=
=6xPU
-----END PGP SIGNATURE-----

--Sig_/ImeeSaRkAnPSQSX=1cHYX=o--

From nobody Tue Nov 22 15:47:10 2022
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 4NGpYL57Zjz4hwPL
	for ; Tue, 22 Nov 2022 15:47:34 +0000 (UTC)
	(envelope-from mack@macktronics.com)
Received: from mail.macktronics.com (coco.macktronics.com [209.181.253.65])
	(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 4NGpYL4kH7z4Ql2
	for ; Tue, 22 Nov 2022 15:47:34 +0000 (UTC)
	(envelope-from mack@macktronics.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from olive.macktronics.com (unknown [209.181.253.67])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.macktronics.com (Postfix) with ESMTPS id E47021D0;
	Tue, 22 Nov 2022 09:47:10 -0600 (CST)
Date: Tue, 22 Nov 2022 09:47:10 -0600 (CST)
From: Dan Mack 
To: Alexander Kabaev 
cc: freebsd-current@freebsd.org
Subject: Re: dmesg content lifetime
In-Reply-To: <20221122104445.4ed88f6f@kan>
Message-ID: 
References: <9d519f-ce87-72d-dc6-789817468974@macktronics.com> <20221122104445.4ed88f6f@kan>
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
X-Rspamd-Queue-Id: 4NGpYL4kH7z4Ql2
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:209, ipnet:209.181.252.0/23, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 22 Nov 2022, Alexander Kabaev wrote:

> On Tue, 22 Nov 2022 09:12:28 -0600 (CST)
> Dan Mack  wrote:
>
>> It seems like dmesg content ages out over time.   Is there a way to
>> leave the contents based on a fixed memory size instead?
>>
>> Dan
>>
> I think this is how it works: the kernel message bugger is of fixed
> size and kernel and syslog sequences (dmesg -a) share it. The other
> syslog users eventually puts enough content in there to displace all of
> kernel messages. If the kernel stays quiet, 'dmesg' then returns
> nothing, as by default it filters syslog entries that do not KERN
> facility out, see sbin/dmesg/dmesg.c.
>
> -- 
> Alexander Kabaev
>

Thank you Alexander, I did not know this.  I'll USL (use-the-source-luke) 
:-)

Dan


From nobody Tue Nov 22 15:49:29 2022
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 4NGpbf05D4z4hwdw
	for ; Tue, 22 Nov 2022 15:49:34 +0000 (UTC)
	(envelope-from mike@karels.net)
Received: from mail.karels.net (mail.karels.net [216.160.39.52])
	by mx1.freebsd.org (Postfix) with ESMTP id 4NGpbd44Jcz3D6y
	for ; Tue, 22 Nov 2022 15:49:33 +0000 (UTC)
	(envelope-from mike@karels.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from mail.karels.net (localhost [127.0.0.1])
	by mail.karels.net (8.16.1/8.16.1) with ESMTP id 2AMFnTc6077416;
	Tue, 22 Nov 2022 09:49:29 -0600 (CST)
	(envelope-from mike@karels.net)
Received: from [10.0.2.130] ([10.0.1.1])
	by mail.karels.net with ESMTPSA
	id EN2XNYnvfGNmLgEA4+wvSQ
	(envelope-from ); Tue, 22 Nov 2022 09:49:29 -0600
From: Mike Karels 
To: Dan Mack 
Cc: Warner Losh , freebsd-current@freebsd.org
Subject: Re: dmesg content lifetime
Date: Tue, 22 Nov 2022 09:49:29 -0600
X-Mailer: MailMate (1.14r5921)
Message-ID: <21FB93B6-708F-4E69-B482-C7601C15394A@karels.net>
In-Reply-To: <6146841c-baef-134-dcd9-30db2d92732@macktronics.com>
References: <9d519f-ce87-72d-dc6-789817468974@macktronics.com>
 
 <6146841c-baef-134-dcd9-30db2d92732@macktronics.com>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Queue-Id: 4NGpbd44Jcz3D6y
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On 22 Nov 2022, at 9:34, Dan Mack wrote:

> It disappears a piece at a time - the oldest entries disappear first. H=
owever, it vanishes even when there are only 2-3 lines in it so I didn't =
think capacity was in play as I expected.
>
> So for example I might see a rate-limit entry from someone spamming the=
 system and then it will usually be gone in a couple days and the buffer =
is completely empty.   Similarly if I do something like ifconfig em0 down=
; ifconfig em0 up ; it's logged but disappears after a day or so.
>
> I'm looking to see if this is just a cron job or something clearing it =
as it might be user-error on my part.   Also this is an older system so I=
'll probably look at it again after I update.

I noticed this too, but discovered with =E2=80=9Cdmesg -a=E2=80=9D that t=
he buffer was full
of syslog messages, so dmesg without -a showed nothing.

It seems unfortunate that syslog messages logged in the message buffer, a=
t
least once syslogd is running.  Apparently this happens because they are
output to /dev/console.

		Mike

> Thank you,
>
> Dan
>
>
> On Tue, 22 Nov 2022, Warner Losh wrote:
>
>> On Tue, Nov 22, 2022 at 8:13 AM Dan Mack  wrote:=

>>
>>> It seems like dmesg content ages out over time.   Is there a way to l=
eave
>>> the contents based on a fixed memory size instead?
>>>
>>
>> It already is a fixed memory size. Do you see it all disappear at once=
, or
>> over time?
>>
>> Warner
>>

From nobody Tue Nov 22 16:03:39 2022
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 4NGpw65wL6z4hyFs
	for ; Tue, 22 Nov 2022 16:03:50 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGpw51NRKz3Fw1
	for ; Tue, 22 Nov 2022 16:03:48 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp;
	dmarc=none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2AMG3eSk065558;
	Wed, 23 Nov 2022 01:03:40 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Wed, 23 Nov 2022 01:03:39 +0900
From: Tomoaki AOKI 
To: Johan Hendriks 
Cc: freebsd-current@freebsd.org
Subject: Re: ULE realtime scheduler advice needed
Message-Id: <20221123010339.94a22d59cca8e225f0669aee@dec.sakura.ne.jp>
In-Reply-To: <600fd39e-d22c-4626-fa88-9af6aea7e432@gmail.com>
References: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
	
	<2863b1e9-f18f-11c7-6f0d-364030103806@selasky.org>
	<600fd39e-d22c-4626-fa88-9af6aea7e432@gmail.com>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-1.60 / 15.00];
	AUTH_NA(1.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	TO_DN_SOME(0.00)[];
	DMARC_NA(0.00)[sakura.ne.jp];
	TAGGED_RCPT(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NGpw51NRKz3Fw1
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 22 Nov 2022 13:15:33 +0100
Johan Hendriks  wrote:

> 
> On 21/11/2022 21:24, Hans Petter Selasky wrote:
> > On 11/21/22 20:12, Mark Johnston wrote:
> >> There were some bug fixes earlier this year to address problems where
> >> high-priority threads were not getting scheduled quickly enough.  If
> >> you're using an old kernel, they might improve things:
> >
> > Are any of these fixes merged to stable/13 ?
> >
> > --HPS
> >
> It looks like it.
> https://freshbsd.org/freebsd/src?q=sched_ule.c

Or track PR on Bugzilla via commit logs on main (pointed by markj@)
instead of Differential Revision on Phablicator.

Phab shouldn't know about branches other than main this case.
On Bugzilla, we can see each of them MFC'ed to stable/13 with second
commit-hook.


-- 
Tomoaki AOKI    

From nobody Tue Nov 22 16:16:55 2022
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 4NGqCG3Ybcz4j07X
	for ; Tue, 22 Nov 2022 16:16:58 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGqCG0cbwz3HVw
	for ; Tue, 22 Nov 2022 16:16:57 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2AMGGtfc069002;
	Wed, 23 Nov 2022 01:16:55 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Wed, 23 Nov 2022 01:16:55 +0900
From: Tomoaki AOKI 
To: Dan Mack 
Cc: Alexander Kabaev , freebsd-current@freebsd.org
Subject: Re: dmesg content lifetime
Message-Id: <20221123011655.c6a00ee21636e45e8b4f3a69@dec.sakura.ne.jp>
In-Reply-To: 
References: <9d519f-ce87-72d-dc6-789817468974@macktronics.com>
	<20221122104445.4ed88f6f@kan>
	
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4NGqCG0cbwz3HVw
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 22 Nov 2022 09:47:10 -0600 (CST)
Dan Mack  wrote:

> On Tue, 22 Nov 2022, Alexander Kabaev wrote:
> 
> > On Tue, 22 Nov 2022 09:12:28 -0600 (CST)
> > Dan Mack  wrote:
> >
> >> It seems like dmesg content ages out over time.   Is there a way to
> >> leave the contents based on a fixed memory size instead?
> >>
> >> Dan
> >>
> > I think this is how it works: the kernel message bugger is of fixed
> > size and kernel and syslog sequences (dmesg -a) share it. The other
> > syslog users eventually puts enough content in there to displace all of
> > kernel messages. If the kernel stays quiet, 'dmesg' then returns
> > nothing, as by default it filters syslog entries that do not KERN
> > facility out, see sbin/dmesg/dmesg.c.
> >
> > -- 
> > Alexander Kabaev
> >
> 
> Thank you Alexander, I did not know this.  I'll USL (use-the-source-luke) 
> :-)
> 
> Dan

Increase kern.msgbufsize tunable on /boot/loader.conf if you want dmesg
to live longer. For example, recommended value by iwlwifi team is
1146880. Much larger than default.

Note that this is actually a tunable and can be set only on boot time.


-- 
Tomoaki AOKI    

From nobody Tue Nov 22 17:37:14 2022
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 4NGs072hHdz4j8bN
	for ; Tue, 22 Nov 2022 17:37:27 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGs070jTDz3hHR
	for ; Tue, 22 Nov 2022 17:37:27 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x633.google.com with SMTP id ft34so37358909ejc.12
        for ; Tue, 22 Nov 2022 09:37:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=C9dE7tHKwWd+Q325ea3gyYmgSt9bZxfTUEi3V3Opfe0=;
        b=WLsR1jntFzxdaKXGHuCx1E/VBfqX43NUPKxehdfkFeo2kA2hlfB4n8KDKr3FltzFFJ
         Uq3aAgZczpDB7mIerLjBUPMr93dWPccWf6GBh8aA+vOHAwZ+f+IZy5cuZB6RwV3lxYcP
         KOxXaTGLx3iKZWXVvHspPzmttTtiqvSM2GNFebAv/eszFyP3ViORDSLlkJhmzN8veK3G
         iktdKlREPpGZ78XKxXS7LZerXZkkNuUISou/WjAz5WWecSBEviJu4sFbNg3cdtBv3uhS
         w/WiPwH2hogVbf/b6iDia1cyJRDpUori9ZMo7QG9ntltvjfJGy0dRm8QXmq9r4LJg6FV
         1UGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=C9dE7tHKwWd+Q325ea3gyYmgSt9bZxfTUEi3V3Opfe0=;
        b=A3/lSVn+XdovbcSW2s9DBKTEJswuLgQYu9VXO2VFZ33X620tO86twxg95SB6mJ2YKr
         tGNBHpAoe8v8locp9C+at65Y/OZHs/uwBuHbXs+keDFzZrETEKuOtnp1M7oSDjFyKl/i
         zW4b3aksHco+LlJ2wcCxibn+RSglot8/xlQIe/CGEDh3YUrNKQ6FcrhAtujPK+pla/W7
         G6Zaejs4aKueCe2Z4GWzeSGLKP5F8LI/Oy3DTuL3jgvUXAl7+hKSrqZaIeNpvABVzge5
         GEtKUeFlU9K4pIFDdfAA3DG6mL0HgLXL6+OEsDAWV+f8F1zhyiY0j8KlPIIhW7TxmxFw
         NHlQ==
X-Gm-Message-State: ANoB5pmlJTVW0J62YGuNWQbVOvu30GNVg3xad3WtYlCiLWPoLUGhVD6F
	Y//bnY0fKUAsBaCfHNgEVTv7Fb0OAamJ5ZmTnP+8uBSJS4k=
X-Google-Smtp-Source: AA0mqf51VCXY89vsifywsOgc9t7QCfg0z+6ign/ENaiIc7C1/7p6FIoeNXjYjvtmJUxB6QSaieGFPsfUyW0PvmLNwvk=
X-Received: by 2002:a17:906:114a:b0:790:b74b:abf2 with SMTP id
 i10-20020a170906114a00b00790b74babf2mr20451764eja.634.1669138645224; Tue, 22
 Nov 2022 09:37:25 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <9d519f-ce87-72d-dc6-789817468974@macktronics.com>
 
 <6146841c-baef-134-dcd9-30db2d92732@macktronics.com> <21FB93B6-708F-4E69-B482-C7601C15394A@karels.net>
In-Reply-To: <21FB93B6-708F-4E69-B482-C7601C15394A@karels.net>
From: Warner Losh 
Date: Tue, 22 Nov 2022 10:37:14 -0700
Message-ID: 
Subject: Re: dmesg content lifetime
To: Mike Karels 
Cc: Dan Mack , freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000007a5c705ee12a0d7"
X-Rspamd-Queue-Id: 4NGs070jTDz3hHR
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--00000000000007a5c705ee12a0d7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 22, 2022 at 8:49 AM Mike Karels  wrote:

> On 22 Nov 2022, at 9:34, Dan Mack wrote:
>
> > It disappears a piece at a time - the oldest entries disappear first.
> However, it vanishes even when there are only 2-3 lines in it so I didn't
> think capacity was in play as I expected.
> >
> > So for example I might see a rate-limit entry from someone spamming the
> system and then it will usually be gone in a couple days and the buffer i=
s
> completely empty.   Similarly if I do something like ifconfig em0 down;
> ifconfig em0 up ; it's logged but disappears after a day or so.
> >
> > I'm looking to see if this is just a cron job or something clearing it
> as it might be user-error on my part.   Also this is an older system so
> I'll probably look at it again after I update.
>
> I noticed this too, but discovered with =E2=80=9Cdmesg -a=E2=80=9D that t=
he buffer was full
> of syslog messages, so dmesg without -a showed nothing.
>
> It seems unfortunate that syslog messages logged in the message buffer, a=
t
> least once syslogd is running.  Apparently this happens because they are
> output to /dev/console.
>

Output to /dev/console that's not via syslogd goes into this buffer for
syslogd
to harvest and put in log files. IIRC, though, there's also the messages
that
syslogd sends to /dev/console in this buffer as well, which can be
confusing.
I'm not sure what a saner policy would be given both of these use cases.

Warner

                Mike
>
> > Thank you,
> >
> > Dan
> >
> >
> > On Tue, 22 Nov 2022, Warner Losh wrote:
> >
> >> On Tue, Nov 22, 2022 at 8:13 AM Dan Mack  wrote:
> >>
> >>> It seems like dmesg content ages out over time.   Is there a way to
> leave
> >>> the contents based on a fixed memory size instead?
> >>>
> >>
> >> It already is a fixed memory size. Do you see it all disappear at once=
,
> or
> >> over time?
> >>
> >> Warner
> >>
>

--00000000000007a5c705ee12a0d7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable





On Tue, Nov 22, 2022 at 8:49 AM Mike Karels <mike@karels.net> wrote:
On 22 Nov 2022, at 9:34, Da=
n Mack wrote:



> It disappears a piece at a time - the oldest entries disappear first. =
However, it vanishes even when there are only 2-3 lines in it so I didn'=
;t think capacity was in play as I expected.

>

> So for example I might see a rate-limit entry from someone spamming th=
e system and then it will usually be gone in a couple days and the buffer i=
s completely empty.=C2=A0 =C2=A0Similarly if I do something like ifconfig e=
m0 down; ifconfig em0 up ; it's logged but disappears after a day or so=
.

>

> I'm looking to see if this is just a cron job or something clearin=
g it as it might be user-error on my part.=C2=A0 =C2=A0Also this is an olde=
r system so I'll probably look at it again after I update.



I noticed this too, but discovered with =E2=80=9Cdmesg -a=E2=80=9D that the=
 buffer was full

of syslog messages, so dmesg without -a showed nothing.



It seems unfortunate that syslog messages logged in the message buffer, at<=
br>
least once syslogd is running.=C2=A0 Apparently this happens because they a=
re

output to /dev/console.

Output to /dev/=
console that's not via syslogd goes into this buffer for syslogd
<=
div>to harvest and put in log files. IIRC, though, there's also the mes=
sages that
syslogd sends to=C2=A0/dev/console in this buffer as w=
ell, which can be confusing.
I'm not sure what a saner policy=
 would be given both of these use cases.

Warner


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mike



> Thank you,

>

> Dan

>

>

> On Tue, 22 Nov 2022, Warner Losh wrote:

>

>> On Tue, Nov 22, 2022 at 8:13 AM Dan Mack <mack@macktronics.com> wrote:
>>

>>> It seems like dmesg content ages out over time.=C2=A0 =C2=A0Is=
 there a way to leave

>>> the contents based on a fixed memory size instead?

>>>

>>

>> It already is a fixed memory size. Do you see it all disappear at =
once, or

>> over time?

>>

>> Warner

>>






--00000000000007a5c705ee12a0d7--

From nobody Tue Nov 22 18:13:18 2022
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 4NGsnn4Cg5z4jCtP
	for ; Tue, 22 Nov 2022 18:13:33 +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 (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGsnn0Gw4z3n5Q
	for ; Tue, 22 Nov 2022 18:13:32 +0000 (UTC)
	(envelope-from garyj@gmx.de)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417;
	t=1669140800; bh=G6uPsC3UuqVvnPfCZpU8UKjgEtYUTitS5W5iQSW1TCQ=;
	h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References:
	 Reply-To;
	b=LAWKkGraq15yInSswUVdZ8KjehvLfpfVil80GyGv2Q92bWQTgq5k0yCQWl8BwjqjB
	 uF8edddB60C7PwLWbqXi8vbo0ns97xT9yuG/j+bIZfLHOLLupWakkm1+ocJytaJm67
	 VDljssY1KICpZXGr+DMwwLqyeSjOd4T0VKjQ9EVLYsyOzmP+Wu0OC2OslAb5F1Fw+k
	 ZnV1RREwlOzofjKM2sfUCCh8rioLxwxR9HlC7LkIWO6ftoDZlvmWZYroKqZjw5VYzo
	 vc9a4EccotygRyWPjp0poPrEmAsq6flayJDAqeFfY5Fm3YxxtcWT+3jcd+qJoG4PAC
	 X+mq0b/MQeEFQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from ernst.home ([91.2.49.186]) by mail.gmx.net (mrgmx004
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MCbIn-1op3Sd1Cvj-009hh9; Tue, 22
 Nov 2022 19:13:20 +0100
Date: Tue, 22 Nov 2022 19:13:18 +0100
From: Gary Jennejohn 
To: Tomoaki AOKI 
Cc: Dan Mack , Alexander Kabaev ,
 freebsd-current@freebsd.org
Subject: Re: dmesg content lifetime
Message-ID: <20221122191318.1036bc1e@ernst.home>
In-Reply-To: <20221123011655.c6a00ee21636e45e8b4f3a69@dec.sakura.ne.jp>
References: <9d519f-ce87-72d-dc6-789817468974@macktronics.com>
	<20221122104445.4ed88f6f@kan>
	
	<20221123011655.c6a00ee21636e45e8b4f3a69@dec.sakura.ne.jp>
Reply-To: garyj@gmx.de
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:OshA2nM3LzrmoOiYvRYMrnEjAeDElbHssxVVuA+PbiaIA0fLraZ
 NxFIM+cbXGl1PwgXA8nWEZwoqb/YCz3n+SbnhnXW4/KTeuUkEpiqqQqJg9HldrUkNqIsHDk
 l95PW5wTuyMVfmWYnCGbFhkU3KiSDS7ZkSYzgmHBiJhmWFkZ4dWOk9LCRJ2OZz1cLvkJRpR
 7EhpboTMeoo11PmNsF23A==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:Wfwkrbk9yjk=;VGSorksgo2L8lWWlFPNvnuBjHQM
 8L3rKg5a1Rx0b8vC3/2W/q8W2bZJ4taGg0XfC6T2zYFRkEfUV+sA2/k0FI5oldWCK2xA5teCm
 JuB6iMs/AksYZfwQpxwcQ7UIXL8gDP24RCAbDtYi35qypB76vTs7ZdemoLHdi+lDKF61ItGzK
 2SqzH0qER4EvdtSoJcsZRgqbZKDSoTuDuqclWwkvtYRPSrclqvlEUe3oHMr6syR1iqieEAl+j
 H025zxliCcDe3PjblhZ3BcCW6GpbZOIybvUpskE5B3Xp8FXIZ0YmwBpiVbKFPdQ6QOupr71hr
 4CTVq5Vk9NerC3E7lrT8iu3GrQs+8P3QkoxAEOOHLVun/x4O3IKl0NKMf3nL/6oFsaVxKWxws
 NFAFodJ2bxIlhxz/31c1v2jywjJMUtyrE+Vj8hN9UQU6jmr49vSqRi4YA9NaAuqi6dQKkHTug
 a2xyusaQqxaHnKRoFz7AxPS9NRVMTb+bGs3XoLxL+UQxcx/KT9c1qY1WSN7fmFGj3FMFecjE6
 Wpti2GxaJloSMwqWj42CEznbf2EJ+WSND1BTfAs8GlEu1URG2WJL71bwXP1s+0wpgB96wRTWn
 RXQRNRFU6AbetAmX88lTVLvSSB4mUVYg39i/4y0pYGIuD1HuPNVEpZ+9uYWA5PXEauwTPyi2f
 fW4xfBdbh5XrdpF1so1wKznkdM+GgrMYKYKXXTQHufuvC+os5D9wzO/YYS9CHwwZD5v8jvMmv
 38N1cAoMcUuKrjDHnlU3aklEA13BtN3DtCwVppySwbX36oecGYN94dCtpeVVVXIeUKHR0cLyo
 5GfrejPvbjWJQ2fixpGnoeBuOXVcy/2kw1wzzQFTpHg8+SW8RDn15SY/GdqtVCs3rBfiLSQO0
 Jwoj5mry6XtmSnLM0n9QHTmWvj9aNWTEzCq9SVi4dnYn+Pjq1lSoINPI0kKJnIIt3/LCyFQpY
 9ptocQ==
X-Rspamd-Queue-Id: 4NGsnn0Gw4z3n5Q
X-Spamd-Bar: ----
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-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Wed, 23 Nov 2022 01:16:55 +0900
Tomoaki AOKI  wrote:

> On Tue, 22 Nov 2022 09:47:10 -0600 (CST)
> Dan Mack  wrote:
>
> > On Tue, 22 Nov 2022, Alexander Kabaev wrote:
> >
> > > On Tue, 22 Nov 2022 09:12:28 -0600 (CST)
> > > Dan Mack  wrote:
> > >
> > >> It seems like dmesg content ages out over time.   Is there a way to
> > >> leave the contents based on a fixed memory size instead?
> > >>
> > >> Dan
> > >>
> > > I think this is how it works: the kernel message bugger is of fixed
> > > size and kernel and syslog sequences (dmesg -a) share it. The other
> > > syslog users eventually puts enough content in there to displace all=
 of
> > > kernel messages. If the kernel stays quiet, 'dmesg' then returns
> > > nothing, as by default it filters syslog entries that do not KERN
> > > facility out, see sbin/dmesg/dmesg.c.
> > >
> > > --
> > > Alexander Kabaev
> > >
> >
> > Thank you Alexander, I did not know this.  I'll USL (use-the-source-lu=
ke)
> > :-)
> >
> > Dan
>
> Increase kern.msgbufsize tunable on /boot/loader.conf if you want dmesg
> to live longer. For example, recommended value by iwlwifi team is
> 1146880. Much larger than default.
>
> Note that this is actually a tunable and can be set only on boot time.
>

Or look at /var/run/dmesg.boot.  It doesn't get overwritten.

=2D-
Gary Jennejohn

From nobody Tue Nov 22 19:25:02 2022
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 4NGvNT2Yc4z4hNmF
	for ; Tue, 22 Nov 2022 19:25:13 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGvNS4sV9z3wkP
	for ; Tue, 22 Nov 2022 19:25:12 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1])
	by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 2AMJP2Nx054229;
	Tue, 22 Nov 2022 11:25:02 -0800 (PST)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: (from freebsd-rwg@localhost)
	by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 2AMJP2jT054228;
	Tue, 22 Nov 2022 11:25:02 -0800 (PST)
	(envelope-from freebsd-rwg)
From: "Rodney W. Grimes" 
Message-Id: <202211221925.2AMJP2jT054228@gndrsh.dnsmgr.net>
Subject: Re: dmesg content lifetime
In-Reply-To: <21FB93B6-708F-4E69-B482-C7601C15394A@karels.net>
To: Mike Karels 
Date: Tue, 22 Nov 2022 11:25:02 -0800 (PST)
CC: Dan Mack , Warner Losh ,
        freebsd-current@FreeBSD.org
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Rspamd-Queue-Id: 4NGvNS4sV9z3wkP
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

> On 22 Nov 2022, at 9:34, Dan Mack wrote:
> 
> > It disappears a piece at a time - the oldest entries disappear first. However, it vanishes even when there are only 2-3 lines in it so I didn't think capacity was in play as I expected.
> >
> > So for example I might see a rate-limit entry from someone spamming the system and then it will usually be gone in a couple days and the buffer is completely empty.   Similarly if I do something like ifconfig em0 down; ifconfig em0 up ; it's logged but disappears after a day or so.
> >
> > I'm looking to see if this is just a cron job or something clearing it as it might be user-error on my part.   Also this is an older system so I'll probably look at it again after I update.
> 
> I noticed this too, but discovered with ?dmesg -a? that the buffer was full
> of syslog messages, so dmesg without -a showed nothing.
> 
> It seems unfortunate that syslog messages logged in the message buffer, at
> least once syslogd is running.  Apparently this happens because they are
> output to /dev/console.
> 
> 		Mike

I very much dislike this behavior.  I though that the kernel dmesg buffer
was for kernel messages only and that I could always count on going there
for any kernel messages about a problem that has occurred, expecting to
see my boot time output if nothing had happened since boot.  Now instead
I am almost always greated with an empty buffer :-(.

Rod

> 
> > Thank you,
> >
> > Dan
> >
> >
> > On Tue, 22 Nov 2022, Warner Losh wrote:
> >
> >> On Tue, Nov 22, 2022 at 8:13 AM Dan Mack  wrote:
> >>
> >>> It seems like dmesg content ages out over time.   Is there a way to leave
> >>> the contents based on a fixed memory size instead?
> >>>
> >>
> >> It already is a fixed memory size. Do you see it all disappear at once, or
> >> over time?
> >>
> >> Warner
> >>
> 
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org

From nobody Tue Nov 22 19:28:44 2022
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 4NGvSb74Y7z4hNrN
	for ; Tue, 22 Nov 2022 19:28:47 +0000 (UTC)
	(envelope-from mike@sentex.net)
Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGvSb1h2Kz3xvF
	for ; Tue, 22 Nov 2022 19:28:47 +0000 (UTC)
	(envelope-from mike@sentex.net)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net;
	dmarc=none
Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19])
	by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 2AMJSiaU059652
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL);
	Tue, 22 Nov 2022 14:28:44 -0500 (EST)
	(envelope-from mike@sentex.net)
Received: from [IPV6:2607:f3e0:0:4:bd64:76f:25e7:3d7a] ([IPv6:2607:f3e0:0:4:bd64:76f:25e7:3d7a])
	by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 2AMJShB4092422
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
	Tue, 22 Nov 2022 14:28:44 -0500 (EST)
	(envelope-from mike@sentex.net)
Message-ID: <8d8c4b03-323a-8e4d-44fd-e47749d2fd85@sentex.net>
Date: Tue, 22 Nov 2022 14:28:44 -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/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: ULE realtime scheduler advice needed
Content-Language: en-US
To: Hans Petter Selasky ,
        FreeBSD Current 
References: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
From: mike tancsa 
In-Reply-To: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.84 on 64.7.153.18
X-Spamd-Result: default: False [-3.35 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-0.95)[-0.948];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32];
	RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_TLS_ALL(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FREEFALL_USER(0.00)[mike];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[sentex.net];
	ARC_NA(0.00)[]
X-Rspamd-Queue-Id: 4NGvSb1h2Kz3xvF
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On 11/17/2022 11:47 PM, Hans Petter Selasky wrote:
> Hi,
>
> I'm doing some work with audio and have noticed some problems with the 
> ULE scheduler. I have a program that generate audio based on 
> key-presses. When no keys are pressed, the load is near 0%, but as 
> soon as you start pressing keys, the load goes maybe to 80% of a CPU 
> core. This program I run with rtprio 8 xxx. The issue I observe or 
> hear actually, is that it takes too long until the scheduler grasps 
> that this program needs it's own CPU core and stops time-sharing the 
> program. When I however use cpuset -l xxx rtprio 8 yyy everything is 
> good, and the program outputs realtime audio in-time.
>
> Or is this perhaps a CPU frequency stepping issue?
>
> Any advice on where to look?
>
A long shot, but I am curious if by chance you have hwpstate_intel for 
your cpu frequency driver. If so, does setting 
dev.hwpstate_intel.0.epp=0 make any difference ?

     ---Mike



From nobody Tue Nov 22 21:03:50 2022
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 4NGxZT52Klz4hbbF
	for ; Tue, 22 Nov 2022 21:04:01 +0000 (UTC)
	(envelope-from ted@io-tx.com)
Received: from io-tx.com (io-tx.com [205.166.246.111])
	(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 "*.io-tx.com", Issuer "AlphaSSL CA - SHA256 - G2" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGxZT2TGTz465p
	for ; Tue, 22 Nov 2022 21:04:01 +0000 (UTC)
	(envelope-from ted@io-tx.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from io-tx.com (io-tx.com [205.166.246.111])
	(authenticated bits=0)
	by io-tx.com (8.17.1/8.16.1) with ESMTPSA id 2AML3oI9064440
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 22 Nov 2022 15:03:50 -0600 (CST)
	(envelope-from ted@io-tx.com)
Date: Tue, 22 Nov 2022 15:03:50 -0600 (CST)
From: Ted Hatfield 
To: "Rodney W. Grimes" 
cc: Mike Karels , Dan Mack ,
        Warner Losh , freebsd-current@FreeBSD.org
Subject: Re: dmesg content lifetime
In-Reply-To: <202211221925.2AMJP2jT054228@gndrsh.dnsmgr.net>
Message-ID: <8e999d31-e37f-7cda-509e-cf1d83fc9fca@io-tx.com>
References: <202211221925.2AMJP2jT054228@gndrsh.dnsmgr.net>
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
X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL,
	KAM_DMARC_STATUS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on io-tx.com
X-Rspamd-Queue-Id: 4NGxZT2TGTz465p
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:55103, ipnet:205.166.246.0/24, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 22 Nov 2022, Rodney W. Grimes wrote:

>> On 22 Nov 2022, at 9:34, Dan Mack wrote:
>>
>>> It disappears a piece at a time - the oldest entries disappear first. However, it vanishes even when there are only 2-3 lines in it so I didn't think capacity was in play as I expected.
>>>
>>> So for example I might see a rate-limit entry from someone spamming the system and then it will usually be gone in a couple days and the buffer is completely empty.   Similarly if I do something like ifconfig em0 down; ifconfig em0 up ; it's logged but disappears after a day or so.
>>>
>>> I'm looking to see if this is just a cron job or something clearing it as it might be user-error on my part.   Also this is an older system so I'll probably look at it again after I update.
>>
>> I noticed this too, but discovered with ?dmesg -a? that the buffer was full
>> of syslog messages, so dmesg without -a showed nothing.
>>
>> It seems unfortunate that syslog messages logged in the message buffer, at
>> least once syslogd is running.  Apparently this happens because they are
>> output to /dev/console.
>>
>> 		Mike
>
> I very much dislike this behavior.  I though that the kernel dmesg buffer
> was for kernel messages only and that I could always count on going there
> for any kernel messages about a problem that has occurred, expecting to
> see my boot time output if nothing had happened since boot.  Now instead
> I am almost always greated with an empty buffer :-(.
>
> Rod
>

It's been this way for as long as I can remember.  Decades probably.

Ted


>>
>>> Thank you,
>>>
>>> Dan
>>>
>>>
>>> On Tue, 22 Nov 2022, Warner Losh wrote:
>>>
>>>> On Tue, Nov 22, 2022 at 8:13 AM Dan Mack  wrote:
>>>>
>>>>> It seems like dmesg content ages out over time.   Is there a way to leave
>>>>> the contents based on a fixed memory size instead?
>>>>>
>>>>
>>>> It already is a fixed memory size. Do you see it all disappear at once, or
>>>> over time?
>>>>
>>>> Warner
>>>>
>>
>>
>>
>
> -- 
> Rod Grimes                                                 rgrimes@freebsd.org
>
>


From nobody Tue Nov 22 21:38:04 2022
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 4NGyL10PcZz4hgNl
	for ; Tue, 22 Nov 2022 21:38:17 +0000 (UTC)
	(envelope-from hps@selasky.org)
Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGyL05B1Nz4CdN
	for ; Tue, 22 Nov 2022 21:38:16 +0000 (UTC)
	(envelope-from hps@selasky.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: from [10.36.2.69] (unknown [84.210.222.10])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.turbocat.net (Postfix) with ESMTPSA id 4F9FA26016E;
	Tue, 22 Nov 2022 22:38:07 +0100 (CET)
Message-ID: <1a404155-4ca9-4e88-4c40-5407c2ae52a9@selasky.org>
Date: Tue, 22 Nov 2022 22:38:04 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: ULE realtime scheduler advice needed
To: mike tancsa ,
 FreeBSD Current 
References: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
 <8d8c4b03-323a-8e4d-44fd-e47749d2fd85@sentex.net>
Content-Language: en-US
From: Hans Petter Selasky 
In-Reply-To: <8d8c4b03-323a-8e4d-44fd-e47749d2fd85@sentex.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4NGyL05B1Nz4CdN
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On 11/22/22 20:28, mike tancsa wrote:
> On 11/17/2022 11:47 PM, Hans Petter Selasky wrote:
>> Hi,
>>
>> I'm doing some work with audio and have noticed some problems with the 
>> ULE scheduler. I have a program that generate audio based on 
>> key-presses. When no keys are pressed, the load is near 0%, but as 
>> soon as you start pressing keys, the load goes maybe to 80% of a CPU 
>> core. This program I run with rtprio 8 xxx. The issue I observe or 
>> hear actually, is that it takes too long until the scheduler grasps 
>> that this program needs it's own CPU core and stops time-sharing the 
>> program. When I however use cpuset -l xxx rtprio 8 yyy everything is 
>> good, and the program outputs realtime audio in-time.
>>
>> Or is this perhaps a CPU frequency stepping issue?
>>
>> Any advice on where to look?
>>
> A long shot, but I am curious if by chance you have hwpstate_intel for 
> your cpu frequency driver. If so, does setting 
> dev.hwpstate_intel.0.epp=0 make any difference ?
> 

Yes, I have four of those, set to 50 by default. Let me try.

--HPS


From nobody Tue Nov 22 22:00:14 2022
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 4NGyqZ1kSLz4hjjm
	for ; Tue, 22 Nov 2022 22:00:26 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGyqY4HxFz4GV1
	for ; Tue, 22 Nov 2022 22:00:25 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2AMM0E5L034973;
	Wed, 23 Nov 2022 07:00:18 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Wed, 23 Nov 2022 07:00:14 +0900
From: Tomoaki AOKI 
To: Hans Petter Selasky 
Cc: mike tancsa ,
        FreeBSD Current
 
Subject: Re: ULE realtime scheduler advice needed
Message-Id: <20221123070014.71f5cc4f1d86cb4d4c0f6bf6@dec.sakura.ne.jp>
In-Reply-To: <1a404155-4ca9-4e88-4c40-5407c2ae52a9@selasky.org>
References: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
	<8d8c4b03-323a-8e4d-44fd-e47749d2fd85@sentex.net>
	<1a404155-4ca9-4e88-4c40-5407c2ae52a9@selasky.org>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4NGyqY4HxFz4GV1
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 22 Nov 2022 22:38:04 +0100
Hans Petter Selasky  wrote:

> On 11/22/22 20:28, mike tancsa wrote:
> > On 11/17/2022 11:47 PM, Hans Petter Selasky wrote:
> >> Hi,
> >>
> >> I'm doing some work with audio and have noticed some problems with the 
> >> ULE scheduler. I have a program that generate audio based on 
> >> key-presses. When no keys are pressed, the load is near 0%, but as 
> >> soon as you start pressing keys, the load goes maybe to 80% of a CPU 
> >> core. This program I run with rtprio 8 xxx. The issue I observe or 
> >> hear actually, is that it takes too long until the scheduler grasps 
> >> that this program needs it's own CPU core and stops time-sharing the 
> >> program. When I however use cpuset -l xxx rtprio 8 yyy everything is 
> >> good, and the program outputs realtime audio in-time.
> >>
> >> Or is this perhaps a CPU frequency stepping issue?
> >>
> >> Any advice on where to look?
> >>
> > A long shot, but I am curious if by chance you have hwpstate_intel for 
> > your cpu frequency driver. If so, does setting 
> > dev.hwpstate_intel.0.epp=0 make any difference ?
> > 
> 
> Yes, I have four of those, set to 50 by default. Let me try.
> 
> --HPS

FYI: I habitally run below manually (as root) when I'm on AC powerline.

sysctl -aN | fgrep dev.hwpstate | fgrep epp | while read OID ; do ; \
sysctl ${OID}=0 ; done

-- 
Tomoaki AOKI    

From nobody Tue Nov 22 22:16:19 2022
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 4NGz9z1xLGz4hlR6
	for ; Tue, 22 Nov 2022 22:16:23 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NGz9y69mXz4KwQ
	for ; Tue, 22 Nov 2022 22:16:22 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2AMMGJrc038029;
	Wed, 23 Nov 2022 07:16:20 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Wed, 23 Nov 2022 07:16:19 +0900
From: Tomoaki AOKI 
To: freebsd-current@freebsd.org
Cc: garyj@gmx.de
Subject: Re: dmesg content lifetime
Message-Id: <20221123071619.4d9fc5c297c165ad98cf343d@dec.sakura.ne.jp>
In-Reply-To: <20221122191318.1036bc1e@ernst.home>
References: <9d519f-ce87-72d-dc6-789817468974@macktronics.com>
	<20221122104445.4ed88f6f@kan>
	
	<20221123011655.c6a00ee21636e45e8b4f3a69@dec.sakura.ne.jp>
	<20221122191318.1036bc1e@ernst.home>
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4NGz9y69mXz4KwQ
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, 22 Nov 2022 19:13:18 +0100
Gary Jennejohn  wrote:

> On Wed, 23 Nov 2022 01:16:55 +0900
> Tomoaki AOKI  wrote:
> 
> > On Tue, 22 Nov 2022 09:47:10 -0600 (CST)
> > Dan Mack  wrote:
> >
> > > On Tue, 22 Nov 2022, Alexander Kabaev wrote:
> > >
> > > > On Tue, 22 Nov 2022 09:12:28 -0600 (CST)
> > > > Dan Mack  wrote:
> > > >
> > > >> It seems like dmesg content ages out over time.   Is there a way to
> > > >> leave the contents based on a fixed memory size instead?
> > > >>
> > > >> Dan
> > > >>
> > > > I think this is how it works: the kernel message bugger is of fixed
> > > > size and kernel and syslog sequences (dmesg -a) share it. The other
> > > > syslog users eventually puts enough content in there to displace all of
> > > > kernel messages. If the kernel stays quiet, 'dmesg' then returns
> > > > nothing, as by default it filters syslog entries that do not KERN
> > > > facility out, see sbin/dmesg/dmesg.c.
> > > >
> > > > --
> > > > Alexander Kabaev
> > > >
> > >
> > > Thank you Alexander, I did not know this.  I'll USL (use-the-source-luke)
> > > :-)
> > >
> > > Dan
> >
> > Increase kern.msgbufsize tunable on /boot/loader.conf if you want dmesg
> > to live longer. For example, recommended value by iwlwifi team is
> > 1146880. Much larger than default.
> >
> > Note that this is actually a tunable and can be set only on boot time.
> >
> 
> Or look at /var/run/dmesg.boot.  It doesn't get overwritten.
> 
> --
> Gary Jennejohn

It may be overwritten on reboot.
And there are dmesg.[today|yesterday] on /var/log/, too.
Rotated daily.

-- 
Tomoaki AOKI    

From nobody Wed Nov 23 10:56:07 2022
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 4NHJ2f1CH3z4jLZg
	for ; Wed, 23 Nov 2022 10:56:10 +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 (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NHJ2c56r9z4NSR
	for ; Wed, 23 Nov 2022 10:56:08 +0000 (UTC)
	(envelope-from garyj@gmx.de)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmx.de header.s=s31663417 header.b=QQG7Xj0W;
	spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.15.19 as permitted sender) smtp.mailfrom=garyj@gmx.de;
	dmarc=pass (policy=none) header.from=gmx.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417;
	t=1669200967; bh=jTlNlK3VO0UbUHnIjWJT1KZpodk9j7i2WssRHT+vYFQ=;
	h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References:
	 Reply-To;
	b=QQG7Xj0WTEEkI05Ow+UlbLcNXY0wjcjvYT2SLP7y5kVS8dqj/ox9iavjyUYXJGD3I
	 iKv/WBQ9auyfsDyG3c1zzJ68vEXWOUrQHC2r7iyXDbLb96lDFqmgIQFCbozPSHGNrf
	 pKZnbgB/bo9S6RJZSarLJfwhHMiL4GQS+IIEzb0koQR3g+qL3rFA3Cqd+6o6R67+tr
	 xK75SO9qKpAkLRnREgnx+02pANsEk6ZKQxFBJacpEAeyLj+Dqxts8o01Y5dIZVSEE7
	 G9a5tncCR2PiitMiGreccBuUXRtf4IV/7qV22wSOo3RBDJNMxZX2sOHwynBc32HReH
	 fothPATkhUaaQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from ernst.home ([91.2.49.186]) by mail.gmx.net (mrgmx004
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MatVh-1pUvW80fBz-00cSiv for
 ; Wed, 23 Nov 2022 11:56:07 +0100
Date: Wed, 23 Nov 2022 11:56:07 +0100
From: Gary Jennejohn 
To: freebsd-current@freebsd.org
Subject: Re: dmesg content lifetime
Message-ID: <20221123115607.0a3a8d80@ernst.home>
In-Reply-To: <20221123071619.4d9fc5c297c165ad98cf343d@dec.sakura.ne.jp>
References: <9d519f-ce87-72d-dc6-789817468974@macktronics.com>
	<20221122104445.4ed88f6f@kan>
	
	<20221123011655.c6a00ee21636e45e8b4f3a69@dec.sakura.ne.jp>
	<20221122191318.1036bc1e@ernst.home>
	<20221123071619.4d9fc5c297c165ad98cf343d@dec.sakura.ne.jp>
Reply-To: garyj@gmx.de
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:EvTVlP97fFiTfPRgHvEqxQ8RxoILe+TmI5N6mt83JiHMc8cspvy
 JDeBz4+FshZdeWM1R8EbkUIJuBQeoWTQBQAWyn480s6detDL8rkl5K7KbeMxnoQHJV6JSwc
 zZCXOC9e/jr0fsBi2a8HoKEM79FrX6ExXpZD72rJ/TVylyX4IxJ0wf/2QYC5ANTc7jJl8BD
 QZ5vZeRllTqRdEl0KkICA==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:sIzK5D9VtNw=;+R/BWNPCgM1idKcgoa0SbwJSTL4
 +whM4iteJj0dTTx57ovqVzq7HyrsGKpnbDi7P08ZN8L5w9BvkqnKgBWofY1XtQMyE+n0/gsle
 ys2YZ2RApRZrzEH3zEUWOIkrE6d+z1znGXKWxiEZc2+ncaCbIqmJUYGoC2y2RopZOnbM409Yz
 wuviVQNLwvx6EzLKbdDCM6HH65s8aoyBCNADwxTxhU72mJEiGqHkADSxnjFNF+PTJVVl4yUmv
 FjImGdoWeTr2VZOyR4zygaHP8tNZm+IPblM8O+v6I0DwCRMM4+WXGcjA2VxQdtWn1EOxOYw77
 CSKisbN7L3CFxOClnJLgTGevjMnerZYprZiVPPO+Gi6JA1VR59RcApr8iSCTsCYUFhen20UDY
 dUBGE8xeMY/fKxSO7WLO+eybUp8drD9qF7YZDZruQpikqKRtno1gAaBuuMM1a7Wcj3f4KPgiw
 kO7S/z+zIvG06VfLKzO2gdn0+MRWvHgZB9TbGM49NZxwzgV2Jes/yuDsvoPnEgbtLf0lWPh+j
 68OzU0/w7CSMRbpsVTdeXrkfQtum5AxeL2riiidvbVQgYs+x3h+rUUj/TdjEyldDTGv69rcLp
 SOqWpVemyvSBKZ6NQgP7JE7Iduqn50MBDkJ+LLAr50B18FvS0nzRDuL1skDq2uTSod6Z1ylb0
 E0EWJVhQhLnY2QO1mSgdIAUcK2IEcbfUGirjMgWQjXLYps90vzpnZxFYjDlyfMz8W00eaFcX6
 lvNXtStNCEeRmG9uNgO7e1i/Bh8ft5UTW2Y5hZ2kpEI89L3iqU18sVrLxMAwmcq+RpDjiNqBs
 Mcdd/t/Z9lz9ijjU/SSmCeM07k064vCWRdje8xOIG9ZKrKdU7uVS6l8BweAWks/Ql/+Y1wiUt
 FmMD19l8y1td7DxWUXOSOuNSWLJjrMtIAA9AFZAgzpCwDzVQ414ztVpXh4SxYarGHOuVmTjNw
 VeWHHw==
X-Spamd-Result: default: False [-1.17 / 15.00];
	NEURAL_HAM_MEDIUM(-0.84)[-0.835];
	NEURAL_SPAM_SHORT(0.54)[0.541];
	DMARC_POLICY_ALLOW(-0.50)[gmx.de,none];
	NEURAL_SPAM_LONG(0.23)[0.229];
	R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25];
	R_DKIM_ALLOW(-0.20)[gmx.de:s=s31663417];
	RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_REPLYTO(0.00)[gmx.de];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	HAS_REPLYTO(0.00)[garyj@gmx.de];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	FREEMAIL_FROM(0.00)[gmx.de];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_NONE(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[gmx.de:+];
	FREEMAIL_ENVFROM(0.00)[gmx.de];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NHJ2c56r9z4NSR
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

On Wed, 23 Nov 2022 07:16:19 +0900
Tomoaki AOKI  wrote:

> On Tue, 22 Nov 2022 19:13:18 +0100
> Gary Jennejohn  wrote:
> > Or look at /var/run/dmesg.boot.  It doesn't get overwritten.
> >
>
> It may be overwritten on reboot.
> And there are dmesg.[today|yesterday] on /var/log/, too.
> Rotated daily.
>

Yes, it definitely does get overwritten on reboot.  But at least its
contents are stable between boots.

=2D-
Gary Jennejohn

From nobody Wed Nov 23 13:13:27 2022
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 4NHM5D1fJMz4hMjY
	for ; Wed, 23 Nov 2022 13:13:36 +0000 (UTC)
	(envelope-from mike@sentex.net)
Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NHM5C6P9Yz4X6R
	for ; Wed, 23 Nov 2022 13:13:35 +0000 (UTC)
	(envelope-from mike@sentex.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19])
	by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 2ANDDSxX067449
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL);
	Wed, 23 Nov 2022 08:13:28 -0500 (EST)
	(envelope-from mike@sentex.net)
Received: from [IPV6:2607:f3e0:0:4:c0b6:89d8:b838:d5de] ([IPv6:2607:f3e0:0:4:c0b6:89d8:b838:d5de])
	by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 2ANDDRUV036646
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
	Wed, 23 Nov 2022 08:13:28 -0500 (EST)
	(envelope-from mike@sentex.net)
Message-ID: <1513f368-bdec-7c93-7c58-c23c5f594f01@sentex.net>
Date: Wed, 23 Nov 2022 08:13:27 -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/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: ULE realtime scheduler advice needed
Content-Language: en-US
To: Tomoaki AOKI ,
        Hans Petter Selasky 
Cc: FreeBSD Current 
References: <7ad10a5e-29d6-aaef-25cf-407d65f056cc@selasky.org>
 <8d8c4b03-323a-8e4d-44fd-e47749d2fd85@sentex.net>
 <1a404155-4ca9-4e88-4c40-5407c2ae52a9@selasky.org>
 <20221123070014.71f5cc4f1d86cb4d4c0f6bf6@dec.sakura.ne.jp>
From: mike tancsa 
In-Reply-To: <20221123070014.71f5cc4f1d86cb4d4c0f6bf6@dec.sakura.ne.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.84 on 64.7.153.18
X-Rspamd-Queue-Id: 4NHM5C6P9Yz4X6R
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On 11/22/2022 5:00 PM, Tomoaki AOKI wrote:
> A long shot, but I am curious if by chance you have hwpstate_intel for
>>> your cpu frequency driver. If so, does setting
>>> dev.hwpstate_intel.0.epp=0 make any difference ?
>>>
>> Yes, I have four of those, set to 50 by default. Let me try.
>>
>> --HPS
> FYI: I habitally run below manually (as root) when I'm on AC powerline.
>
> sysctl -aN | fgrep dev.hwpstate | fgrep epp | while read OID ; do ; \
> sysctl ${OID}=0 ; done

It was a bit of a POLA the first time I encountered this driver going 
from 12 to RELENG_13. Same hardware behaved rather differently as its a 
different power profile default than what I expected and for my use case 
(firewall and router) it was causing dropped packets

     ---Mike



From nobody Thu Nov 24 07:38:12 2022
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 4NHqc54cMgz4hTCb
	for ; Thu, 24 Nov 2022 07:38:29 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.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 4NHqc44t4Mz3khH
	for ; Thu, 24 Nov 2022 07:38:28 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=bBftJmir;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669275504; bh=iWETWzD1lR6Rccscbb9+dzLPMRZFqykSBPyZb7h3rQk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=bBftJmirA9BNZHRQOam5SdcuiBstTkuKMRA3yH71vgH24D+TZjXsxhM3uUPSbr2lIKnGX+lORx5SaX8v8gqTvTN/UuugoigVyQiH5dq64pvWw8HAw4/UbouZx1BDbrhCnLC92Dx7+devcsqEz78NtStUBulH5VC2Ulcgye1JpFuM0jKIsGjUODKu7ufPEhe7xXpAKyBh6fGyciKkhMkPqO94/+FjrcET7GD3x4SEAtIGXq6gZYHFbIQyzGhRstc+qGThZsuTQXKxoj8FumJDAmxunrsdGS7Z+VwufgKTfTLrSsc9wOtZ67uZ5FcNIsTMtXui08y0L/zEfYzOgnUWRQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669275504; bh=qxFg/bbvDvnOXxX3OuaVnfzxwbldoR0TOXiZwaxQ/BH=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kB+c4Q/rT97cUPI3RtvgdkvFoyHiDK+FQlC7tGn4g2xrpD1lKmrFP2zGzFN7z+JuY1Kk7XDhXcpyIC7C5lArpqNndyDVkEkyWHvJeaJGLW68mg7q3KXvDqV9kp8ajJB7adSV83EOyeNFwHf5PkEfOOqb+gymZa04E6we2Piq2AMsWOhd0+e2UHb20YqmoAIJ3f1hOjJ5PF49WqzEiprsGTzYhtVhHLmYnej3zT+t6TH7qfcMt9gYgflQ3bq6TrlGwr9YkWcMJrDfjYc8TEsbSVqxbrAdSnoQmgBzk1tS/scqZOSNMYDzEjhNdG+PBEd3+6mUGsXwJ+Wgt9NPO/BvPQ==
X-YMail-OSG: mVO6SBkVM1ls.0Z2Ie8_bpsqZtnZNHUwI5qXLICTQ8_y.xwaFQzqshDSBXlHrJo
 ApzL5VZuI22LBvB8aQ.BgGn4.m6rHC6m0C6h.ddBHMqmRPsXok32IJLPHLZlmfYjB_9qtVQXqBHN
 dFwKIt3q9f5dANbSQF16mvUu57n67As_Q6hiBIw4FUGDBnX4TojK83lGSwvS4_bWxrClf6POv61O
 K_xIrccqCCyZiTX2rjLVnbigfA_6ytnsfDT_UPIxkvPNNKQcHGWB2GQfEKQHYdQkRdVgIZuyXDAO
 PRMxYLjyFcJjp14niwt7GmD6qiwtFQXhNZ7s3vkctVc7C_sZlWX91cLcrMFihBYEhAMw4YAZ3BI5
 nS5liyS_lIsHWTOpdRJ2t4a9tdxpoeUvEL7p2C2u5DxPh2e3z41rmVtAOhiFtnzO2BmUak89Oftd
 iZPg5.tmjOmeqkOPQ3qSNUbvJfGdWfTaMVJHjKzjTJD4rGa3vm5oe632giiPOhlu9KRhsyEiFzO9
 p.nUH1CgRcpo2couAnpU50tlflcvPbEl9DFRe6IoyFL1R.vNokX5.A8osygcDWKnfbuaUGXB5u.O
 Fk9OulRuLU48woVJqCrR_Y2uFB.neyDC6sWuLIhJ81sS_3d9IcJ8hOg3qRSyfVEsDOmZmBsYjEs5
 PapdIzDORW9jeIMBVwicEnHenYGRzVO2zBmtMfO7fO.Y3yMyY8s8nom0RydNnqmnMC4vn89Pic6c
 3IriUZbWLqKsTlKlRkOQo1nMn7hbmsmqE2PTlYlD5EXJFy.dlW6hVIH_MHYdCn0tvoyll9_69TEJ
 9S3V7W59I8jlXkpHntb1yvrBLMxBZ99vm4MmKTevPoDFZZAxXfoI6xijqzahPjbX0_BhpjESY3m7
 IZmAfui6_eRIqop4aMFFvoImSH.CwqoEc9nkjLeu_M.I2z6abWDMVAyWQwUrhU_JrtZq2JZZblHB
 FkUci_uMd4h4moIxlBfLWz4QQec6.sR_9vn66luxqIvibzB4nIyqEjJ1dTDh64DQhiuYrapLGcVF
 54Mx9ZSM2mRStjZenDgYr.gZc8XGuFqAHy5QwCF1I.sfE.RaZr7U9dr1nxCuvYyyTrQRtMnycCM9
 HTzXIA91gSgfLsfyaL.qTv29Zk_xr_lW6gPk2Bi6HytZ8kD34LFzTw3jtWxMoJ17sVMKrukqhT1q
 wU07ffhsxMOLIYONUB5wxT7BxRb_gW.w8AYComsg5PAzhfBvlUtZO7AxmPXlj1IUFLJ4mk4XwftS
 EDXSf5sfPtCIVVqCG_TzmJYCjcpsx3ZHogoJ02Cn_8yekEzCqT0sEHL8axdfylIbZ.E3USeTZ_sF
 .zwrXxMIT9bX.VUCuO_CEqP4ujXEryjo4r.kVxFNP.C0Qss36NH9.tQL5uRj7SUtwmD_D_caZlgY
 4Qgm1nlJ5122mPCsPNgSSks3SvjnGxG2Z7xiWNL4_IrP7btx_Zvvw4qEqQHjKZpjzOv8zTi2DacS
 1ftAz37xZdrLQ7woKXhyhAEF_sOkHZgFqN_KfhgkjSbi1Ez9AKCMNGYS2ss7CcKjTmAuOqX4Y492
 7wGE9RU6YqqazofgGav8IeEnkwQoA9Px604rO9NUo3oIZepOgCYi.naR4hAOuSIBF433xmv4fso7
 d0ohcV1FYCGKg1WqlrZmngIGZIbF8WpRvZZj6aMT8Fhm7sEADwu94aFwgtwLBzXsxSDOV._SyKcR
 bIyOCL03syIhrzZmfO1UBNnaet4i9cw5DYtCbjNh97Ciuhpzc6cfU1MjJ9Ui1j.OTe9tZtz6kEMC
 xuyDikjG1SRDr2ZSB33CpKDVa.VuWm_d8lUFQr3.1nIIlc39C3BLJYag2.1Kczt.2nQMIWB0pKty
 aomnWZlR1lCRHVyF2gOtbWIvVY5x0sGJ7G1fn3MbKCupdA.68a9j4fQ6koaBex22sYqdkHjBVluU
 t7kTikcwoeI7Mqw4uoaeVSEMLZ6uG63Gd5UKySdRFXVZWNDwfvaVaz3QwjOrXYgiXecv5KrQxFMF
 B8YWE3x1jAisrzq.A2Ke7YdsU3uxCUwDxdsh.wswBQ8Mw6ENWseo0gtFoGqykm8kdI.V6hTDiQCc
 YjRLMDoyxg9GA8CReoBfJy2BgDTImQSwMaz73xPL1ZNgu1RgL_CXmQ0fpucIvlzYfbK5x0xj2Mkz
 7_acJF4xBReFkrDih8KJOKB..ktha_K2Qry61gjIKABWUffeWpNMnqa.zcjrYCzUW8ahrGGj3dDJ
 E2d7INTKHzz4zg_zX5UtmfWd.4wSAEFFkRh3T1Wju5IEzql86T5JB08NwOf0-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 24 Nov 2022 07:38:24 +0000
Received: by hermes--production-ne1-6bcfb7fb87-s7whx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9529c5a6f67f671fc3a07ff54ddbdb40;
          Thu, 24 Nov 2022 07:38:23 +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 \(3731.200.110.1.12\))
Subject: Example "tools/build/make.py --bootstrap-toolchain" failure under
 macOS 13.0.1: libcrypt related not-founds
Message-Id: <4BD55079-7C73-491B-906A-7260175F2DE2@yahoo.com>
Date: Wed, 23 Nov 2022 23:38:12 -0800
To: freebsd-current 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: <4BD55079-7C73-491B-906A-7260175F2DE2.ref@yahoo.com>
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4NHqc44t4Mz3khH
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

My first ever attempt to build a FreeBSD outside of FreeBSD (macOS =
13.0.1)
looked like:

# env MAKEOBJDIRPREFIX=3D/Users/markmi/obj tools/build/make.py =
--bootstrap-toolchain buildworld buildkernel TARGET=3Damd64 =
TARGET_ARCH=3Damd64

It got:

. . .
mkdir -p =
"/Users/markmi/obj/Users/markmi/main-src/amd64.amd64/tmp/legacy//usr/inclu=
de/x86"
cd /Users/markmi/main-src/tools/build;  =
/Users/markmi/obj/bmake-install/bin/bmake DIRPRFX=3Dtools/build/ =
DESTDIR=3D/Users/markmi/obj/Users/markmi/main-src/amd64.amd64/tmp/legacy =
host-symlinks
Linking host tools into =
/Users/markmi/obj/Users/markmi/main-src/amd64.amd64/tmp/legacy/bin
Cannot find host tool 'unxz' in PATH =
(/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin).
*** Error code 1


So it looks like I needed to do the likes of:

# /bin/bash -c "$(curl -fsSL =
https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# brew install libarchive

after that, retrying:

# env MAKEOBJDIRPREFIX=3D/Users/markmi/obj tools/build/make.py =
--bootstrap-toolchain buildworld buildkernel TARGET=3Damd64 =
TARGET_ARCH=3Damd64

progressed until:

cc -O2 -pipe -fno-common -I. -I/Users/markmi/main-src/contrib/com_err =
-std=3Dgnu99 -Wno-format-zero-length -Wno-pointer-sign =
-Wno-system-headers -Wno-empty-body -Wno-string-plus-int =
-Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable =
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality =
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef =
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum =
-Wno-knr-promoted-parameter -Wno-parentheses -Wno-typedef-redefinition =
-Werror=3Dincompatible-pointer-types-discards-qualifiers =
-Qunused-arguments =
-I/Users/markmi/obj/Users/markmi/main-src/amd64.amd64/tmp/legacy/usr/inclu=
de -Werror=3Dimplicit-function-declaration -Werror=3Dimplicit-int =
-Werror=3Dreturn-type -Wundef -DHAVE_NBTOOL_CONFIG_H=3D1 =
-I/Users/markmi/main-src/tools/build/cross-build/include/common =
-D_DARWIN_C_SOURCE=3D1 =
-I/Users/markmi/main-src/tools/build/cross-build/include/mac -idirafter =
/Users/markmi/main-src/contrib/libarchive/libarchive    =
-L/Users/markmi/obj/Users/markmi/main-src/amd64.amd64/tmp/legacy/usr/lib =
-o compile_et compile_et.o parse.o lex.o  =
-L/Users/markmi/obj/Users/markmi/main-src/amd64.amd64/tmp/obj-tools/kerber=
os5/lib/libroken -lroken =
-L/Users/markmi/obj/Users/markmi/main-src/amd64.amd64/tmp/obj-tools/lib/li=
bcrypt -lcrypt =
-L/Users/markmi/obj/Users/markmi/main-src/amd64.amd64/tmp/obj-tools/kerber=
os5/lib/libvers -lvers  -legacy -lresolv
ld: warning: directory not found for option =
'-L/Users/markmi/obj/Users/markmi/main-src/amd64.amd64/tmp/obj-tools/lib/l=
ibcrypt'
ld: library not found for -lcrypt
clang: error: linker command failed with exit code 1 (use -v to see =
invocation)
*** Error code 1


Looking, I found a prior line in the output that started with:

echo compile_et:  =
/Users/markmi/obj/Users/markmi/main-src/amd64.amd64/tmp/legacy/usr/lib/lib=
roken.a /usr/lib/libcrypt.a

But:

% ls -Tld /usr/lib/libcrypt.a
ls: /usr/lib/libcrypt.a: No such file or directory


For reference, the source tree was based on:

f83db6441a2f (HEAD -> main, freebsd/main, freebsd/HEAD) sctp: minor =
changes due to upstreaming of Glebs recent changes
branch: main
merge-base: f83db6441a2f4f925a169c7ddf844589cb73c9b5
merge-base: CommitDate: 2022-11-06 22:06:40 +0000
n259064 (--first-parent --count for merge-base)

It was a copy I made of the directory tree I used for the
ThreadRipper 1950X's most recent update to its FreeBSD.
The macOS machine is a 2018 macMini (so: Intel).
=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com


From nobody Thu Nov 24 12:02:35 2022
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 4NHxT35mmFz4j2LY
	for ; Thu, 24 Nov 2022 12:02:47 +0000 (UTC)
	(envelope-from eduardo@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NHxT357lPz43Lq
	for ; Thu, 24 Nov 2022 12:02:47 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1669291367;
	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=hTraNByM9Jl2TcWesBGdVBzd4/NCPuiZndofyIgcbPI=;
	b=a5JbGl0Pr/38OPqAM6ozRL4JybFh+acP+n31/0Hn9cq1sEijbv46DsC0OUgQD4vfd1P8kg
	SbVvyeuAKjzyv09Kt5hLbOdktV3gOJrVrAZhcW400A3Jz5fsXxSnVIXBqT1SKxiCBLDYvN
	J95tLCsHXZx6E15uK5kKx+sDwMwqHraYGL6hyCzIdvEI8FM5fiSvfiSlWm8MrS/AlX5VMU
	r39GzXReYVNEMy/L79YWn6TLG7txepWBmA58lMw7f9y+NlfcLoj6Z0YWfJX8yBWpuNh4dn
	Pb1kBXkJbCr+13D07QdwqxBO4f7GWn0m4bAm6KoAe+YKefoh/NnoG4/Cg/ALXQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1669291367;
	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=hTraNByM9Jl2TcWesBGdVBzd4/NCPuiZndofyIgcbPI=;
	b=vinb94EFNZrsxLJIVtVysgplcy+vG+IuhpTjrZPZP8eG2ZDebOA5jadl71H0djfr0jNMtc
	bNYBQ4YT4ABKbpWkrG6mPxTBFa7HeI3hKJlrBdzSdGtJEwNTiLdBNbEY4HLxDRhPXJNtwS
	XJlvZ5queLTM54sLXDxtLsePH5N06yvFLi5x/zr9sod9PhTeYDBgdlYUXK6PsjUsE+RQL6
	bRKjbip0u1uqtMtfYvnpkU5WLh9GPlhH9nXpzskVFdNihREb0ffJn6yq/nR2+kG5xULyzN
	1tJzYHGATeQ6UFoM5Xcge7vS61Fykap+laS6VoWfviVo1KVYZQVpS3QiigqFBw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669291367; a=rsa-sha256; cv=none;
	b=PV9ikpuoFXHLexkZDYrbLlPgVUYjohFSfTzPJEEjuTiQ9uUXfSMWB12nzG0Kt8sleWAz4c
	cJGzoARolz/zATWO5nABI5J1yTZ97wB6Ev5Cir5bb+nn2KM1M8tyGBy0AyewdErxR+iJQA
	hxIK50btZf6yISIkKES6izuC/4Z7wqXM/0Atcky0+1WKTC6snmaGmyNSvjyB9jFWWxDQ6b
	jGjqXR5qByqu6iCf+C1paerlFX26rJWg6fcbv1ScSKTbcw6fcKdOmV9XUZZjX8tOXYcG4b
	FgXVqAeiuTb7vBelkArEq5iKFYgbM8N8gUMhSAoNJPbAkUhmjgt8Y/IZB0nRUA==
Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171])
	(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 "GTS CA 1D4" (verified OK))
	(Authenticated sender: eduardo)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NHxT349yMzK6K
	for ; Thu, 24 Nov 2022 12:02:47 +0000 (UTC)
	(envelope-from eduardo@freebsd.org)
Received: by mail-vk1-f171.google.com with SMTP id j24so748177vkk.0
        for ; Thu, 24 Nov 2022 04:02:47 -0800 (PST)
X-Gm-Message-State: ANoB5pnNFL55ooZJYE2T6yw4E2O+CY85CyoaLzcutn/VoVYxq+Dfb0mb
	sRZnL9aLQ4H3xtDj2GN/VD4wD6cPjgY80vMERc8=
X-Google-Smtp-Source: AA0mqf7VU1TRmsppZhV0l6QfcUm0XuZENwOs7AIgb9E2GulHKonDMvwsjuCF+aq6iap/AHrA3RWiXO5Ehd2TzyuwqPE=
X-Received: by 2002:ac5:c895:0:b0:3bc:93ab:e6f7 with SMTP id
 n21-20020ac5c895000000b003bc93abe6f7mr6270932vkl.24.1669291366967; Thu, 24
 Nov 2022 04:02:46 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
From: Nuno Teixeira 
Date: Thu, 24 Nov 2022 12:02:35 +0000
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: buildkernel doesn't respect PORTSDIR with PORTS_MODULES
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000f470fe05ee362ebe"
X-ThisMailContainsUnwantedMimeParts: N

--000000000000f470fe05ee362ebe
Content-Type: text/plain; charset="UTF-8"

Hello,

I'm trying PORT_MODULES with make.conf:
---
PORTSDIR=/work/freebsd/ports
DISTDIR=/work/DISTFILES
PORTS_MODULES=graphics/drm-kmod x11/nvidia-driver
---
and `make buildkernel` fails:
---
linking kernel.full
ctfmerge -L VERSION -g -o kernel.full ...
      text      data       bss        dec         hex   filename
  22977071   1848409   4437760   29263240   0x1be8588   kernel.full
cd: /usr/ports/graphics/drm-kmod: No such file or directory
---

Any hint?
Thanks,

-- 
Nuno Teixeira
FreeBSD Committer (ports)

--000000000000f470fe05ee362ebe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

I'm trying PORT_M=
ODULES with make.conf:
---
PORTSDIR=3D/work/freebsd=
/ports
DISTDIR=3D/work/DISTFILES
PORTS_MODULES=3Dgraphics/drm-kmod x1=
1/nvidia-driver
---
and `make buildkernel` fails:
=

---
linking kernel.full
ctfmerge -L VERSION -g -o kernel.=
full ...
=C2=A0 =C2=A0 =C2=A0 text =C2=A0 =C2=A0 =C2=A0data =C2=A0 =C2=
=A0 =C2=A0 bss =C2=A0 =C2=A0 =C2=A0 =C2=A0dec =C2=A0 =C2=A0 =C2=A0 =C2=A0 h=
ex =C2=A0 filename
=C2=A0 22977071 =C2=A0 1848409 =C2=A0 4437760 =C2=A0 =
29263240 =C2=A0 0x1be8588 =C2=A0 kernel.full
cd: /usr/ports/graphics/drm=
-kmod: No such file or directory
---

Any=
 hint?
Thanks,

-- 
Nuno Teixeira
FreeBSD Committer (ports)


--000000000000f470fe05ee362ebe--

From nobody Thu Nov 24 14:05:32 2022
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 4NJ0Bp0DXdz4jG8N
	for ; Thu, 24 Nov 2022 14:05:38 +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 (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NJ0Bm3qnTz4FVC
	for ; Thu, 24 Nov 2022 14:05:36 +0000 (UTC)
	(envelope-from garyj@gmx.de)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmx.de header.s=s31663417 header.b=JekUgwF0;
	spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.15.19 as permitted sender) smtp.mailfrom=garyj@gmx.de;
	dmarc=pass (policy=none) header.from=gmx.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417;
	t=1669298734; bh=nQM9eXC2GqwwClOlyRxSLEiaM2j8MoGA9G6X2drNYek=;
	h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References:
	 Reply-To;
	b=JekUgwF05yrCiE/gd7ZnKz2x8PO8OJj6TJJmNX4dzHmb4Z7e/eEjwDFqIrzZT7Jpd
	 dNBdhdmufQ/+9CTS2CHq6IO4E+zgZ3PRn1mV2U8zr5dE4lpdVO9OvwXCUtbYGYNB1u
	 /GVmk4akGoLczdm/zG1QzXQIFJ1gw4DJiLPWurSCEjyrevlwrOE5pN12XudQ4f3TRe
	 YFDDH/1orGmpRXLJdzpQuIJpv/em0u3dupeeohxALHFly9zasP6g8iVqwL8/l2mkGb
	 Dke+yaSxQLE8X69XJNKDGjHJi49cSsQhCOL1Fsc4Q5jpJl/ho/WO5EN2foeDU/2lWd
	 7ldEzMBC2Sb2w==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from ernst.home ([91.2.49.186]) by mail.gmx.net (mrgmx004
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MhU9Z-1pSIcH2sJn-00eh5m for
 ; Thu, 24 Nov 2022 15:05:34 +0100
Date: Thu, 24 Nov 2022 15:05:32 +0100
From: Gary Jennejohn 
To: freebsd-current@freebsd.org
Subject: Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES
Message-ID: <20221124150532.1a231863@ernst.home>
In-Reply-To: 
References: 
Reply-To: garyj@gmx.de
X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:9/2pAawf2K4S8nbi7fRKWW+KlYK1jnt7jqmAKqbp13pWO0MvvOh
 1jsuYrALtfx3dh3HwVXTg7wxZgoCqSsBz9XltMqZDZaY5woXEMag2am7l5if0n/W8/9TUXF
 Jb3lTy4oMOf7Ntfayn4nkwZle6rCk97xD0th5DSZjg+Z3SPDTkEGBmaIM9BmAZUPXGGvHLJ
 Y+ywMoE4MjNrOHhi3U1IQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:qQEITwM3Gz4=;v1S0O1q7mDGgXWXngzXKsZaXQpD
 F45zEMDxzlyKMxwgs39V+nCj5ZzCwtkjj08FFukTVruAsjxe4r0BYhWOr6Jq+Pb1sqVeXqkJh
 THEU7y1wZlfFXFCZGlnLsRxdl3yfseEODGQxjfyb3cvtcdNYDNj/RUyANdvaX5U+qjWtez6NI
 VkJV8FEMEwf/1bGvOIj6/Uf8NlDZdU9IptkuqohwBQkbOu+ceH7Vj1kZnGlTWDAHYbsvN2r2x
 66WDqkya8N3cCED2UBzfVxChXY2oF8jNuuPxEAQo/QeluAye8jdzMdgBLsFoBgbhBJ03fDq6a
 d39x59K9HEXJe1S99kxeGyPAPyYF5SRnXK6NUieXTJHtfeHX4iTvrtf49RfYIVeEdFiU/ph+7
 DQaDn3XguebpM4JRZNIiy6kAh+WTqxsOIx+YRsAw7yqfJzr9KAyI7f7Zw45fhWeFx85nAFGp6
 ruzfosCOtgm7m8USCRcOnpTTG7W4PpelTysweTdCrzrnnfMc+CrD1ggIgZTvgo1gNSk36Gms2
 zxIWTRwiVZDCFJ9lxVmEbMbTdXDV2L5C/jPe8rX0h7/vCEgDaV2MPAhd7vBSODGAhp5yql1TR
 PkFCrBdj2UG3wGOprMdUwVFb+0gp1eO1LWpPNZoUJ/cIUuDMFgjSLA9hNzUEcCwPiVJTmfmYH
 bq+gWLDNHOspIPIwjqUor4LlVg30Nzv97vE6dXKULRAdRzUGKlsDUTMyXijfWB5IYGXXdRuou
 oOFDLnQOvpUpUx9QcpgGWjLxRCrOziHKGHf+a853UzbCU+1I2AcOGzZuGWIeZpp99Dg9vcHIj
 wnlLBDD2Qqu30pi9FJnhM/4eif6GGbfM/2V2p+Rcxv0Egx3W9sCCQSAkul4Kpipkvx1nM/APn
 DaKDOBDKD0x+2dwJk8kXvukkw4FnB9vKrN//MH61hLywOyEPSJhXaYCWMtBMbGxBGpFYFYjse
 N6RxJQ==
X-Spamd-Result: default: False [-1.69 / 15.00];
	NEURAL_HAM_MEDIUM(-0.96)[-0.960];
	DMARC_POLICY_ALLOW(-0.50)[gmx.de,none];
	NEURAL_SPAM_LONG(0.29)[0.292];
	R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25];
	R_DKIM_ALLOW(-0.20)[gmx.de:s=s31663417];
	RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from];
	MIME_GOOD(-0.10)[text/plain];
	NEURAL_SPAM_SHORT(0.08)[0.079];
	FREEMAIL_REPLYTO(0.00)[gmx.de];
	RCPT_COUNT_ONE(0.00)[1];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	HAS_REPLYTO(0.00)[garyj@gmx.de];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	FREEMAIL_FROM(0.00)[gmx.de];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	TO_DN_NONE(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[gmx.de:+];
	FREEMAIL_ENVFROM(0.00)[gmx.de];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NJ0Bm3qnTz4FVC
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 24 Nov 2022 12:02:35 +0000
Nuno Teixeira  wrote:

> Hello,
>
> I'm trying PORT_MODULES with make.conf:
> ---
> PORTSDIR=3D/work/freebsd/ports
> DISTDIR=3D/work/DISTFILES
> PORTS_MODULES=3Dgraphics/drm-kmod x11/nvidia-driver
> ---
> and `make buildkernel` fails:
> ---
> linking kernel.full
> ctfmerge -L VERSION -g -o kernel.full ...
>       text      data       bss        dec         hex   filename
>   22977071   1848409   4437760   29263240   0x1be8588   kernel.full
> cd: /usr/ports/graphics/drm-kmod: No such file or directory
> ---
>
> Any hint?
> Thanks,
>

bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR.  You could try adding
that to your list.

=2D-
Gary Jennejohn

From nobody Thu Nov 24 14:16:06 2022
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 4NJ0RD4kBXz4jH6p
	for ; Thu, 24 Nov 2022 14:16:24 +0000 (UTC)
	(envelope-from otis@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NJ0RD42jzz4H3n;
	Thu, 24 Nov 2022 14:16:24 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1669299384;
	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=G7AieSTBr4l1QyrKZqgQMC9dL8yfuRUYMP31p8O4Cjc=;
	b=konv8AWdgI1mi2IqzZlfPIxD6m9A1D+ZJ+9Oviyrkio3TdGp7IMEoTf1VN/abtXKYloLOF
	eEpArPr6CaiZ4L0dpSOlwRcX0kkeQ/BqDZbiX2ZmLWW+3NoPmtspMxiwooPFIa+INw77wl
	c1MHBrq9wBCqrmWBTStFKexOBonCRcQ2ZVrI0D7a+TCRFg8padh0uhB5et8wEfz41HjjCo
	58VZ3qA5zwgKOjjAzOfhkCA0jJeyI7SP6R9YD/oCSf4YOxPHylyZfTDD8QzTE2w/ZMCVv+
	aBQt9L9S0YVCB5jCe7Wnsa3boIjBLvO0bjXkGQ7bGSp66L3qkBHwbARmWb2YDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1669299384;
	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=G7AieSTBr4l1QyrKZqgQMC9dL8yfuRUYMP31p8O4Cjc=;
	b=dwGA25ZN4b3+gydO3SecRn6+48/dHuz6js3S9wi2ZnftXF0gtBa6p/amjneANwD6v4g3dF
	//hi8gkszxhiJhC16Y+gxNgHzUE4PQYJAVbTH4YRzNYJL6uOJseMgwmf1t1U5HLKwIlmUm
	AVyWIbbPaa3XHAEURGZn3ksmH4Wb6I5d0Cq5pMB2PXOZ0P1ZBjhJmkRTGWGMg2QSO2F0hx
	k/reI903UeBBCBhPl8Uoeyhj/arJtH9bOnSqEZ83vYOorUWEajDNdiS92N9HwI4OhxSpq9
	9rHp9ZMf04Co4Ye1DqIN289KgiHXH+F2uvfyHwqGp3xZvW64nes0Q7+7PFfs5Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669299384; a=rsa-sha256; cv=none;
	b=kSElZm6xZqaUrSohJt5pbcQFD6AxLAs3lr8LyjFvIc5wqn5CuVshkkXXToaYIwYXxiZitm
	SpRBY4d4HoxtZbsWBl8cEqhVPKljfO0+Q0QFNZckh2dJzNPu0ZBEszcgP94BpTX7meUwhf
	wq+OJ6qLav0zWaLsJ3sZbj4qZSYf/8yuiTgYc15NcXRyAkKRBZ6xC7W5SVCDHdR+t+tcMd
	/JzK4E+Qqrn/ie2lHOk1usbS9GX70xoEj+0oR79SsAxCbMUcVkundoqZ57+CIzqXTuz3K9
	8GaCk81H32M3LC2s4nlqWDCfurB76EJCmFCTYbb9UjCCvSHR7iQ8wKJXOwst3w==
Received: from ns2.wilbury.net (ns2.wilbury.net [92.60.51.55])
	(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 "svc.wilbury.net", Issuer "R3" (verified OK))
	(Authenticated sender: otis)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NJ0RD2J1qzKql;
	Thu, 24 Nov 2022 14:16:24 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
Received: from smtpclient.apple (unknown [217.73.28.193])
	(Authenticated sender: juraj@lutter.sk)
	by svc.wilbury.net (Postfix) with ESMTPSA id D06FF45D167;
	Thu, 24 Nov 2022 15:16:16 +0100 (CET)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES
From: Juraj Lutter 
In-Reply-To: <20221124150532.1a231863@ernst.home>
Date: Thu, 24 Nov 2022 15:16:06 +0100
Cc: freebsd-current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F9E0B41-A7A8-4D81-9777-2AB4FC1F5E8F@FreeBSD.org>
References: 
 <20221124150532.1a231863@ernst.home>
To: garyj@gmx.de
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,MAY_BE_FORGED,
	RCVD_IN_DNSWL_BLOCKED,RDNS_NONE,SPF_HELO_NONE,SPF_SOFTFAIL,
	URIBL_BLOCKED,URIBL_ZEN_BLOCKED_OPENDNS autolearn=no
	autolearn_force=no version=3.4.5
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on ns2.wilbury.net
X-ThisMailContainsUnwantedMimeParts: N



> On 24 Nov 2022, at 15:05, Gary Jennejohn  wrote:
>=20
> On Thu, 24 Nov 2022 12:02:35 +0000
> Nuno Teixeira  wrote:
>=20
>> Hello,
>>=20
>> I'm trying PORT_MODULES with make.conf:
>> ---
>> PORTSDIR=3D/work/freebsd/ports
>> DISTDIR=3D/work/DISTFILES
>> PORTS_MODULES=3Dgraphics/drm-kmod x11/nvidia-driver
>>=20
>=20
> bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR.  You could try =
adding
> that to your list.
>=20

PORTS_MODULES are being built from within kern.post.mk. I=E2=80=99d put =
PORTSDIR into src-env.conf instead of /etc/src.conf, for that purpose.

=E2=80=94
Juraj Lutter
otis@FreeBSD.org


From nobody Thu Nov 24 14:19:47 2022
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 4NJ0WD11Jzz4jHZk
	for ; Thu, 24 Nov 2022 14:19:52 +0000 (UTC)
	(envelope-from otis@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NJ0WD0SXMz4JKk;
	Thu, 24 Nov 2022 14:19:52 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1669299592;
	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=+7lDm1bAgPVtpWXqhsfU61XarKhLBkWjsK6uNZbB+90=;
	b=VL5FPOoQ7bX1GIgyBIlHHxWct19G0uyfgPlJNvP3M3XP157gCQ+qIVmt38B+rzptmV4ou5
	BXtLH/mZjBQs3FrsyMVkY4B+KKaoZAYVOTUhoY9F28B2zrZOk/r44vs6o6PRd2FgknXmdj
	QkxiexkYIRMOes6BU7HMpXqzQ4FAc05gtrFdMEWpgSKN7YU1GQNFFgtbnHuyycfchtKA4F
	GgIxC6YHqoR9Mh9zQtrJ7IMGDbi9D3/jX6Wz3LBn2nGKt9Gsb2pV2NEkc4+/qa0t3f5t2B
	5rh/VAU/O3Gu/RfQFe3LYkG7igsBCEzMKjGE+xFZg7zoPVIEsFIKo+smbgwvWg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1669299592;
	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=+7lDm1bAgPVtpWXqhsfU61XarKhLBkWjsK6uNZbB+90=;
	b=QzumbwjIG4G+1LbXXD18ZwiFrOKX8VJ0+yMKNFkANH3uItP4UDxn5vg1oQ/dFebyONxc8Y
	hoHVWwi4tIo2EgY3BpZrVMTA5Yh0UaxJyaIeooszakiuqxPweIG35/tyB907osC8Zf8RdE
	q4a1topYPtkX8s+oNRqW+fCSkdPQV5Wu5YoKruzZrlIBs25YV0ylOnXc89/JG/ApyMsRYd
	+o2/+EQU+qXRAbUrFrKeFTomS4Co+EjNUVl111JTUItt602VgMHnBY3euIpQsAB7hghQIh
	ndm9AIG+010NF822+/668UcSYqdTdX1ZzA9oataZwh449DSHBRK+TLqlVAQ30w==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669299592; a=rsa-sha256; cv=none;
	b=rIF+nRPCC+llvMHQIu6Zjv5eRfqmDjg03lQFfTQcsbkWfZf8Ol6amwVlTayZmMy1CasX2C
	kDBjkxW14iT4YGo6sTb0dzgt6CfbF+1nLyoMuW4/gW26DeDlmmCHO3n2RAV0cUAvHNn/fI
	DhQl3Jp7gs6R4NWi1Hw2JasXhFbSwjzbrQgg9BLUzb0C6+u+wpfIRpB247OLfgA1Uon4Kl
	2jZmOyb+tLi+IcCauJQGIXChmGrVG9Rfk7UPKa6sjNUm/9dl+MGr32bHFa/acX6fDnAf31
	sUV+KMn1lak4uCdDlDW9WhyfsSCsjaCJymZ8kCYm0gEosryms9IPFhsEZTBNQw==
Received: from ns2.wilbury.net (ns2.wilbury.net [IPv6:2a01:b200:0:1:f816:3eff:fecd:13e6])
	(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 "svc.wilbury.net", Issuer "R3" (verified OK))
	(Authenticated sender: otis)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NJ0WC5nh4zLtg;
	Thu, 24 Nov 2022 14:19:51 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
Received: from smtpclient.apple (unknown [217.73.28.193])
	(Authenticated sender: juraj@lutter.sk)
	by svc.wilbury.net (Postfix) with ESMTPSA id 0755345D167;
	Thu, 24 Nov 2022 15:19:48 +0100 (CET)
Content-Type: text/plain;
	charset=utf-8
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES
From: Juraj Lutter 
In-Reply-To: <1F9E0B41-A7A8-4D81-9777-2AB4FC1F5E8F@FreeBSD.org>
Date: Thu, 24 Nov 2022 15:19:47 +0100
Cc: freebsd-current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <20221124150532.1a231863@ernst.home>
 <1F9E0B41-A7A8-4D81-9777-2AB4FC1F5E8F@FreeBSD.org>
To: garyj@gmx.de
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,MAY_BE_FORGED,
	RCVD_IN_DNSWL_BLOCKED,RDNS_NONE,SPF_HELO_NONE,SPF_SOFTFAIL,
	URIBL_BLOCKED,URIBL_ZEN_BLOCKED_OPENDNS autolearn=no
	autolearn_force=no version=3.4.5
X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on ns2.wilbury.net
X-ThisMailContainsUnwantedMimeParts: N



> On 24 Nov 2022, at 15:16, Juraj Lutter  wrote:
>>=20
>> bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR.  You could try =
adding
>> that to your list.
>>=20
>=20
> PORTS_MODULES are being built from within kern.post.mk. I=E2=80=99d =
put PORTSDIR into src-env.conf instead of /etc/src.conf, for that =
purpose.

Fingers are quicker than the brain: I=E2=80=99d put PORTSDIR into =
/etc/src.conf instead of /etc/make.conf for that purpose.

otis

=E2=80=94
Juraj Lutter
otis@FreeBSD.org


From nobody Thu Nov 24 14:44:20 2022
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 4NJ13X5ZQVz4hLg9
	for ; Thu, 24 Nov 2022 14:44:24 +0000 (UTC)
	(envelope-from yuri@aetern.org)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29])
	(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 4NJ13X3SlFz4Mtw;
	Thu, 24 Nov 2022 14:44:24 +0000 (UTC)
	(envelope-from yuri@aetern.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
	by mailout.nyi.internal (Postfix) with ESMTP id 02B815C0226;
	Thu, 24 Nov 2022 09:44:23 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
  by compute4.internal (MEProxy); Thu, 24 Nov 2022 09:44:23 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc
	:cc:content-transfer-encoding:content-type:date:date:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:sender:subject:subject:to:to; s=fm1; t=1669301062; x=
	1669387462; bh=rCDvtJYKzJ3WiW3lADpECNTxiIkDbpbEgKi79VPRjRU=; b=O
	6TNX7bnnOW7SklBwPAXepjoyiuWvBwCztnjeQqa19ibv6nAsDt44MJFpBHeugJDF
	XKRYpzZr04rcvJ+kHobGuvBpBvR79cHaEwg9pPDGOAxyMEve3HhHlf6+y5kkDC4K
	XGbKuejpoKeqKBVPg9mecyYmu2C3d7ou+ooAOy4CW6URH5qY6+DCIHwMAo6QXwIP
	5G3PgD1h1XP+egSpG4k2LCIHSwU66M5pCBfa+mn7p/xefH4rJG2aYW/IIfDpOdUH
	OCu5nPnYPiecSew8O6bSv7xuz8NRbp3dRynY+DKmm2dPt7dv6L33TFXQH/dXwUFl
	DhGaEVG2aztQqThh+zrBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:date:date:feedback-id:feedback-id:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1669301062; x=
	1669387462; bh=rCDvtJYKzJ3WiW3lADpECNTxiIkDbpbEgKi79VPRjRU=; b=V
	RY12vs4DmgyVls5d9jhh8lGzgYRP3RQSi4ETunFVlgdJYqt6MX67tsdK7PgG6D16
	JSsXZOqXT4E1OUBTJ4spzrZG41lIzjk1Jolxq98lMPU5w3k/hQdlf31opK+uBe3U
	QKtAbX+9ab89XOaaMYNOyQ4JMP1sE7K+HRoKAF6VCXqam69xr991qhJEh8LWWJab
	2QJRo7OPp8/VL/6ezTJTWZyBHFaTLqQjRYpGbrWYxfY1bNAcpvzoa1JONX2z9jDu
	xbOjajGrq6rPf+QRsZe4MqgGzsQV4v1Alg7/2KWjf35OwNO8iNOZVYFG1Mrxqncf
	3Jb7HZOXiZ2SQphoGKdaQ==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrieefgdeikecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtke
    ertddtfeejnecuhfhrohhmpegjuhhrihcuoeihuhhrihesrggvthgvrhhnrdhorhhgqeen
    ucggtffrrghtthgvrhhnpedufeejkeevveevtddvleejhfeftdektdeghefgheeihfduff
    dthedtkeetuedtieenucffohhmrghinhepphhorhhtrdhmkhdpshhusgguihhrrdhmkhen
    ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeihuhhrih
    esrggvthgvrhhnrdhorhhg
X-ME-Proxy: 
    
    
    
Feedback-ID: i0d79475b:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 24 Nov 2022 09:44:22 -0500 (EST)
Message-ID: <0d99e994-4f37-f4b5-22b2-ed4418faa239@aetern.org>
Date: Thu, 24 Nov 2022 15:44:20 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES
Content-Language: en-US
To: Juraj Lutter , garyj@gmx.de
Cc: freebsd-current@freebsd.org
References: 
 <20221124150532.1a231863@ernst.home>
 <1F9E0B41-A7A8-4D81-9777-2AB4FC1F5E8F@FreeBSD.org>
 
From: Yuri 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4NJ13X3SlFz4Mtw
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Juraj Lutter wrote:
> 
> 
>> On 24 Nov 2022, at 15:16, Juraj Lutter  wrote:
>>>
>>> bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR.  You could try adding
>>> that to your list.
>>>
>>
>> PORTS_MODULES are being built from within kern.post.mk. I’d put PORTSDIR into src-env.conf instead of /etc/src.conf, for that purpose.
> 
> Fingers are quicker than the brain: I’d put PORTSDIR into /etc/src.conf instead of /etc/make.conf for that purpose.

Does it work for you?  I have tried putting it in all of the
/etc/src.conf, /etc/src-env.conf, and /etc/make.conf; still /usr/ports
is being used.

Looks like the expansion does not happen properly (for me, at least) in
kern.post.mk and the following seems to help (with PORTSDIR specified in
one of those 3 conf files or in environment):

diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk
index d08dfe30d7d..7b208510483 100644
--- a/sys/conf/kern.post.mk
+++ b/sys/conf/kern.post.mk
@@ -133,7 +133,7 @@ PORTSMODULESENV=\
 all:
 .for __i in ${PORTS_MODULES}
        @${ECHO} "===> Ports module ${__i} (all)"
-       cd $${PORTSDIR:-/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE}
-B clean build
+       cd ${PORTSDIR:U/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE} -B
clean build
 .endfor

 .for __target in install reinstall clean
@@ -141,7 +141,7 @@ ${__target}: ports-${__target}
 ports-${__target}:
 .for __i in ${PORTS_MODULES}
        @${ECHO} "===> Ports module ${__i} (${__target})"
-       cd $${PORTSDIR:-/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE}
-B ${__target:C/(re)?install/deinstall reinstall/}
+       cd ${PORTSDIR:U/usr/ports}/${__i}; ${PORTSMODULESENV} ${MAKE} -B
${__target:C/(re)?install/deinstall reinstall/} .endfor
 .endfor
 .endif

From nobody Thu Nov 24 18:52:56 2022
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 4NJ6ZV5j7wz4hstH
	for ; Thu, 24 Nov 2022 18:53:06 +0000 (UTC)
	(envelope-from joneum@FreeBSD.org)
Received: from toco-domains.de (mail.toco-domains.de [IPv6:2a01:4f8:151:4202::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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NJ6ZT6xT7z3q5n
	for ; Thu, 24 Nov 2022 18:53:05 +0000 (UTC)
	(envelope-from joneum@FreeBSD.org)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=softfail (mx1.freebsd.org: 2a01:4f8:151:4202::3 is neither permitted nor denied by domain of joneum@FreeBSD.org) smtp.mailfrom=joneum@FreeBSD.org;
	dmarc=none
Received: from [192.168.188.77] (p5b24632f.dip0.t-ipconnect.de [91.36.99.47])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by toco-domains.de (Postfix) with ESMTPSA id EEB936BC18
	for ; Thu, 24 Nov 2022 19:52:56 +0100 (CET)
Message-ID: 
Date: Thu, 24 Nov 2022 19:52:56 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.5.0
Content-Language: de-DE
To: FreeBSD Current 
From: Jochen Neumeister 
Subject: Problems with /usr/src/usr.bin/rs/rs.c
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-3.03 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.93)[-0.928];
	MIME_GOOD(-0.10)[text/plain];
	TO_DN_ALL(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE];
	RCVD_TLS_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[joneum];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	TO_DOM_EQ_FROM_DOM(0.00)[]
X-Rspamd-Queue-Id: 4NJ6ZT6xT7z3q5n
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hi,


this is a problem on 2 CURRENT Maschines.

Both stop with this:

cc -target x86_64-unknown-freebsd14.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common
-I/usr/src/lib/libarchive/tests -I/usr/src/lib/libarchive
-I/usr/obj/usr/src/amd64.amd64/lib/libarchive/tests
-I/usr/src/contrib/libarchive/libarchive
-I/usr/src/contrib/libarchive/libarchive/test
-I/usr/src/contrib/libarchive/test_utils -DHAVE_BZLIB_H=1
-DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1  -DHAVE_ZSTD_H=1 -DHAVE_LIBZSTD=1
-DHAVE_LIBZSTD_COMPRESSOR=1
-DPLATFORM_CONFIG_H=\"/usr/src/lib/libarchive/tests/config_freebsd.h\"
-DWITH_OPENSSL -fPIE -g -gz=zlib -MD
-MF.depend.libarchive_test.test_read_format_cpio_svr4_gzip_rpm.o
-MTtest_read_format_cpio_svr4_gzip_rpm.o -std=gnu99
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable
-Wno-error=unused-but-set-variable -Wno-tautological-compare
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
-Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member  -Qunused-arguments  -c
/usr/src/contrib/libarchive/libarchive/test/test_read_format_cpio_svr4_gzip_rpm.c 

-o test_read_format_cpio_svr4_gzip_rpm.o
--- all_subdir_usr.bin ---
--- rs.o ---
cc -target x86_64-unknown-freebsd14.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common
-fPIE -g -gz=zlib -MD  -MF.depend.rs.o -MTrs.o -std=gnu99
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition
-Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Wno-error=unused-but-set-variable  -Qunused-arguments    -c
/usr/src/usr.bin/rs/rs.c -o rs.o
cc: error: no such file or directory: '/usr/src/usr.bin/rs/rs.c'
cc: error: no input files

I delete /usr/obj/usr/src/amd64.amd64/usr.bin/rs and on both Maschines, 
all is fine.


But on both Maschines is Poudriere working, and both maschines stop when 
i will the CURRENT jails updateting

cc: error: no such file or directory: 
'/usr/local/poudriere/jails/14amd64/usr/src/usr.bin/rs/rs.c'

So i see this PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267871

I make a "make cleandir" in 
/usr/local/poudriere/jails/14amd62/usr/src/usr.bin/rs/rs.c - ans all is 
fine.

But when i update the CURRENT i386 jails, they stop again:

cc: error: no such file or directory: 
'/usr/local/poudriere/jails/14i386/usr/src/usr.bin/rs/rs.c'

a "make cleandir" is not helping here.

I this a problem with tihs Update? 
https://cgit.freebsd.org/src/commit/?id=afb4998dd4de03c2d635faf7db89f3d3f6c3a6ff


Greetings
Jochen




From nobody Fri Nov 25 03:11:44 2022
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 4NJKf63BJsz4hdbZ
	for ; Fri, 25 Nov 2022 03:11:58 +0000 (UTC)
	(envelope-from jett@mcgi.org)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NJKf615Xlz4RcH
	for ; Fri, 25 Nov 2022 03:11:58 +0000 (UTC)
	(envelope-from jett@mcgi.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pj1-x102d.google.com with SMTP id ci10so2634982pjb.1
        for ; Thu, 24 Nov 2022 19:11:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=mcgi-org.20210112.gappssmtp.com; s=20210112;
        h=to:in-reply-to:cc:references:message-id:date:subject:mime-version
         :from:content-transfer-encoding:from:to:cc:subject:date:message-id
         :reply-to;
        bh=RxnHERREx6GSNSZsay+y0k7Wpakharn3A8WUOaJEHUU=;
        b=YLapLN7+O7i/qOSs7KQ+ftv/eR+V2HRNcRLS5tnItCwDCYl5FdEGvNqcD4fmLNs0s/
         uMva0fB31eGuCSfIYiSWR3VJO1gQ0r3a82yaUxTOMudaO0Rur24TdUv8do1FzCQTaUxO
         sEBgbGk5lc7W66e4Ia/GBGZmCJbRfrGR9lADSIoLgJhS0yMnl8tpzidk8QdBQOYQNDbP
         z++gtaxUj9MhZDHltgIgIsCb0UfrP3YnnY08KoPG5e/I+o6nvrc1gZsXD8ZiLBTTT8CO
         TE82elUn3MHCN4MA4A7x/Drcf8doXr2BCKS58685lPkgLGskZUKDVOuQuenVP0BELxVe
         i/Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:in-reply-to:cc:references:message-id:date:subject:mime-version
         :from:content-transfer-encoding:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=RxnHERREx6GSNSZsay+y0k7Wpakharn3A8WUOaJEHUU=;
        b=N7imVnHGfTMLbvQjNA8s96CZ5jyDQf04SwRSDeKIW0riAQ2K28dg7rZAcr6fRsYjj7
         6pu/sq6ND+ReHKJxFw90/D0zDeIxkmDajWVUBj+hWHN8jpZH3nFKkYjS9Bgwa3yO5Brf
         ADwY/qb87jSeHdox2TvqXE/PsC6p03O9wdLXVbletL39aadOy2SGE4g407lNekiegowG
         tIpg9vLHOqv5aPsZ8LLyuurbzWiT0v21bwXOBsFgYRjWy+Wei+YDYKMk3BttO8F6JCU4
         GBWhN3nNzAPS3heIBnsLFqxjhY2B9FLWAhETOgrDOT1a8DK7I6KwF0/PjoE7ysulG7Qu
         u+qg==
X-Gm-Message-State: ANoB5plUXEzlW9fo3zeIedAY3cUPQoD+Iu1JppPHq2IbLMjmVvyXU/UB
	LNmocFPXI4ShpdQVOwEvwY3YAQ==
X-Google-Smtp-Source: AA0mqf7b1Krd1fjoJiP9AV+pdHCoBE44/d2PYmYXbyzPds7VfcLOBPxFbqvod2pGBEMZIDiOTV66Tw==
X-Received: by 2002:a17:902:7445:b0:186:b5c8:4c8f with SMTP id e5-20020a170902744500b00186b5c84c8fmr16856503plt.124.1669345916441;
        Thu, 24 Nov 2022 19:11:56 -0800 (PST)
Received: from smtpclient.apple ([122.11.212.222])
        by smtp.gmail.com with ESMTPSA id q16-20020aa79830000000b00561b3ee73f6sm1970427pfl.144.2022.11.24.19.11.55
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 24 Nov 2022 19:11:56 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Jett Tayer 
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 (1.0)
Subject: Re: Problems with /usr/src/usr.bin/rs/rs.c
Date: Fri, 25 Nov 2022 11:11:44 +0800
Message-Id: <9A749EBC-5AAE-4E51-83FD-461296266EF6@mcgi.org>
References: 
Cc: FreeBSD Current 
In-Reply-To: 
To: Jochen Neumeister 
X-Mailer: iPhone Mail (20B101)
X-Rspamd-Queue-Id: 4NJKf615Xlz4RcH
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N



> On Nov 25, 2022, at 2:53 AM, Jochen Neumeister  wrote:=

>=20
> =EF=BB=BFHi,
>=20
>=20
> this is a problem on 2 CURRENT Maschines.
>=20
> Both stop with this:
>=20
> cc -target x86_64-unknown-freebsd14.0
> --sysroot=3D/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common
> -I/usr/src/lib/libarchive/tests -I/usr/src/lib/libarchive
> -I/usr/obj/usr/src/amd64.amd64/lib/libarchive/tests
> -I/usr/src/contrib/libarchive/libarchive
> -I/usr/src/contrib/libarchive/libarchive/test
> -I/usr/src/contrib/libarchive/test_utils -DHAVE_BZLIB_H=3D1
> -DHAVE_LIBLZMA=3D1 -DHAVE_LZMA_H=3D1  -DHAVE_ZSTD_H=3D1 -DHAVE_LIBZSTD=3D1=

> -DHAVE_LIBZSTD_COMPRESSOR=3D1
> -DPLATFORM_CONFIG_H=3D\"/usr/src/lib/libarchive/tests/config_freebsd.h\"
> -DWITH_OPENSSL -fPIE -g -gz=3Dzlib -MD
> -MF.depend.libarchive_test.test_read_format_cpio_svr4_gzip_rpm.o
> -MTtest_read_format_cpio_svr4_gzip_rpm.o -std=3Dgnu99
> -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers
> -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-error=3Dunused-but-set-variable -Wno-tautological-compare
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
> -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member  -Qunused-arguments  -c
> /usr/src/contrib/libarchive/libarchive/test/test_read_format_cpio_svr4_gzi=
p_rpm.c=20
> -o test_read_format_cpio_svr4_gzip_rpm.o
> --- all_subdir_usr.bin ---
> --- rs.o ---
> cc -target x86_64-unknown-freebsd14.0
> --sysroot=3D/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common
> -fPIE -g -gz=3Dzlib -MD  -MF.depend.rs.o -MTrs.o -std=3Dgnu99
> -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers
> -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
> -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition
> -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-error=3Dunused-but-set-variable  -Qunused-arguments    -c
> /usr/src/usr.bin/rs/rs.c -o rs.o
> cc: error: no such file or directory: '/usr/src/usr.bin/rs/rs.c'
> cc: error: no input files
>=20
> I delete /usr/obj/usr/src/amd64.amd64/usr.bin/rs and on both Maschines, al=
l is fine.
>=20
>=20
> But on both Maschines is Poudriere working, and both maschines stop when i=
 will the CURRENT jails updateting
>=20
> cc: error: no such file or directory: '/usr/local/poudriere/jails/14amd64/=
usr/src/usr.bin/rs/rs.c'
>=20
> So i see this PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D2678=
71
>=20
> I make a "make cleandir" in /usr/local/poudriere/jails/14amd62/usr/src/usr=
.bin/rs/rs.c - ans all is fine.
>=20
> But when i update the CURRENT i386 jails, they stop again:
>=20
> cc: error: no such file or directory: '/usr/local/poudriere/jails/14i386/u=
sr/src/usr.bin/rs/rs.c'
>=20
> a "make cleandir" is not helping here.
>=20
> I this a problem with tihs Update? https://cgit.freebsd.org/src/commit/?id=
=3Dafb4998dd4de03c2d635faf7db89f3d3f6c3a6ff
>=20
>=20
> Greetings
> Jochen
>=20
>=20
>=20
>=20

Happened to me as well=E2=80=A6 i just deleted /usr/obj/* and =E2=80=9Cmake b=
uildworld=E2=80=9D worked just fine.


From nobody Fri Nov 25 23:17:46 2022
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 4NJrXc2YYhz4hkBv
	for ; Fri, 25 Nov 2022 23:24:00 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::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-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NJrXb1Jypz3lQ1;
	Fri, 25 Nov 2022 23:23:59 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=BrhbFlu5;
	spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2001:4860:4864:20::32 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-1433ef3b61fso6705864fac.10;
        Fri, 25 Nov 2022 15:23:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=GhqUYDkUfFO/EWpqtr6qDfEOLz0Q9pGWZNExtqPemMc=;
        b=BrhbFlu5hruLmUJlNxIqO48ckbl42JRIjEgcN4O1tJPyalmBjVqsoy3oS54xSqSEC8
         N/taIGBqrJYwksXac/J9YIojQWLXoPcZvKpSUnW/rRWw8Bma5azgT0ZMiit5GjXJJxyw
         oLoQ6QpxHPasG31eg1gh52W3Ok/srYs4J3RP4jIYSAFOVu62RBlhc2RsI30FZO35fwyS
         hr3Y8IwKLBpJBl+jEjOvrumUl+pEzyKMJLsYggwkG3PVuNk19PvVXpfSCkf9aENzR3EB
         gdEzKEACBP/k+/v+mI+oWXfChkKZEWm76yN8nOHMcuxqolZSXgXBy90idqQoaEgHk6lS
         vtjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=GhqUYDkUfFO/EWpqtr6qDfEOLz0Q9pGWZNExtqPemMc=;
        b=mEtbXEnhv0qzpqTXM6xP3MEyAohJ8E5bYRlN0/LonJz30xbSaatW8xKTZZ8JCmBhun
         efoqb561Eqvp+Xx+cap80AaKSJqvNNmT/ejPl5FHFeGfOKFMUc+rgqOQ/tyIay/n0rWZ
         FDndekZF1zQeYpIlkLHKHFWCYNgPq5M6p5HOSkocxdm0jvPJF2QcVv6llDOv155gULMQ
         WtpiFCMNAbiztx/cIUnPWaOy1P3Yb8hCefFXRSLQrzSpIC80OsFvg+MZFCl1dL7VAXMZ
         JpWcxGuHYsvZr9IqfvYxS3jx7NrYoOmxNOsApSPX6FiCSha44s92lcZp3I4+YKacFEv0
         Yrsg==
X-Gm-Message-State: ANoB5pkscsNFa9bT9l7uU+qWKp3fsk0unq27+AjCR3MYhKiJWM9VaW6x
	JJlReTf1qMbBzkEAT1cFmdc5p8F1YNwq2V1c/OZIMpM=
X-Google-Smtp-Source: AA0mqf45CFXsSbFoESV8z5DqxfhYX1+FeItoBnJxEHR+XkYK6/XFg0Ih2QHXGQrWFXncs+vNSoWIedY6oXLEyIq0otY=
X-Received: by 2002:a17:90a:2f23:b0:218:72e0:307b with SMTP id
 s32-20020a17090a2f2300b0021872e0307bmr42646593pjd.183.1669418277131; Fri, 25
 Nov 2022 15:17:57 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
From: Rick Macklem 
Date: Fri, 25 Nov 2022 15:17:46 -0800
Message-ID: 
Subject: RFC: nfsd in a vnet jail
To: freebsd-current@freebsd.org
Cc: bz@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000063da1b05ee53bbd2"
X-Spamd-Result: default: False [-3.37 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.95)[-0.952];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	NEURAL_HAM_SHORT(-0.42)[-0.418];
	R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::32:from];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCPT_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TAGGED_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NJrXb1Jypz3lQ1
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--00000000000063da1b05ee53bbd2
Content-Type: text/plain; charset="UTF-8"

Hi,

bz@ has encouraged me to fiddle with the nfsd
so that it works in a vnet jail.
I have now basically done so, specifically for
NFSv4, since NFSv3 presents various issues.

What I have not yet done is put global variables
in the vnet. This needs to be done so that the nfsd
can be run in multiple jail instances and/or in and
outside of a jail.
The problem is that there are 100s of global variables.

I can see two approaches:
1 - Move them all into the vnet jail. This would imply
    that all the sysctls need to somehow be changed,
    which would seem to be a POLA violation.
    It also implies a lot of stuff in the vnet.
2 - Just move the global variables that will always
    differ from one nfsd to another (this would make
    the sysctls global and apply to all nfsds).
    This will keep the number of globals in the vnet
    smaller.

I am currently leaning towards #2, put what do others
think?

rick
ps: Personally, I don't know what use there is of
    running the nfsd inside a vnet jail, but bz@ has
    some use case.

--00000000000063da1b05ee53bbd2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,
bz@ ha=
s encouraged me to fiddle with the nfsd
so that it works in a vnet jail.
I have now basically=
 done so, specifically for
NFSv4, since NFSv3 presents various issues.

What I have not yet done=
 is put global variables
in the vnet. This needs to be done so that the nfsd
can be run in mu=
ltiple jail instances and/or in and
outside of a jail.
The problem is that there are 100s of =
global variables.

I can see two approaches:
1 - Move them all into the vnet jail. This would impl=
y
=C2=A0 =
=C2=A0 that all the sysctls need to somehow be changed,
=C2=A0 =C2=A0 which would se=
em to be a POLA violation.
=C2=A0 =C2=A0 It also implies a lot of stuff in the vnet.=

2 - Just=
 move the global variables that will always
=C2=A0 =C2=A0 differ from one nfsd to an=
other (this would make
=C2=A0 =C2=A0 the sysctls global and apply to all nfsds).
=C2=A0 =C2=
=A0 This will keep the number of globals in the vnet
=C2=A0 =C2=A0 smaller.

I am currently leanin=
g towards #2, put what do others
think?

rick
ps: Personally, I don't know what use there is of
=C2=A0 =C2=A0 ru=
nning the nfsd inside a vnet jail, but bz@ has
=C2=A0 =C2=A0 some use case.



--00000000000063da1b05ee53bbd2--

From nobody Sat Nov 26 05:06:44 2022
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 4NK08H43pjz4hQ0m
	for ; Sat, 26 Nov 2022 05:06:55 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NK08G3CSzz47mY;
	Sat, 26 Nov 2022 05:06:54 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.45 as permitted sender) smtp.mailfrom=asomers@gmail.com;
	dmarc=none
Received: by mail-ua1-f45.google.com with SMTP id c26so2149304uak.5;
        Fri, 25 Nov 2022 21:06:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Ii/mCjMS7KHcTwlVhwu+p0U9EqM9JaFJIlHyo/fFR+g=;
        b=raN9IfviySbcY6ETxChHGG8k+jMuON8WLYmA2+ntJM8vzHIXcaZg29AjqDC5ttWJko
         MPS0ASGVaoRad29DF10Il9eaAgOEXVKjTrcHZv3VaHlKQlYnZLIo+dbRyg/I/X14atp1
         3ldfUsafVYhst0D3eEDIjfYZnFIoConU4ZeJ7cajNCBqJO1Z4+XC5oYhy55D1tA6w/qA
         VqTL7KRno8c/q3opc0oOlLppXOj7nNN40rBh4a/uM1gMT3p08ooEGHtE01gDX++tJ8Ik
         fb9cVmwXiRzPCT4LKKFn96QNq/6+Nx6mHs9q27qPWyRi3z3P8AeCb01ejd4lugwPzXfh
         j3Eg==
X-Gm-Message-State: ANoB5pmPeDAU1z87rWoJKxda4dTyLw8YvGHs1pnWp95cvDgEcbAI5JQB
	ZkrAsrJFxKKJp8Chxr/EvsUkAnPa6xtYe3WzFCo=
X-Google-Smtp-Source: AA0mqf75uqEOdXGSt3/dW1rx7xsCIO0bZLyY+fNDvvPGX9kHEvP7XiNhxegGP2BcI0zFsGVB+EO1GNbn2q89ZSfoyGw=
X-Received: by 2002:ab0:6994:0:b0:411:502d:7c67 with SMTP id
 t20-20020ab06994000000b00411502d7c67mr24328079uaq.29.1669439212956; Fri, 25
 Nov 2022 21:06:52 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Alan Somers 
Date: Fri, 25 Nov 2022 22:06:44 -0700
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: Rick Macklem 
Cc: FreeBSD CURRENT , "Bjoern A. Zeeb" 
Content-Type: multipart/alternative; boundary="000000000000432f6805ee589b73"
X-Spamd-Result: default: False [0.63 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_SPAM_MEDIUM(0.93)[0.932];
	NEURAL_SPAM_SHORT(0.70)[0.699];
	FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_TO(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.45:from];
	R_DKIM_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.222.45:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[asomers];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TAGGED_RCPT(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NK08G3CSzz47mY
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

--000000000000432f6805ee589b73
Content-Type: text/plain; charset="UTF-8"

On Fri, Nov 25, 2022, 4:24 PM Rick Macklem  wrote:

> Hi,
>
> bz@ has encouraged me to fiddle with the nfsd
> so that it works in a vnet jail.
> I have now basically done so, specifically for
> NFSv4, since NFSv3 presents various issues.
>
> What I have not yet done is put global variables
> in the vnet. This needs to be done so that the nfsd
> can be run in multiple jail instances and/or in and
> outside of a jail.
> The problem is that there are 100s of global variables.
>
> I can see two approaches:
> 1 - Move them all into the vnet jail. This would imply
>     that all the sysctls need to somehow be changed,
>     which would seem to be a POLA violation.
>     It also implies a lot of stuff in the vnet.
> 2 - Just move the global variables that will always
>     differ from one nfsd to another (this would make
>     the sysctls global and apply to all nfsds).
>     This will keep the number of globals in the vnet
>     smaller.
>
> I am currently leaning towards #2, put what do others
> think?
>
> rick
> ps: Personally, I don't know what use there is of
>     running the nfsd inside a vnet jail, but bz@ has
>     some use case.
>

This is super-awesome! Thank you so much! I've got a use case too.  I think
it would be fine to leave most of the settings global,  like max_threads.
But we should probably decide on a case by case basis .

>
>

--000000000000432f6805ee589b73
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Nov 25, 2022, 4:24 PM Rick Macklem <rick.macklem@gmail.com> wrote:
Hi,

bz@ has encouraged me to fiddle with the nf=
sd
so tha=
t it works in a vnet jail.
I have now basically done so, specifically for
NFSv4, since NFSv3 =
presents various issues.

What I have not yet done is put global variables
in the vnet. This needs=
 to be done so that the nfsd
can be run in multiple jail instances and/or in and
outside of a=
 jail.
Th=
e problem is that there are 100s of global variables.

I can see two approaches:
1 - Move them all=
 into the vnet jail. This would imply
=C2=A0 =C2=A0 that all the sysctls need to som=
ehow be changed,
=C2=A0 =C2=A0 which would seem to be a POLA violation.
=C2=A0 =C2=A0 It also=
 implies a lot of stuff in the vnet.
2 - Just move the global variables that will al=
ways
=C2=
=A0 =C2=A0 differ from one nfsd to another (this would make
=C2=A0 =C2=A0 the sysctl=
s global and apply to all nfsds).
=C2=A0 =C2=A0 This will keep the number of globa=
ls in the vnet
=C2=A0 =C2=A0 smaller.

I am currently leaning towards #2, put what do others
=

think?

rick
ps: Personally, I don=
9;t know what use there is of
=C2=A0 =C2=A0 running the nfsd inside a vnet jail, but=
 bz@ has
=
=C2=A0 =C2=A0 some use case.
=

=


This i=
s super-awesome! Thank you so much! I've got a use case too.=C2=A0 I th=
ink it would be fine to leave most of the settings global,=C2=A0 like max_t=
hreads. But we should probably decide on a case by case basis .




--000000000000432f6805ee589b73--

From nobody Sat Nov 26 15:10:58 2022
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 4NKFYD2hbgz4hLHT
	for ; Sat, 26 Nov 2022 15:10:56 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NKFYC0Ty4z3nJT
	for ; Sat, 26 Nov 2022 15:10:55 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="AYjQwAZ/";
	spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::1132 as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-3b48b139b46so65996907b3.12
        for ; Sat, 26 Nov 2022 07:10:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=KMEb8xwC8lBkHw1w1BGp0ssghzMbl/lfGSZ75w5UZaA=;
        b=AYjQwAZ/unq34vUjpBC0B4WHgSVUrEh4ZaGv1DYp/1nPiZhTGk9MN9raAO9oGKvqUi
         VbkZumyUEcyeByFatKcpYIvOaNRS5eRzy/ZGCK3wXPCd3bNkxYEj86gcrjJyeKUEioDO
         j4qieZ9ut80Jhgmpfpg9Lr0L6B6mquikKWm6t7BD/4ht3f2Fw42LfhlJNr3D/FhZzl+U
         cMOjm7070jQNJ8+cS6gudqUkM12lmPx5piIZ64+alieEXKQ8EFUZyViAR6nsvSxsT0Xf
         YA6l+tgt3bRpIHcdpkIDPcp0nsPSJI06U5Ol4uR7qOOTH4TVCWVjIQKQ74vSF3Eq+czh
         upMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=KMEb8xwC8lBkHw1w1BGp0ssghzMbl/lfGSZ75w5UZaA=;
        b=ujiSSVE4mhkYRPWDJ/cHG0dP2OXVOeqyeiOeHI9RLrKC65MwL/EFxX1vkPKA7FMe4A
         TGe8Eyzl9O2QKlD7G2XNsKKoxTnofnJpdBU2UShnSzwSgoEZaed4JYZx0UbVtu682w98
         hNzYMEaTrPytoVqp99jFCn0tSnSl46VDxO7zo3v7Z3xPWYtzzlZwxDkiXzJ1PFef1XQp
         N9lLXlIqeEHFpK+F+qbTpE3C3esP6p89moHHNN0T0kL+n9j4Nw2SOBJBIL3CbNXGTobC
         b3bsX9aVwqjEKXyHL4VwXAD2OucQ5V+u6/szQ3SLd3aKzRQXtLhAgNDidvwGqjNo1us9
         c03w==
X-Gm-Message-State: ANoB5pmmTf9cE7UUHDT78J7/Msyowcd2EDMDxGNjrhWkSiN7FrO2eU5g
	Yc3N9ur3S1utwx4FFZXvgP7inUoFFRE+gddqQzStR878SQg=
X-Google-Smtp-Source: AA0mqf7dNkJQonkzwAfPn+KpwMEhDmGP/Cp1hNXQnWE4VdQvVqQhpUhHsgN32USdKhk1AbsMaJc9XHCc3yroPZOTGTg=
X-Received: by 2002:a05:690c:285:b0:3ab:189e:3465 with SMTP id
 bf5-20020a05690c028500b003ab189e3465mr20668718ywb.343.1669475453432; Sat, 26
 Nov 2022 07:10:53 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
From: Archimedes Gaviola 
Date: Sat, 26 Nov 2022 23:10:58 +0800
Message-ID: 
Subject: ld error (undefined symbol) while compiling sqlite3
To: freebsd-current 
Content-Type: multipart/alternative; boundary="0000000000005cf70e05ee610bad"
X-Spamd-Result: default: False [-2.62 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	NEURAL_SPAM_SHORT(0.38)[0.377];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1132:from];
	RCPT_COUNT_ONE(0.00)[1];
	ARC_NA(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TAGGED_FROM(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NKFYC0Ty4z3nJT
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--0000000000005cf70e05ee610bad
Content-Type: text/plain; charset="UTF-8"

Hi,

For some reason, I am compiling sqlite3 from the /usr/src/contrib/sqlite3
source using
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221027-769b884e2e2-258837. I
created a /usr/src/usr.bin/sqlite3 directory and created a Makefile file
with content referred to the source.

root@generic:/usr/src/usr.bin/sqlite3 # ls -la
total 16
drwxr-xr-x    2 root  wheel   512 Nov 26 12:46 .
drwxr-xr-x  279 root  wheel  5120 Nov 26 12:46 ..
-rw-r--r--    1 root  wheel   295 Nov 26 16:50 Makefile

root@generic:/usr/src/usr.bin/sqlite3 # cat Makefile
# $FreeBSD$

.include 

SQLITE= ${SRCTOP}/contrib/sqlite3
.PATH:  ${SQLITE}

PROG= sqlite3
MK_MAN=no
SRCS= sqlite3.c
INCS= shell.c sqlite3.h

WARNS?= 3
CFLAGS+=        -I${SQLITE} \
                -DSQLITE_THREADSAFE=0 \
                -DSQLITE_OMIT_LOAD_EXTENSION

.include 

With 'make' command invoked, I encountered this error -> ld: error:
undefined symbol: main as referenced to the crt1_c.c:72
(/usr/src/lib/csu/aarch64/crt1_c.c:72) file. See below details for the
actual error.

root@generic:/usr/src/usr.bin/sqlite3 # make
cc  -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3  -DSQLITE_THREADSAFE=1
 -DSQLITE_OMIT_LOAD_EXTENSION   -fPIE -g -gz=zlib -MD  -MF.depend.sqlite3.o
-MTsqlite3.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-error=unused-but-set-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member  -Qunused-arguments    -c
/usr/src/contrib/sqlite3/sqlite3.c -o sqlite3.o
cc -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3 -DSQLITE_THREADSAFE=1
-DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=zlib -std=gnu99
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Wno-error=unused-but-set-variable -Wno-tautological-compare
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
-Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member -Qunused-arguments  -Wl,-zrelro -pie   -o
sqlite3.full sqlite3.o  -L/usr/obj/usr/src/arm64.aarch64/lib/libthr
-lpthread
ld: error: undefined symbol: main
>>> referenced by crt1_c.c:72 (/usr/src/lib/csu/aarch64/crt1_c.c:72)
>>>               /usr/lib/Scrt1.o:(__start)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Stop.
make: stopped in /usr/src/usr.bin/sqlite3

Not sure if I missed something or if something goes wrong with my Makefile
content construction. I basically followed here
https://www.sqlite.org/howtocompile.html and then proved the source to
compile successfully.

root@generic:/usr/src/contrib/sqlite3 # pwd
/usr/src/contrib/sqlite3
root@generic:/usr/src/contrib/sqlite3 # ls -lah
total 11364
drwxr-xr-x   3 root  wheel   1.0K Oct 27 08:06 .
drwxr-xr-x  89 root  wheel   2.0K Nov 26 13:01 ..
-rw-r--r--   1 root  wheel    15K Oct 27 08:06 INSTALL
-rw-r--r--   1 root  wheel   729B Oct 27 08:06 Makefile.am
-rw-r--r--   1 root  wheel   547B Oct 27 08:06 Makefile.fallback
-rw-r--r--   1 root  wheel    37K Oct 27 08:06 Makefile.in
-rw-r--r--   1 root  wheel    28K Oct 27 08:06 Makefile.msc
-rw-r--r--   1 root  wheel   3.5K Oct 27 08:06 README.txt
-rw-r--r--   1 root  wheel   7.1K Oct 27 08:06 Replace.cs
-rw-r--r--   1 root  wheel   365K Oct 27 08:06 aclocal.m4
-rwxr-xr-x   1 root  wheel   7.2K Oct 27 08:06 compile
-rwxr-xr-x   1 root  wheel    48K Oct 27 08:06 config.guess
-rwxr-xr-x   1 root  wheel    35K Oct 27 08:06 config.sub
-rwxr-xr-x   1 root  wheel   485K Oct 27 08:06 configure
-rw-r--r--   1 root  wheel   8.5K Oct 27 08:06 configure.ac
-rwxr-xr-x   1 root  wheel    23K Oct 27 08:06 depcomp
-rwxr-xr-x   1 root  wheel    15K Oct 27 08:06 install-sh
-rwxr-xr-x   1 root  wheel   320K Oct 27 08:06 ltmain.sh
-rwxr-xr-x   1 root  wheel   6.7K Oct 27 08:06 missing
-rw-r--r--   1 root  wheel   717K Oct 27 08:06 shell.c
-rw-r--r--   1 root  wheel   8.7K Oct 27 08:06 sqlite3.1
-rw-r--r--   1 root  wheel   8.2M Oct 27 08:06 sqlite3.c
-rw-r--r--   1 root  wheel   599K Oct 27 08:06 sqlite3.h
-rw-r--r--   1 root  wheel   267B Oct 27 08:06 sqlite3.pc.in
-rw-r--r--   1 root  wheel   1.9K Oct 27 08:06 sqlite3.rc
-rw-r--r--   1 root  wheel    36K Oct 27 08:06 sqlite3ext.h
-rw-r--r--   1 root  wheel    78B Oct 27 08:06 sqlite3rc.h
drwxr-xr-x   6 root  wheel   512B Oct 27 08:06 tea

root@generic:/usr/src/contrib/sqlite3 # cc -DSQLITE_THREADSAFE=0
-DSQLITE_OMIT_LOAD_EXTENSION shell.c sqlite3.c -o sqlite3

So, the above compilation builds the source successfully.

This time I've manually invoked the first compilation command and it works
just fine as seen below.

root@generic:/usr/src/contrib/sqlite3 # cc  -O2 -pipe -fno-common
-I/usr/src/contrib/sqlite3  -DSQLITE_THREADSAFE=0
 -DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=zlib -MD  -MF.depend.sqlite3.o
-MTsqlite3.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-error=unused-but-set-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member  -Qunused-arguments -c
/usr/src/contrib/sqlite3/sqlite3.c -o sqlite3.o

While the second compilation command below breaks having the same
manifested error.

cc -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3 -DSQLITE_THREADSAFE=1
-DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=zlib -std=gnu99
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Wno-error=unused-but-set-variable -Wno-tautological-compare
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
-Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member -Qunused-arguments  -Wl,-zrelro -pie   -o
sqlite3.full sqlite3.o  -L/usr/obj/usr/src/arm64.aarch64/lib/libthr
-lpthread
ld: error: undefined symbol: main
>>> referenced by crt1_c.c:72 (/usr/src/lib/csu/aarch64/crt1_c.c:72)
>>>               /usr/lib/Scrt1.o:(__start)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Stop.
make: stopped in /usr/src/usr.bin/sqlite3

Any idea of this problem? I posted this at freebsd-database ML however, I'm
thinking that the problem might not be related to SQLite3 perspective as I
have compiled the source without any problem at all so, I share it here.

Thanks and best regards,
Archimedes

--0000000000005cf70e05ee610bad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

For some reason, I am co=
mpiling sqlite3 from the /usr/src/contrib/sqlite3 source using FreeBSD-14.0=
-CURRENT-arm64-aarch64-RPI-20221027-769b884e2e2-258837. I created a /usr/sr=
c/usr.bin/sqlite3 directory and created a Makefile file with content referr=
ed to the source.

root@generic:/usr/src/usr.bi=
n/sqlite3 # ls -la
total 16
drwxr-xr-x =C2=A0 =C2=A02 root =C2=A0whee=
l =C2=A0 512 Nov 26 12:46 .
drwxr-xr-x =C2=A0279 root =C2=A0wheel =C2=A0=
5120 Nov 26 12:46 ..
-rw-r--r-- =C2=A0 =C2=A01 root =C2=A0wheel =C2=A0 2=
95 Nov 26 16:50 Makefile

root@generic:/usr/src/usr.bin/sqlite3 # cat=
 Makefile
# $FreeBSD$

.include <src.opts.mk>

SQLITE=3D ${SRCTOP}/contrib/sqlite3
.PATH: =
=C2=A0${SQLITE}

PROG=3D sqlite3
MK_MAN=3Dno
SRCS=3D sqlite3.c<=
br>INCS=3D shell.c sqlite3.h

WARNS?=3D 3
CFLAGS+=3D =C2=A0 =C2=A0=
 =C2=A0 =C2=A0-I${SQLITE} \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 -DSQLITE_THREADSAFE=3D0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 -DSQLITE_OMIT_LOAD_EXTENSION

.include <<=
a href=3D"http://bsd.prog.mk">bsd.prog.mk>

=
With 'make' command invoked, I encountered this error -> ld: err=
or: undefined symbol: main as referenced to the crt1_c.c:72
(/usr/src/li=
b/csu/aarch64/crt1_c.c:72) file. See below details for the actual error.
root@generic:/usr/src/usr.bin/sqlite3 # make
cc =C2=A0-O2 -pipe -fn=
o-common -I/usr/src/contrib/sqlite3 =C2=A0-DSQLITE_THREADSAFE=3D1
=C2=A0=
-DSQLITE_OMIT_LOAD_EXTENSION =C2=A0 -fPIE -g -gz=3Dzlib -MD =C2=A0-MF.depen=
d.sqlite3.o
-MTsqlite3.o -std=3Dgnu99 -Wno-format-zero-length -fstack-pr=
otector-strong
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-un=
used-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith =
-Wno-uninitialized
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-in=
t
-Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable
-Wn=
o-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-=
unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-addr=
ess-of-packed-member =C2=A0-Qunused-arguments =C2=A0 =C2=A0-c
/usr/src/c=
ontrib/sqlite3/sqlite3.c -o sqlite3.o
cc -O2 -pipe -fno-common -I/usr/sr=
c/contrib/sqlite3 -DSQLITE_THREADSAFE=3D1
-DSQLITE_OMIT_LOAD_EXTENSION -=
fPIE -g -gz=3Dzlib -std=3Dgnu99
-Wno-format-zero-length -fstack-protecto=
r-strong -Wsystem-headers -Werror
-Wall -Wno-format-y2k -W -Wno-unused-p=
arameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-u=
ninitialized -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -Wno=
-unused-const-variable
-Wno-error=3Dunused-but-set-variable -Wno-tautolo=
gical-compare
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-fu=
nction
-Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of=
-packed-member -Qunused-arguments =C2=A0-Wl,-zrelro -pie =C2=A0 -o
sqlit=
e3.full sqlite3.o =C2=A0-L/usr/obj/usr/src/arm64.aarch64/lib/libthr
-lpt=
hread
ld: error: undefined symbol: main
>>> referenced by cr=
t1_c.c:72 (/usr/src/lib/csu/aarch64/crt1_c.c:72)
>>> =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/lib/Scrt1.o:(__start)
cc: er=
ror: linker command failed with exit code 1 (use -v to see invocation)
*=
** Error code 1

Stop.
make: stopped in /usr/src/usr.bin/sqlite3
Not sure if I missed something or if something goes wrong with my Mak=
efile
content construction. I basically followed here
https://www.sqlite.org/howtocompile.h=
tml and then proved the source to
compile successfully.
root@generic:/usr/src/contrib/sqlite3 # pwd
/usr/src/contri=
b/sqlite3
root@generic:/usr/src/contrib/sqlite3 # ls -lah
total 11364=

drwxr-xr-x =C2=A0 3 root =C2=A0wheel =C2=A0 1.0K Oct 27 08:06 .
drwx=
r-xr-x =C2=A089 root =C2=A0wheel =C2=A0 2.0K Nov 26 13:01 ..
-rw-r--r-- =
=C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A015K Oct 27 08:06 INSTALL
-rw-r--r=
-- =C2=A0 1 root =C2=A0wheel =C2=A0 729B Oct 27 08:06 Makefile.am
-rw-r-=
-r-- =C2=A0 1 root =C2=A0wheel =C2=A0 547B Oct 27 08:06 Makefile.fallback-rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A037K Oct 27 08:06 Makefi=
le.in
-rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A028K Oct 27 08:06=
 Makefile.msc
-rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 3.5K Oct 27 08=
:06 README.txt
-rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 7.1K Oct 27 0=
8:06 Replace.cs
-rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 365K Oct 27 =
08:06 aclocal.m4
-rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 7.2K Oct 27=
 08:06 compile
-rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A048K Oct=
 27 08:06 config.guess
-rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=
=A035K Oct 27 08:06 config.sub
-rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=
=A0 485K Oct 27 08:06 configure
-rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=
=A0 8.5K Oct 27 08:06 configure.ac
-=
rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A023K Oct 27 08:06 depcomp-rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A015K Oct 27 08:06 instal=
l-sh
-rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 320K Oct 27 08:06 ltmai=
n.sh
-rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 6.7K Oct 27 08:06 missi=
ng
-rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 717K Oct 27 08:06 shell.c=

-rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 8.7K Oct 27 08:06 sqlite3.1=

-rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 8.2M Oct 27 08:06 sqlite3.c=

-rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 599K Oct 27 08:06 sqlite3.h=

-rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 267B Oct 27 08:06 sqlite3.pc.in
-rw-r--r-- =C2=A0 1 root =C2=
=A0wheel =C2=A0 1.9K Oct 27 08:06 sqlite3.rc
-rw-r--r-- =C2=A0 1 root =
=C2=A0wheel =C2=A0 =C2=A036K Oct 27 08:06 sqlite3ext.h
-rw-r--r-- =C2=A0=
 1 root =C2=A0wheel =C2=A0 =C2=A078B Oct 27 08:06 sqlite3rc.h
drwxr-xr-x=
 =C2=A0 6 root =C2=A0wheel =C2=A0 512B Oct 27 08:06 tea

root@generic=
:/usr/src/contrib/sqlite3 # cc -DSQLITE_THREADSAFE=3D0 -DSQLITE_OMIT_LOAD_E=
XTENSION shell.c sqlite3.c -o sqlite3

So, the abov=
e compilation builds the source successfully.

This time I=
've manually invoked the first compilation command and it works just fi=
ne as seen below.

root@generic:/usr/src/contrib/sqlite3 # cc =C2=A0-=
O2 -pipe -fno-common
-I/usr/src/contrib/sqlite3 =C2=A0-DSQLITE_THREADSAF=
E=3D0
=C2=A0-DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=3Dzlib -MD =C2=A0-=
MF.depend.sqlite3.o
-MTsqlite3.o -std=3Dgnu99 -Wno-format-zero-length -f=
stack-protector-strong
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W=
 -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointe=
r-arith -Wno-uninitialized
-Wno-pointer-sign -Wno-empty-body -Wno-string=
-plus-int
-Wno-unused-const-variable -Wno-error=3Dunused-but-set-variabl=
e
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality<=
br>-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-=
Wno-address-of-packed-member =C2=A0-Qunused-arguments -c
/usr/src/contri=
b/sqlite3/sqlite3.c -o sqlite3.o

While the second compilation comman=
d below breaks having the same manifested error.

cc -O2 -pipe -fno-c=
ommon -I/usr/src/contrib/sqlite3 -DSQLITE_THREADSAFE=3D1
-DSQLITE_OMIT_L=
OAD_EXTENSION -fPIE -g -gz=3Dzlib -std=3Dgnu99
-Wno-format-zero-length -=
fstack-protector-strong -Wsystem-headers -Werror
-Wall -Wno-format-y2k -=
W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpoint=
er-arith -Wno-uninitialized -Wno-pointer-sign
-Wno-empty-body -Wno-strin=
g-plus-int -Wno-unused-const-variable
-Wno-error=3Dunused-but-set-variab=
le -Wno-tautological-compare
-Wno-unused-value -Wno-parentheses-equality=
 -Wno-unused-function
-Wno-enum-conversion -Wno-unused-local-typedef
=
-Wno-address-of-packed-member -Qunused-arguments =C2=A0-Wl,-zrelro -pie =C2=
=A0 -o
sqlite3.full sqlite3.o =C2=A0-L/usr/obj/usr/src/arm64.aarch64/lib=
/libthr
-lpthread
ld: error: undefined symbol: main
>>> r=
eferenced by crt1_c.c:72 (/usr/src/lib/csu/aarch64/crt1_c.c:72)
>>=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/lib/Scrt1.o:(__s=
tart)
cc: error: linker command failed with exit code 1 (use -v to see i=
nvocation)
*** Error code 1

Stop.
make: stopped in /usr/src/us=
r.bin/sqlite3

Any idea of this problem? I posted t=
his at freebsd-database ML however, I'm thinking that the problem might=
 not be related to SQLite3 perspective as I have compiled the source withou=
t any problem at all so, I share it here.

Than=
ks and best regards,
Archimedes 







--0000000000005cf70e05ee610bad--

From nobody Sat Nov 26 15:53:36 2022
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 4NKGVZ1GJVz4hQjx
	for ; Sat, 26 Nov 2022 15:53:42 +0000 (UTC)
	(envelope-from yuri@aetern.org)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28])
	(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 4NKGVY4WgKz3rGX
	for ; Sat, 26 Nov 2022 15:53:41 +0000 (UTC)
	(envelope-from yuri@aetern.org)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=aetern.org header.s=fm1 header.b="h oEzcDd";
	dkim=pass header.d=messagingengine.com header.s=fm1 header.b=l9D488V0;
	spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 66.111.4.28 as permitted sender) smtp.mailfrom=yuri@aetern.org
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
	by mailout.nyi.internal (Postfix) with ESMTP id BAC3F5C00DD;
	Sat, 26 Nov 2022 10:53:40 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
  by compute1.internal (MEProxy); Sat, 26 Nov 2022 10:53:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc
	:content-transfer-encoding:content-type:date:date:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:sender:subject:subject:to:to; s=fm1; t=1669478020; x=
	1669564420; bh=gy7SSOFLvUqisXcxcxHl/2tebO5PODcc4VDRpW+9hio=; b=h
	oEzcDdhVyILkP4NpG0Lu1pOpyXBmyopFrV2iNfFIU5stW5ltvVR5StSj4hyDULcj
	7DoPNWbtDhKjK9Dw2kFq7lrPqEnaUUvSsFSkma8uJhyrQf53lHOqqpf/Pr27Hik4
	H300wpZ5JvoPsyFbxMM643XB605CU5nARThVtK6dfRTeHPlCwG69c98lJDEwRj7l
	meBt+rjRCx42wmo2iuRduGde1KHP16d5ThQOeu+AdJlW3lG+brc90HGt8gLDPp3/
	VkWN+ip8/nbNVdC6yQ6x3CW0gyDCZROEfjO8w75vjcZQQu22K8zBSPTpQuTgwEhq
	ghNZVtW0zQjVFgLQauStg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-transfer-encoding:content-type
	:date:date:feedback-id:feedback-id:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:sender
	:subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm1; t=1669478020; x=1669564420; bh=g
	y7SSOFLvUqisXcxcxHl/2tebO5PODcc4VDRpW+9hio=; b=l9D488V0gYURurdeS
	eOC3Rf304GrAcqhW9g2qQig0aa1ffgP4/1biCK0Yg14U0kKM7gUezI7bg3aRAt1+
	kVMhCMX1vjjnbvLYejLJpio+gzubZaIU2l0WRdJ41yTbtIzB5lTCwsXNFvNIvpdQ
	LRlbtVBcqJ0m/ONxHu7/DoG5zx5NcakXf782v/9CzxoviP9jBBDEeuIP6qcsJNVb
	wIr++BtQvqUEYCbPCBFU8ZaJgcIDaf3y9GSpKk6eCopDlVeoMtqCfuHyByLvArtu
	kMtVpzXKMHHIUGKBqZ6+POO8R+vhg8py4feYeGxQSvY1jxnWB+qdd7QHVHtgtq8T
	0IFOg==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrieejgdekgecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
    fjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpegjuhhrihcu
    oeihuhhrihesrggvthgvrhhnrdhorhhgqeenucggtffrrghtthgvrhhnpefhfeekueduff
    ehvdejueetueffjeduiedtueehlefffeelkeefgeehkedufeeileenucffohhmrghinhep
    ohhpthhsrdhmkhdpphhrohhgrdhmkhdpshhqlhhithgvrdhorhhgpdgtohhnfhhighhurh
    gvrdgrtgdpphgtrdhinhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr
    ihhlfhhrohhmpeihuhhrihesrggvthgvrhhnrdhorhhg
X-ME-Proxy: 
    
    
    
Feedback-ID: i0d79475b:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
 26 Nov 2022 10:53:39 -0500 (EST)
Message-ID: <33b789dd-d501-e57b-0817-a8f533f337a5@aetern.org>
Date: Sat, 26 Nov 2022 16:53:36 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: ld error (undefined symbol) while compiling sqlite3
To: Archimedes Gaviola ,
 freebsd-current 
References: 
Content-Language: en-US
From: Yuri 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4NKGVY4WgKz3rGX
X-Spamd-Bar: /
X-Spamd-Result: default: False [-0.40 / 15.00];
	R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28];
	R_DKIM_ALLOW(-0.20)[aetern.org:s=fm1,messagingengine.com:s=fm1];
	TAGGED_RCPT(0.00)[];
	local_wl_from(0.00)[yuri@aetern.org];
	DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_from
X-ThisMailContainsUnwantedMimeParts: N

Archimedes Gaviola wrote:
> Hi,
> 
> For some reason, I am compiling sqlite3 from the
> /usr/src/contrib/sqlite3 source using
> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221027-769b884e2e2-258837. I
> created a /usr/src/usr.bin/sqlite3 directory and created a Makefile file
> with content referred to the source.
> 
> root@generic:/usr/src/usr.bin/sqlite3 # ls -la
> total 16
> drwxr-xr-x    2 root  wheel   512 Nov 26 12:46 .
> drwxr-xr-x  279 root  wheel  5120 Nov 26 12:46 ..
> -rw-r--r--    1 root  wheel   295 Nov 26 16:50 Makefile
> 
> root@generic:/usr/src/usr.bin/sqlite3 # cat Makefile
> # $FreeBSD$
> 
> .include 
> 
> SQLITE= ${SRCTOP}/contrib/sqlite3
> .PATH:  ${SQLITE}
> 
> PROG= sqlite3
> MK_MAN=no
> SRCS= sqlite3.c

SRCS= shell.c sqlite3.c

> INCS= shell.c sqlite3.h

Remove?

> 
> WARNS?= 3

WARNS?=	2 worked for me.

> CFLAGS+=        -I${SQLITE} \
>                 -DSQLITE_THREADSAFE=0 \
>                 -DSQLITE_OMIT_LOAD_EXTENSION
> 
> .include 
> 
> With 'make' command invoked, I encountered this error -> ld: error:
> undefined symbol: main as referenced to the crt1_c.c:72
> (/usr/src/lib/csu/aarch64/crt1_c.c:72) file. See below details for the
> actual error.
> 
> root@generic:/usr/src/usr.bin/sqlite3 # make
> cc  -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3  -DSQLITE_THREADSAFE=1
>  -DSQLITE_OMIT_LOAD_EXTENSION   -fPIE -g -gz=zlib -MD  -MF.depend.sqlite3.o
> -MTsqlite3.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-error=unused-but-set-variable
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member  -Qunused-arguments    -c
> /usr/src/contrib/sqlite3/sqlite3.c -o sqlite3.o
> cc -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3 -DSQLITE_THREADSAFE=1
> -DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=zlib -std=gnu99
> -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror
> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-error=unused-but-set-variable -Wno-tautological-compare
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
> -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member -Qunused-arguments  -Wl,-zrelro -pie   -o
> sqlite3.full sqlite3.o  -L/usr/obj/usr/src/arm64.aarch64/lib/libthr
> -lpthread
> ld: error: undefined symbol: main
>>>> referenced by crt1_c.c:72 (/usr/src/lib/csu/aarch64/crt1_c.c:72)
>>>>               /usr/lib/Scrt1.o:(__start)
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src/usr.bin/sqlite3
> 
> Not sure if I missed something or if something goes wrong with my Makefile
> content construction. I basically followed here
> https://www.sqlite.org/howtocompile.html
>  and then proved the source to
> compile successfully.
> 
> root@generic:/usr/src/contrib/sqlite3 # pwd
> /usr/src/contrib/sqlite3
> root@generic:/usr/src/contrib/sqlite3 # ls -lah
> total 11364
> drwxr-xr-x   3 root  wheel   1.0K Oct 27 08:06 .
> drwxr-xr-x  89 root  wheel   2.0K Nov 26 13:01 ..
> -rw-r--r--   1 root  wheel    15K Oct 27 08:06 INSTALL
> -rw-r--r--   1 root  wheel   729B Oct 27 08:06 Makefile.am
> -rw-r--r--   1 root  wheel   547B Oct 27 08:06 Makefile.fallback
> -rw-r--r--   1 root  wheel    37K Oct 27 08:06 Makefile.in
> -rw-r--r--   1 root  wheel    28K Oct 27 08:06 Makefile.msc
> -rw-r--r--   1 root  wheel   3.5K Oct 27 08:06 README.txt
> -rw-r--r--   1 root  wheel   7.1K Oct 27 08:06 Replace.cs
> -rw-r--r--   1 root  wheel   365K Oct 27 08:06 aclocal.m4
> -rwxr-xr-x   1 root  wheel   7.2K Oct 27 08:06 compile
> -rwxr-xr-x   1 root  wheel    48K Oct 27 08:06 config.guess
> -rwxr-xr-x   1 root  wheel    35K Oct 27 08:06 config.sub
> -rwxr-xr-x   1 root  wheel   485K Oct 27 08:06 configure
> -rw-r--r--   1 root  wheel   8.5K Oct 27 08:06 configure.ac
> 
> -rwxr-xr-x   1 root  wheel    23K Oct 27 08:06 depcomp
> -rwxr-xr-x   1 root  wheel    15K Oct 27 08:06 install-sh
> -rwxr-xr-x   1 root  wheel   320K Oct 27 08:06 ltmain.sh
> -rwxr-xr-x   1 root  wheel   6.7K Oct 27 08:06 missing
> -rw-r--r--   1 root  wheel   717K Oct 27 08:06 shell.c
> -rw-r--r--   1 root  wheel   8.7K Oct 27 08:06 sqlite3.1
> -rw-r--r--   1 root  wheel   8.2M Oct 27 08:06 sqlite3.c
> -rw-r--r--   1 root  wheel   599K Oct 27 08:06 sqlite3.h
> -rw-r--r--   1 root  wheel   267B Oct 27 08:06 sqlite3.pc.in
> 
> -rw-r--r--   1 root  wheel   1.9K Oct 27 08:06 sqlite3.rc
> -rw-r--r--   1 root  wheel    36K Oct 27 08:06 sqlite3ext.h
> -rw-r--r--   1 root  wheel    78B Oct 27 08:06 sqlite3rc.h
> drwxr-xr-x   6 root  wheel   512B Oct 27 08:06 tea
> 
> root@generic:/usr/src/contrib/sqlite3 # cc -DSQLITE_THREADSAFE=0
> -DSQLITE_OMIT_LOAD_EXTENSION shell.c sqlite3.c -o sqlite3
> 
> So, the above compilation builds the source successfully.
> 
> This time I've manually invoked the first compilation command and it
> works just fine as seen below.
> 
> root@generic:/usr/src/contrib/sqlite3 # cc  -O2 -pipe -fno-common
> -I/usr/src/contrib/sqlite3  -DSQLITE_THREADSAFE=0
>  -DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=zlib -MD  -MF.depend.sqlite3.o
> -MTsqlite3.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-error=unused-but-set-variable
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member  -Qunused-arguments -c
> /usr/src/contrib/sqlite3/sqlite3.c -o sqlite3.o
> 
> While the second compilation command below breaks having the same
> manifested error.
> 
> cc -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3 -DSQLITE_THREADSAFE=1
> -DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=zlib -std=gnu99
> -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror
> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-error=unused-but-set-variable -Wno-tautological-compare
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
> -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member -Qunused-arguments  -Wl,-zrelro -pie   -o
> sqlite3.full sqlite3.o  -L/usr/obj/usr/src/arm64.aarch64/lib/libthr
> -lpthread
> ld: error: undefined symbol: main
>>>> referenced by crt1_c.c:72 (/usr/src/lib/csu/aarch64/crt1_c.c:72)
>>>>               /usr/lib/Scrt1.o:(__start)
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src/usr.bin/sqlite3
> 
> Any idea of this problem? I posted this at freebsd-database ML however,
> I'm thinking that the problem might not be related to SQLite3
> perspective as I have compiled the source without any problem at all so,
> I share it here.
> 
> Thanks and best regards,
> Archimedes
> 
> 
> 
> 
> 
> 


From nobody Sat Nov 26 16:20:43 2022
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 4NKHFk5sm1z4hW7G
	for ; Sat, 26 Nov 2022 16:27:38 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NKHFk3lpQz40L1
	for ; Sat, 26 Nov 2022 16:27:38 +0000 (UTC)
	(envelope-from archimedes.gaviola@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ua1-x936.google.com with SMTP id 97so2496141uam.0
        for ; Sat, 26 Nov 2022 08:27:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=6tH1JngrO9ti+QPKE6klE74+QSOxgnordVh01NDEEQg=;
        b=QdCsXAOGbNPKnYZ7WsxW79+xqAJ/0rcs2LhH6OMbO48j+Wn76zSlFSZ7RdrQsC9TpF
         GXJx/xsXW9f/hBzzpuNdMQ0IstCjHLOQRwK0gltc6YlVWIoAfCRDT9oFRGzDElv7XEGr
         AvnBkITPK63JBrG0i0zevOakJmzXBwh1kOwObf7feiUgbW2zrFIerYS+rWRbcEiG3VCr
         JFuq5cN4To2elifCI5mHBc/ZheZ5ovtsOiAP42sDv2JTqJ4dR+WNUBu808yiHr5StQp9
         DR+uFCXQIZOCQjgW9OtGFHieogfyxealrLdCpdUDKrnCLS7Fv4k9b5BKWhtrmjFSsFCj
         9e7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=6tH1JngrO9ti+QPKE6klE74+QSOxgnordVh01NDEEQg=;
        b=5f+pp74l4KoXJaqcM+x1lSmitGbgVx2tbhVAAEPVB/k2+NbuX2SKBaJu6g1CTR39fG
         2c657Qmw0Jg1nyzNWhD1B0ew2HFkCDvTWxx6xTcE/8hvlGDvHH8dBozDCcdf/gvEu2Eq
         BbL4PnaDNOlhYZ1EwVMhhZAfZJoILO4FoEI0OqCDHZ0agsTEXzfst66B7mXmptpPAU6n
         brZVdBwH0Fz6i5sjj0ctktXa9dIJkYNNyUkniq5lhxpkzwJCMxMFlJE8UWB7sWv5S1v5
         B606bS02lT5fy5UR1cXM4fSEc9sCgF5y90dRJtO4vJ4BBm3hqJoQgupIkQA7Pl7pkn7W
         +xkw==
X-Gm-Message-State: ANoB5pmb4Dlo9ZEYNZOUXKNjlZgVksXOMyYl7aR/0ADBsmqIW12LSKjh
	syQJ7c5vrf6QRc65jfb8UXNCzYMt2TYM4RpNpNv8iFn1
X-Google-Smtp-Source: AA0mqf5gMvMKcff6Eako0OA4S3ve2iUSL9FH5lh/w4iXdJVkmUftUzfUasny1Uj0e1caH+K3QHK1B3Ui9MsXNtOqxe0=
X-Received: by 2002:a5b:54f:0:b0:6e5:92af:572e with SMTP id
 r15-20020a5b054f000000b006e592af572emr39101129ybp.227.1669479638162; Sat, 26
 Nov 2022 08:20:38 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 <33b789dd-d501-e57b-0817-a8f533f337a5@aetern.org>
In-Reply-To: <33b789dd-d501-e57b-0817-a8f533f337a5@aetern.org>
From: Archimedes Gaviola 
Date: Sun, 27 Nov 2022 00:20:43 +0800
Message-ID: 
Subject: Re: ld error (undefined symbol) while compiling sqlite3
To: Yuri 
Cc: freebsd-current 
Content-Type: multipart/alternative; boundary="000000000000cae18805ee6204b7"
X-Rspamd-Queue-Id: 4NKHFk3lpQz40L1
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000cae18805ee6204b7
Content-Type: text/plain; charset="UTF-8"

On Sat, Nov 26, 2022 at 11:53 PM Yuri  wrote:

> Archimedes Gaviola wrote:
> > Hi,
> >
> > For some reason, I am compiling sqlite3 from the
> > /usr/src/contrib/sqlite3 source using
> > FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221027-769b884e2e2-258837. I
> > created a /usr/src/usr.bin/sqlite3 directory and created a Makefile file
> > with content referred to the source.
> >
> > root@generic:/usr/src/usr.bin/sqlite3 # ls -la
> > total 16
> > drwxr-xr-x    2 root  wheel   512 Nov 26 12:46 .
> > drwxr-xr-x  279 root  wheel  5120 Nov 26 12:46 ..
> > -rw-r--r--    1 root  wheel   295 Nov 26 16:50 Makefile
> >
> > root@generic:/usr/src/usr.bin/sqlite3 # cat Makefile
> > # $FreeBSD$
> >
> > .include 
> >
> > SQLITE= ${SRCTOP}/contrib/sqlite3
> > .PATH:  ${SQLITE}
> >
> > PROG= sqlite3
> > MK_MAN=no
> > SRCS= sqlite3.c
>
> SRCS= shell.c sqlite3.c
>
> > INCS= shell.c sqlite3.h
>
> Remove?
>
> >
> > WARNS?= 3
>
> WARNS?= 2 worked for me.
>

Awesome! It works now. Thanks a lot for figuring-out Yuri!


>
> > CFLAGS+=        -I${SQLITE} \
> >                 -DSQLITE_THREADSAFE=0 \
> >                 -DSQLITE_OMIT_LOAD_EXTENSION
> >
> > .include 
> >
> > With 'make' command invoked, I encountered this error -> ld: error:
> > undefined symbol: main as referenced to the crt1_c.c:72
> > (/usr/src/lib/csu/aarch64/crt1_c.c:72) file. See below details for the
> > actual error.
> >
> > root@generic:/usr/src/usr.bin/sqlite3 # make
> > cc  -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3
>  -DSQLITE_THREADSAFE=1
> >  -DSQLITE_OMIT_LOAD_EXTENSION   -fPIE -g -gz=zlib -MD
>  -MF.depend.sqlite3.o
> > -MTsqlite3.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong
> > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
> > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Wno-uninitialized
> > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> > -Wno-unused-const-variable -Wno-error=unused-but-set-variable
> > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> > -Wno-address-of-packed-member  -Qunused-arguments    -c
> > /usr/src/contrib/sqlite3/sqlite3.c -o sqlite3.o
> > cc -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3 -DSQLITE_THREADSAFE=1
> > -DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=zlib -std=gnu99
> > -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror
> > -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign
> > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> > -Wno-error=unused-but-set-variable -Wno-tautological-compare
> > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
> > -Wno-enum-conversion -Wno-unused-local-typedef
> > -Wno-address-of-packed-member -Qunused-arguments  -Wl,-zrelro -pie   -o
> > sqlite3.full sqlite3.o  -L/usr/obj/usr/src/arm64.aarch64/lib/libthr
> > -lpthread
> > ld: error: undefined symbol: main
> >>>> referenced by crt1_c.c:72 (/usr/src/lib/csu/aarch64/crt1_c.c:72)
> >>>>               /usr/lib/Scrt1.o:(__start)
> > cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> > *** Error code 1
> >
> > Stop.
> > make: stopped in /usr/src/usr.bin/sqlite3
> >
> > Not sure if I missed something or if something goes wrong with my
> Makefile
> > content construction. I basically followed here
> > https://www.sqlite.org/howtocompile.html
> >  and then proved the source to
> > compile successfully.
> >
> > root@generic:/usr/src/contrib/sqlite3 # pwd
> > /usr/src/contrib/sqlite3
> > root@generic:/usr/src/contrib/sqlite3 # ls -lah
> > total 11364
> > drwxr-xr-x   3 root  wheel   1.0K Oct 27 08:06 .
> > drwxr-xr-x  89 root  wheel   2.0K Nov 26 13:01 ..
> > -rw-r--r--   1 root  wheel    15K Oct 27 08:06 INSTALL
> > -rw-r--r--   1 root  wheel   729B Oct 27 08:06 Makefile.am
> > -rw-r--r--   1 root  wheel   547B Oct 27 08:06 Makefile.fallback
> > -rw-r--r--   1 root  wheel    37K Oct 27 08:06 Makefile.in
> > -rw-r--r--   1 root  wheel    28K Oct 27 08:06 Makefile.msc
> > -rw-r--r--   1 root  wheel   3.5K Oct 27 08:06 README.txt
> > -rw-r--r--   1 root  wheel   7.1K Oct 27 08:06 Replace.cs
> > -rw-r--r--   1 root  wheel   365K Oct 27 08:06 aclocal.m4
> > -rwxr-xr-x   1 root  wheel   7.2K Oct 27 08:06 compile
> > -rwxr-xr-x   1 root  wheel    48K Oct 27 08:06 config.guess
> > -rwxr-xr-x   1 root  wheel    35K Oct 27 08:06 config.sub
> > -rwxr-xr-x   1 root  wheel   485K Oct 27 08:06 configure
> > -rw-r--r--   1 root  wheel   8.5K Oct 27 08:06 configure.ac
> > 
> > -rwxr-xr-x   1 root  wheel    23K Oct 27 08:06 depcomp
> > -rwxr-xr-x   1 root  wheel    15K Oct 27 08:06 install-sh
> > -rwxr-xr-x   1 root  wheel   320K Oct 27 08:06 ltmain.sh
> > -rwxr-xr-x   1 root  wheel   6.7K Oct 27 08:06 missing
> > -rw-r--r--   1 root  wheel   717K Oct 27 08:06 shell.c
> > -rw-r--r--   1 root  wheel   8.7K Oct 27 08:06 sqlite3.1
> > -rw-r--r--   1 root  wheel   8.2M Oct 27 08:06 sqlite3.c
> > -rw-r--r--   1 root  wheel   599K Oct 27 08:06 sqlite3.h
> > -rw-r--r--   1 root  wheel   267B Oct 27 08:06 sqlite3.pc.in
> > 
> > -rw-r--r--   1 root  wheel   1.9K Oct 27 08:06 sqlite3.rc
> > -rw-r--r--   1 root  wheel    36K Oct 27 08:06 sqlite3ext.h
> > -rw-r--r--   1 root  wheel    78B Oct 27 08:06 sqlite3rc.h
> > drwxr-xr-x   6 root  wheel   512B Oct 27 08:06 tea
> >
> > root@generic:/usr/src/contrib/sqlite3 # cc -DSQLITE_THREADSAFE=0
> > -DSQLITE_OMIT_LOAD_EXTENSION shell.c sqlite3.c -o sqlite3
> >
> > So, the above compilation builds the source successfully.
> >
> > This time I've manually invoked the first compilation command and it
> > works just fine as seen below.
> >
> > root@generic:/usr/src/contrib/sqlite3 # cc  -O2 -pipe -fno-common
> > -I/usr/src/contrib/sqlite3  -DSQLITE_THREADSAFE=0
> >  -DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=zlib -MD  -MF.depend.sqlite3.o
> > -MTsqlite3.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong
> > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
> > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Wno-uninitialized
> > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> > -Wno-unused-const-variable -Wno-error=unused-but-set-variable
> > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> > -Wno-address-of-packed-member  -Qunused-arguments -c
> > /usr/src/contrib/sqlite3/sqlite3.c -o sqlite3.o
> >
> > While the second compilation command below breaks having the same
> > manifested error.
> >
> > cc -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3 -DSQLITE_THREADSAFE=1
> > -DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=zlib -std=gnu99
> > -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror
> > -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign
> > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> > -Wno-error=unused-but-set-variable -Wno-tautological-compare
> > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
> > -Wno-enum-conversion -Wno-unused-local-typedef
> > -Wno-address-of-packed-member -Qunused-arguments  -Wl,-zrelro -pie   -o
> > sqlite3.full sqlite3.o  -L/usr/obj/usr/src/arm64.aarch64/lib/libthr
> > -lpthread
> > ld: error: undefined symbol: main
> >>>> referenced by crt1_c.c:72 (/usr/src/lib/csu/aarch64/crt1_c.c:72)
> >>>>               /usr/lib/Scrt1.o:(__start)
> > cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> > *** Error code 1
> >
> > Stop.
> > make: stopped in /usr/src/usr.bin/sqlite3
> >
> > Any idea of this problem? I posted this at freebsd-database ML however,
> > I'm thinking that the problem might not be related to SQLite3
> > perspective as I have compiled the source without any problem at all so,
> > I share it here.
> >
> > Thanks and best regards,
> > Archimedes
> >
> >
> >
> >
> >
> >
>
>

--000000000000cae18805ee6204b7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Nov 26, 2022 at 11:53 PM Yuri=
 <yuri@aetern.org> wrote:
<=
/div>
Archimedes Gaviola w=
rote:

> Hi,

> 

> For some reason, I am compiling sqlite3 from the

> /usr/src/contrib/sqlite3 source using

> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20221027-769b884e2e2-258837. I<=
br>
> created a /usr/src/usr.bin/sqlite3 directory and created a Makefile fi=
le

> with content referred to the source.

> 

> root@generic:/usr/src/usr.bin/sqlite3 # ls -la

> total 16

> drwxr-xr-x =C2=A0 =C2=A02 root =C2=A0wheel =C2=A0 512 Nov 26 12:46 .
> drwxr-xr-x =C2=A0279 root =C2=A0wheel =C2=A05120 Nov 26 12:46 ..

> -rw-r--r-- =C2=A0 =C2=A01 root =C2=A0wheel =C2=A0 295 Nov 26 16:50 Mak=
efile

> 

> root@generic:/usr/src/usr.bin/sqlite3 # cat Makefile

> # $FreeBSD$

> 

> .include <src.opts.mk>

> 

> SQLITE=3D ${SRCTOP}/contrib/sqlite3

> .PATH: =C2=A0${SQLITE}

> 

> PROG=3D sqlite3

> MK_MAN=3Dno

> SRCS=3D sqlite3.c



SRCS=3D shell.c sqlite3.c



> INCS=3D shell.c sqlite3.h



Remove?



> 

> WARNS?=3D 3



WARNS?=3D 2 worked for me.

Awesome! It =
works now. Thanks a lot for figuring-out Yuri!
=C2=A0



> CFLAGS+=3D =C2=A0 =C2=A0 =C2=A0 =C2=A0-I${SQLITE} \

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -DSQLITE_THREA=
DSAFE=3D0 \

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -DSQLITE_OMIT_=
LOAD_EXTENSION

> 

> .include <bsd.prog.mk>

> 

> With 'make' command invoked, I encountered this error -> ld=
: error:

> undefined symbol: main as referenced to the crt1_c.c:72

> (/usr/src/lib/csu/aarch64/crt1_c.c:72) file. See below details for the=


> actual error.

> 

> root@generic:/usr/src/usr.bin/sqlite3 # make

> cc =C2=A0-O2 -pipe -fno-common -I/usr/src/contrib/sqlite3 =C2=A0-DSQLI=
TE_THREADSAFE=3D1

> =C2=A0-DSQLITE_OMIT_LOAD_EXTENSION =C2=A0 -fPIE -g -gz=3Dzlib -MD =C2=
=A0-MF.depend.sqlite3.o

> -MTsqlite3.o -std=3Dgnu99 -Wno-format-zero-length -fstack-protector-st=
rong

> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-paramete=
r

> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitia=
lized

> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int

> -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable

> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality<=
br>
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member =C2=A0-Qunused-arguments =C2=A0 =C2=A0-c=


> /usr/src/contrib/sqlite3/sqlite3.c -o sqlite3.o

> cc -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3 -DSQLITE_THREADSAF=
E=3D1

> -DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=3Dzlib -std=3Dgnu99

> -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wer=
ror

> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes

> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-s=
ign

> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable

> -Wno-error=3Dunused-but-set-variable -Wno-tautological-compare

> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function

> -Wno-enum-conversion -Wno-unused-local-typedef

> -Wno-address-of-packed-member -Qunused-arguments =C2=A0-Wl,-zrelro -pi=
e =C2=A0 -o

> sqlite3.full sqlite3.o =C2=A0-L/usr/obj/usr/src/arm64.aarch64/lib/libt=
hr

> -lpthread

> ld: error: undefined symbol: main

>>>> referenced by crt1_c.c:72 (/usr/src/lib/csu/aarch64/crt1_c=
.c:72)

>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/lib/=
Scrt1.o:(__start)

> cc: error: linker command failed with exit code 1 (use -v to see invoc=
ation)

> *** Error code 1

> 

> Stop.

> make: stopped in /usr/src/usr.bin/sqlite3

> 

> Not sure if I missed something or if something goes wrong with my Make=
file

> content construction. I basically followed here

> https://www.sqlite.org/howtocompile.html

> <https://www.sqlite.org/howtocompile.html> an=
d then proved the source to

> compile successfully.

> 

> root@generic:/usr/src/contrib/sqlite3 # pwd

> /usr/src/contrib/sqlite3

> root@generic:/usr/src/contrib/sqlite3 # ls -lah

> total 11364

> drwxr-xr-x =C2=A0 3 root =C2=A0wheel =C2=A0 1.0K Oct 27 08:06 .

> drwxr-xr-x =C2=A089 root =C2=A0wheel =C2=A0 2.0K Nov 26 13:01 ..

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A015K Oct 27 08:06 INS=
TALL

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 729B Oct 27 08:06 Makefile=
.am

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 547B Oct 27 08:06 Makefile=
.fallback

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A037K Oct 27 08:06 Mak=
efile.in

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A028K Oct 27 08:06 Mak=
efile.msc

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 3.5K Oct 27 08:06 README.t=
xt

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 7.1K Oct 27 08:06 Replace.=
cs

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 365K Oct 27 08:06 aclocal.=
m4

> -rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 7.2K Oct 27 08:06 compile<=
br>
> -rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A048K Oct 27 08:06 con=
fig.guess

> -rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A035K Oct 27 08:06 con=
fig.sub

> -rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 485K Oct 27 08:06 configur=
e

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 8.5K Oct 27 08:06 configure.ac<=
/a>

> <http://configure.ac>

> -rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A023K Oct 27 08:06 dep=
comp

> -rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A015K Oct 27 08:06 ins=
tall-sh

> -rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 320K Oct 27 08:06 ltmain.s=
h

> -rwxr-xr-x =C2=A0 1 root =C2=A0wheel =C2=A0 6.7K Oct 27 08:06 missing<=
br>
> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 717K Oct 27 08:06 shell.c<=
br>
> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 8.7K Oct 27 08:06 sqlite3.=
1

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 8.2M Oct 27 08:06 sqlite3.=
c

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 599K Oct 27 08:06 sqlite3.=
h

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 267B Oct 27 08:06 sqlite3.pc.i=
n

> <http://sqlite3.pc.in>

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 1.9K Oct 27 08:06 sqlite3.=
rc

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A036K Oct 27 08:06 sql=
ite3ext.h

> -rw-r--r-- =C2=A0 1 root =C2=A0wheel =C2=A0 =C2=A078B Oct 27 08:06 sql=
ite3rc.h

> drwxr-xr-x =C2=A0 6 root =C2=A0wheel =C2=A0 512B Oct 27 08:06 tea

> 

> root@generic:/usr/src/contrib/sqlite3 # cc -DSQLITE_THREADSAFE=3D0

> -DSQLITE_OMIT_LOAD_EXTENSION shell.c sqlite3.c -o sqlite3

> 

> So, the above compilation builds the source successfully.

> 

> This time I've manually invoked the first compilation command and =
it

> works just fine as seen below.

> 

> root@generic:/usr/src/contrib/sqlite3 # cc =C2=A0-O2 -pipe -fno-common=


> -I/usr/src/contrib/sqlite3 =C2=A0-DSQLITE_THREADSAFE=3D0

> =C2=A0-DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=3Dzlib -MD =C2=A0-MF.d=
epend.sqlite3.o

> -MTsqlite3.o -std=3Dgnu99 -Wno-format-zero-length -fstack-protector-st=
rong

> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-paramete=
r

> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitia=
lized

> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int

> -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable

> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality<=
br>
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member =C2=A0-Qunused-arguments -c

> /usr/src/contrib/sqlite3/sqlite3.c -o sqlite3.o

> 

> While the second compilation command below breaks having the same

> manifested error.

> 

> cc -O2 -pipe -fno-common -I/usr/src/contrib/sqlite3 -DSQLITE_THREADSAF=
E=3D1

> -DSQLITE_OMIT_LOAD_EXTENSION -fPIE -g -gz=3Dzlib -std=3Dgnu99

> -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Wer=
ror

> -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes

> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-s=
ign

> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable

> -Wno-error=3Dunused-but-set-variable -Wno-tautological-compare

> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function

> -Wno-enum-conversion -Wno-unused-local-typedef

> -Wno-address-of-packed-member -Qunused-arguments =C2=A0-Wl,-zrelro -pi=
e =C2=A0 -o

> sqlite3.full sqlite3.o =C2=A0-L/usr/obj/usr/src/arm64.aarch64/lib/libt=
hr

> -lpthread

> ld: error: undefined symbol: main

>>>> referenced by crt1_c.c:72 (/usr/src/lib/csu/aarch64/crt1_c=
.c:72)

>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /usr/lib/=
Scrt1.o:(__start)

> cc: error: linker command failed with exit code 1 (use -v to see invoc=
ation)

> *** Error code 1

> 

> Stop.

> make: stopped in /usr/src/usr.bin/sqlite3

> 

> Any idea of this problem? I posted this at freebsd-database ML however=
,

> I'm thinking that the problem might not be related to SQLite3

> perspective as I have compiled the source without any problem at all s=
o,

> I share it here.

> 

> Thanks and best regards,

> Archimedes

> 

> 

> 

> 

> 

> 






--000000000000cae18805ee6204b7--

From nobody Sun Nov 27 15:15:17 2022
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 4NKscR5gC5z4j43F
	for ; Sun, 27 Nov 2022 15:15:51 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from smtp052.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NKscQ3TRrz3qYV
	for ; Sun, 27 Nov 2022 15:15:50 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=o5Js2NmC;
	spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:30) smtp.mailfrom=freebsd@walstatt-de.de;
	dmarc=none
Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by smtp5.goneo.de (Postfix) with ESMTPS id 9A8F010A32DA
	for ; Sun, 27 Nov 2022 16:15:47 +0100 (CET)
Received: from hub2.goneo.de (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPS id C0DF210A32CF
	for ; Sun, 27 Nov 2022 16:15:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
	s=DKIM001; t=1669562145;
	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=t+xvNoeaS+VEVYgpHsSbrVPNtzEnmnxNaBvw2Gl1rv0=;
	b=o5Js2NmCNamMxv7YHnas//7TzP3fVczwiDUKEUjY8R92FZ7NGEtUC5UEvJXg+7VMa+G0zJ
	lmtHoz/ZNilP7ho+X5DRQqSu5x+60X2GFb3eLkJCMr5JBfkCVvtjh3UlF9qMR6+E9FM3gE
	9VcLSHHOJcJZ5f5sxN72DSDhbEE6ZDqhV7XctLLu6/59WVZVf/S3hCrQNszM5ho+yo7Hfo
	otWZk/QJ2ZggMgpUh+zBi/XogqVtU3LjU4S1JTR1H+NRdsRBG+pXT2xnlGDIIAHyWfsYWR
	GBeUV0OXW0Kj3CVFd47B+MoPZVph9am4Hc18Zvnlt3Gg2Mjol4x6hgS+yU2+DQ==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-013-174-210.77.13.pool.telefonica.de [77.13.174.210])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by hub2.goneo.de (Postfix) with ESMTPSA id 7DC7E10A32CC
	for ; Sun, 27 Nov 2022 16:15:45 +0100 (CET)
Date: Sun, 27 Nov 2022 16:15:17 +0100
From: FreeBSD User 
To: FreeBSD CURRENT 
Subject: CAM: extract HDD informations about failure/to fail?
Message-ID: <20221127161544.7dd1207c@thor.intern.walstatt.dynvpn.de>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-UID: d4abf2
X-Rspamd-UID: 8798d7
X-Spamd-Result: default: False [-2.40 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE];
	DKIM_TRACE(0.00)[walstatt-de.de:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	TO_DN_ALL(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[walstatt-de.de];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-Rspamd-Queue-Id: 4NKscQ3TRrz3qYV
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

Hello,

well, the aim of my post sounds strange, but I'm serious.
Background: I run at home a 14-CURRENT based server with a ZFS volume (RAIDZ) comprised from
4x 4 TB HDD. A couple of days I had to exchange the HGST NAS drives since one got a permanent
SMART error. So all HDDs have been replaced by now with four times Seagte IronWolfe Pro 4TB
drives. So far, so good.
Now I face a weird sound sourcing at one of the new HDDs. The box is supposed to be a heavy
duty poudriere build facility, so the drives are up 24/7. It seems that one (or even more)
drives emitt a weird sound like the spindle motor is loosing for a fraction of a second power
and spiining up the the drive again. Searching the net reveals that at least one Seagate
customer did have the same issue and he provided an audio file of that very weird sound, to be
found here:

Post at reddit:
 https://www.reddit.com/r/techsupport/comments/sca6al/seagate_ironwolf_pro_making_weird_noise/

and herin the post of the audio file:

 https://www.mediafire.com/file/x3le816qsakiff9/Hdd.mp4/file

I checked S.M.A.R.T for any unusual data, but everything is fine. The values for 

Power_Cycle_Count
Power-Off_Retract_Count
Start_Stop_Count

seem all within a reasonable range compared to the life time in hours (did some simple
statistsics ), nothing looks unusual.

Also, the advanced view onto each drive via 

smartctl -x

doesn't give me any hint of a power failure as a source for the noise.

So, big question here is: the drives are attached to a HBA, LSI3008 based SAS9300-8i. Is it
possible to retrieve via CAM more health paramteres than those gathered by SMART/smartmontools
and if the answer is yes, how can this be achieved?
It close to impossible to isolate the drive making the noise. My guts tell me to RMA the
supposed to be faulty drive and not to wait until it dies from "spindle motor desease" or
something that is the source for the noises.

Thanks in advance,

oh


-- 
O. Hartmann

From nobody Sun Nov 27 18:04:08 2022
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 4NKxM16GP6z4jP5M
	for ; Sun, 27 Nov 2022 18:04:29 +0000 (UTC)
	(envelope-from pen@lysator.liu.se)
Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NKxM10h4cz44gn;
	Sun, 27 Nov 2022 18:04:28 +0000 (UTC)
	(envelope-from pen@lysator.liu.se)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of pen@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=pen@lysator.liu.se;
	dmarc=pass (policy=none) header.from=lysator.liu.se
Received: from mail.lysator.liu.se (localhost [127.0.0.1])
	by mail.lysator.liu.se (Postfix) with ESMTP id 0D58A1C0CB;
	Sun, 27 Nov 2022 19:04:20 +0100 (CET)
Received: by mail.lysator.liu.se (Postfix, from userid 1004)
	id 0BD821C129; Sun, 27 Nov 2022 19:04:20 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	hermod.lysator.liu.se
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,AWL,HTML_MESSAGE
	autolearn=disabled version=3.4.6
X-Spam-Score: -1.0
Received: from smtpclient.apple (unknown [IPv6:2001:9b1:28fa:7900:5426:ca66:1572:6f63])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.lysator.liu.se (Postfix) with ESMTPSA id 904851C127;
	Sun, 27 Nov 2022 19:04:18 +0100 (CET)
From: Peter Eriksson 
Message-Id: <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_787AA221-05D9-43E9-8A62-1E05DDA91853"
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.200.110.1.12\))
Subject: Re: RFC: nfsd in a vnet jail
Date: Sun, 27 Nov 2022 19:04:08 +0100
In-Reply-To: 
Cc: FreeBSD CURRENT ,
 "Bjoern A. Zeeb" ,
 Alan Somers 
To: Rick Macklem 
References: 
 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	DMARC_POLICY_ALLOW(-0.50)[lysator.liu.se,none];
	MV_CASE(0.50)[];
	R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_TO(0.00)[gmail.com];
	ASN(0.00)[asn:1653, ipnet:2001:6b0::/32, country:EU];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	RCVD_COUNT_THREE(0.00)[4];
	TAGGED_RCPT(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NKxM10h4cz44gn
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_787AA221-05D9-43E9-8A62-1E05DDA91853
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Keep the global variables as defaults that apply to all nfsds and allow =
(at least some subset) to be overridden inside the net jails if some =
things need to be changed from the defaults?

- Peter


On Fri, Nov 25, 2022, 4:24 PM Rick Macklem > wrote:
> Hi,
>=20
> bz@ has encouraged me to fiddle with the nfsd
> so that it works in a vnet jail.
> I have now basically done so, specifically for
> NFSv4, since NFSv3 presents various issues.
>=20
> What I have not yet done is put global variables
> in the vnet. This needs to be done so that the nfsd
> can be run in multiple jail instances and/or in and
> outside of a jail.
> The problem is that there are 100s of global variables.
>=20
> I can see two approaches:
> 1 - Move them all into the vnet jail. This would imply
>     that all the sysctls need to somehow be changed,
>     which would seem to be a POLA violation.
>     It also implies a lot of stuff in the vnet.
> 2 - Just move the global variables that will always
>     differ from one nfsd to another (this would make
>     the sysctls global and apply to all nfsds).
>     This will keep the number of globals in the vnet
>     smaller.
>=20
> I am currently leaning towards #2, put what do others
> think?
>=20
> rick
> ps: Personally, I don't know what use there is of
>     running the nfsd inside a vnet jail, but bz@ has
>     some use case.


--Apple-Mail=_787AA221-05D9-43E9-8A62-1E05DDA91853
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Keep the =
global variables as defaults that apply to all nfsds and allow (at least =
some subset) to be overridden inside the net jails if some things need =
to be changed from the defaults?

- =
Peter


On Fri, Nov =
25, 2022, 4:24 PM Rick Macklem <rick.macklem@gmail.com> =
wrote:
Hi,

bz@ has =
encouraged me to fiddle with the nfsd
so that it works in a vnet =
jail.
I =
have now basically done so, specifically for
NFSv4, since =
NFSv3 presents various issues.

What I have not yet done is put global =
variables
in the vnet. This needs to be done so =
that the nfsd
can be run in multiple jail instances =
and/or in and
outside of a jail.
The problem is =
that there are 100s of global variables.

I can see two approaches:
1 - Move them =
all into the vnet jail. This would imply
    that all the sysctls need =
to somehow be changed,
    which would seem to be a =
POLA violation.
    It also implies a lot of =
stuff in the vnet.
2 - Just move the global variables that =
will always
    differ from one nfsd to =
another (this would make
    the sysctls global and =
apply to all nfsds).
    This will keep the number =
of globals in the vnet
    smaller.

I am currently =
leaning towards #2, put what do others
think?

rick
ps: Personally, I don't know what use =
there is of
    running the nfsd inside a =
vnet jail, but bz@ has
    some use =
case.



=

--Apple-Mail=_787AA221-05D9-43E9-8A62-1E05DDA91853--

From nobody Sun Nov 27 18:10:41 2022
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 4NKxVR0Hclz4jPqb
	for ; Sun, 27 Nov 2022 18:10:55 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NKxVQ45Msz464r
	for ; Sun, 27 Nov 2022 18:10:54 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x631.google.com with SMTP id n21so20874137ejb.9
        for ; Sun, 27 Nov 2022 10:10:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=C10tD6KblrWwq6MsJXng9H3OM0kUckUtk7EWxrS5iT0=;
        b=79ll7z7P8oDL4zxYuN56Vim3oOwzlglXpqLxC8GZVw+NwJVLFgQApqE6tu1SP51lkw
         HSQKhK6tK/vXaFzYOK9ITYWLOv/+AMztFgfgKzY2ebz9kDn/98i5o7EfNfqJcA55RXi5
         p4Kg4sxM/EzlQy641weliNs5Q66zm4QGAxP+vIou70NX1Rswo4lgcMx0hg3ruJE9Stok
         I8tNchN+qB2u77KF36jz+2YO3ElO4F/JHwcUG/mypBxWCqxkJml8Fr96mXQ5fQZDrAij
         3SpLzxcZw4uTJsZvE7eXIO+C2oPwYQiQUsa7beP+jEWVAWeOHd4TdgTNm7wdbC2nkji2
         CyQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=C10tD6KblrWwq6MsJXng9H3OM0kUckUtk7EWxrS5iT0=;
        b=kSjK+EHP4Hf+4wD8UsZv5EFdg6GiLSogjgIhpuTbjfpDBmc4Exda+lFmKioFzmyfHK
         jd9oFGvJoU3hIbXLXhRPSFMAre00FTCHcsvt3JrstOHjVCWkgxW294bkM2ip3z5Ti5K0
         bHG1jxOHETflKSGNKlK+9A+jDAuFRkJb9PVD5UPeNpSKYQlUfVE22JfIiQ2onIvdWTld
         m8+Kru9L0ee1lN1A8NGICfuUdkfa3BEtxNcAqsDjkUQob362O+oMkPQ/V1hrl1gsa/4l
         dHpHJFd+jY/O0bb4ZDIPSjn8W8Vca92k7lxRnStu63QEC0t8FBuFvw+tmNMSLoBJkSbB
         aYdQ==
X-Gm-Message-State: ANoB5pmEghbphD5he+BlYp06cR0TsHkXPsMSGW7UlDXKAwAIPtIgAZTC
	ayqQRwD5HmhMdv+l0WemHBQIQhy+Xyuok6NugmEM3U+Mcuo=
X-Google-Smtp-Source: AA0mqf5brD3V4y88efN2nfZPiFoyYXh6RZM+r08bZIMnJieJxgDm0evTChvkj0Q5mG1CgvghWUyzNTLs4vOyxrtPZYg=
X-Received: by 2002:a17:907:206f:b0:7bb:cc6b:86d6 with SMTP id
 qp15-20020a170907206f00b007bbcc6b86d6mr13457815ejb.252.1669572652908; Sun, 27
 Nov 2022 10:10:52 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <20221127161544.7dd1207c@thor.intern.walstatt.dynvpn.de>
In-Reply-To: <20221127161544.7dd1207c@thor.intern.walstatt.dynvpn.de>
From: Warner Losh 
Date: Sun, 27 Nov 2022 11:10:41 -0700
Message-ID: 
Subject: Re: CAM: extract HDD informations about failure/to fail?
To: FreeBSD User 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000e758c105ee77ac95"
X-Rspamd-Queue-Id: 4NKxVQ45Msz464r
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e758c105ee77ac95
Content-Type: text/plain; charset="UTF-8"

On Sun, Nov 27, 2022 at 8:15 AM FreeBSD User  wrote:

> Hello,
>
> well, the aim of my post sounds strange, but I'm serious.
> Background: I run at home a 14-CURRENT based server with a ZFS volume
> (RAIDZ) comprised from
> 4x 4 TB HDD. A couple of days I had to exchange the HGST NAS drives since
> one got a permanent
> SMART error. So all HDDs have been replaced by now with four times Seagte
> IronWolfe Pro 4TB
> drives. So far, so good.
> Now I face a weird sound sourcing at one of the new HDDs. The box is
> supposed to be a heavy
> duty poudriere build facility, so the drives are up 24/7. It seems that
> one (or even more)
> drives emitt a weird sound like the spindle motor is loosing for a
> fraction of a second power
> and spiining up the the drive again. Searching the net reveals that at
> least one Seagate
> customer did have the same issue and he provided an audio file of that
> very weird sound, to be
> found here:
>
> Post at reddit:
>
> https://www.reddit.com/r/techsupport/comments/sca6al/seagate_ironwolf_pro_making_weird_noise/
>
> and herin the post of the audio file:
>
>  https://www.mediafire.com/file/x3le816qsakiff9/Hdd.mp4/file
>
> I checked S.M.A.R.T for any unusual data, but everything is fine. The
> values for
>
> Power_Cycle_Count
> Power-Off_Retract_Count
> Start_Stop_Count
>
> seem all within a reasonable range compared to the life time in hours (did
> some simple
> statistsics ), nothing looks unusual.
>
> Also, the advanced view onto each drive via
>
> smartctl -x
>
> doesn't give me any hint of a power failure as a source for the noise.
>
> So, big question here is: the drives are attached to a HBA, LSI3008 based
> SAS9300-8i. Is it
> possible to retrieve via CAM more health paramteres than those gathered by
> SMART/smartmontools
> and if the answer is yes, how can this be achieved?
>

>From SATA drives? No. smartctl with enough flags retrieves everything
available. Seagate is mainstream enough that there's unlikely to be other
data.... at least that Seagate documents.


> It close to impossible to isolate the drive making the noise. My guts tell
> me to RMA the
> supposed to be faulty drive and not to wait until it dies from "spindle
> motor desease" or
> something that is the source for the noises.
>

The only way you can do this is to just apply power to the drives one at a
time, which in most setups requires pulling cables.

Warner

--000000000000e758c105ee77ac95
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Nov 27, 2022 at 8:15 AM FreeB=
SD User <freebsd@walstatt-de.d=
e> wrote:
Hello,



well, the aim of my post sounds strange, but I'm serious.

Background: I run at home a 14-CURRENT based server with a ZFS volume (RAID=
Z) comprised from

4x 4 TB HDD. A couple of days I had to exchange the HGST NAS drives since o=
ne got a permanent

SMART error. So all HDDs have been replaced by now with four times Seagte I=
ronWolfe Pro 4TB

drives. So far, so good.

Now I face a weird sound sourcing at one of the new HDDs. The box is suppos=
ed to be a heavy

duty poudriere build facility, so the drives are up 24/7. It seems that one=
 (or even more)

drives emitt a weird sound like the spindle motor is loosing for a fraction=
 of a second power

and spiining up the the drive again. Searching the net reveals that at leas=
t one Seagate

customer did have the same issue and he provided an audio file of that very=
 weird sound, to be

found here:



Post at reddit:

=C2=A0h=
ttps://www.reddit.com/r/techsupport/comments/sca6al/seagate_ironwolf_pro_ma=
king_weird_noise/



and herin the post of the audio file:



=C2=A0https://www.mediafire.com/file/x3le=
816qsakiff9/Hdd.mp4/file



I checked S.M.A.R.T for any unusual data, but everything is fine. The value=
s for 



Power_Cycle_Count

Power-Off_Retract_Count

Start_Stop_Count



seem all within a reasonable range compared to the life time in hours (did =
some simple

statistsics ), nothing looks unusual.



Also, the advanced view onto each drive via 



smartctl -x



doesn't give me any hint of a power failure as a source for the noise.<=
br>


So, big question here is: the drives are attached to a HBA, LSI3008 based S=
AS9300-8i. Is it

possible to retrieve via CAM more health paramteres than those gathered by =
SMART/smartmontools

and if the answer is yes, how can this be achieved?
From SATA drives? No. smartctl with enough flags retrieves eve=
rything available. Seagate is mainstream enough that there's unlikely t=
o be other data.... at least that Seagate documents.
=C2=A0
=


It close to impossible to isolate the drive making the noise. My guts tell =
me to RMA the

supposed to be faulty drive and not to wait until it dies from "spindl=
e motor desease" or

something that is the source for the noises.

The only way you can do this is to just apply power to the drives one=
 at a time, which in most setups requires pulling cables.

Warner=C2=A0


--000000000000e758c105ee77ac95--

From nobody Sun Nov 27 18:18:51 2022
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 4NKxgm29K2z4jQlp
	for ; Sun, 27 Nov 2022 18:19:00 +0000 (UTC)
	(envelope-from jamie@freebsd.org)
Received: from gritton.org (gritton.org [162.220.209.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 (2048 bits) client-digest SHA256)
	(Client CN "gritton.org", Issuer "gritton.org" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NKxgl1JQ6z495L;
	Sun, 27 Nov 2022 18:18:59 +0000 (UTC)
	(envelope-from jamie@freebsd.org)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=softfail (mx1.freebsd.org: 162.220.209.3 is neither permitted nor denied by domain of jamie@freebsd.org) smtp.mailfrom=jamie@freebsd.org;
	dmarc=none
Received: from gritton.org ([127.0.0.3])
	(authenticated bits=0)
	by gritton.org (8.16.1/8.16.1) with ESMTPA id 2ARIIpcM048840;
	Sun, 27 Nov 2022 10:18:51 -0800 (PST)
	(envelope-from jamie@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
Date: Sun, 27 Nov 2022 10:18:51 -0800
From: James Gritton 
To: freebsd-current@freebsd.org
Cc: Rick Macklem , bz@freebsd.org
Subject: Re: RFC: nfsd in a vnet jail
In-Reply-To: 
References: 
User-Agent: Roundcube Webmail/1.4.11
Message-ID: 
X-Sender: jamie@freebsd.org
Content-Type: multipart/alternative;
 boundary="=_d129efa9d504031e718030baf8bed06e"
X-Spamd-Result: default: False [-3.10 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.996];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FREEMAIL_CC(0.00)[gmail.com,freebsd.org];
	ASN(0.00)[asn:30247, ipnet:162.220.208.0/22, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	R_SPF_SOFTFAIL(0.00)[~all];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[jamie];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TAGGED_RCPT(0.00)[];
	TO_DN_SOME(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NKxgl1JQ6z495L
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--=_d129efa9d504031e718030baf8bed06e
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-11-25 15:17, Rick Macklem wrote:

> Hi,
> 
> bz@ has encouraged me to fiddle with the nfsd
> so that it works in a vnet jail.
> I have now basically done so, specifically for
> NFSv4, since NFSv3 presents various issues.
> 
> What I have not yet done is put global variables
> in the vnet. This needs to be done so that the nfsd
> can be run in multiple jail instances and/or in and
> outside of a jail.
> The problem is that there are 100s of global variables.
> 
> I can see two approaches:
> 1 - Move them all into the vnet jail. This would imply
> that all the sysctls need to somehow be changed,
> which would seem to be a POLA violation.
> It also implies a lot of stuff in the vnet.
> 2 - Just move the global variables that will always
> differ from one nfsd to another (this would make
> the sysctls global and apply to all nfsds).
> This will keep the number of globals in the vnet
> smaller.
> 
> I am currently leaning towards #2, put what do others
> think?
> 
> rick
> ps: Personally, I don't know what use there is of
> running the nfsd inside a vnet jail, but bz@ has
> some use case.

I would prefer closer to #2, unless you want to support only one jail 
running nfsd (which is admittedly one of the more likely scenarios).  I 
imagine it's a case-by-case judgement call, as to whether a particular 
knob should be global or per-jail.

- Jamie
--=_d129efa9d504031e718030baf8bed06e
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



On 2022-11-25 15:17, Rick Macklem wrote:








Hi,


 

bz@ has en=
couraged me to fiddle with the nfsd


so that it=
 works in a vnet jail.


I have now=
 basically done so, specifically for


NFSv4, sin=
ce NFSv3 presents various issues.


 

What I hav=
e not yet done is put global variables


in the vne=
t. This needs to be done so that the nfsd


can be run=
 in multiple jail instances and/or in and


outside of=
 a jail.


The proble=
m is that there are 100s of global variables.


 

I can see =
two approaches:


1 - Move t=
hem all into the vnet jail. This would imply


  &nb=
sp; that all the sysctls need to somehow be changed,


  &nb=
sp; which would seem to be a POLA violation.


  &nb=
sp; It also implies a lot of stuff in the vnet.


2 - Just m=
ove the global variables that will always


  &nb=
sp; differ from one nfsd to another (this would make


  &nb=
sp; the sysctls global and apply to all nfsds).


  &nb=
sp; This will keep the number of globals in the vnet


  &nb=
sp; smaller.


 

I am curre=
ntly leaning towards #2, put what do others


think?

 

rick


ps: Person=
ally, I don't know what use there is of


  &nb=
sp; running the nfsd inside a vnet jail, but bz@ has


  &nb=
sp; some use case.












 





I would pr=
efer closer to #2, unless you want to support only one jail running nfsd (w=
hich is admittedly one of the more likely scenarios).  I imagine it's =
a case-by-case judgement call, as to whether a particular knob should be gl=
obal or per-jail.


 

- Jamie


--=_d129efa9d504031e718030baf8bed06e--

From nobody Sun Nov 27 19:13:31 2022
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 4NKytp4tbxz4jWyT
	for ; Sun, 27 Nov 2022 19:13:38 +0000 (UTC)
	(envelope-from bz@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NKytp4L9sz4GQw;
	Sun, 27 Nov 2022 19:13:38 +0000 (UTC)
	(envelope-from bz@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1669576418;
	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=LAN5rLUs4XaFAMPaW9ldAnSiG72q7MMG/lvqP18GXjk=;
	b=e8N2BUSJ+GvLVWFNROhzUt04mF5MtnkCCOrY+ySmBh+CoPUAaHNOeZToYrFC+Li4H6MpNH
	2I0jTT6k7VnyWAgEdH0/2N/lIwh8MBXOQsytPiBUuzbRA8XagGkS1o9ZubWQhBE1PD+OJz
	8ikYkpnHiCjtKLOC+y/Sq+rP4d8RRKTk5Tm/PYuEJup3KIVDv+1lib7dh6O0LuF7rGLtxy
	rTvuoE0JWx/87vWIheLmiR50fKSs5VXYoQNUBWy2JUBMtnDzGCA48TlWRzlCs68swFtZ2n
	ghIY0d591VZyYjHULwRSm3N473cuQtESvI34DrY6ATaMV5o/Crauj2DpUydIjQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1669576418;
	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=LAN5rLUs4XaFAMPaW9ldAnSiG72q7MMG/lvqP18GXjk=;
	b=isoPFsdPJITvMxNXbiMQHjBRGxcpC+lvxqtJatjg5jtG1V+PLsnLzazrvPnFfWGl1LxAIL
	uBJ2cXyINVUAqiS0Lxhd5NC7azp47Ay0ZCbmhB2Z4btdEwolU//81ZLRLXr5z62eurlxHS
	wsGPWtVPNh/NjsXxeAwNIHsmFFTOCt5XLGjM8tFVqrQvKBhw0O9mQ8HkCIGUKExDTV0HaT
	41eKTHfGi/S2W4hNbyw1loCNl/0WqgblWkiETuKttcafG+PARrDn+9iilFGlAypFvGcUEz
	buNtCur5j5kfzKV47WlUdqds1GBykheSOgqU5z4Hhq9aW86ynGdM0SmKjK3AZQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669576418; a=rsa-sha256; cv=none;
	b=Lzfk2K6X6j86uSSzILo9tJLH84ezN3j/ycoVkNuPQKD3kvbATlrnOQ3ao/ukHgA6OQrIH2
	NW0exe3/uHUb1vgwtTmi94tFI31/OVpo8OVHrhUKHZJwMq96/E18vS2nNIO9l6ZPabZda3
	MLlfkiw9ZslcimW0DEq006E20xtmO1i83IOoBquGM4K6EdrUtLyL/jfrolbepspZS4UT/2
	FKkRjTYSVGNfTxn5LaiXhJ8BJqhkWTnk9A8nzLuUy0sWftIZTtM966Jfe3IazW3Z9nwCMj
	ozw3/CHhGoSTR+XCESLuQjihGmYmHd6VpXka7Iu2RUCaTM42kNMNVM7bB0UjAQ==
Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified))
	(Authenticated sender: bz/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NKytp1mYfzlqN;
	Sun, 27 Nov 2022 19:13:38 +0000 (UTC)
	(envelope-from bz@freebsd.org)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mx1.sbone.de (Postfix) with ESMTPS id 713CC8D4A17E;
	Sun, 27 Nov 2022 19:13:35 +0000 (UTC)
Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPS id A1FBE5C3A833;
	Sun, 27 Nov 2022 19:13:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024)
	with ESMTP id 5jesvg1o_ZVo; Sun, 27 Nov 2022 19:13:32 +0000 (UTC)
Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPSA id A388E5C3A830;
	Sun, 27 Nov 2022 19:13:32 +0000 (UTC)
Date: Sun, 27 Nov 2022 19:13:31 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: James Gritton 
cc: freebsd-current@freebsd.org, Rick Macklem 
Subject: Re: RFC: nfsd in a vnet jail
In-Reply-To: 
Message-ID: <5244s3o-p9q6-qp97-2623-onso786os643@serrofq.bet>
References:  
X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-ThisMailContainsUnwantedMimeParts: N

On Sun, 27 Nov 2022, James Gritton wrote:

> On 2022-11-25 15:17, Rick Macklem wrote:
>
>> Hi,
>> 
>> bz@ has encouraged me to fiddle with the nfsd
>> so that it works in a vnet jail.
>> I have now basically done so, specifically for
>> NFSv4, since NFSv3 presents various issues.
>> 
>> What I have not yet done is put global variables
>> in the vnet. This needs to be done so that the nfsd
>> can be run in multiple jail instances and/or in and
>> outside of a jail.
>> The problem is that there are 100s of global variables.
>> 
>> I can see two approaches:
>> 1 - Move them all into the vnet jail. This would imply
>> that all the sysctls need to somehow be changed,
>> which would seem to be a POLA violation.

Not a POLA.  The sysctl (names) don't change.  Just the values are
duplicated per-jail.

>> It also implies a lot of stuff in the vnet.
>> 2 - Just move the global variables that will always
>> differ from one nfsd to another (this would make
>> the sysctls global and apply to all nfsds).
>> This will keep the number of globals in the vnet
>> smaller.
>> 
>> I am currently leaning towards #2, put what do others
>> think?
>> 
>> rick
>> ps: Personally, I don't know what use there is of
>> running the nfsd inside a vnet jail, but bz@ has
>> some use case.
>
> I would prefer closer to #2, unless you want to support only one jail running 
> nfsd (which is admittedly one of the more likely scenarios).  I imagine it's 
> a case-by-case judgement call, as to whether a particular knob should be 
> global or per-jail.


I think the call is:  everything that if changed in a vnet jail that
could cause the entire system to be DoSed by changing the setting in the
jail defintitvely stays global.

Everything which needs to be writeable on a per-instance base probably
needs to be virtualised.

My main concern with virtualising the variables will be early boot and
and NFSROOT szenarios that will need access to them early on before the
virtual network stacks are properly initialized;  I can help sorting
that out if my concerns become real.  Most probably was sorted before
for NFSROOT with the IP stack so it's likely an okay job now.


Also given I have once done it before for another subsystem;  we could
think of a V_FS bit (and I write it that way to not confuse it with
VFS).  Now NFS sits somewhere between FS and NET so I am not surt where
it should belong should we ponder that route as yet another option (and
if we think that VNETs will be way too big one day? -- there's probably
a lot other fish still to fry though some of that has been burnt in the
past already).

I think I have another email or two on the subject (possibly privately);
sorry Rick that I haven't gotten to them more timely.  I'll have a look
later tonight.

/bz

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Sun Nov 27 21:12:49 2022
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 4NL1XW2Svbz4hpXg
	for ; Sun, 27 Nov 2022 21:12:59 +0000 (UTC)
	(envelope-from phk@critter.freebsd.dk)
Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222])
	(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 4NL1XV70K3z3KW1
	for ; Sun, 27 Nov 2022 21:12:58 +0000 (UTC)
	(envelope-from phk@critter.freebsd.dk)
Authentication-Results: mx1.freebsd.org;
	none
Received: from critter.freebsd.dk (unknown [192.168.55.3])
	(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 phk.freebsd.dk (Postfix) with ESMTPS id 88F3D89293;
	Sun, 27 Nov 2022 21:12:50 +0000 (UTC)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 2ARLCoRO013243
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sun, 27 Nov 2022 21:12:50 GMT
	(envelope-from phk@critter.freebsd.dk)
Received: (from phk@localhost)
	by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 2ARLCnsk013242;
	Sun, 27 Nov 2022 21:12:49 GMT
	(envelope-from phk)
Message-Id: <202211272112.2ARLCnsk013242@critter.freebsd.dk>
To: Warner Losh 
cc: FreeBSD User ,
        FreeBSD CURRENT 
Subject: Re: CAM: extract HDD informations about failure/to fail?
In-reply-to: 
From: "Poul-Henning Kamp" 
References: <20221127161544.7dd1207c@thor.intern.walstatt.dynvpn.de> 
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-ID: <13240.1669583569.1@critter.freebsd.dk>
Date: Sun, 27 Nov 2022 21:12:49 +0000
X-Rspamd-Queue-Id: 4NL1XV70K3z3KW1
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--------
Warner Losh writes:

> It close to impossible to isolate the drive making the noise. 

Use a long thin piece of hard wood as a stethoscope.

I keep a 30cm length of 6mm beech dowel in my tool-chest,
but in a pinch you can use a pencil or the shaft from an
art-brush.

Press one end agaist the little piece of cartilage which
can close into your ear, and hold the other end against the suspect
disk-drive, and you hear if there are any mechanical issues.

It also works for fans, motors, bikes etc.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From nobody Sun Nov 27 22:14:27 2022
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 4NL2w25xbZz4j027
	for ; Sun, 27 Nov 2022 22:14:58 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NL2w21P41z3hMg
	for ; Sun, 27 Nov 2022 22:14:58 +0000 (UTC)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1])
	by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 2ARMERI3009735;
	Sun, 27 Nov 2022 14:14:27 -0800 (PST)
	(envelope-from freebsd-rwg@gndrsh.dnsmgr.net)
Received: (from freebsd-rwg@localhost)
	by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 2ARMERSR009734;
	Sun, 27 Nov 2022 14:14:27 -0800 (PST)
	(envelope-from freebsd-rwg)
From: "Rodney W. Grimes" 
Message-Id: <202211272214.2ARMERSR009734@gndrsh.dnsmgr.net>
Subject: Re: CAM: extract HDD informations about failure/to fail?
In-Reply-To: 
To: Warner Losh 
Date: Sun, 27 Nov 2022 14:14:27 -0800 (PST)
CC: FreeBSD User ,
        FreeBSD CURRENT 
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Rspamd-Queue-Id: 4NL2w21P41z3hMg
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

> On Sun, Nov 27, 2022 at 8:15 AM FreeBSD User  wrote:
> 
> > Hello,
> >
> > well, the aim of my post sounds strange, but I'm serious.
> > Background: I run at home a 14-CURRENT based server with a ZFS volume
> > (RAIDZ) comprised from
> > 4x 4 TB HDD. A couple of days I had to exchange the HGST NAS drives since
> > one got a permanent
> > SMART error. So all HDDs have been replaced by now with four times Seagte
> > IronWolfe Pro 4TB
> > drives. So far, so good.
> > Now I face a weird sound sourcing at one of the new HDDs. The box is
> > supposed to be a heavy
> > duty poudriere build facility, so the drives are up 24/7. It seems that
> > one (or even more)
> > drives emitt a weird sound like the spindle motor is loosing for a
> > fraction of a second power
> > and spiining up the the drive again. Searching the net reveals that at
> > least one Seagate
> > customer did have the same issue and he provided an audio file of that
> > very weird sound, to be
> > found here:
> >
> > Post at reddit:
> >
> > https://www.reddit.com/r/techsupport/comments/sca6al/seagate_ironwolf_pro_making_weird_noise/
> >
> > and herin the post of the audio file:
> >
> >  https://www.mediafire.com/file/x3le816qsakiff9/Hdd.mp4/file
> >
> > I checked S.M.A.R.T for any unusual data, but everything is fine. The
> > values for
> >
> > Power_Cycle_Count
> > Power-Off_Retract_Count
> > Start_Stop_Count
> >
> > seem all within a reasonable range compared to the life time in hours (did
> > some simple
> > statistsics ), nothing looks unusual.
> >
> > Also, the advanced view onto each drive via
> >
> > smartctl -x
> >
> > doesn't give me any hint of a power failure as a source for the noise.
> >
> > So, big question here is: the drives are attached to a HBA, LSI3008 based
> > SAS9300-8i. Is it
> > possible to retrieve via CAM more health paramteres than those gathered by
> > SMART/smartmontools
> > and if the answer is yes, how can this be achieved?
> >
> 
> >From SATA drives? No. smartctl with enough flags retrieves everything
> available. Seagate is mainstream enough that there's unlikely to be other
> data.... at least that Seagate documents.
> 
> 
> > It close to impossible to isolate the drive making the noise. My guts tell
> > me to RMA the
> > supposed to be faulty drive and not to wait until it dies from "spindle
> > motor desease" or
> > something that is the source for the noises.
> >
> 
> The only way you can do this is to just apply power to the drives one at a
> time, which in most setups requires pulling cables.
> 
> Warner

What about using camcontrol standby, that should spin the drive down.
It probably takes a camcontrol reset to spin it back up.

	camcontrol standby ada0
	camcontrol reset ada0

-- 
Rod Grimes                                                 rgrimes@freebsd.org

From nobody Mon Nov 28 02:11:00 2022
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 4NL88m2d7rz4jYQm
	for ; Mon, 28 Nov 2022 02:11:20 +0000 (UTC)
	(envelope-from julian@freebsd.org)
Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16])
	(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 "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NL88m0Dt3z400f;
	Mon, 28 Nov 2022 02:11:19 +0000 (UTC)
	(envelope-from julian@freebsd.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: from [192.168.0.11] (c-73-92-38-73.hsd1.ca.comcast.net [73.92.38.73])
	(authenticated bits=0)
	by vps1.elischer.org (8.17.1/8.15.2) with ESMTPSA id 2AS2B6lI070885
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT);
	Sun, 27 Nov 2022 18:11:07 -0800 (PST)
	(envelope-from julian@freebsd.org)
X-Authentication-Warning: vps1.elischer.org: Host c-73-92-38-73.hsd1.ca.comcast.net [73.92.38.73] claimed to be [192.168.0.11]
Message-ID: <0798d1c7-96c6-1bd8-fdea-aa456b9ce194@freebsd.org>
Date: Sun, 27 Nov 2022 18:11:00 -0800
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.5.0
Subject: Re: RFC: nfsd in a vnet jail
To: Rick Macklem 
Cc: freebsd-current@freebsd.org, "Bjoern A. Zeeb" ,
        Marko Zec , James Gritton 
References: 
 
 <5244s3o-p9q6-qp97-2623-onso786os643@serrofq.bet>
Content-Language: en-US
From: Julian Elischer 
In-Reply-To: <5244s3o-p9q6-qp97-2623-onso786os643@serrofq.bet>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4NL88m0Dt3z400f
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US];
	TAGGED_RCPT(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On 11/27/22 11:13 AM, Bjoern A. Zeeb wrote:
> On Sun, 27 Nov 2022, James Gritton wrote:
>
>> On 2022-11-25 15:17, Rick Macklem wrote:
>>
>>> Hi,
>>>
>>> bz@ has encouraged me to fiddle with the nfsd
>>> so that it works in a vnet jail.
>>> I have now basically done so, specifically for
>>> NFSv4, since NFSv3 presents various issues.
>>>
>>> What I have not yet done is put global variables
>>> in the vnet. This needs to be done so that the nfsd
>>> can be run in multiple jail instances and/or in and
>>> outside of a jail.
>>> The problem is that there are 100s of global variables.
>>>
>>> I can see two approaches:
>>> 1 - Move them all into the vnet jail. This would imply
>>> that all the sysctls need to somehow be changed,
>>> which would seem to be a POLA violation.
>
> Not a POLA.  The sysctl (names) don't change.  Just the values are
> duplicated per-jail.
>
>
>

As Marko and I (mostly Marko) were assigning different variable and 
sysctls
when Vnet first hit, it was generally  pretty obvious which were local 
and which were global.
The sysctls values need to mean the same thing in the jail as they do 
in an unjailed system,
so the sysctl names don't change, just the value reported changes.
Some systls become read-only or invisible in jails.
Sometimes this takes adding some boilerplate virtualization code to 
each sysctl howeve
there is already some inbuilt support in the SYSCTL framework for VNET 
isolation.
You just need to set the CTLFLAG_VNET bit in the sysctl definition.
I agree with what Bjorn says below.
There is a slight added complication in that it is not just vnet but 
jailing as well
that needs to be take into account because vnet doesn't affect VFS, 
but jails do.

>
>>> It also implies a lot of stuff in the vnet.
>>> 2 - Just move the global variables that will always
>>> differ from one nfsd to another (this would make
>>> the sysctls global and apply to all nfsds).
>>> This will keep the number of globals in the vnet
>>> smaller.
>>>
>>> I am currently leaning towards #2, put what do others
>>> think?
>>>
>>> rick
>>> ps: Personally, I don't know what use there is of
>>> running the nfsd inside a vnet jail, but bz@ has
>>> some use case.
>>
>> I would prefer closer to #2, unless you want to support only one 
>> jail running nfsd (which is admittedly one of the more likely 
>> scenarios).  I imagine it's a case-by-case judgement call, as to 
>> whether a particular knob should be global or per-jail.
>
>
> I think the call is:  everything that if changed in a vnet jail that
> could cause the entire system to be DoSed by changing the setting in 
> the
> jail defintitvely stays global.
>
> Everything which needs to be writeable on a per-instance base probably
> needs to be virtualised.
>
> My main concern with virtualising the variables will be early boot and
> and NFSROOT szenarios that will need access to them early on before the
> virtual network stacks are properly initialized;  I can help sorting
> that out if my concerns become real.  Most probably was sorted before
> for NFSROOT with the IP stack so it's likely an okay job now.
>
>
> Also given I have once done it before for another subsystem;  we could
> think of a V_FS bit (and I write it that way to not confuse it with
> VFS).  Now NFS sits somewhere between FS and NET so I am not surt where
> it should belong should we ponder that route as yet another option (and
> if we think that VNETs will be way too big one day? -- there's probably
> a lot other fish still to fry though some of that has been burnt in the
> past already).
>
> I think I have another email or two on the subject (possibly 
> privately);
> sorry Rick that I haven't gotten to them more timely.  I'll have a look
> later tonight.
>
> /bz
>


From nobody Mon Nov 28 21:17:32 2022
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 4NLfKg6CsRz4j2Sg
	for ; Mon, 28 Nov 2022 21:50:47 +0000 (UTC)
	(envelope-from editor@callfortesting.org)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NLfKg14t1z3hv2
	for ; Mon, 28 Nov 2022 21:50:47 +0000 (UTC)
	(envelope-from editor@callfortesting.org)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=callfortesting-org.20210112.gappssmtp.com header.s=20210112 header.b=ZReYds8f;
	spf=none (mx1.freebsd.org: domain of editor@callfortesting.org has no SPF policy when checking 2607:f8b0:4864:20::102c) smtp.mailfrom=editor@callfortesting.org;
	dmarc=none
Received: by mail-pj1-x102c.google.com with SMTP id b13-20020a17090a5a0d00b0021906102d05so9982561pjd.5
        for ; Mon, 28 Nov 2022 13:50:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=callfortesting-org.20210112.gappssmtp.com; s=20210112;
        h=content-transfer-encoding:subject:from:to:content-language
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=nAP0EkkDPEKVpaDg2lF3iA42V474sqYqLsaY/J/FHMM=;
        b=ZReYds8fLnPxbgymBLhjQZKZG7jcdqnOgs6WCpfirFeXcDV1uK15bBs9arKIUqdRev
         N++rxwVtRZggw1VPAsExWBD+zFIQVOGbIl0MD5J5aQJB8DCqSRsJSAlTaVcxdtRNvos3
         7JgL3oDqguQY6gjEjUxNajZShUTsosVLYo1dOQhHQYJ5VYenrLBkyhaYNRALZnZAdvtS
         fOkoCUGs2PHPlPyTP+nwuigmD77aGu6/E1yKtMQPB0g85kfpngzAxoFBoWEvp3N5FM8g
         Ub2t2/PqxQsrcYe7U+dG43yL70lSFehl/7WswbWSNGMBiUQwNxG32eRR0SRUF8qrtQoB
         9BXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:subject:from:to:content-language
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=nAP0EkkDPEKVpaDg2lF3iA42V474sqYqLsaY/J/FHMM=;
        b=G+UO9b5p8u/gIT5jRn88XWHXtwN1T0Z7n8flyAk2qzNQZpvD1dP5PSF5VVG17RktSF
         6ig2d4yV3o2p3Fq7YAHMIRK5m6AlTTSy4IoNaj14596902d9Zp/9KsQeqgTzNWZHZKbs
         jkGoRVBORDX0fsYyvQL+xay1T9cqkGIvlme4FObTvWcS12Hkz8YHC6vRPhzNSwBgg6QQ
         gDpM4Uq2pRv+pjWqTyS9n/zBCAKPU8dioAivhW8YSUvEi+PiIlBqqqs+TS4V9B9SCssI
         o2/4gNAiOpqe2QYDAwOgVkbFaGvw6hB9yJyyDAIl2bmXwtcLS6MP+Bc/liRayRi7DQ+v
         tpZQ==
X-Gm-Message-State: ANoB5pnHSnTazFkbeZLVDOt/GmXxOItY5rMVKAHnsfhLep79E27umLQ0
	N6TsreespTzloLq+z1JcQgL8+UhU5eViG9DT
X-Google-Smtp-Source: AA0mqf6YkQzeIkRNr0L2p+b7UrQKWePXv10W148TW0SwoRTNTGi7Jmsnb6Wu6Deih3JQG8Cvq3s0dQ==
X-Received: by 2002:a17:90b:2d8b:b0:202:f88d:587 with SMTP id sj11-20020a17090b2d8b00b00202f88d0587mr57821821pjb.232.1669672245545;
        Mon, 28 Nov 2022 13:50:45 -0800 (PST)
Received: from [10.0.0.236] (c-73-157-223-253.hsd1.or.comcast.net. [73.157.223.253])
        by smtp.gmail.com with ESMTPSA id q18-20020a170902f79200b0016cf3f124e1sm9330189pln.234.2022.11.28.13.50.45
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 28 Nov 2022 13:50:45 -0800 (PST)
Message-ID: 
Date: Mon, 28 Nov 2022 13:17:32 -0800
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:102.0)
 Gecko/20100101 Thunderbird/102.5.0
Content-Language: en-US
To: freebsd-current@freebsd.org
From: Michael Dexter 
Subject: smartpqi0 "panic: Segment size is not aligned" Related panic on
 savecore?
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-2.30 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	R_DKIM_ALLOW(-0.20)[callfortesting-org.20210112.gappssmtp.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102c:from];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	DKIM_TRACE(0.00)[callfortesting-org.20210112.gappssmtp.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DMARC_NA(0.00)[callfortesting.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TO_DN_NONE(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NLfKg14t1z3hv2
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

The HPE P408i-a SR Gen10 3.00/smartpqi(4) on an HP DL325 EYPC system 
worked well under 13.* and a SATA SSD but is providing odd behavior 
under the 14-CURRENT 2022-11-23 RE snapshot.

The dmesg is blown with this incrementing error:

...
(probe0:smartpqi0:0:582:0): Down reving Protocol Version from 6 to 2?
(probe1:smartpqi0:0:583:0): Down reving Protocol Version from 6 to 2?
(probe0:smartpqi0:0:584:0): Down reving Protocol Version from 6 to 2?
...
(probe0:smartpqi0:0:1088:2): Down reving Protocol Version from 6 to 5?
pass0 at smartpqi0 bus 0 scbus0 target 64 lun 0
pass0:  Fixed Enclosure Services SPC-3 SCSI device
(quiets down)

dd'ing the 2022-11-23 Release Engineering VM raw snapshot to a device 
boots fine via USB and performs a growfs but booting to the HBA results 
in a panic when savecore it run, reporting:

panic: Segment size is not aligned


Workaround:

Set savecore_enable="NO" in rc.conf before booting.


Reproduction:

service savecore onestart


Cleanup: fsck / in single user mode and disable savecore as needed.


Possibly related?

Open (note savecore):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240145

Resolved with the same "Segment size is not aligned" panic:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259541
https://reviews.freebsd.org/D30182

Should I update that second PR? Have any suggestions for verifying the 
issue?

All the best,

Michael

From nobody Tue Nov 29 01:04:24 2022
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 4NLkdQ3vdfz4jS1d
	for ; Tue, 29 Nov 2022 01:04:42 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NLkdP5zvQz41Nw;
	Tue, 29 Nov 2022 01:04:41 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=qYuLGjXH;
	spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::636 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pl1-x636.google.com with SMTP id g10so11887775plo.11;
        Mon, 28 Nov 2022 17:04:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=fCDi4OyXwB+4eJqgJVWuqBymQJes4PgYHvG/51ImdN0=;
        b=qYuLGjXHj3pKsiEsOyz+3Udjpxv2b73xQK2e2PR6ieAjlLWYcpeAeMe2Sm6jLezXaI
         EnQp/1FRXryEodUsgi8RMhlF2jSoyjjrcIyhQFR+uguoKD5xFHScP3A9h1B92gOAa7pR
         /+n9eNVJF8JHR4xWHH9GhUWarD+aJD6y0RWJMvz9Tkw7ySRyomk8D4yBd37IPKHroAgI
         pCdnvsnyo68IkVvm+dufWf40Ivj2zXgJ8cBl0LiCbxgnTfkfB95ZHVWAGY3ZkkPjuSLS
         2jaLea2kyAUbYs1UxJsVzu7hMCGYLgltSq4dhhP5fzoPFXZ+vfeOaeaoc18HB205wCsR
         fozg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=fCDi4OyXwB+4eJqgJVWuqBymQJes4PgYHvG/51ImdN0=;
        b=FZRgH6mSnnHlcLpNHPMneNGmzzZ/7kuVhUShIerGvfKRyr+2sjVqUWo65vPEStFRui
         9Mxn6ZQqIxfntgbbr6Y10ia+CYJGgxZ6AkRN3qBf+BM4hJl06m0Z9yn6my+CSvGUgrx7
         XbS40++Mdy/AIxsRKM2XGtcdwWjhmoSifoaNgUfKaBBQ0BLRMZeZzkepP02q93314C8e
         CEqjsoUk26xyDeBUaF/A0e3GKEy/k2XvMxD0kgQuR3PDAocEXE1nLqef0IOrj5QE/5Nj
         wpGU25j8iagCBYF2Sk8nXdpw5YCrTeSYJmhe0GWoM8QrBQ4Zfh5WpI16pHM06rBkHbLK
         kqyw==
X-Gm-Message-State: ANoB5pm5aHPcjWhcLXY/QeuFdSbQ9lz/iUbcvQbpltBD35nnZQEYhl68
	Q1GbfYrovHfsTQcKo5gR39meW0l+h+cNMadWO3SbtNmv3HkSavY=
X-Google-Smtp-Source: AA0mqf7A7rXvLb2GLXp792bdbojKBZk+mMhrgKijpZ7IUxGOeBZDZAA3zqKL4tQa7gF7OYAPvaXwIPu/K6XPHdlIqlk=
X-Received: by 2002:a17:90b:3d90:b0:212:de1c:a007 with SMTP id
 pq16-20020a17090b3d9000b00212de1ca007mr64946533pjb.30.1669683877859; Mon, 28
 Nov 2022 17:04:37 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 
In-Reply-To: 
From: Rick Macklem 
Date: Mon, 28 Nov 2022 17:04:24 -0800
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: Alan Somers 
Cc: FreeBSD CURRENT , "Bjoern A. Zeeb" 
Content-Type: multipart/alternative; boundary="0000000000006e6e4805ee919271"
X-Spamd-Result: default: False [-3.92 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.92)[-0.921];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::636:from];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TAGGED_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NLkdP5zvQz41Nw
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--0000000000006e6e4805ee919271
Content-Type: text/plain; charset="UTF-8"

On Fri, Nov 25, 2022 at 9:06 PM Alan Somers  wrote:

>
>
> On Fri, Nov 25, 2022, 4:24 PM Rick Macklem  wrote:
>
>> Hi,
>>
>> bz@ has encouraged me to fiddle with the nfsd
>> so that it works in a vnet jail.
>> I have now basically done so, specifically for
>> NFSv4, since NFSv3 presents various issues.
>>
>> What I have not yet done is put global variables
>> in the vnet. This needs to be done so that the nfsd
>> can be run in multiple jail instances and/or in and
>> outside of a jail.
>> The problem is that there are 100s of global variables.
>>
>> I can see two approaches:
>> 1 - Move them all into the vnet jail. This would imply
>>     that all the sysctls need to somehow be changed,
>>     which would seem to be a POLA violation.
>>     It also implies a lot of stuff in the vnet.
>> 2 - Just move the global variables that will always
>>     differ from one nfsd to another (this would make
>>     the sysctls global and apply to all nfsds).
>>     This will keep the number of globals in the vnet
>>     smaller.
>>
>> I am currently leaning towards #2, put what do others
>> think?
>>
>> rick
>> ps: Personally, I don't know what use there is of
>>     running the nfsd inside a vnet jail, but bz@ has
>>     some use case.
>>
>
> This is super-awesome! Thank you so much! I've got a use case too.  I
> think it would be fine to leave most of the settings global,  like
> max_threads. But we should probably decide on a case by case basis .
>
The minthreads, maxthreads happen to be handled via nfsd command line
options, so
the sysctls are not needed and they can be set per-prison.
Most of the sysctls are for weird cases or tuning of the DRC. Since the DRC
is
only used for NFSv4.0 mounts and not NFSv4.1 or NFSv4.2 ones, tuning the DRC
should not usually be necessary.

I have left them global for now.

If anyone identifies one that needs to be set per-prison, I can move it into
the vnet.
If you want to see them all:
# sysctl -a | fgrep vfs.nfsd

I have put a first patch up on phabricator as D37519. Although I listed
three
people as reviewers, anyone is welcome to test/comment/review.
If you can't easily get the patch from phabricator, just email me and I'll
send it to you. I think it will apply cleanly to main and, maybe, stable/13.
You only need to build a kernel from patched sources to test it. There is a
change to rc.d/nfsd, which you only need in the prison's etc/rc.d/nfsd.

A very basic setup document (also definitely a work in progress) can be
found at...
https://people.freebsd.org/~rmacklem/nfsd-vnet-prison-setup.txt

Let me know if you test it or have other suggestions, rick
ps: Thanks everyone for your comments. If I have specific questions related
    to them, I'll post. Otherwise I am digesting them.

--0000000000006e6e4805ee919271
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Nov 25, 2022 at 9:06 PM Alan Somers &=
lt;asomers@freebsd.org> wrote=
:


On Fri, Nov 25, 2022, 4:24 PM Rick Macklem <rick.macklem@gmail.com> wrote=
:
Hi,

bz@ has encourage=
d me to fiddle with the nfsd
so t=
hat it works in a vnet jail.
I ha=
ve now basically done so, specifically for
NFSv4, since NFSv3 presents various issues.

What I =
have not yet done is put global variables
in the vnet. This needs to be done so that the nfsd
can be run in multiple jail instances and/or in=
 and
outside of a jail.
The problem is that there are 100s of glob=
al variables.

I can see two approaches:
1 - Move them all into the vnet jail. This would imply=

=C2=A0 =C2=A0 that all the sysct=
ls need to somehow be changed,
=
=C2=A0 =C2=A0 which would seem to be a POLA violation.
=C2=A0 =C2=A0 It also implies a lot of stuff in the v=
net.
2 - Just move the global var=
iables that will always
=C2=A0 =
=C2=A0 differ from one nfsd to another (this would make
=C2=A0 =C2=A0 the sysctls global and apply to all nf=
sds).
=C2=A0 =C2=A0 This will kee=
p the number of globals in the vnet
=C2=A0 =C2=A0 smaller.

I am currently leaning towards #2, =
put what do others
think?

rick
ps: Personally, I don=
't know what use there is of
=
=C2=A0 =C2=A0 running the nfsd inside a vnet jail, but bz@ has
=C2=A0 =C2=A0 some use case.

Th=
is is super-awesome! Thank you so much! I've got a use case too.=C2=A0 =
I think it would be fine to leave most of the settings global,=C2=A0 like m=
ax_threads. But we should probably decide on a case by case basis .
The minthreads, maxthreads happen to be handled via nfsd command l=
ine options, so
the sysctls are not needed and they can be set per-pris=
on.
Most of the sysctls are for weird cases or tuning of the DRC. Since=
 the DRC is
only used for NFSv4.0 mounts and not NFSv4.1 or NFSv4.2 one=
s, tuning the DRC
should not usually be necessary.

I have =
left them global for now.

If anyone identifies one that needs =
to be set per-prison, I can move it into
the vnet.
If you want to s=
ee them all:
# sysctl -a | fgrep vfs.nfsd

I have put a fi=
rst patch up on phabricator as D37519. Although I listed three
=

people a=
s reviewers, anyone is welcome to test/comment/review.=C2=A0
If you can&=
#39;t easily get the patch from phabricator, just email me and I'll
send it to y=
ou. I think it will apply cleanly to main and, maybe, stable/13.
You only need to bu=
ild a kernel from patched sources to test it. There is a
change to rc.d/nfsd, which =
you only need in the prison's etc/rc.d/nfsd.

A very basic setup document (also defin=
itely a work in progress) can be
found at...
https://people.freebsd.org/~rmacklem/nfsd-vnet-=
prison-setup.txt

Let me know if you test it or have other suggestions, rick
ps: Thanks everyo=
ne for your comments. If I have specific questions related
=C2=A0 =C2=A0 to them, I=
'll post. Otherwise I am digesting them.



--0000000000006e6e4805ee919271--

From nobody Tue Nov 29 17:10:03 2022
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 4NM8423X3cz4jJVL
	for ; Tue, 29 Nov 2022 17:10:42 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Received: from smtp052.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NM84107dYz4WXr
	for ; Tue, 29 Nov 2022 17:10:40 +0000 (UTC)
	(envelope-from freebsd@walstatt-de.de)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=WwR9BELb;
	spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:30) smtp.mailfrom=freebsd@walstatt-de.de;
	dmarc=none
Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by smtp5.goneo.de (Postfix) with ESMTPS id 9CC1D10A1E43;
	Tue, 29 Nov 2022 18:10:33 +0100 (CET)
Received: from hub1.goneo.de (localhost [127.0.0.1])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by hub1.goneo.de (Postfix) with ESMTPS id AC3DD10A1E99;
	Tue, 29 Nov 2022 18:10:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de;
	s=DKIM001; t=1669741831;
	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=Ju3NDDsnwgJIGct6Z+dGm11/ljBFh5SG1xVZ9Um2anI=;
	b=WwR9BELb42q67hl1XJx/ZxVqPYlVBM1rlkzniW4uE9yV/XG4hhc85g6G202XFFDMPSetSD
	J+8FrnZEnUDMM8a7OcfFUXSNOPssqa4C2QDvgqoSbUmVaUS0PpPjJ4hQdZ5kTrioDOXBOu
	9kYwe13zoRdzh2lqXVIs3v+fN1Tw3CuNHE6EGy2A6aRCVK37UyF/kwqTb12XdQLUvt550o
	0lIHWUKNNo4tFFVr0Grn95tBnhujgxxghvGLKlmbCR3lTaWTa94B23pk2/NafGdeqtlTCU
	0n/6+ghjRHt5OR6ObfSoqFDYguQrI0yEKJNYkeD7yB2hM10Rwqi7JS+tgeo2Tg==
Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-011-002-211.77.11.pool.telefonica.de [77.11.2.211])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by hub1.goneo.de (Postfix) with ESMTPSA id 126C910A1E96;
	Tue, 29 Nov 2022 18:10:31 +0100 (CET)
Date: Tue, 29 Nov 2022 18:10:03 +0100
From: FreeBSD User 
To: "Poul-Henning Kamp" 
Cc: Warner Losh , FreeBSD CURRENT
 
Subject: Re: CAM: extract HDD informations about failure/to fail?
Message-ID: <20221129181030.25299ff0@thor.intern.walstatt.dynvpn.de>
In-Reply-To: <202211272112.2ARLCnsk013242@critter.freebsd.dk>
References: <20221127161544.7dd1207c@thor.intern.walstatt.dynvpn.de>
	
	<202211272112.2ARLCnsk013242@critter.freebsd.dk>
Organization: walstatt-de.de
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-UID: 59d7b4
X-Rspamd-UID: d68f08
X-Spamd-Result: default: False [-2.40 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.995];
	R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from];
	ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[walstatt-de.de:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	HAS_ORG_HEADER(0.00)[];
	DMARC_NA(0.00)[walstatt-de.de];
	RCVD_COUNT_THREE(0.00)[4];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-Rspamd-Queue-Id: 4NM84107dYz4WXr
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

Am Sun, 27 Nov 2022 21:12:49 +0000
"Poul-Henning Kamp"  schrieb:

> --------
> Warner Losh writes:
> 
> > It close to impossible to isolate the drive making the noise.   
> 
> Use a long thin piece of hard wood as a stethoscope.
> 
> I keep a 30cm length of 6mm beech dowel in my tool-chest,
> but in a pinch you can use a pencil or the shaft from an
> art-brush.
> 
> Press one end agaist the little piece of cartilage which
> can close into your ear, and hold the other end against the suspect
> disk-drive, and you hear if there are any mechanical issues.
> 
> It also works for fans, motors, bikes etc.
> 

Awesome!
I'll try this nice idea.

Thanks and kind regards,

Oliver

-- 
O. Hartmann

From nobody Tue Nov 29 17:26:13 2022
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 4NM8Q11nMCz4jL9Q
	for ; Tue, 29 Nov 2022 17:26:17 +0000 (UTC)
	(envelope-from DKline@safarimontage.com)
Received: from mail1.bemta31.messagelabs.com (mail1.bemta31.messagelabs.com [67.219.246.113])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail1.bemta31.messagelabs.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NM8Q06jXLz4Ylc
	for ; Tue, 29 Nov 2022 17:26:16 +0000 (UTC)
	(envelope-from DKline@safarimontage.com)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=safarimontage.com;
	s=selectorML1; t=1669742776; i=@safarimontage.com;
	bh=Bi3xDxDXV2misn1wz6lcf9S9y0ypRH0aoe1exQq82TU=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	 Content-Type:Content-Transfer-Encoding:MIME-Version;
	b=jTIxleymcOLBEVVSBZxrJke8M0eGBOOIncU6GFkh3B7BVOoVSrWAZ2/RHdOOAZWrz
	 4qUASWBindCBO+X9jB5X8d508qQlYJCvRIhT/XSqXiB7OQykNBxYJCW244uJ4E4p5P
	 ra1E5cidlEHPFRXyVemfzBuKMXIt56VUCI+UhSQr+K3WU5O4E7uA1RZfZKaoWtD5K6
	 zdhmnUNV38JCeLi0mq7ly/JFObBgUb37ybp4JjKow5plBXF/acXQut0yL56I9YOUyx
	 nOHLFE080l1WAlVJezisPxpRqSjNFnGRGNLnP+IPaXnfRGFfBir0iWbrVkZCl6qx2T
	 T3yEU3Y+ngjAg==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFJsWRWlGSWpSXmKPExsWSoe+WprvdoS3
  Z4P51Tos5bz4wWXzs/M1o8XTrckaLD9/4HVg8Puz+yuox49N8Fo9P+yezeex//pU9gCWKNTMv
  Kb8igTXj443wgg6+il0LnrE1MH7g7WLk4mAUWMosce7xBVYIZxGrxP+FU6Gco4wSH18+YwNxW
  AQmMktcfXWJuYuRk0NIYD6TRNPqVJCEkMB9RonFh5czdjFycLAJaEvcPK0AUiMiECTRtfYvO4
  jNLBAgMbflBSuILSzgKDFh3mRmiBoniW9ntjNC2EYSc64vYwGxWQRUJdYdPAtm8wrESjz/vZg
  FYtc3RokbTyYygSQ4BVwlmiesAStiFBCT+H5qDRPEMnGJW0/mg9kSAgISS/acZ4awRSVePv7H
  ClFfLbH320dWiLisxKX53YwQtr3EgUtvoep9JV7umAQ1R05iVe9DFghbXmLaovfsELaMxIMb2
  8EhJCHwhFXi9dedrBDOThaJl/s/QlUZSMz7dgSq6pWIxLr+/6yg4GIW0JRYv0t/AqPeLCSHz0
  LIQIQVJaZ0P2SfBQ4MQYmTM5+wLGBkWcVoVpxaVJZapGtooJdUlJmeUZKbmJmjl1ilm6hXWqy
  bmlhcomuol1herJdaXKxXXJmbnJOil5dasokRmJRSipildzA+W/ZH7xCjJAeTkihvkm1bshBf
  Un5KZUZicUZ8UWlOavEhRg0ODoFrG1dfYJRiycvPS1WS4DW3B6oTLEpNT61Iy8wBJk6YUgkOH
  iUR3kkgY3iLCxJzizPTIVKnGHU5rmzbu5dZCGyGlDjvOZAZAiBFGaV5cCNgSfwSo6yUMC8jAw
  ODEE9BalFuZgmq/CtGcQ5GJWHeRDugKTyZeSVwm14BHcEEdESkGNgRJYkIKakGJv0S2bRlmUt
  eBWlpCjkvWGKp/0rQfbfC9tpri2/ObH3H/ujCPSXXvnXJz/7vrZ9QEPLtzpQzsybMnV7rYKkq
  Fps2IZNlFXtywynxb6/+Ld+0N1//T39ztUl6X9jEVzonPPUUoh79ebNjwlu2nueNtiLPDv9eX
  33y9dMvpTMtPvCHz7oje/CPFI/8dNPQEwKHUv+1V/BveZxZYhns/bGiNNaxuEBlzpMlNx0WHZ
  SpsN915faF1kcGxk0pnIGpPfplEVdla/XDnYOebI+Oy9GVmPG1d1+Vf/nx0oxs00qmg3tk0vf
  //yG2U2wOA+eFwxs4vV5Nu8XJqix2u/O8x5JtbyX3l5cu5ZiXck3n+2qXM0osxRmJhlrMRcWJ
  AG7QuBJdBAAA
X-Env-Sender: DKline@safarimontage.com
X-Msg-Ref: server-17.tower-684.messagelabs.com!1669742774!646772!1
X-Originating-IP: [104.47.70.102]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.101.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27420 invoked from network); 29 Nov 2022 17:26:15 -0000
Received: from mail-bn7nam10lp2102.outbound.protection.outlook.com (HELO NAM10-BN7-obe.outbound.protection.outlook.com) (104.47.70.102)
  by server-17.tower-684.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 29 Nov 2022 17:26:15 -0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=WKfo3HHZ/KBNykiiRTYyjz+szMURSQle5hrUXoioKGwFlVMTItccFgNET1Vh5YqzFb8x34lWBqIiMdfNbRWuICV8IUHrOF+eb8laiYvvr+sktl3k/0E/igf7i9EchTWGv/iIuV792As9ooq+IvydaSY2O8KcmReMox1FOVGIw/VXVgla37PZB8FfSo9a5zacIV7wXbnGZSeXeehoDe+iH2IReg5iA+x24Jhtwx6ls5j5hzAAbE24TX10rbFYnGq4WHbf235fUZtYDEaoXxXNOfeVDwnWJudIT3J2bRsB0MNxqVqsRuU+ocsTpFWN+o+4mDO0/sI6Kbr+rlQ7U0OA8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Bi3xDxDXV2misn1wz6lcf9S9y0ypRH0aoe1exQq82TU=;
 b=N2arz8tjDbAKasv6fIl/kpZhxzgtXpIfD1OHmfR9OcUbBEfRXJF8x7gopREiwolDdNHiliOnfaqym55CK2ZjC5k7/yX2anveWF+h6knPveCj0uP/2ul1s1TjAu0kxzcSnXPdOXbUJk+tE8AGwYY2WrhFXG36mKovq9IWuFWDqbA9Fujpkh4+za6rHPuuVDl2aXBl10mapF1wKygQGpd3/S+hUN+/yRDKj5LnQFG7BZDcOSYVFjBwKbAiVEC4IkI5mn/th+y9+ONLUSzLpatCFB2MhYpEh+K1v+RZHExFCoiLxueEu06vbEuO5GV+K9h8MrFA8hdB/VAYiEt3PmYCHA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=safarimontage.com; dmarc=pass action=none
 header.from=safarimontage.com; dkim=pass header.d=safarimontage.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=safarimontage.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Bi3xDxDXV2misn1wz6lcf9S9y0ypRH0aoe1exQq82TU=;
 b=qAYbJbaXaEESdk9PjHF+G3U7SE/GC0BI3QESlRWTDCu37mfyLNPBFuqCvY4PqKBw1AIQeFYNB3kvt62i2uSRdSvnnjqpzI3k/mc0Y8lkK/xhx4BBJ2zH9yDh7tcW8FGHoTrgRgOOq1RafOLsWu8C8RBfTlhSE3/3FTPj6z1T2ro=
Received: from CH2PR20MB3061.namprd20.prod.outlook.com (2603:10b6:610:2::27)
 by BLAPR20MB3825.namprd20.prod.outlook.com (2603:10b6:208:30c::17) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.17; Tue, 29 Nov
 2022 17:26:13 +0000
Received: from CH2PR20MB3061.namprd20.prod.outlook.com
 ([fe80::5a06:df75:7e5f:9bbf]) by CH2PR20MB3061.namprd20.prod.outlook.com
 ([fe80::5a06:df75:7e5f:9bbf%7]) with mapi id 15.20.5857.023; Tue, 29 Nov 2022
 17:26:13 +0000
From: Dale Kline 
To: FreeBSD User , Poul-Henning Kamp
	
CC: Warner Losh , FreeBSD CURRENT
	
Subject: RE: CAM: extract HDD informations about failure/to fail?
Thread-Topic: CAM: extract HDD informations about failure/to fail?
Thread-Index: AQHZBBWPkvFmBZdS/0apAT3XjQ6yM65WJfBQ
Date: Tue, 29 Nov 2022 17:26:13 +0000
Message-ID:
 
References: <20221127161544.7dd1207c@thor.intern.walstatt.dynvpn.de>
	
	<202211272112.2ARLCnsk013242@critter.freebsd.dk>
 <20221129181030.25299ff0@thor.intern.walstatt.dynvpn.de>
In-Reply-To: <20221129181030.25299ff0@thor.intern.walstatt.dynvpn.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CH2PR20MB3061:EE_|BLAPR20MB3825:EE_
x-ms-office365-filtering-correlation-id: 23ab171d-4aaa-4a7d-7ba5-08dad22ed044
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 OmC7+VS5nj3SKlxOBCzuCoTujYUhffj0WNfWLGYW1WO+ItEcCrFsllbl8cYW5XLY+Mf1RZMJOiODCshckyYrR64iegKn27pt1S6b4H96fiediQLeghEUYjNp24LuPDQLQE1pVF2htz0P45X39n/lFkPpoGht+g6Dqxuxpk0dh2FIAZk2uZfDht7Wpi5oxLnD/UPSwqpRZYUYCGS+PI6rrq5ZFfZvduX4vYlSNf/YNwnNtR1gSJT13lrHD4FWGRQvAVJu230/HEfQ/6W3Oh5n6bVH+sCJUjTZeqPbNjuSVNZWmYc9xYU3sAWSU9rikitEnFEiCqnHPr0UlDEicumZ1u+p3FLllNWAWcaE6W15oj9inON32MHIFxO31VIjvXxjBiZHe20jXGZf8YpeIVJ+GiXp2k6YqgeDFjrdUPdIQKXa0fWUISuq8T9NxlZgKhJyLLfyuoTfPS99J3TIAHFGQwlp4WsuvaaFA09IrF2bv14xur8gqUudTmD6MqC9VAHbvsIgdIikH2jkiliRACN+qD/KGhpDNOWzuLbo2sKXCFS/Ov6k0jurqoRUoxBTThBrr6vig0r6OGMNOiYge0fPJbkucV7NzDLXqidtRbWjYqtZs9V+cQUI/Gk6WC4cmWamyQyhMdU9hxNtEokMPOZM4sVAjj3VTAjfo7WhE+5f39gGzrZRUr8tLIYQKZQcN/nX
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH2PR20MB3061.namprd20.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(376002)(39830400003)(136003)(346002)(366004)(396003)(451199015)(83380400001)(33656002)(110136005)(6506007)(7696005)(71200400001)(9686003)(54906003)(55016003)(86362001)(38070700005)(122000001)(38100700002)(53546011)(186003)(52536014)(26005)(5660300002)(8936002)(478600001)(66446008)(316002)(66476007)(66556008)(41300700001)(66946007)(64756008)(76116006)(8676002)(2906002)(4326008);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?SElBRHZtbXNGU0hwRm1WWkpMWGlRV0VucFRWeGNSUHFQaTBueUwwekxwYWh5?=
 =?utf-8?B?Z20yQUxObnQ5anhuRDVtVjdCTkRxeWFPaVpRSDBUempmR3FsckhVQXZ5SzVS?=
 =?utf-8?B?ajlPOHZYTmV2MktHcUhKalhsQWMrVnRUQ1FJRDN3aEJZeHY2M1N2MC8vQ1NT?=
 =?utf-8?B?Y09HVUFlSmd0d3ZZZzliWFFJQTBCbjBDOFFUVURYVVRxVDRsaEkyaFpOYmFQ?=
 =?utf-8?B?ZVZBYUNTRGR3OUJRTFZubVpUNjJnMHhVbFJBdUVKc0xhUnBmYUpwZ1YrdU5w?=
 =?utf-8?B?a2w2SkRwSnlSZHVmZXA3L1dxTEtrZjc0dlY3S0JVeDdkOGFsY0JNeUp3ZWEx?=
 =?utf-8?B?SFVzbFBUMzlPMHFwaXEvSWhNQVNoTWtrazRkdG13WTRpb1FkNTRlTDRDU1Ju?=
 =?utf-8?B?TnBpVzVIdHJWaDlqOWdRYU1Jb1JWMzZ5VUFwWWRDVFJ6YkwxTnF5WDRxcktR?=
 =?utf-8?B?bC9pNWRFRGhwRkYwbjVQRFA2WjZqVE95a01LNWlyV3Y5cnBaZzJRQ0cxQ3pY?=
 =?utf-8?B?Ym9RWTdvZFRIUEwrd2tyeWxEdzZsMWY0aVhtcCtZdUtYNU92c21nc09SSE5E?=
 =?utf-8?B?aUlqQ3RKaTJ6U1M3NU5QVUNCWXEvL3ZWUGFlR0dTQnF0MjFya01ZcTlLVkl3?=
 =?utf-8?B?WEhINkhFUVhlNjlyRXFERWlicmZTRDJzVnR1RE9sLzcwTE04dW10Y2NGUGpZ?=
 =?utf-8?B?QkErTEJxbU1tVWpBTHBaY2xlOS9WaDVBd2JmSXJzeGZHaUQ0SVBOVm8vMmpR?=
 =?utf-8?B?RkFtNHBuSzdrU1M0a3Y2VXpyVXhxR0pKcXRnc3hYTk5EcXg4YjR5M2lHMmZY?=
 =?utf-8?B?dndmVkNxWmZ5aWo4aXdjc1Y3dHR1eVVDb3E1R1NTK1l2SDBhbS9Sd0pOOUhU?=
 =?utf-8?B?a2NmU0ZXRXErV01zbThqajduTUNtOUFROXJWclZma2JCWW42MTI0L0I5NU9r?=
 =?utf-8?B?MDFBWE5oSUFiREtXUlNZaEdKQ3p3NFp3ckdLdUUyZkNzWWc4bmN0NWNYcm9q?=
 =?utf-8?B?Y0RON1NnSTR4S0pFNFQ4TG8yR2h1a2dXRGxWYjlDNTl2NmpyZEpIZld5bjZX?=
 =?utf-8?B?eDVvbmpDZmJROUJVaGY3SWRpZ2N6RjRTT3JpNzVDVFl3dVZScnR6Uk9YVTcw?=
 =?utf-8?B?RFJrWW8wQ1lPTENLYmhZRE1lVHFkRTRoU01aQTVRZjBwcnJtTjNxcUlxejRB?=
 =?utf-8?B?THg1Y2tDcnpKK3NNS0ExbDFORzVmQjhHdVpQeGFPcWw3UjdURXhwamp3S1gv?=
 =?utf-8?B?TjF3U3g0bExDelpDSEgvTCt5eGZOelAyVjRTT0h5NGFYcmNPY2kyVHF0UXJL?=
 =?utf-8?B?WUtqQnM2b0svY0dvNys4cE9QZW55NmZuSzNIZVdFSEtDQ05kTEF3WWFDL1M1?=
 =?utf-8?B?YVI0MkFSVkZLZUNVM2FCR1paYUY0SmdyeGZQSkpiU1JUR21CRldjVXJLNHdm?=
 =?utf-8?B?QXUwUm9ZMUhZTEJOWHpFbVZLTXVjSXVOQkxwWjN1UkRveXhIRWZEazQ2a2RK?=
 =?utf-8?B?SmhodzFIeGVTRUZ1RDJWd3lsVUo1VnNGd2J0TUh3TDhrWkwxRm1RQm11UXRX?=
 =?utf-8?B?VlhUNzVGNC9QZnlCUnJtTE1hTEh3dTNYZGNVM0dIYzB0OXc3MUl4STQ0bzNx?=
 =?utf-8?B?UkZjcWZ4Q2pyZTdxWjgyN0xabUFBeCtZckhnbFdXTzJyWHJ4dzdXQ1ljZzdE?=
 =?utf-8?B?U2dDMXFwKzNoUHlyWk5XNG1BN2FCYXBOS2dJdXhINU9sMGxvQTd2bEN2S3po?=
 =?utf-8?B?TUxjTm5PMTVWU1p5c2xNbWlEQ2p0ZUdWZVh6enZ2dW5pS2IrN3Nrei9aZ29k?=
 =?utf-8?B?M1VWME8yQ295b3M4bFFScFJnRGVKYVVxY1pWdFNRSlVyWXlNMWd1eUVjNDVu?=
 =?utf-8?B?ZlE3U2hPQTBvejgreVNveExEUjFkMVhLVUpWSjEvZHdYRFROY29yUFpTNlJq?=
 =?utf-8?B?amVTR3o3R0c1bDhtU3RhckdVLy9zc2lBLzk2ZEN0WGdDRGJiNTFSUXlVSGhJ?=
 =?utf-8?B?Wkw3U01HbXlwb3YvN2s2S01ZRk1tdEt1VDdMdE4vZlJPOWpyMWRQalVNWllp?=
 =?utf-8?B?TnZKTTEwUVJJa1Vpd3R4bVY5VDBWSE1ndWNTVzdzNVlZVnpkcHFSY09aRUxu?=
 =?utf-8?Q?lXFRQ0IPX5dTfqv7++99p7hOA?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	=?utf-8?B?TlJFMVhrQ0lMS1poNmQzTDJ2MFRtdXl1OE8xR08zcGFXcU94aHBlSXJXZ0RH?=
 =?utf-8?B?SUw2azA0MGZqbW54QmRMSzFkcWJ6VmFuQ1ByWERwWU8zYUErbFpnL2F1OWd0?=
 =?utf-8?B?V1d6TlJqRCt5RERjMjVPMzYzQnVVWFd0SVB3a3pPMmUrVjJwOVJ2M0thOThs?=
 =?utf-8?B?c0hLQXJjSFBSU29peW93SS9SWG9iRHlvQUNpL0RRanozZWxpblB4c3RuWUo2?=
 =?utf-8?B?OGpEendEU0czSW0xUjNVSGFZMHU3S1k3MUN1VHN3NDJKajFiczhnVHMzdjZw?=
 =?utf-8?B?ZUl5MVVEUUZaaFJLSVVBWGUwUmFaWlBCcnN0eS85LzA3NXRoZzFBb0xuQzF2?=
 =?utf-8?B?cnJkd21yYUhuMGU2ckJTREJPRDUwdnpYYVpVM0NFeFJpaFZpRGpuTG1jNVhK?=
 =?utf-8?B?WGpFYzdtRW1FOU0rcVpORnM4OFlobHNEVXg3UDdyaEhjcTQ2US9GLy9QT25B?=
 =?utf-8?B?MVFaZ2RjVVdST3VNZTdkNkorOVVqcTZ4RDYzemZEMzlxZnVqN2JkZHFMZlNk?=
 =?utf-8?B?WHpESTIxNFJ5ZmhUbldDMEpoZXlpcEkzUzJEd0IrcXRQbnZtSnVxSTFkQTAy?=
 =?utf-8?B?Sm5ZSW94YTVFdGFkMkEzY2lWV1ZSa2NKLzJwWlZ3U2FURXBRVGZvSTNCU3Zl?=
 =?utf-8?B?ZDNiTEdwQjdlbzk5MDJRTkNYQ1haVm9CZDFFdEExMW1lYkxOWk1aUkY3OUMz?=
 =?utf-8?B?RHgvVkdiV2pzOTVqTjJLQjNydzlWcS9kaUlxbEJSSFozQjE5U0dxS05BaThT?=
 =?utf-8?B?cGFEbDQ4OThWNDNyZVJoU0RnczRyUGR6Y1FmSkpmbXRMTzQ2bysxWTB6RnFT?=
 =?utf-8?B?ODlDRVU4b2VERVVSL3FJT05maExBbHpWMGNweDgxU2ZYblRaR1NDTEs0bjFp?=
 =?utf-8?B?T0xFcG41M2dDV0dBV3hSMXJoa0RSTzg1ZjdUeDh5alJORnFtank5SXFGaEJD?=
 =?utf-8?B?R01WZmF6bkhpVkRxMndWK1lUM1VFeEtwSU40UjVtS2NUN3JNRFpwNjdwOTN5?=
 =?utf-8?B?S1FZT2lBRnFsZmJUN2dWQkNDOWlvS2x3RE9MRStEZUhUOVFvOHJMRmFZeFhy?=
 =?utf-8?B?SGIwQ2RjM2paa1BFWGxGUWhMcFQ1RjlDSmRtTmh0OStCeVNIN3o4cTY2TW1Y?=
 =?utf-8?B?aWlYY3ZEeWdKQ1YwYjB2Y3Q4aFIrd3JwcVl1VUpHK2t3OXVnaXZuNFZaS1Bh?=
 =?utf-8?B?UUhjLzgya1VvZ3dtMDQvNmh3SG5Qd1VFWEZlQWt0bHhKVG1YM3ArK1lMS1c2?=
 =?utf-8?Q?5jI3GW6/p5Iaxhk?=
X-OriginatorOrg: safarimontage.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR20MB3061.namprd20.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 23ab171d-4aaa-4a7d-7ba5-08dad22ed044
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2022 17:26:13.0511
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32075e82-a919-45da-88fa-a3233202088f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: JbG0W/VmriVcc9ijBjM6RhQP4rZ3L8lB5uVobrce0gu5bWOYGH7Kexa//8YBWjM6syuqE91IQLOWhmU6f57lM5rdCsAgFZRh1hppce1Xxuw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR20MB3825
X-Rspamd-Queue-Id: 4NM8Q06jXLz4Ylc
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:14618, ipnet:67.219.246.0/24, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

QW55IGdvb2QgYXV0byBtZWNoYW5pYyBrbm93cyB0aGlzICdtYWtlc2hpZnQnIHN0ZXRob3Njb3Bl
IGhhcyBiZWVuIGluIHVzZSBmb3IgbWFueSB5ZWFycy4gIEJ1dCB0aGlzIGlzIGEgZ29vZCBpZGVh
IGZvciBtb2Rlcm4gbW90b3JzIHRvby4uLiAg8J+YiiAgIEkgYWx3YXlzIHVzZWQgYSBsb25nIHNj
cmV3ZHJpdmVyIHdpdGggdGhlIGhhbmRsZSBlbmQgdG8gbXkgZWFyLg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KRnJvbTogb3duZXItZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnIDxv
d25lci1mcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmc+IE9uIEJlaGFsZiBPZiBGcmVlQlNEIFVz
ZXINClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI5LCAyMDIyIDEyOjEwIFBNDQpUbzogUG91bC1I
ZW5uaW5nIEthbXAgPHBoa0BwaGsuZnJlZWJzZC5kaz4NCkNjOiBXYXJuZXIgTG9zaCA8aW1wQGJz
ZGltcC5jb20+OyBGcmVlQlNEIENVUlJFTlQgPGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZz4N
ClN1YmplY3Q6IFJlOiBDQU06IGV4dHJhY3QgSEREIGluZm9ybWF0aW9ucyBhYm91dCBmYWlsdXJl
L3RvIGZhaWw/DQoNCkFtIFN1biwgMjcgTm92IDIwMjIgMjE6MTI6NDkgKzAwMDANCiJQb3VsLUhl
bm5pbmcgS2FtcCIgPHBoa0BwaGsuZnJlZWJzZC5kaz4gc2NocmllYjoNCg0KPiAtLS0tLS0tLQ0K
PiBXYXJuZXIgTG9zaCB3cml0ZXM6DQo+IA0KPiA+IEl0IGNsb3NlIHRvIGltcG9zc2libGUgdG8g
aXNvbGF0ZSB0aGUgZHJpdmUgbWFraW5nIHRoZSBub2lzZS4gICANCj4gDQo+IFVzZSBhIGxvbmcg
dGhpbiBwaWVjZSBvZiBoYXJkIHdvb2QgYXMgYSBzdGV0aG9zY29wZS4NCj4gDQo+IEkga2VlcCBh
IDMwY20gbGVuZ3RoIG9mIDZtbSBiZWVjaCBkb3dlbCBpbiBteSB0b29sLWNoZXN0LCBidXQgaW4g
YSANCj4gcGluY2ggeW91IGNhbiB1c2UgYSBwZW5jaWwgb3IgdGhlIHNoYWZ0IGZyb20gYW4gYXJ0
LWJydXNoLg0KPiANCj4gUHJlc3Mgb25lIGVuZCBhZ2Fpc3QgdGhlIGxpdHRsZSBwaWVjZSBvZiBj
YXJ0aWxhZ2Ugd2hpY2ggY2FuIGNsb3NlIA0KPiBpbnRvIHlvdXIgZWFyLCBhbmQgaG9sZCB0aGUg
b3RoZXIgZW5kIGFnYWluc3QgdGhlIHN1c3BlY3QgZGlzay1kcml2ZSwgDQo+IGFuZCB5b3UgaGVh
ciBpZiB0aGVyZSBhcmUgYW55IG1lY2hhbmljYWwgaXNzdWVzLg0KPiANCj4gSXQgYWxzbyB3b3Jr
cyBmb3IgZmFucywgbW90b3JzLCBiaWtlcyBldGMuDQo+IA0KDQpBd2Vzb21lIQ0KSSdsbCB0cnkg
dGhpcyBuaWNlIGlkZWEuDQoNClRoYW5rcyBhbmQga2luZCByZWdhcmRzLA0KDQpPbGl2ZXINCg0K
LS0NCk8uIEhhcnRtYW5uDQoNCg==

From nobody Tue Nov 29 21:20:13 2022
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 4NMFc92hJhz4jmmd
	for ; Tue, 29 Nov 2022 21:20:25 +0000 (UTC)
	(envelope-from sobomax@sippysoft.com)
Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NMFc83gvKz3PpG
	for ; Tue, 29 Nov 2022 21:20:24 +0000 (UTC)
	(envelope-from sobomax@sippysoft.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of sobomax@sippysoft.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=sobomax@sippysoft.com;
	dmarc=none
Received: by mail-yb1-f172.google.com with SMTP id z192so19192984yba.0
        for ; Tue, 29 Nov 2022 13:20:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=uY8o9set+a3RAQqpgRONuwAX7NLbH7NeY4Qd6vX6iog=;
        b=qQCLcAfN5I2NH1BRz/qrlaDcLFSZ89ju9vTuyFBLZP0dhPj7TS4mYUM0I7EStFPIku
         g4f9KLFsZtoupznti1q3dNtNAECg1BN+xCqVVxABRtrEJz05TJk+UH5gv8G0Dk8HJAys
         4Ka51m87AAZbmXUVtMn3ylU5+J8Q5IsTehLWrXgNKnDiwxnUD1EeZkelUxyMHJcACpbi
         PYKZMKCsJdzOJlmrz5PbHf2AtIz3HKzeyXw6Zw084kUi6pTlvVVIPelSkIYdrhHwOb+j
         zXnfoOd48jxmhwXj7yrJlvhUKDJCwdXvF8dEHG2iusOJh+khzrT7VffRkVVXnM31xzuS
         eGGA==
X-Gm-Message-State: ANoB5pnbgDlVO0wYgNyvMU7+EYgQWexAG+GzOshES/JD7ojt+f/EwdEM
	F4QuAtomfY6KklWdxx0MtJpUJ2xydpYJ426pEKGzQsVMY6o=
X-Google-Smtp-Source: AA0mqf5CB+wkex6iWE4FukNaqIGnBmVmvrqx3Trt4Cja11hLmSymgNbxJqInINZSHu4umbVk0i9x5RGTqameeSMwTgw=
X-Received: by 2002:a25:cfd6:0:b0:6f9:1448:d55c with SMTP id
 f205-20020a25cfd6000000b006f91448d55cmr4279360ybg.257.1669756823406; Tue, 29
 Nov 2022 13:20:23 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <20221127161544.7dd1207c@thor.intern.walstatt.dynvpn.de>
In-Reply-To: <20221127161544.7dd1207c@thor.intern.walstatt.dynvpn.de>
From: Maxim Sobolev 
Date: Tue, 29 Nov 2022 13:20:13 -0800
Message-ID: 
Subject: Re: CAM: extract HDD informations about failure/to fail?
To: FreeBSD User 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000521fce05eea28e80"
X-Spamd-Result: default: False [0.35 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	NEURAL_SPAM_LONG(0.70)[0.705];
	NEURAL_HAM_MEDIUM(-0.36)[-0.357];
	FORGED_SENDER(0.30)[sobomax@freebsd.org,sobomax@sippysoft.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ARC_NA(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.172:from];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_NEQ_ENVFROM(0.00)[sobomax@freebsd.org,sobomax@sippysoft.com];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[sobomax];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.219.172:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	DMARC_NA(0.00)[freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NMFc83gvKz3PpG
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

--000000000000521fce05eea28e80
Content-Type: text/plain; charset="UTF-8"

Perhaps if you log r/w queue length for all 4 drives with a reasonable
interval (say 1 second) under the load using gstat(8) and plot all 4 as
function of time on the same graph you should have no problem to visually
identify the culprit(s). At least that's how I would do it.

-Maksym

On Sun, Nov 27, 2022, 7:15 AM FreeBSD User  wrote:

> Hello,
>
> well, the aim of my post sounds strange, but I'm serious.
> Background: I run at home a 14-CURRENT based server with a ZFS volume
> (RAIDZ) comprised from
> 4x 4 TB HDD. A couple of days I had to exchange the HGST NAS drives since
> one got a permanent
> SMART error. So all HDDs have been replaced by now with four times Seagte
> IronWolfe Pro 4TB
> drives. So far, so good.
> Now I face a weird sound sourcing at one of the new HDDs. The box is
> supposed to be a heavy
> duty poudriere build facility, so the drives are up 24/7. It seems that
> one (or even more)
> drives emitt a weird sound like the spindle motor is loosing for a
> fraction of a second power
> and spiining up the the drive again. Searching the net reveals that at
> least one Seagate
> customer did have the same issue and he provided an audio file of that
> very weird sound, to be
> found here:
>
> Post at reddit:
>
> https://www.reddit.com/r/techsupport/comments/sca6al/seagate_ironwolf_pro_making_weird_noise/
>
> and herin the post of the audio file:
>
>  https://www.mediafire.com/file/x3le816qsakiff9/Hdd.mp4/file
>
> I checked S.M.A.R.T for any unusual data, but everything is fine. The
> values for
>
> Power_Cycle_Count
> Power-Off_Retract_Count
> Start_Stop_Count
>
> seem all within a reasonable range compared to the life time in hours (did
> some simple
> statistsics ), nothing looks unusual.
>
> Also, the advanced view onto each drive via
>
> smartctl -x
>
> doesn't give me any hint of a power failure as a source for the noise.
>
> So, big question here is: the drives are attached to a HBA, LSI3008 based
> SAS9300-8i. Is it
> possible to retrieve via CAM more health paramteres than those gathered by
> SMART/smartmontools
> and if the answer is yes, how can this be achieved?
> It close to impossible to isolate the drive making the noise. My guts tell
> me to RMA the
> supposed to be faulty drive and not to wait until it dies from "spindle
> motor desease" or
> something that is the source for the noises.
>
> Thanks in advance,
>
> oh
>
>
> --
> O. Hartmann
>
>

--000000000000521fce05eea28e80
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Perhaps if y=
ou log r/w queue length for all 4 drives with a reasonable interval (say 1 =
second) under the load using gstat(8) and plot all 4 as function of time on=
 the same graph you should have no problem to visually identify the culprit=
(s). At least that's how I would do it.

-=
Maksym

On Sun, Nov 27, 2022, 7:15 AM FreeBSD User <freebsd@walstatt-de.de> wrote:
Hello,



well, the aim of my post sounds strange, but I'm serious.

Background: I run at home a 14-CURRENT based server with a ZFS volume (RAID=
Z) comprised from

4x 4 TB HDD. A couple of days I had to exchange the HGST NAS drives since o=
ne got a permanent

SMART error. So all HDDs have been replaced by now with four times Seagte I=
ronWolfe Pro 4TB

drives. So far, so good.

Now I face a weird sound sourcing at one of the new HDDs. The box is suppos=
ed to be a heavy

duty poudriere build facility, so the drives are up 24/7. It seems that one=
 (or even more)

drives emitt a weird sound like the spindle motor is loosing for a fraction=
 of a second power

and spiining up the the drive again. Searching the net reveals that at leas=
t one Seagate

customer did have the same issue and he provided an audio file of that very=
 weird sound, to be

found here:



Post at reddit:

=C2=A0https://www.reddit.com/r/techsupport/comments/sca6al/seagate_ir=
onwolf_pro_making_weird_noise/



and herin the post of the audio file:



=C2=A0https://www.mediafire.co=
m/file/x3le816qsakiff9/Hdd.mp4/file



I checked S.M.A.R.T for any unusual data, but everything is fine. The value=
s for 



Power_Cycle_Count

Power-Off_Retract_Count

Start_Stop_Count



seem all within a reasonable range compared to the life time in hours (did =
some simple

statistsics ), nothing looks unusual.



Also, the advanced view onto each drive via 



smartctl -x



doesn't give me any hint of a power failure as a source for the noise.<=
br>


So, big question here is: the drives are attached to a HBA, LSI3008 based S=
AS9300-8i. Is it

possible to retrieve via CAM more health paramteres than those gathered by =
SMART/smartmontools

and if the answer is yes, how can this be achieved?

It close to impossible to isolate the drive making the noise. My guts tell =
me to RMA the

supposed to be faulty drive and not to wait until it dies from "spindl=
e motor desease" or

something that is the source for the noises.



Thanks in advance,



oh





-- 

O. Hartmann






--000000000000521fce05eea28e80--

From nobody Tue Nov 29 22:00:46 2022
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 4NMGVz5PQXz4hdVp
	for ; Tue, 29 Nov 2022 22:00:59 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NMGVz0j0Qz3ljH
	for ; Tue, 29 Nov 2022 22:00:59 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ed1-x532.google.com with SMTP id v8so21691958edi.3
        for ; Tue, 29 Nov 2022 14:00:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=1ezV7Bu4w8wK2izMs3NT0aoY1h+9d0E4C5kv7awzDl4=;
        b=Sf/y3+eizZj3EN33b7/wz5I2Vj8m7M6xyYRvefZSljT7vzb3WJ1mLUUNTTqK04U41F
         OVK4CCgrZ4UgWrwh2TaUruVuyzer6fg434+EsXH/A2SgJeHygjYFR451KG1N/I4vQOLq
         c/gkVnj+Z4HEH/8FsHgMl08FNxGiVkdhp46vCwBD84HBmjO5P0EBkUwnoZIZpd4yDmfK
         iei/HzMzM2EPUuH0DRHfMH0RMJmM+Q/19ak0DbHNWwb+Z/z7fbEdhcVbsm1DXSvfj8/M
         UwV5ca1l5ue9U5hbHpbtkYnf5ZmBjyZQiAuBuN1kGsuUJ0J2EeB8e4hZ9uSwStqCVZ2J
         Pc0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=1ezV7Bu4w8wK2izMs3NT0aoY1h+9d0E4C5kv7awzDl4=;
        b=uOix+VgG+Y+OE6CcbnoTnl6OhE5gmfGU07s3vxc9kotpitiM1c/+9bREUtIGoo8RhW
         rpskwA/ZRgFPU8rZ8Lh5BW47ilI+987/sywnAUZSeeFrNinwWhmk/TXqY5B8k3RPOUxV
         4gjAlwmG+7zQGMmH2AOXa0gb3aSvDeV39i48u3+YHdRgcor2mU09JHPzS5jMR86ty1qy
         wBX5trN/eRlyO7SCr+wJQjTw+ATSoEwLBZAzSrVWQ1VrI938yeizllEeRNWuXYjrMPmb
         ODj5VNpdVoQ/N9tctGghQiQWYKg+0ET2HLTaWMdp3J5BB1ES6eEpDnpIhOgeO7pLzZ17
         2N4w==
X-Gm-Message-State: ANoB5plbcncsItPOUySb/B87ByGt+rtuOAAIrRitp/KtRPKqrXdDeSe+
	/UF50OxXZ2cSmz/BqTknXf7HqVFgy0iC/ZTqBmhVKg==
X-Google-Smtp-Source: AA0mqf6wR7xfHoMbBgYqE0hQNPPZ/qYeXnQhfLKmswQ+YZR9tPe1wvyF6jMesHCQAiIYOilNFiCxPTqMH1Gl/ROUpVY=
X-Received: by 2002:aa7:d85a:0:b0:46b:81a8:1ff6 with SMTP id
 f26-20020aa7d85a000000b0046b81a81ff6mr4537646eds.174.1669759257404; Tue, 29
 Nov 2022 14:00:57 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <20221127161544.7dd1207c@thor.intern.walstatt.dynvpn.de> 
In-Reply-To: 
From: Warner Losh 
Date: Tue, 29 Nov 2022 15:00:46 -0700
Message-ID: 
Subject: Re: CAM: extract HDD informations about failure/to fail?
To: Maxim Sobolev 
Cc: FreeBSD User , FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="0000000000006601b005eea31fb0"
X-Rspamd-Queue-Id: 4NMGVz0j0Qz3ljH
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--0000000000006601b005eea31fb0
Content-Type: text/plain; charset="UTF-8"

Average Latency would also do the trick.

Warner

On Tue, Nov 29, 2022 at 2:20 PM Maxim Sobolev  wrote:

> Perhaps if you log r/w queue length for all 4 drives with a reasonable
> interval (say 1 second) under the load using gstat(8) and plot all 4 as
> function of time on the same graph you should have no problem to visually
> identify the culprit(s). At least that's how I would do it.
>
> -Maksym
>
> On Sun, Nov 27, 2022, 7:15 AM FreeBSD User  wrote:
>
>> Hello,
>>
>> well, the aim of my post sounds strange, but I'm serious.
>> Background: I run at home a 14-CURRENT based server with a ZFS volume
>> (RAIDZ) comprised from
>> 4x 4 TB HDD. A couple of days I had to exchange the HGST NAS drives since
>> one got a permanent
>> SMART error. So all HDDs have been replaced by now with four times Seagte
>> IronWolfe Pro 4TB
>> drives. So far, so good.
>> Now I face a weird sound sourcing at one of the new HDDs. The box is
>> supposed to be a heavy
>> duty poudriere build facility, so the drives are up 24/7. It seems that
>> one (or even more)
>> drives emitt a weird sound like the spindle motor is loosing for a
>> fraction of a second power
>> and spiining up the the drive again. Searching the net reveals that at
>> least one Seagate
>> customer did have the same issue and he provided an audio file of that
>> very weird sound, to be
>> found here:
>>
>> Post at reddit:
>>
>> https://www.reddit.com/r/techsupport/comments/sca6al/seagate_ironwolf_pro_making_weird_noise/
>>
>> and herin the post of the audio file:
>>
>>  https://www.mediafire.com/file/x3le816qsakiff9/Hdd.mp4/file
>>
>> I checked S.M.A.R.T for any unusual data, but everything is fine. The
>> values for
>>
>> Power_Cycle_Count
>> Power-Off_Retract_Count
>> Start_Stop_Count
>>
>> seem all within a reasonable range compared to the life time in hours
>> (did some simple
>> statistsics ), nothing looks unusual.
>>
>> Also, the advanced view onto each drive via
>>
>> smartctl -x
>>
>> doesn't give me any hint of a power failure as a source for the noise.
>>
>> So, big question here is: the drives are attached to a HBA, LSI3008 based
>> SAS9300-8i. Is it
>> possible to retrieve via CAM more health paramteres than those gathered
>> by SMART/smartmontools
>> and if the answer is yes, how can this be achieved?
>> It close to impossible to isolate the drive making the noise. My guts
>> tell me to RMA the
>> supposed to be faulty drive and not to wait until it dies from "spindle
>> motor desease" or
>> something that is the source for the noises.
>>
>> Thanks in advance,
>>
>> oh
>>
>>
>> --
>> O. Hartmann
>>
>>

--0000000000006601b005eea31fb0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Average Latency would also do the trick.
Warner

On Tue, Nov 29, 2022 at 2:20 PM Maxim Sobolev <sobomax@freebsd.org> wrote:
Perhaps if you log r/w queue length=
 for all 4 drives with a reasonable interval (say 1 second) under the load =
using gstat(8) and plot all 4 as function of time on the same graph you sho=
uld have no problem to visually identify the culprit(s). At least that'=
s how I would do it.

=

-Maksym

<=
div class=3D"gmail_quote">
On Sun, Nov=
 27, 2022, 7:15 AM FreeBSD User <freebsd@walstatt-de.de> wrote:
Hello,



well, the aim of my post sounds strange, but I'm serious.

Background: I run at home a 14-CURRENT based server with a ZFS volume (RAID=
Z) comprised from

4x 4 TB HDD. A couple of days I had to exchange the HGST NAS drives since o=
ne got a permanent

SMART error. So all HDDs have been replaced by now with four times Seagte I=
ronWolfe Pro 4TB

drives. So far, so good.

Now I face a weird sound sourcing at one of the new HDDs. The box is suppos=
ed to be a heavy

duty poudriere build facility, so the drives are up 24/7. It seems that one=
 (or even more)

drives emitt a weird sound like the spindle motor is loosing for a fraction=
 of a second power

and spiining up the the drive again. Searching the net reveals that at leas=
t one Seagate

customer did have the same issue and he provided an audio file of that very=
 weird sound, to be

found here:



Post at reddit:

=C2=A0https://www.reddit.com/r/techsupport/comments/sca6al/seagate_ir=
onwolf_pro_making_weird_noise/



and herin the post of the audio file:



=C2=A0https://www.mediafire.co=
m/file/x3le816qsakiff9/Hdd.mp4/file



I checked S.M.A.R.T for any unusual data, but everything is fine. The value=
s for 



Power_Cycle_Count

Power-Off_Retract_Count

Start_Stop_Count



seem all within a reasonable range compared to the life time in hours (did =
some simple

statistsics ), nothing looks unusual.



Also, the advanced view onto each drive via 



smartctl -x



doesn't give me any hint of a power failure as a source for the noise.<=
br>


So, big question here is: the drives are attached to a HBA, LSI3008 based S=
AS9300-8i. Is it

possible to retrieve via CAM more health paramteres than those gathered by =
SMART/smartmontools

and if the answer is yes, how can this be achieved?

It close to impossible to isolate the drive making the noise. My guts tell =
me to RMA the

supposed to be faulty drive and not to wait until it dies from "spindl=
e motor desease" or

something that is the source for the noises.



Thanks in advance,



oh





-- 

O. Hartmann








--0000000000006601b005eea31fb0--

From nobody Wed Nov 30 00:21:28 2022
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 4NMKdL0DzLz4hyh7
	for ; Wed, 30 Nov 2022 00:21:42 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NMKdK07tsz44Lf;
	Wed, 30 Nov 2022 00:21:41 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=a94iGDIV;
	spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::430 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pf1-x430.google.com with SMTP id 21so2173876pfw.4;
        Tue, 29 Nov 2022 16:21:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=uWP0laZ14Jnym5vhvrGwrmkRsZWD7JneHuGU4tC7Beo=;
        b=a94iGDIVGByJSjsBOvaZ1yZ2tt4o68DnD31s+hvDbQZH/8oiac8JHVoAOwt5qp9umy
         VbxFs8XEudYvbdlAmAw38gXJ8JHg4P+btTO4KuhRIU7cbiYlCpsu1xmSYaE9kJe9AgaN
         c8Wrssd7nOOTkMH6UIoNpuvpuXLe1VGmAFx/TL9jrXrQgsyVFFrNB8wxfDZ166ZLMW+A
         lthpO2/2U63Us0Zz/R9Cq0Kpt0IsLuInsg4XOoX1fSIwLnTt1FpzHqPAkgtgUjnJ6vo2
         JjRBNMUGCjtcrhn4GOGbFVibgk/iUERbn6TW9aiUmqHIC/uDtLbaGd1ezSSzhQw5xt/7
         /dxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=uWP0laZ14Jnym5vhvrGwrmkRsZWD7JneHuGU4tC7Beo=;
        b=ZSDu251bkw8lYaFwPphsD1171YlnaJexG4N2OEYBBKQmbkbDn4xVqj9J1pEo82Zw/D
         /QSK2v1LpusPi4jPWeRurOr91qUnMWm38FrvpVF9oWWJOf9PrbIwbYkepFo11+QMHzL4
         rM8RKs6LU+KS9lBFQ4zwFAjko/I0H8B7J9XuXHrtlLs4vInZxnMdj0ZuOtOD5P7IAkdJ
         geNx+PewvGcq6bde62cKLUsW0voF0JuqMbHMS7r5vChjhWMqV6Zp+2ykotZySgh6W3AL
         bcGm18/pYoKDCpFf0+FbXx5JWRGjLqArMkqPKcNgPZut2EVxYK4dIlNk203VIH0Ho1JD
         n/qw==
X-Gm-Message-State: ANoB5pnn5RTYrJyG8LJGJDBgDbORNa/D6/ZXZhQyZWf6XWS3oDQ0qZAW
	fFt9oTyz012aKT++P/aJymjgr4HfZ5qvMD/Zy1LK+2w=
X-Google-Smtp-Source: AA0mqf6/r9OAuXMJRzHb2lAo6ssFWi1jihxgupmRfewotv1od/2oc6Mbk2yoJTMarZbO3GIIDSiMioIh8xx1VKi2r1w=
X-Received: by 2002:a05:6a00:21c8:b0:562:e0fb:3c79 with SMTP id
 t8-20020a056a0021c800b00562e0fb3c79mr39583679pfj.39.1669767699552; Tue, 29
 Nov 2022 16:21:39 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
  <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se>
In-Reply-To: <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se>
From: Rick Macklem 
Date: Tue, 29 Nov 2022 16:21:28 -0800
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: Peter Eriksson 
Cc: FreeBSD CURRENT , "Bjoern A. Zeeb" , 
	Alan Somers 
Content-Type: multipart/alternative; boundary="00000000000096ddc205eea51614"
X-Spamd-Result: default: False [-3.92 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.92)[-0.922];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::430:from];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_ALL(0.00)[];
	TAGGED_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCPT_COUNT_THREE(0.00)[4];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NMKdK07tsz44Lf
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--00000000000096ddc205eea51614
Content-Type: text/plain; charset="UTF-8"

On Sun, Nov 27, 2022 at 10:04 AM Peter Eriksson  wrote:

> Keep the global variables as defaults that apply to all nfsds and allow
> (at least some subset) to be overridden inside the net jails if some things
> need to be changed from the defaults?
>
> This is pretty much a reply to one of the posts selected at random,
but I thought that better than starting a new email thread.

bz@ and asomers@ have both asked about running mountd within a vnet prison
(one via offlist email and the other on phabricator).

I think it is worth discussing here...
mountd (rightly or wrongly) does two distinctly different things:
1 - It pushes the exports into the kernel via nmount() so they
    can be hung off of the "struct mount" for a file system's
    mount point.
    --> This can only work for file system mount points and can
        only be done once for any given file system mount point.

    At this time, I have it done once globally outside of the prisons.
    The alternative I can see is doing it within each prison, but I
    think that would require that each prison have its own file system(s).
    (ie. The prison's root would always be a file system mount point.)

2 - It handles RPC Mount protocol requests from NFSv3 clients.  This one
    is NFSv3 specific, which is why I have done this NFSv4 only at
    this time.  To do this, it must be able to register with rpcbind,
    and I have no idea if running rpcbind in a vnet jail is practical.

Enforcing the use for separate file systems for each jail also makes
things safer, since the exports are enforced by the kernel. Without
this, a malicious NFSv4 client could "guess" a file handle for a file
outside the jail and gain access to that file. Put another way, without
a separate file system, there is no way to stop a malicious client from
finding files above the Root file handle. (Normal clients will use
PutRootFH and LookupParent and these won't be able to go above the top
of the jail.)

So, what do others think of enforcing the requirement that each jail
have its own file systems for this?

rick


> - Peter
>
>
> On Fri, Nov 25, 2022, 4:24 PM Rick Macklem  wrote:
>
>> Hi,
>>
>> bz@ has encouraged me to fiddle with the nfsd
>> so that it works in a vnet jail.
>> I have now basically done so, specifically for
>> NFSv4, since NFSv3 presents various issues.
>>
>> What I have not yet done is put global variables
>> in the vnet. This needs to be done so that the nfsd
>> can be run in multiple jail instances and/or in and
>> outside of a jail.
>> The problem is that there are 100s of global variables.
>>
>> I can see two approaches:
>> 1 - Move them all into the vnet jail. This would imply
>>     that all the sysctls need to somehow be changed,
>>     which would seem to be a POLA violation.
>>     It also implies a lot of stuff in the vnet.
>> 2 - Just move the global variables that will always
>>     differ from one nfsd to another (this would make
>>     the sysctls global and apply to all nfsds).
>>     This will keep the number of globals in the vnet
>>     smaller.
>>
>> I am currently leaning towards #2, put what do others
>> think?
>>
>> rick
>> ps: Personally, I don't know what use there is of
>>     running the nfsd inside a vnet jail, but bz@ has
>>     some use case.
>>
>
>

--00000000000096ddc205eea51614
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sun, Nov 27, 2022 at 10:04 AM Peter Erikss=
on <pen@lysator.liu.se> wro=
te:
Keep th=
e global variables as defaults that apply to all nfsds and allow (at least =
some subset) to be overridden inside the net jails if some things need to b=
e changed from the defaults?

This is pretty much a=
 reply to one of the posts selected at random,
but I thought that bette=
r than starting a new email thread.

bz@ and asomers@ have bo=
th asked about running mountd within a vnet prison
(one via offlist ema=
il and the other on phabricator).

I think it is worth discussi=
ng here...
mountd (rightly or wrongly) does two distinctly different th=
ings:
1 - It pushes the exports into the kernel via nmount() so they
=C2=A0 =C2=A0 can be hung off of the "struct mount" for a file =
system's
=C2=A0 =C2=A0 mount point.
=C2=A0 =C2=A0 --> This c=
an only work for file system mount points and can
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 only be done once for any given file system mount point.

=C2=A0 =C2=A0 At this time, I have it done once globally outside of the p=
risons.
=C2=A0 =C2=A0 The alternative I can see is doing it within each=
 prison, but I
=C2=A0 =C2=A0 think that would require that each prison =
have its own file system(s).
=C2=A0 =C2=A0 (ie. The prison's root w=
ould always be a file system mount point.)

2 - It handles RPC =
Mount protocol requests from NFSv3 clients.=C2=A0 This one
=C2=A0 =C2=
=A0 is NFSv3 specific, which is why I have done this NFSv4 only at
=C2=
=A0 =C2=A0 this time.=C2=A0 To do this, it must be able to register with rp=
cbind,
=C2=A0 =C2=A0 and I have no idea if running rpcbind in a vnet ja=
il is practical.

Enforcing the use for separate file systems f=
or each jail also makes
things safer, since the exports are enforced by=
 the kernel. Without
this, a malicious NFSv4 client could "guess=
" a file handle for a file
outside the jail and gain access to tha=
t file. Put another way, without
a separate file system, there is no wa=
y to stop a malicious client from
finding files above the Root file han=
dle. (Normal clients will use
PutRootFH and LookupParent and these won&=
#39;t be able to go above the top
of the jail.)

So, what d=
o others think of enforcing the requirement that each jail
have its own=
 file systems for this?

rick
=C2=A0
- Peter
<=
div>

On Fri, Nov 25, 2022, 4:24 PM=
 Rick Macklem <rick.macklem@gmail.com> wrote:
Hi,

bz@ has encouraged me to fiddle with the nfsd
so that it works in a vnet jail.
I have now basically done so, specifical=
ly for
NFSv4, since NFSv3 present=
s various issues.

What I have not yet done is put global vari=
ables
in the vnet. This needs to =
be done so that the nfsd
can be r=
un in multiple jail instances and/or in and
outside of a jail.
The=
 problem is that there are 100s of global variables.

I can se=
e two approaches:
1 - Move them a=
ll into the vnet jail. This would imply
=C2=A0 =C2=A0 that all the sysctls need to somehow be changed,
=

=C2=A0 =C2=A0 which would seem to be a=
 POLA violation.
=C2=A0 =C2=A0 It=
 also implies a lot of stuff in the vnet.
2 - Just move the global variables that will always
=C2=A0 =C2=A0 differ from one nfsd to another (=
this would make
=C2=A0 =C2=A0 the=
 sysctls global and apply to all nfsds).
=C2=A0 =C2=A0 This will keep the number of globals in the vnet
=C2=A0 =C2=A0 smaller.

=
I am currently leaning towards #2, put what do others
think?

<=
/div>
rick
ps: Personally, I don't know what use there is of
=C2=A0 =C2=A0 running the nfsd inside a =
vnet jail, but bz@ has
=C2=A0 =C2=
=A0 some use case.





--00000000000096ddc205eea51614--

From nobody Wed Nov 30 00:28:10 2022
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 4NMKn511dhz4j07R
	for ; Wed, 30 Nov 2022 00:28:25 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NMKn34Snmz45Rs;
	Wed, 30 Nov 2022 00:28:23 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=asomers@gmail.com;
	dmarc=none
Received: by mail-vs1-f52.google.com with SMTP id g65so15381156vsc.11;
        Tue, 29 Nov 2022 16:28:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=9npuwjr+jpjM/HTHuED6/vwtk1v0CUH9b+vPuBs2LCA=;
        b=GJ6AiGKpR/gdfxKl51y13Xo59Irta18v9Shp3/chFBJ/am0H1FwKUH2sNx/8Ar6hQb
         uRRMQsK1/JBx/qcYqjD8JrXfZXhoIeytweqTll1+ocTsNrfjipm8L9XJ0D8tmkGr6S/F
         7kj0Bcqwhdrus04V/i21uC3kBeyBs8YStBzlpF/tz7xfyZSzVN4/RIpIGGJJ69cwP1NA
         RWSSKjPn4R45w5ilxDWr9qaMoCtBtHAVkh+5uCQBn4j5sY65okIbXOUER/JHc+siBuEW
         w42UPyG68CE2ByIphguQj34x/m/k92ZhsEqD8XHWkiAF12ojQ94n9xwb1/Qek5lqqVZ/
         Lspw==
X-Gm-Message-State: ANoB5plKMVnMZDj1OXji66gb0VANDVrpIGRrA4Yr0R2xbCJrcHasqZdq
	S+WZ5LEQ0GSoPjwa1nYR2OUrfOXAcZxWsJ1HjxCpe7q0
X-Google-Smtp-Source: AA0mqf6LhSwwsIHOUQXZCRUhOcoicbEUmqWzV5Nn5iQNgjCIY75YqgYmeZTR6e7sXXXKfpz8fC36A3BchdheZMSknlU=
X-Received: by 2002:a05:6102:3911:b0:3af:b08c:9bbe with SMTP id
 e17-20020a056102391100b003afb08c9bbemr34999779vsu.76.1669768102125; Tue, 29
 Nov 2022 16:28:22 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 
 <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se> 
In-Reply-To: 
From: Alan Somers 
Date: Tue, 29 Nov 2022 17:28:10 -0700
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: Rick Macklem 
Cc: Peter Eriksson , FreeBSD CURRENT , 
	"Bjoern A. Zeeb" 
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Result: default: False [0.22 / 15.00];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.94)[-0.936];
	NEURAL_SPAM_SHORT(0.65)[0.653];
	FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17];
	MIME_GOOD(-0.10)[text/plain];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	TAGGED_RCPT(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.217.52:from];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.217.52:from];
	R_DKIM_NA(0.00)[];
	TO_DN_ALL(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	FREEMAIL_TO(0.00)[gmail.com];
	ARC_NA(0.00)[];
	FREEFALL_USER(0.00)[asomers];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[]
X-Rspamd-Queue-Id: 4NMKn34Snmz45Rs
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem  wrote:
>
>
>
> On Sun, Nov 27, 2022 at 10:04 AM Peter Eriksson  wrote:
>>
>> Keep the global variables as defaults that apply to all nfsds and allow (at least some subset) to be overridden inside the net jails if some things need to be changed from the defaults?
>>
> This is pretty much a reply to one of the posts selected at random,
> but I thought that better than starting a new email thread.
>
> bz@ and asomers@ have both asked about running mountd within a vnet prison
> (one via offlist email and the other on phabricator).
>
> I think it is worth discussing here...
> mountd (rightly or wrongly) does two distinctly different things:
> 1 - It pushes the exports into the kernel via nmount() so they
>     can be hung off of the "struct mount" for a file system's
>     mount point.
>     --> This can only work for file system mount points and can
>         only be done once for any given file system mount point.
>
>     At this time, I have it done once globally outside of the prisons.
>     The alternative I can see is doing it within each prison, but I
>     think that would require that each prison have its own file system(s).
>     (ie. The prison's root would always be a file system mount point.)
>
> 2 - It handles RPC Mount protocol requests from NFSv3 clients.  This one
>     is NFSv3 specific, which is why I have done this NFSv4 only at
>     this time.  To do this, it must be able to register with rpcbind,
>     and I have no idea if running rpcbind in a vnet jail is practical.
>
> Enforcing the use for separate file systems for each jail also makes
> things safer, since the exports are enforced by the kernel. Without
> this, a malicious NFSv4 client could "guess" a file handle for a file
> outside the jail and gain access to that file. Put another way, without
> a separate file system, there is no way to stop a malicious client from
> finding files above the Root file handle. (Normal clients will use
> PutRootFH and LookupParent and these won't be able to go above the top
> of the jail.)
>
> So, what do others think of enforcing the requirement that each jail
> have its own file systems for this?

I think that's a totally reasonable requirement.  Especially so for
ZFS users, who already create a filesystem per jail for other reasons.

>
> rick
>
>>
>> - Peter
>>
>>
>> On Fri, Nov 25, 2022, 4:24 PM Rick Macklem  wrote:
>>>
>>> Hi,
>>>
>>> bz@ has encouraged me to fiddle with the nfsd
>>> so that it works in a vnet jail.
>>> I have now basically done so, specifically for
>>> NFSv4, since NFSv3 presents various issues.
>>>
>>> What I have not yet done is put global variables
>>> in the vnet. This needs to be done so that the nfsd
>>> can be run in multiple jail instances and/or in and
>>> outside of a jail.
>>> The problem is that there are 100s of global variables.
>>>
>>> I can see two approaches:
>>> 1 - Move them all into the vnet jail. This would imply
>>>     that all the sysctls need to somehow be changed,
>>>     which would seem to be a POLA violation.
>>>     It also implies a lot of stuff in the vnet.
>>> 2 - Just move the global variables that will always
>>>     differ from one nfsd to another (this would make
>>>     the sysctls global and apply to all nfsds).
>>>     This will keep the number of globals in the vnet
>>>     smaller.
>>>
>>> I am currently leaning towards #2, put what do others
>>> think?
>>>
>>> rick
>>> ps: Personally, I don't know what use there is of
>>>     running the nfsd inside a vnet jail, but bz@ has
>>>     some use case.
>>
>>

From nobody Thu Dec  1 00:00:04 2022
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 4NMx5w64ksz4jQcT;
	Thu,  1 Dec 2022 00:00:04 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NMx5w5ZWWz4QKg;
	Thu,  1 Dec 2022 00:00:04 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1669852804;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=ZngjG/xRhlT6jgyMsmSzmMnS+gIFuEXN7E7QQqBPpS0=;
	b=qHTy1uuO2HsLqajxw0/OyiUERNfOyNDVMcWDWzU2rFl89zK2X/+wgPdWfJ2fV1AnisF+2L
	kjbCOH783P+kF1KSQUkkqXFKQUpI8XwY4UBwWbfee9uEiKiCIbhzEmnmeEKU8q+v7+IUfm
	jVapqhO0CyPsKlI1BZpJ/cTpnHTKy3yYryRk6H0+wwug/wvD4iVkrfnLPRMNsbJ8nA2fTI
	vH9VVON6FlsceRMlbly6KAxlLPsTp3NrE8Y68cKNK31tO8TkCat7NdQqGp6jTNo0UFvuTY
	NLPCia+gslifSkZ4FmPzJUXBkh++nV4I0v7o8sBTwtrwO1tyPF6PcT/ei6YtbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1669852804;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=ZngjG/xRhlT6jgyMsmSzmMnS+gIFuEXN7E7QQqBPpS0=;
	b=t8MjWok9TlqtFN0GcZ7n0FmZMhZUCwP1EWbQZlQ4kbm/qnUNuB62VnZAJMhdFDuYIAPMDU
	QmAXit0p5j1jNFjyE7IZm/YigPjoiM3HCb5RuEB1cI9KgHVhdG8MNj9R5AWpQZHBSBkF01
	9NAN5alHiZecbKaTONQN5B7U24Xbdw5rKJGYJhX2+TknBvpnnBELoGDO/T4dNAPEZkxycY
	yfzyn+z029SpgkiL0y+ZvNfBjjSeOT955q/hKfmROFHhWSQDfFyhPJPLpj6eKh3/itwROe
	62B1YtDRIy1xTQbu4yGhuFKKd0hpkBNNBOXJtgAQMysDkTaAOORkeUcbDpvOqg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669852804; a=rsa-sha256; cv=none;
	b=n3HEiCHKQ3+ZLuMMyOQSRwcAmpVK3EpPVRiZilpFe9VmQ0w6VIc3npXo4D2ufxFcWS4tha
	YMtfFkylQd3ZwtsytQ4saLWTZM1TmYvj8NlaD3UIQpbMpki1yAPftwNjpvf52dWVxnoKBz
	QPdNn9FRPvJfZ3X8JYSeRx4uy8UNGih/vE79puPp/r4OgEztRk2vACRU+b0yyvYdyDzHLF
	IZRbdYxCcQay5xX66J4QaPag/dLgKu2nxfSDSsB9QGzMdVdv/+GumD9TZlsgMAb6gvm1Q5
	kbpSC5hl0Igef3OamRhKJGsDd+NA2Gk4L3j33mQ+yvfLEcGQbeCk21ej9e66Yg==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id ABEFB24CD; Thu,  1 Dec 2022 00:00:04 +0000 (UTC)
To: freebsd-quarterly-calls@FreeBSD.org
Subject: Call for 2022Q4 quarterly status reports
Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org
Message-Id: <20221201000004.ABEFB24CD@freefall.freebsd.org>
Date: Thu,  1 Dec 2022 00:00:04 +0000 (UTC)
From: Lorenzo Salvadore 
X-ThisMailContainsUnwantedMimeParts: N
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

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
December, 31st 2023 for work done since the last round of Quarterly Reports:
October 2022 - December 2022.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the AsciiDoctor template, fill it in, and
email it to quarterly-submissions@FreeBSD.org.
The new AsciiDoctor template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc

We look forward to seeing your 2022Q4 reports!

Thanks,

Lorenzo Salvadore (on behalf of quarterly@)

From nobody Thu Dec  1 09:29:25 2022
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 4NN9lT4WzSz4jtKM
	for ; Thu,  1 Dec 2022 09:29:57 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-256) client-digest SHA256)
	(Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NN9lS5HGzz4M22
	for ; Thu,  1 Dec 2022 09:29:56 +0000 (UTC)
	(envelope-from Alexander@leidinger.net)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=kxPmbCzk;
	spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net;
	dmarc=pass (policy=quarantine) header.from=leidinger.net
Received: from outgoing.leidinger.net (p508d4cfc.dip0.t-ipconnect.de [80.141.76.252])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (P-256)
	 client-signature ECDSA (P-256))
	(Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK))
	by mailgate.Leidinger.net (Postfix) with ESMTPSA id A0F3C1FB5
	for ; Thu,  1 Dec 2022 10:29:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net;
	s=outgoing-alex; t=1669886984;
	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=o9a0pGEVYOXKLCJ+dJyh6S+5EJV1tnmb1lTdowvLqL0=;
	b=kxPmbCzkPa09u/8dv+ADfPXNhSPdpjDSxQMjX7rRypyOa5GEfFz5ir+lrkkYxySOmoRB/5
	klTVAifJ/t2QGuQHF3oQH9DRAQTvEPqcdZUqbD/I+62RV31DTrDXXwqHj62igwS5bogofh
	QZnAK10l3sWjo4oiHqvTLuDfnWJl6cg6VsvqrOkO9m3xuOv2dAFxTD0NkPzMmVuqSzow61
	rvZLmAl0IbqSdOibfx/PVCFczB269hKG2zfAYTLjrv9OdFgvGhBfJ38gqvpQKe8eEWtOkU
	BujtKp8Yb4AXfjGmmB8v3/h0x8A+LrssCHvSE3TzxBVSvc4u9t/fVTXoRj3YXg==
Received: from webmail.leidinger.net (localhost [127.0.0.1])
	by outgoing.leidinger.net (Postfix) with ESMTP id 9B0A4648C
	for ; Thu,  1 Dec 2022 10:29:26 +0100 (CET)
Received: from www (uid 80)
	(envelope-from Alexander@leidinger.net)
	id 62686
	by webmail.leidinger.net (DragonFly Mail Agent v0.13+ on webmail.leidinger.net);
	Thu, 01 Dec 2022 10:29:25 +0100
Date: Thu, 01 Dec 2022 10:29:25 +0100
Message-ID: <20221201102925.Horde.uAC-87YyIRDDnqJTmvsFwNm@webmail.leidinger.net>
From: Alexander Leidinger 
To: Alan Somers 
Cc: Rick Macklem , Peter Eriksson
 , FreeBSD CURRENT , "Bjoern
 A. Zeeb" 
Subject: Re: RFC: nfsd in a vnet jail
References: 
 
 <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se>
 
 
In-Reply-To: 
Accept-Language: de,en
Content-Type: multipart/signed; boundary="=_8zfjp1O9e-Bcwxy_G1BIpfD";
 protocol="application/pgp-signature"; micalg=pgp-sha256
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-Spamd-Result: default: False [-4.60 / 15.00];
	SIGNED_PGP(-2.00)[];
	SUSPICIOUS_RECIPS(1.50)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.20)[multipart/signed,text/plain];
	R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TAGGED_RCPT(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_CC(0.00)[gmail.com,lysator.liu.se,freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	RCPT_COUNT_FIVE(0.00)[5];
	ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE];
	TO_DN_ALL(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[leidinger.net:+];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-Rspamd-Queue-Id: 4NN9lS5HGzz4M22
X-Spamd-Bar: ----
X-ThisMailContainsUnwantedMimeParts: N

This message is in MIME format and has been PGP signed.

--=_8zfjp1O9e-Bcwxy_G1BIpfD
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


Quoting Alan Somers  (from Tue, 29 Nov 2022=20=20
17:28:10=20-0700):

> On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem  wro=
te:

>> So, what do others think of enforcing the requirement that each jail
>> have its own file systems for this?
>
> I think that's a totally reasonable requirement.  Especially so for
> ZFS users, who already create a filesystem per jail for other reasons.

While I agree that it is a reasonable requirement, just a note that we=20=
=20
can=20not assume that every existing jail resides on its own file=20=20
system.=20The base system jail infrastructure doesn't check this, and=20=20
the=20ezjail port doesn't either. The iocage port does it.

Is there a way to detect this inside a jail and error out in nfsd/mountd?

Bye,
Alexander.

--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF

--=_8zfjp1O9e-Bcwxy_G1BIpfD
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmOIc/QACgkQEg2wmwP4
2IYQnA/5Ab+S8XIx+I74YC57YsrTU6knAzoblmXm7IhLYqBM6Hw4+CHPS4b3X/2I
tNkddQpd8vXBofiydmNxa96VGibzfY8NvkgCJ5zLAJKxmST+llSd/BiIdsWC7FbP
jpv34aqNXyzv5WNJyoWWkuXYKXx7OzS9T+bZhXPmaLYAkEM4fVKSJDbNqsQN9/4x
bDjCSBjaHdeyfXsmxH5HgOdstK+bCp3W+HGirsCfLRryFfZmmnOtXFpSJYk907Pv
z0NlKDMg7P/vATlM4vyvmauNMSZCE7KYER5Mj4Q7PYX/m6RnesOU497mK32nnhSk
XE9IwopgWy6TAdkI+Nu9sdJowQnsjyWWIcD4fKJYEwLARhi0DOcn1oW2p8Bs+Z96
vSKwRKQV39oiYVumQMvXL7xaaMUPFfh80pT/dEHb0be4c9p7SSFxFmrbdBjjKtNX
+kJhjZQL+YOaEmLbH2zv/fS7MZVNNmTOR8pyOCBa0WvvLl5zbDm5o506ypzcVN5j
M+zncNsrArR8jLIT4asUywr4v6xKo0ZNSwr9Bcvpxa+38TgMM4jZpdxfqKnsDUbq
evyvrve7Sttouawb5VaOGEY8pzNfxERabhZUV8njco9Lu/X16CL3crnpWr76JlSf
hZCFXAlbo3C9ilV49kTdMy3Ok1ValyIAtPrGY/OBJf/7XS+yIJA=
=E6Uc
-----END PGP SIGNATURE-----

--=_8zfjp1O9e-Bcwxy_G1BIpfD--

From nobody Thu Dec  1 10:01:37 2022
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 UTF8SMTP id 4NNBSD6w7dz4jxt2
	for ; Thu,  1 Dec 2022 10:01:48 +0000 (UTC)
	(envelope-from freebsd-current@dino.sk)
Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72])
	(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 UTF8SMTPS id 4NNBSD39H2z4QH8;
	Thu,  1 Dec 2022 10:01:48 +0000 (UTC)
	(envelope-from freebsd-current@dino.sk)
Authentication-Results: mx1.freebsd.org;
	none
Received: from zeta.dino.sk ([84.245.95.254])
  (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384)
  by cm0.netlabit.sk with ESMTPSA
  id 000000000256D710.0000000063887B82.0001237A; Thu, 01 Dec 2022 11:01:38 +0100
Date: Thu, 1 Dec 2022 11:01:37 +0100
From: Milan Obuch 
To: freebsd-current@freebsd.org
Cc: Alexander Leidinger ,
  Alan Somers ,
  Rick Macklem ,
  Peter Eriksson , bz@freebsd.org
Subject: Re: RFC: nfsd in a vnet jail
Message-ID: <20221201110137.08b2b68c@zeta.dino.sk>
In-Reply-To: <20221201102925.Horde.uAC-87YyIRDDnqJTmvsFwNm@webmail.leidinger.net>
References: 
	
	<82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se>
	
	
	<20221201102925.Horde.uAC-87YyIRDDnqJTmvsFwNm@webmail.leidinger.net>
X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd13.1)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Rspamd-Queue-Id: 4NNBSD39H2z4QH8
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK];
	TAGGED_RCPT(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 01 Dec 2022 10:29:25 +0100
Alexander Leidinger  wrote:

> Quoting Alan Somers  (from Tue, 29 Nov 2022  
> 17:28:10 -0700):
> 
> > On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem
> >  wrote:  
> 
> >> So, what do others think of enforcing the requirement that each
> >> jail have its own file systems for this?  
> >
> > I think that's a totally reasonable requirement.  Especially so for
> > ZFS users, who already create a filesystem per jail for other
> > reasons.  
> 
> While I agree that it is a reasonable requirement, just a note that
> we can not assume that every existing jail resides on its own file  
> system. The base system jail infrastructure doesn't check this, and  
> the ezjail port doesn't either. The iocage port does it.
>

My position would be 'recommended, but not forced-to' one. I have
various installations with jails sharing parts of filesystem (like
ports or src tree for development, or even local git repository), or
even running with exactly the same directory as root of number of
jails. Probably not a common scenario for sure, but still useful.

Regards,
Milan

From nobody Thu Dec  1 16:20:12 2022
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 4NNLsB2kkHz4jbm7
	for ; Thu,  1 Dec 2022 16:20:30 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NNLsB28VNz4Kpx
	for ; Thu,  1 Dec 2022 16:20:30 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x62c.google.com with SMTP id fy37so5358025ejc.11
        for ; Thu, 01 Dec 2022 08:20:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=9EEFY21+4BPEV2AQ1bAJO5U95DjljTflLRMbNhDmgJE=;
        b=IWRRYAx0UhLySyHlhDfkHs4fhe0aCgGat2O5HIweTcMfArhCZiWHhaQna2kKYo72Tc
         iD8T1PSpBVBvqkKcCMFBCDG+AfZSs/tP/5ELroCpD/UhHqjZPzUmQfO9el8cg/acE907
         C5DzpM6ArbWGewUY4r39J7fb0AZsC3Xdhdnkc2JO3vj5R6qeA29jStljHDs+DVmF5Ms+
         k18nvDNr9l2B30oVwAlTGKPB2QAwI31jpDpDTr8RbKt0eEld6ktbL6Veqm8Q1NbDb1z/
         NLFjmQ5TVCFuZXRxaTfvlQFLVRyxVa8Cvi6lxy0eWFL7qUNZFgmQZ2wnmZ/mkhCGfDNW
         xmvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=9EEFY21+4BPEV2AQ1bAJO5U95DjljTflLRMbNhDmgJE=;
        b=6dbVjk4+aoa9Ese9ciwG5d4EYgJSMdQV0iXeueOUnSvfr8oLf0NzWT05y/XvOOww2I
         VzI+pNzwGF3529Sr/y7xasWqxWbjCU2StFLO8kcGS0IV6TXxfcI5PJpGR/yfkfUi4vRS
         VDYFYcl6ohoUAP9W3hsZSETdpMT/pnnsAYrhgMrR52fZS+iDVC4Y/OahtzdNQZsOokWI
         ULvEkai2F2s4gnDk7t/Q+eQlr15/zBqmRsXjr3+EpXCzpNbdRrXg8aPj66b/h7rcaR6Y
         jC5X/ZY/h5DqhGTdYHWczDIWKLu34ZXUNjFqzstW6vZlmDNgxBsS3jeyB4ZbOfnVbblN
         JgDQ==
X-Gm-Message-State: ANoB5plJM8Zm5lYLo72E+H9X2alOUZeB5CDizktcFzD3CnfMXSzm8+Y9
	4XeMw0EJ1CbeYsXXZ2NNjkhNMylNGCey7APpxn5zWg==
X-Google-Smtp-Source: AA0mqf6LWkG/PWrx64bePeEc/L9Txxz6iyJ8DnWJTVAx0pqPKUyJxSeouSOLUhQrXhoTq3xOQcWWwP9sjkJ1OEjIWkY=
X-Received: by 2002:a17:906:f84d:b0:7b9:631b:7dfb with SMTP id
 ks13-20020a170906f84d00b007b9631b7dfbmr38267158ejb.32.1669911623895; Thu, 01
 Dec 2022 08:20:23 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 
 <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se> 
  <20221201102925.Horde.uAC-87YyIRDDnqJTmvsFwNm@webmail.leidinger.net>
In-Reply-To: <20221201102925.Horde.uAC-87YyIRDDnqJTmvsFwNm@webmail.leidinger.net>
From: Warner Losh 
Date: Thu, 1 Dec 2022 09:20:12 -0700
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: Alexander Leidinger 
Cc: Alan Somers , Rick Macklem , 
	Peter Eriksson , FreeBSD CURRENT , 
	"Bjoern A. Zeeb" 
Content-Type: multipart/alternative; boundary="000000000000262f3805eec69916"
X-Rspamd-Queue-Id: 4NNLsB28VNz4Kpx
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	TAGGED_RCPT(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000262f3805eec69916
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 1, 2022 at 2:30 AM Alexander Leidinger 
wrote:

>
> Quoting Alan Somers  (from Tue, 29 Nov 2022
> 17:28:10 -0700):
>
> > On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem 
> wrote:
>
> >> So, what do others think of enforcing the requirement that each jail
> >> have its own file systems for this?
> >
> > I think that's a totally reasonable requirement.  Especially so for
> > ZFS users, who already create a filesystem per jail for other reasons.
>
> While I agree that it is a reasonable requirement, just a note that we
> can not assume that every existing jail resides on its own file
> system. The base system jail infrastructure doesn't check this, and
> the ezjail port doesn't either. The iocage port does it.
>

I have several jails that all live on the same zfs data set that I setup
ages ago before
I understood the full benefits of ZFS... but I could migrate in a pinch.
But they aren't in
their own vnet, so maybe that doesn't apply.


> Is there a way to detect this inside a jail and error out in nfsd/mountd?
>

Whatever we do, there will be people bitten by it, so we need to make the
messaging around
it good (the error messages from the system, as well as the documentation).

Warner

--000000000000262f3805eec69916
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Dec 1, 2022 at 2:30 AM Alexan=
der Leidinger <Alexander@leid=
inger.net> wrote:


Quoting Alan Somers <asomers@freebsd.org> (from Tue, 29 Nov 2022=C2=A0 

17:28:10 -0700):



> On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem <rick.macklem@gmail.com> wrote=
:



>> So, what do others think of enforcing the requirement that each ja=
il

>> have its own file systems for this?

>

> I think that's a totally reasonable requirement.=C2=A0 Especially =
so for

> ZFS users, who already create a filesystem per jail for other reasons.=




While I agree that it is a reasonable requirement, just a note that we=C2=
=A0 

can not assume that every existing jail resides on its own file=C2=A0 

system. The base system jail infrastructure doesn't check this, and=C2=
=A0 

the ezjail port doesn't either. The iocage port does it.

I have several jails that all live on the same zfs da=
ta set that I setup ages ago before
I understood the full benefit=
s of ZFS... but I could migrate in a pinch. But they aren't in
their own vnet, so maybe that doesn't apply.
=C2=A0

Is there a way to detect this inside a jail and error out in nfsd/mountd?

Whatever we do, there will be people bit=
ten by it, so we need to make the messaging around
it good (the e=
rror messages from the system, as well as the documentation).
Warner=C2=A0


--000000000000262f3805eec69916--

From nobody Thu Dec  1 16:22:56 2022
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 4NNLwH1Dffz4jc7W
	for ; Thu,  1 Dec 2022 16:23:11 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NNLwG14dRz4MVH;
	Thu,  1 Dec 2022 16:23:10 +0000 (UTC)
	(envelope-from bsd-lists@bsdforge.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of bsd-lists@bsdforge.com has no SPF policy when checking 24.113.41.81) 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 2B1GMuJY029101;
	Thu, 1 Dec 2022 08:23:02 -0800 (PST)
	(envelope-from bsd-lists@bsdforge.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
Date: Thu, 01 Dec 2022 08:22:56 -0800
From: Chris 
To: Rick Macklem 
Cc: Peter Eriksson ,
        FreeBSD CURRENT
 ,
        "Bjoern A. Zeeb" , Alan
 Somers 
Subject: Re: RFC: nfsd in a vnet jail
In-Reply-To: 
References: 
 
 <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se>
 
User-Agent: UDNSMS/17.0
Message-ID: <2980bcbd22f884962d358808f9440d77@bsdforge.com>
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_cbaeb79b87ecbd078cfa5cb53adff3e9"
X-Rspamd-Queue-Id: 4NNLwG14dRz4MVH
X-Spamd-Bar: +
X-Spamd-Result: default: False [1.50 / 15.00];
	SUSPICIOUS_RECIPS(1.50)[];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	local_wl_ip(0.00)[24.113.41.81];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	HAS_ATTACHMENT(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	TAGGED_RCPT(0.00)[];
	R_SPF_NA(0.00)[no SPF record]
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-ThisMailContainsUnwantedMimeParts: N

--=_cbaeb79b87ecbd078cfa5cb53adff3e9
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-11-29 16:21, Rick Macklem wrote:
> On Sun, Nov 27, 2022 at 10:04 AM Peter Eriksson  wrote:
> 
>> Keep the global variables as defaults that apply to all nfsds and allow
>> (at least some subset) to be overridden inside the net jails if some things
>> need to be changed from the defaults?
>> 
>> This is pretty much a reply to one of the posts selected at random,
> but I thought that better than starting a new email thread.
> 
> bz@ and asomers@ have both asked about running mountd within a vnet prison
> (one via offlist email and the other on phabricator).
> 
> I think it is worth discussing here...
> mountd (rightly or wrongly) does two distinctly different things:
> 1 - It pushes the exports into the kernel via nmount() so they
>     can be hung off of the "struct mount" for a file system's
>     mount point.
>     --> This can only work for file system mount points and can
>         only be done once for any given file system mount point.
> 
>     At this time, I have it done once globally outside of the prisons.
>     The alternative I can see is doing it within each prison, but I
>     think that would require that each prison have its own file system(s).
>     (ie. The prison's root would always be a file system mount point.)
> 
> 2 - It handles RPC Mount protocol requests from NFSv3 clients.  This one
>     is NFSv3 specific, which is why I have done this NFSv4 only at
>     this time.  To do this, it must be able to register with rpcbind,
>     and I have no idea if running rpcbind in a vnet jail is practical.
> 
> Enforcing the use for separate file systems for each jail also makes
> things safer, since the exports are enforced by the kernel. Without
> this, a malicious NFSv4 client could "guess" a file handle for a file
> outside the jail and gain access to that file. Put another way, without
> a separate file system, there is no way to stop a malicious client from
> finding files above the Root file handle. (Normal clients will use
> PutRootFH and LookupParent and these won't be able to go above the top
> of the jail.)
> 
> So, what do others think of enforcing the requirement that each jail
> have its own file systems for this?

I don't care for any of it. It looks like additional overhead with the
addition of potential security risks. All for a very limited (and as yet
unknown) use case.

--chris
> 
> rick
> 
> 
>> - Peter
>> 
>> 
>> On Fri, Nov 25, 2022, 4:24 PM Rick Macklem  wrote:
>> 
>>> Hi,
>>> 
>>> bz@ has encouraged me to fiddle with the nfsd
>>> so that it works in a vnet jail.
>>> I have now basically done so, specifically for
>>> NFSv4, since NFSv3 presents various issues.
>>> 
>>> What I have not yet done is put global variables
>>> in the vnet. This needs to be done so that the nfsd
>>> can be run in multiple jail instances and/or in and
>>> outside of a jail.
>>> The problem is that there are 100s of global variables.
>>> 
>>> I can see two approaches:
>>> 1 - Move them all into the vnet jail. This would imply
>>>     that all the sysctls need to somehow be changed,
>>>     which would seem to be a POLA violation.
>>>     It also implies a lot of stuff in the vnet.
>>> 2 - Just move the global variables that will always
>>>     differ from one nfsd to another (this would make
>>>     the sysctls global and apply to all nfsds).
>>>     This will keep the number of globals in the vnet
>>>     smaller.
>>> 
>>> I am currently leaning towards #2, put what do others
>>> think?
>>> 
>>> rick
>>> ps: Personally, I don't know what use there is of
>>>     running the nfsd inside a vnet jail, but bz@ has
>>>     some use case.
>>> 
>> 
>> 

--=_cbaeb79b87ecbd078cfa5cb53adff3e9
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_cbaeb79b87ecbd078cfa5cb53adff3e9--

From nobody Thu Dec  1 16:37:57 2022
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 4NNMFZ1Tydz4jf0J
	for ; Thu,  1 Dec 2022 16:38:10 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NNMFY6ltsz4Q1w;
	Thu,  1 Dec 2022 16:38:09 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-vs1-f42.google.com with SMTP id 125so2115990vsi.9;
        Thu, 01 Dec 2022 08:38:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=WRTtAKf3cUWTcWlvU2Z/lXXaXs1VWdu0L1CFcke210s=;
        b=dqEpqvhUO7P/ltjw2SSZ/MZuHH513qVb4OzI1CO2PkJcIAGKA5vhcXS3BvXsCRWKhR
         NKryyMezPP3CJPr96QziXo/rfMAbBLNSToNX0rdxUIKSLMjmvv2WN25jNLOgis1N5XR5
         IeF5rqlm33FGHiC9xVgDe3xTZbvsXV+yu6Fef1NG8iNU3TqIqVT6s3QpTdknesOMd3fm
         e6+YWEASQEFkOmr3pwJT4RSEfiD9I3crztbqzTi/mC0kahdhX7eQSNa0dmFdqJuqcyMZ
         Z53eFjWd/sUYiGT8I8WbIX5Ht+Dc5z43h1eSksACsIwcX8KmgKzwtdp2GxOGIME+qUe0
         l04Q==
X-Gm-Message-State: ANoB5pltabMqdFcTOCtqzyYMVsMuxaGK68nFnMnlfv6l8I51Dr//gsKB
	wsyE5N6KLYnBnJ+2BSeUpC+1TqKyuAg68QZ4/s5DDr2RJ9c=
X-Google-Smtp-Source: AA0mqf7D8rYYAGkGMfUk2t/Jc+XPZKYPCoef8rHf4AZR25U+g2fzr64Bhz1eJJRRCYtaaGyytq+PvbEbDaBpjy29w6s=
X-Received: by 2002:a05:6102:3911:b0:3af:b08c:9bbe with SMTP id
 e17-20020a056102391100b003afb08c9bbemr39797365vsu.76.1669912688941; Thu, 01
 Dec 2022 08:38:08 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 
 <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se> 
 <2980bcbd22f884962d358808f9440d77@bsdforge.com>
In-Reply-To: <2980bcbd22f884962d358808f9440d77@bsdforge.com>
From: Alan Somers 
Date: Thu, 1 Dec 2022 09:37:57 -0700
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: Chris 
Cc: Rick Macklem , Peter Eriksson , 
	FreeBSD CURRENT , "Bjoern A. Zeeb" 
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Queue-Id: 4NNMFY6ltsz4Q1w
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	TAGGED_RCPT(0.00)[];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

> I don't care for any of it. It looks like additional overhead with the
> addition of potential security risks. All for a very limited (and as yet
> unknown) use case.

Here's an example of a real-world use case.  I'm responsible for
supporting multiple products involving NFS, iSCSI, and other
protocols.  For security reasons, each product is placed on its own
VLAN.  Sometimes it's not practical to dedicate a physical server to a
single product, so I have to double-up.  For the products that don't
involve NFS or iSCSI, I place them in a VNET jail.  That way their
processes can only access the correct VLAN.  But NFS and iSCSI can't
(yet) be jailed, so those products need to be served by JID 0.
Therefore, those products' processes can access each other's VLANs.
Clearly that's not ideal.

Jailing different products is also good for manageability.  It's
easier to manage the list of packages that must be installed for each
product, config file settings, etc.  For example, some of our NFS
products require vfs.nfsd.enable_stringtouid=1, but others could work
without it.  Right now, we're forced to turn it on for all products.

-Alan

From nobody Thu Dec  1 17:42:19 2022
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 4NNNgk6N84z4jnjR
	for ; Thu,  1 Dec 2022 17:42:26 +0000 (UTC)
	(envelope-from bsd-lists@bsdforge.com)
Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "ultimatedns.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NNNgk4mhKz4Xqx;
	Thu,  1 Dec 2022 17:42:26 +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 2B1HgJ2q004596;
	Thu, 1 Dec 2022 09:42:25 -0800 (PST)
	(envelope-from bsd-lists@bsdforge.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
Date: Thu, 01 Dec 2022 09:42:19 -0800
From: Chris 
To: Alan Somers 
Cc: Rick Macklem ,
        Peter Eriksson
 ,
        FreeBSD CURRENT ,
        "Bjoern
 A. Zeeb" 
Subject: Re: RFC: nfsd in a vnet jail
In-Reply-To: 
References: 
 
 <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se>
 
 <2980bcbd22f884962d358808f9440d77@bsdforge.com>
 
User-Agent: UDNSMS/17.0
Message-ID: <5b062f8a6e4edee98004cd6e4cc394d4@bsdforge.com>
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_d43b3aada8b86d168847bfc6ce465640"
X-Rspamd-Queue-Id: 4NNNgk4mhKz4Xqx
X-Spamd-Bar: ----
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];
	TAGGED_RCPT(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--=_d43b3aada8b86d168847bfc6ce465640
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-12-01 08:37, Alan Somers wrote:
>> I don't care for any of it. It looks like additional overhead with the
>> addition of potential security risks. All for a very limited (and as yet
>> unknown) use case.
> 
> Here's an example of a real-world use case.  I'm responsible for
> supporting multiple products involving NFS, iSCSI, and other
> protocols.  For security reasons, each product is placed on its own
> VLAN.  Sometimes it's not practical to dedicate a physical server to a
> single product, so I have to double-up.  For the products that don't
> involve NFS or iSCSI, I place them in a VNET jail.  That way their
> processes can only access the correct VLAN.  But NFS and iSCSI can't
> (yet) be jailed, so those products need to be served by JID 0.
> Therefore, those products' processes can access each other's VLANs.
> Clearly that's not ideal.
> 
> Jailing different products is also good for manageability.  It's
> easier to manage the list of packages that must be installed for each
> product, config file settings, etc.  For example, some of our NFS
> products require vfs.nfsd.enable_stringtouid=1, but others could work
> without it.  Right now, we're forced to turn it on for all products.
OK. I can see that. Assuming I understand your intent correctly, I might
choose bhyve(8) for that. Tho that *would* be a little more expensive.
I rely on jail(8) daily. They're cheap, fast && easy. As yet, I've never
had unreasonable concern for security. The proposed change looks like a
potentially high addition of overhead (jail not so cheap now?). RPC &&
NFS are not cheap && have a comparatively high attack surface. So I guess
my concerns/view are affected by this understanding.

Thanks for the clarification, Alan.

--chris
> 
> -Alan

--=_d43b3aada8b86d168847bfc6ce465640
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_d43b3aada8b86d168847bfc6ce465640--

From nobody Thu Dec  1 23:30:19 2022
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 4NNXP85Hl4z4jg96
	for ; Thu,  1 Dec 2022 23:30:20 +0000 (UTC)
	(envelope-from gbe@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NNXP84Q9gz3sRX
	for ; Thu,  1 Dec 2022 23:30:20 +0000 (UTC)
	(envelope-from gbe@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1669937420;
	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=iY4ubnVaXM25sop/gUTp6AnCRf7PIeIKRAlGbpSzsPE=;
	b=L5SHoBYwhqYW52HPrUA89nBX+eOO2U3jZb9CKINQMTZpzt74mOb0SnTO5qGmPx2lTQPvPz
	+DTwmmKjTqZytJo4aArJiKWodruQcMRfAzw2BSkZetQo9wcs6O87Je9OyOGlZykPh5OV0F
	N63jgW8nLOlIRniHxH+h3rGxjaMyHmeKVtesSEBYTB+l1D0p2kja5stnVCoQm10M+iqn+F
	lFxc/6OSPxP3H28/7YGy/uOMNsS/NLBWh/l9xw2CiEmiOEsotcMfiUiomRSiV0qZwUDowG
	qz4ak+jzgC1/byuZVunFusGGA2VvNZMY3wFCVAklGWxaiVUhLHixulu3rs9I5Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1669937420;
	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=iY4ubnVaXM25sop/gUTp6AnCRf7PIeIKRAlGbpSzsPE=;
	b=GiyAc+FVELT1mdmVFRrAcpu6Z3Hy2nHNqSzDSMRfDBZdlNJJCmFqYavZ/dOKvLAu8BCoBJ
	3+kOkAezbO/io+PWCWwGxbCF1DXSORMAPuO9VBsZ8ZFZt7WmlbOqWbveNwefDDlHYxNef0
	1bxcGAhQEyDI/jNEiWp0xyiFSstr7AwMwuN2/fkKUHsdxfmnT2VaFmxl8nrJYF7aEWsQiZ
	P0KAXCPrNUJcJDI2hHkbajxtYMTV/jTXxV2r5I8NfGEVJ5EEo3uYLTTp9NnrQxTKkT1fsP
	xC2W0K1XCIJrhkWdRXeDq3O3wV8MDwM3obEKDa8Vj9K3f3HDXL0gKxZZJiHkFQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669937420; a=rsa-sha256; cv=none;
	b=T7q8U9SNkugJ1Dy3rVH3j2QpITywhx+CtBCkr4cSIO5RXwifRsmtTj6yeUvLMMACvJ//UA
	egRU8J2jqS7VYieeCZQsKOzwcDcHQD/R/othyvVZJOnmAKyu8nosOKm3BL61OCZD4cpYYz
	Ff4XoXx23y5MV9qZMak/EOFpqxNbsDAOtCmnSiQMzf/Sd9CT1VjD16bb7xMqnEsatVS/jy
	rwbPWGcJFIxFV60Ds6oa5d+tJbdaeKZI5aH8fkctoi3jkEuwyTBvlybFmfE2igaj14YiuJ
	UDO9FszGZwoj8TCNWz6JJZJC9gmf8qkOjXGZF9zpa0uxlwHDnUkJkb6JNwF03g==
Received: from localhost (p200300cb870eb368004b6908b0a32bda.dip0.t-ipconnect.de [IPv6:2003:cb:870e:b368:4b:6908:b0a3:2bda])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	(Authenticated sender: gbe)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NNXP80h5czNSC
	for ; Thu,  1 Dec 2022 23:30:19 +0000 (UTC)
	(envelope-from gbe@freebsd.org)
Date: Fri, 2 Dec 2022 00:30:19 +0100
From: Gordon Bergling 
To: current@freebsd.org
Subject: Buildword Error on a recent -CURRENT
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: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="1U8r/ZTGhw9dNCs3"
Content-Disposition: inline
X-Url: 
X-Operating-System: FreeBSD 13.1-STABLE amd64
X-Host-Uptime: 12:24AM  up 1 day,  7:18, 2 users, load averages: 1.06, 2.25,
 2.90
X-ThisMailContainsUnwantedMimeParts: N


--1U8r/ZTGhw9dNCs3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello,

I am currently having the following build work error on a recent
-CURRENT.

= ===> usr.bin/less (all)
  -16372 bytes available
  --- loader_lua.bin ---
  *** [loader_lua.bin] Error code 1

  make[5]: stopped in /boiler/nfs/src/stand/i386/loader_lua
  --- all_subdir_stand ---

  make[2]: stopped in /boiler/nfs/src
  --- all_subdir_lib ---

  make[2]: stopped in /boiler/nfs/src
  --- all_subdir_usr.bin ---

  make[2]: stopped in /boiler/nfs/src
  --- all_subdir_usr.sbin ---

  make[2]: stopped in /boiler/nfs/src
        240.29 real       849.36 user        73.97 sys
  --- everything ---

  make[1]: stopped in /boiler/nfs/src
  --- buildworld ---

  make: stopped in /boiler/nfs/src
  make[1]: "/boiler/nfs/src/Makefile.inc1" line 331: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler
  .
  make[1]: "/boiler/nfs/src/Makefile.inc1" line 334: SYSTEM_LINKER: Determined that LD=ld matches the source tree.  Not bootstr
  apping a cross-linker.

Has anyone seen this error before or has recommandation on how to solve it.

My src.conf for building -CURRENT is the following:

WITH_EXTRA_TCP_STACKS=1
WITH_BEARSSL=1
WITH_PIE=1
WITH_RETPOLINE=1
WITH_INIT_ALL_ZERO=1
WITH_OPENSSL_KTLS=1
WITHOUT_CLEAN=1

The usual step if something with WITHOUT_CLEAN isn't working
(deleting the obj directory) had no effect.

--Gordon

--1U8r/ZTGhw9dNCs3
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEYbWI0KY5X7yH/Fy4OQX2V8rP09wFAmOJOQlfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYx
QjU4OEQwQTYzOTVGQkM4N0ZDNUNCODM5MDVGNjU3Q0FDRkQzREMACgkQOQX2V8rP
09zo4gf9H6p03bmZTxOJF/0HSRcDdYZOrXqJ50gsAJ8Xqdipf5faarjVWRs1/xup
btd2tOuhs7alDgBsOVdBFNV9iS6RZCGd+IkPwUl53L1Dk9iwAUPLy+yYC1eiU2rp
BT+4cKeoOrG3ZLQ228zmGjSyXsDD9ZF6H8D3aPBK867IEh3/FSmpZ/5IKmzTRNBf
RnPJnuYdMjq/gpqVJsn9Rpfib8xXZhDl4dvTj8zerVbz/kNp0+mbrUTGpuhYSxVV
AE0gRYKgCldYoaaG2ETepgYR20gcDpL9uPeoVx8fbHRlO+tQR79zVvzHvnqbkmpl
D8JB9togiOmB9PNRU9KE78lyP8mSLA==
=CTwc
-----END PGP SIGNATURE-----

--1U8r/ZTGhw9dNCs3--

From nobody Fri Dec  2 01:14:53 2022
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 4NNZk14pRcz4jvTK
	for ; Fri,  2 Dec 2022 01:15:05 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NNZk12ryFz469n;
	Fri,  2 Dec 2022 01:15:05 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pf1-x42c.google.com with SMTP id l127so2887444pfl.2;
        Thu, 01 Dec 2022 17:15:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=f4NLHJQm6JDDiccjNK99upryKrGTdftx6RD4WPG+NI0=;
        b=ow79V1A+ep9u2AEIGUmd9ICjJIn5oJglHW72cJUfAClMAQjioLlC/CikJHWIg74Awg
         gUTxEcXHDqaPbd5ByLFlevEiv+1KQjscJnPYTnnKH3HbCnXCUHA2LusVJyjR/UN19ujI
         qcBNCRpYQo3qCp2Qb4prDQG72uRtJVc8u9j06JXTsy42m/ylfwMdTi3G5aig/7cSPZAj
         yMhXrIZVmC40iHICh/Mu4b2Ksp+KyaI9gmLkwvhPJRLxHzJFxWxo7lmuMoRiBYSjnTah
         4VzaHfuXqdAzbvfn5T7ddIMaT8GyVGJ6tiNL4HZdyADAFg7L+NBtmwc9GliOGv0kLFkG
         +AWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=f4NLHJQm6JDDiccjNK99upryKrGTdftx6RD4WPG+NI0=;
        b=AE5/STTdbNCxY+up9mXNSAwBmG0bjaA9vh/8CalpQ6FJfkZlrxk4GqnXGzFfcGkjKd
         j4X3AxLT1VD1KaRsMwtkeozUjOikY21t5IupA6bz+419mgOAp5F+UBH1oVDV+08FMzFV
         0J0NZrBepXRoCGBt6TyBc7J3ncjrIKcflqxXSk+Y1wc9siDoZl1IcaRWL7nd97yiiQV1
         E0PUyKgOtAKkU4bRWG3sZ16tDZ5qws6UOZ3LHxD5gzPaq2rWJfOoJ1qVNNPPRtdZHtR0
         3WLGNYQfEsJUKJcWDiqXqfjMYcSfjA4Gstvtqvkhm+ygCu/jhaTbJ7uoZhflUz1QkUBs
         A84g==
X-Gm-Message-State: ANoB5pmEuXHKne+hV/VfepuvWMAd6lLU+S5EcBqlep03hJrktEbewKw+
	P+ofuxEMDveINBmaw6oV/KHZdkirdFr5uppVYZMY2qg=
X-Google-Smtp-Source: AA0mqf7yxnM+iT/S8HCFBfMs6/N+mN2mkYc3eS5tlQNPbqDAh3XFiViL0OtzjTrZtVUnirPyzI2U/F1ltw7ZKLqaKgY=
X-Received: by 2002:a63:4944:0:b0:44e:466f:4759 with SMTP id
 y4-20020a634944000000b0044e466f4759mr43495628pgk.194.1669943703711; Thu, 01
 Dec 2022 17:15:03 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 
 <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se> 
  <20221201102925.Horde.uAC-87YyIRDDnqJTmvsFwNm@webmail.leidinger.net>
In-Reply-To: <20221201102925.Horde.uAC-87YyIRDDnqJTmvsFwNm@webmail.leidinger.net>
From: Rick Macklem 
Date: Thu, 1 Dec 2022 17:14:53 -0800
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: Alexander Leidinger 
Cc: Alan Somers , Peter Eriksson , 
	FreeBSD CURRENT , "Bjoern A. Zeeb" 
Content-Type: multipart/alternative; boundary="00000000000041358305eece11a9"
X-Rspamd-Queue-Id: 4NNZk12ryFz469n
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--00000000000041358305eece11a9
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 1, 2022 at 1:29 AM Alexander Leidinger 
wrote:

>
> Quoting Alan Somers  (from Tue, 29 Nov 2022
> 17:28:10 -0700):
>
> > On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem 
> wrote:
>
> >> So, what do others think of enforcing the requirement that each jail
> >> have its own file systems for this?
> >
> > I think that's a totally reasonable requirement.  Especially so for
> > ZFS users, who already create a filesystem per jail for other reasons.
>
> While I agree that it is a reasonable requirement, just a note that we
> can not assume that every existing jail resides on its own file
> system. The base system jail infrastructure doesn't check this, and
> the ezjail port doesn't either. The iocage port does it.
>
> Is there a way to detect this inside a jail and error out in nfsd/mountd?

I think the check (...->pr_root->v_vflag & VV_ROOT) is sufficient.
At least it is working for current testing.

rick

>
>
Bye,
> Alexander.
>
> --
> http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF
>

--00000000000041358305eece11a9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Dec 1, 2022 at 1:29 AM Alexander Leid=
inger <Alexander@leidinger.ne=
t> wrote:


Quoting Alan Somers <asomers@freebsd.org> (from Tue, 29 Nov 2022=C2=A0 

17:28:10 -0700):



> On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem <rick.macklem@gmail.com> wrote=
:



>> So, what do others think of enforcing the requirement that each ja=
il

>> have its own file systems for this?

>

> I think that's a totally reasonable requirement.=C2=A0 Especially =
so for

> ZFS users, who already create a filesystem per jail for other reasons.=




While I agree that it is a reasonable requirement, just a note that we=C2=
=A0 

can not assume that every existing jail resides on its own file=C2=A0 

system. The base system jail infrastructure doesn't check this, and=C2=
=A0 

the ezjail port doesn't either. The iocage port does it.



Is there a way to detect this inside a jail and error out in nfsd/mountd?
I think the check (...->pr_root->v_vflag & VV_ROOT) is suffici=
ent.
At least it is working for current testing.

<=
div>rick=C2=
=A0
=C2=A0

Bye,

Alexander.



-- 

h=
ttp://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF=


htt=
p://www.FreeBSD.org=C2=A0 =C2=A0 netchild@FreeBSD.org=C2=A0 : PGP 0x8F3=
1830F9F2772BF




--00000000000041358305eece11a9--

From nobody Fri Dec  2 01:21:49 2022
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 4NNZt11HtDz4jvxC
	for ; Fri,  2 Dec 2022 01:22:01 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NNZt05Gmdz47DD;
	Fri,  2 Dec 2022 01:22:00 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pf1-x435.google.com with SMTP id x66so3548157pfx.3;
        Thu, 01 Dec 2022 17:22:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=y1MLVTwCOnMo/Usq1NJtLYtShrZc0jy080rFYGRlj6g=;
        b=MxQkxcWJvMUOQpHY2Qr4fhaAPcfyZqIjtIqM0Vj79u0PLfz3Jf2F1/i7hMdWSipqcj
         6D2IQKre1NUKjYSSLeLoamGyFLAPuHcd/MEwiiqZAXxbYV5UWtj2TwvsPcDM1ZCs5Zb/
         jIxobcbxKiLMzebZS0kVd6d5atLJ06LcfDaTJFZaXFxl8mOavcxN8qKDt80p4KxUGgGY
         prCUBJS1X+yW7qs18udNP4Diu68uot0rx1T2tkHmmVpmsQHE8O/bUksr0oiNvyxdS6Hu
         65QeSrEHrC3DkjO23Pdhzd+WQ+ceI0l0JDX4kUd4v3v+qSFkC+YgWGKU8SFrcu6deRzB
         lt2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=y1MLVTwCOnMo/Usq1NJtLYtShrZc0jy080rFYGRlj6g=;
        b=cEH7zUsYtv7diZRDxJUITXp2TTjHogOT+p3uXMXxQWWClOaDhH6Ft9mFkF1+ZXCCJv
         /RXgoNVvQMWODBrqnD10RpR+jb/JcQfGSU0oipX4MkkwJ+1BdVZhnZE36rp9IgEDxO6j
         iHe+UYOPlKXIOTp1+JuzG/2x2DG9SXnUQxq7eislfBNAd+9xrl++EiotaxVFr3zPYySb
         xwlxV/n5vRNLOX0kJTLFiGzIExEamw3puYPJLBCsVljwWcRdEVySCDj38RsdqmErZUzN
         Dl9/0eqvO/UQXMajM7mTuyKcpOCJr/W8qqi+FDzXbNGN03lXofqMFSeEcHV2VdFrxz4e
         RCaQ==
X-Gm-Message-State: ANoB5plv5j7dPFXGs3qd5b0u4e3qC2iJJGrwg+ffxAGq3uiWEVhMkDtG
	oWxe+jLfYpaBcHSZc18kI3uLhmBbr62nW90RXw==
X-Google-Smtp-Source: AA0mqf40MJe7nXlQKJRDZ5ajFgHKiPHszPtTbnDu2VMM+0imPnooFHp+NlQmPMAVw0We34runBgTDVAziTEzU988xfc=
X-Received: by 2002:a63:4944:0:b0:44e:466f:4759 with SMTP id
 y4-20020a634944000000b0044e466f4759mr43517180pgk.194.1669944119534; Thu, 01
 Dec 2022 17:21:59 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 
 <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se> 
 
 <20221201102925.Horde.uAC-87YyIRDDnqJTmvsFwNm@webmail.leidinger.net> <20221201110137.08b2b68c@zeta.dino.sk>
In-Reply-To: <20221201110137.08b2b68c@zeta.dino.sk>
From: Rick Macklem 
Date: Thu, 1 Dec 2022 17:21:49 -0800
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: Milan Obuch 
Cc: freebsd-current@freebsd.org, Alexander Leidinger , 
	Alan Somers , Peter Eriksson , bz@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000000a2a9805eece2a5f"
X-Rspamd-Queue-Id: 4NNZt05Gmdz47DD
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--0000000000000a2a9805eece2a5f
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 1, 2022 at 2:01 AM Milan Obuch  wrote:

> On Thu, 01 Dec 2022 10:29:25 +0100
> Alexander Leidinger  wrote:
>
> > Quoting Alan Somers  (from Tue, 29 Nov 2022
> > 17:28:10 -0700):
> >
> > > On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem
> > >  wrote:
> >
> > >> So, what do others think of enforcing the requirement that each
> > >> jail have its own file systems for this?
> > >
> > > I think that's a totally reasonable requirement.  Especially so for
> > > ZFS users, who already create a filesystem per jail for other
> > > reasons.
> >
> > While I agree that it is a reasonable requirement, just a note that
> > we can not assume that every existing jail resides on its own file
> > system. The base system jail infrastructure doesn't check this, and
> > the ezjail port doesn't either. The iocage port does it.
> >
>
> My position would be 'recommended, but not forced-to' one. I have
> various installations with jails sharing parts of filesystem (like
> ports or src tree for development, or even local git repository), or
> even running with exactly the same directory as root of number of
> jails. Probably not a common scenario for sure, but still useful.
>
Others indicate they want mountd to run inside the jail.
To get that to work, the jail needs to be in a separate file
system, since it is the file system(s) mount point(s) that the
export information is attached to in the kernel.

It comes down to...
#1 - Run mountd outside of the jails and encourage use of separate
  file systems.
  (Also, since the exports information would be applied to the file
   system(s) and not the jails, a malicious NFS client could
   "guess" a file handle and access files outside of the jail.
   This seems counter to what a jail should provide.)
OR
#2 - Require separate file systems and run mountd inside the jail(s).

I think that allowing both alternatives would be too confusing
and it seems that most want mountd to run within the jail(s).
As such, unless others prefer #1, I think #2 is the way to go.

rick

>
> Regards,
> Milan
>

--0000000000000a2a9805eece2a5f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Dec 1, 2022 at 2:01 AM Milan Obuch &l=
t;freebsd-current@dino.sk>=
; wrote:
On Thu,=
 01 Dec 2022 10:29:25 +0100

Alexander Leidinger <Alexander@leidinger.net> wrote:



> Quoting Alan Somers <asomers@freebsd.org> (from Tue, 29 Nov 2022=C2=A0 

> 17:28:10 -0700):

> 

> > On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem

> > <r=
ick.macklem@gmail.com> wrote:=C2=A0 

> 

> >> So, what do others think of enforcing the requirement that ea=
ch

> >> jail have its own file systems for this?=C2=A0 

> >

> > I think that's a totally reasonable requirement.=C2=A0 Especi=
ally so for

> > ZFS users, who already create a filesystem per jail for other

> > reasons.=C2=A0 

> 

> While I agree that it is a reasonable requirement, just a note that
> we can not assume that every existing jail resides on its own file=C2=
=A0 

> system. The base system jail infrastructure doesn't check this, an=
d=C2=A0 

> the ezjail port doesn't either. The iocage port does it.

>



My position would be 'recommended, but not forced-to' one. I have
various installations with jails sharing parts of filesystem (like

ports or src tree for development, or even local git repository), or

even running with exactly the same directory as root of number of

jails. Probably not a common scenario for sure, but still useful.
O=
thers indicate they want mountd to run inside the jail.
To get that to =
work, the jail needs to be in a separate file
system, since it is the =
file system(s) mount point(s) that the
export information is attached t=
o in the kernel.

It comes down to...
#1 - Run mountd outsi=
de of the jails and encourage use of separate
=C2=A0 file systems.
=C2=A0 (Also, since the exports information would be applied to the file
=C2=A0 =C2=A0system(s) and not the jails, a malicious NFS client could
=C2=A0 =C2=A0"guess" a file handle and access files outside of=
 the jail.
=C2=A0 =C2=A0This seems counter to what a jail should provid=
e.)
OR
#2 - Require separate file systems and run mountd inside the=
 jail(s).

I think that allowing both alternatives would be too=
 confusing
and it seems that most want mountd to run within the jail(s)=
.
As such, unless others prefer #1, I think #2 is the way to go.=

rick=C2=A0



Regards,

Milan




--0000000000000a2a9805eece2a5f--

From nobody Fri Dec  2 01:32:26 2022
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 4NNb6G392bz4jxMM
	for ; Fri,  2 Dec 2022 01:32:38 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NNb6G2YWYz4B6w;
	Fri,  2 Dec 2022 01:32:38 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pj1-x102d.google.com with SMTP id w15-20020a17090a380f00b0021873113cb4so3851304pjb.0;
        Thu, 01 Dec 2022 17:32:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=ppmxmYSUwoN+v3t3yn+I+YH8Loer49ChQ1IxboJTYWM=;
        b=jFdnLeZ17g/Dt2SiFV25TzxqnVAf7etuzI2J2hAeModwItMPLXx2BUCTW+fzrqhSy+
         YKyvZ0QPy7PwHNevKfgfsQodZ+goXToZ8aEOd3yfhglRxgoTMkKe94DdNcf6Q5uLHT1D
         VSs60eteJK+xHZd5UE46ORdmB3TusuqUGD+xJ77fNEFQjIAz31+qE45Ss3mnRTbQQHsG
         cIIX6SsWeXN0jcPQxLg0DcacOP9KmeZGkbno6PwGj8B1gKSs4clsreEi3Sy4Fu9CgF8Q
         jY5tft2YgyS/pcgv1HJQvUHZcRsuzWJiz5Oxif/hZFfOfMVK5nKOviEqVbgmpWrGdGwY
         qnjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ppmxmYSUwoN+v3t3yn+I+YH8Loer49ChQ1IxboJTYWM=;
        b=cfYybltDppuo3xMFAgCl8/hEBXn5Q3xK99gVvMEC4fGzuvgb4s8Przd/t3ZDzb53l4
         aoBmt6q3G5te/KqeCwy7DU0ho6rgbzGxh2Gzk9WriDMiXNdDFlfXz2diwUb2IoOlKTWd
         jVymka1SIQkqpKkrZiIKmEFz0rJSU9N+4qoDhyiBOUjPm4TMy2tnayxe922psMhhcYRr
         TbHv3TmxqvjOGF4QSdWpdMod/OpUeTiRWRXuCo7Ph5t+scPy9P+pymOOoozGaOkTwkck
         TQ6hS9zK3iParVhKxgD0YyyPf6YHeEd6t12leDd298WL2mKjRoFWczI/L5c1MuTsrOcr
         J1Pw==
X-Gm-Message-State: ANoB5pkyn+VtdcwVfDoz6NW+sIYoUgFGFOzHiGJxXGGhUeE3m6qs3W+O
	wlWAA5MPnihJNz43DsooN6p8Joly23Rw2fYdLA==
X-Google-Smtp-Source: AA0mqf4eWCnVwlc4sdc3FfNymUGx7odz6csC9aIge9S6si3kaUgSnEEPJYzPCoEDHIQvIBjHb4jAphgF2ms5lClcKH0=
X-Received: by 2002:a17:902:c104:b0:189:a931:c8a1 with SMTP id
 4-20020a170902c10400b00189a931c8a1mr11657914pli.112.1669944757315; Thu, 01
 Dec 2022 17:32:37 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 
 <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se> 
 <2980bcbd22f884962d358808f9440d77@bsdforge.com>
In-Reply-To: <2980bcbd22f884962d358808f9440d77@bsdforge.com>
From: Rick Macklem 
Date: Thu, 1 Dec 2022 17:32:26 -0800
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: Chris 
Cc: Peter Eriksson , FreeBSD CURRENT , 
	"Bjoern A. Zeeb" , Alan Somers 
Content-Type: multipart/alternative; boundary="0000000000000debab05eece505c"
X-Rspamd-Queue-Id: 4NNb6G2YWYz4B6w
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	TAGGED_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--0000000000000debab05eece505c
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 1, 2022 at 8:23 AM Chris  wrote:

> On 2022-11-29 16:21, Rick Macklem wrote:
> > On Sun, Nov 27, 2022 at 10:04 AM Peter Eriksson 
> wrote:
> >
> >> Keep the global variables as defaults that apply to all nfsds and allow
> >> (at least some subset) to be overridden inside the net jails if some
> things
> >> need to be changed from the defaults?
> >>
> >> This is pretty much a reply to one of the posts selected at random,
> > but I thought that better than starting a new email thread.
> >
> > bz@ and asomers@ have both asked about running mountd within a vnet
> prison
> > (one via offlist email and the other on phabricator).
> >
> > I think it is worth discussing here...
> > mountd (rightly or wrongly) does two distinctly different things:
> > 1 - It pushes the exports into the kernel via nmount() so they
> >     can be hung off of the "struct mount" for a file system's
> >     mount point.
> >     --> This can only work for file system mount points and can
> >         only be done once for any given file system mount point.
> >
> >     At this time, I have it done once globally outside of the prisons.
> >     The alternative I can see is doing it within each prison, but I
> >     think that would require that each prison have its own file
> system(s).
> >     (ie. The prison's root would always be a file system mount point.)
> >
> > 2 - It handles RPC Mount protocol requests from NFSv3 clients.  This one
> >     is NFSv3 specific, which is why I have done this NFSv4 only at
> >     this time.  To do this, it must be able to register with rpcbind,
> >     and I have no idea if running rpcbind in a vnet jail is practical.
> >
> > Enforcing the use for separate file systems for each jail also makes
> > things safer, since the exports are enforced by the kernel. Without
> > this, a malicious NFSv4 client could "guess" a file handle for a file
> > outside the jail and gain access to that file. Put another way, without
> > a separate file system, there is no way to stop a malicious client from
> > finding files above the Root file handle. (Normal clients will use
> > PutRootFH and LookupParent and these won't be able to go above the top
> > of the jail.)
> >
> > So, what do others think of enforcing the requirement that each jail
> > have its own file systems for this?
>
> I don't care for any of it. It looks like additional overhead with the
> addition of potential security risks. All for a very limited (and as yet
> unknown) use case.
>
I am thinking that if/when this goes into main, it would be
under a new kernel build option called something like
NFSD_VIMAGE. I think that would avoid the overhead/security
risks for those that do not need/want it.

rick

>
> --chris
> >
> > rick
> >
> >
> >> - Peter
> >>
> >>
> >> On Fri, Nov 25, 2022, 4:24 PM Rick Macklem 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> bz@ has encouraged me to fiddle with the nfsd
> >>> so that it works in a vnet jail.
> >>> I have now basically done so, specifically for
> >>> NFSv4, since NFSv3 presents various issues.
> >>>
> >>> What I have not yet done is put global variables
> >>> in the vnet. This needs to be done so that the nfsd
> >>> can be run in multiple jail instances and/or in and
> >>> outside of a jail.
> >>> The problem is that there are 100s of global variables.
> >>>
> >>> I can see two approaches:
> >>> 1 - Move them all into the vnet jail. This would imply
> >>>     that all the sysctls need to somehow be changed,
> >>>     which would seem to be a POLA violation.
> >>>     It also implies a lot of stuff in the vnet.
> >>> 2 - Just move the global variables that will always
> >>>     differ from one nfsd to another (this would make
> >>>     the sysctls global and apply to all nfsds).
> >>>     This will keep the number of globals in the vnet
> >>>     smaller.
> >>>
> >>> I am currently leaning towards #2, put what do others
> >>> think?
> >>>
> >>> rick
> >>> ps: Personally, I don't know what use there is of
> >>>     running the nfsd inside a vnet jail, but bz@ has
> >>>     some use case.
> >>>
> >>
> >>
>

--0000000000000debab05eece505c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Dec 1, 2022 at 8:23 AM Chris <bsd-lists@bsdforge.com> wrote:=

On 2022-11-29 1=
6:21, Rick Macklem wrote:

> On Sun, Nov 27, 2022 at 10:04 AM Peter Eriksson <pen@lysator.liu.se> wrote:

> 

>> Keep the global variables as defaults that apply to all nfsds and =
allow

>> (at least some subset) to be overridden inside the net jails if so=
me things

>> need to be changed from the defaults?

>> 

>> This is pretty much a reply to one of the posts selected at random=
,

> but I thought that better than starting a new email thread.

> 

> bz@ and asomers@ have both asked about running mountd within a vnet pr=
ison

> (one via offlist email and the other on phabricator).

> 

> I think it is worth discussing here...

> mountd (rightly or wrongly) does two distinctly different things:

> 1 - It pushes the exports into the kernel via nmount() so they

>=C2=A0 =C2=A0 =C2=A0can be hung off of the "struct mount" for=
 a file system's

>=C2=A0 =C2=A0 =C2=A0mount point.

>=C2=A0 =C2=A0 =C2=A0--> This can only work for file system mount poi=
nts and can

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only be done once for any given file =
system mount point.

> 

>=C2=A0 =C2=A0 =C2=A0At this time, I have it done once globally outside =
of the prisons.

>=C2=A0 =C2=A0 =C2=A0The alternative I can see is doing it within each p=
rison, but I

>=C2=A0 =C2=A0 =C2=A0think that would require that each prison have its =
own file system(s).

>=C2=A0 =C2=A0 =C2=A0(ie. The prison's root would always be a file s=
ystem mount point.)

> 

> 2 - It handles RPC Mount protocol requests from NFSv3 clients.=C2=A0 T=
his one

>=C2=A0 =C2=A0 =C2=A0is NFSv3 specific, which is why I have done this NF=
Sv4 only at

>=C2=A0 =C2=A0 =C2=A0this time.=C2=A0 To do this, it must be able to reg=
ister with rpcbind,

>=C2=A0 =C2=A0 =C2=A0and I have no idea if running rpcbind in a vnet jai=
l is practical.

> 

> Enforcing the use for separate file systems for each jail also makes
> things safer, since the exports are enforced by the kernel. Without
> this, a malicious NFSv4 client could "guess" a file handle f=
or a file

> outside the jail and gain access to that file. Put another way, withou=
t

> a separate file system, there is no way to stop a malicious client fro=
m

> finding files above the Root file handle. (Normal clients will use

> PutRootFH and LookupParent and these won't be able to go above the=
 top

> of the jail.)

> 

> So, what do others think of enforcing the requirement that each jail
> have its own file systems for this?



I don't care for any of it. It looks like additional overhead with the<=
br>
addition of potential security risks. All for a very limited (and as yet
unknown) use case.
I am thinking that if/when this goes into main, =
it would be
under a new kernel build option called something like
N=
FSD_VIMAGE. I think that would avoid the overhead/security
risks for th=
ose that do not need/want it.

rick=C2=A0



--chris

> 

> rick

> 

> 

>> - Peter

>> 

>> 

>> On Fri, Nov 25, 2022, 4:24 PM Rick Macklem <rick.macklem@gmail.com> wro=
te:

>> 

>>> Hi,

>>> 

>>> bz@ has encouraged me to fiddle with the nfsd

>>> so that it works in a vnet jail.

>>> I have now basically done so, specifically for

>>> NFSv4, since NFSv3 presents various issues.

>>> 

>>> What I have not yet done is put global variables

>>> in the vnet. This needs to be done so that the nfsd

>>> can be run in multiple jail instances and/or in and

>>> outside of a jail.

>>> The problem is that there are 100s of global variables.

>>> 

>>> I can see two approaches:

>>> 1 - Move them all into the vnet jail. This would imply

>>>=C2=A0 =C2=A0 =C2=A0that all the sysctls need to somehow be cha=
nged,

>>>=C2=A0 =C2=A0 =C2=A0which would seem to be a POLA violation.
>>>=C2=A0 =C2=A0 =C2=A0It also implies a lot of stuff in the vnet.=


>>> 2 - Just move the global variables that will always

>>>=C2=A0 =C2=A0 =C2=A0differ from one nfsd to another (this would=
 make

>>>=C2=A0 =C2=A0 =C2=A0the sysctls global and apply to all nfsds).=


>>>=C2=A0 =C2=A0 =C2=A0This will keep the number of globals in the=
 vnet

>>>=C2=A0 =C2=A0 =C2=A0smaller.

>>> 

>>> I am currently leaning towards #2, put what do others

>>> think?

>>> 

>>> rick

>>> ps: Personally, I don't know what use there is of

>>>=C2=A0 =C2=A0 =C2=A0running the nfsd inside a vnet jail, but bz=
@ has

>>>=C2=A0 =C2=A0 =C2=A0some use case.

>>> 

>> 

>> 




--0000000000000debab05eece505c--

From nobody Fri Dec  2 05:42:12 2022
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 4NNhfQ6NDBz4jLXc
	for ; Fri,  2 Dec 2022 05:42:22 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NNhfQ1KSqz3HcB;
	Fri,  2 Dec 2022 05:42:22 +0000 (UTC)
	(envelope-from bsd-lists@bsdforge.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of bsd-lists@bsdforge.com has no SPF policy when checking 24.113.41.81) 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 2B25gDtv006364;
	Thu, 1 Dec 2022 21:42:19 -0800 (PST)
	(envelope-from bsd-lists@bsdforge.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
Date: Thu, 01 Dec 2022 21:42:12 -0800
From: Chris 
To: Rick Macklem 
Cc: Peter Eriksson ,
        FreeBSD CURRENT
 ,
        "Bjoern A. Zeeb" , Alan
 Somers 
Subject: Re: RFC: nfsd in a vnet jail
In-Reply-To: 
References: 
 
 <82103A1E-9D39-47B0-9520-205583C8B680@lysator.liu.se>
 
 <2980bcbd22f884962d358808f9440d77@bsdforge.com>
 
User-Agent: UDNSMS/17.0
Message-ID: 
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_a077a3193a9a3f9f829df144783ea915"
X-Rspamd-Queue-Id: 4NNhfQ1KSqz3HcB
X-Spamd-Bar: +
X-Spamd-Result: default: False [1.50 / 15.00];
	SUSPICIOUS_RECIPS(1.50)[];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	local_wl_ip(0.00)[24.113.41.81];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	HAS_ATTACHMENT(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	TAGGED_RCPT(0.00)[];
	R_SPF_NA(0.00)[no SPF record]
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-ThisMailContainsUnwantedMimeParts: N

--=_a077a3193a9a3f9f829df144783ea915
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-12-01 17:32, Rick Macklem wrote:
> On Thu, Dec 1, 2022 at 8:23 AM Chris  wrote:
> 
>> On 2022-11-29 16:21, Rick Macklem wrote:
>> > On Sun, Nov 27, 2022 at 10:04 AM Peter Eriksson 
>> wrote:
>> >
>> >> Keep the global variables as defaults that apply to all nfsds and allow
>> >> (at least some subset) to be overridden inside the net jails if some
>> things
>> >> need to be changed from the defaults?
>> >>
>> >> This is pretty much a reply to one of the posts selected at random,
>> > but I thought that better than starting a new email thread.
>> >
>> > bz@ and asomers@ have both asked about running mountd within a vnet
>> prison
>> > (one via offlist email and the other on phabricator).
>> >
>> > I think it is worth discussing here...
>> > mountd (rightly or wrongly) does two distinctly different things:
>> > 1 - It pushes the exports into the kernel via nmount() so they
>> >     can be hung off of the "struct mount" for a file system's
>> >     mount point.
>> >     --> This can only work for file system mount points and can
>> >         only be done once for any given file system mount point.
>> >
>> >     At this time, I have it done once globally outside of the prisons.
>> >     The alternative I can see is doing it within each prison, but I
>> >     think that would require that each prison have its own file
>> system(s).
>> >     (ie. The prison's root would always be a file system mount point.)
>> >
>> > 2 - It handles RPC Mount protocol requests from NFSv3 clients.  This one
>> >     is NFSv3 specific, which is why I have done this NFSv4 only at
>> >     this time.  To do this, it must be able to register with rpcbind,
>> >     and I have no idea if running rpcbind in a vnet jail is practical.
>> >
>> > Enforcing the use for separate file systems for each jail also makes
>> > things safer, since the exports are enforced by the kernel. Without
>> > this, a malicious NFSv4 client could "guess" a file handle for a file
>> > outside the jail and gain access to that file. Put another way, without
>> > a separate file system, there is no way to stop a malicious client from
>> > finding files above the Root file handle. (Normal clients will use
>> > PutRootFH and LookupParent and these won't be able to go above the top
>> > of the jail.)
>> >
>> > So, what do others think of enforcing the requirement that each jail
>> > have its own file systems for this?
>> 
>> I don't care for any of it. It looks like additional overhead with the
>> addition of potential security risks. All for a very limited (and as yet
>> unknown) use case.
>> 
> I am thinking that if/when this goes into main, it would be
> under a new kernel build option called something like
> NFSD_VIMAGE. I think that would avoid the overhead/security
> risks for those that do not need/want it.
Brilliant. Count me in. :-)

--chris
> 
> rick
> 
>> 
>> --chris
>> >
>> > rick
>> >
>> >
>> >> - Peter
>> >>
>> >>
>> >> On Fri, Nov 25, 2022, 4:24 PM Rick Macklem 
>> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> bz@ has encouraged me to fiddle with the nfsd
>> >>> so that it works in a vnet jail.
>> >>> I have now basically done so, specifically for
>> >>> NFSv4, since NFSv3 presents various issues.
>> >>>
>> >>> What I have not yet done is put global variables
>> >>> in the vnet. This needs to be done so that the nfsd
>> >>> can be run in multiple jail instances and/or in and
>> >>> outside of a jail.
>> >>> The problem is that there are 100s of global variables.
>> >>>
>> >>> I can see two approaches:
>> >>> 1 - Move them all into the vnet jail. This would imply
>> >>>     that all the sysctls need to somehow be changed,
>> >>>     which would seem to be a POLA violation.
>> >>>     It also implies a lot of stuff in the vnet.
>> >>> 2 - Just move the global variables that will always
>> >>>     differ from one nfsd to another (this would make
>> >>>     the sysctls global and apply to all nfsds).
>> >>>     This will keep the number of globals in the vnet
>> >>>     smaller.
>> >>>
>> >>> I am currently leaning towards #2, put what do others
>> >>> think?
>> >>>
>> >>> rick
>> >>> ps: Personally, I don't know what use there is of
>> >>>     running the nfsd inside a vnet jail, but bz@ has
>> >>>     some use case.
>> >>>
>> >>
>> >>
>> 

--=_a077a3193a9a3f9f829df144783ea915
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_a077a3193a9a3f9f829df144783ea915--

From nobody Fri Dec  2 10:03:01 2022
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 4NNpRF302Rz4hxjm
	for ; Fri,  2 Dec 2022 10:03:05 +0000 (UTC)
	(envelope-from olivier.freebsd@free.fr)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15])
	(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 4NNpRD6T91z480X
	for ; Fri,  2 Dec 2022 10:03:04 +0000 (UTC)
	(envelope-from olivier.freebsd@free.fr)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=free.fr header.s=smtp-20201208 header.b=EigQ3UIB;
	spf=pass (mx1.freebsd.org: domain of olivier.freebsd@free.fr designates 2a01:e0c:1:1599::15 as permitted sender) smtp.mailfrom=olivier.freebsd@free.fr;
	dmarc=pass (policy=none) header.from=free.fr
Received: from ravel.localnet (unknown [109.210.33.132])
	(Authenticated sender: olivier.freebsd@free.fr)
	by smtp6-g21.free.fr (Postfix) with ESMTPSA id 51FD078039B;
	Fri,  2 Dec 2022 11:03:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr;
	s=smtp-20201208; t=1669975383;
	bh=sQRv3VeEOWc0uD4lu98Dul6Svbx6D14v20PaM6GAcuc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=EigQ3UIBjS878BjaxZOgtENzs6CotgnAvmiHlp94uLrPh1Pcx3VdWnPSF24zCvH/6
	 7J72tE4UXbxEGfHTY8oJ5lRO3jsn8Y1aeoB9woD0hAmoaxuzi48ZMIZkljjZYZdeMU
	 9+1gzXGFO3g6ApKDJngFDPQGvk/B6MZzNPF2ZRmTOKMUEt0lSR8meQWP7I5xunISOp
	 ByM1ja25y6qRnQHvzbhOvYV6dD+T/voHB9AZ8IXlpVxr0k72z6wcgevFK4tAN6xVLm
	 NiLvpTKh49e94SLhhOj8Thn+knOVytJ6tWYgVDBxi75RXV2oTAl5K3xwk+kikTe64q
	 1RE0FmOvNBg1w==
From: Olivier Certner 
To: freebsd-current@freebsd.org, Rick Macklem 
Subject: Re: RFC: nfsd in a vnet jail
Date: Fri, 02 Dec 2022 11:03:01 +0100
Message-ID: <1955021.aDjkhKmpDe@ravel>
In-Reply-To: 
References:  <20221201110137.08b2b68c@zeta.dino.sk> 
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-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Result: default: False [-2.91 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.91)[-0.905];
	DMARC_POLICY_ALLOW(-0.50)[free.fr,none];
	CTE_CASE(0.50)[];
	MID_RHS_NOT_FQDN(0.50)[];
	R_DKIM_ALLOW(-0.20)[free.fr:s=smtp-20201208];
	R_SPF_ALLOW(-0.20)[+ip6:2a01:e0c:1:1599::15:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TAGGED_RCPT(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2a01:e0c:1:1599::15:from];
	ARC_NA(0.00)[];
	FREEMAIL_ENVFROM(0.00)[free.fr];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[free.fr:+];
	FREEMAIL_FROM(0.00)[free.fr];
	TO_DN_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[free.fr:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[freebsd.org,gmail.com];
	ASN(0.00)[asn:12322, ipnet:2a01:e00::/26, country:FR];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NNpRD6T91z480X
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

Hi,

> (snip)
>
> #2 - Require separate file systems and run mountd inside the jail(s).
>
> I think that allowing both alternatives would be too confusing
> and it seems that most want mountd to run within the jail(s).
> As such, unless others prefer #1, I think #2 is the way to go.

Just to be sure I've understood correctly: You plan to make a separate 
filesystem as jail's root a requirement but only in the case of using 
mountd(8) in the jail? Or in general?

While I think doing so in the NFSv4/mountd case is indeed a good idea, I don't 
think enforcing it in general is. It would generally degrade the multiple 
jails management experience on UFS (in the absence of a volume manager), where 
all jails have roots in the same filesystem (to avoid allocating/deallocating 
space as jails come and go or must be resized).

Regards.

-- 
Olivier Certner



From nobody Fri Dec  2 10:18:21 2022
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 UTF8SMTP id 4NNpn44sT1z4j0mC
	for ; Fri,  2 Dec 2022 10:18:32 +0000 (UTC)
	(envelope-from freebsd-current@dino.sk)
Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72])
	(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 UTF8SMTPS id 4NNpn36T9Lz4CZS
	for ; Fri,  2 Dec 2022 10:18:31 +0000 (UTC)
	(envelope-from freebsd-current@dino.sk)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of freebsd-current@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-current@dino.sk;
	dmarc=none
Received: from zeta.dino.sk ([84.245.95.254])
  (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384)
  by cm0.netlabit.sk with ESMTPSA
  id 00000000025A8264.000000006389D0EF.000050F2; Fri, 02 Dec 2022 11:18:23 +0100
Date: Fri, 2 Dec 2022 11:18:21 +0100
From: Milan Obuch 
To: freebsd-current@freebsd.org
Subject: Re: RFC: nfsd in a vnet jail
Message-ID: <20221202111821.08d94524@zeta.dino.sk>
In-Reply-To: <1955021.aDjkhKmpDe@ravel>
References: 
	<20221201110137.08b2b68c@zeta.dino.sk>
	
	<1955021.aDjkhKmpDe@ravel>
X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd13.1)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-3.29 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[dino.sk];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NNpn36T9Lz4CZS
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On Fri, 02 Dec 2022 11:03:01 +0100
Olivier Certner  wrote:

> Hi,
> 
> > (snip)
> >
> > #2 - Require separate file systems and run mountd inside the
> > jail(s).
> >
> > I think that allowing both alternatives would be too confusing
> > and it seems that most want mountd to run within the jail(s).
> > As such, unless others prefer #1, I think #2 is the way to go.  
> 
> Just to be sure I've understood correctly: You plan to make a
> separate filesystem as jail's root a requirement but only in the case
> of using mountd(8) in the jail? Or in general?
> 
> While I think doing so in the NFSv4/mountd case is indeed a good
> idea, I don't think enforcing it in general is. It would generally
> degrade the multiple jails management experience on UFS (in the
> absence of a volume manager), where all jails have roots in the same
> filesystem (to avoid allocating/deallocating space as jails come and
> go or must be resized).
> 

Exactly my thoughts. If forced generally, it would mean jails are no
longer usable, effectively, for UFS based devices. Or, possibly, 'entry
costs' for using jails would be much higher and thus less used. In my
eyes, they will be no longer lightweight virtualisation tool, main jail
selling point for me.

Regards,
Milan

From nobody Fri Dec  2 14:44:30 2022
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 4NNwh971Hyz4jcv5
	for ; Fri,  2 Dec 2022 14:44:41 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NNwh93vL2z3Nr5
	for ; Fri,  2 Dec 2022 14:44:41 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pg1-x52f.google.com with SMTP id s196so4544927pgs.3
        for ; Fri, 02 Dec 2022 06:44:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=JjpjTaGxUGAo7K328a+c2YpdWjGY6+2kmxC42oM1aI4=;
        b=bIGkTBmHFNXP6VEgt7XwmqwPOLfn7mxwOn//zKpxudaKSFXykoYc9iadKxrERNED/0
         MNZUnyDuvQmWNB2NK6m5BccnYq7pNdulMFd84HZdn1XcNmFu3okyJWV9h0nyYk/Zxwnm
         t+/gWOC+fG0zx+h9kfTziznlkzxFF0Jfn7kaAJSfDBcHo96vCy60Vfgj2gRN27MT4XtV
         ZKWamkl6svk7BXRRTZc+XS9bkWxuRQa66KBVl6kQm1QvkmyxqybzdtgBTV4CBk5+1aob
         WOOd811OCdvoD3j6kZqXapDp9J9VGtSFlYKmnPqT775C2oSrRD4z93VirRtj5Cg/qgVM
         2/Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=JjpjTaGxUGAo7K328a+c2YpdWjGY6+2kmxC42oM1aI4=;
        b=tEXO3ePhYJzC/kO5tAlBaVCcSUqON7tzNt4bBFr3TvphuaCAX0FEhFJj0+QG1tdVB3
         uulODHGHk7ViBdV9NXu6kXOXGGpOvwTL8p5ZErUZ4PzDIQNEdtd3jApKqTWKtF6l8gyz
         LUJY5jDYda2xO3MsHvui24IueyNj+nys2uHMvUx0v+h2jAcffrfA6F1MHJ1jD05Ba4vc
         viVacEs5RAbmA8PUpGAhABc3D7wDKarzwTFe8iJuvvansleoG+OeUEN1IbgBO1mJ6vp1
         Il6HExOUq65PtuPzw6TxxX4ZPlfuY/aWnesrUI36HB5Bm3KrkAjCP7Q7f9BigUmnfMqC
         XQKw==
X-Gm-Message-State: ANoB5pkKFF7DOfv+LRCOQ851HUWGEhIT+1t92lXIS8GaFL0d5xpvXAxl
	Cj8V1GuILZZDjk2l+w5t4M6GlzoE2be1WYCn1w==
X-Google-Smtp-Source: AA0mqf6gE/E6oIZl4BnciC49BUwWwMMmBCjj8uIZI/8ym3F9gbldxgZ3OCrQj0qd2iFLKzP1gSosZKyVj8x8GHB460s=
X-Received: by 2002:a05:6a00:21c8:b0:562:e0fb:3c79 with SMTP id
 t8-20020a056a0021c800b00562e0fb3c79mr52376040pfj.39.1669992280445; Fri, 02
 Dec 2022 06:44:40 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 <20221201110137.08b2b68c@zeta.dino.sk> 
 <1955021.aDjkhKmpDe@ravel>
In-Reply-To: <1955021.aDjkhKmpDe@ravel>
From: Rick Macklem 
Date: Fri, 2 Dec 2022 06:44:30 -0800
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: Olivier Certner 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000a7568c05eed96081"
X-Rspamd-Queue-Id: 4NNwh93vL2z3Nr5
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000a7568c05eed96081
Content-Type: text/plain; charset="UTF-8"

On Fri, Dec 2, 2022 at 2:03 AM Olivier Certner 
wrote:

> Hi,
>
> > (snip)
> >
> > #2 - Require separate file systems and run mountd inside the jail(s).
> >
> > I think that allowing both alternatives would be too confusing
> > and it seems that most want mountd to run within the jail(s).
> > As such, unless others prefer #1, I think #2 is the way to go.
>
> Just to be sure I've understood correctly: You plan to make a separate
> filesystem as jail's root a requirement but only in the case of using
> mountd(8) in the jail? Or in general?
>
Certainly not in general. Current plan is for the case of mountd/nfsd.

To enforce it for cases where mountd/nfsd is not being run would
definitely be a POLA violation.

rick


>
> While I think doing so in the NFSv4/mountd case is indeed a good idea, I
> don't
> think enforcing it in general is. It would generally degrade the multiple
> jails management experience on UFS (in the absence of a volume manager),
> where
> all jails have roots in the same filesystem (to avoid
> allocating/deallocating
> space as jails come and go or must be resized).
>
> Regards.
>
> --
> Olivier Certner
>
>
>

--000000000000a7568c05eed96081
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Dec 2, 2022 at 2:03 AM Olivier Certne=
r <olivier.freebsd@free.fr> wrote:
Hi,=




> (snip)

>

> #2 - Require separate file systems and run mountd inside the jail(s).<=
br>
>

> I think that allowing both alternatives would be too confusing

> and it seems that most want mountd to run within the jail(s).

> As such, unless others prefer #1, I think #2 is the way to go.



Just to be sure I've understood correctly: You plan to make a separate =


filesystem as jail's root a requirement but only in the case of using <=
br>
mountd(8) in the jail? Or in general?





While I think doing so in the NFSv4/mountd case is indeed a good idea, I do=
n't 

think enforcing it in general is. It would generally degrade the multiple <=
br>
jails management experience on UFS (in the absence of a volume manager), wh=
ere 

all jails have roots in the same filesystem (to avoid allocating/deallocati=
ng 

space as jails come and go or must be resized).



Regards.



-- 

Olivier Certner








--000000000000a7568c05eed96081--

From nobody Fri Dec  2 15:41:31 2022
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 4NNxxq3yzzz4jkv0
	for ; Fri,  2 Dec 2022 15:41:35 +0000 (UTC)
	(envelope-from olivier.freebsd@free.fr)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NNxxp5Y96z3k7p
	for ; Fri,  2 Dec 2022 15:41:34 +0000 (UTC)
	(envelope-from olivier.freebsd@free.fr)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=free.fr header.s=smtp-20201208 header.b=Jen0maDo;
	spf=pass (mx1.freebsd.org: domain of olivier.freebsd@free.fr designates 212.27.42.6 as permitted sender) smtp.mailfrom=olivier.freebsd@free.fr;
	dmarc=pass (policy=none) header.from=free.fr
Received: from ravel.localnet (unknown [109.210.33.132])
	(Authenticated sender: olivier.freebsd@free.fr)
	by smtp6-g21.free.fr (Postfix) with ESMTPSA id F3BA078032A;
	Fri,  2 Dec 2022 16:41:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr;
	s=smtp-20201208; t=1669995693;
	bh=P6Tn0SrnwZ9bInBVGq9eX9I0tcQ3vrfS0CXdK9bwt84=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Jen0maDo6vhdyFPJ5nBoT0qBCwdS/dkQsDlHS1D8qTMyic3Ewr5zRWlT9FIDUvgGh
	 FW3rIA0QmrBNB+GfNzjQ85URTOlHIW6D3VefTK1Ob5Bp/toll2PMFG+AA488dNFKCW
	 z5LlDkv7X7lEGZ0QvOnI9CzXg6QnJzdvx7FWTk209XkXd+Na5D9czzZCL4Ej7Pt3Fq
	 nJ9RpgwYdpjR40MsXqp23HfVlba1U0Mw8D69fmxnEiWZMCiWVBTJTPjVcd9ww8Wi39
	 t2KX2oyQNWVXEfGgfOQYIiY7NG0BjnyZqbfO5H+FZ7BbPnkDdRK84aQv6M6QrjL655
	 4t0mwWHl2KxkA==
From: Olivier Certner 
To: rick.macklem@gmail.com
Cc: freebsd-current@freebsd.org
Subject: Re: RFC: nfsd in a vnet jail
Date: Fri, 02 Dec 2022 16:41:31 +0100
Message-ID: <8351812.Gc231LQI4k@ravel>
In-Reply-To: 
References:  <1955021.aDjkhKmpDe@ravel> 
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-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Result: default: False [-2.87 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.77)[-0.770];
	CTE_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[free.fr,none];
	MID_RHS_NOT_FQDN(0.50)[];
	R_SPF_ALLOW(-0.20)[+ip4:212.27.42.6];
	R_DKIM_ALLOW(-0.20)[free.fr:s=smtp-20201208];
	MIME_GOOD(-0.10)[text/plain];
	RWL_MAILSPIKE_GOOD(-0.10)[212.27.42.6:from];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TAGGED_RCPT(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[212.27.42.6:from];
	ARC_NA(0.00)[];
	FREEMAIL_ENVFROM(0.00)[free.fr];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[free.fr:+];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[free.fr];
	DWL_DNSWL_NONE(0.00)[free.fr:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	ASN(0.00)[asn:12322, ipnet:212.27.32.0/19, country:FR];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NNxxp5Y96z3k7p
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

> To enforce it for cases where mountd/nfsd is not being run would
> definitely be a POLA violation.

I could not agree more.

Thanks for the clarification.

-- 
Olivier Certner




From nobody Fri Dec  2 17:57:08 2022
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 4NP0yH4znsz4k33N
	for ; Fri,  2 Dec 2022 17:57:11 +0000 (UTC)
	(envelope-from gbe@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NP0yH4XdDz3wfV;
	Fri,  2 Dec 2022 17:57:11 +0000 (UTC)
	(envelope-from gbe@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1670003831;
	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=mciR6YLG++xNTk/0ErhgBo/z/jq7H7ifKzM24LL6FQU=;
	b=U06f3lG4gNWb5XRyBMt+wfaFtlY21sBovVD2phSlRflvh6zAA8oerLeLQEBOmmpqCU65bQ
	1QyNFie61Ic8gc4cCoBRjUYmWx/Y8ZTcTAjVIYEbpVYYYpVOX1TEDjAXZAnQ7GKT/qpeeP
	WsjR34cssop/sbQH2sKwboUR5RIgv3UrevYGmbxs0spesXF7GI7bZrdlmEFA9jmCi4d4Li
	ZuDZH7itRvEUAyZ718Vyco2tLBdxSzzJ1CjO4AqpKEGS6yrFciFgaZLsV89ZQvxlWKN4op
	HPewHnqEe8/iWARBV78sOr1aq8kC14x7MMe3XAiyUKqns3BF2z5wmtwMntvnIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1670003831;
	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=mciR6YLG++xNTk/0ErhgBo/z/jq7H7ifKzM24LL6FQU=;
	b=iBk7+OkSbEI35gG3Pr9PWjpiz1jP7PB1Uhgy+7VcIaUCQOKhrzlkTpc9YwFltv936R8VLk
	9zXWDrD8fFsc9GjGzRP5zlYL1ARfmbJJHngdRLjLRFG7b+nXiTqGrKv4LI/QwmoGeMs6ab
	JTQJtYGGSuciseHR31Q4B3inn4Pgg91ulTTAuEdO3XotanexXqdfzrYUWcFk8vGSq3R+uz
	FQjOjJx/uWu1U3tIg+MBjiigyBZCtS8T2PJztr2HdGgIXBa9wePtmgv0d2ArDJPVIEfcJt
	SDUnmJEPFBCkRi7CBffkZxqdl/krRVWaB8AP/to/F+sWmt/FFHLwZbMphDxewA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670003831; a=rsa-sha256; cv=none;
	b=Bcz/Be8/3wb6PuoI3ccEC0gWk2yIfyMh0U1DUZQC9JOgAYZs39xZ/feKvFmd6i6hgEJEgK
	k9jPkp7vMGj0sP/LlWmpiNWWYK8lbqrI7H/XeSAJMHvQUsTKmLES8owUAquMRHK5cdc/J7
	m6cIpicj+i4cz1O2KHOKPnKm5Iv66s/NU2cce51tsw0Q/prSFmD+fKTYBO91vjztLLc/9e
	+RiMeR1iZOCGWzOSfttPjWYkoPM9iTbEjMfyLAZ4CGSeNEqpve7LK5rWgTCLmaxIE1jubp
	4VmjKrZ0jc/GQqSahkthqfFoDIiBpsqRNuLnSN1ewdMlgy0faOIUnuWZlchpCQ==
Received: from localhost (p200300cb870eb359080490e4b609ff4c.dip0.t-ipconnect.de [IPv6:2003:cb:870e:b359:804:90e4:b609:ff4c])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	(Authenticated sender: gbe)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NP0yH0pdWzgrS;
	Fri,  2 Dec 2022 17:57:10 +0000 (UTC)
	(envelope-from gbe@freebsd.org)
Date: Fri, 2 Dec 2022 18:57:08 +0100
From: Gordon Bergling 
To: Michael Tuexen 
Cc: Gordon Bergling , current@freebsd.org
Subject: Re: Buildword Error on a recent -CURRENT
Message-ID: 
References: 
 <6B7413E7-1848-472F-95B0-E8270E6248DD@macmic.franken.de>
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="yoZcpUfVSRsd0hWa"
Content-Disposition: inline
In-Reply-To: <6B7413E7-1848-472F-95B0-E8270E6248DD@macmic.franken.de>
X-Url: 
X-Operating-System: FreeBSD 13.1-STABLE amd64
X-Host-Uptime: 6:51PM  up 2 days,  1:44, 2 users, load averages: 0.16, 0.18,
 0.15
X-ThisMailContainsUnwantedMimeParts: N


--yoZcpUfVSRsd0hWa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Michael,

On Fri, Dec 02, 2022 at 12:02:15PM +0100, Michael Tuexen wrote:
> > On 2. Dec 2022, at 00:30, Gordon Bergling  wrote:
> >=20
> > Hello,
> >=20
> > I am currently having the following build work error on a recent
> > -CURRENT.
> >=20
> > =3D =3D=3D=3D> usr.bin/less (all)
> >  -16372 bytes available
> Not enough space available on the disk?
>=20
> Best regards
> Michael

Thanks for the reply.

The ZFS volumes have more then enough diskspace available, but after a seco=
nd
run the build succeed. I hit that problem often after a few weeks, but maybe
there were some stale files or something like this present.

--Gordon

[...]=20
> > Has anyone seen this error before or has recommandation on how to solve=
 it.
> >=20
> > My src.conf for building -CURRENT is the following:
> >=20
> > WITH_EXTRA_TCP_STACKS=3D1
> > WITH_BEARSSL=3D1
> > WITH_PIE=3D1
> > WITH_RETPOLINE=3D1
> > WITH_INIT_ALL_ZERO=3D1
> > WITH_OPENSSL_KTLS=3D1
> > WITHOUT_CLEAN=3D1
> >=20
> > The usual step if something with WITHOUT_CLEAN isn't working
> > (deleting the obj directory) had no effect.

--yoZcpUfVSRsd0hWa
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEYbWI0KY5X7yH/Fy4OQX2V8rP09wFAmOKPHJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYx
QjU4OEQwQTYzOTVGQkM4N0ZDNUNCODM5MDVGNjU3Q0FDRkQzREMACgkQOQX2V8rP
09zU7ggAp5x7pMkpmPRCkNr+CqtB6Yr5nZc1WWhG6umKtmYiy0jfEnoPPgbK+GZH
ABaJFJ0EQcfrGTyBrjtfE3zRs1r0qqqKS9KVCJ/eG0atnylUj5toWkplOgMoIqYS
683dt/t75EXU3l78QO9vCqzv+ccydwFpQl+vA2gpgx1wA1nddoMQrrZSY4o1QhcD
JYVT2Og1nG0Zuz1apnXy492SmASDK74SUOiLfsNGNwIyDCf/H5mb4s4rvfCwYW2Y
wMFEowrWsfkDtyX/rniGBoQ7dG+BthCHHFBwFc3OcGQ6ljDoWY3QfpxwclByVfZh
MOZuFYIBAtuCtshqWLsoFfQxCDitZQ==
=jLMZ
-----END PGP SIGNATURE-----

--yoZcpUfVSRsd0hWa--

From nobody Sat Dec  3 00:04:05 2022
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 4NP95t41kLz4jkt2
	for ; Sat,  3 Dec 2022 00:04:18 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NP95t1SwQz4dKL
	for ; Sat,  3 Dec 2022 00:04:18 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pj1-x1033.google.com with SMTP id t11-20020a17090a024b00b0021932afece4so9721984pje.5
        for ; Fri, 02 Dec 2022 16:04:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=5K51M0vHvQ3IK7ghya0YC4bKHOg9QFIg/WSHNWyseQM=;
        b=R4f6Li5fHxIZIkTnhIfgZFhXNWj92+Uh7oN4QuZsWG2CWrkORrXtpl8G3GsfCnDAUW
         8DNnjfDYc39WFmTqNGU9oZE2Vr9PjUdZp1bokipGx5uqLw5n66mtEL9gHUqQZbHbhr9Z
         LX55dlHqYn61A1FeFHBRngdrJlWuwFiUXtWjDgwHuQY0Fdj0XPp0X9VRthHUYNijAGAP
         EiLTiEfmbl59bXWtXTeuem1VVQ442BY0O4B0fdTH/lxr8+n+lQqCNs8d88uZ8obxC0n3
         4Nfsg12wIrdQ0fKLSJEzd5pC4SwSN0/2cfiOB7Df5EFesS7O6cX1dSh/fzPhhkMjMPX/
         xa3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=5K51M0vHvQ3IK7ghya0YC4bKHOg9QFIg/WSHNWyseQM=;
        b=EH2Aynlnimxdh+vDlE8BsAVkGskL+SQ+nj7n2sIsVR2DKT3ze16iVzFB/yx6hHo2Uj
         FwOmSAY6hCbhrJNRjHRq0vVZyMQCjPjRD1diIcu0+NDblrDYDi/cckymskTVDH0RStWn
         DU1ZGrIYRKyIq4aodx9mY3uNPkBpiRjwO+mqobwu1paSaSj1nALqg/zbuBE9XcYOYwxy
         mTc5LjI7eCBf6blXeYMxa4larXZD9JyDe9SjwnDIosJUbqVta1VIk3lSJk+rcKs0tNNu
         ZhjHVQFtXGTHONsp6VARQveGfaDdX7Wsj2+qgcnP7+X9ErA2AKit92Gm4ZUvNCvqg/2I
         MjPQ==
X-Gm-Message-State: ANoB5pnPYMzE1GnibhL0aWJKIZrkJbbaJ686hfnA+33xMzl1XYc18jUB
	b4tEZclUj0e28bjKm5UJTysbRy7yvGDfTD3Uh8EqYSUHEQ==
X-Google-Smtp-Source: AA0mqf5z5XsE3hZziSEAcv8xwUyEVRY1Pq59bYqe4e8p+h3SRYA2TD0245ePkz3xNDafkO+j7vcyPZ2ANfXfdgs1frI=
X-Received: by 2002:a17:902:d585:b0:189:9fb2:2541 with SMTP id
 k5-20020a170902d58500b001899fb22541mr19386482plh.60.1670025856431; Fri, 02
 Dec 2022 16:04:16 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 <1955021.aDjkhKmpDe@ravel> 
 <8351812.Gc231LQI4k@ravel>
In-Reply-To: <8351812.Gc231LQI4k@ravel>
From: Rick Macklem 
Date: Fri, 2 Dec 2022 16:04:05 -0800
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: Olivier Certner 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000f03aeb05eee131b9"
X-Rspamd-Queue-Id: 4NP95t1SwQz4dKL
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000f03aeb05eee131b9
Content-Type: text/plain; charset="UTF-8"

I think this is worthy of third party testing now.
See https://people.freebsd.org/~rmacklem/nfsd-vnet-prison-setup.txt

I still haven't tried NFSv3 and I have not ported nfsuserd into the vnet,
but most NFSv4 setups don't need it anyhow.

Good luck with it if you test it, rick
ps: Just replied to a random post for this.


On Fri, Dec 2, 2022 at 7:41 AM Olivier Certner 
wrote:

> > To enforce it for cases where mountd/nfsd is not being run would
> > definitely be a POLA violation.
>
> I could not agree more.
>
> Thanks for the clarification.
>
> --
> Olivier Certner
>
>
>
>

--000000000000f03aeb05eee131b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think this is worthy of third party testing now.
See https://people.freebsd.or=
g/~rmacklem/nfsd-vnet-prison-setup.txt

I still haven't tried NFSv3 and I have no=
t ported nfsuserd into the vnet,
but most NFSv4 setups don't need it anyhow.

Good luck with i=
t if you test it, rick
ps: Just replied to a random post for this.


On Fri, Dec 2, 2022 =
at 7:41 AM Olivier Certner <o=
livier.freebsd@free.fr> wrote:
> To enforce it for cases where mountd/nfsd is not=
 being run would

> definitely be a POLA violation.



I could not agree more.



Thanks for the clarification.



-- 

Olivier Certner










--000000000000f03aeb05eee131b9--

From nobody Sat Dec  3 07:38:53 2022
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 4NPMBb52CYz4jsWY
	for ; Sat,  3 Dec 2022 07:39:03 +0000 (UTC)
	(envelope-from max@baroi.com)
Received: from mailin02.mxof.com (mailin02.mxof.com [72.20.134.35])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.mxof.com", Issuer "GeoTrust TLS DV RSA Mixed SHA256 2020 CA-1" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NPMBZ6MjJz43gm
	for ; Sat,  3 Dec 2022 07:39:02 +0000 (UTC)
	(envelope-from max@baroi.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of max@baroi.com designates 72.20.134.35 as permitted sender) smtp.mailfrom=max@baroi.com;
	dmarc=none
Received: from mta01.mxof.net (mta01.mxof.net [10.1.0.31])
	by mailin02.mxof.com (8.15.2/8.15.2/Debian-8) with ESMTPS id 2B37crnK016818
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
	for ; Sat, 3 Dec 2022 07:38:54 GMT
Received: from mta01.mxof.net (localhost [127.0.0.1])
	by mta01.mxof.net (Postfix) with ESMTPS id 67E63260C4E
	for ; Fri,  2 Dec 2022 23:38:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by mta01.mxof.net (Postfix) with ESMTP id 5392A260C7D
	for ; Fri,  2 Dec 2022 23:38:53 -0800 (PST)
Received: from mta01.mxof.net ([127.0.0.1])
	by localhost (mta01.mxof.net [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id mymIj9yoh2kx for ;
	Fri,  2 Dec 2022 23:38:53 -0800 (PST)
Received: from dummy.faircode.eu (cpe-172-116-59-145.socal.res.rr.com [172.116.59.145])
	(Authenticated sender: max@baroi.com)
	by mta01.mxof.net (Postfix) with ESMTPSA id 1C63D260C4E
	for ; Fri,  2 Dec 2022 23:38:53 -0800 (PST)
Date: Fri, 2 Dec 2022 23:38:53 -0800 (PST)
From: Max Baroi 
To: current@freebsd.org
Message-ID: 
Subject: Consequences of disabling vtrnd
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_11_262336782.1670053133569"
X-Correlation-ID: 
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing:default, base:default, @@RPTN)
X-Spam-Score: -0.01 () [Hold at 7.10] HTML_MESSAGE:0.001,URIBL_AMI_WHITE:-0.01
X-CanIt-Geo: No geolocation information available for 10.1.0.31
X-CanItPRO-Stream: outgoing:default (inherits from base:default)
X-Canit-Stats-ID: 028PHCRV4 - bfa58425d3fa - 20221203
X-Antispam-Training-Forget: https://spamblock.prxy.com/b.php?c=f&i=028PHCRV4&m=bfa58425d3fa&rlm=outgoing&t=20221203
X-Antispam-Training-Nonspam: https://spamblock.prxy.com/b.php?c=n&i=028PHCRV4&m=bfa58425d3fa&rlm=outgoing&t=20221203
X-Antispam-Training-Phish: https://spamblock.prxy.com/b.php?c=p&i=028PHCRV4&m=bfa58425d3fa&rlm=outgoing&t=20221203
X-Antispam-Training-Spam: https://spamblock.prxy.com/b.php?c=s&i=028PHCRV4&m=bfa58425d3fa&rlm=outgoing&t=20221203
X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.1.0.12
X-Spamd-Result: default: False [-3.26 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.96)[-0.963];
	R_SPF_ALLOW(-0.20)[+ip4:72.20.134.32/28];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	DMARC_NA(0.00)[baroi.com];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:394437, ipnet:72.20.134.0/24, country:US];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_FIVE(0.00)[6];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEFALL_USER(0.00)[max];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NPMBZ6MjJz43gm
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_11_262336782.1670053133569
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

If this is not the appropriate place, I apologize.

Installing on an instance on vultr.com from booting from the standard image hangs. This is pretty well documented, and the equally well documented workaround is disabling vtrnd.

But are there lingering consequences from setting hint.vtrnd.disabled in the boot menu? The man page says virtio_random supplies the guest with high-quality random bits from the host. With this disabled, is the guest's entropy pool populated from a different high quality source or does the workaround leave the guest with only low entropy sources?

Thanks for any reply,
Max Baroi

------=_Part_11_262336782.1670053133569
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


 
  
 
 
  If this is not the appropriate place, I apologize.  
 
 Installing on an instance on vultr.com from booting from the standard image hangs. This is pretty well documented, and the equally well documented workaround is disabling vtrnd.  
 
 But are there lingering consequences from setting hint.vtrnd.disabled in the boot menu? The man page says virtio_random supplies the guest with high-quality random bits from the host. With this disabled, is the guest's entropy pool populated from a different high quality source or does the workaround leave the guest with only low entropy sources?  
 
 Thanks for any reply, 
 Max Baroi 

 

------=_Part_11_262336782.1670053133569--

From nobody Sat Dec  3 09:06:16 2022
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 4NPP7Y1NCFz4k48C
	for ; Sat,  3 Dec 2022 09:06:33 +0000 (UTC)
	(envelope-from me+freebsd@igalic.co)
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23])
	(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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NPP7X6Fppz4FDW
	for ; Sat,  3 Dec 2022 09:06:32 +0000 (UTC)
	(envelope-from me+freebsd@igalic.co)
Authentication-Results: mx1.freebsd.org;
	none
Date: Sat, 03 Dec 2022 09:06:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igalic.co;
	s=protonmail3; t=1670058389; x=1670317589;
	bh=TsStzok2o2KrZvp74UvqEUyYMV+i+baHkT29GVoWIEc=;
	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;
	b=ZU9Sz1Y/rCbq92OUzCC1BXJQv9ROCyaXCVzzPf1iJ4eFNBwVAsMVm4PAuR7Yg2Dsj
	 obAXPB5pnu5E5+qqLR04Sft7RgaRPgYHLxIuPZXKoxhvXxVj6LLG47wmCxP6W2dFIg
	 Bbjv2T0/9SJyWfvJhuwjKSR/ot5gCV6oHTIbBr9D6N4w5DkGi+j3wQZR6m0oJk+pby
	 xyrpGRdh7samhQ0s7JKlHRZGw8FBL8+uDxLelwsGKBO3GkrhZ/3ZwcOosVtzudJxWh
	 89t/oW6+0DVlMcaBYsbt0/4CPEqK4PSGAP3ulATHcYvary8Tb77MqQ3u6eNmynkHH0
	 Gnx3+iAm0Tj4Q==
To: Max Baroi 
From: =?utf-8?Q?Mina_Gali=C4=87?= 
Cc: current@freebsd.org
Subject: Re: Consequences of disabling vtrnd
Message-ID: 
In-Reply-To: 
References: 
Feedback-ID: 13937434:user:proton
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-Queue-Id: 4NPP7X6Fppz4FDW
X-Spamd-Bar: ----
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];
	TAGGED_FROM(0.00)[freebsd]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


Hi Max,

> If this is not the appropriate place, I apologize.
>=20
> Installing on an instance on vultr.com from booting from the standard ima=
ge hangs. This is pretty well documented, and the equally well documented w=
orkaround is disabling vtrnd.
>=20
> But are there lingering consequences from setting hint.vtrnd.disabled in =
the boot menu? The man page says virtio_random supplies the guest with high=
-quality random bits from the host. With this disabled, is the guest's entr=
opy pool populated from a different high quality source or does the workaro=
und leave the guest with only low entropy sources?

The main consequence is that we go from:

kern.random.random_sources: 'VirtIO Entropy Adapter','Intel Secure Key RNG'
kern.random.harvest.mask_symbolic: PURE_VIRTIO,PURE_RDRAND,[CALLOUT],[UMA],=
[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,C=
ACHED

to:

kern.random.random_sources: 'Intel Secure Key RNG'
kern.random.harvest.mask_symbolic: PURE_RDRAND,[CALLOUT],[UMA],[FS_ATIME],S=
WI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED

That is: The virtual machine already had the capability of emulating Intel =
Secure Key RNG, and we're falling back to that scenario.

> Thanks for any reply,
> Max Baroi

Kind regards,

Mina Gali=C4=87

Try PkgBase: https://alpha.pkgbase.live/

From nobody Sun Dec  4 01:26:16 2022
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 4NPpt40KPYz4k0F1;
	Sun,  4 Dec 2022 01:26:20 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NPpt26mnVz3qkC;
	Sun,  4 Dec 2022 01:26:18 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=j6Nj0hpw;
	spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::e2e as permitted sender) smtp.mailfrom=grarpamp@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-vs1-xe2e.google.com with SMTP id b189so2159839vsc.10;
        Sat, 03 Dec 2022 17:26:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :references:in-reply-to:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=686NIf1KIBcl9er/S5vKPY7QqZKJCo2i9rFrcKo6W6c=;
        b=j6Nj0hpwLA5tI7O8V/AZy//pv7jCZ9Nn5xWpTpeFuwjnlk+z4+pUfLNazRNn+oR/nT
         2l1jYCwQw41fsRSySzbAu1dscw7mvvtoQRZilTkp3FbXlxGNG+z19v55sNhadH9EDYml
         W00QT7nbs85Id4ggxK7m7YnMdHQAgv5kICsRiuFBrk3GJphPe9hggWJKddDIBXkhK3d2
         z9mW2Ag6QTJpmiLRFC5hUWrTCjHSj3Np81rimbflr2ITjCo7rprPag2Qh0h79/g79my5
         MuMOWLYZ7JNP5cz6k0kbGjfKqKm7XBaZpYgzcjsZmp/glwPnTCHwXrlh1Y9vxRKMES0h
         /Lnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=686NIf1KIBcl9er/S5vKPY7QqZKJCo2i9rFrcKo6W6c=;
        b=qCp9Dme7PgKn1s1f95tB0T2FttAkSYYv9rD2cmL1sPrLWcd+Nrfd0aNaYvBSvhN/U8
         zvTYgDiVy8TSLouaKsXDs5UbU5AGCFi7+IKbTf+1ouUkazq5nIDr9jakwz6LqVNB8Vvy
         1vWuhn4QOx6Is92On5JBCR+saOqkZP/grP0P1Srifl7xOzjrYtDtl/ZzySvg0icAj4Iz
         yE4rR3iz6PcClrBlPlGt+s9yuqShICvsbrtZ9hkauvwQaF3u/pqmHsg7Pi14A0mQ6vmH
         Nt3z3umxQrWJD5LirvVMQKKVVx/eD24z0fDI8irMEsy+2p0g9Z1dAxzFVqxFv1YnX+bQ
         3/Bw==
X-Gm-Message-State: ANoB5pmEKPZmxFtZgKN5oUZeRwJk3gx4JGe0w2/0rW1bC9zlUAn+MwGr
	K6EwlPqtYJFHij5oXEt70+VZ7BiNgURQyFFveJDa5a3qvZzO1ZgAUDY=
X-Google-Smtp-Source: AA0mqf4obSX09BCQpTbBN5nwz/5dDkzqpUNmZYTgL0N2t67hzWDHbeUEA3IO4i68GU2SEJKvm30y0Fb7BWVPbNUyWSw=
X-Received: by 2002:a05:6102:502:b0:3b0:df43:87af with SMTP id
 l2-20020a056102050200b003b0df4387afmr8751071vsa.1.1670117177359; Sat, 03 Dec
 2022 17:26:17 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Received: by 2002:a59:acc2:0:b0:32b:33ff:fbc3 with HTTP; Sat, 3 Dec 2022
 17:26:16 -0800 (PST)
In-Reply-To: 
References: 
From: grarpamp 
Date: Sat, 3 Dec 2022 20:26:16 -0500
Message-ID: 
Subject: Re: CA's TLS Certificate Bundle in base = BAD
To: freebsd-security@freebsd.org
Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org, 
	freebsd-current@freebsd.org, freebsd-pkg@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spamd-Result: default: False [-3.97 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.986];
	NEURAL_HAM_MEDIUM(-0.98)[-0.984];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2e:from];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-security@freebsd.org,freebsd-questions@freebsd.org,freebsd-hackers@freebsd.org,freebsd-current@freebsd.org,freebsd-pkg@freebsd.org];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_FIVE(0.00)[5];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-Rspamd-Queue-Id: 4NPpt26mnVz3qkC
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Again, FreeBSD should not be including the bundle in base, if users
choose to, they can get it from ports or packages or wherever else.
Including such bundles exposes users worldwide to massive risks.
You need to do more gpg attestation, pubkey pinning [1], tofu, and
cert management starting from empty file... and quit trusting bundles of
hundreds of random CA's, all of which are entities who have zero duty
or care to the user, and often exist/corrupt/break to present evil [2] ...

[1]
https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d
https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDPU=
BLICKEY.3

FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple option,
thus they're incapable of securely fetching packages, iso's, etc from
servers in re [2]. Nor does FreeBSD even post sigs over its servers pubkeys
for users to get, verify, and pin out of band. Even pubkeys were swapped ou=
t
on FreeBSD servers without announcing for users if any exploit or loss occu=
rred
there or for some other reason. That's all bad news :( But can be fixed :)


[2]
https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addr=
esses-government-connections
https://www.msn.com/en-us/news/technology/mysterious-company-with-governmen=
t-ties-plays-key-internet-role/ar-AA13RwPh
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4=
/m/etbBho-VBQAJ

Major Web Browsers Drop Mysterious Authentication Company After Ties
To US Military Contractor Exposed

TrustCor Systems vouches for the legitimacy of websites. But its
physical address is a UPS Store in Toronto.

Mysterious company with government ties plays key internet role

An offshore company that is trusted by the major web browsers and
other tech companies to vouch for the legitimacy of websites has
connections to contractors for U.S. intelligence agencies and law
enforcement, according to security researchers, documents and
interviews.
Google=E2=80=99s Chrome, Apple=E2=80=99s Safari, nonprofit Firefox and othe=
rs allow
the company, TrustCor Systems, to act as what=E2=80=99s known as a root
certificate authority, a powerful spot in the internet=E2=80=99s
infrastructure that guarantees websites are not fake, guiding users to
them seamlessly.
The company=E2=80=99s Panamanian registration records show that it has the
identical slate of officers, agents and partners as a spyware maker
identified this year as an affiliate of Arizona-based Packet
Forensics, which public contracting records and company documents show
has sold communication interception services to U.S. government
agencies for more than a decade.
One of those TrustCor partners has the same name as a holding company
managed by Raymond Saulino, who was quoted in a 2010 Wired article as
a spokesman for Packet Forensics.
Saulino also surfaced in 2021 as a contact for another company, Global
Resource Systems, that caused speculation in the tech world when it
briefly activated and ran more than 100 million previously dormant IP
addresses assigned decades earlier to the Pentagon. The Pentagon
reclaimed the digital territory months later, and it remains unclear
what the brief transfer was about, but researchers said the activation
of those IP addresses could have given the military access to a huge
amount of internet traffic without revealing that the government was
receiving it.
The Pentagon did not respond to a request for comment on TrustCor.
TrustCor also did not respond to a request for comment.
[Minutes before Trump left office, millions of the Pentagon=E2=80=99s dorma=
nt
IP addresses sprang to life]
TrustCor=E2=80=99s products include an email service that claims to be
end-to-end encrypted, though experts consulted by The Washington Post
said they found evidence to undermine that claim. A test version of
the email service also included spyware developed by a Panamanian
company related to Packet Forensics, researchers said. Google later
banned all software containing that spyware code from its app store.
A person familiar with Packet Forensics=E2=80=99 work confirmed that it had
used TrustCor=E2=80=99s certificate process and its email service, MsgSafe,=
 to
intercept communications and help the U.S. government catch suspected
terrorists.
=E2=80=9CYes, Packet Forensics does that,=E2=80=9D the person said, speakin=
g on the
condition of anonymity to discuss confidential practices.
Packet Forensics counsel Kathryn Temel said the company has no
business relationship with TrustCor. She declined to say whether it
had had one previously.
The latest discovery shows how the technological and business
complexities of the internet=E2=80=99s inner workings can be leveraged to a=
n
extent that is rarely revealed.
Concerns about root certificate authorities, though, have come up before.
In 2019, a security company controlled by the government of the United
Arab Emirates that had been known as DarkMatter applied to be upgraded
to top-level root authority from intermediate authority with less
independence. That followed revelations about DarkMatter hacking
dissidents and even some Americans; Mozilla denied it root power.
In 2015, Google withdrew the root authority of the China Internet
Network Information Center (CNNIC) after it allowed an intermediate
authority to issue fake certificates for Google sites.
With Packet Forensics, a paper trail led to it being identified by
researchers twice this year. Mostly known for selling interception
devices and tracking services to authorities, the company is four
months into a $4.6 million Pentagon contract for =E2=80=9Cdata processing,
hosting and related services.=E2=80=9D
In the earlier spyware matter, researchers Joel Reardon of the
University of Calgary and Serge Egelman of the University of
California at Berkeley found that a Panamanian company, Measurement
Systems, had been paying developers to include code in a variety of
innocuous apps to record and transmit users=E2=80=99 phone numbers, email
addresses and exact locations. They estimated that those apps were
downloaded more than 60 million times, including 10 million downloads
of Muslim prayer apps.
Measurement Systems=E2=80=99 website was registered by Vostrom Holdings,
according to historic domain name records. Vostrom filed papers in
2007 to do business as Packet Forensics, according to Virginia state
records. Measurement Systems was registered in Virginia by Saulino,
according to another state filing.
After the researchers shared their findings, Google booted all apps
with the spy code out of its Play app store.
Tremel said that =E2=80=9Ca company previously associated with Packet
Forensics was a customer of Measurement Systems at one time=E2=80=9D but th=
at
there was no ownership stake.
When Reardon and Egelman looked deeper at Vostrom, they found it had
registered the domain name TrustCor.co, which directed visitors to the
main TrustCor site. TrustCor has the same president, agents and
holding-company partners listed in Panamanian records as Measurement
Systems.
A firm with the same name as one of the holding companies behind both
TrustCor and Measurement Systems, Frigate Bay Holdings, filed papers
to dissolve this March with the secretary of state in Wyoming, where
it was formed. The papers were signed by Saulino, who listed his title
as manager. He could not be reached for comment.
TrustCor has issued more than 10,0000 certificates, many of them for
sites hosted with a dynamic domain name service provider called No-IP,
the researchers said. That service allows websites to be hosted with
constantly changing Internet Protocol addresses.
Because root authority is so powerful, TrustCor can also give others
the right to issue certificates.
Certificates for websites are publicly viewable so that bad ones
should be exposed sooner or later. There have been no reports so far
that the TrustCor certificates have been used inappropriately, for
example by vouching for impostor websites. The researchers speculated
that the system is only used against high-value targets within short
windows of time. The person familiar with Packet Forensics=E2=80=99 operati=
ons
agreed said that was in fact how it has been used.
=E2=80=9CThey have this position of ultimate trust, where they can issue
encryption keys for any arbitrary website and any email address,=E2=80=9D
Egelman said. =E2=80=9CIt=E2=80=99s scary this is being done by some shady =
private
company.=E2=80=9D
The leadership page of the TrustCor=E2=80=99s website lists just two men,
identified as co-founders. Though that page does not say so, one of
them died months ago, and the other=E2=80=99s LinkedIn profile says he left=
 as
chief technology officer in 2019. That man declined to comment.
The website site lists a contact phone number in Panama, which has
been disconnected, and one in Toronto, where a message had not been
returned after more than a week. The email contact form on the site
doesn=E2=80=99t work. The physical address in Toronto given in its auditor=
=E2=80=99s
report, 371 Front St. West, houses a UPS Store mail drop.
TrustCor adds another layer of mystery with its outside auditing firm.
Instead of using a major accounting firm that rates the safety of
internet infrastructure companies, TrustCor selected one called
Princeton Audit Group, which gives its address as a residential
townhouse in Princeton, N.J.
In addition to TrustCor=E2=80=99s certificate power, the firm offers what
purports to be end-to-end encrypted email, MsgSafe.io. But researchers
said the email is not encrypted and can be read by the company, which
has pitched it to a variety of groups worried about surveillance.
MsgSafe has touted its security to a variety of potential customers,
including Trump supporters upset that Parler had been dropped by app
stores in January 2021, and to users of encrypted mail service
Tutanota who were blocked from signing on to Microsoft services.
=E2=80=9CCreate your free end-to-end encrypted email today with over 40
domains to choose from and are guaranteed to work with Microsoft
Teams,=E2=80=9D the company tweeted in August.
Reardon sent test messages over MsgSafe that appeared unencrypted in
transmission, meaning MsgSafe could read them at will. Egelman ran the
same test with the same result.
Jon Callas, a cryptography expert at the Electronic Frontier
Foundation, also tested the system at The Post=E2=80=99s request and said t=
hat
MsgSafe generated and kept the private key for his account, so that it
could decrypt anything he sent.
=E2=80=9CThe private key has to be under the person=E2=80=99s control to be
end-to-end,=E2=80=9D Callas explained.
Packet Forensics first drew attention from privacy advocates a dozen years =
ago.
In 2010, researcher Chris Soghoian attended an invite-only industry
conference nicknamed the Wiretapper=E2=80=99s Ball and obtained a Packet
Forensics brochure aimed at law enforcement and intelligence agency
customers.
The brochure was for a piece of hardware to help buyers read web
traffic that parties thought was secure. But it wasn=E2=80=99t.
=E2=80=9CIP communication dictates the need to examine encrypted traffic at
will,=E2=80=9D the brochure read, according to a report in Wired that quote=
d
Saulino as a Packet Forensics spokesman. =E2=80=9CYour investigative staff
will collect its best evidence while users are lulled into a false
sense of security afforded by web, e-mail or VOIP encryption,=E2=80=9D the
brochure added.
The brochure told customers they could use a decryption key provided
by a court order or a =E2=80=9Clook-alike key.=E2=80=9D
Researchers thought at the time that the most likely way the box was
being used was with a certificate issued by an authority for money or
under a court order that would guarantee the authenticity of an
impostor communications site.
They did not conclude that an entire certificate authority itself
might be compromised.
Obtaining trusted root certificate authority takes time and money for
the infrastructure and for the audit that browsers require, experts
say.
Each browser has slightly different requirements. At Mozilla=E2=80=99s
Firefox, the process takes two years and includes crowdsourced and
direct vetting as well as an audit.
But all of that typically focuses on formal statements of
technological steps, rather than mysteries of ownership and intent.
The person familiar with Packet Forensics said the big tech companies
probably were unwitting participants in the TrustCor play: =E2=80=9CMost
people aren=E2=80=99t paying attention.=E2=80=9D
=E2=80=9CWith enough money, you or I could become a trusted root certificat=
e
authority,=E2=80=9D said Daniel Schwalbe, vice president of technology at w=
eb
data tracker DomainTools.
Mozilla currently recognizes 169 root certificate authorities,
including three from TrustCor.
The case gives new focus to problems with that system, in which
critical tech companies outsource their trust to third parties with
their own agendas.
=E2=80=9CYou can=E2=80=99t bootstrap trust, it has to come from somewhere,=
=E2=80=9D Reardon
said. =E2=80=9CRoot certificate authorities are the kernel of trust from wh=
ich
it is all built on. And it will always be shaky, because it will
always involve humans, committees and decision-making.=E2=80=9D
Reardon and Egelman alerted Google, Mozilla and Apple to their
research on TrustCor in April. They said they have heard little back.
Google did not respond to a request for comment.
Mozilla said it would say more after reviewing details from the researchers=
.


Major Web Browsers Drop Mysterious Authentication Company After Ties
To US Military Contractor Exposed

This week several major web browsers quickly severed ties with a
mysterious software company used to certify the security of websites,
three weeks after the Washington Post exposed its connections to a US
military contractor, the Post reports.

TrustCor Systems provided 'certificates' to browsers to Mozilla
Firefox and Microsoft Edge, which vouched for the legitimacy of said
websites.

"Certificate Authorities have highly trusted roles in the internet
ecosystem and it is unacceptable for a CA to be closely tied, through
ownership and operation, to a company engaged in the distribution of
malware," said Mozilla's Kathleen Wilson in an email to browser
security experts. "Trustcor=E2=80=99s responses via their Vice President of=
 CA
operations further substantiates the factual basis for Mozilla=E2=80=99s
concerns."

According to TrustCor's Panamanian (!?) registration records, the
company has the same slate of officers, agents and officers as
Arizona-based Packet Forensics, which has sold communication
interception services to the U.S. government for over a decade.

    One of those contracts listed the =E2=80=9Cplace of performance=E2=80=
=9D as Fort
Meade, Md., the home of the National Security Agency and the
Pentagon=E2=80=99s Cyber Command.

    The case has put a new spotlight on the obscure systems of trust
and checks that allow people to rely on the internet for most
purposes. Browsers typically have more than a hundred authorities
approved by default, including government-owned ones and small
companies, to seamlessly attest that secure websites are what they
purport to be. -WaPo

Also of concern, TrustCor's small staff in Canada lists its place of
operation at a UPS Store mail drop, according to company executive
Rachel McPherson, who says she told their Canadian staffers to work
remotely. She also acknowledged that the company has 'infrastructure'
in Arizona as well.

McPherson says that ownership in TrustCor was transferred to employees
despite the fact that some of the same holding companies had invested
in both TrustCor and Packet Forensics.

Various technologists in the email discussion said they found TrustCor
to be evasive when it came to basic facts such as legal domicile and
ownership - which they said was not appropriate for a company
responsible for root certificate authority that verifies a secure
'https' website is not an imposter.

    The Post report built on the work of two researchers who had first
located the company=E2=80=99s corporate records, Joel Reardon of the
University of Calgary and Serge Egelman of the University of
California at Berkeley. Those two and others also ran experiments on a
secure email offering from TrustCor named MsgSafe.io. They found that
contrary to MsgSafe=E2=80=99s public claims, emails sent through its system
were not end-to-end encrypted and could be read by the company.

    McPherson said the various technology experts had not used the
right version or had not configured it properly. -WaPo

In a previous case which illustrates the importance of trusting
root-level authorities - a security company controlled by the United
Arab Emirates, DarkMatter, applied in 2019 to have top-level root
authority from their status as an intermediate authority with less
independence. The request followed revelations that DarkMatter had
hacked dissidents and even some Americans - after which Mozilla denied
it root power.


"Received email from DDNS no-IP, they offering free TrustCor Standard
DV SSL certificate."
"Free, comes complete with spyveillance and exploit, lol."
"Imagine that even the most trusted CA's are actually rogue!"

From nobody Sun Dec  4 02:05:21 2022
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 4NPqlf2T45z4hqsc;
	Sun,  4 Dec 2022 02:05:50 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NPqld6t7jz3xdL;
	Sun,  4 Dec 2022 02:05:49 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Authentication-Results: mx1.freebsd.org;
	none
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 2B425LHr005113
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 3 Dec 2022 18:05:21 -0800 (PST)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 2B425LoN005112;
	Sat, 3 Dec 2022 18:05:21 -0800 (PST)
	(envelope-from sgk)
Date: Sat, 3 Dec 2022 18:05:21 -0800
From: Steve Kargl 
To: grarpamp 
Cc: freebsd-security@freebsd.org, freebsd-questions@freebsd.org,
        freebsd-hackers@freebsd.org, freebsd-current@freebsd.org,
        freebsd-pkg@freebsd.org
Subject: Re: CA's TLS Certificate Bundle in base = BAD
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
References: 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4NPqld6t7jz3xdL
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Sat, Dec 03, 2022 at 08:26:16PM -0500, grarpamp wrote:
> there or for some other reason. That's all bad news :( But can be fixed :)
> 

It looks like the FreeBSD mailing list software
stripped your attachment with your patch.  Can
you try sending it again with the patch in-line?

-- 
steve

From nobody Sun Dec  4 02:44:55 2022
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 4NPrcp6WsWz4hwrC;
	Sun,  4 Dec 2022 02:44:58 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NPrcp6437z43hM;
	Sun,  4 Dec 2022 02:44:58 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1670121898;
	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=J/kYN5WtcAGBw19XPuaAnc6JHiAz2NH644md2dTU80I=;
	b=Ge0UdghnZpRay7eOWRxgjG4h+n5lT/RzghDCVZw8BdjOAPKquXNjoGBCDciJfJO/9ayKli
	eYt5Lv0+By4cclQTO/at0toM3oya12yabkBosatez4MXyK97Bc15hOJ07cSrd4yKVj+q0v
	wVIZhVbI5G3YWqDR5Nk6f2pxZ9b82SLZsMEqwXbrOP7u5XTi0idpfEslbx0VekaBiEeWHF
	c12t4D1IzItiwDZnOb+BMGM82K4Ecy1k6ZekuXOv+zJajvZKocIGrUOo0BfIS97pd5lQ6o
	WP9fQmv41VD2AE6AtMYjTQ9WiSSLY741r+ph8PqH8+G/KnEehrqFODYJ9l7Dfg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1670121898;
	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=J/kYN5WtcAGBw19XPuaAnc6JHiAz2NH644md2dTU80I=;
	b=QHHM78h/W2+pkeqzu5ysxeAxmvZEiN73Npy+8QYrWooa2uQyJ/VBrO+Xb/0RNCE+wbNG9o
	piCsgwIoP8Pfzt0hv37J+J8iuXbGtVN+K7efZKjUbUVcfahhUK2kHSSeTYa69rBv0tZjUe
	QoiJcuSqYL4aNurOsy7tq57aIhLvmKPshF2Ue31SEBYe4MX/fUbf88uRZ2Wxpef8hj1HZW
	fO78QEXYVBpOaKbeFHjoAAIIGzLPZitm+Tbpz8yV8cO6VeXwuB3tjyd/mFtb7NLpdqLQU7
	ESpCEUYjPb7G7fjvT71IAIgLe9z7j5y8xWe/SFAmZaaz6qjqf75l5CjFgXV1LA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670121898; a=rsa-sha256; cv=none;
	b=xwskyS9EgQne2qcEYCaYtHxkmPYtyu9osR24WkG5ixcHI0oNjNAIj2V0p8c73cb/elK4xe
	Wa4+z8rwSF51q6cDtkCfUtZeQQxApGKa5VjgBhjb2sGCP+GzXdpPEHdQ2NHOofYOmJ0yCl
	YtuHE3wwjEWwkpwqxdU48fcxmX3HggNBjllEH+JfUZ576HKJNu/chlCCIVs7SRd0NrSUcn
	vcG/MtJMBojargGXD2ANfpZT3/lwxJGRiVmqav5mon3AD48D1BpC9ZTCJiOcd+8t5585e1
	yJUgGonr15Zth4QG5oFsEG7EtXNaNc1F6FHPHXAW4d9Vlx3uwkIgNb6d9RtDDg==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NPrcn6ktRzLLF;
	Sun,  4 Dec 2022 02:44:57 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: <1a9c360a-195a-14f2-7c22-6fdd668aa5cc@freebsd.org>
Date: Sun, 4 Dec 2022 02:44:55 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: CA's TLS Certificate Bundle in base = BAD
To: grarpamp 
Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org,
 freebsd-current@freebsd.org, freebsd-pkg@freebsd.org,
 freebsd-security@freebsd.org
References: 
 
Content-Language: en-GB
From: Graham Perrin 
Organization: FreeBSD
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------DZ1HHh8wOH3EbeKhDixHtHhU"
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------DZ1HHh8wOH3EbeKhDixHtHhU
Content-Type: multipart/mixed; boundary="------------c1EQBIrLvyNIvY0maI9pzRMI";
 protected-headers="v1"
From: Graham Perrin 
To: grarpamp 
Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org,
 freebsd-current@freebsd.org, freebsd-pkg@freebsd.org,
 freebsd-security@freebsd.org
Message-ID: <1a9c360a-195a-14f2-7c22-6fdd668aa5cc@freebsd.org>
Subject: Re: CA's TLS Certificate Bundle in base = BAD
References: 
 
In-Reply-To: 

--------------c1EQBIrLvyNIvY0maI9pzRMI
Content-Type: multipart/alternative;
 boundary="------------1Ig5uKkPBzAjJHbGvg3OjSV7"

--------------1Ig5uKkPBzAjJHbGvg3OjSV7
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

Z3JhcnBhbXAsIHBsZWFzZSByZWZyYWluIGZyb20gYWRkcmVzc2luZyBzbyBtYW55IGxpc3Rz
Lg0KDQpTbyBtYW55IGlzOg0KDQoqIGdlbmVyYWxseSBwb29yIG5ldGlxdWV0dGUNCiogY29u
dHJhcnkgdG8gcnVsZXMgb2YgdGhlIHJvYWQgaW4gdGhlIEZyZWVCU0QgSGFuZGJvb2suDQoN
CjxodHRwczovL2RvY3MuZnJlZWJzZC5vcmcvZW4vYm9va3MvaGFuZGJvb2svYm9vay8jZXJl
c291cmNlcy1jaGFydGVycz4NCg==
--------------1Ig5uKkPBzAjJHbGvg3OjSV7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
grarpamp, please refrain from
      addressing so many lists. 

    

    


    

    
So many is: 

    

    


    

    
* generally poor netiquette

    
* contrary to rules of the road in the=

      FreeBSD Handbook. 

    

    


    

    
<https://docs.freebsd.org/en/books/handbook/book/#eresources-charter=
s>

    

  
  


--------------1Ig5uKkPBzAjJHbGvg3OjSV7--

--------------c1EQBIrLvyNIvY0maI9pzRMI--

--------------DZ1HHh8wOH3EbeKhDixHtHhU
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmOMCacFAwAAAAAACgkQt2dIb0oY1Asu
bBAAjFHnzRhKyZP5BdgDlM+iDPBKAr9ZnBwryBrklZMXUwJ8XllvqRztUpD9adT5BZmvyqdKmu7X
ElXHbkjlpzxtJ8CgE9BTzgjz8KtpCnJw6b+h1XdEs3VoU9zJecqxLnIn4wDBuf4EYqeBk6ZzB/e/
1F34TyFBg8YHM2qVPp+/f4PyFwNFHsAhganeM6tyIGafw82CnKXnGAgO+z54ov0oEcMIgdXumdQX
1oKTlz958j/SqMJAgDkznDP9990s5lsQCp7dU1T217efI7dIgbQP7J4kKMawclCy3eoPhy8j0T2x
0hCF3HogTZ4mvcjyonboxbF93saONviEUEkLX/SYItZ0hkxEqJYS0hdLFS75BKP0ltsQ6HbeHRLF
idsDwIgLb7T5X410EZZGljZ14NplWbbqM0CnJwXnGMNbq1aJV8vxneRaS4HxI6zTcqcSauE67b8p
Jset3DvwoTQSn9Cgrr2qlUxukvusw40dVOy5kq5/7aZPnqVmwtOX7MYI3vgaKhqkPPWRwzzwaL74
3yLCdaJ0Oh/z7vTK38rtXdEjTyDtrdkJOBWRJ19xoZOjbwt72oGt+KJWnBUJRfnmESkBg0YjfSPv
qKXIfFIGsTFz+ej+UZWM4LjIRn8ALkotzn0TznbTPNb88SWC3uTk+w88Py0Ac0PqeEqVWxvRn8Se
5K0=
=LO7a
-----END PGP SIGNATURE-----

--------------DZ1HHh8wOH3EbeKhDixHtHhU--

From nobody Sun Dec  4 06:16:45 2022
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 4NPxKT102zz4jTL1
	for ; Sun,  4 Dec 2022 06:17:01 +0000 (UTC)
	(envelope-from gordon@tetlows.org)
Received: from mr85p00im-ztdg06021201.me.com (mr85p00im-ztdg06021201.me.com [17.58.23.189])
	(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 4NPxKS4jDXz4WMv
	for ; Sun,  4 Dec 2022 06:17:00 +0000 (UTC)
	(envelope-from gordon@tetlows.org)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tetlows.org; s=sig1;
	t=1670134619; bh=wVaLjZc+H7aC5nF+TF4Y+bffPGR0jwjMsHIppMvSeho=;
	h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To;
	b=qqIicwSEkmH2HqLBB69h+CcOgIZUJorpc0DsawV3ezBdaMtAyGw4w/azWzztNBJUS
	 0ryvA1UYRgdPPJtmEwBik1/hciCGNOCcwkOS+kmql9hU8ZYm52GTzTQi4K1HtXtNZ4
	 fxTmwrg4bhWdjzgtcIi40NsDHrmPIRfnbaaoW0Lhu5D+xnMuLvwSUpGxp6CDkpj6NZ
	 PmzjvXR2NcjdD3A4GCd2zglolyhv1lhI3mArJBe1f9FtuO9xsrL/NWxMX2uf7Velsc
	 acSg9bdhyAg+e6fgh+dSEqmLpHdZ9+UMktAawPE5ip/iqPWMT7lubBQ18Rwj6DizpP
	 Wp8ETyJLRnpRQ==
Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18])
	by mr85p00im-ztdg06021201.me.com (Postfix) with ESMTPSA id 7B33D320795;
	Sun,  4 Dec 2022 06:16:58 +0000 (UTC)
From: Gordon Tetlow 
Message-Id: <3FD4E3F3-EAAB-41E9-9381-D98971A9B928@tetlows.org>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F"
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.200.110.1.12\))
Subject: Re: CA's TLS Certificate Bundle in base = BAD
Date: Sat, 3 Dec 2022 22:16:45 -0800
In-Reply-To: 
Cc: freebsd-security@freebsd.org,
 freebsd-questions@freebsd.org,
 freebsd-hackers@freebsd.org,
 freebsd-current@freebsd.org,
 freebsd-pkg@freebsd.org
To: grarpamp 
References: 
 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
X-Proofpoint-GUID: JdfdEwSXJIZROAN6ZP9MzHqHobNhHuNt
X-Proofpoint-ORIG-GUID: JdfdEwSXJIZROAN6ZP9MzHqHobNhHuNt
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?=
 =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.816,17.11.62.513.0000000_definitions?=
 =?UTF-8?Q?=3D2022-01-18=5F01:2020-02-14=5F02,2022-01-18=5F01,2021-12-02?=
 =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 adultscore=0
 clxscore=1030 phishscore=0 malwarescore=0 spamscore=0 mlxlogscore=385
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2209130000 definitions=main-2212040058
X-Rspamd-Queue-Id: 4NPxKS4jDXz4WMv
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


--Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Dec 3, 2022, at 5:26 PM, grarpamp  wrote:
>=20
> Again, FreeBSD should not be including the bundle in base, if users
> choose to, they can get it from ports or packages or wherever else.
> Including such bundles exposes users worldwide to massive risks.
> You need to do more gpg attestation, pubkey pinning [1], tofu, and
> cert management starting from empty file... and quit trusting bundles =
of
> hundreds of random CA's, all of which are entities who have zero duty
> or care to the user, and often exist/corrupt/break to present evil [2] =
...
>=20
> [1]
> =
https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d
> =
https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDP=
UBLICKEY.3
>=20
> FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple =
option,
> thus they're incapable of securely fetching packages, iso's, etc from
> servers in re [2]. Nor does FreeBSD even post sigs over its servers =
pubkeys
> for users to get, verify, and pin out of band. Even pubkeys were =
swapped out
> on FreeBSD servers without announcing for users if any exploit or loss =
occurred
> there or for some other reason. That's all bad news :( But can be =
fixed :)

Key pinning is a bad idea that 100% will cause outages.

As a thought experiment, let's suppose I (as the Security Officer) use =
the system you propose and require users to pin specific keys on our =
publicly available servers. Now let's further suppose that the project =
is compromised such that we believe those certificates might be in the =
hands of the attacker, but we aren't sure. I'm now stuck between a rock =
and hard place. Should I rotate the pinned certificate? In your proposed =
system, rotating that pinned certificate will cause massive downstream =
failures for all users. Since we aren't sure, maybe I'll leave the =
existing certificate in place, because I don't want to cause those =
outages since I'm not sure it's a problem.

In the publicly trusted CA system, I can easily rotate the certificate =
even if I don't believe it was compromised. It incentivizes better =
behavior. Also, please don't lecture me on the problems with the =
publicly trusted CA system: I'm very familiar with them. That said, it's =
the system we have and I have no interest in trying to tilt at that =
particular windmill.

In any event, nothing is preventing you from doing this on your own as =
the system ships with the tools to do so. Recognize the project has a =
need for cryptographic agility and ability to change certificates =
whenever we need to. Running our own root CA infrastructure necessary to =
provide a similar level of assurance to a professionally run CA is =
non-trivial and I don't believe we as a project are in a position (or =
interested) in taking on such a burden.

Gordon=

--Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Dec 3, =
2022, at 5:26 PM, grarpamp <grarpamp@gmail.com> =
wrote:

Again, =
FreeBSD should not be including the bundle in base, if users
choose to, they can get it from ports or =
packages or wherever else.
Including such bundles exposes users worldwide to massive =
risks.
You need to do more gpg =
attestation, pubkey pinning [1], tofu, and
cert =
management starting from empty file... and quit trusting bundles =
of
hundreds of random CA's, =
all of which are entities who have zero duty
or care to the user, and often =
exist/corrupt/break to present evil [2] ...

[1]
https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpub=
key.d
https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_P=
INNEDPUBLICKEY.3

FreeBSD pkg(8) (aka, =
and: fetch(3)) don't even support this simple option,
thus they're incapable of securely fetching =
packages, iso's, etc from
servers =
in re [2]. Nor does FreeBSD even post sigs over its servers =
pubkeys
for users to get, =
verify, and pin out of band. Even pubkeys were swapped out
on FreeBSD servers without announcing for =
users if any exploit or loss occurred
there =
or for some other reason. That's all bad news :( But can be fixed =
:)

Key pinning is a bad idea =
that 100% will cause outages.

As a thought =
experiment, let's suppose I (as the Security Officer) use the system you =
propose and require users to pin specific keys on our publicly available =
servers. Now let's further suppose that the project is compromised such =
that we believe those certificates might be in the hands of the =
attacker, but we aren't sure. I'm now stuck between a rock and hard =
place. Should I rotate the pinned certificate? In your proposed system, =
rotating that pinned certificate will cause massive downstream failures =
for all users. Since we aren't sure, maybe I'll leave the existing =
certificate in place, because I don't want to cause those outages since =
I'm not sure it's a problem.

In the publicly =
trusted CA system, I can easily rotate the certificate even if I don't =
believe it was compromised. It incentivizes better behavior. Also, =
please don't lecture me on the problems with the publicly trusted CA =
system: I'm very familiar with them. That said, it's the system we have =
and I have no interest in trying to tilt at that particular =
windmill.

In any event, nothing is preventing =
you from doing this on your own as the system ships with the tools to do =
so. Recognize the project has a need for cryptographic agility and =
ability to change certificates whenever we need to. Running our own root =
CA infrastructure necessary to provide a similar level of assurance to a =
professionally run CA is non-trivial and I don't believe we as a project =
are in a position (or interested) in taking on such a =
burden.

Gordon
=

--Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F--

From nobody Sun Dec  4 06:33:33 2022
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 4NPxhp0vynz4jWnN;
	Sun,  4 Dec 2022 06:33:46 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NPxhm2ngdz4bPB;
	Sun,  4 Dec 2022 06:33:44 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp;
	dmarc=none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2B46XXAo082514;
	Sun, 4 Dec 2022 15:33:34 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Sun, 4 Dec 2022 15:33:33 +0900
From: Tomoaki AOKI 
To: freebsd-hackers@freebsd.org
Cc: freebsd-current@freebsd.org
Subject: Re: CA's TLS Certificate Bundle in base = BAD
Message-Id: <20221204153333.675a324591300db93dc11089@dec.sakura.ne.jp>
In-Reply-To: 
References: 
	
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-1.46 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	AUTH_NA(1.00)[];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.86)[-0.860];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_SPF_NA(0.00)[no SPF record];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org];
	RCVD_TLS_LAST(0.00)[];
	HAS_ORG_HEADER(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DMARC_NA(0.00)[sakura.ne.jp];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NPxhm2ngdz4bPB
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

Hi.
IMHO, bundling certs on base should be mandatory, at least for
freebsd.org ones.

Without them, how can users download initial certs from ports safely,
and without annoying warnings?

Maybe limiting initially-bundled certs for freebsd.org ones only on
base itself, and forcibly install pkgs ones on install (bundled in all
install media, and upgradable later with pkg or rebuilding with ports)
could be better.


On Sat, 3 Dec 2022 20:26:16 -0500
grarpamp  wrote:

> Again, FreeBSD should not be including the bundle in base, if users
> choose to, they can get it from ports or packages or wherever else.
> Including such bundles exposes users worldwide to massive risks.
> You need to do more gpg attestation, pubkey pinning [1], tofu, and
> cert management starting from empty file... and quit trusting bundles of
> hundreds of random CA's, all of which are entities who have zero duty
> or care to the user, and often exist/corrupt/break to present evil [2] ...
> 
> [1]
> https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d
> https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3
> 
> FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple option,
> thus they're incapable of securely fetching packages, iso's, etc from
> servers in re [2]. Nor does FreeBSD even post sigs over its servers pubkeys
> for users to get, verify, and pin out of band. Even pubkeys were swapped out
> on FreeBSD servers without announcing for users if any exploit or loss occurred
> there or for some other reason. That's all bad news :( But can be fixed :)
> 
> 
> [2]
> https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections
> https://www.msn.com/en-us/news/technology/mysterious-company-with-government-ties-plays-key-internet-role/ar-AA13RwPh
> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/etbBho-VBQAJ
> 
> Major Web Browsers Drop Mysterious Authentication Company After Ties
> To US Military Contractor Exposed
> 
> TrustCor Systems vouches for the legitimacy of websites. But its
> physical address is a UPS Store in Toronto.
> 
> Mysterious company with government ties plays key internet role
> 
> An offshore company that is trusted by the major web browsers and
> other tech companies to vouch for the legitimacy of websites has
> connections to contractors for U.S. intelligence agencies and law
> enforcement, according to security researchers, documents and
> interviews.
> Google’s Chrome, Apple’s Safari, nonprofit Firefox and others allow
> the company, TrustCor Systems, to act as what’s known as a root
> certificate authority, a powerful spot in the internet’s
> infrastructure that guarantees websites are not fake, guiding users to
> them seamlessly.
> The company’s Panamanian registration records show that it has the
> identical slate of officers, agents and partners as a spyware maker
> identified this year as an affiliate of Arizona-based Packet
> Forensics, which public contracting records and company documents show
> has sold communication interception services to U.S. government
> agencies for more than a decade.
> One of those TrustCor partners has the same name as a holding company
> managed by Raymond Saulino, who was quoted in a 2010 Wired article as
> a spokesman for Packet Forensics.
> Saulino also surfaced in 2021 as a contact for another company, Global
> Resource Systems, that caused speculation in the tech world when it
> briefly activated and ran more than 100 million previously dormant IP
> addresses assigned decades earlier to the Pentagon. The Pentagon
> reclaimed the digital territory months later, and it remains unclear
> what the brief transfer was about, but researchers said the activation
> of those IP addresses could have given the military access to a huge
> amount of internet traffic without revealing that the government was
> receiving it.
> The Pentagon did not respond to a request for comment on TrustCor.
> TrustCor also did not respond to a request for comment.
> [Minutes before Trump left office, millions of the Pentagon’s dormant
> IP addresses sprang to life]
> TrustCor’s products include an email service that claims to be
> end-to-end encrypted, though experts consulted by The Washington Post
> said they found evidence to undermine that claim. A test version of
> the email service also included spyware developed by a Panamanian
> company related to Packet Forensics, researchers said. Google later
> banned all software containing that spyware code from its app store.
> A person familiar with Packet Forensics’ work confirmed that it had
> used TrustCor’s certificate process and its email service, MsgSafe, to
> intercept communications and help the U.S. government catch suspected
> terrorists.
> “Yes, Packet Forensics does that,†the person said, speaking on the
> condition of anonymity to discuss confidential practices.
> Packet Forensics counsel Kathryn Temel said the company has no
> business relationship with TrustCor. She declined to say whether it
> had had one previously.
> The latest discovery shows how the technological and business
> complexities of the internet’s inner workings can be leveraged to an
> extent that is rarely revealed.
> Concerns about root certificate authorities, though, have come up before.
> In 2019, a security company controlled by the government of the United
> Arab Emirates that had been known as DarkMatter applied to be upgraded
> to top-level root authority from intermediate authority with less
> independence. That followed revelations about DarkMatter hacking
> dissidents and even some Americans; Mozilla denied it root power.
> In 2015, Google withdrew the root authority of the China Internet
> Network Information Center (CNNIC) after it allowed an intermediate
> authority to issue fake certificates for Google sites.
> With Packet Forensics, a paper trail led to it being identified by
> researchers twice this year. Mostly known for selling interception
> devices and tracking services to authorities, the company is four
> months into a $4.6 million Pentagon contract for “data processing,
> hosting and related services.â€
> In the earlier spyware matter, researchers Joel Reardon of the
> University of Calgary and Serge Egelman of the University of
> California at Berkeley found that a Panamanian company, Measurement
> Systems, had been paying developers to include code in a variety of
> innocuous apps to record and transmit users’ phone numbers, email
> addresses and exact locations. They estimated that those apps were
> downloaded more than 60 million times, including 10 million downloads
> of Muslim prayer apps.
> Measurement Systems’ website was registered by Vostrom Holdings,
> according to historic domain name records. Vostrom filed papers in
> 2007 to do business as Packet Forensics, according to Virginia state
> records. Measurement Systems was registered in Virginia by Saulino,
> according to another state filing.
> After the researchers shared their findings, Google booted all apps
> with the spy code out of its Play app store.
> Tremel said that “a company previously associated with Packet
> Forensics was a customer of Measurement Systems at one time†but that
> there was no ownership stake.
> When Reardon and Egelman looked deeper at Vostrom, they found it had
> registered the domain name TrustCor.co, which directed visitors to the
> main TrustCor site. TrustCor has the same president, agents and
> holding-company partners listed in Panamanian records as Measurement
> Systems.
> A firm with the same name as one of the holding companies behind both
> TrustCor and Measurement Systems, Frigate Bay Holdings, filed papers
> to dissolve this March with the secretary of state in Wyoming, where
> it was formed. The papers were signed by Saulino, who listed his title
> as manager. He could not be reached for comment.
> TrustCor has issued more than 10,0000 certificates, many of them for
> sites hosted with a dynamic domain name service provider called No-IP,
> the researchers said. That service allows websites to be hosted with
> constantly changing Internet Protocol addresses.
> Because root authority is so powerful, TrustCor can also give others
> the right to issue certificates.
> Certificates for websites are publicly viewable so that bad ones
> should be exposed sooner or later. There have been no reports so far
> that the TrustCor certificates have been used inappropriately, for
> example by vouching for impostor websites. The researchers speculated
> that the system is only used against high-value targets within short
> windows of time. The person familiar with Packet Forensics’ operations
> agreed said that was in fact how it has been used.
> “They have this position of ultimate trust, where they can issue
> encryption keys for any arbitrary website and any email address,â€
> Egelman said. “It’s scary this is being done by some shady private
> company.â€
> The leadership page of the TrustCor’s website lists just two men,
> identified as co-founders. Though that page does not say so, one of
> them died months ago, and the other’s LinkedIn profile says he left as
> chief technology officer in 2019. That man declined to comment.
> The website site lists a contact phone number in Panama, which has
> been disconnected, and one in Toronto, where a message had not been
> returned after more than a week. The email contact form on the site
> doesn’t work. The physical address in Toronto given in its auditor’s
> report, 371 Front St. West, houses a UPS Store mail drop.
> TrustCor adds another layer of mystery with its outside auditing firm.
> Instead of using a major accounting firm that rates the safety of
> internet infrastructure companies, TrustCor selected one called
> Princeton Audit Group, which gives its address as a residential
> townhouse in Princeton, N.J.
> In addition to TrustCor’s certificate power, the firm offers what
> purports to be end-to-end encrypted email, MsgSafe.io. But researchers
> said the email is not encrypted and can be read by the company, which
> has pitched it to a variety of groups worried about surveillance.
> MsgSafe has touted its security to a variety of potential customers,
> including Trump supporters upset that Parler had been dropped by app
> stores in January 2021, and to users of encrypted mail service
> Tutanota who were blocked from signing on to Microsoft services.
> “Create your free end-to-end encrypted email today with over 40
> domains to choose from and are guaranteed to work with Microsoft
> Teams,†the company tweeted in August.
> Reardon sent test messages over MsgSafe that appeared unencrypted in
> transmission, meaning MsgSafe could read them at will. Egelman ran the
> same test with the same result.
> Jon Callas, a cryptography expert at the Electronic Frontier
> Foundation, also tested the system at The Post’s request and said that
> MsgSafe generated and kept the private key for his account, so that it
> could decrypt anything he sent.
> “The private key has to be under the person’s control to be
> end-to-end,†Callas explained.
> Packet Forensics first drew attention from privacy advocates a dozen years ago.
> In 2010, researcher Chris Soghoian attended an invite-only industry
> conference nicknamed the Wiretapper’s Ball and obtained a Packet
> Forensics brochure aimed at law enforcement and intelligence agency
> customers.
> The brochure was for a piece of hardware to help buyers read web
> traffic that parties thought was secure. But it wasn’t.
> “IP communication dictates the need to examine encrypted traffic at
> will,†the brochure read, according to a report in Wired that quoted
> Saulino as a Packet Forensics spokesman. “Your investigative staff
> will collect its best evidence while users are lulled into a false
> sense of security afforded by web, e-mail or VOIP encryption,†the
> brochure added.
> The brochure told customers they could use a decryption key provided
> by a court order or a “look-alike key.â€
> Researchers thought at the time that the most likely way the box was
> being used was with a certificate issued by an authority for money or
> under a court order that would guarantee the authenticity of an
> impostor communications site.
> They did not conclude that an entire certificate authority itself
> might be compromised.
> Obtaining trusted root certificate authority takes time and money for
> the infrastructure and for the audit that browsers require, experts
> say.
> Each browser has slightly different requirements. At Mozilla’s
> Firefox, the process takes two years and includes crowdsourced and
> direct vetting as well as an audit.
> But all of that typically focuses on formal statements of
> technological steps, rather than mysteries of ownership and intent.
> The person familiar with Packet Forensics said the big tech companies
> probably were unwitting participants in the TrustCor play: “Most
> people aren’t paying attention.â€
> “With enough money, you or I could become a trusted root certificate
> authority,†said Daniel Schwalbe, vice president of technology at web
> data tracker DomainTools.
> Mozilla currently recognizes 169 root certificate authorities,
> including three from TrustCor.
> The case gives new focus to problems with that system, in which
> critical tech companies outsource their trust to third parties with
> their own agendas.
> “You can’t bootstrap trust, it has to come from somewhere,†Reardon
> said. “Root certificate authorities are the kernel of trust from which
> it is all built on. And it will always be shaky, because it will
> always involve humans, committees and decision-making.â€
> Reardon and Egelman alerted Google, Mozilla and Apple to their
> research on TrustCor in April. They said they have heard little back.
> Google did not respond to a request for comment.
> Mozilla said it would say more after reviewing details from the researchers.
> 
> 
> Major Web Browsers Drop Mysterious Authentication Company After Ties
> To US Military Contractor Exposed
> 
> This week several major web browsers quickly severed ties with a
> mysterious software company used to certify the security of websites,
> three weeks after the Washington Post exposed its connections to a US
> military contractor, the Post reports.
> 
> TrustCor Systems provided 'certificates' to browsers to Mozilla
> Firefox and Microsoft Edge, which vouched for the legitimacy of said
> websites.
> 
> "Certificate Authorities have highly trusted roles in the internet
> ecosystem and it is unacceptable for a CA to be closely tied, through
> ownership and operation, to a company engaged in the distribution of
> malware," said Mozilla's Kathleen Wilson in an email to browser
> security experts. "Trustcor’s responses via their Vice President of CA
> operations further substantiates the factual basis for Mozilla’s
> concerns."
> 
> According to TrustCor's Panamanian (!?) registration records, the
> company has the same slate of officers, agents and officers as
> Arizona-based Packet Forensics, which has sold communication
> interception services to the U.S. government for over a decade.
> 
>     One of those contracts listed the “place of performance†as Fort
> Meade, Md., the home of the National Security Agency and the
> Pentagon’s Cyber Command.
> 
>     The case has put a new spotlight on the obscure systems of trust
> and checks that allow people to rely on the internet for most
> purposes. Browsers typically have more than a hundred authorities
> approved by default, including government-owned ones and small
> companies, to seamlessly attest that secure websites are what they
> purport to be. -WaPo
> 
> Also of concern, TrustCor's small staff in Canada lists its place of
> operation at a UPS Store mail drop, according to company executive
> Rachel McPherson, who says she told their Canadian staffers to work
> remotely. She also acknowledged that the company has 'infrastructure'
> in Arizona as well.
> 
> McPherson says that ownership in TrustCor was transferred to employees
> despite the fact that some of the same holding companies had invested
> in both TrustCor and Packet Forensics.
> 
> Various technologists in the email discussion said they found TrustCor
> to be evasive when it came to basic facts such as legal domicile and
> ownership - which they said was not appropriate for a company
> responsible for root certificate authority that verifies a secure
> 'https' website is not an imposter.
> 
>     The Post report built on the work of two researchers who had first
> located the company’s corporate records, Joel Reardon of the
> University of Calgary and Serge Egelman of the University of
> California at Berkeley. Those two and others also ran experiments on a
> secure email offering from TrustCor named MsgSafe.io. They found that
> contrary to MsgSafe’s public claims, emails sent through its system
> were not end-to-end encrypted and could be read by the company.
> 
>     McPherson said the various technology experts had not used the
> right version or had not configured it properly. -WaPo
> 
> In a previous case which illustrates the importance of trusting
> root-level authorities - a security company controlled by the United
> Arab Emirates, DarkMatter, applied in 2019 to have top-level root
> authority from their status as an intermediate authority with less
> independence. The request followed revelations that DarkMatter had
> hacked dissidents and even some Americans - after which Mozilla denied
> it root power.
> 
> 
> "Received email from DDNS no-IP, they offering free TrustCor Standard
> DV SSL certificate."
> "Free, comes complete with spyveillance and exploit, lol."
> "Imagine that even the most trusted CA's are actually rogue!"
> 
> 


-- 
Tomoaki AOKI    

From nobody Mon Dec  5 15:42:29 2022
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 4NQnr22fKbz4k0tL
	for ; Mon,  5 Dec 2022 15:42:58 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NQnr10JCnz3plb
	for ; Mon,  5 Dec 2022 15:42:56 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu;
	dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none)
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 2B5FgTua011480
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
	for ; Mon, 5 Dec 2022 07:42:29 -0800 (PST)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 2B5FgTqb011479
	for freebsd-current@freebsd.org; Mon, 5 Dec 2022 07:42:29 -0800 (PST)
	(envelope-from sgk)
Date: Mon, 5 Dec 2022 07:42:29 -0800
From: Steve Kargl 
To: freebsd-current@freebsd.org
Subject: The dma mess
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	RCVD_TLS_LAST(0.00)[];
	R_DKIM_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US];
	RCVD_COUNT_THREE(0.00)[3];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	REPLYTO_ADDR_EQ_FROM(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]
X-Rspamd-Queue-Id: 4NQnr10JCnz3plb
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

If one has not seen Mike Karel's email, here's the URL.

https://lists.freebsd.org/archives/dev-commits-src-main/2022-December/011300.html

The upshot is 

1) No entry in src/UPDATING about dma replacing sendmail, and thereby
   breaking a function system on upgrade.

2) Having sendmail_enable="YES" in /etc/rc.conf no longer works
   after an upgrade, because dma replaces /etc/mail/mailer.conf.
   sendmail appears to start, but exits immediately.  One needs
   to go through a serious of git commits to find out about this
   easter egg.

3) It seems that now one must also add

   sendmail_submit_enable="YES"
   sendmail_msp_queue_enable="YES"
   sendmail_outbound_enable="YES"

   to rc.conf to recover a functioning sendmail.

When I upgrade the system next month, will dma remove the 
ability to use sendmail without unfixing whatever damage
it does?

POLA?

-- 
Steve

From nobody Mon Dec  5 16:30:50 2022
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 4NQpvL2L6pz4k6DL
	for ; Mon,  5 Dec 2022 16:30:54 +0000 (UTC)
	(envelope-from bapt@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NQpvL1tngz3wNK;
	Mon,  5 Dec 2022 16:30:54 +0000 (UTC)
	(envelope-from bapt@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1670257854;
	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=6hKjqbY7KB0QMWAcUYRWiSBn5kjJljGROBj5MLdyWt4=;
	b=V75mWV+hfOfqHKkeL8p7ylPfEupjQQfMXgwNzcZI2vsG477MF/AKqxUVNRI0/FG9i5c6OV
	sPwSIZEwiOJWlG9hIUCCNBvYzx4Ed8otC2h+JvWWBzDty1dzhdUF33HEaTsrkYTBiFEc1H
	O5vu+AKboNat8l+bXeUjkObf6QyiAmehJE4Ahb3VVztws33L5fhd/BwKrGloxHEeBRFin6
	bdnMbKjeoxS2tbO4zZVNaIPSMo3NMihqF+NhebEoh9P7yl6TeeUivfmAzUoJrZ9IG0Zjja
	oyL/XXxMSXu6Avur0uGJXusF0sCe9o0deCHgFLl2Qst5xCHnvtHinTZPowpMkw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1670257854;
	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=6hKjqbY7KB0QMWAcUYRWiSBn5kjJljGROBj5MLdyWt4=;
	b=iq72UHRZNakcq/tAkaXw76qrkkwE8iHT9Bhb/v9c9F50CfrpPHX0jW7rKFHKy6eTPxTbNb
	tznhrXCZXQoNPQVFTE/hAdYBWGEP5Y2wM7phuUH+dRvx+nXF3mkY9nFaAxjgdYDWGCfIVj
	UI6pMJUQ1g4PuFT1XvGsP2aJoV3bt+3KLRHiefNkzFlYuxU5S/SzRL4sAafVkwadmkjT42
	S/sIqbVrrcma+P6ZANdexsXA+IfIiS4UWzkTcm/VVtw429NB/qUX20n0EHJuvbNWmVgsxL
	qcI8GxBPqLw68q48mj9KDJ34gJiGzaAfbRQ54UPqw6+jvGs7teb7+snVHKitSA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670257854; a=rsa-sha256; cv=none;
	b=fyVmK2lgdET2EFf0BK01fuYi4MIZHJL0ZnGxyr5qHNXrAS2AigaH1oC2V0uU/WchM30bIX
	z9slyHPzWmJYQ0mrmivsw5m+Pq5cZptPSFESf2FbcP4B3Mm/WRfm6yrxFB5mLokBuDTWun
	2pmcXolzkChvAldohuADFMPN2Pk1XeBbqfAMoTtOW6qvhabq1f0XFY4iN9WBGTx0AAg46D
	uO3+1EzP55FpkHwoqwCJ3Z6pa5btr1eAsyz3JrbVDWoF8ZCmzULF33L9utTQ0eYbrelKxs
	rmzYUdC9rhe178XLwK20/z9IV+QAFxX7uzgz4HN4Ni/1tiBCVbFvDfzc+0Chpg==
Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::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)
	(Authenticated sender: bapt)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NQpvL0ChBz12FS;
	Mon,  5 Dec 2022 16:30:54 +0000 (UTC)
	(envelope-from bapt@FreeBSD.org)
Received: by aniel.nours.eu (Postfix, from userid 1001)
	id DB24718B046; Mon,  5 Dec 2022 17:30:50 +0100 (CET)
Date: Mon, 5 Dec 2022 17:30:50 +0100
From: Baptiste Daroussin 
To: Steve Kargl 
Cc: freebsd-current@freebsd.org
Subject: Re: The dma mess
Message-ID: <20221205163050.n76tjwsrkhoug2kk@aniel.nours.eu>
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-ThisMailContainsUnwantedMimeParts: N

On Mon, Dec 05, 2022 at 07:42:29AM -0800, Steve Kargl wrote:
> If one has not seen Mike Karel's email, here's the URL.
> 
> https://lists.freebsd.org/archives/dev-commits-src-main/2022-December/011300.html
> 
> The upshot is 
> 
> 1) No entry in src/UPDATING about dma replacing sendmail, and thereby
>    breaking a function system on upgrade.

Fixed
> 
> 2) Having sendmail_enable="YES" in /etc/rc.conf no longer works
>    after an upgrade, because dma replaces /etc/mail/mailer.conf.
>    sendmail appears to start, but exits immediately.  One needs
>    to go through a serious of git commits to find out about this
>    easter egg.

It does again.
> 
> 3) It seems that now one must also add
> 
>    sendmail_submit_enable="YES"
>    sendmail_msp_queue_enable="YES"
>    sendmail_outbound_enable="YES"
> 
>    to rc.conf to recover a functioning sendmail.

Not anymore.

Bapt

From nobody Mon Dec  5 16:54:23 2022
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 4NQqQt2BRYz4k90y
	for ; Mon,  5 Dec 2022 16:54:46 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "troutmask", Issuer "troutmask" (not verified))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NQqQt0s92z47VR;
	Mon,  5 Dec 2022 16:54:45 +0000 (UTC)
	(envelope-from sgk@troutmask.apl.washington.edu)
Authentication-Results: mx1.freebsd.org;
	none
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 2B5GsNaA012022
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 5 Dec 2022 08:54:23 -0800 (PST)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 2B5GsNRm012021;
	Mon, 5 Dec 2022 08:54:23 -0800 (PST)
	(envelope-from sgk)
Date: Mon, 5 Dec 2022 08:54:23 -0800
From: Steve Kargl 
To: Baptiste Daroussin 
Cc: freebsd-current@freebsd.org
Subject: Re: The dma mess
Message-ID: 
Reply-To: sgk@troutmask.apl.washington.edu
References: 
 <20221205163050.n76tjwsrkhoug2kk@aniel.nours.eu>
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: <20221205163050.n76tjwsrkhoug2kk@aniel.nours.eu>
X-Rspamd-Queue-Id: 4NQqQt0s92z47VR
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Mon, Dec 05, 2022 at 05:30:50PM +0100, Baptiste Daroussin wrote:
> On Mon, Dec 05, 2022 at 07:42:29AM -0800, Steve Kargl wrote:
> > If one has not seen Mike Karel's email, here's the URL.
> > 
> > https://lists.freebsd.org/archives/dev-commits-src-main/2022-December/011300.html
> > 
> > The upshot is 
> > 
> > 1) No entry in src/UPDATING about dma replacing sendmail, and thereby
> >    breaking a function system on upgrade.
> 
> Fixed
> > 
> > 2) Having sendmail_enable="YES" in /etc/rc.conf no longer works
> >    after an upgrade, because dma replaces /etc/mail/mailer.conf.
> >    sendmail appears to start, but exits immediately.  One needs
> >    to go through a serious of git commits to find out about this
> >    easter egg.
> 
> It does again.
> > 
> > 3) It seems that now one must also add
> > 
> >    sendmail_submit_enable="YES"
> >    sendmail_msp_queue_enable="YES"
> >    sendmail_outbound_enable="YES"
> > 
> >    to rc.conf to recover a functioning sendmail.
> 
> Not anymore.
> 

Thanks.  

-- 
Steve

From nobody Mon Dec  5 17:37:32 2022
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 4NQrNV0Nvjz4kFKF
	for ; Mon,  5 Dec 2022 17:37:46 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NQrNT1WFNz4Fkj
	for ; Mon,  5 Dec 2022 17:37:45 +0000 (UTC)
	(envelope-from bsd-lists@bsdforge.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of bsd-lists@bsdforge.com has no SPF policy when checking 24.113.41.81) 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 2B5HbXpY004657
	for ; Mon, 5 Dec 2022 09:37:39 -0800 (PST)
	(envelope-from bsd-lists@bsdforge.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
Date: Mon, 05 Dec 2022 09:37:32 -0800
From: Chris 
To: freebsd-current 
Subject: Why was Sendmail replaced with DMA?
User-Agent: UDNSMS/17.0
Message-ID: <8abdbf2771e76dbdd35f49e76b8f7cf9@bsdforge.com>
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_eff64f083072cb238289a8bd878950a2"
X-Rspamd-Queue-Id: 4NQrNT1WFNz4Fkj
X-Spamd-Bar: +
X-Spamd-Result: default: False [1.00 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	MIME_UNKNOWN(0.10)[application/pgp-keys];
	MIME_GOOD(-0.10)[multipart/mixed,text/plain];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US];
	R_DKIM_NA(0.00)[];
	local_wl_ip(0.00)[24.113.41.81];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	HAS_ATTACHMENT(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=multimap;
	Matched map: local_wl_ip
X-ThisMailContainsUnwantedMimeParts: N

--=_eff64f083072cb238289a8bd878950a2
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

I just noticed that FreeBSD will now install dma(8) instead of
sendmail(8) as the default mailer. Why is this so?

Thank you

--chris
--=_eff64f083072cb238289a8bd878950a2
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_eff64f083072cb238289a8bd878950a2--

From nobody Mon Dec  5 18:08:28 2022
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 4NQs4C66pvz4kJfj
	for ; Mon,  5 Dec 2022 18:08:43 +0000 (UTC)
	(envelope-from rainer@ultra-secure.de)
Received: from connect.ultra-secure.de (connect.ultra-secure.de [88.198.71.201])
	by mx1.freebsd.org (Postfix) with ESMTP id 4NQs4C1MMzz4K8w
	for ; Mon,  5 Dec 2022 18:08:42 +0000 (UTC)
	(envelope-from rainer@ultra-secure.de)
Authentication-Results: mx1.freebsd.org;
	none
Received: (Haraka outbound); Mon, 05 Dec 2022 19:08:35 +0100
Received-SPF: SoftFail (connect.ultra-secure.de: domain of ultra-secure.de does not designate 127.0.0.10 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=127.0.0.10; helo=connect.ultra-secure.de; envelope-from=
Received: from connect.ultra-secure.de (webmail [127.0.0.10])
	by connect.ultra-secure.de (Haraka/2.6.2-toaster) with ESMTPSA id FA014DBE-AD62-4F34-9CE5-A90DF670F3CA.1
	envelope-from  (authenticated bits=0)
	(version=TLSv1/SSLv3 cipher=AES256-SHA verify=NO);
	Mon, 05 Dec 2022 19:08:29 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 05 Dec 2022 19:08:28 +0100
From: rainer@ultra-secure.de
To: Chris 
Cc: freebsd-current ,
 owner-freebsd-current@freebsd.org
Subject: Re: Why was Sendmail replaced with DMA?
In-Reply-To: <8abdbf2771e76dbdd35f49e76b8f7cf9@bsdforge.com>
References: <8abdbf2771e76dbdd35f49e76b8f7cf9@bsdforge.com>
Message-ID: <01994b0a101b6b2003c8404c29316467@ultra-secure.de>
X-Sender: rainer@ultra-secure.de
User-Agent: Roundcube Webmail/1.2.0
X-Haraka-GeoIP: --, , NaNkm
X-Haraka-GeoIP-Received: 
X-Haraka-p0f: os="undefined undefined" link_type="undefined" distance=undefined total_conn=undefined shared_ip=Y
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on spamassassin
X-Spam-Level: 
X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1
X-Haraka-Karma: score: 6, good: 1620, bad: 0, connections: 1626, history: 1620, pass:all_good, relaying
X-Rspamd-Queue-Id: 4NQs4C1MMzz4K8w
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:24940, ipnet:88.198.0.0/16, country:DE]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Am 2022-12-05 18:37, schrieb Chris:
> I just noticed that FreeBSD will now install dma(8) instead of
> sendmail(8) as the default mailer. Why is this so?
> 
> Thank you
> 
> --chris


I think the problem was that the original developers of sendmail have 
mostly disappeared.
More or less.

It looked like abandonware.

I'm sorry for the people who still use and love it - but the first thing 
we do is install postfix and set a relayhost...


Rainer

From nobody Mon Dec  5 18:26:22 2022
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 4NQsT636Bmz4j7RR
	for ; Mon,  5 Dec 2022 18:26:50 +0000 (UTC)
	(envelope-from gshapiro@freebsd.org)
Received: from zim.gshapiro.net (zim.gshapiro.net [IPv6:2001:bc8:2e97:100::100])
	(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.gshapiro.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NQsT54xj1z4Mn1
	for ; Mon,  5 Dec 2022 18:26:49 +0000 (UTC)
	(envelope-from gshapiro@freebsd.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: from C02Y1186JHD2.corp.proofpoint.com ([IPv6:2600:8805:a810:4200:47c:ca57:5f17:dcbd])
	(authenticated bits=0)
	by zim.gshapiro.net (8.17.0.4/8.17.0.4) with ESMTPSA id 2B5IQMAr060722
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 5 Dec 2022 18:26:26 GMT
Date: Mon, 5 Dec 2022 13:26:22 -0500
From: Gregory Shapiro 
To: rainer@ultra-secure.de
Cc: Chris ,
        freebsd-current 
Subject: Re: Why was Sendmail replaced with DMA?
Message-ID: <20221205182622.uncqg3djv5yskzlw@C02Y1186JHD2.corp.proofpoint.com>
References: <8abdbf2771e76dbdd35f49e76b8f7cf9@bsdforge.com>
 <01994b0a101b6b2003c8404c29316467@ultra-secure.de>
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: <01994b0a101b6b2003c8404c29316467@ultra-secure.de>
X-Rspamd-Queue-Id: 4NQsT54xj1z4Mn1
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:12876, ipnet:2001:bc8::/32, country:FR]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

> I think the problem was that the original developers of sendmail have mostly
> disappeared.
> More or less.
> It looked like abandonware.

Nope, still here.  Granted, the release cycle has slowed, but new
features are being tested and coming (e.g.,  SMTPUTF8/EAI, MTA-STS).

I'll be integrating 8.17.2 into FreeBSD upon its release as it has
stabilized the EAI work for those who wish to use it.

From nobody Mon Dec  5 18:43:22 2022
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 4NQsrL307Sz4j9my
	for ; Mon,  5 Dec 2022 18:43:30 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NQsrL1L9Qz4QBF;
	Mon,  5 Dec 2022 18:43:30 +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 2B5IhNAS002111;
	Mon, 5 Dec 2022 10:43:29 -0800 (PST)
	(envelope-from bsd-lists@bsdforge.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
Date: Mon, 05 Dec 2022 10:43:22 -0800
From: Chris 
To: Gregory Shapiro 
Cc: rainer@ultra-secure.de, freebsd-current 
Subject: Re: Why was Sendmail replaced with DMA?
In-Reply-To: <20221205182622.uncqg3djv5yskzlw@C02Y1186JHD2.corp.proofpoint.com>
References: <8abdbf2771e76dbdd35f49e76b8f7cf9@bsdforge.com>
 <01994b0a101b6b2003c8404c29316467@ultra-secure.de>
 <20221205182622.uncqg3djv5yskzlw@C02Y1186JHD2.corp.proofpoint.com>
User-Agent: UDNSMS/17.0
Message-ID: <8743b8bb73d58c943a97ae9f69af74d3@bsdforge.com>
X-Sender: bsd-lists@bsdforge.com
Content-Type: multipart/mixed;
 boundary="=_23752ceb0c4a20351faea2cfeb2b3d5b"
X-Rspamd-Queue-Id: 4NQsrL1L9Qz4QBF
X-Spamd-Bar: ----
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-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--=_23752ceb0c4a20351faea2cfeb2b3d5b
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed

On 2022-12-05 10:26, Gregory Shapiro wrote:
>> I think the problem was that the original developers of sendmail have 
>> mostly
>> disappeared.
>> More or less.
>> It looked like abandonware.
Oh. You mean for Political reasons. :-(

> 
> Nope, still here.  Granted, the release cycle has slowed, but new
> features are being tested and coming (e.g.,  SMTPUTF8/EAI, MTA-STS).
> 
> I'll be integrating 8.17.2 into FreeBSD upon its release as it has
> stabilized the EAI work for those who wish to use it.
Thank you very much, Gregory. I use it for all it's intended use cases,
but have also leveraged it to generate a list of "bad actors" that I
add to pf(4). The list is verified daily and currently contains `half
a billion IPv4 IP's. I could have never managed anything like this with
all the other mailers available. Can I help sponsor your work in any way?

Thanks again!

--chris
--=_23752ceb0c4a20351faea2cfeb2b3d5b
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-keys;
 name=0xBDE49540.asc
Content-Disposition: attachment;
 filename=0xBDE49540.asc;
 size=5028

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A
2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ
xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs
+OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9
5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd
oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z
b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC
AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk
cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk
ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM
jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG
zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ
vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM
lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT
hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI
AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y
ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA
aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr
dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx
z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f
nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka
KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w
uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz
Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5
cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa
AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+
7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1
Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly
zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f
vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP
wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz
dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6
Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF
CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S
+Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV
V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL
xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W
D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J
/YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv
cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC
GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe
fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ
Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG
/NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu
TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A
BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC
MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo
e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG
CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh
BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH
/jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ
0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F
sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM
79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs
Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630
zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu
c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz
Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8
BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt
SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy
yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq
fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9
KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK
3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI
ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00
QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR
/WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ
wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl
8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH
4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ
ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+
sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te
iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V
k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq
u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P
DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob
1hJ30C8=
=aMQi
-----END PGP PUBLIC KEY BLOCK-----

--=_23752ceb0c4a20351faea2cfeb2b3d5b--

From nobody Mon Dec  5 19:16:47 2022
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 4NQtbW1NqPz4jGM8
	for ; Mon,  5 Dec 2022 19:17:27 +0000 (UTC)
	(envelope-from gshapiro@freebsd.org)
Received: from zim.gshapiro.net (zim.gshapiro.net [IPv6:2001:bc8:2e97:100::100])
	(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.gshapiro.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NQtbV6y07z3H94
	for ; Mon,  5 Dec 2022 19:17:26 +0000 (UTC)
	(envelope-from gshapiro@freebsd.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: from C02Y1186JHD2.corp.proofpoint.com ([IPv6:2600:8805:a810:4200:47c:ca57:5f17:dcbd])
	(authenticated bits=0)
	by zim.gshapiro.net (8.17.0.4/8.17.0.4) with ESMTPSA id 2B5JGmBT061605
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Mon, 5 Dec 2022 19:17:15 GMT
Date: Mon, 5 Dec 2022 14:16:47 -0500
From: Gregory Shapiro 
To: Chris 
Cc: freebsd-current 
Subject: Re: Why was Sendmail replaced with DMA?
Message-ID: <20221205191647.ymgcash7rw4ffue4@C02Y1186JHD2.corp.proofpoint.com>
References: <8abdbf2771e76dbdd35f49e76b8f7cf9@bsdforge.com>
 <01994b0a101b6b2003c8404c29316467@ultra-secure.de>
 <20221205182622.uncqg3djv5yskzlw@C02Y1186JHD2.corp.proofpoint.com>
 <8743b8bb73d58c943a97ae9f69af74d3@bsdforge.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: <8743b8bb73d58c943a97ae9f69af74d3@bsdforge.com>
X-Rspamd-Queue-Id: 4NQtbV6y07z3H94
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:12876, ipnet:2001:bc8::/32, country:FR]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

> Thank you very much, Gregory. I use it for all it's intended use cases,
> but have also leveraged it to generate a list of "bad actors" that I
> add to pf(4). The list is verified daily and currently contains `half
> a billion IPv4 IP's. I could have never managed anything like this with
> all the other mailers available. Can I help sponsor your work in any way?

Thank you, no sponsorship necessary though if you want to sponsor the
greater FreeBSD effort, consider the FreeBSD Foundation:

https://freebsdfoundation.org/


From nobody Tue Dec  6 03:49:53 2022
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 4NR5yr4F23z4jbSC
	for ; Tue,  6 Dec 2022 03:49:56 +0000 (UTC)
	(envelope-from pat@patmaddox.com)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29])
	(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 4NR5yq66p8z3Hfx
	for ; Tue,  6 Dec 2022 03:49:55 +0000 (UTC)
	(envelope-from pat@patmaddox.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=patmaddox.com header.s=fm3 header.b="w/JbheQT";
	dkim=pass header.d=messagingengine.com header.s=fm1 header.b=lcH4lGhF;
	spf=pass (mx1.freebsd.org: domain of pat@patmaddox.com designates 66.111.4.29 as permitted sender) smtp.mailfrom=pat@patmaddox.com;
	dmarc=none
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
	by mailout.nyi.internal (Postfix) with ESMTP id 3780E5C0276;
	Mon,  5 Dec 2022 22:49:55 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
  by compute4.internal (MEProxy); Mon, 05 Dec 2022 22:49:55 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=patmaddox.com;
	 h=cc:content-transfer-encoding:content-type:date:date:from:from
	:in-reply-to:message-id:mime-version:reply-to:sender:subject
	:subject:to:to; s=fm3; t=1670298595; x=1670384995; bh=v+irAIJp69
	kcxU2a5tVUlSkvo+gh9m5QbWkX9HDQYNU=; b=w/JbheQTzjqbKtv7uvj60Yk1cd
	N9ShpuPhAJuWo4pL1GtME2gLbwQW079b9jghCIj1bFwR6Rrrf/upJXTtuGwWSnAH
	QsfsSoBiP2j46rB3cIC45v0OqEGF3L6Sz1zEuSnR+q8Ga/KQLw6859YSySIJv7NJ
	zkP4R4hnheMJxzu6IvLgSM8uf/aYsK2dmuTncsIX3MSYNDFExqB14QwicJb+yqeX
	XW3vgrD6rk1bNmL8mImaBQ2m4FAFLD318IYPLDX7ekMhw5vcItUNhpcjskauzAzs
	ffAjjbzGtChFGUMn60QkzjQNE+TcBwwhKRMvqN/fo29TqYBdPzGL7KFX+P+Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-transfer-encoding:content-type
	:date:date:feedback-id:feedback-id:from:from:in-reply-to
	:message-id:mime-version:reply-to:sender:subject:subject:to:to
	:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
	fm1; t=1670298595; x=1670384995; bh=v+irAIJp69kcxU2a5tVUlSkvo+gh
	9m5QbWkX9HDQYNU=; b=lcH4lGhFgGh6cBpXswThTVgHgBsEK/HbuT93q/Ba6Zm1
	N+QBJPaI2v9hj59Y+ROxr2t81k/vL6PbcEMQAl0NWJVv//8zrMc0vItejpvDLHUz
	Ih8UAwLxkn3+maPhK7SEY+rE7r6Kta+/2eZtXG3kY0lMD+XtsrxQr+D1LPPncxuI
	O0GaxtNk/aQ2xDZ59bmu6ucFfCL9lkiDLXkl09a7qbSDaaQCe99/6DD1SPlQqqoO
	aDcjYD6O+vdUXVlU9MTWqmApUWLZIIxEY3Mqg2H/wyrPJRYyri98bD4RdBOs7LEk
	Rs43YSIZBbags5wo/8BmnwEjGlscgzOXpCGx4o4tVw==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudehgdeihecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffoffkgggtgfesthhqmhdtre
    dtjeenucfhrhhomhepfdfrrghtucforgguughogidfuceophgrthesphgrthhmrgguugho
    gidrtghomheqnecuggftrfgrthhtvghrnhepffffueetvdfhfeeufeekteefvdeuffejie
    etudehfedvieefvdeftdevheeviefgnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhg
    necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgrth
    esphgrthhmrgguughogidrtghomh
X-ME-Proxy: 
    
    
    
Feedback-ID: i8b6c40f9:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 ; Mon, 5 Dec 2022 22:49:54 -0500 (EST)
From: "Pat Maddox" 
To: freebsd-current@freebsd.org
Subject: kldload i915kms screen goes black
Date: Mon, 05 Dec 2022 19:49:53 -0800
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.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"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spamd-Result: default: False [-4.60 / 15.00];
	DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_DKIM_ALLOW(-0.20)[patmaddox.com:s=fm3,messagingengine.com:s=fm1];
	R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEFALL_USER(0.00)[pat];
	DMARC_NA(0.00)[patmaddox.com];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	DKIM_TRACE(0.00)[patmaddox.com:+,messagingengine.com:+];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_COUNT_THREE(0.00)[4];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[]
X-Rspamd-Queue-Id: 4NR5yq66p8z3Hfx
X-Spamd-Bar: ----
X-ThisMailContainsUnwantedMimeParts: N

I have a newly-built system with an ASUS Prime Z590M-Plus and Intel =

10900k with onboard graphics (UHD 630, according to intel).

I specifically chose a 10th gen processor because I believed it was =

well-supported by 13.1+. Unfortunately I can=E2=80=99t even install 13.1 =

(https://forums.freebsd.org/threads/cant-install-i-just-get-a-little-whit=
e-box-and-a-mouse-cursor.87334/)

I have successfully installed =

FreeBSD-14.0-CURRENT-amd64-20221201-d1f3abc89250-259495.

When I run `kldload i915kms`, the screen just goes black.

I have never used graphics before on FreeBSD, so I=E2=80=99m not sure whe=
re to =

begin diagnosing. I did as much research as I could upfront, but have =

run into this obstacle.

I=E2=80=99ll be content to run 14.0-CURRENT because I can still create 13=
=2E1 =

jails.

Does anyone have suggestions for successfully loading the graphics =

driver?

Pat


From nobody Tue Dec  6 04:55:53 2022
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 4NR7R45s8Cz4jlZH
	for ; Tue,  6 Dec 2022 04:56:00 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20])
	(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 4NR7R40XCNz3QJ6
	for ; Tue,  6 Dec 2022 04:55:59 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from pps.filterd (m0170389.ppops.net [127.0.0.1])
	by mx0a-00154904.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2B5Nu5L5030274;
	Mon, 5 Dec 2022 23:55:58 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject :
 date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=smtpout1;
 bh=Pi2Qy6JomarYRWRUa+PHTxue8K+8u4+uerqn3utAVWk=;
 b=XwX4ApxPJwTz6xCk9OTgRfapioXHQ+nZurTrC9LC6JtdCQMMycjzToXQPSKhEkwc8Hsd
 Tm0ChCg2zq2aQZYMrPWxBPfokHeFQaDltGfJ2By4zty2aegmOUUD/i4V4NNQFArqTOf3
 zclQ3jJNnKjMbR/mav+KrPFpeGIOo61rrOPrRj0BcMpKMbgf3e6y5A45qTN5k86hMjiL
 A5bURFz8aIfGBBi7V8mmyldcE2cUEfq1BmubbAtLlxcX1OkeyEyqc4ePDWlvrsFnCw/W
 H22Ihwg9M2glaITaoCBYuCaNYFxYCrtVG4CLbL5kR4IyF8FHbdzKkJbEli4NY0N1OYd8 LQ== 
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37])
	by mx0a-00154904.pphosted.com (PPS) with ESMTPS id 3m83br0cph-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
	Mon, 05 Dec 2022 23:55:58 -0500
Received: from pps.filterd (m0144104.ppops.net [127.0.0.1])
	by mx0b-00154901.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2B64kkog001697;
	Mon, 5 Dec 2022 23:55:57 -0500
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2106.outbound.protection.outlook.com [104.47.70.106])
	by mx0b-00154901.pphosted.com (PPS) with ESMTPS id 3m9y048711-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
	Mon, 05 Dec 2022 23:55:57 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=QL2nrDRvs1INaJ3/lRyjHIvLsThkqzebvU7trwvxUYw0An9FVMoIiBHNzUuccxfyOlxykbLRNqO+VMPVMxEIVl9QwdNRt65o4GKkBCuiSPDb5vCvvFOa3ivmO1cAcuFtGoBzVVgMbZJVgkn97cEm+PgIjQokF/A2efBZ8Th9rJz/EVYZrDoIXQMkBF6rV4fD/dXeuey3UyCIjDPIufuF3zZpMPaMujJtSgheTJgz4bwZlt+k1djfuObJxv/wauTrR93czkxxVKhrG+hosBw4m3uyj+wJJt50X7TyPZbom/endkAKg3S7BFE2mDPiJ5H5YMnttO/kv0x9jSh891doTQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Pi2Qy6JomarYRWRUa+PHTxue8K+8u4+uerqn3utAVWk=;
 b=gTK8nG15NSJtFS6eUnooCjUma8nHUyZISFfA9Sw9S0f0IAucOuiwq89NAWR6PKQxbhs2KvQE3fjwE8HCcglT/O7IrItl9LDTm7lzfzwh01Fvh5I4LX58uhZqUKi/QEPdU+2UrG8mBC7TQDjuUFWTvzTlb49W2jTm0WeHYCDy4Bb/lltMVS9d6zxWj2pAYObkBksu3tyDXvsFPJEV+InaZMZVADDaVTeMGblOO0O24y+r5FoPKFZs7/aUMTsYo2Zcs87nb0KPKqGksUA8g+sMW1hb9c7Znz1Sd0FrGw4u1GHUToTvDZnC4lwLqewvT2nSoAnGEKPw0usqczI8kFWY+w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com;
 dkim=pass header.d=dell.com; arc=none
Received: from PH0PR19MB4938.namprd19.prod.outlook.com (2603:10b6:510:94::9)
 by DM4PR19MB5809.namprd19.prod.outlook.com (2603:10b6:8:64::14) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.14; Tue, 6 Dec
 2022 04:55:53 +0000
Received: from PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::23b9:ea81:a0a1:365d]) by PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::23b9:ea81:a0a1:365d%4]) with mapi id 15.20.5880.014; Tue, 6 Dec 2022
 04:55:53 +0000
From: "Chen, Alvin W" 
To: Pat Maddox ,
        "freebsd-current@freebsd.org"
	
Subject: RE: kldload i915kms screen goes black
Thread-Topic: kldload i915kms screen goes black
Thread-Index: AQHZCSXbGN1rBtGamU22o9u7g69P0a5gSv8w
Date: Tue, 6 Dec 2022 04:55:53 +0000
Message-ID: 
 
References: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.com>
In-Reply-To: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Enabled=true;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SetDate=2022-12-06T04:55:50Z;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Method=Standard;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Name=No Protection (Label
 Only) - Internal Use;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ActionId=1d3b5e79-a067-4f24-8595-c0a8f73ca1f6;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ContentBits=2
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR19MB4938:EE_|DM4PR19MB5809:EE_
x-ms-office365-filtering-correlation-id: 8336f669-b52a-4b33-1021-08dad7462734
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 QS4Zu7FwOpfkmHOk9LNlT/l7CfZiiRhLIBVcDxHRvEHfNzJozdomHFDhuUvQFspwnH9dri6mpDv4MzBLvS78BgI6Ar1NFXDJKEojJ59niEKGTTdBIYnRWUfVMWdvrTCIKxxRHYdfxdzHdbgE7vdQo31DyR4xHKn9ZReSbLx/GREcyqei29nF76b3VfHJlWkqKFK/jFPTdXHrUTHWjo8kOHOuDUycn68/rq/KEw+g5PDFdcbw2QQoGYETufjz+kxt6EaOgbL6jonZ10mjkywDgcC7f2JVaBHcGw7n9mLSFmBfXqsq4gP+H+OrKsMyyD1vPWIAQc44zp1kFkYkn52lnp4eunNoXFAfNStUatB6xNZGFPFYdqVu1XH6sp8qmalCqvSNNOYIGuTR+j5vv10MXsMJmTti85Ph1wX7bsZkx9yqD6CLlkBw6Ep2WfhJnd6CWwXIv7XQOsxoUMHXJhYwMDUPVhS3uxuThs4O6HAyxqOyN7pkVz9UqLUvNdDhJ3H6h17CJEDLsEpWq80cDGdhisHkgBoCTCEHBPwTVTBFG/NvrzCr3zdbiuH/nrnylJwvKHJg07iIy/2OE3/EjNlLWeY2jqiTPI0DZNb6PSrHOihVzfWYKBOKinfec+PVkVrG2Gplx94jC0VpxNSMNH3b1QpoRJ+uGFCpeFmWzITybitUd0HPhbutmOxRAT7LXmI6NS2DRxIurbOuElEp7CSjz8GKNCiFUa12ATo3nEL0Z3YyLrE0RzKMLW4/CvrpKVTCx1WtFaApzEt1HvIrH7gsaw==
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR19MB4938.namprd19.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(366004)(136003)(346002)(39860400002)(396003)(376002)(451199015)(5660300002)(82960400001)(86362001)(8936002)(2906002)(41300700001)(38070700005)(122000001)(33656002)(966005)(66446008)(76116006)(786003)(66476007)(66556008)(316002)(110136005)(66946007)(71200400001)(38100700002)(55016003)(8676002)(52536014)(186003)(6506007)(26005)(9686003)(478600001)(64756008)(7696005);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?utf-8?B?MkY0SjY5WlYwNXFCWjZZVi9IRVZJdDQxRjQrMVdXYkVvL1lHdFlUSGdsYnhu?=
 =?utf-8?B?TWJYVTZTS0k4QmlSNHQ2SjM0dmJKZ000NndQMVhFK2dXNmtRRUhJaENjTlVE?=
 =?utf-8?B?ZlVaUDU4SGl0Y2FMc0swNXhxdUxucWpnOGhFdUUvblAzM0ZEOUdXTXdoeml1?=
 =?utf-8?B?WlowVnRZTEdmR3puc0NXZTBnbFBRL3BQRDZ2UFpaQTlwdnh6aEhhZzZ2WGdy?=
 =?utf-8?B?Zkg4T0hUaEVNUHF2eExLeW5XbklJMVJaaXhQb2taOEZ6bHdnOU9sOG5pNUdC?=
 =?utf-8?B?Q1gvVEIybUxyaERVOUU2b05KOG1VWHZKa1U4RUtsV1dsc3R4VGp0dmxsZFpZ?=
 =?utf-8?B?Rng3ZWQ2NzBnanpmaGJRb2t4MGFGMVRpcjk5VXRkWmsvc2NyN2c1cjdDUG9u?=
 =?utf-8?B?REJmdmY1dkJmVHdZeExRNWp6L1BoMVJ1WHJRb25JYVlzb000VzgvcDVIVTBx?=
 =?utf-8?B?Z1psZU84WUtGVzhLR05uRTB6WlVRMHJiTVYvbnI0ME1ZUDAvZkVlWkErSzFE?=
 =?utf-8?B?NDJacGVGeDNQWlNDQ01RcEgzWXlRa3BuMnh5WmlWTWdiY0dGR1ZhWjNGQ2do?=
 =?utf-8?B?RGVXaFk4YTZjUFY0S3NlNzdXK1hOOGdZNkx4VUVRV2dNM0E0bm9pNEZqZ3d0?=
 =?utf-8?B?ZUdYbkUrU1hMUk5tZnNuWmtKaEJhaFFxQ0laNml4RWNXNElnVHloWXNUWk9G?=
 =?utf-8?B?N3M5VWJKQjVDSGtGNDJ6RjRVK3FEQ0k1YXRGdUR1Y1RjcmJPbzdYWERzVExh?=
 =?utf-8?B?NDVMTFJtMTdmS1kzUFNFeUdWNUtsQ0I4UGhwZmRLYUVmamFUNFlzNk9NRUdB?=
 =?utf-8?B?RUx3V0tlelpMbjNHU1d1cDlHbldaZWZEc0FNcWVNeWlNKzVLbm41ZVNGVXRt?=
 =?utf-8?B?cW5rZlpSQkQ5UllmK0hkdE13WXBpS3F4WUxFUThuZ1JjV01WSkNSSS9sUjMr?=
 =?utf-8?B?UHAyQVhiMzBZV1FVWTV4VDBPenY2cnoyR21UamJnZEVtQkRib2JuQ3o4VjFY?=
 =?utf-8?B?ZEVubDVpRjl6dW0yS25rNG5lRnJhZFpSVzZ0cXJxYk9pWG5YQjI4NngrcGx4?=
 =?utf-8?B?RjQ0ck9LWEZFVkxxbTU4dE9pRHBqUVRjQ3F2TzBHRjBndlZteXRwNmx0bG5J?=
 =?utf-8?B?azJwcGppMFFIdmJPOUZPNU9lS0ZMMFE4NG8ydXp4RmtXcis4SWQ5bVFUYzNv?=
 =?utf-8?B?SDJ3M1pucnhlZkNqWDRQS3RkZGhWb0c4WUFKK3lkcFAzNGlIRUtRY0JFT2la?=
 =?utf-8?B?MTdVdnNOWWFpNTltNXgxalZtUVlLNHdPOG0yZStoL3gveTdFOVFNbk9sckpm?=
 =?utf-8?B?SWppUS9IaDVHakZjSkFBR3dwakFDbFc0aXErc1dqV0ZnZWZIZ3BHN01Pb0RD?=
 =?utf-8?B?dFphMEtWd3Nsc0R2SHNDOEdTdkxvRzVVOTRZMDRhNmFENENpenkwNTFySGVw?=
 =?utf-8?B?R1B3NFpnMUM1NkFNS2dOUVVKYnVjQTRBWXY4MnJIM01VeVU0bno5QVRFWnk3?=
 =?utf-8?B?Mm5tbHBabllCWENyd3U5bExCK2RmMmtzT2lzakZDck9WUmZZbFNiQm9QNjJS?=
 =?utf-8?B?VVk1ckV2MXljY3NLaXp2N0dZTTVnVW9YRTduOHUxVkg2TlhET0t4ZEZSTy9O?=
 =?utf-8?B?VXZBUFhuenBtazdiSHBLdGpHRkdzblo0STNsWUt4SnJrOFlSU2V0SnRnU2My?=
 =?utf-8?B?WXNUeE54VXlZYkR0ang3eGJpdGVoMW5RRkRRWDVTYU9MamJsM2c0a05PdXA3?=
 =?utf-8?B?MnN4SzBLY2JkMnlBUmNZd3k3aGtjQ3d5clg1am16OEpCeWhKVUwyeU5icXVn?=
 =?utf-8?B?N0lWV2IwbzlPMEppZWlQamFob21BSW9vR0kyMGV3YjlGWXgva0dxa0Q0eW1u?=
 =?utf-8?B?Rzg4RGdGejdFbkNnQXAreGZyRkZFMGhweFhlRklzSzNzS0RCQm5OYXJrdDF6?=
 =?utf-8?B?eXZCTGh6NytxOGU5T3RETWt5N1Z6MXJLaEQrQnZ0VHFVS0VjMnRxeGErUkRq?=
 =?utf-8?B?UW1DR01VanFybDNyakZaQzN1Uk92Z3drdU5UeWZoaXppWGpYOHZucGRrY1po?=
 =?utf-8?B?TjR5Sm9WZm5NV2Z3SkRleUFwcmZQVEVNS1dXZVVmZllDRjFTLzFvN2FzQUU5?=
 =?utf-8?Q?ZwfAhQjXyIxc4YyW/T52fBaOg?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR19MB4938.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8336f669-b52a-4b33-1021-08dad7462734
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2022 04:55:53.1283
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /lApODA/ct+FWIBACP2O3leE/zfmm6yF3kJSF17JCyktPaty8jmj4HfLfZcRAnCPsMdY2Tu67E5IG63UIDwt+g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR19MB5809
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-12-06_03,2022-12-05_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0
 lowpriorityscore=0 suspectscore=0 bulkscore=0 adultscore=0 mlxlogscore=883
 priorityscore=1501 clxscore=1011 malwarescore=0 spamscore=0
 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2212060038
X-Proofpoint-ORIG-GUID: ikUtZ074XAAXfBuQ8MVfReX6b1aYhV2N
X-Proofpoint-GUID: ikUtZ074XAAXfBuQ8MVfReX6b1aYhV2N
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 spamscore=0
 malwarescore=0 suspectscore=0 mlxlogscore=977 adultscore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000
 definitions=main-2212060038
X-Rspamd-Queue-Id: 4NR7R40XCNz3QJ6
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:26211, ipnet:148.163.133.0/24, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

PiANCj4gSSBoYXZlIGEgbmV3bHktYnVpbHQgc3lzdGVtIHdpdGggYW4gQVNVUyBQcmltZSBaNTkw
TS1QbHVzIGFuZCBJbnRlbCAxMDkwMGsNCj4gd2l0aCBvbmJvYXJkIGdyYXBoaWNzIChVSEQgNjMw
LCBhY2NvcmRpbmcgdG8gaW50ZWwpLg0KPiANCj4gSSBzcGVjaWZpY2FsbHkgY2hvc2UgYSAxMHRo
IGdlbiBwcm9jZXNzb3IgYmVjYXVzZSBJIGJlbGlldmVkIGl0IHdhcyB3ZWxsLQ0KPiBzdXBwb3J0
ZWQgYnkgMTMuMSsuIFVuZm9ydHVuYXRlbHkgSSBjYW7igJl0IGV2ZW4gaW5zdGFsbCAxMy4xDQo+
IChodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9mb3J1bXMuZnJlZWJzZC5vcmcv
dGhyZWFkcy9jYW50LQ0KPiBpbnN0YWxsLWktanVzdC1nZXQtYS1saXR0bGUtd2hpdGUtYm94LWFu
ZC1hLW1vdXNlLQ0KPiBjdXJzb3IuODczMzQvX187ISFMcEtJIWlSUk1DM2VmOWhiUzFOS1hUQlVv
SUR4bFZ6OXBVX20xSm9jbnpoMlRseGZkDQo+IHM1U25rYkhIWEVNNGlLcVU3d2V1RWlPYlY4cmZK
WGZZJCBbZm9ydW1zWy5dZnJlZWJzZFsuXW9yZ10pDQo+IA0KPiBJIGhhdmUgc3VjY2Vzc2Z1bGx5
IGluc3RhbGxlZA0KPiBGcmVlQlNELTE0LjAtQ1VSUkVOVC1hbWQ2NC0yMDIyMTIwMS1kMWYzYWJj
ODkyNTAtMjU5NDk1Lg0KPiANCj4gV2hlbiBJIHJ1biBga2xkbG9hZCBpOTE1a21zYCwgdGhlIHNj
cmVlbiBqdXN0IGdvZXMgYmxhY2suDQo+IA0KPiBJIGhhdmUgbmV2ZXIgdXNlZCBncmFwaGljcyBi
ZWZvcmUgb24gRnJlZUJTRCwgc28gSeKAmW0gbm90IHN1cmUgd2hlcmUgdG8NCj4gYmVnaW4gZGlh
Z25vc2luZy4gSSBkaWQgYXMgbXVjaCByZXNlYXJjaCBhcyBJIGNvdWxkIHVwZnJvbnQsIGJ1dCBo
YXZlIHJ1biBpbnRvDQo+IHRoaXMgb2JzdGFjbGUuDQo+IA0KPiBJ4oCZbGwgYmUgY29udGVudCB0
byBydW4gMTQuMC1DVVJSRU5UIGJlY2F1c2UgSSBjYW4gc3RpbGwgY3JlYXRlIDEzLjEgamFpbHMu
DQo+IA0KPiBEb2VzIGFueW9uZSBoYXZlIHN1Z2dlc3Rpb25zIGZvciBzdWNjZXNzZnVsbHkgbG9h
ZGluZyB0aGUgZ3JhcGhpY3MgZHJpdmVyPw0KPiANCj4gUGF0DQo+IA0KDQpZb3UgY2FuIGdldCB0
aGUgZHJtIDUuMTAgY29kZSBmb3IgRnJlZWJzZCBoZXJlOiBodHRwczovL2dpdGh1Yi5jb20vZnJl
ZWJzZC9kcm0ta21vZC4NCkl0IHNob3VsZCBzdXBwb3J0IEludGVsIEdQVSBvbGRlciB0aGFuIEFE
TC4NCllvdSBtYXkgbmVlZCBidWlsZCBpdCBieSB5b3Vyc2VsZi4NCg0KDQpJbnRlcm5hbCBVc2Ug
LSBDb25maWRlbnRpYWwNCg==

From nobody Tue Dec  6 05:43:17 2022
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 4NR8Th74Xjz4js0w
	for ; Tue,  6 Dec 2022 05:43:20 +0000 (UTC)
	(envelope-from pat@patmaddox.com)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.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 did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NR8Th4BLsz3kFV
	for ; Tue,  6 Dec 2022 05:43:20 +0000 (UTC)
	(envelope-from pat@patmaddox.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
	by mailout.nyi.internal (Postfix) with ESMTP id 12A595C02C0;
	Tue,  6 Dec 2022 00:43:20 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
  by compute4.internal (MEProxy); Tue, 06 Dec 2022 00:43:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=patmaddox.com;
	 h=cc:cc:content-transfer-encoding:content-type:date:date:from
	:from:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:sender:subject:subject:to:to; s=fm3; t=1670305400; x=
	1670391800; bh=Z1IjZNWM2ezZUm5ZzMjUhBahJGevyTzEv2G1t09Fe6s=; b=V
	t44LPflg0aY1MyRjWdW71J+HvXfjxYOB/FnIyiWWU2ieSIjM8RuEl6oipOF+CFb/
	CGSNajvxo0ubBGAnjw1nOjEbHjq2GV+/6VB3TTNlEO/H7hmptwqne8khMYf+WsTv
	3G65K9M0b5+zT/UXVjS6dpw85vp6Mv0GolIA5wQV/6eFLX6DhBFngLmJqDV0wUtP
	OPkW26NrjgvzAKWpZwJJZ8F6TNQh6WOUDohpR98Qr961bh+Q/tamazUdHHzngvZr
	EUci/ruQ3Di3ksrSkXfZ98xfbrN5SWCNzX5yJsJrc0/7YYNs3yQv+UUkCSOUuyGi
	3XAtTLm2Sv10/FLsT28Lw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:cc:content-transfer-encoding
	:content-type:date:date:feedback-id:feedback-id:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1670305400; x=
	1670391800; bh=Z1IjZNWM2ezZUm5ZzMjUhBahJGevyTzEv2G1t09Fe6s=; b=P
	kVS1yqqkEtxpEl7rUuEzXoL4i3BCZg69ilWwNAGEfjaet+oJghv2fVpRK5RM8QZB
	4+/S6aA4tPb9gS9FuDV/2sDxyNQl5mHSovOAnvIq/DuZCuGGv3+tuCFitySJGeTk
	MRQtuAowioLx42cni75MzNX8thpBNY0xXhxZTHltXybX30qWc0hg7SRASDy9LBcv
	KYWAlJLr/X+rARvwzn3Juf0iVQECFcjQztUEJNjSM6+5b5kEVGOAanYO8dseq1YR
	u737bHFrZRlQMCc/zfB0nYsuKyKGb8eLYwCicX6Vr18vj2W5VUiSdTzGvROL/ta0
	DqL3dTJritW3q9v5uyd/w==
X-ME-Sender: 
    
X-ME-Received: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudehgdekkecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecunecujfgurhephffvvefufffokfgjfhggtgfgsehtke
    hmtdertdejnecuhfhrohhmpedfrfgrthcuofgrugguohigfdcuoehprghtsehprghtmhgr
    ugguohigrdgtohhmqeenucggtffrrghtthgvrhhnpefhjefgtdejvddtkeekleelgeeuhf
    eltdeftedtfeeuffevvdekgffghfelfffhheenucffohhmrghinhepuhhrlhguvghfvghn
    shgvrdgtohhmpdhfrhgvvggsshgurdhorhhgpdhgihhthhhusgdrtghomhenucevlhhush
    htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehprghtsehprghtmhgr
    ugguohigrdgtohhm
X-ME-Proxy: 
    
    
    
Feedback-ID: i8b6c40f9:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 6 Dec 2022 00:43:19 -0500 (EST)
From: "Pat Maddox" 
To: "Chen, Alvin W" 
Cc: freebsd-current@freebsd.org
Subject: Re: kldload i915kms screen goes black
Date: Mon, 05 Dec 2022 21:43:17 -0800
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com>
In-Reply-To: 
References: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.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"; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4NR8Th4BLsz3kFV
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On 5 Dec 2022, at 20:55, Chen, Alvin W wrote:

>>
>> I have a newly-built system with an ASUS Prime Z590M-Plus and Intel 
>> 10900k
>> with onboard graphics (UHD 630, according to intel).
>>
>> I specifically chose a 10th gen processor because I believed it was 
>> well-
>> supported by 13.1+. Unfortunately I can’t even install 13.1
>> (https://urldefense.com/v3/__https://forums.freebsd.org/threads/cant-
>> install-i-just-get-a-little-white-box-and-a-mouse-
>> cursor.87334/__;!!LpKI!iRRMC3ef9hbS1NKXTBUoIDxlVz9pU_m1Jocnzh2Tlxfd
>> s5SnkbHHXEM4iKqU7weuEiObV8rfJXfY$ [forums[.]freebsd[.]org])
>>
>> I have successfully installed
>> FreeBSD-14.0-CURRENT-amd64-20221201-d1f3abc89250-259495.
>>
>> When I run `kldload i915kms`, the screen just goes black.
>>
>> I have never used graphics before on FreeBSD, so I’m not sure where 
>> to
>> begin diagnosing. I did as much research as I could upfront, but have 
>> run into
>> this obstacle.
>>
>> I’ll be content to run 14.0-CURRENT because I can still create 13.1 
>> jails.
>>
>> Does anyone have suggestions for successfully loading the graphics 
>> driver?
>>
>> Pat
>>
>
> You can get the drm 5.10 code for Freebsd here: 
> https://github.com/freebsd/drm-kmod.
> It should support Intel GPU older than ADL.
> You may need build it by yourself.

I believe I have that, otherwise `kldload i915kms` would return 
“kldload: can’t load i915kms: No such file or directory.â€

I have tried installing drivers with:

pkg install drm-kmod
pkg install drm-510-kmod
cd /usr/ports/graphics/drm-510-kmod && make install
cd /usr/ports/graphics/drm-510-kmod && make GH_TAGNAME=drm_v5.11_0 
install

My understanding is that 13.1 supports 10th gen graphics well, so I 
wouldn’t expect to need to use the absolute latest version from GitHub 
(drm_v5.11_0 in this case).

Pat

From nobody Tue Dec  6 12:21:04 2022
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 4NRKK71mLvz4jX9P
	for ; Tue,  6 Dec 2022 12:21:31 +0000 (UTC)
	(envelope-from pbowen@fastmail.fm)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25])
	(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 4NRKK610zBz3QFt
	for ; Tue,  6 Dec 2022 12:21:30 +0000 (UTC)
	(envelope-from pbowen@fastmail.fm)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=fastmail.fm header.s=fm2 header.b="s 8OaEtV";
	dkim=pass header.d=messagingengine.com header.s=fm1 header.b=iJgY7XDa;
	spf=pass (mx1.freebsd.org: domain of pbowen@fastmail.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=pbowen@fastmail.fm;
	dmarc=pass (policy=none) header.from=fastmail.fm
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
	by mailout.west.internal (Postfix) with ESMTP id E50AF32003F4
	for ; Tue,  6 Dec 2022 07:21:27 -0500 (EST)
Received: from imap49 ([10.202.2.99])
  by compute6.internal (MEProxy); Tue, 06 Dec 2022 07:21:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h=
	cc:content-transfer-encoding:content-type:date:date:from:from
	:in-reply-to:in-reply-to:message-id:mime-version:references
	:reply-to:sender:subject:subject:to:to; s=fm2; t=1670329287; x=
	1670415687; bh=pB5t/czO47G7jTj9HEb0g9weQ9NET9c0c1qt41xFsxc=; b=s
	8OaEtVNcMgyL7mG4YQuuhyfWwUXRrgrIS8d0NATFky/EiUmJvf6h0HQ1maGyQQbB
	2P2iG25l1P0FlavKN6NgG+Vj7f5DgpW0gM1lrQ6ucIWvEHIm/q0XI2Qia+NyIqBr
	0djJgVR5L1wqULJfARCkcj5c1glNhT++Dc1RuS44cp2OGD/36zHPtyKvBlbij8BW
	xNBunCpEfRgajYhl8wC8Ejzx2nzd1JIFJdq7mSdOSG/JK+92oYrXlrpNuRlHvQPH
	P0Oyq31vgzwuns0SribBfCJy15CgOMX6NiBsv8s2/RaOTE1ne0FOBaM7fToj0oWB
	8bQmIFhOIQqRfR0tbftGA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-transfer-encoding:content-type
	:date:date:feedback-id:feedback-id:from:from:in-reply-to
	:in-reply-to:message-id:mime-version:references:reply-to:sender
	:subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm1; t=1670329287; x=1670415687; bh=p
	B5t/czO47G7jTj9HEb0g9weQ9NET9c0c1qt41xFsxc=; b=iJgY7XDa+a/NDYPyi
	eE4hNW2MYKv0vsyIWES3KNP+lg8QW7t53w5WgPZpbXX3o2cpqi8j3HZJ96F1dz++
	lZtKL7WY1hyY2fbXzL2GIkBe9XtlzIBbv7EolpaIsN+HfP68/7iv+XLobNN7xiyh
	R/bdfguB22QTLWCbS2IWD3AqBz4dIqi7czyYV1ew/w7yhE3936dZJvbMkwi+mdNU
	wXsSs4V5rpUHkb8LhHKN0OgXVNJIV3VvpaBPhWH27m5yM/MRMc+5qpJjZouNehPa
	S+vVRJ+k+x3krtu89S8l/iimb/6UdAxXXCx5SRJ+hbeyaCP7qC/g5PEeNiNYZwyi
	iAaKQ==
X-ME-Sender: 
    
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeigdefkecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh
    ertderreejnecuhfhrohhmpedfrfgrthhrihgtkhcuuehofigvnhdfuceophgsohifvghn
    sehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeefvdfhveejffdvheekhf
    fftdevtefhfefgteelueevveehuefhhfettdejfedvkeenucffohhmrghinhepuhhrlhgu
    vghfvghnshgvrdgtohhmpdhfrhgvvggsshgurdhorhhgpdhgihhthhhusgdrtghomhenuc
    evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpsghofigv
    nhesfhgrshhtmhgrihhlrdhfmh
X-ME-Proxy: 
    
    
    
Feedback-ID: i8ecd41a5:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501)
	id 4B54D15A0087; Tue,  6 Dec 2022 07:21:27 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
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
Message-Id: <863bdf03-52bc-455d-a2c4-d920defa7d37@app.fastmail.com>
In-Reply-To: <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com>
References: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.com>
 
 <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com>
Date: Tue, 06 Dec 2022 06:21:04 -0600
From: "Patrick Bowen" 
To: freebsd-current@freebsd.org
Subject: Re: kldload i915kms screen goes black
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spamd-Result: default: False [-5.50 / 15.00];
	DWL_DNSWL_LOW(-2.00)[messagingengine.com:dkim,fastmail.fm:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.91)[-0.911];
	DMARC_POLICY_ALLOW(-0.50)[fastmail.fm,none];
	MV_CASE(0.50)[];
	R_DKIM_ALLOW(-0.20)[fastmail.fm:s=fm2,messagingengine.com:s=fm1];
	R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from];
	XM_UA_NO_VERSION(0.01)[];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US];
	RCVD_COUNT_THREE(0.00)[4];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[fastmail.fm];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[fastmail.fm:+,messagingengine.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[fastmail.fm];
	RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from]
X-Rspamd-Queue-Id: 4NRKK610zBz3QFt
X-Spamd-Bar: -----
X-ThisMailContainsUnwantedMimeParts: N


On Mon, Dec 5, 2022, at 11:43 PM, Pat Maddox wrote:
> On 5 Dec 2022, at 20:55, Chen, Alvin W wrote:
>
>>>
>>> I have a newly-built system with an ASUS Prime Z590M-Plus and Intel=20
>>> 10900k
>>> with onboard graphics (UHD 630, according to intel).
>>>
>>> I specifically chose a 10th gen processor because I believed it was=20
>>> well-
>>> supported by 13.1+. Unfortunately I can=E2=80=99t even install 13.1
>>> (https://urldefense.com/v3/__https://forums.freebsd.org/threads/cant-
>>> install-i-just-get-a-little-white-box-and-a-mouse-
>>> cursor.87334/__;!!LpKI!iRRMC3ef9hbS1NKXTBUoIDxlVz9pU_m1Jocnzh2Tlxfd
>>> s5SnkbHHXEM4iKqU7weuEiObV8rfJXfY$ [forums[.]freebsd[.]org])
>>>
>>> I have successfully installed
>>> FreeBSD-14.0-CURRENT-amd64-20221201-d1f3abc89250-259495.
>>>
>>> When I run `kldload i915kms`, the screen just goes black.
>>>
>>> I have never used graphics before on FreeBSD, so I=E2=80=99m not sur=
e where=20
>>> to
>>> begin diagnosing. I did as much research as I could upfront, but hav=
e=20
>>> run into
>>> this obstacle.
>>>
>>> I=E2=80=99ll be content to run 14.0-CURRENT because I can still crea=
te 13.1=20
>>> jails.
>>>
>>> Does anyone have suggestions for successfully loading the graphics=20
>>> driver?
>>>
>>> Pat
>>>
>>
>> You can get the drm 5.10 code for Freebsd here:=20
>> https://github.com/freebsd/drm-kmod.
>> It should support Intel GPU older than ADL.
>> You may need build it by yourself.
>
> I believe I have that, otherwise `kldload i915kms` would return=20
> =E2=80=9Ckldload: can=E2=80=99t load i915kms: No such file or director=
y.=E2=80=9D
>
> I have tried installing drivers with:
>
> pkg install drm-kmod
> pkg install drm-510-kmod
> cd /usr/ports/graphics/drm-510-kmod && make install
> cd /usr/ports/graphics/drm-510-kmod && make GH_TAGNAME=3Ddrm_v5.11_0=20
> install
>
> My understanding is that 13.1 supports 10th gen graphics well, so I=20
> wouldn=E2=80=99t expect to need to use the absolute latest version fro=
m GitHub=20
> (drm_v5.11_0 in this case).
>
> Pat

I had a similar problem. Got it fixed by uninstalling drm-kmod and then =
installing drm-510-kmod and adding "kld_list=3D"i915kms"" to /etc/rc.con=
f.

On an old installation I think I had to build it from ports. On a fresh =
install you can ignore drm-kmod and just "pkg install drm-510-kmod".

Good luck!
Patrick

From nobody Thu Dec  8 00:09:32 2022
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 4NSDzq2fsFz4kD05
	for ; Thu,  8 Dec 2022 00:09:43 +0000 (UTC)
	(envelope-from dan@sunsaturn.com)
Received: from sunsaturn.com (sunsaturn.com [IPv6:2604:4300:a:196::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 (2048 bits) client-digest SHA256)
	(Client CN "sunsaturn.com", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NSDzn62MTz4CgS
	for ; Thu,  8 Dec 2022 00:09:41 +0000 (UTC)
	(envelope-from dan@sunsaturn.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=sunsaturn.com header.s=default header.b=tS+XPAxq;
	spf=pass (mx1.freebsd.org: domain of dan@sunsaturn.com designates 2604:4300:a:196::3 as permitted sender) smtp.mailfrom=dan@sunsaturn.com;
	dmarc=none
Received: by sunsaturn.com (Postfix, from userid 1001)
	id 620B0710C6; Wed,  7 Dec 2022 18:09:32 -0600 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunsaturn.com;
	s=default; t=1670458172;
	bh=jGEIgWYAj5uuIZCKp1cLzhyw7Rs7ZlvSgqcYIOoX/QQ=;
	h=Date:From:To:cc:Subject;
	b=tS+XPAxqE5+ml85jzgx0JNrB1SOjE8+L8dNpM6f/8ZQHIksEk5O4KLs0C/lZUOqSd
	 718MreMUETFO162vWpium3BO4T8ikqsg7AtOnscOcqhnPSWffcATB0l86f5kWuJs++
	 lkYatSwBo9gkgx7VNW2Gm/lvcnL/OIv0+T8VZkvE=
Received: from localhost (localhost [127.0.0.1])
	by sunsaturn.com (Postfix) with ESMTP id 5FC23710C5;
	Wed,  7 Dec 2022 18:09:32 -0600 (CST)
Date: Wed, 7 Dec 2022 18:09:32 -0600 (CST)
From: Dan The Man 
To: freebsd-current@FreeBSD.org
cc: freebsd@intel.com
Subject: Outdated IX intel driver in /usr/src tree
Message-ID: <5a6c05e5-3e4f-0de5-8e5e-8d40ad66159c@sunsaturn.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; format=flowed; charset=US-ASCII
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	R_SPF_ALLOW(-0.20)[+ip6:2604:4300:a:196::3];
	R_DKIM_ALLOW(-0.20)[sunsaturn.com:s=default];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	FROM_EQ_ENVFROM(0.00)[];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[sunsaturn.com:+];
	RCVD_COUNT_THREE(0.00)[3];
	ASN(0.00)[asn:33387, ipnet:2604:4300::/32, country:US];
	FREEFALL_USER(0.00)[dan];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	DMARC_NA(0.00)[sunsaturn.com: no valid DMARC record];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NSDzn62MTz4CgS
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N


ix-3.3.32 is on intel website since back in July.
https://www.intel.com/content/www/us/en/download/14303/intel-network-adapters-driver-for-pcie-10-gigabit-network-connections-under-freebsd.html

/usr/src/sys/dev/ixgbe seems to be behind.

Currently having issues with Intel 520 DA card hitting 10 gigabit speeds, 
last night booted same machine with Rocky Linux 9 on USB stick, no problem 
hitting 10gigabit with iperf3. Tried booting even a 13 release FreeBSD 
same issues, so nothing related to CURRENT.

I've played with /boot/loader.conf and /etc/sysctl.conf tuning parameters 
to no avail, nothing seems to work, perhaps the updated driver may fix 
this? I notice there are new sysctl parameters under newest driver.

router:/usr/src/sys/modules # uname -a
FreeBSD router.sunsaturn.com 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n259557-4fa1e855be60: Sun Dec  4 22:28:09 CST 2022 
dan@router.sunsaturn.com:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64
router:/usr/src/sys/modules #

Standard Dell r720 server.


Dan.

From nobody Thu Dec  8 05:44:06 2022
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 4NSNPn65YBz4jl3L
	for ; Thu,  8 Dec 2022 05:44:13 +0000 (UTC)
	(envelope-from shuriku@shurik.kiev.ua)
Received: from mail.flex-it.com.ua (mail.flex-it.com.ua [193.239.74.7])
	(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 4NSNPm4S8kz3lWK
	for ; Thu,  8 Dec 2022 05:44:12 +0000 (UTC)
	(envelope-from shuriku@shurik.kiev.ua)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of shuriku@shurik.kiev.ua designates 193.239.74.7 as permitted sender) smtp.mailfrom=shuriku@shurik.kiev.ua;
	dmarc=none
Received: from 93.183.208.50.ipv4.datagroup.ua ([93.183.208.50] helo=[192.168.200.124])
	by mail.flex-it.com.ua with esmtpsa  (TLS1.3) tls TLS_AES_128_GCM_SHA256
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1p39hT-000374-KM
	for freebsd-current@freebsd.org;
	Thu, 08 Dec 2022 07:44:03 +0200
Message-ID: <1da06028-5eb2-fb57-6d44-59255160c317@shurik.kiev.ua>
Date: Thu, 8 Dec 2022 07:44:06 +0200
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: Outdated IX intel driver in /usr/src tree
Content-Language: uk-UA
To: freebsd-current@freebsd.org
References: <5a6c05e5-3e4f-0de5-8e5e-8d40ad66159c@sunsaturn.com>
From: Oleksandr Kryvulia 
In-Reply-To: <5a6c05e5-3e4f-0de5-8e5e-8d40ad66159c@sunsaturn.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-3.30 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:35297, ipnet:193.239.72.0/22, country:UA];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[shurik.kiev.ua];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NSNPm4S8kz3lWK
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

08.12.22 02:09, Dan The Man пише:
>
> ix-3.3.32 is on intel website since back in July.
> https://www.intel.com/content/www/us/en/download/14303/intel-network-adapters-driver-for-pcie-10-gigabit-network-connections-under-freebsd.html 
>
>
> /usr/src/sys/dev/ixgbe seems to be behind.
>
> Currently having issues with Intel 520 DA card hitting 10 gigabit 
> speeds, last night booted same machine with Rocky Linux 9 on USB 
> stick, no problem hitting 10gigabit with iperf3. Tried booting even a 
> 13 release FreeBSD same issues, so nothing related to CURRENT.
>
> I've played with /boot/loader.conf and /etc/sysctl.conf tuning 
> parameters to no avail, nothing seems to work, perhaps the updated 
> driver may fix this? I notice there are new sysctl parameters under 
> newest driver.
>
> router:/usr/src/sys/modules # uname -a
> FreeBSD router.sunsaturn.com 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
> main-n259557-4fa1e855be60: Sun Dec  4 22:28:09 CST 2022 
> dan@router.sunsaturn.com:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64
> router:/usr/src/sys/modules #
>
> Standard Dell r720 server.
>

Hi,
can you try net/intel-ix-kmod from ports?


From nobody Sat Dec 10 15:52:11 2022
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 4NTspQ0Tg7z4jWBW;
	Sat, 10 Dec 2022 15:52:14 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NTspP6qFwz4WqD;
	Sat, 10 Dec 2022 15:52:13 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1670687534;
	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=27m2qk8M4HO8FZvt0pveouOjWfjY0nboFeus9Plw5+Y=;
	b=N1D5Dl92HEygQzLeaRPVoGeRzweqFDu0Pd885DFmXUtlJJpjOXeakKMdBIk076gk+R3WIM
	hcyCvE281FpbO4L22uq7yTGmhsSoHaboCsj4I4nWtP7+wfy7RQND0zuDmuamsS4RsQ0C6l
	IcfLlP/0l8N6PXwcSBu5aVk9yaCse8JqfLDS2mmQZndN8EXmq5UgQ+IHNp3DcLIeMf9SKY
	L7sGj3wvs1pXwBZy3tLvyuf9pcJtqA/kvty8ZSj6DWzSEdkrsO3cXdaCgt7OJhV+eW2MlI
	g8ovM86y2kNaEKF8G2mT39oelF1wAYZv1AkpXNT6Aa+L+z+qNUc3YfiGIP+n5g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1670687534;
	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=27m2qk8M4HO8FZvt0pveouOjWfjY0nboFeus9Plw5+Y=;
	b=P7aT/Nc7jkqMneZLwo1gGneYPNjvlWW1B+fZyZfQVWU21seAmyhQF/CXeAIxycIEuHrSXk
	Vs3l+TbBLk6vdX1g0K6xsnW6wH92KolmUdPjqaZf8HvL7jJlqoTOtVsOt5VeNLIMPy6fgK
	wiRdbyMrQYoX7yztkH5kvWd1S3dSJQB+Ymv9ni6ADkmoo+U44c9fZSUNLL8973JmiFeFl9
	TnOBC4q6DCJBZi2ywuQuJXMP7TzfpqxLBkuEVmApvpuxfYK0KNtpTU+58Q9/SNMIFyvlyd
	pE/sMmEy3m5GrNLDTFIOfM3FQ4DMbxxANjGLk53iYo9oHzbZhpwwZEDG4RFfTg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670687534; a=rsa-sha256; cv=none;
	b=k3cXlsvDPXCTv9HMzYZeOmsLTneHm4Wgp2+BY1gKQ35L7ozX6Kazr55Jn4jlgHCEAmfMyt
	AOn1mauUNwrGV3KG0oMnbMMa61YjaEp09BNeOOirW53llyABlLX2ZRAMTR2m8s5pZo1nk1
	1V3vKqBFTXh3490g8JWW8SVL2Uoe4AYgezQ//nNiwMp5DJOaFiTE2xSbaCLgPtXrm0JZMR
	lxDoYBrlhzfWQQ/G5bxD+BeUA1lrjm27LAL5okm8stGfhIkk7wBtcxNZpXh9StfdfjWnUm
	vCsZioKSyk4C28LnUmB+SPNs+tU+DnaPqVEThhV7qCdYFHCrnLJLcKJdBA/r3w==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NTspP3vTDz109Y;
	Sat, 10 Dec 2022 15:52:13 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Content-Type: multipart/alternative;
 boundary="------------ljsFn2DAf5A7hw6kP2lsz95p"
Message-ID: <0a1421b6-71b1-83dc-9cf1-52a11304ed61@freebsd.org>
Date: Sat, 10 Dec 2022 15:52:11 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: ifconfig_em0: DHCP NOAUTO
From: Graham Perrin 
To: freebsd-net@freebsd.org, FreeBSD CURRENT 
References: <991bbedf-95af-6203-cc41-b6c7c0f917e9@freebsd.org>
Content-Language: en-GB
Organization: FreeBSD
In-Reply-To: <991bbedf-95af-6203-cc41-b6c7c0f917e9@freebsd.org>
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------ljsFn2DAf5A7hw6kP2lsz95p
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 26/11/2022 21:41, Graham Perrin wrote:

> With *NOAUTO* (for the interface to be *not* be configured at boot)
>
> When, some time after boot, I *do* want to use the interface, what 
> steps are required for
> /var/run/resolvconf/interfaces/em0
> to be created?
>
> Example context:
>
>
> % date ; uptime
> Sat 26 Nov 2022 15:00:11 GMT
> 3:00p.m.  up 10 mins, 8 users, load averages: 0.36, 1.05, 0.75
> % sysrc ifconfig_em0 ifconfig_wlan0 cloned_interfaces
> ifconfig_em0: DHCP NOAUTO
> ifconfig_wlan0: WPA DHCP
> cloned_interfaces: gif0
> % ls /var/run/resolvconf/interfaces/
> wlan0
> % cat /var/run/resolvconf/interfaces/wlan0
> search lan
> nameserver 192.168.1.1
> nameserver 192.168.1.1
> % ifconfig em0 | grep -e inet -e status
>        inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
>        status: active
> % su -
> Password:
> root@mowa219-gjp4-8570p-freebsd:~ # grep em0 /var/log/dmesg.today | 
> grep -v -e umodem0 -e address
> em0:  port 0x3020-0x303f mem 
> 0xd0400000-0xd041ffff,0xd043a000-0xd043afff at device 25.0 on pci0
> em0: EEPROM V0.15-4
> em0: Using 1024 TX descriptors and 1024 RX descriptors
> em0: Using an MSI interrupt
> em0: netmap queues/slots: TX 1/1024, RX 1/1024
> ahciem0:  on ahci0
> ses0 at ahciem0 bus 0 scbus2 target 0 lun 0
> em0: link state changed to UP
> debugnet_any_ifnet_update: Bad dn_init result from em0 (ifp 
> 0xfffff80001b88000), ignoring.
> em0: link state changed to DOWN
> em0: link state changed to UP
> em0: link state changed to DOWN
> em0: link state changed to UP
> root@mowa219-gjp4-8570p-freebsd:~ #
>
>
> gif0 is sometimes used for a tunnel between 192.168.1.10 and an IPv6 
> tunnel broker.
>

Please, can anyone answer the question about steps?

Through hours of trial and error, I did find at least one routine that 
works, however I do not know whether it's a proper routine.

If someone can tell me what's proper, I'll compare with my own 
experience (and maybe make a bug report).

Thanks

--------------ljsFn2DAf5A7hw6kP2lsz95p
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 26/11/2022 21:41, Graham Perrin
      wrote:

      

    

    

      
      
With NOAUTO (for the interface to be not be
        configured at boot)

      
When, some time after boot, I do want to use the
        interface, what steps are required for 

        /var/run/resolvconf/interfaces/em0
        

        to be created? 

      
Example context: 

      

      


      

      
% date ;
            uptime 

          Sat 26 Nov 2022 15:00:11 GMT 

          3:00p.m.  up 10 mins, 8 users, load averages: 0.36, 1.05, 0.75
          

          % sysrc ifconfig_em0 ifconfig_wlan0 cloned_interfaces 

          ifconfig_em0: DHCP NOAUTO 

          ifconfig_wlan0: WPA DHCP 

          cloned_interfaces: gif0 

          % ls /var/run/resolvconf/interfaces/ 

          wlan0 

          % cat /var/run/resolvconf/interfaces/wlan0 

          search lan 

          nameserver 192.168.1.1 

          nameserver 192.168.1.1 

          % ifconfig em0 | grep -e inet -e status 

                 inet 192.168.1.10 netmask 0xffffff00 broadcast
          192.168.1.255 

                 status: active 

          % su - 

          Password: 

          root@mowa219-gjp4-8570p-freebsd:~ # grep em0
          /var/log/dmesg.today | grep -v -e umodem0 -e address 

          em0: <Intel(R) 82579LM> port 0x3020-0x303f mem
          0xd0400000-0xd041ffff,0xd043a000-0xd043afff at device 25.0 on
          pci0 

          em0: EEPROM V0.15-4 

          em0: Using 1024 TX descriptors and 1024 RX descriptors 

          em0: Using an MSI interrupt 

          em0: netmap queues/slots: TX 1/1024, RX 1/1024 

          ahciem0: <AHCI enclosure management bridge> on ahci0 

          ses0 at ahciem0 bus 0 scbus2 target 0 lun 0 

          em0: link state changed to UP 

          debugnet_any_ifnet_update: Bad dn_init result from em0 (ifp
          0xfffff80001b88000), ignoring. 

          em0: link state changed to DOWN 

          em0: link state changed to UP 

          em0: link state changed to DOWN 

          em0: link state changed to UP 

          root@mowa219-gjp4-8570p-freebsd:~ # 

      


      

      
gif0 is sometimes
        used for a tunnel between 192.168.1.10
        and an IPv6 tunnel broker. 

      

      
    

    


    

    
Please, can anyone answer the question about steps? 

    

    
Through hours of trial and error, I did find at least one routine
      that works, however I do not know whether it's a proper routine. 

    

    
If someone can tell me what's proper, I'll compare with my own
      experience (and maybe make a bug report). 

    

    
Thanks

    

  


--------------ljsFn2DAf5A7hw6kP2lsz95p--

From nobody Mon Dec 12 06:58:41 2022
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 4NVstC707wz4k5qP
	for ; Mon, 12 Dec 2022 06:58:59 +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 4NVstB3r3Wz3NFp
	for ; Mon, 12 Dec 2022 06:58:58 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=nkIabM+7;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670828336; bh=xhQgxu57C9iBn9Lajd/5H3MotiUP/SnUa4gNmLWzCgs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=nkIabM+7LY9wZvi+1ApYaaYNFaEB+FrsdVnr9emvNdr4qm/phD6hWIBtwgagK3zHfRGFBI3qj3l7PISnkTt20aoIFGdQWdvlYZVDRTE+aHP+u4/XrP8rbqZVtzr6EVO9e3MMZB+kTtArLR6zzsVfZlFCO7ve2fzkEHqfSAxVVGVS4bjglrM+UqkaD5EXRr51dARrGhI0leJ5NJCE8mFBuZwTIZIJdfnJhKGux8uGaepcBZj3tXGIPOmzJXToyLQ/quEvnJLyehdfpRzzaKMT8UbcmKFcUXUudWqGe8lxoqRYQcVQJo0YL7BODychYwHItRBAqmQ2pmyVIWHKM3gSGA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670828336; bh=Ncfy2IUxIhE0p1og9qf4nVo3eLfIeyaowNEc9AGDvSV=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KBxrAnMM2i+nARhHNeiruFQXslG/bVwHLnnvT8amXvg6fACLblUtcnVXQKc+4CPmEQPB/PCfZk1g1LOBO5K8g+1jL2i4IrA03A3UJ/D38gztMyaVHuDrJgXkKHOKCITDZJIsUSyEokrQfyowpAu3DTiql2s9LhbXO8xaALdLdIamhTheQON8oBE8/YALZAhv/ru1fIUqo3xXlXuLwkadR8/hqpIn3wjExBnrFSv3aTYxLWIOLzFKzgonzAOocbLKZIfeslQc9KyZ4NQQnwrjzvEs196tDZUN5ko2Oh9Za0n/guTAN7x/7WczdOryL2iMQmRjJPvEhrcW3byqR3SxdQ==
X-YMail-OSG: vN2oSs8VM1n0eb1r.mNBD5vio1SQUZ7pB2R5d7IgvBMpyvPREqx3TAQouUU4LbU
 3Z2uOuHTc3FVMOSjJPKEFl9WtmkI7ICr0qQwR5f9mCecAPZxUqZWttykuG0jjFm3GEPQUTKkRaqa
 nFzHTUjvOlWWrdN0t9Pt2.HotiyBXsdlAocEA8iihPgxOxzqWMWri0NmqYzKjcY9X3JgVSjSSSdV
 hn7LYmcbAtOzQp0fyQV5NGcyrSb6wW8wThmUmXosRa10oNPQFl6RQqr9wLJZAj43XmSrcnn06FC7
 ocug6JrSDPvA0ztIvLKwSFYZJNhN8NRt8F8JZMCwRzz3xUJNT6Qs7y1N96uW61VpADwMW7KSEDYf
 _4QUD9gfWWCdPwdec90IAdI6rdlDZkVnQWA3q7mPWEPmhJyIow0yveT7aYPSaJ_2vWKrkaIXLIea
 JgFGMDUasvFX80At8pkM8T3tw9UdDVZv.eJeMfiY81RNU.kHgXA88ZjJEF7MJIQQGEEzdAMV1q9C
 7AGjtcCrZhimC1NIJkhSY103k57KJfEun2lGA2wAE8I_ybByktn4RzgFkAcsoAZxNs4vxPtFKCwQ
 lIHmO3q.kkiWpGtA3VQnhEfaeNgMdq1L.k1Im88ihz7YFUtsGbYfHyWJvDMXRA1NbYE9YE6e4AJP
 7r6TX3iR76asQzIqqU5QdO0d0pdbeqy_dhT_mmbmwXf4euP7sNV55z88SRhwJo4oZLft0kCQqDnL
 nvYW.Ywh8qVsGV1U2DZkmK8V1DOCBPSFVaR1mnuh_zJRMa9LcTdF1gmrfvVxaQeEJruXUwQSh6LK
 wGCx1gawR2krJT_ijGtK3txiyC2_JkpGmz3UA2UsBSUCM.5d0iLZm0SNCdaIkOPfc7Dgl9AI3YUv
 gjDpOkLzrOJVcNUljBHqs_OosvtYla8lhydqf9LTleK4uIz9dGi1EDYHAiJkjKH3efRMH_prUB3n
 WHn_5q1KeyW3Xt7rYm68bEU54fl1wmjtyUT955OXDMVW3IzKuRbQ2ie1stqYhea4i_EMFcPNCKLY
 CTxkusQ2N5dUOY9CSyUBxWA7enXjHavb2.zg5VXMcifzTNSkCz7YyCYBjJP1sF_jg_O71YQW6Iqj
 JnBfaycam4w5EiD9HQ_qusqhi6A.lya7lgvdoODqbY54aTK2MJUPR.R4BMg5QYf_mrczPuJfNtm2
 08LxjTo2Zu4CiYu1A7t8g6z4LJgFTg0IoHJJlpcQGtU3thMeouMCqJh8iRzI79krbT3yX88Odj1g
 W.1VfPwalPRKwMRIUDjRtUqR.tVrK9XrkG1jGoGc5ObWakYu84opVgHWYzJB5Xt6o5OPNfHEt7Z9
 aykwXOlL7PDc41UEVtia.tARXW7WB7XJnRJdnXnu.8u5VmdcXrsm21ngRnxVYVspBeRspB.TfhN2
 8slf0uAglAfB9WLxGOoFGknBxfBhGc_X.oESxQ4hSOqF92WPArW0bHZKiBKQ9VhIR4S35aYbP.06
 RjnQJePqRrx8U0d3B2rz3usrS7Inof054BAIzCafsNz0UNwkqokrsIbpUAAKNTJrcV6Z7BufGgTM
 W6au3mce0itjzH9lpQ.QAm.4P4bGSplnOGVJ0WF7k4FbJpoVQZBdhSN2_kR6USUtd8lBGcjFTtkQ
 q0cScDl5qMCkTZqnYHmZHuC7Dh.5RWs8I2FXKMeyPDkvv9Zs3grSkAwGrgG3N3BZoC0EPyl7CnlM
 SqFOonxNbMPL4ECOo6v8vIRA1aHph0s6aaFwc7djlbAeLjNTshmErKqrIwJ6lDQAwbAZrqe8aX8K
 GkvDmo6epZToqte4hHYvHFoPQynuEtbi..iSMTr7UoHjpfVdWUU.vYQJcvHsG63bB.ILvC4_HUAe
 3pA7Yn1ukVsqZ5WlLVVsHfzAADGAiXM1JG0A06.hmJSJmuT9Zgo4c7UbcpVlmKkwzGoqFZcLmamZ
 v7WZvSsOpNGJSKb.F0vCjaayXzMkDuHlwNE1g8b0o7BCK5VjszWL2YY81qN925sRQNtnUNo10dEo
 rVDKcAmnGqrF2rZ.Z00Z7k2Z40i1N6Sheflo06pMd9X2yyKwp3ZzkvKSVh6XFmWBB0fMICdintn_
 9jOfMgLCW9U4j7clSHFMrUcLoqGaob2vefo1bIyG87AAtFY6SsuKHen6kpACBVsjVi63nBkwyqjI
 ZkosgnG5JdXZmbmfKnQlYKtFR5ihhDMEiwe0bHYnA6WoDUCLpjDLxcnijQtqzeVMyb1NL.QaQOen
 QoHp7BFHVkXAbsDr9.AmqIfWn7CT__wvuxy0l.gJr9JfbeS4fCib8ycjFTsWEcmJWiJE5GHGj5g-
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Dec 2022 06:58:56 +0000
Received: by hermes--production-gq1-d898c4779-nnvpg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID abd28a8f8a5cac9f9c91860a825f70b8;
          Mon, 12 Dec 2022 06:58:52 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: dpaa2_mc_acpi.o build failure with ACPI_DEBUG option? (sources are
 back as of 2022-11-06, unfortunately)
Message-Id: <56937725-3C96-43C0-812B-4676FD3EF26E@yahoo.com>
Date: Sun, 11 Dec 2022 22:58:41 -0800
To: freebsd-arm ,
 freebsd-current 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: <56937725-3C96-43C0-812B-4676FD3EF26E.ref@yahoo.com>
X-Spamd-Result: default: False [-3.34 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.84)[-0.840];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4NVstB3r3Wz3NFp
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--- dpaa2_mc_acpi.o ---
/usr/main-src/sys/dev/dpaa2/dpaa2_mc_acpi.c:186:2: error: implicit =
declaration of function 'AcpiUtTrace' is invalid in C99 =
[-Werror,-Wimplicit-function-declaration]
        ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
        ^
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:480:5: note: =
expanded from macro 'ACPI_FUNCTION_TRACE'
    AcpiUtTrace (ACPI_DEBUG_PARAMETERS)
    ^
/usr/main-src/sys/dev/dpaa2/dpaa2_mc_acpi.c:186:2: error: use of =
undeclared identifier '_AcpiModuleName'
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:480:18: note: =
expanded from macro 'ACPI_FUNCTION_TRACE'
    AcpiUtTrace (ACPI_DEBUG_PARAMETERS)
                 ^
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:402:39: note: =
expanded from macro 'ACPI_DEBUG_PARAMETERS'
    __LINE__, ACPI_GET_FUNCTION_NAME, _AcpiModuleName, _COMPONENT
                                      ^
/usr/main-src/sys/dev/dpaa2/dpaa2_mc_acpi.c:186:2: error: use of =
undeclared identifier '_COMPONENT'
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:480:18: note: =
expanded from macro 'ACPI_FUNCTION_TRACE'
    AcpiUtTrace (ACPI_DEBUG_PARAMETERS)
                 ^
/usr/main-src/sys/contrib/dev/acpica/include/acoutput.h:402:56: note: =
expanded from macro 'ACPI_DEBUG_PARAMETERS'
    __LINE__, ACPI_GET_FUNCTION_NAME, _AcpiModuleName, _COMPONENT
                                                       ^

But this is for source that is somewhat over a month old:

# ~/fbsd-based-on-what-commit.sh -C /usr/main-src/
f83db6441a2f (HEAD -> main, freebsd/main, freebsd/HEAD) sctp: minor =
changes due to upstreaming of Glebs recent changes
branch: main
merge-base: f83db6441a2f4f925a169c7ddf844589cb73c9b5
merge-base: CommitDate: 2022-11-06 22:06:40 +0000
n259064 (--first-parent --count for merge-base)


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


From nobody Tue Dec 13 19:02:05 2022
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 4NWntP17Rkz4kWh9
	for ; Tue, 13 Dec 2022 19:02:21 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NWntN1bJCz4Jxx;
	Tue, 13 Dec 2022 19:02:20 +0000 (UTC)
	(envelope-from carpeddiem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com;
	dmarc=none
Received: by mail-pg1-f180.google.com with SMTP id 142so490197pga.1;
        Tue, 13 Dec 2022 11:02:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=u26dz0Bhe+yuygzpBlrzN5Z1H2ZeLi6oyiwVD3FeGsg=;
        b=FnJGtFlpZ0M+HWNULAi9PkAXPqpsB3ztw6TQgATYVWLBjNE3vKZpljYb+BSh7wcdkD
         0OvARKjN+g4MmMtp0W9rVareT1I49hP13cP/x+uyK79D/qT1qHX2nLpD3ml1mhikWf5n
         c//xkRc0hRefvvvWYTyUsTiDbiKpAbBpPLPdTxRMylv7NeZXKDByMq5SB32cITxEMCsl
         8EVGL1bFP4kS9egfQNctkXl/72n/e5jHPz4QGnjniy2gNtMoQUV57k6RJFptNHlEzP+m
         lvJ8e9MM2Suet85vuagnHpJGTK6C17wjaXGbCHc9DFS43x2cdtOrYR2B4l6D+l5itowI
         B66A==
X-Gm-Message-State: ANoB5pl+KrNLhWSoH38lXxOvI7Ooy0B7Likn6sUaSLsmq63Vhouqtgb4
	314Zl+7xRvHMPfkkSGuWV0XH/n0ikKvifBSw25XfohrRdnk=
X-Google-Smtp-Source: AA0mqf6rhSHSG4egHRzUrWa2LCCo3x4x+ZbzQBoUeT3xowzqu05pb48Y610y+Pv43LxrFfeA39bOisPMjbX7sWZpOsE=
X-Received: by 2002:a63:2226:0:b0:478:54e2:ecb1 with SMTP id
 i38-20020a632226000000b0047854e2ecb1mr37717270pgi.550.1670958137930; Tue, 13
 Dec 2022 11:02:17 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com>
 
 <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com>
  <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.com>
  <20211216161337.1fa53758e61eaeb37b8b24d0@bidouilliste.com>
  
 
In-Reply-To: 
From: Ed Maste 
Date: Tue, 13 Dec 2022 14:02:05 -0500
Message-ID: 
Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?
To: Gleb Smirnoff 
Cc: Warner Losh , Emmanuel Vadot , 
	FreeBSD Current 
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Result: default: False [-1.60 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_SHORT(-0.99)[-0.985];
	NEURAL_HAM_MEDIUM(-0.51)[-0.512];
	FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	RWL_MAILSPIKE_GOOD(-0.10)[209.85.215.180:from];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.215.180:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	TO_DN_ALL(0.00)[];
	ARC_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[carpeddiem];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	R_DKIM_NA(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NWntN1bJCz4Jxx
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

On Thu, 16 Dec 2021 at 11:49, Gleb Smirnoff  wrote:
>
> So I'm fine with removal [of ce, cp drivers] if anybody demonstrates
> me a non-zero cost of leaving the drivers in.

I just found PR264160: likely heap overflow in driver for Cronyx
[ce(4), cp(4)] adapters (others also possibly affected)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264160
although it was submitted some time ago. I am not sure if it's a real
issue or not.

From nobody Tue Dec 13 19:04:16 2022
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 4NWnwm0vw2z4kWlg
	for ; Tue, 13 Dec 2022 19:04:24 +0000 (UTC)
	(envelope-from glebius@freebsd.org)
Received: from glebi.us (glebi.us [162.251.186.162])
	by mx1.freebsd.org (Postfix) with ESMTP id 4NWnwl58Ggz4LJb;
	Tue, 13 Dec 2022 19:04:23 +0000 (UTC)
	(envelope-from glebius@freebsd.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: by glebi.us (Postfix, from userid 1000)
	id E51972DCC8; Tue, 13 Dec 2022 11:04:16 -0800 (PST)
Date: Tue, 13 Dec 2022 11:04:16 -0800
From: Gleb Smirnoff 
To: Ed Maste 
Cc: Warner Losh , Emmanuel Vadot ,
	FreeBSD Current 
Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?
Message-ID: 
References: 
 <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com>
 
 <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.com>
 
 <20211216161337.1fa53758e61eaeb37b8b24d0@bidouilliste.com>
 
 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4NWnwl58Ggz4LJb
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Dec 13, 2022 at 02:02:05PM -0500, Ed Maste wrote:
E> > So I'm fine with removal [of ce, cp drivers] if anybody demonstrates
E> > me a non-zero cost of leaving the drivers in.
E> 
E> I just found PR264160: likely heap overflow in driver for Cronyx
E> [ce(4), cp(4)] adapters (others also possibly affected)
E> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264160
E> although it was submitted some time ago. I am not sure if it's a real
E> issue or not.

At this point I'm fine with removing the drivers.

-- 
Gleb Smirnoff

From nobody Tue Dec 13 22:19:39 2022
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 4NWtGL3cJcz4jhLR
	for ; Tue, 13 Dec 2022 22:19:54 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NWtGK6G5xz3ns1
	for ; Tue, 13 Dec 2022 22:19:53 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=qd7Y3sRx;
	spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::102c as permitted sender) smtp.mailfrom=rick.macklem@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pj1-x102c.google.com with SMTP id hd14-20020a17090b458e00b0021909875bccso2291740pjb.1
        for ; Tue, 13 Dec 2022 14:19:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=+HmsmmAOuJPq20Vzz3rIqWxQrnMSsnXxjhAALcU5XPY=;
        b=qd7Y3sRxrrAEVlGD9EjZb4twv8THnuAJE8Ua4w4VQ+tpIpvweySk5S8bALsWs54dTx
         91sAf3mcWNQkI+kYUbN8UKxUZ5Gvc19FBCucjSzgUpRXsTg0GpWKUcoupB084i2Nhr23
         gbpOvJTTjJSn56s5XrO0syHxmqX1xzIJ2Nk5yj4T1oC9P9BRX7A4GS1HlBRg9Ph9AsC4
         hcfqUd5d+R60s1c/2P4kl3dvsDRCQfVXdXf3XK3Cbvwcz82vyQE9u1IR+2apXy0MwExn
         zJi+kxW2XMAFKrgbowyU3aboYlKgXkDEYGxK+oF57du1MWRl9hYG9Br0QU7iwS2IPxDT
         m+6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=+HmsmmAOuJPq20Vzz3rIqWxQrnMSsnXxjhAALcU5XPY=;
        b=KKZjQyTldUDF+8kQLw/ACC6fuPJKuyMAm9mBWJSo31eq49bbVVf06rHQR7FNl/77U0
         LNCxsCLNpB7DeQN0dlEeBdtDnF3iGmr+76JtF1mtMwVUHWckgRvMIjyn2yKuxBqrSo0l
         lZhYY2bMM3XbVBAhgUBj9Brl8PU9zTAFeefLkweoggP8U466lv1VrqWISkH/DEWIX1Gq
         dVQeXn8A8wh6UrVpg5f1kMxE9MfZlmfw76KO3scwHdZ4EXHvxRT+PPf4zRgn2XK3QRx4
         eTpLqMWLW3NpPGtrHsPH+F+766xMlugyyf4BCAwNfxf8dqdf4cxxllzKBmOdEdBDVsUx
         8Wdw==
X-Gm-Message-State: AFqh2krCAI42e3dtNToofi7W/OpBCCYX74vz142bJzky0Ihb+WY6pqnR
	YhgUzEmI6wvE8Vofpxpkw4CSmeciQsUQTc8LYQci4lP8dWom
X-Google-Smtp-Source: AA0mqf4csZbByUYYH56lamZi/lF2+m8E3OHN+Mllq7LriwXVgObheI/oYt2QwjabZcxDShuy72mr9SNaPhpok/Psoks=
X-Received: by 2002:a17:90a:7e0a:b0:219:661f:9916 with SMTP id
 i10-20020a17090a7e0a00b00219661f9916mr31876pjl.200.1670969992586; Tue, 13 Dec
 2022 14:19:52 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
From: Rick Macklem 
Date: Tue, 13 Dec 2022 14:19:39 -0800
Message-ID: 
Subject: What to do about a few lines in vfs_domount() never executed?
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000d6a85d05efbd0464"
X-Spamd-Result: default: False [-0.55 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_SPAM_MEDIUM(0.94)[0.942];
	NEURAL_HAM_SHORT(-0.94)[-0.936];
	NEURAL_HAM_LONG(-0.55)[-0.551];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_TLS_LAST(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102c:from];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	TAGGED_FROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NWtGK6G5xz3ns1
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

--000000000000d6a85d05efbd0464
Content-Type: text/plain; charset="UTF-8"

Hi,

While working on getting mountd/nfsd to run in a vnet
prison, I came across the following lines near the
beginning of vfs_domount() in sys/kern/vfs_mount.c:

if (fsflags & MNT_EXPORTED) {
     error = priv_check(td, PRIV_VFS_MOUNT_EXPORTED);
     if (error)
           return (error);
}

#1 - Since MNT_EXPORTED is never set in fsflags, this code never
     gets executed.
     --> I am asking what to do with the above code, since that
         changes for the patch that allows mountd to run in a vnet
         prison.
#2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always returns 0
     because nothing in sys/kern/kern_priv.c checks
     PRIV_VFS_MOUNT_EXPORTED.

I don't know what the original author's thinking was w.r.t. this.
Setting exports already checks that the mount operation can be
done by the requestor.

So, what do you think should be done with the above code snippet?
- Consider it cruft and delete it.
- Try and figure out what PRIV_VFS_MOUNT_EXPORTED should check?
- Leave it as is. After the patch that allows mountd to run in
  a vnet prison, MNT_EXPORTED will be set in fsflags, but the
  priv_check() call will just return 0. (A little overhead,
  but otherwise no semantics change.)

rick

--000000000000d6a85d05efbd0464
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

While working on getting mountd/nfsd to run in a vnet
prison, I came acro=
ss the following lines near the
beginning of vfs_domount() in sys/kern/vfs_mount.c:<=
/div>

if (fsflags &=
amp; MNT_EXPORTED) {
=C2=A0 =C2=A0 =C2=A0error =3D priv_check(td, PRIV_VFS_MOUNT_EXP=
ORTED);
=
=C2=A0 =C2=A0 =C2=A0if (error)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return (erro=
r);
}

#1 - Since MNT_E=
XPORTED is never set in fsflags, this code never
=C2=A0 =C2=A0 =C2=A0gets executed.<=
/div>
=C2=A0 =
=C2=A0 =C2=A0--> I am asking what to do with the above code, since that<=
/div>
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0changes for the patch that allows mountd to run =
in a vnet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prison.
#2 - priv_check(td, PRIV_VFS_MOUNT_EXPORT=
ED) always returns 0
=C2=A0 =C2=A0 =C2=A0because nothing in sys/kern/kern_priv.c che=
cks
=C2=
=A0 =C2=A0 =C2=A0PRIV_VFS_MOUNT_EXPORTED.

I don't know what the original author'=
s thinking was w.r.t. this.
Setting exports already checks that the mount operation =
can be
do=
ne by the requestor.

So, what do you think should be done with the above code snippet?
- Consider=
 it cruft and delete it.
- Try and figure out what PRIV_VFS_MOUNT_EXPORTED should ch=
eck?
- Le=
ave it as is. After the patch that allows mountd to run in
=C2=A0 a vnet prison, MN=
T_EXPORTED will be set in fsflags, but the
=C2=A0 priv_check() call will just return=
 0. (A little overhead,
=C2=A0 but otherwise no semantics change.)

rick



--000000000000d6a85d05efbd0464--

From nobody Tue Dec 13 22:25:27 2022
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 4NWtP20FTFz4jjH8
	for ; Tue, 13 Dec 2022 22:25:42 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NWtP12XJgz3q3W
	for ; Tue, 13 Dec 2022 22:25:41 +0000 (UTC)
	(envelope-from asomers@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=asomers@gmail.com;
	dmarc=none
Received: by mail-vs1-f48.google.com with SMTP id t5so16152160vsh.8
        for ; Tue, 13 Dec 2022 14:25:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=wJ2jqbIWlriHZJI0pOhklUW5lJSdWDCQsL3fMAA/rGo=;
        b=qh0JH1YE324p/hjzQpUIjkLJdOpbvgRmKEyzPhF1Zri2cllzRuFEQm/eB1T4bRp9mR
         9XwEmjpoH56KsFMhZwpwFyuTMzJaF/04vVXeWzjkzKVmx/m2lbfgeM560F7uWHXDqL+u
         J+/PmlNqLx7bc9sLaokPJRo650IQHU3j1du4p4SZmpFW5/ijBL8yL7b9dMtYcbOsL7Bn
         hMyCpFX0pvqP37+tYOPwYsfMbqlxN9YPkFQ7+mTQvb+QcwT7hCxJFbfA+oSYQYCMfyip
         lFBQb8QfWr/195zdR7jmE826rCJNSrgYG2vmDwuZ2qVpABIQG2OUpn9cTa5C7xOlJeMQ
         TSlw==
X-Gm-Message-State: ANoB5plzxVeT7+kKHJoa7+jHB9h1AvnBnVxdK/8Pr/47DQSfAzwsPcvS
	7FeKXZ5wV5rxBemVprQx/sYujiDFfQ7+emTRpJ8z08p8
X-Google-Smtp-Source: AA0mqf4+nBzVVhMjwv+y5UTdBkMP7xVuxTVh+gAuA7FQl7jCcXWBvixU6+17/UdvGfvoCYuMUnLVvG5QGTvqn+BUUaE=
X-Received: by 2002:a05:6102:c48:b0:3b0:9f5f:e25 with SMTP id
 y8-20020a0561020c4800b003b09f5f0e25mr28019919vss.74.1670970339267; Tue, 13
 Dec 2022 14:25:39 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Alan Somers 
Date: Tue, 13 Dec 2022 15:25:27 -0700
Message-ID: 
Subject: Re: What to do about a few lines in vfs_domount() never executed?
To: Rick Macklem 
Cc: FreeBSD CURRENT 
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Result: default: False [-0.15 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_LONG(-0.98)[-0.981];
	NEURAL_HAM_SHORT(-0.96)[-0.962];
	NEURAL_SPAM_MEDIUM(0.79)[0.791];
	FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com];
	R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	TAGGED_RCPT(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[209.85.217.48:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[asomers];
	ARC_NA(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_ALL(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.217.48:from];
	RCVD_TLS_LAST(0.00)[];
	R_DKIM_NA(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US];
	FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NWtP12XJgz3q3W
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

If you're 100.0% percent sure that it will never be run, you can
delete it.  But if you're only 99.9%, then I suggest converting it
into a KASSERT.

On Tue, Dec 13, 2022 at 3:20 PM Rick Macklem  wrote:
>
> Hi,
>
> While working on getting mountd/nfsd to run in a vnet
> prison, I came across the following lines near the
> beginning of vfs_domount() in sys/kern/vfs_mount.c:
>
> if (fsflags & MNT_EXPORTED) {
>      error = priv_check(td, PRIV_VFS_MOUNT_EXPORTED);
>      if (error)
>            return (error);
> }
>
> #1 - Since MNT_EXPORTED is never set in fsflags, this code never
>      gets executed.
>      --> I am asking what to do with the above code, since that
>          changes for the patch that allows mountd to run in a vnet
>          prison.
> #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always returns 0
>      because nothing in sys/kern/kern_priv.c checks
>      PRIV_VFS_MOUNT_EXPORTED.
>
> I don't know what the original author's thinking was w.r.t. this.
> Setting exports already checks that the mount operation can be
> done by the requestor.
>
> So, what do you think should be done with the above code snippet?
> - Consider it cruft and delete it.
> - Try and figure out what PRIV_VFS_MOUNT_EXPORTED should check?
> - Leave it as is. After the patch that allows mountd to run in
>   a vnet prison, MNT_EXPORTED will be set in fsflags, but the
>   priv_check() call will just return 0. (A little overhead,
>   but otherwise no semantics change.)
>
> rick
>

From nobody Wed Dec 14 13:08:01 2022
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 4NXFzC3RXjz4kZtK
	for ; Wed, 14 Dec 2022 13:08:07 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic318-22.consmr.mail.ne1.yahoo.com (sonic318-22.consmr.mail.ne1.yahoo.com [66.163.186.84])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NXFzB0h5Mz4MTd
	for ; Wed, 14 Dec 2022 13:08:06 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=hEIUJRIj;
	spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.186.84 as permitted sender) smtp.mailfrom=filippomore@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671023282; bh=dgKDuJnXvGdsS6mxsoL13N+AgY9abr3CHE1vK8yPmIk=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=hEIUJRIj1BLaSznQZdNDeXvnnHlIwL3Xw3BTcbyDiUL2aJyq++XrO1aWyUXztxca1rbsN2mN6349+2eMsWNXYFnKgc3C97puMJPg7vGvDmsxHrgrV1dWYq0RTy87Q+xHqcSyrPaaHNGEl4yJcN06GYLdoIBk1rsj0JXz+kLnWAIYFLs9wOu9UuZ0F7nFZc5oI1ez7TPDuj3T2jQbqWh8kOR1tXDDfC6+ilIIErsgt1s9nECKrBtyyNIQ1u/277x3cvzRmk8b8m+lkIL3dBR/vt16lX+w/kYp/27iZQ8NKQ3XzbrIVjnwx1MCVh5TJTsceFuIB98Q0XvfYk1eU6bugQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671023282; bh=SspjFK8urbfjqCXHmagLwBItepnOxg9U5WrFJnzOzCH=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=S9x7YliFkC519FNyFqeu2zoXqQt7UFKS+xaMzn5qj9WxkFxFHF5QlgWuyLlMga9M1RXntURcs4RGu58n5N6ziiLk+8OXbrHTWSxt/QdOJ69ZRJvJOFhKrtZqSYPgo9gE1qUc54EMcgWXWyN8xwiZCd+VNrwq52f76HcXji7ZSnRLTpXmfoSr6iGT+tXXy3XFJ588O2Wv9Wxfibe16zqdNqTTcrRejCjnTQcDUjJWl6a895HUlxEZVCbIMgHb0Rb9yvcU1yLzi2DzdzRnLFBiepA38BsxVSC9j4jXDWq+kkbX3WWiSrgeY2ODewQEjlaDbbZ6Ubb0d7qaZKUGLpnpKg==
X-YMail-OSG: WVi3YTMVM1nqBdD34Bu89YhdQUNuPptUWVqQvhUtAFZLT6BYLN6W_RSpRvD12L9
 ggizWuSUBWlm8ilL0FatLkqHZUHqfsW6nHQC2otGSLoKB7dssshgL.u2m9GhfOJJ_B_bXImvnD2.
 ZCyPLAyqWJEPZyul4AN7xbWzkm880cSlSdTMCVOW6KQn3MRs4Fe53KwGtLeO6PmtBXxpyR_S2t03
 Q3CMR.m6IioBzAD9dOgjGnApl5J8Gxm.VwaQcubZQkZQnKocf_WbIDc33FQ7X2p0cHwO_sN4s5d7
 AZb1MJylyGeqZ_F3urvNEqCxkdrLs8UQV1zI7Ml3eIKJvvM_Zp.b53w1uKUpP_ixAhAhfIaBHVmP
 y8q2N3H1O3yLcQfCpfTVYc0FbVeWBdik6JAp.dGr7Rbe4rT94qFbiyH187uisXCLfvKmI_g0576N
 zp9sBSJOQkHkV4GmZ5mtOc4wbuw5YjeCOKdzdW29B1yoILAGxOh1ayitsWE.GHhyb1J2xV6g_i2r
 RHROGWX5kepypwTowfp_XEjR9bdheOzAtseRPMPHkp.iHV3nxpJhZVaWXc9ExVujxRVPRfgCoaZr
 VNZ2MLFM3egaxaEr_tY30Nueja2Yu6r.dB39nVN4mao1t7J_HiA2JLeO0ko3rYwgSBOrkYRyMyw8
 U7v_KAA3TpTZgRcaQISyRKSB.A5l.jHLpexbSNm4fexKM_NIyiQGbL.LLvjjdjl0p3GFgZulkM0q
 cLOjfhOl6AZkQbKqMQG_A0GeO0ZUK2Ob5UrY0Vf6mFVYMVJck0RItq0vNWxQsEwJJMzvFJc5NKD7
 1R56H74_OhJEK8BZ9VDqGS6Mb0Bj7a.S_OcKlWOtxU.2p2e3sIUY2rMb7vpTyMS4CajDz6LwbVBX
 MNLoZKUGInvNnsZOPmQTugEsdzLNV0RS9wrzSicsJN9wBXvFF6bSgyFO0YLuiZEbGVc5Ac9vMId3
 ycxb3Mh0zCntYB47RTR4BLo7b7dazc0ms8wWBtjNn7R83awyasTNp9mIEV_pvB1Qej0D4d.2s9v9
 M4lgS1Rhp52zWaayEXEH4lu6220G7ckrkZ22v21egD2T5zprQfvsmtByM6J478bfmsnd2IQNali4
 Fj23sc6Rrivba5JK09Y1PkD.Z5eSfZCiV7zoppXWBdIL6b5_gt2rtXplN52N_cHAfNi9CtrHLvIY
 kTSGq6VyWnz0gLGR2_TJrcU._QBwDKm5N5KqVunc3cbibhRolwL1F732Ltlum2CAN9tDnF8GY8G4
 5.wUyOuH2ZZHr1GvoMhuuYNks79Eibx.zFqK2Zpq09PguZ8EM5B3z4_RuR5kzL_XoqI6FAvuYUev
 TTEqfk8A9mBKXMJ5FpYGji2YEwWpJ4N2Z5D3yHYB6MOSXT15zUW5tSppiVKkxAkbE35LSvsgBEiv
 ljrHWxwvof5XMkarDtqmJgt4iiSzd57uWzAqR1_HVp9.RWBsQPzQk6KrS1X7UKjl5Vs4GChq3W.F
 ewWh.0Ogn.nwdT7nUXCCwwekbQO4O8rG8x6h0L3wmgEH5T4JIjC8hnR6w_AHe9iQcWhrYNC1Y1Kc
 SZ.C8Cv9MpksIOdfMS_YLRMp90tZOET9Nxjay7H.1gLQUw.0PRAmrKiCpxrrgMrqmhvUqsRrs9R6
 e.HT_7x40gBsE90sBUr5h28i9ebKGnuzsAvbfqD.3crbYtbQTio619xhNNTH1ZOo6aVut1csSb9p
 a27pZi4OS2xmvJ22IqTVRG2PYZXhsRlMbiAehvI_0Em9_C49SBeVHmNMv6DQMHMoIXJ0vhqMkIsw
 NC9pBjXuXsFqyo8gVUdyZoumZKun7gzht.aoGoRm2VBxORPQQmDP4ru_UpXMiQ1cv4mlpb6rsVDD
 rIuFcphJbAhEm4GqWFoQAGpY.o7MTOo05ImyQTix6nBB1VDnvNw3wJIaNDUWSp2G7XqiqToC0DmM
 JrjvWOs6Jq6hwjy3kzdtNFYjUH9zpOPLeTij.IENg2GcXrM9k6CQ1.ujUxST5iecf2WvmA4sgAPd
 FthDOMPaFvuMIfW2sxi0KBvhTf89P5.OV8e5.KXFlW_T_K9npFhNtw8fWI3yWm0lsdJvPdG.7Kr.
 QjsB_M1KgM0FxU3Rbp2hxIqV5l1zFOgZANWmVh5HNcZAIf882gLkFR2GDz.7L9SRLI_zSfIsJuzj
 ZRoH75O1HbbsCZa3yeuzcgjKrD2g9kA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic318.consmr.mail.ne1.yahoo.com with HTTP; Wed, 14 Dec 2022 13:08:02 +0000
Date: Wed, 14 Dec 2022 13:08:01 +0000 (UTC)
From: Filippo Moretti 
To: FreeBSD Current 
Message-ID: <1498874308.5423541.1671023281171@mail.yahoo.com>
Subject: Problem compiling CURRENT
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_5423540_1597441317.1671023281169"
References: <1498874308.5423541.1671023281171.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.20926 YMailNorrin
X-Spamd-Result: default: False [-3.71 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.71)[-0.710];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[66.163.186.84:from];
	ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-Rspamd-Queue-Id: 4NXFzB0h5Mz4MTd
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_5423540_1597441317.1671023281169
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

FreeBSD ROXY 14.0-CURRENT FreeBSD 14.0-CURRENT #4 main-n258255-de56ac88099:=
 Wed Sep 28 19:35:24 CEST 2022=C2=A0=C2=A0=C2=A0=C2=A0 root@ROXY:/usr/obj/u=
sr/src/amd64.amd64/sys/ROXY amd64







Dear Sir I had the following error while trying to compile CURRENT=3D=3D=3D=
> usr.bin/rs (all)
make[4]: /usr/obj/usr/src/amd64.amd64/usr.bin/rs/.depend.rs.o, 1: ignoring =
stale .depend for /usr/src/usr.bin/rs/rs.c
cc -target x86_64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/amd64.am=
d64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin=C2=A0 -O2 -pipe -fno-com=
mon=C2=A0=C2=A0 -fPIE -g -gz=3Dzlib -MD=C2=A0 -MF.depend.rs.o -MTrs.o -std=
=3Dgnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers =
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes =
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-stri=
ngs -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wn=
ested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmissin=
g-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-in=
t -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable=C2=A0 -Qu=
nused-arguments=C2=A0=C2=A0=C2=A0 -c /usr/src/usr.bin/rs/rs.c -o rs.o
*** Error code 1

Stop.
make[4]: stopped in /usr/src/usr.bin/rs
*** Error code 1

Stop.
make[3]: stopped in /usr/src/usr.bin
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src



------=_Part_5423540_1597441317.1671023281169
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


FreeBSD ROXY 14.0-CURRENT FreeBSD 14.0-=
CURRENT #4 main-n258255-de56ac88099: Wed Sep 28 19:35:24 CEST 2022 &nb=
sp;   root@ROXY:/usr/obj/usr/src/amd64.amd64/sys/ROXY amd64





=


Dear Sir I had the following error while trying to compile CUR=
RENT
=3D=3D=3D> usr.bin=
/rs (all)
make[4]: /usr/obj/usr/src/amd64.amd64/usr.bin/rs/.depend.rs.o,=
 1: ignoring stale .depend for /usr/src/usr.bin/rs/rs.c
cc -target x86_6=
4-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/amd64.amd64/tmp -B/usr/o=
bj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common   =
-fPIE -g -gz=3Dzlib -MD  -MF.depend.rs.o -MTrs.o -std=3Dgnu99 -Wno-for=
mat-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wn=
o-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototy=
pes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wsh=
adow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wo=
ld-style-definition -Wno-pointer-sign -Wdate-time -Wmissing-variable-declar=
ations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-con=
st-variable -Wno-error=3Dunused-but-set-variable  -Qunused-arguments&n=
bsp;   -c /usr/src/usr.bin/rs/rs.c -o rs.o
*** Error code 1
Stop.
make[4]: stopped in /usr/src/usr.bin/rs
*** Error code 1
Stop.
make[3]: stopped in /usr/src/usr.bin
*** Error code 1
=

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.<=
br>make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: s=
topped in /usr/src



------=_Part_5423540_1597441317.1671023281169--

From nobody Wed Dec 14 13:17:51 2022
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 4NXGBd3snWz4kbhR
	for ; Wed, 14 Dec 2022 13:18:01 +0000 (UTC)
	(envelope-from herbert@gojira.at)
Received: from mail.bsd4all.net (mail.bsd4all.net [IPv6:2a01:4f8:13b:240c::25])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature ECDSA (P-384) client-digest SHA384)
	(Client CN "mail.bsd4all.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NXGBb71Pjz4PF2
	for ; Wed, 14 Dec 2022 13:17:59 +0000 (UTC)
	(envelope-from herbert@gojira.at)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gojira.at header.s=mail202005 header.b=MsZePpdM;
	spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 2a01:4f8:13b:240c::25 as permitted sender) smtp.mailfrom=herbert@gojira.at;
	dmarc=none
Date: Wed, 14 Dec 2022 14:17:51 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at;
	s=mail202005; t=1671023872;
	bh=K4ah4+H1bye4LDl3Orbpas3oRvkzJSDIPfjCyl7gGjM=;
	h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type;
	b=MsZePpdMwnBdH99U7JdZfp9F2l/+vrEXnz0ih5RIHhJqZTUc82Og9t/k3zA4XL+de
	 7aWjcvZl9xeV7uQ85blDIjMqKmSQPScIpModBXpu3OJI3t5OwMB4i8Y2kInNnHla6l
	 QeUBHOi+92rglfSQ5GYXKNhD2vi2IOPuMjQEGCIs+1a2EySQL+zYXVLZ3rFHLYlzuU
	 9xm4IGwhqHKt8MUx8YGN8c7NnY6CI+RxgzoEOO52hjUYb3u7ek7LB/2zVEX3ZMAf76
	 3HkEoS49ZifVgrcndbqU3GXRAv8dWHfSgFbEuFzRLoBESmX1wAUIWD2RWIGT95geHy
	 cJtAMueUdc3NQ==
Message-ID: <87pmcmt98g.wl-herbert@gojira.at>
From: "Herbert J. Skuhra" 
To: current@freebsd.org
Subject: Re: Problem compiling CURRENT
In-Reply-To: <1498874308.5423541.1671023281171@mail.yahoo.com>
References: <1498874308.5423541.1671023281171.ref@mail.yahoo.com>
	<1498874308.5423541.1671023281171@mail.yahoo.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/30.0 Mule/6.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 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spamd-Result: default: False [-2.50 / 15.00];
	MID_CONTAINS_FROM(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:240c::25];
	R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_ZERO(0.00)[0];
	DKIM_TRACE(0.00)[gojira.at:+];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[gojira.at];
	FROM_HAS_DN(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]
X-Rspamd-Queue-Id: 4NXGBb71Pjz4PF2
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

On Wed, 14 Dec 2022 14:08:01 +0100, Filippo Moretti wrote:
> =

> FreeBSD ROXY 14.0-CURRENT FreeBSD 14.0-CURRENT #4
> main-n258255-de56ac88099: Wed Sep 28 19:35:24 CEST 2022=A0=A0=A0=A0
> root@ROXY:/usr/obj/usr/src/amd64.amd64/sys/ROXY amd64
> =

> =

> =

> =

> =

> =

> =

> Dear Sir I had the following error while trying to compile CURRENT=3D=
=3D=3D> usr.bin/rs (all)
> make[4]: /usr/obj/usr/src/amd64.amd64/usr.bin/rs/.depend.rs.o, 1: ign=
oring stale .depend for /usr/src/usr.bin/rs/rs.c
> cc -target x86_64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/am=
d64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin=A0 -O2 -pipe -=
fno-common=A0=A0 -fPIE -g -gz=3Dzlib -MD=A0 -MF.depend.rs.o -MTrs.o -st=
d=3Dgnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-hea=
ders -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pr=
ototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual=
 -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wch=
ar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign=
 -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty=
-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=3Dunus=
ed-but-set-variable=A0 -Qunused-arguments=A0=A0=A0 -c /usr/src/usr.bin/=
rs/rs.c -o rs.o
> *** Error code 1
> =

> Stop.
> make[4]: stopped in /usr/src/usr.bin/rs
> *** Error code 1
> =

> Stop.
> make[3]: stopped in /usr/src/usr.bin
> *** Error code 1
> =

> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
> =

> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
> =

> Stop.
> make: stopped in /usr/src

Have you tried to wipe /usr/obj (or at least:
/usr/obj/usr/src/amd64.amd64/usr.bin/rs/)?

--
Herbert

From nobody Wed Dec 14 13:22:33 2022
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 4NXGHy0dhpz4kc82
	for ; Wed, 14 Dec 2022 13:22:38 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic306-21.consmr.mail.ne1.yahoo.com (sonic306-21.consmr.mail.ne1.yahoo.com [66.163.189.83])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NXGHx5cQQz4Qdq
	for ; Wed, 14 Dec 2022 13:22:37 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671024156; bh=4SyEzXGuR2WV+S66yssBRypY8X2hqudffvQGno4npWs=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=C3eqJFH4TbGBZRLkjbkR04aRuyiO6Nj+pCexz7c1MvYnCw+FSOj+W52QAZUF/ZhBdtS+ehBg42yvgu6qyOxjWkg9W9ugUQPyZb0uQHHOwyEXI/kiDnBmMP3sP/EH8MpS2StJchHXnZBYaoT7FO+b58wsPnA8fo/rR/5z9oIOtiusSNFzwtZZG2PW7Umiq8abQVN95ExgAI/3L6o4CGfqHAJEfGl0Ew3Bf3HDlxM0JHSKz40ukjdi25pQnl+y6f1Vu+6Uzv2rCyaVgwJXr86FHHQnUsa/nqLX5t7LSvoT1FY803qZ04+YGbW4MVQ48tkdFTFN8D1b5tIDN+dIVlc0GA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671024156; bh=FCjS3XborL/PFZEcMm4yXDQcDF75fuV4lXisEzMh5tO=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=KI1GjGsecjxfaDKT530HrO2KRdr0TKHVpPXbLWLEGC0qUcQzUO2xP1DxTuQqN8z6qSRZpKVC0LY5JpjoL/qkDmb7fatpvz8XsFSIG2pauQh9PcYjg9jCg5G6XJWhASVgwhHm/h8hhco7m8GgXVLoOpJ0D2x+z1DgMCPWys5UhmHnWugv2SIObQh0qh13mMZFGmV8v8PlGDCozzO2p2eH5QaM+NlMcINQAH5OmYFbVgvvLu3upSba7FHQCklH/mV8EVLChb8Bzfs4b1iK38VamcZpxM0gyGRbUjSM7/pdnaBN+iesAORwomICOBL/COZ1pAuR5ho6dMxxbdfHxQDtVA==
X-YMail-OSG: mZVYjKsVM1lPg_sBMFRkIVca0d2Vc4Vg2OYc.9w6tQ590c754L5ACrbCOFMLy5P
 Rv4I1lxWGUnR.DlCG5EVNoIblhqFyrNF9VGRSu3ZbBOwL5.mM.E55CHHhyTmwz4NwhmVSkwz5xZN
 cRVx3_BloaPxrycUEbmObROTPkeeB8zca3Hnq3L6DwU7kEkWE2eK0kYWFs6O1IGU8EMHAzdIsbDT
 Y3GMbw02elJOJWo10PeJsP5c.G4CtoOi_c75wys.Zw5rE0.dISFnLPiz31ngtyA2YttV4zXDwlI6
 IN6XMx8yb3UiID_YnTPJva0QlrAGmAVh_KZWNaFOwgIUAXPPCPAspPNUcnLmW_SBYyrLgoxtRbF5
 ozR6vDa.yfSCdrkpv_P4g3.W_NL8UOPOstHYqzzLZZxjEbTwZlpnw90inHiA_dCiIJJCK4Km.ka9
 vs5JwiliVtekvR1XVHk_pgxTOV2VaaZ_PjmJC1ugmW18qU8NL56EGVMxBviBVOXwPOUkkU.jEqoS
 ZgjkPDAc9dLRrP.AVVgScP2rvj2ntYzHhmmlcW6_siIeXs.BPR_3AyvetllaeeSa_3Q9WdwnWH6U
 zTpniiv53zAAmntuhbrZUBFcLOxCYiiYjrh.ttv9r.kyYSPfbbvKMusREBgRHawWQ7x0TiuU_3a5
 TL.2Xlp4XZC1iH0EXlw7RYvbsWuMKuHeyUKBVgECyO8iEmHPKJeShDm3IkG8OXs2aKLwfCObTfc3
 FrV6huKTtpzkLVXGrw9rukwKQ7fKvQZrsY.70gErUVn81gSuG.9pu_JftR0yMCWIFCCLLILtvqmW
 AtDU.91AV_3qI6WYLeJQotId8arrz8gfB3ogM5H8hwsu9FfMqMCkW_uSKCQI9M12efHRzOXnEPq.
 M5eOiWnjtZDrrTbuw2fUTq6KHy2iNCbwuXeUZS8tYjaJMQ84pLNo5cP9XHukXvPIvnpj1mzbQ75f
 kyofqNFU.7ypjjvq79vGqzI8KJgbxCUNALiKaCdxBIYfvD0.LL5fz4lH60NcEQDId3KBuX0TfSIn
 TbKiJrk5hhIZwixjgKMB2Q8fXdE_N1Qp3htVD1azG2W0BObVYltSH8FeXfjbk2Pk_smATziRu2xo
 JnDyExXlwk8jRYrwd.Fbc.oB1ymfpro1JWAOepJU4ECHzAz5sS5RtZKF8vm1prQNtlXDTqvOonav
 AitkWlbfm0X0F.zvqjsDh2MVFzi9V9jsIF.8cifKg3qeBy4RmvrrRw8nyOOVNyrCz.B7eDEfMcnh
 JS0INeGoyae8X.U33hMiU0phgwl3mTj2Ed32.EKSy5EIqRRaggXyUX6pkv4I1iN6xgkl7NM_9Vq9
 5jaqOp0WwPfLeMvjXbm.nVUeO5TphgPkoIFz1XrTAcqucTpK4JtMT6dmI1NMGbKTEiWnLRTib5CH
 zP.Q.apfV.pEmWrQbC1NFt5xt3q35md8Rq1X66iWB3ZJ_2mh6IYD74pKKuCyhKC4lIsYhtkv7o.M
 fgczlNgLaeDZ8iPuHkOxvJDtjeY40ZQcyf8eQJLxB6sdjQ0TgaDRsbk_yL13cQ0G4m4SdoeLso6n
 pTOFmXhu9OCk_k5aPrr6JYCzf9ME_kl2viSNcB18louQp6S0Ze1ff6Ag0CtL8mMdBHA9.yVeMI6D
 F7vbAEMFj.KaJpQVvYv_fmzcdtffcSSaX.2uPpKfeoWdwqDv.iMzJMukOPUBbOIpi0n5Qcq_sJnt
 1wNpci1WpyxYHSdhg48JDjo5I7NXyH2fQen6GtDBbAIBPjx0ThQbHMpJr0NKgJGhAdbikZxMmVUT
 djsvVGN9DvcHTMEQh8ik_R2IiovNoYIrCtJPmWT0rUFdofNMCBxgYwPYUYk859WRE6cH8Oce2EBn
 W7vXogkeuLXYxxoIVuM627uMxF2BnRAMemLM3mw.9v.V6j.SixxEe8zswzbuRMrD_6qzfKBXRjZF
 5axFuVyG_KwgirBEfA9P2SCELV64a8B0n8uEB2IynoFBjdTQZp_d9BWAkuLHsEqn3wVL3AqQUvOo
 v0XIoLcWHDnTy5If3GG1rqKN3SLd4INZ1cO1jSMKn19xESkSI.XlLHwEalUKynEb_BsYKDIHZ22W
 T4eqjiJRxSvtLUldfIozVH9gM6dcFcJS7otJPSHokK9bv2yt6BV4mdAIEvXmLeiNUIjUHfUBR9ht
 Ja1dZSE4cU9oSfEEEW9ti6RwVrJvTeppM5480KOcwjLGS89qufDoM93SgMx6jCyXKzZpzzFpGRAG
 R6uD_JYmjKA--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Wed, 14 Dec 2022 13:22:36 +0000
Date: Wed, 14 Dec 2022 13:22:33 +0000 (UTC)
From: Filippo Moretti 
To: "current@freebsd.org" , 
	"Herbert J. Skuhra" 
Message-ID: <1228071193.5432259.1671024153530@mail.yahoo.com>
In-Reply-To: <87pmcmt98g.wl-herbert@gojira.at>
References: <1498874308.5423541.1671023281171.ref@mail.yahoo.com> <1498874308.5423541.1671023281171@mail.yahoo.com> <87pmcmt98g.wl-herbert@gojira.at>
Subject: Re: Problem compiling CURRENT
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_5432258_1356685440.1671024153529"
X-Mailer: WebService/1.1.20926 YMailNorrin
X-Rspamd-Queue-Id: 4NXGHx5cQQz4Qdq
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_5432258_1356685440.1671024153529
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=20
I downloaded src for current on 13/12 11.20 CEST.I did have the same issues=
 for about 5 days I made a few attempts all whit same error.Filippo
    On Wednesday, December 14, 2022 at 02:18:20=E2=80=AFPM GMT+1, Herbert J=
. Skuhra  wrote: =20
=20
 On Wed, 14 Dec 2022 14:08:01 +0100, Filippo Moretti wrote:
>=20
> FreeBSD ROXY 14.0-CURRENT FreeBSD 14.0-CURRENT #4
> main-n258255-de56ac88099: Wed Sep 28 19:35:24 CEST 2022=C2=A0=C2=A0=C2=A0=
=C2=A0
> root@ROXY:/usr/obj/usr/src/amd64.amd64/sys/ROXY amd64
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> Dear Sir I had the following error while trying to compile CURRENT=3D=3D=
=3D> usr.bin/rs (all)
> make[4]: /usr/obj/usr/src/amd64.amd64/usr.bin/rs/.depend.rs.o, 1: ignorin=
g stale .depend for /usr/src/usr.bin/rs/rs.c
> cc -target x86_64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/amd64.=
amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin=C2=A0 -O2 -pipe -fno-c=
ommon=C2=A0=C2=A0 -fPIE -g -gz=3Dzlib -MD=C2=A0 -MF.depend.rs.o -MTrs.o -st=
d=3Dgnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers=
 -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes=
 -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-str=
ings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -W=
nested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmissi=
ng-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-i=
nt -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable=C2=A0 -Q=
unused-arguments=C2=A0=C2=A0=C2=A0 -c /usr/src/usr.bin/rs/rs.c -o rs.o
> *** Error code 1
>=20
> Stop.
> make[4]: stopped in /usr/src/usr.bin/rs
> *** Error code 1
>=20
> Stop.
> make[3]: stopped in /usr/src/usr.bin
> *** Error code 1
>=20
> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
>=20
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>=20
> Stop.
> make: stopped in /usr/src

Have you tried to wipe /usr/obj (or at least:
/usr/obj/usr/src/amd64.amd64/usr.bin/rs/)?

--
Herbert

 =20
------=_Part_5432258_1356685440.1671024153529
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



        

I downloaded =
src for current on 13/12 11.20 CEST.I did have the same issues for about 5 =
days I made a few attempts all whit same error.
Filippo

       =20
        

            

               =20
                

                    On Wednesday, December 14, 2022 at 02:18:20=E2=80=AFPM =
GMT+1, Herbert J. Skuhra <herbert@gojira.at> wrote:
                

                


                


                
On Wed, 14 Dec 2022 14:08:01 +0100, F=
ilippo Moretti wrote:
> 
> FreeBSD ROXY 14.0-CURRENT FreeBSD 14.0-CURRENT #4
> main-n258255-de56ac88099: Wed Sep 28 19:35:24 CEST 2022&nbs=
p;   
> root@ROXY:/usr/obj/usr/src/amd64.amd=
64/sys/ROXY amd64
> 
> 
> 
> 
<=
/div>
> 
> 
> 
> Dear Sir I had the followin=
g error while trying to compile CURRENT=3D=3D=3D> usr.bin/rs (all)
> make[4]: /usr/obj/usr/src/amd64.amd64/usr.bin/rs/=
.depend.rs.o, 1: ignoring stale .depend for /usr/src/usr.bin/rs/rs.c
> cc -target x86_64-unknown-freebsd14.0 --sysroot=3D=
/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin=
  -O2 -pipe -fno-common   -fPIE -g -gz=3Dzlib -MD  -MF.=
depend.rs.o -MTrs.o -std=3Dgnu99 -Wno-format-zero-length -fstack-protector-=
strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parame=
ter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type =
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-ali=
gn -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-s=
ign -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-=
body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=3Dunused-bu=
t-set-variable  -Qunused-arguments    -c /usr/src/usr.b=
in/rs/rs.c -o rs.o
> *** Error code 1
> 
> Stop.
> make[4]: stopped in /usr/src/usr.bin/rs
> *** Error code 1
> 
> Stop.
> make[3]: stopped in=
 /usr/src/usr.bin
> *** Error code 1
=

> 
> Stop.
> make[2]: stopped in /usr/src
>=
 *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/src
=

> *** Error code 1
>=
 
> Stop.
> make:=
 stopped in /usr/src

H=
ave you tried to wipe /usr/obj (or at least:
/usr=
/obj/usr/src/amd64.amd64/usr.bin/rs/)?

=

--
Herbert


            

        

------=_Part_5432258_1356685440.1671024153529--

From nobody Wed Dec 14 13:28:58 2022
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 4NXGRN06tmz4kckX
	for ; Wed, 14 Dec 2022 13:29:04 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic306-21.consmr.mail.ne1.yahoo.com (sonic306-21.consmr.mail.ne1.yahoo.com [66.163.189.83])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NXGRM1R2wz4Rs1
	for ; Wed, 14 Dec 2022 13:29:03 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=DfrGi0vM;
	spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.189.83 as permitted sender) smtp.mailfrom=filippomore@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671024542; bh=zSeyEOA7HY3j5o8ew9EE7nJ3DVQhi3XdB4L9VCqvAR0=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=DfrGi0vM8qKTkCJCYWamuJ3MKQ7bTGayvShUe2icTZCppsuOGcOZI2+SoNUzUFEia+nRrAhWY7gXg9pXSyH7aVcPbGj4tTYMqaYE7R3cFdT+KJ+wHBHaNyhT+cd0TcPx0Tjx1DB7ZXLTgNLtK1RWmEsFz++ovcAw0aIk8hMwIZr7sHGN1t+MQZP767tmEA/TeZbC8yBdRbN498BK5FEVWJaIYx+X2cx/og2HMbvcWtnSQs7pcShHhfc0IPs3tjnAKrDBpsgBN3//cevrFkdB0V4CFTOLS3Imk0PiKSML+s+1fGhCVCz9Ha6rUuZmfomJ6c9GaPX1IBT78vqqAf6tMg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671024542; bh=38AEtFQC9fB0DRPY7aco3t1/vcCNIOy+dSgILLY9epJ=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=mkupOt2Yl144lZyHuJlkNnybv0HpBs1x4Q5AyfR7Flj6s/7XG9aQa+QFUZe9LmRNdoVDaQRYuktEl+qf8geCSJrJnAojqlK6poaUXZFonHQhU+8eP/EIWBlkITuXCYdthZBFQZbgjglf6e1KYMoDIb+BGNlgtMebbZ9k2xKhHdXCJEo3IcO24r+kdnPkjyerguzUOm/yw+hnR207lDkCoNy6Dlt8rYsrMhYY9Ajnei1g+4oP/6GuA517d4Rl1v0Y9or9hD1tn4nsk67V28ACKK42cs/pI7PCdhmPk9cbv8GDivBcyRMESCcLqK4727U0dHXGEJ84nLZPZw1xe99lmQ==
X-YMail-OSG: 5J9wnFgVM1kdUo6ELBugGfneQOt9e5R3H.Y5tzRQenmeVv8_RK4NOjR9pHBCGzo
 Vq5a.NbeCzvNnLELrrP1QsZP_2yfyTQDlRmZUpHKhHvQJqKVfonYU.pgNElf53AmfPEbX1EBsjWv
 id4bIqZUgJM5Tj2vTZJrEe4WQfSAn966tm4F0PrRJ_weS4bF7Q2YTUpzcn9zCjSeTxorkhXOfjqH
 GpON3s5HAXb524LC7.KcGpEnWOYDX.0nUTQkYJO1.8jvX.0rjLAPIN7jOqg6_sZxEOncQpTlZ4eZ
 hjHUI3DWDNI0A9SSAiAUqC0qyjQu.IvK2QWDCWTLBFBOTt38wYzdM21PJVC8uj34f.htkzIR4W0J
 jKTNkzyTbTnCdVIMR2p1IuFf1SUSrAWCTSCdU.PZY6zcD59z61afzIeqqNoQBnhdEPhWXCNNDrUF
 Ax6vUcuUHurksJ0crdOPGMQBToiDh7N_z.ZFDpMQc5RCzKp55nXXEwbOZdD6weWPS8m92hZW6DDP
 Vlfv3Of7XyjcDWZF2xwVf7Xdt2T8bGxrfqn.bGsEVHjtHgV2skIqB_Y_SK54D8ITTT.pV3F2dy7k
 4JilV.jZTCTHvFf.lh1AX.2iRdYzNaXz57NcGzXIUm0ewRWOOB_Wev7FIZ7uEQtgaYxgnRub1ceQ
 g5.UY_UbZ9nWO8ScUGOsmnODrhiFegyd7KlpNPzmhsrbFBRLSB2Uflj.x_.ZgyJ1UHKnYCYDc4YJ
 WZJHs_ersHb01P1M5JNV1Xggiqvp34_LC6imD9Vt__KAzEGqLKyvZr3WBTrIorG1efh3IhGNRqjV
 WCw0JijwYlojRE4bRgFt2Url4xD7sH80bcb9pKwd21Ehq47TsgJ_Jq5DLVcLM0bWXn5dUo2B1NTV
 o.y.l15mcpbRBnkOaJ0_F15vLCLv6SOWgJJQZ0vXgQLs.pjT.VgwNUE9DdHemxNwc7SgtyYh8dHg
 XKmgHfGdYZKDBW_7tlK80bnXz_8kvG7BA6HdMc8kFyhEf.EC4VJ85jtwT_LXeNTe6y_zSNRL7e9q
 CHjIdEOcmTEC0eFq1g_6dK1c4yx7dWpKBnM1NxDC_oJgH01z_7Was8aYDN_hRp9EP5D.VkAuUS5o
 FadUaaPPVb6R48zCjpxauU4AYigujuWbAVGb94WX5mCAeKvFCOAD.uWmNgFG8fWx4qNpN63hXL.V
 fzxtLkeGE1SG3fDgrUeHAbUJf9NeR3IETY9Y_ScvekeY.TKAGITzZnRqtmQ88jRMod.Qr.FAeuCt
 U0gWgFReXLWy4G4mdBxSbwQ4Y9G1r5gcbxHZrpYYuxpQIVwCPiaugqnhX_73sP.tBRKVEtUec3Fd
 z5Tk4LGUFJt06wPKva1_B9MIngECGtVH6TpmgI1AsfsPCGZ3U3yhBngsrVnYeCx_oIbSiYvttPha
 DabLc.FT_mIhfjCBMQAFcL8x72uvYizpZ2CwQ2gBoTjlVka0toXMkP.ObAtRSQD_OBASCIERPbRC
 VGSKio1JS1hWcy_6QwvmJQs9FqU3xXVO8lF_CBZIaA8VAR6HDEXEO1eJ92xidGCXKcDYRAomGAWc
 q2XnZCcT_DDDtLeJuVPJIEkIhRao6wY_mWJLxQk4KUw4pjqy_l7x0AoRhMjhtut6a5sVbIF0Wez8
 gPMhVNKn157t0lwKoN6U4kccuym_pccuOUdJmYK4QvaUMIPK6Bw8ajaxiVexThzhB0yCq0MCW5A4
 g8RLkD4Sbei_.enZStJI6lMeHwbvCOuqR2W2eNgtvjnkRTVjbwRFg2eiLvzH2QM2XH4os.dbaE2w
 BschoMHy_ZPEsID1jhMKxbFpmFjPzmlUMN5SV_iN4vhbkKZYgzfoqa7wlHvLBjgrXhYJ89dVDEbK
 7aV8YS9T_LyplVoSiBFgNIvDJ8O4oFTQZPI6NVVkUPiowz69AOqnOosgrd..gNjmFobncKPYjgFE
 r9eRKqGaE_XpskST1f3ULMZ_UnKqgXAC1htJ79xCJiPusncXN8.ugab8wfhIea.CoW.T9PZT2ZqB
 f3LUdDKPyRbP_l4GRoflZ9nyAzuq6m_sKlgjfwoXjjVOOlWkMNkSBGwezMNzPuF7SRTM6Sips3Np
 mZxU4.EfiDE4UgGqPtpa7g4oCldGuZgRxA_rSrksLmAP25GielatOtoQb9rHzPzPfQEmfcADtCPk
 FQPkNLUvDefKnuvXP4vkDdOwZsJ9h3ok3FRbBR4BgRCzfS3RkiA_2WnywzkEi9w66n_pTOxavKk0
 55xjQokurRg--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Wed, 14 Dec 2022 13:29:02 +0000
Date: Wed, 14 Dec 2022 13:28:58 +0000 (UTC)
From: Filippo Moretti 
To: "current@freebsd.org" , 
	"Herbert J. Skuhra" 
Message-ID: <1714019869.869016.1671024538469@mail.yahoo.com>
In-Reply-To: <1228071193.5432259.1671024153530@mail.yahoo.com>
References: <1498874308.5423541.1671023281171.ref@mail.yahoo.com> <1498874308.5423541.1671023281171@mail.yahoo.com> <87pmcmt98g.wl-herbert@gojira.at> <1228071193.5432259.1671024153530@mail.yahoo.com>
Subject: Re: Problem compiling CURRENT
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_869015_419176896.1671024538467"
X-Mailer: WebService/1.1.20926 YMailNorrin
X-Spamd-Result: default: False [-3.90 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.90)[-0.904];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[current@freebsd.org];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[66.163.189.83:from];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCPT_COUNT_TWO(0.00)[2];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	TO_DN_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-Rspamd-Queue-Id: 4NXGRM1R2wz4Rs1
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_869015_419176896.1671024538467
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 I deleted /usr/obj and restarted world I will see tomorrow the outcome.Fil=
ippo

    On Wednesday, December 14, 2022 at 02:22:57 PM GMT+1, Filippo Moretti <=
filippomore@yahoo.com> wrote: =20
=20
 =20
I downloaded src for current on 13/12 11.20 CEST.I did have the same issues=
 for about 5 days I made a few attempts all whit same error.Filippo
    On Wednesday, December 14, 2022 at 02:18:20=E2=80=AFPM GMT+1, Herbert J=
. Skuhra  wrote: =20
=20
 On Wed, 14 Dec 2022 14:08:01 +0100, Filippo Moretti wrote:
>=20
> FreeBSD ROXY 14.0-CURRENT FreeBSD 14.0-CURRENT #4
> main-n258255-de56ac88099: Wed Sep 28 19:35:24 CEST 2022=C2=A0=C2=A0=C2=A0=
=C2=A0
> root@ROXY:/usr/obj/usr/src/amd64.amd64/sys/ROXY amd64
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> Dear Sir I had the following error while trying to compile CURRENT=3D=3D=
=3D> usr.bin/rs (all)
> make[4]: /usr/obj/usr/src/amd64.amd64/usr.bin/rs/.depend.rs.o, 1: ignorin=
g stale .depend for /usr/src/usr.bin/rs/rs.c
> cc -target x86_64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/src/amd64.=
amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin=C2=A0 -O2 -pipe -fno-c=
ommon=C2=A0=C2=A0 -fPIE -g -gz=3Dzlib -MD=C2=A0 -MF.depend.rs.o -MTrs.o -st=
d=3Dgnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers=
 -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes=
 -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-str=
ings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -W=
nested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmissi=
ng-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-i=
nt -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable=C2=A0 -Q=
unused-arguments=C2=A0=C2=A0=C2=A0 -c /usr/src/usr.bin/rs/rs.c -o rs.o
> *** Error code 1
>=20
> Stop.
> make[4]: stopped in /usr/src/usr.bin/rs
> *** Error code 1
>=20
> Stop.
> make[3]: stopped in /usr/src/usr.bin
> *** Error code 1
>=20
> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
>=20
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>=20
> Stop.
> make: stopped in /usr/src

Have you tried to wipe /usr/obj (or at least:
/usr/obj/usr/src/amd64.amd64/usr.bin/rs/)?

--
Herbert

   =20
------=_Part_869015_419176896.1671024538467
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



        
I deleted /usr/obj and resta=
rted world I will see tomorrow the outcome.
Filippo


       =20
        

            

               =20
                

                    On Wednesday, December 14, 2022 at 02:22:57 PM GMT+1, F=
ilippo Moretti <filippomore@yahoo.com> wrote:
                

                


                


                

        

I downloaded src for=
 current on 13/12 11.20 CEST.I did have the same issues for about 5 days I =
made a few attempts all whit same error.
Filippo

       =20
        

            

               =20
                

                    On Wednesday, December 14, 2022 at 02:18:20=E2=80=AFPM =
GMT+1, Herbert J. Skuhra <herbert@gojira.at> wrote:
                

                


                


                
On Wed, 14 Dec 2022 14:08:01 +0100, F=
ilippo Moretti wrote:
> 
> FreeBSD ROXY 14.0-CURRENT FreeBSD 1=
4.0-CURRENT #4
> main-n258255-d=
e56ac88099: Wed Sep 28 19:35:24 CEST 2022    
> root@ROXY:/usr/obj/usr/src/amd64.amd64/sys/ROXY amd64
> 
> 
> 
> 
> 
> 
> 
>=
 Dear Sir I had the following error while trying to compile CURRENT=3D=3D=
=3D> usr.bin/rs (all)
> make=
[4]: /usr/obj/usr/src/amd64.amd64/usr.bin/rs/.depend.rs.o, 1: ignoring stal=
e .depend for /usr/src/usr.bin/rs/rs.c
> cc -target x86_64-unknown-freebsd14.0 --sysroot=3D/usr/obj/usr/sr=
c/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pip=
e -fno-common   -fPIE -g -gz=3Dzlib -MD  -MF.depend.rs.o -MT=
rs.o -std=3Dgnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem=
-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pr=
ototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Ww=
rite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subsc=
ripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time=
 -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-strin=
g-plus-int -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable&=
nbsp; -Qunused-arguments    -c /usr/src/usr.bin/rs/rs.c -o r=
s.o
> *** Error code 1
> 
> Stop.
> make[4]: stop=
ped in /usr/src/usr.bin/rs
> **=
* Error code 1
> 
> Stop.
> make[3]: stopped in /usr/src/usr.bin
> *** Error code 1
> 
> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
> 
>=
; Stop.
> make: stopped in /usr=
/src

Have you tried to wipe /usr/obj (or at least:
/usr/obj/usr/src/amd64.amd64/usr.bin/rs/)?

--
Herbert


            

        

            

        

------=_Part_869015_419176896.1671024538467--

From nobody Wed Dec 14 17:14:31 2022
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 4NXMRk3DDfz4k5wn
	for ; Wed, 14 Dec 2022 17:14:42 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NXMRh71Czz3QCq
	for ; Wed, 14 Dec 2022 17:14:40 +0000 (UTC)
	(envelope-from junchoon@dec.sakura.ne.jp)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp;
	dmarc=none
Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210])
	(authenticated bits=0)
	by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2BEHEVaD014329
	for ; Thu, 15 Dec 2022 02:14:31 +0900 (JST)
	(envelope-from junchoon@dec.sakura.ne.jp)
Date: Thu, 15 Dec 2022 02:14:31 +0900
From: Tomoaki AOKI 
To: freebsd-current@freebsd.org
Subject: Re: What to do about a few lines in vfs_domount() never executed?
Message-Id: <20221215021431.d190e55ee911f5e94799f953@dec.sakura.ne.jp>
In-Reply-To: 
References: 
Organization: Junchoon corps
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-0.35 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	AUTH_NA(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.75)[-0.752];
	MV_CASE(0.50)[];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[sakura.ne.jp];
	HAS_ORG_HEADER(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NXMRh71Czz3QCq
X-Spamd-Bar: /
X-ThisMailContainsUnwantedMimeParts: N

Tracking the commits, it was originally introduced to
sys/kern/vfs_syscalls.c at r22521 [1][2] (Mon Feb 10 02:22:35 1997 by
dyson, submitted by hsu@freebsd.org) and later centralized into
sys/kern/vfs_mount.c at r99264 [2].

But according to the comment above the codes, maybe it would be
intended to block userland programs or ports FS modules setting 
MNT_EXPORTED.

If I'm not mis-understanding, it can be the case when
 *vfs.usermount sysctl is non-zero,
 *underlying FS (to be exported) allows it, and
 *non-root user tries to mount the FS via NFS.


[1]
https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?revision=22521&view=markup&pathrev=99264

[2]
https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?r1=22520&r2=22521&pathrev=99264&

[3]
https://cgit.freebsd.org/src/commit/sys/kern/vfs_mount.c?id=2b4edb69f1ef62fc38b02ac22b0a3ac09e43fa77


On Tue, 13 Dec 2022 14:19:39 -0800
Rick Macklem  wrote:

> Hi,
> 
> While working on getting mountd/nfsd to run in a vnet
> prison, I came across the following lines near the
> beginning of vfs_domount() in sys/kern/vfs_mount.c:
> 
> if (fsflags & MNT_EXPORTED) {
>      error = priv_check(td, PRIV_VFS_MOUNT_EXPORTED);
>      if (error)
>            return (error);
> }
> 
> #1 - Since MNT_EXPORTED is never set in fsflags, this code never
>      gets executed.
>      --> I am asking what to do with the above code, since that
>          changes for the patch that allows mountd to run in a vnet
>          prison.
> #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always returns 0
>      because nothing in sys/kern/kern_priv.c checks
>      PRIV_VFS_MOUNT_EXPORTED.
> 
> I don't know what the original author's thinking was w.r.t. this.
> Setting exports already checks that the mount operation can be
> done by the requestor.
> 
> So, what do you think should be done with the above code snippet?
> - Consider it cruft and delete it.
> - Try and figure out what PRIV_VFS_MOUNT_EXPORTED should check?
> - Leave it as is. After the patch that allows mountd to run in
>   a vnet prison, MNT_EXPORTED will be set in fsflags, but the
>   priv_check() call will just return 0. (A little overhead,
>   but otherwise no semantics change.)
> 
> rick


-- 
Tomoaki AOKI    

From nobody Wed Dec 14 20:18:23 2022
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 4NXRWq09wtz4kT5S
	for ; Wed, 14 Dec 2022 20:18:31 +0000 (UTC)
	(envelope-from verm@darkbeer.org)
Received: from mx.coeval.ca (mx.coeval.ca [184.75.211.21])
	(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 4NXRWp0H3Yz43GR
	for ; Wed, 14 Dec 2022 20:18:29 +0000 (UTC)
	(envelope-from verm@darkbeer.org)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=darkbeer.org header.s=mail header.b=p6f3vVkc;
	spf=pass (mx1.freebsd.org: domain of verm@darkbeer.org designates 184.75.211.21 as permitted sender) smtp.mailfrom=verm@darkbeer.org;
	dmarc=none
Received: from mx.darkbeer.org (unknown [192.168.211.20])
	by mx.coeval.ca (Postfix) with ESMTP id A8C8143605D
	for ; Wed, 14 Dec 2022 20:18:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbeer.org; s=mail;
	t=1671049103; bh=tyLTA6MGFcOcCfx2CeVCgBYjhkxQQ9UNrcIKxejrlZk=;
	h=Date:From:To:Subject:References:In-Reply-To;
	b=p6f3vVkcCrGkxHGH3YQCdGj+/S56vxXqNSfktNJoW8WD8gp1o0evMVIsLNfP3CoBG
	 WaBEfD2u0Z1mPOawumU+uJa6MQvsTOImGtct7gbhLWm0kazDlAfMFsUWn0YZ0J3v3l
	 42P3T6R0sK3g/tvxUgSy09Kv9b+2B92e1YQ+S/oA=
Received: by mx.darkbeer.org (Postfix, from userid 1001)
	id A1FE5470BFC; Wed, 14 Dec 2022 20:18:23 +0000 (UTC)
Date: Wed, 14 Dec 2022 20:18:23 +0000
From: Amar Takhar 
To: freebsd-current@freebsd.org
Subject: Re: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Message-ID: <20221214201823.GA843@darkbeer.org>
Mail-Followup-To: freebsd-current@freebsd.org
References: 
 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:184.75.211.21];
	R_DKIM_ALLOW(-0.20)[darkbeer.org:s=mail];
	MIME_GOOD(-0.10)[text/plain];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	DKIM_TRACE(0.00)[darkbeer.org:+];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[darkbeer.org];
	ARC_NA(0.00)[];
	ASN(0.00)[asn:32489, ipnet:184.75.211.0/24, country:CA];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_ONE(0.00)[1];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NXRWp0H3Yz43GR
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On 2022-11-14 09:09 +0200, Konstantin Belousov wrote:
>
> You might use this patch meantime
> https://kib.kiev.ua/git/gitweb.cgi?p=deviant3.git;a=commit;h=5d72240a8777b26d5e0a7d2d26bb919d05f60002

Thank you for this patch.  On my 13.1 machine it fixed all the panics with a
i9-12900KF.  It's nice to be able to use all the cores since I got this machine 
in May.  I had them disabled in BIOS.

Also as a side note this fixed the audio issues I was having with the e cores 
both enabled and disabled.

  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263385


Thanks again!


Amar.

From nobody Wed Dec 14 22:04:12 2022
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 4NXTt52LhSz4kgvJ
	for ; Wed, 14 Dec 2022 22:04:29 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NXTt50LJ3z4GX9
	for ; Wed, 14 Dec 2022 22:04:29 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pl1-x631.google.com with SMTP id g10so4814285plo.11
        for ; Wed, 14 Dec 2022 14:04:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=o3UIUFfrWJ/E6HRwkThNEl8XnU/EDOT7LIZHL+HunHg=;
        b=LurmaW9Uli4TlKxIbS+j7o0BR89ioKuu65H24GCdTtARXz65dWZW3fVHX4QBzmiEcc
         4xt9eWml7sg7MUZ4lHAVMfz0fh2jIcbr96VEcUdQnsUEcZ6ocaCsludjJc90I+874Xou
         8BBZJMGLyMSjiam3cpwdk4H45Yawy0YAIJgY866AdVPcY0Vg1t1er5DLCsftPvbGzw9H
         gaZbPZop/1l5e1MvwS/oy4bCNUeGoK7BHGh3M+60Y7poLEJ9PD7Q/M8xcvObFenbPrLH
         KUR4OowLz4oIe77SnNeRB2BXVT+JUqWar6m8Tyi2sE0E0+1h6z9j+ZpbFccCK5ZHZgMQ
         rrMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=o3UIUFfrWJ/E6HRwkThNEl8XnU/EDOT7LIZHL+HunHg=;
        b=fHzS9fL+ihIoSUM5483c5JCZco2ohn7uC6jEIshHEZpjDyDzwX1Zd/wrnBneo+XQG/
         74qB1GDZugiyEzda113s2lGjajGFCb0hUyUFeSK+rWBJAmNOUp9pm9NiYXoVxO9PHrQr
         4F3r2q+khHEjMS3jC8laASNKN3X6F/ZvdGK/DbJVVrgwC+ELIzJC0zUPaGwUBSNYj4K7
         cm25mimxgELfpV30mKu7MGWPPrS/0eVr3xwYyndvObjEw2wYcU4cmQbBpK31LYV06WKE
         kZ4qhxcTP7JliBtjJjJ+3U+1i846yJnlYZRsh8sVZVve7x2SICbFLGXPksXJGioOHMSZ
         ibNg==
X-Gm-Message-State: ANoB5pllfw2xRy1COrsuzg8kxtai5GNe6FDMPIOq3na3/IuW4za+QSMR
	LE3j0KQDnEc53y/fWN39DydSfOCtXvVUqoeXvedEjhQY5g==
X-Google-Smtp-Source: AA0mqf70yjZkfeY8dQfPieVdzsrOmqj2jo9PvdUDeTGDml1+NbDafZhNV4fqdKiMO00KM3+bPmVSyGXC7kNAi3nYGD0=
X-Received: by 2002:a17:90a:ad09:b0:219:5079:7aa3 with SMTP id
 r9-20020a17090aad0900b0021950797aa3mr356744pjq.183.1671055466959; Wed, 14 Dec
 2022 14:04:26 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 <20221215021431.d190e55ee911f5e94799f953@dec.sakura.ne.jp>
In-Reply-To: <20221215021431.d190e55ee911f5e94799f953@dec.sakura.ne.jp>
From: Rick Macklem 
Date: Wed, 14 Dec 2022 14:04:12 -0800
Message-ID: 
Subject: Re: What to do about a few lines in vfs_domount() never executed?
To: Tomoaki AOKI 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000008216dc05efd0eb0b"
X-Rspamd-Queue-Id: 4NXTt50LJ3z4GX9
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--0000000000008216dc05efd0eb0b
Content-Type: text/plain; charset="UTF-8"

On Wed, Dec 14, 2022 at 9:15 AM Tomoaki AOKI 
wrote:

> Tracking the commits, it was originally introduced to
> sys/kern/vfs_syscalls.c at r22521 [1][2] (Mon Feb 10 02:22:35 1997 by
> dyson, submitted by hsu@freebsd.org) and later centralized into
> sys/kern/vfs_mount.c at r99264 [2].
>
> But according to the comment above the codes, maybe it would be
> intended to block userland programs or ports FS modules setting
> MNT_EXPORTED.
>
> If I'm not mis-understanding, it can be the case when
>  *vfs.usermount sysctl is non-zero,
>  *underlying FS (to be exported) allows it, and
>  *non-root user tries to mount the FS via NFS.
>
It does appear that ancient code restricted doing NFS exports
to root only.
I don't think that restriction is exactly enforced now, since
vfs_suser() allows a non-root owner to do the update (which
would include updating exports).
(As I noted, MNT_EXPORTED never gets set in fsflags. The variable
 is local to one of the functions in vfs_mount.c and a search shows
 it never gets set.)

I suppose you could argue that priv_check(td,  PRIV_VFS_MOUNT_EXPORTED)
should check for caller being root, since that is what ancient code did.
Or, you could argue that, if a non-root user is allowed to mount a file
system that they should also be allowed to export it, which is what I
think the current code allows (and has for at least a decade).

Admittedly, allowing a non-root user to do a mount and also add exports
to it could cause confusion, since the system basically assumes that
mountd will manage all exports.

Do others think adding code to check that cr_uid == 0 for
PRIV_VFS_MOUNT_EXPORTED to be allowed makes sense?

rick



>
> [1]
>
> https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?revision=22521&view=markup&pathrev=99264
>
> [2]
>
> https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?r1=22520&r2=22521&pathrev=99264&
>
> [3]
>
> https://cgit.freebsd.org/src/commit/sys/kern/vfs_mount.c?id=2b4edb69f1ef62fc38b02ac22b0a3ac09e43fa77
>
>
> On Tue, 13 Dec 2022 14:19:39 -0800
> Rick Macklem  wrote:
>
> > Hi,
> >
> > While working on getting mountd/nfsd to run in a vnet
> > prison, I came across the following lines near the
> > beginning of vfs_domount() in sys/kern/vfs_mount.c:
> >
> > if (fsflags & MNT_EXPORTED) {
> >      error = priv_check(td, PRIV_VFS_MOUNT_EXPORTED);
> >      if (error)
> >            return (error);
> > }
> >
> > #1 - Since MNT_EXPORTED is never set in fsflags, this code never
> >      gets executed.
> >      --> I am asking what to do with the above code, since that
> >          changes for the patch that allows mountd to run in a vnet
> >          prison.
> > #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always returns 0
> >      because nothing in sys/kern/kern_priv.c checks
> >      PRIV_VFS_MOUNT_EXPORTED.
> >
> > I don't know what the original author's thinking was w.r.t. this.
> > Setting exports already checks that the mount operation can be
> > done by the requestor.
> >
> > So, what do you think should be done with the above code snippet?
> > - Consider it cruft and delete it.
> > - Try and figure out what PRIV_VFS_MOUNT_EXPORTED should check?
> > - Leave it as is. After the patch that allows mountd to run in
> >   a vnet prison, MNT_EXPORTED will be set in fsflags, but the
> >   priv_check() call will just return 0. (A little overhead,
> >   but otherwise no semantics change.)
> >
> > rick
>
>
> --
> Tomoaki AOKI    
>
>

--0000000000008216dc05efd0eb0b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Dec 14, 2022 at 9:15 AM Tomoaki AOKI =
<junchoon@dec.sakura.ne.jp<=
/a>> wrote:
T=
racking the commits, it was originally introduced to

sys/kern/vfs_syscalls.c at r22521 [1][2] (Mon Feb 10 02:22:35 1997 by

dyson, submitted by hs=
u@freebsd.org) and later centralized into

sys/kern/vfs_mount.c at r99264 [2].



But according to the comment above the codes, maybe it would be

intended to block userland programs or ports FS modules setting 

MNT_EXPORTED.



If I'm not mis-understanding, it can be the case when

=C2=A0*vfs.usermount sysctl is non-zero,

=C2=A0*underlying FS (to be exported) allows it, and

=C2=A0*non-root user tries to mount the FS via NFS.
It does appear =
that ancient code restricted doing NFS exports
to root only.
I don&=
#39;t think that restriction is exactly enforced now, since
vfs_suser()=
 allows a non-root owner to do the update (which
would include updating=
 exports).
(As I noted, MNT_EXPORTED never gets set in fsflags. The var=
iable
=C2=A0is local to one of the functions in vfs_mount.c and a searc=
h shows
=C2=A0it never gets set.)

I suppose you could argu=
e that priv_check(td, =C2=A0PRIV_VFS_MOUNT_EXPORTED)
should check for caller =
being root, since that is what ancient code did.
Or, you could argue th=
at, if a non-root user is allowed to mount a file
system that they shou=
ld also be allowed to export it, which is what I
think the current code=
 allows (and has for at least a decade).

Admittedly, allowing =
a non-root user to do a mount and also add exports
to it could cause co=
nfusion, since the system basically assumes that
mountd will manage all=
 exports.

Do others think adding code to check that cr_uid =3D=
=3D 0 for
PRIV_VFS_MOUNT_EXPORTED to be allowed makes sense?

rick







[1]

https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c=
?revision=3D22521&view=3Dmarkup&pathrev=3D99264



[2]

https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?r1=
=3D22520&r2=3D22521&pathrev=3D99264&



[3]

https://cgit.freebsd.org/src/commit/sys/kern/vfs_mount.c?id=3D2b4edb69f1e=
f62fc38b02ac22b0a3ac09e43fa77





On Tue, 13 Dec 2022 14:19:39 -0800

Rick Macklem <rick.macklem@gmail.com> wrote:



> Hi,

> 

> While working on getting mountd/nfsd to run in a vnet

> prison, I came across the following lines near the

> beginning of vfs_domount() in sys/kern/vfs_mount.c:

> 

> if (fsflags & MNT_EXPORTED) {

>=C2=A0 =C2=A0 =C2=A0 error =3D priv_check(td, PRIV_VFS_MOUNT_EXPORTED);=


>=C2=A0 =C2=A0 =C2=A0 if (error)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return (error);

> }

> 

> #1 - Since MNT_EXPORTED is never set in fsflags, this code never

>=C2=A0 =C2=A0 =C2=A0 gets executed.

>=C2=A0 =C2=A0 =C2=A0 --> I am asking what to do with the above code,=
 since that

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 changes for the patch that allows mo=
untd to run in a vnet

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 prison.

> #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always returns 0

>=C2=A0 =C2=A0 =C2=A0 because nothing in sys/kern/kern_priv.c checks

>=C2=A0 =C2=A0 =C2=A0 PRIV_VFS_MOUNT_EXPORTED.

> 

> I don't know what the original author's thinking was w.r.t. th=
is.

> Setting exports already checks that the mount operation can be

> done by the requestor.

> 

> So, what do you think should be done with the above code snippet?

> - Consider it cruft and delete it.

> - Try and figure out what PRIV_VFS_MOUNT_EXPORTED should check?

> - Leave it as is. After the patch that allows mountd to run in

>=C2=A0 =C2=A0a vnet prison, MNT_EXPORTED will be set in fsflags, but th=
e

>=C2=A0 =C2=A0priv_check() call will just return 0. (A little overhead,<=
br>
>=C2=A0 =C2=A0but otherwise no semantics change.)

> 

> rick





-- 

Tomoaki AOKI=C2=A0 =C2=A0 <junchoon@dec.sakura.ne.jp>






--0000000000008216dc05efd0eb0b--

From nobody Thu Dec 15 00:00:07 2022
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 4NXXRW6GPzz4kvMS;
	Thu, 15 Dec 2022 00:00:07 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NXXRW4m9Dz3DLD;
	Thu, 15 Dec 2022 00:00:07 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1671062407;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=NHCrH3emcgUifmhNrGK5KqcfJlPpV/HJ5UClcPRnW20=;
	b=MyaLeE2NjIoxeYRIDJrsbaDkcL1F++31V9UdCFyiUurQa6ZK/7OxY2q/l8pDomrJFzFSgX
	/1kUe0KP7V4dc6Ls8RKGGSZ3DWXhsVp49hqN/xFoYAQedJABCaEwfCJl1ChhPGiZsynKXp
	uXOybQnnsx0uaHsyl46o2BgmwXQK/BIKK87Cf/LCvHXalx2toAF7xtNh7IDdfcGYdyJi8U
	OQC+Ttn4wD62iXOkgGKK8ngzhZQr2vafKVLFjxp/Ddspur6nXgaeQJgeqmmkt4CO9JM0zw
	utAPwSRchLcTVnCrzeyKnYFVtvj/se+xPPz4LFZXJ6WUJGjfoW5OF/JqyGgP8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1671062407;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=NHCrH3emcgUifmhNrGK5KqcfJlPpV/HJ5UClcPRnW20=;
	b=R2ppKQJNd/U3d9Vzo9KxA4VJfye9HM1eYkADr42vJI5BdeurIc217u+aW+emBRNYQlMwm8
	de2Dk5daMDVK9B2entc7Yt0qLWGEGGiTYwfJvqJlbUTtxmi0Ab8frcQlm2BU51JoWQXd9Q
	MlxLKUnAVAakwNBYL/OpiMHBesly+mEcLD8RrOQ5OEfGE5eyqcUQTW6rs7TkUb7a/z2VIX
	GJBXeT24uWjpBu3lyG5nHwqHIeibSjwxcFflL4yxIcfIDI2KyvIAmKm+lggioCxbBKqLSV
	6Z/G0be50pKLwBH980PdfQrBrkbupN0fLLIfx3lEF+wWjuUKVidWPf7PvLkp5A==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1671062407; a=rsa-sha256; cv=none;
	b=UfI6XBOv0Pvad2WB7yfniCM6gc7KyDdC0Ppd6YXJJbUx8FyTVLvObChXAhvSCol8DB+PwM
	Hs2RFrNJn4jvgsJRb1Ct8exHPadraCypHjVgts5uIYs26Ga1LCFPB/cdBtOG4IIobv2f22
	c7Ybsy1IX5906ubn2QeuS5JH3LefiF3saJqBOaExrRhbttNWHJLzwwFjDYS9XE7gyQWw9j
	3FUzqc7O3XjDDALvx7U4Ic4HXozMXXjvqf+bjnooVxx0McIhtUmNGIsuCQ7gMJAEsq2W9k
	oF4/kT61neDT5aDX+lfu9lGY4bkT/N3uimm9dGZYG4SspihYRAMGLxs+lr9rWg==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id 4A92EADB6; Thu, 15 Dec 2022 00:00:07 +0000 (UTC)
To: freebsd-quarterly-calls@FreeBSD.org
Subject: [2 WEEKS LEFT REMINDER] Call for 2022Q4 quarterly status reports
Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org
Message-Id: <20221215000007.4A92EADB6@freefall.freebsd.org>
Date: Thu, 15 Dec 2022 00:00:07 +0000 (UTC)
From: Lorenzo Salvadore 
X-ThisMailContainsUnwantedMimeParts: N
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

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
December, 31st 2022 for work done since the last round of Quarterly Reports:
October 2022 - December 2022.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the AsciiDoctor template, fill it in, and
email it to quarterly-submissions@FreeBSD.org.
The new AsciiDoctor template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc

We look forward to seeing your 2022Q4 reports!

Thanks,

Lorenzo Salvadore (on behalf of quarterly@)

From nobody Thu Dec 15 00:42:47 2022
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 4NXYP427bqz4l0s6
	for ; Thu, 15 Dec 2022 00:43:04 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NXYP32BcCz3Jp4
	for ; Thu, 15 Dec 2022 00:43:03 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=qlrCqzSr;
	spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::62e as permitted sender) smtp.mailfrom=rick.macklem@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pl1-x62e.google.com with SMTP id l10so5184111plb.8
        for ; Wed, 14 Dec 2022 16:43:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=AEA2BUpfluP6ogZx8bDAfse1XGuAkoud8hvOsYE9MwU=;
        b=qlrCqzSrt5wbhAN1AWsBDTyJta/w9pnZfX7tL5Q+OgYf3JhtzcKt/DF9MLOSkwsB/F
         BwzRVg9fa6u7Rhm0U6ocCyYsi9gogGPqo3eYHtYGbdT2JTrV0p5KW1x/tJ7tNWDsQAXj
         HtFfFUP1J7w9j7ZO4HN5HKuDwq5WkBNZYX76/Rg0lI6rs3TIQVkuF6C0SI2IHhLtbVih
         9bf+5zn3K8yK+7SXeLoIkEe4fs78AMwydKShiIZQQHrkPRf1dp0Ll+RPM0YIpggv8oJd
         NuaPc3YYuhGTyMMl3KIasWHmyp19QJ0NdNVSYRb57zdywgvbwWZGwlmD1jKie8gYBNRh
         xCgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=AEA2BUpfluP6ogZx8bDAfse1XGuAkoud8hvOsYE9MwU=;
        b=ahE2RClibL7R9QnDvkpa0YVmJpS3FDgbgy15iGCRdkQm6dvWkhtRD+WLNRAyND5Kpf
         iIUbtjpqxcrwNIAEIT38nKltEgyc+i9xAMoM/0oY87z/ma08atNmTQILNKuf0Zp2ionY
         5tVWl9EjQTGEf6uvbKucPmkTAds3gYBgZZDqV8DlKo7r1hWNxSQzPd9mYrHNJhJ+fXNu
         gOWh/2Uw2FvCeb2ZXhHMcnCmRbuDJbeKxvAsfdJ03GzR0FQtfQgSj2XC8852IESQcI5A
         nZuWNL3oSS+YAvZwrCd3GI+55w3CxnmBTcy3ScCSAexSIoKHr7++SExsDABpjP+2WSqM
         jMJQ==
X-Gm-Message-State: ANoB5plXBlIpWsFCcl9HVuqYsBrFzRhgI48yNtD+t18SUTO/PCVH5+mH
	LG1tqXE7V3/gNKv6K8RrHzi4bkxtKUWy3SPPPwFcBaQnmw==
X-Google-Smtp-Source: AA0mqf64zSVZSZ7YhTyqlAsredcMuKUOrNPgG6XTsFXtryGcSkNHANtiQmEzIs66mJ3zPiNWmZjCBNGXcyIOLs9zLks=
X-Received: by 2002:a17:902:d585:b0:189:9fb2:2541 with SMTP id
 k5-20020a170902d58500b001899fb22541mr44704449plh.60.1671064982203; Wed, 14
 Dec 2022 16:43:02 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 <20221215021431.d190e55ee911f5e94799f953@dec.sakura.ne.jp> 
In-Reply-To: 
From: Rick Macklem 
Date: Wed, 14 Dec 2022 16:42:47 -0800
Message-ID: 
Subject: Re: What to do about a few lines in vfs_domount() never executed?
To: Tomoaki AOKI 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000a92fe205efd322f6"
X-Spamd-Result: default: False [-2.70 / 15.00];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-0.88)[-0.879];
	NEURAL_HAM_SHORT(-0.82)[-0.817];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::62e:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TAGGED_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NXYP32BcCz3Jp4
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--000000000000a92fe205efd322f6
Content-Type: text/plain; charset="UTF-8"

On Wed, Dec 14, 2022 at 2:04 PM Rick Macklem  wrote:

>
>
> On Wed, Dec 14, 2022 at 9:15 AM Tomoaki AOKI 
> wrote:
>
>> Tracking the commits, it was originally introduced to
>> sys/kern/vfs_syscalls.c at r22521 [1][2] (Mon Feb 10 02:22:35 1997 by
>> dyson, submitted by hsu@freebsd.org) and later centralized into
>> sys/kern/vfs_mount.c at r99264 [2].
>>
>> But according to the comment above the codes, maybe it would be
>> intended to block userland programs or ports FS modules setting
>> MNT_EXPORTED.
>>
>> If I'm not mis-understanding, it can be the case when
>>  *vfs.usermount sysctl is non-zero,
>>  *underlying FS (to be exported) allows it, and
>>  *non-root user tries to mount the FS via NFS.
>>
> It does appear that ancient code restricted doing NFS exports
> to root only.
>
It looks like the semantics change was introduced when mountd
as converted to nmount() { r158857 about 17years ago }.
The code in vfs_mount.c assumed that MNT_EXPORTED was set in the
argument passed in from mountd.c when it called nmount(), but
that was not the case.
--> As such, the check was not performed.

The check was for suser() until r164033 when it was replaced
by priv_check(td, PRIV_VFS_MOUNT_EDPORTED).
--> This does the same thing, failing if cr_uid != 0.

So, I think the snippet was supposed to enforce "only root
can set exports", but the check has not worked post r158857
because MNT_EXPORTED was never set in fsflags.
(nmount() uses the "export" option.)

So, should I set MNT_EXPORTED in fsflags when nmount()
has specified the "export" option and restore the
"must be root to export" check?

rick
ps: Thanks Tomoaki AOKI for looking at the old code and
     spotting this.

> I don't think that restriction is exactly enforced now, since
> vfs_suser() allows a non-root owner to do the update (which
> would include updating exports).
> (As I noted, MNT_EXPORTED never gets set in fsflags. The variable
>  is local to one of the functions in vfs_mount.c and a search shows
>  it never gets set.)
>
> I suppose you could argue that priv_check(td,  PRIV_VFS_MOUNT_EXPORTED)
> should check for caller being root, since that is what ancient code did.
> Or, you could argue that, if a non-root user is allowed to mount a file
> system that they should also be allowed to export it, which is what I
> think the current code allows (and has for at least a decade).
>
> Admittedly, allowing a non-root user to do a mount and also add exports
> to it could cause confusion, since the system basically assumes that
> mountd will manage all exports.
>
> Do others think adding code to check that cr_uid == 0 for
> PRIV_VFS_MOUNT_EXPORTED to be allowed makes sense?
>
> rick
>
>
>
>>
>> [1]
>>
>> https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?revision=22521&view=markup&pathrev=99264
>>
>> [2]
>>
>> https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?r1=22520&r2=22521&pathrev=99264&
>>
>> [3]
>>
>> https://cgit.freebsd.org/src/commit/sys/kern/vfs_mount.c?id=2b4edb69f1ef62fc38b02ac22b0a3ac09e43fa77
>>
>>
>> On Tue, 13 Dec 2022 14:19:39 -0800
>> Rick Macklem  wrote:
>>
>> > Hi,
>> >
>> > While working on getting mountd/nfsd to run in a vnet
>> > prison, I came across the following lines near the
>> > beginning of vfs_domount() in sys/kern/vfs_mount.c:
>> >
>> > if (fsflags & MNT_EXPORTED) {
>> >      error = priv_check(td, PRIV_VFS_MOUNT_EXPORTED);
>> >      if (error)
>> >            return (error);
>> > }
>> >
>> > #1 - Since MNT_EXPORTED is never set in fsflags, this code never
>> >      gets executed.
>> >      --> I am asking what to do with the above code, since that
>> >          changes for the patch that allows mountd to run in a vnet
>> >          prison.
>> > #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always returns 0
>> >      because nothing in sys/kern/kern_priv.c checks
>> >      PRIV_VFS_MOUNT_EXPORTED.
>> >
>> > I don't know what the original author's thinking was w.r.t. this.
>> > Setting exports already checks that the mount operation can be
>> > done by the requestor.
>> >
>> > So, what do you think should be done with the above code snippet?
>> > - Consider it cruft and delete it.
>> > - Try and figure out what PRIV_VFS_MOUNT_EXPORTED should check?
>> > - Leave it as is. After the patch that allows mountd to run in
>> >   a vnet prison, MNT_EXPORTED will be set in fsflags, but the
>> >   priv_check() call will just return 0. (A little overhead,
>> >   but otherwise no semantics change.)
>> >
>> > rick
>>
>>
>> --
>> Tomoaki AOKI    
>>
>>

--000000000000a92fe205efd322f6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Dec 14, 2022 at 2:04 PM Rick Macklem =
<rick.macklem@gmail.com>=
; wrote:

<=
/div>
O=
n Wed, Dec 14, 2022 at 9:15 AM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote=
:
Tracking the c=
ommits, it was originally introduced to

sys/kern/vfs_syscalls.c at r22521 [1][2] (Mon Feb 10 02:22:35 1997 by

dyson, submitted by hs=
u@freebsd.org) and later centralized into

sys/kern/vfs_mount.c at r99264 [2].



But according to the comment above the codes, maybe it would be

intended to block userland programs or ports FS modules setting 

MNT_EXPORTED.



If I'm not mis-understanding, it can be the case when

=C2=A0*vfs.usermount sysctl is non-zero,

=C2=A0*underlying FS (to be exported) allows it, and

=C2=A0*non-root user tries to mount the FS via NFS.
It does appear =
that ancient code restricted doing NFS exports
to root only.
It looks like the semantics change was introduced when m=
ountd
as converted to nmount() { r158857 about 17years ago }.
The c=
ode in vfs_mount.c assumed that MNT_EXPORTED was set in the
argument pa=
ssed in from mountd.c when it called nmount(), but
that was not the cas=
e.
--> As such, the check was not performed.

The check =
was for suser() until r164033 when it was replaced
by priv_check(td, PR=
IV_VFS_MOUNT_EDPORTED).
-->=C2=A0This does the same thing, failing if cr_u=
id !=3D 0.

So, I think the snippet was supposed to enforce &qu=
ot;only root
can set exports", but the check has not worked post r=
158857
because MNT_EXPORTED was never set in fsflags.
=
(nmount() use=
s the "export" option.)

So, should I set MNT_EXPORTE=
D in fsflags when nmount()
has specified the "export" option =
and restore the
"must be root to export" check?
<=
div>
=
rick
ps: Thanks Tomoaki AOKI for looking at the old code and
=C2=A0=
 =C2=A0 =C2=A0spotting this.
I don't think =
that restriction is exactly enforced now, since
vfs_suser() allows a no=
n-root owner to do the update (which
would include updating exports).
(As I noted, MNT_EXPORTED never gets set in fsflags. The variable=

=
=C2=A0is local to one of the functions in vfs_mount.c and a search shows
=C2=A0it never gets set.)

I suppose you could argue that pri=
v_check(td, =C2=A0PRIV_VFS_MOUNT_EXPORTED)
should check for caller being root=
, since that is what ancient code did.
Or, you could argue that, if a n=
on-root user is allowed to mount a file
system that they should also be=
 allowed to export it, which is what I
think the current code allows (a=
nd has for at least a decade).

Admittedly, allowing a non-root=
 user to do a mount and also add exports
to it could cause confusion, s=
ince the system basically assumes that
mountd will manage all exports.<=
/span>

Do others think adding code to check that cr_uid =3D=3D 0 for<=
/span>
PRIV_VFS_MOUNT_EXPORTED to be allowed makes sense?

rick







[1]

https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c=
?revision=3D22521&view=3Dmarkup&pathrev=3D99264



[2]

https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?r1=
=3D22520&r2=3D22521&pathrev=3D99264&



[3]

https://cgit.freebsd.org/src/commit/sys/kern/vfs_mount.c?id=3D2b4edb69f1e=
f62fc38b02ac22b0a3ac09e43fa77





On Tue, 13 Dec 2022 14:19:39 -0800

Rick Macklem <rick.macklem@gmail.com> wrote:



> Hi,

> 

> While working on getting mountd/nfsd to run in a vnet

> prison, I came across the following lines near the

> beginning of vfs_domount() in sys/kern/vfs_mount.c:

> 

> if (fsflags & MNT_EXPORTED) {

>=C2=A0 =C2=A0 =C2=A0 error =3D priv_check(td, PRIV_VFS_MOUNT_EXPORTED);=


>=C2=A0 =C2=A0 =C2=A0 if (error)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return (error);

> }

> 

> #1 - Since MNT_EXPORTED is never set in fsflags, this code never

>=C2=A0 =C2=A0 =C2=A0 gets executed.

>=C2=A0 =C2=A0 =C2=A0 --> I am asking what to do with the above code,=
 since that

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 changes for the patch that allows mo=
untd to run in a vnet

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 prison.

> #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always returns 0

>=C2=A0 =C2=A0 =C2=A0 because nothing in sys/kern/kern_priv.c checks

>=C2=A0 =C2=A0 =C2=A0 PRIV_VFS_MOUNT_EXPORTED.

> 

> I don't know what the original author's thinking was w.r.t. th=
is.

> Setting exports already checks that the mount operation can be

> done by the requestor.

> 

> So, what do you think should be done with the above code snippet?

> - Consider it cruft and delete it.

> - Try and figure out what PRIV_VFS_MOUNT_EXPORTED should check?

> - Leave it as is. After the patch that allows mountd to run in

>=C2=A0 =C2=A0a vnet prison, MNT_EXPORTED will be set in fsflags, but th=
e

>=C2=A0 =C2=A0priv_check() call will just return 0. (A little overhead,<=
br>
>=C2=A0 =C2=A0but otherwise no semantics change.)

> 

> rick





-- 

Tomoaki AOKI=C2=A0 =C2=A0 <junchoon@dec.sakura.ne.jp>








--000000000000a92fe205efd322f6--

From nobody Fri Dec 16 21:07:20 2022
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 4NYhWT2zR4zZddr
	for ; Fri, 16 Dec 2022 21:07:33 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NYhWS48YBz3xtV
	for ; Fri, 16 Dec 2022 21:07:32 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="Mm/89ufI";
	spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::629 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pl1-x629.google.com with SMTP id l10so3496087plb.8
        for ; Fri, 16 Dec 2022 13:07:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=CfAUDc7pHuMEMfDvij+TeDql4BbKQLaKyaccqSIGRVY=;
        b=Mm/89ufI/fGjqRNF04JlmFqAw/PFn0JSGwEy9s2PZqy25l0QcjK9NwB+hu4Hgopzrw
         u0JvhzOttifr0VrfL2avn3AAC+GDBYGQEbXKQ7RBL/+SsGlPgcYHh6vUyltiWM0VGr+b
         6oZ7MwiPazLIgUOF7bTAY8bIISbTyyEr2uU72zWdivnX2kDDO+r+YTTA6YoRdlJlS6y0
         lKL2IOv47IRmaubp+T41s/rTGk2uao7juHwgS7SX+5O6JQgBklcPM7UooFu5BUlHohfG
         aK4hFBqwo2ULLtrIJ8mexOtvy1NMFidUYB5CYIzV9o5U3QYID8P3v3Ue+t7a3va90hM8
         TbuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=CfAUDc7pHuMEMfDvij+TeDql4BbKQLaKyaccqSIGRVY=;
        b=4nmTC4w6vi/xYfqS6IjB67dMxBpSKwYMtc2Nv1e9VHWAtyIkx2BC2xRExkPcjE/4+q
         7bah0PmMtxGuQbwRZD4l+SmFZqbN+PnZTrs8ecUhFRgWxuRII2t8WtFbIHpX82fwfIhi
         ErDYfcvEISfxmfp//gZ9MbZOaiZKIYZ1qK4o7buskHAJbUNOYO7fPvdnVWRX9uZad4ut
         a21s3xgbzbubRZfQMJKl+e8EPZ5BAOlBhytBFH3ZTbiTTpnpYbrhJDB6wBNEPKOkOKD/
         6k9/8PxKqmUV0Oy0fbxpRBol6sTI8nKRg6P85wHk0BodixOCWSxOoiJapn4G6I6Xllf/
         QM4A==
X-Gm-Message-State: AFqh2koH7yKfinpgr7AzZvKvQ3Mj8HMfwqctzkuUiiL4XgZ2cRWMXx3M
	WOTqsUxT9Xsr2lmnHSaWHf8nhnR2Ck+VoKRGiW5lkvGzCg==
X-Google-Smtp-Source: AA0mqf5/pQcoEic58w7X8xBFgfeQgH7UDpEdjWek44EmSwOC7pr3YJ2t4QzI/6yvyo0o4vjRGPfQcF3DIhX5JHkULDw=
X-Received: by 2002:a17:90a:7e0a:b0:219:661f:9916 with SMTP id
 i10-20020a17090a7e0a00b00219661f9916mr1367132pjl.200.1671224851196; Fri, 16
 Dec 2022 13:07:31 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 <20221215021431.d190e55ee911f5e94799f953@dec.sakura.ne.jp>
In-Reply-To: <20221215021431.d190e55ee911f5e94799f953@dec.sakura.ne.jp>
From: Rick Macklem 
Date: Fri, 16 Dec 2022 13:07:20 -0800
Message-ID: 
Subject: Re: What to do about a few lines in vfs_domount() never executed?
To: Tomoaki AOKI 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000098712405eff85bb9"
X-Spamd-Result: default: False [-3.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	SUBJECT_ENDS_QUESTION(1.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::629:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	TAGGED_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NYhWS48YBz3xtV
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

--00000000000098712405eff85bb9
Content-Type: text/plain; charset="UTF-8"

Just to provide closure on this, I just committed a patch to
main (that will be MFC'd in 2 weeks) that sets MNT_EXPORTED
when the "export" option is specified to nmount(2).

This restores the "only root can do exports" semantics that
appear to have been the case pre-r158857.

Thanks everyone for your comments, rick


On Wed, Dec 14, 2022 at 9:15 AM Tomoaki AOKI 
wrote:

> Tracking the commits, it was originally introduced to
> sys/kern/vfs_syscalls.c at r22521 [1][2] (Mon Feb 10 02:22:35 1997 by
> dyson, submitted by hsu@freebsd.org) and later centralized into
> sys/kern/vfs_mount.c at r99264 [2].
>
> But according to the comment above the codes, maybe it would be
> intended to block userland programs or ports FS modules setting
> MNT_EXPORTED.
>
> If I'm not mis-understanding, it can be the case when
>  *vfs.usermount sysctl is non-zero,
>  *underlying FS (to be exported) allows it, and
>  *non-root user tries to mount the FS via NFS.
>
>
> [1]
>
> https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?revision=22521&view=markup&pathrev=99264
>
> [2]
>
> https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?r1=22520&r2=22521&pathrev=99264&
>
> [3]
>
> https://cgit.freebsd.org/src/commit/sys/kern/vfs_mount.c?id=2b4edb69f1ef62fc38b02ac22b0a3ac09e43fa77
>
>
> On Tue, 13 Dec 2022 14:19:39 -0800
> Rick Macklem  wrote:
>
> > Hi,
> >
> > While working on getting mountd/nfsd to run in a vnet
> > prison, I came across the following lines near the
> > beginning of vfs_domount() in sys/kern/vfs_mount.c:
> >
> > if (fsflags & MNT_EXPORTED) {
> >      error = priv_check(td, PRIV_VFS_MOUNT_EXPORTED);
> >      if (error)
> >            return (error);
> > }
> >
> > #1 - Since MNT_EXPORTED is never set in fsflags, this code never
> >      gets executed.
> >      --> I am asking what to do with the above code, since that
> >          changes for the patch that allows mountd to run in a vnet
> >          prison.
> > #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always returns 0
> >      because nothing in sys/kern/kern_priv.c checks
> >      PRIV_VFS_MOUNT_EXPORTED.
> >
> > I don't know what the original author's thinking was w.r.t. this.
> > Setting exports already checks that the mount operation can be
> > done by the requestor.
> >
> > So, what do you think should be done with the above code snippet?
> > - Consider it cruft and delete it.
> > - Try and figure out what PRIV_VFS_MOUNT_EXPORTED should check?
> > - Leave it as is. After the patch that allows mountd to run in
> >   a vnet prison, MNT_EXPORTED will be set in fsflags, but the
> >   priv_check() call will just return 0. (A little overhead,
> >   but otherwise no semantics change.)
> >
> > rick
>
>
> --
> Tomoaki AOKI    
>
>

--00000000000098712405eff85bb9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Just to provide closure on this, I just committed a patch to
main (that will be M=
FC'd in 2 weeks) that sets MNT_EXPORTED
when the "export" option is sp=
ecified to nmount(2).

This restores the "only root can do exports" semantics t=
hat
appea=
r to have been the case pre-r158857.

Thanks everyone for your comments, rick


=

On Wed, De=
c 14, 2022 at 9:15 AM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
Tracking the commits, it was originally i=
ntroduced to

sys/kern/vfs_syscalls.c at r22521 [1][2] (Mon Feb 10 02:22:35 1997 by

dyson, submitted by hs=
u@freebsd.org) and later centralized into

sys/kern/vfs_mount.c at r99264 [2].



But according to the comment above the codes, maybe it would be

intended to block userland programs or ports FS modules setting 

MNT_EXPORTED.



If I'm not mis-understanding, it can be the case when

=C2=A0*vfs.usermount sysctl is non-zero,

=C2=A0*underlying FS (to be exported) allows it, and

=C2=A0*non-root user tries to mount the FS via NFS.





[1]

https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c=
?revision=3D22521&view=3Dmarkup&pathrev=3D99264



[2]

https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?r1=
=3D22520&r2=3D22521&pathrev=3D99264&



[3]

https://cgit.freebsd.org/src/commit/sys/kern/vfs_mount.c?id=3D2b4edb69f1e=
f62fc38b02ac22b0a3ac09e43fa77





On Tue, 13 Dec 2022 14:19:39 -0800

Rick Macklem <rick.macklem@gmail.com> wrote:



> Hi,

> 

> While working on getting mountd/nfsd to run in a vnet

> prison, I came across the following lines near the

> beginning of vfs_domount() in sys/kern/vfs_mount.c:

> 

> if (fsflags & MNT_EXPORTED) {

>=C2=A0 =C2=A0 =C2=A0 error =3D priv_check(td, PRIV_VFS_MOUNT_EXPORTED);=


>=C2=A0 =C2=A0 =C2=A0 if (error)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return (error);

> }

> 

> #1 - Since MNT_EXPORTED is never set in fsflags, this code never

>=C2=A0 =C2=A0 =C2=A0 gets executed.

>=C2=A0 =C2=A0 =C2=A0 --> I am asking what to do with the above code,=
 since that

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 changes for the patch that allows mo=
untd to run in a vnet

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 prison.

> #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always returns 0

>=C2=A0 =C2=A0 =C2=A0 because nothing in sys/kern/kern_priv.c checks

>=C2=A0 =C2=A0 =C2=A0 PRIV_VFS_MOUNT_EXPORTED.

> 

> I don't know what the original author's thinking was w.r.t. th=
is.

> Setting exports already checks that the mount operation can be

> done by the requestor.

> 

> So, what do you think should be done with the above code snippet?

> - Consider it cruft and delete it.

> - Try and figure out what PRIV_VFS_MOUNT_EXPORTED should check?

> - Leave it as is. After the patch that allows mountd to run in

>=C2=A0 =C2=A0a vnet prison, MNT_EXPORTED will be set in fsflags, but th=
e

>=C2=A0 =C2=A0priv_check() call will just return 0. (A little overhead,<=
br>
>=C2=A0 =C2=A0but otherwise no semantics change.)

> 

> rick





-- 

Tomoaki AOKI=C2=A0 =C2=A0 <junchoon@dec.sakura.ne.jp>






--00000000000098712405eff85bb9--

From nobody Mon Dec 19 16:59:48 2022
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 4NbQtV64x2z1GCFX
	for ; Mon, 19 Dec 2022 17:00:02 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NbQtT63gmz3lp2;
	Mon, 19 Dec 2022 17:00:01 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=ZTHAWOzm;
	spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::1031 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pj1-x1031.google.com with SMTP id o12so9692619pjo.4;
        Mon, 19 Dec 2022 09:00:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=UZPhz2y24L89bdRjaLOY+mG3dNf9gz03ZS4p8wkVXuw=;
        b=ZTHAWOzmr1SoXwwr0EUCRxk5rDEvJJbmo5IgcSZs8D+vV9cdOYLrriu5bU1271nKfS
         W4S/VS4FxPe4LiREKNUU2/xFriJTW1WCsZt+fBj5CK/L+7jrkinQu3lpXxfekA1InRky
         l4eNgQZTqIJvP7EIslCUxnR2+fo5fbW8Ng/TAq9uQT8LiIyW+STVJee+ciX/v/k2CAcW
         IMLLtotl/1rWg4hSTddaJmRIhm8p/S/at0XmILgf+Lf4NnPe3RB4pF4i7TuFYPpY0lce
         YIR1KdduSGu2lv1sE8dD5lmh/w9MJESxjkL46KUCNhjh/Myu9+xnnkgfr3bAQNzqR5bz
         oU2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=UZPhz2y24L89bdRjaLOY+mG3dNf9gz03ZS4p8wkVXuw=;
        b=mrgBEFSVEYGY1DjRjd4xmEOfYOk3xCerbG/kwJNTm7nyWQxraShU6IKqfzK8M7t+3a
         ub1UO+PqHL2vFeiJNQQuGg9fPWHqzs2Jx2lt7i0ve7YHE1r2WU8QyKUOqokMoII3zxca
         wxqBWhLohe7FUGp4hLfmLDYxbKHuaFZVbcpcmq0C3CQ+n2boPSrh6gJw+ja27LGrlT2g
         gpMW3eO2fH4GhruDuZC3xf1GRmpb5TwLYIafAJVjP8p5fKWjIZ2aXneC50lwelsLs+Is
         zOLD8soGW0RzlClcA/q9SU+35wv7iWKBuKfcZQvZ53xFqh7cRfJwy8C/xFisvTKzx3lY
         MaXw==
X-Gm-Message-State: AFqh2kp71pufdR3u9gMOt1ETzY8BBV63n84xORGow1KnP8eDFEC6A0UN
	T5YKGDKNZwVzPXYloIfHAUSXDZcieZkpdRh6daA2KEu2AQ==
X-Google-Smtp-Source: AMrXdXvlywA29vutbe+6LDn/MBZSjm8D9XtkxAt/74YEUuygNh79/8HFCBvw1cO7YpYKz3CUaorpk2H6VnmXmfgZL2A=
X-Received: by 2002:a17:902:d488:b0:191:8cb:fbe6 with SMTP id
 c8-20020a170902d48800b0019108cbfbe6mr678600plg.60.1671469199878; Mon, 19 Dec
 2022 08:59:59 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 <1955021.aDjkhKmpDe@ravel> 
 <8351812.Gc231LQI4k@ravel> 
In-Reply-To: 
From: Rick Macklem 
Date: Mon, 19 Dec 2022 08:59:48 -0800
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: kib@freebsd.org, James Gritton , "Bjoern A. Zeeb" 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000e96d9105f0313fba"
X-Spamd-Result: default: False [-3.99 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.989];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1031:from];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	TAGGED_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_SOME(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NbQtT63gmz3lp2
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e96d9105f0313fba
Content-Type: text/plain; charset="UTF-8"

Hi,

Kostik expressed some concern w.r.t. using a non-default VNET_NFSD kernel
build option and I understand his concern, given that many prefer to use
a GENERIC kernel and binary updates.

Right now there are 29 NFS variables VNET_DEFINED() and several of them
are arrays currently sized at 500. One of the reasons for the non-default
VNET_NFSD kernel option was the bloat this caused to the vnet.
(Chris  expressed concern that adding mountd/nfsd
 to the vnet would result in bloat/overhead in a previous post to this
 thread.)

Another issue with putting all these variables in the vnet is that the
nfsd.ko
cannot be loaded (it complains the vnet is out of space) and, as such,
options NFSD must be used with VNET_NFSD so that the nfsd is linked into the
kernel.

As such, I am wondering what others think of this alternate plan?
- Pull all the VNET_DEFINE()'d variable (except the 3 manipulated by
sysctls)
  into a structure.
- Define a single VNET_DEFINE()'d variable that is a pointer to that
structure
  and then malloc() the structure in the function called by VNET_SYSINIT().
This would result in a malloc'd structure for each vnet jail (for kernels
built with VMIMAGE), but would only add 4 variables to the vnet.

If a small C file that only consists of the VNET_DEFINE()s for the 4
variables
is linked into the kernel whenever the VIMAGE option is specified, then I
think nfsd.ko would be loadable.

Unfortunately, this does not deal with vnet'ng the kgssapi, rpcsec_gss for
Kerberized mounts or vnet'ng NFS-over-TLS, but those could be handled in a
similar manner, I think?

So, what do others think of this alternate plan?

rick
ps: Every use of the vnet'd variables is currently wrapped in a macro called
    NFSD_VNET(), so the change is pretty easy to do by just re-writing this
macro.

--000000000000e96d9105f0313fba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,
Kostik=
 expressed some concern w.r.t. using a non-default VNET_NFSD kernel
build option and=
 I understand his concern, given that many prefer to use
a GENERIC kernel and binary=
 updates.

Rig=
ht now there are 29 NFS variables VNET_DEFINED() and several of them
<=
div class=3D"gmail_default" style=3D"font-family:monospace">are arrays curr=
ently sized at 500. One of the reasons for the non-default
VNET_NFSD kernel option =
was the bloat this caused to the vnet.
(Chris <bsd-lists@bsdforge.com> expressed concern that adding mountd=
/nfsd
=C2=
=A0to the vnet would result in bloat/overhead in a previous post to this
=C2=A0threa=
d.)

<=
/div>
Another i=
ssue with putting all these variables in the vnet is that the nfsd.ko
=

cannot be load=
ed (it complains the vnet is out of space) and, as such,
options NFSD must be used w=
ith VNET_NFSD so that the nfsd is linked into the
kernel.

As such, I am wondering what others thi=
nk of this alternate plan?
- Pull all the VNET_DEFINE()'d variable (except the 3=
 manipulated by sysctls)
=C2=A0 into a structure.
- Define a single VNET_DEFINE()'d varia=
ble that is a pointer to that structure
=C2=A0 and then malloc() the structure in th=
e function called by VNET_SYSINIT().
This would result in a malloc'd structure f=
or each vnet jail (for kernels
built with VMIMAGE), but would only add 4 variables t=
o the vnet.

I=
f a small C file that only consists of the VNET_DEFINE()s for the 4 variabl=
es
is lin=
ked into the kernel whenever the VIMAGE option is specified, then I
think nfsd.ko wo=
uld be loadable.

Unfortunately, this does not deal with vnet'ng the kgssapi, rpcsec_=
gss for
K=
erberized mounts or vnet'ng NFS-over-TLS, but those could be handled in=
 a
simila=
r manner, I think?

So, what do others think of this alternate plan?

rick
ps: Every use of the vnet'd varia=
bles is currently wrapped in a macro called
=C2=A0 =C2=A0 NFSD_VNET(), so the change=
 is pretty easy to do by just re-writing this macro.



--000000000000e96d9105f0313fba--

From nobody Mon Dec 19 17:36:05 2022
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 4NbRhF27Qjz1GHst
	for ; Mon, 19 Dec 2022 17:36:13 +0000 (UTC)
	(envelope-from bz@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NbRhF1WMRz3r3p;
	Mon, 19 Dec 2022 17:36:13 +0000 (UTC)
	(envelope-from bz@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1671471373;
	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=Dvd+MjyYG9IflkJ0jedPAYfa+HlZHgCRoVoEOvjgaV8=;
	b=ou87nnGn5reYjXPN7NiAbUuatQ4q9gI4NO1dwSqL0WAWgFOr2bQIY5p/O9XvO1tI9EbVup
	u0WSCauKToHQZ97nxtXMSJ+2ki+JebLu5eSgkitKXsK7py1WAJzuIjPTMcFgaK2YFJjp6O
	xY8au6i6ulnji2OArCH0JURg56tMmJnXXGvwSP4sHA1mHHMANtuNMX0n2gTGCyNCVTRPOf
	juwPjK5eoQNxLDlGe+oN+pwnaQGskIY/E3i+qEvhvmIm7QAsd8XHT65XvIINhfgGyLI0Ez
	kx7e0UuEQFhsWUjCU8sXweQkOIk3lpS2UcsiLZn/B5Cc5yeemF5UtU3w+rGQTQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1671471373;
	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=Dvd+MjyYG9IflkJ0jedPAYfa+HlZHgCRoVoEOvjgaV8=;
	b=d00DRuM9cSLc2VOkcSN1+NSzjDxNCprUgmRzHlvW9ySlxXPaUQFVBS184c4V5e8yByuNzh
	CmrfUmFW5K2L+ZuiWQbdkieXrts/bYAEo0ipRRQyBp+mJZjr4YOIs33vqBEhPn1nKytgGW
	/66VvS6tIXvSJrl1tYexUf+oosjzVinwKMXJMg+R9Ng8aVIObrU5Z3vsnyLTNlxrboSSC0
	KKsDFwMilZc+IqzjG564Q+3BjZQUS8Kk/yW1DxQggJwbrhMYqCiC5y8hgyHoAoMe2Tt26J
	oXhPpJhac3vbSAu3pWMVLlGlipxzkimcJtxJeo/nMc1ciHTUR5pArG/LCC07Jw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1671471373; a=rsa-sha256; cv=none;
	b=Ek6SayBUHApADMhDFSIFELjno1abCZpd++BhjjLxFytZ1ep+RroxYhACKwoHBoxnZqZAJQ
	lfM/Gkm+99dlVmLci7I2kJdsldI6PgHCDEmrADH26sYUIv+IE4hq5MSItnAV1R7qm6sJWO
	lxc0AecixGu6cKmlh7Tlvnif+jlgdz7WLweKZtbPtp2HX0uVJohle+XJTJu3eS76yTk1s8
	1GqWpyA7iRSO9lnODSAcb42+XgpRq1VvzGLoevnYS/QNOtfZEJydg3XEuL5g4bbJjDM7A1
	k5GWEmbVDkkoyFZ2O61jQ7UwTv9aTGpcnMdSanCcOLyxFI2fGfHMpeYPkijwjQ==
Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified))
	(Authenticated sender: bz/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NbRhD6yppzl9M;
	Mon, 19 Dec 2022 17:36:12 +0000 (UTC)
	(envelope-from bz@freebsd.org)
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mx1.sbone.de (Postfix) with ESMTPS id 8BC5F8D4A142;
	Mon, 19 Dec 2022 17:36:10 +0000 (UTC)
Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPS id 2A5E25C3A876;
	Mon, 19 Dec 2022 17:36:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024)
	with ESMTP id b_L558xNkaDe; Mon, 19 Dec 2022 17:36:05 +0000 (UTC)
Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPSA id 8F6045C3A833;
	Mon, 19 Dec 2022 17:36:05 +0000 (UTC)
Date: Mon, 19 Dec 2022 17:36:05 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: Rick Macklem 
cc: Konstantin Belousov , James Gritton , 
    freebsd-current@freebsd.org
Subject: Re: RFC: nfsd in a vnet jail
In-Reply-To: 
Message-ID: 
References:  <1955021.aDjkhKmpDe@ravel>  <8351812.Gc231LQI4k@ravel> 
 
X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-ThisMailContainsUnwantedMimeParts: N

On Mon, 19 Dec 2022, Rick Macklem wrote:

> Hi,
>
> Kostik expressed some concern w.r.t. using a non-default VNET_NFSD kernel
> build option and I understand his concern, given that many prefer to use
> a GENERIC kernel and binary updates.

yes, I may have hinted towards that (at least in my mind) during looking
at the review.

There is a reason that (at least for now) I do like having it.
Personally (due to lack of time mostly) I haven't figured out if I would
want this to be a vnfs one day or part of vnet.  The earlier (like the
kernel option) could more easily address possible security concerns to
people (especially while this is a moving target with more possibly
coming later).

Hence me having asked for a dedicated macro not mangling with the VNET
macros directly in place as this gives us a lot of flexibility to easily
move this around in the future if we wanted to.

Removing the option will make the code simpler.


> Right now there are 29 NFS variables VNET_DEFINED() and several of them
> are arrays currently sized at 500. One of the reasons for the non-default
> VNET_NFSD kernel option was the bloat this caused to the vnet.
> (Chris  expressed concern that adding mountd/nfsd
> to the vnet would result in bloat/overhead in a previous post to this
> thread.)
>
> Another issue with putting all these variables in the vnet is that the
> nfsd.ko
> cannot be loaded (it complains the vnet is out of space) and, as such,
> options NFSD must be used with VNET_NFSD so that the nfsd is linked into the
> kernel.
>
> As such, I am wondering what others think of this alternate plan?
> - Pull all the VNET_DEFINE()'d variable (except the 3 manipulated by
> sysctls)
>  into a structure.
> - Define a single VNET_DEFINE()'d variable that is a pointer to that
> structure
>  and then malloc() the structure in the function called by VNET_SYSINIT().
> This would result in a malloc'd structure for each vnet jail (for kernels
> built with VMIMAGE), but would only add 4 variables to the vnet.
>
> If a small C file that only consists of the VNET_DEFINE()s for the 4
> variables
> is linked into the kernel whenever the VIMAGE option is specified, then I
> think nfsd.ko would be loadable.

It is not the number of variables added that is a problem; it is (as you
point out above) their size which is a problem.

So 500 uint8_t variables are as expensive as 1 uint8_t[500];

There's only a "small" allocated per-vnet to replicate state for
modules.

Multicast also had that problem needing huge junks and we eventually
switched to malloc to fix this and make the module loadable as well
again.  (See 1a117215c7f90e6ef8c50ef3bfe099490aaa98f9 for one of the
changes -- I think I scrwed somehting up there about sizing so probably
follow-ups but it'll show the concept).

So wether you make this one huge malloc or multiple small ones for the
few big variables is up to you in the end.  I also wonder what is easier
to deal with "vnet0/prison0/'nfs0-bits'" as NFS_ROOT and other parts
will need some of these things eventually to be in place early one for
the base.

Also sysctl and malloc and virtualisation can be a bit tricky.

The "common" theme would be to only malloc the complex data types but
leave the simple type variables being normal virtualised ones.


> Unfortunately, this does not deal with vnet'ng the kgssapi, rpcsec_gss for
> Kerberized mounts or vnet'ng NFS-over-TLS, but those could be handled in a
> similar manner, I think?

Could be, yes.


> So, what do others think of this alternate plan?
>
> rick
> ps: Every use of the vnet'd variables is currently wrapped in a macro called
>    NFSD_VNET(), so the change is pretty easy to do by just re-writing this
> macro.
>

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Tue Dec 20 23:12:40 2022
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 4NcC650QdXz1HJgX
	for ; Tue, 20 Dec 2022 23:12:45 +0000 (UTC)
	(envelope-from zseri.devel+fbsd@ytrizja.de)
Received: from ytrizja.de (ytrizja.de [138.201.154.11])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NcC641HXzz3N8y
	for ; Tue, 20 Dec 2022 23:12:44 +0000 (UTC)
	(envelope-from zseri.devel+fbsd@ytrizja.de)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=ytrizja.de header.s=2020 header.b=iXMMDvdN;
	spf=pass (mx1.freebsd.org: domain of zseri.devel+fbsd@ytrizja.de designates 138.201.154.11 as permitted sender) smtp.mailfrom=zseri.devel+fbsd@ytrizja.de;
	dmarc=pass (policy=reject) header.from=ytrizja.de
Message-ID: <91c3d49d-5d69-8c04-0269-908f31689748@ytrizja.de>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ytrizja.de; s=2020;
	t=1671577961;
	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=YVCbA81w+sDm5X+2yzdNGTNYvOr8dGkDo876KXhcrxE=;
	b=iXMMDvdNCAWPRFe1cWsSwLVzaqDLwr0dQp13Pvd6VyTc5p6uNlXfKzBiNMYEj0IxtZaeXt
	Qq25CLdgkxCANsLSSxc6Qnmo5WE18Nkut2X7oS3M578aP3hTSmQtLslqZOz7+doyysURbU
	BZMGWucyBo/cqNxygKPppejHp+7WyrJLLqIR8OI1wR4hVr0sMCWAI/0DufFtg49DL4g367
	auIuvKAbSGRGpYTEtn9gQeeEq6wG14Rs5UVBcAv/pfyU5TvM1plbRHOU2rodnKqB8By177
	hAGxJ+0QhtP6BLc6XLlPtU35uUIJAilbdrOHxH9CZdqAh+q/+iB8bCj/ovYTnQ==
Date: Wed, 21 Dec 2022 00:12:40 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Language: en-US
To: freebsd-current@FreeBSD.org
From: Alain Zscheile 
Subject: all_subdir_lib/libclang_rt build failure (libc++ ld error)
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.997];
	DMARC_POLICY_ALLOW(-0.50)[ytrizja.de,reject];
	R_SPF_ALLOW(-0.20)[+mx:c];
	R_DKIM_ALLOW(-0.20)[ytrizja.de:s=2020];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_ZERO(0.00)[0];
	ASN(0.00)[asn:24940, ipnet:138.201.0.0/16, country:DE];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TAGGED_FROM(0.00)[fbsd];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[ytrizja.de:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NcC641HXzz3N8y
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hello,

I encountered a build failure while trying to build fbsd'
src.git commit ae521fda895ff0b5076904f08ec92e3c60d53701
with `make -j4 buildworld` on an FreeBSD 13.1 system.


--- all_subdir_lib/libclang_rt ---
ld: error: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc++.so:2:
   cannot find /usr/lib/libc++.so.1 inside
   /usr/obj/usr/src/amd64.amd64/tmp
>>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )
>>>         ^
c++: error: linker command failed with exit code 1
   (use -v to see invocation)

make[2]: stopped in /usr/src


The stated file is indeed not present, and resides in .../tmp/lib
instead of .../tmp/usr/lib. It appears that the .so linker script
should either be patched (to point to /lib instead of /usr/lib) or
a symlink for the .so.1 file should be created.
(at least the corresponding c++ command line doesn't indicate
  anything to the contrary of that afaik)

I don't know when this problem was introduced and it might be the
case that this bootstrapping problem only occurs when the "outside
system" (in this case FreeBSD 13.1) has an older version of clang.
(as I'm not really sure when the bootstrapping process actually
  kicks in, as it appears to have omitted building a linker when it
  detected that the current one is recent enough/matches)
It might also be that case that this is just the result of a
missing dependency, which messes with parallel building, idk...

Regards,
Alain Zscheile

From nobody Wed Dec 21 00:24:21 2022
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 4NcDj559Bsz1G164
	for ; Wed, 21 Dec 2022 00:24:41 +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 4NcDj4582Jz3n9k
	for ; Wed, 21 Dec 2022 00:24:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=bGCDyabJ;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671582278; bh=w2dKKhhnykM4ivCqVz06pLaQicpBFHZrD+Azn8qguIM=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=bGCDyabJK39oWWohtcilsVOxsWRkqUbE7bco5XuG8jcriXlzj3Ntwy5IB7mjR7EWkdP4+9tZFViAGU6hdajsEBSzVoL2FPu0Rd502O+SD40azOARwxpCyn90djqo4FHSoZhc8p1uvLYY1bDGC7Qlavr7qFmx9v9WRoDCKWyIDCCX/vS9TkiMGPu3iYKYMvRDlkFKG9UrRYZ0nfJQJXckS1JEqduMTV0NctJppF4JH3ZoeRT719AwupPYvpsNPY93pdJ/6GlxSnz30qNLSxuX3znmNC+uTp2gG+DLHobub2Q6EJQBIHBT8Vzvk5MEbkMG1mPVph5VHdPZTvoCQD74LA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671582278; bh=KcUE22vlC4MoRMNr3C3Kb1pVR4nN4c0kddzcWlAXQLE=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=f1apIjqj6HJBOYFmBZ6gcrEcZnv6YMFVSzriw8qn/pH3R/ppRX2DMYhN2aKLLEEvo75VRfcj6qVA8+nxzA1bboClzS0n+uQiOwN0oHGl9cT4I4XJo6sua1q4IIozRFaLjyhHGyWY13bH4zSvSxWKhaGvxfVy+f6zbXEEB772tfLdPgeJSq6yj/KA+rg79MVgqVgjxAEMw9DVit4clrMdAETD8l2qfbrnK0O6x22cECKIqKDX/1lA+r59uLdGQNPBGLHisyESnR2UVfz/lkF1yQ8NGwa8hrb5GoYN1oQj+AE9aXMFJP4nbcOm2uhQnvOGqG2gg4QF7kdwmRj2tfNGaQ==
X-YMail-OSG: 84EOXTwVM1nVP0lKNPgnXi7gpL5HEyfXxLBqq4UuH_9zlk0hh7w6FrdXhql.yPz
 BZGSWU1TOBvQpcO1Qdg2u9oc5Qx5Jwk3vyFb7sT1qcdiiWtE8HQy4r5OIAHA4hI90_0OB24mlE6N
 UJfB_Dv_QjdiqYx904GWJd8pL4EUH9riEyZ1r6YdnJ97AYCtafkMrhYWRpfCE7wAQv40VW4ck3tY
 F2OD4yXmqe3Xl2ehUq.rDENEq.uglnDOFu9kaUlNOqMIgw9QbhdYI5yA8k4PKjyF2kIT6egKsQyp
 uqdVWkLoCC.R6pgLTQau60PhHF0uAHdd_X_wcH0HnALiPXUy6u7WTHGRVrBW7bHzalBrR5.qNLvx
 PTMIoKuUkWWhy9fe3cTawStxmUjHhlI9GfQBKVGVWYF7Ih1VzZlDBEny01Q0u4BamCpujToqNFzK
 3RH3x0OZdxcDrP59u4qptVz0a1r4Dyi8Ybyq3s0zKoY567hFHr1qQbWArg5SbHcexSpakirTn2u1
 0twvQfaFN.zhiQbQzdnprKBeTTD7191D.9J7QceK60VLMUrq3XITDLQ_mCdmNeD34eG9zqOsaIR4
 WUzQBfzP4e2GG0m5XBizK9Jgls2Qk7tYyC.dFSCXjDYiemHPrRkNXdc72c8drTmJxkRvKUCs98uR
 8hT_E29ZrtB4pYnlp6fVS2AdkFlxXYJw_i9lB5OlrnIEd6R2KlZyehoglOfnFExHalcPZx5GSvY4
 xbF1.CXjp.ZhXVkBMaLCgZNiGh8zIW86ewaHlnF7y9kibzKY0Ab60yPzjVFyxYW1_slSeR8qb9Du
 HnW4qfmNr3bDQwsA8jkl6QHcMBbUwuXADChDsb2RwQ6VwBSfjRuKP3z_wStMcNmOU2kCyJe.CXdR
 eESYnizE643l5e.aruBfwevpHhFyIKyzUao8KZnpa1W.EeWP1a2vPZCZPYKaDusFpaYPOUmY5WxV
 91Cews9SJiqSVgYW4jVXDzr2dC0OGHyGW4GO2IXEPPPvmwlMIXbKD4ANm3JK82zL8ZcS6IWcvaIz
 DuufdPPqLwS2V_wM_NdW0dKWZMKPJKc3.MT1x1xE97rEJEBHHojk.TazmKeGfH_8QcitCHS7zAMe
 MqgVvxERWFojKJMV5vAa9Gsa2hxQlfSFZX4MCXq7Rw_FdLawfyzLGbdYncM8_.F_atpXZ_jEY4aQ
 oCnnFvDzaZW7x6VCJAdE6sjDqwu3.f6pDtb12db1n51AI.hvqX5GPMA1QYoBBB_KlaIngTSWa6MZ
 HGLHj1LlHtCHt3QtB6vQfubWdtCE_0nrfNVvmR3AqDBOIds5QHtfC4vx5sFKVartRHjHfd8U2XiI
 _GDaXxHj6UYfi8zeR4V3fo9s98dyjDRQIzDIJo0d9KFnOfDeZiUwejn_o2TB0Pe6Xt6wKia_2VLE
 40Tn9lWcdvCF8wzANMmS7t1hsazEHU2CcEUGLbce8FsNwyfPbpSsiOvG_1aJZlT8AZiP_edx0eN0
 5W.i8b5a13Ajq9_7J.LmGovrSMItmtBynr.IkkCG4s0lMWZQrYDk6yR3.Y0NJqNKnkpZcNmsEPI8
 WZpXfksM1lH8GXL2IVFVG1dr769HuY77ZRmQB0mkh.lurpiF.69KhsOhLa_jXEYjgtcY08HUCzIZ
 hmD3hxTBd9G.OfSrzsUvOaOXd38Sig7qp1KXff36FQW6QGJUO6Oluac.EsHBnfGVvbByV2py26VY
 Z.aA65gIVXHuK0h8nL3XwlVL_ZVAMYS1V0DdMerU0UYyHL7PJWgTfdCBoxptmAv80zlWFX56AVfl
 6OJYmF_Q84mx3JaWhgI5pKpt7GZwWLOpGnyR5_tF7lFHsptCPrW1M2xaPDqCcLnZ7yNnwN3VdyCU
 2gQH8zclgc0MeKJqeA4fBfd7WEQudD8WP_RLBnlkLPmtLFl1QivWok3JcNcvYYIM3fm4Uq.nfc_0
 DVEsHEjH_R804oBz.BzznyYKVzcfV22UKw62jKmM73wDcyN9AFcvGRSiIWJfs8OQlk7PkDiP3v2I
 MSxFy3ocOfaFPAfxiPsiv757jqITXi0YJdLM46l1mACyvYfCTjJR9dThxtPewSutqZxIQLDjADUL
 YjtolfmbH0XP3YBjjmK_BtSOi9qVe_ALy.tIhYcOswwY8BOUGE34ZSC7tOFRbMi7eA7liwnc4Djz
 eTwmdlSSxFT3rHrR8aXcY5lGQRKVFTu2J5icRDCy4l2ryszRF5OggZuv4SrC8LTPuS10cQaO7Yj_
 dSTziH7SHhOJZIkf.7R1SldhsYkQjoCGBfLqzeaZylomnV0mRvNAxv41wvjveToUqlp96Lw_qOe_
 VLp7_juAK
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 21 Dec 2022 00:24:38 +0000
Received: by hermes--production-bf1-5458f64d4-tg4jl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 25076c550aba9bc58f57cac50a3eeb77;
          Wed, 21 Dec 2022 00:24:33 +0000 (UTC)
From: Mark Millard 
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: RE: all_subdir_lib/libclang_rt build failure (libc++ ld error) 
Message-Id: 
Date: Tue, 20 Dec 2022 16:24:21 -0800
Cc: FreeBSD Toolchain 
To: zseri.devel+fbsd@ytrizja.de,
 freebsd-current 
X-Mailer: Apple Mail (2.3731.200.110.1.12)
References: 
X-Spamd-Result: default: False [-2.99 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	MV_CASE(0.50)[];
	SUBJECT_ENDS_SPACES(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TAGGED_RCPT(0.00)[fbsd];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	TO_DN_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4NcDj4582Jz3n9k
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

Alain Zscheile  wrote on
Date: Tue, 20 Dec 2022 23:12:40 UTC :

> I encountered a build failure while trying to build fbsd'
> src.git commit ae521fda895ff0b5076904f08ec92e3c60d53701

That commit is from main:

    =E2=80=A2 git: ae521fda895f - main - stress2: Added link to problem =
found Peter Holm

> with `make -j4 buildworld` on an FreeBSD 13.1 system.

So this was some 13.1 variant building at ae521fda895f of
main [so: 14]. That was not obvious on a first read of the
report. Sort of a self-hosted version upgrade cross-build.

For reference (example local installs):

# find /usr/obj/DESTDIRs/*/ -name libc++.so.1 -exec ls -C1 {} \;  | grep =
-v lib32
/usr/obj/DESTDIRs/13S-amd64-poud-bulk_a/usr/lib/libc++.so.1
/usr/obj/DESTDIRs/13_1R-amd64-poud-bulk_a/usr/lib/libc++.so.1
/usr/obj/DESTDIRs/main-amd64-poud-bulk_a/lib/libc++.so.1

Note that only main has main-amd64-poud-bulk_a/lib/libc++.so.1
and it does not have a main-amd64-poud-bulk_a/usr/lib/libc++.so.1 .

As for lib32:

# find /usr/obj/DESTDIRs/*/ -name libc++.so.1 -exec ls -C1 {} \;  | grep =
lib32
/usr/obj/DESTDIRs/13S-amd64-poud-bulk_a/usr/lib32/libc++.so.1
/usr/obj/DESTDIRs/13_1R-amd64-poud-bulk_a/usr/lib32/libc++.so.1
/usr/obj/DESTDIRs/main-amd64-poud-bulk_a/usr/lib32/libc++.so.1

So all 3 have *-amd64-poud-bulk_a/usr/lib32/libc++.so.1 and none
have a *-amd64-poud-bulk_a/lib32/libc++.so.1 .

> 
> --- all_subdir_lib/libclang_rt ---
> ld: error: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc++.so:2:
> cannot find /usr/lib/libc++.so.1 inside
> /usr/obj/usr/src/amd64.amd64/tmp
> >>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )
> >>> ^
> c++: error: linker command failed with exit code 1
> (use -v to see invocation)
>=20
> make[2]: stopped in /usr/src
> 
>=20
> The stated file is indeed not present, and resides in .../tmp/lib
> instead of .../tmp/usr/lib.

tmp/lib/libc++.so.1 would be a main [so: 14] style path.
tmp/usr/lib/libc++.so.1 would be a 13.1 style path.

The build appears to have which type of context applies
confused.

> It appears that the .so linker script
> should either be patched (to point to /lib instead of /usr/lib) or
> a symlink for the .so.1 file should be created.
> (at least the corresponding c++ command line doesn't indicate
> anything to the contrary of that afaik)
>=20
> I don't know when this problem was introduced and it might be the
> case that this bootstrapping problem only occurs when the "outside
> system" (in this case FreeBSD 13.1) has an older version of clang.

It is not clang that is the issue, it is that FreeBSD changed
the path used for libc++.so.1 . (main avoids needing more
mounts already being actie place when libc++.so.1 is used in
some common configurations, usr/lib/ not being available yet.

> (as I'm not really sure when the bootstrapping process actually
> kicks in, as it appears to have omitted building a linker when it
> detected that the current one is recent enough/matches)
> It might also be that case that this is just the result of a
> missing dependency, which messes with parallel building, idk...

Looks to me like whatever vintage/variant of 13.1 it was did
not yet(?) have logic for making sure that it provides for
builds of main [so: 14] that have the new libc++.so.1 style
path. Nor did the main materials have logic to make it work
when built from an older context, such as a 13.1 context.
At least one of the two must happen to allow 13.1 to build
a 14. Having main [so: 14] deal with it, if possible, could
possibly also deal with 13.0 vintages/variants without
adjusting 13.0 materials.

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


From nobody Wed Dec 21 13:41:07 2022
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 4NcZN61nl9z1GwjK
	for ; Wed, 21 Dec 2022 13:41:10 +0000 (UTC)
	(envelope-from zseri.devel+fbsd@ytrizja.de)
Received: from ytrizja.de (ytrizja.de [138.201.154.11])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NcZN54LKVz49w6
	for ; Wed, 21 Dec 2022 13:41:09 +0000 (UTC)
	(envelope-from zseri.devel+fbsd@ytrizja.de)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=ytrizja.de header.s=2020 header.b=ASL1RtQB;
	spf=pass (mx1.freebsd.org: domain of zseri.devel+fbsd@ytrizja.de designates 138.201.154.11 as permitted sender) smtp.mailfrom=zseri.devel+fbsd@ytrizja.de;
	dmarc=pass (policy=reject) header.from=ytrizja.de
Message-ID: 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ytrizja.de; s=2020;
	t=1671630067;
	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=6TseFy8N2Qms7AGuEwO0PbKRKUK0Nh00Pnp//n51IvE=;
	b=ASL1RtQBrvZOsr4yjKDkZbocSACH/Ji7HeF5NxX9yMvW7QalOiGnmB0fXgjvDCGZMsfR2l
	B18t0fIWVu0oEcPayMsAK/t5TnjDh5eFpqoQK0DN6J2IPrmNM+iIoRcBm5OlSTpSYjzmqZ
	qTojXZBrZiJNK9JazymveTaYFlaT+MnEsFEZ0e3wopMXvrOTwtFRTlstcS5chEL+yDIJtL
	wDAjpy1AjalICSzNvw4G9mBvZnr5KQzFTO+oK1W795SjQ1mQC3+t6z0zLG+DL0fqg4NS7A
	jPdUNb8u7/JkbDA9JTh8mCQ8Wes/z+X3HgOMK8vWw1P9iRs8bZrhJkGjnTE5pQ==
Date: Wed, 21 Dec 2022 14:41:07 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Subject: Re: all_subdir_lib/libclang_rt build failure (libc++ ld error)
Content-Language: en-US
To: freebsd-current@FreeBSD.org
References: 
 
From: Alain Zscheile 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-3.97 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.97)[-0.969];
	DMARC_POLICY_ALLOW(-0.50)[ytrizja.de,reject];
	R_SPF_ALLOW(-0.20)[+mx:c];
	R_DKIM_ALLOW(-0.20)[ytrizja.de:s=2020];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_ZERO(0.00)[0];
	ASN(0.00)[asn:24940, ipnet:138.201.0.0/16, country:DE];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	TAGGED_FROM(0.00)[fbsd];
	FROM_HAS_DN(0.00)[];
	DKIM_TRACE(0.00)[ytrizja.de:+];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NcZN54LKVz49w6
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hello,

On 21.12.22 01:24, Mark Millard wrote:
> Alain Zscheile  wrote on
> Date: Tue, 20 Dec 2022 23:12:40 UTC :
> 
>> I encountered a build failure while trying to build fbsd'
>> src.git commit ae521fda895ff0b5076904f08ec92e3c60d53701
> 
> That commit is from main:
> 
>      • git: ae521fda895f - main - stress2: Added link to problem found Peter Holm
> 
>> with `make -j4 buildworld` on an FreeBSD 13.1 system.
> 
> So this was some 13.1 variant building at ae521fda895f of
> main [so: 14]. That was not obvious on a first read of the
> report. Sort of a self-hosted version upgrade cross-build.
> 
> For reference (example local installs):
> 
> # find /usr/obj/DESTDIRs/*/ -name libc++.so.1 -exec ls -C1 {} \;  | grep -v lib32
> /usr/obj/DESTDIRs/13S-amd64-poud-bulk_a/usr/lib/libc++.so.1
> /usr/obj/DESTDIRs/13_1R-amd64-poud-bulk_a/usr/lib/libc++.so.1
> /usr/obj/DESTDIRs/main-amd64-poud-bulk_a/lib/libc++.so.1
> 
> Note that only main has main-amd64-poud-bulk_a/lib/libc++.so.1
> and it does not have a main-amd64-poud-bulk_a/usr/lib/libc++.so.1 .
> 
> As for lib32:
> 
> # find /usr/obj/DESTDIRs/*/ -name libc++.so.1 -exec ls -C1 {} \;  | grep lib32
> /usr/obj/DESTDIRs/13S-amd64-poud-bulk_a/usr/lib32/libc++.so.1
> /usr/obj/DESTDIRs/13_1R-amd64-poud-bulk_a/usr/lib32/libc++.so.1
> /usr/obj/DESTDIRs/main-amd64-poud-bulk_a/usr/lib32/libc++.so.1
> 
> So all 3 have *-amd64-poud-bulk_a/usr/lib32/libc++.so.1 and none
> have a *-amd64-poud-bulk_a/lib32/libc++.so.1 .
> 
> tmp/lib/libc++.so.1 would be a main [so: 14] style path.
> tmp/usr/lib/libc++.so.1 would be a 13.1 style path.
> 
> The build appears to have which type of context applies
> confused.
> 
> It is not clang that is the issue, it is that FreeBSD changed
> the path used for libc++.so.1 . (main avoids needing more
> mounts already being actie place when libc++.so.1 is used in
> some common configurations, usr/lib/ not being available yet.

thanks for the explanation.

> Looks to me like whatever vintage/variant of 13.1 it was did

"vintage" I upgraded to the latest stable/13 commit before
attempting the jump to main.

> not yet(?) have logic for making sure that it provides for
> builds of main [so: 14] that have the new libc++.so.1 style
> path. Nor did the main materials have logic to make it work
> when built from an older context, such as a 13.1 context.
> At least one of the two must happen to allow 13.1 to build
> a 14. Having main [so: 14] deal with it, if possible, could
> possibly also deal with 13.0 vintages/variants without
> adjusting 13.0 materials.

To somewhat fix it I ran: `make cleanworld`,
then reran `make -j4 buildworld`, while that was in progress
I created a symlink from .../tmp/usr/lib/libc++.so.1 to
`../../lib/libc++.so.` which resulted in a successfully finishing
build.

Regards,
Alain Zscheile

From nobody Thu Dec 22 17:45:29 2022
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 4NdHlp1mD4z1H5MQ
	for ; Thu, 22 Dec 2022 17:45:42 +0000 (UTC)
	(envelope-from rick.macklem@gmail.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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NdHln3n7bz44V3;
	Thu, 22 Dec 2022 17:45:41 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=JlZxq15t;
	spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::536 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pg1-x536.google.com with SMTP id 79so1773320pgf.11;
        Thu, 22 Dec 2022 09:45:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=FYi7mdlWAfaIS+D9bTziHF3l0579wthd+q0YWyJgFaY=;
        b=JlZxq15t1ffyVyExYBHRmgolGVwEwaCkOFevfNM7A+aTk7636A3OZt5NZ98qSxT5q2
         THLjWrXDFrEZHRUWKr3jO4Dh6BbAgkA/fNayKnC4OJqBnu7AklsFYM0KUMEhZm1/sKrG
         4BRWuepQQXtm/6Hno5SmfWqAUERjyCaypUWRX2oP1ggYF8kIbqD42m1VD2NnVWV4oJGN
         QcC4DDcxXHHth7Twbb5e3XHfgHVcjg9LEQ501iVkJ4M6MWy+o/RUDkS83ErR2Y0wTohK
         jXfyTQL58qEvp13qMAuY37/rgFsbqLcQQZDTEwHUSiC9EHRrXalBrI18wE4QfpsB666g
         R/Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=FYi7mdlWAfaIS+D9bTziHF3l0579wthd+q0YWyJgFaY=;
        b=qXSfK6hP7+3ysEiTinXghxL3H6EVy+apBLV5ixXdHL6KyVnE2seSg3cpdWyo3czPg7
         e5rD/wsGBtHW8bM6a4PHCoMRcCkzqhg8XGDZYtnqBbes00AFLun4fXJNnjzu5txvJiWi
         CcgqG8QZEIGzvB3pz4EtfAITgDqJ802pJFzdVu0Fx4of9ksBnMjrbSrAWEMHhBsv/4nF
         W/PJVpt2mG6KudQApMyNwR3kW98pLt4w4qT/SD2WkUnM5rvkCovLLr/SiCMVeBqdQs+/
         7+DisJfO67N2vNPrgZ8uKXJ1iMdVapd8I33IQvnKKtUbhXJzbw6L8ANz7chJdElb1BHJ
         Ou8Q==
X-Gm-Message-State: AFqh2kq/gncywyYwPmOzj2SBR56O1C6Z1WDpMGpUuqCHLYXkRt61o4S5
	mlJ8DdXxUt3ZgERoeTHoOOVR4wpc8B+dnbJbEp0Q6T02+A==
X-Google-Smtp-Source: AMrXdXupdcJfNFuhp5cI848gn7GHBasnqjKdy6lhtH/vZXB+Ar9mkHm4Tqcwf5r8Ub/oFWdc9TwLZ5d6elLb7QMYcDk=
X-Received: by 2002:a62:e912:0:b0:579:6402:5b39 with SMTP id
 j18-20020a62e912000000b0057964025b39mr403906pfh.11.1671731139974; Thu, 22 Dec
 2022 09:45:39 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 <1955021.aDjkhKmpDe@ravel> 
 <8351812.Gc231LQI4k@ravel> 
  
In-Reply-To: 
From: Rick Macklem 
Date: Thu, 22 Dec 2022 09:45:29 -0800
Message-ID: 
Subject: Re: RFC: nfsd in a vnet jail
To: "Bjoern A. Zeeb" 
Cc: Konstantin Belousov , James Gritton , freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000c21b6105f06e3cdf"
X-Spamd-Result: default: False [-3.86 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.86)[-0.859];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::536:from];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	TAGGED_FROM(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_SOME(0.00)[];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NdHln3n7bz44V3
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--000000000000c21b6105f06e3cdf
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 19, 2022 at 9:36 AM Bjoern A. Zeeb  wrote:

> On Mon, 19 Dec 2022, Rick Macklem wrote:
> [good stuff snipped]
> > Unfortunately, this does not deal with vnet'ng the kgssapi, rpcsec_gss
> for
> > Kerberized mounts or vnet'ng NFS-over-TLS, but those could be handled in
> a
> > similar manner, I think?
>
> Could be, yes.
>
> I have now created a patch for the NFS-over-TLS part of the krpc.
It uses the same technique, except the macros are called KRPC_VNETxxx
instead of NFSD_VNETxxx.

The patches are in phabricator as:
D37519 - Most of the changes.
D37777 - The krpc changes for NFS-over-TLS
D37741 - The vfs_mount.c changes in D37519
Although I listed a few possible reviewers, anyone is welcome to test
and/or review them.

The patches are also here (in a form that "patch" might prefer):
https://people.freebsd.org/~rmacklem/vnet.patch
https://people.freebsd.org/~rmacklem/vnetsmall-rpctls.patch

rick


>
> > So, what do others think of this alternate plan?
> >
> > rick
> > ps: Every use of the vnet'd variables is currently wrapped in a macro
> called
> >    NFSD_VNET(), so the change is pretty easy to do by just re-writing
> this
> > macro.
> >
>
> --
> Bjoern A. Zeeb                                                     r15:7
>

--000000000000c21b6105f06e3cdf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Dec 19, 2022 at 9:36 AM Bjoern A. Zee=
b <bz@freebsd.org> wrote:
On Mon, 19 Dec 2022, =
Rick Macklem wrote:
[good stuff snipped]

> Unfortunately, this does not deal with vnet'ng the kgssapi, rpcsec=
_gss for

> Kerberized mounts or vnet'ng NFS-over-TLS, but those could be hand=
led in a

> similar manner, I think?



Could be, yes.


I have now created a patch for the NFS-over-TLS part of the krpc.<=
/span>
It uses the same technique, except the macros are called KRPC_VNETxxx
instead of NFSD_VNETxxx.

The patches are in phabricator as:=

D37519 - Most of the changes.
D37777 - The krpc changes for NFS-ov=
er-TLS
D37741 - The vfs_mount.c changes in D37519
Although I listed=
 a few possible reviewers, anyone is welcome to test
and/or review them=
.

The patches are also here (in a form that "patch" =
might prefer):

rick
=C2=A0



> So, what do others think of this alternate plan?

>

> rick

> ps: Every use of the vnet'd variables is currently wrapped in a ma=
cro called

>=C2=A0 =C2=A0 NFSD_VNET(), so the change is pretty easy to do by just r=
e-writing this

> macro.

>



-- 

Bjoern A. Zeeb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r15:7




--000000000000c21b6105f06e3cdf--

From nobody Fri Dec 23 23:47:33 2022
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 4Nf3lH1gXxz1Lpxm
	for ; Fri, 23 Dec 2022 23:47:55 +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 4Nf3lG0RfWz4HfZ
	for ; Fri, 23 Dec 2022 23:47:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=ilcJV+Xn;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671839269; bh=S++yCKXxnvgQNJSpCsWxJU8y5zPrprseuvNThCXowhk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=ilcJV+XnacZMyRPk0nD8wXi60AGk1G3i+nT4GSG7ukh3NmqkD0L1y0iUkBis+1+uzq1sCpyQ2O8nDfat5cgApfMsZ7Arm40i9g1ay01kpGVT49A7kjMQnfMovRLot8kvs1lNcFLBvoqI0tmvz9SdFrZHLBlxkuJENfzMO6vArQG6AtLFFALNZ1kNm0yBnA/TszutE/wCvz/Y6jRUvVkKWma7uIDrHruhv2vGk9AT/NHsAZnxVEpSyoCS4AuQg2yE+kuxJn2nqUAwoc00NrbR7UlRtxE+gGDzg/sd6fniY6ct34FJpRBnnc34+2cXtqcYs9UQ1VvG16E4OvJZ/X8pMg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671839269; bh=mYFHuzCCKz4rwQszGrCTP7WU5KDmpQDPCXDz9IfXhkR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=AjnU604yVQO5cnYutfyp+FZWYAr4+1noUVuIxZDL6CUuERWwQ8TtkmEwrxSbVedk23zQchQXsC/CZJXoPb81wr1JGixQMQmxcvilIPsEL5LV5VMq5Cq3TlpaY8TJjyrVSiwgcarJ3DIXjdcYw3CLOpQbzahdHun6wcSpcI5ay5ERkaeuISQozqKxFbtBKdkvdv6FYumB6Yt5ANnJuW17+Bk2h0bOi+zm201+z+wyswwt7dR4PX+airGZx+dhM+aJH+eF6ZAu0zDfhLqGoc4VY0ao+/UaaOoeDqyEX3uTJQnsH1vdNIeF6Teyf3l3CIrelFoWhNglpmMY4NLzPmGa5w==
X-YMail-OSG: 2icHlMoVM1lNUDgDCoKZa_582SEGKytyI81ictbtlBIROc1ijl.oi.e.RKWz.kr
 r1gVq.GGROzqhPeD.g6cFTKiEqcRoe6lV3PuKH73YlDZ4DniulrQRwSQ.4CiQdaaq4Rr1IJylV7m
 eQqM0y7SS6pO5WFPaDtj66X58Caw1qVOYz.wy_6dK1P.4lSJ41edmA0hTzdPcRdaL4bROR2nVdMA
 pdV9lWq.gXzaJClUcAkhGgdtYq7Z11m2h7jiqriOKgpxRyirnw8UdnImh48YXWPLsenjjeDQ0Ivm
 1WGqoAMsHyukVjGyHHySpHr4tiJQOis8g1tLUwhPrgf_Uc61WDou7epktT507O7RafImacLa6xov
 t_AaLFgfaEe4Q4yohrX48zknkrEMG3suSd10q2u9q86g.PCFxj9dVFbBUJtK4vb6hp8ER5cb7ISa
 vLb1.6oR14xXupWSMSi82qN.IVfxZa7KV7pe2GrxTNQl6MqCiC8uGkdtsqFsueSNISFvwtCqpJwM
 6tlqHu1xd4lVtSm4tmFxSjYr5gnwuiFTNFqJLOlsSplMPChu.iIDxDFUraJIJFdnoaupmmCkPXFz
 8XuVr_TQhrs4hDjrLIanY3OsZ2965zIfQXzoGGkB.3WptefKpx0s3JS.DeNkyxPGgtIb7.HsUcFr
 utsN5M5SAvmlQk5HNBGfOOeGLnQYAzF4C0s86fJwEDbpNcGkrv3u4kVHm8Czru.UusDJPwi8LOkD
 MdDXzC9wAOEUV1LGC1G2y4gLaXIUoSTZmjBXOk4W4Abpz4XkCaDmld88KzlCfIlgZ2x07U_0SZzH
 113UY_yc1rtkRh6.J2PDtNYv8meDNcuT9BWu0jjGIlWgFOBb4RDump9IRFi7hJGMVzku_8GSBkt1
 _wSeS1xK6CqX0Xw.HuDa64.24mLltNknQjp8cL5vbwv8OAfmNYZstDrf1WG_bPFUzDJt.HsoJ2TW
 IVQoVX.TRW7zEzhmjJ.zjTb__sRP.NnEYqdOkiogcr1daZ3GDVCxBfq0vWLma_6YngfQetRLbn8A
 j.2funHsEAqbxSztm1ApUoTfzx3P7HomoFUWhYo8pxe7i8hbWdly4pAWlozM.TiZjFoUau9fwnAj
 U5ODrNtGi1rn2CdOUSuz.s6YWCNefdTOzU6kuXaA8OeNKugL_ZAG8B2VOe50gRfTFFZ77_n.QVXN
 Qm87JdeM6CuUbYJC0HjbnZvtDLoNWWsqYu3aSMSXiV8aU0ceSa2km9dYPmRDflORUTF6Lp5LE9_V
 knXsvNA.hrTe.EVUkglSHgm3IFXkp2_Al8eAzud2BrKuvlB2HOjdEBfSE63IueAVXNTN6JxFaFvl
 Xk4w14Pgv0fpBOZW5Mkqah1C4BVfV.h9LP7YVMxMsabtHpLTzTkKExKAjFzV_WLQBhVWM4au.3kS
 kN25IxAcAEiH17iWE99S4gP.kNwnmu6LdFKbDaZSwdNIeSNh.HgEtOuzS2_6dmh_o_YxUbu6kLUb
 prale4Gxt2XQhc9eES3ff26XDGzlu9sibHploIJb9FzWlHAHC7Sp3gdnDnC7AIPQHrggH1Drt.Jh
 r1Dj9o8jExvQafmKOsh3.B9KOdyWEFtdEA_oF5l0pdCW3LBiWvPGsg8eqxhfzCvuYZKvRZ2TQ5AM
 9OZ_i2A4WUuPMR65.Gxnkf2nXS1PU_KvoqVabRPI9QXOJ8XdEDTUKrajzpStPEEJ6eYT51bYxcrJ
 9sfuiTDIjZF6PX3fyabLfUKHJzH0OxG9seYd6CXRX.HOeFAaK5It7cD7OSJDKX.GCcr7xxv_vTT_
 eWq0KqL1Aoq3leKZm7d0MoxQdEnNLyX3nHLmgTQ9CUdgmhbeABzXrzdR8opXEwz4LdNZdRYP7aqz
 Y4TFVhANXeUITD23I3IqrrLHfZTyETu.v7fZ_ToMY3uLAhkn_jqZUOzsHMzXypXiycjLfEoj.Bit
 Oc131pL0vZ8kq0AL1VLCrVgcmB8vKL6ksZ3C7WyTtG6UYjdJHyHLKw7101evFn6V1.YJAfbfEqH5
 IBuK7o6dFqlziI9Ub_070Wre958H8apjbxNke8UL6IcLk4pnnOCYZ4WUbCrAfecK9fo.mxXFaSbP
 hTfg6fnMd3TaDefXUSnaiaE9BAr4RadhB4ZHC8D_J2YbA_XMM5OLua_PLv2Qsb5HaMyRqRWz_Ttk
 rfoHjlTfaMuOIEO6ncUwtUysEBjvhbBRsuJnI7G8S9LT8ZMveCFpMiWQN5xXDddY7LzfUAEsHN_n
 SmUsKULCAtrJxVPzlVtxuXSmlBCJPoQvAXfRRTDEHT_SW.HcUiM6bwsnjlnjxBoyUaSkNJoLr2Zb
 4
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 23 Dec 2022 23:47:49 +0000
Received: by hermes--production-bf1-5458f64d4-x4bxm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 268af7ab50cb22483dd25d695b525e81;
          Fri, 23 Dec 2022 23:47:45 +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 \(3731.300.101.1.3\))
Subject: Re: Unusual errors on recent stable/13 22-Dec-2022 (a related problem
 report on freebsd-ports?)
Message-Id: 
Date: Fri, 23 Dec 2022 15:47:33 -0800
To: Jonathan Chen ,
 FreeBSD-STABLE Mailing List ,
 freebsd-current 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
References: 
X-Spamd-Result: default: False [-3.40 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.995];
	NEURAL_HAM_SHORT(-0.90)[-0.902];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	SUBJECT_HAS_QUESTION(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]
X-Rspamd-Queue-Id: 4Nf3lG0RfWz4HfZ
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Jonathan Chen  wrote on
Date: Fri, 23 Dec 2022 18:40:27 UTC :

> On 24/12/22 07:14, Mark Millard wrote:
> > Jonathan Chen  wrote on
> > Date: Thu, 22 Dec 2022 19:21:37 UTC :
> >=20
> >> I recently updated my package builder machine to the
> >> stable/13-n253297-fc15d5bf1109of (22-Dec-2022); and appear to be =
having
> >> some unusual issues when building with a high number of jobs. My =
package
> >> builder uses synth (which uses nullfs on ZFS), and I have had =
failures
> >> with missing files, as well as what appears to be sequencing issues =
with
> >> Makefiles. If I re-run the build, these errors usually do not =
reoccur.
> >>
> >> I'm puzzled as to what is happening. Is this just happening to me? =
It
> >> appears that the ZFS code has been updated recently, and I'm =
wondering
> >> whether a regression has crept in. [Or it could just be my =
hardware?]
> >=20
> >=20
> > =
https://lists.freebsd.org/archives/freebsd-ports/2022-December/003153.html=

> >=20
> > indicates a problem with tmpfs use such that using USE_TMPFS=3Dno
> > avoids a problem for poudriere bulk builds on 13.1 amd64.
> > (Unclear if the note is for stable/13 vs. releng/13.1 vs. both.)
>=20
> I'll try disabling tmpfs on synth.
>=20


FYI . . .

The following is about the tmpfs issue referenced in
freebsd-ports/2022-December/003153.html .

Here is what is going on (manually entered commands, not a script). =
First under a tmpfs:

# df -m
Filesystem 1M-blocks Used Avail Capacity Mounted on
/dev/ufs/rootfs 221683 97879 106068 48% /
devfs 0 0 0 100% /dev
/dev/msdosfs/MSDOSBOOT 49 31 18 62% /boot/msdos
tmpfs 7716 0 7716 0% /tmp
# cd /tmp
# : > mmjnk.test
# ls -Tld mmjnk.test
-rw-r--r-- 1 root wheel 0 Mar 9 08:56:53 2022 mmjnk.test
# : > mmjnk.test
# ls -Tld mmjnk.test
-rw-r--r-- 1 root wheel 0 Mar 9 08:56:53 2022 mmjnk.test

(no time change). The makefile involved is using ": > NAME" notation
to try to update timestamps on deliberately empty files.

Vs. under (for example) UFS:

# cd ~/
# : > mmjnk.test
# ls -Tld mmjnk.test
-rw-r--r-- 1 root wheel 0 Mar 9 09:00:45 2022 mmjnk.test
# : > mmjnk.test
# ls -Tld mmjnk.test
-rw-r--r-- 1 root wheel 0 Mar 9 09:00:54 2022 mmjnk.test

(time changed).

Back in tmpfs land . . .

Part of this is that the file is already of size zero and continues
to be so. By contrast, starting with a file with 15 bytes in it:

# ls -Tld mmjnk.test
-rw-r--r-- 1 root wheel 15 Mar 9 09:07:38 2022 mmjnk.test
# : > mmjnk.test
# ls -Tld mmjnk.test
-rw-r--r-- 1 root wheel 0 Mar 9 09:07:49 2022 mmjnk.test
# ls -Tld mmjnk.test
-rw-r--r-- 1 root wheel 0 Mar 9 09:07:49 2022 mmjnk.test

The lack of a timestamp change when the file already has size zero
looks like an example of a bug to me.

truncate for tmpfs files behaves similarly (showing just the
lack of timestamp change context):

# truncate -s 0 mmjnk.test
# ls -Tld mmjnk.test
-rw-r--r-- 1 root wheel 0 Mar 9 09:11:31 2022 mmjnk.test
# truncate -s 0 mmjnk.test
# ls -Tld mmjnk.test
-rw-r--r-- 1 root wheel 0 Mar 9 09:11:31 2022 mmjnk.test

(UFS got a timestamp update from such a sequence.)


I'll note that touch does not get this tmpfs behavior:

# touch mmjnk.test
# ls -Tld mmjnk.test
-rw-r--r-- 1 root wheel 0 Mar 9 09:11:26 2022 mmjnk.test
# touch mmjnk.test
# ls -Tld mmjnk.test
-rw-r--r-- 1 root wheel 0 Mar 9 09:11:31 2022 mmjnk.test

(But it would not force size zero on its down.)

I did these tests on:

# uname -apKU
FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0 =
stable/13-n253133-b51ee7ac252c: Wed Nov 23 03:36:16 UTC 2022 =
root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC =
arm64 aarch64 1301509 1301509

However, I previously did a devel/nasm bulk test with with USE_TMPFS=3Dall=
 on:

# uname -apKU
FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #55 =
main-n259064-f83db6441a2f-dirty: Sun Nov 6 16:31:55 PST 2022 =
root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a=
md64/sys/GENERIC-NODBG amd64 amd64 1400073 1400073

and it got the problem. (I normally use USE_TMPFS=3Ddata , which does =
not
get the problem because the files in question end up not on a tmpfs.)

So: not specific to amd64 , not specific to stable/13 , existed in early
November in main. This may have been around for some time for tmpfs.

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


From nobody Sat Dec 24 00:00:07 2022
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 4Nf41N2p50z1Lrjg;
	Sat, 24 Dec 2022 00:00:08 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nf41N227yz4LS5;
	Sat, 24 Dec 2022 00:00:08 +0000 (UTC)
	(envelope-from salvadore@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1671840008;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=NHCrH3emcgUifmhNrGK5KqcfJlPpV/HJ5UClcPRnW20=;
	b=ydB/v2B4dYlGyBYwnjCYqNA4gIq3M+kW/pq3JidvPV8PRHQHWh1hs9EvqRyrHBdO+wcVuh
	qnjtR9cQ3tSwrnOxBRMa/DixScRM83XNPgFsQ2LefKDKRVve1TRkcIdyoS93Y5ydT9MatS
	0wwbB6UjNI4zGQ7L27S4QhsEMj05H5bAoCF8vt6saQ//+7KZI3k9uNoXIpIe/eVFywk432
	v9aP6oZqmnqeCjIdAbNwZD8iW/9UwlbIVwZnt0BbF4elORGT1J0+eZMFRq2SsojvdfQr1m
	PLnI/dqP7m6EvKOQ3xdhZIfNNmBFN6M6pcY1rzVjq7fDQ32My9e6bs14TGjYSw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1671840008;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc; bh=NHCrH3emcgUifmhNrGK5KqcfJlPpV/HJ5UClcPRnW20=;
	b=p/cZS3Dz5vUnuOgpoLsP1f66dg2Sv5e6oAnyn6+k762Qzb0RudyHDdSxE6yStS51sd4vDl
	oCUYjXjaNpoWN49od+c+Tp+v53izku5hdY3VdprG9sILj3hEyBuj83IeReXR/3PmgtMi20
	0yfMKYGwLwpUryblMKLa7DQa1PiKJ0Vk7NQmMCakeob6VhGSuSDL8XpPmXiKnBNSSAak9H
	nyMPFDJxLecsxxazNdaqQfY0tRBthC63L7clUFVTz8DNb2BYU4wqoBc8QdYWwkyDwaztic
	j886+pOW8il4l7sPfYSzHAmp5Sjnkf48aLNojIEJYKNAOsfnw4IK2xayFD74Eg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1671840008; a=rsa-sha256; cv=none;
	b=bVphBOJHbTINPp2HRSAeCwx48EC94tS9QNeZoYA+YsA0wMIvHS5PuB8uGF+RlukiL9CaT7
	3IYOfP6rcrmbPBMUaxb8mjAfEsyyZtW7DFeniNprLv32qmDapeO7z9W+E4oM9ILqErqTH2
	FMl3dPYSqXC48699vt1wP+WSfHdvBRJwFP47aCNx/3tAf6Whj13b0QOhd7pyAhO2VHq3Jg
	dZVq92/IDgw/YMgjbLf69llO0uZpr52m1kQS3OSlMbfWuhbHx3xLUfLUG1bT4fIK3yJXUo
	zdm8wVCZQgW4HmEsTtkWEZGt8C8oZPmnVrfwfWZVMQp8K3QnZr6iwqmR1HvN1w==
Received: by freefall.freebsd.org (Postfix, from userid 1472)
	id 09877377A; Sat, 24 Dec 2022 00:00:07 +0000 (UTC)
To: freebsd-quarterly-calls@FreeBSD.org
Subject: [LAST OFFICIAL REMINDER] Call for 2022Q4 quarterly status reports
Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org
Message-Id: <20221224000008.09877377A@freefall.freebsd.org>
Date: Sat, 24 Dec 2022 00:00:07 +0000 (UTC)
From: Lorenzo Salvadore 
X-ThisMailContainsUnwantedMimeParts: N
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

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
December, 31st 2022 for work done since the last round of Quarterly Reports:
October 2022 - December 2022.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the AsciiDoctor template, fill it in, and
email it to quarterly-submissions@FreeBSD.org.
The new AsciiDoctor template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc

We look forward to seeing your 2022Q4 reports!

Thanks,

Lorenzo Salvadore (on behalf of quarterly@)

From nobody Sat Dec 24 00:25:32 2022
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 4Nf4b21xq3z1GyZw;
	Sat, 24 Dec 2022 00:25:50 +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 4Nf4b14X14z4QPS;
	Sat, 24 Dec 2022 00:25:49 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 2BO0PWjZ032512
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Sat, 24 Dec 2022 02:25:35 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 2BO0PWjZ032512
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 2BO0PWZF032511;
	Sat, 24 Dec 2022 02:25:32 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Sat, 24 Dec 2022 02:25:32 +0200
From: Konstantin Belousov 
To: Mark Millard 
Cc: Jonathan Chen ,
        FreeBSD-STABLE Mailing List ,
        freebsd-current 
Subject: Re: Unusual errors on recent stable/13 22-Dec-2022 (a related
 problem report on freebsd-ports?)
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=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home
X-Rspamd-Queue-Id: 4Nf4b14X14z4QPS
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Fri, Dec 23, 2022 at 03:47:33PM -0800, Mark Millard wrote:
> Jonathan Chen  wrote on
> Date: Fri, 23 Dec 2022 18:40:27 UTC :
> 
> > On 24/12/22 07:14, Mark Millard wrote:
> > > Jonathan Chen  wrote on
> > > Date: Thu, 22 Dec 2022 19:21:37 UTC :
> > > 
> > >> I recently updated my package builder machine to the
> > >> stable/13-n253297-fc15d5bf1109of (22-Dec-2022); and appear to be having
> > >> some unusual issues when building with a high number of jobs. My package
> > >> builder uses synth (which uses nullfs on ZFS), and I have had failures
> > >> with missing files, as well as what appears to be sequencing issues with
> > >> Makefiles. If I re-run the build, these errors usually do not reoccur.
> > >>
> > >> I'm puzzled as to what is happening. Is this just happening to me? It
> > >> appears that the ZFS code has been updated recently, and I'm wondering
> > >> whether a regression has crept in. [Or it could just be my hardware?]
> > > 
> > > 
> > > https://lists.freebsd.org/archives/freebsd-ports/2022-December/003153.html
> > > 
> > > indicates a problem with tmpfs use such that using USE_TMPFS=no
> > > avoids a problem for poudriere bulk builds on 13.1 amd64.
> > > (Unclear if the note is for stable/13 vs. releng/13.1 vs. both.)
> > 
> > I'll try disabling tmpfs on synth.
> > 
> 
> 
> FYI . . .
> 
> The following is about the tmpfs issue referenced in
> freebsd-ports/2022-December/003153.html .
> 
> Here is what is going on (manually entered commands, not a script). First under a tmpfs:
> 
> # df -m
> Filesystem 1M-blocks Used Avail Capacity Mounted on
> /dev/ufs/rootfs 221683 97879 106068 48% /
> devfs 0 0 0 100% /dev
> /dev/msdosfs/MSDOSBOOT 49 31 18 62% /boot/msdos
> tmpfs 7716 0 7716 0% /tmp
> # cd /tmp
> # : > mmjnk.test
> # ls -Tld mmjnk.test
> -rw-r--r-- 1 root wheel 0 Mar 9 08:56:53 2022 mmjnk.test
> # : > mmjnk.test
> # ls -Tld mmjnk.test
> -rw-r--r-- 1 root wheel 0 Mar 9 08:56:53 2022 mmjnk.test
> 
> (no time change). The makefile involved is using ": > NAME" notation
> to try to update timestamps on deliberately empty files.
> 
> Vs. under (for example) UFS:
> 
> # cd ~/
> # : > mmjnk.test
> # ls -Tld mmjnk.test
> -rw-r--r-- 1 root wheel 0 Mar 9 09:00:45 2022 mmjnk.test
> # : > mmjnk.test
> # ls -Tld mmjnk.test
> -rw-r--r-- 1 root wheel 0 Mar 9 09:00:54 2022 mmjnk.test
> 
> (time changed).
> 
> Back in tmpfs land . . .
> 
> Part of this is that the file is already of size zero and continues
> to be so. By contrast, starting with a file with 15 bytes in it:
> 
> # ls -Tld mmjnk.test
> -rw-r--r-- 1 root wheel 15 Mar 9 09:07:38 2022 mmjnk.test
> # : > mmjnk.test
> # ls -Tld mmjnk.test
> -rw-r--r-- 1 root wheel 0 Mar 9 09:07:49 2022 mmjnk.test
> # ls -Tld mmjnk.test
> -rw-r--r-- 1 root wheel 0 Mar 9 09:07:49 2022 mmjnk.test
> 
> The lack of a timestamp change when the file already has size zero
> looks like an example of a bug to me.
> 
> truncate for tmpfs files behaves similarly (showing just the
> lack of timestamp change context):
> 
> # truncate -s 0 mmjnk.test
> # ls -Tld mmjnk.test
> -rw-r--r-- 1 root wheel 0 Mar 9 09:11:31 2022 mmjnk.test
> # truncate -s 0 mmjnk.test
> # ls -Tld mmjnk.test
> -rw-r--r-- 1 root wheel 0 Mar 9 09:11:31 2022 mmjnk.test
> 
> (UFS got a timestamp update from such a sequence.)
> 
> 
> I'll note that touch does not get this tmpfs behavior:
> 
> # touch mmjnk.test
> # ls -Tld mmjnk.test
> -rw-r--r-- 1 root wheel 0 Mar 9 09:11:26 2022 mmjnk.test
> # touch mmjnk.test
> # ls -Tld mmjnk.test
> -rw-r--r-- 1 root wheel 0 Mar 9 09:11:31 2022 mmjnk.test
> 
> (But it would not force size zero on its down.)
> 
> I did these tests on:
> 
> # uname -apKU
> FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0 stable/13-n253133-b51ee7ac252c: Wed Nov 23 03:36:16 UTC 2022 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 aarch64 1301509 1301509
> 
> However, I previously did a devel/nasm bulk test with with USE_TMPFS=all on:
> 
> # uname -apKU
> FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #55 main-n259064-f83db6441a2f-dirty: Sun Nov 6 16:31:55 PST 2022 root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1400073 1400073
> 
> and it got the problem. (I normally use USE_TMPFS=data , which does not
> get the problem because the files in question end up not on a tmpfs.)
> 
> So: not specific to amd64 , not specific to stable/13 , existed in early
> November in main. This may have been around for some time for tmpfs.

Should be fixed by https://reviews.freebsd.org/D37866

From nobody Sun Dec 25 08:02:30 2022
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 4NftgW05Cdz20kWC
	for ; Sun, 25 Dec 2022 08:02:31 +0000 (UTC)
	(envelope-from danfe@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NftgV6mYNz3G04
	for ; Sun, 25 Dec 2022 08:02:30 +0000 (UTC)
	(envelope-from danfe@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1671955350;
	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=lNW/2SASMIwtGkkgjuSfzhP8bku56CpusvTDQkB8P14=;
	b=CyneWT42262L68VF/FjVz5boyQ8PjlXyAQs4TuqNhMc3QwYlPnLpxK9oHZkWWYYWWx77I+
	XD+mMMGQaJHj+nPBRAkaCsfH9aycTo1+Be/Og1grV1q9QU9seewbGIWGRy3Fq248W0OTS2
	ePG5yFbos0MrkLu7Ia/KZk08w/RXWy9jIa95RepvhSHFkuFgVdp6yihXldfZ+IPHvhHjHI
	XriDsErEARNKi//1K711NzbWfqQKHyiZdZLJH+B7lrXD3C9gzLj11qP0W7Tbmavg6Yskcd
	M/ltz5+YCdUz43wOuw67b+Y2lCbuRQLfkWW5Ju0a30tHD5pbjOV8GtmU+LwLCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1671955350;
	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=lNW/2SASMIwtGkkgjuSfzhP8bku56CpusvTDQkB8P14=;
	b=f5pwwW+SWY6wWvlo6hBRkLivBIu/94Fs87UHHvpHdtTGGnYItEX1VuU++4oh5klJpsdPhZ
	iJpR0kI6OMMR20FIXbPXP515YxtgRCvOch26da4U1opeXb60Y48KKFiVX/V5rTQ6mxxTHz
	bU3WPl2mcmKzcA1t+OiIPKSt6/tNpapDtAH/c8Bfef2K7mCfjqPl7IyxfBbVQQMxxv4uBm
	HNm4CcIEmp5LaugGSSSzKW1qCTLo/fYGuoZQz71Q/s1cEM/sqq9r4lKs2cvBdluRmAGRdp
	UOLijSJG9L1MEX/IXZKXa4I9KrqKFT6WyQVqdbFtFKRpQKfBSA+IloGbFBmMmg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1671955350; a=rsa-sha256; cv=none;
	b=g3XtbSgfQM7jwFE+HuAWMWXH1IOgxIoqWDn9bV+5QXCBsha4OUfoxxnMwhcGaD58sYxrDp
	sNwojYAQ+TgOgOTCQUsEjKE4RI+hASQeYIwBcRWugvKbPVLF3z6jVRCeBG93n2WnG+2tAb
	MZ/wThDv1cRbjJN1+Ip+VUrGM5osGFRQ7itL620HnfB/tJMN+anF/YClfLF2l/IOVpHQr3
	vvKYG+eah94f2MtrA2hGs+bhKQ/HM3cRwD+wmkN+MrDj6nAbhG4RF9GmLtuAH1Z7IBbknr
	FgCtVhlTwmxKl86R902S0R4jp3KfGNscHVbvt4vXS7cJC2cMslbGAAEloxdI9A==
Received: by freefall.freebsd.org (Postfix, from userid 1033)
	id D704790EB; Sun, 25 Dec 2022 08:02:30 +0000 (UTC)
Date: Sun, 25 Dec 2022 08:02:30 +0000
From: Alexey Dokuchaev 
To: current@freebsd.org
Subject: Disk partitions disappear when mounting others
Message-ID: 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-ThisMailContainsUnwantedMimeParts: N

Hi there,

I'm in the process of moving my data from a dying HDD, and just noticed
something weird.  It's an MBR partitioned drive, and there is a FreeBSD
slice and Fedora LVM in EBR, accessible as /dev/linux_lvm/fedora-{swap,home,root}.

The problem is that once I mount my old FreeBSD partition, e.g.
/dev/ada0s2a, those LVM nodes are gone, logging this:

  GEOM_LINUX_LVM: disk pv0 already initialised in fedora
  GEOM_LINUX_LVM: Disk diskid/DISK-XXXXXXX1s4+00000001 removed from pv0.
  GEOM_LINUX_LVM: Device linux_lvm/fedora-swap removed.
  GEOM_LINUX_LVM: Device linux_lvm/fedora-home removed.
  GEOM_LINUX_LVM: Device linux_lvm/fedora-root removed.

If I unmount /dev/ada0s2a and mount any Fedora's partition, then I can
longer access other slices as there's only /dev/ada0 remains; ``gpart show''
also does not list them, but only those under diskid/DISK-XXXXXXX1.

Why is this happening?  What should I fix to stop my partitions from
disappearing and reappearing?  Thanks,

./danfe

From nobody Sun Dec 25 16:32:55 2022
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 4Ng60h3r3Jz20jVm
	for ; Sun, 25 Dec 2022 16:33:08 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Ng60h1f9Gz4VMV
	for ; Sun, 25 Dec 2022 16:33:08 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ed1-x535.google.com with SMTP id i9so13248411edj.4
        for ; Sun, 25 Dec 2022 08:33:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=oecEONUScIcgko7m4ktgTXdqZLmin9Qj3xWSacinJY4=;
        b=34a0b59+/Vlb85tPDCZMh0bKrBtPRAgtCXWHV8JwCzqyQXrOca1wBEFucmh7qUQv0K
         Eh3yoHtD5mugRY4Y3OXrcxQbjlAmuEinko52U0XUARwk5nuWgBTnTUhpch6TxKCJT3ap
         6czND1Z+BzBcXX6esxFYcCG+2WFNPYXpQ+ma/fb+5MPpoxD9aV8/zVCm64A90sMmvSXp
         7GmjSiKH1eKZE6s256BHh5FHxizdR+OoxS80EZKgxNLM55Cf+6bYIBK06Or9YkvDOIH+
         YkFg2Z6+SyiWzjBBpmnLPqcPOkp6FaY/q2Y8YyndxFo1R+jcdM4jGkqf1z8D52VSyNkc
         g/qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=oecEONUScIcgko7m4ktgTXdqZLmin9Qj3xWSacinJY4=;
        b=pve96oDfZ+q7xTwKulw98vEFIA4CKtYOmNlhUB7/RB6dQr2TO1RYi6IC7KVDNSCkZb
         K9TXynvxcHeGrfPVp5TWynhds8O83yjLNnwNI1sMT6XbjpB8HM2gt4eOGQcBISjKloAw
         B6tMcDhJeoTCnHgQbdRhGlBnGIAd5ntPK9S07PU8LVh95qGT/qGPZWCTZ1yRK0tLzHG8
         4MwT9yBK4P9nwUPqeVHrYxiX39zNJTZss1FjYq57MES0R/gDQJ9pfu/7tdzd4cjkzIkq
         aBmX0iTS484prU2mofVBEY26uRsmw6GutHGkOhsAW11Ar06WvtQNh4TFXp1POTPZPaWl
         eRKA==
X-Gm-Message-State: AFqh2kpimI7YVgMamPcDFARxzQOPNJ9NxAAgB5B0DR2lBOYQWGTwXAif
	U80utu0PljHYiJOc/c80XL8ryExoDAOc/GICpbQ0dKH+VG26vg==
X-Google-Smtp-Source: AMrXdXtJ8krMv57QakxtqUU3skxQLn16Enph3eOKJbhP2jtQpU5Yt0+w5YxcExcvRrFo+DexGx5p9sivWSQuHHYN1SA=
X-Received: by 2002:a05:6402:1f02:b0:47f:6531:deed with SMTP id
 b2-20020a0564021f0200b0047f6531deedmr1001237edb.154.1671985986313; Sun, 25
 Dec 2022 08:33:06 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Warner Losh 
Date: Sun, 25 Dec 2022 09:32:55 -0700
Message-ID: 
Subject: Re: Disk partitions disappear when mounting others
To: Alexey Dokuchaev 
Cc: FreeBSD Current 
Content-Type: multipart/alternative; boundary="000000000000c8b81e05f0a9929f"
X-Rspamd-Queue-Id: 4Ng60h1f9Gz4VMV
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000c8b81e05f0a9929f
Content-Type: text/plain; charset="UTF-8"

On Sun, Dec 25, 2022, 1:02 AM Alexey Dokuchaev  wrote:

> Hi there,
>
> I'm in the process of moving my data from a dying HDD, and just noticed
> something weird.  It's an MBR partitioned drive, and there is a FreeBSD
> slice and Fedora LVM in EBR, accessible as
> /dev/linux_lvm/fedora-{swap,home,root}.
>
> The problem is that once I mount my old FreeBSD partition, e.g.
> /dev/ada0s2a, those LVM nodes are gone, logging this:
>
>   GEOM_LINUX_LVM: disk pv0 already initialised in fedora
>   GEOM_LINUX_LVM: Disk diskid/DISK-XXXXXXX1s4+00000001 removed from pv0.
>   GEOM_LINUX_LVM: Device linux_lvm/fedora-swap removed.
>   GEOM_LINUX_LVM: Device linux_lvm/fedora-home removed.
>   GEOM_LINUX_LVM: Device linux_lvm/fedora-root removed.
>
> If I unmount /dev/ada0s2a and mount any Fedora's partition, then I can
> longer access other slices as there's only /dev/ada0 remains; ``gpart
> show''
> also does not list them, but only those under diskid/DISK-XXXXXXX1.
>
> Why is this happening?  What should I fix to stop my partitions from
> disappearing and reappearing?


Something has them open. My guess is the Linux lvm geom provider opens too
many things. It's been standard geom behavior to remove the other device
aliases in /dev when one is open.

Though the problem may be in tasting during open since gpart list shows
them gone.

Warner

Thanks,
>
> ./danfe
>
>

--000000000000c8b81e05f0a9929f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sun, Dec 25, 2022, 1:02 AM Alexey Dokuchaev <danfe@freebsd.org> wrote:
Hi there,



I'm in the process of moving my data from a dying HDD, and just noticed=


something weird.=C2=A0 It's an MBR partitioned drive, and there is a Fr=
eeBSD

slice and Fedora LVM in EBR, accessible as /dev/linux_lvm/fedora-{swap,home=
,root}.



The problem is that once I mount my old FreeBSD partition, e.g.

/dev/ada0s2a, those LVM nodes are gone, logging this:



=C2=A0 GEOM_LINUX_LVM: disk pv0 already initialised in fedora

=C2=A0 GEOM_LINUX_LVM: Disk diskid/DISK-XXXXXXX1s4+00000001 removed from pv=
0.

=C2=A0 GEOM_LINUX_LVM: Device linux_lvm/fedora-swap removed.

=C2=A0 GEOM_LINUX_LVM: Device linux_lvm/fedora-home removed.

=C2=A0 GEOM_LINUX_LVM: Device linux_lvm/fedora-root removed.



If I unmount /dev/ada0s2a and mount any Fedora's partition, then I can<=
br>
longer access other slices as there's only /dev/ada0 remains; ``gpart s=
how''

also does not list them, but only those under diskid/DISK-XXXXXXX1.



Why is this happening?=C2=A0 What should I fix to stop my partitions from
disappearing and reappearing?
Something has them open. My guess is the Linux lvm=
 geom provider opens too many things. It's been standard geom behavior =
to remove the other device aliases in /dev when one is open.=C2=A0

Though the problem may be in tas=
ting during open since gpart list shows them gone.=C2=A0

Warner

 =
Thanks,



./danfe






--000000000000c8b81e05f0a9929f--

From nobody Sun Dec 25 23:28:38 2022
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 4NgHDP5NJjz1LgB9
	for ; Sun, 25 Dec 2022 23:28:53 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NgHDN2qt5z4Ky7
	for ; Sun, 25 Dec 2022 23:28:52 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=COZDMyCn;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672010930; bh=Em+YSFOu6p5hjWga+Uh4r29GSZUyiZBRHSD+YZLCyT4=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=COZDMyCnCRC4UIlCP1gN+otoWjIWrjPWNJjtJhSTU7e0HY9ciWbjTVvNzzC1gDLFbeHljeP5IGVEQy1G46iwJX/HTnjxBlvHK3NWIra2V/1zDxYdhVIEdlIwWwDLqQFuKtClZOO9y2Aj28UaMdyM4Op3Gt8tehd1MCHIrtVavYmQXMMO0SDTWNi+ghojvwPtfzF9+vrEtOVTfmeY4x/2WL4gMldS+Ty4dOKZnPww2KBHPE2Umq3ohQgk1Vn8hCs4iCLdFggLbxslQEbBFHm5KmcqN/Qq3YRSyHGJlR3S1kW+tPvcU+ctYvs+fnGPKeclX22dTNGb7e/VhjJtRqR5Bw==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672010930; bh=zjeXx8uT6lE2tGK3r/oUdTIpw/YDo0lfdaqtEo+r+oK=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=GW+bJrEWG9b4xuCne4peqF8UbUZ9H2dmNjkMKGfSxHohvmoeIQaYzvzJisIf+NXaFjXBq8y3NF/jsG11hkuXWKkGSp8696076vyuzei1oK4ACcKqaZIjaTBe48uDk89QKc0+YgJAmxM84WOFwL76rOxjYtlkcgTORN6ZcsEMOnqMcBY02eU86oL2gBqfYMw/sOt+0jqToEm7u+AhO739xpBZByRdYDL05UtxqGRQjkRgUYb05oPzzoPDb1XhZEhJmNN0Lnau3qhReYBL+KtYj2BNkZ9MCXzIKb3ZkyQ2/+nqI1tpGPL0+frnqxXXYx0JzL1iFXv8w/6PgqH+xXPlgQ==
X-YMail-OSG: 3NXPc3YVM1nABw_9kLWOgmto7gmUroKXTNREAM3AvgYhp1VbcRtVQLT98zEnfg4
 4jUukz00DYX8zc0pFbQnwWT12OfrC8x0nraXgAeuVUFCz.AtJFMqmU8ARICaBnZTWYGFixvjUm4G
 7OOehqe7apDXqMKqJs.9ZMRrs17wherAFHk_SWhqquQ3AmtyJKIoULKTrseKClvKJz42Do.p_SpY
 ZbbCSkxqK0wOKB9vn_GHa.UEbADfvccfpY_Q.BSgYR0weySrm.CYICUO8ujOVeVpPlS6Sq7qW_00
 o_5gtJK3hbOwcXl6S5JZRBDbFfGLgEfS_Mzwt.C2YY.Ov.dDj7.3Odok9.q1lcvlz.0KAIR8W056
 zx47lyAEksvRav4EUiac_broRNAVq.DBp0vcmVZCV.3fuQ7pqM3BLaHg3LlQLw64LJfORoK559cO
 7xvkR02CO.OCJfK8RXY.R6HfXmIA6sQKdkAQHkrFIm5h42uuZfa42w8ZEvbFzP3i0wBNkEVFnrLi
 UKYJRsh37bSgOD8U.qpRxnubbwWjxy1fRxRqNnSMe0vEla_FYXtXF1alpM1ru8Rqe7qOvDFuqMkr
 4MuQlQm2ux6LkKe9ogR03W1Ka.GrZ5MmRiufYEd6jEBfVgFBYwWgdzxMq4CaxDNirk1lK_ecE9mV
 fS9xT3PzLps_nnkjBUY40XovrCsPZvBkBa5t650BS1WRTaEto7lVUp56.G.Asg77gFylmg9NYmCE
 VQn8ecPXPPPGeK3TGlxSVzHcEaYe_BA0VIq.LOwsWM6NLxT9zO.7x9FDuX9vYXyx7gk7VfjSiPyG
 aVbnN99Bm2qPreKbH55aqkDSSTzw.e2xBaj5uyyzE2WNxluyCy4yOzfNO1iKpxZlhM1N5x0GpKwO
 vQa4tRQ_C0Re6k9N5QWPz.w2EdiqzukTkRKWaxVVEidBUKgIKFpbAcmxA2JdUrxyNM.Jxex0_1TX
 l.HeHCs24LRSJ6ypVn1cCuuD5D8XB1CHwwBTfDMvZK55WVuJqECw4I4n4Okb23q210pENR.kYTah
 Ze.2a0QUxwfaHLepBoAMm6f4MjXxppxbbEFAbP6FEVeCU9bnFLKD4hNKYm1R0XKAugKbn6mKAIiI
 zbAEdztz4H71s5OajfZ2CNoo4lrx7bcESc1TfjwQvTxlw20kaRm29jIaLeLPyDLQfCcDaR9XVJu4
 5J0GjQ_q18bU13q6GMcojvo3WUsZGHCXH0uNnTnIfwkZJ8CG2O020OWx5ZgbeW3mYloOXB_P76cL
 _Hkxyi.WwJz7UTN8eMN_YOIEl2vLuzCL1ESKx47I36JWTa9JXZdM19iNiIswLfXDWobxsDjZEmuu
 q_h3yW4YrR6wghz_acw9K_lm8Ft7clRCRwv0lKXstSiI2H6gMy8bxy_hCINVmlW1Z5TqzYJTyJdd
 cn5rjQSwhbSuUL8Wj4pZ0TdgzjQ.O9txl_MdKhexepKQBf2dzzjtKqHDGJtw8_dKXYFs1fU1btfw
 XzD0d9xMgZLBGfANIl0KNIViuwPmk7rUSb6haTdQlIdFXMTnbwZd5xruvm5e2NHHgcNvENjIAGSe
 AU2rhSFVdG4DPCVzfwIHxH_CBrVmpA8my4vDz37EW1WlLi.W.sTYWWXGyGxZ9y.CokyrSFXX_eBO
 gNq.JaENypL_qCp.BWf3Fv2N8uJP6drJsoepGj.B4W1lFV_0Me02.TcbX1Kc88XsG1rL.4._EBWj
 vhkuk.6MMH0j1ILh44KFEifgpkv9IsPvUWFbZulTnzud0e7tG.eVnuGVxTKFgnw72DPCld4hRXxv
 _tYVtxbUflZ5DwsZHf1QULzOPVeS6LrVpVwRj8Jg6avnxLBLznQx1pLVgVbIBEMiUI4ovEL36vW0
 rDPaGVGGtn7Ba56d9fOaKB0UaBlux03WyyX7rtFF4X8NQCHFqpu_ghkpExWAdUmUpZVmRn1QwKW1
 QDaYsgNV7oucoeS9CWGcqBJ1lZlZ268oCtpsTcIsHnSH51QCKvNwejlR8nsP_fs3J7_twdUFXayo
 M5.G29xf5ZkzzF5HFLSdySkrETYXdOKM6Ysk3G7uiBnY7wmSgdGQlhGA8njaN9_mBcGar5uXTwYo
 ALrFIoWl5F0IvQYs04J9fHU_t4Smxx6ylTHK1w76_Z4fabMm_lUY79.KAQakRRq.adM_d27rjgIK
 iGYYRa5fXXU800IDlK9yoWFjGT7WC_G_8L2DY8g6M8WqIcIY8PEldPcWQ5jrz18PODBGByvQ4vax
 DaYHx6UP7VUs9gdQ0L8Giuowjk5LCRS0oooub8Q.Fu_Ofb4krAaXnUQbIncL3vANpNU3wot8L2ek
 -
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 25 Dec 2022 23:28:50 +0000
Received: by hermes--production-gq1-d898c4779-wpm62 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 51a9335efac85295b6afc7ab901b2c11;
          Sun, 25 Dec 2022 23:28:49 +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 \(3731.300.101.1.3\))
Subject: snapshot 1st aarcch64 boot got devd error message: "sh:
 /usr/libexec/hyperv/hyperv_vfattach: not found"
Message-Id: 
Date: Sun, 25 Dec 2022 15:28:38 -0800
Cc: freebsd-arm 
To: freebsd-current 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
References: 
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.991];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from];
	TO_DN_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FREEMAIL_FROM(0.00)[yahoo.com];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4NgHDN2qt5z4Ky7
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

=46rom the Dec 24 main [so: 14] snaphot for an aarch64 RPi*
system:

. . .
Starting devd.
genet0: link state changed to UP
sh: /usr/libexec/hyperv/hyperv_vfattach: not found
Starting dhclient.
. . .

This seems to be from /etc/devd/hyperv.conf :

notify 10 {
        match "system"          "ETHERNET";
        match "type"            "IFATTACH";
        action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0";
};

For reference:

# ls -Tla /usr/libexec/hyperv/
total 8
drwxr-xr-x   2 root  wheel   512 Dec 24 06:30:06 2022 .
drwxr-xr-x  10 root  wheel  1536 Dec 24 06:49:40 2022 ..

I do not know if the error might have lead to skipping some
other activities or not.

Note:

This is from a test where I'd 1st side stepped a syntax problem
in /etc/rc.d/growfs in the snapshot to try to see if the growfs
otherwise worked.

# uname -apKU  # long output line split for reability
FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
arm64 aarch64 1400076 1400076

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


From nobody Sun Dec 25 23:55:30 2022
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 4NgHqP5sn4z1Lknk
	for ; Sun, 25 Dec 2022 23:55:45 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NgHqP11Dzz4PwJ
	for ; Sun, 25 Dec 2022 23:55:45 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ed1-x531.google.com with SMTP id u28so9085792edd.10
        for ; Sun, 25 Dec 2022 15:55:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=ddq7biMjkEHbjOp/GIOt3/6DEeCXpL+Kl8dJdU9OZ2w=;
        b=gFnVHtY6EQRvgQNSmGCzsV/zZKsi9U2kBulTG7V7Y82bB2Vzzv/RjNT6xbM/I5CjpD
         Wya5+jXaSdjmyHpSlV/erT70UmfiQN0dYNhcPzTPV9I5PsWAIGOh2RobrlqPSW70/+ti
         G1tecD7K2icqIUW7MeZHxV7TNza2OS/c6IQ4lpYSo7g4ROKeBsjHhO6tTttP+rFDPysm
         /yZ+TGuRZHtbMaLCIATq/oC7FILmMLCdPG+8+bWURYf7/BwPNbIJxDwgrx3Q60qCTIiW
         fCv6ZD0AWOREwF4KcRxOrrKZsoOmrXFD38+8g/p6LmijrCpazeJuVJAFmPLmjmFZbARV
         IsQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=ddq7biMjkEHbjOp/GIOt3/6DEeCXpL+Kl8dJdU9OZ2w=;
        b=DMljlWUhljkjWsrHB5hzhbtc7xy3LyQCV1GJHZ3vUcyxb7X2U/39U7fPnNDIKom4Mj
         A61Yfl1+US3BNARw1k6+IrPTkRCVkksKKhuMZS3c/IQHy6XjEcxt1mrVzpzHVHCV29J/
         9xn1nVvykCM/57iaWMViJZ+aoJ810nw7Eu+OGuP/hDjePPdZo2jyOckAVZMgABqt/tCa
         PV67rmW1AkZ7BKt8TMceYq2szcg69JJcg8oFqC0Ih/X/YBNBUEHKYLirbfTPSMe9Mmne
         rJwFEyiRGhz2bgXgvxSH9lcvc5CwS+igPLA+HgTWzfL32tLkHEKnKZXiq/PNQoBGIbM2
         Cxzg==
X-Gm-Message-State: AFqh2kqKWoZlf09p6TujkEkKOd526AmOrhrZKWTVxOgtSpqJhuEsj3wA
	daXPczuVeXDSNyUjNuBNSPgsMjFmKtpERx77AmzbPxe81/ca2A==
X-Google-Smtp-Source: AMrXdXv2QLNj++QRh+gYtQhGNy1sMjIFJB+7IZyROcf7mEU2qB+dwiNBvRZbKcUJ1PRjDLzARsFhYW+DYj8tWlLT0w0=
X-Received: by 2002:a05:6402:3205:b0:469:f59f:352e with SMTP id
 g5-20020a056402320500b00469f59f352emr1321136eda.241.1672012541474; Sun, 25
 Dec 2022 15:55:41 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Warner Losh 
Date: Sun, 25 Dec 2022 16:55:30 -0700
Message-ID: 
Subject: Re: snapshot 1st aarcch64 boot got devd error message: "sh:
 /usr/libexec/hyperv/hyperv_vfattach: not found"
To: Mark Millard 
Cc: freebsd-current , freebsd-arm 
Content-Type: multipart/alternative; boundary="000000000000984fc105f0afc157"
X-Rspamd-Queue-Id: 4NgHqP11Dzz4PwJ
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000984fc105f0afc157
Content-Type: text/plain; charset="UTF-8"

Most likely MK_HYPERV is defaulting to no for aarch64? Or there is a bogus
if MACHINE_ARCH == "amd64" somewhere.

Warner

On Sun, Dec 25, 2022, 4:28 PM Mark Millard  wrote:

> From the Dec 24 main [so: 14] snaphot for an aarch64 RPi*
> system:
>
> . . .
> Starting devd.
> genet0: link state changed to UP
> sh: /usr/libexec/hyperv/hyperv_vfattach: not found
> Starting dhclient.
> . . .
>
> This seems to be from /etc/devd/hyperv.conf :
>
> notify 10 {
>         match "system"          "ETHERNET";
>         match "type"            "IFATTACH";
>         action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0";
> };
>
> For reference:
>
> # ls -Tla /usr/libexec/hyperv/
> total 8
> drwxr-xr-x   2 root  wheel   512 Dec 24 06:30:06 2022 .
> drwxr-xr-x  10 root  wheel  1536 Dec 24 06:49:40 2022 ..
>
> I do not know if the error might have lead to skipping some
> other activities or not.
>
> Note:
>
> This is from a test where I'd 1st side stepped a syntax problem
> in /etc/rc.d/growfs in the snapshot to try to see if the growfs
> otherwise worked.
>
> # uname -apKU  # long output line split for reability
> FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
> main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022
> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
> arm64 aarch64 1400076 1400076
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
>

--000000000000984fc105f0afc157
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Most likely MK_HYPERV is defaulting to no for aarch64? Or=
 there is a bogus if MACHINE_ARCH =3D=3D "amd64" somewhere.

Warner

On Sun, Dec 25, 2022, 4=
:28 PM Mark Millard <marklmi@yahoo.=
com> wrote:
From the Dec 24 =
main [so: 14] snaphot for an aarch64 RPi*

system:



. . .

Starting devd.

genet0: link state changed to UP

sh: /usr/libexec/hyperv/hyperv_vfattach: not found

Starting dhclient.

. . .



This seems to be from /etc/devd/hyperv.conf :



notify 10 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 match "system"=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "ETHERNET";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 match "type"=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "IFATTACH";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 action "/usr/libexec/hyperv/hyperv_vfattac=
h $subsystem 0";

};



For reference:



# ls -Tla /usr/libexec/hyperv/

total 8

drwxr-xr-x=C2=A0 =C2=A02 root=C2=A0 wheel=C2=A0 =C2=A0512 Dec 24 06:30:06 2=
022 .

drwxr-xr-x=C2=A0 10 root=C2=A0 wheel=C2=A0 1536 Dec 24 06:49:40 2022 ..



I do not know if the error might have lead to skipping some

other activities or not.



Note:



This is from a test where I'd 1st side stepped a syntax problem

in /etc/rc.d/growfs in the snapshot to try to see if the growfs

otherwise worked.



# uname -apKU=C2=A0 # long output line split for reability

FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0

main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022

root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC

arm64 aarch64 1400076 1400076



=3D=3D=3D

Mark Millard

marklmi at yahoo.com








--000000000000984fc105f0afc157--

From nobody Mon Dec 26 01:23:22 2022
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 4NgKmr41dgz1HGbC
	for ; Mon, 26 Dec 2022 01:23:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4NgKmr1St2z3MTS
	for ; Mon, 26 Dec 2022 01:23:40 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672017818; bh=Ae2waz8ZF+dQ/6qylM/+6wPQxnmrpn0i1GFMGQLH1n8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=p46ekyY5ZaoWNfhquVE6+GEQzrhiVrn2NKEPeug5l5TqhHts8S9m7yftOiloLtVj2YYOI65CgQ18oUl2Naony3C2E8mVIiNCdkY56wdKhpv67jRYKxYMjB53AxWudiEmQzhgP2y8KNOTMjBc0k5UPkIwhWRV8hIXSnfcheo05D8HDaiqJqIagHFw87LOitz7EDBj+ayqNeG7YDQk1vmc/hiOOQoLiIEU63pCVenEbWw2UWIQSaaZOa1d9Yi7FU3H+z8yEP4ox3LKrZpa131xqNPO1Y8wngepxepp+eXZ6/mD8sfH8/hisIBocnmBe88wrJj5atZq4Xt6XBnKDSzNFg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672017818; bh=9XKVhp7MxXzO7Y5pOm6azNyFPycvDIj3mwx4WOUotSA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BQY2yVlga2rkGSnpD+b1/aiYAkRnTPn3dHSyd0GEGVutNlgccqy006TSFgOY3h1B+nWA1YEFywHSX8oaYX4FhZVGenTGBh3lJwwahhLboKLCqh+zZkJc2srZhszuxXPm0wxVr9XBGkp9NAdHyEJLBqP3xhEoOVitykC+5kFC3SWEO9eDy44ht4sCgBJX2jc6WeWYjFCWppk+ll1+/sSB/MMnCydQfv7RceIa7PoyZ3QejAiu1WQpLFE6m2Hp2unE6VGIsWUHlBVWOco/KTIiXhi1AHXhhtzkufHwfyMgU6YsOp/d6X2TatIvmF/umaMVqtFe41w2hOczKOwGkoo+yA==
X-YMail-OSG: PBUQtgcVM1nvhxivt2a93APtatJXG1bnbNSdAVnrLKiZAyVZQaJQfP7nrP8VTuX
 BdpYiCtfJyrd_RvuhWdEHyDygtcXdRnRZeSGQJvhanNpnyordBElS7UjhhHWKxNjN9jpAcjUPejB
 Ly96R0IcwD1RRCTSzNa3CHUk9puqJ5YRVy.uiUVMdZuw13dBdPSnQFvF5jt5F8UtQfPQkXbAJq1d
 pn5ncX85jkI4k85WzU00VtfUb8gw6b53tTykWf7W0r7RGvLejmAqEKY9B_T6AP6jNICE3ZvDIT1k
 JNLD0mRGu7CkpBxZkcznsW_g6eZMSth1vTuiEdxRugTGiXSzMhJXdtJ8QbEzDyUfWrtfdb2APJzK
 8jj_jEejjo4yBQhnQLS1nJt.7QsrokbBO7D8MEltKB3ei7gb2iXe1xNDPXH9l5sTA.mSHKS_vL6t
 FZEGHkP7Gs0G4sowcxLUttIjK__zUTEC890b5JMYvLWL5TDY3ZiKCsR_G76gADmFIDbu5kvBt.rN
 aMtMhTP2ngvtdUnX9ggWiu4uTv3u_XcI4iE9pxOIOek3vRSKNsL7J6v1JwA7U5adXqCM3ZCk6SoR
 RHI8_RlL970eu.kqsmJuJPCpXJuPjTmz7JMEgkLWYTRvLmrXh6ioKF5sQYeXiV0tbrnZkV3aBvdp
 4eeraUg2uX7MFaSjKvnDozEPCc68zWqpAzZe_T6pw._qTZ.eXQF9atGqKg1l7lpCoVbj5tk1zZ4o
 JWBs_M8NaSq5AHc93DddIkzNSF3alLE7KsO00maMeToNrVKBIDZQj_4SqJvB6Tlwyg9_B3NSeIWu
 a0FWvDsv.vpXTW7S0Vgef9lDFigGLsuEmjelPA6.5M4nAXiZziQarpIYtuyUDuooOpSeWxTUCv_4
 5De034Q5r00d7sTNRVYBvg_0yeY8z2VEljH8aYjUNZX4nAPoEHl_u0Cx0efdwh.FwtwxYbSbZ3nc
 AwfSaoeyeRXXBKspv0SxoxZ5R0e4l2US0R0LLfY_VJBXJG0VnKGJpUdfmy8jLC7X1I_mqmUKmD43
 LPodTFKUFPhDinUjRHZ9CRXBNeTxroGiBiABUTVOZKVDflMZr_L0.usNicKdZoKjGpXVujjEQBkF
 elwZvpjOcvlDzWJ7ZT1z.QdEczKRMQ2FqQhYVX6KWqVDrb53lHFYL0qcPLcyjijzDeIt6bwSfM6B
 m64iTXb8riKPhjN..fcMHXbI22ZYNNCtrrSCMbMD8H.2Vht91YOD_atMvZX6T3JIrll2XmHitoi3
 knmz1RBJtMwQg5.do9n.K0LRdX3t4NuNeGXs8yQAk83qs2XRw3Jf7wZiGPh_K3LmNsTZ0dw_oWby
 kTOCpKk59HOQyjxB7_nYSBqZ_1utx0UOOvuVKDB7G6hMP0ncomIX749bfc0ROx3deZpcJizRdFFW
 dsBjWj8l558Tgeehj8DTx4xWkKv8wpAarJ3FT2.aQfAswNQyWn2Tw3fSVxG4ipwV.Kk0PDVsDnEB
 HfnDjRzb.PglETebfuYZvsF8Nu8evhtLkt1nW4Nz2J_7Zzm5nCgMOaFp6CvM0rHq5BiZN9yOf765
 ni6RUWKmVBVxGHIHWIINHnQrGyRgOG2uumAzqAdn3CXEwTcWdHc5398b3KMyhf7xbHIPxd1nFklJ
 N1VEfYADRt6lNv5rOipLILeMRON7w8TinPhWZsC.1lXSioUU9FdXh0EcMH3ga_prvavbIhsbRkZS
 cR5.gy3zXLxI5Wzk.VpKZjn0lAA1S.kZDtBmjqeR18cKTG.csjZlFwWsLxMh.yEBBDk07AgYMCQH
 AodGdcZfo9K4U4zFxoS36HPbYCPtqsAtEmty1qM7JgedqaSXGSauNPvjjEykAA7cPNxJ3ZUJ8Ajl
 IRPTH5RbZgeKnfeSOOW9_OsXnTbggNMSPbS.AdPgIG6PfvAHmGKesk3VevH9uVgKhX6.vQYekC_e
 nf3nBIww2qc1upAQ88H8nyzWC2FC4J9nFsTy0DkFUYZDEoTTEXAdjJBsZ.6OY0onNxWN60zIBU5L
 KF4PGq26vWhLu8ZYSgW0k.tvf5GLqvXM_St0eKAisc0bbncu9rZwFZpHiR9clHBZwon7ieewLiKR
 j8Gx2.fQXarXZUXUD3FArsGxraXs60zh8sIjPynDLQ_yPRmfvVZclTIIpIYWhv8XSr3k2FupehBL
 qX8Xz9EiyRk8mnkhGup.VdV0.CH0sdQ45ePMgy_B0VkthCAAFuGa43Qpi_Jgf3OENeu8XmXI9dmv
 2hvTude5x5qxINT.gsX5YQ6nk4E5CNTi9LkokYpwfNZfjEee6akcb2qFVPDMjVye0IfxKbeVAU58
 A
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 26 Dec 2022 01:23:38 +0000
Received: by hermes--production-gq1-d898c4779-9jfqr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e52595520abca9777e47cd8c14d51972;
          Mon, 26 Dec 2022 01:23:33 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
Subject: Re: snapshot 1st aarcch64 boot got devd error message: "sh:
 /usr/libexec/hyperv/hyperv_vfattach: not found"
From: Mark Millard 
In-Reply-To: 
Date: Sun, 25 Dec 2022 17:23:22 -0800
Cc: freebsd-current ,
 freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 
 
To: Warner Losh 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NgKmr1St2z3MTS
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N



On Dec 25, 2022, at 15:55, Warner Losh  wrote:

> Most likely MK_HYPERV is defaulting to no for aarch64? Or there is a =
bogus if MACHINE_ARCH =3D=3D "amd64" somewhere.

Well, seems more is missing for aarch64 if devd hyperv is to be enabled:

# grep -r MK_HYPERV /usr/main-src/ | more
/usr/main-src/sbin/devd/Makefile:.if ${MK_HYPERV} !=3D "no"
/usr/main-src/libexec/Makefile.i386:.if ${MK_HYPERV} !=3D "no"
/usr/main-src/libexec/Makefile.amd64:.if ${MK_HYPERV} !=3D "no"
/usr/main-src/usr.sbin/Makefile.amd64:.if ${MK_HYPERV} !=3D "no"
/usr/main-src/usr.sbin/Makefile.i386:.if ${MK_HYPERV} !=3D "no"
/usr/main-src/lib/libc/x86/sys/Makefile.inc:.if ${MACHINE_CPUARCH} =3D=3D =
"amd64" && ${MK_HYPERV} !=3D "no"
/usr/main-src/tools/build/mk/OptionalObsoleteFiles.inc:.if ${MK_HYPERV} =
=3D=3D no

(The below is based on cgit.freebsd.org  in =
case my source tree
vintage is problematical.)

There is no libexec/Makefile.aarch64 or libexec/Makefile.arm64 .

For reference, libexec/Makefile.amd64 example:

# $FreeBSD$

.if ${MK_HYPERV} !=3D "no"
SUBDIR+=3D hyperv
.endif


There is a usr.sbin/Makefile.aarch64 but it makes no
mention of hyperv:

# $FreeBSD$

.if ${MK_ACPI} !=3D "no"
SUBDIR+=3D acpi
.endif
SUBDIR+=3D ofwdump


By contrast usr.sbin/Makefile.amd64 (for example) contains:

. . .
.if ${MK_HYPERV} !=3D "no"
SUBDIR+=3D hyperv
.endif
. . .

I do not find an aarch64 equivalent of
lib/libc/x86/sys/Makefile.inc 's:

. . .
.if ${MACHINE_CPUARCH} =3D=3D "amd64" && ${MK_HYPERV} !=3D "no"
CFLAGS+=3D -DWANT_HYPERV
.endif
. . .


> Warner
>=20
> On Sun, Dec 25, 2022, 4:28 PM Mark Millard  wrote:
> =46rom the Dec 24 main [so: 14] snaphot for an aarch64 RPi*
> system:
>=20
> . . .
> Starting devd.
> genet0: link state changed to UP
> sh: /usr/libexec/hyperv/hyperv_vfattach: not found
> Starting dhclient.
> . . .
>=20
> This seems to be from /etc/devd/hyperv.conf :
>=20
> notify 10 {
>         match "system"          "ETHERNET";
>         match "type"            "IFATTACH";
>         action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0";
> };
>=20
> For reference:
>=20
> # ls -Tla /usr/libexec/hyperv/
> total 8
> drwxr-xr-x   2 root  wheel   512 Dec 24 06:30:06 2022 .
> drwxr-xr-x  10 root  wheel  1536 Dec 24 06:49:40 2022 ..
>=20
> I do not know if the error might have lead to skipping some
> other activities or not.
>=20
> Note:
>=20
> This is from a test where I'd 1st side stepped a syntax problem
> in /etc/rc.d/growfs in the snapshot to try to see if the growfs
> otherwise worked.
>=20
> # uname -apKU  # long output line split for reability
> FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0
> main-n259842-c89209c674f2: Sat Dec 24 05:52:28 UTC 2022
> =
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
> arm64 aarch64 1400076 1400076
>=20


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


From nobody Tue Dec 27 03:54:57 2022
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 4Nh15K5m0Pz1LgFn
	for ; Tue, 27 Dec 2022 03:55:17 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nh15J3DDZz3nf3
	for ; Tue, 27 Dec 2022 03:55:16 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=LvWYnPSm;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672113313; bh=AV4sxJW03eL3GuLcaC48+nZD6+5ZD+LP7e5lJP5YRdU=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=LvWYnPSmEpCwqZzvGN/MhfLlbDOtnlNRso5DOnKPV44ie2CcXLuviuVOSLfAhpBs6YL/LK0xFROpx/wBnZ9fJsZ09CPZ3Jr/+2uAsVE3DnOLGMR9dj9TABXorJsfcjOTGt+zx0yjxhTo6PMQxKwAESBbpxE74Z5zKqex5W7LvI62acFhwfnVMhQMaB9xhlHhTxtKXTcC2K0rAQpRPthQ3aEzaRH0vYdOQg0J44Kz4YAYJeNGcsrWjvrOLyCcrU+O5TzDHDbMenX5dPXi8OgU86dxTfPXvO4bb5o7mYmw0A/aNk4xYNn7Lmo6CKjF4CUZwcOZTJIBjYpj1KbSA9HIGg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672113313; bh=H+H3u6TdLkUKTRYKTGSQZqu53t15TpQoYy8zfMxJDay=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KeocbQvY+gN899DxZ5mWvNwuhicDa3sEnvnhPTEr9gzlqC1lglZZ8ZoP5Kzy3qI8+XypgVL/rYQbL3ylARksrGsRamSQh5/g84yfMqDsQqcXSKeLGmsXRo0pxcKbsrztDaVmmUObB/l/1bQSZ0uEowfSw70AHGsUzDhJ/Dscc+13azC9E3Wj6rSMP78OP2NKccMA2QJJ6aSzHurKepcDiU4GX7JrXe5NfFGWKp2JEpuRv1AmGT4alkZJWpKj2K6hZBGhiSQBP8MZ8wxCnA/d9/X12fs7jK5HuKB62e2fVtdxZx0dusol60kkf4gNQqNprkEVMJlkxlH3G+CrwOB6lA==
X-YMail-OSG: H21SoT4VM1mO1rXFmij8Ua_xG6ibk.mDo6uD8W9lzc3AdB.eHebP9vV2K.yY5fC
 V6XUObX5nV514NViq6smZ0aigjD05xulZfWAwxWy84xhK6uXumTZOOoxLvawYoYHQnR0w05X2Aza
 jt_bMYnFu82Uw2bextknGR4sAHEI.QE8Ree6P85i1tZTGnq35YSLZKNVBvFxQ7a86g.SoeneVsK7
 TkchjRrcMRmFqnPsJxaRsi32dzqxUCLmRQawvYlFqhmXFAWsE7bkAHtjRZDkbdwcFQ50VsQLPTDY
 a305fwBP8VLxh8BNAAhVEvxaGcx3j4LvewQuwJgvJucErG6zVWSqgs19odC04yurXe3dwIYtMIq9
 KoaOnU00w5m1y5jLtyRwgJxIdGSef7AFbpocnL11cJzwiL7VndeU.5I6v9cG27ytRBCznAdm3IiM
 hPbPNJ4e0C5EI4tixkWZG_ZCpOiu8VLJNG.mHxMxArrOdtM9bdkln5mEr2aEsx69tI3z1m_ygEmF
 i7Ju9zyvkdu1d5ewjlAVTFdUurIkav6YtfzMoI7HS_VgMO1rt3VlpLglQ8j_af247IRu.OEjuCdz
 obDFBJDXFyaIep8ZA_WaE76ahuriWVS4HBpVsvcHZ95jhT6HbZ5kTwN4UAcjdp5lbnagB9aWpsJ8
 Tm6HUjNz_fNRxi2nGbApJOb49EjsS0wAXiTXfCyHTHX40_vjVM5z1KnKUrpWptAvvTmfStlAFm42
 JhlacDPRZlM0eehlyKlfKksXYlYjgP8.s0sOOeZVHv9LiEo3m4VgK33y9_m4eGi5Q8ZGllJEQfz5
 Qd3XxgJfKAJHX9IJw3bh9mPgyNLWBuyj2cgBFjaTLecKushJA3yXCvJPTVJjh2nW9gXOLaf4iR..
 AjTbsJuJ5vmsXkRUo0DyUfHJJHGgMtH_AP3.9.1Kh9ewpfSX7DcuY9vdHNZ.IOI38ei4FRFpXaed
 qKmVAlntNWaswWdspOiQN8NObJrIBWeoAi83L2QwGtbCrluaREcy5RsBjnRnyfDkYs0VbYtHPgHU
 VBxG_AiKF._Eqx7kCP_1yItjpIcSpvpUAmaLNQBQ_rtTPDwmDx4xFsG82QAymDc0u6XxowoB2dyB
 oLDc1MfkYOTBoXB1I01K2cZ_F8zYvwGd_b7TZrecmZOzDQ9v6lRPhbMrvA4NNdy0Qt1DypFhCiw0
 jOJl4D1qOREyWqyiMHSEZPC2WmctCVUw3MFnG8YSMFDs0DyqHzngVMgYYNq3DPuPBlJyNqTLMgrv
 sDXNGhhmPpHrncjg7nXujsFY12YDNq.Erg0vTqqihtN1dMH8kotZ9.KxLcyIL1sJnE57_dlmjfiF
 B3ZK3VQ58EgLMuR20WJo6S346vRBMsYY8Fqjo_hoDeDPGYEsvjfzBIaXx4mRjjkFXg.iGmm5J_eL
 BC757hKcOJfLJMlywdUgWIZqqlm5G7tIHJdwIBBmfalsOYoIoLYQbLmDTY8oEnyRwHPZi2AmUuVe
 qOPzXzyI2UEDWstPXbTwKmGwOnA6N9atWSU1N1f2CNK.U_vUvz.OAexeGljWSEZiesc6lEV54vnX
 iYbih1UKkWQrqGm96Yc8BuT6JYMHTuY5y1079McgvNIF9qhpvvpYp9xmniFIfm7asGSGuRpbspdB
 1IPpVcpUh8SuWXiUbE.1KFC.0Q8EShiGdgSgAXGW1eORQSk3IbaO9.IcokgGwJv37Ji7S1fNkFW7
 AemtqyiwjlG6WEyB.pJf4hbiZB4dltC4DDWfFGJX6ZA8XGxrxJCji0byCte6pdDSJf1XjgBbyJdd
 uCflGjMEsgoPxug4aZE69qzf71znBh9mzUp.JoR3vZ9uC_skdi_fqmm7sMVLSYilI7hj49phht6.
 6AMK73b.D8oKuVmDssDzrwsL4O4EGvwk9cCv18ETD9Sjd85HJmM0XScF1P5wpXDTuVakAo81IjZK
 7nZbXprScqiqKpu5R1es3WNF._4Uwo9GtKUJVuw7_PYcwok0dv1UmsBbaHrehs.UJ6AOxjEyRrp_
 XsnhV2A0fZCAe0rAfeI91izIvlFMhovcYqvD.q967VX.3GnbYNmpiLQjWEOxFM_ZFepb0FgrFYy8
 N2aTES_SDeFJaDPmU9fz_HL06ogm9hUf2noiFIEFQLl7CCrLpjbRuOmFSAWsZqcCAKwDcwcmvhJZ
 8r2C1YK_bvpaSP7_ZRaleWHGJ63slq99eKmlao9PPT5dBZr7iwcJkjBHYZ8..BP48skh0OKB.EGE
 OLBYx3DD62PNKjAqsjxyg7LUJJIAHRSHM4H_8LaIZ0Qcbd26zesISqvSaaxsG5iCXcNFk3SsXdrZ
 niVIcCh_XsQ--
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Dec 2022 03:55:13 +0000
Received: by hermes--production-bf1-5458f64d4-kkg2s (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b27c0c01835962e0954ab5edfe5b1dcb;
          Tue, 27 Dec 2022 03:55:10 +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 \(3731.300.101.1.3\))
Subject: RE: ofw_pci: Fix incorrectly sized softc causing pci(4) out-of-bounds
 reads (Should  it have been MFC'd?)
Message-Id: 
Date: Mon, 26 Dec 2022 19:54:57 -0800
Cc: freebsd-arm 
To: "jrtc27@freebsd.org" ,
 freebsd-current ,
 FreeBSD-STABLE Mailing List 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
References: 
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]
X-Rspamd-Queue-Id: 4Nh15J3DDZz3nf3
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Should the following have been MFC'd? (I ran into this while
looking to see why I see a boot message oddity on 13.* that
I do not see on main [so: 14]. There was a time when main
also produced the odd messages. But I'm not  claiming that
this is what makes the difference. The oddity was observed
on aarch64 RPi4B's.)

author Jessica Clarke 2022-01-15 19:03:53 +0000
committer Jessica Clarke 2022-01-15 19:03:53 +0000
commit 4e3a43905e3ff7b9fcf228022f05d636f79c4b42 (patch)
tree b6be66e54604bb2c1fbdfde27bf8a6644e04fd05
parent 3266a0c5d5abe8dd14de8478edec3e878e4a1c0b (diff)
download src-4e3a43905e3ff7b9fcf228022f05d636f79c4b42.tar.gz
          src-4e3a43905e3ff7b9fcf228022f05d636f79c4b42.zip

ofw_pci: Fix incorrectly sized softc causing pci(4) out-of-bounds reads

We do not include sys/rman.h and so machine/resource.h ends up not being =
included by the time pci_private.h is included. This means PCI_RES_BUS =
is never defined, and so the sc_bus member of pci_softc is not present =
when compiling ofw_pci, resulting in the wrong softc size being passed =
to DEFINE_CLASS_1 and thus any attempts by pci(4) to access that member =
are out-of-bounds reads or writes.

This is pretty fragile; arguably pci_private.h should be including =
sys/rman.h, but this is the minimal needed change to fix the bug whilst =
maintaining the status quo.

Found by: CHERI
Reported by: andrew=20


Diffstat
-rw-r--r-- sys/dev/ofw/ofw_pci.c 1
1 files changed, 1 insertions, 0 deletions

diff --git a/sys/dev/ofw/ofw_pci.c b/sys/dev/ofw/ofw_pci.c
index 7f7aad379ddc..4bd6ccd64420 100644
--- a/sys/dev/ofw/ofw_pci.c
+++ b/sys/dev/ofw/ofw_pci.c
@@ -33,6 +33,7 @@ __FBSDID("$FreeBSD$");
  #include 
  #include 
  #include 
+#include 
 =20
  #include 
  #include 




(Note: leading whitespace might not be preserved.)

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


From nobody Tue Dec 27 04:21:27 2022
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 4Nh1gs1WByz1Ll6b
	for ; Tue, 27 Dec 2022 04:21:45 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4Nh1gr34csz3tZN
	for ; Tue, 27 Dec 2022 04:21:44 +0000 (UTC)
	(envelope-from marklmi@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=PyflGyDQ;
	spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672114902; bh=OO+RdfmwNO2UJG4xMFLyjjw5i+YqSt0w2siKzgQikbU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PyflGyDQ+ahvQo02jGk0PQt3qK8jnm7zEeShiFuVnWcUStfk0ycteKGglKgLpp+FQv/Hfi7zw9btBzzoLqT74/xlGO33w6hyfUy/ODl0dY5q1IyUH5k3wiFVIVlSEB3JTLPF7vtqEb2CDmJN0On1ZJHBusQlszHAxyR5PCsOcwEL5VHqo7fiacSBkiKiY34Lqn/1W6FCEHrRDMepDYLJbhvrzzON9YQj84bg+TS10BV++dqhzDhkgbmYNGph0muIXpoo7geYIxYniAuyRdKdoXtMfVfOU0jZM8JD2r4Xlh1rUzUmXxk7ZFQDFepaSY27TDl8Ne2s5r7R8JXVgRE9Sg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672114902; bh=6OBysDaPFPBYjrnorSerAOcMKScDU2BrWzoy/MPguoi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HeQ73Hev1kKsE3ndFbuLZf3cNRZzDNSxK1NIYTYtMLbQ28odYzfNso6OqeXb43nK7la8Ue8JsVf2PILGYGRos+u6Q3fEIPhp1/fyCkp2LfmLqQSuIs+u8Qgj2ePv1dLMuIhSFsj+HzGMHKnA4i6dxfkt5dQnbt9nfrEDjuhefqwdtgIrg0DSy8zWrqVWdXwx+6FGZNG8PPccyywa/9X9QXwt59d2kS3BMLpm8rUFHp/6Ae7WdthunaWEn/ZtfsFKmoLMXkTeGY23kF9WfD1sDu7Y7A4NQ19sK1P733b3RIPSdFTGjqxAh+3IA0vuMbTls9PvEfz3xa8Z1IPwx3JYGw==
X-YMail-OSG: BT4c6fYVM1mmrJ4mMmrZwMTOiEDN1RBK.gDiDSF2lo5TfDR8RcHMkhr2mzfp148
 xiyvFlFdYLQIPuUzNcOAU6wBGVJEOTJrS8K3LOeUJx5VqOu9DFjWy3fKKtgO8OtZMQFTaDdrvVEt
 gH0A3Rv5VbDRSfmxsQ9nv891xmwaglE96XxVAOSR7Fu1xOnXQGH68L05BCSxB_VrrakPhnDZ_.p6
 r63l6TilNoIItsVw59ZuX4NZVa711dTN6oBvZiR7O55T8SzelS5alaLhOEwXk_3cBxJl2bLNwE.F
 2XvPyI2PzNtJnbNWCaDzsf8Lt5xcX8qnNX850o7eO.cQgceHFhHYpH35QsCCxS3Ld_PoXaH39aUO
 YmdtA_dnmoKjfT6S1HmvoS4vx1xYf8Bt7wOOlPhWp7k9e.k3i0kuD3QA7C.rIdhknJDiGPqI.vT0
 rAFldIADyu3UdaU8TXv6GnxaQA10xSw8NKNwiWOXz3SGgOIEen6WNPzYo8BG8AoQhRux4t4.C9n.
 0v8Fb6X02HZW_5eWUjsUKWoqmS3fzrkEHaAfho72MAh0QUntk_rUfzrq.BIHMMIWnN8TlCcl1QDV
 nnBhXe2I55UGG8kUmVqzFGjYJS1R450t7wmFIJeH3pXiX1uOVlvtylkrLVe5osZXdFdLo2LNRBkf
 t.RnKHNMeruflYGx9Ds7EygeFhhu0EyDyZTVSejvD9b1LU7lcRMyMjaZB4wfLG2zoQP4m616VZtN
 kKSWzSqjJGR3iNbYqXyqS.miFZiDfBy4cnTsXzbul8e3NdAAl.5IL_0PKPd6e3hrn7Hr42x1cD8R
 ipYgGpdX.iKSq9goe116EDsIXm643EfXbw8CN3.yjh0j9B_4kajWprVXZSMU1aoqOcqk5mtTI_Zm
 zv5LBDB_MMjuug1FY8Vqfblkd2BuU6FZSOkxfPhFLvzhOAjNmAX4OWkFIkHjhGMo923FwVJoOXDm
 ScVAZ0spv8UjkglIWKWW11te9Hx69xZ1Sc7kXKYIkfXYVidfWiBhDfwJX7vgbyDLO4vwEGnA1bkK
 Dp3KYdRXvfRbKXRyobPgdJHk4g6VVg_dA13a8fsLX46cIgrcXPXPNFnd2_Ag9DGeLcZ2uaOd1iLS
 pNBfBb67pbZrSu.4rY24f5zH6N0Fvwqh1SEkzTxV1MqZVCmN6GEQn0OTzc2PDLL4Erz7L.ge.zkT
 us.CUtaffIGQntkGdXIAAJcRHUn9eYT_j2_NCfpNiBvCR.uAchcv9hODMuHEXeV3UhhMwbF_2t57
 wrgULBdcVMo4V3cVi56KdV3HraRiC3P9itIYL8YA0FtGfUeSAd8gYXQewhAyDJZPHS.A98_q3NuP
 dkPjTVgXVVL8t8Iqlm3Yjn2SF25e1C8RAFvXj3TOXIipfLMBCxjbIGxDcilWy98pIC8YJYY9Xh3n
 KDUvPe41KJ5Us9IBudBdP5EbNmZOTJ2MF0Gf56VG_RJVBoTCjDYp4tF_01BvmNxj9fIYaeCHLH4W
 LhXDTI9wXG8ejzTY2mt_Id9q8Q1ijp5Tm9lkyU3A02GHmSes4exCFtgNWXya1.OrM80WQquzYwaB
 Rc7lbn.NMk7NiccsAKD8dWeLG12vZIPrT2sXX7eKTAEpP6Spe4HFVd7kgfs7luopvL7t_Zpw9JGk
 .yAx1cKP.abIjxe_Xa9vrgto0LveHDe2CwlT.4igorG3S_3Xjw4IkrrxGHCQH1myut3nRDjmTk4Z
 KVVtsku4Q18z9AptehWaOcI.80sTn1_IQnfj79UxvcB66MnNeW5E0mhI6A.KH7cqI9nj5fIbhMBg
 IUSM2O9gY0C5tydQQMC_Klen5VQX33SqNfwEKVyAWW.v7hs5LcgRQ4t9nLiJgYr4s4Tm8cy8DiLC
 7WcKnB9LQi2r88pv7nwGQQbEB6euBvmOoTrUYC0oCQ7EdOcxWvEPjlUiiPRlim5zO6sRkgRFWKCW
 BKid4fTrgEAbqYvHmgElFtp5W2zl7l1OHMqhiz.c.7lPiQOycOwiuDRC2gMqgvxPXGhpk8ZcC0mT
 nJybhbvoX7avhh0Mwf2Yk3nlkimkjVu0s._Epz_5iG7_aknzr9UC5iBYK_mn2rFqat6217GgKYrY
 QAAM7zCEgMME0tJoEn2c7AM8OM9Ysva.6UdxtHkwcPJqMY_YkpyOY7JZLgkhu7PkMXZH.zJOhuXi
 m.wb_3YDyFY6xQ.LB8haBNwpeepN4GE.U4u7ZzpWyTnLdkaTrwiFZ3QTZQbZOZIYttUi.Y_d3Ice
 _QNLwT30ts1YhAA0wgjybC.JTuTd5NHe5ImuKsHOL3n9s9JJK8IAWiM8ot606FFtkIRR32NBx7yA
 ZflIpFn8-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Dec 2022 04:21:42 +0000
Received: by hermes--production-bf1-5458f64d4-46wzk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0a79607a9a26acb1091b4051c31df28a;
          Tue, 27 Dec 2022 04:21:39 +0000 (UTC)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
Subject: Re: ofw_pci: Fix incorrectly sized softc causing pci(4) out-of-bounds
 reads (Should  it have been MFC'd?)
From: Mark Millard 
In-Reply-To: 
Date: Mon, 26 Dec 2022 20:21:27 -0800
Cc: freebsd-arm 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "jrtc27@freebsd.org" ,
 freebsd-current ,
 FreeBSD-STABLE Mailing List 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Spamd-Result: default: False [-1.54 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_SPAM_SHORT(0.96)[0.955];
	MV_CASE(0.50)[];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[4];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	SUBJECT_HAS_QUESTION(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	RCVD_TLS_LAST(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	MIME_TRACE(0.00)[0:+];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4Nh1gr34csz3tZN
X-Spamd-Bar: -
X-ThisMailContainsUnwantedMimeParts: N

On Dec 26, 2022, at 19:54, Mark Millard  wrote:

> Should the following have been MFC'd? (I ran into this while
> looking to see why I see a boot message oddity on 13.* that
> I do not see on main [so: 14]. There was a time when main
> also produced the odd messages. But I'm not  claiming that
> this is what makes the difference. The oddity was observed
> on aarch64 RPi4B's.)
>=20

Never mind. I got myself confused over the history. 13.* does
not have the file at all.

> author Jessica Clarke 2022-01-15 19:03:53 +0000
> committer Jessica Clarke 2022-01-15 19:03:53 +0000
> commit 4e3a43905e3ff7b9fcf228022f05d636f79c4b42 (patch)
> tree b6be66e54604bb2c1fbdfde27bf8a6644e04fd05
> parent 3266a0c5d5abe8dd14de8478edec3e878e4a1c0b (diff)
> download src-4e3a43905e3ff7b9fcf228022f05d636f79c4b42.tar.gz
>          src-4e3a43905e3ff7b9fcf228022f05d636f79c4b42.zip
>=20
> ofw_pci: Fix incorrectly sized softc causing pci(4) out-of-bounds =
reads
>=20
> We do not include sys/rman.h and so machine/resource.h ends up not =
being included by the time pci_private.h is included. This means =
PCI_RES_BUS is never defined, and so the sc_bus member of pci_softc is =
not present when compiling ofw_pci, resulting in the wrong softc size =
being passed to DEFINE_CLASS_1 and thus any attempts by pci(4) to access =
that member are out-of-bounds reads or writes.
>=20
> This is pretty fragile; arguably pci_private.h should be including =
sys/rman.h, but this is the minimal needed change to fix the bug whilst =
maintaining the status quo.
>=20
> Found by: CHERI
> Reported by: andrew=20
>=20
>=20
> Diffstat
> -rw-r--r-- sys/dev/ofw/ofw_pci.c 1
> 1 files changed, 1 insertions, 0 deletions
>=20
> diff --git a/sys/dev/ofw/ofw_pci.c b/sys/dev/ofw/ofw_pci.c
> index 7f7aad379ddc..4bd6ccd64420 100644
> --- a/sys/dev/ofw/ofw_pci.c
> +++ b/sys/dev/ofw/ofw_pci.c
> @@ -33,6 +33,7 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>  #include 
> +#include 
>=20
>  #include 
>  #include 
>=20
>=20
>=20
>=20
> (Note: leading whitespace might not be preserved.)




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


From nobody Wed Dec 28 00:34:32 2022
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 4NhXbT6Vh1z1Lsh8
	for ; Wed, 28 Dec 2022 00:34:45 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NhXbS5HfQz3F6l
	for ; Wed, 28 Dec 2022 00:34:44 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=j+yY3GoZ;
	spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-pj1-x1033.google.com with SMTP id j8-20020a17090a3e0800b00225fdd5007fso4992856pjc.2
        for ; Tue, 27 Dec 2022 16:34:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=E6BXpk7cNZ+hD+Pwr+PRPQAljH32KZz8KSLiwjLHx9s=;
        b=j+yY3GoZcYrkRovJbT09XL9nxzw5VgFJOcQI4ase674mfDI0iLhsd3RSQE0oJ+7j0W
         pOST5uE6Ny4pMWAuiNtpWlvtYSAPY+rpQkCf1wAvQoTnhc9Gl32Y5F7OGYPSZ/fR6diX
         +uuPTWbDiOBve4ZkrDaKLNucZRotBXJ1xDqc/gXbQeCdCqG0Q6UDNQ2Pi8EsGLwExRiG
         5A1a/QzABEw0tfos/7KJdLMw7A9Jn9B7jMk99AxTsbvfZJHVAR8vowE1BOD8EWR9Uih2
         CBk0uyakxt5d5TAQzgcr6srCGrIrP9H9z4od7e+Pi+Bde0Ps0FjDD/ElGBDmeqLFh0L8
         KR0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=E6BXpk7cNZ+hD+Pwr+PRPQAljH32KZz8KSLiwjLHx9s=;
        b=oiXzIL2v0uKPkwVmqUtQT+PA/bvB91UvVIyxo70jDnGAsUJyzUfvmPRvb3hYLaB1kf
         Om29p+JtuIp3LPHw3Am3UdSDulMvcw57kc3KGnjIZ77Hpex3iWPdkC5Q36/mRsnHewHk
         /MnqRAkJwhSZHZ8+VRPbf/ev0Pp1rRU3Aah8al/FFwGFkzDNiP0boxKeEq+M2yZ2GL25
         Z6rQ3SHZFfudaqomdOZsAHNGd10YzUVRd47rulBpZDbFWTDz5NnKgPsCQ8D8ME2Qu3ED
         0/En3PXL1pabgLtmWjvWK4vARXgt2TYs0c4jHai8uuLoT7ZQPMSStSlWvXVWIAoXfXJl
         ejDw==
X-Gm-Message-State: AFqh2koo5tIRCpVPVKHz5aqysOdOGIvYMf7iONO/IMOu/wfp7PFT25R0
	NCbCes6FzTlNAnii9MdOdpLZi1FhsYrNVtbvLIfx8ZlvRA==
X-Google-Smtp-Source: AMrXdXvI+pw9dREgnyaHRB9U0YHnscdY+E3MKgJTf2+rEkVfElVhTN1ElK5yr9iS0A30Fm2Xt3F6heXqP0DUipuin3Q=
X-Received: by 2002:a17:90b:2548:b0:219:661f:9916 with SMTP id
 nw8-20020a17090b254800b00219661f9916mr2248330pjb.200.1672187683622; Tue, 27
 Dec 2022 16:34:43 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
From: Rick Macklem 
Date: Tue, 27 Dec 2022 16:34:32 -0800
Message-ID: 
Subject: Kerberos doc needs an update
To: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="000000000000e1530f05f0d888d5"
X-Spamd-Result: default: False [-3.98 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.982];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1033:from];
	ARC_NA(0.00)[];
	TAGGED_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	DKIM_TRACE(0.00)[gmail.com:+];
	TO_DN_ALL(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_COUNT_TWO(0.00)[2]
X-Rspamd-Queue-Id: 4NhXbS5HfQz3F6l
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--000000000000e1530f05f0d888d5
Content-Type: text/plain; charset="UTF-8"

Hi,

I just set up a KDC, which is easy once you realize
that Sec. 14.5 of the FreeBSD handbook is out of date.
(I was a dummy and spent several hours installing stuff
 from ports before I realized it was all in the system,
 but the startup file in /etc/rc.d is called "kdc" and
 not "kerberos".)

In 14.5.1, kerberos5_server_enable and kadmind5_server_enable
have been renamed, although these old names still work.

Further down in 14.5.1, it says "service kerberos start",
which doens't work. It is now "service kdc start".
(This was the one that sent me on a wild goose chase.;-)

Maybe someone that can do so could patch the handbook?

Thanks, rick

--000000000000e1530f05f0d888d5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,
I just=
 set up a KDC, which is easy once you realize
that Sec. 14.5 of the FreeBSD handbook=
 is out of date.
(I was a dummy and spent several hours installing stuff
=C2=A0from ports bef=
ore I realized it was all in the system,
=C2=A0but the startup file in /etc/rc.d is =
called "kdc" and
=C2=A0not "kerberos".)

In 14.5.1, kerberos5_server_enable an=
d kadmind5_server_enable
have been renamed, although these old names still work.

Further down in =
14.5.1, it says "service kerberos start",
which doens't work. It is no=
w "service kdc start".
(This was the one that sent me on a wild goose chas=
e.;-)
Maybe s=
omeone that can do so could patch the handbook?

Thanks, rick



--000000000000e1530f05f0d888d5--

From nobody Wed Dec 28 01:18:16 2022
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 4NhYYk6hlWz2cCSK
	for ; Wed, 28 Dec 2022 01:18:18 +0000 (UTC)
	(envelope-from ler@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NhYYk57WQz3Kj0;
	Wed, 28 Dec 2022 01:18:18 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1672190298;
	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=NgF/bJFWAlj4f9G9lO9Vh4Z67O4ThUqyQFBfrefE/5c=;
	b=Mk5aOkTbZzZPu3F170e4Mqa6nClSxLXKyJ2jHhYJnuBpKf9omCRBo79UkhBR4k6g5txu03
	Ie1gP1yH8fksstoXd98qYRqWkDIoM51ICYQq3WgEa5RUtU+b3Nh8izNjvPzbP8G7qOPfA9
	swNBb7LR8ll2t0AG4fxAS8Rz0t8lVJszCfQVCWfImbyYMLjEh0JnUc/3HQZl9h9Ko3UM1k
	+nfyMi2MdXfFlcYQq5q2jgS/Zedwap6y82EPIB8tJR4rvbadchV0/qVip+GFE9PVC/hXtC
	1ChmYv49md97+vwlayGFyCYvycFIS6JR7HJms0rWto5Y6mZ4aVbJaLnHVQkTvA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1672190298;
	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:dkim-signature;
	bh=NgF/bJFWAlj4f9G9lO9Vh4Z67O4ThUqyQFBfrefE/5c=;
	b=wOVPXOL6Dwpgom9w0lLRbxtG72N0SRwFjPwLQZmi67uNt87HUOoHPFpKecZW5yBr67LtZl
	QrBfGrkRT1fNQnEpbPyasnq4d1wfJgCJSJXMF8513arN9GNNWPCKYccS3gmyJSNTT6ZK0F
	JL4WBV18ty+IOswur+4ZVEbVxDfpYomd0pa5+v4pSJvMtrU0LBA8lJVux/nNENibkUOveD
	n7bNWuP3NYjMFc+gYP4EHi92NUScJm67tXCuk7OY2q7x9WK+yR47j6JXa2mR9mVFiwb+Ym
	2h9gwSUNiq/kWrb2YWZPvH5EOzuOkFbUvoMME/MYIY6sj2wGr9qIXiV8jPw8Og==
ARC-Authentication-Results: i=1;
	thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=192.147.25.65;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672190298; a=rsa-sha256; cv=none;
	b=TDlzSTAtyVV0PD/7ohAQAY/Z3jNS4a+mmqyur9NF/v+CleMPV6ZUek7g1B6iFDd/FUoumu
	dcFgfKWy8sWOL/hb2w/+d72FT/YvLmWdShIADpFUkoGQC3RH1Zon/YzxH0xSnMpzYim9W7
	aXpL1cAAbsBWfwCW01ipTOdD//laMNzxlfNUmfPMET7Aoxvjk8LcPpZ3IGrxHajhe1aGuN
	G20sEpIMIAydPJa63iYgF4hsFAwk4xkSOfQJ2ywyWD1793qs4HU3Bs2ijp9vFTpOOHXEhM
	HBwsOTh1r58J+Zr9ecaU0J0ZtWt9a0tC5uh+rHLENhoptLSkppHO1x0IsVhDRQ==
Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65])
	(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 "*.lerctr.org", Issuer "R3" (verified OK))
	(Authenticated sender: ler/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NhYYk3XGXz1RRY;
	Wed, 28 Dec 2022 01:18:18 +0000 (UTC)
	(envelope-from ler@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org;
	s=ler2019; h=Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:
	From:Date:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
	List-Post:List-Owner:List-Archive;
	bh=NgF/bJFWAlj4f9G9lO9Vh4Z67O4ThUqyQFBfrefE/5c=; b=HAAY2c6I/06ytJsDYg9cXo/D9K
	fAzaZtpoZ/WQmtgpGZxkt5o4yp/UQ9IdkWByFZSJ9TFTmlB+SlQJOlyBncsjJ016N+1mGI/+UzoNB
	cTO/uRIKOdaLFeIEaNTyE4RuMbW058AOU12vE67bR8wSzpqxxSqOOHUqyb7dCEZ9g2bnRyuctfliw
	zPLXJmxFrn2kYQAqhx93qSfCbSeR4vZd+t/QOSJP8XboD+HcewOCqMg7mOrRW7Ev32RR0h6gKOpmf
	MeiMUkQbNW/qaO8TFx4azHQP9vk7yhnDWiopPePLUDzyiLMigpc41TF6iltxBsef2q4hgh7yXj8Y5
	JjpLP6uA==;
Authentication-Results: thebighonker.lerctr.org;
	iprev=pass (thebighonker.lerctr.org) smtp.remote-ip=192.147.25.65;
	auth=pass (LOGIN) smtp.auth=ler@lerctr.org;
	spf=softfail smtp.mailfrom=FreeBSD.org;
	dmarc=skipped header.from=FreeBSD.org;
	arc=none
Received-SPF: softfail (thebighonker.lerctr.org: transitioning domain of FreeBSD.org does not designate 192.147.25.65 as permitted sender) client-ip=192.147.25.65; envelope-from=ler@FreeBSD.org; helo=webmail.lerctr.org;
Received: from thebighonker.lerctr.org ([192.147.25.65]:36788 helo=webmail.lerctr.org)
	by thebighonker.lerctr.org with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.95 (FreeBSD))
	(envelope-from )
	id 1pAL5F-0002Mf-8X;
	Tue, 27 Dec 2022 19:18:17 -0600
Received: from 99-190-128-217.lightspeed.austtx.sbcglobal.net
 ([99.190.128.217])
 by webmail.lerctr.org
 with HTTP (HTTP/1.1 POST); Tue, 27 Dec 2022 19:18:16 -0600
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Date: Tue, 27 Dec 2022 19:18:16 -0600
From: Larry Rosenman 
To: Rick Macklem 
Cc: FreeBSD CURRENT 
Subject: Re: Kerberos doc needs an update
In-Reply-To: 
References: 
Message-ID: 
X-Sender: ler@FreeBSD.org
Content-Type: multipart/alternative;
 boundary="=_7fe4d8e4a12b75c3bd1a2dcd50a475d8"
X-ThisMailContainsUnwantedMimeParts: N

--=_7fe4d8e4a12b75c3bd1a2dcd50a475d8
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



Can you gen a PR with a patch?  I'm sure the doc folks would appreciate 
it.

On 12/27/2022 6:34 pm, Rick Macklem wrote:

> Hi,
> 
> I just set up a KDC, which is easy once you realize
> that Sec. 14.5 of the FreeBSD handbook is out of date.
> (I was a dummy and spent several hours installing stuff
> from ports before I realized it was all in the system,
> but the startup file in /etc/rc.d is called "kdc" and
> not "kerberos".)
> 
> In 14.5.1, kerberos5_server_enable and kadmind5_server_enable
> have been renamed, although these old names still work.
> 
> Further down in 14.5.1, it says "service kerberos start",
> which doens't work. It is now "service kdc start".
> (This was the one that sent me on a wild goose chase.;-)
> 
> Maybe someone that can do so could patch the handbook?
> 
> Thanks, rick

-- 
Larry Rosenman                     http://people.freebsd.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--=_7fe4d8e4a12b75c3bd1a2dcd50a475d8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8



Can you gen a PR with a patch?  I'm sure the doc folks would apprec=
iate it.





On 12/27/2022 6:34 pm, Rick Macklem wrote:








Hi,


 

I just set=
 up a KDC, which is easy once you realize


that Sec. =
14.5 of the FreeBSD handbook is out of date.


(I was a d=
ummy and spent several hours installing stuff


 from=
 ports before I realized it was all in the system,


 but =
the startup file in /etc/rc.d is called "kdc" and


 not =
"kerberos".)


 

In 14.5.1,=
 kerberos5_server_enable and kadmind5_server_enable


have been =
renamed, although these old names still work.


 

Further do=
wn in 14.5.1, it says "service kerberos start",


which doen=
s't work. It is now "service kdc start".


(This was =
the one that sent me on a wild goose chase.;-)


 

Maybe some=
one that can do so could patch the handbook?


 

Thanks, ri=
ck


 












=
-- 
Larry Rosenman        =
;             http://people.fre=
ebsd.org/~ler
Phone: +1 214-642-9640         &=
nbsp;       E-Mail: ler@F=
reeBSD.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106





--=_7fe4d8e4a12b75c3bd1a2dcd50a475d8--

From nobody Wed Dec 28 14:21:20 2022
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 4NhtxP46zXz1Lnjj
	for ; Wed, 28 Dec 2022 14:21:29 +0000 (UTC)
	(envelope-from mack@macktronics.com)
Received: from mail.macktronics.com (coco.macktronics.com [209.181.253.65])
	(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 4NhtxN4r7Cz3L71
	for ; Wed, 28 Dec 2022 14:21:28 +0000 (UTC)
	(envelope-from mack@macktronics.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of mack@macktronics.com designates 209.181.253.65 as permitted sender) smtp.mailfrom=mack@macktronics.com;
	dmarc=pass (policy=none) header.from=macktronics.com
Received: from olive.macktronics.com (unknown [209.181.253.67])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.macktronics.com (Postfix) with ESMTPS id 0D225328C
	for ; Wed, 28 Dec 2022 08:21:21 -0600 (CST)
Date: Wed, 28 Dec 2022 08:21:20 -0600 (CST)
From: Dan Mack 
To: freebsd-current@freebsd.org
Subject: native recording of all network connections on freebsd
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; format=flowed; charset=US-ASCII
X-Spamd-Result: default: False [-3.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[macktronics.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:209.181.253.64/29];
	MIME_GOOD(-0.10)[text/plain];
	ASN(0.00)[asn:209, ipnet:209.181.252.0/23, country:US];
	MIME_TRACE(0.00)[0:+];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NhtxN4r7Cz3L71
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N


I'm wondering if anyone can help point me at a good way to continously 
capture every inbound and outbound connection made to a freebsd system. 
I'd prefer a way that is native in base if possible.   I don't really want 
to record all the packets, just the src:dest:rport:dport stats.

Happy to RTFM as well,

Dan

From nobody Wed Dec 28 14:28:47 2022
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 4Nhv655gcpz1LphZ
	for ; Wed, 28 Dec 2022 14:29:01 +0000 (UTC)
	(envelope-from sodynet1@gmail.com)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nhv653jJyz3NHV
	for ; Wed, 28 Dec 2022 14:29:01 +0000 (UTC)
	(envelope-from sodynet1@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-lj1-x22d.google.com with SMTP id f20so16680853lja.4
        for ; Wed, 28 Dec 2022 06:29:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=w/YBMYeTvSDo3Q+bsgPwVXoSnfHF1kWbjHpgavOe1vc=;
        b=A/LhNGHJ41BnWCjLu1T8fMIbqpB5OLC+lx+XPBDSl5D0CEiwbHho++a3UJ5ax3juM7
         yxC16ZS7BfD3bLY8YgYzY9CNTUlCAPfVHeHY68S9s3DOl8oKIXw3xPcRfeSY99WhnMx5
         fI48JqowkdjHwO6XeXJLqB0n+NJatDXQFQVXp9CuUeFGkJ5G2X4eEQu+d4LmgMYfLTsE
         TlUtaKtk2kSirOAP29OlLMxhqNdfuPOeBel+GX8ej2Y3GEUBA4LB21ECkbzxObdssaJB
         s3eCHdU+mGGPYYVHv+qYubiEkYlSrAdATXcC9khJEOKjKId4pM+r/fulKidcpv7S4Ech
         vzyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=w/YBMYeTvSDo3Q+bsgPwVXoSnfHF1kWbjHpgavOe1vc=;
        b=ihD/I45hmj2EiQNrNE9hLbfas7Ztq4FAFHcOCFv8SBS0yoIfB0dOf6XzSzSTesMAIJ
         InGGu1fG5HHsTxVQAFO5M93SzbTGP1Z2O1FBiIXe+ME0jqUjwPQxHpzZ1VdV03qUlpb0
         cqsx0Y/iMI4Fi4tQM9sXYJO3npXhrsBTZpLi75X839JeqtH3NNX+3J+B97KnSsV3kbIh
         Mgr54pxr7NKgYBxHAtwGuuHiuhmx6+Vad9A46R4+PfkxzAehSP+qcr0eSTnB0LFOZUSD
         ix5uqPvOeo2dkoeJ669HdzVLBKhMa6XPgr0R/CgoGs6L2R8ZQTn3pVOKwV030PrSEmcL
         CF5A==
X-Gm-Message-State: AFqh2kpsCy/0wd2cW2Ceh6JBdvbxdyk1E6S+Y113twiVGvYwUlyiKrLS
	MiadLyGiv5pBZZr/B3guRALBgeJp7Wwn+buwQiyhMKVh
X-Google-Smtp-Source: AMrXdXvbbcHk6UDKgOVVBHfXxOD/2xTobyiGwL+zLuB+24i8gPrRFL/oG9Krm8bOB2S9tmp3aHC+z1m/ISy8mhmls4g=
X-Received: by 2002:a2e:9bd4:0:b0:27f:c51a:73de with SMTP id
 w20-20020a2e9bd4000000b0027fc51a73demr337707ljj.332.1672237737711; Wed, 28
 Dec 2022 06:28:57 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Sami Halabi 
Date: Wed, 28 Dec 2022 16:28:47 +0200
Message-ID: 
Subject: Re: native recording of all network connections on freebsd
To: Dan Mack 
Cc: FreeBSD Current 
Content-Type: multipart/alternative; boundary="000000000000561cfa05f0e43070"
X-Rspamd-Queue-Id: 4Nhv653jJyz3NHV
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000561cfa05f0e43070
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

using firewall ike ipfw with rule to log any to any would be a start.. for
advanced use, stateful fw so You can log start of connections

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=93=D7=B3, 28 =
=D7=91=D7=93=D7=A6=D7=9E=D7=B3 2022, 16:21, =D7=9E=D7=90=D7=AA Dan Mack =E2=
=80=8F:

>
> I'm wondering if anyone can help point me at a good way to continously
> capture every inbound and outbound connection made to a freebsd system.
> I'd prefer a way that is native in base if possible.   I don't really wan=
t
> to record all the packets, just the src:dest:rport:dport stats.
>
> Happy to RTFM as well,
>
> Dan
>
>

--000000000000561cfa05f0e43070
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


using firewall ike ipfw with rule to log any to any would=
 be a start.. for advanced use, stateful fw so You can log start of connect=
ions

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=93=D7=B3, 2=
8 =D7=91=D7=93=D7=A6=D7=9E=D7=B3 2022, 16:21, =D7=9E=D7=90=D7=AA Dan Mack =
=E2=80=8F<mack@macktronics.com>:


I'm wondering if anyone can help point me at a good way to continously =


capture every inbound and outbound connection made to a freebsd system. 
I'd prefer a way that is native in base if possible.=C2=A0 =C2=A0I don&=
#39;t really want 

to record all the packets, just the src:dest:rport:dport stats.



Happy to RTFM as well,



Dan






--000000000000561cfa05f0e43070--

From nobody Wed Dec 28 14:39:30 2022
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 4NhvLC6HjXz1LqrS
	for ; Wed, 28 Dec 2022 14:39:31 +0000 (UTC)
	(envelope-from mack@macktronics.com)
Received: from mail.macktronics.com (coco.macktronics.com [209.181.253.65])
	(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 4NhvLC5cZDz3PTh
	for ; Wed, 28 Dec 2022 14:39:31 +0000 (UTC)
	(envelope-from mack@macktronics.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from olive.macktronics.com (unknown [209.181.253.67])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.macktronics.com (Postfix) with ESMTPS id D5B693291;
	Wed, 28 Dec 2022 08:39:30 -0600 (CST)
Date: Wed, 28 Dec 2022 08:39:30 -0600 (CST)
From: Dan Mack 
To: Sami Halabi 
cc: FreeBSD Current 
Subject: Re: native recording of all network connections on freebsd
In-Reply-To: 
Message-ID: <134dcd9-30d-b2d9-2732-992cf2310d8@macktronics.com>
References:  
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Rspamd-Queue-Id: 4NhvLC5cZDz3PTh
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:209, ipnet:209.181.252.0/23, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


Thank you, Oh how dumb I am - I'll just have pf do it using 'log all'.

Dan

On Wed, 28 Dec 2022, Sami Halabi wrote:

> using firewall ike ipfw with rule to log any to any would be a start.. for
> advanced use, stateful fw so You can log start of connections
>
> ?????? ??? ??, 28 ????? 2022, 16:21, ??? Dan Mack ?:
>
>>
>> I'm wondering if anyone can help point me at a good way to continously
>> capture every inbound and outbound connection made to a freebsd system.
>> I'd prefer a way that is native in base if possible.   I don't really want
>> to record all the packets, just the src:dest:rport:dport stats.
>>
>> Happy to RTFM as well,
>>
>> Dan
>>
>>
>

From nobody Wed Dec 28 16:45:28 2022
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 4Nhy7c1P9Hz2kXcK
	for ; Wed, 28 Dec 2022 16:45:32 +0000 (UTC)
	(envelope-from paulf2718@gmail.com)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nhy7b3JZyz3rB4
	for ; Wed, 28 Dec 2022 16:45:31 +0000 (UTC)
	(envelope-from paulf2718@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=HTNOO+gt;
	spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::436 as permitted sender) smtp.mailfrom=paulf2718@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-wr1-x436.google.com with SMTP id bs20so13287455wrb.3
        for ; Wed, 28 Dec 2022 08:45:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:subject:from:content-language:to
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=b8pWiCtcrYN3+rNcv61QI1CAUqiYKxSL98GR7jUXf6s=;
        b=HTNOO+gt5svJoiFFZ9W1zjYaB5sxlhyv2+XQ0Eyy6MVSRGOJIjc1lq2O6jhvaATk2K
         cdcu5MtMq6B7JyDkz8GEiZkIgb20DnSDG1HfnaxqIbl6l/Z+r28wlL2mEQD/vnKgVsSp
         1kIA7E3zl6Y9PktRyICJLuj8wtqZiwPyw6Bk1d0cwq2Ob51W0e6epvTxcha3/6yNDhAQ
         znvZswJ0wPqrlTsEDOdVjVKxDi3VBw5ieQWGnI/P6CmomYdP3NgXqXLotkv/KcbvehsX
         jQpMhsT5DFOTJ93IcBlo6c/aDjnGa29g2vajrOLQg33oJ5v3iVw9ogYqddZCDUqCUB7a
         th2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:subject:from:content-language:to
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=b8pWiCtcrYN3+rNcv61QI1CAUqiYKxSL98GR7jUXf6s=;
        b=4DmgxoNWu0wLVLIL+8nWz0baF68ZoHgr4mbotaptDJO98hJmR0O3umZxsWUG7VbkNV
         26UeL6lKZreKaZaM2F7Wjco+h0qhhn4CwW7B/87nth6lp9b0g/K/pXHlEqTLEfRQez9q
         WFN8mtcjeauHobhcj3CO6LhTNOjbg1KDrjTWJYR+MyWExY4Pi9dMquVgfmiSmEYgYCZo
         7NWeMjLVoW9RnGjRueUpus1xA2QDKTchuq8Q0l7tk/dhafvdzJn6niEv5hec823OmEgu
         QeSCVzsaouT2FOwNfvvSEnls+Kc6pzUgZ+6wblf3SWlBj1FIA3mYF1T9IAObIFfNQGMV
         oQmQ==
X-Gm-Message-State: AFqh2koiRb+sGi5Gs6mjDFlhHCayG7vq/qovKd+G9rWmXHQwGjiuE9Yo
	9dYWL7QIXoghZmKbh+0WikbEO0Ma2RxyXA==
X-Google-Smtp-Source: AMrXdXvZMzALRq3HlGYi4bvwcu6251XV4PB01PwiAg4pdh/qimg0EuIHW2jngr/ZLSBv8YGs0GFfEg==
X-Received: by 2002:adf:eb01:0:b0:242:4c00:f544 with SMTP id s1-20020adfeb01000000b002424c00f544mr15034441wrn.45.1672245930080;
        Wed, 28 Dec 2022 08:45:30 -0800 (PST)
Received: from [192.168.1.28] (lfbn-gre-1-309-115.w90-112.abo.wanadoo.fr. [90.112.30.115])
        by smtp.gmail.com with ESMTPSA id k4-20020adff284000000b00289bdda07b7sm805511wro.92.2022.12.28.08.45.29
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 28 Dec 2022 08:45:29 -0800 (PST)
Message-ID: 
Date: Wed, 28 Dec 2022 17:45:28 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
To: freebsd-current@FreeBSD.org
Content-Language: en-US
From: Paul Floyd 
Subject: 14.0-CURRENT panic on boot, i386 VirtualBox client
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-2.92 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	NEURAL_SPAM_SHORT(0.08)[0.084];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::436:from];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4Nhy7b3JZyz3rB4
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

Hi

For quite a few weeks I've been unable to boot 14.0-CURRENT i386 in a 
VirtualBox VM. I've tried both booting from iso image and the vmdk 
image. I get a kernel panic

The host is running 13.1-RELEASE-p3 amd64

No problems with 14.0-CURRENT amd64 guests.

I haven't been able to see the last message before the panic as it 
scrolls past too quickly.

Any suggestions for a working either how to get more info or what vbox 
settings to use?

A+
Paul

From nobody Wed Dec 28 17:05:46 2022
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 4Nhyb02NBlz2kb6q
	for ; Wed, 28 Dec 2022 17:05:48 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nhyb01sRNz3sqF
	for ; Wed, 28 Dec 2022 17:05:48 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1672247148;
	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=1ZZI62SJIx2mAF1bAkPvE4GPa5S3vNjzq10yW9JtKEY=;
	b=RDHTVrTQwXOoi4aF5GJgtUuYGmM0g43D/3ELc6o+4KtWAc0pBmoYt3rRBP05FtcTnKYF3r
	4X9V30rZml1hrmj9GZt7fas9DyP1nTBK7Xzti6kjMf7u6ne/P/D5h8hAOdxj3vcSnQQqFR
	6yw8I5pj2TzMixGB2C2CrUskP1YcBFjwQ/wowNsyvwFWtThCNrHX20bhGyv+eSiPnQ6NJ8
	XnG1nxxbrVTKzrHUuibfMLNsfP6Ai8eAYlOiiJVNojnqoeqpyaPmD1aouYZvbV+nNFR6we
	CaajokEYI/IM3rthFz7ehJ+Si2RpI+srlYDicSkPThiDWTm9G0Nv2cf/LbbuWw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1672247148;
	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=1ZZI62SJIx2mAF1bAkPvE4GPa5S3vNjzq10yW9JtKEY=;
	b=plPoTg5bH5zWk8okNIsOUjgvLN7TqbA+/1k40fuD1RVW6HmfZeK8qfbEwFdBgLi5O49GPj
	/GO1Vod2KVPAGuG5zSgw90YWqGfEG8nnon/9iwSjkvGojF1cluwYRjJ4eSYBfjX/5C2aOO
	fNZ4G3WxTZC2lfRbuVV7mXO5IZ2b3xMIBrTJWDcvhtGkPTnI2JSCp2VTTkQGnt7ebYz1e7
	Y8B08QwJybhtVm32oJofb6W6vqRNSj5jBjjGdGWnd0so+qH1wjif7Q7CKfTmWn6tctJk7l
	MTHPQPOCkWSk6z6NMsH8WVxh9H7fD2O1f58sgidmJgQyKLNylLgSeGja0ltAog==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672247148; a=rsa-sha256; cv=none;
	b=yhpPoBc9DShhs5G9Y5vQVjreZ/+xP82ZbZLFwj9mfBduKrZqL+6kGikDDDoWOE+DByxRjK
	8Z6y3EVBfYEesYGxRMw36o9+yy1BF63ASgTWs07zxfSrTGTvUb89SLY5fgxzwNW1gi82B0
	rjtbH8s9jSD5T7uBhKieBwC4tGelOewCZXhBi9t9YPpH4XqnW50a7DM/kXGFZ0W1CMq5Pd
	A465PJXvMYLZ3O09z7H0GRkaxj01gAvUZR7w5/40YlvTf9kObpshqCaHPKy/QF5qCbYOUP
	BvJOh3T20KirEnxj3ckZA0wQDxuthuFMDIIkNHf5nVsRHrfxrvmAIaSRiqRNqA==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NhyZz6lMCzV9P
	for ; Wed, 28 Dec 2022 17:05:47 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: 
Date: Wed, 28 Dec 2022 17:05:46 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
Content-Language: en-GB
To: FreeBSD CURRENT 
References: 
From: Graham Perrin 
Organization: FreeBSD
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------jhIPuOxNLWIE2PxLCI3DEpzm"
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------jhIPuOxNLWIE2PxLCI3DEpzm
Content-Type: multipart/mixed; boundary="------------wj9JQl8Z3o1BagdbnQD9DO0N";
 protected-headers="v1"
From: Graham Perrin 
To: FreeBSD CURRENT 
Message-ID: 
Subject: Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
References: 
In-Reply-To: 

--------------wj9JQl8Z3o1BagdbnQD9DO0N
Content-Type: multipart/alternative;
 boundary="------------pZNL70W0GzdySWwhQRikb1Zo"

--------------pZNL70W0GzdySWwhQRikb1Zo
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMjgvMTIvMjAyMiAxNjo0NSwgUGF1bCBGbG95ZCB3cm90ZToNCg0KPiDigKYgSSBoYXZl
bid0IGJlZW4gYWJsZSB0byBzZWUgdGhlIGxhc3QgbWVzc2FnZSBiZWZvcmUgdGhlIHBhbmlj
IGFzIGl0IA0KPiBzY3JvbGxzIHBhc3QgdG9vIHF1aWNrbHkuDQo+DQo+IEFueSBzdWdnZXN0
aW9ucyBmb3IgYSB3b3JraW5nIGVpdGhlciBob3cgdG8gZ2V0IG1vcmUgaW5mbyBvciB3aGF0
IHZib3ggDQo+IHNldHRpbmdzIHRvIHVzZT8NCg0KDQpJZiB0aGUgZ3Vlc3QgaGFzIG1vcmUg
dGhhbiBDUFUsIHRyeSByZWR1Y2luZyB0byBvbmUuDQoNCkEgc3RlcCBmdXJ0aGVyOiB0cnkg
Ym9vdGluZyB0aGUgZ3Vlc3QgaW4gc2FmZSBtb2RlLg0KDQo=
--------------pZNL70W0GzdySWwhQRikb1Zo
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 28/12/2022 16:45, Paul Floyd wrote:

    

    
=E2=80=A6=
 I
      haven't been able to see the last message before the panic as it
      scrolls past too quickly.
      

      

      Any suggestions for a working either how to get more info or what
      vbox settings to use?
      

    

    


    

    
If the guest has more than CPU, try reducing to one. 

    

    
A step further: try booting the guest in safe mode. 

    

  
  


--------------pZNL70W0GzdySWwhQRikb1Zo--

--------------wj9JQl8Z3o1BagdbnQD9DO0N--

--------------jhIPuOxNLWIE2PxLCI3DEpzm
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmOsd2oFAwAAAAAACgkQt2dIb0oY1Ask
IRAAgbKl+TvvvDDzPTshD3KIeOekLmvMRQmcb6ZqOSMCjxP+C4iEq0KRHhD0+Cv6T6wj863tpcHk
bnjkz/QlTMsPislSYpv18pJHZngrEIq1Qv2hWaj+/5Hv23BRZ7VvI8yQxAiC6MQMhfkH7iWSsE4J
SWwitrpzKmsdBDPOLzSsvLYEsjEj90BSPbwppMBIFkvo4hpv0Uz3DFoqczmD2SU6QuiO8MjLWf7R
0V8DEk8mW+7t6AyulClTd4jGNGyC9hzhRPmmYWdXnne+B0xF82rwg5PuLh5WbiIgIEw2+L58KVbA
wwrxkX2IcLHxyMgRQSKxmjw95Hbs6Dh3thqqMMe9Qrn1V5wIEofJFtfD/0BE11gavcQ26GlBXwYY
xcoRzHeaNzaQ1dDv8UlMSwc5DsQGGd+M9ACWpztlc/7fCfXBGhze4xhi+VOq+bNWB51nD6y2zEle
GbqkegbSKjJJsb5Q11h4TwEvzo8QIoKvIFBDktFXFxJfiOG5PZtIv/X+q12A6PjDUxLRXVKtgJhx
O1eXLB7q31qUtgsY312W0yHo2xHXVrMKhhBHRGS6VX0eNhp+giHdfElR1W2eao9T3d/TPoNwMKtj
EmwOajZ5oxC0bi1Ub60PaQ35gpr12STljuhS3wX182buhaCjlGVDwDSrAYT/osJZKUJwwGMGF+II
38Y=
=z5ox
-----END PGP SIGNATURE-----

--------------jhIPuOxNLWIE2PxLCI3DEpzm--

From nobody Wed Dec 28 17:11:48 2022
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 4Nhyjz4h0jz2kbvv
	for ; Wed, 28 Dec 2022 17:11:51 +0000 (UTC)
	(envelope-from paulf2718@gmail.com)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nhyjy5r1Vz3vSx
	for ; Wed, 28 Dec 2022 17:11:50 +0000 (UTC)
	(envelope-from paulf2718@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=gZ1jFg7T;
	spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=paulf2718@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-wr1-x432.google.com with SMTP id z10so15422465wrh.10
        for ; Wed, 28 Dec 2022 09:11:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date:message-id:reply-to;
        bh=DmKHzS1NtfxgT9hecS5/X7cWmJ9XYHdvXBh0sx7pqBc=;
        b=gZ1jFg7TMjnJoXVB3guUY8pPBYUrDgdS4ve9OJaCVBnZmKz95mtCNInZ/jhh8HNcmJ
         Fze9bVu75uubeMb+GSXy7L2ieB6eDyobzFKcM2kJ2Px21aj3hMfaXTkXLxk/jE7gR0nx
         zXfCuWE7FHAHRGzwF0D9IIk1+QF1b7xvzV5NAJWKG4eyuRph8OQjEE2sLNMGaL4/wCob
         op09eJngeaxZXOHkCa8rQJ8B7Wj7tQEZP79Be7WnSebEj0gIIrB+qQvxbHHC8ywgdeZn
         Oa4xH71OLOqnSCMajbe1I+UcE7Agbf5Q8++tbMurJAH57/KmykIS1sLg/3kRV56nbHNs
         LA9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=DmKHzS1NtfxgT9hecS5/X7cWmJ9XYHdvXBh0sx7pqBc=;
        b=wyLnjDl0ZjKavQzFqZ/7uJQQEd7MybmVpHEdhd0JEUJsuCtJHAIFJ2tkuP3MduiBcp
         U3Muof0diGk4jNQr6eulzRA/MFARjMr+nlvB+uI4BszHdpA3yxh4lto6ZF+wU6HQ371E
         tryPI28dA8yf5YgKNx8uxzMyWY9E9I8G3SU/eokbh3j36dmDAcwv9XrYMUpZoTXT50rt
         d2/0eo6gph13TIky/iC1oU3kP1g78gabEvOQqb2IICdXCKyrZPyOYTB7UULnhHXDUaLF
         Qav83GyzmDK0TcjeAOF8uvcpFHRrh8MxGxn7pLq3hhiMuqTrbcgvovSh158VVBX8oHYP
         4w4A==
X-Gm-Message-State: AFqh2koBDDzZJ40wRRGmIWIWRgSJjBiBLpwpwXofWEmdBO4GGivITU5/
	GOos5HNujahj9howIdDWelWk1fcccUgVDw==
X-Google-Smtp-Source: AMrXdXsAoHNoQk7zdpLeZB9wVb1dFEXoqMhO+bQ8ep1VUk0kqSEcOCmr9gdZv0+BK1B3Uh4AXyQe1g==
X-Received: by 2002:a5d:6b8c:0:b0:242:7084:b1b1 with SMTP id n12-20020a5d6b8c000000b002427084b1b1mr17001442wrx.23.1672247509396;
        Wed, 28 Dec 2022 09:11:49 -0800 (PST)
Received: from [192.168.1.28] (lfbn-gre-1-309-115.w90-112.abo.wanadoo.fr. [90.112.30.115])
        by smtp.gmail.com with ESMTPSA id f8-20020adff8c8000000b00282194eaf7bsm5797575wrq.71.2022.12.28.09.11.48
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 28 Dec 2022 09:11:48 -0800 (PST)
Message-ID: <663b32be-e8a1-dab0-baa7-3b863aa58930@gmail.com>
Date: Wed, 28 Dec 2022 18:11:48 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
Content-Language: en-US
To: freebsd-current@freebsd.org
References: 
 
From: Paul Floyd 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-3.64 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.64)[-0.641];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::432:from];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4Nhyjy5r1Vz3vSx
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N



On 28-12-22 18:05, Graham Perrin wrote:

> 
> If the guest has more than CPU, try reducing to one.
> 
> A step further: try booting the guest in safe mode.
> 

Neither of those changed anything (I was using 2 CPUs)

A+
Paul

From nobody Wed Dec 28 17:12:14 2022
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 4Nhylw0G8Kz2kcMs
	for ; Wed, 28 Dec 2022 17:13:32 +0000 (UTC)
	(envelope-from ronald@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nhylv6rhRz3wJ1
	for ; Wed, 28 Dec 2022 17:13:31 +0000 (UTC)
	(envelope-from ronald@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1672247612;
	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=YTVY+hTNW+tNNrf5gZSF+cMoEhurwfCS6zz54pOcKQw=;
	b=qs74jhD0H+4HQzLy8vFrCfA5OOsX5e5W0LTdEONvQCR6ZrnOOeTqXMtPwmDx993ZjLKna6
	l5cWrrUT0GQsQH9fXuMziFGyYJSag/ABKzl4eESTdCHgoVpeoVhCfLyLfLJITqqOMzEayk
	HinpyNPPuFOXu6nYL/eQBem+TSbvPm1JoRqZYpsBwpuXO/XdX9GsDFpGiLdc6VGgP8GSM5
	2Fj/Ln9qIKFkCQEm5pKs/DYOaTvgzgBy7ess0SLNPj8e1oRrd1OOcLQQrIHz/ErZs37yaq
	GBdtgr5oPZaoq6dw/7oZPH3t43xGjTJjs9utHM8uDp2g7Ao6+almrUxdd6MXAA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1672247612;
	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=YTVY+hTNW+tNNrf5gZSF+cMoEhurwfCS6zz54pOcKQw=;
	b=IxkW4Gi16TP0WxPJZvDBBmXircg7zxu9+DR//TN+Q0MJfMkTWxwZWd5Ft/M4VRAlI0glyi
	9eYqwbzDZT1seZgH2ckl3SVv+aquU2FvwnZs6iP3rMzj0DJb2xjEoI7OMTI9r5cA/OgGtg
	PLTYIgy1nvObZP2doXDuL5xQmt6HKrqGzh4tVmt/bCaNHZotXmWSut4YokoPGs3UW7r1AE
	PXBgw23auwEpjYHtctZIyXLwwRAW2VE6n/E94yOsM/P3agpIOjycH/HsSN/1ZxvQpGysf9
	A7lV645lgi/3SmNL2Bvr0iV7DftgRiDXngExJzJ74ImPQOjU3rmKj1IHILlHhw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672247612; a=rsa-sha256; cv=none;
	b=DHxqVRphdnAqtPJohS7Umk5mSfE/FfvxJXI6lcyUBeLse+lTFi/Sw9sRSI/AbtcHbj94n2
	yT4g0haMDY8T2uERdaibcAzleBDQJE9B5rX2W5TxsqCgrrIQ7Qa7Qkeg0ZSj3TqtebkblY
	0WkTmZBEaDioQfZWKS27R+SSIUxQiTrOTkzV6sIdo5fwWwefxrDsOjq3JLONHmEK+n0kPu
	T883V/x3MkSa7PmKeDLVT/h6p5ToPSlm0ULtxFGxM96wyAzBiJqRvZyJp+bLD0D8LMCEJu
	WRPp9/4znd03312Q1H9/iURdxiTuNyQMMCLG6Vz9MHOPI0Snl2vk2Hgl+4BH/Q==
Received: from [192.168.1.109] (85-147-65-221.cable.dynamic.v4.ziggo.nl [85.147.65.221])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	(Authenticated sender: ronald/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4Nhylv49L1zTym
	for ; Wed, 28 Dec 2022 17:13:31 +0000 (UTC)
	(envelope-from ronald@FreeBSD.org)
Message-ID: 
Date: Wed, 28 Dec 2022 18:12:14 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
Content-Language: en-US
To: freebsd-current@freebsd.org
References: 
From: Ronald Klop 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ThisMailContainsUnwantedMimeParts: N

On 12/28/22 17:45, Paul Floyd wrote:
> Hi
> 
> For quite a few weeks I've been unable to boot 14.0-CURRENT i386 in a VirtualBox VM. I've tried both booting from iso image and the vmdk image. I get a kernel panic
> 
> The host is running 13.1-RELEASE-p3 amd64
> 
> No problems with 14.0-CURRENT amd64 guests.
> 
> I haven't been able to see the last message before the panic as it scrolls past too quickly.
> 
> Any suggestions for a working either how to get more info or what vbox settings to use?
> 
> A+
> Paul
> 


I've had success to capture errors by recording the screen with my phone and playing back on slow speed.
Another option might be to enable serial port for the console of the guest and capture the output. But I don't know if the default ISO uses that and how hard it is to configure VirtualBox to do that properly.

Regards,
Ronald.


From nobody Wed Dec 28 23:13:21 2022
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 4Nj6lL52GTz2cJHY
	for ; Wed, 28 Dec 2022 23:13:34 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nj6lL38n5z3PL5;
	Wed, 28 Dec 2022 23:13:34 +0000 (UTC)
	(envelope-from rick.macklem@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pl1-x630.google.com with SMTP id m4so17357475pls.4;
        Wed, 28 Dec 2022 15:13:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Ghm+u4DBnlkfxY8fXqX5L2nJRi2gakKEfHEf6OCwaLg=;
        b=DnR1WzQWpPXUi3EiO0hL3RVtDjxcX+3Ehs2WlC35tzCFeMOx35xV0woiyYZh5/xsVL
         5fL28yJb0lWF/RYCzCb2Wer2FXPoA4ML+NMbcW+CzWeTGKL6OyIoFcgD/rSbRtBXUEGs
         aQZJnX5fbCRIcJrzWcT1XUWZu+SiaPHgLSLA3hZznxNMGQw5qMnOz85SI41NU56glo5w
         KE4zrmFQRby4AJ0Lg+L232jl88lu80cQn9veI6iRNyYfl+WAK36rtCo2NdR/dksp4Kt1
         tIFl8CSuc2bGnRKtrfvCl2Zc8BfbVyzpjFbLEIYNvvzSQtexkxdbue9rwTbbHiHxBCDl
         okRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Ghm+u4DBnlkfxY8fXqX5L2nJRi2gakKEfHEf6OCwaLg=;
        b=IiWjiasnAjIlUmaS79H1kjqLG06gJjXLEjXd3KBJrSCsH1SQEPcDZA4g4b3+ZFPi3U
         TPIYj1yxpUq8wzjL/b2XE743S6i8oPvupXovHEfBeTaxi9sCMY8CVBPz3kAooxOwUshW
         ob1Z+BaJYMAZMvsylI9R4YLBOV07QEjyo+HZV0AQXFg5pqn30NNYw/JyUukM3hoPeEoV
         ts5hxcHPuFAZzW6SCW0s817k30K05IrplwCrqiDlvYLm1xx7ON7ougE3dKZiH7bBx3Iw
         t4PBRN/pLLcb4dZSNZecPUWiIEASEZT856ohCsux6Das/AVVDEMA0RgGjm1o+Hm5c27V
         TZCA==
X-Gm-Message-State: AFqh2kqyK6xjOvZoJy8vAtuICtML6GFmrhZ2HGmldZQle8pDZkVHi22X
	oF9d3299VYAqMO6Ja8FAHCvFd53U6HLmifXqNjMc/2PKqg==
X-Google-Smtp-Source: AMrXdXuMtSg6bIZIufNfEmX/s0hcyF0tH4LlGB7f0TGgem9l2omrMgnOl8/BUe5/xxxfy7cC1XRysJU9PNT8jP67Iro=
X-Received: by 2002:a17:902:70cb:b0:189:da70:9723 with SMTP id
 l11-20020a17090270cb00b00189da709723mr1552411plt.103.1672269211502; Wed, 28
 Dec 2022 15:13:31 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
 
In-Reply-To: 
From: Rick Macklem 
Date: Wed, 28 Dec 2022 15:13:21 -0800
Message-ID: 
Subject: Re: Kerberos doc needs an update
To: Larry Rosenman 
Cc: FreeBSD CURRENT 
Content-Type: multipart/alternative; boundary="00000000000052112305f0eb847e"
X-Rspamd-Queue-Id: 4Nj6lL38n5z3PL5
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--00000000000052112305f0eb847e
Content-Type: text/plain; charset="UTF-8"

Nope, I don't have the time/resources to do doc stuff.
(My development laptop doesn't have the space for a
 doc repo. I know nothing about the doc tools, etc...)
I currently have the following raw text files that
would be nice to have in the handbook, but I won't
be doing it:
https://people.freebsd.org/~rmacklem/nfs-krb5-setup.txt
https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt
https://people.freebsd.org/~rmacklem/pnfs-planb-setup.txt
https://people.freebsd.org/~rmacklem/nfsd-vnet-prison-setup.txt

If it is not obvious what needs to be changed in Section 14.5,
the doc person can email me and I will clarify, although I
think it is obvious from the original email, when you pull
Section 14.5 up on the screen.
Btw, the change to kdc was r270782 was done on Aug. 29, 2014.

rick


On Tue, Dec 27, 2022 at 5:18 PM Larry Rosenman  wrote:

> Can you gen a PR with a patch?  I'm sure the doc folks would appreciate it.
>
>
> On 12/27/2022 6:34 pm, Rick Macklem wrote:
>
> Hi,
>
> I just set up a KDC, which is easy once you realize
> that Sec. 14.5 of the FreeBSD handbook is out of date.
> (I was a dummy and spent several hours installing stuff
>  from ports before I realized it was all in the system,
>  but the startup file in /etc/rc.d is called "kdc" and
>  not "kerberos".)
>
> In 14.5.1, kerberos5_server_enable and kadmind5_server_enable
> have been renamed, although these old names still work.
>
> Further down in 14.5.1, it says "service kerberos start",
> which doens't work. It is now "service kdc start".
> (This was the one that sent me on a wild goose chase.;-)
>
> Maybe someone that can do so could patch the handbook?
>
> Thanks, rick
>
>
>
> --
> Larry Rosenman                     http://people.freebsd.org/~ler
> Phone: +1 214-642-9640                 E-Mail: ler@FreeBSD.org
> US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
>

--00000000000052112305f0eb847e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Nope, I don't have the time/resources to do doc stuff.
(My development laptop=
 doesn't have the space for a
=C2=A0doc repo. I know nothing about the doc too=
ls, etc...)
I currently have the following raw text files that
would be nice to have in the h=
andbook, but I won't
be doing it:
https://people.freebsd.org/~rmacklem/nfs-krb5-setup.txt
https://people=
.freebsd.org/~rmacklem/nfs-over-tls-setup.txt
https://people.freebsd.org/~rmacklem/pn=
fs-planb-setup.txt
https://people.freebsd.org/~rmacklem/nfsd-vnet-prison-setup.=
txt
<=
br>
If it=
 is not obvious what needs to be changed in Section 14.5,
the doc person can email=
 me and I will clarify, although I
think it is obvious from the original email, whe=
n you pull
Section 14.5 up on the screen.
Btw, the change to kdc was r270782 was done on Aug.=
 29, 2014.

ri=
ck


On Tue, Dec 27, 2022 at 5:18 PM Larry Rosenman <ler@freebsd.org> wrote:


Can you gen a PR with a patch?=C2=A0 I'm sure the doc folks would ap=
preciate it.





On 12/27/2022 6:34 pm, Rick Mac=
klem wrote:








Hi,


=C2=A0


I just set up a KDC, which is easy onc=
e you realize


that Sec. 14.5 of the FreeBSD handbook=
 is out of date.


(I was a dummy and spent several hours=
 installing stuff


=C2=A0from ports before I realized it =
was all in the system,


=C2=A0but the startup file in /etc/rc.=
d is called "kdc" and


=C2=A0not "kerberos".)


=C2=A0


In 14.5.1, kerberos5_server_enable and=
 kadmind5_server_enable


have been renamed, although these old =
names still work.


=C2=A0


Further down in 14.5.1, it says "=
service kerberos start",


which doens't work. It is now &quo=
t;service kdc start".


(This was the one that sent me on a wi=
ld goose chase.;-)


=C2=A0


Maybe someone that can do so could pat=
ch the handbook?


=C2=A0


Thanks, rick


=C2=A0













--=C2=A0<=
br>Larry Rosenman =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 http://people.freebsd.org/~ler
Phone: +1=
 214-642-9640 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 E-Mai=
l: ler@FreeBSD.org=

US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106








--00000000000052112305f0eb847e--

From nobody Thu Dec 29 01:22:05 2022
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 4Nj9bp1GrKz2knDV
	for ; Thu, 29 Dec 2022 01:22:14 +0000 (UTC)
	(envelope-from lyndon@orthanc.ca)
Received: from orthanc.ca (orthanc.ca [208.79.93.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 SHA512)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nj9bn5KzZz3sNp
	for ; Thu, 29 Dec 2022 01:22:13 +0000 (UTC)
	(envelope-from lyndon@orthanc.ca)
Authentication-Results: mx1.freebsd.org;
	none
Received: from orthanc.ca (localhost [127.0.0.1])
	by orthanc.ca (OpenSMTPD) with ESMTP id 2ae62d16;
	Wed, 28 Dec 2022 17:22:05 -0800 (PST)
From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" 
To: Dan Mack 
cc: freebsd-current@freebsd.org
Subject: Re: native recording of all network connections on freebsd
In-reply-to: 
References: 
Comments: In-reply-to Dan Mack 
   message dated "Wed, 28 Dec 2022 08:21:20 -0600."
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <49916.1672276925.1@orthanc.ca>
Date: Wed, 28 Dec 2022 17:22:05 -0800
Message-ID: <1a196a2a8d9034d8@orthanc.ca>
X-Rspamd-Queue-Id: 4Nj9bn5KzZz3sNp
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:25795, ipnet:208.79.88.0/21, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

Dan Mack writes:

> I'm wondering if anyone can help point me at a good way to continously 
> capture every inbound and outbound connection made to a freebsd system. 

Assuming "connection" means "log every TCP connection setup" probably
the quickest way is to tcpdump every TCP packet with both SYN and
ACK set.  That will log one packet for every TCP connection that
is established with the system. It won't capture anything for
connection attempts that fail. If you want that as well, just log
everything with SYN set.

If you do the latter you will also collect the background noise
from people port scanning you and attempting other nefarious deeds.

--lyndon

From nobody Thu Dec 29 01:58:02 2022
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 4NjBPM6Wl8z2ksFF
	for ; Thu, 29 Dec 2022 01:58:15 +0000 (UTC)
	(envelope-from damjan.jov@gmail.com)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NjBPM2sxyz40bv
	for ; Thu, 29 Dec 2022 01:58:15 +0000 (UTC)
	(envelope-from damjan.jov@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ua1-x92c.google.com with SMTP id e24so3906423uam.10
        for ; Wed, 28 Dec 2022 17:58:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Qx3qvOVDfR6e1ojg4gVat4DvLiMmUzJEoi+YTGJuZbc=;
        b=PoBoYHjnQ35KdzYxvcCf6/rx9kW6y7ouVRQpIfu89sloRKONLMKmTiOradlCnye15d
         yH9ix+KsLH47vRiewe3pB+VNWqBtOLksiRn1UX8M+iyU+0Aig+nA6qY2RpY774ObHxHz
         k2DXrX+8CyKf1HiOdGXdDkgoRgYq+Hbh0M0oqVIQ0q6orY4zQUnpIJ94wxQQKlEKjxdz
         ymw878pj1NXoMF6MmeEkLVIs8FrnastPGxTCE9aZuqPXmmy6fOFIGT4HW2gcERArfUkG
         +M516RSN5mryhXwrZECpn7+rM44JMA7rzwgdtgn5RWXjpoo4t+1E4q4ZArOCeFTxbPqx
         fCmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Qx3qvOVDfR6e1ojg4gVat4DvLiMmUzJEoi+YTGJuZbc=;
        b=4nPUFfKr3MS6l2P22PAj6SxiUJBQX3iFfqbCK7MpqlX+Gp9titL6wuIfjkds4vfbTI
         1O/N/9QLdI5rqpp13BYJRIk4J8pui9qInvjDAokG0OtVhmCV8/89ubF0vNt7HtqouZZg
         dI+pojp7pJzyJDI4hoD8mY15mnmFaR3pJbkPD3ieaAd2OkEG4ATU3iIF19MS/yFYWEDb
         VkYNr58PDS7yGAy9yBQnJ5CakjmPn/GyQHzdV52Rb/47lLytgncY5jZCkk+u+dBOEqdS
         UcwftWVNpwSuSqmoNJLQ5LKqYN3rQCfx7WxTfgl7o1ZTGZ6yWbi9mz9BaSVcjtsYWz2o
         ErRw==
X-Gm-Message-State: AFqh2kq7fT9cbRZVK/jA9Byh0AL/h90JOQDBZoxSG/9N+/Twpy7AKky8
	UZGAZrb6y3tXN8goRXC7vMlSM6zo5caAzKi/wURqg4BWxQrP8/HzFxU=
X-Google-Smtp-Source: AMrXdXtXuT6rN5jIDwA6WZReBO1IjNkA4tAXZhM0xQnScso47sgiZKCnJDsJ6QEVF1HZRTUFyjdbXOIC7J6z/44CWjU=
X-Received: by 2002:a9f:2f12:0:b0:419:d688:24b2 with SMTP id
 x18-20020a9f2f12000000b00419d68824b2mr2544861uaj.79.1672279094412; Wed, 28
 Dec 2022 17:58:14 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Damjan Jovanovic 
Date: Thu, 29 Dec 2022 03:58:02 +0200
Message-ID: 
Subject: Re: native recording of all network connections on freebsd
To: Dan Mack 
Cc: freebsd-current@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000006349e305f0edd1e0"
X-Rspamd-Queue-Id: 4NjBPM2sxyz40bv
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	TAGGED_FROM(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--0000000000006349e305f0edd1e0
Content-Type: text/plain; charset="UTF-8"

On Wed, Dec 28, 2022 at 4:21 PM Dan Mack  wrote:

>
> I'm wondering if anyone can help point me at a good way to continously
> capture every inbound and outbound connection made to a freebsd system.
> I'd prefer a way that is native in base if possible.   I don't really want
> to record all the packets, just the src:dest:rport:dport stats.
>
> Happy to RTFM as well,
>
> Dan
>
>
Another possibility is to enable Netflow in ipfw (there is an ipfw_netflow
service), which submits periodic reports of all connections made and their
data usage, and then collect and process the Netflow data using a Netflow
server.

Or develop a custom Netgraph service that examines packets and logs
connections. This would even work in the absence of any firewall.

Damjan

--0000000000006349e305f0edd1e0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Dec 28, 2022 at 4:21 PM Dan M=
ack <mack@macktronics.com>=
; wrote:


I'm wondering if anyone can help point me at a good way to continously =


capture every inbound and outbound connection made to a freebsd system. 
I'd prefer a way that is native in base if possible.=C2=A0 =C2=A0I don&=
#39;t really want 

to record all the packets, just the src:dest:rport:dport stats.



Happy to RTFM as well,



Dan



Another possibility is to enable Netfl=
ow in ipfw (there is an ipfw_netflow service), which submits periodic repor=
ts of all connections made and their data usage, and then collect and proce=
ss the Netflow data using a Netflow server.

Or dev=
elop a custom Netgraph service that examines packets and logs connections. =
This would even work in the absence of any firewall.

Damjan



--0000000000006349e305f0edd1e0--

From nobody Thu Dec 29 02:31:01 2022
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 4NjC7R4nTNz2kxxg
	for ; Thu, 29 Dec 2022 02:31:15 +0000 (UTC)
	(envelope-from bakul@iitbombay.org)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NjC7R2ycWz43rf
	for ; Thu, 29 Dec 2022 02:31:15 +0000 (UTC)
	(envelope-from bakul@iitbombay.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-pl1-x629.google.com with SMTP id b2so17676374pld.7
        for ; Wed, 28 Dec 2022 18:31:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=iitbombay-org.20210112.gappssmtp.com; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=ixYP9LwA5czUikEeatOgu0kf103Ka1Ni1XWLkQpGlco=;
        b=KI3YHoT4NLj2Hw7Z3vtXwLauNaxTPzlsl050EX6tVt5lfhxMExWoCzA9hiWsH+AKKa
         UivGYKTr2TIv/nsF5MADQ4wNChLaPQpkgGlq/FsBxUjY0k5hXPpvpzGzLBeDMbiY43ma
         qMuzXjGligl180ZK6X8zWHzFgjhunCAHIlCv99kQhtKawskUvEk4bf5f0h5pPGq5Jaik
         0x92htw/y5u77LpyenWv5DE98ExZ110IXheTqCwvIMnCBqeMKB5tn29XUAb3ZHGnRqh2
         rWBeX8rFR81ocSo4tkAI+aVmK0e+f/nssGt1liAjxTfTqqKXZcIFTcS3H7PR9ln5TGIq
         lBng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=to:references:message-id:content-transfer-encoding:cc:date
         :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=ixYP9LwA5czUikEeatOgu0kf103Ka1Ni1XWLkQpGlco=;
        b=CQ2kERczkmUrSB7lzeWz6vpQ3HIAtVhtbp3NicqEOwVaVYBPW90+21oATwAQ1BYmET
         D7wKje8XCfQZ0exE9jnHW/TlSb1Kkrhblav6P/Lk88ilfZ1atgzcbYxA7V/3FrJhCqWA
         NxIj9CqYQdFKtMFiZPsLTbhHCyyBnQuRfT9fm5K9uYJ8Rfvo+8e2mwjItAZLSUBZ6C+v
         Jt2FE7u1sF2V+BCDk0yY2l2GcaIftreF24tXQ3xq+/LDUMiJSTZ+uw5ULXvM9FpChbeA
         DL+5i3bmRjFQ6mfzXSdS9KIqItXej37unGkxCuR25dapYYHyccbzNFuZYHPxOqLLe9e4
         AH5Q==
X-Gm-Message-State: AFqh2kr7yOj4ynYGVvU9pH825ZCPTcAdbhsuwAnEn/tIwFAG5WSVXG5a
	uKY+zHpoXmlqGHiRdQyAwX9fj9AHp59ZQ/K7
X-Google-Smtp-Source: AMrXdXvNTdJR54Ta2IXizER9efFNOPSwqbaRf5KzVr/MjjWrkWre7QaOq1Bebb7vqvc1txC1LaQGrw==
X-Received: by 2002:a17:903:230c:b0:192:64a9:62f5 with SMTP id d12-20020a170903230c00b0019264a962f5mr27859159plh.29.1672281073052;
        Wed, 28 Dec 2022 18:31:13 -0800 (PST)
Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229])
        by smtp.gmail.com with ESMTPSA id s19-20020a170903201300b00187197c4999sm11652859pla.167.2022.12.28.18.31.12
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 28 Dec 2022 18:31:12 -0800 (PST)
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.300.101.1.3\))
Subject: Re: native recording of all network connections on freebsd
From: Bakul Shah 
In-Reply-To: 
Date: Wed, 28 Dec 2022 18:31:01 -0800
Cc: freebsd-current@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CC0832A-5852-43A2-ACD6-802BFD9E9BDA@iitbombay.org>
References: 
To: Dan Mack 
X-Mailer: Apple Mail (2.3731.300.101.1.3)
X-Rspamd-Queue-Id: 4NjC7R2ycWz43rf
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Dec 28, 2022, at 6:21 AM, Dan Mack  wrote:
>=20
> I'm wondering if anyone can help point me at a good way to continously =
capture every inbound and outbound connection made to a freebsd system. =
I'd prefer a way that is native in base if possible.   I don't really =
want to record all the packets, just the src:dest:rport:dport stats.

I'd build a simple program using pcap(3), and compile a bpf program
using pcap_compile and then do pcap_setfilter to capture just the
packets I want. Then save the desired fields from captured packets
(and use a hashtable if just {src,dst}{ip,port} are wanted). There
are online examples one can start from.=

From nobody Thu Dec 29 08:39:44 2022
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 4NjMJg4Wbrz2kdRh
	for ; Thu, 29 Dec 2022 08:39:47 +0000 (UTC)
	(envelope-from paulf2718@gmail.com)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NjMJf6LRwz3CBj
	for ; Thu, 29 Dec 2022 08:39:46 +0000 (UTC)
	(envelope-from paulf2718@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b="VJfkeuD/";
	spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::32d as permitted sender) smtp.mailfrom=paulf2718@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-wm1-x32d.google.com with SMTP id k26-20020a05600c1c9a00b003d972646a7dso9624894wms.5
        for ; Thu, 29 Dec 2022 00:39:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id:from
         :to:cc:subject:date:message-id:reply-to;
        bh=2ubPupzPf3riQuoIs2XsJYUIRu0DGhUry2G3mMOReK0=;
        b=VJfkeuD/+KmMhpXlTgM9k4aLIx5r76JKd7AtG3tS+vFDMRDXZX4/fAihtn1aXzZC72
         UtIf/8Kz6jYr6mR4pS+YZ8YrKi6on3OhbtzHtF5VQF6dte1daP9T4n9+7j6nRFFXUlRY
         /sqb9OfTADWC0LDr/ZUUVILDceboqtG9UUNLbsYyWSjBU69HTKlC4E50QN0JN52X2qZd
         UtdLtgIlgiSDa8a5G+b2Hg82k2TKc2wpCmQE34MPbwvCH8LzGYJjuwVCojgAar6jwQeZ
         hsdK+lBcvP6JIgGOCr5AKAAM5R/SVvHttm/MK/VdrqUrH5q8PZHIwziYSMBiAgYb07m6
         NM+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=2ubPupzPf3riQuoIs2XsJYUIRu0DGhUry2G3mMOReK0=;
        b=q8bdOOlI6FP5VNlp9sEBMgglQcY3WO6oq5SKmQD48rUFxsdX33A/s6+/nEhCnqnc9G
         TRS1I5ZDMnFkn0vjADPyRKH1xkcvmixM3awuTYe/Zx7Vat6Kw8YhMvMOdeMwoaTd8p8V
         mVOWvXykXbn1mHoV07gnFLlW4TCUXyo1ZUeKrEYrfBWNsvR+RwX4ZcUFzGKeDQymq2/6
         AmM2YHuxm0GxlUQ5tkBmzPVQ25aNCwuv23nbWRV9cxbf8kwVLI3bOBMZZFh3AwKdx6c+
         XUdb6YwTYLzI/sTHrUW0frUVKJJWWHnBU+okq82SR5oiNdrH6HLSJi/Z4RUtnuaPVlmI
         lMjQ==
X-Gm-Message-State: AFqh2krn2S6Be7hC01OEUwcDDlGFcI0NXGjY2fU2Zjl7si35Jn5aoAgT
	Wp3Qj90dQCdVuMnByDmur62xChGaX2Rfiw==
X-Google-Smtp-Source: AMrXdXuA73DB1GVIjFHp4/W2dckoxlqpkckOXxCmvM9bBQJtzkjjDQq1d+ji5tngDjhC7T/geeVXZA==
X-Received: by 2002:a7b:c3c1:0:b0:3c7:1359:783b with SMTP id t1-20020a7bc3c1000000b003c71359783bmr19660826wmj.1.1672303185594;
        Thu, 29 Dec 2022 00:39:45 -0800 (PST)
Received: from [192.168.1.28] (lfbn-gre-1-309-115.w90-112.abo.wanadoo.fr. [90.112.30.115])
        by smtp.gmail.com with ESMTPSA id bd25-20020a05600c1f1900b003cfd4cf0761sm28789548wmb.1.2022.12.29.00.39.45
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 29 Dec 2022 00:39:45 -0800 (PST)
Message-ID: 
Date: Thu, 29 Dec 2022 09:39:44 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
To: freebsd-current@freebsd.org
References: 
 
Content-Language: en-US
From: Paul Floyd 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-3.99 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.996];
	NEURAL_HAM_SHORT(-0.99)[-0.993];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32d:from];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4NjMJf6LRwz3CBj
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N



On 28-12-22 18:12, Ronald Klop wrote:

> 
> I've had success to capture errors by recording the screen with my phone 
> and playing back on slow speed.
> Another option might be to enable serial port for the console of the 
> guest and capture the output. But I don't know if the default ISO uses 
> that and how hard it is to configure VirtualBox to do that properly.

Hi

I have used my phone before, and I tried that.

The last message with verbose turned on is

isa_probe_children: probing PnP devices
smist: found supported isa bridge Intel PIX4 ISA bridge
panic: td 0x1d94840 stack 0x2424ee8 not in kstack VA 0x2420000 4



A+
Paul


From nobody Thu Dec 29 09:13:24 2022
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 4NjN3W2RzKz2kjH9
	for ; Thu, 29 Dec 2022 09:13:27 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NjN3V4rslz3HBj
	for ; Thu, 29 Dec 2022 09:13:26 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=FfDr+qrZ;
	spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl;
	dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl
Received: from [IPV6:2a02:22e0:cf00:1ff:14:8c0b:28dd:98c] (mzar@[IPv6:2a02:22e0:cf00:1ff:14:8c0b:28dd:98c])
	(authenticated bits=0)
	by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 2BT9DOIr009172
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO)
	for ; Thu, 29 Dec 2022 10:13:24 +0100 (CET)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl;
	s=plan-b-mailer; t=1672305205;
	bh=gCtpJP5K2f8XeeYhPfN7hKNUdEpa0q5qNVlvTRQflds=;
	h=Date:Subject:To:References:From:In-Reply-To;
	b=FfDr+qrZuls3vZ+uD3R8KeQDETc7DfuXGJ+lLSO72t15BkGSU+nqx8BC1umqomTYj
	 Q1vqLIbCyujqD8wlZr85OEhO+nOcVBllnKLGNbnfXWKuwMxj/AprxRTGMaq8c6uyLA
	 Fdgs3CbzyT71B5Qw1ir3mUmMb9ioCo3BDZWnxoAOxYQX/uULMtHSoG0XDcd/u+KUJW
	 w80qM7HRZZb2mqIP/HMWivn+bjybXezohnlCmVyCqCZwE8q/gWRdW/dmPfkLfoo6Gk
	 T1hK2bpMjJ79KsgkWfr2GHEN/+hHUX+Y1dFi1VMWVcD3cbIM0eob5kzPz2xI2b+mKn
	 HYBsQ3S9NeqBA==
Content-Type: multipart/alternative;
 boundary="------------UIWKljjd19Yx81xeL1gh6a3v"
Message-ID: 
Date: Thu, 29 Dec 2022 10:13:24 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: native recording of all network connections on freebsd
Content-Language: en-US
To: freebsd-current@freebsd.org
References: 
 
From: Marek Zarychta 
In-Reply-To: 
X-Spamd-Result: default: False [-3.80 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none];
	R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NjN3V4rslz3HBj
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------UIWKljjd19Yx81xeL1gh6a3v
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

W dniu 29.12.2022 o 02:58, Damjan Jovanovic pisze:
>
>
> On Wed, Dec 28, 2022 at 4:21 PM Dan Mack  wrote:
>
>
>     I'm wondering if anyone can help point me at a good way to
>     continously
>     capture every inbound and outbound connection made to a freebsd
>     system.
>     I'd prefer a way that is native in base if possible.   I don't
>     really want
>     to record all the packets, just the src:dest:rport:dport stats.
>
>     Happy to RTFM as well,
>
>     Dan
>
>
> Another possibility is to enable Netflow in ipfw (there is an 
> ipfw_netflow service), which submits periodic reports of all 
> connections made and their data usage, and then collect and process 
> the Netflow data using a Netflow server.
>
> Or develop a custom Netgraph service that examines packets and logs 
> connections. This would even work in the absence of any firewall.
>
Such a node exists: ng_netflow(4) and works flawlessly.



-- 
Marek Zarychta

--------------UIWKljjd19Yx81xeL1gh6a3v
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
W dniu 29.12.2022 o 02:58, Damjan
      Jovanovic pisze:

    

    

      
      

        


        

        

        

          
On Wed, Dec 28, 2022 at 4:21
            PM Dan Mack <mack@macktronics.com>
            wrote:

          

          


            I'm wondering if anyone can help point me at a good way to
            continously 

            capture every inbound and outbound connection made to a
            freebsd system. 

            I'd prefer a way that is native in base if possible.   I
            don't really want 

            to record all the packets, just the src:dest:rport:dport
            stats.

            

            Happy to RTFM as well,

            

            Dan

            

          

          


          

          
Another possibility is to enable Netflow in ipfw (there
            is an ipfw_netflow service), which submits periodic reports
            of all connections made and their data usage, and then
            collect and process the Netflow data using a Netflow server.

          


          

          
Or develop a custom Netgraph service that examines
            packets and logs connections. This would even work in the
            absence of any firewall.

          


          

        

      

    

    
Such a node exists: ng_netflow(4) and works flawlessly.

    

    


    

    


    

    
-- 
Marek Zarychta

  


--------------UIWKljjd19Yx81xeL1gh6a3v--

From nobody Wed Dec 28 14:52:54 2022
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 4NjRd070s2z2l7P8
	for ; Thu, 29 Dec 2022 11:54:12 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NjRd06WJ0z3rg8
	for ; Thu, 29 Dec 2022 11:54:12 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1672314852;
	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=tkPliJLVgZQRzAEEoslXPwGHfq4omEyzufnDw9kouvs=;
	b=sj9oEMrzQDhQagbo7GjMsgx69lYx+7sx676YeYDMLJN4EbjZjk58WDXc9b5xwQSRT0QBvo
	MMNaf4y2PBIc1nOPaAjHuo3vus3Ra98nnmbrsrChY9x2j1Qy+JsEg2s7n9PmhokqjmvFnL
	mQpDl3A/UBJOORbF0od1SO2UD/C/Tcy2XP4yUKcRqYnggpHpVZy//WBXwOQqQU7bsjfCFP
	uzjEdXYGVW3PHFA97/qpHw7LOe+AGwXqbItVvwgV0CqOrj5oOMi6ToqKCD7Mt7KV+perO2
	dykXNutn+V6rjl98F8E3pOQ7ZXXQ20BXKaroZ/RzwGqTmkwkYCLlhmg/2JLpug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1672314852;
	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=tkPliJLVgZQRzAEEoslXPwGHfq4omEyzufnDw9kouvs=;
	b=k/1B6fqMFADHWm1jx8M1NRjcgNX7tlvVRIgSwJERKvfVU98qOl2tWrHMNfW69HHDKULhD+
	0lRN0sT6KupRRKyrttkKtbKT6KhR1RzXUTNaCFO3gD91o1iTNY/2R53tQDfeaEH1t0ELHm
	2QsOCLp9r7NtV1pRtjFaI+P8SJOVKFbnKUW8DgdtLYGlmB/2c0UhW7vBdSimR7464mQkF+
	0NMJevzHCe8eP3vpLqQME5fwDzuf75HT/39I5ooozmSViklQxLa4CigvoGAH4yP4FB0b7R
	cPkbj0n9F+doGHCuq4ZC8sZmDx62H7YTJPigV/l5Kira/liTXjw7UBUgSWjhIQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672314852; a=rsa-sha256; cv=none;
	b=okIH5PkJhhB4HcdxHVUrjDsCf9QwfqwOBEeWQbSXcHIRFwLvy7rjOPeqsnIM1ewU5bR2RV
	/Mwa37aEbNyr/hFskqBA/YgfsrUXWdUbOIc4mfgL+zMUhDOgxfTg8VUS5VIyjITORFC9qE
	jrJxoTPym9RfEm78gtVo62d3VMW9QKa9QlL3p9pZeeBa8OGEs6GJhHbelFGctKlSTdupsI
	9EPVngTKjMdgTlhVlnMvvt29WOekIUR+REIm+7+zDN5ZzPNloZfHPGIS+zl4tR2zMCxEaY
	EjmYGaNCEu3qzDUHv2nvZg2Lx/naeMmn8JpzKOkeSRdGJZcVbb64xwFJqkY4RA==
Received: from ns2.wilbury.net (ns2.wilbury.net [IPv6:2a01:b200:0:1:f816:3eff:fecd:13e6])
	(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 "svc.wilbury.net", Issuer "R3" (verified OK))
	(Authenticated sender: otis)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NjRd04pT0zsBQ
	for ; Thu, 29 Dec 2022 11:54:12 +0000 (UTC)
	(envelope-from otis@FreeBSD.org)
Received: by svc.wilbury.net (Postfix, from userid 125)
	id 20D0345D401; Thu, 29 Dec 2022 10:21:47 +0100 (CET)
Received: from smtpclient.apple (gw-upc.owhome.net [188.167.168.254])
	(Authenticated sender: juraj@lutter.sk)
	by svc.wilbury.net (Postfix) with ESMTPSA id DD7CB45D28C
	for ; Wed, 28 Dec 2022 15:52:54 +0100 (CET)
From: Juraj Lutter 
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 \(3696.120.41.1.1\))
Subject: Re: native recording of all network connections on freebsd
Date: Wed, 28 Dec 2022 15:52:54 +0100
References: 
 
To: FreeBSD Current 
In-Reply-To: 
Message-Id: <96D7C087-7C42-420F-A032-A3430658EC52@FreeBSD.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,KHOP_HELO_FCRDNS,
	SPF_HELO_NONE,SPF_SOFTFAIL,TW_PF autolearn=no autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ns2.wilbury.net
X-ThisMailContainsUnwantedMimeParts: N



> On 28 Dec 2022, at 15:28, Sami Halabi  wrote:
>=20
> using firewall ike ipfw with rule to log any to any would be a start.. =
for advanced use, stateful fw so You can log start of connections

I would also consider using ng_netflow(4) with, for example, nfsend or =
even
logstash with netflow input module (and stored into elastic indexes),
visualized by kibana or other tools.


=E2=80=94
Juraj Lutter
otis@FreeBSD.org


From nobody Fri Dec 30 00:54:51 2022
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 4Njmxx1qytz2kbvZ
	for ; Fri, 30 Dec 2022 00:55:01 +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 4Njmxw5hylz46wp
	for ; Fri, 30 Dec 2022 00:55:00 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 2BU0spXv051316
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 30 Dec 2022 02:54:55 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 2BU0spXv051316
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 2BU0spe7051315;
	Fri, 30 Dec 2022 02:54:51 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Fri, 30 Dec 2022 02:54:51 +0200
From: Konstantin Belousov 
To: Paul Floyd 
Cc: freebsd-current@freebsd.org
Subject: Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
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=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home
X-Rspamd-Queue-Id: 4Njmxw5hylz46wp
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Thu, Dec 29, 2022 at 09:39:44AM +0100, Paul Floyd wrote:
> 
> 
> On 28-12-22 18:12, Ronald Klop wrote:
> 
> > 
> > I've had success to capture errors by recording the screen with my phone
> > and playing back on slow speed.
> > Another option might be to enable serial port for the console of the
> > guest and capture the output. But I don't know if the default ISO uses
> > that and how hard it is to configure VirtualBox to do that properly.
> 
> Hi
> 
> I have used my phone before, and I tried that.
> 
> The last message with verbose turned on is
> 
> isa_probe_children: probing PnP devices
> smist: found supported isa bridge Intel PIX4 ISA bridge
> panic: td 0x1d94840 stack 0x2424ee8 not in kstack VA 0x2420000 4
> 
%esp is indeed outside the KVA for the thread stack, assuming the
numbers are accurate.  It should be in range of 0x2420000 - 0x2424000.
I just checked random boot in qemu for latest GENERIC/i386, and thread0
stack pointer returned by init386() is inside THREAD0_STACK.

The backtrace is needed to make a further analysis.

From nobody Sat Dec 31 17:57:51 2022
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 4Nkqbz3BTrz2kwqm
	for ; Sat, 31 Dec 2022 17:58:07 +0000 (UTC)
	(envelope-from obiwac@gmail.com)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nkqby50dcz3Nms;
	Sat, 31 Dec 2022 17:58:06 +0000 (UTC)
	(envelope-from obiwac@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=MMhRDvjK;
	spf=pass (mx1.freebsd.org: domain of obiwac@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) smtp.mailfrom=obiwac@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-ej1-x630.google.com with SMTP id ud5so58231408ejc.4;
        Sat, 31 Dec 2022 09:58:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=e8goITse2Ja0Y1uZZmPuSwjIw93UXnfLW3Q04smbW8k=;
        b=MMhRDvjKjflxdEgV6mWkiIgcX5b1hBy5Q3fEqTJNhHBZbrS7Eow9Dm4F9xxlas6zHe
         x2BdF6JKOQ9BTVa9A+2pcAfmzF0SzVH5SftCoz2UzMW2oSPI3idWz/wHRZDgAOmk6tqC
         L89LyAlKvOXi9zpXjcz8QyAOSYhqiUj9DfrMcZuuUwMrO5foFzMvwAGEV3aTPQ/PALVg
         7U6dfBwn0wN13zHq7NJJhWCAe9qBlswks0zW5OyRXrjZMKQauOlHEZ61ER/QUVMUExta
         th+DTOUCua+H+nNlRSfUI5MzHX0eSjxyZbKvCiJ4aRUKt+ahX/wwtg2usEXdZI3If8tb
         yXEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=e8goITse2Ja0Y1uZZmPuSwjIw93UXnfLW3Q04smbW8k=;
        b=5R5AEuorWZ3lqC0q2XDWkJSUqQ8nyA/GXed+lOjJkF6R/OSgTUBCRXU/VXacaBilxR
         bV5gYijqcPQf76GPCOrLcSTSn4oaDK77dSyb6F/HiNPc3d2cosJONWZGaOp02QT8knbB
         4TxmIZJxWmTLYQzrTOU21VQrkrA8OHsaYAN728wUadJbTsl685BCtnu9U2ArdAuAOGIJ
         yvAVRISvKKyEsI3WpY1GbhDCiNPG8egGLkj0qEO7JqL4L2TkuhR3IhHv7Z5Q7zzgTpRz
         QHM+7v0AjPjJJwqPALSxJygCfbDXgOkvJMEoOzdwOHGAjFZo6CX5nJ/tR3Zs8gW05lea
         ssuQ==
X-Gm-Message-State: AFqh2krl8Xhp7bvOawJPodYrqfrZixfjdVMlV9eOjuTLdniunO+71S9e
	xzahE9KNa9In/NCOyl09fpH09uLu0UsUSHDZXtqIRCMbDWk=
X-Google-Smtp-Source: AMrXdXtakdxBSW8m1KcQffjVp6gAoHBx9nAMR6ewIr4DE+O8GyJVnSshPrhaUFmmgd5YbKNbXe3Akel7UdY8BPLLc3Q=
X-Received: by 2002:a17:906:9402:b0:781:fcf6:e73a with SMTP id
 q2-20020a170906940200b00781fcf6e73amr1940966ejx.352.1672509485054; Sat, 31
 Dec 2022 09:58:05 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
From: obiwac 
Date: Sat, 31 Dec 2022 18:57:51 +0100
Message-ID: 
Subject: i915: RCS timing out when being idled
To: freebsd-current@freebsd.org
Cc: manu@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000bd7e9d05f12375cd"
X-Spamd-Result: default: False [-3.98 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.976];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_TLS_LAST(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::630:from];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	FREEMAIL_FROM(0.00)[gmail.com];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-Rspamd-Queue-Id: 4Nkqby50dcz3Nms
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--000000000000bd7e9d05f12375cd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey,

I didn't find a more appropriate mailing list to post to, so here it goes:

I'm running what is essentially FreeBSD-CURRENT on an Asus C300 Chromebook
(iGPU, gen 7).

Building branch 5.10-lts (or HEAD on main for that matter) of drm-kmod and
loading i915kms results in a wedged GPU, after a call to
intel_gt_wait_for_idle fails in __engines_record_defaults in
drivers/gpu/drm/i915/gt/intel_gt.c.

It fails waiting for the RCS0 engine; not loading a new context to it (i.e.
adding a few 'if (id =3D=3D RCS0) continue;' lines to ignore it) allows the=
 GPU
to continue initialisation without wedging. This isn't ideal though because
the RCS ends up unhappy after a bit of load and the GPU hangs (RCS engine
crashes) :P

I guess the issues (the wedging and the hang) could be unrelated but I have
a strong suspicion they are.

I've been trying to understand how the whole i915 stuff is architectured
for a couple days now (Intel's vocabulary is very confusing ngl), but there
are a few things I can't really wrap my head around, which leads me asking
for help debugging here =F0=9F=98=84

Is there anything else I can try in terms of troubleshooting/anyone else I
can contact for help? If not I wouldn't really mind attempting to
understand everything through-and-through and fix the issue myself, if
there was someone I could ask for a couple short explanations on bits of
the driver ;)

Last I checked, everything was working well with drm-tip on Linux.

Kind regards and a happy new year,
Aymeric =F0=9F=A5=82

--000000000000bd7e9d05f12375cd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey,

<=
div dir=3D"auto">I didn't find a more appropriate mailing list to post =
to, so here it goes:

I&#=
39;m running what is essentially FreeBSD-CURRENT on an Asus C300 Chromebook=
 (iGPU, gen 7).

Building=
 branch 5.10-lts (or HEAD on main for that matter) of drm-kmod and loading =
i915kms results in a wedged GPU, after a call to intel_gt_wait_for_idle fai=
ls in __engines_record_defaults in drivers/gpu/drm/i915/gt/intel_gt.c.

It fails waiting for the RCS=
0 engine; not loading a new context to it (i.e. adding a few 'if (id =
=3D=3D RCS0) continue;' lines to ignore it) allows the GPU to continue =
initialisation without wedging. This isn't ideal though because the RCS=
 ends up unhappy after a bit of load and the GPU hangs (RCS engine crashes)=
 :P

I guess the issues (=
the wedging and the hang) could be unrelated but I have a strong suspicion =
they are.

I've been =
trying to understand how the whole i915 stuff is architectured for a couple=
 days now (Intel's vocabulary is very confusing ngl), but there are a f=
ew things I can't really wrap my head around, which leads me asking for=
 help debugging here =F0=9F=98=84

Is there anything else I can try in terms of troubleshooting/anyo=
ne else I can contact for help? If not I wouldn't really mind attemptin=
g to understand everything through-and-through and fix the issue myself, if=
 there was someone I could ask for a couple short explanations on bits of t=
he driver ;)

Last I checked, everything wa=
s working well with drm-tip on Linux.

Kind=C2=A0regards and a happy new year,
Ay=
meric =F0=9F=A5=82


--000000000000bd7e9d05f12375cd--

From nobody Sat Dec 31 23:10:40 2022
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 4NkyXy0PbJz2ngfc
	for ; Sat, 31 Dec 2022 23:10:58 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NkyXx4qXSz462y;
	Sat, 31 Dec 2022 23:10:57 +0000 (UTC)
	(envelope-from kob6558@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-476e643d1d5so228243807b3.1;
        Sat, 31 Dec 2022 15:10:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=pZNsgmZ9o+v5EzBXhbCt+iUYvxlUa8/Lyfzsw/9k3Gw=;
        b=bz7BC9JrcI4aeP4/n/fvdLJqd7g/vCC+coFWuEmKpn9GqnJHgFiSqLgb3RFXWPp6DW
         5UF3wP+pStzkWr9f98s9knFRQGPSjIr0yjddCx9xYu0hLm1rFX9F5PGEZWMGjWokKvhb
         rJQ9CfbhAIQ62RFjobPCmh/Yrl6BOju2mIqaSGi0047abwsSh6ePi09WxNHDr4nOjHub
         5/QN9JL46IZ8nq6+cnGSXp2bWIank2CwJ7Q+gch4d2mwo0i9ASAnPpt8WwTfpWqbLuDh
         zj9nV/aen6VayQ3ESTnQCPG3MMSyNc4h/P5v4hJTNri9+1uoTMuw0HbEqMmC/7+CAng8
         DYig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=pZNsgmZ9o+v5EzBXhbCt+iUYvxlUa8/Lyfzsw/9k3Gw=;
        b=dI0auwJkZmXqjNRCyQ1tnZ6WE+9y+ccXyD0vgN/+0ZTT+8F6hlx59TZiQ8pctDcORS
         n75/6fAZFMsHgtl4SKfDmfSKMKwFhcRkfybJzgXq48uAj/PYD3IhR/0yARC2wxuVf51Q
         XDLZYejKW2MBHq3HEaCwRZkilj3A6p3eSpid3UlpxKY/BMucofPLf2YWHNNXpG3axbP+
         8uTnQSFHKLeHZBhNP/pDSIh0dNexxs8rCDsvJLVCskMY9mo9XliKBMRJp5UsrgKAXEoE
         zoyZCBWVETskcEZSf70uwEqL0b8dRUH0Ubkz24uNbiv+Z93sU/YpqtJ8NeqaV8qYu/Te
         6edA==
X-Gm-Message-State: AFqh2krnxoQenzgb68JPgBcJ0L7lK7IESGjEW68gAE9tuBmvthV3VE4o
	f7PqHXPvaQeYUXe/f0F7sn39tHsoHaxr2IlTPR4=
X-Google-Smtp-Source: AMrXdXsyT6BZspnSxF6zr/EoHfrG2BWNrhqt1MT2j824lz0AscB45TtSo9WT6+cwHTCyVoQ1STM8n3W1bzM+LHGUI7M=
X-Received: by 2002:a81:6908:0:b0:45d:f0c4:cf4f with SMTP id
 e8-20020a816908000000b0045df0c4cf4fmr3864807ywc.251.1672528256089; Sat, 31
 Dec 2022 15:10:56 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Kevin Oberman 
Date: Sat, 31 Dec 2022 15:10:40 -0800
Message-ID: 
Subject: Re: i915: RCS timing out when being idled
To: obiwac 
Cc: freebsd-current@freebsd.org, manu@freebsd.org
Content-Type: multipart/alternative; boundary="00000000000094c37e05f127d49e"
X-Rspamd-Queue-Id: 4NkyXx4qXSz462y
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--00000000000094c37e05f127d49e
Content-Type: text/plain; charset="UTF-8"

On Sat, Dec 31, 2022 at 9:58 AM obiwac  wrote:

> Hey,
>
> I didn't find a more appropriate mailing list to post to, so here it goes:
>
I'm afraid I can't really help with your problem, but issues with graphics
should be sent to FreeBSD graphics GitHub
. I think having this outside of the
standard FreeBSD support structure has bothered me since it was moved from
the Bugziila a few years ago. If you want a mailing list, x11@freebsd.org
would be most appropriate, though you need to subscribe first.
-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

--00000000000094c37e05f127d49e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sat, Dec 31, 2022 at 9:58 AM obiwac <obiwac@gmail.com> wrote:
Hey,

I didn't find a more =
appropriate mailing list to post to, so here it goes:
I'm afraid I can&#=
39;t really help with your problem, but issues with graphics should be sent=
 to FreeBSD graphics GitHu=
b. I think having this outside of the standard FreeBSD support structur=
e has bothered me since it was moved from the Bugziila a few years ago. If =
you want a mailing list, x11@freebsd.org=
 would be most appropriate, though you need to subscribe first.
-- 
<=
div>
Kevin Oberman, Part time kid herder and retired Networ=
k Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B7=
8C1694B318AB39EF1B055683


--00000000000094c37e05f127d49e--

From nobody Sun Jan  1 08:35:14 2023
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 4NlC424TQVz1Lm7X
	for ; Sun,  1 Jan 2023 08:35:14 +0000 (UTC)
	(envelope-from danfe@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NlC423qTjz3ppS;
	Sun,  1 Jan 2023 08:35:14 +0000 (UTC)
	(envelope-from danfe@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1672562114;
	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=5NSshynNv4DifPwjlD9JBmhETnx69uVQPBKPlFxfSMk=;
	b=mrNqzs/fqrlqV5aNDk5fipQWl8YUwNu0cPmZasQ06fgEUMmG1K/i03kLTDMe6RXdozvooo
	BKR+qBM+rXzhuQ7m+WBEbEIbVmeiuQ7E+b8eX3zwzfPllYs6b4VK8kzjYjC/QoHOOIEiCB
	U1cP+oPFV1V/7K4ah/VkXsFlb0d5oSgwUaHxN0/Hi2ACUsUhvphZAmIp+5hcuIKFQu/aBX
	FcnfByCZyS4zImD3vSik/FZfdI/dkO70f04Af0PUVyxb3LxRCqK0LuD8nt1l260OB6VCik
	LXHe9F/WalT88zx+1hrlzBVbwSOMjtRb5R5zz+dCjIN6am1yuFYpXVgoeEwoSQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1672562114;
	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=5NSshynNv4DifPwjlD9JBmhETnx69uVQPBKPlFxfSMk=;
	b=nOFQw3kfHOPJLcV9ebFTaP2XeHKlRrSHllVsrYgZFyVGCbLqDWXL46cxQiITNRY3um3plC
	XHQuhsSvWSSTJb54sa34/rXP1gKKISGRX6fvzBLl8EZZg7lCuVSLCHpmoib/CfDeLx00zG
	MWQ9PWdqbdYwZVYAt3UBO/06VElGzEoGjAmXaDV+OuaF59ppuJ3WY60AoOXVWtitsQRo2R
	BHypog2vAO6p4pRVQ6e9O5Bj6BiAW9JUKND1jomZ7UOlLk18S7DUa0gkpCr0anWMCwMC3s
	x+u1DefLaHZIX3FFf7w/Pk9ArsGG3zhyiHwisLTvsCu/AO9M+gOd4ZmCgjWeIw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672562114; a=rsa-sha256; cv=none;
	b=BcXJmekw0Z3aAdfnxSCRdH2BZEan0U5ttQ2CDPzws8sWAYYaYhR5rzT6SURQofDyKxWt9c
	ZOzfTBeoaUwd/wbeHi3kZzIvA/NJt+0at8HypHXlq81qcDMvKgFooqOGmfqJCShJk1LwZw
	R5fsdo1FYhY+s68D4MsVoD1fFiGQFJNdgl6OyS4+/4vbJUvKLUIyRZqi6b1cSoJ+7mHY0M
	uaPIJVoH5xYt4LCHx3juBryKBFXSpguHraXiS7hpzFdkMuyxDrYU5uNgX+klVUZO6htSXE
	Tr58qohG5mnuPBPHluAE2SmufQA54pzzukABGggW2fFX/jUQS/4qS/wbcth9cA==
Received: by freefall.freebsd.org (Postfix, from userid 1033)
	id 6C0611D12C; Sun,  1 Jan 2023 08:35:14 +0000 (UTC)
Date: Sun, 1 Jan 2023 08:35:14 +0000
From: Alexey Dokuchaev 
To: Warner Losh 
Cc: FreeBSD Current 
Subject: Re: Disk partitions disappear when mounting others
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-ThisMailContainsUnwantedMimeParts: N

On Sun, Dec 25, 2022 at 09:32:55AM -0700, Warner Losh wrote:
> On Sun, Dec 25, 2022, 1:02 AM Alexey Dokuchaev  wrote:
> > ...
> > The problem is that once I mount my old FreeBSD partition, e.g.
> > /dev/ada0s2a, those LVM nodes are gone, logging this:
> >
> >   GEOM_LINUX_LVM: disk pv0 already initialised in fedora
> >   GEOM_LINUX_LVM: Disk diskid/DISK-XXXXXXX1s4+00000001 removed from pv0.
> >   GEOM_LINUX_LVM: Device linux_lvm/fedora-swap removed.
> >   GEOM_LINUX_LVM: Device linux_lvm/fedora-home removed.
> >   GEOM_LINUX_LVM: Device linux_lvm/fedora-root removed.
> >
> > If I unmount /dev/ada0s2a and mount any Fedora's partition, then I can
> > longer access other slices as there's only /dev/ada0 remains; ``gpart
> > show'' also does not list them, but only those under diskid/DISK-XXXXXXX1.
> >
> > Why is this happening?  What should I fix to stop my partitions from
> > disappearing and reappearing?
> 
> Something has them open. My guess is the Linux lvm geom provider opens too
> many things. It's been standard geom behavior to remove the other device
> aliases in /dev when one is open.

Well, yeah, but it's weird to see that on a detached harddrive.  It's not
like it's still opened under another operating system, I'm simply mounting
existing partitions one by one to move my data to a new SSD.

> Though the problem may be in tasting during open since gpart list shows
> them gone.

I've found out that putting either geom_linux_lvm_load="YES" or kern.geom.
label.disk_ident.enable=0 in /boot/loader.conf remedies the problem.  Just
in case someone encounters the same issue.  When I was still booting off
this disk, I had geom_linux_lvm_load="YES" so that's probably why it did
not bite me before.

./danfe

From nobody Mon Jan  2 17:14:51 2023
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 4Nm2YC3Nccz2p2SQ
	for ; Mon,  2 Jan 2023 17:14:55 +0000 (UTC)
	(envelope-from mikej@paymentallianceintl.com)
Received: from us-smtp-delivery-197.mimecast.com (us-smtp-delivery-197.mimecast.com [170.10.133.197])
	(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 "*.mimecast.com", Issuer "DigiCert TLS RSA SHA256 2020 CA1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nm2YB53C9z3LpC
	for ; Mon,  2 Jan 2023 17:14:54 +0000 (UTC)
	(envelope-from mikej@paymentallianceintl.com)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	spf=pass (mx1.freebsd.org: domain of mikej@paymentallianceintl.com designates 170.10.133.197 as permitted sender) smtp.mailfrom=mikej@paymentallianceintl.com;
	dmarc=none
Received: from MAIL2.pai.local (175.158.26.216.gopai.com [216.26.158.175])
 by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 us-mta-650-H_QvD5KXPde_tMkOgVHnig-1; Mon, 02 Jan 2023 12:14:52 -0500
X-MC-Unique: H_QvD5KXPde_tMkOgVHnig-1
Received: from MAIL1.pai.local (10.10.0.192) by MAIL2.pai.local (10.10.0.193)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Mon, 2 Jan
 2023 12:14:51 -0500
Received: from MAIL1.pai.local ([fe80::dd29:5379:c237:1209]) by
 MAIL1.pai.local ([fe80::dd29:5379:c237:1209%3]) with mapi id 15.01.2507.016;
 Mon, 2 Jan 2023 12:14:51 -0500
From: Michael Jung 
To: freebsd-current 
Subject: witness_lock_list_get: witness exhausted
Thread-Topic: witness_lock_list_get: witness exhausted
Thread-Index: AdkezGkp4bqsJ7wHQoaOgpcPv6aHnQ==
Date: Mon, 2 Jan 2023 17:14:51 +0000
Message-ID: 
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.250.0.59]
x-c2processedorg: 474f336e-f930-49ec-9717-e3226b5b6e6e
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-Mimecast-Spam-Score: 0
X-Mimecast-Originator: paymentallianceintl.com
Content-Type: multipart/alternative;
	boundary="MCBoundary=_12301021214530581"
X-Spamd-Result: default: False [-3.16 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_SHORT(-0.96)[-0.960];
	R_SPF_ALLOW(-0.20)[+ip4:170.10.133.0/24];
	MIME_BASE64_TEXT(0.10)[];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[170.10.133.197:from];
	R_DKIM_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:30031, ipnet:170.10.132.0/23, country:US];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[4];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	HAS_XOIP(0.00)[];
	TO_DN_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[paymentallianceintl.com];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4Nm2YB53C9z3LpC
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

--MCBoundary=_12301021214530581
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

Rmlyc3Qgc2hhbWUgb24gbWUgYXMgSSBvYnZpb3VzbHkgbWlzc2VkIHRoZSByZXBseSB0byBteSBm
b3JtZXIgcmVwb3J0IGFuZCBkaWQgbm90DQpyZXBvcnQgYmFjayBvbiBhIHByb3Bvc2VkIHBhdGNo
Lg0KDQpodHRwczovL2xpc3RzLmZyZWVic2Qub3JnL3BpcGVybWFpbC9mcmVlYnNkLWN1cnJlbnQv
MjAxOC1KYW51YXJ5LzA2ODEzNi5odG1sDQoNCkkgYW0gc3RpbGwgcnVubmluZyBjdXJyZW50IOKA
kyB0aGUgZ3Vlc3QgaGFzIDE2MEdCIFJhbSBhbmQgNjQgdkNQVeKAmXMgYXNzaWduZWQgdW5kZXIg
RVNYaQ0Kd2hpY2ggbWFpbmx5IHJ1bnMgcG91ZHJpZXJlIGZvciBhbWQ2NCthcm0gYnVpbGRzIGFu
ZCBJIGFnYWluIG5vdGljZWQNCiJ3aXRuZXNzX2xvY2tfbGlzdF9nZXQ6IHdpdG5lc3MgZXhoYXVz
dGVkIiBvbiB0aGUgY29uc29sZSAod2hpY2ggSSBkb24ndCBwYXkgbXVjaCBhdHRlbnRpb24gdG8p
Lg0KDQpVTkFNRTogRnJlZUJTRCBwb3VkcmllcmUuZ29wYWkuY29tIDE0LjAtQ1VSUkVOVCBGcmVl
QlNEIDE0LjAtQ1VSUkVOVCAjMCBtYWluLW4yNTk4NzItZjk0OGNiNzE3ZjUwOiBXZWQgRGVjIDI4
IDEzOjEzOjQzIEVTVCAyMDIyICAgICBtaWtlakBwb3VkcmllcmUuZ29wYWkuY29tOi91c3Ivb2Jq
L3Vzci9zcmMvYW1kNjQuYW1kNjQvc3lzL0dFTkVSSUMgYW1kNjQNCg0KSXQgc2VlbXMgdGhhdCBM
T0NLX05DSElMRFJFTiBhbmQgTE9DS19DSElMRENPVU5UIG5ldmVyIGdvdCBpbmNyZW1lbnRlZCBk
dWUgdG8gbXkgbGFjayBvZiByZXBvcnRpbmcgaW4NCi91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfd2l0
bmVzcy5jDQoNCklmIGl0J3MganVzdCBhIG1hdHRlciBvZiBpbmNyZW1lbnRpbmcgTE9DS19DSElE
Q09VTlQgNDA5NiBhbmQgTE9DS19OQ0hJTERSRU4gMjAgd2l0aG91dCBhZGRpbmcgdGhlDQpzeXNj
dGwga25vYnMgSSBkbyB0aGF0IGFsc28gLSBJIGFtIG5vdCBrZXJuZWwgc2F2dnkuDQoNCkkgd2ls
bCBtYWtlIHN1cmUgYW5kIHRlc3QgYW4gdXBkYXRlZCBwYXRjaCBzaG91bGQgb25lIGJlIG1hZGUg
YXZhaWxhYmxlIG9yIGFkdmlzZSB3aGV0aGVyIHRvIGluY3JlbWVudCB0aGVzZSB2YWx1ZXMNCm9y
IGlnbm9yZSB0aGUgd2FybmluZ3MuDQoNClJlZ2FyZHMsDQoNCk1pY2hhZWwgSnVuZw0KDQoNCg0K
DQoNCkNPTkZJREVOVElBTElUWSBOT1RFOiBUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgb25seSBm
b3IgdGhlIHVzZQ0Kb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gaXQgaXMgYWRk
cmVzc2VkIGFuZCBtYXkNCmNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBwcml2aWxlZ2VkLCBj
b25maWRlbnRpYWwsIGFuZA0KZXhlbXB0IGZyb20gZGlzY2xvc3VyZSB1bmRlciBhcHBsaWNhYmxl
IGxhdy4gSWYgdGhlIHJlYWRlcg0Kb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQg
cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieQ0Kbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlv
biwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcNCm9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJp
Y3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZQ0KcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g
aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgYnkNCnRlbGVwaG9uZSBhdCAoNTAyKSAyMTItNDAw
MCBvciBub3RpZnkgdXMgYXQgUEFJLCBEZXB0LiA5OSwNCjIxMDEgSGlnaCBXaWNraGFtIFBsYWNl
LCBTdWl0ZSAxMDEsIExvdWlzdmlsbGUsIEtZIDQwMjQ1DQoNCkRpc2NsYWltZXINCg0KVGhlIGlu
Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gZnJvbSB0aGUgc2VuZGVy
IGlzIGNvbmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB1c2UgYnkgdGhlIHJl
Y2lwaWVudCBhbmQgb3RoZXJzIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBpdC4gSWYgeW91IGFyZSBu
b3QgdGhlIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xv
c3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHRha2luZyBhY3Rpb24gaW4gcmVsYXRpb24g
b2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRl
ZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KDQpUaGlzIGVtYWlsIGhhcyBiZWVuIHNjYW5uZWQgZm9y
IHZpcnVzZXMgYW5kIG1hbHdhcmUsIGFuZCBtYXkgaGF2ZSBiZWVuIGF1dG9tYXRpY2FsbHkgYXJj
aGl2ZWQgYnkgTWltZWNhc3QsIGEgbGVhZGVyIGluIGVtYWlsIHNlY3VyaXR5IGFuZCBjeWJlciBy
ZXNpbGllbmNlLiBNaW1lY2FzdCBpbnRlZ3JhdGVzIGVtYWlsIGRlZmVuc2VzIHdpdGggYnJhbmQg
cHJvdGVjdGlvbiwgc2VjdXJpdHkgYXdhcmVuZXNzIHRyYWluaW5nLCB3ZWIgc2VjdXJpdHksIGNv
bXBsaWFuY2UgYW5kIG90aGVyIGVzc2VudGlhbCBjYXBhYmlsaXRpZXMuIE1pbWVjYXN0IGhlbHBz
IHByb3RlY3QgbGFyZ2UgYW5kIHNtYWxsIG9yZ2FuaXphdGlvbnMgZnJvbSBtYWxpY2lvdXMgYWN0
aXZpdHksIGh1bWFuIGVycm9yIGFuZCB0ZWNobm9sb2d5IGZhaWx1cmU7IGFuZCB0byBsZWFkIHRo
ZSBtb3ZlbWVudCB0b3dhcmQgYnVpbGRpbmcgYSBtb3JlIHJlc2lsaWVudCB3b3JsZC4gVG8gZmlu
ZCBvdXQgbW9yZSwgdmlzaXQgb3VyIHdlYnNpdGUuDQo=
--MCBoundary=_12301021214530581
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

First shame on me as I obviously missed the reply t=
o my former report and did not

report back on a proposed patch.



https://lists.freebsd.org/pipermail/freebsd=
-current/2018-January/068136.html



I am still running current =E2=80=93 the guest has 160GB Ram and 64 vCPU=E2=
=80=99s assigned under ESXi

which mainly runs poudriere for amd64+arm builds and I again noticed

"witness_lock_list_get: witness exhausted" on the console (which =
I don't pay much attention to).



UNAME: FreeBSD poudriere.gopai.com 14.0-CURRENT FreeBSD 14.0-CURRENT #0 mai=
n-n259872-f948cb717f50: Wed Dec 28 13:13:43 EST 2022     mikej@poudriere.go=
pai.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64



It seems that LOCK_NCHILDREN and LOCK_CHILDCOUNT never got incremented due =
to my lack of reporting in

/usr/src/sys/kern/subr_witness.c



If it's just a matter of incrementing LOCK_CHIDCOUNT 4096 and LOCK_NCHILDRE=
N 20 without adding the

sysctl knobs I do that also - I am not kernel savvy.



I will make sure and test an updated patch should one be made available or =
advise whether to increment these values

or ignore the warnings.



Regards,



Michael Jung











CONFIDENTIALITY NOTE: This message is intended only for the use

of the individual or entity to whom it is addressed and may

contain information that is privileged, confidential, and

exempt from disclosure under applicable law. If the reader

of this message is not the intended recipient, you are hereby

notified that any dissemination, distribution or copying

of this communication is strictly prohibited. If you have

received this transmission in error, please notify us by

telephone at (502) 212-4000 or notify us at PAI, Dept. 99,

2101 High Wickham Place, Suite 101, Louisville, KY 40245




<=
b>Disclaimer
The information contained in this communication from the sender i=
s confidential. It is intended solely for use by the recipient and others a=
uthorized to receive it. If you are not the recipient, you are hereby notif=
ied that any disclosure, copying, distribution or taking action in relation=
 of the contents of this information is strictly prohibited and may be unla=
wful.

This email has been scanned for viruses and malware, and may h=
ave been automatically archived by Mimecast, a leader in email security and=
 cyber resilience. Mimecast integrates email defenses with brand protection=
, security awareness training, web security, compliance and other essential=
 capabilities. Mimecast helps protect large and small organizations from ma=
licious activity, human error and technology failure; and to lead the movem=
ent toward building a more resilient world. To find out more, visit our web=
site.


--MCBoundary=_12301021214530581--


From nobody Mon Jan  2 17:43:57 2023
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 4Nm3Bx5WsDz2p5mQ
	for ; Mon,  2 Jan 2023 17:44:09 +0000 (UTC)
	(envelope-from rcarter@pinyon.org)
Received: from out-139.mta0.migadu.com (out-139.mta0.migadu.com [IPv6:2001:41d0:1004:224b::8b])
	(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 4Nm3Bw1klPz3Q5N
	for ; Mon,  2 Jan 2023 17:44:08 +0000 (UTC)
	(envelope-from rcarter@pinyon.org)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=pinyon.org header.s=key1 header.b=p6Goiey2;
	spf=pass (mx1.freebsd.org: domain of rcarter@pinyon.org designates 2001:41d0:1004:224b::8b as permitted sender) smtp.mailfrom=rcarter@pinyon.org;
	dmarc=none
Message-ID: 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pinyon.org; s=key1;
	t=1672681439;
	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=jqa2mipMhza4PKW8kFfpuXaTQMmsE5uFD+OHfACJZeQ=;
	b=p6Goiey2dODGhcWFwLnDcqrSzAMdBnSQMv2D1scfXDZRYOEdai9kS/c7HAl666O1wgsAUb
	MEu36IEFTzUV1+EWiy9l9B2kF7LbZYIb175PHbEM6mSg2NrqaNgjIXjHVpde5S9Rp2/qVl
	F/VsR8M+EZMkTClVr8oWhUj1oboHMNo=
Date: Mon, 2 Jan 2023 12:43:57 -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
Content-Language: en-US
To: freebsd-current@freebsd.org
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: "Russell L. Carter" 
Subject: AMD Ryzen 5 5600G graphics acceleration fails now on -current
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Migadu-Flow: FLOW_OUT
X-Spamd-Result: default: False [-3.49 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.99)[-0.989];
	R_DKIM_ALLOW(-0.20)[pinyon.org:s=key1];
	R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:1004:224b::/64];
	MIME_GOOD(-0.10)[text/plain];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_ZERO(0.00)[0];
	DKIM_TRACE(0.00)[pinyon.org:+];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[pinyon.org];
	FROM_HAS_DN(0.00)[];
	ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4Nm3Bw1klPz3Q5N
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Greetings,

I have been happily using an AMD 5600G box for about 9 months
on -current with zero hiccups.

After performing my quarterly git pull + buildworld + installworld
+ pkg update + pkg upgrade, no packages that require graphics
work.  This is broad based, from kitty to mpv, thunderbird, and
firefox.  Oddly chromium still "works".  I see nothing in
/usr/src/UPDATING or /usr/ports/UPDATING.  I spent the past
4 months moving across the country so maybe I missed something?

Thanks for any tips.

All the best,
Russell

From nobody Tue Jan  3 08:20:16 2023
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 4NmQdy4595z2p6FQ
	for ; Tue,  3 Jan 2023 08:20:22 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20])
	(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 4NmQdw6nw3z43dZ
	for ; Tue,  3 Jan 2023 08:20:20 +0000 (UTC)
	(envelope-from Weike.Chen@Dell.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=dell.com header.s=smtpout1 header.b=BXEPYMu8;
	spf=pass (mx1.freebsd.org: domain of Weike.Chen@Dell.com designates 148.163.137.20 as permitted sender) smtp.mailfrom=Weike.Chen@Dell.com;
	dmarc=pass (policy=reject) header.from=dell.com;
	arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}")
Received: from pps.filterd (m0170398.ppops.net [127.0.0.1])
	by mx0b-00154904.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30305njC001323;
	Tue, 3 Jan 2023 03:20:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject :
 date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=smtpout1;
 bh=LuPeFXMLuhY0Gw7fl6jDtAHy8WZ+fIgmRXtkOD6BZCM=;
 b=BXEPYMu8I1B8bnyF3rI0chNawO2pQlCWyTKYxbxk8pFDtTT6KTmt+chnuyRJzNc06/Rv
 3KkvDz56R9rqJqE8MCdKQAPLckb+TdkMk2rgEDiD8Brk3VBNQjsBix11oODTLN9iPq2d
 78AblrmmEc2h4sN+Wfd/BJBS+KhJpGxRd4YTRg/4dUMz4BLGjUdfao8wbpt+02Ocx2Nc
 V8EDozX9vNg2HMyfob4p/rJPRCOLiOcFVP4a2uHiHnTCb1a7TxI7KZ/yxG6ZlDZXXWR3
 WyHTndwNLTX/B8CeN4XEXfQhl/CkE2AF9XK5bds37bdxItQKz87EwBZdkN6f6vFkorSQ pA== 
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37])
	by mx0b-00154904.pphosted.com (PPS) with ESMTPS id 3mth6fbw76-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
	Tue, 03 Jan 2023 03:20:18 -0500
Received: from pps.filterd (m0134318.ppops.net [127.0.0.1])
	by mx0a-00154901.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3037r4gR018351;
	Tue, 3 Jan 2023 03:20:18 -0500
Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2171.outbound.protection.outlook.com [104.47.55.171])
	by mx0a-00154901.pphosted.com (PPS) with ESMTPS id 3mu36x2v2v-1
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
	Tue, 03 Jan 2023 03:20:18 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=GvdJ/yvGZ66PPG8VP5mj7Fufvn8JlQw2LYBSGfI5xxIjWlH2lUSfBzYoxrCWJvVDClC51Y722noOAC8W/JhOYeN28yREJC6fksslcbOgvjTmmo571hyHst3ZqASofSntI1BFC+WCKO7eoYO2l9xNNGiv/OanhWoPW/y1YwDF8LilDZqkUjUdG21EPVmkmTVvepkA+Y7jrYK+xy79/dUmIDTaFEfosQvm5F3YkiNuRLJZhou758elASTwsPQaATXmNrHhcUskYGguj0J1sUqG7Pw2cjvWoBpQCSiXxKWpO0j7yL+EyY4drkESLrg05xl/qrFDfcDSeu3XYbeJYRV7ig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=LuPeFXMLuhY0Gw7fl6jDtAHy8WZ+fIgmRXtkOD6BZCM=;
 b=P+u1cinz32//oHiimyLCqD0IX9G6KyBY1JRgMMGaN70aVhs7qKEoRfopZN+TQ914PYDSN8x/fm9VmzsZDmWjNWKmsPRi302+JiFu/o3w9+nUmVXDqQa6MLVr8Tn1aE2YCe6l78r+NBPGmvylBUU2LoI4vSM56nBw2UmNfo+P+8jIon/PpK1rxroTX1HiN9MEnR+mYioVqWKt9NBIpmIFJDJohAcIEn9nv0wA5y8AaQ0/1GFbEvwWeJgcVY7CNeGHpetOAjfoVsHjZqcZEqR/vOTGJX65JRdrkdrRbpYJJiV/QoOw6ClUIGRkpLec4F2TtNvfqBLnDs/slK3wMqpOZw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com;
 dkim=pass header.d=dell.com; arc=none
Received: from PH0PR19MB4938.namprd19.prod.outlook.com (2603:10b6:510:94::9)
 by PH7PR19MB7170.namprd19.prod.outlook.com (2603:10b6:510:20d::9) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5944.19; Tue, 3 Jan
 2023 08:20:16 +0000
Received: from PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::23b9:ea81:a0a1:365d]) by PH0PR19MB4938.namprd19.prod.outlook.com
 ([fe80::23b9:ea81:a0a1:365d%6]) with mapi id 15.20.5944.019; Tue, 3 Jan 2023
 08:20:16 +0000
From: "Chen, Alvin W" 
To: Amar Takhar ,
        "freebsd-current@freebsd.org"
	,
        Konstantin Belousov 
Subject: RE: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Thread-Topic: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Thread-Index: AdjptCu1BUq3xWQjS9a169SAwDUljwAYvyqAA3ddajAAANodAAYATCiAA9ReixA=
Date: Tue, 3 Jan 2023 08:20:16 +0000
Message-ID: 
 
References: 
 
 
 
  <20221214201823.GA843@darkbeer.org>
In-Reply-To: <20221214201823.GA843@darkbeer.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Enabled=true;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SetDate=2023-01-03T08:20:12Z;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Method=Standard;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_Name=No Protection (Label
 Only) - Internal Use;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ActionId=b12043df-2720-4392-a137-4090798fb615;
 MSIP_Label_73dd1fcc-24d7-4f55-9dc2-c1518f171327_ContentBits=2
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR19MB4938:EE_|PH7PR19MB7170:EE_
x-ms-office365-filtering-correlation-id: 96149ded-1c54-4aec-80dd-08daed635829
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 
 6j3d6F+SyGsiVDibQJHQNCOGX1CxUqgD+FQIaBLwLIvFwUvaBsmzdtrr6tcQXXtL+qnibtfpmQEdKcEwodWkW5rk/UdXXwrla9VwGa6kjwhzSCGrHk1Q3sQhCMHN0p2OzEIg/A1WRz7hLonuqLepVueFlB/jAgmKdgnns8QRr/Uch5FT8h6AvKuAl3UE/Updp3NH16qL+WtWLJpv1IlvdeBBmQAO+LIcjco1T3VUuPi0/jEdc0IPWik56Pt/lqKG55OOfI/3I1wlP8GXMrddJlj3SdavZiwkpDFaYjYB02G+/ZiEgUCKBBgQPZ0a/GLUUE7bTMTSXokz07z8zOgAwy7gCs2Jee775WibjVi9kNLpYCcFhIwEABTEpvr2t/PW1iw3I2pFN9KDI2mKPAPjHHJhxVCw6iIg844Xvhag7fLvX13FpfQHwibbhGdKkmmSTSXTUZruL1WVeIp3J2F/IUemD8W3AcS/IL07SdQv39x/fYgqHz47ede4wb+hWs9iAe/KhuVo3oXCGJ73oEHfidCvDSSitJYE7znv4rcSHEPAPmtGjRrJGzcH2c9Y+yiorFvGDVBqXvr7OXOQd660oJ8xMsMR1QsvE038GcugStYzX2fTGyxTWcrCZ5DtTzLic+AjfxbV3wr8TNqXVy5HQea76yQrqC/SffP77VDPkhczt4Elp82LM7ArF3KTKI1f/X5n0XKi2ecjI7WKe6TpgIljwK4wC1CDaUJBE9GSwtyhzV2eGhAxc7zdthwD2W3t
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR19MB4938.namprd19.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(376002)(136003)(346002)(366004)(396003)(39860400002)(451199015)(186003)(83380400001)(26005)(9686003)(86362001)(55016003)(33656002)(38070700005)(122000001)(38100700002)(82960400001)(786003)(110136005)(316002)(52536014)(4001150100001)(2906002)(8936002)(8676002)(41300700001)(5660300002)(66946007)(76116006)(66446008)(66476007)(66556008)(64756008)(478600001)(71200400001)(53546011)(6506007)(966005)(7696005)(22166006);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?0YBYSH+9Kg2kU7NAkLlpXQPE+6wO7EVYVavQ+xCso+daIXCgyO3lllXx7Rj9?=
 =?us-ascii?Q?PLwCd3pQT7EGwHT2sSo27oXQg1PKFGR+lvaNlwQxNTybKplpvLQyS6Ek1zA/?=
 =?us-ascii?Q?FJ0dBrZyzSH/2+eYh0n5Lq/kPYskWwKoD8ipY7/VGa/ILQe/k7plHRlca5ID?=
 =?us-ascii?Q?yMytneLOlRRlEPGzeGtmND74yVTw9iy/VMTLSfXBG7Ni7Qaiscn3tGLMYqzW?=
 =?us-ascii?Q?feCOH6bOPAz8gduw6f1IOjHWA0W+nCNMIkzrSnPhIgDd+AtAdSHJkXCeziXw?=
 =?us-ascii?Q?S4isz29j5AueisQWmaoZDv8mW89RYVp3pVQG7sTO/pG6WgBbgfacefwW8y3F?=
 =?us-ascii?Q?XZX1nX5bn8gES4q1nWykQqb9DIdfe6OM7XIG1Salltbznnd8kehiluJGpRVN?=
 =?us-ascii?Q?ihoyMIG90LVcxTG6sQv5CPDq2zE5z1ajIKEIcJgcBkvwC7cFvufUhuFmBdlK?=
 =?us-ascii?Q?r+0PjsoSAawOAwdMod6WtYY6BRp2bA16GV5swn4l/HkK+1+wGRBOZEL/jfHr?=
 =?us-ascii?Q?tqYGlaIJZtjGRQtOy9jhIHUE4yMWIT9uuCnJHbVXx3LmKWNbvi8vQruzofd2?=
 =?us-ascii?Q?YiY0h7CTkMvIccfVf5JP8ugmg69ES9gS7RZHAOxwnwuurXwRNFXMFuX9uU//?=
 =?us-ascii?Q?3XS3oBMS9NWQ48BH/FDWWAD2hHvbsKeUpQlZBTKCV8CzRI7gU7W2krN5wn2c?=
 =?us-ascii?Q?g6KBbaVfAW86uhUS0h8fx6lI1DBLJ0DJKc1hFiZT9HxA2D2CR49yM1ZxvAqz?=
 =?us-ascii?Q?dwdoTOOEZggDFAq1VdccE1X6pRmqcsb0Q8/WiQJaLmg3DIMrVKxmdCmsXJ1p?=
 =?us-ascii?Q?ZFxrw1SxLHRCaC2GEM2rSGDAKZBjx5mDnQidlL210F2XCXWgQrTgUegyYlTG?=
 =?us-ascii?Q?fho5iLjT/C/1QouPdWJ+P5W2Cirtvcc59aJop1xyD3ANoobc3rjYzopEbZXL?=
 =?us-ascii?Q?wgDIlfbnY4Zrz+edTE+RAiKcuVlmkxH4nRzpYDU8P1pHkRSNQss8iXbHyg0V?=
 =?us-ascii?Q?bJeddrgkQX8YCSnENaZzjNrVFMHXDR5DHrGoV/LtayANhjrExhQ+cm6CeikN?=
 =?us-ascii?Q?Rz97S834xJxZYCiPeX6y8h4FkbRZEMZPy0IQWlH+wQdGNlKRyL0kq6MNIDkp?=
 =?us-ascii?Q?AKfNMQC0vwZiL5CMJUg3H+vL54dl0hAa0R7atA0NEGYWE5UWYnIIY2XDqzz0?=
 =?us-ascii?Q?5MEo2S6auz14whH+xietiQYehTROAQ3mTS6ON8MmTnmaEnntN2lj5K1rh/Og?=
 =?us-ascii?Q?yEfRMGvYyJsHZ6ueqi3VWZibCnwCiF+g9gTAoYlMrzEF629AsWVBM3xFt1s6?=
 =?us-ascii?Q?QrIIWc1nUnu+NjcQkkeWQEbc42HFagRNP2g4oYvG9SKohe9CkfVFgDH4U8wR?=
 =?us-ascii?Q?Z8xXlnPfKDpxd94zXl+zDvoObXw86+qziMcSNrQdMNyF8lyRKS/QGxBXdYJF?=
 =?us-ascii?Q?SFBNqXIRRw8mEtThmEnS3lZbndrkU5yA6ozhCJ1M/gK9CAp8AjGNTVkfxwrS?=
 =?us-ascii?Q?PaaUs+GWzO+Q28eMtKjDjaO0/FeFTUC7ffaVl4ZUq1EzKQCe2c+37aU2LzLY?=
 =?us-ascii?Q?u2wlkgifN9jmHN0hnG+ufTB8WbP03OkzSB9qQrL2?=
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
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR19MB4938.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 96149ded-1c54-4aec-80dd-08daed635829
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2023 08:20:16.2381
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9XZCz/YMxULZ+afc/ZpJ6dgw0JgtvsOtbZrwnu0BDOLFFvqE6pNuBHpz2zTLmKvKDzuFpLGvewrx9ijfgtMWeg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR19MB7170
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2023-01-02_14,2022-12-30_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 clxscore=1011
 mlxscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501
 spamscore=0 mlxlogscore=771 phishscore=0 malwarescore=0 bulkscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2301030073
X-Proofpoint-GUID: HoF_p6_z2uIZbXrWS33pAU-iRVTNCkFD
X-Proofpoint-ORIG-GUID: HoF_p6_z2uIZbXrWS33pAU-iRVTNCkFD
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0
 suspectscore=0 bulkscore=0 mlxlogscore=874 phishscore=0 spamscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2301030073
X-Spamd-Result: default: False [-7.10 / 15.00];
	WHITELIST_SPF_DKIM(-3.00)[dell.com:d:+,Dell.com:s:+];
	ARC_REJECT(1.00)[signature check failed: fail, {[1] = sig:microsoft.com:reject}];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	DWL_DNSWL_LOW(-1.00)[dell.com:dkim];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.998];
	DMARC_POLICY_ALLOW(-0.50)[dell.com,reject];
	R_SPF_ALLOW(-0.20)[+ip4:148.163.137.20];
	R_DKIM_ALLOW(-0.20)[dell.com:s=smtpout1];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[67.231.157.37:received];
	TO_DN_EQ_ADDR_SOME(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[104.47.55.171:received];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	RWL_MAILSPIKE_POSSIBLE(0.00)[148.163.137.20:from];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCPT_COUNT_THREE(0.00)[3];
	RCVD_TLS_LAST(0.00)[];
	ASN(0.00)[asn:22843, ipnet:148.163.137.0/24, country:US];
	DKIM_TRACE(0.00)[dell.com:+];
	TO_DN_SOME(0.00)[];
	FROM_HAS_DN(0.00)[];
	FREEMAIL_TO(0.00)[darkbeer.org,freebsd.org,gmail.com];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_SEVEN(0.00)[7]
X-Rspamd-Queue-Id: 4NmQdw6nw3z43dZ
X-Spamd-Bar: -------
X-ThisMailContainsUnwantedMimeParts: N

>=20
> [EXTERNAL EMAIL]
>=20
> On 2022-11-14 09:09 +0200, Konstantin Belousov wrote:
> >
> > You might use this patch meantime
> > https://urldefense.com/v3/__https://kib.kiev.ua/git/gitweb.cgi?p=3Ddevi=
a
> >
> nt3.git;a=3Dcommit;h=3D5d72240a8777b26d5e0a7d2d26bb919d05f60002__;!!Lp
> KI!j
> >
> pyHChyB8NZAQq5isiNFepD61cX0HczrFCeOriYbSwyfMPGW7k8I_BYxPWXv1FG
> yfl1Y-Ip
> > dgcNkyg$ [kib[.]kiev[.]ua]
>=20
> Thank you for this patch.  On my 13.1 machine it fixed all the panics wit=
h a i9-
> 12900KF.  It's nice to be able to use all the cores since I got this mach=
ine in
> May.  I had them disabled in BIOS.
>=20
> Also as a side note this fixed the audio issues I was having with the e c=
ores
> both enabled and disabled.
>=20

This patch can't work well with some older CPUs, and I find one N6005 (Inte=
l JSP).
This JSP cpu is not a hybrid cpu architecture, but the high cpu id is 0x1b =
with 0x20000000 which meet the small core condition in the patch, but kerne=
l got crashed on this cpu.
We need a better condition to pick up the E cores to make sure the kernel c=
an be compatible with all older Non-Hybrid CPUs.

Internal Use - Confidential

From nobody Tue Jan  3 10:17:34 2023
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 4NmTFk4r4Qz2pNKw
	for ; Tue,  3 Jan 2023 10:18:02 +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 4NmTFk1h5Vz4JJL
	for ; Tue,  3 Jan 2023 10:18:02 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 303AHYVu055757
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Tue, 3 Jan 2023 12:17:37 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 303AHYVu055757
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 303AHY8r055756;
	Tue, 3 Jan 2023 12:17:34 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Tue, 3 Jan 2023 12:17:34 +0200
From: Konstantin Belousov 
To: "Chen, Alvin W" 
Cc: Amar Takhar ,
        "freebsd-current@freebsd.org" 
Subject: Re: Status of Intel Hybrid CPU support (Alder Lake/Raptor Lake)
 support
Message-ID: 
References: 
 
 
 
 <20221214201823.GA843@darkbeer.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=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home
X-Rspamd-Queue-Id: 4NmTFk1h5Vz4JJL
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Jan 03, 2023 at 08:20:16AM +0000, Chen, Alvin W wrote:
> > 
> > [EXTERNAL EMAIL]
> > 
> > On 2022-11-14 09:09 +0200, Konstantin Belousov wrote:
> > >
> > > You might use this patch meantime
> > > https://urldefense.com/v3/__https://kib.kiev.ua/git/gitweb.cgi?p=devia
> > >
> > nt3.git;a=commit;h=5d72240a8777b26d5e0a7d2d26bb919d05f60002__;!!Lp
> > KI!j
> > >
> > pyHChyB8NZAQq5isiNFepD61cX0HczrFCeOriYbSwyfMPGW7k8I_BYxPWXv1FG
> > yfl1Y-Ip
> > > dgcNkyg$ [kib[.]kiev[.]ua]
> > 
> > Thank you for this patch.  On my 13.1 machine it fixed all the panics with a i9-
> > 12900KF.  It's nice to be able to use all the cores since I got this machine in
> > May.  I had them disabled in BIOS.
> > 
> > Also as a side note this fixed the audio issues I was having with the e cores
> > both enabled and disabled.
> > 
> 
> This patch can't work well with some older CPUs, and I find one N6005 (Intel JSP).
> This JSP cpu is not a hybrid cpu architecture, but the high cpu id is 0x1b with 0x20000000 which meet the small core condition in the patch, but kernel got crashed on this cpu.
> We need a better condition to pick up the E cores to make sure the kernel can be compatible with all older Non-Hybrid CPUs.

How does the kernel panic?  Could you show the verbose dmesg lines with
CPUID information?

If this is JasperLake, I suspect that the patch below should be enough.

Still, the workaround is not confirmed/explained by you (Intel).  I have
a high hope that we would eventually be able to use INVLPG with PCID on
(newer) small cores, might be even on older small cores after a microcode
update.

commit c8812792202d73804cccd624f6478c4069b22438
Author: Konstantin Belousov 
Date:   Tue Jan 3 12:13:07 2023 +0200

    amd64: be more precise when enabling the AlderLake workaround
    
    Reported by:    "Chen, Alvin W" 
    Sponsored by:   The FreeBSD Foundation
    MFC after:      1 week

diff --git a/sys/amd64/amd64/initcpu.c b/sys/amd64/amd64/initcpu.c
index 08385d3095d0..cddf8502437e 100644
--- a/sys/amd64/amd64/initcpu.c
+++ b/sys/amd64/amd64/initcpu.c
@@ -247,6 +247,26 @@ cpu_auxmsr(void)
 	return (PCPU_GET(cpuid));
 }
 
+void
+cpu_init_small_core(void)
+{
+	u_int r[4];
+
+	if (cpu_high < 0x1a)
+		return;
+
+	cpuid_count(0x1a, 0, r);
+	if ((r[0] & CPUID_HYBRID_CORE_MASK) != CPUID_HYBRID_SMALL_CORE)
+		return;
+
+	PCPU_SET(small_core, 1);
+	if (pmap_pcid_enabled && invpcid_works &&
+	    pmap_pcid_invlpg_workaround_uena) {
+		PCPU_SET(pcid_invlpg_workaround, 1);
+		pmap_pcid_invlpg_workaround = 1;
+	}
+}
+
 /*
  * Initialize CPU control registers
  */
@@ -255,7 +275,6 @@ initializecpu(void)
 {
 	uint64_t msr;
 	uint32_t cr4;
-	u_int r[4];
 
 	cr4 = rcr4();
 	if ((cpu_feature & CPUID_XMM) && (cpu_feature & CPUID_FXSR)) {
@@ -319,18 +338,8 @@ initializecpu(void)
 	    (cpu_stdext_feature2 & CPUID_STDEXT2_RDPID) != 0)
 		wrmsr(MSR_TSC_AUX, cpu_auxmsr());
 
-	if (cpu_high >= 0x1a) {
-		cpuid_count(0x1a, 0, r);
-		if ((r[0] & CPUID_HYBRID_CORE_MASK) ==
-		    CPUID_HYBRID_SMALL_CORE) {
-			PCPU_SET(small_core, 1);
-			if (pmap_pcid_enabled &&
-			    pmap_pcid_invlpg_workaround_uena) {
-				PCPU_SET(pcid_invlpg_workaround, 1);
-				pmap_pcid_invlpg_workaround = 1;
-			}
-		}
-	}
+	if (!IS_BSP())
+		cpu_init_small_core();
 }
 
 void
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 05342b31d2aa..c601ce868978 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -1341,6 +1341,12 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
 		pmap_pcid_enabled = 0;
 	}
 
+	/*
+	 * Now we can do small core initialization, after the PCID
+	 * CPU features and user knobs are evaluated.
+	 */
+	cpu_init_small_core();
+
 	link_elf_ireloc(kmdp);
 
 	/*
diff --git a/sys/amd64/include/md_var.h b/sys/amd64/include/md_var.h
index f014c66c0d06..f5cbdb6bbd9d 100644
--- a/sys/amd64/include/md_var.h
+++ b/sys/amd64/include/md_var.h
@@ -72,6 +72,7 @@ void	amd64_bsp_ist_init(struct pcpu *pc);
 void	amd64_syscall(struct thread *td, int traced);
 void	amd64_syscall_ret_flush_l1d(int error);
 void	amd64_syscall_ret_flush_l1d_recalc(void);
+void	cpu_init_small_core(void);
 void	doreti_iret(void) __asm(__STRING(doreti_iret));
 void	doreti_iret_fault(void) __asm(__STRING(doreti_iret_fault));
 void	flush_l1d_sw_abi(void);

From nobody Tue Jan  3 10:38:55 2023
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 4NmTjx0306z2pR4w
	for ; Tue,  3 Jan 2023 10:39:01 +0000 (UTC)
	(envelope-from paulf2718@gmail.com)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NmTjv43NKz4LxF
	for ; Tue,  3 Jan 2023 10:38:59 +0000 (UTC)
	(envelope-from paulf2718@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=gQE8689h;
	spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=paulf2718@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-wr1-x42e.google.com with SMTP id z16so12513959wrw.1
        for ; Tue, 03 Jan 2023 02:38:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to:subject
         :user-agent:mime-version:date:message-id:from:to:cc:subject:date
         :message-id:reply-to;
        bh=WmVlk0v9vFMkt4IZDk8GReXDsTvNxmkV2374+N7h5gc=;
        b=gQE8689hNEqy7Hylq1PdUkbZg9QhCif2CLNTuYwa/u1zfZLmFgPr5r7aS8earH4WEx
         veeHVc/9bUEL0mAWg+aKRWSxqbaXS5h+ObWPXWdd43z2CA7gs0/Dw8mqYQZqlhsHv6kB
         0fde9tkbBnuNMo3KveV2R8tFdq5S4S523Ks8tmVpX0zqjaQ1ewoPE/iCNnuW1d3XYWX8
         /b7oln7oyBI2hnUaCiXdYTZzYAxJoPdE4P2sXgC81h3CPFMz+yq9HibMkySrXQ0bGXeV
         oOmEdsNQWlkrbBeHQLdBb6aQ3mjUIpgFS8K5JmnCO+2EJ+fYJBxVexMz8QtWkn98JEV3
         W7cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to:subject
         :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
         :cc:subject:date:message-id:reply-to;
        bh=WmVlk0v9vFMkt4IZDk8GReXDsTvNxmkV2374+N7h5gc=;
        b=TXJ7/9F5+CwbfNFkSw/VPQdhNCoGOMfPJQKtBFxmD6AoVUX0OAohN5BZhPCJOGuJ+H
         /syOQh1dtfxq6xFLasxtjyvJJcrDC3K6ohRMUzfmmifPm1AioFb2Z2stUk19j7p4/LLM
         glLyaXw1hDpqI+9ghm+ujiGYnKtTQdfAUwZZbIiF8b6esQs+w8Eb0pOu6iOMSPontyss
         O9Qq+JFqlI9G7mLAtHbVDT+7Iw7bhakg641pBsTEwCCDJtgOeegOirBaQCODlOfXRxdJ
         O3Qg5thkQN+Y92cFYgzgqqG1UmEfqvkoqCCNTFYBb0NJQf4Edz85HZuswHJCTQUAk2nD
         pC0Q==
X-Gm-Message-State: AFqh2kp8MkqTxLzqnizMcGJV3aaAaf/33pvz+5sLw1CPihfGUFbdpQdK
	8YBorYwEJIq+pU2dKKv6n4/3haC/AZ1elqGm
X-Google-Smtp-Source: AMrXdXtU2sg8CLWhn5skiNihmmM11tnnNn6hKAzjVXCS6nnJ/UfrJFXexWEe+d2Dp4R5qUCYHALuZA==
X-Received: by 2002:a05:6000:181:b0:276:c52a:e3a0 with SMTP id p1-20020a056000018100b00276c52ae3a0mr19488424wrx.65.1672742338356;
        Tue, 03 Jan 2023 02:38:58 -0800 (PST)
Received: from [137.202.253.23] (nat-ies.mentorg.com. [192.94.31.2])
        by smtp.gmail.com with ESMTPSA id p18-20020adf9d92000000b002383fc96509sm30930146wre.47.2023.01.03.02.38.57
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 03 Jan 2023 02:38:57 -0800 (PST)
Message-ID: 
Date: Tue, 3 Jan 2023 11:38:55 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
To: freebsd-current@freebsd.org
References: 
 
 
 
From: "Floyd, Paul" 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-3.96 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.99)[-0.994];
	NEURAL_HAM_SHORT(-0.97)[-0.968];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4NmTjv43NKz4LxF
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N


On 30/12/2022 01:54, Konstantin Belousov wrote:
>
> The backtrace is needed to make a further analysis.


Any suggestions for getting a backtrace? I get the panic booting either 
the installer ISO or the VM image, both in VirtualBox.


A+

Paul


From nobody Tue Jan  3 17:45:41 2023
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 4NmgBM1Jkgz2pG3h
	for ; Tue,  3 Jan 2023 17:45:47 +0000 (UTC)
	(envelope-from i@vboldin.ru)
Received: from forward400b.mail.yandex.net (forward400b.mail.yandex.net [178.154.239.159])
	(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 4NmgBK6v7gz40Gp
	for ; Tue,  3 Jan 2023 17:45:45 +0000 (UTC)
	(envelope-from i@vboldin.ru)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=vboldin.ru header.s=mail header.b=awdVsWYH;
	spf=pass (mx1.freebsd.org: domain of i@vboldin.ru designates 178.154.239.159 as permitted sender) smtp.mailfrom=i@vboldin.ru;
	dmarc=none
Received: from sas1-a5965286a9e9.qloud-c.yandex.net (sas1-a5965286a9e9.qloud-c.yandex.net [IPv6:2a02:6b8:c14:3a15:0:640:a596:5286])
	by forward400b.mail.yandex.net (Yandex) with ESMTP id B78BE5FFD9
	for ; Tue,  3 Jan 2023 20:45:43 +0300 (MSK)
Received: by sas1-a5965286a9e9.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id gjafiR4caKo1-1gH27C21;
	Tue, 03 Jan 2023 20:45:42 +0300
X-Yandex-Fwd: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vboldin.ru; s=mail; t=1672767943;
	bh=do2RmBl1sCseVoNno4Eo48JSnhtyBNls6vw5NhWvSwY=;
	h=Subject:To:Message-ID:Date:From;
	b=awdVsWYHGMMdeSB8S8U7jt15IrjCdKbtrsQ1Bhf5/dS/V0Ssz1WqiKK/AIF8i1vVZ
	 pQfPvhpTtB4GjD8q7rZSME9BEbeMjwDZQSEJfykd6qklxyPJLdjNpiL5KukkbMoU5T
	 xDEP1rOqYpizSAiE+vh5orVrovu0dGLdRM/dBVEY=
Content-Type: multipart/alternative;
 boundary="------------0DUuGSE5YETQjWfplI0PTT4r"
Message-ID: <99fb8ae0-c8d5-1cbb-5edf-28907120da3e@vboldin.ru>
Date: Tue, 3 Jan 2023 20:45:41 +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/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Content-Language: en-US
To: freebsd-current@FreeBSD.org
From: Vladimir Boldin 
Subject: pkg: No packages available to install matching
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	R_SPF_ALLOW(-0.20)[+ip4:178.154.239.144/28];
	R_DKIM_ALLOW(-0.20)[vboldin.ru:s=mail];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org];
	DKIM_TRACE(0.00)[vboldin.ru:+];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DMARC_NA(0.00)[vboldin.ru];
	RCPT_COUNT_ONE(0.00)[1];
	ASN(0.00)[asn:200350, ipnet:178.154.224.0/19, country:RU];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Queue-Id: 4NmgBK6v7gz40Gp
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------0DUuGSE5YETQjWfplI0PTT4r
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello!

Can't findnet-im/telegram-desktop with|pkg search command.|

|root@beast:/home/user # pkg search telegram|

|libqtelegram-ae-6.1_5 Fork of libqtelegram by Aseman Team
p5-WWW-Telegram-BotAPI-0.10_1  Perl implementation of the Telegram Bot API
py39-python-telegram-bot-13.1_1 Not just a Python wrapper around the 
Telegram Bot API
telegram-cli-20200106_1        Command-line interface for Telegram
telegram-purple-1.4.7          Libpurple plugin for Telegram messenger
telegramqml-0.9.2_4            Telegram API tools for QtQML and Qml|

|root@beast:/home/user # pkg install net-im/telegram-desktop|

|Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'net-im/telegram-desktop' 
have been found in the repositories|

|root@beast:/home/user # pkg install telegram-desktop|

|Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'telegram-desktop' have 
been found in the repositories|

|root@beast:/home/user # uname -a|

|FreeBSD beast 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n259905-231d75568f16: Sun Jan  1 09:51:55 UTC 2023 
root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64|

Tried after|pkg update -f|, same result.

--------------0DUuGSE5YETQjWfplI0PTT4r
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
Hello!

    
Can't find net-im/telegram-desktop
        with pkg search command.

    
root@beast:/home/user # pkg
          search telegram

    
libqtelegram-ae-6.1_5         
          Fork of libqtelegram by Aseman Team

          p5-WWW-Telegram-BotAPI-0.10_1  Perl implementation of the
          Telegram Bot API

          py39-python-telegram-bot-13.1_1 Not just a Python wrapper
          around the Telegram Bot API

          telegram-cli-20200106_1        Command-line interface for
          Telegram

          telegram-purple-1.4.7          Libpurple plugin for Telegram
          messenger

          telegramqml-0.9.2_4            Telegram API tools for QtQML
          and Qml

    
root@beast:/home/user # pkg
          install net-im/telegram-desktop

    
Updating FreeBSD repository
          catalogue...

          FreeBSD repository is up to date.

          All repositories are up to date.

          pkg: No packages available to install matching
          'net-im/telegram-desktop' have been found in the repositories

    
root@beast:/home/user # pkg
          install telegram-desktop

    
Updating FreeBSD repository
          catalogue...

          FreeBSD repository is up to date.

          All repositories are up to date.

          pkg: No packages available to install matching
          'telegram-desktop' have been found in the repositories

    
root@beast:/home/user # uname -a

    
FreeBSD beast 14.0-CURRENT
          FreeBSD 14.0-CURRENT #0 main-n259905-231d75568f16: Sun Jan  1
          09:51:55 UTC 2023     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
          amd64

    

      

        
Tried
          after pkg update -f, same result.

        

      

    

    

  


--------------0DUuGSE5YETQjWfplI0PTT4r--

From nobody Tue Jan  3 21:39:31 2023
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 4NmmN869WTz2ns9n
	for ; Tue,  3 Jan 2023 21:39:36 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2013.outbound.protection.outlook.com [40.92.97.13])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NmmN740nkz4NQy
	for ; Tue,  3 Jan 2023 21:39:35 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=hotmail.com header.s=selector1 header.b=aMvFhMBt;
	spf=pass (mx1.freebsd.org: domain of tezeka@hotmail.com designates 40.92.97.13 as permitted sender) smtp.mailfrom=tezeka@hotmail.com;
	dmarc=pass (policy=none) header.from=hotmail.com;
	arc=pass ("microsoft.com:s=arcselector9901:i=1")
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ZKlOq+856XwPfOi552EQFfnebwY1iJCjH6hOzXkDHhphwLAgUHYTHaBQYNvGRu6MJeyUBP6yzqMPTQsD9uGTPd2NIwAvY7kzzLqL1pGzBmPCxA3mYgePqTqUQzwg+Me4o7QIdQEY3djJPmpf2GQHAUyZZGSOFDW4ISFnot/mFsVybb08cmH25us1JcfYQD3xDONwxZ5U2tuW8GaDB1lyV4HJa2zhrkNUajQn2Sln6cj0VERA20mZ36CD/iVjjLz3h+h8qLjHlLCKaZr16DrXaMaTuOpgH1l3OmKYxXHDUbJWoT2TYaw95Y9tRwALOz5J+V38v5Cy6xsLMa7i5ZPpPg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=T3P9QUVxpXm8n3Bcktn6EvKDKl8W05xh/VPEI4yqdsg=;
 b=Oa5SXLZGzWTOn57Hubm/rXSEGfpEcopRgvLksX84PNdy/SkWOXda43P9YNoW6McehMfcFC8TQ75SM5S4+TZMdpgRPfv4OMp6zt4UrMsbfaKjxDvxZjZ1so0FY+19HKDA+ptMMQsGzKJWh4YqyGLngzh3oIWwcfSHKxuVnqWhA2yIJSsMeoSCuJACZBKjj0dsbzWpnhlUoYogTBygX6geL/HobXB4AepHAJ75jV4Ms0QzmOGDvesk5fzgS9Ncp4BJc5bShYWEAfUzYtpMjMU3CuqEHKwzz5UbZkkzbla/Mrf83V4T/v/saVgbBok6zhIZPFDdDzy+qXhLnuMVZGAI3A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=T3P9QUVxpXm8n3Bcktn6EvKDKl8W05xh/VPEI4yqdsg=;
 b=aMvFhMBtEsj72zduV9RXPcM8AoCJSpVnHntNyH5QweR817pBxQg4SRl86ayppFh+k01+HlKC7jsTT5O/2JlQf5yi+QtTgQEhbwDpYEmCXRBpUuzirLZpmPPRnuAS8vy8tbpojH40YSGaFkl/4qN9Pf2iQ/MBfE+9GBnumV/ObIgEXfNgs07OtlLY8qJC54L7hnN1HWp/Zb++Kj5f2za3NXoogqO90N3i2espGv8tPqC2WDVoqxV3p1kzfy/fiF37Ex7xa78OP+ibWDHWddAC0aer8fFZPRnSTI4csNdPEbjVS3uhS6Cq7/Ph1NiKC8uRXrhUzBQqXN4OGnloDspA/w==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by ROAP284MB2347.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:d8::6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5944.19; Tue, 3 Jan 2023 21:39:32 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::42aa:25c0:1211:33a8]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::42aa:25c0:1211:33a8%9]) with mapi id 15.20.5944.019; Tue, 3 Jan 2023
 21:39:32 +0000
From: Ivan Quitschal 
To: "freebsd-current@freebsd.org" 
Subject: cant login after make installworld: pam_opie.so.6 not found
Thread-Topic: cant login after make installworld: pam_opie.so.6 not found
Thread-Index: Adkfu/MgSfn+1G7AQtm+nH0V0Z/UIQ==
Date: Tue, 3 Jan 2023 21:39:31 +0000
Message-ID:
 
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tmn: [Z2Gzh9Y4AdFIoTpdGY09rtv94d6sTVhwm+rUvLT5docRrveT5eD+OrWp3pQxq2BP]
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CP6P284MB1900:EE_|ROAP284MB2347:EE_
x-ms-office365-filtering-correlation-id: c832011a-32f6-4b12-6e21-08daedd30001
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 lKnnfVif6A31gg4FQim9kz2DGkR2OH0MVCPfp83hBueJ4gxrQz1LBlBzWdjdIYUtzjaPSXSkGZIi5sg+MQ9GYFmGo+ZozCYu5jw3hPFNNpKHnBfvyz9PM+Fv76MliloaCc7vbwiGCINCkUnFs7GypXCyug7W8VwACR0nI9cXG0iK84pOK3oLK+4o9XgnTeLxAi5UzXr7WSZwO+kiqvXWtw/wHIcvDIm4kWnVCoJ34Lxf+pucht0JKFJukUoVX9FAqeAFessdwWKzmdOEWDpfScuDTtDUBgnYcMCK/iM+sATdsXR1nDOnh329KEt+iimgwwTaD7msd/Bhos6LkH/IGPGNPVxxXShLxt6gJhKKQ0cHtp9gxog3eDDHyiyALLpwxazDs7DfPAFo7UdW8EsdZpmwDqdlC5cKFz5PV3b3MKFSnQ1jPuZQDfRtPBDjHx2uctzWRSqSHu8B4TYNWTs0i5mJCfzoEpaOO2SDjetObD4kxPFjfskfeWiCp+FQ02Yt+hdKv0Qn3JwSN3OvohhG75dSfEY0XwTusS4SlU1HqdG1bjcGeXeq1dCrylUfGL2c1sshY8z0Z9tl2fKzjc2k3lqbiqMTyZtff0krRLkzn0w=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?E3WEQIxwJbZ4/fCCkpFM4IFWm0bHff6ulual9UsicJFaXRcO7gl5JQJABgM7?=
 =?us-ascii?Q?fjtpcpOgczxHAnLelfJOdqGd3upWxuwx+8x+s+w561u/d1BZj4yFqgnsb13x?=
 =?us-ascii?Q?z5EH//B7liSfvjO2RvoRlGKn8j564cTM8SOrDkWrLGTcsZgB29poWHgld4UV?=
 =?us-ascii?Q?fsOcWRQw+1cVEaPVM4uoq5SYMw8h46g70ZkLE0SiuIGeCR+1rnf9INMAM06I?=
 =?us-ascii?Q?sbzQhmszZia96aJJAgZ2Gv66uJD0xCu2XLQVwA9nABuUkuJ+KXgOuxLPfxxl?=
 =?us-ascii?Q?9jYKzI7Cp2OxeuE1J0gci208IYr7UcO6CMXZ/VLkBQbXZJO8lZDHTF9tGjNn?=
 =?us-ascii?Q?YLCbGLrSoKKKyVUe5DEc7LzLmayBCym8sgfxQrbfrO620kRw3pYrK/M7Y/SP?=
 =?us-ascii?Q?sozqzKESdr3cJs8YsdCxCeN6naMZGuHf0mEBd3mUnV+0d6nCedP9I0XpESJm?=
 =?us-ascii?Q?9VD5xm5nyuE8hqxJiTLX3NE07ar5PW+Sl5xFB/uOVCKoez9uAYuNUEB2nhwB?=
 =?us-ascii?Q?NKBMhwWyKpMhAzL0uReeXjrEuZjEng7l+GXS5pAOzJaI1pzKNhfXczRecUea?=
 =?us-ascii?Q?2raXE+8BmRI3z+u3JJi534LCR/esyKDLZm4v4UBYJIFjhtNr6l1mD4vPlMU0?=
 =?us-ascii?Q?B1MvfZOAKjXQf9qRp13T3wiTnqVPhoB+9YoQS2GXkg0j+3gWLpxH6J2ZlbYC?=
 =?us-ascii?Q?TY0nqP8JnDGh7sA+ZZFVx4zcXBnWBvzxR7PkOhpMb2hUTZPPIWFic0u6BLFX?=
 =?us-ascii?Q?KLltZIZrAV6W5F/VJ//svJ76ebLR9ngkxxsshClpMsuFCTGcCc+X3LQRybEx?=
 =?us-ascii?Q?ubXWL4M/UOFCZJJDrOejHKAK2+NDhPWvD306X7R4wPjPa7E889FGItmt1OyK?=
 =?us-ascii?Q?TZ+G2N531DBr6tecW8x53kOS1Z575dptB4C7qudyMQLy7hAXYNASRLLX3ZAD?=
 =?us-ascii?Q?P0Tw3yUVIxA+T9kSFkUldWu9cbdfluY+5yBNRZOI5R8vhfXS42wF8rDc4vtz?=
 =?us-ascii?Q?iV6JFDCcOSTx151URdonMJMax9Yh5qwxvUi8ctZxCZim7BCcJrG9iiS5cjcG?=
 =?us-ascii?Q?ldKfhuTIesJeoTKpO9jytsQTUEbc5mSvjMD/Z0eRmP+t7J0WvhuupXIMauKs?=
 =?us-ascii?Q?QKqessjQxEDWJoqfpdM3jSy/1TZCRnifVqC5pX3A5Uytu7TLw15nsFG6GnhZ?=
 =?us-ascii?Q?TZos7UfQxTIr57ea14jtspfCygfRWcvDA9xLbNZ40urZoxrzHD3GbyE2CkJn?=
 =?us-ascii?Q?R2jpc1hG80ApwXZbFDaqtD5iXJIfJ3XVpFTqtsS5xN8jO9OBCNmScHPZWQGW?=
 =?us-ascii?Q?6Zi7IAxWzgFgDMhKsZeIS0sP?=
Content-Type: multipart/alternative;
	boundary="_000_CP6P284MB19005029976B118AB19D106DCBF49CP6P284MB1900BRAP_"
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-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: c832011a-32f6-4b12-6e21-08daedd30001
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2023 21:39:31.9697
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB2347
X-Spamd-Result: default: False [-4.62 / 15.00];
	ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-0.98)[-0.983];
	NEURAL_HAM_SHORT(-0.63)[-0.633];
	DMARC_POLICY_ALLOW(-0.50)[hotmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15];
	R_DKIM_ALLOW(-0.20)[hotmail.com:s=selector1];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US];
	TO_DN_EQ_ADDR_ALL(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[hotmail.com];
	DKIM_TRACE(0.00)[hotmail.com:+];
	RCVD_TLS_LAST(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[40.92.97.13:from];
	FREEMAIL_FROM(0.00)[hotmail.com];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[hotmail.com:dkim]
X-Rspamd-Queue-Id: 4NmmN740nkz4NQy
X-Spamd-Bar: ----
X-ThisMailContainsUnwantedMimeParts: N

--_000_CP6P284MB19005029976B118AB19D106DCBF49CP6P284MB1900BRAP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All

I am having a problem here after doing a:
make installworld
and
make delete-old-libs

now I cant login (only thru single user)
looks like the "make delete-old-libs"  has deleted that lib pam_opie.so.6 a=
nd now I cannot pass the login prompt
says the error "pam_opie.so: not found

how can I get it back? I tried everything and nothing brought it back , not=
 even another make installworld
any insights?

Thanks

--tzk


--_000_CP6P284MB19005029976B118AB19D106DCBF49CP6P284MB1900BRAP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi All


 


I am having a problem here afte=
r doing a:



make installworld 


and 


make delete-old-libs=



 


now I cant login (only thru sin=
gle user)


looks like the “make dele=
te-old-libs”  has deleted that lib pam_opie.so.6 and now I canno=
t pass the login prompt


says the error “pam_opie.=
so: not found


 


how can I get it back? I tried =
everything and nothing brought it back , not even another make installworld=



any insights?=



 


Thanks 


 


--tzk


 






--_000_CP6P284MB19005029976B118AB19D106DCBF49CP6P284MB1900BRAP_--

From nobody Tue Jan  3 21:48:00 2023
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 4NmmYz5Q2Fz2nv81
	for ; Tue,  3 Jan 2023 21:48:07 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NmmYz224Kz4Q9g
	for ; Tue,  3 Jan 2023 21:48:07 +0000 (UTC)
	(envelope-from david@catwhisker.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: from albert.catwhisker.org (localhost [127.0.0.1])
	by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 303Lm0HC037245;
	Tue, 3 Jan 2023 21:48:00 GMT
	(envelope-from david@albert.catwhisker.org)
Received: (from david@localhost)
	by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 303Lm0WH037244;
	Tue, 3 Jan 2023 13:48:00 -0800 (PST)
	(envelope-from david)
Date: Tue, 3 Jan 2023 13:48:00 -0800
From: David Wolfskill 
To: Ivan Quitschal 
Cc: "freebsd-current@freebsd.org" 
Subject: Re: cant login after make installworld: pam_opie.so.6 not found
Message-ID: 
Mail-Followup-To: David Wolfskill ,
	Ivan Quitschal ,
	"freebsd-current@freebsd.org" 
References: 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="c2NXQifye2fqGMCg"
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4NmmYz224Kz4Q9g
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N


--c2NXQifye2fqGMCg
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 03, 2023 at 09:39:31PM +0000, Ivan Quitschal wrote:
> ...
> I am having a problem here after doing a:
> make installworld
> and
> make delete-old-libs
>=20
> now I cant login (only thru single user)
> looks like the "make delete-old-libs"  has deleted that lib pam_opie.so.6=
 and now I cannot pass the login prompt
> says the error "pam_opie.so: not found
>=20
> how can I get it back? I tried everything and nothing brought it back , n=
ot even another make installworld
> any insights?
> ....

I believe that the issue is a result of:

| commit 0aa2700123e22c2b0a977375e087dc2759b8e980
| Author: Dag-Erling Sm=F8rgrav 
| Date:   Sun Oct 2 03:37:29 2022 +0200
|=20
|     Put OPIE to rest.
|=20
|     Differential Revision: https://reviews.freebsd.org/D36592

(in src/lib/libpam/modules).

OPIE is (thus) no longer part of FreeBSD current.  I expect it would
be best if you arranged things so you no longer depend on it.

Peace,
david
--=20
David H. Wolfskill                              david@catwhisker.org
Putin seems to use the word "peace" in the way that Neville Chamberlain did.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

--c2NXQifye2fqGMCg
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCY7SikF8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE
MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix
1L7UAP4kW5cIWlwwuLpdpb14tu6UlUbnV+dRJ6Ka3P0Qd27/PAD/bhPhUbaHVzuA
fAPFx/MadTzROucvHO9vwX68NOfWfwE=
=e924
-----END PGP SIGNATURE-----

--c2NXQifye2fqGMCg--

From nobody Tue Jan  3 21:55:00 2023
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 4Nmmk23RZzz2nw2G
	for ; Tue,  3 Jan 2023 21:55:06 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2066.outbound.protection.outlook.com [40.92.96.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nmmk16Jy1z3CYr
	for ; Tue,  3 Jan 2023 21:55:05 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Authentication-Results: mx1.freebsd.org;
	none
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=JRhnP9lPbqPs2jzrUlpWUdLkEXdhfIaj+uLFOVl97w7lq3U5dTVpjcEbMWc7421JRQWVUCeO0QRHdndnGFDlxz9Yl/tgD5XzgYGuJdeiP1yU1W/HQRYKNnAM4z94S3j/Xmv68SV2Ah2c+DgguXgcchlZe/pQ4/ak45s5X0RMARIm0EtSkgPTnYCsNnTxrDS772uDwcPgDaW9FJQIH+bl0JalZp+iVbPDZtbxAf9gbe7wLWFplX8dxp/EjGTTP67hOMBebf7dXopOt5m1XpMYsL1URHFmWJ+vPEX6jcGuYzjxhbhgc7MFGX18I4a1wu7pgsuOv+hQHJmDeXl10JmhEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=Xku2oTLJOjuT0VZMn+WKeVJ0LIGF2Xu/nFRoDZCLNkA=;
 b=oaH90GZ/Er8dSgenIv8nDedfL+ONKsqTwh0yNKP5AURnPYqt/8kK4pSz5QrZ+5wkWsq5Nqzg7koldJms6XpSbw4A1sTINs7pElZM2e3iRaZ9Ds3y6D8Yw2NTpDebtx2mxmwcDlUNDo0LAfEaxhxM8XbBeU+7I1P1dYA13b/Kab9Pvy5UyhII1GQEgmrC/sZkDoTwzGYaAPyfXP4d401tauAJw+q6O+W6bnfmejKSjMT63ViANpycLQTW2qSkqlCDgOBYb1w/TWYJupoD4ArQL2Z39Moj/5yNXX89WZHTTaI0cOmAPjCwln2vof15PmmQUXCG19bOj0q1IQGMmRO3TQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=Xku2oTLJOjuT0VZMn+WKeVJ0LIGF2Xu/nFRoDZCLNkA=;
 b=NFzCprizuhhZ2l7KRYXQFBuOY2OBq9ce+BMPzNXKm01VBYRknmnZYL5Dmsk3Zo5vUGnSPsp2xYzKj6RydqKuSJn7s4DFpPMPoTQTg1/0XirSVgxQfJ4Myx4GNk1z54ZogRs5oKj51AtIPnPqaiSS22GBEzgpTu387qaMV/8dhnzQHSuNDCLbU5ztr3g6L5wfTciak/ztPCNWex0ImnaNs8FAjadWfLiHdtiZOAeIyMiNuTI7hrD6yLbHRKtkQUMHQTQGBWzE2brt5WXtrIjqZK9avQ0hsN8Uac88bsUZXnJtw5m9ZJpuF2wwsq9L0HaBo1RK9j43zrs6P+dVaLsXZg==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by FRBP284MB0044.BRAP284.PROD.OUTLOOK.COM (2603:10d6:203:33::7) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5944.19; Tue, 3 Jan
 2023 21:55:00 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::42aa:25c0:1211:33a8]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::42aa:25c0:1211:33a8%9]) with mapi id 15.20.5944.019; Tue, 3 Jan 2023
 21:55:00 +0000
From: Ivan Quitschal 
To: David Wolfskill 
CC: "freebsd-current@freebsd.org" 
Subject: Re: cant login after make installworld: pam_opie.so.6 not found
Thread-Topic: cant login after make installworld: pam_opie.so.6 not found
Thread-Index: Adkfu/MgSfn+1G7AQtm+nH0V0Z/UIQAARkwAAAAtroE=
Date: Tue, 3 Jan 2023 21:55:00 +0000
Message-ID:
 
References:
 
 
In-Reply-To: 
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [RCGiEcmtUkrOBRVi1EckHqspEyiKXzc+]
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CP6P284MB1900:EE_|FRBP284MB0044:EE_
x-ms-office365-filtering-correlation-id: 21be9528-277a-4770-fc9c-08daedd5299d
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 wR7/Ed0ZCYDVJvM/N+R8I0iRgw7cD30QrEIK5rZfhePi1kbq6QWT71JkH5kqmFn2osMmX05Bbfho9AAunpmac38LeE+FH7n+U0vnSny/1FDC5K+Plrvyo+tutyWUIMu1zvFJZ+BtBSfLIOFNazVeVAwVyHSWq84m271Hke/oRfz5EJ3xID+Tpv8xLB4ZmUCviuDIVvbIF6VVo2EB4qymBuuoBoQaJ/9vQmfYdCQ5wFSvxHU1g9oIgh6vnQ97bhl93RnV5/lrwHKsVYa6iyXAWSGWTGsU7lDzNPbMqGzbyeoddN2yHS57wkMuxGVbWSeu+ARaCnxnmo1yqBRDVhiqKGiKa/UkKDqAC9kau7wl1JyJ2Y9tuvl58THMnY8D6f3yqUU621M5WLSwSsXXyvBX3aNWdaNuZQXN5mjcyz4t0RBWRcYEnQRe28aw+4zPFhmb27anmhhPPcW7fhSoHBUTFvI9RY3UGwVJcKMue5052f/xDfLRqnTJ6cTOEq5LqVC3iobGPib+wW2aDiyhrCh7gTBAvNCwKFlh1zT5j3v2dHlxY8zaFUP+fd0tRJkFue/MYsQfNka58CUimYDqm8yt5130wEHVR4SkUaxgWMZVzjmss2nFbAxQ8jKotlKnzMzK+rYLrT4CXvHkKeTZNJO/NQ==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?QP2WwzlBv5oxMIO9CdfBI4RW2v018tdcJcMwElQ2sHGhABjYwdG/BfqnzZ?=
 =?iso-8859-1?Q?NcvdN9U/UxAjMCwW0zw88GPpbIhcwcVmCZ/QSHkhYzsMwOLG43R+CYOvab?=
 =?iso-8859-1?Q?1KviuKRz3fMXnoN/GbGIBa6OdcAEHcj8UUu1uC1yu/WSyKkrkQw+pZvPGw?=
 =?iso-8859-1?Q?vLB8ISD9UkzPP++oN+X2ydGfrTAA4jrPlJcfHiefmcasqFBFQytf+M7TFZ?=
 =?iso-8859-1?Q?x+K0WuBjcTw/rof/x9cWbll+ZvPEkQucdRfU+Imh5pAZmOTXO/JTBVjDzJ?=
 =?iso-8859-1?Q?O6JxWhWAoyZ0vxBkLD7Wen5klCUP7J93QQhDU/hCDTq6/8L0cRTcDJ/fGk?=
 =?iso-8859-1?Q?3gJRrdK2pdGRKby9Q0kB+2WIwsp4J4ugkmWDnFQsODe492lqj+ixzPBBys?=
 =?iso-8859-1?Q?e8EE36DX3XvyG+6u6XnQyppxvL1Tm53gAsSivZdHMFfXmGBJ6K8G9F8bIg?=
 =?iso-8859-1?Q?HMXkHAp9g0x26jM3p8t1i/qaX/jZFPErPqApV93TAIz708w94Zpprz3I3R?=
 =?iso-8859-1?Q?oWvS6WUWYXQcsARZazhBDy8rU6Z1QXPWnY2LuW/Gj2Ycb/NJgU2mEcfycP?=
 =?iso-8859-1?Q?OE1rEA7dQjgXX+ax/6Ubo38l7WInIsYDTQfJIBGfCo5O6IJTzuRYsHM6MW?=
 =?iso-8859-1?Q?Iy9vOMiGR9tdmjJ1UA4LBrGDpJOMhilYom3kxJxDDrvtT4v9UFdvahcL7T?=
 =?iso-8859-1?Q?W693twm+dgXVjqRrqPyht0kOWXyNAVhq5JWZUlH4F1UgewXr2+esTs73PI?=
 =?iso-8859-1?Q?zl/7W+Pv+5TuZPQJdGy1WwfmkT2qh6YQdLlpr00wVcNJCtY1uMk8TIIQzy?=
 =?iso-8859-1?Q?uVfaLTKqydmSl+h2f14j9ZAIRdn9+5SVwOUSWlo9NL8c3P3e7HL45/AXTK?=
 =?iso-8859-1?Q?AqELM5DWq5jW/aYsH/YsLZ+jWEda+xQ5oKVlEbnaEgwT5UUGxmfDN6TAYA?=
 =?iso-8859-1?Q?MHb7GLZmcXjV0xSTr4B8UcpJBXCIEPeWUHz7/mdcig25TKStOpHOBp6LtM?=
 =?iso-8859-1?Q?47mXOeyMDcXS23vxarqyuaq6JQJKDVByKlIwIwWB8340MG3bTngXMg1Lyp?=
 =?iso-8859-1?Q?oqhtQh85KoQdfH55qwD8uF15eApJCujLV2/4I++1o1h6G9oHQirLO5+wit?=
 =?iso-8859-1?Q?S/2o3HHSkjEbULs2Mq6+xbjj/n0xTPkPst2K2R03ZbkZmblImJ598ZtZEP?=
 =?iso-8859-1?Q?iRn7f2DE9xas+FLnCQm3ZseHRo3VZhxwvUCjwvMKdzQCh6svZzHtqrTf3I?=
 =?iso-8859-1?Q?LdieFEg84FmI21/mdT9bmt1z2gdBFmngmYZBOR/ZToViHxC9B4FkwwGU0U?=
 =?iso-8859-1?Q?1PWKm4rwzGBsmiY0gdLt/E6Agg=3D=3D?=
Content-Type: multipart/alternative;
	boundary="_000_CP6P284MB19006490A396B9B323AC1CF2CBF49CP6P284MB1900BRAP_"
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-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 21be9528-277a-4770-fc9c-08daedd5299d
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2023 21:55:00.7758
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRBP284MB0044
X-Rspamd-Queue-Id: 4Nmmk16Jy1z3CYr
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--_000_CP6P284MB19006490A396B9B323AC1CF2CBF49CP6P284MB1900BRAP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi david / all

And how can i fix my login not to use this opie anylonger?

Thanks
--tzk


________________________________
De: owner-freebsd-current@freebsd.org  e=
m nome de David Wolfskill 
Enviado: ter=E7a-feira, 3 de janeiro de 2023 18:48
Para: Ivan Quitschal 
Cc: freebsd-current@freebsd.org 
Assunto: Re: cant login after make installworld: pam_opie.so.6 not found

On Tue, Jan 03, 2023 at 09:39:31PM +0000, Ivan Quitschal wrote:
> ...
> I am having a problem here after doing a:
> make installworld
> and
> make delete-old-libs
>
> now I cant login (only thru single user)
> looks like the "make delete-old-libs" has deleted that lib pam_opie.so.6 =
and now I cannot pass the login prompt
> says the error "pam_opie.so: not found
>
> how can I get it back? I tried everything and nothing brought it back , n=
ot even another make installworld
> any insights?
> ....

I believe that the issue is a result of:

| commit 0aa2700123e22c2b0a977375e087dc2759b8e980
| Author: Dag-Erling Sm=F8rgrav 
| Date: Sun Oct 2 03:37:29 2022 +0200
|
| Put OPIE to rest.
|
| Differential Revision: https://reviews.freebsd.org/D36592

(in src/lib/libpam/modules).

OPIE is (thus) no longer part of FreeBSD current. I expect it would
be best if you arranged things so you no longer depend on it.

Peace,
david
--
David H. Wolfskill david@catwhisker.org
Putin seems to use the word "peace" in the way that Neville Chamberlain did=
.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


--_000_CP6P284MB19006490A396B9B323AC1CF2CBF49CP6P284MB1900BRAP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Hi david / all









And how can i fix my login not to use this opie anylonger? 









Thanks



--tzk















De: o=
wner-freebsd-current@freebsd.org <owner-freebsd-current@freebsd.org> =
em nome de David Wolfskill <david@catwhisker.org>

Enviado: ter=E7a-feira, 3 de janeiro de 2023 18:48

Para: Ivan Quitschal <tezeka@hotmail.com>

Cc: freebsd-current@freebsd.org <freebsd-current@freebs=
d.org>

Assunto: Re: cant login after make installworld: pam_opie.=
so.6 not found





On Tue, Jan 03, 2023 at 09:39:31PM +0000, Ivan Quitschal wrote:

> ...

> I am having a problem here after doing a:

> make installworld

> and

> make delete-old-libs

> 

> now I cant login (only thru single user)

> looks like the "make delete-old-libs" has deleted that lib p=
am_opie.so.6 and now I cannot pass the login prompt

> says the error "pam_opie.so: not found

> 

> how can I get it back? I tried everything and nothing brought it back =
, not even another make installworld

> any insights?

> ....



I believe that the issue is a result of:



| commit 0aa2700123e22c2b0a977375e087dc2759b8e980

| Author: Dag-Erling Sm=F8rgrav <des@FreeBSD.org>

| Date: Sun Oct 2 03:37:29 2022 +0200

| 

| Put OPIE to rest.

| 

| Differential Revision: https://reviews.freebsd.org/D36592



(in src/lib/libpam/modules).



OPIE is (thus) no longer part of FreeBSD current. I expect it would

be best if you arranged things so you no longer depend on it.



Peace,

david

-- 

David H. Wolfskill david@catwhisker.org

Putin seems to use the word "peace" in the way that Neville Chamb=
erlain did.



See https://www.catwhisker.org/~david/publickey.gpg for my public key.










--_000_CP6P284MB19006490A396B9B323AC1CF2CBF49CP6P284MB1900BRAP_--

From nobody Tue Jan  3 21:57:22 2023
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 4Nmmmw0nKrz2nwF5
	for ; Tue,  3 Jan 2023 21:57:36 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Nmmmt4Rsvz3DWH
	for ; Tue,  3 Jan 2023 21:57:34 +0000 (UTC)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=r76J5vns;
	spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl;
	dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl
Received: from [IPV6:2a02:22e0:cf00:1ff:7404:464b:d558:b5b7] (mzar@[IPv6:2a02:22e0:cf00:1ff:7404:464b:d558:b5b7])
	(authenticated bits=0)
	by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 303LvOal043273
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO)
	for ; Tue, 3 Jan 2023 22:57:24 +0100 (CET)
	(envelope-from zarychtam@plan-b.pwste.edu.pl)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl;
	s=plan-b-mailer; t=1672783044;
	bh=gIWiJVjIad5RkxIsLgA4QMevMn6N61vwELjaDdWEWYQ=;
	h=Date:Subject:To:References:From:In-Reply-To;
	b=r76J5vnsWaB16MA6JPFlPS1dj1AlVViJrS4Qa8dXM0k9xoMqlbfSWX79Q17zAcxQf
	 hpU1ZereZPM5cfwcjx7ehjQCqZ/rE4N7G1fpL46dOuXva2snEoq/PEO5lhBXVHgfeh
	 kXbfuzXxeqPJAhsOQID4b3pGnQK1qXnuW4RooScMsMD1INypV7R4q1imFRTsYhCGpH
	 m3RdGjQD6QX730yhvehpork2eN3g17KGXRYa8AdokYdqQa2Nk5EU75fLXRZqsvSMaC
	 xj7k5zpmJx2F+gC5ld0Mqp0Bb/REdpYsEfz9TlHIvZnd3bjgfW+33pZ74U+DFaZj0p
	 g5+H07E+H6GYg==
Content-Type: multipart/alternative;
 boundary="------------T91ylvGgHOXegDKlu7Xw3eyp"
Message-ID: <6f85c1b2-91ed-f02c-bbaf-65e10cf36bbc@plan-b.pwste.edu.pl>
Date: Tue, 3 Jan 2023 22:57:22 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: cant login after make installworld: pam_opie.so.6 not found
Content-Language: en-US
To: freebsd-current@freebsd.org
References: 
From: Marek Zarychta 
In-Reply-To: 
X-Spamd-Result: default: False [-3.80 / 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)[plan-b.pwste.edu.pl,none];
	R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	R_SPF_NA(0.00)[no SPF record];
	ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+];
	RCPT_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4Nmmmt4Rsvz3DWH
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

This is a multi-part message in MIME format.
--------------T91ylvGgHOXegDKlu7Xw3eyp
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

W dniu 3.01.2023 o 22:39, Ivan Quitschal pisze:
>
> now I cant login (only thru single user)
>
> looks like the “make delete-old-libs† has deleted that lib 
> pam_opie.so.6 and now I cannot pass the login prompt
>
> says the error “pam_opie.so: not found
>
> how can I get it back? I tried everything and nothing brought it back 
> , not even another make installworld
>
> any insights?
>
Remove dependencies from /etc/pam.d/ files. Use either etcupdate(7) or 
mergemaster(8) or do it by hand.

-- 
Marek Zarychta

--------------T91ylvGgHOXegDKlu7Xw3eyp
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
W dniu 3.01.2023 o 22:39, Ivan
      Quitschal pisze:

    

    

      
now I cant login (only
          thru single user)

      
looks like the “make
          delete-old-libs† has deleted that lib pam_opie.so.6 and now I
          cannot pass the login prompt

      
says the error
          “pam_opie.so: not found

      
 

      
how can I get it back? I
          tried everything and nothing brought it back , not even
          another make installworld

      
any insights?

      
 

    

    
Remove dependencies from /etc/pam.d/ files. Use either
      etcupdate(7) or mergemaster(8) or do it by hand.

    

    
-- 
Marek Zarychta

  


--------------T91ylvGgHOXegDKlu7Xw3eyp--

From nobody Tue Jan  3 22:17:01 2023
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 4NmnCP5vQYz2p01n
	for ; Tue,  3 Jan 2023 22:17:05 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2052.outbound.protection.outlook.com [40.92.97.52])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NmnCP3QFTz3GjL
	for ; Tue,  3 Jan 2023 22:17:05 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Authentication-Results: mx1.freebsd.org;
	none
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=h0/QUbsbnh3F8EKJj9sHyaVsbvVkwhOiNPfnXgdo2TlX6uOfAyiZyaxIlD1EurSyVFGvvXiWMMWelJKmQ0LpUvC00KpiVXp4bijVW5R+CpFb0oReWnkskD70irlIum1EsWbL1Vu9rHqMZRXJSA0rKa/qMLa91LXq2C8LQkiEvnwm6VffuF4jrNTvqhfJ8N8iQIVeSYHr9mbgu10CmYdo34rVHXuJo5hd/AsbrrMwFH7gH4jKy3aOOgztHCuGA72zVI5h2gh60XPyorIiHlwOKLJAVkQJdgdRZUp+AhIKlXxCZia9j4UYvEiFryT8pvhAfWCrdPQnAmAJtL6tcrq3BQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=PSVBKdmDBYfW4K2H7BR/baEhc0wwWrLuV9W8jjUcM40=;
 b=JXzqWMHQkI5H94zNhqRfMgwFsg1wsbkarm2zh8lWrBKQLCpDG9ZfcvE5DlFo3rw55IeLwfYBB5lWeSNLfqsL8u4yYDS20yVoWIeLDSvw7ixr46J1fbLUwmg6i+BRqd/Y6pE1I73ydhK2FxgzmF3tGTYuBgCH3Q+FZRFeTaaplLddqi1bOwbdnVvRErG7tYNuRdG+xXgkxjl/qK6D5wOy8J1T9IawHvbqpTSNLxAWiz7uIHtfzEC9q2tbe+tWaMMQcD4LrS9jsk5w8e53VcAO4GCBzJzffFKFwQKDD2/Aq1N11d14IjqS2n0+1fIxEB/OInCGI66aUUwga+6KsV6GVg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=PSVBKdmDBYfW4K2H7BR/baEhc0wwWrLuV9W8jjUcM40=;
 b=fWXlyIfK9fW2JqpiY2zJBDtoSNJWL1BeAch5fRvAIyw73/XOyFr6EDEm6R4uvR8cuM7sRW7478c9Xl1Ya7xV/6Nob6SrKNQtBV2/sUOG8I3LrC8vBFiYUToWWUcE6jikb3IYtGV+YkmtFVRGdGf4xVzPV9fO3qzKhFNUCRU7w+XHhTx3LGrAH4vGmwNcpU/UM2ZRB6mzqkf1gSDHTpP3CbFNr2mGULlib9oa4IGLKH/JMvL8SVm0uwV7BOfOskVD2kfjHUwBD4FL/AA0VMbvIb3puJehVShmEnypirubZOuRvPw4iPDXicVPO2GvQ+fgSSETGtRjOdh9HdxSxzn3JA==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by ROAP284MB0272.BRAP284.PROD.OUTLOOK.COM (2603:10d6:10:3f::6) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5944.19; Tue, 3 Jan 2023 22:17:01 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::42aa:25c0:1211:33a8]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::42aa:25c0:1211:33a8%9]) with mapi id 15.20.5944.019; Tue, 3 Jan 2023
 22:17:01 +0000
From: Ivan Quitschal 
To: Marek Zarychta ,
	"freebsd-current@freebsd.org" 
Subject: Re: cant login after make installworld: pam_opie.so.6 not found
Thread-Topic: cant login after make installworld: pam_opie.so.6 not found
Thread-Index: Adkfu/MgSfn+1G7AQtm+nH0V0Z/UIQAAmgoAAACVJCM=
Date: Tue, 3 Jan 2023 22:17:01 +0000
Message-ID:
 
References:
 
 <6f85c1b2-91ed-f02c-bbaf-65e10cf36bbc@plan-b.pwste.edu.pl>
In-Reply-To: <6f85c1b2-91ed-f02c-bbaf-65e10cf36bbc@plan-b.pwste.edu.pl>
Accept-Language: pt-BR, en-US
Content-Language: pt-BR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [CtHEsLeOpSFyo4naOrOrAGR/4O0Rdl4q]
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CP6P284MB1900:EE_|ROAP284MB0272:EE_
x-ms-office365-filtering-correlation-id: c6e47932-d91a-47a0-6f31-08daedd83cc6
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 nkPPAvDlKzmcBjozZfIhsdJk0+8Pmvt6FoCSz9ngRCqW7ZCKMI9ujQ6NPHn5/ZI81uiqBrtLl1Mo4AVWmhIdEEEcrZ5cbKGv+777gUgFtV4y54mO41LDp3hYUJmZoq6qMwe3oc5wSfuIngsup9mukOwLu6nLagtYL7+NK0cCXpNR3fzT7wuuqtTGrJpOUwxvT9cvPAmHHIu3HxP/0hH8n76pJaxnxLRkAvcTEcXqo3oxNpWEmj2ro5DpMi4bhVsAcWqRPrN13+INshAooI8cGBdlzZkuX88HznLgq1JhSu1UyZqqfzDYd+obhMdw5SH+VytAtYbNXcDRgGvLL1YjWTwpUUat39mRZ+7ixYDPHcdv7E0R6AbrOtMiVXRsgvK3aZjxTE1blaPRDrDh4CTISJkEXhKvi3o9mF3KI9gbKTahXRvvw520+VuQ/uqoVynE+5KLJJ6/tx4qDXWNH4pxutov7JvFNbnBpx2GI6clW9us+2srBajOwIjUgyjXaXhaB1dbDULa2rVBbU33agF1KetsCGm+3ELXmdxmslwkluzg5iDr2PqXJnCDNt2mf5hZjjQM8f5VVJW5237PfArLAcyP2gU1Hv6Dh64iRlPyAJqF4Wb70MPMykf9W0JVddQS10zMfoC7YohFvo+uePZG+A==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?Windows-1252?Q?4JZvUc0g2rcV77kaH3ug/37aX+aPiuxflSYHs4gdVlbG5+FPAlqb+rfW?=
 =?Windows-1252?Q?uc5U9MF3+0t6vKIIZ7IY14uI9CIOtQFHZyAjpXQa1Gm62srn1fh6UGQY?=
 =?Windows-1252?Q?/aD8h5Rb+bw7I7kHpmdL2VycT7gyZsPaMfaEy1YP7e/m/lIzUvZUzway?=
 =?Windows-1252?Q?WCVrNMVp1bUzXc4Xo8Xi4PuUvXNhdQUfGlWRpZPmyzdf5S13tAQZEoAo?=
 =?Windows-1252?Q?WChUm0TrIykPsQ7/xxsDcEYnKQbQxEieLKDT9cyP/I46xIxfYGr2Mp5S?=
 =?Windows-1252?Q?sF0+hAbXvASJQf7ZMx6rGqEJLiO4toWrKoMjqcx32aYLjr+aEp0B2gOX?=
 =?Windows-1252?Q?muXDWVtcCfx/4RYNLds/cVRwtwS0dXPuCVHzxHszzoDyucvx4TZIuNVr?=
 =?Windows-1252?Q?cTPmmpmQxpxKcb8hebYXzw24x4VM+2ssnn6NkSAdoZWPKTqUz07sV/fr?=
 =?Windows-1252?Q?ZrptroGDrTPn1JP85cchJKQYX2jaGq+X1+RTlo3WtqFBP+f8tIohSMNf?=
 =?Windows-1252?Q?gFu0I0YzuH1cWpr/I3VJjYI6qGPfEkxfq4tHrkFUNr4O5VieuAs6yxEg?=
 =?Windows-1252?Q?WWfmWdN3j8EEdixIxFFmvS01BXDvLCN8h3wlj8gvkQv4hqRkD17nUJsh?=
 =?Windows-1252?Q?BA81LSWHxhNUfDWHbj5TbaH5paWDE/yYxhHcbAIt/0TMyVyA5gP92ucC?=
 =?Windows-1252?Q?k8Ht/5H2FHcdm7tSP80d94yreStxafyn+QDkoVUtd/qOWGnow/nGwr4E?=
 =?Windows-1252?Q?4k1Ege9V23Ik4fO9PvXLif63gqeMnPYv7bW/wbABdBcHnASg6I7E6ZhL?=
 =?Windows-1252?Q?Fo4gICQSrVTERA0GCawe6vxHiaCnYDN0jR06Jcda6WcUA66EzKtOMTHZ?=
 =?Windows-1252?Q?v5prWZ33FphWuwfp6NDSDIUIpI/2OXPM5BjYvnOdlNzxaR62273Tgqie?=
 =?Windows-1252?Q?Xdhs5+24wWcra90U0EZ0VehQjhRDD12/vhqv3N4Xt+ATiFgThvwxViUV?=
 =?Windows-1252?Q?cO8/B0G6wvFP9blXuKiRVOqPx/BIFlqUZZpQqullVrS+QGnwVH0CccHK?=
 =?Windows-1252?Q?KD6cBXxwYijTmmfiVNVP4QsJe6j0wFLc8f6J02CRDOjqRKvEt2JsgR8P?=
 =?Windows-1252?Q?s4ziQ87N0TuXkmPfpLsCN0myJsJuTtU1a1blEeZLt66Qsapq159ILdpk?=
 =?Windows-1252?Q?54OqUoSPQeSKwd/UfSQWAaj9hyTWya9fYZYAEvw6r09lh5Um0erRCJ02?=
 =?Windows-1252?Q?Y20rU+cyP3eJuUgIPQjrFjfbS+YOd4lDTj1NY2Xv92MD0JW5NiKS2KaD?=
 =?Windows-1252?Q?cgxFlJls48bAg8/IGgN5yqfF2XkxIzZyTBltYbCXA5wGz61UUqSbOqsK?=
 =?Windows-1252?Q?+0ZWaDRy2KzzXg=3D=3D?=
Content-Type: multipart/alternative;
	boundary="_000_CP6P284MB19006F13C9AB4F25C7029AE1CBF49CP6P284MB1900BRAP_"
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-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: c6e47932-d91a-47a0-6f31-08daedd83cc6
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2023 22:17:01.4078
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ROAP284MB0272
X-Rspamd-Queue-Id: 4NmnCP3QFTz3GjL
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--_000_CP6P284MB19006F13C9AB4F25C7029AE1CBF49CP6P284MB1900BRAP_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi marek/david

Worked, thank you

I had to "install" the new temporary /etc/pam.d files with mergemaster. I t=
hink the problematic file was the "system" config file. Now its all fine

Thanks again
--tzk

________________________________
De: owner-freebsd-current@freebsd.org  e=
m nome de Marek Zarychta 
Enviado: ter=E7a-feira, 3 de janeiro de 2023 18:57
Para: freebsd-current@freebsd.org 
Assunto: Re: cant login after make installworld: pam_opie.so.6 not found

W dniu 3.01.2023 o 22:39, Ivan Quitschal pisze:
now I cant login (only thru single user)
looks like the =93make delete-old-libs=94  has deleted that lib pam_opie.so=
.6 and now I cannot pass the login prompt
says the error =93pam_opie.so: not found

how can I get it back? I tried everything and nothing brought it back , not=
 even another make installworld
any insights?


Remove dependencies from /etc/pam.d/ files. Use either etcupdate(7) or merg=
emaster(8) or do it by hand.

--
Marek Zarychta


--_000_CP6P284MB19006F13C9AB4F25C7029AE1CBF49CP6P284MB1900BRAP_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable








Hi marek/david









Worked, thank you









I had to "install" the new temporary /etc/pam.d files with mergem=
aster. I think the problematic file was the "system" config file.=
 Now its all fine









Thanks again



--tzk













De: o=
wner-freebsd-current@freebsd.org <owner-freebsd-current@freebsd.org> =
em nome de Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>

Enviado: ter=E7a-feira, 3 de janeiro de 2023 18:57

Para: freebsd-current@freebsd.org <freebsd-current@free=
bsd.org>

Assunto: Re: cant login after make installworld: pam_opie.=
so.6 not found






W dniu 3.01.2023 o 22:39, Ivan Quitscha=
l pisze:






now I cant login (only thru sin=
gle user)


looks like the =93make delete-o=
ld-libs=94  has deleted that lib pam_opie.so.6 and now I cannot pass t=
he login prompt


says the error =93pam_opie.so: =
not found


 


how can I get it back? I tried =
everything and nothing brought it back , not even another make installworld=



any insights?


 




Remove dependencies from /etc/pam.d/ files. Use either etcupdate(7) or m=
ergemaster(8) or do it by hand.




-- =0A=
Marek Zarychta










--_000_CP6P284MB19006F13C9AB4F25C7029AE1CBF49CP6P284MB1900BRAP_--

From nobody Tue Jan  3 23:07:32 2023
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 4NmpKg46Z8z2p5b2
	for ; Tue,  3 Jan 2023 23:07:35 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NmpKg3fVkz3L78
	for ; Tue,  3 Jan 2023 23:07:35 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1672787255;
	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=V4r6kaUqHwz/5215kPOH11+JzI2iePa79TEtu3xH56Y=;
	b=ZE0IgyRJrrEP4nvgDVO8CKF55I0Tx47j4NGRrU685orkJOqvP3XYJAYWEVLtY5og52qKvw
	FkLbU66aYfXuoFKfirrWlqRZZHfjNmRYaOnDt+SBmsWZu2xcP/apPI0KRYKypOTLKBMp74
	cmQpRC4QR3C2EU59uMdrD9hToPJx9OB6uc4B+NmhhKldc52mL3q1ktMVpn+SduEhN5HxeC
	19lG9egFRzV6+CNxHC3BOcHvPtX1Vq1VfeJzmNOpYeCnH0L9NbHZl6yE9U38vOIulvPFrU
	miqpbGitBlNLOiPoKgo57oDTuxnZn99cNkAKsgvujgFnaYuaG+ms2eUN9n1J8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1672787255;
	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=V4r6kaUqHwz/5215kPOH11+JzI2iePa79TEtu3xH56Y=;
	b=ijoC/VVFW6G0DWy0il0xqCmuYzwEKRG6q9+Rf6yeGxVfR0JTGflOUGcbTlFKUB2hUWh0NP
	sV32oP5fD6AWhs+PjxE3+KaK3KSaGiVCXMK6y1n8alBzonmC3n89Jwz9TrTUhwkNKata0b
	H27oiMXbkEFckCNYkyp3RlT12SQSjaHZ3ezsXDbMi9wS2gXV4ukyDVf2pZXQ6wZzye0SdK
	ezlXrcZWWGfcQ6nIAWzEnX2D+k0cp8oO/xoL8rg78Ku2GuEG/PsuxpHgEEdrMczV7OtoTE
	/OthCWntO/LzW+R5pysOL16Jb+k7qsSQZ/1VyQ6BnK1JNuJRWsH810+lH3oayQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672787255; a=rsa-sha256; cv=none;
	b=Yq3HFSI1GCwJ1/3JEu02kO0cC1E6oB484cWIuOZUXWJEhJ6DI1Xgc1S/aRFgTrBXwp1a+0
	ndAA53aUMoCIPH+WchI6Ylld5/bAUcLvfSxDfxLyApKjLY+QwueAkYlR21e+h8wK8xxunR
	L4wGIO0jtdxPh7fZyRdUwuDjBAkT3CrgVesXIClCk2IsIhHFqgjYIcayX5honbBcrHQFoF
	0NchfZ/3bTxgR9sh6YnO+g3B8wR3VN9dI5sx+E9PIe08DBwDns2b0TGaIq9n98feFXz5nz
	9lFpDuJIkYvN2F1O3CDiLJgBCyHeOtLLmQ0mKZOvw0/xmj17VViTaFnu47pusQ==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NmpKg1T4fz1H8C
	for ; Tue,  3 Jan 2023 23:07:35 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: <2f941407-599c-b422-75b1-8464d3a31a88@freebsd.org>
Date: Tue, 3 Jan 2023 23:07:32 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Using package build records at pkg-status.freebsd.org (was: pkg: No
 packages available to install matching)
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: <99fb8ae0-c8d5-1cbb-5edf-28907120da3e@vboldin.ru>
From: Graham Perrin 
Organization: FreeBSD
In-Reply-To: <99fb8ae0-c8d5-1cbb-5edf-28907120da3e@vboldin.ru>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------4efBDmzVhB3eAoKDO99YQc39"
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------4efBDmzVhB3eAoKDO99YQc39
Content-Type: multipart/mixed; boundary="------------BCw5Qt8vSTptFumBV2FRSqSp";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: <2f941407-599c-b422-75b1-8464d3a31a88@freebsd.org>
Subject: Using package build records at pkg-status.freebsd.org (was: pkg: No
 packages available to install matching)
References: <99fb8ae0-c8d5-1cbb-5edf-28907120da3e@vboldin.ru>
In-Reply-To: <99fb8ae0-c8d5-1cbb-5edf-28907120da3e@vboldin.ru>

--------------BCw5Qt8vSTptFumBV2FRSqSp
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDMvMDEvMjAyMyAxNzo0NSwgVmxhZGltaXIgQm9sZGluIHdyb3RlOg0KDQo+IENhbid0
IGZpbmRuZXQtaW0vdGVsZWdyYW0tZGVza3RvcCB3aXRofHBrZyBzZWFyY2gg4oCmDQo+IHwN
Cj4NCnxWaWEgPGh0dHBzOi8vb2xkLnJlZGRpdC5jb20vci9mcmVlYnNkL2NvbW1lbnRzLzEw
Mmx0OGEvLS8+OiB8DQoNCnx8DQoNCnw8aHR0cHM6Ly9wZW9wbGUuZnJlZWJzZC5vcmcvfmdy
YWhhbXBlcnJpbi9wa2ctc3RhdHVzLz4NCi8vL1VzaW5nIHBhY2thZ2UgYnVpbGQgcmVjb3Jk
cyBhdCBwa2ctc3RhdHVzLmZyZWVic2Qub3JnL3wNCg0KfHwNCg0KfA0KfA0KDQp8fA0KDQo+
IHx84oCmIDE0LjAtQ1VSUkVOVCDigKYNCj4gfHwNCnwNCnwNCg0KfFNlZSA8aHR0cHM6Ly93
d3cucmVkZGl0LmNvbS9yL2ZyZWVic2QvY29tbWVudHMvMTAybHQ4YS9jb21tZW50L2oydTBt
OW8vPi4NCnwNCg0K

--------------BCw5Qt8vSTptFumBV2FRSqSp--

--------------4efBDmzVhB3eAoKDO99YQc39
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmO0tTQFAwAAAAAACgkQt2dIb0oY1Avl
mg//Xb3Lg+ixpYXK39LCL5kax6JALKV5g0ifMXkvw38gFaZxJ9WWl8zQLm9svHdz8B5iFwgKksFJ
kutBJM339U8qDeaBf+Ov+oP7SBII/oS2KeT7wkiTT5hIZnixU+F+CtSuXcvhKXB+/DECWJnFrMHV
ZIEe1rxk4ppAZQiay66DkjYdSbP/pkQDxAL//yvexiZeKYfMtRmMElwzHDTr0TNg2GLZjeCXycQM
rVqThDjm4YfbT6u26tnyhC0qobXh1+AqsQIme+ZQhkCW0DFOpcsYv8QUqOjKJT7KH54L4HXOQv1u
XTkHmQ50IqHUEEMVIOyqfat+gUxU2fQYE+9ZZrX7Rq3DAVJZLjewG2qFHA/sHfNkdtaYKDS/MvPo
oW68VHpmbEGOeFiDEPeEOUhztMU9TRIzOhO4jcoroUn6lKugLaYx1mGap9kbAH784evj8IvF+Qv8
Z8JhbSOaXPnLQwe4CqlV3SWmmGL3+GaOoUFFpdOFPGawzfjkJnVgdwfoHg4iN3sDyeEaL+oNI8jb
qDK4OYAEW6eKAz/G/MOyV9T9+TMo4GPDoWSsVKmkA4P0VWDVNCZo8j9b08Xr1AtOucC/3lXaFh6d
m75RzrB537gw8kI6gobrkktkZMIphxdXKuisEoGbw9NJnQcWL1CYVmSsv2ktEb12HC4V29ALykd0
Yzo=
=Dqkm
-----END PGP SIGNATURE-----

--------------4efBDmzVhB3eAoKDO99YQc39--

From nobody Wed Jan  4 10:24:45 2023
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 4Nn5MD6d6tz2nn3C
	for ; Wed,  4 Jan 2023 10:24:56 +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 4Nn5MD32tNz3GNn
	for ; Wed,  4 Jan 2023 10:24:56 +0000 (UTC)
	(envelope-from kostikbel@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: from tom.home (kib@localhost [127.0.0.1])
	by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 304AOjfv013561
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Wed, 4 Jan 2023 12:24:48 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 304AOjfv013561
Received: (from kostik@localhost)
	by tom.home (8.16.1/8.16.1/Submit) id 304AOjq0013560;
	Wed, 4 Jan 2023 12:24:45 +0200 (EET)
	(envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f
Date: Wed, 4 Jan 2023 12:24:45 +0200
From: Konstantin Belousov 
To: "Floyd, Paul" 
Cc: freebsd-current@freebsd.org
Subject: Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
Message-ID: 
References: 
 
 
 
 
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Rspamd-Queue-Id: 4Nn5MD32tNz3GNn
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Tue, Jan 03, 2023 at 11:38:55AM +0100, Floyd, Paul wrote:
> 
> On 30/12/2022 01:54, Konstantin Belousov wrote:
> > 
> > The backtrace is needed to make a further analysis.
> 
> 
> Any suggestions for getting a backtrace? I get the panic booting either the
> installer ISO or the VM image, both in VirtualBox.
It should be there right after the panic message.  No idea how to take the
virtual screen snapshot under VB.

Also it might be easier if you configure serial console and catch its output
outside VB, but again I have no idea how to do that.

From nobody Wed Jan  4 16:30:53 2023
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 4NnFTV5rp1z2qtQL
	for ; Wed,  4 Jan 2023 16:30:54 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NnFTV5Hvjz43nt
	for ; Wed,  4 Jan 2023 16:30:54 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1672849854;
	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=CA8+fkUtjv4nmQUmGKIKsk2b2/dNaLinTfbouepof78=;
	b=NC/XJq4Kl7lAdYT/ruI7k2IbfR2+4/ZIZmw9JCf6E8VTmgfMA52oPIhu7Vzb6cVqikxruI
	/h2XGMKuAPVV6mijw6ldGIinHaCuPuHzH0CL83a/4L/9Yfqyp7GAYFoxt+LuMLtvstK2OU
	J+Yj3Y+elu5DfpJfk1SqgZpL2+uwB2HVq9uf78PbKR8p5uIbct3FhZMuBYk3CIp6gGJBVz
	8xw2mi01zlu7YSUxzGdHgucU883eYuChdm+KmhUhzK5TU497pb8FV+IOVveELLHa6Nfaz1
	1CAJE2ofIto52OxtYr6cEexphxwqsow3v9yRrg4JoAGHXgPef3Uxpc9R8Wx3Ng==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1672849854;
	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=CA8+fkUtjv4nmQUmGKIKsk2b2/dNaLinTfbouepof78=;
	b=SkmHQjRC8dk48tEuGvJ8N19ceAVFBXxVvPWkyQnYAf8u4WycB70irafezVf5exsW/jl30m
	TJz4P9gSF/xWjCGekAviA+lliiFqxDUGLNyMAJZqlDSaznq/UgpEYAlJrKC6C22nHRPcgI
	EsfFciltYnJsV1H5UyACbzUDL6ZReK9dc9frxvj+A0/yl5qhafM4lKDT+e5eaWaHdrT0QF
	aSJXn2ee42/qW4TZm/MJOzpW8Hbleyjl+SRwG1Kk/SOeWj2xJLCwjeLO8LQnjR49roRO8W
	MLhPBofUQVWSNQ95zAe+NAxc1nBJ/pl+Ig4NvQ4u/NKkfXjGu0gyO8wD6bboOw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672849854; a=rsa-sha256; cv=none;
	b=Tq6uNe613os8T7QdeWMV8Lbhrw77P8m/nicODCZzuJcGpy9W+tGodlS7FitiCJci4ye3Yt
	5iMTlfLnEcGe/2WkmXuun+OAqE/hoqfn5a+7cJKyYilNPkf4mmeQaUSXyrgPW93pnPCaeO
	d81ueS5kMq5TVwbIqEtdo5xij+Tla+79T27a8jRe10I+eJ4MyuQmVSiNIuam9YevaHiokX
	dEmCFAzdT8mXLZjcw0tPrn4V8NZF+fOszSPy2c+FEc0HyPLm6hegL1LZ72+9rMEmGq/bGP
	e2opWooIfcgYKsqw32jpWi8pKGKW9z5/sBoGSeVgndf1uWy4ln/9s1VU4+00gg==
Received: from [194.81.204.29] (oa-mowa-01-194.81.204.29.brighton.ac.uk [194.81.204.29])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits))
	(Client did not present a certificate)
	(Authenticated sender: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NnFTV2w7hzM3Q
	for ; Wed,  4 Jan 2023 16:30:54 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: 
Date: Wed, 4 Jan 2023 16:30:53 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: VirtualBox: screenshots (was: 14.0-CURRENT panic on boot, i386
 VirtualBox client)
Content-Language: en-GB
To: freebsd-current@freebsd.org
References: 
 
 
 
 
 
From: Graham Perrin 
Organization: FreeBSD
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------5gJQqnLzN8kFxUiZyuLeqS5Q"
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------5gJQqnLzN8kFxUiZyuLeqS5Q
Content-Type: multipart/mixed; boundary="------------mSN4s2SqAgrpvIP0pNUjwo0F";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: 
Subject: VirtualBox: screenshots (was: 14.0-CURRENT panic on boot, i386
 VirtualBox client)
References: 
 
 
 
 
 
In-Reply-To: 

--------------mSN4s2SqAgrpvIP0pNUjwo0F
Content-Type: multipart/alternative;
 boundary="------------KeMVXvPxIQd5v8F1st0P6ip2"

--------------KeMVXvPxIQd5v8F1st0P6ip2
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDQvMDEvMjAyMyAxMDoyNCwgS29uc3RhbnRpbiBCZWxvdXNvdiB3cm90ZToNCj4g4oCm
IE5vIGlkZWEgaG93IHRvIHRha2UgdGhlIHZpcnR1YWwgc2NyZWVuIHNuYXBzaG90IHVuZGVy
IFZCLiDigKYNCkZvciBtZSwgaXQncyB0aGUgQ29udHJvbCBrZXkgdG8gdGhlIHJpZ2h0ICsg
RQ0K
--------------KeMVXvPxIQd5v8F1st0P6ip2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 04/01/2023 10:24, Konstantin
      Belousov wrote:

    

    

      
=E2=80=A6 No idea how to tak=
e the virtual screen snapshot under VB. =E2=80=A6

    

    For me, it's the Control key to the right + E

  
  


--------------KeMVXvPxIQd5v8F1st0P6ip2--

--------------mSN4s2SqAgrpvIP0pNUjwo0F--

--------------5gJQqnLzN8kFxUiZyuLeqS5Q
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmO1qb0FAwAAAAAACgkQt2dIb0oY1AuW
mQ//VhO/TkhFOT1DmPq7WK+3ywzdj5x9F5IfUJGG3IDiTpmbqMJewgqBBid3q3mlEoVf4M0dZYQw
Z/wEJLileMgvTMXwDSGx66s+8BzFT1uoQr4tssVH2elpOsAAwErT3C3dgjuFW+IUPa+cYGdzz+xY
YfOrN+Mcc7F0t9kXQITN81QhBqrWd2K6zlaKSthqyaT+xnsuls+zhwXFM5rYmZGkx8cmal9Gk+e2
ETduEav3AX8fpXpkuF1INnJikN/9pIxUo5XY0rrxA9o5TyYXuiGgP+0n4HmBzi0Uqu5dt2mdHaZD
ZTqImdS4N9phUd+fzY1dx3dfNdeZyGlzOBZP+1n0eYO6yQ4ONjT3+g7YTzY6eiu2Us4roz3wHCPc
rOBjo4Orf4rdptN4H/MDarNxXvh0vKHxz7aqY8WO7YvmL6FQ6K50TaNwQNrgKdnzQ+Hc5bKtJeq1
MOlPjAK+QrfeoriJWKifRKoo8iWURpWCPBFEaFIZuDEFoOMTl+wki+Yg4+6rYe5i1xZbAv8MWmwV
evd1ZJXPHIa2kArcOeYkpmqFpw6HMyLP9hiyiWsjmHISQfmpNGxsp7ptrNfg0+/+uZ82eLtszS3h
qu6F+NG9rri19AGhLFCzeZg7jzzh1VJwDBiSTbU0umTRncKTo0m/PuJ8pqFmcSNDYKUHqIaiNo/s
lO4=
=J58u
-----END PGP SIGNATURE-----

--------------5gJQqnLzN8kFxUiZyuLeqS5Q--

From nobody Wed Jan  4 20:48:49 2023
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 4NnMCD0TmDz2p4kv
	for ; Wed,  4 Jan 2023 20:48:56 +0000 (UTC)
	(envelope-from paulf2718@gmail.com)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NnMCB6wbYz3D7Z
	for ; Wed,  4 Jan 2023 20:48:54 +0000 (UTC)
	(envelope-from paulf2718@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=anb2mZAr;
	spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::332 as permitted sender) smtp.mailfrom=paulf2718@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-wm1-x332.google.com with SMTP id bg13-20020a05600c3c8d00b003d9712b29d2so24887466wmb.2
        for ; Wed, 04 Jan 2023 12:48:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id:from
         :to:cc:subject:date:message-id:reply-to;
        bh=bd368QM8ZvPWseLjzv2OWgvzbeur18nBIjCC/vw+W/Y=;
        b=anb2mZArahzHI2XvICs2NdNvCR/PhuiTn6DoAQkVQNsR0yOFoj0qw3xsv96zSkB7nm
         rhBPuriQhumuxvpJMzPG2/BcLym1u7NWUA7NiStYGYcyDn3UTGY1vvMtrh8rcl95q2Cw
         x97JhUbOynmZtVPW746NFoAVy2VqV9qm0/oQGpnRTGZqI7HQsjuQFjjijlPldpVYqUiH
         M2ZRa8Y4eBQGkI8jKTRGRWKy5rZvq7VrVJYjyOpD7AKtWpDcyivqDkCFFUkalvWLl3wT
         7WgdECAdJOlY7Y4bR28ea0KWu/ya0wRFzw7wQEd6EgNu70psGjZh+zYcdX2+O2mRSqZB
         a8Cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:content-language
         :references:to:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
        bh=bd368QM8ZvPWseLjzv2OWgvzbeur18nBIjCC/vw+W/Y=;
        b=5d4GV2SwUplPkzt2JQRxrQCTGZJoUnhNW/8fABZNPcnCME/mx2NWO443lTDxGk9pqZ
         cVM64wQYeOx0oXlYrLV8g7HZ91WOUlCFWv61x8JnzHHup7wAcEcpoIgEZz9h+VUcuf9C
         leh94kVm66U98KJMlaexVqfuku5emUjeZYBPSHygKusywHtufG24rNK4oFbXrR/fUY3Z
         2oSYgV6uYOVCGq3PneKucNe09+Wt2oUjflser1qsVCzn8vWSQBPfxLeXARsqLR3BZW+P
         OYY6J4IeDoYcgdlqn1Fvg5m8CSDLRAoX+TKFZMoIu7HbVVhAHd754Nz/byUM64t+YIKh
         5Nxg==
X-Gm-Message-State: AFqh2kppuRFWwMzE8cDWdu/I6aMTr2uBlfTrIx2ID8SU5uYaenCKSY5I
	CnL7oCbmGkXihihCfZCNRJ/13xQpoiqU1f5s
X-Google-Smtp-Source: AMrXdXstxL10xzoLeeucyOox5WM/Egogfxxur+UPGl/ahHpmflwERUlUiBH27l1O7TmUaO/v7emfiw==
X-Received: by 2002:a05:600c:3b90:b0:3d1:f0f1:ceb4 with SMTP id n16-20020a05600c3b9000b003d1f0f1ceb4mr35008370wms.19.1672865330467;
        Wed, 04 Jan 2023 12:48:50 -0800 (PST)
Received: from [192.168.1.28] (lfbn-gre-1-309-115.w90-112.abo.wanadoo.fr. [90.112.30.115])
        by smtp.gmail.com with ESMTPSA id s16-20020a1cf210000000b003c6bd12ac27sm46222057wmc.37.2023.01.04.12.48.49
        for 
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 04 Jan 2023 12:48:49 -0800 (PST)
Message-ID: <60a60db7-5ade-6261-9150-94e1a9aa4de1@gmail.com>
Date: Wed, 4 Jan 2023 21:48:49 +0100
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: 14.0-CURRENT panic on boot, i386 VirtualBox client
To: freebsd-current@freebsd.org
References: 
 
 
 
 
 
Content-Language: en-US
From: Paul Floyd 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-3.97 / 15.00];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-0.998];
	NEURAL_HAM_MEDIUM(-0.97)[-0.973];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_HAS_DN(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	RCVD_TLS_LAST(0.00)[];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::332:from];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	FREEMAIL_FROM(0.00)[gmail.com];
	MID_RHS_MATCH_FROM(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]
X-Rspamd-Queue-Id: 4NnMCB6wbYz3D7Z
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N



On 04-01-23 11:24, Konstantin Belousov wrote:
> On Tue, Jan 03, 2023 at 11:38:55AM +0100, Floyd, Paul wrote:
>>
>> On 30/12/2022 01:54, Konstantin Belousov wrote:
>>>
>>> The backtrace is needed to make a further analysis.
>>
>>
>> Any suggestions for getting a backtrace? I get the panic booting either the
>> installer ISO or the VM image, both in VirtualBox.
> It should be there right after the panic message.  No idea how to take the
> virtual screen snapshot under VB.
> 
> Also it might be easier if you configure serial console and catch its output
> outside VB, but again I have no idea how to do that.

You can connect the vbox vm serial output to a hist pipe.

Here is the start of the panics

smist: found supported isa bridge Intel PIIX4 ISA bridge
panic: td 0x1d94840 stack 0x2424ee8 not in kstack VA 0x2420000 4
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self_wrapper(0,1d94840,4,2424000,9,...) at 
db_trace_self_wrapper+0x28/frame 0x2424e9c
vpanic(1491c57,2424ed8,2424ed8,2424f9c,1415b35,...) at vpanic+0xf4/frame 
0x2424eb8
panic(1491c57,1d94840,2424ee8,2420000,4,...) at panic+0x14/frame 0x2424ecc
trap(2424fa8,0,0,0,0,...) at trap+0x975/frame 0x2424f9c
calltrap() at 0xffc0321f/frame 0x2424f9c
--- trap 0x9, eip = 0xa02, esp = 0xffe, ebp = 0 ---
KDB: enter: panic
panic: td 0x1d94840 stack 0x2424d90 not in kstack VA 0x2420000 4
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self_wrapper(0,1d94840,4,2424000,3,...) at 
db_trace_self_wrapper+0x28/frame 0x2424d44
vpanic(1491c57,2424d80,2424d80,2424e48,1415b35,...) at vpanic+0xf4/frame 
0x2424d60
panic(1491c57,1d94840,2424d90,2420000,4,...) at panic+0x14/frame 0x2424d74
trap(2424e54,8,28,28,100,...) at trap+0x975/frame 0x2424e48
calltrap() at 0xffc0321f/frame 0x2424e48
--- trap 0x3, eip = 0x1042444, esp = 0x2424e94, ebp = 0x2424e94 ---
kdb_enter(1527748,1527748) at kdb_enter+0x34/frame 0x2424e94
vpanic(1491c57,2424ed8,2424ed8,2424f9c,1415b35,...) at 
vpanic+0x11f/frame 0x2424eb8
panic(1491c57,1d94840,2424ee8,2420000,4,...) at panic+0x14/frame 0x2424ecc
trap(2424fa8,0,0,0,0,...) at trap+0x975/frame 0x2424f9c
calltrap() at 0xffc0321f/frame 0x2424f9c

From nobody Thu Jan  5 02:59:32 2023
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 4NnWQv6qd2z2p106;
	Thu,  5 Jan 2023 02:59:35 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NnWQt330qz43L9;
	Thu,  5 Jan 2023 02:59:34 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=Azg6RHQj;
	spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::92b as permitted sender) smtp.mailfrom=grarpamp@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-ua1-x92b.google.com with SMTP id j14so765039ual.10;
        Wed, 04 Jan 2023 18:59:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=+huZeC8RyRLKcJCpfVjxpNuaohqbt541afXmnOzISR0=;
        b=Azg6RHQj5ENGlZ0iT31eWZeVdwG+hGSX1b8dJNvzpYs7PeW+mVj3rYvQr/BYggOoZV
         0xvStndv9YPj/Wjt6fjV+K59SjhCNIfIBovPYDuW4RpksDzezqkfzvXLYRB5jIpcrE4a
         xlzH36vsnISQuxsx3LHDkX3oIIQgwiK+LhGicFquVSid//ahmit4asWAZOfzEM+7RR6S
         QJzmoKiXHQiyNSET4CwjKu/s6tB4c++/3Ws7saX92j1oXn3I/zQoUVsOdb7xkE8WWUaT
         upRbLc7s7jDlis7pf3RCRSbl6Zh+LfMjG8V8LxVDn3Oo29pKCB9xFiY7pDEU3O0HC7TH
         a2iA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=+huZeC8RyRLKcJCpfVjxpNuaohqbt541afXmnOzISR0=;
        b=v5P1GD9INZWVmUox0AJ8Ft96ppjfkw0cOkFVctbPj50kbhJh1bqwXbLXl4peZTmiT+
         aUvbl0/tn73NqrxbZlI90PaGJ+2YRoiwDBKbR+AdxX5cmOzOFDzzuyuypLC8w74RxXM8
         g3Sm2dUmn0Mbby66HXo6jnWXkEiIgs9EqCDpBxYDlxfunCrwRWna7Dmyj3KX5yW6F/xm
         OawIxAcGBG9ZZHlH+dK9nvxsgfePE59L7R+LwZ48ZxzNc3mrWbXvFUOy+sxSYhs+txQN
         Sa7lw7uzExKE725pgGKCQBvwsw4DmTaOihNKgJYmErdEnOLDNRP1w6djIZvvKy5Ge8Aj
         z2Yg==
X-Gm-Message-State: AFqh2krYzhBl956Fyxef0Tn2B7Pit42QpexhpPD7SApsfe/O1qBwLX/A
	B5etFSWD+kE4yxdG8RPzrOw+1m1QVm3o+AQq3h5zhFk7DRnZB3uwSbs=
X-Google-Smtp-Source: AMrXdXu8xTH9L7XvFaPeosmvllbjL4V83zxoBfdJZuehNXm1ZQ0GZiRIREMTCvzZdziNvHbcEZRo9navaKDYe79x/h4=
X-Received: by 2002:ab0:6544:0:b0:553:bde4:42f5 with SMTP id
 x4-20020ab06544000000b00553bde442f5mr1837345uap.67.1672887572959; Wed, 04 Jan
 2023 18:59:32 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Received: by 2002:a05:612c:1190:b0:374:fe0f:8b62 with HTTP; Wed, 4 Jan 2023
 18:59:32 -0800 (PST)
In-Reply-To: 
References: 
  
From: grarpamp 
Date: Wed, 4 Jan 2023 21:59:32 -0500
Message-ID: 
Subject: Re: cant login after make installworld: pam_opie.so.6 not found
To: freebsd-current@freebsd.org
Cc: freebsd-security@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Result: default: False [-2.39 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.976];
	NEURAL_SPAM_MEDIUM(0.59)[0.588];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-security@freebsd.org];
	ARC_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92b:from];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-Rspamd-Queue-Id: 4NnWQt330qz43L9
X-Spamd-Bar: --
X-ThisMailContainsUnwantedMimeParts: N

>> looks like the "make delete-old-libs" has deleted that lib pam_opie.so.6
>> and now I cannot pass the login prompt
>> says the error "pam_opie.so: not found

>> how can I get it back? I tried everything and nothing brought it back

> commit 0aa2700123e22c2b0a977375e087dc2759b8e980
> Differential Revision: https://reviews.freebsd.org/D36592

This appeared as perhaps an arbitrary deletion change for some
unknown non-discussed reason. Someone else posted the problems,
user features, and alternatives that would preserve and update use of
OPIE options for FreeBSD users, but again, no one discussed.
So now users are getting locked out and have one less security
option available to them in FreeBSD.

https://lists.freebsd.org/archives/freebsd-security/2022-September/
https://lists.freebsd.org/archives/freebsd-security/2022-October/

There is still good opportunity therein to restore some
implementation of it for FreeBSD.

Welcome to 2023 :)

From nobody Thu Jan  5 08:07:04 2023
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 4NnfFm0CZsz2r0Xw
	for ; Thu,  5 Jan 2023 08:07:08 +0000 (UTC)
	(envelope-from grahamperrin@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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NnfFl6bB5z4X81
	for ; Thu,  5 Jan 2023 08:07:07 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1672906027;
	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=b1Lq++S8gNo99tPh4IZzBCVNHxD3+aJuIitrAjDpq0E=;
	b=AC9oAZna5mOm8ISEvzlaPGQgNVfqLwxraU4WkIOxTaHPe+6nqYkPQF9Hp30Fn5UISXfQL+
	nYdTo0S+78RyAwnjnFCXF2Pw5cStW3p0EDALaP0X+zri8FYH3HyaVeIP2mVGY/LYkvLgSd
	ms/N2wBn3nz2ybCYhwJjfp96F/wSbxUWFmO7/izygtoPoGyZWtCyEJvkEOTqIJGtiKUncy
	0g6qn7Eq9fpPVWLtP+PlezgvbibfbKGK4gcoFDKG7ZGWjWFzdTTdhQEZRMhi11aPPOFLE5
	F8CWvQ2mJe81PmhwYc6is/DLWjK/ZUjDow7tJXSyFonMtxlu7vD2+gLUGtHtVQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1672906027;
	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=b1Lq++S8gNo99tPh4IZzBCVNHxD3+aJuIitrAjDpq0E=;
	b=oOby96/T83Uc9dvmh0dwjVEP/nFct9UAGrasybcXJN+Bctg43dn9DGuMq4qOsV1w6f1UDR
	8nLPQU1AnZioCC+/9ee8mXqmCHYDIVPi9rrEuQJpga6LkXzLXSatlGbRovh1dFZ1yJNOux
	BmaOrzl72UdORZhVYIRB7tzSs4pjkM3S+M7PpthGvlla/QNF/5YjIimGa6arCfRZrXXK2S
	UK54iaKyZICl40JC6JGhhwsp+rGqAXEXrCoFp5Ua75zschWrfirEbrEfIf24aySTBsKe/2
	P3+gDWMvFQv3Rl4fwKxP5Kq4qmcOREDxw9djW/YwwaIbGlCTMZxRWoK/lCVCTQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1672906027; a=rsa-sha256; cv=none;
	b=RQgVO1qYe4dXds8e3SuRYpIBoiMWMfecHjzk84LTNg8gXD4gNZpCWV98/O0eDELLxnNH6L
	3CAaDYsw4iu3kXfB9okuCLIfTduZWQZSj+sqQKmbIMFNph8y2wIPTGcx2EKZghr9oeSNy5
	drRfX8o8zA97qqHEK57aenfx8uLNThB8arV7A8fKlYVQ1UPmgp3jPxenSNl09exX1fCIz1
	sqGEaCqATkaLPTvvajoJRRb7eBOI+L5g24mSAVU5wm94NgffhlDZWxsTpt8anWDdIyPh51
	myGa0K4+skfuSWSkI/VcYKhWbZp05CGOtCV5WsW2TOi0s9lnLWnDof3QYM8G1w==
Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2])
	(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: grahamperrin)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4NnfFl3wvzzdMv
	for ; Thu,  5 Jan 2023 08:07:07 +0000 (UTC)
	(envelope-from grahamperrin@freebsd.org)
Message-ID: <6373b14e-5fbc-7b09-e385-c7286ac9d3d8@freebsd.org>
Date: Thu, 5 Jan 2023 08:07:04 +0000
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Putting OPIE to rest (was: Re: cant login after make installworld:
 pam_opie.so.6 not found)
To: freebsd-current@freebsd.org
References: 
 
 
 
Content-Language: en-GB
From: Graham Perrin 
Organization: FreeBSD
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------7RT0hA2jP3eTcMM7GH3t7u0M"
X-ThisMailContainsUnwantedMimeParts: N

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------7RT0hA2jP3eTcMM7GH3t7u0M
Content-Type: multipart/mixed; boundary="------------Lq0g3Dn6cJjUsHUIkUsE8PGm";
 protected-headers="v1"
From: Graham Perrin 
To: freebsd-current@freebsd.org
Message-ID: <6373b14e-5fbc-7b09-e385-c7286ac9d3d8@freebsd.org>
Subject: Putting OPIE to rest (was: Re: cant login after make installworld:
 pam_opie.so.6 not found)
References: 
 
 
 
In-Reply-To: 

--------------Lq0g3Dn6cJjUsHUIkUsE8PGm
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gMDUvMDEvMjAyMyAwMjo1OSwgZ3JhcnBhbXAgd3JvdGU6DQoNCj4g4oCmDQo+DQo+IGh0
dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvYXJjaGl2ZXMvZnJlZWJzZC1zZWN1cml0eS8yMDIy
LVNlcHRlbWJlci8NCj4gaHR0cHM6Ly9saXN0cy5mcmVlYnNkLm9yZy9hcmNoaXZlcy9mcmVl
YnNkLXNlY3VyaXR5LzIwMjItT2N0b2Jlci8NCj4NCj4g4oCmDQoNCkkgcmVjYWxsIHRoZSBv
cmlnaW5hbCBlbWFpbCBhZGRyZXNzaW5nIHRocmVlIHB1YmxpYyBsaXN0cyAoYXdhcmVuZXNz
IA0KYWNyb3NzIGFuIHVudXN1YWxseSBicm9hZCBhdWRpZW5jZSk6IC1jdXJyZW50LCAtaGFj
a2VycywgYW5kIC1zZWN1cml0eS4NCg0KPGh0dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvYXJj
aGl2ZXMvZnJlZWJzZC1jdXJyZW50LzIwMjItU2VwdGVtYmVyLzAwMjU2NS5odG1sPg0KPGh0
dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvYXJjaGl2ZXMvZnJlZWJzZC1oYWNrZXJzLzIwMjIt
U2VwdGVtYmVyLzAwMTQ3OS5odG1sPg0KPGh0dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvYXJj
aGl2ZXMvZnJlZWJzZC1zZWN1cml0eS8yMDIyLVNlcHRlbWJlci8wMDAwODEuaHRtbD4NCg0K


--------------Lq0g3Dn6cJjUsHUIkUsE8PGm--

--------------7RT0hA2jP3eTcMM7GH3t7u0M
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmO2hSgFAwAAAAAACgkQt2dIb0oY1Avo
hA/+ImID2BkRA7lI7g7dqmOLXyf0gjvbK80W35+p4A8rT1MTbiS5dvNi9RKkKhaivlpUgUbDVf6q
bfN2r0iPe/ayEUof7XaiMRgwkbjDErRACzh0WmUWB5bSFnCW0GjNNQYlbV1goQ8al9e4bfw3A+WM
gyDL1DUxk6WLArVBMtRhLkcyYedXcr5mUh7GFfSYbusEAvyTIkbQKv/NaVGXEtXTl1JgUaWz4eQm
PqTq2kJNsT530vdH9IiIqdsMW67N1bFDDGUiJiJohog5OAs67rjtZrmBK6l78Wrro68we9a3LRXS
DyLZUAw9RwlSRpBY1mOS3poiIsqmyK/bn8ZrYIsf/avooT9O/ba7ryIuy0ce24BX7nACsUh15bkQ
9RuF4eWlWPddupL2H4I/bTJ+ZeImxTLXU/4mY+DvSR9JYnOeHcQ2RDk2SWdReiY4j2sB0JpwSlws
oJf50fqnI9Dd3ARvhV3GhrP3K/NSRT5l5ToaM+0UJBdeU7G3td3eW0iuDpqqiXssA7sbQShs5FO/
hxpvFbqw8kF6abkmMdQvgg94BwlJP7PflgpzGZpcvYFCBk/NJYqPKRDHu3DRfYRlnW4DCG9Ftybr
7tRywJc13xZRnQ/uwKLyRrVjod2XrQYeJ3i9Rt+rbPzPsr1ACXfZtvsylqYZdFoxBThZ0xt1Nu07
ag8=
=Zai2
-----END PGP SIGNATURE-----

--------------7RT0hA2jP3eTcMM7GH3t7u0M--

From nobody Fri Jan  6 03:49:40 2023
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 4Np8VH3Xtvz2pPWn;
	Fri,  6 Jan 2023 03:49:43 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Np8VG5dbdz4Hbc;
	Fri,  6 Jan 2023 03:49:42 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=K++kXLlf;
	spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::e30 as permitted sender) smtp.mailfrom=grarpamp@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-vs1-xe30.google.com with SMTP id o63so392080vsc.10;
        Thu, 05 Jan 2023 19:49:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=i1EpVsONavu6cMlcPhJsrBT0V7CIsc3rXZercKZOSRk=;
        b=K++kXLlfJY6FKD1uX2U+IwUBtV0KH3ZGoCGQWWscap+VBMdwJ22KGbEBCpidG1HxLC
         lp2VsF5vLqhcIfyK4qdXFMwOiogHTMqovM1xwNfFp75VW+2aQ+VVZlROSkK+KrtCLNk/
         KFNBpsYN67PZ3lXfWbfDhMlgUh+vQcfLzse7QiiZRO2PHhQ4HPfDxg4gdfGyMZ1kA9wG
         9vCWYPi/Pi31ZT4NlHk5eOi3+oFHkL2zizHFH+DhPri6899HxRTRnWWPXyCZi2KOGDMD
         APJ5INtKNIUTveb6FgkM9qszcUed38M2sSuqxSr+t4z7qTz6vqZtCe0hBiLX9kfFNs1e
         kF0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=i1EpVsONavu6cMlcPhJsrBT0V7CIsc3rXZercKZOSRk=;
        b=0uG+uk3aRABsiiPwF/MX7WwvIrXsy27atDPtPBCUhErupAq2cMcCepRzVrzIKv18nf
         aiyMtJhB4sznl1W2T0DUHnxlHW+Zh9Vk7qt/72hYor+kCrdC8LQJx56GFNluimEGXO9L
         gwq04vjPlz8927bPf0Vlyvu6+eDLSHhG3Hw/WPc0GZ3kjEL2Y3K+ihgC10vjuByu4ZuK
         p0Jh3xwZuk6AOzclMWbkv7IFD080wVThZuDWdbAQP+XjvvRqc/lWPSi8tY+3VdtUyhah
         gzNVuDZHiP+Bzd2UjtpYqV4CfEIOE28qWxULznK5ogYvDd2RpooMxjf0Euz8+vgSb9jv
         eyCg==
X-Gm-Message-State: AFqh2kqojeSJ9f8oNizj8V+yBTrihGBdcN6U4zMoJLnU7vXDD9e4ENLC
	z0loa/H7zwTD+geLiONNcMzHM0aL7mQixlSBhlraD6Y3sYgLLkhX7LE=
X-Google-Smtp-Source: AMrXdXvWbveg6rX1UtTXAiA3ofPS10oI616VNxNFRCrRjaAdNswfbVll4/44i1zQmaWxxRUuI4E8lp4lPu+8++26d78=
X-Received: by 2002:a67:fb5a:0:b0:3c7:9cb5:5980 with SMTP id
 e26-20020a67fb5a000000b003c79cb55980mr4654527vsr.44.1672976981411; Thu, 05
 Jan 2023 19:49:41 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Received: by 2002:a05:612c:1190:b0:374:fe0f:8b62 with HTTP; Thu, 5 Jan 2023
 19:49:40 -0800 (PST)
In-Reply-To: <6373b14e-5fbc-7b09-e385-c7286ac9d3d8@freebsd.org>
References: 
  
  <6373b14e-5fbc-7b09-e385-c7286ac9d3d8@freebsd.org>
From: grarpamp 
Date: Thu, 5 Jan 2023 22:49:40 -0500
Message-ID: 
Subject: Re: Putting OPIE to rest (was: Re: cant login after make
 installworld: pam_opie.so.6 not found)
To: freebsd-current@freebsd.org
Cc: freebsd-ports@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Result: default: False [-3.99 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.997];
	NEURAL_HAM_SHORT(-0.99)[-0.994];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	MIME_GOOD(-0.10)[text/plain];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org];
	ARC_NA(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e30:from];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-Rspamd-Queue-Id: 4Np8VG5dbdz4Hbc
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On 1/5/23, Graham Perrin  wrote:
> I recall the original email

Orthagonal as it, and some notes since neither consider any
potential gap issue or/of any perhaps whimful removal process,
nor moves forward on any of potential better alternatives to that
which were hint (port) a bit in posts even before the removal was taken.
Opie is not some hi-maint lo-api-compat legacy driver holding back
kernel dev, it's a tiny stable user app plugin that just works for decades.
Now users are posting locked out, punted to deploy non-replacements,
and can't even compile it back because code gone from trees in use.
There was hardly reason to remove it (lots of other things could be
considered "outlived usefulness" but don't get removed), and even
if so (as perhaps part of say some larger discuss on pam), there
was zero reason for the removal team not to portify it given
FreeBSD has already set good example of moving even
large/complex user apps from base to ports.
That should have, and still should be done, with opie.

Consider on that process for future,
rather than whatever is thought of some app.

Cheers.

Cc: ports, as the lo-maint hi-api-compat opie could also be
used to +1 their competitive 35k count :)

See also compat{M}x-{arch} packages.

> https://lists.freebsd.org/archives/freebsd-current/2022-September/002565.html
> https://lists.freebsd.org/archives/freebsd-hackers/2022-September/001479.html
> https://lists.freebsd.org/archives/freebsd-security/2022-September/000081.html

From nobody Fri Jan  6 06:57:45 2023
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 4NpDgQ3xMCz2r4tZ;
	Fri,  6 Jan 2023 06:57:54 +0000 (UTC)
	(envelope-from delphij@delphij.net)
Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212])
	(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 "anubis.delphij.net", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NpDgP21xcz3KxD;
	Fri,  6 Jan 2023 06:57:53 +0000 (UTC)
	(envelope-from delphij@delphij.net)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=delphij.net header.s=m7e2 header.b=esl2CHK9;
	spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 64.62.153.212 as permitted sender) smtp.mailfrom=delphij@delphij.net;
	dmarc=pass (policy=reject) header.from=delphij.net
Received: from odin.corp.delphij.net (c-141-193-140-184.rev.sailinternet.net [141.193.140.184])
	by anubis.delphij.net (Postfix) with ESMTPSA id AC38F3B41A;
	Thu,  5 Jan 2023 22:57:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=m7e2;
	t=1672988265; x=1673002665;
	bh=L9D4PF4c8ykSXWDxi56gFia95kyFNk+j+g5eAbPHAMI=;
	h=Date:Reply-To:To:Cc:References:From:Subject:In-Reply-To;
	b=esl2CHK9Zg3UJnl9qrDjaaX3MZmP65Dd2ElrkYnZI2Pr/lAdSi2O/c+tOyJhw2qCu
	 dPwu24meMdqT7rRZSbsYC0Ap9bayTwk8mM6W6OquLm/27tTBl3+WuydMM4RTI5wALB
	 iYb77sJXLqIqKS5JOJLNeU5zbss86QMa2N9qNJdQ2TDMIgx/CenXiivJxRHkRnIl9J
	 9AThPbd5l7lhhm2ysBjNezfw8uXVsrudoBdFz4MUEX79dkMmaBWND0sbwhP+0wSxnd
	 iSkmEF9bOXi2dTPVKsfwxCJQnkca52jW0ArWktYMiMT+sFvIx6rYKUTKlSgf3Px5Nh
	 b34og+a3kkVMw==
Message-ID: <44346488-85be-825c-4a42-1de3f701c3f4@delphij.net>
Date: Thu, 5 Jan 2023 22:57:45 -0800
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
User-Agent: Thunderbird
Reply-To: d@delphij.net
To: grarpamp , freebsd-current@freebsd.org
Cc: freebsd-security@freebsd.org
References: 
 
 
 
Content-Language: en-US
From: Xin Li 
Subject: Re: cant login after make installworld: pam_opie.so.6 not found
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spamd-Result: default: False [-3.99 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2];
	MIME_GOOD(-0.10)[text/plain];
	XM_UA_NO_VERSION(0.01)[];
	FROM_HAS_DN(0.00)[];
	FREEFALL_USER(0.00)[delphij];
	RCPT_COUNT_THREE(0.00)[3];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	REPLYTO_DOM_EQ_FROM_DOM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-security@freebsd.org];
	HAS_REPLYTO(0.00)[d@delphij.net];
	MID_RHS_MATCH_FROM(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[delphij.net:+];
	TO_DN_SOME(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ARC_NA(0.00)[];
	FREEMAIL_TO(0.00)[gmail.com,freebsd.org];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US];
	RCVD_TLS_ALL(0.00)[]
X-Rspamd-Queue-Id: 4NpDgP21xcz3KxD
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On 2023-01-04 6:59 PM, grarpamp wrote:
>>> looks like the "make delete-old-libs" has deleted that lib pam_opie.so.6
>>> and now I cannot pass the login prompt
>>> says the error "pam_opie.so: not found
> 
>>> how can I get it back? I tried everything and nothing brought it back
> 
>> commit 0aa2700123e22c2b0a977375e087dc2759b8e980
>> Differential Revision: https://reviews.freebsd.org/D36592
> 
> This appeared as perhaps an arbitrary deletion change for some
> unknown non-discussed reason. Someone else posted the problems,
> user features, and alternatives that would preserve and update use of
> OPIE options for FreeBSD users, but again, no one discussed.

Security team has discussed this a decade ago.  See 
https://www.miknet.net/security/skey-dungeon-attack/ for technical details.

And this could have been avoided if user have followed source upgrade 
instructions by performing mergemaster or etcupdate *before* make 
delete-old{-libs}, which is well documented in /usr/src/UPDATING and I 
quote it here:

	To upgrade in-place from stable to current
	----------------------------------------------
	
	make buildworld                                 [9]
	make buildkernel KERNCONF=YOUR_KERNEL_HERE      [8]
	make installkernel KERNCONF=YOUR_KERNEL_HERE
                                                         [1]
	                         [3]
	etcupdate -p                                    [5]
	make installworld
	etcupdate -B                                    [4]
	make delete-old                                 [6]
	

The order here is very important.

Cheers,

From nobody Fri Jan  6 10:36:02 2023
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 4NpKW93FWpz2pKqZ;
	Fri,  6 Jan 2023 10:36:05 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NpKW841L1z45NQ;
	Fri,  6 Jan 2023 10:36:04 +0000 (UTC)
	(envelope-from grarpamp@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=fzERyNDB;
	spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::e2a as permitted sender) smtp.mailfrom=grarpamp@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
Received: by mail-vs1-xe2a.google.com with SMTP id 3so1065509vsq.7;
        Fri, 06 Jan 2023 02:36:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=qgM5CNO2fp3bcmZD9soYiAaVuYStM98JbVZUP2mvwSA=;
        b=fzERyNDBxnLTlnc5hOYoZIOAs7wa2ggQXkXVzDLeN++X/S10RDhyOHjYL2PIs/yN5i
         UvwxtGAnlLMdWVBqPaiLDUlNWkSWXZoUe3EnQtmMcPlsv9hg+hNLp119Gh6maWLAmbQa
         trVDjve24dvjW+iBh2f8WSIugrvMDaVGzt7T2IFWQ3ST9ufFGOeaMevJBIugR5ls1Mv0
         uFzIV1EzlkCcfFfSPpFDRej/NWepCvcZ899g5RBLy3bj2zvLg8gzrw4ADuZJ0MpFOfyZ
         /y1hDpuabc0Fs84l7gTL8gUvrXfm/Zy3TTrilT9RxOy+c+RK7gNaBFTJI8ClZxhsusRj
         5B2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:references:in-reply-to
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=qgM5CNO2fp3bcmZD9soYiAaVuYStM98JbVZUP2mvwSA=;
        b=KpwY6Jao9LcgOYBxprCbMmB7a6V2u/v25Ed3QCr8Wp1hgHENZTlsBHl84I4uvlCz+A
         U/t4nxGnfpOUzQ7T0m0YTPC0B02PXrjeCNIfGdJHmtEoMZp6g+BNHR9CB+PWWs/lAzSO
         cnohBhuWuyGjTezyrXfVXTpcknoaSdArTNVhF/UkC0xwZXMkBkVsfvgR8aRpUbKIHwNK
         A9TV82zoXiiVrgXOqk7zXJsx8Ye8uGbo3OpQjcr+4igIbXHi0jRYgTALWDq3wcDEI6ct
         4Nue7wT234mE04RgMmqPQ4GsLBpLtekj/oxEbAEtoUytXW+i9S0tBiC3P4pyWCkbBXIS
         PfqQ==
X-Gm-Message-State: AFqh2kpuzbIItMPA0no/wpflopMusdjhdrTm6XvFm7Jichyz0LXSvNSF
	L1uJfU24dY2Wwd1ucR3LrERoMI6apnkS+jHEoAa1tSCC4pEbHISrxno=
X-Google-Smtp-Source: AMrXdXsL8ojQxGty9QU+7vMpDpPbgtwdwDmF2x5x4kjz0WtBi60NUfMfoCvyLqM6QY7hPAIh0uZfuV92sa6xH0iWW6Q=
X-Received: by 2002:a05:6102:2757:b0:3b3:5fe5:e22 with SMTP id
 p23-20020a056102275700b003b35fe50e22mr6211076vsu.55.1673001363360; Fri, 06
 Jan 2023 02:36:03 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
Received: by 2002:a05:612c:1190:b0:374:fe0f:8b62 with HTTP; Fri, 6 Jan 2023
 02:36:02 -0800 (PST)
In-Reply-To: <44346488-85be-825c-4a42-1de3f701c3f4@delphij.net>
References: 
  
  <44346488-85be-825c-4a42-1de3f701c3f4@delphij.net>
From: grarpamp 
Date: Fri, 6 Jan 2023 05:36:02 -0500
Message-ID: 
Subject: Re: cant login after make installworld: pam_opie.so.6 not found
To: freebsd-security@freebsd.org
Cc: freebsd-current@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Result: default: False [-3.39 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	NEURAL_HAM_SHORT(-0.39)[-0.387];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	MLMMJ_DEST(0.00)[freebsd-security@freebsd.org,freebsd-current@freebsd.org];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2a:from];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	TO_DN_NONE(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-Rspamd-Queue-Id: 4NpKW841L1z45NQ
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

On 1/6/23, Xin Li  wrote:
> Security team has discussed this a decade ago.  See
> https://www.miknet.net/security/skey-dungeon-attack/
> for technical details.

That would mean that FreeBSD knowingly left users exploitable without
doing even the "easy fix" in that article to the opie code for over a decade.
And further left opie vulnerable and present since the commit in all RELENG,
STABLE, and handbook. And did not issue a SA on it since the commit, nor
ever since the article. If attempting to claim security as reason to delete,
then FreeBSD might appear to be faulty of this. Which would present good
opportunity to consider any potential improvements to that process too.

> And this could have been avoided if user have followed source upgrade

Lockout avoided... yes maybe if users wanted to quit their opie forever
at that moment, but if not, then opie code module hasn't yet been
moved to ports for anyone to use and or update as they wish.
The nature of port security in every unix OS is 3rd-party and un-dedicated,
so that wouldn't be reason not to port such things either.

Onward :)

From nobody Fri Jan  6 12:56:44 2023
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 4NpNdV1crtz2qsTW
	for ; Fri,  6 Jan 2023 12:56:46 +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 "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NpNdV0tfpz4Jv0;
	Fri,  6 Jan 2023 12:56:46 +0000 (UTC)
	(envelope-from des@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1673009806;
	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=uBjptD/YocfulNALpSyR3kepSq6SIBlMfFbaruluHeE=;
	b=WQ2naiEncVMu6QV3Zf+JcMflHRnCy9Y3hXveD0q02KBOVpsVQsYhOA4e/JbfBjjsbQ/P5u
	AkAO3/qFV6mFlQ6KmhyKyG8gDRezt+FC3iC8zlU/iIfSDGbLFQhubZD/NColfwpmLf/6YH
	P5iyMYl0bV4Xha//Ne46C7YNNaSF+CvTtBJ9qbHnpAvvxqO9csxPGuu0q/glGRCx7TDBi4
	po13oasEBxn4E3rOfz/VelogyQzMhSH99BuIsuNwiUzcD9ruUp9tYZ6wMA2ZXwKQrpy2ls
	bbbT8mZga8mlsonKAIorklZ6NXPtFAhngHHR2knPp/+4eeJ5n25ikkPJ52g2cw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1673009806;
	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=uBjptD/YocfulNALpSyR3kepSq6SIBlMfFbaruluHeE=;
	b=oOAkvTdFpyTQlvom3sCDXltQNtvQ9Dp2tRcGnUvNuCDFmBIKiL9v59VwvSCIi1KETffCjO
	mP3CCnfvFLyYZ3Oj676Y9djgaiGPSHEV/68Sd1lHaUOKOXfqD8+zqOCiYwVgbMkM5U1vjl
	xUo4T3Dc8GvIyyI4hUECAzhQWbobwd/tjrvlHWuDH9zit0XelUgmKTxpQmkBUkbzIi699h
	3Y4FKmszy51/6hhcXZZctBR56xWi9++mZ5xpZEKmd5PstpyC5hA20y0Obm+Aawll/Uyf0Y
	uh9Js5PEeQcSOluGfVjAH5zFRbIugVTPWgDeagTwGFbW0qvGVbsO87UmR31nsg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1673009806; a=rsa-sha256; cv=none;
	b=lo9hS0NDCE/mZjwgQsOucFI0JvP9ramlk7Lt+xovfZdko+qGNGxiz7JMcgTcMSZZS/ugSk
	4StQWlmT0D+LxZxqHdEzPH8vla/1bL/1yVd9Q9Eh7qgIOhOQMB/hpteuhIh2VQazOclHJ1
	b9Cbks7q6Z0afaPlYPBswTm4wqD+lzkmVPxnOeJfSLBasluOQuqZfCzT78JcuDVBTqOFs8
	NKRzvFgWn4zP6UPCqvq7zcSc0YQLbUpB2RfMEE5I7fuRiaOtnKjLriDOKHyNVdhIq4DWzh
	rvcpI/e5l/VWCCf42ZXafURkDhsOqhZJKSZOkZ6agoId8cnD5gQsidFiwLXivA==
Received: from ltc.des.no (unknown [178.232.227.131])
	(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 4NpNdT698Fz1B2W;
	Fri,  6 Jan 2023 12:56:45 +0000 (UTC)
	(envelope-from des@freebsd.org)
Received: by ltc.des.no (Postfix, from userid 1001)
	id 2721861C84; Fri,  6 Jan 2023 13:56:44 +0100 (CET)
From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= 
To: Ivan Quitschal 
Cc: Marek Zarychta ,
  "freebsd-current@freebsd.org" 
Subject: Re: cant login after make installworld: pam_opie.so.6 not found
In-Reply-To: 
	(Ivan Quitschal's message of "Tue, 3 Jan 2023 22:17:01 +0000")
References: 
	<6f85c1b2-91ed-f02c-bbaf-65e10cf36bbc@plan-b.pwste.edu.pl>
	
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix)
Date: Fri, 06 Jan 2023 13:56:44 +0100
Message-ID: <861qo73joz.fsf@ltc.des.no>
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-ThisMailContainsUnwantedMimeParts: N

Ivan Quitschal  writes:
> I had to "install" the new temporary /etc/pam.d files with mergemaster. I=
 think the problematic file was
> the "system" config file. Now its all fine

If you wish to continue to use OPIE (which I don't recommend), there is
now a port (security/opie).  You will have to manually add back the
pam_opie and pam_opieaccess lines in the relevant PAM policies.

DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org

From nobody Fri Jan  6 13:38:21 2023
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 4NpPYn6L8Yz2qy9G
	for ; Fri,  6 Jan 2023 13:38:37 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Received: from BRA01-ROA-obe.outbound.protection.outlook.com (mail-roabra01olkn2045.outbound.protection.outlook.com [40.92.96.45])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NpPYn3JDyz4MsN;
	Fri,  6 Jan 2023 13:38:37 +0000 (UTC)
	(envelope-from tezeka@hotmail.com)
Authentication-Results: mx1.freebsd.org;
	none
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=RBSHWdV6tx9dNI3TfZ0bub3Aiay2PrEn5DFQLCIOI6RYJhxU8zsZkPIzUjQDNsTE6M0x+d0yQpodEFpl9DbouB+4OZOwYxrhZFE8nhOwBr9mssd19ey5hDD4tRoqI9om6cFNtda1pmtf25a4qwBAoseWLXOyhiTY9vJbgY//GmiNe7HJBH0DOVSSSBnGFEmDi9fOn1/ZuoeoASoKeq0JE57kTjfLupQcyOv5xcrErWXaBA5wsh7LlJ/KwNDOWzgCf18VcQ5yb7ykNt8WR/PWHGhuBeh6R9nsVypwOFriMkq6BCZl6BfdbA7D0tWr/azekazzOYCsr97YZxS9LwS0fg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=J32WjKifu0l/TWL5ViGyYOSKo6V9IefgDGYLB6dhj6I=;
 b=YBWu4+pHgaH2X8lWfIH+kEWR/tWUMc57qWGCqRMznXIxybb7CmZki+3t/Qsuj+H48LKL1u0YNWSYkWK3n4gTl3Bf4ujGRkvgfqb6/eNJraJMLYWPtqLXfLnMvo865T6Io6lu/slIqyOL/5Ts2L2OCfP6yHmjqDPxo8JRQCk6O8WYrQbZXHr2O/UnUxEWFF2tG7NdG9Jh63hR/GGXaMkyYRXfTU9FUeswqp+P7GCm/UiJ8DlWrCfCwh0GCVjAbL6OLmuEIKmgQpX6LXkhlXmG6EVW94n2U18akeqgBrlW/LTY0dwI9SoJUBZYruaRbjL9MDwBcBr1yL1VgE7BtyPO+w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=J32WjKifu0l/TWL5ViGyYOSKo6V9IefgDGYLB6dhj6I=;
 b=Y3+SRJLdTtCLH5yWHn9Zo3CPUjAzUMY7rKD5ayYLPgGKa+BDvuJPxlfabgWWqM5rFpcWmGeC61zltc4IaIjgRTTs5FGhIot5pY/AgIXea30wDJ+UA+fwfU2pavpR4r23JUHOsIxPZLiiwjBOvUwo/MAysoSNVTLv3WV3U2cwQ8iitZ8bG4xS0kwTi9mPUKyhQfPDeXmc9Y+ndyxILyWxYaRQxldUNIKzTN5wKcmWLKefQeJkONiBU6OfszS1JgYI9AfIKhKLYUu7MfdQ9elDEUTIzq4gpiM4y+dNwj9TJT0WC8BT9lYKpp2uT1wQ40QVZ051nnQRflrtzKlyyusb1Q==
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:118::12)
 by CP8P284MB2066.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:1e2::10) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5944.19; Fri, 6 Jan
 2023 13:38:33 +0000
Received: from CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::42aa:25c0:1211:33a8]) by CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 ([fe80::42aa:25c0:1211:33a8%9]) with mapi id 15.20.5944.019; Fri, 6 Jan 2023
 13:38:33 +0000
Date: Fri, 6 Jan 2023 10:38:21 -0300 (-03)
From: Ivan Quitschal 
To: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= 
cc: Ivan Quitschal , 
    Marek Zarychta , 
    "freebsd-current@freebsd.org" 
Subject: Re: cant login after make installworld: pam_opie.so.6 not found
In-Reply-To: <861qo73joz.fsf@ltc.des.no>
Message-ID:
 
References:  <6f85c1b2-91ed-f02c-bbaf-65e10cf36bbc@plan-b.pwste.edu.pl> 
 <861qo73joz.fsf@ltc.des.no>
Content-Type: multipart/mixed; boundary="3432851520-228389938-1673012310=:1798"
X-TMN: [UOt9L+JykSBt83oTR3GRAtCdOPPJ0gsI]
X-ClientProxiedBy: CP6P284CA0050.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:1ab::16) To CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
 (2603:10d6:103:118::12)
X-Microsoft-Original-Message-ID:
 <34832514-d092-7cb3-7e48-7e4089628aad@hotmail.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
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CP6P284MB1900:EE_|CP8P284MB2066:EE_
X-MS-Office365-Filtering-Correlation-Id: 81bfaa91-2056-4d40-05e8-08daefeb4db9
X-MS-Exchange-SLBlob-MailProps:
	znQPCv1HvwUotVqeSD8jkA+xY8MbWg7Yh7aTUz13/B4I0e9ZMF0++fLcuD5xU5pvfGKUww1UAinhSb14i1+8/xjRphVICbWnfY8mTHdcujjJ19hVvA/AhflWaB+Mps7La90OAeYFjpCtTNsya/iRNdShUI+PIogl7VGFoNW9vnFs/y/7vomLBD6otCgc5U9iC974gSugLQ9KIay2+6Rtl/w4Vovj8jZHoX0eWE+/7SRGHSh2K5fBhWGVc0Sqy7XRH4NrZ76ocUB3zs/B7mogGKWa7RFlXPdvs7usyY3L4TWVzzPtr0AhZF4pumG8ppiuk2YubcOy8eOuKcUoOJ01P6Z9kgDH8oaFPs0sZC2A4al3zYSDVeQSoh7YkrzDRkbl5jFAP01b18DI9syUYyiu/+lKsdkRUF/NDcE3nYX6vUMuFhwNN9y2+BDLy48EaRZm9R5bjgK5cZZlJm/iA8QpKi9fSxvVKfQZSLCq/ZM9kkTwL0jKS4U+mL5JenKYLGzcLyetzRsK/tjPGr8nsTRlswqSCvR4vJsO6QmH4b5akKbIbw5fjH0bd3g5ywUxiiPJpfSM4w275+N0RIDo5/xyxd80LOOX4A7JqOEbs2ZA2OxQFNzJDYklZYSO09EoV0r99c7jFertE4YtWONfQgGQQIOzV3PADsv1OyElWy7H08JAH4BkPFuqf6h7dI64ED2QIgbAg0C54A5SjKEhXBFaUrEhGG3EADDUCzrqFcn82D51TNxh5txmgk2SSZpN+G/JeavkjNkLrps=
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info:
	NsbkCvbJs08gdhBzr422lnttQFEzndqPIYJpi8bqhoaa5LgJszPaXxr9kByNfd8gNE902its87ZFcSJxzBQ9IulrBUXvqOndRtD24xUt/gI5cmV6ZErCErXZGaOBdpu1vkaVaJ6qdfkLdgHQpMMZsphGUT8dSJR1DPAuqkuAfzSQY9jLDMzFt0D1cn/ULlk1W99/HVZq4qGBJFOXhQaTt431RzB2D2xFOz4sBWywPGe6OMyaMgU76A0QDAMTRziRoVXTyppHIZfRNtX972mxj2LjnJdHu7wRDGOFE4Wvc7ul13jJT+hRuyAn1Hr0cJke5CuS205gtH/YM8q+2utQt+aZ2/mPKigILI2hRL9N6mRuY+TbCYoYxygHwKvAjD6WT7kn3M7m2kqP+Y4zzneNU9m69GULhlwbtX98xdlAj4SZlO5Mv3VxKH3/FxHWjxAiFJGOKy9Gl+vSnzW11ybRo24ALmhhy/JmEkUxP9CXsADiiJlevUcb/GDF6tiELjBpV9yH2Xt1XS5R4NQdQjbyl8ctiiywFKT/cQRYI0kU/af00mmivAgFDo3b7Xj2jHS4M8OJSrLu1EHnYcwdts1sULmR1C5ERxZI/2mcgwf5E3Ahpj6YTqEI/6giB7J8jraKDvjnzVLBAa1GJ+4T97+HsSbx2J36cagalNsW52kKNGSoxQSNIXW4gBKUeGleqUsM
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?R056a2ZkY2RmaXFveHU1NHdSVkx6ejExbE1IRmJhWThVR21YdloyYUMxUGdN?=
 =?utf-8?B?bmhIdVY2NmhPNDFYNXFtRVNOQ0RsNHNlOHhWcmo1VUMyTTNzUXN5NVNVdFBZ?=
 =?utf-8?B?Y1BJV1EyS0FCMmVGMnBwSTEwSEZiZ1kzM3d1VEcrZ3lISWQzSGZ6Mmd5OXFo?=
 =?utf-8?B?RnJVMGJhdlNqZ0pMQ05CdXBVMmcvb1JtTWpMOEo4a1huR2haWitkWFNHTUw4?=
 =?utf-8?B?bzdQYU9SWXpEejZqM29OckNXdDlWL3Z3SllWZFUvNFZGbCs1MDBOUlZRWXBo?=
 =?utf-8?B?S2hyaytvWTA2ZFFBNGkrcnJBSlV5K3lzT1VVTjZPRmYzSllTV3FvWkFCaXNN?=
 =?utf-8?B?cm5pWGV4T2QzRFBHNWoxNkJ4dUlxeFpOMG16OUZLL0hsdG12NzFreHhXckNJ?=
 =?utf-8?B?QnNBQ2dBVElhMjlKODhNOUlyYTJ2b0xJNVlNSDFZQkNDb0o3VS81ZHFpQmZp?=
 =?utf-8?B?YjJhRlZzUnYrQXZTNk1aOUNOOFBHelpKOVpVL25Rc3BHOVBBSUhIblhIMWVL?=
 =?utf-8?B?dTVnTnBFZkpCRkduR3NWTUhVZVJ1V1VSaUsxRFZwdW5CQnNiV3Z4aGpGWFZ0?=
 =?utf-8?B?VUdWaEt3NkEvOVVuOGs1RW80WCttbG01QW1yQkJqK2FzbjRrazVQcXh6ODR4?=
 =?utf-8?B?M2REV1RZSFVOT2RGRVJoZmppNjVXcHF1Q0w1dnVia2N1Mlp2M0pXay91Vmt0?=
 =?utf-8?B?aW5nNnpuTUVhSEI4S0JEQ1lPdEV3b3NJaEMwR3BBajRNdnZkUTNDdy9zQTE0?=
 =?utf-8?B?RlFIcXNRNjNLVmdGeCtlaEF6ME1sNk8rWlFDSXlQdDV2NVh1TDdib2VHdWIz?=
 =?utf-8?B?TXR3Y1hGZ0JsVkpHWVhNeHdIdUNyQ2t6WFFPODM0NVRMcVNYTnoyYlNEY1ZV?=
 =?utf-8?B?eFZHT0h5dDN4ZE5DL0RkNkJGLzRPT0NaVVhsRDdONWVzaVZIWlBXV21NazZV?=
 =?utf-8?B?bFZETTVYZVNQdHJXdnRBOHdCTExRNnVJelU3d2RVaHgyU0NobWhpT1pQei9k?=
 =?utf-8?B?cXdNWEhBUTY1WkUxZTdwazhHOWdVeS9PVWpKbGlRaHZUTm96KzZmU2pnTlQ3?=
 =?utf-8?B?ZnRENC9ZOTZWR0Z5ZXlkeUhFNldGMzcxVHRPN216YlJhYnFsUCswNVp0SG96?=
 =?utf-8?B?NUlTY3d1WEpxaWJ6UGtLMThqNjZXQXY5VEx6ODlvUXAxblQ1cXdLYjVhNFEx?=
 =?utf-8?B?U0pZUGlYeXFoSlZ6VFdiZTdkdnJRdXFmMTlZK0lVNGwwVEdzWWlYa212MytP?=
 =?utf-8?B?OW5mQ0d3YUc0UjZ6SmJIVWMyejJJUURJalh3NUpSdnlzYmtuTEFob2QvZVY2?=
 =?utf-8?B?NHNIaHhJVEZyTVNuV095aTlwWDUyZE1wMzRJRTVLM3lBckI2OUpGK294ZHZ2?=
 =?utf-8?B?blphcE5NZU5kRFBZRDMwOHNwaDR6UWdDTHRRNjRqNkg3UTFnVGEzNUlraGQ0?=
 =?utf-8?B?UjFVRjhZci9seDFwNGpEOWVFeGVSbjBqSE9zUFNablJ2QWRqQzhmdHB1dXZZ?=
 =?utf-8?B?SythUlZ1L04xR3RndjFIOG9JcEhsa2hCRWs2anhvWGkvcjloY051cW0zZVMy?=
 =?utf-8?B?YTVReVlaQ3Q2OWRXdlJyVHRSL1JaNHBqT25NQVNGY3BKcitNN2ZFdmRXaXpk?=
 =?utf-8?B?b1NINGpCS2RNNHV1Sy83aVRsWU5Fb2w5N21vRjJ3WjR6Q0NWRFZVd3lIaTFh?=
 =?utf-8?B?SytWV2hNQmFTZlVHNG5QaFdmMmVjZ2ZkVkVtK2tWOW8va2kzOHJlbERnPT0=?=
X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-7dc52.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 81bfaa91-2056-4d40-05e8-08daefeb4db9
X-MS-Exchange-CrossTenant-AuthSource: CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2023 13:38:33.4477
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP8P284MB2066
X-Rspamd-Queue-Id: 4NpPYn3JDyz4MsN
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--3432851520-228389938-1673012310=:1798
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

Hi Dag-Erling

no problem at all , i just wanted to pass thru the login thats it.
its working fine with this new pam_login_access.so / pam_unix.so (not sure which 
one we are using now)

thanks

--tzk


On Fri, 6 Jan 2023, Dag-Erling Smørgrav wrote:

> Ivan Quitschal  writes:
>> I had to "install" the new temporary /etc/pam.d files with mergemaster. I think the problematic file was
>> the "system" config file. Now its all fine
>
> If you wish to continue to use OPIE (which I don't recommend), there is
> now a port (security/opie).  You will have to manually add back the
> pam_opie and pam_opieaccess lines in the relevant PAM policies.
>
> DES
> -- 
> Dag-Erling Smørgrav - des@FreeBSD.org
>
--3432851520-228389938-1673012310=:1798--

From nobody Mon Jan  9 10:41:56 2023
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 4Nr9Vf6Ycmz2pRnP
	for ; Mon,  9 Jan 2023 10:42:02 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic322-10.consmr.mail.ne1.yahoo.com (sonic322-10.consmr.mail.ne1.yahoo.com [66.163.189.33])
	(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 4Nr9Vd69pmz3Mm1
	for ; Mon,  9 Jan 2023 10:42:01 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=yahoo.com header.s=s2048 header.b=m5pIb5Bw;
	spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.189.33 as permitted sender) smtp.mailfrom=filippomore@yahoo.com;
	dmarc=pass (policy=reject) header.from=yahoo.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673260920; bh=Df4aXfBIrsgs8PuI6pXIfA4RsAnQQwsl2GkXPQefbCg=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=m5pIb5BwHAKeFmVhvHFSksxEnqtEkXRHWOL5wtAYziL8YIinDO9Ylpsy+wHFHlBp/zSdZBm16/823f657kd61xj3xO9b/Rptl2/iobT62U7IjZAGNSqZb0+ILm9pYn0en5YwKAL7/xRurcyS6A6/ol0gCJQ71gdm2PCu1v6i/Tu1VZ10wqjohHYcR+ZXVlsAe3DcRZo4kHxCEAb3+j8P178Wt2xvdhEOnsbPE4zSlD9lnRiBiVqLXaySm8GBlo9gaRJXxO2/c0q6vDETqNSpAxO4HIs7BKLKY1rMohTnKy59Dr2txTNGGIR8VMdMYUMY81QvHRussacGd6DmDJjVsQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673260920; bh=N4oAaosTY1qRM3EtseYmysUMFoo2enpMRKGATgoue93=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=BJUfF6JFS50mIO+FP8zyAaXKpcVB3lO+jgJn9k0qi/05JSoSCBCBz+zAZI8rgED4zKDf+ygHMX+0qkcby6IJz+1iz1ODD6h8+/UW9nH9fvskZTn1oVUyuJpnggr2FjvvphyDMORozG20kyACrSJXiloMN2Vew+cvzqylf3zJtRvk6I13Gg/keMaUuFAEDetAHYSBCl4VkjcLRzvKqZfAad/bzClW/EgGJlFpuq56yTCF/bdOoFVWmx2DnPCa+b6XVoyLHzJYgHPJZX6nXFyti9s7IRUaZgXDXvHelIlZMX+5Rs7FcX2WTAE6C0Z/O7qicgV/hvRtL5RETfQdrQglOg==
X-YMail-OSG: UUu.3esVM1k3gI28qnx33ZNeqcu_0lvdPnGe6v2VBSwOkWTbxdb9Vs30Dln_JQW
 zNHIpXyZ6PeWgHESfhxXZt9VsWPx8Q8BdzfKHXOdqu3BvcTxtlvXZxvxIdAJ4_SNDMjIVAoKeZSJ
 uOMuRQX5h1BuZZWlI8grTlQ_qnVZiOl6FsD.QSdjb8_k8UbVgJIUWD1X68gqOP2Fi5MnYFmSVHS4
 4Qj3ML9DcpSXKFOgDQQKNu4NuePfuecFGc2VH7zZCX4oQKpSMQtvSN5mh7FjPK01goiPiKJnAQKT
 VaL52hjNl4S7jeI.frDzuMrxuz6TYApqgZdsK3Aw3fo_jS9_jq5ZiZCjQ90rjnq4ybBN5VYS1sHe
 X5HQljWOiXJo4GW80T4M5Iv8hpjIeaQpvJS0tj.41K7yMEINEdX32dK.pvBlHfwjiPmJXG3F3oHd
 _8TPtkFio9JgSLW6TsdwVNRNSYbHyaLATZ8x02pdTzkyL1LoVhVZ31_hLOYSickPOnoiZVtcQUl7
 DgwtuyBRFsJcGG2NoBMMLnt.NSDQdXWoebebtHwJzh0AFNDQXROATysEsj6xUfEpcpjReNxV2ZKe
 Q49yvqU4JvefYtD9yJbD1GbMHyUmDeeqYXFtJ3sxcPuEWniiHL.0SEmHf57kUkDb1WpMyuJxpbZ_
 ewr.WHHb0RNYorpXL8jDmgOT90LZwP6MANgfLcbJXx80P8T4f74KnSw0MGIniR6mbDbJCWC.8C5q
 SwOnE9QU4Z9tILxDHMB8nBDzP8dMeXcRMiqLl2SwYs676hSZFLeaF1.gisibRG70A3f3jNMk_oh8
 BqQ.1BmvjkgpVPgAIOueKnCV1K3cyuNegZVEbfQYwG6WTSdEA6H_0LQ1AKJ0bTmXrcSvu2aulDqK
 iF_GQ02F0er0Pd0C0RBU9AcZz2sq9aGLIpWocpB7MAdrOAxAAiCjd9BrMrmRIQfeiVwTx6SuiXfh
 bwBvYKH_vDQaFKrAHV7.vpFQ_ngbEjlQ4.GYplbX5ZdesMf2uz5vC5o_93aFWn98PoqUX.DMilDa
 4.stAOFK5ZcvHd1kYgPZ5yCRMc1AYf7hJ_9wKJc7zb9qNCjgg1lmNQQOPy2THKatToHZYEhqwLbx
 7V_kkRsjmkywwM5DeazLX_KxIsB9z.mUMceTU.7iI.18icLQ3J6gYyzae79HUegy3RDiFpLTyic4
 IPYV.mbHXsMYmUkliMa6Jv9OTe4TydiRyTuH08PbbFmm.8sQnSkwUvHG2rnhcqCySGw_AnkVA4YS
 Amplh16ccHfdnCgON7PlDEHP7c1MDBOMPT511L5An35C8YyZTIybg_9iGKx.oELbd7VgsjWAs39q
 q629GbZBBru5IhbSXPcNZpBP3sU0yBdWz3fT98kx3MJP3_ZZVB1y8CWYf_vvSA7HIrRahfdfyMok
 omLjl.caubcdQRnkGNnkSTvzxholpa_69Y3eNEpM.HjrQbZdsISA2mRrfIjgYPpFCUbk.asMsEhq
 dKptFtqQPXjdlBBKvv8d93VTPyKY7uldIQgJskJpTymg8PBAwMom1ocYlU04gRJUSxskr4k9SmOw
 pC2evsr7aGq7.vlAmIRDMBNWCPz.pvMHqoJ.Bl3SCAT2Kx6H3NHFDle_FFC_VpbggPn85BlDMWFO
 bPF4N2C0srlvBjTi57ipgFcO5F5mdWj06uDdwCAKaHB9CdvjUHb8TCoFQC2eKPTY62Hm2a2q.Tnl
 t_Nz6vIMAgmNopKOVN2rGyX4MrfVUdqLmq.YfWfThgG9CUdtiwgqzE6s_8Tx6dBBpI2HV0rJA0sb
 1Gh_UnUuUBA_maEmYaDeY0Ivix18kwoVZOgoG58A6eWes07I7QTJWvVS28yy4O2mmt.4VXe0BZI2
 Xsn0Iua6YmX3yc2N0fTiLYuTsXblAFNbu3Q9S9QBoZxJgCRCC3L1BUQvIfnMNWfuwY3tnExKp65E
 MZ1XlVvFD9y3WzZ7kGyg4G7Lp9.IYCH5cKiNENWECMZ._bNhGuh.nh1Bi8SrvxYZSTuaKXqn6Uqt
 sKzgjTCqs_kGWaYh8ygyv_zmhzfEirGuEVxbIxb_YIB1Y97qCVanxt5LJavtXZzUjNPuAoz6smcp
 UqQWu8UJUofr4oNKtXgaEzmujTV_2kpF.9B0DzBylqOt72L0GMJRcY8TqWSA3P1p4NsIShCT89an
 rrvCjpkwXNkmmjRTKuPrOMtu63YmDN04-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic322.consmr.mail.ne1.yahoo.com with HTTP; Mon, 9 Jan 2023 10:42:00 +0000
Date: Mon, 9 Jan 2023 10:41:56 +0000 (UTC)
From: Filippo Moretti 
To: FreeBSD Current 
Message-ID: <1795804180.9324624.1673260916531@mail.yahoo.com>
Subject: Problem in userland
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_9324623_439246582.1673260916529"
References: <1795804180.9324624.1673260916531.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.20982 YMailNorrin
X-Spamd-Result: default: False [-3.50 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject];
	NEURAL_HAM_SHORT(-0.50)[-0.500];
	R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048];
	R_SPF_ALLOW(-0.20)[+ptr:yahoo.com];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	RCVD_IN_DNSWL_NONE(0.00)[66.163.189.33:from];
	ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US];
	FREEMAIL_ENVFROM(0.00)[yahoo.com];
	RCVD_TLS_LAST(0.00)[];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	TO_DN_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	ARC_NA(0.00)[];
	DKIM_TRACE(0.00)[yahoo.com:+];
	FREEMAIL_FROM(0.00)[yahoo.com];
	RCPT_COUNT_ONE(0.00)[1];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]
X-Rspamd-Queue-Id: 4Nr9Vd69pmz3Mm1
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_9324623_439246582.1673260916529
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Good morning,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I =
have two computers running CURRENT when launching firefox I get the followi=
ng error:
[filippo@ROXY ~]$ firefox
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot access=
 /sys/bus/pci (t=3D3.60308) [GFX1-]: glxtest: cannot access /sys/bus/pci
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot access=
 /sys/bus/pci (t=3D3.60308) |[1][GFX1-]: glxtest: VA-API test failed: faile=
d to initialise VAAPI connection. (t=3D4.09897) [GFX1-]: glxtest: VA-API te=
st failed: failed to initialise VAAPI connection.

[filippo@ROXY ~]$ uname -a
FreeBSD ROXY 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n259682-67e628b7a643=
: Wed Dec 14 22:56:22 CET 2022=C2=A0=C2=A0=C2=A0=C2=A0 root@ROXY:/usr/obj/u=
sr/src/amd64.amd64/sys/ROXY amd64

On this computer firefox works in spite of the Crash Annotation.
On the other hand on this computer:[filippo@ROXY ~]$ less problem
FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n259975-4ffe60e6833=
e: Sun Jan=C2=A0 8 17:40:19 CET 2023=C2=A0=C2=A0=C2=A0=C2=A0 root@STING:/us=
r/obj/usr/src/amd64.amd64/sys/STING amd64

firefox doen't work at all.I did check and there is no /sys/bus/pci and the=
re is no /usr/src/sys/bus/pci.Any help appreciated,sincerelyFilippo

------=_Part_9324623_439246582.1673260916529
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Good morning,
          &=
nbsp;            I h=
ave two computers running CURRENT when launching firefox I get the followin=
g error:

[filippo@ROXY ~]$ firefox
Crash Annotati=
on GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot access /sys/bus/pci =
(t=3D3.60308) [GFX1-]: glxtest: cannot access /sys/bus/pci
Crash Annotat=
ion GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot access /sys/bus/pci=
 (t=3D3.60308) |[1][GFX1-]: glxtest: VA-API test failed: failed to initiali=
se VAAPI connection. (t=3D4.09897) [GFX1-]: glxtest: VA-API test failed: fa=
iled to initialise VAAPI connection.

[filippo@ROXY ~]$ uname -a
FreeBSD ROXY 14.0-CURRENT =
FreeBSD 14.0-CURRENT #0 main-n259682-67e628b7a643: Wed Dec 14 22:56:22 CET =
2022     root@ROXY:/usr/obj/usr/src/amd64.amd64/sys/ROX=
Y amd64

On this compute=
r firefox works in spite of the Crash Annotation.

On the =
other hand on this computer:
[filippo@ROXY ~]$ less problem
FreeBSD STING 14.0-CURRENT FreeBSD 14.=
0-CURRENT #1 main-n259975-4ffe60e6833e: Sun Jan  8 17:40:19 CET 2023&n=
bsp;    root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING am=
d64

firefox doen't work=
 at all.
I did check and there =
is no /sys/bus/pci and there is no /usr/src/sys/bus/pci.
Any help appreciated,
sincerely
Fili=
ppo

------=_Part_9324623_439246582.1673260916529--

From nobody Mon Jan  9 15:22:24 2023
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 4NrHkG52tLz2sJML
	for ; Mon,  9 Jan 2023 15:22:30 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NrHkG3HCcz3v8m
	for ; Mon,  9 Jan 2023 15:22:30 +0000 (UTC)
	(envelope-from wlosh@bsdimp.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-ej1-x635.google.com with SMTP id vm8so20980679ejc.2
        for ; Mon, 09 Jan 2023 07:22:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=bsdimp-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=VN0D71SZyqORSFzGZ+v/Zq5EApesyOwpM3vcSFq6v3M=;
        b=FmIwuDoy5WTjDmClLZt9uv5xRblLS5lDpPO90lNqbnOkVF2blQjQVM6oA1X7zcKEUv
         D0wkM+5nCEkYsBkrrFyLNnrHht1nW/9/q3vpMThfko2tZFUJrPIJhcS1N8V7PlLYhGh4
         VWsNOEjt7ErcVAAxdUfWX5QvC50S44AnNBakAe1ENv/4QsP/IqaxVcz1pGQp8rNNctlD
         g2eZeUciavk9NumIntfBoViSPmkhJ9iX9m4Cv2pBvyXM76Un4sSUsu6JHJWW7PiSG3Kt
         lBs/lDRMuTuAXEC+cWQ80yJLZQXlfQ7IAxX1Uv/LCvoKWvSAAzyRMQnnYy+dodH95frV
         FLSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=VN0D71SZyqORSFzGZ+v/Zq5EApesyOwpM3vcSFq6v3M=;
        b=icOE+UgJYd4uOm3dtwZkJMygxZmRw+tMsyWuKzHs97orRpPSBwwFTnTHKMYhVuSSDo
         fFGqtPpSVLViKGgFe2VwGUW02FSvlPE3Fbv0Jbb6DGBiyIlhHIE+p85XFo7yz24mMNKS
         RD8GUg1bF9OkCJwgVooAF0br1zJK59lh3o0vVhCJL1UGPM1I2miSjIPD2U3AcjVV4RoD
         SHVnKYalX3lLvTQGtONoqbxguVJKIbAnVVT2Nwfl9ZF7ssdRBN3NHSHVHvyEqUdLbzs8
         JIjlyiwfVqkbemkRUTDwJXHHa4IAhrGcq98dl/egyNWySJZbzVO680qHWuj4j3PFIsRS
         L72Q==
X-Gm-Message-State: AFqh2krESMYCeMLj/qCW12XTMEQpE+HEDJ2kjqjrr5QPakx4yIjKS5KM
	2LiTG9fU9ZDyG6kFDaWk9/XpO2MDnZ/B/iQUXVOXPkL8NxHO2KCt
X-Google-Smtp-Source: AMrXdXvZ0xyuWu+TMHYuf+DmJlSMjqBFVeaqNI4vmFiaLWQ3O/miS2q6/dzwcOB0AXJmhygXg0Rz56WsPWzMFDO0cu8=
X-Received: by 2002:a17:906:1858:b0:7c0:e7a6:cd2d with SMTP id
 w24-20020a170906185800b007c0e7a6cd2dmr3831387eje.317.1673277748527; Mon, 09
 Jan 2023 07:22:28 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <1795804180.9324624.1673260916531.ref@mail.yahoo.com> <1795804180.9324624.1673260916531@mail.yahoo.com>
In-Reply-To: <1795804180.9324624.1673260916531@mail.yahoo.com>
From: Warner Losh 
Date: Mon, 9 Jan 2023 08:22:24 -0700
Message-ID: 
Subject: Re: Problem in userland
To: Filippo Moretti 
Cc: FreeBSD Current 
Content-Type: multipart/alternative; boundary="000000000000cfdee005f1d65582"
X-Rspamd-Queue-Id: 4NrHkG3HCcz3v8m
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000cfdee005f1d65582
Content-Type: text/plain; charset="UTF-8"

On Mon, Jan 9, 2023 at 3:42 AM Filippo Moretti 
wrote:

> Good morning,
>                        I have two computers running CURRENT when launching
> firefox I get the following error:
>
> [filippo@ROXY ~]$ firefox
> Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot
> access /sys/bus/pci (t=3.60308) [GFX1-]: glxtest: cannot access /sys/bus/pci
> Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot
> access /sys/bus/pci (t=3.60308) |[1][GFX1-]: glxtest: VA-API test failed:
> failed to initialise VAAPI connection. (t=4.09897) [GFX1-]: glxtest: VA-API
> test failed: failed to initialise VAAPI connection.
>
> [filippo@ROXY ~]$ uname -a
> FreeBSD ROXY 14.0-CURRENT FreeBSD 14.0-CURRENT #0
> main-n259682-67e628b7a643: Wed Dec 14 22:56:22 CET 2022     root@ROXY:/usr/obj/usr/src/amd64.amd64/sys/ROXY
> amd64
>
> On this computer firefox works in spite of the Crash Annotation.
>
> On the other hand on this computer:
> [filippo@ROXY ~]$ less problem
> FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #1
> main-n259975-4ffe60e6833e: Sun Jan  8 17:40:19 CET 2023     root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING
> amd64
>
> firefox doen't work at all.
> I did check and there is no /sys/bus/pci and there is no
> /usr/src/sys/bus/pci.
>

Not sure why firefox is accessing a linux-specific file. FreeBSD does
emulate some of it, but only with linsysfs mounted. Generally only linux
binaries need it.

           mount -t linsysfs linsys /compat/linux/sys

might be useful to see if that's missing?

Warner

--000000000000cfdee005f1d65582
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Jan 9, 2023 at 3:42 AM Filipp=
o Moretti <filippomore@yahoo.co=
m> wrote:
Good morning,
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I have two computers ru=
nning CURRENT when launching firefox I get the following error:

[filippo@ROXY ~]$ firefox
Cra=
sh Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot access /s=
ys/bus/pci (t=3D3.60308) [GFX1-]: glxtest: cannot access /sys/bus/pci
Cr=
ash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot access /=
sys/bus/pci (t=3D3.60308) |[1][GFX1-]: glxtest: VA-API test failed: failed =
to initialise VAAPI connection. (t=3D4.09897) [GFX1-]: glxtest: VA-API test=
 failed: failed to initialise VAAPI connection.

[filippo@ROXY ~]$ uname -a
FreeBSD ROXY 14.0-CURRENT FreeBSD 14.=
0-CURRENT #0 main-n259682-67e628b7a643: Wed Dec 14 22:56:22 CET 2022=C2=A0=
=C2=A0=C2=A0=C2=A0 root@ROXY:/usr/obj/usr/src/amd64.amd64/sys/ROXY amd64
On this computer firefox works in spite of the =
Crash Annotation.

On the o=
ther hand on this computer:
[filippo@ROXY ~]$ le=
ss problem
FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n2599=
75-4ffe60e6833e: Sun Jan=C2=A0 8 17:40:19 CET 2023=C2=A0=C2=A0=C2=A0=C2=A0 =
root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64

firefox doen't work at all.
I did chec=
k and there is no /sys/bus/pci and there is no /usr/src/sys/bus/pci.
<=
/div>

Not sure why =
firefox is accessing a linux-specific file. FreeBSD does emulate some of it=
, but only with linsysfs mounted. Generally only linux binaries need it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 mount -t li=
nsysfs linsys /compat/linux/sys

might be useful to=
 see if that's missing?

Warner 
<=
/div>


--000000000000cfdee005f1d65582--

From nobody Mon Jan  9 15:56:44 2023
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 4NrJTr2Rtlz2sMt3
	for ; Mon,  9 Jan 2023 15:56:48 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Received: from sonic318-20.consmr.mail.ne1.yahoo.com (sonic318-20.consmr.mail.ne1.yahoo.com [66.163.186.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 4NrJTq71mhz40PW
	for ; Mon,  9 Jan 2023 15:56:47 +0000 (UTC)
	(envelope-from filippomore@yahoo.com)
Authentication-Results: mx1.freebsd.org;
	none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673279806; bh=+iQ9WnlSoVk4R8FXHpum0hM3KWzuZPxOvbuTiLelsJQ=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=EZAeVjUFOHDmV3fbr3pLF2iJ3sjnZoNvjJLTlMycNa7BKOV6lhalhOH3O5DCEoILxnU0GQsP+ejTk9ULyBry4I+yAPdBUvYr7gLpCYuB3GvCk+H/wT6qYfb4OtXweSjxiEqeYP8JRpk7xQ9l1BxzoC6NtMNmGNhSVq/GbxKeEmM/5g+vKHQ14CBlCqkONaZ4IT0tMDfze636gtnkoLPslIF50MJDGLSey8f82lkcbHSMpBM8pJi3e4yxJK5HB7NtW636vs0ENPvY+z8tZQkPczGWwTL+0Qaz7ywgtnSv1AkzSU9OjBHeqkWtqaq4YOkvZ6bWTdK1l5gqK5AM2zdCJQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673279806; bh=UskmVTUAWRSpn7asCMaU0bvARHmgywPF9O+hMwliryJ=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=A8gk1PO2nIZ05owzEYNIw9bcZIKIJGQZlugdt2iX4dY/Skwi6W4TzHvu8FLy3Fn6wZTR3XCzVJfwn4l740Q3769Qsqj2M538GTC9c7pxr0F/qE/i5pcvMWw3K6eLsdPVqQCSCUT/Jt6Zu2caEnlOXUlAV5QUJW+wf21aswICZ/A/PK90BAmnpFjjIza5SXfueBHYh5QKWMB0KedNYMr7fP6cZzORpRodib1vZZLWjPfAn6/ekDajLEd6OQMw9VOc+PbDV4ucTAAdFMmuYc0JbKUxeymewMEseqpBe/NMMM1Q1bmmzVFvDkWWlFGFECVTWFudkqZxQDY67NJb3JMxHA==
X-YMail-OSG: CC3BDkMVM1knqFPPRgt1SPL3tn9bPBu6tTWWu_XYXUejtQ5AIdIxXYF9Mg6OBLh
 TayP3imcNlEEjMi4OqJhLFiLEbVSArzKaYIlCgu2Bs.2I.md3G2BgNnDXKuX74vA4imzT98hWp3.
 9HD.WfNmtOcBsNoZ7LN3TBSyZ6mLFWocPypiQ10qnEKLrWfNHFQ5fQeH6ZnYP6XJyUMTGgXizHia
 offra2l8IdSe3Goy6FtQX4XEbbCkbwRbMtOM8C8DSPm.6oBhEgWRKL.lOg_FswNPHVdqKGm0lFZz
 Y4UFWpg6FWRAbN8gBSia3D7LiWmHvB1XAe0B3zrB99.PppGNVW3GsuAdPrYxd_ltfPNAAO6J8o5c
 37WG8kNrCxgHMx9TvMFVpPtmogDENS_oEepELMAa9txosoVst3Z8xXrJTNJrTb8w00bZU2QvwLYb
 cKz4HqZC0RKd6QRMFTzFylkRIReGahZMEcs978RJSglNhXJftbVUod42FfvGHMAh0Q5ti.6pTiOl
 E6FF.J2kTOw7_fDf7xoTUZ7mRVVZ2OZLLDcFQVpq0IJkbmp4hodK3zAZ9z7APnO__Whjp6iyN0As
 m9EGgRYFPSy79ttTtLd90BRfHoPfTvgFyGbrmBgjAJX53YoIBztzGKpEFcNvhhw1J12CoR3UQ2Cr
 3IVCBMMw83_0bWuHbn5yYmwCQstOM.I6gA2vFkJmj7SeJprfFTTGnHRnfUTfJ_dmBoxy_ccIq0uX
 FXm1w61LHarCFepLUgy6MMevI4ab7ESqFVyoOVGeO_fH0cKFq3adyzRlGqDa_ZK33doF4p2dMp9Y
 HZC04ip2CKHonuzcK6abgcGOTaLV4WOiYma5YUD11UDgomECy6anbC_uw8zhxhdkyc4spZGv1ZoB
 hHKQvlfqDXu8a8lq7LljzgXy6xWtLxwRPIbIpr4.F61MpptVT4z4f1KBOKtUQwahUqLjNb8E3FyM
 ecOI06h5PzNZKHJxXQJXnLDtonGarAWv3dzbS.aY0EZd6v6An89FXhnOmSsonVrEWqhdaQOav.u_
 grWlTDTBknwtXj85xiY1sdSv7bu.qqPQ7cCqgt7Je6s_CHvPOLhGO2VyZnaJiSqX8nP8W80JggcL
 GFOzmAQQNhZctzmBdPtVDR4GB6mv6g1lNOKYUXbdwOaZxIagDU0r5AL41J20jI5YbXMaCORfeJP6
 GzcIJGYPPfTgCjMs0wfIXWAQd1FNXy4NcW_p8661BCM5_JADONuM9Okzc7p7RD1qObgISUmePxmK
 SiWBjHtRV1YDckSXHbq99LP5gjvOEtNrAbZMVRs0ODnbEqjwaZhDZOkU8wZNz2x_TwlvqHf0N9cS
 Bmx2mXoXUGwVd2wRxD46HpI3nPaYTlOfBi3bZc_.NtP4JlJwJRUusBRCTL2TlBe3c425xg90obOR
 A6JR8Rer1DHF91ZO8p7nSFx00.rLsS9VF64IgXkZmQAfMAdpCo4vL.RyIxU7nejVvP8PUDkIAAAJ
 SklQQvzw6MlNaZW6yFVy2VIvZ21abUYMzKcYuJfK4nZNQ_D7CfxHWBIsCduhy2BoxJaupFXZ5d.e
 ptXfNiSFuOJCmdgESa4eLBG6795IwsX2Yy8s3ej1WFmaT03eWcMx5Q1YsvUHtrR5wCMpH4Gt_edH
 Z4tM_DRXpkBOsl3Xl6s6Gqp4kxSvxHkt__TeyEt6iILuJIhYS77Cp.HZ3t6VFBdEnauII7jwseGS
 Btco3k0lwZKhZHc0W77Rh__83xoMCJuahG_oUzZeGZ1BlBgk8PxPADdkOHaVS4Kzsa9Pg3bkJayI
 AsZLgVidwDbSrvRME8kAfswTvwY1fWTFxnrw9m30FY.Dy6BAkdewg6YjrxF0wP2APP18xH0qoDm6
 o1cs5KAdZ2oLYR7q9HK2H7qaJWTUzSIlUHUUg3xKjKwKyRz93TbA3oBmhUhMW97Clr8GQDREetG2
 ThJJQTX6KxWVogXQszlwUY64TAbGVpsoRVzqPeElMsN5GJcC_jGcALG5.HYbStqBFYGgAeXO7erD
 UAcEGJmFeXUijgQR6lP.spwA0Kcu.tpXf4zeht5M10i.LkeOSvevA8r2z37vMJ5.xsHQCeBPAnI.
 H7FdqPtKce0gLiK11JdwsoMbtHayS4q8dGpLz8mA84Eur38VUtoubebH1NqU2R.8HZ3PpKiq6.FZ
 aEOhbV6wurRr5GUbcl9tFdEG_f9RZ0kaa6N79jIAJNNmkT_4aBHIRdNZQFOAaCkUYzWFJRamC9_A
 VppN0dZS42as-
X-Sonic-MF: 
Received: from sonic.gate.mail.ne1.yahoo.com by sonic318.consmr.mail.ne1.yahoo.com with HTTP; Mon, 9 Jan 2023 15:56:46 +0000
Date: Mon, 9 Jan 2023 15:56:44 +0000 (UTC)
From: Filippo Moretti 
To: Warner Losh 
Cc: FreeBSD Current 
Message-ID: <519013808.9171830.1673279804159@mail.yahoo.com>
In-Reply-To: 
References: <1795804180.9324624.1673260916531.ref@mail.yahoo.com> <1795804180.9324624.1673260916531@mail.yahoo.com> 
Subject: Re: Problem in userland
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_9171829_1950499645.1673279804157"
X-Mailer: WebService/1.1.20982 YMailNorrin
X-Rspamd-Queue-Id: 4NrJTq71mhz40PW
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

------=_Part_9171829_1950499645.1673279804157
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=20
Thank you for your prompt answer.I tried your suggestion but did not work:I=
 get the same error.Please note however that I have not linux emulation ena=
bled as I run no linux program:Firefox was installed from ports and it is t=
he native freebsd one.I will switch to another browser if needed.Filippo
    On Monday, January 9, 2023 at 04:22:49=E2=80=AFPM GMT+1, Warner Losh  wrote: =20
=20
=20

On Mon, Jan 9, 2023 at 3:42 AM Filippo Moretti  wrot=
e:

Good morning,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I =
have two computers running CURRENT when launching firefox I get the followi=
ng error:
[filippo@ROXY ~]$ firefox
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot access=
 /sys/bus/pci (t=3D3.60308) [GFX1-]: glxtest: cannot access /sys/bus/pci
Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot access=
 /sys/bus/pci (t=3D3.60308) |[1][GFX1-]: glxtest: VA-API test failed: faile=
d to initialise VAAPI connection. (t=3D4.09897) [GFX1-]: glxtest: VA-API te=
st failed: failed to initialise VAAPI connection.

[filippo@ROXY ~]$ uname -a
FreeBSD ROXY 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n259682-67e628b7a643=
: Wed Dec 14 22:56:22 CET 2022=C2=A0=C2=A0=C2=A0=C2=A0 root@ROXY:/usr/obj/u=
sr/src/amd64.amd64/sys/ROXY amd64

On this computer firefox works in spite of the Crash Annotation.
On the other hand on this computer:[filippo@ROXY ~]$ less problem
FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n259975-4ffe60e6833=
e: Sun Jan=C2=A0 8 17:40:19 CET 2023=C2=A0=C2=A0=C2=A0=C2=A0 root@STING:/us=
r/obj/usr/src/amd64.amd64/sys/STING amd64

firefox doen't work at all.I did check and there is no /sys/bus/pci and the=
re is no /usr/src/sys/bus/pci.

Not sure why firefox is accessing a linux-specific file. FreeBSD does emula=
te some of it, but only with linsysfs mounted. Generally only linux binarie=
s need it.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 mount -t linsysfs linsys /compat/l=
inux/sys
might be useful to see if that's missing?

Warner=20
 =20
------=_Part_9171829_1950499645.1673279804157
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



        

Thank you for=
 your prompt answer.I tried your suggestion but did not work:I get the same=
 error.Please note however that I have not linux emulation enabled as I run=
 no linux program:Firefox was installed from ports and it is the native fre=
ebsd one.
I will switch to anot=
her browser if needed.
Filippo<=
br>

       =20
        

            

               =20
                

                    On Monday, January 9, 2023 at 04:22:49=E2=80=AFPM GMT+1=
, Warner Losh <imp@bsdimp.com> wrote:
                

                


                


                


On Mon, Jan 9, 2023 at 3:42 AM Filippo =
Moretti <f=
ilippomore@yahoo.com> wrote:
Good m=
orning,
       &nb=
sp;            =
   I have two computers running CURRENT when launching firefox I =
get the following error:

<=
div>[filippo@ROXY ~]$ firefox
Crash Annotation GraphicsCriticalError: |[=
0][GFX1-]: glxtest: cannot access /sys/bus/pci (t=3D3.60308) [GFX1-]: glxte=
st: cannot access /sys/bus/pci
Crash Annotation GraphicsCriticalError: |=
[0][GFX1-]: glxtest: cannot access /sys/bus/pci (t=3D3.60308) |[1][GFX1-]: =
glxtest: VA-API test failed: failed to initialise VAAPI connection. (t=3D4.=
09897) [GFX1-]: glxtest: VA-API test failed: failed to initialise VAAPI con=
nection.

[filippo@ROXY ~]$ uname -a
F=
reeBSD ROXY 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n259682-67e628b7a643:=
 Wed Dec 14 22:56:22 CET 2022     root@ROXY:/usr/obj/us=
r/src/amd64.amd64/sys/ROXY amd64

On this comp=
uter firefox works in spite of the Crash Annotation.
=

On the other hand on this computer:
[filippo@ROXY ~]$ less problem
FreeBSD STING 14.0-CURRENT=
 FreeBSD 14.0-CURRENT #1 main-n259975-4ffe60e6833e: Sun Jan  8 17:40:1=
9 CET 2023     root@STING:/usr/obj/usr/src/amd64.amd64/=
sys/STING amd64

firefox doen't work at all.
I did check and there is no /sys/bus/pci and there is =
no /usr/src/sys/bus/pci.

Not sure why firefox is accessing a linux-specific file. =
FreeBSD does emulate some of it, but only with linsysfs mounted. Generally =
only linux binaries need it.

      =
     mount -t linsysfs linsys /compat/linux/sys
might be useful to see if that's missing?

Warner 



            

        

------=_Part_9171829_1950499645.1673279804157--

From nobody Mon Jan  9 16:25:53 2023
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 4NrK8770tlz2sR1c
	for ; Mon,  9 Jan 2023 16:26:31 +0000 (UTC)
	(envelope-from m.e.sanliturk@gmail.com)
Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35])
	(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 "GTS CA 1D4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NrK8756THz43t4
	for ; Mon,  9 Jan 2023 16:26:31 +0000 (UTC)
	(envelope-from m.e.sanliturk@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-15b9c93848dso867096fac.1
        for ; Mon, 09 Jan 2023 08:26:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=/VmiMtOl8VGIhGu+u7wkvyn+KlL83n1S2CaIYmdMKjo=;
        b=kzs0OAUk/YOw4e+G75xNTNpNbx5licMCIxDJjXsRmt4khlQSy/OIrGgfYyqSjaZeau
         EiLTovcnY3L6pJxuM6Zo5bAUsFNmd1ieYMjmrbPp+9rAaczPKe/Ka2uA2CqKfHN0WW2E
         FUUQNCrhtpEZkS5OmvXWed+8jio1UZvbyOUbRyMnoG0Yk+yYL8sUTudueAK49s2xQC9l
         x65KhXiAjCFd8kwGL2FbJHbYv10M2eMqs1vBWbTOiCdcPSh3dd9hhGj4DKhO6G7DlnsI
         aj2gtUkvzWH7dLzNW79nTNWHXC01m+9nYOdlR2uDpsW8JzXFQA+fqI0oLhaWFtwWmF8P
         IEew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=/VmiMtOl8VGIhGu+u7wkvyn+KlL83n1S2CaIYmdMKjo=;
        b=VNpxmaUG3EPy5FhlxFA/UIrrb1S9zeJ0DsZ6WQ28SuvXsmE7c6n0FuYEVff1wfTYMB
         tzpRc7kjrfE8ALMGFSd/OYc9YJtN8iwmUemqQGA0bY/tc9h744G7WhUlvQ/PTTkZZpg3
         XZI3swtcKQzxLVoU6yKpdElEIj8yVlB943KE91s6dqBJpWtE7Z9puzfQafcZD5YRZoEl
         ZQPN8coP2b6pYjhpm6oOci7I9BNXO4rhHG6Il0Nh5USJW/pPgIv6sszaM+AqehgZgs39
         4QBK1ofny1dajCEdgVh80iaBVMxm+2ysmOISkY6VxfLGQ2bfO3XM49uwjEFj4X2DQnA6
         dtFA==
X-Gm-Message-State: AFqh2koKqIC3BcbM09yvE6sXtND4vZ4WHcWlTPNj56BqGoXKPJkl4z8I
	3V7Xp9mKJ4TxxBI+fSY0/s+OWZt7wqBSwhHWb4Bx0E9/Z+E=
X-Google-Smtp-Source: AMrXdXsR2trS8hGQVZnVKfSV4u3G8QacG/DFpGQSz8Nnc3kR1Bi+FHE/LFv1AIVgHLtbuyPChmcST6GwxAFkYXcS+LE=
X-Received: by 2002:a05:6871:2309:b0:15b:9ab9:75ea with SMTP id
 sf9-20020a056871230900b0015b9ab975eamr72117oab.193.1673281590438; Mon, 09 Jan
 2023 08:26:30 -0800 (PST)
List-Id: Discussions about the use of FreeBSD-current 
List-Archive: https://lists.freebsd.org/archives/freebsd-current
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
Sender: owner-freebsd-current@freebsd.org
MIME-Version: 1.0
References: <1795804180.9324624.1673260916531.ref@mail.yahoo.com>
 <1795804180.9324624.1673260916531@mail.yahoo.com> 
 <519013808.9171830.1673279804159@mail.yahoo.com>
In-Reply-To: <519013808.9171830.1673279804159@mail.yahoo.com>
From: Mehmet Erol Sanliturk 
Date: Mon, 9 Jan 2023 19:25:53 +0300
Message-ID: 
Subject: Re: Problem in userland
To: Filippo Moretti 
Cc: Warner Losh , FreeBSD Current 
Content-Type: multipart/alternative; boundary="000000000000ceae8905f1d73a2c"
X-Rspamd-Queue-Id: 4NrK8756THz43t4
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US];
	TAGGED_FROM(0.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

--000000000000ceae8905f1d73a2c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 9, 2023 at 6:56 PM Filippo Moretti 
wrote:

>
> Thank you for your prompt answer.I tried your suggestion but did not
> work:I get the same error.Please note however that I have not linux
> emulation enabled as I run no linux program:Firefox was installed from
> ports and it is the native freebsd one.
> I will switch to another browser if needed.
> Filippo
> On Monday, January 9, 2023 at 04:22:49=E2=80=AFPM GMT+1, Warner Losh <
> imp@bsdimp.com> wrote:
>
>
>
>
> On Mon, Jan 9, 2023 at 3:42 AM Filippo Moretti 
> wrote:
>
> Good morning,
>                        I have two computers running CURRENT when launchin=
g
> firefox I get the following error:
>
> [filippo@ROXY ~]$ firefox
> Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot
> access /sys/bus/pci (t=3D3.60308) [GFX1-]: glxtest: cannot access /sys/bu=
s/pci
> Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot
> access /sys/bus/pci (t=3D3.60308) |[1][GFX1-]: glxtest: VA-API test faile=
d:
> failed to initialise VAAPI connection. (t=3D4.09897) [GFX1-]: glxtest: VA=
-API
> test failed: failed to initialise VAAPI connection.
>
>




It seems that you are running  firefox  from a command line .
If there is not a graphical  underlayer , is it possible to run  firefox  ?


The reason for the above question is due to  the firefox display structure
which is a graphical one , not a text one .


Mehmet Erol Sanliturk







> [filippo@ROXY ~]$ uname -a
> FreeBSD ROXY 14.0-CURRENT FreeBSD 14.0-CURRENT #0
> main-n259682-67e628b7a643: Wed Dec 14 22:56:22 CET 2022     root@ROXY:/us=
r/obj/usr/src/amd64.amd64/sys/ROXY
> amd64
>
> On this computer firefox works in spite of the Crash Annotation.
>
> On the other hand on this computer:
> [filippo@ROXY ~]$ less problem
> FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #1
> main-n259975-4ffe60e6833e: Sun Jan  8 17:40:19 CET 2023     root@STING:/u=
sr/obj/usr/src/amd64.amd64/sys/STING
> amd64
>
> firefox doen't work at all.
> I did check and there is no /sys/bus/pci and there is no
> /usr/src/sys/bus/pci.
>
>
> Not sure why firefox is accessing a linux-specific file. FreeBSD does
> emulate some of it, but only with linsysfs mounted. Generally only linux
> binaries need it.
>
>            mount -t linsysfs linsys /compat/linux/sys
>
> might be useful to see if that's missing?
>
> Warner
>

--000000000000ceae8905f1d73a2c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Jan 9, 2023 =
at 6:56 PM Filippo Moretti <filippomore@yahoo.com> wrote:

        

Thank you for your prompt answer.I =
tried your suggestion but did not work:I get the same error.Please note how=
ever that I have not linux emulation enabled as I run no linux program:Fire=
fox was installed from ports and it is the native freebsd one.
I will switch to another browser if needed.
Filippo

       =20
        

            

               =20
                

                    On Monday, January 9, 2023 at 04:22:49=E2=80=AFPM GMT+1=
, Warner Losh <imp@b=
sdimp.com> wrote:
                

                


                


                


On Mon, Jan 9, 2023 at 3:42 AM Filippo Moretti <filippomore@yahoo.com> wrote:
Good morning,
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I have two comput=
ers running CURRENT when launching firefox I get the following error:
=


[filippo@ROXY ~]$ firefox<=
br>Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot acc=
ess /sys/bus/pci (t=3D3.60308) [GFX1-]: glxtest: cannot access /sys/bus/pci=

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot ac=
cess /sys/bus/pci (t=3D3.60308) |[1][GFX1-]: glxtest: VA-API test failed: f=
ailed to initialise VAAPI connection. (t=3D4.09897) [GFX1-]: glxtest: VA-AP=
I test failed: failed to initialise VAAPI connection.






It seems that you are running=C2=A0 firefox=C2=A0 from a=
 command line .
If there is not a graphical=C2=A0 underlayer=
 , is it possible to run=C2=A0 firefox=C2=A0 ?


=

The reason for the above question is due to=C2=A0 the =
firefox display structure which is a graphical one , not a text one .
=



Mehmet Erol Sanliturk





=C2=A0
[filippo@ROXY ~]$ uname -a
FreeBSD ROXY 14.0-C=
URRENT FreeBSD 14.0-CURRENT #0 main-n259682-67e628b7a643: Wed Dec 14 22:56:=
22 CET 2022=C2=A0=C2=A0=C2=A0=C2=A0 root@ROXY:/usr/obj/usr/src/amd64.amd64/=
sys/ROXY amd64

On this computer firefox works=
 in spite of the Crash Annotation.

On the other hand on this computer:
[fi=
lippo@ROXY ~]$ less problem
FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURR=
ENT #1 main-n259975-4ffe60e6833e: Sun Jan=C2=A0 8 17:40:19 CET 2023=C2=A0=
=C2=A0=C2=A0=C2=A0 root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64<=
br>
firefox doen't work at all.
I did check and there is no /sys/bus/pci and there is no /usr/src/=
sys/bus/pci.

Not sure why firefox is accessing a linux-specific file. FreeBSD does=
 emulate some of it, but only with linsysfs mounted. Generally only linux b=
inaries need it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0=C2=A0 mount -t linsysfs linsys /compat/linux/sys

might be useful to see if that's missing?

Warner 



            

        


--000000000000ceae8905f1d73a2c--

From nobody Mon Jan  9 17:23:28 2023
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 4NrLv91Rmnz2p7vP
	for ; Mon,  9 Jan 2023 17:45:25 +0000 (UTC)
	(envelope-from steffen@sdaoden.eu)
Received: from sdaoden.eu (sdaoden.eu [217.144.132.164])
	(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 4NrLv85rmyz4Fw4
	for ; Mon,  9 Jan 2023 17:45:24 +0000 (UTC)
	(envelope-from steffen@sdaoden.eu)
Authentication-Results: mx1.freebsd.org;
	none
Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2])
	by sdaoden.eu (Postfix) with ESMTPS id A188716059;
	Mon,  9 Jan 2023 18:45:16 +0100 (CET)
Received: by kent.sdaoden.eu (Postfix, from userid 1000)
	id 93340B58DE; Mon,  9 Jan 2023 18:23:28 +0100 (CET)
Date: Mon, 09 Jan 2023 18:23:28 +0100
Author: Steffen Nurpmeso 
From: Steffen Nurpmeso 
To: Filippo Moretti 
Cc: Warner Losh ,
 FreeBSD Current 
Subject: Re: Problem in userland
Message-ID: <20230109172328.GWbZw%steffen@sdaoden.eu>
In-Reply-To: <519013808.9171830.1673279804159@mail.yahoo.com>
References: <1795804180.9324624.1673260916531.ref@mail.yahoo.com>
 <1795804180.9324624.1673260916531@mail.yahoo.com>
 
 <519013808.9171830.1673279804159@mail.yahoo.com>
Mail-Followup-To: Filippo Moretti ,
 Warner Losh ,
 FreeBSD Current 
User-Agent: s-nail v14.9.24-390-g5eddb1e5df
OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD;
 url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt
BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in
 the world can make no bugs.
X-Rspamd-Queue-Id: 4NrLv85rmyz4Fw4
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N
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

Filippo Moretti wrote in
 <519013808.9171830.1673279804159@mail.yahoo.com>:
 |[filippo@ROXY ~]$ firefox
 |Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot \
 |access /sys/bus/pci (t=3.60308) [GFX1-]: glxtest: cannot access /sys/bus\
 |/pci
 ...
 |Thank you for your prompt answer.I tried your suggestion but did not \
 |work:I get the same error.Please note however that I have not linux \
 |emulation enabled as I run no linux program:Firefox was installed from \
 |ports and it is the native freebsd one.I will switch to another browser \
 |if needed.Filippo

fwiw i get the same in my unshare(1) / ip(8) netns etc etc boxed
firefox (running unprivileged (but being in "video" and "input"
groups) Xorg):

  bash-5.2$ ALSAPCM=xmix apulse firefox --no-remote
  [GFX1-]: glxtest: cannot access /sys/bus/pci

It never caused problems.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From nobody Mon Jan  9 17:28:30 2023
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 4NrPDm50rQz2pMLS
	for ; Mon,  9 Jan 2023 19:30:48 +0000 (UTC)
	(envelope-from Mathias.Picker@virtual-earth.de)
Received: from www94.your-server.de (www94.your-server.de [213.133.104.94])
	(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 4NrPDl52GXz4RST
	for ; Mon,  9 Jan 2023 19:30:47 +0000 (UTC)
	(envelope-from Mathias.Picker@virtual-earth.de)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=virtual-earth.de header.s=default_1811 header.b=BV62RNHo;
	spf=pass (mx1.freebsd.org: domain of Mathias.Picker@virtual-earth.de designates 213.133.104.94 as permitted sender) smtp.mailfrom=Mathias.Picker@virtual-earth.de;
	dmarc=pass (policy=none) header.from=virtual-earth.de
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=virtual-earth.de; s=default_1811; h=Content-Transfer-Encoding:Content-Type:
	MIME-Version:Message-ID:Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID:
	Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
	:Resent-Message-ID:In-Reply-To:References;
	bh=Dp2rggERKkFvAvCoGU8H+s7MzvmVdzGOnc9kAViKzog=; b=BV62RNHoj5uBieP4J7PghN6GIW
	HaQMkSuWKue3rQn38ibhJR3uisnXkFzjyzGiXOwnoLRUYcmu/ZjajUUXWPJJxSr4Un51ims4z4VJE
	qTBmn3PumlHs+YjCbZxGPKFsANkBOKxxqjKLRypEWmKJnjYtWLyM6M8CToIX9AeZAsD8MH6px7hEI
	0g13camLoFpjnVGun7tgE3gZ2q7UovWNbjyuC4dy1NxEcmoznaxI7cttO6DS6obonp+pg9SYOBkL2
	UXKQHl/RQJsTvO27JpAS+MKl5kMvzxQJFZEMSAur28sJ9DA0gM1Dj0I2/rKbl0LghiOc0f0MAhr1B
	HOH4se5Q==;
Received: from sslproxy04.your-server.de ([78.46.152.42])
	by www94.your-server.de with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from )
	id 1pExr2-000K8I-Tl
	for freebsd-current@freebsd.org; Mon, 09 Jan 2023 20:30:44 +0100
Received: from [2a01:c22:6eda:c100:4a2a:e3ff:fe1a:da58] (helo=danton.virtual-earth.de)
	by sslproxy04.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from )
	id 1pExr2-000FkZ-NM
	for freebsd-current@freebsd.org; Mon, 09 Jan 2023 20:30:44 +0100
User-agent: mu4e 1.8.13; emacs 28.2
From: Mathias Picker 
To: freebsd-current@freebsd.org
Subject: Trying to switch to 14-CURRENT for linuxulator netlink, now sudo
 hanging in sbwait in linux jail
Date: Mon, 09 Jan 2023 18:28:30 +0100
Message-ID: <86eds3sdy3.fsf@virtual-earth.de>
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; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Authenticated-Sender: Mathias.Picker@virtual-earth.de
X-Virus-Scanned: Clear (ClamAV 0.103.7/26776/Mon Jan  9 10:39:18 2023)
X-Spamd-Result: default: False [-4.00 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[virtual-earth.de,none];
	R_DKIM_ALLOW(-0.20)[virtual-earth.de:s=default_1811];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_IN_DNSWL_NONE(0.00)[213.133.104.94:from];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-current@freebsd.org];
	ASN(0.00)[asn:24940, ipnet:213.133.96.0/19, country:DE];
	MIME_TRACE(0.00)[0:+];
	DKIM_TRACE(0.00)[virtual-earth.de:+];
	RCVD_COUNT_THREE(0.00)[3];
	RCPT_COUNT_ONE(0.00)[1];
	MID_RHS_MATCH_FROM(0.00)[];
	ARC_NA(0.00)[];
	RCVD_TLS_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_NONE(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	HAS_X_AS(0.00)[]
X-Rspamd-Queue-Id: 4NrPDl52GXz4RST
X-Spamd-Bar: ---
X-ThisMailContainsUnwantedMimeParts: N

Hi all,

I was not sure if I should go with this to -current or -emulation,=20
I threw a coin and landed here :)
Tell me if I need to take this to -emulation.

I=E2=80=99m testing a few linux triplestore in a linux jail, and used 13.1=
=20
which worked fine most of the time.

Now one of the stores shows dropped connections with many clients,=20
and as I can see logs of netlink errors in the logs, I thought I=E2=80=99d=
=20
try -CURRENT.

I haven=E2=80=99t been on current for years, and have to say, beinstall.sh=
=20
is a very nice tool and a comfortable way to do this, especially=20
if one is on a remote server. With bectl activate -t this feels=20
quite safe. So, thanks to whoever did this!

Sadly, my linux jail (Ubuntu 16.04.7) now shows an irritating=20
behaviour, some programs seem to hang indefinitely waiting for=20
name resolution:

Inside the jail:

Working version with ping

root@bayerlinux:/home/mathiasp/triplestore-analysis/tmp# ping=20
google.de
WARNING: setsockopt(ICMP_FILTER): Protocol not available
PING google.de (172.217.16.131) 56(84) bytes of data.
Outside:
root@kap:/usr/home/mathiasp # tcpdump -ni bayerlinux_b
tcpdump: verbose output suppressed, use -v or -vv for full=20
protocol decode
listening on bayerlinux_b, link-type EN10MB (Ethernet), capture=20
size 262144 bytes
20:17:10.852625 IP 192.168.100.10.13809 > 192.168.100.1.53: 3191+=20
[1au] A? google.de. (38)
20:17:10.852668 IP 192.168.100.1.53 > 192.168.100.10.13809: 3191=20
1/0/1 A 172.217.16.131 (54)

Non-working with wget (same for curl and others)

Inside the jail:
root@bayerlinux:/home/mathiasp/triplestore-analysis/tmp# wget=20
http://google.de/
--2023-01-09 19:21:58--  http://google.de/
Resolving google.de (google.de)...=20
(waitet for max 5 minutes, no change)
Outside the jail:
root@kap:/usr/home/mathiasp # tcpdump -ni bayerlinux_b
tcpdump: verbose output suppressed, use -v or -vv for full=20
protocol decode
listening on bayerlinux_b, link-type EN10MB (Ethernet), capture=20
size 262144 bytes
20:17:02.738570 IP 192.168.100.10.60967 > 192.168.100.1.53: 30219+=20
A? google.de. (27)
20:17:02.738893 IP 192.168.100.1.53 > 192.168.100.10.60967: 30219=20
1/0/0 A 172.217.16.131 (43)

So, this tcpdump looks pretty much as if both got answers from=20
unbound.
Why is wget (and host, and curl, and sudo) not =E2=80=9Cgetting=E2=80=9D th=
is=20
answer?

Any ideas where to look or questions about my setup welcome!

This is on a current from around 4p.m. CET:

FreeBSD kap.virtual-earth.de 14.0-CURRENT FreeBSD 14.0-CURRENT #0=20
main-n259979-9408f36627b7: Mon Jan  9 16:36:51 CET 2023=20
root@kap.virtual-earth.de:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG=
=20
amd64

/etc/jail.conf looks like this:

$iface=3D"igb0";
$j=3D"/jail";
path=3D"/jails/$name";

mount.devfs;

exec.clean;
exec.start=3D"sh /etc/rc";
exec.stop=3D"sh /etc/rc.shutdown";
exec.prestart=3D"logger starting jail $name ...";
exec.poststart=3D"logger jail $name has started";
exec.prestop=3D"logger shutting down jail $name";
exec.poststop=3D"logger jail $name has shut down";

# generic hostnames

host.hostname=3D"$name.kap.local";



# vnet jails
vnet;
vnet.interface=3D"${name}_j";
exec.prestart+=3D"/usr/local/sbin/jailtobridge $name jailbridge0";
exec.poststop+=3D"/sbin/ifconfig jailbridge0 deletem=20
${name}_b;/sbin/ifconfig ${name}_b destroy";

exec.consolelog=3D"/var/log/jails/$name-console.log";


# virtual earth vnet jails


# linux jails
# needs FreeBSD ifconfig and route from /rescue to work!

bayerlinux {
mount.fstab=3D"/jails/fstabs/bayerlinux";
allow.mount;
allow.raw_sockets;
allow.read_msgbuf;
allow.socket_af;
sysvmsg;
sysvsem;
sysvshm;
#mount.devfs;
exec.start =3D "/etc/init.d/rc 3";
exec.stop =3D "/etc/init.d/rc 0";
persist;
}


Thanks,

Mathias

--=20
Mathias Picker=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20
Gesch=C3=A4ftsf=C3=BChrer
Mathias.Picker@virtual-earth.de

virtual earth Gesellschaft f=C3=BCr Wissens re/pr=C3=A4 sentation mbH
http://www.virtual-earth.de/           HRB126870
support@virtual-earth.de               Westendstr. 142
089 / 1250 3943=20=20=20=20=20=20=20=20=20=20=20=20

From nobody Tue Jan 10 04:46:30 2023
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 4NrdZ34j9Sz2pMbX
	for ; Tue, 10 Jan 2023 04:46:35 +0000 (UTC)
	(envelope-from jbeich@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "freefall.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4NrdZ34CN0z3tcN;
	Tue, 10 Jan 2023 04:46:35 +0000 (UTC)
	(envelope-from jbeich@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1673325995;
	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=175y090CF5rXvuQOy0QyHI+CzrtisseUZyZCLHLe38M=;
	b=xanZEsSgd2YdOdp3u+7+a385CbcQ1YBv+V7TLSgfqV14wCK8lqZBfcuG3G224ZUtgNcs7z
	TBkyBjTWljkamT9vWZaxk4+UbA9BsycfmkHAjdQrmVU6j7EQfhVPH3Fc7EGJpW5GL7eDdN
	3pbdRXtM8ZMzVshu/5cfktMUvu1qjmJ7T13gCHStVFg2PMWg9nLHeVijhbNEnqRSzWfuCn
	USC+QXyvveYmcyoO5gPne4nv29j+YaRPVVzcz4k1SmolIZ3jM0pggAW+0H5kIQhKyD/Dd6
	sFTkIZwAGAzN9Bu4eLStR9DE25ZruX7Mtkl04jIiLrwRZWhs3vuCRiszek/MnQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1673325995;
	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=175y090CF5rXvuQOy0QyHI+CzrtisseUZyZCLHLe38M=;
	b=sYTiOBEaKITAOMHF1O1KDaVo7WElgcC3uEdsYgMQKc8ijQ3xX+ipiJVTiYrc3p2bkezDNP
	VBL89HVmqMesBwX5ykU+c4EghBwmBeDuIa1Fyelbo+ZIDY2DTF9KBftDClxATdBDcakoq+
	YM9HsOgI9T+kfdOB5IkVyfgcb+rNVfQbegjpz0nWmG499LxpziiGMD4O3thaXidTOGvQPI
	vyPRmGik304VivRzEgrgOCsjD/2asQAhjYZ/HxSpKE7sGVt1fEwG7E6sdjjuzi5ob6dYF2
	Fds2vSx5rP25HbLO5FreitU5zECIkYo5myNDETeaFQm87JV2Y4POfcsRs7JRFA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1673325995; a=rsa-sha256; cv=none;
	b=pe1TO6XjM48Or86ZIgoUKwnXbO0sW3vgPLzr2imeuyZsHETRvksG1pP85gkJfWIwWDLhxr
	gKBhKdc6LMxS17KSfLTksY9Q/9lN7klk7L7pRbHABaEHPi/M+LYr3FZGaUO9l1RMrU/TK5
	5ppz3T5NuFqZu8M5CnrToegBGhgmB7SoQoWb/jEA7AtZArBkaqlM7mxkpiJQ4llsAEoDRC
	lQXyvCSkNmpTQ5+T/I+PKexlGELBDmJ8xIbhY6TQblRFEvqOUwucVe9WSixjI5z/Bzdp9V
	X+T6dapK+dT0a7Msh0S55d4tIceIkkjjUDrhQYoehSpp66x+1/vSIklXtiLVpw==
Received: by freefall.freebsd.org (Postfix, from userid 1354)
	id 7A5EF12E9E; Tue, 10 Jan 2023 04:46:35 +0000 (UTC)
From: Jan Beich 
To: Filippo Moretti 
Cc: FreeBSD Current 
Subject: Re: Problem in userland
In-Reply-To: <1795804180.9324624.1673260916531@mail.yahoo.com> (Filippo
	Moretti's message of "Mon, 9 Jan 2023 10:41:56 +0000 (UTC)")
References: <1795804180.9324624.1673260916531.ref@mail.yahoo.com>
	<1795804180.9324624.1673260916531@mail.yahoo.com>
Date: Tue, 10 Jan 2023 05:46:30 +0100
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
X-ThisMailContainsUnwantedMimeParts: N

Filippo Moretti  writes:

> Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: cannot access /sys/bus/pci (t=3.60308) [GFX1-]: glxtest: cannot access /sys/bus/pci

Regressed by https://bugzilla.mozilla.org/show_bug.cgi?id=1696691
but only impacts https://bugzilla.mozilla.org/show_bug.cgi?id=1676883

This may affect whether some GPU features are enabled by default based
on vendor_id + device_id allow-list. Nothing more.